VPC ネットワーク ピアリングの概要

Google Cloud VPC ネットワーク ピアリングでは、同じプロジェクトまたは組織に属しているかどうかにかかわらず、2 つの Virtual Private Cloud(VPC)ネットワーク間でプライベート RFC 1918 接続を確立できます。

VPC ネットワーク ピアリングを使用すると、VPC ネットワークをピアリングして、さまざまな VPC ネットワーク内のワークロードの通信を RFC 1918 規定のプライベート空間で行えます。トラフィックは Google のネットワーク内に留まり、公共のインターネットを経由することはありません。

VPC ネットワーク ピアリングは、次のような場合に役立ちます。

  • Google Cloud の SaaS(Service-as-a-Service)エコシステムを使用する場合。組織内や複数の組織にあるさまざまな VPC ネットワークで非公開にサービスを使用できます。
  • 複数のネットワーク管理ドメインを持つ組織が相互にピアリングできる場合。

組織内に複数のネットワーク管理ドメインが存在する場合、VPC ネットワーク ピアリングを利用すると、RFC 1918 規定のプライベート空間で VPC ネットワーク全体にサービスを提供できます。他の組織にサービスを提供する場合、VPC ネットワーク ピアリングを利用すると、RFC 1918 規定のプライベート空間で他の組織にサービスを提供できます。組織を超えてサービスを提供できれば、他の企業にサービスを提供することが可能になります。また、合併吸収の結果あるいは独自の要件のために、自社内に複数の組織ノードが存在する場合にも便利です。

VPC ネットワーク ピアリングは、ネットワークを接続するうえで外部 IP アドレスや VPN を使用するより次の点で優れています。

  • ネットワークのレイテンシ: パブリック IP ネットワークでは、プライベート ネットワークよりもレイテンシが大きくなります。すべてのピアリング トラフィックは Google のネットワーク内に留まります。
  • ネットワークのセキュリティ: サービス オーナーは、サービスをインターネットに公開して関連するリスクに対処する必要がありません。
  • ネットワークのコスト: Google Cloud では、同じゾーン内のトラフィックであっても、外部 IP を使用して通信するネットワークに対して下り(外向き)帯域幅の料金が発生します。ただし、ネットワークがピアリングされている場合、内部 IP を使用して通信することで、このような下り(外向き)のコストを節約できます。この場合でも、通常のネットワーク料金はすべてのトラフィックに適用されます。

ピアリング接続の作成については、VPC ネットワーク ピアリングの使用をご覧ください。

基本特性

ピアリングされる VPC ネットワークには次のような特性があります。

  • VPC ネットワーク ピアリングは、Compute EngineGKEApp Engine フレキシブル環境で動作します。
  • ピアリングされる VPC ネットワークの管理は別々に行います。ルート、ファイアウォール、VPN などのトラフィック管理ツールは、各 VPC ネットワークで別々に管理し、適用します。
  • ピアリングの両側は別々に設定されます。両側の構成が一致する場合にのみ、ピアリングが有効になります。ピアリング関係はいつでも削除できます。どちらの側でも実行できます。
  • ピアリングの構成と、カスタムルートをインポートおよびエクスポートするための構成は、一方の VPC ネットワークが作成されていない場合でも、他方の VPC ネットワークに対して行えます。ルート交換は両側が構成された後にのみ行われます。
  • VPC のピア同士は、常にすべてのサブネット ルートを交換します。また、ピアリング構成でカスタムルート(静的ルートと動的ルート)をインポートまたはエクスポートできるよう構成している場合は、カスタムルートを交換することもできます。詳細については、カスタムルートのインポートとエクスポートをご覧ください。
  • サブネット ルートと静的ルートはグローバルです。動的ルートは、VPC ネットワークの動的ルーティング モードに応じて、リージョングローバルのいずれかになります。
  • 1 つの VPC ネットワークを複数の VPC ネットワークにピアリングできますが、上限があります。
  • VPC ネットワーク ピアリングの作成と削除のための IAM 権限は、プロジェクト所有者、プロジェクト編集者、ネットワーク管理者の役割に含まれています。
  • ピアリング トラフィック(ピアリングされるネットワーク間で送受信されるトラフィック)のレイテンシ、スループット、可用性は、同じネットワーク内のプライベート トラフィックと同様です。
  • ピアリング トラフィックの請求ポリシーは、同じネットワーク内のプライベート トラフィックの請求ポリシーと同じです。
  • 組織のポリシー管理者は組織ポリシーを使用して、組織内の VPC ネットワークとピアリングできる VPC ネットワークを制限できます。特定の VPC ネットワーク、または特定のフォルダや組織内の VPC ネットワークへのピアリング接続を拒否できます。この制約は新しいピアリング構成に適用され、既存の接続には影響しません。新しいポリシーによって新しい接続が拒否された場合も、既存のピアリング接続は引き続き機能します。詳細については、constraints/compute.restrictVpcPeering 制約をご覧ください。

