ルートの概要

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 と内部ロードバランサに転送します。
VPC ネットワーク全体に適用されます。

サブネットまたはサブネットのセカンダリ IP アドレス範囲の作成、変更、削除を行うと、Google Cloud によって自動的に作成、更新、削除されます。
カスタムルート
静的ルート
さまざまな宛先をサポートします。
パケットを静的ルートのネクストホップに転送します。 静的ルートのネクストホップの詳細については、次の考慮事項をご覧ください。
動的ルート
サブネット ルートまたは静的ルートと競合しない宛先
Cloud Router での BGP セッションのピア ルートは、VPC ネットワーク内の Cloud Router によって自動的に追加、削除されます。

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

ピア ネットワークでサブネットが作成、変更、削除されると、Google Cloud によって自動的に作成、更新、削除されます。
ピアリング カスタムルート
VPC ネットワーク ピアリングで接続されたネットワーク内のカスタム静的ルートまたはカスタム動的ルート
ピア VPC ネットワークのネクストホップ ピア ネットワークの静的ルートに基づくピアリング カスタムルートは次のように適用されます。
  • ネットワーク タグを使用するピア ネットワーク内の静的ルートは、ピアリング カスタム ルートとしてインポートされません。
  • デフォルトのインターネット ゲートウェイのネクストホップを使用するピア ネットワーク内の静的ルートは、ピアリング カスタム ルートとしてインポートされません。
  • 内部 TCP / UDP ロードバランサ ネクストホップを使用するピア ネットワーク内の静的ルートは、グローバル アクセスが有効かどうかによって、1 つのリージョンのみ、またはすべてのリージョンに適用できます。詳細については、内部 TCP / UDP ロードバランサのネクストホップに関する考慮事項をご覧ください。
ピア ネットワーク内の動的ルートを利用するピアリング カスタムルートは、そのルートをインポートする VPC ネットワークの動的ルーティング モードに従って適用されます。

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

VPC ネットワークを作成すると、システム生成の IPv4 デフォルト ルート0.0.0.0/0)が組み込まれます。サブネットで外部 IPv6 アドレスを有効にすると、システム生成の IPv6 のデフォルト ルート(::/0)がその VPC ネットワークに追加されます。デフォルト ルートは次の目的で使用されます。

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

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

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

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

    IPv6 のデフォルト ルートを削除すると、VM は IPv6 アドレスを使用して他のリージョンの VM に接続できなくなります。

サブネット ルート

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

各サブネットには 1 つ以上のサブネット ルートがあり、その宛先はサブネットのプライマリ IP 範囲と一致します。サブネットにセカンダリ IP 範囲がある場合は、セカンダリ IP アドレス範囲ごとに対応するサブネット ルートがあります。サブネット 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/2510.70.1.0/24 に収まる他の宛先に向かう新しいカスタム静的ルートを作成することはできません。

  • 逆に、Google Cloud では、宛先が既存のカスタム静的ルートと完全に一致するか、既存のカスタム静的ルートよりも広い範囲(既存のカスタム静的ルートが含まれる)を持つ新しいサブネット ルートやピアリング サブネット ルートを作成することはできません。たとえば、VPC ネットワークに 10.70.1.128/25 に向かうカスタム静的ルートがある場合、Google Cloud では、10.70.1.128/2510.70.1.0/2410.70.1.128/25 内のすべての IP アドレスを含む他の範囲のプライマリまたはセカンダリ サブネット IP 範囲を持つサブネット ルートやピアリング サブネット ルートは作成できません。

カスタム動的ルートとの相互作用

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

  • Cloud Router がサブネット ルートやピアリング サブネット ルートの宛先と完全に一致するプレフィックスを学習した場合、Google Cloud では、こうしたカスタム動的ルートは無視されます。たとえば、10.70.1.0/24 に向かうサブネット ルートまたはピアリング サブネット ルートが存在し、VPC ネットワーク内にある 1 つ以上の Cloud Router が BGP 経由で 10.70.1.0/24 のプレフィックスを受信すると、Google Cloud ではサブネット ルートまたはピアリング サブネット ルートが使用され、競合するサブネット動的ルートは無視されます。

  • Cloud Router がサブネット ルートやピアリング サブネット ルートの宛先に収まるプレフィックスを学習した場合、Google Cloud では、こうしたカスタム動的ルートは無視されます。たとえば、10.70.1.0/24 に向かうサブネット ルートまたはピアリング サブネット ルートが存在し、VPC ネットワーク内にある 1 つ以上の Cloud Router が BGP 経由で 10.70.1.0/25 のプレフィックスを受信すると、Google Cloud では、サブネット ルートやピアリング サブネット ルートが使用され、競合するサブネット動的ルートは無視されます。

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

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

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

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

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

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

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

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

