路徑順序

本頁面說明下一個躍點為 Cloud VPN 通道的自訂路徑在 Google Cloud中的運作方式。

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

路徑類型

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

  • Cloud Router 一律會管理使用動態轉送的傳統版 VPN 通道或高可用性 VPN 通道。Cloud Router 會接收來自對等 VPN 閘道的 BGP 通告,並傳送 BGP 訊息給該閘道。Cloud Router 會在 VPC 網路中自動建立及移除動態路徑,也就是目的地為對等互連網路的路徑。此外,Cloud Router 也會將路徑通告至對等互連網路,也就是通告至 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 通道轉送
子網路的 IP 範圍 Google Cloud 靜態 (以政策為準、以路徑為準)
僅限傳統版 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 的流量會保留在虛擬私有雲網路中。
fd20:a:b:c::/64
與內部部署 IP 範圍相同
傳統版 VPN 不支援 IPv6。 通道相關聯的 Cloud Router 會忽略目的地為 fd20:a:b:c::/64 的任何公告路徑。目的地為 fd20:a:b:c::/64 的流量會保留在虛擬私有雲網路中。
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 的流量會保留在虛擬私有雲網路中。
fd20:a:b::/48
比內部部署 IP 範圍更廣泛
(子網路遮罩較小)
傳統版 VPN 不支援 IPv6。 通道相關聯的 Cloud Router 會忽略目的地符合或位於 fd20:a:b::/48 的任何公告路徑,包括 fd20:a:b:c::/64。目的地為 fd20:a:b::/48 的流量會保留在虛擬私有雲網路中。
10.2.99.0/24
比內部部署 IP 範圍窄
(子網路遮罩較長)
Google Cloud 可讓您建立靜態路徑,將目的地設為 10.2.0.0/16,下一個躍點設為 Cloud VPN 通道;不過,前往 10.2.99.0/24 中 IP 位址的流量仍會留在虛擬私有雲網路中。 通道相關聯的 Cloud Router 會接受目的地為 10.2.0.0/16 的通告路徑,但前往 10.2.99.0/24 中 IP 位址的流量仍會留在虛擬私有雲網路內。
fd20:a:b:c::/80
比內部部署 IP 範圍窄
(子網路遮罩較長)
傳統版 VPN 不支援 IPv6。 通道相關聯的 Cloud Router 會接受目的地為 fd20:a:b:c::/64 的通告路徑,但前往 fd20:a:b:c::/80 中 IP 位址的流量仍會留在虛擬私有雲網路內。

通道關閉時

以下各節說明通道中斷時,Cloud VPN 在動態和靜態轉送方面的行為。

動態 (BGP) 轉送

如果使用動態轉送的傳統版 VPN 通道或高可用性 VPN 通道關閉,管理該通道的 Cloud Router 會自動移除已知路徑。偵測中斷所需的時間長度,取決於設定的 BGP keepalive 間隔保留計時器。通道重新建立後,即可重新加入已知路徑。

這項程序完全自動執行,但 Cloud Router 移除受影響的路徑時,仍可能導致部分封包遺失。

靜態轉送

Google Cloud 一律不會將未建立 IKE 安全關聯 (SA) 的 Cloud VPN 通道視為有效的下一個躍點。如果 Cloud VPN 通道已建立 IKE SA, Google Cloud會將其視為運作中。只有在根據轉送順序選取 Cloud VPN 通道做為下一個躍點時,運作中的 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,透過 Cloud VPN 通道傳送多個同步 TCP 串流,最好是從多個Google Cloud 虛擬機器 (VM) 執行個體傳送。如要驗證 ECMP 行為,請勿使用 ICMP (ping) 執行測試。從一個 VM 執行個體進行 ping 測試,不足以測試透過 Cloud VPN 通道的 ECMP 輸出,因為當您有固定的來源和目的地時,系統只會選取一個通道。ICMP 沒有通訊埠的概念,而且是固定通訊協定,因此雜湊碼只會根據兩項資訊計算:來源和目的地地址 (雙元組雜湊碼)。

後續步驟

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