こんにちは。ソリューションアーキテクトの渡邊(dai)です。
このブログでは、SORACOM Door を利用して Azure と閉域接続を組む場合に、VPN を冗長化して障害に強いネットワークを作る方法を解説します。
過去にもSORACOM ↔ Azure 間の閉域接続について、いくつか情報を掲載しています。このブログでは、改めて情報を整理し、障害に強い閉域接続を作る方法を紹介します。
# | 構築パターン | 概要 | 参照ドキュメント |
---|---|---|---|
1 | 1つのVPNでstaticルーティングでの構築 | VPN1つ、内部にトンネルを2つで構築します。必要最小限の構成です。 | 新タイプの VPG で Azure Virtual Machine とプライベートネットワークを構成する |
2 | 2つのVPNで動的(BGP)ルーティングによるActive-Active構成構築 | VPNを2つ、それぞれの内部にトンネルを2つ合計4つのトンネルを構築します。より高い可用性が必要な場合の採用を推奨致します。 | How to connect AWS and Azure using a BGP-enabled VPN gateway※AzureのConnection設定でConnection ModeはResponderOnlyではなくDefaultを推奨 |
また、関連トピックとして、 【Ask SA!】SORACOM Gateの “Gate Peer” を冗長化して、障害に強いネットワークを作る方法 という記事もありますので参考にしてください。
なお、ここで紹介する方法はネットワークへ高い可用性を求める方向けの内容となっています。可用性の向上には再送機能など他の方法も存在しますので、運用されるサービスと求められる非機能要件に応じて適切なものを選択してください。
SORACOM Door とは
SORACOM Door (以下、Door) は、SORACOM プラットフォームとお客様のシステムとを仮想専用線で接続するサービスです。インターネット Virtual Private Network (VPN) を使用してオンプレミスや他のクラウド上にある利用者のシステムと SORACOM のシステムを仮想専用線で接続します。
図に記載されている通り、SORACOM Door は Microsoft Azure との仮想専用線(閉域接続)もサポートしています。具体的には、 Azure VPN Gateway を利用して SORACOM Door との閉域接続を構築することが可能です。
AWS Site-to-Site VPN と Azure VPN Gateway の冗長化の考え方
各サービスでは、同じ VPN といってもそれぞれに微妙な仕様の違いが存在します。まずはじめに、ここでは AWS Site-to-Site VPN と Azure VPN Gateway の冗長化の仕様についておさらいします。
SORACOM DoorのVPNは、AWS Site-to-Site VPN の仕様に準じています。そのため、お客様(今回はAzure側)のネットワークからは、AWS Site-to-Site VPN からの接続のように見えます。そこでここからは、AWS Site-to-Site VPN の仕様を見てみます。
AWS Site-to-Site VPN の冗長化
AWS Site-to-Site VPNは、冗長性を確保するためにデフォルトで Active-Active のトンネルを構成する仕組み(2つのパブリックIPアドレスが払い出される)になっています。1つのカスタマーゲートウェイ(皆さん側のVPNルーター)から2つのIPアドレスそれぞれにトンネルを作成することで、AWS側のメンテナンス等によるトンネルの一時的な切断にも耐えることができます。
Azure VPN Gateway の冗長化
Azure VPN Gateway(以下、VPN Gateway)は標準では Active-Standby で構築されます(参考ブログ)。払い出されるパブリックIPアドレスは1つで、カスタマーゲートウェイはそのアドレスへトンネルを作成します。メンテナンス等の際にはVPN Gateway内でStandbyへ切り替わりますが、フェイルオーバーに約10秒〜3分程度かかります。この時間がサービスへ大きく影響してしまう場合には、Active-Active を検討します。
VPN GatewayのActive-Active構成は、VPN Gatewayを複数作るようなものです。この構成によって2つのパブリックIPアドレスが払い出され、カスタマーゲートウェイからはそれぞれのアドレスに対してトンネルを作成します。これにより高可用性が確保できるわけです。
それぞれの冗長化の仕組みをおさらいしたところで、AWS Site-to-Site VPN と Azure VPN Gateway を冗長化しつつ接続する注意点を見ていきます。
【NGパターン】 Azure との Active-Active VPN 接続(1対1)
AWS Site-to-Site VPN と Azure VPN Gateway を冗長構成でつなげるには、Azure VPN Gateway の Active-Active 構成による2つのパブリックIPアドレスと、AWS Site-to-Site VPN標準の2つのパブリックIPアドレス間でトンネルを作成する方法が考えられます。
しかしながら、この構成は構築できません。
前述の AWS Site-to-Site VPN の図でも、1つの AWS Site-to-Site VPN に対しては、1つのカスタマーゲートウェイをつなげるようになっています。実際に構築を試みても、1つのカスタマーゲートウェイのみが設定できるようになっています。カスタマーゲートウェイは “パブリックIPアドレス” とも言い換えることができるので、「AWS Site-to-Site VPNが持つ2つのパブリックIPアドレスは、1つのパブリックIPアドレスとのみ接続(確立)できる」ことを意味していると言えます。
一方で 、Azure の ページ で ”OnPrem(= オンプレミス)” と書かれている部分を ”AWS” と読み替えると、AWS側では「2 つの Azure VPN Gateway のパブリック IP アドレスへの 2 つの S2S(サイト間) VPN トンネルを受け入れるか確立する※」ように構成する必要があります。これは「Azure VPN Gatewayの Active-Active 構成は、2つのパブリックIPを用いて冗長化をする」という意味です。
このように Azure VPN Gateway の VPN接続は、AWS Site-to-Site VPN が期待するものではないため、この構成は構築できないのです。
※ Azure VPN Gateway で Virtual Network Gateway を作成する際に Active-Active を選択すると、SECOND PUBLIC IP ADDRESS の設定が必要となることからもご理解頂けるかと思います。
実はこれを回避する方法もあります。Azure VPN Gateway を構築する際に、Active-Activeモード、BGPオフ、で構築し、それぞれのルートを静的に設定することで1つのVPNで2つのトンネルを作ることも可能です。ですが、AWS の仕様ではこの場合でも PRIMARY Public IP Address のみを使って構築されてしまいますので、フェイルオーバー時の瞬断は避けられません(冗長性が担保できない)。
【OKパターン】 Azure との Active-Active VPN 接続(2対1)
それでは AWS Site-to-Site VPN と Azure 間で Active-Active な VPN 接続を構築するにはどうすればよいでしょうか。結論から言えば、2つのAWS Site-to-Site VPNと、1つのActive-Active構成のAzure VPN Gatewayを用いることで解決できます。
この件については、AWSのこちらのページ にも記載があります。
カスタマーゲートウェイデバイスが使用できなくなった場合に接続が失われるのを防ぐために、2 番目のカスタマーゲートウェイデバイスを使用して、VPC および仮想プライベートゲートウェイへの 2 番目の Site-to-Site VPN 接続を設定できます。
https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/vpn-redundant-connection.html
また、先程のAzureのページを読み進めると「デュアル冗長性: Azure とオンプレミスの両方のネットワークのアクティブ/アクティブ VPN Gateway」の記載があります。この構成は、オンプレミスをAWSへと置き換えた手順としてこちらのサイトでもドキュメント化されています。
これらのことから、AWS Site-to-Site VPN と Azure VPN Gatewayの接続には「2つの AWS Site-to-Site VPNと 1つのActive-Active 構成のAzure VPN Gatewayで、4つのトンネルを作る」で構築できることがわかりました。構築手順についても Azure の サイトに従って進めることで、構築可能ですので参考にしてください。
以前この構成は、Azure側で「複数 APIPA 指定ができない制約」があったため使用されないダミートンネルが存在していましたが、Azure のアップデート により4つすべてのトンネルが使用できるようになりました。
この方法でVPN接続を構築すると、たとえそれぞれのVPNサービスやコネクションでメンテナンスが発生したとしてもスムーズにフェイルオーバーできます。実際のアプリケーションでは、特にメンテナンスを気にすることなくサービスの提供が可能となります。
なお、こちらの方法で Azure との Active-Active VPN 接続 を構築される際は、SORACOM Door の申請時に以下の点を申し添えて頂ければありがたいです!
- 2つのVPN接続が必要であること(AWS Site-to-Site VPN が2つ必要)
- APIPA のカスタマイズが必要(以前のブログ記載の通り、Azure との BGP接続のため)
その他実際に構築される際の考慮点として、AWS と Azure では以下の仕様の違いがあります。これらは VPN接続先の切替や移行を行う際には特に留意する必要があります。
AWS: Virtual Private Gateway は1VPCに1つだけアタッチ可能
これにより Virtual Private Gateway へ含まれる ASN 番号などを変更する場合には、一度デタッチする必要がありますが、AWS Site-to-Site VPN は複数構築できるため、カスタマーゲートウェイの接続先を増やすなどの操作も既存の接続を維持したまま可能です(SORACOM Door のご利用申請が都度必要です)。
Azure: VPN Gateway は 1VNet に1つだけ作成可能
これにより VPN Gateway へ含まれる Active-Active mode 、BGP設定、ASN 番号、パブリックIPアドレス、APIPA アドレスなどを変更する場合には、既存の VPN接続へ影響を与える可能性があります。また、Connection の追加・削除は可能ですが、Connection の設定は VPN Gateway の設定に依存するので注意が必要です。
複数のサイト間での VPN接続が必要な場合には、Transit Gateway との接続 もご検討ください。
おわりに
最後まで読んでいただき、有難う御座いました!
今回は最近お問い合わせも増えてきた Azure との接続について、昨今の Microsoft Azure のアップデートも交えてご紹介してみました。SORACOM Door と Azure の冗長構成を構築される方はもちろん、AWS と Azure の閉域接続をご検討されている方にもご参考になればうれしいです。
また、Azure に限らず VPN 接続ではカスタマーゲートウェイの仕様の違いにより接続できないこともよくありますので、AWS の公式ドキュメント: カスタマーゲートウェイデバイスのトラブルシューティングもよくご覧頂くと良いかと思います。
― ソラコム渡邊(dai)