Pourquoi une reconnexion VPN redemande des identifiants

Un tunnel qui a fonctionné pendant des heures demande un mot de passe à l'instant où l'ordinateur portable se réveille, et rien dans la configuration n'a changé. Ce qui a changé, c'est l'état de l'identifiant que la reconnexion a tenté de réutiliser. Trois types de matériel régissent cela, et un seul survit à un intervalle arbitraire.

Lisez lequel le client a demandé, car les trois expirent selon des horloges différentes et échouent avec des messages différents.

Trois types de matériel réutilisable

Un mot de passe mis en cache est un secret détenu par le client, et il reste valide jusqu'à ce que le compte le change. Un jeton de session est délivré par le serveur après une connexion réussie, porte sa propre durée de vie et peut être révoqué à tout moment. Un ticket de session TLS ou une association de sécurité IKE est un état de protocole, peu coûteux à reprendre et totalement indépendant de votre mot de passe. Chacun est délivré par un composant différent, et chacun expire selon ses propres conditions.

Le premier survit à un redémarrage, le deuxième survit généralement à une mise en veille, et le troisième peut ne pas survivre du tout à un changement de réseau. Les confondre produit la mauvaise correction, comme réinitialiser un mot de passe qui n'a jamais été rejeté.

L'invite elle-même est le diagnostic. Une fenêtre de navigateur ou un code de second facteur signifie que le serveur a exigé une authentification interactive, tandis qu'un échec silencieux sans invite signifie que le client n'est jamais allé assez loin pour qu'on lui demande.

Renouveler les clés n'est pas réauthentifier

Un renouvellement de clés remplace les clés tout en conservant l'identité authentifiée, c'est pourquoi il se produit silencieusement de temps à autre sur un tunnel sain. La réauthentification répète la vérification d'identité elle-même, et c'est l'événement qui a besoin de vous. IKEv2 sépare explicitement les deux, et un pair peut exiger une réauthentification complète à un intervalle configuré, quel que soit le nombre de renouvellements de clés survenus entre-temps. Les deux événements semblent identiques de l'extérieur jusqu'à ce que vous lisiez lequel le journal nomme.

OpenVPN se comporte de la même manière dans son propre vocabulaire : un intervalle de renégociation rafraîchit le canal de données, et un jeton d'authentification peut être rendu au client pour éviter une connexion complète à la prochaine connexion. Ce jeton a une durée de vie, et le serveur décide s'il l'accepte à nouveau.

Ainsi, une reconnexion après huit heures peut échouer là où une reconnexion après huit minutes avait réussi, sans aucun changement de configuration d'un côté ou de l'autre. C'est toute l'explication d'une invite qui n'apparaît qu'après le déjeuner.

Quand le client ne peut pas relever le nouveau défi

Une politique qui exige une étape dans le navigateur échouera sur un client qui n'a aucun moyen d'en afficher une. Les serveurs sans interface, les scripts de démarrage et les profils anciens conçus pour une authentification par mot de passe seul se heurtent tous à ce mur, et l'échec apparaît souvent comme un délai d'attente générique plutôt que comme une erreur d'authentification.

Les transitions d'appareil et de réseau peuvent aussi tomber dans une fenêtre d'évaluation de la politique, si bien qu'un passage du Wi-Fi à un point d'accès coïncide avec un contrôle qui aurait eu lieu de toute façon. La coïncidence fait paraître le réseau coupable alors que la cause est le minuteur.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

La première ligne montre les événements de renégociation et d'authentification dans le propre journal du client, et la seconde montre les associations de sécurité qu'un pair strongSwan détient actuellement. Comparez les horodatages avec le moment où l'invite est apparue ; une correspondance confirme le minuteur plutôt que le réseau.

Ce qu'il faut signaler et ce qu'il ne faut pas désactiver

Si une connexion manuelle réussit et que la réutilisation automatique échoue systématiquement, dites-le exactement à l'exploitant. Cela nomme le composant : le chemin de réutilisation, pas l'identifiant. Indiquez l'heure de l'échec, le compte utilisé et le type d'invite que vous avez vu.

Ne désactivez pas le second facteur, ne contournez pas la validation du certificat et ne collez pas d'identifiants dans un script pour rendre la reconnexion silencieuse. Chacune de ces actions supprime le contrôle que la politique existe pour imposer, et chacune transforme une invite de connexion en incident.

Demandez plutôt le flux pris en charge : un client capable de mener à bien le défi, une durée de vie de jeton adaptée à la journée de travail, ou un profil non interactif approuvé pour la machine qui ne peut pas demander. Ce sont toutes des décisions de configuration que quelqu'un peut approuver, ce qu'un contournement n'est pas.