DNS diviso e VPN: le regole di dominio non sono rotte IP

Il vostro portatile risolve intranet.corp attraverso il tunnel mentre gitlab.com continua ad andare al resolver del fornitore, e questa è la disposizione che funziona come progettata. Due decisioni separate l’hanno prodotta: una regola di corrispondenza dei nomi ha scelto il resolver e una rotta ha riportato la risposta. Rompete una delle due e il browser mostra un guasto che dall’esterno sembra uguale. La maggior parte dei resoconti sul DNS diviso descrive il secondo guasto citando prove sul primo.

Le due metà vivono in luoghi diversi e di solito sono modificate da persone diverse. Una è la politica DNS allegata al profilo VPN, l’altra è una rotta che il tunnel installa o trattiene. Il debug si blocca quando nessuno stabilisce quale metà si è davvero mossa.

Due decisioni nascoste in una richiesta

La metà del nome è un oggetto di politica, non una rotta. Su Windows è una politica di risoluzione dei nomi sul profilo VPN; sulle piattaforme Apple un insieme di domini di corrispondenza su un oggetto impostazioni DNS; su Linux un dominio di routing, una riga di resolver diviso o l’ordine dello switch dei servizi dei nomi. La metà del percorso è routing ordinario, installato dal tunnel o a mano, e non ha idea di cosa sia un nome host. Un profilo che ammette un suffisso decide solo chi risponde; non rende mai la risposta raggiungibile.

Un rapido test dei sintomi le separa: sostituite il nome con un indirizzo. Se l’indirizzo funziona, il percorso è a posto e la regola è sbagliata. Se anche l’indirizzo fallisce, la regola può essere giusta e il percorso mancante.

Come ogni piattaforma esprime la stessa regola di nome

L’intento è identico e i nomi dei campi non lo sono. Un esempio copiato da un client all’altro viene analizzato correttamente e non corrisponde mai. Le tre forme sono così:

Un dominio di corrispondenza o di routing è un test di suffisso, quindi intranet.corp copre git.intranet.corp e non copre corp.intranet, e invertirlo è l’errore più comune dell’intera configurazione. Windows porta la mappatura come politica di risoluzione dei nomi allegata al profilo, con il proprio ordine di precedenza rispetto a qualsiasi elenco di suffissi che l’interfaccia avesse già. Le piattaforme Apple allegano i domini di corrispondenza all’oggetto impostazioni DNS dell’estensione di rete, e il sistema li applica per ogni resolver con ambito. Nessuna di queste forme è una rotta, e nessuna può rendere raggiungibile un indirizzo irraggiungibile. Il riferimento politica di risoluzione dei nomi di Windows elenca i nomi dei campi e le regole di precedenza per quella piattaforma, e non sono quelle usate dai documenti Apple o systemd.

Una risposta corretta ha comunque bisogno di un percorso

La risposta di un resolver è solo un indirizzo, e l’applicazione deve ancora raggiungerlo. Un progetto di tunnel diviso spesso spinge 10.20.0.0/16 e trattiene la rotta predefinita, così il nome interno si risolve e la connessione poi si blocca. Il caso opposto è altrettanto comune: la rotta esiste, un resolver pubblico risponde al nome privato con NXDOMAIN e il guasto viene archiviato come problema di routing. Testare prima il percorso vi lascia a fissare rotte per un nome che non si sarebbe mai risolto.

C’è anche una terza porta che nessuna metà copre. Un ACL sul gateway, una regola del firewall o una politica lato client possono far cadere la connessione dopo che entrambe le decisioni erano corrette. Quando il nome si risolve, la rotta esiste e la connessione scade ancora, smettete di testare il DNS.

Testare nomi e percorsi in un ordine fisso

Scegliete un ordine e mantenetelo, altrimenti inseguirete il passo che ha fallito più di recente. Risolvete il nome interno completo documentato, confermate che la risposta è un indirizzo che la tabella di routing può portare, poi ripetete con un nome pubblico per dimostrare che il tunnel non ha catturato tutto. Su un host systemd la query e il dominio di routing del resolver distano un comando:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Un client Windows pone le stesse due domande con altri cmdlet. Il secondo riporta l’interfaccia che il sistema userebbe davvero:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Se la ricerca restituisce un indirizzo e il controllo del percorso nomina l’interfaccia fisica, la regola dei nomi ha funzionato e la rotta no. Se il nome corto fallisce mentre il nome completo si risolve, l’elenco dei suffissi è sbagliato e non il resolver.

Dove il confronto di solito va storto

Il primo errore è chiedere a un resolver pubblico non correlato di un nome privato e leggere il rifiuto come prova sulla VPN. Il secondo è supporre che una ricerca pubblica funzionante dimostri il percorso del resolver del tunnel. Il terzo è trattare tunnel diviso e DNS diviso come un’unica decisione di progetto, quando un deployment può essere corretto in uno e rotto nell’altro. Ogni errore produce conclusioni sicure da un test che non ha mai esercitato la parte accusata.

Un browser con il proprio DNS sicuro può anche aggirare la regola di sistema, per questo il fatto che un browser fallisca mentre un altro riesce non è una contraddizione. Confrontate il resolver che ha risposto, non il browser che si è lamentato.

Una volta che entrambe le metà sono visibili, la domanda che resta è di politica e non tecnica: quali spazi dei nomi appartengono all’organizzazione, chi possiede ogni risposta e quali di essi dovrebbero lasciare la macchina. Scrivetelo accanto al profilo, perché la prossima persona che toccherà la regola ne avrà bisogno.