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

Google Cloud VPC ネットワーク ピアリングは、2 つの Virtual Private Cloud（VPC）ネットワークを接続して、各ネットワーク内のリソースが相互に通信できるようにします。

  • すべてのサブネットは内部 IPv4 アドレスを使用して通信できます。
  • また、デュアルスタック サブネットは、内部または外部 IPv6 アドレスを使用して通信を行うことができます。

ピアリングされた VPC ネットワークは、同じプロジェクト、同じ組織の異なるプロジェクト、または異なる組織の異なるプロジェクトに存在します。

VPC ネットワーク ピアリングには次の利点があります。

VPC ネットワーク ピアリングの利点

VPC ネットワーク ピアリングには次の利点があります。

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

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

仕様

VPC ネットワーク ピアリングの仕様は次のとおりです。

全般的な仕様:

  • VPC ネットワーク ピアリングは、Compute Engine、GKE、App Engine フレキシブル環境で動作します。
    • デフォルトでは、GKE との VPC ネットワーク ピアリングは IP エイリアスで使用する場合にサポートされます。IP エイリアスを使用しない場合は、カスタムルートをエクスポートすることで、ピアリングされたネットワークから GKE コンテナにアクセスできます。
  • VPC ネットワーク ピアリングでは VPC ネットワークのみがサポートされます。レガシー ネットワークでは、ピアリングはサポートされていません。
  • VPC ネットワーク ピアリングは IPv4 と IPv6 の両方の接続をサポートしています。VPC ネットワーク ピアリングはデュアルスタック サブネットを含む VPC ネットワークで構成できます。ただし、IPv6 の場合は動的ルートのみが交換されます。
  • 1 つの VPC ネットワークを複数の VPC ネットワークにピアリングできますが、上限があります。
  • すべての自動モードの VPC ネットワークにはまったく同じサブネットがあるため、2 つの異なる自動モードの VPC ネットワークをピアリングすることはできません。
  • カスタムモードの VPC ネットワークと自動モードの VPC ネットワーク（デフォルト ネットワークなど）をピアリングできます。ただし、カスタムモードの VPC ネットワークのサブネットは、自動モードの VPC ネットワークのアドレス空間（10.128.0.0/9）と重複しないようにする必要があります。

管理の分離:

  • ピアリングされた VPC ネットワークの管理は別々に行います。ルート、ファイアウォール、VPN などのトラフィック管理ツールは、各 VPC ネットワークで別々に管理し、適用します。
  • ピアリング接続を確立するには、各 VPC ネットワークのネットワーク管理者が、他の VPC ネットワークとのピアリング接続を確立する必要があります。ピアリング接続は、いずれかの VPC ネットワークのネットワーク管理者が切断できます。
  • ピアリングの両側は別々に設定されます。両側の構成が一致する場合にのみ、ピアリングが有効になります。ピアリング関係は、どちらの側でも、いつでも削除できます。
  • ピアリング接続を作成しても、他の VPC ネットワークに対する Identity and Access Management（IAM）ロールは付与されません。たとえば、一方のネットワークの Compute ネットワーク管理者ロールまたは Compute セキュリティ管理者ロールが付与されていても、もう一方のネットワークのネットワーク管理者やセキュリティ管理者になることはできません。

IAM:

  • VPC ネットワーク ピアリングの作成と削除の IAM ロールは、Compute ネットワーク管理者ロール（roles/compute.networkAdmin）に含まれています。
  • 次の権限を含むカスタムロールを使用できます。
    • compute.networks.addPeering
    • compute.networks.updatePeering
    • compute.networks.removePeering
    • compute.networks.listPeeringRoutes

