Rédigé par Rédaction CyberSDF / 18 September 2026

Configurer WireGuard sur Linux : un tunnel VPN lisible

Pour un premier tunnel WireGuard, reliez deux pairs avec un sous-réseau privé, puis commencez par AllowedIPs = 10.20.0.0/24. Cette route ne détourne pas tout le trafic Internet. Générez une paire de clefs sur chaque machine, échangez seulement les clefs publiques, activez wg-quick et vérifiez le handshake avant de changer le routage.

Si vous préférez une coordination des appareils et des identités plutôt que des fichiers de pairs à maintenir, le guide Tailscale pour Linux explique le tailnet, MagicDNS et les routes qui changent le trajet.

Le résultat attendu avant la première commande

Le montage ci-dessous relie un client Linux à un serveur WireGuard. Le serveur porte l’adresse 10.20.0.1, le client 10.20.0.2, et le port UDP 51820 est joignable depuis le client. Le premier contrôle consiste à atteindre 10.20.0.1 depuis le client. Il ne s’agit pas encore de faire passer la navigation web ou tout le réseau local dans le tunnel.

Un tunnel réussi donne quatre signaux qui ne se remplacent pas :

• l’interface wg0 existe et possède son adresse privée ;
• le pair attendu apparaît dans wg show ;
• latest handshake reçoit une date après l’envoi d’un paquet ;
• la cible choisie répond, par exemple avec ping -c 3 10.20.0.1.

Le critère technique à retenir est AllowedIPs. Ce champ sert à sélectionner les destinations envoyées vers un pair et à indiquer quelles adresses ce pair peut annoncer sur l’interface. Une configuration peut donc avoir une interface active et une route mal choisie.

Installer les outils et protéger les clefs

Sur Debian ou Ubuntu, la page d’installation officielle WireGuard indique :

sudo apt update
sudo apt install wireguard

Sur Fedora, le paquet indiqué est wireguard-tools; sur Arch Linux, wireguard-tools est également le paquet de référence. Les noms changent selon la distribution, mais le tutoriel utilise ensuite les deux commandes wg et wg-quick. La liste d’installation officielle WireGuard donne le paquet adapté à chaque système.

Chaque pair possède sa propre paire de clefs. La clef privée reste sur sa machine. La clef publique est celle que vous placez dans le bloc [Peer] de l’autre machine. Ne copiez jamais une clef privée dans un message, une capture ou un dépôt de code.

Sur le serveur, créez les clefs dans /etc/wireguard :

sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey'
sudo cat /etc/wireguard/publickey

Faites la même opération sur le client, avec ses propres fichiers :

sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey'
sudo cat /etc/wireguard/publickey

Conservez les deux sorties publiques sous un nom explicite, par exemple SERVEUR_PUBLIC_KEY et CLIENT_PUBLIC_KEY. Le démarrage rapide officiel explique la séquence umask 077, wg genkey puis wg pubkey. Le umask doit être posé avant la génération, car la clef privée n’a pas vocation à être lisible par les autres utilisateurs du système.

Écrire la configuration du serveur

Sur le serveur, créez /etc/wireguard/wg0.conf avec sudoedit :

[Interface]
Address = 10.20.0.1/24
ListenPort = 51820
PrivateKey = CLE_PRIVEE_SERVEUR

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.20.0.2/32

Remplacez CLE_PRIVEE_SERVEUR par le contenu de la clef privée du serveur, et CLIENT_PUBLIC_KEY par la clef publique produite sur le client. Les deux marqueurs doivent disparaître du fichier final. Le serveur n’a pas besoin d’un Endpoint pour ce premier montage : il apprend l’adresse source du client quand celui-ci se connecte.

Protégez le fichier et contrôlez son mode :

sudo chmod 600 /etc/wireguard/wg0.conf
sudo stat -c '%a %n' /etc/wireguard/wg0.conf

Le résultat attendu commence par 600. Le fichier contient une clef privée, contrairement au fichier publickey qui peut être transmis au pair.

Le pare-feu du serveur doit aussi laisser arriver le trafic UDP sur 51820 depuis le chemin réellement utilisé. Si le serveur se trouve derrière une box, le transfert de port doit viser la bonne adresse interne. Un accès à un autre réseau derrière le serveur ajoute du forwarding et des règles de pare-feu adaptées.

