Cloud VPN 状态：先读资源状态，再看 IKE 日志

一条 Cloud VPN 隧道同时运行着两套生命周期，而它们并不同步。资源必须先完成分配与配置，之后才谈得上协商，此后协议还有自己的一串 IKE 报文。状态字段可能报告了前者，却对后者毫无有用的说明。把两者当成一件事来读，正是密钥不匹配被误当成配置延迟的原因。

先确定一个隧道对象和一个时间窗口。

两套生命周期，一个隧道对象

资源的生命周期是云厂商在准备隧道：地址、配置、容量。协议的生命周期则在双方都具备足够配置、可以交换 IKE_SA_INIT、随后 IKE_AUTH、随后子级安全关联那一刻才开始。仍停留在第一阶段的隧道并没有认证失败，因为认证根本还没被尝试过。

正是这个区别构成了全部问题。其余的一切，都是如何在不混淆无关报文的前提下观察它。

读对象，别读控制台摘要

只向 API 要那两个关键字段，别的都不要，这样返回结果小到凌晨三点也读得完：gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)"。status 字段给出生命周期阶段，detailedStatus 则带着与之对应的可读原因。完整配置转储回答的是另外一些问题，而且更难贴进工单。这类只读调用不会改动隧道，在故障仍在进行时这一点很关键。

把调用时间戳记在取值旁边，因为两个字段都会变。

ALLOCATING_RESOURCES 不是密钥不匹配

当隧道报告 ALLOCATING_RESOURCES 时，云厂商仍在拼装这个对象。在这个阶段，预共享密钥不匹配根本观察不到，对端端口被挡同样无法证明。你能查的是详细消息、项目与服务看起来是否正常，以及隧道配置是否完整到足以联系上对端。此时更换密钥，改的是一个从未被验证过的值。

等状态发生移动，再对配置下结论。

ESTABLISHED 才是接入检查的起点

隧道已建立，只说明 IKE 完成了，不代表流量能过。确认隧道承载的路由；如果涉及 Cloud Router，还要确认 BGP 会话与它学到的前缀。然后再测一次被允许的应用层交换，因为一条防火墙规则或一条缺失的路由，都能让本来完全健康的隧道过不了流量。上述每一项都是独立观察，各有各的修法。

状态告诉你下一个该问什么问题，它从来不会替你回答接入问题。

对齐一个对象和一个时间窗口

日志里那条旧的认证失败属于更早的一次尝试，除非它的时间戳落在你正在排查的窗口内。按你记录状态的那几分钟去取该隧道资源的日志，并把标识符放在一起对照。更晚的 IKE 事件可以在你盯着的那条控制台消息已经过期时，说明协商其实已经开始。

如果在你采集到任何东西之前隧道就恢复了，就照实说。写明原因未定，比用无关日志行拼出一个笃定的故事要好。

下一步永远是同一个形状：一个对象、一个窗口、一个阶段。再宽的东西都只是摘要，不是诊断。