Tutorial
Failover Dual-WAN MikroTik pour FAI
Comment bâtir un failover dual-WAN MikroTik fiable pour un parc de FAI : routage récursif, Netwatch, NAT par WAN, temps de bascule et vérification distante.
Résumé Le failover dual-WAN de MikroTik maintient un site en ligne en déplaçant automatiquement le trafic vers un lien de secours lorsque le lien primaire tombe. RouterOS vous donne trois briques — le routage récursif avec check-gateway, Netwatch et le NAT par WAN — et la bonne combinaison dépend de la rapidité et de l’intelligence dont votre détection a besoin. Pour les parcs de FAI, le problème le plus difficile n’est pas le bout de configuration, mais de confirmer, sur des centaines de sites distants derrière du CGNAT, que la bascule a réellement fonctionné. Ce guide couvre les deux.

Qu’est-ce que le Failover Dual-WAN de MikroTik ?
Le failover dual-WAN de MikroTik est une configuration RouterOS qui donne à un routeur deux liens internet — un primaire et un de secours — et déplace automatiquement le trafic vers le secours quand le primaire cesse de transmettre des paquets, puis le ramène une fois rétabli. Ce n’est pas la même chose que la répartition de charge : le failover garde un lien au repos comme assurance, tandis que la répartition étale le trafic sur les deux. L’objectif est la continuité, pas la bande passante supplémentaire, et c’est pourquoi c’est le schéma de redondance par défaut pour les sites qui ne peuvent tout simplement pas tomber dans le noir.
Le mécanisme repose sur la sélection de route. RouterOS choisit la route par défaut active selon la plus faible distance administrative, vous donnez donc au primaire une distance plus petite et au secours une plus grande. Toute la conception se réduit alors à une question : comment le routeur décide-t-il que le primaire est « tombé » et déclasse-t-il sa route ? Réussissez cette décision — assez rapide, mais pas nerveuse — et le failover est fiable. Ratez-la et vous basculerez soit trop lentement, soit en oscillant entre les liens à chaque paquet perdu.
Étape 1 — Cartographiez les deux WAN avant de toucher à une route
Commencez par noter ce qu’est réellement chaque lien. Un primaire fibre fixe ou PPPoE avec une passerelle statique ou attribuée par PPP se comporte différemment d’un secours Starlink ou LTE qui siège derrière du Carrier-Grade NAT et vous remet une adresse dynamique. Cela compte parce que le routage récursif ne fonctionne qu’avec des passerelles IP stables, pas avec des types d’interface dynamiques comme PPPoE ou DHCP où l’adresse peut changer (Documentation MikroTik — Failover (WAN Backup)). Décidez quel lien est primaire, lequel est de secours, et si l’un d’eux change d’IP à la reconnexion — ce seul fait dicte la méthode de détection que vous pouvez utiliser.
Étape 2 — Ajoutez des routes par défaut récursives avec check-gateway
L’approche classique utilise le routage récursif : au lieu de pointer la route par défaut directement vers un prochain saut, vous la pointez vers une cible de sonde (par exemple un résolveur public bien connu) et ajoutez une route statique disant à RouterOS d’atteindre cette cible uniquement via une passerelle WAN précise. Vous créez ensuite deux routes par défaut résolues récursivement sur ces cibles — la primaire avec une distance plus petite et check-gateway=ping activé, le secours avec une distance plus grande (Scoop — Basic ISP Failover with MikroTik).
Le comportement à anticiper, c’est le timing. Check-gateway désactive une route après deux vérifications échouées consécutives, et les vérifications s’exécutent environ toutes les 10 secondes, si bien que la bascule réelle se situe autour de 20 à 30 secondes — et elle ne réagit pas à la perte de paquets intermittente, seulement à une passerelle totalement morte (Documentation MikroTik — Failover (WAN Backup)). Pour beaucoup de sites clients de FAI, c’est acceptable. Pour des terminaux voix ou de paiement, souvent non, et c’est là qu’intervient l’Étape 4.
Étape 3 — Configurez le NAT pour les deux liens
Un routeur dual-WAN a besoin d’une règle masquerade (ou src-nat) distincte par interface WAN pour que le lien actif traduise correctement le trafic sortant ; une seule règle liée à une interface cassera silencieusement la connectivité au moment où le failover déplacera le trafic vers l’autre lien. Ajoutez une règle masquerade dans la chaîne srcnat pour l’out-interface primaire et une seconde pour le secours. Si vous publiez des services entrants, rappelez-vous que les règles dst-nat liées à l’adresse du primaire cessent de fonctionner quand ce lien — et son IP publique — disparaît. Cette fragilité en entrée est le même piège architectural traité dans notre cas des changements d’IP Starlink, et c’est pourquoi un accès ancré sur le sortant passe mieux à l’échelle que la redirection de ports. Pour les fondamentaux du NAT, voyez notre guide de configuration du NAT sur MikroTik.
Étape 4 — Utilisez Netwatch quand vous avez besoin d’une détection plus rapide ou plus intelligente
Quand 20–30 secondes sont trop lentes ou que vous devez agir sur des liens dégradés-mais-vivants, Netwatch est l’outil le plus flexible. Dans RouterOS v7, Netwatch a gagné un paramètre type capable de sonder avec icmp, tcp-conn, http-get, https-get ou simple, et vous pouvez définir votre propre intervalle de vérification au lieu de subir la cadence fixe de check-gateway (Documentation MikroTik — Failover (WAN Backup)). Chaque hôte a un script up et un script down, vous pouvez donc désactiver la route par défaut primaire, lever une alerte ou journaliser l’événement lors de la transition.
Beaucoup d’opérateurs combinent les deux : le routage récursif gère la mort nette du lien, tandis que Netwatch couvre les cas plus brouillons et envoie des notifications. Un long fil communautaire débat exactement de ce compromis et mérite d’être lu avant de standardiser une méthode sur tout un parc (Forum MikroTik — netwatch instead of recursive routing). Quel que soit votre choix, gardez la configuration identique sur chaque site — un parc de scripts de failover sur mesure est lui-même une panne qui n’attend que d’arriver.
Étape 5 — Vérifiez la bascule sur chaque site distant
Voici la partie que les tutoriels de configuration sautent. Ajouter les routes sur un routeur de labo est facile ; prouver que le failover fonctionne sur des centaines de CPE déployés est le vrai problème du FAI — et cela se complique quand le lien de secours est Starlink ou LTE derrière du CGNAT, car l’appareil n’a souvent aucune IP publique joignable pour l’administrer après la bascule. Si vous ne pouvez confirmer le failover qu’en attendant l’appel d’un client, vous n’avez pas vraiment de failover ; vous avez un script dont vous espérez qu’il s’exécute.
C’est là que la gestion centralisée change l’économie. MKController garde chaque routeur joignable via un tunnel sortant authentifié, vous pouvez donc confirmer que le chemin de secours transporte du trafic, observer la transition de failover dans la supervision et pousser une configuration corrigée — sans dépendre d’une IP publique qui pourrait ne pas exister sur le lien de secours. Associez cela à de la télémétrie : nos guides sur la supervision de MikroTik à distance avec Zabbix et la supervision SNMP pour MikroTik montrent comment alerter sur l’événement de failover lui-même, pour qu’un passage silencieux vers le lien de secours coûteux ne passe jamais inaperçu.
Conseils
- Gardez la sonde
check-gatewaydu lien de secours pointée vers une cible que vous atteignez via ce lien, pas via le primaire, sinon votre test n’a aucun sens. - Marquez les transitions de failover dans votre supervision pour qu’un site tournant depuis des jours sur son lien de secours génère un ticket — un failover que personne ne remarque est un coût récurrent, pas un sauvetage.
- Testez le vrai câble, pas seulement la route : débranchez le connecteur du primaire et chronométrez la bascule réelle.
Ramenez le failover sous un seul plan de contrôle
Le failover dual-WAN sur un seul MikroTik est un problème résolu. Le faire de façon fiable sur tout un parc — avec une configuration cohérente et la capacité de prouver que le secours fonctionne sur un routeur que vous ne pouvez pas joindre par IP publique — c’est là que la plupart des opérateurs perdent de l’argent. Une gestion centralisée, ancrée sur le sortant, comble cette lacune.