Ինչու է ձեր IPsec թունելը աշխատում մինչև CHILD SA առաջին բանալու նորացումը

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

Միացված լինելը չի նշանակում, որ PFS կարգավորումները համընկնում են

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

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

Որտեղ է անհամապատասխանությունը թաքնված առաջարկի տողում

strongSwan-ում խումբը կցվում է դուստր առաջարկին, դրա համար էլ տողը, ինչպիսին է aes256gcm16-prfsha256-ecp256 թվում է որպես գաղտնագրման ընտրություն, բայց նաև կրում է բանալիների փոխանակման պահանջ։ Կողմը, որն առաջարկում է միայն aes256gcm16-prfsha256 նման պահանջ չունի, և երկու ցանկերը հատվում են գաղտնագրման մեջ, սակայն տարբերվում են փոխանակման հարցում։

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

Կարդացեք ձախողումը, ոչ թե այն ֆայլը, որը խմբագրել եք

Գտեք այն notify-ն, որն ավարտեց փոխանակումը։ Դուստր բանալու նորացումը, որը վերադարձնում է «ընդունելի առաջարկ չկա», մատնանշում է առաջարկների ցանկերին. նորացման հարցումը, որը երբեք պատասխան չի ստանում, մատնանշում է ուղուն կամ այն կողմին, որը դադարել է լսել։ Այս երկուսին տարբեր ուղղումներ են պետք, և մատյանի տողի ձևակերպումը բաժանում է նրանց։

Հաստատեք աշխատող կոնֆիգուրացիան, ոչ թե սկավառակի վրա եղածը։ Պահված, բայց չբեռնված ֆայլը կամ այլ include-ից նորից կարդացված կապը կստեղծի անհամապատասխանություն, որը տեսանելի ֆայլի ոչ մի խմբագրում չի շտկի։

Երեք իրադարձություն, որոնք բոլորն անվանում են բանալու նորացում

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

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

Նորացումն անջատելը լուծում չէ

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

Փոխարենը համաձայնեցրեք առաջարկները։ Ընտրեք խումբ, որն իրականացնում են երկու կողմերը, դրեք այն երկու ծայրերում էլ դուստր առաջարկի մեջ, և նորացման քաղաքականությունը պահեք այն միջակայքում, որն իրականում պահանջում է կազմակերպությունը։

Ապացուցեք դա ձախողված փոխանակումով

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

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