路由顺序

本页面介绍了具有 Cloud VPN 隧道的下一个跃点的自定义路由如何在 Google Cloud 中运作。

路由类型

Cloud VPN 隧道可以是 VPC 网络中自定义路由的下一个跃点。每个具有下一个跃点 Cloud VPN 隧道的自定义路由都会为离开 VPC 网络的数据包定义一个出站路径

  • 使用动态路由的传统 VPN 或高可用性 VPN 隧道始终由 Cloud Router 路由器管理。Cloud Router 路由器接收来自对等 VPN 网关的 BGP 通告,并会将 BGP 消息发送到该网关。Cloud Router 路由器会在您的 VPC 网络中自动创建和移除自定义动态路由,这些路由在对等网络中具有相应的目标。它还会将路由通告给对等网络,这些路由通向 VPC 网络中子网的 IP 地址范围,或通向您在 Cloud Router 路由器配置中指定的自定义目标。Cloud Router 路由器导入和导出的一组路由由 VPC 网络的动态路由模式控制。

  • 基于政策或路由的传统 VPN 隧道使用静态路由。如果您使用 Cloud Console 创建其中一个隧道,Google Cloud 会根据您在 Cloud VPN 配置中指定的远程 IP 地址范围自动创建自定义静态路由。如果使用 gcloud 命令创建其中一个隧道,则必须手动创建将该隧道用作下一个跃点的静态路由。

场景示例

Google Cloud 在选择应接收数据包的下一个跃点时,遵循明确定义的适用范围和顺序。以下示例展示了路由与 Cloud VPN 之间的常见交互。

与子网路由的交互

下表展示了子网路由和自定义路由的交互方式。每行表示 VPC 网络中子网的可能 IP 地址范围。本地 IP 地址范围为 10.2.0.0/16

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 网络中。
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 网络中。
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 网络中。

当隧道关闭时

动态 (BGP) 路由

如果高可用性 VPN 隧道或使用动态路由的传统 VPN 隧道发生故障,管理相应隧道的 Cloud Router 路由器会在约 40 秒内自动移除获知的自定义动态路由。重新建立隧道后即可重新添加自定义动态路由。

虽然此过程是全自动的,但在 Cloud Router 路由器移除受影响的路由期间仍会导致数据包丢失。

静态路由

Google Cloud 绝不会考虑将未建立 IKE 安全关联 (SA) 的 Cloud VPN 隧道视为有效的下一个跃点。如果 Google Cloud 建立了 IKE SA,则 Google Cloud 会将 Cloud VPN 隧道视为可使用。请注意,只有根据路由顺序被选择为下一个跃点的可使用 Cloud VPN 隧道才会传递流量。可能会改用其他路由的下一个跃点(目标更具体或优先级更高)。

以下场景展示了预期的行为:

  • 如果同一目标有多个自定义静态路由,每个路由具有不同的下一个跃点 Cloud VPN 隧道,则 Google Cloud 仅考虑已建立 IKE 安全关联的路由(第 1 阶段)。在考虑路由优先级之前,已关闭的隧道(即没有有效 IKE 安全关联的隧道)将被忽略

    例如,假设 192.168.168.0/24 目标有 3 个自定义静态路由:第一个路由的优先级为 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

对于动态路由和静态路由,如果同一目标具有多个自定义路由,则 Google Cloud 会使用 ECMP 在隧道之间分配数据包;其中同一目标是指具有相同的优先级和有效的(已建立 IKE SA)下一个跃点隧道。

这种平衡方法基于哈希技术,因此只要该隧道处于启用状态,来自同一流的所有数据包都将使用相同的隧道。

如需测试 ECMP 行为,请使用 iperf3 通过 Cloud VPN 隧道同时发送多个 TCP 流,这些流最好是来自多个 GCP 虚拟机。如果您需要验证 ECMP 行为,请不要使用 ICMP (ping) 执行测试。如需测试通过 Cloud VPN 隧道发送的 ECMP 出站流量,虚拟机实例的“Ping 测试”是不够的,因为当您的来源和目标固定时,系统只会选择一个隧道。ICMP 不涉及端口的概念,是一种固定的协议,因此哈希仅通过两条信息进行计算:来源地址和目标地址(二元组哈希)。

后续步骤