VPN WireGuard hub-and-spoke pour 3 bureaux avec accès basé sur les rôles

Décisions d’architecture qui ne vous mordront pas plus tard

Pourquoi hub-and-spoke pour trois bureaux ?

Avec trois sites, la topologie full-mesh est tentante : « connectez tout le monde à tout le monde ». Ça marche jusqu’à ce que vous ajoutiez des rôles, des services partagés, des sites futurs et un auditeur conformité avec un clipboard et des rêves. Le hub-and-spoke vous donne un point d’étranglement unique où vous pouvez :

• appliquer la politique de façon cohérente (pare-feu, journalisation, DNS)
• rendre le routage prévisible (les spokes envoient le trafic non local vers le hub)
• réduire la complexité opérationnelle (un seul endroit pour déboguer les problèmes inter-sites)
• ajouter un quatrième bureau sans apprendre de nouvelles façons de souffrir

Le compromis est que le hub devient important. C’est acceptable. Les systèmes de production ont toujours des parties importantes ; l’astuce est de savoir quelles parties sont importantes et de les traiter en conséquence.

Définissez les rôles avant de définir les règles

« Règles d’accès par rôle » n’est pas une fonctionnalité de pare-feu. C’est une décision métier exprimée en paquets. Commencez par des rôles qui correspondent aux modèles de trafic :

• IT/Admin : peut atteindre les sous-réseaux de management, les jump hosts, la supervision, peut-être tout pendant les incidents.
• Finance : peut atteindre les systèmes comptables, les partages de fichiers, certaines imprimantes, pas les réseaux R&D.
• Ingénierie : peut atteindre les systèmes de build, les dépôts, les environnements de staging, pas les systèmes RH.
• Invité/Fournisseur : peut atteindre une ou deux applications, et rien d’autre.

Dès que vos « rôles » sont en fait des « personnes », vous aurez une tempête d’ACL. Gardez peu de rôles. Associez utilisateurs/appareils aux rôles via les IPs pairs WireGuard ou des interfaces séparées, puis appliquez la politique de façon centralisée.

N’utilisez pas WireGuard comme seul moteur de politique

WireGuard est excellent dans son domaine : un tunnel chiffré petit et rapide avec un modèle de clés propre. Ce n’est pas un système RBAC. Le AllowedIPs de WireGuard est à la fois du routage et un contrôle d’admission très grossier. Ce n’est pas un pare-feu, et le prétendre conduit à des pannes étranges.

Utilisez WireGuard pour le transport sécurisé et le cadrage basique des pairs. Utilisez nftables (ou iptables, si vous devez) sur le hub pour appliquer qui peut parler à quoi. Cela vous donne traçabilité et un emplacement unique pour implémenter « Finance peut atteindre 10.10.20.0/24 mais pas 10.10.30.0/24 ».

Blague #1 : Un VPN sans règles de pare-feu n’est qu’un câble LAN très sûr de lui.

Supposez que NAT existe quelque part et planifiez en conséquence

Les bureaux sont souvent derrière des routeurs basiques. WireGuard utilise UDP et est compatible NAT, mais le NAT influencera quand même les keepalives, le MTU et la joignabilité entrante. Votre hub devrait avoir une IP publique statique si possible. Sinon, vous aurez besoin d’une approche plus créative, mais pour trois bureaux, payez pour l’IP statique et finissez-en.

Décidez : routé vs ponté. Choisissez routé.

Faire du bridging L2 entre sites, c’est importer des tempêtes de broadcast et des « ARP mystère » dans votre vie. Utilisez des sous-réseaux routés par bureau. Si quelqu’un insiste pour « avoir besoin de L2 », faites-lui nommer l’application et le protocole, puis corrigez cette application.

Faits intéressants et contexte (parce que l’histoire se répète dans les tickets)

• L’objectif de conception de WireGuard était la simplicité : beaucoup moins de lignes de code que les piles VPN traditionnelles, ce qui réduit la surface d’attaque et le temps de débogage.
• Il utilise de la cryptographie moderne par défaut : Curve25519 pour l’échange de clés, ChaCha20-Poly1305 pour le chiffrement authentifié, et BLAKE2s pour le hachage.
• Le « routage par cryptokey » est l’idée centrale de WireGuard : la clé que vous utilisez détermine aussi les plages IP que vous êtes autorisé à envoyer à ce pair.
• IPsec est plus ancien que beaucoup de vos routeurs : il est né dans les années 1990, et sa complexité est en partie un fossile d’exigences anciennes.
• Les VPN site-à-site étaient autrefois matériels uniquement : les premiers déploiements d’entreprise s’appuyaient sur des appliances dédiées parce que les CPU étaient plus lents et la crypto coûteuse.
• Les VPN UDP peuvent surpasser les VPN TCP : parce que le phénomène TCP-over-TCP existe ; WireGuard évite ce type de misère en restant sur UDP.
• Les bugs MTU sont intemporels : la découverte du MTU de chemin et le filtrage ICMP ont provoqué des incidents « tout marche sauf cette application » pendant des décennies.
• Les bases de données de routage Linux (tables de routage multiples et ip rule) existent parce qu’une « route par défaut » n’a plus suffi dans les réseaux réels.

Une idée paraphrasée à garder sur votre écran : l’espoir n’est pas une stratégie — souvent attribuée dans la culture ops à General Gordon R. Sullivan. Traitez-la comme un état d’esprit, pas un exercice de police des citations.

Plan d’adressage IP et modèle de routage (la partie ennuyeuse qui vous sauve)

Sous-réseaux des bureaux : gardez-les uniques et simples

