静的ルート
このページでは、 Google Cloudでの静的ルートの機能について説明します。
Google Cloudのルートの概要については、ルートの概要をご覧ください。
静的ルートを作成する際の考慮事項
静的ルートは次のいずれかの方法で作成できます。
静的ルートを手動で作成するには、Google Cloud コンソール、
gcloud compute routes create、またはroutes.insertAPI を使用します。Google Cloud コンソールを使用して、動的ルーティングを使用しない Classic VPN トンネルを作成すると、それに対応する静的ルートが Cloud VPN によって自動的に作成されることがあります。詳細については、Cloud VPN ネットワークとトンネル ルーティングをご覧ください。
VPC ネットワーク ピアリング ドキュメントのカスタム静的ルートの交換オプションで説明されているように、ピアリングされた VPC ネットワークと静的ルートを交換できます。
ルート パラメータ
静的ルートは、次の属性をサポートしています。
名前と説明。これらのフィールドでルートが識別されます。名前は必須ですが、説明は省略可能です。ルート名はプロジェクト内で一意にする必要があります。
ネットワーク。各ルートは、1 つの VPC ネットワークだけに関連付けられていなければなりません。
ネクストホップ。ネクストホップは、パケットの送信先のネットワーク リソースを識別します。すべてのネクストホップ タイプは IPv4 の宛先をサポートし、一部のネクストホップ タイプは IPv6 の宛先をサポートします。詳細については、ネクストホップと機能をご覧ください。
送信先の範囲。宛先の範囲は、単一の IPv4 または IPv6 の CIDR 表記です。
静的ルートの宛先は、サブネット ルートと静的ルートの相互作用および VPC ネットワーク ピアリングのサブネットと静的ルートの相互作用に記述されたルールに従う必要があります。IPv4 静的ルートの最も広い宛先は「
0.0.0.0/0」です。IPv6 静的ルートの最も広い宛先は「::/0」です。優先度。数字が小さいほど優先度が高くなります。最も高い優先度は
0で、最も低い優先度は65,535です。ネットワーク タグ。静的ルートは、ネットワーク タグによって識別される VPC ネットワーク内の一部の VM インスタンスにのみ適用できます。
ネットワーク タグのない静的ルートは、VPC ネットワーク内のすべてのリソース（すべての VM インスタンス、Cloud VPN トンネル、Cloud Interconnect VLAN アタッチメント、ルーター アプライアンス、プロキシ専用サブネット内の Envoy プロキシなど）に適用されます。
ネットワーク タグ付きの静的ルートは、そのネットワーク タグを持つ VM インスタンスにのみ適用されます。他のリソースには適用されません。
ネクストホップと機能
次の表は、ネクストホップのタイプ別の静的ルート機能のサポートをまとめたものです。
| ネクストホップのタイプ | IPv4 | IPv61 | ECMP2 |
|---|---|---|---|
ネクストホップ ゲートウェイ（next-hop-gateway）デフォルトのインターネット ゲートウェイを指定して、外部 IP アドレスのパスを定義します。 |
|||
名前とゾーンによるネクストホップ インスタンス（next-hop-instance）名前とゾーンによって識別され、ルートと同じプロジェクトにあるネクストホップ VM にパケットを送信します。詳しくは、ネクストホップ インスタンスに関する考慮事項をご覧ください。 |
|||
アドレスによるネクストホップ インスタンス（next-hop-address）ネットワーク インターフェースのプライマリ内部 IPv4 アドレスまたは内部または外部 IPv6 アドレスで識別されるネクストホップ VM にパケットを送信します。詳しくは、ネクストホップ インスタンスに関する考慮事項をご覧ください。 |
|||
転送ルール名（next-hop-ilb）とリージョン（next-hop-ilb-region）によるネクストホップの内部パススルー ネットワーク ロードバランサ転送ルールの名前、リージョン、および必要に応じてプロジェクトで識別される内部パススルー ネットワーク ロードバランサのバックエンドにパケットを送信します。詳細については、内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項をご覧ください。 |
|||
アドレスによるネクストホップ内部パススルー ネットワーク ロードバランサ（next-hop-ilb）ロードバランサの転送ルールの IP アドレスによって識別される内部パススルー ネットワーク ロードバランサのバックエンドにパケットを送信します。詳細については、内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項をご覧ください。 |
3 | ||
ネクストホップの Classic VPN トンネル（next-hop-vpn-tunnel）ポリシーベース ルーティングまたはルートベースの VPN を使用して、ネクストホップの Classic VPN トンネルにパケットを送信します。詳しくは、Classic VPN トンネルのネクストホップに関する考慮事項をご覧ください。 |
next-hop-gatewaynext-hop-instance
ネクストホップのプロジェクトとネットワーク
静的ルートのネクストホップは、VPC ネットワークとプロジェクトの両方に関連付けられます。
ネットワーク: 以下の表に示す状況を除き、ネクストホップの VPC ネットワークはルートの VPC ネットワークと一致する必要があります。
プロジェクト: 以下の表に示す状況を除き、ネクストホップは、そのネクストホップの VPC ネットワークを扱うプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）に配置する必要があります。ネクストホップによっては、共有 VPC サービス プロジェクトに配置できるものがあります。
| ネクストホップのタイプ | ピアリングされる VPC ネットワークに配置できる | Network Connectivity Center ハブの別の VPC スポークに配置できる | 共有 VPC サービス プロジェクトに配置できる |
|---|---|---|---|
ネクストホップのゲートウェイ（next-hop-gateway） |
|||
名前によるネクストホップ インスタンス（next-hop-instance） |
|||
アドレスによるネクストホップ インスタンス（next-hop-address） |
|||
転送ルールの名前とリージョンによるネクストホップの内部パススルー ネットワーク ロードバランサ（next-hop-ilb） |
|||
転送ルールのリソースリンクによるネクストホップの内部パススルー ネットワーク ロードバランサ（next-hop-ilb） |
|||
アドレスによるネクストホップ内部パススルー ネットワーク ロードバランサ（next-hop-ilb） |
IPv4 のみ |
||
ネクストホップの 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）: 有効なネクストホップ VM の IP アドレスは次のとおりです。- VM ネットワーク インターフェースのプライマリ内部 IPv4 アドレス。
- VM ネットワーク インターフェースに割り振られた
/96IPv6 アドレス範囲にある内部または外部の IPv6 アドレス。
IP アドレスで指定されたネクストホップ インスタンスを持つ静的ルートを作成すると、 Google Cloud は、ルートと同じ VPC ネットワーク内のサブネットのサブネット範囲で VM に割り振られた IP アドレスを受け入れます。ただし、 Google Cloud は、ネクストホップ アドレスが有効なネクストホップ VM IP アドレスである場合にのみ、ルートをプログラムします。たとえば、ルートを作成し、ネクストホップをエイリアス IP 範囲の IP アドレスとして指定すると、ルートが作成されます。ただし、そのエイリアスの IP アドレスは有効なネクストホップ VM の IP アドレスではないため、ルートはプログラムされません。
ネクストホップの IP アドレスが別の VM に移動しても、IP アドレスが有効なネクストホップ VM IP アドレスのままであれば、Google Cloud はネクストホップのプログラミングを自動的に更新します。
IP アドレスでネクストホップ インスタンスを指定すると、パケットは特定の IP アドレスではなく、インスタンスのネットワーク インターフェースに転送されます。
共有 VPC サービス プロジェクトのネクストホップ インスタンス: IP アドレスでネクストホップ VM を指定する場合、VM は、ルートと同じプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）か、共有 VPC サービス プロジェクトに配置できます。インスタンス名とゾーンでネクストホップ VM を指定する場合、ネクストホップ VM は、ルートおよび VPC ネットワークと同じプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）に配置する必要があります。
リージョン間のコストとレイテンシ: VM をネクストホップとして使用する場合、ネクストホップはリージョンのゾーンにあります。ネクストホップを使用するルートは、同じ VPC ネットワーク内のすべてのインスタンス、または一致するネットワーク タグを持つインスタンスで使用できます。 Google Cloud では、インスタンスをネクストホップとして使用するルートのリージョン間距離が考慮されないので、異なるリージョンのネクストホップ VM にトラフィックを送信するルートを作成できます。あるリージョンから別のリージョンにパケットを送信すると、アウトバウンド データ転送の費用が増加し、ネットワーク レイテンシが発生します。
ヘルスチェックや構成の検証がない: インスタンスと内部パススルー ネットワーク ロードバランサのネクストホップに共通する考慮事項のセクションに記述されたすべての要件をネクストホップ インスタンスが満たしているかどうかが Google Cloudでは確認されません。インスタンスのゲスト オペレーティング システムを構成することによって VM のネットワーク インターフェースを無効にしても、 Google Cloud ではネクストホップのインスタンスが無視されません。
2 つの VPC ネットワークを接続する際に対称ハッシュがない: 次の条件をすべて満たす構成で、複数のネットワーク インターフェースを持つ 2 つ以上のネクストホップ VM を使用していると、Google Cloud では対称ハッシュが提供されません。
- VM が、1 つの VPC ネットワークに 1 つのネットワーク インターフェースを持ち、もう 1 つの VPC ネットワークに別のインターフェースを備えている。
- 各 VPC ネットワークには、優先度と宛先が同じ 2 つ以上のカスタム静的ルートのセットがあり、セット内の各ルートは一意のネクストホップ VM を参照している。
複数のインターフェースがある 2 つ以上の VM を使用して VPC ネットワークを接続し、特定の接続に対して同じ VM が双方向でパケットを処理する必要がある場合は、ネクストホップの内部パススルー ネットワーク ロードバランサによってのみサポートされる対称ハッシュが必要です。詳細については、対称ハッシュをご覧ください。
- インスタンスが停止または削除されたときの動作: Google Cloud は、静的ルートのネクストホップ VM（名前とゾーン、または内部アドレスで指定）を停止する操作も削除する操作も妨げません。ネクストホップ VM が動作していない場合、ルーティングは、それと宛先がまったく同じ他のルートが存在するかどうか、およびそのルートに動作しているネクストホップがあるかどうかによって異なります。次の例で、この動作について説明します。
次のルートと VM の状態があります。
route-a、宛先192.168.168.0/24、優先度10、ネクストホップ VMvm-aが停止しているroute-b、宛先192.168.168.0/24、優先度20、ネクストホップ VMvm-bが実行されているroute-c、宛先192.168.168.0/24、優先度30、ネクストホップ VMvm-cが実行されている
この例では、優先度が最も高い
route-aのvm-aネクストホップが実行されていないため、宛先が192.168.168.0/24に収まるパケットはvm-bネクストホップに送信されます。このようになる理由は、「使用できないネクストホップを含む静的ルートおよび動的ルートを無視する」ステップが、「優先度の低いルートを無視する」ステップよりも、Google Cloud のルーティング順序で優先されることにあります。次のルートと VM の状態があります。
route-x、宛先192.168.168.0/24、優先度10、ネクストホップ VMvm-xが停止しているroute-y、宛先192.168.168.0/24、優先度20、ネクストホップ VMvm-yが停止しているroute-z、宛先192.168.0.0/16、優先度0、ネクストホップ VMvm-zが実行されている
この例では、2 つの
192.168.168.0/24ルート（route-xとroute-y）のネクストホップ VM が実行されていないため、ネクストホップ VM が実行されている広範な192.168.0.0/16宛先のルート（route-z）が存在していても、宛先が192.168.168.0/24に収まるパケットがドロップされます。このようになる理由は、「最も具体的な宛先」のステップが、「使用できないネクストホップを持つ静的ルートおよび動的ルートを無視する」ステップよりも、Google Cloud のルーティング順序で優先されることにあります。
内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項
サポートされている転送ルール。 Google Cloud は、ネクストホップの内部パススルー ネットワーク ロードバランサの転送ルールのみをサポートしています。他のロードバランサで使用されるネクストホップ転送ルール、プロトコル転送で使用されるネクストホップ転送ルール、Private Service Connect エンドポイントとして使用されるネクストホップ転送ルールを、 Google Cloud はサポートしていません。
指定方法および転送ルール ネットワークとプロジェクトネクストホップ転送ルールは、次の 3 つの方法のいずれかを使用して指定できます。使用する指定方法によって、転送ルールのネットワークをルートのネットワークと一致させる必要があるかどうかと、転送ルールを配置できるプロジェクトが決まります。
次のいずれかの方法を選択し、転送ルールの IP バージョンが、作成する静的ルートの IP バージョンと一致するようにします。
転送ルールの名前（
--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 サービス プロジェクトに配置できます。転送ルールの IP アドレスを使用: IPv4 アドレスまたは IPv6 アドレスでネクストホップ転送ルールを指定している場合、転送ルールのネットワークとすることができるのは、ルートの VPC ネットワーク、または VPC ネットワーク ピアリングか Network Connectivity Center を使用してルートの VPC ネットワークに接続されている VPC ネットワークです。Network Connectivity Center は、接続に関する Network Connectivity Center の要件に従って、VPC スポークのネクストホップ内部パススルー ネットワーク ロードバランサをサポートします。転送ルールは、その転送ルールのネットワークを扱うプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）、または任意の共有 VPC サービス プロジェクトに配置できます。
グローバル アクセスの影響。内部パススルー ネットワーク ロードバランサのネクストホップを使用するカスタム静的ルートは、すべてのリージョンでプログラムされます。ネクストホップを使用できるかどうかは、ロードバランサのグローバル アクセスの設定によって異なります。グローバル アクセスを有効にすると、VPC ネットワークのすべてのリージョンでロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、ロードバランサと同じリージョンでのみロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、内部パススルー ネットワーク ロードバランサのネクストホップを使用して別のリージョンからルートに送信されるパケットは、破棄されます。
すべてのバックエンドが異常な場合。内部パススルー ネットワーク ロードバランサのすべてのバックエンドでヘルスチェックに失敗した場合でも、そのロードバランサのネクストホップを使用したルートは引き続き有効です。ルートで処理されるパケットは、トラフィック分配に従って、ネクストホップ ロードバランサのバックエンドの一つに送信されます。
共通の内部 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 ドキュメントのトンネルがダウンした場合をご覧ください。
Network Connectivity Center の考慮事項
- VPC スポークから、Network Connectivity Center ハブを介してアクセス可能な内部パススルー ネットワーク ロードバランサへの静的ルートを作成できます。
- これらの Network Connectivity Center の静的ルートには、追加の制限が適用されます。詳細については、静的ルートの概要をご覧ください。