Pi-hole blockéiert keng Annoncen nodeems d'VPN verbonne gouf: fënnef Kontrollen

Annoncë erschéngen nach op engem Client, Pi-hole mellt sech gesond, an den Tunnel ass aktiv, dofir ass den Instinkt de Verkéier vun deem Client duerch de Pi ze leeden. Dat ass déi falsch Kéier. D'Filtréierung brauch d'Froen, net d'Paketen, an e Client, deem seng Ufroe bei de Resolver vum Ubidder ginn, bleift onfilteréiert, egal wou säi Verkéier fléisst. Gitt dës Lëscht an der Rei duerch a stoppt beim éischte Schrëtt, dee feelt, well e méi spéit Schrëtt Iech näischt ka soen, wärend e fréiere kaputt ass.

1. Liest de Resolver, deen de Client tatsächlech benotzt

Frot de Client, net de Router. Op Linux dréckt resolvectl status d'DNS-Server pro Verbindung an dee wéi eng Verbindung gewënnt; /etc/resolv.conf eleng ass meeschtens e Stub, deen op 127.0.0.53 weist. Op Windows listet ipconfig /all d'Server, déi vum DHCP pro Adapter geliwwert ginn, an op macOS weist scutil --dns dat selwecht pro Beräich. Wann d'Äntwert net d'Adress vum Pi-hole ass, hutt Dir e Zouverlässigungsproblem a Schrëtt 2 ass dee Punkt, wou et läit.

