WireGuard VPN : Déployez votre propre serveur sans ouvrir de trous inutiles

Vous voulez un VPN parce que votre ordinateur portable se connecte à des Wi‑Fi de cafés, des réseaux d’hôtel, et ce machin « FREE_AIRPORT_WIFI ». Vous voulez aussi héberger vous‑même parce que vous avez lu assez de rapports de violations pour savoir que « faites-nous confiance » n’est pas un modèle de sécurité.

Le piège : les gens considèrent « configurer un VPN » comme « ouvrir plein de ports et croiser les doigts ». C’est ainsi qu’on obtient un serveur joignable, oui — par des attaquants, des scanners, et par vous‑même à 3 h du matin en vous demandant pourquoi le routage est cassé. Nous allons faire les choses de la façon ennuyeuse et correcte : un port UDP exposé (ou aucun si vous utilisez une voie sortante uniquement), un pare‑feu strict, un routage explicite, et une routine de diagnostic qui ne repose pas sur l’intuition.

Posture de sécurité : « un port, une tâche »

WireGuard n’est pas un ensemble de démons et de modules. C’est un protocole léger et une implémentation simple. Traitez‑le comme un appareil à usage unique : exposez un port UDP (si nécessaire), acceptez les paquets uniquement sur ce port, depuis n’importe où, et laissez la négociation cryptographique de WireGuard faire le travail lourd.

Votre pare‑feu n’est pas là pour « rendre le VPN sécurisé ». Il est là pour vous empêcher d’exposer accidentellement tout le reste pendant que vous tentez d’être malin. Ne soyez pas malin.

À quoi ressemblent généralement les « trous inutiles »

• Ouvrir SSH vers le monde « juste pour l’instant », puis l’oublier pendant un an.
• Rediriger des ports au hasard parce qu’un article de blog l’a conseillé, alors que WireGuard n’a besoin que d’un port UDP.
• Autoriser le forwarding de l’interface VPN vers votre LAN sans politique, parce que « c’est chiffré ».
• Installer une interface web qui s’exécute en root parce que « ça simplifie la gestion ».

Le chiffrement n’est pas une permission. C’est du transport. La permission, c’est le routage et la politique.

Une citation, parce qu’elle reste vraie

« L’espoir n’est pas une stratégie. » — James Cameron

Ce n’est pas une citation d’opérations, mais elle marche : ne comptez pas sur l’espoir pour votre pare‑feu ; vérifiez‑le.

Faits et contexte WireGuard (ce que les gens oublient)

Ces points sont courts volontairement. Le but est d’ajuster votre modèle mental pour que vous arrêtiez de dépanner la mauvaise couche.

1. WireGuard utilise UDP uniquement par conception. Si vous cherchez des « relances TCP », vous dépannez la mauvaise couche.
2. Il utilise une négociation basée sur Noise (NoiseIK). C’est une des raisons pour lesquelles il est rapide et relativement simple comparé aux piles VPN plus anciennes.
3. Il est arrivé dans le noyau Linux en 5.6 (2020). Avant cela, il fonctionnait en dehors du noyau ; maintenant c’est un citoyen de première classe sur les distributions modernes.
4. « Pairs » n’est pas synonyme d’« utilisateurs ». Un pair est une paire de clés et une politique de routage ; l’identité vit dans les clés, pas dans des noms d’utilisateur.
5. AllowedIPs est à la fois routage et contrôle d’accès. Il détermine quelles routes sont installées et quel trafic est accepté pour un pair.
6. Le NAT traversal n’est pas magique ; ce sont des keepalives. PersistentKeepalive, c’est essentiellement frapper poliment à la porte toutes les N secondes pour que les pare‑feux avec état ne vous oublient pas.
7. WireGuard n’a pas de renégociation comme IPsec. Les clés tournent, mais le modèle est volontairement minimal.
8. Il évite la prolifération d’algorithmes. Les choix cryptographiques sont délibérément limités ; vous ne pouvez pas « choisir ce que vous voulez », et c’est une fonctionnalité, pas un bug.

Blague #1 : Un VPN qui « prend en charge tous les chiffrements » est comme un restaurant avec un menu de 40 pages — personne ne vérifie la fraîcheur.

Choisir votre topologie : VPS hub, hub à la maison, ou « sans ports entrants »

La façon la plus propre d’éviter des trous inutiles est de décider ce que vous essayez de connecter. Il y a trois schémas courants, et ils ne sont pas interchangeables.

Topologie A : VPS comme hub (recommandée pour la plupart)

Vous louez un petit VPS, vous exposez un port UDP (par exemple 51820/udp), et vous connectez les clients à ce VPS. Si vous voulez accéder à des appareils domestiques, vous exécutez aussi un peer WireGuard chez vous qui se connecte au VPS et annonce vos routes domestiques.

Pourquoi c’est bien :

• Vous n’avez pas besoin d’exposer votre IP domestique ni de percer un routeur ISP instable.
• Vous obtenez un point d’accès public stable et un pare‑feu prévisible.
• Vous pouvez garder SSH verrouillé sur un réseau de gestion ou un bastion.

