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. Решить это заранее дешевле, чем обнаружить после постройки таблиц маршрутов.