- WireGuard VPN : acces distant securise Linux

WireGuard vs OpenVPN : pourquoi le moderne gagne

Pendant deux decennies, OpenVPN a ete le standard de facto des VPN. Robuste, mature et largement supporte, il a equipe la majorite des deploiements VPN d'entreprise. Mais sa complexite et ses performances mediocres en ont fait une cible reguliere de critiques. WireGuard, integre au kernel Linux mainline depuis 2020 (version 5.6), apporte une approche radicalement differente : moins de code, plus de performance, une cryptographie moderne et figee.

Le code source de WireGuard tient en moins de 4000 lignes. C'est moins que la moitie d'une bibliotheque crypto standard et infiniment moins que les centaines de milliers de lignes d'OpenVPN ou IPsec. Cette simplicite radicale facilite l'audit de securite et reduit la surface d'attaque. Aucune negociation de chiffrement : tous les peers utilisent les memes algorithmes (Curve25519, ChaCha20, Poly1305, BLAKE2s), et c'est non negociable.

Comparaison directe

Cas d'usage typiques

• Acces admin distant : connexion securisee a vos serveurs depuis n'importe ou.
• Bridge entre LANs : relier deux reseaux prives (siege et succursale).
• Acces aux services internes : base de donnees, monitoring, intranet sans exposition publique.
• Site-to-site : hub-and-spoke entre datacenter et plusieurs filiales.
• VPN personnel : chiffrer le trafic sur des reseaux WiFi publics.

Installation sur Debian et Ubuntu

Sur Debian 12 (Bookworm) et Ubuntu 22.04+, WireGuard est inclus dans le kernel mainline. L'installation se limite aux outils userland (commande wg et helper wg-quick).

Installation des paquets

# Met a jour les depots
sudo apt update

# Installe les outils WireGuard et resolvconf (gestion DNS)
# wireguard-tools : commande wg, wg-quick, wg-genkey
# resolvconf : permet a wg-quick de configurer les DNS sur le client
sudo apt install wireguard-tools resolvconf -y

# Verifie que le module noyau se charge correctement
sudo modprobe wireguard
lsmod | grep wireguard

# Affiche la version installee (4.0+ recommandee)
wg --version

Sur les anciennes versions (Debian 10, Ubuntu 18.04)

# Pour Debian 10 (Buster), activez les backports
echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee /etc/apt/sources.list.d/buster-backports.list
sudo apt update
sudo apt install -t buster-backports wireguard wireguard-tools -y

# Pour Ubuntu 18.04 / 20.04, ajoutez le PPA officiel
sudo add-apt-repository ppa:wireguard/wireguard
sudo apt update
sudo apt install wireguard wireguard-tools -y

Activer l'IP forwarding sur le serveur

Pour qu'un peer client puisse acceder au LAN ou au reseau Internet via le serveur WireGuard, l'IP forwarding doit etre actif.

# Active l'IP forwarding immediatement (volatil, perdu au reboot)
sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1

# Active l'IP forwarding de maniere permanente
sudo nano /etc/sysctl.d/99-wireguard.conf

# Contenu a ajouter
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

# Applique la configuration
sudo sysctl --system

# Verifie le parametre
sysctl net.ipv4.ip_forward
# Sortie attendue : net.ipv4.ip_forward = 1

Generation des cles et configuration serveur

WireGuard utilise une paire de cles asymetriques par peer (serveur et chaque client). Le serveur conserve sa cle privee et connait les cles publiques de tous ses peers. Chaque client connait sa cle privee et la cle publique du serveur. C'est aussi simple que ca : pas de certificats, pas d'autorite de certification.

Generer la paire de cles serveur

# Cree le dossier de configuration WireGuard
sudo mkdir -p /etc/wireguard
sudo chmod 700 /etc/wireguard
cd /etc/wireguard

# Genere la cle privee du serveur (256 bits) avec permissions strictes
# umask 077 : les fichiers crees seront en 600 (lisibles par root uniquement)
umask 077

# Genere une paire de cles
# wg genkey : genere une cle privee aleatoire base64
# wg pubkey : derive la cle publique correspondante
sudo wg genkey | sudo tee server_private.key | sudo wg pubkey | sudo tee server_public.key

# Affiche les cles generees (a copier pour la config)
sudo cat server_private.key
sudo cat server_public.key

Generer une cle pre-partagee (PSK) optionnelle

La cle pre-partagee ajoute une couche de securite post-quantique : meme si la cryptographie Curve25519 etait cassee dans le futur, le PSK reste secret.

