Editar resolv.conf no arregla el DNS després que la VPN es desconnecti

Desconnectes la VPN, ping 1.1.1.1 encara respon, i cada consulta de nom es penja abans que la pàgina finalment es rendeixi. Llavors cat /etc/resolv.conf mostra un servidor de noms que només va existir mai dins del túnel, normalment el primer de la llista. Esborrar aquella línia sembla arreglar-ho durant uns deu minuts, fins que una suspensió, un roaming de Wi-Fi o un reinici el tornen a posar. El fitxer que has editat no és la configuració; és una representació de l’estat de l’enllaç que posseeix un altre component.

Per què una entrada obsoleta costa segons per consulta

El resolutor de glibc recorre la llista de servidors de noms en ordre i espera que passi un temps d’espera abans de provar el següent, i resolv.conf(5) limita aquesta llista a tres entrades. Posa un resolutor del costat del túnel com 10.8.0.1 al capdamunt després que el túnel hagi desaparegut i cada consulta paga el temps d’espera abans de passar a un servidor que respon. Per això el símptoma sembla una connexió morta i no una errada de DNS: els navegadors es bloquegen, es queden sense temps i de vegades serveixen una adreça en memòria cau que després queda obsoleta.

També explica per què la queixa arriba com «l’internet està trencat». Un ping a una adreça IP demostra que l’enllaç va bé, cosa que fa que la fallada sembli de l’aplicació. La llista de resolutors és la primera cosa a llegir i l’última a editar.

El mite: resolv.conf és un fitxer de configuració

Pregunta què és realment el camí abans de canviar-lo:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

En un amfitrió amb systemd-resolved és un enllaç simbòlic a un fitxer stub que apunta a 127.0.0.53, i els servidors reals viuen en l’estat per enllaç que imprimeix resolvectl. En un amfitrió amb NetworkManager pot ser un fitxer que NetworkManager escriu de la connexió activa. Amb alguns clients de fabricant és un fitxer pla reescrit al lloc en connectar-se i, si no tens sort, mai restaurat en desconnectar-se. Són tres propietaris diferents, i editar els dos primers a mà o no fa res o dura fins al proper esdeveniment de xarxa.

resolvectl status és la vista que diu la veritat: servidors DNS per enllaç, dominis d’encaminament i si l’enllaç del túnel encara existeix. resolvectl query example.com va més enllà i mostra quina interfície ha respost. Fes servir tots dos abans de tocar cap fitxer, i tingues present que un navegador amb DNS segur propi ignora tot això.

Troba el propietari abans d’editar res

Tres components solen competir per la mateixa configuració: systemd-resolved, NetworkManager i el que hagi instal·lat el client de VPN. Identifica primer el viu:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Si resolved és actiu i l’enllaç simbòlic apunta al seu stub, el fitxer global és sortida generada i la teva edició és cosmètica. Si NetworkManager posseeix la connexió, els servidors pertanyen al perfil de connexió, així que l’arranjament és un canvi de propietat amb nmcli i no una edició de fitxer. Si hi ha un dimoni del fabricant en marxa, només el seu propi camí de restauració sobreviu a la propera connexió.

Neteja l’estat de l’enllaç que el client ha deixat enrere

Un client mort no pot executar el seu hook de neteja. SIGKILL no es pot capturar de cap manera, mentre que SIGINT i SIGTERM sí, així que un túnel que «s’ha aturat» després d’una mort forçada sovint deixa al seu lloc tant el registre de la interfície com l’entrada del resolutor. Troba el PID concret i envia el senyal només a aquest:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

No compris pkill -f vpn ni killall vpn abans de llegir la llista completa de coincidències. -f coincideix amb tota la línia d’ordres, així que pot acabar amb un script embolcall, una sessió d’editor o un procés no relacionat el camí del qual conté la cadena. Acabar amb el procés equivocat a mig fer és com un problema de resolutor es converteix en un fitxer perdut.

resolvectl revert reinicia la configuració DNS d’execució d’aquell enllaç, cosa més estreta que reiniciar el resolutor i molt més estreta que editar el fitxer global. Si l’enllaç del túnel ha desaparegut del tot, systemctl restart NetworkManager reconstrueix l’estat de la connexió i és el pas al qual els fils d’origen tornen una i altra vegada. Vés amb compte amb un gestor de serveis amb Restart=always, perquè pot tornar a posar un client mort, i les seves opcions DNS, directament.

L’altra direcció: DNS empès que mai no ha arribat

La imatge mirall de l’entrada obsoleta és un túnel sense cap resolutor utilitzable. Una opció DNS al perfil és una petició; el component que gestiona la connexió ha de lliurar-la al resolutor. Si el registre mostra que el servidor s’ha rebut però l’enllaç del túnel no porta cap opció DNS, falta la integració, no el servidor.

Prova el lliurament fent-lo a mà, cosa que separa «el servidor està malament» de «ningú no l’ha aplicat»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

El domini d’encaminament comodí envia cada nom a aquell enllaç, que és el que vol un client de túnel complet i el que el DNS dividit no ha d’usar. Aquestes opcions desapareixen a la propera connexió. Per fer-les persistents a NetworkManager, desactiva el DNS automàtic, posa el servidor a la connexió i afegeix el domini:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Per a un túnel d’empresa que només ha de respondre noms interns, llista aquelles zones amb una titlla inicial en lloc del comodí, perquè els noms públics continuïn usant el resolutor local.

Solucions temporals que esdevenen la propera caiguda

Copiar resolv.conf abans de connectar i restaurar-lo després és una línia legítima en un runbook, i és una solució temporal i no una reparació. Falla exactament quan importa, perquè una caiguda o un reinici forçat salta la restauració. Anota-ho com a solució temporal perquè la propera persona no hi construeixi a sobre.

Desactivar systemd-resolved i fixar servidors públics és l’altra maniobra popular. Fa que connectar i desconnectar siguin previsibles i treu el DNS per enllaç de qualsevol altra xarxa, cosa que trenca el DNS dividit per als noms interns i desfà el propòsit d’un túnel pensat per mantenir les consultes a dins. Instal·lar resolvconf i fixar servidors públics costa el mateix amb una capa extra. Tracta qualsevol de les dues com un diagnòstic: si et torna la navegació, has après que la integració del resolutor és la culpable, no que els servidors públics siguin correctes.

L’arranjament durador és un propietari per capa: decideix quin component posseeix el DNS de l’enllaç del túnel i quin el valor global per defecte, anota-ho i treu els altres del camí. Després verifica-ho després d’una desconnexió amb un nom que només resolgui la VPN. Si un nom privat encara respon, el registre no s’ha tret; si no es resol res, el fitxer apunta a un servidor que ja no existeix. Totes dues coses es veuen a resolvectl abans que obris un navegador.