Trafic unidirecțional după dezactivarea SNAT-ului de subrețea Tailscale

Dezactivați NAT-ul sursă pe un router de subrețea Tailscale și tunelul continuă să funcționeze în timp ce conexiunile prin el se opresc. Cererile ajung la destinație cu adresa overlay proprie a clientului îndepărtat, ceea ce este exact scopul schimbării, și răspunsurile au acum nevoie de o cale pe care LAN-ul nu a trebuit niciodată să o cunoască. Fără acea cale pachetele aterizează, răspunsurile pleacă prin gateway-ul obișnuit, iar defecțiunea se prezintă ca o problemă de firewall pe care nicio regulă nu o explică. Tunelul este sănătos; lipsește partea de întoarcere.

Ce ascundea SNAT

Cu SNAT activat, routerul rescrie adresa sursă în propria adresă LAN înainte de a redirecționa către subrețea, astfel încât destinația răspunde unui host pe care deja știe cum să-l atingă și nimic altceva nu trebuie configurat. Dezactivarea păstrează sursa originală, iar destinația vede atunci o adresă din intervalul overlay, nu un vecin pe propriul cablu. Acea adresă este reală și rutabilă în tot tailnet-ul, dar este inaccesibilă din LAN prin gateway-ul implicit. Comutatorul documentat este --snat-subnet-routes=false, aplicat routerului de subrețea Linux însuși.

Este o setare permanentă, nu un comutator pentru fiecare pachet, așa că ruta de întoarcere trebuie să existe pentru fiecare rețea de destinație deservită de acel router. De aceea schimbarea este o decizie de implementare, nu o bifă. Tot ce deserveste acel router moștenește cerința în același moment.

Unde poate sta ruta de întoarcere

Trei amplasări sunt obișnuite și diferă prin acoperire, nu prin corectitudine. O rută statică pe hostul de destinație este cea mai directă și cea mai puțin scalabilă, deoarece fiecare dispozitiv are nevoie de propria copie. Un tabel de rutare în VPC sau în routerul locației acoperă o întreagă rețea deodată, iar o opțiune DHCP care transportă rute statice fără clase ajunge automat la clienți dar eșuează în tăcere pe dispozitivele care o ignoră.

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

Orice amplasare ați alege, următorul salt este adresa LAN a routerului și niciodată adresa sa tailnet. Un host din LAN nu poate ajunge la overlay până nu are această rută, așa că un salt următor în interiorul overlay-ului este circular și nu trimite pachetul nicăieri. Acea singură greșeală explică majoritatea configurațiilor care par corecte și totuși eșuează, și supraviețuiește oricărei verificări care citește doar tabelul routerului însuși. Notați ce amplasare ați folosit, altfel următoarea persoană o va testa pe cea greșită.

Citirea defecțiunii ca trafic unidirecțional

Simptomul este mai ușor de recunoscut decât cauza: serviciul răspunde pe routerul însuși și rămâne mut de la un client îndepărtat. O captură la destinație arată cereri care sosesc și răspunsuri care pleacă, ceea ce pare un succes până observați încotro se îndreaptă acele răspunsuri. Ele merg spre gateway-ul implicit, ceea ce înseamnă că partea de intrare a funcționat, iar cea de întoarcere nu.

Capturați în schimb pe router, pentru că vede ambele direcții ale unui schimb și arată dacă a sosit vreodată un răspuns. Dacă răspunsul apare la destinație dar niciodată pe router, ruta lipsește sau este greșită pe partea destinației. Dacă apare pe router și se oprește acolo, problema este mai departe și aparține altei investigații.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Merită adresa reală o rută

Păstrarea SNAT rămâne răspunsul mai simplu oricând rețeaua de destinație nu poate fi reconfigurată, iar costul este că fiecare client arată ca routerul în jurnalele și politica destinației. Dezactivarea este justificată când o aplicație are nevoie de adresa sursă reală sau când politica de rețea trebuie să distingă clienții care împart un router. Ambele sunt motive legitime și niciunul nu este gratuit. Beneficiul trebuie să merite întreținerea unei rute în fiecare rețea de destinație, plus revizuirea firewall-ului descrisă mai jos.

Pentru un LAN mic schimbul de obicei merită, în timp ce pentru o multitudine de aparate care nu pot primi o rută statică de obicei nu merită. Înregistrați decizia și motivul lângă configurația routerului, ca următorul administrator să știe ce comportament este intenționat. O valoare implicită pe care nimeni nu a scris-o nu se distinge de o scăpare.

Firewall, jurnalizare și rolul dublu

Fiecare regulă care se potrivea cu adresa LAN a routerului se potrivește acum cu o altă sursă, inclusiv regulile de permitere și orice câmp de jurnal care înregistra routerul ca client. Citiți acele reguli înainte de primul test, nu după primul eșec, deoarece o regulă care permite doar adresa routerului blochează complet noua sursă. Restrângeți înlocuirea la clienții și porturile care au nevoie de ea, apoi confirmați că nu admite în tăcere întregul tailnet.

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

Un nod care servește simultan ca nod de ieșire și ca router de subrețea este o combinație documentată care poate pierde traficul ascendent după ce SNAT-ul de subrețea este dezactivat. Separarea acestor roluri pe noduri diferite elimină acea rezervă și dă fiecărei rute și politici de firewall un singur proprietar. Dacă rolurile trebuie să rămână împreună, așteptați-vă la acest comportament și testați-l înainte de a da vina pe un client. Păstrați ruta, setarea comutatorului și alocarea rolurilor într-o singură notă, pentru că sunt citite împreună când următoarea conexiune eșuează.