Impostare il DNS su un adattatore VPN di Windows con PowerShell, poi verificare

Una connessione VPN di Windows non memorizza i server DNS nel profilo che modifichi in Impostazioni. Quando il tunnel si attiva, il client negozia la configurazione IP con il gateway, il gateway invia un elenco di resolver e Windows lo applica all'adattatore del tunnel. Quell'adattatore è un'interfaccia separata dalla tua Wi-Fi o Ethernet, e l'elenco appartiene all'interfaccia, non al profilo. Una volta che sai quale oggetto possiede il valore, sovrascriverlo in PowerShell è un solo comando; far sopravvivere la sovrascrittura a una riconnessione è la parte che richiede una decisione.

Quale oggetto possiede l'indirizzo

RAS crea l'adattatore del tunnel quando la connessione riesce e lo rimuove quando la connessione cade. I server DNS che vedi in ipconfig /all arrivano durante quello scambio di configurazione, accanto agli indirizzi IPv4 e IPv6 e alle route. Poiché il valore è legato all'interfaccia, Set-DnsClientServerAddress scrive in qualcosa che esiste solo finché esiste la connessione.

Questo singolo fatto spiega gran parte della confusione attorno al DNS della VPN. Un profilo si può ispezionare da disconnessi, ma non c'è un'interfaccia su cui puntare, quindi uno script di accesso che chiama il cmdlet sull'alias della VPN fallisce prima che qualcuno si sia connesso. Spiega anche un cambiamento che sembra tornare indietro: nulla è tornato indietro, l'interfaccia è stata distrutta e ricostruita con i valori inviati dal gateway.

Trova l'alias prima di toccare il DNS

Il nome del profilo e l'alias dell'interfaccia di solito sono la stessa stringa, ma non sono lo stesso oggetto. Get-VpnConnection elenca i profili; Get-NetAdapter elenca le interfacce che Windows ha davvero. I cmdlet DNS vogliono la seconda, e le due divergono più spesso di quanto la gente si aspetti, soprattutto quando il client aggiunge un descrittore come "(RAS)" al nome dell'adattatore.

Se il profilo non esiste, PowerShell può creare una voce nativa. Il tipo di tunnel e l'autenticazione devono corrispondere a ciò che offre il gateway, perché una discrepanza emerge al momento della connessione e non della creazione:

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

Connettiti una volta, poi leggi l'alias reale prima di scrivere qualsiasi comando DNS:

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

Applica la sovrascrittura nell'ordine giusto

L'ordine conta più della sintassi. L'adattatore deve essere attivo, l'alias deve risolversi e all'account deve essere consentito modificare le impostazioni dell'interfaccia. Una connessione per utente di solito accetta la modifica dall'utente connesso; una connessione per tutti gli utenti creata con -AllUserConnection in genere richiede una shell con privilegi elevati.

Il cmdlet in sé è una riga sola, documentato nella documentazione di riferimento di Set-DnsClientServerAddress di Microsoft:

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

Due modalità di errore vale la pena riconoscerle a colpo d'occhio. Un alias sbagliato produce un errore dal cmdlet, ed è il risultato buono, perché il silenzio sarebbe peggio. Un cmdlet corretto senza effetto visibile di solito significa che stai guardando l'adattatore sbagliato: un adattatore di tunnel rimasto da un altro client, una NIC fisica con una descrizione simile o un secondo adattatore virtuale creato da uno strumento di rete in sandbox.

Perché una riconnessione può annullare la modifica

La sovrascrittura appartiene a una singola istanza dell'interfaccia. Quando il client smonta l'adattatore e lo ricostruisce alla connessione successiva, i valori inviati vengono applicati di nuovo e il tuo elenco sparisce. Alcuni client ricreano l'interfaccia a ogni connessione; altri la riusano per tutta la durata della sessione. Confronta l'indice dell'interfaccia in Get-NetAdapter tra due connessioni e saprai quale comportamento hai.

Esistono tre risposte durature, e impilarle crea bug propri. Un suffisso DNS specifico della connessione più una regola NRPT invia solo lo spazio dei nomi interno al resolver interno e lascia in pace i nomi pubblici. Un'impostazione di Criteri di gruppo o MDM applicata alla connessione VPN imposta il DNS al momento della connessione senza alcuno script. Un'attività pianificata che reagisce all'evento di connessione e riesegue il cmdlet è l'opzione grezza, ma funziona e lascia un registro. Scegli un solo proprietario per il DNS e annota quale sia.

Anche i nomi interni con una sola etichetta richiedono un elenco di ricerca dei suffissi. Set-DnsClientGlobalSetting -SuffixSearchList vale per l'intera macchina, quindi cambia la risoluzione per ogni adattatore del computer, Ethernet compreso. Provalo su una macchina di laboratorio prima che finisca in un'immagine.

Verifica la risoluzione, non solo l'impostazione

Un resolver elencato su un adattatore dimostra solo che un valore è stato scritto. Chiedi direttamente al server previsto, poi chiedi attraverso il percorso normale:

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

La separazione ti dice dove sta il guasto. La query diretta risponde e la query semplice fallisce: l'impostazione dell'adattatore o l'elenco dei suffissi non è in vigore. Falliscono entrambe: il resolver non è raggiungibile attraverso il tunnel, quindi guarda le route e le regole del firewall prima di toccare di nuovo il DNS. La query diretta fallisce mentre quella semplice risponde da un'altra parte: il DNS diviso è configurato male e un resolver pubblico risponde per un nome interno, il che è un problema di policy prima che di connettività.

Esegui il test due volte, una subito dopo la connessione e una dopo una disconnessione e riconnessione, e confronta l'output di Get-DnsClientServerAddress delle due esecuzioni. Se il valore inviato è tornato sulla seconda connessione, la sovrascrittura è vissuta e morta con l'adattatore, e resisterà solo la regola NRPT o il percorso di policy della sezione precedente. Conserva entrambe le trascrizioni e le marche temporali della connessione; risolvono la domanda se resta più in fretta di un altro giro di modifiche.