この記事では、Azure で高可用性を実現するために一連のネットワーク仮想アプライアンス (NVA) をデプロイするための最も一般的なオプションについて説明します。 NVA は通常、De-Militarized ゾーン (DMZ) 仮想ネットワークとパブリック インターネットの間など、さまざまなセキュリティ レベルで分類されたネットワーク セグメント間のトラフィックフローを制御したり、VPN や SDWAN (Software-Defined WAN) アプライアンスなどの外部の場所を Azure に接続したりするために使用されます。
さまざまなセキュリティ ゾーン間のトラフィックを検査するために NVA が使用される設計パターンは多数あります。次に例を示します。
- 仮想マシンからインターネットへのエグレス トラフィックを検査し、データ流出を防ぐため。
- インターネットから仮想マシンへのイングレス トラフィックを検査し、攻撃を防ぐため。
- Azure 内の仮想マシン間のトラフィックをフィルター処理して、侵害されたシステムの横移動を防ぐ。
- オンプレミス システムと Azure 仮想マシンの間のトラフィックをフィルター処理する (異なるセキュリティ レベルに属していると見なされる場合)。 (たとえば、Azure が DMZ をホストし、内部アプリケーションをオンプレミスでホストしている場合など)。
- オンプレミス ネットワークやその他のパブリック クラウドなどの外部の場所から VPN または SDWAN トンネルを終了するため。
NVA には、次のような多くの例があります。
- ネットワーク ファイアウォール
- レイヤー 4 のリバース プロキシ
- IPsec VPN エンドポイント
- SDWAN アプライアンス
- Web アプリケーション ファイアウォール機能を備えた Web ベースのリバース プロキシ
- Azure からアクセスできるインターネット ページを制限するインターネット プロキシ
- レイヤー 7 ロード バランサー
これらの NVA はすべて、この記事で説明するパターンを使用して Azure デザインに挿入できます。 Azure Firewall や Azure Application Gateway などの Azure ファースト パーティのネットワーク仮想アプライアンスでも、この記事で後述する設計を使用。 これらのオプションを理解することは、設計の観点とネットワークの問題のトラブルシューティングの両方で重要です。
最初に答える必要がある質問は、ネットワーク仮想アプライアンスの高可用性が必要な理由です。 その理由は、これらのデバイスがネットワーク セグメント間の通信を制御するためです。 使用できない場合、ネットワーク トラフィックは流れず、アプリケーションは動作を停止します。 スケジュールされた停止と予定外の停止により、NVA インスタンスが (Azure またはその他のクラウド内の他の仮想マシンと同様に) ダウンすることがあります。 これらの NVA が Premium Managed Disks で構成され、Azure で単一インスタンスの SLA を提供するように構成されている場合でも、インスタンスは停止します。 そのため、高可用性アプリケーションには、接続を確保できる少なくとも 2 つ目の NVA が必要です。
前提条件: この記事では、Azure ネットワーク、Azure Load Balancer、および仮想ネットワーク トラフィック ルーティング (UDR) の に関する基本的な理解を前提としています。
Azure VNet にネットワーク仮想アプライアンスをデプロイするための最適なオプションを選択する場合、考慮すべき最も重要な側面は、NVA ベンダーがその特定の設計を検証して検証したかどうかです。 ベンダーは、NVA を Azure に統合するために必要な NVA 構成も提供する必要があります。 NVA ベンダーが NVA でサポートされている設計オプションとして異なる代替手段を提供している場合、次の要因が決定に影響を与える可能性があります。
- 収束時間: 失敗した NVA インスタンスからトラフィックを離れるには、各設計でどのくらいの時間がかかりますか?
- トポロジのサポート: 各設計オプションでサポートされる NVA 構成 n+1 冗長性を備えたアクティブ/アクティブ、アクティブ/スタンバイ、スケールアウト NVA クラスター
- トラフィックの対称性: 特定の設計では、非対称ルーティングを回避するために、NVA がパケットに対してソース ネットワーク アドレス変換 (SNAT) を実行するように強制されますか? または、トラフィックの対称性は他の方法で適用されますか?
ドキュメントの次のセクションでは、NVA をハブ アンド スポーク ネットワークに統合するために使用される最も一般的なアーキテクチャについて説明します。
注
この記事では、Hub & Spoke の設計に焦点を当てています。 Virtual WAN は、Virtual WAN ハブで特定の NVA がサポートされているかどうかに応じて、NVA のデプロイ方法に関してはるかに規範的であるため、説明されていません。 詳細については、Virtual WAN ハブ のネットワーク仮想アプライアンスの を参照してください。
HA アーキテクチャの概要
次のアーキテクチャでは、高可用性 NVA に必要なリソースと構成について説明します。
| 解決策 | メリット | 考慮 事項 |
|---|---|---|
| Azure Load Balancer | 良好な収束時間でアクティブ/アクティブ、アクティブ/スタンバイ、スケールアウト NVA をサポート | NVA では、正常性プローブ (特にアクティブ/スタンバイデプロイ用) のポートを提供する必要があります。 トラフィックの対称性を必要とするファイアウォールなどのステートフル アプライアンスの場合、インターネットとの間のフローには SNAT が必要です |
| Azure Route Server | NVA は BGP をサポートする必要があります。 アクティブ/アクティブ、アクティブ/スタンバイ、スケールアウト NVA をサポートします。 | トラフィックの対称性にも SNAT が必要 |
| Gateway Load Balancer | SNAT なしでトラフィックの対称性が保証されます。 NVA はテナント間で共有できます。 良好な収束時間。 アクティブ/アクティブ、アクティブ/スタンバイ、スケールアウト NVA をサポートします。 | インターネット間のフローをサポートし、East-West フローはサポートしません |
| PIP/UDR の変更の | NVA に特別な機能は必要ありません。 対称トラフィックを保証する | アクティブ/パッシブ 設計の場合のみ。 1 ~ 2 分の高い収束時間 |
ロード バランサーの設計
この設計では、2 つの Azure Load Balancer を使用して、NVA のクラスターをネットワークの残りの部分に公開します。 このアプローチは、ステートフル NVA とステートレス NVA の両方で頻繁に使用されます。
- 内部ロード バランサーは、Azure とオンプレミスからの内部トラフィックを NVA にリダイレクトするために使用されます。 この内部ロード バランサーは、すべての TCP/UDP ポートが NVA インスタンスにリダイレクトされるように、HA ポート規則を使用して構成されます。
- パブリック ロード バランサーは、NVA をインターネットに公開します。 HA ポート は受信トラフィック用であるため、個々のすべての TCP/UDP ポートを専用の負荷分散規則で開く必要があります。
次の図は、インターネットからスポーク VNet 内のアプリケーション サーバーへのパケットがファイアウォール NVA を通過し、パブリック インターネットとの間のトラフィック (北/南トラフィックとも呼ばれます) を制御するホップのシーケンスを示しています。
Azure Load Balancer 統合する
このアーキテクチャの Visio ファイル をダウンロードします。
NVA を介してスポークからパブリック インターネットにトラフィックを送信するメカニズムは、内部ロード バランサーの IP アドレスを次ホップする 0.0.0.0/0 の User-Defined ルートです。
Azure とパブリック インターネットの間のトラフィックの場合、トラフィック フローの各方向が異なる Azure Load Balancer を通過します。 これは、ファイアウォール NVA にパブリック ネットワークと内部ネットワークの両方に 1 つの NIC がある場合でも発生します。イングレス パケットはパブリック ALB を通過し、エグレス パケットは内部 ALB を通過します。 フローの両方向が異なるロード バランサーを通過するため、トラフィックの対称性が必要な場合は、ほとんどのファイアウォールで通常のように、戻りトラフィックを引き付け、トラフィックの非対称性を回避するために、NVA インスタンスによってソース ネットワーク アドレス変換 (SNAT) を実行する必要があります。
ロード バランサーと同じ設計を使用して、内部ロード バランサーのみが関係する Azure とオンプレミス ネットワーク (東部/西部) 間のトラフィックを検査することもできます。
NVA を介してスポーク間でトラフィックを送信するメカニズムはまったく同じであるため、他の図は提供されません。 上の図の例では、spoke1 はスポーク 2 の範囲を認識していないため、0.0.0.0/0 UDR はスポーク 2 宛のトラフィックを NVA の内部 Azure Load Balancer に送信します。
オンプレミス ネットワークと Azure 間、または Azure 仮想マシン間のトラフィックの場合、内部 Azure Load Balancer によって単一 NIC NVA でトラフィックの対称性が保証されます。トラフィック フローの双方向が同じ Azure Load Balancer を通過すると、同じ NVA インスタンスがロード バランサーによって選択されます。 デュアル NIC NVA の場合、通信の各感覚に内部ロード バランサーがある場合は、上記の北/南の例のように、トラフィックの対称性を SNAT 経由で提供する必要があります。
この設計でデュアル NIC NVA が直面するもう 1 つの課題は、ロード バランサーの正常性チェックに応答を返す場所です。 Azure Load Balancer では、正常性チェックのソースと同じ IP アドレスが常に使用されます (168.63.129.16)。 NVA は、受信したのと同じインターフェイスで、この IP アドレスから送信された正常性チェックの応答を送信できる必要があります。 宛先ベースのルーティングは常に同じ NIC を介して正常性チェックに応答を送信するため、これは通常、オペレーティング システム内の複数のルーティング テーブルを必要とします。
Azure Load Balancer には、個々の NVA の停止で良好な収束時間があります。 正常性プローブ は 5 秒ごとに送信でき、失敗したプローブを 3 回使用してサービス外のバックエンド インスタンスを宣言するため、通常、Azure Load Balancer が別の NVA インスタンスへのトラフィックを収束するのに 10 秒から 15 秒かかります。
このセットアップでは、アクティブ/アクティブ構成とアクティブ/スタンバイ構成の両方がサポートされます。 アクティブ/スタンバイ構成の場合、NVA インスタンスは、アクティブロール内のインスタンスの Load Balancer 正常性プローブにのみ応答する TCP/UDP ポートまたは HTTP エンドポイントを提供する必要があります。
L7 ロード バランサーの使用
セキュリティ アプライアンスに対するこの設計の特定のケースでは、Azure パブリック ロード バランサーを、Azure Application Gateway (単独で NVA と見なすことができる) などの Layer-7 ロード バランサーに置き換えます。 この場合、NVA では、ワークロード システムからのトラフィックに対して内部ロード バランサーのみが必要です。 このメカニズムは、前のセクションで説明した Azure Load Balancer の正常性チェックに関するルーティングの問題を回避するために、デュアル NIC デバイスで使用される場合があります。 この設計の 1 つの制限は、レイヤー 7 ロード バランサー (通常は HTTP) でサポートされるレイヤー 7 プロトコルのみをサポートすることです。
NVA は、レイヤー 7 ロード バランサーでサポートされていないプロトコルと、可能性のあるすべてのエグレス トラフィックに対して受信トラフィックを受け取る必要があります。 NVA として Azure Firewall を使用する場合のこの構成の詳細と、レイヤー 7 Web リバース プロキシとして Azure Application Gateway を使用する場合の詳細については、仮想ネットワーク のファイアウォールと Application Gateway のに関するページを参照してください。
Azure Route Server
Azure Route Server は、NVA が Border Gateway Protocol (BGP) 経由で Azure SDN と対話できるようにするサービスです。 NVA は、Azure VNet に存在する IP プレフィックスを学習するだけでなく、Azure の仮想マシンの有効なルート テーブルにルートを挿入できます。
Azure Route Server 統合する
上の図では、各 NVA インスタンスが Azure Route Server と BGP 経由でピアリングされています。 Azure Route Server は NVA によってアドバタイズされたルートをプログラムするため、スポーク サブネットにはルート テーブルは必要ありません。 Azure 仮想マシンで 2 つ以上のルートがプログラムされている場合は、Equal Cost MultiPathing (ECMP) を使用して、すべてのトラフィック フローに対して NVA インスタンスの 1 つを選択します。 その結果、トラフィックの対称性が要件である場合、SNAT はこの設計で必須となります。
この挿入方法では、アクティブ/アクティブ (すべての NVA が同じルートを Azure Route Server にアドバタイズ) とアクティブ/スタンバイ (1 つの NVA は、他の NVA よりも短い AS パスでルートをアドバタイズ) の両方をサポートします。 Azure Route Server では、最大 8 つの BGP 隣接関係がサポートされています。 そのため、アクティブな NVA のスケールアウト クラスターを使用する場合、この設計では最大 8 つの NVA インスタンスがサポートされます。
この設定では収束時間が速く、BGP 隣接性のキープアライブ タイマーとホールドタイム タイマーの影響を受けます。 Azure Route Server には既定のキープアライブ タイマーとホールドタイム タイマー (それぞれ 60 秒と 180 秒) が設定されていますが、NVA は BGP 隣接性の確立中に下位タイマーをネゴシエートできます。 これらのタイマーを低く設定すると、BGP が不安定になる可能性があります。
この設計は、Azure ルーティングと対話する必要がある NVA の最も一般的なオプションです。たとえば、通常は BGP が適切にサポートされており、Azure VNet で構成されているプレフィックスを学習したり、ExpressRoute プライベート ピアリング経由で特定のルートをアドバタイズしたりする必要がある SDWAN や IPsec NVA などです。 通常、この種類のアプライアンスはステートレスであるため、トラフィックの対称性は問題ではないため、SNAT は必要ありません。
Azure Gateway Load Balancer
Azure Gateway Load Balancer は、User-Defined ルートを使用してトラフィックを誘導することなく、データ パスに NVA を挿入する新しい方法です。 Azure Load Balancer またはパブリック IP アドレスを介してワークロードを公開する仮想マシンの場合、受信トラフィックと送信トラフィックは、別の VNet にある NVA のクラスターに透過的にリダイレクトできます。 次の図は、ワークロードが Azure Load Balancer を介してアプリケーションを公開する場合に、パブリック インターネットからの受信トラフィックに対してパケットが従うパスを示しています。
ゲートウェイ ロード バランサー統合する
この NVA インジェクション方法の主な利点の 1 つは、トラフィックの対称性を保証するためにソース ネットワーク アドレス変換 (SNAT) が必要ない点です。 この設計オプションのもう 1 つの利点は、同じ NVA を使用して異なる VNet との間のトラフィックを検査できるため、NVA の観点からマルチテナントを実現できることです。 NVA VNet とワークロード VNet の間に VNet ピアリングは必要ありません。また、ワークロード VNet では User-Defined ルートは必要ありません。これにより、構成が大幅に簡略化されます。
ゲートウェイ ロード バランサーを使用したサービスの挿入は、Azure パブリック ロード バランサーにヒットする受信フロー (およびその戻りトラフィック) と、Azure から送信される送信フローに使用できます。 Azure 仮想マシン間の East-West トラフィックは、NVA インジェクションにゲートウェイ ロード バランサーを利用できません。
NVA クラスターでは、Azure Load Balancer 正常性チェック プローブを使用して個々の NVA インスタンスの障害を検出し、迅速な収束時間 (10 ~ 15 秒) を実現します。
PIP-UDR の変更
この設計の背後にある考え方は、NVA の冗長性なしで必要となるセットアップを行い、NVA がダウンタイムに苦しむ場合に備えて変更することです。 次の図は、Azure パブリック IP アドレスがアクティブ NVA (NVA1) にどのように関連付けられているかを示しています。また、スポーク内の User-Defined ルートには、アクティブな NVA の IP アドレスが次ホップ (10.0.0.37) として割り当てられます。
PIP/UDR
アクティブな NVA が使用できなくなった場合、スタンバイ NVA は Azure API を呼び出してパブリック IP アドレスとスポーク User-Defined ルートをそれ自体に再マップします (またはプライベート IP アドレスも移動します)。 これらの API 呼び出しが有効になるまでに数分かかる場合があります。そのため、この設計では、このドキュメントのすべてのオプションの収束時間が最悪になります。
この設計のもう 1 つの制限事項は、アクティブ/スタンバイ構成のみがサポートされるため、スケーラビリティの問題につながる可能性があります。NVA でサポートされる帯域幅を増やす必要がある場合、この設計の唯一のオプションは両方のインスタンスをスケールアップすることです。
この設計の利点の 1 つは、特定の時点でアクティブな NVA が 1 つしかないため、トラフィックの対称性を保証するためにソース ネットワーク アドレス変換 (SNAT) が必要ないということです。
貢献者
この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。
主要な著者:
- キース・メイアー |プリンシパル クラウド ソリューション アーキテクト
- Telmo Sampaio | プリンシパル サービス エンジニアリング マネージャー
- ホセ・モレノ |プリンシパル エンジニア
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- Azure Firewall を使用してセキュリティで保護されたハイブリッド ネットワーク を実装 方法について説明します。
- 境界ネットワーク - クラウド導入フレームワークの
- クラウド DMZ - クラウド導入フレームワークの