制限事項

VPC ネットワークとピアリングする際は、次の制限事項を考慮してください。

  • ピアリングされる一方の VPC ネットワーク内のサブネット CIDR 範囲とピアリングされる他方のネットワーク内の静的ルートは重複できません。このルールは、サブネット ルートと静的ルートの両方に適用されます。Google Cloud は次の状況で重複が発生していないか確認し、重複が発生した場合にエラーを生成します。
    • 初めて VPC ネットワークをピアリングする場合
    • ピアリングされる VPC ネットワークで静的ルートを作成する場合
    • ピアリングされる VPC ネットワーク内に新しいサブネットを作成する場合
  • 動的ルートはピア ネットワーク内のサブネット ルートと重複できます。動的ルートの場合、ピア ネットワークのサブネット ルートと重複する宛先範囲は暗黙的にドロップされます。Google Cloud はサブネット ルートを使用します。
  • VPC ネットワーク ピアリングでは VPC ネットワークのみがサポートされます。レガシー ネットワークでは、ピアリングはサポートされていません。
  • サブネット ルートの交換の無効化や、交換するサブネット ルートの選択はできません。ピアリングが確立されると、サブネット IP アドレス内のリソースはすべて、直接ピアリングされるネットワーク全体でアクセス可能になります。VPC ネットワーク ピアリングでは、どのサブネット CIDR 範囲がピアリングされるネットワーク間で到達可能かをフィルタするような、細かなルート管理は行われません。ルート管理が必要であれば、トラフィックをフィルタするファイアウォール ルールを使用する必要があります。直接ピアリングしたネットワーク間では、次の種類のエンドポイントとリソースに到達できます。
    • すべてのサブネットの仮想マシン(VM)の内部 IP
    • すべてのサブネットで内部負荷分散された IP
  • 通信できるのは、ダイレクト ピアリングしたネットワークだけです。推移的ピアリングはサポートされていません。たとえば、VPC ネットワーク N1 が N2 と N3 にピアリングされ、N2 と N3 が直接接続されていない場合、VPC ネットワーク N2 は VPC ネットワーク ピアリング経由で VPC ネットワーク N3 と通信できません。
  • ピアリングされる一方のネットワークのタグまたはサービス アカウントを他方のネットワーク内で使用することはできません。
  • ネットワークで作成した Compute Engine 内部 DNS 名で、ピアリングされるネットワークにはアクセスできません。ピアリングされるネットワーク内の VM インスタンスにアクセスするには、IP アドレスを使用してください。
  • デフォルトでは、GKE との VPC ネットワーク ピアリングは IP エイリアスで使用する場合にサポートされます。IP エイリアスを使用しない場合は、カスタムルートをエクスポートすることで、ピアリングされるネットワークから GKE コンテナにアクセスできます。

ルーティング順序

別のネットワークとピアリングしてルートを交換すると、VPC ネットワークでルートの宛先の競合が生じる場合があります。Google Cloud がルーティング順序を決定する方法については、ルーティング順序をご覧ください。

カスタムルートのインポートとエクスポート

デフォルトでは、ピアリングされるネットワーク間で常にサブネット ルートが交換されます。双方のネットワークのネットワーク管理者が適切にピアリングを構成している場合、カスタムルート(静的ルートと動的ルートを含む)も交換できます。

カスタムルートをインポートする場合、こちら側の VPC ネットワークでピア ネットワークからカスタムルートを受け取れるのは、ピア ネットワークがカスタムルートをエクスポートするように設定されている場合だけです。同様に、カスタムルートをエクスポートする場合、ピア ネットワークでカスタムルートを受け取れるのは、そのネットワークがカスタムルートをインポートするように設定されている場合だけです。