Topologie B : Serveur à la maison comme hub (ça marche, mais vous gérez le routeur)

Vous redirigez un port UDP depuis votre routeur domestique vers votre serveur WireGuard. Ça marche quand ça marche. C’est aussi à une mise à jour du firmware de « pourquoi mon routeur a‑t‑il réinitialisé toutes mes règles ? ».

Ne faites cela que si vous comprenez le comportement du pare‑feu avec état de votre routeur domestique et que vous pouvez tolérer des pannes occasionnelles.

Topologie C : « Aucun port entrant » : uniquement sorties via un rendez‑vous

Si votre environnement interdit les ports entrants (réseaux d’entreprise, CGNAT, ISP hostiles), vous pouvez quand même construire un système fonctionnel. L’approche habituelle est :

• Un VPS public exécute le serveur WireGuard (un port UDP ouvert sur le VPS).
• Tout le reste (passerelle domestique, ordinateurs portables) se connecte en sortie vers ce VPS.

Notez ce qui se passe : vous n’avez pas éliminé l’exposition ; vous l’avez déplacée vers une machine publique contrôlée et vous avez gardé les entrées domestiques fermées. C’est généralement le bon compromis.

Décisions de durcissement qui comptent vraiment

1) Placez le point d’accès WireGuard sur un hôte minimal

Ne co‑hébergez pas votre point d’accès VPN avec votre cluster Kubernetes préféré, votre galerie de photos familiale et une application Node expérimentale. Chaque service additionnel multiplie votre rayon d’impact. Si vous avez besoin d’un couteau suisse, d’accord. Mais ne soyez pas surpris si vous vous coupez.

2) Restreignez SSH comme si vous le pensiez vraiment

SSH est habituellement le vrai « trou inutile ». Si ce serveur est accessible sur Internet, par défaut :

• Clés SSH uniquement, pas d’authentification par mot de passe.
• Filtrez SSH au pare‑feu vers une plage d’IP de confiance (bureau, domicile ou votre sous‑réseau VPN).
• Envisagez une interface de gestion séparée ou un bastion si vous opérez cela pour une équipe.

3) Politique de pare‑feu : autoriser WireGuard, autoriser établi, bloquer le reste

Le jeu de règles de base est ennuyeux et suffisant :

• Entrant : autoriser UDP 51820 (ou votre port choisi) vers l’hôte WireGuard.
• Entrant : autoriser SSH uniquement depuis une source restreinte.
• Transfert : n’autoriser que ce que vous avez l’intention d’autoriser depuis wg0 vers d’autres interfaces.

L’interface VPN n’est pas un laissez‑passer pour votre LAN. C’est un segment réseau. Traitez‑le comme tel.

4) La politique de routage est votre contrôle d’accès

WireGuard ne gère pas les « permissions utilisateur » comme un concentrateur VPN d’entreprise. Vos leviers sont :

• AllowedIPs par pair (quelles routes un pair peut envoyer et recevoir).
• Règles de pare‑feu sur wg0 (quel trafic est autorisé une fois arrivé).
• Décisions d’IP forwarding / NAT (ce que le serveur va router ensuite).

5) MTU : le tueur silencieux

WireGuard est rapide. Il est aussi prêt à faire chuter votre débit si vous encapsulez dans PPPoE, VLANs ou d’autres tunnels et que vous n’ajustez pas le MTU. En cas de doute, commencez par 1420 sur wg0 et mesurez.

6) Journalisation : assez pour diagnostiquer, pas assez pour fuir

WireGuard est volontairement discret. C’est bien. Mais vous avez quand même besoin d’observabilité au niveau système :

• Compteurs d’interface et routes.
• Compteurs de paquets du pare‑feu.
• Journaux noyau pour paquets rejetés (avec prudence).

Listes de contrôle / plan étape par étape

Checklist : avant de toucher au serveur

• Choisissez votre sous‑réseau VPN (exemple : 10.6.0.0/24). Ne réutilisez pas un sous‑réseau LAN.
• Décidez tunnel divisé vs tunnel complet par client. Par défaut, tunnel divisé sauf si vous avez besoin de « tout le trafic via le VPN ».
• Choisissez votre port d’écoute (51820/udp par défaut est bien). La sécurité par l’obscurité n’est pas une stratégie, mais réduire le bruit l’est.
• Notez quels sous‑réseaux privés vous voulez rendre accessibles (exemple : 192.168.50.0/24 chez vous).
• Décidez si le serveur doit NATer le trafic client vers Internet (tunnel complet) ou juste router vers des réseaux internes.

Étape par étape : VPS hub sur Ubuntu avec nftables

Ce flux suppose :

• Interface publique du serveur : eth0
• Interface WireGuard : wg0
• Sous‑réseau VPN : 10.6.0.0/24
• IP VPN du serveur : 10.6.0.1
• IP VPN du client : 10.6.0.2

