Trànsit unidireccional en desactivar l'SNAT de subxarxa de Tailscale

Desactiveu el NAT d'origen en un encaminador de subxarxa de Tailscale i el túnel continua funcionant mentre les connexions que el travessen s'aturen. Les peticions arriben a la destinació amb l'adreça overlay pròpia del client remot, que és exactament el sentit del canvi, i les respostes ara necessiten un camí que la LAN mai no havia de conèixer. Sense aquest camí els paquets arriben, les respostes surten per la passarel·la ordinària i la fallada es presenta com un problema de tallafocs que cap regla de tallafocs explica. El túnel és sa; la cama de tornada falta.

Què amagava l'SNAT

Amb l'SNAT activat, l'encaminador reescriu l'adreça d'origen per la seva pròpia adreça de LAN abans de reenviar cap a la subxarxa, de manera que la destinació respon a un amfitrió que ja sap com assolir i no cal configurar res més. Desactivar-ho preserva l'origen original, i la destinació veu aleshores una adreça dins del rang overlay en lloc d'un veí al seu propi cable. Aquesta adreça és real i encaminable per la tailnet, i és inabastable des de la LAN a través de la passarel·la per defecte. L'interruptor documentat és --snat-subnet-routes=false, aplicat al mateix encaminador de subxarxa Linux.

És un paràmetre permanent i no un commutador per paquet, així que el camí de tornada ha d'existir per a cada xarxa de destinació que serveixi aquest encaminador. Això és el que converteix el canvi en una decisió de desplegament i no en una casella. Tot el que serveixi aquest encaminador hereta el requisit al mateix moment.

On pot viure el camí de tornada

Tres ubicacions són habituals, i es diferencien en abast, no en correcció. Una ruta estàtica a l'amfitrió de destinació és la més directa i la menys escalable, ja que cada dispositiu necessita la seva pròpia còpia. Una taula de rutes a la VPC o a l'encaminador del lloc cobreix tota una xarxa alhora, i una opció DHCP que porti rutes estàtiques sense classe arriba automàticament als clients però falla en silenci als dispositius que la ignoren.

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

Sigui quina sigui la ubicació que trieu, el salt següent és l'adreça de LAN de l'encaminador i mai la seva adreça de tailnet. Un amfitrió de la LAN no pot arribar a l'overlay fins que té aquesta ruta, així que un salt següent dins de l'overlay és circular i no envia el paquet enlloc. Aquest sol error explica la majoria de configuracions que semblen correctes i igualment fallen, i sobreviu a totes les comprovacions que només llegeixen la taula del mateix encaminador. Anoteu quina ubicació heu fet servir, perquè altrament la persona següent provarà la incorrecta.

Llegir la fallada com a trànsit unidireccional

El símptoma és més fàcil de reconèixer que la causa: el servei respon a l'encaminador mateix i calla des d'un client remot. Una captura a la destinació mostra peticions que arriben i respostes que surten, cosa que sembla un èxit fins que us fixeu on van aquestes respostes. Van cap a la passarel·la per defecte, cosa que significa que la cama d'entrada va funcionar i la de tornada no.

Captureu a l'encaminador, en canvi, perquè veu les dues direccions d'un intercanvi i mostra si alguna vegada ha arribat una resposta. Si la resposta apareix a la destinació però mai a l'encaminador, la ruta falta o és incorrecta al costat de la destinació. Si apareix a l'encaminador i s'hi atura, el problema és més enllà i pertany a una altra investigació.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Val la pena una ruta per a l'adreça real

Mantenir l'SNAT continua sent la resposta més simple sempre que la xarxa de destinació no es pugui reconfigurar, i el cost és que cada client sembla l'encaminador als registres i a la política de la destinació. Desactivar-ho es justifica quan una aplicació necessita l'adreça d'origen real o quan la política de xarxa ha de distingir clients que comparteixen un encaminador. Totes dues són raons legítimes i cap no és gratuïta. El benefici ha de valer la pena de mantenir una ruta a cada xarxa de destinació, més la revisió del tallafocs descrita més avall.

Per a una LAN petita l'intercanvi normalment surt a compte, mentre que per a una dispersió d'aparells que no poden acceptar una ruta estàtica normalment no. Anoteu la decisió i el motiu al costat de la configuració de l'encaminador, perquè el proper administrador sàpiga quin comportament és deliberat. Un valor per defecte que ningú no ha escrit és indistingible d'un oblit.

Tallafocs, registres i la doble funció

Cada regla que coincidia amb l'adreça de LAN de l'encaminador ara coincideix amb una font diferent, i això inclou les regles de permissió i qualsevol camp de registre que enregistrés l'encaminador com a client. Llegiu aquestes regles abans de la primera prova i no després de la primera fallada, perquè una regla que només permet l'adreça de l'encaminador bloqueja la nova font de ple. Estrebeu la substitució als clients i ports que la necessiten, i després confirmeu que no admet en silenci tota la tailnet.

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

Un node que fa alhora de node de sortida i d'encaminador de subxarxa és una combinació documentada que pot descartar trànsit ascendent un cop desactivat l'SNAT de subxarxa. Separar aquests papers en nodes diferents elimina aquesta advertència i dona a cada ruta i política de tallafocs un sol propietari. Si els papers han de quedar junts, espereu aquest comportament i proveu-lo abans de culpar un client. Guardeu la ruta, el paràmetre de l'interruptor i l'assignació de papers en una sola nota, perquè es llegeixen juntes quan falla la connexió següent.