# Genere une cle pre-partagee unique pour ce peer
sudo wg genpsk | sudo tee /etc/wireguard/preshared_key

Configuration serveur complete (/etc/wireguard/wg0.conf)

# ========================================================
# /etc/wireguard/wg0.conf — Configuration serveur WireGuard
# ========================================================

[Interface]
# Adresse IP de l'interface VPN (subnet prive : 10.10.0.0/24)
# Le serveur prend .1, les clients prendront .2, .3, .4, etc.
Address = 10.10.0.1/24

# Port UDP d'ecoute (51820 = port officiel WireGuard)
# Modifiez si vous voulez masquer le service
ListenPort = 51820

# Cle privee du serveur (contenu de server_private.key)
PrivateKey = SERVEUR_PRIVATE_KEY_ICI

# Active iptables a la creation de l'interface
# eth0 = interface reseau publique du serveur (verifiez avec ip a)
PostUp   = iptables -A FORWARD -i %i -j ACCEPT
PostUp   = iptables -A FORWARD -o %i -j ACCEPT
PostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Nettoie les regles iptables a la suppression de l'interface
PostDown = iptables -D FORWARD -i %i -j ACCEPT
PostDown = iptables -D FORWARD -o %i -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# Garde les peers eveilles meme derriere un NAT (toutes les 25 secondes)
# A regler dans la section Peer si on veut un comportement par client
# PersistentKeepalive = 25

# -------- Peers (clients) --------

[Peer]
# Cle publique du client laptop-mezgani
PublicKey = CLE_PUBLIQUE_CLIENT_LAPTOP

# Cle pre-partagee optionnelle (recommandee pour la securite quantique)
PresharedKey = PSK_CLIENT_LAPTOP

# IP que le client utilisera dans le tunnel
AllowedIPs = 10.10.0.2/32

[Peer]
# Cle publique du client mobile (telephone)
PublicKey = CLE_PUBLIQUE_CLIENT_MOBILE

# IP attribuee au mobile
AllowedIPs = 10.10.0.3/32

Demarrer le serveur

# Demarre l'interface wg0 (lit /etc/wireguard/wg0.conf)
sudo wg-quick up wg0

# Sortie attendue
# [#] ip link add wg0 type wireguard
# [#] wg setconf wg0 /dev/fd/63
# [#] ip -4 address add 10.10.0.1/24 dev wg0
# [#] ip link set mtu 1420 up dev wg0
# [#] iptables -A FORWARD -i wg0 -j ACCEPT
# [#] iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Verifie l'etat de l'interface
sudo wg show

# Sortie attendue
# interface: wg0
#   public key: ABCDEF...
#   private key: (hidden)
#   listening port: 51820

# Affiche l'IP de l'interface
ip a show wg0

Configuration des peers : Linux, Windows, mobile

Chaque client genere sa propre paire de cles (privee gardee localement, publique transmise au serveur). La configuration client ressemble a celle du serveur, avec une section [Peer] qui pointe vers le serveur.

Client Linux (laptop)

# Sur le client Linux, installez wireguard-tools
sudo apt install wireguard-tools resolvconf -y

# Genere la paire de cles client
cd /etc/wireguard
sudo umask 077
sudo wg genkey | sudo tee client_private.key | sudo wg pubkey | sudo tee client_public.key

# Affiche la cle publique a copier sur le serveur
sudo cat client_public.key

# /etc/wireguard/wg0.conf — Configuration client laptop

[Interface]
# IP allouee par le serveur a ce client (cf section [Peer] cote serveur)
Address = 10.10.0.2/24

# Cle privee de ce client (contenu de client_private.key)
PrivateKey = CLIENT_PRIVATE_KEY_ICI

# DNS a utiliser quand le tunnel est actif (DNS interne ou public selon besoin)
DNS = 1.1.1.1

[Peer]
# Cle publique du serveur WireGuard (donnee par l'admin)
PublicKey = SERVEUR_PUBLIC_KEY_ICI

# Cle pre-partagee optionnelle (doit correspondre a celle du serveur)
PresharedKey = PSK_CLIENT_LAPTOP

# Adresse publique du serveur et son port d'ecoute
Endpoint = vpn.exemple.com:51820

# Reseaux a router via le VPN
# 10.10.0.0/24 : LAN du serveur uniquement (split-tunneling)
# 0.0.0.0/0    : tout le trafic Internet (full-tunnel)
AllowedIPs = 10.10.0.0/24, 192.168.1.0/24

# Maintient la connexion active derriere un NAT (envoie un paquet keepalive)
PersistentKeepalive = 25

