Il VPN ha cambiato il mio DNS? Confrontate prima e dopo

Connettete il tunnel, aprite una dashboard privata e il nome si risolve in un indirizzo che non avete mai visto. Oppure accade il contrario: il browser continua a funzionare mentre uno strumento da riga di comando all’improvviso non risolve più nulla. Entrambi i risultati derivano dallo stesso cambiamento, e di solito lo si spiega con una frase sul VPN che "usa il proprio DNS", che non è abbastanza precisa per diagnosticare o verificare. In quella frase si nascondono due domande: quali richieste dovrebbe assumere questo profilo e la vostra macchina le ha davvero inviate al resolver che le è stato assegnato? Tenerle separate è tutto il metodo, perché un test che le mescola produce una risposta sbagliata e sicura di sé in entrambe le direzioni.

Perché un profilo fornisce un resolver

Dentro un tunnel, i nomi dietro l’estremità remota di solito si risolvono in indirizzi che esistono solo in quella rete. Una zona privata come corp.internal non ha delega pubblica, quindi il resolver che la serve deve essere raggiungibile dall’interno del tunnel. Lo stesso meccanismo serve un secondo scopo: quando le richieste uscirebbero altrimenti dal vostro provider, un resolver sul lato remoto tiene la query dentro il percorso cifrato. Per questo l’indirizzo del server DNS arriva come parte della politica della connessione e non come impostazione globale scelta una volta per la macchina.

L’indirizzo da solo non decide nulla. Un resolver può rispondere solo se esiste una rotta verso di esso, e il guasto più comune è un resolver raggiungibile solo finché il tunnel è attivo. Quando il tunnel cade e la politica resta, le richieste vanno a un indirizzo senza percorso, e il sintomo è un timeout anziché un errore pulito. Quella differenza conta quando leggete il risultato del test successivo, perché un timeout manda le persone verso impostazioni di trasporto che non sono mai state coinvolte.

Confrontate i due progetti prima di confrontare le risposte

Il tunnel completo e il DNS diviso producono aspettative opposte, e nessuno dei due è un malfunzionamento. Con un tunnel completo ogni richiesta può passare al provider o al resolver aziendale, quindi è atteso che i nomi pubblici rispondano diversamente dopo la connessione. Con il DNS diviso solo i domini elencati vanno al resolver privato mentre tutto il resto resta locale; su Windows l’elenco dei domini vive nella Name Resolution Policy Table, su macOS nei domini corrispondenti delle impostazioni DNS, e su un host systemd-resolved nei domini di routing per collegamento.

È questo il confronto da fare per primo, perché decide che cosa conta come difetto. Con il DNS diviso, un nome pubblico che risponde da un nuovo resolver è ciò che merita indagine, mentre un nome interno che risponde correttamente è il sistema che fa il suo lavoro. Con un tunnel completo, l’anomalia è un nome pubblico che risponde ancora dal resolver del vostro provider. La documentazione di Microsoft sulla risoluzione dei nomi VPN descrive l’ordine di Windows di queste regole, incluso come una voce di criterio corrispondente venga consultata prima dei server propri dell’adattatore.

C’è un terzo resolver nella stanza facile da dimenticare. Il DNS sicuro del browser risolve i nomi per conto proprio e può continuare a rispondere dopo che il tunnel ha cambiato la politica del sistema operativo, quindi una pagina che si carica dimostra che il resolver del browser ha funzionato, non che il profilo sia stato applicato. Se confrontate solo ciò che mostra il browser, metà delle volte state testando lo strato sbagliato.

Registrate una linea di base con una sola variabile

Cambiate il tunnel. Non cambiate anche il nome, lo strumento o il suffisso di ricerca nello stesso passo. Scegliete un nome che vi è consentito interrogare, annotate quale applicazione avete usato e scrivete o l’indirizzo tornato o l’errore esatto. Su Windows, Get-DnsClientServerAddress -AddressFamily IPv4 stampa i server per adattatore e Get-DnsClientNrptPolicy stampa le voci di criterio; su Linux con systemd-resolved, resolvectl status mostra i server DNS e i domini di routing per collegamento; su macOS, scutil --dns stampa l’ordine dei resolver che il sistema seguirà davvero.

Poi connettetevi tramite i normali controlli del client e ripetete esattamente gli stessi comandi. Conservate il primo output invece di ricordarlo, perché il confronto è tutto il punto e una seconda lettura presa dopo lo svuotamento della cache è già un’altra misura. Se la linea di base è stata presa con il browser in primo piano e l’esecuzione dopo la connessione avviene in un terminale, state confrontando due resolver, non due stati di un solo resolver.

Una query esplicita e una ricerca dell’applicazione sono test diversi

Chiedere a un server specifico, con nslookup name 10.20.0.1 o dig @10.20.0.1 name, dimostra una sola cosa: che il server che avete nominato risponde quando potete raggiungerlo. Salta completamente la logica di selezione, quindi non può dirvi se il sistema avrebbe scelto quel server per questo nome. Usatelo per verificare se il resolver assegnato è raggiungibile, e non usatelo per verificare la politica.

Una ricerca attraverso il resolver locale esercita davvero la selezione. resolvectl query name percorre le stesse regole dei domini di routing e riporta quale protocollo ha risposto, Resolve-DnsName su Windows passa per la tabella dei criteri e la cache del client, e scutil --dns mostra l’ordine che una ricerca seguirebbe. Eseguite entrambi i tipi e teneteli in colonne separate dei vostri appunti. Una query esplicita riuscita accanto a una ricerca dell’applicazione fallita è un problema di routing o di selezione, non un resolver che si rifiuta di funzionare.

La cache sta tra voi e la risposta. Il sistema operativo, il resolver stub locale, il browser e la cache negativa trattengono tutti risultati, quindi una ricerca può riuscire senza che un solo pacchetto lasci la macchina. Registrate il risultato prima di svuotare qualsiasi cosa: ipconfig /flushdns, resolvectl flush-caches o sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder su macOS. Saltate il ripristino di rete ampio in questa fase, perché distrugge le prove che state ancora raccogliendo.

Che cosa significa la differenza

Confrontate le due righe registrate e classificate il cambiamento prima di toccare una sola impostazione.

Una riga merita enfasi. Un nome che si risolve non è un servizio che funziona, e il successo del DNS dice solo che è stato trovato un indirizzo. Non dice nulla sull’inoltro, sulle regole del firewall o se il vostro account possa usare il servizio, quindi chiudete testando l’applicazione reale invece di supporre che il guasto si sia ritirato da solo.

Ripristinate la linea di base e verificate

Disconnettetevi tramite i controlli del client invece di terminare il processo, poi rileggete gli stessi tre comandi. I server per collegamento, le voci di criterio e la risposta per il nome di test dovrebbero tornare alla linea di base annotata. Una voce di criterio rimasta dopo una disconnessione pulita è un difetto reale che vale la pena registrare, ed è anche il motivo per cui le modifiche a mano a un file di resolver generato sono una cattiva abitudine: il file viene riscritto e la modifica sparisce, oppure la modifica sopravvive e fissa un resolver che non ha più una rotta.

Percorrete questa lista una volta, in ordine. Decidete quale progetto implementa il profilo prima di giudicare qualsiasi risultato. Tenete nome, strumento e suffisso fissi nelle due esecuzioni. Separate la query esplicita dalla ricerca dell’applicazione. Leggete la politica effettiva, non solo la risposta. Svuotate le cache per ultime, dopo che il confronto è scritto. Verificate con l’applicazione reale, poi riavviate una volta e confermate che lo stato disconnesso è ancora pulito.