Après le script d’installation, quelqu’un doit être responsable du serveur VPN

Deux métiers différents sont vendus comme un seul : transformer une machine en serveur VPN, et ajouter un client VPN à un portable qui doit rejoindre la passerelle de quelqu’un d’autre. Un script d’installation répond au premier et ne peut pas répondre au second, quoi qu’en dise son README. Prenez le projet setup-ipsec-vpn comme exemple concret : il construit un serveur IPsec/L2TP, Cisco IPsec ou IKEv2 sur un hôte Linux pris en charge avec Libreswan et xl2tpd. C’est un contrat de déploiement pour un serveur, pas une recette générale pour n’importe quelle machine. Décidez quel métier est le vôtre avant que le script ne s’exécute, car tout ce qui suit concerne le serveur.

Soyez honnête sur l’hôte

Une machine qui termine aussi autre chose, ou dont le pare-feu est géré par un plan de contrôle cloud plutôt que par le système d’exploitation, est une installation différente d’une machine virtuelle propre. Notez le protocole que vous activez et la version que vous utilisez, puis vérifiez les deux contre la liste de prise en charge du projet, et non contre un billet de blog de l’an dernier.

Activer le service n’ouvre pas le chemin vers lui. Pour IPsec, le réseau devant l’hôte doit laisser passer UDP 500 et 4500 et, selon le déploiement, le protocole ESP lui-même. Un script qui se termine avec succès derrière un groupe de sécurité qui jette le protocole 50 a produit un serveur que personne ne peut atteindre, et rien dans la sortie de l’installateur ne le dira.

Ce que l’installateur prend réellement en charge

Attendez-vous à un fichier de configuration et de secrets IPsec, une configuration du démon L2TP, des options PPP et des unités systemd qui possèdent désormais ces ports. Le README du projet indique que les fichiers de configuration existants sont sauvegardés avant modification, ce qui est utile et n’est pas la même chose qu’une sauvegarde de l’hôte. Décidez quels composants seront mis à jour par les paquets de la distribution et lesquels en relançant ou en réécrivant le script, car ce sont deux voies de maintenance aux modes de défaillance différents.

Épinglez la révision que vous avez approuvée. Une URL de téléchargement qui sert la branche par défaut actuelle peut renvoyer un contenu différent le mois prochain, alors notez le commit ou la version que vous avez exécuté et conservez-en une copie. Cette seule habitude transforme un état non attribuable en quelque chose sur quoi une deuxième personne peut raisonner à deux heures du matin.

Ce que le script ne peut pas vous donner

L’automatisation produit une installation fonctionnelle et s’arrête là. Elle ne décide pas quelles ressources privées le tunnel doit atteindre, ce qui est une question de politique d’accès sur laquelle le pare-feu de l’hôte et le réseau amont ont tous deux un avis. Elle ne décide pas qui reçoit des identifiants, comment ils sont remis, ni comment l’accès d’une personne est retiré quand elle part. Et elle ne décide pas comment la machine est restaurée après une mauvaise mise à jour, ce qui est la partie généralement découverte au pire moment possible.

Les profils clients et les secrets affichés sont du matériel d’accès, pas des journaux d’installation. Un profil généré collé dans un canal partagé est un compte, et la même règle vaut pour les captures d’écran du récapitulatif d’installation. Tenez un inventaire protégé de l’état d’identité nécessaire pour restaurer le service, et notez lesquels de ces identifiants ont été révoqués depuis.

Le premier client est le test de recette

Acceptez le déploiement depuis un client autorisé, avec le protocole que vous avez réellement activé. Vérifiez que le nom privé se résout, que le chemin de retour fonctionne, qu’une reconnexion se comporte bien et qu’une destination hors de l’ensemble autorisé est refusée. Une connexion réussie depuis une autre application cliente n’est pas une preuve pour celle que vous avez livrée.

Si la combinaison que vous voulez n’est plus prise en charge, choisissez une voie maintenue avant l’installation. Ressusciter une ancienne version, affaiblir l’authentification ou relancer un script inexpliqué sont des reports, pas des plans de maintenance, et chacun rend la reprise plus difficile.

Rédigez la page de reprise

Gardez-la courte : le serveur, la révision qui l’a construit, les ports nécessaires, les composants et leurs responsables de mise à jour, les ressources autorisées, le chemin des identifiants et la procédure de restauration. Ajoutez la voie console ou hors bande que vous utiliserez quand une modification du tunnel est ce qui a cassé l’accès. Alors la personne suivante hérite d’un service plutôt que d’une commande qu’elle craint de lancer deux fois.

Revoyez cette page quand l’hôte change, et pas seulement quand quelque chose casse. Un document de reprise qui n’est jamais lu est un document qui a cessé d’être vrai en silence.