AWS 的 NAT 网关向 VPN 方向使用哪个源 IP？

你打开 VPC 控制台，是因为合作伙伴问：通过站点到站点 VPN 过来的会是哪个源网段。NAT 网关页面显示一个绑定了弹性 IP 的公有网关，诱惑就是直接把这个地址发过去然后结束。对互联网路径来说这是正确答案，对 VPN 路径来说这是错误答案，差别在于路由表指向哪个网关。写下允许列表之前，先把路由走一遍。

从 NAT 网关页面开始，而不是从允许列表开始

NAT 网关页面告诉你子网、类型和弹性 IP，这三个字段足以起步。它没有告诉你的是流量之后走哪条路。那来自挂在 NAT 网关子网上的路由表。

先读类型，因为公有还是私有决定了后面链路里会不会出现互联网网关。再读子网，因为第二条路由就住在那里。

沿着两次转换走

公有和私有 NAT 网关都会把工作负载的私有 IPv4 源地址转换成 NAT 网关自己的私有 IPv4 地址。第一次转换与类型无关。第二次转换才是人们容易忘记的：公有 NAT 网关把流量交给互联网网关，由它把地址映射到绑定的弹性 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 网关的私有地址，也就是远端收到的源地址。合作伙伴应该放行的是这个地址，而不是弹性 IP。

VPN 路径通常显示私有地址

对于 10.20.1.0/24 中要到达合作伙伴前缀的工作负载，工作负载子网的路由表指向 NAT 网关，NAT 网关子网的路由表指向私有网关的路径。两跳都重要，而只有第二跳决定合作伙伴看到什么。如果 NAT 子网没有通往 VPN 路径的路由，报文永远不会到达，这与源地址写错是两回事。

在讨论地址之前，先核实第二条路由。缺少路由和源地址报错，在一个根本看不到流量的合作伙伴眼里完全一样。

当第二次转换改变答案时

AWS 还在中转网关连接上提供显式的一对一 NAT 映射。该映射可以在远端服务看到之前再次转换源地址，而这不是只做路由的默认行为。由于它必须刻意配置，请把它当作设计上的例外，而不是偶然继承的东西。如果团队里没人记得开过它，就先假定它不存在，直到你读过那条连接。

如果你的设计用了它，允许列表必须描述最终映射，而不是 NAT 网关的地址。同样的谨慎适用于可用性路径：当多个网关地址参与时，预期的源集合是并集，而不是一个代表性地址。写下每个地址属于哪次转换，因为没有来源的清单事后无法审计。

私有 NAT 网关无法通过指向互联网网关来获得互联网服务；AWS 记录这类流量会被丢弃。类型要从完整路径来选，而不是从需求里的 VPN 这个词来选。

写下合作伙伴可以据以行动的契约

可用的契约有四部分：流由哪个方向发起、合作伙伴会看到的转换后身份、该身份的回程路由，以及适用的保护范围。NAT 网关的流由被支持的源侧发起，所以它不是用来暴露私有工作负载的入站端口转发服务。早早把这一点说清楚，可以避免双方都以为对方在发起的评审。

转换换来地址重叠的缓解和可预测的源策略，代价是合作伙伴日志里失去单个工作负载的身份。如果审计需要按工作负载归因，就应在应用层保留这个身份，而不是试图从转换后的源地址里还原它。

然后任何变更之后都要重新核对两张路由表，因为新的连接或重新关联的子网会悄悄改写答案。