openconnect muerto: las rutas y el DNS siguen apuntando al túnel

El túnel está caído, pero la máquina sigue comportándose como si estuviera arriba: una consulta se cuelga hasta agotar el tiempo de espera y una ruta apunta a una interfaz que ya no existe. Esa es la firma de un proceso openconnect que murió sin ejecutar su asistente de desconexión. El estado de red que creó sigue instalado, y nada más en el sistema sabe cómo eliminarlo.

Recorra la máquina en el orden en que se creó el estado: proceso, enlace, ruta, resolutor. Cada paso le dice si el cliente se ha ido de verdad o solo se ha desenganchado de su terminal, y esa distinción decide si hay que reparar algo.

Empiece por el proceso, no por la configuración

Abra un terminal y pregunte qué sigue ejecutándose antes de tocar una ruta. pgrep -a openconnect lista cada instancia con sus argumentos, lo que muestra el archivo pid y el script que se le dio. Un proceso que no esperaba explica el túnel fantasma más rápido que cualquier registro.

Si no se ejecuta nada, mire el enlace. ip link show tun0 le dice si la interfaz sobrevivió, y ip route show dev tun0 lista las rutas que siguen ligadas a ella. Después compruebe el resolutor con resolvectl status. Anote las tres salidas antes de cambiarlas, porque ese registro es la forma de distinguir más tarde una entrada obsoleta de una nueva.

Una interfaz que desaparece normalmente se lleva sus rutas consigo. Las rutas que sobreviven al enlace suelen significar que el proceso sigue vivo o que un segundo cliente posee el dispositivo.

El script auxiliar es lo que deshace los cambios

openconnect no elimina por sí mismo la interfaz, las rutas ni las entradas del resolutor. Llama a un asistente externo, /etc/vpnc/vpnc-script en una compilación upstream y /usr/share/vpnc-scripts/vpnc-script en los paquetes de Debian y Ubuntu, elegido con -s. El mismo script que levanta el túnel es el que lo desmonta.

Si el proceso sale sin llamar a ese asistente, el estado se queda. El manual de OpenConnect es explícito en que el enrutamiento y el servicio de nombres no funcionarán correctamente sin el script, y describe al asistente como el componente que desmonta el estado de la interfaz al salir. Por eso importa la ruta cuando inicia el cliente con -s.

Qué señal llega a esa ruta cambió entre versiones. El manual de la 7.06 trata SIGTERM como una salida inmediata que omite el script. Las compilaciones actuales documentan INT y TERM como una parada limpia, en la que la sesión se desconecta y el asistente se ejecuta. Lea la sección SIGNALS del binario que realmente tiene en lugar de suponer cualquiera de los dos comportamientos.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Envíe la señal que documenta su compilación

Una vez que conozca la señal, detenga el proceso por pid y no por patrón.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Luego repita las tres comprobaciones de la primera sección en lugar de confiar en el estado de salida. ip link show tun0 debería fallar, ip route show dev tun0 no debería imprimir nada, y resolvectl status ya no debería listar el enlace VPN.

SIGHUP no es un botón de parada: desconecta, ejecuta el script y deja la sesión reanudable con --cookie. SIGUSR2 fuerza una reconexión inmediata. SIGKILL omite la limpieza por completo, que es exactamente el estado del que trata este artículo.

Repare el resolutor sin sustituir resolv.conf

En la mayoría de los sistemas Ubuntu /etc/resolv.conf es un enlace simbólico a systemd-resolved, no un archivo que deba editar. Sustituirlo rompe la resolución de nombres para todas las redes, no solo para la VPN. En su lugar, elimine el registro del túnel:

resolvectl revert tun0
resolvectl query example.com

Si el sistema usa resolvconf en lugar de systemd-resolved, el registro por interfaz persiste hasta que se le dice que suelte el enlace, y resolvconf -d tun0 es la acción equivalente. Compruebe qué resolutor se está usando antes de elegir el comando.

Una consulta que sigue dirigida a un servidor detrás del enlace muerto se cuelga hasta agotar el tiempo de espera, y ese retraso parece un servidor DNS roto más que una ruta sobrante.

Haga aburrida la próxima desconexión

Mantenga la misma ruta del archivo pid al iniciar y al apagar pasando --pid-file cada vez, o ejecute openconnect bajo una unidad cuyo KillSignal coincida con la señal que documenta su versión. Probar primero en primer plano le muestra los mensajes de apagado que imprime el asistente.

Conéctese, desconéctese y ejecute las tres comprobaciones una vez. Una salida limpia no deja ningún enlace VPN, ninguna ruta VPN ni ninguna entrada de resolutor VPN. Si una de las tres sobrevive, ahora sabe qué componente no limpió. La siguiente investigación empieza entonces desde esa respuesta y no desde una consulta colgada.