ルートの概要

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 ネットワーク内のルートを分類する方法をまとめたものです。

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

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

サブネットまたはサブネットのセカンダリ IP アドレス範囲の作成、変更、削除を行うと、Google Cloud によって自動的に作成、更新、削除されます。
カスタムルート
静的ルート
さまざまな宛先をサポートします。
有効な静的ルートのネクストホップ ネクストホップの内部 TCP / UDP ロードバランサの場合、グローバル アクセスが有効になっている場合を除き、ロードバランサと同じリージョン内の TCP トラフィックと UDP のトラフィックにのみ適用されます。

他の静的ルートの場合: ルートにネットワーク タグを指定すると、特定の VM にルートを適用できます。ネットワーク タグを指定しない場合、VPC ネットワーク内のすべての VM にルートが適用されます。
動的ルート
サブネット ルートまたは静的ルートと競合しない宛先
Cloud Router での BGP セッションのピア ルートは、VPC ネットワーク内の Cloud Router によって自動的に追加、削除されます。

ルートは、VPC ネットワークの動的ルーティング モードに従って VM に適用されます。
ピアリング ルート
ピアリング サブネット ルート
VPC ネットワーク ピアリングを使用して接続されたネットワーク内のサブネット IP アドレス範囲を表します。
ピア VPC ネットワーク
パケットをピア ネットワーク内の VM と内部ロードバランサに転送します。
VPC ネットワーク全体に適用されます。

ピア ネットワークでサブネットが作成、変更、削除されると、Google Cloud によって自動的に作成、更新、削除されます。
ピアリング カスタムルート
VPC ネットワーク ピアリングで接続されたネットワーク内のカスタム静的ルートまたはカスタム動的ルート
ピア VPC ネットワークのネクストホップ ピア ネットワークの静的ルートに基づくピアリング カスタムルートは次のように適用されます。
  • ネクストホップが内部 TCP / UDP ロードバランサであるカスタム静的ルートをピアリング カスタムルートが利用している場合、ロードバランサの転送ルールでグローバル アクセスが有効になっていない限り、このルートはロードバランサと同じリージョン内の TCP トラフィックと UDP トラフィックに適用されます。
  • ネクストホップが内部 TCP / UDP ロードバランサであるカスタム静的ルートをピアリング カスタムルートが利用し、そのカスタム静的ルートに関連付けられたタグがない場合は、このルートをインポートする VPC ネットワーク内のすべての VM にルートが適用されます。
  • ピア ネットワークでネットワーク タグを使用している静的ルート、またはネクストホップがデフォルトのインターネット ゲートウェイの静的ルートはピアリング関係にエクスポートされません。
ピア ネットワーク内の動的ルートを利用するピアリング カスタムルートは、そのルートをインポートする VPC ネットワークの動的ルーティング モードに従って適用されます。

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

VPC ネットワークを作成すると、システムによりデフォルト ルートが生成されます。このデフォルト ルートには 2 つの用途があります。

  • VPC ネットワークから外部へのパス(インターネットのパスなど)を定義します。インターネットにアクセスする必要がある場合は、このルートを設定するだけではなく、インスタンスが追加要件を満たす必要があります。

  • 限定公開の Google アクセスの標準パスを指定します。

システム生成のデフォルト ルートの優先順位は 1000 です。宛先の範囲が非常に広いため(0.0.0.0/0)、パケットに特定の宛先のルートが適用されない場合に限り、Google Cloud はこのルートを使用します。ルートを選択する際の宛先の指定方法とルートの優先度については、ルーティング順序をご覧ください。

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

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

  • 置き換えを行わずにデフォルト ルートを削除すると、他のルートで網羅されていない IP 範囲に送信されたパケットは破棄されます。

サブネット ルート

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

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

サブネット ルートの宛先と一致する宛先や、これよりも限定された宛先(サブネット マスクが長い宛先)を持つルートは作成できません。

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

サブネット ルートの作成または削除では、次の点に注意してください。

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

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

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

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

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

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

静的ルート

静的ルートは、静的ルートのパラメータで定義され、静的ルートのネクストホップをサポートします。静的ルートは次のいずれかの方法で作成できます。

