El DNS de OpenVPN queda atrás tras SIGKILL: revise primero el propietario

El DNS deja de resolver después de que se mata un cliente de OpenVPN, y el primer instinto es reescribir /etc/resolv.conf. Ese cambio puede romper un resolver que funciona mientras el verdadero estado obsoleto está en otro sitio. La cuestión que hay que resolver primero es quién posee los ajustes de DNS que instaló el túnel, y si la salida que se saltó la limpieza realmente importó.

Tres condiciones deciden la reparación: la señal que terminó el proceso, el componente del resolver que recibió los ajustes y si el enlace del túnel sigue existiendo. Respóndalas en ese orden y la corrección suele llegar sin tocar ningún archivo global.

Decida qué tipo de salida ocurrió

En la edición Community de OpenVPN, tanto SIGINT como SIGTERM son peticiones de salida ordenada. SIGKILL no se puede capturar: no se puede bloquear ni manejar, así que ninguna rutina de apagado tiene ocasión de ejecutarse. Un Ctrl+C normal en una terminal en primer plano genera SIGINT, mientras que un supervisor que deja de esperar suele escalar a SIGKILL. La diferencia importa porque solo el segundo caso garantiza que se saltaron los ganchos.

Ejecutarlo dentro de screen o tmux no cambia qué señal envía Ctrl+C. Compruebe qué recibió realmente el proceso, no qué hace normalmente la terminal.

Cuando un servicio o un gestor de conexiones ejecuta el túnel, detenga esa conexión concreta a través de su propietario en lugar de matar el pid. Un gestor puede volver a levantar el proceso, dejándole un túnel nuevo y un estado del resolver confuso. Un proceso autónomo solo necesita una petición de terminación normal para que se ejecute la limpieza.

Decida quién posee el resolver

systemd-resolved, un script al estilo de resolvconf y una simple reescritura de archivo son tres propietarios distintos. El primero mantiene los ajustes por enlace en memoria y los descarta cuando la interfaz desaparece. El segundo mantiene registros que persisten hasta que algo los elimina. El tercero escribe un archivo y deja la restauración a quien lo escribió.

Identifique al propietario antes de elegir un comando de reparación. El mismo síntoma tiene tres respuestas correctas distintas según cuál esté en uso.

Una VPN gestionada por NetworkManager puede poseer ya los cambios del resolver. Añadir un segundo ayudante encima crea dos propietarios que compiten por el mismo enlace, y el estado del perdedor reaparece en la siguiente reconexión. Si un gestor manda, corrija el ajuste en el gestor y no en un script.

Qué puede y qué no puede hacer el gancho down

El script down se ejecuta una vez que se ha cerrado el dispositivo TUN/TAP. Añadir down-pre invierte ese orden y ejecuta el script mientras el dispositivo aún existe, algo que requieren los ayudantes que necesitan el enlace activo.

Ninguna de las dos directivas hace que un gancho se ejecute tras SIGKILL. Los privilegios tampoco se restauran con down-pre: si el demonio baja a un user o group o entra en un chroot, el gancho se ejecuta con el acceso que eso le deje. Un gancho invocado puede aun así fallar al actualizar el resolver. La referencia de OpenVPN cubre las señales y el ciclo de vida de la retrollamada.

Compruebe el error propio del gancho junto al estado de salida del proceso. Una limpieza ausente y una limpieza fallida se ven igual en el resolver y distinto en los registros.

Compruebe el estado que realmente queda

En un sistema que usa systemd-resolved, resolvectl status muestra qué enlace sigue llevando los servidores DNS de la VPN o los dominios de enrutamiento. Ese enlace puede pertenecer a una conexión que ya no está o a otro túnel que sigue levantado.

Una interfaz que desaparece se lleva su configuración por enlace, así que un gancho saltado puede convivir con un DNS limpio. Si el enlace sigue registrado y lo posee en exclusiva la conexión detenida, el gestor propietario debería eliminarlo. Si un script más antiguo reescribió un archivo global del resolver, busque en su lugar el paso de restauración documentado de ese script.

Recupere sin robar otro enlace

Cuando los ajustes por enlace son suyos de gestionar, resolvectl revert toma el nombre del enlace y borra la configuración DNS en tiempo de ejecución para esa interfaz. Es una acción en tiempo de ejecución y no una edición de perfil, así que la configuración persistente de la conexión queda intacta. Nombre el enlace equivocado y borrará el DNS de un túnel que funciona, por eso el nombre sale de la salida de estado.

Confirme que /etc/resolv.conf es un enlace simbólico gestionado antes de editarlo, luego detenga el cliente con normalidad una vez más y vuelva a mirar el DNS. Si la segunda parada limpia, el problema anterior era la salida forzada y no la configuración.