VPN site-à-site : connecter deux bureaux en un seul réseau (plan simple et efficace)

Ce que vous voulez réellement (et ce que vous voulez probablement pas)

Quand les gens disent « connecter deux bureaux en un seul réseau », ils veulent généralement une ou plusieurs des choses suivantes :

• Les utilisateurs du bureau B peuvent atteindre des applications internes hébergées au bureau A (et réciproquement).
• Les deux sites peuvent atteindre une infrastructure partagée : AD/LDAP, partages de fichiers, Git, supervision, VoIP, imprimantes (oui, encore).
• Politiques d’accès cohérentes : « Les RH peuvent atteindre les systèmes RH » quelle que soit la qualité du café du bâtiment.
• Performances stables et modes de défaillance prévisibles.

Ce qu’ils pensent vouloir, c’est « faire comme si on avait étiré un switch entre les bâtiments ». Ne faites pas ça. L’extension L2 sur Internet est la manière dont vous vous retrouvez à dépanner des tempêtes de broadcast avec le directeur financier dans la pièce.

Votre objectif est simple : router le trafic entre deux (ou plusieurs) réseaux IP bien définis sur un tunnel chiffré, avec des frontières claires, un DNS cohérent et suffisamment d’observabilité pour répondre à « qu’est-ce qui est cassé ? » en moins de cinq minutes.

Et souvenez-vous : un VPN n’est pas un portail magique vers la productivité. C’est un transport. Si vos applications ne tolèrent pas la latence, la perte de paquets ou des liaisons intermittentes, le tunnel rendra simplement la douleur géographiquement répartie.

Petite blague #1 : Un VPN n’« accélère » pas les réseaux, mais il fait voyager le blâme à la vitesse du câble.

Quelques faits et un peu d’histoire qui expliquent les pièges actuels

Un peu de contexte aide, parce que la moitié des problèmes vient d’idées héritées qui survivent bien au-delà de leur utilité.

1. IPsec précède la « pensée cloud » moderne. Les standards de base datent du milieu à la fin des années 1990 ; beaucoup de vendors livrent encore des présupposés de cette époque.
2. IKEv1 vs IKEv2 importe. IKEv2 (milieu des années 2000) a corrigé des problèmes réels : complexité de négociation, mobilité et stabilité. Si vous avez le choix, prenez IKEv2.
3. NAT traversal (NAT-T) existe parce qu’Internet a été NATé. IPsec ESP ne s’accommode pas bien du NAT ; l’encapsulation UDP (généralement port 4500) a été la solution pratique.
4. « VPN sur UDP » n’est pas nouveau. L2TP/IPsec puis WireGuard ont adopté l’UDP parce qu’il se comporte mieux à travers les middleboxes que l’ESP pur dans de nombreux environnements.
5. WireGuard est volontairement minimal. Il a été conçu pour être auditable et compact comparé aux piles IPsec traditionnelles. C’est un avantage opérationnel réel.
6. BGP sur tunnels est plus ancien que votre pare-feu actuel. Les opérateurs exécutent du routage dynamique sur des liens encapsulés depuis des décennies ; ce n’est pas excessif quand vous avez besoin d’un basculement propre.
7. La douleur MTU est historique, pas une faute personnelle. L’encapsulation ajoute de l’overhead ; la découverte PMTU est souvent bloquée ou maltraitée ; « ça marche sur mon ping » ment depuis toujours.
8. Les réseaux d’entreprise étaient autrefois fiables par défaut. L’ère du LAN plat a laissé beaucoup d’organisations avec un accès interne large. Un VPN site-à-site peut recréer ça accidentellement, à l’échelle d’Internet.

Choisir une topologie qui échoue proprement

The default: routed site-to-site (hub-and-spoke or point-to-point)

Pour deux bureaux, un tunnel routé simple suffit généralement : le bureau A a une passerelle, le bureau B a une passerelle, et vous routez les sous-réseaux A vers les sous-réseaux B via le tunnel.

Si vous ajoutez d’autres sites plus tard, choisissez un hub-and-spoke tôt : un ou deux hubs (data center ou cloud), des spokes pour les bureaux. Cela simplifie la politique et la supervision, et évite le « maillage complet de tristesse » où chaque bureau doit établir des tunnels séparés vers tous les autres.

IPsec vs WireGuard (avis)

Si vous avez déjà des pare-feux d’entreprise et avez besoin d’un support vendor : utilisez IPsec avec IKEv2. C’est omniprésent, interopérable, peut être HA et les auditeurs le reconnaissent.

Si vous voulez la simplicité et contrôlez les deux extrémités : WireGuard est difficile à battre. Moins de négociation. Moins de pièces en mouvement. Le debug est plus « paquets entrants/paquets sortants » et moins « la phase 1 est up mais la phase 2 est hantée ».

Dans tous les cas, ne choisissez pas sur la base d’un seul benchmark. Choisissez selon ce que vous pouvez exploiter à 3h du matin, et ce que vous pouvez remplacer proprement.

Layer 2 bridging: the trap

Réaliser un pont L2 entre les réseaux de bureaux sur un VPN semble séduisant quand on veut « zéro changement ». C’est aussi la façon dont vous transportez chaque broadcast, ARP et boucle accidentelle à travers un tunnel. Routez. Toujours routez. Si quelqu’un insiste pour du L2, qu’il assume l’appel d’incident.

Listes de contrôle / plan étape par étape (le plan simple qui marche)

Phase 0 : prérequis avant de toucher au tunnel

