Google Cloud VPN 怎么配置，本地数据中心如何连接 Google Cloud

企业把部分业务迁移到Google Cloud以后，最先遇到的问题往往不是虚拟机怎么创建，而是原来的办公室、机房、数据库和内部应用怎样继续与云端通信。如果本地数据中心拥有10.0.0.0/16这样的私有网络，而Google Cloud VPC使用10.20.0.0/16，两边的服务器需要像处于同一个企业网络一样互相访问，那么就需要解决路由、加密、身份认证、故障切换和地址规划等一系列问题。

Google Cloud VPN提供的是基于IPsec的加密连接。对于新的生产环境，尤其是需要BGP动态路由、高可用或者更复杂混合云网络的场景，通常应该从HA VPN开始设计，而不是按照旧的Classic VPN架构搭建。Google已经停止支持Classic VPN的新BGP动态路由配置，现有部分旧配置虽然仍可能继续工作，但已经不适合作为新的生产架构。

Google Cloud的HA VPN网关是由Google管理的区域级资源，并不是用户在VPC子网里面启动的一台普通虚拟机。一个HA VPN网关拥有两个接口，每个接口都有自己的区域性外部IP地址。企业数据中心一侧则需要准备支持IPsec的VPN设备或软件网关，例如企业防火墙、路由器或者其他支持站点到站点IPsec VPN的设备。Google Cloud中还需要配置external VPN gateway资源，用来描述本地对等VPN网关的接口信息。

因此，一个典型的混合云结构可以理解为：本地服务器和交换网络连接企业防火墙，防火墙通过公网连接Google Cloud HA VPN网关，IPsec负责加密隧道，而Cloud Router负责通过BGP交换双方的私有网络路由。这样，Google Cloud知道10.0.0.0/16应该通过VPN发送，本地路由器也知道Google Cloud的VPC地址应该进入VPN隧道。

第一步不是创建VPN，而是规划地址空间。如果本地数据中心已经使用10.0.0.0/16，那么Google Cloud VPC就不能再使用完全相同的地址范围。两边的网络地址重叠以后，路由器无法明确判断一个目标IP到底属于本地网络还是云端网络，很多后续设计都会因此陷入麻烦。生产环境通常还应该提前规划不同环境，例如生产VPC、开发VPC、灾备VPC以及未来可能连接的其他数据中心，避免今天能连通，几年以后网络扩展时却发现地址空间已经没有办法继续使用。

完成地址规划以后，需要确定本地VPN设备的公网IP、Google Cloud项目、目标VPC、部署区域以及Cloud Router。对于HA VPN，Cloud Router是动态路由的重要组成部分。Cloud Router本身并不是一台需要用户维护的传统路由器，而是Google Cloud提供的托管BGP路由服务，用来与本地路由器交换动态路由。Google官方的HA VPN配置流程要求为每条VPN隧道配置对应的Cloud Router接口和BGP会话。

随后创建HA VPN gateway，并建立本地数据中心与Google Cloud之间的VPN tunnel。IKEv2是当前推荐的选择，也是支持HA VPN IPv6流量时所要求的IKE版本。预共享密钥，也就是PSK，需要在Google Cloud和本地VPN设备两端保持一致。它不是IPv4地址，也不存在“必须使用IPv4地址作为字符串”的要求。Google Cloud创建隧道时可以直接生成随机的共享密钥，创建以后应该将其安全保存，因为控制台不会再次显示已经创建的PSK。

加密算法也不能简单写成“推荐AES-256”。实际配置应该根据Google Cloud支持的IKE/IPsec算法以及本地防火墙能力进行协商。Google Cloud目前支持自定义cipher配置，但两端必须选择兼容的参数。Cloud VPN使用IPsec ESP Tunnel Mode，IKE阶段负责建立和协商安全关联，ESP负责对实际隧道数据进行保护。

