strongSwan-ը EC2-ում. թող VPC-ն երթուղավորի աշխատանքային ծանրաբեռնվածությունը

Թունելը գործում է, դարպասի օրինակը կարող է ping անել հեռավոր ցանցին, սակայն կողքի հավելվածի օրինակը ոչնչի չի հասնում։ Ոչինչ կոտրված չէ։ Հաջողված փորձարկումը սկսվել է VPN հոսթից, և այն երբեք չի հարցրել՝ կարո՞ղ է արդյոք այդ հոսթը կրել այլ աղբյուրի հասցե նույն IPsec հարաբերության միջով։ Այս ուղեցույցը փակում է այդ բացը չորս քայլով՝ այն հաջորդականությամբ, որը յուրաքանչյուր ձախողում տեսանելի է պահում։

Նախ գրեք չորս հասցեները

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

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Օրինակը ենթադրում է հաստատված, աշխատող քաղաքականության վրա հիմնված IPsec կապ և աղբյուրը պահպանող հոսք։ Սա NAT-ով հեռահար մուտքի հաճախորդ չէ, որը վերցնում է մեկ հատկացված հասցե, և այդ տարբերությունը որոշում է՝ արդյոք ընտրիչները պետք է փոխվեն։

Քայլ 1. տվեք աշխատանքային ծանրաբեռնվածության ենթացանցին երթուղի

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

AWS-ի սարքով երթուղավորման ուղեցույցը նկարագրում է ցանցային ինտերֆեյսի թիրախները և փոխանցող օրինակի աղբյուր/նպատակակետ ստուգման պահանջը։ Սահմանափակեք այդ ստուգման փոփոխությունը դարպասի դերով և սովորական հավելվածների օրինակները հանգիստ թողեք։

Մի՛ փոխարինեք VPC-ի լոկալ երթուղին կամ յուրաքանչյուր գոյություն ունեցող գրառումը մեկ հաստատված ցանցի համար տեղ ազատելու նպատակով։ Ստուգեք, թե ինչն է կապված և ակտիվ, և ոչ թե այն, ինչ ցույց է տալիս կոնսոլի էջը այն երթուղավորման աղյուսակի համար, որը ոչ ոք չի օգտագործում։ Երկու նմանատիպ աղյուսակ կարող են տարբեր կապեր ունենալ։ Կարևորը այն է, որին միացված է աշխատանքային ծանրաբեռնվածության ենթացանցը։

Քայլ 2. միացրեք փոխանցումը հյուրի վրա

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

Անվտանգության խմբերն այն տեղն են, որտեղ այս քայլը սովորաբար կանգ է առնում։ Միջանկյալ սարքը չի ժառանգում օրինակների ուղղակի հաղորդակցության անվտանգության խմբի հղումային վարքը, ուստի կառավարվող Client VPN-ի օրինակից պատճենված կանոնը կարող է երբեք չհամընկնել։ Ստուգեք անվտանգության խումբը և ենթացանցի ACL-ը իրական ուղու վրա՝ երկու ուղղություններով։

Քայլ 3. ընդարձակեք ընտրիչները իրական աղբյուրների վրա

AWS կողմում միայն 10.60.1.10/32-ը ընդգրկող քաղաքականությունը բացատրում է դարպասից սկսված հաջողությունը՝ չընդգրկելով 10.60.2.20-ը։ Հեռավոր նպատակակետի ուղղությամբ երթուղին չի ընդարձակում թրաֆիկի ընտրիչը, և դա նույն անակնկալի երկրորդ կեսն է։

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Եթե համաձայնեցված նախագիծը պաշտպանում է ամբողջ VPC-ն, երկու կողմերն էլ պետք է ընդունեն 10.60.0.0/16 և 10.90.0.0/24։ Եթե այն պաշտպանում է մեկ աշխատանքային ծանրաբեռնվածություն, ապա գիտակցաբար օգտագործեք այդ ավելի նեղ նախածանցը։ Ամեն դեպքում ստուգեք տեղադրված CHILD-SA քաղաքականությունը, որովհետև ձեր խմբագրած կոնֆիգուրացիան և այն կողմը, որը նեղացրել է այն այլ կերպ, նույն պայմանավորվածությունը չեն։

Հեռավոր տեղամասը նույնպես պետք է պահպանված VPC աղբյուրների պատասխանները հետ երթուղավորի նախատեսված IPsec դարպասով։ Պահպանեք աջակցվող NAT բացառությունը պաշտպանված թրաֆիկի համար այնտեղ, որտեղ կան աղբյուրի NAT այլ կանոններ. չհաստատված աշխատանքային ծանրաբեռնվածությունը թույլատրված հոսթի հասցեի վերածելը այլ ինքնության պայմանագիր է, ոչ թե կարճ ուղի դեպի ցանկալի մուտքը։

Քայլ 4. ստուգեք, ապա անհրաժեշտության դեպքում հետ գլորեք

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

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

Հետ գլորելը շրջում է նույն հաջորդականությունը։ Հեռացրեք աշխատանքային ծանրաբեռնվածության ենթացանցի երթուղին վերջինը՝ նախորդ ընտրիչները վերականգնելուց հետո, որպեսզի չթողնեք ենթացանց, որը ցույց է տալիս դարպասին, որն այլևս չի պաշտպանում իր աղբյուրները։ Երբ այս պայմանագրերը գործում են, ինքնահոսթինգը կարող է սպասարկել ավելին, քան դարպասի հոսթը, իսկ AWS-ի կողմից կառավարվող Site-to-Site VPN-ը այլ գործառնական մոդել է, որտեղ strongSwan-ը կարող է նստել հաճախորդի դարպասի կողմում։