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

Google Cloud VPC ネットワーク ピアリングは、2 つの Virtual Private Cloud（VPC）ネットワークを接続して、各ネットワーク内のリソースが相互に通信できるようにします。ピアリングされた VPC ネットワークは、同じプロジェクト、同じ組織の異なるプロジェクト、または異なる組織の異なるプロジェクトに存在します。

仕様

VPC ネットワーク ピアリングを使用すると、次のことができます。

接続性

  • VPC ネットワーク ピアリングは、レガシー ネットワークではなく、VPC ネットワークの接続をサポートしています。
  • VPC ネットワーク ピアリングは、VPC ネットワークのペア間で内部 IPv4 / IPv6 接続を実現します。ピアリング トラフィック（ピアリングされたネットワーク間で送受信されるトラフィック）のレイテンシ、スループット、可用性は、同じ VPC ネットワーク内のトラフィックと同じです。
    • VPC ネットワーク ピアリングは推移的ルーティングを提供しません。たとえば、VPC ネットワーク net-a と net-b が VPC ネットワーク ピアリングを使用して接続され、VPC ネットワーク net-a と net-c も VPC ネットワーク ピアリングを使用して接続されている場合、VPC ネットワーク ピアリングは net-b と net-c の間の接続を提供しません。
    • VPC ネットワーク ピアリングを使用して、2 つの自動モードの VPC ネットワークを接続することはできません。これは、ピアリングされた VPC ネットワークは常にプライベート内部 IPv4 アドレスを使用するサブネット ルートを交換し、自動モード VPC ネットワークの各サブネットが 10.128.0.0/9 CIDR ブロックに収まるサブネット IP アドレス範囲を使用するためです。
    • カスタムモード VPC ネットワークは自動モード VPC ネットワークに接続できます。ただし、カスタムモード VPC ネットワークは、10.128.0.0/9 内に収まるサブネット IP アドレス範囲を提供しません。
  • また、宛先の外部 IPv6 アドレス範囲へのルートが VPC ネットワーク ピアリングで交換される場合、VPC ネットワーク ピアリングは、次に示すリソースの宛先外部 IPv6 アドレスに対して特定の外部 IPv6 接続を提供します。
    • デュアルスタック仮想マシン（VM）インスタンスのネットワーク インターフェース
    • 外部プロトコル転送の転送ルール
    • 外部パススルー ネットワーク ロードバランサのファイアウォール ルール
  • VPC ネットワーク ピアリングは IPv4 と IPv6 の両方の接続をサポートしています。VPC ネットワーク ピアリングはデュアルスタック サブネットを含む VPC ネットワークで構成できます。

管理

  • ピアリングされた 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 ネットワークのネットワーク管理者によって構成されたルート交換オプションに基づいてルートを交換します。

VPC ネットワーク ピアリングは、VPC ファイアウォール ルールやファイアウォール ポリシーを交換しません。

VPC ファイアウォール ルールの場合:

  • ネットワーク タグを使用してターゲットが定義されているファイアウォール ルールは、ファイアウォール ルールの VPC ネットワーク内のインスタンスにのみ解決されます。ピアリングされた VPC ネットワークのセキュリティ管理者は、同じネットワーク タグを使用して、ピアリングされた VPC ネットワーク内のファイアウォール ルールのターゲットを定義できますが、ピアリングされた VPC のファイアウォール ルールのターゲットに VPC ネットワーク内のインスタンスは含まれません。同様に、送信元がネットワーク タグを使用して定義されている上り（内向き）ファイアウォール ルールは、ファイアウォール ルールの VPC ネットワーク内のインスタンスにのみ解決されます。

  • サービス アカウントを使用してターゲットが定義されているファイアウォール ルールは、ファイアウォール ルールの VPC ネットワーク内のインスタンスに対してのみ解決されます。IAM 権限に応じて、ピアリングされた VPC ネットワークのセキュリティ管理者は、同じサービス アカウントを使用して、ピアリングされた VPC ネットワーク内のファイアウォール ルールのターゲットを定義できますが、ピアリングされる VPC ネットワーク内のファイアウォール ルールのターゲットには、VPC ネットワーク内のインスタンスは含まれません。同様に、送信元がサービス アカウントを使用して定義されている上り（内向き）ファイアウォール ルールは、ファイアウォール ルールの VPC ネットワーク内のインスタンスにのみ解決されます。

ネットワーク ファイアウォール ポリシーのルールでは、ネットワーク タグとは異なるセキュアなタグを使用して、ターゲットとソースを識別できます。

  • ネットワーク ファイアウォール ポリシーの上り（内向き）ルールまたは下り（外向き）ルールのターゲットを指定する場合、タグを使用すると、タグの対象となる VPC ネットワーク内のターゲットのみを識別できます。

  • ネットワーク ファイアウォール ポリシーの上り（内向き）ルールの送信元を指定する場合、タグを使用すると、タグの対象である VPC ネットワークと、その VPC ネットワークに接続している任意のピアリングされた VPC ネットワークの両方で送信元を識別できます。詳細については、ファイアウォールのタグをご覧ください。

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

暗黙の下り（外向き）許可ファイアウォール ルールのため、ピアリングされた VPC ネットワークの宛先へのパケットを許可する下り（外向き）許可ファイアウォール ルールまたはファイアウォール ポリシーのルールを作成する必要はありません。

DNS のサポート

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

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

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

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

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

ピアリング グループと割り当て

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

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

制限事項

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

ピアリングされた VPC ネットワーク間でサブネット IP 範囲を重複できない

