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

Google Cloud VPC ネットワーク ピアリングでは、2 つの Virtual Private Cloud(VPC)ネットワークが同じプロジェクトまたは同じ組織に属しているかにかかわらず、内部 IP アドレス接続できます。

VPC ネットワーク ピアリングを使用すると、異なる VPC ネットワーク内のワークロードが内部で通信できるように、VPC ネットワークを接続できます。トラフィックは Google のネットワーク内に留まり、公共のインターネットを経由することはありません。

VPC ネットワーク ピアリングは、次の環境で役立ちます。

  • Google Cloud の SaaS(Software-as-a-Service)エコシステムを使用する場合。
  • 組織に複数のネットワーク管理ドメインがある場合

組織内に複数のネットワーク管理ドメインが存在する場合、VPC ネットワーク ピアリングを利用すると、内部 IP アドレスを使用して VPC ネットワーク全体にサービスを提供できます。他の組織にサービスを提供する場合、VPC ネットワーク ピアリングを使用すると、他の組織が内部 IP アドレスを使用してこのようなサービスを利用できるようになります。組織を超えてサービスを提供できれば、他の企業にサービスを提供することが可能になります。あるいは、複数の組織を所有または管理する場合にも便利です。

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

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

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

基本特性

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

  • VPC ネットワーク ピアリングは、Compute EngineGKEApp Engine フレキシブル環境で動作します。
  • ピアリングされた VPC ネットワークの管理は別々に行います。ルート、ファイアウォール、VPN などのトラフィック管理ツールは、各 VPC ネットワークで別々に管理し、適用します。
  • ピアリングの両側は別々に設定されます。両側の構成が一致する場合にのみ、ピアリングが有効になります。ピアリング関係は、どちらの側でも、いつでも削除できます。
  • ピアリングの構成と、カスタムルートをインポートおよびエクスポートするための構成は、片側の VPC ネットワークが作成されていない場合でも、すでに作成されているもう片側の VPC ネットワークに対して行えます。ルート交換は両側が構成された後にのみ行われます。
  • VPC ピアは、内部 IP アドレスとして再利用されるパブリック IP アドレスを使用しないサブネット ルートを常に交換します。ネットワークが内部 IP アドレスとして再利用されるパブリック IP アドレスを使用するサブネットを受け入れるには、サブネット ルートを明示的にインポートする必要があります。
  • ピアリング構成でカスタムルート(静的ルートと動的ルート)をインポートまたはエクスポートするように構成していれば、カスタムルートの交換も可能です。詳細については、カスタムルートのインポートとエクスポートをご覧ください。
  • サブネット ルートと静的ルートはグローバルです。動的ルートは、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 コンテナにアクセスできます。

ルーティング順序

Google Cloud がピアリング グループ内のネットワーク間におけるルート競合を解決する方法については、ルーティング順序をよくご確認ください。

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

内部 IP アドレスとして再利用されるパブリック IP アドレスを使用しないサブネット ルートは、ピアリングされるネットワーク間で常に交換されます。両側のネットワークのネットワーク管理者が適切にピアリングを構成している場合は、カスタムルート(静的ルートと動的ルートを含む)、内部 IP アドレスとして再利用されるパブリック IP アドレスを使用するサブネットのルートも交換できます。

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

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

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

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

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

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

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

考慮事項

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

  • ピアリング時に、Google Cloud は相手側のネットワークでサブネット IP 範囲と重複するサブネット IP 範囲が存在するかどうかを確認します。重複がある場合、ピアリングは確立しません。この重複チェックは 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 インスタンス vm-a1vm-a2 は、vm-a2 が VPN トンネルとは異なるリージョンにある場合でも、オンプレミス ネットワークにアクセスできます。

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 ネットワーク ピアリングを使用する場合、2 つのピアリングされたネットワーク間で、内部 IP アドレスとして再利用されるパブリック IP アドレスを使用しないサブネット ルートが常に交換されます。各ネットワークのファイアウォール ルールによって通信が許可される場合、一方のネットワーク内の VM インスタンスは、ピアリングされるネットワーク内のインスタンスと通信できます。

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

次のステップ