Добавление локальной подсети в AWS VPN: VGW или Transit Gateway

Существующий Site-to-Site VPN передает 10.60.0.0/16, за тем же локальным шлюзом появляется новая сервисная сеть как 10.70.0.0/16, и кто-то спрашивает, нужен ли прокси. Обычно нет: маршрутизируемый путь может передавать префикс, но только если совпадут три вещи, и какие именно три зависит от архитектуры AWS, которую вы уже используете. Виртуальный частный шлюз имеет одну границу таблицы маршрутов; transit gateway добавляет вторую. Правильное объявление при неверной таблице дает сеанс, который выглядит здоровым и ничего не доставляет.

Объявите префикс, который шлюз действительно может доставить

Локальному шлюзу нужен путь к новой сети, прежде чем любое объявление обретет смысл. Объявление 10.70.0.0/16 через BGP сообщает AWS, куда отправлять пакеты этого диапазона; оно не создает локальный путь пересылки, который делает диапазон доступным на другом конце. Убедитесь, что у шлюза есть маршрут для префикса, указывающий на устройство, которое его содержит, и что устройство настроено отвечать за эти адреса. Политика экспорта и принимаемые ограничения префиксов — следующее ограничение, потому что префикс, который сеанс отфильтровывает, до AWS вообще не доходит.

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

Путь первый: граница виртуального частного шлюза

С виртуальным частным шлюзом документация AWS VPN по маршрутизации описывает два режима распространения — статические маршруты и объявления BGP, — и оба зависят от таблицы маршрутов подсети, которую приложение действительно использует. Распространение удобно, когда вы контролируете весь диапазон, а явный маршрут легче обосновать, когда нужно, чтобы пункт назначения был указан рядом с целью. В любом случае проверка одна: есть ли в таблице конкретной подсети приложения рабочий путь к цели VPN для нового префикса и побеждает ли он что-то более конкретное?

Здоровый сеанс BGP доказывает, что канал существует. Он ничего не говорит о том, приняла ли данная таблица подсети этот маршрут.

Путь второй: transit gateway добавляет таблицу

Transit gateway делит этот один вопрос на два. Подсеть VPC должна отправить пункт назначения на присоединение transit gateway, а затем таблица маршрутов transit gateway должна выбрать присоединение VPN для того же префикса. Выбор ассоциации и распространения определяет, какие подключенные сети получат маршрут, поэтому префикс может быть правильно объявлен VPN и все же никогда не достичь VPC, таблица которой никогда не была связана с нужной таблицей маршрутов.

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

Распространение маршрутов тоже не дает префикс каждому присоединению. Оно распределяет его по таблицам, настроенным на его прием.

Обратный путь — самостоятельное политическое решение

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

Перекрытие адресов — другая ловушка. Непересекающиеся, явно принадлежащие вам диапазоны сохраняют простоту; перекрывающиеся диапазоны означают трансляцию или перепроектирование, и ни то, ни другое не является взаимозаменяемым вариантом того же рецепта.

Проверьте с источником в новой сети и назначением в подсети приложения, затем повторите в обратном направлении. Односторонний тест доказывает только одно направление.

Когда прокси действительно лучшая граница

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

Решайте в таком порядке: локальная пересылка, объявление, граница таблицы, политика обратного пути. Исправьте первое, что не сработает, и только затем спросите, является ли маршрутизируемый путь вообще правильным ответом.