VPN basé sur les routes vs basé sur les politiques : lequel est mieux pour les bureaux et pourquoi

Ce que sont réellement les VPN basés sur les routes et sur les politiques

VPN basé sur les politiques : « assortir le trafic, puis le chiffrer »

Un VPN basé sur les politiques est typiquement un tunnel IPsec où le pare-feu utilise des sélecteurs (souvent appelés « proxy IDs » ou « traffic selectors »)
pour décider ce qui est chiffré : sous-réseau(s) source, sous-réseau(s) destination, parfois ports/protocoles.
Si le trafic correspond à la politique, il entre dans le tunnel ; sinon, il n’y entre pas.

Le modèle mental est : la politique de sécurité guide le transfert. Le routage existe toujours, mais ce n’est pas le point de décision principal.
Sur de nombreux équipements, les VPN basés sur les politiques ressemblent à l’écriture d’ACL qui ont pour effet de chiffrer.

C’est pourquoi les VPN basés sur les politiques sont courants sur du matériel ancien et sur des pare-feux « niveau PME » : ils sont faciles à expliquer et rapides à déployer
pour un sous-réseau vers un autre. Le prix est payé plus tard, avec intérêts.

VPN basé sur les routes : « créer une interface, puis router dedans »

Les VPN basés sur les routes créent une interface de tunnel logique (souvent VTI : Virtual Tunnel Interface) et laissent votre table de routage décider ce qui doit
transiter par le tunnel. Le chiffrement s’applique à ce qui est routé via cette interface (plus ce que votre politique IPsec autorise, mais l’idée est :
vous le concevez comme un réseau, pas comme un tas de cas particuliers).

Le modèle mental est : le routage guide le transfert ; la politique de sécurité contrôle l’autorisation. Cette séparation est précieuse en exploitation.
Elle permet de faire les choses normales : routage dynamique (BGP/OSPF), basculement de routes, plusieurs sous-réseaux sans explosion combinatoire,
et un dépannage sensé (« quelle route avons-nous choisie ? » est une meilleure question que « lequel des 37 sélecteurs a correspondu ? »).

Ce que les gens veulent dire (et où ils se trompent)

Les fournisseurs ne sont pas cohérents dans la terminologie. Certains appareils prétendent être « basés sur les routes » mais exigent toujours des sélecteurs ; d’autres implémentent
le « basé sur les politiques » mais permettent de le lier à un objet type tunnel. Ne vous battez pas sur les étiquettes. Discuter plutôt de ces propriétés :

• Y a-t-il une véritable interface de tunnel avec une adresse IP ? (Souvent oui pour le route-based, non pour le policy-based pur.)
• Pouvez-vous installer des routes (statiques ou dynamiques) pointant vers le tunnel ?
• Faut-il énumérer chaque paire de sous-réseaux local/distal ? (Le policy-based a tendance à l’exiger.)
• Pouvez-vous exécuter BGP dessus ? (Le route-based rend cela généralement simple.)
• Comment le basculement se comporte-t-il ? (Le route-based peut être propre ; le policy-based peut réserver des surprises.)

Une citation à garder sur votre mur, parce qu’elle résume le travail en une phrase :
« L’espoir n’est pas une stratégie. » — Gene Kranz

Les VPN basés sur les politiques reposent plus souvent sur l’espoir que les équipes ne l’admettent. Ils fonctionnent jusqu’à l’arrivée d’un nouveau sous-réseau,
ou jusqu’à ce que quelqu’un demande de l’actif/actif, ou que l’équipe cloud veuille du BGP. Alors les sélecteurs deviennent un tas fragile d’hypothèses.

Réalité des bureaux : ce qui change tout

Les bureaux sont en désordre. Ils s’étendent latéralement. Ils héritent de VLAN d’imprimantes de 2014 et de conceptions Wi‑Fi invité de 2017 et d’un sous‑réseau « temporaire »
ajouté pour un prestataire qui n’est jamais parti. Une conception VPN qui survit en environnement de bureau doit gérer :

• Nombreux sous‑réseaux par site (utilisateurs, voix, caméras, IoT, serveurs, invités, OT).
• Changements fréquents (nouveaux breakouts SaaS, nouveau DNS, nouvelles exceptions de split‑tunnel).
• Acquisitions (les espaces RFC1918 qui se chevauchent ne sont pas un problème théorique ; c’est un événement calendaire).
• Multiples upstreams (double ISP, secours LTE, underlays SD‑WAN).
• Vendeurs mixtes (parce que bien sûr il y a un Forti à une extrémité et un Palo à l’autre, avec un NAT « utile » au milieu).
• Pression des politiques de sécurité (segmentation façon zero trust, audit, MFA pour l’accès admin, et « tout bloquer par défaut »).

La question centrale n’est pas « quel VPN est le plus sûr ». Les deux peuvent être sûrs. La question est : quel modèle échoue de façon prévisible
et diagnostiquable quand le bureau change ? Parce que le bureau changera. Il change toujours.

Lequel est meilleur pour les bureaux (et les exceptions)

Recommandation par défaut : route-based pour presque tous les VPN bureau-à-bureau et bureau‑vers‑datacenter

