Sauvegarde du serveur VPN : décider ce qui doit être restaurable

Copier un fichier de configuration n’est pas une sauvegarde, et une sauvegarde que personne ne peut restaurer n’est pas un plan. L’archive doit contenir l’identité du service, la politique qui l’entoure et l’état qui indique quels appareils sont encore autorisés. Elle doit aussi être protégée, car dans la plupart des déploiements l’archive accorde exactement ce que le VPN accorde. Décider ce qui doit être restaurable vient d’abord ; la liste des fichiers découle de cette décision.

Partez de la cible de reconstruction

Écrivez ce qu’un serveur reconstruit doit faire avant de lister un seul fichier : terminer les mêmes tunnels, présenter la même identité et refuser les appareils actuellement révoqués. Cette phrase écarte la plupart des copies naïves, car un répertoire de configuration contient rarement la liste de révocation ou la dépendance d’identité externe. Elle expose aussi les éléments qui vivent hors de l’hôte, comme les enregistrements DNS, les règles de pare-feu cloud et l’annuaire contre lequel la passerelle s’authentifie. Un plan qui les ignore produit un serveur restauré qui semble sain et n’admet personne.

Regroupez le matériel en trois catégories : identité, configuration et état. L’identité, ce sont les clés, les certificats et l’autorité qui les signe. La configuration, ce sont les réglages du démon, les pools, les routes et la politique de pare-feu, tandis que l’état est l’ensemble des pairs, des comptes et des révocations qui change chaque jour.

L’identité est la partie que vous ne pouvez pas régénérer

Les clés privées ne peuvent pas être recréées de mémoire, et les certificats qui en dépendent expirent selon un calendrier que vous héritez plutôt que choisissez. Sauvegardez la clé du serveur, le matériel de provisionnement des clients et l’autorité de certification, puis notez lesquels doivent rester hors ligne. Une clé d’autorité qui ne vit que sur la passerelle en fonctionnement est à une compromission d’une réinitialisation complète d’identité pour chaque client. Notez ce qui est délibérément stocké ailleurs pour que personne ne le duplique dans une archive moins protégée.

La révocation mérite sa propre ligne dans le plan. Restaurer la configuration d’hier peut réintroduire une identité que vous avez supprimée aujourd’hui, ce qui transforme une reprise en incident de sécurité. Conservez l’état de révocation actuel ailleurs, indépendamment de l’instantané vers lequel vous reviendriez, et vérifiez-le après toute restauration.

Capturez l’état à un seul instant

Une copie prise pendant que le service écrit produit un inventaire incohérent, et des données d’identité incohérentes sont pires qu’une copie propre plus ancienne. Utilisez le chemin d’exportation pris en charge pour chaque magasin, puis enregistrez l’heure de l’instantané, car toute question ultérieure sur la restauration en dépend.

wg showconf wg0 > /srv/backup/wg0.runtime.conf
sqlite3 /var/lib/vpn/admin.db ".backup '/srv/backup/admin.db'"
cp -a /etc/wireguard /srv/backup/etc-wireguard
sha256sum /srv/backup/*.conf > /srv/backup/MANIFEST

La première commande réimprime l’interface en cours comme configuration, ce qui est le moyen le plus rapide de capturer les pairs ajoutés à la main plutôt que par un outil de gestion ; le manuel de wg(8) le documente. La ligne sqlite est le modèle d’une base de données de gestion : la commande de sauvegarde produit une copie cohérente pendant que l’écrivain continue. La copie du répertoire préserve les permissions, ce qui compte car ces fichiers de clés ne sont lisibles que par root. Le manifeste est ce qui permet de distinguer une archive complète d’une archive tronquée.

Rendez la restauration possible, puis essayez-la

Chiffrez l’archive et gardez la clé de récupération ailleurs que sur la machine d’où elle vient. Une sauvegarde dont la phrase secrète n’existe que sur le serveur défaillant est une sauvegarde que personne n’ouvrira. Limitez la récupération aux personnes qui pouvaient déjà administrer la passerelle, et journalisez chaque récupération. Testez la restauration sur un réseau isolé, car une identité clonée montée à côté de la production crée deux serveurs qui répondent pour la même clé de pair.

Documentez les exclusions aussi soigneusement que le contenu. Les règles de pare-feu cloud, les enregistrements DNS et un annuaire externe peuvent chacun nécessiter leur propre étape de récupération. Une copie de fichiers réussie n’est pas la preuve que le service revient ; la seule preuve qui compte est un point de terminaison reconstruit qui passe le même test d’acceptation que l’original.