Checklist : ce que vous devriez obtenir

• Uniquement UDP 51820 entrant exposé (plus SSH strictement restreint si nécessaire).
• wg0 up au démarrage, configuration propriétaire root, permissions verrouillées.
• IP forwarding activé seulement si vous routez réellement entre des interfaces.
• Règles de pare‑feu qui autorisent explicitement le trafic voulu, et rien d’autre.
• Configurations clients correspondant à AllowedIPs, endpoint et choix DNS.

Tâches pratiques : commandes, sorties et décisions

Cette section est volontairement pratique : commande, sortie réaliste, puis la décision que vous prenez. Si vous sautez la partie « décision », vous vous contentez de taper des incantations.

Tâche 1 : confirmer le support WireGuard et les infos OS de base

cr0x@server:~$ uname -r
6.5.0-41-generic

Ce que ça signifie : Noyau moderne ; le support in‑kernel de WireGuard est disponible.
Décision : Utiliser wireguard-tools et le module noyau ; éviter les shim utilisateurs sauf contrainte de plateforme.

Tâche 2 : installer les outils WireGuard

cr0x@server:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y wireguard wireguard-tools nftables
Reading package lists... Done
Setting up wireguard-tools (1.0.20210914-1ubuntu2) ...
Setting up wireguard (1.0.20210914-1ubuntu2) ...
Setting up nftables (1.0.2-1ubuntu1) ...

Ce que ça signifie : Les outils sont présents. Décision : Procéder avec une interface gérée par systemd et des règles nftables. Si vous êtes sur une distro qui active ufw par défaut, décidez maintenant si vous l’utilisez ou la désactivez ; mélanger des pare‑feux est un passe‑temps, pas une carrière.

Tâche 3 : générer les clés serveur avec les bonnes permissions

cr0x@server:~$ umask 077

cr0x@server:~$ sudo mkdir -p /etc/wireguard

cr0x@server:~$ sudo bash -c 'wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub'

cr0x@server:~$ sudo ls -l /etc/wireguard
total 8
-rw------- 1 root root 45 Oct 12 10:20 server.key
-rw------- 1 root root 45 Oct 12 10:20 server.pub

Ce que ça signifie : Les clés existent et ne sont pas lisibles par tous.
Décision : Si les permissions sont plus larges que 600, corrigez‑les ; ne continuez pas avec une gestion négligente des clés.

Tâche 4 : écrire la configuration de l’interface serveur

cr0x@server:~$ sudo bash -c 'cat > /etc/wireguard/wg0.conf <<EOF
[Interface]
Address = 10.6.0.1/24
ListenPort = 51820
PrivateKey = '"$(sudo cat /etc/wireguard/server.key)"'
SaveConfig = false

# If you will route to other networks, enable forwarding and add firewall rules (below).
EOF'

cr0x@server:~$ sudo chmod 600 /etc/wireguard/wg0.conf

Ce que ça signifie : Le serveur est configuré avec une adresse interne et un port UDP.
Décision : Garder SaveConfig=false sauf si vous voulez que les modifications runtime soient écrites automatiquement. L’écriture automatique est pratique jusqu’au jour où ce ne l’est plus.

Tâche 5 : activer l’interface et vérifier son existence

cr0x@server:~$ sudo systemctl enable --now wg-quick@wg0
Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service → /lib/systemd/system/wg-quick@.service.

cr0x@server:~$ ip a show wg0
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.6.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever

Ce que ça signifie : L’interface est active avec MTU 1420 (par défaut wg-quick).
Décision : Si votre environnement nécessite un autre MTU (fréquent avec PPPoE), réglez‑le explicitement maintenant plutôt que de chasser des fantômes plus tard.

Tâche 6 : confirmer que le serveur écoute sur le port UDP choisi

cr0x@server:~$ sudo ss -lunp | grep 51820
UNCONN 0      0           0.0.0.0:51820       0.0.0.0:*    users:(("wireguard",pid=1123,fd=6))

Ce que ça signifie : Une socket UDP est ouverte et liée.
Décision : S’il n’écoute pas, arrêtez et inspectez journalctl pour des échecs de wg-quick avant de toucher aux règles du pare‑feu.

Tâche 7 : configurer nftables pour autoriser uniquement ce dont vous avez besoin

cr0x@server:~$ sudo bash -c 'cat > /etc/nftables.conf <<EOF
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    ct state established,related accept
    iif "lo" accept

    # Allow WireGuard
    udp dport 51820 accept

    # Allow SSH only from a trusted source (example: your office IP)
    ip saddr 203.0.113.10 tcp dport 22 accept

    # Optional: allow ICMP for debugging (rate-limit in real environments)
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept

    counter reject with icmpx type port-unreachable
  }

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

    ct state established,related accept
    # Allow VPN clients to reach the server itself is handled in input;
    # forward is for routed traffic to other interfaces.

    # Example: allow VPN clients to reach a private LAN behind this server
    # iif "wg0" oif "eth0" ip daddr 192.168.50.0/24 accept
    # iif "eth0" oif "wg0" ip saddr 192.168.50.0/24 accept
  }

  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}
