VPN WireGuard sur Linux : 12 étapes [2026]

Un VPN auto-hébergé avec WireGuard chiffre tout votre trafic, contourne la censure réseau et vous rend votre vie privée pour le prix d’un petit serveur, environ 5 € par mois. Là où OpenVPN traîne 100 000 lignes de code et IPsec en aligne encore davantage, WireGuard tient dans à peine 4 000 lignes, ce qui le rend plus rapide, plus simple à auditer et bien plus facile à configurer. Fusionné dans le noyau Linux 5.6 le 29 mars 2020, il est aujourd’hui présent par défaut sur toutes les distributions modernes. NordVPN (NordLynx) et Mullvad s’appuient sur lui pour leurs offres commerciales.

Ce tutoriel vous guide pas à pas, en 12 étapes et environ 30 minutes, pour déployer votre propre serveur WireGuard sur un VPS Ubuntu 24.04 ou Debian 12, y connecter vos ordinateurs et vos téléphones, et durcir l’installation contre les fuites DNS. Tout est testé pour 2026, avec les commandes exactes, des exemples de sortie réels et une section de dépannage complète. Aucune connaissance préalable des VPN n’est requise, mais une aisance avec la ligne de commande Linux aide.

Pourquoi choisir WireGuard pour un VPN en 2026

WireGuard a redéfini ce qu’on attend d’un protocole VPN. Sa philosophie tient en un mot : la simplicité. Le code source complet du module noyau représente environ 4 000 lignes, contre des dizaines de milliers pour OpenVPN et plusieurs centaines de milliers pour la pile IPsec/StrongSwan. Cette compacité n’est pas qu’une coquetterie d’ingénieur. Moins de code signifie moins de surface d’attaque, des audits de sécurité plus rapides et bien moins de bugs exploitables. Des cryptographes ont relu le protocole, qui s’appuie sur des primitives modernes et éprouvées.

Côté cryptographie, WireGuard fait des choix tranchés et n’offre aucune option à configurer, ce qui élimine les erreurs de paramétrage. L’échange de clés utilise Curve25519 (ECDH), le chiffrement authentifié repose sur ChaCha20-Poly1305, le hachage sur BLAKE2s, et la protection contre le déni de service sur SipHash24. La dérivation de clés passe par HKDF. Contrairement à OpenVPN, vous ne choisissez pas votre suite de chiffrement : tout le monde utilise la même, la meilleure disponible. Si une faille était découverte dans une primitive, WireGuard prévoit un mécanisme de versionnage pour migrer l’ensemble du réseau.

La performance achève de convaincre. WireGuard tourne dans l’espace noyau, ce qui évite les coûteux changements de contexte entre l’espace utilisateur et le noyau que subit OpenVPN. Sur des tests publiés par Protectli sous OPNsense, WireGuard atteint 2,18 à 4,15 Gbit/s selon le matériel, tandis qu’OpenVPN plafonne entre 816 Mbit/s et 1,09 Gbit/s dans les mêmes conditions. L’analyse de Zenarmor résume un débit supérieur d’environ 15 % et une latence inférieure d’environ 20 % par rapport à IPsec. Les chiffres exacts varient selon le processeur, le MTU et la taille des paquets, mais la tendance est constante : WireGuard est le protocole le plus rapide sur la quasi-totalité des configurations.

Dernier atout, l’expérience utilisateur. Le concept de « cryptokey routing » associe chaque clé publique à une plage d’adresses IP autorisées, ce qui rend la configuration déclarative et lisible. Un fichier de configuration WireGuard tient en une dizaine de lignes au format INI, là où une configuration OpenVPN équivalente en demande souvent plus de cinquante, réparties dans plusieurs fichiers de certificats. Cette lisibilité est précieuse quand vous gérez vous-même votre infrastructure.

WireGuard contre OpenVPN et IPsec : le comparatif

Avant de mettre les mains dans le cambouis, situons WireGuard face aux deux protocoles historiques. Le tableau ci-dessous synthétise les différences structurelles qui expliquent pourquoi tant de fournisseurs et d’administrateurs ont migré vers WireGuard depuis 2022. Gardez en tête que les débits dépendent du matériel : ils servent à illustrer un ordre de grandeur, pas à promettre un résultat exact sur votre serveur.

Critère	WireGuard	OpenVPN	IPsec/IKEv2
Lignes de code	≈ 4 000	≈ 100 000	≈ 400 000+
Débit (test Protectli)	2,18 à 4,15 Gbit/s	0,82 à 1,09 Gbit/s	1,87 à 2,25 Gbit/s
Espace d’exécution	Noyau	Espace utilisateur	Noyau
Transport	UDP uniquement	UDP ou TCP	UDP (ESP)
Cryptographie	Fixe (ChaCha20-Poly1305)	Configurable (OpenSSL)	Configurable
Port par défaut	51820/UDP	1194/UDP	500 et 4500/UDP
Temps de configuration	≈ 10 lignes	50+ lignes	Élevé
Reconnexion (roaming)	Transparente	Lente	Moyenne

