Ce qu’un petit manuel VPN doit pouvoir répondre dans l’urgence

L’administrateur qui a pris la relève à 02:00 n’a pas pu dire si le service était sain, parce que le document expliquait la conception et ne disait jamais quoi exécuter. Passer le fichier à quelqu’un d’autre puis quitter la pièce est le seul test qui compte. La plupart des petites notes VPN y échouent dès la deuxième page. La forme ci-dessous passe ce test, et rien en elle n’a besoin d’être long.

Commencez par une carte qu’une personne fatiguée peut parcourir

Notez ce que quelqu’un doit consulter dans l’urgence : les noms auxquels les clients se connectent, les ports sur lesquels le démon écoute, les plages d’adresses qu’il distribue, la manière dont les noms de clients sont résolus et les réseaux derrière le tunnel qui doivent être joignables. Ajoutez le numéro de build que vous exécutez réellement et nommez le composant qui possède chaque pièce mobile, car les routes, le filtre de paquets et les profils de clients sont souvent configurés à trois endroits différents. Notez aussi les dépendances externes : le compte d’hébergement, le lien montant, le fournisseur d’identité et les réseaux privés à l’autre bout. Un tableau ou un schéma dessiné à la main porte mieux cela que des paragraphes, parce que le lecteur survole au lieu de lire.

Nommez ensuite les personnes qui peuvent autoriser un changement d’urgence, avec une voie de contact qui ne dépende pas du fait que le tunnel soit monté. Une ligne d’escalade sans repli est un cul-de-sac précisément dans l’incident qui en a besoin. Deux noms et un numéro de téléphone suffisent ; la carte n’est pas un annuaire du personnel.

Chaque vérification a besoin de la réponse qui compte comme saine

Pour chaque service, placez la commande et la ligne qui signifie qu’elle a fonctionné côte à côte, afin que le lecteur n’ait jamais à déduire l’une de l’autre dans la précipitation. L’état du processus et la joignabilité de bout en bout se situent à des couches différentes : l’une montre que le démon a accepté sa configuration, l’autre qu’un client peut utiliser ce que le tunnel offre. Écrivez les deux lignes et dites quelle panne chacune attrape, car une vérification sans résultat énoncé devient une discussion sur le point de savoir si la sortie a l’air correcte.

systemctl status openvpn-server@lab
ss -lntu | grep 1194

Exécutez les deux et traitez-les comme des preuves séparées plutôt qu’une séquence. Une unité verte peut côtoyer un tunnel que personne ne peut utiliser, et l’inverse se produit quand un écouteur survit à une route cassée. Indiquez la couche qu’observe chaque ligne, et le lecteur saura à laquelle se fier lorsqu’elles se contredisent.

Trois pannes couvrent la plupart des nuits

Point de terminaison injoignable, identité rejetée et connexion sans trafic utile expliquent presque tout ce qui réveille quelqu’un. Pour chacune, listez les deux premières vérifications et la personne à qui escalader, afin que personne n’ait à inventer un ordre de diagnostic à 02:00. Injoignable pointe généralement le chemin ou l’écouteur, une identité rejetée un certificat, un magasin d’identifiants ou une horloge, et une connexion vide les routes, le transfert ou la résolution de noms. Ces trois branches lisent des journaux différents, c’est pourquoi la branche doit être choisie avant que le journal soit ouvert.

Liez la documentation amont au lieu de coller des commandes que vous n’avez pas exécutées sur cet hôte. Une commande non testée copiée d’un autre environnement est pire qu’un pointeur, parce qu’elle a l’air péremptoire et échoue en silence.

Écrivez le changement comme une séquence, pas comme un paragraphe

Pour tout changement, notez le point de contrôle auquel revenir, la vérification qui confirme le succès et la condition qui déclenche le retour arrière, dans cet ordre. Incluez une voie de retour qui ne passe pas par le tunnel, puisque le changement que vous faites est exactement ce qui peut le fermer. Notez comment les révocations actuelles seraient restaurées plutôt qu’un instantané plus ancien, parce qu’une liste périmée réadmet silencieusement des identifiants qui ont été retirés ce matin-là. Des étapes impératives numérotées survivent à la pression ; la prose devient de l’interprétation.

Exercez cette voie de retour avant d’en avoir besoin, chaque fois que le changement est assez important pour compter. Un retour arrière écrit de mémoire est une conjecture avec une date attachée.

Les identifiants vivent ailleurs

Renvoyez au gestionnaire de mots de passe, au coffre ou à l’enveloppe scellée, et dites qui peut l’ouvrir, au lieu de citer quelque matière que ce soit dans le fichier. Les clés privées, les codes de récupération à usage unique et les profils qui intègrent un secret appartiennent à un stockage protégé, et la page devrait expliquer comment un mainteneur autorisé y accède à 02:00. N’utilisez jamais un secret vivant comme exemple, car les exemples finissent collés dans des tickets et des fils de discussion. Un pointeur plus une liste d’autorisations, c’est tout ce dont le document a besoin.

Relisez le fichier après un changement réel ou un exercice de récupération, supprimez les chemins qui n’existent plus et notez à qui revient la prochaine décision d’entretien. Tenez à la fin un journal des changements à trois colonnes : date, ce qui a changé, qui l’a vérifié. C’est cette page qui dit au lecteur suivant si le reste est à jour, et la documentation de systemctl de systemd est un meilleur lien qu’une paraphrase de commandes de service qui dériveront.