VGW или TGW? Къде завършва IPsec тунелът на AWS Site-to-Site

Хората питат къде 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 на услугата или криптиране на хранилището, конфигурирани и проверени отделно.

Пазете идентификаторите на връзките, състоянията на тунелите и субектите на сертификатите в записа. Когато някой се върне към дизайна след шест месеца, тези три артефакта отговарят на въпроса за границата за минути, вместо да започват спора отново от диаграма.