• Choisissez des sous-réseaux non chevauchants. Si le bureau A utilise 192.168.1.0/24, le bureau B ne doit pas. Ce n’est pas négociable.
• Définissez quels sous-réseaux doivent communiquer. « Tout vers tout » est paresseux et dangereux.
• Choisissez un modèle de routage. Routes statiques pour les petits réseaux stables. BGP si vous avez besoin de basculement ou prévoyez de croître.
• Choisissez une méthode d’authentification. La clé pré-partagée (PSK) va pour de petites configurations ; les certificats montent mieux en charge et tournent proprement.
• Inventoriez NAT et pare-feux. Sachez qui possède les IP publiques, quels ports sont autorisés et si un des côtés est derrière un carrier-grade NAT.

Phase 1 : plan IP et politique de trafic

Faites ceci sur papier d’abord :

• Bureau A LAN : par ex. 10.10.0.0/16
• Bureau B LAN : par ex. 10.20.0.0/16
• Plages d’infrastructure réservées (serveurs, VoIP, imprimantes) avec des sous-réseaux plus petits pour la clarté
• Décidez si les clients doivent sortir vers Internet localement (split tunnel) ou via un egress centralisé (full tunnel)

Avis : Pour deux bureaux, par défaut privilégiez le split tunnel sauf si vous avez une exigence de conformité pour centraliser l’egress. Le full tunnel via site-à-site est un excellent moyen de transformer un incident ISP local en incident global.

Phase 2 : configuration du tunnel (minimum viable, orienté production)

• Chiffrement : utilisez des suites modernes. Évitez les algorithmes obsolètes et le « parce que c’est compatible ». Si vous êtes coincé par compatibilité, isolez et planifiez une mise à niveau.
• Perfect Forward Secrecy : activez-le.
• Intervalles de rekey : conservez les valeurs par défaut sauf raison ; un rekeying trop agressif peut créer des coupures périodiques.
• DPD/keepalives : activez la détection de pairs morts pour échouer vite.
• Règles de pare-feu : autorisez uniquement le trafic nécessaire sur le tunnel (par sous-réseau et port), puis élargissez volontairement.

Phase 3 : routage et DNS

• Routage : installez les routes sur les passerelles (ou via BGP). Confirmez avec traceroute que le chemin passe par le tunnel.
• DNS : faites fonctionner la résolution de noms entre sites. C’est là que « le tunnel est up mais l’appli est down » survit.
• Synchronisation temporelle : assurez-vous que les deux sites ont un NTP fiable. La validation de certificats et Kerberos n’aiment pas le voyage dans le temps.

Phase 4 : durcissement et observabilité

• Journalisez les changements d’état du tunnel et les événements de rekey.
• Surveillez la perte de paquets et la latence entre hôtes représentatifs, pas seulement « tunnel up ».
• Consignez les réglages MTU/MSS et validez-les avec des transferts réels.
• Documentez : sous-réseaux, routes, ports autorisés, responsabilités et plan de rollback.

Phase 5 : tester comme un pessimiste

• Simulez une panne d’ISP sur un site (désactivez le WAN, testez le lien de secours si existant).
• Testez la résolution DNS depuis les deux sites vers les services partagés.
• Testez des transferts de fichiers volumineux et des connexions longues (appels VoIP, sessions RDP/SSH, connexions BD).
• Testez après un rekey (attendez au moins un intervalle de rekey).

Routage : statique vs dynamique, et la règle unique à ne pas enfreindre

The one rule: no overlapping IP space

Si la même plage RFC1918 existe des deux côtés, vous finirez par vous NATer dans un coin. Parfois cela marche quelques semaines. Puis vous ajoutez un troisième site, ou un VPC cloud, ou un VPN prestataire, et tout devient une aventure dont la fin est un routage cassé.

Renumérotation est pénible. Mais reste plus simple que des rustines NAT permanentes.

Routage statique : bon pour les petits réseaux stables

Si chaque bureau n’a qu’un lien WAN et vos sous-réseaux changent peu, les routes statiques conviennent. Elles sont simples, débogables et n’exigent pas de daemons de routage.

Le routage statique échoue quand :

• Vous ajoutez de la redondance et voulez un basculement propre.
• Vous ajoutez des réseaux et oubliez une route d’un côté (ça arrive).
• Vous comptez sur des humains pour mettre à jour les routes pendant un incident (les humains sont peu fiables sous stress, y compris moi-même).

BGP : pas obligatoire, mais souvent l’outil le plus propre pour le failover

Si vous avez deux tunnels (ou deux ISPs) et voulez que le trafic bascule rapidement, BGP en vaut la peine. Vous pouvez faire tourner BGP sur IPsec ou WireGuard, n’échanger que les préfixes souhaités et laisser le protocole gérer le basculement.

Gardez-le conservateur :

• Utilisez des prefix-lists.
• Utilisez des limites max-prefix.
• Utilisez des route-maps pour prévenir un « oups, j’ai annoncé 0.0.0.0/0 ».

Petite blague #2 : BGP, c’est comme les ragots en entreprise : puissant, rapide et il répandra absolument la mauvaise chose si vous ne fixez pas de limites.

DNS et identité : le tueur silencieux

La plupart des « problèmes VPN » sont en réalité des problèmes DNS déguisés en VPN. Le tunnel est up. La route existe. Mais les utilisateurs ne peuvent pas atteindre intranet, l’authentification échoue, ou un client de base de données cale.

Décidez votre modèle de nommage

• Domaine interne unique (commun dans les environnements AD) : les deux bureaux résolvent les mêmes zones internes.
• DNS split-horizon : les noms se résolvent différemment selon le site source.
• Nommage de service explicite : les applis utilisent des FQDN pointant vers des VIP locaux au site ou des load balancers globaux ; moins de concept « bureau ».

