Microsoft Azure (以下、Azure) をハブとする、オンプレミス - Azure - Oracle Cloud Infrastructure (以下、OCI) の相互接続を構築しました。最終的な構成にたどり着くまでに様々な検証を行いましたので、本記事ではその検証内容について紹介します。

構成の説明

最終的に採用した構成図を以下に示します。

こちらの構成では、Azure - OCI 間を VPN サーバーと OCI の VPN 接続サービスを使用して接続しています。オンプレミスから OCI への通信は、オンプレミス → 事業所間網 → Azure 上の VPN サーバー → OCI という流れで行われます。事業所間網 - Azure 間は動的ルーティング (BGP) でルートを伝播しています。オンプレミスから OCI への通信を Azure へ向けるために、Azure VNet の IP アドレス範囲に OCI VCN の IP アドレス範囲を加えています。この設定によって、OCI 宛ての通信を Azure へ送るようルートを事業所間網に伝播しています。

採用に至った経緯

このような構成になった経緯について説明します。今回実現したかったことは、オンプレミス - OCI 間の接続を構築することです。そのため、事業所間網から直接 OCI へ接続しようと考えたのですが、事業所間網が OCI の閉域網接続サービス (FastConnect¹) に対応しておらず断念しました。

そこで以下の4つの構成を考えました。

• Azure をハブとして OCI に接続する
• 各事業所から OCI に対してそれぞれ接続を構築する
• Azure Virtual WAN を使用する
• ExpressRoute Global Reach を使用する

「Azure をハブとして OCI に接続する」方法は最初に紹介した通り、最終的に採用された構成ですので、それ以外の構成を不採用とした理由について説明します。

各事業所から OCI に対してそれぞれ接続を構築する

事業所間網を経由せずに各事業所から直接 OCI に対する接続を構築する方法ですが、ルーティングや管理の手間が増える等、事業所間網を使用している利点を消してしまうため不採用としました。

Azure Virtual WAN を使用する

Azure Virtual WAN は、Azure が提供する WAN サービスです。Azure Virtual WAN を使用する場合、既に利用している事業所間網に加えてもう1つ似たサービスを使用することになります。こちらについては料金との兼ね合いが付かず不採用としました。

ExpressRoute Global Reach を使用する

ExpressRoute Global Reach は、Azure の閉域網接続サービスである ExpressRoute が複数ある場合に、ExpressRoute の接続先であるオンプレミスネットワーク同士の通信を行うことができるようになるサービスです。今回の用途にぴったりなサービスなのですが、サービスの名前に Global と付いている通り、リージョンをまたいだ接続を構築する上で利用されるサービスです。そのため、Global Reach を使用してリンクする2本の ExpressRoute が異なるピアリングの場所である必要があります²。
事業所間網 - Azure 間の ExpressRoute のピアリングの場所で既に東京を使用していたため、新たに OCI との接続で ExpressRoute を構築する場合は、東京以外のピアリングの場所を使用する必要がありました。しかし、東京を除くとピアリングの場所は非常に離れた場所しか存在しなかったため、不採用としました。

検証

以上のような流れで、VPN サーバーを使用して Azure をハブとするオンプレミス - OCI 間の接続を構築したのですが、この構成では以下の課題がありました。

• VPN サーバーの管理コストが高い
• ルーティングの管理コストが高い

どちらに関しても、Azure のマネージドサービスを使用することで管理コストを大幅に下げられることと、VPN サーバーを使用した接続の経験を活かしてマネージドサービスを使用した接続を構築できるのではないかという期待もあり、マネージドサービスを使用した接続の構築検証を行うことになりました。
※これから紹介する検証は、全て実現できなかった構成です。

1つの ExpressRoute に2つの接続

まず試したのが、事業所間網 - Azure 間の接続に使用されている ExpressRoute を使って OCI との接続も構築できないかという検証です。

この構成は、ExpressRoute 1つにつき1つ割り当てられるサービスキーを複数の接続で使いまわせないため、実現することができませんでした。

1つの VNet に2つの ExpressRoute

2つ目に試したのが、1つの VNet に2つの ExpressRoute を接続する方法です。この検証から、OCI 上に2つの VCN を用意し、片方を OCI、もう片方をオンプレミスと見立てて検証を行っています。

この構成では、OCI (oci-subnet) - Azure、オンプレミス (onpremiss-subnet) - Azure の通信は通りますが、オンプレミス (onpremiss-subnet) - OCI (oci-subnet) 間のルートの伝播ができず、期待した結果とはなりませんでした。

1つの VNet に ExpressRoute と VPN

3つ目に試したのが、1つの VNet に ExpressRoute と仮想ネットワークゲートウェイを使用した VPN 接続を構築する方法です。1つの VNet に2つの ExpressRoute を接続する方法では、ユーザー定義のカスタムルートによるデフォルトルートの上書きができないためにオンプレミス - OCI 間のルートの伝播ができませんでした³。種類が VPN の仮想ネットワークゲートウェイであればデフォルトルートの上書きができそうだったため、こちらの構成を試しました。

しかし、こちらの構成では、そもそも VPN 接続が安定して構築できないという状態になりました。これは Azure の VPN 接続に使用するパラメータと OCI の VPN 接続に使用するパラメータが異なることが原因でした（使用する Diffie Hellman グループが異なるため）。OCI のサポートに対応していただいて VPN 接続を構築できましたが、次は BGP に使用する IP アドレス範囲の要件が噛み合わず、BGP を構築することができませんでした。
静的ルートを使用して VPN 接続を構築することはできたものの、1つの VNet に2つの ExpressRoute を接続する方法と同様にカスタムルートによるデフォルトルートの上書きができませんでした。カスタムルートのネクストホップが「なし」と表示されていたことから、VPN 接続が「完全には構成されていない」と判断されたのではないかと考えています³⁴。以上より、この構成についてもオンプレミス - OCI 間のルートの伝播ができないという結果になってしまいました。

2つの VNet に2つの ExpressRoute (VNet ピアリング)

最後に試したのが、2つの VNet に2つの ExpressRoute を使用して、VNet 間は VNet ピアリングを使用した接続を構築する方法です。

こちらの構成は、VNet ピアリングを使用した場合、ピアリングをしている VNet で使用できるゲートウェイは1つのみという制限があったため、実現すること自体ができませんでした⁵。

まとめ

検証を行った4つの構成について、構築できなかった原因を以下にまとめました。

結果としては Azure マネージドの VPN 接続サービスを使用したオンプレミス - OCI 間の接続の構築はできませんでした。ドキュメントに記載されている通り、Azure マネージドのネットワークサービスを、Azure 以外のサービスとのトランジットルーターとして構成することはできないということですね⁶⁷。
今回要件が合わず検証を行わなかった Azure Virtual WAN や、ExpressRoute Global Reach、Azure Route Server というサービス等もありますので、今後のアップデートに合わせてまた構成を考えてみたいと思います⁸。

参考資料