WireGuard maillage complet : quand les tunnels directs bureau-à-bureau valent le coup (et quand non)

décembre 8, 2025 • février 3, 2026 • Lecture : 33 min • Views: 7

Cet article vous a aidé ?

Vous le remarquez d’abord sur des détails : les partages de fichiers semblent « collants », les appels VoIP entre bureaux sonnent comme si quelqu’un parlait à travers un aquarium, et le tableau de bord préféré du CFO se charge juste assez lentement pour qu’on blâme « le cloud ».
Puis vous regardez le chemin et réalisez que vous faites du hairpin du trafic du Bureau A vers le Bureau B via un centre de données central à trois États de là parce que c’est ainsi que le VPN a été construit en 2017 et personne ne veut y toucher.

Le maillage complet WireGuard ressemble à la solution : connectez chaque bureau directement à tous les autres. La latence baisse, les sorties Internet restent locales, et vous arrêtez de payer la « taxe du hub central ».
C’est aussi un bon moyen de créer une « snowflake » opérationnelle qui explose au moment où vous ajoutez votre 13e site.

Ce que vous décidez vraiment : topologie et domaines de panne

Les gens parlent du « maillage complet » comme si c’était une fonctionnalité produit. Ce n’en est pas une. C’est un pari.
Le pari est que réduire la longueur des chemins (et éviter un point d’étranglement hub) vaut la peine d’augmenter le nombre de relations que vous devez gérer : clés, endpoints, routes, règles de pare-feu, monitoring et rayon d’impact des incidents.

WireGuard lui-même n’est pas la partie difficile. WireGuard est un protocole propre, minimal, avec une petite base de code et un comportement prévisible.
La partie difficile est le système autour : politique de routage, réalité du NAT, gestion des adresses, cas limites MTU/fragmentation, et des humains gérant les changements à l’échelle.

Le calcul d’échelle que personne ne veut mettre sur une diapositive

Dans un maillage complet avec n sites, vous avez n(n-1)/2 tunnels (ou relations de pairs) si tout le monde est pairé directement avec tout le monde.
Ça fait 10 sites → 45 relations. 20 sites → 190. 50 sites → 1225. La croissance est quadratique, et votre patience ne l’est pas.

Vous pouvez automatiser la génération et la distribution des configurations. Vous le devriez. Mais l’automatisation n’enlève pas la complexité opérationnelle ; elle vous permet juste de créer de la complexité plus rapidement.

Ce que WireGuard fait bien (et ce qu’il ne prétend pas faire)

WireGuard vous donne un chiffrement authentifié, un modèle d’interface simple, et une belle propriété : s’il n’y a pas de trafic, il n’y a pratiquement pas d’état.
Mais WireGuard ne fait pas de routage dynamique. Il ne fait pas de sélection de chemin. Il ne vous dit pas « le pair B est tombé ; utilisez le pair C ».
Ces comportements viennent de votre couche de routage (routes statiques, BGP/OSPF via FRR, routage basé sur la politique, logique SD-WAN) et de votre conception réseau.

La leçon fiable en ingénierie des systèmes est ancienne et toujours vraie : gardez le plan de contrôle simple, mais ne prétendez pas ne pas en avoir un.

Une citation pour vous garder honnête

L’espoir n’est pas une stratégie. — General Gordon R. Sullivan

Elle s’applique magnifiquement aux topologies VPN. Si votre plan dépend de « le hub n’a probablement pas de problèmes », vous avez un plan fait de vœux.

Quand les tunnels directs bureau-à-bureau valent le coup

Le maillage complet peut être la bonne réponse. Pas parce que c’est tendance, mais parce qu’il résout des problèmes physiques et organisationnels spécifiques.
Voici les cas où je le recommanderai sans faire la tête « vous êtes sûr ? ».

1) Vous avez du trafic temps réel site-à-site qui souffre de la latence du hairpin

VoIP, vidéo, VDI, bureau à distance vers des applis on-prem, télémétrie OT/SCADA, et tout ce qui est interactif.
Si le Bureau A et le Bureau B sont à 8 ms l’un de l’autre, et que votre hub est un détour de 40 ms, les mathématiques sont cruelles.
Le jitter est souvent pire que la latence brute, et la congestion du hub ajoute du jitter gratuitement.

Un tunnel direct vous donne un chemin cohérent qui ne concurrence pas le trafic non lié destiné au hub.

2) Votre hub est un goulot d’étranglement que vous ne pouvez pas (ou ne devriez pas) scaler indéfiniment

Parfois le hub est une paire de pare-feux virtuels avec des licences au prix d’un petit yacht. Parfois c’est un circuit DC exigu que les achats ne mettront pas à niveau avant le trimestre prochain, ce qui signifie « jamais ».
Le maillage complet répartit la charge et réduit le mode de défaillance « toutes les routes mènent à Rome ».

3) Vous avez besoin d’exits Internet locaux tout en conservant une forte connectivité site-à-site

Si chaque bureau rétrocède Internet via une egression centrale, vous obtenez des contrôles de sécurité cohérents et des logs faciles. Vous obtenez aussi de mauvaises performances SaaS et des joies liées au routage asymétrique.
Un maillage peut permettre aux bureaux de garder leur propre egress tout en préservant l’accessibilité directe pour les services internes.

4) Votre transport WAN est hétérogène et vous voulez de la diversité de chemins

