Um utilizador do ZimaOS pensou que o Tailscale tinha falhado após o primeiro arranque, porque a página da aplicação apresentava «serviço indisponível» e um telemóvel não conseguia aceder aos serviços do servidor doméstico. Os diagnósticos do contentor mostraram um resultado diferente: o Tailscale estava em execução, o dispositivo estava autorizado e as montagens do estado e do túnel estavam presentes.
O problema confirmado era o endereço utilizado no telemóvel. O utilizador estava a tentar aceder a um endereço LAN doméstico normal sem configurar o encaminhamento de sub-redes. A ligação ao serviço através do endereço do Tailscale do dispositivo ZimaOS 100.x.x.x o endereço funcionava.
O contentor do Tailscale não tinha falhado
O sintoma inicial sugeria que o contentor tinha parado após um reinício, mas o estado recolhido mostrou:
- O estado do contentor era «em execução», com código de saída 0.
- O Tailscale passou de «A iniciar» para «Em execução».
- A máquina estava autorizada na tailnet do utilizador.
- O diretório de estado persistente estava mapeado para o contentor.
- O dispositivo TUN necessário ao Tailscale também estava mapeado.
- O dispositivo recebeu um endereço IPv4 do Tailscale e conseguia ver os pares.
Esta evidência distinguiu uma mensagem da página da aplicação ou da interface Web do ZimaOS do estado do próprio daemon do Tailscale.
Porque é que as primeiras tentativas de diagnóstico apresentaram «Permissão negada»
A sessão de terminal utilizou um utilizador normal do ZimaOS. A primeira listagem do Docker foi executada com privilégios elevados, mas os comandos posteriores tentaram aceder ao socket do Docker sem esses privilégios e, por isso, devolveram erros de permissão. As aspas curvas copiadas do fórum também impediram que algumas substituições de comandos fossem interpretadas corretamente.
Essas mensagens de permissão descreviam a sessão de diagnóstico, não uma falha do Tailscale em execução. O resultado posterior, obtido com os privilégios adequados, mostrou que o contentor estava saudável.
Um endereço da LAN doméstica não é automaticamente um endereço do Tailscale
Um endereço como 10.0.0.93 pertence à LAN doméstica. Um telemóvel ligado remotamente à mesma tailnet não obtém automaticamente uma rota para todos os endereços LAN privados.
O Tailscale atribui a cada nó o seu próprio endereço, normalmente no intervalo 100.x.x.x. A documentação oficial sobre endereços IP do Tailscale explica que estes endereços identificam dispositivos dentro da tailnet e permanecem separados dos endereços LAN normais.
O método de ligação que funcionou
O responsável pela resposta pediu ao utilizador que se ligasse à aplicação através do IP do Tailscale do nó ZimaOS e da própria porta da aplicação:
http://TAILSCALE-IP:APP-PORTPor exemplo, um serviço na porta 8096 usaria um URL com o formato:
http://100.x.x.x:8096O telemóvel também tem de ter sessão iniciada na mesma tailnet e estar ativamente ligado ao Tailscale. O utilizador confirmou que este endereço funcionava, o que demonstrou que o próprio Tailscale estava a funcionar.
Quando é necessário o encaminhamento de sub-redes
Se o objetivo for alcançar dispositivos através dos respetivos endereços LAN existentes — como 10.0.0.x—um dispositivo nessa rede tem de anunciar a sub-rede da LAN como uma rota, e a rota tem de ser aprovada de acordo com a configuração da tailnet.
Esta é uma configuração diferente do acesso direto ao anfitrião ZimaOS através do seu próprio IP Tailscale. Consulte a documentação oficial sobre routers de sub-rede do Tailscale antes de esperar que os endereços normais da LAN funcionem remotamente.
Porque poderia a página da aplicação continuar a indicar «Serviço indisponível»
Uma verificação de disponibilidade da interface Web pode falhar mesmo quando o daemon de rede está em execução. No caso de origem, a prova decisiva foi o estado em execução, a autorização bem-sucedida na tailnet, o IP Tailscale atribuído, os pares visíveis e uma ligação funcional ao serviço remoto.
Alterar aleatoriamente as portas da aplicação, eliminar o estado do Tailscale ou reinstalar repetidamente o contentor não resolveria um endereço de destino incorreto. Verifique o estado do daemon e o método de ligação antes de repor uma identidade funcional.
Porque poderia a ligação funcional parecer lenta
A resposta final sugeriu que a ligação poderia estar a utilizar um relay DERP em vez de um percurso direto ponto a ponto. O tráfego Tailscale encaminhado pode funcionar corretamente, mas proporcionar menor débito ou maior latência, dependendo das redes, dos routers e da região de relay disponível.
A lentidão, por si só, não prova que o contentor esteja a falhar. Primeiro, confirme se a ligação funciona e se o Tailscale indica um percurso direto ou encaminhado; em seguida, investigue o comportamento do NAT e da firewall se o desempenho for importante.
Uma ordem de diagnóstico mais segura
- Verifique se o contentor Tailscale está em execução, em vez de depender apenas do estado apresentado na página da aplicação.
- Confirme que o nó ZimaOS aparece como autorizado e online na mesma tailnet que o telemóvel.
- Identifique o endereço Tailscale do nó ZimaOS
100.x.x.xendereço através da interface do Tailscale ou da consola de administração. - Ligue-se ao serviço pretendido utilizando esse endereço Tailscale e a porta do serviço.
- Configure o encaminhamento de sub-rede apenas se for necessário aceder através de endereços normais da LAN doméstica.
- Investigue separadamente a utilização de um relay DERP se a ligação funcionar mas for lenta.
Perguntas frequentes sobre a ligação Tailscale do ZimaOS
A mensagem «serviço indisponível» prova que o Tailscale parou?
Não. Neste caso, o contentor estava em execução, autorizado e ligado, apesar de a página da aplicação apresentar essa mensagem.
Porque não ajudou alterar a porta da aplicação Tailscale?
O problema era o endereço de destino, não um conflito normal de portas da aplicação Web. O utilizador precisava do IP Tailscale do nó.
Que endereço deve um telemóvel remoto utilizar?
Utilize o Tailscale do nó ZimaOS 100.x.x.x endereço e a porta da aplicação, exceto se tiver sido configurado um router de sub-rede para endereços da LAN.
Porque falha um endereço 10.0.0.x através do Tailscale?
É um endereço privado da LAN doméstica. Para aceder remotamente a essa sub-rede, é necessário anunciar e aprovar uma rota de sub-rede.
Porque pode uma ligação Tailscale funcional ser lenta?
A ligação pode ser encaminhada através do DERP em vez de utilizar uma ligação direta ponto a ponto.
