Editar resolv.conf no arregla el DNS después de que la VPN se desconecte

Desconectas la VPN, ping 1.1.1.1 sigue respondiendo y cada consulta de nombre se cuelga antes de que la página por fin se rinda. Entonces cat /etc/resolv.conf muestra un servidor de nombres que solo existió nunca dentro del túnel, normalmente el primero de la lista. Borrar esa línea parece arreglarlo durante unos diez minutos, hasta que una suspensión, un roaming de Wi-Fi o un reinicio la vuelven a poner. El archivo que editaste no es el ajuste; es una representación del estado del enlace que posee otro componente.

Por qué una entrada obsoleta cuesta segundos por consulta

El resolutor de glibc recorre la lista de servidores de nombres en orden y espera a que expire un tiempo de espera antes de probar el siguiente, y resolv.conf(5) limita esa lista a tres entradas. Pon un resolutor del lado del túnel como 10.8.0.1 arriba después de que el túnel desaparezca y cada consulta paga el tiempo de espera antes de caer a un servidor que responde. Por eso el síntoma parece una conexión muerta y no un error de DNS: los navegadores se bloquean, se quedan sin tiempo y a veces sirven una dirección en caché que luego caduca.

También explica por qué la queja llega como «internet está roto». Un ping a una dirección IP demuestra que el enlace está bien, lo que hace que el fallo parezca de la aplicación. La lista de resolutores es lo primero que hay que leer y lo último que hay que editar.

El mito: resolv.conf es un archivo de ajustes

Pregunta qué es realmente la ruta antes de cambiarla:

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

En un host con systemd-resolved es un enlace simbólico a un archivo stub que apunta a 127.0.0.53, y los servidores reales viven en el estado por enlace que imprime resolvectl. En un host con NetworkManager puede ser un archivo que NetworkManager escribe desde la conexión activa. Con algunos clientes de fabricante es un archivo plano reescrito en su sitio al conectar y, si tienes mala suerte, nunca restaurado al desconectar. Son tres dueños distintos, y editar los dos primeros a mano o no hace nada o dura hasta el siguiente evento de red.

resolvectl status es la vista que dice la verdad: servidores DNS por enlace, dominios de enrutamiento y si el enlace del túnel sigue existiendo. resolvectl query example.com va más allá y muestra qué interfaz respondió. Usa ambos antes de tocar un archivo, y ten en cuenta que un navegador con DNS seguro propio ignora todo esto.

Encuentra al dueño antes de editar nada

Tres componentes suelen competir por el mismo ajuste: systemd-resolved, NetworkManager y lo que haya instalado el cliente de VPN. Identifica primero el vivo:

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

Si resolved está activo y el enlace simbólico apunta a su stub, el archivo global es salida generada y tu edición es cosmética. Si NetworkManager es dueño de la conexión, los servidores pertenecen al perfil de conexión, así que el arreglo es un cambio de propiedad con nmcli y no una edición de archivo. Si hay un demonio del fabricante en marcha, solo su propia ruta de restauración sobrevive a la siguiente conexión.

Limpia el estado del enlace que dejó el cliente

Un cliente muerto no puede ejecutar su hook de limpieza. SIGKILL no se puede capturar en absoluto, mientras que SIGINT y SIGTERM sí, así que un túnel que «simplemente se detuvo» tras una muerte forzada a menudo deja en su sitio tanto el registro de la interfaz como la entrada del resolutor. Encuentra el PID concreto y envía la señal solo a ese:

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

No eches mano de pkill -f vpn ni killall vpn antes de leer la lista completa de coincidencias. -f coincide con toda la línea de comandos, así que puede terminar un script envoltorio, una sesión de editor o un proceso no relacionado cuya ruta contenga la cadena. Terminar el proceso equivocado en mitad del trabajo es como un problema de resolutor se convierte en un archivo perdido.

resolvectl revert restablece la configuración DNS en tiempo de ejecución de ese enlace, lo que es más estrecho que reiniciar el resolutor y mucho más estrecho que editar el archivo global. Si el enlace del túnel ha desaparecido del todo, systemctl restart NetworkManager reconstruye el estado de la conexión y es el paso al que los hilos de origen vuelven una y otra vez. Ojo con un gestor de servicios con Restart=always, porque puede devolver un cliente muerto, y sus ajustes de DNS, directamente.

La otra dirección: DNS empujado que nunca llegó

La imagen espejo de la entrada obsoleta es un túnel sin ningún resolutor utilizable. Una opción DNS en el perfil es una petición; el componente que gestiona la conexión tiene que entregársela al resolutor. Si el registro muestra que el servidor se recibió pero el enlace del túnel no lleva ningún ajuste DNS, falta la integración, no el servidor.

Prueba la entrega haciéndola a mano, lo que separa «el servidor está mal» de «nadie lo aplicó»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

El dominio de enrutamiento comodín envía cada nombre a ese enlace, que es lo que quiere un cliente de túnel completo y lo que el DNS dividido no debe usar. Estos ajustes desaparecen en la siguiente conexión. Para hacerlos persistentes en NetworkManager, desactiva el DNS automático, pon el servidor en la conexión y añade el 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 solo debe responder nombres internos, lista esas zonas con una tilde inicial en lugar del comodín, para que los nombres públicos sigan usando el resolutor local.

Soluciones provisionales que se convierten en la próxima caída

Copiar resolv.conf antes de conectar y restaurarlo después es una línea legítima en un runbook, y es una solución provisional y no una reparación. Falla justo cuando importa, porque un cuelgue o un reinicio forzado se salta la restauración. Anótalo como solución provisional para que la siguiente persona no construya sobre ella.

Desactivar systemd-resolved y fijar servidores públicos a mano es la otra maniobra popular. Hace que conectar y desconectar sean predecibles y elimina el DNS por enlace de cualquier otra red, lo que rompe el DNS dividido para nombres internos y echa por tierra el propósito de un túnel pensado para mantener las consultas dentro. Instalar resolvconf y fijar servidores públicos cuesta lo mismo con una capa extra. Trata cualquiera de las dos como un diagnóstico: si te devuelve la navegación, has aprendido que la integración del resolutor es la culpable, no que los servidores públicos sean correctos.

El arreglo duradero es un dueño por capa: decide qué componente posee el DNS del enlace del túnel y cuál el valor global por defecto, anótalo y quita a los demás del camino. Luego verifica tras una desconexión con un nombre que solo resuelva la VPN. Si un nombre privado sigue respondiendo, no se eliminó el registro; si no se resuelve nada, el archivo apunta a un servidor que ya no existe. Ambas cosas se ven en resolvectl antes de que abras un navegador.