对于生产系统，最重要的设计通常不是“能不能建立一条隧道”，而是发生故障以后还能不能继续通信。HA VPN的高可用架构要求至少配置两条隧道，分别连接Google Cloud HA VPN网关的两个接口。Google官方文档明确说明，如果Google Cloud一侧只配置一条隧道，就不能获得99.99%的HA VPN可用性SLA。根据对端设备的能力，可以连接一个拥有两个公网接口的本地VPN设备，也可以连接两个独立的本地VPN设备。

如果本地防火墙只有一个公网IP，也不意味着HA VPN一定无法实现双隧道。Google支持一个对等VPN网关只有一个外部IP的配置，两条隧道可以连接到同一个对端地址，同时分别使用Google Cloud HA VPN的两个接口。对于企业级环境，如果本地条件允许，使用两个独立的VPN设备或者两个独立的公网接口通常可以进一步降低设备本身成为单点故障的风险。

路由配置则是整个系统中非常容易出错的部分。对于规模较小、网络变化很少的环境，可以使用静态路由或者route-based VPN。但如果企业拥有多个VPC、多个数据中心、灾备站点或者需要自动故障切换，BGP通常更加合适。HA VPN配合Cloud Router可以让Google Cloud与本地路由器动态交换前缀，而不是每增加一个网络都手工修改大量静态路由。Google Cloud目前把HA VPN和BGP作为动态路由生产架构的重要组成部分。

例如，本地数据中心使用10.0.0.0/16，Google Cloud VPC使用10.20.0.0/16。本地路由器通过BGP向Cloud Router宣告10.0.0.0/16，Google Cloud再把VPC中的相关网络前缀通过BGP发送给本地设备。这样双方都知道哪些目的地址应该进入VPN，而不需要把某一个“本地网关IP”简单写成所有流量的静态下一跳。

对于HA VPN，还可以利用BGP路由优先级设计active-active或者active-passive架构。Google Cloud允许通过不同的advertised route priority控制路径选择。如果两个路径使用相同的优先级，可以形成相应的等价路径；如果希望一条链路作为主要路径，另一条作为备用路径，则可以通过不同的路由优先级进行控制。

防火墙规则同样不能忽略。Google Cloud VPC侧需要允许实际业务所需要的协议和端口，例如内部服务器之间使用TCP 443，就需要针对相应源地址、目标地址和协议配置VPC防火墙规则。本地数据中心的防火墙也需要允许IPsec所需要的Internet流量。具体包括IKE使用的UDP 500，以及发生NAT-T时使用的UDP 4500。不能简单地说“允许ESP就可以”，因为实际网络中是否存在NAT会影响IPsec封装方式。

NAT也不是所有VPN部署都必须配置的步骤。很多企业网络本身就拥有直接公网出口，VPN设备直接使用公网地址，这种情况下并不需要为了VPN额外配置NAT。如果VPN网关位于NAT设备后面，则需要按照Google Cloud支持的NAT方式进行设计。Google明确说明，Cloud VPN在特定NAT场景中要求NAT-T，并不支持一个公网IP通过一对多NAT同时承载多个对等VPN网关的这种架构。

建立隧道以后，测试不能只看Google Cloud控制台显示“Tunnel Established”。隧道建立只说明IPsec控制面已经成功建立，并不代表业务流量一定能够正常通过。应该分别测试本地到Google Cloud、Google Cloud到本地以及不同子网之间的访问，并检查BGP邻居状态、学习到的路由、实际转发路径和防火墙日志。

例如，本地一台服务器10.0.1.20访问Google Cloud中的10.20.1.10。如果Ping被禁用，不能因为ICMP不通就直接判断VPN故障。更可靠的方式是根据实际业务使用TCP 443、数据库端口或者其他应用协议进行测试，同时检查两端路由表和防火墙日志。网络排障应该按照“隧道是否建立、BGP是否建立、路由是否学习、VPC防火墙是否允许、服务器本身是否监听”这样的链路逐层定位。

