Una connexió VPN de Windows no desa els servidors DNS al perfil que editeu a Configuració. Quan el túnel s’aixeca, el client negocia la configuració IP amb la passarel·la, la passarel·la envia una llista de resolutors i Windows l’aplica a l’adaptador del túnel. Aquest adaptador és una interfície separada de la vostra Wi-Fi o Ethernet, i la llista pertany a la interfície, no al perfil. Un cop sabeu quin objecte posseeix el valor, sobreescriure’l a PowerShell és una ordre; fer que la sobreescriptura sobrevisqui a una reconnexió és la part que necessita una decisió.

Quin objecte posseeix l’adreça

RAS crea l’adaptador del túnel quan la connexió té èxit i l’elimina quan la connexió cau. Els servidors DNS que veieu a ipconfig /all arriben durant aquest intercanvi de configuració, al costat de les adreces IPv4 i IPv6 i les rutes. Com que el valor està lligat a la interfície, Set-DnsClientServerAddress escriu en una cosa que només existeix mentre existeix la connexió.

Aquest sol fet explica la major part de la confusió sobre el DNS de VPN. Un perfil es pot inspeccionar desconnectat, però no hi ha cap interfície a la qual apuntar, així que un script d’inici de sessió que cridi l’ordre contra l’àlies de VPN falla abans que ningú s’hagi connectat. També explica un canvi que sembla revertir-se: no s’ha revertit res, la interfície es va destruir i reconstruir amb els valors que la passarel·la va enviar.

Trobeu l’àlies abans de tocar el DNS

El nom del perfil i l’àlies de la interfície solen ser la mateixa cadena, però no són el mateix objecte. Get-VpnConnection llista perfils; Get-NetAdapter llista les interfícies que Windows té realment. Les ordres DNS volen la segona, i les dues divergeixen més sovint del que la gent espera, sobretot quan el client afegeix un descriptor com "(RAS)" al nom de l’adaptador.

Si el perfil no existeix, PowerShell pot crear una entrada nativa. El tipus de túnel i l’autenticació han de coincidir amb el que ofereix la passarel·la, perquè la discrepància apareix en connectar, no en crear:

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

Connecteu-vos un cop i llegiu l’àlies real abans d’escriure cap ordre DNS:

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

Apliqueu la sobreescriptura en l’ordre correcte

L’ordre importa més que la sintaxi. L’adaptador ha d’estar actiu, l’àlies s’ha de resoldre i el compte ha de tenir permís per canviar la configuració de la interfície. Una connexió per usuari sol acceptar el canvi de l’usuari connectat; una connexió per a tots els usuaris creada amb -AllUserConnection normalment necessita un shell elevat.

L’ordre en si és una línia, documentada a la referència de Set-DnsClientServerAddress:

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

Dos modes de fallada val la pena reconèixer-los d’un cop d’ull. Un àlies equivocat produeix un error de l’ordre, que és el bon resultat, perquè el silenci seria pitjor. Una ordre correcta sense efecte visible sol significar que mireu l’adaptador equivocat: un adaptador de túnel sobrant d’un altre client, una NIC física amb una descripció semblant o un segon adaptador virtual creat per una eina de xarxa aïllada.

Per què una reconnexió pot desfer el canvi

La sobreescriptura pertany a una instància d’interfície. Quan el client desmunta l’adaptador i el reconstrueix a la connexió següent, els valors enviats s’apliquen de nou i la vostra llista desapareix. Alguns clients recreen la interfície a cada connexió; d’altres la reutilitzen durant tota la sessió. Compareu l’índex d’interfície a Get-NetAdapter entre dues connexions i sabreu quin comportament teniu.

Hi ha tres respostes duradores, i apilar-les crea errors propis. Un sufix DNS específic de la connexió més una regla NRPT envia només l’espai de noms intern al resolutor intern i deixa els noms públics tranquils. Una configuració de Group Policy o MDM aplicada a la connexió VPN estableix el DNS en connectar sense cap script. Una tasca programada que reaccioni a l’esdeveniment de connexió i torni a executar l’ordre és l’opció grollera, però funciona i deixa un registre. Trieu un sol propietari per al DNS i anoteu quin és.

Els noms interns d’una sola etiqueta també necessiten una llista de cerca de sufixos. Set-DnsClientGlobalSetting -SuffixSearchList és a tota la màquina, així que canvia la resolució per a cada adaptador de l’equip, inclòs l’Ethernet. Proveu-ho en una màquina de laboratori abans que arribi a una imatge.

Verifiqueu la resolució, no només la configuració

Un resolutor llistat en un adaptador només demostra que s’hi ha escrit un valor. Pregunteu directament al servidor previst i després pregunteu pel camí normal:

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

La divisió us diu on és la fallada. La consulta directa respon i la consulta normal falla: la configuració de l’adaptador o la llista de sufixos no està en vigor. Totes dues fallen: el resolutor no és abastable pel túnel, així que mireu les rutes i les regles del tallafoc abans de tornar a tocar el DNS. La consulta directa falla mentre la consulta normal respon des d’un altre lloc: el split DNS està mal configurat i un nom intern el respon un resolutor públic, cosa que és un problema de política abans que de connectivitat.

Executeu la prova dues vegades, una just després de connectar i una després de desconnectar i reconnectar, i compareu la Get-DnsClientServerAddress sortida de les dues execucions. Si el valor enviat torna a la segona connexió, la sobreescriptura va viure i morir amb l’adaptador, i només aguantarà la ruta NRPT o de política de la secció anterior. Guardeu totes dues transcripcions i les marques de temps de connexió; resolen la pregunta de si s’hi manté més ràpid que una altra ronda d’edicions.

Articles relacionats