Un portable meurt avec trois tunnels WireGuard configurés, et les fichiers de configuration sont toujours sur le disque. Les copier sur une machine de remplacement produit un service qui démarre puis refuse de monter. Les fichiers sont protégés par une clé qui appartient au compte et à la machine qui les ont créés, donc les octets voyagent mais la capacité de les lire non. Le parcours ci-dessous va de la localisation du fichier à l’option qui rétablit réellement le service.

Où vit désormais le fichier du tunnel

L’emplacement a changé entre les versions. Les anciennes installations conservaient les profils dans les données d’applications locales du profil système, dans un dossier WireGuard\Configurations, et les versions actuelles utilisent un répertoire de données dans l’arborescence des fichiers du programme. Chaque tunnel est un seul fichier avec une double extension qui nomme la protection :

Get-ChildItem "C:\Program Files\WireGuard\Data\Configurations"

Le suffixe .dpapi n’est pas décoratif. Le fichier est un blob protégé, et le service est conçu pour le consommer exactement sous cette forme. La manière prise en charge d’installer un tunnel à partir de celui-ci est un appel élevé qui pointe vers le blob :

$blob = "C:\Program Files\WireGuard\Data\Configurations\hq.conf.dpapi"
wireguard.exe /installtunnelservice $blob

Cette commande ne réussit que dans le contexte qui peut déballer le blob. Elle installe un service ; elle ne déchiffre rien pour vous.

Pourquoi le blob ne s’ouvre pas ailleurs

La protection tire sa clé des identifiants de connexion de l’utilisateur et, selon la portée choisie, de la machine. La documentation Microsoft de l’appel de protection indique que la valeur par défaut appartient à l’utilisateur et à la machine qui l’ont chiffré, et une option à l’échelle de la machine change qui peut le déballer. Dans les deux cas, la clé vit dans le matériel d’identification du système d’exploitation, pas dans le fichier. Le texte chiffré est portable ; la clé ne l’est pas.

Prendre possession du dossier change une ACL et rien d’autre. Monter l’ancien disque dans un boîtier et copier le blob sur un nouveau PC vous laisse un texte chiffré dont la clé n’a jamais été copiée. La défaillance est cryptographique, et aucune réinstallation du service ne la change. La nouvelle machine n’a aucune clé maîtresse pour ce compte, et l’ancien magasin de clés ne voyage pas avec le fichier.

Les produits qui stockent les réglages dans un fichier obscurci rendent le contraste évident. Une configuration simplement obscurcie devient lisible dès que vous trouvez l’indicateur qui désactive l’obscurcissement ; un blob protégé reste fermé sans la clé. Confondre les deux pousse les gens à chercher un décodeur qui n’existe pas.

Ce qu’il faut tenter tant que l’ancien système démarre encore

Si l’installation démarre encore, exportez les tunnels depuis le client en étant connecté avec le compte qui les a créés. L’export produit des fichiers de configuration ordinaires, et c’est à ce moment qu’une sauvegarde devient portable.

Si le disque est lisible mais que Windows ne démarre pas, les fichiers protégés sont bel et bien perdus. Les outils qui promettent de les récupérer soit tournent dans le contexte d’origine, que vous n’avez plus, soit vous demandent de livrer le blob et l’image de votre ancien disque, ce qui est une décision qui mérite une pause.

Notez ce que vous apprenez dans les deux cas : les noms des tunnels, les points de terminaison et les clés publiques. Les noms et les points de terminaison vous permettent de reconstruire rapidement, et les clés publiques permettent à l’autre côté d’identifier quelle entrée supprimer.

Reconstruisez plutôt depuis le côté du pair

Pour un pair que vous contrôlez, générez une nouvelle paire de clés et ajoutez la nouvelle clé publique à la liste du pair. Pour un point de terminaison d’entreprise ou hébergé, demandez à l’administrateur d’émettre une nouvelle clé et de supprimer l’ancienne. Cette demande est la même que celle que vous feriez après un vol, car un disque perdu signifie que l’ancienne clé privée doit être traitée comme exposée.

Reconstruisez ensuite le tunnel à partir des valeurs que vous avez notées, et confirmez la poignée de main avant de supprimer autre chose. L’ancienne entrée sur le pair devrait disparaître dans le même changement, afin qu’un disque volé ne puisse pas se reconnecter plus tard.

La leçon relève de la politique de sauvegarde plutôt que d’un outil de récupération. Une configuration WireGuard est un identifiant : quiconque détient la clé privée détient l’identité du pair, et il n’y a pas de second mot de passe en travers. Soit vous exportez délibérément la configuration et la conservez avec vos autres secrets, soit vous acceptez que récupérer signifie réémettre des clés, et vous notez quel choix s’applique à chaque tunnel.

Articles similaires