OpenVPN auth-user-pass: ֆայլ, stdin թե հուշում? Ինչպես ընտրել

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

Երեք պայմանները, որոնք որոշում են դա

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

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

• Մարդ կոնսոլի մոտ, առանց ավտոմատացման՝ ինտերակտիվ հուշում։
• Գործարկում առանց հսկողության, գաղտնիքը կարելի է պահել՝ 0600 ռեժիմով հավատարմագրերի ֆայլ։
• Գործարկում առանց հսկողության, գաղտնիքը չի կարելի պահել՝ գործընթացի փոխարինում կամ fd, որի մեջ գրում է գաղտնիքների գործակալը։
• Հաճախորդը պատկանում է մեկ այլ գործընթացի՝ կառավարման միջերես։

Երբ երկու պատասխան է համապատասխանում, ընտրեք այն, որը գաղտնիքը պահում է argv-ից և shell-ի պատմությունից դուրս։ Ծրագրի արգումենտով փոխանցված գաղտնաբառը կարող է կարդալ ցանկացած տեղական օգտատեր գործընթացների ցանկի միջոցով, և դժվար է չեղարկել այդ բացահայտումը։

Ինչ է իրականում անում յուրաքանչյուր մուտքային ուղին

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

Մյուս երկու ուղիները հոսքն ու socket-ն են։ OpenVPN-ին պետք է միայն ընթեռնելի ֆայլի նկարագրիչ, ուստի այն կընդունի գործընթացի փոխարինում, խողովակով ապահովված /dev/fd գրառում կամ ֆայլի անուն, որն իրականում FIFO է։ Կառավարման միջերեսը տարբերվում է բնույթով՝ հաճախորդը արժեքները հարցնում է վերահսկող գործընթացից՝ դրանք ինքնուրույն կարդալու փոխարեն։ Այդ տարբերությունը կարևոր է վերամիացման ժամանակ՝ հավատարմագրերի ֆայլը, FIFO-ն, որի մեջ գաղտնիքների օժանդակ գործիքը կարող է նորից գրել, և կառավարման միջերեսը կարող են նորից մատակարարել առանց մարդու, գործընթացի փոխարինումը չի կարող, որովհետև նկարագրիչը սպառվում է առաջին ընթերցման ժամանակ։

Ֆայլը պետք է լինի ուղիղ երկու տող

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

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Ուղին նույնքան կարևոր է, որքան բովանդակությունը։ Հարաբերական ուղին լուծվում է գործընթացի աշխատանքային գրացուցակի նկատմամբ, որը ծառայության համար հազվադեպ է այն գրացուցակը, որտեղ փորձարկել եք։ Օգտագործեք բացարձակ ուղի, ֆայլը դարձրեք հաճախորդը գործարկող հաշվի սեփականություն և պահեք 0600 ռեժիմը, որպեսզի խումբը և մյուսները չկարողանան կարդալ այն։ OpenVPN 2.6 ձեռնարկը թվարկում է հրահանգի ընդունելի ձևերը, ստուգեք այն նախքան երրորդը հորինելը։

Փորձարկեք ֆայլը նախքան սերվերին մեղադրելը։ openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 գործարկելը տպում է՝ արդյոք ֆայլը բացվել է, և ավելի ուշ՝ արդյոք հավատարմագրերն ընդունվել են, ինչը ձեզ ասում է, թե որ շերտը փոխել հաջորդը։

Հոսքեր, stdin և դրանց առաջացրած սխալները

Գաղտնաբառը խողովակով ուղարկելը առաջին բանն է, որ փորձում են մարդկանց մեծ մասը, և ամենաշատ անակնկալներով ուղին։ Գործընթացի փոխարինումը աշխատում է, որովհետև հաճախորդին պետք է միայն ընթեռնելի նկարագրիչ՝ openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS")։ /dev/stdin փոխանցելը աշխատում է միայն այն ժամանակ, երբ stdin-ը դեռ բաց և ընթեռնելի է հաճախորդի հարցման պահին, ինչը ճիշտ չէ այն խողովակաշարում, որն արդեն սպառել է այն։

