Pi-hole nu blochează reclamele după conectarea VPN: cinci verificări

Reclamele apar în continuare pe un client, Pi-hole raportează că este sănătos, iar tunelul este activ, așa că instinctul este să direcționezi traficul acelui client prin Pi. Este virajul greșit. Filtrarea are nevoie de întrebări, nu de pachete, iar un client ale cărui interogări merg la resolverul furnizorului rămâne nefiltrat oriunde ar curge traficul său. Parcurge această listă în ordine și oprește-te la primul pas care eșuează, pentru că un pas ulterior nu-ți poate spune nimic cât timp unul anterior este stricat.

1. Citește resolverul pe care clientul îl folosește efectiv

Întreabă clientul, nu routerul. În Linux resolvectl status afișează serverele DNS pe legătură și care legătură câștigă; /etc/resolv.conf singur este de obicei un stub care indică 127.0.0.53. În Windows ipconfig /all listează serverele furnizate de DHCP pe adaptor, iar în macOS scutil --dns arată același lucru pe domeniu. Dacă răspunsul nu este adresa Pi-hole, ai o problemă de atribuire și pasul 2 este locul unde se află.

Două lucruri înving resolverul sistemului chiar și când este configurat corect. Browserele cu DNS securizat propriu (opțiunea “Use secure DNS” din Chrome, network.trr.mode din Firefox) trimit interogări prin HTTPS către un resolver public și nu deschid niciodată portul 53. Și un client VPN pe clientul însuși poate instala un server DNS pe interfața sa de tunel cu un domeniu de rutare ~., ceea ce face acea legătură autoritară pentru fiecare nume.

Testează calea pe care o iau aplicațiile, nu calea pe care o ia un instrument de depanare. resolvectl query example.com arată care legătură a răspuns, iar getent hosts example.com trece prin aceeași cale NSS ca o aplicație; în macOS dscacheutil -q host -a name example.com citește resolvereii pe domeniu pe care îi listează scutil --dns. Un dig gol nu face asta: citește /etc/resolv.conf și sare peste selecția pe legătură, așa că poate răspunde din Pi-hole în timp ce fiecare aplicație folosește resolverul împins, iar aceasta este exact defecțiunea pentru care există această listă. Păstrează dig @192.168.1.53 pentru a testa un server anume.

2. Confirmă cine distribuie răspunsul

Atribuirea vine de la ceea ce răspunde la DHCP. În dnsmasq este o singură linie, dhcp-option=6,192.168.1.53; în interfața web a unui router este câmpul DNS din secțiunea DHCP a LAN-ului. Clienții trebuie să reînnoiască înainte de a-l vedea. Un dispozitiv pornit de zile întregi păstrează încă bailmentul vechi, iar un dispozitiv cu resolver scris manual îl păstrează pentru totdeauna. Reînnoiește pe un client de test în loc să presupui propagarea.

IPv6 este jumătatea care este omisă. Anunțurile routerului pot transporta propriul server DNS (RDNSS), iar în OpenWrt aceasta este opțiunea ra_dns din odhcpd; un client care preferă IPv6 folosește acel server în timp ce opțiunea DHCPv4 tocmai setată rămâne nefolosită. Dacă nu ești pregătit să servești DNS prin IPv6, șterge doar anunțul DNS: ra_dns în odhcpd, sau opțiunea RDNSS în orice răspunde la anunțurile routerului. Oprirea întregului anunț elimină și adresarea IPv6 din LAN, ceea ce este o schimbare mult mai mare decât cea intenționată, în timp ce ștergerea doar a opțiunii DNS păstrează adresarea intactă și face RDNSS-ul lipsă vizibil într-o captură de pachete.

3. Demonstrează că interogarea ajunge la Pi-hole

O interogare de pe Pi nu demonstrează nimic despre calea de rețea. Rulează-o de pe client și citește codul de răspuns:

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

Un timeout indică filtrarea sau o rută; REFUSED indică o regulă de acces; SERVFAIL indică resolverul superior din spatele Pi-hole; un răspuns corect care nu apare niciodată în jurnalul de interogări înseamnă că clientul a întrebat altceva. Verifică UDP și TCP 53, pentru că răspunsurile mari și unii resolvere cad înapoi pe TCP, și publică ambele când Pi-hole rulează într-un container. O mapare care acoperă doar UDP produce eșecuri intermitente care arată ca pierderea pachetelor.

Apoi modul de ascultare al Pi-hole decide dacă răspunde deloc. În modul doar local, dnsmasq ignoră interogările din surse care nu sunt într-o subrețea conectată direct, iar exact așa arată un client din spatele altui router sau care vine printr-un tunel: clientul expiră și interogarea nu ajunge niciodată în jurnal. O interogare care totuși apare ca REFUSED a fost respinsă de o listă de acces sau de o regulă de firewall. Permiterea tuturor surselor este soluția obișnuită, împreună cu o regulă de firewall care limitează portul 53 la propriile subrețele.

4. Verifică dacă tunelul a înlocuit sau a înghițit răspunsul

Acesta este cazul în care se ascund ambele simptome. Când routerul este el însuși un client VPN, o opțiune DNS împinsă poate suprascrie setarea LAN în momentul în care tunelul se ridică: serverele OpenVPN împing dhcp-option DNS, iar profilele WireGuard poartă propria intrare DNS. Citește resolverul efectiv al routerului cu tunelul activ, nu înainte, și ignoră ce afirmă pagina LAN.

Cealaltă defecțiune este accesibilitatea, nu înlocuirea. Dacă prefixele permise ale tunelului includ subrețeaua ta LAN, routerul are o rută care trimite interogările pentru 192.168.1.53 în tunel, iar cealaltă parte nu are rută de întoarcere: interogările expiră deși tunelul este sănătos. Opusul se întâmplă când Pi-hole stă într-o subrețea pe care tunelul nu o transportă. Compară adresa cu prefixele permise ale tunelului și cu tabela de rutare a routerului înainte de a atinge din nou DNS-ul.

Alege o corectură, nu ambele. Ori ții tunelul departe de DNS — cu pull-filter ignore “dhcp-option DNS” pe OpenVPN și fără prefix LAN în AllowedIPs pe WireGuard —, ori accepți resolverul împins și renunți la filtrarea locală pentru clienții din spatele acelui router. Orice ai alege, scrie-l lângă profil, pentru că următoarea persoană care îl editează va inversa altfel decizia din greșeală.

5. Repetă testul după o reconectare

Fă o interogare de pe un client, confirmă că acel client apare în jurnalul Pi-hole, apoi rezolvă un domeniu care ar trebui blocat și verifică dacă primești răspunsul de blocare în locul celui real. Reconectează tunelul și rulează aceleași două interogări, pentru că o setare de resolver care rezistă doar până la următoarea conectare este rezultatul obișnuit al unei corecturi aplicate în stratul greșit.

Lasă o cale secundară de resolver care nu depinde de tunel, astfel încât o cădere a Pi-hole să degenereze în navigare nefiltrată în loc de nicio navigare. Păstrează valorile anterioare de DHCP și resolver până când testul trece de două ori; o schimbare care strică internetul gospodăriei la cină este mult mai greu de depanat decât una pe care o poți anula într-un minut.