Ինչպես է VPN մուտքը հասնում RADIUS և ձեր ինքնության մատակարարին
Անցեք VPN մուտքը հաճախորդից մինչև դարպասի RADIUS հարցումը, դրա հետևում գտնվող ինքնության մատակարարը և ընդունումից հետո կիրառվող քաղաքականությունը։
Անցյալ շաբաթ օգտատերը կարողացավ մուտք գործել VPN և այնուամենայնիվ հայտնվեց ցանցում, որտեղ ոչինչ չէր լուծվում։ Հաճախորդն ասաց՝ միացված է, դարպասի մատյանն ասաց Access-Accept, իսկ ինքնության թիմն ասաց, որ հաշիվը կարգին է։ Մուտքը ստացվել էր. դրա հետևում գտնվող լիազորումը՝ ոչ։ Երբ VPN մուտքը ձախողվում է, ես անցնում եմ այն ուղին, որով հարցումն իրականում գնում է՝ հաճախորդ, դարպաս, RADIUS սերվեր, ինքնության մատակարար, և կանգ եմ առնում առաջին քայլի վրա, որի պատասխանը չի համընկնում հաջորդի հետ։
Հաճախորդը երբեք RADIUS չի խոսում
Ինչ էլ ցույց տա նոթբուքի հավելվածը, նրա առաջին քայլը VPN արձանագրությունն է՝ IKEv2, OpenVPN, WireGuard կամ TLS-ի վրա հիմնված հաճախորդ։ RADIUS-ը այդ փոխանակման մեջ չի հայտնվում։ Հաճախորդը նույնականանում է դարպասի առջև վկայականով, օգտանունով ու գաղտնաբառով կամ թունելի կարգավորման մեջ փոխանցվող EAP մեթոդով։
Դա կարևոր է մատյանները կարդալիս, քանի որ օգտատիրոջ տեսած ընդհանուր նույնականացման սխալը ստեղծում է դարպասը՝ արդեն ինչ-որ այլ բանի հետ խոսելուց հետո։ Եթե հաճախորդը երբեք չի հասնում դարպասին, վրիպազերծելու RADIUS հարցում գոյություն չունի, և RADIUS սերվերի վրա անցկացրած մեկ ժամը վատնված է։ Համոզվեք, որ թունելը ընդհանրապես բարձրացել է, նախքան հետին մասին դիպչելը։
Դարպասը RADIUS հաճախորդն է
Հենց թունելի կարգավորումը հասնում է այն կետին, որտեղ պետք է ստուգել մուտքի տվյալները, դարպասը դառնում է ցանցային մուտքի սերվեր։ Այն կառուցում է Access-Request՝ User-Name, գաղտնաբառ կամ EAP բեռնվածք, NAS-IP-Address կամ NAS-Identifier, և Message-Authenticator, երբ մեթոդը պահանջում է։ Հարցումը լռելյայն գնում է UDP 1812, իսկ հաշվառումը՝ 1813։ Հին տեղակայումները դեռ օգտագործում են 1645 և 1646, ուստի մեկ զույգի համար գրված firewall կանոնը բացատրում է շատ լուռ ձախողումներ։
Երկու կողմերը կիսում են գաղտնիք, և դա օգտատիրոջ մուտքի տվյալ չէ։ Այն ստորագրում է փոխանակումը, և յուրաքանչյուր պատասխան ստուգվում է դրա դեմ։ Կարգավորեք գաղտնիքը տարբեր կերպ երկու կողմերում, և սերվերը սխալ գաղտնիքով պատասխան չի տալիս՝ այն գցում է հարցումը կամ պատասխանը չի անցնում ստուգումը, ուստի դարպասը հաղորդում է ժամանակի սպառում։ Սխալ գաղտնիքն ու մեռած սերվերը դարպասից նույն տեսքն ունեն, դրա համար էլ քայլը ստուգում եմ հաճախորդի գործիքով, նախքան գրացուցակին մեղադրելը։
Արձանագրությունը փոքր է և հին՝ RFC 2865-ը սահմանում է նույնականացման փոխանակումը, բայց այն ատրիբուտները, որ կրում է, այն հիմքն են, որի վրա կառուցված է VPN քաղաքականության մեծ մասը։
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS սերվերը կարող է միայն ինքնության մատակարարի առջև կանգնել
Մարդիկ խոսում են RADIUS-ի և ինքնության մատակարարի մասին, կարծես դրանք նույն արկղն են։ Հաճախ այդպես չէ։ RADIUS սերվերը ստանում է Access-Request-ը և հետո պատասխանելուց առաջ հարցնում է մեկ այլ բանի՝ Active Directory-ին LDAP-ով կամ Kerberos-ով, տեղական օգտատերերի ֆայլին կամ արտաքին ծառայության։ FreeRADIUS-ը LDAP կամ krb5 մոդուլով, Windows NPS-ը և Cisco ISE-ն բոլորը կանգնած են այս դիրքում։
Տարբերությունը որոշում է, թե որտեղ նայել։ Մերժված գաղտնաբառը ինքնության մատակարարի պատասխանն է, որը փոխանցում է RADIUS-ը։ Ժամանակի սպառումը սովորաբար RADIUS-ից գրացուցակ ընկած հատվածն է՝ ժամկետանց bind հաշիվ, անհասանելի գրացուցակ կամ սխալ հետին մաս ուղարկված հարցում։ Եթե օգտանունը տիրույթի վերջածանց ունի, սերվերը կարող է դրանով երթուղավորել, և նույն հաշիվը՝ ուղարկված որպես CORP\alice և [email protected], կարող է հայտնվել տարբեր տեղերում։ Windows NPS-ում Security մատյանը գրանցում է 6272՝ թույլտվության, և 6273՝ մերժման համար, ինչը ձեզ ասում է՝ արդյոք որոշումը ընդհանրապես NPS-ից է եկել։
Կարդացեք ձախողումը այն քայլում, որն այն առաջացրել է
Մեկ չի կարողանում միանալ հաղորդագրությունը ծածկում է չորս տարբեր ձախողում։ Նախքան ինչ-որ բան փոխելը, համապատասխանեցրեք ախտանիշը այն քայլին, որն այն առաջացրել է։
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
Հենց վերջին տողն է մարդկանց ուղարկում սխալ թիմի մոտ։ Access-Accept նշանակում է, որ մուտքի տվյալներն ընդունվել են. դա չի նշանակում, որ դարպասը օգտատիրոջը դրել է ճիշտ pool-ում կամ ուղիներ է մղել։ Խմբի ատրիբուտները նշանակություն ունեն միայն այն դեպքում, երբ դարպասի քաղաքականությունը կարդում է դրանք։ Ես տեսել եմ, թե ինչպես ճիշտ մուտքը հայտնվում է հյուրերի pool-ում, որովհետև խմբերի քարտեզագրումը RADIUS-ի կողմում կարգավորված էր այլ ատրիբուտի համար, քան այն, ինչը ստուգում է դարպասը։
Հետևեք մեկ մուտքի սկզբից մինչև վերջ
Ընտրեք մեկ փորձնական հաշիվ և մեկ դարպաս, ապա դիտեք նույն փորձը բոլոր չորս կետերում։ Սկսեք վրիպազերծման աշխատանք RADIUS-ի կողմում՝ freeradius -X-ը տպում է հարցումը և յուրաքանչյուր մոդուլ, որին այն դիպչում է, հետևեք դարպասի նույնականացման մատյանին և գործարկեք tcpdump-ը UDP փոխանակման համար։ Միացեք մեկ անգամ և կարդացեք չորս հետքերը հերթականությամբ։
Ինչ ուզում եք տեսնել, համաձայնությունն է՝ դարպասը հարցրել է ձեր սպասած օգտատիրոջ մասին, RADIUS սերվերը ընտրել է ձեր սպասած հետին մասը, այդ հետին մասը վերադարձրել է որոշում, և պատասխանի ատրիբուտները համապատասխանում են դարպասի կիրառած քաղաքականությանը։ Առաջին տեղը, որտեղ հետքերը տարբերվում են, ձեր խափանման գիծն է։ Եթե պատասխանը խմբի ատրիբուտ չի կրում, խնդիրը RADIUS-ի կողմում է, ոչ թե VPN պրոֆիլում. եթե ատրիբուտը կա, և դարպասը անտեսում է այն, խնդիրը դարպասի քաղաքականությունն է։
Մեկ անվտանգության նշում, քանի դեռ այնտեղ եք։ Ընդհանուր գաղտնիքը պաշտպանում է փոխանակումը, բայց այն չի գաղտնագրում ատրիբուտների մեծ մասը։ Եթե դարպասը և RADIUS սերվերը տարբեր սեգմենտներում են, դրեք այդ հատվածը RADIUS-ի վրա TLS-ով կամ մասնավոր ուղով։ Գաղտնագրված օգտատիրոջ թունելը ոչինչ չի ասում հետին մասի կապի մասին։
Նախքան տոմսը փակելը, հաստատեք չորս բան։ Դարպասը կարող է հասնել RADIUS սերվերին այն պորտով, որի համար իրականում կարգավորված է։ Ընդհանուր գաղտնիքը համընկնում է երկու կողմերում։ RADIUS սերվերը լուծում է օգտանվան այն ճշգրիտ ձևը, որը ուղարկում է դարպասը։ Ընդունումը կրում է դարպասի քաղաքականությանը անհրաժեշտ ատրիբուտները։ Երբ բոլոր չորսը պահպանվում են, մուտքը, որը դեռ ձախողվում է, դարպասի քաղաքականության խնդիր է, ոչ թե նույնականացման։