ルート

Google Cloud のルートは、ネットワーク トラフィックが仮想マシン（VM）インスタンスから他の宛先に到達する経路を定義します。これらの宛先は、Google Cloud Virtual Private Cloud（VPC）ネットワークの内部（別の VM など）の場合もあれば、VPC ネットワークの外部の場合もあります。

VPC ネットワークの場合、ルートは 1 つの宛先（CIDR 形式）と 1 つのネクストホップで構成されます。VPC ネットワークのインスタンスがパケットを送信したときに、パケットの宛先アドレスがルートの宛先範囲内にある場合、Google Cloud はパケットをルートのネクストホップに送信します。

このページでは、Google Cloud でのルートの機能について説明します。

Google Cloud でのルーティング

VPC ネットワークは、スケーラブルな分散仮想ルーティング メカニズムを使用します。ネットワークに割り当てられている物理デバイスはありません。ルートを個別に適用することもできますが、VPC ネットワークのルーティング テーブルが VPC ネットワーク レベルで定義されています。

VM インスタンスには、ネットワークのルーティング テーブルから適用可能なルートを通知するコントローラがあります。VM から送信されるパケットは、ルーティング順序に基づいて、適用可能なルートで適切なネクストホップに配信されます。ルートを追加または削除すると、最終的に一貫性のある設計によって、一連の変更が VM コントローラに伝播されます。

ルートのタイプ

次の表は、Google Cloud が VPC ネットワーク内のルートを分類する方法をまとめたものです。

タイプと宛先 ネクストホップ 注
システム生成ルート
システム生成のデフォルト ルート
IPv4 の場合は 0.0.0.0/0
IPv6 の場合は ::/0		 default-internet-gateway VPC ネットワーク全体に適用されます。

削除または置換できます。
サブネット ルート
サブネット IP アドレス範囲ごとに自動的に作成されます。		 VPC ネットワーク
パケットを VM と内部ロードバランサに転送します。

サブネットのライフサイクルのイベント中に Google Cloud によって自動的に作成、更新、削除されます。

ローカル サブネット ルートは VPC ネットワーク全体に適用されます。
カスタムルート
静的ルート
さまざまな宛先をサポートします。		 パケットを静的ルートのネクストホップに転送します。 各静的ルートのネクストホップの詳細については、次の考慮事項をご覧ください。
動的ルート
サブネット ルートまたは静的ルートと競合しない宛先		 Cloud Router での BGP セッションのピア ルートは、VPC ネットワーク内の Cloud Router から学習したルートに基づいて自動的に追加、削除されます。

ルートは、VPC ネットワークの動的ルーティング モードに応じて VM に適用されます。
VPC ネットワーク ピアリング ルート
ピアリング サブネット ルート
VPC ネットワーク ピアリングを使用して接続される別の VPC ネットワーク内のサブネット IP アドレス範囲を表します。		 ピア VPC ネットワークのネクストホップ

VPC ネットワーク ピアリングには、サブネット ルートを交換するためのオプションが用意されています。

サブネットのライフサイクルのイベント中に Google Cloud によって自動的に作成、更新、削除されます。

インポートされたピアリング サブネット ルートは、VPC ネットワーク全体に適用されます。
ピアリングの静的ルートと動的ルート
VPC ネットワーク ピアリングを使用して接続される別の VPC ネットワーク内の静的ルートまたは動的ルート		 ピア VPC ネットワークのネクストホップ

VPC ネットワーク ピアリングには、静的ルートを交換するためのオプションが用意されています。

インポートされたピアリング静的ルートは、VPC ネットワーク全体に適用されます。

VPC ネットワーク ピアリングには、動的ルートを交換するためのオプションが用意されています。

インポートされたピアリング動的ルートは、ルートをエクスポートする VPC ネットワークの動的ルーティング モードに従って、VPC ネットワークの一部のリージョンまたはすべてのリージョンに適用されます。
Network Connectivity Center のルート
Network Connectivity Center のサブネット ルート
VPC スポーク（Network Connectivity Center ハブに接続されている別の VPC ネットワーク）内のサブネット IP アドレス範囲を表します。 		Network Connectivity Center ハブ

Network Connectivity Center のスポークの管理者は、サブネット ルートのエクスポートを除外できます。

サブネットのライフサイクルのイベント中に Google Cloud によって自動的に作成、更新、削除されます。

インポートされた Network Connectivity Center のサブネット ルートは、VPC ネットワーク全体に適用されます。
ポリシーベースのルート
ポリシーベースのルート
ポリシーベースのルートは、ソース IP アドレス、宛先 IP アドレス、プロトコル、またはそれらの組み合わせに基づいてパケットに適用できます。

ポリシーベースのルートは、他のルートよりも先に評価されます。ポリシーベースのルートは、ネットワーク内のすべての VM、ネットワーク タグで選択された特定の VM、または利用者が指定したCloud Interconnect VLAN アタッチメントを経由して VPC ネットワークに入るトラフィックに適用できます。

ポリシーベースのルートは、VPC ネットワーク ピアリングを通じて交換されることはありません。

システム生成のデフォルト ルート

VPC ネットワークを作成すると、システム生成の IPv4 デフォルト ルート（0.0.0.0/0）が含まれます。VPC ネットワークで外部 IPv6 アドレス範囲を持つデュアル スタック サブネットを作成すると、ルードがまだ存在しない場合は、システム生成の IPv6 デフォルト ルート（::/0）が対象のネットワークに追加されます。デフォルト ルートは次の目的で使用されます。

Google Cloud は、より具体的な宛先のルートがパケットに適用されない場合にのみ、デフォルト ルートを使用します。ルートを選択する際の宛先の指定方法とルートの優先度については、ルーティング順序をご覧ください。

ネットワークを完全にインターネットから隔離する場合や、デフォルト ルートをカスタムルートに置き換える場合は、デフォルト ルートを削除できます。

  • IPv4 のみ: インターネット トラフィックを別のネクストホップにルーティングする場合は、デフォルト ルートをカスタム静的ルートまたは動的ルートに置き換えることができます。たとえば、ネクストホップがプロキシ VM のカスタム静的ルートに置き換えることができます。

  • IPv4 と IPv6: デフォルト ルートを置き換えずに削除した場合、他のルートで対象とされていない IP 範囲に送信されたパケットは破棄されます。

サブネット ルート

サブネット ルートは、VPC ネットワーク内のリソース（VM、内部ロードバランサなど）のパスを定義します。

