Porque é que o DNS do próprio router contorna o túnel VPN?

As consultas dos clientes seguem o túnel, enquanto as consultas do próprio router saem pela WAN, e a regra de firewall que governa uma não tem qualquer efeito sobre a outra. O motivo não é um erro: um pedido reencaminhado e um pedido que o router gera por si são dois fluxos separados, e cada um é comparado com uma parte diferente da configuração. Capturar apenas a metade do cliente produz uma resposta confiante sobre um caminho que a segunda metade nunca usa. A correção é apontar deliberadamente o resolvedor do router e testar depois os dois caminhos em separado.

A que fluxo pertence realmente a captura de pacotes

Uma consulta envolve duas trocas. Um cliente da LAN envia uma consulta ao resolvedor do router, e esta chega como tráfego reencaminhado na interface LAN, pelo que uma rota de política ou uma regra NAT escrita para pacotes reencaminhados pode corresponder-lhe. Depois o router responde a partir da cache ou, em caso de falha, abre a sua própria consulta para um servidor a montante.

Essa segunda consulta tem o router como origem e como destino próprio, e a plataforma escolhe o seu caminho num bloco de configuração diferente. Ambas as trocas transportam o mesmo nome, e nenhuma é uma cópia da outra. Por isso, uma captura feita do lado da LAN prova para onde foi o pacote do cliente e não diz nada sobre o pacote de saída.

A verificação prática é observar os dois lados ao mesmo tempo. No router, liste o socket do resolvedor, consulte-o localmente e capture a interface WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Se a lista de sockets mostrar um ouvinte ligado ao endereço de loopback ou da LAN, o router está a responder localmente em vez de reencaminhar para outro anfitrião. A captura mostra então se a consulta a montante resultante sai pela interface do túnel ou pela WAN, e essa é a resposta que a regra de rota de política nunca daria.

Porque a rota de política nunca vê a segunda consulta

As regras de firewall são escritas para uma interface, uma origem, um destino e uma porta, e são avaliadas para os pacotes que atravessam o equipamento. Uma consulta que o router origina não atravessa nada, porque um processo local entrega-a diretamente à tabela de encaminhamento. Encaminhamento por política e NAT aplicam-se, portanto, apenas ao caminho reencaminhado, e é por isso que um conjunto de regras pode parecer completo e ainda assim deixar o DNS do router fora do túnel.

Esta distinção sobrevive a cada reescrita de firmware porque resulta do caminho do pacote e não de uma funcionalidade. Tudo o que o equipamento gera para si, sejam consultas do resolvedor, sincronização de hora, verificações de atualizações ou acesso a espelhos de pacotes, é de origem local e cai no mesmo ponto cego. É também por isso que um teste feito a partir de um portátil não prova nada sobre o router.

Onde o resolvedor do pfSense decide o seu próprio caminho a montante

O pfSense torna a separação visível. O tráfego dos clientes pode ser encaminhado por política através de um gateway VPN enquanto o tráfego do próprio firewall segue a definição de saída do resolvedor em vez das regras da LAN. Na interface web, essa definição encontra-se em Services > DNS Resolver > Outgoing Network Interfaces, e o seu valor é a lista de interfaces que o resolvedor pode usar para consultas a montante.

Nomear aí a interface do túnel, e apenas essa interface, é o que faz as consultas do próprio router seguirem o túnel. Deixada no valor predefinido, a definição escolhe uma saída da tabela de encaminhamento, que num anfitrião com WAN dupla ou VPN é muitas vezes a WAN.

Outros firmwares expõem a mesma decisão com outra etiqueta: uma lista de servidores a montante ligada a um endereço de origem, um modo apenas de reencaminhamento ou uma política de rotas documentada. A definição a procurar é sempre a que escolhe uma saída ou uma origem para consultas geradas localmente. A referência de configuração do resolvedor documenta essa opção para o pfSense e vale a pena ler antes da alteração.

Escolha o comportamento em caso de falha antes da definição

Quando o túnel cai, dois comportamentos são defensáveis: parar as consultas a montante para que nada escape, ou recorrer a um resolvedor aprovado num caminho conhecido. Ambos são políticas, e nenhum é o que se obtém por predefinição. Decida qual a rede precisa antes de tocar na lista de interfaces.

Fechar em caso de falha é mais fácil de defender, mas transforma uma queda do túnel numa queda de resolução de nomes para cada dispositivo atrás do router. A alternativa mantém o escritório utilizável, ao custo de uma troca a montante fora do túnel que tem de ser aceitável de propósito e não por acidente. Escreva a escolha, porque a próxima pessoa que vir um endereço de resolvedor fora da VPN vai lê-lo como uma fuga, a menos que uma nota diga o contrário. É essa nota que separa uma alternativa documentada de um achado sem explicação na revisão do próximo trimestre.

Dois casos complicam a decisão. Os nomes privados podem exigir um resolvedor interno que o túnel alcance, e um navegador ou aplicação com o seu próprio DNS cifrado pode contornar o router por completo, pelo que o resolvedor configurado não é sempre o que uma dada aplicação usa.

Teste ambos os caminhos e mantenha os resultados separados

Um teste de DNS no navegador responde a uma pergunta estreita: que resolvedores usou aquele navegador, nas condições desse teste. Não inventaria os dispositivos da rede e não consegue ver uma consulta que o router gerou para si. Trate o resultado como um dado e não como uma auditoria.

A partir de um cliente da LAN, peça ao router um nome público e depois um nome privado que só a sua zona interna deveria responder. Uma falha apenas na segunda consulta aponta para o reencaminhamento de nomes e não para o túnel:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Depois baixe o túnel e repita as duas consultas. Respostas recusadas significam que o resolvedor fecha em caso de falha; uma resposta bem-sucedida aponta para um resolvedor alternativo e para o caminho que usou. Compare isso com a nota que escreveu e com uma captura na interface WAN feita no mesmo minuto.

Mantenha as observações separadas no registo: a troca do cliente com o router, a troca do router com o servidor a montante e a configuração que decidiu a segunda. Uma alteração de encaminhamento posterior exercitará essa segunda troca sem aviso. Uma resposta que chega de outro sítio que não o ponto final da VPN não é uma fuga por si só; só se torna fuga quando a configuração escolheu esse caminho por acidente.