Deux connexions Internet au bureau : basculement VPN sur MikroTik sans chaos

Ce que vous construisez vraiment (et pourquoi ça casse)

Quand on dit « basculement », on entend généralement « si l’ISP A meurt, on utilise l’ISP B ». Pour les VPN, ce n’est que la coque extérieure.
Le système réel est une chaîne de dépendances : décisions de routage, comportement du NAT, accessibilité du pair du tunnel, état des sessions, et la rapidité à détecter le problème sans osciller.

L’ennemi n’est pas le manque de fonctionnalités. RouterOS a les commandes nécessaires. L’ennemi, ce sont les configurations partielles qui se combattent entre elles :
routes par défaut en concurrence avec des routes de politique, suivi de connexion qui fixe des flux sur une sortie morte, NAT réécrivant les réponses sur la mauvaise interface,
et des vérifications de santé qui mesurent la mauvaise chose.

Voici le modèle mental le plus important : le basculement VPN n’est pas un événement unique ; c’est un changement contrôlé de chemin tout en préservant le déterminisme.
Déterminisme signifie : pour un flux donné, vous pouvez prédire quelle WAN il utilise, quelle adresse source il utilise, ce que fait le NAT, et par quel tunnel il sort.
Si vous ne pouvez pas le prédire, vos utilisateurs le « découvriront » via des interruptions.

Blague n°1 : Dual WAN, c’est comme acheter deux parapluies et supposer que la pluie organisera son emploi du temps autour de vos réunions.

Les trois modes de défaillance que vous voyez sur le terrain

• Routage asymétrique : sortie via l’ISP A, retour entrant via l’ISP B (ou inversement). Les VPN et les pare-feux stateful détestent ça.
• Fausse santé : la passerelle répond aux pings mais l’amont est mort ; votre « basculement » ne se déclenche jamais car vous avez mesuré le mauvais saut.
• Tempêtes de flapping : une perte de paquets minime fait rebondir les routes/tunnels toutes les quelques secondes. Le VPN est « up », mais rien ne reste stable.

Une citation, parce que c’est vrai en production

Werner Vogels (idée paraphrasée) : « Tout échoue, tout le temps. » Concevez des systèmes qui s’y attendent, et votre astreinte pourra dormir.

Faits et contexte historique (court, utile, légèrement déprimant)

1. IPsec précède la commodité des “cloud VPN” modernes. Les RFC de base datent de la fin des années 1990, ce qui explique certaines de ses aspérités.
2. Le NAT traversal (NAT-T) est devenu la norme parce que tout le monde a insisté sur le NAT. Encapsuler ESP dans UDP/4500 était un compromis pratique, pas élégant.
3. Les pare-feux stateful ont changé les attentes de routage. Une fois que vous suivez les connexions, « n’importe quel chemin de retour » cesse d’être acceptable ; le trafic retour doit correspondre à l’état.
4. Le Multi-WAN s’est popularisé en PME avant d’être bien maîtrisé. Beaucoup de petits bureaux ont adopté des doubles ISP bien avant d’avoir du personnel pour opérer le routage de politique en sécurité.
5. BFD (Bidirectional Forwarding Detection) existe parce que les protocoles de routage avaient besoin d’une détection de panne plus rapide que les timers hello. MikroTik supporte BFD avec certains protocoles, mais la plupart des designs SMB ne l’utilisent jamais.
6. “check-gateway=ping” n’est pas un oracle de disponibilité. Il vous dit une chose seulement, et cette cible peut encore répondre pendant que l’Internet brûle.
7. WireGuard est jeune (années 2010) et volontairement minimaliste. Cette simplicité le rend plus facile à raisonner pour le basculement comparé aux piles héritées, mais il faut quand même de la discipline de routage.
8. Le Carrier-grade NAT (CGNAT) a discrètement rompu des hypothèses. Votre « IP publique » pourrait ne pas être la vôtre, et l’initiation entrante d’un VPN peut devenir impossible sans aide.
9. Les timeouts du connection tracking importent plus qu’on ne le pense. En basculement, des entrées conntrack obsolètes peuvent fixer des flux sur une egress morte même après un changement de route.

Principes de conception pour garder le basculement VPN raisonnable

1) Décidez ce que signifie « succès » : liaison up, Internet up ou VPN utilisable ?

Une liaison physique peut être up tandis que le fournisseur blackhole des routes. Une passerelle par défaut peut répondre tandis que le DNS amont est mort.
Et un VPN peut afficher « established » alors que vos applis timeoutent à cause d’un MTU ou d’un routage asymétrique.

