Pi-hole blockerar inte annonser efter att VPN:en anslutit: fem kontroller

Annonser visas fortfarande på en klient, Pi-hole rapporterar sig frisk och tunneln är uppe, så instinkten är att dirigera den klientens trafik genom Pi:n. Det är fel sväng. Filtrering behöver frågorna, inte paketen, och en klient vars frågor går till leverantörens resolver förblir ofiltrerad vart dess trafik än flyter. Gå igenom listan i ordning och stanna vid det första steg som misslyckas, eftersom ett senare steg inte kan säga något medan ett tidigare är trasigt.

1. Läs resolvern som klienten faktiskt använder

Fråga klienten, inte routern. På Linux skriver resolvectl status ut DNS-servrarna per länk och vilken länk som vinner; /etc/resolv.conf ensamt är oftast en stub som pekar på 127.0.0.53. På Windows listar ipconfig /all de DHCP-utdelade servrarna per adapter, och på macOS visar scutil --dns samma sak per omfång. Om svaret inte är Pi-holes adress har du ett tilldelningsproblem och steg 2 är där det bor.

Två saker besegrar systemresolvern även när den är rätt inställd. Webbläsare med egen säker DNS (Chromens “Use secure DNS”, Firefox network.trr.mode) skickar frågor över HTTPS till en offentlig resolver och öppnar aldrig port 53. Och en VPN-klient på klienten själv kan installera en DNS-server på sitt tunnelgränssnitt med en routingdomän på ~., vilket gör den länken auktoritativ för varje namn.

Testa vägen som applikationer tar, inte vägen som ett felsökningsverktyg tar. resolvectl query example.com visar vilken länk som svarade, och getent hosts example.com går genom samma NSS-väg som en applikation; på macOS läser dscacheutil -q host -a name example.com de omfattningsbestämda resolvrarna som scutil --dns listar. En bar dig gör inte detta: den läser /etc/resolv.conf och hoppar över valet per länk, så den kan svara från Pi-hole medan varje applikation använder den pushade resolvern, och det är precis det fel som den här listan finns för att fånga. Behåll dig @192.168.1.53 för att testa en specifik server.

2. Bekräfta vem som delar ut svaret

Tilldelningen kommer från det som svarar på DHCP. På dnsmasq är det en rad, dhcp-option=6,192.168.1.53; i en routers webbgränssnitt är det DNS-fältet i LAN-DHCP-avsnittet. Klienter måste förnya innan de ser det. En enhet som varit igång i dagar håller fortfarande kvar den gamla leasen, och en enhet med en handskriven resolver håller den för evigt. Förnya på en testklient i stället för att anta spridning.

IPv6 är den halva som glöms bort. Routerannonser kan bära sin egen DNS-server (RDNSS), och på OpenWrt är det odhcpds ra_dns-alternativ; en klient som föredrar IPv6 använder den servern medan DHCPv4-alternativet du just ställde in står oanvänt. Om du inte är redo att betjäna IPv6-DNS, rensa bara DNS-annonsen: ra_dns i odhcpd, eller RDNSS-alternativet i det som svarar på routerannonser. Att stänga av hela annonsen tar också bort IPv6-adressering från LAN:et, vilket är en mycket större ändring än den du menade, medan att bara rensa DNS-alternativet håller adresseringen intakt och gör den saknade RDNSS:en synlig i en paketinsamling.

3. Bevisa att frågan når Pi-hole

En fråga från Pi:n bevisar ingenting om nätverksvägen. Kör den från klienten och läs svarskoden:

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

En timeout pekar på filtrering eller på en rutt; REFUSED pekar på en åtkomstrregel; SERVFAIL pekar på den överordnade resolvern bakom Pi-hole; ett korrekt svar som aldrig dyker upp i frågeloggen betyder att klienten frågade något annat. Kontrollera UDP och TCP 53, eftersom stora svar och vissa resolvrar faller tillbaka på TCP, och publicera båda när Pi-hole körs i en container. En mappning som bara täcker UDP ger periodiska fel som ser ut som paketförlust.

Därefter avgör Pi-holes lyssnarläge om den över huvud taget svarar. I läget endast lokalt ignorerar dnsmasq frågor från källor som inte ligger på ett direkt anslutet subnät, och exakt så ser en klient bakom en annan router eller en som kommer genom en tunnel ut: klienten får timeout och frågan når aldrig loggen. En fråga som ändå dyker upp som REFUSED avvisades av en åtkomstlista eller en brandväggsregel. Att tillåta alla ursprung är den vanliga rättelsen, tillsammans med en brandväggsregel som begränsar port 53 till dina egna subnät.

4. Kontrollera om tunneln ersatte eller slukade svaret

Det här är fallet där båda symptomen gömmer sig. När routern själv är en VPN-klient, kan ett pushat DNS-alternativ skriva över LAN-inställningen i samma ögonblick som tunneln kommer upp: OpenVPN-servrar pushar dhcp-option DNS, och WireGuard-profiler bär sin egen DNS-post. Läs routerns effektiva resolver med tunneln uppe, inte före, och ignorera vad LAN-sidan påstår.

Det andra felet är nåbarhet snarare än ersättning. Om tunnelns tillåtna prefix omfattar ditt LAN-subnät har routern en rutt som skickar frågor för 192.168.1.53 in i tunneln, och andra sidan har ingen rutt tillbaka: frågorna får timeout trots att tunneln är frisk. Det omvända händer när Pi-hole sitter på ett subnät som tunneln inte bär. Jämför adressen med tunnelns tillåtna prefix och routerns routingtabell innan du rör DNS igen.

Välj en rättelse, inte båda. Antingen håller du tunneln borta från DNS — med pull-filter ignore “dhcp-option DNS” på OpenVPN och utan LAN-prefix i AllowedIPs på WireGuard —, eller så accepterar du den pushade resolvern och ger upp lokal filtrering för klienter bakom den routern. Vad du än väljer, skriv det bredvid profilen, för nästa person som redigerar den kommer annars att vända beslutet av misstag.

5. Upprepa testet efter en återanslutning

Fråga från en klient, bekräfta att den klienten dyker upp i Pi-holes logg, lös sedan upp en domän som borde blockeras och kontrollera att du får blockeringssvaret i stället för det riktiga. Anslut tunneln igen och kör samma två frågor, för en resolverinställning som bara håller till nästa anslutning är det vanliga resultatet av en rättelse som tillämpats på fel lager.

Lämna en sekundär resolverväg som inte beror på tunneln, så att ett Pi-hole-avbrott degraderar till ofiltrerat surfande i stället för inget surfande alls. Behåll de tidigare DHCP- och resolvervärdena tills testet går igenom två gånger; en ändring som bryter hushållets internet vid middagen är mycket svårare att felsöka än en du kan rulla tillbaka på en minut.