Profil WireGuard copié : pourquoi les deux appareils échouent

Le tunnel fonctionnait sur l’ordinateur portable, le fichier de configuration est donc passé sur le téléphone et la tablette, et désormais les handshakes vont et viennent sur les trois. Rien n’a été mal saisi et la configuration du serveur n’a pas été modifiée. Un profil WireGuard n’est pas un compte avec mot de passe que plusieurs appareils peuvent utiliser ; c’est une paire de clés, et seule la moitié publique identifie un pair. Copier le fichier copie l’identité, donc le serveur cherche maintenant à maintenir une seule relation de point de terminaison pour plusieurs appareils qui prétendent tous être le même. Côté serveur, il n’y a pas de second appareil à remarquer, seulement un pair dont l’adresse ne cesse de bouger.

Commencez par le journal des handshakes sur chaque appareil

Ouvrez le client sur chaque appareil et relevez l’heure du dernier handshake ainsi que le point de terminaison actuel avant de changer quoi que ce soit. Dans une installation saine, ces valeurs restent stables tant qu’un appareil est utilisé ; avec une identité dupliquée, les horodatages alternent, et le point de terminaison enregistré sur le serveur peut décrire un appareil différent de celui qui détient le profil. Cette alternance est la signature, et elle explique pourquoi le symptôme ressemble à une connectivité instable plutôt qu’à une erreur de configuration. Les appareils ne sont pas en panne ; ils s’interrompent mutuellement.

Faites le relevé sur les appareils eux-mêmes, afin que chaque observation soit rattachée à une machine précise. Un horodatage copié depuis un chat d’assistance perd ce rattachement et vaut ensuite très peu.

Confirmez si deux appareils partagent une identité

Comparez les clés publiques, jamais les privées. La clé publique dérive de la clé privée, donc deux profils contenant la même clé privée produisent la même clé publique et sont indissociables pour le serveur. Si deux appareils annoncent la même clé publique, la question est réglée et aucun réglage de keepalive n’aidera. Deux clés différentes avec des handshakes instables pointent ailleurs, et c’est pourquoi la comparaison doit précéder tout changement.

wg show wg0 public-key
wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Ces commandes n’affichent que du matériel public et des compteurs, ce qui suffit à une conversation d’assistance. Une entrée de pair sur le serveur avec une seule clé publique et un point de terminaison qui ne cesse de passer d’un réseau à l’autre est le résultat attendu de la duplication, car un paquet authentifié venu d’une nouvelle source met à jour la destination du trafic. Ce comportement est le protocole fonctionnant comme prévu, et c’est pourquoi il est si facile de le prendre pour une panne réseau.

Fournissez une seconde identité correctement

Générez une nouvelle paire de clés sur l’appareil qui en a besoin, puis ajoutez la clé publique obtenue au serveur comme pair distinct avec ses propres adresses autorisées. La clé privée doit être créée sur l’appareil et y rester ; une clé générée ailleurs et collée a traversé au moins un endroit de plus, et ce trajet fait désormais partie de l’histoire de confiance.

umask 077
wg genkey > newdevice.key
wg pubkey < newdevice.key

Côté serveur, il faut la clé publique plus une attribution d’adresse autorisée qui n’entre pas en collision avec l’appareil d’origine. Un profil qui conserve l’ancienne adresse de tunnel tout en présentant une nouvelle clé produit un pair que le serveur peut accepter puis router de travers, ce qui est une défaillance plus subtile qu’un handshake refusé. Vérifiez l’attribution d’adresse avant de vous connecter, pas après la première perte de paquets déroutante.

Retirez le doublon sans casser l’original

Une fois la nouvelle identité opérationnelle, retirez le profil copié de l’entourage de l’appareil d’origine au lieu de supprimer l’entrée serveur que l’original utilise encore. Si la copie a pu être exposée, révoquez-la immédiatement à la place, puis délivrez-en une nouvelle ; la commodité n’est pas une raison de laisser un secret partagé en circulation.

Un service géré qui prend réellement en charge plusieurs appareils par abonnement vous le dira et délivrera des identifiants distincts depuis sa propre interface. La duplication manuelle d’un profil n’est jamais ce modèle, même lorsque l’image de marque du service suggère des appareils illimités.

Testez les deux appareils séparément et ensemble

Vérifiez d’abord chaque appareil seul : handshake, compteurs de transfert qui progressent et une destination que seul le tunnel atteint. Lancez ensuite les deux en même temps et observez la vision du serveur sur les points de terminaison ; deux clés distinctes devraient produire deux entrées de pair stables plutôt qu’une seule qui saute.

Conservez les nouvelles clés publiques avec les notes de déploiement et notez quel appareil détient laquelle. Sans cette liste, la prochaine personne qui copie un profil répétera la même défaillance, et les handshakes alternés seront de nouveau imputés au réseau.