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 сервісу або шифрування сховища, налаштованих і перевірених окремо.

Зберігайте ідентифікатори з'єднань, стани тунелів і суб'єкти сертифікатів у записі. Коли хтось повернеться до проєктування за пів року, ці три артефакти дадуть відповідь на питання про межу за кілька хвилин, а не почнуть суперечку заново зі схеми.