OpenVPN cierra una sesión OTP más tarde: qué necesita la reautenticación

Desde el lado del cliente parece una desconexión aleatoria una hora después de una sesión en funcionamiento. El icono de la bandeja desaparece, el túnel se reconstruye y el registro muestra un fallo de autenticación en lugar de un error de red. Lo que ocurrió en realidad es que la sesión renegoció y el segundo handshake necesitó credenciales de las que el cliente ya no tenía una copia válida. Un código de un solo uso que funcionó al iniciar sesión no puede funcionar otra vez, así que la renovación de clave falla exactamente como estaba diseñada.

La solución es una decisión sobre qué debe presentar el segundo handshake, no un temporizador de reintento más largo.

Siga el intercambio desde el punto de vista del cliente

Al iniciar sesión el cliente envía el nombre de usuario, la contraseña y un código del dispositivo de token, y el servidor acepta la combinación. Después la sesión funciona hasta que se dispara un activador de renegociación, que inicia un nuevo handshake TLS dentro del túnel existente. Ese handshake vuelve a pedir autenticación. Si la ruta de autenticación del servidor espera una contraseña más un código de un solo uso vigente, el cliente no tiene ningún código nuevo que ofrecer a menos que el usuario esté presente para escribirlo.

La mayoría de los clientes no abren un aviso a mitad de sesión, así que el handshake caduca y el túnel cae. El usuario ve una reconexión, no un aviso de autenticación, y por eso el primer informe suele culpar a la red.

auth-gen-token cambia quién responde la segunda pregunta

auth-gen-token es la opción que permite al servidor emitir un token tras un inicio de sesión correcto, y las renegociaciones posteriores presentan ese token en lugar de repetir la contraseña y el código. El manual documenta su vida útil y su comportamiento de renovación, y el token debe tratarse como una credencial con su propia caducidad. En la ruta predeterminada el servidor valida el token él mismo en lugar de volver a llamar al autenticador de contraseña externo.

Con una integración de autenticación externa, esa división cambia. El complemento debe entender el estado del token y aplicar sus propias comprobaciones, porque el servidor ya no es el único componente que decide si la sesión continúa. Tratar el token como otro código numérico de un solo uso no es una implementación de la función.

Decida qué ocurre con el estado de la cuenta

Un token que sobrevive al acceso de una cuenta es un agujero de política. Decida cómo surten efecto una cuenta desactivada, una pertenencia a grupo eliminada o un dispositivo revocado mientras el token sigue vigente. Vidas útiles cortas del token reducen la ventana; una ruta de revocación explícita la hace intencionada. Escriba la respuesta antes de activar la opción, porque la ruta predeterminada no consulta el autenticador externo en cada renegociación.

En un despliegue con varios servidores, el secreto de firma de tokens debe compartirse, o el cliente puede ser enviado a un nodo que no puede validar su token.

Pruebe la caducidad y la reconexión, no solo el inicio de sesión

Baje el intervalo de renegociación en un perfil de prueba para que el segundo handshake ocurra mientras observa, y luego siga ambos registros. Confirme que el token se emite al iniciar sesión, se presenta al renovar la clave y se refresca o reemite según la vida útil configurada. Después fuerce una caducidad del token y una reconexión completa, porque un cliente que se reconecta limpiamente puede fallar igualmente en la ruta de renovación de clave.

Pruebe la eliminación de la cuenta al final. Ese caso le dice si la política que escribió se aplica o solo está documentada.

No lo arregle desactivando la renovación

Poner el intervalo de renegociación a cero en ambos extremos elimina el síntoma y con él la rotación de claves. Eso esconde un problema de reutilización de credenciales detrás de un cambio de política que nadie revisó. Mantenga la renovación y elija entre un token emitido por el servidor y un desafío interactivo nuevo según si hay un usuario presente.

Un temporizador de reintento más largo no hace que un código gastado vuelva a ser válido. Solo retrasa la desconexión y hace el registro más difícil de leer.