ルート交換:

  • ピアリングの構成と、カスタムルートをインポートおよびエクスポートするための構成は、片側の VPC ネットワークが作成されていない場合でも、すでに作成されているもう片側の VPC ネットワークに対して行えます。ルート交換は両側が構成された後にのみ行われます。
  • VPC ピアは常にサブネット ルートをエクスポートします。
  • サブネットでプライベート IP アドレスが使用されている場合、VPC ピアは常にサブネット ルートをインポートします。サブネットで、プライベートで使用されるパブリック IP アドレスが使用されている場合、ピアリングされたネットワークは、プライベートで使用されるパブリック IP サブネット ルートを明示的にインポートして、他のネットワークから受信する必要があります。プライベート IP アドレスとプライベートで使用されるパブリック IP アドレスの詳細については、有効な範囲をご覧ください。
  • サブネット ルートの交換の無効化や、交換するサブネット ルートの選択はできません。ピアリングが確立されると、サブネット IP アドレス内のリソースはすべて、直接ピアリングされたネットワーク全体でアクセス可能になります。VPC ネットワーク ピアリングでは、どのサブネット CIDR 範囲がピアリングされたネットワーク間で到達可能かをフィルタするような、細かなルート管理は行われません。ルート管理が必要であれば、トラフィックをフィルタするファイアウォール ルールを使用する必要があります。直接ピアリングしたネットワーク間では、次の種類のエンドポイントとリソースに到達できます。
    • すべてのサブネットの仮想マシン（VM）の内部 IP
    • すべてのサブネットで内部ロードバランスされた IP
  • ピアリング構成でカスタムルート（静的ルートと動的ルート）をインポートまたはエクスポートするように構成していれば、カスタムルートの交換も可能です。詳細については、カスタムルートのインポートとエクスポートをご覧ください。
  • サブネット ルートと静的ルートはグローバルです。動的ルートは、VPC ネットワークの動的ルーティング モードに応じてリージョンかグローバルのいずれかになります。
  • 片側のピア VPC ネットワーク内のサブネット CIDR 範囲ともう片側のピア ネットワーク内の静的ルートは重複できません。このルールは、サブネット ルートと静的ルートの両方に適用されます。Google Cloud は次の状況で重複が発生していないか確認し、重複が発生した場合にエラーを生成します。
    • 初めて VPC ネットワークをピアリングする場合
    • ピアリングされる VPC ネットワークで静的ルートを作成する場合
    • ピアリングされる VPC ネットワーク内に新しいサブネットを作成する場合
  • 動的ルートはピア ネットワーク内のサブネット ルートと重複できます。動的ルートの場合、ピア ネットワークのサブネット ルートと重複する宛先範囲は暗黙的にドロップされます。Google Cloud はサブネット ルートを使用します。

制限事項:

  • 通信できるのは、直接ピアリングしたネットワークだけです。推移的ピアリングはサポートされていません。たとえば、VPC ネットワーク N1 が N2 と N3 にピアリングされ、N2 と N3 が直接接続されていない場合、VPC ネットワーク N2 は VPC ネットワーク ピアリング経由で VPC ネットワーク N3 と通信できません。
  • ピアリングされるネットワークのネットワーク タグまたはサービス アカウントは、VPC ファイアウォール ルールで使用できません。詳細については、ネットワーク セキュリティをご覧ください。
  • ネットワークで作成した Compute Engine 内部 DNS 名で、ピアリングされたネットワークにはアクセスできません。ピアリングされたネットワーク内の VM インスタンスにアクセスするには、IP アドレスを使用してください。
  • ポリシーベースのルートはピアリングで交換されません。

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

ネットワーク セキュリティ

VPC ネットワーク ピアリングでは、VPC ファイアウォール ルールまたは階層型ファイアウォール ポリシーは交換されません。一方の VPC ネットワークの VPC ファイアウォール ルールで、もう一方の VPC ネットワークのネットワーク タグまたはサービス アカウントを使用して宛先または送信元を指定することはできません。ただし、両方のネットワークで同じターゲットタグを使用できます。

すべての VPC ネットワークには暗黙のファイアウォール ルールが存在します。暗黙の上り（内向き）拒否ファイアウォール ルールのため、ローカル VPC ネットワークのセキュリティ管理者は、適切な上り（内向き）許可ファイアウォール ルールまたは階層型ファイアウォール ポリシーを作成する必要があります。これらのルールまたはポリシーにより、ピアリングされた VPC ネットワーク内で必要な送信元 IP アドレス範囲のパケットが許可されます。

