¿Cuánto tiempo debe OpenConnect seguir reintentando una VPN caída?

--reconnect-timeout responde a una pregunta muy concreta: cuando cae el túnel, cuánto tiempo sigue intentándolo este proceso cliente antes de rendirse y salir. La página del manual de OpenConnect registra esa opción con un valor predeterminado documentado de 300 segundos para los reintentos que siguen a la pérdida del enlace o a un par que dejó de responder, y el número es una fecha límite para un cliente en ejecución, no una prueba de que la VPN siga siendo accesible. Tampoco es una política para mantener vivo el proceso, y ahí empieza la mayor parte de la confusión.

La confusión aumenta cuando encima hay un segundo mecanismo. Un supervisor que reinicia el cliente, un sondeador que hace ping a la puerta de enlace y la ventana de reintentos integrada pueden reaccionar todos a un mismo fallo, y el incidente produce entonces tres cronologías que nadie puede conciliar.

Qué limita realmente la ventana de reconexión

Imagine que la red de acceso desaparece durante unos segundos. El cliente ve caer el enlace, o deja de oír las respuestas del par muerto, y empieza a restablecer la sesión conservando el estado que puede. Los reintentos continúan hasta que la puerta de enlace vuelve a aceptar o hasta que se agota la ventana, y una ventana agotada termina en una salida con código distinto de cero. Esa salida, y no el valor del tiempo de espera, es donde la propiedad del ciclo de vida pasa a quien supervise el proceso.

La ventana no dice nada sobre la frecuencia con que se ejecuta una sonda, y no puede ampliar la autenticación. Si la puerta de enlace revocó la sesión, o la cuenta exige ahora un segundo factor nuevo, esperar más no hará que la sesión antigua vuelva a ser válida. Un reintento solo tiene éxito cuando el camino vuelve, la puerta de enlace sigue reconociendo la sesión y las credenciales que pide siguen siendo utilizables, así que lea el número como una fecha límite y no como un intervalo de vitalidad.

La ventana tampoco gobierna lo que hacen las aplicaciones mientras dura. Según la plataforma y hasta dónde llegó el fallo, el cliente puede estar reconectándose con las rutas aún instaladas, o después de que se retiraran. Por eso una petición emitida en mitad de una interrupción suele quedarse colgada hasta agotar el tiempo de espera en lugar de fallar rápido.

Los reinicios del supervisor y los reintentos del cliente son dos capas

Deje que el cliente en ejecución gaste su propia ventana, y que el gestor de servicios reaccione a la salida. Un cliente en primer plano bajo systemd con una política de reinicio da exactamente esa división: reintentos durante un periodo acotado y después una sola decisión de reinicio. El resultado es una única cronología que aún puede reconstruir después.

Un cliente en segundo plano más un sondeador independiente que inicia otra copia cuando no ve una interfaz es el patrón que sale mal. Ambos procesos compiten entonces por el mismo nodo de dispositivo, las rutas y la configuración del resolutor. Si de verdad quiere un demonio, ponga la opción en la línea de comandos con la que el cliente arranca en realidad:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Dos detalles de esa línea pesan. --background separa el proceso, así que el archivo pid se convierte en el único asidero fiable que hay sobre él, y el tiempo de espera solo se consume mientras ese mismo proceso vive; un supervisor que lo mata no deja presupuesto para continuar.

Las desconexiones intencionadas necesitan su propia señal. Una pausa planificada y una caída real resultan idénticas a un observador ingenuo, y ambas se leen como «no conectado». Dirija la pausa mediante la operación de parada del supervisor, o una marca que el envoltorio entienda, para que una detención deliberada no dispare un reinicio que nadie pidió.

Evitar que el traspaso compita con el bucle de reintentos

La recuperación desatendida depende de credenciales que se renuevan sin una persona presente. Un llavero que solo se desbloquea dentro de una sesión interactiva de escritorio, o un token que siempre exige un código tecleado, dejarán al cliente atascado en la fase de autenticación cuando el camino vuelva. Resuelva ese flujo antes de alargar la ventana, porque una ventana más larga solo da a la misma solicitud bloqueada más tiempo para fallar.

La verificación del servidor no debe relajarse para reducir solicitudes. Precisamente el pin o el ancla de confianza que valida la puerta de enlace es lo que hace segura una reconexión automática, y desactivarlo para evitar una pregunta sobre el certificado cambia una interrupción visible por otra invisible. Conserve la identidad verificada y repare la solicitud en su lugar; un cliente dispuesto a conectarse a cualquier puerta de enlace es peor que uno que se detiene y espera.

La presencia de la interfaz tampoco es una señal de salud. Un dispositivo de túnel puede existir con una sesión muerta detrás, y un proceso lanzador puede existir sin túnel alguno. Ninguna de esas observaciones resiste una petición real. La salud tiene que venir de lo que el usuario necesita, como una petición que atraviesa el túnel hasta un servicio interno conocido.

Qué verificar durante y después de una interrupción

Ejecute cuatro sucesos como pruebas separadas: una interrupción más corta que la ventana, una caída más larga que esta, un fallo de autenticación y una parada intencionada. Cada uno debe terminar en un estado distinto y predecible, y la frontera entre los dos primeros es toda la razón para elegir un valor.

Mantenga las comprobaciones mirando hacia fuera, porque la tabla de procesos por sí sola demuestra muy poco. Observe que el pid se mantenga estable durante el corte corto y luego confirme que desapareció y se sustituyó una vez tras el largo:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Durante la interrupción corta, confirme que el cliente reintentó de verdad en lugar de salir antes de tiempo, y que las rutas y las entradas del resolutor volvieron sin duplicados. Para la caída larga, confirme una salida limpia y exactamente un reinicio después. Para el fallo de autenticación, confirme que el cliente no gira contra una puerta de enlace que seguirá rechazándolo. Añada una comprobación de que el pid vuelve a un solo valor en lugar de acumularse.

Para la parada deliberada, la URL de salud debe seguir siendo inalcanzable y el proceso debe seguir caído. Después cierre el bucle desde el lado de la aplicación: la misma petición debe fallar mientras el túnel no está y debe tener éxito tras su regreso, desde la dirección de origen que su política espera. Un icono verde de túnel no es una prueba, pero una petición completada sí lo es.