EOF'

cr0x@server:~$ sudo systemctl enable --now nftables

cr0x@server:~$ sudo nft list ruleset | sed -n '1,60p'
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		udp dport 51820 accept
		ip saddr 203.0.113.10 tcp dport 22 accept
		ip protocol icmp accept
		ip6 nexthdr icmpv6 accept
		counter reject with icmpx type port-unreachable
	}

Ce que ça signifie : Politique par défaut drop, autorisations explicites. C’est ce que vous voulez sur un hôte exposé à Internet.
Décision : Si vous ne pouvez pas restreindre SSH par IP source, envisagez fortement de mettre SSH derrière le VPN (c’est‑à‑dire : pas de SSH public du tout).

Tâche 8 : vérifier que vous n’avez pas exposé d’autres services par erreur

cr0x@server:~$ sudo ss -lntup
Netid State  Recv-Q Send-Q Local Address:Port   Peer Address:Port Process
udp   UNCONN 0      0      0.0.0.0:51820       0.0.0.0:*     users:(("wireguard",pid=1123,fd=6))
tcp   LISTEN 0      4096   0.0.0.0:22          0.0.0.0:*     users:(("sshd",pid=904,fd=3))

Ce que ça signifie : Seulement SSH et WireGuard écoutent. Bien.
Décision : Si vous voyez des écouteurs surprises (dashboards web, exporters, agents aléatoires), supprimez‑les ou pare‑feu‑lez‑les. « Mais c’est lié à 0.0.0.0 » n’est pas une caractéristique de personnalité.

Tâche 9 : générer une paire de clés client et ajouter un peer

cr0x@server:~$ wg genkey | tee /tmp/client1.key | wg pubkey > /tmp/client1.pub

cr0x@server:~$ sudo wg set wg0 peer $(cat /tmp/client1.pub) allowed-ips 10.6.0.2/32

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 3rYlF8wF1aV9rS8dK0aJ7xw5w2Vn9pYqHc0Rr3X0u2M=
  private key: (hidden)
  listening port: 51820

peer: 7bTt2yqg3fJ0zq5fQm2v0QwqYk9mM9t8Gq2dZ1gk3jA=
  allowed ips: 10.6.0.2/32

Ce que ça signifie : Le serveur connaît maintenant une clé de peer et quelle IP VPN lui appartient.
Décision : Gardez AllowedIPs serrés : /32 par client sauf si vous faites expressément du routage site‑à‑site. Des AllowedIPs larges causent des fuites de routage et des conflits de peers.

Tâche 10 : créer la configuration client (tunnel divisé par défaut)

cr0x@server:~$ SERVER_PUB=$(sudo cat /etc/wireguard/server.pub); echo "$SERVER_PUB"
3rYlF8wF1aV9rS8dK0aJ7xw5w2Vn9pYqHc0Rr3X0u2M=

cr0x@server:~$ cat > /tmp/client1.conf <<EOF
[Interface]
PrivateKey = $(cat /tmp/client1.key)
Address = 10.6.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = $(sudo cat /etc/wireguard/server.pub)
Endpoint = 198.51.100.25:51820
AllowedIPs = 10.6.0.0/24
PersistentKeepalive = 25
EOF

Ce que ça signifie : Tunnel divisé : le client ne route que le trafic du sous‑réseau VPN dans le tunnel.
Décision : Commencez par tunnel divisé. Activez le tunnel complet seulement quand vous pouvez expliquer pourquoi vous en avez besoin (et que vous avez testé le comportement DNS).

Tâche 11 : vérifier la poignée de main et les compteurs de trafic sur le serveur

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 3rYlF8wF1aV9rS8dK0aJ7xw5w2Vn9pYqHc0Rr3X0u2M=
  private key: (hidden)
  listening port: 51820

peer: 7bTt2yqg3fJ0zq5fQm2v0QwqYk9mM9t8Gq2dZ1gk3jA=
  allowed ips: 10.6.0.2/32
  latest handshake: 24 seconds ago
  transfer: 18.21 KiB received, 22.77 KiB sent

Ce que ça signifie : La poignée de main a réussi et le trafic circule.
Décision : Si « latest handshake » est vide ou ancien, dépannez la connectivité (pare‑feu, endpoint, NAT) avant de toucher aux routes.

Tâche 12 : vérifier la table de routage et la politique sur le serveur

cr0x@server:~$ ip route show
default via 203.0.113.1 dev eth0 proto dhcp src 198.51.100.25 metric 100
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1
203.0.113.0/24 dev eth0 proto kernel scope link src 198.51.100.25

Ce que ça signifie : Le serveur sait que le sous‑réseau VPN est sur wg0.
Décision : Si la route vers 10.6.0.0/24 manque, wg0 n’est pas configuré correctement ; ne passez pas aux « corrections » NAT/routage tant que l’interface de base n’est pas saine.