カスタムルートをインポートまたはエクスポートする場合、ネットワークでは直接のピアとのみカスタムルートを交換できます。たとえば、VPC ネットワークが複数のネットワークとピアリングされている場合、ピアリングされるネットワークの 1 つからインポートされたルートは、ピアリングされる別のネットワークにはエクスポートされません。

ピアリング構成の作成や変更を行う場合、ルートのインポートとエクスポートのどちらか、または両方を選択できます。ピア ネットワークの管理者も、ルートを交換する前に同様にピアリング構成を行う必要があります。このプロセスを通じて、双方のネットワーク管理者の明示的な同意を得るまで、カスタムルートの交換が行われないようにできます。

カスタムルートの交換によるメリット

ピアリングされる VPC ネットワークとカスタムルートを共有すると、そのネットワークから直接ルートを学習できます。たとえば、ピアリングされるネットワークでカスタムルートが更新された場合、こちら側の VPC ネットワークは、更新されたカスタムルートを自動的に学習して使用します。ユーザーの操作は必要ありません。

カスタムルートの交換は、次のような状況に役立ちます。

  • VPC ネイティブ アドレスのない GKE クラスタを使用している場合、コンテナをホストする VM インスタンスにトラフィックを送信するための静的ルートが複数存在する場合があります。これらの静的ルートをエクスポートすることで、ピアリングされるネットワークからそのコンテナに到達できます。
  • VPN トンネルまたは相互接続を使用している場合、カスタムルートを共有することで、ピア ネットワークがこちらのオンプレミス ネットワークに到達できます。動的ルートの場合、Cloud Router のカスタムルート アドバタイズをこちら側の VPC ネットワークに追加して、ピアリングされるネットワークのサブネットをオンプレミス ネットワークに通知する必要があります。

考慮事項

カスタムルートのインポートまたはエクスポートを構成する際は、次の動作について考慮してください。

  • 静的ルートと動的ルートの両方がインポートまたはエクスポートされます。1 種類のルートだけを選んでインポートまたはエクスポートすることはできません。
  • 1 つの VPC ネットワークからインポートされたカスタムルートを、ピアリングされる別の VPC ネットワークに推移的にエクスポートすることはできません。
  • 次のルートはインポートとエクスポートから除外されます。
    • タグ付けされたルートがピア ネットワーク間で交換されることはありません。タグ付けされたルートとは、ネットワーク タグで特定の VM インスタンスにスコープされたカスタム静的ルートです。ネットワーク タグは、ネットワーク タグが作成された VPC ネットワークでのみ解決できます。
    • デフォルト インターネット ゲートウェイへのネクストホップを持つ静的ルートが交換されることはありません。たとえば、デフォルト インターネット ゲートウェイのネクストホップを持つデフォルト ルート(0.0.0.0/0)はピア ネットワーク間で交換されません。
  • インポートされたルートによって、ルーティング順序の変更など、トラフィック フローが意図せずに変更される場合があります。詳細については、ルーティング順序をご覧ください。
  • VPC ネットワークがピア ネットワークからカスタムルートをインポートする場合、宛先範囲はそのままインポートされます。ただし、インポートされたルートのネクストホップにはピアリング接続の名前が設定されます。トラフィックは、実際のネクストホップが定義されているピアリングされるネットワークにルーティングされます。

VPC ネットワーク ピアリングのネットワーク機能

この後のセクションでは、特定の状況で VPC ネットワーク ピアリングがどのように動作するかを紹介します。

ピアリング時にサブネットが重複している場合

ピアリング時に、Google Cloud は 2 つの VPC ネットワーク間またはピアリングされるネットワークでサブネットの IP 範囲が重複していないことを確認します。重複がある場合、ピアリングは確立しません。VM インスタンス間でフルメッシュ接続が構成されるため、ピアリングされる VPC ネットワークのサブネットで IP 範囲が重複していると、ルーティングで問題が発生します。

2 つのピアでのサブネット IP 範囲の重複(クリックで拡大)
2 つのピアでのサブネット IP 範囲の重複(クリックで拡大)

特定の VPC ネットワークのピア間でサブネット IP 範囲が重複していると、ルーティングで競合が発生します。たとえば、VPC ネットワーク N1 が VPC ネットワーク N2 とピアリングしているときに、VPC ネットワーク N3 が N2 とのピアリングを試みたとします。N3 のサブネット Subnet_5 がネットワーク N1 の Subnet_1 と IP 範囲が重複しているため、このピアリングは確立しません。

