Pi-hole blokkerer ikkje annonsar etter at VPN-en koplet til: fem kontrollar

Annonsar blir framleis viste på ein klient, Pi-hole melder seg frisk, og tunnelen er oppe, så instinktet er å rute trafikken frå den klienten gjennom Pi-en. Det er den gale svingen. Filtrering treng spørsmåla, ikkje pakkane, og ein klient der spørjingane går til resolvaren til leverandøren, blir verande ufiltrert kvar trafikken enn flyt. Gå gjennom denne lista i rekkjefølgje og stopp ved det første trinnet som feilar, fordi eit seinare trinn ikkje kan fortelje deg noko medan eit tidlegare er øydelagt.

1. Les resolvaren klienten faktisk brukar

Spør klienten, ikkje rutaren. På Linux skriv resolvectl status ut DNS-tenarane per lenkje og kva lenkje som vinn; /etc/resolv.conf åleine er vanlegvis ein stub som peikar på 127.0.0.53. På Windows listar ipconfig /all opp tenarane som DHCP deler ut per adapter, og på macOS viser scutil --dns det same per omfang. Viss svaret ikkje er Pi-hole-adressa, har du eit tildelingsproblem, og trinn 2 er der det bur.

To ting slår systemresolvaren sjølv når han er rett sett opp. Nettlesarar med eigen sikker DNS (valet “Use secure DNS” i Chrome, network.trr.mode i Firefox) sender spørjingar over HTTPS til ein offentleg resolvar og opnar aldri port 53. Og ein VPN-klient på sjølve klienten kan installere ein DNS-tenar på tunnelgrensesnittet med eit rutingsdomene på ~., noko som gjer den lenkja autoritativ for kvart namn.

Test vegen applikasjonar tek, ikkje vegen eit feilsøkingsverktøy tek. resolvectl query example.com viser kva lenkje som svara, og getent hosts example.com går gjennom same NSS-vegen som ein applikasjon; på macOS les dscacheutil -q host -a name example.com dei omfangsbestemte resolvarane som scutil --dns listar opp. Ein bar dig gjer ikkje dette: han les /etc/resolv.conf og hoppar over valet per lenkje, så han kan svare frå Pi-hole medan kvar applikasjon brukar den dytta resolvaren, og det er nøyaktig feilen denne lista finst for å fange. Hald dig @192.168.1.53 for å teste éin bestemd tenar.

2. Stadfest kven som deler ut svaret

Tildelinga kjem frå det som svarar på DHCP. På dnsmasq er det éi linje, dhcp-option=6,192.168.1.53; i webgrensesnittet til ein ruter er det DNS-feltet i LAN-DHCP-delen. Klientar må fornye før dei ser det. Ein eining som har stått på i dagar, held framleis den gamle leiga, og ei eining med ein handskriven resolvar held henne for alltid. Forny på ein testklient i staden for å anta spreiing.

IPv6 er halvparten som blir gløymd. Ruterannonsar kan bere sin eigen DNS-tenar (RDNSS), og på OpenWrt er det valet ra_dns i odhcpd; ein klient som føretrekkjer IPv6 brukar den tenaren, medan DHCPv4-valet du nettopp sette står ubrukt. Viss du ikkje er klar til å tene IPv6-DNS, tøm berre DNS-annonsen: ra_dns i odhcpd, eller RDNSS-valet i det som svarar på ruterannonsar. Å slå av heile annonsen fjernar òg IPv6-adressering frå LAN-et, noko som er ei mykje større endring enn den du meinte å gjere, medan å tømme berre DNS-valet held adresseringa intakt og gjer den manglande RDNSS-en synleg i ein pakkefangst.

3. Prov at spørjinga når Pi-hole

Ei spørjing frå Pi-en provar ingenting om nettverksvegen. Køyr henne frå klienten og les svarkoden:

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

Eit tidsavbrot peikar på filtrering eller på ei rute; REFUSED peikar på ein tilgangsregel; SERVFAIL peikar på resolvaren over Pi-hole; eit rett svar som aldri dukkar opp i spørjeloggen, tyder på at klienten spurde om noko anna. Sjekk UDP og TCP 53, fordi store svar og nokre resolvarar fell tilbake til TCP, og publiser båe når Pi-hole køyrer i ein container. Ein kartlegging som berre dekkjer UDP, gjev periodiske feil som ser ut som pakketap.

Deretter avgjer lyttemodusen til Pi-hole om han i det heile svarar. I modusen berre lokalt ignorerer dnsmasq spørjingar frå kjelder som ikkje er på eit direkte tilkopla subnett, og akkurat slik ser ein klient bak ein annan ruter eller ein som kjem gjennom ein tunnel ut: klienten får tidsavbrot og spørjinga når aldri loggen. Ei spørjing som likevel dukkar opp som REFUSED, vart avvist av ei tilgangsliste eller ein brannmurregel. Å tillate alle opphav er den vanlege rettinga, saman med ein brannmurregel som avgrensar port 53 til dine eigne subnett.

4. Sjekk om tunnelen erstatta eller slukte svaret

Dette er tilfellet der båe symptoma gøymer seg. Når rutaren sjølv er VPN-klient, kan eit dytta DNS-val overstyre LAN-innstillinga i det augneblinket tunnelen kjem opp: OpenVPN-tenarar dyttar dhcp-option DNS, og WireGuard-profil har sin eigen DNS-oppføring. Les den effektive resolvaren til rutaren med tunnelen oppe, ikkje før, og ignorer det LAN-sida påstår.

Den andre feilen er tilgjenge snarare enn erstatning. Viss dei tillatne prefiksa til tunnelen omfattar LAN-subnettet ditt, har rutaren ei rute som sender spørjingar for 192.168.1.53 inn i tunnelen, og den andre sida har inga rute tilbake: spørjingane får tidsavbrot sjølv om tunnelen er frisk. Det motsette skjer når Pi-hole sit på eit subnett tunnelen ikkje ber. Samanlikn adressa med dei tillatne prefiksa til tunnelen og rutetabellen til rutaren før du rører DNS igjen.

Vel éi retting, ikkje båe. Anten hald tunnelen unna DNS — med pull-filter ignore “dhcp-option DNS” på OpenVPN og utan LAN-prefiks i AllowedIPs på WireGuard —, eller godta den dytta resolvaren og gje opp lokal filtrering for klientar bak den rutaren. Uansett kva du vel, skriv det ved sida av profilen, fordi neste person som redigerer han elles vil snu avgjerda ved eit uhell.

5. Gjenta testen etter ein ny tilkopling

Spør frå ein klient, stadfest at den klienten dukkar opp i loggen til Pi-hole, løys deretter opp eit domene som burde vere blokkert og sjekk at du får blokkeringssvaret i staden for det ekte. Kople tunnelen til igjen og køyr dei same to spørjingane, fordi ei resolvarinnstilling som berre held til neste tilkopling, er det vanlege resultatet av ei retting brukt på feil lag.

Lat det liggje att ein sekundær resolvarveg som ikkje er avhengig av tunnelen, slik at eit Pi-hole-utfall blir degradert til ufiltrert surfing i staden for inga surfing. Hald på dei førre DHCP- og resolvarverdiane til testen går gjennom to gonger; ei endring som bryt internettet til husstanden ved middagstid er mykje vanskelegare å feilsøkje enn ei du kan rulle tilbake på eitt minutt.