Por que o cliente Tailscale no Linux ignora as rotas de sub-rede anunciadas

Você está num portátil Linux, tailscale status lista as outras máquinas, e o NAS em 10.80.0.25 continua esgotando o tempo. A tailnet está saudável, o roteador de sub-rede está online, e nada na saída do cliente diz por que a LAN atrás dele é inalcançável. O percurso abaixo avança desse sintoma para fora: a opção neste cliente, depois o anúncio no roteador, depois a aprovação, depois a política, e só então o destino em si. Cada porta falha com o mesmo tempo esgotado, por isso a ordem importa mais que os comandos.

O que o cliente Linux se recusa a instalar

Os clientes Tailscale no Linux não aceitam rotas de sub-rede anunciadas a menos que você peça. Sem esse ajuste o cliente entra na tailnet e alcança os endereços dos pares, enquanto cada prefixo anunciado pelo roteador fica sem uso. O padrão é deliberado, e é por isso que o sintoma parece um roteador quebrado e não uma decisão local.

Duas coisas diferentes se chamam roteamento aqui, e só uma é sua. O roteador anuncia um prefixo na tailnet; sua máquina decide se o instala. Uma falha em qualquer uma delas produz o mesmo tempo esgotado, por isso adivinhar desperdiça uma tarde. Descubra qual lado está recusando antes de editar qualquer coisa.

Ative a aceitação de rotas para esta máquina

Defina a preferência no cliente, e depois veja o que mudou em vez de supor que o comando surtiu efeito. A forma atual aplica o ajuste sem repetir o fluxo de login, o que importa quando você está no meio de uma sessão.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

O Tailscale instala as rotas aceitas na própria tabela no Linux, então um prefixo que aparece na tabela 52 é prova direta de que este cliente instalou o anúncio. Se a sua faixa não está nessa tabela, pare: o problema é local e nenhum trabalho no roteador vai mudá-lo.

Clientes mais antigos expõem a mesma preferência como opção do comando de login, então sudo tailscale up --accept-routes é a alternativa quando falta tailscale set. Use-a em vez de editar rotas à mão, porque o daemon reescreve a própria tabela e a sua edição desaparece na próxima reconexão. Confira a versão antes de copiar um comando de um artigo antigo.

Verifique o anúncio e a aprovação separadamente

No roteador de sub-rede o prefixo precisa ser anunciado, e o kernel precisa encaminhar pacotes entre interfaces. Anunciar sem encaminhar dá uma rota aprovada que descarta o tráfego em silêncio, e essa é a configuração pela metade mais comum.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Compare o prefixo anunciado com o endereço que você realmente tenta alcançar, caractere por caractere. Um roteador que anuncia 10.70.0.0/24 não diz nada sobre um NAS em 10.80.0.25, e a divergência é invisível em qualquer saída de status porque os dois números parecem igualmente plausíveis. A maioria dos relatos de rota quebrada termina aqui. Corrija o anúncio antes de tocar em qualquer coisa adiante.

A aprovação é a próxima porta, e é fácil pulá-la quando o roteador foi configurado a partir de um shell. O anúncio precisa estar habilitado para esse dispositivo no console de administração antes que outras máquinas possam usá-lo. Aceitar rotas no cliente não aprova nada e não anula nenhuma regra de acesso.

Teste o endereço privado antes do nome do host

Uma conexão bem-sucedida ao endereço tailnet do próprio roteador prova que a tailnet funciona, o que você já sabia. O teste útil é o serviço de que você realmente precisa, primeiro contra o endereço privado, para que uma falha de DNS não possa se disfarçar de falha de roteamento.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

Se o endereço responde e o nome do host não, você tem um problema de resolução de nomes e deveria parar de tratá-lo como problema de rota. Se nenhum responde, volte uma seção e confirme que o anúncio cobre o endereço. As duas falhas parecem idênticas do aplicativo e são corrigidas em lugares diferentes.

Vale a pena uma verificação local antes de culpar a tailnet. Quando a sua LAN atual usa o mesmo prefixo da sub-rede remota, o kernel prefere a rota conectada diretamente e o tráfego nunca sai da máquina; é o que acontece quando uma casa e um escritório escolhem ambos 192.168.1.0/24.

Por que uma opção do cliente não é um ajuste do roteador

São papéis diferentes com requisitos diferentes, e copiar uma opção de cliente para um roteador é como uma tailnet funcional ganha um laço. Uma máquina que anuncia rotas precisa de encaminhamento, regras de firewall que permitam o tráfego encaminhado e uma decisão sobre quais prefixos anuncia. Nada disso é implicado por --accept-routes.

A documentação dos roteadores de sub-rede adverte contra habilitar a aceitação de rotas em roteadores redundantes que anunciam um único prefixo, já que um nó em espera pode empurrar tráfego que já é local através do ativo. Se você opera um par HA, trate isso como restrição de projeto e não como nota de rodapé, e decida qual nó possui o prefixo antes de aprová-lo nos dois. Num único roteador o mesmo aviso se lê como um lembrete de que a aceitação pertence aos clientes, não à máquina que anuncia. Anote qual porta estava fechada.

Para um cliente comum a sequência termina no teste de aplicação que falhou no início. Para o roteador, revise encaminhamento, anúncio, aprovação e firewall nessa ordem, porque o primeiro que falta produz exatamente o tempo esgotado com que você começou.