Ինչու վավեր մեկանգամյա կոդը դեռ ձախողվում է VPN մուտքի ժամանակ

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

Հարցումների հերթականությունը ցույց է տալիս, թե որ հոսքում եք

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

Սխալ ձևը նման է վատ կոդի։ Տեղադրեք թարմ կոդը միայն գաղտնաբառի համար նախատեսված դաշտում, և սերվերը կկարդա այն որպես գաղտնաբառի մաս։ Հաճախորդի կողմում OpenVPN 2.4-ը և ավելի նորերը տեսանելի են դարձնում տարբերությունը. AUTH_FAILED,CRV1:-ով պատասխանող սերվերը սպասում է մարտահրավերի պատասխանի, ուստի պրոֆիլին անհրաժեշտ է static-challenge կամ SCRV1: ձևի գաղտնաբառի ֆայլ։ Ավելի հին պրոֆիլը, որը կրում է միայն auth-user-pass, ստուգում է գաղտնաբառը և հետո կանգ է առնում, ինչը մատյանում նման է OTP ձախողման, թեև ոչ մի կոդ չի ուղարկվել։

WireGuard-ը արժե նշել որպես բացառություն. այն նույնականացնում է բանալիների զույգեր, ոչ թե մարդկանց, ուստի կոդի դաշտ չկա։ Եթե մատակարարը գովազդում է այդպիսին, ապա թունելից դուրս ինչ-որ բան է այն ընդունում։

Ինչ է անում սերվերը վեց թվանշաններով

Ժամանակահիմն կոդերը հետևում են RFC 6238-ին, որը փաթաթում է RFC 4226-ի հին հաշվիչահիմն կառուցվածքը. HMAC շարժվող գործոնի վրա, լռելյայն կրճատված մինչև վեց թվանշան։ TOTP-ի դեպքում շարժվող գործոնը ընթացիկ Unix ժամանակն է՝ բաժանված քայլի, 30 վայրկյան, եթե օպերատորը չի փոխել այն։ Ստուգիչը երբեք չի համեմատում ձեր թվանշանները պահված արժեքի հետ. այն վերահաշվարկում է սպասվող կոդը ընդհանուր սերմից և սովորաբար ընդունում է նաև հարևան քայլերը, ուստի դանդաղ շրջանը չի ձախողում մուտքը։

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

Հաշվիչահիմն թոքենները հաշվիչը տեղափոխում են յուրաքանչյուր սեղմումով, ուստի դուրս են գալիս համաժամացումից այն բանից հետո, երբ կոդերը գեներացվել են, բայց երբեք չեն ուղարկվել. սովորական վերանորոգումը վերահամաժամացման պատուհանն է, որն ընդունում է առաջ գտնվող մի քանի արժեք։ Եթե օպերատորը գրանցել է HOTP, իսկ ձեր հավելվածը ցույց է տալիս TOTP, ապա ամեն արժեք սխալ է այնպես, որ նման է ժամացույցի խնդրի։ QR կոդի հետևի տրամադրման URI-ն նշում է տեսակը, թվանշանները, պարբերությունը և հեշը։

Ձախողումներ, որոնք նման են սխալ կոդի

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

Երկրորդը անհամապատասխան պարամետրերի հավաքածուն է։ Ութ թվանշանով, 60 վայրկյան պարբերությամբ կամ SHA-256-ով գրանցված սերմը տալիս է կոդեր, որոնք մերժում է վեց թվանշան, 30 վայրկյան և SHA-1 սպասող ստուգիչը, և հաճախորդի մոտ դա անհնար է տարբերել սխալ կոդից։ Այն ի հայտ է գալիս միգրացիաներից հետո, երբ գրառումը նորից ավելացվել է QR կոդի լուսանկարից, կամ երբ թոքենի գրառումը վերակառուցվել է լռելյայն արժեքներով։

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

Կարճ հաջորդականություն, որը նեղացնում է

Սկսեք ամենաէժան ստուգումից և կանգ առեք առաջին քայլում, որը չի դիմանում։

1. Սպասեք թարմ կոդի, ուղարկեք այն մեկ անգամ և նշեք՝ մարտահրավերը հայտնվում է գաղտնաբառի ընդունումից առաջ, թե հետո։
2. Համապատասխանեցրեք նույնականացուցիչի պիտակը սերվերի պահած օգտանվանը։
3. Հաստատեք, որ պրոֆիլն ընդհանրապես կարող է պատասխանել մարտահրավերին, ինչպես վերևի CRV1 դեպքում։
4. Համեմատեք սարքի ժամացույցը հայտնի ժամանակի աղբյուրի հետ. մի քանի տասնյակ վայրկյանից ավելի շեղումն ինքնին կոտրում է TOTP-ն։
5. Հարցրեք օպերատորին՝ թոքենը TOTP է, թե HOTP, և որ թվանշանները, պարբերությունը և հեշը գրանցվեցին։

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

Սերմը և վերականգնման կոդերը պահեք շրջանից դուրս

Վեց թվանշանները և դրանց հետևի գաղտնիքը փոխարինելի չեն։ Տրամադրման QR կոդը կամ Base32 սերմը գեներացնում է հաշվի բոլոր ապագա կոդերը, ուստի այն նույն կատեգորիային է պատկանում, ինչ գաղտնաբառը. ոչ էկրանի պատկերում, ոչ տոմսի մեկնաբանությունում, ոչ էլ առաջինը ձեզ դիմած անձի հետ զրույցում։ Վերականգնման կոդերը առանձին մեխանիզմ են — մեկանգամյա, հաճախ ամբողջությամբ շրջանցում են կոդի հարցումը, և մեկը հաշիվը ստուգելու վրա ծախսելը վերացնում է պահուստային ուղի, որը կարող է ավելի ուշ պետք գալ։

Կոդը նաև մուտքի էջը վստահելի չի դարձնում. նմանատիպ դոմենում OTP հարցումը հավաքում է վավեր կոդ և նույն պատուհանի ընթացքում նորից նվագարկում այն, իսկ վկայականը դեռևս այն է, ինչ ասում է, թե որտեղ եք մուտքագրում։

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