OpenVPN auth-nocache՝ ինչ է լինում հաջորդ մուտքի ժամանակ

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

Որտեղի՞ց պետք է գա հավատարմագրերի երկրորդ հավաքածուն

OpenVPN-ը auth-nocache-ը կիրառում է auth-user-pass-ի և askpass-ի հավաքած գաղտնիքներին․ օգտագործվելուց հետո գործընթացը դեն է նետում դրանք՝ հաջորդ ձեռքսեղմման համար պահելու փոխարեն։ Վերաբանակցումը գալիս է ժամաչափով՝ լռելյայն ժամը մեկ անգամ, ուստի երկրորդ հարցումը հասնում է այն բանից շատ հետո, երբ գաղտնաբառը մուտքագրողը վաղուց գնացել է։ Այդ բացը ողջ պատմությունն է։ Քեշը միացված թողնելու դեպքում հաճախորդը վերախաղարկում է պահված պատճենը՝ ոչ մեկին չհարցնելով․ քեշն անջատելու դեպքում նա պետք է գաղտնիքը գտնի այլ տեղ կամ ձախողվի։

Ուստի թվարկեք բոլոր տեղերը, որտեղից այդ պահին կարող է գալ գաղտնիքը, և ազնիվ եղեք, թե դրանցից որոնք են գոյություն ունենում հոսթում։ Տերմինալի մոտ գտնվող մարդը, ֆայլ, որը կարող են կարդալ auth-user-pass-ը կամ askpass-ը, կամ սերվերի տրամադրած սեսիայի թոքենը երեքն են, որոնք այստեղ նշանակություն ունեն։ Եթե դրանցից ոչ մեկը հասանելի չէ, վերաբանակցումը ձախողվում է փոփոխությունից մեկ ժամ անց, ոչ թե այն պահին, երբ դուք այն կատարեցիք։

Երեք ձև, երեք ձախողման կետ

Սեղանային հաճախորդը, որի առջև մարդ կա, մեղմ դեպքն է․ հարցումը վերադառնում է, ինչ-որ մեկը նորից մուտքագրում է գաղտնաբառը, և գինը ուշադրությունն է։ Տերմինալ չունեցող OpenVPN գործարկող ծառայությունը, կոնտեյները կամ երթուղիչը կոշտ դեպքն է, քանի որ պատասխանող չկա, և այն վերամիացումը, որ նախկինում լուռ էր, հիմա ավարտում է թունելը։ Հիբրիդը գտնվում է երկուսի միջև և վարվում է սեղանային դեպքի պես, մինչև անհետանա այն սեսիան, որը կարող էր պատասխանել հարցմանը։ Նրանց չի բաժանում այն, թե արդյոք GUI է տեղադրված, այլ այն, թե արդյոք վերաբանակցման պահին գոյություն ունի հավատարմագրերի աղբյուր։

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

Հրահանգ թե դրոշակ․ ընտրեք մեկը և իմացեք, թե որն եք օգտագործել

Պրոֆիլի ներսում auth-nocache-ը առանձին տող է․ այն կանչում, որը բացահայտ նշում է պրոֆիլը, այն այդ հրամանի տողի դրոշակն է, և OpenVPN-ի ձեռնարկը թվարկում է երկու ձևերը։ Երկուսն էլ նույնն են անում հավատարմագրերի պահպանման հետ, և ոչ մեկը չի դիպչում միջերեսի տեսակին կամ չի վերանորոգում նույն մատյանի անկապ նախազգուշացումը։ Տարբերությունը կայունությունն է․ դրոշակը ծածկում է միայն այդ գործարկումը, ուստի unit-ֆայլից կամ փաթաթող սկրիպտից վերագործարկված ծառայությունը այն չի ունենա, եթե փաթաթանն էլ այն չփոխանցի։

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

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

Հավատարմագրերի ֆայլը տեղափոխում է գաղտնիքը՝ այն ջնջելու փոխարեն

auth-user-pass-ը ֆայլին ուղղելը յուրաքանչյուր հետագա վերաբանակցման աղբյուր է տալիս, և նաև գաղտնաբառը դնում է մի տեղ, որը վերապրում է վերագործարկումները։ Հարցրեք, թե ով կարող է կարդալ այդ ֆայլը, կարո՞ղ է արդյոք դեմոնը դեռ կարդալ այն արտոնություններից հրաժարվելուց հետո, և ինչ է լինում, երբ ֆայլային համակարգը միացված է միայն կարդալու ռեժիմով կամ կոնտեյների տեսքը թաքցնում է ուղին։ Սկավառակի վրա գաղտնիքը և հիշողության մեջ գաղտնիքը տարբեր խնդիրներ են, և մեկի լուծումը թողնում է մյուսին իր տեղում։ Ռոտացիան այն քայլն է, որը բաց թողնվում է․ սերվերում փոխված, բայց ֆայլում չփոխված գաղտնաբառը ստեղծում է ձախողում, որը կարդացվում է որպես ցանցի խափանում։

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

Վերաբանակցման ձգումը տեղափոխում է ծախսը, չի հեռացնում

Մյուս առաջարկը reneg-sec-ի բարձրացումն է, մինչև հարցումը բավական հազվադեպ դառնա անտեսելու համար։ Դա վերաշարադրում է սեսիայի բանալիների ռոտացիայի ժամանակացույցը և նույն հավատարմագրերի խնդիրը հրում է ավելի ուշ, ավելի քիչ կանխատեսելի պահի․ այն չի ստեղծում հավատարմագրերի աղբյուր։ Ժամանակացույցով ինչ-որ պատճառով բանալիներ թարմացնող քաղաքականությունը չպետք է թուլացվի միայն գաղտնաբառ մուտքագրելուց խուսափելու համար։

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

Կառավարվող նավատորմում տեղակայման տերը պետք է կարողանա անվանել երեք բան․ որտեղից են գալիս հավատարմագրերը, որտեղ են պահվում, և ով է դրանք ռոտացնում։ Եթե այդ պատասխաններից որևէ մեկը հոսթը տեղադրող մարդն է, տարբերակն այնտեղ դեռ ապահով չէ։