OpenVPN-ը ցույց է տալիս active (exited)։ Գտե՛ք այն պատճենը, որը դուք գործարկել եք

Դուք ստուգում եք թունելը, գործարկում systemctl status openvpn-ը և ստանում active (exited)՝ առանց Main PID-ի և դատարկ պրոցեսների ցանկով։ Բնական ընթերցումն այն է, որ ծառայությունը մեկնարկել է և մեռել, ուստի բացում եք unit-ը, գտնում /bin/true-ն և եզրակացնում, որ փաթեթը կոտրված է։ Debian-ի փաթեթավորման մեջ այդ վիճակը wrapper-ն է, որն աշխատում է ինչպես նախատեսված է, և թունելը ապրում է այն instance-unit-ներից մեկում, որոնք այն գործարկում է։ Ամբողջական unit-ը երբեք չի ասի, թե որ պատճենն է այն կառուցել։

Ինչ է իրականում նշանակում active (exited)-ը այս unit-ում

Փաթեթավորված unit-ը մեկանգամյա առաջադրանք է․ նրա ExecStart-ը /bin/true է, և RemainAfterExit=yes-ն է, որ ավարտված unit-ը պահում է active (exited) վիճակում։ Հեռացրեք այդ հրահանգը, և նույն հաջող /bin/true առաջադրանքը ավարտվում է inactive (dead)-ով, որը հենց այն վիճակն է, որ մարդիկ սպասում են և հակառակ ուղղությամբ սխալ են կարդում։ Հրամանը ընդամենը տեղապահ է, և unit-ը հաշվետվություն է տալիս այն աշխատանքի մասին, որն անում են այլ unit-ներ։ Այդ դասավորության մեջ ոչինչ կոտրված չէ, և /bin/true-ն փոխարինելը փոխում է փաթեթավորման պայմանագիրը, ոչ թե թունելը։

Wrapper-ը պատվիրակում է։ Այն գործարկում է այն instance-unit-ները, որոնք տրամադրում է փաթեթի կարգավորումը կամ նրա systemd գեներատորը, դրա համար դատարկ պրոցեսների ցանկը ոչինչ չի ապացուցում թունելի մասին։ Երբ ոչ մի պատճեն ընտրված չէ, wrapper-ը միևնույն է հաջողում է և միևնույն է ոչինչ չի գործարկում։ Վիճակը պատասխանում է՝ արդյոք wrapper-ը աշխատել է, ոչ թե՝ արդյոք թունել կա։

Կարդացեք status-ի ելքի երեք տողերը, ոչ թե փակագծերում եղած բառը։ Loaded-ը նշում է այն unit ֆայլը, որը կարդացել է systemd-ը, Active-ը կրում է վերջին հաջող աշխատանքի ժամանակի դրոշմը, և բացակայող Main PID-ը համապատասխանում է ավարտված մեկանգամյա առաջադրանքի։ Այդ երեք տողերով էլ տարբերում եք այս wrapper-ը մեկնարկից մեկ վայրկյան անց ընկած ծառայությունից։

Թվարկե՛ք unit-ները նախքան status-ը նորից կարդալը

Հարցրե՛ք systemd-ին, թե ինչ կա, նախքան կհարցնեք, թե ինչ է աշխատում։ Կաղապարը կարող է տեղադրված լինել, մինչդեռ ոչ մի պատճեն ստեղծված չէ, և միայն ստեղծված unit-ն է կրում թունել։ Սկսե՛ք բեռնված հավաքածուից․

systemctl list-units 'openvpn*'

Այդ ցանկը այն է, ինչ systemd-ը բեռնել է այս պահին, և այն ամենամոտն է թունելների գույքագրմանը։ Տեղադրված unit ֆայլերը պատասխանում են այլ հարցի, և այդ ցանկը դեռ ցույց է տալիս կաղապար, երբ ոչինչ ստեղծված չէ․

systemctl list-unit-files 'openvpn*'

