VPN 上的 Google API：要路由到 VIP，而不只是子网

通过 SSH 登录本地服务器并拉起隧道后，私有 VM 会响应；但第一次调用 Google API 却因为无路由而失败。VM 子网和 API 的 VIP 是不同的目的地，因此指向其中一个的路由不会选中另一个。私有 API 调用要成功，必须同时满足三个条件。API 名称必须解析到 VIP，VIP 前缀必须通过隧道通告出去，而 VPC 必须知道如何把回复送回去。ping 无法说明其中任何一点，能连通子网内机器的 SSH 会话也不行。

API 的 VIP 是独立的目的地

Google 为本地网络访问 API 发布了专用 VIP，这些正是你的 DNS 为 API 名称必须返回的地址。两者都是小前缀，都不属于 RFC 1918 地址空间:

看起来像公网的地址，并不意味着路由必须离开隧道 对于普通互联网而言。这些前缀的存在，是为了让本地客户端通过受支持的路径到达 Google 前端，而不是经由任意出口点。应把它们视为属于隧道的目标，而不是可供探测的主机。为互联网出口编写的防火墙规则通常会把它们丢掉，这也是调用在开始之前就失败的常见原因。

DNS 决定你到达哪个端点

把本地解析器指向 Google 为所选端点记录的条目，使应用所需的名称用该 VIP 应答。仅仅映射 googleapis.com 并不等于清单：软件包注册表、容器注册表和迁移连接器都有各自记录在案的名称。受限 VIP 也不承载所有服务，因此能解析的名称仍可能不受支持。在改动解析器之前，先写下应用实际访问的域名。

用猜测的 VPC VM 地址代替服务名称不是修复，它通常会把 DNS 的缺口掩盖起来，直到另一个客户端失败。

通告 VIP 前缀，保留其余部分

在基于 BGP 的连接中，Cloud Router 必须通告所选 VIP 前缀，本地路由器才能通过预期的会话学到该网段。只通告 VPC 子网不会加上该网段，本地路由器对这些地址仍会使用默认路径。路由表中的前缀是通告已跨越会话的唯一证据。

新增时要保留已有通告，因为路由器级和邻居级的选项覆盖范围不同，替换集合可能撤销已经可用的网络。然后在每个会话上查看实际生效的通告，而不是看整个路由器。缺失的前缀和被撤销的前缀从本地一侧看起来完全一样，因此只有会话视图才能区分遗漏与回归。

VPC 一侧需要自己的路由和返回路径

在 VPC 内部，通往 VIP 的路径必须使用默认互联网网关作为下一跳；尽管名称如此，这些流量仍留在 Google 的网络内。VPC 还需要一条经 VPN 回到本地源的路由，它与已通告的前缀是两个独立对象。当隧道和客户端不在同一区域时，要考虑文档中记录的区域路由要求。

返回路径要独立检查，因为请求方向可用可能掩盖回复方向已断。两个方向、两条路由，各自以不同的症状失败。

先测试请求，再读拒绝信息

这些 VIP 不会回应 ICMP echo，因此 ping 失败说明不了什么，ping 成功也说明不了多少。从真实客户端出发，检查名称的应答和选中的路由，然后向你在意的服务发出经授权的 HTTPS 请求。如果请求到达了服务却被拒绝，就看凭据、IAM 以及适用的服务边界策略。

私有路由并不授予 API 授权，也不改变身份被允许做什么。传输成功与获得授权应答是两个独立结果，两者都需要。IPv6 路径同样要明确，因为配置 IPv4 前缀并不能说明偏好 IPv6 的客户端会怎样。

Google 关于 本地网络 Private Google Access 的指南 把 DNS 记录和路由要求放在一起讲，因此应拿解析器与通告设置去对照它，而不是对照论坛帖子。然后重跑同一个请求，把应答和路由记在同一张工单里。