Rendez le DNS résilient à travers le tunnel

Au minimum :

• Chaque site devrait avoir des résolveurs DNS locaux.
• Les résolveurs devraient forwarder ou répliquer les zones selon les besoins.
• Les clients ne devraient pas dépendre du « DNS de l’autre site » comme primaire. C’est ainsi qu’un incident WAN devient une tempête d’authentification.

Les systèmes d’identité détestent la connectivité partielle

Kerberos, LDAP et l’authentification basée sur certificats peuvent échouer de façon à sembler être des « lenteurs aléatoires ». Si le DNS bascule entre A et B, vous pouvez obtenir des timeouts d’authentification intermittents. Gardez les services d’identité locaux quand c’est possible, ou concevez un basculement explicite avec health checks.

MTU, MSS, et pourquoi « ça ping » est dénué de sens

L’encapsulation ajoute des octets. IPsec ajoute de l’overhead (en-têtes ESP, possible encapsulation UDP). WireGuard ajoute aussi de l’overhead. Si vous n’en tenez pas compte, vous créez un type particulier de panne : les petits paquets fonctionnent, les gros stagnent. Les utilisateurs rapportent « certains sites se chargent, les partages de fichiers plantent, les appels vidéo figent ». Vous commencez à blâmer les équipes applicatives. C’est le MTU.

Conseils pratiques

• Supposez que votre MTU effectif sur le tunnel est inférieur à 1500.
• Clampez le MSS TCP sur le bord du tunnel si possible (courant sur les pare-feux et routeurs). C’est un instrument brutal, mais il évite la misère liée à la fragmentation.
• Testez avec ping en mode « ne pas fragmenter » et des tailles de charge réalistes.

Objectif visé

Vous voulez un chemin où TCP peut établir des sessions et transférer de gros volumes sans blackholing. Si PMTUD est bloqué sur le chemin (courant), le clamp MSS vous évite souvent une semaine de réunions inutiles.

Posture de sécurité : le chiffrement n’est pas du contrôle d’accès

Un VPN site-à-site chiffre le trafic entre passerelles. Il ne décide pas qui doit accéder à quoi. C’est votre travail.

Ne faites pas du « autre bureau » une zone de confiance

Beaucoup de réseaux traitent le sous-réseau distant comme s’il s’agissait d’un VLAN local. Alors un laptop compromis au bureau B peut sonder des serveurs au bureau A. Le chiffrement protège fidèlement le trafic de l’attaquant. Ce n’est pas le gain que vous voulez.

Ségrégation minimale viable

• N’autorisez que les flux subnet-à-subnet nécessaires (ex. clients vers sous-réseaux applicatifs, appli vers BD).
• Bloquez l’est-ouest entre VLAN clients par défaut.
• Journalisez les flux refusés pendant le déploiement pour ajuster sans conjectures.

Gestion et rotation des clés

Pour IPsec PSK : traitez-les comme des mots de passe ; faites-les tourner, stockez-les dans un gestionnaire de secrets et n’envoyez pas par email. Pour les certificats : automatisez l’émission et le renouvellement si possible. Les certificats expirés sont le type de panne qui semble personnelle.

Idée paraphrasée (Werner Vogels, opérations/fiabilité) : « Concevez les systèmes en supposant que les choses tombent en panne ; la résilience vient de ce design. »

Haute disponibilité : ce que « redondant » signifie vraiment

La redondance est une chaîne, et le maillon le plus faible est souvent « un seul ISP ». Vous pouvez construire une paire VPN HA et avoir quand même un engin de pelleteuse qui vous coupe.

Patrons HA qui marchent réellement

• Double WAN à chaque site (idéalement opérateurs différents, chemins physiques différents).
• Deux passerelles VPN (active/standby ou active/active) avec synchronisation d’état si supportée.
• Deux tunnels (un par WAN) avec basculement de routage (BGP préféré, ou routes statiques suivies).

Méfiez-vous du « HA qui échoue pendant le basculement »

Mode de défaillance courant : HA est configuré, mais personne ne l’a jamais testé. Puis le lien primaire tombe, le tunnel bascule, et les sessions longues meurent. Les utilisateurs appellent ça « le VPN est instable ». Le VPN fait ce que vous avez demandé. Vous avez demandé une bascule sans tolérance applicative.

Soyez explicite sur ce que vous promettez :

• « Basculement sous 30 secondes, les sessions TCP existantes peuvent être réinitialisées. » (honnête)
• « Aucun impact perceptible. » (rare, coûteux, et nécessite plus qu’un VPN)

Supervision et SLO pour le tunnel (oui, vraiment)

Si votre supervision se résume à « le tunnel est up », vous apprendrez la perte de paquets via Slack. Ce n’est pas de l’observabilité ; c’est du crowd-sourcing pour la détection d’incidents.

Que mesurer

• État : tunnel établi, événements de rekey, flaps.
• Latence : RTT entre hôtes représentatifs à travers le tunnel.
• Perte : pourcentage de perte de paquets, idéalement à plusieurs tailles de paquets.
• Débit : tests iperf périodiques entre deux endpoints de test (planifiés, limités en taux).
• Erreurs : drops d’interface, compteurs de fragmentation, refus de pare-feu sur le tunnel.

Fixer des attentes (SLO léger)

Exemple : « Connectivité inter-bureaux : 99,9 % de disponibilité mensuelle ; RTT p95 sous 40 ms en heures ouvrées ; perte de paquets sous 0,5 %. » Adaptez à la réalité. Puis alertez quand vous violez ces objectifs, pas quand quelqu’un se plaint.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces tâches sont centrées Linux car Linux dit honnêtement ce qu’il fait. Même si vos passerelles sont des appliances, vous pouvez exécuter ces vérifications depuis des hôtes de test de chaque côté.

