Clé privée ici, clé publique là : les clés de WireGuard
Votre clé privée reste sur votre appareil ; l’entrée de pair contient la clé publique de l’autre côté. Ne partagez que la moitié publique, et donnez à chaque appareil sa propre identité.
La plupart des échecs WireGuard montés à la main se résument à quelle clé est allée où. La section d’interface porte la clé privée de l’appareil que vous configurez, tandis qu’une section de pair porte la clé publique de la machine à l’autre bout. Intervertir ces moitiés, ou coller la mauvaise, produit une poignée de main qui ne se termine jamais et un journal qui ne nomme jamais de clé. Faites les quatre vérifications ci-dessous dans l’ordre avant de toucher à AllowedIPs ou au DNS.
Deux clés, deux directions
Une clé privée appartient à exactement un appareil et reste dans la section d’interface de cet appareil. Sa moitié publique est ce dont tout autre pair a besoin pour reconnaître l’appareil, et l’outillage la dérive au lieu de l’inventer. Sur le serveur, la clé publique de votre appareil apparaît comme une entrée de pair ; sur votre appareil, la clé publique du serveur tient ce rôle. Lire une configuration à voix haute dans ces termes attrape la plupart des confusions avant qu’elles n’atteignent une poignée de main.
La commande wg affiche ce que l’interface locale utilise réellement, y compris les deux clés publiques. Cela en fait le moyen le plus rapide de séparer une erreur de configuration d’un problème de connectivité :
wg show
wg show interfacesLa première sortie liste chaque pair avec sa clé publique, le point de terminaison qu’il a utilisé en dernier et l’âge de sa dernière poignée de main. Un âge de poignée de main « jamais » d’un côté et récent de l’autre pointe vers une clé qu’un seul bout a acceptée. La seconde commande nomme les interfaces que vous pouvez examiner plus avant.
Quoi partager et quoi ne jamais partager
Une clé publique est faite pour être remise, même si elle identifie encore une relation entre appareils, c’est pourquoi l’envoyer à l’administrateur qui l’a demandée diffère de la publier. Une clé privée ne quitte jamais l’appareil qui l’a générée. Un profil exporté ou un code QR contient toute la configuration, y compris cette clé privée, donc ni l’un ni l’autre n’est sûr à faire circuler, et cacher le texte dans une image ne change rien. Les clés prépartagées sont facultatives et tout aussi secrètes, et les deux bouts doivent porter la même valeur, sinon la poignée de main s’arrête à cette étape.
Une autre distinction mérite d’être dite franchement : un point de terminaison est une adresse et un port, jamais une clé. Coller une clé publique dans le champ du point de terminaison, ou une adresse dans un champ de clé, produit un profil qui s’analyse puis ne fait rien. L’outillage ne l’attrapera pas, car les deux champs ne sont que des chaînes. Le démarrage rapide de WireGuard montre la chaîne de génération et de dérivation en une ligne.
Un appareil, une entrée de pair
Là où le service le permet, chaque appareil devrait porter sa propre identité de pair. Coller le profil complet d’un ordinateur portable sur un téléphone brouille quel appareil détient cette identité sur le serveur et rend plus difficile la révocation d’un seul téléphone perdu. Si une clé privée fuit, retirez l’ancienne autorisation de pair sur le serveur et prévoyez un remplacement. Supprimer le fichier local ne retire pas l’entrée du serveur, et une nouvelle clé cliente n’aide personne tant que le serveur n’en connaît pas la moitié publique.
Gardez la correspondance entre appareil et clé publique à côté de la liste d’adresses. C’est cette liste qui transforme une révocation en une tâche de deux minutes plutôt qu’en un après-midi.
Ce qui échoue encore après la poignée de main
Les paires de clés identifient les pairs ; elles ne décident pas du comportement du réseau. AllowedIPs associe des plages d’adresses à un pair, et le client ou l’outil de configuration gère les routes autour. Le symptôme indique généralement quelle couche ouvrir ensuite :
| What you see | Which key problem it usually means | Where to look first |
|---|---|---|
| Handshake age stays at never on both ends | Peer public key missing, or an endpoint pointing at nothing | wg show, then the endpoint value |
| Handshake completes on one side only | The two ends hold different public keys for each other | wg show on both hosts |
| Handshake works, then no traffic | AllowedIPs or routes rather than keys | wg show and the route table |
| Worked until a key was regenerated | The peer entry still holds the old public key | Compare both public keys, then update the peer |
Le DNS peut échouer après que les deux pairs se sont authentifiés correctement, et une application peut échouer alors que le tunnel lui-même est sain, donc une poignée de main qui fonctionne n’est pas la fin du diagnostic. Les clés ne disent rien non plus sur la pratique de journalisation d’un opérateur ni sur le fait qu’un site reconnaisse votre compte, et ces questions appartiennent ailleurs. Passez aux couches réseau une fois les quatre vérifications passées, car une clé manquante n’est pas un problème de routage déguisé.