Trois bureaux. Chacun a son propre circuit Internet, ses petites particularités locales et sa personne qui « a juste besoin d’accéder à l’autre site ».
Vous configurez un VPN site-à-site, puis un autre, et soudain vous jonglez avec des routes, des règles de pare-feu, des bizarreries DNS et une imprimante qui ne tombe en panne que le mardi.
Un VPN full-mesh semble être la solution adulte : tout le monde communique directement avec tout le monde. Parfois c’est vrai. Parfois c’est une manière coûteuse de créer
un générateur d’incidents distribué. Décidons dans quel monde vous êtes — et comment l’exploiter sans devenir la table de routage humaine.
Ce que « full-mesh » signifie réellement pour 3 bureaux (et ce que ce n’est pas)
Avec trois sites — appelons-les NYC, DAL, SFO — un maillage complet signifie que vous construisez
trois tunnels site-à-site : NYC↔DAL, DAL↔SFO, SFO↔NYC. Chaque site dispose d’un chemin chiffré direct vers les autres.
Pas de détours par un hub central.
C’est la partie que les vendeurs aiment mettre dans un joli schéma triangulaire. Dans la vraie vie, un « full mesh » n’est pas seulement des tunnels. C’est :
- Politique de routage : quels préfixes sont annoncés où, et ce qui l’emporte quand plusieurs chemins existent.
- Politique de sécurité : ce qui est autorisé est-ouest entre les bureaux.
- Politique opérationnelle : comment déployer des changements sans casser la moitié de votre WAN.
- Identité et nommage : DNS, split-horizon, topologie AD site, ou tout ce que fait votre pile d’authentification.
Pour trois bureaux, un full-mesh n’est pas automatiquement « complexe ». Il est facile à rendre complexe. C’est la distinction qui compte.
Petit calcul : pourquoi la douleur augmente
Le nombre de tunnels dans un full mesh est n(n−1)/2. Avec 3 sites : 3 tunnels. Avec 6 sites : 15. Avec 10 sites : 45.
La plupart des équipes peuvent maintenir 3 tunnels en bonne santé. Beaucoup ne peuvent pas garder 15 tunnels cohérents sans automatisation et télémétrie.
Faits intéressants et un peu d’histoire (parce que vous hériterez d’idées anciennes)
- Fait 1 : IPsec est né dans les années 1990 comme partie de la sécurité IPv6, mais a été largement adopté sur IPv4 parce que… réalité.
- Fait 2 : Le « NAT traversal » (UDP 4500) existe parce que IPsec ESP ne s’entendait pas bien avec le NAT ; ce n’était pas un luxe, c’était de la survie.
- Fait 3 : Beaucoup de produits « site-à-site VPN » héritent encore d’une vision issue des jours des lignes louées : points de terminaison stables, chemins prévisibles, moins de rekeys.
- Fait 4 : BGP est devenu le standard pour le routage WAN dynamique non pas parce qu’il est sympathique, mais parce qu’il est brutalement explicite sur les chemins et les politiques.
- Fait 5 : Le bazar MTU/MSS dans les VPNs existe depuis des décennies ; ce n’est pas un problème « ère cloud » — PPP, GRE et IPsec ont tous leur lot de paquets cassés.
- Fait 6 : Le DNS split-horizon précède le « zero trust » de plusieurs années ; c’est un vieil outil toujours pertinent quand différents réseaux doivent obtenir des réponses différentes.
- Fait 7 : Le grand avantage du SD-WAN n’était pas le chiffrement (les VPNs le faisaient déjà) ; c’était le contrôle centralisé, l’observabilité et la sélection de chemin face à la perte/jitter.
- Fait 8 : Les topologies « full mesh » étaient courantes dans les premiers WANs d’entreprise utilisant Frame Relay PVC — puis tout le monde a rappelé la facturation et est passé aux hubs.
Quand vous avez réellement besoin d’un full-mesh
Vous avez besoin d’un full mesh quand les chemins directs sont véritablement meilleurs pour votre activité et que vous ne pouvez pas obtenir ce résultat de manière fiable avec un hub-and-spoke.
« Matériellement meilleur » signifie latence, bande passante, domaines de disponibilité ou isolation des pannes. Pas des impressions.
1) Votre trafic est réellement site-à-site, pas site-vers-datacenter
Si les utilisateurs à NYC accèdent constamment aux serveurs de fichiers à DAL, et que DAL exécute constamment des build runners à SFO, envoyer tout cela via un hub revient
à faire transiter le courrier local par un autre État « pour la visibilité ». Votre hub devient une taxe.
2) Vous avez besoin d’isolation des pannes entre sites
Dans un hub-and-spoke, le hub est un domaine de défaillance partagé : DDoS sur le circuit du hub, mise à jour du pare-feu du hub, push de politique raté — tout le monde le ressent.
Un maillage peut maintenir NYC↔DAL quand SFO connaît une journée mouvementée.
3) Vous avez plusieurs circuits Internet et voulez de meilleurs choix de chemin
Si chaque bureau a son propre Internet solide, un maillage permet à chaque paire d’utiliser le meilleur chemin entre elles. Vous pouvez toujours le faire avec un hub si vous
acceptez le hairpin et implémentez du policy routing astucieux, mais vous choisissez alors la complexité — au moins tirez parti du bénéfice en latence.
4) Vous avez des exigences réglementaires de segmentation entre sites
Ça semble contre-intuitif (« maillage = plus de confiance »), mais si vous le faites correctement, le maillage peut réduire l’exposition en n’acheminant pas tout via un hub
où tout se mélange. Vous pouvez appliquer des politiques par paire : DAL peut atteindre la finance de NYC, mais pas le laboratoire de NYC ; SFO peut atteindre le SSO de NYC, mais pas DAL OT.
5) Vous pouvez l’exploiter comme un système, pas comme un projet ponctuel
Le full mesh est un engagement opérationnel. Si vous n’avez pas de supervision, de versioning de config et de processus de changement, vous construisez un joli triangle
qui deviendra de l’art moderne la première fois que quelqu’un change un CPE ISP.
Idée paraphrasée (John Allspaw) : la fiabilité vient de la manière dont le travail est fait en conditions réelles, pas de plans parfaits
.
Les VPNs en maillage punissent la pensée « plan parfait ».
Quand le full-mesh n’est pas l’outil adapté
La raison la plus courante pour laquelle les équipes choisissent le full mesh est émotionnelle : « Je ne veux pas de hub. » Juste. Mais éviter un hub en créant trois tunnels indépendants,
gérés de façon incohérente, n’est pas une stratégie. C’est un passe-temps.
Ne faites pas de full-mesh si vous avez vraiment un site central
Si la plupart du trafic est « succursale vers systèmes HQ », construisez un hub-and-spoke. R Rendez le hub redondant. Donnez-lui plusieurs uplinks. Supervisez-le agressivement.
Vous obtiendrez une politique plus simple et un meilleur contrôle du rayon d’impact.
Ne faites pas de full-mesh si vous ne pouvez pas standardiser l’équipement et les configurations
Si NYC utilise un appareil pare-feu, DAL un box Linux que quelqu’un a appelé « vpn1 », et SFO un routeur cloud avec une pile IKE différente,
vous vous engagez à déboguer trois dialectes du même protocole. Ce n’est pas de l’ingénierie. C’est de la linguistique.
Ne faites pas de full-mesh si votre problème est « accès distant »
Le site-à-site pour les réseaux. L’accès distant est pour les personnes et les appareils. Si vous essayez de résoudre l’accès d’un portable à un bureau en maillant les bureaux,
vous vous retrouverez avec un réseau parfaitement connecté qui ne sait toujours pas qui est l’utilisateur.
Blague #1 : Un full mesh, c’est comme un chat de groupe — génial jusqu’à ce que quelqu’un ajoute l’imprimante, et soudain tout le monde reçoit des notifications à 3 h du matin.
Options de conception : IPsec, WireGuard, SD-WAN et « économique »
Option A : IPsec (IKEv2) site-à-site
IPsec est ennuyeux dans le bon sens : largement supporté, interopérable, compris par les pare-feu et généralement acceptable pour les auditeurs.
Il est aussi rempli de réglages qui peuvent vous nuire : propositions, durées, DPD, NAT-T, PFS, comportement de fragmentation et « serviabilité » des vendeurs.
Si vous optez pour IPsec, privilégiez :
- IKEv2 plutôt qu’IKEv1. Moins de fantômes.
- Tunnels basés sur des routes (VTI) plutôt que policy-based lorsque possible. Le routage doit rester au routage.
- Propositions cohérentes sur tous les tunnels, idéalement une suite unique que vos équipements gèrent bien.
Option B : WireGuard site-à-site
WireGuard est plaisant opérationnellement : configuration minimale, rékey rapide et philosophie « faire moins ». Ce n’est pas un protocole de routage.
Vous devez toujours décider comment propager les routes et comment empêcher les AllowedIPs de devenir votre table de routage globale accidentelle.
Pour trois sites, WireGuard peut être excellent si :
- Vous contrôlez les deux extrémités (routeurs Linux ou appliances qui le supportent bien).
- Vous pouvez standardiser la posture du pare-feu et la supervision.
- Vous êtes à l’aise de gérer le routage dynamique séparément (routes statiques ou BGP/OSPF au-dessus).
Option C : SD-WAN (politique gérée + overlays)
Le SD-WAN s’achète quand vous voulez moins de réseau sur-mesure et plus d’opérations répétables. Il vous offre une politique centralisée, la sélection de chemin
et une meilleure observabilité. Vous payez en licences et en faisant du « contrôleur » une partie de la production.
Pour trois bureaux, le SD-WAN peut être excessif — sauf si vous êtes en croissance, avez plusieurs circuits par site ou avez besoin d’un steering applicatif.
Option D : Hub-and-spoke avec routage intelligent (souvent le compromis correct)
Si vous voulez du « presque direct » sans la complexité complète du maillage, faites du hub-and-spoke avec :
- Hubs redondants (active/active ou active/passive).
- BGP entre sites et hubs.
- Politique qui favorise le breakout local pour l’internet et préfère le hub pour les services centraux.
Vous obtenez une topologie gérable et évitez tout de même certains hairpins pour le trafic Internet.
Routage, DNS et identité : où le full-mesh échoue en pratique
Modèle de routage : routes statiques vs routage dynamique
Pour trois bureaux, les routes statiques peuvent fonctionner. Elles pourrissent aussi silencieusement.
Dès que vous ajoutez un nouveau sous-réseau, changez une plage LAN ou introduisez un deuxième circuit, vous trouverez le tunnel qui n’a pas été mis à jour.
Ce n’est pas hypothétique. C’est mardi.
Le routage dynamique (typiquement BGP) sur des tunnels basés sur des routes est l’option « adulte » :
- Les routes se propagent automatiquement.
- Vous pouvez exprimer préférence et politique de basculement.
- Vous pouvez filtrer ce que chaque site apprend (vital pour la segmentation).
Choisir l’approche de routage pour exactement trois sites
Voici l’avis tranché :
- Routes statiques suffisent si chaque bureau a un seul préfixe LAN, pas de réseaux qui se chevauchent et que vous n’ajouterez pas de sites bientôt.
- BGP vaut le coup si un bureau a plusieurs segments internes, si vous voulez un basculement propre ou si vous prévoyez de dépasser trois sites.
DNS split-horizon : l’exigence silencieuse
La plupart des douleurs inter-sites ne viennent pas de la connectivité IP. Elles viennent de la résolution de noms et de la découverte de services :
- Le DNS de NYC renvoie une IP interne que seul NYC peut atteindre à moins que les routes soient correctes.
- Les clients de DAL résolvent « fileserver » vers le mauvais site parce que quelqu’un a configuré un suffixe de recherche et s’en est contenté.
- Le split tunneling SaaS envoie le DNS d’un côté et le trafic de l’autre, et ensuite vous obtenez « ça marche sur mon téléphone ».
Décidez si vous voulez :
- Vue DNS interne unique (tous les bureaux voient les mêmes réponses internes), ou
- DNS conscient du site (les réponses varient selon le site source, généralement pour garder les clients locaux).
Le DNS conscient du site est puissant. C’est aussi la manière dont vous construisez accidentellement un système distribué sans vous en rendre compte.
Plages qui se chevauchent : le mensonge « on ne le fera jamais »
Si un bureau utilise de l’espace RFC1918 qui chevauche un autre bureau — ou un réseau partenaire — vous allez passer un mauvais moment.
Renumérotation douloureuse ; mais le NAT-over-VPN est pire à long terme car il fuit dans les configurations applicatives et le dépannage.
Contrôles de sécurité pour empêcher que le maillage devienne un paradis pour le mouvement latéral
Un full mesh augmente la connectivité. Les attaquants adorent la connectivité.
Votre travail est de faire en sorte que le maillage augmente la connectivité intentionnelle, pas la confiance accidentelle.
Principe : annoncer tout ce dont vous avez besoin, autoriser presque rien par défaut
Routage et firewalling sont des couches différentes. Vous pouvez annoncer des routes largement (pour la simplicité) et appliquer une politique stricte au L3/L4.
Ou vous pouvez filtrer les routes sévèrement et garder les règles de pare-feu plus simples. Choisissez l’un comme plan de contrôle principal et soyez cohérent.
Contrôles de base recommandés
- ACL inter-sites par zone (LAN utilisateur, LAN serveur, management, voix, OT).
- Isolation du plan de management : les passerelles VPN doivent avoir une interface ou un sous-réseau de gestion dédié, pas « admin depuis n’importe où ».
- Journalisation des refus sur le VPN, avec échantillonnage ou limites de débit pour ne pas DDoS votre SIEM.
- Rotation des clés et hygiène des certificats : les PSK vivent souvent éternellement ; les certificats obligent les adultes à intervenir.
Pattern de segmentation qui fonctionne
Utilisez des zones et des listes d’autorisations explicites :
- NYC-users → DAL-apps : autoriser 443, 22 (vers bastion uniquement), 445 (seulement vers le cluster de fichiers), refuser le reste.
- DAL-users → SFO-users : refuser (la plupart des organisations n’ont pas besoin d’un « LAN utilisateur vers LAN utilisateur » du tout).
- Tous-sites → monitoring : autoriser uniquement vers les endpoints centraux de métriques/logs.
Blague #2 : Si vous autorisez « any-any » entre les bureaux « juste pour l’instant », félicitations — vous avez inventé une machine à remonter le temps où « l’instant » dure trois ans.
Garder la solution gérable : nommage, automatisation, supervision, contrôle des changements
Standardisez les primitives
Choisissez un modèle cohérent et tenez-vous-y :
- Tunnels basés sur des routes avec des VTI nommés de façon prévisible (par ex.,
vti-nyc-dal). - Plages cohérentes par site (évitez les astuces). Exemple : NYC=10.10.0.0/16, DAL=10.20.0.0/16, SFO=10.30.0.0/16.
- ASNs BGP cohérents si vous utilisez BGP : AS privés par site, documentés.
- Disposition de zones pare-feu cohérente : users, servers, management, guest.
Rendez la configuration diffable
Si votre config VPN ne vit que dans une UI web, vous n’avez pas de gestion de configuration — vous avez de l’espoir.
Exportez la config, stockez-la dans un contrôle de version et traitez les changements comme du code même si le « code » est la syntaxe du vendeur.
Supervision : mesurez ce qui casse en premier
Les VPNs échouent de façon ennuyeuse :
- La perte de paquets et le jitter cassent la voix/VDI avant que « le tunnel soit down ».
- Les problèmes MTU cassent des applications spécifiques (SMB, certains HTTPS) alors que le ping fonctionne.
- Les rekeys provoquent des flapping et causent de brèves baisses que les utilisateurs décrivent comme « aléatoires ».
Surveillez :
- État des tunnels (IKE SA, child SA, santé des handshakes).
- Latence/perte entre sites (pas seulement vers Internet).
- Débit et drops sur l’interface VPN et l’interface WAN.
- Adiacence de routage (session BGP up/down, changement du nombre de routes).
Contrôle des changements qui ne vous déteste pas
Vous n’avez pas besoin d’une bureaucratie. Vous avez besoin d’une habitude :
- Effectuer les changements pendant une fenêtre.
- Avoir un plan de rollback réel (config sauvegardée, procédure testée).
- Changer un tunnel à la fois sauf si vous faites une bascule coordonnée.
- Après le changement : vérifier le routage, vérifier le DNS, vérifier un vrai flux applicatif.
Playbook de diagnostic rapide
Quand « le VPN est lent » ou « le site B ne peut pas joindre le site C », vous n’avez pas le temps pour une discussion philosophique sur la topologie.
Vous devez trouver le goulot rapidement. Voici l’ordre qui fonctionne en production.
Première étape : est-ce vraiment le VPN ?
- Vérifiez si le problème est spécifique à une application (SMB vs HTTPS vs RDP).
- Vérifiez si c’est seulement dans un sens (routage asymétrique, état du pare-feu).
- Vérifiez si c’est une paire de sites seulement (NYC↔DAL OK, DAL↔SFO cassé).
Deuxième : la santé de l’underlay (le chemin ISP) prime sur les arguments overlay
- Mesurez la perte et la latence entre les endpoints publics des passerelles VPN.
- Recherchez des rafales de perte, pas des moyennes.
- Confirmez que personne ne sature l’uplink (sauvegardes, sync cloud, réunion vidéo surprise).
Troisième : santé du tunnel et du crypto
- L’IKE SA est-il stable, ou y a-t-il des rekeys/flapping ?
- Y a-t-il des retransmissions, des drops de fragmentation, des problèmes NAT-T ?
- Le offload matériel est-il actif (si pertinent), ou une mise à jour de firmware l’a-t-elle désactivé ?
Quatrième : routage et MTU (les deux tueurs silencieux)
- Routage : vérifiez le next-hop et assurez-vous qu’il n’y a pas de boucles hairpin.
- MTU : testez avec DF ; clamperez MSS si nécessaire.
Cinquième : politique (pare-feu) et identité (DNS/AD)
- Refus de pare-feu entre zones. Cherchez les refus implicites.
- DNS renvoyant des cibles inatteignables ; mappings AD erronés ; DNS en split-brain.
Tâches pratiques : commandes, sorties attendues et décisions à prendre
Ci-dessous des tâches pratiques que vous pouvez exécuter depuis des passerelles VPN basées sur Linux ou des hôtes de diagnostic sur chaque site.
L’essentiel n’est pas la commande ; c’est la boucle : observer → interpréter → décider.
Tâche 1 : Confirmer la reachabilité basique entre les passerelles de site (underlay)
cr0x@server:~$ ping -c 5 203.0.113.20
PING 203.0.113.20 (203.0.113.20) 56(84) bytes of data.
64 bytes from 203.0.113.20: icmp_seq=1 ttl=54 time=18.7 ms
64 bytes from 203.0.113.20: icmp_seq=2 ttl=54 time=19.1 ms
64 bytes from 203.0.113.20: icmp_seq=3 ttl=54 time=18.6 ms
64 bytes from 203.0.113.20: icmp_seq=4 ttl=54 time=120.3 ms
64 bytes from 203.0.113.20: icmp_seq=5 ttl=54 time=19.0 ms
--- 203.0.113.20 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 18.6/39.1/120.3/40.6 ms
Ce que cela signifie : Pas de perte de paquets, mais un pic de latence suggère du jitter ou de la congestion transitoire.
Décision : Si les pics corrèlent avec « le VPN est lent », enquêtez sur le chemin ISP, la saturation ou le bufferbloat avant de toucher aux réglages VPN.
Tâche 2 : Tracer le chemin public pour détecter des détours étranges
cr0x@server:~$ traceroute -n 203.0.113.20
traceroute to 203.0.113.20 (203.0.113.20), 30 hops max, 60 byte packets
1 198.51.100.1 1.012 ms 0.941 ms 0.915 ms
2 198.51.100.9 3.122 ms 3.101 ms 3.094 ms
3 203.0.113.1 9.884 ms 9.860 ms 9.841 ms
4 203.0.113.20 18.992 ms 18.970 ms 18.948 ms
Ce que cela signifie : Chemin court, sauts stables. Si vous voyez des chemins soudainement longs ou des timeouts, l’underlay est suspect.
Décision : Si le chemin a changé récemment, ouvrez un ticket auprès de l’ISP ou basculez sur un circuit secondaire si vous en avez un.
Tâche 3 : Vérifier les interfaces de tunnel et les compteurs (santé de l’overlay)
cr0x@server:~$ ip -s link show dev vti-nyc-dal
6: vti-nyc-dal: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
RX: bytes packets errors dropped overrun mcast
987654321 1234567 0 12 0 0
TX: bytes packets errors dropped carrier collsns
876543210 1122334 0 0 0 0
Ce que cela signifie : Les drops en RX sur le tunnel pointent souvent vers des problèmes MTU, de queueing ou des drops de politique en amont.
Décision : Si les drops augmentent durant les plaintes, passez aux tests MTU/MSS et vérifiez les logs du pare-feu pour des drops sur la VTI.
Tâche 4 : Vérifier la route vers un sous-réseau distant (correction du routage)
cr0x@server:~$ ip route get 10.30.5.10
10.30.5.10 via 169.254.30.1 dev vti-nyc-sfo src 10.10.0.1 uid 0
cache
Ce que cela signifie : Le kernel enverra le trafic vers SFO via le tunnel NYC↔SFO.
Décision : Si cela passe de façon inattendue par DAL (hairpin), corrigez la préférence de routage (metrics/politique BGP) avant d’accuser l’application.
Tâche 5 : Détecter le routage asymétrique (classique « ça marche dans un sens »)
cr0x@server:~$ tcpdump -ni vti-nyc-dal host 10.20.8.50 and tcp port 445 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vti-nyc-dal, link-type RAW (Raw IP), snapshot length 262144 bytes
IP 10.10.9.25.49812 > 10.20.8.50.445: Flags [S], seq 112233, win 64240, options [mss 1360,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0
IP 10.10.9.25.49812 > 10.20.8.50.445: Flags [S], seq 112233, win 64240, options [mss 1360,sackOK,TS val 1123 ecr 0,nop,wscale 7], length 0
IP 10.10.9.25.49812 > 10.20.8.50.445: Flags [S], seq 112233, win 64240, options [mss 1360,sackOK,TS val 2123 ecr 0,nop,wscale 7], length 0
5 packets captured
Ce que cela signifie : Des retransmissions de SYN sans SYN-ACK en retour sur cette interface. Soit le chemin de retour est ailleurs (asymétrique), soit bloqué.
Décision : Capturez aussi sur le tunnel du site distant. Si le SYN-ACK revient via un autre tunnel, corrigez la symétrie du routage ou les attentes des pare-feu stateful.
Tâche 6 : Tester le MTU correctement avec DF activé (arrêtez de faire confiance au « ping fonctionne »)
cr0x@server:~$ ping -M do -s 1372 -c 3 10.30.5.10
PING 10.30.5.10 (10.30.5.10) 1372(1400) bytes of data.
1400 bytes from 10.30.5.10: icmp_seq=1 ttl=63 time=32.1 ms
1400 bytes from 10.30.5.10: icmp_seq=2 ttl=63 time=31.8 ms
1400 bytes from 10.30.5.10: icmp_seq=3 ttl=63 time=32.0 ms
--- 10.30.5.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 31.8/32.0/32.1/0.1 ms
Ce que cela signifie : Payload 1372 (1400 bytes ICMP) passe avec DF — donc le PMTU est au moins 1400.
Décision : Si des tailles supérieures échouent (par ex. 1472), réglez le MTU du tunnel en conséquence et clamperez le MSS TCP pour éviter des trous noirs de fragmentation.
Tâche 7 : Vérifier les erreurs « fragmentation nécessaire » (la preuve irréfutable)
cr0x@server:~$ ping -M do -s 1472 -c 2 10.30.5.10
PING 10.30.5.10 (10.30.5.10) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1436
ping: local error: message too long, mtu=1436
--- 10.30.5.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1012ms
Ce que cela signifie : Votre MTU d’interface locale est 1436 ; des trames 1500 ne passeront pas par le tunnel.
Décision : Clampez le MSS (par ex. 1360) et assurez-vous que les interfaces internes n’assument pas des jumbo/1500 bout en bout sur le VPN.
Tâche 8 : Vérifier l’état des sessions BGP et le nombre de routes
cr0x@server:~$ vtysh -c "show ip bgp summary"
BGP router identifier 10.10.0.1, local AS number 65010
BGP table version is 42
3 BGP AS-PATH entries
1 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.254.20.2 4 65020 812 799 42 0 0 02:11:34 18
169.254.30.2 4 65030 805 790 42 0 0 02:09:57 22
Ce que cela signifie : Les deux voisins sont Established ; vous recevez des préfixes. Des chutes soudaines à 0 préfixes sont une panne de routage même si le tunnel est « up ».
Décision : Si des préfixes manquent, vérifiez les filtres, la reachabilité du next-hop et si l’IP de l’interface de tunnel a changé.
Tâche 9 : Valider ce que vous exportez réellement (éviter le transit accidentel)
cr0x@server:~$ vtysh -c "show ip bgp neighbors 169.254.20.2 advertised-routes"
BGP table version is 42, local router ID is 10.10.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.10.0.0/16 0.0.0.0 0 32768 i
*> 10.10.50.0/24 0.0.0.0 0 32768 i
Ce que cela signifie : Vous n’annoncez que les préfixes de NYC, pas « le monde entier ».
Décision : Si vous voyez des routes DAL annoncées à SFO via NYC, vous pourriez involontairement faire de NYC un transit ; corrigez la politique d’export.
Tâche 10 : Confirmer le forwarding IP et rp_filter (les routeurs Linux peuvent mordre)
cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 1
Ce que cela signifie : Le forwarding est activé, mais le reverse-path filtering strict peut dropper des flows asymétriques (commun dans les maillages multi-tunnel).
Décision : Si vous avez du routage asymétrique par conception ou lors de basculements, réglez rp_filter en mode loose (2) sur les interfaces concernées.
Tâche 11 : Vérifier les IKE et CHILD SA de strongSwan (vérité IPsec)
cr0x@server:~$ sudo swanctl --list-sas
nyc-dal: #12, ESTABLISHED, IKEv2, 1d 02:11:04, 198.51.100.10[nyc]...203.0.113.20[dal]
local 'nyc' @ 198.51.100.10[4500]
remote 'dal' @ 203.0.113.20[4500]
AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
nyc-dal-child: #22, INSTALLED, TUNNEL, reqid 1, 2h 11:04, ESP in UDP SPIs: c1a2b3c4_i c4b3a2c1_o
AES_GCM_16_256, 12345678 bytes_i, 11223344 bytes_o, rekeying in 31 minutes
Ce que cela signifie : Tunnel établi, child SA installé, compteurs de trafic incrémentent, rekey programmé.
Décision : Si les octets restent à 0 alors que les applis échouent, vous avez probablement un problème de routage/pare-feu, pas « VPN down ».
Tâche 12 : Surveiller les flaps de rekey dans les logs (baisses brèves)
cr0x@server:~$ sudo journalctl -u strongswan --since "30 min ago" | tail -n 12
Aug 22 10:11:03 nyc-gw charon[2014]: 12[IKE] rekeying IKE_SA nyc-dal[12]
Aug 22 10:11:04 nyc-gw charon[2014]: 12[IKE] sending CREATE_CHILD_SA request 1 [ SA No KE TSi TSr ]
Aug 22 10:11:09 nyc-gw charon[2014]: 12[IKE] retransmit 1 of request with message ID 47
Aug 22 10:11:14 nyc-gw charon[2014]: 12[IKE] retransmit 2 of request with message ID 47
Aug 22 10:11:19 nyc-gw charon[2014]: 12[IKE] giving up after 3 retransmits
Aug 22 10:11:19 nyc-gw charon[2014]: 12[IKE] deleting IKE_SA nyc-dal[12] between 198.51.100.10[nyc]...203.0.113.20[dal]
Ce que cela signifie : Rekey échoué ; le tunnel a été détruit. Les utilisateurs subissent une courte interruption qui paraît « aléatoire ».
Décision : Enquêtez sur la perte dans l’underlay, les durées/propositions non alignées, le comportement NAT-T, ou la saturation CPU durant le rekey.
Tâche 13 : Vérifier les compteurs de politiques du pare-feu pour les autorisations/refus inter-sites
cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
iifname "vti-nyc-dal" oifname "lan0" ip saddr 10.20.0.0/16 ip daddr 10.10.50.0/24 tcp dport { 443, 445 } accept
counter packets 1842 bytes 221040 drop
}
}
Ce que cela signifie : Politique par défaut drop ; un allow spécifique existe. Le compteur final-drop capture quelque chose.
Décision : Si le compteur de drop augmente lors d’une panne signalée, ajoutez un allow ciblé (ou corrigez l’application pour qu’elle utilise les ports attendus), n’ouvrez pas « any-any ».
Tâche 14 : Mesurer le débit réel et la perte avec iperf3 (pas de conjectures)
cr0x@server:~$ iperf3 -c 10.20.8.50 -t 10 -P 4
Connecting to host 10.20.8.50, port 5201
[ 5] local 10.10.9.25 port 41862 connected to 10.20.8.50 port 5201
[ 6] local 10.10.9.25 port 41864 connected to 10.20.8.50 port 5201
[ 7] local 10.10.9.25 port 41866 connected to 10.20.8.50 port 5201
[ 8] local 10.10.9.25 port 41868 connected to 10.20.8.50 port 5201
[SUM] 0.00-10.00 sec 412 MBytes 346 Mbits/sec 0 sender
[SUM] 0.00-10.00 sec 410 MBytes 344 Mbits/sec receiver
Ce que cela signifie : Vous pouvez transférer ~344 Mbps entre sites en conditions de test.
Décision : Si le trafic métier est plus lent, examinez les limites par flux, le QoS, le fenêtrage TCP ou les goulets applicatifs — pas seulement « le VPN ».
Trois micro-histoires issues du monde de l’entreprise
Micro-histoire 1 : L’incident causé par une mauvaise hypothèse
L’entreprise avait trois bureaux et un joli full mesh. Le diagramme réseau ressemblait à un devoir de géométrie, ce qui rassurait tout le monde.
Ils avaient aussi une hypothèse : « Si le tunnel est up, les routes sont correctes. » Personne ne l’a écrite, ce qui fait que les hypothèses se propagent — silencieusement, comme la poussière.
Puis un petit changement est arrivé : un nouveau VLAN à DAL pour un laboratoire de sous-traitant. L’ingénieur a ajouté le sous-réseau localement, mis à jour une seule route statique du tunnel,
et est passé à autre chose. Le labo pouvait atteindre NYC, donc le ticket a été fermé avec une note enjouée. SFO ne pouvait pas atteindre le labo, mais personne n’a testé ce chemin.
Une semaine plus tard, une pipeline de build à SFO a commencé à échouer lorsqu’elle tentait de récupérer des artefacts depuis un hôte de DAL qui était passé dans le nouveau VLAN.
Les échecs étaient intermittents parce que certains jobs touchaient encore des artefacts mis en cache ailleurs. L’équipe a appelé cela « CI instable », la phrase qu’on utilise
quand on ne sait pas encore ce qui est cassé.
Le correctif n’a rien d’exotique : ne plus considérer l’état du tunnel comme un proxy pour la connectivité et arrêter d’utiliser des routes statiques one-off sans inventaire.
Ils sont passés à des tunnels basés sur des routes et BGP, et ont implémenté un test post-change qui contacte un hôte représentatif dans chaque sous-réseau distant depuis chaque site.
Le résultat était ennuyeux. Ce qui est le but.
Micro-histoire 2 : L’optimisation qui a échoué
Une autre organisation voulait « performance maximale », donc elle a activé des réglages crypto agressifs et raccourci les durées parce que quelqu’un avait lu que les rekeys sont plus sûrs.
Ils ont aussi monté le logging en « debug » pendant le déploiement et ont oublié de le désactiver. Classique.
Pendant un moment tout semblait correct. Puis lundi est arrivé : plus d’utilisateurs, plus de trafic, plus de rekeys. Les passerelles ont commencé à avoir des pics CPU pendant les événements de rekey,
et comme les durées étaient courtes, les pics étaient fréquents. Les utilisateurs n’ont pas vu une panne totale. Ils ont vu des micro-pannes : appels qui coupent, pauses SMB,
RDP qui fige pendant cinq secondes puis reprend.
Le helpdesk a fait ce que font les helpdesks : ils l’ont corrélé à « problèmes VPN » et ont escaladé. L’équipe réseau voyait des tunnels établis et est passée à autre chose.
Pendant ce temps le volume de logs était suffisamment élevé pour remplir le disque sur une passerelle, et ensuite la machine est devenue « intéressante » de nouvelles façons.
Ils ont annulé l’« optimisation » : durées raisonnables, logging debug uniquement lors de sessions planifiées, et dimensionnement matériel basé sur la charge de rekey maximale.
Les performances se sont améliorées non pas parce que le crypto était devenu plus rapide, mais parce que le système a arrêté de se frapper la tête toutes les quelques minutes.
Micro-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une entreprise axée finance exploitait trois bureaux avec un maillage, mais traitait le VPN comme de la production : config en contrôle de version, fenêtres de changement,
et un simple runbook de validation. Ce n’était pas glamour. C’était aussi la raison pour laquelle ils pouvaient dormir.
Un après-midi, un ISP dans une ville a eu une panne partielle : pas une coupure totale, juste assez de perte de paquets pour ruiner le trafic encapsulé UDP.
Le tunnel est resté « up » assez longtemps pour embrouiller tout le monde, mais les symptômes applicatifs étaient immédiats — jitter voix, accès fichiers lent, timeouts étranges.
Leur supervision l’a détecté parce qu’ils mesuraient la perte entre passerelles et suivaient les retransmissions IPSec. L’astreinte a suivi le runbook :
vérifier la perte de l’underlay, confirmer les compteurs du tunnel, exécuter des tests MTU, puis basculer le trafic sur le circuit secondaire. Ils n’ont pas débattu avec le réseau.
Ils ont déplacé la charge.
Le meilleur : ils avaient une checklist de validation post-change qui incluait des étapes « restaurer le primaire », donc le revert n’est pas devenu un second incident.
Pas d’héroïsme. Juste de l’ennui pratiqué.
Erreurs courantes (symptômes → cause racine → correctif)
1) Symptom : « Le ping fonctionne, mais SMB/HTTPS plante »
Cause racine : Trou noir MTU ; paquets TCP plus grands que le MTU du tunnel sont dropped, ICMP fragmentation-needed bloqué, ou MSS non clampé.
Correctif : Régler le MTU du tunnel et clamp le MSS TCP à l’entrée/sortie du VPN. Confirmer avec des ping DF et des tests applicatifs réels.
2) Symptom : « Le tunnel est up, mais un sous-réseau est injoignable »
Cause racine : Annonce de route manquante (route statique non ajoutée, filtre BGP, mauvais next-hop), ou plages qui se chevauchent causant une mauvaise sélection de route.
Correctif : Valider les tables de routage sur les trois sites ; si vous utilisez BGP, vérifier les routes annoncées/ reçues et les prefix-lists. Corriger les chevauchements via renumérotation.
3) Symptom : « Ça marche de NYC vers DAL, pas de DAL vers NYC »
Cause racine : Routage asymétrique plus drop par pare-feu stateful ; rp_filter sur Linux ; routes politiques renvoyant le trafic de retour vers un autre tunnel.
Correctif : Assurer un routage symétrique pour les flows stateful ou utiliser des règles stateless où approprié. Mettre rp_filter en mode loose si nécessaire.
4) Symptom : « Pannes aléatoires de 10–30 secondes »
Cause racine : Flaps de rekey dus à perte de paquets, durées/propositions non alignées, pics CPU ou DPD trop agressif.
Correctif : Aligner durées/propositions ; tuner DPD ; enquêter sur la perte de l’underlay ; dimensionner le CPU ; éviter des intervalles de rekey extrêmes.
5) Symptom : « DAL n’atteint SFO que lorsque le tunnel NYC est down »
Cause racine : Mauvaise préférence de routage ; NYC agit accidentellement en transit à cause de fuites de routes, metrics ou local-pref BGP.
Correctif : Corriger la politique de routage : préférer le tunnel direct, filtrer les routes transit, régler local-pref/weight et assurer next-hop-self quand approprié.
6) Symptom : « Le DNS fonctionne, mais l’IP retournée est injoignable depuis un bureau »
Cause racine : Mismatch split-horizon ; enregistrements conscients du site non alignés avec le routage ; services internes liés à des sous-réseaux locaux.
Correctif : Décider d’un modèle DNS (vue unique vs conscient du site). Le documenter et tester résolution + connectivité depuis chaque site.
7) Symptom : « Le débit est terrible seulement pour les flux uniques »
Cause racine : Shaping par flux, problèmes de fenêtre TCP ou application qui n’utilise qu’un flux ; overhead du chiffrement réduisant le MSS/throughput effectif.
Correctif : Utiliser iperf3 avec flux parallèles pour comparer. Envisager QoS, tuning TCP ou modifications côté appli ; n’augmentez pas seulement la bande passante.
8) Symptom : « Tout meurt pendant les sauvegardes »
Cause racine : Pas de QoS et saturation de l’uplink ; bufferbloat ; trafic de sauvegarde qui prend le tunnel en otage.
Correctif : Limiter le débit des sauvegardes, les planifier ou appliquer du QoS. Mesurer drops et latence en charge ; prioriser le trafic interactif.
Listes de contrôle / plan pas à pas
Plan pas à pas : construire un maillage trois-bureaux qui ne vous hantera pas
- Décidez la topologie pour une raison : latence/bande passante/isolation des pannes. Écrivez la raison.
- Normalisez le addressing : choisir des plages RFC1918 non chevauchantes par site ; réserver de la place pour la croissance.
- Choisir le type de tunnel : tunnels basés sur des routes (VTI) par défaut.
- Choisir le routage : statique si vraiment petit et stable ; BGP si quelque chose change plus souvent que trimestriellement.
- Définir les zones de sécurité : users, servers, management, guest, voix/OT selon besoin.
- Écrire la politique inter-site : allow-lists par paire de zones ; refuser user-to-user LAN par défaut.
- Plan DNS : vue unique ou conscient du site ; documenter ce que résolvent les noms internes à chaque site.
- Baseline MTU/MSS : régler le MTU du tunnel, clamp MSS et vérifier avec des ping DF.
- Observabilité : état tunnel, état BGP, sondes perte/latence, drops d’interface et échantillonnage des logs.
- Gestion de config : exporter les configs ; stocker en contrôle de version ; utiliser des conventions de nommage cohérentes.
- Tests : pour chaque changement, tester depuis chaque site au moins un hôte dans chaque sous-réseau distant.
- Exercices de panne : simuler un tunnel down, un circuit dégradé et un mauvais routage DNS. S’entraîner sur bascule et retour en production.
Checklist pré-changement (faire avant de toucher la production)
- Configs actuelles exportées et sauvegardées (avec timestamps et ID de changement).
- Procédure de rollback écrite et faisable sans héroïsme Internet.
- Liste des flux critiques entre sites (ports + sous-réseaux + propriétaires).
- Fenêtre de maintenance communiquée (y compris « ce qui va casser »).
- Dashboards de supervision ouverts : perte/latence, état tunnel, BGP, erreurs d’interface.
Checklist de vérification post-changement (la partie que tout le monde saute)
- Tunnels établis et stables (pas de flaps dans les logs).
- Routes présentes sur tous les sites (nombre de préfixes attendus).
- Test MTU réussi à la taille attendue (ping DF).
- Au moins une transaction applicative réelle par paire de sites (pas juste un ping).
- Compteurs de refus du pare-feu non explosifs.
- Documentation mise à jour : préfixes, peers, politiques et exceptions.
FAQ
1) Pour trois bureaux, le full-mesh est-il toujours meilleur que hub-and-spoke ?
Non. Si la plupart du trafic va vers un site « core » (datacenter/HQ), le hub-and-spoke est plus simple et souvent plus fiable.
Le full-mesh est meilleur quand le trafic site-à-site est lourd ou quand vous avez besoin d’isolation de panne par paire.
2) Dois-je utiliser des routes statiques ou BGP pour un maillage trois sites ?
Les routes statiques sont acceptables si le réseau est minuscule et stable. BGP vaut le coût si vous avez plusieurs sous-réseaux par site, prévoyez de croître,
ou voulez un basculement propre et des filtrages. Si vous maintenez déjà plus d’une poignée de routes statiques, vous les avez dépassées.
3) Quelle est la manière la plus rapide d’éviter les fuites de routes dans un maillage ?
Utilisez des prefix-lists (ou équivalent) et n’annoncez que les préfixes locaux à chaque voisin. Supposez que chaque voisin acceptera joyeusement des bêtises sauf si vous l’en empêchez.
Décidez aussi si un site peut être transit. Habituellement la réponse est « non ».
4) Pourquoi mon tunnel affiche « up » alors que les utilisateurs se plaignent ?
Parce que « up » signifie généralement que le plan de contrôle est vivant (IKE SA). Le plan de données peut être cassé par des trous noirs MTU, perte de paquets, boucles de routage
ou drops de pare-feu. Mesurez la perte/latence, vérifiez les compteurs et validez des flux applicatifs réels.
5) Dois-je clamp le MSS ?
Si votre MTU effectif sur le VPN est inférieur à 1500 (commun avec IPsec/NAT-T), clamp le MSS est souvent la façon la plus simple d’éviter des blocages difficiles à déboguer.
Vérifiez avec des ping DF et observez si des « grosses réponses » échouent.
6) WireGuard peut-il faire un full-mesh entre bureaux en toute sécurité ?
Oui, si vous gérez correctement les clés et êtes discipliné avec AllowedIPs et la politique de pare-feu. WireGuard facilite les tunnels ; il n’automatise pas la politique de routage.
Pour trois sites, c’est excellent sur des passerelles Linux avec des configs et une supervision cohérentes.
7) Comment empêcher qu’un maillage ne devienne un cauchemar de sécurité ?
Refus par défaut du forwarding inter-site, segmentation par zones et autorisations explicites seulement pour les flux requis.
Journalisez les refus avec des limites de débit raisonnables. Et gardez l’accès management hors du tissu inter-site général.
8) Que dois-je surveiller pour détecter les problèmes avant les utilisateurs ?
Perte et latence entre passerelles, stabilité des rekeys de tunnel, drops/erreurs d’interface, état des sessions BGP et nombre de préfixes,
et quelques checks synthétiques applicatifs (résolution DNS + connexion TCP + petit transfert).
9) Et la haute disponibilité pour trois sites ?
La HA aide, mais ce n’est pas magique. Commencez par deux circuits Internet si possible, puis des passerelles redondantes avec une méthode de basculement testée.
Assurez-vous que le basculement ne change pas les IP sources de façon à casser les attentes des pairs, et répétez le retour en place.
10) Comment savoir si le SD-WAN vaut le coup pour seulement trois bureaux ?
Ça vaut le coup quand vous avez besoin d’une politique centralisée, d’une meilleure observabilité, de plusieurs circuits par site et d’un steering applicatif.
Si votre environnement est stable et que vous pouvez standardiser sur une pile de passerelles unique, un VPN classique avec BGP suffit souvent.
Conclusion : prochaines étapes pratiques
Pour trois bureaux, un VPN full-mesh est soit un tissu propre et basse latence — soit un jeu de blâme en forme de triangle. La différence ne tient pas à la topologie.
Elle tient à savoir si vous traitez le routage, le DNS, le MTU et la politique comme des citoyens de première classe, et si vous exploitez la chose avec discipline.
Prochaines étapes que vous pouvez faire cette semaine :
- Écrivez la vraie raison de votre maillage (latence, bande passante, isolation). Si vous ne pouvez pas, reconsidérez le hub-and-spoke.
- Inventoriez les sous-réseaux et éliminez les chevauchements avant qu’ils ne se multiplient.
- Réalisez les tests MTU DF et clamp le MSS si nécessaire.
- Si vous utilisez des routes statiques, comptez-les. Si leur nombre vous agace, migrez vers BGP.
- Ajoutez de la supervision pour la perte/latence entre passerelles et pour les flaps de rekey. « Tunnel up » n’est pas de l’observabilité.
- Mettez en place une politique inter-site par défaut-deny et ajoutez des allow-lists explicites pour les flux métier réels.
Construisez le maillage comme si vous devrez le déboguer à 2 h du matin. Parce que vous le ferez. L’objectif est que ce soit ennuyeux quand vous le ferez.