Pihole bindet nicht alle Adressen

Master · September 24, 2019, 11:35pm

Hallo, ich habe gerade mein drittes pihole aufgesetzt, funktioniert über v4 auch prima. Mit IPv6 allerdings habe ich noch so meine Probleme:
Ich habe die Adresse fd12:3456:789a:bcde:f0d1:****:fe0d:**** in der SetupVars.conf hinterlegt. Diese ist auch dem System zugewiesen. Über diese Adresse kann ich allerdings keinen DNS-Server erreichen und netstat -tulpen sagt mir:

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      999        22231      1050/pihole-FTL
tcp        0      0 10.10.100.53:53         0.0.0.0:*               LISTEN      999        22229      1050/pihole-FTL
tcp6       0      0 ::1:53                  :::*                    LISTEN      999        22235      1050/pihole-FTL
tcp6       0      0 fe80::f0d1:****:fe0d:53 :::*                    LISTEN      999        22233      1050/pihole-FTL
udp        0      0 127.0.0.1:53            0.0.0.0:*                           999        22230      1050/pihole-FTL
udp        0      0 10.10.100.53:53         0.0.0.0:*                           999        22228      1050/pihole-FTL
udp6       0      0 ::1:53                  :::*                                999        22234      1050/pihole-FTL
udp6       0      0 fe80::f0d1:****:fe0d:53 :::*                                999        22232      1050/pihole-FTL

So wie ich das sehe ist nur die Link Local Unicast (fe80), sowie der Loopback (::1) gebunden, nicht aber alle interfaces (::). Das widerspricht allerdings der Ausgabe aus pihole -d... pihole%20-d
... nach der die grüne (die oben zuerst genannte) Adresse auch gebunden sein sollte.

Wie bekomme ich Pi-hole auf humane Weise dazu die ULA auch zu binden?

Master · September 24, 2019, 11:50pm

Also als Workarround hilft wohl pihole restartdns. Allerdings nur bis zum nächsten Neustart, dann ist das Problem wieder da. Ich scheine die ULA und meine IPv6-Adressen erst nach ein paar Minuten zu bekommen. Kann ich den Server möglicherweise anweisen sich auf allen Interfaces zu binden (::), der ist ja schon vorher hochgefahren...

Edit: Ich habe den Befehl jetzt mal in cron eingetragen, wird jede Stunde ausgeführt. Den Titel des Threads habe ich umbenannt, da meiner Meinung nach hier ein generelles Problem beim Binden vorliegt. Vielleicht ist es aber auch gewollt, dass :: und 0.0.0.0 nicht gebunden werden, kann @DL6ER da nochmal eine Auskunft geben?

mibere · September 25, 2019, 7:16am

Hilft es im Pi-hole Webinterface -> Settings -> DNS -> "Listen on all interfaces, permit all origins" zu aktivieren?

Bucking_Horn · September 25, 2019, 12:05pm

Mit netstat -tulpen listest Du Statistiken für alle derzeit mit den Protokollen TCP und UDP aktiven Ports nebst daran gebundenen Prozessen auf - Interfaces werden hier gar nicht berücksichtigt.
Für die von Dir behauptete Fehlersituation erlaubt dieses Kommando keine relevanten Rückschlüsse,.

Eine Auflistung von allen zu einem Interface gehörenden IP-Adressen gibt es mit ifconfig oder netstat -ie, und deren Ausgabe ist laut Deinem pihole -d auch unauffällig (ok).

Das ist bereits der Fall.

Was allerdings an Deiner netstat-Ausgabe auffällt:
Bei den Ports fehlen 80 und 4711, die normalerweise von lighttpd bzw. pihole-FTL verwendet werden - könnte ein Hinweis darauf sein, dass Deine Pi-hole-Installation noch Fehler aufweist.

Spricht aus meiner Sicht für einen Fehler in der Konfiguration von lighttpd, da pihole-FTL ja bereits lauscht.

Da solte ein Moderator mal einen Blick in ein von Dir hochgeladenes Debug-Log werfen.

Master · September 25, 2019, 6:58pm

Nein mir wird auch angezeigt an welche IP-Adressen gebunden ist. (fe80::f0d1:****:fe0d:53 < hier wird nur die Adresse fe80::f0d1:****:fe0d gebunden und eben nicht an später vergebene Adressen wie die ULA beginnend mit "fd12")

Ich könnte ja auch keinen Webserver installiert haben Tatsächlich habe ich aber nicht mein ganzes iptables gepostet sondern nur $ netstat -tulpen | grep :53, wodurch mir nur Zeilen ausgegeben werden, in denen der DNS-Port 53 vorkommt. Mit lighttpd hat das nix zu tun, das Problem ist nur der DNS-Server.