Si vos trois bureaux utilisent tous 192.168.1.0/24, vous n’avez pas un « problème VPN ». Vous avez un problème d’adressage. Corrigez-le d’abord. Renuméroter fait mal, mais moins que de gérer NAT dans votre VPN pour toujours.

Un plan propre et lisible :

• LAN Bureau A : 10.10.10.0/24
• LAN Bureau B : 10.10.20.0/24
• LAN Bureau C : 10.10.30.0/24
• Transit VPN (WireGuard) : 10.200.0.0/24

Les adresses des interfaces WireGuard vivent dans 10.200.0.0/24. Ce n’est pas un « LAN ». C’est un réseau de transit. N’y placez pas d’imprimantes. N’y placez pas de personnes. Gardez-le sacré et un peu ennuyeux.

Où vivent les passerelles ?

Chaque bureau obtient une petite passerelle Linux (boîtier physique, VM ou routeur capable d’exécuter WireGuard). Le hub est aussi une passerelle Linux dans un centre de données ou un VPC cloud avec une IP publique stable.

Exemple de nommage :

• hub1 (IP publique, politique centrale) : wg0: 10.200.0.1/24
• spoke-a : wg0: 10.200.0.11/24, interface LAN sur 10.10.10.0/24
• spoke-b : wg0: 10.200.0.21/24, interface LAN sur 10.10.20.0/24
• spoke-c : wg0: 10.200.0.31/24, interface LAN sur 10.10.30.0/24

Modèle de routage : les spokes envoient par défaut au hub pour les réseaux distants

Les spokes doivent router le trafic destiné aux autres sous-réseaux de bureau via le hub. Le hub route vers le spoke correct en fonction de la destination. Cela vous donne une politique centralisée et évite la multiplication des exceptions « spoke-à-spoke ».

Vous aurez quand même une sortie Internet locale dans chaque bureau. Ce n’est pas un design « envoyer tout vers le hub » à moins que vous en ayez besoin spécifiquement et aimiez déboguer la navigation web sur un lien WAN.

Accès par rôle : ce que « par rôle » signifie réellement sur WireGuard

Trois façons d’implémenter les rôles

Vous pouvez implémenter les « rôles » à différents niveaux. Choisissez-en un et soyez cohérent.

1. Par sous-réseau source (recommandé) : assignez les rôles aux VLANs/sous-réseaux internes de chaque bureau (par ex. VLAN Finance). Le pare-feu du hub applique l’accès depuis ces sous-réseaux.
   
   Avantages : évolutif, facile à auditer. Inconvénients : nécessite une hygiène réseau interne.
2. Par IP pair WireGuard : donnez à chaque rôle (ou chaque appareil) une IP VPN et écrivez des règles de pare-feu en utilisant ces IP source.
   
   Avantages : fonctionne même si les LANs sont plats. Inconvénients : peut devenir salissant ; vous encodez l’identité comme une IP.
3. Par interfaces WireGuard séparées par rôle : wg-finance, wg-eng, etc.
   
   Avantages : très explicite. Inconvénients : plus d’interfaces, plus d’éléments en mouvement ; généralement inutile pour trois bureaux sauf exigences de conformité.

La recommandation pratique

Implémentez les rôles par sous-réseau source à l’intérieur de chaque bureau, et appliquez-les au hub. Si le Bureau A est aujourd’hui sur un seul sous-réseau plat, séparez-le. Oui, c’est du « travail réseau ». C’est aussi le but.

Exemple de VLANs de rôle au Bureau A :

• Bureau A Finance : 10.10.11.0/24
• Bureau A Ingénierie : 10.10.12.0/24
• Bureau A IT/Admin : 10.10.13.0/24

Répétez de manière similaire pour les Bureaux B et C, ou gardez les rôles cohérents entre bureaux si possible. La cohérence est un multiplicateur de force quand vous êtes fatigué.

Ce que WireGuard peut et ne peut pas faire pour le RBAC

WireGuard peut garantir qu’un pair donné n’est utilisé que pour certains préfixes de destination via AllowedIPs. Cela empêche les fuites de routage accidentelles et certaines formes d’usurpation. Cela n’empêche pas un pair d’atteindre tout ce qu’il peut router une fois à l’intérieur du tunnel. C’est le rôle du pare-feu.

Configurations WireGuard : hub, spokes, et ce que fait vraiment AllowedIPs

Configuration du hub

Le hub termine tous les trois spokes. Les AllowedIPs du hub pour chaque pair devraient inclure :

• l’IP du tunnel WireGuard du spoke (un /32)
• les sous-réseaux LAN du spoke (LAN du bureau et VLANs de rôle)

cr0x@server:~$ sudo cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.200.0.1/24
ListenPort = 51820
PrivateKey = HUB_PRIVATE_KEY
# Optional but practical:
SaveConfig = false

# Spoke A
[Peer]
PublicKey = SPOKE_A_PUBLIC_KEY
AllowedIPs = 10.200.0.11/32, 10.10.10.0/24, 10.10.11.0/24, 10.10.12.0/24, 10.10.13.0/24

# Spoke B
[Peer]
PublicKey = SPOKE_B_PUBLIC_KEY
AllowedIPs = 10.200.0.21/32, 10.10.20.0/24, 10.10.21.0/24, 10.10.22.0/24, 10.10.23.0/24

# Spoke C
[Peer]
PublicKey = SPOKE_C_PUBLIC_KEY
AllowedIPs = 10.200.0.31/32, 10.10.30.0/24, 10.10.31.0/24, 10.10.32.0/24, 10.10.33.0/24

Configuration du spoke

Chaque spoke a un seul peer : le hub. Les AllowedIPs du spoke pour le hub doivent inclure :