Les bureaux peuvent avoir de la fibre, du câble, du LTE, ou de l’étrange « broadband entreprise » qui se comporte comme allergique à la disponibilité.
Avec plusieurs WAN par site, vous pouvez avoir plusieurs peers WireGuard et du routage par politique pour garder le trafic hors du pire lien.
Le maillage ne vous donne pas automatiquement de l’ingénierie du trafic, mais il vous donne plus d’options de chemin à exploiter.

5) Vous avez un petit nombre de sites et une forte culture d’automatisation

Le maillage complet est gérable à 3–8 sites. Il peut être acceptable à ~10–15 si vous générez les configs centralement, suivez les allocations IP, imposez des revues et testez les changements.
Au-delà, il vous faut un plan sérieux pour le routage et la distribution des configs, sinon vous construisez une machine de Rube Goldberg qui est à un renversement de café de l’indisponibilité.

6) Vous devez contenir les pannes à des paires de sites

Dans une conception hub-and-spoke, l’instabilité du hub devient le problème de tout le monde. Dans un maillage, un flap de tunnel affecte les deux points terminaux.
Ce rayon d’impact plus étroit peut faire la différence entre « un ticket » et « une réunion d’incident à l’échelle de l’entreprise ».

7) Vous migrez depuis MPLS et l’attente « any-to-any » est ancrée

Les organisations qui ont grandi avec MPLS s’attendent à ce que n’importe quel bureau puisse parler à n’importe quel autre bureau. Quand vous remplacez cela par hub-and-spoke, les utilisateurs le remarquent.
Un maillage (ou un maillage partiel avec routage) peut correspondre aux attentes avec moins de batailles politiques.

Quand le maillage complet est un piège

Le maillage échoue de manière prévisible. Les échecs ne sont pas des bugs crypo exotiques ; ce sont des échecs « humains et tables de routage ».
Voici quand j’éviterais un maillage complet et choisirais un autre modèle.

1) Vous avez plus de sites que d’attention opérationnelle

Si vous vous dirigez vers 20+ emplacements, le maillage complet sans routage dynamique et sans forte automatisation devient un risque de maintenance.
La rotation des clés à elle seule devient un problème de calendrier avec des invitations et des emails d’escalade gênants.

Aussi, quand chaque changement touche des dizaines de peers, chaque changement est un « gros changement », ce qui signifie moins de changements, ce qui signifie plus de dérive, ce qui signifie des pannes pires.

2) Vos sites sont derrière des NAT hostiles ou ont des IPs qui changent fréquemment

WireGuard peut fonctionner derrière un NAT, mais il a quand même besoin d’un moyen de trouver l’autre côté.
Si les deux extrémités sont derrière un NAT de l’opérateur avec des adresses changeantes et pas de rendez-vous stable (ou si vous ne pouvez pas utiliser de relais), les tunnels directs deviennent un hobby pour maintenir la disponibilité.

3) Vous avez besoin d’une segmentation propre ou de frontières de conformité

Le maillage complet a tendance à encourager « tout peut atteindre tout » sauf si vous mettez en place une politique sérieuse de routage/pare-feu.
Si vous êtes dans un environnement réglementé, ou si vous avez des unités métier qui ne devraient pas partager des réseaux, un maillage devient un puzzle d’application de politique.
Plus vous avez d’arêtes, plus vous avez d’endroits où autoriser le trafic accidentellement.

4) Vous ne pouvez pas tolérer l’erreur humaine dans AllowedIPs

AllowedIPs est à la fois le contrôle d’accès de WireGuard et son sélecteur de routage. C’est élégant. C’est aussi un couteau tranchant.
Une entrée AllowedIPs erronée peut noyer le trafic, détourner le trafic vers le mauvais peer, ou créer des boucles de routage combinées avec les routes de l’OS.

5) Votre équipe a besoin de « mettre en place et oublier »

Si le banc réseau est peu fourni et que les changements sont rares, préférez une conception avec moins de pièces mobiles :
hub-and-spoke, double hubs, ou un petit nombre de hubs régionaux.
Vous n’êtes pas moins professionnel en choisissant l’ennuyeux. Vous êtes plus employé.

Petite blague #1 : Le maillage complet, c’est comme un chat de groupe — super avec cinq personnes, et un désastre une fois que la tante de tout le monde est ajoutée.

Options de conception qui ne sont pas « maillage ou rien »

Hub-and-spoke (hub unique) — le kit de démarrage

Avantages : le plus simple à comprendre, le plus facile à sécuriser centralement, le plus simple à monitorer.
Coûts : le hub devient un goulot de bande passante et un domaine de panne ; latence de hairpin ; coûts du circuit hub.

À utiliser quand : vous avez peu de flux inter-bureaux, principalement du « branche vers datacenter », et que le hub est robuste et redondant.

Double hub — la version « adulte »

Deux hubs (de préférence dans des régions/fournisseurs différents) avec des branches connectées aux deux. Utilisez la préférence de routage et le basculement.
Cela réduit le point de défaillance unique et peut réduire la latence de hairpin si vous choisissez bien les hubs.

C’est souvent la meilleure valeur : vous évitez la croissance quadratique tout en améliorant la résilience.

Hubs régionaux (maillage partiel) — latence sans folie

Créez 3–6 points d’agrégation régionaux ; les bureaux se maillent au sein d’une région ou se connectent à leur région la plus proche. Le trafic inter-région passe hub-à-hub.
Vous conservez la plupart des gains de latence et réduisez dramatiquement le nombre de peers.

