Noranzko bakarreko trafikoa Tailscale azpisareko SNAT desaktibatzean
Desaktibatu SNAT Tailscale azpisareko bideratzailean, eta erantzunak ez dira iristen hasiko. Benetako iturburu-helbidea mantentzen da, beraz, LANak 100.64.0.0/10-era itzultzeko bidea behar du.
Desaktibatu iturburu-NAT Tailscale azpisareko bideratzailean, eta tunela lanean jarraitzen du harekin igarotzen diren konexioak gelditzen diren bitartean. Eskaerak helmugara iristen dira urruneko bezeroaren overlay-helbide propioarekin, hau da, aldaketaren xedea, eta erantzunek orain LANak inoiz ezagutu behar ez zuen bide bat behar dute. Bide hori gabe paketeak lurreratzen dira, erantzunak ohiko atebidetik irteten dira, eta hutsegitea suebaki-arazo gisa aurkezten da, inolako suebaki-arauak azaltzen ez duena. Tunela osasuntsu dago; itzulerako osagaia falta da.
Zer ezkutatzen zuen SNATek
SNAT gaituta dagoenean, bideratzaileak iturburu-helbidea bere LAN-helbidera berridazten du azpisarera bidali aurretik, beraz, helmugak jada nola iritsi badaki ostalari bati erantzuten dio eta ez da ezer gehiago konfiguratu behar. Hori desaktibatzeak jatorrizko iturburua mantentzen du, eta helmugak overlay-barruti barruko helbide bat ikusten du ondoren, bere kableko bizilagun bat izan beharrean. Helbide hori erreala da eta tailnet osoan bideragarria, eta ez da irisgarria LANetik atebide lehenetsiaren bidez. Dokumentatutako etengailua --snat-subnet-routes=false da, Linux azpisareko bideratzaileari berari aplikatuta.
Ezarpen iraunkorra da, ez pakete bakoitzeko etengailua, beraz, itzulerako bideak bideratzaile horrek zerbitzatzen duen helmuga-sare bakoitzerako egon behar du. Horrek bihurtzen du aldaketa inplementazio-erabaki eta ez kontrol-lauki. Bideratzaile horrek zerbitzatzen duen guztiak betebeharra oinordetzen du une berean.
Non egon daitekeen itzulerako bidea
Hiru kokapen ohikoak dira, eta irismenean desberdinak dira, ez zuzenketan. Helmuga-ostalarian jarritako bide estatikoak zuzenena eta eskalagarritasun gutxienekoa da, gailu bakoitzak bere kopia behar baitu. VPCko edo gunearen bideratzaileko bide-taulak sare osoa aldi berean estaltzen du, eta klase gabeko bide estatikoak daramatzan DHCP aukerak bezeroengana automatikoki iristen da, baina isilean huts egiten du aukera hori ez ikusten duten gailuetan.
ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5
Aukeratzen duzun kokapena edozein dela ere, hurrengo jauzia bideratzailearen LAN-helbidea da, eta inoiz ez bere tailnet-helbidea. LAN ostalari batek ezin du overlay-ra iritsi bide hori izan arte, beraz, overlay barruko hurrengo jauzia zirkularra da eta ez du paketea inora bidaltzen. Akats bakar horrek azaltzen ditu zuzen itxura duten eta hala ere huts egiten duten konfigurazio gehienak, eta bideratzailearen taula propioa soilik irakurtzen duen edozein egiaztapenetik bizirik ateratzen da. Idatzi zein kokapen erabili duzun, bestela hurrengo pertsonak okerrekoa probatuko baitu.
Hutsegitea noranzko bakarreko trafiko gisa irakurtzea
Sintoma arrazoia baino errazago ezagutzen da: zerbitzuak bideratzailean bertan erantzuten du eta isilik geratzen da urruneko bezero batetik. Helmugan egindako kapturak eskaerak iristen eta erantzunak irteten erakusten ditu, arrakasta ematen du eta, harik eta erantzunok nora doazen ohartu arte. Atebide lehenetsira doaz, eta horrek esan nahi du sarrerako osagaiak lan egin zuela eta itzulerakoak ez.
Hartu kaptura bideratzailean, horren ordez, elkartruke baten bi norabideak ikusten baititu eta erantzun bat inoiz iritsi den erakusten baitu. Erantzuna helmugan agertzen bada baina inoiz ez bideratzailean, bidea falta da edo okerra da helmugaren aldean. Bideratzailean agertzen bada eta han gelditzen bada, arazoa harago dago eta beste ikerketa bati dagokio.
sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5
Benetako helbideak bide bat merezi ote duen
SNAT mantentzea erantzun sinpleena izaten jarraitzen du helmuga-sarea birkonfiguratu ezin denean, eta kostua da bezero bakoitzak bideratzailearen itxura hartzen duela helmugaren erregistroetan eta politikan. Hori desaktibatzea justifikatzen da aplikazio batek benetako iturburu-helbidea behar duenean edo sare-politikak bideratzaile bat partekatzen duten bezeroak bereizi behar dituenean. Biak dira arrazoi zilegiak eta bat ere ez da doakoa. Onurak helmuga-sare bakoitzean bide bat mantentzearen eta behean deskribatutako suebakiaren berrikuspenaren truke balio izan behar du.
LAN txiki baterako trukeak normalean ordaintzen du, eta bide estatikoa hartu ezin duten gailu-multzo handi baterako, berriz, ez du normalean ordaintzen. Erregistratu erabakia eta arrazoia bideratzailearen konfigurazioaren alboan, hurrengo administratzaileak jakin dezan zein jokabide den nahita egindakoa. Inork idatzi ez zuen lehenetsia ezin da axolagabekeriaz bereizi.
Suebakia, erregistroak eta rol bikoitza
Bideratzailearen LAN-helbidearekin bat egiten zuen arau bakoitzak orain beste iturburu batekin bat egiten du, eta horren barruan daude baimen-arauak eta bideratzailea bezero gisa erregistratzen zuen eremu oro. Irakurri arau horiek lehen proba baino lehen, lehen hutsegitearen ondoren baino, bideratzailearen helbidea soilik baimentzen duen arau batek iturburu berria erabat blokeatzen baitu. Murriztu ordezkoa behar duten bezero eta atakaetara, eta gero egiaztatu isilean tailnet osoa onartzen ez duela.
sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'
Irteera-nodo eta azpisare-bideratzaile gisa aldi berean lan egiten duen nodo bat dokumentatutako konbinazioa da, eta azpisareko SNAT desaktibatu ondoren goranzko trafikoa gal dezake. Rol horiek nodo desberdinetan bereizteak ohar hori kentzen du eta bide eta suebaki-politika bakoitzari jabe bakarra ematen dio. Rolak elkarrekin egon behar badute, espero jokabide hori eta probatu bezeroa erruduntzat jo aurretik. Gorde bidea, etengailuaren ezarpena eta rolen esleipena ohar bakarrean, hurrengo konexioak huts egiten duenean elkarrekin irakurtzen baitira.