AnyConnect se cae al cerrar un terminal: comprobaciones de sesión

El túnel está activo, cierras un terminal de sobra y la VPN se cae sin una sola pulsación en el cliente. En el cliente AnyConnect para Linux la causa informada es la contabilidad de sesiones y no el enrutamiento: el cliente registra qué sesiones de inicio existían cuando se levantó el túnel y trata el final de cualquiera de ellas como motivo para derribarlo. Las comprobaciones siguientes se ejecutan en orden, y la primera que falla te dice si estás viendo este comportamiento. Nada en la salida habitual del cliente menciona un terminal, por eso el primer instinto, culpar al concentrador, suele ser esfuerzo perdido.

No empieces editando archivos del sistema. Cada paso o explica la caída o elimina un candidato, y los pasos baratos van primero.

Separa una caída de sesión de una caída de la red subyacente

Vuelve a conectar inmediatamente después de la desconexión. Un túnel que regresa en segundos, en la misma red, sin credenciales nuevas, apunta a un desencadenante local como una sesión cerrada y no a un enlace ascendente muerto, a una itinerancia Wi-Fi o a un tiempo de espera por inactividad en el concentrador. Un túnel que se queda colgado en Connecting, o que falla hasta que cambias de red, es otro artículo.

Anota qué estaba abierto cuando se levantó el túnel: el terminal desde el que ejecutaste el cliente, cualquier segundo intérprete, el inicio de sesión gráfico y cualquier sesión SSH desde otra máquina. Necesitarás esa lista en un momento, y reconstruirla de memoria tras la siguiente caída no es fiable.

Comprueba qué registró el cliente al conectar

El cliente no inspecciona los procesos padre ni la propiedad del terminal. Toma una instantánea del conjunto de sesiones de inicio presentes al conectar y compara ese conjunto más tarde; cuando un miembro desaparece, la comparación falla y el túnel se va con él. Por eso cerrar la ventana desde la que te conectaste puede ser inofensivo mientras que cerrar un terminal de sobra sin relación mata la conexión: lo que importa es si esa sesión estaba en el conjunto original. La comprobación es una comparación de conjuntos y no un recuento, por eso sustituir una sesión puede ser tan fatal como perder una.

Enumera lo que el cliente podía ver antes de cambiar nada:

who
w
last -n 10
sudo ls -l /run/utmp

Cada línea de who es una entrada de proceso de usuario en utmp. Si tu sesión aparece dos veces, una por el inicio de sesión gráfico y otra por el terminal, ambas entradas existían al conectar y ambas son candidatas.

Elimina solo tu propia entrada de utmp

El apaño publicado hace invisible en utmp la sesión que estás a punto de usar antes de que arranque el cliente. Un pequeño programa en C recorre getutent(), busca el registro cuyo ut_line coincide con el TTY de la entrada estándar y después reescribe ese registro. El orden es deliberado: setutent(), leer la entrada, copiar su ut_id, poner ut_type en DEAD_PROCESS, borrar los campos de usuario y línea, escribirla de nuevo con pututline() y luego endutent().

Compílalo y ejecútalo como root desde el intérprete que iniciará el cliente:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Dos modos de fallo explican la mayoría de los informes de que la herramienta no hace nada. Actúa sobre el TTY asociado a la entrada estándar, así que ejecutarla desde un script o una tarea cron sin terminal no le deja nada con lo que coincidir. Y /run/utmp no es escribible por usuarios normales, así que una ejecución sin root falla en silencio salvo que compruebes el estado de salida.

Verifica que el túnel sobrevive al cierre

Prueba el mecanismo en lugar de suponerlo. Conéctate desde una sesión que pretendas mantener, abre un segundo terminal, cierra el segundo y luego confirma que el túnel sigue activo con vpn state y un vistazo a la lista de interfaces. Si el túnel sobrevive, el desencadenante era un tipo de sesión concreto y no todas las sesiones, y has encontrado la sesión que debe permanecer abierta.

Si aún se cae, la sesión vigilada estaba en otro sitio, casi siempre el inicio de sesión gráfico que engendró tu terminal, y quitar una sola entrada de TTY no ayudará. Repite la observación con la lista completa del primer paso en lugar de añadir más cirugía.

Cuándo reescribir utmp es la respuesta equivocada

utmp es contabilidad compartida, no una tabla privada. Reescribir la entrada de una sesión que sigue viva hace que who, w y algunas herramientas de auditoría la reporten por debajo, y un programa que después cierre esa misma entrada puede fallar por completo. Mantén la herramienta limitada a tu propia sesión, guarda una copia del archivo original y no la conviertas en un servicio de arranque que elimine todos los registros.

Si tu organización recopila contabilidad de sesiones por cumplimiento, el apaño choca con ese requisito y la respuesta admitida es otra versión del cliente u otro método de acceso, no un utmp parcheado. Para la mayoría de la gente la corrección menos invasiva es simplemente iniciar el cliente desde una sesión que permanecerá abierta todo el día y dejar esa ventana en paz.

Antes de cerrar el ticket, anota qué sesión vigilaba el cliente cuando se levantó el túnel. Esa sola línea es lo que convierte una desconexión misteriosa en una condición reproducible para la siguiente persona en la máquina.