ERROR: could not read Auth username from stdin-ն ունի երկու տարբեր պատճառ։ Որոշ 2.3.x հաճախորդների վրա հաղորդագրությունը գալիս էր stdin-ի մշակման թերությունից, որը ուղղել են ավելի ուշ 2.3 թողարկումները, ուստի այդքան հին հաճախորդը բարելավվում է միայն թարմացումով։ Ընթացիկ հաճախորդի վրա նույն ձևակերպումը նշանակում է, որ հաճախորդը պահանջել է կոնսոլի մուտք, և stdin-ը տերմինալ չի եղել՝ հենց այն վիճակը, որ լինում է systemd միավորում, cron առաջադրանքում կամ առանց -t-ի գործարկված կոնտեյներում։

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

Կառավարման միջերեսը, երբ հուշումը պատկանում է մեկ այլ գործընթացի

Վերահսկիչը, որն արդեն հսկում է թունելը, կարող է նաև պատասխանել նրա հարցերին։ Գործարկեք հաճախորդը --management 127.0.0.1 7505-ով, կարդացեք վիճակի տողերը և հետևեք >PASSWORD:Need 'Auth' username/password-ին։ Վերահսկիչը պատասխանում է username "Auth" alice-ով, որին հաջորդում է password "Auth" ...-ը առանձին հրամանի տողերում։ 'Auth' նշանը կրկնում է հարցման նույնացուցիչը և պետք է համընկնի, հակառակ դեպքում պատասխանը անտեսվում է, և հաճախորդը սպասում է։

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

Հավատարմագրերի խնդիր թվացող խափանումներ

TLS ձեռքսեղմումը, որը երբեք չի ավարտվում, կամ VERIFY ERROR: depth=0, error=certificate signature failure-ը վստահության խնդիր է և տեղի է ունենում նախքան որևէ օգտանուն կարդալը։ UDP լսողին ուղղված proto tcp հաճախորդը ձախողվում է նույն տեղում՝ փաթեթները երբեք չեն հասնում նույնականացման փուլին, ուստի ամեն գաղտնաբառ սխալ է թվում ասոցիացիայով։ Թողեք վկայագրի ստուգումը միացված, մինչ հավատարմագիրն ուղարկվելը, ծանոթ հուշումը ոչինչ չի ասում այն մասին, թե ով է ստանում գաղտնաբառը։ Ստուգեք վկայագրերի շղթան, ընդհանուր անունը և փոխադրումը նախքան հավատարմագիրին դիպչելը։

Պրոֆիլը հավաքող սկրիպտի shell սխալները երկրորդ կեղծ հետքն են։ [ ! -f "$file" ]-ի ներսում բացակայող բացատը առաջացնում է command not found, սկրիպտը վաղ է կանգնում, պրոֆիլը երբեք նորից չի կառուցվում, և հաճախորդը գործարկվում է նախորդով։ Այդ սխալը shell-ին է պատկանում, ոչ նույնականացմանը, և գաղտնաբառը քանի անգամ էլ նորից մուտքագրեք, այն չի ջնջվի։

Այս հոսքի ամեն հուշում այս հավատարմագիրը չէ։ Մասնավոր բանալու գաղտնաբառը, HTTP փոխարինողի մուտքը և ծառայության գաղտնաբառը երեք տարբեր գաղտնիքներ են, որոնք պահանջվում են տարբեր փուլերում, և բանալու գաղտնաբառը սովորաբար ղեկավարում է հաճախորդը կամ գործակալը, ոչ auth-user-pass-ը։ Եթե հուշումը հայտնվում է նախքան TLS նստաշրջանի կանգնելը, դուք պատասխանում եք սխալ հարցին, և հաշվի վերականգնումը չի օգնի։ Սխալ հուշումը բացառելուց հետո մնացած ստուգումները սկսվում են ամենավաղ շերտից՝

• Կարդացեք առաջին արձանագրության սխալը, ոչ վերջին հավատարմագրի տողը՝ TLS, ապա նույնականացում, ապա push։
• Հաստատեք, որ ֆայլը երկու տող է, վագոնի վերադարձեր չունի և հղվում է բացարձակ ուղով։
• Հաստատեք, որ պրոֆիլը և հրամանի տողը չեն հակասում հրահանգի շուրջ։
• Առանձնացրեք «հավատարմագրերն ընդունված են»-ը «տրաֆիկը հոսում է»-ից, երթուղումը և DNS-ը ավելի ուշ շերտ են։

Երբ հաճախորդը հասնում է push փուլին, դադարեք նայել հավատարմագրերին և սկսեք կարդալ սերվերի ուղարկած երթուղիներն ու DNS սերվերները։ Դա հաջորդ խնդիրն է, և կապ չունի այն գաղտնաբառի հետ, որը հենց նոր ուղղեցիք։