Pi-hole po pripojení VPN neblokuje reklamy: päť kontrol

Reklamy sa na klientovi stále zobrazujú, Pi-hole sa hlási ako zdravý a tunel je aktívny, takže inštinkt je poslať prevádzku toho klienta cez Pi. To je nesprávna odbočka. Filtrovanie potrebuje otázky, nie pakety, a klient, ktorého dopyty idú do resolvera poskytovateľa, zostáva nefiltrovaný bez ohľadu na to, kadiaľ jeho prevádzka tečie. Prejdite tento zoznam v poradí a zastavte sa pri prvom kroku, ktorý zlyhá, pretože neskorší krok vám nič nepovie, kým je predchádzajúci pokazený.

1. Prečítajte si resolver, ktorý klient skutočne používa

Pýtajte sa klienta, nie routera. V Linuxe resolvectl status vypisuje DNS servery pre každé pripojenie a ktoré pripojenie vyhrá; /etc/resolv.conf sám je zvyčajne stub ukazujúci na 127.0.0.53. Vo Windows ipconfig /all vypisuje servery pridelené cez DHCP pre každý adaptér a v macOS scutil --dns ukazuje to isté podľa rozsahu. Ak odpoveď nie je adresa Pi-hole, máte problém s priradením a krok 2 je miesto, kde sa nachádza.

Dve veci porážajú systémový resolver, aj keď je správne nastavený. Prehliadače s vlastným zabezpečeným DNS (voľba “Use secure DNS” v Chrome, network.trr.mode vo Firefoxe) posielajú dopyty cez HTTPS verejnému resolveru a nikdy neotvoria port 53. A VPN klient na samotnom klientovi môže nainštalovať DNS server na svoje tunelové rozhranie s doménou smerovania ~., čo toto pripojenie robí autoritatívnym pre každé meno.

Testujte cestu, ktorou idú aplikácie, nie cestu, ktorou ide ladiaci nástroj. resolvectl query example.com ukáže, ktoré pripojenie odpovedalo, a getent hosts example.com ide tou istou cestou NSS ako aplikácia; v macOS dscacheutil -q host -a name example.com číta resolvery podľa rozsahu, ktoré vypisuje scutil --dns. Holý dig to nerobí: číta /etc/resolv.conf a preskočí výber podľa pripojenia, takže môže odpovedať z Pi-hole, kým každá aplikácia používa vynútený resolver, a to je presne tá porucha, pre ktorú tento zoznam existuje. Ponechajte dig @192.168.1.53 na testovanie jedného konkrétneho servera.

2. Potvrďte, kto odpoveď rozdáva

Priradenie pochádza od toho, čo odpovedá na DHCP. Na dnsmasq je to jeden riadok, dhcp-option=6,192.168.1.53; vo webovom rozhraní routera je to pole DNS v sekcii DHCP pre LAN. Klienti musia obnoviť, kým to uvidia. Zariadenie, ktoré beží dni, stále drží starý prenájom a zariadenie s ručne zadaným resolverom ho drží navždy. Obnovte to na testovacom klientovi namiesto predpokladu šírenia.

IPv6 je tá polovica, ktorá sa prehliada. Oznamy routera môžu niesť vlastný DNS server (RDNSS) a v OpenWrt je to voľba ra_dns v odhcpd; klient, ktorý preferuje IPv6, používa tento server, kým práve nastavená voľba DHCPv4 zostáva nevyužitá. Ak nie ste pripravení obsluhovať IPv6 DNS, vymažte iba oznam DNS: ra_dns v odhcpd alebo voľbu RDNSS v čomkoľvek, čo odpovedá na oznamy routera. Vypnutie celého oznamu odstráni aj adresovanie IPv6 z LAN, čo je oveľa väčšia zmena než zamýšľaná, kým vymazanie iba voľby DNS ponechá adresovanie nedotknuté a chýbajúci RDNSS sa stane viditeľným v zachytení paketov.

3. Dokážte, že dopyt sa dostane do Pi-hole