La colonne « reconnexion » mérite une explication. WireGuard est sans état au sens où il ne maintient pas de session permanente : chaque paquet porte les informations nécessaires pour être routé vers le bon pair. Quand votre téléphone passe du Wi-Fi à la 5G, la connexion bascule instantanément sans renégociation. C’est un confort déterminant pour un usage mobile, là où OpenVPN impose souvent une reconnexion visible de plusieurs secondes.

L’unique transport UDP est à la fois une force et une limite. Une force, car UDP évite le problème de « TCP sur TCP » qui dégrade les débits d’OpenVPN en mode TCP. Une limite, car certains réseaux d’entreprise ou hôtels bloquent l’UDP non standard. Si vous devez traverser ces réseaux, vous combinerez WireGuard avec un outil d’obfuscation comme udp2raw ou un tunnel TCP, sujet que nous évoquerons dans les conseils avancés. Pour comprendre comment le chiffrement de transport protège vos échanges au quotidien, notre article sur HTTPS et TLS pose des bases utiles.

Prérequis et versions nécessaires

Réunissez ces éléments avant de commencer. Les versions indiquées sont celles validées pour ce tutoriel en juin 2026 ; des versions plus récentes fonctionneront sans difficulté puisque WireGuard est intégré au noyau.

Un serveur (VPS) Linux avec une adresse IP publique : Ubuntu 24.04 LTS ou Debian 12, noyau 5.6 ou supérieur. Un petit VPS à 1 vCPU et 1 Go de RAM suffit largement (offres à partir de 4 à 5 € par mois chez la plupart des hébergeurs européens).
Un accès root ou sudo sur ce serveur, via SSH.
Le paquet wireguard version 1.0.x (outils wg et wg-quick), disponible dans les dépôts officiels.
Un client : application WireGuard officielle pour Windows, macOS, Linux, iOS (App Store) ou Android (Google Play / F-Droid), toutes en version stable 2026.
Le port UDP 51820 ouvert et routé jusqu’à votre serveur (à vérifier chez votre hébergeur si un pare-feu externe existe).
Environ 30 minutes et une connaissance de base de la ligne de commande Linux (éditer un fichier, lancer un service).

Vérifiez d’emblée la version de votre noyau, car WireGuard a besoin du support intégré (5.6+) pour fonctionner sans module externe. Sur la quasi-totalité des VPS récents, c’est acquis.

$ uname -r
6.8.0-31-generic

$ lsb_release -d
Description:    Ubuntu 24.04.1 LTS

Étape 1 : Préparer le serveur et mettre à jour le système

Connectez-vous à votre VPS en SSH, puis mettez à jour la liste des paquets et le système. Un système à jour évite les conflits de dépendances et corrige les failles connues avant même d’exposer un nouveau service au réseau. Travaillez en tant qu’utilisateur disposant de sudo, jamais directement en root pour vos opérations quotidiennes.

# Se connecter au serveur
ssh utilisateur@VOTRE_IP_PUBLIQUE

# Mettre à jour les dépôts et le système
sudo apt update && sudo apt upgrade -y

# Identifier l'interface réseau publique (souvent eth0 ou ens3)
ip route list default
# default via 203.0.113.1 dev eth0 proto static

Notez le nom de l’interface publique affiché après dev dans la dernière commande. Dans cet exemple, c’est eth0, mais sur de nombreux VPS modernes elle s’appelle ens3, enp1s0 ou similaire. Vous en aurez besoin à l’étape 6 pour la règle de NAT. Notez aussi votre adresse IP publique, que les clients utiliseront comme point de terminaison (endpoint). Si vous ne la connaissez pas, récupérez-la ainsi :

$ curl -4 ifconfig.co
203.0.113.42

Profitez de cette étape pour durcir votre accès SSH si ce n’est pas déjà fait : désactivez l’authentification par mot de passe au profit des clés, et changez éventuellement le port par défaut. Un serveur VPN devient une porte d’entrée vers tout votre trafic ; il mérite une hygiène de sécurité irréprochable. Notre guide sur la sécurité des mots de passe détaille pourquoi les clés valent toujours mieux qu’un mot de passe, aussi long soit-il.

Étape 2 : Installer WireGuard

L’installation se résume à un seul paquet. Sur Ubuntu et Debian, le paquet wireguard tire automatiquement les outils en espace utilisateur (wireguard-tools, qui fournit wg et wg-quick). Le module noyau, lui, est déjà présent puisqu’il fait partie du noyau Linux depuis la version 5.6.

# Installer WireGuard et ses outils
sudo apt install wireguard wireguard-tools -y

# Vérifier que les binaires sont disponibles
wg --version
# wireguard-tools v1.0.20210914 - https://git.zx2c4.com/wireguard-tools/

# Vérifier que le module noyau se charge
sudo modprobe wireguard && echo "Module WireGuard OK"
# Module WireGuard OK

Si la commande wg --version renvoie un numéro, vous êtes prêt. Sur un noyau antérieur à 5.6 (rare en 2026, sauf systèmes très anciens), il faudrait installer le module DKMS via wireguard-dkms, mais ce cas est devenu marginal. Sur les conteneurs LXC ou OpenVZ non privilégiés, le module noyau peut être absent et inaccessible ; vous devrez alors utiliser l’implémentation en espace utilisateur wireguard-go ou demander à votre hébergeur un noyau compatible. Vérifiez ce point avant d’aller plus loin si vous êtes sur un VPS très bas de gamme.