• l’IP du tunnel du hub (/32) et tout service central côté hub
• tous les autres LANs de bureaux atteignables via le hub

Cela signifie que le spoke route les autres bureaux via le hub. Pas de peering spoke-à-spoke. Pas d’exceptions particulières.

cr0x@server:~$ sudo cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.200.0.11/24
PrivateKey = SPOKE_A_PRIVATE_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub1.example.net:51820
AllowedIPs = 10.200.0.1/32, 10.200.0.0/24, 10.10.20.0/24, 10.10.21.0/24, 10.10.22.0/24, 10.10.23.0/24, 10.10.30.0/24, 10.10.31.0/24, 10.10.32.0/24, 10.10.33.0/24
PersistentKeepalive = 25

Pourquoi inclure 10.200.0.0/24 dans AllowedIPs sur le spoke ?

Pour que le spoke puisse atteindre les IPs de tunnel des autres peers si nécessaire (supervision, ping, vérifications de santé). Si vous préférez verrouiller, incluez seulement 10.200.0.1/32 et comptez sur la supervision côté hub. Les deux approches sont valides ; choisissez-en une. J’autorise généralement le transit /24 et le firewall au hub s’en charge.

IP forwarding : vous devez l’activer

C’est la partie que les gens oublient, puis ils blâment WireGuard. Le tunnel est up, mais personne n’atteint rien parce que la machine Linux ne route pas.

Application des accès avec nftables (pas des impressions)

Principe : deny par défaut entre rôles, autoriser selon le besoin

Le hub doit faire respecter la segmentation entre sous-réseaux de rôle des bureaux et les services partagés. Commencez par « refuser l’inter-office par défaut », puis autorisez les flux réellement nécessaires. Ça paraît strict. Ça évite aussi les incidents « l’ordi Finance peut scanner tout le réseau ingénierie ».

Directions de trafic qui vous intéressent

• Trafic forwarded via le hub : bureau-à-bureau et bureau-vers-services-centraux
• Trafic input vers le hub lui-même : SSH, supervision, DNS si le hub l’héberge

Exemple de politique nftables sur le hub

C’est un schéma simplifié mais réaliste : accepter l’établi, puis les autorisations explicites, puis drop. Loggez les drops parcimonieusement, sinon vous DDoS votre propre disque pendant un incident.

cr0x@server:~$ sudo cat /etc/nftables.conf
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    iif lo accept
    ct state established,related accept

    # Allow WireGuard
    udp dport 51820 accept

    # Allow SSH from IT/Admin role subnets only
    ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } tcp dport 22 accept

    # Allow monitoring from IT/Admin
    ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } tcp dport { 9100, 9182 } accept

    # Optional: ICMP for troubleshooting
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;

    ct state established,related accept

    # Allow IT/Admin roles cross-office (jump hosts, mgmt)
    ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } ip daddr { 10.10.0.0/16 } accept

    # Allow Finance to reach accounting service subnet (central or specific office)
    ip saddr { 10.10.11.0/24, 10.10.21.0/24, 10.10.31.0/24 } ip daddr 10.10.50.0/24 tcp dport { 443, 5432 } accept

    # Allow Engineering to reach build systems
    ip saddr { 10.10.12.0/24, 10.10.22.0/24, 10.10.32.0/24 } ip daddr 10.10.60.0/24 tcp dport { 22, 443, 8080 } accept

    # Allow limited printer access within each office only (example)
    ip saddr 10.10.11.0/24 ip daddr 10.10.10.50 tcp dport { 631, 9100 } accept
    ip saddr 10.10.21.0/24 ip daddr 10.10.20.50 tcp dport { 631, 9100 } accept
    ip saddr 10.10.31.0/24 ip daddr 10.10.30.50 tcp dport { 631, 9100 } accept

    # Log and drop everything else
    limit rate 5/second log prefix "vpn-forward-drop " flags all counter drop
  }
}

C’est là que vous gagnez votre pain. Le hub devient un point d’application de politique. Quand quelqu’un demande « pourquoi le fournisseur X ne peut pas atteindre Y », vous pouvez répondre avec une règle, une ligne de log et une demande de changement — pas du folklore.

DNS entre sites sans en faire une maison hantée

Choisissez une stratégie DNS et tenez-vous-y

Les VPN multi-bureaux échouent de deux façons : le routage casse, ou le DNS casse. Les échecs de routage sont évidents ; les échecs DNS sont lents, étranges et épuisants émotionnellement.

Stratégies communes :

• DNS central : un service DNS interne unique accessible via le VPN. Politique la plus simple, source de vérité unique. Assurez la redondance.
• DNS par bureau avec forwarding conditionnel : chaque bureau résout les noms locaux et forwarde les autres zones via le VPN. Fonctionne bien mais demande de la discipline.
• Pure IP + fichiers hosts : techniquement possible, socialement désastreux. Ne le faites pas.

Recommandation

Pour trois bureaux, exécutez un DNS central au hub (ou deux hubs pour la HA), et configurez les clients des bureaux pour l’utiliser pour les zones internes. Si des bureaux doivent résoudre des noms locaux uniquement, utilisez des forwarders conditionnels. Gardez les zones internes explicites (par ex. corp.internal, svc.corp.internal).

Performance : MTU, réalités UDP, et pourquoi « rapide » est un choix de conception

Le MTU n’est pas une trivia optionnelle

WireGuard ajoute de l’overhead. Si vous poussez des paquets trop gros, ils se fragmentent ou sont perdus. Si l’ICMP « fragmentation needed » est bloqué quelque part (ce qui arrive souvent), vous obtenez des symptômes classiques : SSH marche mais les transferts de fichiers stagnent ; les applis web se chargent à moitié ; SMB devient de l’art performance.

