通过 VPN 访问 Cloud SQL 私有 IP：没人导出的那条路由

很多团队相信 Cloud SQL 私有 IP 只能在 VPC 内部使用，这个误解之所以长期存在，是因为故障看起来像数据库问题。Google 文档中明确写了可通过 Cloud VPN 或 Cloud Interconnect 连接的网络来访问。这些网络需要的并不是某种特殊的数据库功能，而是两次很容易只做一半的路由交换。隧道建立、计算实例响应正常，数据库连接却超时，正是这种组合把人引向了错误的控制台。

误区：私有 IP 意味着只对 VPC 私有

专用服务访问实际上是你所在网络与 Google 拥有的生产者网络之间的一次 VPC 对等连接。服务所分配的网段位于生产者一侧，实例地址就在其中。正因为是对等连接，项目中的数据库才能落在 VPC 有路由、却没有任何显式子网包含的地址上。

既然是对等连接，它就带有对等连接的行为，其中一部分就是自定义路由不会自动穿越。

误区：隧道通了，数据库路由自然就通了

有两个网段必须走完这段路。第一个是客户端前缀：本地网络必须以具体前缀被 Cloud Router 知晓，因为默认路由无法提供生产者网络回程所需的导入。第二个是分配的服务网段，外部一侧必须学到它，发往数据库的数据包才有去处。这是在不同边界上维护的两条不同路由，修好一条，另一条仍然是断的。

在 Google 一侧，这意味着在相关的对等连接上启用 Export custom routes，并把分配的服务网段加入 Cloud Router 为该隧道通告的路由中。

已有的通告要保留。加入服务网段不应删掉同一条 BGP 会话为其他流量承载的 VPC 路由，而整组通告被整体替换，则是藏在第一次故障背后的第二次故障。还要检查外部设备上的有效路由，因为能 ping 通 VPN 网关或另一个子网，只能证明传输是通的。

误区：Cloud SQL Auth Proxy 能解决网络问题

The Auth Proxy 应用与实例之间提供受支持的认证和加密传输。它并不创建路由。在没有通往私有网络路径的主机上启动代理，失败方式与直连完全相同，而且日志对原因的解释更少。把代理移到有连通性的主机上，改变的是这一段路径中哪一腿必须通，这是真正的设计决策，而不是绕路。

它做不到的是让一台断网的笔记本电脑访问仅私有的实例。

误区：Private Service Connect 遵循同样的规则

Private Service Connect 使用你自己子网内的端点，以及你可控的 DNS 安排，所以通往它的路由就是一条通往你自有地址的普通路由。对等连接的导出设置并不适用于这种设计，把对等连接的改动照搬到 PSC 部署上，只会增加风险，不会增加可达性。

两者都给你一个私有地址，相似之处到此为止。

按正确顺序排查路径

先从外部客户端测试数据库的 TCP 端点。TCP 握手完成，说明路由、防火墙和监听都在位，下一项测试应是一次被允许的认证操作。此时认证被拒绝其实是好消息，因为它证明数据库监听确实应答了。ICMP 超时几乎说明不了数据库访问的问题，因为很多路径会丢弃它，却照样转发 TCP。

如果你的客户端网段不在 RFC 1918 范围内，在断定该设计不受支持之前，请先核对额外的路由导出和网络授权要求。

把四样东西与连接一起记录下来：外部前缀、分配的服务网段、涉及的对等连接，以及负责通告的路由器。这四样足以解释整条私有路径，也能取代“Cloud SQL 要么永远需要代理、要么根本不能走 VPN”这类传闻。