Pi-hole no bloquea los anuncios tras conectar la VPN: cinco comprobaciones

Los anuncios siguen apareciendo en un cliente, Pi-hole se declara sano y el túnel está activo, así que el instinto es enrutar el tráfico de ese cliente a través del Pi. Ese es el giro equivocado. El filtrado necesita las preguntas, no los paquetes, y un cliente cuyas consultas van al resolutor del proveedor sigue sin filtrar vaya donde vaya su tráfico. Recorra esta lista en orden y deténgase en el primer paso que falle, porque un paso posterior no puede decirle nada mientras uno anterior está roto.

1. Lea el resolutor que el cliente usa realmente

Pregunte al cliente, no al router. En Linux, resolvectl status imprime los servidores DNS por enlace y qué enlace gana; /etc/resolv.conf por sí solo suele ser un stub que apunta a 127.0.0.53. En Windows, ipconfig /all lista los servidores proporcionados por DHCP por adaptador, y en macOS scutil --dns muestra lo mismo por ámbito. Si la respuesta no es la dirección de Pi-hole, tiene un problema de asignación y el paso 2 es donde vive.

Dos cosas vencen al resolutor del sistema incluso cuando está configurado correctamente. Los navegadores con su propio DNS seguro (la opción “Use secure DNS” de Chrome, el network.trr.mode de Firefox) envían consultas por HTTPS a un resolutor público y nunca abren el puerto 53. Y un cliente VPN en el propio cliente puede instalar un servidor DNS en su interfaz de túnel con un dominio de enrutamiento ~., lo que hace que ese enlace sea autoritativo para cada nombre.

Pruebe el camino que toman las aplicaciones, no el que toma una herramienta de depuración. resolvectl query example.com muestra qué enlace respondió, y getent hosts example.com pasa por el mismo camino NSS que una aplicación; en macOS, dscacheutil -q host -a name example.com lee los resolutores por ámbito que lista scutil --dns. Un dig desnudo no hace esto: lee /etc/resolv.conf y se salta la selección por enlace, así que puede responder desde Pi-hole mientras cada aplicación usa el resolutor empujado, y ese es exactamente el fallo para el que existe esta lista. Reserve dig @192.168.1.53 para probar un servidor concreto.

2. Confirme quién reparte la respuesta

La asignación viene de lo que responda a DHCP. En dnsmasq es una sola línea, dhcp-option=6,192.168.1.53; en la interfaz web de un router es el campo DNS de la sección DHCP de la LAN. Los clientes tienen que renovar antes de verlo. Un dispositivo que lleva días encendido sigue conservando la concesión antigua, y un dispositivo con un resolutor escrito a mano la conserva para siempre. Renueve en un cliente de prueba en lugar de suponer la propagación.

IPv6 es la mitad que se pasa por alto. Los anuncios del router pueden llevar su propio servidor DNS (RDNSS), y en OpenWrt eso es la opción ra_dns de odhcpd; un cliente que prefiere IPv6 usa ese servidor mientras la opción DHCPv4 que acaba de configurar queda sin usar. Si no está listo para servir DNS por IPv6, borre solo el anuncio de DNS: ra_dns en odhcpd, o la opción RDNSS en lo que responda a los anuncios del router. Desactivar todo el anuncio también quita el direccionamiento IPv6 de la LAN, que es un cambio mucho mayor que el que pretendía, mientras que borrar solo la opción DNS mantiene el direccionamiento intacto y hace visible el RDNSS que falta en una captura de paquetes.

3. Demuestre que la consulta llega a Pi-hole

Una consulta desde el Pi no demuestra nada sobre el camino de red. Ejecútela desde el cliente y lea el código de respuesta:

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

Un tiempo de espera apunta al filtrado o a una ruta; REFUSED apunta a una regla de acceso; SERVFAIL apunta al resolutor superior que hay detrás de Pi-hole; una respuesta correcta que nunca aparece en el registro de consultas significa que el cliente preguntó otra cosa. Compruebe UDP y TCP 53, porque las respuestas grandes y algunos resolutores caen a TCP, y publique ambos cuando Pi-hole se ejecute en un contenedor. Una asignación que solo cubre UDP produce fallos intermitentes que parecen pérdida de paquetes.

Después, el modo de escucha de Pi-hole decide si responde siquiera. En modo solo local, dnsmasq ignora las consultas de orígenes que no están en una subred conectada directamente, que es exactamente el aspecto de un cliente detrás de otro router o que llega por un túnel: el cliente agota el tiempo y la consulta nunca llega al registro. Una consulta que sí aparece como REFUSED fue rechazada por una lista de acceso o por una regla de cortafuegos. Permitir todos los orígenes es la solución habitual, junto con una regla de cortafuegos que limite el puerto 53 a sus propias subredes.

4. Compruebe si el túnel sustituyó o se tragó la respuesta

Este es el caso en el que se esconden ambos síntomas. Cuando el router es a su vez un cliente VPN, una opción DNS empujada puede anular la configuración de la LAN en el momento en que se levanta el túnel: los servidores OpenVPN empujan dhcp-option DNS, y los perfiles de WireGuard llevan su propia entrada DNS. Lea el resolutor efectivo del router con el túnel levantado, no antes, e ignore lo que afirme la página de la LAN.

El otro fallo es de accesibilidad, no de sustitución. Si los prefijos permitidos del túnel incluyen su subred de LAN, el router tiene una ruta que envía las consultas de 192.168.1.53 dentro del túnel, y el otro extremo no tiene ruta de vuelta: las consultas agotan el tiempo aunque el túnel esté sano. Lo contrario ocurre cuando Pi-hole está en una subred que el túnel no transporta. Compare la dirección con los prefijos permitidos del túnel y la tabla de rutas del router antes de volver a tocar el DNS.

Elija una solución, no ambas. O mantenga el túnel lejos del DNS — con pull-filter ignore “dhcp-option DNS” en OpenVPN y sin prefijo de LAN en AllowedIPs en WireGuard —, o acepte el resolutor empujado y renuncie al filtrado local para los clientes detrás de ese router. Elija lo que elija, anótelo junto al perfil, porque la siguiente persona que lo edite, de lo contrario, invertirá la decisión por accidente.

5. Repita la prueba tras una reconexión

Consulte desde un cliente, confirme que ese cliente aparece en el registro de Pi-hole, luego resuelva un dominio que debería bloquearse y compruebe que obtiene la respuesta de bloqueo en lugar de la real. Reconecte el túnel y ejecute las mismas dos consultas, porque un ajuste de resolutor que solo aguanta hasta la próxima reconexión es el resultado habitual de una corrección aplicada en la capa equivocada.

Deje un camino de resolutor secundario que no dependa del túnel, para que una caída de Pi-hole degenere en navegación sin filtrar en lugar de ninguna navegación. Mantenga los valores anteriores de DHCP y del resolutor hasta que la prueba pase dos veces; un cambio que rompe el internet de la casa a la hora de cenar es mucho más difícil de depurar que uno que puede revertir en un minuto.