Task 1: Confirm your local IP and route to remote subnet

cr0x@server:~$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.10.12.34/24 brd 10.10.12.255 scope global eth0
       valid_lft forever preferred_lft forever

cr0x@server:~$ ip route get 10.20.8.50
10.20.8.50 via 10.10.12.1 dev eth0 src 10.10.12.34 uid 1000
    cache

Que cela signifie : Votre hôte pense que le trafic vers 10.20.8.50 va vers la gateway locale (10.10.12.1). Bien. Si au lieu de ça il route vers une autre interface (ou une route par défaut inattendue), vous dépannez la mauvaise machine.

Décision : Si la route est mauvaise, corrigez le routage local / option DHCP 121 / routes statiques avant de toucher aux configs VPN.

Task 2: Check that the remote subnet is actually routed back

cr0x@server:~$ traceroute -n 10.20.8.50
traceroute to 10.20.8.50 (10.20.8.50), 30 hops max, 60 byte packets
 1  10.10.12.1  0.407 ms  0.352 ms  0.331 ms
 2  172.16.100.1  10.982 ms  11.104 ms  11.015 ms
 3  10.20.8.50  12.201 ms  12.144 ms  12.087 ms

Que cela signifie : Le saut 2 est probablement votre passerelle VPN / interface tunnel. Vous voyez que le chemin passe par l’intermédiaire attendu.

Décision : Si traceroute meurt au saut 2, suspectez la politique du tunnel, des règles de pare-feu ou des routes de retour manquantes à l’autre bout.

Task 3: Verify you don’t have overlapping subnets (on a host)

cr0x@server:~$ ip route | egrep '10\.10\.|10\.20\.|192\.168\.'
10.10.12.0/24 dev eth0 proto kernel scope link src 10.10.12.34
10.20.0.0/16 via 10.10.12.1 dev eth0

Que cela signifie : Votre hôte a une route propre vers le réseau distant. Les chevauchements apparaissent souvent comme plusieurs routes pour le même préfixe ou des réseaux connectés inattendus.

Décision : Si vous voyez le préfixe distant comme « connecté » localement, vous avez un chevauchement ou une configuration DHCP rogue. Arrêtez-vous et corrigez l’adressage.

Task 4: Test basic reachability and distinguish “no route” from “filtered”

cr0x@server:~$ ping -c 3 10.20.8.50
PING 10.20.8.50 (10.20.8.50) 56(84) bytes of data.
64 bytes from 10.20.8.50: icmp_seq=1 ttl=62 time=12.4 ms
64 bytes from 10.20.8.50: icmp_seq=2 ttl=62 time=12.2 ms
64 bytes from 10.20.8.50: icmp_seq=3 ttl=62 time=12.5 ms

--- 10.20.8.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 12.210/12.378/12.512/0.121 ms

Que cela signifie : L’ICMP fonctionne et la latence est raisonnable. Cela ne prouve pas que le TCP fonctionnera à grande échelle, mais c’est un début.

Décision : Si ping échoue mais traceroute atteint l’hôte, l’ICMP peut être bloqué ; testez TCP ensuite au lieu de déclarer le VPN mort.

Task 5: Test TCP port reachability (service-level check)

cr0x@server:~$ nc -vz -w 2 10.20.8.50 443
Connection to 10.20.8.50 443 port [tcp/https] succeeded!

Que cela signifie : Le routage et la politique de pare-feu autorisent le TCP/443. C’est plus proche de l’expérience utilisateur que le ping.

Décision : Si ceci échoue mais que le ping marche, suspectez des règles de pare-feu, des security groups ou un pare-feu hôte sur le serveur.

Task 6: Validate DNS resolution across sites

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.20.0.53

cr0x@server:~$ dig +short app.internal.example
10.20.8.50

Que cela signifie : Vous avez des résolveurs des deux sites disponibles, et le nom se résout vers l’IP distante attendue.

Décision : Si la résolution bascule entre différentes réponses (ou timeouts), corrigez le forward/replication DNS avant de toucher au routage.

Task 7: Catch MTU problems with “do not fragment” pings

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

cr0x@server:~$ ping -M do -s 1392 -c 2 10.20.8.50
PING 10.20.8.50 (10.20.8.50) 1392(1420) bytes of data.
1400 bytes from 10.20.8.50: icmp_seq=1 ttl=62 time=13.1 ms
1400 bytes from 10.20.8.50: icmp_seq=2 ttl=62 time=13.0 ms

Que cela signifie : La PMTU est autour de 1420 octets. Si les endpoints essaient des paquets de 1500 sans clamp MSS ni PMTUD, vous aurez des stalls.

Décision : Clampez le MSS (ex. 1360–1380) ou ajustez le MTU d’interface pour éviter la fragmentation/blackholing.

Task 8: Check TCP MSS currently negotiated (spot clamping)

cr0x@server:~$ ss -ti dst 10.20.8.50:443 | sed -n '1,20p'
ESTAB  0  0  10.10.12.34:52514  10.20.8.50:443
	 cubic wscale:7,7 rto:204 rtt:13.1/1.2 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:10 bytes_sent:2145 bytes_acked:2145 segs_out:17 segs_in:14 data_segs_out:10 data_segs_in:9

Que cela signifie : MSS est 1360 et PMTU 1420 ; cela semble cohérent avec un overhead de tunnel.

Décision : Si MSS affiche 1460 alors que PMTU est ~1420, vous invitez les problèmes. Implémentez le clamp MSS sur la passerelle.

Task 9: Measure latency and loss with mtr (not just ping)