静的ルート

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

動的ルート

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

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

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

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

ただし、動的ルートの宛先には、サブネットの IP 範囲を含める(それよりも小さいサブネット マスクを持つ)ことができます。たとえば、サブネット IP 範囲が 10.10.10.0/24 の場合、宛先が 10.10.10.0/23 の動的ルートを使用できます。パケットの宛先 IP アドレスがサブネット ルートの宛先内に収まらない場合、パケットは動的ルートのネクストホップに送信されます。最も広範囲な宛先は 0.0.0.0/0 です。

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

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

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

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

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

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

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

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

ピアリング ルートは、特別なリターンパスの一部である送信元からのトラフィックについては考慮されません。ネクストホップのインスタンスまたは転送ルールに限定が緩いルート(例: 0.0.0.0/0)と、特別なリターンパスの送信元 IP アドレスからのトラフィックの宛先 IP アドレスを含むピアリング ルートがある場合、このトラフィックはピアリングされた VPC に転送されず、限定が緩いルートにルーティングされます。

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

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

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

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

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

ピアリング ルートは、特別なリターンパス IP 範囲の一部である送信元からのトラフィックについては考慮されません。詳細については、サブネット ルートのピアリングをご覧ください。

適用範囲と順序

適用可能なルート

各インスタンスには適用可能なルートのセットがあります。これは、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 ネットワークの外部から始まる場合があります。詳細については、ロードバランサのリターンパスをご覧ください。

ルーティング順序

以下のプロセスは、VPC ネットワーク ルート選択の動作をモデル化したものです。Google Cloud がパケットに対して行うルート選択の判断は、前のセクションで説明した適用可能なルートのセットから始め、このプロセスに従ってモデル化できます。

  1. 最も狭い範囲の宛先: まず、Google Cloud は、適用可能なルートの中から、パケットの宛先 IP アドレスを含む最も狭い範囲の宛先のルートを特定します。宛先が具体的でない他のルートはすべて無視されます。たとえば、10.240.1.0/2410.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 は内部アルゴリズムを使用して、最も狭い範囲の宛先に向かうネクストホップを持つ単一のピア ネットワークを選択します。ルートの優先度は、この時点では考慮されません。また、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 候補 内部 TCP / UDP ロードバランサのネクストホップを持つ単一のカスタム静的ルート。
    Google Cloud は、内部アルゴリズムを使用して単一のネクストホップ内部 TCP / UDP ロードバランサを選択し、優先度が同じ他の内部 TCP / UDP ロードバランサ ネクストホップを無視します。詳細については、内部 TCP / UDP ロードバランサのネクストホップに関する考慮事項の「同じ宛先と複数のネクストホップの内部 TCP / UDP ロードバランサ」をご覧ください。
    第 4 候補 default-internet-gateway ネクストホップを使用するカスタム静的ルート。

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

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

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

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

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

