Pi-hole ei blokeeri reklaame pärast VPN-i ühendamist: viis kontrolli

Reklaamid ilmuvad endiselt kliendis, Pi-hole teatab, et on terve, ja tunnel on üleval, seega on instinkt suunata selle kliendi liiklus läbi Pi. See on vale pööre. Filtreerimine vajab küsimusi, mitte pakette, ja klient, kelle päringud lähevad teenusepakkuja resolverisse, jääb filtreerimata olenemata sellest, kuhu tema liiklus voolab. Käige see nimekiri järjest läbi ja peatuge esimese sammu juures, mis ebaõnnestub, sest hilisem samm ei saa teile midagi öelda, kuni varasem on katki.

1. Lugege resolverit, mida klient tegelikult kasutab

Küsige kliendilt, mitte ruuterilt. Linuxis trükib resolvectl status DNS-serverid lingi kohta ja selle, milline link võidab; /etc/resolv.conf üksi on tavaliselt stub, mis osutab aadressile 127.0.0.53. Windowsis loetleb ipconfig /all DHCP kaudu antud serverid adapteri kohta ja macOS-is näitab scutil --dns sama ulatuse kaupa. Kui vastus ei ole Pi-hole'i aadress, on teil määramisprobleem ja samm 2 on koht, kus see asub.