暗黙の下り（外向き）許可ファイアウォール ルールのため、ピアリングされた VPC ネットワークの宛先へのパケットを許可する下り（外向き）許可ファイアウォール ルールまたは階層型ファイアウォール ポリシーを作成する必要はありません。ただし、ローカル VPC ネットワークのセキュリティ管理者が明示的な下り（外向き）拒否ルールを作成した場合は、下り（外向き）許可ルールまたはポリシーを作成する必要があります。

DNS のサポート

ピアリングされた VPC ネットワークのリソースでは、ローカル VPC ネットワークによって作成された Compute Engine の内部 DNS 名を使用できません。

ピアリングされた VPC ネットワークでは、ローカル VPC ネットワークのみに承認された Cloud DNS 限定公開マネージド ゾーンを使用できません。ピアリングされた VPC ネットワーク内のリソースで DNS 名を使用できるようにするには、次のいずれかの方法を使用します。

内部ロードバランサのサポート

ローカル VPC ネットワーク内のクライアントは、ピア VPC ネットワークの内部パススルー ネットワーク ロードバランサにアクセスできます。詳細については、内部パススルー ネットワーク ロードバランサに VPC ネットワーク ピアリングを使用するをご覧ください。ピアリングされたネットワークは、内部パススルー ネットワーク ロードバランサをネクストホップとして使用して、カスタム静的ルートを交換できます。詳細については、ルート交換オプションをご覧ください。

ローカル VPC ネットワーク内のクライアントは、ピア VPC ネットワークの内部アプリケーション ロードバランサにアクセスできます。詳細については、内部アプリケーション ロードバランサに VPC ネットワーク ピアリングを使用するをご覧ください。

VPC ネットワーク ピアリングに関する上限

VPC ネットワーク ピアリングでは、次のものが制御されます。

  • ピアリング グループ内に存在できるリソースの数。たとえば、仮想マシン（VM）インスタンスや内部転送ルールなど。
  • 特定の VPC ネットワークが接続できるネットワークの数。

VPC ピアリングの上限は、ピアリング グループと呼ばれるコンセプトに基づいて決まります。各 VPC ネットワークには独自のピアリング グループがあります。このグループは、そのネットワーク自体と、VPC ネットワーク ピアリングで接続している他のすべての VPC ネットワークから構成されます。最も単純なシナリオで net-a と net-b の 2 つの VPC ネットワークが相互にピアリングされている場合、2 つのピアリング グループがあります。一方は net-a からのグループ、もう一方はnet-b からのグループです。

詳細については、VPC ネットワーク ピアリングに関する制限をご覧ください。

ルート交換オプション

VPC ネットワークは、ピアリングされた VPC ネットワークとローカルルートを共有すると、そのルートをエクスポートします。これで、ピアリングされた VPC ネットワークがルートをインポートできるようになります。サブネット ルート（プライベートで使用されるパブリック IPv4 アドレスの IPv4 サブネット ルートを除く）は常に交換されます。

VPC ネットワーク ピアリング構成では、次のことを制御できます。

  • IPv6 ルートを交換するかどうか
  • プライベートで使用されるパブリック IPv4 アドレスのサブネットのルートをエクスポートまたはインポートするかどうか。
  • カスタム静的ルートまたは動的ルートをエクスポートまたはインポートするかどうか。

この構成は、ピアリングの確立前またはピアリング接続がアクティブなときに更新できます。

サブネットのルート交換オプション

次の表に、サブネット ルートのルート交換オプションを示します。

ルートのタイプ ルートのエクスポート条件 ルートのインポート条件
プライベート IPv4 アドレス範囲を使用した IPv4 サブネット ルート（プライマリとセカンダリの IPv4 サブネット範囲） 常にエクスポート

無効にできません		 常にインポート

無効にできません
プライベートで使用されるパブリック IPv4 アドレス範囲を使用した IPv4 サブネット ルート（プライマリとセカンダリの IPv4 サブネット範囲） デフォルトでエクスポート

エクスポートは --export-subnet-routes-with-public-ip フラグで制御されます		 デフォルトではインポートされない

