UDM Pro: Umgehung von Pi-Hole nicht mehr möglich

[TWIN013]

Moin zusammen!

Ich stehe hier gerade vor einem für mich nicht mehr nachvollziehbaren Netzwerkproblem und hoffe auf einen entscheidenden Tipp von euch. Folgende Ausgangssituation ist gegeben:

UDM-Pro 192.168.0.1
QNAP-NAS 192.168.0.20
Pi-Hole (als Docker auf QNAP) 192.168.0.30
Unbound (als Docker auf QNAP) 192.168.0.35

Unbound ist als Custom-DNS in Pi-Hole eingetragen.

In der UDM-Pro habe ich unter Settings/Networks/WAN als DNS-Server üblicherweise den Pi-Hole hinterlegt, also die 192.168.0.30

Jetzt wollte ich zum Zwecke des Updates des Pi-Hole Containers diesen "aus dem Loop nehmen" und habe den DNS-Server in der UDMP einfach gelöscht. Das scheint zu funktionieren, denn Webseiten etc. werden mir jetzt wieder mit Werbung angezeigt. Allerdings: sobald ich den Pi-Hole Container stoppe, geht gar nichts mehr! Weder per PC über Browser noch über die QNAP (die ja Netzzugriff bräuchte, um ein aktuelles Docker-Image zu laden) geht noch was. Ich habe es also irgendwie geschafft mir eine Abhängigkeit von diesem Container einzufangen, die ich nicht finde. Habt ihr evtl. eine Idee, wo ich suchen könnte?
Danke schon mal!

 

[pumuck|]

irgendwie hast du ja schon im eigenen Netz eine kaskadierende DNS Auflösung gebaut. Warum benutzt du denn unbound zusammen mit pihole? Standard wäre eines davon, je nach Anforderung...

hast du in deinem Endgerät mal den DNS Cache gelöscht?

 

[TWIN013]

Unbound als unabhängigen DNS zu nutzen und somit ein wenig mehr Privatsphäre zu schaffen war hierzu die ursprüngliche Idee - PiHole dagegen als Werbefilter. Habe Unbound mal rausgenommen und den PiHole DNS auf Cloudflare gesetzt, das funtioniert.

Zum DNS Cache: wir reden jetzt vom Win10-PC? Nein, wie macht man das in diesem Fall?

Edit: ipconfig/ renew war die Lösung! Es kann so einfach sein... Danke!

 

[kamanu]

Deine Lösung hast du ja gefunden. Falls dich noch interessiert wieso sie funktioniert hat:
Dein PC bekommt via DHCP seine IP-Adresse zugewiesen. Gleichzeitig werden ihm aber auch noch Gateway (UDM-Pro) und DNS (Pihole) mitgeteilt.
Diese Einstellungen bleiben so lange, bis deine IP-Adresse im DHCP abläuft und der PC sich eine neue zieht.
Mit deinem "ipconfig /renew" hast du dir schlicht vorzeitig eine neue IP (und damit den neuen DNS-Server) gezogen.
Davon ab sollte es eigentlich nicht lange dauern das pihole zu updaten? Als ich letztens mit pihole und docker rumgespielt habe hat ein Neustart des Containers (bei dem er dann ein aktuelles Image gezogen hat) vllt 10s gedauert. Danach war alles wieder erreichbar.

 

[TWIN013]

Es sah für mich leider so aus, als wäre damit auch die QNAP vom Netz abgeschnitten und somit der Download des aktuellen Images leider nicht möglich - und ich wollte mir dann ungern den Pi-Hole Container zerschießen, der ja dann "lebenswichtig" erschien.
Dennoch nochmal vielen Dank für die Erläuterung, ist immer gut sowas nochmal Revue passieren zu lassen. Man lernt immer dazu....

 

[Klikidiklik]

Zum DNS Cache: wir reden jetzt vom Win10-PC? Nein, wie macht man das in diesem Fall?

"ipconfig /flushdns" hätte ich zunächst mal probiert.

 

[-THOR-]

Hallo, ich habe fast das identische Setup wie du.
Lediglich redundant mit einem PiHole und einem ADGuard für Ausfallsicherheit.

Neben dem schon angesprochenen Cache Problem fällt mir noch etwas anders:


Im EIngangspost schreibst du du hast den DNS bei deiner UDM unter den WAN Optionen raus genommen.
Warum ?
Das hat nichts mit deinem Netzwerk und den Clients erstmal zu tun, sondern sind die DNS Server für die UDM die sie selbst benutzt um Adressen oder Ziele aufzulösen.