動的ルート

動的ルートは VPC ネットワーク内の Cloud Router によって管理されます。宛先は常に VPC ネットワーク外の IP アドレス範囲を表します。これは BGP ピアから受信します。動的ルートは次のもので使用されます。

宛先が次のいずれかの条件に一致すると、VPC ネットワークは Cloud Router が受信した宛先を無視します。

  • 宛先がサブネットの IP アドレス範囲と完全に一致している。

  • 宛先がサブネット IP アドレス範囲内にある(サブネット IP アドレス範囲よりもサブネット マスクが長い)。

動的ルートの宛先がサブネットの IP アドレス範囲を含む場合(サブネット IP アドレス範囲よりもサブネット マスクが短い場合)は無視されません。この場合、パケットがサブネット ルートの宛先内に収まらない場合にのみ、動的ルートのネクストホップに送信されます。最も広範囲な宛先は 0.0.0.0/0 です。

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

ピアリング サブネット ルートは、VPC ネットワーク ピアリングで接続された別の VPC ネットワーク内のサブネットを使用してリソースのパスを定義します。もう一方のネットワークはピア VPC ネットワークといいます。

ピア ネットワークは次のようにサブネット ルートを共有します。

  • ピア ネットワークは、プライマリとセカンダリのすべての IP アドレス範囲に対して常にサブネット ルートをエクスポートします。

  • ピア ネットワークは、ルートの宛先(サブネット IP アドレス範囲)がプライベートで再利用されたパブリック IP アドレスでない限り、サブネット ルートを自動的にインポートします。必要であれば、プライベートでパブリック IP アドレスを使用するサブネット ルートをインポートするようにピアを構成できます。

  • ピアリングを無効にしない限り、インポートされたピアリング サブネット ルートは削除できません。ピアリングを無効にすると、インポートされたすべてのピアリング サブネット ルートが自動的に削除されます。

  • Google Cloud は、ピアリングされるネットワーク間でのサブネット IP アドレス範囲の競合を防ぎます

VPC ネットワーク内にあるサブネット ルートと、すべてのピア ネットワークからインポートされたピアリング ルートを組み合わせた合計数は、サブネット IP 範囲(プライマリとセカンダリ)の最大数によって制限されます。

ピアリング カスタムルート

カスタムルートをエクスポートまたはインポートするようにピア ネットワークを構成できます。このコンテキストで、カスタムルートは、VPC ネットワーク内の静的ルートと動的ルートの両方を意味します。

VPC ネットワークがカスタムルートをエクスポートするように構成されている場合でも、次に示すタイプのルートは省略されます。

VPC ネットワーク内の静的ルートと動的ルートの合計に、すべてのピア ネットワークからインポートされたピアリング ルートを合わせた数は、次のものによって制限されます。

  • ピアリング グループ内の最大静的ルート数
  • ピアリング グループ内の最大動的ルート数

適用範囲と順序

適用可能なルート

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

  • サブネットとピアリングのサブネット ルートはすべてのインスタンスに適用されます。サブネット ルートとピアリング サブネット ルートは、VPC ネットワーク内のサブネットとピア ネットワークからインポートされたサブネットに対応しています。

  • システムが生成するデフォルトのルートはすべてのインスタンスに適用されます。システム生成のデフォルト ルートは、必要に応じてカスタム静的ルートに置き換えることができます。

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

    • カスタム静的ルートに VM インスタンスのネクストホップがある場合、ネクストホップの VM で削除、電源オフまたは誤動作が発生しても、ルートは常に有効です。詳細については、ネクストホップとしてのインスタンスをご覧ください。

    • Cloud VPN トンネルのネクストホップを持つカスタム静的ルートの場合、トンネルが稼働している場合は常に有効です。トンネルが利用できない場合に Google Cloud がルートを処理する方法については、Cloud VPN のドキュメントのトンネルがダウンした場合をご覧ください。

  • 動的ルートは、VPC ネットワークの動的ルーティング モードに基づいてインスタンスに適用されます。VPC ネットワークでリージョン動的ルーティング モードが使用されている場合、Cloud Router はそのローカル リージョンで学習した接頭辞に対してのみ動的ルートを作成します。VPC ネットワークでグローバル動的ルーティング モードが使用されている場合、Cloud Router は、すべてのリージョンで学習された接頭辞に対して動的ルートを作成します。

    • Cloud Router は、アクセスできないネクストホップ(Cloud VPN トンネルまたは Cloud Interconnect アタッチメント)に対応する学習済みの接頭辞を自動的に破棄します。ネットワークによっては、Cloud Router が停止しているネクストホップを含む動的ルートを削除するまでに 40 秒ほどかかる場合があります。
  • 負荷分散トラフィックによっては、適用可能なルートが VPC ネットワークの外部から始まる場合があります。詳細については、ロードバランサのリターンパスをご覧ください。

