Объявления BGP от VGW и таблица маршрутов VPC: что меняет что

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

Назовите присоединение, прежде чем читать любую таблицу

VPN «сайт-сайт» завершается либо на виртуальном частном шлюзе, либо на транзитном шлюзе, и идентификаторы ресурсов определяют, какая модель маршрутизации применяется. Прочитайте их первыми: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Ответ скажет, какую таблицу проверять следующей — таблицу маршрутов VPC или таблицу маршрутов транзитного шлюза.

Если VPN присоединён к транзитному шлюзу, перестаньте рассматривать таблицу маршрутов VPC как плоскость управления. Там таблица VPC указывает на присоединение шлюза, а ассоциация и распространение происходят в таблице маршрутов транзитного шлюза. Смешение двух представлений даёт уверенные выводы о неправильном объекте.

Направление от AWS к офису — это объявление

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

У простого правила есть исключения, поэтому держите его в своих рамках. Конфигурация VPN CloudHub может повторно объявлять префиксы площадок между шлюзами клиентов, а транзитный шлюз следует собственным правилам распространения. Утверждение, что VGW объявляет только свой VPC, — полезное значение по умолчанию, а не закон, покрывающий каждую топологию, которую вы встретите.

Направление от офиса к AWS — это распространение плюс выбор

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

Читайте происхождение, а не предполагайте его: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Запись с происхождением EnableVgwRoutePropagation пришла из BGP; запись с происхождением CreateRoute ввёл человек, и она будет побеждать, пока кто-нибудь её не удалит.

Runbook, который держит два направления раздельно

Запишите четыре факта на стороне AWS, прежде чем что-либо менять: тип присоединения, связанные блоки CIDR VPC, происхождение маршрута подсети для рассматриваемого префикса, а также состояние туннеля и BGP. Тот же вызов describe возвращает VgwTelemetry с числом принятых маршрутов на туннель, что говорит, принял ли AWS хоть какие-то маршруты. Затем сравните это с тем, что устройство клиента действительно установило. Префикс, присутствующий в BGP, но отсутствующий в таблице пересылки, — это проблема локального импорта или лучшего пути, а не проблема таблицы маршрутов AWS.

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

Что не менять, пока вы там

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

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

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