IKEv2-ը մեկ ձեռքսեղմում չէ. IKE SA, նույնականացում, ապա CHILD SA

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

Առասպել. եթե դարպասը պատասխանում է, դուք միացված եք

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

Այդ խափանումները տեղի են ունենում ավելի ուշ և տալիս են տարբեր ախտանիշներ։ Սերտիֆիկատի մերժումը կամ EAP-ի խափանումը գալիս է այն բանից հետո, երբ առաջին փոխանակումն արդեն հաջողվել է, դրա համար էլ UDP 500-ին ուղղված ping-ը և հաճախորդի կանաչ պատկերակը այդքան քիչ բան են ասում։

IKE_SA_INIT. պայմանավորվեք պարամետրերի, ոչ ինքնության շուրջ

Առաջին փոխանակումը կրում է IKE անվտանգության ասոցիացիայի առաջարկները. գաղտնագրման և ամբողջականության ալգորիթմներ, կեղծ պատահական ֆունկցիա և Diffie-Hellman խումբ։ Կողմերը նաև փոխանակում են nonce-ներ, և յուրաքանչյուր կողմ IKE SA-ի բանալու նյութը ստանում է այն ընդհանուր գաղտնիքից, որ ստեղծում են այդ արժեքները։ Այս փոխանակման մեջ ոչինչ չի հաստատում, թե ով է մյուս կողմը։ Այն հաստատում է, որ երկու կողմերն էլ կարող են հաշվարկել նույն բանալիները և համաձայն են առաջարկի շուրջ։ Պատասխանողը, ում ոչ մի առաջարկ դուր չի գալիս, այստեղ մերժում է փոխանակումը, դրա համար էլ տարբերակի կամ ալգորիթմի անհամապատասխանությունը նման է սերվերի անջատված լինելուն։

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

IKE_AUTH. ապացուցեք ինքնությունը, ապա կառուցեք առաջին CHILD SA-ն

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

Սովորական դեպքում IKE_AUTH-ը բանակցում է նաև առաջին CHILD SA-ն, այնպես որ տվյալների պաշտպանությունը համաձայնեցվում է նույն շրջապտույտում։ Սկսողը առաջարկում է տրաֆիկի ընտրիչներ, պատասխանողը նեղացնում կամ մերժում է դրանք, և տվյալների ուղու բանալիները ստացվում են IKE SA-ից։ Դա նշանակում է, որ մեկ փոխանակում կարող է ձախողվել երկու շատ տարբեր տեղերում. ինքնության կամ քաղաքականության։ Կարդացեք ծանուցման բեռը կամ սխալը, այլ ոչ թե ձեռքսեղմման ընդհանուր խափանումը, որովհետև մեկի լուծումը սերտիֆիկատն է, իսկ մյուսինը՝ ենթացանցի անհամապատասխանությունը։

Երկու SA, երկու աշխատանք

Դրանք իրարից առանձին պահելը բացատրում է երկու վարք, որոնք սխալ են թվում։ Թունելը կարող է ցույց տալ հաստատված վիճակ, մինչդեռ ֆոնում բանալիների նորացումը ձախողվում է, և CHILD SA-ն կարող է փոխարինվել առանց հաճախորդի կապի կորստի։

strongSwan-ում IKEv2 կոնֆիգուրացիայի հղումը և swanctl --list-sas ցույց են տալիս երկու մակարդակները, իսկ ip xfrm state -ը ip xfrm policy հետ միասին ցույց են տալիս, թե ինչ է իրականում տեղադրել միջուկը։ Այս երկու տեսքերի համեմատումը ամենաարագ ճանապարհն է տեսնելու, թե բանակցությունն ավարտվել է, թե միայն ավարտված էր թվում։ Եթե դեմոնը թվարկում է CHILD SA, որի համար միջուկը վիճակ չունի, տեղադրումը լուռ ձախողվել է։ Եթե միջուկը պահում է վիճակ, որը դեմոնը չգիտի, դուք տեսնում եք ավելի վաղ փորձի մնացորդ։

Ինչ պետք է դեռ ճիշտ լինի թունելը բարձրացնելուց հետո

Տրաֆիկի ընտրիչները սահմանում են, թե որ հասցեներն են ընդգրկված։ Եթե հաճախորդն առաջարկում է մեկ ենթացանց, իսկ սերվերը սպասում է մյուսին՝ CHILD SA-ն տեղադրվում է, բայց ոչ մի օգտակար բան չի տեղափոխում, և սխալը հայտնվում է որպես երթուղավորման խնդիր, ոչ թե բանակցության։ Այնուհետև տեղական ստեկը պետք է համագործակցի՝ փոխանցումը միացված այնտեղ, որտեղ հոսթը երթուղավորում է, դեպի թունել ուղղվող երթուղիներ, ապակապսուլավորված փաթեթները թույլատրող ֆայրվոլի կանոններ և ներքին լուծիչ, եթե մասնավոր անուններ ներառված են։ Դրանցից յուրաքանչյուրը ձախողվում է առանձին, և դրանցից ոչ մեկը չի ուղղվում IKE դեմոնը վերագործարկելով։

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