本页面介绍了具有 Cloud VPN 隧道的下一个跃点的自定义路由如何在 Google Cloud 中运作。
如需了解 Google Cloud 路由的背景信息（包括路由适用性、顺序和静态路由参数），请参阅 Virtual Private Cloud (VPC) 路由概览。
路由类型
Cloud VPN 隧道可以是 VPC 网络中自定义路由的下一个跃点。每个具有下一个跃点 Cloud VPN 隧道的自定义路由都会为离开 VPC 网络的数据包定义一个出站路径：
Cloud Router 路由器始终会管理使用动态路由的传统 VPN 隧道或高可用性 VPN 隧道。Cloud Router 路由器接收来自对等 VPN 网关的 BGP 通告，并会将 BGP 消息发送到该网关。Cloud Router 路由器会在您的 VPC 网络中自动创建和移除自定义动态路由，这些路由在对等网络中具有相应的目标。它还会将路由通告给对等网络，这些路由通向 VPC 网络中子网的 IP 地址范围，或通向您在 Cloud Router 路由器配置中指定的自定义目标。由 VPC 网络的动态路由模式控制 Cloud Router 路由器导入和导出的一组路由。
基于政策或路由的传统 VPN 隧道使用静态路由。如果您使用 Google Cloud 控制台创建其中一个隧道，Google Cloud 会根据您在 Cloud VPN 中指定的远程 IP 地址范围自动创建自定义静态路由配置。如果使用 Google Cloud CLI 创建其中一个隧道，则必须手动创建将该隧道用作下一个跃点的静态路由。
场景示例
Google Cloud 在选择应接收数据包的下一个跃点时，遵循明确定义的适用范围和顺序。以下示例展示了路由与 Cloud VPN 之间的常见交互。
与子网路由的交互
下表展示了子网路由和自定义路由的交互方式。每行表示 VPC 网络中子网的可能 IP 地址范围。本地范围为 10.2.0.0/16 (IPv4) 和 fd20:a:b:c::/64 (IPv6)。
只有配置了 IPv4 和 IPv6 双栈类型的高可用性 VPN 网关才支持 IPv6 流量。
| VPC 网络 | Cloud VPN 隧道路由 | |
|---|---|---|
| Google Cloud 子网的 IP 地址范围 | 静态（基于政策、基于路由） 仅限传统 VPN |
动态 (BGP) 传统 VPN 或高可用性 VPN |
10.2.0.0/16与本地 IP 地址范围相同 |
Google Cloud 不允许创建目标为 10.2.0.0/16 以及下一个跃点为 Cloud VPN 隧道的自定义静态路由。 |
隧道的关联 Cloud Router 路由器会忽略目标为 10.2.0.0/16 的所有通告路由。传入 10.2.0.0/16 的流量仍会保留在您的 VPC 网络中。 |
fd20:a:b:c::/64与本地 IP 地址范围相同 |
传统 VPN 不支持 IPv6。 | 隧道的关联 Cloud Router 路由器会忽略目标为 fd20:a:b:c::/64 的所有通告路由。传入 fd20:a:b:c::/64 的流量仍会保留在您的 VPC 网络中。 |
10.0.0.0/8比本地 IP 地址范围更宽 （子网掩码较小） |
Google Cloud 不允许创建目标为 10.2.0.0/16 以及下一个跃点为 Cloud VPN 隧道的自定义静态路由。 |
隧道的关联 Cloud Router 路由器会忽略目标符合 10.0.0.0/8（包括 10.2.0.0/16）的所有通告路由。传入 10.0.0.0/8 的流量仍会保留在您的 VPC 网络中。 |
fd20:a:b::/48比本地 IP 地址范围更宽 （子网掩码较小） |
传统 VPN 不支持 IPv6。 | 隧道的关联 Cloud Router 路由器会忽略目标符合 fd20:a:b::/48（包括 fd20:a:b:c::/64）的所有通告路由。传入 fd20:a:b::/48 的流量仍会保留在您的 VPC 网络中。 |
10.2.99.0/24比本地 IP 地址范围更窄 （子网掩码更长） |
Google Cloud 允许您创建具有 10.2.0.0/16 目标和下一个跃点 Cloud VPN 隧道的自定义静态路由；但传入 10.2.99.0/24 中各 IP 地址的流量仍保留在您的 VPC 网络中。 |
隧道的关联 Cloud Router 路由器接受目标为 10.2.0.0/16 的通告路由；但传入 10.2.99.0/24 中各 IP 地址的流量仍保留在您的 VPC 网络中。 |
fd20:a:b:c::/80比本地 IP 地址范围更窄 （子网掩码更长） |
传统 VPN 不支持 IPv6。 | 隧道的关联 Cloud Router 路由器接受目标为 fd20:a:b:c::/64 的通告路由；但传入 fd20:a:b:c::/80 中各 IP 地址的流量仍保留在您的 VPC 网络中。
|
当隧道关闭时
动态 (BGP) 路由
如果高可用性 VPN 隧道或使用动态路由的传统 VPN 隧道发生故障，管理相应隧道的 Cloud Router 路由器会自动移除已知路由。检测中断所需的时间取决于是否启用了双向转发检测 (BFD)。如果启用了 BFD，则检测会在 BGP 限制计时器到期时开始。否则，检测会在 60 秒内开始。重新建立隧道后即可重新添加已知路由。
虽然此过程是全自动的，但在 Cloud Router 路由器移除受影响的路由期间仍会导致数据包丢失。
静态路由
Google Cloud 绝不会将 Cloud VPN 隧道视为建立尚未建立 IKE 安全关联 (SA) 的有效下一个跃点。如果 Cloud VPN 隧道已建立 IKE SA，则 Google Cloud 会将其视为运行。只有根据路由顺序被选择为下一个跃点的可使用 Cloud VPN 隧道才会传递流量。可能会改用其他路由的下一个跃点（目标更具体或优先级更高）。
以下场景展示了预期的行为：
如果同一目标有多个自定义静态路由，每个路由具有不同的下一个跃点 Cloud VPN 隧道，则 Google Cloud 仅考虑已建立 IKE SAs（第 1 阶段）。在关闭路由优先级之前，系统会关闭（即没有有效的 IKE SA）的隧道。
例如，假设您的
192.168.168.0/24目标具有三个自定义静态路由：一个优先级为10，其下一个跃点 Cloud VPN 隧道关闭，第二个优先级为20下一个跃点隧道已启动，第三个优先级为30的下一个跃点隧道也启动。Google Cloud 会将流量发送到第二个下一个跃点，即使其路由的优先级比已关闭下一个跃点的路由低也是如此。如果重新建立第一条隧道，则 Google Cloud 会将其视为有效的下一个跃点，并改用该路由。如果所有 Cloud VPN 隧道（作为目标相同的自定义静态路由的下一个跃点）都被关闭，则流量会中断。即使具有一个运行下一个跃点的下一个跃点隧道的自定义静态路由，也会丢失流量。
例如，假设您有一个
192.168.168.0/24的自定义静态路由，其下一个跃点 Cloud VPN 隧道已关闭（没有有效的 IKE SA）。即使192.168.0.0/16有一个路由，其下一个跃点为可使用的 Cloud VPN 隧道，传入192.168.168.0/24的流量也会丢失。这是因为 Google Cloud 始终选择目标最具体的路由。
当流量在各跃点 Cloud VPN 隧道之间切换时，您应该仍会遇到数据包丢失的问题。传输中的数据包可能会丢失，需要重新传输。
在各隧道之间使用 ECMP
对于动态路由和静态路由，如果同一目标具有多个自定义路由，并且目标优先级相同且有效（已建立 IKE SA），则 Google Cloud 会使用等价多路径 (ECMP) 路由，用于在隧道之间分配数据包。
这种平衡方法基于哈希技术，因此只要该隧道处于启用状态，来自同一流的所有数据包都将使用相同的隧道。
如需测试 ECMP 行为，请使用 iperf3 通过 Cloud VPN 隧道同时发送多个 TCP 流，这些流最好是来自多个 Google Cloud 虚拟机 (VM) 实例。如果您需要验证 ECMP 行为，请勿使用 ICMP (ping) 进行测试。如需测试通过 Cloud VPN 隧道发送的 ECMP 出站流量，虚拟机实例的 ping 测试是不够的，因为当您的来源和目标固定时，系统只会选择一个隧道。ICMP 不涉及端口的概念，是一种固定的协议，因此哈希仅通过两条信息进行计算：来源地址和目标地址（二元组哈希）。
后续步骤
- 要了解 Cloud VPN 的基本概念，请参阅 Cloud VPN 概览。
- 如需帮助解决使用 Cloud VPN 时可能会遇到的常见问题，请参阅问题排查。