AWS Client VPN թե bastion՝ peered VPC հասնելու համար

Client VPN-ի մեկ endpoint-ը կարող է հասնել VPC-ի, որը peering-ով կապված է իր հետ կապակցված VPC-ի հետ, և դա օրինական դարձնելու համար bastion պետք չէ։ Ընտրությունը, որն արժե անել, այն է, թե որտեղ է երթևեկությունը փոխում ձեռքերը՝ endpoint-ի երթուղի, որը վայրէջք է կատարում association ենթացանցում և անցնում peering կապով, կամ host peered VPC-ում, որը ավարտում է սեսիան։ Երկու ուղիներն էլ աշխատում են և ձախողվում տարբեր տեղերում, ուստի որոշումը սեփականության և աուդիտի մասին է, ոչ թե այն մասին, ինչ թույլատրում է AWS-ը։ Ահա թե ինչպես եմ ընտրում նրանց միջև, և այն չորս գրառումները, որոնք աշխատեցնում են երթուղավորված ուղին։

Երկու ուղի, մեկ endpoint, տարբեր սեփականատերեր

Երթուղավորված ուղու վրա հաճախորդի երթևեկությունը հասնում է endpoint-ին, թարգմանվում է association ենթացանցում Client VPN ցանցային ինտերֆեյսի հասցեի, և լքում է այդ ենթացանցը A-ից B peering կապով։ VPC B-ն ոչ մի VPN սեսիա չի ավարտում. այն տեսնում է սովորական երթևեկություն VPC A-ից, դրա համար էլ նրա վերադարձի երթուղին ուղղված է VPC A-ին, ոչ թե հաճախորդների լողավազանին։

bastion ուղու վրա հաճախորդը նախ հասնում է host-ին։ A-ում bastion-ը դեռ թողնում է վերջին ցատկը անցնել peering կապով, ուստի դուք պահպանում եք peering աշխատանքը և ավելացնում սեսիա։ B-ում bastion-ին նույնպես պետք է ուղի հաճախորդից, և երբ այդ ուղին նույն endpoint երթուղին է, դուք ունեք երթուղավորված ձևավորում գումարած մեկ ցատկ։ bastion-ը հանում է աշխատանք միայն այն ժամանակ, երբ այն արդեն գոյություն ունի, արդեն հաստատված է, և նրա հետևում գտնվողը պահանջում է սեսիայի սահման, ոչ թե ցանցի սահման։

Չորս գրառում աշխատեցնում են երթուղավորված ուղին

AWS-ը փաստագրում է այս սցենարը Client VPN how-it-works էջում, և գործնականում ամեն ինչ հանգում է չորս գրառումների, որոնք պատկանում են երկու կամ երեք թիմերի։ Միջակայքերը պատկերավոր են. peered միջակայքը պետք է լինի եզակի, իսկ վերադարձի միջակայքը պետք է համապատասխանի ձեր պլանին։

Երթուղին և թույլտվությունը առանձին վերահսկիչներ են։ Ճիշտ endpoint երթուղին առանց համապատասխան լիազորման կանոնի հաճախորդին ոչինչ չի տալիս. նպատակակետի համար լիազորման կանոնը, որը endpoint-ը չի կարող երթուղավորել, նրան սև փոս է տալիս։ Երկուսն էլ պետք է նշեն նույն միջակայքը։

endpoint-ի երթուղին ուղղված է endpoint-ի սեփական VPC-ի ենթացանցին, երբեք peering կապին։ VPC-ի երթուղիների աղյուսակները ուղղված են peering կապին, երբեք instance-ին կամ ինտերֆեյսին։ Արժեքը նրանց միջև պատճենելը պահվում է առանց բողոքի և ոչինչ չի երթուղավորում։

Քանի որ association ենթացանցը թարգմանում է հաճախորդի աղբյուրը, B-ն պետք է երթուղավորի հետ դեպի VPC A, ոչ թե հաճախորդների լողավազան։ Հաճախորդի միջակայքը peering կապով ուղարկելը սիմետրիկ է թվում, անցնում է վերանայումը և լուռ ձախողվում, որովհետև B-ն երբեք չի տեսնում հաճախորդի աղբյուրով փաթեթ։

Անվտանգության խմբեր և թույլտվության վերջին մետրը

Երթուղավորումը փաթեթները բերում է B. B-ն դեռ որոշում է։ Նույն տարածաշրջանում ակտիվ peering կապի համար B-ում անվտանգության խումբը կարող է հղում կատարել Client VPN association-ի վրա կիրառված խմբին, ինչը կանոնը պահում է նեղ և դիմանում հասցեների փոփոխություններին։ Այնտեղ, որտեղ խմբի հղումը հնարավոր չէ, թույլատրեք association ենթացանցի միջակայքը բացահայտորեն՝ 0.0.0.0/0-ի ընդլայնելու փոխարեն, ինչը երթուղավորման սխալը վերածում է անբացատրելի timeout-ի։