インポートは --import-subnet-routes-with-public-ip フラグで制御されます
内部 IPv6 サブネット範囲
（ipv6-access-type=INTERNAL）		 デフォルトではエクスポートされない

エクスポートは --stack-type=IPV4_IPV6 で有効にします		 デフォルトではインポートされない

インポートは --stack-type=IPV4_IPV6 で有効にします
外部 IPv6 サブネット範囲
（ipv6-access-type=EXTERNAL）		 デフォルトではエクスポートされない

エクスポートは --stack-type=IPV4_IPV6 で有効にします		 デフォルトではインポートされない

インポートは --stack-type=IPV4_IPV6 で有効にします

カスタム静的ルートの交換オプション

次の表に、カスタム静的ルートのルート交換オプションを示します。

ルートのタイプ ルートのエクスポート条件 ルートのインポート条件
ネットワーク タグを含むカスタム静的ルート（すべてのネクストホップ タイプ） エクスポートできません インポートできません
デフォルト インターネット ゲートウェイのネクストホップを使用するカスタム静的ルート エクスポートできません インポートできません
ネットワーク タグのないカスタム IPv4 静的ルート。ネクストホップとして内部パススルー ネットワーク ロードバランサのプライベート IPv4 アドレスを使用。 常にエクスポート（サブネット IPv4 ルートなど）

無効にできません		 常にインポート（サブネット IPv4 ルートなど）

無効にできません
ネットワーク タグのないカスタム IPv4 静的ルート。ネクストホップとして内部パススルー ネットワーク ロードバランサの転送ルール名を使用 デフォルトではエクスポートされない

エクスポートは --export-custom-routes フラグで制御されます		 デフォルトではインポートされない

インポートは --import-custom-routes フラグで制御されます
他のネクストホップ タイプを使用する（ネットワーク タグなし）カスタム IPv4 静的ルート デフォルトではエクスポートされない

エクスポートは --export-custom-routes フラグで制御されます		 デフォルトではインポートされない

インポートは --import-custom-routes フラグで制御されます
VM インスタンスをネクストホップとして使用する（ネットワーク タグなし）カスタム IPv6 静的ルート デフォルトでエクスポートされない

ピアリングのスタックタイプが --stack-type=IPV4_IPV6 に設定されている場合、エクスポートは --export-custom-routes フラグで制御されます。		 デフォルトではインポートされない

ピアリングのスタックタイプが --stack-type=IPV4_IPV6 に設定されている場合、インポートは --import-custom-routes フラグで制御されます。

動的ルートの交換オプション

次の表に、動的ルートのルート交換オプションを示します。

ルートのタイプ ルートのエクスポート条件 ルートのインポート条件
動的 IPv4 ルート デフォルトではエクスポートされない

エクスポートは --export-custom-routes フラグで制御されます		 デフォルトではインポートされない

インポートは --import-custom-routes フラグで制御されます
動的 IPv6 ルート デフォルトでエクスポートされない

ピアリングのスタックタイプが --stack-type=IPV4_IPV6 に設定されている場合、エクスポートは --export-custom-routes フラグで制御されます。		 デフォルトではインポートされない

ピアリングのスタックタイプが --stack-type=IPV4_IPV6 に設定されている場合、インポートは --import-custom-routes フラグで制御されます。

カスタムルートの交換

1 つの VPC ネットワークがカスタムルートをエクスポートし、もう 1 つの VPC ネットワークがカスタムルートをインポートすると、インポート側のネットワークは、インポートされたピア VPC ネットワークの各カスタムルートのネクストホップに直接パケットを送信できます。カスタム静的ルートとカスタム動的ルートは同時に学習されるため、個別に構成できません。一方のネットワークの変更は、特定の条件に従い、他方のネットワークに反映されます。詳細については、このドキュメントの無視されるルート、サブネットとピアリング サブネット ルートの相互作用、サブネットと静的ルートの相互作用をご覧ください。

