Installez le contrôleur TP-Link Omada sur CasaOS en tant que service Docker persistant et conservez ses répertoires data, work et logs. L’ancien tutoriel de 2023 reste utile sur le plan conceptuel, mais l’image mbentley/omada-controller maintenue a évolué et les déploiements actuels doivent exposer plusieurs ports TCP et UDP pour la découverte, l’adoption, la gestion et les fonctions de portail captif.
Ne considérez pas Omada comme une application web à port unique. L’interface web peut s’ouvrir correctement tandis que la découverte et l’adoption des appareils échouent parce que des ports UDP ou de gestion sont manquants.
Utilisez une image Docker Omada maintenue
L’image Docker Omada Controller actuellement disponible est activement maintenue et inclut les recommandations actuelles pour les mises à niveau.
Conservez les trois principaux chemins de données
L’image documente les volumes persistants pour :
/opt/tplink/EAPController/data/opt/tplink/EAPController/work/opt/tplink/EAPController/logs
Associez-les aux dossiers AppData de CasaOS afin que les mises à niveau n’effacent pas l’état du contrôleur.
Exposez les ports requis
Omada utilise davantage que l’interface de gestion. La documentation actuelle du conteneur inclut notamment les ports suivants :
- 8043/TCP pour la gestion HTTPS ;
- 8088/TCP pour la gestion HTTP ;
- 8843/TCP pour le portail HTTPS ;
- 27001/UDP et 29810/UDP pour la découverte ;
- 29811–29817/TCP pour la gestion des appareils dans les versions actuelles.
Ne publiez que les services nécessaires à votre déploiement, mais n’omettez pas les ports de découverte et d’adoption avant de diagnostiquer le contrôleur comme défaillant.
Le mode pont fonctionne généralement
Les appareils Omada peuvent communiquer avec un conteneur via les ports publiés de l’hôte. Vous n’avez pas automatiquement besoin du mode réseau de l’hôte ni d’une adresse macvlan dédiée.
Si la découverte des appareils échoue entre les VLAN, il s’agit d’un problème de découverte routée et de conception réseau, non d’un problème d’installation de CasaOS.
Comment l’installer en tant qu’application personnalisée CasaOS
- Créez une application Docker personnalisée.
- Utilisez la version actuelle de
mbentley/omada-controllerimage/tag. - Associez les répertoires persistants data/work/log.
- Publiez les ports TCP et UDP requis.
- Définissez une politique de redémarrage telle que
unless-stopped. - Démarrez le conteneur et ouvrez le port de gestion HTTPS.
Sauvegarder le contrôleur avant les mises à niveau majeures
Les mises à niveau du contrôleur Omada peuvent inclure des modifications de la base de données. Exportez une sauvegarde du contrôleur avant de changer de version majeure, en particulier pour les versions nécessitant des étapes de migration.
Ne pas exposer publiquement les ports de gestion
Gardez le contrôleur sur un réseau local de confiance ou un VPN privé. Utilisez le guide de déploiement Docker pour appliquer les mêmes principes de déploiement de conteneurs.
Utiliser une adresse stable pour le contrôleur
Les appareils Omada doivent continuer à trouver le contrôleur après les redémarrages. Attribuez au serveur CasaOS une adresse stable sur le réseau local au moyen d’une réservation DHCP ou d’une adresse IP statique gérée avec soin. Si l’adresse de l’hôte change, les appareils précédemment adoptés peuvent continuer à tenter de joindre l’ancienne adresse du contrôleur.
La découverte entre VLAN peut nécessiter une conception réseau supplémentaire
La découverte par diffusion locale fonctionne mieux lorsque le contrôleur et les nouveaux appareils Omada se trouvent sur le même réseau de couche 2. Si vos points d’accès et votre contrôleur sont sur des VLAN différents, la simple publication des ports Docker ne permettra peut-être pas aux diffusions de découverte de traverser le routeur.
Dans ce cas, utilisez le processus d’adoption/inform de couche 3 pris en charge par TP-Link ou configurez intentionnellement les règles de routage et de pare-feu. Ne tentez pas de résoudre un problème de routage VLAN en réinstallant le conteneur à répétition.
Vérifier la mémoire Java sur les petits hôtes CasaOS
Omada est une application Java qui peut consommer beaucoup plus de mémoire que les conteneurs DNS ou de tableau de bord légers. L’image maintenue expose des paramètres liés à la mémoire, et les déploiements aux ressources limitées doivent laisser suffisamment de RAM pour CasaOS, Docker et les autres services.
Si le conteneur redémarre sous charge, examinez les journaux et la pression sur la mémoire avant de conclure que la base de données est corrompue.
Vérifier l’adoption des appareils après chaque mise à niveau
Après une mise à jour majeure d’Omada, vérifiez que l’interface du contrôleur s’ouvre, que les appareils adoptés restent connectés et que les ports de découverte et d’adoption sont toujours publiés. Le fait qu’un conteneur soit « en cours d’exécution » ne suffit pas à prouver que le plan de gestion du réseau fonctionne correctement.
FAQ
Pourquoi puis-je ouvrir Omada alors que les appareils ne sont pas détectés ?
Le port Web peut fonctionner alors que la découverte UDP ou les ports de gestion TCP manquent. Vérifiez chaque port publié requis.
Ai-je besoin du mode host ?
Non. Le mode bridge avec les ports publiés correctement configurés convient à de nombreux déploiements.
Que dois-je sauvegarder ?
Conservez les répertoires de données, de configuration et de journaux indiqués dans la documentation, et utilisez également la sauvegarde intégrée du contrôleur Omada avant toute mise à niveau majeure.
Puis-je exposer Omada directement sur Internet ?
Évitez de le faire. Gardez l’interface de gestion derrière le réseau local ou un accès distant privé.
