Cómo dejar OpenConnect en segundo plano tras un inicio de sesión interactivo

Termina el aviso de MFA, el túnel sube y cerrar la terminal se lleva la conexión consigo. Es un problema de supervisión, no de autenticación, y OpenConnect ya incluye el interruptor que lo resuelve. La solución es dejar que el cliente se bifurque en segundo plano cuando termine el arranque, una vez que la parte interactiva haya acabado de verdad. Sigue una secuencia de comprobaciones: hágalas en orden y deténgase en la primera que no se cumpla en su puerta de enlace.

Confirme qué exige la puerta de enlace al iniciar sesión

Antes de escribir un comando, anote la ruta de credenciales que impone el despliegue. Solo certificado, contraseña más token y un ida y vuelta por el navegador mediante un proveedor SAML se comportan de forma distinta, y el modo en segundo plano no puede saltarse ninguno. La opción cambia lo que ocurre después del arranque, nunca lo que ocurre durante él.

El atajo tentador es automatizar el aviso. Un envoltorio que escribe una respuesta fija cuando reconoce un aviso de contraseña se rompe en cuanto la puerta de enlace pide un código de un solo uso, y deja una credencial en un archivo que otras cuentas pueden leer. Si una persona debe aprobar la sesión, mantenga a la persona en el circuito.

Ejecute la primera sesión en primer plano y lea la salida

Conéctese una vez con normalidad y deje que se imprima todo el handshake. Anote el protocolo en uso, la ruta del certificado o del token, la dirección del túnel que asigna el servidor y cada advertencia antes de aceptar la conexión. Esa transcripción es su línea base y la única forma barata de distinguir después un problema del cliente de un cambio en la puerta de enlace. Guárdela fuera del búfer de la terminal.

Luego repita la misma invocación con modo en segundo plano y un archivo PID añadido, por ejemplo openconnect --background --pid-file /run/openconnect.pid vpn.example.net, manteniendo el protocolo y las opciones de autenticación que exige su puerta de enlace en la misma línea. El manual de OpenConnect describe esa opción como continuar en segundo plano tras completarse el arranque, y por eso la fase interactiva debe haber terminado primero.

Haga que el proceso en ejecución sea localizable y detenible

Un archivo PID solo es prueba mientras coincide con un proceso vivo. Póngalo en un directorio propiedad de la cuenta de servicio y compare el número registrado con la tabla de procesos antes de enviar ninguna señal. Los reinicios y las caídas dejan el archivo atrás, y un archivo obsoleto es la razón habitual de que un script de parada informe de éxito mientras el túnel sigue activo. Trate la comprobación como parte del procedimiento de parada, no como un paso opcional.

Envíe la señal al PID verificado y luego confirme que la interfaz del túnel ha desaparecido realmente en lugar de confiar en el estado de salida. Si el cliente necesita privilegios elevados para configurar la interfaz, la señal debe venir de una cuenta autorizada a enviarla.

No apile el modo en segundo plano bajo un supervisor

systemd y supervisores similares esperan ser dueños del proceso que lanzaron, y por eso un cliente que se bifurca los confunde. El supervisor ve salir un lanzador mientras la conexión real sigue viva, así que la lógica de reinicio, los informes de estado y los tiempos de parada describen algo que ya no es cierto. Escriba la unidad en el esquema de primer plano admitido y deje que el supervisor haga el trabajo de demonio.

Reserve --background para sesiones que una persona inicia y luego abandona. Si el requisito es un túnel que exista antes de que alguien inicie sesión, falta una identidad no interactiva aprobada y un plan para renovarla, y ningún indicador de línea de comandos proporciona ninguna de las dos. Añadir el indicador a un script de arranque produce un túnel que falla en silencio con la primera credencial caducada.

Trate la cookie de sesión como una credencial

OpenConnect documenta una fase de autenticación aparte mediante --authenticate, y el material resultante puede devolverse con --cookie-on-stdin. Ese par existe para trabajo de integración, y lo que produce es tan sensible como la contraseña que lo creó.

Mantenga el valor fuera del historial del shell, de los registros y de cualquier ticket que abra. Un script de entrega también debe conservar la información verificada del punto de conexión que el cliente recibió junto con la cookie; si la pierde, una ejecución posterior puede conectarse a un host que nunca autenticó, lo que es peor que una conexión que simplemente falla.

Recorra la lista antes de cerrar la terminal

Cuatro cosas deben ser ciertas: el inicio de sesión interactivo terminó en primer plano, el archivo PID apunta a un proceso que ha verificado, la cuestión del supervisor está resuelta en un sentido o en otro y la cookie tiene un plan de almacenamiento que no es un archivo de texto plano. Cuando las cuatro se cumplen, alejarse de la terminal es seguro y el túnel sigue funcionando.

Si una falla, corrija ese punto antes de tocar los demás, porque las comprobaciones restantes no pueden compensarlo. Guarde también la transcripción de primer plano de su primera ejecución: la próxima vez que el túnel caiga sin aviso, esa línea base separa un cambio del lado de la puerta de enlace de uno del lado del cliente.