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

このトピックでは、リモートVCNピアリングについて説明します。

この場合、リモートとは、仮想クラウド・ネットワーク(VCNs)がそれぞれ異なる動的ルーティング・ゲートウェイ(DRG)にアタッチされ、DRGが異なるリージョンに存在することも、同じリージョンに存在することもあることを意味します。接続するVCNが同じリージョン内にあり、同じDRGに接続されている場合は、アップグレードされたDRGを介したローカルVCNピアリングを参照してください。

ノート

このシナリオは、レガシーDRGでは異なるテナンシでのDRGの接続や複数のVCNのアタッチがサポートされていないことを除き、アップグレードまたはレガシーDRGで使用できます。DRGバージョンの詳細は、DRGバージョンを参照してください。

このシナリオを実装する前に、次を確認してください:

  • VCN AはDRG Aにアタッチされています
  • VCN BはDRG Bにアタッチされています
  • 両方のDRGのルーティング構成でデフォルト・ルート表が使用されています
  • 適切なIAM権限が同じテナンシまたは異なるテナンシにあるVCNに適用されます

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

リモートVCNピアリングは、異なるリージョン内の2つのVCNを接続するプロセスです。ピアリングにより、VCNsのリソースは、インターネットまたはオンプレミス・ネットワークを介してトラフィックをルーティングすることなく、プライベートIPアドレスを使用して通信できます。VCNsは、同じOracle Cloud Infrastructureテナンシまたは異なるテナンシに配置できます。ピアリングを行わない場合は、VCNは、異なるリージョン内の別のVCNと通信する必要があるインスタンスに対してインターネット・ゲートウェイおよびパブリックIPアドレスを必要にします。

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

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

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

    ノート

    VCN CIDRは重複できません

    ピアリング関係内の2つのVCNsに重複するCIDRを含めることはできません。また、特定のVCNに複数のピアリング関係がある場合、それらの他のVCNは相互に重複するCIDRを持つことはできません。たとえば、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と通信する必要があるサブネット内のインスタンス間で許可されるトラフィックのタイプを制御する、サポート・セキュリティ・ルール。

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

この図は、リモートでピアリングされた2つのVCNの基本レイアウトを示しています。それぞれがDRG上でリモート・ピアリング接続を使用しています
ノート

VCNは、接続されたRPCを使用して他のVCNのVNICに到達するか、DRGがオンプレミスに接続されている場合はオンプレミス・ネットワークに到達するかのみを使用できます。たとえば、前の図でVCN-1にインターネット・ゲートウェイがあった場合、VCN-2のインスタンスはそれを使用してインターネット上のエンドポイントにトラフィックを送信できませんでした。詳細は、ピアリングの重要な意味を参照してください。

ピアリングの重要な意味

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

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

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

ノート

この項で説明するシナリオは引き続きサポートされていますが、中央ネットワーク仮想アプライアンスを介したトラフィックのルーティングで説明されているDRG転送ルーティング方法を使用することをお薦めします。

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

2つのハブVCNの間にリモート・ピアリングを設定できます。さらに、ハブVCN内の転送ルーティングで説明されているように、ハブVCNのDRGとLPGに転送ルーティングを設定することもできます。この設定により、あるリージョン内のスポークVCNは、それらのVCNs間で直接リモート・ピアリング接続を必要とせずに、他のリージョン内の1つ以上のスポークVCNと通信できます。

たとえば、VCN-1-A内のリソースがハブVCNを経由してVCN-2-AおよびVCN-2-B内のリソースと通信できるように、ルーティングを構成できます。これにより、VCN 1-Aは、他のリージョンの各スポークVCNsと別個のリモート・ピアリングを持つ必要はありません。また、VCN-1-Bが独自のリモート・ピアリングを持たずにリージョン2内の各スポークVCNと通信できるようにルーティングを設定することもできます。

この図は、ハブアンドスポーク・レイアウトのVCNを含む2つのリージョンの基本レイアウトを示しています。ハブVCNの間にリモート・ピアリングを使用しています。

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

ノート

この項のシナリオでは、中央ネットワーク仮想アプライアンスを介したトラフィックのルーティングで説明されているDRG転送ルーティング方法を使用します。

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

2つのハブVCNs間にリモート・ピアリングを設定できます。その後、中央のネットワーク仮想アプライアンスを介してトラフィックをルーティングするためのDRGの説明に従って、ハブVCNの転送ルートを設定することもできます。この設定により、あるリージョン内のスポークVCNは、それらのVCNs間で直接リモート・ピアリング接続を必要とせずに、他のリージョン内の1つ以上のスポークVCNと通信できます。