Votre cible de vérification de santé doit correspondre au niveau qui vous importe :
ping de la passerelle ISP détecte les pannes L2/L3 ; ping d’une IP publique détecte la reachabilité amont ;
vérification du point de terminaison VPN distant détecte la viabilité du service réel. La plupart des bureaux ont besoin au minimum de la reachabilité amont.

2) Préférez le routage déterministe au « magique »

MikroTik peut faire beaucoup automatiquement, mais les comportements automatiques sont souvent « raisonnables » uniquement en environnement mono-WAN.
Dual WAN + VPN exige des choix explicites :

• Quelle adresse source chaque tunnel doit-il utiliser ?
• Quel WAN chaque tunnel doit-il préférer ?
• Quel trafic peut basculer, et qu’est-ce qui doit rester attaché ?
• Comment empêcher les sessions existantes de rester attachées à une WAN morte ?

3) Construisez pour un basculement stable, pas pour un basculement ultra-rapide

Oui, vous voulez une récupération rapide. Non, vous ne voulez pas un routeur qui change d’avis à chaque éternuement de paquet.
Ajoutez de l’hystérésis : plusieurs échecs consécutifs avant de basculer, et plusieurs succès consécutifs avant de revenir.

4) Traitez le NAT comme partie du routage (parce que c’en est)

Avec deux WAN, les règles NAT doivent être conscientes de l’interface et alignées sur votre politique de routage.
Si le trafic sort via ISP B mais est NATé vers l’adresse de l’ISP A, vous vous êtes infligé une panne.

5) Isolez le routage VPN du routage Internet du bureau

Les défaillances les plus propres sont des défaillances circonscrites. Mettez votre logique de décision VPN dans des tables de routage séparées (VRF si vous êtes sérieux),
ou au moins des tables séparées avec des marques de routage, et gardez le trafic de navigation par défaut hors de cette logique.

Blague n°2 : Si vous ne pouvez pas expliquer votre routage de politique sur un seul schéma au tableau blanc, votre routeur complote déjà contre vous.

Trois architectures viables (choisissez-en une, ne les mélangez pas)

Architecture A : route par défaut active/standby simple avec initiation VPN propre

C’est le design « petit bureau mais veut moins de surprises ». Vous gardez une route par défaut principale via WAN1, une secondaire via WAN2 avec une distance plus élevée.
Les pairs VPN sont joignables via la WAN active ; quand WAN1 échoue, le routeur change la route par défaut et le VPN se rétablit depuis WAN2.

Avantages : plus simple, moins de règles mangle, moins de risque d’autodDoS via le routage de politique. Inconvénients : les sessions existantes meurent au basculement. C’est acceptable ; vous basculez, vous ne faites pas de chirurgie.

Idéal pour : un ou deux tunnels site-à-site, IPsec avec peers dynamiques, ou WireGuard où la reconnexion est bon marché.

Architecture B : routage de politique avec egress VPN fixé + basculement par tunnel

Ici vous routez explicitement le trafic du tunnel VPN lui-même (IKE/ESP ou UDP WireGuard) via une WAN préférée, mais vous autorisez une bascule.
Vous utilisez des marques de routage pour que « trafic vers le pair VPN » utilise une table dédiée avec deux routes par défaut : WAN1 primaire, WAN2 secours.

Avantages : isole le trafic de contrôle VPN du surf du bureau ; évite les flaps aléatoires du tunnel dus aux changements de route généraux.
Inconvénients : plus de règles, plus de façons de se tirer une balle dans le pied, nécessite de la discipline avec des listes d’adresses et des règles de routage.

Architecture C : deux tunnels (un par ISP) + routage dynamique ou priorité manuelle

C’est l’approche « faites-le correctement ou ne le faites pas » pour une connectivité inter-site sérieuse. Vous construisez deux tunnels indépendants :
un sourcé depuis WAN1, un depuis WAN2. Ensuite vous faites tourner un protocole de routage (ou des routes statiques avec vérificateurs) sur les tunnels.

Avantages : redondance réelle au niveau VPN, moins de dépendance à la re-négociation d’un tunnel unique lors d’un événement ISP.
Inconvénients : plus complexe, nécessite le support du site distant, exige un filtrage et des métriques de routes soigneuses.

Si vous pouvez exécuter du routage dynamique, vous pouvez aussi utiliser BFD pour une détection rapide dans certains setups. Si vous ne le pouvez pas, gardez-le statique et stable.

Choix orienté

Pour la plupart des bureaux : l’Architecture B est le point d’équilibre. Elle isole le comportement VPN sans vous forcer dans la jungle des protocoles de routage.
L’Architecture A est acceptable si vous tolérez de courts déconnects. L’Architecture C s’adresse à ceux qui se font hurler dessus en réunion trimestrielle quand il y a une coupure.

