高可用性のネットワーク仮想アプライアンスをデプロイするDeploy highly available network virtual appliances

この記事では、高可用性のネットワーク仮想アプライアンス (NVA) セットを Azure にデプロイする方法を示します。This article shows how to deploy a set of network virtual appliances (NVAs) for high availability in Azure. NVA は、通常は、境界ネットワーク (DMZ とも呼ばれます) から他のネットワークまたはサブネットへのネットワーク トラフィックのフローを制御するために使用されます。An NVA is typically used to control the flow of network traffic from a perimeter network, also known as a DMZ, to other networks or subnets. Azure での DMZ の実装については、「Microsoft クラウド サービスとネットワーク セキュリティ」を参照してください。To learn about implementing a DMZ in Azure, see Microsoft cloud services and network security. この記事には、イングレスのみ、エグレスのみ、イングレスとエグレスの両方を行うアーキテクチャの例が含まれています。The article includes example architectures for ingress only, egress only, and both ingress and egress.

前提条件: この記事は、Azure のネットワーク、Azure ロード バランサー、およびユーザー定義ルート (UDR) の基本的な知識があることを前提としています。Prerequisites: This article assumes a basic understanding of Azure networking, Azure load balancers, and user-defined routes (UDRs).

アーキテクチャの図Architecture diagrams

NVA は、さまざまなアーキテクチャの DMZ に配置できます。An NVA can be deployed to a DMZ in many different architectures. たとえば、次の図は、イングレス用の単一の NVA の使用を示しています。For example, the following figure illustrates the use of a single NVA for ingress.

00

このアーキテクチャでは、NVA は、すべての着信ネットワーク トラフィックと発信ネットワーク トラフィックをチェックし、ネットワーク セキュリティ ルールを満たしているトラフィックのみを渡すことによって、セキュリティで保護されたネットワーク境界を提供します。In this architecture, the NVA provides a secure network boundary by checking all inbound and outbound network traffic and passing only the traffic that meets network security rules. ただし、すべてのネットワーク トラフィックが NVA を通過する必要があるという事実は、NVA がネットワークの単一障害点であることを意味します。However, the fact that all network traffic must pass through the NVA means that the NVA is a single point of failure in the network. この NVA で障害が発生した場合、ネットワーク トラフィック用の他のパスが存在しないため、すべてのバックエンド サブネットが使用不能になります。If the NVA fails, there is no other path for network traffic and all the back-end subnets are unavailable.

NVA に高可用性を持たせるには、複数の NVA を可用性セットにデプロイします。To make an NVA highly available, deploy more than one NVA into an availability set.

以下のアーキテクチャは、高可用性の NVA で必要なリソースと構成について説明しています。The following architectures describe the resources and configuration necessary for highly available NVAs:

解決策Solution メリットBenefits 考慮事項Considerations
第 7 層で NVA を使用するイングレスIngress with layer 7 NVAs すべての NVA ノードがアクティブAll NVA nodes are active 接続を終了し SNAT を使用できる NVA が必要Requires an NVA that can terminate connections and use SNAT
インターネットからのトラフィックと Azure からのトラフィック用に別個の NVA セットが必要Requires a separate set of NVAs for traffic coming from the Internet and from Azure
Azure の外部から発信されるトラフィックでのみ使用可能Can only be used for traffic originating outside Azure
第 7 層で NVA を使用するエグレスEgress with layer 7 NVAs すべての NVA ノードがアクティブAll NVA nodes are active 接続を終了し、ソース ネットワーク アドレス変換 (SNAT) を実装できる NVA が必要Requires an NVA that can terminate connections and implements source network address translation (SNAT)
第 7 層で NVA を使用するイングレスとエグレスIngress-Egress with layer 7 NVAs すべてのノードがアクティブAll nodes are active
Azure で発信されたトラフィックを処理可能Able to handle traffic originated in Azure
接続を終了し SNAT を使用できる NVA が必要Requires an NVA that can terminate connections and use SNAT
インターネットからのトラフィックと Azure からのトラフィック用に別個の NVA セットが必要Requires a separate set of NVAs for traffic coming from the Internet and from Azure
PIP-UDR スイッチPIP-UDR switch すべてのトラフィック用の単一の NVA セットSingle set of NVAs for all traffic
すべてのトラフィックを処理可能 (ポート規則に制限なし)Can handle all traffic (no limit on port rules)
アクティブ/パッシブActive-passive
フェールオーバー プロセスが必要Requires a failover process
SNAT なしのPIP-UDRPIP-UDR without SNAT すべてのトラフィック用の単一の NVA セットSingle set of NVAs for all traffic
すべてのトラフィックを処理可能 (ポート規則に制限なし)Can handle all traffic (no limit on port rules)
着信要求に対して SNAT を構成する必要なしDoes not require configuring SNAT for inbound requests
アクティブ/パッシブActive-passive
フェールオーバー プロセスが必要Requires a failover process
調査とフェールオーバーのロジックを仮想ネットワークの外部で実行Probing and failover logic run outside the virtual network