たとえば、VCN-1-A内のリソースがハブVCNを経由してVCN-2-AおよびVCN-2-B内のリソースと通信できるように、ルーティングを構成できます。これにより、VCN 1-Aは、他のリージョンの各スポークVCNsと別個のリモート・ピアリングを持つ必要はありません。また、VCN-1-Bが独自のリモート・ピアリングを持たずにリージョン2内の各スポークVCNと通信できるようにルーティングを設定することもできます。

この図は、ハブアンドスポーク・レイアウトのVCNを含む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をターゲットとして指定します。DRGは、このルールに一致するトラフィックを他のDRGにルーティングします。これにより、さらにそこから他のVCNのネクストロップにトラフィックがルーティングされます。
次の図で、VCN-1とVCN-2はピアリングされています。サブネットA (10.0.0.15)のインスタンスからのトラフィックのうち、VCN-2 (192.168.0.15)のインスタンスに対して送信されるものは、サブネットAのルート表にあるルールに基づいてDRG-1にルーティングされます。トラフィックは、そこからRPCを介してDRG-2にルーティングされ、さらにサブネットX内の宛先にルーティングされます。
この図は、一方のDRGから他方にルーティングされるトラフィックのルート表およびパスを示しています。
コールアウト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で許可されるトラフィックのタイプを制御できます。VCNsの構成の一環として、各管理者は、他のVCN内のVNICと通信するために必要な独自のVCN内のサブネットを決定し、サブネットのセキュリティ・リストを適切に更新する必要があります。
ネットワーク・セキュリティ・グループ(NSG)を使用してセキュリティ・ルールを実装する場合、トラフィックのソースまたは宛先として別のNSGを指定するNSJ用セキュリティ・ルールを記述できることに注意してください。ただし、2つのNSGは同じVCNに属している必要があります。

ピアリングの重要な意味

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

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

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

重要

以降の手順では次のことを前提としています:

  • テナンシが他のVCNのリージョンにサブスクライブされていること。されていない場合は、リージョンの管理を参照してください。
  • VCNがDRGにすでにアタッチされていること。そうでない場合は、Dynamic Routing Gatewaysを参照してください。
  • 接続に必要なIAMポリシーがすでに設定されていること。同じテナンシ内のリモート・ピアリングおよびテナンシ間のIAMポリシーは異なります。VCNs間のルーティングのIAMポリシーを参照してください

必要なステップの概要:

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

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

タスクA: RPCの作成

各管理者は、自分のVCNのDRGにRPCを作成します。次の手順での「自分」は、管理者(アクセプタまたはリクエスタ)を意味します。

ノート

RPCを作成するために必要なIAMポリシー

管理者にすでに幅広いネットワーク管理者権限がある場合(ネットワーク管理者によるクラウド・ネットワークの管理を参照)、RPCを作成、更新および削除する権限があります。それ以外の場合、RPCAdminsというグループに必要な権限を付与するポリシーの例を次に示します。RPCを作成すると所属するDRGに影響するため、管理者にはDRGを管理する権限が必要であり、2番目のステートメントが必要となります。

Allow group RPCAdmins to manage remote-peering-connections in tenancy
Allow group RPCAdmins to manage drgs in tenancy
  1. コンソールで、RPCを追加するDRGを含むコンパートメントを表示していることを確認します。コンパートメントとアクセス制御の詳細は、アクセス制御に関する項を参照してください。
  2. ナビゲーション・メニューを開き、「ネットワーキング」を選択します。「顧客接続」で、「動的ルーティング・ゲートウェイ」を選択します。
  3. 目的のDRGを選択します。
  4. 「リソース」で、「リモート・ピアリング接続アタッチメント」を選択します。
  5. 「リモート・ピアリング接続の作成」を選択します。
  6. 次を入力します:

    • 名前: RPCのわかりやすい名前。必ずしも一意である必要はありませんが、後でコンソールで変更することはできません(ただし、APIで変更できます)。機密情報の入力は避けてください。
    • コンパートメントに作成: RPCを作成するコンパートメント(作業しているコンパートメントと異なる場合)。
  7. 「リモート・ピアリング接続の作成」を選択します。

    これにより、RPCが作成され、選択したコンパートメントの「リモート・ピアリング接続」ページに表示されます。

  8. 自分がアクセプタである場合は、後でリクエスタに渡すRPCのリージョンおよびOCIDを記録しておきます。
  9. 2つのVCNsが異なるテナンシにある場合は、このテナンシのOCIDを記録します(コンソールのページの下部にあります)。後で他の管理者にOCIDを提供します。
タスクB: 情報の共有

