VPN connessa ma i nomi falliscono: dove si rompe davvero il DNS

Tunnel attivo, icona verde e ogni scheda del browser segnala un errore di risoluzione dei nomi. Tre meccanismi diversi producono questa immagine: il resolver può essere irraggiungibile, il client può interrogare un resolver che non si aspettava, oppure possono fallire solo i nomi privati. Separali prima di cambiare qualcosa nel protocollo del tunnel, perché ciascuno si ripara in un punto diverso. L'ordine seguente parte dalle osservazioni che separano i tre casi.

Cosa serve davvero a una query

Una query ha bisogno di tre cose: un indirizzo di resolver, una rotta verso quell'indirizzo e una risposta che corrisponda alla domanda. Ognuna può fallire da sola, e il sintomo visibile è la stessa pagina che non si carica. Per questo la pagina di errore non ti dice quasi nulla finché non sai quale dei tre si è rotto.

Il client apprende il proprio resolver dal profilo VPN, dal DHCP sul tunnel o dalla propria configurazione, e quale sorgente vince dipende dalla piattaforma. Su Windows, ipconfig /all elenca i server DNS per adattatore, così puoi vedere se il valore inviato è davvero arrivato. Un valore inviato che non ha mai raggiunto il sistema operativo è un guasto silenzioso e comune. Leggi il valore configurato prima di toccare il profilo.

Linux e macOS rispondono alla stessa domanda con comandi diversi, e la risposta merita la stessa lettura: resolvectl status e scutil --dns entrambi elencano i server per interfaccia. Confronta quell'elenco con l'indirizzo che il profilo dichiara di inviare. Un'incoerenza qui spiega tutto il resto, quindi risolvila prima di testare i nomi.

Prova un nome pubblico e uno privato

Interroga un normale nome host pubblico e il nome host privato documentato dalla stessa macchina, e annota quale server ha risposto a ciascuno. Se falliscono entrambi, il resolver o la sua rotta sono rotti. Se fallisce solo il nome privato, il resolver ha risposto e la domanda diventa la zona o l'instradamento. Esegui le due query a meno di un minuto di distanza perché un cambio di rotta non possa spiegare la differenza.

Tieni i nomi interni fuori dagli screenshot pubblici e dai resolver pubblici. Un timeout e una risposta di dominio inesistente sono osservazioni diverse: la prima dice che non è tornato nulla, la seconda che un'autorità ha risposto che il nome non esiste. Trattarli come un unico errore ti porta allo strato sbagliato, e un avviso di certificato è ancora una terza cosa, non un guasto DNS.

nslookup stampa sia il server interrogato sia la risposta ricevuta, ed è esattamente la coppia che ti serve. Eseguilo due volte nella stessa shell e scrivi l'indirizzo che risponde accanto a ogni risposta.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Verifica che il client riesca davvero a raggiungere quel server

Un resolver privato inviato dal profilo è utile solo se il client riesce a raggiungerlo mentre il tunnel è attivo. Un indirizzo che sembra corretto senza rotta produce un timeout, e lo stato connesso del tunnel non dice nulla su quella rotta. Il controllo è una ricerca di rotta rivolta al resolver stesso, non all'endpoint VPN.

Ogni piattaforma risponde in una riga, e l'interfaccia indicata nell'output è tutta la risposta. Se punta all'adattatore fisico mentre il resolver sta dietro il tunnel, il profilo non invia un prefisso che lo copra.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

In un profilo a tunnel diviso il resolver può stare fuori dalle rotte inviate, il che è un problema del profilo e non del server. Confronta l'indirizzo del resolver con i prefissi inviati e conferma che uno di essi lo copra. La stessa incoerenza spiega perché il DNS funziona su una rete e fallisce su un'altra con un profilo identico.

Ricorda che i browser possono aggirare il resolver di sistema

Un browser con DNS sicuro attivo può inviare query via HTTPS a un provider di sua scelta e ignorare del tutto il resolver del sistema operativo. Il sistema sembra allora corretto mentre il browser fallisce, o il contrario. È una questione di policy per il browser, non per il tunnel.

Controlla l'impostazione DNS sicuro del browser e qualsiasi policy gestita che la controlla, poi prova una seconda applicazione o un secondo browser con il tunnel invariato. Se fallisce una sola applicazione, la correzione appartiene a quell'applicazione. Una finestra privata non è un confronto pulito, perché può disattivare le estensioni per impostazione predefinita in un browser e non in un altro, e non aggira mai una policy gestita. Usa invece un secondo profilo del browser o un'altra applicazione.

Svuota la cache e ritesta il compito reale

Dopo aver corretto un'impostazione, svuota la cache locale del resolver perché una vecchia risposta non sopravviva alla correzione. Un breve recupero seguito da un nuovo guasto significa che la causa è ancora presente, non che lo svuotamento abbia fallito. Scegli la riga che corrisponde alla macchina su cui sei, perché le tre cache sono separate.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Poi ripeti il compito originale invece di una query sintetica, perché il compito è ciò che interessa all'utente. Riconnettiti una volta, così il nuovo test copre lo stato in cui l'utente sarà davvero. La documentazione di nslookup di Microsoft è la pagina da tenere per gli argomenti della query.

Se i nomi falliscono solo dopo la disconnessione, il client non ha ripristinato la configurazione precedente, il che è un bug del ciclo di vita da segnalare, non un server DNS da sostituire. Una query funzionante non è nemmeno un test di fuga, perché il paese di uscita non ti dice quale resolver ha risposto.