Installer un serveur WireGuard sur Debian 12 / Ubuntu 24.04

1. Prérequis

Vous aurez besoin de trois choses : un VPS VPSPLEX sous Debian 12 ou Ubuntu 24.04 (le tutoriel fonctionne tel quel sur les deux), un accès root, et dix minutes devant vous. Un VPS-1 Coast à 6,99 $ suffit largement pour un usage personnel ou familial — WireGuard consomme peu de CPU et la courbe Curve25519 est traitée nativement par nos EPYC.

Un point que beaucoup de tutoriels passent sous silence : le pays de votre VPS devient votre pays de sortie. Tout le trafic de vos appareils sortira avec l'IP publique du serveur, donc avec sa juridiction. Si vous voulez une IP néerlandaise, déployez à Rotterdam ; si vous préférez sortir hors de l'Union, Panama ou la Russie sont disponibles. Le même tutoriel s'applique aux six localisations.

Note d'honnêteté : un VPN déplace la confiance, il ne la supprime pas. Votre trafic est chiffré jusqu'à votre VPS, puis il ressort en clair vers Internet depuis ce serveur. Chez VPSPLEX, nous ne gardons aucun log de session — c'est précisément pour cela que ce schéma a du sens ici.

2. Installation des paquets

Depuis le noyau 5.6 (donc depuis Debian 11 et Ubuntu 20.04), WireGuard est intégré au noyau Linux : pas de module DKMS à compiler, pas de dépendance kernel-headers. Sur Debian 12 et Ubuntu 24.04, apt install wireguard suffit.

# Mise à jour puis installation de WireGuard et qrencode (utile pour le mobile)
apt update && apt upgrade -y
apt install -y wireguard qrencode

# Vérification : le module doit être présent dans le noyau
modprobe wireguard && lsmod | grep wireguard

3. Génération des clés

WireGuard identifie les pairs par des clés publiques Curve25519 — il n'y a ni nom d'utilisateur, ni mot de passe, ni négociation. Une paire de clés par appareil : votre téléphone et votre portable sont deux pairs distincts, avec deux adresses IP distinctes sur le tunnel.

# Les clés privées ne doivent jamais être lisibles par un autre utilisateur
umask 077

# Paire serveur
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub

# Paire client n°1 (laptop)
wg genkey | tee /etc/wireguard/client1-laptop.key | wg pubkey > /etc/wireguard/client1-laptop.pub

# Paire client n°2 (téléphone)
wg genkey | tee /etc/wireguard/client2-phone.key | wg pubkey > /etc/wireguard/client2-phone.pub

# Une clé pré-partagée (PSK) par paire, optionnelle mais recommandée
wg genpsk > /etc/wireguard/client1-laptop.psk

Ajoutez une clé pré-partagée par paire : elle ajoute une couche de chiffrement symétrique indépendante des clés asymétriques, ce qui protège votre tunnel même dans l'hypothèse (très théorique) d'une faille future sur Curve25519. C'est une bonne pratique, pas un luxe paranoïaque.

4. Configuration du serveur — wg0.conf

Créez /etc/wireguard/wg0.conf. Le sous-réseau du tunnel (ici 10.10.0.0/24) ne doit pas chevaucher celui de votre réseau local ni celui des réseaux Wi-Fi que vous fréquentez — si votre box utilise déjà 192.168.1.0/24, tout est bon.

[Interface]
# Adresse du serveur SUR le tunnel (pas son IP publique)
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <contenu de /etc/wireguard/server.key>

# NAT : on autorise le forwarding tunnel →> interface publique
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

# Client n°1 : laptop
[Peer]
PublicKey = <contenu de client1-laptop.pub>
PresharedKey = <contenu de client1-laptop.psk>
AllowedIPs = 10.10.0.2/32

# Client n°2 : téléphone
[Peer]
PublicKey = <contenu de client2-phone.pub>
AllowedIPs = 10.10.0.3/32

