Միակողմանի երթևեկություն Tailscale ենթացանցի SNAT-ն անջատելուց հետո
Անջատեք SNAT-ը Tailscale ենթացանցի երթուղիչում, և պատասխանները կդադարեն հասնել։ Իսկական աղբյուրի հասցեն մնում է, ուստի LAN-ին պետք է վերադարձի երթուղի դեպի 100.64.0.0/10։
Անջատեք աղբյուրի NAT-ը Tailscale ենթացանցի երթուղիչում, և թունելը շարունակում է աշխատել, մինչ դրա միջով անցնող կապերը դադարում են։ Հարցումները հասնում են նպատակակետին հեռավոր հաճախորդի սեփական overlay հասցեով, ինչը հենց փոփոխության իմաստն է, և պատասխաններին այժմ պետք է ուղի, որը LAN-ը երբեք չպետք է իմանար։ Առանց այդ ուղու փաթեթները վայրէջք են կատարում, պատասխանները դուրս են գալիս սովորական դարպասով, և խափանումը ներկայացվում է որպես հրային պատի խնդիր, որը ոչ մի կանոն չի բացատրում։ Թունելը առողջ է, իսկ վերադարձի հատվածը բացակայում է։
Ինչ էր թաքցնում SNAT-ը
SNAT-ը միացված վիճակում երթուղիչը ենթացանց ուղարկելուց առաջ աղբյուրի հասցեն վերագրում է իր սեփական LAN հասցեին, այնպես որ նպատակակետը պատասխանում է հոսթի, որին արդեն գիտի ինչպես հասնել, և ուրիշ ոչինչ պետք չէ կարգավորել։ Այն անջատելը պահպանում է սկզբնական աղբյուրը, և նպատակակետը այնուհետև տեսնում է overlay տիրույթի ներսում գտնվող հասցե՝ իր լարին հարևան լինելու փոխարեն։ Այդ հասցեն իրական է և երթուղելի tailnet-ով, սակայն LAN-ից լռելյայն դարպասով անհասանելի է։ Փաստագրված անջատիչը --snat-subnet-routes=false-ն է, որը կիրառվում է հենց Linux ենթացանցի երթուղիչի վրա։
Սա մշտական կարգավորում է, ոչ թե յուրաքանչյուր փաթեթի անջատիչ, ուստի վերադարձի ուղին պետք է գոյություն ունենա յուրաքանչյուր նպատակակետ ցանցի համար, որը սպասարկում է այդ երթուղիչը։ Սա է, ինչ փոփոխությունը դարձնում է տեղակայման որոշում, այլ ոչ թե նշատուփ։ Այն ամենը, ինչ սպասարկում է այդ երթուղիչը, ժառանգում է պահանջը նույն պահին։
Որտեղ կարող է լինել վերադարձի ուղին
Երեք տեղաբաշխում սովորական են, և դրանք տարբերվում են ընդգրկվածությամբ, ոչ թե ճշգրտությամբ։ Նպատակակետ հոսթի վրա ստատիկ երթուղին ամենաուղղակին և ամենաքիչ մասշտաբայինն է, քանի որ յուրաքանչյուր սարքի պետք է իր պատճենը։ VPC-ում կամ տեղամասի երթուղիչում երթուղային աղյուսակը միանգամից ընդգրկում է ամբողջ ցանցը, իսկ դասերից զուրկ ստատիկ երթուղիներ կրող DHCP տարբերակը ինքնաբերաբար հասնում է հաճախորդներին, բայց լուռ ձախողվում է այն սարքերում, որոնք անտեսում են այն։
ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5
Ինչ տեղաբաշխում էլ ընտրեք, հաջորդ թռիչքը երթուղիչի LAN հասցեն է և երբեք նրա tailnet հասցեն։ LAN հոսթը չի կարող հասնել overlay-ին մինչև այս երթուղին չունենա, ուստի overlay-ի ներսում հաջորդ թռիչքը շրջանաձև է և փաթեթը ոչ մի տեղ չի ուղարկում։ Այս մեկ սխալը բացատրում է ճիշտ տեսք ունեցող և այնուամենայնիվ ձախողվող կարգավորումների մեծ մասը, և այն վերապրում է ցանկացած ստուգում, որը կարդում է միայն երթուղիչի սեփական աղյուսակը։ Գրեք, թե որ տեղաբաշխումն եք օգտագործել, այլապես հաջորդ մարդը կփորձարկի սխալը։
Խափանումը կարդալը որպես միակողմանի երթևեկություն
Ախտանիշն ավելի հեշտ է ճանաչել, քան պատճառը. ծառայությունը պատասխանում է հենց երթուղիչի վրա և լուռ է մնում հեռավոր հաճախորդից։ Նպատակակետում արված գրառումը ցույց է տալիս ժամանող հարցումներ և մեկնող պատասխաններ, ինչը հաջողություն է թվում, քանի դեռ չեք նկատել, թե ուր են գնում այդ պատասխանները։ Դրանք գնում են լռելյայն դարպասին, ինչը նշանակում է, որ մուտքի հատվածը աշխատել է, իսկ վերադարձինը՝ ոչ։
Փոխարենը գրառեք երթուղիչի վրա, քանի որ այն տեսնում է մեկ փոխանակության երկու ուղղությունները և ցույց է տալիս՝ արդյոք պատասխանը երբևէ հասել է։ Եթե պատասխանը երևում է նպատակակետում, բայց երբեք՝ երթուղիչում, ապա երթուղին բացակայում է կամ սխալ է նպատակակետի կողմում։ Եթե այն երևում է երթուղիչում և այնտեղ կանգ է առնում, խնդիրն ավելի հեռու է և պատկանում է այլ հետաքննության։
sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5
Արդյոք իրական հասցեն արժե երթուղի
SNAT-ը պահելը մնում է ավելի պարզ պատասխան, երբ նպատակակետ ցանցը հնարավոր չէ վերակարգավորել, և արժեքն այն է, որ յուրաքանչյուր հաճախորդ նպատակակետի մատյաններում և քաղաքականության մեջ երևում է որպես երթուղիչ։ Այն անջատելը արդարացված է, երբ հավելվածին պետք է իսկական աղբյուրի հասցեն կամ երբ ցանցային քաղաքականությունը պետք է տարբերի նույն երթուղիչը կիսող հաճախորդներին։ Երկուսն էլ օրինական պատճառներ են, և ոչ մեկը անվճար չէ։ Օգուտը պետք է արժենա յուրաքանչյուր նպատակակետ ցանցում երթուղի պահելը, գումարած ստորև նկարագրված հրային պատի վերանայումը։
Մեկ փոքր LAN-ի համար փոխանակումը սովորաբար արդարացնում է իրեն, մինչդեռ ստատիկ երթուղի չընդունող սարքերի բազմության համար սովորաբար ոչ։ Գրանցեք որոշումը և պատճառը երթուղիչի կարգավորումների կողքին, որպեսզի հաջորդ ադմինիստրատորը իմանա, թե որ վարքագիծն է դիտավորյալ։ Այն լռելյայնը, որը ոչ ոք չի գրել, չի տարբերվում անփութությունից։
Հրային պատ, մատյան և կրկնակի դեր
Յուրաքանչյուր կանոն, որը համընկնում էր երթուղիչի LAN հասցեի հետ, այժմ համընկնում է այլ աղբյուրի հետ, և դա ներառում է թույլտվության կանոնները և ցանկացած մատյանի դաշտ, որը գրանցում էր երթուղիչը որպես հաճախորդ։ Կարդացեք այդ կանոնները առաջին փորձարկումից առաջ, ոչ թե առաջին ձախողումից հետո, որովհետև միայն երթուղիչի հասցեն թույլատրող կանոնը լիովին արգելափակում է նոր աղբյուրը։ Սահմանափակեք փոխարինումը այն հաճախորդներով և պորտերով, որոնց այն պետք է, ապա հաստատեք, որ այն լուռ չի ընդունում ողջ tailnet-ը։
sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'
Մեկ հանգույց, որը միաժամանակ ծառայում է որպես ելքի հանգույց և ենթացանցի երթուղիչ, փաստագրված համակցություն է, որը կարող է գցել վերին հոսքի երթևեկությունը ենթացանցի SNAT-ն անջատելուց հետո։ Այդ դերերը տարբեր հանգույցների վրա բաժանելը վերացնում է այս վերապահումը և յուրաքանչյուր երթուղու և հրային պատի քաղաքականության տալիս է մեկ սեփականատեր։ Եթե դերերը պետք է մնան միասին, սպասեք այս վարքագծին և փորձարկեք այն նախքան հաճախորդին մեղադրելը։ Պահեք երթուղին, անջատիչի կարգավորումը և դերերի բաշխումը մեկ նշումում, որովհետև դրանք միասին են կարդացվում, երբ հաջորդ կապը ձախողվում է։