Այնուհետև ստուգեք այն, ինչին երթուղավորումը երբեք չի դիպչում՝ ցանցային ACL-ները երկու ենթացանցերում, հավելվածի թույլատրվածների ցանկը կամ token-ի լսարանը, և DNS-ը։ peering-ը չի պատճենում մասնավոր հոսթինգի գոտիները, ուստի նոթբուքը կարող է պահել աշխատող երթուղի դեպի հասցե, որը չի կարող լուծել, և peering կապը վստահություն չի ավելացնում վկայականին։ Ուղղեք endpoint-ը resolver-ին, որը պատասխանում է B-ի համար, ապա հաստատեք, որ մասնավոր անունը և վկայականը համընկնում են։

Երբ bastion-ը ազնիվ պատասխանն է

Ես պահում եմ երեք գործարկիչ bastion-ի դիտավորյալ ընտրության համար։ peered VPC-ն պատկանում է թիմի, որը չի ավելացնի վերադարձի երթուղի ձեր միջակայքի համար կամ չի ընդունի խմբի հղում։ Մուտքը պետք է հաստատվի կամ գրանցվի յուրաքանչյուր սեսիայի համար, և հավելվածը չի կարող ինքնուրույն կրել դա։ Կամ վերջին ցատկը պետք է մնա B-ի ներսում, որովհետև ծառայությունը լուծվում է միայն այնտեղ, և նրա TLS ինքնությունը ամրացված է ներքին անվանը։

Այս ոչ մեկը շրջանցում չէ այն փաստի, որ peering-ը տրանզիտիվ չէ։ Ոչ տրանզիտիվությունը սահմանափակում է, թե ինչ կարող են անել B-ի ռեսուրսները. նրանք չեն կարող A-ն օգտագործել որպես տրանզիտ երրորդ VPC-ի, որի հետ A-ն peering-ում է։ Դա երբեք չի նշանակել, որ VPN օգտատերը չի կարող հասնել ուղղակիորեն peered VPC-ին, և այդ սխալ ընթերցումը շրջանցելու համար կառուցված bastion-ը host է, որը patch-վում է առանց պատճառի։

Հակառակ սխալը ժամանակի ընթացքում ավելի թանկ է նստում. անցկացրեք յուրաքանչյուր թիմի արդեն գոյություն ունեցող միակ bastion-ով, ապա պարզեք, որ նրա անվտանգության խումբը, երթուղիների աղյուսակը և patch-ի պատուհանը արտադրական կախվածությունն են։ Գրեք, թե որ գործարկիչին է ծառայում host-ը, և հանեք այն շահագործումից, երբ գործարկիչը վերանա։

Transit Gateway-ը և մի քանի association փոխում են թվաբանությունը

Եթե endpoint-ը կցված է ուղղակիորեն Transit Gateway-ին, այլ ոչ ենթացանցին, մոդելը փոխվում է. հաճախորդներն այլևս չեն թարգմանվում association ենթացանցի ինտերֆեյսի հասցեի, և gateway-ի երթուղիների աղյուսակները պետք է կրեն հաճախորդի միջակայքը գումարած կցումը, որը տանում է peered VPC։ Դա ավելի մաքուր է մասշտաբով, բայց աշխատանքը տեղափոխվում է չորս գրառումներից gateway-ի երթուղիների աղյուսակներ։

Մի քանի association բազմապատկում են ստուգումները։ endpoint-ի երթուղին պատկանում է endpoint-ին, սակայն յուրաքանչյուր association ենթացանց պահանջում է երթուղիների աղյուսակ իրական peering հաջորդ ցատկով։ Սեսիան կարող է հաջողվել մեկ association-ով, մինչ դուրսը վերադարձի ուղի չունի, ուստի փորձարկեք յուրաքանչյուրը։

Ստուգման հաջորդականություն, որը արագ գտնում է խափանումը

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

1. Լուծեք հավելվածի անունը հաճախորդից և ստուգեք, որ հասցեն peered միջակայքի ներսում է։
2. Միացեք, ապա կարդացեք endpoint-ի միացումների մատյանը այն association-ի համար, որը ավարտեց սեսիան։
3. Այդ association ենթացանցում հաստատեք, որ երթուղիների աղյուսակը peered միջակայքը ուղղում է ակտիվ peering կապի։
4. B-ի ռեսուրսային ենթացանցում հաստատեք ինտերֆեյսի միջակայքի վերադարձի գրառումը և համապատասխան խմբի կանոնները։
5. Փորձարկեք մեկ թույլատրված գործողություն և մեկ ռեսուրս, որը պետք է մնա անհասանելի. երկրորդը բռնում է կարգաբերման մնացորդները։
6. Կրկին միացեք split-tunnel երթուղու ցանկացած փոփոխությունից հետո, որովհետև աշխատող թունելը նոր երթուղիների հավաքածու չի վերցնի։

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

Եթե երեք գործարկիչներից ոչ մեկը չի գործում, ավարտեք երթուղավորված ուղին և գրանցեք այդ չորս գրառումները։ Եթե մեկը գործում է, պահեք bastion-ը միայն այդ սահմանի համար և թողեք endpoint-ի երթուղին այն ծառայություններին, որոնց առջևում սեսիա պետք չէ։