各サブネットには 1 つ以上のサブネット ルートがあり、その宛先はサブネットのプライマリ IPv4 範囲と一致します。サブネットにセカンダリ IP 範囲がある場合は、セカンダリ IP アドレス範囲ごとに対応するサブネット ルートがあります。サブネットに IPv6 範囲がある場合は、IPv6 アドレス範囲に対応するサブネット ルートがあります。サブネット IP 範囲の詳細については、サブネットをご覧ください。

サブネット ルートには常に最も狭い範囲の宛先が設定されます。優先度の高いルートであっても、別のルートをオーバーライドすることはできません。ルートを選択するときに、Google Cloud は優先度よりも宛先の限定性を考慮するためです。Google Cloud は、すべてのサブネット ルートの優先度として 0 を使用します。

静的ルートとの相互作用

ローカル サブネット ルートとインポートされたピアリング サブネット ルートは、カスタム静的ルートと次のように相互に影響し合います。

  • Google Cloud では、サブネット ルートやピアリング サブネット ルートと同等または狭い範囲の宛先を持つカスタム静的ルートを作成できません。例:

    • 10.70.1.0/24 の宛先にローカル サブネット ルートまたはピアリング サブネット ルートが存在する場合、10.70.1.0/24、10.70.1.0/25、10.70.1.128/25、または 10.70.1.0/24 内に収められる他の宛先への新しいカスタム静的ルートを作成することはできません。

    • 2001:0db8:0a0b:0c0d::/64 の宛先に対するローカル サブネット ルートまたはピアリング サブネット ルートが存在する場合、2001:0db8:0a0b:0c0d::/64 または 2001:0db8:0a0b:0c0d::/64 内に収まる他の宛先（2001:0db8:0a0b:0c0d::/96 など）に対する新しいカスタム静的ルートを作成することはできません。

  • 逆に、Google Cloud では、既存のカスタム静的ルートと完全に一致するか、既存のカスタム静的ルートよりも広い（既存のカスタム静的ルートが含まれる）宛先がある新しいサブネット ルートやピアリング サブネット ルートを作成することはできません。例:

    • VPC ネットワークに 10.70.1.128/25 の宛先に対するカスタム静的ルートがある場合、Google Cloud では、プライマリまたはセカンダリのサブネット IPv4 アドレス範囲が 10.70.1.128/25、10.70.1.0/24、または 10.70.1.128/25 のすべての IPv4 アドレスを含む他の範囲を持つサブネット ルートやピアリング サブネット ルートの作成が禁止されています。

    • VPC ネットワークに 2001:0db8:0a0b:0c0d::/96 の宛先に対するカスタム静的ルートがある場合、Google Cloud では、2001:0db8:0a0b:0c0d::/64 の IPv6 アドレス範囲、または 2001:0db8:0a0b:0c0d::/96 のすべての IPv6 アドレスを含む他の範囲を持つデュアル スタック サブネット ルートやピアリング サブネット ルートの作成が禁止されています。

動的ルートとの相互作用

ローカル サブネット ルートとインポートされたピアリング サブネット ルートは、Cloud Router と次のように相互に影響し合います。

  • Cloud Router が、既存のサブネットまたはピアリング サブネット ルートの宛先と完全に一致するプレフィックスを学習した場合、Google Cloud は競合するプレフィックスに対するカスタム動的ルートを作成しません。たとえば、宛先が 10.70.1.0/24 のサブネットまたはピアリング サブネット ルートが存在する場合、VPC ネットワーク内の Cloud Router が BGP によって 10.70.1.0/24 プレフィックスを受信すると、Google Cloud はそのサブネットまたはピアリング サブネット ルートを使用し、10.70.1.0/24 のカスタム動的ルートは作成しません。

    • 宛先が VPC ネットワーク内の Cloud Router によって学習されたプレフィックスと完全に一致するサブネットまたはピアリング サブネット ルートが作成されると、Google Cloud はサブネットやピアリング サブネット ルート用のスペースを確保するために、競合するプレフィックスのカスタム動的ルートを削除します。

  • Cloud Router が、既存のサブネットまたはピアリング サブネット ルートの宛先に収まるプレフィックスを学習した場合、Google Cloud は競合するプレフィックスのカスタム動的ルートを作成しません。たとえば、宛先が 10.70.1.0/24 のサブネットまたはピアリング サブネット ルートが存在する場合、VPC ネットワーク内の Cloud Router が BGP を通じて 10.70.1.0/25 および 10.70.1.128/25 プレフィックスを受信すると、Google Cloud はサブネットまたはピアリング サブネット ルートを使用し、10.70.1.0/25 および 10.70.1.128/25 のカスタム動的ルートは作成しません。

    • VPC ネットワークの Cloud Router によって学習されたプレフィックスを宛先に含むサブネットまたはピアリング サブネット ルートが作成されると、Google Cloud はサブネットやピアリング サブネット ルート用のスペースを確保するために、競合するプレフィックスのカスタム動的ルートを削除します。

サブネット ルートのライフサイクル

サブネット ルートが作成、更新、削除されるのは、サブネットやサブネット IP アドレス範囲を作成、変更、削除したときです。

  • サブネットを追加すると、Google Cloud はサブネットのプライマリ IP アドレス範囲に対応するサブネット ルートを作成します。

  • 自動モードの VPC ネットワークでは、自動生成されたサブネットのプライマリ IP 範囲にサブネット ルートが作成されます。これらのサブネットを削除できるのは、自動モードの VPC ネットワークをカスタムモードに変換する場合だけです。

  • サブネットを変更または削除しない限り、サブネット ルートは削除できません。

    • サブネットからセカンダリ範囲を削除すると、そのセカンダリ範囲のサブネット ルートが自動的に削除されます。

    • サブネットを削除すると、プライマリとセカンダリの両方の範囲のサブネット ルートがすべて自動的に削除されます。他の方法では、サブネットのプライマリ範囲のサブネット ルートを削除できません。

VPC ネットワーク内のサブネット ルートの数は、サブネット IP 範囲の最大数（プライマリとセカンダリ）によって制限されます。

動的ルート

Cloud Router は、受信した Border Gateway Protocol（BGP）メッセージ、適用可能な BGP ルートポリシー（プレビュー）、および構成した Cloud Router のカスタム学習ルートに基づいて、動的ルートの作成、更新、削除を VPC ネットワークに指示します。Cloud Router のコントロール プレーンは、VPC ネットワークの動的ルーティング モードに基づいてリージョンに動的ルートをインストールします。

  • VPC ネットワークがリージョン動的ルーティング モードを使用する場合、各リージョンの Cloud Router は、Cloud Router と同じリージョンにのみ動的ルートを作成します。

  • VPC ネットワークがグローバル動的ルーティング モードを使用する場合、各リージョンの Cloud Router は VPC ネットワークのすべてのリージョンに動的ルートを作成します。

