Um contentor Tailscale pode aparecer como ligado sem funcionar como router de sub-rede. Neste tópico do ZimaOS de abril de 2026, o Tailscale estava a ser executado no Docker com rede do anfitrião, modo privilegiado e /dev/net/tun montado, mas a consola de administração do Tailscale indicava que a máquina não expunha nenhuma rota. O Navidrome funcionava na rede local, mas não podia ser acedido remotamente através da tailnet.
O tópico não terminou com uma correção confirmada pelo autor original. Em vez disso, outro membro da comunidade partilhou uma configuração funcional de um contentor Tailscale BigBear que anunciava com êxito uma sub-rede LAN no seu próprio ambiente ZimaOS. Essa configuração é útil como referência para resolução de problemas, mas não constitui uma garantia suportada pela IceWhale para todos os pacotes de aplicações Tailscale.
Estar ligado ao Tailscale não significa que as rotas de sub-rede sejam anunciadas
A configuração original já tinha concluído a autenticação do dispositivo. O problema era especificamente de encaminhamento: os registos mostravam uma lista de rotas vazia e a consola de administração do Tailscale não apresentava nenhuma rota de sub-rede para aprovação.
Esta distinção é importante porque um nó Tailscale normal apenas entra na tailnet. Um router de sub-rede tem responsabilidades adicionais: deve anunciar um ou mais prefixos de LAN e cumprir os requisitos de encaminhamento do sistema operativo necessários para encaminhar tráfego entre a tailnet e essa LAN.
A documentação atual do Tailscale descreve os routers de sub-rede como gateways que anunciam redes privadas a dispositivos da tailnet. Também exige o encaminhamento de IP no Linux e a aprovação da rota na consola de administração do Tailscale, a menos que uma aprovadores automáticos a política trata automaticamente da aprovação.
Documentação do router de sub-rede do Tailscale
A referência funcional da comunidade utilizou TS_ROUTES
A resposta de TomasSzwed utilizou um contentor Tailscale BigBear e configurou a sub-rede através de variáveis de ambiente, em vez de depender de um comando manual único após o arranque. As partes importantes dessa referência incluíam:
-
network_mode: host; - modo privilegiado;
-
/dev/net/tunmontado no contentor; -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24para a LAN anunciada; -
TS_EXTRA_ARGS=--accept-routesna configuração desse utilizador; - estado persistente do Tailscale em
/var/lib/tailscale.
Utilize o prefixo LAN correto para a sua rede
O exemplo funcional anunciado 192.168.2.0/24. Esse valor só faz sentido numa LAN que utilize essa sub-rede. Outra rede doméstica poderá utilizar 192.168.1.0/24, 10.0.0.0/24, ou outro prefixo privado.
A publicidade da sub-rede errada pode produzir um nó Tailscale saudável, mas que ainda não consegue encaminhar para os serviços ZimaOS pretendidos. Determine o prefixo de rede local real antes de definir TS_ROUTES ou um equivalente --advertise-routes opção.
As rotas anunciadas ainda têm de ser ativadas
As orientações atuais do Tailscale distinguem o anúncio de rotas da aprovação de rotas. Assim que o encaminhador de sub-redes anunciar uma rota, esta tem de ser ativada na consola de administração do Tailscale, a menos que a política da tailnet a aprove automaticamente.
Se a consola de administração indicar que a máquina não expõe quaisquer rotas, comece por verificar a configuração de anúncio de rotas do contentor. Se a rota aparecer, mas o tráfego continuar a não funcionar, reveja a aprovação da rota, a política de controlo de acesso, o reencaminhamento e o próprio serviço de destino.
As redes Docker alteram o que o contentor pode encaminhar
O autor original utilizou a rede do anfitrião e montou o dispositivo TUN. A referência comunitária fez o mesmo. A documentação atual do Tailscale também suporta a execução do Tailscale em Docker, mas as redes Docker e o encaminhamento do Tailscale são camadas separadas, e ambas têm de estar configuradas corretamente.
Documentação do Tailscale para Docker
Não assuma que duas aplicações Tailscale na loja de aplicações do ZimaOS utilizam definições de contentor idênticas. O autor original reparou especificamente que o exemplo partilhado utilizava o pacote Tailscale da BigBear, enquanto a instalação existente utilizava a outra entrada do Tailscale.
O que isto significa para o Navidrome e outros serviços locais
O objetivo do tópico de origem era aceder ao Navidrome a partir de um iPhone sem reencaminhamento público de portas. Se o Navidrome já estiver acessível na LAN local, um encaminhador de sub-redes funcional pode tornar esse endereço da LAN acessível a dispositivos autorizados da tailnet.
No entanto, o tópico não confirma que o autor original tenha concluído a mudança para a configuração da BigBear ou conseguido aceder ao Navidrome posteriormente. Por isso, a página documenta uma referência comunitária viável e um modelo de diagnóstico, não uma resolução confirmada para essa instalação específica.
Perguntas frequentes sobre o encaminhamento de sub-redes do Tailscale no ZimaOS
Porque é que o Tailscale indica que está ligado, mas não mostra rotas de sub-rede?
Aderir à tailnet e anunciar uma rota da LAN são operações diferentes. No caso de origem, a autenticação foi bem-sucedida, mas a lista de rotas permaneceu vazia.
O Tailscale em Docker pode funcionar como encaminhador de sub-redes no ZimaOS?
Um membro da comunidade relatou que funcionou na sua configuração do ZimaOS e partilhou uma configuração do Tailscale da BigBear. O próprio Tailscale também suporta encaminhamento de sub-redes e implementações Docker, mas a configuração exata da aplicação no ZimaOS continua a ser importante.
Tenho de aprovar a rota no Tailscale?
De acordo com o comportamento atual do Tailscale, as rotas de sub-rede anunciadas normalmente precisam de aprovação na consola de administração, a menos que uma aprovadores automáticos a política trata delas automaticamente.
Devo copiar 192.168.2.0/24 da captura de ecrã?
Não. Utilize a sub-rede efetiva da LAN que pretende expor. O valor na captura de ecrã pertence à rede de outro membro da comunidade.
