Pi-hole blokkeer nie advertensies nadat die VPN koppel nie: vyf kontroles

Advertensies wys nog op 'n kliënt, Pi-hole sê hy is gesond, en die tonnel is op, so die instink is om daardie kliënt se verkeer deur die Pi te stuur. Dit is die verkeerde draai. Filtering het die vrae nodig, nie die pakkette nie, en 'n kliënt wie se navrae na die ISP-resolver gaan, bly ongefilterd maak nie saak waar sy verkeer vloei nie. Werk hierdie lys in volgorde deur en stop by die eerste stap wat misluk, want 'n latere stap kan jou niks sê terwyl 'n vroeëre een stukkend is.

1. Lees die resolver wat die kliënt werklik gebruik

Vra die kliënt, nie die router nie. Op Linux druk resolvectl status die DNS-bediener per skakel en watter skakel wen; /etc/resolv.conf op sy eie is gewoonlik 'n stomp wat na 127.0.0.53 wys. Op Windows lys ipconfig /all die DHCP-verskafte bedieners per adapter, en op macOS wys scutil --dns dieselfde ding per omvang. As die antwoord nie Pi-hole se adres is nie, het jy 'n toewysingsprobleem en stap 2 is waar dit sit.

Twee dinge verydel die stelselresolver selfs wanneer dit korrek opgestel is. Blaaiers met hul eie veilige DNS (Chrome se “Use secure DNS”, Firefox se network.trr.mode) stuur navrae via HTTPS na 'n openbare resolver en maak nooit poort 53 oop nie. En 'n VPN-kliënt op die kliënt self kan 'n DNS-bediener op sy tonnelkoppelvlak installeer met 'n roeteringsdomein van ~., wat daardie skakel gesaghebbend maak vir elke naam.

Toets die pad wat programme neem, nie die pad wat 'n ontfoutingsinstrument neem nie. resolvectl query example.com wys watter skakel geantwoord het, en getent hosts example.com gaan deur dieselfde NSS-pad as 'n program; op macOS lees dscacheutil -q host -a name example.com die geskoopde resolvers wat scutil --dns lys. 'n Kaal dig doen dit nie: dit lees /etc/resolv.conf en slaan per-skakel keuse oor, so dit kan van Pi-hole antwoord terwyl elke program die gestuurde resolver gebruik, wat die presiese fout is waarvoor hierdie lys bestaan. Hou dig @192.168.1.53 vir die toets van een spesifieke bediener.

2. Bevestig wie die antwoord uitdeel

Toewysing kom van wat ook al DHCP beantwoord. Op dnsmasq is dit 'n enkele reël, dhcp-option=6,192.168.1.53; op 'n router se webkoppelvlak is dit die DNS-veld in die LAN DHCP-afdeling. Kliënte moet hernu voordat hulle dit sien. 'n Toestel wat al dae lank aan is, hou steeds die ou huur, en 'n toestel met 'n handmatig getikte resolver hou dit vir ewig. Hernu op 'n toetskliënt in plaas daarvan om voortplanting te aanvaar.

IPv6 is die helfte wat misgekyk word. Router-advertensies kan hul eie DNS-bediener dra (RDNSS), en op OpenWrt is dit odhcpd se ra_dns-opsie; 'n kliënt wat IPv6 verkies, gebruik daardie bediener terwyl die DHCPv4-opsie wat jy pas gestel het, onbenut bly. As jy nie gereed is om IPv6-DNS te bedien nie, wis slegs die DNS-advertensie: ra_dns in odhcpd, of die RDNSS-opsie in wat ook al router-advertensies beantwoord. Om die hele advertensie af te skakel, verwyder ook IPv6-adressering van die LAN, wat 'n veel groter verandering is as die een wat jy bedoel het om te maak, terwyl die wis van net die DNS-opsie adressering ongeskonde hou en die ontbrekende RDNSS in 'n pakketopname sigbaar maak.

3. Bewys dat die navraag Pi-hole bereik