Étape 3 : Générer les clés cryptographiques du serveur

WireGuard repose sur une paire de clés Curve25519 par pair. Le serveur a la sienne, chaque client a la sienne. La clé privée ne doit jamais quitter la machine qui la détient ; seule la clé publique est partagée. Générons d’abord la paire du serveur, en restreignant immédiatement les permissions pour que personne d’autre que root ne puisse lire la clé privée.

# Se placer dans le dossier de config et durcir l'umask
cd /etc/wireguard
umask 077

# Générer la clé privée puis en dériver la clé publique
wg genkey | sudo tee server_private.key | wg pubkey | sudo tee server_public.key

# Afficher les deux clés (à conserver pour la config)
echo "Privee serveur : $(sudo cat server_private.key)"
echo "Publique serveur : $(sudo cat server_public.key)"

La sortie ressemble à ceci (vos clés seront différentes, ce sont des chaînes en base64 de 44 caractères) :

Privee serveur : 4Hn9c0xJ2vQpL8mZ3kF7sT1yB6dW0aR5eN2uG8hK4M=
Publique serveur : xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=

L’umask 077 garantit que les fichiers créés ne sont lisibles que par leur propriétaire. C’est crucial : quiconque obtient la clé privée du serveur peut déchiffrer le trafic et usurper son identité. Pour aller plus loin sur la sécurité, vous pouvez ajouter une clé pré-partagée (PresharedKey) entre chaque paire de pairs, qui ajoute une couche de protection symétrique utile contre une future attaque quantique sur Curve25519. Générez-la avec wg genpsk et nous verrons où l’insérer à l’étape 5.

Étape 4 : Activer le routage IP avec sysctl

Pour que votre serveur fasse transiter le trafic des clients vers Internet (le rôle d’un VPN « full tunnel »), il doit se comporter en routeur. Par défaut, Linux ne transmet pas les paquets d’une interface à l’autre. Activons donc le forwarding IPv4 (et IPv6 si vous l’utilisez) de façon persistante.

# Activer le forwarding de façon permanente
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
echo 'net.ipv6.conf.all.forwarding=1' | sudo tee -a /etc/sysctl.d/99-wireguard.conf

# Appliquer immédiatement sans redémarrer
sudo sysctl --system

# Vérifier la valeur
sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 1

Le résultat net.ipv4.ip_forward = 1 confirme que le serveur acheminera désormais les paquets entre l’interface WireGuard et l’interface publique. Si vous n’avez pas besoin d’IPv6, vous pouvez omettre la seconde ligne, mais l’activer évite les fuites d’adresse IPv6 réelle lorsque vos clients ont une connectivité IPv6 native. Nous reviendrons sur ce risque de fuite à l’étape 11. Placer la directive dans un fichier dédié sous /etc/sysctl.d/ plutôt que dans /etc/sysctl.conf garde votre configuration propre et facile à retirer.

Étape 5 : Rédiger la configuration du serveur (wg0.conf)

Voici le cœur du dispositif. Créez le fichier /etc/wireguard/wg0.conf. Le nom wg0 deviendra le nom de l’interface réseau virtuelle. La section [Interface] décrit le serveur lui-même : sa clé privée, son adresse dans le réseau du tunnel et le port d’écoute. Nous choisissons le sous-réseau privé 10.8.0.0/24 pour le VPN, avec le serveur en 10.8.0.1.

# /etc/wireguard/wg0.conf  (sur le SERVEUR)
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = 4Hn9c0xJ2vQpL8mZ3kF7sT1yB6dW0aR5eN2uG8hK4M=

# Regles de NAT appliquees au demarrage et a l'arret du tunnel
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# Les pairs (clients) seront ajoutes ci-dessous a l'etape 9

Remplacez PrivateKey par la clé privée du serveur générée à l’étape 3, et eth0 par le nom réel de votre interface publique relevé à l’étape 1. Les jetons %i sont remplacés automatiquement par wg-quick par le nom de l’interface (wg0). Les lignes PostUp et PostDown créent et suppriment proprement les règles de pare-feu et de NAT en même temps que le tunnel, ce qui évite de laisser des règles orphelines.

Si vous avez généré une clé pré-partagée à l’étape 3, elle ne se place pas ici mais dans chaque bloc [Peer], via la directive PresharedKey, et doit être identique des deux côtés. Sauvegardez le fichier, puis vérifiez ses permissions : il contient votre clé privée et ne doit être lisible que par root.

sudo chmod 600 /etc/wireguard/wg0.conf
sudo ls -l /etc/wireguard/wg0.conf
# -rw------- 1 root root 412 juin 11 14:22 /etc/wireguard/wg0.conf

Étape 6 : Configurer le NAT avec iptables ou nftables