cr0x@server:~$ mtr -n -r -c 50 10.20.8.50
Start: 2025-12-27T11:12:41+0000
HOST: server                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.12.1                0.0%    50   0.4   0.4   0.3   0.9   0.1
  2.|-- 172.16.100.1              0.0%    50  11.2  11.0  10.7  13.9   0.6
  3.|-- 10.20.8.50                1.0%    50  12.5  12.7  12.0  18.4   1.2

Que cela signifie : 1 % de perte à destination suffit à rendre certaines applis « lentes », surtout les applis bavardes.

Décision : Si la perte apparaît aux sauts 2 et 3, suspectez le WAN ou le transport du tunnel. Si seulement au saut 3, suspectez l’hôte ou son réseau local.

Task 10: Verify IPsec SA state on a Linux gateway (strongSwan)

cr0x@server:~$ sudo ipsec statusall | sed -n '1,40p'
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.8.0, x86_64):
  uptime: 2 hours, since Dec 27 09:11:02 2025
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
Connections:
 office-a-office-b:  10.0.0.1...203.0.113.20  IKEv2, dpddelay=30s
 office-a-office-b:   local:  [gw-a] uses pre-shared key authentication
 office-a-office-b:   remote: [gw-b] uses pre-shared key authentication
Security Associations (1 up, 0 connecting):
 office-a-office-b[12]: ESTABLISHED 15 minutes ago, 10.0.0.1[gw-a]...203.0.113.20[gw-b]
 office-a-office-b{8}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c9f2a1d1_i c6f8b02f_o
 office-a-office-b{8}:   10.10.0.0/16 === 10.20.0.0/16

Que cela signifie : IKEv2 est établi, et le child SA (ESP) est installé pour les sous-réseaux attendus.

Décision : Si IKE est up mais aucun child SA installé, vous avez probablement des selectors/trafic mismatched ou des problèmes de policy.

Task 11: Check for rekey flaps and negotiation errors in logs

cr0x@server:~$ sudo journalctl -u strongswan --since "2 hours ago" | egrep -i "rekey|established|failed|proposal" | tail -n 20
Dec 27 10:55:03 gw-a charon[1124]: 12[IKE] initiating IKE_SA office-a-office-b[12] to 203.0.113.20
Dec 27 10:55:03 gw-a charon[1124]: 12[IKE] IKE_SA office-a-office-b[12] established between 10.0.0.1[gw-a]...203.0.113.20[gw-b]
Dec 27 10:55:03 gw-a charon[1124]: 12[CHD] CHILD_SA office-a-office-b{8} established with SPIs c9f2a1d1_i c6f8b02f_o and TS 10.10.0.0/16 === 10.20.0.0/16

Que cela signifie : Établissement propre. Si vous voyez des échecs répétés, vous avez probablement un WAN intermittent, des propositions mismatched ou des soucis NAT.

Décision : Rekeys fréquents pendant les heures ouvrées : investiguez la saturation CPU, la perte de paquets ou des durées de vie trop agressives.

Task 12: Verify WireGuard peer state (if you use WireGuard)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 0u9z4x2m3u9l4t...
  listening port: 51820

peer: 2q8m9n0b1v2c3x...
  endpoint: 203.0.113.20:51820
  allowed ips: 10.20.0.0/16
  latest handshake: 52 seconds ago
  transfer: 1.32 GiB received, 1.08 GiB sent
  persistent keepalive: every 25 seconds

Que cela signifie : Handshake récent et compteurs de trafic qui augmentent. Si « latest handshake » est « never », vous avez des problèmes de routage/NAT/pare-feu.

Décision : Si des handshakes ont lieu mais que le trafic échoue, suspectez allowed IPs/routes ou une politique de pare-feu au-delà du tunnel.

Task 13: Confirm forwarding and policy routing on a Linux gateway

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

cr0x@server:~$ ip rule show
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default

Que cela signifie : Le forwarding est activé ; pas de rules de policy routing inhabituelles présentes.

Décision : Si forwarding est 0, votre passerelle est un hôte très coûteux. Activez le forwarding et assurez-vous que les règles de pare-feu autorisent le forwarding.

Task 14: Inspect firewall counters for dropped tunnel traffic (nftables)

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 "wg0" ip saddr 10.20.0.0/16 ip daddr 10.10.0.0/16 tcp dport { 53, 443, 445 } accept
    counter packets 184 bytes 11040 drop
  }
}

Que cela signifie : La politique forward est drop, et vous avez une règle d’accept spécifique depuis wg0 vers office-a. Le compteur sur la règle drop finale indique que quelque chose est refusé.

Décision : Si les compteurs de drop augmentent lors des plaintes utilisateurs, revoyez quels ports/sous-réseaux manquent. Ajoutez des règles intentionnellement ; ne « allow all » pas par frustration.

Task 15: Measure throughput (controlled) to spot CPU or shaping limits

cr0x@server:~$ iperf3 -c 10.20.8.50 -P 4 -t 10
Connecting to host 10.20.8.50, port 5201
[  5] local 10.10.12.34 port 46318 connected to 10.20.8.50 port 5201
[  7] local 10.10.12.34 port 46334 connected to 10.20.8.50 port 5201
[  9] local 10.10.12.34 port 46344 connected to 10.20.8.50 port 5201
[ 11] local 10.10.12.34 port 46356 connected to 10.20.8.50 port 5201
[SUM]   0.00-10.00  sec   420 MBytes   352 Mbits/sec  sender
[SUM]   0.00-10.00  sec   418 MBytes   350 Mbits/sec  receiver

