VPNSmith
VPS Contabo
self-host-vpnINFO

Deux appareils, une seule clé WireGuard : ce qui casse vraiment, et pourquoi ça semble aléatoire

Copier une même config client sur un téléphone et un portable fonctionne, jusqu'à ce que les deux soient connectés. Le trafic part alors vers celui qui a fait le dernier handshake, le serveur ne peut pas les distinguer, et impossible de révoquer l'un sans couper l'autre. Ce que fait le protocole, et la solution en trois commandes.

Par Eric Gerard · Fondateur · VPNSmith - Spécialiste self-host VPN & VPS GDPR4 min de lecturePhoto via Pexels

Vous installez WireGuard sur un portable, ça fonctionne, et copier cette même config sur un téléphone prend dix secondes. Les deux se connectent. Pendant un temps, rien ne semble anormal.

Puis les deux sont connectés en même temps, et l'un d'eux cesse de recevoir du trafic. Sans erreur, pas de façon systématique, et généralement pendant que vous essayez de faire autre chose.

La solution, c'est une paire de clés par appareil. Notre générateur de config WireGuard gratuit crée une paire de clés, une adresse et une config distinctes pour chaque peer, directement dans votre navigateur, et s'il vous reste à louer le serveur, un Contabo Cloud VPS 4 à 5,50 €/mois (lien affilié) est livré avec sa propre IPv4 publique. Si vous préférez un hébergeur américain avec 30 jours satisfait ou remboursé, le VPS Basic d'Ultahost coûte 5,52 $ par mois sur 24 mois (1 Go de RAM, IPv4 dédiée, relevé le 21 octobre 2026), assez pour un serveur WireGuard desservant quelques appareils. Le générateur est gratuit jusqu'à 10 appareils ; au-delà, WireGuard Pro (notre propre produit, 9 EUR en une fois, sans abonnement) relève la limite à 250 et ajoute un ZIP unique avec chaque .conf client et son QR code en PNG, pratique pour équiper tout un bureau ou toute une famille d'un coup.

Ce que voit le serveur

WireGuard identifie un peer par sa clé publique. Pas par son IP, pas par l'appareil, pas par un nom. Deux appareils portant la même clé privée sont, pour le serveur, un seul peer qui n'arrête pas de bouger.

Chaque handshake met à jour l'endpoint enregistré pour ce peer, c'est-à-dire l'adresse et le port auxquels le serveur envoie ses réponses. Le téléphone fait un handshake, les réponses vont au téléphone. Le portable fait un handshake, les réponses vont au portable. Celui qui n'a pas fait le handshake le plus récent continue d'envoyer des paquets qui arrivent bien, et ne reçoit plus rien en retour.

C'est tout le mécanisme, et il explique exactement le symptôme : une connectivité qui bascule entre deux appareils à des intervalles que personne ne contrôle, puisque l'intervalle de handshake n'est pas quelque chose que vous planifiez.

Les trois conséquences, par ordre de ce qu'elles vous coûteront

Vous ne pouvez pas les distinguer. wg show liste un peer, une heure de handshake, un compteur de transfert. Le trafic du téléphone et celui du portable s'additionnent. Si vous avez un jour besoin de savoir quel appareil a fait quelque chose, l'information n'existe pas.

Vous ne pouvez pas en révoquer un seul. Retirer la clé du serveur retire l'accès à tous les appareils qui la détiennent. Un téléphone perdu, c'est aussi couper le portable, puis réémettre des clés pour les deux.

AllowedIPs devient ambigu. Côté serveur, AllowedIPs est ce qui associe un paquet à un peer. Deux appareils derrière une seule entrée de peer partagent une seule adresse de tunnel, donc tout ce qui est routé vers cette adresse atteint l'appareil qui détient l'endpoint à ce moment-là.

Un serrurier au travail sur un établi dans son atelier, taillant une clé sur une machine, avec des centaines de clés vierges suspendues à un panneau perforé derrière lui
Un serrurier au travail sur un établi dans son atelier, taillant une clé sur une machine, avec des centaines de clés vierges suspendues à un panneau perforé derrière lui