Maillage avec routage dynamique (FRR + BGP) — l’option « réseau sérieux »

Si vous insistez pour un maillage à grande échelle, ne le faites pas avec du routage statique et de l’espoir.
Exécutez un démon de routage (souvent FRR) et échangez des routes sur WireGuard. Laissez la couche de routage gérer l’accessibilité et le basculement.

Mise en garde : vous avez maintenant introduit un véritable plan de contrôle de routage. Vous devez le sécuriser, le monitorer et le garder cohérent. Ça en vaut la peine, mais ce n’est pas gratuit.

Overlay + relais pour sites NATés — acceptez la réalité

Certains sites ne peuvent pas assurer une connectivité entrante stable. Dans ce cas, envisagez un relais (un VPS ou hub) que les deux côtés peuvent atteindre.
Ce n’est pas du « maillage pur », mais ça vous donne une connectivité fonctionnelle avec un comportement prévisible.

Faits intéressants et contexte historique

WireGuard a été créé par Jason A. Donenfeld au milieu des années 2010 avec l’objectif d’être petit, moderne et auditable comparé aux piles VPN traditionnelles.
L’intégration au noyau Linux est arrivée en 2020, ce qui a changé l’histoire opérationnelle : les mises à jour et les performances sont devenues plus faciles pour beaucoup d’équipes.
WireGuard utilise une poignée de main basée sur Noise (idées du cadre de protocole Noise), favorisant des primitives modernes et une complexité de négociation minimale.
Il évite intentionnellement l’agilité algorithmique — un choix historiquement controversé, mais qui réduit les rétrogradations et la complexité de configuration en production.
AllowedIPs est un mécanisme à double usage (routage + contrôle d’accès). Ce design est élégant et aussi la principale source de tickets « pourquoi le trafic va là ? ».
Les VPN en maillage complet prédatent WireGuard de décennies : les premières conceptions WAN d’entreprise cherchaient l’interconnexion any-to-any bien avant que le SD-WAN ne la rende populaire en marketing.
La douleur MTU est plus vieille que les VPN. Les problèmes de fragmentation sont apparus dans les premiers réseaux IP ; l’encapsulation VPN réintroduit simplement la même physique avec de nouveaux wrappers.
« Hub-and-spoke » est devenu populaire en partie grâce à la centralisation des pare-feux — il est plus facile d’auditer un point d’étranglement que 40 bords, surtout sous pression de conformité.
Les modes de défaillance opérationnels dominent généralement les modes de défaillance crypto dans les VPN matures : fuites de routage, hypothèses NAT, et lacunes de monitoring causent plus d’indisponibilités que la cryptographie.

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

Voici les tâches que j’exécute réellement quand je décide si un maillage se comporte, se comporte mal, ou complote tranquillement contre moi.
Chaque tâche inclut : une commande, une sortie d’exemple, ce que cela signifie, et la décision à prendre.

Task 1: Confirm WireGuard is up and handshaking

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

peer: 7y8N...aZk=
  endpoint: 198.51.100.10:51820
  allowed ips: 10.60.1.0/24, 10.60.200.2/32
  latest handshake: 32 seconds ago
  transfer: 1.21 GiB received, 980.45 MiB sent
  persistent keepalive: every 25 seconds

Ce que cela signifie : « latest handshake » récent et compteurs de transfert qui bougent indiquent que le tunnel est vivant.
Si le handshake est « never », vous avez des problèmes de reachability, NAT, pare-feu, ou de clefs incompatibles.

Décision : Si le handshake est obsolète/never, ne touchez pas encore au routage. Corrigez d’abord la reachability (pare-feu, UDP, endpoints, keepalive).

Task 2: Verify the interface has the right addresses

cr0x@server:~$ ip -br addr show dev wg0
wg0             UNKNOWN        10.60.200.1/24

Ce que cela signifie : L’IP de l’overlay est configurée. « UNKNOWN » est normal pour les interfaces WireGuard.

Décision : Si l’adresse manque ou est incorrecte, corrigez la config locale avant d’accuser le réseau.

Task 3: Confirm the kernel routes match your intent

cr0x@server:~$ ip route show table main | grep -E 'wg0|10\.60\.'
10.60.1.0/24 dev wg0 scope link
10.60.2.0/24 dev wg0 scope link
10.60.200.0/24 dev wg0 proto kernel scope link src 10.60.200.1

Ce que cela signifie : Des routes existent pointant des sous-réseaux vers wg0. Si vous utilisez wg-quick, il installera des routes basées sur AllowedIPs.

Décision : Si une route de sous-réseau manque, vérifiez AllowedIPs pour le peer qui doit la porter, ou votre démon de routage si vous utilisez BGP.

Task 4: Identify “route stealing” from overlapping AllowedIPs

cr0x@server:~$ sudo wg show wg0 allowed-ips
7y8N...aZk= 10.60.1.0/24 10.60.200.2/32
Jp2c...9Qs= 10.60.0.0/16 10.60.200.3/32

Ce que cela signifie : Un peer annonce 10.60.0.0/16, qui chevauche 10.60.1.0/24. WireGuard choisit le préfixe le plus spécifique, mais les préfixes larges sont un piège fréquent.

Décision : Retirez les AllowedIPs larges sauf si vous faites intentionnellement un « default via ce peer ». Soyez explicite par site.

