OpenVPN-ի վկայականի ֆայլ, թե՞ կառավարման socket. ինչը սկրիպտավորել

Սկրիպտը, որը գործարկում է OpenVPN-ը և երբեք չի միանում, սովորաբար ցանցի խնդիր չէ. հաճախորդը նստած է հարցման առաջ՝ առանց տերմինալի, որի վրա այն պատկերեր։ OpenVPN-ն ունի ճիշտ երկու աջակցվող եղանակ այդ հարցմանը առանց մարդու պատասխանելու համար՝ auth-user-pass-ի հետևում գտնվող վկայականի ֆայլը և կառավարման socket-ը, և դրանք փոխարինելի չեն։ Ֆայլը արժե մեկ հրահանգ և պատասխանում է մեկ հարցման. socket-ը պատասխանում է յուրաքանչյուր հարցման և ցանկացած բանի, որը կարող է բացել loopback պորտ, տալիս է չնույնականացված կառավարման ուղի։ Դրանցից որը պատկանում է ձեր տեղակայմանը, կախված է նրանից, թե որ հարցումն է իրականում արգելափակում, և թե որ գաղտնիքը կարող եք թույլ տալ հանգիստ թողնել։

Անվանեք հարցումը, նախքան մեխանիզմ ընտրելը

Չորս հարցում տերմինալում նույն տեսքն ունեն։ Հաշվի զույգը գալիս է սերվերի PAM կամ auth-user-pass-verify կարգավորումից և դրան պատասխանում է auth-user-pass-ը։ Անձնական բանալու գաղտնաբառը պատկանում է բանալու ֆայլին և կարդացվում է --askpass-ով կամ ձեռքով մուտքագրվում։ PKCS#12 փաթեթը պահանջում է իր սեփական գաղտնաբառը։ Պրոքսի նույնականացումը օգտագործում է auth ֆայլը, որը վերցնում է --http-proxy-ն, ոչ թե հաշվի վկայականները։

Երբ OpenVPN-ը աշխատում է որպես systemd-ի, PHP-ի կամ Node-ի զավակ, տերմինալ չկա, ուստի դրանցից ցանկացածը լուռ արգելափակում է։ Գործընթացը նստած է այնտեղ, մատյանը կանգ է առնում գաղտնագրման տողից հետո, և միավորը վերջում անցնում է ժամկետը. այդ լռությունն է պատճառը, որ մարդիկ ավելացնում են կրկնափորձի հանգույց կամ sleep՝ փոխարենը նայելու, թե որ հարցումն է սպասում։ Միայն կառավարման socket-ը կարող է պատասխանել բոլոր չորսին։ Վկայականի ֆայլը պատասխանում է առաջինին և ոչ այլ բանի։

auth-user-pass՝ մեկ ֆայլ, մեկ հարցում

Ֆայլը պարունակում է օգտանունը առաջին տողում և գաղտնաբառը երկրորդում, և ոչ այլ բան. առանց չակերտների, առանց բանալու անունների, առանց մեկնաբանության։ Սահմանեք 600 ռեժիմը և սեփականատերը դարձրեք այն հաշիվը, որը գործարկում է openvpn-ը, ինչը ծառայության համար հաճախ ձեր մուտքը չէ, այլ առանձին օգտատեր։ /root-ի տակ root-ին պատկանող ֆայլը տարբերությունն է ձեր shell-ում աշխատող հրամանի և բեռնման ժամանակ ձախողվող միավորի միջև։

Երկու մանրամասնություն ճիշտ ֆայլը դարձնում են հարցում։ CRLF պահող խմբագրիչը գաղտնաբառին կպած թողնում է վագոնի վերադարձ, այնպես որ սերվերը մերժում է գաղտնաբառը, որը ֆայլում ճիշտ է թվում. ստուգեք cat -A-ով կամ od -c-ով, ոչ աչքով։ Իսկ պրոֆիլի ներսում առանց արգումենտի auth-user-pass-ը նշանակում է «հարցրու օգտատիրոջը» ըստ նախագծի, ինչը հրամանի տողի երկրորդ հրահանգը կարող է չվերացնել, որովհետև պրոֆիլը վերլուծվում է այնտեղ, որտեղ գտնվում է։

Տարբերակների կարգը երրորդ թակարդն է, և այն կախված է տարբերակից։ OpenVPN 2.4-ի որոշ կառուցումներ անտեսում են --auth-user-pass-ը, երբ այն գալիս է --config-ից առաջ, ուստի նույն երկու տարբերակները հակառակ կարգով միանում են։ Դրեք հրահանգը պրոֆիլի ներսում կամ հրամանի տողում --config-ից հետո, և նախքան ուրիշ բան փոխելը grep արեք պրոֆիլում յուրաքանչյուր հանդիպում։

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

