Pi-hole ne blokira reklame nakon spajanja VPN-a: pet provjera

Reklame se još prikazuju na klijentu, Pi-hole se prijavljuje kao zdrav, a tunel je aktivan, pa je instinkt da se promet tog klijenta usmjeri kroz Pi. To je pogrešan skret. Filtriranje traži pitanja, a ne pakete, i klijent čiji upiti idu na ISP-ov resolver ostaje nefiltriran bez obzira kuda teče njegov promet. Prođite kroz ovaj spisak redom i zaustavite se na prvom koraku koji padne, jer kasniji korak ne može ništa reći dok je raniji pokvaren.

1. Pročitajte resolver koji klijent zapravo koristi

Pitajte klijenta, a ne ruter. Na Linuxu resolvectl status ispisuje DNS servere po linku i koji link pobjeđuje; /etc/resolv.conf sam po sebi obično je stub koji pokazuje na 127.0.0.53. Na Windowsu ipconfig /all navodi servere dobijene putem DHCP-a po adapteru, a na macOS-u scutil --dns pokazuje isto po opsegu. Ako odgovor nije Pi-holeova adresa, imate problem s dodjelom i korak 2 je mjesto gdje se nalazi.

Dvije stvari pobjeđuju sistemski resolver čak i kada je ispravno postavljen. Preglednici s vlastitim sigurnim DNS-om (Chromeova “Use secure DNS”, Firefoxov network.trr.mode) šalju upite preko HTTPS-a javnom resolveru i nikada ne otvaraju port 53. A VPN klijent na samom klijentu može instalirati DNS server na svoje tunelsko sučelje s domenom usmjeravanja ~., što taj link čini mjerodavnim za svako ime.

Testirajte putanju kojom idu aplikacije, a ne putanju kojom ide alat za otklanjanje grešaka. resolvectl query example.com pokazuje koji je link odgovorio, a getent hosts example.com prolazi istom NSS putanjom kao aplikacija; na macOS-u dscacheutil -q host -a name example.com čita resolvere po opsegu koje scutil --dns navodi. Goli dig to ne radi: on čita /etc/resolv.conf i preskače odabir po linku, pa može odgovoriti iz Pi-hole-a dok svaka aplikacija koristi gurnuti resolver, a to je upravo onaj kvar za koji ovaj spisak postoji. Zadržite dig @192.168.1.53 za testiranje jednog konkretnog servera.

2. Potvrdite ko dijeli odgovor

Dodjela dolazi od svega što odgovara na DHCP. Na dnsmasq-u to je jedan red, dhcp-option=6,192.168.1.53; u web sučelju rutera to je polje DNS u odjeljku LAN DHCP. Klijenti moraju obnoviti prije nego što to vide. Uređaj koji radi danima još drži stari zakup, a uređaj s ručno upisanim resolverom drži ga zauvijek. Obnovite na testnom klijentu umjesto da pretpostavljate propagaciju.

IPv6 je ona polovina koja se propušta. Router oglasi mogu nositi vlastiti DNS server (RDNSS), a na OpenWrt-u to je odhcpd-ova opcija ra_dns; klijent koji preferira IPv6 koristi taj server dok opcija DHCPv4 koju ste upravo postavili ostaje neiskorištena. Ako niste spremni posluživati IPv6 DNS, obrišite samo DNS oglas: ra_dns u odhcpd-u ili opciju RDNSS u čemu god odgovara na router oglase. Isključivanje cijelog oglasa uklanja i IPv6 adresiranje iz LAN-a, što je mnogo veća promjena od one koju ste namjeravali, dok brisanje samo DNS opcije čuva adresiranje netaknutim i čini nedostajući RDNSS vidljivim u snimci paketa.

3. Dokažite da upit stiže do Pi-hole-a

Upit s Pi-ja ne dokazuje ništa o mrežnoj putanji. Pokrenite ga s klijenta i pročitajte kod odgovora:

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

Vremensko ograničenje ukazuje na filtriranje ili na rutu; REFUSED ukazuje na pravilo pristupa; SERVFAIL ukazuje na uzvodni resolver iza Pi-hole-a; ispravan odgovor koji se nikada ne pojavi u zapisu upita znači da je klijent pitao nešto drugo. Provjerite UDP i TCP 53, jer veliki odgovori i neki resolveri prelaze na TCP, i objavite oba kada Pi-hole radi u kontejneru. Mapiranje koje pokriva samo UDP stvara povremene kvarove koji izgledaju kao gubitak paketa.

Tada način slušanja Pi-hole-a odlučuje odgovara li uopće. U načinu samo lokalno dnsmasq ignorira upite s izvora koji nisu na izravno priključenoj podmreži, a upravo tako izgleda klijent iza drugog rutera ili onaj koji dolazi kroz tunel: klijent istekne i upit nikada ne stigne do zapisa. Upit koji se ipak pojavi kao REFUSED odbio je popis pristupa ili pravilo vatrozida. Dopuštanje svih izvora uobičajen je popravak, uz pravilo vatrozida koje ograničava port 53 na vaše vlastite podmreže.

4. Provjerite je li tunel zamijenio ili progutao odgovor

To je slučaj u kojem se kriju oba simptoma. Kada je ruter sam VPN klijent, gurnuta DNS opcija može nadjačati LAN postavku u trenutku kada se tunel podigne: OpenVPN serveri guraju dhcp-option DNS, a WireGuard profili nose vlastiti DNS unos. Čitajte efektivni resolver rutera s podignutim tunelom, a ne prije toga, i zanemarite što tvrdi LAN stranica.

Drugi kvar je dostupnost, a ne zamjena. Ako dopušteni prefiksi tunela uključuju vašu LAN podmrežu, ruter ima rutu koja upite za 192.168.1.53 šalje u tunel, a suprotna strana nema rutu natrag: upiti isteknu iako je tunel zdrav. Obrnuto se događa kada Pi-hole sjedi na podmreži koju tunel ne nosi. Uporedite adresu s dopuštenim prefiksima tunela i ruterovom tablicom ruta prije nego ponovno dirnete DNS.

Odaberite jedan popravak, a ne oba. Ili držite tunel podalje od DNS-a — s pull-filter ignore “dhcp-option DNS” na OpenVPN-u i bez LAN prefiksa u AllowedIPs na WireGuard-u — ili prihvatite gurnuti resolver i odreknete se lokalnog filtriranja za klijente iza tog rutera. Što god odabrali, zapišite to uz profil, jer će sljedeća osoba koja ga bude uređivala inače slučajno preokrenuti odluku.

5. Ponovite test nakon ponovnog spajanja

Upitajte s klijenta, potvrdite da se taj klijent pojavljuje u Pi-holeovom zapisu, zatim razriješite domenu koja bi trebala biti blokirana i provjerite dobivate li blokirajući odgovor umjesto pravog. Ponovno spojite tunel i pokrenite ista dva upita, jer resolver postavka koja traje samo do sljedećeg spajanja uobičajen je rezultat popravka primijenjenog na pogrešnom sloju.

Ostavite sekundarnu resolver putanju koja ne ovisi o tunelu, kako bi ispad Pi-hole-a degradirao na nefiltrirano pregledanje umjesto nikakvog pregledanja. Zadržite prethodne DHCP i resolver vrijednosti dok test ne prođe dvaput; promjenu koja pokvari kućni internet za večerom mnogo je teže otkloniti od one koju možete vratiti u minuti.