3 つのピアでのサブネット IP 範囲の重複(クリックで拡大)
3 つのピアでのサブネット IP 範囲の重複(クリックで拡大)

サブネットの作成または拡大時にサブネットが重複している場合

VPC サブネットが作成されるか、サブネット IP 範囲が拡張されると、Google Cloud は、新しいサブネット範囲が同じ VPC ネットワークまたはダイレクト ピアリングされている VPC ネットワーク内のサブネット IP 範囲と重複していないことを確認します。重複する場合、作成または拡大は失敗します。下の図で、新しいサブネット subnet_3 をネットワーク N2 に作成する場合、直接ピアリングされるネットワーク N1 の定義と重複する IP 範囲は使用できません。

サブネット作成時のチェック(クリックで拡大)
サブネット作成時のチェック(クリックで拡大)

Google Cloud は、ピアリングされるネットワークを持つ VPC ネットワーク間でサブネット IP 範囲が重複していないことも確認します。重複する場合、作成または拡大は失敗します。下の図で、新しいサブネット subnet_5 をネットワーク N3 に作成する場合、ネットワーク N1 はすでに N2 とピアリングされているため、直接ピアリングされるネットワーク N2 のサブネット IP 範囲だけでなく、ネットワーク N1 の定義に重複する IP 範囲も使用できません。

3 つのピアが存在する場合のサブネット作成時のチェック(クリックで拡大)
3 つのピアが存在する場合のサブネット作成時のチェック(クリックで拡大)

ピア ネットワークからオンプレミスにアクセスする場合

Cloud VPN または Cloud Interconnect を使用すると、オンプレミス ネットワークを VPC ネットワークに安全に接続できます。カスタムルートをエクスポートすると、ピアリングされる VPC ネットワークもこのオンプレミス ネットワークに接続できます。オンプレミス側では、VPC ネットワークに向かうトラフィックが VPN トンネルに送られるようにルートを作成する必要があります。

Cloud VPN では静的ルーティングと動的ルーティングがサポートされますが、Cloud Interconnect では動的ルーティングだけがサポートされます。動的ルーティングの場合は、Cloud Router を使用して、VPC ネットワークとオンプレミス ネットワークの間のルートを Border Gateway Protocol(BGP)によって動的に更新します。Cloud Routers では、そのリージョン内、または VPC ネットワーク内のすべてのリージョンでルートを学習して伝搬できます。この動作は、VPC ネットワークの動的ルーティング モード(リージョンまたはグローバル)によって異なります。

次のユースケースでは、ピアリングされる VPC ネットワークでカスタムルートのインポートとエクスポートが行われた後に、それらのネットワーク内のリソースがどのようにアクセス可能になるかを示しています。それぞれの例は、相互にピアリングされている 2 つのネットワーク(network-anetwork-b)を表しています。1 つの例では、network-b の動的ルーティング モードがリージョンであり、もう 1 つの例ではグローバルです。

リージョン動的ルーティング

リージョン動的ルーティングを使用する場合、Cloud Router と同じリージョン内のリソースだけがオンプレミス ネットワークにアクセスできます。この制限は、ピアリングされる VPC ネットワークの動的ルーティング モードに関係なく、Cloud Router の VPC ネットワークとそのピアリングされるすべての VPC ネットワークに適用されます。次の例では、network-b に VPN トンネル(相互接続の場合もあります)と Cloud Router が含まれています。network-b の動的ルーティング モードはリージョンに設定されています。ピアリングされるネットワークでは subnet-anetwork-b の Cloud Router と同じリージョン内にあります。

ピアリング接続が確立されると、network-anetwork-b の VPN トンネルにアクセスできます。このアクセスは、Cloud Router と同じリージョンにあるサブネットに制限されます。たとえば、VM インスタンス vm-a は Cloud Router と同じリージョンにあるため、その VPN トンネルに接続できます。他のリージョンにある VM インスタンスはこのトンネルにアクセスできません。

Cloud Router では、ピアリングされる VPC ネットワークからルートの学習や伝搬は行いません。そのため、BGP セッションでオンプレミス ネットワークに 10.8.1.0/24 範囲を伝搬するカスタムルート アドバタイズが Cloud Router で必要になります。

