ローカル・ピアリング・ゲートウェイを使用したローカルVCNピアリング

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

ローカル・ピアリング・ゲートウェイは引き続きサポートされます。このシナリオは、レガシーDRGを使用していることを前提としています。現在、Oracleでは、DRGを介した同じリージョン内のVCNのピアリングで説明されているように、アップグレードされたDRGを介したVCN間のトラフィックのルーティングが推奨されています。

ローカルVCNピアリングの概要

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

詳細は、他のVCNへのアクセス: ピアリングを参照してください。

LPGを使用したピアリング用のネットワーキング・コンポーネントのサマリー

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

  • 重複しないCIDRを含む同じリージョン内の2つのVCN
  • ピアリング関係の各VCN上のローカル・ピアリング・ゲートウェイ(LPG)
  • 2つのLPG間の接続
  • 接続を介したトラフィックのフローを可能にするルート・ルールのサポート。各VCN内の選択サブネットに対してのみ有効にします(必要な場合)。
  • 他のVCNと通信する必要があるサブネット内のインスタンス間で許可されるトラフィックのタイプを制御するセキュリティ・ルールのサポート。

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

この図は、ローカル・ピアリングされた2つのVCNの基本的なレイアウトを示しています。各VCNはローカル・ピアリング・ゲートウェイを持っています。

ノート

特定のVCNでは、ピアリングされたLPGを使用して次のリソースに到達できます:

  • 他のVCN内のVNIC
  • 転送ルーティングと呼ばれる拡張ルーティング・シナリオがVCNに設定されている場合に、他のVCNにアタッチされているオンプレミス・ネットワーク

VCNは、ピアリングされたVCNを使用して、VCN外部の他の宛先(インターネットなど)に到達することはできません。たとえば、前の図のVCN-1にインターネット・ゲートウェイがあっても、VCN-2のインスタンスはそれを使用してインターネット上のエンドポイントにトラフィックを送信できません。ただし、VCN-2は、VCN-1を経由してインターネットからトラフィックを受信できます。詳細は、VCNピアリングの重要な意味を参照してください。

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

ピアリングには、同じ当事者または異なる2つの当事者が所有する2つのVCNが関係します。2つの当事者は、どちらも自分の会社に存在していても、異なる部門に属する場合があります。または、2つの当事者は、完全に異なる会社に属することもあります(サービス・プロバイダ・モデルなど)。

2つのVCN間のピアリングでは、各当事者が独自のVCNのコンパートメントまたはテナンシに対して実装するOracle Cloud Infrastructure Identity and Access Managementポリシーの形式で、両方の当事者からの明示的な合意が必要です。VCNが異なるテナンシにある場合、各管理者はテナンシOCIDを提供し、ピアリングを有効にする特別なポリシー・ステートメントを用意する必要があります。

拡張シナリオ: 転送ルーティング

単一のOracle Cloud Infrastructure FastConnectまたはサイト間VPNを介したオンプレミス・ネットワークと複数のVCN間の通信を可能にする転送ルーティングと呼ばれる拡張ルーティング・シナリオがあります。各VCNは、同じリージョンに存在し、ハブ・アンド・スポーク・レイアウトでローカル・ピアリングされる必要があります。シナリオの一部として、ハブとして機能しているVCNには、各LPGに関連付けられたルート表があります(通常、ルート表はVCNのサブネットに関連付けられます)。

LPGを作成するときに、オプションでルート表を関連付けることができます。または、ルート表のない既存のLPGがすでにある場合、ルート表をそれに関連付けることができます。ルート表はLPGのVCNに属している必要があります。LPGに関連付けられたルート表には、ターゲットとしてVCNにアタッチされたDRGを使用するルールのみを含めることができます。

LPGは、ルート表が関連付けられていない状態でも存在できます。ただし、ルート表をLPGに関連付けた後は、常にルート表が関連付けられている必要があります。ただし、異なるルート表を関連付けることもできます。表のルールの編集や、ルールの一部またはすべての削除も可能です。

ローカル・ピアリングの重要な概念

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