ルーティング順序

インスタンスがパケットを送信すると、Google Cloud は次のルーティング順序に従って適用可能なルートのセットから 1 つのルートを選択します。

  1. サブネット ルートとピアリング サブネット ルートは、宛先の範囲が最も狭いため、最初に考慮されます。Google Cloud は、ローカル サブネット ルートの場合と同様に、ピアリング サブネット ルートも考慮します。

    • パケットの宛先 IP アドレスがサブネットまたはピアリング サブネット ルートの宛先内にある場合:

      • パケットは、実行中の VM インスタンスまたは構成済みの内部ロードバランサの内部 IP アドレスに配信されます。

      • 停止している VM インスタンス宛てのパケットは破棄されます。

      • 内部 IP アドレス宛てのパケットは、その IP アドレスを使用するように Google Cloud リソースが構成されていない場合、破棄されます。

    • Google Cloud では、サブネット ルートまたはピアリング サブネット ルートと同じ範囲か、それ以上に狭い範囲の宛先を持つカスタム静的ルートを作成することはできません。

    • Cloud Router は、サブネット ルートまたはピアリング サブネット ルートの宛先と完全に一致する学習済みの接頭辞を無視します。

    • Cloud Router は、サブネット ルートまたはピアリング サブネット ルートに収まる(これらのルートよりもサブネット マスクが長い)学習済みの接頭辞を無視します。

  2. サブネット ルートまたはピアリング サブネット ルートでパケットをルーティングできない場合、Google Cloud は最も狭い範囲の宛先を持つ静的ルート、動的ルート、ピアリング カスタムルートを検索します。たとえば、宛先が 10.240.1.4 のパケットの場合、10.240.1.0/2410.240.0.0/16 よりも限定された宛先になります。

  3. 最も狭い範囲の宛先を持つルートが複数ある場合、Google Cloud は次のプロセスを使用してルート候補からルートを選択します。ルート候補は、最も狭い同じ範囲の宛先を持つ静的ルート、動的ルート、ピアリング カスタムルートです。

    1. VPC ネットワークがピア ネットワークに接続されている場合、Google Cloud は単一の VPC ネットワークからのルートを除いてすべてのルート候補を排除します。

      • ローカル VPC ネットワークに 1 つ以上のルート候補が存在する場合、Google Cloud はピア ネットワークからのルート候補をすべて無視します。

      • ローカル VPC ネットワークにルート候補がなく、複数のピア ネットワークに候補が存在する場合、Google Cloud は、ピア ネットワークの 1 つに定義されているルート候補を除き、すべてのルート候補を無視します。Google Cloud は内部アルゴリズムを使用して単一のピア ネットワークを選択します。このアルゴリズムは、プロセスのこの時点でルートの優先度を考慮しません。新しいネットワークとピアリングするか、既存のピア ネットワークから切断すると、Google Cloud で選択される VPC ネットワークが変更されることがあります。

    2. Google Cloud は、優先度が最も高いルートを除いてすべてのルート候補を排除します。その結果、ルートが 1 つ残った場合、Google Cloud はそのネクストホップにパケットを送信します。

    3. 複数のルート候補の優先度がすべて同じ場合、Google Cloud はルートのネクストホップとルートタイプを使用して除外プロセスを続行します。その結果、ルートが 1 つ残った場合、Google Cloud はそのネクストホップにパケットを送信します。

      1. 最も優先度の高い候補は、ネクストホップのネクストホップ インスタンス、ネクストホップ IP、またはネクストホップ VPN トンネルを使用するカスタム静的ルートです。このネクストホップ タイプを使用するルート候補が存在する場合、他のすべてのルート候補が除外されます。

      2. 2 番目はカスタム動的ルート、

      3. 3 番目は、ネクストホップが内部 TCP / UDP ロードバランサのカスタム静的ルートです。

      4. デフォルト インターネット ゲートウェイのネクストホップを使用するカスタム静的ルートは最も優先度が低くなります。

    4. ルート候補からのルートが複数存在する場合、それらのルートはすべて同じ VPC ネットワーク内に存在し、同じ優先度になります。Google Cloud はアフィニティ用に 5 タプルのハッシュを使用してルート候補のネクストホップ間にトラフィックを分散させ、ECMP(Equal Cost Multi-Path)を実装します。ハッシュ計算は、ルート選択アルゴリズムによって決定されるルート候補数に基づいて、各パケットの送信時に行われます。ルートの候補数が変わると、同じ 5 タプルハッシュを持つパケットを別のネクストホップに転送する場合があります。

  4. 該当する宛先が見つからない場合、Google Cloud はパケットを破棄し、ICMP の宛先またはネットワーク到達不能エラーで応答します。

