Configurer un VPN sur ton VPS avec WireGuard

Ce qui suit s'adresse à quelqu'un qui a déjà un accès root à un VPS Linux, qui sait éditer un fichier avec `nano` ou `vim`, et qui veut un tunnel fonctionnel plutôt qu'une usine à gaz. On travaille sur Ubuntu 22.04 LTS ou Debian 12, avec WireGuard 1.0.20210914 ou plus récent.

Ce qu'il te faut avant de commencer

Un VPS avec un noyau Linux 5.6 minimum. En dessous, WireGuard fonctionne encore mais en userspace via `wireguard-go`, avec une pénalité de performance qui annule une bonne partie de l'intérêt.

Un accès root ou un utilisateur avec `sudo`. Toutes les commandes ci-dessous supposent `sudo`.

Un client : une machine Linux, un téléphone Android ou iOS, ou un routeur. Le client a aussi besoin du paquet WireGuard installé. Sur Android et iOS, l'application officielle suffit.

Connaître l'adresse IP publique de ton VPS et le nom de ton interface réseau principale. Sur la plupart des hébergeurs, c'est `eth0`. Sur d'autres, `ens3` ou `enp1s0`. Vérifie avec `ip route` avant d'écrire une règle de firewall.

Étape 1 — Installer WireGuard

Sur Ubuntu 22.04 et Debian 12, WireGuard est dans les dépôts officiels. Pas besoin d'ajouter un PPA, ce qui est une bonne nouvelle : moins de sources tierces, moins de surprises lors des mises à jour.

```bash sudo apt update sudo apt install -y wireguard wireguard-tools ```

Le paquet `wireguard` installe le module noyau. Le paquet `wireguard-tools` fournit `wg` et `wg-quick`, les deux commandes que tu vas utiliser tout le reste de l'article.

Vérifie que le module est chargé :

```bash sudo modprobe wireguard lsmod | grep wireguard ```

Si `lsmod` ne renvoie rien, ton noyau est trop ancien ou le module n'est pas compilé. Dans ce cas, tu peux forcer le mode userspace, mais attends-toi à perdre 30 à 50 % de débit selon la charge.

Étape 2 — Générer les clés du serveur

WireGuard n'utilise pas de certificats. Il utilise des paires de clés Curve25519, une privée et une publique. C'est plus simple qu'OpenVPN et c'est aussi plus rapide à vérifier côté noyau.

Crée le répertoire de configuration avec les bonnes permissions. C'est un détail que beaucoup de tutoriels sautent, et c'est une erreur : une clé privée lisible par tous les utilisateurs du système ne sert à rien.

```bash sudo mkdir -p /etc/wireguard sudo chmod 700 /etc/wireguard cd /etc/wireguard

umask 077 wg genkey | sudo tee server_private.key | wg pubkey | sudo tee server_public.key ```

Le `umask 077` garantit que les fichiers créés ne sont lisibles que par root. Sans lui, `wg genkey` écrit avec les permissions par défaut, souvent `0644`, ce qui laisse ta clé privée en lecture pour tout le monde.

Note la clé publique du serveur, tu en auras besoin sur le client :

```bash sudo cat /etc/wireguard/server_public.key ```

Étape 3 — Activer le forwarding IP

Un VPS qui fait office de sortie VPN doit relayer les paquets venant du client vers Internet. Par défaut, Linux refuse. Il faut le lui dire explicitement.

Sans cette étape, ton client se connecte, le tunnel monte, et rien ne passe. C'est le piège numéro un de WireGuard, et il ne produit aucun message d'erreur : les paquets sont simplement jetés en silence.

```bash 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 sudo sysctl -p /etc/sysctl.d/99-wireguard.conf ```

La deuxième ligne n'est utile que si tu veux aussi router l'IPv6. Si ton VPS n'a pas d'IPv6, tu peux la sauter. Garder une config plus petite, c'est une chose de moins qui peut casser.

Étape 4 — Écrire la configuration du serveur

Le fichier de config vit dans `/etc/wireguard/wg0.conf`. Le nom `wg0` est conventionnel : c'est le nom de l'interface réseau virtuelle que WireGuard va créer. Tu peux en avoir plusieurs, `wg1`, `wg2`, chacune avec son propre fichier.

Ouvre le fichier :

```bash sudo nano /etc/wireguard/wg0.conf ```

Colle ceci, en remplaçant `eth0` par le nom réel de ton interface et `` par le contenu de `server_private.key` :

```ini [Interface] Address = 10.8.0.1/24 ListenPort = 51820 PrivateKey =

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT PostUp = iptables -A FORWARD -o wg0 -j ACCEPT PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i wg0 -j ACCEPT PostDown = iptables -D FORWARD -o wg0 -j ACCEPT PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE ```

Le sous-réseau `10.8.0.0/24` est arbitraire. Évite `192.168.0.0/24` et `192.168.1.0/24` si ton réseau domestique les utilise déjà : un conflit d'adresses produira un routage imprévisible.

Les lignes `PostUp` et `PostDown` appliquent les règles NAT et firewall au démarrage et à l'arrêt de l'interface. Tu pourrais les mettre dans un script séparé, mais les garder ici a un avantage : la config est autoportante. Si tu déplaces le fichier sur une autre machine, tout suit.

