Um host Tailscale inacessível: router de sub-rede ou nó de saída?

Um host Tailscale responde enquanto outro fica às escuras, ou tudo funciona até os sites públicos começarem a reportar o país errado. As duas queixas chegam como «o Tailscale está quebrado», e as duas são normalmente a construção errada ativada para o destino errado. Um router de sub-rede expõe uma rede privada à tailnet, enquanto um nó de saída muda de onde sai o tráfego de internet. Ordena primeiro o destino que falha e depois escolhe o papel que o cobre.

Começa pelo destino que falhou

Anota o endereço ou o nome que não funcionou e que tipo de coisa é. Um dispositivo numa LAN privada atrás de outro local, um serviço no teu próprio segmento e um site público são três problemas de encaminhamento que partilham um único cliente por acaso. A distinção não é cosmética, porque as duas construções cobrem conjuntos diferentes de destinos. Ativar uma não faz nada pela outra, e é essa toda a fonte da confusão.

Repara também na família de endereços. Uma sub-rede anunciada apenas como IPv4 deixa os destinos IPv6 no caminho local, o que se lê como uma falha parcial até alguém comparar as duas tabelas de encaminhamento. Anota que caminho esperavas, para que o teste posterior tenha algo a contradizer.

Chega a um dispositivo que nunca executa Tailscale

O router anuncia intervalos específicos à tailnet e depois reencaminha pacotes entre a tailnet e o segmento privado, pelo que os dispositivos desse segmento não precisam do seu próprio cliente. Chegar a um NAS do escritório a partir de um portátil em casa é exatamente este caso. O router é o único membro da tailnet desse lado.

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

O anúncio é apenas a primeira de três condições. A rota tem de ser aprovada para a tailnet, o cliente tem de aceitar as rotas anunciadas, e uma regra de acesso tem de permitir a ligação. É essa cadeia que faz com que o sintoma seja tantas vezes o router estar ativo e o NAS não. Um router acessível prova que o túnel funciona; não prova nada sobre aprovação, aceitação do cliente ou política.

Cada uma dessas três falhas parece diferente na consola de administração. Verifica-as por ordem em vez de mudar as três ao mesmo tempo, porque uma segunda alteração esconde qual era a que importava.

Faz sair o tráfego público por outra máquina

Um nó de saída encaminha o teu tráfego geral de internet através de si mesmo, que é o equivalente mais próximo do túnel completo de outros produtos VPN. Também precisa de três consentimentos separados: o dispositivo anuncia o papel, um administrador permite-o e o cliente seleciona-o. Entrar numa tailnet não envia nada por outro membro por predefinição.

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

Selecionar um nó de saída não concede automaticamente acesso à sua própria LAN. A opção de acesso à LAN existe precisamente porque são permissões diferentes, e deixá-la desligada é a predefinição mais segura. As rotas para outros recursos Tailscale mantêm o seu próprio tratamento mesmo enquanto um nó de saída está ativo. É por isso que um serviço alojado numa sub-rede pode continuar a funcionar enquanto o caminho público de internet mudou.

Um nó de saída também muda a forma como a internet te vê, não só a rapidez com que parece ir. Espera que a geolocalização, os catálogos de streaming e os limites de velocidade sigam o endereço da saída e não o teu.

Lê a divisão em três quando só falha um host

Uma impressora no teu segmento, um NAS atrás de um router de sub-rede remoto e um site público são três destinos com três caminhos diferentes. Se falhar exatamente um deles, o defeito pertence ao caminho desse destino e não ao cliente como um todo. Para a impressora local enquanto um nó de saída está em uso, a definição de acesso à LAN é a resposta habitual. Para o NAS remoto, verifica o intervalo anunciado, o seu estado de aprovação e as regras de acesso nessa ordem. Para um site público, verifica qual nó de saída está selecionado e se o cliente realmente o aceitou.

Se o endereço funciona e o nome não, para de olhar para as rotas. O DNS privado configura-se em separado, e um nome que resolve para o endereço errado falha de uma forma que parece idêntica a uma rota bloqueada. Testa primeiro o endereço e depois o nome, e os dois resultados dizem-te que camada abrir.

Confirma o caminho que achas que construíste

A verificação é uma consulta de rota mais uma verificação de endereço, não um ping. A consulta diz que interface um destino usaria, e a verificação de endereço diz em que intervalo o destino vive realmente. Um ping bem-sucedido diz que o host está vivo em algum lugar, o que não é a pergunta. Executa ambos antes de alterar qualquer configuração.

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

Combina isso com a vista da própria tailnet, que mostra se o par está ligado diretamente ou retransmitido. Um caminho retransmitido continua a funcionar, e isso explica queixas de latência que não têm nada a ver com a rota que estavas a depurar. a documentação do router de sub-rede cobre o passo de aprovação se não te for familiar. Depois anota que construção cobre que destino na tua própria rede, porque a próxima pessoa que acrescentar um local fará a mesma pergunta.