Gestion d’un routeur MikroTik : le cycle d’exploitation RouterOS

Router management vs configuration réseau

La configuration réseau (routes, NAT, firewall, queues) reste du ressort de l’ingénieur dans Winbox ou au terminal. Le router management, lui, couvre tout ce qui entoure cette config : qui a le droit de se connecter, où vit le dernier export, quelle version tourne, comment on sait que le WAN est mort sans être sur site.

Beaucoup d’incidents « MikroTik down » sont en réalité des échecs de management : mot de passe perdu, pas de backup, Winbox injoignable parce que le WAN a changé d’IP, mise à jour lancée sans export. Traiter ces sujets à part évite de mélanger dépannage firewall et hygiène d’exploitation.

Sur un seul routeur critique (cabinet, entrepôt, CHR de lab), cette discipline vaut déjà le coup. Elle devient non négociable dès que la même personne gère plusieurs clients — mais l’unité de travail reste l’appareil.

Accès au routeur : Winbox, SSH, API

RouterOS offre plusieurs portes. Les mélanger sans politique est la première dette.

• Winbox (8291) : confortable, dangereux s’il est publié sur le WAN
• SSH : automatisable (backup, scripts), à restreindre à un préfixe de management
• API / REST : lecture métriques et actions bornées, idéal pour un outil
• WebFig : dépannage ponctuel, pas une surface permanente

Changer la config sans perdre le site

Toute modification firewall, route par défaut ou PPPoE peut isoler le routeur. La séquence minimale avant un changement risqué : export/backup hors équipement, fenêtre acceptée, plan de retour (safe mode RouterOS ou restore).

Safe mode dans Winbox annule les changements si la session tombe — utile en intervention interactive. Il ne remplace pas un fichier de restore stocké ailleurs. Un brick firmware ou un reset n’a que l’export externe.

• Backup cloud ou copie scp juste avant la fenêtre
• Un changement à la fois sur le chemin de management
• Vérifier le retour de session avant de fermer le ticket

Mises à jour RouterOS

check-for-updates puis install déclenche un reboot. Sur un site unique, cela veut dire : backup frais, clients prévenus, délai de boot selon le hardware (quelques secondes sur un CCR récent, nettement plus sur un petit hAP chargé).

Tester la cible de version sur un lab identique (v6 vs v7, syntaxe firewall). Le router management n’est pas « toujours la dernière stable » ; c’est « une version validée, tracée, restaurable ».

Diagnostic sans être sur place

Avant d’ouvrir Winbox, un routeur bien géré donne déjà : last-seen, CPU, RAM, compteurs WAN, éventuellement un ping depuis le routeur vers 1.1.1.1 ou la gateway LAN.

Ces signaux séparent « box ISP down », « CPU à 100 % » et « tunnel de management cassé alors que le LAN client va bien ». Sans eux, chaque ticket commence par un déplacement ou une demande de capture d’écran au non-technicien sur site.

Backup : local ne suffit pas

/system backup et /export vivent sur le routeur jusqu’à ce que le routeur meure. La gestion d’un routeur MikroTik impose une copie hors flash, nommée, datée, récupérable si l’appareil est éteint.

Fréquence : quotidienne sur un site qui change souvent, au minimum avant chaque upgrade. Un restore jamais testé n’est pas un plan de reprise.

Anti-patterns de gestion d’un MikroTik

Ils coûtent plus cher qu’un outil.

• Admin unique partagé par SMS
• Winbox sur l’IP publique « temporairement » depuis 18 mois
• Aucune copie de config hors du routeur
• Upgrade le vendredi soir sans lab
• Pas de note : le prochain intervenant redécouvre le NAT custom

Routiv comme couche de router management

Routiv n’écrit pas la config métier à votre place. Il encadre le cycle de vie : tunnel de management, fiche d’identité RouterOS, backups cloud, alertes offline, sessions Winbox/WebFig bornées, diagnostic ping.

Sur un seul routeur de prod, enrôlez-le, vérifiez le premier backup et une session d’accès, puis seulement étendez. Essai 30 jours — sans carte — sur routiv.net.