AWS Site-to-Site VPN до NAT Gateway: VGW чи Transit Gateway

Усі першого разу малюють ту саму схему: VPN у VPC, NAT gateway назовні в інтернет, готово. Але AWS не підтримує цей шлях, коли VPN завершується на virtual private gateway, і збій настільки тихий, що команди перебудовують його більше ніж раз. Робоча схема потребує transit gateway, а це змінює шлюз і таблиці маршрутів з обох боків. Порівняйте дві форми, перш ніж щось малювати.

Топологія, яка здається очевидною і не підтримується

Документація з NAT gateway від AWS проводить межу, яка дивує кожного, хто будував схеми лише з одним VPC: трафік із підключення Site-to-Site VPN не можна спрямувати до NAT gateway через virtual private gateway. Тип шлюзу, на якому завершується VPN, визначає, чи існує взагалі шлях трансляції. Помилка виживає тому, що тунель має стан UP, а інстанс EC2 у тій самій підмережі без проблем досягає інтернету. Жодне з цих двох спостережень не перевіряє зламаний напрямок.

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

Virtual private gateway проти transit gateway

Virtual private gateway належить одному VPC. Він завершує VPN, встановлює маршрути в таблиці цього VPC і на цьому зупиняється. У нього немає моделі attachment, тому він не може передати трафік іншому VPC або спільному вихідному сегменту. Уся межа — це обсяг одного VPC, і жоден маршрут, доданий усередині VPC, цього не змінює.

Transit gateway — регіональний центр, у якому VPN, кожен spoke VPC і VPC спільних сервісів постають як attachment. Він має власні таблиці маршрутів, які вибирають, який attachment отримає заданий префікс.

Саме цей центр уможливлює централізований вихід: VPN приземляється як один attachment, вихідний VPC — як інший, а таблиця маршрутів transit gateway надсилає префікси в бік інтернету з першого до другого. З virtual private gateway другого attachment немає, тому схему не можна доопрацювати заднім числом.

Підтримуваний шлях виходу, хоп за хопом

Еталонна схема має п'ять хопів, і кожна стрілка — це рішення про маршрутизацію, яке треба налаштувати. Трафік виходить з локальної мережі в attachment Site-to-Site VPN, таблиця transit gateway передає його в attachment вихідного VPC, де таблиця підмережі надсилає його до публічного NAT gateway. NAT gateway транслює джерело, а internet gateway виносить пакет назовні.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Дві деталі вирішують, чи працюють останні хопи. NAT gateway має бути публічним, з elastic IP і маршрутом до internet gateway, бо приватний NAT gateway транслює між мережами й ніколи не стає виходом в інтернет.

Плануйте один NAT gateway на кожну зону Availability, яку збираєтеся обслуговувати, і нехай кожна таблиця підмережі вказує на локальну. Тримайте таблицю transit gateway і таблиці VPC у нотатках як окремі об'єкти, бо одна вибирає attachment, а інша — ресурс усередині VPC. Маршрут за замовчуванням лише в одній із них залишає половину шляху невизначеною і породжує часткові збої, які найважче віднести до причини.

Саме на зворотному шляху ці схеми й ламаються

NAT gateway зберігає стан для вже бачених потоків, тож відповіді на вихідне з'єднання повертаються без нового вхідного правила. Ця властивість не публікує локальний сервіс в інтернеті, і ставлення до неї так, ніби публікує, коштує команді дня налагодження з'єднання, яке ніколи б не встановилося. Для трафіку, який починає клієнт, мають узгодитися чотири маршрути: локальна політика, таблиця transit gateway, таблиця вихідної підмережі й таблиця підмережі NAT. Пропустіть останню — і запит залишає будівлю, поки відповідь помирає всередині AWS.

Перевірте реальним клієнтом за VPN і подивіться, яку публічну адресу джерела він показує. Якщо це elastic IP NAT gateway, трансляція відбувається; якщо щось інше, ви міряєте інший вихід.

Асиметричну версію цього збою варто розпізнавати рано. Коли таблиця підмережі NAT однієї зони Availability має зворотний маршрут до префікса клієнта, а інша ні, нові з'єднання вдаються або не вдаються залежно від зони, у яку потрапляє потік, і закономірність хибно читають як нестабільний інтернет. Порівнюйте таблиці підмереж для кожної зони, яку обслуговуєте, замість того щоб лагодити ту, де відкрили тікет, бо відсутній маршрут — це вся несправність, і на іншому боці нічого змінювати не треба.

Коли явний proxy — краща схема

HTTP proxy на інстансі у вихідному VPC — законна альтернатива й часто дешевша. Клієнти налаштовуються на його використання, proxy відкриває власне з'єднання назовні, і зворотний шлях стає його проблемою, а не головоломкою симетричної маршрутизації. Для невеликої кількості застосунків це знімає більшу частину роботи з transit gateway. Він також дає журналювання за користувачами, якого NAT gateway не може забезпечити.

Однак він не прозорий. Усе, що ігнорує налаштування proxy, і кожен протокол, який не є HTTP, цим шляхом не підуть.

Вибір залежить від того, на чому насправді говорять ваші застосунки і скільки ідентичності потрібно в журналах. Там, де вони говорять HTTP, proxy виправдовує своє місце; там, де потрібен загальний вихід для довільних протоколів, схема з transit gateway — та, яку підтримує AWS. Вирішити це заздалегідь дешевше, ніж виявити після побудови таблиць маршрутів.