Ինչու է հաստատված Tailscale ենթացանցի երթուղին դեռ թայմաութի հանգեցնում

Հաստատումը ադմինիստրատորի վահանակում թվում է վերջին քայլը, բայց այդպես չէ։ Նախ հավելվածը թայմաութի է հանգեցնում, և միայն դրանից հետո եք գտնում երթուղիչը առցանց և երթուղին հաստատված։ Հաստատումը տարածման քայլ է, ոչ թույլտվություն և ոչ փոխանցման երաշխիք։ Չորս փուլեր պետք է համընկնեն, որպեսզի փաթեթը հասնի ենթացանցի երթուղիչի հետևում գտնվող հոսթին, և յուրաքանչյուրը կարող է հաջողվել, մինչ հաջորդը ձախողվում է։ Անցեք դրանք հերթականությամբ և կանգ առեք առաջին փուլում, որը չի դիմանում։

Չորս փուլ, մեկ ձախողում

Երթուղիչը հայտարարում է նախադասությունը, tailnet-ը հաստատում է այդ հայտարարությունը, հաճախորդը ընդունում է ստացված երթուղին, և մուտքի քաղաքականությունը թույլատրում է կոնկրետ կապը։ Սրանք երեք տարբեր բաղադրիչների կողմից կայացված չորս առանձին որոշումներ են։ Ուստի հաստատված երթուղին միայն ասում է, որ ցանցն այժմ tailnet-ի երթուղային աղյուսակի մասն է։

Չորրորդ փուլը ամենահաճախ բաց թողնվածն է, քանի որ առաջին երեքը տեսանելի վիճակ են ստեղծում։ Թույլտվությունը, որը ծածկում է երթուղիչի սեփական tailnet հասցեն, ինքնաբերաբար չի ծածկում դրա հետևում գտնվող մասնավոր ենթացանցը։ Դրանք տարբեր նպատակակետեր են, և քաղաքականությունը գնահատվում է յուրաքանչյուր նպատակակետի համար առանձին։

Linux-ում երրորդ փուլն ունի նաև լռելյայն վարք, որը զարմացնում է մարդկանց՝ ենթացանցի երթուղիների ընդունումը կամընտիր է։ Մի քանի գրաֆիկական հաճախորդ լռելյայն ընդունում են հայտարարված երթուղիները, ուստի խառը պարկը կարող է ցույց տալ մեկ ձախողվող մեքենա, մինչ մյուսները աշխատում են։

Հաստատեք կարգավորումը ձախողվող մեքենայի վրա՝ պլատֆորմ ենթադրելու փոխարեն։ Երթուղին երբեք չի եղել աշխատող մեքենաների բացակայող մասը, ուստի թող նրանք ապացուցեն, որ tailnet-ի կողմը առողջ է։ Tailscale-ի ենթացանցի երթուղիչների փաստաթղթերը ծածկում են հաստատումը, հաճախորդի երթուղիների ընդունումը և քաղաքականության փուլը։

Ստուգեք երթուղին այնտեղ, որտեղ աշխատում է հաճախորդը

Սկսեք ձախողվող հաճախորդից, ոչ թե երթուղիչից։ Հաստատեք, որ երթուղին առկա է և որ հաճախորդի կարգավորումն ընդհանրապես թույլ է տալիս ընդունել երթուղիներ։

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Առաջին հրամանը ցույց է տալիս զուգընկերների ցանկը և արդյոք ենթացանցի երթուղիչը հասանելի է, երկրորդը տպում է հաճախորդի կարգավորումները՝ ներառյալ երթուղու ընդունման դրոշը, իսկ երրորդը հարցնում է միջուկից, թե որ ինտերֆեյսը կօգտագործի ենթացանցում իրական հոսթի համար։ Եթե այդ վերջին հրամանը նշում է ֆիզիկական ինտերֆեյսը Tailscale-ի ինտերֆեյսի փոխարեն, ապա երթուղին երբեք չի մտել աղյուսակ։ Բացակայող երթուղին հաճախորդի կողմի խնդիր է, ոչ թե հաստատման խնդիր։ Ուղղեք այն նախքան քաղաքականությանը նայելը։

Linux-ում երթուղիներ ընդունելու համար նորից միացեք դրոշով՝ ենթադրելու փոխարեն, որ այն դրված է՝ tailscale up --accept-routes։ Այլ դրոշներով միացած հաճախորդը պահում է դրանք, քանի դեռ չեն փոխվել, ուստի ստուգեք ընթացիկ կարգավորումը նախքան ևս մեկը ավելացնելը։ Առաջին հրամանի կրկնակի կատարումը փոփոխությունից հետո պետք է ցույց տա երթուղին աղյուսակում։