Կառավարման socket-ը. ամեն հարցում, ավելի շատ մակերես

Գործարկեք հաճախորդը լսողով և հստակ հայտարարեք, որ հարցումները կհաղորդվեն դրա վրա՝ օգտագործելով OpenVPN 2.6 ձեռնարկում փաստաթղթավորված հրահանգները.

management 127.0.0.1 3030
management-query-passwords

bash-ից պահեք կապը ազատ ֆայլի նկարագրիչի վրա և պատասխանեք հարցման անունով, ոչ դիրքով, որովհետև վերամիացումը կարող է հարցնել այլ կարգով.

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

Սահմանը փոխադրումն է։ Կառավարման արձանագրությունը բաց տեքստ է TCP-ի վրա loopback-ում, ուստի լսողը չպետք է հրապարակվի LAN կամ թունելի հասցեում, որպեսզի հեռավոր կարգավորիչը հասնի դրան. հեռավոր կարգավորիչը նշանակում է SSH փոխանցում, ոչ ավելի լայն կապում։ Համայնքի դեմոնը նաև ընդունում է միայն մեկ կառավարման հաճախորդ միաժամանակ, ուստի GUI-ն կամ մոնիտորը չեն կարող socket-ը կիսել ձեր սկրիպտի հետ։ Երկրորդ միացումը մերժվում է, ոչ հերթագրվում, և ձախողումը նման է խլացած սկրիպտի։

Այդ socket-ը նաև կառավարման ուղի է։ Առանց կառավարման գաղտնաբառի՝ ամեն ինչ, որ կարող է միանալ 127.0.0.1:3030-ին, կարող է կարդալ կարգավիճակը, սպանել թունելը կամ ինքնուրույն պատասխանել հարցմանը։ Կառավարման գաղտնաբառը և վկայականի ֆայլը նույն դասի գաղտնիք են, և երկուսն էլ արժանի են նույն խնամքին։

Որն է հարմար տեղակայմանը

Ընտրեք վկայականի ֆայլը, երբ միակ հարցումը հաշվի զույգն է, հաճախորդը աշխատում է որպես ծառայություն կայուն սեփականատիրոջով, և դուք կարող եք 600 ֆայլը պահել ձեր չվերահսկած պահուստներից դուրս։ Ընտրեք կառավարման socket-ը, երբ գործի մեջ է բանալու գաղտնաբառ կամ PKCS#12 գաղտնաբառ, երբ փաթաթանն արդեն հսկում է գործընթացը, կամ երբ պետք է դիտեք կարգավիճակն ու հարցումները վերամիացումը վրիպազերծելիս։

Երկու պայման տեղափոխում են որոշումը։ Եթե փաթաթանը /bin/sh է, systemd միավոր, որն ուղղակիորեն կանչում է բինարը, կամ նվազագույն կոնտեյներ, ապա միայն bash-ի համար նախատեսված socket-ի սոսինձը հասանելի չէ, և ֆայլն ավելի էժան պատասխանն է։ Եթե գաղտնիքը հաճախ պտտվում է, ոչ մի ֆայլ լավ տուն չէ դրա համար. հարցրեք բանալիների շարանը փոքր փաթաթանից և թույլ տվեք միավորին կանչել փաթաթանը, ինչը պտտումը պահում է մեկ տեղում, իսկ գաղտնաբառը՝ shell-ի պատմությունից դուրս։

Գործընթացի փոխարինումը կանգնած է երկուսի միջև և չի պատկանում ոչ մեկին։ Ներքևի մեկտողանոցը աշխատում է, որովհետև bash-ը ընդլայնում է այն մինչև openvpn-ի մեկնարկը, ոչ թե որովհետև հաճախորդը հասկանում է շարահյուսությունը.

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

Այն կոտրվում է /bin/sh-ի տակ, shell-ը շրջանցող միավորում և առանց bash կամ /dev/fd պատկերներում։ Պահեք այն ինտերակտիվ փորձարկման համար, երբեք որպես պայմանագիր, որից ծառայությունը կախված է։

Պաշտպանեք գաղտնիքը, ապա ստուգեք մատյանից

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

Ճիշտ աշխատանքը ցույց է տալիս հարցումների հաջորդականության ավարտը և սեսիայի հասնելը «Initialization Sequence Completed»-ին։ Եթե հաճախորդը կանգ է առնում նույն հարցման վրա, համապատասխանությունը ձախողվել է. տպեք socket-ի ուղարկած ճշգրիտ տողերը, ստուգեք չակերտներն ու հարցման անունը, և ուղղեք օրինաչափությունը՝ sleep ավելացնելու փոխարեն։ Թունելը, որը հաղորդում է հաջողություն և ոչինչ չի փոխադրում, երթուղավորման կամ push խնդիր է, ոչ վկայականի։

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