如何在不暴露公网 IP 的情况下建立反向 VPN 通道？ - 问题详情 - 创脉思

解读

面试官真正想验证的是：

你是否理解 Cloud SQL 默认只提供私网访问（Private IP）与公网访问（Cloud SQL Auth Proxy）两种模型，而国内金融、政企客户往往既不允许暴露公网 IP，又要求本地 IDC 主动发起连接；
你是否能把“反向 VPN”拆解成**“谁拨号、谁监听、路由怎么放、流量怎么过 GCP 边界”三个层次，并给出在中国合规专线环境**下的落地步骤；
你是否知道Cloud SQL 实例本身没有 VPN 功能，必须把 VPN 终结在VPC 层，再通过Private Service Connect 或 RFC 1918 内网地址把流量引到实例；
你是否能区分**“反向隧道”与“正向隧道”**在国内运营商侧备案、带宽计费的差异，避免答成“直接开公网 VPN 网关”而被一票否决。

知识点

Cloud SQL 私网架构：实例依附于 Google 托管的租户 VPC（tenant project VPC），用户 VPC 通过 Private Service Connect（PSC） 或 VPC Peering 打通，实例本身不感知 VPN；
Cloud VPN 与 HA VPN：GCP 侧仅支持正向拨号（GCP 作为 initiator 或 responder 均需要公网 IP），在中国区因无公网出口，HA VPN 无法直接绑定公网 IP；
反向 VPN 定义：本地 IDC 防火墙作为 IPSec 监听方（responder），GCP 侧作为拨号方（initiator），但 GCP 侧没有公网 IP 可用，必须借助第三方 SD-WAN 或云原生隧道把“反向”转成“双向”；
合规专线：中国区必须使用中国移动、电信、联通 A26 类跨境专线，并在BGP 路由里只宣告 RFC 1918 地址，禁止出现公网网段；
Cloud Router + BGP：HA VPN 依赖 Cloud Router 交换 BGP 路由，但中国区Cloud Router 只能与 Dedicated Interconnect 或 Partner Interconnect 搭配，不能直接用于公网 VPN；
Private IP 访问 Cloud SQL：用户 VPC 与租户 VPC 建立 PSC 终端节点后，Cloud SQL 实例的私网地址落在 172.x 段，VPN 路由需把该段宣告到本地 IDC；
Terraform IAM 最小权限：创建 VPN 隧道需 roles/compute.networkAdmin + roles/iam.serviceAccountUser，创建 PSC 需 roles/servicenetworking.serviceAgent；
MTU 与 MSS 钳制：GCP 侧 VPN 默认 MTU 1460，国内部分老旧思科设备默认为 1500，必须在隧道口强制 TCP MSS 1360，否则 Cloud SQL 长连接会间歇 Reset。

答案

步骤概览（全程不出现公网 IP）：

专线接入
在北京/上海 GCP POP 点通过Partner Interconnect 1000 Mbps 线路接入，BGP ASN 双方私有 64512-65534 范围内，只宣告 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。
VPC 与租户 VPC 打通
在用户项目里启用 Service Networking API，创建 IP 范围 google-managed-services-vpc，建立 Private Service Connect 终端节点，Cloud SQL 实例获得 172.17.17.0/24 私网地址。
Cloud Router 宣告
Cloud Router 与 Partner Interconnect 的 VLAN 连接关联，把 172.17.17.0/24 通过 BGP 宣告给本地 IDC，本地 IDC 回程路由指向隧道子接口。
反向 VPN 隧道（逻辑反向）
由于 GCP 中国区无公网出口，无法在 GCP 侧创建传统 IPSec 监听。变通方案：
- 在本地 IDC 侧部署一台具备公网 IP 的 SD-WAN 盒子（如华为 AR 系列），监听 UDP 4500；
- 在GCP 侧创建无公网 IP 的 GKE 私有节点池，运行 strongSwan 容器，容器通过 Partner Interconnect 默认路由主动拨号到 IDC 盒子；
- 隧道建立后，双方 inner IP 使用 169.254.100.0/30，BGP 用 multi-hop eBGP 交换 172.17.17.0/24 与本地 10.250.0.0/16；
- 安全策略：仅放行 TCP 3307（Cloud SQL 私有端口）与 TCP 5432，拒绝任何 0.0.0.0/0 流量。
验证
从本地 IDC 堡垒机执行
```
gcloud sql connect my-instance --user=root --quiet --private-ip
```
抓包显示源地址 10.250.1.10 → 172.17.17.3，TTL 62，无 NAT 痕迹，证明流量全程私网，未暴露公网 IP。

拓展思考

双活容灾：在上海与新加坡两地各建一条 Partner Interconnect，Cloud SQL 启用跨区域只读副本，通过 BGP AS-Path prepend 让主路径优先走上海，故障时 30 秒内自动切到新加坡，满足国内监管 RPO<5 min 要求；
零信任加固：在隧道内再套一层 Istio mTLS，Cloud SQL 私网地址只授权给 Spiffe ID，即使 BGP 被劫持也无法伪造身份；
成本优化：如果数据量低于 100 GB/月，可改用 Private Service Connect + Cloud SQL Serverless 导出 到 GCS 私有桶，再通过 Storage Transfer Service 走专线拉回本地，省去长期 VPN 带宽费用；
IPv6 演进：Google 中国区目前未开放 IPv6 Private Service Connect，若未来开放，可把隧道直接迁移到 IPv6/IPv4 双栈，避免 IPv4 地址短缺带来的 NAT 日志合规风险。