ピアリング
ピアリングは、2つのVCN間の単一のピアリング関係です。例: VCN-1が他の3つのVCNとピアリングしている場合、3つのピアリングがあります。ローカル・ピアリングローカルという部分は、VCNが同じリージョン内にあることを示します。1つのVCNで、同時に最大10のローカル・ピアリングを確立できます。
注意ピアリング関係内の2つ

のVCNは、重複するCIDRを持つことはできません。ただし、VCN-1が他の3つのVCNとピアリングされている場合、それらの3つのVCNは、相互に重複するCIDRを持つことができます。ターゲットのピアリングVCNにトラフィックを転送するルート・ルールを持つように、VCN-1のサブネットを設定します。
VCN管理者
通常、VCNピアリングは、両方のVCN管理者が同意している場合にのみ実行できます。実際には、2人の管理者が次を行う必要があります:
  • 一定の基本情報を相互に共有します。
  • ピアリングを有効にするために必要なOracle Cloud Infrastructure Identity and Access Managementポリシーを設定するように調整します。
  • ピアリング用にVCNを構成します。
状況によっては、一方の管理者が両方のVCNおよび関連ポリシーを担当します。
必要なポリシーおよびVCN構成の詳細は、ローカル・ピアリングの設定を参照してください。
アクセプタおよびリクエスタ
ピアリングに必要なIAMポリシーを実装するには、2人のVCN管理者が1人の管理者をリクエスタとして、もう1人をアクセプタとして指定する必要があります。リクエスタは、2つのLPGを接続するリクエストを開始する必要があります。一方、アクセプタは、アクセプタのコンパートメント内のLPGに接続するためのリクエスタ権限を付与する特定のIAMポリシーを作成する必要があります。このポリシーがないと、リクエスタの接続リクエストは失敗します。
ローカル・ピアリング・ゲートウェイ(LPG)
ローカル・ピアリング・ゲートウェイ(LPG)は、ローカル・ピアリングされたVCNにトラフィックをルーティングするためのVCN上のコンポーネントです。VCN構成の一環として、各管理者は、VCN用のLPGを作成する必要があります。指定したVCNでは、確立されるローカル・ピアリングごとに個別のLPG (VCNごとに最大10個のLPG)が必要です。前の例を続行する場合: VCN-1には、他の3つのVCNとピアリングするための3つのLPGがあります。APIでは、LocalPeeringGatewayはピアリングに関する情報を含むオブジェクトです。後で別のピアリングを確立するためにLPGを再利用することはできません。
ピアリング接続
リクエスタが(コンソールまたはAPIで)ピアへのリクエストを開始すると、2つのLPGを接続するように事実上求められます。リクエスタには、各LPGを識別する情報(LPGのコンパートメントと名前、またはLPGのOCIDなど)が必要です。各管理者は、コンパートメントまたはテナンシに必要なIAMポリシーを設定する必要があります。
どちらのVCN管理者も、LPGを削除することでピアリングを終了できます。この場合、他のLPGのステータスはREVOKEDに切り替わります。かわりに、管理者は、接続でのトラフィック・フローを可能にするルート・ルールまたはセキュリティ・ルールを削除することで、接続を無効化できます(次の各項を参照)。
LPGへのルーティング
VCN構成の一環として、各管理者は、VCN間のトラフィック・フローを可能にするようにVCNのルーティングを更新する必要があります。実際には、これはゲートウェイ(インターネット・ゲートウェイ動的ルーティング・ゲートウェイなど)に設定したルーティングと同様です。他のVCNと通信する必要があるサブネットごとに、サブネットのルート表を更新します。ルート・ルールでは、宛先トラフィックのCIDRとLPGをターゲットとして指定します。LPGは、そのルールに一致するトラフィックを他のLPGにルーティングし、さらにそこから他のVCN内のネクスト・ホップにトラフィックをルーティングします。
次の図で、VCN-1とVCN-2はピアリングされています。サブネットA (10.0.0.15)のインスタンスからのトラフィックのうち、VCN-2 (192.168.0.15)のインスタンスに対して送信されるものは、サブネットAのルート表にあるルールに基づいてLPG-1にルーティングされます。トラフィックは、そこからLPG-2にルーティングされ、さらにサブネットXの宛先にルーティングされます。
この図は、一方のローカル・ピアリング・ゲートウェイから他方にルーティングされるトラフィックのルート表およびパスを示しています。
ノート

