静的ルート
このページでは、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 表記です。
静的ルートの宛先は、静的ルートとの相互作用とサブネットと静的ルートの相互作用に記載されたルールに従う必要があります。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 アドレスか、内部または外部 IPv6 アドレスによって識別されるネクストホップ VM にパケットを送信します。詳しくは、ネクストホップ インスタンスに関する考慮事項をご覧ください。 |
（プレビュー） | ||
転送ルール名（next-hop-ilb）とリージョン（next-hop-ilb-region）によるネクストホップの内部パススルー ネットワーク ロードバランサ転送ルールの名前、リージョン、プロジェクトで識別される内部パススルー ネットワーク ロードバランサのバックエンドにパケットを送信します。詳細については、内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項をご覧ください。 |
（プレビュー） | ||
アドレスによるネクストホップ内部パススルー ネットワーク ロードバランサ（next-hop-ilb）ロードバランサの転送ルールの IP アドレスによって識別される内部パススルー ネットワーク ロードバランサのバックエンドにパケットを送信します。詳細については、内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項をご覧ください。 |
（プレビュー） | ||
ネクストホップの Classic VPN トンネル（next-hop-vpn-tunnel）ポリシーベース ルーティングまたはルートベースの VPN を使用して、ネクストホップの Classic VPN トンネルにパケットを送信します。詳しくは、Classic VPN トンネルのネクストホップに関する考慮事項をご覧ください。 |
ネクストホップのプロジェクトとネットワーク
静的ルートのネクストホップは、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）: 有効なネクストホップ 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 ネットワークを接続する際に対称ハッシュがない: Google Cloud では、次の条件をすべて満たす構成で、複数のネットワーク インターフェースを持つ 2 つ以上のネクストホップ VM を使用する場合、対称ハッシュを提供しません。
- 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 が実行されていないため、宛先が192.168.168.0/24に収まるパケットがドロップされます。ただし、ネクストホップ VM が実行されている、より広範な192.168.0.0/16宛先のルートは存在します（route-z）。これは、Google Cloud のルーティング順序で「最も具体的な宛先」ステップが「使用できないネクストホップを含む静的ルートおよび動的ルートを無視する」ステップの前に来るからです。
内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項
サポートされている転送ルールGoogle Cloud では、ネクストホップの内部パススルー ネットワーク ロードバランサの転送ルールのみがサポートされています。Google Cloud では、他のロードバランサ、プロトコル転送で使用される、または Private Service Connect エンドポイントとして使用されるネクストホップ転送ルールはサポートされていません。
指定方法および転送ルール ネットワークとプロジェクト。ネクストホップ転送ルールは、次の 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 ネットワークになります。転送ルールは、転送ルールのネットワークを含むプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）、または共有 VPC サービス プロジェクトに配置できます。
グローバル アクセスの影響。内部パススルー ネットワーク ロードバランサのネクストホップを使用するカスタム静的ルートは、すべてのリージョンでプログラムされます。ネクストホップを使用できるかどうかは、ロードバランサのグローバル アクセスの設定によって異なります。グローバル アクセスを有効にすると、VPC ネットワークのすべてのリージョンでロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、ロードバランサと同じリージョンでのみロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、内部パススルー ネットワーク ロードバランサのネクストホップを使用して別のリージョンからルートに送信されるパケットは、破棄されます。
すべてのバックエンドが異常な場合。内部パススルー ネットワーク ロードバランサのすべてのバックエンドでヘルスチェックに失敗した場合でも、そのロードバランサのネクストホップを使用したルートは引き続き有効です。ルートで処理されるパケットは、トラフィック分配に従って、ネクストホップ ロードバランサのバックエンドの 1 つに送信されます。
共通の内部 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 ドキュメントのトンネルがダウンした場合をご覧ください。