Warum Pi-hole v6 DNS-Anfragen von WireGuard-Clients ignoriert

Pi-hole v6 empfängt eine DNS-Anfrage auf Port 53 und entscheidet dann, ob das angekommene Paket beantwortet werden darf. Auf einem WireGuard-Host ist diese zweite Entscheidung meist der Grund, warum ein Client in einen Timeout läuft, während der Resolver aus dem LAN gesund aussieht. Der Port ist offen, FTL läuft, und trotzdem kommt von 10.90.0.1 nichts zurück. Drei Dinge wirken zusammen, bevor eine Antwort das System verlässt: dns.interface, dns.listeningMode und die Firewall vor beiden.

Der lauschende Socket entscheidet nicht, wer eine Antwort bekommt

FTL öffnet UDP- und TCP-Listener auf Port 53. In der Standardkonfiguration ist der Socket oft ein Wildcard, sodass ss -lunp | grep :53 0.0.0.0:53 und [::]:53 anzeigt, unabhängig davon, ob VPN-Clients bedient werden. Ein Wildcard-Socket nimmt das Paket an, dann wendet FTL seine Schnittstellen- und Quellregeln an, bevor es antwortet. Deshalb beweist "der Port lauscht" sehr wenig über einen Tunnel-Client.

Lesen Sie die laufende Konfiguration statt der Datei, die Sie für aktiv halten. pihole-FTL --config dns.interface und pihole-FTL --config dns.listeningMode geben die effektiven Werte aus, und sie können von der Host-Datei abweichen, wenn ein Container, eine Umgebungsvariable oder ein Deployment-Manager die Einstellung besitzt. Die Pi-hole-FTL-Konfigurationsreferenz listet die Modi und welcher davon auf die Schnittstelle abstellt.

LOCAL fragt nach dem Subnetz, SINGLE fragt nach der Schnittstelle

LOCAL, der Standard, beantwortet Anfragen, deren Quelladresse zu einem Subnetz gehört, das auf einer der Host-Schnittstellen konfiguriert ist. Ein einfaches wg0 mit 10.90.0.1/24 besteht diesen Test, weil der Client auf 10.90.0.2 innerhalb des Tunnel-Subnetzes liegt. Ein gerouteter Client auf der anderen Seite eines Peers, oder einer, der hinter NAT in einem anderen Präfix verborgen ist, besteht ihn nicht, obwohl das Paket auf wg0 ankam, und im Protokoll erscheint keine Anfrage.

SINGLE ändert die Frage. Es akzeptiert Anfragen, die auf der in dns.interface benannten Schnittstelle ankommen, Loopback eingeschlossen, und ignoriert das Quell-Subnetz. Das ist der Modus, der eine verkettete oder geroutete VPN-Topologie übersteht. Setzen Sie beide Schlüssel zusammen, denn ein Modus ohne benannte Schnittstelle ist keine vollständige Anweisung:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND ändert den Socket, und das hat einen Preis

BIND filtert keinen Wildcard-Socket; es bindet Port 53 nur an Adressen, die auf der benannten Schnittstelle existieren, sodass der Kernel Pakete ablehnt, die anderswo ankommen. Es ist strenger als SINGLE und kein Synonym dafür. Der Preis zeigt sich beim Booten: Wenn wg0 beim Start von FTL nicht oben ist, gibt es möglicherweise keine Adresse zum Binden, und der Resolver kann ohne Listener laufen, bis die Schnittstelle erscheint und FTL neu startet.

Wählen Sie BIND, wenn Sie die Startreihenfolge kontrollieren, etwa eine systemd-Unit, die nach der WireGuard-Schnittstelle geordnet ist, und wenn der Kernel verirrte Pakete verwerfen soll, bevor FTL sie sieht. Wählen Sie SINGLE, wenn der Tunnel kommt und geht oder wenn die Schnittstelle von einem Werkzeug erzeugt wird, das nach FTL startet.

Die Firewall ist das zweite Tor

Ein korrekter FTL-Modus scheitert trotzdem, wenn die Host-Firewall Port 53 auf wg0 verwirft. Lassen Sie den VPN-Quellbereich für beide Protokolle zu und halten Sie die Internetseite geschlossen. In nftables sehen die Regeln mit der vorhandenen input-Kette in der Tabelle inet filter so aus:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Fügen Sie passende IPv6-Regeln hinzu, wenn der Tunnel IPv6 trägt, und setzen Sie sie vor die Drop-Richtlinie der Kette. Nutzt der Host ufw oder firewalld, drücken Sie dieselbe Übereinstimmung in diesem Manager aus, statt Werkzeuge zu mischen. Leiten Sie Port 53 nicht vom Internetrouter weiter; Clients sollten die VPN-Adresse des Resolvers über den Tunnel erreichen.

Zwei Pfade bleiben getrennt. Client-Anfragen enden bei FTL. Die eigenen Upstream-Abfragen von FTL verlassen den Host gemäß der Routing-Tabelle, die den Tunnel nutzen kann oder nicht, sodass ein Resolver, der antwortet, aber nichts Brauchbares zurückgibt, ein Upstream-Problem ist. Die Webverwaltung und die API lauschen auf eigenen Ports und brauchen ihre eigene Einschränkung.

Prüfen Sie die Antwort und die Ablehnung

Fragen Sie von einem VPN-Client die Resolver-Adresse über beide Protokolle ab: dig @10.90.0.1 example.com und dig +tcp @10.90.0.1 example.com. Prüfen Sie dann das Anfrageprotokoll in der Administrationsoberfläche, um zu bestätigen, dass FTL die Anfrage erfasst hat. Ein Client-Timeout ohne Protokolleintrag deutet auf die Firewall oder den Schnittstellenfilter; ein Eintrag ohne Antwort deutet auf die Upstream-Auflösung.

Testen Sie den negativen Pfad von einem Host außerhalb des VPN. dig @10.90.0.1 example.com sollte in einen Timeout laufen, und ss -lunp auf dem Resolver sollte Port 53 nicht an eine öffentliche Adresse gebunden zeigen. Starten Sie den Dienst einmal neu, starten Sie dann den Host neu und bestätigen Sie, dass der Resolver weiterhin antwortet, nachdem wg0 wieder erscheint. Eine Anfrage, die nur bis zum nächsten Neustart funktioniert, ist keine abgeschlossene Änderung.