Fixez le MTU délibérément. Une valeur sûre courante est 1420 sur les interfaces WireGuard. Parfois vous aurez besoin d’une valeur plus basse (1412, 1380) selon les liens en amont et encapsulations.

UDP et « état »

WireGuard utilise UDP. C’est bon pour la performance et évite les problèmes TCP-over-TCP, mais cela signifie :

• les timeouts NAT peuvent briser silencieusement les chemins de retour si vous n’utilisez pas de keepalives.
• certains réseaux traitent l’UDP comme suspect et le limitent.
• vous devez surveiller la fraîcheur des handshakes et les compteurs de trafic, pas l’« état de connexion ».

Blague #2 : Les problèmes de MTU sont comme des chats — si vous pensez n’en pas avoir, il se cache juste sous le canapé.

Shaping de bande passante et équité

Si un bureau sature le lien du hub, tout le monde partage la douleur. Si c’est un souci, utilisez le traffic control (tc) pour façonner par interface ou par sous-réseau source. Ne le faites pas prématurément. Mais faites-le intentionnellement si vos applis métier se retrouvent bloquées par la sauvegarde hors site de quelqu’un.

Opérations : rotation des clés, gestion des changements et mises à jour

La gestion des clés n’est pas difficile, mais elle est réelle

WireGuard utilise des clés publiques/privées statiques par peer. Les clés n’expirent pas par défaut. C’est à la fois une force et un problème de gouvernance. Vous devriez :

• faire tourner les clés selon un calendrier (par ex. annuellement) et lors de départs de personnel
• stocker les clés privées de façon sécurisée (fichiers root-only, sauvegardes chiffrées)
• documenter quelle clé appartient à quel site/ rôle

Gestion des changements qui ne ruine pas votre week-end

Le hub est central. Traitez sa config comme du code de production :

• gardez /etc/wireguard et la config du pare-feu dans le contrôle de version (repo privé)
• utilisez des conventions de nommage pour les peers et des commentaires hors du fichier si besoin
• déployez les changements avec un processus prévisible (Ansible, Salt, ou au moins un rsync scripté)
• ayez toujours un plan de rollback

Mises à jour

WireGuard in-kernel sur Linux est stable. Pourtant, les mises à jour modifient les kernels, le comportement de nftables et les drivers NIC. Ne mettez pas à jour le hub et tous les spokes en une seule fois. Étalez. Vérifiez les handshakes et les routes après chaque étape.

Tâches pratiques : commandes, sorties, décisions (12+ que vous exécuterez réellement)

Tâche 1 : Vérifier l’état de l’interface WireGuard

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 1Xh9nR...hubpub...
  private key: (hidden)
  listening port: 51820

peer: rGm8z...spokeA...
  allowed ips: 10.200.0.11/32, 10.10.10.0/24, 10.10.11.0/24, 10.10.12.0/24, 10.10.13.0/24
  latest handshake: 37 seconds ago
  transfer: 2.31 GiB received, 3.02 GiB sent
  persistent keepalive: every 25 seconds

Ce que cela signifie : « latest handshake » vous dit si le peer est vivant. Les compteurs de transfert indiquent si le trafic circule dans les deux sens.

Décision : Si les handshakes sont périmés (>2 minutes) pour un spoke derrière NAT, vérifiez le keepalive, la joignabilité UDP et la correction de l’endpoint avant de toucher au routage.

Tâche 2 : Confirmer l’IP de l’interface et le MTU

cr0x@server:~$ ip -d link show dev wg0
8: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
    wireguard version 1.0.20210914

Ce que cela signifie : Le MTU est défini à 1420 ; l’interface est UP.

Décision : Si vous voyez MTU 1500 et que vous êtes sur PPPoE ou d’autres liens à overhead élevé, prévoyez une réduction du MTU et retestez les transferts de fichiers.

Tâche 3 : S’assurer que le forwarding IPv4 est activé sur hub et spokes

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Ce que cela signifie : Le routage Linux est activé.

Décision : Si c’est 0, activez-le et rendez-le persistant ; sinon vous avez un « VPN qui se connecte mais ne route pas », classique.

Tâche 4 : Vérifier les routes des sous-réseaux de bureau sur le hub

cr0x@server:~$ ip route show table main | grep 10.10.
10.10.10.0/24 dev wg0 scope link
10.10.20.0/24 dev wg0 scope link
10.10.30.0/24 dev wg0 scope link

Ce que cela signifie : Le hub croit que ces sous-réseaux sont joignables via wg0.

Décision : Si des routes manquent, le AllowedIPs du peer sur le hub peut être incomplet ou l’interface n’applique pas ces routes (selon comment vous gérez le routage). Corrigez AllowedIPs en premier.

Tâche 5 : Valider qu’un spoke route les autres bureaux via le hub

cr0x@server:~$ ip route get 10.10.20.10
10.10.20.10 dev wg0 src 10.200.0.11 uid 0
    cache

Ce que cela signifie : Le Spoke A route le trafic vers le Bureau B via wg0.

Décision : S’il essaie de sortir par l’interface WAN, le AllowedIPs du hub pour le peer du spoke est manquant pour les sous-réseaux du Bureau B.

Tâche 6 : Vérifier que les règles nftables sont chargées (hub)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		iif "lo" accept
		ct state established,related accept
		udp dport 51820 accept
		ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } tcp dport 22 accept
		ip protocol icmp accept
	}
	chain forward {
		type filter hook forward priority filter; policy drop;
		ct state established,related accept
		ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } ip daddr 10.10.0.0/16 accept
		limit rate 5/second log prefix "vpn-forward-drop " flags all counter drop
	}
}

