Pi-hole blockiert nach dem VPN-Verbindungsaufbau keine Werbung: fünf Prüfungen

Anzeigen erscheinen weiterhin auf einem Client, Pi-hole meldet sich als gesund, und der Tunnel steht, also ist der Instinkt, den Verkehr dieses Clients über den Pi zu leiten. Das ist die falsche Abzweigung. Filterung braucht die Fragen, nicht die Pakete, und ein Client, dessen Anfragen an den Resolver des Providers gehen, bleibt ungefiltert, egal wohin sein Verkehr fließt. Gehen Sie diese Liste der Reihe nach durch und stoppen Sie beim ersten Schritt, der fehlschlägt, denn ein späterer Schritt kann Ihnen nichts sagen, solange ein früherer kaputt ist.

1. Lesen Sie den Resolver, den der Client tatsächlich verwendet

Fragen Sie den Client, nicht den Router. Unter Linux druckt resolvectl status die DNS-Server pro Link und welcher Link gewinnt; /etc/resolv.conf allein ist meist ein Stub, der auf 127.0.0.53 zeigt. Unter Windows listet ipconfig /all die vom DHCP bereitgestellten Server pro Adapter auf, und unter macOS zeigt scutil --dns dasselbe pro Bereich. Ist die Antwort nicht die Adresse von Pi-hole, haben Sie ein Zuweisungsproblem, und Schritt 2 ist der Ort, an dem es sitzt.