ピアリングされた VPC ネットワークからカスタムルートをインポートすると、次のような場合に便利です。

  • ピアリングされた VPC ネットワークにルートベースの GKE クラスタがあり、それらのクラスタ内の Pod にパケットを送信する必要がある場合: Pod IP アドレスは、ピアリングされた VPC ネットワークにあるカスタム静的ルートの宛先範囲として実装されます。
  • ピアリングされた VPC ネットワークにオンプレミス リソースへのルートが含まれていて、ローカル VPC ネットワーク内のリソースにアクセスする必要がある場合: オンプレミス ネットワークのローカル VPC ネットワークのサブネット IP アドレス範囲のルートも作成する必要があります。ピアリングされた VPC ネットワークで Cloud Router のカスタムルート アドバタイズを使用すると、この追加要件を満たすことができます。

無視されるルート

次のような状況では、VPC ネットワークがルートをインポートしても、インポートされたルートが無視されることがあります。

  • ローカル VPC ネットワークに同じまたはより限定された宛先（より長いサブネット マスク）を持つルートがある場合、ローカル VPC ネットワークは常にローカルルートを使用します。

  • ローカル VPC ネットワークに最も限定されたルートが含まれていないが、2 つ以上のピアリングされた VPC ネットワークにパケットの最も限定された宛先が含まれている場合、Google Cloud は内部アルゴリズムを使用して、ピアリングされた VPC ネットワークの 1 つからネクストホップを選択します。この選択はルートの優先度が考慮される前に行われます。この動作は構成できません。ピアリングされた VPC ネットワークを追加または削除すると、ルーティング順序が意図せず変更される可能性があるため、この構成は避けてください。

こうした状況の詳細については、ルーティング順序をご覧ください。

デュアルスタック ピアリングで、IPv6 ルートをインポートするローカル VPC ネットワークにデュアルスタック サブネットがない場合、ピアリングされた VPC ネットワークから受信する IPv6 ルートは使用できません。さらに、constraints/compute.disableAllIpv6 組織のポリシーの制約が設定されている場合、ネットワーク管理者がデュアルスタック サブネットを作成できない場合があります。

サブネットとピアリングのサブネット ルートの相互作用

ピアリングされた VPC ネットワークの IPv4 サブネット ルートは重複できません。

  • ピアリングでは、同一 IPv4 サブネットのルートが禁止されます。たとえば、2 つのピアリングされた VPC ネットワークは、宛先が 100.64.0.0/10 の IPv4 サブネット ルートを持つことはできません。
  • ピアリングでは、ピアリング サブネット ルート内にサブネット ルートを含めることはできません。たとえば、ローカル VPC ネットワークの宛先が 100.64.0.0/24 であるサブネット ルートがある場合、ピアリングされたどの VPC ネットワークも、宛先が 100.64.0.0/10 のサブネット ルートを持つことはできません。

次の場合、Google Cloud では IPv4 サブネット ルートに対して前述の条件が適用されます。

  • VPC ネットワーク ピアリングを使用して初めて VPC ネットワークを接続するとき。
  • ネットワークがピアリングされている間。
  • ピアリング構成を変更するとき（例: プライベートで使用されるパブリック IP アドレスのサブネット IPv4 ルートのインポートを有効にする場合）。

ネットワークのピアリング中に、次のいずれかのオペレーションが重複すると、Google Cloud はエラーを返します。

IPv6 サブネット ルート（内部と外部の両方）は、定義上一意です。2 つの VPC ネットワークが同じ内部または外部 IPv6 サブネット範囲を使用することはできません。たとえば、ある VPC ネットワークが fc:1000:1000:1000::/64 を IPv6 サブネット範囲として使用する場合、VPC ネットワーク接続に VPC ネットワーク ピアリングが使用されているかどうかに関係なく、Google Cloud の他の VPC ネットワークは fc:1000:1000:1000::/64 を使用できません。

サブネットと静的ルートの相互作用

Google Cloud では、サブネット ルートとピアリング サブネット ルートに、最も狭い範囲の宛先 IPv4 または IPv6 範囲が必要です。どの VPC ネットワークでも、ローカル静的ルートにローカル サブネット ルートと完全に一致する宛先や、ルートに収まる宛先を設定することはできません。このシナリオの詳細については、カスタム静的ルートとの相互作用をご覧ください。

