VPN conectada mas os nomes falham: onde o DNS realmente quebra

Túnel ativo, ícone verde e cada aba do navegador relata uma falha de resolução de nomes. Três mecanismos diferentes produzem essa imagem: o resolver pode estar inacessível, o cliente pode estar a perguntar a um resolver que não esperava, ou só os nomes privados podem falhar. Separe-os antes de mudar qualquer coisa no protocolo do túnel, porque cada um se repara num lugar diferente. A ordem abaixo começa pelas observações que separam os três casos.

O que uma consulta realmente precisa

Uma consulta precisa de três coisas: um endereço de resolver, uma rota até esse endereço e uma resposta que corresponda à pergunta. Cada uma pode falhar sozinha, e o sintoma visível é a mesma página que não carrega. Por isso a página de erro não lhe diz quase nada até saber qual das três se quebrou.

O cliente aprende o seu resolver do perfil VPN, do DHCP no túnel ou da sua própria configuração, e qual fonte ganha depende da plataforma. No Windows, ipconfig /all lista os servidores DNS por adaptador, por isso vê se o valor enviado chegou realmente. Um valor enviado que nunca chegou ao sistema operativo é uma falha silenciosa e comum. Leia o valor configurado antes de tocar no perfil.

Linux e macOS respondem à mesma pergunta com comandos diferentes, e a resposta merece a mesma leitura: resolvectl status e scutil --dns ambos listam os servidores por interface. Compare essa lista com o endereço que o perfil diz enviar. Uma discrepância aqui explica tudo a jusante, por isso resolva-a antes de testar nomes.

Teste um nome público e um privado

Consulte um nome de anfitrião público comum e o nome de anfitrião privado documentado a partir da mesma máquina, e registe qual servidor respondeu a cada um. Se ambos falharem, o resolver ou a rota dele estão quebrados. Se só o nome privado falhar, o resolver respondeu e a pergunta passa a ser a zona ou o encaminhamento. Execute as duas consultas com menos de um minuto de diferença para que uma mudança de rota não possa explicar a diferença.

Mantenha os nomes internos fora de capturas públicas e fora de resolvers públicos. Um tempo de espera e uma resposta de domínio inexistente são observações diferentes: a primeira diz que nada voltou, a segunda que uma autoridade respondeu que o nome não existe. Tratá-los como um único erro leva-o à camada errada, e um aviso de certificado é ainda uma terceira coisa, não uma falha de DNS.

nslookup mostra tanto o servidor a que perguntou como a resposta recebida, e é exatamente o par de que precisa. Execute-o duas vezes no mesmo shell e escreva o endereço que responde ao lado de cada resposta.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Confirme que o cliente consegue realmente chegar a esse servidor

Um resolver privado enviado pelo perfil só é útil se o cliente o conseguir alcançar com o túnel ativo. Um endereço que parece correto sem rota produz um tempo de espera, e o estado ligado do túnel não diz nada sobre essa rota. A verificação é uma pesquisa de rota dirigida ao próprio resolver, não ao ponto final do VPN.

Cada plataforma responde a isso numa linha, e a interface indicada na saída é a resposta completa. Se apontar para o adaptador físico enquanto o resolver está atrás do túnel, o perfil não está a enviar um prefixo que o cubra.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Num perfil de túnel dividido, o resolver pode ficar fora das rotas enviadas, o que é um problema do perfil e não do servidor. Compare o endereço do resolver com os prefixos enviados e confirme que um deles o cobre. A mesma discrepância explica porque o DNS funciona numa rede e falha noutra com um perfil idêntico.

Lembre-se de que os navegadores podem contornar o resolver do sistema

Um navegador com DNS seguro ativado pode enviar consultas por HTTPS a um fornecedor à sua escolha e ignorar por completo o resolver do sistema operativo. O sistema parece então correto enquanto o navegador falha, ou o contrário. Isso é uma questão de política do navegador, não do túnel.

Verifique a definição de DNS seguro do navegador e qualquer política gerida que a controle, e depois experimente uma segunda aplicação ou navegador com o túnel inalterado. Se só uma aplicação falhar, a correção pertence a essa aplicação. Uma janela privada não é uma comparação limpa, porque pode desativar extensões por predefinição num navegador e não noutro, e nunca contorna uma política gerida. Use antes um segundo perfil de navegador ou outra aplicação.

Limpe a cache e volte a testar a tarefa real

Depois de corrigir uma definição, limpe a cache local do resolver para que uma resposta antiga não sobreviva à correção. Uma recuperação breve seguida de nova falha significa que a causa ainda está lá, não que a limpeza falhou. Escolha a linha que corresponde à máquina em que está, porque as três caches são separadas.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Depois repita a tarefa original em vez de uma consulta sintética, porque a tarefa é o que importa ao utilizador. Volte a ligar uma vez, para que o novo teste cubra o estado em que o utilizador estará de facto. A referência de nslookup da Microsoft é a página que deve guardar para os argumentos da consulta.

Se os nomes falharem apenas após desligar, o cliente não restaurou a configuração anterior, o que é um bug de ciclo de vida a comunicar, não um servidor DNS a substituir. Uma consulta a funcionar também não é um teste de fuga, porque o país de saída não lhe diz qual resolver respondeu.