Por que unha reconexión VPN volve pedir credenciais
Un contrasinal gardado e un testemuño reutilizable caducan segundo calendarios distintos. Le que material pediu a reconexión antes de cambiar nada no cliente.
Un túnel que funcionou durante horas pide un contrasinal no momento en que o portátil esperta, e nada da configuración cambiou. O que si cambiou é o estado da credencial que a reconexión intentou reutilizar. Tres tipos de material gobernan iso, e só un deles sobrevive a un intervalo arbitrario.
Le cal pediu o cliente, porque os tres caducan con reloxos distintos e fallan con mensaxes distintas.
Tres tipos de material reutilizable
Un contrasinal en caché é un segredo que garda o cliente, e segue sendo válido ata que a conta o cambie. Un testemuño de sesión emíteo o servidor tras un inicio de sesión correcto, leva a súa propia vida útil e pode revogarse en calquera momento. Un tícket de sesión TLS ou unha asociación de seguridade IKE é estado de protocolo, barato de retomar e completamente independente do teu contrasinal. Cada un emíteo un compoñente distinto, e cada un caduca nos seus propios termos.
O primeiro sobrevive a un reinicio, o segundo adoita sobrevivir a unha suspensión, e o terceiro pode que non sobreviva de ningún xeito a un cambio de rede. Confundilos produce a solución incorrecta, como restablecer un contrasinal que nunca foi rexeitado.
O propio aviso é o diagnóstico. Unha xanela de navegador ou un código de segundo factor significa que o servidor esixiu autenticación interactiva, mentres que un fallo silencioso sen aviso significa que o cliente nunca chegou o suficiente lonxe como para que lle preguntasen.
| 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 non é reautenticar
Unha renovación de claves substitúe as claves mantendo a identidade autenticada, e por iso ocorre en silencio de cando en vez nun túnel san. A reautenticación repite a propia comprobación de identidade, e ese é o acontecemento que te necesita. IKEv2 separa ambos explicitamente, e un par pode esixir unha reautenticación completa nun intervalo configurado, sen importar cantas renovacións de claves ocorresen entrementres. Os dous acontecementos parecen idénticos desde fóra ata que les cal nomea o rexistro.
OpenVPN compórtase igual co seu propio vocabulario: un intervalo de renegociación refresca a canle de datos, e un testemuño de autenticación pode devolverse ao cliente para evitar un inicio de sesión completo na seguinte conexión. Ese testemuño ten unha vida útil, e o servidor decide se o acepta de novo.
Así, unha reconexión tras oito horas pode fallar onde unha reconexión tras oito minutos tivo éxito, sen ningún cambio de configuración en ningunha das dúas partes. Esa é toda a explicación dun aviso que só aparece despois de xantar.
Cando o cliente non pode completar o novo desafío
Unha política que esixe un paso no navegador fallará nun cliente que non ten forma de mostralo. Servidores sen interface, scripts de arranque e perfís antigos creados para autenticación só con contrasinal chocan todos con esa parede, e o fallo adoita aparecer como un tempo de espera xenérico en lugar dun erro de autenticación.
As transicións de dispositivo e rede tamén poden caer dentro dunha xanela de avaliación da política, así que un cambio de Wi-Fi a un punto de acceso coincide cunha comprobación que ocorrería de todos os xeitos. A coincidencia fai que a rede pareza culpable cando a causa é o temporizador.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
A primeira liña mostra acontecementos de renegociación e autenticación no rexistro propio do cliente, e a segunda mostra as asociacións de seguridade que un par strongSwan mantén agora mesmo. Compara as marcas de tempo co momento en que apareceu o aviso; unha coincidencia confirma o temporizador e non a rede.
Que informar e que non desactivar
Se un inicio de sesión manual funciona e a reutilización automática falla de forma constante, díxelo exactamente así ao operador. Nomea o compoñente: a ruta de reutilización, non a credencial. Inclúe a hora do fallo, a conta en uso e o tipo de aviso que viches.
Non desactives o segundo factor, non saltes a validación do certificado nin pegues credenciais nun script para que a reconexión sexa silenciosa. Cada unha desas accións elimina a comprobación que a política existe para impor, e cada unha converte un aviso de inicio de sesión nun incidente.
Pide en cambio o fluxo admitido: un cliente que poida completar o desafío, unha vida útil de testemuño que encaixe coa xornada laboral, ou un perfil non interactivo aprobado para a máquina que non pode preguntar. Todas son decisións de configuración que alguén pode aprobar, cousa que unha solución alternativa non é.