WireGuard comme transport de transit IP : alternative chiffrée au GRE

Introduction

WireGuard est un protocole VPN moderne (UDP, chiffrement ChaCha20-Poly1305, ~4000 lignes de code kernel), très utilisé en peer-to-peer ou client-VPN. Mais il fait aussi un excellent transport de transit BGP quand :

• Ton FAI bloque IP proto 47 (Bouygues Bbox notamment)
• Tu veux chiffrer le trafic du tunnel (GRE et VXLAN sont en clair)
• Tu veux un setup simple, sans dépendance kernel exotique

Ce tuto suppose que tu as déjà commandé un Remote Transit IP VeryCloud avec transport WireGuard (à demander explicitement à la commande). VeryCloud te fournit alors une config peer WG côté backbone.

Prérequis

• Un serveur Linux avec une IP publique (ou derrière NAT avec port forwarding pour le keepalive)
• Le mail technique VeryCloud avec : PUB_VC, PORT_VC (UDP, souvent 51820), PubKey_VC, plan d'adressage tunnel 169.254.X.0/30 + 2a0e:XXXX:XXXX::/127
• Root / sudo
• WireGuard installé (kernel ≥ 5.6 ou wireguard-tools userland)

Étape 1 : Installer WireGuard

# Debian / Ubuntu (kernel-module + userland)
sudo apt update
sudo apt install -y wireguard wireguard-tools

# RHEL / Rocky / Alma
sudo dnf install -y wireguard-tools

Vérification :

wg --version

Étape 2 : Générer ta paire de clés

cd /etc/wireguard
sudo umask 077
sudo wg genkey | sudo tee privatekey | sudo wg pubkey > publickey
sudo cat publickey

Tu obtiens :

• privatekey : ne quitte JAMAIS ton serveur
• publickey : à envoyer à VeryCloud pour qu'ils l'ajoutent côté backbone

💡 La clé privée doit être chmod 600. Si elle leak, l'attaquant peut impersonate ton endpoint.

Étape 3 : Envoyer ta pubkey à VeryCloud

Réponds au ticket / mail technique avec ta clé publique :

Pubkey client : <contenu de publickey>

VeryCloud configure son côté et te confirme. Tu reçois en retour :

• PubKey_VC : clé publique du peer VeryCloud
• PUB_VC:PORT_VC : endpoint WireGuard côté VeryCloud
• Plan d'adressage tunnel inchangé

Étape 4 : Créer la config WireGuard

Crée /etc/wireguard/wg-vc.conf :

[Interface]
PrivateKey = <contenu de privatekey>
Address    = 169.254.X.2/30, 2a0e:XXXX:XXXX::1/127
ListenPort = 51820
MTU        = 1420

# Pas de Table=auto : on ne veut PAS que WG injecte des routes par défaut
Table      = off

[Peer]
PublicKey           = <PubKey_VC fournie par VeryCloud>
Endpoint            = PUB_VC:PORT_VC
AllowedIPs          = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Explications des points-clés :

• Address : les IPs internes du tunnel (côté client /30 et /127)
• MTU = 1420 : WireGuard ajoute 80 octets de header en IPv4 (60 en IPv6). MTU effective = 1500 - 80 = 1420
• Table = off : très important — sinon WG installe une route par défaut, et on veut que ce soit BGP qui le fasse
• AllowedIPs = 0.0.0.0/0, ::/0 : autorise tout trafic dans le tunnel (le filtrage se fera par BGP / iptables, pas par WG)
• PersistentKeepalive = 25 : envoie un keepalive toutes les 25s, utile si tu es derrière NAT

⚠️ Le Table = off est essentiel. Avec Table = auto, WG ferait un fwmark et installerait une default route — incompatible avec un setup BGP.

Étape 5 : Démarrer le tunnel

sudo chmod 600 /etc/wireguard/wg-vc.conf
sudo wg-quick up wg-vc

Vérification :

sudo wg show

Tu dois voir un handshake récent (< 2 min) si le tunnel est UP :

interface: wg-vc
  public key: ...
  private key: (hidden)
  listening port: 51820

peer: <PubKey_VC>
  endpoint: PUB_VC:51820
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 32 seconds ago
  transfer: 1.2 KiB received, 1.8 KiB sent

