Por qué Pi-hole v6 ignora las consultas DNS de los clientes de WireGuard

Pi-hole v6 recibe una consulta DNS en el puerto 53 y después decide si el paquete que llegó puede ser respondido. En un host WireGuard esa segunda decisión suele ser la razón por la que un cliente recibe un tiempo de espera mientras el resolutor parece sano desde la LAN. El puerto está abierto, FTL se está ejecutando, y aun así no vuelve nada desde 10.90.0.1. Tres cosas interactúan antes de que salga una respuesta: dns.interface, dns.listeningMode y el cortafuegos delante de ambos.

El socket de escucha no decide quién recibe una respuesta

FTL abre escuchas UDP y TCP en el puerto 53. En la configuración predeterminada el socket suele ser wildcard, así que ss -lunp | grep :53 muestra 0.0.0.0:53 y [::]:53 tanto si se atiende a clientes VPN como si no. Un socket wildcard acepta el paquete y luego FTL aplica sus reglas de interfaz y de origen antes de responder. Por eso "el puerto está escuchando" demuestra muy poco sobre un cliente de túnel.

Lee la configuración en ejecución en lugar del archivo que creas activo. pihole-FTL --config dns.interface y pihole-FTL --config dns.listeningMode imprimen los valores efectivos, y pueden diferir del archivo del host cuando un contenedor, una variable de entorno o un gestor de despliegue es dueño del ajuste. La Referencia de configuración de Pi-hole FTL enumera los modos y cuál de ellos depende de la interfaz.

LOCAL pregunta qué subred, SINGLE pregunta qué interfaz

LOCAL, el modo predeterminado, responde consultas cuya dirección de origen pertenece a una subred configurada en una de las interfaces del host. Un wg0 sencillo con 10.90.0.1/24 pasa esa prueba, porque el cliente en 10.90.0.2 está dentro de la subred del túnel. Un cliente enrutado al otro lado de un par, o uno oculto tras NAT en un prefijo distinto, no la pasa aunque el paquete llegó por wg0, y no aparece ninguna consulta en el registro.

SINGLE cambia la pregunta. Acepta las consultas que llegan por la interfaz indicada en dns.interface, con loopback incluido, e ignora la subred de origen. Ese es el modo que sobrevive a una topología VPN encadenada o enrutada. Define ambas claves juntas, porque un modo sin interfaz indicada no es una instrucción completa:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND cambia el socket, y eso tiene un coste

BIND no filtra un socket wildcard; enlaza el puerto 53 solo a las direcciones que existen en la interfaz indicada, así que el núcleo rechaza los paquetes que llegan a otro sitio. Es más estricto que SINGLE y no es un sinónimo. El coste aparece al arrancar: si wg0 no está levantada cuando FTL inicia, puede que no haya dirección a la que enlazar y el resolutor puede funcionar sin escucha hasta que la interfaz aparezca y FTL se reinicie.

Elige BIND cuando controles el orden de arranque, por ejemplo una unidad de systemd ordenada después de la interfaz WireGuard, y cuando quieras que el núcleo descarte los paquetes perdidos antes de que FTL los vea. Elige SINGLE cuando el túnel va y viene, o cuando la interfaz la crea una herramienta que arranca después de FTL.

El cortafuegos es la segunda puerta

Un modo de FTL correcto sigue fallando si el cortafuegos del host descarta el puerto 53 en wg0. Admite el rango de origen de la VPN para ambos protocolos y mantén cerrado el lado de Internet. En nftables, con la cadena input existente en la tabla inet filter, las reglas se ven así:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Añade reglas IPv6 equivalentes si el túnel transporta IPv6, y ponlas antes de la política de descarte de la cadena. Si el host usa ufw o firewalld, expresa la misma coincidencia en ese gestor en vez de mezclar herramientas. No reenvíes el puerto 53 desde el router de Internet; los clientes deben alcanzar la dirección VPN del resolutor a través del túnel.

Dos rutas permanecen separadas. Las consultas de los clientes terminan en FTL. Las búsquedas propias de FTL hacia el upstream salen según la tabla de enrutamiento del host, que puede usar el túnel o no, así que un resolutor que responde pero no devuelve nada útil es un problema de upstream. La administración web y la API escuchan en sus propios puertos y necesitan su propia restricción.

Verifica la respuesta y el rechazo

Desde un cliente VPN, consulta la dirección del resolutor por ambos protocolos: dig @10.90.0.1 example.com y dig +tcp @10.90.0.1 example.com. Luego revisa el registro de consultas en la interfaz de administración para confirmar que FTL registró la consulta. Un tiempo de espera del cliente sin entrada en el registro apunta al cortafuegos o al filtro de interfaz; una entrada sin respuesta apunta a la resolución upstream.

Prueba la ruta negativa desde un host fuera de la VPN. dig @10.90.0.1 example.com debería agotarse, y ss -lunp en el resolutor no debería mostrar el puerto 53 enlazado a una dirección pública. Reinicia el servicio una vez, después reinicia el host y confirma que el resolutor sigue respondiendo cuando wg0 reaparece. Una consulta que solo funciona hasta el siguiente reinicio no es un cambio terminado.