Какой исходный IP использует шлюз NAT в AWS по направлению к VPN?

Вы открываете консоль VPC, потому что партнёр спросил, какой диапазон источника придёт через VPN «сайт-сайт». Страница шлюзов NAT показывает публичный шлюз с привязанным Elastic IP, и соблазн — отправить этот адрес и двигаться дальше. Это правильный ответ для интернет-пути и неправильный для пути через VPN, а разница в том, на какой шлюз указывает таблица маршрутов. Пройдите маршрут, прежде чем писать список разрешённых адресов.

Начните со страницы шлюзов NAT, а не со списка разрешённых адресов

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

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

Проследите два преобразования

И публичные, и частные шлюзы NAT преобразуют частный источник IPv4 рабочей нагрузки в собственный частный адрес IPv4 шлюза NAT. Это первое преобразование происходит независимо от типа. Второе преобразование — то, о котором забывают: публичный шлюз NAT передаёт трафик интернет-шлюзу, который сопоставляет адрес с привязанным Elastic IP.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

На частном пути интернет-шлюза в цепочке нет. Когда трафик выходит через транзитный шлюз или виртуальный частный шлюз, руководство по шлюзам NAT документирует частный адрес шлюза NAT как источник, который получает удалённая сторона. Именно этот адрес партнёр должен разрешить, а не Elastic IP.

Путь через VPN обычно показывает частный адрес

Для рабочей нагрузки в 10.20.1.0/24, достигающей префикса партнёра, таблица маршрутов подсети рабочей нагрузки указывает на шлюз NAT, а таблица маршрутов подсети шлюза NAT — на путь частного шлюза. Оба перехода важны, и только второй определяет, что видит партнёр. Если у подсети NAT нет маршрута к пути через VPN, пакет никогда не придёт, и это другая неисправность, чем неверный адрес источника.

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

Когда второе преобразование меняет ответ

AWS также предлагает явное, соответствующее сопоставление NAT «один к одному» на вложении транзитного шлюза. Это сопоставление может ещё раз преобразовать источник, прежде чем удалённый сервис его увидит, и это не поведение по умолчанию, которое только маршрутизирует. Поскольку его нужно настраивать намеренно, относитесь к нему как к проектному исключению, а не как к чему-то, что вы получаете случайно. Если никто в вашей команде не помнит, что его включил, считайте, что его нет, пока вы не прочитаете вложение.

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

Частному шлюзу NAT нельзя дать интернет-сервис, направив его на интернет-шлюз; AWS документирует, что такой трафик отбрасывается. Выбирайте тип по полному пути, а не по слову VPN в требовании.

Напишите контракт, по которому ваш партнёр может действовать

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

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

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