Basculer le VPN de bureau : garder les tunnels actifs avec 2 FAI (sans surveillance manuelle)

décembre 30, 2025 • février 3, 2026 • Lecture : 30 min • Views: 8

Cet article vous a aidé ?

Le bureau perd l’accès à Internet. Quelqu’un crie « le VPN est en panne », Slack s’affole, et soudain vous déboguez depuis votre téléphone sur le parking avec une barre de LTE. Pendant ce temps, le second FAI pour lequel vous payez chaque mois reste là comme une roue de secours jamais gonflée.

Le basculement VPN en dual‑FAI n’est pas difficile, mais il est facile de le faire d’une manière qui semble redondante sur un schéma et qui pourtant s’effondre en production. Voici la version pragmatique : des architectures qui maintiennent réellement les tunnels, des sondes qui ne mentent pas, un routage qui n’envoie pas les paquets vers le vide, et les habitudes opérationnelles ennuyeuses qui empêchent qu’un incident ne devienne une séance collective de thérapie.

Ce que « basculement » devrait signifier (et ce qu’il ne doit pas signifier)

Dans le monde des bureaux, « basculement VPN » signifie généralement « le tunnel doit rester actif quand un FAI tombe ». C’est le résultat attendu. Mais vous n’y arrivez que si vous définissez ce que « actif » veut dire et ce que vous êtes prêt à accepter pendant la panne.

Définissez le succès en termes opérationnels

Recovery time objective (RTO) : Combien de secondes de perte de paquets sont acceptables ? 2 secondes ? 30 secondes ? « Quand Bob le remarque » n’est pas une métrique.
Recovery point objective (RPO) : Pour les VPN, il s’agit moins des données que de l’état. Les flux avec état (VoIP, RDP, uploads longs) seront coupés lors d’un changement de chemin sauf si vous avez une préservation de session (rare). Décidez si la coupure de sessions est acceptable.
Rayon d’impact : Le basculement affecte‑t‑il seulement le trafic site‑à‑site, ou aussi la sortie Internet, DNS, SaaS, la voix ?
Action opérateur : « Automatique » signifie pas besoin de CLI à 2h du matin. Ça peut toujours alerter fort. Simplement, ça ne doit pas nécessiter que vous interveniez manuellement.

Attention : le basculement n’est pas un bouton magique qui rend le routage en amont parfait. Si votre FAI secondaire a un peering dégradé, votre tunnel peut être « up » alors que vos applications fondent. Le système doit mesurer l’utilité, pas seulement l’état du lien.

Blague #1 : Deux WAN sans sondes, c’est comme avoir deux parapluies et quand même être trempé parce que vous ne les ouvrez que quand l’application météo dit « pluie ».

Quelques faits et un peu d’histoire qui expliquent les modes de défaillance actuels

Un peu de contexte rend le basculement VPN moderne moins mystérieux et plus « ah, voilà pourquoi ça casse ». Voici des faits concrets à garder en tête :

IPsec précède les bureaux « toujours en ligne » d’aujourd’hui. Les premières normes IPsec datent de la fin des années 1990, quand on supposait des sites statiques et des liens de longue durée ; la bascule rapide n’était pas l’objectif premier.
Le NAT n’était pas traitée comme prioritaire. La traversée NAT (NAT‑T) est devenue courante plus tard ; beaucoup de comportements étranges viennent d’encapsuler ESP dans UDP/4500 pour traverser des NAT.
Le comportement d’IKEv1 et IKEv2 diffère en cas de panne. Beaucoup de configurations « ça marche jusqu’à ce que ça casse » reposent sur des bizarreries d’IKEv1 ; IKEv2 se comporte généralement mieux mais dépend toujours des timers et des réglages DPD.
Les « pannes » des FAI consommateurs sont souvent partielles. Beaucoup d’incidents ne sont pas une coupure de lien. Ce sont des échecs de résolution DNS, des PMTU cassés, ou des fluctuations de routage en amont. C’est pour ça que détecter une gateway morte en pingant le next‑hop du FAI est trompeur.
BGP est devenu la méthode sérieuse pour le multi‑homing en entreprise. Mais la plupart des bureaux ne peuvent pas obtenir d’espace d’adresses indépendant du fournisseur ni BGP sur des circuits bon marché ; on simule donc la résilience à des couches supérieures.
Le SD‑WAN n’a pas inventé les sondes ; il les a industrialisées. L’idée centrale — mesurer perte/latence vers une cible réelle et orienter le trafic — existe depuis des décennies dans des scripts maison et des fonctionnalités de routeur.
La perte de paquets affecte les VPN plus que la navigation ordinaire. L’encapsulation IPsec et les retransmissions peuvent transformer « 1% de perte » en « pourquoi Teams est inutilisable ? » plus vite que vous ne le pensez.
Les blackholes PMTU sont un vieux mode de panne répétable. Le sur‑coût d’encapsulation réduit l’MTU effectif ; si ICMP est bloqué, la découverte de PMTU se casse et de gros paquets disparaissent dans le vide.