• AllowedIPs côté serveur déclare quelles adresses sources ce pair a le droit d'utiliser. Une seule IP par appareil, en /32 : chaque appareil est routé individuellement.
• eth0 est l'interface réseau de sortie sur nos KVM. Vérifiez la vôtre avec ip route show default — sur certaines images il s'appelle ens3. Le MASQUERADE doit pointer sur la bonne interface, sinon le tunnel s'établit mais rien ne passe.
• Ne mettez pas SaveConfig = true : wg-quick réécrirait le fichier en écrasant vos commentaires et vos PSK à chaque arrêt.

5. Activation du routage (IP forwarding)

Par défaut, Linux ne fait pas suivre les paquets d'une interface à l'autre. Il faut activer le forwarding IPv4 de façon persistante, puis l'appliquer immédiatement :

echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-wireguard.conf
sysctl --system

# Vérification : doit afficher net.ipv4.ip_forward = 1
sysctl net.ipv4.ip_forward

6. Ouverture du pare-feu (UFW)

Si UFW est actif sur le serveur (c'est le cas si vous avez suivi notre guide de durcissement), il faut ouvrir l'UDP 51820. Sinon, le tunnel ne s'établira jamais et vous chercherez le problème côté WireGuard alors qu'il est côté pare-feu.

# SSH d'abord — adaptez le port si vous l'avez changé (2222 dans notre guide durcissement)
ufw allow OpenSSH
# ou : ufw allow 2222/tcp comment 'SSH'

# WireGuard — UDP uniquement, c'est le protocole natif du tunnel
ufw allow 51820/udp comment 'WireGuard'

# Politique par défaut : tout bloquer sauf ce qui est explicitement autorisé
ufw default deny incoming
ufw default allow outgoing

ufw enable
ufw status verbose

Chez VPSPLEX, aucun filtrage entrant n'est appliqué en amont de votre VPS : le port 51820/UDP est joignable dès l'ouverture côté UFW. Notre anti-DDoS protège la couche réseau sans bloquer le trafic UDP légitime vers vos ports ouverts.

7. Démarrage et service systemd

chmod 600 /etc/wireguard/wg0.conf

# Démarrage + activation au boot
systemctl enable --now wg-quick@wg0

# Contrôle d'état
systemctl status wg-quick@wg0 --no-pager
wg show

wg show doit afficher l'interface wg0, sa clé publique et la liste des pairs, avec des compteurs de transfert à zéro en attendant les premiers handshakes. Si la commande échoue, regardez journalctl -u wg-quick@wg0 -e : une clé mal copiée ou une permission trop ouverte (600 requis) en sont les causes les plus fréquentes.

8. Configuration des clients

Laptop — tunnel complet

Sur votre machine locale, créez /etc/wireguard/wg0.conf (Linux/macOS) ou importez le fichier dans l'application officielle WireGuard (Windows, macOS, iOS, Android) :

[Interface]
PrivateKey = <contenu de client1-laptop.key, généré côté serveur>
Address = 10.10.0.2/32
DNS = 1.1.1.1
MTU = 1420

[Peer]
PublicKey = <contenu de /etc/wireguard/server.pub>
PresharedKey = <contenu de client1-laptop.psk>
# Remplacez 203.0.113.10 par l'IP publique de votre VPS VPSPLEX
Endpoint = 203.0.113.10:51820
# 0.0.0.0/0 = tout le trafic passe dans le tunnel (full tunnel)
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

• PersistentKeepalive = 25 : envoie un paquet toutes les 25 secondes pour maintenir la traduction d'adresses (NAT) côté routeur local. Indispensable derrière une box 4G ou un réseau d'entreprise, inoffensif ailleurs.
• MTU = 1420 : laisse de la place à l'en-tête WireGuard (80 octets sur IPv4). Si certains sites ne répondent plus derrière le tunnel, essayez 1380 avant de chercher ailleurs.
• AllowedIPs = 0.0.0.0/0 route tout le trafic. Pour un split tunnel (seul le trafic destiné au serveur et à un réseau distant passe dans le tunnel), remplacez par AllowedIPs = 10.10.0.0/24 et vos plages spécifiques.

Téléphone — via QR code

Générez un QR code de la configuration côté serveur, puis scannez-le dans l'application WireGuard mobile. La configuration ne transite par aucun cloud tiers :

# Construit le fichier client téléphone puis l'affiche en QR
cat > /etc/wireguard/client2-phone.conf <<'EOF'
[Interface]
PrivateKey = <contenu de client2-phone.key>
Address = 10.10.0.3/32
DNS = 1.1.1.1
MTU = 1420

[Peer]
PublicKey = <contenu de server.pub>
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
EOF

qrencode -t ansiutf8 < /etc/wireguard/client2-phone.conf

Ajouter un pair sans redémarrer

Pour ajouter un appareil à chaud, injectez le pair directement dans l'interface en cours — mais écrivez-le aussi dans wg0.conf, sinon il disparaîtra au prochain redémarrage :

wg set wg0 peer $(cat /etc/wireguard/client3-tablette.pub) allowed-ips 10.10.0.4/32
wg show

9. Vérification de bout en bout

Activez le tunnel côté client, puis contrôlez chaque couche, de la plus proche à la plus lointaine :

# 1. Le tunnel est-il actif côté client ?
sudo wg show
# Un champ "latest handshake" récent (< 2 min) = le tunnel est établi

# 2. Le serveur répond-il sur l'IP du tunnel ?
ping -c 3 10.10.0.1

# 3. La sortie Internet passe-t-elle bien par le VPS ?
curl -4 ifconfig.me
# Doit afficher l'IP publique de votre VPS VPSPLEX, pas celle de votre box

# 4. Côté serveur : les compteurs de transfert augmentent-ils ?
wg show | grep -A3 "peer:"

En débit, attendez-vous à 200–600 Mbit/s sur un VPS-2 Reef ou supérieur, limité plus par le chiffrement ChaCha20 côté client que par le serveur. Sur un VPS-1 Coast, un téléphone récent satisfera tout le monde sauf les gros transferts. Enfin, testez une fuite DNS (par exemple sur dnsleaktest.com) : si vous voyez le résolveur de votre FAI au lieu de celui configuré, remplacez DNS = 1.1.1.1 par le résolveur de votre choix côté client.

10. Dépannage

Aucun handshake

• Vérifiez que le démon écoute : ss -lunp | grep 51820 doit montrer 0.0.0.0:51820.
• Le pare-feu du serveur (UFW) autorise-t-il bien l'UDP 51820 ? N'oubliez pas : ufw allow 51820/udp, pas de /tcp.
• L'Endpoint côté client pointe-t-il vers la bonne IP publique et le bon port ?
• Les clés sont-elles inversées ? La PublicKey du [Peer] côté client doit être la server.pub, et réciproquement.

Handshake OK mais aucun trafic

• sysctl net.ipv4.ip_forward doit renvoyer 1 — c'est l'oubli n°1.
• Le MASQUERADE pointe-t-il sur la bonne interface (eth0 vs ens3) ? Comparez avec ip route show default.
• Le [Peer] côté serveur a-t-il un AllowedIPs correspondant exactement à l'adresse du client (10.10.0.2/32 et pas autre chose) ?

Sites qui ne chargent pas, DNS, IPv6

• Pages qui se bloquent à mi-chargement : baissez le MTU à 1380 côté client.
• Certains sites en IPv6 inaccessibles : si votre VPS n'a pas d'IPv6, retirez ::/0 de AllowedIPs, sinon le client essaiera de sortir en IPv6 via un tunnel qui n'existe pas.
• Les journaux ne mentent jamais : journalctl -u wg-quick@wg0 -e côté serveur, sudo wg show côté client.

Questions fréquentes