Task 5: Check if NAT or firewall blocks UDP/51820

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

Ce que cela signifie : La machine écoute sur UDP/51820 sur toutes les interfaces.

Décision : Si rien n’écoute, vous déboguez un problème de service/config, pas un problème de chemin réseau.

Task 6: Validate firewall rules for the WireGuard port

cr0x@server:~$ sudo nft list ruleset | grep -n '51820'
117: udp dport 51820 accept

Ce que cela signifie : Il y a une règle d’autorisation. Si vous n’en voyez pas, supposez que c’est bloqué jusqu’à preuve du contraire.

Décision : Ajoutez des règles d’autorisation explicites et journalisez les drops temporairement si vous recherchez des handshakes intermittents.

Task 7: Test basic reachability across the tunnel (ICMP)

cr0x@server:~$ ping -c 3 10.60.200.2
PING 10.60.200.2 (10.60.200.2) 56(84) bytes of data.
64 bytes from 10.60.200.2: icmp_seq=1 ttl=64 time=8.12 ms
64 bytes from 10.60.200.2: icmp_seq=2 ttl=64 time=8.25 ms
64 bytes from 10.60.200.2: icmp_seq=3 ttl=64 time=8.09 ms

--- 10.60.200.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 8.089/8.155/8.246/0.070 ms

Ce que cela signifie : La connectivité L3 de base fonctionne et la latence est dans la plage attendue.

Décision : Si le ping fonctionne mais que les applications ne fonctionnent pas, suspectez MTU, TCP MSS, ou politique de pare-feu sur le trafic routé.

Task 8: Find MTU trouble with DF pings

cr0x@server:~$ ping -M do -s 1420 -c 2 10.60.200.2
PING 10.60.200.2 (10.60.200.2) 1420(1448) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 10.60.200.2 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1015ms

Ce que cela signifie : Le MTU de l’interface locale (ou une limitation du PMTU) empêche cette taille de paquet. L’overhead d’encapsulation rend cela courant.

Décision : Réduisez le MTU de wg0 (par exemple 1380 ou 1360), ou cloisonnez le TCP MSS sur le trafic routé. Ne devinez pas — testez les tailles jusqu’à ce que ça passe.

Task 9: Inspect path and where latency spikes (traceroute)

cr0x@server:~$ traceroute -n 10.60.2.10
traceroute to 10.60.2.10 (10.60.2.10), 30 hops max, 60 byte packets
 1  10.60.200.2  8.431 ms  8.207 ms  8.189 ms
 2  10.60.2.10    8.922 ms  8.743 ms  8.701 ms

Ce que cela signifie : Un chemin en deux sauts indique un routage propre via le peer. Si vous voyez des sauts inattendus (comme un hub), votre politique de routage ne fait pas ce que vous pensez.

Décision : Si le trafic fait du hairpin, corrigez la préférence de route (métriques, routage par politique, local-pref BGP) ou retirez les routes conflictuelles.

Task 10: Confirm forwarding is enabled (classic gotcha)

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 0

Ce que cela signifie : Le forwarding IPv4 est activé. Le forwarding IPv6 est désactivé (ce qui peut être correct ou expliquer des pannes IPv6 uniquement).

Décision : Si vous faites du routage entre des LANs de bureaux, vous voulez en général le forwarding activé sur vos routeurs VPN. Pour IPv6, décidez intentionnellement ; ne le noyez pas accidentellement.

Task 11: Watch packets to prove where they die

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.60.2.10 and tcp port 445 -c 6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:01:14.220123 IP 10.60.1.50.51234 > 10.60.2.10.445: Flags [S], seq 2209001, win 64240, options [mss 1360,sackOK,TS val 111 ecr 0], length 0
12:01:15.221004 IP 10.60.1.50.51234 > 10.60.2.10.445: Flags [S], seq 2209001, win 64240, options [mss 1360,sackOK,TS val 112 ecr 0], length 0
12:01:16.221998 IP 10.60.1.50.51234 > 10.60.2.10.445: Flags [S], seq 2209001, win 64240, options [mss 1360,sackOK,TS val 113 ecr 0], length 0

Ce que cela signifie : Retransmissions SYN sans SYN-ACK. Le trafic entre dans le tunnel mais ne reçoit pas de réponse.
C’est généralement un pare-feu côté distant, une route de retour manquante, ou un routage asymétrique provoquant des réponses sortant ailleurs.

Décision : Vérifiez le chemin de retour : routes sur le LAN de destination, politiques de pare-feu, et règles NAT. Si les réponses ne reviennent pas par le même chemin, corrigez la symétrie de routage.

Task 12: Detect asymmetric routing with policy rules

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.60.2.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Ce que cela signifie : Il y a une règle de politique forçant le trafic source de 10.60.2.0/24 à utiliser la table 100. Si la table 100 route vers Internet au lieu de wg0, vous avez bâti de l’asymétrie.

Décision : Assurez-vous que le routage par politique correspond à votre design VPN. Si vous faites un breakout Internet local, soyez explicite sur les chemins de retour pour le trafic inter-bureaux.

Task 13: Validate rp_filter isn’t dropping legitimate forwarded traffic

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.wg0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.wg0.rp_filter = 1

Ce que cela signifie : Le reverse path filtering strict peut dropper des paquets quand les chemins de retour ne correspondent pas à l’idée du noyau de la « meilleure route ». Ça mord les designs multi-homed et policy-routed.