動的ルートのネクストホップは、次のいずれかに設定できます。

動的ルートのネクストホップがアクセス不能になった場合、BGP セッションを管理する Cloud Router は、次のいずれかの条件が満たされた後に動的ルートを削除するよう VPC ネットワークに指示します。

Google Cloud は、動的ルートとの相互作用で説明されているように、動的ルートとローカル サブネット ルートおよびピアリング サブネット ルートの競合を解決します。

ピアリング サブネット ルート

ピアリング サブネット ルートは、VPC ネットワーク ピアリングで接続されている別の VPC ネットワーク内に存在するサブネット内のリソースへのパスを定義します。詳細については、サブネットのルート交換オプションをご覧ください。

ローカル サブネットとピアリング サブネット ルートを重複させることはできません。詳細については、サブネットとピアリング サブネット ルートの相互作用をご覧ください。

ピアリング グループあたりのサブネット ルートの数は、ピアリング グループの割り当てごとのネットワークあたりのサブネットワーク範囲で制御されます。

ピアリングの静的ルートと動的ルート

VPC ネットワーク ピアリングを使用して 2 つの VPC ネットワークを接続すると、一方のネットワークから静的ルートと動的ルートをエクスポートし、もう一方のネットワークにインポートできます。詳しくは以下をご覧ください。

ピアリング グループあたりの静的ルート数と、ピアリング グループごとのリージョンあたりの動的ルート数は、ネットワークごとの静的ルートと動的ルートの割り当てによって制限されます。

適用範囲と順序

該当するルート

各インスタンスには適用可能なルートのセットがあります。これは、VPC ネットワーク内のすべてのルートのサブセットになります。適用可能なルートとは、パケットがインスタンスから送信されたときに使用される可能性のある下り（外向き）パスのことです。

  • プロキシ ロードバランサ、ヘルスチェック システム、他の Google サービスにルーティングされる場合は、特別なルーティング パスが適用されます。詳細については、特別なルーティング パスをご覧ください。これらのルートは、ルートテーブルには表示されません。

  • ポリシーベースのルートは、Compute Engine VM インスタンスから送信されたパケットや Cloud Interconnect VLAN アタッチメントで受信されたパケットに適用できます。ポリシーベースのルートは、パケットがポリシーベースのルートの条件と一致する場合にのみ適用されます。

  • ローカルとピアリングのサブネット ルートはすべてのインスタンスに適用されます。ポリシーベースのルートを除き、ローカル サブネット ルートまたはピアリング サブネット ルートの宛先と一致する宛先、または宛先内に収まるルートタイプを持つルートタイプは他にありません。サブネット、静的ルート、動的ルート間の競合解決の詳細については、サブネットと静的ルートの相互作用とサブネットと動的ルートの相互作用をご覧ください。

  • カスタム静的ルートはすべてのインスタンスまたは特定のインスタンスに適用できます。タグ属性を持つ静的ルートは同じネットワーク タグを持つインスタンスに適用されます。ルートにネットワーク タグがない場合、そのルートはネットワーク内のすべてのインスタンスに適用されます。

  • 動的ルートは、VPC ネットワークの動的ルーティング モードに基づいてインスタンスに適用されます。

特別なルーティング パス

VPC ネットワークには特定のサービス用の特別なルートがあります。こうした特別なルーティング パスは、VPC ネットワーク ルートテーブルには表示されません。特別なルーティング パスを削除することはできません。ただし、VPC ファイアウォール ルールまたはファイアウォール ポリシーを使用することで、パケットを許可または拒否できます。

外部パススルー ネットワーク ロードバランサと外部プロトコル転送のためのパス

外部パススルー ネットワーク ロードバランサと外部プロトコル転送では、Maglev システムを使用して、インターネット上のクライアントから VPC ネットワーク内のバックエンド VM とターゲット インスタンスにパケットを転送します。これらの Maglev システムは、外部転送ルールの宛先と一致する宛先のパケットを転送します。

外部パススルー ネットワーク ロードバランサまたは外部プロトコル転送の各転送ルールは、バックエンド VM やターゲット インスタンスが VPC ネットワークの外部の宛先にパケットを送信するためのルーティング パスも提供します。

  • バックエンド VM またはターゲット インスタンスから送信されるパケットは、アウトバウンド レスポンス パケット（クライアントに送り返される）または新しい接続を開始するアウトバウンド パケットのいずれかです。
  • パケットの送信元は、転送ルールの IP アドレスと一致しなければなりません。パケットのプロトコルと送信元ポートが、転送ルールのプロトコルとポートの仕様に一致する必要はありません。
  • 転送ルールのルーティング パスは、デフォルト ルートやデフォルト インターネット ゲートウェイのネクストホップの使用に依存しません。
  • バックエンド VM とターゲット インスタンスで IP 転送を有効にする必要はありません。

Google Front End とバックエンド間のパス

外部アプリケーション ロードバランサと外部プロキシ ネットワーク ロードバランサは、Google Front End（GFE）を使用します。2 番目のレイヤの GFE は、バックエンド VM への TCP 接続を開き、以下の送信元からパケットを送信します。

  • 35.191.0.0/16
  • 130.211.0.0/22

Google Cloud は、Google のネットワーク内のルートを使用して、これらの送信元の範囲から VPC ネットワーク内のバックエンド VM にパケットを配信します。各 VPC ネットワークには、VM が 35.191.0.0/16 と 130.211.0.0/22 にレスポンス パケットを送信できるようにするルーティング パスが含まれています。

ヘルスチェックのパス

すべてのロードバランサに対するヘルスチェックとマネージド インスタンス グループの自動修復用のヘルスチェックでは、ヘルスチェック プローブの IP アドレス範囲からバックエンド VM にパケットが送信されます。

Google Cloud は、Google のネットワーク内のルートを使用して、ヘルスチェック プローブ システムから VPC ネットワーク内の VM にパケットを配信します。各 VPC ネットワークには、VM がヘルスチェック プローブ システムにレスポンス パケットを送信できるルーティング パスが含まれています。

Identity-Aware Proxy（IAP）のパス

IAP を使用した TCP 転送では、35.235.240.0/20 を内部専用範囲として使用し、ネクストホップはすべて Google のネットワーク内にあります。Google は、インターネット上に 35.235.240.0/20 へのルートを公開していません。

IAP TCP 転送を使用する場合、Google のネットワーク内のルートによって、35.235.240.0/20 から VPC ネットワーク内の VM にパケットが配信されます。各 VPC ネットワークには、VM が 35.235.240.0/20 にレスポンス パケットを送信できるルーティング パスが含まれています。