Süsteemset resolverit võidavad kaks asja ka siis, kui see on õigesti seatud. Oma turvalise DNS-iga brauserid (Chrome'i “Use secure DNS”, Firefoxi network.trr.mode) saadavad päringud HTTPS-i kaudu avalikku resolverisse ega ava kunagi porti 53. Ja VPN-klient kliendi enda peal võib paigaldada DNS-serveri oma tunneliliidesele marsruutimisdomeeniga ~., mis teeb selle lingi iga nime jaoks autoriteetseks.

Testige teed, mida rakendused lähevad, mitte teed, mida silumisriist läheb. resolvectl query example.com näitab, milline link vastas, ja getent hosts example.com läbib sama NSS-teed nagu rakendus; macOS-is loeb dscacheutil -q host -a name example.com ulatuspõhiseid resolvereid, mida scutil --dns loetleb. Paljas dig seda ei tee: see loeb /etc/resolv.conf ja jätab lingipõhise valiku vahele, seega võib see vastata Pi-hole'ist, samal ajal kui iga rakendus kasutab surutud resolverit, ja just see ongi tõrge, mille jaoks see nimekiri olemas on. Jätke dig @192.168.1.53 ühe kindla serveri testimiseks.

2. Kinnitage, kes vastuse välja jagab

Määramine tuleb sellest, mis DHCP-le vastab. dnsmasq-is on see üks rida, dhcp-option=6,192.168.1.53; ruuteri veebiliideses on see LAN-i DHCP-jaotise DNS-väli. Kliendid peavad enne selle nägemist uuendama. Seade, mis on päevi üleval olnud, hoiab endiselt vana rendilepingut, ja käsitsi sisestatud resolveriga seade hoiab seda igavesti. Uuendage testkliendil, selle asemel et levikut eeldada.

IPv6 on see pool, mis kahe silma vahele jääb. Ruuteri teated võivad kanda oma DNS-serverit (RDNSS), ja OpenWrt-is on see odhcpd valik ra_dns; klient, kes eelistab IPv6-te, kasutab seda serverit, samal ajal kui äsja seatud DHCPv4 valik jääb kasutamata. Kui te ei ole valmis IPv6 DNS-i teenindama, kustutage ainult DNS-teade: ra_dns odhcpd-is või RDNSS-valik selles, mis ruuteri teadetele vastab. Kogu teate väljalülitamine eemaldab LAN-ist ka IPv6 adresseerimise, mis on palju suurem muudatus kui kavatsesite, samal ajal kui ainult DNS-valiku kustutamine hoiab adresseerimise puutumatuna ja teeb puuduva RDNSS-i paketipüügises nähtavaks.

3. Tõestage, et päring jõuab Pi-hole'ini

Päring Pi küljest ei tõesta võrgutee kohta midagi. Käivitage see kliendist ja lugege vastusekoodi:

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

Ajalõpp osutab filtreerimisele või marsruudile; REFUSED osutab juurdepääsureeglile; SERVFAIL osutab Pi-hole'i taga olevale ülemresolverile; õige vastus, mis ei ilmu kunagi päringulogis, tähendab, et klient küsis midagi muud. Kontrollige UDP ja TCP 53, sest suured vastused ja mõned resolverid langesid tagasi TCP-le, ja avaldage mõlemad, kui Pi-hole töötab konteineris. Ainult UDP-d kattev vastendus tekitab aeg-ajalt tõrkeid, mis näevad välja nagu paketikaotus.

Seejäre l otsustab Pi-hole'i kuulamisrežiim, kas see üldse vastab. Ainult kohalikus režiimis eirab dnsmasq päringuid allikatest, mis ei ole otseselt ühendatud alavõrgus, ja täpselt selline näebki välja klient teise ruuteri taga või tunnelist saabuv klient: kliendil lõpeb aeg ja päring ei jõua kunagi logisse. Päring, mis siiski ilmub REFUSED-ina, lükati tagasi juurdepääsunimekirja või tulemüürireegliga. Kõigi päritolude lubamine on tavaline parandus, millega kaasneb tulemüürireegel, mis piirab pordi 53 teie enda alavõrkudega.

4. Kontrollige, kas tunnel asendas vastuse või neelas selle alla

See on juhtum, mille sisse mõlemad sümptomid peituvad. Kui ruuter ise on VPN-klient, võib surutud DNS-valik alistada LAN-i seade hetkel, mil tunnel üles tuleb: OpenVPN serverid suruvad dhcp-option DNS ja WireGuard profiilid kannavad oma DNS-kirjet. Lugege ruuteri tegelikku resolverit tunneliga üleval, mitte enne seda, ja ignoreerige seda, mida LAN-i leht väidab.

Teine viga on kättesaadavus, mitte asendamine. Kui tunneli lubatud prefiksid sisaldavad teie LAN-i alavõrku, on ruuteril marsruut, mis saadab 192.168.1.53 päringud tunnelisse, ja teisel poolel pole tagasiteed: päringutel lõpeb aeg, kuigi tunnel on terve. Vastupidine juhtub siis, kui Pi-hole asub alavõrgus, mida tunnel ei kanna. Võrrelge aadressi tunneli lubatud prefiksite ja ruuteri marsruutimistabeliga enne, kui DNS-i uuesti puutute.

Valige üks parandus, mitte mõlemad. Kas hoidke tunnel DNS-ist eemal — OpenVPN-is pull-filter ignore “dhcp-option DNS” ja WireGuard-is ilma LAN-i prefiksita AllowedIPs-is — või leppige surutud resolveriga ja loobuge selle ruuteri taga olevate klientide kohalikust filtreerimisest. Ükskõik mida valite, kirjutage see profiili kõrvale, sest järgmine inimene, kes seda muudab, pöörab otsuse muidu kogemata ümber.

5. Korrake testi pärast uuesti ühendamist

Tehke päring kliendist, kinnitage, et see klient ilmub Pi-hole'i logisse, seejärel lahendage domeen, mis peaks olema blokeeritud, ja kontrollige, et saate blokeeriva vastuse tõelise asemel. Ühendage tunnel uuesti ja käivitage samad kaks päringut, sest resolveri seade, mis püsib ainult kuni järgmise ühenduseni, on vale kihis rakendatud paranduse tavaline tulemus.

Jätke teisene resolveri tee, mis ei sõltu tunnelist, et Pi-hole'i rike manduks filtreerimata sirvimiseks, mitte üldse sirvimise puudumiseks. Hoidke varasemad DHCP ja resolveri väärtused, kuni test läbib kaks korda; muudatust, mis lõhub majapidamise interneti õhtusöögi ajal, on palju raskem siluda kui seda, mille saate minutiga tagasi võtta.