```bash sudo chmod 600 /etc/wireguard/wg0.conf ```

Étape 5 — Générer les clés du client

Répète l'opération de l'étape 2, cette fois pour le client. Sur une machine Linux, c'est identique. Sur Android ou iOS, l'application génère les clés elle-même et affiche la clé publique à copier.

```bash umask 077 wg genkey | tee client_private.key | wg pubkey | tee client_public.key ```

Récupère la clé publique du client :

```bash cat client_public.key ```

Étape 6 — Déclarer le client sur le serveur

Ajoute un bloc `[Peer]` à la fin de `/etc/wireguard/wg0.conf`. Chaque client a son propre bloc, identifié par sa clé publique.

```ini [Peer] PublicKey = AllowedIPs = 10.8.0.2/32 ```

`AllowedIPs` fait deux choses à la fois, et c'est là que beaucoup de gens se perdent. Côté serveur, il dit « accepte les paquets venant de cette clé, et route vers cette adresse ». Côté client, il dit « envoie vers le tunnel tout ce qui correspond à ce préfixe ». La même clé, deux sémantiques selon le fichier.

Pour un client unique, `10.8.0.2/32` suffit. Pour plusieurs clients, incrémente : `10.8.0.3/32`, `10.8.0.4/32`, et ainsi de suite. WireGuard n'a pas de serveur DHCP. Chaque adresse est attribuée à la main, et c'est volontaire : moins de code, moins de bugs.

Étape 7 — Démarrer l'interface côté serveur

```bash sudo wg-quick up wg0 sudo systemctl enable wg-quick@wg0 ```

La première commande monte l'interface et applique les règles `PostUp`. La seconde fait en sorte que tout cela se reproduise à chaque redémarrage du VPS. Sans elle, ton VPN disparaît au premier reboot, et tu ne le remarques qu'au moment où tu en as besoin.

Étape 8 — Configurer le client

Crée un fichier `wg0.conf` sur le client. Le contenu est symétrique mais avec les rôles inversés :

```ini [Interface] Address = 10.8.0.2/32 PrivateKey = DNS = 1.1.1.1

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

`AllowedIPs = 0.0.0.0/0, ::/0` route tout le trafic du client via le VPS. Si tu veux seulement atteindre le réseau du VPS sans sortir par lui, remplace par `10.8.0.0/24`. C'est la différence entre un VPN « full tunnel » et un VPN « split tunnel », et le choix dépend de ton usage.

`PersistentKeepalive = 25` envoie un paquet toutes les 25 secondes pour maintenir la session NAT ouverte. Sans lui, un client derrière une box domestique perd la connexion après quelques minutes d'inactivité, parce que le NAT a oublié la traduction. Coût : un paquet de 32 octets toutes les 25 secondes. Négligeable.

Sur Linux, monte l'interface :

```bash sudo wg-quick up wg0 ```

Sur Android ou iOS, importe le fichier de config ou scanne le QR code généré avec `qrencode -t ansiutf8 < client.conf`.

Vérification

Trois contrôles, dans l'ordre.

Sur le serveur, l'interface est active :

```bash sudo wg show ```

Tu dois voir `interface: wg0`, la clé publique du serveur, le port d'écoute `51820`, et un bloc `peer` avec la clé publique du client. La ligne `latest handshake` doit afficher un délai récent si le client est connecté.

Sur le client, l'IP publique vue depuis Internet doit être celle du VPS :

```bash curl -4 ifconfig.me ```

Si la réponse est l'IP de ton VPS, le tunnel fonctionne. Si c'est ton IP domestique, la route par défaut n'est pas passée par `wg0` — vérifie `AllowedIPs` côté client.

Dernier test, la latence :

```bash ping -c 4 10.8.0.1 ```

Quatre réponses, moins de 5 ms si le VPS est proche. Si le ping passe mais que `curl` ne renvoie rien, le forwarding ou le NAT est en cause, pas le tunnel.

Problèmes fréquents

Le handshake n'a jamais lieu. Le port UDP 51820 est bloqué par un firewall en amont. Vérifie avec `sudo ufw status` et `sudo iptables -L -n`. Si ton hébergeur a un firewall externe (c'est le cas chez plusieurs fournisseurs), ouvre le port dans son panneau, pas seulement sur la machine.

Le tunnel monte mais aucun trafic ne sort. `net.ipv4.ip_forward` est à 0, ou la règle `MASQUERADE` pointe vers une interface qui n'existe pas. Vérifie avec `sysctl net.ipv4.ip_forward` et `ip route`. Une faute de frappe dans `eth0` produit exactement ce symptôme.

La connexion tombe après quelques minutes d'inactivité. Le NAT de la box cliente a expiré. Ajoute `PersistentKeepalive = 25` côté client. Si le problème persiste, c'est que le client est derrière un CGNAT, et là aucune configuration WireGuard ne sauvera la situation.

Un dernier point qu'aucun tutoriel ne mentionne : ta clé privée est la seule chose qui protège ton tunnel. Si elle fuite, n'importe qui peut se faire passer pour ton client. Change-la tous les six mois, ou plus souvent si tu as un doute. WireGuard ne prévoit pas de rotation automatique — c'est à toi de le faire, et personne ne te le rappellera.