Comment restaurer un serveur VPN sans dupliquer les identités

Vous avez restauré la sauvegarde, le service a démarré et un client s’est connecté du premier coup. Ce succès est le piège. Une restauration rend les fichiers que le serveur avait au moment de l’instantané, pas l’état d’accès qui a changé depuis, et si l’ancien point de terminaison reste joignable, vous avez maintenant deux machines qui répondent à une seule identité. La solution n’est pas une meilleure sauvegarde ; elle consiste à décider ce que l’hôte restauré a le droit d’être avant qu’il ne réponde à une seule poignée de main.

Une sauvegarde rapporte des fichiers, pas l’autorité

L’instantané contient la configuration du serveur, les clés privées, l’autorité de certification, la liste des pairs et les règles du pare-feu telles qu’elles étaient au moment de la sauvegarde. Il ne peut pas contenir ce qui a changé ensuite : l’appareil que vous avez révoqué, la clé que vous avez réémise, le pair que vous avez retiré à la vente d’un portable, le sous-réseau que vous avez déplacé. Restaurer rembobine les fichiers jusqu’à ce moment. Cela ne rembobine pas les décisions que les gens ont prises depuis.

Le dommage vient précisément de cet écart. Un portable volé, révoqué deux semaines après la sauvegarde, présente un certificat qui se valide encore contre l’ancienne CRL de l’arbre restauré, et le serveur accepte un appareil que vous avez mis au rebut. WireGuard est plus direct : un pair est autorisé parce qu’il est listé, donc un pair supprimé après l’instantané est simplement de nouveau présent. Personne n’a réapprouvé cet accès. L’ancien fichier l’a fait.

L’identité du serveur et celle du client échouent de manières différentes

Sur WireGuard, l’identité du serveur est la clé privée dans wg0.conf, donc copier ce fichier sur un second hôte joignable crée deux serveurs de même identité et qui s’ignorent. Chacun tient sa propre liste de pairs. Retirez un pair sur le nouvel hôte et l’ancien l’accepte toujours ; vérifiez wg show sur l’un et vous voyez la moitié de la vérité. Les clients ne basculent pas non plus d’eux-mêmes : un profil porte un seul Endpoint, donc un appareil continue de parler à l’adresse avec laquelle il a été configuré, qui peut être l’hôte que vous vouliez mettre au rebut.

OpenVPN se duplique à la même couche avec un certificat de serveur, sa clé privée et la clé statique tls-auth ou tls-crypt. Copiez les trois et un client ne distingue plus les instances ; si les deux sont joignables, une reconnexion peut atterrir sur l’une ou l’autre, et chaque journal raconte une histoire partielle. L’autorité de certification est la copie plus profonde. Un arbre easy-rsa restauré est une seconde source de vérité qui peut émettre un certificat valide pour n’importe quel nom que vous lui donnez.

Les clients sont dupliqués aussi, généralement pendant la migration elle-même. Copier un profil sur un appareil de secours « juste pour tester » produit un second appareil avec la même clé et le même nom commun. Avec duplicate-cn, les deux sessions peuvent rester actives en même temps, et une attribution d’adresse statique dans ccd ou ifconfig-pool-persist peut entrer en collision avec l’appareil d’origine. Ce sont deux machines portant une identité, et rien dans la configuration du serveur ne les distingue.

Choisissez l’un des trois états pour l’ancien point de terminaison

Une restauration n’est sûre qu’une fois le sort de l’ancien point de terminaison décidé. Mettez-le au rebut : l’ancien service doit cesser d’accepter le port VPN avant que le nouvel hôte démarre, et si vous ne pouvez pas joindre la machine, bloquez ce port à la périphérie du réseau pour tout sauf votre source d’administration. Réparez le même hôte : réutiliser l’identité est acceptable car une seule machine la détient, mais détruisez ensuite la copie disque ou l’instantané de la VM de l’ancienne clé pour qu’elle ne puisse pas revenir. Construisez une paire de disponibilité : deux hôtes ont besoin d’identités d’hôte distinctes plus un point de terminaison partagé, comme une adresse flottante, un répartiteur de charge ou un DNS que vous pouvez déplacer. Copier la clé privée n’est pas une conception de bascule ; ce sont deux serveurs qui revendiquent un seul nom.