Pour les bureaux, le route-based gagne sur le long terme parce qu’il s’aligne avec la façon dont les réseaux sont réellement exploités :
vous ajoutez des routes, vous surveillez des routes, vous basculez des routes, vous résumez des routes, vous déboguez des routes. Vous ne voulez pas que la
connectivité VPN dépende d’une matrice de sélecteurs que seul un ingénieur comprend et que personne ne veut toucher un vendredi.

Les VPN basés sur les routes sont aussi mieux adaptés aux besoins réels :

• Routage dynamique (BGP en particulier) pour de nombreux sites, interconnexions cloud et logique de basculement.
• Plusieurs sous‑réseaux sans explosion de sélecteurs (un tunnel, de nombreuses routes).
• HA plus propre (surveiller l’interface de tunnel, la session BGP, retirer les routes).
• Gestion des changements moins fragile (ajouter un sous‑réseau devient « ajouter une route + une règle de pare‑feu », pas « ajouter N sélecteurs »).

Quand le policy-based reste acceptable

Le VPN basé sur les politiques est acceptable quand :

• C’est vraiment petit : un sous‑réseau vers un autre (ou quelques-uns), et cela ne va pas croître.
• L’équipement ne supporte pas correctement le VTI/route-based (fréquent sur matériel ancien/entrée de gamme).
• Vous avez besoin de décisions de chiffrement par application/port et la plateforme le fait proprement (rare, mais possible).
• Vous intégrez un partenaire qui insiste sur des traffic selectors stricts et ne veut pas de routage dynamique.

Mais comprenez ce à quoi vous vous engagez : chaque nouveau sous‑réseau est un changement de politique. Chaque changement de politique est une chance de casser des choses
d’une manière qui n’apparaît pas dans les contrôles « tunnel up ».

Où les équipes se brûlent : « tunnel up » n’est pas « le trafic fonctionne »

Les VPN basés sur les politiques adorent afficher des voyants verts : IKE est up, IPsec est up, des octets bougent. Pendant ce temps, le nouveau VLAN ne peut rien atteindre
parce que ses sélecteurs n’ont jamais été ajoutés, ou parce qu’un NAT s’est glissé et a changé l’IP source, ou parce que l’extrémité distante est stricte et rejette silencieusement
le trafic qui ne correspond pas.

Les architectures basées sur les routes peuvent aussi casser, mais elles cassent comme les réseaux cassent : mauvaise route, route manquante, routage asymétrique, problèmes de MTU,
règle de pare‑feu. Ce sont des problèmes qu’on peut résoudre à 2 h du matin avec un terminal et un pouls.

Blague #1 : Un VPN basé sur les politiques ressemble à une liste d’invités VIP. Ça marche très bien jusqu’à ce que votre entreprise continue d’embaucher.

Ce que « meilleur » signifie opérationnellement

Dans les environnements de bureau, « meilleur » n’est pas l’élégance. C’est le temps moyen de restauration, le rayon d’impact, et combien de choses peuvent changer en toute sécurité.
Le route-based a tendance à l’emporter sur :

• Observabilité : tables de routage, statistiques d’interface, état BGP, outils standards.
• Sécurité du changement : diffs plus petits, moins de conditions couplées.
• Scalabilité : ajouter des sites/sous‑réseaux ne multiplie pas les objets de configuration des deux côtés.
• Interopérabilité : les clouds et les pare‑feux modernes supposent de plus en plus des schémas basés sur les routes.

Matrice de décision : choisir en 5 minutes

Choisissez route-based si l’un de ces éléments est vrai

• Vous avez plus de deux sous‑réseaux sur l’un ou l’autre site, ou vous en prévoyez dans l’année.
• Vous avez besoin d’un basculement qui n’est pas un coup de pièce (double ISP, hubs doubles, actif/actif).
• Vous voulez BGP (ou pourriez le vouloir plus tard).
• Vous avez des VPN cloud dans le mix (la plupart des gateways cloud sont centrées sur les routes).
• Vous devez résumer des routes ou gérer des sous‑réseaux qui se chevauchent via NAT.
• Vous voulez dépanner avec des outils normaux : routes, ping, tcpdump, compteurs.

Choisissez policy-based si tous ces éléments sont vrais

• C’est un lien petit, stable et statique sous‑réseau à sous‑réseau.
• Pas de routage dynamique. Pas de complexité HA. Pas d’attente de croissance.
• La mise en œuvre route‑based sur la plateforme est faible ou inexistante.
• Vous pouvez documenter les sélecteurs et les garder synchronisés sur les deux extrémités.

Choisissez « route-based, mais avec garde‑fous » pour la plupart des bureaux

Les meilleurs VPN de bureau sont basés sur les routes plus de la discipline :
préfixes autorisés explicites, filtres de routes, valeurs par défaut sensées pour MTU/MSS, et surveillance qui traite le tunnel comme un lien WAN.
Vous construisez un réseau, pas un portail magique.

Faits intéressants et contexte à répéter en réunion