Test de connectivité :

ping 169.254.X.1
ping6 2a0e:XXXX:XXXX::0

Étape 6 : Activer au boot

sudo systemctl enable --now wg-quick@wg-vc

WireGuard remonte le tunnel au démarrage du serveur.

Étape 7 : MTU et MSS clamping

WireGuard gère bien le MTU en interne, mais pour les flux forwardés (si ton serveur est un routeur qui forwarde du trafic via WG), tu veux quand même du clamping :

sudo iptables -t mangle -A FORWARD -o wg-vc -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

sudo ip6tables -t mangle -A FORWARD -o wg-vc -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

Étape 8 : Autoriser TCP/179 sur le tunnel

sudo iptables -A INPUT -i wg-vc -p tcp --dport 179 -j ACCEPT
sudo iptables -A INPUT -i wg-vc -p tcp --sport 179 -j ACCEPT

sudo ip6tables -A INPUT -i wg-vc -p tcp --dport 179 -j ACCEPT
sudo ip6tables -A INPUT -i wg-vc -p tcp --sport 179 -j ACCEPT

Étape 9 : Le piège WireGuard + BGP — Table = off

C'est la subtilité de ce tuto.

Si tu laisses Table = auto (défaut), wg-quick :

• Crée une route par défaut via wg-vc
• Met en place un fwmark
• Empêche le forwarding "normal" via les routes BGP

Avec Table = off :

• WG ne touche pas à la table de routage
• BGP installe les routes selon ce que VeryCloud annonce (default route)
• Tu gardes le contrôle total

Étape 10 : Prêt pour BGP

Le tunnel WG est UP, les IPs internes pinguent, TCP/179 est ouvert. Tu peux lancer BIRD ou FRR avec :

• Peer IPv4 : 169.254.X.1
• Peer IPv6 : 2a0e:XXXX:XXXX::0
• Local : 169.254.X.2 et 2a0e:XXXX:XXXX::1

Voir les tutos BIRD 2 / FRR pour la session BGP.

Dépannage

Aucun handshake

• Port UDP/PORT_VC bloqué côté firewall (cloud provider, iptables)
• Endpoint mal renseigné
• Vérifier sudo tcpdump -i eth0 udp port PORT_VC -nn

Handshake OK mais ping ne marche pas

• Mauvais AllowedIPs (doit inclure 0.0.0.0/0, ::/0)
• IPs du tunnel pas assignées : ip addr show wg-vc

BGP refuse de s'établir alors que le tunnel est UP

• TCP/179 pas autorisé sur wg-vc
• Table = off pas en place : WG a installé des routes parasites qui interférent

Le tunnel monte au boot mais coupe après quelques heures

• Pas de keepalive : ajoute PersistentKeepalive = 25 côté client
• Conntrack table pleine si tu es derrière NAT

Performance < GRE

• C'est attendu : WG chiffre, GRE non. Compte 10-30% de moins selon CPU
• Sur Linux récent avec AES-NI ou ARM Crypto, le surcoût est minime

Commandes utiles

# État WireGuard
sudo wg show
sudo wg show wg-vc dump

# Stats interface
ip -s link show wg-vc

# Tcpdump dans le tunnel
sudo tcpdump -i wg-vc -nn

# Tcpdump sur le trafic UDP encapsule
sudo tcpdump -i eth0 udp port 51820 -nn

# Redemarrer
sudo systemctl restart wg-quick@wg-vc

# Stop manuel
sudo wg-quick down wg-vc

Conclusion

WireGuard en transport de transit = la combo gagnante quand GRE est filtré ou que tu veux du chiffrement bonus. La clé du setup est le Table = off : sans ça, WG marche contre ton BGP. Une fois cette subtilité comprise, tu as un tunnel rapide, chiffré, qui survit aux NAT, et qui passe partout où UDP passe.

Pour aller plus loin : BIRD 2 ou FRR pour la session BGP, multi-peer WG si tu veux rebondir sur plusieurs PoP VeryCloud, monitoring du handshake via Prometheus exporter WG.

Ressources

• WireGuard — Site officiel
• WireGuard — Conceptual overview
• wg-quick(8) — Documentation
• VeryCloud — Tunnel WireGuard de base