特別なリターンパス

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 範囲が 10.10.10.0/24 の場合、宛先が 10.10.10.0/23 の静的ルートを使用できます。パケットの宛先 IP アドレスがサブネット ルートの宛先内に収まらない場合、パケットは静的ルートのネクストホップに送信されます。最も広範囲な宛先は 0.0.0.0/0 です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • インスタンス名によるネクストホップ(next-hop-instance: ルートとネクストホップ インスタンスの両方が同じプロジェクト内にある場合、その名前とゾーンを使用して、ネクストホップ インスタンスを指定できます。Google Cloud では、ルートを作成する前にネクストホップ インスタンスが存在し、次のすべての条件を満たしている必要があります。

    • インスタンスの名前が、ルートのネクストホップの VM 名と一致している必要があります。
    • インスタンスのゾーンが、ルートのネクストホップのゾーンと一致している必要があります。
    • ルートの VPC ネットワークに、インスタンスのネットワーク インターフェースが 1 つ存在している必要があります。

    次の場合、Google Cloud は、ネクストホップが next-hop-instance によって指定されているルートを自動的に更新します。

    • ネクストホップ インスタンスの IPv4 アドレスが変更された場合
    • ネクストホップ インスタンスを置き換えた場合(置き換え後のインスタンスが置き換えられたインスタンスと同じ条件を満たしている限り)
  • ネクストホップ インスタンスの内部 IP アドレス(next-hop-address: ルートの VPC ネットワークのネットワーク インターフェースに関連付けられた内部 IPv4 アドレスを使用して、ネクストホップ インスタンスを指定できます。Google Cloud では、ルートを作成する前にネクストホップ インスタンスが存在し、次のすべての条件を満たしている必要があります。

    • ルートの VPC ネットワークに、インスタンスのネットワーク インターフェースが 1 つ以上存在している必要があります。
    • インスタンスのネットワーク インターフェースには、ルートのネクストホップ アドレスと一致する内部 IPv4 アドレスが必要です。内部 IPv4 アドレスは、ネットワーク インターフェースのプライマリ IPv4 アドレスか、ネットワーク インターフェースのエイリアス IP 範囲の IPv4 アドレスのいずれかです。

    IPv4 アドレスが別の VM に移動したときに、置き換え用の VM が上記の条件を満たしていると、Google Cloud は、ネクストホップが next-hop-address によって指定されたルートを自動的に更新します。

  • 共有 VPC サービス プロジェクトでのネクストホップ: ネクストホップ インスタンスがサービス プロジェクトにある共有 VPC ネットワークにルートを作成する必要がある場合は、next-hop-address を使用して、ネクストホップを指定する必要があります。next-hop-instance を使用してネクストホップを指定することはできません。

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

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

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

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

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

  • インスタンスが停止または削除された場合の動作: Google Cloud では、ネクストホップ インスタンスの指定方法(next-hop-instance またはnext-hop-address)にかかわらず、その停止や削除を妨げることはありません。Google Cloud は、ルーティング順序の選好分類ステップで停止または削除されたすべてのインスタンスを破棄します。次の例でこの動作を説明します。

    • 192.168.168.0/24 に向かう 3 つのカスタム静的ルートがあり、1 つ目はネクストホップ VM が停止しており、優先度が 10、2 つ目はネクストホップ VM が動作しており、優先度が 20、3 つ目はネクストホップ VM が動作しており、優先度が 30 とします。Google Cloud は、ネクストホップ VM が停止しているルートより優先順位が低い場合でも、2 つ目の VM にパケットを送信します。1 つ目のネクストホップで VM を起動すると、Google Cloud は 1 つ目のルートを使用します。

    • 上記の 3 つのカスタム静的ルートがあり、すべてのネクストホップ VM が停止または削除されたとします。Google Cloud は、ネクストホップ VM が実行されているかどうかを判断する前に宛先の限定性を考慮するため、動作しているネクストホップを持つ範囲の緩いルートが存在しても、パケットは破棄されます。

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

  • グローバル アクセスの影響。内部 TCP / UDP ロードバランサのネクストホップを使用するカスタム静的ルートは、すべてのリージョンでプログラムされます。ネクストホップを使用できるかどうかは、ロードバランサのグローバル アクセスの設定によって異なります。グローバル アクセスを有効にすると、VPC ネットワークのすべてのリージョンでロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、ロードバランサと同じリージョンでのみロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、内部 TCP / UDP ロードバランサのネクストホップを使用して別のリージョンからルートに送信されるパケットは、破棄されます。
  • すべてのバックエンドが異常な場合。内部 TCP / UDP ロードバランサのすべてのバックエンドでヘルスチェックに失敗した場合でも、そのロードバランサのネクストホップを使用したルートは引き続き有効です。ルートで処理されるパケットは、トラフィック分配に従って、ネクストホップ ロードバランサのバックエンドの 1 つに送信されます。

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

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

    宛先が同じで、内部 TCP / UDP ロードバランサのネクストホップが異なる場合
    宛先が同じで、内部 TCP / UDP ロードバランサのネクストホップが異なる場合
  • 複数の宛先で、ネクストホップの内部 TCP / UDP ロードバランサが同じ場合。

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

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

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

    共通の内部 TCP / UDP ロードバランサのネクストホップを使用した、タグ付けられていないルートの例
    共通の内部 TCP / UDP ロードバランサのネクストホップを使用した、タグ付けられていないルートの例
  • インスタンス タグ

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

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

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

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

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

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

次のステップ