ルート

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/2410.70.1.0/2510.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 では、10.70.1.128/2510.70.1.0/24、または 10.70.1.128/25 のすべての IPv4 アドレスを含むその他の範囲のプライマリまたはセカンダリのサブネット 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)メッセージと、ユーザーが構成した 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 ネットワークの外部(Google の本番環境ネットワーク)に定義されています。これは、VPC ネットワーク ルートテーブルには表示されません。VPC ネットワークでデフォルト ルートを削除または置換しても、削除や上書きはできません。ただし、VPC ファイアウォール ルール、ネットワーク ファイアウォール ポリシー、または階層型ファイアウォール ポリシーを使用して、パケットを許可または拒否できます。

ロードバランサのリターンパス

Google Cloud は、VPC ネットワーク外の特別なルートを使用して、次の対象間でパケットを配信します。

  • クライアント システムとロードバランサのバックエンド(外部パススルー ネットワーク ロードバランサの場合)
  • プロキシ システムとロードバランサのバックエンド(外部プロキシ ロードバランサの場合)
  • ヘルスチェック プローバーとロードバランサのバックエンド
Google Front End(GFE)のプロキシとバックエンド間のパス

グローバル外部アプリケーション ロードバランサ従来型アプリケーションのロードバランサ従来型プロキシ ネットワーク ロードバランサグローバル外部プロキシ ネットワーク ロードバランサは、Google Front End(GFE)システムをプロキシとして使用します。

クライアントがロードバランサにリクエストを送信すると、GFE はその最初の TCP 接続を終端します。次に、GFE がバックエンド VM への 2 番目の TCP 接続を開きます。Google Cloud は、VPC ネットワーク外で定義されたルートを使用して、GFE プロキシとバックエンド VM 間でパケットを転送します。

外部パススルー ネットワーク ロードバランサのバックエンドへのパス

外部パススルー ネットワーク ロードバランサの場合、Google Cloud は VPC ネットワーク外で定義されたルートを使用して、クライアントとバックエンド VM 間でパケットを転送します。

すべてのロードバランサ タイプのヘルスチェック

Google Cloud ヘルスチェック プローブ システムから送信されたパケットは、プローブ IP 範囲とファイアウォール ルールに記載されているパケットソースを使用します。

IAP

Google Cloud には、IAP を使用した TCP 転送をサポートするために、各 VPC ネットワーク内の 35.235.240.0/20 との間のルートが含まれています。Google の本番環境ネットワークでは、内部専用範囲として 35.235.240.0/20 が使用されます。35.235.240.0/20 のネクストホップは、完全に Google の本番環境ネットワーク内にあります。

Cloud DNS と Service Directory

Google Cloud には、プライベート ルーティングを使用する Cloud DNS 転送ターゲットプライベート ルーティングを使用する Cloud DNS 代替ネームサーバーService Directory のプライベート ネットワーク アクセスをサポートするために、各 VPC ネットワークに 35.199.192.0/19 との間のルートが含まれています。Google の本番環境ネットワークでは、内部専用範囲として 35.199.192.0/19 が使用されます。35.199.192.0/19 のネクストホップは、完全に Google の本番環境ネットワーク内にあります。

サーバーレス VPC アクセス

Google Cloud には、サーバーレス VPC アクセスをサポートするために、各 VPC ネットワーク内の 35.199.224.0/19 との間のルートが含まれています。Google の本番環境ネットワークでは、内部専用範囲として 35.199.224.0/19 が使用されます。35.199.224.0/19 のネクストホップは、完全に Google の本番環境ネットワーク内にあります。

