Por que uma rota de sub-rede aprovada do Tailscale ainda expira

A aprovação na consola de administração parece o último passo, e não é. Primeiro a aplicação expira, e só depois descobre que o router está online e a rota aprovada. A aprovação é um passo de distribuição, não uma permissão nem uma garantia de encaminhamento. Quatro etapas têm de se alinhar antes de um pacote chegar a um anfitrião atrás de um router de sub-rede, e cada uma pode funcionar enquanto a seguinte falha. Percorra-as por ordem e pare na primeira que não se sustente.

Quatro etapas, uma falha

O router anuncia o prefixo, a tailnet aprova esse anúncio, o cliente aceita a rota que recebeu e a política de acesso permite a ligação concreta. São quatro decisões separadas tomadas por três componentes diferentes. Portanto, uma rota aprovada diz apenas que a rede passou a fazer parte da tabela de encaminhamento da tailnet.

A quarta etapa é a que mais se omite, porque as três primeiras produzem um estado visível. Uma concessão que cobre o endereço tailnet do próprio router não cobre automaticamente uma sub-rede privada atrás dele. São destinos diferentes, e a política é avaliada por destino.

No Linux a terceira etapa também tem um valor predefinido que surpreende: aceitar rotas de sub-rede é opcional. Vários clientes com interface gráfica aceitam as rotas anunciadas por predefinição, pelo que uma frota mista pode mostrar uma máquina a falhar enquanto as restantes funcionam.

Confirme a preferência na máquina que falha em vez de supor uma plataforma. A rota nunca foi a peça em falta nas máquinas que funcionam, por isso deixe que sejam elas a provar que o lado da tailnet está são. A documentação do Tailscale sobre routers de sub-rede cobre a aprovação, a aceitação de rotas no cliente e a etapa de política.

Verifique a rota onde o cliente é executado

Comece pelo cliente que falha, não pelo router. Confirme que a rota está presente e que a preferência do cliente permite aceitar rotas.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

O primeiro comando mostra a lista de pares e se o router de sub-rede está acessível, o segundo imprime as preferências do cliente incluindo o indicador de aceitação de rotas, e o terceiro pergunta ao núcleo que interface usaria para um anfitrião real na sub-rede. Se esse último comando nomear a interface física em vez da interface do Tailscale, a rota nunca chegou à tabela. Uma rota em falta é um problema do lado do cliente, não de aprovação. Corrija-o antes de olhar para a política.

Para aceitar rotas no Linux, volte a ligar-se com o indicador em vez de supor que está definido: tailscale up --accept-routes. Um cliente que se juntou com outros indicadores mantém-nos até serem alterados, por isso verifique a preferência atual antes de acrescentar outra. Voltar a executar o primeiro comando após a alteração deverá mostrar a rota na tabela.

Prove o encaminhamento e o caminho de volta

A aprovação não configura o router para encaminhar pacotes nem arranja a resposta. Ambas são questões ao nível do anfitrião no lado LAN do router. Teste-as no router, não no cliente.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

O primeiro comando tem de reportar 1, ou o núcleo descarta o pacote encaminhado. O segundo mostra se a máscara da rota de sub-rede reescreve a origem, que é o comportamento predefinido e normalmente o que se pretende. O terceiro mostra se o pedido chega ao destino e se algo regressa; um pedido sem resposta é um problema do caminho de volta, não de aprovação. Leia os três resultados em conjunto antes de alterar qualquer um deles.

Se a máscara foi desativada, a rede de destino precisa de uma rota de volta para os endereços da tailnet, e cada salto intermédio tem de a conhecer. Voltar a ativar a máscara é a correção mais rápida para um único serviço, ao custo de ocultar o endereço original do cliente ao destino. Esse compromisso importa quando o destino regista endereços de origem para auditoria, por isso decida-o deliberadamente em vez de trocar o indicador durante um incidente. Documente que opção escolheu, porque a pessoa seguinte só verá um dos dois comportamentos.

Leia a regra de acesso ao recurso

Com a rota presente e o encaminhamento provado, o suspeito restante é a política. Leia a concessão que deveria permitir a ligação e verifique o destino, não apenas a origem. A identidade do próprio cliente também tem de corresponder ao seletor da política, por isso registe-a a partir da mesma máquina que falha.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

A saída de estado identifica os endereços do próprio cliente e os pares que vê, e é com isso que o seletor de origem da política tem de coincidir. tailscale ping prova o caminho da tailnet até ao próprio router de sub-rede; resolve nomes de pares e endereços da tailnet, não anfitriões dentro de uma sub-rede anunciada. O terceiro comando envia um eco ICMP normal pela rota de sub-rede, pelo que o resultado descreve o destino e não o router. Uma negação ao nível da tailnet costuma voltar como recusa, enquanto um pacote que sai e nunca regressa expira.

Um nome que falha é uma questão diferente de um endereço que falha; resolva o anfitrião diretamente antes de culpar a rota. Escreva a concessão segundo o requisito real do recurso e não segundo toda a sub-rede. Abrir uma /24 inteira para que uma aplicação funcione é a forma como um pedido estreito se torna uma permissão ampla que depois ninguém ousa retirar.

Se o objetivo era a saída para a internet e não uma sub-rede privada, o componente correto é um nó de saída, não um router de sub-rede, e a política e o encaminhamento diferem em conformidade. Verifique essa decisão antes de ampliar uma concessão. Um nó de saída altera a rota predefinida; um router de sub-rede apenas anuncia um prefixo.