O que deve verificar quando o Tailscale não consegue aceder ao seu servidor doméstico?

Quando o Tailscale não consegue alcançar o seu servidor doméstico, a falha nem sempre está dentro da rede Tailscale. O servidor pode estar offline, o nome do dispositivo pode não resolver, uma regra de acesso pode rejeitar a ligação, o firewall do sistema operativo pode bloquear o serviço, ou a aplicação pode estar a escutar apenas no localhost.

A forma mais rápida de encontrar a causa é resolver problemas por camadas. Primeiro confirme que ambos os nós Tailscale estão online. Depois teste o IP Tailscale bruto do servidor, separe a conectividade básica do nó do acesso à aplicação, e só avance para o encaminhamento de sub-rede ou resolução DERP quando os sintomas apontarem para aí.

Comece por identificar qual camada está a falhar

Um erro comum na resolução de problemas é tratar todos os tempos de espera como o mesmo problema. Um servidor doméstico que parece offline na tailnet é diferente de um servidor que responde ao ping Tailscale mas recusa uma ligação SSH ou web.

O Tailscale fornece o caminho de rede privada entre dispositivos, mas o serviço final ainda depende do sistema operativo do servidor, firewall, porta de escuta, configuração da aplicação, rede Docker e política de acesso. Corrigir a camada errada pode criar problemas adicionais sem restaurar a ligação.

Antes de alterar qualquer coisa, anote o sintoma exato. Verifique se o servidor parece online, se o seu IP Tailscale responde, se o nome MagicDNS resolve e se a porta específica da aplicação aceita uma ligação.

Confirme que ambos os nós Tailscale estão online

Comece pelos dois dispositivos envolvidos na ligação. O portátil ou telemóvel remoto deve estar ligado à tailnet, e o servidor doméstico também deve estar online com a conta, etiqueta ou identidade de dispositivo esperada.

Num servidor Linux, verifique o serviço Tailscale e execute estado do tailscaleNos sistemas de ambiente de trabalho, verifique se o cliente está ligado e não em pausa, desconectado ou à espera de autenticação. Um servidor que não conseguiu iniciar o Tailscale após um reinício não pode ser corrigido alterando o DNS ou as portas da aplicação.

Verifique também se o servidor aparece sob o nome de dispositivo e IP Tailscale esperados. Se o nó estiver offline, corrija o serviço, estado de login, comportamento de arranque do sistema ou versão do cliente antes de resolver qualquer coisa acima da camada de rede.

Use o IP Tailscale Bruto Antes de Testar um Nome de Host

Um nome de host adiciona resolução DNS ao caminho de ligação. Se começar com um nome de servidor como servidor doméstico ou dispositivo-nas, não pode imediatamente dizer se a falha vem da rede ou da resolução de nomes.

Encontre o endereço IPv4 Tailscale do servidor, normalmente na gama 100.x.x.x, e tente esse endereço diretamente. Quando rotas LAN, nós de saída ou sub-redes sobrepostas complicam o caminho, é especialmente útil testar o IP Tailscale do dispositivo antes do seu endereço LAN privado.

Se o IP bruto funciona mas o nome do host não, a conectividade básica do nó provavelmente está saudável. Passe para o MagicDNS e as configurações DNS do cliente em vez de reinstalar o Tailscale ou mudar o router.

Se o IP Funciona mas o Nome Falha, Verifique o MagicDNS

O MagicDNS permite que os dispositivos usem nomes de máquina legíveis em vez de memorizar endereços IP Tailscale. Quando funciona, um dispositivo chamado servidor doméstico pode ser alcançado através desse nome a partir de outro dispositivo no mesmo tailnet.

A funcionalidade cria nomes automáticos de dispositivos dentro do tailnet, mas a resolução bem-sucedida ainda depende do dispositivo estar ligado e do cliente aceitar a configuração DNS do tailnet. Filtros DNS locais, ferramentas de segurança empresarial, resolvedores personalizados ou registos em cache desatualizados podem interferir.

Compare o nome curto do host, o nome completo do tailnet e o IP Tailscale bruto. Se apenas os nomes falharem, verifique se o MagicDNS está ativado, se a máquina foi renomeada e se outro produto DNS está a substituir a configuração do resolvedor.

Separe a Conectividade Tailscale da Conectividade da Aplicação

Uma ligação bem-sucedida de nó para nó não prova que todos os serviços no servidor são acessíveis. Pode conseguir fazer ping ao IP Tailscale enquanto SSH, Jellyfin, um painel, SMB ou uma interface web Docker ainda estão a expirar.

Isso geralmente significa que o caminho Tailscale existe, mas a camada de aplicação está recusando ou não tem a conexão. O serviço pode estar parado, a escutar noutra porta, ligado à interface errada, bloqueado pelo firewall do servidor ou não publicado no seu contentor.

