Guide technique
MikroTik multi-sites : relier des RouterOS distants sans ouvrir le réseau
Un déploiement MikroTik multi-sites n’est pas « plusieurs Winbox ». C’est un problème de chemin de management, de visibilité et de reprise : comment joindre chaque routeur derrière un NAT, savoir lequel est down, et restaurer un site sans être sur place. Ce guide détaille l’architecture technique avant de parler outil.
Ce que « multi-sites » veut dire sur MikroTik
Multi-sites, ce n’est pas seulement « plusieurs routeurs ». Un seul bâtiment avec trois hAP reste un site. Le cas multi-sites commence quand chaque emplacement a sa propre sortie Internet, son propre NAT, souvent un ISP différent, et qu’aucun LAN commun ne relie les équipements.
L’intention de recherche est opérationnelle : comment un intégrateur ou un MSP voit tous les RouterOS à la fois, sans VPN site-à-site dessiné à la main entre chaque paire de sites, et sans exposer le port 8291 sur chaque IP publique.
Sur le terrain, le schéma qui tient est presque toujours le même : chaque site initie une connexion sortante vers un point central (cloud ou CHR), keepalive régulier, puis le management (API, SSH, backup) passe dans ce tunnel. Inverser le flux — le centre qui pousse vers l’IP WAN du client — casse dès qu’il y a CGNAT ou box grand public.
Contraintes réelles d’un parc multi-sites
Les échecs d’adoption multi-sites viennent rarement de RouterOS lui-même. Ils viennent du chemin jusqu’au routeur.
- CGNAT opérateur : pas d’IP publique dédiée, impossible de DNAT Winbox
- Box ISP qui change d’IP ou coupe l’UDP inbound
- Sites sans DNS configuré sur le routeur (endpoint hostname inutile)
- Coupure courte prise pour un offline « client down »
- Pas de backup hors du flash : un brick = site perdu
NAT et handshake
WireGuard ou IPsec n’établissent un tunnel que si au moins un paquet atteint le pair. Persistent-keepalive côté site résout la majorité des NAT, à condition que l’endpoint central soit une IP ou un hostname résolu, et que l’UDP du listen-port arrive bien au concentrateur.
DNS optionnel, IP obligatoire
Un routeur de lab ou un équipement « nu » n’a parfois aucun serveur DNS. Un endpoint en FQDN reste alors à current-endpoint vide et tx=0. En multi-sites, l’endpoint de management doit pouvoir être une adresse IP publique stable.
Architecture de management recommandée
Trois familles existent. Elles ne se valent pas dès que le nombre de sites dépasse une poignée.
Maillage VPN site-à-site
Chaque paire de sites a un tunnel. Le nombre de tunnels explose (n²). Utile pour le trafic métier (VLAN étendu), lourd pour le seul management. Un oubli de keepalive et un site devient invisible.
Hub-and-spoke vers un CHR / VPS
Un concentrateur (souvent un CHR) termine les tunnels. Chaque site n’a qu’un pair. C’est le schéma le plus lisible pour du multi-sites MikroTik : un listen-port, une ACL, un inventaire d’allowed-address.
Contrôleur cloud + tunnel sortant
Le site n’ouvre rien. Il établit le tunnel, le contrôleur parle API/SSH dans le tunnel. Backups et alertes vivent hors du site. C’est le modèle qui évite de maintenir un CHR « artisan » par intégrateur, tout en gardant le même principe réseau.
Exploitation au quotidien : ce qu’il faut voir en une écran
Une fois les tunnels up, le besoin n’est plus « comment joindre » mais « quel site dérive ». Un opérateur multi-sites doit répondre en quelques secondes : combien de routeurs offline, depuis quand, est-ce une fenêtre de maintenance, y a-t-il un backup récent.
Sans cette vue agrégée, on rouvre Winbox site par site — exactement ce que le multi-sites était censé éliminer. L’historique court (last-seen, handshake, CPU) suffit pour le diagnostic ; le data lake n’est pas le sujet.
- Statut online / pending / offline par site, pas seulement par IP WAN
- Délai de grâce au reboot pour éviter les fausses alertes
- Backup cloud horodaté lié à l’identité du routeur
- Session d’accès temporaire plutôt que port 8291 ouvert
Sécurité : ne pas transformer le hub en surface d’attaque
Le concentrateur multi-sites voit tous les managements. Il doit être traité comme une zone de confiance minimale : comptes dédiés, API restreinte au préfixe du tunnel, pas de Winbox exposé sur le WAN des clients.
Côté site, le compte de supervision n’a pas besoin des droits « design » complets si la plateforme ne fait que lire les ressources, pousser un backup et ouvrir une session bornée. Séparer l’identité d’exploitation de l’admin local évite qu’un script d’adoption ne devienne un super-utilisateur oublié.
Erreurs classiques en multi-sites MikroTik
Les mêmes échecs reviennent d’un projet à l’autre.
- Endpoint en hostname alors que le routeur n’a pas de DNS
- Pas de persistent-keepalive derrière NAT
- Forward UDP du concentrateur cassé : les anciens tunnels restent up, les nouveaux jamais
- Inventaire Excel désyncronisé des allowed-address WireGuard
- Backup uniquement local : un site brické n’a plus de config
Routiv pour un parc MikroTik multi-sites
Routiv industrialise le schéma hub-and-spoke : chaque routeur établit un tunnel sortant vers le concentrateur, apparaît dans une flotte unique, dépose des backups hors site et peut être joint en session contrôlée — sans ouvrir Winbox chez le client.
Pour un pilote : un site lab, vérifier handshake et premier backup, puis enrôler un deuxième site distant. L’essai 30 jours sur routiv.net permet de valider le chemin de management avant de généraliser.
FAQ
Comment connecter plusieurs sites MikroTik à un seul contrôleur ?+
Tunnel sortant par site (WireGuard en pratique) vers un hub. Le contrôleur parle ensuite à l’IP du tunnel, pas à l’IP WAN du client.
Faut-il une IP publique sur chaque site ?+
Non. Le site initie le tunnel. Seul le concentrateur a besoin d’un endpoint joignable (IP ou DNS + forward UDP).
WireGuard ou IPsec pour du multi-sites management ?+
WireGuard est plus simple à industrialiser (clés, keepalive, allowed-address). IPsec reste pertinent pour du trafic métier site-à-site déjà en place.
Pourquoi les nouveaux sites sont offline alors que les anciens marchent ?+
Souvent le port UDP du hub n’accepte plus les nouvelles sessions, ou l’endpoint du script (hostname) ne se résout pas sur le routeur nu.
The Dude peut-il remplacer un contrôleur multi-sites ?+
Non dès que les sites sont isolés derrière NAT. The Dude suppose un chemin IP vers chaque équipement.
Que surveiller en priorité ?+
Handshake / last-seen, puis backup hors site réussi. CPU et WAN viennent ensuite pour le diagnostic.
Comment éviter les fausses alertes au reboot ?+
Délai de grâce de quelques minutes et distinction pending (jamais vu) vs offline (vu puis perdu).
Où stocker les backups multi-sites ?+
Hors de chaque routeur, centralisés, liés à l’identité de l’appareil, avec test de restore ponctuel.
À lire aussi
Essai 30 jours — sans carte
Essai gratuit 30 jours