Պլանավորե՛ք IKEv2-ի կարգավորումներ մեկից ավելի հաճախորդների համար
Աշխատող աշխատասեղանի պրոֆիլը փորձարկել է մեկ հաճախորդ։ Համաձայնեցրե՛ք ինքնության պայմանագիրը, ընտրե՛ք աջակցվող հատում և ապա փորձարկե՛ք նորացումն ու քունը յուրաքանչյուր հարթակի համար։
Մեկ աշխատասեղանի վրա աշխատող պրոֆիլը մեկ հաճախորդի հաջող փորձարկում է։ Սա միջհարթակային տեղակայում չէ, և դրան այդպես վերաբերվելը ստեղծում է ծանոթ աջակցության օրինաչափությունը՝ Windows-ը միանում է, հեռախոսը ձախողվում է ինքնության ստուգման ժամանակ, իսկ կառավարվող նոթբուքը վերամիանում է ամեն անգամ, երբ արթնանում է։ Տարբերություններն իրական են և հիմնականում կանխատեսելի, այդ պատճառով պլանը պետք է լինի մատրիցա, այլ ոչ թե էկրանի պատկեր։
Նախ որոշե՛ք ինքնության պայմանագիրը
Նախքան ալգորիթմների քննարկումը՝ փաստաթղթավորե՛ք սերվերի ինքնությունը, վկայագրի նկատմամբ վստահությունը և հաճախորդի նույնականացման եղանակը։ Այս երեքը որոշում են՝ արդյոք հաճախորդը կարող է ընդհանրապես նույնականանալ, և հենց դրանք են, որ հարթակները տարբեր կերպ են արտահայտում։
Ստուգե՛ք, թե ինչպես է յուրաքանչյուր հարթակ անվանում սպասվող նույնացուցիչը և ինչպես է վարվում սուբյեկտի այլընտրանքային անունների հետ։ Մեկ հաճախորդի վրա սերվերի անուն ընդունող պրոֆիլը կարող է մերժել նույն վկայագիրը մյուսի վրա, քանի որ նույնացուցիչի դաշտը լցվում է այլ արժեքից։
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
Ապա ընտրե՛ք գաղտնագրային հատումը
Համեմատե՛ք յուրաքանչյուր աջակցվող հաճախորդի առաջարկները և ընտրե՛ք ժամանակակից հատում, որը թույլատրում է նաև դարպասը։ Մի՛ միացրեք չափազանց մեծ հին ցանկ մեկ հին սարքի միանալու համար, քանի որ այդ ցանկը դառնում է դարպասի լռելյայնը բոլոր հաջորդների համար։ Գրե՛ք, թե ինչու է յուրաքանչյուր հին տարբերակ դեռ այնտեղ։ Եթե ոչ ոք չի կարող անվանել սարքը, որին դա պետք է, ապա դա պահանջ չէ։
Պլանում IKE-ի և CHILD-ի կարգավորումները առանձին պահե՛ք։ IKE-ի փոխանակման համար ընդունելի առաջարկը ինքնաբերաբար ընդունելի չէ պաշտպանված երթևեկության համար, և երկուսը բանակցվում են առանձին։ Դարպասը, որը մեկ շերտում ընդունում է առաջարկը, կարող է այն մերժել մյուս շերտում, և մատյանը ցույց կտա ձախողում, որը կարծես առաջին շերտը հաջողվել է։
Տրամադրե՛ք հավատարմագրերը ստուգված գործընթացով և պահե՛ք օգտվողի գաղտնաբառը, ընդհանուր գաղտնիքը և հաճախորդի անձնական բանալին իրենց դաշտերում։ Փորձերն ու սխալները նույնանուն արկղերի վրա այն ուղին է, որով աշխատող փորձարկումը դառնում է չկրկնվող։
Փորձարկե՛ք կյանքի ցիկլը, ոչ թե կայուն վիճակը
Յուրաքանչյուր հաճախորդի համար փորձարկե՛ք սկզբնական նույնականացումը, նախատեսված հավելվածը, DNS-ի լուծումը և հասցեների ընտանիքների ծածկույթը։ Ապա վարժվե՛ք այն մասերին, որոնք ի հայտ են գալիս միայն ավելի ուշ՝ նորացում, քուն և ցանցի սովորական փոփոխություն։
MOBIKE-ի աջակցությունը և վերանույնականացման վարքը կարող են տարբերվել ձեր նոր չափած կայուն արդյունքից։ Գրանցե՛ք իրադարձությունը և միության վիճակը տվյալ պահին, ոչ միայն այն, թե արդյոք միջերեսը վերջում միացած է երևում։
Սահմանե՛ք, թե ինչ կարող է անել ուղիղ երթևեկությունը, մինչ VPN-ն անհասանելի է։ Սա քաղաքականության որոշում է՝ առանձին այն հարցից, թե արդյոք հաճախորդը նորից կմիանա, և տեղակայումների մեծ մասը պատասխանում է երկրորդ հարցին՝ անտեսելով առաջինը։ Պատասխանը գրե՛ք տեղակայման նշումների մեջ՝ պրոֆիլների անունների կողքին։ Ինչ-որ մեկին այն պետք կգա խափանման ժամանակ, և նա ժամանակ չի ունենա այն վերականգնելու։
Օգտագործե՛ք սերվերի ինքնության ստուգումներ, երբ մի հարթակ համաձայն չէ
Երբ պրոֆիլը աշխատում է մի հարթակում, իսկ մյուսը մերժում է նրա անունը, համեմատե՛ք հաճախորդի իրականում ուղարկած նույնացուցիչը վկայագրում եղած նույնացուցիչների հետ։ Այդ համեմատությունը լուծում է այս դեպքերի մեծ մասը ավելի արագ, քան ծածկագրման ցանկերը փոխելը։
Փորձարկված մատրիցան պահե՛ք կազմաձևման աղբյուրի և թարմացման ընթացակարգի հետ միասին։ Երբ հին հաճախորդի աջակցությունն ավարտվում է, դիտավորյալ հեռացրե՛ք նրա բացառությունը՝ փոխարենը դարպասում թաքնված ավելի թույլ համատեղելիության կարգավորումներ թողնելու, որպեսզի հաջորդ աուդիտը դրանք գտնի։ strongSwan-ի IKEv2 փաստաթղթերը օգտակար հղում են այն մասին, թե ինչպես են կազմաձևվում փոխանակումները։