Նախապես ստեղծված tun OpenVPN-ում․ երկու սեփականության մոդելների համեմատում

Ինչ-որ մեկը նախապես ստեղծել է tun1-ը, պրոֆիլում գրված է dev tun1, և կապը դեռ չի միանում։ Անվան առկայությունը հոսթում գրեթե ոչինչ չի ասում, որովհետև միանալը կախված է անվանատարածքից, սարքի տեսակից, նրանից, թե ով է տիրապետում կապին և ինչ թույլատրված է դեյմոնին։ Սարքի կրկնակի օգտագործումը նաև պարտադրում է մի որոշում, որը լռելյայն կոնֆիգուրացիան թաքցնում է՝ ո՛ր բաղադրիչն է գրում հասցեներն ու երթուղիները։ Երկու կարգավորումների ձախողման ձևերը շատ ավելի են տարբերվում, քան կոնֆիգուրացիայի տողերը, այնպես որ որոշեք նախքան պրոֆիլը խմբագրելը։

Անունը միացում չէ

dev tun1-ը OpenVPN-ից պահանջում է այդ անվանված ինտերֆեյսը, և ավանդական օգտվողական տարածության կառուցումները կփորձեն բացել այն։ Եթե անունը չի հետևում սովորական tun կամ tap ձևին, ապա պրոֆիլին անհրաժեշտ է նաև համապատասխան dev-type, որովհետև տեսակը երբեք չի եզրակացվում տողից։ TAP սարքը տարբեր պիտակով TUN սարք չէ․ սխալը միացնելը կամ անմիջապես ձախողվում է, կամ ստեղծում է կապ, որը տեղափոխում է շրջանակներ, որոնք ոչ ոք չի սպասում։ Ստուգեք տեսակը ամեն ինչից առաջ, քանի որ յուրաքանչյուր հետագա ստուգում ենթադրում է, որ երկու կողմերը համաձայն են դրա շուրջ։ Այնուհետև հաստատեք, որ գործընթացը իսկապես կարող է բացել սարքը, ոչ միայն տեսնել այն։

dev tun1
dev-type tun

Ցանցային ինտերֆեյսը և /dev/net/tun-ը տարբեր օբյեկտներ են․ մեկը անվանատարածքի ներսում կապ է, մյուսը՝ սիմվոլային սարքը, որը օգտվողական տարածության ծրագիրն օգտագործում է միանալու համար։ Linux TUN/TAP փաստաթղթերը նկարագրում են այդ միացման ուղին և մշտական սարքերի սեփականության կանոնները։ Root shell-ը, որը կարող է գործարկել ip link-ը, ապացուցում է միայն, որ shell-ն ունի արտոնություններ, ոչ թե որ դեյմոնն ունի։ Սարքի հանգույցի սեփականությունը, ծառայության հնարավորությունների հավաքածուն և այն օգտվողը, ում անունից այն աշխատում է՝ բոլորը պետք է համընկնեն, մինչև բացումը հաջողվի։

Սարքը, որը գոյություն ունի և չի բացվում, սեփականության խնդիր է, ոչ թե երթուղավորման։ Վրիպազերծման ժամանակ այդպես էլ վերաբերվեք դրան, այլապես կեսօրը կանցնի երթուղային աղյուսակներ կարդալով, որոնք երբեք խնդիրը չեն եղել։

Ով է կարգավորում կապը․ սեփականության երկու մոդել

Առաջին մոդելում OpenVPN-ը կարգավորում է հասցեներն ու երթուղիները կապը բարձրացնելու մասով։ Դա լռելյայն վարքն է և ամենահեշտը պատճառաբանելու համար, որովհետև մեկ բաղադրիչ է ստեղծում վիճակը և նորից հեռացնում այն։ Երկրորդ մոդելում արտաքին կառավարիչն է տիրապետում ինտերֆեյսին, և ifconfig-noexec-ը թույլ չի տալիս OpenVPN-ին գործարկել հասցեների կարգավորման իր հրամանները և պարամետրերը փոխանցում է սկրիպտներին։ Այն ժամանակ կառավարիչն ինքը պետք է կիրառի ճիշտ տեղական և զուգընկերոջ կոնֆիգուրացիան, ինչը ավելի շատ աշխատանք է, քան ենթադրում է ընտրանքի անունը։ Երկուսի միջև ընտրությունը հարց է այն մասին, թե ով կարող է փոխել կապը, քանի դեռ այն բարձրացված է։

