O DNS da sua VPN é realmente usado? Capture a porta 53 e veja

Pergunte à maioria das pessoas o que um cliente VPN faz com o DNS e elas dirão que define o resolver, então as consultas viajam dentro do túnel. O empurrão é real; a suposição de que ele se torna uma consulta não é. Entre uma opção empurrada e um pacote no fio há três estágios, e cada um falha de forma independente em maneiras que todas parecem um servidor DNS quebrado. É por isso que uma página de teste de vazamento e um navegador que funciona podem discordar sobre a mesma máquina no mesmo momento.

Uma opção empurrada não é uma consulta

O primeiro estágio é o servidor oferecer configurações, por exemplo uma opção DNS empurrada que nomeia um resolver dentro do túnel. O segundo estágio é o cliente aplicar essas configurações a uma interface. O terceiro estágio é uma aplicação realmente enviar uma consulta para esse endereço. Uma falha no segundo estágio deixa a opção visível no registro de conexão enquanto a lista de resolvers permanece inalterada, e uma falha no terceiro estágio deixa uma lista de resolvers perfeitamente correta sem uso.

A maior parte do diagnóstico funde esses três em um e culpa o servidor VPN, que costuma ser a única parte capaz de provar que fez a sua. Leia, em vez disso, o estado real do resolver do cliente e depois observe uma consulta sair. Essas duas observações separam a configuração do roteamento e da política, e custam cerca de cinco minutos. Guarde as capturas, porque o próximo engenheiro quer o antes e o depois, não uma descrição deles.

Verifique o que a interface realmente mantém

No Linux o resolver do sistema pode ser o arquivo simples, o NetworkManager ou o systemd-resolved, e qual deles o possui decide onde um servidor empurrado pousa. Um processo OpenVPN de linha de comando não atualiza o resolver do sistema sozinho, então a integração documentada é um script up/down ou um gerenciador de conexões que já sabe aplicar as configurações. Executar os dois é uma forma eficiente de criar uma corrida.

resolvectl status
cat /etc/resolv.conf

No Windows a lista é por adaptador, então o adaptador do túnel pode manter os servidores internos enquanto o adaptador físico fica com os locais e vence para alguns nomes. Compare os dois adaptadores em vez do que você supõe ativo.

Siga uma consulta para fora da máquina

Capture as duas interfaces ao mesmo tempo e depois resolva um nome que deveria usar o resolver interno. Esse par de capturas responde o que nenhuma saída de configuração consegue.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Uma consulta que aparece na interface física e nunca no túnel significa que o cliente escolheu o resolver errado. Uma consulta em nenhuma das duas significa que a aplicação respondeu do cache, perguntou a um stub à escuta em loopback ou usou um resolver cifrado cujo tráfego nunca aparece como porta 53. Capture também as respostas, não só as consultas, porque uma consulta que sai pelo túnel com resposta de um endereço público é uma falha diferente de nenhuma resposta chegando.

O firewall que aceita apenas o seu próprio DNS

Clientes comerciais às vezes instalam as suas próprias cadeias de filtragem. Um padrão documentado permite DNS para o resolver próprio do cliente e descarta todo o restante tráfego UDP na porta 53 que tenta sair de uma interface que não é loopback, incluindo tráfego que o usuário encaminhou deliberadamente para outro lugar. As consultas do daemon desaparecem sem rastro, o que se lê como falha do resolver e não como filtro.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Se uma regra de descarte for avaliada antes da sua exceção, uma regra anexada nunca é alcançada, então insira-a na primeira posição e limite o destino ao resolver que você realmente pretende.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Essa exceção é diagnóstica e não política. Se a regra do fornecedor é deliberada, o reparo suportado é configurar o cliente para permitir esse resolver e registrar a decisão, porque uma regra inserida não sobreviverá à próxima atualização do cliente.

Por que uma página de vazamento prova menos do que parece

O que uma página de teste de vazamento mostra é o resolver que falou com o operador do teste, não o que a sua máquina consultou. Um encaminhador local que faz recursão para fora coloca o seu próprio endereço de saída nessa página, e consultas cifradas podem deixar a página completamente em branco. Ambos os resultados são mal lidos, um como vazamento e o outro como garantia, e nenhuma das duas leituras decorre da observação.

A prova defensável é a captura: interface, endereço de destino, resposta e carimbo de tempo. Tire uma antes de o túnel subir e outra depois, e compare-as na próxima vez que um nome falhar. Esse par também diz à próxima pessoa se a falha foi de resolução, de roteamento ou da política de acesso do próprio resolver.