OpenVPN-ը չի գտնում ca.crt-ն, թեև պրոֆիլը բեռնվում է

Ծառայությունը սկսվում է, կարդում պրոֆիլը առանց բողոքների և հետո մահանում է մի տողում, որը կապ չունեցող է թվում՝ այն չի կարող բացել ca.crt-ը։ Վկայականում ոչինչ չի փոխվել, և unit ֆայլում պրոֆիլի ուղին բացարձակ է։ Հենց այդ համակցությունն է հուշումը։ Ձեր տված ուղին տեղորոշում է մեկ ֆայլ, իսկ այդ ֆայլի ներսի անունները լուծվում են բոլորովին այլ տեղ, ուստի ամբողջովին որակավորված թվացող գործարկումը կարող է դեռ կարդալ իր բանալիները մի պանակից, որը ոչ ոք չի նախատեսել։

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

Պրոֆիլի ուղին բազային պանակ չէ

Պատկերացրեք գործընթաց, որը սկսվում է /tmp-ում և ստանում /etc/vpn/prod/tenant-a.ovpn-ը։ Այդ պրոֆիլի ներսում ca ca.crt տողը նշում է հարաբերական ուղի։ Պրոֆիլը գտած արգումենտում ոչինչ չի վերագրում այդ անունը, ուստի գործընթացը փնտրում է /tmp/ca.crt-ը և հաղորդում բացակայող ֆայլի մասին։

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

Ինչ է առանձնացնում ձեռնարկը՝ --config և --cd

OpenVPN 2.6-ի ձեռնարկը նկարագրում է երկու տարբեր ընտրանք։ Մեկը բեռնում է կոնֆիգուրացիայի ֆայլ։ Մյուսը փոխում է գործընթացի պանակը նախքան կոնֆիգուրացիայի, բանալու, սկրիպտի և այլ ֆայլերի ընթերցումը, և պահանջում է բացարձակ պանակ՝ առանց ընթացիկին հղումի։

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

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

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

Ծառայությունը սկսվում է այլ տեղ

Պրոֆիլի պանակում ինտերակտիվ shell-ը ոչինչ չի ապացուցում փաթեթավորված unit-ի մասին։ Կառավարիչները սահմանում են իրենց աշխատանքային պանակը, և փաթաթող սկրիպտը կարող է կրկին փոխել այն նախքան բինարի գործարկումը։ Ձախողվող unit-ը միակ գործարկումն է, որի մասին արժե մտածել։

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

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

Փնտրմանից հետո՝ թույլտվություններ, chroot և ավազարկղ

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

Երեք սովորական տարբերակ նույն սխալն են տալիս։ Ֆայլը ընթեռնելի է միայն root-ի համար, մինչդեռ ծառայությունը բացելուց առաջ հրաժարվում է արտոնություններից։ Unit-ը սահմանում է ֆայլային համակարգի պաշտպանիչ տեսք, որը չի ներառում պրոֆիլի պանակը։ Դեմոնը աշխատում է chroot-ով, ուստի հոսթում գոյություն ունեցող ուղին այդ տեսքի ներսում գոյություն չունի։

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

Ապացուցեք ուղղումը ձեր իսկ գործարկումով

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

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

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

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