VGW же TGW? AWS Site-to-Site IPsec туннели кайда бүтөт

Адамдар AWS Site-to-Site VPN пакетти кайдан коргоону токтоторун сурап, бир жооп күтүшөт: дарбазада. Бул жооптун пайдалуу версиясы кайсы дарбаза экенин атайт, анткени виртуалдык жеке дарбаза менен транзиттик дарбаза ар кандай тиркеме объектилери бар ар кандай түзүлүштөр, ал эми туура эмес деп болжолдогон рецензент баалоонун калганын жок диаграммага курат. Төмөнкү үч текшерүүнү ирети менен аткарыңыз. Ар бири чекти ырастайт же мурунку жооп башка ресурс жөнүндө болгонун айтат.

Бир нерсени баалардан мурун үч акыркы чекитти атаңыз

Бул жолдун шифрлоо кароосуна үч аталган нерсе керек: кардар дарбазасы, IPsecти бүтүргөн AWS VPN максаты жана ички пакетти кабыл алган колдонмонун акыркы чекити. Бир консоль баракчасын ачканга чейин аларды ресурс идентификаторлору менен жазып коюңуз, анткени бул чекиттен кийинкинин баары ошол үчөөнүн бири жөнүндө билдирүү.

Кардар дарбазасы сиздики жана анын конфигурациясы сизге көрүнөт. 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и же сактоо шифрлоосу өзүнчө конфигурацияланып, текшерилиши керек.

Туташуу идентификаторлорун, туннелдердин абалын жана сертификат субъектилерин жазууда сактаңыз. Бирөө алты айдан кийин дизайнга кайрылганда, бул үч артефакт чек суроосуна бир нече мүнөттө жооп берет, диаграммадан талашты кайра баштоонун ордуна.