Que cela signifie : Vous obtenez ~350 Mbps sur le tunnel entre ces hôtes. Ça peut être excellent ou médiocre selon votre WAN et le hardware de passerelle.

Décision : Si le débit est bien en-dessous de la capacité WAN, vérifiez le CPU de la passerelle, l’offload de chiffrement, le shaping ou un goulet mono-thread.

Task 16: Check gateway CPU during load (encryption bottleneck hint)

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

11:14:01 AM  CPU   %usr   %nice    %sys %iowait  %irq  %soft  %steal  %guest  %gnice  %idle
11:14:02 AM  all   35.12    0.00   20.44    0.00  0.00   5.33    0.00    0.00    0.00  39.11
11:14:02 AM    0   80.00    0.00   18.00    0.00  0.00   2.00    0.00    0.00    0.00   0.00
11:14:02 AM    1   10.00    0.00   25.00    0.00  0.00   8.00    0.00    0.00    0.00  57.00
11:14:02 AM    2   20.00    0.00   15.00    0.00  0.00   5.00    0.00    0.00    0.00  60.00
11:14:02 AM    3   30.00    0.00   24.00    0.00  0.00   6.00    0.00    0.00    0.00  40.00

Que cela signifie : CPU0 est surchargé. Cela indique souvent un problème d’affinité d’interruptions ou une file unique, ou un process qui ne scale pas. Le débit VPN peut s’effondrer sous un core chaud.

Décision : Si vous voyez un core chaud pendant le trafic peak, songez à régler l’affinité IRQ, activer le multiqueue, upgrader le matériel ou changer les ciphers / offload (prudemment).

Playbook de diagnostic rapide

Ceci est le flux « cinq minutes, sans drame ». Vous essayez de trouver rapidement le goulet : routage, état du tunnel, MTU, DNS ou service distant.

Première étape : est-ce vraiment le tunnel, ou juste une appli ?

1. Choisissez un hôte de test dans chaque bureau (ou un jump box) que vous contrôlez.
2. Testez le TCP vers un service connu (ex. nc -vz remote-ip 443).
3. Testez la résolution DNS pour le même nom de service depuis les deux côtés.

Si une seule appli casse mais que le TCP de base fonctionne, cessez de blâmer le VPN. Montez la pile (TLS, auth, dépendances applicatives).

Deuxième étape : confirmez le routage et le chemin de retour

1. Faites traceroute dans les deux sens si possible (A→B et B→A). Le routage asymétrique est courant quand un côté a plusieurs gateways.
2. Vérifiez les routes des gateways pour assurer que chaque sous-réseau est connu et pointe dans le tunnel.
3. Cherchez du NAT là où vous ne l’attendiez pas. Le NAT dans un site-to-site routé est souvent le symptôme d’un chevauchement ou d’une rustine.

Troisième étape : sanity check MTU/MSS

1. Faites des pings DF pour trouver la PMTU approximative.
2. Vérifiez le MSS d’une session TCP établie (ss -ti).
3. Si le blackholing est probable, clampiez le MSS à la gateway.

Quatrième étape : est-ce que le transport est malade ?

1. Lancez mtr pour 50–200 paquets pour voir perte et jitter.
2. Vérifiez les erreurs/drops d’interface sur les gateways.
3. Vérifiez si le lien ISP est saturé (shaping ou bufferbloat peut imiter une « lenteur VPN »).

Cinquième étape : logs et état du démon tunnel

1. Pour IPsec : confirmez que IKE et les child SAs sont installés et stables.
2. Pour WireGuard : confirmez les handshakes et que les compteurs de trafic augmentent.
3. Cherchez des événements périodiques : rekeys, timeouts DPD, changements d’endpoint (NAT).

Erreurs courantes : symptômes → cause racine → correction

1) « Le tunnel est up, mais SMB/RDP/transferts de fichiers plantent »

Symptômes : Le ping fonctionne. Les petites requêtes HTTP passent. Les gros téléchargements stagnent. Les copies SMB démarrent vite puis gèlent.

Cause : Blackhole MTU ou absence de clamp MSS ; PMTUD bloqué quelque part.

Correction : Déterminez la PMTU avec ping DF ; clampiez le MSS TCP sur la gateway VPN ; envisagez de réduire le MTU du tunnel. Retestez avec iperf et des transferts réels.

2) « Une seule direction fonctionne »

Symptômes : Le bureau A peut atteindre le bureau B, mais pas l’inverse. Ou un sous-réseau peut initier mais ne reçoit pas de réponses.

Cause : Route de retour manquante, routage asymétrique via une sortie Internet différente, ou hypothèses d’état du pare-feu.

Correction : Vérifiez les routes sur les deux gateways. Confirmez que l’autre extrémité sait atteindre le sous-réseau initiateur. Assurez-vous que les pare-feux stateful voient les deux directions sur le même chemin.

3) « Ça marche pendant une heure, puis ça coupe périodiquement »

Symptômes : Déconnexions périodiques. Les appels VoIP tombent à intervalles réguliers. Les logs montrent des rekeys ou des timeouts DPD.

Cause : Durées de vie agressives, timeouts des mappings NAT, ou WAN instable avec pertes brèves qui tuent les keepalives.

Correction : Ajustez keepalives/persistent keepalive (WireGuard) ou les settings DPD (IPsec). Évitez des intervalles de rekey trop courts. Si derrière NAT, assurez-vous du NAT-T et des pinholes UDP stables.

4) « Le DNS échoue aléatoirement, les connexions sont lentes, des erreurs Kerberos apparaissent »

Symptômes : Timeouts intermittents pour des noms internes ; authentifications parfois échouent ; les retries fonctionnent parfois.