Écrire la configuration du client

Sur le client, créez /etc/wireguard/wg0.conf :

[Interface]
Address = 10.20.0.2/24
PrivateKey = CLE_PRIVEE_CLIENT

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/24
PersistentKeepalive = 25

Remplacez CLE_PRIVEE_CLIENT par la clef privée du client, SERVER_PUBLIC_KEY par la clef publique du serveur et vpn.example.net par son nom DNS ou son adresse publique. Le port de l’Endpoint doit correspondre au ListenPort du serveur.

PersistentKeepalive = 25 n’est pas une obligation générale. La documentation WireGuard le recommande comme intervalle raisonnable lorsqu’un pair derrière un NAT ou un pare-feu doit rester joignable après une période sans trafic. Retirez la ligne si ce besoin n’existe pas; un tunnel silencieux n’a pas besoin de générer des paquets périodiques uniquement pour rester bavard.

La clef publique du serveur va dans le [Peer] du client. La clef publique du client va dans le [Peer] du serveur. Inverser ces deux lignes est une erreur fréquente : les noms des machines ne figurent pas dans le format, seule la relation entre les clefs et les adresses permet de vérifier le montage.

Protégez aussi le fichier du client :

sudo chmod 600 /etc/wireguard/wg0.conf
sudo stat -c '%a %n' /etc/wireguard/wg0.conf

La page wg(8) décrit le format INI, les deux sections [Interface] et [Peer], ainsi que les commandes de génération et d’inspection des clefs.

Le choix qui change tout : AllowedIPs

Dans l’exemple, le client contient AllowedIPs = 10.20.0.0/24. Le système envoie donc les adresses du réseau WireGuard vers wg0, tandis que les autres destinations continuent d’utiliser la connexion habituelle. Ce mode est le bon premier essai lorsqu’il faut seulement atteindre le serveur ou un sous-réseau privé.

Pour un seul service, réduisez encore la route :

AllowedIPs = 10.20.0.1/32

Pour un réseau privé derrière le serveur, utilisez son réseau réel, par exemple :

AllowedIPs = 10.30.0.0/24

Sur le serveur, gardez une adresse dédiée au client :

AllowedIPs = 10.20.0.2/32

N’attribuez pas la même adresse autorisée à deux pairs. WireGuard s’en sert pour choisir à quel pair remettre un paquet sortant et le serveur doit pouvoir distinguer ses clients.

Le full-tunnel est une autre décision :

AllowedIPs = 0.0.0.0/0, ::/0

Cette ligne demande de diriger tout IPv4 et tout IPv6 vers le pair. wg-quick traite alors la route par défaut avec des règles de routage particulières. Le serveur doit être configuré pour transférer et masquerader le trafic, et le DNS du client doit rester fonctionnel dans ce nouveau chemin. Ne remplacez pas la route privée par 0.0.0.0/0 pour corriger un handshake absent : vous changeriez le problème au lieu de le diagnostiquer.

Le manuel wg-quick(8) détaille le rôle de Address, DNS, Table, PostUp, PreDown et la manière dont les routes sont déduites des AllowedIPs.

Activer, lire, arrêter

Commencez manuellement sur le serveur, puis sur le client. Le nom wg0 permet à wg-quick de chercher /etc/wireguard/wg0.conf :

sudo wg-quick up wg0
sudo ip address show dev wg0
sudo wg show wg0

Le serveur peut afficher le pair avant que le client n’ait envoyé un paquet, mais latest handshake restera vide ou à never. Depuis le client, vérifiez la route puis envoyez un paquet :

ip route get 10.20.0.1
ping -c 3 10.20.0.1
sudo wg show wg0

Après le ping, latest handshake doit contenir une date récente et les compteurs de transfert doivent évoluer. Le ping vérifie l’adresse du tunnel; les autres réseaux demandent leur propre routage et leurs règles de pare-feu.

Quand le lancement manuel fonctionne, arrêtez l’interface avant de laisser systemd en devenir propriétaire :

sudo wg-quick down wg0

Confiez ensuite le démarrage à systemd :

sudo systemctl enable --now wg-quick@wg0
sudo systemctl status wg-quick@wg0 --no-pager