Le NAT (masquerade) réécrit l’adresse source des paquets des clients pour qu’ils semblent provenir du serveur, condition indispensable pour qu’Internet sache où renvoyer les réponses. À l’étape 5, nous avons placé la règle iptables directement dans PostUp, ce qui est la méthode la plus simple et la plus portable. Si vous préférez gérer le NAT séparément, ou si votre distribution utilise nftables (devenu le défaut sur Debian 12 et Ubuntu récents), voici les équivalents.

# Variante nftables (a placer dans PostUp/PostDown ou un fichier dedie)
# Creer la table et la chaine de NAT
sudo nft add table ip wireguard
sudo nft 'add chain ip wireguard postrouting { type nat hook postrouting priority 100 ; }'
sudo nft add rule ip wireguard postrouting oifname "eth0" masquerade

# Verifier la regle
sudo nft list table ip wireguard

Le tableau suivant clarifie le rôle de chaque règle de filtrage, une source fréquente de confusion pour qui débute avec le routage Linux.

Règle	Chaîne	Rôle
FORWARD -i wg0 ACCEPT	filter	Autorise le trafic entrant depuis le tunnel
FORWARD -o wg0 ACCEPT	filter	Autorise le trafic sortant vers le tunnel
POSTROUTING MASQUERADE	nat	Réécrit l’IP source vers l’IP publique
INPUT 51820/udp ACCEPT	filter	Laisse passer les paquets WireGuard entrants

Important : ne mélangez pas iptables et nftables sur le même système, car les deux peuvent entrer en conflit et créer des comportements imprévisibles. Choisissez une approche et tenez-vous-y. Sur Ubuntu 24.04, iptables est en réalité une façade (iptables-nft) au-dessus de nftables, donc la syntaxe iptables de l’étape 5 fonctionne parfaitement et reste la plus simple pour la majorité des installations.

Étape 7 : Ouvrir le pare-feu et démarrer le service systemd

Si vous utilisez le pare-feu UFW (fréquent sur Ubuntu), autorisez le port WireGuard et le SSH avant de démarrer le tunnel, sinon vous risquez de vous verrouiller hors du serveur. Puis lancez le service via l’unité systemd wg-quick@wg0, qui lit votre wg0.conf et monte l’interface automatiquement.

# Ouvrir les ports necessaires
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 51820/udp comment 'WireGuard'
sudo ufw enable

# Demarrer WireGuard et l'activer au demarrage
sudo systemctl enable --now wg-quick@wg0

# Verifier l'etat du service
sudo systemctl status wg-quick@wg0 --no-pager

Une sortie saine ressemble à ceci, avec active (exited) qui est normal pour ce type d’unité oneshot :

● [email protected] - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/[email protected]; enabled)
     Active: active (exited) since Thu 2026-06-11 14:25:03 UTC
    Process: 1843 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0)

Confirmez que l’interface est bien montée et que WireGuard écoute sur le bon port :

$ sudo wg show
interface: wg0
  public key: xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
  private key: (hidden)
  listening port: 51820

$ ip addr show wg0
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN
    inet 10.8.0.1/24 scope global wg0

Aucun pair n’apparaît encore, c’est normal : nous n’avons pas de client. Notez au passage le MTU de 1420 choisi automatiquement, un point que nous affinerons dans les réglages avancés.

Étape 8 : Générer les clés et la configuration du client

Chaque appareil client a sa propre paire de clés. Vous pouvez générer la paire sur le serveur par commodité, mais l’approche la plus sûre est de la générer sur le client lui-même, afin que sa clé privée ne transite jamais par le réseau. Pour ce tutoriel, générons-la sur le serveur pour aller vite, puis nous transférerons uniquement la configuration finale au client.

# Sur le serveur, generer la paire du premier client
cd /etc/wireguard
wg genkey | tee client1_private.key | wg pubkey > client1_public.key

echo "Privee client1 : $(cat client1_private.key)"
echo "Publique client1 : $(cat client1_public.key)"
# Privee client1 : aF3kP9wQ2mL7nZ8xR5tY1bV6cD0eG4hJ8uN2sK7iM0=
# Publique client1 : Hx7kLp2nQ9wZ4mR8tY1bV6cD0eG3hJ5uN8sK2iA9Bg=

Créez maintenant le fichier de configuration du client. Il reflète celui du serveur en miroir : la section [Interface] décrit le client (sa clé privée, son adresse 10.8.0.2 dans le tunnel, le serveur DNS à utiliser), et la section [Peer] décrit le serveur (sa clé publique, son point de terminaison public et les plages à router).

# client1.conf  (a transferer sur l'appareil CLIENT)
[Interface]
PrivateKey = aF3kP9wQ2mL7nZ8xR5tY1bV6cD0eG4hJ8uN2sK7iM0=
Address = 10.8.0.2/24
DNS = 1.1.1.1, 1.0.0.1

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
Endpoint = 203.0.113.42:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