Կարդացե՛ք երկու ցանկերը միասին, որովհետև երկրորդում կաղապարը և առաջինում պատճենը տարբեր պատասխաններ են։ Գոյություն ունեցող կաղապարը և աշխատող պատճենը նույն փաստը չեն, և միայն երկրորդն է նշանակում թունել։ Փաթեթների դասավորությունները տարբերվում են նաև տարածումների և OpenVPN տարբերակների միջև։ Ավելի հին openvpn@ կաղապարը, առանձին client և server զույգը և տարածման wrapper-ը բոլորը կարող են օրինական լինել իրենց փաթեթում։

Հարմարվե՛ք ձեր մեքենային, ոչ թե գտած ձեռնարկին։ Ուրիշի ելքում պատճենի անունը կարող է office լինել, մինչ ձերը home կամ work է։ Փոխանցվում է մեթոդը, ոչ թե տողը։

Հետևե՛ք պատճենի անվանը մինչև այն ֆայլը, որը նա կարդում է

Upstream client կաղապարում unit-ի աշխատանքային գրացուցակը /etc/openvpn/client է, և նրա հրամանը այնտեղից վերցնում է %i.conf-ը, ուստի openvpn-client@office-ը կարդում է /etc/openvpn/client/office.conf-ը։ Հաստատե՛ք այդ քարտեզագրումը տեղադրված unit-ի վրա՝ օրինակին վստահելու փոխարեն, որովհետև ձեր կաղապարը կարող է ավելի հին լինել կամ տարածման վերաշարադրանք․

systemctl cat [email protected]

Կարդացե՛ք այդ ելքի ներքևում հայտնվող drop-in-ները, որովհետև .d/-ի տակ գտնվող ֆայլը կարող է փոխել ExecStart-ը, աշխատանքային գրացուցակը կամ կարգավորման ուղին։ office.ovpn անունով ներբեռնած պրոֆիլը այն ֆայլը չէ, որը բացում է պատճենը։ Այդ բացն է սովորական պատճառը, թե ինչու սխալը նշում է ուղի, որը երբեք չեք խմբագրել։

Պրոֆիլի ներսում հարաբերական ուղիները հաջորդ թակարդն են։ Հիմնական ֆայլը տեղափոխելը, մինչ ca, cert և key հղումները հարաբերական են մնում, բացակայող ֆայլի սխալը փոխարինում է մեկ այլ բացակայող ֆայլի սխալով։ Երկրորդը մատնանշում է ֆայլ, որի գոյության մեջ վստահ էիք, և դրա համար պրոֆիլի գրացուցակն ավելի կարևոր է, քան ֆայլի անունը։

Գործարկե՛ք այն, ապա կարդացե՛ք այդ պատճենի մատյանը

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Մեկնարկելը և միացնելը տարբեր որոշումներ են․ start-ը unit-ը գործարկում է հիմա, enable-ը կարգավորում է հաջորդ բեռնումը, և enable --now-ը երկուսն էլ անում է մեկ քայլով։ daemon-reload-ը նորից կարդում է unit-ի սահմանումները և չի վերագործարկում աշխատող պրոցեսը և չի կիրառում խմբագրված պրոֆիլ։ Պրոֆիլը փոխելուց հետո վերագործարկե՛ք պատճենը, որովհետև հենց դա է նորից կարդում ֆայլը։

Նույն թունելի վրա երկրորդ կառավարիչ մի՛ դրեք

NetworkManager-ը և OpenVPN 3 սեսիաների կառավարիչները ունեն իրենց միացման վիճակը, և նրանցից մեկի կողքին systemd պատճենը նույն թունելի վրա դնում է երկու սեփականատեր։ Ախտանիշը թունելն է, որը բարձրանում է և մի քանի վայրկյան անց փոխարինվում, կամ մեկը, որը հրաժարվում է կանգնած մնալ։ Ընտրե՛ք այն կառավարիչը, որը ձեր տարածումը փաստաթղթավորում է աշխատասեղանի համար, և սերվերում գիտակցաբար օգտագործե՛ք systemd։

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

Պատասխանե՛ք սկզբնական հարցին պատճենի անունով, նրա կարդացած ֆայլով և ձախողված մատյանի տողով։ OpenVPN-ի նշումները systemd ինտեգրման մասին նկարագրում են կաղապարի դասավորությունը և ֆայլի քարտեզագրումը, որով լուծվում է պատճենի անունը։