Ich nehme an du benutzt sie auch als DHCP Server, dann ist die "richtige" Einstellung für dich unter Networks -> Dein Internes Netz -> DHCP Name Servers (DAS IST DUMM BESCHRIEBEN! - in den Feldern stehen sie in grau dann eindeutig als "DNS").

Hier musst du deinen neuen DNS Server eintragen damit er an die Clients verteilt wird, sonst versuchen sie weiter deinen PiHole zu erreichen und können es nicht.

@pumuck| :
sein kaskadierendes Setup macht Sinn, die Kernfrage ist nämlich welchen DNS Servern kann man vertrauen und es ist auch nicht abwegig es so aufzubauen wie er. Gibt jede Menge Tutorials genau zu dem Thema. Nicht ganz uninteressant sich da mal rein zu lesen wenn man sich dafür interessiert .



EDIT:

Nach genauer Überlegung ist mir noch etwas unklar. Und da weiß ich nicht genau wie sich die UDM verhält.
Was kam bei deiner ersten Einstellung mit dem PiHole als DNS in den WAN Einstellungen dann als DNS per DHCP bei deinen Clients an ?

Kann es sein das die UDM sich selbst als DNS zu den Clients dann verteilt, selbst aber alle Adressen über den PiHole auflöst, da der als DNs für sie selbst eingetragten ist ?

Mir ist nämlich gerade nicht klar ob die UDM bei nicht definiertem DHCP DNS Server einfach den "externen" WAN DNS Server an die Clients automatisch verteilt, oder sich selbst "einsetzt".

Falls ersteres wäre da noch Optimierungspotential bei dir, denn es ist nicht sehr sinnvoll das alle Anfragen erst an die UDM gehen, die sie dann wiederum weiterleitet an deinen PiHole.

 

[TWIN013]

Guten Morgen!

Ja, ich nutze die UDMP als DHCP-Server. Auf die Einstellung im WAN Bereich kam ich durch einen (leider jetzt nicht mehr für mich auffindbaren) Eintrag in einem Ubiquiti-Forum und das hatte für mich den Charme, diesen Eintrag nicht jeweils separat für LAN, IoT-LAN, Guest-LAN etc setzen zu müssen.

Als Standardgateway wird meinem PC per DHCP die 192.168.0.1 - also die IP der UDMP - mitgeteilt. Ich nehme an das ist die Bezeichnng unter Win10 für DNS?

 

[-THOR-]

Guten Morgen ,

ok, Gateway ist schon richtig. Das muss die UDM sein. Das ist für deine Clients der „Zugang“ zum Internet.
Mache auf einem deiner Clients mal die eingabeaufforderung auf und gebe ipconfig ein.
Dann siehst du was sie als DNS zugeteilt bekommen haben.

wie gesagt weis ich nicht genau wie sich die UDM bei der WAN DNS Einstellung verhält.
Bei allen FritzBoxen und Tcom Routern ist das Verhalten aber garantiert so das sie als DNS immer sich selbst an alle Clients verteilen (es sei denn es ist etwas abweichendes konfiguriert) und die WAN DNS Einstellung hat da auch gar keinen Einfluss drauf.
das ist auch logisch und daher gehe ich davon aus die UDM macht es auch so.
kann es leider bei mir gerade nicht überprüfen da ich für jedes Subnetz eigene DNS Server manuell konfiguriert habe, bzw in meiner aus dem Internet erreichbaren DMZ gar kein DHCP nutze.

btw vllt magst du dir ja jetzt einen zweiten DNS aufsetzen um den Fall mit dem Ausfall immer ausgleichen zu können . Daher hab auch ich es so gemacht auf zwei getrennten Raspi Pi , so kann ich einen rebooten , umbauen usw und das Netzwerk funktioniert weiter.
Bei dir würde ja erstmal ein zweiter Docker Container reichen, hängt halt dann immer noch alles an dem einen Host :-D (QNAP) die dann der Single Point of Failure ist.

 

[Raijin]

Es sollte via DHCP immer die IP des DHCP-Server selbst verteilt werden, weil sonst keine lokalen Namen aufgelöst werden können. Es sei denn man verwendet im anderen DNS eben den DHCP-Server als Upstream-DNS oder man konfiguriert dort conditional forwarding für die lokale Domain. D.h. der DHCP-Server sollte stets in der DNS-Aufrufkette präsent sein, wo genau ist unerheblich.

 

