The normal Tailscale Docker app is convenient, but a containerized VPN does not always behave like Tailscale installed directly on a Linux host. The source author wanted a first-class host daemon with a real TUN device so ZimaOS itself could act as a subnet router or exit node and mount resources reachable through the tailnet.
A aplicação Docker normal do Tailscale é conveniente, mas uma VPN em contentor nem sempre se comporta como o Tailscale instalado diretamente num anfitrião Linux. O autor da fonte pretendia um daemon de anfitrião de primeira classe com um dispositivo TUN real, para que o próprio ZimaOS pudesse atuar como encaminhador de sub-rede ou nó de saída e montar recursos acessíveis através da tailnet. Como o ZimaOS tem uma raiz só de leitura ao estilo de um dispositivo e não possui um apt install tailscale caminho, o autor empacotou o Tailscale como um systemd-sysext
extensão. Este é um projeto comunitário, não um pacote Tailscale suportado pela IceWhale, pelo que os respetivos comandos e ciclo de vida devem ser identificados como tal.
Por que executar o Tailscale no anfitrião? O autor da fonte descreveu a rede em espaço de utilizador do Docker como suficientemente boa para a conectividade normal, mas pouco prática para o encaminhamento ao nível do anfitrião. Um daemon nativo pode utilizar diretamente o dispositivo TUN do kernel e integrar-se comsystemctl
, o encaminhamento IP, as rotas de sub-rede e o comportamento do nó de saída.
Porque o systemd-sysext se adequa ao ZimaOS systemd-sysext sobrepõe ficheiros adicionais em localizações como /usr /DATA/AppData/tailscale/.
em tempo de execução, sem modificar a imagem base imutável. O autor reproduziu a estrutura Buildroot a montante do Tailscale e armazenou o estado de autenticação persistente em
O projeto fornece um script de instalação no anfitrião O fluxo de início rápido do repositório comunitário clona o projeto, executa o instalador com sudo e autentica-se comtailscale up
. Como este é código de terceiros executado como root, reveja o repositório e o histórico de versões antes da execução.
Leia o projeto sysext atual e as respetivas notas de instalação mantidas, em vez de copiar uma versão antiga do fórum.
O projeto mantém o estado do nó em armazenamento fora da extensão descartável /DATA/AppData/tailscale/. Isto permite que a identidade do Tailscale sobreviva à reconstrução ou substituição de .raw ficheiro sysext.
Foi encontrado um erro de reinício real após a versão inicial
Um utilizador comunicou que tailscaled não arrancou após o reinício. O autor do projeto reproduziu o problema e explicou a condição de corrida: multi-user.target resolveu as dependências dos serviços antes de systemd-sysext.service tinha integrado a extensão, pelo que a unidade de serviço não existia no momento em que o systemd criou o destino.
v1.0.1 adicionou um temporizador de watchdog
O autor corrigiu a condição de corrida no arranque com um pequeno temporizador e um serviço oneshot armazenados na raiz persistente em /etc/systemd/system/É executado pouco depois do arranque e inicia tailscaled assim que a sobreposição sysext está presente.
O autor da fonte comunicou que verificou a correção após um reinício real.
As definições de encaminhamento IP eram uma questão de persistência separada
A discussão também questionava se as definições sysctl do encaminhador de sub-rede sobreviviam ao reinício. O autor explicou que o ZimaOS mantém /etc através de uma sobreposição suportada por armazenamento persistente, pelo que a configuração em /etc/sysctl.d/ sobrevive e é reaplicado.
Essas definições de encaminhamento são necessárias para utilizar o encaminhamento de sub-redes ou um nó de saída, não para um cliente Tailscale comum.
A limitação do IPv6 mudou com o kernel do ZimaOS
O módulo original de maio de 2026 documentava a ausência de opções do kernel para o encaminhamento baseado em políticas IPv6 no ZimaOS 1.6.1/kernel 6.12.25, o que fazia com que o Tailscale desativasse o IPv6 encapsulado.
Até 30 de julho, o autor atualizou o tópico porque o kernel mais recente da IceWhale fornecia as capacidades IPv6 necessárias. O repositório atual do projeto verifica o funcionamento do IPv6 na tailnet no ZimaOS 1.7.0/kernel 6.18.9.
Execute novamente o instalador após as atualizações do ZimaOS
O projeto foi concebido para reconstruir o sysext a partir dos binários estáticos oficiais do Tailscale e preservar separadamente o estado de autenticação. O repositório recomenda atualmente executar novamente o instalador após uma atualização do ZimaOS.
Trate um módulo comunitário ao nível da raiz como software de sistema
Este módulo é executado diretamente no anfitrião NAS e o respetivo instalador tem privilégios elevados. Analise o código-fonte, os hashes, o comportamento das atualizações e o comportamento da desinstalação antes de o implementar num sistema que contenha dados importantes.
O projeto foi novamente verificado no ZimaOS 1.7.0
O repositório atual indica um teste completo bem-sucedido no ZimaOS 1.7.0 com o kernel 6.18.9, incluindo persistência após reinícios e IPv6 funcional na tailnet. Isto constitui uma evidência mais forte do que a publicação original de maio de 2026, desenvolvida com base no ZimaOS 1.6.1.
Docker e sysext nativo resolvem necessidades diferentes
Se apenas precisar que aplicações específicas estejam acessíveis através do Tailscale, a abordagem Docker pode ser mais simples e manter ao mínimo as alterações no anfitrião. A abordagem sysext é apelativa quando o próprio anfitrião ZimaOS precisa de montar recursos da tailnet, anunciar sub-redes da LAN ou funcionar como nó de saída.
Não substitua uma instalação Docker funcional apenas porque existe uma abordagem nativa. Escolha com base na necessidade real de encaminhamento ao nível do anfitrião.
Desinstalar e limpar completamente são operações diferentes
O projeto comunitário separa deliberadamente a remoção do sysext da eliminação do estado do Tailscale. O processo normal de desinstalação pode manter os dados persistentes do nó, enquanto uma limpeza completa também remove o diretório de estado. Esta distinção é importante se pretender reinstalar sem criar outra identidade na tailnet.
O watchdog de arranque continua a fazer parte do projeto
A documentação atual do projeto indica que o watchdog continua a ser necessário mesmo no ZimaOS 1.7.0, porque a unidade de serviço dentro do sysext pode continuar a não detetar a montagem inicial do destino do systemd. O kernel mais recente corrigiu a capacidade IPv6, não a condição de corrida na ordem de arranque do serviço sysext.
Perguntas frequentes sobre o Tailscale nativo
Este é um pacote oficial do Tailscale para IceWhale?
Não. É um projeto comunitário systemd-sysext.
Porquê utilizá-lo em vez do Docker?
O projeto destina-se à integração de TUN ao nível do anfitrião, encaminhamento de sub-redes, nós de saída e systemd normal.
O problema do arranque após o reinício foi corrigido?
O autor do projeto reproduziu o problema e lançou uma correção baseada num watchdog na versão v1.0.1.
O IPv6 continua a ter a limitação da versão 1.6.1?
O projeto indica que o kernel 6.18.9 mais recente, utilizado pelo ZimaOS 1.7.0, fornece o suporte necessário para o encaminhamento baseado em políticas IPv6.