Topologies qui fonctionnent : actif/standby, actif/actif, et « ne faites pas ça »

Topologie A : tunnels actif/standby (le plus simple, souvent le meilleur)

Vous créez deux tunnels site‑à‑site : un sur ISP1, un sur ISP2. Un seul transporte du trafic en conditions normales. Si les sondes échouent, vous basculez la route vers le tunnel de secours. Vous pouvez faire cela avec :

VPN basé sur routes (préféré) : deux interfaces tunnel, deux next hops, métriques/priorités.
VPN basé sur politiques (fonctionne, mais devient fragile à mesure que le réseau grossit).
Routage dynamique (BGP/OSPF) sur les tunnels (basculement propre, plus d’éléments en jeu).

Pourquoi ça marche : stable, prévisible, moins de surprises d’asymétrie de routage. Déboguer à 3h du matin reste acceptable.

Inconvénient : vous « gaspillez » le lien de secours. Ce n’est pas grave. Votre DAF dépense plus en chaises de salle de réunion.

Topologie B : tunnels actif/actif (plus dur, à utiliser seulement si nécessaire)

Les deux tunnels transportent le trafic simultanément. Vous faites du routage par préfixe, de l’orientation par application, ou de l’ECMP. C’est courant quand vous voulez plus de débit ou éviter qu’un FAI soit un « poids mort ».

Où ça casse :

Routage asymétrique si le trafic de retour ne suit pas le même tunnel.
Firewalls stateful qui verrouillent les flux sur un chemin puis rejettent des paquets arrivant sur l’interface « incorrecte ».
Limitations côté distant (certains gateways VPN cloud n’aiment pas les changements fréquents de chemin).

Mon avis : faites actif/standby sauf si vous avez une contrainte de débit mesurée qui justifie la complexité. Si vous avez besoin d’actif/actif, soyez honnête : vous construisez un petit WAN. Traitez‑le comme tel.

Topologie C : « basculement par DNS » (ne pas faire)

Certaines équipes tentent : « Si ISP1 tombe, changeons le DNS pour l’endpoint VPN. » Ce n’est pas du basculement ; c’est un plan de maintenance déguisé en résilience. Les caches DNS, les TTL ignorés par les clients, et les sessions longue durée feront que vos utilisateurs implémenteront votre test de basculement en direct.

Mécanique : comportement IKE/IPsec, NAT, DPD, et réalité du rekey

Le basculement VPN est un jeu de timers. Vous équilibrez la vitesse de détection de la panne et la fréquence des oscillations lors de pertes transitoires.

DPD : Dead Peer Detection est nécessaire, pas suffisante

DPD (ou équivalent keepalives) peut vous dire que le pair ne répond pas. Mais si le chemin Internet est à moitié cassé — les paquets sortent, mais les réponses ne reviennent pas — vous avez besoin de preuves supplémentaires.

Bonnes pratiques :

Activez DPD avec des valeurs raisonnables (par ex. intervalles 10–30s, petit nombre de tentatives).
Utilisez aussi des sondes du plan de données (ICMP ou TCP vers une cible à travers le tunnel).
Décidez du basculement sur des pertes/latences soutenues, pas sur une seule sonde manquée.

NAT et adresses source : choisir des identités stables

En dual‑FAI, la passerelle VPN locale peut présenter des IP publiques différentes. Les pairs distants peuvent authentifier par ID (FQDN) et ignorer le changement d’IP source, ou pinner sur une adresse spécifique. Beaucoup de services VPN cloud attendent que vous configuriez explicitement les deux tunnels ; c’est une bonne chose. Vous voulez que le côté distant s’attende à la défaillance.

Comportement du rekey pendant le basculement

Les événements de rekey sont un classique du mystère « ça plante toutes les heures ». Pendant le basculement, les timers de rekey peuvent s’aligner mal avec l’instabilité du chemin, entraînant des tentatives de négociation répétées. Quand c’est possible :

Décalez les durées de rekey entre le tunnel primaire et le secondaire.
Assurez‑vous que les deux tunnels peuvent négocier indépendamment (pas de confusion d’SA partagée).
Conservez les logs. Les échecs de rekey se résolvent rarement par l’intuition.

MTU : le tueur silencieux de tunnel

L’encapsulation réduit l’MTU. Si vous utilisez 1500 sur le LAN et encapsulez en IPsec sur PPPoE (commun sur DSL), vous devrez peut‑être clamer le MSS TCP ou réduire l’MTU de l’interface. Sinon, vous obtiendrez des échecs intermittents qui ressemblent à « certains sites se chargent, d’autres non ».

Blague #2 : Les problèmes d’MTU sont l’équivalent IT d’une chaise qui grince : inoffensifs jusqu’à ce que tout le monde devienne fou et que vous commenciez à remettre en question vos choix de vie.

Routage qui ne ment pas : VPN basé sur politiques vs basé sur routes vs BGP

VPN basé sur routes : recommandation par défaut

Le VPN basé sur routes vous donne une interface tunnel. Vous pouvez utiliser des routes statiques, jouer sur les métriques, et utiliser votre table de routage habituelle. C’est plus simple à combiner avec des sondes et le routage dynamique.

