Pi-hole po povezavi z VPN ne blokira oglasov: pet preverjanj

Oglasi se še vedno prikazujejo na odjemalcu, Pi-hole se poroča kot zdrav, tunel pa je aktiven, zato je instinkt usmeriti promet tega odjemalca skozi Pi. To je napačen ovinek. Filtriranje potrebuje vprašanja, ne paketov, in odjemalec, katerega poizvedbe gredo k razreševalniku ponudnika, ostane nefiltriran, kamorkoli teče njegov promet. Pojdite skozi ta seznam po vrsti in se ustavite pri prvem koraku, ki spodleti, ker kasnejši korak ne more povedati ničesar, dokler je prejšnji pokvarjen.

1. Preberite razreševalnik, ki ga odjemalec dejansko uporablja

Vprašajte odjemalca, ne usmerjevalnika. V Linuxu resolvectl status izpiše strežnike DNS po povezavi in katera povezava zmaga; /etc/resolv.conf sam je običajno stub, ki kaže na 127.0.0.53. V Windowsu ipconfig /all našteje strežnike, ki jih dodeli DHCP, po vsakem vmesniku, v macOS pa scutil --dns prikaže isto po obsegu. Če odgovor ni naslov Pi-hole, imate težavo z dodelitvijo in korak 2 je mesto, kjer je.

Dve stvari premagata sistemski razreševalnik tudi, ko je pravilno nastavljen. Brskalniki z lastnim varnim DNS (možnost “Use secure DNS” v Chromu, network.trr.mode v Firefoxu) pošiljajo poizvedbe po HTTPS javnemu razreševalniku in nikoli ne odprejo vrat 53. In odjemalec VPN na samem odjemalcu lahko namesti strežnik DNS na svojem tunelskem vmesniku z domeno usmerjanja ~., kar to povezavo naredi merodajno za vsako ime.

Preizkusite pot, ki jo uberejo aplikacije, ne poti, ki jo ubere orodje za razhroščevanje. resolvectl query example.com pokaže, katera povezava je odgovorila, getent hosts example.com pa gre po isti poti NSS kot aplikacija; v macOS dscacheutil -q host -a name example.com bere razreševalnike po obsegu, ki jih našteje scutil --dns. Goli dig tega ne naredi: prebere /etc/resolv.conf in preskoči izbiro po povezavi, zato lahko odgovori iz Pi-hole, medtem ko vsaka aplikacija uporablja potisnjeni razreševalnik, in to je natanko tista okvara, za katero ta seznam obstaja. Obdržite dig @192.168.1.53 za preizkušanje enega določenega strežnika.

2. Potrdite, kdo razdeli odgovor

Dodelitev prihaja od tistega, kar odgovori na DHCP. Na dnsmasq je to ena vrstica, dhcp-option=6,192.168.1.53; v spletnem vmesniku usmerjevalnika je to polje DNS v razdelku DHCP za LAN. Odjemalci morajo obnoviti, preden to vidijo. Naprava, ki deluje že dneve, še vedno drži staro najemnino, naprava z ročno vpisanim razreševalnikom pa jo drži za vedno. Obnovite na preskusnem odjemalcu, namesto da bi predpostavljali širjenje.

IPv6 je tista polovica, ki se spregleda. Oznanila usmerjevalnika lahko nosijo lasten strežnik DNS (RDNSS), v OpenWrt je to možnost ra_dns v odhcpd; odjemalec, ki daje prednost IPv6, uporablja ta strežnik, medtem ko pravkar nastavljena možnost DHCPv4 ostaja neuporabljena. Če niste pripravljeni streči DNS po IPv6, izbrišite samo oznanilo DNS: ra_dns v odhcpd ali možnost RDNSS v čemur koli, kar odgovarja na oznanila usmerjevalnika. Izklop celotnega oznanila odstrani tudi naslavljanje IPv6 iz LAN, kar je veliko večja sprememba od načrtovane, medtem ko brisanje samo možnosti DNS ohrani naslavljanje nedotaknjeno in naredi manjkajoči RDNSS viden v zajemu paketov.

