RPCを使用したリモートVCNピアリング

このトピックでは、リモートVCNピアリングについて説明します。この場合、リモートとは、VCNが異なるリージョンに存在することを意味します。接続する各VCNが同じリージョン内にある場合は、ローカル・ピアリング・ゲートウェイを使用したローカルVCNピアリングを参照してください。

このシナリオではレガシーDRGを使用していることを前提としていますが、アップグレードされたDRGを使用したDRGを介した異なるリージョンのVCNのピアリングで使用されるアプローチは、Oracleからの現在の推奨です。

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

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

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

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

  • リモート・ピアリングをサポートしている異なるリージョンに存在する、CIDRが重複していない2つのVCN。

    ノート

    いずれのVCN CIDRにも重複がないことが必要

    ピアリング関係にある2つのVCNに、重複するCIDRがないことが必要です。また、ある特定のVCNが複数のピアリング関係を持つ場合、他のVCN間で重複するCIDRがないことも必要です。たとえば、VCN-1がVCN-2とピアリングされ、さらにVCN-3ともピアリングされている場合、VCN-2とVCN-3に重複するCIDRがない必要があります。

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

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

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

ノート

いずれのVCNも、接続されたRPCを使用して、もう一方のVCNまたはオンプレミス・ネットワーク内のVNICにのみアクセスできます。VCNの外側にある宛先(インターネットなど)にはアクセスできません。たとえば、前の図のVCN-1にインターネット・ゲートウェイがある場合、VCN-2のインスタンスがそれを使用してインターネット上のエンドポイントにトラフィックを送信することはできません。詳細は、ピアリングの重要な意味を参照してください。

スポークツースポーク: 転送ルーティングを使用するリモート・ピアリング

ノートこの

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

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

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

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

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

両方の側から必要な明示的合意

ピアリングは、同じ当事者または異なる2つの当事者が管理する、同じテナンシ内の2つのVCNの間で行われます。2つの当事者は、どちらも自分の会社に存在していても、異なる部門に属する場合があります。

2つのVCN間のピアリングでは、各当事者が独自のVCNのコンパートメントに対して実装するOracle Cloud Infrastructure Identity and Access Managementポリシーの形式で、両方の当事者からの明示的な合意が必要です。

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

次の概念は、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構成の詳細は、リモート・ピアリングの設定を参照してください。
アクセプタおよびリクエスタ
ピアリングに必要なIAMポリシーを実装するには、2人のVCN管理者が1人の管理者をリクエスタとして、もう1人をアクセプタとして指定する必要があります。リクエスタは、2つのRPCを接続するリクエストを開始する必要があります。一方、アクセプタは、アクセプタのコンパートメント内のRPCに接続するためのリクエスタ権限を付与する特定のIAMポリシーを作成する必要があります。このポリシーがないと、リクエスタの接続リクエストは失敗します。
リージョン・サブスクリプション
別のリージョン内のVCNとピアリングするには、テナンシがそのリージョンにサブスクライブされている必要があります。サブスクライブの詳細は、リージョンの管理を参照してください。
リモート・ピアリング接続(RPC)
リモート・ピアリング接続(RPC)は、VCNにアタッチされたDRG上に作成するコンポーネントです。RPCの役割は、リモートにピアリングされたVCNの接続ポイントとなることです。VCNの構成の一部として、各管理者はVCN上にDRGのRPCを作成する必要があります。いずれのDRGも、VCNに対して確立するリモート・ピアリングごとに別々のRPCが必要です(テナンシ当たりのRPCの最大数は10)。前の例から続行する場合: 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から他方にルーティングされるトラフィックのルート表およびパスを示しています。
ノート

前述したように、どちらのVCNも、接続されたRPCを使用して、もう一方のVCN内のVNICにのみアクセスできます。VCNの外側にある宛先(インターネットやオンプレミス・ネットワークなど)にはアクセスできません。たとえば、前の図で、VCN-2はVCN-1にアタッチされたインターネット・ゲートウェイを使用できません。

セキュリティ・ルール
VCNの各サブネットには、パケット・レベルでサブネットのVNIC内外のトラフィックを制御する1つ以上のセキュリティ・リストがあります。セキュリティ・リストを使用して、他のVCNで許可されるトラフィックのタイプを制御できます。VCN構成の一環として、各管理者は、自分のVCN内のどのサブネットが他のVCN内のVNICと通信する必要があるかを判断し、それに応じてサブネットのセキュリティ・リストを更新する必要があります。
ネットワーク・セキュリティ・グループ(NSG)を使用してセキュリティ・ルールを実装する場合、トラフィックのソースまたは宛先として別のNSGを指定するNSG用セキュリティ・ルールを記述するオプションがあることに注意してください。ただし、2つのNSGは同じVCNに属している必要があります