Décision : Pour un routage complexe, mettez rp_filter à 2 (loose) sur les interfaces concernées, ou redesign pour la symétrie. Ne le désactivez pas partout sans réfléchir.

Task 14: Measure real throughput and spot CPU or MTU ceilings

cr0x@server:~$ iperf3 -c 10.60.200.2 -P 4 -t 10
Connecting to host 10.60.200.2, port 5201
[SUM]   0.00-10.00  sec  1.05 GBytes   902 Mbits/sec  0             sender
[SUM]   0.00-10.00  sec  1.04 GBytes   893 Mbits/sec  12             receiver

Ce que cela signifie : Vous obtenez ~900 Mbps avec peu de retransmissions. Si vous voyez des chiffres bien plus bas, vérifiez le CPU, le MTU, ou le shaping sur le WAN.

Décision : Si le CPU est saturé pendant iperf, votre routeur est sous-dimensionné ou vous avez besoin d’un offload matériel (ou simplement moins de tunnels sur ce nœud).

Task 15: Check CPU saturation during encryption

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (edge-a)  12/27/2025  _x86_64_  (4 CPU)

12:02:01 AM  CPU   %usr %nice %sys %iowait %irq %soft  %idle
12:02:02 AM  all   62.00  0.00  30.00   0.00  0.00  6.00   2.00
12:02:02 AM    0   78.00  0.00  20.00   0.00  0.00  2.00   0.00
12:02:02 AM    1   60.00  0.00  36.00   0.00  0.00  4.00   0.00
12:02:02 AM    2   55.00  0.00  35.00   0.00  0.00  8.00   2.00
12:02:02 AM    3   55.00  0.00  29.00   0.00  0.00  10.00  6.00

Ce que cela signifie : Vous manquez presque de CPU libre en poussant du trafic. WireGuard est efficace, mais il peut saturer des routeurs modestes à des débits élevés.

Décision : Augmentez la puissance matérielle, réduisez la concurrence, ou réduisez le nombre de tunnels à haut débit par nœud (hubs régionaux plutôt que maillage complet).

Task 16: Confirm MSS clamping if you do NAT or have MTU constraints

cr0x@server:~$ sudo iptables -t mangle -S | grep -E 'TCPMSS|wg0'
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Ce que cela signifie : Les paquets SYN ont leur MSS ajustée pour éviter des problèmes de fragmentation. Ça règle souvent des blocages d’applis que le ping ne montre pas.

Décision : Si vous voyez des blocages liés au MTU, ajoutez le clamping au bord VPN. Si vous l’avez déjà et que les problèmes persistent, testez le PMTU réel et réduisez le MTU de wg0.

Task 17: Verify that a peer’s endpoint is what you think it is

cr0x@server:~$ sudo wg show wg0 endpoints
7y8N...aZk= 198.51.100.10:51820

Ce que cela signifie : WireGuard montre l’endpoint courant utilisé. Si le peer bouge (changement NAT), cela se met à jour après réception de paquets.

Décision : Si l’endpoint est incorrect (IP ancienne), assurez-vous que le côté distant peut initier du trafic (keepalive) ou mettez à jour la gestion DNS/IP. Le maillage avec endpoints instables nécessite un plan.

Mode opératoire pour un diagnostic rapide

Quand le CEO dit « les bureaux entre eux sont lents » vous n’avez pas le temps pour un séminaire de philosophie. Vous avez besoin d’une séquence de triage qui vous mène vite au goulot.

Première étape : décidez si c’est un problème de tunnel ou de routage/chemin

Vérifiez le handshake et les compteurs : wg show. Si le handshake est obsolète/never, c’est reachability/NAT/pare-feu/clés.
Vérifiez où le trafic va : ip route get <dest> et traceroute -n. Si ça passe par le hub, c’est une préférence de routage ou des routes directes manquantes.
Capturez quelques paquets : tcpdump -ni wg0. Si des SYN sortent mais pas de SYN-ACK qui revient, c’est routage de retour ou pare-feu côté destination.

Deuxième étape : isolez MTU et fragmentation (le tueur silencieux)

Faites des DF pings avec tailles croissantes : ping -M do -s 1200/1300/1400.
Si ça échoue à des tailles modestes, réduisez le MTU de wg0 et/ou clamperez le MSS.
Retestez l’application réelle (SMB, HTTPS, RDP). Les bugs MTU adorent les illusions « ça marche pour les petites choses ».

Troisième étape : décidez si c’est débit, CPU, ou shaping WAN

Exécutez iperf3 à travers le tunnel pour une baseline.
Surveillez le CPU avec mpstat pendant le test.
Vérifiez la perte/jitter avec ping et les drops avec les compteurs d’interface (ip -s link).

Quatrième étape : vérifiez routage par politique et sabotage rp_filter

ip rule show pour les surprises de routage par politique.
sysctl net.ipv4.conf.all.rp_filter quand des chemins asymétriques existent.
Corrigez le design, pas seulement les symptômes. Mais si vous devez patcher, réglez rp_filter en loose sur les bonnes interfaces et documentez le pourquoi.

Petite blague #2 : Les problèmes MTU sont l’équivalent réseau du témoin « check engine » — vague, inquiétant, et d’une manière ou d’une autre toujours votre problème.

Erreurs courantes : symptôme → cause racine → correction

