Configura o DNS nun adaptador VPN de Windows con PowerShell e despois verifica

Unha conexión VPN de Windows non garda os servidores DNS no perfil que editas en Configuración. Cando o túnel se levanta, o cliente negocia a configuración IP coa pasarela, a pasarela envía unha lista de resolvedores e Windows aplícaa ao adaptador do túnel. Ese adaptador é unha interface separada da túa Wi-Fi ou Ethernet, e a lista pertence á interface, non ao perfil. Unha vez que sabes que obxecto posúe o valor, sobrescribilo en PowerShell é unha soa orde; facer que a sobrescritura sobreviva a unha reconexión é a parte que require unha decisión.

Que obxecto posúe o enderezo

RAS crea o adaptador do túnel cando a conexión ten éxito e elimínao cando a conexión cae. Os servidores DNS que ves en ipconfig /all chegan durante ese intercambio de configuración, xunto aos enderezos IPv4 e IPv6 e as rutas. Como o valor está ligado á interface, Set-DnsClientServerAddress escribe nun algo que só existe mentres existe a conexión.

Ese único feito explica a maior parte da confusión arredor do DNS da VPN. Pódese inspeccionar un perfil mentres estás desconectado, pero non hai interface á que apuntar, así que un script de inicio de sesión que chame o cmdlet contra o alias da VPN falla antes de que ninguén se conecte. Tamén explica un cambio que parece reverter: nada reverteu, a interface foi destruída e reconstruída cos valores que enviou a pasarela.

Atopa o alias antes de tocar o DNS

O nome do perfil e o alias da interface adoitan ser a mesma cadea, pero non son o mesmo obxecto. Get-VpnConnection lista perfís; Get-NetAdapter lista as interfaces que Windows ten realmente. Os cmdlets de DNS queren a segunda, e as dúas diverxen máis a miúdo do que a xente espera, sobre todo cando o cliente engade un descritor como "(RAS)" ao nome do adaptador.

Se o perfil non existe, PowerShell pode crear unha entrada nativa. O tipo de túnel e a autenticación deben coincidir co que ofrece a pasarela, porque unha discrepancia aparece no momento de conectar e non no de crear:

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

Conecta unha vez e despois le o alias real antes de escribir calquera orde de DNS:

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

Aplica a sobrescritura na orde correcta

A orde importa máis ca a sintaxe. O adaptador ten que estar levantado, o alias ten que resolverse e a conta ten que ter permiso para cambiar a configuración da interface. Unha conexión por usuario adoita aceptar o cambio do usuario que iniciou sesión; unha conexión para todos os usuarios creada con -AllUserConnection normalmente necesita unha consola elevada.

O cmdlet en si é unha soa liña, documentado na referencia de Set-DnsClientServerAddress de Microsoft:

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

Dous modos de fallo paga a pena recoñecelos de vista. Un alias incorrecto produce un erro do cmdlet, que é o bo resultado, porque o silencio sería peor. Un cmdlet correcto sen efecto visible normalmente significa que estás a mirar o adaptador equivocado: un adaptador de túnel deixado por outro cliente, unha NIC física cunha descrición semellante ou un segundo adaptador virtual creado por unha ferramenta de redes illada.

Por que unha reconexión pode desfacer o cambio

A sobrescritura pertence a unha soa instancia da interface. Cando o cliente destrúe o adaptador e o reconstrúe na seguinte conexión, os valores enviados aplícanse de novo e a túa lista desaparece. Algúns clientes recrean a interface en cada conexión; outros reutilízana durante toda a sesión. Compara o índice da interface en Get-NetAdapter entre dúas conexións e saberás que comportamento tes.

Existen tres respostas duradeiras, e apilalas crea os seus propios fallos. Un sufixo DNS específico da conexión máis unha regra NRPT envía só o espazo de nomes interno ao resolvedor interno e deixa os nomes públicos en paz. Unha configuración de Directiva de grupo ou MDM aplicada á conexión VPN establece o DNS no momento de conectar sen ningún script. Unha tarefa programada que reaccione ao evento de conexión e volva executar o cmdlet é a opción bruta, pero funciona e deixa un rexistro. Escolle un único responsable do DNS e anota cal é.

Os nomes internos dunha soa etiqueta tamén necesitan unha lista de busca de sufixos. Set-DnsClientGlobalSetting -SuffixSearchList é para toda a máquina, así que cambia a resolución de todos os adaptadores do equipo, incluído Ethernet. Proba nunha máquina de laboratorio antes de que entre nunha imaxe.

Verifica a resolución, non só a configuración

Un resolvedor listado nun adaptador só demostra que se escribiu un valor. Pregunta directamente ao servidor previsto e despois pregunta pola ruta normal:

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

A división diche onde está a falla. A consulta directa responde e a consulta simple falla: a configuración do adaptador ou a lista de sufixos non está en efecto. Fallan as dúas: o resolvedor non é alcanzable polo túnel, así que mira as rutas e as regras da devasa antes de tocar o DNS outra vez. A consulta directa falla mentres a simple responde desde outro sitio: o DNS dividido está mal configurado e un resolvedor público está a responder a un nome interno, o que é un problema de política antes de ser un de conectividade.

Executa a proba dúas veces, unha xusto despois de conectar e outra tras desconectar e reconectar, e compara a saída de Get-DnsClientServerAddress das dúas execucións. Se o valor enviado volve na segunda conexión, a sobrescritura viviu e morreu co adaptador, e só a regra NRPT ou a ruta de política da sección anterior aguantará. Garda as dúas transcricións e as marcas de tempo da conexión; resolven a pregunta de se persiste máis rápido ca outra rolda de edicións.