VPNSmith
self-host-vpnINFO

Templates de configuration WireGuard 2026 (prêts à l'emploi)

8 templates wg0.conf testés en production : home VPN, travel kill-switch, multi-peer, hub-and-spoke, MTU optim. Copie, colle, adapte. Setup en 5 min.

Par Eric Gerard · Fondateur · VPNSmith — Spécialiste self-host VPN & VPS GDPR9 min de lecturePhoto via Unsplash

Tu as installé WireGuard sur ton VPS. Tu as lu trois tutos contradictoires. Le wg0.conf que tu colles ne ping pas, ou alors il ping mais le DNS fuit, ou alors le kill switch coupe ta machine entière quand tu déconnectes le tunnel. La cause est presque toujours la même : un template copié sans comprendre le contexte d'origine.

Ce guide propose 8 templates wg0.conf testés en production sur Contabo VPS S, avec le contexte d'usage, les pièges connus et les ajustements à faire. Tu choisis celui qui matche ton scénario, tu adaptes 4 lignes, tu te connectes. Cinq minutes.

Conventions communes

Tous les templates suivent les mêmes conventions, simplifie ton mental model :

  • Subnet client : 10.66.66.0/24 (peers .2 → .254)
  • Interface publique serveur : eth0 (vérifie avec ip route | awk '/default/ {print $5}')
  • Port UDP : 51820 (changeable, voir template 7 obfuscation)
  • Clés : générées avec wg genkey | tee server.key | wg pubkey > server.pub
  • Sysctl : net.ipv4.ip_forward=1 activé sur le serveur (/etc/sysctl.conf)
  • MTU : 1420 par défaut, ajusté quand nécessaire

Les blocs PrivateKey ci-dessous sont des placeholders — remplace par les tiens. Ne jamais committer ces fichiers dans un repo git public.

Template 1 — Serveur WireGuard standard (1 client roadwarrior)

Le cas le plus courant : ton VPS Contabo expose un tunnel pour ton MacBook en déplacement.

# /etc/wireguard/wg0.conf (serveur)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820
MTU = 1420

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

[Peer]
# MacBook Eric
PublicKey = CLIENT_PUBLIC_KEY_HERE
AllowedIPs = 10.66.66.2/32

Côté client :

# /etc/wireguard/wg0.conf (client macOS/Linux)
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9, 149.112.112.112
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Points d'attention :

  • AllowedIPs = 0.0.0.0/0, ::/0 route TOUT le trafic du client via le VPS — c'est ce que tu veux pour un VPN classique.
  • PersistentKeepalive = 25 est obligatoire si le client est derrière un NAT (réseau hôtel, 4G) — sans ça, le tunnel meurt après ~3 min d'inactivité.
  • DNS = 9.9.9.9 force Quad9 résolution — sinon le client utilise le DNS local et tu fuites tes requêtes.

Template 2 — Home VPN (split-tunnel : LAN local exclu)

Tu veux du VPN pour ton trafic web mais garder l'accès au LAN local (imprimante, NAS) sans passer par le tunnel.

# Client home
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Tout sauf le LAN RFC1918 + multicast + APIPA
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/3, 224.0.0.0/4, 240.0.0.0/5, 248.0.0.0/6, 252.0.0.0/7, 254.0.0.0/8, 255.0.0.0/9
PersistentKeepalive = 25

L'astuce des subnets fragmentés (au lieu de 0.0.0.0/0) fait que WireGuard ajoute des routes spécifiques qui n'écrasent pas la route par défaut. Le 192.168.x.x et 10.x.x.x du LAN restent accessibles directement.

Outils en ligne pour générer ces ranges : wg-allowed-ips.compute() ou simplement Tunsafe / WireGuard Network Calc.

Template 3 — Travel VPN avec kill switch netfilter strict

Tu pars en Chine, en Iran, en Russie. Si le tunnel tombe, rien ne doit fuiter. Solution : kill switch netfilter qui drop tout sauf le trafic via wg0 et la connexion au handshake serveur.

# Client travel kill-switch
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1280

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PostUp = ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Ces 4 lignes PostUp/PreDown sont le vrai kill switch — pas une popup applicative. Tant que wg-quick down wg0 n'a pas tourné, aucun paquet ne sort de l'interface qui ne soit pas marqué par WireGuard.

MTU à 1280 pour les réseaux capricieux (hôtels, 3G). Quitte à perdre 1 % de débit, mieux vaut un tunnel qui tient.

Template 4 — Multi-peer (5 appareils, même utilisateur)

Tu as un MacBook, un iPhone, un iPad, un VPS de travail, un Raspberry Pi. Tu veux tous les router via le même VPN avec des subnets séparés pour le monitoring.

# /etc/wireguard/wg0.conf (serveur)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

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

[Peer]
# MacBook
PublicKey = MAC_PUBKEY
AllowedIPs = 10.66.66.2/32

[Peer]
# iPhone
PublicKey = IPHONE_PUBKEY
AllowedIPs = 10.66.66.3/32

[Peer]
# iPad
PublicKey = IPAD_PUBKEY
AllowedIPs = 10.66.66.4/32

[Peer]
# Worker VPS (Hetzner)
PublicKey = WORKER_PUBKEY
AllowedIPs = 10.66.66.5/32

[Peer]
# Raspberry Pi home
PublicKey = RPI_PUBKEY
AllowedIPs = 10.66.66.6/32

Chaque peer a une IP fixe sur le subnet 10.66.66.0/24. Si tu surveilles via Prometheus (voir le guide monitoring), tu peux étiqueter par IP et savoir qui consomme combien.

Template 5 — Hub-and-spoke (peer-to-peer entre clients)

Par défaut WireGuard ne route pas les paquets entre peers. Si tu veux que ton iPhone parle à ton Raspberry Pi à travers le hub serveur :

Côté serveur, ajoute :

sysctl -w net.ipv4.ip_forward=1

Et dans les [Peer] du serveur, mets AllowedIPs = 10.66.66.X/32 (IP unique du peer).

Côté clients, modifie AllowedIPs :

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Tout le subnet, pas juste 0.0.0.0/0
AllowedIPs = 10.66.66.0/24

Avec ça, depuis ton iPhone (10.66.66.3) tu peux ssh pi@10.66.66.6 directement — le hub forward.

Template 6 — Restriction sortie par peer (allowlist)

Cas avancé : un peer (ton enfant, un invité, un service automatisé) doit pouvoir se connecter au tunnel mais uniquement vers certains domaines/IP.

Ajoute côté serveur, dans le bloc [Peer] concerné, des règles iptables ciblées par source IP :

# PostUp côté serveur (en plus du MASQUERADE)
iptables -A FORWARD -s 10.66.66.50/32 -d 1.1.1.1 -j ACCEPT
iptables -A FORWARD -s 10.66.66.50/32 -d 142.250.0.0/15 -j ACCEPT  # Google
iptables -A FORWARD -s 10.66.66.50/32 -j REJECT

Le peer 10.66.66.50 ne peut joindre que 1.1.1.1 (DNS) et les IP Google. Tout le reste est rejeté.

Template 7 — Obfuscation port 443 via udp2raw

Certains pare-feu corporate bloquent UDP en sortie. Solution : encapsuler WireGuard dans du fake TCP/443 via udp2raw.

Côté serveur :

udp2raw_amd64 -s -l 0.0.0.0:443 -r 127.0.0.1:51820 -k "p@ssw0rd_long" --raw-mode faketcp

Côté client :

udp2raw_amd64 -c -l 127.0.0.1:50000 -r vpn.example.com:443 -k "p@ssw0rd_long" --raw-mode faketcp

Dans le wg0.conf client, change Endpoint :

Endpoint = 127.0.0.1:50000

Le débit chute (~30 % overhead) mais ça passe à travers presque tout DPI corporate.

Template 8 — Site-to-site (deux LAN reliés)

Deux maisons, deux Raspberry Pi en passerelle, un VPS Contabo comme hub. Chaque LAN voit l'autre LAN comme s'il était local.

Côté serveur (VPS hub) :

[Interface]
PrivateKey = HUB_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

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

[Peer]
# Site A (LAN 192.168.10.0/24)
PublicKey = SITE_A_PUBKEY
AllowedIPs = 10.66.66.10/32, 192.168.10.0/24

[Peer]
# Site B (LAN 192.168.20.0/24)
PublicKey = SITE_B_PUBKEY
AllowedIPs = 10.66.66.20/32, 192.168.20.0/24

Côté Site A (Raspberry Pi) :

[Interface]
PrivateKey = SITE_A_PRIVATE_KEY_HERE
Address = 10.66.66.10/24

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

[Peer]
PublicKey = HUB_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Ne pas oublier d'activer ip_forward sur les deux Raspberry et d'ajouter une route statique sur les autres machines du LAN si elles doivent répondre depuis l'autre site.

Diagnostic rapide quand rien ne marche

Tu as collé le template, tu lances wg-quick up wg0, ça démarre — mais ping fail. Checklist dans cet ordre :

  • wg show : la dernière handshake est-elle récente ? Si "never" → handshake KO, vérifie l'Endpoint, le port UDP côté firewall serveur (ufw status ou iptables -L).
  • ip route sur le client : la route vers le subnet VPN existe-t-elle ? Si non → AllowedIPs client foireux.
  • dig @9.9.9.9 ifconfig.me +short depuis le client connecté : retourne-t-il l'IP du VPS ? Si non → MASQUERADE manquant côté serveur, ou ip_forward = 0.
  • tcpdump -i wg0 côté serveur : vois-tu les paquets arriver ? Si oui mais aucune sortie sur eth0 → règle FORWARD/MASQUERADE manquante.
  • MTU : ping -M do -s 1400 1.1.1.1 depuis le client. Si "Frag needed" → réduit MTU dans wg0.conf à 1380 ou 1280.

Si tu pars de zéro et que tu galères, le guide setup Contabo pas-à-pas reprend toute l'installation depuis le SSH initial.

En production : ce que ces templates ne couvrent pas

Ils sont volontairement minimalistes. Pour un usage prod long-terme, prévois :

  • Backup régulier de /etc/wireguard/ (sinon une perte de clé serveur = re-générer tous les clients)
  • Rotation des clés tous les 12-18 mois (procédure : générer nouvelle clé, ajouter peer parallèle, migrer clients un par un, retirer ancien peer)
  • Monitoring via Prometheus + wireguard_exporter (voir le guide monitoring Grafana)
  • Fail2ban sur le port UDP 51820 si tu vois des tentatives de port scan dans journalctl -u wg-quick@wg0
  • Limitation par peer via tc (traffic control Linux) si un peer abuse de la bande passante

Et surtout : ne committe jamais un wg0.conf réel dans un repo, même privé. Garde-les en .gitignore ou chiffre-les avec age / sops.

Pour aller plus loin

Si tu veux comprendre pourquoi WireGuard est plus rapide qu'OpenVPN à débit équivalent CPU, on a fait un comparatif technique détaillé avec benchmarks réels iperf3 sur Contabo, kernel module vs userspace, et profil consommation batterie sur iPhone.

Et pour la partie tueur de fuite, le guide kill switch Linux iptables + systemd montre comment garantir zéro fuite même quand WireGuard crash.

Tous les templates ci-dessus sont en usage chez nous depuis 14 mois sur un Contabo VPS S à 4,99 €/mois (/go/contabo). Aucun outage tunnel non planifié, ~2 fenêtres maintenance Contabo prévues à l'avance.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis

Voir l'offre Contabo30 jours satisfait ou remboursé→
Articles liés

Pour aller plus loin