strongSwan-ից AWS Site-to-Site. ինչու Child SA-ն ոչինչ չի ընտրում

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

Թարգմանեք AWS-ի անունները strongSwan-ի տերմինների

AWS-ը նկարագրում է կապը հաճախորդի կողմից՝ հաճախորդի դարպասի հասցեն և լոկալ CIDR-ը պատկանում են ձեզ, իսկ հեռավոր CIDR-ը՝ VPC-ին։ strongSwan-ը երկու ծայրերը կոչում է left և right՝ ձեր նախածանցը leftsubnet-ում է, իսկ VPC-ի նախածանցը՝ rightsubnet-ում։ Մեկ զույգը շրջելը ստեղծում է թունել, որը բանակցում և ընտրում է սխալ տրաֆիկը։

Ներբեռնեք այն կոնֆիգուրացիան, որը AWS-ը ստեղծում է կապի համար, և դիտարկեք այն որպես հենց այդ կապի հղում՝ ներառյալ թունելի հասցեները և նախածանցերը։ Եթե ստեղծելիս CIDR-ի երկու դաշտերն էլ թողնեք դատարկ, ծառայությունը յուրաքանչյուր կողմում օգտագործում է 0.0.0.0/0 լռելյայն արժեքը։ Նեղ նախածանցով կարգավորված երթուղիչն այն ժամանակ երբեք չի համապատասխանի, ուստի կամ լրացրեք դաշտերը, կամ գիտակցաբար լայնացրեք ընտրիչը։

Այստեղ անհամապատասխանությունը նման է երթուղավորման խափանման, բայց այդպիսին չէ։

Ամրացրեք այն հասցեն, որն AWS-ը իրականում տեսնում է

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

conn %default
    local_addrs = 203.0.113.10

strongSwan-ում local_addrs-ը ընտրում է IKE-ի աղբյուրի հասցեն, իսկ հին OpenSwan կոնֆիգուրացիաները նույն միտքը գրում են left անունով։ Ուղղեք այն դեպի այն ինտերֆեյսը, որն ունի հանրային հասցեն, ապա հենց NAT սարքում ստուգեք, որ UDP 500 և 4500-ը հասնում են այդ հոսթին, քանի որ նախորդ երթուղիչից մնացած կանոնը լուռ գցում է դրանք։ Ճիշտ ընտրիչների զույգը սխալ աղբյուրի հասցեով դեռ ձախողվում է, և մատյանը մեղադրելու է առաջարկը։ Հենց այդ շփոթեցնելն է պատճառը, որ աղբյուրի հասցեն արժանի է առանձին ստուգման։

Հաստատեք փոխանցման կանոնը՝ այն ենթադրելու փոխարեն, քանի որ նախորդ երթուղիչի համար ճիշտ կանոնը հաճախ մնում է։

Անդրադարձեք 1-ին և 2-րդ փուլերին առանձին

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

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Շարահյուսությունը չի տեղափոխվում իրականացումների միջև։ OpenSwan-ում աշխատող զույգը, օրինակ phase2alg=aes_gcm-ը ike=aes256-sha1;modp1024-ի հետ, պետք է թարգմանվի strongSwan-ի esp= և ike= ձևի, և ալգորիթմների անունները տարբերվում են։ Քանի որ GCM-ը նույնականացնում է գաղտնագրման ընթացքում, այն առանձին ամբողջականության փոխակերպման կարիք չունի, ի տարբերություն SHA-ի հետ զուգակցված CBC հավաքածուի։ Մեկ դեմոնից մյուսը առանց թարգմանության տեղադրված 2-րդ փուլի տողը ստեղծում է մերժում, որը կարդացվում է որպես ընտրիչների անհամապատասխանություն։

Ստուգեք զավակ ասոցիացիան, ոչ թե թունելի ցուցիչը

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

ipsec statusall

Գտեք զավակ անվտանգության ասոցիացիան և կարդացեք կողքին տպված տրաֆիկի ընտրիչները, ապա համեմատեք դրանք ստեղծված կոնֆիգուրացիայի նախածանցերի հետ։

Փորձարկեք լոկալ նախածանցի ներսում գտնվող հոսթից VPC-ի նախածանցի ներսում գտնվող հոսթ, և ստուգեք վերադարձի ուղին ու AWS-ի կողմի ցանկացած անվտանգության խումբ կամ ցանցային ACL։ Ճիշտ ընտրիչները չեն պաշտպանում փաթեթը հետագա դեն նետումից։

Երբ ընտրիչների համընկնումից հետո էլ չի աշխատում

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

Գրանցեք մեկ մուտքային և մեկ ելքային փաթեթ յուրաքանչյուր կողմում, նախքան մեկ այլ առաջարկ փոխելը։

Նշեք ընտրիչները, 1-ին և 2-րդ փուլերի առաջարկները և աղբյուրի հասցեն տոմսում։ Այս չորս արժեքները բացատրում են site-to-site-ի խափանումների մեծ մասը՝ առանց զանգի։