La plupart des guides répondent à « comment ajouter un peer WireGuard ? » par wg-quick down wg0 && wg-quick up wg0. Ça marche, et ça déconnecte aussi tous ceux qui utilisent le tunnel à ce moment-là, juste pour ajouter une ligne à un fichier. Sur un serveur avec quelques clients, c'est une gêne passagère. Sur un serveur dont tu dépends vraiment, c'est la raison pour laquelle on finit par éviter d'ajouter des peers.
Il existe une commande qui le fait à chaud.
Comment ajouter un peer à WireGuard ?
Une ligne, sur l'interface active :
wg set wg0 peer <CLIENT_PUBLIC_KEY> allowed-ips 10.0.0.5/32
Le peer existe à partir de cet instant. Pas de redémarrage, pas de handshake perdu, aucune interruption pour ceux qui sont déjà connectés. wg set parle directement au module noyau et modifie la configuration active de l'interface.
Vérifie que c'est pris en compte :
wg show wg0
La nouvelle clé publique apparaît dans la liste, sans handshake pour l'instant. C'est normal : le handshake a lieu quand le client envoie son premier trafic.
Comment ajouter un peer en ligne de commande, du début à la fin ?
Sur la machine cliente, génère la paire de clés :
wg genkey | tee client.key | wg pubkey > client.pub
client.key est la clé privée et ne quitte jamais cette machine. client.pub est ce dont le serveur a besoin.
Sur le serveur :
wg set wg0 peer "$(cat client.pub)" allowed-ips 10.0.0.5/32
De retour sur le client, le fichier de config a besoin de la clé publique du serveur, de son endpoint et de l'adresse que tu viens d'attribuer :
[Interface]
PrivateKey = <contents of client.key>
Address = 10.0.0.5/32
[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Les deux clés, c'est l'étape où l'on se trompe : chaque côté détient la clé publique de l'autre côté, jamais la sienne.
Si le nouveau client est un téléphone, ou une machine sans wg installé, tu peux produire sa partie sans terminal. Règle notre générateur de config WireGuard gratuit sur un client avec l'endpoint et le sous-réseau de ton serveur : il crée la paire de clés dans ton navigateur et te donne le fichier client, son QR code et le bloc [Peer] correspondant pour le serveur. Deux choses à vérifier avant usage. Le générateur invente sa propre paire de clés serveur, donc remplace PublicKey dans le bloc [Peer] du client par ta vraie clé, obtenue avec wg show wg0 public-key. Et il attribue au premier client l'adresse .2 du sous-réseau, donc change Address (et le allowed-ips que tu passes à wg set) si elle est déjà prise. La clé privée du client et la clé publique que tu donnes au serveur sont prêtes telles quelles. 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.
Que mettre dans AllowedIPs quand on ajoute un peer ?
Ça dépend du côté où tu te trouves, et cette asymétrie est la source de la plupart des confusions.
| Sur le serveur, pour ce peer | Sur le client, pour le serveur | |
|---|---|---|
| Ce que ça signifie | quelle adresse appartient à ce client | quel trafic envoyer dans le tunnel |
| Valeur typique | 10.0.0.5/32, une seule adresse | 0.0.0.0/0 (tout) ou le sous-réseau du LAN (split tunnel) |
| Peut chevaucher un autre peer ? | Non | sans objet |
| Effet en cas d'erreur | les paquets partent vers le mauvais peer, ou sont rejetés | le trafic contourne le tunnel, ou le tunnel capture ton LAN |
La règle de non-chevauchement est structurelle, pas une question de propreté. AllowedIPs est ce qui indique à WireGuard à quel peer appartient une destination donnée, donc une adresse listée sur deux peers rend cette décision ambiguë, et le symptôme concret est qu'ajouter un client met silencieusement le précédent hors ligne.
Côté client, le tunnel complet 0.0.0.0/0 est simple ; « tout sauf mon LAN » ne l'est pas, car AllowedIPs n'a pas de syntaxe d'exclusion. Notre calculateur AllowedIPs gratuit transforme « tout sauf X » en la liste la plus courte de plages IPv4 et IPv6 à coller dans le bloc [Peer] du nouveau client.
Comment faire survivre le nouveau peer à un reboot ?
wg set modifie l'interface active. Il ne touche pas à /etc/wireguard/wg0.conf, donc un reboot l'oublie. Deux façons de le rendre persistant :
Ajouter le bloc au fichier à la main :
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.0.0.5/32
N'écris pas l'état actif dans le fichier avec wg showconf wg0 > /etc/wireguard/wg0.conf, un raccourci qui circule beaucoup. wg showconf ne connaît que ce que connaît le noyau : la clé privée, le port d'écoute et les peers. Il n'a aucune des lignes propres à wg-quick : Address, DNS, MTU, PostUp, PostDown. Écrase le fichier avec et le wg-quick up suivant monte wg0 sans adresse de tunnel ni règles NAT : chaque client fait son handshake et rien n'est routé.
Si tu veux que l'état actif soit sauvegardé pour toi, mets SaveConfig = true dans [Interface]. wg-quick réécrit alors les peers quand l'interface descend et conserve ses propres lignes. Le piège : il réécrit tout le fichier à ce moment-là, donc un commentaire ou une modification manuelle faite pendant que le tunnel est actif est perdu. Choisis une méthode, fichier édité à la main ou SaveConfig, pas les deux.
Pour recharger un fichier modifié sans couper les sessions :
wg syncconf wg0 <(wg-quick strip wg0)
syncconf applique les différences. wg-quick down/up ne le fait pas : il reconstruit l'interface de zéro, exactement ce que tu cherchais à éviter.
Comment scripter l'ajout de peers sous Linux ?
La séquence n'a aucune étape interactive, elle se scripte donc directement :
#!/usr/bin/env bash
set -euo pipefail
NAME="$1"; IP="$2" # ./addpeer.sh laptop 10.0.0.7
umask 077
wg genkey | tee "$NAME.key" | wg pubkey > "$NAME.pub"
wg set wg0 peer "$(cat "$NAME.pub")" allowed-ips "$IP/32"
printf '\n[Peer]\n# %s\nPublicKey = %s\nAllowedIPs = %s/32\n' \
"$NAME" "$(cat "$NAME.pub")" "$IP" >> /etc/wireguard/wg0.conf
echo "added $NAME at $IP"
umask 077 compte : sans lui, la clé privée fraîchement écrite est lisible par tous les comptes de la machine. set -euo pipefail compte aussi : sans lui, un wg set en échec te laisse quand même des fichiers de clés et un message de succès enjoué. La ligne printf ajoute le peer à la fin du fichier au lieu de le réécrire, pour la raison donnée dans la section précédente.
Une version plus complète de ce script est gratuite sur GitHub : wg-newpeer.sh génère aussi une clé pré-partagée, écrit le .conf client dans ./clients/, applique le changement avec wg syncconf et affiche un QR code quand qrencode est installé. Il est inclus dans notre WireGuard Self-Hosting Kit payant (9 USD), à côté des modèles serveur et client, de la checklist de dépannage en 12 causes et de la checklist de durcissement, si tu veux l'ensemble sous forme de fichiers.
Une main posée sur le clavier pendant que l'écran reste noir : ajouter un peer avec wg set ne produit aucune confirmation visible, c'est pourquoi wg show est la seule chose qui te dit que ça a marché.
Pourquoi le nouveau peer ne se connecte pas ?
La commande a réussi et rien ne se passe. En pratique, c'est presque toujours l'une de ces quatre choses, et les quatre se vérifient au lieu de se deviner.
- Les clés sont inversées. Le serveur détient la clé publique du client ; le client détient celle du serveur. Mettre une clé privée là où une clé publique est attendue échoue en silence.
- Le client est derrière du NAT sans
PersistentKeepalive. Le serveur n'a aucune route de retour tant que le client ne parle pas en premier, et le mapping NAT expire entre-temps.PersistentKeepalive = 25côté client le garde ouvert. - L'adresse est déjà prise. Deux peers avec le même
AllowedIPs, c'est le cas qui paraît le plus mystérieux, car c'est l'ancien peer qui casse. - Le port UDP du serveur n'est pas joignable depuis l'extérieur. Les peers existants sur le LAN marchent toujours, donc le serveur a l'air en bonne santé, mais un nouveau peer en données mobiles n'obtient jamais de handshake. Notre vérificateur de port WireGuard gratuit te dit si ton routeur peut seulement rediriger le port (il détecte le CGNAT et le double NAT) et donne la règle de pare-feu pour ton système. Si la réponse est CGNAT, aucune redirection de port n'y changera rien : la sortie habituelle est de faire tourner le serveur sur un VPS avec sa propre IPv4 publique, comme un Contabo Cloud VPS (lien affilié), et d'y ajouter tes peers. Si tu préfères un hébergeur américain avec une garantie satisfait ou remboursé de 30 jours, Ultahost VPS Basic coûte 5.52 $ par mois sur un engagement de 24 mois (1 GB de RAM, IPv4 dédiée, relevé le 21 octobre 2026), assez pour un serveur WireGuard pour quelques appareils.
Cette troisième panne est la raison d'être de wg-clients-audit. Il lit un dossier de configs clients et signale les adresses en double, les clés privées réutilisées et les plages AllowedIPs assez larges pour avaler le réseau local, les trois défauts qui produisent un tunnel qui se connecte puis se comporte bizarrement. Le lancer avant de remettre une config à quelqu'un est plus rapide que de diagnostiquer après coup.
Commence par wg show wg0. Un peer sans latest handshake n'en a jamais complété, ce qui oriente vers les clés ou la joignabilité. Un peer qui fait son handshake mais ne transporte aucune donnée oriente vers AllowedIPs.
Pendant que tu modifies un bloc de peer, c'est le bon moment pour envisager une clé pré-partagée : un wg genpsk par paire de peers, mélangé au handshake, et elle doit être identique des deux côtés, sinon le tunnel devient muet.
Un VPN change ton IP. Il ne change pas ton navigateur.
Un tunnel remplace l'adresse que voit un service. Il ne change rien à ce que ton navigateur annonce de lui-même (polices, écran, fuseau horaire, pile graphique), et cette combinaison est souvent assez stable pour te reconnaître d'une session à l'autre, avec ou sans tunnel.
Mesure ta propre empreinte de navigateur : mesure passive, aucune question, aucun compte, aucune adresse e-mail.
Ce qu'il faut retenir
wg set ajoute un peer à chaud ; wg-quick down/up déconnecte tout le monde pour faire le même travail. Tout ce que tu ajoutes à chaud disparaît au reboot si tu ne l'écris pas aussi dans la config, et wg showconf n'est pas un fichier de config : redirige-le par-dessus wg0.conf et tu perds Address et PostUp. Un /32 par client, sans jamais de chevauchement. Et quand un nouveau peer se comporte mal, vérifie wg show avant de changer quoi que ce soit : la différence entre « pas de handshake » et « handshake mais pas de trafic » te dit quelle moitié de la configuration examiner.
Et si tu t'apprêtais à copier une config sur un deuxième appareil au lieu d'ajouter un peer, le symptôme qui en découle est documenté : deux appareils, une seule clé WireGuard (en anglais).
★ 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→