La solution : une clé et une adresse par appareil

Sur le client, ou sur le serveur si vous générez pour quelqu'un d'autre :

wg genkey | tee phone.key | wg pubkey > phone.pub

Sur le serveur, ajoutez un bloc peer par appareil, chacun avec sa propre adresse :

[Peer]
# laptop
PublicKey = <laptop.pub>
AllowedIPs = 10.10.0.2/32

[Peer]
# phone
PublicKey = <phone.pub>
AllowedIPs = 10.10.0.3/32

Ajoutez-le à chaud, sans déconnecter personne :

wg set wg0 peer <phone.pub> allowed-ips 10.10.0.3/32

⛔ Puis écrivez-le aussi dans le fichier de config. wg set modifie l'interface en cours d'exécution et rien sur le disque ; un redémarrage le perd. Ce piège, et le reste du cycle de vie d'un peer, sont traités dans ajouter un peer WireGuard.

Retirer un appareil plus tard se fait alors en une seule commande, qui ne touche à rien d'autre :

wg set wg0 peer <phone.pub> remove

La ligne de commentaire n'est pas décorative

Rien dans le protocole ne transporte un nom d'appareil, donc une liste de douze clés publiques est illisible six mois plus tard. Un commentaire # phone au-dessus de chaque bloc est la seule étiquette qui existera jamais, et le jour où vous devrez en révoquer un en urgence, vous serez content de l'avoir.

Deux cas voisins qui ne sont pas celui-ci

Une clé pré-partagée est partagée volontairement. PresharedKey est symétrique et doit être identique aux deux extrémités d'une même paire de peers. Ce n'est pas une réutilisation de clé entre appareils, et les deux se confondent facilement : voir le guide de la clé pré-partagée.

Un appareil, plusieurs tunnels, ça ne pose pas de problème non plus. Un portable peut détenir des clés différentes pour des serveurs différents sans conflit, car l'identité est propre à chaque tunnel et non à la machine.

Si vous distribuez régulièrement des configs à des appareils, générer le QR code est la partie rapide, et elle mérite la même discipline : le QR code WireGuard contient la clé privée en entier, donc un code par appareil et jamais un code partagé.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · port 200 Mbit/s

Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→

Questions fréquentes

Deux appareils peuvent-ils utiliser la même clé WireGuard ?
Ils peuvent se connecter, et c'est bien ce qui induit en erreur. Le serveur identifie un peer par sa clé publique, donc deux appareils qui partagent une clé ne forment pour lui qu'un seul peer. Seul le handshake le plus récent détient l'endpoint, si bien que le trafic retour ne va qu'à un appareil à la fois.
Qu'est-ce qui casse exactement quand je réutilise une clé ?
Le trafic retour suit l'appareil qui a fait le dernier handshake, donc l'autre semble perdre la connexion au hasard. Le serveur ne peut les distinguer ni dans wg show ni dans aucun journal. Et révoquer l'accès d'un appareil le révoque pour les deux, puisqu'il n'y a qu'une seule clé à supprimer.
Partager une clé, c'est un problème de sécurité ou seulement de routage ?
Les deux, et le volet sécurité dure plus longtemps que la gêne. Une clé sur un téléphone perdu plus tard est la même clé, toujours installée sur le portable, donc le seul remède est de la révoquer partout et d'en réémettre. Une clé par appareil réduit cela à une modification d'une ligne.
Combien de peers un serveur WireGuard peut-il avoir ?
En pratique, il n'y a pas de petite limite fixe ; la liste des peers est gardée en mémoire et des milliers restent gérables sur du matériel ordinaire. Ajouter un peer par appareil ne coûte rien, ce qui fait tomber le dernier argument en faveur du partage d'une clé.
Deux peers peuvent-ils partager la même adresse AllowedIPs ?
Non. Côté serveur, AllowedIPs est ce qui lui permet de décider à quel peer appartient un paquet, donc deux peers qui revendiquent 10.10.0.2/32 créent une ambiguïté que le noyau tranche en utilisant l'un des deux. Chaque appareil a besoin de sa propre adresse dans le tunnel.
Articles liés

Pour aller plus loin