Tâche 13 : activer l’IP forwarding seulement si vous routez au‑delà du serveur

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Ce que ça signifie : Le serveur ne route pas les paquets entre interfaces.
Décision : Laissez‑le désactivé sauf si vous en avez besoin. Si vous faites tunnel complet ou site‑à‑site, activez‑le délibérément et ajoutez des règles de pare‑feu en conséquence.

cr0x@server:~$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

cr0x@server:~$ sudo bash -c 'printf "net.ipv4.ip_forward=1\n" > /etc/sysctl.d/99-wireguard-forward.conf'

Tâche 14 : ajouter du NAT pour les clients en tunnel complet (seulement quand c’est voulu)

Si vous voulez que les clients utilisent le VPS comme egress Internet, vous devez NATer le trafic de wg0 vers eth0. Sans ça, vous aurez « connecté mais pas d’Internet ».

cr0x@server:~$ sudo nft add table ip nat

cr0x@server:~$ sudo nft 'add chain ip nat postrouting { type nat hook postrouting priority 100 ; }'

cr0x@server:~$ sudo nft add rule ip nat postrouting oif "eth0" ip saddr 10.6.0.0/24 masquerade

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
	chain postrouting {
		type nat hook postrouting priority srcnat; policy accept;
		oif "eth0" ip saddr 10.6.0.0/24 masquerade
	}
}

Ce que ça signifie : Le trafic client sortira avec l’IP publique du serveur.
Décision : Si vous n’avez pas besoin de tunnel complet, ne faites pas ça. Le NAT masque les erreurs comme « ça marche », jusqu’au jour où vous avez besoin de visibilité site‑à‑site.

Tâche 15 : valider les compteurs du pare‑feu pendant un test

cr0x@server:~$ sudo nft list chain inet filter input
chain input {
	type filter hook input priority filter; policy drop;
	ct state established,related accept
	iif "lo" accept
	udp dport 51820 accept
	ip saddr 203.0.113.10 tcp dport 22 accept
	ip protocol icmp accept
	ip6 nexthdr icmpv6 accept
	counter packets 12 bytes 672 reject with icmpx type port-unreachable
}

Ce que ça signifie : Le compteur de reject s’incrémente quand le bruit Internet aléatoire vous atteint.
Décision : Si les compteurs d’accept inattendus augmentent (par ex., SSH), resserrez les règles. Si les compteurs UDP 51820 restent à zéro pendant que les clients se connectent, vous n’atteignez pas réellement l’hôte — vérifiez les groupes de sécurité en amont.

Tâche 16 : capture de paquets pour « la poignée de main n’arrive jamais »

cr0x@server:~$ sudo tcpdump -n -i eth0 udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:44:10.112233 IP 203.0.113.77.49822 > 198.51.100.25.51820: UDP, length 148
12:44:10.212244 IP 203.0.113.77.49822 > 198.51.100.25.51820: UDP, length 148
5 packets captured

Ce que ça signifie : Des paquets arrivent au serveur. Si wg affiche toujours aucune poignée de main, le problème vient probablement des clés, de la config du pair, ou d’AllowedIPs.
Décision : Si tcpdump ne montre rien, arrêtez d’éditer les configs WireGuard et allez corriger la connectivité (pare‑feu cloud/groupe de sécurité, NAT, redirection de port, IP erronée).

Routage et NAT : tunnel divisé vs tunnel complet sans se saboter

Tunnel divisé : risque minimal, surprises minimales

Dans le tunnel divisé, le client ne route que des sous‑réseaux spécifiques vers le VPN. AllowedIPs typiques côté client :

• 10.6.0.0/24 pour atteindre d’autres peers VPN
• 192.168.50.0/24 pour atteindre votre LAN domestique via un peer site‑à‑site

Avantages :

• Moins de risque de casser l’accès Internet client.
• Moins d’utilisation de bande passante sur le serveur.
• Moins de « pourquoi Netflix est dans un autre pays ».

Inconvénient : vous ne cachez pas tout votre trafic du réseau local. Si vous avez besoin de cela (Wi‑Fi hostile), utilisez le tunnel complet temporairement.

Tunnel complet : puissant, casse les choses plus vite

Le tunnel complet signifie que le client route 0.0.0.0/0 (et ::/0 pour IPv6) via le VPN. Cela implique :

• Nat ou routage corrects sur le serveur.
• DNS géré avec soin pour éviter fuites ou pannes.
• Les problèmes de MTU deviennent plus visibles parce que tout utilise le tunnel.

La ligne de config client fait la différence entre « bel outil » et « dépendance réseau totale » :

• Divisé : AllowedIPs = 10.6.0.0/24, 192.168.50.0/24
• Complet : AllowedIPs = 0.0.0.0/0, ::/0

Site‑à‑site via VPS : la façon propre d’atteindre la maison sans ouvrir de ports

