Ինչու .ovpn ֆայլի խմբագրումը չի կարող միացնել MFA-ն սերվերում

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

Հարցումը ապացուցում է միայն, որ հաճախորդը հարցրել է, ոչ ավելին

.ovpn ֆայլը հաճախորդի կողմի փաստաթուղթ է։ Այն կարող է հաճախորդին ասել պահանջել հավատարմագրեր, պահել դրանք քեշում կամ դադարեցնել դա։ Այն չի կարող գրանցել օգտատեր, տեղադրել PAM մոդուլ կամ ստիպել սերվերին պահանջել երկրորդ գործոն, որը նա այժմ չի ստուգում։

Հեռախոսում նույնականացման հավելվածի տեղադրումը նույնպես չի ստեղծում այդ կապը։ Google Authenticator PAM նախագիծը OTP ստուգման բաղադրիչ է, որը կարող է կանգնել OpenVPN-ի հետևում; դա Google հաշվի մուտքը ներմուծված պրոֆիլին կպցնելու միջոց չէ։

Գրանցումը այն մասն է, որը պրոֆիլը չի կարող անել

TOTP-ն պահանջում է գրանցման նյութ, որը կիսվում է նույնականացման հավելվածի և նրա ստուգողի միջև։ Հեռախոսի վեց թվանշանները ելքն են. դրանց հետևում գտնվող սերմը գաղտնիքն է, և այն պատկանում է մեկ ինքնության։

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

PAM-ի վրա հիմնված ձևավորումը պարտավոր չէ յուրաքանչյուր VPN օգտատիրոջ համար առանձին Unix հաշիվ ստեղծել։ Մոդուլի փաստաթղթերը աջակցում են գաղտնիքի այլընտրանքային ուղիներ և ֆայլերի հասանելիության համար առանձնացված հաշիվ, ինչը ֆայլային համակարգի ինքնություն է, ոչ թե ստուգվող մուտքի ինքնությունը։

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

Կարդացեք PAM կույտը՝ հասկանալու, թե իրականում ինչ է պահանջվում

account required pam_permit.so-ի նման տողը չի իրականացնում հաշվի իրավասություն և գործոն չի ավելացնում։ Այն թույլատրում է PAM հաշվի կառավարման այդ փուլը, ինչը հայտարարություն է փուլի մասին, ոչ թե ձեր օգտատերերի։

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

Համապատասխանեցրեք հաճախորդի փոխազդեցությունը սերվերի ձևավորմանը

auth-user-pass

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

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

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

Վերամիացումներ, թոքեններ և այն թեստը, որը լուծում է հարցը

Պլանավորեք, թե ինչ է լինում առաջին հաջող մուտքից հետո։ Նախկինում ընդունված կոդը կարող է ժամկետանց լինել կամ մերժվել որպես կրկնություն հաջորդ նույնականացման ժամանակ։ auth-nocache-ը վերահսկում է հավատարմագրերի պահպանումը և չի տեղադրում MFA, իսկ reneg-sec 0-ը TOTP աջակցության սահմանում չէ, որքան էլ հաճախ այն հայտնվի ֆորումի թեմաներում։

Որոշ տեղաբաշխումներ նույնականացման թոքեններ են թողարկում նախնական ստուգումից հետո, որպեսզի վերամիացումները նորից չհարցնեն։ Դա ձևավորման որոշում է՝ իր վավերականության պատուհանով և չեղարկման պատմությամբ, ոչ թե լռելյայն արժեք, որը ժառանգում եք։

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