Pi-hole no bloqueja els anuncis després de connectar la VPN: cinc comprovacions

Els anuncis encara es mostren en un client, Pi-hole es declara sa i el túnel està actiu, així que l'instint és encaminar el trànsit d'aquest client a través del Pi. Aquest és el gir equivocat. El filtratge necessita les preguntes, no els paquets, i un client les consultes del qual van al resolutor del proveïdor continua sense filtrar faci on faci el seu trànsit. Recorreu aquesta llista en ordre i atureu-vos al primer pas que falli, perquè un pas posterior no us pot dir res mentre un d'anterior està trencat.

1. Llegiu el resolutor que el client fa servir realment

Pregunteu al client, no al router. A Linux, resolvectl status mostra els servidors DNS per enllaç i quin enllaç guanya; /etc/resolv.conf per si sol sol ser un stub que apunta a 127.0.0.53. A Windows, ipconfig /all llista els servidors proporcionats pel DHCP per adaptador, i a macOS scutil --dns mostra el mateix per àmbit. Si la resposta no és l'adreça de Pi-hole, teniu un problema d'assignació i el pas 2 és on és.

Dues coses derroten el resolutor del sistema fins i tot quan està ben configurat. Els navegadors amb DNS segur propi (l'opció “Use secure DNS” del Chrome, el network.trr.mode del Firefox) envien consultes per HTTPS a un resolutor públic i mai obren el port 53. I un client VPN al mateix client pot instal·lar un servidor DNS a la seva interfície de túnel amb un domini d'encaminament ~., cosa que fa que aquest enllaç sigui autoritatiu per a tots els noms.

Proveu el camí que fan les aplicacions, no el camí que fa una eina de depuració. resolvectl query example.com mostra quin enllaç ha respost, i getent hosts example.com passa pel mateix camí NSS que una aplicació; a macOS, dscacheutil -q host -a name example.com llegeix els resolutors per àmbit que llista scutil --dns. Un dig nu no ho fa: llegeix /etc/resolv.conf i es salta la selecció per enllaç, així que pot respondre des de Pi-hole mentre cada aplicació fa servir el resolutor empès, i aquesta és exactament la fallada per a la qual existeix aquesta llista. Reserveu dig @192.168.1.53 per provar un servidor concret.

2. Confirmeu qui reparteix la resposta

L'assignació ve de qualsevol cosa que respongui al DHCP. A dnsmasq és una sola línia, dhcp-option=6,192.168.1.53; a la interfície web del router és el camp DNS de la secció DHCP de la LAN. Els clients han de renovar abans de veure-ho. Un dispositiu encès des de fa dies encara conserva la concessió antiga, i un dispositiu amb un resolutor escrit a mà la conserva per sempre. Renoveu en un client de prova en lloc de suposar la propagació.

IPv6 és la meitat que es descuida. Els anuncis del router poden portar el seu propi servidor DNS (RDNSS), i a OpenWrt això és l'opció ra_dns d'odhcpd; un client que prefereix IPv6 fa servir aquest servidor mentre l'opció DHCPv4 que acabeu de configurar queda sense usar. Si no esteu a punt per servir DNS per IPv6, esborreu només l'anunci DNS: ra_dns a odhcpd, o l'opció RDNSS en allò que respongui als anuncis del router. Desactivar tot l'anunci també treu l'adreçament IPv6 de la LAN, que és un canvi molt més gran que el que volíeu fer, mentre que esborrar només l'opció DNS manté l'adreçament intacte i fa visible el RDNSS que falta en una captura de paquets.

3. Demostreu que la consulta arriba a Pi-hole

Una consulta des del Pi no demostra res sobre el camí de xarxa. Executeu-la des del client i llegiu el codi de resposta:

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

Un temps d'espera assenyala el filtratge o una ruta; REFUSED assenyala una regla d'accés; SERVFAIL assenyala el resolutor superior darrere de Pi-hole; una resposta correcta que no apareix mai al registre de consultes vol dir que el client ha preguntat una altra cosa. Comproveu UDP i TCP 53, perquè les respostes grans i alguns resolutors passen a TCP, i publiqueu tots dos quan Pi-hole s'executa en un contenidor. Una assignació que només cobreix UDP produeix fallades intermitents que semblen pèrdua de paquets.

Aleshores el mode d'escolta de Pi-hole decideix si respon o no. En mode només local, dnsmasq ignora les consultes d'orígens que no són en una subxarxa connectada directament, que és exactament l'aspecte d'un client darrere d'un altre router o que arriba per un túnel: el client esgota el temps i la consulta no arriba mai al registre. Una consulta que sí que apareix com a REFUSED ha estat rebutjada per una llista d'accés o per una regla de tallafocs. Permetre tots els orígens és la solució habitual, acompanyada d'una regla de tallafocs que limita el port 53 a les vostres pròpies subxarxes.

4. Comproveu si el túnel ha substituït o s'ha empassat la resposta

Aquest és el cas on s'amaguen tots dos símptomes. Quan el router és ell mateix un client VPN, una opció DNS empesa pot substituir la configuració de la LAN en el moment que el túnel s'aixeca: els servidors OpenVPN empenyen dhcp-option DNS, i els perfils de WireGuard porten la seva pròpia entrada DNS. Llegiu el resolutor efectiu del router amb el túnel aixecat, no abans, i ignoreu el que afirma la pàgina de la LAN.

L'altra fallada és de connectivitat, no de substitució. Si els prefixos permesos del túnel inclouen la vostra subxarxa de LAN, el router té una ruta que envia les consultes per a 192.168.1.53 dins del túnel, i l'altre costat no té cap ruta de tornada: les consultes esgoten el temps tot i que el túnel està sa. El contrari passa quan Pi-hole és en una subxarxa que el túnel no transporta. Compareu l'adreça amb els prefixos permesos del túnel i la taula de rutes del router abans de tornar a tocar el DNS.

Trieu una solució, no totes dues. O manteniu el túnel lluny del DNS — amb pull-filter ignore “dhcp-option DNS” a OpenVPN i sense cap prefix de LAN a AllowedIPs a WireGuard —, o accepteu el resolutor empès i renuncieu al filtratge local per als clients darrere d'aquest router. Escolliu el que escolliu, escriviu-ho al costat del perfil, perquè la propera persona que l'editi no invertirà la decisió per accident.

5. Repetiu la prova després d'una reconnexió

Consulteu des d'un client, confirmeu que aquest client apareix al registre de Pi-hole, i després resolgueu un domini que hauria d'estar bloquejat i comproveu que obteniu la resposta de bloqueig en lloc de la real. Torneu a connectar el túnel i executeu les mateixes dues consultes, perquè una configuració de resolutor que només aguanta fins a la propera reconnexió és el resultat habitual d'una solució aplicada a la capa equivocada.

Deixeu un camí de resolutor secundari que no depengui del túnel, perquè una caiguda de Pi-hole degradi la navegació a sense filtrar en lloc de deixar-la sense navegació. Manteniu els valors anteriors de DHCP i de resolutor fins que la prova passi dues vegades; un canvi que trenca la internet de la casa a l'hora de sopar és molt més difícil de depurar que un que podeu revertir en un minut.