Por qué falla la respuesta DNS en un cortafuegos perimetral de VPN sin estado

El túnel está activo, los clientes llegan al host VPN y el host no puede resolver nada. Sus propias consultas salientes abandonan la interfaz limpiamente, así que el fallo está en el camino de vuelta: en un perímetro aguas arriba que filtra el tráfico entrante sin memoria de lo que el host acaba de enviar. Permitir el puerto del túnel no describe en absoluto ese intercambio. La respuesta a una consulta DNS es un flujo aparte, y si el perímetro no tiene estado, nada la ha autorizado a volver.

Los dos intercambios no son el mismo intercambio

Escriba las tuplas y el error se vuelve obvio. El puerto de destino de la petición se convierte en el puerto de origen de la respuesta, que es lo contrario de lo que la mayoría imagina cuando añade una regla entrante para el puerto 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Una regla entrante que exige el puerto de destino 53 describe tráfico dirigido a un escucha DNS que se ejecuta en el host, que es un servicio completamente distinto. Esas direcciones son ejemplos de documentación, y el puerto de origen lo elige el cliente para cada consulta, así que no es un valor que pueda copiar en una regla y esperar que siga funcionando.

Perímetro sin estado frente a cortafuegos de host con estado

Un filtro perimetral sin estado evalúa cada paquete entrante contra su lista de reglas sin ninguna tabla de conexiones detrás. Una consulta saliente que se marchó correctamente no crea ningún permiso para su respuesta entrante, porque el dispositivo no tiene registro de que alguna vez hubiera una consulta. Un cortafuegos de host con estado es lo contrario: su seguimiento de conexiones reconoce el tráfico de retorno de un intercambio permitido y lo deja pasar sin una regla para la respuesta. Ambos límites existen en una ruta típica, y ambos tienen que permitir el paquete previsto.

La comparación importa porque los dos dispositivos fallan de forma distinta. Un cortafuegos con estado que deniega la respuesta registra un descarte; un perímetro sin estado la deniega en silencio, y por eso el host simplemente agota el tiempo.

Construya el permiso en torno al protocolo, no a un número de puerto

Limite la regla a las direcciones reales del resolutor, al host de destino y a la política de puerto de recepción que admite el producto. Tenga también presente la ruta TCP de DNS, porque una respuesta grande o un retroceso por truncamiento traslada el intercambio a TCP y una regla solo para UDP no lo cubrirá. Si el perímetro admite inspección con estado para un flujo definido, prefíerala a una regla de respuesta escrita a mano, porque la ruta con estado sigue automáticamente los puertos que elige el cliente.

Después confirme qué producto de la ruta filtra realmente el tráfico. Un ámbito perimetral IPv4 documentado no establece una política IPv6, y el tráfico interno del proveedor puede no atravesar nunca ese mismo filtro.

Por qué permitir cualquier puerto de origen 53 no es una solución

Una regla que acepta cualquier cosa que afirme tener el puerto de origen 53 es una regla que acepta lo que un emisor escriba en un campo de cabecera. El número de puerto no autentica al emisor ni demuestra que la carga útil sea una respuesta válida, así que la regla amplía la exposición del host sin hacer la resolución más fiable. Mantenga las restricciones de origen y las comprobaciones de respuesta del propio cliente, incluida la aleatorización del puerto de origen, en lugar de desactivarlas para simplificar una lista de acceso.

Si el resolutor es un servicio que usted controla, restringirlo a sus direcciones es suficiente. Si es un resolutor público, limite a las direcciones que haya aprobado y anótelas en el comentario de la regla.

Verifique en el límite correcto, en la dirección correcta

Capture en el host y en el perímetro la misma consulta, y compare las tuplas en lugar de los recuentos de paquetes. Una consulta visible en ambos lados sin respuesta visible en el lado del host apunta al filtro entrante; una consulta visible solo en el lado del host apunta al enrutamiento o al propio resolutor. Repita con una consulta TCP si solo tiene permiso para UDP, porque esa es la laguna que la primera prueba no puede ver.

Corregir esto completa un intercambio DNS que el host realmente necesita. No convierte al host en un resolutor público, no autoriza flujos VPN reenviados ni demuestra que DNS fuera la causa de algún problema de túnel no relacionado.