3. Dokažite, da poizvedba doseže Pi-hole

Poizvedba s Pi ne dokaže ničesar o omrežni poti. Zaženite jo z odjemalca in preberite kodo odgovora:

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

Časovna omejitev kaže na filtriranje ali na pot; REFUSED kaže na pravilo dostopa; SERVFAIL kaže na nadrejeni razreševalnik za Pi-hole; pravilen odgovor, ki se nikoli ne pojavi v dnevniku poizvedb, pomeni, da je odjemalec vprašal nekaj drugega. Preverite UDP in TCP 53, ker veliki odgovori in nekateri razreševalniki preidejo na TCP, in objavite oboje, ko Pi-hole teče v vsebniku. Preslikava, ki pokriva samo UDP, ustvarja občasne napake, ki izgledajo kot izguba paketov.

Nato način poslušanja Pi-hole odloči, ali sploh odgovarja. V načinu samo lokalno dnsmasq prezre poizvedbe iz virov, ki niso v neposredno povezanem podomrežju, in natanko tako izgleda odjemalec za drugim usmerjevalnikom ali tisti, ki prihaja skozi tunel: odjemalcu poteče čas in poizvedba nikoli ne doseže dnevnika. Poizvedba, ki se vseeno pojavi kot REFUSED, je bila zavrnjena s seznamom dostopa ali pravilom požarnega zidu. Dovoljenje vseh virov je običajna rešitev, skupaj s pravilom požarnega zidu, ki omejuje vrata 53 na vaša lastna podomrežja.

4. Preverite, ali je tunel odgovor nadomestil ali ga pogoltnil

To je primer, v katerem se skrivata oba simptoma. Ko je usmerjevalnik sam odjemalec VPN, lahko potisnjena možnost DNS preglasi nastavitev LAN v trenutku, ko se tunel dvigne: strežniki OpenVPN potiskajo dhcp-option DNS, profili WireGuard pa nosijo svoj vnos DNS. Berite dejanski razreševalnik usmerjevalnika z dvignjenim tunelom, ne pred tem, in prezrite, kar trdi stran LAN.

Druga napaka je dosegljivost, ne nadomestitev. Če dovoljene predpone tunela vključujejo vaše podomrežje LAN, ima usmerjevalnik pot, ki pošilja poizvedbe za 192.168.1.53 v tunel, druga stran pa nima poti nazaj: poizvedbam poteče čas, čeprav je tunel zdrav. Nasprotno se zgodi, ko Pi-hole sedi v podomrežju, ki ga tunel ne prenaša. Primerjajte naslov z dovoljenimi predponami tunela in usmerjevalno tabelo usmerjevalnika, preden se znova dotaknete DNS.

Izberite eno popravljanje, ne obeh. Bodisi držite tunel stran od DNS — s pull-filter ignore “dhcp-option DNS” na OpenVPN in brez predpone LAN v AllowedIPs na WireGuard —, bodisi sprejmite potisnjeni razreševalnik in se odrecite lokalnemu filtriranju za odjemalce za tem usmerjevalnikom. Karkoli izberete, zapišite to ob profilu, ker bo naslednja oseba, ki ga bo urejala, sicer po nesreči obrnila odločitev.

5. Ponovite preskus po ponovni povezavi

Poizvedite z odjemalca, potrdite, da se ta odjemalec pojavi v dnevniku Pi-hole, nato razrešite domeno, ki bi morala biti blokirana, in preverite, ali dobite odgovor o blokiranju namesto pravega. Znova povežite tunel in zaženite isti dve poizvedbi, ker je nastavitev razreševalnika, ki zdrži le do naslednje povezave, običajen rezultat popravka, uporabljenega na napačnem sloju.

Pustite sekundarno pot razreševalnika, ki ni odvisna od tunela, da izpad Pi-hole degradira v nefiltrirano brskanje namesto v nobenega. Obdržite prejšnje vrednosti DHCP in razreševalnika, dokler preskus ne uspe dvakrat; spremembo, ki pokvari internet gospodinjstva pri večerji, je veliko težje razhroščevati kot tisto, ki jo lahko razveljavite v minuti.