GCP Cloud VPN：按顺序检查网关、隧道和防火墙

隧道显示已建立、每次探测却都超时，通常说明缺少 VPC 防火墙规则。请按网关、选择器、路由类型的顺序检查。

控制台里显示一条绿色的隧道，本地监控却仍连不上任何一个实例，重建隧道看起来是显而易见的修法。但事实很少如此。已建立的隧道只能证明两个网关完成了 IKE 交换。它完全不能说明数据包是否曾被允许进入你的 VPC。

在这枚绿色图标和一次响应之间隔着四个判断，它们会按可预测的顺序失败。从代价最低的开始。

三个对象，其中只有一个负责加密

VPN 网关持有对端加密所指向的外部地址。在控制台里你从不手工创建它：在连接表单中选择或预留一个地址，网关便随之出现。HA 网关在两个接口上占用两个地址，这在后面的配额检查中很关键。

隧道是网关与对端之间的配对。它携带共享密钥，以及它承诺保护的流量选择器。大多数静默故障正是从这些选择器开始的。本地选择器覆盖 10.0.0.0/24 的隧道，无论状态看起来多健康，都不会投递 10.0.1.0/24。

远端保有自己的清单，通常称为加密域，终结侧硬件会把它与你的清单比对。任何一侧都不会协商一个从未被告知的选择器。

路由类型决定什么能进入路由表

Cloud VPN 提供三种路由形态，它们并不能干净地混用。基于策略的路由保留静态选择器对，基于路由的路由需要你自己添加静态路由，动态路由则通过 BGP 借助 Cloud Router 通告前缀。请有意识地选定一种。

动态隧道旁边再放手工编写的静态路由，会得到一张在 BGP 会话一抖动就清空的路由表。

动态是唯一能在不重建隧道的前提下改变受保护前缀的形态，它同时把 Cloud Router 拉进你必须核验的对象集合。当对端是讲不了 BGP 的硬件防火墙时，静态选择器仍然可用。此时两端需要相同的地址范围，而且更具体的那条必须在两侧都胜出。只差一个子网的一对选择器会建立成功，然后只承载你一半的流量。

隐式拒绝就坐在隧道背后

入站流量按最低优先级与隐式拒绝比对，而那条规则并不关心数据包是不是加密到达的。直到某条防火墙规则点名本地地址范围和使用中的端口，数据包才会被解密、检查并丢弃。VPN 日志全程干净，因为隧道完全兑现了它的承诺。

当隧道正常而探测超时时，改读防火墙的拒绝日志，然后把规则限定到源地址范围和所需端口：

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

只有一个方向通，是防火墙的线索

出站的行为不同，因为隐式允许规则让实例可以发往任何地方。连不上 VM 的数据中心，往往处在另一方向上完全正常的出站路径之后。这种不对称把防火墙遗漏与路由故障区分开来，因为路由故障会同时断开两个方向。在再改一条规则之前，先测反向。

创建地址同样是一项配额操作。接近在用外部地址上限的项目会拒绝连接，报出的错误读起来却像权限失败。

选择器、配额，然后是四项检查

控制台创建的隧道有时会从 gcloud compute vpn-tunnels describe 返回空的远端流量选择器，而生成的路由却能正确承载流量。在断定隧道有问题之前，先把 API 记录的内容与你实际保护的地址范围做比对。通过 API 或 SDK 创建可以让选择器保持显式。

配额是另一个容易漏掉的点。请在维护窗口之前而不是之内申请增量，并在与网关相同的项目里核对地址数量。

由外向内推进：对端状态、两份选择器清单、每一侧的路由、针对源地址范围和端口的入站规则，最后抓包。趁隧道还新，把网关地址、两份选择器清单和路由类型写进变更单，因为下一个添加子网的工程师会三样都需要。

相关文章