VGW թե TGW? Որտեղ է ավարտվում AWS Site-to-Site-ի IPsec թունելը

Մարդիկ հարցնում են, թե որտեղ է AWS Site-to-Site VPN-ը դադարում պաշտպանել փաթեթը, և սպասում են մեկ պատասխանի՝ դարպասի մոտ։ Այդ պատասխանի օգտակար տարբերակը նշում է, թե որ դարպասը, որովհետև վիրտուալ մասնավոր դարպասը և տրանզիտ դարպասը տարբեր կարգավորումներ են՝ տարբեր կցորդի օբյեկտներով, և սխալը ենթադրող գրախոսը գնահատման մնացած մասը կառուցում է մի դիագրամի վրա, որը գոյություն չունի։ Կատարեք ստորև նշված երեք ստուգումները հերթականությամբ։ Յուրաքանչյուրը կա՛մ հաստատում է սահմանը, կա՛մ ասում է, որ նախորդ պատասխանը վերաբերում էր այլ ռեսուրսի։

Անվանեք երեք վերջնակետերը, նախքան որևէ բան գնահատելը

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

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

Ստուգում 1՝ ո՞ր դարպասն է իրականում վերջացնում թունելը

Երկու կարգավորումներն էլ աջակցվում են, և Site-to-Site VPN-ի ճարտարապետության ուղեցույցը նկարագրում է դրանք կողք կողքի, ուստի հարցրեք API-ին, այլ ոչ թե դիագրամի, որը հաճախ մեկ տարվա վաղեմության է։ Մեկ կապի վրա միայն կարդալու հարցումը վերադարձնում է VPN նպատակակետի դաշտերը՝

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

Տարբերիչը TransitGatewayId-ն է, ոչ VpnGatewayId-ը։ Կապը, որում TransitGatewayId-ը դատարկ է, ավարտվում է առանձին վիրտուալ մասնավոր դարպասում, մինչդեռ կապը, որում այդ դաշտը սահմանված է, ավարտվում է տրանզիտ դարպասի VPN կցորդում, և VpnGatewayId-ը այդ դեպքում կարող է դեռ լրացված լինել, որովհետև այն կարող է անվանել կցորդի կրող դարպասը։ Նախ կարդացեք TGW դաշտը, ապա հաստատեք կցորդի տեսակը կցորդների ցանկից, այլ ոչ թե դաշտի անունից, որովհետև այդ տրանզիտ դարպասի վրա VPC կցորդը VPN կցորդը չէ։ Նպատակակետ ինստանսը կցված VPC-ում գտնելը ոչինչ չի ասում այն մասին, թե որ VPN կցորդն է տեղափոխել փաթեթը։

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

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Ստուգում 2՝ ինչ է դեռ կրում ներքին փաթեթը

Երբ IPsec-ը ավարտվում է, AWS-ը վերափաթեթավորված փաթեթն ուղարկում է այն երթուղով, որը համապատասխանում էր դրան։ Այդ պահից երթևեկությունը սովորական VPC երթևեկություն է, և VPN-ի պաշտպանությունն ավարտվել է։ Սա ծառայության բաց չէ, սա է սահմանի իմաստը, և ստուգաթերթի կետն այն է, որ դա հստակ ասվի՝ փոխարենը թույլ տալով, որ «VPN-ը գաղտնագրված է»-ը փոխարինի «տվյալները գաղտնագրված են ծայրից ծայր»-ին։

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

Սովորական ավելորդ ուղղումը եզրակացնելն է, որ դարպասի հետևում ամեն ինչ բաց է։ Այդպես չէ։ Ծառայության տեղափոխումը, պահեստավորման գաղտնագրումը և հավելվածի TLS-ը առանձին մեխանիզմներ են՝ առանձին պայմաններով, և յուրաքանչյուրը պետք է գնահատվի իր պայմաններով, այլ ոչ թե ենթադրվի VPN-ի ձևից։ Հոսքի մատյանի գրառումը, որը ցույց է տալիս ACCEPT, ապացուցում է, որ երթուղավորումն աշխատել է, և ոչինչ չի ասում գաղտնիության մասին, ինչը հենց այն սխալն է, որին այս ստուգաթերթը գոյություն ունի կանխելու։

Ստուգում 3՝ ինչն է վերջացնում TLS-ը դարպասի հետևում

Հետևեք լսողին, ոչ թե հասցեին։ Եթե բեռնվածքի հավասարակշռիչը կամ պրոքսին վերջացնում է TLS-ը, ձեր հաճախորդի պահած կապն ավարտվում է այնտեղ, և պրոքսին երկրորդ կապ է բացում դեպի բեքենդ, որը կարող է լինել բաց տեքստ կամ այլ վստահության շղթայով TLS։ Մասնավոր IP հասցեն և համապատասխան երթուղին ապացույց չեն այդ երկրորդ կապի մասին։

Փորձարկեք այն վերջնակետը, որն իրոք ձեզ համար կարևոր է, VPC-ի ներսից, այն անունով, որն օգտագործում է հավելվածը, այլ ոչ թե IP-ով, որը մի անգամ լուծել եք՝

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

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

Արդյունքը գրանցեք որպես հատվածներ, ոչ թե որպես դատավճիռ

Այս ստուգաթերթի ելքը փոքր աղյուսակ է՝ մեկ տող յուրաքանչյուր հատվածի համար՝ հաճախորդի դարպասից AWS VPN նպատակակետ, դարպասից աշխատանքային բեռ, աշխատանքային բեռից տվյալների պահոց, և արանքում ցանկացած պրոքսի թռիչք։ Յուրաքանչյուր տող ասում է, թե ինչն է պաշտպանում այն և ինչից է կախված այդ պաշտպանությունը։ «Գաղտնագրված»-ը առանց մեխանիզմի և առանց վերջնակետի տող չէ։

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

Պահեք կապերի նույնացուցիչները, թունելների վիճակները և վկայագրերի սուբյեկտները գրառման մեջ։ Երբ ինչ-որ մեկը վեց ամիս անց վերադառնա նախագծին, այդ երեք արտեֆակտները րոպեների ընթացքում կպատասխանեն սահմանի հարցին՝ դիագրամից վեճը նորից սկսելու փոխարեն։