La valeur AllowedIPs = 0.0.0.0/0, ::/0 côté client signifie « route tout mon trafic, IPv4 et IPv6, dans le tunnel » : c’est le mode full tunnel, qui masque votre IP et chiffre tout. Si vous vouliez seulement accéder au réseau privé du serveur (split tunnel), vous mettriez ici uniquement 10.8.0.0/24. Le DNS = 1.1.1.1 force la résolution via un résolveur côté tunnel, ce qui prévient les fuites DNS. Choisissez un résolveur respectueux de la vie privée ; les enjeux sont les mêmes que ceux que nous décrivons dans notre comparatif Proton Mail contre Tuta sur la minimisation des métadonnées.

Étape 9 : Déclarer le client comme pair sur le serveur

Le serveur doit connaître la clé publique du client et l’adresse qui lui est réservée dans le tunnel. Ajoutez un bloc [Peer] à la fin de /etc/wireguard/wg0.conf. Notez la différence essentielle avec le client : côté serveur, AllowedIPs est restreint à l’adresse unique du client (/32), car ici cette directive sert d’autorisation et de routage, pas de redirection de trafic.

# A ajouter a la fin de /etc/wireguard/wg0.conf sur le serveur
[Peer]
# client1
PublicKey = Hx7kLp2nQ9wZ4mR8tY1bV6cD0eG3hJ5uN8sK2iA9Bg=
AllowedIPs = 10.8.0.2/32

Vous pouvez recharger la configuration sans couper les connexions existantes grâce à la combinaison wg syncconf, ce qui est précieux en production. Voici la commande idiomatique qui applique le nouveau fichier à chaud :

# Recharger sans interrompre les pairs deja connectes
sudo wg syncconf wg0 <(wg-quick strip wg0)

# Verifier que le pair apparait
sudo wg show wg0 peers
# Hx7kLp2nQ9wZ4mR8tY1bV6cD0eG3hJ5uN8sK2iA9Bg=

Si vous préférez la simplicité au prix d’une brève coupure, un sudo systemctl restart wg-quick@wg0 recharge tout le fichier. La méthode syncconf reste recommandée dès que des utilisateurs sont connectés. Une erreur classique consiste à oublier ce rechargement après avoir édité le fichier : le serveur ignore alors le nouveau client et le handshake échoue silencieusement.

Étape 10 : Connecter le client et vérifier le handshake

Transférez le fichier client1.conf sur votre appareil. Sur un poste Linux, copiez-le dans /etc/wireguard/ puis lancez wg-quick up. Sur Windows ou macOS, importez le fichier dans l’application WireGuard officielle. Sur mobile, nous générerons un QR code à l’étape 12 pour éviter de saisir les clés à la main.

# Sur un client Linux
sudo cp client1.conf /etc/wireguard/wg0.conf
sudo wg-quick up wg0

# Tester la connectivite vers le serveur dans le tunnel
ping -c 3 10.8.0.1
# 64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=12.4 ms

# Afficher l'etat et verifier le dernier handshake
sudo wg show

La ligne décisive est latest handshake. Si elle affiche un instant récent, votre tunnel est établi et chiffré. Vous devez aussi voir des compteurs transfer augmenter à mesure que le trafic passe.

$ sudo wg show
interface: wg0
  public key: Hx7kLp2nQ9wZ4mR8tY1bV6cD0eG3hJ5uN8sK2iA9Bg=
  private key: (hidden)
  listening port: 51820

peer: xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
  endpoint: 203.0.113.42:51820
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 8 seconds ago
  transfer: 1.24 MiB received, 320.50 KiB sent

Si latest handshake n’apparaît jamais, le problème vient presque toujours du pare-feu (port 51820/UDP fermé), d’une clé mal copiée, ou d’un endpoint erroné. La section dépannage ci-dessous passe ces cas en revue méthodiquement.

Étape 11 : Empêcher les fuites DNS et vérifier votre IP publique

Un tunnel établi ne suffit pas : encore faut-il que tout votre trafic, y compris les requêtes DNS, passe réellement par lui. Une fuite DNS révèle les sites que vous visitez à votre fournisseur d’accès, anéantissant l’intérêt du VPN. Vérifions d’abord que votre IP publique est bien celle du serveur, puis que le DNS ne fuit pas.

# Votre IP publique doit desormais etre celle du serveur (203.0.113.42)
curl -4 ifconfig.co
# 203.0.113.42

# Verifier qu'aucune adresse IPv6 reelle ne fuit
curl -6 ifconfig.co 2>/dev/null || echo "Pas de fuite IPv6 (ou IPv6 routee dans le tunnel)"

Si curl -4 ifconfig.co renvoie l’adresse de votre serveur, le full tunnel fonctionne. Pour les fuites DNS, rendez-vous sur un service de test comme dnsleaktest.com depuis le navigateur du client : tous les serveurs DNS affichés doivent correspondre au résolveur que vous avez défini (ici 1.1.1.1), et aucun ne doit appartenir à votre fournisseur d’accès. Sur Linux, si vous constatez une fuite malgré la directive DNS =, installez le paquet openresolv ou resolvconf, dont wg-quick a besoin pour réécrire /etc/resolv.conf.

Les fuites de données personnelles ne se limitent pas au DNS : une mauvaise configuration de VPN peut exposer bien plus. Notre dossier sur les fuites de données explique comment des métadonnées en apparence anodines suffisent à vous identifier. Pour un usage sérieux, testez aussi les fuites WebRTC, que votre navigateur peut provoquer indépendamment du VPN.

