Google Cloud でのルーティング: VM から送信される IP パケットの可能な宛先
Manjuram Perumalla
Customer Solutions Engineer
※この投稿は米国時間 2024 年 9 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Cloud の Virtual Private Cloud（VPC）ネットワークでのルーティングには、分散、スケーラブル、仮想化という特性があり、ネットワークに接続されたルーティング デバイスはありません。Google Cloud は、仮想マシンからの直接ネットワーク トラフィックを VPC ネットワークの内部または外部の宛先にルーティングします。他のクラウド プロバイダとは異なるこのアプローチは、ソフトウェアのデータ、コントロール、管理の各機能の分離、ネットワーク管理の簡素化、ネットワーク インフラストラクチャの変更の迅速化によって、ネットワークの信頼性を高めます。これにより、企業が製品やサービスを市場に投入するまでに要する期間が短縮され、競争上の優位性が生まれます。
このブログ記事では、シームレスなアクセスを可能にするため、仮想マシン（VM）の観点から利用可能な幅広いルーティング・オプションについて説明します。これには以下が含まれます。
-
同一の VPC やピアリングされた VPC 内でデプロイされたアプリケーション（マイクロサービスまたは VM ベース）
-
Google Cloud で提供されているマネージド サービス（BigQuery、Cloud SQL、Vertex AI プラットフォームなど）
-
Google Cloud でホストされている SaaS ソリューション
-
オンプレミスまたは他のクラウド ハイパースケーラーでホストされているサービス
-
インターネットを通じてアクセスできる公開サービスや限定公開サービス
また、ポリシーベースのルートを使用して Google Cloud の VPC 内でのトラフィック検査を行う方法についても説明します。
ルートタイプとネクストホップ
Google Cloud のルートは、クラスレス ドメイン間ルーティング（CIDR）形式の宛先プレフィックス、ネクストホップ、優先度の 3 つの主要要素で構成されます。ポリシーベースのルートでは、宛先 IP アドレスのみを使用するのではなく、プロトコルや送信元 IP アドレスなどの追加要素に基づいてネクストホップを選択できるため、ファイアウォールなどのアプライアンスをネットワーク トラフィック パスに挿入できます。
下の図は、Google Cloud 内の仮想マシンから発信されるパケットの可能なネクストホップ宛先を示しています。これには、仮想マシン、IP アドレス、ロードバランサ、VPN トンネルなどの宛先が含まれます。また、この図は Google Cloud 内で利用できるさまざまなタイプのルートも示しています。
図 1: VM からのパケットのルートタイプとホップ オプション（クリックして拡大）
以下のセクションでは、さまざまなタイプのルートと各ルートタイプのネクストホップ、およびそれらのユースケースについて説明します。
システム生成ルート
1a. サブネット ルートサブネット ルートは、VM、Private Service Connect（PSC）エンドポイント、VPC ネットワーク内の内部ロードバランサなどのリソースに対して構成された Google Cloud サブネットと一致する宛先へのパスを指定します。これは、サブネットのライフサイクルに関連して作成され、削除されます。サブネット ルートには、ローカル、ピアリング、Network Connectivity Center の 3 つのタイプがあります。
複数のサービスを利用する e コマース アプリケーションを開発していると想像してみてください。注文を処理するクライアント マシンと同じサブネット内で、以下を含む複数のサービスと簡単に通信できます。
-
同じサブネットでホストされている商品カタログ サービス
-
別のサブネットでホストされているロードバランスされた注文検証サービス
-
別の VPC / 組織内にあり、PSC エンドポイントを使用するサードパーティの決済処理サービス
-
Network Connectivity Center ハブの VPC スポークでホストされる共通の出荷処理サービス - VPC スポーク間（vpc1 と Network Connectivity Center ハブの他の VPC ネットワーク間）で IP アドレスが重複していても、Private NAT を使用してアクセス可能
Google Cloud はこれらすべてのシナリオですぐに使用できるルーティングを提供しているため、ルートに関する追加のカスタム構成は不要です。
1b. システム生成のデフォルト ルートVPC ネットワークを作成すると、宛先の範囲が最も広いデフォルト ルート 0.0.0.0/0 と、ネクストホップとしてのデフォルト インターネット ゲートウェイが生成されます。デフォルト インターネット ゲートウェイによって、リモート IP アドレス、デフォルト ドメインの Google API、プライベート ドメイン private.googleapis.com および restricted.googleapis.com へのアクセスが円滑になります。
このデフォルト ルートは削除することも、より具体的な宛先や異なるネクストホップが指定されたカスタム静的ルートに置き換えることもできます。たとえば、プライベート ドメイン（private.googleapis.com）を使用して Google API にアクセスするには、デフォルト インターネット ゲートウェイをネクストホップとする 199.36.153.8/30 の静的ルートを作成します。詳細については、システム生成のデフォルト ルートをご確認ください。
カスタムルート
2a. 静的ルートニーズに応じて、指定された宛先 CIDR 範囲の静的ルートを作成できます。このルートは、デフォルト インターネット ゲートウェイ、仮想マシン（VM）、IP アドレス、VPN トンネル、内部パススルー ロードバランサなど、さまざまな宛先にパケットを送信できます。これにより、パケットのパスを制御し、ネットワーク トラフィック フローを最適化できます。宛先 CIDR 範囲が、ローカル、ピアリング、Network Connectivity Center の各サブネット ルートと競合しないようご注意ください。詳細については、静的ルートに関するドキュメントをご覧ください。
VPC1 のルートテーブル:
2b. 動的ルート動的ルートは、Border Gateway Protocol（BGP）を介して受信したメッセージに基づいて、Cloud Router で作成、更新、削除されます。ネクストホップは VLAN アタッチメント、Cloud VPN トンネル、Network Connectivity Center のルーター アプライアンス VM インスタンスのいずれかにできます。これらの動的ルートは、VPC ルーティング モード（リージョンまたはグローバル）に応じて、単一リージョン内のリソースか、VPC ネットワークの全リージョンのリソースに適用されます。HA VPN ゲートウェイを作成して 2 つの VPC ネットワークを接続し、ネットワーク間でルートを動的に交換するには、HA VPN ゲートウェイを作成して VPC ネットワークに接続するをご覧ください。
以下は、BGP セッションを介して受信した動的ルートの例です。
VPC ネットワーク ピアリング ルート
VPC ネットワークが VPC ピアリングを介して別の VPC ネットワークに接続されると、ピアリングされたサブネット ルートによって、ピアリングされたネットワーク内のリソースにアクセスするためのパスが定義されます。サブネット ルートは常に交換され、無効にできません。ただし、プライベートで使用されるパブリック IPv4 アドレスを利用する IPv4 サブネット ルートは例外です。サブネット ルート、静的ルート、動的ルートをピアリングされたネットワークと共有するさまざまな方法については、ルート交換オプションに関するドキュメントをご覧ください。また、ピアリング ルートタイプに基づく、ネットワークやピアリング グループあたりのサブネット ルート、静的ルート、動的ルートの数の割り当てがあることにご注意ください。
us-east1 リージョンの VPC1 ルート:
us-east1 リージョンの VPC2 ルート:
Network Connectivity Center のルート
Network Connectivity Center は、ハブと呼ばれる一元管理リソースに接続されているスポーク リソース間のネットワーク接続を可能にします。Network Connectivity Center では、VPC とハイブリッド（VLAN、VPN トンネル、ルーター アプライアンス VM）の 2 種類のスポークがサポートされています。Network Connectivity Center を使用することで、VPC ネットワーク間、オンプレミスと VPC ネットワーク間（サイトツークラウド）、Google のネットワークを広域ネットワークとして使用する外部サイト間（サイトツーサイト）の接続を実現できます。
Network Connectivity Center のサブネット ルートは、Network Connectivity Center ハブに接続されている VPC スポーク内のサブネット IP アドレス範囲です。以下は、2 つの VPC スポーク（vpc1 をバッキングする ncc-spoke1 と vpc3 をバッキングする ncc-spoke2）のハブ（ncc-hub1）のネクストホップが指定された VPC ルートテーブルと Network Connectivity Center ハブ ルートテーブルの例です。各 VPC スポークの VPC ネットワーク ルートテーブルと Network Connectivity Center ハブ ルートテーブルは、Google Cloud によって自動的に更新されます。
1 つの VPC スポークは、他のスポークと CIDR 範囲が重複しているため、サブネットのエクスポートをスキップできます。gcloud コマンドを使用している場合は、–exclude-export-ranges オプションを使用してこの処理を実行できます。
VPC ネットワーク（vpc1）の VPC ルートテーブル
VPC ネットワーク（vpc3）の VPC ルートテーブル
ハブ ルートテーブル:
ポリシーベースのルート（PBR）
ここまで、パケットの宛先 IP アドレスに基づくネクストホップの指定方法を見てきました。ポリシーベースのルートでは、それに加え、パケットのプロトコルと送信元 IP アドレスに基づいてネクストホップを指定することもできます。この場合、トラフィックが内部パススルー ネットワーク ロードバランサにリダイレクトされることで、ファイアウォールなどのアプライアンスをネットワーク トラフィックのパスに挿入できます。これは、ポリシーベースのルートが他のルートより前に評価されるためです。ポリシーベースのルート以外のルートタイプでは、ローカル、ピアリング、Network Connectivity Center の各サブネット ルートの宛先と一致するか、その範囲内に含まれる宛先は許可されないことにご注意ください。
下の例の場合、デフォルトでは、ローカル サブネット ルートでトラフィックが VM1 から VM2 に送信されます。ポリシーベースのルートを追加すると、VM1 から VM2 へのトラフィックが L4 ロードバランサにリダイレクトされ、マネージド インスタンス グループで実装されたネットワーク仮想アプライアンス（NVA）にトラフィックが転送されます。NVA 内で、トラフィックは最終宛先である VM2 に到達する前に検査されます。
VPC1 のルートテーブル:
このポリシーベースのルートは、VM からの下り（外向き）トラフィックを検査するように拡張できますが、いくつかの例外があります。たとえば、ポリシーベースのルートを使用した Google API やサービスへのトラフィックのルーティングは、Google Cloud ではサポートされていません。
ポリシーベースのルートは、すべての VM やネットワーク タグによって選択された特定の VM に適用することも、Cloud Interconnect VLAN アタッチメントを介して VPC ネットワークに入るトラフィックに適用することもできます。また、ポリシーベースのルートは、VPC ネットワーク ピアリングを介して交換されることはありません。
特別なルートのパス
VPC ネットワークには、VPC ネットワーク ルートテーブルに表示されず、削除もできない特定のサービス用の特別なルートがあります。これには、外部パススルー ネットワーク ロードバランサやヘルスチェックへの応答などが含まれます。これらについても、VPC ファイアウォール ルールや Cloud NGFW ファイアウォール ポリシーを使用して、トラフィックを許可または拒否することはできます。
意思決定表
下の表は、仮想マシン（VM）が Google Cloud、オンプレミス、別のクラウドのいずれかでホストされているサービスにアクセスする可能性があるシナリオと、各シナリオで可能なルーティング オプションをまとめたものです。
まとめと次のステップ
このブログ投稿では、ワークロードのニーズに基づいてネットワーキング トポロジを開発できるよう、VM からのパケットに対して Google Cloud で利用できるさまざまなルートタイプについて説明しました。詳細については、一般公開ドキュメントの Google Cloud でのルーティングをご覧ください。次のステップとして、トラフィック検査にポリシーベースのルートを使用することも、ラボ: SD-WAN アプライアンスを使用して NCC サイトからクラウドへに記載されている Network Connectivity Center の機能の一部を実際に体験することもできます。
ー カスタマー ソリューション エンジニア、Manjuram Perumalla