Ce que cela signifie : Votre politique existe et est appliquée avec un drop par défaut.

Décision : Si les règles ne sont pas présentes, vous ne chargez pas nftables au démarrage ou un autre outil l’a écrasé. Corrigez l’ordre des services avant d’ajouter d’autres règles.

Tâche 7 : Trouver pourquoi un flux est bloqué en utilisant compteurs et logs

cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } ip daddr 10.10.0.0/16 accept
    limit rate 5/second log prefix "vpn-forward-drop " flags all counter packets 41 bytes 2460 drop
  }
}

Ce que cela signifie : 41 paquets forward ont été dropés par la règle catch-all.

Décision : Si des utilisateurs signalent des problèmes d’accès et que ce compteur augmente pendant leur test, vous avez besoin d’une règle d’autorisation explicite (ou vous observez du trafic inattendu qui doit rester bloqué).

Tâche 8 : Confirmer la joignabilité UDP 51820 depuis un spoke

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:44:01.102938 IP 198.51.100.22.39422 > 203.0.113.10.51820: UDP, length 148
12:44:01.128440 IP 203.0.113.10.51820 > 198.51.100.22.39422: UDP, length 92

Ce que cela signifie : Les paquets arrivent et les réponses repartent. La joignabilité de base est OK.

Décision : Si vous voyez des arrivées mais pas de sorties, suspectez le pare-feu du hub. Si vous ne voyez rien d’entrant, suspectez un NAT en amont/forwarding de port ou une IP d’endpoint incorrecte.

Tâche 9 : Valider que le NAT n’est pas appliqué par accident au trafic VPN

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth0" masquerade
  }
}

Ce que cela signifie : Tout ce qui sort par eth0 est NATé, ce qui peut inclure le trafic routé VPN si cela transite par le hub.

Décision : Si vous voulez un trafic bureau-à-bureau purement routé, assurez-vous que le trafic inter-bureaux reste sur wg0 et ne fait pas de hairpin vers eth0. Si vous faites un breakout Internet central, le NAT peut être correct — mais vous devez alors planifier la bande passante et la journalisation en conséquence.

Tâche 10 : Détecter les trous MTU avec ping + DF

cr0x@server:~$ ping -M do -s 1372 10.10.20.10 -c 3
PING 10.10.20.10 (10.10.20.10) 1372(1400) bytes of data.
1380 bytes from 10.10.20.10: icmp_seq=1 ttl=62 time=18.9 ms
1380 bytes from 10.10.20.10: icmp_seq=2 ttl=62 time=18.7 ms
1380 bytes from 10.10.20.10: icmp_seq=3 ttl=62 time=18.8 ms

--- 10.10.20.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Ce que cela signifie : Un paquet de 1400 octets (headers inclus) passe sans fragmentation. Bon signe.

Décision : Si cela échoue à des tailles bien inférieures à 1400, baissez le MTU WireGuard et retestez, ou arrêtez de bloquer l’ICMP « frag needed » en amont.

Tâche 11 : Confirmer que le reverse path filtering ne droppe pas le trafic VPN routé

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

Ce que cela signifie : Le reverse-path filtering strict est désactivé globalement (0) ce qui est souvent nécessaire pour des scénarios de routage multi-homed.

Décision : Si rp_filter est 1 ou 2 et que vous observez du trafic unidirectionnel, ajustez-le (prudemment) sur les interfaces pertinentes. Ne désactivez pas la sécurité aveuglément ; comprenez d’abord l’asymétrie du routage.

Tâche 12 : Vérifier que les routes côté LAN existent de retour vers les sous-réseaux distants

cr0x@server:~$ ip route | grep 10.10.20.0/24
10.10.20.0/24 via 10.10.10.1 dev eth1

Ce que cela signifie : Un hôte sur le LAN du Bureau A sait envoyer le trafic vers le Bureau B via la gateway locale (10.10.10.1).

Décision : Si les clients du bureau n’ont pas de route, soit faites annoncer les routes via le routeur du bureau, soit faites de la passerelle Linux la gateway par défaut pour ces VLANs. Le routage VPN échoue si seuls les gateways connaissent les routes.

Tâche 13 : Vérifier l’état conntrack pour un flux spécifique

cr0x@server:~$ sudo conntrack -L -p tcp --dport 443 2>/dev/null | head
tcp      6 431999 ESTABLISHED src=10.10.11.22 dst=10.10.50.10 sport=53422 dport=443 src=10.10.50.10 dst=10.10.11.22 sport=443 dport=53422 [ASSURED] mark=0 use=1

Ce que cela signifie : Le hub voit un flux TCP établi entre un client Finance et le service comptable.

Décision : Si les utilisateurs se plaignent de resets/timeouts mais que conntrack ne montre jamais ESTABLISHED, suspectez des drops pare-feu, du routage ou du MTU. S’il montre ESTABLISHED mais que l’appli est lente, regardez la congestion/la perte de paquets.

Tâche 14 : Confirmer que l’heure est correcte (les handshakes détestent les voyages dans le temps)

cr0x@server:~$ timedatectl status | sed -n '1,8p'
Local time: Sun 2025-12-28 10:25:44 UTC
Universal time: Sun 2025-12-28 10:25:44 UTC
RTC time: Sun 2025-12-28 10:25:44
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Ce que cela signifie : L’horloge est synchronisée. Bien.

Décision : Si l’heure est décalée, corrigez NTP en priorité. Des problèmes de handshake et de corrélation de logs bizarres sont garantis quand les horloges dérivent.

Playbook de diagnostic rapide