Règle : si votre plateforme supporte le VPN basé sur routes, utilisez‑le sauf contrainte spécifique.

VPN basé sur politiques : acceptable pour les petits réseaux

Le VPN basé sur politiques lie le chiffrement à des sélecteurs de trafic (subnet‑to‑subnet). Ça marche tant que vous n’ajoutez pas un troisième sous‑réseau, puis un quatrième, puis quelqu’un veut router un /32 pour une VM de test, et soudain vous faites de la politique de sécurité pilotée par tableur.

Routage dynamique sur les tunnels : basculement propre, besoin de compétence plus élevée

BGP sur IPsec (ou GRE sur IPsec) est la façon la plus robuste de basculer des routes entre tunnels, parce que les protocoles de routage gèrent déjà « quel chemin est viable » si vous leur fournissez des signaux d’interface et de keepalive corrects.

Quand l’utiliser :

Vous avez plusieurs sites ou plusieurs préfixes.
Vous avez besoin de reroutage automatique sans fonctionnalités SD‑WAN propriétaires.
Vous pouvez l’exploiter : supervision, filtres de routes, et contrôle des changements.

Quand ne pas l’utiliser :

Vous êtes un bureau unique avec un réseau distant unique et pas d’appétit pour la politique de routage.
Vous ne pouvez pas garantir que les deux bouts peuvent faire tourner BGP proprement (certains services managés le restreignent).

Une citation fiabilité (idée paraphrasée) : Gene Kranz, directeur de vol de la NASA, insistait sur le fait d’être « dur et compétent » sous pression — la fiabilité est surtout préparation, pas héros.

Sondes : prouver que le chemin est bon, pas seulement « up »

Le problème central du basculement en bureau est que la plupart des configurations « dual WAN » détectent la mauvaise panne. Le modem câble est toujours synchronisé, donc le routeur pense que tout va bien. Pendant ce temps, le routage en amont envoie vos paquets du VPN vers le néant.

Que sonder

Atteignabilité de l’underlay : Pouvez‑vous atteindre une cible Internet stable via chaque FAI ? Utilisez plusieurs cibles dans différents réseaux. Évitez de pinger uniquement la passerelle du FAI comme seul test.
Atteignabilité de l’overlay : Pouvez‑vous joindre quelque chose à travers le tunnel ? Une loopback sur le pare‑feu distant est idéale. Encore mieux : un port de service (TCP/443 vers un endpoint de santé) qui prouve plus que l’ICMP.
Qualité : Mesurez latence et perte de paquets. Définissez des seuils adaptés à vos applications (voix, VDI, partages de fichiers).

Comment rendre les sondes fiables

Attachez les sondes à l’interface/à l’adresse source de chaque FAI pour tester le bon chemin.
Utilisez plusieurs sondes et exigez des échecs consécutifs avant de déclarer un chemin mort.
Rate‑limitez le retour vers l’ancien lien. Flapper entre les FAI transforme un petit problème amont en panne totale.

Tâches pratiques (avec commandes, sorties et décisions)

Voici des tâches pratiques que vous pouvez exécuter sur une passerelle VPN basée sur Linux (ou un hôte de dépannage) pour valider une conception VPN dual‑FAI. Les commandes sont réalistes. Les sorties sont représentatives. Après chacune, vous verrez ce que la sortie signifie et quelle décision prendre.

Tâche 1 : Confirmer que les deux WAN ont des routes valides

cr0x@server:~$ ip route show
default via 203.0.113.1 dev wan1 proto static metric 100
default via 198.51.100.1 dev wan2 proto static metric 200
10.10.0.0/16 dev lan0 proto kernel scope link src 10.10.0.1
203.0.113.0/24 dev wan1 proto kernel scope link src 203.0.113.20
198.51.100.0/24 dev wan2 proto kernel scope link src 198.51.100.20

Signification : Deux routes par défaut existent ; wan1 est préférée via une métrique plus basse. La route LAN est présente.

Décision : Si vous voulez un underlay actif/standby, c’est correct. Si vous vouliez actif/actif, vous avez besoin de routage policy ou d’ECMP, pas seulement deux routes par défaut avec métriques.

Tâche 2 : Vérifier les règles de policy routing (si vous faites du probing sur l’underlay dual ou actif/actif)

cr0x@server:~$ ip rule show
0:	from all lookup local
1000:	from 203.0.113.20 lookup 100
1001:	from 198.51.100.20 lookup 200
32766:	from all lookup main
32767:	from all lookup default

Signification : Le trafic provenant de chaque IP WAN utilise une table de routage spécifique.

Décision : Conservez cela si vous avez besoin d’épingler des sondes (et du trafic de certains tunnels) à l’ISP correct. Si absent, votre « sonde wan2 » peut sortir par wan1 et vous mentir.

Tâche 3 : Confirmer que chaque WAN peut atteindre le peer VPN en underlay (lié à l’interface)

