Permitir DNS solo a través de tu resolutor VPN: un recorrido paso a paso

Sigue una sola consulta de nombre desde el momento en que la escribes. El navegador pregunta al sistema operativo, el sistema operativo pregunta al resolutor que elige su política, y la consulta sale del dispositivo por alguna interfaz con algún transporte. Tu diseño de VPN dice que la respuesta debe venir de un resolutor concreto por una ruta concreta. La brecha entre esas dos afirmaciones es lo que configuras y luego impones.

Paso 1: nombra el resolutor y la ruta

Escribe tres cosas antes de tocar un cortafuegos: la dirección del resolutor, el protocolo y el puerto que esperas, y la interfaz por la que la consulta debe salir. Sin esa lista, una regla es una conjetura sobre el tráfico y no la ejecución de una decisión. Una VPN puede transportar datos de aplicaciones mientras el DNS sigue un arreglo aparte, y eso no es un error en sí mismo. Es lo que ocurre cuando nadie le ha dicho otra cosa al cliente.

Nombrar la ruta de forma explícita es la diferencia entre un diseño y un accidente. También te da algo que probar después, porque cada observación puede compararse con una expectativa escrita. Guarda esa lista en el ticket de cambio y no en la cabeza de alguien.

Paso 2: pon la política donde de verdad vive

La selección del resolutor pertenece al cliente: la configuración de red del sistema operativo, los ajustes propios del cliente VPN o una política de navegador gestionada. Ponla primero ahí, con el mecanismo que admite la plataforma, porque un cortafuegos no puede obligar a un cliente a elegir un resolutor que nunca le han mencionado. En un cliente con túnel dividido, di explícitamente qué dominios van al resolutor interno. En un parque gestionado, la política del navegador suele ser la única palanca para DoH, porque el navegador puede elegir su propio resolutor cifrado con independencia del ajuste del sistema.

Si te saltas esto y vas directo al cortafuegos, obtienes una regla que permite el resolutor correcto junto a un cliente que nunca lo usa. La regla parece correcta y los registros del resolutor siguen vacíos, una pareja desconcertante de depurar. Configura primero la elección y después impónla.

Paso 3: impón la ruta de forma estrecha

Ahora añade el permiso de red para la ruta permitida: la dirección del resolutor, el protocolo y el puerto, y la interfaz por la que debe salir. Mantén la regla limitada a ese resolutor en lugar de permitir todo el DNS saliente. Las tres rutas de abajo son las que puede tomar un cliente moderno, y solo la primera queda cubierta por una regla del puerto 53.

Bloquear DoH y DoT es legítimo; suponer que una regla del puerto 53 ya los ha bloqueado no lo es. Un navegador con DoH resuelve nombres por una ruta que tu regla nunca describió, y una aplicación que trae su propio resolutor hace lo mismo. Escribe cada ruta que pretendes permitir y cada una que pretendes rechazar. Una regla que no nombra una ruta no ha decidido nada sobre ella.

Paso 4: sigue los nombres privados y públicos

El DNS dividido envía a propósito solo espacios de nombres privados a un resolutor interno mientras los nombres públicos van a otro sitio, así que más de un resolutor en el diseño no es una fuga. La fuga es una consulta que debía ir a tu resolutor y llega a otro lugar, o una ruta prevista inalcanzable que hace que el cliente vuelva atrás en silencio. Esos dos casos son los que hay que buscar. Sigue un nombre interno y un nombre público bajo la política prevista y anota qué resolutor respondió a cada uno.

Un sitio de prueba que informa de tu resolutor es una pista, no una prueba, porque solo ve las consultas que le llegaron. Captura la consulta en el lado del cliente cuando necesites saber qué ruta tomó de verdad, y compara ambas observaciones. Cuando no coinciden, has encontrado un retroceso que nadie documentó.

Si la dirección del resolutor es correcta pero no es accesible, el problema está en el enrutamiento o el filtrado y no en la política. Sigue la consulta hasta esa dirección y confirma que la respuesta vuelve por la interfaz esperada antes de cambiar cualquier ajuste del resolutor.

Paso 5: mantén una vía de vuelta

Antes de endurecer el acceso DNS en la puerta de enlace, confirma un método de recuperación que no dependa de la resolución de nombres. Un resolutor roto hace más difícil llegar a cualquier herramienta de reparación, incluidas las que usarías para deshacer el cambio. Mantén una consola local o una vía fuera de banda abierta hasta que la nueva política esté probada. Quítala solo cuando la política haya sobrevivido a una reconexión.

Tras una reconexión o una actualización de la política del navegador, inspecciona de nuevo el estado efectivo, porque ambos pueden cambiar el resolutor sin cambiar tu regla. El requisito es un destinatario conocido y una ruta protegida para las consultas, no una etiqueta de resolutor tranquilizadora en una captura de pantalla. La especificación RFC 8484 de DNS over HTTPS es la referencia para la ruta cifrada que tu regla de puerto no ve.