Pi-hole blokkerer ikke annonser etter at VPN-en kobles til: fem kontroller

Annonser vises fortsatt på en klient, Pi-hole melder seg frisk, og tunnelen er oppe, så instinktet er å rute trafikken fra den klienten gjennom Pi-en. Det er den gale svingen. Filtrering trenger spørsmålene, ikke pakkene, og en klient hvis spørringer går til leverandørens resolver forblir ufiltrert uansett hvor trafikken flyter. Gå gjennom denne listen i rekkefølge og stopp ved det første trinnet som feiler, fordi et senere trinn ikke kan fortelle deg noe mens et tidligere er ødelagt.

1. Les resolveren klienten faktisk bruker

Spør klienten, ikke ruteren. På Linux skriver resolvectl status ut DNS-serverne per lenke og hvilken lenke som vinner; /etc/resolv.conf alene er vanligvis en stub som peker på 127.0.0.53. På Windows lister ipconfig /all opp de DHCP-utdelte serverne per adapter, og på macOS viser scutil --dns det samme per omfang. Hvis svaret ikke er Pi-holes adresse, har du et tildelingsproblem, og trinn 2 er der det bor.

To ting beseirer systemresolveren selv når den er riktig satt opp. Nettlesere med egen sikker DNS (Chromes “Use secure DNS”, Firefox' network.trr.mode) sender spørringer over HTTPS til en offentlig resolver og åpner aldri port 53. Og en VPN-klient på selve klienten kan installere en DNS-server på tunnelgrensesnittet med et rutingsdomene på ~., noe som gjør den lenken autoritativ for hvert navn.

Test veien applikasjoner tar, ikke veien et feilsøkingsverktøy tar. resolvectl query example.com viser hvilken lenke som svarte, og getent hosts example.com går gjennom samme NSS-vei som en applikasjon; på macOS leser dscacheutil -q host -a name example.com de omfangsbestemte resolverne som scutil --dns lister opp. En bar dig gjør ikke dette: den leser /etc/resolv.conf og hopper over valget per lenke, så den kan svare fra Pi-hole mens hver applikasjon bruker den dyttede resolveren, og det er nøyaktig feilen denne listen finnes for å fange. Behold dig @192.168.1.53 for å teste én bestemt server.

2. Bekreft hvem som deler ut svaret

Tildelingen kommer fra det som svarer på DHCP. På dnsmasq er det én linje, dhcp-option=6,192.168.1.53; i et ruters webgrensesnitt er det DNS-feltet i LAN-DHCP-delen. Klienter må fornye før de ser det. En enhet som har stått på i dager, holder fortsatt den gamle leien, og en enhet med en håndskrevet resolver holder den for alltid. Forny på en testklient i stedet for å anta spredning.

IPv6 er halvparten som blir glemt. Ruterannonser kan bære sin egen DNS-server (RDNSS), og på OpenWrt er det odhcpds ra_dns-valg; en klient som foretrekker IPv6 bruker den serveren, mens DHCPv4-valget du nettopp satte står ubrukt. Hvis du ikke er klar til å betjene IPv6-DNS, tøm bare DNS-annonsen: ra_dns i odhcpd, eller RDNSS-valget i det som svarer på ruterannonser. Å slå av hele annonsen fjerner også IPv6-adressering fra LAN-et, noe som er en mye større endring enn den du mente å gjøre, mens å tømme bare DNS-valget holder adresseringen intakt og gjør den manglende RDNSS-en synlig i en pakkefangst.

3. Bevis at spørringen når Pi-hole

En spørring fra Pi-en beviser ingenting om nettverksveien. Kjør den fra klienten og les svarkoden:

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

En timeout peker på filtrering eller på en rute; REFUSED peker på en tilgangsregel; SERVFAIL peker på overordnet resolver bak Pi-hole; et riktig svar som aldri dukker opp i spørringsloggen betyr at klienten spurte om noe annet. Sjekk UDP og TCP 53, fordi store svar og noen resolvere faller tilbake til TCP, og publiser begge når Pi-hole kjører i en container. En kartlegging som bare dekker UDP gir periodiske feil som ser ut som pakketap.

Deretter avgjør Pi-holes lyttemodus om den i det hele tatt svarer. I modusen bare lokalt ignorerer dnsmasq spørringer fra kilder som ikke er på et direkte tilkoblet subnett, og akkurat slik ser en klient bak en annen ruter eller en som kommer gjennom en tunnel ut: klienten får timeout og spørringen når aldri loggen. En spørring som likevel dukker opp som REFUSED, ble avvist av en tilgangsliste eller en brannmurregel. Å tillate alle opphav er den vanlige rettelsen, sammen med en brannmurregel som begrenser port 53 til dine egne subnett.

4. Sjekk om tunnelen erstattet eller slukte svaret

Dette er tilfellet der begge symptomene gjemmer seg. Når ruteren selv er VPN-klient, kan et dyttet DNS-valg overstyre LAN-innstillingen i det øyeblikket tunnelen kommer opp: OpenVPN-servere dytter dhcp-option DNS, og WireGuard-profiler har sin egen DNS-oppføring. Les ruterens effektive resolver med tunnelen oppe, ikke før, og ignorer det LAN-siden påstår.

Den andre feilen er tilgjengelighet snarere enn erstatning. Hvis tunnelens tillatte prefikser omfatter LAN-subnettet ditt, har ruteren en rute som sender spørringer for 192.168.1.53 inn i tunnelen, og den andre siden har ingen rute tilbake: spørringene får timeout selv om tunnelen er frisk. Det motsatte skjer når Pi-hole sitter på et subnett tunnelen ikke bærer. Sammenlign adressen med tunnelens tillatte prefikser og ruterens rutetabell før du rører DNS igjen.

Velg én rettelse, ikke begge. Enten hold tunnelen unna DNS — med pull-filter ignore “dhcp-option DNS” på OpenVPN og uten LAN-prefiks i AllowedIPs på WireGuard —, eller godta den dyttede resolveren og gi opp lokal filtrering for klienter bak den ruteren. Uansett hva du velger, skriv det ved siden av profilen, fordi neste person som redigerer den ellers vil snu beslutningen ved et uhell.

5. Gjenta testen etter en gjentilkobling

Spør fra en klient, bekreft at den klienten dukker opp i Pi-holes logg, løs deretter opp et domene som burde være blokkert og sjekk at du får blokkeringssvaret i stedet for det ekte. Koble til tunnelen igjen og kjør de samme to spørringene, fordi en resolverinnstilling som bare holder til neste tilkobling, er det vanlige resultatet av en rettelse brukt på feil lag.

La det være igjen en sekundær resolvervei som ikke avhenger av tunnelen, slik at et Pi-hole-utfall degraderes til ufiltrert surfing i stedet for ingen surfing. Behold de forrige DHCP- og resolververdiene til testen består to ganger; en endring som bryter husstandens internett ved middagstid er mye vanskeligere å feilsøke enn en du kan rulle tilbake på et minutt.