Um contentor VPN pode ligar-se a uma rede remota enquanto o anfitrião ZimaOS permanece completamente alheio a essa rota. Esse era o problema descrito no tópico original de setembro de 2025. O contentor Tailscale do utilizador entrou com sucesso na tailnet, mas o próprio ZimaOS — e, consequentemente, a aplicação Ficheiros e o fluxo de montagem SMB no anfitrião — não conseguia aceder ao servidor CasaOS remoto através do espaço de nomes de rede do contentor.
O utilizador resolveu o problema prático das cópias de segurança alterando a arquitetura, em vez de tentar transformar o contentor Tailscale numa VPN do anfitrião. Adicionou o servidor CasaOS remoto à rede ZeroTier associada ao ZimaOS e relatou que o acesso SMB passou a funcionar bem.
A topologia original tinha dois servidores remotos
A configuração de origem era:
- ZimaBlade a executar ZimaOS como máquina de origem;
- servidor remoto a executar CasaOS como destino da cópia de segurança SMB;
- Tailscale a ligar ambos os locais.
Quando ambas as máquinas executavam anteriormente CasaOS, o utilizador tinha instalado o Tailscale diretamente nos anfitriões e montado normalmente a partilha SMB remota.
O contentor Tailscale entrou na tailnet, mas o ZimaOS não
No ZimaOS, o utilizador executou o Tailscale no Docker. Isso criou conectividade para o próprio contentor Tailscale. No entanto, não adicionou automaticamente rotas ou endereços Tailscale ao espaço de nomes de rede do anfitrião ZimaOS.
Por isso, a aplicação Ficheiros não podia simplesmente procurar um servidor SMB que só estava acessível a partir do interior do contentor Tailscale.
Este é um limite do espaço de nomes de rede, não um problema de palavra-passe SMB
Normalmente, um contentor Docker tem as suas próprias interfaces, rotas e contexto de firewall. Mesmo que o contentor consiga efetuar ping para um endereço remoto da tailnet, as aplicações do anfitrião não herdam essas rotas, a menos que a VPN tenha sido deliberadamente integrada com a rede do anfitrião, com encaminhamento ou com uma arquitetura baseada em proxy.
Alterar as credenciais SMB não resolveria a ausência dessa rota.
O utilizador mudou o servidor CasaOS remoto para ZeroTier
Depois de investigar mais, o autor original instalou o ZeroTier no servidor CasaOS remoto e adicionou-o à rede virtual utilizada pelo ZimaOS. Em seguida, afirmou que o servidor remoto conseguia aceder à partilha SMB e que a solução funcionava bem.
O comando de instalação exato apresentado no fórum era uma orientação comunitária fornecida por um utilizador. A arquitetura reutilizável é mais importante do que copiar esse script de instalação de uma linha.
O acesso remoto atual do ZimaOS baseia-se numa rede virtual ZeroTier
A documentação atual da IceWhale descreve o ID de Rede do Início de sessão remoto do ZimaOS como uma identidade de rede ZeroTier. O ZimaClient utiliza esta rede virtual para estabelecer conectividade remota encriptada.
Isso faz com que a solução do utilizador original pareça menos um recurso improvisado do que poderia parecer: em vez de tentar exportar uma rota Docker do Tailscale para o anfitrião, o NAS remoto entra na rede virtual que o ZimaOS já utiliza ao nível do anfitrião.
A IceWhale documenta agora o mesmo padrão com outras plataformas NAS
A documentação atual do ZimaOS sobre sincronização com QNAP indica aos utilizadores que devem obter o ID de Rede do ZimaOS, instalar o ZeroTier no lado do QNAP e aderir a esse ID antes de criar uma tarefa de sincronização entre redes.
Utilize o padrão atual de rede ZeroTier entre NAS como referência de arquitetura suportada.
Uma opção Tailscale ao nível do anfitrião é uma solução diferente
Projetos comunitários posteriores disponibilizaram o Tailscale como um systemd-sysext nativo do ZimaOS, especificamente para fornecer ao anfitrião uma interface TUN real e permitir o encaminhamento ao nível do anfitrião. Isso pode resolver a limitação original do espaço de nomes, mas trata-se de software comunitário e não de uma funcionalidade Tailscale oficial do ZimaOS.
Se o objetivo for apenas efetuar cópias de segurança SMB remotas, adicionar o servidor remoto à rede virtual existente do ZimaOS poderá ser mais simples do que instalar uma nova extensão VPN ao nível do anfitrião.
A acessibilidade ao nível do anfitrião tem de existir antes de os Ficheiros poderem montar SMB
Independentemente da rede sobreposta escolhida, o anfitrião ZimaOS tem de conseguir encaminhar tráfego para o endereço do servidor SMB remoto. Só depois é que o nome da partilha SMB, o nome de utilizador, a palavra-passe e as permissões passam a ser a camada seguinte de resolução de problemas.
Considere o destino SMB remoto como parte do perímetro de segurança da cópia de segurança
Uma partilha de cópia de segurança acessível através de uma rede sobreposta deve continuar a exigir autenticação e expor apenas as pastas necessárias ao fluxo de cópia de segurança. Evite tornar todo o servidor remoto gravável apenas porque o tráfego está encriptado.
Perguntas frequentes sobre SMB remoto através de redes sobrepostas
Porque é que o contentor Tailscale conseguia aceder ao servidor remoto, mas os Ficheiros do ZimaOS não?
O contentor tinha o seu próprio espaço de nomes de rede e as suas próprias rotas; o anfitrião ZimaOS não as herdava automaticamente.
O que utilizou o autor original em alternativa?
Adicionou o servidor CasaOS remoto à rede ZeroTier utilizada pelo ZimaOS e relatou que funcionava bem.
O ZimaOS atual utiliza ZeroTier para redes remotas?
A documentação atual da IceWhale descreve o ID de Rede do Início de sessão remoto e os fluxos de trabalho entre NAS utilizando redes virtuais baseadas em ZeroTier.