Exécutez WireGuard sur une petite machine à la maison (routeur, mini PC, NAS si nécessaire) en tant que peer qui se connecte en sortie au VPS.
Sur le VPS, ajoutez un peer avec AllowedIPs égal à votre sous‑réseau LAN domestique. Sur le peer domestique, ajoutez une route et des règles de pare‑feu pour forwarder entre wg0 et lan0.

Deux garde‑fous importants :

• Un seul peer doit « posséder » une route donnée dans AllowedIPs. Si deux peers annoncent 192.168.50.0/24, le trafic ira au dernier ajouté (et vous allez détester votre vie).
• Côté maison, le forwarding du pare‑feu n’est pas optionnel. Vous créez un routeur. Comportez‑vous comme tel.

Cahier d’intervention rapide

Quand WireGuard « ne fonctionne pas », les gens s’agitent : changent de ports, réinstallent des paquets, rebootent, puis déclarent victoire pour la mauvaise raison. Voici la séquence qui trouve le goulot d’étranglement rapidement.

Première étape : les paquets peuvent‑ils atteindre le port UDP du serveur ?

• Sur le serveur : ss -lunp | grep 51820 (est‑il à l’écoute ?)
• Sur le serveur pendant une tentative de connexion : tcpdump -n -i eth0 udp port 51820 (les paquets arrivent‑ils ?)
• Dans les environnements cloud : confirmer que le pare‑feu/groupe de sécurité du fournisseur autorise UDP 51820.

Si les paquets n’arrivent pas, rien d’autre n’a d’importance. Réparez le chemin réseau.

Deuxième étape : WireGuard forme‑t‑il une poignée de main ?

• wg show → vérifier « latest handshake »
• Si pas de poignée de main : endpoint IP/port erroné, clés incorrectes, ou pare‑feu serveur qui bloque UDP.

Troisième étape : pouvez‑vous faire transiter du trafic à l’intérieur du tunnel ?

• Pinger l’IP wg du serveur depuis le client.
• Serveur : surveiller les compteurs de transfert avec wg show.
• Si la poignée de main existe mais le trafic échoue, suspecter un mismatch AllowedIPs, un pare‑feu sur wg0, ou le MTU.

Quatrième étape : routage/NAT et DNS (la catégorie « connecté mais inutile »)

• Tunnel divisé : assurer que les routes existent côté client pour les sous‑réseaux privés attendus.
• Tunnel complet : assurer que le serveur a masquerade NAT et forwarding activés.
• DNS : assurer que votre client pointe vers un résolveur joignable via le mode de routage choisi.

Cinquième étape : goulots de performance

• Vérifiez le MTU et les symptômes de fragmentation en premier (HTTPS lent, blocages, certains sites échouent).
• Vérifiez la saturation CPU du serveur (VPS bon marché + gros débit peut être limitant).
• Vérifiez le path MTU et le comportement CGNAT si sur réseaux mobiles.

Blague #2 : Le dépannage VPN, c’est comme la plomberie — 99 % du temps, le problème est là où vous n’avez pas regardé parce que c’était « évident ».

Erreurs courantes (symptômes → cause → correction)

1) Symptom : « La poignée de main n’arrive jamais »

Cause racine : Port UDP bloqué en amont (pare‑feu cloud, ISP, mauvaise redirection), ou endpoint IP/port erroné dans la config client.

Correction : Vérifier avec ss que le serveur écoute, puis tcpdump pour voir l’UDP entrant. Si les paquets n’arrivent pas, corrigez les règles amont avant de toucher aux configs WireGuard.

2) Symptom : « Poignée de main OK, mais je ne peux pas pinger 10.6.0.1 »

Cause racine : Le pare‑feu serveur bloque le trafic sur wg0 (chaîne input n’autorise pas), ou l’Address/AllowedIPs du client est incorrect.

Correction : Autoriser l’input sur wg0 ou permettre ICMP pour le débogage ; confirmer que l’Address client est 10.6.0.2/32 et que le server peer AllowedIPs inclut 10.6.0.2/32.

3) Symptom : « Connecté, mais pas d’internet en tunnel complet »

Cause racine : IP forwarding et/ou NAT masquerade manquant sur le serveur.

Correction : Activer net.ipv4.ip_forward=1 et ajouter le masquerade nftables du sous‑réseau wg vers l’interface de sortie.

4) Symptom : « Certains sites chargent, d’autres bloquent (surtout HTTPS) »

Cause racine : Mismatch MTU causant fragmentation / blackholing.

Correction : Réduire le MTU de wg0 (essayer 1420 → 1380 → 1360). Avec PPPoE ou tunnels imbriqués, il faut souvent encore plus petit.

5) Symptom : « Un client met un autre hors ligne »

Cause racine : Deux peers configurés avec des AllowedIPs qui se chevauchent (ex. : tous les deux revendiquent 10.6.0.2/32 ou le même sous‑réseau LAN).

Correction : Rendre les AllowedIPs des peers uniques. Utiliser /32 par client. Pour les sous‑réseaux site, s’assurer qu’un seul peer annonce chaque sous‑réseau.