前述のように、特定のVCNは、他のVCN内のVNICに到達するためにピアリングされたLPGを使用するか、VCNに対して転送ルーティングが設定されている場合はオンプレミス・ネットワークを使用できます。ただし、VCNは、ピアリングされたVCNを使用して、VCN外部の他の宛先(インターネットなど)に到達することはできません。たとえば、前の図で、VCN-2はVCN-1にアタッチされたインターネット・ゲートウェイを使用できません。

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

VCNピアリングの重要な意味

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

ローカル・ピアリングの設定

同じリージョン内の2つのVCN間にピアリングを設定するための一般的なプロセスを次に示します:

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

必要に応じて、管理者は接続を確立する前にタスクEおよびFを実行できます。その場合、各管理者は、他のVCNのCIDRブロックまたは特定のサブネットを把握して、タスクBでそれを共有する必要があります。接続の確立後、独自のLPGの詳細をコンソールで確認することにより、他のVCNのCIDRブロックを取得することもできます。「ピア通知CIDR」を確認してください。または、APIを使用している場合は、peerAdvertisedCidrパラメータを参照してください。

タスクA: LPGの作成

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

ノート

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

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

Allow group LPGAdmins to manage local-peering-gateways in tenancy
Allow group LPGAdmins to manage vcns in tenancy
  1. コンソールで、LPGを追加するVCNを含むコンパートメントを表示していることを確認します。コンパートメントとアクセス制御の詳細は、アクセス制御を参照してください。
  2. ナビゲーション・メニューを開き、「ネットワーキング」「仮想クラウド・ネットワーク」の順にクリックします。
  3. 関心のあるVCNをクリックします。
  4. 「リソース」で、「ローカル・ピアリング・ゲートウェイ」をクリックします。
  5. 「ローカル・ピアリング・ゲートウェイの作成」をクリックします。
  6. 次を入力します:

    • 名前: LPGのわかりやすい名前。必ずしも一意である必要はありませんが、後でコンソールで変更することはできません(ただし、APIで変更できます)。機密情報の入力は避けてください。
    • コンパートメントで作成: LPGを作成するコンパートメント(現在作業しているコンパートメントと異なる場合)。
    • ルート表との関連付け(オプション): 転送ルーティングと呼ばれる拡張ルーティング・シナリオを設定する場合のみ。LPGと関連付けるルート表を含むコンパートメントと、ルート表自体を選択します。この部分をスキップして、後で必要に応じてLPGをルート表に関連付けることもできます。
    • タグ: リソースの作成権限がある場合は、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかわからない場合は、このオプションをスキップするか(後からでもタグを適用できます)、管理者に問い合せてください。
  7. 「ローカル・ピアリング・ゲートウェイの作成」をクリックします。

    これにより、LPGが作成され、選択したコンパートメントの「ローカル・ピアリング・ゲートウェイ」ページに表示されます。

タスクB: 情報の共有

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

  • VCNが同じテナンシ内にある場合: アクセプタのコンパートメントに接続を作成する権限を付与する必要があるIAMグループの名前。次のタスクの例では、このグループはRequestorGrpです。
  • VCNが異なるテナンシ内にある場合: 自分のテナンシのOCIDと、アクセプタのコンパートメントに接続を作成する権限を付与する必要があるIAMグループのOCID。次のタスクの例では、これはRequestorGrpのOCIDです。
  • オプション: VCNのCIDR、または他のVCNとピアリングするための特定のサブネット。

自分がアクセプタである場合は、次の情報をリクエスタに提供します:

  • VCNが同じテナンシ内にある場合: LPGのOCID。オプションとして、VCN、LPGおよびそれぞれが属するコンパートメントの名前があります。
  • VCNが異なるテナンシ内にある場合: LPGのOCID、およびテナンシのOCID。
  • オプション: VCNのCIDR、または他のVCNとピアリングするための特定のサブネット。