第 7 層で NVA を使用するイングレスIngress with layer 7 NVAs

次の図は、インターネットに接続するロード バランサーの背後にイングレス DMZ を実装する高可用性アーキテクチャを示しています。The following figure shows a high availability architecture that implements an ingress DMZ behind an internet-facing load balancer. このアーキテクチャは、第 7 層のトラフィックで Azure ワークロードへの HTTP や HTTPS などの接続を提供するように設計されています。This architecture is designed to provide connectivity to Azure workloads for layer 7 traffic, such as HTTP or HTTPS:

11

このアーキテクチャの利点は、すべての NVA がアクティブであることであり、片方の NVA で障害が発生すると、ロード バランサーが他方の NVA にネットワーク トラフィックを送信します。The benefit of this architecture is that all NVAs are active, and if one fails the load balancer directs network traffic to the other NVA. 両方の NVA がトラフィックを内部ロード バランサーにルーティングするため、1 つの NVA がアクティブである限り、トラフィックが停止することはありません。Both NVAs route traffic to the internal load balancer so as long as one NVA is active, traffic continues to flow. Web 層の VM を対象とする SSL トラフィックを終了するには、NVA が必要です。The NVAs are required to terminate SSL traffic intended for the web tier VMs. オンプレミスのトラフィックには独自のネットワーク ルートを持つ NVA の別の専用セットが必要であるため、これらの NVA をオンプレミスのトラフィックを処理するように拡張することはできません。These NVAs cannot be extended to handle on-premises traffic because on-premises traffic requires another dedicated set of NVAs with their own network routes.

注意

このアーキテクチャは、Azure とオンプレミスのデータセンターの間の DMZ リファレンス アーキテクチャと Azure とインターネットの間の DMZ リファレンス アーキテクチャで使用されています。This architecture is used in the DMZ between Azure and your on-premises datacenter reference architecture and the DMZ between Azure and the Internet reference architecture. これらのリファレンス アーキテクチャのそれぞれに、使用できるデプロイ ソリューションが含まれています。Each of these reference architectures includes a deployment solution that you can use. 詳細については、リンクを参照してください。Follow the links for more information.

第 7 層で NVA を使用するエグレスEgress with layer 7 NVAs

前述のアーキテクチャを拡張して、Azure ワークロードから発信される要求を処理するエグレス DMZ を提供できます。The previous architecture can be expanded to provide an egress DMZ for requests originating in the Azure workload. 次のアーキテクチャは、DMZ 内の NVA に、HTTP や HTTPS などの第 7 層のトラフィックで高可用性を提供するように設計されています。The following architecture is designed to provide high availability of the NVAs in the DMZ for layer 7 traffic, such as HTTP or HTTPS:

22

このアーキテクチャでは、Azure から発信されるすべてのトラフィックが内部ロード バランサーにルーティングされます。In this architecture, all traffic originating in Azure is routed to an internal load balancer. ロード バランサーは、発信要求を NVA セットに分散します。The load balancer distributes outgoing requests between a set of NVAs. これらの NVA は、それぞれのパブリック IP アドレスを使用して、インターネットにトラフィックを送信します。These NVAs direct traffic to the Internet using their individual public IP addresses.

注意

このアーキテクチャは、Azure とオンプレミスのデータセンターの間の DMZ リファレンス アーキテクチャと Azure とインターネットの間の DMZ リファレンス アーキテクチャで使用されています。This architecture is used in the DMZ between Azure and your on-premises datacenter reference architecture and the DMZ between Azure and the Internet reference architecture. これらのリファレンス アーキテクチャのそれぞれに、使用できるデプロイ ソリューションが含まれています。Each of these reference architectures includes a deployment solution that you can use. 詳細については、リンクを参照してください。Follow the links for more information.

第 7 層で NVA を使用する イングレスとエグレスIngress-egress with layer 7 NVAs

前述の 2 つのアーキテクチャでは、イングレス用とエグレス用に別個の DMZ がありました。In the two previous architectures, there was a separate DMZ for ingress and egress. 次のアーキテクチャは、第 7 層のトラフィックで、HTTP や HTTPS などのイングレスとエグレスの両方で使用できる DMZ の作成方法を示しています。The following architecture demonstrates how to create a DMZ that can be used for both ingress and egress for layer 7 traffic, such as HTTP or HTTPS:

4

