Pi-hole non bloquea os anuncios tras conectar a VPN: cinco comprobacións

Os anuncios seguen aparecendo nun cliente, Pi-hole declárase san e o túnel está activo, así que o instinto é encamiñar o tráfico dese cliente a través do Pi. Ese é o xiro equivocado. O filtrado necesita as preguntas, non os paquetes, e un cliente cuxas consultas van ao resolutor do provedor segue sen filtrar vaia onde vaia o seu tráfico. Percorra esta lista en orde e detéñase no primeiro paso que falla, porque un paso posterior non pode dicirlle nada mentres un anterior está roto.

1. Lea o resolutor que o cliente usa realmente

Pregunte ao cliente, non ao router. En Linux, resolvectl status imprime os servidores DNS por ligazón e que ligazón gaña; /etc/resolv.conf por si só adoita ser un stub que apunta a 127.0.0.53. En Windows, ipconfig /all lista os servidores proporcionados por DHCP por adaptador, e en macOS scutil --dns mostra o mesmo por ámbito. Se a resposta non é o enderezo de Pi-hole, ten un problema de asignación e o paso 2 é onde está.

Dúas cousas derrotan o resolutor do sistema mesmo cando está configurado correctamente. Os navegadores co seu propio DNS seguro (a opción “Use secure DNS” de Chrome, o network.trr.mode de Firefox) envían consultas por HTTPS a un resolutor público e nunca abren o porto 53. E un cliente VPN no propio cliente pode instalar un servidor DNS na súa interface de túnel cun dominio de encamiñamento ~., o que fai que esa ligazón sexa autoritativa para cada nome.

Probe o camiño que toman as aplicacións, non o que toma unha ferramenta de depuración. resolvectl query example.com mostra que ligazón respondeu, e getent hosts example.com pasa polo mesmo camiño NSS que unha aplicación; en macOS, dscacheutil -q host -a name example.com le os resolutores por ámbito que lista scutil --dns. Un dig espido non fai isto: le /etc/resolv.conf e salta a selección por ligazón, así que pode responder desde Pi-hole mentres cada aplicación usa o resolutor empurrado, e ese é exactamente o fallo para o que existe esta lista. Reserve dig @192.168.1.53 para probar un servidor concreto.

2. Confirme quen reparte a resposta

A asignación vén do que responda a DHCP. En dnsmasq é unha soa liña, dhcp-option=6,192.168.1.53; na interface web dun router é o campo DNS da sección DHCP da LAN. Os clientes teñen que renovar antes de velo. Un dispositivo que leva días acendido aínda conserva a concesión antiga, e un dispositivo cun resolutor escrito a man consérvaa para sempre. Renove nun cliente de proba en lugar de supoñer a propagación.

IPv6 é a metade que se pasa por alto. Os anuncios do router poden levar o seu propio servidor DNS (RDNSS), e en OpenWrt iso é a opción ra_dns de odhcpd; un cliente que prefire IPv6 usa ese servidor mentres a opción DHCPv4 que acaba de configurar queda sen usar. Se non está listo para servir DNS por IPv6, borre só o anuncio de DNS: ra_dns en odhcpd, ou a opción RDNSS no que responda aos anuncios do router. Desactivar todo o anuncio tamén quita o direccionamento IPv6 da LAN, que é un cambio moito maior que o que pretendía, mentres que borrar só a opción DNS mantén o direccionamento intacto e fai visible o RDNSS que falta nunha captura de paquetes.

3. Demostre que a consulta chega a Pi-hole

Unha consulta desde o Pi non demostra nada sobre o camiño de rede. Execútea desde o cliente e le o código de resposta:

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

Un tempo de espera apunta ao filtrado ou a unha ruta; REFUSED apunta a unha regra de acceso; SERVFAIL apunta ao resolutor superior detrás de Pi-hole; unha resposta correcta que nunca aparece no rexistro de consultas significa que o cliente preguntou outra cousa. Comprobe UDP e TCP 53, porque as respostas grandes e algúns resolutores caen a TCP, e publique ambos cando Pi-hole se execute nun contedor. Unha asignación que só cobre UDP produce fallos intermitentes que parecen perda de paquetes.

Despois, o modo de escoita de Pi-hole decide se responde sequera. En modo só local, dnsmasq ignora as consultas de orixes que non están nunha subrede conectada directamente, que é exactamente o aspecto dun cliente detrás doutro router ou que chega por un túnel: o cliente esgota o tempo e a consulta nunca chega ao rexistro. Unha consulta que si aparece como REFUSED foi rexeitada por unha lista de acceso ou por unha regra de devasado. Permitir todas as orixes é a solución habitual, xunto cunha regra de devasado que limita o porto 53 ás súas propias subredes.

4. Comprobe se o túnel substituíu ou tragou a resposta

Este é o caso no que se esconden ambos os síntomas. Cando o router é el mesmo un cliente VPN, unha opción DNS empurrada pode anular a configuración da LAN no momento en que se levanta o túnel: os servidores OpenVPN empurran dhcp-option DNS, e os perfís de WireGuard levan a súa propia entrada DNS. Lea o resolutor efectivo do router co túnel levantado, non antes, e ignore o que afirme a páxina da LAN.

O outro fallo é de accesibilidade, non de substitución. Se os prefixos permitidos do túnel inclúen a súa subrede de LAN, o router ten unha ruta que envía as consultas de 192.168.1.53 dentro do túnel, e o outro extremo non ten ruta de volta: as consultas esgotan o tempo aínda que o túnel estea san. O contrario ocorre cando Pi-hole está nunha subrede que o túnel non transporta. Compare o enderezo cos prefixos permitidos do túnel e a táboa de rutas do router antes de volver tocar o DNS.

Escolla unha solución, non ambas. Ou mantén o túnel lonxe do DNS — con pull-filter ignore “dhcp-option DNS” en OpenVPN e sen prefixo de LAN en AllowedIPs en WireGuard —, ou acepte o resolutor empurrado e renuncie ao filtrado local para os clientes detrás dese router. Escolla o que escolla, escríbao xunto ao perfil, porque a seguinte persoa que o edite inverterá a decisión por accidente se non o fai.

5. Repita a proba tras unha reconexión

Consulte desde un cliente, confirme que ese cliente aparece no rexistro de Pi-hole, despois resolva un dominio que debería estar bloqueado e comprobe que obtén a resposta de bloqueo en lugar da real. Reconecte o túnel e execute as mesmas dúas consultas, porque un axuste de resolutor que só aguanta até a próxima reconexión é o resultado habitual dunha corrección aplicada na capa equivocada.

Deixe un camiño de resolutor secundario que non dependa do túnel, para que unha caída de Pi-hole dexenere en navegación sen filtrar en lugar de ningunha navegación. Manteña os valores anteriores de DHCP e do resolutor ata que a proba pase dúas veces; un cambio que rompe a internet da casa á hora de cear é moito máis difícil de depurar que un que pode reverter nun minuto.