特別なリターンパス

VPC ネットワークには特定のサービス用の特別なルートがあります。このルートは、VPC ネットワークの外部(Google の本番環境ネットワーク)に定義されています。このルートは、VPC ネットワークのルーティング テーブルに含まれません。VPC ネットワークでデフォルト ルートを削除または置換しても、削除や上書きはできません。ただし、ファイアウォール ルールを使用して、これらのサービス間のトラフィックを制御できます。

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

次のいずれかの Google Cloud ロードバランサを使用している場合、Google Cloud には、ロードバランサとそれに関連するヘルスチェック用の特別なルートがあります。以下では、このルートについて詳しく説明します。

HTTP(S) プロキシ、SSL プロキシ、TCP プロキシ ロードバランサのリターンパス

これらのロードバランサ タイプでは、Google フロントエンド(GFE)システムがプロキシとして機能します。クライアントがロードバランサにリクエストを送信すると、プロキシが TCP セッションを終了し、バックエンド VM と新しい TCP セッションを開始します。VPC ネットワークの外部で定義されたルートにより、GFE プロキシからバックエンド VM への通信と、バックエンド VM から GFE プロキシへの通信が可能になります。

詳しくは次のページをご覧ください。

ネットワーク ロードバランサのリターンパス

インターネット上のクライアントが TCP または UDP リクエストをネットワーク ロードバランサ経由でバックエンド VM に送信すると、Google Cloud は VPC ネットワーク外で定義されたルートを使用して、クライアントからバックエンド VM への通信とバックエンド VM からクライアントへの通信を行います。

詳細については、ネットワーク負荷分散をご覧ください。

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

Google Cloud ヘルスチェック プローブ システムから送信されるパケットには、プローブ IP 範囲とファイアウォール ルールで説明されているような送信元があります。Google Cloud ヘルスチェック プローブ システムとバックエンド VM 間の通信を可能にするルートは VPC ネットワーク外に存在するため、削除できません。ただし、VPC ネットワークでは、これらのシステムからのトラフィックを許可する上り(内向き)ファイアウォール ルールを設定する必要があります。

IAP

35.235.240.0/20 へのルートは、IAP を使用した TCP 転送をサポートするために含まれています。Google の本番環境ネットワークは、インターネット上の他の送信元からの 35.235.240.0/20 へのルートを受け入れません。

Cloud DNS

35.199.192.0/19 へのルートは、限定公開ルーティングを使用する転送先または限定公開ルーティングを使用する代替ネームサーバーへの接続をサポートします。Google の本番環境ネットワークは、インターネット上の他のソースからの 35.199.192.0/19 へのルートを受け入れません。

静的ルートのパラメータ