ピアリングの重要な意味

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

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

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

重要

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

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

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

タスク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. Open the navigation menu. Under Core Infrastructure, go to Networking and click Dynamic Routing Gateway.

  3. 目的のDRGをクリックします。
  4. 「リソース」で、「リモート・ピアリング接続」をクリックします。
  5. 「リモート・ピアリング接続の作成」をクリックします。
  6. 次を入力します:

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

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

  8. 自分がアクセプタである場合は、後でリクエスタに渡すRPCのリージョンおよびOCIDを記録しておきます。
タスクB: 情報の共有
  • 自分がアクセプタである場合は、次の情報をリクエスタに提供します(電子メールや他のアウト・オブ・バンド方式などを使用):

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

    • 自分のVCNが含まれるリージョン(アクセプタのテナンシはこのリージョンにサブスクライブされている必要があります)。
    • アクセプタのコンパートメント内に接続を作成する権限を付与される必要があるIAMグループの名前(次のタスクの例では、RequestorGrpがそのグループです)。
    • 他方のVCNで使用可能にする必要がある、自分のVCN内のサブネットのCIDRブロック。アクセプタは、アクセプタVCNのルーティングを設定するときにこの情報を必要とします。
タスクC: IAMポリシーの設定(同じテナンシ内のVCN)

リクエスタとアクセプタの両方が、適切なポリシーが有効であることを確認する必要があります:構成内容は次のとおりです:

  • ポリシーR (リクエスタによる実装):

    Allow group RequestorGrp to manage remote-peering-from in compartment RequestorComp

    リクエスタは、RequestorGrpというIAMグループに属しています。このポリシーによって、グループ内のすべてのユーザーが、リクエスタのコンパートメント(RequestorComp)の任意のRPCから接続を開始できます。ポリシーRは、テナンシ(ルート・コンパートメント)またはRequestorCompにアタッチできます。これを一方または他方にアタッチする理由の詳細は、ポリシーの基本を参照してください。

  • ポリシーA (アクセプタによる実装):

    Allow group RequestorGrp to manage remote-peering-to in compartment AcceptorComp
    

    このポリシーを使用すると、リクエスタはアクセプタのコンパートメント(AcceptorComp)内の任意のRPCに接続できます。このステートメントは、ピアリングを確立するためのアクセプタからの必要な合意を反映します。ポリシーAは、テナンシ(ルート・コンパートメント)またはAcceptorCompにアタッチできます。

この図は、同じテナンシ内の異なるリージョンにあるVCNに対する2つのポリシーを示しています。

ポリシーRとポリシーAの両方がRequestorGrpにアクセス権を付与します。ただし、ポリシーRにはremote-peering-fromというリソース・タイプがあり、ポリシーAにはremote-peering-toというリソース・タイプがあります。まとめると、これらのポリシーにより、RequestorGrpのユーザーは、リクエスタのコンパートメント内のRPCからアクセプタのコンパートメント内のRPCへの接続を確立できます。実際に接続を作成するAPIコールで、2つのRPCを指定します。

ヒント

別のポリシーでRequesterCompのすべてのネットワーキング・コンポーネントを管理する権限をリクエスタが持っている場合は、ポリシーRによって付与される権限がすでに有効である可能性があります。たとえば、Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorCompのような一般的なネットワーク管理ポリシーが存在する場合があります。リクエスタがNetworkAdminグループに属している場合、ポリシーRでカバーされる必要な権限をすでに持っています(virtual-network-familyにRPCが含まれます)。さらに、テナンシ全体をカバーするようにポリシーが記述されている場合(Allow group NetworkAdmin to manage virtual-network-family in tenancy)、リクエスタは、接続を確立するために必要な権限を両方のコンパートメントですでに持っています。その場合、ポリシーAは必要ありません。
タスクD: 接続の確立

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

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

  • アクセプタのVCNが含まれるリージョン(リクエスタのテナンシはこのリージョンにサブスクライブされている必要があります)。
  • アクセプタのRPCのOCID。
  1. コンソールで、アクセプタRPCに接続するリクエスタRPCの詳細を表示します。
  2. 「接続の確立」をクリックします。
  3. 次を入力します:

    • リージョン: アクセプタのVCNが含まれるリージョン。ドロップダウン・リストには、リモートVCNピアリングをサポートし、かつテナンシがサブスクライブされているリージョンのみが含まれます。
    • リモート・ピアリング接続OCID: アクセプタのRPCのOCID。
  4. 「接続の確立」をクリックします。

