Por que falla a resposta DNS nun cortalumes perimetral de VPN sen estado

O túnel está activo, os clientes chegan ao servidor VPN e o servidor non pode resolver nada. As súas propias consultas saíntes abandonan a interface limpiamente, así que o fallo está no camiño de volta: nun perímetro superior que filtra o tráfico entrante sen memoria do que o servidor acaba de enviar. Permitir o porto do túnel non describe en absoluto ese intercambio. A resposta a unha consulta DNS é un fluxo aparte, e se o perímetro non ten estado, nada a autorizou a volver.

Os dous intercambios non son o mesmo intercambio

Escriba as tuplas e o erro faise obvio. O porto de destino da petición convértese no porto de orixe da resposta, que é o contrario do que a maioría imaxina cando engade unha regra entrante para o porto 53:

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

Unha regra entrante que esixe o porto de destino 53 describe tráfico dirixido a un escoitador DNS que se executa no servidor, o que é un servizo completamente distinto. Eses enderezos son exemplos de documentación, e o porto de orixe escolleuno o cliente para cada consulta, así que non é un valor que poida copiar nunha regra e esperar que siga funcionando.

Perímetro sen estado fronte a cortalumes de servidor con estado

Un filtro perimetral sen estado avalía cada paquete entrante contra a súa lista de regras sen ningunha táboa de conexións detrás. Unha consulta saínte que marchou correctamente non crea ningún permiso para a súa resposta entrante, porque o dispositivo non ten rexistro de que algunha vez houbese unha consulta. Un cortalumes de servidor con estado é o contrario: o seu seguimento de conexións recoñece o tráfico de retorno dun intercambio permitido e déixao pasar sen unha regra para a resposta. Ambos os límites existen nunha ruta típica, e ambos teñen que permitir o paquete previsto.

A comparación importa porque os dous dispositivos fallan de forma distinta. Un cortalumes con estado que denega a resposta rexistra un descarte; un perímetro sen estado denégaa en silencio, e por iso o servidor simplemente esgota o tempo.

Constrúa o permiso arredor do protocolo, non dun número de porto

Limite a regra aos enderezos reais do resolutor, ao servidor de destino e á política de porto de recepción que admite o produto. Teña tamén presente a ruta TCP de DNS, porque unha resposta grande ou un retroceso por truncamento traslada o intercambio a TCP e unha regra só para UDP non o cubrirá. Se o perímetro admite inspección con estado para un fluxo definido, prefíraa a unha regra de resposta escrita á man, porque a ruta con estado segue automaticamente os portos que escolle o cliente.

Despois confirme que produto da ruta filtra realmente o tráfico. Un ámbito perimetral IPv4 documentado non establece unha política IPv6, e o tráfico interno do provedor pode non atravesar nunca ese mesmo filtro.

Por que permitir calquera porto de orixe 53 non é unha solución

Unha regra que acepta calquera cousa que afirme ter o porto de orixe 53 é unha regra que acepta o que un emisor escriba nun campo de cabeceira. O número de porto non autentica o emisor nin demostra que a carga útil sexa unha resposta válida, así que a regra amplía a exposición do servidor sen facer a resolución máis fiable. Manteña as restricións de orixe e as comprobacións de resposta do propio cliente, incluída a aleatorización do porto de orixe, en lugar de desactivalas para simplificar unha lista de acceso.

Se o resolutor é un servizo que vostede controla, restrinxilo aos seus enderezos é suficiente. Se é un resolutor público, limite ás direccións que aprobou e anóteas no comentario da regra.

Verifique no límite correcto, na dirección correcta

Capture no servidor e no perímetro a mesma consulta, e compare as tuplas en lugar dos recontos de paquetes. Unha consulta visible nos dous lados sen resposta visible no lado do servidor apunta ao filtro entrante; unha consulta visible só no lado do servidor apunta ao encamiñamento ou ao propio resolutor. Repita cunha consulta TCP se só ten permiso para UDP, porque esa é a lagoa que a primeira proba non pode ver.

Corrixir isto completa un intercambio DNS que o servidor realmente necesita. Non converte o servidor nun resolutor público, non autoriza fluxos VPN reenviados nin demostra que DNS fose a causa dalgún problema de túnel non relacionado.