Beiträge von Curiosity

Laut Beschreibung des Artikels steht da folgendes.

Artikelzustand: rezertifiziert, werkseitig versiegelt, null Stunden Laufzeit

sebcodes

Danke für den Link, ich meine, den habe ich schon mal gelesen gehabt. Allerdings beim Überfliegen ist mir schon aufgefallen, das der eher für die UDM/Pro ist. Die genannten Tools funktionieren bei der UDM Pro SE wohl nicht mehr, vor allem wenn da jetzt schon die 3.x drauf ist.

Aber ich lese mich da heute Nachmittag nochmal rein. Ist auf der Arbeit gerade etwas schlecht.

Hallo @all,

so hab heute Nachmittag nochmal nach einer Lösung gesucht und für mich eine Zufriedene Lösung gefunden, die sogar einen Reboot übersteht.

Da ja auf der UDM-SE ein Debian Bullseye Unterbau besteht konnte man das Problem relativ einfach lösen ohne zusätzliche Software zu installieren.

und zwar über die aktuell Entfernte Datei in Debian Bullseye /etc/rc.local

Also per SSH auf die UDM-SE einloggen und die Datei /etc/rc.local mit folgendem Standard-Inhalt anlegen:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.systemctl start rc-local# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
exit 0

Die Datei mit folgenden Kommando ausführbar machen: chmod +x /etc/rc.local

Danach den systemd Manager mit systemctl daemon-reload konfigurieren.

Jetzt wird der rc-local Daemon mit systemctl start rc-local gestartet.

Läuft alles? Ein kurzer Check des Status vom rc-local mit systemctl status rc-local. Jetzt sollte die Ausgabe so aussehen:

● rc-local.service - /etc/rc.local Compatibility
     Loaded: loaded (/lib/systemd/system/rc-local.service; enabled-runtime; vendor preset: enabled)
    Drop-In: /lib/systemd/system/rc-local.service.d
             └─debian.conf
     Active: active (exited) since Wed 2023-08-09 17:08:32 CEST; 43min ago
       Docs: man:systemd-rc-local-generator(8)
      Tasks: 0 (limit: 4724)
     Memory: 0B
        CPU: 0
     CGroup: /system.slice/rc-local.service

Danach hatte ich dann meine eigentliche rc.local mit meinen Iptables Inhalt gefüllt. Das sah dann so aus:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.


#Redirect DNS Traffic over Pihole

iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to 10.x.x.x
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 10.x.x.x
iptables -t nat -A PREROUTING -p tcp --dport 853 -j DNAT --to 10.x.x.x
iptables -t nat -A PREROUTING -p udp --dport 853 -j DNAT --to 10.x.x.x 

exit 0

10.x.x.x ist natürlich die IP des Pihole.

Danach habe ich den rc.local Daemon mit systemctl restart rc-local neugestartet und et voilà: fertig war meine Reboot-resistente Änderung für die Umleitung des DNS-Traffics über meine Pi-Holes (hab das nach der Arbeit natürlich gleich mit einem reboot der UDM-SE getestet, läuft ). Jetzt kann sich kein fest einprogrammierter DNS-Server-Eintrag von irgendwelchen Geräten an meinen Pi-Holes vorbeimogeln. Außer natürlich verschlüsselter Traffic über DNS over HTTPS (DoH). Für das Schlupfloch habe zusätzlich eine Liste auf dem Pi-Hole eingepflegt, die einige DoH-Server filtert.

Beim mir funktioniert die Iptables-Umleitung ohne die Masquerade-Regel, da mein Pi-Hole in einem separaten Subnetz liegt, wie der Rest der Netzwerke. Die Clients bekommen davon nichts mit, das passiert transparent, die meinen die Antwort von ihren einprogrammierten DNS Server zu erhalten. Wie in folgenden Beispiel hab ich mal einfach die Abfrage von einem Client gestartet und einen abzufragenden DNS-Server angegeben:

loxberry@loxberry:~ $ dig qnap.de  @8.8.8.8

; <<>> DiG 9.16.42-Debian <<>> qnap.de @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24268
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ec5b5eab000a80079a615cec64d3be5745ae27d7b50cdb25 (good)
;; QUESTION SECTION:
;qnap.de.                       IN      A

