Le minuteur de session VPN et le jeton d'authentification expirent séparément

Une coupure VPN peut survenir pour des raisons qui paraissent identiques côté client et n'ont rien en commun en dessous : la session du tunnel s'est terminée, un minuteur d'inactivité s'est déclenché ou un justificatif que le client réutilisait est devenu périmé. Chacune a un responsable différent et un correctif différent. C'est la séquence d'erreurs au moment de la coupure qui les distingue, et elle tient généralement en une ligne.

Trois horloges courent contre un seul tunnel, et une seule d'entre elles est le tunnel.

Trois horloges différentes sur un seul tunnel

L'horloge de session appartient à la passerelle : une durée de connexion maximale, un délai d'inactivité ou les deux, et elle met fin au tunnel dès que l'un des deux est atteint. L'horloge du jeton appartient au système d'authentification et décide combien de temps un justificatif peut être présenté de nouveau sans intervention humaine. L'horloge du chemin appartient au NAT ou au pare-feu situé entre le client et la passerelle, et elle fait expirer les correspondances des flux qu'il considère terminés. Toutes les trois produisent une déconnexion, et aucune ne produit la même ligne de journal.

Seule la première est un concept VPN. Les deux autres viennent de l'identité et du réseau, et elles sont régulièrement confondues avec elle.

Comment le jeton est réellement réutilisé

Les serveurs OpenVPN peuvent émettre un jeton d'authentification après la connexion initiale, si bien qu'une renégociation du canal de contrôle ne redemande pas d'identifiants à l'utilisateur. Le client continue de présenter ce jeton et le serveur décide combien de temps il reste acceptable. Lorsque la durée de vie du jeton est plus courte que l'intervalle de renégociation, la renégociation suivante échoue et le client signale une erreur d'authentification au lieu d'un délai d'attente. C'est pourquoi le même profil fonctionne pendant une heure puis échoue à un point fixe.

L'intervalle de renégociation est un réglage distinct. Le modifier déplace le moment où le jeton est présenté, pas la durée pendant laquelle il vit.

À quoi ressemble chaque expiration côté client

Un délai de session arrive généralement comme une déconnexion propre avec une raison côté serveur, souvent après une durée prévisible et sans aucune erreur d'authentification attachée. Un délai d'inactivité ressemble à du silence : le tunnel cesse de transporter du trafic, puis le keepalive abandonne. Une expiration de jeton arrive sous la forme d'AUTH_FAILED au milieu d'une session qui fonctionnait une seconde plus tôt.

Lisez la ligne, puis regardez l'horloge. Une durée qui correspond à une valeur configurée n'est pas une coïncidence.

Pourquoi un mot de passe enregistré n'aide pas

Un mot de passe en cache répond à un défi pour un mot de passe. Il ne prolonge pas la durée de vie d'un jeton et ne satisfait pas un défi pour un second facteur ni un contrôle de l'état de l'appareil. Augmenter la fréquence des tentatives, réduire les délais de connexion ou réimporter le profil ne change rien à la durée pendant laquelle le système d'identité acceptera le justificatif.

Les correctifs durables sont la bonne durée de vie sur le bon objet, ou un parcours client capable de relever le défi requis sans intervention humaine.

Ce qu'il faut documenter et tester

Notez les trois valeurs : les limites de session et d'inactivité de la passerelle, la durée de vie du jeton et le délai de correspondance pertinent le plus court sur le chemin. Testez ensuite chaque expiration délibérément en raccourcissant une valeur, en observant ce que le client signale et en la rétablissant. Confirmez ce que l'utilisateur doit faire à chaque frontière, car exiger une connexion complète chaque heure est une décision de politique que quelqu'un aurait dû prendre exprès.

Une coupure qui arrive sans aucun événement d'authentification appartient au chemin ou au minuteur d'inactivité, ce qui est une autre enquête avec d'autres preuves.