OpenVPN Access Server : redémarrer le démon ou appliquer le réglage

Deux commandes sont collées pour ce qui ressemble au même travail sur OpenVPN Access Server, et elles font des choses différentes. systemctl restart openvpnas arrête et redémarre tout le produit. sacli start relève les services internes qui lisent la configuration que vous venez de modifier. Choisir entre elles n’est pas une question de goût : cela dépend de ce que dit la documentation du réglage lui-même, de si votre session passe par le serveur que vous allez redémarrer et de si vous regardez seulement le bon produit.

Deux couches, un démon

Access Server tourne comme une seule unité systemd, openvpnas, et ce démon supervise les services internes derrière l’interface web et les écouteurs VPN. sacli est l’interface en ligne de commande vers la même installation, à /usr/local/openvpn_as/scripts/sacli, et il peut démarrer, arrêter et interroger ces composants internes sans remplacer l’unité.

C’est pourquoi les deux commandes existent. Un redémarrage du démon réexécute tout, y compris le processus qui termine les tunnels des clients. sacli start demande au démon déjà en cours de relever ses composants pour qu’ils lisent la nouvelle configuration, et c’est ce que la plupart des changements de propriétés exigent réellement.

Première condition : ce que dit la documentation du réglage

Lisez la page du réglage que vous avez modifié, pas celle d’un réglage modifié le mois dernier. Une propriété écrite via ConfigPut est normalement suivie de sacli start, et ce couple est l’étape d’application documentée. Un changement de comportement au niveau de l’écouteur, ou tout ce que la page décrit comme exigeant un redémarrage du service, est la classe où le redémarrage de l’unité est correct.

Les deux commandes ne sont pas interchangeables, donc le mode d’échec quand on devine est asymétrique. Utiliser sacli start alors qu’un redémarrage complet était nécessaire laisse un ancien processus servir la configuration précédente, ce qui donne l’impression que le réglage a été ignoré. Un redémarrage complet alors que sacli start aurait suffi coupe chaque client connecté sans raison.

Deuxième condition : votre session est-elle dans le tunnel

Si vous administrez Access Server via le VPN qu’il fournit, le redémarrage supprime la connexion qui porte votre shell. La commande peut se terminer après la mort de votre session, ce qui vous laisse deviner si elle a fonctionné. sacli start peut aussi interrompre brièvement une session pour la même raison lorsque le composant redémarré traite votre trafic.

Gardez un chemin hors bande ouvert avant l’une ou l’autre commande : une console du fournisseur, une console de l’hyperviseur ou une session série. Cette condition décide quand vous exécutez la commande, pas laquelle, et c’est elle qui transforme un changement de deux minutes en rapport d’incident.

Troisième condition : est-ce bien le produit que vous croyez

Access Server n’est pas Community OpenVPN. Une installation community exécute des unités comme openvpn@server ou openvpn-client@profile, avec la configuration dans /etc/openvpn, et sacli n’y existe pas. Redémarrer toutes les unités contenant openvpn dans leur nom sur un hôte partagé, c’est ainsi que des tunnels sans rapport tombent ensemble.

Identifiez avant de toucher à quoi que ce soit : systemctl status openvpnas --no-pager répond si Access Server est bien ce qui tourne, sacli status liste ses composants internes, et systemctl list-units --type=service liste les unités dont le nom contient openvpn. Si la dernière commande montre des unités nommées d’après un profil, vous êtes sur le produit community et le reste de ce texte ne s’applique pas.

Appliquez, puis vérifiez au-delà de active

Une unité qui rapporte active a un processus en cours, ce qui n’est pas la même chose qu’un chemin d’authentification qui fonctionne. Après l’étape d’application, vérifiez sacli status pour les composants que vous attendiez redémarrer, confirmez que la valeur a été enregistrée avec sacli ConfigQuery, puis lancez une connexion client limitée avec un compte de test.

Terminez par quelque chose au niveau applicatif : atteignez une ressource privée par le tunnel, pas seulement un ping vers l’adresse publique du serveur. Une poignée de main qui réussit alors que la route poussée ou le réglage DNS est faux passera tous les contrôles de service et échouera quand même à la personne qui a signalé le problème.

le tutoriel du fournisseur sur la gestion des services est la référence pour savoir quelles opérations appartiennent à sacli, et cela vaut la peine de l’ouvrir avant de décider qu’un redémarrage est l’option sûre.

La décision en une passe

Parcourez ces quatre lignes et arrêtez-vous à la première qui correspond :

• La page du réglage nomme sacli start, ou vous venez d’exécuter ConfigPut : utilisez sacli start.
• La page exige un redémarrage, ou le changement touche les écouteurs plutôt que les propriétés : utilisez systemctl restart openvpnas.
• Votre shell arrive par ce serveur : organisez d’abord l’accès console, puis exécutez la commande choisie par les deux lignes ci-dessus.
• Vérification : sacli status, ConfigQuery pour la valeur, une connexion, une ressource privée. L’état du service seul n’est pas la ligne d’arrivée.

Deux de ces lignes sont des contrôles et deux sont des actions, et c’est tout l’intérêt de l’ordre. Si vous ne pouvez pas répondre à la question du produit, arrêtez-vous : la commande que vous alliez lancer appartient à une autre installation, et le tunnel que vous coupez ne sera pas celui que vous visiez.