この記事では、Azure で高可用性を実現するために一連のネットワーク仮想アプライアンス (NVA) をデプロイする一般的な方法について説明します。 NVA は通常、異なるセキュリティ レベルを持つネットワーク セグメント間のトラフィックフローを制御します。 たとえば、境界ネットワーク仮想ネットワークとパブリック インターネットの間で NVA を使用したり、仮想プライベート ネットワーク (VPN) またはソフトウェア定義 WAN (SD-WAN) アプライアンスを介して外部の場所を Azure に接続したりできます。
この記事では、Azure ネットワーク、 Azure ロード バランサー、 仮想ネットワーク トラフィック ルーティング、ユーザー定義ルート (UDR) に関する基本的な理解があることを前提としています。
多くの設計パターンでは、NVA を使用して、異なるセキュリティ ゾーン間のトラフィックを検査します。 これらのパターンでは、次の目的で NVA が使用される場合があります。
仮想マシンからインターネットへのエグレス トラフィックを検査し、データ流出を防ぐため。
インターネットから仮想マシンへのイングレス トラフィックを検査し、攻撃を防ぐため。
侵害されたシステムの横移動を防ぐために、Azure 内の仮想マシン間のトラフィックをフィルター処理します。
オンプレミス システムと Azure 仮想マシンの間のトラフィックをフィルター処理するには (特に、異なるセキュリティ レベルに属している場合)。 たとえば、Azure は境界ネットワークをホストし、オンプレミス環境では内部アプリケーションをホストします。
オンプレミス ネットワークやその他のパブリック クラウドなど、外部の場所から VPN または SD-WAN トンネルを終了する。
この記事のパターンを使用して、Azure デザインに次の NVA を追加できます。
- ネットワーク ファイアウォール
- レイヤー 4 のリバース プロキシ
- インターネット プロトコル セキュリティ (IPsec) VPN エンドポイント
- SD-WAN アプライアンス
- Web アプリケーション ファイアウォール機能を持つ Web ベースのリバース プロキシ
- Azure からアクセスできるインターネット ページを制限するインターネット プロキシ
- レイヤー 7 ロード バランサー
Azure Firewall や Azure Application Gateway などの Azure ネイティブ NVA では、この記事で後述する設計を使用します。 これらのオプションは、設計の観点から、およびネットワークのトラブルシューティングを目的として理解する必要があります。
NVA は多くの場合、ネットワーク セグメント間の通信を制御するため、高可用性を必要とします。 NVA が使用できなくなった場合、ネットワーク トラフィックはフローできず、アプリケーションは動作を停止します。 スケジュールされた停止とスケジュールされていない停止により、Azure または他のクラウド内の他の仮想マシンと同様に、NVA インスタンスがシャットダウンされる場合があります。 NVA インスタンスは、Azure で単一インスタンスのサービス レベル アグリーメントを提供する Azure Premium SSD を使用して構成した場合でもシャットダウンする可能性があります。 高可用性アプリケーションでは、接続を確保するために少なくとも 2 つの NVA が必要です。
NVA を Azure 仮想ネットワークにデプロイするための最適なオプションを選択する場合、最も重要な側面は、NVA ベンダーが設計を評価して検証したかどうかです。 ベンダーは、NVA を Azure に統合するために必要な NVA 構成も提供する必要があります。 NVA ベンダーがサポートされている複数の設計オプションを提供する場合は、次の要因を考慮して決定してください。
収束時間: 失敗した NVA インスタンスからトラフィックを再ルーティングするために各設計が要する時間
トポロジのサポート: 各設計オプションでサポートされる NVA 構成 (冗長性のために追加のユニットがあるアクティブ/アクティブ、アクティブ/スタンバイ、スケールアウト NVA クラスターなど)
トラフィックの対称性: 特定の設計で NVA がパケットに対してソース ネットワーク アドレス変換 (SNAT) を強制的に実行して非対称ルーティングを回避するかどうか、または他の方法でトラフィック対称を適用するかどうか
注
この記事では 、ハブアンドスポークの設計について説明します。 この記事では、Virtual Wan ハブが特定の NVA をサポートしているかどうかに応じて、NVA をデプロイするためのより規範的なガイドラインがあるため、 Azure Virtual WAN については説明しません。 詳細については、 Virtual WAN ハブの NVA を参照してください。
次のセクションでは、NVA をハブアンドスポーク ネットワークに統合するために使用できる一般的なアーキテクチャについて説明します。
高可用性アーキテクチャの概要
| 解決策 | メリット | 考慮事項 |
|---|---|---|
| Azure Load Balancer | このソリューションでは、アクティブ/アクティブおよびアクティブ/スタンバイ構成と、良好な収束時間のスケールアウト NVA をサポートします。 | NVA では、正常性プローブ (特にアクティブ/スタンバイデプロイ用) のポートを提供する必要があります。 トラフィックの対称性を必要とするファイアウォールなどのステートフル アプライアンスの場合、インターネットとの間のフローには SNAT が必要です。 |
| Azure Route Server | NVA はボーダー ゲートウェイ プロトコル (BGP) をサポートしている必要があります。 このソリューションでは、アクティブ/アクティブ、アクティブ/スタンバイ、スケールアウトの NVA がサポートされます。 | このソリューションでは、トラフィックの対称性に SNAT が必要です。 |
| Azure Gateway Load Balancer | トラフィックの対称性は、SNAT なしで保証されます。 NVA はテナント間で共有できます。 このソリューションは収束時間が短く、アクティブ-アクティブ構成、アクティブ-スタンバイ構成、スケールアウトNVAに対応しています。 | このソリューションは、インターネットとの間のフローをサポートし、East-West フローをサポートしていません。 |
| 動的プライベート IP アドレスと UDR | NVA には特別な機能は必要ありません。 このソリューションでは、対称トラフィックが保証されます。 | このソリューションは、アクティブ/パッシブ設計専用です。 1 分から 2 分の高い収束時間を持ちます。 |
ロードバランサー (負荷分散装置)
Load Balancer の設計では、2 つの Azure ロード バランサーを使用して、NVA のクラスターをネットワークの残りの部分に公開します。 このアプローチは、ステートフル NVA とステートレス NVA の両方に適しています。
内部ロード バランサーは、Azure とオンプレミスからの内部トラフィックを NVA にリダイレクトします。 この内部ロード バランサーは 、すべての伝送 制御プロトコル (TCP) ポートとユーザー データグラム プロトコル (UDP) ポートが NVA インスタンスにリダイレクトされるように、高可用性ポート規則で構成されます。
パブリック ロード バランサーは、NVA をインターネットに公開します。 高可用性ポートは受信トラフィック用であるため、各 TCP/UDP ポートを専用の負荷分散規則で開く必要があります。
次の図は、パケットがインターネットからスポーク仮想ネットワーク内のアプリケーション サーバーに送信するホップのシーケンスを示しています。 これらのパケットは、ファイアウォール NVA を通過して、パブリック インターネットとの間のトラフィック ( North-South トラフィックとも呼ばれます) を制御します。
このアーキテクチャの Visio ファイルをダウンロードします。
この設計では、NVA を介してスポークからパブリック インターネットにトラフィックを送信するために、 0.0.0.0/0に UDR を使用します。 次ホップは、内部ロード バランサーの IP アドレスです。
Azure とパブリック インターネットの間のトラフィックの場合、トラフィック フローの各方向が異なる Azure ロード バランサーを通過します。 このプロセスは、ファイアウォール NVA にパブリック ネットワークと内部ネットワークの両方に 1 つのネットワーク インターフェイス カード (NIC) がある場合でも発生します。これは、イングレス パケットがパブリック Azure ロード バランサーを通過し、エグレス パケットが内部 Azure ロード バランサーを通過するためです。 フローの両方向は、異なるロード バランサーを通過します。 そのため、トラフィックの対称性が必要な場合、NVA インスタンスは SNAT を実行してリターン トラフィックを引き付け、トラフィックの対称性を確保する必要があります。 ほとんどのファイアウォールでは、トラフィックの対称性が必要です。
次の図は、同じロード バランサー設計を使用して、Azure とオンプレミス ネットワーク間のトラフィック、または内部ロード バランサーのみを含む トラフィックEast-West 検査する方法を示しています。 この方法を使用して、NVA を介してスポーク間でトラフィックを送信することもできます。
前の図では、スポーク 1 はスポーク 2 の範囲について認識していません。 そのため、 0.0.0.0/0 UDR は、スポーク 2 用のトラフィックを NVA の内部 Azure ロード バランサーに送信します。
オンプレミス ネットワークと Azure 間、または Azure 仮想マシン間のトラフィックの場合、内部 Azure ロード バランサーによって単一 NIC NVA でトラフィックの対称性が保証されます。 トラフィック フローの双方向が同じ Azure ロード バランサーを通過すると、ロード バランサーは双方向に同じ NVA インスタンスを選択します。 デュアル NIC NVA 設計に通信の方向ごとに内部ロード バランサーがある場合、SNAT によってトラフィックの対称性が確保されます。 前の North-South 図は、この設計の例を示しています。
この設計では、デュアル NIC NVA は、ロード バランサーの正常性チェックに応答を送信する場所を決定する必要があります。 Load Balancer では、正常性チェックのソースと同じ IP アドレスが常に使用されます。これは 168.63.129.16。 NVA は、受信したのと同じインターフェイスを介してこれらの正常性チェック応答を送信する必要があります。 宛先ベースのルーティングは同じ NIC を介して応答を送信するため、このプロセスでは通常、オペレーティング システムに複数のルーティング テーブルが必要です。
Azure ロード バランサーは、個々の NVA の停止で良好な収束時間を持っています。 正常性プローブは 5 秒ごとに送信でき、失敗した 3 つのプローブを使用して、バックエンド インスタンスをサービス外として宣言します。 そのため、通常、Azure ロード バランサーが別の NVA インスタンスにトラフィックを収束するのに 10 秒から 15 秒かかります。
このセットアップでは、アクティブ/アクティブ構成とアクティブ/スタンバイ構成の両方がサポートされます。 アクティブ/スタンバイ構成の場合、NVA インスタンスは、現在アクティブロールにあるインスタンスのロード バランサーの正常性プローブにのみ応答する TCP または UDP ポートまたは HTTP エンドポイントを提供する必要があります。
レイヤー 7 ロード バランサー
セキュリティ アプライアンスの特定の設計により、Azure パブリック ロード バランサーは、NVA 自体と見なすことができる Azure Application Gateway などの Layer-7 ロード バランサーに置き換えられます。
このシナリオでは、NVA はワークロード システムからのトラフィックに対して内部ロード バランサーのみを必要とします。 Dual-NIC デバイスでは、この方法を使用して、Azure ロード バランサーの正常性チェックに関するルーティングの問題を回避することがあります。 この設計では、レイヤー 7 ロード バランサーがサポートするレイヤー 7 プロトコル (通常は HTTP と HTTPS) のみがサポートされます。
NVA は、レイヤー 7 ロード バランサーがサポートしていないプロトコルの受信トラフィックを処理する必要があります。 NVA はエグレス トラフィックも処理する場合があります。 詳細については、「 仮想ネットワークのファイアウォールとアプリケーション ゲートウェイ」を参照してください。
ルート サーバー
Route Server は、NVA が BGP 経由で Azure ソフトウェア定義ネットワークと対話できるようにするサービスです。 NVA は、Azure 仮想ネットワークに存在する IP アドレス プレフィックスを学習します。 また、Azure の仮想マシンの有効なルート テーブルにルートを挿入することもできます。
前の図では、各 NVA インスタンスが BGP 経由でルート サーバーに接続しています。 ルート サーバーは NVA によってアドバタイズされるルートをプログラムするため、この設計ではスポーク サブネット内のルート テーブルは必要ありません。 Azure 仮想マシンで複数のルートがプログラムされている場合は、等コストのマルチパス ルーティングを使用して、すべてのトラフィック フローに対して NVA インスタンスの 1 つを選択します。 そのため、トラフィックの対称性が必要な場合は、この設計に SNAT を含める必要があります。
この挿入方法では、アクティブ/アクティブ構成とアクティブ/スタンバイ構成の両方がサポートされます。 アクティブ/アクティブ構成では、すべての NVA が同じルートをルート サーバーにアドバタイズします。 アクティブ/スタンバイ構成では、一方の NVA は、もう一方の NVA よりも短い自律システム (AS) パスを使用してルートをアドバタイズします。 ルート サーバーでは、最大 8 つの BGP 隣接関係がサポートされます。 そのため、アクティブな NVA のスケールアウト クラスターを使用する場合、この設計では最大 8 つの NVA インスタンスがサポートされます。
このセットアップでは、収束時間は高速です。 BGP 隣接性の keepalive および holdtime タイマーは、収束時間に影響します。 Route Server には、既定のキープアライブ タイマーが 60 秒に設定され、holdtime タイマーが 180 秒に設定されています。 ただし、NVA は BGP 隣接性の確立中に下位タイマーをネゴシエートできます。 これらのタイマーを低く設定すると、BGP が不安定になる可能性があります。
この設計は、Azure ルーティングと対話する必要がある NVA に適しています。 たとえば、SD-WAN または IPsec NVA などです。通常は BGP が適切にサポートされています。 これらの NVA は、Azure 仮想ネットワークで構成されたプレフィックスを学習するか、ExpressRoute プライベート ピアリング経由で特定のルートをアドバタイズする必要があります。 これらの種類のアプライアンスは通常ステートレスであるため、トラフィックの対称性は問題ではなく、SNAT は必要ありません。
ゲートウェイロードバランサー
ゲートウェイ ロード バランサー は、UDR を使用してトラフィックをルーティングすることなく、データ パスに NVA を挿入する方法を提供します。 Azure ロード バランサーまたはパブリック IP アドレスを介してワークロードを公開する仮想マシンの場合、受信トラフィックと送信トラフィックを、別の仮想ネットワークにある NVA のクラスターに透過的にリダイレクトできます。 次の図は、ワークロードが Azure ロード バランサーを介してアプリケーションを公開する場合に、パブリック インターネットからの受信トラフィックに対してパケットが従うパスを示しています。
この NVA インジェクション方法には、次の利点があります。
この方法では、トラフィックの対称性を保証するために SNAT は必要ありません。
同じ NVA を使用して、異なる仮想ネットワークとの間のトラフィックを検査できます。これは、NVA の観点からマルチテナントを提供します。
NVA 仮想ネットワークとワークロード仮想ネットワークの間の仮想ネットワーク ピアリングは必要ありません。これにより、構成が簡略化されます。
UDR はワークロード仮想ネットワークでは必要ありません。これにより、構成も簡略化されます。
ゲートウェイ ロード バランサー経由のサービスインジェクションを使用して、Azure パブリック ロード バランサーへの受信トラフィック、そのリターン トラフィック、および Azure からの送信トラフィックを行うことができます。 Azure 仮想マシン間の East-West トラフィックは、NVA インジェクションにゲートウェイ ロード バランサーを使用できません。
NVA クラスターでは、Azure ロード バランサーの正常性チェック プローブによって個々の NVA インスタンスのエラーが検出され、10 ~ 15 秒の迅速な収束時間が提供されます。
動的パブリック IP アドレスと UDR 管理
この設計の目的は、NVA 冗長性なしで機能し、NVA でダウンタイムが発生した場合に変更できるセットアップを用意することです。 次の図は、Azure パブリック IP アドレスがアクティブな NVA (図の NVA1) にどのように関連付けるかを示しています。 スポーク内の UDR は、アクティブな NVA の IP アドレス (10.0.0.37) を次ホップとして使用します。
アクティブな NVA が使用できなくなった場合、スタンバイ NVA は Azure API を呼び出してパブリック IP アドレスとスポーク UDR をそれ自体に再マップするか、プライベート IP アドレスを引き継ぐ。 これらの API 呼び出しが有効になるまでに数分かかる場合があります。 この記事のオプションの中では、この設計の収束時間が最悪です。
この設計では、アクティブ/スタンバイ構成のみがサポートされており、スケーラビリティの問題につながる可能性があります。 NVA でサポートされる帯域幅を増やす必要がある場合は、両方のインスタンスをスケールアップする必要があります。
この設計では、特定の時点でアクティブな NVA は 1 つだけであるため、トラフィックの対称性を保証するために SNAT は必要ありません。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要な著者:
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。