1) « Le tunnel est up, mais seules certaines applis fonctionnent »

Symptôme : Le ping et les petites requêtes HTTP fonctionnent ; SMB, SSH avec gros payloads, ou uploads HTTPS stagnent.
Cause racine : MTU/PMTUD en blackhole dû à l’overhead d’encapsulation ; ICMP « fragmentation needed » bloqué ; MSS non clampé.
Correction : Réglez le MTU de wg0 de façon conservatrice (souvent ~1380), et clamperez le MSS sur les paquets SYN TCP forwardés. Vérifiez avec des DF pings.

2) « Les handshakes s’arrêtent après quelques minutes sauf s’il y a du trafic »

Symptôme : Latest handshake devient obsolète ; le trafic reprend seulement après un ping manuel d’un côté.
Cause racine : Le mapping NAT expire ; aucun côté n’initie pour rafraîchir ; pas de keepalive sur le côté NATé.
Correction : Configurez PersistentKeepalive = 25 (ou similaire) sur le côté derrière NAT. Assurez-vous que le pare-feu autorise les retours UDP.

3) « Le trafic vers le Bureau B va au Bureau C et meurt »

Symptôme : Le mauvais peer reçoit le trafic ; traceroute montre un premier saut inattendu ; tcpdump montre des paquets sortant par le mauvais tunnel.
Cause racine : AllowedIPs chevauchants ou préfixes larges installés par commodité ; vol de route par un résumé trop général combiné aux métriques OS.
Correction : Rendez AllowedIPs précis par sous-réseau site ; évitez 0.0.0.0/0 et les grands synthèses sauf si vous le voulez vraiment. Auditez avec wg show allowed-ips.

4) « Ça marche de A vers B, mais pas de B vers A »

Symptôme : Flux unidirectionnels ; SYNs vus dans un sens seulement ; réponses qui sortent via Internet ou un autre WAN.
Cause racine : Routage asymétrique dû au routage par politique, dual WAN, ou routes de retour manquantes sur les routeurs LAN.
Correction : Assurez-vous que le chemin de retour pointe vers le routeur WireGuard ; utilisez le routage basé source avec précaution ; considérez des tables de routage par source par sous-réseau.

5) « Après l’ajout d’un nouveau bureau, d’autres bureaux cassent au hasard »

Symptôme : L’ajout d’un peer provoque des pertes de connectivité non liées ; blackholes intermittents.
Cause racine : Chevauchement d’adresses (IP de tunnel dupliquées ou LANs en doublon), ou AllowedIPs incluant accidentellement le sous-réseau de quelqu’un d’autre.
Correction : Imposer un IPAM pour overlay et plages LAN ; rejeter les allocations dupliquées dans le CI ; exécuter un check de chevauchement de routes avant le déploiement.

6) « Le débit est terrible mais le CPU est ok »

Symptôme : iperf montre des Mbps faibles ; CPU idle ; pics de perte de paquets ; performance variable selon l’heure.
Cause racine : Shaping WAN, bufferbloat, ou ISP congestionné ; parfois police UDP sur le broadband entreprise.
Correction : Confirmez avec des tests soutenus ; ajoutez QoS/SQM au bord ; considérez plusieurs WANs avec basculement ; ne blâmez pas WireGuard pour la personnalité de votre FAI.

7) « Tout casse pendant la rotation des clés »

Symptôme : Certains tunnels reviennent, d’autres non ; les handshakes ne reprennent pas pour un sous-ensemble.
Cause racine : Déploiement incohérent de config ; anciennes clés publiques encore référencées ; configs obsolètes non rechargées ; automatisation partielle.
Correction : Faites une rotation en approche par étapes (ajoutez les nouvelles clés en parallèle quand possible), rechargez de façon déterministe, et vérifiez les handshakes avec des contrôles automatisés.

Trois mini-histoires d’entreprise du terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne est passée de six à onze bureaux en moins d’un an. L’équipe réseau a décidé de « finir ce qu’on avait commencé » et de construire un maillage complet avec des configs WireGuard statiques.
Leur hypothèse : « Ce sont des bureaux ; les IP publiques sont stables. » C’était vrai pour les sites fibre. C’était hilarantement faux pour les deux nouveaux emplacements utilisant un broadband « temporaire » devenu permanent.

Un lundi matin, deux bureaux ont perdu la reachability vers trois autres. Pas tous. Juste assez pour créer un bazar de services à moitié fonctionnels : présence téléphonique en défaut, mais les appels fonctionnaient parfois ; partages de fichiers mappés mais impossibles à ouvrir ; imprimantes affichées hors ligne.
Le tableau de bord de monitoring était vert parce que les tunnels hub étaient ok, et l’équipe avait construit des checks qui validaient seulement branche-vers-hub.

La cause racine était banale : ces circuits broadband ont changé d’IP pendant le week-end. Certains peers ont mis à jour leurs endpoints via le roaming (parce que le côté NATé a initié du trafic), et d’autres ne l’ont pas fait (parce que les autres sites n’ont jamais initié).
Donc la moitié du maillage a convergé et l’autre moitié est restée gelée avec « latest handshake: 3 days ago. »

La correction n’a pas été juste « régler PersistentKeepalive ». Ils ont aussi introduit une règle de conception : tout site sans endpoint stable ne participe pas en tant que nœud maillé de première classe.
Ces sites se connectent à un petit ensemble de hubs de rendez-vous stables. Les connexions directes bureau-à-bureau sont autorisées uniquement entre sites stables ou via un relais contrôlé.

