Оголошення 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.

Зберігайте стан до і після кожного запиту до таблиці маршрутів у журналі змін. Якщо зміна погіршує ситуацію, відновіть попередні маршрути й підтвердьте тим самим запитом, бо відкат, який ви не можете перевірити, — це лише здогад.