Stéphane.
NetworkTerminé

Maillage WireGuard multi-site

Interconnexion chiffrée de plusieurs sites et fournisseurs cloud avec WireGuard, routage dynamique et déploiement automatisé.

Technologies employées

  • WireGuard
  • Ansible
  • BIRD
  • Linux
  • nftables

Résumé

Un maillage chiffré reliant plusieurs sites physiques et fournisseurs cloud, avec propagation dynamique des routes et déploiement entièrement automatisé.

Contexte

Les tunnels point à point configurés à la main ne passent pas l’échelle. À partir de quatre sites, le nombre de tunnels et de routes statiques devient ingérable, et chaque ajout de site impose de modifier tous les autres.

Étoile contre maillage completÀ gauche, trois sites raccordés à un concentrateur central : toute communication entre sites traverse ce point unique. À droite, les mêmes trois sites reliés deux à deux par des tunnels directs, sans point de passage obligé.ÉTOILEMAILLAGEhubsite Asite Bsite Csite Asite Bsite C
À gauche, tout transite par le concentrateur : il tombe, tout tombe. À droite, chaque lien est direct — trois sites, trois tunnels.

Objectifs

  • Ajouter un site sans reconfigurer manuellement les sites existants.
  • Chiffrer l’intégralité des flux inter-sites.
  • Conserver un basculement automatique en cas de perte d’un lien.

Contraintes

  • Adresses IP publiques dynamiques sur certains sites.
  • Traversée de NAT obligatoire pour deux emplacements.
  • Latence à préserver : pas de concentrateur central unique.

Architecture

Chaque site expose une interface WireGuard. Les sites disposant d’une adresse stable acceptent les connexions entrantes ; les autres initient et maintiennent le tunnel par échanges périodiques.

Le routage n’est pas statique : un démon de routage distribue les préfixes de chaque site, ce qui rend l’ajout d’un réseau transparent pour les voisins.

Implémentation

L’inventaire décrit les sites, leurs préfixes et leurs clés publiques. Un rôle Ansible génère la configuration de chaque pair, les règles de filtrage et les sessions de routage. Les clés privées ne quittent jamais leur machine.

Difficultés rencontrées

Derrière NAT, un tunnel silencieux se ferme sans que rien ne le signale : le lien paraît actif jusqu’à la première tentative d’émission. Le basculement, lui, restait trop lent parce que le protocole de routage attendait l’expiration de ses propres délais.

Solutions

Un maintien de session périodique est activé sur les pairs situés derrière NAT. La détection de perte de lien s’appuie désormais sur un mécanisme dédié plutôt que sur l’expiration des annonces de routage, ce qui ramène la bascule sous la seconde.

Résultats

  • Ajout d’un site réduit à une entrée d’inventaire et une exécution du rôle.
  • Bascule de lien inférieure à la seconde lors des tests de coupure.
  • Aucun flux inter-sites en clair.

Améliorations possibles

  • Rotation automatisée des clés.
  • Sondes de qualité de lien exportées vers la supervision.