Tâches pratiques : commandes, sorties et décisions

Ce sont des vérifications réelles que vous pouvez exécuter pendant la construction ou le debug. Chaque tâche inclut : une commande, ce que signifie une sortie typique, et la décision à prendre.
Les commandes sont en CLI RouterOS sauf indication contraire. Vous pouvez les coller dans une session terminal MikroTik.

Task 1: Confirm interface state and speed/duplex (don’t assume cabling is fine)

cr0x@server:~$ /interface/ethernet/print detail where name~"ether1|ether2"
 0 name="ether1" default-name="ether1" mtu=1500 l2mtu=1598 mac-address=DC:2C:6E:AA:BB:01 arp=enabled
   speed=1Gbps full-duplex=yes auto-negotiation=yes link-downs=0
 1 name="ether2" default-name="ether2" mtu=1500 l2mtu=1598 mac-address=DC:2C:6E:AA:BB:02 arp=enabled
   speed=100Mbps full-duplex=yes auto-negotiation=yes link-downs=7

Sens : ether2 a des link-downs et a négocié à 100Mbps. Ce n’est pas « correct » ; c’est un indice.
Décision : échangez le câble, vérifiez la remise au fournisseur, ou verrouillez vitesse/duplex si l’équipement amont est basique. Une liaison WAN instable fait ressembler la logique de basculement à un échec.

Task 2: See your default routes and whether they’re active

cr0x@server:~$ /ip/route/print where dst-address="0.0.0.0/0"
Flags: D - dynamic, A - active, c - connect, s - static
 #      DST-ADDRESS        GATEWAY            DISTANCE
 0  As  0.0.0.0/0          198.51.100.1              1
 1  s   0.0.0.0/0          203.0.113.1               5

Sens : la route WAN1 est active ; WAN2 est en attente (distance plus élevée).
Décision : si les deux sont actives alors que vous en attendiez une seule, vous aurez un comportement proche de l’ECMP et des sessions aléatoires échoueront à moins que vous n’y ayez pensé.

Task 3: Verify “check-gateway” behavior and whether it’s lying to you

cr0x@server:~$ /ip/route/print detail where dst-address="0.0.0.0/0"
 0 A S  dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=1 check-gateway=ping
 1   S  dst-address=0.0.0.0/0 gateway=203.0.113.1 distance=5 check-gateway=ping

Sens : vous pinguez l’IP de la passerelle, pas l’Internet.
Décision : pour un vrai basculement, préférez des routes récursives avec une cible publique (ou des vérifications scriptées) pour tester au-delà du premier saut.

Task 4: Check recursive routing targets (recommended approach for upstream reachability)

cr0x@server:~$ /ip/route/print where comment~"rec-check"
Flags: D - dynamic, A - active, c - connect, s - static
 #     DST-ADDRESS        GATEWAY         DISTANCE COMMENT
 0 As  1.1.1.1/32         198.51.100.1           1 rec-check-wan1
 1  s  0.0.0.0/0          1.1.1.1                1 default-via-wan1
 2  s  8.8.8.8/32         203.0.113.1            1 rec-check-wan2
 3  s  0.0.0.0/0          8.8.8.8                5 default-via-wan2

Sens : les routes par défaut sont récursives via des IP publiques. Si l’IP publique devient inaccessible via cette WAN, la route par défaut tombe.
Décision : utilisez ceci quand vous voulez un basculement basé sur la « reachabilité Internet », pas sur « la passerelle répond à l’ARP ».

Task 5: Confirm the router can reach health targets via the intended WAN

cr0x@server:~$ /ping 1.1.1.1 routing-table=main count=3
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 1.1.1.1                                     56  57 11ms
    1 1.1.1.1                                     56  57 10ms
    2 1.1.1.1                                     56  57 11ms
    sent=3 received=3 packet-loss=0% min-rtt=10ms avg-rtt=10ms max-rtt=11ms

Sens : la reachabilité existe, mais cela ne prouve toujours pas le chemin spécifique à la WAN à moins que vous ne le contraigniez.
Décision : si vous avez besoin de vérifications par WAN, utilisez des règles/tables de routage et pinguez avec routing-table=....

Task 6: Inspect routing rules (policy routing) and catch shadow rules

cr0x@server:~$ /routing/rule/print
Flags: X - disabled
 #   SRC-ADDRESS     DST-ADDRESS     ACTION           TABLE
 0   10.10.10.0/24                    lookup          main
 1                   203.0.113.10/32 lookup          to_wan1_vpn
 2                   203.0.113.11/32 lookup          to_wan2_vpn

Sens : vous routez le trafic vers des pairs VPN spécifiques via des tables dédiées.
Décision : assurez-vous que l’ordre a du sens ; une règle plus large en amont peut voler le trafic à une règle plus spécifique en aval.