Cause : Clients utilisant le DNS du site distant comme primaire ; forward DNS sur un tunnel instable ; mauvaise configuration split-horizon ; dérive horaire.

Correction : Préférez des résolveurs locaux ; répliquez les zones ; ajoutez du forwarding conditionnel ; validez NTP sur les deux sites ; maintenez les dépendances DNS locales quand possible.

5) « On a ajouté du NAT pour gérer un chevauchement ; maintenant tout est bizarre »

Symptômes : Certains services fonctionnent, d’autres non. Les logs montrent des IP source inattendues. Le contrôle d’accès casse. Le dépannage devient de l’archéologie.

Cause : Sous-réseaux chevauchants masqués par NAT ; les applis supposent l’IP source ou des reverse lookups.

Correction : Renumérotez un site (vraiment). Si vous devez NATer temporairement, documentez-le, isolez-le et fixez une échéance de retrait.

6) « Le débit est nul mais le lien ISP est rapide »

Symptômes : Les tests de vitesse Internet sont bons ; les transferts sur VPN sont lents ; le CPU de passerelle grimpe.

Cause : Le chiffrement est lié au CPU ; un core unique est saturé ; absence d’offload ; mauvais queuing ; petit MTU causant overhead.

Correction : Mesurez avec iperf. Vérifiez le CPU par core. Upgradez le hardware, ajustez l’affinité IRQ, ou utilisez un cipher/path d’offload supporté par la plateforme. Ne devinez pas — mesurez avant/après.

Trois mini-histoires d’entreprise issues du terrain

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

L’entreprise avait deux bureaux après une acquisition. Le bureau A hébergeait tout : identité, partages, applis web internes. Le bureau B avait un petit réseau qui « semblait correct » et un pare-feu configuré il y a des années. Le plan était un IPsec site-à-site simple. Le chef de projet répétait « c’est juste un tunnel ».

Jour un, le tunnel est monté. Tout le monde applaudit. Le bureau B ne pouvait toujours pas se connecter au CRM par nom d’hôte. Par IP, ça marchait. La salle d’incident a immédiatement blâmé le VPN parce que c’était ce qui avait changé. L’équipe VPN a commencé à échanger les ciphers et les timers de rekey comme s’il s’agissait d’un concours de cuisine.

Deux heures plus tard, quelqu’un a enfin lancé dig depuis un client du bureau B. Il utilisait le DNS du bureau A comme primaire, via le tunnel. Sous faible charge, ça marchait. Sous la charge des connexions matinales, les requêtes DNS se sont retrouvées derrière de gros transferts SMB. Les résolutions ont timeouté, l’authentification a enchaîné des retries, et les utilisateurs ont vécu « Internet cassé ».

La mauvaise hypothèse était de considérer le DNS comme « petit trafic » qui pouvait partager sans priorité ni localité. La correction était ennuyeuse : ajouter des résolveurs DNS locaux au bureau B, implémenter du forwarding conditionnel pour les zones internes et autoriser explicitement le trafic DNS avec plus de priorité. Le tunnel n’a pas changé. L’issue oui.

Après coup, ils ont écrit une règle opérationnelle : « Chaque site doit pouvoir résoudre les noms internes localement pendant une panne WAN. » Cette règle a évité au moins trois incidents ultérieurs, y compris une panne ISP qui est passée inaperçue quinze minutes parce que le site est resté fonctionnel.

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

Une autre organisation avait une connectivité solide mais voulait « plus de vitesse ». Leurs liens WAN ont été upgradés, et quelqu’un a décidé que le VPN était le goulot. Ils ont activé un ensemble de « boutons performance » sur la passerelle : intervalles de rekey plus courts, DPD agressif et un cipher plus coûteux en CPU parce que « plus fort, c’est mieux ». Ils ont aussi activé du shaping « juste pour lisser », sans définir d’objectifs.

Le tunnel est resté up. La plupart du trafic semblait ok. Puis, exactement à intervalles réguliers, une vague de plaintes : appels vocaux coupés, remote desktop gelant, transferts suspendus puis repris. Le motif ressemblait à une horloge hantée.

Ce n’était pas hanté. C’était du churn de rekey combiné au shaping qui a introduit de la latence de queue pendant les rafales de négociation. Les paquets de rekey concurrençaient les paquets de données. DPD se déclenchait quand la latence montait. Les gateways démontaient et reconstruisaient l’état, causant des reset de sessions. Tout le monde vivait une « instabilité aléatoire » qui était en réalité parfaitement pianifiée.

Le rollback a corrigé immédiatement : restaurer des lifetimes raisonnables, rendre DPD sensé et retirer le shaping jusqu’à ce qu’ils mesurent des besoins. Plus tard, ils ont ajouté du QoS sélectif pour la voix, pas un « rendre tout joli ». La leçon : optimiser sans goulot mesuré ajoute simplement de la complexité avec une minuterie.

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

Une équipe d’ops maintenait un hub-and-spoke VPN reliant deux bureaux et un petit VPC cloud. Rien de fancy : deux tunnels par site, BGP avec filtres de préfixes et un job de supervision qui testait DNS, TCP/443 et un ping gros paquet chaque minute depuis chaque côté. Les dashboards n’étaient pas beaux, mais honnêtes.

Un après-midi, le bureau B a signalé « lenteur vers tout le bureau A ». L’état du tunnel était up. Pour les utilisateurs, cela signifiait « le VPN est up, donc ce sont les applis ». L’équipe applicative s’est préparée au pire.

La supervision a raconté une meilleure histoire : la latence a bondi et la perte de paquets a augmenté uniquement sur le chemin utilisant l’ISP #1 de B. Le tunnel de secours via l’ISP #2 était propre. BGP préférait encore ISP #1 parce que le tunnel était « up ». L’équipe a ajusté les métriques BGP pour préférer le chemin propre et a temporairement dé-priorisé le lien dégradé.

