レガシー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がないことが必要です。また、特定のVCNに複数のピアリング関係がある場合、それらの他のVCNは、相互に重複するCIDRを持つことはできません。たとえば、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と通信する必要があるサブネット内のインスタンス間で許可されるトラフィックのタイプを制御する、サポート・セキュリティ・ルール。
次の図は、これらのコンポーネントを示しています。
VCNは、接続されたRPCを使用して、他のVCNまたはオンプレミス・ネットワークのVNICに到達することのみでき、インターネットなどのVCNsの外部の宛先には到達できません。たとえば、前の図でVCN-1にインターネット・ゲートウェイがある場合、VCN-2のインスタンスはそれを使用してインターネット上のエンドポイントにトラフィックを送信できませんでした。詳細は、ピアリングの重要な意味を参照してください。
スポークツースポーク: 転送ルーティングを使用するリモート・ピアリング
この項で説明するシナリオはまだサポートされていますが、非推奨です。「中央ネットワーク仮想アプライアンスを介したトラフィックのルーティング」で説明されているDRG転送ルーティング方法を使用することをお薦めします。
次の図に示すように、各リージョンで複数のVCNsがハブアンドスポーク・レイアウトにあるとします。リージョン内のこのタイプのレイアウトについては、ハブVCN内の転送ルーティングで詳しく説明しています。特定のリージョン内のスポークVCNは、ローカル・ピアリング・ゲートウェイを使用して、同じリージョン内のハブ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と通信できるようにルーティングを設定することもできます。
両方の側から必要な明示的合意
2つのVCN間のピアリングでは、各当事者が独自のVCNのコンパートメントに対して実装するOracle Cloud Infrastructure Identity and Access Managementポリシーの形式で、両当事者からの明示的な承諾が必要です。
リモート・ピアリングの重要な概念
次の概念は、ピアリングの基本およびリモート・ピアリングの確立方法を理解するのに役立ちます。
- ピアリング
- ピアリングは、2つのVCN間の単一のピアリング関係です。例: VCN-1が他の2つのVCNとピアリングする場合、2つのピアリングが存在します。リモート・ピアリングのリモートという部分は、VCNが異なるリージョンに存在することを示します。
- VCN管理者
- 通常、VCNピアリングは、両方のVCN管理者が同意している場合にのみ実行できます。実際には、2人の管理者が次を行う必要があります:
- アクセプタおよびリクエスタ
- ピアリングに必要な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など)を持っている必要があります。
- DRGへのルーティング
- VCN構成の一環として、各管理者は、VCN間のトラフィック・フローを可能にするようにVCNのルーティングを更新する必要があります。他のVCNと通信する必要があるサブネットごとに、サブネットのルート表を更新します。ルート・ルールでは、宛先トラフィックのCIDRとDRGをターゲットとして指定します。DRGは、このルールに一致するトラフィックを他のDRGにルーティングします。これにより、さらにそこから他のVCNのネクストロップにトラフィックがルーティングされます。
- セキュリティ・ルール
- VCNの各サブネットには、パケット・レベルでサブネットのVNIC内外のトラフィックを制御する1つ以上のセキュリティ・リストがあります。セキュリティ・リストを使用して、他のVCNで許可されるトラフィックのタイプを制御できます。VCNsの構成の一環として、各管理者は、他のVCN内のVNICと通信するために必要な独自のVCN内のサブネットを決定し、トラフィックを許可するようにサブネットのセキュリティ・リストを更新する必要があります。
ピアリングの重要な意味
まだ参照していない場合は、ピアリングの重要な意味を読んで、ピアリングされたVCNのアクセス制御、セキュリティおよびパフォーマンスに対する重要な影響を理解してください。
リモート・ピアリングの設定
この項では、異なるリージョンにある2つのVCN間にピアリングを設定するための一般的なプロセスについて説明します。
以降の手順では次のことを前提としています:
- このテナンシは、他方のVCNのリージョンにサブスクライブされています。されていない場合は、リージョンの管理を参照してください。
- すでにDRGがVCNにアタッチされています。そうでない場合は、Dynamic Routing Gatewaysを参照してください。
- RPCの作成: 各VCN管理者は、自分のVCNのDRGにRPCを作成します。
- 情報の共有: 管理者は基本的な必須情報を共有します。
- 接続に必要なIAMポリシーの設定:管理者は、IAMポリシーを設定して、接続を確立できるようにします。
- 接続の確立: リクエスタが2つのRPCを接続します(リクエスタおよびアクセプタの定義については、リモート・ピアリングの重要な概念を参照)。
- ルート表の更新:各管理者はVCNのルート表を更新して、ピアリングされたVCNまたはサブネット間のトラフィックを有効にします。
- セキュリティ・ルールの更新:各管理者がVCNのセキュリティ・ルールを更新して、ピアリングされたVCNまたはサブネット間のトラフィックを有効にします。
管理者は、接続を確立する前に、タスクEおよびFを実行できます。各管理者は、他のVCNのCIDRブロックまたは特定のサブネットを把握して、タスクBでそれを共有する必要があります。
各アクセプタまたはリクエスタ管理者は、自分の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 (コンソールのページの下部にあります)を記録し、この情報を他の管理者に提供する必要があります。
両方のVCNsが同じテナンシ内にあり、リージョンが異なる場合は、(同じテナンシ内の)DRGを使用したリモート・ピアリングで提供されるポリシーを使用します。
両方のVCNが異なるテナンシにあるが、同じリージョンにある場合は、「他のテナンシのVCNsへのアタッチ」で提供されるポリシーを使用します。
リクエスタがこのタスクを実行する必要があります。
前提条件: リクエスタが次のものを持っている必要があります:
- アクセプタのVCNが含まれるリージョン(リクエスタのテナンシはこのリージョンにサブスクライブされている必要があります)。
- アクセプタのRPCのOCID。
一般的な手順については、リモート・ピアリング接続の作成を参照し、アクセプタに提供される情報を使用します。RPCの操作の一般的な手順は、リモート・ピアリング管理を参照してください。
前述のように、各管理者は接続の確立前後にこのタスクを実行できます。
前提条件: 各管理者には、他のVCN内の特定のサブネットのVCN CIDRブロックまたはCIDRブロックが必要です。
各VCNについて、VCN内のどのサブネットが他のVCNと通信する必要があるかを決定し、それらの各サブネットのルート表(VCNルート表のルールの更新を参照)を更新して、他のVCNを宛先とするトラフィックをDRGに送信する新しいルート・ルールを含めます:
- ターゲット・タイプ: 動的ルーティング・ゲートウェイ。VCNのアタッチされているDRGがターゲットとして自動的に選択されるため、ターゲットを自分で指定する必要はありません。
- 宛先CIDRブロック: 他方のVCN CIDRブロック。必要に応じて、ピアリングされたVCN CIDRの任意のサブネットまたは特定のサブセットを指定できます。
- 説明: ルールのオプションの説明。
ルールに一致する宛先のサブネット・トラフィックが、DRGにルーティングされます。VCNルート表およびルールの詳細は、VCNルート表に関する項を参照してください。
必要なルーティングがない場合、トラフィックはピアリングされたDRG間を流れません。ピアリングを一時的に停止する必要がある状況が発生した場合は、トラフィックを有効にするルート・ルールを一時的に削除します。RPCを削除する必要はありません。
前述のように、各管理者は接続の確立前後にこのタスクを実行できます。
前提条件: 各管理者は、他のVCNと共有するCIDRブロックまたは特定のサブネットを認識している必要があります。通常は、タスクE: ルート表の構成にあるルート表のルールで使用したものと同じCIDRブロックを使用します。
次のルールを追加します。
- 他のVCN (特にVCNのCIDRや特定のサブネット)から許可するトラフィックのタイプに対するイングレス・ルール。
- ローカルVCNから他のVCNへの送信トラフィックを許可するためのエグレス・ルール。サブネットに、全ての宛先(0.0.0.0/0)へのすべてのタイプのプロトコルに対応する広範囲なエグレス・ルールがすでにある場合は、他方のVCN用に特別なルールの1つを追加する必要はありません。
ローカルVCNの場合、VCN内のどのサブネットが他のVCNと通信する必要があるかを決定し、それらの各サブネットのセキュリティ・リストを更新して、他のVCNのCIDRブロックまたはサブネットとのエグレス・トラフィックまたはイングレス・トラフィックを許可するルールを含めます:
セキュリティ・ルールの詳細は、セキュリティ・ルールを参照してください。
他方のVCNのCIDRからのイングレスHTTPS (ポート443)トラフィックを許可するステートフル・ルールを追加するとします。ルールを追加する際の基本的なステップは次のとおりです:
- 「イングレスのルール許可」セクションで、「+Addルール」を選択します。
- 「ステートレス」チェック・ボックスは選択を解除したままにします。
- ソース・タイプ: 「CIDR」のままにします。
- ソースCIDR: ルート・ルールで使用するのと同じCIDRブロックを入力します(タスクE: ルート表の構成を参照)。
- IPプロトコル: TCPのままにします。
- ソース・ポート範囲: 「すべて」のままにします。
- 宛先ポート範囲: 443と入力します。
- 説明: ルールのオプションの説明。