Quand le téléphone sonne et que quelqu’un dit « le VPN est down », il veut généralement dire « une application est cassée ». Ne déboguez pas l’application en premier. Déboguez le chemin.

Premier point : le tunnel est-il vivant ?

• Sur le hub : wg show — vérifiez latest handshake pour le spoke affecté.
• Sur le spoke : wg show — confirmez qu’il parle à l’endpoint du hub et que les compteurs augmentent pendant un test.
• Si le handshake est périmé : vérifiez la joignabilité UDP, l’IP/port de l’endpoint, le keepalive NAT, et tout changement récent chez l’ISP/routeur.

Second point : le routage est-il correct aux deux bouts ?

• Sur le spoke : ip route get <remote-ip> — doit sélectionner wg0.
• Sur le hub : ip route get <destination> — assurez-vous qu’il pointe vers le peer correct via wg0.
• Vérifiez le LAN du bureau : les clients ont-ils des routes de retour via la gateway locale ?

Troisième point : le pare-feu fait-il ce que vous lui avez dit ?

• Sur le hub : nft list chain inet filter forward — surveillez les compteurs pendant la reproduction.
• Cherchez les drops correspondant aux sous-réseaux/ports concernés.
• Ajoutez temporairement une règle d’autorisation étroite (source subnet + destination + port) pour confirmer l’hypothèse. Revenez en arrière si cela ne prouve rien.

Quatrième point : est-ce un problème MTU/fragmentation ?

• Utilisez des tests ping -M do -s à travers le VPN.
• Si les petits paquets fonctionnent et les gros échouent ou stagnent : ajustez le MTU WireGuard et/ou corrigez le filtrage ICMP.

Cinquième point : est-ce le DNS ?

• Si les utilisateurs peuvent pinguer des IP mais pas des noms, arrêtez de toucher aux routes.
• Vérifiez les résolveurs, les forwarders conditionnels et les paramètres split-DNS. Confirmez que le serveur DNS est joignable depuis le sous-réseau du rôle.

L’idée est la rapidité : tunnel → route → pare-feu → MTU → DNS. Dans cet ordre. À chaque fois.

Erreurs courantes : symptôme → cause racine → correction

« Le tunnel est up mais je n’arrive à rien atteindre »

Symptôme : wg show affiche des handshakes ; les pings vers le LAN distant échouent.

Cause racine : IP forwarding désactivé sur hub ou spoke, ou routes côté LAN manquantes.

Correction : Activez net.ipv4.ip_forward=1. Assurez-vous que les clients des bureaux routent les sous-réseaux distants via la gateway locale ; ne supposez pas qu’ils le sauront magiquement.

« Le Bureau A peut atteindre le Bureau B, mais pas l’inverse »

Symptôme : Connectivité unidirectionnelle ; sessions TCP bloquées.

Cause racine : Routage asymétrique ou rp_filter ; aussi possible des problèmes d’état de pare-feu.

Correction : Vérifiez les routes des deux côtés et du hub. Réglez rp_filter convenablement sur les gateways multi-homed. Vérifiez que les règles forward du hub autorisent les deux sens ou utilisent established/related.

« Seulement certaines applis échouent ; les transferts de fichiers stagnent ; SSH marche »

Symptôme : Les petits paquets réussissent ; les charges utiles volumineuses expirent.

Cause racine : Trou noir MTU / fragmentation, souvent causé par ICMP bloqué en amont.

Correction : Mettez mtu 1420 (ou moins) sur wg0. Testez avec ping -M do. Corrigez le filtrage ICMP si possible.

« Un nouveau routeur de bureau a été installé et maintenant le VPN flapit »

Symptôme : Handshakes intermittents ; compteurs de trafic gelés puis qui bondissent.

Cause racine : Timeout NAT ou changement du traitement UDP ; keepalive manquant.

Correction : Mettez PersistentKeepalive = 25 sur les spokes derrière NAT. Vérifiez que le port du hub est joignable et pas remappé de façon inattendue.

« Finance peut accéder aux services ingénierie (oups) »

Symptôme : Des utilisateurs atteignent des ressources qu’ils ne devraient pas ; pas de refus de pare-feu évident.

Cause racine : Règle allow trop large, ou dépendre de AllowedIPs comme « politique ».

Correction : Implémentez un drop par défaut dans la chaîne forward du hub et ajoutez des allow explicites par rôle. Gardez les règles d’autorisation étroites : sous-réseau source, sous-réseau destination, ports.

« Après un reboot, rien ne route jusqu’à ce que quelqu’un exécute une commande »

Symptôme : Ça marche après intervention manuelle.

Cause racine : Ordonnancement des services : WireGuard up avant sysctl/nftables, ou nftables non chargé.

Correction : Assurez la persistance des sysctl, activez le service nftables, et faites dépendre le démarrage de WireGuard de la disponibilité réseau. Testez un cold boot, pas seulement des redémarrages chauds.

« Le DNS est lent entre sites »

Symptôme : La première requête prend des secondes ; ensuite ça va.

Cause racine : Le résolveur essaie d’abord des serveurs DNS injoignables (ordre erroné), ou fragmentation UDP pour les réponses DNS.

Correction : Assurez-vous que les clients utilisent en priorité le DNS interne joignable. Envisagez le fallback TCP pour le DNS et corrigez le MTU si nécessaire.

Trois mini-histoires d’entreprise issues du terrain

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

Une entreprise de taille moyenne a connecté trois bureaux avec un joli hub WireGuard. Le diagramme réseau était propre. Le plan de déploiement était simple : installer les passerelles, ajouter les routes, célébrer.

