O VPN alterou o meu DNS? Compare antes e depois

Liga o túnel, abre um painel privado e o nome resolve-se num endereço que nunca viu. Ou acontece o contrário: o navegador continua a funcionar enquanto uma ferramenta de linha de comandos de repente não resolve nada. Os dois resultados vêm da mesma alteração, e as pessoas costumam explicá-la com uma frase sobre o VPN que "usa o próprio DNS", o que não é suficientemente preciso para diagnosticar ou verificar. Nessa frase escondem-se duas perguntas: que consultas deve este perfil assumir e se a sua máquina as enviou realmente ao resolver que lhe foi atribuído. Mantê-las separadas é todo o método, porque um teste que as mistura produz uma resposta errada e confiante em ambas as direções.

Porque é que um perfil fornece um resolver

Dentro de um túnel, os nomes atrás da extremidade remota costumam resolver-se em endereços que só existem nessa rede. Uma zona privada como corp.internal não tem delegação pública, por isso o resolver que a serve tem de ser alcançável de dentro do túnel. O mesmo mecanismo serve um segundo objetivo: quando as consultas sairiam de outra forma pelo seu fornecedor, um resolver do lado remoto mantém a consulta dentro do caminho cifrado. É por isso que o endereço do servidor DNS chega como parte da política da ligação e não como uma definição global que escolheu uma vez para a máquina.

O endereço por si só não decide nada. Um resolver só pode responder se houver uma rota até ele, e a falha mais comum é um resolver alcançável apenas enquanto o túnel está ativo. Quando o túnel cai e a política permanece, as consultas vão para um endereço sem caminho, e o sintoma é um tempo limite esgotado e não um erro limpo. Essa diferença importa quando lê o resultado do teste seguinte, porque um tempo limite envia as pessoas para definições de transporte que nunca estiveram envolvidas.

Compare os dois desenhos antes de comparar respostas

O túnel completo e o DNS dividido produzem expectativas opostas, e nenhum deles é um mau funcionamento. Com um túnel completo, cada consulta pode passar para o fornecedor ou para o resolver da empresa, pelo que é esperado que os nomes públicos respondam de forma diferente após a ligação. Com DNS dividido, só os domínios listados vão para o resolver privado enquanto tudo o resto permanece local; no Windows a lista de domínios vive na Name Resolution Policy Table, no macOS nos domínios correspondentes das definições de DNS, e num anfitrião systemd-resolved nos domínios de encaminhamento por ligação.

É esta a comparação a fazer primeiro, porque decide o que conta como defeito. Com DNS dividido, um nome público que responde a partir de um novo resolver é o que merece investigação, enquanto um nome interno que responde corretamente é o sistema a fazer o seu trabalho. Com um túnel completo, a anomalia é um nome público que continua a responder a partir do resolver do seu fornecedor. A documentação da Microsoft sobre a resolução de nomes de VPN descreve a ordem do Windows destas regras, incluindo como uma entrada de política correspondente é consultada antes dos servidores do próprio adaptador.

Há um terceiro resolver na sala que é fácil esquecer. O DNS seguro do navegador resolve nomes por conta própria e pode continuar a responder depois de o túnel ter alterado a política do sistema operativo, por isso uma página que carrega prova que o resolver do navegador funcionou, não que o perfil foi aplicado. Se comparar apenas o que o navegador mostra, metade das vezes está a testar a camada errada.

Registe uma linha de base com apenas uma variável

Altere o túnel. Não altere também o nome, a ferramenta ou o sufixo de pesquisa no mesmo passo. Escolha um nome que lhe seja permitido consultar, anote que aplicação usou e escreva ou o endereço que voltou ou o erro exato. No Windows, Get-DnsClientServerAddress -AddressFamily IPv4 imprime os servidores por adaptador e Get-DnsClientNrptPolicy imprime as entradas de política; no Linux com systemd-resolved, resolvectl status mostra os servidores DNS e os domínios de encaminhamento por ligação; no macOS, scutil --dns imprime a ordem de resolvers que o sistema seguirá realmente.

Depois ligue através dos controlos habituais do cliente e repita exatamente os mesmos comandos. Guarde a primeira saída em vez de uma memória dela, porque a comparação é todo o ponto e uma segunda leitura feita após limpar a cache já é outra medição. Se a linha de base foi tomada com o navegador à frente e a execução após a ligação acontece num terminal, está a comparar dois resolvers, não dois estados de um mesmo resolver.

Uma consulta explícita e uma pesquisa da aplicação são testes diferentes

Perguntar a um servidor específico, com nslookup name 10.20.0.1 ou dig @10.20.0.1 name, prova uma única coisa: que o servidor que nomeou responde quando consegue alcançá-lo. Contorna por completo a lógica de seleção, por isso não pode dizer se o sistema teria escolhido esse servidor para este nome. Use-o para testar se o resolver atribuído é alcançável, e não o use para testar a política.

Uma pesquisa através do resolver local exercita mesmo a seleção. resolvectl query name percorre as mesmas regras de domínios de encaminhamento e relata que protocolo respondeu, Resolve-DnsName no Windows passa pela tabela de política e pela cache do cliente, e scutil --dns mostra a ordem que uma pesquisa seguiria. Execute os dois tipos e mantenha-os em colunas separadas das suas notas. Uma consulta explícita com sucesso ao lado de uma pesquisa da aplicação falhada é um problema de encaminhamento ou de seleção, não um resolver que se recusa a funcionar.

A cache está entre si e a resposta. O sistema operativo, o resolver stub local, o navegador e a cache negativa guardam todos resultados, por isso uma pesquisa pode ter sucesso sem que um único pacote saia da máquina. Registe o resultado antes de limpar o que quer que seja: ipconfig /flushdns, resolvectl flush-caches ou sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder no macOS. Evite o reinício de rede amplo nesta fase, porque destrói as provas que ainda está a recolher.

O que significa a diferença

Compare as duas linhas registadas e classifique a alteração antes de tocar numa única definição.

Uma linha merece ênfase. Um nome que se resolve não é um serviço que funciona, e o sucesso do DNS diz apenas que foi encontrado um endereço. Não diz nada sobre reencaminhamento, regras de firewall ou se a sua conta pode sequer usar o serviço, por isso termine testando a aplicação real em vez de assumir que a falha se retirou sozinha.

Restaure a linha de base e verifique-a

Desligue através dos controlos do próprio cliente em vez de matar o processo, e depois releia os mesmos três comandos. Os servidores por ligação, as entradas de política e a resposta para o seu nome de teste devem voltar à linha de base que escreveu antes. Uma entrada de política que sobra após uma desconexão limpa é um defeito real que vale a pena registar, e é também por isso que as edições manuais de um ficheiro de resolver gerado são um mau hábito: o ficheiro é reescrito e a edição desaparece, ou a edição sobrevive e fixa um resolver que já não tem rota.

Percorra esta lista uma vez, por ordem. Decida que desenho o perfil implementa antes de julgar qualquer resultado. Mantenha o nome, a ferramenta e o sufixo fixos nas duas execuções. Separe a consulta explícita da pesquisa da aplicação. Leia a política efetiva, não apenas a resposta. Limpe as caches por último, depois de a comparação estar escrita. Verifique com a aplicação real, depois reinicie uma vez e confirme que o estado desligado continua limpo.