1. IPsec a commencé comme couche de sécurité pour IPv6 dans les années 1990, puis a été largement déployé pour IPv4 parce que la réalité gagne toujours.
2. Les « proxy IDs » viennent des premières idées de sélecteurs IPsec : définir exactement quel trafic doit être protégé, adaptées à l’ère sous‑réseau‑à‑sous‑réseau.
3. Les Virtual Tunnel Interfaces (VTI) sont devenues populaires lorsque les fournisseurs ont compris que les opérateurs voulaient qu’IPsec se comporte comme GRE : une interface sur laquelle router.
4. IKEv2 (standardisation milieu‑2000) a corrigé de nombreux défauts d’IKEv1, surtout autour de la négociation et de la résilience.
5. Le NAT‑Traversal existe parce qu’Internet est désordonné : l’encapsulation UDP (typiquement 4500) a été une solution pragmatique pour les NAT qui brisent IPsec.
6. Les produits VPN cloud ont poussé l’adoption du route‑based parce que les clouds veulent des tables de routage et du routage dynamique, pas des feuilles de calcul de sélecteurs.
7. SD‑WAN a accéléré l’état d’esprit « tunnel comme interface » : les underlays changent, les overlays routent ; les sélecteurs basés sur des politiques ne s’adaptent pas bien.
8. Route‑based n’est pas automatiquement « any‑to‑any » : vous avez toujours besoin de politique de pare‑feu et de filtres de routes. La différence est que vous pouvez les gérer séparément.

Trois mini‑histoires d’entreprise du terrain

Mini‑histoire n°1 : l’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne avait un VPN site‑à‑site basé sur les politiques entre le siège et une agence. Il était stable depuis des années : un /24 à l’agence,
quelques /24 au siège. Voyants verts partout. Personne n’y touchait.

Puis l’agence a ajouté un second VLAN pour les téléphones VoIP. L’ingénieur réseau a ajouté le VLAN sur le pare‑feu de l’agence, ajouté le DHCP,
et a supposé « le VPN le transportera parce que c’est le même tunnel ». Cette hypothèse est la façon dont naissent les pannes.

Les téléphones s’enregistraient sur le PBX local ? Parfait. Les téléphones atteignant le call manager centralisé au siège ? Mort. Pendant ce temps, le VPN affichait toujours « up »
parce que les sous‑réseaux existants correspondaient toujours aux sélecteurs et maintenaient le trafic. La surveillance ne l’a pas détecté parce que les checks
faisaient un ping depuis l’ancien sous‑réseau.

La correction a été d’ajouter de nouveaux sélecteurs (proxy IDs) sur les deux extrémités, plus des règles de pare‑feu. La leçon n’était pas « le policy‑based est mauvais ».
La leçon était : les VPN basés sur les politiques rendent la portabilité un opt‑in par paire de sous‑réseaux, donc le mode de défaillance par défaut est une panne partielle silencieuse.

Après cela, la société a migré vers des tunnels basés sur les routes pour les agences. Le même changement aujourd’hui est : ajouter VLAN, ajouter l’annonce de route,
ajouter la règle de pare‑feu. Surveillance des pings depuis plusieurs VLANs, pas un seul sous‑réseau « ancien et bon ».

Mini‑histoire n°2 : l’optimisation qui a mal tourné

Une autre organisation voulait « optimiser » leur VPN en resserrant les sélecteurs pour réduire le « chiffrement inutile ».
Ils avaient un tunnel policy‑based avec de nombreuses paires de sous‑réseaux, et quelqu’un a décidé de supprimer les larges sélecteurs et ne garder que les « actifs ».
Sur le papier, cela réduisait l’encombrement de configuration.

Deux mois plus tard, une équipe applicative a redémarré un service dans un sous‑réseau DR qui n’avait pas été utilisé récemment. Le trafic est parti d’un préfixe source différent,
toujours valide et attendu. Il ne correspondait plus à aucun sélecteur, donc le pare‑feu l’a envoyé en clair vers le chemin routier sortant Internet, où des ACL upstream l’ont bloqué.
Le tunnel est resté up. Les logs étaient bruyants mais pas évidents.

La panne a duré plus longtemps qu’elle n’aurait dû parce que les gens ont chassé la mauvaise couche : logs applicatifs, DNS, puis règles de pare‑feu, puis ISP.
Ce n’est que plus tard que quelqu’un a comparé des captures et a remarqué que le trafic n’entrait pas du tout dans IPsec.

La correction a été de restaurer les sélecteurs, puis plus tard de repenser en route‑based avec filtrage de routes et segmentation appropriée. L’« optimisation »
était en réalité une codification fragile d’hypothèses. Le chiffrement devrait être une propriété d’un chemin, pas une liste fragile d’exceptions.

Mini‑histoire n°3 : la pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise avec plus de 40 bureaux exécutait un IPsec basé sur les routes avec BGP vers deux hubs régionaux. Rien de fancy. La partie « ennuyeuse » était leur discipline de changement :
chaque bureau avait un plan de préfixes standard, des filtres de routes, et une liste de tests pré‑changement incluant des vérifications MTU et la connectivité par VLAN.

Un jour, une mise à jour du pare‑feu du hub a introduit un comportement différent par défaut pour le clamp MSS TCP. Soudain, les transferts de fichiers depuis certains bureaux ont ralenti.
La latence semblait correcte ; les pings fonctionnaient ; les petites requêtes HTTP fonctionnaient. Les grosses copies SMB étaient lamentables.

Leur runbook exigeait un contrôle PMTU rapide et une vérification des compteurs d’interface IPsec. En quelques minutes ils ont vu la fragmentation et les retransmissions.
Ils ont ajusté le clamp MSS sur les interfaces de tunnel du hub et confirmé l’amélioration. Pas d’escalade fournisseur. Pas de désignation « c’est l’ISP ».

