Le VPN du Mac se reconnecte juste après avoir cliqué sur Déconnecter
Un moniteur qui traite chaque état déconnecté comme une panne finira par lutter contre le bouton Déconnecter. Séparez l’intention de l’état observé, puis bornez les tentatives.
Cliquer sur Déconnecter fonctionne, et dix secondes plus tard le tunnel revient quand même. Cette boucle est rarement le client VPN qui se comporte mal ; c’est un script de récupération qui ne posait jamais qu’une seule question, « est-il en panne ? », et y répondait en se connectant. Dès que vous séparez la question à laquelle l’utilisateur a répondu de la question que le système rapporte, le correctif devient un peu d’état plutôt qu’une attente plus longue.
Deux questions, pas une
Ce profil doit-il être connecté en ce moment, et que rapporte actuellement le système ? Ce sont des questions différentes avec des propriétaires différents, et une politique de récupération a besoin des deux avant d’agir. L’intention est ce que votre outil décide et retient. L’état observé est ce que la plateforme vous dit.
| Intent | What you observe | What to do |
|---|---|---|
| Wanted | Dropped unexpectedly | Allow one supported recovery attempt |
| Paused by the user | Disconnected | Do nothing until intent changes |
| Wanted | Already connecting | Wait instead of starting a rival attempt |
| Wanted | Authentication needs a person | Prompt, then stop replaying credentials |
Lisez les lignes comme une politique plutôt que comme une liste de cas. La deuxième ligne est celle que la plupart des scripts omettent, et c’est la seule ligne qui distingue un moniteur d’une machine qui tient à avoir raison.
L’état observé n’est pas une préférence
Le modèle d’état Network Extension d’Apple rapporte les états connecting, connected, disconnecting, disconnected et recovery. Tous les cinq décrivent la connexion. Aucun ne dit « l’utilisateur a demandé que ce profil reste en pause », car ce n’est pas du tout un état de connexion. Les clients qui ne sont pas bâtis sur ce cadre exposent leurs propres contrôles pris en charge et appels d’état, et ils tracent la même frontière dans leur propre vocabulaire.
La conséquence est qu’un état déconnecté ne peut jamais s’interpréter seul. Il signifie l’une d’au moins trois choses : le tunnel est tombé, l’utilisateur l’a arrêté, ou le système est entre deux tentatives. Seul votre propre registre d’intention peut les distinguer. Notez ce registre, conservez-le d’un redémarrage à l’autre s’il doit survivre à un redémarrage, et mettez-le à jour au moment où l’utilisateur agit plutôt que de le déduire plus tard d’une ligne de journal.
scutil --nc list
scutil --nc status "Office VPN"Qui d’autre a le droit de démarrer ce profil
Une pause promise par votre assistant ne vaut que ce que valent les autres propriétaires du même profil. Une règle On Demand, une configuration gérée ou un second client peuvent tous demander une connexion, et votre assistant paraîtra cassé alors qu’il se comporte exactement comme écrit.
Trouvez tous les mécanismes qui peuvent démarrer le profil avant de promettre de respecter une pause, et notez lequel l’emporte. Quand un service géré retient délibérément une option de pause personnelle, c’est une décision d’administrateur sur la politique, et non un manque qu’un script devrait combler en luttant contre la gestion.
Rendez les tentatives ennuyeuses
Limitez le nombre de tentatives et faites en sorte que chacune réagisse à quelque chose qui a changé : le réseau est revenu, la passerelle a répondu, l’invite d’identifiants s’est terminée. Une passerelle indisponible, une identité expirée et un second facteur rejeté exigent trois réponses différentes, et une boucle serrée donne la même aux trois.
Regardez ce qu’une tentative rapide produit réellement à l’écran. Les boîtes de dialogue répétées que l’utilisateur ferme sont pires qu’un seul message d’échec clair, et elles apprennent aux gens à cliquer sur les invites sans les lire.
La pause et la politique de trafic sont des promesses distinctes
Un tunnel mis en pause par l’utilisateur laisse souvent le trafic bloqué à dessein, ce qui est tout l’intérêt d’une politique de type kill switch. Cela signifie que Pause ne devrait promettre qu’une seule chose : la récupération s’arrête. Elle ne devrait pas modifier silencieusement ce que le réseau autorise.
Décidez le comportement du trafic séparément, documentez-le à côté du contrôle Pause, et gardez-le cohérent que le tunnel soit en pause, en échec ou absent. Sinon, l’utilisateur apprend que cliquer sur Déconnecter fait quelque chose d’imprévisible, et le prochain ticket d’assistance concerne un réseau qui « cesse parfois de fonctionner » sans raison visible.