このコンセプトは、次の 2 つのルールによって VPC ネットワーク ピアリングにも拡張されます。

  • ローカル静的ルートに、ピアリング サブネット ルートと完全に一致する宛先またはルートに収まる宛先を含めることはできません。ローカル静的ルートが存在する場合、Google Cloud は以下を適用します。

    • ピアリング構成で競合するサブネット ルートがインポートされる場合、ローカル静的ルートの宛先と完全に一致するか、その宛先を含むサブネット ルートがすでに存在する VPC ネットワークに対して、新しいピアリング接続を確立することはできません。次に例を示します。

      • 宛先が 10.0.0.0/24 のローカル静的ルートが存在する場合、宛先が 10.0.0.0/24 に完全に一致するか 10.0.0.0/24 が含まれている IPv4 （例: 10.0.0.0/8） サブネット ルートを含む VPC ネットワークに、新しいピアリング接続を確立することはできません。

      • 目的のピアリング スタックの種類が IPV4_IPV6 の場合、宛先が 2001:0db8:0a0b:0c0d::/96 であるローカル静的ルートが存在すると、宛先が完全に一致しているか、2001:0db8:0a0b:0c0d::/96 が含まれている IPv6 サブネット ルートを持つ VPC ネットワークと新しいピアリング接続を確立できません。この状況では、Google Cloud のサブネット IPv6 アドレス範囲は 64 ビットのサブネット マスク長を使用する必要があるため、想定されるサブネット IPv6 アドレス範囲は 2001:0db8:0a0b:0c0d::/64 のみになります。

    • ピアリング構成を更新した結果、競合するサブネット ルートがインポートされる場合は、既存のピアリング接続を更新することはできません。次に例を示します。

      • 2 つの VPC ネットワークがすでにピアリングされているものの、プライベートで使用される一般公開 IPv4 アドレス範囲を使用して IPv4 サブネット ルートを現在エクスポートおよびインポートしていないとします。最初の VPC ネットワークに、宛先が 11.0.0.0/24 のローカル静的ルートが存在し、ピアリングされた VPC ネットワークに宛先が 11.0.0.0/8 のサブネット ルートが存在します。プライベートで使用される一般公開 IPv4 アドレスを使用してサブネット ルートをエクスポートするようにピアリングされた VPC ネットワークを同時に構成することはできません。また、プライベートで使用される一般公開 IPv4 アドレスを使用してサブネット ルートをインポートするように、最初の VPC ネットワークを構成することもできません。

      • 2 つの VPC ネットワークがすでにピアリングされており、ピアリング スタックの種類が IPv4 のみであるとします。宛先が 2001:0db8:0a0b:0c0d::/96 のローカル静的ルートが最初の VPC ネットワークに存在し、宛先が 2001:0db8:0a0b:0c0d::/64 の IPv6 サブネット ルートがピアリングされた VPC ネットワークに存在します。ピアリング スタックの種類を IPV4_IPV6 に変更することはできません。

    • 逆に、VPC ネットワーク ピアリングで VPC ネットワークがすでに接続されている場合は、次の操作を行うことができません。

      • インポートされたピアリング サブネット ルートと完全に一致するか、それに収まる宛先の新しいローカル静的ルートを作成する。

      • 範囲が完全に一致するか、範囲に既存のローカル静的コードが含まれる場合に、ピアリングされた VPC ネットワークに新しいサブネット アドレス範囲を作成する。

  • ピアリング静的ルートに、ローカル サブネット ルートと完全に一致する宛先またはそのルート内の宛先を含めることはできません。ローカル サブネット ルートが存在する場合、Google Cloud では次のことが禁止されます。

    • ピアリング構成で、ピアからカスタムルートがインポートされる場合、ローカル VPC ネットワークのサブネット ルートの宛先に完全に一致する静的ルートか、その宛先内の静的ルートを含む VPC ネットワークに、新しいピアリング接続を確立することはできません。次のような例が挙げられます。

      • 10.0.0.0/8 のローカル サブネット ルートが存在する場合、宛先が 10.0.0.0/8 と完全に一致する静的ルートまたは宛先が 10.0.0.0/8 内（たとえば、10.0.0.0/24）に収まる静的ルートが存在する VPC ネットワークとピアリング接続を確立することはできません。

      • 目的のピアリング スタックの種類が IPV4_IPV6 の場合、2001:0db8:0a0b:0c0d::/64 のローカル サブネット ルートが存在すれば、宛先が 2001:0db8:0a0b:0c0d::/64 と完全に一致するか、2001:0db8:0a0b:0c0d::/64 内に該当する VPC ネットワーク（例: 2001:0db8:0a0b:0c0d::/96）には、ピアリング接続を確立できません。

    • ピアリング構成の更新によって競合する静的ルートがインポートされる場合、既存のピアリング接続を更新することはできません。

    • 逆に、VPC ネットワーク ピアリングで VPC ネットワークがすでに接続されている場合は、次の操作を行うことができません。

      • インポートされたピアリング静的ルートと完全に一致する宛先か、インポートされたピアリング静的ルートが含まれる宛先を持つ新しいローカル サブネット ルートを作成します。
      • ピアリングされた VPC ネットワークに、既存のローカル サブネット ルートと完全に一致する宛先か、そのルートに収まる宛先を持つ新しい静的ルートを作成します。

