Facebook Twitter
お問い合わせ
TOPICS
更新情報
ホーム > ブログ > Oracle Cloud > Azure-OCI間のVPN接続の手順について

Azure-OCI間のVPN接続の手順について

ブログ
Oracle Cloud
Microsoft Azure
2023.06.05

皆さま、こんにちは!y.takanashiです。

ここ最近、OCIは他のクラウドサービスとの相互運用性を重視し、マルチクラウド環境の構築を推進しております。

 

そこで今回は、AzureとOCI間でVPNを使用した接続方法について検証してみましたので、その結果を皆様にご紹介します。


今回の検証の構成

以下は、今回の検証の構成図です。

今回の検証の手順として、

 

1.両クラウド間でのBGPを使用したIPSec接続を設定

       

2.疎通確認のためのルート・ルール追加等の事前準備

       ↓

3.両サーバ間の疎通確認および1GBのダミーファイルを使用した転送時間の計測を実行

 

と行った流れで行います。

 

※両クラウドのネットワーク・リソースとサーバの作成手順は割愛していますので、自身であらかじめ作成しておきましょう。

この記事は個人が検証目的で作成したもので、本番稼働などで設定する際には以下のドキュメントを参考にしてください。

OCI公式ドキュメント - 「AzureへのVPN接続」


Azure側の設定

仮想ネットワーク・ゲートウェイの作成

最初にAzure側の設定を行います。

 

Azureポータルの検索窓から「仮想ネットワークゲートウェイ」と入力し、出力されたサービスを選択します。

仮想ネットワークゲートウェイの作成」から以下の項目を入力します。

  • ゲートウェイ名:任意(ここでは「VNG-to-OCI」)
  • ゲートウェイの種類:VPN
  • VPNの種類:ルートベース
  • SKU:任意(ここではVpnGw1)
  • 世代:任意(ここではGeneration1)
    ※SKUと世代は IKEv2をサポートし、スループット要件を満たすものを選択しましょう。
  • 仮想ネットワーク:任意(ここでは「VNet」)
  • パブリックIPアドレス名:任意(ここでは「Public-IP」)
  • アクティブ/アクティブモードの有効化:無効
  • BGPの構成:有効
  • 自律システム番号(ASN):65515
  • カスタムのAzure APIPA BGP IPアドレス:任意(ここでは169.254.21.2)
    ※ 169.254.21.0/30または169.254.22.0/30から選択する必要があります。

30分程度で仮想ネットワーク・ゲートウェイの作成は完了となります。

 

尚、新規発行されたパブリックIPアドレスはOCI側の設定で使用しますので控えておきましょう。


OCI側の設定

CPE(顧客構内機器)の作成

Azure側で仮想ネットワーク・ゲートウェイの作成完了後、OCI側の設定も行います。

 

OCIコンソール画面左上のハンバーガーアイコンから「ネットワーキング」→顧客接続性内の「顧客構内機器」を選択します。

CPEの作成」から以下の項目を入力します。

  • 名前:任意(ここでは「CPE-to-Azure」)
  • パブリックIPアドレス:Azureの仮想プライベート・ゲートウェイで払い出されたIPアドレスを使用
  • CPEベンダー:Other

IPSec接続の作成

同様にIPSec接続の設定も行います。

OCIコンソール画面左上のハンバーガーアイコンから「ネットワーキング」→顧客接続性内の「サイト間VPN」を選択します。

Create IPSec connection」から以下の項目を入力を行います。

  • 名前:任意(ここでは「IPSec-to-Azure」)
  • 顧客構内機器:任意(ここでは「CPE-to-Azure」)
  • 動的ルーティング・ゲートウェイ:任意(ここでは「DRG2」)
  • オンプレミス・ネットワークへのルート:(空白)
  • トンネル1の名前:任意(ここでは「Tunnel1」)
  • IKEバージョン:IKEv2
  • ルーティング・タイプ:BGP動的ルーティング
  • BGP ASN:65515
    ※デフォルトのAzure BGP ASNを使用します。
  • IPv4トンネル内インタフェース - CPE:任意(ここでは169.254.21.2/30)
  • IPv4トンネル内インタフェース - Oracle:任意(ここでは169.254.21.1/30)
  • Oracle IKE開始:Initiator or responder
  • NAT-T有効:自動
  • デッド・ピア検出タイムアウトの有効化:Initiate or respond
  • フェーズ1(ISAKMP)構成
    • 暗号化アルゴリズム:AES_256_CBC
    • 認証アルゴリズム:SHA2_384
    • Diffie-Hellmanグループ:GROUP24
    • IKEセッション・キー存続期間:28,800秒(8時間)
  • フェーズ2 (IPSec)構成
    • 暗号化アルゴリズム:AES_256_GCM
    • IPSecセッション・キー存続時間:3,600秒(1時間)
    • Diffie-Hellmanグループ:GROUP24
  • ※今回は検証目的のため、トンネル2の設定については省略させていただきます。