La pratique qui les a sauvés n’était pas une astuce brillante. C’était la standardisation + tests répétables + visibilité sur le routage.
Quand votre VPN se comporte comme une interface avec des routes, il est plus facile de localiser l’endroit où les choses ont déraillé.

Blague #2 : La manière la plus rapide d’apprendre le dépannage VPN est de planifier un « petit » changement de pare‑feu juste avant un long week‑end.

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

Ce sont des vérifications de niveau opérateur que vous pouvez exécuter depuis des hôtes Linux, des pare‑feux exposant des shells, ou des bastions proches des points de terminaison.
L’important n’est pas la commande ; c’est la décision que vous prenez en fonction de la sortie.

1) Confirmer que la route attendue existe (sanity check route‑based)

cr0x@server:~$ ip route get 10.40.12.20
10.40.12.20 via 169.254.21.2 dev vti0 src 169.254.21.1 uid 1000
    cache

Sens : Le trafic vers 10.40.12.20 sortira via vti0 via le next‑hop du tunnel. Bon.
Décision : S’il montre votre passerelle par défaut à la place, corrigez le routage (route statique, BGP, route‑map) avant de toucher à IPsec.

2) Vérifier si des SA IPsec existent et se renégocient (exemple strongSwan)

cr0x@server:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.8.0, x86_64):
  uptime: 2 hours, since Dec 28 09:11:02 2025
Connections:
 office-hub:  169.254.21.1...203.0.113.10  IKEv2
Security Associations (1 up, 0 connecting):
 office-hub[12]: ESTABLISHED 37 minutes ago, 198.51.100.20[198.51.100.20]...203.0.113.10[203.0.113.10]
 office-hub{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c2f4a1d2_i c8a19f10_o
 office-hub{7}:   169.254.21.1/32 === 169.254.21.2/32

Sens : IKEv2 est établi ; ESP est installé ; les sélecteurs sont host/32 sur les terminaux VTI (schéma typique route‑based).
Décision : S’il n’y a pas de SA, concentrez‑vous sur la négociation IKE, PSK/certs, NAT‑T et la connectivité UDP.

3) Vérifier que le trafic est réellement chiffré (regarder les stats XFRM)

cr0x@server:~$ ip -s xfrm state
src 198.51.100.20 dst 203.0.113.10
    proto esp spi 0xc8a19f10 reqid 1 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha256) 0x... 128
    enc cbc(aes) 0x...
    anti-replay context: seq 0x0000007b, oseq 0x0000007b, bitmap 0xffffffff
    stats: replay-window 0 replay 0 failed 0 bytes 981234 packets 812 add 2025-12-28 09:15:01 use 2025-12-28 10:02:31

Sens : Les compteurs de paquets/octets qui augmentent signifient que le trafic passe par IPsec.
Décision : Si les compteurs restent à plat alors que les applis tombent, votre routage/politique ne dirige pas le trafic vers le tunnel (ou les sélecteurs ne correspondent pas en policy‑based).

4) Détecter les trous MTU/PMTU (douleur classique des VPN de bureau)

cr0x@server:~$ ping -M do -s 1372 10.40.12.20 -c 3
PING 10.40.12.20 (10.40.12.20) 1372(1400) bytes of data.
1380 bytes from 10.40.12.20: icmp_seq=1 ttl=61 time=21.3 ms
1380 bytes from 10.40.12.20: icmp_seq=2 ttl=61 time=21.1 ms
1380 bytes from 10.40.12.20: icmp_seq=3 ttl=61 time=21.2 ms

--- 10.40.12.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Sens : La PMTU est au moins ~1400 octets bout‑à‑bout. Bon pour de nombreux chemins IPsec.
Décision : Si vous voyez « Frag needed », clampez le MSS TCP sur l’interface de tunnel ou baissez le MTU. Si vous voyez des timeouts seulement pour de gros paquets, suspectez un filtrage PMTU.

5) Observer le path MTU avec tracepath (trouver où ça tombe)

cr0x@server:~$ tracepath 10.40.12.20
 1?: [LOCALHOST]                      pmtu 1500
 1:  169.254.21.2                                           2.123ms
 2:  10.40.12.20                                           21.004ms reached
     Resume: pmtu 1400 hops 2 back 2

Sens : La PMTU découverte est 1400. C’est normal avec l’overhead ESP.
Décision : S’il rapporte pmtu 1500 mais que de gros flux TCP bloquent, suspectez des ICMP bloqués quelque part et appliquez quand même un clamp MSS.

6) Confirmer que le DNS n’est pas la « panne VPN »

cr0x@server:~$ resolvectl query fileserver.corp.example
fileserver.corp.example: 10.40.12.20                         -- link: vti0

-- Information acquired via protocol DNS in 19.9ms.
-- Data is authenticated: no

Sens : Le nom se résout vers l’IP distante et le résolveur l’associe au lien tunnel.
Décision : Si le DNS pointe vers des IP publiques ou des plages internes erronées, corrigez le split‑DNS ou le forwarding conditionnel avant d’accuser IPsec.

7) Prouver que la poignée de main TCP fonctionne (ou non)

cr0x@server:~$ nc -vz 10.40.12.20 445
Connection to 10.40.12.20 445 port [tcp/microsoft-ds] succeeded!