Confirmez dans quel état vous êtes réellement avant de toucher aux clients. L’ancien hôte qui répond sur le port VPN est celui qui acceptera l’appareil révoqué, même si le DNS a bougé. Vérifiez les écouteurs et la clé publique :

ss -lunp | grep -E ':51820|:1194'
wg show wg0
wg pubkey < /etc/wireguard/server.key

Réconciliez d’abord les pairs, les révocations et les adresses

Listez ce que la restauration revendique face à ce qui est actuellement autorisé. Sur WireGuard, wg show wg0 donne la clé, le point de terminaison, la dernière poignée de main et les compteurs de transfert de chaque pair, de quoi repérer un appareil que vous ne possédez plus. Retirez-le à chaud avec wg set wg0 peer <key> remove, puis modifiez aussi la configuration, sinon le pair revient au prochain démarrage. wg show wg0 allowed-ips révèle le second problème : deux pairs sur une adresse, ou une adresse que vous avez déjà réattribuée.

Sur OpenVPN, la liste de révocation est un fichier daté, et une restauration peut en rapporter une ancienne. Vérifiez-la avant que les clients ne se connectent :

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
grep -E 'crl-verify|reneg-sec' /etc/openvpn/server.conf

Si la dernière mise à jour précède la révocation, le serveur honore encore un certificat que vous avez révoqué. OpenVPN 2.4 et ultérieur relisent le fichier CRL à chaque nouvelle connexion, donc remplacer le fichier arrête les nouvelles sessions, mais les tunnels établis persistent jusqu’à la renégociation ; la valeur par défaut de reneg-sec est 3600 secondes, et c’est la baisser ou redémarrer le service qui vous donne le changement tout de suite. Les versions plus anciennes ne reprennent peut-être pas le fichier aussi fiablement, redémarrez donc quand vous ne pouvez pas confirmer le comportement de la version. Le manuel de wg(8) couvre la suppression de pairs et la syntaxe allowed-ips utilisées ci-dessus.

Nettoyez aussi les attributions statiques des appareils qui n’existent plus. Réutiliser l’adresse d’un appareil mis au rebut pour un nouveau alors que l’ancien profil est encore installé crée exactement le doublon que vous cherchez à éviter.

Vérifiez avec un client que vous avez révoqué

Exécutez les contrôles dans l’ordre, depuis un réseau hors du tunnel. D’abord un appareil autorisé se connecte, résout le DNS via le résolveur poussé et atteint une ressource privée. Ensuite l’appareil révoqué doit échouer, en utilisant son profil existant plutôt qu’un nouveau. Puis essayez l’ancien point de terminaison depuis l’extérieur : si le port VPN termine encore une poignée de main, l’ancien hôte est vivant et la duplication est réelle, pas théorique.

Redémarrez l’hôte restauré et répétez les contrôles autorisé et révoqué, car c’est là que le fichier de configuration l’emporte sur ce que vous avez modifié à chaud. Comparez la clé publique ou l’empreinte de certificat de l’hôte à celle qu’utilisait la machine mise au rebut. Des empreintes identiques sur deux machines vivantes signifient que la restauration a cloné l’identité ; des empreintes identiques sur une seule machine sont normales. Notez les versions restaurées, les empreintes de clés et le numéro de série ou la clé de pair révoqués, puis faites la sauvegarde suivante après cette réconciliation, pour qu’elle représente le service tel qu’il est maintenant. Le test qui marche n’est pas qu’un client se connecte. C’est que le client que vous avez retiré reste dehors tandis que l’ancien point de terminaison reste fermé.