ライフサイクルの状態が「使用可能」となればIPSec接続の作成は完了となります。

まだAzureとの接続の設定を行っていないので、IPSec Statusの状態は「停止」となっております。

 

トンネル1のOracle VPN IP addressと共有シークレットは後ほど使用しますので控えておきましょう。


Azure側の設定(再度)

ローカル・ネットワーク・ゲートウェイの作成

OCI側の設定完了後、Azureでローカル・ネットワーク・ゲートウェイの作成を行います。

 

Azureポータルの検索窓から「ローカルネットワークゲートウェイ」と入力し、出力されたサービスを選択します。

ローカルネットワークゲートウェイの作成」から以下の項目を入力します。

  • ゲートウェイ名:任意(ここでは「LGW-to-OCI」)
  • IPアドレス:トンネル1の保存済OCI VPN IPアドレスを入力します。
  • アドレス空間:(空白)
  • BGPの構成:有効
  • 自律システム番号(ASN):31898
  • BGPピアのIPアドレス:「IPV4トンネル内インタフェース - Oracle」で使用されているものと同じIPアドレスを使用します。

VPN接続の作成

ローカル・ネットワーク・ゲートウェイの作成後、先ほど作成した仮想ネットワーク・ゲートウェイからVPN接続の設定を行います。

 

先ほど作成した仮想ネットワーク・ゲートウェイの詳細画面の「接続」から「追加」を選択します。

以下の項目を入力して「OK」を選択します。

  • 名前:任意(ここでは「VPN-to-OCI」)
  • 接続の種類:サイト対サイト(IPsec)
  • 仮想ネットワークゲートウェイ:任意(ここでは「VNG-to-OCI」)
  • ローカルネットワークゲートウェイ:任意(ここでは「LGW-to-OCI」)
  • 共有キー:OCIのIPSec接続設定時の共有キーを使用
  • BGP:有効
  • IKEプロトコル:IKEv2

作成後、VPNの詳細画面の「構成」から赤枠部分のIKEの設定変更を行います。

 

ここでは以下の値に変更後、「保存」を選択します。

  • IKEフェーズ1
    • 暗号化:AES256
    • 整合性またはPRF:SHA384
    • DHグループ:DHGroup24
  • IKEフェーズ2
    • IPsec暗号化:GCMAES256
    • IPsec整合性:GCMAES256
    • PFSグループ:PFS24
  • IPSec SAの有効期間(KB):28,800秒(8時間)
    ※OCIの「IKEセッション・キー存続期間」に相当します。
  • IPSec SAの有効期間(秒):3,600秒(1時間)
    ※OCIの「IPSecセッション・キー存続時間」に相当します。

変更後、VPNの状態は「接続済み」となります。

OCI側もIPSec StatusとIPv4 BGP statusがともに「稼働中」となり、Azureとの接続が確立されていることが確認できます。

以上でAzureとOCI間のVPN接続の設定は全て完了となります。

 

IKEの設定値は以下のドキュメントを参考に設定を行なっておりますのでこちらをご確認ください。

OCI公式ドキュメント - 「サポートされているIPsecパラメータ」


設定後の検証

事前準備

AzureとOCI間のVPN接続を設定した後、両クラウドに配置したサーバ間での疎通確認および1GBのダミーファイルを使用した転送時間の計測を行います。

Azure側では、ルート・テーブルとネットワーク・セキュリティ・グループの設定が必要になります。

ルート・テーブルを作成する場合、Azureポータルの検索窓から「ルートテーブル」と入力し、出力されたサービスを選択します。

作成」から任意の名前(ここでは「RT-to-OCI」)を入力、「確認および作成」を選択します。

ルート・テーブルの作成後、「ルート」→「追加」からOCI用のルートの追加を行います。

  • ルート名:任意(ここでは「to-OCI」)
  • 宛先アドレスのプレフィックス:IPアドレス
  • 宛先 IPアドレス / CIDR範囲:172.16.0.0/16
    ※OCI側のCIDRを入力します。
  • ネクスト・ホップの種類:仮想ネットワーク・ゲートウェイ