Sens : Le VPN et la politique de pare‑feu autorisent SMB vers cet hôte.
Décision : Si cela time‑out, décidez si c’est le routage (pas de chemin de retour), la politique de pare‑feu (bloqué), ou les sélecteurs IPsec (mismatch policy‑based).

8) Inspecter les compteurs d’interface pour des pertes sur l’interface de tunnel

cr0x@server:~$ ip -s link show dev vti0
6: vti0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    RX:  bytes  packets  errors  dropped  missed  mcast
      18922310   152233       0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
      20100291   160112       0        0       0       0

Sens : Des drops en RX suggèrent des problèmes de file d’attente/MTU/politique, ou un souci de gestion kernel/xfrm.
Décision : Si les drops augmentent pendant des transferts, concentrez‑vous sur MTU/MSS et CPU ; si les drops sont à zéro mais que l’appli échoue, regardez la politique de pare‑feu ou l’hôte distant.

9) Valider l’adjacence BGP sur le tunnel (coup de maître route‑based)

cr0x@server:~$ sudo vtysh -c "show ip bgp summary"
BGP router identifier 169.254.21.1, local AS number 65010
Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
169.254.21.2    4      65000    8123    7991      144    0    0 03:12:44        37

Sens : BGP est up depuis des heures et reçoit 37 préfixes. Voilà à quoi ressemble un VPN « piloté par le routage ».
Décision : Si BGP flappe, traitez le tunnel comme un WAN : vérifiez la perte sur l’underlay, le MTU, les timers DPD, et le CPU avant de toucher aux filtres de routes.

10) Détecter des fuites ou routes manquantes (ce que vous annoncez compte)

cr0x@server:~$ sudo vtysh -c "show ip route 10.40.12.0/24"
Routing entry for 10.40.12.0/24
  Known via "bgp", distance 20, metric 0, best
  Last update 00:02:11 ago
  * 169.254.21.2, via vti0

Sens : Le préfixe existe et est joignable via le tunnel.
Décision : Si la route manque, arrêtez. Ne débrouillez pas IPsec. Corrigez d’abord l’annonce/importation de routage.

11) Confirmer que les sélecteurs policy‑based correspondent (débogage générique via capture)

cr0x@server:~$ sudo tcpdump -ni eth0 host 203.0.113.10 and udp port 4500 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:04:11.201122 IP 198.51.100.20.4500 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc8a19f10,seq=0x0000007c), length 148
10:04:11.221009 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP-encap: ESP(spi=0xc2f4a1d2,seq=0x00000080), length 148

Sens : Vous voyez de l’ESP dans de l’UDP. Si vous générez du trafic de test et ne voyez pas de paquets ESP, il n’entre pas dans IPsec.
Décision : Dans les configurations policy‑based, cela signifie généralement un mismatch de sélecteur ou que le NAT a changé les adresses internes.

12) Vérifier conntrack pour symptômes de routage asymétrique

cr0x@server:~$ sudo conntrack -L -p tcp --dport 445 | head
tcp      6 431999 ESTABLISHED src=10.20.5.44 dst=10.40.12.20 sport=51234 dport=445 src=10.40.12.20 dst=10.20.5.44 sport=445 dport=51234 [ASSURED] mark=0 use=1

Sens : Le flux est établi dans les deux sens ; le trafic de retour est observé.
Décision : Si vous voyez beaucoup de SYN_SENT sans réponse, suspectez une route de retour manquante côté distant ou une règle de pare‑feu bloquante.

13) Vérifier que le NAT ne sabote pas vos sélecteurs

cr0x@server:~$ sudo iptables -t nat -S | sed -n '1,20p'
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE

Sens : Une règle MASQUERADE large peut réécrire les IP sources, casser des sélecteurs policy‑based et embrouiller le débogage route‑based.
Décision : Ajoutez des exemptions NAT pour les destinations VPN ou rétrécissez la portée du NAT à « internet uniquement ».

14) Surveiller CPU et softirqs pendant plaintes de débit (le chiffrement coûte des cycles)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (vpn-gw1) 	12/28/2025 	_x86_64_	(8 CPU)

10:06:31 AM  CPU   %usr   %nice %sys %iowait  %irq %soft  %steal  %idle
10:06:32 AM  all   12.10   0.00  9.88   0.00  0.00  21.44    0.00  56.58
10:06:33 AM  all   10.34   0.00  8.91   0.00  0.00  24.10    0.00  56.65
10:06:34 AM  all   11.02   0.00  9.33   0.00  0.00  25.89    0.00  53.76

Sens : Un %soft élevé peut indiquer une pression de traitement des paquets (souvent VPN + NAT + pare‑feu).
Décision : Si le CPU est saturé pendant les heures ouvrables, vous avez besoin d’un accélérateur matériel crypto, d’un meilleur dimensionnement, ou d’une ingénierie du trafic.

15) Mesurer le débit avec iperf3 (arrêtez de deviner)

cr0x@server:~$ iperf3 -c 10.40.12.20 -t 10 -P 4
Connecting to host 10.40.12.20, port 5201
[SUM]   0.00-10.00  sec   842 MBytes   707 Mbits/sec  sender
[SUM]   0.00-10.00  sec   839 MBytes   704 Mbits/sec  receiver

Sens : Vous avez ~700 Mbps de débit réel sur le tunnel dans ces conditions de test.
Décision : Si le débit est faible mais la latence correcte, concentrez‑vous sur MTU/MSS, CPU crypto, ou policing/shaping sur l’underlay.

