VPN site à site WireGuard : relier deux réseaux (guide 2026)

Transparence affiliation — Cet article contient des liens affiliés Contabo. Si vous commandez un VPS via ces liens, nous touchons une commission sans surcoût pour vous. Toutes les commandes et configs ci-dessous sont documentées d'après les sources officielles WireGuard et écrites pour être reproductibles sur vos propres machines.

Un VPN site à site relie deux réseaux entiers pour qu'ils se comportent comme un seul. Chaque hôte du LAN du bureau peut joindre chaque hôte du LAN du domicile — votre NAS, une imprimante, un hyperviseur, une base de données — sans installer de client VPN sur chaque appareil. WireGuard rend cela léger et rapide : un seul port UDP, quelques lignes de config, une crypto en espace noyau. Ce guide construit un tunnel WireGuard site à site fonctionnel de zéro, puis explique les trois pièges récurrents : AllowedIPs, le routage IP, et le routage des hôtes.

Nous prenons une topologie concrète et courante : le Site A est un LAN domestique ou de bureau derrière NAT (pas d'IP publique exploitable), et le Site B est un VPS à IPv4 publique servant de hub toujours actif. La même config relie aussi deux domiciles, deux bureaux ou deux datacenters — seuls les sous-réseaux changent.

Site à site vs nomade : ce qui change vraiment

Si vous avez déjà configuré WireGuard pour un portable, 90 % de tout ceci vous est familier. Le changement de logique est petit mais essentiel :

• Nomade (accès distant) : un appareil rejoint le réseau. Son pair annonce une seule adresse de tunnel — AllowedIPs = 10.66.66.2/32.
• Site à site : un réseau entier rejoint. Le pair annonce le sous-réseau LAN situé derrière lui — AllowedIPs = 10.66.66.2/32, 192.168.10.0/24 — et la box WireGuard relaie pour chaque hôte de ce LAN.

Tout le reste — clés, handshake, port UDP — est identique. Si votre handshake n'aboutit jamais, les causes sont les mêmes que pour n'importe quel tunnel ; déroulez la liste de correctifs du handshake WireGuard avant d'incriminer la partie site à site.

Planifiez d'abord le plan d'adressage (5 minutes qui en font gagner des heures)

Avant de toucher à une config, notez trois plages. Se tromper ici est la cause n°1 d'un tunnel qui se connecte mais ne transporte aucun trafic hôte.

La règle dure : les deux LAN ne doivent pas se chevaucher. Si les deux côtés utilisent aujourd'hui 192.168.1.0/24, renumérotez-en un maintenant. Un hôte ne peut pas router vers un sous-réseau distant identique au sien — il considérera l'adresse comme locale et ne passera jamais le paquet à WireGuard. Si le calcul de sous-réseaux vous échappe, notre explication d'un sous-réseau détaille le CIDR simplement.

Étape 1 — Provisionner le hub (Site B, le VPS)

Le Site B a besoin d'une IPv4 publique et d'un port UDP ouvert. Nous utilisons un Contabo Cloud VPS 10 (4 vCPU, 8 Go RAM, 75 Go NVMe) à 5,50 €/mois sur l'engagement 12 mois — surdimensionné pour un tunnel, confortable s'il fait tourner d'autres services. Si vous n'avez pas encore de VPS, prenez le Contabo Cloud VPS 10 ; choisissez une région proche du site qui émet le plus de trafic. Pour une installation propre de WireGuard dessus, suivez le guide pas à pas Contabo + WireGuard, puis revenez ici pour le routage site à site.

Installez WireGuard et générez les clés sur le VPS :

sudo apt update && sudo apt install -y wireguard
umask 077
wg genkey | tee siteB.key | wg pubkey > siteB.pub

Étape 2 — Mettre en place le routeur WireGuard au Site A

La box WireGuard du Site A est n'importe quelle machine Linux toujours allumée du LAN — un Raspberry Pi, une petite VM, un vieux portable. Elle n'a pas besoin d'IP publique ; elle compose vers le VPS. Générez ses clés de la même façon :

wg genkey | tee siteA.key | wg pubkey > siteA.pub

Cette machine devient la passerelle du sous-réseau distant : elle doit donc relayer les paquets entre son interface LAN et l'interface WireGuard.

Étape 3 — Les deux configurations

Voici tout le tunnel. Remarquez comment l'AllowedIPs de chaque côté liste le LAN de l'autre site — c'est cette ligne qui transforme une liaison point à point en liaison réseau à réseau.

Site B — le hub VPS (/etc/wireguard/wg0.conf) :

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = <siteB.key>
# forward + masquerade pour que les hôtes du Site A atteignent aussi internet via le VPS
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Site A
PublicKey = <siteA.pub>
AllowedIPs = 10.66.66.2/32, 192.168.10.0/24

Site A — le routeur LAN (/etc/wireguard/wg0.conf) :

[Interface]
Address = 10.66.66.2/24
PrivateKey = <siteA.key>
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT

[Peer]
# Site B (le hub VPS)
PublicKey = <siteB.pub>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Deux détails qui comptent :

• PersistentKeepalive = 25 se place du côté derrière NAT (Site A). Il envoie un petit paquet toutes les 25 secondes pour que la box domestique garde le chemin UDP ouvert et que le VPS puisse toujours répondre.
• Endpoint n'apparaît que dans le bloc pair du Site A — c'est le Site A qui appelle le VPS. Le VPS apprend l'adresse du Site A à l'arrivée du premier paquet : son bloc pair n'a donc pas d'Endpoint.

Montez les deux tunnels avec sudo wg-quick up wg0 et vérifiez sudo wg show. Un latest handshake de moins de deux minutes des deux côtés signifie que le lien est vivant.

Étape 4 — L'étape que tout le monde oublie : le routage des hôtes

C'est là que la plupart des tunnels site à site calent. Les routeurs se pinguent en 10.66.66.x, mais un portable du Site A n'atteint toujours pas un NAS du Site B. Pourquoi ? Parce que les autres hôtes de chaque LAN ignorent que la box WireGuard est la porte vers le sous-réseau distant. Ils envoient le paquet à leur passerelle par défaut, qui n'a aucune route pour 192.168.20.0/24, et il meurt.

Deux moyens propres de corriger :

1. Route statique sur la passerelle du LAN (le mieux). Sur le routeur principal du Site A, ajoutez une route statique : destination 192.168.20.0/24, passerelle = l'IP LAN de la box WireGuard du Site A (par ex. 192.168.10.5). Faites le miroir au Site B. Chaque hôte hérite alors automatiquement de la route. La plupart des routeurs grand public et pro gèrent les routes statiques dans leur interface d'administration.
2. Routes statiques par hôte. Si vous ne pouvez pas toucher au routeur, ajoutez une route sur chaque machine qui doit accéder à l'autre site :

# sur un hôte du Site A, joindre le LAN du Site B via la box WireGuard locale
sudo ip route add 192.168.20.0/24 via 192.168.10.5

Si la box WireGuard est la passerelle par défaut de votre LAN, vous pouvez sauter complètement cette étape — elle relaie déjà. C'est conceptuellement un problème de routage, pas de VPN ; la même logique que la redirection de port mais appliquée à un sous-réseau entier au lieu d'un seul port.

Étape 5 — Pare-feu sur le chemin de forwarding

Forwarder sans règle de pare-feu, c'est laisser passer soit rien, soit tout. Soyez explicite. Sur le hub VPS, le PostUp ci-dessus accepte déjà le trafic relayé depuis wg0 ; resserrez-le si vous ne voulez autoriser que certains sous-réseaux :

# n'autoriser que LAN Site A <-> LAN Site B, jeter le reste
iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -i wg0 -j ACCEPT
iptables -A FORWARD -s 192.168.20.0/24 -d 192.168.10.0/24 -o wg0 -j ACCEPT

Rendez les règles persistantes (iptables-save, ou netfilter-persistent save sur Debian/Ubuntu) pour qu'elles survivent à un redémarrage. Le port UDP unique doit aussi être ouvert devant le VPS — voyez quel port utilise WireGuard et comment l'ouvrir si le handshake ne démarre jamais.

Vérifier le chemin complet

Lancez ceci dans l'ordre et arrêtez-vous au premier échec :

1. Tunnel actif ? sudo wg show des deux côtés → latest handshake récent, transfer non nul.
2. Routeur à routeur ? Depuis la box WireGuard du Site A : ping 10.66.66.1. Échec → c'est un problème de tunnel, pas de site à site.
3. Routeur vers LAN distant ? Depuis la box du Site A : ping 192.168.20.1. Échec → AllowedIPs ou ip_forward sur le Site B.
4. Hôte vers hôte distant ? Depuis un portable du Site A : ping 192.168.20.50. Échec ici mais l'étape 3 passait → routage des hôtes (étape 4).

Cette échelle en quatre lignes isole en moins d'une minute la couche exacte qui casse.

Quand ajouter d'autres sites — en étoile (hub-and-spoke)

Pour relier trois réseaux ou plus, gardez le VPS comme hub central et ajoutez chaque nouveau LAN comme pair satellite dessus. Chaque satellite liste tous les autres sous-réseaux LAN dans son AllowedIPs (routés via le hub), et le hub liste le LAN de chaque satellite. Ça reste simple jusqu'à une poignée de sites. Au-delà — ou si vous voulez rotation automatique des clés, ACL et traversée de NAT sans IP publique d'aucun côté — un plan de contrôle maillé comme Tailscale ou Headscale demande moins de travail que d'éditer les pairs à la main ; pesez le choix dans notre comparatif Tailscale vs WireGuard self-host.

Pourquoi auto-héberger le hub plutôt qu'un service géré

Une liaison site à site est précisément l'endroit où posséder la box paie : pas de tarif par siège, pas de quota de données, aucun tiers sur le chemin entre vos deux réseaux. Un Contabo Cloud VPS 10 à 5,50 €/mois offre une IPv4 publique, le root complet, un trafic illimité (fair-use) et la liberté d'ouvrir le seul port UDP dont vous avez besoin — le hub toujours actif idéal pour relier vos sites. Construisez-le une fois, il tourne des années.

Pour aller plus loin

• VPN auto-hébergé sur Contabo : guide WireGuard complet 2026
• Handshake WireGuard qui n'aboutit pas : la liste complète des correctifs
• Qu'est-ce qu'un sous-réseau ? Subnetting et CIDR expliqués
• La redirection de port expliquée : joindre un serveur derrière votre routeur
• Tailscale vs WireGuard self-host : lequel choisir
• Modèles de configuration WireGuard prêts à l'emploi 2026

Sources et références :

• Livre blanc WireGuard — Jason A. Donenfeld
• Quickstart WireGuard et docs wg-quick
• Pages de manuel wg(8) et wg-quick(8)
• Arch Wiki — WireGuard (routage & site à site)

Publié le 2026-06-26. Topologie validée sur Debian 12 et Ubuntu 24.04 avec un hub Contabo Cloud VPS 10 et un routeur LAN Raspberry Pi. Vos sous-réseaux, modèles de routeur et le comportement NAT de votre FAI différeront — confirmez toujours chaque couche avec wg show, ping et ip route avant de considérer une configuration comme finale.

Rappel : faire tourner WireGuard et auto-héberger un VPN est légal dans l'UE, aux États-Unis, au Canada et dans la plupart des pays démocratiques. VPNSmith publie ce contenu à des fins éducatives.