;; ANSWER SECTION:
qnap.de.                2400    IN      A       18.233.144.27
qnap.de.                2400    IN      A       3.222.6.149
qnap.de.                2400    IN      A       34.195.88.28

;; Query time: 36 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Aug 09 18:27:03 CEST 2023
;; MSG SIZE  rcvd: 112

Angeblich wurde der 8.8.8.8 abgefragt, aber die Antwort kam von meinem Pi-Hole:

Nicht wundern über den Pi-Hole-Port 533. Das ist mein BIND-DNS Upstream-Server für den Pi-Hole. Der ist für die lokale Namensauflösung meines lokalen Netzwerks und die eigentlich Auflösungen der IP-Adressen des Internets verantwortlich. Dieser leitet dann alle Anfragen, die er nicht selbst beantworten kann entweder über den DNSCrypt-Proxy oder Stubby weiter, damit diese dann die korrekte IP liefern. Der Pihole ist also praktisch die Vorfilterung meiner IP-Abfragen.

Hallo, nachdem ich die Tage über diesen Thread hier gestolpert bin, wollte ich das ganze auch bei mir umsetzen, da ich kürzlich mein ganzen Netzwerk nach dem Firewall Tutorial 2.0 umstrukturiert habe. Dazu gehörte jetzt natürlich auch, dass vorbei schleichen an meinen beiden Piholes (inkl. interne BIND Konfiguration). Durch das setzen der block Regel für DNS Anfragen von externen DNS Servern ist mir aufgefallen, das es zur Zeit zwei Geräte beim mir gibt, die meinen die 8.8.8.8 (Google) zu benutzen. Was ich natürlich nicht okay ist, wozu benutzt man sonst einen Pihole?

Da wurde mal wieder das gute Orakel befragt und so bin ich auf diesen Thread gestoßen und wollte nun das ganze bei meiner UDM-SE umsetzen. Hab es gestern ausprobiert. Aber irgendwie haben bei mir die oberen Beispiele irgendwie nicht so ganz gepasst, in der Log vom Pihole wurde angeblich alles vom Gateway beantwortet, was ja nicht stimmte.

Also etwas weiter gesucht und hab dabei noch eine andere Webseite gefunden gehabt, die ich Euch nicht vorenthalten möchte. Das hat bei mir auf Anhieb hin gehauen, sogar ohne die MASQUARAD Regel. [EDIT on] Wohl, weil meine beiden Piholes sind in einem anderen Subnetz, als die UDM SE. Benutze zwei Piholes die per Failover arbeiten und damit immer unter der gleichen IP zu erreichen sind wenn einer mal ausfallen sollte, übernimmt der andere sofort mit gleicher Datenbank, da beide Syncronisiert. [/Edit off]

Obwohl die Abfrage intern vom Pihole beantwortet wurde, meinte der Sky Receiver den Google DNS benutzt zu haben. In der Log vom Pihole ist auch die Abfrage des Pihole zu sehen gewesen.

Diese Webseite hat mich wieder einen Schritt weitergebracht, mein Netzwerk nach meinen Vorstellungen anzupassen.

Folgende Iptables hab ich für meine UDM-SE benutzt:

iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to 10.x.x.x
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 10.x.x.x
iptables -t nat -A PREROUTING -p tcp --dport 853 -j DNAT --to 10.x.x.x
iptables -t nat -A PREROUTING -p udp --dport 853 -j DNAT --to 10.x.x.x

So hat das ganze bei mir wirklich transparent in allen VLANs funktioniert.

Jetzt muss ich nur noch rausfinden, wie die Iptables Regeln automatisch bei einem Reboot der UDM-SE oder Firmware update beim start ausgeführt werden.

Über einen geeigneten funktionierenden Tip würde ich mich freuen.

Oh, sollte wohl lieber ins Bett gehen, ist schon spät … hab gar nicht mitbekommen dass ich nicht auf den TE geantwortet habe … man sollte etwas aufmerksamer um diese Uhrzeit lesen.

