Pourquoi un rappel VPN de 23 heures se déclenche pour la mauvaise session

L'avis est apparu vingt minutes après la connexion. Le compteur en dessous tournait depuis la matinée précédente, ou depuis la dernière authentification du compte, et rien dans l'alerte ne disait laquelle. C'est le symptôme : un rappel lié à autre chose qu'à la connexion devant vous.

Le correctif n'est pas une meilleure alerte. C'est décider quelle horloge le besoin désigne, puis lier le minuteur à un objet qui existe dans cette horloge.

Ce qui s'est déclenché, et ce qu'il comptait

Trois sources plausibles produisent le même message. Une règle de calendrier s'exécute à une heure locale fixe et ne sait rien des tunnels. Un compteur dans le client s'accumule tant qu'une connexion est active et survit aux reconnexions. Une politique de passerelle expire la session côté serveur et pousse d'abord un avertissement.

Seules les deux dernières concernent une session, et même elles ne s'accordent pas. Le compteur du client mesure ce que le processus local a observé ; la passerelle mesure ce qu'elle a authentifié et comptabilisé. Une veille, un changement de réseau ou un redémarrage de l'observateur peuvent les séparer de plusieurs heures, et c'est pourquoi l'alerte et l'expiration imposée divergent.

Trois horloges derrière une seule exigence

Commencez par écrire la phrase que vous voulez vraiment. Prévenir avant que la passerelle ne termine cette connexion n'est pas la même exigence que rappeler après une journée de temps connecté. Ce n'est pas non plus la même chose que signaler que cette session dure depuis 23 heures. Chaque version nomme un événement différent, et un composant différent doit y répondre.

Vérifiez ensuite que les données existent. Un horodatage local de début vous donne l'âge de la session sans dépendance au serveur. Une politique de passerelle vous donne la durée de vie restante, mais seulement si la passerelle l'expose. Un rapport d'usage vous donne la durée après coup, et cela ne peut pas piloter un avis préalable.

Liez le minuteur à la session, pas au compte

Choisissez d'abord l'objet. Un compte peut contenir plusieurs appareils et plusieurs sessions simultanées, donc un rappel indexé sur le nom d'utilisateur ne peut pas dire quelle connexion a atteint l'âge. Indexez-le sur le profil plus cette activation, et annulez l'avis en attente quand l'activation se termine.

Ce tableau est un contrat pour votre propre notificateur, pas une description de l'API de rappel d'un client quelconque. Ce que le produit installé documente sur l'état de la connexion est la source à laquelle se lier ; là où il n'expose que des événements d'authentification, dites-le tout haut et acceptez le comportement plus grossier au lieu de déduire une session.

Testez-le avec un seuil court

Ne déboguez jamais un minuteur d'une journée avec une attente d'une journée. Ajoutez un seuil configurable, réglez-le à trente secondes et exécutez quatre transitions dans l'ordre : connexion, attente, déconnexion, reconnexion. Chaque transition doit produire exactement un changement d'état, et la reconnexion doit programmer une nouvelle échéance plutôt que d'hériter de l'ancienne.

# current connection state and profile identity
nmcli -f GENERAL.STATE,GENERAL.CONNECTION connection show work

# the notifier unit you wrote: does it restart the deadline or resume it?
journalctl --user -u vpn-timer.service --since "-5 min" -o cat

Regardez les horodatages plutôt que la formulation. Un avis qui arrive avec l'heure de début de la session précédente a lié le mauvais objet, et un avis qui arrive deux fois pour une même échéance signifie que l'indicateur d'envoi n'a jamais été persisté.

Veille, reconnexion et remise manquée

La veille casse les deux conceptions naïves. Un décompte monotone s'arrête pendant que la machine dort, une échéance sur horloge murale continue d'avancer, et un minuteur qui se déclenche pendant la veille est remis tard ou pas du tout. Décidez quel comportement votre exigence demande, puis mettez la machine en veille au-delà du seuil et confirmez.

La remise mérite le même soin. Si l'avis ne peut pas être affiché, mettez-le en file et revérifiez que la session cible existe encore avant de l'afficher enfin ; sinon l'utilisateur est averti d'une connexion déjà terminée. La déconnexion forcée et le renouvellement des identifiants restent hors de ce chemin, car un rappel qui change en silence le sort de la connexion est une décision de politique habillée en notification.