Combien de temps OpenConnect doit-il réessayer un VPN interrompu ?

--reconnect-timeout répond à une question étroite : après la chute du tunnel, combien de temps ce processus client continue-t-il d’essayer avant d’abandonner et de quitter. La page de manuel d’OpenConnect consigne cette option avec une valeur par défaut documentée de 300 secondes pour les nouvelles tentatives qui suivent une perte de lien ou un pair qui a cessé de répondre, et le nombre est une échéance pour un seul client en cours d’exécution, non une preuve que le VPN reste joignable. Ce n’est pas non plus une politique de maintien en vie du processus, et c’est là que commence l’essentiel de la confusion.

La confusion s’aggrave dès qu’un second mécanisme se superpose. Un superviseur qui redémarre le client, une sonde qui ping la passerelle et la fenêtre de nouvelles tentatives intégrée peuvent tous réagir à une même panne, et l’incident produit alors trois chronologies que personne ne peut concilier.

Ce que la fenêtre de reconnexion borne réellement

Imaginez que le réseau d’accès disparaisse quelques secondes. Le client voit le lien tomber, ou cesse d’entendre les réponses du pair mort, et commence à rétablir la session en conservant l’état qu’il peut. Les tentatives se poursuivent jusqu’à ce que la passerelle accepte de nouveau ou que la fenêtre s’épuise, et une fenêtre épuisée se termine par une sortie non nulle. C’est cette sortie, et non la valeur du délai, qui marque le passage de la propriété du cycle de vie à celui qui supervise le processus.

La fenêtre ne dit rien de la fréquence d’exécution d’une sonde et ne peut pas prolonger l’authentification. Si la passerelle a révoqué la session, ou si le compte exige désormais un second facteur neuf, attendre davantage ne rendra pas l’ancienne session valide. Une nouvelle tentative n’aboutit que si le chemin revient, si la passerelle reconnaît encore la session et si les identifiants demandés restent utilisables ; lisez donc le nombre comme une échéance et non comme un intervalle de vitalité.

La fenêtre ne régit pas non plus ce que font les applications pendant qu’elle court. Selon la plateforme et selon la portée de la panne, le client peut se reconnecter avec les routes encore installées, ou après leur retrait. C’est pourquoi une requête émise au milieu d’une coupure a tendance à rester suspendue jusqu’au délai au lieu d’échouer rapidement.

Les redémarrages du superviseur et les nouvelles tentatives du client sont deux couches

Laissez le client en cours d’exécution consommer sa propre fenêtre, et laissez le gestionnaire de services réagir à la sortie. Un client au premier plan sous systemd avec une politique de redémarrage donne exactement cette séparation : des tentatives pendant une période bornée, puis une seule décision de redémarrage. Le résultat est une chronologie unique que vous pouvez encore reconstituer ensuite.

Un client en arrière-plan plus une sonde indépendante qui lance une autre copie quand elle ne voit pas d’interface est le schéma qui tourne mal. Les deux processus se disputent alors le même nœud de périphérique, les routes et les réglages du résolveur. Si vous voulez vraiment un démon, mettez l’option sur la ligne de commande avec laquelle le client démarre réellement :

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Deux détails de cette ligne pèsent. --background détache le processus, si bien que le fichier pid devient la seule prise fiable sur lui, et le délai n’est consommé que tant que ce même processus vit ; un superviseur qui le tue ne laisse aucun budget pour continuer.

Les déconnexions volontaires ont besoin de leur propre signal. Une pause planifiée et une coupure réelle sont identiques pour un observateur naïf, toutes deux se lisent comme « non connecté ». Pilotez la pause via l’opération d’arrêt du superviseur, ou un marqueur que l’enveloppe comprend, pour qu’un arrêt délibéré ne déclenche pas un redémarrage que personne n’a demandé.

Éviter que la passation ne course la boucle de tentatives

La reprise sans surveillance dépend d’identifiants qui se renouvellent sans personne présente. Un trousseau qui ne se déverrouille que dans une session de bureau interactive, ou un jeton qui exige toujours un code saisi, laissera le client bloqué à l’étape d’authentification dès que le chemin revient. Réglez ce flux avant d’allonger la fenêtre, car une fenêtre plus longue ne fait que donner à la même invite bloquée plus de temps pour échouer.

La vérification du serveur ne doit pas être assouplie pour réduire les invites. C’est précisément l’épinglage ou l’ancre de confiance qui valide la passerelle qui rend une reconnexion automatique sûre, et le désactiver pour éviter une question de certificat échange une interruption visible contre une invisible. Conservez l’identité vérifiée et réparez plutôt l’invite ; un client prêt à se connecter à n’importe quelle passerelle est pire qu’un client qui s’arrête et attend.

La présence d’une interface n’est pas non plus un signal de santé. Un périphérique de tunnel peut exister avec une session morte derrière lui, et un processus de lancement peut exister sans aucun tunnel. Aucune de ces observations ne résiste à une vraie requête. La santé doit venir de ce dont l’utilisateur a besoin, par exemple une requête qui traverse le tunnel vers un service interne connu.

Ce qu’il faut vérifier pendant et après une coupure

Exécutez quatre événements comme des tests distincts : une interruption plus courte que la fenêtre, une coupure plus longue que celle-ci, un échec d’authentification et un arrêt délibéré. Chacun doit se terminer dans un état différent et prévisible, et la frontière entre les deux premiers est toute la raison du choix d’une valeur.

Gardez les contrôles tournés vers l’extérieur, car la table des processus ne prouve que très peu à elle seule. Regardez le pid rester stable pendant la coupure courte, puis confirmez qu’il a disparu et a été remplacé une fois après la longue :

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Pendant l’interruption courte, confirmez que le client a réellement réessayé au lieu de quitter trop tôt, et que les routes et les entrées du résolveur sont revenues sans doublons. Pour la coupure plus longue, confirmez une sortie propre et exactement un redémarrage ensuite. Pour l’échec d’authentification, confirmez que le client ne tourne pas contre une passerelle qui continuera de le refuser. Ajoutez un contrôle vérifiant que le pid revient à une seule valeur au lieu de s’accumuler.

Pour l’arrêt délibéré, l’URL de santé doit rester injoignable et le processus doit rester arrêté. Fermez ensuite la boucle côté application : la même requête doit échouer tant que le tunnel est absent et doit réussir après son retour, depuis l’adresse source que votre politique attend. Une icône de tunnel verte n’est pas une preuve, mais une requête aboutie en est une.