このタスクは、クロステナンシ接続に固有です。接続が同じテナンシ内にある場合は、次のタスクにスキップできます。

  • 自分がアクセプタである場合は、次の情報をリクエスタに提供します(電子メールや他のアウト・オブ・バンド方式などを使用):

    • VCNが存在するリージョン(リクエスタのテナンシがこのリージョンにサブスクライブされている必要があります)。
    • RPCのOCID。
    • 他のVCNで使用可能にする、VCN内のサブネットのCIDRブロック。リクエスタは、リクエスタVCNのルーティングを設定するときにこの情報を必要とします。
    • VCNsが異なるテナンシにある場合: アクセプタ・テナンシのOCID。
  • 自分がリクエスタである場合は、次の情報をアクセプタに提供します:

    • VCNが存在するリージョン(アクセプタのテナンシがこのリージョンにサブスクライブされている必要があります)。
    • VCNsが同じテナンシにある場合: アクセプタのコンパートメントに接続を作成する権限を付与されたIAMグループの名前。
    • VCNsが異なるテナンシにある場合: リクエスタ・テナンシのOCID。
    • 他のVCNで使用可能にする、VCN内のサブネットのCIDRブロック。アクセプタは、アクセプタVCNのルーティングを設定するときにこの情報を必要とします。
タスクC: 接続の確立

リクエスタがこのタスクを実行する必要があります。

前提条件: リクエスタが次のものを持っている必要があります:

  • アクセプタのVCNが含まれるリージョン(リクエスタのテナンシはこのリージョンにサブスクライブされている必要があります)。
  • アクセプタのRPCのOCID。
  • アクセプタのテナンシのOCID (アクセプタのVCNが異なるテナンシにある場合のみ)

2つのリモート・ピアリング接続の接続の手順を参照してください。RPCに関連するその他のタスクについては、「リモート・ピアリング管理」を参照してください。

タスクD: ルート表の構成

前述のように、各管理者は接続の確立前後にこのタスクを実行できます。

前提条件: 各管理者には、他のVCNのCIDRブロックまたは特定のサブネットが必要です。

VCNごとに、ローカルVCN内のどのサブネットが他のVCNと通信する必要があるかを決定します。次に、それらの各サブネットのルート表を更新します。このルート表には、他方のVCN宛のトラフィックがローカルDRGに転送される新しいルールが含まれます。VCNルート表のルールの更新を参照し、次の設定を使用するルート・ルールを追加します:

  • ターゲット・タイプ: 動的ルーティング・ゲートウェイ。VCNのアタッチされているDRGがターゲットとして自動的に選択されるため、ターゲットを自分で指定する必要はありません。
  • 宛先CIDRブロック: 他方のVCN CIDRブロック。例では、10.0.0.0/16および192.68.0.0/16を持つVCNsを使用します。必要に応じて、ピアリングされたVCN CIDRの任意のサブネットまたは特定のサブセットを指定できます。
  • 説明: ルールのオプションの説明。

ルールに一致する宛先のサブネット・トラフィックは、ローカルDRGにルーティングされます。ルート・ルールの設定の詳細は、VCNルート表を参照してください。

ヒント

必要なルーティングがない場合、トラフィックはピアリングされたDRG間を流れません。ピアリングを一時的に停止する必要がある状況が発生した場合は、トラフィックを有効にするルート・ルールを削除できます。RPCを削除する必要はありません。
タスクE: セキュリティ・ルールの構成

前述のように、各管理者は接続の確立前後にこのタスクを実行できます。

前提条件: 各管理者には、他のVCNのCIDRブロックまたは特定のサブネットが必要です。通常は、タスクD: ルート表のルールの構成にあるルート表のルールで使用したのと同じCIDRブロックを使用します。

次のルールを追加することをお薦めします。

  • 他のVCNのCIDRまたは特定のサブネットから許可するトラフィックのタイプのイングレス・ルール。例では、10.0.0.0/16および192.68.0.0/16を持つVCNsを使用します。
  • ローカルVCNから他のVCNへの送信トラフィックを許可するためのエグレス・ルール。サブネットに、すべての宛先(0.0.0.0/0)へのすべてのタイプのプロトコルに対応する広範囲のエグレス・ルールがすでにある場合は、他方のVCN用に特別なルールを追加する必要はありません。
ノート

次の手順ではセキュリティ・リストを使用しますが、かわりにネットワーク・セキュリティ・グループにセキュリティ・ルールを実装し、サブネットのリソースをそのNSGに作成することもできます。

VCNごとに、ローカルVCN内のどのサブネットが他のVCNと通信する必要があるかを決定します。次に、それらの各サブネットのセキュリティ・リストを更新します。これには、他のVCNのCIDRブロックまたはサブネットを使用する、目的のエグレス・トラフィックまたはイングレスのトラフィックを許可するためのルールが含まれます。セキュリティ・リストのルールの更新およびセキュリティ・リストの作成(セキュリティ・ルールで使用可能なオプションの詳細は)を参照してください。

セキュリティ・ルールの一般情報は、セキュリティ・ルールに関する項を参照してください。