Trafik njëdrejtimësh pas çaktivizimit të SNAT-së së nënrrjetit Tailscale
Çaktivizoni SNAT-në në një ruter të nënrrjetit Tailscale dhe përgjigjet ndalojnë së ardhuri. Adresa reale e burimit mbetet, prandaj LAN ka nevojë për një rrugë kthimi drejt 100.64.0.0/10.
Çaktivizoni NAT-në e burimit në një ruter të nënrrjetit Tailscale dhe tuneli vazhdon të punojë ndërsa lidhjet përmes tij ndalen. Kërkesat arrijnë në destinacion me adresën overlay të vetë klientit të largët, që është pikërisht qëllimi i ndryshimit, dhe përgjigjet tani kanë nevojë për një rrugë që LAN nuk duhej ta njihte kurrë. Pa atë rrugë paketat ulen, përgjigjet dalin përmes portës së zakonshme, dhe dështimi shfaqet si problem firewall-i që asnjë rregull nuk e shpjegon. Tuneli është i shëndetshëm; këmba e kthimit mungon.
Çfarë fshihte SNAT
Me SNAT të aktivizuar, rutera rishkruan adresën e burimit në adresën e vet LAN përpara se ta përcjellë në nënrrjet, kështu që destinacioni i përgjigjet një hosti që tashmë e di si ta arrijë dhe asgjë tjetër nuk duhet konfiguruar. Çaktivizimi ruan burimin origjinal, dhe destinacioni atëherë sheh një adresë brenda diapazonit overlay, jo një fqinj në telin e vet. Kjo adresë është reale dhe e rrugëtueshme nëpër tailnet, por është e paarritshme nga LAN përmes portës së parazgjedhur. Ndërprerësi i dokumentuar është --snat-subnet-routes=false, i aplikuar në vetë ruterin e nënrrjetit Linux.
Është një cilësim i përhershëm dhe jo një ndërprerës për çdo paketë, prandaj rruga e kthimit duhet të ekzistojë për çdo rrjet destinacioni që shërben ai ruter. Kjo është ajo që e bën ndryshimin vendim vendosjeje dhe jo kuti kontrolli. Çdo gjë që shërben ai ruter trashëgon kërkesën në të njëjtin moment.
Ku mund të jetojë rruga e kthimit
Tre vendosje janë të zakonshme, dhe ndryshojnë në shtrirje, jo në saktësi. Një rrugë statike në hostin e destinacionit është më e drejtpërdrejta dhe më pak e shkallëzueshme, sepse çdo pajisje ka nevojë për kopjen e vet. Një tabelë rrugësh në VPC ose në ruterin e sitit mbulon një rrjet të tërë përnjëherë, dhe një opsion DHCP që mbart rrugë statike pa klasa arrin klientët automatikisht por dështon në heshtje në pajisjet që e injorojnë.
ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5
Cilindo vendosje të zgjidhni, hapi tjetër është adresa LAN e ruterit dhe kurrë adresa e tij tailnet. Një host i LAN nuk mund ta arrijë overlay derisa ta ketë këtë rrugë, prandaj një hap tjetër brenda overlay është rrethor dhe nuk e dërgon paketën askund. Ky gabim i vetëm shpjegon shumicën e konfigurimeve që duken të sakta dhe gjithsesi dështojnë, dhe i mbijeton çdo kontrolli që lexon vetëm tabelën e vetë ruterit. Shkruani cilën vendosje përdorët, përndryshe personi tjetër do të testojë atë të gabuarën.
Leximi i dështimit si trafik njëdrejtimësh
Simptoma është më e lehtë për t'u njohur sesa shkaku: shërbimi përgjigjet në vetë ruterin dhe hesht nga një klient i largët. Një kapje në destinacion tregon kërkesa që vijnë dhe përgjigje që ikin, që duket si sukses derisa të vini re ku po shkojnë ato përgjigje. Ato po shkojnë drejt portës së parazgjedhur, që do të thotë se këmba hyrëse punoi dhe ajo e kthimit jo.
Kapni në ruter në vend të kësaj, sepse ai i sheh të dyja drejtimet e një shkëmbimi dhe tregon nëse një përgjigje ka ardhur ndonjëherë. Nëse përgjigja shfaqet në destinacion por kurrë në ruter, rruga mungon ose është e gabuar në anën e destinacionit. Nëse shfaqet në ruter dhe ndalon atje, problemi është më tej dhe i përket një hetimi tjetër.
sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5
A e meriton adresa reale një rrugë
Mbajtja e SNAT mbetet përgjigjja më e thjeshtë sa herë që rrjeti i destinacionit nuk mund të rikonfigurohet, dhe kostoja është që çdo klient duket si ruteri në regjistrat dhe politikën e destinacionit. Çaktivizimi justifikohet kur një aplikacion ka nevojë për adresën reale të burimit ose kur politika e rrjetit duhet të dallojë klientët që ndajnë një ruter. Të dyja janë arsye legjitime dhe asnjëra nuk është falas. Përfitimi duhet të ia vlejë mirëmbajtjes së një rrugë në çdo rrjet destinacioni, plus rishikimin e firewall-it të përshkruar më poshtë.
Për një LAN të vogël shkëmbimi zakonisht ia vlen, ndërsa për një shpërndarje pajisjesh që nuk mund të marrin një rrugë statike zakonisht nuk ia vlen. Regjistroni vendimin dhe arsyen pranë konfigurimit të ruterit, që administratori tjetër ta dijë se cila sjellje është e qëllimshme. Një parazgjedhje që askush nuk e shkroi nuk dallohet nga një lëshim.
Firewall, regjistrim dhe roli i dyfishtë
Çdo rregull që përputhej me adresën LAN të ruterit tani përputhet me një burim tjetër, përfshirë rregullat e lejimit dhe çdo fushë regjistri që shënonte ruterin si klient. Lexoni ato rregulla përpara provës së parë, jo pas dështimit të parë, sepse një rregull që lejon vetëm adresën e ruterit e bllokon plotësisht burimin e ri. Kufizoni zëvendësimin te klientët dhe portat që kanë nevojë për të, pastaj konfirmoni se nuk e pranon në heshtje të gjithë tailnet-in.
sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'
Një nyje që shërben njëkohësisht si nyje daljeje dhe si ruter i nënrrjetit është një kombinim i dokumentuar që mund të hedhë trafikun në rrjedhën lart pasi SNAT e nënrrjetit të çaktivizohet. Ndarja e këtyre roleve në nyje të ndryshme e heq atë rezervë dhe i jep çdo rruge dhe politike firewall-i një pronar të vetëm. Nëse rolet duhet të mbeten bashkë, prisni këtë sjellje dhe provojeni përpara se të fajësoni një klient. Mbani rrugën, cilësimin e ndërprerësit dhe caktimin e roleve në një shënim të vetëm, sepse lexohen bashkë kur lidhja tjetër dështon.