ルーティング順序

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

  1. 特別なリターンパス: 特別なリターンパスは、VPC ネットワークのルートテーブルに表示されません。VPC ネットワークで構成したルートは、特定の Google Cloud ロードバランサ、ヘルスチェック システム、Identity-Aware Proxy(IAP)、Cloud DNS プロキシのレスポンス パケットには適用されません。詳しくは、特別なリターンパスをご覧ください。

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

  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 はパケットをネクストホップの内部パススルー ネットワーク ロードバランサに配信し、ポリシーベースではないルートをすべて無視します。

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

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

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

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

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

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

  5. ネクストホップが実行されていないカスタム静的ルートを無視する: このステップでは、実行されていないとみなされるネクストホップを 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 が確立されていないルートをモデルから削除します。

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

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

    • 最も限定された範囲の同一の宛先
    • すべて 1 つの VPC ネットワークにあるネクストホップ(ローカル VPC ネットワークまたは単一のピア VPC ネットワーク)
    • 停止していないことがわかっているネクストホップ
    • 最も高い同じ優先度
  7. 最も望ましい選好カテゴリのみを選択する: 異なる種類のネクストホップでの ECMP ルーティングを回避します。この動作は、次の表に示す選好カテゴリ体系を考慮に入れることでモデル化できます。このステップでは、同じルートタイプか、ルートタイプとネクストホップ タイプの組み合わせのルートのみを含むようにルートモデルを絞り込みます。

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

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

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

    • ルートモデルが空の場合、パケットは 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.168.0/24 ルートのすべてのネクストホップ VM が実行されていませんが、より広範な 192.168.0.0/16 のルートのネクストホップ 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 アドレスを使用する転送ルールで、異なるバックエンド サービス(異なる内部パススルー ネットワーク ロードバランサ)を参照することは可能です。

  • 同じ宛先と複数のネクストホップの内部パススルー ネットワーク ロードバランサ。異なる内部パススルー ネットワーク ロードバランサ ネクストホップを使用して、同じ宛先で 2 つ以上のカスタム静的ルートを作成する場合、Google Cloud は ECMP を使用してロードバランサのネクストホップ間でトラフィックを分散しません。ルートの優先度が一意である場合、Google Cloud は、優先度が最も高いルートの内部パススルー ネットワーク ロードバランサを使用します。ルートの優先度が同じ場合、Google Cloud は、ネクストホップ内部パススルー ネットワーク ロードバランサを 1 つだけ選択します。後者の状況では、以下の図に示すように、Google Cloud は決定論的な内部アルゴリズムで単一のネクストホップ転送ルール(forwarding-rule-a)を選択し、同じ優先度を持つ他のルートを無視します。

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

    インスタンス タグを使用する場合:

    インスタンス タグ(ネットワーク タグともいいます)を使用する場合、同じ宛先と優先度を持つ複数のカスタム静的ルートに同じネクストホップの内部パススルー ネットワーク ロードバランサを使用できます。

    インスタンス タグなし: インスタンス タグがない場合、宛先、優先度、内部パススルー ネットワーク ロードバランサのネクストホップの同じ組み合わせを持つ複数のカスタム静的ルートを作成することはできません。たとえば、route-xroute-yroute-z は作成できますが、route-x-copy は作成できません。

    同じ宛先、優先度、内部パススルー ネットワーク ロードバランサのネクストホップを使用して、インスタンス タグのない静的ルートを作成することはできません。
  • インスタンス タグ

    インスタンス タグ(ネットワーク タグとも呼ばれます)を指定すると、ネクストホップ ルートはタグを使用して構成されたクライアント インスタンスにのみ適用されます。これにより、タグ付きのネクストホップ ルートを適用するクライアント インスタンスと、トラフィックをルーティングするアプライアンスのセットを選択できます。

    複数のクライアント インスタンスを別々の VPC ネットワークに分離する必要はありません。それぞれが、アプライアンスのセットをフロントエンドする優先内部パススルー ネットワーク ロードバランサを指しています。

  • 同じ宛先プレフィックスへの複数のルート。インスタンス タグを使用すると、異なる内部ロードバランサを持つ同じ宛先への複数のルートをネクストホップとして指定できます。同じ宛先ルートに対して、異なるインスタンス タグや異なる優先度を使用できます。

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

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

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

次のステップ