Task 7: Validate NAT rules are interface-aware (and ordered correctly)

cr0x@server:~$ /ip/firewall/nat/print
Flags: X - disabled, I - invalid, D - dynamic
 #   CHAIN  ACTION    SRC-ADDRESS       OUT-INTERFACE   COMMENT
 0   srcnat masquerade 10.10.10.0/24    ether1          NAT-to-WAN1
 1   srcnat masquerade 10.10.10.0/24    ether2          NAT-to-WAN2
 2   srcnat accept     10.10.10.0/24    (none)          no-NAT-to-VPN

Sens : la règle « no-NAT-to-VPN » est en dernier, donc elle ne correspondra jamais avant le masquerade.
Décision : déplacez les règles accept au-dessus du masquerade. L’ordre NAT n’est pas un débat philosophique ; c’est un moteur qui s’exécute ligne par ligne.

Task 8: See active IPsec SAs and confirm which local address they use

cr0x@server:~$ /ip/ipsec/active-peers/print detail
 0 address=203.0.113.200 local-address=198.51.100.10 state=established
   nat-traversal=yes ike2=yes exchange-mode=ike2

Sens : le tunnel est établi et sourcé depuis l’IP publique de WAN1.
Décision : si le basculement se produit et qu’il se source toujours depuis la WAN morte, vous avez besoin d’un gestion explicite de local-address ou de politique de routage pour le trafic peer.

Task 9: Check IPsec policies and whether they’re too broad (causing route leaks)

cr0x@server:~$ /ip/ipsec/policy/print
Flags: T - template, D - dynamic, X - disabled, A - active
 #   SRC-ADDRESS      DST-ADDRESS      SA-SRC-ADDRESS    SA-DST-ADDRESS
 0 A 10.10.10.0/24    10.20.20.0/24    198.51.100.10     203.0.113.200
 1   0.0.0.0/0        0.0.0.0/0        198.51.100.10     203.0.113.200

Sens : il y a une policy 0/0. C’est une « arme à feu » qui route tout le trafic dans le tunnel sauf si vous voulez vraiment un full-tunnel.
Décision : supprimez ou désactivez les policies larges sauf si vous pouvez les expliquer à votre vous futur à 3h du matin.

Task 10: Verify WireGuard peer handshakes and transfer on each link

cr0x@server:~$ /interface/wireguard/peers/print detail
 0 interface=wg0 public-key="..." endpoint-address=203.0.113.210 endpoint-port=51820
   allowed-address=10.20.20.0/24 persistent-keepalive=25s
   last-handshake=1m12s rx=145.2MiB tx=162.9MiB

Sens : les handshakes ont lieu ; le trafic circule. Si last-handshake augmente pendant le « basculement », vous ne rétablissez pas la session.
Décision : vérifiez le routage de l’endpoint et les règles NAT ; envisagez deux peers/endpoints si le côté distant supporte les deux ISPs.

Task 11: Check connection tracking for flows stuck on the wrong WAN

cr0x@server:~$ /ip/firewall/connection/print where dst-address~"203.0.113.200" and protocol=udp
Flags: S - seen-reply, A - assured, C - confirmed, D - dying
 #   PROTO SRC-ADDRESS:PORT    DST-ADDRESS:PORT    TIMEOUT     TCP-STATE
 0 SAC udp  198.51.100.10:4500 203.0.113.200:4500 00:00:27

Sens : le flux NAT-T IPsec est suivi et fixé à une source spécifique. En cas de basculement, les anciennes entrées peuvent continuer d’essayer le chemin mort.
Décision : après un changement de route, vous devrez peut-être effacer des entrées conntrack spécifiques (surgicalement) pour forcer la ré-établissement.

Task 12: Flush only what you must (surgical conntrack reset)

cr0x@server:~$ /ip/firewall/connection/remove [find dst-address~"203.0.113.200" and protocol=udp]

Sens : supprime les flux suivis vers le pair afin que le tunnel puisse renégocier en utilisant le nouveau chemin.
Décision : évitez de vider toutes les connexions sauf si vous aimez expliquer au CEO pourquoi tous les appels ont été coupés.

Task 13: Capture traffic to confirm which interface is actually used

cr0x@server:~$ /tool/sniffer/quick interface=ether1 ip-address=203.0.113.200
  TIME  NUM  DIR  SRC-ADDRESS           DST-ADDRESS           PROTOCOL  SIZE
  0.01    1  tx   198.51.100.10         203.0.113.200         udp       146
  0.02    2  rx   203.0.113.200         198.51.100.10         udp       146

