Tráfego unidirecional ao desativar o SNAT de sub-rede do Tailscale

Desative o NAT de origem num router de sub-rede do Tailscale e o túnel continua a funcionar enquanto as ligações através dele param. Os pedidos chegam ao destino com o endereço overlay do próprio cliente remoto, que é exatamente o objetivo da alteração, e as respostas precisam agora de um caminho que a LAN nunca teve de conhecer. Sem esse caminho os pacotes aterram, as respostas saem pela gateway habitual e a falha apresenta-se como um problema de firewall que nenhuma regra de firewall explica. O túnel está saudável; falta o troço de regresso.

O que o SNAT escondia

Com o SNAT ativo, o router reescreve o endereço de origem para o seu próprio endereço de LAN antes de encaminhar para a sub-rede, pelo que o destino responde a um anfitrião que já sabe como alcançar e nada mais precisa de ser configurado. Desativá-lo preserva a origem original, e o destino passa a ver um endereço dentro do intervalo overlay em vez de um vizinho no seu próprio cabo. Esse endereço é real e encaminhável pela tailnet, e é inalcançável a partir da LAN através da gateway predefinida. O interruptor documentado é --snat-subnet-routes=false, aplicado ao próprio router de sub-rede Linux.

É uma definição permanente e não um interruptor por pacote, por isso o caminho de regresso tem de existir para cada rede de destino servida por esse router. É isso que faz da alteração uma decisão de implementação e não uma caixa de seleção. Tudo o que esse router serve herda o requisito no mesmo momento.

Onde o caminho de regresso pode viver

Três colocações são comuns, e diferem no alcance, não na correção. Uma rota estática no anfitrião de destino é a mais direta e a menos escalável, pois cada dispositivo precisa da sua própria cópia. Uma tabela de rotas na VPC ou no router do local cobre uma rede inteira de uma vez, e uma opção DHCP que transporte rotas estáticas sem classe chega automaticamente aos clientes mas falha em silêncio nos dispositivos que a ignoram.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Qualquer que seja a colocação escolhida, o salto seguinte é o endereço de LAN do router e nunca o seu endereço de tailnet. Um anfitrião da LAN não consegue alcançar o overlay antes de ter esta rota, por isso um salto seguinte dentro do overlay é circular e não envia o pacote para lado nenhum. Esse único erro explica a maioria das configurações que parecem corretas e ainda assim falham, e sobrevive a todas as verificações que só leem a tabela do próprio router. Anote que colocação usou, porque de contrário a pessoa seguinte testará a errada.

Ler a falha como tráfego unidirecional

O sintoma é mais fácil de reconhecer do que a causa: o serviço responde no próprio router e fica silencioso a partir de um cliente remoto. Uma captura no destino mostra pedidos a chegar e respostas a sair, o que parece um sucesso até se notar para onde vão essas respostas. Vão para a gateway predefinida, o que significa que o troço de entrada funcionou e o de regresso não.

Capture no router, em vez disso, porque vê as duas direções de uma troca e mostra se alguma vez chegou uma resposta. Se a resposta aparecer no destino mas nunca no router, a rota falta ou está errada do lado do destino. Se aparecer no router e aí parar, o problema está mais adiante e pertence a outra investigação.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Se o endereço real merece uma rota

Manter o SNAT continua a ser a resposta mais simples sempre que a rede de destino não pode ser reconfigurada, e o custo é que cada cliente parece o router nos registos e na política do destino. Desativá-lo justifica-se quando uma aplicação precisa do endereço de origem real ou quando a política de rede tem de distinguir clientes que partilham um router. Ambos são motivos legítimos e nenhum é gratuito. O benefício tem de valer a manutenção de uma rota em cada rede de destino, mais a revisão da firewall descrita abaixo.

Para uma LAN pequena a troca costuma compensar, enquanto para uma dispersão de aparelhos que não conseguem aceitar uma rota estática normalmente não. Registe a decisão e o motivo junto à configuração do router, para que o administrador seguinte saiba que comportamento é deliberado. Um valor predefinido que ninguém escreveu é indistinguível de um descuido.

Firewall, registos e o papel duplo

Cada regra que correspondia ao endereço de LAN do router passa agora a corresponder a uma origem diferente, incluindo as regras de permissão e qualquer campo de registo que registasse o router como cliente. Leia essas regras antes do primeiro teste e não depois da primeira falha, porque uma regra que só permite o endereço do router bloqueia a nova origem por completo. Restrinja a substituição aos clientes e portas que dela precisam e depois confirme que não admite em silêncio toda a tailnet.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

Um nó que serve simultaneamente como nó de saída e como router de sub-rede é uma combinação documentada que pode deixar cair tráfego ascendente assim que o SNAT de sub-rede é desativado. Separar esses papéis em nós diferentes elimina essa ressalva e dá a cada rota e política de firewall um único proprietário. Se os papéis tiverem de ficar juntos, conte com esse comportamento e teste-o antes de culpar um cliente. Guarde a rota, a definição do interruptor e a atribuição de papéis numa só nota, porque são lidas em conjunto quando a ligação seguinte falha.