L’hypothèse était du type qu’on ne remarque qu’après douleur : « les clients apprendront les routes automatiquement ». Les gateways avaient les bonnes routes. Le hub avait les bons AllowedIPs. Les handshakes étaient frais. Les pings entre gateways fonctionnaient. Mais les utilisateurs ne pouvaient rien atteindre à travers le VPN à moins d’être sur un sous-réseau où la gateway était la route par défaut.

Le helpdesk a escaladé en « VPN down ». L’SRE de garde a vérifié WireGuard d’abord, l’a trouvé sain, et a perdu une heure à chasser des problèmes pare-feu fantômes parce que « tunnel up » implique habituellement « les chemins existent ». Ce n’était pas le cas.

La correction fut douloureusement ordinaire : mettre à jour les routeurs de bureau pour annoncer des routes statiques vers les autres bureaux via la gateway VPN locale (ou faire de la gateway VPN la gateway par défaut pour les VLANs de rôle). Après cela, tout a « magiquement » fonctionné, ce à quoi ressemble un routage fait correctement.

La leçon : quand vous déployez un VPN routé, votre LAN doit participer. Si votre routeur edge de bureau ne sait pas où se trouve 10.10.20.0/24, vos clients non plus. Les réseaux ne lisent pas les pensées.

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

Une autre organisation a voulu être ambitieuse. Ils voulaient réduire la latence entre les Bureaux B et C, alors ils ont ajouté un tunnel direct spoke-à-spoke WireGuard « juste pour le trafic lourd ». Le hub restait le chemin officiel. Le tunnel direct était la « voie rapide ».

Ça a bien fonctionné en labo. En production, ça a créé une seconde vérité de routage. Certains sous-réseaux préféraient le tunnel direct ; d’autres suivaient le hub. Les politiques de pare-feu vivaient sur le hub, si bien que maintenant le trafic passait soit en dehors de la politique soit se voyait dropé selon le chemin choisi ce jour-là.

Puis est venue la panne la plus étrange : les partages de fichiers fonctionnaient de B vers C mais pas de C vers B, et seulement pour des utilisateurs d’un VLAN. Ils avaient accidentellement créé un routage asymétrique : les paquets de requête prenaient le chemin direct, les réponses revenaient via le hub. Les pare-feu stateful n’apprécient pas la créativité.

L’« optimisation » a été retirée. Ils sont revenus au hub-and-spoke, puis ont amélioré les performances d’une manière ennuyeuse : correct MTU, QoS sur l’edge WAN, et arrêter les backups pendant les heures de travail. La latence s’est améliorée, et surtout la prévisibilité est revenue.

La leçon : dans les réseaux multi-site, « un tunnel de plus » n’est presque jamais « juste un tunnel de plus ». C’est un univers de routage supplémentaire.

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

Une troisième entreprise traitait son hub comme un vrai service de production. Ils gardaient les configs en contrôle de version. Chaque changement avait une petite description et un impact attendu. Ils avaient aussi une page « diagnostic VPN rapide » collée dans le carnet de garde, comme si c’était 2004 et que les imprimantes comptaient encore.

Un après-midi, le Bureau A a perdu l’accès à une application interne hébergée au Bureau C. Le tunnel était up. L’appli était up. Les gens ont commencé à pointer du doigt « le VPN » et « le pare-feu » comme s’il s’agissait d’humeurs.

L’ingénieur de garde a suivi le runbook : a vérifié les handshakes (frais), vérifié le routage (correct), vérifié les compteurs nftables forward (drops en augmentation sur la règle de drop par défaut). Cela a réduit le diagnostic à la politique. Le dernier changement était une règle d’autorisation resserrée pour l’Ingénierie qui excluait accidentellement un sous-réseau utilisé par cette application.

Ils ont reverté la règle en quelques minutes, restauré le service, puis réintroduit une règle corrigée avec un plan de test approprié. L’incident est resté petit parce que leurs changements étaient traçables et que leur ordre de débogage était discipliné.

La leçon : l’hygiène ennuyeuse — configs versionnées, changements étroits, et ordre de diagnostic déterministe — bat l’héroïsme. À chaque fois.

Listes de vérification / plan étape par étape

Plan de construction étape par étape (faites ceci, dans cet ordre)

1. Corrigez les chevauchements IP : assurez-vous que chaque bureau a des sous-réseaux uniques. Si ce n’est pas le cas, renumérotez maintenant. Ne vous « NATez temporairement » pas en dette technique permanente.
2. Définissez les sous-réseaux de rôle : créez des VLANs/sous-réseaux par rôle quand possible. Commencez par IT/Admin et Finance ; ajoutez d’autres seulement si nécessaire.
3. Provisionnez le hub : IP publique stable, Linux, WireGuard, nftables, NTP, journalisation, agent de monitoring.
4. Provisionnez les trois spokes : chacun avec WireGuard et capacité de router entre le LAN et wg0.
5. Générez les clés : une paire de clés par passerelle (et éventuellement par rôle ou par appareil si vous étendez plus tard).
6. Configurez WireGuard : peers hub pour chaque spoke avec AllowedIPs corrects ; spokes pointant vers l’endpoint hub avec les sous-réseaux distants dans AllowedIPs.
7. Activez le forwarding et les sysctls de base : ip_forward, réglage rp_filter si nécessaire.
8. Installez le routage sur le LAN du bureau : le routeur du bureau annonce les routes pour les autres sous-réseaux via la gateway VPN locale, ou la gateway VPN devient la gateway VLAN.
9. Implémentez le pare-feu hub : drop par défaut pour forward, autorisations explicites par rôle. Gardez un jeu de règles « break-glass » temporaire que vous pouvez appliquer en cas d’incident sévère.
10. Plan DNS : décidez central vs forwarding conditionnel. Testez la résolution des noms depuis chaque VLAN de rôle.
11. Validation MTU : définissez le MTU wg (départ 1420), testez pings de gros paquets et charges réelles (copie de fichiers, HTTPS, base de données).
12. Monitoring : suivez l’âge des handshakes, les débits, les drops (compteurs nft), erreurs d’interface, CPU et bande passante.
13. Documentez : plan IP, règles de rôle, propriété des clés, et l’ordre de diagnostic rapide. Votre futur vous est un intervenant.

