初めに
ISV様 (Independent Software Vendorの略称、SaaS提供者)が、オラクル・クラウドを使用する時、シングル・テナンシで複数エンドユーザーの共同利用は、一般的なビジネス・モデルです。本シリーズ記事は、このような共同利用型のISV/SaaS事業者さまに向いています。
初回目として、OCIでネットワーク構成を設計する時、ISV様の共通課題と解決方法を紹介したいと思います。少しでもお役に立てれば幸いです。
索引
ISVモデルのネットワーク設計の課題と解決方法
ネットワーク設計の課題
課題-1 (LPG数の制限)
VCNで各エンドユーザー様を分けて、それぞれ管理用VCNと接続するのは、ISV様にとって一般的な構成方法です。ただ、1個の管理用VCNに対し、10個のLPG(Local Peering Gateway)まで作成できるというサービス制限があります。SR(サービス・リクエスト)で引き上げるのは可能ですが、やはり限界（20個ぐらい）があります。
ビジネスの規模拡張と伴い、エンドユーザーの数が増えてくると、LPG数の制限がボルトネックになります。
課題-2 (エンドユーザー間のCIDRブロックの独立性)
On-PとOCIの間、IPSec VPN/Fastconnectで接続する場合、各ユーザーのCIDRブロックは重複できないという制限があります。
利用者は、他社のCIDRを意識しなくてもよいのは当然であり。CIDR重複の制限は、ISV様にもエンドユーザーにも不便です。
解決方法
課題解決-1 (LPG→DRGv2)
LPG接続ではなく、DRGv2でVCN間の接続を集約します。従来のDRGとVCNの対応関係は、1:1でしたが、1:Nになりました。１つDRGに対し、最大300個のVCNをアタッチするのは可能であり、LPGの制限を乗り越えます。
課題解決-2 (DRGv2のルーティング機能)
DRGv2のルーティング機能を利用すれば、IPSec VPN/FastConnect接続の時、エンドユーザーごと、それぞれのルートを分けることは可能です。なお、管理用VCNから、各エンドユーザー用VCNへの経路を振り分けることができます。
OnP側、各エンドユーザーとISVは、他社のCIDRを意識しなくてもよいです。クラウド側、各エンドユーザのCIDDRは重複してもよいが、管理と運用の利便性の考慮で、重複しないように設計するのを推奨します。
これから、検証方法と結果を紹介します。
検証環境の構成
Libreswanを利用し、On-PとOCIの間、IPSec VPNの複数接続をシミュレーションします。
On-P: 大阪リージョン (LibreswanをVMにインストール)
OCI: 東京リージョン
ISV様とエンドユーザーのA社、C社 (On-PとOCI両側、CIDRの重複があります。)
検証作業の流れ
STEP1-事前準備 (On-P/OCI両側)
1. 関連リソースの作成
関連リソースをOn-P/OCI両側で作成しておきます。必要なリソース数は、以下となります。
- VCN: 6個 (On-PとOCI側は、３個ずつ)
- サブネット: 6 個 (On-PとOCI側は、３個ずつ。この例は、全部パブリック・サブネットを使用）)
On-P側：各サブネットのCIDR(192.168.0.0/24)は、全部重複している。
OCI側：A社のC社のCIDR(10.0.0.0/24)は、重複しているが、ISVの保守環境のCIDRは、各エンドユーザと重複しない。 - Compute インスタンス (Linux): 9 個 = (OnP側の端末 + CPE + OCI側の端末) * 3
- DRG: 1個
- CPE: 3個
- IPSec接続: 3個
両側にセキュリティ・リストとルート・テーブルの設定も必要です。設定内容の詳細は、以下の記事のSTEP-1をご参照ください。
On-PとOCI間のIPSec VPN接続のシミュレーション (Libreswanを利用)
2. ISV様の管理環境向けの追加設定
上記のシミュレーションの構成例に、ISV様の管理用VCNを含めていません。管理VCNからエンドユーザー用VCNに接続するため、以下の追加設定は必要です。
2-1. ルート・テーブル
ISV様用サブネットのルート・テーブル：
エンドユーザーのCIDR (192.168.0.0/24) を追加します。
エンドユーザー用サブネットのルート・テーブル：
ISV様のCIDR (172.16.0.0/24) を追加します。
2-2. セキュリティ・リスト (SL)
エンドユーザー用サブネットのSLに、ISV様から (172.16.0.0/24) の入力ルールを許可します。
エンドユーザーからISV様の環境にアクセスしないので（片道通行）、ISV様の SL の入力ルールにエンドユーザーのCIDR追加する必要がありません。
STEP2-サイト間VPNの作成 (OCI)
1. 顧客構内機器(CPE)の作成
ネットワーキング -> 顧客接続性 -> 顧客構内機器 -> 「顧客構内機器の作成」ボタンを押す
名前: CPE名を入力
Public IP アドレス: LibreswanインスタンスのパブリックIPを入力
ベンダー: Libreswanを選択
Platform Version: リストから選択
作成後：
2. IPSec接続の作成
ネットワーキング -> 顧客接続性 -> サイト間VPN ->「IPSec接続の作成」ボタンを押す
以下のように必要な情報を入力し、「IPSec接続の作成」ボタンを押します。
名前: IPSec接続名を入力
CPE: リストから作成したCPEを選択
DRG: リストから既存のDRGを選択。
オンプレミス・ネットワークへのルート: On-P側のサブネットの CIDR ブロックを入力
トンネル１と２のルーティング・タイプ: 静的ルーティングを指定
作成後：
STEP3-VCNアタッチメントの作成 (OCI)
ネットワーキング → 顧客接続性 → 動的ルーティング・ゲートウェイ → DRG → 仮想クラウド・ネットワーク・アタッチメント → 「仮想クラウド・ネットワーク・アタッチメントの作成」を押す
DRGルート表：デフォルトのままでよい
作成後：
STEP4-ルート・ディストリビューションのインポートの作成 (OCI)
ネットワーキング → 顧客接続性 → 動的ルーティング・ゲートウェイ → DRG → ルート・ディストリビューションのインポート → 「ルート・ディストリビューションのインポートの作成」を押す
入力情報 (各エンドユーザー用)
- 優先度：1~3を入力 (３行)
- 一致タイプ："Attachment"を選択
- アタッチメント・タイプ・フィルタ
1～2行目："IPSec Tunnel"を選択。
3行目："Virtual Cloud Network"を選択 - DRGアタッチメント
1～2行目：IPSec接続が作成された時、２個のDRGアタッチメントが自動に作成されたので、それらを選択。
3行目：STEP3で作成したISV用のアタッチメントを選択 (ISV様からのアクセス)。
入力情報 (ISV様用)
ISV様用の場合、"IPSec Tunnel"の2行だけでOKです。
作成後：
STEP5-DRGルート表の作成 (OCI)
ネットワーキング → 顧客接続性 → 動的ルーティング・ゲートウェイ → DRG → DRGルート表 → 「DRGルート表の作成」を押す
入力情報 (各エンドユーザー用)
- 宛先CDIR：各エンドユーザーのサブネットのCIDR
- アタッチメント："Virtual Cloud Network"を選択 (同一リージョンの場合)
- 次のホップ・アタッチメント：STEP3で作成したアタッチメントを選択
- ルート・ディストリビューションのインポートの有効化：チェックする
- ルート・ディストリビューションのインポート：STEP4で作成したものを選択
入力情報 (ISV様用)
- 宛先CDIR：
1行目：ISV用サブネットのCIDR
2行目以降：接続先(VM)のプライベートIP - アタッチメント："Virtual Cloud Network"を選択
- 次のホップ・アタッチメント：
1行目：ISV用アタッチメント
2行目以降：各エンドユーザー用アタッチメント - ルート・ディストリビューションのインポートの有効化：チェックする
- ルート・ディストリビューションのインポート：STEP4で作成したものを選択
上記の"10.0.0.23"は、A社のVM（Client A2）のIPアドレスで、"10.0.0.58"は、C社のVM（Client C2）のIPアドレスです。
作成後：
STEP6-VCNアタッチメントの編集 (OCI)
VCNアタッチメントを編集し、STEP5で作成したDRGルート表を選択します。
編集後：
STEP7-IPSecトンネル・アタッチメントの編集 (OCI)
IPSecトンネル・アタッチメントを編集し、STEP5で作成したDRGルート表を選択します。
編集後：
STEP8-Libreswanの構成 (On-P)
On-P(大阪リージョン)側のVMで、Libreswanのインストールと構成を実施してから、サービスを起動します。実施方法の詳細は、以下の記事のSTEP-3とSTEP-4をご参照ください。
On-PとOCI間のIPSec VPN接続のシミュレーション (Libreswanを利用)
STEP9-接続テスト (On-P/OCI両側)
接続タイプ：SSH接続 (左右双方向)
前提条件：TCP(22ポート)を両側のセキュリティ・リスト（或いはNSG）に許可しておきます。
結果は予定通り、各エンドユーザーは自分のネットワーク内のVMしか接続できないで、エンドユーザー間のネットワーク隔離性を確保できます。
ISV様は、OnPとOCIの間、双方通信できます。なお、クラウド保守環境 (Client ISV2)から、エンドユーザーのOCI上のVMにアクセスできます（片道のみ）。
DRGルート表のサービス制限を超えた時
一つのDRGに対し、最大100個のルート表を作成できす。この制限はハードリミットで、増やすことができません。各エンドユーザーが、IPSec VPNでOCIに接続する時、ユーザーごと、DRGルート表を作成しますので、100社の場合、1個のDRGに100個のルート表は必要です。もし100社を超えたら、どう対応するかといいますと、もう1個DRGを追加すればOKです。
付録
DRGv2のエンハンスメント
従来のDRGv1と比較し、大きなエンハンスメントがあります。
詳細は、以下のアナウンス記事をご参照ください。
Introducing global connectivity and enhanced cloud networking with the dynamic routing gateway
サービス制限
サービス制限は、リソースに対して設定される割当てまたは許容量です。これらの制限は、OCIリソースの使用状況およびアカウントの存続期間に基づいて自動的に増加する場合があります。サービス制限の増加をリクエストすることもできます 。下記以外のリソースに係るサービス制限はマニュアルを参照。
ネットワーク関連
※ 1. 一つリージョンに、最大300個のVCNまで増やすのは可能です。
※ 2. このリソースの制限を増やすことはできません。
DRG関連
※、このリソースの制限を増やすことはできません。
以上です。
関連記事
オラクル・クラウド関連の個人ブログ
On-PとOCI間のIPSec VPN接続のシミュレーション (Libreswanを利用)
OCI 各種GWのまとめ
オフィシャル資料
アーキテクチャ・センター/参照アーキテクチャ (日本語)
動的ルーティング・ゲートウェイを使用したハブ・アンド・スポーク・ネットワーク・トポロジの設定