Sens : le trafic utilise ether1. Si vous pensez avoir basculé sur ether2 mais voyez des paquets sur ether1, le routage/NAT ne fait pas ce que vous croyez.
Décision : faites confiance à la capture de paquets plutôt qu’aux tableaux de bord et aux impressions.

Task 14: Observe route changes live while you simulate failure

cr0x@server:~$ /log/print follow where topics~"route"
12:01:14 route,info default-via-wan1 inactive
12:01:14 route,info default-via-wan2 active
12:01:16 route,info default-via-wan1 active
12:01:17 route,info default-via-wan2 inactive

Sens : vous êtes en flapping. Ce n’est pas « rapide » ; c’est instable.
Décision : introduisez de l’hystérésis : intervalles de vérification plus longs, plusieurs échecs avant le switch, et basculement de retour retardé.

Task 15: Check CPU load during failover events (VPN crypto can be the bottleneck)

cr0x@server:~$ /system/resource/print
                   uptime: 3d4h22m
                  version: 7.16.1 (stable)
               cpu-load: 84
         free-memory: 214.3MiB
        total-memory: 512.0MiB

Sens : CPU élevée pendant une rekey ou une reconstruction de tunnel peut retarder la convergence et faire timeout les vérifications de santé.
Décision : réduisez la charge crypto (choix d’algorithmes), réduisez le churn des tunnels, ou changez de matériel. « Mais c’est juste un bureau » n’est pas un plan de capacité.

Task 16: Verify MTU/MSS clamping if you see weird app-specific failures

cr0x@server:~$ /ip/firewall/mangle/print where comment~"MSS"
Flags: X - disabled, I - invalid, D - dynamic
 #   CHAIN     ACTION             PROTOCOL  TCP-FLAGS  NEW-MSS  COMMENT
 0   forward   change-mss         tcp       syn       1360     clamp-mss-for-vpn

Sens : un clamp MSS existe. Si vous n’avez pas cela et que vous exécutez des tunnels sur PPPoE ou des MTU mixtes, vous pouvez avoir « VPN up, appli down ».
Décision : si les gros téléchargements stagnent ou si des SaaS spécifiques cassent uniquement via le VPN, testez le PMTUD et envisagez le MSS clamp sur le bon chemin.

Méthode de diagnostic rapide

Quand le VPN « ne bascule pas » (ou bascule dans un mur), vous avez besoin d’un ordre de triage reproductible.
Ceci est optimisé pour la vitesse et le signal, pas pour l’élégance.

Premier : déterminez si vous avez un problème de liaison, de routage ou d’état

1. Liaison : interface down, flapping, problèmes de négociation, perte de paquets.
2. Routage : mauvaise route active, mauvaise table/règle de routage, cible récursive encore joignable via la mauvaise WAN.
3. État : conntrack qui fixe, handshake IPsec/WireGuard obsolète, mapping NAT bloqué.

Deuxième : mesurez les WAN séparément, pas « l’Internet »

• Pinger une cible publique via la table de routage de WAN1.
• Pinger une cible publique via la table de routage de WAN2.
• Sniffer le trafic vers le pair VPN pour confirmer l’interface d’egress réelle.

Troisième : vérifiez le plan de contrôle du tunnel avant le plan de données

Pour IPsec, vérifiez les peers actifs, les SAs, et les logs pour les erreurs de rekey. Pour WireGuard, vérifiez le last handshake.
Si le tunnel n’est pas établi, déboguer les routes vers les sous-réseaux est une perte de temps.

Quatrième : confirmez l’ordre NAT et firewall

Un ordre NAT erroné est classique : vous « autorisez no-NAT vers VPN », mais le masquerade correspond en premier.
Lisez toujours les règles de haut en bas avec la même suspicion cynique que vous réservez aux notes de version des fournisseurs.

Cinquième : ne videz que l’état qui bloque la convergence

Supprimez les entrées conntrack pour le peer. Faites rebondir le tunnel si nécessaire. Évitez de redémarrer le routeur à moins d’avoir épuisé les idées et la crédibilité.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: VPN stays “up” but traffic dies after failover

Cause racine : routage asymétrique ou conntrack obsolète. Les paquets de contrôle du tunnel peuvent encore fonctionner, mais les flux de données sont fixés sur une egress morte.

Correction : appliquez du routage de politique pour le trafic peer ; effacez le conntrack du pair après le basculement ; assurez-vous que les règles NAT correspondent correctement à l’out-interface.

2) Symptom: VPN re-establishes, but only some subnets work

Cause racine : routes qui se chevauchent, policy IPsec trop large, ou routes manquantes sur le site distant après le changement de chemin.

Correction : resserrez les selectors/policies ; vérifiez les routes des deux côtés ; évitez les policies 0/0 sauf si vous voulez réellement un full-tunnel.