6) Symptom : « Le VPN marche depuis le Wi‑Fi domestique mais pas depuis le mobile »

Cause racine : NAT opérateur mobile / pare‑feu avec état qui expire les mappings UDP ; pas de keepalive réglé.

Correction : Mettre PersistentKeepalive = 25 sur le client. Ne pas le mettre sur le serveur pour des clients nomades ; c’est le client qui est derrière un NAT.

7) Symptom : « Le VPN est up, mais je n’accède pas à mon LAN via le VPS »

Cause racine : Le peer domestique ne forwarde pas entre son LAN et wg0, ou les routes de retour manquent sur les appareils LAN.

Correction : Activer le forwarding et ajouter des règles de pare‑feu sur la passerelle domestique. Envisager du NAT côté domestique pour la simplicité si vous ne pouvez pas ajouter de routes de retour.

8) Symptom : « Fuites DNS ou résolution split‑brain étrange »

Cause racine : Le client utilise un DNS local malgré le routage interne via le VPN, ou vous avez pointé le DNS vers un résolveur interne non joignable en tunnel divisé.

Correction : En tunnel divisé, soit garder un DNS public, soit router vers votre DNS interne et inclure son sous‑réseau dans AllowedIPs. En tunnel complet, définir explicitement le DNS et vérifier qu’il est joignable via le tunnel.

Trois micro‑histoires du monde professionnel

Micro‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne voulait un VPN rapide pour les ingénieurs d’astreinte. Le plan était « simple » : déployer WireGuard sur une VM cloud, laisser les ingénieurs se connecter, puis router vers des sous‑réseaux de production. L’ingénieur qui l’a mis en place a supposé que le groupe de sécurité cloud était déjà permissif pour l’UDP parce que « nous autorisons le trafic web ».

Lundi soir, un ingénieur d’astreinte a essayé de se connecter pendant un incident. Le client affichait « connecté » dans l’interface graphique, parce que l’interface locale s’était montée. Mais le serveur n’avait jamais vu de poignée de main. Les gens ont chassé les clés, les configs et le MTU pendant une heure, parce que ce sont des réglages que vous pouvez toucher sans demander à personne.

Le vrai problème : UDP 51820 était bloqué au niveau du pare‑feu fournisseur. Le serveur était à l’écoute. Le pare‑feu OS était correct. Mais les paquets n’arrivaient jamais. L’équipe avait traité « pare‑feu serveur » comme le seul pare‑feu.

La correction a été triviale une fois identifiée : ajouter une règle UDP entrante en bordure cloud. La leçon a coûté cher : valider la joignabilité d’abord, et documenter où la politique réside réellement. Les réseaux cloud sont en couches, et chaque couche est une chance d’être confiant et de se tromper.

Micro‑histoire 2 : L’optimisation qui a mal tourné

Une autre organisation utilisait WireGuard comme hub pour les développeurs. Quelqu’un a remarqué que l’ajout de peers et de routes rendait les configs difficiles à gérer. Leur « optimisation » a été d’élargir AllowedIPs partout : au lieu de /32 par client, ils ont utilisé 10.6.0.0/24 pour chaque peer sur le serveur, pensant que cela réduirait la maintenance.

Ça a fonctionné jusqu’au jour où ça n’a plus fonctionné. Un portable de développeur se connectait et détournait silencieusement le trafic destiné aux autres peers. Pas malicieusement — simplement parce que WireGuard croyait désormais que ce peer pouvait légitimement envoyer du trafic pour tout le sous‑réseau. Le routage est devenu non déterministe selon l’ordre d’ajout des peers et l’état des interfaces.

Les symptômes étaient délicieusement chaotiques : deux ingénieurs pouvaient se connecter correctement, le troisième se connectait mais ne pouvait pas atteindre des services internes, et parfois le problème « se réparait » après un redémarrage de wg0. Ce sont les meilleures pannes parce qu’elles enseignent l’humilité et la profanité en même temps.

Le rollback a été de revenir à des AllowedIPs stricts : /32 par road‑warrior, et seulement des sous‑réseaux spécifiques pour les peers de site. La gestion est devenue un peu plus fastidieuse. Le réseau a cessé d’être hanté. C’est un bon compromis.

Micro‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers utilisait WireGuard pour un petit ensemble d’agents d’automatisation dans plusieurs VPC. Leur configuration était peu glamour : une petite VM comme hub, un port UDP ouvert, SSH uniquement depuis un sous‑réseau de gestion dédié, et des règles nftables avec des politiques de forward explicites. Ils tenaient aussi un runbook : « joignabilité → poignée de main → routes → DNS ».

Pendant un incident fournisseur, la perte de paquets a grimpé et les latences sont devenues erratiques. Les agents d’automatisation ont commencé à échouer aux vérifications de santé. L’équipe n’a pas paniqué et n’a pas redéployé. Ils ont sorti leur runbook et l’ont exécuté comme s’ils payaient un loyer dessus.