[-THOR-]

Das stimmt mit der internen Auflösung, die Frage ist ob er das muss/es ein Problem ist.
Meine internen Hosts spreche ich alle direkt mit IP an.
Eins der Probleme muss er nämlich in seinem Setup in Kauf nehmen. Es sei denn er ergänzt die conditional forwarding Einträge natürlich.

in der von dir beschrieben Einstellung werden seine DNS Antwort Zeiten extrem hoch.

Denn der Client fragt die UDM, die wiederum den Pihole und der wiederum seinen unbound der dann rekursiv auflöst und alles zurück.
Das ist unglaublich ineffizient.

andere Option wäre die DHCP Funktion in dem PiHole zu verwenden und über die UDM keine Adressen zu verteilen.
Allerdings finde ich den DHCP Server des PIHole sehr sehr simpel, aber das muss jeder für sich selbst entscheiden.

 

[TWIN013]

Der PiHole erschien mir damals nicht unbedingt eine gute Wahl als DHCP Server und aufgrund der Separierung meiner Netze (Privat, Gast, IoT) mit eigenen IP-Bereichen die UDMP eigentlich recht praktisch.
Bietet sich denn eine dedizierter DHCP (evtl. ebenfalls auf Docker-Basis) für eine solche Lösung eher an?

 

[-THOR-]

Das sehe ich auch so und hab es daher auch nie benutzt.

das geht, ändert aber nichts an dem von @Raijin geschilderten Problem.
um ehrlich zu sein sehe ich dieses Problem bei dir aber gar nicht.
Er mag recht haben in großen Netzen in denen man viele interne Hosts über URLs erreichen will. Da wird das dann nicht ohne weiteres gehen.
Aber tust du das ?
Hast du viele Geräte wie dein NAS zb das du über eine URL im Browser aufrufst ? Oder nutzt du dafür direkt die IP. Dann ist das Problem mit der internen Auflösung für dich gar nicht erst existent.

Und selbst wenn du 3-4 Hosts hast die du über die URL erreichen willst, dann kannst du die als statische Einträge in deinem PIHole hinzufügen und dann kann er die auflösen auch wenn die UDM dein DHCP Server ist.

wie gesagt sehe ich daher auch gerade nicht das Problem.
Um es in einem Beispiel zu zeigen wie ich es gemacht habe:
Wie erwähnt habe ich 2 DNS und die UDM ist DHCP Server. Die UDM verteilt als DNS Server die beiden genannten Server an alle Clients.
Daneben gibt es bei mir einige Raspis, Dell Server, Nas Server die ich immer erreichen muss da auf ihnen Web Server/NAS/Docker Host usw laufen.
Daher sind in jedem Subnetz bei mir die ersten 30 IP Adressen für den DHCP gesperrt.
Diese ersten 30 Adressen kann ich also fix auf die genannten Hosts statisch verteilen (in den Geräten eingetragen). Bzw ist in der DMZ aus Sicherheitsgründen alles manuell.
so haben sie immer die selbe IP Adresse.
Als letztes füge ich diese fixen Einträge mit Host Namen dann noch in die Static Host Table der DNS Server ein.

so alle Probleme gelöst, alles auflösbar.
Da wir hier nicht über 200 Host Einträge reden ist der Aufwand finde ich verschmerzbar.

 

[Raijin]

@TWIN013


Also als DHCP nutzt pihole standardmäßig dnsmasq, das in der Linux-Welt durchaus weit verbreitet ist. Es ist auch nicht auszuschließen, dass in diversen Routern selbst dnsmasq zum Einsatz kommt.

DHCP ist bei pihole allerdings auch nur eine optionale Zusatzfunktion. Es spricht nichts dagegen, pihole als DNS und den Router weiterhin als DHCP-Server einzusetzen - das eine hat mit dem anderen nichts zu tun.

Wenn man DHCP und DNS auf getrennten Systemen betreibt, muss man aber zB conditional forwarding konfigurieren, wenn man lokale Namen auflösen will, weil pihole ja die DHCP-Clients des Routers und deren Namen nicht kennt.

 

[-THOR-]

@Raijin : nichts für ungut, aber sprichst oder erzeugst du für ihn hier nicht ein Problem das er eventuell gar nicht hat ?

bisher hat er noch nicht bestätigt das er überhaupt interne Adressen auflösen will/muss.

