Porque o Windows envia os nomes da sua VPN para um servidor DNS que nunca configurou

Define o servidor DNS no adaptador da VPN, volta a ligar-se e o nome privado continua a vir do resolver do escritório que ninguém configurou neste portátil. O resultado parece indicar que a definição foi ignorada, e em certo sentido foi, porque a lista de adaptadores é um conjunto de candidatos e não uma decisão. O Windows resolve nomes através de uma política de espaço de nomes que pode indicar outro servidor para um sufixo específico, e essa política é aplicada antes de a definição do adaptador ser considerada. Encontrar a regra que ganhou é trabalho de cinco minutos quando se sabe que tabela ler.

O que alterou e o que decide realmente

O endereço DNS de um adaptador diz ao cliente para onde essa interface pode enviar consultas. A tabela de políticas de resolução de nomes diz ao cliente para onde deve enviar as consultas de um determinado espaço de nomes, e é avaliada por nome, não por adaptador. Quando uma regra corresponde ao sufixo introduzido, são usados os servidores da regra e a lista de adaptadores deixa de importar para essa consulta.

É por isso que dois nomes no mesmo portátil podem seguir caminhos diferentes no mesmo momento. Um anfitrião sob o sufixo da empresa segue a sua regra; um nome público segue o caminho predefinido, o que normalmente significa o adaptador que responde primeiro.

Como a tabela associa um nome

As regras são indexadas por espaço de nomes e vence a correspondência mais específica. Uma regra para corp.example aplica-se a vpn.corp.example e não se aplica a example.net. Uma regra com o espaço de nomes . cobre tudo o que as outras regras não cobrem, o que a torna a entrada mais perigosa da lista e a que vale a pena verificar quando um site não relacionado é resolvido pelo túnel.

Uma regra pode também conter um comentário, uma política que desativa a entrada e definições de segurança sem qualquer relação com endereços DNS. Uma regra desativada continua visível na configuração sem efeito, pelo que uma entrada que parece correta no papel pode continuar inerte após uma alteração de perfil.

Leia a tabela efetiva, não a lista de desejos

Regras configuradas e regras efetivas são duas perguntas diferentes. Get-DnsClientNrptRule lista o que existe na máquina. Get-DnsClientNrptPolicy -Effective mostra o que o cliente vai realmente aplicar, com os valores combinados da política e das definições locais.

Compare o sufixo dessa saída com o nome que está a testar, carácter a carácter. Uma regra para corp.example não capta um nome que termina em corp.example.com, e um ponto final num sítio e não no outro é suficiente para mudar a correspondência.

Sem regra, o Windows pergunta a mais de um adaptador

Quando nada na tabela reclama o nome, o cliente pode enviar a consulta por várias interfaces e ficar com a primeira resposta que chegar. O resultado depende do momento: o mesmo nome pode ser resolvido pelo adaptador com cabo na segunda-feira e pelo túnel na terça-feira, e nada na configuração de qualquer dos adaptadores explica a diferença.

Existem duas saídas. Acrescente uma regra para o espaço de nomes para que a decisão deixe de ser uma corrida, ou desative o comportamento paralelo através da política de cliente DNS e aceite a resolução mais lenta e determinística. A primeira costuma adequar-se melhor a uma VPN com túnel dividido, porque documenta a intenção em vez de depender da ordem.

Caminhos que contornam o resolver por completo

Um navegador com DNS seguro ativado resolve por conta própria e entrega ao Windows apenas o endereço, pelo que a tabela de regras nunca vê o nome. Os clientes construídos sobre ambientes com o seu próprio resolver podem comportar-se da mesma forma. Quando um nome é resolvido numa aplicação e falha noutra na mesma máquina, compare os dois caminhos de resolução antes de mexer na política.

Verifique também se a aplicação se liga a um endereço em cache de uma sessão anterior. Clear-DnsClientCache e depois a mesma consulta dá uma resposta mais limpa do que deduzi-la de um resultado antigo.

Teste com o nome que falhou

Resolva o nome de anfitrião exato do relatório, não um domínio público de teste de velocidade, e anote que servidor respondeu. Depois altere uma coisa: a regra, a lista de adaptadores ou a atribuição de política, e repita a mesma consulta após reconectar para que o estado aplicado seja reconstruído.

Se o nome for resolvido e o serviço continuar a recusar, pare de editar DNS. O próximo passo útil é o endereço e a rota até ele, porque a resolução de nomes já fez o seu trabalho.