Ապացուցեք փոխանցումը և վերադարձի ուղին

Հաստատումը չի կարգավորում երթուղիչը փաթեթներ փոխանցելու համար, և չի կազմակերպում պատասխանը։ Երկուսն էլ հոսթի մակարդակի հարցեր են երթուղիչի LAN կողմում։ Փորձարկեք դրանք երթուղիչի վրա, ոչ թե հաճախորդի։

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Առաջին հրամանը պետք է հաղորդի 1, այլապես միջուկը կգցի փոխանցված փաթեթը։ Երկրորդը ցույց է տալիս՝ արդյոք ենթացանցի երթուղու քողարկումը վերագրում է աղբյուրը, ինչը լռելյայն վարքն է և սովորաբար այն, ինչ ուզում եք։ Երրորդը ցույց է տալիս՝ արդյոք հարցումը հասնում է նպատակակետին և ինչ-որ բան վերադառնում է՝ պատասխան չունեցող հարցումը վերադարձի ուղու խնդիր է, ոչ թե հաստատման։ Կարդացեք երեք արդյունքները միասին նախքան դրանցից որևէ մեկը փոխելը։

Եթե քողարկումն անջատված է, նպատակակետ ցանցին պետք է երթուղի դեպի tailnet-ի հասցեները, և արանքում յուրաքանչյուր թռիչք պետք է իմանա այդ մասին։ Քողարկումը նորից միացնելը ավելի արագ լուծում է մեկ ծառայության համար, բայց այն գնով, որ հաճախորդի բնօրինակ հասցեն թաքցվում է նպատակակետից։ Այդ փոխանակումը կարևոր է, երբ նպատակակետը գրանցում է աղբյուրի հասցեները աուդիտի համար, ուստի որոշեք գիտակցաբար՝ միջադեպի ընթացքում դրոշը շրջելու փոխարեն։ Փաստաթղթավորեք, թե որ տարբերակն ընտրեցիք, քանի որ հաջորդ մարդը կտեսնի երկու վարքից միայն մեկը։

Կարդացեք ռեսուրսի մուտքի կանոնը

Երթուղին առկա է և փոխանցումն ապացուցված, ուստի մնացած կասկածյալը քաղաքականությունն է։ Կարդացեք թույլտվությունը, որը պետք է թույլատրի կապը, և ստուգեք դրա նպատակակետը, ոչ միայն աղբյուրը։ Հաճախորդի ինքնությունը նույնպես պետք է համապատասխանի քաղաքականության ընտրիչին, ուստի գրանցեք այն նույն մեքենայից, որը ձախողվում է։

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Կարգավիճակի ելքը նույնականացնում է հաճախորդի սեփական հասցեները և զուգընկերներին, որոնց նա տեսնում է, և դրա հետ պետք է համապատասխանի քաղաքականության աղբյուր-ընտրիչը։ tailscale ping ապացուցում է tailnet-ի ուղին մինչև ենթացանցի երթուղիչը ինքը՝ այն լուծում է զուգընկերների անուններ և tailnet հասցեներ, ոչ թե հայտարարված ենթացանցի ներսում գտնվող հոսթեր։ Երրորդ հրամանը ուղարկում է սովորական ICMP արձագանք ենթացանցի երթուղով, ուստի դրա արդյունքը նկարագրում է նպատակակետը, ոչ թե երթուղիչը։ tailnet մակարդակի մերժումը սովորաբար վերադառնում է որպես մերժում, մինչ դուրս եկած և երբեք չվերադարձող փաթեթը թայմաութի է հանգեցնում։

Ձախողվող անունը տարբեր հարց է, քան ձախողվող հասցեն՝ լուծեք հոսթը ուղղակիորեն նախքան երթուղին մեղադրելը։ Գրեք թույլտվությունը ըստ ռեսուրսի իրական պահանջի, ոչ թե ամբողջ ենթացանցի։ Ամբողջ /24-ը բացելը, որպեսզի մեկ հավելված աշխատի, այն ճանապարհն է, որով նեղ հարցումը դառնում է լայն թույլտվություն, որը հետո ոչ ոք չի համարձակվում հեռացնել։

Եթե նպատակը ինտերնետ ելքն էր, ոչ թե մասնավոր ենթացանց, ճիշտ բաղադրիչը ելքի հանգույցն է, ոչ թե ենթացանցի երթուղիչը, և քաղաքականությունն ու երթուղավորումը տարբերվում են համապատասխանաբար։ Ստուգեք այդ որոշումը նախքան թույլտվությունը լայնացնելը։ Ելքի հանգույցը փոխում է լռելյայն երթուղին՝ ենթացանցի երթուղիչը միայն հայտարարում է նախադասություն։