¿Se usa de verdad el DNS de tu VPN? Captura el puerto 53 y compruébalo

Pregunta a la mayoría qué hace un cliente de VPN con el DNS y dirán que configura el resolutor, así que las consultas viajan dentro del túnel. El empuje es real; la suposición de que se convierte en una consulta, no. Entre una opción empujada y un paquete en el cable hay tres etapas, y cada una falla de forma independiente en maneras que todas parecen un servidor DNS roto. Por eso una página de prueba de fugas y un navegador que funciona pueden discrepar sobre la misma máquina en el mismo momento.

Una opción empujada no es una consulta

La primera etapa es que el servidor ofrece ajustes, por ejemplo una opción DNS empujada que nombra un resolutor dentro del túnel. La segunda etapa es que el cliente aplica esos ajustes a una interfaz. La tercera etapa es que una aplicación envíe realmente una consulta a esa dirección. Un fallo en la segunda etapa deja la opción visible en el registro de conexión mientras la lista de resolutores sigue sin cambios, y un fallo en la tercera etapa deja una lista de resolutores perfectamente correcta sin usar.

La mayoría del diagnóstico funde esas tres en una y culpa al servidor VPN, que suele ser la única parte que puede demostrar que hizo lo suyo. Lee en cambio el estado real del resolutor del cliente y luego observa salir una consulta. Esas dos observaciones separan la configuración del enrutamiento y de la política, y cuestan unos cinco minutos. Guarda las capturas, porque el siguiente ingeniero quiere el antes y el después, no una descripción.

Comprueba qué guarda realmente la interfaz

En Linux el resolutor del sistema puede ser el archivo simple, NetworkManager o systemd-resolved, y cuál de ellos lo posee decide dónde aterriza un servidor empujado. Un proceso OpenVPN de línea de comandos no actualiza el resolutor del sistema por sí solo, así que la integración documentada es un script up/down o un gestor de conexiones que ya sabe aplicar los ajustes. Ejecutar ambos es una forma eficaz de crear una carrera.

resolvectl status
cat /etc/resolv.conf

En Windows la lista es por adaptador, así que el adaptador del túnel puede tener los servidores internos mientras el adaptador físico conserva los locales y gana para algunos nombres. Compara ambos adaptadores en lugar del que supones activo.

Sigue una consulta fuera de la máquina

Captura ambas interfaces a la vez y luego resuelve un nombre que debería usar el resolutor interno. Ese par de capturas responde lo que ninguna salida de configuración puede.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Una consulta que aparece en la interfaz física y nunca en el túnel significa que el cliente eligió el resolutor equivocado. Una consulta en ninguna de las dos significa que la aplicación respondió de la caché, preguntó a un stub que escucha en loopback o usó un resolutor cifrado cuyo tráfico nunca aparece como puerto 53. Captura también las respuestas, no solo las consultas, porque una consulta que sale por el túnel con una respuesta de una dirección pública es un fallo distinto a que no llegue ninguna respuesta.

El cortafuegos que solo acepta su propio DNS

Los clientes comerciales a veces instalan sus propias cadenas de filtrado. Un patrón documentado permite DNS hacia el resolutor propio del cliente y descarta todo el tráfico UDP restante del puerto 53 que intenta salir de una interfaz que no es loopback, incluido el tráfico que el usuario enrutó deliberadamente a otro sitio. Las consultas del demonio desaparecen sin rastro, lo que se lee como un fallo del resolutor en vez de un filtro.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Si una regla de descarte se evalúa antes de tu excepción, una regla añadida al final nunca se alcanza, así que insértala en la primera posición y limita el destino al resolutor que realmente pretendes.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Esa excepción es de diagnóstico y no de política. Si la regla del proveedor es deliberada, la reparación admitida es configurar el cliente para permitir ese resolutor y registrar la decisión, porque una regla insertada no sobrevivirá a la próxima actualización del cliente.

Por qué una página de fugas demuestra menos de lo que parece

Lo que muestra una página de prueba de fugas es el resolutor que habló con el operador de la prueba, no el que consultó tu máquina. Un reenviador local que hace recursión hacia fuera pone su propia dirección de salida en esa página, y las consultas cifradas pueden dejar la página completamente en blanco. Ambos resultados se leen mal, uno como fuga y el otro como garantía, y ninguna de las dos lecturas se sigue de la observación.

La evidencia defendible es la captura: interfaz, dirección de destino, respuesta y marca de tiempo. Toma una antes de que suba el túnel y otra después, y compáralas la próxima vez que falle un nombre. Ese par también dice a la siguiente persona si el fallo era de resolución, de enrutamiento o de la política de acceso del propio resolutor.