Perché nslookup risolve sulla VPN ma il browser no

nslookup invia una query al server che indicate e stampa la risposta, per questo può riuscire mentre ogni scheda del browser fallisce. Il browser chiede al sistema operativo di risolvere, e il sistema soppesa i resolver per interfaccia, le regole dei criteri di risoluzione dei nomi e la posizione di rete dell'adattatore. Poi il browser può aggiungere il proprio DNS cifrato sopra. Tre percorsi diversi, un sintomo, e il tunnel di solito non è la parte guasta.

I controlli seguenti seguono quei percorsi dal sistema verso l'esterno. Non modificate il profilo VPN prima di sapere quale percorso ha risposto e quale ha fallito.

Tre criteri decidono la risposta

Ogni interfaccia porta la propria lista di resolver e i propri suffissi di ricerca. Un adattatore VPN aggiunge server mentre l'adattatore fisico conserva i suoi, e il sistema può prendere quello che risponde per primo, così una risoluzione può essere servita fuori dal tunnel senza che nessuno lo abbia scelto. Le regole della tabella dei criteri di risoluzione dei nomi possono inviare domini scelti a server scelti, ed è così che di solito si esprime il DNS separato su Windows. E il client o il gateway VPN possono spingere un indirizzo di resolver che esiste solo dentro la rete privata.

Questi tre interagiscono in modi che dal browser sembrano arbitrari. Un resolver spinto su un indirizzo privato senza rotta attraverso il tunnel separato fa bloccare ogni risoluzione e poi fallire. Una regola di criterio che copre il suffisso interno e punta a un server spento produce lo stesso errore visibile di una rotta mancante. Un suffisso di ricerca mancante sull'adattatore VPN trasforma un nome breve in una query pubblica per il dominio sbagliato. Ognuno richiede una riparazione diversa.

Perché il browser pone un'altra domanda

nslookup emette la propria query verso il server che sceglie e non segue né i criteri dello spazio dei nomi né l'impostazione del DNS cifrato del browser. Per questo una query manuale verso un resolver pubblico risponde mentre il browser segnala che il sito non esiste. State confrontando due programmi, non due stati di un programma.

La preferenza di famiglia di indirizzi spiega un ritardo, non un guasto. Un browser che chiede prima record IPv6 su un tunnel che trasporta solo IPv4 attende la scadenza del timeout prima di retrocedere. Firefox ha portato una preferenza proprio per questo, e disattivarla è un passo diagnostico, non una riparazione.

Leggete la lista dei resolver e le regole

Su Windows, stampate ciò che il sistema tiene prima di teorizzare. Get-DnsClientServerAddress mostra i server per interfaccia, Get-DnsClientNrptRule elenca le regole dello spazio dei nomi e Resolve-DnsName risponde al nome esatto attraverso il percorso di sistema. Confrontate quella risposta con una query diretta al server della VPN per indirizzo. Quando Resolve-DnsName fallisce e la query diretta riesce, il sospetto è la lista dei resolver o una regola dello spazio dei nomi.

Controllate anche il nome stesso. Un nome breve interno può richiedere il suffisso privato che solo l'adattatore VPN fornisce, mentre il nome completamente qualificato si risolve bene. Un avviso di certificato dopo una risoluzione riuscita appartiene a un altro problema.

Il resolver spinto irraggiungibile

Il gateway o il client possono spingere un indirizzo di resolver, e quell'indirizzo deve essere raggiungibile attraverso il tunnel. Su un tunnel separato, l'intervallo privato che contiene il resolver può non essere tra le rotte incluse, il che produce una risoluzione che non riceve mai risposta. Confermate che la rotta esista, poi interrogate quell'indirizzo specificamente, attraverso il tunnel. È il guasto dietro un errore di dominio nel browser mentre un resolver pubblico risponde ancora.

Se il resolver è irraggiungibile, la riparazione è una rotta o una sottorete inclusa, non un altro server DNS.

Il DNS cifrato aggira tutto il percorso

I browser con DNS-over-HTTPS risolvono i nomi da soli tramite una connessione HTTPS a un provider scelto. Con questa opzione attiva, il resolver di sistema e le regole del DNS separato vengono aggirati del tutto per quelle risoluzioni, così i nomi interni falliscono nel browser mentre il sistema operativo li risolve correttamente. Accade anche il contrario: nomi interni riescono nel browser tramite un provider che non avrebbe mai dovuto vederli, e questo è un problema di criteri, non di connettività.

Decidete deliberatamente se il DNS cifrato è ammesso sui dispositivi gestiti, poi configuratelo tramite la superficie di gestione del browser perché la scelta sia visibile. Lasciarlo alle preferenze individuali produce un parco in cui la stessa VPN si comporta diversamente su ogni portatile.

Riparazioni adeguate al guasto

Se la VPN spinge il proprio resolver, fate trasportare al tunnel il traffico verso di esso e rendete la stessa impostazione visibile sugli adattatori che partecipano alla risoluzione. Se i siti locali smettono di risolversi mentre siete connessi, aggiungete eccezioni esplicite di spazio dei nomi o un inoltro condizionale invece di sostituire il resolver in blocco. Se il DNS cifrato del browser aggira i criteri, è quella l'impostazione da cambiare. Non aggiungete mai un resolver pubblico per correggere un nome interno: filtra query private e non risolve il nome.

Poi separate la risoluzione dalla connessione. Un nome che si risolve all'indirizzo giusto ma rifiuta una connessione è un problema di servizio, firewall o certificato, e le modifiche DNS non lo correggeranno.

Annotate quale percorso ha risposto, quale ha fallito e cosa avete cambiato. Il prossimo rapporto sullo stesso sintomo costerà allora un comando invece di un pomeriggio.