Anypoint VPN 还是 Transit Gateway NAT：翻译发生在哪里
Anypoint VPN 本身并不转换地址。在承诺 NAT 之前，先决定是采用防火墙上的 PAT 设计、AWS 前缀映射，还是换一种连接方式。
NAT 需求只有在写明哪些地址会变、以及哪个组件有权改变它们之后，才算真正的需求。在 MuleSoft 的连接方案里，这个决定有三个输入：后端需要的是多对一的端口转换还是一对一的前缀别名；你实际拥有的 AWS 连接能否完成该映射；整条路径是否落在厂商支持的组合之内。这三点搞错，你搭出来的实验环境能跑通，却过不了评审。
唯一确定的一点是：Anypoint VPN 本身不是转换设备。CloudHub 2.0 文档把 NAT 列为不受支持，因此任何假设隧道会隐藏 worker 地址的方案，从一开始就是错的。
先确定转换要完成什么
如果大量应用 worker 必须以单一地址出现在后端面前，需求就是共享的源地址转换，通常是你控制的防火墙上的有状态 SNAT 或 PAT。这个组件必须位于获批路径上，在整个流生命周期内保持状态，并能看到它改写的每一条连接的回程流量。会话中途丢失状态不会让连接变差，而是直接中断。拒绝共享转换状态的防火墙双机，会在故障切换后丢弃所有落到备机的会话。这个组件要按并发流来选型，而不是按吞吐。
反过来，如果两个网段重叠、每台主机都需要不同别名，需求就是一对一地址规划：映射前缀必须无歧义，路由要匹配，名称解析要与映射一致。把所有 worker 藏在一个地址后面并不是它的廉价版本；在评审中把两者互相替换，正是项目白白损失一个季度的原因。
在选产品之前，先把决定写成具体条目：原始源、原始目的、转换后的值、发起方向、转换设备的所有者、预期回程路径。再加上后端日志会保留什么身份信息，因为隐藏所有源的方案同时也会毁掉按客户维度的审计。
确认 AWS 能否替你完成映射
AWS 现在已在 Transit Gateway 与 Cloud WAN 连接上提供托管的一对一 NAT，并于 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 规则硬贴进一条本来能用的隧道。后端的回包必须经过同一个转换组件，而出向隧道健康并不能说明这条回程路径。
走中转网关路线时，要清点私有空间连接、相关路由表、本地连接，以及客户真正能配置的部分。这是另一种连接架构，不是给现有 Anypoint VPN 连接加一个 NAT 勾选项，支持边界也会随之移动。
用一张表比较三种方案
多数团队只需要回答两个问题：多对一还是一对一，以及连接归谁所有。下表把这些答案转成起点方案。
| 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 前缀，之后每次网段变更都会变成一次故障。
在签字之前，写下三个答案：转换类型、转换器的所有者、承载它的受支持连接或产品路径。只要有一项还是猜测，这个设计就不适合进入变更窗口。