Por que a resposta DNS falha num firewall de borda VPN sem estado

O túnel está ativo, os clientes alcançam o host VPN, e o host não consegue resolver nada. As suas próprias consultas de saída deixam a interface de forma limpa, logo a falha está no caminho de volta: numa borda a montante que filtra o tráfego de entrada sem memória do que o host acabou de enviar. Permitir a porta do túnel não descreve de todo essa troca. A resposta a uma consulta DNS é um fluxo separado, e se a borda não tem estado, nada a autorizou a regressar.

As duas trocas não são a mesma troca

Escreva os tuples e o erro torna-se óbvio. A porta de destino do pedido passa a ser a porta de origem da resposta, que é o contrário do que a maioria imagina ao acrescentar uma regra de entrada para a porta 53:

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

Uma regra de entrada que exige a porta de destino 53 descreve tráfego endereçado a um ouvinte DNS a correr no host, o que é um serviço completamente diferente. Esses endereços são exemplos de documentação, e a porta de origem é escolhida pelo cliente para cada consulta, pelo que não é um valor que possa copiar para uma regra e esperar que continue a funcionar.

Borda sem estado versus firewall de host com estado

Um filtro de borda sem estado avalia cada pacote de entrada contra a sua lista de regras sem qualquer tabela de ligações por trás. Uma consulta de saída que saiu com sucesso não cria qualquer permissão para a resposta de entrada correspondente, porque o equipamento não tem qualquer registo de que alguma vez tenha havido uma consulta. Um firewall de host com estado é o oposto: o seu rastreio de ligações reconhece o tráfego de retorno de uma troca permitida e deixa-o passar sem uma regra para a resposta. Ambos os limites existem num caminho típico, e ambos têm de permitir o pacote pretendido.

A comparação importa porque os dois equipamentos falham de forma diferente. Um firewall com estado que nega a resposta registra um descarte; uma borda sem estado nega-a em silêncio, e é por isso que o host simplesmente esgota o tempo.

Construa a permissão em torno do protocolo, não de um número de porta

Restrinja a regra aos endereços reais do resolver, ao host de destino e à política de porta de receção que o produto suporta. Tenha também em conta o caminho TCP do DNS, porque uma resposta grande ou um recuo por truncamento desloca a troca para TCP e uma regra apenas para UDP não a cobrirá. Se a borda suportar inspeção com estado para um fluxo definido, prefira-a a uma regra de resposta escrita à mão, porque o caminho com estado segue automaticamente as portas escolhidas pelo cliente.

Depois confirme qual produto no caminho filtra realmente o tráfego. Um âmbito de borda IPv4 documentado não estabelece uma política IPv6, e o tráfego interno do fornecedor pode nunca atravessar esse mesmo filtro.

Porque permitir qualquer porta de origem 53 não é uma correção

Uma regra que aceita tudo o que afirma ter a porta de origem 53 é uma regra que aceita o que um emissor escreve num campo de cabeçalho. O número da porta não autentica o emissor e não prova que a carga útil seja uma resposta válida, pelo que a regra alarga a exposição do host sem tornar a resolução mais fiável. Mantenha as restrições de origem e as verificações de resposta do próprio cliente, incluindo a aleatorização da porta de origem, em vez de as desativar para simplificar uma lista de acesso.

Se o resolver for um serviço que controla, restringi-lo aos seus endereços é suficiente. Se for um resolver público, limite aos endereços que aprovou e registe-os no comentário da regra.

Verifique no limite correto, na direção correta

Capture no host e na borda a mesma consulta, e compare os tuples em vez das contagens de pacotes. Uma consulta visível dos dois lados sem resposta visível do lado do host aponta para o filtro de entrada; uma consulta visível apenas do lado do host aponta para o encaminhamento ou para o próprio resolver. Repita com uma consulta TCP se tiver apenas permissão para UDP, porque é essa a lacuna que o primeiro teste não consegue ver.

Corrigir isto completa uma troca DNS de que o host realmente necessita. Não transforma o host num resolver público, não autoriza fluxos VPN reencaminhados nem prova que o DNS era a causa de algum problema de túnel não relacionado.