Ah okay, hab gerade mit dem iPad Online nachgesehen, hab jetzt den Punkt auch gefunden. Aber leider bekomme ich das mit dem iPad nicht hin. Muss ich morgen am großen Rechner mal machen um den direkten Vergleich zu machen mit meinen alten Plan.

Ich hatte bei mir übrigens die Außenwand laut Bauplan Zeichnung genommen und die entsprechende Meterzahl eingetragen.

Ich gehe mal davon aus, dass du die höhe des montierten Access Point auch eingetragen hast oder ?

Zitat von mtbz

[…] Mit dem UDR und 5GHz sähe dein Erdgeschoss in der Theorie so aus: […]

Ist denn bei den Online UI Designer ein Maßstabs Anpassung erfolgt? Bei dem alten Maps musste man eine Linie vom Plan, am besten eine Außenwand von Anfang bis Ende Makieren und dann dieTatsächliche Meter Zahl eintragen. Dann hatte der Designer daraus den Maßstab errechnet und schon waren die Austrahlungen des Access Points deutlich besser.

Ob das jetzt bei den neuen Online UI Designer geht weiß ich jetzt leider nicht, hab mich mit dem noch nicht weiter beschäftigt gehabt.

UPnP ist bei mir auch deaktiviert und das auch schon seit ich damals die Fritz!Box als Router verwendet hatte. Möchte schließlich wissen was bei mir im Netzwerk los ist und nicht plötzlich vor lauter offenen Ports stehen, weil irgendein Program meint was zu öffnen zu müssen.

Jack Das kann ich dir leider nicht beantworten, da ich mein myFritz nie wirklich verwendet habe. Seit dem ich Unifi habe, kann ich intern nicht mal die FritzFon App benutzen, da er die FritzBox im Netzwerk nicht findet, da die im eigenen VLAN hängt. Die FritzBox meint immer, ich komme aus dem Internet, weil anderer IP Bereich und lässt das nicht zu.

Aber jetzt besser wieder Back2Topic, wir driften hier zu weit ab.

Zitat von phino

Die 5060 wird für die reinkommenden Anrufe benötigt. Zusätzlich noch in der Fritz!Box folgende Einstellung vornehmen.

Hallo Phino,

warum eigentlich den Port 5060 freigeben? Ich habe auch einen Telekom Anschluss und bei mir funktioniert die Telefonie seit über zwei Jahren (vorher USG 4 Pro, jetzt UDM-SE) ohne irgendwelche Portweiterleitungen auf die Fritz!Box. Nach draußen ist die UDM-SE komplett verschlossen, bis auf den VPN WireGuard Zugang.

Zitat von swag

Aber das kann sie doch. Am Internet Port einen dyndns Service auswählen. Ggf. die server url anpassen um andere kompatible Provider auszuwählen.

[…]

Hallo swag,

ja, das weiß ich ja und hab es ja auch so gemacht. Trotzdem steht einem im Menü nur einmal eine „DynDNS“ Auswahl zur Verfügung. Ansonsten lassen sich nur andere Anbieter auswählen. Was aber eigentlich quatsch ist, wenn man sich später die eigentliche Konfig auf der UDM-SE anschaut. Da steht nicht einmal der vorher ausgewählte Dienst drin. Von daher ist es eigentlich egal, welchen Anbieter von dem DynDNS Dienst ausgewählt wird. In der anschließenden Konfig steht da nichts von drin. Sondern nur die Daten die die in deinem Beispiel angegeben hast. Domainname, Server, Username, Passwort, URL usw.

Von daher hätte man sich die kleine Auswahl im Menü sparen können und die Einträge einfach so händisch zum entsprechenden Anbieter eingetragen.

Der einfache User weiß das aber nicht und nimmt vielleicht an, das er seinen Dienst nicht benutzen kann, da er nicht in der Liste steht.

Was ich aber auch noch nicht wusste ist, wenn man z.B. mehrere Domains beim gleichen DynDNS Dienst hat, das man alle Domains/Hostnames in der Konfigzeile eintragen kann und nicht für jede Domain eine extra Konfig braucht.

Zitat von gierig