Zwou Saache besiegen de Systemresolver, och wann en richteg agestellt ass. Browseren mat hirem eegene sécheren DNS (d'Optioun “Use secure DNS” vum Chrome, network.trr.mode vum Firefox) schécken Ufroe iwwer HTTPS un e ëffentleche Resolver a maachen ni de Port 53 op. An e VPN-Client um Client selwer kann en DNS-Server op sengem Tunnelinterface installéieren mat engem Routing-Domän ~., wat déi Verbindung fir all Numm autoritär mécht.

Testt de Wee, deen d'Applikatiounen huelen, net de Wee, deen en Debuginstrument hëlt. resolvectl query example.com weist, wéi eng Verbindung geäntwert huet, an getent hosts example.com geet duerch dee selwechten NSS-Wee wéi eng Applikatioun; op macOS liest dscacheutil -q host -a name example.com d'Beräichsresolver, déi scutil --dns listet. En nackte dig mécht dat net: en liest /etc/resolv.conf an iwwerspréngt d'Auswiel pro Verbindung, dofir kann en aus Pi-hole äntweren, während all Applikatioun den gedréckten Resolver benotzt, an dat ass genee dee Feeler, fir deen dës Lëscht existéiert. Halt dig @192.168.1.53 fir een bestëmmte Server ze testen.

2. Bestätegt, wien d'Äntwert verdeelt

D'Zouverlässigung kënnt vun deem, wat op DHCP äntwert. Op dnsmasq ass dat eng eenzeg Zeil, dhcp-option=6,192.168.1.53; an der Webschnittstell vun engem Router ass et d'DNS-Feld am LAN-DHCP-Abschnitt. D'Cliente mussen erneieren, ier se et gesinn. En Apparat, deen zënter Deeg leeft, hält nach dee alten Lease, an en Apparat mat engem handgetippte Resolver hält en fir ëmmer. Erneiert op engem Testclient amplaz d'Verbreedung unzehuelen.

IPv6 ass déi Halschent, déi vergiess gëtt. Routerannonce kënnen hiren eegenen DNS-Server droen (RDNSS), an op OpenWrt ass dat d'Optioun ra_dns vum odhcpd; e Client, deen IPv6 virzitt, benotzt dee Server, während d'DHCPv4-Optioun, déi Dir just agestellt hutt, onbenotzt bleift. Wann Dir net prett sidd, IPv6-DNS ze servéieren, läscht just d'DNS-Annonce: ra_dns am odhcpd, oder d'RDNSS-Optioun an deem, wat op Routerannonce äntwert. D'Annonce ganz ausschalte läscht och d'IPv6-Adresséierung aus dem LAN, wat eng vill méi grouss Ännerung ass wéi déi, déi Dir gemengt hutt, wärend d'Läschen just vun der DNS-Optioun d'Adresséierung intakt hält an den feelenden RDNSS an enger Paketopnam sichtbar mécht.

3. Beweist, datt d'Ufro Pi-hole erreecht

Eng Ufro vum Pi beweist näischt iwwer de Netzwierkwee. Fëllt se vum Client aus a liest de Code vun der Äntwert:

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

En Timeout weist op d'Filtréierung oder op eng Route; REFUSED weist op eng Zougriffsregel; SERVFAIL weist op den ieweschte Resolver hannert Pi-hole; eng korrekt Äntwert, déi ni am Ufroelog opdaucht, bedeit, datt de Client eppes anescht gefrot huet. Kontrolléiert UDP an TCP 53, well grouss Äntwerten an e puer Resolveren op TCP zréckfalen, a publizéiert béides, wann Pi-hole an engem Container leeft. Eng Zousordnung, déi nëmmen UDP deckt, produzéiert intermittéierend Feeler, déi wéi Paketverloscht ausgesinn.

Duerno entscheet de Lauschmodus vum Pi-hole, ob en iwwerhaapt äntwert. Am Modus nëmme lokal ignoréiert dnsmasq Ufroe vun de Quellen, déi net op engem direkt ugeschlossenen Subnet sinn, an genau sou gesäit en Client hannert engem anere Router oder deen duerch en Tunnel kënnt aus: de Client leeft an den Timeout an d'Ufro erreecht ni de Log. Eng Ufro, déi awer als REFUSED opdaucht, gouf vun enger Zougriffslëscht oder enger Firewallregel ofgeleent. All Hierkonft z'erlaben ass déi üblech Korrektur, gepaart mat enger Firewallregel, déi de Port 53 op Är eege Subnetze begrenzt.

4. Kontrolléiert, ob den Tunnel d'Äntwert ersat oder verschluecht huet

Dat ass de Fall, an deem sech béid Symptomer verstoppen. Wann de Router selwer e VPN-Client ass, kann eng gedréckten DNS-Optioun d'LAN-Astellung iwwerschreiwen, am Moment wou den Tunnel eropkënnt: OpenVPN-Servere drécke dhcp-option DNS, a WireGuard-Profiler droen hiren eegene DNS-Entrag. Liest den effektive Resolver vum Router mam Tunnel erop, net virdrun, an ignoréiert wat d'LAN-Säit behaapt.

Den anere Feeler ass d'Erreechbarkeet, net d'Ersetzung. Wann déi erlaabt Präfixer vum Tunnel Ären LAN-Subnet enthalen, huet de Router eng Route, déi d'Ufroe fir 192.168.1.53 an den Tunnel schéckt, an déi aner Säit huet keng Route zréck: d'Ufroe lafen an den Timeout, obwuel den Tunnel gesond ass. Dat Ëmgedréint geschitt, wann Pi-hole op engem Subnet sëtzt, deen den Tunnel net dréit. Vergläicht d'Adress mat deenen erlaabten Präfixer vum Tunnel an der Routentabelle vum Router, ier Dir den DNS erëm ufässt.

Wielt eng Korrektur, net béid. Entweder haalt den Tunnel vum DNS fort — mat pull-filter ignore “dhcp-option DNS” op OpenVPN an ouni LAN-Präfix an AllowedIPs op WireGuard —, oder akzeptéiert den gedréckten Resolver a gitt déi lokal Filtréierung fir d'Cliente hannert deem Router op. Wat Dir och wielt, schreift et nieft de Profil, well déi nächst Persoun, déi en editéiert, soss d'Entscheedung zoufälleg ëmdréit.

5. Widderhëlt den Test no enger Neiverbindung

Frot vun engem Client, bestätegt, datt dee Client am Log vum Pi-hole opdaucht, léist dann eng Domän op, déi sollt blockéiert ginn, a kontrolléiert, datt Dir d'Blockäntwert statt déi richteg kritt. Verbënnt den Tunnel erëm a fëllt déiselwecht zwou Ufroe aus, well eng Resolverastellung, déi nëmme bis zur nächster Verbindung hält, ass dat üblech Resultat vun enger Korrektur, déi op der falscher Schicht ugewannt gouf.

Loosst en zweeten Resolverwee leien, deen net vum Tunnel ofhänkt, sou datt e Pi-hole-Ausfall op onfilteréiert Surfen degradéiert amplaz guer net Surfen. Halt déi fréier DHCP- an Resolverwäerter, bis den Test zweemol geläscht; eng Ännerung, déi dem Stot säin Internet beim Iessen ënnerbricht, ass vill méi schwéier ze debuggen wéi eng, déi Dir an enger Minutt zréckdréie kënnt.