16) Confirmer le comportement DPD/keepalive dans les logs (stabilité du tunnel)

cr0x@server:~$ sudo journalctl -u strongswan --since "10 minutes ago" | tail -n 8
Dec 28 10:00:01 vpn-gw1 charon[1123]: 12[IKE] sending DPD request
Dec 28 10:00:01 vpn-gw1 charon[1123]: 12[IKE] received DPD response, peer alive
Dec 28 10:05:01 vpn-gw1 charon[1123]: 12[IKE] sending DPD request
Dec 28 10:05:01 vpn-gw1 charon[1123]: 12[IKE] received DPD response, peer alive

Sens : Le pair répond. Le chemin underlay n’est pas mort, et l’état est maintenu.
Décision : Si le DPD échoue de façon intermittente, suspectez une perte ISP, des timeouts de mapping NAT, ou des timeout UDP agressifs sur un pare‑feu en amont.

Guide de diagnostic rapide

La façon la plus rapide de perdre des heures est de commencer au milieu. Commencez aux bords et suivez le paquet.
Quand quelqu’un dit « le VPN est lent » ou « le site est down », exécutez ceci dans l’ordre.

Première étape : le problème est‑il de routage, de chiffrement ou de politique ?

1. Vérifiez la route depuis un hôte proche de la source :
   ip route get <remote_ip>.
   Si elle ne pointe pas vers le tunnel/VTI, arrêtez‑vous et corrigez le routage.
2. Vérifiez l’état des SA et des compteurs :
   IKE établi ? ESP installé ? Octets/paquets augmentent‑ils quand vous générez du trafic ?
   Si les SA sont down, corrigez IKE/underlay. Si les SA sont up mais compteurs à plat, c’est un problème d’aiguillage/sélecteurs.
3. Vérifiez la politique de pare‑feu sur le chemin de données :
   pouvez‑vous nc -vz sur le port ? Sinon, vérifiez les règles et les routes de retour.

Deuxième étape : isolez « ça répond au ping » de « ça fonctionne pour le vrai trafic »

1. Test PMTU avec ping -M do et tracepath. Si les gros paquets échouent, clampez le MSS ou baissez le MTU.
2. Test de débit avec iperf3. S’il est très inférieur à la capacité du circuit, vérifiez CPU, softirqs et shaping.
3. Capture de paquets sur l’interface publique : voyez‑vous de l’ESP/UDP 4500 quand vous générez du trafic ?

Troisième étape : vérifiez la symétrie et le chemin de retour

1. Conntrack ou table d’état : les flux deviennent‑ils ESTABLISHED ou restent‑ils en SYN_SENT ?
2. Table de routage côté distant : sait‑elle comment atteindre votre préfixe source via le tunnel ?
3. Filtres de routes (si routage dynamique) : avez‑vous accidentellement bloqué le nouveau préfixe ?

Empreinte rapide du goulot

• Haute latence + perte : underlay ISP, appareil NAT, basculement LTE, ou congestion du fournisseur.
• Basse bande passante, latence bonne : MTU/MSS, limite CPU crypto, QoS policing, ou limitation par flux unique.
• Un sous‑réseau fonctionne, un autre pas : mismatch de sélecteur policy‑based ou route/advertisement manquant.
• Fonctionne dans un sens seulement : route de retour manquante, routage asymétrique, ou drop par pare‑feu stateful.

Erreurs courantes : symptômes → cause racine → correction

1) « Le tunnel est up, mais un nouveau VLAN ne rejoint pas le siège »

Symptômes : Les sous‑réseaux existants fonctionnent ; le nouveau sous‑réseau échoue ; la page d’état VPN est verte.
Cause racine : Les sélecteurs policy‑based non mis à jour des deux côtés, ou les annonces de routes non mises à jour pour le route‑based.
Correction : Pour policy‑based : ajoutez des sélecteurs locaux/distants correspondants (proxy IDs) dans les deux sens et assurez l’exemption NAT. Pour route‑based : annoncez ou ajoutez des routes statiques, puis autorisez en politique de pare‑feu.

2) « Les petites requêtes web fonctionnent, les copies de fichiers bloquent »

Symptômes : Ping OK ; RDP OK ; SMB/gros HTTPS bloquent ; retransmissions sur captures.
Cause racine : Trou PMTU/MTU dû à l’overhead ESP + ICMP fragmentation nécessaire bloquée.
Correction : Clamp MSS TCP sur les interfaces de tunnel ; réduire le MTU ; autoriser les types ICMP nécessaires pour PMTU sur l’underlay quand approprié.

3) « Le trafic fonctionne pendant des heures, puis meurt aléatoirement jusqu’à ce qu’on rekey/restart »

Symptômes : Pannes intermittentes ; logs montrant des échecs DPD ; souvent derrière un NAT.
Cause racine : Timeout de mapping NAT pour UDP 4500/500, ou lifetimes mal alignés menant à un comportement de rekey bizarre.
Correction : Activez les keepalives NAT‑T ; alignez les lifetimes IKE/ESP ; ajustez DPD ; assurez‑vous que les firewalls en amont gardent les mappings UDP suffisamment longtemps.

4) « On a activé l’actif/actif, maintenant certaines sessions se cassent »