このアーキテクチャでは、NVA は、アプリケーション ゲートウェイから着信する要求を処理します。In this architecture, the NVAs process incoming requests from the application gateway. NVA は、ロード バランサーのバックエンド プール内のワークロード VM から発信された要求も処理します。The NVAs also process outgoing requests from the workload VMs in the back-end pool of the load balancer. 着信トラフィックはアプリケーション ゲートウェイによってルーティングされ、発信トラフィックはロード バランサーによってルーティングされるため、NVA は、セッション アフィニティも担当します。Because incoming traffic is routed with an application gateway and outgoing traffic is routed with a load balancer, the NVAs are responsible for maintaining session affinity. つまり、着信要求と発信要求のマッピングはアプリケーション ゲートウェイが管理するため、最初の要求元に適切な応答を転送できます。That is, the application gateway maintains a mapping of inbound and outbound requests so it can forward the correct response to the original requestor. ただし、内部ロード バランサーはアプリケーション ゲートウェイのマッピングにアクセスできないため、独自のロジックを使用して NVA への応答を送信します。However, the internal load balancer does not have access to the application gateway mappings, and uses its own logic to send responses to the NVAs. ロード バランサーは、アプリケーション ゲートウェイから要求を受信していない NVA に応答を送信する場合があります。It's possible the load balancer could send a response to an NVA that did not initially receive the request from the application gateway. この場合、適切な NVA がアプリケーション ゲートウェイに応答を転送できるように、NVA 間で通信を行って応答を転送する必要があります。In this case, the NVAs must communicate and transfer the response between them so the correct NVA can forward the response to the application gateway.

注意

NVA がインバウンドのソース ネットワーク アドレス変換 (SNAT) を確実に実行することで、非対称ルーティングの問題を解決することもできます。You can also solve the asymmetric routing issue by ensuring the NVAs perform inbound source network address translation (SNAT). これにより、要求元のソース IP が、インバウンド フローで使用される NVA のいずれかの IP アドレスに置き換えられます。This would replace the original source IP of the requestor to one of the IP addresses of the NVA used on the inbound flow. これで、ルートの対称性を維持しながら、一度に複数の NVA を使用できます。This ensures that you can use multiple NVAs at a time, while preserving the route symmetry.

第 4 層で NVA を使用する PIP-UDR の切り替えPIP-UDR switch with layer 4 NVAs

次のアーキテクチャは、1 つのアクティブ NVA と 1 つのパッシブ NVA があるアーキテクチャを示しています。The following architecture demonstrates an architecture with one active and one passive NVA. このアーキテクチャでは、第 4 層のトラフィックでのイングレスとエグレスの両方を処理します。This architecture handles both ingress and egress for layer 4 traffic:

33

ヒント

このアーキテクチャの完全なソリューションについては、GitHub を参照してください。A complete solution for this architecture is available on GitHub.

このアーキテクチャは、この記事で説明した最初のアーキテクチャに似ています。This architecture is similar to the first architecture discussed in this article. そのアーキテクチャには、第 4 層の着信要求を受け取ってフィルター処理する単一の NVA が含まれていました。That architecture included a single NVA accepting and filtering incoming layer 4 requests. このアーキテクチャでは、2 つ目のパッシブ NVA を追加して、高可用性を実現します。This architecture adds a second passive NVA to provide high availability. アクティブ NVA で障害が発生した場合は、パッシブ NVA がアクティブになり、その時点でアクティブな NVA の NIC をポイントするように UDR と PIP が変更されます。If the active NVA fails, the passive NVA is made active and the UDR and PIP are changed to point to the NICs on the now active NVA. UDR と PIP に対するこれらの変更は、手動で実行するか、自動化されたプロセスを使用して実行できます。These changes to the UDR and PIP can either be done manually or using an automated process. 自動化されたプロセスは、通常はデーモンまたは Azure で実行されている他の監視サービスです。The automated process is typically daemon or other monitoring service running in Azure. プロセスは、アクティブ NVA の正常性プローブをクエリし、NVA の障害を検出したときに、UDR と PIP の切り替えを実行します。It queries a health probe on the active NVA and performs the UDR and PIP switch when it detects a failure of the NVA.

上記の図は、高可用性デーモンがある ZooKeeper クラスターの例を示しています。The preceding figure shows an example ZooKeeper cluster providing a high availability daemon. ZooKeeper クラスター内では、ノードのクォーラムがリーダーを選出します。Within the ZooKeeper cluster, a quorum of nodes elects a leader. リーダーで障害が発生した場合は、残りのノードによって新しいリーダーが選出されます。If the leader fails, the remaining nodes hold an election to elect a new leader. このアーキテクチャでは、リーダー ノードが、NVA の正常性エンドポイントをクエリするデーモンを実行します。For this architecture, the leader node executes the daemon that queries the health endpoint on the NVA. NVA が正常性プローブに応答できなければ、デーモンがパッシブ NVA をアクティブにします。If the NVA fails to respond to the health probe, the daemon activates the passive NVA. その後、デーモンは、Azure REST API を呼び出して、障害が発生した NVA から PIP を削除して新しくアクティブになった NVA にアタッチします。The daemon then calls the Azure REST API to remove the PIP from the failed NVA and attaches it to newly activated NVA. 次に、デーモンは、新しくアクティブになった NVA の内部 IP アドレスをポイントするように UDR を変更します。The daemon then modifies the UDR to point to the newly activated NVA's internal IP address.

