Por que resolv.conf mostra o DNS da túa VPN pero as consultas ignórano

Nos rexistros nada parece estar mal: a interface está activa, o resolutor informa do servidor DNS da VPN e o ficheiro do disco enumerao. Aínda así, un nome de host interno séguese resolvendo a través do encamiñador local. As tres afirmacións non se contradín, porque o ficheiro, o estado de cada ligazón e a ruta da consulta son obxectos distintos que casualmente comparten nome. O que segue é a ruta que unha consulta percorre realmente nunha máquina con systemd-resolved.

Tres obxectos chamados resolv.conf

Nunha máquina con resolved, /etc/resolv.conf adoita ser unha ligazón simbólica a /run/systemd/resolve/stub-resolv.conf. Ese destino contén o enderezo dun escoitador stub local, 127.0.0.53, ademais dos dominios de busca que resolved calculou. É unha vista do estado, non o estado mesmo.

O estado vive na configuración por ligazón de resolved, e por iso resolvectl status pode discrepar do ficheiro e aínda así ter razón. Cada ligazón leva os seus propios servidores e os seus propios dominios de encamiñamento, e o stub consulta eses datos cando chega unha consulta. O manual de systemd-resolved describe os ficheiros xerados e o modelo por ligazón; a separación entre vista e estado é a parte que paga a pena lembrar. Editar o destino da ligazón simbólica cambia o que len os clientes tradicionais, non o que sabe o resolutor.

Un terceiro obxecto, /run/systemd/resolve/resolv.conf, achanda cada ligazón nunha soa lista de servidores. Un programa apuntado a ese ficheiro envía as consultas directamente aos servidores listados e omite o stub, así que a política por ligazón xa non se lle aplica. Por iso dous programas na mesma máquina poden responder o mesmo nome de forma distinta, e ningún está roto.

Segue unha consulta a través de NSS

glibc le /etc/nsswitch.conf para decidir quen responde a un nome. Unha liña hosts que conteña resolve encamiña a pregunta a nss-resolve, que pregunta a resolved por D-Bus e recibe a resposta por ligazón. Unha liña con só files dns envía a consulta ao enderezo que teña /etc/resolv.conf.

Esa única liña explica a maioría dos desacordos entre un navegador e dig. dig le resolv.conf directamente e nunca toca NSS, así que proba o stub ou un servidor superior en lugar da ruta que usa a aplicación. getent hosts internal.example pasa por NSS, e comparar a súa resposta coa de dig é a primeira medición útil.

As aplicacións que incorporan o seu propio resolutor, ou que falan DNS sobre HTTPS cun extremo fixo, evitan ambas as rutas. Nada en resolv.conf nin no estado de resolved as limita.

Comproba quen é dono do ficheiro e cara a onde apunta

Le a cadea de ligazóns antes de cambiar nada, porque a propiedade decide que ficheiro é autoritativo. Cada orde de abaixo só le estado.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

A primeira liña imprime a ligazón e o seu destino xuntos, e un ficheiro normal propiedade dun script de VPN significa que o resolutor nunca trata esa escritura como entrada. A saída de estado enumera os servidores por ligazón máis os dominios de encamiñamento que deciden cara a onde vai cada consulta. A liña nsswitch di se o stub se consulta sequera, así que un enderezo stub no ficheiro sen resolve alí significa que as consultas chegan ao escoitador local mentres nada xestiona a división. Esa última listaxe tamén importa, porque unha máquina sen stub-resolv.conf non executa o arranxo aquí descrito.

Se a cadea remata nun ficheiro que xestiona outro paquete, o cliente VPN e ese paquete son os dous propietarios que hai que conciliar. Substituír a ligazón descarta o traballo dun propietario e deixa o do outro no seu sitio.

Repara no propietario da ligazón

Unha conexión VPN debería rexistrar os seus servidores e os seus dominios na súa propia ligazón e despois retiralos ao desconectar. A integración de resolved de NetworkManager e o axudante propio dun cliente funcionan así; un script que só reescribe resolv.conf non o fai.

Nunha ligazón que xa existe, a configuración en tempo de execución mostra o mecanismo. resolvectl dns tun0 10.40.0.53 achega un servidor, e resolvectl domain tun0 '~corp.example' achega un dominio de encamiñamento. O til é o carácter que sostén todo: confina as consultas dese sufixo a esta ligazón e deixa o demais en paz, mentres que o mesmo valor sen el convértese nun dominio de busca e a división evapórase. Eses enderezos son exemplos de laboratorio, non unha configuración persistente. Confírmao con resolvectl query host.corp.example e le cal ligazón respondeu.

Un servidor rexistrado aínda necesita unha ruta. Cando a consulta chega á ligazón correcta e caduca, o fallo está na accesibilidade a través do túnel e non na propiedade do resolutor.

Como se ve un estado que funciona

Un resultado san é coherente nas tres vistas: os servidores por ligazón coinciden co que repartiu a VPN, os dominios de encamiñamento cobren só sufixos internos, e a aplicación que importa resolve un nome interno mentres un nome público segue a ruta local. Unha consulta exitosa demostra menos que esa concordancia.

Despois desconecta e repite ambas as consultas. Un cliente que deixa os seus dominios rexistrados tras o desmontaxe produce unha máquina que falla as consultas internas horas despois, sen túnel aberto e sen causa evidente.