Hub-and-spoke ou maillage complet : quelle topologie VPN convient à vos sites

Deux sites annexes se parlent toute la journée, et le tunnel entre eux fait un détour par un centre de données d’une autre région. Chaque requête paie ce détour deux fois, et personne ne le remarque avant que la synchronisation de fichiers ne commence à sembler anormale. C’est là que la question de la topologie commence vraiment : non pas en se demandant quel schéma paraît plus résilient, mais quel schéma de trafic vous payez. Les deux conceptions fonctionnent, et elles échouent de manières différentes à des coûts différents.

Comptez les relations entre pairs avant tout le reste

Avec N sites, un maillage complet demande N fois N moins un, divisé par deux, tunnels ; un hub en demande N. À cinq sites, cela fait dix contre cinq, ce qui semble encore gérable. À quinze, cela fait 105 contre quinze, et la différence n’est plus arithmétique mais humaine.

Chacune de ces relations porte un état dont vous devez être propriétaire. En IPsec, cela veut dire une association de sécurité, une identité, une clé ou un certificat, la détection de pair mort et au moins une route par préfixe distant. En WireGuard, cela veut dire une clé publique et un AllowedIPs bloc par pair, ce qui coûte moins cher par pair mais arrive sans aucune découverte : un nouveau site reste un changement de configuration sur chacun des sites existants.

Laissez la composition du trafic décider, pas le dessin

Si le trafic des sites est surtout constitué de requêtes vers un ERP central ou un cluster de fichiers, un hub n’est pas un compromis, c’est la bonne forme : le trafic voulait déjà aller là, et un seul point de politique est plus facile à auditer qu’un maillage de règles par paires. Un maillage mérite sa complexité quand les sites échangent des données entre eux — réplication entre deux bureaux, voix entre sites, un partage CAO qu’une douzaine d’ingénieurs ouvrent toute la journée.

Les cas gênants se situent entre les deux, et ils sont majoritaires. Mesurez avant de discuter au lieu de deviner à partir d’un organigramme.

Lisez le tableau comme un départage, pas comme une règle. Trois lignes sur quatre dans le même sens tranchent généralement la conception ; une division signifie un hybride, ce vers quoi la plupart des réseaux matures finissent de toute façon par aller.

Il faut dire au hub de transmettre

Deux tunnels spokes-vers-hub qui fonctionnent ne créent pas d’accès spoke-à-spoke. Le hub a besoin du transfert IP activé, d’une route vers chaque réseau spoke, d’une règle de pare-feu qui autorise le transit et d’un chemin de retour calculé ; chaque spoke a besoin d’une route pour les préfixes de l’autre site. Sur un hub Linux, c’est net.ipv4.ip_forward=1 plus FORWARD une chaîne qui ne laisse pas tomber la paire en silence, et en IPsec basé sur des politiques, ce sont des sélecteurs de trafic qui listent le sous-réseau spoke distant des deux côtés. Chez strongSwan, les notes de transfert couvrent le côté noyau et pare-feu quand c’est cette couche qui vous manque. Un test peu coûteux consiste à envoyer du trafic d’un spoke vers un service de l’autre en observant les compteurs du hub ; une règle qui n’incrémente jamais signifie que l’ordre est faux, pas la route.

La politique centrale est aussi la partie utile. On peut autoriser les sites à joindre des services partagés sans se joindre entre eux, et cette matrice d’accès mérite d’être écrite explicitement. Des routes manquantes sont un pauvre substitut à une règle que quelqu’un peut lire.

Attention à la version à moitié faite : le spoke A route vers le spoke B via le hub, le hub route dans les deux sens, et le pare-feu du hub autorise les nouvelles connexions depuis A mais pas depuis B. Le premier sens se teste bien et le second se bloque, ce qui ressemble à une panne de routage et n’en est pas une.

Concevez la panne, puis le chemin normal

Un hub unique est une dépendance partagée et un goulot d’étranglement de transit, et la redondance est précisément là où les conceptions à hub se trompent. Deux hubs signifient que chaque spoke détient deux tunnels, et le chemin de retour doit s’accorder avec le chemin sortant ; quand ce n’est pas le cas, un pare-feu à états jette les réponses et le symptôme est une connexion qui s’ouvre puis meurt. Les déploiements plus grands règlent cela avec un protocole de routage sur les tunnels plutôt que des préfixes statiques, ce qui fait plus de machinerie mais supprime les devinettes. Quoi que vous choisissiez, écrivez le chemin de retour à côté du chemin sortant, car c’est la moitié retour que personne ne teste.

Un maillage répartit ce risque : la chute du lien d’un site n’isole pas les autres. Il multiplie aussi les endroits où la sélection de chemin peut vous surprendre, et les sessions applicatives ne survivent toujours pas à un changement de chemin sans aide.

Aucune des deux conceptions ne maintient une session TCP en vie pendant un basculement par elle-même. Si l’application ne peut pas se reconnecter, la topologie n’est pas votre problème.

Choisissez par coût de changement, puis vérifiez les routes

Commencez par le hub, car c’est la chose la moins chère sur laquelle se tromper, et ajoutez des tunnels directs pour les paires dont le trafic le justifie. Cet hybride n’est pas un refus de décider ; c’est la conception vers laquelle la plupart des organisations convergent en un an. L’important est que chaque lien direct ait une raison énoncée et un responsable.

Vérifiez ensuite les deux schémas plutôt qu’un seul. Pour le chemin normal, traceroute de chaque site vers chaque préfixe de service et confirmez que les sauts correspondent au diagramme. Pour le chemin de panne, coupez un tunnel et recommencez, car une route qui ne fonctionne que tant que tout est debout n’a pas été conçue, seulement configurée.

Conservez les deux schémas avec la matrice d’accès, et revoyez-les lorsqu’un site est ajouté ; le coût que vous gérez est celui du prochain changement, pas l’élégance de l’image actuelle.