从 strongSwan 到 AWS Site-to-Site：Child SA 为何什么都没选中

IKE 隧道可能已经建立，但子关联却把您的子网排除在外。先比较 AWS 的本地与远程 CIDR 和 leftsubnet、rightsubnet。

控制台显示 up，strongSwan 报告 IKE 关联已建立，可数据包仍然到不了。接下来要比较的不是预共享密钥，而是双方各自认为隧道所保护的那对前缀。请按顺序完成下面的检查，因为前两项决定了隧道究竟能不能承载您的流量。

把 AWS 的命名换成 strongSwan 的说法

AWS 从客户侧描述连接：客户网关地址和本地 CIDR 属于您，远程 CIDR 属于 VPC。strongSwan 把两端称为 left 和 right，您的前缀放在 leftsubnet，VPC 的前缀放在 rightsubnet。只要把其中一对反过来，就会得到一个协商并选中错误流量的隧道。

下载 AWS 为该连接生成的配置，并把它当作这条连接的参考，包括隧道地址和前缀。创建时若把两个 CIDR 字段都留空，服务会在每一侧使用默认的 0.0.0.0/0。这样，配置了窄前缀的路由器就永远对不上，所以要么填好字段，要么有意识地放宽选择器。

这里的错配看起来像路由故障，其实不是。

固定 AWS 真正看到的地址

NAT 后面的路由器可能从对端从未获知的接口发出 IKE。AWS 中记录的网关地址必须是 AWS 在链路上实际观察到的地址，路由器也必须固定到同一个本地地址，而不是跟随默认路由。

conn %default
    local_addrs = 203.0.113.10

在 strongSwan 中，local_addrs 决定 IKE 的源地址，较早的 OpenSwan 配置把同一想法写作 left。把它指向持有公网地址的接口，然后在 NAT 设备本身上确认 UDP 500 和 4500 能到达该主机，因为上一台路由器遗留的规则会悄悄把它们丢掉。选择器对正确但源地址错误依然会失败，而日志会把责任推给提案。正是这种误导，让源地址值得单独检查。

转发规则要去确认，而不是假定，因为对上一台路由器正确的规则常常会留下来。

把阶段 1 和阶段 2 分开处理

AWS 把 IKE 和 ESP 选项列为两份独立的清单。双方都接受的 IKE 套件并不能说明 ESP 提案，因为两份清单彼此独立。从生成的配置里把两者都读出来，再逐项比较。

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

语法不会在实现之间通用。在 OpenSwan 中可用的组合，例如 phase2alg=aes_gcm 配 ike=aes256-sha1;modp1024，需要转换成 strongSwan 的 esp= 和 ike= 形式，而算法名称也不相同。GCM 在加密的同时完成认证，因此不需要单独的完整性变换，这一点与搭配 SHA 的 CBC 套件不同。把阶段 2 的一行从一种守护进程原样贴到另一种，得到的拒绝读起来像是选择器不匹配。

检查子关联，而不是隧道指示灯

如果连接已加载却没有子关联建立，那就是提案或选择器被拒绝了。如果子关联建立了，但它的选择器把您的前缀排除在外，数据包在到达隧道之前就被过滤掉了。控制台的指示灯只覆盖 IKE 层，所以它无法告诉您是两者中的哪一种。

ipsec statusall

找到子安全关联，读取它旁边打印的流量选择器，再与生成配置中的前缀对照。

从本地前缀内的主机向 VPC 前缀内的主机测试，并检查回程路径以及 AWS 侧的任何安全组或网络 ACL。选择器正确，并不能阻止数据包在之后被丢弃。

当选择器一致之后仍然失败

先确认两侧的路由都指向隧道，再确认 NAT 设备没有以策略未预料的方式改写流量。基于策略的隧道匹配的是数据包地址，因此在策略判定之后再做转换会改变结果。

在改动下一个提案之前，先在每一侧各记录一个入向和一个出向数据包。

在工单中记录选择器、阶段 1 和阶段 2 的提案以及源地址。这四个值无需致电就能解释大多数 site-to-site 故障。

相关文章