Reconstruire un appareil VPN Raspberry Pi sans copier sa clé

Démarrer une fois depuis une image ne fait pas d’un Pi un appareil reconstructible. Il faut un petit ensemble d’entrées réapplicables : une base maintenue, une configuration déclarée, les données persistantes de l’application et une identité d’appareil qui n’appartient qu’à cette carte. Oubliez la dernière et chaque remplacement devient le clone d’un identifiant.

Les étapes ci-dessous sont un ordre de travail, pas une recommandation d’outil. Tout système de configuration capable de les exprimer fera l’affaire.

Dressez d’abord la liste des quatre types d’entrées

L’image de base et ses paquets définissent le système d’exploitation, l’architecture et l’origine des mises à jour, et un constructeur d’images n’aide que si l’outil qu’il nomme est encore maintenu pour votre version. La configuration déclarée est la partie qu’un humain relit : rôles réseau, réglages des services et actions de cycle de vie dont chaque service a besoin. Les données persistantes de l’application sont tout ce que le service ne peut pas régénérer, et leur emplacement comme leur méthode de sauvegarde appartiennent à cette application, pas à l’image. Les identités et secrets des appareils constituent la quatrième entrée, et c’est précisément celle que l’on oublie quand on clone une carte qui fonctionne.

Écrivez les quatre listes avant de reconstruire quoi que ce soit. Une liste avec une ligne vide est une décision que vous n’avez pas encore prise.

Gardez les secrets hors du dépôt et dites où ils vivent

Un dépôt est un bon foyer pour des modèles relus et une configuration non secrète, et un mauvais foyer pour des clés privées VPN, des identifiants administrateur réutilisables et des archives de diagnostic. Si un secret doit exister sur l’appareil, notez d’où il vient, qui peut le lire et comment il est renouvelé. Une clé qui ne vit que sur une carte SD est un point de défaillance unique, tandis qu’une clé copiée sur chaque carte est un identifiant à l’échelle de la flotte sans propriétaire. Ni l’une ni l’autre n’est un plan de reprise.

Le test est simple : si le dépôt fuitait demain, qu’y gagnerait un attaquant ? Les modèles et les notes de topologie survivent. Une identité en service, non.

Laissez l’automatisation posséder ce qu’elle peut rejouer

Le modèle d’Ansible tient un inventaire de nœuds gérés à l’écart des pièces, tâches, rôles et gestionnaires qui se déclenchent quand une tâche signale un changement. Utilisez cette structure pour donner à chaque service un seul propriétaire de configuration au lieu de rejouer un historique de shell. Préférez les opérations sûres à exécuter deux fois et décidez délibérément comment un fichier modifié atteint le processus en cours. Une tâche qui garantit qu’un service est démarré ne le fait pas forcément recharger une configuration que vous venez de réécrire.

Séparez aussi les étapes de l’administration. La connectivité d’amorçage, la configuration courante et la gestion dépendante du VPN sont trois fenêtres différentes, et la troisième peut supprimer votre propre accès si la reconstruction réinitialise le réseau en dessous. Gardez un chemin d’entrée indépendant.

Restaurez données et identité à dessein

Les volumes de conteneur persistent indépendamment du cycle de vie du conteneur, alors que la couche inscriptible à l’intérieur d’un conteneur ne le fait pas, ce qui explique que recréer un conteneur depuis son image ne recrée pas l’état que l’application utilisait, comme le décrit la documentation des volumes. Notez les volumes, les montages et les services externes dont dépend l’appareil, et utilisez le processus de sauvegarde et de restauration propre à l’application. Un conteneur qui démarre sans erreur ne prouve pas que sa base de données et ses fichiers sont d’accord.

Pour l’identité, décidez si vous récupérez le même appareil ou si vous enrôlez un remplaçant, car ce sont des opérations différentes avec un nettoyage différent.

Réconciliez l’accès de l’ancien pair avant d’activer une identité ailleurs, et seulement ensuite testez l’appareil reconstruit dans un environnement isolé ou de récupération. Vérifiez les données requises, la bonne identité, un chemin de mise à jour avec un propriétaire et la politique réseau prévue.

Une image amorçable est une entrée parmi quatre, et c’est la plus facile à reproduire.