FortiGate Azure բանալու նորացում. peer SA առաջարկը չի համապատասխանում տեղական քաղաքականությանը

Թունելը բարձրացավ, երթևեկությունը հոսեց, և ավելի ուշ մատյանն ասում է peer SA proposal not match local policy։ Մարդկանց մեծ մասը այդ տողը կարդում է որպես ապացույց, որ երկու կազմաձևերը երբեք չեն համապատասխանել։ Սովորաբար դա նշանակում է ավելի նեղ բան. դրանք համապատասխանել են առաջին CHILD SA-ի համար և դադարել են համապատասխանել առաջին նորացման ժամանակ, քանի որ առաջին միավորումը երբեք չի ունեցել այն փոխանակման կարիքը, որը կատարում են հաջորդները։ Հենց այդ տարբերությունն է որոշում, թե որտեղ նայել։

Առաջին CHILD SA-ն ժառանգում է, հաջորդները բանակցում են

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

CHILD_SA բանալու նորացումը այլ հաղորդագրությունների հաջորդականություն է։ Երբ PFS-ը կազմաձևված է, peer-երը կատարում են նոր բանալիների փոխանակում և պետք է համաձայնության գան երկու կողմերի ընդունած խմբի, ինչպես նաև նոր միավորման ESP առաջարկի շուրջ։ Հենց այդ պահին է անհամապատասխանությունը դառնում տեսանելի, և դրա համար էլ սխալը նշում է առաջարկ, այլ ոչ թե երթուղի։

Այսպիսով՝ «երեկ աշխատում էր»-ը ձեզ ոչինչ չի ասում առաջարկի մասին։ Այն ասում է, որ սկզբնական փոխանակումը հաջողվել է, ինչը դուք արդեն գիտեիք։

Կարդացեք ձախողված փոխանակումը, ոչ թե առաջին ping-ը

Նախքան որևէ բան փոխելը հավաքեք երկու ծայրերից հաջող IKE նույնականացումը, սկզբնական CHILD SA-ն և ձախողված փոխարինումը։ Այնուհետև ճշգրիտ անվանեք գործողությունը. IKE SA բանալու նորացումը, IKE վերանույնականացումը և CHILD SA բանալու նորացումը երեք տարբեր իրադարձություններ են, և «2-րդ փուլ»-ը սովորական խոսքում ընդգրկում է դրանք բոլորը։

Համեմատեք ստորև նշված դաշտերը ձախողված միացման համար, ոչ թե թունելի ընդհանուր առմամբ։

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

Azure-ի լռելյայն քաղաքականությունը մնում է քաղաքականություն

Միացմանը կցված հատուկ քաղաքականության բացակայությունը չի նշանակում, որ Azure-ը ոչ մեկը չի կիրառում։ Միացումը վերադառնում է դարպասի լռելյայն առաջարկների հավաքածուին, որը կարող է ավելի լայն կամ ավելի նեղ լինել, քան ձեր FortiGate-ն է առաջարկում։ Եթե երկու հավաքածուները համընկնում են IKE-ի համար, բայց ոչ PFS-ով ESP-ի համար, դուք ստանում եք հենց այս ձախողման օրինաչափությունը։

Այս միայն-ընթերցման տեսքը ցույց է տալիս իրականում կցված քաղաքականությունը՝ առանց գաղտնիքներ բացահայտելու.

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

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

Պորտալում Configuration էջն այն տեղն է, որտեղ տեղադրվում է հատուկ IPsec/IKE քաղաքականությունը։ Microsoft-ի հատուկ քաղաքականությունների ուղեցույցը թվարկում է աջակցվող պարամետրերը և SKU պահանջները։ Azure-ը մեկ միացման համար վերցնում է մեկ ամբողջական համակցություն, ուստի դուք IKE դաշտերը և IPsec դաշտերը նշում եք միասին, ոչ թե մեկ առ մեկ։

PFS-ը պահանջ է, ոչ թե շրջելու անջատիչ

Եթե ձեր անվտանգության հիմնագիծը պահանջում է PFS, լուծումը մի խումբ է, որն ընդունում են երկու peer-երը երկու կողմերում՝ արտահայտված համապատասխան քաղաքականությամբ։ PFS-ն անջատելը, որպեսզի սխալը անհետանա, փոխում է այն անվտանգության հատկությունը, որը դուք փորձում էիք պահպանել, և այն սովորաբար ավելի ուշ վերադառնում է որպես այլ անհամապատասխանություն։

Azure-ին հատուկ մեկ թակարդ. երբ ESP-ի համար ընտրում եք GCM, գաղտնագրման և ամբողջականության ընտրությունները պետք է նշեն նույն GCM ալգորիթմը և նույն բանալու երկարությունը։ GCM ծածկագիրը առանձին ամբողջականության ալգորիթմի հետ խառնելը տալիս է համակցություն, որը ծառայությունը մերժում է, և դա peer-երի անհամապատասխանության տեսք ունի, քանի դեռ ուշադիր չեք կարդացել քաղաքականությունը։

Ընտրեք ամենաուժեղ համակցությունը, որն աջակցում են երկու ծայրերը և թույլ է տալիս ձեր պահանջը, ապա գրեք այն փոփոխությունների գրանցամատյանում։ Հաջորդ մարդը կհամեմատի այդ գրանցամատյանի հետ, ոչ թե աշխատող թունելի հիշողության հետ։ Դրա մեջ ներառեք PFS խումբը և ESP առաջարկը, ոչ միայն քաղաքականության անունը։ Երբ ավելի ուշ ինչ-որ մեկը հարցնի, թե ինչու աուդիտը ձախողվեց կամ ինչու է բանալու նորացումը դանդաղ, այդ տողը պատասխանում է երկու հարցերին էլ։

Ստուգեք ձախողված փոխանակումը

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

Արժե անվանել երկու կեղծ հետք։ SA-ների կյանքի տևողությունները տեղական բնութագրեր են, ուստի անհավասար արժեքները նորմալ են, և դրանց փոփոխությունը միայն տեղափոխում է, թե երբ է խնդիրը ի հայտ գալիս։ DPD-ն հայտնաբերում է՝ peer-ը կենդանի է, թե ոչ. դրա ժամկետի բարձրացումը չի հավասարեցնում ESP կամ PFS ընտրությունները։

Գրանցեք բանակցված արդյունքը և փոփոխությունից հետո հաջորդ իրադարձությունը։ Եթե միացումն այժմ ձախողվում է մինչև IKE նույնականացման ավարտը, դուք նայում եք հենց նոր խմբագրած IKE կարգավորումներին, ոչ թե սկզբնական CHILD-նորացման ձախողմանը։