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

Սխալը գալիս է դարպասից առաջ

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

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

Այդ տարբերությունը փոխում է նաև, թե ով է ուղղելու։ Բեռնարկղի խնդիրը պատկանում է սարքին և դրա տիրոջը, իսկ հաշվի մերժումը՝ նրան, ով վարում է նույնականացման ենթակառուցվածքը։

Համեմատեք բեռնարկղերը, ոչ թե նշանները

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

Where the value stopsWhat you seeWhat you checkWho owns the fix
GUI field or managed profileA validation message before any connection opensThe selected authentication mode and whether the field holds the secret or the usernameThe device owner or the profile author
Keychain or secret agentA prompt that keeps reappearing, or an agent errorWhether the agent is unlocked and holds an entry for this profileThe user who owns the keychain
Two-line credential fileA prompt for a password that was already suppliedLine count, line order and whether a trailing newline is presentWhoever generated the file
Shell argument or environmentWorks interactively but fails in automationWhether the shell expanded, trimmed or logged the valueWhoever wrote the automation

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

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

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

Կառուցեք հավատարմագրերի ֆայլը առանց հրամանային միջավայրի վնասի

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

read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/creds

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

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

Կարդացեք փուլը առաջին սխալից

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

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

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

Առնչվող հոդվածներ