Pi-hole blokerer ikke annoncer efter VPN-forbindelsen: fem kontroller

Annoncer vises stadig på en klient, Pi-hole melder sig sund, og tunnelen er oppe, så instinktet er at rute den klients trafik gennem Pi'en. Det er den forkerte drejning. Filtrering kræver spørgsmålene, ikke pakkerne, og en klient, hvis forespørgsler går til udbyderens resolver, forbliver ufiltreret, uanset hvor dens trafik løber. Gå listen igennem i rækkefølge, og stop ved det første trin, der fejler, fordi et senere trin ikke kan fortælle dig noget, mens et tidligere er i stykker.

1. Læs den resolver, klienten faktisk bruger

Spørg klienten, ikke routeren. På Linux udskriver resolvectl status DNS-serverne for hvert link og hvilket link der vinder; /etc/resolv.conf alene er normalt en stub, der peger på 127.0.0.53. På Windows viser ipconfig /all de DHCP-tildelte servere for hver adapter, og på macOS viser scutil --dns det samme opdelt efter omfang. Hvis svaret ikke er Pi-holes adresse, har du et tildelingsproblem, og trin 2 er, hvor det bor.

To ting besejrer systemresolveren, selv når den er sat korrekt. Browsere med deres egen sikre DNS (Chroms “Use secure DNS”, Firefox' network.trr.mode) sender forespørgsler over HTTPS til en offentlig resolver og åbner aldrig port 53. Og en VPN-klient på selve klienten kan installere en DNS-server på sin tunnelinterface med et routingdomæne på ~., hvilket gør det link autoritativt for hvert navn.

Test den vej, applikationer tager, ikke den vej et fejlfindingsværktøj tager. resolvectl query example.com viser, hvilket link der svarede, og getent hosts example.com går gennem samme NSS-vej som en applikation; på macOS læser dscacheutil -q host -a name example.com de scoped resolvere, som scutil --dns viser. En bar dig gør ikke dette: den læser /etc/resolv.conf og springer valget for hvert link over, så den kan svare fra Pi-hole, mens hver applikation bruger den skubbede resolver, og det er præcis den fejl, denne liste findes for at fange. Behold dig @192.168.1.53 til at teste én bestemt server.

2. Bekræft, hvem der udleverer svaret

Tildelingen kommer fra det, der svarer på DHCP. På dnsmasq er det én linje, dhcp-option=6,192.168.1.53; i en routers webgrænseflade er det DNS-feltet i LAN-DHCP-afsnittet. Klienter skal forny, før de ser det. En enhed, der har været tændt i dagevis, holder stadig den gamle lease, og en enhed med en håndskrevet resolver holder den for evigt. Forny på en testklient i stedet for at antage udbredelse.

IPv6 er den halvdel, der bliver glemt. Routerannoncer kan bære deres egen DNS-server (RDNSS), og på OpenWrt er det odhcpds ra_dns-indstilling; en klient, der foretrækker IPv6, bruger den server, mens den DHCPv4-indstilling, du netop satte, står ubrugt. Hvis du ikke er klar til at betjene IPv6-DNS, skal du kun rydde DNS-annoncen: ra_dns i odhcpd eller RDNSS-indstillingen i det, der svarer på routerannoncer. At slå hele annoncen fra fjerner også IPv6-adressering fra LAN'et, hvilket er en meget større ændring end den, du havde til hensigt, mens det kun at rydde DNS-indstillingen holder adresseringen intakt og gør den manglende RDNSS synlig i en pakkeoptagelse.

3. Bevis, at forespørgslen når Pi-hole

En forespørgsel fra Pi'en beviser intet om netværksvejen. Kør den fra klienten, og læs svar-koden:

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

En timeout peger på filtrering eller på en rute; REFUSED peger på en adgangsregel; SERVFAIL peger på den opstrøms resolver bag Pi-hole; et korrekt svar, der aldrig dukker op i forespørgselsloggen, betyder, at klienten spurgte om noget andet. Kontroller UDP og TCP 53, fordi store svar og nogle resolvere falder tilbage til TCP, og udgiv begge, når Pi-hole kører i en container. En mapping, der kun dækker UDP, giver periodiske fejl, der ligner pakketab.

Derefter afgør Pi-holes lyttetilstand, om den overhovedet svarer. I local-only-tilstand ignorerer dnsmasq forespørgsler fra kilder, der ikke er på et direkte tilsluttet subnet, og præcis sådan ser en klient bag en anden router eller en, der kommer gennem en tunnel, ud: klienten løber tør for tid, og forespørgslen når aldrig loggen. En forespørgsel, der alligevel dukker op som REFUSED, blev afvist af en adgangsliste eller en firewallregel. At tillade alle oprindelser er den sædvanlige rettelse, parret med en firewallregel, der begrænser port 53 til dine egne subnets.

4. Tjek, om tunnelen erstattede eller slugte svaret

Det er det tilfælde, begge symptomer skjuler. Når routeren selv er VPN-klient, kan en skubbet DNS-indstilling tilsidesætte LAN-indstillingen i det øjeblik, tunnelen kommer op: OpenVPN-servere skubber dhcp-option DNS, og WireGuard-profiler bærer deres egen DNS-post. Læs routerens effektive resolver med tunnelen oppe, ikke før den, og ignorer, hvad LAN-siden påstår.

Den anden fejl er nåbarhed snarere end erstatning. Hvis tunnelens tilladte præfikser omfatter dit LAN-subnet, har routeren en rute, der sender forespørgsler for 192.168.1.53 ind i tunnelen, og den anden side har ingen rute tilbage: forespørgslerne løber tør for tid, selv om tunnelen er sund. Det omvendte sker, når Pi-hole sidder på et subnet, som tunnelen ikke bærer. Sammenlign adressen med tunnelens tilladte præfikser og routerens rutetabel, før du rører DNS igen.

Vælg én rettelse i stedet for begge. Hold enten tunnelen væk fra DNS — med pull-filter ignore “dhcp-option DNS” på OpenVPN og intet LAN-præfiks i AllowedIPs på WireGuard — eller accepter den skubbede resolver og opgiv lokal filtrering for klienter bag den router. Uanset hvad du vælger, så skriv det ved siden af profilen, fordi den næste person, der redigerer den, ellers ved et uheld vil vende beslutningen.

5. Gentag testen efter en genopkobling

Forespørg fra en klient, bekræft, at den klient dukker op i Pi-holes log, og slå derefter et domæne op, der burde blokeres, og kontroller, at du får blokeringssvaret i stedet for det rigtige. Genopkobl tunnelen, og kør de samme to forespørgsler, fordi en resolverindstilling, der kun holder til næste genopkobling, er det sædvanlige resultat af en rettelse anvendt på det forkerte lag.

Efterlad en sekundær resolvervej, der ikke afhænger af tunnelen, så et Pi-hole-nedbrud nedgraderes til ufiltreret browsing i stedet for ingen browsing. Behold de tidligere DHCP- og resolverværdier, indtil testen består to gange; en ændring, der bryder husstandens internet ved middagstid, er meget sværere at fejlfinde end en, du kan rulle tilbage på et minut.