路徑順序

本頁面說明在 Google Cloud中,具有 Cloud VPN 通道下一個躍點的自訂路徑如何運作。

如要瞭解 Google Cloud 路由的背景資訊,包括路由適用性、路由順序和靜態路由參數,請參閱虛擬私有雲 (VPC) 路由總覽

路徑類型

Cloud VPN 通道可做為 VPC 網路中自訂路徑的下一個躍點。每個含有下一個躍點 Cloud VPN 通道的自訂路徑,都會為離開虛擬私人雲端網路的封包定義輸出路徑

  • Cloud Router 一律會管理使用動態轉送的傳統版 VPN 通道或 HA VPN 通道。Cloud Router 會接收 BGP 廣告,並將 BGP 訊息傳送至對等 VPN 閘道。Cloud Router 會在 VPC 網路中自動建立及移除動態路徑,也就是目的地為對等網路的路徑。它也會將路徑通告給對等網路,也就是通往 VPC 網路中子網路 IP 範圍的路徑,或通往 Cloud Router 設定中您指定的自訂目的地的路徑。虛擬私人雲端網路的動態轉送模式會控制 Cloud Router 匯入和匯出的路徑組合。

  • 採用政策或路徑的傳統版 VPN 通道會使用靜態轉送。如果您使用 Google Cloud 主控台建立其中一個通道,Google Cloud 會根據您在 Cloud VPN 設定中指定的遠端 IP 範圍,自動建立靜態路徑。如果您使用 Google Cloud CLI 建立其中一個通道,必須手動建立使用通道做為下一個躍點的靜態路徑。

範例情境

Google Cloud 會在選取應傳送封包的下一個躍點時,遵循明確定義的適用性和順序。以下範例說明路徑和 Cloud VPN 之間的常見互動情形。

與子網路路由的互動

下表說明子網路路由和自訂路由的互動方式。每個資料列代表虛擬私有雲網路中子網路的可能 IP 範圍。在內部網路範圍中,IPv4 為 10.2.0.0/16,IPv6 為 fd20:a:b:c::/64

只有設為使用 IPv4 和 IPv6 雙重堆疊類型的高可用性 VPN 閘道,才支援 IPv6 流量。

虛擬私有雲網路 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.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::/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 SA (第 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 傳送多個同時的 TCP 串流,最好是透過 Cloud VPN 通道,從多個Google Cloud 虛擬機器 (VM) 執行個體傳送。如果您需要驗證 ECMP 行為,請勿使用 ICMP (ping) 執行測試。從單一 VM 執行個體進行的 ping 測試無法測試透過 Cloud VPN 通道以 ECMP 為基礎的輸出流量,因為在有固定來源和目的地時,系統只會選取一個通道。ICMP 沒有通訊埠的概念,且為固定通訊協定,因此雜湊碼只會根據兩項資訊計算:來源和目的地位址 (二元組雜湊碼)。

後續步驟

  • 如要瞭解 Cloud VPN 的基本概念,請參閱 Cloud VPN 總覽
  • 如要解決使用 Cloud VPN 時可能遇到的常見問題,請參閱疑難排解