Ինչ է ներառում IPsec-ի առաջարկը. IKE և ESP դաշտեր
Առաջարկը մեկ ամբողջական առաջարկ է, ոչ թե ալգորիթմների պարկ։ Տեսեք, թե որ դաշտերն են պատկանում IKE-ին և որոնք՝ ESP-ին, և ինչու մեկ անհամապատասխանությունը մերժում է ամբողջ հավաքածուն։
IKE-ն սկսվում է, երկու կողմերն էլ հայտարարում են AES, սակայն թունելը դեռ ձախողվում է NO_PROPOSAL_CHOSEN-ով։ Մատյանը նշում է առաջարկը, բայց ոչ այն դաշտը, որը չի համապատասխանել։ Առաջարկը մեկ ամբողջական առաջարկ է, և մեկ անհամատեղելի դաշտը անվավեր է դարձնում ամբողջ համակցությունը, ոչ միայն այդ տողը։ Այն որպես անկախ ալգորիթմների ընտրությունների պարկ կարդալը սովորական պատճառն է, թե ինչու անհամապատասխանությունը մնում է անտեսանելի։
Երկու բանակցություն՝ առանձին առաջարկների ցանկերով
IKEv2-ը կառուցում է երկու անվտանգության միավորում։ Առաջինը IKE SA-ն է, որը պաշտպանում է կառավարման փոխանակումը, իսկ երկրորդը՝ CHILD SA-ն, որը ձեր տրաֆիկը տեղափոխում է ESP-ով։ Յուրաքանչյուրն ունի իր առաջարկների ցանկը, և կողմը կարող է ընդունել մեկը և մերժել մյուսը։
Այդ բաժանումը բացատրում է սովորական շփոթություն. աշխատող IKE SA-ն ապացուցում է միայն, որ կառավարման ալիքի ալգորիթմները համապատասխանել են։ Եթե CHILD առաջարկը ձախողվի, թունելը ոչ մի փաթեթ չի տեղափոխի, թեև առաջին փուլը ավարտված է, և մատյանները վերևում առողջ են երևում։
Յուրաքանչյուր ցանկի ներսում հերթականությունը նույնպես կարևոր է։ Պատասխանողը ընտրում է նախաձեռնողի դասավորված առաջարկներից, ուստի լայնորեն համատեղելի գրառումը նեղ գրառումից վեր տեղափոխելը փոխում է, թե որ հավաքածուն կտեղադրվի՝ չփոխելով ոչ մի ալգորիթմի անուն։ Ամրագրեք այդ հերթականությունը կազմաձևում՝ լռելյայն արժեքներին հույս դնելու փոխարեն։ Կայուն հերթականությունը նաև իմաստալից է դարձնում կայքերի միջև մատյանների համեմատությունը։
Որ դաշտերն են պատկանում որ առաջարկին
Դաշտերի հավաքածուն փոքր է, բայց երկու բանակցություններում նույնը չէ։ Կարդացեք աղյուսակը տող առ տող, որովհետև մի սյունակի դաշտը կարող է բացակայել մյուսում։ Շարահյուսությունը տարբերվում է՝ կախված իրականացումից, իսկ strongSwan-ի առաջարկների փաստաթղթերը մեկ կոնկրետ հղում են։
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
Գաղտնագրման դաշտը նշում է ծածկագրիչը և շարահյուսությունների մեծ մասում՝ դրա բանալու երկարությունը։ Ամբողջականության դաշտը նշում է հեշը, որն օգտագործվում է գաղտնագրված տեքստի նույնականացման համար, իսկ PRF-ը նշում է ֆունկցիան, որը բանալային նյութ է ածանցում IKE SA-ի համար։ DH խումբը ստեղծում է թարմ ընդհանուր գաղտնի նյութ, այդ պատճառով այն հայտնվում է երկու կողմերում, բայց տարբեր նպատակներով։
Ընդլայնված հաջորդականության համարները պատկանում են միայն տվյալների ուղուն։ Դրանք լայնացնում են հաջորդականության տարածքը և բանակցվում են CHILD առաջարկի մասով, ուստի այնտեղ անհամապատասխանությունը մերժում է CHILD առաջարկը՝ IKE SA-ն անձեռնմխելի թողնելով։
Ինչպես է ընտրվում մեկ ամբողջական առաջարկ
Յուրաքանչյուր առաջարկ հավաքածու է, և պատասխանողը փնտրում է հավաքածու, որտեղ յուրաքանչյուր պարտադիր դաշտ ընդունելի է։ Երկու ցանկեր կարող են երկուսն էլ պարունակել AES և SHA-256 և այնուամենայնիվ չունենալ ոչ մի համատեղելի գրառում, որովհետև բանալու երկարությունը, PRF-ը կամ DH խումբը տարբերվում են։ Համեմատությունը կատարվում է առաջարկով, ոչ թե ալգորիթմով։
Երբ ոչինչ չի համապատասխանում, պատասխանողն ուղարկում է NO_PROPOSAL_CHOSEN ձախողված SA տեսակով։ Կարդացեք, թե որ առաջարկների ցանկին է վերաբերում ծանուցումը, նախքան կազմաձևը խմբագրելը՝ ESP ալգորիթմների փոփոխությունը, երբ IKE առաջարկը մերժվել է, վատնում է վրիպազերծման մեկ ցիկլ։
Արժե իմանալ ընտրության վարքը, երբ պրոֆիլ եք կարգավորում։ Որոշ իրականացումներ նախընտրում են նախաձեռնողի հերթականությունը, մյուսները վերադասավորում են ըստ տեղական քաղաքականության, ուստի երկու մատակարարների միջև աշխատող հավաքածուն կարող է անհետանալ երբ շրջեք, թե որ կողմն է սկսում միացումը։
AEAD-ը դաշտ հեռացնում է, ոչ թե ավելացնում
AES-GCM-ը և ChaCha20-Poly1305-ը նույնականացնում և գաղտնագրում են մեկ գործողությամբ։ Երբ դրանցից որևէ մեկն ընտրվում է ESP-ի համար, ամբողջականության ալգորիթմը առանձին չի բանակցվում, որովհետև AEAD կառուցվածքն արդեն ծածկում է այն։ Ուստի AES-GCM-ը SHA-256-ի հետ զուգակցող առաջարկը լավագույն դեպքում ավելորդ է, իսկ վատագույն դեպքում՝ մերժված։
PRF-ը IKE կողմում դեռ առանձին է, քանի որ այն բանալիներ է ածանցում կառավարման ալիքի համար, այլ ոչ թե պաշտպանում է բեռնվածքը։ Այդ պատճառով IKE առաջարկը կարող է օրինականորեն համատեղել AEAD ծածկագրիչը PRF-ի և DH խմբի հետ, մինչդեռ համապատասխան ESP առաջարկը թվարկում է միայն AEAD ծածկագրիչը և ընտրովի PFS խումբը։
Բանալու երկարությունը գաղտնագրման նշանի մասն է, ուստի AES-128-GCM-ը և AES-256-GCM-ը տարբեր առաջարկներ են։ Ուղեցույցից պատճենված պրոֆիլը, որը ենթադրում էր 256-bit բանալիներ, չի համապատասխանի 128-bit-ի համար կարգավորված վերջնակետին, թեև երկու տողերն էլ ասում են AES-GCM։ Երկու կողմեր կարող են համաձայնել ծածկագրիչների ընտանիքի շուրջ և այնուամենայնիվ մերժել միմյանց գծիկից հետո եկող թվի պատճառով։
Կարդացեք տեղադրված SA-ն, ոչ թե կազմաձևը
Կարգավորված առաջարկների ցանկը առաջարկ է, իսկ տեղադրված SA-ն՝ արդյունքը։ strongSwan-ում և Linux միջուկում երկու տեսքն էլ հասանելի են:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas տպում է յուրաքանչյուր SA-ի համար բանակցված ալգորիթմները, ներառյալ՝ արդյոք CHILD-ը օգտագործում է AEAD։ ip xfrm state ցույց է տալիս, թե ինչ է իրականում տեղադրել միջուկը, և հենց այստեղ է հաստատվում, որ բանալիների նորացումը չի վերադարձել ձեր փաստաթղթավորածից տարբեր հավաքածուի։
Ուղղումից հետո պահպանեք այդ ելքը կազմաձևի կողքին։ Երբ հաճախորդի թարմացումը փոխում է լռելյայն արժեքները, գրանցված հավաքածուն ձեզ համեմատության հիմք է տալիս, և համեմատությունը մատնանշում է տեղաշարժված դաշտը՝ հետաքննությունը սկզբից սկսելու փոխարեն։