pi-hole in fertiges UniFi Setup integrieren - so korrekt?

[Katao]

Hallo zusammen,

habe heute mal etwas mit pihole rumgespielt - und es läuft auch sehr gut, nur hab ich ein paar Fragen warum und hoffe
die kann mir einer beantworten.
Zuerst mal zum Setup:
USG4p als Router mit der 192.168.1.1
pihole läuft im Docker auf einer Diskstation 916+ auf dem 2ten Interface mit der IP 192.168.1.3
Ich habe 3 Netze
das management LAN des Systems 192.168.1.1/24
Vlan10 mit der 10.1.1.1/24
Vlan20 mit der 10.2.2.1/24
Jedes Netz hat seinen DHCP Server von xx.xx.xx.100 - xx.xx.xx.199

Habe in jedem Netz dann unter den DHCP Settings den DNS von auto auf manuell gesetzt
und dort die IP des piholes (192.168.1.3) eingetragen.
Ist das so korrekt?

Denke mal ja, denn es läuft ja perfekt
bzw. es lief perfekt - denn jetzt hab ich wieder das normale Setup weil einiges nicht läuft wie ich es will.

Zu meinen Fragen und Problemen:
Im pihole log sollte ja immer die IP des Hauptrouters angezeigt werden oder?
Bei mir steht / stand da immer eine Ip aus einem komplett anderen Netz
nämlich 172.17.0.1
Hat das USG eine seperate Notfall IP? Oder wo bitte kommt die her?

Und mein Hauptproblem warum ich das Setup wieder umgestellt hab.
Mein Smarthome läuft nicht mehr - speziell die steuerung meiner TP-Link Kasa Steckdosen per Echo/Alexa.
Die Geräte werden in der Alexa-App immer als nicht erreichbar angezeigt.
Habe zwar einige TP-Link Einträge aus dem Log zur Whitelist hinzu gefügt - aber das hat alles nix gebracht.

Kann mir einer sagen woran das liegt bzw. welche Sachen man da "freigeben" muss damit die Geräte wieder untereinander reden können?
Oder bin ich mal wieder der einzige mit so einem Problem.

 

[Raijin]

Ich würde den DNS jedes Subnetzes einfach beim USG belassen. D.h. alle DNS-Requests werden jeweils an die .1 gerichtet. Beim USG selbst stellst du wiederum den pihole als DNS ein und so übernimmt das USG die Weiterleitung an den pihole - so wie das USG vor dem pihole vermutlich an den Provider-DNS oder zB 8.8.8.8 weitergeleitet hat.

 

[snaxilian]

Läuft der pihole Container mit Netzwerk macvlan? Wenn nicht macht Docker ein NAT und nutzt standardmäßig private 172.x.y.z Netze und würde die Einträge im Log erklären.
Ebenso muss es nicht zwangsweise sein, dass der pihole nur die IP des USGs sieht. Mit/Dank EDNS0 sollte man auch die Client IP sehen können sofern das USG dies kann.

Zum zweiten Problem:

• Befinden sich die Steckdosen und die Wanze im selben VLAN oder in unterschiedlichen VLANs?
• Hast du IPv6 bei dir komplett und aktiv abgeklemmt oder nur nicht konfiguriert?

 

[Katao]

Vielen Dank für eure Antworten!
hm... das mit dem DNS direkt im USG wäre auch meine erste Lösung gewesen, allerdings
habe ich was das angeht nur negative Sachen gelesen - sprich dass das nicht läuft...
Aber testen werde ich das mal.
Heißt also genau:
In der Config der WAN Schnittstelle die ins Internet läuft den Provider DNS
direkt auf das pihole lenken - hab ich richtig verstanden bzw. das hast du gemeint oder?

Und zum Thema macvlan - damit hab ich mich noch nicht befasst... danke für den Input.
Allerdings hab ich da ne andere Idee was den Docker angeht.
Ich würde ja gerne den Container mit der Option "selbes Netz wie Host" betreiben.
Allerdings geht das nicht, da die Diskstation ja den Port 80 auf 5000 weiterleitet um den eigenen
Webserver erreichen zu können.
Wenn ich diesen abändere auf z.b. 83, dann sollte ja pihole mit den entsprechenden Einstellungen
dann normal über port 80 bzw. ohne Portangabe erreichbar sein oder?
Oder gibts da noch irgend eine andere Möglichkeit?

Und zum Thema IPv6 das ist nicht konfiguriert.
Aber wie soll das damit zusammenhängen?

 

[Droxmox]

In der Config der WAN Schnittstelle die ins Internet läuft den Provider DNS
direkt auf das pihole lenken - hab ich richtig verstanden bzw. das hast du gemeint oder?

Der DNS wird in der LAN Schnitstelle eingetragen. Siehe hier Punkt 6
So läuft es zumindest bei mir.

//edit
ok, das hattest Du ja schon gemacht. ist wohl noch zu früh

 

[Harrdy]

Alternativ lässt sich am USG4p natürlich auch ne DNAT für Port 53 mit Ausnahme für die Pihole Instanz einrichten. Dann ist es völlig egal welchen DNS Server ein Client zu erreichen versucht (extern) und landet immer auf der Pihole Instanz (DoH/DoT ausgenommen)

 

[snaxilian]

Und zum Thema macvlan - damit hab ich mich noch nicht befasst... danke für den Input.
Allerdings hab ich da ne andere Idee was den Docker angeht.
Ich würde ja gerne den Container mit der Option "selbes Netz wie Host" betreiben.
Allerdings geht das nicht, da die Diskstation ja den Port 80 auf 5000 weiterleitet um den eigenen
Webserver erreichen zu können.
Wenn ich diesen abändere auf z.b. 83, dann sollte ja pihole mit den entsprechenden Einstellungen
dann normal über port 80 bzw. ohne Portangabe erreichbar sein oder?
Oder gibts da noch irgend eine andere Möglichkeit?

Genau für dein Vorhaben wäre die docker network Option macvlan wie geschaffen. Der Container bekommt dann eine eigene MAC-Adresse und erscheint als eigenständiges Gerät im entsprechenden Subnet und würde vom DHCP-Server eine IP anfordern sofern nicht statisch konfiguriert.
Dein NAS hat dann die IP a.b.c.d am physikalischen Interface eth0 und der Container a.b.c.e am virtuellen Interface eth0.1 und du brauchst auch nicht den Docker-Dienst auf einem zweiten Interface des NAS laufen lassen.
Stand jetzt läuft auf eth0 des NAS das Webinterface und auf eth1 lauscht der Docker-Dienst und bindet per Bridge (inkl. NAT) die Container an.

 

[Raijin]

hm... das mit dem DNS direkt im USG wäre auch meine erste Lösung gewesen, allerdings
habe ich was das angeht nur negative Sachen gelesen - sprich dass das nicht läuft...

Aha. Und wo hast du das gelesen? Das ist in meinen Augen ganz großer Unsinn. Nicht alles was man liest muss stimmen. Nicht selten sind solche Aussagen schlicht und ergreifend auf Konfigurationsfehler durch den Anwender zurückzuführen. Ein USG ist nun mal keine Fritzbox, bei der überhaupt nur ~5% der Einstellungen durch den Anwender verändert werden können. Man kann ein USG auch schlicht und ergreifend falsch konfigurieren und dann geht's natürlich in die Hose. Von konkreten DNS-Problemen höre ich aber das erste Mal.