Symptômes : La moitié des utilisateurs vont bien ; d’autres voient des resets ; tables d’état inconsistantes.
Cause racine : Routage asymétrique sur deux tunnels sans synchronisation d’état, ou ECMP sans cohérence par flux.
Correction : Utilisez un hashing par flux avec chemin de retour cohérent, ou utilisez actif/passif pour les services stateful ; préférez BGP avec attributs et checks de santé appropriés.

5) « Le VPN du partenaire ne fonctionne que pour un seul sous‑réseau ; ils refusent d’en ajouter »

Symptômes : Un seul préfixe interne atteint le partenaire ; l’expansion est lente et politique.
Cause racine : Le partenaire utilise des sélecteurs policy‑based stricts et le contrôle de changement est douloureux.
Correction : Négociez du route‑based avec VTI si possible ; sinon utilisez le NAT (avec précaution) pour mapper plusieurs préfixes internes sur un sélecteur autorisé, et documentez‑le comme du matériel dangereux.

6) « Après avoir resserré les règles NAT, le VPN a cassé »

Symptômes : IKE up mais le trafic ne passe pas ; les sélecteurs semblent corrects.
Cause racine : Exemption NAT supprimée ; IP source modifiée ; match policy‑based échoue ou le distant rejette des adresses internes inattendues.
Correction : Ajoutez des règles de contournement NAT explicites pour les préfixes distants ; validez par capture que les adresses sources internes correspondent à ce que le pair attend.

7) « VPN cloud ↔ bureau flappe, on‑prem ↔ on‑prem est stable »

Symptômes : Rekeys périodiques ; resets BGP ; l’underlay semble OK.
Cause racine : Attentes de timers et timeouts d’infrastructures cloud ; parfois DPD agressif ; parfois chemins multiples avec NAT incohérent.
Correction : Alignez les timers sur les recommandations cloud ; keepalives ; évitez le double NAT ; vérifiez la stabilité UDP 4500 ; envisagez des tunnels doubles avec routage health‑checked.

8) « Le VPN est lent seulement aux heures de pointe »

Symptômes : Plaintes 9–11h ; pics CPU ; augmentation des drops ; jitter VoIP.
Cause racine : Gateway CPU limité sur le crypto ou le traitement des paquets, ou congestion de l’underlay sans QoS.
Correction : Dimensionnez correctement les gateways, activez l’offload matériel si disponible, appliquez du QoS sur l’underlay, et envisagez de répartir le trafic sur plusieurs tunnels/régions.

Listes de contrôle / plan étape par étape

Étape par étape : concevoir un nouveau VPN de bureau (chemin recommandé)

1. Choisir route‑based (VTI) sauf si vous avez une raison concrète de ne pas le faire.
2. Définir la propriété des préfixes : blocs résumés par bureau si possible (facilite routage et filtres).
3. Décider du routage :
   • Petit environnement : les routes statiques conviennent, mais documentez‑les et gardez‑les symétriques.
   • Multi‑bureaux ou fort cloud : exécutez BGP sur le tunnel. Le route‑based rend cela propre.
4. Définir MTU/MSS intentionnellement : n’attendez pas que SMB vous enseigne le PMTU en production.
5. Règles de pare‑feu : moindre privilège, mais pas de spaghetti de sélecteurs : autorisez les ports requis entre zones, journalisez les refus à un débit utile.
6. Surveillance : vérifiez l’état IKE/IPsec, la présence des routes, et la disponibilité applicative réelle depuis plus d’un VLAN.
7. Conception du basculement :
   • Privilégiez les tunnels doubles avec santé via routage (BGP ou routes statiques suivies).
   • Rendez les pannes explicites : retirez les routes quand le tunnel est malsain.
8. Gestion des changements : définissez comment un nouveau VLAN est connecté : « ajouter préfixe + annoncer + politique ». Faites‑en une case de la checklist, pas une histoire de héros.

Étape par étape : migrer policy‑based vers route‑based sans drame

1. Inventoriez les sélecteurs : listez toutes les paires de sous‑réseaux locaux/distants utilisées aujourd’hui.
2. Mappez vers l’intention de routage : quels préfixes doivent réellement être joignables ? Lesquels sont legacy et doivent disparaître ?
3. Démarrez un tunnel route‑based parallèle (IP pair différent ou ID de tunnel différent) en gardant l’ancien.
4. Déplacez un préfixe à la fois par le routage : installez la route via VTI et retirez le sélecteur pour ce préfixe de l’ancien tunnel seulement après validation.
5. Validez MTU/MSS tôt ; les migrations route‑based exposent souvent des péchés PMTU anciens.
6. Verrouillez les filtres de routes : ne créez pas accidentellement du any‑to‑any entre bureaux parce que « ça route maintenant ».
7. Basculez la surveillance sur le nouveau tunnel, puis retirez les anciennes politiques.

Checklist opérationnelle : quoi vérifier après tout changement VPN

• IKE établi et stable (pas de rekeys constants ou d’échecs DPD).
• Les compteurs ESP augmentent quand vous générez du trafic de test.
• Routes installées pour tous les préfixes requis (et seulement ces préfixes).
• La politique de pare‑feu autorise les ports requis ; les refus sont journalisés de façon utile.
• Test PMTU passé sur des hôtes représentatifs ; clamp MSS en place si nécessaire.
• Au moins un test par VLAN critique : utilisateurs, voix et IoT « bizarre ».
• Basculement testé : déconnectez un lien ISP ou désactivez un tunnel ; confirmez le retrait des routes et la récupération des sessions comme prévu.
• Surveillance/alertes mises à jour : pas de métriques « tunnel up » sans checks de trafic.

