Vous n'avez pas besoin de la clé privée pour déboguer un VPN

La demande semble raisonnable : envoyez la configuration pour que le support voie ce qui ne va pas. C'est aussi ainsi que les clés privées finissent dans les systèmes de tickets et les journaux de discussion. Une configuration est une identité, pas un diagnostic, et la personne qui débogue votre tunnel n'a presque jamais besoin de la moitié qui prouve qui vous êtes. La sortie d'état répond aux mêmes questions sans ce risque.

Le mythe veut qu'une configuration soit la seule vue complète. C'est la vue complète la moins sûre.

Le mythe : le support a besoin de la configuration

Le support a besoin du texte de l'erreur, des versions du client et du serveur, du point de terminaison, de l'état de la poignée de main et de l'ordre des événements. Tout cela est de l'état. Une configuration ajoute des clés, et les clés sont ce qui permet à quelqu'un d'autre d'être vous. Remettre une configuration pour corriger un problème de routage, c'est comme poster son passeport pour expliquer un vol retardé. La demande vient généralement de quelqu'un qui n'a jamais vu votre réseau et qui réclame la pièce la plus facile à joindre.

Envoyez la plus petite sortie qui répond à la question, pas la plus grande que vous puissiez trouver.

Ce que l'état montre réellement

Le wg show de WireGuard affiche les interfaces, les pairs, les IP autorisées, les points de terminaison, la dernière poignée de main et les compteurs de transfert, et il n'affiche pas la clé privée. La sortie d'état et de journal d'OpenVPN donne l'état de connexion et les erreurs sans les blocs de clé intégrés. Les deux suffisent pour voir si une poignée de main aboutit, si les compteurs bougent et quel pair est utilisé, ce que le manuel de wg documente comme vue d'état.

Si un assistant demande la configuration avant de demander cette sortie, demandez ce que la configuration montrerait que l'état ne montre pas.

Où se cachent les secrets dans chaque format

Les fichiers de configuration WireGuard contiennent des lignes PrivateKey, et les clés publiques des pairs ainsi que les métadonnées du point de terminaison restent identifiantes même sans elles. Les profils OpenVPN peuvent intégrer des blocs <key> et <tls-crypt> ou pointer vers des fichiers séparés qui voyagent avec le profil. L'archive de support d'un client peut contenir bien plus que ce que montre la fenêtre de journal, y compris des profils en cache dont vous aviez oublié l'existence. Les captures d'écran sont l'autre fuite courante, car une fenêtre de terminal montre plus que la commande que vous vouliez partager.

Lisez la documentation d'export, puis ouvrez le fichier. Une sortie étiquetée diagnostic n'a pas forcément été vidée de quoi que ce soit.

Caviardez, puis envoyez une copie relue

Gardez l'original dans un endroit protégé et envoyez une copie relue. Remplacez les points de terminaison et les clés publiques par des valeurs de remplacement stables lorsque les vraies valeurs ne sont pas nécessaires, et supprimez entièrement les blocs de clé privée au lieu de les masquer partiellement. Le masquage partiel d'un bloc base64 reste une clé divulguée. Relisez le fichier une dernière fois avant qu'il parte, car les archives contiennent souvent une seconde copie du même profil.

Utilisez un canal vérifié et contrôlez qui le reçoit avant de joindre quoi que ce soit.

Si une clé a déjà fuité

Supprimer le message ne récupère pas les copies que d'autres possèdent déjà. Faites tourner l'identité via le processus de révocation et de remplacement de l'opérateur, et considérez l'ancienne clé comme compromise dès l'instant où elle a été envoyée. La plupart des opérateurs remplaceront rapidement l'identité d'un client une fois l'exposition signalée, et c'est précisément le signalement que les gens retardent.

La même règle s'applique à une clé collée dans un ticket, une capture d'écran ou un fil de discussion. La rotation est la solution ; la suppression n'est que du rangement.