O erro fundamental neste tópico de setembro de 2025 foi interpretar modprobe tun falha como prova de que o ZimaOS não tinha qualquer suporte para TUN. Zima-Jerry corrigiu essa suposição: na compilação de origem, o TUN estava compilado diretamente no kernel, pelo que não existia nenhum tun.ko ficheiro em /lib/modules para modprobe para carregar.
No entanto, o fluxo de trabalho específico do utilizador com um contentor Docker como encaminhador de sub-redes continuava a precisar do comportamento de dispositivo/módulo esperado pelo Tailscale. Por isso, a IceWhale alterou o empacotamento no ZimaOS 1.5.0, para que o TUN passasse a ser um módulo do kernel carregável. O autor original voltou a testar a 29 de setembro e respondeu que já estava a funcionar.
O Utilizador Pretendia um Encaminhador de Sub-redes Tailscale Entre Locais
O design original ligava duas localizações físicas, o México e o Uruguai, e pretendia que os dispositivos locais em cada local comunicassem através do Tailscale sem instalar o Tailscale em todos os terminais.
Esse é um caso de utilização de encaminhador de sub-redes, não apenas de “acesso remoto ao painel do ZimaOS”. Um encaminhador de sub-redes tem de encaminhar pacotes entre a tailnet e outra sub-rede IP.
O modprobe Não Indicou Nenhum Ficheiro de Módulo tun
O utilizador executou um contentor Tailscale privilegiado e viu:
modprobe: FATAL: Module tun not found in directory /lib/modules/6.12.25Também não encontraram tun.ko ficheiro e não encontrou nenhuma entrada TUN no resultado das verificações de listagem de módulos.
A IceWhale Disse que o TUN Estava Compilado Diretamente no Kernel
A primeira resposta oficial de Zima-Jerry foi explícita: a funcionalidade TUN estava compilada diretamente no kernel, pelo que não apareceria como um ficheiro de módulo normal em /lib/modules/6.12.25.
Esta é uma distinção do kernel Linux: uma funcionalidade configurada como integrada está presente sem aparecer em lsmod ou ser carregável através de modprobe.
O Suporte Integrado Não Resolveu Totalmente o Fluxo de Trabalho do Contentor de Origem
O autor original respondeu que o contentor continuava a entrar no modo de espaço de utilizador e não conseguia fornecer o comportamento completo de encaminhador de sub-redes no anfitrião que pretendia. Perguntou especificamente se o TUN poderia ser exposto de forma modular.
Zima-Jerry afirmou que isto poderia ser ajustado na versão seguinte.
O ZimaOS 1.5.0 Alterou o TUN para um Módulo Carregável
A 28 de setembro, Zima-Jerry publicou que, na nova versão 1.5.0, tun.ko tinha passado a ser um módulo do kernel e pediu ao utilizador que testasse novamente.
O autor original respondeu no dia seguinte: “Obrigado, agora está a funcionar.”
Essa é uma correção confirmada pela fonte e a conclusão mais importante do tópico.
A Rede do Tailscale em Espaço de Utilizador é um Modo de Funcionamento Diferente
A documentação atual do Tailscale explica que os contentores podem funcionar sem um dispositivo TUN através da utilização de redes em espaço de utilizador. Nesse modo, tailscaled funciona através de uma pilha/proxy de rede no espaço do utilizador, em vez de se comportar como uma interface de túnel Linux normal.
Utilize o modelo atual de redes de espaço do utilizador do Tailscale ao decidir se o TUN do kernel é realmente necessário.
O Tailscale atual pode encaminhar sub-redes em modo de kernel ou de espaço do utilizador
A documentação atual do Tailscale descreve agora tanto o encaminhamento de sub-redes em modo de kernel como em modo de espaço do utilizador/netstack. O modo de kernel no Linux preserva o comportamento normal de encaminhamento de pacotes e, geralmente, oferece melhor desempenho; o modo de espaço do utilizador também pode encaminhar tráfego, mas termina e reorigina o tráfego suportado na sua própria pilha de rede.
No Docker, o Tailscale atual também documenta que TS_USERSPACE está ativado por predefinição, enquanto o modo de kernel requer /dev/net/tun e as capacidades necessárias.
Um dispositivo TUN funcional não é toda a configuração de um router de sub-rede
Um router de sub-rede Linux também precisa de reencaminhamento de IP, rotas divulgadas, aprovação das rotas na consola de administração do Tailscale e regras de acesso adequadas à tailnet. Um contentor que crie com êxito tailscale0 por si só não significa que os dispositivos LAN remotos possam encaminhar tráfego através dele.
Siga o fluxo de trabalho atual do Tailscale para routers de sub-rede depois de a camada do kernel/dispositivo do ZimaOS estar a funcionar.
Não aplique o diagnóstico “tun.ko em falta” da versão 1.4.x ao ZimaOS atual
O próprio código-fonte documenta o limite entre versões: o ficheiro estava ausente devido à forma como o kernel 1.4.x foi compilado, e o ZimaOS 1.5.0 alterou a funcionalidade TUN para um módulo. O ZimaOS atual já evoluiu muito para além dessa versão.
Perante uma falha atual, verifique as definições atuais do contentor, a disponibilidade do dispositivo TUN, o modo de espaço do utilizador/kernel, o reencaminhamento de IP e a aprovação das rotas, em vez de presumir que o problema de empacotamento do kernel de 2025 voltou.
FAQ do Tailscale sobre TUN
A falha do modprobe tun provava que o ZimaOS não tinha suporte para TUN?
Não. A IceWhale disse que o TUN foi compilado diretamente no kernel de origem, em vez de ser disponibilizado como um módulo separado.
O que mudou no ZimaOS 1.5.0?
O Zima-Jerry disse tun.ko passou a ser um módulo do kernel que pode ser carregado.
O autor da publicação original confirmou que a nova versão funcionava?
Sim. Voltaram a testar depois da alteração na versão 1.5.0 e disseram que estava a funcionar.