Cloud DNS と Service Directory のパス

以下の Cloud DNS と Service Directory の機能では、35.199.192.0/19 を内部専用の範囲として使用し、ネクストホップは Google のネットワーク内にあります。Google は、インターネット上に 35.199.192.0/19 へのルートを公開していません。

これらの Cloud DNS や Service Directory の機能を使用する場合、Google のネットワーク内のルートによって 35.199.192.0/19 から VPC ネットワーク内の VM にパケットが配信されます。各 VPC ネットワークには、VM が 35.199.192.0/19 にレスポンス パケットを送信できるルーティング パスが含まれています。

サーバーレス VPC アクセスのパス

サーバーレス VPC アクセスでは、35.199.224.0/19 を内部専用の範囲として使用し、ネクストホップはすべて Google のネットワーク内にあります。Google は、インターネット上に 35.199.224.0/19 へのルートを公開していません。

Google ネットワーク内のルートによって、35.199.224.0/19 からサーバーレス VPC アクセス コネクタ インスタンスにパケットが配信されます。各 VPC ネットワークには、コネクタ インスタンスが 35.199.224.0/19 にレスポンス パケットを送信できるルーティング パスが含まれています。

グローバル Google API の Private Service Connect エンドポイントのパス

グローバル Google API 用の Private Service Connect エンドポイントを作成すると、Google Cloud によって、エンドポイントのルートが VPC ネットワークに追加されます。ルートの宛先は、エンドポイントのグローバル内部 IP アドレスです。

ルーティング順序