Na ja ein wenig reißerisch und ein wenig drüber auch wenns grob so stimmt.

[…]

Und ja klar die UI Kiste gibt sich selber keine eigne IP was dann auch ein /64 weniger bedeuten

würde sondern gibt ALLES zu deinen Netzen weiter.

Alles anzeigen

Ja, da hast du Recht, manche Videos sind etwa auf Bildzeitungs Überschriften Niveau …

Aber ich mag den Typ irgendwie, entgegen so manche anderen Technik Tutorials auf YouTube (manchen kann man echt nicht zuhören und schläft ein oder schaltet ab) kann man da wenigstens zuhören.

Aber zurück zum Thema. Das mit dem Prinzip IPv6, kein NAT usw. Ist mir ja schon klar.

Ich möchte halt nur, das die UDM-SE einfach ihre öffentliche IPv6 beim DynDNS Dienst veröffentlicht um sie von außerhalb darüber zu erreichen. Wenn ich ein DynDNS Dienst auf einem meiner Rechner laufen lasse, erscheint dessen IP dort. Aber das will ich ja nicht, es soll ja schließlich die des Routers erscheinen. Denn auf dieser läuft ja schließlich auch mein VPN Zugang und nicht auf den Kisten dahinter.

Was mich aber echt stört ist, das so mache Funktionen einfach nicht implementiert sind und nur nach und nach in Updates nachgereicht werden. Auch die DynDNS Einstellungen in der Oberfläche sind etwas unflexibel, erst einmal ist nur eine Handvoll Anbieter vorhanden, dann kann man zwar einen Custom Anbieter programmieren, aber dann auch nur einen, einen zweiten unbekannten geht nicht.

Naja, aber ich weiche ab. Die Implementierung von IPv6 scheint bei UniFi noch in den Kinderschuhen zu stecken.

Zitat von MeisterEder

Ich habe jetzt mal den ubiquiti support angeschrieben und dem Mitarbeiter das Problem geschildert. Vielleicht könnten andere das auch tun, damit denen das Problem überhaupt bewusst wird. Denn ich will keine Fritz kaufen müssen, das wäre erbärmlich.

Hi, ist ja so ähnlich wie das Dilemma mit den Abgleich der IPv6 DynDNS Adressen. Bekomme zwar ne IPv6 von der Telekom, aber ich kann sie nicht bekannt machen, da die betroffene Schnittstelle nicht von derer Existenz weiß ...

Nach dem ich mir das Video von Dennis Schröder angesehen habe, weiß ich auch warum ... Irgendwie ist die Software mit mehr als nur mit einer heißen Nadel gestrickt worden.

Zitat von hommes

Oh cool danke für die Information, das ist dann ja doch wieder etwas einfacher, Softwarestände bei dir auch gleich gewesen oder unterschiedlich und ich denke dann nicht über die Cloud gemacht, oder?

Puh gute Frage, ich weiß nicht, wann der Cloudkey Gen1 sein letztes offizielles update hatte, das was als letzte Online war, war aufgespielt und mein letztes Backup was ich noch aus der Festplatte vom Cloudkey Gen2 Plus auslesen konnte eingespielt. Lief zum Glück ohne Probleme und soweit ich weiß und in Erinnerung hatte waren die Software Stände unterschiedlich gewesen. Kann ich aber auch nicht zu 100% beschwören.

Hi,

Also ich bin Anfang Mai von dem CloudKey Gen.1 und USG 4 Pro auf die UDM-SE umgezogen. Hab mein aktuelles Backup eingespielt und fertig. Einzig mein Protect musste ich neu Konfigurieren, da es vorher auf einen CloudKey 2 Plus installiert war, der ist mir allerdings Anfang des Jahres abgeraucht und da musste der Cloudkey Gen1 wieder ran. Zum Glück war der noch in der Schublade. So hatte ich die Zeit mit den alten überbrückt, bis die UDM-SE einzog.

Also bei mir hat das Einspielen des Backups vom Cloudkey 1 zu UDM-SE geklappt. Selbst die manuellen Einstellungen der Config für das USG 4 hatte ich irgendwo in den Verzeichnisen der UDM-SE wiedergefunden. Ob die allerdings benutze werden, entzieht sich meiner Kenntniss.

