アップグレード済DRGを介したリモートVCNピアリング

リモートVCNピアリングの概要

リモート・ピアリングのネットワーキング・コンポーネントのサマリー

リモート・ピアリングに必要なネットワーキング・サービス・コンポーネントの概要は次のとおりです:

• 異なるリージョンで、CIDRが重複しない2つのVCNs。

  ノート
  
  

  VCN CIDRは重複できません

  ピアリング関係内の2つのVCNsに重複するCIDRを含めることはできません。Also, if a particular VCN has several peering relationships, those other VCNs can't have CIDRs that overlap with each other.たとえば、VCN-1がVCN-2とピアリングされ、さらにVCN-3ともピアリングされている場合、VCN-2とVCN-3に重複するCIDRがない必要があります。

  このシナリオを構成する場合は、プランニング・ステージでこの要件を満たす必要があります。CIDRが重複している場合にルーティングの問題が発生する可能性がありますが、コンソールまたはAPI操作によって、問題の原因となる構成を作成できなくなることはありません。

• ピアリング関係の各VCNにアタッチされたDynamic Routing Gateway (DRG)。サイト間VPN IPSecトンネルまたはOracle Cloud Infrastructure FastConnectプライベート仮想回線を使用している場合、VCNにはすでにDRGがあります。
• ピアリング関係にある各DRG上のリモート・ピアリング接続(RPC)。
• その2つのRPCの間の接続。
• トラフィックがその接続を介して、また(必要な場合は)各VCN内の選択サブネットとの間でのみ流れることを可能にする、サポート・ルート・ルール。
• 他のVCNと通信する必要があるサブネット内のインスタンス間で許可されるトラフィックのタイプを制御する、サポート・セキュリティ・ルール。

次の図は、これらのコンポーネントを示しています。

ピアリングの重要な意味

まだ参照していない場合は、ピアリングの重要な意味を読んで、ピアリングされたVCNのアクセス制御、セキュリティおよびパフォーマンスに対する重要な影響を理解してください。

異なるテナンシのVCNのピアリングには、両方のテナンシで解決する必要がある権限の問題がいくつかあります。必要な権限の詳細は、VCNs間のルーティングのIAMポリシーを参照してください。

スポークツースポーク: 転送ルーティングを使用するリモート・ピアリング(レガシーDRGのみ)

次の図に示すように、各リージョンで複数のVCNsがハブアンドスポーク・レイアウトにあるとします。リージョン内のこのタイプのレイアウトについては、ハブVCN内の転送ルーティングで詳しく説明しています。リージョン内のスポークVCNsは、ローカル・ピアリング・ゲートウェイを使用して、同じリージョン内のハブVCNとローカルにピアリングされます。

2つのハブVCNの間にリモート・ピアリングを設定できます。さらに、ハブVCN内の転送ルーティングで説明されているように、ハブVCNのDRGとLPGに転送ルーティングを設定することもできます。This setup lets a spoke VCN in one region to communicate with one or more spoke VCNs in the other region without needing a remote peering connection directly between those VCNs.

たとえば、VCN-1-A内のリソースがハブVCNを経由してVCN-2-AおよびVCN-2-B内のリソースと通信できるように、ルーティングを構成できます。That way, VCN 1-A isn't required to have a separate remote peering with each of the spoke VCNs in the other region.また、VCN-1-Bが独自のリモート・ピアリングを持たずにリージョン2内の各スポークVCNと通信できるようにルーティングを設定することもできます。

スポークツースポーク: 転送ルーティングを使用するリモート・ピアリング(アップグレードされたDRG)

次の図に示すように、各リージョンで複数のVCNsがハブアンドスポーク・レイアウトにあるとします。リージョン内のこのタイプのレイアウトについては、ハブVCN内の転送ルーティングで詳しく説明しています。リージョン内のスポークVCNsは、DRGへの相互接続によって、同じリージョン内のハブDRG/VCNペアでローカルにピアリングされます。

2つのハブVCNs間にリモート・ピアリングを設定できます。その後、中央のネットワーク仮想アプライアンスを介してトラフィックをルーティングするためのDRGの説明に従って、ハブVCNの転送ルートを設定することもできます。This setup lets a spoke VCN in one region to communicate with one or more spoke VCNs in the other region without needing a remote peering connection directly between those VCNs.

たとえば、VCN-1-A内のリソースがハブVCNを経由してVCN-2-AおよびVCN-2-B内のリソースと通信できるように、ルーティングを構成できます。That way, VCN 1-A isn't required to have a separate remote peering with each of the spoke VCNs in the other region.また、VCN-1-Bが独自のリモート・ピアリングを持たずにリージョン2内の各スポークVCNと通信できるようにルーティングを設定することもできます。

リモート・ピアリングの重要な概念

次の概念は、VCNピアリングの基本およびリモート・ピアリングの確立方法を理解するのに役立ちます。

ピアリング

ピアリングは、2つのVCN間の単一のピアリング関係です。例: VCN-1が他の2つのVCNとピアリングしている場合、2つのピアリングが存在します。リモート・ピアリングのリモートという部分は、VCNが異なるリージョンに存在することを示します。このリモート・ピアリング方法では、VCNは同じテナンシに存在することも、異なるテナンシに存在することもできます。

VCN管理者

通常、VCNピアリングは、両方のVCN管理者が同意している場合にのみ実行できます。実際には、2人の管理者が次を行う必要があります:

• 一定の基本情報を相互に共有します。
• ピアリングを有効にするために必要なOracle Cloud Infrastructure Identity and Access Managementポリシーを設定するように調整します。
• ピアリング用にVCNを構成します。