La leçon : le maillage suppose une symétrie de reachability et une découverte stable. Si vous n’avez pas ça, vous ne construisez pas un maillage ; vous construisez un jeu de devinettes distribué.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre entreprise avait un VPN hub-and-spoke et détestait la latence entre deux régions.
Quelqu’un a proposé un « gain simple » : ajouter des tunnels directs entre tous les bureaux de la Région Est et tous les bureaux de la Région Ouest. Ça paraissait raisonnable — jusqu’à ce que ça rencontre des résumés BGP et l’optimisme humain.

Ils utilisaient déjà du routage dynamique dans le datacenter. Pour éviter d’annoncer des dizaines de petits sous-réseaux, ils résumaient des routes à chaque frontière de bureau.
Puis ils ont activé les liens maillés inter-régions et importé les résumés sans filtres stricts, parce que la fenêtre de changement était courte et que le plan de rollback était essentiellement « l’éteindre et faire comme si rien ne s’était passé ».

Pendant une semaine, tout allait bien. Puis un routeur de bureau dans la Région Est a mal annoncé un résumé à cause d’un bug dans un template de config.
Soudain, le trafic pour une grosse partie de la Région Est a commencé à circuler vers le mauvais bureau, via un lien maillé, et a été ensuite rejeté par un pare-feu qui n’attendait jamais du transit.

La panne a été douloureuse parce qu’elle ressemblait d’abord à une « lenteur SaaS aléatoire ». Les graphes WAN étaient normaux ; le hub était sain ; seulement un sous-ensemble d’applis internes échouait.
Il a fallu une capture de paquets et un diff de tables de routage pour repérer le mauvais résumé.

Ils ont gardé les liens maillés, mais ont arrêté de traiter la politique de routage comme une quête annexe.
Des filtres de préfixes stricts, des limites max-prefix, et la validation de routes sont devenus non négociables. L’optimisation était correcte ; l’absence de garde-fous ne l’était pas.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise avec neuf bureaux a exécuté un maillage partiel : hubs régionaux plus quelques tunnels directs pour les applis sensibles à la latence.
Ce n’était pas glamour. C’était documenté. Rien que ça les a mis en avant par rapport à la plupart de l’industrie.

Leur « pratique ennuyeuse » était un audit automatisé hebdomadaire : exporter wg show, les tables de routage, et les règles de pare-feu en snapshot, puis diff par rapport à la semaine précédente.
La sortie allait dans une file de tickets que personne n’aimait, mais ça rendait la dérive visible.

Un après-midi, un technicien helpdesk faisant du « nettoyage » a supprimé ce qui semblait être une route statique inutilisée sur un routeur de bureau.
En quelques minutes, un système de gestion d’entrepôt a cessé de synchroniser les mises à jour d’inventaire vers un autre site. Les utilisateurs ont blâmé l’application. Bien sûr.

Le diff d’audit a signalé la route supprimée et pointé l’appareil et l’heure exacts. La correction a été immédiate : restauration de la route et ajout d’un commentaire dans la config expliquant pourquoi elle existait.
L’incident n’est jamais devenu une fête de blâme multi-équipes parce que la preuve était là, ennuyeuse et précise.

La leçon : le maillage ne casse pas seulement parce qu’il est complexe. Il casse parce que les gens oublient pourquoi les choses existent. Faites en sorte que le réseau s’explique lui-même.

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

Décidez si vous devez faire un maillage complet

Listez les flux inter-bureaux principaux : VoIP, SMB, ERP, réplication de base de données, trafic de sauvegarde. Mettez une estimation de bande passante et de sensibilité à la latence à côté de chaque flux.
Comptez les sites maintenant et dans 18 mois. Si vous dépassez ~15, supposez que vous aurez besoin d’automatisation de routage et/ou d’un maillage partiel.
Classez les endpoints : IP publique stable, IP dynamique, derrière CGNAT, dual WAN, backup LTE. Le maillage déteste l’incertitude.
Décidez votre modèle de sécurité : any-to-any plat, segmenté, ou « seulement certaines applis ». Maillage + segmentation exige une discipline politique.
Choisissez intentionnellement les domaines de panne : voulez-vous « panne du hub impacte tout », ou « panne de tunnel paire impacte deux » ?

Construisez-le comme vous prévoyez de l’exploiter

Allouez les IPs d’overlay via un IPAM (même un registre simple géré en Git). Ne « choisissez jamais au hasard ».
Standardisez le nommage des interfaces : wg0 pour site-à-site, wg-mgmt pour la gestion, etc. La cohérence vous fait gagner du temps en incident.
Générez les configs à partir d’une source de vérité. Les configs maillées éditées à la main sont un plan de retraite pour votre futur thérapeute.
Définissez des patterns AllowedIPs : préfixes LAN par site seulement ; évitez les grands résumés sauf s’ils sont soutenus par une politique de routage et une revue.
Fixez le MTU intentionnellement et documentez le raisonnement. Si vous ne le faites pas, vous le redécouvrirez pendant une panne, ce qui coûte cher.
Planifiez la rotation des clés : calendrier, rayon d’impact, et étapes de vérification. Faites-en une procédure, pas un rituel.

Exploitez-le avec des garde-fous