3) Symptom: Failover never triggers during “ISP outage”

Cause racine : vous pinguez la passerelle ISP, qui répond encore alors que l’amont est mort.

Correction : utilisez des routes par défaut récursives via des cibles publiques, ou des vérifications scriptées qui testent au-delà de la passerelle.

4) Symptom: Failover triggers constantly (flapping)

Cause racine : vérification de santé trop sensible ; cible instable ; WAN avec perte intermittente ; ou pics CPU retardant les réponses.

Correction : ajoutez de l’hystérésis (multiples échecs/succès), choisissez des cibles stables, réparez la liaison physique, et surveillez le CPU pendant le churn.

5) Symptom: After failback to WAN1, VPN won’t come back without manual intervention

Cause racine : le côté distant attend encore l’ancienne IP source ; mappings NAT bloqués ; peer IPsec verrouillé sur une adresse spécifique ; timers DPD trop lents.

Correction : configurez des peers doubles ou une identité dynamique quand c’est possible ; réduisez les temps de détection DPD avec précaution ; effacez l’état des deux côtés pendant les tests.

6) Symptom: Internet works, but VPN negotiation fails only on WAN2

Cause racine : WAN2 est derrière un CGNAT ou bloque UDP/500/4500 ; ou le MTU diffère suffisamment pour casser les hypothèses de fragmentation.

Correction : testez la reachabilité des ports UDP ; préférez WireGuard à IPsec dans des environnements NAT hostiles ; appliquez un MSS clamp ; envisagez de changer de fournisseur si le VPN est bloqué.

7) Symptom: Users complain “Teams calls break exactly when failover happens”

Cause racine : c’est normal. Les flux temps réel ne survivent pas à un changement de chemin sans résilience au niveau session.

Correction : acceptez que le basculement casse les sessions en direct ; concentrez-vous sur le temps de récupération et la stabilité ; communiquez le comportement attendu.

8) Symptom: Random outbound connections fail when both WAN routes are active

Cause racine : ECMP accidentel sans retour symétrique ; mismatch NAT/conntrack.

Correction : gardez une seule route par défaut active sauf si vous implémentez un PCC/load balancing correct avec NAT assorti ; ne créez pas de multi-path accidentellement.

Trois micro-histoires d’entreprise issues du terrain

Mini-story 1: The outage caused by a wrong assumption

Une entreprise de taille moyenne a ajouté un second circuit fibre après une coupure mémorable où quelqu’un a essayé de faire du hotspot d’un VPN de bureau via un téléphone.
La directive était simple : « basculement automatique ». L’admin réseau a mis deux routes par défaut avec des distances différentes et activé les checks de passerelle.
Ça avait l’air propre. C’était aussi basé sur une mauvaise hypothèse : « Si la passerelle ping, Internet fonctionne. »

Un mois plus tard, l’ISP A a eu un problème de routage en amont. La passerelle est restée joignable, l’ARP était OK, et les pings vers la passerelle étaient parfaits.
Pendant ce temps, tout ce qui était au-delà du bord ISP était blackholé de façon intermittente. Le MikroTik a refusé de basculer parce que sa cible de check était toujours verte.
Les utilisateurs ont vécu un désastre au ralenti : timeouts DNS, échecs de connexion aux SaaS, tunnels VPN « up » mais inutilisables.

L’admin a essayé de « forcer » le basculement en désactivant la route manuellement. Le trafic est passé sur l’ISP B et s’est stabilisé immédiatement.
Puis, dès qu’il a réactivé la route WAN1, le routeur l’a préférée de nouveau (distance=1), et la douleur est revenue. Place aux tickets helpdesk aux symptômes contradictoires.

La correction n’a pas été héroïque. Ils sont passés à des routes par défaut récursives avec checks de reachabilité publique, et ont ajouté de l’hystérésis pour éviter un retour après un seul bon ping.
La leçon opérationnelle n’était pas technique. C’était : votre cible de monitoring définit votre réalité, même quand la réalité n’est pas d’accord.

Mini-story 2: The optimization that backfired

Une autre société voulait « zéro downtime » entre ISPs. Quelqu’un avait lu sur le load balancing et a voulu être malin :
ils ont activé l’équilibrage par connexion sur les deux WAN tout en ayant un IPsec site-à-site vers un datacenter.
L’objectif : utiliser les deux uplinks et « gagner de la bande passante gratuite ».

Ce qu’ils ont obtenu était un bingo d’appels au helpdesk. Les transferts de fichiers démarraient vite puis bloquaient.
Certaines applis web fonctionnaient, d’autres échouaient aléatoirement à s’authentifier. Le VPN renégociait plusieurs fois par heure.
Les graphs de monitoring avaient l’air vivants, ce qui est la pire torture qu’un graphique puisse infliger.