'n Navraag van die Pi bewys niks oor die netwerkpad nie. Voer dit vanaf die kliënt uit en lees die antwoordkode:

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

'n Tydverstrekking dui op filtering of op 'n roete; REFUSED dui op 'n toegangsreël; SERVFAIL dui op die opstroomresolver agter Pi-hole; 'n korrekte antwoord wat nooit in die navraaglog verskyn nie, beteken die kliënt het iets anders gevra. Kontroleer UDP en TCP 53, want groot antwoorde en sommige resolvers val terug op TCP, en publiseer albei wanneer Pi-hole in 'n houer loop. 'n Kartering wat net UDP dek, lewer ongereelde foute wat soos pakketverlies lyk.

Pi-hole se luistermodus besluit dan of hy hoegenaamd antwoord. In slegs-plaaslike modus ignoreer dnsmasq navrae van bronne wat nie op 'n direk gekoppelde subnet is nie, wat presies is hoe 'n kliënt agter 'n ander router of een wat deur 'n tonnel aankom, lyk: die kliënt hou op reageer en die navraag bereik nooit die log nie. 'n Navraag wat wel as REFUSED verskyn, is eerder deur 'n toegangslys of 'n firewall-reël verwerp. Om alle oorspronge toe te laat is die gewone oplossing, gepaard met 'n firewall-reël wat poort 53 tot jou eie subnette beperk.

4. Kyk of die tonnel die antwoord vervang of ingesluk het

Dit is die geval waarin albei simptome wegkruip. Wanneer die router self 'n VPN-kliënt is, kan 'n gestuurde DNS-opsie die LAN-instelling oorskryf die oomblik wanneer die tonnel opkom: OpenVPN-bediener stuur dhcp-option DNS, en WireGuard-profiele dra hul eie DNS-inskrywing. Lees die router se effektiewe resolver met die tonnel op, nie voor dit nie, en ignoreer wat die LAN-bladsy beweer.

Die ander fout is bereikbaarheid eerder as vervanging. As die tonnel se toegelate voorvoegsels jou LAN-subnet insluit, het die router 'n roete wat navrae vir 192.168.1.53 in die tonnel instuur, en die oorkant het geen roete terug nie: navrae hou op reageer al is die tonnel gesond. Die omgekeerde gebeur wanneer Pi-hole op 'n subnet sit wat die tonnel nie dra nie. Vergelyk die adres met die tonnel se toegelate voorvoegsels en die router se roetebeheertabel voordat jy DNS weer aanraak.

Kies een oplossing eerder as albei. Hou óf die tonnel weg van DNS, met pull-filter ignore “dhcp-option DNS” op OpenVPN en geen LAN-voorvoegsel in AllowedIPs op WireGuard, óf aanvaar die gestuurde resolver en gee plaaslike filtering vir kliënte agter daardie router op. Watter een jy ook kies, skryf dit langs die profiel neer, want die volgende persoon wat dit wysig, sal die besluit anders per ongeluk omkeer.

5. Herhaal die toets ná 'n herverbinding

Vra vanaf 'n kliënt, bevestig dat daardie kliënt in Pi-hole se log verskyn, en los dan 'n domein op wat geblokkeer behoort te word en kyk of jy die blokkeringsantwoord kry eerder as die regte een. Verbind die tonnel weer en voer dieselfde twee navrae uit, want 'n resolver-instelling wat net tot die volgende herverbinding hou, is die gewone resultaat van 'n oplossing wat op die verkeerde laag toegepas is.

Laat 'n sekondêre resolverpad wat nie van die tonnel afhang nie, sodat 'n Pi-hole-onderbreking na ongefilterde blaai verswak eerder as na geen blaai hoegenaamd. Hou die vorige DHCP- en resolver-waardes totdat die toets twee keer slaag; 'n verandering wat die huishouding se internet tydens aandete breek, is baie moeiliker om te ontfout as een wat jy in 'n minuut kan terugdraai.