Monitoring : alertez sur les handshakes obsolètes pour les peers critiques, la montée de la perte de paquets, et la saturation CPU sur les routeurs VPN.
Gestion des changements : chaque ajout/suppression de site doit être reproductible et révocable. Le maillage amplifie les erreurs.
Test : après chaque changement, exécutez ping/DF ping/iperf vers au moins un peer et un hôte LAN distant.
Détection de dérive : snapshot des configs et de l’état de routage ; diff régulièrement. « Nous n’avons rien changé » est généralement faux.

FAQ

1) Le maillage complet WireGuard est-il plus sûr que le hub-and-spoke ?

Pas intrinsèquement. La sécurité WireGuard dépend de la gestion des clés et des restrictions des peers. Le maillage peut augmenter la surface d’attaque car il y a plus de bords et plus d’endroits pour mal configurer AllowedIPs ou des règles de pare-feu.
Si vous faites du maillage, traitez la politique comme primordiale : restreignez les routes, appliquez la segmentation, et auditez régulièrement.

2) Quel est le plus grand avantage pratique des tunnels directs bureau-à-bureau ?

La réduction de la latence et du jitter pour le trafic inter-bureaux. Si le hub est géographiquement excentré ou congestionné, les tunnels directs peuvent transformer « à peine utilisable » en « correct ».

3) Quel est le principal inconvénient opérationnel du maillage complet ?

Le nombre de peers et le rayon d’impact des changements. Ajouter un site devient une mise à jour multi-peer. La rotation des clés et le troubleshooting deviennent des problèmes combinatoires à moins d’automatiser et de monitorer sérieusement.

4) Combien de sites est « trop » pour un maillage complet statique ?

En gros : au-delà de 10–15 sites, le maillage statique devient pénible sauf si votre automatisation et discipline de routage sont excellentes. Au-delà de 20, vous voulez généralement du routage dynamique et/ou des hubs régionaux.

5) Dois-je exécuter BGP sur WireGuard ?

Si vous avez besoin d’échelle, de basculement et de moins de tracas avec des routes statiques, oui — BGP (via FRR) est un bon choix. Mais ce n’est pas magique.
Vous devez implémenter des filtres de préfixes, des limites max-prefix, et du monitoring, sinon vous transformerez un bug de routage en indisponibilité à l’échelle de l’entreprise.

6) Comment gérer les bureaux avec IPs dynamiques ?

Utilisez PersistentKeepalive sur le côté NATé pour qu’il puisse roam et maintenir le mapping NAT, et préférez des points de rendez-vous stables (hubs/relais) pour ces sites.
Attendez-vous à ce que « maillage pur partout » soit fragile si plusieurs sites ont des endpoints instables.

7) Puis-je faire des tunnels active-active entre bureaux ?

Pas avec WireGuard seul. WireGuard vous donne des liens chiffrés ; le routage décide comment les utiliser.
L’active-active se fait typiquement avec de l’ECMP via un démon de routage, ou de l’équilibrage applicatif. Attention : ECMP plus chemins asymétriques peuvent perturber des pare-feux et middleboxes stateful.

8) Pourquoi WireGuard utilise AllowedIPs pour le routage ?

C’est un choix de design pour garder WireGuard minimal : il décide quel peer doit recevoir un paquet en se basant sur le préfixe de destination.
Ça réduit la surface de configuration mais rend la justesse de la configuration de votre responsabilité. Traitez AllowedIPs comme du code de production.

9) Dois-je NATer le trafic à travers des tunnels site-à-site ?

Évitez si possible. Le NAT cache les erreurs d’adressage jusqu’à ce qu’elles deviennent des incidents. Routez des préfixes réels quand c’est possible.
Le NAT est utile parfois pour des chevauchements d’espaces RFC1918 lors de fusions, mais traitez-le comme un outil transitoire avec une date d’expiration.

10) Quelle est la manière la plus propre d’éviter les réseaux LAN qui se chevauchent ?

Établissez tôt une norme d’adressage (allocations par site) et appliquez-la avec un IPAM et une revue. Les chevauchements sont une des principales causes du comportement « le maillage est hanté ».

Étapes pratiques suivantes

Si vous hésitez à construire des tunnels directs WireGuard bureau-à-bureau, faites ceci dans l’ordre :

Mesurez la latence de hairpin actuelle et le jitter entre les bureaux qui se plaignent le plus.
Prototypiez un tunnel direct entre deux sites et validez : stabilité du handshake, MTU, débit, et routage de retour.
Choisissez une topologie basée sur le nombre de sites et la stabilité des endpoints : maillage complet (petit/stable), maillage partiel (régional), ou double hubs (souvent le meilleur compromis).
Automatisez la génération des configs avant de dépasser une poignée de sites. Si vous attendez, vous ne rattraperez jamais le retard.
Installez des garde-fous : filtres de routes, contrôles de sanity des préfixes, détection de dérive, et une politique MTU/MSS standard.
Rédigez le runbook tant que ça semble encore évident. Le vous du futur sera fatigué et méfiant pendant la panne.

Les tunnels directs valent le coup quand ils éliminent un vrai goulot d’étranglement et que vous pouvez garder le modèle opérationnel propre.
Ils ne valent pas le coup quand vous les utilisez pour éviter de choisir une architecture réseau. Votre topologie choisira une pour vous — généralement pendant une fenêtre de changement un vendredi.