レガシーDRGを使用したリモートVCNピアリング

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

ノート

この記事では、DRGがレガシーDRGであることを前提としており、アップグレードされたDRGについて「アップグレードされたDRGを介したリモートVCNピアリング」で説明されている方法をお薦めします。DRGバージョンの説明は、DRGバージョンを参照してください。

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

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

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

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

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

    ノート

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

    ピアリング関係にある2つのVCNに、重複するCIDRがないことが必要です。Also, if a particular VCN has several peering relationships, those other VCNs must not have overlapping CIDRs with each other.たとえば、VCN-1がVCN-2とピアリングされ、さらにVCN-3ともピアリングされている場合、VCN-2とVCN-3に重複するCIDRがない必要があります。

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

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

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

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

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

ノート

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

次の図に示すように、各リージョンで複数のVCNsがハブアンドスポーク・レイアウトにあるとします。リージョン内のこのタイプのレイアウトについては、ハブVCN内の転送ルーティングで詳しく説明しています。The spoke VCNs in a particular region are locally peered with the hub VCN in the same region, using local peering gateways .

2つのハブVCNの間にリモート・ピアリングを設定できます。さらに、ハブVCN内の転送ルーティングで説明されているように、ハブVCNのDRGとLPGに転送ルーティングを設定することもできます。This setup lets a spoke VCN in one region 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の間にリモート・ピアリングを使用しています。

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

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

Peering between two VCNs requires explicit agreement from both parties in the form of Oracle Cloud Infrastructure Identity and Access Management policies that each party implements for their own VCN's compartment .

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

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

ピアリング
ピアリングは、2つのVCN間の単一のピアリング関係です。Example: If VCN-1 peers with two other VCNs, then two peerings exist.リモート・ピアリングリモートという部分は、VCNが異なるリージョンに存在することを示します。
VCN管理者
通常、VCNピアリングは、両方のVCN管理者が同意している場合にのみ実行できます。実際には、2人の管理者が次を行う必要があります:
  • 一定の基本情報を相互に共有します。
  • ピアリングを有効にするために必要なOracle Cloud Infrastructure Identity and Access Managementポリシーを設定するように調整します。
  • ピアリング用に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が必要です。前の例から続行する場合: 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内の宛先にルーティングされます。
この図は、一方のDRGから他方にルーティングされるトラフィックのルート表およびパスを示しています。
コールアウト3: サブネットAルート表
宛先CIDR ルート・ターゲット
0.0.0.0/0 インターネット・ゲートウェイ
192.168.0.0/16 DRG-1
コールアウト4: サブネットXルート表
宛先CIDR ルート・ターゲット
10.0.0.0/16 DRG-2
ノート

As mentioned earlier, a VCN can only use the connected RPCs to reach VNICs in the other VCN, and not destinations outside of the VCNs (such as the internet or an on-premises network).たとえば、前の図で、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 to allow the traffic.
ネットワーク・セキュリティ・グループ(NSG)を使用してセキュリティ・ルールを実装する場合、トラフィックのソースまたは宛先として別のNSGを指定するNSG用セキュリティ・ルールを記述するオプションがあることに注意してください。ただし、2つのNSGは同じVCNに属している必要があります

ピアリングの重要な意味

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

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

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

重要

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

  • このテナンシは、他方のVCNのリージョンにサブスクライブされています。されていない場合は、リージョンの管理を参照してください。
  • すでにDRGがVCNにアタッチされています。そうでない場合は、Dynamic Routing Gatewaysを参照してください。
  1. RPCの作成: 各VCN管理者は、自分のVCNのDRGにRPCを作成します。
  2. 情報の共有: 管理者は基本的な必須情報を共有します。
  3. 接続に必要なIAMポリシーの設定:管理者は、IAMポリシーを設定して、接続を確立できるようにします。
  4. 接続の確立: リクエスタが2つのRPCを接続します(リクエスタおよびアクセプタの定義については、リモート・ピアリングの重要な概念を参照)。
  5. Update route tables: Each administrator updates their VCN's route tables to enable traffic between the peered VCNs or subnets.
  6. Update security rules: Each administrator updates their VCN's security rules to enable traffic between the peered VCNs or subnets.

管理者は、接続を確立するに、タスク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

RPCの作成および操作の一般的な手順は、リモート・ピアリング接続の作成およびリモート・ピアリング管理を参照してください。アクセプタの場合は、RPCのリージョンおよびOCIDを記録し、その情報をリクエスタと共有します。2つのVCNsが異なるテナンシにある場合、各管理者はテナンシOCID (コンソールのページの下部にあります)を記録し、この情報を他の管理者に提供する必要があります。

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

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

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

両方のVCNsが同じテナンシ内にあり、リージョンが異なる場合は、レガシーDRGを使用したリモート・ピアリングで提供されているポリシーを使用します。

両方のVCNが異なるテナンシにあるが、同じリージョンにある場合は、「他のテナンシのVCNsへのアタッチ」で提供されるポリシーを使用します。

タスクD: 接続の確立

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

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

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

一般的な手順については、リモート・ピアリング接続の作成を参照し、アクセプタに提供される情報を使用します。RPCの操作の一般的な手順は、リモート・ピアリング管理を参照してください。

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

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

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

各VCNについて、VCN内のどのサブネットが他のVCNと通信する必要があるかを決定し、それらの各サブネットのルート表(VCNルート表のルールの更新を参照)を更新して、他のVCNを宛先とするトラフィックをDRGに送信する新しいルート・ルールを含めます:

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

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

ヒント

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

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

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

次のルールを追加します。

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

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

ローカルVCNの場合、VCN内のどのサブネットが他のVCNと通信する必要があるかを決定し、それらの各サブネットのセキュリティ・リストを更新して、他のVCNのCIDRブロックまたはサブネットとのエグレス・トラフィックまたはイングレス・トラフィックを許可するルールを含めます:

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

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

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