Dopyt z Pi nič nedokazuje o sieťovej ceste. Spustite ho z klienta a prečítajte kód odpovede:

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

Časový limit ukazuje na filtrovanie alebo na trasu; REFUSED ukazuje na prístupové pravidlo; SERVFAIL ukazuje na nadradený resolver za Pi-hole; správna odpoveď, ktorá sa nikdy neobjaví v protokole dopytov, znamená, že klient sa pýtal na niečo iné. Skontrolujte UDP a TCP 53, pretože veľké odpovede a niektoré resolvery prechádzajú na TCP, a publikujte oboje, keď Pi-hole beží v kontajneri. Mapovanie, ktoré pokrýva iba UDP, vytvára občasné zlyhania, ktoré vyzerajú ako strata paketov.

Potom režim počúvania Pi-hole rozhodne, či vôbec odpovedá. V režime iba lokálne dnsmasq ignoruje dopyty zo zdrojov, ktoré nie sú v priamo pripojenej podsieti, a presne tak vyzerá klient za iným routerom alebo ten, ktorý prichádza cez tunel: klientovi vyprší čas a dopyt sa nikdy nedostane do protokolu. Dopyt, ktorý sa napriek tomu objaví ako REFUSED, bol odmietnutý zoznamom prístupu alebo pravidlom firewallu. Povolenie všetkých zdrojov je obvyklá oprava spolu s pravidlom firewallu, ktoré obmedzuje port 53 na vaše vlastné podsiete.

4. Skontrolujte, či tunel odpoveď nahradil alebo pohltil

To je prípad, v ktorom sa skrývajú oba príznaky. Keď je router sám VPN klientom, vynútená voľba DNS môže prepísať nastavenie LAN vo chvíli, keď sa tunel zdvihne: servery OpenVPN vynucujú dhcp-option DNS a profily WireGuard nesú vlastný záznam DNS. Čítajte efektívny resolver routera so zdvihnutým tunelom, nie predtým, a ignorujte, čo tvrdí stránka LAN.

Druhá závada je dosiahnuteľnosť, nie nahradenie. Ak povolené prefixy tunela zahŕňajú vašu podsiete LAN, router má trasu, ktorá posiela dopyty na 192.168.1.53 do tunela, a druhá strana nemá trasu späť: dopyty vypršia, aj keď je tunel zdravý. Opačne sa to stane, keď Pi-hole sedí v podsieti, ktorú tunel nenesie. Porovnajte adresu s povolenými prefixmi tunela a smerovacou tabuľkou routera, kým znova siahnete na DNS.

Vyberte jednu opravu, nie obe. Buď držte tunel mimo DNS — s pull-filter ignore “dhcp-option DNS” na OpenVPN a bez prefixu LAN v AllowedIPs na WireGuard —, alebo prijmite vynútený resolver a vzdajte sa lokálneho filtrovania pre klientov za týmto routerom. Čokoľvek vyberiete, napíšte to vedľa profilu, pretože ďalší človek, ktorý ho bude upravovať, by inak rozhodnutie omylom obrátil.

5. Po opätovnom pripojení test zopakujte

Dopytujte sa z klienta, potvrďte, že sa tento klient objavuje v protokole Pi-hole, potom preložte doménu, ktorá by mala byť blokovaná, a overte, že dostávate blokujúcu odpoveď namiesto skutočnej. Znova pripojte tunel a spustite tie isté dva dopyty, pretože nastavenie resolvera, ktoré vydrží len do ďalšieho pripojenia, je obvyklým výsledkom opravy vykonanej v nesprávnej vrstve.

Nechajte sekundárnu cestu resolvera, ktorá nezávisí od tunela, aby výpadok Pi-hole degradoval na nefiltrované prehliadanie namiesto žiadneho prehliadania. Ponechajte predchádzajúce hodnoty DHCP a resolvera, kým test neprejde dvakrát; zmena, ktorá pokazí internet domácnosti pri večeri, sa ladení oveľa ťažšie než tá, ktorú môžete vrátiť za minútu.