cr0x@server:~$ ping -I wan1 -c 3 192.0.2.10
PING 192.0.2.10 (192.0.2.10) from 203.0.113.20 wan1: 56(84) bytes of data.
64 bytes from 192.0.2.10: icmp_seq=1 ttl=55 time=18.4 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=55 time=18.1 ms
64 bytes from 192.0.2.10: icmp_seq=3 ttl=55 time=18.3 ms

--- 192.0.2.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 18.1/18.2/18.4/0.1 ms

Signification : L’underlay vers le peer est joignable via wan1, avec peu de perte.

Décision : Répétez pour wan2. Si wan2 ne peut pas atteindre le peer, ne blâmez pas IPsec tout de suite ; corrigez le routage, le filtrage FAI, ou des problèmes amonts.

Tâche 4 : Vérifier qu’IKE écoute sur les deux WAN

cr0x@server:~$ sudo ss -lunp | grep -E ':(500|4500)\s'
UNCONN 0      0        0.0.0.0:500     0.0.0.0:*    users:(("charon",pid=1324,fd=12))
UNCONN 0      0        0.0.0.0:4500    0.0.0.0:*    users:(("charon",pid=1324,fd=13))

Signification : Le démon IKE (ex. strongSwan charon) écoute UDP/500 et UDP/4500 sur toutes les interfaces.

Décision : S’il n’est lié qu’à une IP, le basculement secondaire ne fonctionnera jamais. Corrigez les paramètres de binding du démon ou le pare‑feu système.

Tâche 5 : Valider l’état du tunnel IPsec (exemple strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
vpn-primary: #12, ESTABLISHED, IKEv2, rekeying in 46 minutes
  local  'office-fw' @ 203.0.113.20[4500]
  remote 'dc-fw' @ 192.0.2.10[4500]
  AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
  vpn-primary-child: #34, INSTALLED, TUNNEL, reqid 1
    local  10.10.0.0/16
    remote 10.50.0.0/16
vpn-secondary: #0, CONNECTING, IKEv2
  local  'office-fw' @ 198.51.100.20[4500]
  remote 'dc-fw' @ 192.0.2.10[4500]

Signification : Le primaire est établi ; le secondaire est en tentative mais pas up.

Décision : Si le secondaire ne s’établit jamais, vérifiez que le peer distant est configuré pour accepter la deuxième identité/source et que les règles NAT/pare‑feu le permettent.

Tâche 6 : Confirmer que les routes vers les sous‑réseaux distants préfèrent le tunnel primaire

cr0x@server:~$ ip route get 10.50.1.25
10.50.1.25 dev vti0 src 10.255.0.2 uid 0
    cache

Signification : Le trafic vers le réseau distant utilise vti0 (interface tunnel primaire).

Décision : Si ça sort directement par wan1, votre VPN basé sur routes ne fait pas de routage. Corrigez les routes, VTI, ou les sélecteurs de trafic.

Tâche 7 : Prouver l’atteignabilité de l’overlay (sonder une loopback distante à travers le tunnel)

cr0x@server:~$ ping -c 3 10.50.255.1
PING 10.50.255.1 (10.50.255.1) 56(84) bytes of data.
64 bytes from 10.50.255.1: icmp_seq=1 ttl=63 time=21.9 ms
64 bytes from 10.50.255.1: icmp_seq=2 ttl=63 time=22.1 ms
64 bytes from 10.50.255.1: icmp_seq=3 ttl=63 time=22.0 ms

--- 10.50.255.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 21.9/22.0/22.1/0.1 ms

Signification : Le plan de données fonctionne à travers le tunnel.

Décision : Si l’underlay est up mais que l’overlay échoue, concentrez‑vous sur les sélecteurs IPsec, les politiques de pare‑feu, ou le routage côté distant.

Tâche 8 : Vérifier les problèmes MTU/fragmentation avec un ping DF

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

--- 10.50.255.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2051ms

Signification : L’MTU effectif le long du tunnel est 1436. Votre paquet 1500 bytes ne passe pas avec DF activé.

Décision : Clamez le MSS TCP (par ex. à 1360–1400 selon l’overhead) ou réglez l’MTU du tunnel/LAN en conséquence. Si ICMP est bloqué en amont, vous verrez des blackholes au lieu d’erreurs claires.

Tâche 9 : Inspecter l’état xfrm pour confirmer que les SA sont installées (IPsec Linux)

cr0x@server:~$ sudo ip xfrm state
src 203.0.113.20 dst 192.0.2.10
	proto esp spi 0xc12f4a9d reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x4f9b... 128
src 192.0.2.10 dst 203.0.113.20
	proto esp spi 0x1a2b3c4d reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x0aa1... 128

Signification : Des SA ESP existent dans les deux sens pour le primaire.

Décision : Si les SA manquent alors qu’IKE indique « established », vous pouvez avoir des problèmes de négociation CHILD_SA ou des conflits de politique.

Tâche 10 : Vérifier la traversée NAT et l’encapsulation UDP sur le réseau

cr0x@server:~$ sudo tcpdump -ni wan1 udp port 4500 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wan1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:04:11.120111 IP 203.0.113.20.4500 > 192.0.2.10.4500: UDP-encap: ESP(spi=0xc12f4a9d,seq=0x2f1), length 132
12:04:11.140225 IP 192.0.2.10.4500 > 203.0.113.20.4500: UDP-encap: ESP(spi=0x1a2b3c4d,seq=0x19a), length 132
12:04:12.120332 IP 203.0.113.20.4500 > 192.0.2.10.4500: UDP-encap: ESP(spi=0xc12f4a9d,seq=0x2f2), length 132
12:04:12.140447 IP 192.0.2.10.4500 > 203.0.113.20.4500: UDP-encap: ESP(spi=0x1a2b3c4d,seq=0x19b), length 132
12:04:13.120552 IP 203.0.113.20.4500 > 192.0.2.10.4500: UDP-encap: ESP(spi=0xc12f4a9d,seq=0x2f3), length 132
5 packets captured

Signification : ESP est encapsulé dans UDP/4500 et le trafic circule dans les deux sens.

Décision : Si vous ne voyez que des paquets sortants, suspectez un filtrage amont, un NAT incorrect, ou un côté distant qui ne répond pas. Si vous ne voyez que IKE/500 et pas de 4500 alors que vous êtes derrière un NAT, NAT‑T peut être mal négocié.

Tâche 11 : Confirmer que le pare‑feu permet IKE/IPsec sur les deux WAN

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    iifname "wan1" udp dport { 500, 4500 } accept
    iifname "wan2" udp dport { 500, 4500 } accept
    iifname "lan0" accept
    counter reject with icmpx type admin-prohibited
  }
}

