Perché la tua voce in /etc/hosts non raggiunge il DNS della VPN

Hai aggiunto un nome in /etc/hosts, ti sei connesso alla VPN e ti aspettavi che il record apparisse a tutti. Non succede, e la sorpresa di solito arriva con un secondo sintomo: il nome si risolve sulla tua macchina e fallisce su quella di un collega, il che sembra un servizio DNS della VPN guasto ed è in realtà il file hosts che fa esattamente ciò per cui è stato progettato. Un file hosts è configurazione locale di risoluzione dei nomi, non un aggiornamento di zona, e nulla in una normale connessione VPN lo carica.

Hosts è una sostituzione locale, non un aggiornamento di zona

Il file è un elenco di mappature che le librerie del servizio nomi consultano prima di, o al posto di, interrogare un server DNS. Una riga come 10.40.0.20 build.corp.example cambia ciò che le applicazioni su quella singola macchina concludono. Non crea un record, non viaggia attraverso il tunnel, e il server DNS verso cui punta il tunnel non ha idea che esista.

Per questo il guasto è asimmetrico. Il tuo client ottiene una risposta dal file. Un altro client interroga il server DNS della VPN, che non restituisce nulla, e l'applicazione segnala che il nome non esiste. Entrambe le macchine si comportano correttamente; solo una ha una sostituzione che l'altra non ha mai visto.

Due comandi, due componenti diversi

Il modo più rapido per chiudere la discussione è rendere visibile la differenza in due comandi, entrambi eseguiti sul client che ha la voce hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Il primo interroga il percorso di ricerca del sistema stesso, che su un tipico sistema glibc legge i file locali prima del DNS. Il secondo invia una query DNS direttamente al server a quell'indirizzo e non consulta affatto i file locali. Quando il primo restituisce la tua voce e il secondo restituisce NXDOMAIN, hai dimostrato che il record non esiste nel DNS e che la tua macchina risponde da una sostituzione locale.

L'ordine è configurabile, e vale la pena verificarlo prima di concludere qualcosa su una particolare distribuzione. Guarda la riga hosts: in /etc/nsswitch.conf; hosts: files dns consulta prima i file. Non copiare quell'esempio su una configurazione funzionante solo per cambiare l'ordine, perché i sistemi reali spesso elencano fonti aggiuntive e voci di servizio condizionali che l'esempio non contiene.

systemd-resolved confonde il test

Su un sistema che usa systemd-resolved, lo stub locale serve anche nomi dal database hosts. Interrogare 127.0.0.53 quindi non è un test indipendente del server remoto, anche se sembra una query DNS e si comporta come tale. Puoi confermare cosa sa il resolver e quali server interrogherebbe con:

resolvectl query build.corp.example
resolvectl status

L'output di status elenca i server DNS per collegamento, ed è così che scopri se il collegamento VPN ha effettivamente ricevuto un resolver. Questa domanda è separata dalla voce hosts ed è quella che vale la pena porsi quando un nome privato fallisce per tutti gli utenti e non per uno.

Le applicazioni possono aggiungere un altro livello. Un browser con la propria impostazione DNS-over-HTTPS, un container con la propria configurazione del resolver o un runtime che memorizza nella cache le ricerche per tutta la vita del processo possono ciascuno rispondere diversamente dal sistema. Prova l'applicazione che ti interessa invece di presumere che un comando descriva ogni programma sulla macchina.

Cosa condivide davvero un nome attraverso la VPN

Se un nome privato deve funzionare per tutti, ha bisogno di un proprietario che il resolver di tutti possa raggiungere. La risposta pulita è pubblicare il record in una zona gestita e rendere quella zona risolvibile tramite il percorso DNS previsto della VPN. Il record ha allora un'unica fonte di verità, una traccia di audit e un ciclo di vita, e nessuno deve ricordare quale portatile porta una sostituzione locale.

Distribuire file hosts è un'alternativa legittima, ed è gestione degli endpoint più che servizio dei nomi. Se la scegli, il file deve essere distribuito, versionato e rimosso da ciò che gestisce il parco, e va descritto così nel progetto. «Ci pensa la VPN» non è una descrizione di quel processo.

La registrazione DNS dinamica è un terzo meccanismo, con i propri permessi, l'autenticazione degli aggiornamenti e la durata del record. Non deriva da una voce hosts, e non deriva nemmeno da un client che si limita a connettersi, a meno che il server e il client non siano stati entrambi configurati per farlo. Un record che appare da solo è il segnale che qualcuno ha abilitato gli aggiornamenti sicuri e un client che si registra da solo, e quella configurazione appartiene al documento di progetto e non a una discussione di troubleshooting. Se nessuno sa indicare chi possiede quell'impostazione, tratta il record automatico come non verificato e mantieni la zona gestita come fonte di verità.

Un nome risolto non è una rotta

La risoluzione dei nomi e la raggiungibilità sono cose separate, e una mappatura locale obsoleta è il modo classico di confonderle. Una voce hosts che punta a un indirizzo che si è spostato continuerà a selezionare l'host obsoleto molto dopo che il DNS è stato corretto, e il sintomo sembra un guasto di routing su un nome che si risolve bene.

Quindi quando il rapporto è «il nome si risolve ma il servizio non è raggiungibile», confronta la ricerca di sistema con una query esplicita al server DNS della VPN, poi verifica l'indirizzo ottenuto rispetto a quello che il servizio usa realmente. Il riferimento di systemd-resolved documenta le fonti locali che consulta, e quella è la mappa che ti serve per quel confronto.

Poi correggi la sostituzione tramite il suo proprietario. Rimuovere una riga dal tuo file hosts non fa nulla per i dodici portatili che hanno ricevuto la stessa riga da uno script di distribuzione, e questa è la versione di questo problema che le persone hanno davvero.