client-config-dir-ը անտեսվում է, երբ OpenVPN-ը դարձավ ծառայություն
Հարաբերական client-config-dir-ը լուծվում է դեմոնի աշխատանքային պանակի նկատմամբ։ Կարդացեք unit-ը, ստուգեք ուղու թույլտվությունները, ապա հաստատեք որոնումը մատյանում։
Թունելը բարձրանում է, և հաճախորդը միանում է, բայց ֆիքսված հասցեն և այն ուղիները, որոնք դուք սահմանել էիք այդ մեկ օգտատիրոջ համար, բացակայում են։ Մատյանում “file not found” գրված չէ, և հենց դա է մարդկանց ուղարկում վկայագրերը վերստեղծելու։ Այս դեպքերի մեծ մասում դեմոնը աշխատում է այլ պանակից, քան այն shell-ը, որտեղ փորձարկում էիք, և client-config-dir երբեք չլուծվեց այնպես, ինչպես դուք ենթադրել էիք։ Ուղղումը ուղու ուղղում է, ոչ թե հավատարմագրերի վերակայում։
Կարդացեք unit-ը նախքան կոնֆիգուրացիային դիպչելը
Սկսեք այն գործընթացից, որն իրականում աշխատում է, ոչ թե այն ֆայլից, որը խմբագրել եք։ Հարցրեք systemd-ին գործարկման տողը, աշխատանքային պանակը և այն հաշիվը, որին այն իջնում է։ Այդ երեք պատասխանները բացատրում են այս դասի խափանումների մեծ մասը.
systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectoryԴատարկ WorkingDirectory նշանակում է, որ unit-ը սկսվում է /-ում, ուստի հարաբերական client-config-dir ccd փնտրվում է /ccd-ում։ Այդ պանակը գրեթե երբեք չի լինում, և դեմոնը դրա բացակայությունը ճակատագրական չի համարում։
Համեմատեք դա ձեր փորձարկման ժամանակ օգտագործած ինտերակտիվ գործարկման հետ, որտեղ ձեր shell-ի ընթացիկ պանակը հավանաբար կոնֆիգուրացիայի պանակն էր։ Նույն ֆայլը, նույն բանալի բառերը, երկու տարբեր արդյունք։
Ինչի՞ նկատմամբ է լուծվում հարաբերական ուղին
Բանալի բառը լուծվում է գործընթացի աշխատանքային պանակի նկատմամբ այն պահին, երբ օգտագործվում է ընտրանքը։ Դա չի նշանակում “այն կոնֆիգուրացիայի ֆայլի կողքին, որը փոխանցել եմ --config-ով”։ OpenVPN-ը սիրով կկարդա կոնֆիգուրացիա բացարձակ ուղուց և միևնույն է հարաբերական արժեքները կլուծի այլ տեղ, և հենց դա է այստեղ թակարդը։ OpenVPN 2.6-ի ձեռնարկը կանոնը նշում է --client-config-dir-ի տակ և կրկին --cd-ի տակ։
cd բանալի բառը փոխում է այդ համատեքստը մինչև այլ ֆայլերի կարդալը, ուստի unit-ը, որը սահմանում է cd /etc/openvpn/server և ապա client-config-dir ccd, լուծվում է /etc/openvpn/server/ccd-ի։ Եթե ավելացնեք cd, ստուգեք հրահանգների հերթականությունը և հիշեք, որ այն ազդում է նույն ֆայլի յուրաքանչյուր այլ հարաբերական հղման վրա։
Անցեք ուղին դեմոնի հաշվով
Ուղին կարող է ճիշտ լինել և միևնույն է անընթեռնելի։ Արտոնությունների իջեցումից հետո դեմոնն այլևս root չէ, ուստի յուրաքանչյուր ծնող պանակ այդ հաշվի համար պահանջում է որոնման թույլտվություն, և հաճախորդի ֆայլն ինքը՝ ընթերցման թույլտվություն։ Ծնող պանակի վրա մեկ բացակայող կատարման բիթը բավական է ֆայլը թաքցնելու համար, և սխալը երևում է միայն որպես հաճախորդ, որը լուռ ստանում է լռելյայն լողավազանը։
namei-ը տպում է յուրաքանչյուր բաղադրիչի թույլտվությունը հերթով, ինչը ավելի արագ է, քան պանակները մեկ առ մեկ ստուգելը.
namei -l /etc/openvpn/server/ccd/client1Ապա փորձարկեք ընթերցումը որպես ծառայության հաշիվ, ոչ որպես ինքներդ ձեզ.
runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readableԵթե unit-ը օգտագործում է chroot, պանակը պետք է գոյություն ունենա բանտի ներսում, և կոնֆիգուրացիայի ուղին մեկնաբանվում է chroot-ը կիրառելուց հետո։ Հոսթի վրա բանտից դուրս գտնվող ֆայլը ներսից անտեսանելի է։
Հաստատեք որոնումը՝ ոչ թե գուշակեք
Բարձրացրեք մատյանի մակարդակը մեկ վերագործարկման համար և կարդացեք, թե ինչ է ասում սերվերը հաճախորդին բնորոշ ընտրանքների մասին։ verb 4-ում դեմոնը հաղորդում է ներմուծված յուրաքանչյուր հաճախորդի կոնֆիգուրացիան, ուստի բացակայող տողը ուղղակի ապացույց է, որ այդ կապի համար ոչ մի ֆայլ չի կարդացվել։
openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccdԳործարկեք դա առաջին պլանում ազատ պորտի վրա և միացրեք մեկ հաճախորդ։ Դա ամբողջությամբ հանում է systemd-ին պատկերից. եթե վերագրանցումները երևում են այստեղ և ոչ ծառայության տակ, տարբերությունը unit-ի համատեքստն է, ոչ ֆայլը։
Որոշեք, թե ինչ պետք է տեղի ունենա, երբ ոչ մի ֆայլ չհամապատասխանի։ Առանց ccd-exclusive հաճախորդը ընդունվում է միայն գլոբալ լողավազանի կարգավորումներով, և դա է վերը նկարագրված լուռ խափանումը։ Դրա հետ բացակայող ֆայլը դառնում է մերժված կապ, և այդ մերժումը ավելի հեշտ է նկատել, բայց ավելի դժվար վրիպազերծել ծանրաբեռնվածության տակ։
Ուղղեք, վերագործարկեք, ստուգեք
Կոնֆիգուրացիայում պանակը դարձրեք բացարձակ և թողեք այդպես։ Հարաբերական ուղիները անվտանգ են միայն այն դեպքում, երբ unit-ը ամրացնում է աշխատանքային պանակը, իսկ ամրացնելը լրացուցիչ շարժվող մաս է, որը ինչ-որ մեկը հետո կհեռացնի։
client-config-dir /etc/openvpn/server/ccd
ccd-exclusiveՎերագործարկեք օրինակը, նորից միացրեք մեկ հայտնի հաճախորդ և կարդացեք նրա ստացած հասցեն՝ դեպի նա ուղարկված ուղիների հետ միասին։ Եթե հասցեն համընկնում է այդ հաճախորդի ֆայլի ifconfig-push տողի հետ, որոնումը աշխատեց։ Եթե հաճախորդը դեռ ընկնում է ընդհանուր լողավազան, վերադարձեք մատյանի տողերի հաշվին. զրո ներմուծում նշանակում է, որ ուղին կամ ինքնությունը սխալ է, սխալ պարունակությամբ մեկ ներմուծում նշանակում է, որ խմբագրում եք այլ ֆայլ, քան կարդում է դեմոնը։
Հետ գնացեք՝ միասին վերականգնելով նախորդ unit-ը և կոնֆիգուրացիան, ապա վերագործարկեք։ Վկայագրերը սրա համար վերաթողարկել պետք չէ, և պանակի խնդիրը որպես հավատարմագրի խնդիր դիտելը հենց այն ուղին է, որով հինգ րոպեի ուղղումը դառնում է սպասարկման պատուհան։