Le problème n’était pas que le load balancing soit mauvais. C’est qu’ils n’ont pas conçu pour des chemins symétriques.
Une partie du trafic vers le peer VPN sortait par WAN1, les paquets de retour arrivaient sur WAN2, conntrack les rejetait, et le plan de données du tunnel devenait un pile-ou-face.
Le NAT a aggravé la situation : des flux sortant par WAN2 étaient parfois masqueradés comme WAN1 parce que les règles étaient trop génériques et mal ordonnées.

Le rollback a été une confession : ils ont remis une route par défaut active, ont épinglé le trafic VPN dans une table dédiée, et ont arrêté d’essayer d’être plus malins que le networking stateful.
L’optimisation de bande passante n’est pas gratuite si elle vous achète des pannes. L’entreprise a préféré la stabilité et un peu de lenteur.

Mini-story 3: The boring but correct practice that saved the day

Une organisation axée finance avait deux ISPs et un VPN site-à-site clé vers une plateforme comptable hébergée.
Ils avaient un processus de changement d’une banalité agressive : toute modification réseau exigeait une étape de rollback écrite, une fenêtre de maintenance planifiée,
et une simulation de basculement au moins une fois par trimestre. Personne n’adorait ça. Personne ne le mettait sur son CV.

Puis un chantier a coupé un conduit. WAN1 est tombé net. WAN2 est resté up.
Le MikroTik a basculé en quelques intervalles de check, le VPN s’est rétabli, et les utilisateurs ont eu une brève déconnexion puis un fonctionnement normal.
Le helpdesk a eu peut-être une poignée d’appels, surtout des gens demandant si « Internet est bizarre ».

Ce qui a fait fonctionner les choses n’était pas un design tape-à-l’œil. C’était la discipline ennuyeuse :
tables de routage séparées pour le trafic de contrôle VPN, règles NAT épinglées sur les out-interfaces, et une procédure testée incluant l’effacement des conntrack peers si nécessaire.
Ils gardaient aussi les logs hors du routeur, pour pouvoir prouver la timeline quand les fournisseurs commençaient la danse du blâme.

Plus tard, lors de la revue post-incident, quelqu’un a demandé pourquoi ça s’était si bien passé.
La réponse de l’admin réseau : « Nous pratiquons ce que nous prétendons avoir. » Ce n’est pas de la poésie, mais c’est comme ça que la production reste ennuyeuse.

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

Étape par étape : construire un basculement VPN dual-WAN sur MikroTik (stable, pas fancy)

1. Inventaire des réalités. Confirmez si chaque ISP vous fournit une IP publique réelle, si l’un est en CGNAT, et si UDP/500/4500 est bloqué.
   Si WAN2 est en CGNAT, prévoyez une initiation sortante uniquement ou WireGuard avec keepalives.
2. Nommez les interfaces et documentez-les. « ether1 » n’est pas de la documentation. Utilisez des commentaires, des listes d’interfaces, et un nommage cohérent.
3. Choisissez votre signal de basculement. Préférez des routes par défaut récursives via des cibles publiques, ou des vérifications scriptées qui testent la vraie reachabilité.
4. Gardez la logique de route par défaut simple. Une route par défaut active, une standby avec distance plus élevée.
   Si vous voulez utiliser les deux liens, c’est un projet séparé avec des modes de défaillance séparés.
5. Isolez le routage des peers VPN. Créez une table de routage pour le trafic peer VPN (et éventuellement une par WAN) et ajoutez des règles pour les IPs de destination des peers.
6. Rendez le NAT déterministe. Placez les règles no-NAT/accept pour les destinations VPN au-dessus du masquerade. Utilisez le match out-interface sur les règles de masquerade.
7. Validez l’établissement du tunnel sur chaque WAN indépendamment. Désactivez temporairement la route WAN1 et confirmez que le tunnel monte sur WAN2, et vice versa.
8. Ajoutez de l’hystérésis. Évitez les retours rapides. Exigez une réussite soutenue avant de revenir sur WAN1.
9. Définissez une procédure de réinitialisation d’état. Sachez quelles entrées conntrack effacer, comment faire rebondir le tunnel, et quels logs vérifier.
10. Testez avec une panne contrôlée. N’arrach ez pas les câbles au hasard. Désactivez une route, ou une interface, pendant une fenêtre planifiée, et surveillez logs/sniffer.
11. Observez les problèmes de MTU. Si des applis se comportent étrangement via le VPN sur un ISP, testez le MSS clamp et le PMTUD.
12. Écrivez-le. La config n’est pas évidente, et vous ne vous souviendrez pas de l’intention dans six mois.