タスクC: IAMポリシーの設定(同じテナンシ内のVCN)

タスクCのこのバージョンでは、両方のVCNが同じテナンシ内にあります。これらが異なるテナンシ内にある場合は、かわりにタスクC: IAMポリシーの設定(異なるテナンシ内のVCN)を参照してください。

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

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

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

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

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

    Allow group RequestorGrp to manage local-peering-to in compartment AcceptorComp
    
    Allow group RequestorGrp to inspect vcns in compartment AcceptorComp
    
    Allow group RequestorGrp to inspect local-peering-gateways in compartment AcceptorComp
    

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

    ヒント

    ポリシーAの2番目と3番目のステートメントにより、リクエスタはAcceptorCompのVCNとLPGをリストできます。これらのステートメントは、リクエスタがコンソールUIを使用してAcceptorComp内のVCNとLPGのリストから選択し、接続を確立するために必要です。次の図では、最初のステートメント(接続を許可する重要なもの)のみを中心に説明しています。

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

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

ヒント

別のポリシーでRequesterCompのすべてのネットワーキング・コンポーネントを管理する権限をリクエスタが持っている場合は、ポリシーRによって付与される権限がすでに有効である可能性があります。たとえば、次のような一般的なネットワーク管理ポリシーが存在する可能性があります:

 Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorComp

リクエスタがNetworkAdminグループに属している場合、ポリシーRでカバーされる必要な権限をすでに持っています(virtual-network-familyにLPGが含まれます)。さらに、RequestorCompコンパートメントのみではなく、テナンシ全体をカバーするようにポリシーが記述されている場合、リクエスタは、接続を確立するために必要なすべての権限を両方のコンパートメントですでに持っています。その場合、ポリシーAは必要ありません。

タスクC: IAMポリシーの設定(異なるテナンシ内のVCN)

タスクCのこのバージョンでは、VCNが異なるテナンシ内にあります(つまり、クロステナンシ・ピアリングです)。VCNが同じテナンシ内にある場合は、かわりにタスクC: IAMポリシーの設定(同じテナンシ内のVCN)を参照してください。

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

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

    Define tenancy Acceptor as <acceptor_tenancy_OCID>
    
    Allow group RequestorGrp to manage local-peering-from in compartment RequestorComp
    
    Endorse group RequestorGrp to manage local-peering-to in tenancy Acceptor
    
    Endorse group RequestorGrp to associate local-peering-gateways in compartment RequestorComp
       with local-peering-gateways in tenancy Acceptor

    リクエスタは、RequestorGrpというIAMグループに属しています。このポリシーによって、グループ内のすべてのユーザーが、リクエスタのコンパートメント(RequestorComp)の任意のLPGから接続を開始できます。

    最初のステートメントは、アクセプタのテナンシOCIDにわかりやすいラベルを割り当てる"define"ステートメントです。ここでのステートメントはラベルとして"Acceptor"を使用していますが、リクエスタが選択した値にすることができます。ポリシー内のすべての"define"ステートメントは、一番上にある最初のステートメントである必要があります。

    2番目のステートメントにより、RequestorGrpはリクエスタのコンパートメントにあるLPGからの接続を確立できます。

    3番目と4番目のステートメントは、LPGが異なるテナンシにあるために必要となる特別なものです。これらによって、RequestorGrpは、リクエスタのテナンシ内のLPGをアクセプタのテナンシ内のLPGに接続できます。

    任意のテナンシ内のLPGに接続する権限をRequestorGrpに付与する場合、かわりにポリシーは次のようになります:

    
    Allow group RequestorGrp to manage local-peering-from in compartment RequestorComp
    
    Endorse group RequestorGrp to manage local-peering-to in 
    
    any-tenancy
    
    
    
    Endorse group RequestorGrp to associate local-peering-gateways in compartment RequestorComp
        with local-peering-gateways in 
    
    any-tenancy
    
    

    これとは関係なく、ポリシーRはリクエスタのテナンシ(ルート・コンパートメント)にアタッチする必要があり、リクエスタのコンパートメントにはアタッチしません。クロステナンシ・アクセスを有効にするポリシーは、テナンシにアタッチする必要があります。ポリシーのアタッチメントの詳細は、ポリシーの基本を参照してください。

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

    Define tenancy Requestor as <requestor_tenancy_OCID>
    
    Define group RequestorGrp as <RequestorGrp_OCID>
    
    Admit group RequestorGrp of tenancy Requestor to manage local-peering-to in compartment AcceptorComp
    
    Admit group RequestorGrp of tenancy Requestor to associate local-peering-gateways in tenancy Requestor
        with local-peering-gateways in compartment AcceptorComp

    リクエスタのポリシーと同様に、このポリシーでは、最初に"define"ステートメントを使用して、リクエスタのテナンシOCIDおよびRequestorGrp OCIDにわかりやすいラベルを割り当てます。前述のように、アクセプタは必要に応じてそれらのラベルに他の値を使用できます。

    3番目と4番目のステートメントにより、RequestorGrpがアクセプタのコンパートメント(AcceptorComp)のLPGに接続できます。これらのステートメントは、ピアリングを確立するために必要となる重要な合意を反映します。Admitという語は、ポリシーが存在するテナンシの外部のグループにアクセス権が適用されることを示します。

    ポリシーAはアクセプタのテナンシ(ルート・コンパートメント)にアタッチする必要があり、アクセプタのコンパートメントにはアタッチしません。

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

