Per què la teva entrada a /etc/hosts no arriba al DNS de la VPN

Has afegit un nom a /etc/hosts, has connectat la VPN i esperaves que el registre aparegués per a tothom. No passa, i la sorpresa sol venir amb un segon símptoma: el nom es resol a la teva màquina i falla a la d'un company, cosa que sembla un servei DNS de VPN trencat i en realitat és el fitxer hosts fent exactament allò per a què va ser dissenyat. Un fitxer hosts és configuració local de resolució de noms, no una actualització de zona, i res en una connexió VPN normal el puja.

Hosts és una substitució local, no una actualització de zona

El fitxer és una llista de mapatges que les biblioteques de servei de noms consulten abans de, o en lloc de, preguntar a un servidor DNS. Una línia com 10.40.0.20 build.corp.example canvia el que conclouen les aplicacions d'aquella única màquina. No crea cap registre, no viatja pel túnel, i el servidor DNS al qual apunta el túnel no té ni idea que existeix.

Per això la fallada és asimètrica. El teu client obté una resposta del fitxer. Un altre client pregunta al servidor DNS de la VPN, que no retorna res, i l'aplicació informa que el nom no existeix. Totes dues màquines es comporten correctament; només una té una substitució que l'altra no ha vist mai.

Dos ordres, dos components diferents

La manera més ràpida d'aturar la discussió és fer visible la diferència en dues ordres, totes dues executades al client que té l'entrada a hosts:

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

La primera pregunta el camí de consulta propi del sistema, que en un sistema glibc típic llegeix fitxers locals abans que el DNS. La segona envia una consulta DNS directament al servidor d'aquella adreça i no consulta cap fitxer local. Quan la primera retorna la teva entrada i la segona retorna NXDOMAIN, has demostrat que el registre no existeix al DNS i que la teva màquina respon des d'una substitució local.

L'ordre és configurable, i val la pena comprovar-lo abans de concloure res sobre una distribució concreta. Mira la línia hosts: a /etc/nsswitch.conf; hosts: files dns consulta primer els fitxers. No copiïs aquell exemple sobre una configuració que funciona només per canviar l'ordre, perquè els sistemes reals sovint llisten fonts addicionals i entrades de servei condicionals que l'exemple no porta.

systemd-resolved enterboleix la prova

En un sistema que fa servir systemd-resolved, el stub local també serveix noms de la base de dades hosts. Per tant, consultar 127.0.0.53 no és una prova independent del servidor remot, encara que sembli una consulta DNS i es comporti com una. Pots confirmar què sap el resolutor i quins servidors preguntaria amb:

resolvectl query build.corp.example
resolvectl status

La sortida de status anomena els servidors DNS per enllaç, i així és com esbrines si l'enllaç de la VPN ha rebut cap resolutor. Aquesta pregunta és separada de l'entrada a hosts i és la que val la pena fer quan un nom privat falla per a tots els usuaris i no només per a un.

Les aplicacions poden afegir una altra capa. Un navegador amb la seva pròpia configuració de DNS-over-HTTPS, un contenidor amb la seva pròpia configuració de resolutor, o un entorn d'execució que emmagatzema consultes durant tota la vida del procés poden respondre cadascun de manera diferent del sistema. Prova l'aplicació que t'importa en lloc de suposar que una ordre descriu tots els programes de la màquina.

Què comparteix realment un nom a través de la VPN

Si un nom privat ha de funcionar per a tothom, necessita un propietari que el resolutor de tothom pugui assolir. La resposta neta és publicar el registre en una zona gestionada i fer que aquesta zona sigui resoluble pel camí DNS previst de la VPN. Llavors el registre té una sola font de veritat, un rastre d'auditoria i un cicle de vida, i ningú no ha de recordar quin portàtil porta una substitució local.

Distribuir fitxers hosts és una alternativa legítima, i és gestió d'equips finals més que servei de noms. Si la tries, el fitxer ha de ser desplegat, versionat i retirat per allò que gestiona el parc, i així s'ha de descriure al disseny. «La VPN se n'encarrega» no és una descripció d'aquest procés.

El registre dinàmic de DNS és un tercer mecanisme, amb els seus propis permisos, autenticació d'actualitzacions i vida útil del registre. No es deriva d'una entrada a hosts, i tampoc no es deriva d'un client que simplement es connecta, tret que el servidor i el client estiguin tots dos configurats per fer-ho. Un registre que apareix sol és un senyal que algú ha activat les actualitzacions segures i un client que es registra a si mateix, i aquesta configuració pertany al registre de disseny i no a un fil de resolució de problemes. Si ningú no pot dir qui posseeix aquest paràmetre, tracta el registre automàtic com a no verificat i mantén la zona gestionada com a font de veritat.

Un nom resolt no és una ruta

La resolució de noms i l'abastabilitat són coses separades, i un mapatge local obsolet és la manera clàssica de confondre-les. Una entrada a hosts que apunta a una adreça que s'ha mogut continuarà seleccionant l'amfitrió obsolet molt després que el DNS s'hagi corregit, i el símptoma sembla una fallada d'encaminament en un nom que es resol bé.

Així, quan l'informe és «el nom es resol però el servei no és abastable», compara la consulta del sistema amb una consulta explícita al servidor DNS de la VPN, i després comprova l'adreça que has obtingut amb la que el servei fa servir realment. La referència de systemd-resolved documenta les fonts locals que consulta, i aquest és el mapa que necessites per a aquesta comparació.

Després corregeix la substitució a través del seu propietari. Treure una línia del teu propi fitxer hosts no fa res pels dotze portàtils que van rebre la mateixa línia d'un script de desplegament, i aquesta és la versió d'aquest problema que la gent té de debò.