通过Open VPN连接仅含私有IP的Postgres 13 Cloud SQL实例故障排查及替代VPN方案咨询

首先，咱们先排查你当前OpenVPN连接失败的核心原因，再聊聊除了Cloud Proxy之外的可行VPN方案：

一、排查OpenVPN连接超时的原因 #

你遇到的Connection timed out错误，大概率是流量没正确路由到Cloud SQL所在的VPC，或者防火墙/路由配置有遗漏，按下面的步骤逐一检查：

• 确认VPN路由是否正确推送：Cloud SQL的私有IP属于GCP VPC的某个子网，你的OpenVPN服务器需要给Windows客户端推送这个子网的路由规则，让访问Cloud SQL的流量走VPN隧道。你可以在Windows上执行route print命令，查看目标子网的下一跳是不是VPN的虚拟网卡；也可以检查OpenVPN服务器的配置，确保有类似push "route <Cloud-SQL子网CIDR> 255.255.255.0"的规则。
• 验证VPN服务器的网络位置：如果你的OpenVPN服务器不在Cloud SQL所在的GCP VPC里，那它根本没法直接访问Cloud SQL的私有IP。必须把OpenVPN部署在同VPC的Compute实例上，或者通过VPC peering把VPN所在的VPC和Cloud SQL的VPC连通。
• 检查防火墙规则的细节：你把OpenVPN的IP加入白名单，但要注意：
  • Cloud SQL的入站防火墙规则，要允许来自VPN客户端IP段或VPN服务器所在子网的TCP 5432端口流量；
  • VPN服务器所在VPC的出站规则，要允许到Cloud SQL子网的TCP 5432端口流量；
  • 确保防火墙规则的优先级足够高，不会被其他拒绝规则覆盖。
• 测试VPN连通性：先在VPN服务器上执行psql -h <Cloud-SQL私有IP> -U <用户名>，看看能不能连接。如果服务器能连但客户端不行，那就是客户端路由或者VPN推送规则的问题；如果服务器也连不上，那就是VPC/防火墙的配置问题。

二、除了Cloud Proxy的其他VPN方案 #

当然可以用其他VPN实现，这里推荐几种靠谱的方案：

1. GCP Cloud VPN（官方原生方案） #

这是最稳定的选择，和GCP生态完全集成：

• 创建一个Cloud VPN网关，配置IPsec隧道连接你的本地网络和GCP VPC；
• 在本地路由器上配置对应的VPN参数，让本地Windows机器的流量能通过隧道访问GCP VPC子网；
• 最后在Cloud SQL的防火墙里允许本地网络的CIDR访问5432端口即可。
  这种方案不需要额外维护中间服务器，可靠性和安全性都有保障。

2. 部署在GCP VPC内的第三方VPN（比如你的OpenVPN CE） #

如果坚持用OpenVPN，调整配置即可：

• 在Cloud SQL所在的GCP VPC里创建一个Compute实例，安装OpenVPN CE作为服务器；
• 配置OpenVPN服务器推送Cloud SQL子网的路由规则给客户端；
• 配置VPC防火墙，允许VPN客户端的IP段访问Cloud SQL的5432端口，同时允许VPN实例的入站VPN端口（比如1194）流量；
• Windows客户端连接这个VPN后，就能直接用私有IP访问Cloud SQL了。

3. 零信任VPN工具（如Tailscale） #

这类工具配置更简单，适合小型团队或个人使用：

• 在GCP VPC内的任意Compute实例上安装Tailscale节点；
• 你的Windows机器也安装Tailscale客户端，加入同一个Tailscale网络；
• 配置Cloud SQL的防火墙，允许Tailscale节点的IP或Tailscale子网访问5432端口；
• 之后Windows机器就能通过Tailscale的点对点网络直接访问Cloud SQL的私有IP，不需要复杂的路由配置。

最后注意事项 #

不管用哪种方案，核心都是确保：

1. 你的Windows机器的流量能通过VPN路由到Cloud SQL所在的VPC子网；
2. 防火墙规则允许对应的IP段访问Cloud SQL的5432端口；
3. Cloud SQL实例的私有网络配置正确，没有限制跨VPC或VPN的访问。

内容的提问来源于stack exchange，提问作者Nishchal Dinesh