Signification : UDP/500 et UDP/4500 sont acceptés sur les deux interfaces WAN.

Décision : Si wan2 est absent, les négociations du tunnel secondaire échoueront silencieusement. Corrigez le pare‑feu avant de toucher aux configs IPsec.

Tâche 12 : Surveiller les changements de routes lors d’une panne provoquée

cr0x@server:~$ ip monitor route
Deleted default via 203.0.113.1 dev wan1 proto static metric 100
Added default via 198.51.100.1 dev wan2 proto static metric 200
Added 10.50.0.0/16 dev vti1 proto static metric 50
Deleted 10.50.0.0/16 dev vti0 proto static metric 10

Signification : La route par défaut primaire et la route du tunnel primaire ont été supprimées ; le secondaire est devenu actif et la route a basculé vers vti1.

Décision : C’est ce que vous voulez. Si les routes ne changent pas, votre logique de basculement n’est pas connectée au routage (ou elle échoue à se déclencher). Si elles flappent sans arrêt, ajoutez des timers de maintien et élargissez les seuils de sondes.

Tâche 13 : Confirmer la santé au niveau applicatif à travers le VPN (test TCP)

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

Signification : L’overlay peut atteindre un service réel. Un succès ICMP seul peut masquer des problèmes de pare‑feu ou MTU.

Décision : Utilisez ceci comme cible de sonde quand la disponibilité applicative vous importe. Si ça échoue lors du basculement mais que le ping fonctionne, suspectez MSS/MTU, inspection stateful, ou asymétrie de routage.

Tâche 14 : Rechercher des symptômes d’asymétrie de routage avec conntrack

cr0x@server:~$ sudo conntrack -S
cpu=0 found=24872 invalid=36 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0

Signification : Vous avez un nombre non nul de paquets invalid, ce qui augmente souvent lors d’asymétrie de routage ou de changements de chemin.

Décision : Si les invalid augmentent pendant le basculement, envisagez actif/standby plutôt qu’actif/actif, ou assurez la symétrie avec du policy routing et une gestion NAT/état cohérente.

Mode opératoire de diagnostic rapide

Quand le VPN « bascule » mais que les utilisateurs se plaignent, vous devez isoler où se trouve la panne : underlay (FAI), overlay (IPsec), routage (votre équipement), ou côté distant. Faites‑le dans cet ordre.

Première étape : sanity check de l’underlay (prouver que le chemin FAI est utilisable)

Vérifiez le lien et l’adressage IP sur les deux WAN (carrier up, DHCP/PPPoE, routes).
Sondez plusieurs cibles Internet stables par WAN (ping lié à l’interface ou TCP). Si un seul FAI est dégradé, ne touchez pas encore au VPN.
Confirmez que vous pouvez atteindre l’IP publique du peer VPN depuis chaque WAN.

Deuxième étape : plan de contrôle de l’overlay (IKE négocie‑t‑il ?)

Confirmez que UDP/500 et UDP/4500 sont autorisés dans les deux sens.
Consultez les logs IKE pour boucles de négociation, échecs d’auth, ou incompatibilités de propositions.
Validez que le tunnel secondaire est configuré côté distant et non bloqué par « n’autoriser qu’une IP source connue ».

Troisième étape : plan de données de l’overlay (les paquets peuvent‑ils passer ?)

Pingez une loopback distante ou un hôte de test à travers le tunnel.
Effectuez un test de connexion TCP vers un service réel à travers le tunnel.
Testez la PMTU avec des pings DF et clamez le MSS si nécessaire.