Checklist avant changement (à chaque modification de politique)

• Sais-je quels sous-réseaux/rôles sont impactés ?
• Ai-je un cas de test (IP source, IP destination, port) pour valider ?
• Ai-je vérifié les compteurs/logs actuels pour établir une base ?
• Le changement est-il étroit (moindre privilège) et réversible ?
• Ai-je un accès console si je me verrouille hors du hub ?

Checklist post-changement (prouvez-le, ne l’assumez pas)

• wg show sur le hub : tous les peers ont toujours des handshakes
• Ping et un test applicatif par rôle (Finance, Ingénierie, IT)
• Vérifiez les compteurs nftables : l’incrément attendu des règles allow ; la règle drop stable
• Validez la résolution DNS pour les zones internes
• Enregistrez le changement et l’impact observé

FAQ

1) Dois-je faire du full-mesh au lieu du hub-and-spoke ?

Pour trois bureaux, vous pouvez, mais vous le regretterez quand vous ajouterez des règles basées sur les rôles et aurez besoin d’une application cohérente. Le hub-and-spoke centralise la politique et simplifie le dépannage.

2) Puis-je appliquer les rôles uniquement avec AllowedIPs ?

Pas de manière fiable. AllowedIPs est grossier et concerne principalement le routage et le cadrage des peers. Utilisez nftables sur le hub pour appliquer l’accès par rôle, car c’est là que vous pouvez exprimer « Finance peut atteindre ces ports sur ces sous-réseaux ».

3) Où doivent vivre les règles d’accès : hub ou spokes ?

Placez la politique canonique sur le hub. Vous pouvez ajouter des règles locales d’egress sur les spokes pour une défense en profondeur, mais ne transformez pas la politique en puzzle distribué sauf si vous aimez le comportement incohérent.

4) Ai-je besoin de BGP/OSPF pour trois sites ?

Non. Le routage statique suffit et est souvent meilleur pour la prévisibilité. Le routage dynamique peut être utile plus tard, mais il ajoute un second plan de contrôle à déboguer. Gagnez cette complexité.

5) Comment gérer des sous-réseaux qui se chevauchent si renuméroter est politiquement impossible ?

Vous pouvez utiliser du NAT (1:1 ou masquerade) aux spokes, mais traitez cela comme une dette technique avec intérêts. Documentez les translations, attendez des cas limites applicatifs, et planifiez un projet de renumérotation de toute façon.

6) Dois-je héberger le hub dans le cloud ou sur site ?

Le cloud est souvent plus simple pour une IP publique stable, une bonne bande passante et des mains distantes. Sur site peut convenir si vous avez une redondance internet et d’alimentation. Le facteur décisif est la maturité opérationnelle, pas l’idéologie.

7) Comment ajouter des utilisateurs distants plus tard sans casser le modèle site-to-site ?

Ajoutez une interface WireGuard ou un groupe de peers séparé pour les utilisateurs distants, assignez-leur un subnet dédié (par ex. 10.200.10.0/24), et appliquez les règles de rôle sur le hub de la même façon. Évitez de mélanger les road-warriors dans la même pool d’adresses que les passerelles.

8) Que fait « PersistentKeepalive » et quand en ai-je besoin ?

Il envoie périodiquement des paquets pour maintenir les mappings NAT actifs. Utilisez-le sur les spokes derrière NAT (commun) et sur les clients nomades. Inutile sur le hub avec IP publique à moins d’une raison spécifique.

9) Comment rendre cela hautement disponible ?

Exécutez deux hubs et utilisez soit anycast/BGP (avancé) soit DNS + outil de bascule (plus simple), plus des tunnels doubles depuis chaque spoke. Gardez l’état minimal (WireGuard est plutôt sans état), mais votre pare-feu et DNS doivent aussi être redondants.

10) Que dois-je logger sans me noyer dans les données ?

Loggez les forwards dropés avec rate limit sur le hub, suivez l’âge des handshakes et les compteurs de trafic, et capturez les changements de configuration. Ne logguez pas chaque paquet accepté ; votre système de stockage mérite mieux.

Prochaines étapes pour calmer le lundi

Si vous voulez un VPN qui se comporte comme une infrastructure plutôt que comme un tour de magie, construisez-le comme une infrastructure : sous-réseaux uniques, design routé, politique centrale et observabilité. Le hub-and-spoke WireGuard est un modèle solide pour trois bureaux, surtout quand vous avez besoin d’accès par rôle plutôt que « tout le monde voit tout ».

Prochaines étapes pratiques :

• Écrivez le plan IP et les sous-réseaux de rôle, puis assurez l’unicité entre les bureaux.
• Déployez le hub avec WireGuard + nftables et forward par défaut-drop.
• Montez un spoke, validez le routage de bout en bout, puis clonez le modèle pour les deux autres.
• Implémentez des règles de rôle comme des allow explicites, surveillez les compteurs, et gardez un rollback prêt.
• Ajoutez du monitoring pour l’âge des handshakes, la bande passante et les compteurs de drop, et gardez l’ordre de diagnostic rapide à portée de main.

Vous aurez encore des tickets. Mais ce seront des tickets résolubles, pas des tickets surnaturels.