Les utilisateurs se sont remis en quelques minutes. Aucun débogage héroïque. Aucun doigt pointé. Plus tard, ils ont ajouté un tracking basé sur la perte/latence mesurée pour que « up » ne soit pas le seul signal. La pratique ennuyeuse a sauvé la journée parce que la journée n’avait pas besoin d’être sauvée ; elle avait besoin de preuves.

FAQ

1) Dois-je utiliser IPsec ou WireGuard pour un VPN site-à-site ?

Si vous avez besoin de support appliance, de cases de conformité à cocher ou d’une intégration facile avec des pare-feux existants, utilisez IPsec avec IKEv2. Si vous contrôlez les deux extrémités et voulez la simplicité opérationnelle, WireGuard est souvent plus facile à exploiter et déboguer.

2) Puis-je connecter deux bureaux si un côté est derrière NAT ou carrier-grade NAT ?

En général oui. Pour IPsec, utilisez NAT-T (UDP 4500) et assurez-vous que keepalives/DPD sont configurés. Pour WireGuard, le persistent keepalive aide à maintenir les mappings NAT. Si l’inbound est impossible, vous pouvez avoir besoin d’un hub atteignable (VM cloud) et connecter les deux sites vers l’extérieur.

3) Ai-je besoin d’une IP publique statique sur les deux sites ?

Cela facilite la vie, mais ce n’est pas strictement requis. Les IP dynamiques fonctionnent avec DDNS ou avec une approche hub. Toujours, pour la production : payez des IP statiques si possible. C’est moins cher que les heures passées à débugger « pourquoi l’endpoint a changé ? »

4) Devrions-nous router tout le trafic Internet du bureau B via le bureau A ?

Seulement si vous avez une raison claire (outillage de sécurité centralisé, conformité). Sinon, laissez l’egress Internet local et routez seulement les préfixes internes sur le VPN. Le full-tunneling site-à-site est une voie classique pour créer des pannes surprises.

5) Combien de sous-réseaux doivent être autorisés via le tunnel ?

Le moins possible. Commencez par les sous-réseaux serveurs spécifiques et les ports requis. Élargissez selon les besoins observés. « Allow any-any » est la manière dont les incidents internes deviennent inter-sites.

6) Pourquoi tout casse quand quelqu’un lance une grosse copie de fichiers ?

Le plus souvent, c’est un problème MTU/MSS ou bufferbloat/saturation sur le lien WAN. Validez la PMTU avec ping DF, vérifiez le MSS avec ss -ti, et mesurez perte/latence avec mtr pendant la copie.

7) Peut-on exécuter BGP sur le VPN, ou est-ce trop sophistiqué ?

Oui, et c’est souvent la façon la plus propre de gérer la redondance et éviter les éditions de routes manuelles. Si vous n’avez qu’un tunnel et deux sous-réseaux, le statique suffit. Si vous avez deux tunnels et voulez un basculement fiable, BGP est la solution adulte.

8) Comment faire pour que le basculement n’interrompe pas les sessions utilisateurs ?

Vous ne pouvez généralement pas garantir cela avec seulement un changement VPN. Vous pouvez réduire la perturbation par une convergence rapide et un MTU stable, mais beaucoup d’applications et de sessions TCP se réinitialiseront lors d’un changement de chemin. Si « aucune interruption » est exigé, vous entrez dans le domaine de la résilience applicative et du load-balancing.

9) Quels ports ouvrir pour une configuration typique ?

Ça dépend. Classiquement : IPsec utilise UDP 500 et UDP 4500 (et ESP si pas de NAT-T). WireGuard utilise un unique port UDP que vous choisissez (souvent 51820). Ensuite, vos ports internes autorisés sont une décision de politique, pas une exigence du VPN.

10) Est-il sûr de traiter deux bureaux comme un seul réseau de confiance si le trafic est chiffré ?

Non. Le chiffrement protège les données en transit ; il ne vous protège pas d’un poste compromis de l’autre côté. Segmentez, restreignez et journalisez. Supposiez une compromission, car la réalité le fait déjà.

Prochaines étapes qui ne vous feront pas honte plus tard

1. Rédigez le plan IP et bannissez les chevauchements. Si vous avez déjà des chevauchements, planifiez la renumérotation au lieu d’un « NAT temporaire pour toujours ».
2. Choisissez des tunnels routés avec des préfixes autorisés clairs. Évitez l’extension L2 sauf si vous aimez la douleur.
3. Choisissez IPsec (IKEv2) ou WireGuard selon ce que vous pouvez exploiter, pas selon la diapositive d’un vendeur.
4. Décidez split vs full tunnel délibérément. Par défaut split. Full tunnel uniquement pour une raison.
5. Rendez le DNS local sur chaque site, avec forwarding / réplication. Testez la résolution lors d’une simulation de panne WAN.
6. Corrigez MTU/MSS tôt et validez avec pings DF et transferts réels. « Ça ping » n’est pas un plan de test.
7. Ajoutez une supervision qui reflète la douleur utilisateur : DNS, TCP, perte/latence, pas seulement « tunnel up ».
8. Testez le basculement comme si vous le pensiez vraiment. Puis documentez ce qui casse (les sessions peuvent se réinitialiser) pour que la direction ne soit pas surprise plus tard.

Si vous faites ces étapes dans l’ordre, vous aurez un VPN site-à-site qui se comporte comme une infrastructure adulte : ennuyeux, prévisible et uniquement excitant de la manière que vous choisissez.