Teste o destino exato que precisa, como 100.x.x.x:22 para SSH ou http://100.x.x.x:8080 para um serviço web. Se o nó responder mas a porta não, pare de resolver problemas com MagicDNS e DERP até que o serviço do lado do servidor seja verificado.

Verifique se o Serviço Está a Escutar na Interface Correta

Uma aplicação pode funcionar normalmente no servidor doméstico e ainda assim ser inacessível a partir de qualquer outro dispositivo. Isto acontece quando o serviço escuta apenas em 127.0.0.1, que aceita ligações do próprio servidor mas não através das suas interfaces LAN ou Tailscale.

Um serviço a escutar em 0.0.0.0 aceitar tráfego IPv4 em todas as interfaces disponíveis, enquanto um serviço também pode estar explicitamente ligado ao endereço LAN do servidor ou ao endereço Tailscale. A escolha correta depende se o serviço deve ser acessível a partir da LAN, tailnet ou apenas através de um proxy reverso local.

Não altere automaticamente todos os serviços para 0.0.0.0. Confirme primeiro o caminho de acesso pretendido, depois use regras de firewall e autenticação da aplicação para limitar quem pode aceder à porta.

O Firewall do Servidor Pode Estar a Bloquear o Tráfego Tailscale

Um serviço pode funcionar através do IP LAN do servidor doméstico mas falhar através do seu IP Tailscale porque o sistema operativo trata a interface Tailscale como um caminho de rede separado. As regras LAN nem sempre se aplicam ao tráfego que chega através de tailscale0.

Sistemas Linux podem usar UFW, firewalld, iptables ou nftables. O Windows pode classificar o adaptador Tailscale de forma diferente da LAN doméstica. Firewalls de rede mais amplos também podem impedir conexões UDP diretas e forçar o tráfego a caminhos retransmitidos. A verificação relevante é se o seu firewall permite o caminho de conexão Tailscale pretendido.

Não desative o firewall inteiro como solução permanente. Permita apenas a porta do serviço necessária a partir da interface Tailscale, endereços Tailscale selecionados ou uma política tailnet apropriada. Depois teste novamente a aplicação diretamente.

Verifique as Políticas de Acesso, Concessões, Etiquetas e Identidade do Dispositivo

Se um dispositivo Tailscale consegue aceder ao servidor doméstico enquanto outro não, a diferença pode ser uma política intencional e não uma falha de rede. O acesso pode depender do utilizador, dispositivo de origem, etiqueta de destino, protocolo e porta.

Um servidor etiquetado para acesso à infraestrutura pode não aceitar tráfego de um dispositivo pessoal, a menos que a política permita essa combinação. Uma regra que permite SSH não permite necessariamente o painel web numa porta diferente, e um dispositivo partilhado pode ter permissões diferentes de um dispositivo pertencente ao mesmo utilizador.

Revise a identidade da origem, a identidade do destino, as etiquetas do servidor e a porta solicitada em conjunto. Uma regra ampla temporária pode ajudar a isolar um problema de política, mas deve ser substituída pela regra correta mais restrita após os testes.

Um Servidor Doméstico Direto Não Precisa de um Router de Sub-rede

Se o Tailscale estiver instalado diretamente no servidor doméstico, use o próprio IP Tailscale do servidor ou o nome MagicDNS. Um router de sub-rede não é necessário para aceder a essa máquina.

Os routers de sub-rede resolvem um problema diferente: fornecem acesso a dispositivos que não executam o Tailscale, como uma impressora, câmara, NAS antigo, dispositivo doméstico inteligente ou outra máquina na LAN doméstica.

Adicionar encaminhamento de sub-rede a um problema simples de nó direto cria mais pontos onde a ligação pode falhar. Primeiro, prove que o cliente Tailscale no servidor doméstico é acessível. Só resolva problemas das rotas LAN anunciadas quando o destino real estiver atrás desse servidor.

O encaminhamento de sub-rede requer uma cadeia de encaminhamento completa

Quando o destino é um dispositivo LAN sem Tailscale, o router de sub-rede tem de fazer mais do que parecer online. Tem de receber tráfego do tailnet, encaminhá-lo para a LAN doméstica e permitir que a resposta regresse.

Uma configuração funcional normalmente requer encaminhamento de IP no dispositivo de encaminhamento, rotas de sub-rede anunciadas, aprovação da rota, controlos de acesso correspondentes e aceitação da rota no lado do cliente quando necessário. O objetivo é anunciar uma sub-rede privada através de um gateway para que os dispositivos tailnet possam alcançar máquinas que não executam o cliente.