同様に「サブネット」→「関連付け」からサーバが配置されているサブネットに紐付けます。

  • 仮想ネットワーク:任意(ここでは「Vnet」)
  • サブネット:任意(ここではdefault)

ネットワーク・セキュリティ・グループは、Azureポータルの検索窓から「ネットワークセキュリティグループ」と入力し、出力されたサービスを選択します。

作成」から任意の名前(ここでは「NSG-to-OCI」)を入力、「確認および作成」を選択します。

ネットワーク・セキュリティ・グループの作成後、「セキュリティ規則」からOCIとの接続用のルールの追加を行います。

 
以下はOCIとVPN接続する際の受信セキュリティ規則の設定例です。

  • ソース:IP Addresses
  • ソースIPアドレス/CIDR範囲:172.16.0.0/16(OCI側のCIDR)
  • ソース・ポート範囲:All(画面上では「*」と記載)
  • 宛先:IP Addresses
  • 宛先IPアドレス/CIDR範囲:10.0.0.0/16(Azure側のCIDR)
  • サービス:Custom
  • 宛先ポート範囲:All(画面上では「*」と記載)
  • プロトコル:Any
  • アクション:許可
  • 優先度:100
  • 名前:AllowCidrBlockCustomAnyInBound

以下はOCIとVPN接続する際の送信セキュリティ規則の設定例です。

  • ソース:IP Addresses
  • ソースIPアドレス/CIDR範囲:10.0.0.0/16(Azure側のCIDR)
  • ソース・ポート範囲:All(画面上では「*」と記載)
  • 宛先:IP Addresses
  • 宛先IPアドレス/CIDR範囲:172.16.0.0/16(OCI側のCIDR)
  • サービス:Custom
  • 宛先ポート範囲:All(画面上では「*」と記載)
  • プロトコル:Any
  • アクション:許可
  • 優先度:110
  • 名前:AllowCidrBlockCustomAnyOutBound


セキュリティ規則の追加後、サーバまたはサブネットにアタッチする必要があります。

 

ここではサブネットにアタッチする例を示します。

ネットワーク・セキュリティ・グループの「サブネット」から「関連付け」を選択します。

任意の仮想ネットワーク(ここでは「Vnet」)とサブネット(ここでは「default」)を入力、「OK」を選択します。

以上でAzure側の事前準備は完了となります。

OCI側では、VCNのルート表とセキュリティ・リスト(もしくはサーバにアタッチしているネットワーク・セキュリティ・グループ)の設定が必要になります。

 

ルート表のルールには、送信先にAzure側のCIDR、ターゲットには作成した動的ルーティング・ゲートウェイを追加します。

セキュリティ・リストのインバウンドルールに、Azure接続用のルールを追加します。


疎通確認

事前準備の完了後、pingコマンドを使用して両サーバ間の疎通確認を行います。

以下がAzure→OCIでの疎通確認の結果となります。

以下がOCI→Azureでの疎通確認の結果となります。


ダミーファイルを使用した転送時間の確認

続いて両クラウドに配置したサーバ間で、1GBのダミーファイルを使用した転送時間の確認を行います。

この検証ではscpコマンドを使用し、転送時間のばらつきを少なくするために10回程度の検証を実行しております。

結果として、

・Azure→OCI間の1GBのダミーファイルの転送時間は平均32秒

・OCI→Azure間の1GBのダミーファイルの転送時間は平均20秒

となり、10秒程度OCIからAzureへのファイル転送速度の方が早いことが判明しております。


まとめ

今回の検証については以上となります。

 


実際に検証して、大まかな流れは一緒ですが、AzureはAWSと比較して設定が容易に行えるという特徴があります。

しかし、仮想ネットワーク・ゲートウェイの作成等のリソースの作成に時間がかかる点が、設定におけるネックであるなと感じました。

 

また、今回の検証では冗長化は行っていませんので、本番稼働する場合には、運用上の要件やセキュリティ要件等に基づいて、トンネルの冗長化を検討してください。

 

以上となります。

この記事を通じて読者の皆様の問題解決の一助となれば幸いです。

最後まで読んで頂き、ありがとうございましたm(_ _)m


この記事が気に入ったら
「いいね!」

この記事を書いた人


関連コンテンツ

CONTACT お問い合わせ

Cloudiiのサービスやプロダクトについて
興味をお持ちの方は、
お気軽にお問い合わせください。