ifconfig-noexec-ը ծածկում է միայն հասցեները․ երթուղային աղյուսակը մնում է անձեռնմխելի, իսկ երթուղիների կարգավորումը պատկանում է route-noexec-ին։ Երկու հրահանգներին վերաբերվեք որպես առանձին կառավարման՝ առանձին տերերով, որովհետև մեկը սահմանելը և մյուսը ենթադրելը կիսակարգավորված կապերի սովորական աղբյուր է։ Յուրաքանչյուր շերտի համար ընտրեք ուղիղ մեկ տեր՝ հասցեները մեկ տեղում, երթուղիները՝ մեկ տեղում։ Ցանցային կառավարիչը և VPN օգնականը, որոնք երկուսն էլ հասցեներ են գրում, հենց այն ձևն է, որով անջատումը ջնջում է վիճակ, որի վրա մյուս կողմը դեռ հենվում է։

Ուսումնասիրեք սարքը այն անվանատարածքից, որն ունի նշանակություն

Ուսումնասիրեք սարքը այն անվանատարածքից, որտեղ աշխատում է VPN գործընթացը, ոչ թե այնտեղից, որտեղ պատահաբար գտնվում է ձեր shell-ը։ Ներքևի երկու հրամանները պատասխանում են տարբեր հարցերի, և տարբերությունը երևում է, երբ հոսթը տեսնում է ինտերֆեյս, որը կոնտեյները չի տեսնում։ Գործարկեք դրանք նշված հերթականությամբ, որովհետև երկրորդն իմաստ ունի միայն այն բանից հետո, երբ գիտեք՝ կապը ընդհանրապես գոյություն ունի՞։

ip -details link show dev tun1
ip tuntap show

Առաջին հրամանը տպում է կապն այնպես, ինչպես այն տեսնում է միջուկը՝ ներառյալ դրոշները և ինտերֆեյսի տեսակը, և այդպես եք հաստատում, որ սա հենց այն սարքն է, որը նկատի ունեիք։ Երկրորդը թվարկում է մշտական tun/tap գրառումները, որոնք գոյություն ունեն առանց որևէ գործընթացի կողմից պահվելու։ Ինտերֆեյսը, որը սպասում է իր նախատեսված տիրոջը, տարբեր իրավիճակ է, քան մեկ այլ VPN-ին միացված կենդանի թունելը, և միայն երկրորդն է բացատրում, թե ինչու է ձեր իսկ միացումը ձախողվում։ Գտեք սարքը պահող գործընթացը նախքան որևէ բան փոխելը, որովհետև մշտական գրառումն ու զբաղված ինտերֆեյսը տարբեր լուծումներ ունեն։

Բազմահերթային աջակցությունը կրիչի որոշակի դասավորություն է իր պահանջներով, ոչ թե թույլտվություն անկապ գործընթացներին մեկ ինտերֆեյս կիսելու։ Մեկ այլ տիրոջ կենդանի սեսիան համակարգման խնդիր է, և ոչ մի պրոֆիլի խմբագրում այն չի լուծում։

Կայունության երկու տեսակ

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

Հաստատեք նաև backend-ը, որովհետև նախապես ստեղծված ինտերֆեյսը ոչինչ չի ասում այն մասին, թե որ իրականացումը կբացի այն։ Համայնքային կառուցումները, որոնք կրում են ուղիղ տվյալների ուղին, կփորձեն օգտագործել այն, եթե դիզայնը այլ բան չի ասում։ Այնտեղ, որտեղ տարբերակը աջակցում է անջատիչին, disable-dco-ը փոխարենը ընտրում է օգտվողական տարածության ուղին․ ավելի հին շարժիչներն ու այլ հաճախորդները նման հրահանգ չունեն, ուստի տարբերակի պայմանը պահեք ընտրանքի կողքին՝ փոխարենը չենթադրելով, որ այն կիրառելի է։

Ինչ է կոտրվում, երբ փորձարկվում է միայն մեկնարկը

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

systemctl status openvpn-client@lab
ip -details link show dev tun1

Մեկնարկը հեշտ դեպքն է․ միավորը բարձրանում է, կապը հայտնվում է, և վիճակի ելքը նշում է բեռնված պրոֆիլի անունը։ Միացումը այն պահն է, երբ դեյմոնը բացում է սարքը, ուստի կապի ստուգումը գործարկեք այն բանից հետո, երբ միավորը հաղորդի ակտիվ լինելու մասին, ոչ թե առաջ։ Եթե կապը գոյություն ունի, մինչ վիճակը դեռ ակտիվանում է, դուք նայում եք մշտական սարքի, որին դեռ ոչ ոք չի միացել, ոչ թե աշխատող թունելի։ Անցեք իրական երթևեկություն կապով նախքան առաջ շարժվելը, որովհետև օգտագործելի երթուղի չունեցող միացված ինտերֆեյսը դեռ ձախողում է։

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

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