NVA を含むルートを使用してのみアクセスできるサブネットに ZooKeeper ノードを配置しないでください。Do not include the ZooKeeper nodes in a subnet that is only accessible using a route that includes the NVA. 配置すると、NVA で障害が発生した場合に ZooKeeper ノードにアクセスできなくなります。Otherwise, the ZooKeeper nodes are inaccessible if the NVA fails. デーモンが何らかの理由で失敗した場合に、ZooKeeper ノードにアクセスして問題を診断することができなくなります。Should the daemon fail for any reason, you won't be able to access any of the ZooKeeper nodes to diagnose the problem.

サンプル コードを含む完全なソリューションを確認するには、GitHub リポジトリ内のファイルを参照してください。To see the complete solution including sample code, see the files in the GitHub repository.

SNAT なしのPIP-UDR NVAPIP-UDR NVAs without SNAT

このアーキテクチャでは、2 つの Azure 仮想マシンを使用して、自動化されたフェールオーバーをサポートしても送信元ネットワーク アドレス変換 (SNAT) を必要としないアクティブ/パッシブ構成で NVA ファイアウォールをホストします。This architecture uses two Azure virtual machines to host the NVA firewall in an active-passive configuration that supports automated failover but does not require Source Network Address Translation (SNAT).

SNAT アーキテクチャなしのPIP-UDR NVA

ヒント

このアーキテクチャの完全なソリューションについては、GitHub を参照してください。A complete solution for this architecture is available on GitHub.

このソリューションは、NVA ファイアウォールで着信要求に SNAT を構成できない Azure のお客様向けに設計されています。This solution is designed for Azure customers who cannot configure SNAT for inbound requests on their NVA firewalls. SNAT は、元のソース クライアントの IP アドレスを隠します。SNAT hides the original source client IP address. 元の IP を記録する必要があるか、それを NVA の背後にある他の複数層セキュリティ コンポーネント内で使用した場合は、このソリューションに基本的なアプローチが用意されています。If you need to log the original IPs or used them within other layered security components behind your NVAs, this solution offers a basic approach.

UDR テーブル エントリのフェールオーバーは、アクティブな NVA ファイアウォールの仮想マシン上のインターフェイスの IP アドレスに設定された次ホップ アドレスによって自動化されます。The failover of UDR table entries is automated by a next-hop address set to the IP address of an interface on the active NVA firewall virtual machine. 自動化されたフェールオーバーのロジックは、Azure Functions を使用して作成する関数アプリでホストされます。The automated failover logic is hosted in a function app that you create using Azure Functions. フェールオーバーのコードは、Azure Functions 内でサーバーレス関数として実行されます。The failover code runs as a serverless function inside Azure Functions. デプロイは、便利でコスト効率に優れ、管理とカスタマイズが簡単です。Deployment is convenient, cost-effective, and easy to maintain and customize. さらに、関数アプリは Azure Functions 内でホストされるため、仮想ネットワークでの依存関係がありません。In addition, the function app is hosted within Azure Functions, so it has no dependencies on the virtual network. 仮想ネットワークに対する変更が NVA ファイアウォールに影響する場合、関数アプリは独立して実行を続けます。If changes to the virtual network impact the NVA firewalls, the function app continues to run independently. また、テストもより正確です。着信クライアント要求と同じルートを使用して、仮想ネットワークの外部で実行されるためです。Testing is more accurate as well, because it takes place outside the virtual network using the same route as the inbound client requests.

NVA ファイアウォールの可用性を確認するため、関数アプリ コードは、次の 2 つの方法のいずれかでそれをプローブします。To check the availability of the NVA firewall, the function app code probes it in one of two ways:

  • NVA ファイアウォールをホストする Azure 仮想マシンの状態を監視する。By monitoring the state of the Azure virtual machines hosting the NVA firewall.

  • バックエンド Web サーバーに対してファイアウォール経由で開かれたポートがあるかどうかをテストする。By testing whether there is an open port through the firewall to the back-end web server. このオプションは、NVA がテストする関数アプリ コードの PIP を使用してソケットを公開する必要があります。For this option, the NVA must expose a socket via PIP for the function app code to test.

関数アプリを構成するときに使用するプローブの種類を選択します。You choose the type of probe you want to use when you configure the function app. サンプル コードを含む完全なソリューションを確認するには、GitHub リポジトリ内のファイルを参照してください。To see the complete solution including sample code, see the files in the GitHub repository.

次の手順Next steps