Cloud VPN 中无法调整的上限：IKE 生命周期与对端 NAT

给远端设备配置 24 小时的阶段 1 生命周期，即便 Google 一侧全部配置正确，Cloud VPN 隧道也会一直无法建立。对端提出的值响应方不会接受，因此协商要么直接失败，要么无限重启。Cloud VPN 将阶段 1 限制在 36,000 秒，也就是十小时，而这个上限不是你可以调高的设置。改动应该落在远端设备上。

对端提出，响应方决定

IKE 是两个提议集合之间的匹配过程。只有当两个集合在响应方接受的范围内出现交集时，隧道才会建立，因此超出范围的生命周期不会产生任何部分隧道。常见的错误是把对端的配置当成愿望清单，而不是当成提议。交集为空时，无论路由和选择器多么正确，隧道都建不起来。

在提交工单之前先读取隧道自身的状态，因为详细状态通常会指出失败的阶段：

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

把返回结果与你的网关类型和 IKE 版本所支持的集合进行对比，并顺便记录两个流量选择器。选择器不一致造成的隧道不通，症状与算法不一致相同；而不同于算法的是，这一项需要你来修。

36,000 秒就是上限

阶段 1 在 36,000 秒处停止。把设备设成 86,400 等于要求响应方永远不会同意的值，重试也不会改变它的决定。把远端提议调回范围内，同样的配置就能建立；这种不对称正是全部教训，因为你可以调低自己的值，却无法调高 Google 的值。

把选定的值写进设计笔记。否则下一位工程师会重做 24 小时的实验，然后撞上同一堵墙。

受支持的集合按网关类型和 IKE 版本公布在 Cloud VPN 概览中，所以请阅读与你拓扑对应的章节，而不是通用的 IKE 指南。

按固定节奏掉线的隧道

阶段 2 的行为不同：两端不一致时，密钥重协商会跟随较短的时间间隔。把不一致当成致命错误的对端则会直接断开隧道，于是同一个不一致看起来像两个互不相关的故障。要观察密钥重协商的节奏，而不只是第一次连接。按固定节拍反复起落的隧道，更常见的是生命周期不一致，而不是路由缺陷。

在改动任何东西之前，先把这些掉线时间戳与对端自己的日志对齐，因为选择器或路由的改动也能模拟出同样的节奏。如果节拍与阶段 2 定时器吻合，不必动提议就能找到原因。

套件由网关类型决定

加密与完整性套件不是像 strongSwan 那样可以逐隧道编辑的配置文件。它们由网关类型和 IKE 版本决定，去寻找一个并不存在的配置文件只会浪费一下午。

如果旧设备在受支持集合内什么都提供不了，只有两条诚实的路：更换设备，或者在你可控的软件网关上终止，再从那里路由进 VPC。其他任何做法都是临时变通，下一次评审就过不了。

每台设备一个外部地址

对端的外部地址必须与其内部地址一对一映射。 过载的 PAT 池无法工作，因为单个公网地址后面的多台主机让响应方无法区分它们。如果多台主机必须共用一个地址，隧道就必须终止在能够区分它们的地方。

这个外部地址也要保持稳定。把设备挪到另一个 NAT 后面，即使每条提议仍然匹配，关联也会断开。值得写下来哪些值属于 Google、哪些属于你：生命周期、套件和一对一 NAT 在对方一侧固定，而提议、选择器、路由和 BGP 优先级属于你。