IKEv2 վկայագրի կարգավորում iPhone-ում՝ ձեռքով կամ կառավարվող գրանցում

RSA-ն ընտրելը միայն այն պատճառով, որ դարպասի վկայագրի գործիքը լռելյայն օգտագործում է այն, որոշում է, որն ընդունվում է մինչև կարևոր հարցին պատասխանելը՝ ինչպե՞ս են գրանցվելու այս iPhone-ները Օգտագործողի կողմից մուտքագրված միացումը և կառավարման կողմից տրամադրված կազմաձևման պրոֆիլը տարբեր կարգավորումներ են ցուցադրում, և վկայագրի որոշ ընտրանքներ գոյություն ունեն միայն այդ ուղիներից մեկում։ Ճիշտ դասավորեք հաջորդականությունը, և վկայագրի պլանը կդառնա կարճ, սխալ դասավորեք, և կթողարկեք հավատարմագիր, որը հեռախոսը չի օգտագործի։ Ստորև բերված քայլերը դիտարկեք որպես հաջորդականություն, քանի որ յուրաքանչյուրը նեղացնում է հաջորդի համար հասանելի ընտրանքները։

Առաջին քայլ՝ ընտրեք գրանցման ուղին

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

Երկու ուղիներն էլ կարող են նույնականացնել հեռախոսը։ Նրանք տարբերվում են նրանով, թե ինչ կարող եք կարգավորել և թե ով է տիրապետում ինքնությանը, ուստի գիտակցաբար ընտրեք մեկը՝ կառավարվող պրոֆիլը ձեռքով հավատարմագրերի մուտքագրման հետ խառնելու փոխարեն։

Երկրորդ քայլ՝ ընտրեք ալգորիթմները ձեր ընտրած ուղու համար

Ձեռքով կարգավորված iPhone-ների համար strongSwan-ի iOS փոխգործակցելիության նշումները խորհուրդ են տալիս RSA սերվերի վկայագիր, քանի որ ձեռքով հաճախորդը կարող է չընդունել ECDSA սերվերի վկայագիր, իսկ նույն նշումները macOS-ը դիտարկում են առանձին։ Սա կարդացեք որպես աջակցվող հաճախորդների հավաքածուի ուղեցույց, ոչ թե Apple սարքերի մասին մշտական օրենք։ Կառավարվող պրոֆիլն ավելի շատ տեղ ունի՝ այն կարող է հստակ ընտրել վկայագրի տեսակը, ներառյալ ECDSA հաճախորդի ինքնությունը, երբ բեռնվածքը և դարպասը երկուսն էլ դա աջակցում են։

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

Երրորդ քայլ՝ կարդացեք պրոֆիլի դաշտերը որպես առանձին իրեր

Միևնույն անվանումով մի քանի բանալիներ նկարագրում են տարբեր օբյեկտներ։ Հեռավոր հասցեն այն հոսթն է, որը հեռախոսը հավաքում է։ Հեռավոր նույնացուցիչը այն IKE ինքնությունն է, որը նա ակնկալում է, որ դարպասը կներկայացնի։ Բեռնվածքի վկայագրի հղումը ցույց է տալիս հաճախորդի հավատարմագրին, իսկ վկայագրի տեսակի դաշտը ընտրում է այն տեսակը, որն օգտագործվում է IKEv2 մեքենայական նույնականացման համար։ Դրանցից ոչ մեկը CA-ի ստորագրության ալգորիթմը չէ, թեև բառերը համընկնում են։

Apple-ի IKEv2 բեռնվածքի հղումը RSA-ն թվարկում է որպես լռելյայն վկայագրի տեսակ՝ բացահայտ ECDSA տարբերակներով, և թողարկողի անվան բանալին կապում է որոշակի նույնականացման կարգավորումների հետ։ Այդ կապերը կարդացեք ձեր ընտրած եղանակի հղումում՝ աշխատող տեղակայումից մեկ բանալի պատճենելու փոխարեն։

Չորրորդ քայլ՝ համապատասխանեցրեք դարպասի ինքնությունը նրա վկայագրին

Օգտագործեք բացահայտ դարպասի անվանում, օրինակ՝ vpn.example.com և տեղադրեք համապատասխան այլընտրանքային սուբյեկտի անուն սերվերի վկայագրում։ strongSwan-ի Apple ուղեցույցը նաև ակնկալում է ընդլայնված բանալու օգտագործումը սերվերի նույնականացման համար։ RSA-ի կամ ECDSA-ի ընտրությունը դրանից ոչինչ չի փոխում՝ ալգորիթմը չի կարող վերանորոգել անվան անհամապատասխանությունը, բացակայող EKU-ն կամ թերի շղթան։

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

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

Հինգերորդ քայլ՝ առանձնացրեք հաճախորդի ինքնությունը CA-ի վստահությունից

Հաճախորդի վկայագիրը և նրա մասնավոր բանալին նույն օբյեկտը չեն, ինչ CA-ի վկայագիրը, որին վստահում է հեռախոսը։ CA-ի վկայագիրը PKCS#12 ինքնության մեջ փաթեթավորելը այն ինքնաշխատ չի տեղադրում որպես վստահության խարիսխ յուրաքանչյուր աջակցվող սարքում, ուստի վստահության բաշխումը դիտարկեք որպես առանձին քայլ՝ իր սեփական ստուգմամբ։

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

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