Solução da comunidade

Instalar o controlador TP-Link Omada no CasaOS com Docker

A 2023 CasaOS tutorial introduced TP-Link Omada Controller; current container packaging requires persistent volumes and multiple management/discovery ports.

Instale o TP-Link Omada Controller no CasaOS como um serviço Docker persistente e preserve os respetivos diretórios de dados, trabalho e registos. O tutorial antigo de 2023 continua a ser conceptualmente útil, mas a imagem mantida mbentley/omada-controller evoluiu e as implementações atuais têm de expor várias portas TCP e UDP para as funções de deteção, adoção, gestão e portal cativo.

Não trate o Omada como uma aplicação Web de porta única. A interface Web pode abrir corretamente enquanto a deteção e a adoção de dispositivos falham devido à ausência de portas UDP ou de gestão.

Utilize uma imagem Docker do Omada mantida

A atual imagem Docker do Omada Controller é ativamente mantida e inclui orientações atuais sobre atualizações.

Torne persistentes os três principais caminhos de dados

A imagem documenta volumes persistentes para:

  • /opt/tplink/EAPController/data
  • /opt/tplink/EAPController/work
  • /opt/tplink/EAPController/logs

Mapeie-as para as pastas AppData do CasaOS para que as atualizações não eliminem o estado do controlador.

Exponha as portas necessárias

O Omada utiliza mais do que a interface Web de gestão. A documentação atual do contentor inclui portas como:

  • 8043/TCP para gestão HTTPS;
  • 8088/TCP para gestão HTTP;
  • 8843/TCP para o portal HTTPS;
  • 27001/UDP e 29810/UDP para deteção;
  • 29811–29817/TCP para gestão de dispositivos nas versões atuais.

Publique apenas os serviços de que a sua implementação necessita, mas não omita as portas de deteção/adoção e depois diagnostique o controlador como avariado.

O modo Bridge normalmente funciona

Os dispositivos Omada podem comunicar com um contentor através das portas publicadas no anfitrião. Não precisa automaticamente de utilizar a rede do anfitrião nem de um endereço macvlan dedicado.

Se a deteção de dispositivos falhar entre VLANs, isso passa a ser um problema de deteção encaminhada/desenho de rede, e não um problema de instalação do CasaOS.

Como instalar como aplicação personalizada do CasaOS

  1. Crie uma aplicação Docker personalizada.
  2. Utilize a versão atual mbentley/omada-controller imagem/etiqueta.
  3. Mapeie os diretórios persistentes de dados, trabalho e registos.
  4. Publique as portas TCP e UDP necessárias.
  5. Defina uma política de reinício, como a menos que seja parado.
  6. Inicie o contentor e abra a porta de gestão HTTPS.

Faça uma cópia de segurança do controlador antes de atualizações principais

As atualizações do controlador Omada podem incluir alterações na base de dados. Exporte uma cópia de segurança do controlador antes de alterar versões principais, especialmente em versões que exijam etapas de migração.

Não exponha publicamente as portas de gestão

Mantenha o controlador numa LAN fidedigna ou numa VPN privada. Utilize o guia de implementação do Docker para aplicar os mesmos princípios de implementação de contentores.

Utilize um endereço de controlador estável

Os dispositivos Omada precisam de continuar a encontrar o controlador após reinícios. Atribua ao servidor CasaOS um endereço LAN estável através de uma reserva DHCP ou de um IP estático cuidadosamente gerido. Se o endereço do host mudar, os dispositivos anteriormente adotados podem continuar a tentar contactar o endereço antigo do controlador.

A descoberta entre VLANs pode exigir um desenho de rede adicional

A descoberta por difusão local funciona melhor quando o controlador e os novos dispositivos Omada estão na mesma rede de camada 2. Se os seus pontos de acesso e o controlador estiverem em VLANs diferentes, publicar simplesmente as portas do Docker poderá não fazer com que as difusões de descoberta atravessem o router.

Nesse caso, utilize o processo de adoção/informação de camada 3 suportado pela TP-Link ou configure intencionalmente as regras de encaminhamento/firewall. Não tente resolver um problema de encaminhamento entre VLANs reinstalando repetidamente o contentor.

Verifique a memória Java em hosts CasaOS pequenos

O Omada é uma aplicação Java e pode consumir substancialmente mais memória do que contentores leves de DNS ou de painéis. A imagem mantida disponibiliza definições relacionadas com a memória, e as implementações com recursos limitados devem reservar RAM suficiente para o CasaOS, o Docker e outros serviços.

Se o contentor reiniciar sob carga, analise os registos e a pressão sobre a memória antes de presumir que a base de dados está corrompida.

Verifique a adoção dos dispositivos após cada atualização

Após uma atualização importante do Omada, confirme que a interface do controlador abre, que os dispositivos adotados permanecem ligados e que as portas de descoberta/adoção continuam publicadas. O facto de um contentor estar “em execução” não prova, por si só, que o plano de gestão da rede esteja a funcionar corretamente.

Perguntas frequentes

Porque é que consigo abrir o Omada, mas os dispositivos não são descobertos?

A porta Web pode funcionar enquanto a descoberta UDP ou as portas de gestão TCP estão em falta. Verifique todas as portas publicadas necessárias.

Preciso do modo Host?

Não. O modo Bridge com as portas publicadas corretamente funciona em muitas implementações.

O que devo salvaguardar?

Faça a persistência dos diretórios de dados/registos de trabalho documentados e utilize também a cópia de segurança do próprio controlador Omada antes de atualizações importantes.

Posso expor o Omada diretamente à Internet?

Evite fazê-lo. Mantenha a interface de gestão atrás da LAN ou de um acesso remoto privado.