Reconnecter un client OpenVPN : trois contrôles, trois portées

Quelqu’un demande que le client VPN soit reconnecté, et cette demande peut signifier trois choses différentes. Elle peut signifier supprimer une session authentifiée, prévenir chaque client qu’un serveur UDP disparaît ou redémarrer le démon lui-même. Chacune a un rayon d’impact différent, et le mauvais choix transforme une correction pour un utilisateur en panne. La portée est la décision, et la commande en découle.

Demandez qui doit être affecté avant de demander quel contrôle utiliser.

Une instance : l’interface de gestion

Une interface de gestion configurée peut lister les instances connectées et en supprimer exactement une. Chaque session porte un identifiant de client, et client-kill CID cible cet identifiant plutôt qu’un nom commun. Lisez l’identifiant vivant dans la sortie d’état actuelle, car une valeur copiée depuis un ancien journal désigne une session qui n’existe plus. Supprimer l’instance met fin à cette connexion et à rien d’autre.

Cela ne garantit pas une nouvelle connexion. Le retour du client dépend de ses réglages de nouvelle tentative, de ses entrées distantes restantes, de ses exigences d’authentification et de l’exécution ou non de l’application de supervision. Un client qui revient obtient un nouvel identifiant, et c’est pourquoi comparer les identifiants est le seul moyen fiable de distinguer l’ancien du nouveau.

Un avis de sortie UDP n’est pas une commande par client

explicit-exit-notify est une directive de configuration sur les événements de sortie et de redémarrage. Sur un client UDP, elle indique à l’homologue que la session se termine, et l’argument numérique contrôle combien de fois l’avis est réessayé. Quand le serveur fonctionne sur UDP, il envoie un message de contrôle de redémarrage à ses clients connectés, et les valeurs documentées distinguent la reconnexion au même serveur du passage à une autre entrée distante. C’est un signal de cycle de vie à large audience.

Rien n’y sélectionne un client arbitraire à un moment arbitraire. Le traiter comme un bouton de reconnexion atteint toutes les sessions connectées à la fois.

Les signaux agissent sur le processus, pas sur une session

SIGUSR1 demande à un processus en cours de relancer sa connexion sans relire la configuration, et les options de persistance décident de ce qui survit à ce redémarrage. SIGHUP va plus loin : il relit le fichier de configuration et rouvre ses ressources. SIGTERM et SIGINT demandent un arrêt ordonné. Ce sont des opérations au niveau du processus : sur un serveur multi-clients, elles touchent chaque session que le processus porte, pas celle nommée dans le ticket.

Quand le processus tourne sous un gestionnaire de services, utilisez le contrôle propre au gestionnaire plutôt que d’envoyer un signal à un PID trouvé dans une liste de processus. Lisez l’unité pour voir quel signal le gestionnaire envoie, car un redémarrage et un rechargement font des choses différentes au même démon.

Décidez la portée avant de choisir le contrôle

Trois questions tranchent. Qui doit être affecté : un utilisateur, chaque client d’un serveur, ou le démon et tout ce qu’il porte. Que doit survivre : la configuration, l’état du tunnel, ou ni l’un ni l’autre. Qui est autorisé : l’intégration de gestion, le propriétaire du service, ou l’opérateur réseau qui contrôle l’avis de sortie. Répondez-y et un seul contrôle convient.

Ajouter un écouteur de contrôle non authentifié pour obtenir un bouton de reconnexion confie à quiconque atteint le port bien plus que ce bouton.

Vérifiez la nouvelle session, pas la déconnexion

Un événement de déconnexion prouve que l’ancienne session s’est terminée. Il ne dit rien d’une nouvelle qui s’authentifie, reçoit une adresse, installe des routes ou atteint la ressource dont l’utilisateur avait besoin. Vérifiez le nouvel identifiant, puis l’état du tunnel, puis une ressource réelle. Ces trois étapes font la différence entre une reconnexion et une connexion qui fonctionne.

Écrivez la portée dans le journal des changements. « J’ai reconnecté le client » n’est pas une description quand le client était l’un de quarante sur un serveur partagé.