静的ルートは次の要素から構成されます。

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

  • ネットワーク。各ルートは 1 つの VPC ネットワークに関連付ける必要があります。

  • 宛先の範囲。宛先の範囲は、受信パケットを受信するシステムの IP アドレスを含む単一の IPv4 CIDR ブロックです。宛先は CIDR 表記で表す必要があります。サブネットの IP アドレス範囲と完全に一致する宛先を設定することはできません。また、サブネット IP アドレス範囲の範囲内に収まる宛先も使用できません(サブネット IP アドレス範囲よりも長いサブネット マスクを使用することはできません)。静的ルートの宛先にはサブネット IP アドレス範囲を含めることが可能です(サブネット IP アドレス範囲よりも短いサブネット マスクを使用できます)。この場合、パケットがサブネット ルートの宛先内に収まらない場合にのみ、静的ルートのネクストホップに送信されます。最も広範囲な宛先は 0.0.0.0/0 です。

  • 優先度。複数のルートが同じ宛先を持つ場合、使用するルートの決定に優先度が使用されます。数字が小さいほど、優先度が高くなります。たとえば、優先度の値が 100 のルートは、200 のルートよりも優先されます。ルート優先度の最高値は最も小さい正の整数です。ゼロは最小の正の整数であるため、最も高い優先度になります。

  • ネクストホップ。静的ルートには、デフォルト インターネット ゲートウェイ、Google Cloud インスタンスまたは Cloud VPN トンネルを参照するネクストホップを設定できます。詳細については、静的ルートのネクストホップをご覧ください。

  • タグ。ルートがリスト内のタグを含むインスタンスにのみ適用されるように、ネットワーク タグのリストを指定できます。タグを指定しないと、Google Cloud はネットワーク内のすべてのインスタンスにルートを適用します。ネクストホップの内部 TCP / UDP ロードバランサは、ネットワーク タグをサポートしていません。

静的ルートのネクストホップ

静的ルートに有効なネクストホップは次のとおりです。各タイプの詳細については、gcloud リファレンスのドキュメントをご覧ください。

  • ネクストホップ ゲートウェイ(next-hop-gateway)。デフォルトのインターネット ゲートウェイを指定して、外部 IP アドレスのパスを定義できます。

  • ネクストホップ インスタンス(next-hop-instance)。名前とゾーンを指定して、Google Cloud の既存のインスタンスにトラフィックを転送できます。トラフィックは、ルートを定義する VPC ネットワーク内にある VM のネットワーク インターフェースのプライマリ内部 IP アドレスに転送されます。

    • VPC ネットワーク内にある VM インスタンスのネットワーク インターフェースのプライマリ内部 IP アドレスが変更されると、新しい IP アドレスの VM にトラフィックが引き続き送信されるように、Google Cloud は VPC ネットワークのルーティング テーブルを自動的に更新します。

    • VM が同じゾーンにある同じ名前の新しい VM で置き換えられると、トラフィックが新しい VM に転送されるように、Google Cloud は VPC ネットワークのルーティング テーブルを自動的に更新します。

    • Google Cloud は、ルートの作成時にネクストホップ VM の存在を検証します。VM がパケットを処理または転送できるかどうかは検証しません。VM が削除されても置換されていない場合、引き続きルートが適用されるため、パケットが破棄される可能性があります。詳細については、ネクストホップとしてのインスタンスをご覧ください。

  • ネクストホップの内部 TCP / UDP ロードバランサ(next-hop-ilb)。内部 TCP / UDP 負荷分散の場合、正常なバックエンド インスタンス間でトラフィックを分散するネクストホップとしてロードバランサの IP アドレスを使用できます。たとえば、ネクストホップが内部 TCP / UDP ロードバランサのカスタム静的ルートを使用して、バックエンド VM 間でトラフィックを分散できます。このネクストホップを使用するカスタム静的ルートの場合、ネットワーク タグで特定のインスタンスに範囲を限定することはできません。

  • ネクストホップ IP(next-hop-address)。ネクストホップとして Google Cloud VM に割り当てられた内部 IP アドレスを指定できます。

    • next-hop-address を使用する場合、Google Cloud はその IP アドレスに割り当てられた VM インスタンスにトラフィックを転送します。VM インスタンスを同じ IP アドレスの別の VM インスタンスで置き換えると、置換後のインスタンスが元のインスタンスと別の名前でも、トラフィックが置換後のインスタンスに送信されます。VM 名でネクストホップを定義するには、代わりにネクストホップ インスタンスを使用します。

    • ルートを作成するときに、Google Cloud は IP アドレスがサブネットのプライマリまたはセカンダリ IP 範囲の有効なメンバーかどうかを確認します。インスタンスがネクストホップ IP アドレスに存在することは検証しません。ネクストホップ IP アドレスがどのインスタンスにも割り当てられていない場合、引き続きルートが適用されるため、パケットが破棄される可能性があります。詳細については、インスタンスとロードバランサのネクストホップに関する考慮事項をご覧ください。

    • 任意の IP アドレスのネクストホップを指定することはできません。VPC ネットワーク内にあるサブネットの IP アドレス範囲外のアドレスは許可されません。

  • ネクストホップ VPN トンネル(next-hop-vpn-tunnel)。ポリシーベースのルーティングとルートベースの VPN を使用する Cloud VPN トンネルの場合、ネクストホップが名前とリージョンでトンネルを参照するルートを作成し、トラフィックを VPN トンネルに転送できます。ネクストホップの Cloud VPN トンネルが停止している場合、Google Cloud はそのルートを無視します。ルートと Cloud VPN トンネルの関係については、Cloud VPN ルーティングの例をご覧ください。