以下のプロセスは、VPC ネットワーク ルート選択の動作をモデル化したもので、前のセクションで説明した一連の適用可能なルートから開始します。

  1. 特別なルーティング パス: Google Cloud の特別なルーティング パスには、VPC ネットワークのルートテーブルに表示されないものがあります。詳細については、特別なルーティング パスをご覧ください。

    特別なルーティング パスが適用される場合、ルート選択モデルには特別なパスのみが含まれます。他のルートはすべて無視され、評価はこのステップで停止します。

  2. ポリシーベースのルート: ポリシーベースのルートは、特別なルーティング パスの後で、他のタイプのルートより前に評価されます。ポリシーベースのルートが VPC ネットワークに存在しない場合、Google Cloud はこの手順をスキップし、「最も狭い範囲の宛先」のステップに進みます。

  • Google Cloud は、ポリシーベースのルートを優先度だけで評価します。Google Cloud は、各ポリシーベースのルートについて、優先度の最も高いポリシーベースのルートから順にパケットの送信元と宛先を評価します。パケットの特性がポリシーベースのルートと一致しない場合、Google Cloud はポリシーベースのルートを無視し、ソートされたリストにある次のポリシーベースのルートを評価します。次に評価するポリシーベースのルートは、無視されたポリシーベースのルートと同じ優先度の場合も、それよりも低い優先度の場合もあります。

    • ルート選択モデル内のすべてのポリシーベースのルートを評価した後、パケットの特性がどのポリシーベースのルートにも一致しない場合、Google Cloud はすべてのポリシーベースのルートを無視し、「最も具体的な宛先」のステップに進みます。

    • パケットの特性が優先度の最も高いポリシーベースのルートと一致する場合、Google Cloud はまず、優先度の低いポリシーベースのルートをすべて無視します。リストにポリシーベースのルートが 2 つ以上残っている場合、Google Cloud は、優先度が等しい残りのポリシーベースのルートをそれぞれ評価します。パケットの特性が一致しない残りのポリシーベースのルートはすべて無視します。このステップの後、ルート選択モデルには、ポリシーベースのルートが 1 つ以上含まれる場合があります。

    • ルート選択モデルに、最も優先度の高いポリシーベースのルートが 2 つ以上含まれている場合、Google Cloud は内部アルゴリズムを使用して 1 つのポリシーベースのルートを選択します。選択されたポリシーベースのルートは、パケットの送信元または宛先に対して最も詳細に一致しない可能性があります。このあいまいさを避けるため、一意の優先度を持つポリシーベースのルートを作成することをおすすめします。

    • ルート選択モデルに、他のポリシーベースのルートをスキップするように構成された、最も優先度の高いポリシーベースのルートが 1 つだけ含まれている場合、Google Cloud は、「最も具体的な宛先」のステップでポリシーベースではないルートを評価し、ポリシーベースのルートはすべて無視します。

    • ルート選択モデルに、他のポリシーベースのルートをスキップするように構成されていない、最も優先度の高いポリシーベースのルートが 1 つだけ含まれている場合、Google Cloud はパケットをネクストホップの内部パススルー ネットワーク ロードバランサに配信し、ポリシーベースではないルートをすべて無視します。

  1. 最も具体的な宛先: Google Cloud は、適用可能なルートの中から、パケットの宛先 IP アドレスを含む最も具体的な宛先のルートを特定します。Google Cloud は、宛先が具体的でない他のルートをすべて無視します。たとえば、10.240.1.0/24 は 10.240.0.0/16 よりも限定された宛先です。どのようなタイプのルートも最も具体的な宛先になり得ますが、定義上は、サブネット ルート、ピアリング サブネット ルート、特別なルーティング パスが最も具体的な宛先です。

    このステップを終えると、ルート選択モデルに特別なルーティング パスやポリシーベースのルートは含まれません。最も狭い範囲の宛先を持つルートのみが含まれます。

  2. 単一 VPC ネットワーク内のネクストホップ: このステップは、ルーティング動作をモデル化する VPC ネットワークが、VPC ネットワーク ピアリングを使用して 1 つ以上の VPC ネットワークに接続している場合にのみ適用されます。VPC ネットワーク ピアリングでは、同じ宛先を持つカスタムルートがピアリング グループ内の複数のネットワークに存在する可能性があります。このステップでモデル化する場合、Google Cloud によって選択されるすべてのネクストホップが、同じ 1 つの VPC ネットワーク内に存在している必要があります。

    • ルートモデル内の 1 つ以上のルートで、モデル化対象の VPC ネットワーク内にネクストホップがある場合、ピア ネットワークにネクストホップがあるルートはすべて無視されます。この場合、Google Cloud は、1 つ以上のピア VPC ネットワークに同じ宛先に向かうネクストホップが存在する場合でも、ローカル VPC ネットワークのネクストホップのみを使用します。

    • モデル化対象の VPC ネットワークにネクストホップがあるルートがルートモデルになく、すべてのネクストホップが複数のピア ネットワークに存在する場合、Google Cloud は内部アルゴリズムを使用して、最も具体的な宛先に向かうネクストホップがあるピア ネットワークを 1 つ選択します。ルートの優先度は、この時点では考慮されません。また、VPC ネットワークが新しい VPC ネットワークとピアリングする場合や、既存のピア VPC ネットワークから切断された場合、ネクストホップ用に選択された VPC ネットワークは変わる可能性があります。

    このステップが終わると、ルート選択モデルには、最も具体的な宛先を持つルートのみが含まれ、これらのルートのネクストホップはすべて同じ 1 つの VPC ネットワーク内にあります。

  3. ネクストホップが動作していないカスタム静的ルートを無視する: このステップでは、動作していないとみなされるネクストホップを Google Cloud が無視する 2 つの状況をモデル化します。このステップは、カスタム静的ルートにのみ適用されます。カスタム動的ルートは BGP アドバタイズを使用して自動的に追加、削除されます。

    • ネクストホップの VM が停止または削除された場合、Google Cloud はすべてのネクストホップの VM インスタンス（next-hop-instance または next-hop-address）を無視します。詳細については、ネクストホップ インスタンスに関する考慮事項の「インスタンスが停止または削除されたときの動作」をご覧ください。ルートモデルに、ネクストホップ VM が停止または削除された静的ルートが含まれている場合は、そのルートをモデルから削除してください。

    • トンネルにフェーズ 1（IKE）セキュリティ アソシエーション（SA）がない場合、Google Cloud は、ネクストホップの Classic VPN トンネルを使用するカスタム静的ルートをすべて無視します。詳細については、Classic VPN ドキュメントのルートの順序をご覧ください。ネクストホップが Classic VPN トンネルである静的ルートがルートモデルに含まれている場合は、IKE SA が確立されていないルートをモデルから削除してください。

  4. 優先度の低いルートを無視する: このステップでは、Google Cloud が、最も高い優先度のルート以外をすべて破棄する仕組みをモデル化します。

    このステップを終えると、ルート選択モデルは空か、1 つ以上のルートを含みます。モデルにルートが含まれている場合、そのすべてのルートが次のすべての特性を持ちます。

    • 最も限定された範囲の同一の宛先
    • すべて 1 つの VPC ネットワークにあるネクストホップ（ローカル VPC ネットワークまたは単一のピア VPC ネットワーク）
    • 停止していないことがわかっているネクストホップ
    • 最も高い同じ優先度

  5. 最も望ましい選好カテゴリのみを選択する: 異なる種類のネクストホップでの ECMP ルーティングを回避します。この動作は、次の表に示す選好カテゴリ体系を考慮に入れることでモデル化できます。このステップでは、同じルートタイプか、ルートタイプとネクストホップ タイプの組み合わせのルートのみを含むようにルートモデルを絞り込みます。

    選好カテゴリ カテゴリとネクストホップの組み合わせ
    第 1 候補（最も望ましい） 実行中のネクストホップ インスタンス（next-hop-instance または next-hop-address）か、IKE SA 確立済みのネクストホップの Classic VPN トンネルを含むカスタム静的ルート。
    第 2 候補 Cloud Router の BGP セッションから学習したカスタム動的ルート。
    第 3 候補 内部パススルー ネットワーク ロードバランサのネクストホップを持つ単一のカスタム静的ルート。
    Google Cloud は、内部アルゴリズムを使用して単一のネクストホップ内部パススルー ネットワーク ロードバランサを選択し、優先度が同じ他の内部パススルー ネットワーク ロードバランサ ネクストホップを無視します。詳細については、内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項の「同じ宛先と複数のネクストホップの内部パススルー ネットワーク ロードバランサ」をご覧ください。
    第 4 候補 default-internet-gateway ネクストホップを使用するカスタム静的ルート。

    このステップを終えると、ルートモデルは、ルートなし、1 つのルート、または複数のルートのいずれかになります。

  6. パケットを送信またはドロップする: ここで行われることは、ルートモデルに残っているルートの数によって変わります。

    • ルートモデルが空の場合、パケットは ICMP の宛先到達不能エラーかネットワーク到達不能エラーで破棄されます。Google Cloud は、ネクストホップが動作している可能性がある、具体性が低いルートにフォールバックすることはありません。

    • ルートモデルに単一ルートが含まれている場合、Google Cloud はネクストホップにパケットを送信します。VM のネクストホップの場合、Google Cloud は VM のネクストホップがパケットを処理できるかどうかを検証しません。詳細については、インスタンスと内部パススルー ネットワーク ロードバランサのネクストホップに共通する考慮事項をご覧ください。単一ルートがサブネット ルートまたはピアリング サブネット ルートであり、パケットの宛先 IP アドレスに Google Cloud リソースがない場合、パケットは破棄されます。

    • ルートモデルに 2 つ以上のルートが含まれている場合、それらのルートは最も具体的な同じ宛先を共有します。これらのルートは単一の VPC ネットワーク内にあり、ネクストホップがダウンしているかどうかわかりません。また、優先度が最も高く、1 つのルートタイプとネクストホップの組み合わせ（選好カテゴリ）に属します。Google Cloud は、ハッシュ アルゴリズムを使用して等価コスト マルチパス（ECMP）を実装しているネクストホップに対してパケットを配信します。ハッシュ計算は、各パケットの送信時にネクストホップの現在の数に基づいて行われます。パケットにポート情報が含まれている場合、Google Cloud は 5 タプルハッシュを使用します。それ以外の場合は、3 タプルハッシュを使用します。ハッシュ パケットが同じでも、後続のパケットの送信でルートモデルが変更されると、Google Cloud はそれらのパケットを別のネクストホップに転送する場合があります。

静的ルート

静的ルートは次のいずれかの方法で作成できます。

VPC ネットワーク ピアリング ドキュメントのカスタム静的ルートの交換オプションで説明されているように、ピアリングされた VPC ネットワークと静的ルートを交換できます。

ルート パラメータ

静的ルートは、次の属性をサポートしています。

  • 名前と説明これらのフィールドでルートが識別されます。名前は必須ですが、説明は省略可能です。ルート名はプロジェクト内で一意にする必要があります。

  • ネットワーク。各ルートは、1 つの VPC ネットワークだけに関連付けられていなければなりません。

  • ネクストホップ。ネクストホップは、パケットの送信先のネットワーク リソースを識別します。すべてのネクストホップ タイプは IPv4 の宛先をサポートし、一部のネクストホップ タイプは IPv6 の宛先をサポートします。詳細については、ネクストホップと機能をご覧ください。

  • 宛先の範囲。宛先の範囲は、単一の IPv4 または IPv6 の CIDR 表記です。

    静的ルートの宛先は、静的ルートとの相互作用とサブネットと静的ルートの相互作用に記載されたルールに従う必要があります。IPv4 静的ルートの最も広い宛先は「0.0.0.0/0」です。IPv6 静的ルートの最も広い宛先は「::/0」です。

  • 優先度。数字が小さいほど優先度が高くなります。最も高い優先度は 0 で、最も低い優先度は 65,535 です。

  • ネットワーク タグ。静的ルートは、ネットワーク タグによって識別される VPC ネットワーク内の一部の VM インスタンスにのみ適用できます。ネットワーク タグを指定しない場合、Google Cloud は静的ルートをネットワーク内のすべてのインスタンスに適用します。VPC ネットワーク ピアリングを使用する場合、タグを持つ静的ルートは交換されません。

