如何排查 VPC 对等网路由冲突导致的连接超时？ - 问题详情 - 创脉思

解读

在国内多云混合或集团云落地的场景里，VPC 对等网路由冲突是 Cloud SQL 私有连接（Private IP）最常见的“隐形杀手”。
面试官想验证三点：

你是否理解 Cloud SQL 在租户 VPC（Google 托管）与用户 VPC 之间通过VPC 对等互连建立通道，而非普通实例 ENI；
能否用分层诊断法快速区分“路由黑洞”“防火墙阻断”“代理配置错误”三类症状；
是否熟悉国内网络合规（如跨境专线、跨省 MPLS）带来的额外跳数与 MTU 限制，能把 Google 全球路由与国内云厂商路由差异解释清楚。

知识点

Cloud SQL 私有连接架构：Google 在租户项目里自动创建一条不可见的 VPC 对等连接（servicenetworking-googleapis-com），并在用户 VPC 侧下发目的网段为 /24 的自定义路由，优先级 1000。
路由冲突判定：若用户 VPC 已存在相同或更具体前缀（≤24）指向 VPN/专线/其他对等网，则 GCP 路由不会生效，表现为间歇性 5 秒 SYN 超时。
国内常见踩坑：
– 集团云“共享 VPC”子网与 Cloud SQL 网段重叠（如 10.127.0.0/24）；
– 跨省云联网发布聚合路由 10.0.0.0/8，掩码更短却被运营商 MPLS 优先；
– MTU 1500 vs 1460 导致大包分片被运营商丢弃，看似路由可达却应用超时。
排查工具：
– gcloud compute routes list --filter="nextHopPeering=servicenetworking-googleapis-com" 验证预期路由是否存在；
– gcloud compute networks get-effective-routes <vpc-name> --region=<region> 查看实际生效顺序；
– ping -M do -s 1472 <cloud-sql-private-ip> 快速确认 MTU 黑洞；
– Cloud SQL Auth Proxy 日志若出现**“dial tcp <ip>:3307: i/o timeout”** 90% 为路由或防火墙问题。

答案

回答时分四步，每步给出可落地的命令与输出示例，让面试官听到就能“脑内复现”。

确认现象
“用户在北京 VPC 子网 10.4.0.0/24 通过内网域名连接 Cloud SQL PostgreSQL，间歇报 ‘connection timeout after 5 s’，同一 VPC 访问北京 GKE 业务正常，排除容器出口 NAT 问题。”
分层验证路由
a) 在用户项目执行
gcloud compute routes list --filter="nextHopPeering=servicenetworking-googleapis-com"
发现返回为空，说明Cloud SQL 侧未成功下发路由。
b) 继续执行
gcloud compute networks get-effective-routes beijing-vpc --region=asia-northeast1
看到 10.127.0.0/24 的下一跳是 peer=beijing-cisco-vpn，优先级 800，比 GCP 默认 1000 更高，确认路由被 VPN 抢占比。
根因定位
与客户网络组核对，发现集团云联网自动把北京→上海 MPLS 的聚合路由 10.127.0.0/16 广播进北京 VPC，掩码 /16 比 Cloud SQL 的 /24 更短，但管理距离优先，导致流量被送往上海 Cisco 路由器，形成路由黑洞。
修复与灰度
– 在VPC 路由表里增加一条更具体的 10.127.0.0/24 指向 nextHopPeering=servicenetworking-googleapis-com，优先级 700；
– 使用 Terraform 固化：
```
resource "google_compute_route" "sql-private" {
  name              = "beijing-to-cloudsql-private"
  network           = "beijing-vpc"
  dest_range        = "10.127.0.0/24"
  next_hop_peering  = "servicenetworking-googleapis-com"
  priority          = 700
}
```
– 灰度发布：先在一台跳板机 curl -w "@curl-format.txt" -o /dev/null -s "jdbc:postgresql://<private-ip>:5432/postgres" 验证 time_total <100 ms 且稳定 50 次；
– 最后把国内跨域 MPLS 的聚合路由改为 ≥/20，避免再次冲突，并写入运维手册：Cloud SQL 网段一旦在 Service Networking API 分配，禁止在集团侧发布相同或更具体前缀。

拓展思考

如果客户坚持不修改现有 VPN 路由，能否用 Private Service Connect（PSC） 替代 VPC 对等？
答：可以，PSC 发布的是用户自定义别名 IP，不会与旧 VPN 路由重叠；但国内需注意 PSC 端点计费（每 GiB 0.01 USD）与跨境合规审计（需完成 GAAP 评估）。
当 Cloud SQL 启用跨区域高可用（北京→南京）时，Google 会再建一条对等连接，南京 VPC 同样可能遭遇华东 MPLS 聚合路由冲突，建议提前在Landing Zone 设计阶段把 Service Networking 网段池统一规划为 10.250–10.255/16，并在全国 MPLS 路由策略里永久拉黑，形成**“云数据库专属地址段”**，一劳永逸。