Tráfico unidireccional ao desactivar o SNAT de subrede de Tailscale

Desactive o NAT de orixe nun encamiñador de subrede de Tailscale e o túnel segue funcionando mentres as conexións a través del se deteñen. As peticións chegan ao destino coa dirección overlay propia do cliente remoto, que é exactamente o obxectivo do cambio, e as respostas agora necesitan un camiño que a LAN nunca tivo que coñecer. Sen ese camiño os paquetes aterran, as respostas saen pola pasarela habitual e o fallo preséntase como un problema de devasas que ningunha regra de devasas explica. O túnel está san; falta o tramo de volta.

Que ocultaba o SNAT

Co SNAT activado, o encamiñador reescribe a dirección de orixe pola súa propia dirección de LAN antes de reenviar á subrede, de xeito que o destino responde a un host que xa sabe como acadar e non hai que configurar nada máis. Desactivalo conserva a orixe orixinal, e o destino ve entón unha dirección dentro do rango overlay en lugar dun veciño no seu propio cable. Esa dirección é real e encamiñable pola tailnet, e é inalcanzable desde a LAN a través da pasarela predeterminada. O conmutador documentado é --snat-subnet-routes=false, aplicado ao propio encamiñador de subrede Linux.

É un axuste permanente e non un conmutador por paquete, así que a ruta de volta ten que existir para cada rede de destino que sirva ese encamiñador. Iso é o que converte o cambio nunha decisión de despregamento e non nunha caixa de verificación. Todo o que serve ese encamiñador herda o requisito no mesmo momento.

Onde pode vivir a ruta de volta

Tres localizacións son habituais, e difiren en alcance, non en corrección. Unha ruta estática no host de destino é a máis directa e a menos escalable, xa que cada dispositivo necesita a súa propia copia. Unha táboa de rutas na VPC ou no encamiñador do sitio cobre toda unha rede á vez, e unha opción DHCP que transporte rutas estáticas sen clase chega automaticamente aos clientes pero falla en silencio nos dispositivos que a ignoran.

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

Escolla a localización que escolla, o seguinte salto é a dirección de LAN do encamiñador e nunca a súa dirección de tailnet. Un host da LAN non pode alcanzar o overlay ata que teña esta ruta, así que un seguinte salto dentro do overlay é circular e non envía o paquete a ningures. Ese único erro explica a maioría de configuracións que parecen correctas e aínda así fallan, e sobrevive a toda comprobación que só lea a táboa do propio encamiñador. Anote que localización usou, porque doutro xeito a seguinte persoa probará a incorrecta.

Ler o fallo como tráfico unidireccional

O síntoma é máis doado de recoñecer que a causa: o servizo responde no propio encamiñador e permanece en silencio desde un cliente remoto. Unha captura no destino mostra peticións que chegan e respostas que saen, o que parece un éxito ata que un advirte cara a onde van esas respostas. Van cara á pasarela predeterminada, o que significa que o tramo de entrada funcionou e o de volta non.

Capture no encamiñador, en cambio, porque ve as dúas direccións dun intercambio e mostra se algunha vez chegou unha resposta. Se a resposta aparece no destino pero nunca no encamiñador, a ruta falta ou é incorrecta no lado do destino. Se aparece no encamiñador e se detén alí, o problema está máis adiante e pertence a outra investigación.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Se a dirección real merece unha ruta

Manter o SNAT segue sendo a resposta máis simple sempre que a rede de destino non se poida reconfigurar, e o custo é que cada cliente parece o encamiñador nos rexistros e na política do destino. Desactivalo xustifícase cando unha aplicación necesita a dirección de orixe real ou cando a política de rede ten que distinguir clientes que comparten un encamiñador. Ambas son razóns lexítimas e ningunha é de balde. O beneficio ten que merecer manter unha ruta en cada rede de destino, máis a revisión da devasa descrita abaixo.

Para unha LAN pequena o intercambio adoita compensar, mentres que para unha dispersión de aparellos que non poden aceptar unha ruta estática normalmente non. Anote a decisión e o motivo xunto á configuración do encamiñador, para que o seguinte administrador saiba que comportamento é deliberado. Un valor predeterminado que ninguén escribiu é indistinguible dun descoido.

Devasas, rexistros e o dobre papel

Cada regra que coincidía coa dirección de LAN do encamiñador agora coincide cunha orixe distinta, e iso inclúe as regras de permiso e calquera campo de rexistro que rexistrase o encamiñador como cliente. Lea esas regras antes da primeira proba e non despois do primeiro fallo, porque unha regra que só permite a dirección do encamiñador bloquea a nova orixe de plano. Reduza a substitución aos clientes e portos que a necesitan e logo confirme que non admite en silencio toda a tailnet.

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

Un nodo que fai á vez de nodo de saída e de encamiñador de subrede é unha combinación documentada que pode perder tráfico ascendente unha vez desactivado o SNAT de subrede. Separar eses papeis en nodos distintos elimina esa advertencia e dá a cada ruta e política de devasas un único propietario. Se os papeis teñen que quedar xuntos, espere ese comportamento e próbeo antes de culpar un cliente. Garde a ruta, o axuste do conmutador e a asignación de papeis nunha soa nota, porque se len xuntos cando falla a seguinte conexión.