Habe ich jetzt mal gemacht, nach dem reboot ist es aber wieder nur an Link local und Loopback gebunden und nicht an ::. Wie gesagt, zu dem Zeitpunkt habe ich in ifconfig auch noch nicht die ULA und die GUA, nur die Link local. Sobald ich die ULA habe und danach FTL neustarte wird diese auch gebunden.

Bucking_Horn · September 26, 2019, 1:38pm

Das ist eine IP-Adresse - Interfaces sind z.B. eth0 oder wlan0. Aber inzwischen habe ich verstanden, wo unser Verständis da auseinanderläuft, glaube ich:

Die Überschrift "bindet nicht alle interfaces" ist doppelt mehrdeutig und führt uns daher in diese Meinungsverschiedenheit, die höchstwahrscheinlich keine ist.

Ich lese "Pihole bindet (nicht alle) interfaces", Du meinst aber "Pihole bindet nicht: (alle interfaces)", wobei Du mit (alle interfaces) tatsächlich die Wildcard-IPs (::/128 und 0.0.0.0/32, also alle IP-Adressen der Maschine) meinst.

Meine Aussage, dass netstat keine relevanten Rückschlüsse erlaubt, bezieht sich dementsprechend darauf, dass sich daraus nicht unmittelbar ableiten lässt, welche Interfaces an dnsmasq gebunden werden, und dementsprechend auch nicht, welche nicht gebunden wurden.

Deine eigentlich gemeinte Aussage - Pihole lauscht nicht auf der Wildcard IP - lässt sich hingegen sehr wohl mit netstat belegen.

Zurück zum echten Problem.

Pi-hole bindet standardmässig überhaupt nicht auf einzelne IP-Adressen, sondern auf Interfaces.
Pi-hole bindet dabei genau die Interfaces, die Du dafür konfigurierst. Wenn Du eine Pi-hole-Standardinstallation durchgeführt und nichts manuell angepasst hast, wird normalerweise interface=eth0 gesetzt.

Diese Zeile veranlasst Piholes DNS-Server, zwar auf allen IP-Adressen zu lauschen, aber nur die Anfragen über eth0 zu bearbeiten.

Hast Du Deine Pihole-Konfiguration vielleicht manuell erweitert?
Wenn Du in Deiner Konfiguration irgendwo die Zeile
bind-interfaces
oder einen entsprechenden Kommandozeilenparameter eingefügt hast, dann wird der DNS-Server ausschließlich auf den konfigurierten Interfaces lauschen, siehe Man page von dnsmasq:

(relevanter Auszug aus Man Page direkt hier:)

-z, --bind-interfaces
On systems which support it, dnsmasq binds the wildcard address, even when it is listening on only some interfaces. It then discards requests that it shouldn't reply to. This has the advantage of working even when interfaces come and go and change address.
This option forces dnsmasq to really bind only the interfaces it is listening on.
About the only time when this is useful is when running another nameserver (or another instance of dnsmasq) on the same machine. Setting this option also enables multiple instances of dnsmasq which provide DHCP service to run in the same machine.

Das würde zumindest erklären, warum bei Deinem netstat weder :: noch 0.0.0.0 auftauchen.

Fehlt noch eine Erklärung für die fehlende Nutzung der fd12:-ULA-Adresse.
Kannst Du nochmal prüfen, ob Du in Deinem Setup diese Adresse als lokalen IPv6-DNS-Server konfiguriert hast, entweder im Router oder auf den entsprechenden Clients?

Master · September 26, 2019, 5:32pm

