Anypoint VPN или NAT в Transit Gateway: где выполняется трансляция
Anypoint VPN сам не транслирует адреса. Выберите между PAT на межсетевом экране, картой префиксов AWS или другим подключением, прежде чем обещать NAT.
Требование к NAT не является требованием, пока оно не называет адреса, которые меняются, и компонент, которому разрешено их менять. В подключении MuleSoft это решение имеет три входа: нужен ли бэкенду трансляция портов «многие к одному» или псевдоним префикса «один к одному», может ли то подключение AWS, которым вы действительно владеете, выполнить это сопоставление и остаётся ли весь путь внутри комбинации, поддерживаемой поставщиком. Ошибётесь — построите работающую лабораторию, которая не проходит проверку.
Единственная неизменная точка: сам Anypoint VPN не является устройством трансляции. Документация CloudHub 2.0 указывает NAT там как неподдерживаемый, поэтому любой проект, предполагающий, что туннель скроет адреса ваших воркеров, уже сломан.
Определите, что должна делать трансляция
Если множество рабочих процессов приложения должны выглядеть для бэкенда как один адрес, требование — общая трансляция источника, обычно SNAT или PAT с сохранением состояния на межсетевом экране, которым вы управляете. Этот элемент должен стоять на одобренном пути, сохранять состояние в течение всей жизни потока и видеть обратный трафик для каждого переписанного соединения. Потеря состояния в середине сеанса не ухудшает соединение; она его завершает. Пара межсетевых экранов, отказывающаяся разделять состояние трансляции, сбросит каждый сеанс, который после переключения окажется на резервном узле. Рассчитывайте этот элемент на одновременные потоки, а не на пропускную способность.
Если же две сети пересекаются и каждому узлу нужен отдельный псевдоним, требование — план адресов «один к одному» с однозначно сопоставленными префиксами, согласованными маршрутами и разрешением имён, совпадающим с сопоставлением. Скрыть каждого воркера за одним адресом — не более дешёвая версия этого, а замена одного другим на защите проекта — это то, как проекты теряют квартал.
Запишите решение конкретными терминами до выбора продукта: исходный источник, исходное назначение, транслированное значение, направление инициации, владелец транслятора и ожидаемый обратный маршрут. Добавьте, какую идентичность сохранят журналы бэкенда, потому что проект, скрывающий все источники, уничтожает и аудит по клиентам.
Проверьте, может ли AWS выполнить сопоставление за вас
AWS теперь документирует управляемый NAT «один к одному» на подключениях Transit Gateway и Cloud WAN, объявленный в конце октября 2026 года, так что старое общее утверждение, будто транзитный шлюз никогда не может транслировать, устарело. Документация Transit Gateway NAT описывает сопоставление префиксов IPv4 без состояния: исходные и транслированные префиксы сохраняют одинаковую длину, а биты узла и транспортные порты переживают трансляцию. Читайте направления входа и выхода как отдельные проектные решения, потому что они настраиваются отдельно и одно может быть готово, пока другое нет. Ничто в этом описании не подразумевает состояние на поток, поэтому не ждите, что сопоставление будет отслеживать соединения за вас.
Это значит, что 10.80.0.0/16, сопоставленный с 172.28.0.0/16, превращает 10.80.10.23 в 172.28.10.23. Он не сжимает /16 в один адрес и не заменяет требование PAT. Он также охватывает отдельные типы подключений, включая VPC и Site-to-Site VPN, но не подключения Client VPN, а конфигурация находится у владельца транзитного шлюза, а не на стороне Anypoint.
Относитесь к функции как к ещё одной возможной точке контроля, а не как к доказательству, что ваше развёртывание может её использовать. CloudHub 2.0 документирует подключения частного пространства к транзитному шлюзу в собственном аккаунте AWS клиента, с региональными условиями и условиями прав, поэтому подтвердите реальный тип подключения, его владельца и позицию поставщика по поддержке, прежде чем проектировать вокруг нового варианта.
Держите путь внутри поддерживаемой границы
Для транслятора на межсетевом экране используйте поддерживаемую модель VPN, трансляции и маршрутизации этого продукта вместо того, чтобы вставлять общее правило NAT в работающий туннель. Ответ бэкенда должен вернуться через тот же элемент трансляции, а здоровый исходящий туннель ничего не говорит об этом обратном пути.
Для маршрута через транзитный шлюз проведите инвентаризацию подключения частного пространства, соответствующих таблиц маршрутов, локального подключения и частей, которые клиент действительно может настроить. Это другая архитектура связности, а не галочка NAT, прикрученная к существующему подключению Anypoint VPN, и граница поддержки смещается вместе с ней.
Сравните три варианта в одной таблице
Большинству команд достаточно ответить на два вопроса: «многие к одному» или «один к одному» и кому принадлежит подключение. Таблица ниже превращает эти ответы в начальный вариант.
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
Читайте третий столбец как вопрос проверки, а не как запоздалую мысль. Карта префиксов, разрешённая на бумаге, но настроенная на подключении, которым вы не владеете, остаётся заблокированным проектом, а правило PAT, пропускающее трафик, но ломающее журналирование по клиентам, не проходит последующий аудит.
Проверьте сопоставление, прежде чем обещать его
Пропустите одну свежую операцию приложения через путь и подтвердите ответ, а не только запрос. Спросите владельца бэкенда, какой адрес источника записали их журналы, проверьте, что обработка семейства адресов соответствует плану в обоих направлениях, и убедитесь, что путь, который должен быть отклонён, по-прежнему отклоняется. Старое соединение ничего не доказывает о сопоставлении, которое вы только что изменили.
Держите аутентификацию бэкенда независимой от того, какой транслированный адрес удовлетворяет его списку разрешений, потому что сопоставление — это сетевая инженерия, а не решение о контроле доступа. В тот момент, когда сброс пароля зависит от префикса NAT, любое будущее изменение диапазона становится сбоем.
Перед утверждением запишите три ответа: тип трансляции, владельца транслятора и поддерживаемое подключение или путь продукта, который её несёт. Если что-то из этого всё ещё догадка, проект не готов к окну изменений.