Se a rota for visível mas o tráfego falhar, verifique cada etapa separadamente. Confirme que a sub-rede correta foi anunciada, verifique se foi aprovada, inspecione o firewall de encaminhamento e certifique-se de que o dispositivo da LAN tem um caminho de retorno válido.

Sub-redes privadas sobrepostas podem enviar o tráfego na direção errada

Muitas redes domésticas, de escritório e de hotel reutilizam endereços como 192.168.1.0/24. Se o seu Wi-Fi atual e a sua sub-rede doméstica usarem o mesmo intervalo, o sistema operativo pode tratar o destino como local em vez de o enviar através do Tailscale.

Isto cria um sintoma confuso: o IP Tailscale direto do servidor funciona, mas o seu IP da LAN doméstica não. O pedido pode estar a ir para a rede atual em vez do router da sub-rede remota.

Use o IP Tailscale do destino sempre que possível. Se for necessário acesso à sub-rede, considere alterar uma LAN para um intervalo privado menos comum ou aplicar um design de encaminhamento que lide deliberadamente com as redes sobrepostas.

Um Nó de Saída Pode Alterar o Acesso à LAN Atual

Se o dispositivo cliente estiver a usar um nó de saída Tailscale, a sua seleção de rota difere de uma conexão tailnet normal. O acesso a dispositivos LAN próximos pode ser bloqueado a menos que o acesso à rede local seja explicitamente permitido.

Isto é importante ao resolver problemas a partir de um portátil ligado a Wi-Fi de hotel, escritório ou casa enquanto também usa um nó de saída. Uma falha em alcançar um endereço LAN privado pode vir do comportamento do nó de saída em vez do servidor doméstico.

Teste sem o nó de saída, ou ative o acesso LAN apenas quando confiar na rede local. Não ative o acesso local amplo automaticamente em Wi-Fi público desconhecido.

O Docker Adiciona Outra Fronteira de Porta e Interface

Um serviço do host como SSH pode funcionar através do Tailscale enquanto uma aplicação Docker no mesmo servidor falha. Isso geralmente aponta para a rede do contentor em vez da conectividade do nó.

Verifique se o contentor está a funcionar, se a aplicação está a escutar dentro do contentor e se a sua porta está publicada para o host. Um mapeamento Compose como 8080:80 expõe a porta 80 do contentor através da porta 8080 do host, enquanto uma porta ligada apenas a 127.0.0.1 pode permanecer inacessível através do IP do Tailscale.

Verifique também rotas de proxy reverso, rede do host, regras de firewall do Docker e se a própria aplicação permite conexões de endereços fora da LAN. Teste a porta do host diretamente antes de depurar domínios ou certificados de nível superior.

DERP Geralmente Explica Lentidão Mais do Que Falha Completa

O Tailscale tenta criar conexões diretas entre dispositivos. Quando o comportamento do NAT ou restrições do firewall impedem isso, pode usar um caminho de retransmissão em vez disso.

DERP fornece um fallback de retransmissão encriptada quando a conectividade direta falha. A retransmissão encaminha tráfego já encriptado e pode conectar dispositivos através de combinações difíceis de IPv4, IPv6, NAT e firewall.

Um caminho DERP muitas vezes funciona com mais latência ou menor largura de banda, por isso é um forte suspeito quando o SSH parece lento ou as transferências de ficheiros são lentas. Se a conexão não funcionar de todo, verifique primeiro o estado do nó, a política de acesso, o firewall local, a porta da aplicação e o endereço de ligação.

Use Diagnóstico de Conexão Antes de Alterar o Roteador

Comandos como tailscale ping ajuda a separar um caminho de nó de um caminho de aplicação. Um resultado bem-sucedido prova mais do que uma aba do navegador falhada porque testa a conectividade sem depender da porta, proxy ou certificado da aplicação.

tailscale netcheck pode ajudar a mostrar a disponibilidade UDP, comportamento NAT, conectividade IPv4 ou IPv6 e regiões de retransmissão próximas. Estes resultados são mais úteis quando a ligação funciona apenas através de um retransmissor ou muda entre redes.

Não comece por adicionar encaminhamento de porta pública ao router doméstico. O Tailscale foi concebido para funcionar sem expor diretamente as portas da aplicação do servidor doméstico à internet. As alterações no router devem responder a um problema de caminho confirmado, não substituir os passos de diagnóstico anteriores.

Reinicie e Atualize Apenas Depois de Saber Qual a Camada com Falha

Reiniciar o Tailscale pode restaurar um daemon falhado ou estado de cliente obsoleto, mas reinícios repetidos não são um diagnóstico. Se a mesma falha regressar após cada reinício, o problema subjacente é provavelmente a configuração de arranque, política de firewall, encaminhamento ou ligação da aplicação.