Und conditional forwarding Konfigurieren muss er auch nicht, wie gesagt reicht auch der Static Host Eintrag.
Ich finde wir sollten ihm nicht mehr Probleme machen als er hat/hatte.

edit: und zu der Pihole DHCP Sache. Ja auch wenn es in der Basis eventuell das dnsmasq Paket ist, so bietet die GUI nur minimalste Einstellungen. Beispielsweise ist ein sekundärer DNS gar nicht erst einstellbar (bzw. war er es nicht als ich es getestet hatte.
Natürlich könnte man direkt per Console die Konfig Dateien bearbeiten, jedoch ist das alles witzlos wenn man sieht was die UDM aus dem ganzen „zaubert“.
Inklusive Host Analyse und jeder Menge grafischer Aufarbeitungen und zusatzinfos zb. Dann auch an welchem Port am Switch das System angeschlossen ist.

daher macht es über die UDM dann schon mehr Spaß

 

[Raijin]

Statische Einträge muss man pflegen und wenn man das nicht tut bzw daran denkt, sind neue Geräte stets nur mit IP erreichbar. Klar, kann jeder machen wie er will, du schreibst ja zB dass du sowieso nur die IP nimmst. Da conditional forwarding genau eine einzelne Einstellung ist, die mit einem Schlag alle aktuellen und zukünftigen Namen im lokalen Netz abdeckt, weiß ich allerdings nicht was das Problem sein sollte.

Auch halte ich es für fragwürdig, korrekte lokale Namensauflösung per Definition als weniger wichtig abzutun. Namen sind von jeher eine Komfortfunktion, um sich keine IP merken zu müssen, und das gilt sowohl für öffentliche Namen aka Domains wie für lokale. Ein Handgriff und man hat beides, so what?

 

[-THOR-]

@Raijin
Wie ich schon geschrieben habe macht dein Punkt ja in großen Netzen sinn.
Wir reden hier aber von einem Heim Netz mit maximal 10 statischen Einträgen, ich sehe nicht wo da ein hoher Pflegeaufwand ist.

Außerdem vergisst du einen extrem wichtigen Punkt.
Port Freigaben und Firewallrules sind immer IP und Port basiert, für den Host dahinter will man also immer eine fixe IP haben da sonst deine Komfortfunktion sehr große Sicherheitsprobleme mit sich bringt , oder der Host gar nicht erreichbar ist sollte er eine andere IP bekommen haben.
Also muss man für diese Hosts logischerweise eine fixe Ip konfigurieren und an dem Punkt ist dann auch Ende für dein conditional forwarding.
Das bringt dir dann auch nichts mehr, da der DHCP den Host ja gar nicht kennt. Man muss also zwangsweise einen statischen Host Eintrag nun im DNS haben.

Und gerade er als Besitzer der UDM wird sie sicher nicht gekauft haben um sie als einfachen Router zu verwenden, gerade die Firewall Optionen und die Intrusion Detection/Prevention machen sie aus und sind der USP.

Also vergiss doch einfach bitte dein conditional forwarding was hier am Ende jede Menge neuer Probleme verursachen kann, nämlich gerade dann wenn der TE die UDM PRO dafür verwendet wofür sie da ist.

 

[Raijin]

Wir reden hier aber von einem Heim Netz mit maximal 10 statischen Einträgen, ich sehe nicht wo da ein hoher Pflegeaufwand ist.

Und? Sobald ein neues Gerät, das man im Netzwerk ansprechen will, müsste man händisch einen neuen statischen Eintrag generieren, jedes Mal. Das kann man bereits als hohen Pflegeaufwand bezeichnen. Es ist doch vollkommen unerheblich ob man eine Komfortfunktion in einem Netzwerk mit 2000 Clients einsetzt oder daheim mit 10 Geräten, wenn man absolut nichts dafür tun muss als die DNS-Sequenz so zu gestalten, dass der DHCP mit von der Partie ist. Und nein, das hat nichts mit Performanceproblemen zu tun, weil das bei lokalen Namen vollkommen unerheblich ist.

Port Freigaben und Firewallrules sind immer IP und Port basiert, für den Host dahinter will man also immer eine fixe IP haben da sonst deine Komfortfunktion sehr große Sicherheitsprobleme mit sich bringt

Die Firewall hat jetzt was genau damit zu tun? Was ist das für ein Argument, dass nicht alles mit Namen geht? Weil zum Beispiel Firewall und NAT mit IPs arbeitet, kann man Namen komplett vergessen oder wie?

Also muss man für diese Hosts logischerweise eine fixe Ip konfigurieren und an dem Punkt ist dann auch Ende für dein conditional forwarding.

What? Schon mal von statischen Reservierungen im DHCP-Server gehört? Schwupps ist die IP "fix" UND der Name kann verwendet werden.


Es gibt einfach kein sinnvolles Argument gegen die Namensauflösung, insbesondere nicht, weil sie keinen Mehraufwand bedeutet. Wenn man am Ende trotzdem nur IP-Adressen verwendet, ist das doch kein Problem, weil nix verloren geht. Bei mir funktioniert die Namensauflösung wunderbar und trotzdem gebe ich häufig die IP-Adresse ein, weil ich berufsbedingt einfach extrem viel mit IPs zu tun habe und mir sowieso fast alle gemerkt habe.


Da ich aber nicht gerne gegen Wände rede, bin ich raus.

 

[TWIN013]

Also um die Ausgangssituation mal etwas klarer zu beschreiben: es gibt in meinem Netz gerade mal eine Hand voller Geräte, die eine fixe IP haben. Das sind UDMP und alles was so dran hängt (Switch, WLAN APs), das QNAP NAS und mein eigener PC. Davon sind bis auf den PC alle IPs zugewiesen, d.h. nicht im Gerät hinterlegt, sondern sie werden vom DHCP fix vergeben. Lediglich der PC hat seine IP eingetragen.
Das Problem mit interner Namensauflösung stellt sich mir also eigentlich gar nicht, ich muss aber auch gestehen, dass ich das nie (wissentlich) genutzt habe. Meine QNAP erreiche ich intern z.B. auch unter https://qnapnas - ich nehme an, dass es sich um solche Dinge handelt. Dazu kann ich nur sagen: scheint zu funktionieren.

 

[-THOR-]

Oha, sehr emotionale Reaktion . Hab ich da einen Nerv getroffen ?

Die Firewall hat jetzt was genau damit zu tun? Was ist das für ein Argument, dass nicht alles mit Namen geht? Weil zum Beispiel Firewall und NAT mit IPs arbeitet, kann man Namen komplett vergessen oder wie?

Die Firewall hat jetzt genau so viel damit zu tun, das man ein solches Gerät kauft wenn man vor hat Web Server mit freigaben, VPNS usw zu betreiben und du gerade dabei bist einen Sicherheitstechnischen GAU zu empfehlen indem er alles auf DHCP und Namensauflösung umstellt.

Es liegt nahe das der Thread Ersteller das vor hat, wenn er sich eine UDM Pro kauft. Wir reden hier nicht über eine Fritzbox oder Linksys Router. Kennst du das Gerät überhaupt ?

What? Schon mal von statischen Reservierungen im DHCP-Server gehört? Schwupps ist die IP "fix" UND der Name kann verwendet werden.

Danke, darauf habe ich gewartet ! Ich wusste das du damit um die Ecke kommst. Natürlich kenne ich die und bestens.
Weißt du wie viele Fälle ich auf der Arbeit schon hatte in denen aus unerklärlichen Gründen (fehlgeschlagenes Failover usw) die Reservierung plötzlich nicht mehr aktiv war und plötzlich Geräte doch wieder andere IP's bekommen haben ?

Im Normalfall ist das relativ egal, nur kommen wir hier wieder in den Fall falls dummerweise eins der Devices über eine Firewall Regel aus dem Internet erreichbar ist. Und zufällig bekommt zB. sein Nas diese Adresse und schon ist es der Super GAU. Das NAS ist offen am Internet.

Das ist wirklich eine sehr tolle Idee die du hast .

Es gibt einfach kein sinnvolles Argument gegen die Namensauflösung, insbesondere nicht, weil sie keinen Mehraufwand bedeutet.

Vielleicht magst du dich ja noch ein wenig mit IT Security beschäftigen ?

Da ich aber nicht gerne gegen Wände rede, bin ich raus.

Ja ist vielleicht besser. Schließlich kann DHCP in Verbindung mit Firewall Freigaben (die du hier ja komplett ausblenden willst) wirklich schlimme Folgen haben.


Also an den TE: Falls du also Freigaben in deiner Firewall auf Geräte hast, sei bitte vorsichtig mit DHCP. Der manuelle Weg ist da deutlich sicherer. Daher ist meine DMZ auch komplett von Hand konfiguriert.