Per què resolv.conf mostra el DNS de la VPN però les consultes l'ignoren

Als registres no hi ha res que sembli malament: la interfície està activa, el resolutor informa del servidor DNS de la VPN i el fitxer al disc l'esmenta. I tot i així, un nom d'amfitrió intern encara es resol a través del router local. Aquestes tres afirmacions no es contradiuen, perquè el fitxer, l'estat de cada enllaç i el camí de la consulta són objectes diferents que casualment comparteixen nom. A continuació es descriu el camí que una consulta recorre realment en un amfitrió amb systemd-resolved.

Tres objectes anomenats resolv.conf

En un amfitrió amb resolved, /etc/resolv.conf sol ser un enllaç simbòlic a /run/systemd/resolve/stub-resolv.conf. Aquest objectiu conté l'adreça d'un escoltador stub local, 127.0.0.53, més els dominis de cerca que resolved ha calculat. És una vista de l'estat, no l'estat mateix.

L'estat viu a la configuració per enllaç de resolved, i per això resolvectl status pot discrepar del fitxer i tot i així tenir raó. Cada enllaç porta els seus propis servidors i els seus propis dominis d'encaminament, i el stub consulta aquestes dades quan arriba una consulta. El manual de systemd-resolved descriu els fitxers generats i el model per enllaç; la separació entre vista i estat és la part que val la pena retenir. Editar l'objectiu de l'enllaç simbòlic canvia el que llegeixen els clients tradicionals, no el que sap el resolutor.

Un tercer objecte, /run/systemd/resolve/resolv.conf, aplana cada enllaç en una sola llista de servidors. Un programa apuntat a aquest fitxer envia les consultes directament als servidors llistats i s'alta el stub, de manera que la política per enllaç ja no li és aplicable. Per tant, dos programes a la mateixa màquina poden respondre el mateix nom de manera diferent, i cap dels dos no està espatllat.

Ressegueix una consulta a través d'NSS

glibc llegeix /etc/nsswitch.conf per decidir qui respon un nom. Una línia hosts que contingui resolve encamina la pregunta a nss-resolve, que pregunta a resolved per D-Bus i rep la resposta per enllaç. Una línia amb només files dns envia la consulta a l'adreça que tingui /etc/resolv.conf.

Aquesta sola línia explica la majoria de desacords entre un navegador i dig. dig llegeix resolv.conf directament i no toca mai NSS, així que prova el stub o un servidor superior en lloc del camí que fa servir l'aplicació. getent hosts internal.example passa per NSS, i comparar la seva resposta amb la de dig és la primera mesura útil.

Les aplicacions que incorporen el seu propi resolutor, o que parlen DNS sobre HTTPS amb un punt final fix, eviten tots dos camins. Res a resolv.conf ni a l'estat de resolved no les limita.

Comprova qui posseeix el fitxer i cap a on apunta

Llegeix la cadena d'enllaços abans de canviar res, perquè la propietat decideix quin fitxer és l'autoritatiu. Cada ordre d'aquí sota només llegeix estat.

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

La primera línia imprimeix l'enllaç i el seu objectiu junts, i un fitxer normal propietat d'un script de VPN significa que el resolutor mai no tracta aquesta escriptura com a entrada. La sortida d'estat llista els servidors per enllaç més els dominis d'encaminament que decideixen on va cada consulta. La línia nsswitch diu si el stub es consulta o no, així que una adreça stub al fitxer sense resolve allà significa que les consultes arriben a l'escoltador local mentre res no gestiona la divisió. Aquest darrer llistat també importa, perquè un amfitrió sense stub-resolv.conf no executa el dispositiu aquí descrit.

Si la cadena acaba en un fitxer que gestiona un altre paquet, el client VPN i aquest paquet són els dos propietaris a reconciliar. Substituir l'enllaç descarta la feina d'un propietari i deixa la de l'altre al seu lloc.

Repara al propietari de l'enllaç

Una connexió VPN hauria de registrar els seus servidors i els seus dominis al seu propi enllaç i treure'ls en desconnectar. La integració de resolved de NetworkManager i l'ajudant propi d'un client funcionen així; un script que només reescriu resolv.conf no ho fa.

En un enllaç que ja existeix, la configuració en temps d'execució mostra el mecanisme. resolvectl dns tun0 10.40.0.53 adjunta un servidor, i resolvectl domain tun0 '~corp.example' adjunta un domini d'encaminament. La titlla és el caràcter que sosté tot: confina les consultes d'aquest sufix a aquest enllaç i deixa la resta tranquil·la, mentre que el mateix valor sense ella es converteix en un domini de cerca i la divisió s'esvaeix. Aquestes adreces són exemples de laboratori, no una configuració persistent. Confirma-ho amb resolvectl query host.corp.example i llegeix quin enllaç ha respost.

Un servidor registrat encara necessita una ruta. Quan la consulta arriba a l'enllaç correcte i expira, la fallada és de connectivitat a través del túnel, no de propietat del resolutor.

Com es veu un estat que funciona

Un resultat sa és coherent a les tres vistes: els servidors per enllaç coincideixen amb el que la VPN ha repartit, els dominis d'encaminament cobreixen només sufixos interns, i l'aplicació que importa resol un nom intern mentre un nom públic encara segueix el camí local. Una consulta amb èxit demostra menys que aquesta concordança.

Després desconnecta i repeteix les dues consultes. Un client que deixa els seus dominis registrats després del desmuntatge produeix una màquina que falla les consultes internes hores més tard, sense túnel obert i sense cap causa òbvia.