Demarrer et tester depuis le client

# Demarre le tunnel
sudo wg-quick up wg0

# Verifie la connexion
sudo wg show

# Doit afficher
# peer: SERVEUR_PUBLIC_KEY
#   endpoint: vpn.exemple.com:51820
#   allowed ips: 10.10.0.0/24, 192.168.1.0/24
#   latest handshake: 5 seconds ago
#   transfer: 1.23 KiB received, 2.45 KiB sent

# Test de connectivite : ping le serveur via son IP VPN
ping 10.10.0.1

# Test acces a un service interne (ex: base de donnees sur 192.168.1.50)
curl http://192.168.1.50:5432

Client mobile : QR code

Pour Android et iOS, l'application officielle WireGuard accepte l'import par QR code. Generez la configuration mobile sur le serveur (jamais sur un poste public).

# Sur le serveur ou un poste de confiance, genere les cles du peer mobile
umask 077
wg genkey | tee mobile_private.key | wg pubkey > mobile_public.key

# Cree le fichier de configuration client mobile
cat > /tmp/mobile.conf < Scanner

Client Windows

Telechargez l'installeur officiel sur wireguard.com/install/. L'application Windows propose un editeur de tunnel qui accepte le meme format .conf. Importez le fichier ou collez le contenu directement.

Routage avance : split-tunneling vs full-tunnel

Le parametre AllowedIPs dans la configuration client controle quel trafic transite par le VPN. Il s'agit d'un jeu de prefixes IP : tout paquet vers une de ces destinations est encapsule dans le tunnel WireGuard. Tout le reste sort par l'interface reseau classique.

Mode split-tunneling (le plus courant)

# Configuration client : seul le LAN serveur passe par le VPN
[Peer]
# ...
# Le client peut joindre 10.10.0.x (autres clients VPN) et 192.168.1.x (LAN serveur)
# Tout autre trafic (Google, Facebook, etc.) sort par la connexion locale du client
AllowedIPs = 10.10.0.0/24, 192.168.1.0/24

Avantages :

• Performance maximale : le serveur VPN ne voit que le trafic vers le LAN.
• Bande passante reduite : pas de surcharge inutile.
• Confidentialite : le trafic personnel ne transite pas par le serveur d'entreprise.

Mode full-tunnel

# Configuration client : TOUT le trafic Internet passe par le VPN
[Peer]
# ...
# 0.0.0.0/0 capture tout le trafic IPv4
# ::/0 capture tout le trafic IPv6 (a ajouter pour vraie completude)
AllowedIPs = 0.0.0.0/0, ::/0

Cas d'usage :

• WiFi public (cafe, aeroport) : chiffre la totalite du trafic contre l'ecoute reseau.
• Contournement de censure : sortie Internet apparente depuis l'IP du serveur.
• Conformite reglementaire : obliger le trafic d'employes a passer par les pare-feu de l'entreprise.

NAT et MASQUERADE pour le full-tunnel

Pour que le full-tunnel fonctionne, le serveur doit faire du NAT pour les paquets sortants. La regle iptables MASQUERADE dans le PostUp du serveur s'en charge :

# Sur le serveur, verification que MASQUERADE est applique
sudo iptables -t nat -L POSTROUTING -n -v

# Sortie attendue
# Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
#  pkts bytes target     prot opt in     out     source               destination
#  1234 56789 MASQUERADE all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

# Si l'interface publique du serveur n'est pas eth0, adaptez la regle
# Identifier l'interface publique
ip route get 8.8.8.8
# default via 1.2.3.4 dev ens3 src 1.2.3.5

Routage DNS dans le tunnel

En full-tunnel, vous voulez generalement que les requetes DNS passent aussi par le VPN pour eviter les leaks DNS. Le parametre DNS dans la section [Interface] du client le configure automatiquement.

# Force le client a utiliser un DNS specifique pendant la session VPN
# 1.1.1.1 / 1.0.0.1 : Cloudflare (rapide, respecte la vie privee)
# 9.9.9.9 : Quad9 (filtre les domaines malveillants)
DNS = 1.1.1.1, 9.9.9.9

# Pour utiliser un DNS interne du LAN (ex: pour resoudre intranet.local)
DNS = 192.168.1.10

Pare-feu et exposition reseau

Le port UDP de WireGuard (51820 par defaut) doit etre accessible depuis Internet pour que les clients puissent se connecter. Toutes les autres protections du serveur restent valables : SSH securise, fail2ban, etc.

UFW : autoriser le port WireGuard

# Ouvre le port UDP 51820 (WireGuard)
sudo ufw allow 51820/udp

