Երկու ինքնություն մեկ IKEv2 մուտքում՝ նախ մեքենան, ապա՝ օգտատերը

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

Ախտանիշը՝ ձախողում հաջող առաջին ապացույցից հետո

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

Այդ ձախողման երկու նկարագրություններն էլ ճիշտ են՝ կախված նրանից, թե որտեղ եք կանգնած։ Հաճախորդի կողմից դա նման է սերվերի, որը մերժում է վավեր վկայական, իսկ սերվերի կողմից՝ հաճախորդի, որը չի կարող ավարտել մուտքը։ Նույն իրադարձությունը մեկ մատյանում կարդացվում է որպես վստահության խնդիր, իսկ մյուսում՝ որպես ունակության խնդիր։ Միայն կարգավորված քաղաքականությունն է ասում, թե որն է։

Ինչ է ավելացնում ընդլայնումը և ինչ՝ ոչ

IKEv2-ը կրում է ընդլայնում մեկ նստաշրջանի ընթացքում մեկից ավելի նույնականացման փոխանակումներ անցկացնելու համար։ RFC 4739-ը, ի թիվս այլ հաջորդականությունների, ուրվագծում է հաճախորդ, որը հաստատում է վկայականի ինքնությունը, ապա EAP-ի միջոցով նույնականացնում է անձի։ Փաստաթուղթն ունի Experimental կարգավիճակ, ինչը նշանակում է, որ ոչ մի իրականացում ձեզ պարտավոր չէ այդ հնարավորությամբ։ Ոչինչ մի՛ ենթադրեք աջակցության մասին, քանի դեռ գործընկերը չի բանակցել այն։

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

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

EAP-TLS-ը երրորդ ձևն է, և այն նույնպես սա չէ։ Այնտեղ հաճախորդի վկայականը ներկայացվում է EAP մեթոդի ներսում, ուստի հաճախորդը դեռևս ավարտում է մեկ IKE նույնականացում։ Հավատարմագրերը կարող են նույնը թվալ բազմափուլ դեպքին, մինչ արձանագրությունը կրում է մեկ փուլ երկուսի փոխարեն։ Այդ պատճառով EAP-TLS տեղադրումից պատճենված դիզայնը ձախողվում է հենց այնտեղ, որտեղ սպասվում է երկրորդ ապացույցը։

Նույն ֆայլը դարպասի վրա այլ կերպ է կարդացվում

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

Բաժնի դիրքը սահմանում է դրա հերթականությունը, եթե փուլի համարը չի վերադասավորում այն։ Ուստի լրացուցիչ local կամ remote բաժինները նկարագրում են լրացուցիչ փուլեր, ոչ այլընտրանքներ, և swanctl.conf-ի հղումում ներկայացված բացահայտ փուլի համարը հենց դրա համար է, որպեսզի այդ հերթականությունը դիտավորյալ լինի։ Առանց դրա՝ բլոկի տեղափոխումը փոխում է վարքը։ Այդ պատճառով էլ թղթի վրա համարժեք թվացող երկու կարգավորում կարող են հակառակ հերթականությամբ աշխատել։

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

Տարբերակեք փուլերը անկախ գործոններից

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

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

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

Գրեք զուգակցման կանոնը և փորձարկեք մերժումները

Որոշեք, թե որ մեքենաների ինքնությունները կարող են զուգակցվել որ մարդկանց հետ, և կանոնը գրեք այնտեղ, որտեղ ապրում է կիրառումը։ Երկու վավեր հավատարմագիր կողք կողքի ոչինչ չեն ապացուցում զուգակցման մասին, քանի որ զուգակցումը լիազորման որոշում է, ոչ թե նույնականացման արդյունք։ Գրանցման գրառումները կամ նույնականացման backend-ը պետք է կիրառեն այն կապը, որը կազմակերպությունը ցանկանում է։

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

swanctl --list-conns
swanctl --list-sas

Ստուգեք բանակցված փուլերը և դրանցից բխող լիազորումը, ոչ միայն հաջող մուտքը։ Եվ մի՛ դիմեք IKEv1 XAuth-ի հին կարգավորումներին որպես կարճ ճանապարհ. համապատասխանեցրեք արձանագրությանը, դերերին, հերթականությանը և հաճախորդի իրական վարքին՝ պահանջվող փուլը ջնջելու փոխարեն, մինչև կապը հաջողվի։ Ձախողվող փուլը ջնջելն այն ուղին է, որով երկու ապացույցով դիզայնը լուռ դառնում է մեկ ապացույցով դիզայն, որը ոչ ոք չի վերանայել։ Ջնջումը պահեք փոփոխությունների գրանցամատյանում։