Quatrième étape : routage et symétrie (où le trafic est‑il réellement passé ?)

Vérifiez la sélection de route vers les sous‑réseaux distants.
Recherchez l’asymétrie de routage via les invalids conntrack ou les rejets du pare‑feu.
Si du routage dynamique est impliqué, vérifiez les annonces de routes et les filtres.

Cinquième étape : côté distant et dépendances applicatives

Confirmez que le pare‑feu distant a des routes de retour vers les réseaux du bureau via le tunnel actif.
Vérifiez DNS, fournisseurs d’identité, et tout proxy « utile » qui aurait pu se pinner sur l’ancien chemin.

Trois mini‑histoires d’entreprise issues du terrain

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

Le bureau avait deux FAI. La diapositive annonçait fièrement « connectivité redondante ». En réalité : ISP2 était branché et avait une IP, mais personne n’avait jamais testé un VPN site‑à‑site via ce lien parce que « le pare‑feu le supporte ». Cette phrase devrait porter un avertissement.

Un mardi, ISP1 ne s’est pas coupé ; il est devenu étrange. Le trafic sortant fonctionnait pour certaines destinations. Le réseau du peer VPN ? Blackholé en amont. La détection de gateway morte du pare‑feu continuait à déclarer le lien sain car il pouvait pinger le next‑hop du FAI. Les utilisateurs pouvaient naviguer, ce qui rendait la direction convaincue que le problème venait de « l’équipe VPN ».

L’équipe a forcé le basculement manuellement vers ISP2. Le tunnel ne s’est jamais établi. Le peer distant n’autorisait que l’IP publique connue d’ISP1, et l’identité du certificat était liée à cette hypothèse. Ils avaient construit une redondance sur papier, mais opérationnellement c’était un point de défaillance unique avec un abonnement associé.

Ils ont corrigé correctement : configurer les deux tunnels sur le distant, utiliser une identité IKE stable non liée à une seule IP WAN, et implémenter des sondes overlay qui testent une loopback derrière le pare‑feu distant. Deux semaines plus tard, ils ont simulé une panne en heures ouvrables et ont vu les tunnels se comporter comme des adultes.

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

Une autre société voulait « utiliser les deux circuits parce que finance ». Ils ont activé actif/actif avec ECMP sur deux VTI IPsec et se sont félicités quand iperf montrait plus de débit en labo.

En production, l’assistance a commencé à recevoir des tickets qui semblaient sans rapport : déconnexions intermittentes de partages de fichiers, audio VoIP unidirectionnel, et « l’ERP tourne en rond ». Rien n’était complètement en panne. Tout était légèrement hanté.

Le coupable était le routage asymétrique combiné à des politiques de sécurité stateful côté distant. Certains flux sortaient par le tunnel A et revenaient par le tunnel B. Le pare‑feu les rejetait comme invalides. Même quand les paquets n’étaient pas rejetés, le réordonnement et la gigue augmentaient parce que les chemins différaient.

La correction fut peu glamour : revenir à actif/standby pour la plupart du trafic, réserver l’actif/actif seulement pour quelques flux massifs sans état, et imposer la symétrie avec du policy routing là où c’était nécessaire. Les graphiques de débit furent moins excitants. Les utilisateurs ont cessé d’appeler. C’est le KPI qui compte.

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

Un bureau de taille moyenne utilisait dual FAI avec deux tunnels IPsec vers un centre de données. Rien d’ostentatoire : VPN basé sur routes, primaire/secondaire, sondes qui testaien‑t une loopback distante et un port TCP, plus un timer de maintien de 60 secondes avant le retour automatique.

Ils faisaient aussi quelque chose que personne n’aime : des exercices de basculement trimestriels pendant une fenêtre de maintenance. Ils ne débranchèrent pas seulement des câbles ; ils simulèrent des pannes partielles — injection de perte, pannes DNS, blackholes de routage amont — parce que c’est ce que les vrais FAI vous font quand vous avez des plans pour le week‑end.

Quand une équipe de construction a coupé la fibre (prévisible, éternel), le bureau a perdu quelques secondes de trafic et a continué de fonctionner. Le tunnel a basculé, les routes se sont mises à jour, et le système de supervision a alerté avec un message clair « basculement VPN réussi ». Personne n’a eu besoin de se connecter en SSH depuis un téléphone.

Le post‑mortem fut court : confirmer les timelines, confirmer que l’exercice correspondait à la réalité, ouvrir le ticket FAI, et retourner au travail. L’ennuyeux est une fonctionnalité.

Erreurs courantes : symptôme → cause racine → correctif

Cette section est pour quand vous êtes déjà en retard.

1) Symptom : ISP1 tombe et le tunnel tombe ; le tunnel sur ISP2 ne se lève jamais

Cause racine : Le peer distant n’autorise qu’une IP source / un seul tunnel configuré / identité IKE incorrecte pour le secondaire.
Fix : Configurez les deux tunnels côté distant explicitement ; utilisez une ID stable (FQDN ou DN de certificat) plutôt que « mon IP publique » ; confirmez la reachabilité UDP/500 et UDP/4500 sur ISP2.