性能方面也不能简单规定“吞吐量必须超过500Mbps、延迟必须低于50ms、丢包率必须低于0.1%”。这些数字没有普遍适用的工程意义。VPN实际性能取决于本地互联网出口、对端设备、Google Cloud区域、路径、数据包大小、加密处理能力以及业务流量特征。Google目前给出的Cloud VPN单条隧道限制是每秒250,000个数据包，综合进出方向计算，根据平均数据包大小，对应的吞吐能力大约在1Gbps到3Gbps之间。

这也解释了为什么不能简单说“VPN最多3Gbps”。3Gbps只是特定数据包大小条件下的近似带宽，真正限制条件是每秒250,000个包以及双方网络设备和公网链路。如果大量流量由小数据包组成，达到PPS限制以后，实际Gbps吞吐量可能明显低于3Gbps。对于吞吐量需求较大的企业，可以通过增加隧道来提高整体VPN容量，Google官方也提供了增加HA VPN隧道数量的拓扑方案。

如果企业的数据中心需要长期运行大规模数据复制、数据库同步、灾备或者大量文件传输，仅仅增加VPN隧道可能不是最合理的方案。这时候应该比较Cloud Interconnect。Dedicated Interconnect、Partner Interconnect等方案可以提供更加稳定的专用网络连接，而不是把所有企业数据都压在公共Internet上的IPsec隧道里。

Cloud Interconnect的容量也远远不是简单的“10Gbps”。当前Google Cloud支持的Dedicated Interconnect连接可以由多个物理电路组成，最高可以达到多个400Gbps电路组合的规模；单个VLAN attachment的容量也可以根据产品和连接类型达到更高水平。因此，原稿中“Cloud Interconnect支持10Gbps”已经过时，把10Gbps当成产品上限是不准确的。

Cloud Interconnect还可以和HA VPN结合使用。例如企业希望通过专用连接获得更稳定的基础网络，同时仍然希望使用IPsec进行额外加密，可以设计HA VPN over Cloud Interconnect。Google Cloud目前也支持在Interconnect VLAN attachment上建立加密的HA VPN架构。

对于一般中小企业，如果只是需要让办公室、机房和Google Cloud中的几个私有子网互通，HA VPN通常已经足够。它的部署门槛和成本明显低于专用互联，而且可以通过BGP、双隧道和合理的监控设计实现相当可靠的混合云连接。对于需要持续传输大量数据的企业，或者数据库、灾备系统对带宽和稳定性有较高要求的环境，则应该认真评估Cloud Interconnect，而不是把VPN不断堆叠成越来越复杂的隧道网络。

SD-WAN也不是Cloud VPN的简单替代品。SD-WAN解决的是企业WAN路径选择、分支互联、应用识别和多链路管理等更广泛的问题，可以把Internet、专线、LTE/5G等多种链路纳入统一策略。如果企业本身已经部署SD-WAN，则可以让SD-WAN设备承担本地网络的路径选择，再通过IPsec或者其他受支持的连接方式进入Google Cloud。

最终，一个稳定的Google Cloud混合云网络应该至少考虑地址规划、HA VPN双隧道、Cloud Router、BGP、防火墙、MTU、NAT-T、监控、故障切换和日志，而不是把它理解成“在Google Cloud创建VPN，然后填一个预共享密钥”。对于小规模环境，静态路由可以降低部署复杂度；对于生产企业网络，BGP通常更容易随着网络规模增长而维护；对于高带宽和长期稳定连接，则应该进一步评估Cloud Interconnect。

VPN的价值也从来不只是把两个网络“连起来”。它实际上建立了一条跨越公共网络的加密传输路径，而真正决定这条路径能否长期稳定工作的，是路由设计、故障域划分、地址规划、链路冗余、MTU处理和监控体系。把这些基础工作做好以后，Google Cloud只是网络中的另一端，而不是一套需要不断手工维护的神秘黑盒。