ネクストホップと機能

次の表は、ネクストホップのタイプ別の静的ルート機能のサポートをまとめたものです。

ネクストホップのタイプ IPv4 IPv6 ECMP1
ネクストホップ ゲートウェイ（next-hop-gateway）
デフォルトのインターネット ゲートウェイを指定して、外部 IP アドレスのパスを定義します。
名前とゾーンによるネクストホップ インスタンス（next-hop-instance）
名前とゾーンによって識別され、ルートと同じプロジェクト内にあるネクストホップ VM にパケットを送信します。詳しくは、ネクストホップ インスタンスに関する考慮事項をご覧ください。
アドレスによるネクストホップ インスタンス（next-hop-address）
そのネットワーク インターフェースのプライマリ IPv4 アドレスによって識別されるネクストホップ VM にパケットを送信します。詳しくは、ネクストホップ インスタンスに関する考慮事項をご覧ください。
転送ルール名とリージョンによるネクストホップの内部パススルー ネットワーク ロードバランサ（next-hop-ilb）
転送ルールの名前とリージョンによって識別される内部パススルー ネットワーク ロードバランサのバックエンドにパケットを送信します。詳細については、内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項をご覧ください。
アドレスによるネクストホップ内部パススルー ネットワーク ロードバランサ（next-hop-ilb）
ロードバランサの転送ルールの IP アドレスによって識別される内部パススルー ネットワーク ロードバランサのバックエンドにパケットを送信します。詳細については、内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項をご覧ください。
ネクストホップの Classic VPN トンネル（next-hop-vpn-tunnel）
ポリシーベース ルーティングまたはルートベースの VPN を使用して、ネクストホップの Classic VPN トンネルにパケットを送信します。詳しくは、Classic VPN トンネルのネクストホップに関する考慮事項をご覧ください。
1 等価コスト マルチパス（ECMP）とは、2 つ以上の静的ルートで同じ宛先範囲と優先度を共有できることを意味します。同じ宛先、同じ優先度、デフォルト インターネット ゲートウェイのネクストホップを持つ VPC ネットワーク内に複数の静的ルートを作成できますが、その宛先と優先度のデフォルト インターネット ゲートウェイのネクストホップを使用する単一の静的ルートを持つことと効果は同じです。

ネクストホップのプロジェクトとネットワーク

静的ルートのネクストホップは、VPC ネットワークとプロジェクトの両方に関連付けられます。

  • ネットワーク: 下の表に記載されている場合を除き、ネクストホップの VPC ネットワークはルートの VPC ネットワークと一致する必要があります。

  • プロジェクト: 以下の表に示す場合を除き、ネクストホップは、ネクストホップの VPC ネットワークを含むプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）に配置する必要があります。一部のネクストホップは、共有 VPC サービス プロジェクトに配置できます。

ネクストホップのタイプ ピアリングされる VPC ネットワークに配置できる 共有 VPC サービス プロジェクトに配置できる
ネクストホップのゲートウェイ（next-hop-gateway）
名前によるネクストホップ インスタンス（next-hop-instance）
アドレスによるネクストホップ インスタンス（next-hop-address）
転送ルールの名前とリージョンによるネクストホップの内部パススルー ネットワーク ロードバランサ（next-hop-ilb）
アドレスによるネクストホップ内部パススルー ネットワーク ロードバランサ（next-hop-ilb）
ネクストホップの Classic VPN トンネル（next-hop-vpn-tunnel）

インスタンスと内部パススルー ネットワーク ロードバランサのネクストホップに共通する考慮事項

インスタンス ベースのルーティングは、ネクストホップが VM インスタンスである静的ルートを参照します（next-hop-instance または next-hop-address）。

ネクストホップとしての内部パススルー ネットワーク ロードバランサとは、ネクストホップが内部パススルー ネットワーク ロードバランサ（next-hop-ilb）である静的ルートを指します。

インスタンス ベースのルーティングや内部パススルー ネットワーク ロードバランサをネクストホップとして構成する場合は、次のガイドラインを考慮してください。

  • 任意の送信元 IP アドレスからパケットを転送するように、バックエンド VM またはネクストホップ インスタンスを構成する必要があります。転送を構成するには、VM の作成時に VM ごとに IP 転送を有効にします（can-ip-forward）。マネージド インスタンス グループの一部として自動的に作成される VM では、インスタンス グループで使用されるインスタンス テンプレートで IP 転送を有効にします。パケットのルーティングに必要なオペレーティング システムの構成に加え、この構成の変更も行う必要があります。

  • バックエンド VM またはネクストホップ インスタンスで実行されているソフトウェアを適切に構成する必要があります。たとえば、ルーターやファイアウォールとして機能するサードパーティ アプライアンス VM は、メーカーの指示に従って構成する必要があります。

  • バックエンド VM またはネクストホップ インスタンスに適切なファイアウォール ルールを設定する必要があります。ルーティングするパケットに適用するファイアウォール ルールを構成する必要があります。次の点にご注意ください。

    • ルーティング機能を実行するインスタンスに適用される上り（内向き）ファイアウォール ルールには、ルーティングされるパケットソースの IP アドレスを含める必要があります。暗黙の上り（内向き）拒否ルールはすべての受信パケットをブロックするため、少なくともカスタム上り（内向き）許可ファイアウォール ルールを作成する必要があります。
    • ルーティング機能を実行するインスタンスに適用される下り（外向き）ファイアウォール ルールには、ルーティングされるパケットの宛先の IP アドレスを含める必要があります。特定の下り（外向き）拒否ルールを作成してオーバーライドしない限り、暗黙の下り（外向き）許可ルールはこのトラフィックを許可します。
    • ファイアウォール ルールの作成時に、バックエンド VM またはネクストホップ インスタンスがネットワーク アドレス変換（NAT）を実行しているかどうかを確認してください。

    詳細については、暗黙のファイアウォール ルールをご覧ください。

  • バックエンド VM またはネクストホップ インスタンスによって送信されたパケットの送信元リージョンは、バックエンド VM またはネクストホップ インスタンスが配置されているリージョンです。たとえば、バックエンド VM または us-west1 のネクストホップ インスタンスによって処理されたパケットは、バックエンド VM またはネクストホップ インスタンスが us-west1 とは異なるリージョンのリソースからパケットを受信したとしても、us-west1 でのみアクセス可能な宛先に送信できます。パケットを送信する VM と同じリージョンでのみアクセスできるリソースの例を次に示します。

    • グローバル アクセスがオフになっている内部パススルー ネットワーク ロードバランサ、内部アプリケーション ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサ
    • Cloud VPN トンネル、Cloud Interconnect VLAN アタッチメント、Network Connectivity ルーター アプライアンス VM（VPC ネットワークがリージョン動的ルーティングを使用する場合）