Checklist opérationnelle : avant de pousser des changements en production

• Ayez un plan d’accès hors-bande (console LTE, mains distantes, ou au moins une personne locale avec un laptop).
• Exportez la configuration actuelle et stockez-la en lieu sûr.
• Connaissez vos commandes de rollback et l’ordre d’application.
• Choisissez un test qui correspond au business : résolution DNS, login ERP, transfert de fichier, appel VoIP—ce qui casse en premier.
• Décidez du downtime acceptable par événement de basculement et communiquez-le.

FAQ

1) Can MikroTik do true “seamless” VPN failover without dropping sessions?

Généralement non. La plupart des sessions applicatives se couperont quand l’IP egress publique change.
Vous pouvez réduire le temps d’indisponibilité et accélérer la reconnexion, mais « seamless » exige de la résilience au niveau applicatif ou des designs plus complexes (souvent avec la participation du côté distant).

2) Should I use “check-gateway=ping” on the default route?

Seulement si vous acceptez que cela détecte « ma passerelle est vivante », pas « Internet fonctionne ».
Pour les bureaux, le routage récursif via une cible publique stable est typiquement un meilleur déclencheur de basculement.

3) Is WireGuard easier than IPsec for failover?

Opérationnellement, oui. Le modèle de handshake de WireGuard et son minimalisme rendent le comportement plus facile à raisonner.
Mais vous devez toujours résoudre le déterminisme du routage et du NAT ; WireGuard ne vous sauvera pas d’un routage de politique bâclé.

4) Why does the VPN show established but users can’t reach remote subnets?

Parce que le succès du plan de contrôle ne garantit pas le succès du plan de données. Coupables fréquents : ordre NAT erroné, routes manquantes, chemin asymétrique, ou problèmes de MTU.
Une capture vers le peer et un lookup de route révèlent généralement la vérité.

5) Do I need two VPN tunnels (one per ISP)?

Si le VPN est critique pour le business et que vous pouvez coordonner les deux extrémités, deux tunnels sont l’approche la plus robuste.
Pour un bureau typique tolérant de brèves reconnexions, un tunnel unique pouvant se rétablir sur l’une ou l’autre WAN suffit souvent.

6) What about load balancing across both WANs and VPN failover?

C’est faisable, mais ne tombez pas dedans par accident. Il faut une classification par-connexion cohérente, des règles NAT correspondantes, et un plan pour le retour symétrique.
Si vous n’êtes pas prêt à tester pendant des jours, gardez une WAN principale.

7) How do I avoid flapping between ISPs?

Utilisez l’hystérésis : plusieurs échecs avant le basculement, et un retour retardé jusqu’à preuve de stabilité.
Choisissez aussi des cibles de santé stables et réparez la perte de paquets sous-jacente. Aucun script ne bat un mauvais raccord fibre.

8) How do I test failover safely during business hours?

Ne tirez pas les câbles. Désactivez brièvement la route par défaut primaire, ou baissez sa priorité, et surveillez les logs et l’état du tunnel.
Limitez le test dans le temps, communiquez la fenêtre, et ayez un rollback prêt.

9) Why does WAN2 fail even though general browsing works?

Les protocoles VPN sont plus pointilleux que le trafic web. WAN2 peut bloquer UDP/500/4500, être en CGNAT, ou avoir un MTU inférieur qui casse l’encapsulation.
Testez la reachabilité protocolaire et envisagez WireGuard si IPsec est malmené par le chemin ISP.

Étapes suivantes (les trucs ennuyeux qui évitent les tickets)

Construisez l’architecture la plus simple qui réponde aux besoins métier, puis rendez-la déterministe :
routage explicite pour les peers VPN, règles NAT qui correspondent à l’egress choisi, et checks de santé qui mesurent le bon niveau.
Gardez le basculement stable, pas nerveux. Si vous voulez une convergence plus rapide, investissez dans une meilleure détection — pas dans plus d’aléa.

Étapes pratiques à faire cette semaine :

• Remplacez les pings de passerelle par des checks récursifs de reachabilité vers des cibles publiques.
• Isolez le routage des peers VPN dans une table dédiée et vérifiez avec une capture de paquets.
• Auditez l’ordre des règles NAT et ajoutez des exceptions no-NAT pour les sous-réseaux VPN en haut.
• Exécutez un test de basculement contrôlé et enregistrez : temps de détection, temps de ré-établissement du tunnel, et l’appli bizarre qui se plaint toujours la première.
• Rédigez un runbook d’une page : quoi vérifier, quoi effacer et comment revenir en arrière. Votre vous futur vous remerciera sous forme de moins d’alertes.