インスタンスとロードバランサのネクストホップに関する考慮事項

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

ネクストホップとしての内部 TCP / UDP ロードバランサは、ネクストホップが内部 TCP / UDP ロードバランサの静的ルートを参照します(next-hop-ilb)。

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

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

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

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

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

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

ネクストホップ インスタンスに固有の考慮事項

  • インスタンスをネクストホップとして使用する場合(next-hop-instance または next-hop-address)、インスタンスがゾーンリソースであるので注意してください。ゾーンを選択するとリージョンが選択されたとみなされますが、Google Cloud では、ネクストホップ インスタンスを使用するルートの地理的な距離を考慮しないため、異なるリージョンのネクストホップにトラフィックを送信するルートを作成できます。これにより、下り(外向き)のコストが増加し、ネットワーク レイテンシが発生します。

  • ルートを作成するときに、Google Cloud は次の基本的な検証のいずれかを行います。

    • next-hop-instance を指定する場合、インスタンスがすでに存在している必要があります。
    • next-hop-address を指定する場合、IP アドレスが既存サブネットのプライマリまたはセカンダリ IP 範囲に含まれている必要があります。
  • たとえば、インスタンスやサブネットの削除を後で行うと、Google Cloud が適用可能なルートを評価するときに、そのインスタンスをネクストホップとして使用するルートが引き続き検討されます。これにより、ネットワークの他のルートによっては、特定の宛先に対する一部またはすべてのパケットが破棄される可能性があります。

  • VM インスタンスのソフトウェア(VM のオペレーティング システム、パケットをルーティングする VM プロセスなど)が失敗した場合、そのインスタンス宛てのパケットは破棄されます。信頼性を高めるには、内部 TCP / UDP ロードバランサをネクストホップとして使用することを検討してください。内部 TCP / UDP ロードバランサの場合、ヘルスチェックの構成が必要です。このヘルスチェックにより、新しい接続のルーティング方法が決まります。

  • インスタンスのゲスト オペレーティング システムを構成してネットワーク インターフェースを無効にしても、インターフェースは引き続きネクストホップとして評価されます。

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

Google Cloud は、ネクストホップの Classic VPN トンネルを使用するルートのリージョン距離を考慮しません。別のリージョンのネクストホップの Classic VPN トンネルにトラフィックを送信すると、下り(外向き)のコストが増加し、ネットワークのレイテンシが発生します。HA VPN トンネルまたは動的ルーティングを使用する Classic VPN トンネルを使用することをおすすめします。

次のステップ