Por que a túa entrada en /etc/hosts non chega ao DNS da VPN

Engadiches un nome en /etc/hosts, conectaches a VPN e esperabas que o rexistro aparecese para todos. Non ocorre, e a sorpresa adoita vir cun segundo síntoma: o nome resólvese na túa máquina e falla na dun compañeiro, o que parece un servizo DNS da VPN roto e en realidade é o ficheiro hosts facendo exactamente aquilo para o que foi deseñado. Un ficheiro hosts é configuración local de resolución de nomes, non unha actualización de zona, e nada nunha conexión VPN normal o sobe.

Hosts é unha substitución local, non unha actualización de zona

O ficheiro é unha lista de asignacións que as bibliotecas de servizo de nomes consultan antes de, ou en lugar de, preguntar a un servidor DNS. Unha liña como 10.40.0.20 build.corp.example cambia o que conclúen as aplicacións desa única máquina. Non crea un rexistro, non viaxa polo túnel, e o servidor DNS ao que apunta o túnel non ten nin idea de que existe.

Por iso o fallo é asimétrico. O teu cliente obtén unha resposta do ficheiro. Outro cliente pregunta ao servidor DNS da VPN, que non devolve nada, e a aplicación informa de que o nome non existe. Ambas as máquinas compórtanse correctamente; só unha ten unha substitución que a outra nunca viu.

Dous comandos, dous compoñentes distintos

A forma máis rápida de rematar a discusión é facer visible a diferenza en dous comandos, ambos executados no cliente que ten a entrada de hosts:

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

O primeiro pregunta pola propia ruta de busca do sistema, que nun sistema glibc típico le ficheiros locais antes que o DNS. O segundo envía unha consulta DNS directamente ao servidor dese enderezo e non consulta ficheiros locais en absoluto. Cando o primeiro devolve a túa entrada e o segundo devolve NXDOMAIN, demostraches que o rexistro non existe no DNS e que a túa máquina responde desde unha substitución local.

A orde é configurable, e paga a pena comprobalo antes de concluír nada sobre unha distribución concreta. Mira a liña hosts: en /etc/nsswitch.conf; hosts: files dns consulta primeiro os ficheiros. Non copies ese exemplo sobre unha configuración que funciona só para cambiar a orde, porque os sistemas reais adoitan listar fontes adicionais e entradas de servizo condicionais que o exemplo non inclúe.

systemd-resolved enturba a proba

Nun sistema que usa systemd-resolved, o stub local tamén serve nomes da base de datos hosts. Por iso consultar 127.0.0.53 non é unha proba independente do servidor remoto, aínda que pareza unha consulta DNS e se comporte como tal. Podes confirmar que sabe o resolutor e a que servidores preguntaría con:

resolvectl query build.corp.example
resolvectl status

A saída de status nomea os servidores DNS por ligazón, e así é como descubres se a ligazón da VPN recibiu algún resolutor. Esa pregunta está separada da entrada de hosts e é a que paga a pena facer cando un nome privado falla para todos os usuarios e non para un.

As aplicacións poden engadir outra capa. Un navegador coa súa propia configuración de DNS-over-HTTPS, un contedor coa súa propia configuración de resolutor ou un contorno de execución que almacena consultas durante toda a vida do proceso poden responder cada un de forma distinta ao sistema. Proba a aplicación que che importa en lugar de supoñer que un comando describe todos os programas da máquina.

Que comparte realmente un nome a través da VPN

Se un nome privado ten que funcionar para todos, necesita un propietario ao que o resolutor de todos poida chegar. A resposta limpa é publicar o rexistro nunha zona xestionada e facer que esa zona sexa resoluble pola ruta DNS prevista da VPN. Entón o rexistro ten unha soa fonte de verdade, un rastro de auditoría e un ciclo de vida, e ninguén ten que lembrar que portátil leva unha substitución local.

Distribuír ficheiros hosts é unha alternativa lexítima, e é xestión de equipos finais máis que servizo de nomes. Se a elixes, o ficheiro ten que ser despregado, versionado e retirado polo que xestione o parque, e así debe describirse no deseño. «A VPN encárgase diso» non é unha descrición dese proceso.

O rexistro dinámico de DNS é un terceiro mecanismo, cos seus propios permisos, autenticación de actualizacións e vida útil do rexistro. Non se deriva dunha entrada de hosts, e tampouco se deriva dun cliente que simplemente se conecta, a non ser que o servidor e o cliente estean ambos configurados para facelo. Un rexistro que aparece só é un sinal de que alguén activou as actualizacións seguras e un cliente que se rexistra a si mesmo, e esa configuración pertence ao rexistro de deseño e non a un fío de resolución de problemas. Se ninguén pode dicir quen é o propietario dese axuste, trata o rexistro automático como non verificado e mantén a zona xestionada como fonte de verdade.

Un nome resolto non é unha ruta

A resolución de nomes e a alcanzabilidade son cousas separadas, e unha asignación local obsoleta é a forma clásica de confundilas. Unha entrada de hosts que apunta a un enderezo que se moveu seguirá seleccionando o host obsoleto moito despois de que se corrixise o DNS, e o síntoma parece un fallo de encamiñamento nun nome que se resolve ben.

Así que cando o informe é «o nome resólvese pero o servizo non é alcanzable», compara a consulta do sistema cunha consulta explícita ao servidor DNS da VPN e despois comproba o enderezo que obtiveches co que o servizo usa realmente. A referencia de systemd-resolved documenta as fontes locais que consulta, e ese é o mapa que necesitas para esa comparación.

Despois corrixe a substitución a través do seu propietario. Quitar unha liña do teu propio ficheiro hosts non fai nada polos doce portátiles que recibiron a mesma liña dun script de despregamento, e esa é a versión deste problema que a xente ten de verdade.