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-і немесе сақтау шифрлауы бөлек конфигурацияланып, тексерілуі қажет.

Қосылым идентификаторларын, туннель күйлерін және сертификат субъектілерін жазбада сақтаңыз. Біреу алты айдан кейін дизайнға оралғанда, осы үш артефакт шекара сұрағына бірнеше минутта жауап береді, диаграммадан дауды қайта бастаудың орнына.