Ինչու Linux-ի Tailscale հաճախորդն անտեսում է հայտարարված ենթացանցային երթուղիները

52-րդ աղյուսակը հուշումն է. Linux-ի Tailscale հաճախորդը հայտարարված ենթացանցային երթուղին տեղադրում է միայն --accept-routes-ից հետո, իսկ սարքի հաստատումը առանձին դարպաս է։

Դուք Linux նոթբուքի վրա եք, tailscale status-ը թվարկում է մյուս մեքենաները, և 10.80.0.25 հասցեի NAS-ը դեռ ժամանակի սպառմամբ է ավարտվում: Tailnet-ը առողջ է, ենթացանցային երթուղիչը առցանց է, և հաճախորդի ելքի մեջ ոչինչ չի ասում, թե ինչու դրա հետևի LAN-ը հասանելի չէ: Ստորև նկարագրությունը շարժվում է այդ ախտանիշից դեպի դուրս՝ այս հաճախորդի դրոշը, ապա հայտարարումը երթուղիչի վրա, ապա հաստատումը, ապա քաղաքականությունը, և միայն դրանից հետո ինքը նպատակակետը: Յուրաքանչյուր դարպաս ձախողվում է նույն ժամանակի սպառմամբ, ուստի հերթականությունն ավելի կարևոր է, քան հրամանները:

Ինչից է հրաժարվում Linux-ի հաճախորդը տեղադրել

Linux-ի Tailscale հաճախորդները չեն ընդունում հայտարարված ենթացանցային երթուղիներ, եթե դուք չխնդրեք: Առանց այդ կարգավորման հաճախորդը միանում է tailnet-ին և հասնում հավասարակից հասցեներին, մինչդեռ երթուղիչի հայտարարած յուրաքանչյուր նախածանց մնում է չօգտագործված: Կանխադրվածը դիտավորյալ է, և դրա համար ախտանիշը նման է կոտրված երթուղիչի, ոչ թե տեղական որոշման:

Այստեղ երկու տարբեր բաներ են կոչվում երթուղավորում, և դրանցից միայն մեկն է ձերը: Երթուղիչը նախածանց է հայտարարում tailnet-ում. ձեր մեքենան որոշում է՝ տեղադրե՞լ այն: Ցանկացածի ձախողումը տալիս է նույն ժամանակի սպառումը, ուստի գուշակելը կեսօր է վատնում: Պարզեք, թե որ կողմն է հրաժարվում, նախքան ինչ-որ բան խմբագրելը:

Միացրեք երթուղիների ընդունումը այս մեքենայի համար

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

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

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

Ավելի հին հաճախորդները նույն նախապատվությունը տրամադրում են որպես մուտքի հրամանի դրոշ, ուստի sudo tailscale up --accept-routes-ը պահուստային տարբերակն է, երբ tailscale set-ը բացակայում է: Օգտագործեք այն՝ երթուղիները ձեռքով խմբագրելու փոխարեն, քանի որ դեմոնը վերագրում է իր աղյուսակը, և ձեր խմբագրումը անհետանում է հաջորդ վերամիացման ժամանակ: Ստուգեք տարբերակը նախքան հին գրառումից հրաման պատճենելը:

Ստուգեք հայտարարումը և հաստատումը առանձին

Ենթացանցային երթուղիչի վրա նախածանցը պետք է հայտարարվի, և միջուկը պետք է փոխանցի փաթեթները միջերեսների միջև: Առանց փոխանցման հայտարարումը տալիս է հաստատված երթուղի, որը լուռ գցում է երթևեկությունը, և սա ամենատարածված կիսատ կարգավորումն է:

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Համեմատեք հայտարարված նախածանցը այն հասցեի հետ, որին իրականում փորձում եք հասնել՝ տառ առ տառ: 10.70.0.0/24 հայտարարող երթուղիչը ոչինչ չի ասում 10.80.0.25 հասցեի NAS-ի մասին, և անհամապատասխանությունն անտեսանելի է ցանկացած կարգավիճակի ելքում, քանի որ երկու թվերն էլ հավասարապես հավանական են թվում: Կոտրված երթուղու մասին հաշվետվությունների մեծ մասն ավարտվում է այստեղ: Ուղղեք հայտարարումը նախքան ներքևում ինչ-որ բանի դիպչելը:

Հաստատումը հաջորդ դարպասն է, և հեշտ է բաց թողնել, երբ երթուղիչը կարգավորվել է shell-ից: Հայտարարումը պետք է միացված լինի այդ սարքի համար ադմինիստրացիոն վահանակում, նախքան այլ մեքենաներ կկարողանան օգտագործել այն: Հաճախորդի վրա երթուղիների ընդունումը ոչինչ չի հաստատում և չի շրջանցում ոչ մի մուտքի կանոն:

Փորձարկեք մասնավոր հասցեն մինչև հոսթի անունը

Երթուղիչի սեփական tailnet հասցեին հաջող միացումը ապացուցում է, որ tailnet-ը աշխատում է, ինչը դուք արդեն գիտեիք: Օգտակար փորձարկումը ձեզ իրոք անհրաժեշտ ծառայությունն է՝ նախ մասնավոր հասցեի դեմ, որպեսզի DNS-ի ձախողումը չկարողանա ներկայանալ որպես երթուղավորման ձախողում:

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

Եթե հասցեն պատասխանում է, իսկ հոսթի անունը՝ ոչ, դուք անունների լուծման խնդիր ունեք և պետք է դադարեք այն դիտարկել որպես երթուղու խնդիր: Եթե ոչ մեկը չի պատասխանում, վերադարձեք մեկ բաժին և հաստատեք, որ հայտարարումը ծածկում է հասցեն: Երկու ձախողումները հավելվածից նույնն են երևում և ուղղվում են տարբեր տեղերում:

Մեկ տեղական ստուգում արժե անել նախքան tailnet-ին մեղադրելը: Երբ ձեր ընթացիկ LAN-ը օգտագործում է նույն նախածանցը, ինչ հեռավոր ենթացանցը, միջուկը նախընտրում է ուղղակիորեն միացված երթուղին, և երթևեկությունը երբեք չի հեռանում մեքենայից. դա տեղի է ունենում, երբ տունը և գրասենյակը երկուսն էլ ընտրում են 192.168.1.0/24:

Ինչու հաճախորդի դրոշը երթուղիչի կարգավորում չէ

Սրանք տարբեր պահանջներով տարբեր դերեր են, և հաճախորդի դրոշը երթուղիչի վրա պատճենելը այն ձևն է, որով աշխատող tailnet-ը հանգույց է ձեռք բերում: Երթուղիներ հայտարարող մեքենային պետք է փոխանցում, փոխանցվող երթևեկությունը թույլատրող firewall-ի կանոններ և որոշում, թե որ նախածանցերն է հայտարարում: Դրանցից ոչինչ չի ենթադրվում --accept-routes-ից:

Ենթացանցային երթուղիչների փաստաթղթերը զգուշացնում են չմիացնել երթուղիների ընդունումը ավելորդ երթուղիչների վրա, որոնք մեկ նախածանց են հայտարարում, քանի որ սպասող հանգույցը կարող է արդեն տեղական երթևեկությունը դուրս մղել ակտիվ հանգույցով: Եթե աշխատեցնում եք HA զույգ, դիտարկեք դա որպես նախագծային սահմանափակում, ոչ թե ծանոթագրություն, և որոշեք, թե որ հանգույցն է տիրում նախածանցին, նախքան այն երկուսի վրա հաստատելը: Մեկ երթուղիչի դեպքում նույն զգուշացումը կարդացվում է որպես հիշեցում, որ ընդունումը պատկանում է հաճախորդներին, ոչ թե հայտարարող մեքենային: Գրեք, թե որ դարպասն էր փակ:

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

Առնչվող հոդվածներ