2) Symptom : Le tunnel indique « up » mais les utilisateurs n’atteignent rien

Cause racine : Le plan de contrôle est établi ; le plan de données est cassé à cause de routes manquantes, mauvais sélecteurs de trafic, ou routage côté distant.
Fix : Sondez une loopback distante à travers le tunnel ; vérifiez que la route vers le sous‑réseau distant pointe vers l’interface tunnel ; vérifiez les routes de retour distantes vers les sous‑réseaux du bureau.

3) Symptom : Le basculement se produit, mais le SaaS fonctionne et les apps internes non

Cause racine : Seul le chemin VPN est cassé (reachabilité du peer, ESP bloqué, ou route overlay non échangée), tandis que l’Internet général reste fonctionnel.
Fix : Sondez l’underlay l’IP publique spécifique du peer depuis chaque FAI ; utilisez des sondes overlay ; ne comptez pas sur « Internet est up » pour prouver que le VPN est sain.

4) Symptom : Sites aléatoires ou gros téléchargements échouent seulement via le VPN, surtout après basculement

Cause racine : Blackhole MTU/PMTU ; ICMP bloqué ; MSS TCP trop grand pour le chemin encapsulé.
Fix : Clamez le MSS sur le tunnel ou à la sortie LAN ; réglez l’MTU du tunnel ; autorisez ICMP fragmentation‑needed quand c’est possible ; vérifiez avec des pings DF.

5) Symptom : Actif/actif semble OK jusqu’à ce que les appels vocaux sonnent robotiques

Cause racine : Gigue/réordonnement de chemin ; routage asymétrique ; ECMP distribuant des flux sur des liens de qualités différentes.
Fix : Utilisez un steering conscient des applications ; épinglez la voix sur le meilleur lien ; ou arrêtez d’être trop malin et passez en actif/standby.

6) Symptom : Flapping—basculement fréquent toutes les quelques minutes

Cause racine : Seuils de sonde agressifs ; cible de sonde unique ; failback sans temporisation.
Fix : Utilisez plusieurs cibles de sonde ; exigez des échecs consécutifs ; ajoutez un timer de maintien pour le failback ; ajustez les seuils selon la tolérance applicative.

7) Symptom : Le tunnel secondaire se lève, mais le trafic de retour meurt (trafic unidirectionnel)

Cause racine : Le côté distant route toujours via le tunnel primaire ; propagation de route retardée ; routage asymétrique + rejet par firewall stateful.
Fix : Assurez‑vous que le distant utilise des priorités de route correspondant à la santé des tunnels ; si vous utilisez BGP, validez le retrait/annonce des routes ; si statique, utilisez des routes suivies liées à l’état du tunnel.

8) Symptom : Tout casse seulement pendant le rekey, surtout sur le secondaire

Cause racine : Timers de rekey coïncident avec un lien instable ; propositions incompatibles ; DPD trop lent/rapide causant des négociations répétées.
Fix : Alignez les propositions crypto ; décalez les rekey ; ajustez DPD ; validez les logs lors des fenêtres de rekey.

Checklists / plan étape par étape

Si vous voulez un basculement VPN de bureau qui ne nécessite pas un ingénieur de soutien émotionnel dédié, suivez ce plan. Il est volontairement opiniâtre parce que la réalité l’est aussi.

Étape 1 : Choisissez votre architecture cible

Par défaut : IPsec basé sur routes, tunnels actif/standby, sondes du plan de données pilotant les changements de route.
Voie d’amélioration : ajoutez du routage dynamique (BGP) sur les deux tunnels quand vous avez plusieurs préfixes/sites.
Éviter : le « basculement » par DNS, des scripts qui éditent des configs à chaud, et l’ECMP sauf si vous comprenez la symétrie et l’état.

Étape 2 : Rendre les identités et la configuration robustes aux changements WAN

Utilisez des IDs IKE stables (FQDN ou certificats) plutôt que « mon IP publique ».
Configurez les deux tunnels sur le peer distant explicitement.
Documentez les ports et protocoles requis (UDP/500, UDP/4500 ; ESP si pas de NAT‑T).

Étape 3 : Implémenter des sondes qui mesurent l’utilité

Sondes underlay : 2–3 cibles Internet par FAI (lié à l’interface), pas seulement le next‑hop du FAI.
Sondes overlay : pinger une loopback distante plus une connexion TCP à un service interne.
Logique de décision : échecs consécutifs, seuils, et temporisation pour le failback.

Étape 4 : Lier la santé au routage, pas à l’espoir

Routes suivies ou métriques qui changent quand les sondes échouent.
Ordre de préférence clair : primaire sauf preuve du contraire.
Si vous devez faire actif/actif, implémentez des contrôles de symétrie et préparez‑vous à déboguer les pertes d’état.

Étape 5 : Ingénierie pour MTU et réalité du rekey

Réglez MTU/MSS correctement dès le départ. Ce n’est pas un « nice to have ».
Décalez les timers de rekey si votre plateforme le permet.
Conservez les logs assez longtemps pour capturer des motifs horaires/quotidiens.