Ils ont rapidement prouvé : les paquets UDP arrivaient, les poignées de main étaient récentes, et les compteurs de transfert augmentaient. Cela a éliminé la plupart des causes locales. Puis ils ont vérifié les erreurs d’interface et le MTU : propre. À ce stade, ils ont monté un dossier auprès du fournisseur avec des preuves plutôt qu’avec des impressions.

Le problème fournisseur s’est résolu plus tard, mais le point clé est que l’équipe a évité les blessures auto‑infligées. La pratique ennuyeuse n’était pas « avoir WireGuard ». C’était avoir un flux de diagnostic répétable, en plus d’une politique de pare‑feu qui ne change pas sous stress.

FAQ

1) Dois‑je changer le port WireGuard par défaut pour la sécurité ?

Pas pour la sécurité. La sécurité de WireGuard vient des clés, pas des numéros de port. Changer le port peut réduire le bruit des scans aléatoires. Si vous le changez, faites‑le partout et documentez‑le.

2) Puis‑je exécuter WireGuard et garder SSH fermé sur Internet ?

Oui, et c’est souvent la bonne démarche. Montez WireGuard d’abord via une console/accès out‑of‑band, puis restreignez SSH au sous‑réseau VPN (ou à un bastion). Si vous ne pouvez pas garantir de ne pas vous verrouiller hors du système, conservez une voie de gestion restreinte.

3) Quel est le minimum à exposer sur Internet ?

Un port UDP vers l’hôte WireGuard (par exemple 51820/udp). C’est tout. Tout le reste doit être bloqué ou restreint à des sources de confiance.

4) Comment empêcher un client VPN d’atteindre tout mon LAN ?

Deux couches : garder les AllowedIPs du client limitées (ne pas router le LAN vers lui), et appliquer des règles de forwarding sur le serveur (bloquer wg0 → LAN sauf autorisation explicite).

5) Dois‑je utiliser le NAT ou le routage pour site‑à‑site ?

Préférez le routage quand vous contrôlez les deux extrémités et pouvez ajouter des routes de retour ; c’est plus propre et plus facile à dépanner. Utilisez le NAT quand vous ne contrôlez pas les appareils LAN ou ne pouvez pas ajouter de routes ; c’est pragmatique mais masque la réalité réseau.

6) Pourquoi « connecté » ne veut pas dire « fonctionnel » ?

Beaucoup de clients affichent « connecté » quand l’interface est montée localement, même sans poignée de main. Faites confiance à wg show et aux compteurs de paquets, pas aux badges UI.

7) Ai‑je besoin de PersistentKeepalive ?

Pour les clients nomades derrière NAT (mobile, Wi‑Fi d’hôtel), oui — souvent. Réglez‑le côté client sur ~25 secondes. Pour un serveur avec IP publique, en général non.

8) WireGuard est‑il adapté à la production ?

Oui, avec un modèle de déploiement sensé : services exposés au minimum, AllowedIPs stricts, pare‑feu explicite, et un plan pour la rotation des clés et le offboarding. La plupart des « incidents VPN » sont des échecs de routage et de politique, pas de cryptographie WireGuard.

9) Et IPv6 ?

Si votre environnement utilise IPv6, traitez‑le comme une priorité : assignez des adresses IPv6 sur wg0, incluez ::/0 seulement si vous voulez un tunnel complet IPv6, et écrivez des règles de pare‑feu IPv6. Ignorer IPv6 est une façon courante de créer des « trous inutiles » que vous n’avez jamais surveillés.

10) Comment faire tourner les clés sans downtime ?

Ajoutez une nouvelle clé de peer (ou mettez à jour un peer) tout en gardant l’ancienne brièvement, puis retirez l’ancienne une fois que les clients confirment. En pratique : étalez les changements, vérifiez la poignée de main, puis purgez. N’effectuez pas des rotations « flag day » sauf si vous aimez les appels surprises.

Conclusion : étapes suivantes à faire aujourd’hui

Si vous ne retenez qu’une idée : exposez un seul port UDP et soyez explicite sur tout le reste. WireGuard est assez simple pour que vous puissiez garder l’ensemble du système en tête — jusqu’à ce que vous commenciez à ajouter des raccourcis « utiles ».

Étapes pratiques :

1. Choisissez une topologie (VPS hub est généralement la moins pénible) et notez les sous‑réseaux que vous allez router.
2. Mettez en place un pare‑feu par défaut drop avec des autorisations explicites pour UDP 51820 et SSH restreint.
3. Configurez les peers avec des AllowedIPs serrés (/32 par client) et testez la poignée de main et les compteurs avec wg show.
4. Si vous avez besoin d’un tunnel complet, activez le forwarding et le NAT délibérément, puis validez le comportement DNS.
5. Imprimez (ou collez) le Cahier d’intervention rapide dans votre runbook. Votre futur vous enverra une note de remerciement sous la forme de moins d’incidents.