ルートの概要

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 コントローラに伝播され、最終的には一貫した設計になります。

ルートのタイプ

VPC ネットワークには、システム生成ルートとカスタムルートがあります。

次の表に、システム生成ルートの概要を示します。VPC ネットワークの作成サブネットの追加サブネットのプライマリ IP 範囲の拡張またはサブネットのセカンダリ IP 範囲の編集を行うと、システム生成ルートが自動的に追加または更新されます。このルートは、VPC ネットワーク内のすべてのインスタンスに適用されます。

システム生成ルート
タイプ 宛先 ネクストホップ 削除可能
デフォルト ルート 0.0.0.0/0 default-internet-gateway
サブネット ルート プライマリとセカンダリのサブネット IP 範囲
サブネット内の VM にパケットを転送する VPC ネットワーク サブネットが削除された場合とサブネットのセカンダリ IP 範囲を変更した場合のみ

次の表に、直接または Cloud Router で作成し、維持できるカスタムルートの概要を示します。

カスタムルート
タイプ 宛先 ネクストホップ 削除可能 適用先
静的ルート • 任意のサブネット IP 範囲と一部または全体が重複していない IP 範囲
• サブネット IP 範囲より広い IP 範囲
次のいずれか:
• 名前で指定されたインスタンス
• IP アドレスで指定されたインスタンス
• Cloud VPN トンネル
次のいずれか:
• ネットワーク内のすべてのインスタンス
• ネットワーク タグで指定されたネットワーク内の特定のインスタンス(ルートの範囲がネットワーク タグで指定できる場合)
動的ルート • 任意のサブネット IP 範囲と一部または全体が重複していない IP 範囲
• サブネット IP 範囲より広い IP 範囲
Cloud Router の BGP ピアの IP アドレス Cloud Router によってのみ可能(Cloud Router が BGP ピアからルートを受信しなくなった場合) • Cloud Router と同じリージョンのインスタンス(VPC ネットワークがリージョン動的ルーティング モードになっている場合)
• すべてのインスタンス(VPC ネットワークがグローバル動的ルーティン グモードの場合)

デフォルト ルート

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

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

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

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

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

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

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

サブネット ルート

サブネット ルートは、VPC ネットワークにあるサブネットのパスを定義するシステム生成ルートです。

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

サブネット ルートの宛先と一致する宛先や、これよりも狭い範囲の宛先を持つルートは作成できません。サブネット ルートの宛先範囲よりも広い宛先のカスタムルートを作成できます。

Google Cloud はルーティング順序の最初の基準として宛先指定を使用します。IP 範囲が重複する場合、パケットの宛先がルートの宛先範囲内にあれば、サブネット ルートが常に優先ネクストホップとして使用されます。ルートの宛先に優先度の高いサブネット ルートの宛先が含まれている場合でも同じ結果になります。

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

  • サブネットが作成されると、そのサブネットのプライマリ IP 範囲に対応するサブネット ルートも作成されます。

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

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

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

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

  • ネットワークが VPC ネットワーク ピアリングで接続されている場合、ネットワーク間でサブネット ルートがインポートされます。このため、プライマリとセカンダリのサブネット IP 範囲はすべて一意でなければなりません。

    • ピアリングされたネットワーク内のサブネットのサブネット ルートは、ピアリング関係を解除しない限り削除できません。ピアリング関係を解除すると、他のネットワークからインポートされたサブネット ルートはすべて自動的に削除されます。

ファイアウォール ルールによってインスタンス間の通信がブロックされる場合があります。インスタンス間の通信については、ネットワーク内の通信をご覧ください。

カスタムルート

カスタムルートは、手動で作成した静的ルートか、1 つ以上の Cloud Router によって自動的に保持される動的ルートのどちらかです。

カスタムルートには、ネットワーク内のサブネット ルートに一致する宛先や、これよりも狭い範囲の宛先は設定されません。

自動モードの VPC ネットワークを使用している場合は、10.128.0.0/9 CIDR ブロックに該当する宛先を使用できません。このブロックは、サブネット ルートの現在のアドレス空間と将来のアドレス空間を定義するために使用されます。詳細については、自動モードの IP 範囲をご覧ください。

