Почему GRE и ESP не проходят через шлюз NAT в AWS

Туннель не работает, группа безопасности уже разрешает весь трафик, и делается вывод, что AWS блокирует VPN. Она ничего не блокирует. Управляемый шлюз NAT пересылает документированный набор внешних протоколов, и собственные GRE или ESP в него не входят, поэтому никакое добавленное правило не заставит шлюз их передавать. Правило разрешения и способность транспорта — две разные вещи, и изменить можно только одну из них.

Набор правил — не набор протоколов

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

Спецификация протоколов шлюза NAT от AWS перечисляет TCP, UDP и ICMP для управляемой службы. Это весь поддерживаемый набор. Правило разрешения для другого протокола IP не может его расширить, потому что правило оценивается задолго до того, как достигается путь пересылки шлюза.

Это различие важно, потому что оба сбоя выглядят со стороны клиента одинаково и имеют совершенно разные исправления.

PPTP показывает, почему проверка порта лжёт

PPTP — самый яркий старый пример проверки порта, которая ничего не доказывает. Он открывает управляющее соединение TCP на порту 1723, а затем передаёт данные туннеля по GRE, то есть по протоколу IP 47. Протокол 47 — не порт TCP 47, и эти два числа не имеют друг к другу никакого отношения, кроме общих цифр.

Оператор, который проверяет связность с 1723 и видит завершённое рукопожатие, заключает, что путь работает. Затем канал данных не пропускает ни одного пакета, потому что шлюзу нечего предложить в качестве поддержки GRE. Это трактовка требований старого протокола, а не совет разворачивать PPTP, устаревший много лет назад.

Те же рассуждения применимы к любому протоколу, управляющий канал которого — TCP или UDP, а путь данных — нет.

IPsec выживает только как UDP

IPsec — это случай, когда ответ условный, а не категорическое нет. AWS документирует NAT traversal как поддерживаемую схему для IPsec через шлюз NAT. При согласованном NAT-T ESP инкапсулируется в UDP, и шлюз видит обычный UDP вместо протокола 50.

Разрешение UDP 4500 не заставляет конечные точки использовать NAT traversal. Оно лишь разрешает пакеты, если они уже имеют такую форму. Подтвердите по собственному выводу согласования клиента, какая инкапсуляция выбрана, и подтвердите на принимающей стороне, что партнёр её принял. Две конечные точки, настроенные на собственный ESP, продолжат отправлять собственный ESP, что бы ни говорил набор правил.

VPN на основе TCP или UDP укладывается в документированный набор транспортов и всё равно может отказать из-за маршрутизации, фильтрации или аутентификации. Соответствие набору необходимо, но недостаточно.

Проверьте путь, прежде чем расширять политику

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

Затем зафиксируйте испробованную конечную точку, семейство адресов, внешний протокол и порт, если у протокола он есть. Используйте диагностику клиента и наблюдения за потоком владельца сети вместо успешного запроса браузера, который доказывает лишь то, что TCP и UDP работают. После этого проверьте группу безопасности, ACL подсети, брандмауэр гостя и политику службы для обоих направлений потока.

Не открывайте весь трафик, чтобы компенсировать транспорт, который служба не может передать. Изменение правила это не исправит, и оно переживёт инцидент.

Когда транспорт не подходит

Если внешний протокол вне поддерживаемого набора, исправление архитектурное: выберите транспорт, который путь может передать, или перенесите выход на то, что передаёт нужный вам. OpenVPN по UDP, WireGuard по UDP и туннели на основе TLS все укладываются в документированный набор. Экземпляр NAT под управлением клиента — вариант, когда конкретный протокол должен пройти и эксплуатационные затраты на его поддержку приемлемы.

Хостинг входящего VPN-сервера — отдельная проблема с отдельным ответом. Шлюз NAT обеспечивает исходящую трансляцию и не даёт общего перенаправления входящих портов, поэтому серверу за ним нужен свой одобренный публичный вход, спроектированный на собственных условиях.

Порядок работы: назовите внешний протокол, подтвердите следующий переход, сравните его с документированным набором, затем измените архитектуру или транспорт. Другой номер порта не превратит GRE в TCP, и ещё одно разрешающее правило не превратит завершённый обмен управления в работающий канал данных.