EC2 上的 strongSwan：让 VPC 为工作负载路由

隧道已建立，网关实例能 ping 通远端网络，而旁边那台应用实例却哪里都到不了。没有东西坏掉。成功的测试源起于 VPN 主机，它从未追问该主机能否用同一条 IPsec 关系承载另一个源地址。本手册分四步补上这个缺口，顺序让每一种失败都看得见。

先写下四个地址

下面每一步都要用到它们，所以在动路由表之前先按自己的账号填好。

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

示例假定已有获批且可用的策略型 IPsec 连接，以及保留源地址的流量。这不是借用单一分配地址的 NAT 远程访问客户端，而这个差别决定了选择器是否需要改动。

第 1 步：给工作负载子网一条路由

真正关联到工作负载子网的那张路由表，需要一条指向网关网络接口的远端前缀路径。在实例内部装的来宾路由不是那张 AWS 路由表里的条目，再多的 strongSwan 配置也不会变出一条。

AWS 的设备路由指南说明了网络接口类型的目标，以及转发实例的源/目标检查要求。把这项检查改动限定在网关角色上，普通应用实例不要动。

不要为了给一个获批网络腾位置而替换 VPC 的本地路由或每一条现有条目。要查的是实际关联且生效的内容，而不是控制台为一张没人使用的路由表显示的内容。两张看起来一样的表可能有不同关联。真正重要的是工作负载子网所关联的那张。

第 2 步：在来宾上开启转发

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

内核必须转发，主机防火墙必须放行。不要一律接受，而是为工作负载和远端前缀加入预期的转发规则，并确认网关子网为自己流量保有一条可用的传输路由。

这一步通常卡在安全组上。中间设备不会继承实例直连通信的安全组引用行为，所以从托管 Client VPN 示例抄来的规则可能永远匹配不上。要在真实路径上双向检查安全组和子网 ACL。

第 3 步：把选择器放宽到真实源

在 AWS 一侧只覆盖 10.60.1.10/32 的策略，解释了从网关发起的成功，却没有覆盖 10.60.2.20。通往远端目的地的路由不会扩大流量选择器，这就是同一个意外的后半段。

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

如果商定的设计保护整个 VPC，双方就必须接受 10.60.0.0/16 和 10.90.0.0/24。如果只保护一个工作负载，就刻意使用那个更窄的前缀。无论哪种，都要查看已安装的 CHILD-SA 策略，因为你改过的配置和把范围收得更窄的对端并不是同一个约定。

远端站点也必须把保留的 VPC 源地址的回应经预期 IPsec 网关回程路由。在其他源 NAT 规则存在的地方，保留受支持的保护流量 NAT 豁免；把未获批的工作负载译成允许的主机地址是另一种身份契约，不是通往你想要的访问的捷径。

第 4 步：验证，必要时回滚

从工作负载自身、用一次新的获批应用操作来测，再用一个应当被排除的目的地重复。记录远端服务看到的源地址以及它使用的回程路径。网关 ping 或绿色 IKE 状态都不是这个测试。

如果网关正常而工作负载仍然失败，就按顺序往回走：选择器，然后是转发与安全组，然后是关联的路由表。每一种症状都不同，靠猜会跳过真正出错的那一处。

回滚把同样的顺序倒过来。最后再移除工作负载子网的路由，在恢复先前选择器之后移除，这样就不会留下一个指向已不再保护其源的网关的子网。这些契约成立时，自托管能服务的范围超过网关主机；而 AWS 托管的 Site-to-Site VPN 是另一种运行模型，strongSwan 可能改放在客户网关一端。