La VPN ha preso il controllo del DNS e rotto i nomi locali: ripara l’elenco

Il tunnel sale, l’intranet si carica e il nome della stampante smette di risolversi. O il contrario: i nomi locali funzionano ancora mentre tutto ciò che è dentro la rete aziendale va in timeout. Entrambi i sintomi vengono dallo stesso punto, un elenco di resolver che il client VPN ha riscritto alla connessione.

Ripara l’elenco di proposito, poi affronta il meccanismo push separatamente. Le rotte sono un terzo argomento e non è quello che si ripara qui.

Quale elenco usano davvero le applicazioni

Windows risolve tramite impostazioni a livello di interfaccia e non tramite ciò che mostra una finestra di dialogo, quindi inizia dagli elenchi effettivi per interfaccia. L’alias conta più del nome visualizzato, perché ogni comando qui sotto si rivolge a un’interfaccia. Sbaglia l’alias e la riparazione finirà sull’adattatore sbagliato. Sembrerà funzionare fino alla prossima riconnessione, quando tornerà la voce del tunnel stesso.

La domanda è quali server sono finiti davanti e se sono arrivati come voci statiche o come lease DHCP. Entrambi i fatti decidono quale riparazione hai a disposizione.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Leggi l’output per l’adattatore del tunnel e per quello fisico, e annota ogni indirizzo su ciascuno. Una voce statica può essere rimossa da un criterio o da uno script; una fornita da DHCP è legata al lease e tornerà, il che cambia la riparazione da scegliere. I nomi nella rete remota li risolve il resolver annunciato, quelli nella LAN locale l’adattatore fisico, e la query va all’elenco consultato per primo.

Rimuovi i server spinti, o mettili più in basso

Elimina i server spinti quando nulla dentro il tunnel ne ha bisogno, perché i resolver dell’adattatore fisico riprendono il sopravvento. Tienili solo se la rete remota possiede zone a cui solo i suoi server possono rispondere, e in quel caso metti un resolver locale davanti a loro. I due comandi qui sotto coprono entrambe le scelte, quindi scegli quello che corrisponde alla situazione invece di eseguirli entrambi.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

L’indice 1 viene consultato per primo, quindi gli indirizzi spinti restano disponibili ma smettono di essere la risposta predefinita a ogni query. Il flag validate=no salta un test di raggiungibilità che spesso fallisce mentre il tunnel si sta ancora assestando, quindi conferma il risultato con il comando show invece di fidarti del codice di uscita.

Vale la pena conoscere due limiti prima di farci affidamento. Windows non eliminerà i server arrivati via DHCP attraverso netsh, e quei valori persistono come DhcpNameServer sotto la chiave di registro dell’interfaccia, quindi modificare il registro è un ultimo ricorso da ricontrollare dopo il lease successivo. Anche l’ordine di binding degli adattatori non è un meccanismo di classificazione affidabile, perché un client VPN può inserire la propria voce in cima all’elenco.

Dove si può filtrare il push

Una riparazione migliore rimuove l’opzione prima che venga applicata. Il client Community OpenVPN può filtrare una direttiva spinta per nome, il che lascia intatta la configurazione del server.

pull-filter ignore "dhcp-option DNS "

Lo spazio finale appartiene alla corrispondenza e il filtro nomina l’opzione, non un indirizzo di server. Se il profilo contiene anche una direttiva block-outside-dns, rimuoverla cambia la protezione dalle perdite e non la risoluzione dei nomi, quindi decidi a parte invece di raggruppare le due modifiche.

Per un singolo nome host ostinato, una riga nel file hosts di Windows è più stabile che riordinare i resolver per tutta la macchina. È anche invisibile alla persona successiva, quindi annotala dove la configurazione della macchina è documentata.

Fai sopravvivere la riparazione a una riconnessione

La risoluzione va testata due volte, una contro un server scelto e una nella forma che usa un’applicazione. Questa coppia separa un problema di ordine dei resolver da un server che non risponde affatto. Saltare il primo test lascia le due cause aggrovigliate.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Riconnetti il tunnel e ripeti entrambi i comandi. Ciò che hai cambiato a mano dura solo fino alla connessione successiva, perché il client ricostruisce il suo stato dei resolver mentre alza l’adattatore. Metti le righe netsh nello script di connessione supportato del tuo client, lascia che quello script termini con successo e aggiungi una breve attesa prima che venga eseguito. Un client che applica il DNS dopo lo script sovrascriverà comunque il risultato.

Se i nomi pubblici si risolvono e quelli interni falliscono ancora dopo la riparazione, l’elenco dei resolver non è più il sospetto. La query probabilmente non raggiunge affatto il server, il che punta a routing o a una regola del firewall e non a un’altra impostazione DNS. Annota l’alias dell’interfaccia e gli indirizzi su cui ti sei fermato, perché entrambi variano da macchina a macchina e nessuno dei due sopravvive da solo a una ricostruzione.