自動モードの VPC ネットワークでは、10.128.0.0/9 内の宛先を持つ静的ルートが無効になることがあります。新しい Google Cloud リージョンが使用可能になり、新しいサブネットがサブネット ルートとともに自動的に生成されると、このような状況が発生する場合があります。詳細については、自動モードの VPC ネットワークに関する考慮事項をご覧ください。

静的ルート

静的ルートは、静的ルートのネクストホップのいずれかを使用します。静的ルートは次のいずれかの方法で作成します。

  • 手動で作成する。

  • Google Cloud Console を使用する。ポリシーベースのルーティングまたはルートベースの VPN を使用する Cloud VPN トンネルを作成すると、リモート トラフィック セレクタの静的ルートが作成されます。詳細については、Cloud VPN ネットワークとトンネル ルーティングをご覧ください。

詳細については、静的ルート パラメータをご覧ください。

動的ルート

動的ルートは 1 つ以上の Cloud Router によって管理されます。宛先は常に VPC ネットワークに含まれない IP 範囲で、ネクストホップは常に BGP ピアアドレスになります。Cloud Router は次の動的ルートを管理します。

適用範囲と順序

適用可能なルート

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

  • システム生成ルートは、VPC ネットワーク内のすべてのインスタンスに適用されます。サブネット ルートが適用されるインスタンスの範囲は変更できません。ただし、デフォルト ルートは置き換えが可能です。

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

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

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

  • 動的ルートは、VPC ネットワークの動的ルーティング モードに基づいてインスタンスに適用されます。VPC ネットワークが動的ルーティング モードの場合、Cloud Router は各リージョンで学習したルートを適用します。ネットワークがグローバル動的ルーティング モードの場合、Cloud Router はネットワーク全体で学習したルートを適用します。

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

ルーティング順序

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

  1. サブネット ルートを最初に検討します。サブネット ルートには、サブネットの IP アドレス範囲に一致する最も狭い範囲の宛先が必要になります。サブネット ルートは、VPC ネットワークの各サブネットのプライマリおよびセカンダリ サブネットの IP アドレス範囲と、ピア ネットワークのサブネットのプライマリおよびセカンダリ サブネットの IP アドレス範囲のルートです。パケットの宛先がサブネット ルートの宛先内にある場合、このパケットは Google Cloud サブネットに配信されます。サブネット ルートは、他のタイプのルートで上書きできません

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

    • 静的ルートが動的ルートと同じ接頭辞長を持つ場合、静的ルートのほうが Cloud Router 動的ルートより優先されます。動的ルートと同じ接頭辞とルート指標を持つ静的ルートは常に優先されるため、競合する動的ルートは無視されます。

    • カスタム動的ルートでは、受信したルートにサブネット ルートと同じ宛先や、これよりも狭い宛先がある場合、Cloud Router は受信した他のネットワークへのルートをすべて無視します。

    • VPC ネットワーク ピアリングを使用して VPC ネットワークを接続すると、ネットワークではすべてのサブネット ルートが共有されます。Google Cloud は、ローカル ネットワーク自身のサブネット ルートと同様に、ピア ネットワークのサブネット ルートに優先順位を付けます。ピア ネットワークのサブネット ルートは、宛先範囲を最も狭くする必要があります。

  2. パケットがサブネット ルートの宛先内に収まらない場合、Google Cloud は宛先範囲が最も狭い別のルートを探します。

    • たとえば、VM から送信されるパケットの宛先が 10.240.1.4 で、異なる宛先(10.240.1.0/2410.240.0.0/16)を持つ 2 つのルートが存在するとします。10.240.1.4 で最も狭い範囲の宛先は 10.240.1.0/24 のため、宛先が 10.240.1.0/24 のルートがパケットのネクストホップを定義します。
  3. 最も狭い範囲の宛先を持つルートが複数ある場合、Google Cloud は次のプロセスを使用してルート候補からルートを選択します。ルート候補は、最も狭い同じ範囲の宛先を持つカスタムルート(静的ルートまたは動的ルート)です。

    1. VPC ネットワークが VPC ネットワーク ピアリングを介して他のネットワークに接続されている場合、Google Cloud はまず、すべてが単一の VPC ネットワークからであるルート候補に絞り込みます。

      • ローカル VPC ネットワークで少なくとも 1 つのルート候補が定義されている場合、Google Cloud はそのローカルルート候補を使用し、ピア ネットワークからの候補をすべて無視します。

      • ルート候補が複数のピア ネットワークからのものである場合、Google Cloud は少なくとも 1 つの候補ルートが定義されているピア ネットワークの 1 つを選択し、他のピア ネットワークからの候補ルートを無視します。Google Cloud は各ルートの優先度に関係なく、非決定的な方法で 1 つのピア ネットワークを選択します。ピアリング グループに対してネットワークの追加または削除を行うと、Google Cloud は別のピア ネットワークから候補ルートを選択する可能性があります。

      Google Cloud は、単一ネットワークの候補ルートからルートを選択します。

    2. 優先度の最も高いルートが利用可能な場合、Google Cloud はそのネクストホップにパケットを送信します。

    3. 優先度が最高のルートが複数存在する場合、Google Cloud Select は、ルートが静的か動的か、ネクストホップの値に応じてルートを選択します。Google Cloud は次の順序を使用します(優先度の高い順)。

      1. Google Cloud は、ネクストホップがネクストホップ インスタンス、ネクストホップ IP、ネクストホップ VPN トンネルのいずれかであるカスタム静的ルートを選択します。

      2. Google Cloud は、Cloud Router によってアドバタイズされているカスタム動的ルートを選択します。

      3. Google Cloud は、ネクストホップがネクストホップ内部 TCP / UDP ロードバランサであるカスタム静的ルートを選択します。

      4. Google Cloud は、ネクストホップのデフォルト インターネット ゲートウェイを使用してカスタム静的ルートを選択します。

    4. 単一のルートを選択できない場合、Google Cloud はアフィニティ用に 5 タプルのハッシュを使用してルート候補のネクストホップ間にトラフィックを分散させ、ECMP ルーティング設計を実装します。ハッシュは、プロトコル、送信元と宛先の IP アドレス、および送信されているパケットの送信元ポートと宛先ポートから計算されます。この計算は、利用可能なルート候補の数に基づいて送信された各パケットに対して行われます。使用可能なルート候補の数が変わると、パケットが別のネクストホップに転送される可能性があります。

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

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