Ouh, sorry ich meinte nicht die interfaces sondern die Adressen dees interfaces, da hast du völlig recht, mein Fehler.
Ich habe mein Pihole wie sonst auch installiert (curl -sSL https://install.pi-hole.net | bash)
Danach habe ich nur die setupVars.config so geändert, dass die fd12-Adresse als IPv6-Adresse genutzt wird (IPV6_ADDRESS=), ansonsten habe ich nichts angerührt. (Diese ULA liegt übrigens auf dem selben interface )

Warum die ULA nicht genutzt wird:
Ich nutze ein Unifi USG als Router und habe nicht die leiseste Ahnung, aber ich bekomme die ULA und die GUA erst nach ca. 5 Minuten nach dem Neustart des Servers. Das ist aber bei vielen anderen Geräten auch so.

Warum pihole nicht an 0.0.0.0 bzw. :: bindet ist auch mir völlig unklar, ich erhoffe mir ja gerade hier eben eine Lösung, wie ich pihole dazu bringe auf den Adressen zu lauschen. Meine pihole-FTL.conf hat nur den Inhalt "PRIVACYLEVEL=0" (Loglevel der Anfragen).

Jedenfalls startet FTL bevor ich eine ULA habe, sodass diese nicht gebunden wird. (Was ich jetzt halt durch meinen cronjob (restart FTL jede Stunde, denn da habe ich ja dann eine ULA) zumindest gelindert habe).

Bucking_Horn · September 26, 2019, 8:21pm

Die Konfiguration für den Pi-hole-DNS/DHCP-Server (eine Variante von dnsmasq) steht im Verzeichnis
/etc/dnsmasq.d/
Bei einer Standard-Installation befindet sich dort zumindest die Datei
/etc/dnsmasq.d/01-pihole.conf

In dieser Datei trägt Pi-hole -bei entsprechender Einrichtung- auch die Zeile interface=... ein, und wenn in irgendeiner der Dateien unter /etc/dnsmasq.d/ das erwähnte bind-interfaces auftauchte, würde auch nur genau dies Interface vom DNS-Server gebunden.

Ich kann aber Deine Konfiguration von hier aus ohne weitere Infos nicht genauer beurteilen und möchte deshalb nochmals vorschlagen:

Im Debug-Log kann ein Mod wie @mibere viel schneller sehen, ob bei Dir offensichtlich was schief hängt (z.B. ob das in Deinem Screenshot oben genannte Interface ensl8 konsistent in Pi-holes Konfigurationsdateien auftaucht)

Master · September 26, 2019, 8:36pm

Meine 01-pihole.conf:

[....]
addn-hosts=/etc/pihole/gravity.list
addn-hosts=/etc/pihole/black.list
addn-hosts=/etc/pihole/local.list


localise-queries


no-resolv



cache-size=10000

log-queries
log-facility=/var/log/pihole.log

local-ttl=2

log-async
server=192.168.2.1#53
domain-needed
bogus-priv
interface=ens18

In einer "lxd" steht tatsächlich:

bind-interfaces
except-interface=lxdbr0

Wenn ich nicht drum rum komme hier der Debugtoken: https://tricorder.pi-hole.net/k33nq9m8a9
Zum Zeitpunkt des Tests ist die ULA lt. netstat nicht gebunden gewesen und ich bekam folgendes Output:

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[...]
[✗] Failed to resolve ad.doubleclick.net.35715.9256.302br.net via Pi-hole [...] ULA-Adresse
[...]

Bucking_Horn · September 26, 2019, 10:37pm

Eigentlich wollte ich ja jetzt den Mods die Debug-Log-Analyse überlassen, aber dann las ich:

Machst Du irgendwas mit Linux Containern?
Falls ja, brauchst Du jemanden mit LXD-Erfahrung zur Hilfe.

Falls nein, gehört die Datei /etc/dnsmasq.d/lxd vermutlich nicht da hin, und wir können folgendes probieren:
In diesem Post wird empfohlen, die 'lxd'-Datei zunächst testweise aus dem Weg zu räumen:

The config file /etc/dnsmasq.d/lxd is not a Pi-hole one.
Try move it out of that folder to your home folder (for backup):

sudo mv /etc/dnsmasq.d/lxd ~

Danach den Pihole-DNS-Server neu starten
pihole restartdns
und anschliessend Dein
sudo netstat -tulpn | grep :53
noch einmal ausführen.

Wenn's dann gut aussieht, fehlt nur noch ein Reboot und eine erneute netstat-Prüfung.
Ich drück mal die Daumen

Master · September 26, 2019, 10:50pm

root@pihole:~# netstat -tulpen | grep :53
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      999        44403      9990/pihole-FTL
tcp6       0      0 :::53                   :::*                    LISTEN      999        44405      9990/pihole-FTL
udp        0      0 0.0.0.0:53              0.0.0.0:*                           999        44402      9990/pihole-FTL
udp6       0      0 :::53                   :::*                                999        44404      9990/pihole-FTL

Ich geh ins Bett, hab kein Bock mehr auf Linux!

Jetzt könnte ich mich aufregen, warum "bind-interfaces" ohne parameter, ohne alles dafür sorgt, dass nicht gewildcarded wird.

Ich nutze kein lxd, ich habe Pihole auf einem standard 18.04er Ubuntu Server laufen, welches auf einem Proxmox-Server läuft (nicht als lxc, sondern als "richtige" VM). Das Ubuntu ist ganz normal als .iso runtergeladen und es sind keine weiteren Dienste installiert auf dieser VM. Ich habe nicht die leiseste Ahnung, was diese lxd-Datei da gemacht hat, ich habe nicht mal ein lxdbr0-interface in der VM, ich hab nicht mal einen einzigen eingerichtet. Und ich weiß auch nicht, warum Proxmox, da vielleicht im dnsmasq.d rumgespielt haben könnte. Ich hab nur Ubuntu geladen und Pihole installiert.

Danke dir erstmal, damit sollte das ja jetzt behoben sein