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

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

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が作成され、選択したコンパートメントの「ローカル・ピアリング・ゲートウェイ」ページに表示されます。

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

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

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

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

  Allow group <requestor-group-name> to manage local-peering-from in compartment RequestorComp

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

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

  Allow group <requestor-group-name> to manage local-peering-to in compartment <acceptor-compartment>
  
  Allow group <requestor-group-name> to inspect vcns in compartment <acceptor-compartment>
  
  Allow group <requestor-group-name> to inspect local-peering-gateways in compartment <acceptor-compartment>
  

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

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

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

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

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

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

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

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

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

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

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

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

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

  
  Allow group <requestor-group-name> to manage local-peering-from in compartment <requestor-compartment>
  
  Endorse group <requestor-group-name> to manage local-peering-to in 
  
  any-tenancy
  
  
  
  Endorse group <requestor-group-name> to associate local-peering-gateways in compartment <requestor-compartment> 
  with local-peering-gateways in 
  any-tenancy
  
  

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

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

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

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

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

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

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

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

1. コンソールで、アクセプタLPGに接続するリクエスタLPGの詳細を表示します。
2. リクエスタLPGについて、「アクション」メニューをクリックして、「ピアリング接続の確立」をクリックします。

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のルート表およびセキュリティ・ルールを更新できます。

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

前提条件: 各管理者には、他の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内のすべてのルート・ルールを最初に削除する必要があります。

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

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

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

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

自分の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. 既存のルールを削除する場合は、「アクション」メニューをクリックして、「削除」をクリックします。
   6. 既存のルールを編集する場合は、「アクション」メニューをクリックして、「編集」をクリックします。

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

タスクA: LPGの作成の手順を参照してください。

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

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について、「アクション」メニューをクリックし、「終了」をクリックします。
5. プロンプトが表示されたら確認します。

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

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

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

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

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