Ինչպես է IKEv1-ի հիբրիդային նույնականացումը փոխանցվում IKEv2-ի օգտատերերի նույնականացմանը
Հիբրիդային ռեժիմը բաժանում էր դարպասի ապացույցը օգտատիրոջ ապացույցից։ IKEv2-ին անցումը պահպանում է այդ բաժանումը, բայց փոխում է փոխանակումը, EAP մեթոդը և սերտիֆիկատի ստուգումները։
Յուրաքանչյուր հին VPN պրոֆիլ, որը սկզբում պահանջում է սերվերի սերտիֆիկատ, ապա՝ օգտատիրոջ անուն, մեկ փոխանակման մեջ կրում է նույնականացման երկու իրադարձություն, և այդ ձևը վերապրում է այն արձանագրությանը, որը ներմուծեց այն։ IKEv1-ի հիբրիդային ռեժիմը կառուցվել է հենց դրա համար՝ դարպասը իրեն ապացուցում է հանրային բանալիով, իսկ օգտատերը՝ ավելի ուշ XAuth-ի միջոցով։ IKEv2-ը նույն երկքայլ գաղափարն արտահայտում է այլ մեխանիզմով, և հենց այդ տարբերություններում են ձախողվում միգրացիաները։ Ոչ մի տարբերակի համար մի բանը չի վերածում մյուսի, և հին ընտրանքների անունները նոր պրոֆիլում պատճենելը տալիս է հաճախորդ, որը բանակցում է և հետո ոչինչ չի նույնականացնում։
Ինչ էր անում հիբրիդային ռեժիմը IKEv1-ի ներսում
Հիբրիդային պրոֆիլում պատասխանող կողմը ստորագրում է առաջին փուլի փոխանակումը իր սերտիֆիկատով, իսկ նախաձեռնողը դիտավորյալ ոչինչ չի ներկայացնում։ Ուստի ինքնության ապացույցը ասիմետրիկ է, և դա թույլ տվեց դարպասին պահպանել գործող PKI-ն, իսկ օգտատերերին՝ իրենց գրացուցակի գաղտնաբառերը։ Երբ առաջին փուլն ավարտվում է, XAuth-ը կատարվում է որպես հարցում և պատասխան, որոնք կրում են օգտատիրոջ անվան և գաղտնաբառի ատրիբուտները արդեն գաղտնագրված ISAKMP ալիքի ներսում։
Ուշադրություն դարձրեք, թե որտեղ է հայտնվում վստահությունը։ Սերտիֆիկատը պատասխանում է, թե որ դարպասին է հասել հաճախորդը՝ XAuth-ը պատասխանում է, թե որ օգտատերն է ուզում մուտք։ Ոչ մեկը չի փոխարինում մյուսին, և ցանկացած սերվերի սերտիֆիկատ ընդունելու կարգավորված հաճախորդը լուռ դեն է նետել առաջին պատասխանը։ Հիբրիդային պիտակը օգտագործվում է նաև ագրեսիվ ռեժիմի համար՝ նախապես համօգտագործված բանալի գումարած XAuth, այլ դասավորություն նույն օգտատիրոջ փորձով, ուստի կարդացեք պրոֆիլը, ոչ թե անունը։ Երկու տարբերակներն էլ գալիս են նախագծերից, որոնք երբեք ստանդարտ չդարձան, և դրա համար երկու արտադրող կարող են ներդնել հիբրիդային ռեժիմ և չհամագործակցել ոչ մեկի հետ։
Ինչպես է IKEv2-ը հասնում նույն երկու ապացույցներին
IKEv2-ը աշխատանքը բաժանում է IKE_SA_INIT-ի և IKE_AUTH-ի միջև։ Առաջին փոխանակումը համաձայնեցնում է առաջարկներն ու բանալիները բացարձակապես առանց ինքնությունների, երկրորդը կրում է IDi, IDr և AUTH բեռերը։ EAP-ի ներքո նախաձեռնողի առաջին AUTH բեռը դուրս է գալիս դատարկ, պատասխանողը նախ ինքն է նույնականացվում իր սերտիֆիկատով և ստորագրությամբ, ապա EAP զրույցը ընթանում է IKE_AUTH հաղորդագրությունների ներսում։
Մեխանիզմը, որն այս ամենը դարձնում է անվտանգ, բանալիային նյութն է։ Հաջող EAP մեթոդը արտահանում է սեսիայի բանալի, և նախաձեռնողի վերջնական AUTH բեռը հաշվարկվում է դրանից, այնպես որ օգտատիրոջ ապացույցը և թունելի բանալիները կապվում են իրար։ XAuth-ը համարժեք չունի՝ նրա ատրիբուտները գալիս են առաջին փուլից հետո և ոչինչ չեն ավելացնում բանալիներին։ Հենց այդ բացն էր նախատեսված փակել IKEv2-ի շրջանակը, և դրա համար աշխատող IKEv2 մուտքը ստուգում է սերվերի սերտիֆիկատը, նախքան ինչ-որ բան հարցնելը։
Այս հերթականությունը նաև օգտակար ախտորոշում է։ Երբ հաճախորդը բողոքում է մուտքի տվյալներից նախքան ձեզ սերտիֆիկատ ցույց տալը, նա ընդհանրապես IKEv2 EAP փոխանակում չի կատարում։
Երեք ինքնություն պահեք առանձին
Միգրացիան վատ է ընթանում, երբ երեք ինքնություն միաձուլվում են մեկ դաշտում։ Կա դարպասի ինքնությունը, որը հաճախորդը ստուգում է, սովորաբար DNS անուն սերտիֆիկատի subject կամ SAN դաշտում։ Կա EAP-ում ներկայացվող օգտատիրոջ ինքնությունը՝ գուցե դոմենային մուտք, հասցե կամ հստակ EAP ինքնության տող։ Եվ կա լիազորման աղբյուրը, որը այդ օգտատիրոջը քարտեզագրում է ցանցերին և երթուղիներին։
strongSwan-ի swanctl շարահյուսությունը տեսանելի է դարձնում բաժանումը՝ կապը սահմանում է remote { auth = pubkey } դարպասի համար և local { auth = eap-mschapv2 } օգտատիրոջ համար, իսկ EAP ինքնությունը փոխանցվում է առանձին։
Երբ նոր պրոֆիլում օգտատիրոջ ինքնությունը տարբերվում է հին XAuth ատրիբուտներից, օրինակ՝ կարճ անվան փոխարեն UPN, նույնականացման սերվերը տեսնում է անհայտ օգտատեր, և խափանումը նման է սխալ գաղտնաբառի։ Ստուգեք ինքնության տողը նախքան մուտքի տվյալները ստուգելը։
Քարտեզագրեք ընտրանքները և հետո սպասեք թակարդներին
Քարտեզագրումը կարճ է, և յուրաքանչյուր տողում կա թակարդ, որը ի հայտ է գալիս միայն նույնականացման պահին։
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Այդ տողերից ոչ մեկը պարզ վերանվանում չէ։ Կոնֆիգուրացիայի բեռը հասցեներն ու լուծիչները հանձնում է տիպավորված ատրիբուտների ցանկով, մինչդեռ XAuth-ի ատրիբուտային տարածքը սեփական գյուտ էր, դրանք փոխանակելի համարելը հենց այն ուղին է, որով պրոֆիլը սկսում է պահանջել մի կարգավորում, որը դարպասը երբեք չի ուղարկի։
Երթևեկության ընտրիչները արժանի են իրենց սեփական նախազգուշացմանը։ IKEv1-ը հետաքրքիր երթևեկությունն արտահայտում էր quick mode փոխանակմանը կապված proxy ID-ներով, մինչդեռ IKEv2-ը ընտրիչները բանակցում է IKE_AUTH-ի ընթացքում, և պատասխանողը կարող է դրանք նեղացնել։ Անհամապատասխանությունը ստեղծում է հաստատված IKE SA՝ առանց child SA, որը որոշ հաճախորդներ ուրախությամբ ցուցադրում են որպես միացված։
Հին կապը դիտարկեք որպես սահման
RFC 9395-ը IKEv1-ը հայտարարում է հնացած, ուստի հին հիբրիդային կապը ամսաթիվ ունեցող համատեղելիության սահման է, ոչ թե հիմք։ Փոփոխության ընթացքում գործարկեք երկու պրոֆիլները կողք կողքի, որովհետև կարևոր փորձարկումը ոչ թե այն է, թե արդյոք նոր պրոֆիլը բարձրանում է, այլ այն, թե արդյոք նույն օգտատերը նույն սարքում հասնում է նույն ռեսուրսներին։
Սերտիֆիկատների ստուգումը խիստ պահեք մինչև վերջ։ Հենց հաճախորդը դադարում է ներկայացնել իր սեփական սերտիֆիկատը, առաջանում է գայթակղություն թուլացնել սերվերի ստուգումը, մինչև ձեռքսեղմումն ավարտվի, և դա փոխանակում է մնացած միակ ապացույցը կանաչ պատկերակի հետ։
Նախքան հին պրոֆիլը դուրս բերելը գրեք չորս բան՝ EAP մեթոդը, ինքնության տողը, լիազորման աղբյուրը և ամսաթիվը, երբ աջակցությունն ավարտվում է։