FAQ

1) Le VPN basé sur les routes est‑il plus sûr que le policy‑based ?

Pas intrinsèquement. La sécurité vient des paramètres crypto, de la gestion des clés et de la politique de pare‑feu. Le route‑based est généralement plus sûr opérationnellement
parce qu’il est moins susceptible de créer des connectivités partielles accidentelles ou des contournements silencieux lors des changements.

2) Pourquoi les VPN basés sur les politiques causent‑ils des pannes « ça marche pour certains sous‑réseaux » ?

Parce que la portée de la connectivité est définie par des sélecteurs. Si vous n’incluez pas explicitement une paire de sous‑réseaux, le trafic ne sera pas chiffré et peut être
rejeté ou fuiter vers un chemin différent. Le tunnel peut rester « up » alors que votre nouveau réseau est effectivement invisible.

3) Les VPN basés sur les routes peuvent‑ils encore utiliser des traffic selectors ?

Oui, de nombreuses implémentations négocient toujours des sélecteurs, mais dans les conceptions route‑based ils sont souvent étroits (host‑to‑host pour les extrémités VTI) et
le routage décide quels préfixes intérieurs traversent le tunnel. Le comportement opérationnel est la distinction clé.

4) Ai‑je besoin de BGP pour justifier le route‑based ?

Non. Des routes statiques sur une VTI sont encore plus faciles à raisonner qu’une matrice de sélecteurs, surtout quand les bureaux ont plusieurs VLANs.
BGP le rend seulement plus scalable et plus gracieux pour le basculement.

5) Qu’en est‑il des espaces RFC1918 qui se chevauchent entre bureaux ?

Les chevauchements arrivent lors de fusions et de mauvaises planifications. Le route‑based facilite l’introduction d’un NAT contrôlé à la périphérie et rend la logique de routage explicite.
Le policy‑based peut aussi faire du NAT, mais le débogage devient un casse‑tête impliquant sélecteurs et traductions.

6) Quel modèle est meilleur pour le basculement double ISP ?

Route‑based, presque toujours. Vous pouvez surveiller l’état de l’interface de tunnel, utiliser le routage dynamique et retirer les routes proprement. Le basculement policy‑based
se transforme souvent en politiques dupliquées avec des divergences subtiles et des surprises « pourquoi ce flux a choisi tel tunnel ».

7) Pourquoi la surveillance « tunnel up » ne détecte‑t‑elle pas les vraies pannes ?

Parce que la santé du plan de contrôle IKE/IPsec ne garantit pas la correction du plan de données. Vous pouvez avoir des SA up avec des routes erronées, des sélecteurs incorrects,
des ports bloqués, des trous PMTU ou des chemins de retour manquants. Surveillez à la fois le plan de contrôle et des probes applicatives représentatives.

8) Route‑based signifie‑t‑il que j’ai accidentellement créé un accès full mesh entre bureaux ?

Seulement si vous le laissez faire. Le route‑based facilite le routage de nombreux préfixes, mais vous appliquez toujours la segmentation avec des filtres de routes et la politique de pare‑feu.
« Ça route » n’est pas une permission.

9) Quel est le principal facteur tuant le débit sur les VPN de bureau ?

Les problèmes MTU/MSS et les limites CPU. Les problèmes de MTU créent retransmissions et blocages qui ressemblent à un « internet lent ». Les limites CPU apparaissent aux heures de pointe
quand chiffrement et filtrage des paquets se disputent les cycles.

10) Si mon pare‑feu ne supporte que policy‑based, que faire ?

Gardez l’ensemble de sélecteurs minimal et documenté, évitez un NAT trop large qui réécrit les adresses internes, et mettez en place une surveillance qui teste chaque sous‑réseau critique.
Si le bureau croît, planifiez un renouvellement matériel ; le policy‑based à l’échelle devient une taxe à long terme.

Prochaines étapes concrètes

Si vous gérez des bureaux et que vous voulez moins de surprises VPN, faites ceci :

1. Standardisez sur le route‑based VPN pour les liaisons de bureau sauf contraintes par l’équipement partenaire ou plateformes legacy.
2. Rendez le routage explicite : routes statiques pour les petits déploiements ; BGP pour de nombreux sites ou intégration cloud.
3. Gérez MTU/MSS dès le jour un. N’attendez pas que SMB ruine votre après‑midi.
4. Surveillez le plan de données : probes par VLAN, pas seulement « IKE est up ».
5. Documentez les modes de panne que vous observez réellement : mismatch de sélecteurs, exemptions NAT, routage asymétrique, trous PMTU.
6. Exercez le basculement en le cassant volontairement pendant des fenêtres compatibles avec l’activité. Un design que vous n’avez pas testé en basculement est une rumeur.

Les VPN basés sur les routes ne rendront pas votre réseau parfait. Ils le rendent seulement diagnostiquable, scalable et moins dépendant du savoir tribal.
Pour les bureaux, c’est la différence entre « un WAN sécurisé » et « un thème d’incident récurrent ».