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 сервиса или шифрование хранилища, настроенные и проверенные отдельно.

Сохраняйте идентификаторы подключений, состояния туннелей и субъекты сертификатов в записи. Когда кто-то вернётся к проектированию через полгода, эти три артефакта ответят на вопрос о границе за минуты вместо того, чтобы начинать спор заново со схемы.