Zwei Dinge besiegen den Systemresolver, selbst wenn er korrekt eingestellt ist. Browser mit eigenem sicheren DNS (Chroms “Use secure DNS”, Firefox' network.trr.mode) senden Anfragen über HTTPS an einen öffentlichen Resolver und öffnen nie Port 53. Und ein VPN-Client auf dem Client selbst kann einen DNS-Server auf seiner Tunnelschnittstelle mit einer Routing-Domain von ~. installieren, was diesen Link für jeden Namen autoritativ macht.

Testen Sie den Weg, den Anwendungen nehmen, nicht den Weg, den ein Debug-Werkzeug nimmt. resolvectl query example.com zeigt, welcher Link geantwortet hat, und getent hosts example.com geht durch denselben NSS-Pfad wie eine Anwendung; unter macOS liest dscacheutil -q host -a name example.com die bereichsbezogenen Resolver, die scutil --dns auflistet. Ein blankes dig tut das nicht: Es liest /etc/resolv.conf und überspringt die Auswahl pro Link, kann also von Pi-hole antworten, während jede Anwendung den gepushten Resolver nutzt, und genau das ist der Fehler, für den diese Liste existiert. Behalten Sie dig @192.168.1.53 zum Testen eines bestimmten Servers.

2. Bestätigen Sie, wer die Antwort verteilt

Die Zuweisung kommt von dem, was auf DHCP antwortet. Bei dnsmasq ist das eine Zeile, dhcp-option=6,192.168.1.53; in der Weboberfläche eines Routers ist es das DNS-Feld im LAN-DHCP-Abschnitt. Clients müssen erneuern, bevor sie es sehen. Ein Gerät, das seit Tagen läuft, hält noch den alten Lease, und ein Gerät mit einem manuell eingetippten Resolver hält ihn für immer. Erneuern Sie auf einem Testclient, statt die Verbreitung anzunehmen.

IPv6 ist die Hälfte, die vergessen wird. Router-Ankündigungen können ihren eigenen DNS-Server mitbringen (RDNSS), und unter OpenWrt ist das die Option ra_dns von odhcpd; ein Client, der IPv6 bevorzugt, nutzt diesen Server, während die gerade gesetzte DHCPv4-Option ungenutzt bleibt. Wenn Sie IPv6-DNS noch nicht bereitstellen können, löschen Sie nur die DNS-Ankündigung: ra_dns in odhcpd oder die RDNSS-Option in dem, was Router-Ankündigungen beantwortet. Das Abschalten der ganzen Ankündigung entfernt auch die IPv6-Adressierung aus dem LAN, was eine viel größere Änderung ist als die beabsichtigte, während das Löschen nur der DNS-Option die Adressierung intakt lässt und den fehlenden RDNSS in einem Paketmitschnitt sichtbar macht.

3. Beweisen Sie, dass die Anfrage Pi-hole erreicht

Eine Anfrage vom Pi beweist nichts über den Netzwerkpfad. Führen Sie sie vom Client aus und lesen Sie den Antwortcode:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Eine Zeitüberschreitung deutet auf Filterung oder auf eine Route hin; REFUSED deutet auf eine Zugriffsregel hin; SERVFAIL deutet auf den vorgelagerten Resolver hinter Pi-hole hin; eine korrekte Antwort, die nie im Anfragenprotokoll auftaucht, bedeutet, dass der Client etwas anderes gefragt hat. Prüfen Sie UDP und TCP 53, weil große Antworten und manche Resolver auf TCP zurückfallen, und veröffentlichen Sie beides, wenn Pi-hole in einem Container läuft. Eine Zuordnung, die nur UDP abdeckt, erzeugt zeitweise Fehler, die wie Paketverlust aussehen.

Dann entscheidet der Lauschmodus von Pi-hole, ob sie überhaupt antwortet. Im Nur-lokal-Modus ignoriert dnsmasq Anfragen von Quellen, die nicht an einem direkt angeschlossenen Subnetz liegen, und genau so sieht ein Client hinter einem anderen Router oder einer, der über einen Tunnel kommt, aus: Der Client läuft in eine Zeitüberschreitung, und die Anfrage erreicht nie das Protokoll. Eine Anfrage, die doch als REFUSED auftaucht, wurde stattdessen von einer Zugriffsliste oder einer Firewallregel abgelehnt. Alle Ursprünge zu erlauben ist die übliche Lösung, gepaart mit einer Firewallregel, die Port 53 auf Ihre eigenen Subnetze beschränkt.

4. Prüfen Sie, ob der Tunnel die Antwort ersetzt oder geschluckt hat

Das ist der Fall, in dem sich beide Symptome verstecken. Wenn der Router selbst ein VPN-Client ist, kann eine gepushte DNS-Option die LAN-Einstellung in dem Moment überschreiben, in dem der Tunnel hochkommt: OpenVPN-Server pushen dhcp-option DNS, und WireGuard-Profile bringen ihren eigenen DNS-Eintrag mit. Lesen Sie den effektiven Resolver des Routers bei hochgefahrenem Tunnel, nicht davor, und ignorieren Sie, was die LAN-Seite behauptet.

Der andere Fehler ist Erreichbarkeit statt Ersetzung. Wenn die erlaubten Präfixe des Tunnels Ihr LAN-Subnetz enthalten, hat der Router eine Route, die Anfragen für 192.168.1.53 in den Tunnel schickt, und die Gegenseite hat keine Route zurück: Anfragen laufen in Zeitüberschreitungen, obwohl der Tunnel gesund ist. Das Umgekehrte passiert, wenn Pi-hole in einem Subnetz sitzt, das der Tunnel nicht trägt. Vergleichen Sie die Adresse mit den erlaubten Präfixen des Tunnels und der Routentabelle des Routers, bevor Sie DNS erneut anfassen.

Wählen Sie eine Lösung statt beider. Halten Sie den Tunnel entweder vom DNS fern — mit pull-filter ignore “dhcp-option DNS” unter OpenVPN und ohne LAN-Präfix in AllowedIPs unter WireGuard —, oder akzeptieren Sie den gepushten Resolver und geben Sie die lokale Filterung für Clients hinter diesem Router auf. Was auch immer Sie wählen, schreiben Sie es neben das Profil, weil die nächste Person, die es bearbeitet, die Entscheidung sonst versehentlich umkehrt.

5. Wiederholen Sie den Test nach einer erneuten Verbindung

Fragen Sie von einem Client aus, bestätigen Sie, dass dieser Client im Protokoll von Pi-hole auftaucht, lösen Sie dann eine Domain auf, die blockiert werden sollte, und prüfen Sie, dass Sie die blockierende Antwort statt der echten bekommen. Verbinden Sie den Tunnel neu und führen Sie dieselben zwei Anfragen aus, denn eine Resolver-Einstellung, die nur bis zur nächsten Verbindung hält, ist das übliche Ergebnis einer Korrektur auf der falschen Ebene.

Lassen Sie einen sekundären Resolver-Pfad, der nicht vom Tunnel abhängt, damit ein Pi-hole-Ausfall zu ungefiltertem Surfen statt zu gar keinem Surfen führt. Behalten Sie die bisherigen DHCP- und Resolver-Werte, bis der Test zweimal besteht; eine Änderung, die das Internet des Haushalts beim Abendessen bricht, ist viel schwerer zu debuggen als eine, die Sie in einer Minute zurücknehmen können.