vpn.persistent continue d'essayer, il ne vous garde pas connecté

NetworkManager expose une propriété, vpn.persistent, et on lui demande de répondre à quatre questions différentes à la fois. Sa documentation amont est prudente : la persistance s'applique lorsque le service VPN la prend en charge et que le profil l'active, et la connexion est alors invitée à survivre aux changements de lien et aux pannes jusqu'à une déconnexion explicite. La même documentation montre aussi que la propriété vaut false par défaut, ce que la plupart des plans de récupération ne supposent pas. Lisez-la comme une demande de tentative, non comme la promesse d'un résultat.

Ce à quoi le réglage s'engage vraiment

Une valeur stockée dans un profil est une instruction destinée au gestionnaire, et le gestionnaire doit transmettre cette instruction à un greffon VPN qui sait quoi en faire. Si le greffon installé ignore la propriété, le profil s'active quand même et le journal reste silencieux, ce qui est le pire des deux mondes pour quiconque devra déboguer plus tard. Rien dans un profil ne peut forcer un greffon à implémenter un comportement qu'il n'a pas, donc le seul résultat visible est une absence.

C'est pourquoi la condition de la documentation compte plus que l'interrupteur. Vérifiez quel greffon et quelle version vous avez réellement, et écrivez la version à côté de la description de la connexion pour que la personne suivante n'ait pas à la redécouvrir. Une politique de récupération bâtie sur un indicateur non implémenté échoue exactement une fois en production, et toujours au moment le plus inopportun.

Traiter la propriété comme une tentative fixe aussi la bonne attente pour les tests. Vous ne vérifiez pas si l'indicateur est défini ; vous vérifiez si quelque chose s'est produit lorsque le lien est tombé. Ce sont des expériences différentes, et une seule d'entre elles vaut un après-midi.

Quatre questions fusionnées en une

L'activation demande ce qui fait monter le VPN au départ. Un profil NetworkManager peut être lié à une connexion de base, un service OpenVPN géré séparément possède son propre démarrage, et ajouter un troisième lanceur à cet arrangement vous donne deux propriétaires avec des idées différentes sur qui commande. Décidez quel composant possède le démarrage avant d'ajouter un autre déclencheur.

La récupération demande ce qui se passe lorsque le lien change ou disparaît, et c'est la question étroite que traite vpn.persistent. La vivacité demande si le client peut savoir que l'extrémité distante a cessé de répondre, et le comportement de keepalive ou de redémarrage d'OpenVPN y répond à sa place ; les deux mécanismes sont souvent décrits avec le même mot et implémentés à des endroits différents. Testez-les séparément, avec des outils différents, sinon vous attribuerez un comportement à l'autre.

L'intention demande si la reconnexion est souhaitée tout court, et c'est la question à laquelle l'interrogation d'état ne peut pas répondre. Un arrêt délibéré et une panne produisent le même état inactif, donc tout ce qui se reconnecte sur absence devine une décision humaine. Deviner est acceptable jusqu'au moment où cela passe outre quelqu'un.

Une liste de contrôle qui les sépare

Exécutez les événements dans l'ordre plutôt que de lire la configuration et de raisonner dessus, et consignez ce que chacun montre avec un horodatage.

Premièrement, activez la connexion de base prévue et confirmez que le VPN est monté par le déclencheur attendu et non par un mécanisme que vous aviez oublié installé. Deuxièmement, pendant une interruption approuvée, comparez les événements VPN du gestionnaire, l'état de récupération du client propriétaire et une nouvelle requête vers une ressource privée. Troisièmement, déconnectez délibérément, attendez et confirmez que rien ne redémarre le profil dans votre dos.

La troisième étape est celle que les gens sautent, et c'est celle qui trouve le vrai défaut le plus souvent. Un chien de garde qui interroge un profil actif et se reconnecte quand il est absent annulera allègrement une déconnexion intentionnelle de l'utilisateur. Du point de vue de l'utilisateur, ce n'est pas de la résilience ; c'est une machine qui n'obéira pas. Demandez-leur avant d'en ajouter un.

Écrivez les résultats dans le même document que la description de la connexion. Une politique de récupération ne vaut que ce que valait la dernière fois où quelqu'un l'a vue échouer exprès. Les horodatages rendent la différence visible pour quiconque lira les notes ensuite.

L'authentification fait partie de la récupération

Se reconnecter n'est pas un acte purement réseau. Si le flux approuvé exige un nouveau défi, un code à usage unique ou un secret que le contexte d'activation ne peut pas atteindre, aucun réglage de persistance ne peut le produire à partir de rien.

Cela explique un schéma familier : la connexion se rétablit sur une machine dont le trousseau est déverrouillé et échoue sur la même machine après un redémarrage. La couche réseau a fait exactement ce qu'on lui demandait et la couche d'identifiants n'avait rien à offrir.

Corrigez le flux d'identifiants au lieu de raccourcir l'intervalle de nouvelle tentative. Des tentatives plus rapides face à une invite à laquelle personne ne peut répondre génèrent du bruit dans le journal et une fausse impression que quelque chose est tenté.

La persistance n'est pas un kill switch

La propriété tente de conserver ou de rétablir la relation VPN. Elle ne décide pas de ce que les applications peuvent faire pendant que le VPN est hors service, et elle ne bloque rien par elle-même.

Si l'exigence est qu'aucun trafic ne sorte du tunnel, c'est une politique distincte avec son propre mécanisme, ses propres tests et ses propres modes de défaillance. Supposer que la persistance le couvre transforme une décision de sécurité en accident.

Consignez les deux moitiés dans les notes de récupération : ce que le VPN a tenté et quel trafic applicatif était autorisé pendant la tentative.