タスクD: 接続の確立

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

前提条件: リクエスタには、アクセプタのLPGのOCIDが必要です。

ヒント

コンソールを使用していて、ピアリングが同じテナンシ内の2つのVCN間にある場合: アクセプタのLPG OCIDを指定するかわりに、テナンシ内のリソースのリストからアクセプタのVCNおよびLPGを選択できます。ただし、LPGのOCIDではなく、アクセプタのVCNおよびLPGの名前とコンパートメントの両方を把握している必要があります。詳細は、タスクB: 情報の共有を参照してください。
  1. コンソールで、アクセプタLPGに接続するリクエスタLPGの詳細を表示します。
  2. リクエスタLPGについて、「アクション」アイコン(3つのドット)をクリックして、「ピアリング接続の確立」をクリックします。
  3. ピアリングするLPGを指定します:

    • VCNが異なるテナンシにある場合: 「ローカル・ピアリング・ゲートウェイOCIDの入力」を選択して、アクセプタLPGのOCIDを入力します。
    • VCNが同じテナンシにある場合: 次のいずれかを実行します:

      • 「ローカル・ピアリング・ゲートウェイOCIDの入力」を選択して、アクセプタLPGのOCIDを入力します。
      • 「下を参照」を選択して、表示されるリストからアクセプタのVCNおよびLPGを選択します。VCNとLPGは、それぞれ現在作業しているコンパートメントとは異なるコンパートメントに存在する可能性があることに注意してください。
  4. 「ピアリング接続の確立」をクリックします。

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

この時点で、他方のVCNの「ピアVCN CIDRブロック」を表示するように各LPGの詳細が更新されます。これは、LPGからのピアリングにおける他方のVCNのCIDRです。各管理者は、この情報を使用して、独自のVCNのルート表およびセキュリティ・ルールを更新できます。

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

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

前提条件: 各管理者には、他のVCNのCIDRブロックまたは特定のサブネットが必要です。接続がすでに確立されている場合は、コンソールでLPGの「ピアVCN CIDRブロック」を参照してください。それ以外の場合、電子メールまたは他の方法で他方の管理者から情報を取得します。

自分のVCNについて:

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

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

      • ターゲット・タイプ: ローカル・ピアリング・ゲートウェイ。
      • 宛先CIDRブロック: 他方のVCN CIDRブロック。必要に応じて、ピアリングされたVCN CIDRの任意のサブネットまたは特定のサブセットを指定できます。
      • ターゲット・コンパートメント: LPGが配置されているコンパートメント(現在のコンパートメントではない場合)。
      • ターゲット: LPG。
      • 説明: ルールのオプションの説明。
    6. 「ルート・ルールの追加」をクリックします。

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

