Por qué una reconexión VPN vuelve a pedir credenciales
Una contraseña guardada y un token reutilizable caducan según calendarios distintos. Lee qué material pidió la reconexión antes de cambiar nada en el cliente.
Un túnel que funcionó durante horas pide una contraseña en el momento en que el portátil se despierta, y nada de la configuración ha cambiado. Lo que sí ha cambiado es el estado de la credencial que la reconexión intentó reutilizar. Tres tipos de material lo gobiernan, y solo uno de ellos sobrevive a un intervalo arbitrario.
Lee cuál pidió el cliente, porque los tres caducan con relojes distintos y fallan con mensajes distintos.
Tres tipos de material reutilizable
Una contraseña en caché es un secreto que guarda el cliente, y sigue siendo válida hasta que la cuenta la cambie. Un token de sesión lo emite el servidor tras un inicio de sesión correcto, lleva su propia vida útil y puede revocarse en cualquier momento. Un tique de sesión TLS o una asociación de seguridad IKE es estado de protocolo, barato de reanudar y completamente independiente de tu contraseña. Cada uno lo emite un componente distinto, y cada uno caduca en sus propios términos.
El primero sobrevive a un reinicio, el segundo suele sobrevivir a una suspensión, y el tercero puede que no sobreviva en absoluto a un cambio de red. Confundirlos produce la solución equivocada, como restablecer una contraseña que nunca fue rechazada.
El propio aviso es el diagnóstico. Una ventana de navegador o un código de segundo factor significa que el servidor exigió autenticación interactiva, mientras que un fallo silencioso sin aviso significa que el cliente nunca llegó lo bastante lejos como para que se le preguntara.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Renovar claves no es reautenticar
Una renovación de claves sustituye las claves manteniendo la identidad autenticada, y por eso ocurre en silencio cada cierto tiempo en un túnel sano. La reautenticación repite la propia comprobación de identidad, y ese es el evento que te necesita. IKEv2 separa ambos explícitamente, y un par puede exigir una reautenticación completa en un intervalo configurado, sin importar cuántas renovaciones de claves hayan ocurrido entretanto. Los dos eventos parecen idénticos desde fuera hasta que lees cuál nombra el registro.
OpenVPN se comporta igual con su propio vocabulario: un intervalo de renegociación refresca el canal de datos, y un token de autenticación puede devolverse al cliente para evitar un inicio de sesión completo en la siguiente conexión. Ese token tiene una vida útil, y el servidor decide si lo acepta de nuevo.
Así, una reconexión tras ocho horas puede fallar donde una reconexión tras ocho minutos tuvo éxito, sin ningún cambio de configuración en ninguna de las dos partes. Esa es toda la explicación de un aviso que solo aparece después de comer.
Cuando el cliente no puede completar el nuevo desafío
Una política que exige un paso en el navegador fallará en un cliente que no tiene forma de mostrarlo. Servidores sin interfaz, scripts de arranque y perfiles antiguos creados para autenticación solo con contraseña chocan todos con esa pared, y el fallo suele aparecer como un tiempo de espera genérico en lugar de un error de autenticación.
Las transiciones de dispositivo y red también pueden caer dentro de una ventana de evaluación de la política, así que un cambio de Wi-Fi a un punto de acceso coincide con una comprobación que habría ocurrido de todos modos. La coincidencia hace que la red parezca culpable cuando la causa es el temporizador.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
La primera línea muestra eventos de renegociación y autenticación en el registro propio del cliente, y la segunda muestra las asociaciones de seguridad que un par strongSwan mantiene ahora mismo. Compara las marcas de tiempo con el momento en que apareció el aviso; una coincidencia confirma el temporizador y no la red.
Qué informar y qué no desactivar
Si un inicio de sesión manual funciona y la reutilización automática falla de forma constante, díselo exactamente así al operador. Nombra el componente: la ruta de reutilización, no la credencial. Incluye la hora del fallo, la cuenta en uso y el tipo de aviso que viste.
No desactives el segundo factor, no te saltes la validación del certificado ni pegues credenciales en un script para que la reconexión sea silenciosa. Cada una de esas cosas elimina la comprobación que la política existe para imponer, y cada una convierte un aviso de inicio de sesión en un incidente.
Pide en cambio el flujo admitido: un cliente que pueda completar el desafío, una vida útil de token que encaje con la jornada laboral, o un perfil no interactivo aprobado para la máquina que no puede preguntar. Todas son decisiones de configuración que alguien puede aprobar, cosa que un apaño no es.