Pour revenir à l’état précédent :

sudo systemctl disable --now wg-quick@wg0

Ou, pour une session lancée directement avec wg-quick :

sudo wg-quick down wg0

down retire l’interface et les routes ajoutées par wg-quick. N’effacez pas le fichier de configuration avant d’avoir confirmé le retour de la route réseau habituelle.

Lire une panne sans changer cinq réglages à la fois

Si wg-quick up wg0 échoue avant de créer l’interface, relisez d’abord le chemin du fichier, le mode 600, les marqueurs restants et la syntaxe des sections. Une clef copiée avec un espace ou une ligne tronquée ne peut pas authentifier le pair.

Si l’interface existe mais que latest handshake reste à never, contrôlez dans cet ordre :

1. le nom DNS ou l’adresse de Endpoint depuis le client ;
2. le port UDP exposé sur le serveur et le transfert éventuel de la box ;
3. la clef publique du serveur dans le client et celle du client dans le serveur ;
4. le pare-feu des deux machines ;
5. la présence de PersistentKeepalive = 25 seulement si le client est derrière un NAT qui oublie la session.

Si le handshake est récent mais que ping échoue, regardez Address, le masque et la route AllowedIPs. Si le ping du serveur passe mais qu’un réseau situé derrière lui ne répond pas, le problème se trouve généralement dans le forwarding ou le pare-feu du serveur, pas dans la paire de clefs.

Le contrôle local qui attrape les erreurs de fichier

Avant d’utiliser une vraie clef, vous pouvez vérifier la structure et les permissions avec une fixture qui ne touche pas /etc/wireguard :

set -eu
work="$(mktemp -d)"
trap 'rm -rf "$work"' EXIT
umask 077
cat > "$work/wg0.conf" <<'EOF'
[Interface]
Address = 10.20.0.2/24
PrivateKey = REMPLACER_PAR_LA_CLE_PRIVEE_DU_CLIENT
DNS = 10.20.0.1

[Peer]
PublicKey = REMPLACER_PAR_LA_CLE_PUBLIQUE_DU_SERVEUR
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/24
PersistentKeepalive = 25
EOF
chmod 600 "$work/wg0.conf"
stat -c 'mode=%a octets=%s' "$work/wg0.conf"
printf 'interface_sections=%s peer_sections=%s\n' "$(grep -c '^\[Interface\]$' "$work/wg0.conf")" "$(grep -c '^\[Peer\]$' "$work/wg0.conf")"

Le contrôle exécuté le 17 septembre 2026 a renvoyé mode=600 octets=247 et interface_sections=1 peer_sections=1 sur Linux 6.8.0-106-generic avec iproute2-6.1.0; dans cet environnement de rédaction, wg, wg-quick et le module noyau WireGuard étaient absents, donc l’activation et le handshake doivent être vérifiés sur la machine cible équipée des outils.

Les marqueurs de clefs sont volontairement présents dans cette fixture. Une sortie positive confirme uniquement le mode du fichier et la présence d’une section locale et d’une section distante. Après remplacement des marqueurs par de vraies clefs, le contrôle utile est celui de la machine cible :

sudo wg show wg0
sudo ip address show dev wg0
sudo ip route get 10.20.0.1

Un latest handshake récent, un compteur de transfert qui augmente et une réponse de la cible forment un contrôle plus solide qu’une simple interface visible.

La décision utile pour commencer

Commencez en split-tunnel avec une seule adresse ou un seul réseau autorisé. Vous pourrez ensuite élargir AllowedIPs après avoir vérifié le serveur, le DNS, le forwarding et le retour du trafic. Pour comparer ce besoin avec une synchronisation de fichiers, l’article sur Syncthing et les dossiers entre appareils rappelle qu’une copie de fichiers ne crée pas un tunnel réseau. La grille de choix d’un logiciel aide à séparer le besoin, les données touchées et la maintenance.

Le diagnostic réseau général peut ensuite s’appuyer sur les commandes pour diagnostiquer une connexion Linux, tandis que l’univers Linux et terminal replace les adresses, routes et services dans un parcours plus large.

Un tunnel WireGuard est prêt quand le pair attendu fait un handshake et que la destination prévue répond. Tout le reste, notamment le full-tunnel, vient après cette preuve simple.