Pritunl : l’état de contrôle face au profil généré

Une archive restaure un déploiement Pritunl fonctionnel ; l’autre restaure une image de celui-ci. Un profil client, une copie de la configuration de l’hôte et une archive tar du répertoire d’état ressemblent tous à des sauvegardes, et aucun d’eux à lui seul ne ramène les organisations, les utilisateurs et les définitions de serveur que Pritunl gère. La différence tient à la propriété : un certain état appartient à une base de données, un autre à l’hôte, et un autre est une sortie régénérée. Choisissez la mauvaise couche et la restauration produit un serveur qui démarre, écoute et ne sait rien. Cette comparaison sépare les trois couches pour que l’archive que vous conservez corresponde à la panne dont vous vous remettez.

Deux objets ressemblent à des sauvegardes et un seul restaure le service

Un profil client téléchargé contient un certificat, une clé et un point de terminaison. Il est complet pour cet appareil précis et inutile comme enregistrement du déploiement : il ne porte aucune organisation, aucun utilisateur désactivé, aucune route de serveur et aucun compte administratif. Restaurer à partir d’un dossier de profils donne des clients qui ne peuvent s’authentifier auprès de rien.

Une copie de la configuration de l’hôte est tout aussi partielle. /etc/pritunl.conf contient des réglages au niveau de l’hôte, notamment la façon de joindre la base de données, et ne contient pas les objets VPN eux-mêmes.

Ce que possède la base de données et ce que possède l’hôte

Pritunl conserve les définitions de serveur, les utilisateurs, les organisations et les clés dans MongoDB. Cette base de données est le plan de contrôle de référence, et chaque fichier OpenVPN généré sur le disque est une sortie dérivée de celle-ci. Une modification faite directement dans un fichier généré survit jusqu’à la régénération suivante puis disparaît, ce qui explique pourquoi modifier des fichiers d’exécution n’est pas un correctif durable. La même règle s’applique aux routes et interfaces effectives : elles décrivent ce que le plan de contrôle a produit, pas ce qu’il devrait produire.

L’hôte apporte un ensemble de valeurs plus petit mais non transférable. L’une d’elles est /var/lib/pritunl/pritunl.uuid, l’identité de ce nœud particulier.

Cette identité compte surtout dans un cluster. Un hôte de remplacement a besoin de sa propre inscription plutôt que du clone de l’UUID d’un nœud actif, sinon les deux se disputent la même identité. Consignez la correspondance entre chaque hôte, son UUID et la base de données vers laquelle il pointe, car un seul export de base de données ne décrit pas quels réglages d’hôte appartenaient à quelle machine. Les versions logicielles et les noms de point de terminaison publics appartiennent au même enregistrement.

Faites un export cohérent, pas une copie de répertoire

Copier le répertoire de données MongoDB pendant que le service écrit produit des fichiers qui peuvent ne pas former une base de données utilisable. Utilisez plutôt le chemin d’export pris en charge par la base de données, exécuté contre la topologie que vous avez réellement :

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

Un hôte autonome tolère cette forme simple. Un jeu de réplicas a besoin d’un point dans le temps cohérent, et un export basé sur l’oplog a des exigences qu’un export simple n’a pas. La procédure prise en charge dépend de votre version et de votre topologie MongoDB, alors ne l’inférez pas de la présence d’un répertoire de données. Archivez la couche hôte à côté de l’export, dans la même exécution, avec le même horodatage.

Répétez la restauration avant d’en avoir besoin

Une sauvegarde que personne n’a restaurée est une hypothèse. Construisez le service dans un réseau isolé, restaurez l’export et remettez les fichiers de l’hôte en place :

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

Vérifiez ensuite les objets plutôt que le processus : connectez-vous, confirmez que les organisations et les utilisateurs sont présents, et démarrez un client de test contre une définition de serveur que vous reconnaissez. Empêchez l’hôte restauré d’annoncer le point de terminaison de production ou d’accepter de vraies connexions tant que les adresses et les identités ne sont pas délibérées. C’est aussi là que vous découvrez que l’archive a besoin d’identifiants qui ne vivaient que sur la machine en panne, alors stockez les identifiants de récupération ailleurs, de façon indépendante. Une restauration qui dépend de l’hôte que vous venez de perdre n’est pas un plan de restauration.

Enfin, rappelez-vous qu’un ancien instantané restaure d’anciennes décisions. Si un administrateur a désactivé une identité après la prise de l’export, la restauration la réactive. La réconciliation après la récupération fait partie de la procédure, pas de l’après-coup.