接続が確立され、RPCの状態がPEEREDに変わります。

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

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

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

自分のVCNについて:

  1. VCN内のどのサブネットが他方のVCNと通信する必要があるかを判断します。
  2. それらの各サブネットのルート表を更新し、他方のVCN宛のトラフィックをDRGに転送する新しいルールを含めます:

    1. ナビゲーション・メニューを開き、「ネットワーキング」「仮想クラウド・ネットワーク」の順にクリックします。
    2. 目的のVCNをクリックします。
    3. 「リソース」で、「ルート表」をクリックします。
    4. 目的のルート表をクリックします。
    5. 「ルート・ルールの追加」をクリックし、次の情報を入力します:

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

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

ヒント

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

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

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

どのルールを追加する必要がありますか。

  • 他方のVCN (特にVCNのCIDRや特定のサブネット)から許可するトラフィックのタイプに関するイングレス・ルール。
  • 自分のVCNから他方のVCNへの送信トラフィックを許可するエグレス・ルール。サブネットに、すべての宛先(0.0.0.0/0)へのすべてのタイプのプロトコルに対応する広範囲のエグレス・ルールがすでにある場合は、他方のVCN用に特別なルールを追加する必要はありません。
ノート

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

自分のVCNについて:

  1. VCN内のどのサブネットが他方のVCNと通信する必要があるかを判断します。
  2. それらの各サブネットのセキュリティ・リストを更新して、目的の(他方のVCNのCIDRブロックまたはサブネットを使用する)エグレス・トラフィックまたはイングレス・トラフィックを許可するルールを含めます:

    1. コンソールで、目的のVCNを表示している状態で、「セキュリティ・リスト」をクリックします。
    2. 関心のあるセキュリティ・リストをクリックします。
    3. 「リソース」で、使用するルールのタイプに応じて、「イングレス・ルール」または「エグレス・ルール」のいずれかをクリックします。
    4. 新しいルールを追加する場合は、「イングレス・ルールの追加」(または「エグレス・ルールの追加」)をクリックします。

    5. 既存のルールを削除する場合は、「アクション」アイコン(3つのドット)をクリックして、「削除」をクリックします。
    6. 既存のルールを編集する場合は、「アクション」アイコン(3つのドット)をクリックして、「編集」をクリックします。

セキュリティ・ルールの詳細は、セキュリティ・ルールを参照してください。

他方のVCN CIDRからのイングレスHTTPS (ポート443)トラフィックを有効化するステートフル・ルールを追加するとします。ルールを追加する際の基本的なステップは次のとおりです:

  1. 「イングレスのルール許可」セクションで、「+ルールの追加」をクリックします。
  2. 「ステートレス」チェック・ボックスは選択を解除したままにします。
  3. ソース・タイプ: 「CIDR」のままにします。
  4. ソースCIDR: ルート・ルールで使用するのと同じCIDRブロックを入力します(タスクE: ルート表の構成を参照)。
  5. IPプロトコル: TCPのままにします。
  6. ソース・ポート範囲: 「すべて」のままにします。
  7. 宛先ポート範囲: 443と入力します。
  8. 説明: ルールのオプションの説明。

コンソールの使用

リモート・ピアリング接続を削除するには

RPCを削除すると、ピアリングは終了します。ピアリングの反対側のRPCが、REVOKED状態に変わります。

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Dynamic Routing Gateway.

  2. 目的のDRGをクリックします。
  3. 「リソース」で、「リモート・ピアリング接続」をクリックします。
  4. 目的のRPCをクリックします。
  5. 「終了」をクリックします。
  6. プロンプトが表示されたら確認します。
ノート

RPCを削除した後(つまり、ピアリングを終了した後)、セキュリティ・ルールを確認して、他方のVCNとのトラフィックを有効にしていたルールを削除することをお薦めします。

APIの使用

APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKの詳細は、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。

RPCを管理して接続を作成するには、次の操作を使用します: