Pi-hole po připojení VPN neblokuje reklamy: pět kontrol

Reklamy se na klientovi stále zobrazují, Pi-hole se hlásí jako zdravý a tunel je nahoře, takže instinktem je poslat provoz toho klienta přes Pi. To je špatné odbočení. Filtrování potřebuje otázky, ne pakety, a klient, jehož dotazy jdou do resolveru poskytovatele, zůstává nefiltrovaný bez ohledu na to, kudy jeho provoz teče. Projděte tento seznam v pořadí a zastavte se u prvního kroku, který selže, protože pozdější krok vám nic neřekne, dokud je předchozí rozbitý.

1. Přečtěte si resolver, který klient skutečně používá

Ptejte se klienta, ne routeru. V Linuxu resolvectl status vypisuje DNS servery pro každé připojení a které připojení vyhraje; /etc/resolv.conf sám o sobě je obvykle stub ukazující na 127.0.0.53. Ve Windows ipconfig /all vypisuje servery přidělené DHCP pro každý adaptér a v macOS scutil --dns ukazuje totéž podle rozsahu. Pokud odpověď není adresa Pi-hole, máte problém s přiřazením a krok 2 je místo, kde sídlí.

Dvě věci porazí systémový resolver, i když je správně nastavený. Prohlížeče s vlastním zabezpečeným DNS (volba “Use secure DNS” v Chromu, network.trr.mode ve Firefoxu) posílají dotazy přes HTTPS veřejnému resolveru a nikdy neotevřou port 53. A VPN klient na samotném klientovi může nainstalovat DNS server na své tunelové rozhraní s doménou směrování ~., což toto připojení učiní autoritativním pro každé jméno.

Testujte cestu, kterou jdou aplikace, ne cestu, kterou jde ladicí nástroj. resolvectl query example.com ukáže, které připojení odpovědělo, a getent hosts example.com jde stejnou cestou NSS jako aplikace; v macOS dscacheutil -q host -a name example.com čte resolvery podle rozsahu, které vypisuje scutil --dns. Holý dig to nedělá: čte /etc/resolv.conf a přeskakuje výběr podle připojení, takže může odpovědět z Pi-hole, zatímco každá aplikace používá vynucený resolver, a to je přesně ta porucha, pro kterou tento seznam existuje. Ponechte dig @192.168.1.53 pro testování jednoho konkrétního serveru.

2. Potvrďte, kdo odpověď rozdává

Přiřazení pochází od toho, co odpovídá na DHCP. Na dnsmasq je to jeden řádek, dhcp-option=6,192.168.1.53; ve webovém rozhraní routeru je to pole DNS v sekci DHCP pro LAN. Klienti musí obnovit, než to uvidí. Zařízení, které běží dny, stále drží starý pronájem a zařízení s ručně zadaným resolverem ho drží navždy. Obnovte to na testovacím klientovi, místo abyste předpokládali šíření.

IPv6 je ta polovina, která se přehlíží. Oznámení routeru mohou nést vlastní DNS server (RDNSS) a na OpenWrt je to volba ra_dns v odhcpd; klient, který preferuje IPv6, používá tento server, zatímco volba DHCPv4, kterou jste právě nastavili, zůstává nevyužitá. Pokud nejste připraveni obsluhovat IPv6 DNS, vymažte pouze oznámení DNS: ra_dns v odhcpd, nebo volbu RDNSS v čemkoli, co odpovídá na oznámení routeru. Vypnutí celého oznámení také odstraní adresování IPv6 z LAN, což je mnohem větší změna než ta, kterou jste zamýšleli, zatímco vymazání pouze volby DNS ponechá adresování nedotčené a učiní chybějící RDNSS viditelným v zachytávání paketů.

3. Dokažte, že dotaz dorazí do Pi-hole

Dotaz z Pi nic nedokazuje o síťové cestě. Spusťte ho z klienta a přečtěte kód odpovědi:

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

Časový limit ukazuje na filtrování nebo na trasu; REFUSED ukazuje na přístupové pravidlo; SERVFAIL ukazuje na nadřazený resolver za Pi-hole; správná odpověď, která se nikdy neobjeví v protokolu dotazů, znamená, že se klient ptal na něco jiného. Zkontrolujte UDP a TCP 53, protože velké odpovědi a některé resolvery přecházejí na TCP, a publikujte obojí, když Pi-hole běží v kontejneru. Mapování, které pokrývá jen UDP, vytváří občasné poruchy, které vypadají jako ztráta paketů.

Pak režim naslouchání Pi-hole rozhodne, zda vůbec odpovídá. V režimu pouze lokálně dnsmasq ignoruje dotazy od zdrojů, které nejsou v přímo připojené podsíti, a přesně tak vypadá klient za jiným routerem nebo ten, kdo přichází tunelem: klient vyprší a dotaz se nikdy nedostane do protokolu. Dotaz, který se přesto objeví jako REFUSED, byl odmítnut přístupovým seznamem nebo pravidlem firewallu. Povolení všech zdrojů je obvyklá oprava spolu s pravidlem firewallu, které omezuje port 53 na vaše vlastní podsítě.

4. Zkontrolujte, zda tunel odpověď nahradil nebo pohltil

To je případ, ve kterém se skrývají oba příznaky. Když je router sám VPN klientem, vynucená volba DNS může přepsat nastavení LAN ve chvíli, kdy se tunel zvedne: servery OpenVPN vynucují dhcp-option DNS a profily WireGuard nesou vlastní záznam DNS. Čtěte efektivní resolver routeru se zvednutým tunelem, ne před tím, a ignorujte, co tvrdí stránka LAN.

Druhá závada je dosažitelnost, ne nahrazení. Pokud povolené prefixy tunelu zahrnují vaši podsíť LAN, má router trasu, která posílá dotazy na 192.168.1.53 do tunelu, a protistrana nemá trasu zpět: dotazy vyprší, i když je tunel zdravý. Opačně se to stane, když Pi-hole sedí v podsíti, kterou tunel nenese. Porovnejte adresu s povolenými prefixy tunelu a směrovací tabulkou routeru, než znovu sáhnete na DNS.

Vyberte jednu opravu, ne obě. Buď držte tunel mimo DNS — s pull-filter ignore “dhcp-option DNS” na OpenVPN a bez prefixu LAN v AllowedIPs na WireGuard —, nebo přijměte vynucený resolver a vzdáte se místního filtrování pro klienty za tímto routerem. Ať vyberete cokoli, napište to vedle profilu, protože další člověk, který ho bude upravovat, by jinak rozhodnutí omylem obrátil.

5. Po opětovném připojení test zopakujte

Dotážejte se z klienta, potvrďte, že se tento klient objevuje v protokolu Pi-hole, pak přeložte doménu, která má být blokována, a ověřte, že dostáváte blokující odpověď místo skutečné. Znovu připojte tunel a spusťte stejné dva dotazy, protože nastavení resolveru, které vydrží jen do příštího připojení, je obvyklým výsledkem opravy provedené ve špatné vrstvě.

Nechte sekundární cestu resolveru, která nezávisí na tunelu, aby výpadek Pi-hole degradoval na nefiltrované prohlížení místo žádného prohlížení. Ponechte předchozí hodnoty DHCP a resolveru, dokud test neprojde dvakrát; změna, která rozbije internet domácnosti při večeři, se ladí mnohem obtížněji než ta, kterou můžete vrátit za minutu.