Editar resolv.conf non arranxa o DNS despois de que a VPN se desconecte

Desconectas a VPN, ping 1.1.1.1 segue respondendo e cada consulta de nome colga antes de que a páxina por fin se renda. Entón cat /etc/resolv.conf mostra un servidor de nomes que só existiu nunca dentro do túnel, normalmente o primeiro da lista. Borrar esa liña parece arranxalo durante uns dez minutos, ata que unha suspensión, unha itinerancia Wi-Fi ou un reinicio a volven poñer. O ficheiro que editaches non é o axuste; é unha representación do estado da ligazón que posúe outro compoñente.

Por que unha entrada obsoleta custa segundos por consulta

O resolutor de glibc percorre a lista de servidores de nomes en orde e espera a que expire un tempo de espera antes de probar o seguinte, e resolv.conf(5) limita esa lista a tres entradas. Pon un resolutor do lado do túnel como 10.8.0.1 arriba despois de que o túnel desapareza e cada consulta paga o tempo de espera antes de caer a un servidor que responde. Por iso o síntoma parece unha conexión morta e non un erro de DNS: os navegadores bloquean, quedan sen tempo e ás veces serven un enderezo na caché que despois caduca.

Tamén explica por que a queixa chega como «internet está roto». Un ping a un enderezo IP demostra que a ligazón está ben, o que fai que o fallo pareza da aplicación. A lista de resolutores é o primeiro que hai que ler e o último que hai que editar.

O mito: resolv.conf é un ficheiro de axustes

Pregunta que é realmente a ruta antes de cambiala:

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

Nun host con systemd-resolved é unha ligazón simbólica a un ficheiro stub que apunta a 127.0.0.53, e os servidores reais viven no estado por ligazón que imprime resolvectl. Nun host con NetworkManager pode ser un ficheiro que NetworkManager escribe desde a conexión activa. Con algúns clientes de fabricante é un ficheiro simple reescrito no seu sitio ao conectar e, se tes mala sorte, nunca restaurado ao desconectar. Son tres donos distintos, e editar os dous primeiros á man ou non fai nada ou dura ata o seguinte evento de rede.

resolvectl status é a vista que di a verdade: servidores DNS por ligazón, dominios de enrutamento e se a ligazón do túnel segue existindo. resolvectl query example.com vai máis alá e mostra que interface respondeu. Usa ambos antes de tocar un ficheiro, e ten en conta que un navegador con DNS seguro propio ignora todo isto.

Atopa o dono antes de editar nada

Tres compoñentes adoitan competir polo mesmo axuste: systemd-resolved, NetworkManager e o que instalase o cliente de VPN. Identifica primeiro o vivo:

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

Se resolved está activo e a ligazón simbólica apunta ao seu stub, o ficheiro global é saída xerada e a túa edición é cosmética. Se NetworkManager posúe a conexión, os servidores pertencen ao perfil de conexión, así que o arranxo é un cambio de propiedade con nmcli e non unha edición de ficheiro. Se hai un demo do fabricante en marcha, só o seu propio camiño de restauración sobrevive á seguinte conexión.

Limpa o estado da ligazón que deixou o cliente

Un cliente morto non pode executar o seu hook de limpeza. SIGKILL non se pode capturar en absoluto, mentres que SIGINT e SIGTERM si, así que un túnel que «simplemente se detivo» tras unha morte forzada a miúdo deixa no seu sitio tanto o rexistro da interface como a entrada do resolutor. Atopa o PID concreto e envía o sinal só a ese:

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

Non botes man de pkill -f vpn nin killall vpn antes de ler a lista completa de coincidencias. -f coincide con toda a liña de ordes, así que pode rematar un script envoltorio, unha sesión de editor ou un proceso non relacionado cuxa ruta conteña a cadea. Rematar o proceso equivocado no medio do traballo é como un problema de resolutor se converte nun ficheiro perdido.

resolvectl revert restablece a configuración DNS en tempo de execución desa ligazón, o que é máis estreito que reiniciar o resolutor e moito máis estreito que editar o ficheiro global. Se a ligazón do túnel desapareceu por completo, systemctl restart NetworkManager reconstrúe o estado da conexión e é o paso ao que os fíos de orixe volven unha e outra vez. Ollo cun xestor de servizos con Restart=always, porque pode devolver un cliente morto, e os seus axustes de DNS, directamente.

A outra dirección: DNS empurrado que nunca chegou

A imaxe espello da entrada obsoleta é un túnel sen ningún resolutor utilizábel. Unha opción DNS no perfil é unha petición; o compoñente que xestiona a conexión ten que entregala ao resolutor. Se o rexistro mostra que o servidor se recibiu pero a ligazón do túnel non leva ningún axuste DNS, falta a integración, non o servidor.

Proba a entrega facéndoa a man, o que separa «o servidor está mal» de «ninguén o aplicou»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

O dominio de enrutamento comodín envía cada nome a esa ligazón, que é o que quere un cliente de túnel completo e o que o DNS dividido non debe usar. Estes axustes desaparecen na seguinte conexión. Para facelos persistentes en NetworkManager, desactiva o DNS automático, pon o servidor na conexión e engade o dominio:

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 "~."

Para un túnel de empresa que só debe responder nomes internos, lista esas zonas cun til inicial no canto do comodín, para que os nomes públicos sigan usando o resolutor local.

Solucións provisionais que se converten na próxima caída

Copiar resolv.conf antes de conectar e restauralo despois é unha liña lexítima nun runbook, e é unha solución provisional e non unha reparación. Falla xusto cando importa, porque un colapso ou un reinicio forzado salta a restauración. Anótao como solución provisional para que a seguinte persoa non constrúa sobre ela.

Desactivar systemd-resolved e fixar servidores públicos a man é a outra manobra popular. Fai que conectar e desconectar sexan previsibles e elimina o DNS por ligazón de calquera outra rede, o que rompe o DNS dividido para nomes internos e bota por terra o propósito dun túnel pensado para manter as consultas dentro. Instalar resolvconf e fixar servidores públicos custa o mesmo cunha capa extra. Trata calquera das dúas como un diagnóstico: se che devolve a navegación, aprendiches que a integración do resolutor é a culpable, non que os servidores públicos sexan correctos.

O arranxo duradeiro é un dono por capa: decide que compoñente posúe o DNS da ligazón do túnel e cal o valor global por defecto, anótao e quita os demais do camiño. Despois verifica tras unha desconexión cun nome que só resolva a VPN. Se un nome privado segue respondendo, non se eliminou o rexistro; se non se resolve nada, o ficheiro apunta a un servidor que xa non existe. As dúas cousas vense en resolvectl antes de que abras un navegador.