動的ルーティング モードの影響

VPC ネットワークの動的ルーティング モードにより、ネットワーク内の Cloud Router から学習した接頭辞がローカル カスタム動的ルートとして適用されるリージョンが決まります。この動作の詳細については、動的ルーティング モードの影響をご覧ください。

このコンセプトは VPC ネットワーク ピアリングにも拡張されます。エクスポート側の VPC ネットワークの動的ルーティング モード（これらの動的ルートの接頭辞を学習した Cloud Router を含むネットワーク）によって、ピアリング動的ルートがピア ネットワークでプログラムできるリージョンが決まります。

  • エクスポート側の VPC ネットワークの動的ルーティング モードがリージョンの場合、そのネットワークは、接頭辞を学習した Cloud Router と同じリージョン内の動的ルートのみをエクスポートします。

  • エクスポート側の VPC ネットワークの動的ルーティング モードがグローバルの場合、そのネットワークはすべてのリージョンの動的ルートをエクスポートします。

どちらの場合も、インポート側の VPC ネットワークの動的ルーティング モードは関係ありません。

この動作を示す例については、オンプレミス接続を使用したローカル VPC ネットワークとピア VPC ネットワークをご覧ください。

サブネットと動的ルートの相互作用

ローカルまたはピアリング サブネット ルートと動的ルートの間の競合は、カスタム動的ルートとの相互作用で説明されているように解決されます。

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

次の例は、2 つの一般的な VPC ネットワーク ピアリング シナリオを示しています。

ローカル VPC ネットワークとオンプレミス接続を備えたピア VPC ネットワーク

この例では、次のようにネットワーク ピアリングが設定されています。

  • network-a は network-b にピアリングされ、network-b は network-a にピアリングされます。
  • network-a には 2 つのサブネットがあり、各サブネットが別々のリージョンにあります。network-b には単一のサブネットが含まれています。
  • network-b は、動的ルーティングにより、Cloud VPN トンネルを介してオンプレミス ネットワークに接続します（トンネルの代わりに Cloud Interconnect VLAN アタッチメントを使用する場合も同じ原則が適用されます）。
  • network-b のピアリング接続は、カスタムルートをエクスポートするように構成されています。network-a のピアリング接続は、カスタムルートをインポートするように構成されています。

オンプレミスから network-a と network-b のサブネットへの接続を可能にするため、カスタム ルート アドバタイズを使用するように network-b の Cloud Router を構成する必要があります。たとえば、Cloud Router はカスタム プレフィックス custom-prefix-1 のみをアドバタイズします。これには、network-b のサブネット範囲と network-a のサブネット範囲が含まれます。