ネクストホップ インスタンスに関する考慮事項

  • インスタンス名とゾーンによるネクストホップ（next-hop-instance）: インスタンス名とゾーンで指定されたネクストホップ インスタンスを持つ静的ルートを作成する場合、Google Cloud では、指定されたゾーンにその名前のインスタンスが存在し、以下の条件を満たしている必要があります。

    • インスタンスは、ルートと同じプロジェクトに配置されている。
    • インスタンスのネットワーク インターフェース（NIC）がルートの VPC ネットワーク（ピアリングされた VPC ネットワークではない）にある。

    インスタンス名とゾーンでネクストホップを指定する静的ルートが存在する限り、以下が適用されます。

    • Google Cloud は、次のいずれかの場合に、ネクストホップのプログラミングを自動的に更新します。

    • ネクストホップ インスタンスのプライマリ内部 IPv4 アドレスが変更された。

    • ネクストホップ インスタンスを置き換え、置き換え後のインスタンスは名前が同じで、同じゾーンとプロジェクトに存在し、ルートの VPC ネットワーク内にネットワーク インターフェースがある。

    • 次の場合、Google Cloud はネクストホップのプログラミングを更新しません。

    • インスタンスが削除されている場合

    • インスタンスの NIC に割り振られている IPv6 アドレス範囲が変更されている

    • インスタンスの IPv4 または IPv6 のアドレスが割り当てられていない場合

  • ネクストホップ インスタンスの内部 IP アドレス（next-hop-address）: 内部 IPv4 アドレスで指定されたネクストホップ インスタンスを持つ静的ルートを作成すると、Google Cloud は、ネクストホップ VM の IPv4 アドレスが、ルートの VPC ネットワークにあるサブネットのサブネット IPv4 範囲内に収まることを確認します。ただし、Google Cloud は、ネクストホップ アドレスが（ピアリングされた VPC ネットワークではなく）ルートの VPC ネットワーク内の VM NIC に割り振られているプライマリ内部 IPv4 アドレスである場合にのみ、ルートをプログラムします。

    ネクストホップの IPv4 アドレスが別の VM に移動すると、代替 VM が同じ要件を満たしている場合、Google Cloud はネクストホップのプログラミングを自動的に更新します。

  • 共有 VPC サービス プロジェクトのネクストホップ インスタンス: IP アドレスでネクストホップ VM を指定する場合、VM は、ルートと同じプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）か、共有 VPC サービス プロジェクトに配置できます。インスタンス名とゾーンでネクストホップ VM を指定する場合、ネクストホップ VM は、ルートおよび VPC ネットワークと同じプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）に配置する必要があります。

  • リージョン間のコストとレイテンシ: VM をネクストホップとして使用する場合、ネクストホップはリージョンのゾーンにあります。ネクストホップを使用するルートは、同じ VPC ネットワーク内のすべてのインスタンス、または一致するネットワーク タグを持つインスタンスで使用できます。Google Cloud は、インスタンスをネクストホップとして使用するルートのリージョン距離を考慮しないため、異なるリージョンのネクストホップ VM にトラフィックを送信するルートを作成できます。あるリージョンから別のリージョンにパケットを送信すると、アウトバウンド データ転送の費用が増加し、ネットワーク レイテンシが発生します。

  • ヘルスチェックや構成の検証がない: Google Cloud では、ネクストホップ インスタンスがインスタンスと内部パススルー ネットワーク ロードバランサのネクストホップに共通する考慮事項セクションに説明されているすべての要件を満たしているかどうかチェックされません。インスタンスのゲスト オペレーティング システムを構成することによって VM のネットワーク インターフェースを無効にしても、Google Cloud がネクストホップ インスタンスを無視するようにはなりません。

  • 2 つの VPC ネットワークを接続する際に対称ハッシュがない: Google Cloud では、次の条件をすべて満たす構成で、複数のネットワーク インターフェースを持つ 2 つ以上のネクストホップ VM を使用する場合、対称ハッシュを提供しません。

    • VM が、1 つの VPC ネットワークに 1 つのネットワーク インターフェースを持ち、もう 1 つの VPC ネットワークに別のインターフェースを備えている。
    • 各 VPC ネットワークには、優先度と宛先が同じ 2 つ以上のカスタム静的ルートのセットがあり、セット内の各ルートは一意のネクストホップ VM を参照している。

    複数のインターフェースがある 2 つ以上の VM を使用して VPC ネットワークを接続し、特定の接続に対して同じ VM が双方向でパケットを処理する必要がある場合は、ネクストホップの内部パススルー ネットワーク ロードバランサによってのみサポートされる対称ハッシュが必要です。対称ハッシュの詳細については、ネクストホップとしての内部パススルー ネットワーク ロードバランサのドキュメントの対称ハッシュをご覧ください。

  • インスタンスが停止または削除されたときの動作: Google Cloud は静的ルートのネクストホップ VM（名前とゾーン、または内部アドレスで指定）を停止または削除することを妨げません。ネクストホップ VM が動作していない場合、宛先へのルーティングは、まったく同じ宛先への他のルートが存在するかどうか、およびそのルートに動作しているネクストホップがあるかどうかによって変わります。次の例で、この動作について説明します。

    • 優先度が最も高いルートのネクストホップが動作していない以下の状況では、宛先が 192.168.168.0/24 に入るパケットは、route-vm-b のネクストホップに送信されます。このルーティングは、Google Cloud がルーティング順序の「優先度の低いルートを無視する」ステップを考慮する前に、動作していないネクストホップを無視するために起こります。
    • route-vm-a、宛先 192.168.168.0/24、優先度 10、ネクストホップ VM が停止している
    • route-vm-b、宛先 192.168.168.0/24、優先度 20、ネクストホップ VM が実行されている

    • route-vm-c、宛先 192.168.168.0/24、優先度 30、ネクストホップ VM が実行されている

    • 次の例では、宛先が 192.168.168.0/24 に入るパケットがドロップされます。この例では、広範な 192.168.0.0/16 のルートのネクストホップ VM が動作していても、192.168.168.0/24 ルートのすべてのネクストホップ VM は動作していません。Google Cloud では、ルーティング順序の「ネクストホップが実行されていないカスタム静的ルートを無視する」ステップの前にある「最も具体的な宛先」のステップで宛先範囲が広い（サブネット マスク長が短い）ルートが無視されるため、パケットがドロップされます。

    • route-vm-x、宛先 192.168.168.0/24、優先度 10、ネクストホップ VM が停止している

    • route-vm-y、宛先 192.168.168.0/24、優先度 20、ネクストホップ VM が停止している

    • route-vm-z、宛先 192.168.0.0/16、優先度 0、ネクストホップ VM が実行されている

