Один VPN между площадками для нескольких VPC в AWS Transit Gateway

Подключите VPN один раз, а каждый VPC — к одному транзитному шлюзу, затем разделите связывание и распространение, чтобы филиалы видели офис, но не друг друга.

Двум VPC в этом квартале нужна офисная сеть, и именно на втором туннеле оценка ломается. AWS Transit Gateway может служить общим маршрутизирующим концентратором: VPN подключается один раз, и каждый VPC подключается к тому же центру. Затем локальная сеть достигает каждого подключённого VPC через одно соединение. Это меняет то, кому принадлежит решение о маршрутизации, и именно эту часть большинство проектов делают неправильно.

Присоединение VPN и присоединения VPC — разные объекты на одном шлюзе, поэтому связи маршрутизации приходится строить после этого.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Почему peering — не тот короткий путь, на который надеются

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

Это ограничение — свойство peering, а не квота, которую можно поднять.

Связывание и распространение делают разную работу

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

Полностью связанный небольшой центр — простой случай.

Поместите каждое присоединение в одну таблицу, и VPN вместе с обоими префиксами VPC разрешается чисто. Это также разрешает достижимость между VPC, которую организация, возможно, никогда не замышляла, потому что общая таблица не знает понятия филиала.

Маршруты рабочих нагрузок живут в другом месте

Каждой подсети рабочей нагрузки всё ещё нужен собственный маршрут к транзитному шлюзу для нужных локальных префиксов. Эти таблицы маршрутов VPC — отдельные объекты от собственных таблиц транзитного шлюза. Добавьте нужные префиксы и сохраните существующие маршруты вместо замены каждого назначения новым default. Маршрут подсети также ничего не объявляет клиентскому устройству.

Выбирайте динамическую или статическую маршрутизацию осознанно; peering не даёт ни того, ни другого.

Изолируйте филиалы, не теряя локальный доступ

Когда A и B могут обе достигать офиса, но не должны маршрутизироваться друг к другу, разделите таблицы. Связанная таблица присоединения VPN хранит префиксы VPC. Связанная таблица присоединений VPC хранит локальные префиксы, без маршрута, соединяющего A с B. Именно распространение создаёт это отношение, поэтому принимать каждое стандартное связывание не требуется.

Это изоляция маршрутизации, а не авторизация приложения.

Группы безопасности, сетевые ACL, межсетевые экраны хостов и собственные права каждой службы всё ещё решают, какой трафик допускается. Если нужна инспекция, проектируйте её поддерживаемый путь явно, а не предполагайте, что концентратор её выполнит.

Чего концентратор не исправляет

Планы адресации по-прежнему не должны пересекаться, потому что концентратор не позволяет одному префиксу обозначать две рабочие нагрузки. Каждому присоединению VPC нужна зона доступности Availability Zone, которую ожидают его рабочие нагрузки. С BGP маршруты клиентского устройства назад к каждому требуемому префиксу должны соответствовать проекту и его политике импорта. Отсутствующее объявление выглядит точно как сломанный туннель.

VPN-соединение и транзитный шлюз теперь общая инфраструктура.

Планируйте резервирование туннелей, ёмкость устройств, мониторинг и обслуживание вокруг всех зависимых VPC, а не рассматривайте каждый из них как независимо подключённый.

Переход с существующей схемы virtual private gateway заслуживает такого же явного плана. Постройте присоединения и политики, перенесите один контролируемый путь рабочей нагрузки и подтвердите разрешённые и запрещённые отношения, прежде чем выводить старый путь. Централизация помогает, когда даёт сетевой команде одно место для управления общей связностью, и вредит, когда скрывает, кто к кому может попасть, за одной большой таблицей.

Похожие статьи