Chi applica davvero le impostazioni DNS di OpenConnect su Windows?

Alzare il tunnel non è la stessa cosa che installarne i valori DNS. OpenConnect negozia e un helper lato Windows applica. Il divario tra questi due passaggi spiega la maggior parte degli errori sui nomi privati con questo client, e l’helper quasi mai è la pagina delle impostazioni VPN di Windows.

Separate ciò che il gateway ha offerto da ciò che Windows ha installato

Il client consegna i dati di connessione a un’interfaccia di script, e le varianti Unix e Windows sono programmi separati. Su Windows l’implementazione è di solito un helper JavaScript che legge variabili come il server DNS interno e il dominio interno prima di toccare qualsiasi adattatore. Nulla nel tunnel stesso scrive lo stato del resolver.

Questa separazione conta perché un valore può esistere nella negoziazione e non raggiungere mai l’adattatore. Un helper mancante, che fallisce a metà o che è una copia più vecchia inclusa in un wrapper GUI lascia Windows esattamente com’era. La sessione sembra connessa, il nome privato continua a risolversi tramite il provider locale e nulla nella finestra del client suggerisce la differenza. Leggere l’output dell’helper stesso è l’unico modo affidabile per sapere quale fase si è rotta.

Un wrapper GUI può fornire la propria copia del client e dell’helper, quindi un secondo openconnect.exe altrove sul disco non prova nulla. Trovate l’eseguibile che ha avviato la sessione prima di giudicarne la configurazione.

Leggete lo stato del resolver senza cambiarlo

Tre query di sola lettura coprono la confusione usuale, e ciascuna risponde a una domanda diversa:

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective

Un server a livello di adattatore è ciò che la maggior parte delle persone intende per DNS VPN. Un suffisso specifico della connessione decide se un nome breve viene espanso. L’elenco dei criteri di namespace si applica ai nomi corrispondenti indipendentemente dall’ordine degli adattatori, e un risultato vuoto lì non è un difetto quando l’helper non ha mai inteso crearne uno. Leggere tutti e tre prima di modificare è ciò che evita una riparazione che sposta solo il sintomo altrove.

Iniziate dal nome completamente qualificato. Se l’FQDN si risolve e il nome breve no, la lacuna è il suffisso o l’elenco di ricerca, non l’indirizzo del server.

Interrogate direttamente il server previsto come secondo passaggio, con qualunque strumento resolver già installato. Una risposta diretta dimostra che il server è raggiungibile e autorevole per la zona. Non dimostra nulla su quale server interroghi un’applicazione per impostazione predefinita.

Nominate il componente che possiede la connessione

Due disposizioni sono comuni. Un client avviato da un terminale passa esplicitamente il percorso del suo script, quindi il proprietario è visibile nel comando eseguito. Un’applicazione pacchettizzata avvia il client per voi e tiene l’helper nella propria directory, il che significa che il fornitore decide quando cambia.

Confrontate le versioni dell’helper tra installazioni prima di sostituire qualsiasi cosa. Eseguire con privilegi elevati un helper scaricato da un mirror perché il nome del file sembra familiare trasforma una lacuna DNS in un incidente di sicurezza.

Una volta noto il proprietario, l’obiettivo della riparazione diventa ovvio: un percorso di script supportato nel launcher, un aggiornamento del pacchetto o un profilo corretto sul gateway. Nessuno di questi richiede di modificare a mano le proprietà dell’adattatore.

Riparate il proprietario, non l’adattatore

Il DNS impostato a mano sull’adattatore spesso sopravvive alla disconnessione, per questo sembra funzionare e poi crea problemi sulla rete successiva. Un resolver pubblico avvitato su ogni interfaccia nasconde il problema del namespace privato invece di risolverlo. Quando l’helper non ha mai ricevuto un valore DNS, il profilo del gateway è il posto da guardare. Quando ne ha ricevuto uno e l’adattatore mostra ancora il vecchio server, l’helper ha fallito durante la connessione e il log del client di solito lo registra vicino alle righe di configurazione del tunnel.

Ricostruite lo stato tramite il percorso supportato, poi verificate un ciclo completo: connettete, risolvete l’FQDN privato, aprite il servizio, disconnettete e confermate che l’adattatore è tornato con i server precedenti.

Controllate l’applicazione che fallisce davvero

Un browser con la propria impostazione di DNS cifrato ignora tutto quanto sopra e continua a rispondere da un resolver pubblico. Un’applicazione che conserva una risposta negativa in cache da prima che il tunnel salisse si comporta allo stesso modo. Confrontatela con una normale query di sistema sulla stessa macchina prima di cambiare di nuovo gli indirizzi del resolver.

Se la query di sistema è corretta e l’applicazione no, il guasto rimanente è nella configurazione DNS di quell’applicazione, non nel percorso VPN.