Étape 12 : Ajouter d’autres clients et un QR code pour mobile

Ajouter un appareil suit toujours le même rituel : générer une paire de clés, attribuer la prochaine adresse libre (10.8.0.3, 10.8.0.4, etc.), créer le fichier client, puis déclarer le pair sur le serveur et recharger. Pour les téléphones, l’application WireGuard sait importer une configuration en scannant un QR code, ce qui évite toute saisie manuelle. Le paquet qrencode génère ce code directement dans le terminal.

# Installer le generateur de QR code
sudo apt install qrencode -y

# Generer la paire du telephone (client2 = 10.8.0.3)
cd /etc/wireguard
wg genkey | tee client2_private.key | wg pubkey > client2_public.key

# Creer client2.conf (adapter l'adresse a 10.8.0.3)
# ... meme structure qu'a l'etape 8 ...

# Afficher le QR code a scanner depuis l'app WireGuard mobile
qrencode -t ansiutf8 < client2.conf

Un damier de caractères s’affiche dans votre terminal. Ouvrez l’application WireGuard sur le téléphone, choisissez « Ajouter un tunnel », puis « Scanner un QR code », et pointez l’appareil vers l’écran. La configuration s’importe en une seconde, clés comprises. N’oubliez pas d’ajouter ensuite le bloc [Peer] correspondant sur le serveur (avec AllowedIPs = 10.8.0.3/32) et de recharger avec wg syncconf, sinon le téléphone n’établira aucun handshake.

Veillez à ne jamais réutiliser la même paire de clés pour deux appareils. Chaque pair doit être unique, faute de quoi WireGuard mélange les routes et la connexion devient instable. Documentez vos attributions d’adresses dans un simple fichier texte pour ne pas perdre le fil quand votre flotte d’appareils grandit.

Comprendre AllowedIPs et le cryptokey routing

Si un seul concept mérite d’être maîtrisé dans WireGuard, c’est AllowedIPs. Contrairement à ce que son nom suggère, il ne s’agit pas d’une simple liste de contrôle d’accès. C’est le pivot du « cryptokey routing », l’idée fondatrice de WireGuard qui associe chaque clé publique à un ensemble d’adresses IP. Cette directive joue deux rôles selon le sens du trafic.

En réception, AllowedIPs agit comme un filtre : un paquet chiffré arrivant d’un pair n’est accepté que si son adresse source figure dans les AllowedIPs déclarés pour ce pair. Cela empêche un client d’usurper l’adresse d’un autre. En émission, la directive fonctionne comme une table de routage : pour envoyer un paquet vers une adresse donnée, WireGuard cherche le pair dont les AllowedIPs contiennent cette adresse, puis chiffre le paquet avec la clé de ce pair. C’est pourquoi côté client on écrit 0.0.0.0/0 (tout passe par le serveur) et côté serveur on écrit 10.8.0.2/32 (seul ce client précis est routé via ce pair).

Cette élégance a une conséquence pratique : il ne peut y avoir de chevauchement ambigu. Si deux pairs revendiquaient la même plage en émission, WireGuard ne saurait pas où router. D’où la règle d’or : côté serveur, chaque client reçoit une adresse unique en /32 (ou /128 en IPv6). Si vous voulez router tout un réseau distant à travers un client (par exemple un site d’entreprise), vous élargissez ses AllowedIPs à ce réseau, et vous obtenez un VPN site à site sans configuration supplémentaire. Cette même logique de correspondance clé-identité sous-tend les signatures numériques, où une clé publique atteste sans ambiguïté de l’origine d’un message.

Réglages avancés : MTU, kill switch et keepalive

Trois réglages font la différence entre un VPN qui marche et un VPN qui marche bien. Le premier est le MTU. WireGuard ajoute environ 60 octets d’en-tête à chaque paquet (80 en IPv6). Si le MTU est trop élevé, les paquets sont fragmentés ou perdus, ce qui se traduit par des connexions qui « bloquent » sur certains sites alors que le ping fonctionne. La valeur 1420 convient à la plupart des liaisons Internet ; sur des réseaux à MTU réduit (certaines connexions PPPoE, réseaux mobiles), descendez à 1380 voire 1280.

# Forcer un MTU dans la section [Interface] du client
[Interface]
MTU = 1380

# Diagnostiquer le bon MTU avec ping (option -M do, paquets non fragmentables)
ping -M do -s 1372 -c 2 1.1.1.1

Le deuxième réglage est PersistentKeepalive. Quand un client est derrière un routeur NAT (cas de tout réseau domestique), la table de traduction du routeur oublie le tunnel après quelques dizaines de secondes d’inactivité, et le serveur ne peut plus joindre le client. En envoyant un petit paquet chiffré toutes les 25 secondes, PersistentKeepalive = 25 maintient le « trou » ouvert dans le NAT. Réglez-le côté client pour les configurations road warrior ; il est inutile côté serveur, qui a une IP publique fixe.

