Servidor DNS errado na VPN do Windows: métrica, ordem de enlace ou sufixo

Um cliente Windows pode ter um túnel a funcionar, transportar o resolvedor da empresa e ainda assim enviar nomes internos para o router de casa. Três mecanismos diferentes decidem que servidor responde, e falham de formas diferentes. Não é preciso corrigir os três: o sintoma diz-lhe qual está em jogo. A árvore de decisão abaixo leva alguns minutos e evita o desfecho habitual, em que uma alteração de métrica, uma reordenação do registo e uma regra NRPT chegam juntas e ninguém sabe qual fez algo.

Três mecanismos decidem, e normalmente um está errado

A métrica da interface ordena os adaptadores para uma determinada família de endereços. A ordem de enlace em Tcpip\Linkage é uma lista de identificadores de interface válida para toda a máquina que os caminhos de código antigos ainda consultam. A tabela de políticas de resolução de nomes (NRPT) liga um espaço de nomes a servidores específicos, e a lista de sufixos decide se um nome curto chega a ser expandido. São independentes, e é por isso que um resolvedor correto no adaptador VPN perde para uma preferência desatualizada noutro sítio.

Nenhum destes mecanismos é o outro lado do túnel. Se o servidor que a VPN empurra não conseguir resolver o nome, qualquer definição do lado do cliente é decoração, pelo que a primeira decisão é se o próprio resolvedor consegue responder quando lhe perguntam diretamente.

Decisão um: o resolvedor empurrado consegue responder?

Pergunte ao servidor de forma explícita e compare com uma pesquisa normal. A diferença entre as respostas separa um problema de seleção de um problema de alcance, e é a bifurcação mais rápida aqui:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Se a primeira funcionar e a segunda falhar, o resolvedor é alcançável e o Windows escolhe mal; vá às decisões de espaço de nomes e ordem abaixo. Se a primeira também falhar, nada no cliente ajudará: verifique se UDP e TCP 53 chegam ao servidor pelo túnel, se nenhuma firewall do anfitrião no servidor descarta o conjunto, e se os reencaminhadores do próprio servidor estão sãos.

Pare nesta bifurcação. Aplicar uma regra NRPT a um resolvedor que não consegue alcançar produz a mesma falha com mais configuração para desfazer, e esconde a avaria real atrás de uma regra que parece ter autoridade.

Decisão dois: um espaço de nomes ou cada consulta?

O âmbito decide a ferramenta. Quando só falham os nomes da empresa, ligue o espaço de nomes em vez de reordenar a máquina: uma regra NRPT envia esse sufixo para o resolvedor do túnel e deixa tudo o resto em paz. Quando toda a pesquisa é afetada, o problema é a preferência global de adaptadores, e a métrica é o ponto de partida porque não altera nenhuma definição do servidor.

Defina a métrica por família de endereços, nas duas interfaces, e confirme a ordem depois:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Substitua 11 pelo ifIndex do adaptador do túnel da linha acima; se 11 for o adaptador LAN, o mesmo comando baixa o caminho errado. Subir antes o adaptador LAN chega à mesma ordem pelo outro lado: netsh int ip set interface interface="Ethernet" metric=15, e netsh int ipv6 set interface interface="Ethernet" metric=15 para a segunda família, porque int ip só toca em IPv4.

A ordem de enlace é o último recurso e não o primeiro movimento. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage contém uma lista Bind de identificadores de dispositivo, e mover o identificador do túnel para a frente altera de facto qual adaptador é questionado primeiro, mas é um valor de registo para toda a máquina sem âmbito por espaço de nomes. Exporte-o antes de editar e volte a ligar o túnel depois, para que a ordem se aplique no estado que o cliente espera.

Para um único espaço de nomes, prefira o instrumento mais estreito:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Decisão três: a correção sobrevive a uma reconexão?

Uma métrica que funciona até à próxima reconexão por linha comutada nunca foi guardada. L2TP/IPsec e outros perfis de ligação são recriados quando a ligação começa, por isso o valor guardado vive na entrada da agenda telefónica como IpInterfaceMetric, não apenas na interface ativa. Alguns ambientes automatizam esse campo precisamente por isto; outros empurram a preferência a partir de uma política de gestão e deixam o ponto final em paz.

A cache e o registo são uma camada à parte. Executar isto depois de o túnel subir corrige entradas obsoletas e volta a registar o cliente, mas nenhum dos dois reordena um adaptador:

ipconfig /registerdns
ipconfig /flushdns

Há um interruptor na mesma camada. Desativar o registo dinâmico no adaptador físico impede o cliente de anunciar o seu endereço do lado VPN com o nome errado, o que é uma reparação diferente da atualização acima.

O IPv6 merece a sua própria linha na decisão. Se o adaptador físico tiver um endereço IPv6 global enquanto o túnel só transporta IPv4, o Windows pode preferir o caminho sem túnel para a resolução de nomes. Verifique essa família em separado, porque uma métrica definida para IPv4 não diz nada sobre ela:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Desativar o IPv6 no adaptador LAN elimina esse caminho e o protocolo com ele; uma alteração de métrica na interface IPv6, ou uma regra NRPT para o espaço de nomes da empresa, mantém a família e corrige a preferência. Escolha a mais estreita, a menos que tenha decidido que essa ligação não deve ter IPv6.

Verifique com a fonte nomeada, e mantenha um só proprietário

Verifique com ferramentas que reportem que fonte está em vigor, não apenas se uma página carrega:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Depois separe a filtragem da seleção, porque de dentro de uma aplicação parecem idênticas. block-outside-dns do OpenVPN bloqueia a porta 53 nos outros adaptadores; não escolhe um resolvedor. Se agora toda a consulta falhar, um filtro pode estar a bloquear o único servidor alcançável; se o resolvedor configurado estiver a ser ignorado, a ordem ou a regra de espaço de nomes está errada. Alterar os dois ao mesmo tempo torna indistinguíveis uma consulta bloqueada e uma consulta ignorada.

Mantenha um só proprietário para a política de DNS: o perfil VPN, uma política de gestão ou uma regra NRPT, não dois deles. Antes de fechar:

• O resolvedor empurrado responde quando é nomeado explicitamente, e uma pesquisa normal usa-o.
• A regra ou a métrica que alterou cobre a família de endereços que de facto transporta as consultas.
• A definição sobrevive a uma desconexão e reconexão, ou mudou-a para o perfil guardado.
• Exatamente um mecanismo é autoritativo, e os restantes ficaram como estavam.

Trate a ordem como estado do ambiente e não como algo que se termina. Volte a verificá-la depois de uma reconexão e depois de uma atualização do Windows que toque na pilha de rede, porque qualquer das duas pode voltar a pôr o adaptador físico à frente.