状況によっては、一方の管理者が両方のVCNおよび関連ポリシーを担当します。VCNは同じテナンシに存在することも、異なるテナンシに存在することもできます。

必要なポリシーおよびVCN構成の詳細は、VCNs間のルーティングのためのIAMポリシーを参照してください。

アクセプタおよびリクエスタ

ピアリングに必要なIAMポリシーを実装するには、2人のVCN管理者が1つの管理者をリクエスタとして、もう1人をアクセプタとして指定する必要があります。2つのRPCを接続する要求を開始するには、リクエスタがリクエスタである必要があります。次に、アクセプタは、アクセプタのコンパートメント内のRPCに接続する権限をリクエスタに付与する特定のIAMポリシーを作成する必要があります。このポリシーがないと、リクエスタの接続リクエストは失敗します。

リージョン・サブスクリプション

別のリージョン内のVCNとピアリングの際には、まずテナンシがそのリージョンにサブスクライブされている必要があります。サブスクライブの詳細は、リージョンの管理を参照してください。

リモート・ピアリング接続(RPC)

リモート・ピアリング接続(RPC)は、VCNにアタッチされたDRG上に作成するコンポーネントです。RPCの役割は、リモートにピアリングされたVCNの接続ポイントとなることです。VCNの構成の一部として、各管理者はVCN上にDRGのRPCを作成する必要があります。DRGには、VCNに対して確立されるリモート・ピアリングごとに個別のRPCが必要です。前の例から続行する場合: VCN-1のDRGには、他の2つのVCNとピアリングするための2つのRPCがあります。APIでは、RemotePeeringConnectionはピアリングに関する情報を含むオブジェクトです。後で別のピアリングを確立するためにRPCを再利用することはできません。

2つのRPC間の接続

リクエスタがピア(コンソールまたはAPI)へのリクエストを開始すると、2つのRPCを接続するように求められます。リクエスタは各RPCを特定する情報(RPCのリージョンやOCIDなど)を持っている必要があります。

どちらのVCN管理者でも、RPCを削除することでピアリングを終えることができます。その場合、もう一方のRPCのステータスがREVOKEDに切り替わります。管理者は、接続間のトラフィック・フローを許可するルート・ルールを削除することで、接続を一時的に無効にできます(次の項を参照)。

DRGへのルーティング

VCN構成の一環として、各管理者は、VCN間のトラフィック・フローを可能にするようにVCNのルーティングを更新する必要があります。他のVCNと通信する必要があるサブネットごとに、サブネットのルート表を更新します。ルート・ルールでは、宛先トラフィックのCIDRとDRGをターゲットとして指定します。The DRG routes traffic that matches that rule to the other DRG, which in turn routes the traffic to the next hop in the other VCN.

次の図で、VCN-1とVCN-2はピアリングされています。サブネットA (10.0.0.15)のインスタンスからのトラフィックのうち、VCN-2 (192.168.0.15)のインスタンスに対して送信されるものは、サブネットAのルート表にあるルールに基づいてDRG-1にルーティングされます。トラフィックは、そこからRPCを介してDRG-2にルーティングされ、さらにサブネットX内の宛先にルーティングされます。

コールアウト1: サブネットAルート表

宛先CIDR	ルート・ターゲット
0.0.0.0/0	インターネット・ゲートウェイ
192.168.0.0/16	DRG-1

コールアウト2: サブネットXルート表

宛先CIDR	ルート・ターゲット
10.0.0.0/16	DRG-2

ノート

前述のように、VCNは接続されたRPCを使用して、インターネット上の宛先ではなく、他のVCNまたはオンプレミス・ネットワーク内のVNICにのみ到達できます。たとえば、前の図で、VCN-2はVCN-1にアタッチされたインターネット・ゲートウェイを使用することはできません。

セキュリティ・ルール

VCNの各サブネットには、パケット・レベルでサブネットのVNIC内外のトラフィックを制御する1つ以上のセキュリティ・リストがあります。セキュリティ・リストを使用して、他のVCNで許可されるトラフィックのタイプを制御できます。As part of configuring the VCNs, each administrator must decide which subnets in their own VCN need to communicate with VNICs in the other VCN and update their subnet's security lists appropriately.

ネットワーク・セキュリティ・グループ(NSG)を使用してセキュリティ・ルールを実装する場合、トラフィックのソースまたは宛先として別のNSGを指定するNSG用セキュリティ・ルールを記述できることに注意してください。ただし、2つのNSGは同じVCNに属している必要があります。

ピアリングの重要な意味

まだ参照していない場合は、ピアリングの重要な意味を読んで、ピアリングされたVCNのアクセス制御、セキュリティおよびパフォーマンスに対する重要な影響を理解してください。

リモート・ピアリングの設定

この項では、異なるリージョンの2つのVCNs間のピアリングを設定するための一般的なプロセスについて説明します。

必要なステップの概要:

1. RPCの作成: 各VCN管理者は、自分のVCNのDRGにRPCを作成します。
2. 情報の共有: 管理者は基本的な必須情報を共有します。
3. 接続の確立: リクエスタが2つのRPCを接続します(リクエスタおよびアクセプタの定義については、リモート・ピアリングの重要な概念を参照)。
4. ルート表の更新:各管理者は、VCNのルート表を更新して、ピアリングされたVCNs間のトラフィックを意図したとおりに有効にします。
5. セキュリティ・ルールの更新:各管理者は、VCNのセキュリティ・ルールを更新して、ピアリングされたVCNs間のトラフィックを意図したとおりに有効にします。

必要に応じて、管理者は接続を確立する前にタスク4および5を実行できます。各管理者は、他のVCNのCIDRブロックまたは特定のサブネットを把握して、タスク2でそれを共有する必要があります。