次のいずれかの Google Cloud ロードバランサを使用している場合、Google Cloud には、ロードバランサとそれに関連するヘルスチェック用の特別なルートがあります。以下では、このルートについて詳しく説明します。このルートは、VPC ネットワークの外部(Google の本番環境ネットワーク)に定義されています。このルートは、VPC ネットワークのルーティング テーブルに含まれません。VPC ネットワークでデフォルト ルートを削除または置換しても、削除や上書きはできません。

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 ネットワークでは、これらのシステムからのトラフィックを許可する上り(内向き)ファイアウォール ルールを設定する必要があります。

静的ルートのパラメータ

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

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

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

  • 宛先の範囲。宛先の範囲は、受信パケットを受信するシステムの IP アドレスを含む単一の IPv4 CIDR ブロックです。Google Cloud は、IPv6 の宛先の範囲をサポートしていません。宛先は、CIDR 表記で表す必要があります。最も範囲の広い宛先は 0.0.0.0/0 です。

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

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

  • タグ。ルートがリスト内のタグを含むインスタンスにのみ適用されるように、ネットワーク タグのリストを指定できます。タグを指定しないと、Google Cloud はネットワーク内のすべてのインスタンスにルートを適用します。

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

静的ルートに有効なネクストホップは次のとおりです。各タイプの詳細については、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。IP アドレスが VPC ネットワークに存在するサブネットのプライマリまたはセカンダリ IP 範囲内にある場合、その IP アドレスをネクストホップとして指定できまます。オンプレミス ネットワークのパブリック IP アドレスまたは内部 IP アドレスは使用できません。

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

    • ルートを作成するときに、Google Cloud は IP アドレスがサブネットのプライマリまたはセカンダリ IP 範囲の有効なメンバーかどうかを確認します。インスタンスがネクストホップ IP アドレスに存在することは検証しません。ネクストホップ 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 ロードバランサの場合、ヘルスチェックの構成が必要です。このヘルスチェックにより、新しい接続のルーティング方法が決まります。

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

次のステップ