Le troisième est le kill switch, qui coupe tout trafic si le tunnel tombe, évitant que votre IP réelle ne fuie pendant une micro-coupure. wg-quick peut l’implémenter via des règles de pare-feu dans PostUp/PreDown, ou plus simplement en posant 0.0.0.0/0 dans AllowedIPs avec la table de routage automatique, qui installe une règle suppress_prefixlength. Sur les applications de bureau Windows et macOS, une case « Block untunneled traffic (kill-switch) » active cette protection en un clic dès que AllowedIPs couvre tout le trafic.

5 pièges courants à éviter

Ces erreurs reviennent dans la quasi-totalité des demandes d’aide en ligne. Les connaître à l’avance vous épargnera des heures de frustration.

Oublier d’activer le forwarding IP. Sans net.ipv4.ip_forward=1 (étape 4), le handshake réussit, le ping vers 10.8.0.1 fonctionne, mais aucun trafic Internet ne passe. Symptôme typique d’un débutant qui croit le tunnel cassé alors qu’il manque une seule ligne sysctl.
Mauvais nom d’interface dans la règle MASQUERADE. Copier-coller eth0 alors que votre interface s’appelle ens3 rend le NAT silencieusement inopérant. Vérifiez toujours avec ip route list default.
Confondre clé privée et clé publique. Mettre la clé publique du serveur dans le champ PrivateKey du serveur (ou inversement) empêche tout handshake. Les clés se ressemblent, soyez méticuleux.
AllowedIPs trop large côté serveur. Mettre 0.0.0.0/0 dans le bloc [Peer] du serveur fait croire au serveur que tout l’Internet passe par ce client, ce qui casse le routage des autres pairs. Côté serveur, restez en /32.
Ne pas recharger après modification. Éditer wg0.conf sans lancer wg syncconf ou redémarrer le service : vos changements restent lettre morte. C’est la cause numéro un des « j’ai ajouté le client mais il ne se connecte pas ».

Dépannage : 8 problèmes fréquents et leurs solutions

Quand quelque chose ne fonctionne pas, procédez du bas vers le haut : d’abord le handshake, puis le ping interne, puis le trafic Internet, enfin le DNS. Le tableau ci-dessous couvre les pannes les plus répandues avec une cause probable et une action corrective immédiate.

Symptôme	Cause probable	Solution
Aucun « latest handshake »	Port UDP 51820 bloqué	Ouvrir 51820/udp sur le pare-feu serveur et chez l’hébergeur
Handshake puis silence	Forwarding IP désactivé	Vérifier `sysctl net.ipv4.ip_forward` (doit valoir 1)
Ping 10.8.0.1 OK, pas d’Internet	Règle MASQUERADE absente ou mauvaise interface	Corriger le nom d’interface dans PostUp, recharger
Connexion qui « bloque »	MTU trop élevé	Passer MTU à 1380 ou 1280 côté client
Fuite DNS détectée	resolv.conf non réécrit	Installer `openresolv`, vérifier la directive DNS
Déconnexions sur mobile	NAT qui expire	Ajouter `PersistentKeepalive = 25` côté client
« Address already in use »	Tunnel déjà monté	`wg-quick down wg0` avant de relancer
Handshake intermittent	Endpoint ou IP dynamique change	Utiliser un nom DNS dynamique pour l’endpoint

Pour diagnostiquer plus finement, deux outils sont vos alliés. Le premier est sudo wg show, qui révèle l’heure du dernier handshake et les octets transférés par pair. Le second est tcpdump sur le port WireGuard, qui confirme si les paquets atteignent même le serveur.

# Voir si des paquets WireGuard arrivent sur le serveur
sudo tcpdump -n -i eth0 udp port 51820
# 14:31:02.118 IP 198.51.100.7.51820 > 203.0.113.42.51820: UDP, length 148

# Suivre les journaux du noyau pour les erreurs WireGuard
sudo dmesg | grep -i wireguard

Si tcpdump ne montre aucun paquet entrant alors que le client tente de se connecter, le problème est en amont du serveur : pare-feu de l’hébergeur, NAT du fournisseur, ou endpoint erroné. Si les paquets arrivent mais qu’aucun handshake ne se forme, suspectez une clé incorrecte ou une clé pré-partagée présente d’un seul côté.

Conseils d’experts et bonnes pratiques de sécurité

Un VPN auto-hébergé concentre énormément de confiance : il voit passer tout votre trafic. Jason Donenfeld, le créateur de WireGuard, a conçu le protocole autour d’un principe affiché sur le site du projet, être aussi simple à configurer et déployer qu’SSH. Cette simplicité ne dispense pas de rigueur. Quelques pratiques élèvent nettement votre niveau de sécurité.

