Gérer un hotspot MikroTik à distance : le guide complet
Gérer les utilisateurs, les vouchers et les profils d'un hotspot MikroTik sans être sur place : ce qu'il faut préparer côté routeur, et comment le faire sans exposer votre réseau.
Pourquoi administrer un hotspot à distance
Un hotspot MikroTik installé dans une boutique, un cybercafé ou une résidence continue de tourner même quand l'administrateur est ailleurs. Le problème n'est pas de faire fonctionner le routeur : il fonctionne. Le problème est de créer un code Wi-Fi à 21 h parce qu'un client attend, ou de vérifier qui consomme la bande passante, sans prendre la route.
RouterOS permet déjà d'administrer à distance, mais chacun de ses canaux a une contrainte : Webfig demande un navigateur sur le bon réseau, Winbox demande le port 8291, et l'API demande un client à installer. Les trois exigent surtout que le routeur soit joignable depuis l'Internet.
Étape 1 — Rendre le routeur joignable
Un routeur MikroTik n'a pas forcément d'adresse publique : derrière une box opérateur, il est souvent en double NAT. Deux solutions, dans cet ordre de simplicité.
Le DDNS gratuit de MikroTik Cloud
Dans Winbox : IP → Cloud, cochez DDNS Enabled. RouterOS vous attribue une adresse du type xxxxx.sn.mynetname.net qui suit votre IP publique, même si l'opérateur la change. C'est la méthode recommandée : rien à installer, rien à payer.
Une IP publique fixe
Si votre fournisseur vous en donne une, elle fonctionne tout aussi bien. Notez simplement qu'une IP fixe n'est pas une mesure de sécurité : elle rend le routeur trouvable, pas protégé.
Étape 2 — Activer l'API RouterOS, et seulement l'API
Dans Winbox : IP → Services. Le service api écoute sur le port 8728 (et api-ssl sur 8729). Activez-le, puis bornez son accès par adresse source dans l'onglet Available From :
- l'adresse de votre serveur de gestion, si vous utilisez une plateforme hébergée ;
- ou le réseau de votre bureau, si vous administrez depuis un poste fixe.
Laisser 0.0.0.0/0 revient à publier l'API sur Internet. Un mot de passe fort ralentit une attaque par dictionnaire, il ne l'empêche pas. Une règle /ip firewall filter limitant le port 8728 à l'adresse du serveur fait le vrai travail.
À retenir : n'ouvrez jamais 8728, 8291 et 80 à tout le monde « pour tester ». Un routeur exposé trois semaines finit dans les scans automatisés, et RouterOS a un historique de vulnérabilités exploitées en masse.
Étape 3 — Connecter le routeur à un tableau de bord
Une fois l'API joignable, un tableau de bord en ligne peut lire et écrire dans RouterOS : créer des utilisateurs hotspot, générer des vouchers, lire les profils. Sur Hotspots Online, cela se fait en quatre champs — nom, hôte (le DDNS), utilisateur et mot de passe RouterOS — puis un bouton Tester la connexion.
Les identifiants sont chiffrés sur le serveur et ne ressortent jamais dans une réponse. La procédure complète est dans la documentation.
Les erreurs les plus fréquentes
- « Connection refused » : le service
apiest désactivé, ou le port 8728 est bloqué par le pare-feu du routeur. - Délai dépassé : le DDNS n'est pas à jour, ou l'opérateur filtre les ports entrants. Vérifiez depuis un autre réseau que l'adresse répond.
- « Login failed » : l'utilisateur RouterOS n'a pas le droit
api, ou Available From exclut l'adresse du serveur. - Le routeur redémarre : trop de sessions API ouvertes à la suite. Un tableau de bord sérieux ferme ses connexions après chaque opération.
Et quand le routeur est bloqué par l'opérateur ?
Certains abonnements n'autorisent aucun port entrant : le routeur est en double NAT et aucun DDNS ne suffira. La solution propre est un tunnel sortant — WireGuard entre le routeur et un serveur que vous contrôlez, ou le tunnel intégré de la plateforme. Le routeur initie alors la connexion : aucun port entrant n'est requis.
Créer un compte Hotspots Online et connecter votre premier routeur prend quelques minutes.