Confirme que o servidor doméstico inicia o Tailscale sem um login interativo no ambiente de trabalho e permanece ligado após o reinício. Compare também as versões dos clientes se um dispositivo se comportar de forma diferente do resto da tailnet.

Após uma atualização ou reinício, repita os mesmos testes na mesma ordem: estado do nó, IP direto, nome de anfitrião, ping Tailscale e porta da aplicação. Uma sequência de testes consistente mostra qual camada realmente mudou.

Siga Uma Ordem de Resolução de Problemas

O caminho mais rápido é mover-se do nó Tailscale em direção à aplicação. Não modifique DNS, rotas de sub-rede, regras de firewall e rede Docker ao mesmo tempo.

Primeiro confirme que ambos os nós estão online. Depois teste o IP Tailscale direto, seguido do nome MagicDNS. Teste o caminho do nó, depois a porta da aplicação. Só após essas verificações deve investigar o firewall do servidor, o endereço de ligação, a política de acesso, o mapeamento Docker ou o encaminhamento de sub-rede.

Esta ordem evita que um serviço parado simples se transforme num projeto de encaminhamento complicado. Cada teste deve responder a uma pergunta antes de passar para a camada seguinte.

Conclusão Final

Quando o Tailscale não consegue aceder ao seu servidor doméstico, comece pela distinção mais simples: podem os dois nós Tailscale comunicar, e a aplicação pode aceitar tráfego? Confirme que ambos os nós estão online, teste o IP Tailscale direto e depois teste o nome MagicDNS e a porta exata do serviço.

Se o caminho do nó funcionar mas a aplicação não, concentre-se no firewall do servidor, interface de escuta, definições da aplicação, mapeamento de portas Docker e política de acesso. Se o destino não executar Tailscale, avance para a configuração do router de sub-rede, aprovação de rotas, encaminhamento de IP e verificação de sub-redes sobrepostas.

Os caminhos de retransmissão DERP geralmente explicam um desempenho mais lento em vez de uma falha completa. Um teste consistente camada a camada é mais eficaz do que reinstalar o Tailscale, desativar o firewall ou adicionar encaminhamento de porta pública sem saber onde a ligação falha.

FAQ

Por que consigo fazer ping ao meu servidor Tailscale mas não abrir a sua interface web?

A ligação nó a nó está a funcionar, mas o serviço web pode estar parado, a escutar noutra porta, ligado apenas ao localhost, bloqueado pelo firewall do servidor ou não publicado a partir do seu contentor Docker.

Por que o IP Tailscale funciona mas o nome do servidor não?

Isto indica um problema com o MagicDNS ou outra configuração DNS. Verifique se o MagicDNS está ativado, se o nome da máquina mudou e se outro resolvedor DNS está a substituir as definições do Tailscale.

Preciso de um router de sub-rede para aceder ao meu servidor doméstico?

Não quando o Tailscale está instalado diretamente nesse servidor. Use o seu IP Tailscale ou nome MagicDNS. É necessário um router de sub-rede para aceder a outros dispositivos LAN que não executam Tailscale.

Um firewall pode bloquear o Tailscale mesmo quando o nó está online?

Sim. O cliente Tailscale pode ligar-se à tailnet enquanto o firewall do sistema operativo ainda bloqueia SSH, web, SMB ou outra porta de aplicação que chega através da interface Tailscale.

Uma ligação DERP significa que o Tailscale está avariado?

Não. DERP é uma solução encriptada de recurso quando não é possível estabelecer uma ligação direta. Pode adicionar latência ou reduzir a largura de banda, mas ainda assim fornece conectividade entre os dispositivos.

Por que consigo aceder ao servidor mas não a outro dispositivo na minha LAN doméstica?

O servidor é um nó Tailscale direto, enquanto o outro dispositivo precisa de um router de sub-rede. Verifique o encaminhamento de IP, rotas anunciadas, aprovação de rotas, regras de acesso e o caminho de retorno do dispositivo LAN.

Sub-redes domésticas e remotas sobrepostas podem impedir o acesso ao Tailscale?

Sim. Se ambos os locais usarem a mesma sub-rede privada, o cliente pode enviar tráfego para a sua LAN atual em vez da rota da sub-rede remota. Prefira o IP Tailscale do destino ou altere o intervalo de endereços de uma das redes.

Devo abrir portas no meu router para corrigir o Tailscale?

Normalmente não. Primeiro confirme o estado do nó, o comportamento do firewall, a ligação da aplicação, a política de acesso e se a ligação é direta ou retransmitida. Encaminhar publicamente a porta da aplicação não substitui a identificação da falha real do Tailscale.