OpenVPN ծառայությունը կանգ է առնում մասնավոր բանալու գաղտնաբառը հարցնելիս․ ինչպես ուղղել
Ծառայությունը տերմինալ չունի, ուստի գաղտնագրված բանալուն անհրաժեշտ են askpass և ընթեռնելի ֆայլ։ Առանձնացրեք բանալու գաղտնաբառը սերվերում մուտքից և ստուգեք unit-ը։
OpenVPN տեղական մեքենայում հարցնում է մասնավոր բանալու գաղտնաբառը, ուստի աշխատող մուտքի ֆայլը երբեք չի պատասխանում դրան։ Ծառայության մեջ տերմինալ չկա մուտքագրելու համար, և գործարկումը կա՛մ կախվում է, կա՛մ ձախողվում է մատյանում գրառմամբ, որը նշում է մուտքագրումը, այլ ոչ պատճառը։ Այստեղ երկու գաղտնիք կա, և յուրաքանչյուրին պետք է իր ընթեռնելի աղբյուրը մինչև unit-ի վերագործարկումը։ Ներքևի ընթացքը բաժանում է դրանք, ապա ստուգում է այն ինքնությունը, որն իրականում բացում է յուրաքանչյուր ֆայլ։
Տարբերակեք երկու հարցումները
Բանալու գաղտնաբառը վերծանում է տեղական մասնավոր բանալին, իսկ հաշվի տվյալները նույնականացնում են սեսիան սերվերի հետ։ Դրանք գալիս են տարբեր տեղերից, ձախողվում են տարբեր պահերին և տալիս են տարբեր հաղորդագրություններ։ Դրանք շփոթելը մարդկանց ուղարկում է գաղտնաբառի վերականգնում փնտրելու, մինչդեռ հաշիվն ընդհանրապես ներգրավված չէր։ Կարդացեք հարցման տեքստը նախքան որևէ ընտրանք փոխելը, որովհետև ձևակերպումը միակ վստահելի ակնարկն է, թե որ գաղտնիքն է բացակայում։
Community OpenVPN 2.x-ում askpass նշում է ֆայլ, որի առաջին տողում բանալու գաղտնաբառն է, իսկ auth-user-pass նշում է ֆայլ, որտեղ օգտանունը մի տողում է, իսկ գաղտնաբառը՝ հաջորդում։ Ֆայլերից ոչ մեկը չի բավարարում մյուս ընտրանքին։ Աշխատասեղանի հավելվածը կամ NetworkManager-ի պրոֆիլը կարող են երկուսն էլ պահել իրենց գաղտնիքների պահոցում, որը հրամանի տողի հաճախորդը երբեք չի կարդում, ուստի նշեք, թե որ հաճախորդն եք կարգավորում, նախքան որևէ ուղի գրելը։
Ուղղեք երկու ընտրանքները ընթեռնելի ֆայլերին
Պրոֆիլը, որին պետք են երկու մուտքագրումները, վերջում ունենում է երեք ֆայլի հղում՝ գաղտնագրված բանալին, այն բացող գաղտնաբառը և մուտքի զույգը։ Ավելացրեք դրանք՝ չդիպչելով CA-ին և ինքնության ստուգումներին, որովհետև դրանք որոշում են, թե ով է սերվերը, և այս խնդրի մասը չեն։ Եթե տեղակայումն ընդհանրապես չի օգտագործում հաշվի տվյալներ, ապա auth-user-pass ավելացնելը ստեղծում է մուտքագրում, որը ոչ ոք չի կարող տրամադրել։
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authԱռանց արգումենտի ընտրանքները այլ կերպ են վարվում, քան ուղի ունեցողները, և ծառայությունում այդ տարբերությունը կարևոր է։ Առանց արգումենտի askpass-ը դեռ կարդում է վահանակից, իսկ միայն օգտանուն պարունակող auth-user-pass ֆայլը դեռ թողնում է գաղտնաբառի հարցումը սպասելիս։ Երբ հաճախորդը դառնում է դեմոն, այն ընդհանրապես չի կարող տերմինալից մուտքագրում խնդրել, ուստի այսպես կարգավորված ծառայությունը չի բարձրանում։
Բացարձակ ուղիները վերացնում են աշխատանքային պանակի հարցը, բայց հասանելիություն չեն տալիս։ Հետո գալիս են սեփականությունը, ռեժիմը և անցումը, և երեքն էլ ստուգվում են այն հաշվի նկատմամբ, որի տակ աշխատում է գործընթացը։
Կարդացեք unit-ի կազմաձևը մինչև պրոֆիլը
Թե որ կազմաձևը կբեռնի օրինակը, որոշում է unit-ը, այլ ոչ այն ֆայլը, որը խմբագրում էիք։ Կարդացեք նրա հրամանի տողը և բոլոր drop-in-ները, ապա հետևեք աշխատանքային պանակից մինչև իրականում օգտագործվող պրոֆիլը։ Այլ .ovpn ֆայլում ավելացված գաղտնաբառի հղումը այս օրինակի համար ոչինչ չի փոխում։
Երեք միայն-ընթերցման հրամաններ պատասխանում են դրա մեծ մասին։ Առաջինը տպում է unit-ը և բոլոր drop-in-ները, երկրորդը՝ ինքնությունը և գործընթացը սահմանափակող sandbox-ի կարգավորումները, երրորդը՝ ինչի՞ց իրականում դժգոհեց վերջին գործարկումը։ Օգտագործեք հոսթում գոյություն ունեցող օրինակի անունը՝
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bՈւշադրություն դարձրեք ProtectHome-ին և պրոֆիլի սեփական user, group և chroot ընտրանքներին։ Տնային պանակի տակ գտնվող ֆայլը կարող է ընթեռնելի լինել ձեր shell-ում և անտեսանելի՝ ծառայության ներսում, երբ տնային պանակները թաքցվում են։ Այն հաշիվը, որով systemd-ն սկսում է, միշտ չէ, որ վերջում բանալին բացող հաշիվն է։
Ապացուցեք, որ գործարկման ինքնությունը կարող է բացել երկու ֆայլերը
Ռեժիմը կարդալը բավարար չէ, որովհետև ուղու յուրաքանչյուր պանակ պետք է անցանելի լինի նույն ինքնության համար։ Անցեք ուղին բաղադրիչ առ բաղադրիչ, ապա փորձարկեք բացումը որպես այն հաշիվ, որն օգտագործում է գործընթացը։ root-ին պատկանող և 600 ռեժիմով ֆայլը աշխատում է միայն այնքան ժամանակ, քանի դեռ գործընթացը root է, ինչը ճիշտ չէ շատ պրոֆիլների կատարած արտոնությունների իջեցումից հետո։ Երկու հրաման ծածկում են անցումը և բացումը՝
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableԱռաջին հրամանը տպում է յուրաքանչյուր բաղադրիչի ռեժիմը և ձախողվում այնտեղ, որտեղ հաշիվը չի կարող անցնել, իսկ երկրորդը պատասխանում է միակ կարևոր հարցին՝ կարո՞ղ է գործարկման ինքնությունը բացել ֆայլը ընթերցման համար։ Ոչ մեկը չի տպում ֆայլի բովանդակությունը, և դա է իմաստը, երբ ֆայլը գաղտնաբառ է պարունակում։ Կրկնեք փորձարկումը մուտքի ֆայլի համար, որովհետև երկուսը հաճախ պահվում են տարբեր սեփականությամբ։
Եթե գործընթացն օգտագործում է chroot կամ սահմանափակ namespace, գործարկեք նույն փորձարկումը այդ տեսքի ներսից, այլապես պատասխանը նկարագրում է սխալ ֆայլային համակարգ։ Թաքնված տնային պանակի տակ պահված գաղտնաբառը սովորական օրինակ է այն փորձարկման, որն անցնում է unit-ից դուրս և ձախողվում ներսում։
Ստուգեք առաջին գործարկումը, ապա վերակապակցումը
Գործարկեք օրինակը մեկ անգամ և կարդացեք առաջին ձախողումը, ոչ թե վերջինը։ Բացակայող մուտքային ֆայլը, բանալու վերծանման ձախողումը և սերվերի կողմից AUTH_FAILED-ը երեք տարբեր իրադարձություններ են՝ երեք տարբեր ուղղումներով։ Թույլտվությունների նախազգուշացումը ուղղելը ոչինչ չի ապացուցում այն մասին՝ արդյոք բանալին բացվել է։
Մատյանի տողը ասում է, թե երեքից որն ունեք։ Ուղղումը բխում է նրանից, թե որ մուտքագրումը ձախողվեց՝
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Ապա փորձարկեք այն կյանքի ցիկլը, որն իսկապես պետք է ձեզ՝ գործարկում բեռնման պահին և ցանկացած աջակցվող վերակապակցում, ոչ միայն ձեռքով գործարկում ձեր shell-ից։ auth-nocache-ի դեպքում մուտքագրումները դեն են նետվում առաջին օգտագործումից հետո, ուստի ավելի ուշ վերակապակցումը դեռ ընթեռնելի աղբյուրի կարիք ունի։ Աշխատասեղանի մուտքի պահին բացվող բանալիների շարանը հասանելի չէ այն ծառայությանը, որը սկսել է նախքան որևէ մեկի մուտքը, և դա է սովորական պատճառը, թե ինչու ձեռքի փորձարկումն անցնում է, իսկ վերագործարկումը ձախողվում։ Եթե առաջին գործարկումը հաջողվում է, իսկ ավելի ուշ վերակապակցումը ձախողվում, կարդացեք մատյանը վերակապակցման իրադարձության համար նախքան թույլտվությունները կրկին փոխելը։
Գաղտնաբառը բանալու կողքին պահելը նվազեցնում է այն, ինչ գաղտնագրումը տալիս է ձեզ, ուստի սահմանափակեք այդ ֆայլը և դրա պահուստները։ Բանալու գաղտնաբառը հեռացնելը դիտարկեք որպես առանձին հավատարմագրային որոշում, այլ ոչ բացակայող մուտքագրման ուղղում։ Մարդկային հաստատումից կամ ինտերակտիվ MFA-ից կախված տեղակայմանը պետք է իր աջակցվող գործակալը կամ կառավարման ինտեգրումը, իսկ մշտապես պահված մեկանգամյա կոդը համարժեք փոխարինում չէ։