AWS Client VPN или bastion для доступа к VPC с peering

Один endpoint Client VPN может достучаться до VPC, который соединён peering с его связанным VPC, и для законности этого bastion не нужен. Выбор, который стоит сделать, — где трафик меняет хозяина: маршрут endpoint, который попадает в подсеть ассоциации и пересекает peering-соединение, или хост в VPC с peering, который завершает сеанс. Оба пути работают и отказывают в разных местах, поэтому решение о владении и аудите, а не о том, что разрешает AWS. Вот как я выбираю между ними, и четыре записи, которые заставляют маршрутизируемый путь работать.

Два пути, один endpoint, разные владельцы

На маршрутизируемом пути трафик клиента доходит до endpoint, транслируется в адрес сетевого интерфейса Client VPN в подсети ассоциации и покидает эту подсеть через peering-соединение из A в B. VPC B не завершает ни одного VPN-сеанса; он видит обычный трафик из VPC A, поэтому его обратный маршрут указывает на VPC A, а не на пул клиентов.

На пути через bastion клиент сначала попадает на хост. Bastion в A всё ещё оставляет последний переход за peering-соединением, поэтому работа peering остаётся, а сеанс добавляется. Bastion в B тоже требует пути от клиента, и когда этот путь — тот же маршрут endpoint, вы получаете маршрутизируемую схему плюс один переход. Bastion убирает работу только тогда, когда он уже существует, уже одобрен, и тому, что за ним, нужна граница сеанса, а не граница сети.

Четыре записи заставляют маршрутизируемый путь работать

AWS описывает этот сценарий на странице Client VPN how-it-works, и на практике всё сводится к четырём записям, которыми владеют две или три команды. Диапазоны приведены для примера; диапазон с peering должен быть уникальным, а обратный диапазон должен соответствовать вашему плану.

Маршрут и разрешение — разные средства контроля. Правильный маршрут endpoint без подходящего правила авторизации ничего не даёт клиенту; правило авторизации для адресата, который endpoint не может маршрутизировать, даёт ему чёрную дыру. Оба должны называть один и тот же диапазон.

Маршрут endpoint указывает на подсеть в собственном VPC endpoint, никогда на peering-соединение. Таблицы маршрутов VPC указывают на peering-соединение, никогда на инстанс или интерфейс. Копирование значения между ними сохраняется без возражений и ничего не маршрутизирует.

Поскольку подсеть ассоциации транслирует источник клиента, B должен маршрутизировать обратно в VPC A, а не в пул клиентов. Отправка клиентского диапазона через peering-соединение выглядит симметрично, проходит проверку и тихо отказывает, потому что B никогда не видит пакет с клиентским источником.

Группы безопасности и последний метр разрешения

Маршрутизация приносит пакеты в B; решает по-прежнему B. Для активного peering-соединения в том же регионе группа безопасности в B может ссылаться на группу, применённую к ассоциации Client VPN, что держит правило узким и переживает смену адресов. Там, где ссылка на группу неосуществима, разрешите диапазон подсети ассоциации явно вместо расширения до 0.0.0.0/0, которое превращает ошибку маршрутизации в необъяснимый тайм-аут.

Затем проверьте то, чего маршрутизация никогда не касается: сетевые ACL на обеих подсетях, список разрешённых или аудиторию токена приложения, и DNS. Peering не копирует приватные хост-зоны, поэтому ноутбук может держать рабочий маршрут к адресу, который не может разрешить, а peering-соединение не добавляет доверия сертификату. Направьте endpoint на резолвер, который отвечает за B, и затем подтвердите, что приватное имя и сертификат совпадают.

Когда bastion — честный ответ

Я держу три триггера для осознанного выбора bastion. VPC с peering принадлежит команде, которая не добавит обратный маршрут для вашего диапазона или не примет ссылку на группу. Доступ должен утверждаться или записываться для каждого сеанса, а приложение не может нести это само. Или последний переход должен остаться внутри B, потому что сервис разрешается только там, а его идентичность TLS привязана к внутреннему имени.

Ничто из этого не обходит того, что peering не транзитивен. Нетранзитивность ограничивает то, что могут делать ресурсы в B: они не могут использовать A как транзит к третьему VPC, с которым A соединён peering. Это никогда не означало, что пользователь VPN не может напрямую достичь VPC с peering, а bastion, построенный в обход этого неверного прочтения, — хост, который латают без причины.

Обратная ошибка со временем стоит дороже: проведите каждую команду через единственный уже существующий bastion, а затем обнаружьте, что его группа безопасности, таблица маршрутов и окно обновлений — это производственная зависимость. Запишите, какому триггеру служит хост, и выведите его из эксплуатации, когда триггер исчезнет.

Transit Gateway и несколько ассоциаций меняют арифметику

Если endpoint подключён напрямую к Transit Gateway, а не к подсети, модель меняется: клиенты больше не транслируются в адрес интерфейса в подсети ассоциации, и таблицы маршрутов шлюза должны нести клиентский диапазон плюс подключение, ведущее к VPC с peering. В масштабе это чище, но работа переезжает с четырёх записей в таблицы маршрутов шлюза.

Несколько ассоциаций умножают проверки. Маршрут endpoint принадлежит endpoint, но каждой подсети ассоциации нужна таблица маршрутов с настоящим следующим переходом peering. Сеанс может пройти через одну ассоциацию, пока у другой нет обратного пути, поэтому проверяйте каждую.

Порядок проверки, который быстро находит поломку

Выполняйте их по порядку; каждый шаг может пройти, пока следующий отказывает, а тайм-аут клиента почти никогда не говорит, что именно сломалось.

1. Разрешите имя приложения с клиента и проверьте, что адрес находится внутри диапазона с peering.
2. Подключитесь, затем прочитайте журнал соединений endpoint для ассоциации, которая завершила сеанс.
3. В этой подсети ассоциации подтвердите, что таблица маршрутов направляет диапазон с peering на активное peering-соединение.
4. В подсети ресурсов в B подтвердите обратную запись для диапазона интерфейса и соответствующие правила группы.
5. Проверьте одну разрешённую операцию и один ресурс, который должен остаться недоступным; второй ловит остатки отладки.
6. Переподключитесь после любого изменения маршрута split-tunnel, потому что работающий туннель не примет новый набор маршрутов.

Два симптома стоит запомнить. SYN, который доходит до B без ответа, почти всегда отсутствующий обратный маршрут. Соединение, которое завершается и затем сбрасывается, обычно группа, ACL или приложение. Ни один не появляется в журнале endpoint как причина, поэтому держите четыре записи с владельцем рядом с каждой.

Если ни один из трёх триггеров не действует, завершите маршрутизируемый путь и запишите эти четыре записи. Если действует один, держите bastion только для этой границы и оставьте маршрут endpoint сервисам, которым не нужен сеанс перед ними.