次の表に、network-anetwork-b で結果として得られるルート(両方のネットワークでカスタムルートのインポートとエクスポートを行う場合)をまとめています。

ネットワーク 宛先 ネクストホップ 送信元
network-a 0.0.0.0/0 インターネット ゲートウェイ ローカル
10.8.1.0/24 network-a ローカル
10.30.0.0/16 vm-a1 ローカル
10.8.2.0/24 peering-a-to-b ピア
10.10.0.0/16
(ダイナミック ルートは us-west1 に制限されています)
peering-a-to-b ピア
network-b 0.0.0.0/0 インターネット ゲートウェイ ローカル
10.8.2.0/24 network-b ローカル
10.10.0.0/16
(ダイナミック ルートは us-west1 に制限されています)
vpn-b ローカル
10.8.1.0/24 peering-b-to-a ピア
10.30.0.0/16 peering-b-to-a ピア

グローバル動的ルーティング

network-b でグローバル動的ルーティングが有効な場合、すべてのリージョン内のリソースからオンプレミス ネットワークにアクセスできます。これは、ピアリングされる VPC ネットワークの動的ルーティング モードに関係なく、Cloud Router の VPC ネットワークとそのピアリングされるすべての VPC ネットワークに適用されます。

次の例で、network-a のリソースは、リージョンにかかわらず network-b の VPN トンネルにアクセスできます。たとえば、vm-a2 が VPN トンネルとは異なるリージョンにあっても、VM インスタンス vm-a1vm-a2 はオンプレミス ネットワークに接続できます。

Cloud Router には、BGP セッションでオンプレミス ネットワークに 10.8.1.0/2410.9.1.0/24 の範囲を通知するカスタムルート アドバタイズを含めることも必要です。

次の表に、network-anetwork-b で結果として得られるルート(両方のネットワークでカスタムルートのインポートとエクスポートを行う場合)をまとめています。

ネットワーク 宛先 ネクストホップ 送信元
network-a 0.0.0.0/0 インターネット ゲートウェイ ローカル
10.8.1.0/24 network-a ローカル
10.9.1.0/24 network-a ローカル
10.30.0.0/16 vm-a1 ローカル
10.8.2.0/24 peering-a-to-b ピア
10.10.0.0/16
(グローバル動的ルート)
peering-a-to-b ピア
network-b 0.0.0.0/0 インターネット ゲートウェイ ローカル
10.8.2.0/24 network-b ローカル
10.10.0.0/16
(グローバル動的ルート)
vpn-b ローカル
10.8.1.0/24 peering-b-to-a ピア
10.9.1.0/24 peering-b-to-a ピア
10.30.0.0/16 peering-b-to-a ピア

トランジット ネットワークとしての VPC ネットワーク

VPC ネットワークとオンプレミス ネットワーク間に、VPN トンネルや相互接続などの単一のオンプレミス接続が確立されているとします。この接続を他の VPC ネットワークと共通して、他のすべての VPC ネットワーク向けにオンプレミス接続を再作成しなくてすむようにしたいと思っています。

その場合、オンプレミス接続が確立されている VPC ネットワーク(トランジット ネットワークとも呼びます)と他の VPC ネットワークをピアリングすると、他の VPC ネットワークもそのオンプレミス接続を使用できるようになります。ピアリングされるすべてのネットワークはオンプレミス接続を利用できますが、トランジット ネットワーク経由で他のピアにトラフィックをルーティングすることはできません。

次の例には 3 つの VPC ネットワークがあります。network-bnetwork-anetwork-c にピアリングされています。すべてのネットワークが、カスタムルートをエクスポートおよびインポートします。network-b は VPN トンネルが配置されているトランジット ネットワークとして機能します。

  • network-b には、接続されたオンプレミス ネットワークにトラフィックをルーティングするための静的 VPN ルートがあります。この静的ルートは、ピアリングされる VPC ネットワークによってエクスポートされた後、インポートされます。Cloud Router を動的ルーティングに使用する場合は、ピア ネットワークのサブネット IP アドレスをアドバタイズする必要があります。Cloud Router は、VPC ネットワーク ピアリングからのルートを自動的にはアドバタイズしません。

  • オンプレミス ネットワーク内のホストは、各 VPC ネットワーク内のホストとの間でトラフィックを送受信できます。トラフィックの宛先がいずれかの VPC ネットワークである場合、オンプレミス ネットワークには VPN ゲートウェイへのネクストホップがあるルートが含まれていなければなりません。

  • network-b のホストは network-c とオンプレミス ネットワークのホストにアクセスできますが、network-a のホストにはアクセスできません。同様に、network-a のホストは network-b とオンプレミス ネットワークにアクセスできますが、network-c のホストにはアクセスできません。これは、ピアリング ルートが推移的でないためです。

