VPN մուտքը կանգ է առնում RADIUS Access-Challenge-ից հետո

Ձեր գաղտնաբառը ճիշտ է, VPN մուտքը միևնույն է ձախողվում է, և RADIUS սերվերը գուցե արել է հենց այն, ինչ իրեն ասվել էր։ Դարպասը հավանաբար ստացել է Access-Challenge, ոչինչ օգտակար չի ցուցադրել, ապա ժամկետը լրացել է կամ այդ պատասխանը համարել է մերժում։ Կլիենտի կողմից դա նման է սխալ հավատարմագրերի կամ կոտրված թունելի։ Պատճառը սովորաբար գտնվում է զրույցի մեջտեղում, որը ոչ ոք չի ֆիքսել։

Մեկ մուտք, երկու RADIUS փոխանակում

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

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

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

Ինչ է իրականում կրում մարտահրավերը

RADIUS ճշգրտումը նկարագրում է 11 կոդը 4.4 բաժնում և թույլատրում է երկու ատրիբուտ, որոնք այստեղ կարևոր են։ Reply-Message-ը պահում է օգտատիրոջ համար նախատեսված տեքստ, իսկ State-ը պահում է անթափանց արժեք, որը սերվերը ցանկանում է հետ ստանալ։ NAS-ը չպետք է մեկնաբանի State-ը, միայն անփոփոխ վերադարձնի այն։

Շարունակական հարցումն օգտագործում է նոր Identifier և նոր Request Authenticator և պետք է կրի նույն State արժեքը գումարած օգտատիրոջ պատասխանը։ Սերվերը այն կապում է սպասվող մարտահրավերի հետ հենց այդ State-ի միջոցով, դրա համար էլ ատրիբուտը վերարտադրող կամ դեն նետող դարպասը չի կարող ավարտել արարողությունը։ Յուրաքանչյուր պատասխանի response authenticator-ը նույնպես պետք է վավերացվի, հակառակ դեպքում NAS-ը պետք է դեն նետի փափաթեթը։

4.4 բաժինը ավելացնում է այն մանրամասնությունը, որը բացատրում է անաղմուկ ձախողումների մեծ մասը՝ մարտահրավերներին չաջակցող NAS-ը Access-Challenge-ը համարում է մերժում։ Եթե ձեր դարպասի VPN ծառայությունը ավելի հին է այդ աջակցությունից կամ բաց է թողնում այն, backend-ի երկրորդ գործոնի հարցումը դառնում է ակնթարթային «նույնականացումը ձախողվեց» առանց որևէ հուշման։

Որտեղ է կորչում շղթայված հարցումը

Առաջին կասկածյալը հուշման ուղին է, ոչ թե հավատարմագրերը։ Վեբ մուտքերի համար OTP դաշտ ցուցադրող պորտալը դա ինքնաբերաբար չի անում VPN ծառայության համար, և որոշ դարպասներ մարտահրավերը փոխանցում են միայն այն կլիենտներին, որոնք հայտարարում են այդ հնարավորությունը։ Փորձարկեք նույն հաշիվը երկու մուտքի կետերում՝ եթե պորտալն աշխատում է, իսկ VPN-ը՝ ոչ, դուք նայում եք փոխանցմանը, ոչ թե token-ին։

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

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

Հետևեք մեկ փորձի սկզբից մինչև վերջ

Կրկնեք մեկ անգամ՝ սերվերի կողմի վրիպազերծումը միացված, և բոլոր այլ սեսիաները պահեք որսման պատուհանից դուրս։

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

Արդյունքում փնտրեք զրույցի ձևը, ոչ թե մեկ տող։ Առաջին Access-Request՝ Identifier 3-ով, State կրող Access-Challenge, ապա երկրորդ Access-Request՝ Identifier 4-ով, որը կրկնում է այդ State-ը և ներառում օգտատիրոջ պատասխանը։ Եթե երկրորդ հարցումը բացակայում է, դարպասը երբեք չի շարունակել։ Եթե այն գալիս է առանց State-ի, սերվերը չի կարող այն կապել սպասվող մարտահրավերի հետ և սովորաբար կմերժի։

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

Ձեր ուզած վերջնական վիճակը ավարտված, լիազորված զրույց է, որին հաջորդում է նախատեսված ծառայության հասանելիությունը։ RADIUS սերվերից եկող պատասխանը շատ ավելի քիչ բան է ապացուցում։