如何让 AWS 主动发起 Site-to-Site VPN 隧道

启动动作与 DPD 超时动作回答的是不同的问题。先设好让 AWS 主动发起的那一项，再检查对端地址和应用的路由。

默认情况下，AWS Site-to-Site VPN 会等待 customer gateway 发起协商。这个默认值只是一项设置，并非定律，设置名叫 Startup action。动手之前，先把两个经常被混为一谈的问题分开：谁负责建立隧道，以及你关心的报文在隧道里到底有没有路由。只有前一个问题属于隧道选项。

把启动动作与 DPD 超时动作分开

每条隧道有两个选项，分别管理两类不同的事件，设置其中一个并不说明另一个。

EventOptionUseful values
A new or modified VPN connection needs a tunnelStartup actionadd waits for the peer; start asks AWS to initiate
Dead peer detection times outDPD timeout actionclear ends the session, restart reinitiates, none does nothing

如果该由 AWS 拉起新建或变更的隧道，请选择 start。如果 DPD 超时之后也需要由 AWS 重新发起协商，请针对该事件单独配置 restart 。两者都不是应用层的重试策略，也都不是密钥更新间隔：DPD 检查对端是否存活，而密钥更新是在活跃隧道上替换 security associations。

隧道仍报告 up 时应用却超时，属于数据路径问题。缩短 DPD 计时器解决不了它，还可能带来日后需要解释的抖动。

确认 AWS 有地方可发送协商

AWS 侧主动发起只支持 IKEv2，而且 AWS 需要 customer gateway 的公网地址才能知道把提议发往哪里。最容易踩的坑是创建了带证书认证却没有地址的 customer gateway 资源：AWS 文档给出的做法是新建一个带地址的 customer gateway 资源，再把 VPN 连接改为指向它。

证书只能证明对端是谁，并不能告诉 AWS 对端在哪里，这是两项不同的要求。所以补救办法是新建 customer gateway 资源，而不是换新证书。只换证书，AWS 仍然缺少同一个目的地。

如果 customer gateway 位于 NAT 之后，AWS 还需要配置 responder identity， IDr，让对端身份与设备预期一致。在责怪刚改过的选项之前，先确认这个取值，以及放行 IKE 流量的防火墙路径。选择 start 并不能让不可达或身份识别错误的对端接受提议。

把变更应用到一条隧道，并预期出现中断

一个 VPN 连接有两条隧道，选项彼此独立，所以要通过外部地址确认你正在编辑哪一条。AWS 一次只允许修改一条隧道，所选隧道上的连通性可能中断数分钟。

  1. 选中该 Site-to-Site VPN 连接，打开 Modify VPN tunnel options。
  2. 按外部 IP 地址选择隧道，并确认其 IKE 版本与 customer gateway 资源。
  3. 设置你真正需要的启动动作与 DPD 动作，然后在你可控的时间窗口内保存。
  4. 确认修改后的隧道建立成功，并在下一次变更前检查另一条隧道和路由。

维护前有一点行为值得注意。启用 AWS 发起后没有超时：AWS 会一直尝试直到隧道建立，并在 customer gateway 发送 delete-SA 消息时重新发起。若你故意让对端下线，AWS 会持续敲门，对端日志里能看到。

要验证应用路径，而不只是隧道状态

隧道报告 up 并不等于请求可用。挂在 VPC 上的 Lambda 函数仍然需要通往客户网段前缀的 subnet 路由、允许流量的 security group 与 network ACL 规则、返回正确地址的名称解析，以及 客户侧的返回路径。

用应用上下文中的真实请求测一次，失败就读 flow logs。当 AWS 发起关闭且空闲隧道需要报文维持时，keepalive 流量是正当选项，但它应当是一个你能叫出名字的监控决策，而不是硬挂在函数上的莫名 ping 循环。

先确定由谁建立隧道，再在各自的层次上诊断剩下的故障。 AWS 关于主动发起的文档 对地址、身份和重试要求的说明，比控制台提示更详细。

相关文章