Tráfico unidireccional al desactivar el SNAT de subred de Tailscale

Desactive el NAT de origen en un enrutador de subred de Tailscale y el túnel sigue funcionando mientras las conexiones a través de él se detienen. Las peticiones llegan al destino con la dirección overlay propia del cliente remoto, que es exactamente el objetivo del cambio, y las respuestas ahora necesitan una ruta que la LAN nunca tuvo que conocer. Sin esa ruta los paquetes aterrizan, las respuestas salen por la puerta de enlace habitual y el fallo se presenta como un problema de cortafuegos que ninguna regla de cortafuegos explica. El túnel está sano; falta el tramo de vuelta.

Qué ocultaba el SNAT

Con el SNAT activado, el enrutador reescribe la dirección de origen por su propia dirección de LAN antes de reenviar a la subred, de modo que el destino responde a un host que ya sabe cómo alcanzar y no hay que configurar nada más. Desactivarlo conserva el origen original, y el destino ve entonces una dirección dentro del rango overlay en lugar de un vecino en su propio cable. Esa dirección es real y enrutable por la tailnet, y es inalcanzable desde la LAN a través de la puerta de enlace predeterminada. El conmutador documentado es --snat-subnet-routes=false, aplicado al propio enrutador de subred Linux.

Es un ajuste permanente y no un conmutador por paquete, así que la ruta de vuelta tiene que existir para cada red de destino que sirva ese enrutador. Eso es lo que convierte el cambio en una decisión de despliegue y no en una casilla. Todo lo que sirve ese enrutador hereda el requisito en el mismo momento.

Dónde puede vivir la ruta de vuelta

Tres ubicaciones son habituales, y difieren en alcance, no en corrección. Una ruta estática en el host de destino es la más directa y la menos escalable, ya que cada dispositivo necesita su propia copia. Una tabla de rutas en la VPC o en el enrutador del sitio cubre toda una red a la vez, y una opción DHCP que transporte rutas estáticas sin clase llega automáticamente a los clientes pero falla en silencio en dispositivos que la ignoran.

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

Elija la ubicación que elija, el siguiente salto es la dirección de LAN del enrutador y nunca su dirección de tailnet. Un host de la LAN no puede alcanzar el overlay hasta que tenga esta ruta, así que un siguiente salto dentro del overlay es circular y no envía el paquete a ninguna parte. Ese único error explica la mayoría de configuraciones que parecen correctas y aun así fallan, y sobrevive a toda comprobación que solo lea la tabla del propio enrutador. Anote qué ubicación usó, porque de lo contrario la siguiente persona probará la incorrecta.

Leer el fallo como tráfico unidireccional

El síntoma es más fácil de reconocer que la causa: el servicio responde en el propio enrutador y permanece en silencio desde un cliente remoto. Una captura en el destino muestra peticiones que llegan y respuestas que salen, lo que parece un éxito hasta que uno advierte hacia dónde van esas respuestas. Van hacia la puerta de enlace predeterminada, lo que significa que el tramo de entrada funcionó y el de vuelta no.

Capture en el enrutador, en cambio, porque ve ambas direcciones de un intercambio y muestra si alguna vez llegó una respuesta. Si la respuesta aparece en el destino pero nunca en el enrutador, la ruta falta o es incorrecta en el lado del destino. Si aparece en el enrutador y se detiene allí, el problema está más adelante y pertenece a otra investigación.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Si la dirección real merece una ruta

Mantener el SNAT sigue siendo la respuesta más simple siempre que la red de destino no pueda reconfigurarse, y el coste es que cada cliente parece el enrutador en los registros y la política del destino. Desactivarlo se justifica cuando una aplicación necesita la dirección de origen real o cuando la política de red tiene que distinguir clientes que comparten un enrutador. Ambas son razones legítimas y ninguna es gratuita. El beneficio tiene que merecer mantener una ruta en cada red de destino, más la revisión del cortafuegos descrita abajo.

Para una LAN pequeña el intercambio suele compensar, mientras que para una dispersión de aparatos que no pueden aceptar una ruta estática normalmente no. Anote la decisión y el motivo junto a la configuración del enrutador, para que el siguiente administrador sepa qué comportamiento es deliberado. Un valor predeterminado que nadie escribió es indistinguible de un descuido.

Cortafuegos, registros y el doble papel

Cada regla que coincidía con la dirección de LAN del enrutador ahora coincide con un origen distinto, y eso incluye las reglas de permiso y cualquier campo de registro que registrara el enrutador como cliente. Lea esas reglas antes de la primera prueba y no después del primer fallo, porque una regla que solo permite la dirección del enrutador bloquea el nuevo origen de plano. Reduzca la sustitución a los clientes y puertos que la necesitan y luego confirme que no admite en silencio toda la tailnet.

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

Un nodo que hace a la vez de nodo de salida y de enrutador de subred es una combinación documentada que puede perder tráfico ascendente una vez desactivado el SNAT de subred. Separar esos papeles en nodos distintos elimina esa advertencia y da a cada ruta y política de cortafuegos un solo propietario. Si los papeles tienen que quedarse juntos, espere ese comportamiento y pruébelo antes de culpar a un cliente. Guarde la ruta, el ajuste del conmutador y la asignación de papeles en una sola nota, porque se leen juntos cuando falla la siguiente conexión.