Il tunnel diviso esclude il browser, non le sue query DNS

Browser escluso dal tunnel, la pagina dell’IP pubblico conferma che il suo traffico esce dalla connessione di casa, e il wiki interno continua a non aprirsi. La risoluzione dei nomi è andata altrove, e quell’altrove di solito è il resolver configurato dalla VPN. Il percorso dei dati e il percorso del resolver sono decisioni separate nella maggior parte dei progetti di tunnel diviso. Verificate quale ha usato davvero il browser prima di definire l’esclusione difettosa.

Il percorso dei dati e quello del resolver si separano

Un’esclusione rimuove i pacchetti di un’applicazione dal tunnel, il che è una decisione di routing e firewall sul percorso dei dati. La risoluzione dei nomi è un’altra ricerca: un processo interroga il resolver di sistema, e quel resolver decide quale server riceve la domanda.

Entrambi possono essere intenzionali e diversi. Un deployment aziendale può mantenere gli spazi dei nomi interni sul resolver aziendale mentre manda la navigazione pubblica selezionata fuori dal tunnel, proprio perché i nomi interni non si risolvono altrove. Il caso confuso è l’opposto: un sito pubblico fallisce perché il browser non ha mai interrogato il resolver che il deployment si aspettava. Annotate la rotta e il resolver separatamente, e metà delle discussioni sparisce.

Trovate quale processo pone la domanda

Un browser può usare il resolver di sistema, il proprio servizio DNS cifrato, o un resolver che il sistema operativo assegna per rete. Il primo segue la politica della piattaforma, il secondo aggira del tutto quella politica, e il terzo dipende da quale collegamento riceve la query.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Leggete la configurazione effettiva prima di testare: quali collegamenti portano server DNS, quali spazi dei nomi rivendicano, e se una politica per nome sostituisce il valore predefinito. Su Linux il DNS diviso usa domini di routing; su Windows la tabella delle politiche di risoluzione dei nomi fa lo stesso per gli spazi dei nomi. Nessuna delle due è visibile da una pagina di test delle perdite.

Decidete quale resolver deve vedere quale nome

Scrivete la mappatura prevista prima di cambiare qualcosa: nomi interni al resolver aziendale, nomi pubblici al servizio che la politica consente, ed eccezioni con un responsabile. Senza quell’elenco, ogni etichetta del test delle perdite diventa una discussione politica che nessuno può chiudere.

Poi controllate l’impostazione del browser stesso, perché il DNS cifrato nel browser si applica prima che il sistema operativo riceva la query. Un utente che l’ha attivato per aggirare un portale captive ha silenziosamente sostituito il resolver scelto dal deployment. È una decisione di configurazione e non una perdita, e merita una decisione invece di una lista di blocco.

Non riscrivete ogni campo DNS per far diventare verde un’etichetta di test. L’etichetta descrive una query di un processo in un istante.

Verificate query e connessione separatamente

Provate i due percorsi separatamente. Il test di connessione mostra la rotta dei dati, e il test del resolver mostra chi ha ricevuto il nome.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Interrogate anche esplicitamente il resolver, così un guasto può essere attribuito al server e non al percorso. Poi riavviate il browser e ripetete, perché le applicazioni mettono in cache le risposte negative e un guasto vecchio sembra persistente.

Dopo una modifica approvata, annotate la rotta dei dati e il destinatario del resolver come due righe separate con la data. Se il comportamento torna alla prossima riconnessione, il profilo che lo fornisce è ciò che va corretto, non il browser.