サブネット IP 範囲には、ピアリングされた VPC ネットワーク内の他のサブネット IP 範囲と完全に一致する範囲、他のサブネット IP 範囲に含まれる範囲、または他のサブネット IP 範囲内に収まる範囲は設定できません。ピアリング時に、Google Cloud は重複する IP 範囲のサブネットの存在を確認します。存在する場合、ピアリングは失敗します。すでにピアリングされたネットワークで、新しいサブネット ルートを作成する場合、Google Cloud では、新しいサブネット ルートに一意の宛先 IP アドレス範囲が必要です。

新しいサブネットを作成する前に、ピアリング接続のルートを一覧表示して、新しいサブネットの IPv4 アドレス範囲がすでに使用されていないことを確認できます。

この制限と Google Cloud の対応するチェックは、次のようなシナリオにも適用されます。

  • VPC ネットワーク network-1 が 2 番目の VPC ネットワーク network-2 とピアリングされている。
  • network-2 が、3 番目の VPC ネットワーク network-3 ともピアリングされている。
  • network-3 は network-1 とピアリングされていない。

このシナリオでは、network-2 のネットワーク管理者と調整する必要があります。network-2 のネットワーク管理者から、VPC ネットワークのピアリング ルートのリストを取得します。

重複チェックの詳細については、サブネットとピアリング サブネット ルートの相互作用をご覧ください。

ピアリングされたネットワークで内部 DNS 名が解決されない

ネットワークで作成された Compute Engine 内部 DNS 名では、ピアリングされたネットワークにアクセスできません。ピアリングされたネットワーク内の VM インスタンスにアクセスするには、VM の IP アドレスを使用します。

ピアリングされたネットワーク間でタグとサービス アカウントを使用できない

ファイアウォール ルールで、ピアリングされたネットワークの VM に関連するタグまたはサービス アカウントを他のピアリングされたネットワークで参照することはできません。たとえば、ピアリングされたネットワークの上り（内向き）ルールがタグに基づいて送信元をフィルタリングしている場合、ピアリングされたネットワーク内の VM にそのタグが設定されていても、ピアリングではなく、そのネットワーク内から送信された VM トラフィックにのみルールが適用されます。サービス アカウントの場合も同様の状況になります。

ルート交換オプション

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

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

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

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

VPC ネットワーク ピアリングでは、次の機能はありません。

  • 特定のサブネット ルート、静的ルート、動的ルートの交換を制御する詳細な方法。
  • ポリシーベースのルートの交換のサポート。

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

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

ルートのタイプ ルートのエクスポート条件 ルートのインポート条件
プライベート 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 静的ルート（ネットワーク タグなし） デフォルトではエクスポートされない

エクスポートは --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 ネットワークのネットワーク管理者は、--export-custom-routes フラグを使用して、そのネットワークの静的ルートと動的ルートのエクスポートを一緒に制御します。対応するピアリングされた VPC ネットワークのネットワーク管理者は、--import-custom-routes フラグを使用して静的ルートと動的ルートのインポートを制御します。詳しくは無視されたルート、サブネットとピアリング サブネット ルートの相互作用、サブネットと静的ルートの相互作用をご覧ください。

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

  • ピアリングされた VPC ネットワークにルートベースの GKE クラスタがあり、それらのクラスタ内の Pod にパケットを送信する必要がある場合。Pod IP アドレスは、ピアリングされた VPC ネットワークにある静的ルートの宛先範囲として実装されます。

  • オンプレミス ネットワークとピアリングされた VPC ネットワークの間の接続を提供する必要がある場合。ローカル VPC ネットワークに、ネクストホップの Cloud VPN トンネル、Cloud Interconnect アタッチメント（VLAN）、またはオンプレミス ネットワークに接続するルーター アプライアンスが存在する動的ルートが含まれているとします。ピアリングされた VPC ネットワークからオンプレミス ネットワークへのパスを提供するには、ローカル VPC ネットワークのネットワーク管理者がカスタムルートのエクスポートを有効にし、ピアリングされた VPC ネットワークのネットワーク管理者がカスタムルートのインポートを有効にします。オンプレミス ネットワークからピアリングされた VPC ネットワークへのパスを指定するには、オンプレミス ネットワークに接続する Cloud VPN トンネル、Cloud Interconnect アタッチメント（VLAN）、またはルーター アプライアンスの BGP セッションを管理する Cloud Router で、ローカル VPC ネットワークのネットワーク管理者が Cloud Router のカスタム アドバタイズ モードを構成する必要があります。これらのカスタム アドバタイズ ルートには、ピアリングされた VPC ネットワークのサブネット IP アドレス範囲が含まれている必要があります。

無視されるルート

次のような状況では、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 内に収められている （例: 2001:0db8:0a0b:0c0d::/96） VPC ネットワークには、ピアリング接続を確立できません。

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

    • 逆に、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 のピアリング接続は --export-custom-routes フラグで構成し、network-a のピアリング接続は --import-custom-routes フラグで構成します。
グローバル動的ルーティングを使用したピアリング ネットワーク。
グローバル動的ルーティングを使用してオンプレミス ネットワークにアクセスするピアリング ネットワーク（クリックして拡大）

オンプレミスから 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 がオンプレミス ネットワークに接続され、他の 2 つのネットワーク network-a と network-c のトランジット ネットワークとして機能するシナリオを考えてみましょう。両方のネットワーク内の VM が内部 IP アドレスのみを使用して、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 へのピアリング接続は、--export-custom-routes フラグで構成します。network-a から network-b と network-c から network-b へのピアリング接続は、--import-custom-routes フラグで構成します。
他の 2 つの VPC ネットワークとピアリングされた VPN トンネルを含むトランジット VPC ネットワーク。
VPC トランジット ネットワーク（クリックして拡大）

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

  • 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 インスタンスは相互に通信を行うことができません。

料金

VPC ネットワーク ピアリングには通常のネットワーク料金が適用されます。

次のステップ