us-west1 の Cloud Router は、on-premises-prefix をオンプレミス ルーターから学習します。on-premises-prefix はサブネット ルートやピアリング サブネット ルートより広いため、競合は発生しません。つまり、on-premises-prefix は、サブネット ルートやピアリング サブネット ルートに完全には一致しません。また、サブネット ルートやピアリング サブネット ルートの範囲にも収まりません。

次の表は、上記の例に指定したネットワーク構成をまとめたものです。

ネットワーク名 ネットワーキング コンポーネント IPv4 範囲 IPv6 範囲 リージョン

network-a

subnet-a

10.0.0.0/24

fc:1000:1000:1000::/64

us-west1

network-a

subnet-b

10.0.1.0/24

fc:1000:1000:1001::/64

europe-north 1

network-b

subnet-c

10.0.2.0/23

fc:1000:1000:1002::/64

us-west1

network-b

Cloud Router

10.0.0.0/22

fc:1000:1000:1000::/64

us-west1

オンプレミス ネットワーク

オンプレミス ルーター

10.0.0.0/8

fc:1000:1000:1000::/56

該当なし

次のルーティング特性は、network-a の動的ルーティング モードに関係なく該当します。

  • network-b の動的ルーティング モードがグローバルの場合、network-b の Cloud Router によって学習された On-premises prefix が、network-b のすべてのリージョンに動的ルートとして追加されます。また、network-a のすべてのリージョンにピアリング動的ルートとして追加されます。ファイアウォール ルールが正しく構成されていれば、vm-a1、vm-a2 および vm-b は、IPv4 アドレス 10.5.6.7（または IPv6 アドレス fc:1000:1000:10a0:29b::）を持つオンプレミス リソースと通信できます。

  • network-b の動的ルーティング モードがリージョンに変更されると、network-b の Cloud Router によって学習された On-premises prefix は、network-b の us-west1 リージョンにのみ動的ルートとして追加されます。また、network-a の us-west1 リージョンにピアリング動的ルートとして追加されます。ファイアウォール ルールが正しく構成されている場合、IPv4 アドレス 10.5.6.7（または IPv6 アドレス fc:1000:1000:10a0:29b::）のオンプレミス リソースと通信できるのは、vm-a1 と vm-b のみです。それが Cloud Router と同じリージョンにある唯一の VM であるためです。

トランジット ネットワーク

次の例で、network-b はトランジット ネットワークとして機能します。

  • network-a は network-b にピアリングされ、network-b は network-a にピアリングされます。
  • network-c は network-b にピアリングされ、network-b は network-c にピアリングされます。
  • network-b は、動的ルーティングにより、Cloud VPN トンネルを介してオンプレミス ネットワークに接続します（トンネルの代わりに Cloud Interconnect VLAN アタッチメントを使用する場合も同じ原則が適用されます）。
    • オンプレミスから network-a、network-b、network-c のサブネットへの接続を可能にするため、カスタム ルート アドバタイズを使用するように network-b の Cloud Router を構成する必要があります。たとえば、Cloud Router は network-b のサブネット ルートだけでなく、network-a と network-c のサブネット ルートを網羅するカスタム プレフィックスをアドバタイズします。
    • サブネットと動的ルートの相互作用で説明したように、network-b の Cloud Router はオンプレミスのプレフィックスを学習し、network-b に動的ルートを作成します。
  • network-b から network-a と network-b から network-c へのピアリング接続は、カスタムルートをエクスポートするように構成されています。network-a から network-b と network-c から network-b へのピアリング接続は、カスタムルートをインポートするように構成されています。

ファイアウォールが正しく構成されている場合、次のような接続のシナリオが考えられます。

  • network-a の VM インスタンスは、network-b とオンプレミス システムの他の VM にアクセスできます。
  • network-c の VM インスタンスは、network-b とオンプレミス システムの他の VM にアクセスできます。
  • network-b の VM インスタンスは、network-a と network-c の両方の VM とオンプレミス ネットワーク内のシステムにアクセスできます。

VPC ネットワーク ピアリングは推移的ではないため、VPC を使用してネットワーク network-a と network-c も接続しない限り、network-a と network-c の VM インスタンスは相互に通信を行うことができません。

次のステップ