Definir o DNS num adaptador VPN do Windows com o PowerShell e depois verificar

Uma ligação VPN do Windows não guarda os servidores DNS no perfil que edita nas Definições. Quando o túnel sobe, o cliente negoceia a configuração IP com o gateway, o gateway envia uma lista de resolvedores e o Windows aplica-a ao adaptador do túnel. Esse adaptador é uma interface separada da sua Wi-Fi ou Ethernet, e a lista pertence à interface, não ao perfil. Depois de saber que objeto detém o valor, substituí-lo no PowerShell é um único comando; fazer com que a substituição sobreviva a uma nova ligação é a parte que exige uma decisão.

Que objeto detém o endereço

O RAS cria o adaptador do túnel quando a ligação tem êxito e remove-o quando a ligação cai. Os servidores DNS que vê em ipconfig /all chegam durante essa troca de configuração, ao lado dos endereços IPv4 e IPv6 e das rotas. Como o valor está ligado à interface, Set-DnsClientServerAddress escreve em algo que só existe enquanto a ligação existir.

Esse único facto explica a maior parte da confusão em torno do DNS da VPN. Um perfil pode ser inspecionado com a ligação desligada, mas não há interface para apontar, pelo que um script de início de sessão que chame o cmdlet contra o alias da VPN falha antes de alguém se ter ligado. Explica também uma alteração que parece reverter: nada reverteu, a interface foi destruída e reconstruída com os valores que o gateway enviou.

Encontre o alias antes de tocar no DNS

O nome do perfil e o alias da interface costumam ser a mesma cadeia, mas não são o mesmo objeto. Get-VpnConnection lista perfis; Get-NetAdapter lista as interfaces que o Windows realmente tem. Os cmdlets de DNS querem a segunda, e as duas divergem mais vezes do que as pessoas esperam, sobretudo quando o cliente acrescenta um descritor como "(RAS)" ao nome do adaptador.

Se o perfil não existir, o PowerShell pode criar uma entrada nativa. O tipo de túnel e a autenticação têm de corresponder ao que o gateway oferece, porque uma incompatibilidade surge no momento da ligação e não no da criação:

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

Ligue-se uma vez e depois leia o alias real antes de escrever qualquer comando DNS:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

Aplique a substituição pela ordem certa

A ordem importa mais do que a sintaxe. O adaptador tem de estar ativo, o alias tem de resolver e a conta tem de ter permissão para alterar definições da interface. Uma ligação por utilizador costuma aceitar a alteração do utilizador com sessão iniciada; uma ligação para todos os utilizadores criada com -AllUserConnection geralmente exige uma shell elevada.

O cmdlet propriamente dito é uma linha única, documentado na referência Set-DnsClientServerAddress da Microsoft:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

Dois modos de falha valem a pena reconhecer à primeira vista. Um alias errado produz um erro do cmdlet, e esse é o bom resultado, porque o silêncio seria pior. Um cmdlet correto sem efeito visível significa normalmente que está a olhar para o adaptador errado: um adaptador de túnel deixado por outro cliente, uma NIC física com uma descrição semelhante, ou um segundo adaptador virtual criado por uma ferramenta de rede em sandbox.

Porque é que uma nova ligação pode desfazer a alteração

A substituição pertence a uma única instância da interface. Quando o cliente desmonta o adaptador e o reconstrói na ligação seguinte, os valores enviados são aplicados de novo e a sua lista desaparece. Alguns clientes recriam a interface em cada ligação; outros reutilizam-na durante toda a sessão. Compare o índice da interface em Get-NetAdapter entre duas ligações e saberá qual é o comportamento que tem.

Existem três respostas duradouras, e empilhá-las cria erros próprios. Um sufixo DNS específico da ligação mais uma regra NRPT envia apenas o espaço de nomes interno para o resolvedor interno e deixa os nomes públicos em paz. Uma definição de Política de Grupo ou MDM aplicada à ligação VPN define o DNS no momento da ligação sem qualquer script. Uma tarefa agendada que reaja ao evento de ligação e volte a executar o cmdlet é a opção grosseira, mas funciona e deixa um registo. Escolha um único responsável pelo DNS e anote qual é.

Os nomes internos de um só rótulo também precisam de uma lista de pesquisa de sufixos. Set-DnsClientGlobalSetting -SuffixSearchList é para toda a máquina, por isso altera a resolução de cada adaptador no computador, incluindo o Ethernet. Teste-a numa máquina de laboratório antes de entrar numa imagem.

Verifique a resolução, não apenas a definição

Um resolvedor listado num adaptador prova apenas que um valor foi escrito. Pergunte diretamente ao servidor pretendido e depois pergunte pelo caminho normal:

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

A divisão diz-lhe onde está a falha. A consulta direta responde e a consulta simples falha: a definição do adaptador ou a lista de sufixos não está em vigor. Ambas falham: o resolvedor está inacessível através do túnel, por isso veja as rotas e as regras da firewall antes de voltar a mexer no DNS. A consulta direta falha enquanto a simples responde de outro sítio: o DNS dividido está mal configurado e um nome interno está a ser respondido por um resolvedor público, o que é um problema de política antes de ser um problema de conetividade.

Execute o teste duas vezes, uma logo após a ligação e outra após desligar e voltar a ligar, e compare a saída de Get-DnsClientServerAddress das duas execuções. Se o valor enviado voltou na segunda ligação, a substituição viveu e morreu com o adaptador, e só a regra NRPT ou o caminho de política da secção anterior se manterá. Guarde ambas as transcrições e as marcas temporais da ligação; resolvem a questão de saber se persiste mais depressa do que outra ronda de edições.