Provisionner un client OpenVPN avec des étapes qui s’arrêtent en cas d’erreur

Les scripts de provisionnement qui signalent une erreur et continuent sont pires que des scripts qui ne s’exécutent jamais. La configuration du client touche des clés protégées, une identité sur la passerelle et un service qui sert peut-être déjà du trafic. Chacun de ces éléments exige une condition d’arrêt, et le script doit savoir à quelle étape il s’est arrêté.

Traitez l’ensemble comme une transaction à cinq points de contrôle, et faites en sorte que chaque point de contrôle refuse de poursuivre de lui-même.

Corrigez les entrées avant de toucher au système de fichiers

Commencez par un contrat explicite : une identité, une source de profil, un propriétaire de service prévu. Vérifiez que le profil existe, que le certificat et la clé auxquels il renvoie sont lisibles et que le répertoire cible appartient au paquet attendu. Un chemin qui se résout n’est pas la preuve que la matière derrière lui est complète.

Rejetez tôt les variables vides. Une $DEVICE non définie qui s’étend à rien transforme install -m 400 $KEY /etc/openvpn/client/ en une copie visant un répertoire, et la défaillance arrive plus tard sous la forme d’un service qui ne peut pas lire sa clé.

Assemblez l’ensemble des profils dans un répertoire de préparation

Construisez d’abord l’ensemble complet dans un endroit privé : profil, CA, certificat client, clé et tout auxiliaire appelé par le profil. Copiez avec install -m 400 -o root -g root pour que les droits soient fixés à la création et non après. Vérifiez ensuite les références à l’intérieur du profil, car une ligne relative ca ou key se résout par rapport au répertoire de travail de l’unité dès que le service démarre. Rien ne doit être écrit dans le répertoire actif tant que l’ensemble complet n’est pas validé.

Enregistrez une empreinte non secrète de ce que cette exécution a produit, par exemple sha256sum office.conf conservé à côté d’un marqueur de version. Cette valeur unique est ce qui permet à une réexécution de distinguer une mise à jour d’une absence d’action.

Permutez atomiquement et conservez l’ensemble précédent

Déplacez l’ensemble préparé vers sa place en une seule opération là où le système de fichiers le permet, et conservez l’ensemble précédent relu sous un nom horodaté. Une copie partielle qui laisse un nouveau profil à côté d’une ancienne clé produit un service qui s’authentifie avec la mauvaise identité et ne journalise rien d’utile sur la raison. Si la permutation ne peut pas être atomique, ordonnez les déplacements pour que le profil arrive en dernier.

Lorsque la cible existe déjà, décidez explicitement si cette exécution est une mise à jour, une réexécution identique ou un conflit avec le profil d’un autre appareil. Écraser silencieusement un profil qui appartient à une autre identité est la façon dont deux machines finissent par partager un seul certificat. Refusez l’exécution et nommez le propriétaire en conflit.

Activez un seul propriétaire et prouvez-le

Choisissez un seul chemin d’activation, soit l’instance systemd soit NetworkManager, et utilisez-le de façon cohérente. Démarrer un processus openvpn non géré à côté d’une unité activée donne deux tunnels, des mises à jour DNS concurrentes et aucune réponse claire sur celui que vise une commande d’arrêt. Après l’activation, vérifiez systemctl is-active openvpn-client@office, puis la route vers le préfixe distant, puis resolvectl status pour le résolveur installé par le tunnel. Terminez en atteignant une ressource pour laquelle le tunnel existe.

Un processus en cours et une icône verte dans la zone de notification sont des faits sur le processus, pas la preuve que l’identité et la politique de trafic ont survécu à la remise.

La réexécution et le retrait sont des flux de travail distincts

Une seconde exécution devrait converger vers les mêmes fichiers relus et le même propriétaire, et non créer un second compte ou un second démon. Le retrait est sa propre procédure : arrêtez le propriétaire exact, archivez ou supprimez le profil local selon la politique, et révoquez l’identité sur la passerelle. Supprimer un fichier de clé local ne révoque pas une copie qui a déjà quitté la machine.

Conservez un chemin de récupération qui ne dépend pas du tunnel, comme un accès console ou une seconde route de gestion. Un changement de provisionnement qui vous enferme dehors est un changement raté même lorsque chaque étape a signalé un succès.

Le script qui vaut la peine d’être conservé est une transaction autour de la propriété et des preuves. Une courte liste de commandes de copie privilégiées n’est pas la même chose.