内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項

  • サポートされている転送ルールGoogle Cloud では、ネクストホップの内部パススルー ネットワーク ロードバランサの転送ルールのみがサポートされています。Google Cloud では、他のロードバランサ、プロトコル転送で使用される、または Private Service Connect エンドポイントとして使用されるネクストホップ転送ルールはサポートされていません。

  • 指定方法および転送ルール ネットワークとプロジェクトネクストホップ転送ルールは、次の 3 つの方法のいずれかを使用して指定できます。使用する指定方法によって、転送ルールのネットワークをルートのネットワークと一致させる必要があるかどうかと、転送ルールを配置できるプロジェクトが決まります。

    • 転送ルール名（--next-hop-ilb）とリージョン（--next-hop-ilb-region）を使用: 名前とリージョンでネクストホップ転送ルールを指定する場合、転送ルールのネットワークはルートの VPC ネットワークと一致する必要があります。転送ルールは、転送ルールのネットワークを含む同じプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）に配置する必要があります。

    • 転送ルールのリソースリンクを使用: 転送ルールのリソースリンクは、/projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME の形式を使用します。ここで、PROJECT_IDは転送ルールを含むプロジェクトのプロジェクト ID、REGION は転送ルールのリージョン、FORWARDING_RULE_NAME は転送ルールの名前です。このリソースリンクでネクストホップ転送ルールを指定する場合、転送ルールのネットワークはルートの VPC ネットワークと一致する必要があります。転送ルールは、転送ルールのネットワークを含むプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）、または共有 VPC サービス プロジェクトに配置できます。

    • 転送ルールの IPv4 アドレスを使用: この IPv4 アドレスでネクストホップ転送ルールを指定する場合、転送ルールのネットワークはルートの VPC ネットワーク、またはピアリングした VPC ネットワークになります。転送ルールは、転送ルールのネットワークを含むプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）、または共有 VPC サービス プロジェクトに配置できます。

  • グローバル アクセスの影響。内部パススルー ネットワーク ロードバランサのネクストホップを使用するカスタム静的ルートは、すべてのリージョンでプログラムされます。ネクストホップを使用できるかどうかは、ロードバランサのグローバル アクセスの設定によって異なります。グローバル アクセスを有効にすると、VPC ネットワークのすべてのリージョンでロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、ロードバランサと同じリージョンでのみロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、内部パススルー ネットワーク ロードバランサのネクストホップを使用して別のリージョンからルートに送信されるパケットは、破棄されます。

  • すべてのバックエンドが異常な場合。内部パススルー ネットワーク ロードバランサのすべてのバックエンドでヘルスチェックに失敗した場合でも、そのロードバランサのネクストホップを使用したルートは引き続き有効です。ルートで処理されるパケットは、トラフィック分配に従って、ネクストホップ ロードバランサのバックエンドの 1 つに送信されます。

  • 共通の内部 IP アドレス（--purpose=SHARED_LOADBALANCER_VIP）を使用する転送ルールがサポートされない。ネクストホップの内部パススルー ネットワーク ロードバランサと、共通の IP アドレスを持つ内部パススルー ネットワーク ロードバランサの転送ルールは相互に排他的な機能です。ネクストホップの内部パススルー ネットワーク ロードバランサでは、1 つのバックエンド サービス（1 つのロードバランサ）のみを明確に参照するように、ロードバランサの転送ルールに固有の IP アドレスを使用する必要があります。共通の内部 IP アドレスを使用する転送ルールで、異なるバックエンド サービス（異なる内部パススルー ネットワーク ロードバランサ）を参照することは可能です。

  • 同じ宛先と優先度の複数のルートがあり、ネクストホップの内部パススルー ネットワーク ロードバランサが異なる。Google Cloud は、ECMP を使用して 2 つ以上のネクストホップ内部パススルー ネットワーク ロードバランサ間でトラフィックを分散することはありません。代わりに、Google Cloud は決定的な内部アルゴリズムを使用して、ネクストホップ内部パススルー ネットワーク ロードバランサを 1 つだけ選択します。このあいまいさを回避するには、ルートごとに一意のネットワーク タグを使用します。

    異なる内部パススルー ネットワーク ロードバランサのネクストホップを使用する静的ルートに同じ優先度と宛先が設定されている場合、Google Cloud は単一のネクストホップを選択します。

  • 同じ宛先、優先度、ネクストホップの内部パススルー ネットワーク ロードバランサを持つ複数のルート。ネットワーク タグがない場合、Google Cloud では、宛先、優先度、内部パススルー ネットワーク ロードバランサのネクストホップの組み合わせが同じ静的ルートを複数作成することはできません。ネットワーク タグを使用すると、宛先、優先度、内部パススルー ネットワーク ロードバランサのネクストホップの組み合わせが同じ静的ルートを複数作成できます。

Classic VPN トンネルのネクストホップに関する考慮事項

  • リージョン間のコストとレイテンシ: Google Cloud では、ネクストホップの Classic VPN トンネルを使用するルートのリージョンの距離が考慮されません。別のリージョンにあるネクストホップの Classic VPN トンネルにトラフィックを送信すると、アウトバウンド データ転送の費用が増加し、ネットワークのレイテンシが発生します。この構成では、リージョンの距離が考慮されるため、動的ルーティングを使用した HA VPN トンネルの使用をおすすめします。

  • Classic VPN トンネルが実行されていない場合の動作: ネクストホップが Classic VPN トンネルのカスタム静的ルートは、Classic VPN トンネルが実行されていない場合に自動的に削除されることはありません。トンネルが実行されていない場合の影響については、Classic VPN ドキュメントのトンネルがダウンした場合をご覧ください。

次のステップ