El temporizador de sesión VPN y el token de autenticación caducan por separado

Un corte de VPN puede ocurrir por motivos que desde el cliente parecen idénticos y no comparten nada por debajo: la sesión del túnel terminó, saltó un temporizador de inactividad o una credencial que el cliente reutilizaba quedó obsoleta. Cada uno tiene un dueño distinto y una solución distinta. La secuencia de errores en el momento del corte es lo que los separa, y suele ser una sola línea.

Tres relojes corren contra un solo túnel, y solo uno de ellos es el túnel.

Tres relojes distintos en un solo túnel

El reloj de la sesión pertenece a la pasarela: una duración máxima de conexión, un tiempo de espera por inactividad o ambos, y cierra el túnel cuando se alcanza cualquiera de los dos. El reloj del token pertenece al sistema de autenticación y decide cuánto tiempo se puede presentar de nuevo una credencial sin una persona. El reloj de la ruta pertenece a cualquier NAT o cortafuegos que esté entre el cliente y la pasarela, y hace caducar las asignaciones de los flujos que considera terminados. Los tres producen una desconexión, y ninguno produce la misma línea de registro.

Solo el primero es un concepto de VPN. Los otros dos se toman de la identidad y de las redes, y se confunden con él con frecuencia.

Cómo se reutiliza realmente el token

Los servidores OpenVPN pueden emitir un token de autenticación tras el inicio de sesión inicial, de modo que una renegociación del canal de control no vuelve a pedir credenciales al usuario. El cliente sigue presentando ese token y el servidor decide cuánto tiempo sigue siendo aceptable. Cuando la vida del token es más corta que el intervalo de renegociación, la siguiente renegociación falla y el cliente informa de un error de autenticación en lugar de un tiempo de espera. Por eso el mismo perfil funciona durante una hora y luego falla en un punto fijo.

El intervalo de renegociación es un ajuste aparte. Cambiarlo mueve cuándo se presenta el token, no cuánto vive.

Cómo se ve cada caducidad desde el cliente

Un tiempo de espera de sesión suele llegar como una desconexión limpia con un motivo del servidor, a menudo tras una duración previsible y sin ningún error de autenticación adjunto. Un tiempo de espera por inactividad parece silencio: el túnel deja de llevar tráfico y entonces el keepalive se rinde. Una caducidad de token llega como AUTH_FAILED en mitad de una sesión que funcionaba un segundo antes.

Lea la línea y luego mire el reloj. Una duración que coincide con un valor configurado no es casualidad.

Por qué una contraseña guardada no ayuda

Una contraseña en caché responde a un desafío por una contraseña. No prolonga la vida de un token ni satisface un desafío por un segundo factor o una comprobación del estado del dispositivo. Aumentar la frecuencia de reintentos, reducir los tiempos de espera de conexión o reimportar el perfil no cambia nada sobre cuánto tiempo el sistema de identidad aceptará la credencial.

Las soluciones duraderas son la vida correcta sobre el objeto correcto, o un flujo de cliente que pueda completar el desafío necesario sin una persona.

Qué documentar y probar

Anote los tres valores: los límites de sesión e inactividad de la pasarela, la vida del token y el tiempo de espera de asignación relevante más corto de la ruta. Luego pruebe cada caducidad a propósito acortando un valor, observando qué informa el cliente y restaurándolo. Confirme qué debe hacer el usuario en cada frontera, porque exigir un inicio de sesión completo cada hora es una decisión de política que alguien debería haber tomado a propósito.

Un corte que llega sin ningún evento de autenticación pertenece a la ruta o al temporizador de inactividad, que es otra investigación con otras pruebas.