その後、ピアリングが不要になってLPGを削除する場合は、LPGをターゲットとして指定しているVCN内のすべてのルート・ルールを最初に削除する必要があります。

ヒント

必要なルーティングがない場合、トラフィックはピアリングされたLPG間を流れません。ピアリングを一時的に停止する必要がある状況が発生した場合は、トラフィックを有効にするルート・ルールのみを削除できます。LPGを削除する必要はありません。
タスク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. ルールを追加する場合は、「イングレス・ルールの追加」(または「エグレス・ルールの追加」)をクリックします。

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

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

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

コンソールの使用

ルート表を既存のローカル・ピアリング・ゲートウェイに関連付けるには

このタスクは、転送ルーティングと呼ばれる拡張ルーティング・シナリオに関連しています。

LPGは、ルート表が関連付けられていない状態でも存在できます。ただし、ルート表をLPGに関連付けた後は、常にルート表が関連付けられている必要があります。ただし、異なるルート表を関連付けることもできます。表のルールの編集や、ルールの一部またはすべての削除も可能です。

前提条件: ルート表が存在し、LPGが属するVCNに属している必要があります。

  1. ナビゲーション・メニューを開き、「ネットワーキング」「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「リソース」で、「ローカル・ピアリング・ゲートウェイ」をクリックします。
  4. 目的のLPGについて、「アクション」アイコン()をクリックし、次のいずれかをクリックします:

    • ルート表との関連付け: LPGにルート表がまだ関連付けられていない場合。
    • ルート表関連の置換: LPGに関連付けられているルート表を変更する場合。
  5. ルート表が存在するコンパートメントを選択し、ルート表自体を選択します。
  6. 「関連付け」をクリックします。
ローカル・ピアリング・ゲートウェイを削除するには

前提条件: 最初に、LPGをターゲットとして指定しているVCN内のすべてのルート・ルールを削除します。それらのルールを削除すると、VCNでLPGへのルーティングが停止します。ただし、他方のLPGがまだ存在する場合、LPGの状態はPEEREDのままになることがあります。LPGが削除されるたびに、ピアリングの他方の側にあるLPGはREVOKED状態に変更されます。

  1. ナビゲーション・メニューを開き、「ネットワーキング」「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「ローカル・ピアリング・ゲートウェイ」をクリックします。
  4. 削除するLPGについて、「アクション」アイコン(3つのドット)をクリックし、「終了」をクリックします。
  5. プロンプトが表示されたら確認します。
ノート

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

ローカル・ピアリング・ゲートウェイのタグを管理するには
  1. ナビゲーション・メニューを開き、「ネットワーキング」「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「リソース」で、「ローカル・ピアリング・ゲートウェイ」をクリックします。
  4. ローカル・ピアリング・ゲートウェイの「アクション」アイコン(3つのドット)をクリックし、「タグの表示」をクリックします。その場所で、既存のタグの表示、それらの編集、および新しいタグの適用を行うことができます。

詳細は、リソース・タグを参照してください。

ローカル・ピアリング・ゲートウェイを別のコンパートメントに移動するには

ローカル・ピアリング・ゲートウェイは、コンパートメント間で移動できます。ローカル・ピアリング・ゲートウェイを新しいコンパートメントに移動すると、固有のポリシーがただちに適用されます。

  1. ナビゲーション・メニューを開き、「ネットワーキング」「仮想クラウド・ネットワーク」の順にクリックします。
  2. 関心のあるVCNをクリックします。
  3. 「リソース」で、「ローカル・ピアリング・ゲートウェイ」をクリックします。
  4. ローカル・ピアリング・ゲートウェイの「アクション」アイコン(3つのドット)をクリックし、「リソースの移動」をクリックします。
  5. リストから宛先コンパートメントを選択します。
  6. 「リソースの移動」をクリックします。

コンパートメントとポリシーを使用したクラウド・ネットワークへのアクセスの制御の詳細は、アクセス制御を参照してください。コンパートメントに関する一般情報は、コンパートメントの管理を参照してください。

APIの使用

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

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