IKEv2 Windows-ում և FortiGate-ում՝ երեք կարգավորում, որ մարդիկ միավորում են
IKE բանալիների փոխանակումը, CHILD SA-ի պաշտպանությունը և հավասարակիցքի նույնականացումը երեք առանձին տողեր են։ Երկու երկխոսություններում խմբի համարների համընկնումը դրանք չի միավորում։
Windows-ի հաճախորդի և FortiGate-ի դարպասի միջև IKEv2 համաձայնությունը շարունակաբար ձախողվում է, և անհամապատասխան համարի որոնումը ստեղծում է համարների ավելի երկար ցանկ։ Ցանկը դառնում է կառավարելի միայն այն ժամանակ, երբ այն բաժանվում է երեք տողերի, որոնք ձախողվում են ինքնուրույն՝ IKE-ն պաշտպանող բանալիների փոխանակումը, CHILD SA-ի վրա կիրառվող պաշտպանությունը և նույնականացումը, որն ապացուցում է, թե ով է յուրաքանչյուր կողմը։ Խմբի համարները հայտնվում են այդ տողերից երկուսում և տարբեր նշանակություն ունեն։
Երեք տող, որոնք ձախողվում են ինքնուրույն
Առաջին տողը IKE-ի ներսում բանալիների փոխանակումն է, որը ստեղծում է բանակցությունը պաշտպանող բանալիները։ Երկրորդը CHILD SA-ի առաջարկն է, որը պաշտպանում է թունելի փոխադրած երթևեկությունը։ Երրորդը նույնականացումն է, որը որոշում է, թե ինչ է ներկայացնում յուրաքանչյուր կողմ և ինչպես է մյուսը վավերացնում այն։
Ձախողումները տեղի են ունենում տարբեր տեղերում։ Փոխանակման ձախողումը կանգնեցնում է բանակցությունը նախքան որևէ թունելի գոյությունը։ CHILD SA-ի ձախողումը տեղի է ունենում նույնականացման հաջողությունից հետո, երբեմն միայն բանալիների նորացման ժամանակ։ Նույնականացման ձախողումը մատյաններում կարող է նմանվել փոխանակման ձախողման, եթե կարդում եք միայն առաջին սխալը։
Տողերը բաժանելը հաշվապահություն չէ։ Այն փոխում է, թե որ կարգավորումն արժե փոխել, և կանխում է այս ամբողջ ոլորտի ամենաթանկ քայլը՝ աշխատող վկայագրերի վերականգնումը առաջարկի անհամապատասխանությունը շտկելու համար։ Մեկ տողի փոփոխությունը երբեք չպետք է ստիպի մյուս երկուսին փոխվել դրա հետ։ Այդ անկախությունն է դրանք առանձին գրելու ամբողջ իմաստը։
Ինչ են կառավարում Windows-ի երկու դաշտերը
Windows-ը երկու դաշտ առանձին է պահում՝ DHGroup-ը կարգավորում է հենց IKE փոխանակումը, մինչդեռ PfsGroup-ը կարգավորում է IPsec քաղաքականությունը, որը պաշտպանում է թունելի ներսի երթևեկությունը։ Դրանք պատկանում են տարբեր փուլերի։ Windows-ի IKE դաշտը FortiGate-ի 2-րդ փուլի արժեքի հետ համեմատելը ստուգում է սխալ զույգը, և համարները կարող են համընկնել, մինչդեռ հիմքում ընկած փոխանակումը դեռ ձախողվում է։
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAԵրկրորդ և երրորդ հրամանները հաղորդում են իրականում գոյություն ունեցող անվտանգության ասոցիացիաները, և դա ամենամոտն է պատասխանին, որը հաճախորդը կարող է տալ ձեզ։ Հիմնական ռեժիմի ասոցիացիա առանց արագ ռեժիմի ասոցիացիայի CHILD SA-ի խնդիր է, և դա 2-րդ փուլի անհամապատասխանության, այլ ոչ թե վկայագրի խնդրի նշան է։
Գրանցեք, թե ինչ է առաջարկվել և ինչ է ընտրվել մեկ փորձի ընթացքում։ Առաջարկված ցանկը, որը պարունակում է ընդունելի առաջարկ, և ընտրված առաջարկը, որը չի համապատասխանում դարպասի քաղաքականությանը, կարգավորման անհամաձայնություն է, ոչ թե փոխգործունակության առեղծված։
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
Էլիպսաձև կորի խումբը չի ընտրում ձեր ստորագրության բանալին
Այս ոլորտի ամենահամառ սխալ եզրակացությունն այն է, որ էլիպսաձև կորի DH խումբ ընտրելը պահանջում է էլիպսաձև կորի վկայագիր։ DH խումբը տրամադրում է բանալիների փոխանակման նյութ. ստորագրության ալգորիթմը բանակցվում է նույնականացման շրջանակի կողմից, և դրանք IKEv2-ում երկու առանձին որոշումներ են։
RFC 7427-ը գոյություն ունի հենց այն պատճառով, որ այդ որոշումները նախկինում միահյուսված էին, և այն սահմանում է, թե ինչպես են ստորագրության ալգորիթմները հայտարարվում և ընտրվում բանալիների փոխանակումից անկախ։ Դարպասը կարող է միաժամանակ աջակցել կորի խմբին և ստորագրության սխեմաների ընտրությանը։
Այսպիսով, երբ բանակցությունը ձախողվում է խմբի փոփոխությունից հետո, նայեք նույնականացման մեթոդին նախքան վկայագրի բանալու տեսակին նայելը։ Վկայագիրը փոխելը դանդաղ և ռիսկային գործողություն է, որը հազվադեպ է պատասխանը, և այն առաջինը անելը ոչնչացնում է ձեր կարողությունը պարզելու, թե որ փոփոխությունն իրականում օգնեց։ Կարդացեք նույնականացման տողը նախքան վկայագրերի պահոցին դիպչելը։
Պահեք երկուսն էլ համաձայնագրի թերթիկի առանձին տողերում, և սխալը կդադարի գայթակղիչ լինել։ Մեկ տողը թվարկում է խմբեր, մյուսը՝ ստորագրության սխեմաներ և ինքնություններ, և ոչ մեկը մյուսի մասին ապացույց չէ։
Տեղադրեք յուրաքանչյուր գաղտնի բանալին իր իրական սեփականատիրոջ մոտ
Դարպասը, որը ներկայացնում է իր սեփական վկայագիրը, կարիք ունի դրան համապատասխանող գաղտնի բանալու։ Հավասարակիցքը, որը վավերացնում է շղթան, կարիք ունի CA վկայագրի և հատկապես կարիք չունի CA-ի ստորագրության բանալու։ Այս երեք տարրերը շփոթելն այն ճանապարհն է, որով մարդիկ CA-ի գաղտնի բանալին ներմուծում են VPN սարք, որպեսզի վկայագիրը հայտնվի այլ կատեգորիայում։
FortiOS-ում դերերը տարբեր են՝ տեղական վկայագիր իր բանալիով, հեռավոր վկայագիր, որն օգտագործվում է հավասարակիցքին նույնականացնելու համար, և հեռավոր CA գրառում, որը վստահություն է հաստատում այդ CA-ի ստորագրած վկայագրերի նկատմամբ։ Առանց գաղտնի բանալու հեռավոր CA գրառումը թերի չէ. այն ճիշտ է իր նպատակի համար։
Ներմուծված CA ստորագրության բանալիները լայնացնում են այն սարքը կարդալ կարող ցանկացածի լիազորությունները։ Դրանք նաև չեն լուծում սովորական հավասարակիցքի վավերացումը, որովհետև վավերացմանը պետք է հանրային վկայագիր և վստահության որոշում, այլ ոչ թե նոր վկայագրեր թողարկելու կարողություն։
Պահեք CA-ի ստորագրության բանալին թողարկողի սեփական գործընթացի մոտ և գրանցեք, թե որ սարքն որ բանալին է պահում։ Սեփականատերերի կարճ աղյուսակն ավելի արժեքավոր է, քան ալգորիթմների ավելի երկար աղյուսակը, երբ աուդիտը հարցնում է, թե ով ում կարող էր նմանակել։ Ոչ ոք չի ներմուծում բանալի, որի մասին գիտի, որ միայն գույքագրման համար է։ Գրեք գույքագրումը միջադեպից առաջ, ոչ թե հետո։