Guide technique
Contrôleur RouterOS : piloter la configuration et l’exploitation à l’échelle
RouterOS se configure très bien poste par poste. La difficulté commence quand il faut appliquer, vérifier et maintenir les mêmes standards sur des dizaines de boîtiers — sans ouvrir Winbox en permanence sur Internet. Ce guide détaille ce qu’implique un vrai contrôle de RouterOS côté exploitation.
Ce que signifie « contrôler » RouterOS
Contrôler RouterOS ne se limite pas à ouvrir une session Winbox. Il s’agit de disposer d’un levier fiable pour lire l’état (identité, version, interfaces, ressources), appliquer ou vérifier des configurations, lancer des diagnostics, et garder une trace de ce qui a été fait — sur un équipement isolé comme sur un parc.
RouterOS expose pour cela plusieurs surfaces : Winbox, WebFig, API binaire (port 8728), API REST sur certaines versions, et SSH. Chacune a un rôle. L’API et les automatisations deviennent indispensables dès que le volume d’équipements dépasse ce qu’un technicien peut suivre manuellement.
Un contrôleur RouterOS s’appuie sur ces interfaces pour industrialiser inventaire, collecte, sauvegarde et accès, tout en gardant le plan de données du client (LAN, routage, firewall métier) sous la responsabilité de l’exploitant local.
Surfaces d’administration RouterOS
Comprendre les canaux disponibles évite les mauvaises architectures (par exemple un Winbox publié « temporairement » qui reste ouvert des mois).
Winbox et WebFig
Idéals pour le diagnostic interactif et la configuration fine. Peu adaptés seuls à la supervision 24/7 ou à l’inventaire multi-sites : pas d’historique central, pas d’alerte native globale, dépendance à la disponibilité de l’opérateur.
API et REST
Permettent lectures et écritures scriptables (ressources système, interfaces, exports). La complexité réelle est opérationnelle : rotation des secrets, timeouts, versions RouterOS hétérogènes, et limitation des droits (groupe full vs profil restreint).
SSH et scripts locaux
Utiles pour des actions ponctuelles ou des jobs planifiés sur la box. Sans orchestration centrale, on multiplie les variantes de scripts et on perd la visibilité sur les échecs silencieux.
Passer de un routeur à un parc
Sur un seul site, la mémoire humaine suffit : on sait quelle version tourne, où est le dernier backup, qui a touché le firewall. À partir de quelques sites, cette mémoire devient un risque.
Les écarts typiques : NTP désactivé sur un boîtier, backup jamais exporté hors flash, API user avec mot de passe faible partagé, ports d’admin exposés « le temps d’un dépannage ». Un contrôleur RouterOS vise à rendre ces écarts visibles et actionnables.
- Inventaire : modèle, serial, architecture, version ROS
- Disponibilité : online / offline, dernière vue
- Capacité : CPU, mémoire, uptime
- Sauvegarde : dernière copie hors équipement
- Accès : sessions d’admin limitées dans le temps
Sécurité du plan de contrôle
Le plan de contrôle (comment on administre) doit être plus strict que le plan de données. Exposer durablement Winbox ou l’API sur une IP publique, même filtré par pays, reste un anti-pattern : scans, force brute, 0-day éventuels.
Les architectures saines privilégient un tunnel sortant initié par le routeur (VPN type WireGuard, ou équivalent), des comptes API dédiés, et des sessions d’administration révocables plutôt qu’un accès permanent.
Secrets et comptes
Séparez le compte d’exploitation « humain » du compte machine utilisé par le contrôleur. Évitez le partage du même mot de passe full sur tout le parc.
Journalisation
Qui a ouvert une session, sur quel équipement, à quelle heure : indispensable en multi-opérateur ou multi-client. Sans journal, le post-incident reste de la spéculation.
Backups RouterOS hors de la box
Un fichier `.backup` ou un export uniquement stocké sur le routeur ne protège ni du vol matériel, ni d’une mauvaise manip qui corrompt le flash, ni d’un RMA.
Le contrôle de RouterOS inclut donc une politique de copie externe : fréquence, rétention, test de restore périodique. L’export texte (.rsc) facilite le diff ; le backup binaire accélère un restore à l’identique — les deux ont leur place.
Métriques et santé au-delà du ping
Le simple ping WAN ne dit pas si le CPU sature, si la mémoire file, ou si une interface critique flap. RouterOS expose ressources et compteurs ; encore faut-il les collecter, les historiser et les alerter avec des seuils utiles.
Une bonne pratique consiste à corréler offline tunnel, absence de métriques récentes, et jobs de backup manquants — plutôt que d’inonder d’alertes unitaires.
Limites d’une approche 100 % scripts maison
Beaucoup d’équipes commencent par un cron + API. Cela fonctionne jusqu’au moment où il faut une UI multi-utilisateur, des droits fins, une app mobile, une file d’attente robuste et un support des versions RouterOS divergentes.
Le coût caché n’est pas le premier script : c’est la maintenance sur 24–36 mois. Un contrôleur dédié externalise cette couche tout en laissant la config métier sur RouterOS.
Routiv comme couche de contrôle RouterOS
Routiv s’adresse aux parcs MikroTik qui ont besoin de cette couche sans construire un produit interne : enrôlement, monitoring, backups, alertes, accès Winbox/WebFig en sessions contrôlées, outils de diagnostic — via un tunnel sortant, sans port d’admin exposé chez le client.
Pour valider l’approche : enrôlez un routeur de lab, vérifiez inventaire et backup, simulez un offline, puis comparez le temps de diagnostic à votre méthode actuelle.
FAQ
Qu’est-ce qu’un contrôleur RouterOS ?+
Une couche d’exploitation qui centralise inventaire, supervision, backups et accès d’administration sur des équipements RouterOS, au-delà de la configuration unitaire.
Faut-il ouvrir le port API ou Winbox sur Internet ?+
Non. Préférez un accès sortant (VPN/tunnel) et des sessions temporaires. Les ports d’admin publics restent une surface d’attaque.
API binaire ou REST ?+
Cela dépend de la version RouterOS et de votre stack. L’important est la stabilité des jobs (auth, timeouts, droits) plus que le protocole seul.
Winbox suffit-il pour contrôler RouterOS ?+
Pour un équipement, oui. Pour un parc (alertes, backups hors site, inventaire), non.
Comment gérer RouterOS v6 et v7 ensemble ?+
En testant chaque brique (métriques, backup, accès) sur un pilote de chaque branche avant généralisation.
Que mettre dans un backup externalisé ?+
Au minimum une sauvegarde restaurable et, si possible, un export pour audit/diff, avec rétention définie.
Le contrôleur remplace-t-il le firewall du client ?+
Non. Il administre et supervise. Les politiques LAN/WAN restent sur le routeur.
Par quoi commencer sur un parc existant ?+
Inventaire des versions, bascule des accès admin hors exposition publique, puis backups externalisés et alertes offline.
Qui est concerné ?+
MSP, intégrateurs multi-sites, et entreprises avec plusieurs sites RouterOS sans équipe réseau dédiée 24/7.
À lire aussi
Essai 30 jours — sans carte
Essai gratuit 30 jours