内部 TCP/UDP 負荷分散

次の条件が満たされている場合、ピア ネットワーク内の VM インスタンスは VPC ネットワークの内部 TCP/UDP ロードバランサの内部 IP アドレスにアクセスできます。

  • VM が内部 TCP/UDP ロードバランサと同じリージョンにある。
  • ロードバランサのバックエンド VM に適用される上り(内向き)ファイアウォール ルールで、ピア ネットワーク内のソースからのトラフィックが許可されている。この上り(内向き)ファイアウォール ルールは、ロードバランサを含む VPC ネットワーク内で作成する必要があります。

詳細については、VPC ネットワーク ピアリングの使用をご覧ください。

ファイアウォール ルール

VPC ネットワーク ピアリングを使用してネットワークを接続する際に、そのネットワーク間でファイアウォール ルールは交換されません。ピア ネットワーク内の VM インスタンスからの上り(内向き)トラフィックを許可するには、上り(内向き)許可ファイアウォール ルールを作成する必要があります。デフォルトでは、VM への上り(内向き)トラフィックは、暗黙の上り(内向き)拒否ルールによってブロックされます。

VM へのアクセスを制限して、自分の VPC ネットワーク内の他の VM だけがアクセスできるようにする場合は、上り(内向き)許可ファイアウォール ルールの送信元で、自分の VPC ネットワーク内の VM だけが識別され、ピア ネットワークの VM は識別されないようにしてください。たとえば、自分の VPC ネットワーク内のサブネットにだけ、ソース IP の範囲を指定します。

内部 TCP/UDP ロードバランサへのアクセスを制限するには、ロードバランサのバックエンド VM に適用される上り(内向き)ファイアウォール ルールを作成します。

ファイアウォール

ファイアウォール ルールは、ピアリングされるネットワークにインポートされません。ピアリングされるネットワークで許可またはブロックするトラフィックを制御するために、それぞれのネットワークでファイアウォール ルールを個別に構成できます。

自身の VPC ネットワークと他の VPC ネットワークをピアリングしている状況で、特定の VM インスタンスまたは内部負荷分散エンドポイントへのトラフィックをブロックしたい場合があります。特定の VM インスタンスまたは内部ロードバランサをピアリングから除外する方法はないため、このような機能を実装するにはファイアウォール ルールを使用する必要があります。特定の VM インスタンスまたは内部ロードバランサとの通信を禁止するには、通信をブロックするネットワークに上り(内向き)のファイアウォール ルールを設定します。

  • VM インスタンス: 特定のソース IP からのトラフィックのみを許可する上り(内向き)ファイアウォールを設定します。これらのソース IP は、自身の VPC ネットワークのサブネット CIDR にマッピングします。これにより、ピアリングされる VPC ネットワークから送信されたトラフィックがブロックされます。
VPC ネットワーク ピアリングでのファイアウォール(クリックで拡大)
VPC ネットワーク ピアリングでのファイアウォール(クリックで拡大)
  • 内部ロードバランサ: 内部ロードバランサのある VPC ネットワークに上り(内向き)ファイアウォール ルールを設定します。これらのソース IP は、自身のネットワークのサブネット CIDR の全部または一部にマッピングできます。上り(内向き)ファイアウォール ルールが、ピアリングされるネットワークのすべてのサブネット CIDR 範囲に設定されると、このネットワーク内のインスタンスは、内部ロードバランサのバックエンド VM に到達できなくなります。

共有 VPC

VPC Network Peering を使用すると、共有 VPC とピアリングできます。共有 VPC ホスト プロジェクトは、他のプロジェクトがそのネットワークの 1 つを使用できるようにするプロジェクトです。次の図にこの構成を示します。

ネットワーク ピアリングでの共有 VPC(クリックで拡大)
ネットワーク ピアリングでの共有 VPC(クリックで拡大)