Étape 6 : Supervision et alerting qui ne crie pas au loup

Alerter sur : tunnel down, échecs des sondes overlay, et fréquence de flap.
Enregistrer : quel FAI est actif, perte/latence des sondes, et changements de route.
Avoir un signal unique « basculement VPN réussi » ; cela réduit la panique et le bruit des tickets.

Étape 7 : Tester comme un adulte

Tester une perte complète du FAI (lien down).
Tester des pannes partielles (bloquer UDP/4500, injecter de la perte, casser le DNS).
Tester le comportement de retour (temporisation de hold‑down et stabilité).

FAQ

1) Dois‑je faire actif/actif ou actif/standby pour le VPN de bureau ?

Actif/standby sauf si vous avez un besoin de bande passante mesuré qu’un lien seul ne peut satisfaire. L’actif/actif introduit des problèmes de symétrie et d’état coûteux à dépanner.

2) Puis‑je me fier uniquement à DPD pour le basculement ?

Non. DPD détecte la réactivité du pair, pas l’utilité applicative. Vous avez aussi besoin de sondes du plan de données à travers le tunnel et idéalement d’un contrôle TCP applicatif.

3) Pourquoi mon pare‑feu dit que le tunnel est up mais rien ne fonctionne ?

Parce qu’IKE peut être établi alors que les routes, les sélecteurs, ou le routage de retour côté distant sont incorrects. Testez toujours l’atteignabilité overlay vers une IP/service distant connu.

4) Quelle est la meilleure cible de sonde pour la santé de l’overlay ?

Une IP de loopback sur le gateway VPN distant (stable, toujours routée) plus une sonde TCP vers un service réel qui vous importe (par ex. HTTPS sur un load‑balancer interne).

5) Ai‑je besoin de BGP pour un bon basculement ?

Pas pour un bureau unique vers un site unique. Des routes statiques avec tracking peuvent être parfaitement fiables. Utilisez BGP quand vous avez plusieurs préfixes, plusieurs sites, ou que vous en avez assez de gérer des routes statiques.

6) À quelle vitesse le basculement doit‑il être ?

Assez rapide pour que les utilisateurs ne remarquent pas, assez lent pour éviter le flap. En pratique : détection ~10–30 secondes pour beaucoup de bureaux, avec un hold‑down de failback de 60–300 secondes. Ajustez selon le comportement mesuré du lien.

7) Pourquoi de gros transferts échouent mais de petits pings passent ?

Classique blackhole MTU/PMTU. Les petits paquets ICMP passent, les gros segments TCP non. Corrigez en clampant MSS et vérifiez avec des pings DF.

8) Puis‑je faire le basculement en changeant le DNS public du endpoint VPN ?

Vous pouvez, mais ce n’est pas un basculement fiable. Le caching DNS et les sessions longue durée vous trahiront. Utilisez deux tunnels et du vrai routage/sondes basées sur la santé.

9) Que faire si mon FAI utilise du CGNAT sur le lien de secours ?

C’est encore possible si le peer distant accepte NAT‑T avec changement de ports/adresses sources, mais c’est plus risqué. Préférez une IP publique réelle pour la terminaison VPN, ou utilisez un relais/terminaison cloud sous votre contrôle.

10) Comment empêcher le flapping de failback quand ISP1 est « en grande partie revenu » ?

Ajoutez un timer de maintien et exigez des sondes saines soutenues avant de revenir. Sondez plusieurs cibles ; un chemin revenu ne signifie pas que l’Internet est réellement sain.

Conclusion : prochaines étapes réalisables cette semaine

Si vous voulez un basculement VPN de bureau qui ne nécessite pas de babysitting manuel, cessez de penser en termes de « deux circuits » et commencez à penser en termes de « chemins mesurables et pilotables ». Construisez deux tunnels, prouvez que les deux marchent, et faites choisir au routeur/pare‑feu selon la santé du plan de données — pas selon les voyants du lien.

Prochaines étapes pratiques

Inventaire de la réalité : Confirmez que les deux FAI peuvent atteindre le peer VPN distant et que UDP/500/4500 passent dans les deux sens.
Mettez en place le tunnel secondaire : Configurez‑le sur les deux bouts. Vérifiez qu’il s’établit et peut passer du trafic avant de l’appeler « redondant ».
Ajoutez des sondes overlay : Pinger une loopback distante et exécuter une sonde TCP vers un service à travers le tunnel. Faites suivre le routage des résultats de la sonde.
Réglez l’MTU tôt : Testez les pings DF, clamez le MSS, et documentez les valeurs retenues.
Faites un exercice de basculement : Induisez une panne dans une fenêtre contrôlée, observez les changements de route, confirmez l’impact utilisateur, et ajustez les seuils pour arrêter le flap.

Faites cela et vous obtiendrez le vrai prix : le second FAI cessera d’être un don mensuel aux dieux du réseau et redeviendra ce qu’il devait être — une assurance ennuyeuse qui paie quand il le faut.