Unuvoja trafiko post malŝalto de Tailscale-subreta SNAT

Malŝaltu fontan NAT sur Tailscale-subreta enkursigilo kaj la tunelo daŭre funkcias dum la konektoj tra ĝi haltas. Petoj alvenas al la celo kun la propra overlay-adreso de la fora kliento, kio estas ĝuste la senco de la ŝanĝo, kaj la respondoj nun bezonas vojon, kiun la LAN neniam devis koni. Sen tiu vojo la pakaĵoj surteriĝas, la respondoj eliras tra la ordinara kluzo, kaj la fiasko prezentiĝas kiel fajroŝirma problemo, kiun neniu fajroŝirma regulo klarigas. La tunelo estas sana; la revena kruro mankas.

Kion SNAT kaŝis

Kun SNAT ŝaltita, la enkursigilo reverkas la fontan adreson al sia propra LAN-adreso antaŭ ol plusendi en la subreton, do la celo respondas al gastiganto, al kiu ĝi jam scias kiel atingi, kaj nenio alia bezonas agordiĝi. Malŝaltado konservas la originalan fonton, kaj la celo tiam vidas adreson ene de la overlay-gamo anstataŭ najbaron sur sia propra drato. Tiu adreso estas reala kaj itinerebla tra la tailnet, kaj ĝi estas neatingebla de la LAN tra la defaŭlta kluzo. La dokumentita ŝaltilo estas --snat-subnet-routes=false, aplikata al la Linux-subreta enkursigilo mem.

Ĝi estas konstanta agordo, ne ŝaltilo por ĉiu pakaĵo, do la revena vojo devas ekzisti por ĉiu cela reto, kiun tiu enkursigilo servas. Tio igas la ŝanĝon deploja decido anstataŭ markobutono. Ĉio servata de tiu enkursigilo heredas la postulon en la sama momento.

Kie la revena vojo povas loĝi

Tri lokigoj estas kutimaj, kaj ili diferencas laŭ atingo, ne laŭ korekteco. Statika itinero sur la cela gastiganto estas la plej rekta kaj la malplej skalebla, ĉar ĉiu aparato bezonas sian propran kopion. Itinera tabelo en la VPC aŭ en la eja enkursigilo kovras tutan reton samtempe, kaj DHCP-opcio portanta senklasajn statikajn itinerojn atingas klientojn aŭtomate sed malsukcesas silente sur aparatoj, kiuj ignoras ĝin.

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

Kiun lokigon vi ajn elektas, la sekva salto estas la LAN-adreso de la enkursigilo kaj neniam ĝia tailnet-adreso. LAN-gastiganto ne povas atingi la overlay-on ĝis ĝi posedas ĉi tiun itineron, do sekva salto ene de la overlay estas cirkla kaj sendas la pakaĵon nenie. Tiu sola eraro klarigas la plej multajn agordojn, kiuj aspektas ĝustaj kaj tamen malsukcesas, kaj ĝi postvivas ĉiun kontrolon, kiu legas nur la propran tabelon de la enkursigilo. Notu, kiun lokigon vi uzis, ĉar alie la sekva persono testos la malĝustan.

Legi la fiaskon kiel unuvojan trafikon

La simptomo estas pli facile rekonebla ol la kaŭzo: la servo respondas sur la enkursigilo mem kaj restas silenta de fora kliento. Kaptaĵo sur la celo montras petojn alvenantajn kaj respondojn forirantajn, kio aspektas kiel sukceso ĝis vi rimarkos, kien tiuj respondoj iras. Ili iras al la defaŭlta kluzo, kio signifas, ke la envena kruro funkciis kaj la revena ne.

Kaptu anstataŭe sur la enkursigilo, ĉar ĝi vidas ambaŭ direktojn de unu interŝanĝo kaj montras, ĉu respondo iam alvenis. Se la respondo aperas sur la celo sed neniam sur la enkursigilo, la itinero mankas aŭ estas malĝusta sur la cela flanko. Se ĝi aperas sur la enkursigilo kaj haltas tie, la problemo kuŝas pli antaŭe kaj apartenas al alia esploro.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Ĉu la reala adreso indas itineron

Konservi SNAT restas la pli simpla respondo kiam la cela reto ne povas esti reagordita, kaj la kosto estas, ke ĉiu kliento aspektas kiel la enkursigilo en la protokoloj kaj politiko de la celo. Malŝalti ĝin pravigas, kiam aplikaĵo bezonas la realan fontan adreson aŭ kiam reta politiko devas distingi klientojn, kiuj dividas enkursigilon. Ambaŭ estas legitimaj kialoj kaj neniu estas senpaga. La avantaĝo devas indi prizorgi itineron en ĉiu cela reto, plus la fajroŝirma revizio priskribita sube.

Por unu malgranda LAN la interŝanĝo kutime pagas, dum por disaĵo da aparatoj, kiuj ne povas preni statikan itineron, ĝi kutime ne pagas. Notu la decidon kaj la kialon apud la enkursigila agordo, por ke la sekva administranto sciu, kiu konduto estas intenca. Defaŭlto, kiun neniu skribis, ne distingiĝas de preteratento.

Fajroŝirmilo, protokolado kaj la duobla rolo

Ĉiu regulo, kiu kongruis kun la LAN-adreso de la enkursigilo, nun kongruas kun malsama fonto, kaj tio inkluzivas permesajn regulojn kaj ĉiun protokolan kampon, kiu registris la enkursigilon kiel klienton. Legu tiujn regulojn antaŭ la unua testado anstataŭ post la unua fiasko, ĉar regulo permesanta nur la adreson de la enkursigilo tute blokas la novan fonton. Mallarĝigu la anstataŭaĵon al la klientoj kaj pordoj, kiuj bezonas ĝin, poste konfirmu, ke ĝi ne silente enlasas la tutan tailnet-on.

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

Unu nodo servanta kaj kiel elira nodo kaj kiel subreta enkursigilo estas dokumentita kombinaĵo, kiu povas perdi suprenan trafikon post kiam subreta SNAT estas malŝaltita. Disigi tiujn rolojn sur malsamajn nodojn forigas la kaŭzon kaj donas al ĉiu itinero kaj fajroŝirma politiko unu posedanton. Se la roloj devas resti kune, atendu tiun konduton kaj testu ĝin antaŭ ol kulpigi klienton. Konservu la itineron, la ŝaltilan agordon kaj la rolodisponon en unu noto, ĉar ili legiĝas kune, kiam la sekva konekto fiaskas.