Network-SVPC は、ホスト プロジェクト P1 の共有 VPC ネットワークです。サービス プロジェクト P3 と P4 は VM インスタンスを Network-SVPC に接続できます。Network-A は Network-SVPC とピアリングします。結果として次のようになります。

  • Network-SVPC(VM3 と VM4)を使用している共有 VPC サービス プロジェクトの VM インスタンスは、Network-A のエンドポイントとプライベートの内部 IP で接続します。
  • エンドポイントがホスト プロジェクトにあるか、サービス プロジェクトにあるかに関係なく、Network-A の VM インスタンスは Network-SVPC に関連付けられたすべてのエンドポイントとプライベート内部 IP で接続します。

2 つの共有 VPC ネットワーク間に VPC ネットワーク ピアリングを設定できます。

VM インスタンス別の複数のネットワーク インターフェース

VM インスタンスには、1 つの VPC ネットワークごとに複数のネットワーク インターフェースを設定できます。Google Cloud は、これらのインスタンスに宛先ベースの IP ルートを割り当てます。各インターフェースが、属するサブネットからルートを取得します。また、Google Cloud は、プライマリ ネットワーク インターフェースへのデフォルト ルートを提供します。宛先ベースのルーティングでは、インスタンスのサブネット宛てではないトラフィックはプライマリ ネットワーク インターフェースから外向きに送信されます。詳細については、複数のネットワーク インターフェースがある場合の DHCP の動作をご覧ください。

複数のネットワーク インターフェースを持つ VM インスタンスを含むピアネットワークがある場合は、デフォルトの宛先ベースのルーティング ポリシーをソースベースのルーティング ポリシーに変更しなければならないことがあります。詳細については、ポリシー ルーティングの構成をご覧ください。

次のシナリオでは、どのような場合に VM インスタンスにソースベースのルーティング ポリシーが必要か説明しています。

ルーティング ポリシーが必要

次の例では、vm1vm2 が通信できるようにするため、vm1 にソースベースのルーティング ポリシーが必要です。ルーティング ポリシーがない場合、トラフィックが nic1 の位置する subnet-b 宛でない限り、すべてのトラフィックは vm1-nic0 から network-a に外向きに送信されます。つまり、VM インスタンスは常にプライマリ インターフェースからトラフィックを送信するため、vm1 から network-c 宛てのトラフィックは破棄されるか、誤った宛先に送信されることになります。

ルーティング ポリシーの要件は、サブネット IP 範囲によって異なります。

次の例では、vm1 のプライマリ ネットワーク インターフェースは別のネットワークとピアリングされているネットワーク内にあります。vm1 でポリシー ルーティングを構成する必要はありません。

次の例では、vm1-nic1vm2-nic0 が重複したサブネット中にあります。ピアリングが確立されると、Google Cloud はピア間だけの IP 範囲の重複を確認し、ネットワーク インターフェースを含む他のネットワーク間での重複は確認しません。vm1vm2 間の通信を確実に行うには、vm1-nic0 にソースベースのルーティング ポリシーを追加する必要があります。

インターフェース間のピアリング

次の例は、複数のネットワーク インターフェースを持つ VM インスタンスを示しています。各インターフェースは相互にピアリングされるネットワーク内にあります。この場合、vm1 にソースベースのルーティング ポリシーは必要ありません。VM インスタンスから各サブネットへのトラフィックは、対応するネットワーク インターフェースを使用します。

vm1vm2-nic1 の IP アドレスにトラフィックを送信すると、トラフィックは nic1 に入りますが nic0 から外向きに送信されます。同様に、vm3vm2-nic0 の IP アドレスにトラフィックを送信すると、トラフィックは nic0 に入りますが nic1 から外向きに送信されます。

サブネット セカンダリ範囲

サブネットには 1 つのプライマリ IP アドレス範囲と、オプションの 1 つ以上のセカンダリ IP アドレス範囲があります。サブネット IP アドレス範囲ごとに、Google Cloud はサブネット ルートを作成します。VPC ネットワーク ピアリングを使用すると、Google Cloud は 2 つのピアリングされるネットワーク間で必ずサブネット ルートを交換します。各ネットワークのファイアウォール ルールによって通信が許可される場合、一方のネットワーク内の VM インスタンスは、ピアリングされるネットワーク内のインスタンスと通信できます。

ピアリング関係を確立する際、Google Cloud は、サブネットのプライマリおよびセカンダリ範囲がピアリングされるネットワークの他の範囲と重複しないことを確認します。

次のステップ