# Verifie l'etat actif
sudo ufw status verbose

# Sortie attendue
# 22/tcp                     ALLOW IN    Anywhere
# 51820/udp                  ALLOW IN    Anywhere

Variante : restreindre les IPs sources autorisees

# Si vos clients ont des IPs fixes connues, restreignez l'acces
# Cette commande remplace la regle precedente "ALLOW Anywhere"
sudo ufw delete allow 51820/udp

# Autorise UDP 51820 seulement depuis des plages IP connues
sudo ufw allow from 78.123.45.67 to any port 51820 proto udp comment "Maison admin"
sudo ufw allow from 203.0.113.0/24 to any port 51820 proto udp comment "Bureau"

nftables : configuration moderne

Sur les systemes recents, nftables est le successeur de iptables. WireGuard fonctionne avec les deux. Pour un serveur deja sous nftables, ajoutez les regles dans votre table principale.

# Edite la configuration nftables
sudo nano /etc/nftables.conf

# Extrait pour autoriser WireGuard dans nftables
table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;

        # Accepter loopback
        iif lo accept

        # Accepter le trafic etabli
        ct state established,related accept

        # SSH
        tcp dport 22 accept

        # WireGuard (UDP 51820)
        udp dport 51820 accept

        # Trafic dans le tunnel WireGuard (interface wg0)
        iifname "wg0" accept
    }

    chain forward {
        type filter hook forward priority filter; policy drop;

        # Accepter le forwarding pour les paquets WireGuard
        iifname "wg0" accept
        oifname "wg0" accept
    }
}

# Table NAT pour le MASQUERADE
table ip nat {
    chain postrouting {
        type nat hook postrouting priority srcnat;

        # MASQUERADE pour les paquets sortants venant de wg0
        # eth0 = interface publique
        iifname "wg0" oifname "eth0" masquerade
    }
}

Demarrage automatique systemd et debug

Pour que WireGuard soit actif en permanence et redemarre apres un reboot serveur, utilisez l'unit systemd wg-quick@. Cette unit prend en argument le nom de l'interface (apres l'arobase) et lit la config dans /etc/wireguard/[NOM].conf.

Activer le demarrage automatique

# Active wg-quick@wg0 au boot et le demarre immediatement
sudo systemctl enable --now wg-quick@wg0

# Verifie l'etat du service
sudo systemctl status wg-quick@wg0

# Sortie attendue
# wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
#      Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled)
#      Active: active (exited) since...
#     Process: ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)

# Pour redemarrer le tunnel (utile apres modification de wg0.conf)
sudo systemctl restart wg-quick@wg0

# Pour arreter sans desactiver le boot automatique
sudo systemctl stop wg-quick@wg0

# Pour desactiver le demarrage automatique
sudo systemctl disable wg-quick@wg0

Mise a jour dynamique de la config

Modifier wg0.conf et redemarrer le service interromp temporairement les sessions actives. Pour une mise a jour douce sans interruption, utilisez wg syncconf.

# Recharge la config sans interrompre les sessions etablies
# Operation atomique : applique seulement les diff entre l'ancienne et la nouvelle config
wg syncconf wg0 <(wg-quick strip wg0)

# Equivalent en une commande
sudo bash -c "wg syncconf wg0 <(wg-quick strip wg0)"

Diagnostic et logs

# Affiche l'etat detaille de toutes les interfaces WireGuard
sudo wg show

# Affiche un peer specifique
sudo wg show wg0 endpoints

# Logs systemd de wg-quick
sudo journalctl -u wg-quick@wg0 -n 50

# Suit les logs en temps reel
sudo journalctl -u wg-quick@wg0 -f

# Active les logs detailles dans le kernel pour debug WireGuard
echo 'module wireguard +p' | sudo tee /sys/kernel/debug/dynamic_debug/control

# Suit les logs kernel WireGuard
sudo dmesg -w | grep -i wireguard

# Desactive les logs detailles apres debug
echo 'module wireguard -p' | sudo tee /sys/kernel/debug/dynamic_debug/control

Tests de connectivite

# Verifie que le port 51820 ecoute en UDP
sudo ss -ulnp | grep 51820

# Verifie que les paquets passent dans wg0
sudo tcpdump -i wg0 -n

# Test ping depuis le client vers le serveur via le tunnel
ping 10.10.0.1

# Test depuis le serveur vers un client
ping 10.10.0.2

# Test debit dans le tunnel (avec iperf3)
# Sur le serveur : iperf3 -s
# Sur le client  : iperf3 -c 10.10.0.1