Zitat von LachCraft

Hilft dir das?

https://fccid.io/SWX-UCKG2/Int…7624?utm_content=cmp-true

Den gleichen link wollte ich auch gerade posten. Warst einem Moment schneller.

Hallo,

Meinen Beileid, genau das gleich hatte ich letztes Jahr auch mit meinen Cloudkey 2 + gehabt. Von heute auf morgen ging nix mehr. Garantie natürlich auch abgelaufen (war nicht ganz zwei Jahre in Betrieb).

Also im Netz mal schlau gemacht und nachgeschaut, da ich das Teil im Netzwerkschrank mit dem „teuren“ 19“ Zusatz verbaut hatte musste erst einmal alles demontiert werden. Obwohl kein Display an war, war die Kiste in der nähe des POE Ports höllisch heiß gewesen, das lies nichts gutes vermuten und so wie ich gelesen hatte, hat der Akku wohl dicke Backen bekommen und es wäre wohl besser ihn ohne zu betreiben.

Also Kiste nach Anleitung zerlegt (wenn man keine zwei linken Hände hat ist es relativ einfach). Problem war nur, der Akku war so extrem aufgebläht, das man ihn so gut wie gar nicht aus dem Gehäuse bekommen hat. Mit reichlich Geduld und vorsichtiges ziehen hab ich es dann irgendwann geschafft die Platine herauszudrücken. Die Wärmeleitplatte hat sich auch schon gelöst gehabt und wär auch nicht mehr an seinem Platz.

Was soll ich sagen, der Akku war wohl kurz vorm Platzen, zum Glück ist das Teil nicht in Flammen aufgegangen.

Einen neuen Akku zu besorgen und diesen einzubauen, kam für mich nicht in Frage. Wollte so eine tickende Zeitbombe nicht mehr im Haus haben. Also dachte ich mir, dann betreib ihn ohne. Sollte ja gehen. Also POE Kabel dran … Nadda … nichts … aber auch keine Reaktion vom Teil. Die einzige Reaktion die kam, war das die Platine sich innerhalb kürzester Zeit aufheizt und einige Bauteile so heiß wurden, das man sie nicht berühren konnte. Denke mal das irgendwas auf der Platine für den POE Bereich in Mitleidenschaft gezogen worden ist.

Also das ganz mal mit einem USB Netzteil ausprobiert. Leider hatte ich nicht ein einziges, was wohl genug Strom für den Cloudkey lieferte. Die blaue LED blinkte kurz, das Display war kurz an und resetet sich dann immer wieder. Kein Arbeiten möglich. Außerdem blieb immer das ungute Gefühl, wann denn das Teil endgültig seinen Geist aufgibt.

Für mich stand zu diesem Zeitpunkt fest. Nochmal über zweihundert Euro für die Tickende Zeitbombe auszugeben, war ich nicht bereit. Das Wärme Management des CloudKey2 + ist Miserabel und in meinen Augen mit dem Akku auch noch sehr Brandgefährlich.

Zum Glück hatte ich noch den Cloudkey 1 in der Schublade gehabt und ihn mit dem Backup der Konfiguration in Betrieb genommen. Allerdings musste ich auf die Protect Geschichte eine gewisse Zeit verzichten. Da ich schon eine gewisse Zeit mit dem Gedanken gespielt hatte, meine USG Pro 4 vorzeitig in Rente zu schicken, POE Ports auf dem 16’er wurden auch schon knapp, hatte ich mir gedacht in investiert in eine UDM Pro SE und kann somit die fünf Kameras gleich darüber versorgen.

Hat nur ein bisschen gedauert, da die Preise durch die Pandemie und Krieg ordentlich gestiegen waren und ich nicht bereit dazu gewesen bin die überhöhten Preise zu bezahlen, jetzt wo alles so extrem Teuer geworden war.

Jetzt läuft bei mir wieder alles und ich bin mit der Geschwindigkeit der neuen UDM SE sehr zufrieden und hab noch dazu einen HE mehr Platz im 19“ Schrank bekommen.