Activez les clés pré-partagées (PresharedKey) entre chaque paire de pairs. Générées avec wg genpsk, elles ajoutent une couche de chiffrement symétrique qui protège préventivement contre un futur ordinateur quantique capable de casser Curve25519. C’est gratuit et recommandé par le projet pour les déploiements sensibles.
Faites tourner vos clés. Si un appareil est perdu ou volé, retirez immédiatement son bloc [Peer] du serveur et rechargez. Comme chaque appareil a sa propre clé, révoquer un client n’affecte pas les autres.
Limitez la surface d’attaque du serveur. N’exposez que le port 22 (SSH, idéalement par clé) et 51820 (WireGuard). Fermez tout le reste. Activez les mises à jour de sécurité automatiques avec unattended-upgrades.
Surveillez les connexions. Un simple script qui consigne la sortie de wg show dans un journal vous alerte sur les handshakes inattendus.
Sauvegardez vos configurations hors du serveur, dans un gestionnaire de secrets chiffré. Perdre wg0.conf signifie reconfigurer tous vos clients.

Enfin, posez-vous la question du modèle de menace. Un VPN auto-hébergé sur un VPS commercial cache votre trafic à votre fournisseur d’accès et aux réseaux publics, mais votre hébergeur, lui, voit votre IP de sortie. Pour l’anonymat fort, des fournisseurs sans journaux audités comme Mullvad ou l’usage de Tor répondent à des besoins différents. WireGuard auto-hébergé excelle pour la confidentialité du transport et l’accès distant sécurisé, pas pour l’anonymat absolu. Choisissez l’outil adapté à votre objectif réel.

Foire aux questions sur WireGuard

WireGuard est-il vraiment plus rapide qu’OpenVPN ?

Oui, dans la quasi-totalité des tests publiés. Parce qu’il s’exécute dans le noyau et utilise ChaCha20-Poly1305, WireGuard évite les coûteux changements de contexte d’OpenVPN. Les tests Protectli montrent 2,18 à 4,15 Gbit/s pour WireGuard contre 0,82 à 1,09 Gbit/s pour OpenVPN sur le même matériel. L’écart se creuse sur les processeurs sans accélération AES matérielle, car ChaCha20 reste rapide en logiciel pur.

WireGuard protège-t-il mon anonymat ?

WireGuard chiffre votre trafic et masque votre IP réelle aux yeux des sites visités et de votre fournisseur d’accès. Mais il n’anonymise pas : votre hébergeur VPS voit l’IP de sortie, et WireGuard conserve par défaut la dernière adresse IP de chaque pair en mémoire, ce qui a soulevé des débats sur la vie privée. Pour de l’anonymat fort, Tor ou un fournisseur sans journaux audité répondent mieux au besoin.

Puis-je utiliser WireGuard sur plusieurs appareils à la fois ?

Oui, sans limite pratique. Chaque appareil reçoit sa propre paire de clés et sa propre adresse dans le tunnel (10.8.0.2, 10.8.0.3, etc.), puis un bloc [Peer] dédié sur le serveur. Ne réutilisez jamais la même clé pour deux appareils, sous peine d’instabilité. Un VPS modeste gère sans peine des dizaines de clients simultanés.

WireGuard est-il résistant à l’informatique quantique ?

Pas nativement : Curve25519 serait cassable par un ordinateur quantique suffisamment puissant, qui n’existe pas encore. WireGuard prévoit toutefois la directive PresharedKey, une clé symétrique partagée qui rend le tunnel résistant aux attaques quantiques tant qu’elle reste secrète. Pour les déploiements sensibles en 2026, activez-la systématiquement.

Quel port et quel protocole WireGuard utilise-t-il ?

WireGuard utilise exclusivement UDP, sur le port 51820 par défaut, que vous pouvez changer via ListenPort. Il n’existe aucun mode TCP, ce qui maximise les performances mais peut poser problème sur les réseaux bloquant l’UDP. Dans ce cas, encapsulez WireGuard dans un tunnel TCP avec des outils comme udp2raw ou wstunnel.

Comment supprimer proprement un client ?

Retirez le bloc [Peer] correspondant dans /etc/wireguard/wg0.conf sur le serveur, puis rechargez avec sudo wg syncconf wg0 <(wg-quick strip wg0). Le client est immédiatement révoqué et ne peut plus établir de handshake. Comme chaque appareil possède une clé distincte, cette révocation n’affecte aucun autre client.

WireGuard fonctionne-t-il derrière un routeur domestique en NAT ?

Côté client, oui, sans configuration spéciale : ajoutez simplement PersistentKeepalive = 25 pour maintenir le NAT ouvert. Côté serveur, il faut une IP publique joignable, ou une redirection du port 51820/UDP sur votre routeur si vous hébergez chez vous. Un serveur derrière un NAT sans redirection ne recevra aucune connexion entrante.

Combien coûte un VPN WireGuard auto-hébergé ?

Le seul coût est celui du serveur. Un VPS à 1 vCPU et 1 Go de RAM, suffisant pour saturer une connexion fibre domestique, se loue de 4 à 6 € par mois chez les hébergeurs européens. WireGuard lui-même est gratuit et open source sous licence GPLv2. C’est nettement moins cher qu’un abonnement VPN commercial sur le long terme, avec un contrôle total sur vos données.

Pour aller plus loin

Sources et références externes : WireGuard.com (projet officiel), livre blanc technique de WireGuard (PDF), guide de démarrage rapide officiel, manuel wg-quick(8), Mullvad : pourquoi WireGuard.

VPN WireGuard sur Linux : 12 étapes, 30 min [2026]