インフラストラクチャの設計方法は、クラウドによって変化しています。これは、ネットワークが物理的でも仮想 LAN でもなくなっているため、ファイアウォールの設計にも当てはまります。 物理ネットワークのすべての機能を仮想ネットワーク (VNet) で使用できるわけではありません。 これにはフローティング IP アドレスやブロードキャスト トラフィックの使用が含まれ、それは HA アーキテクチャの実装に影響します。 ネットワーク仮想アプライアンス (NVA) 用のロード バランサーは、仮想ネットワーク内で高可用性 (HA) アーキテクチャを実現する方法で実装できるか、実装する必要があります。 このガイドでは、サードパーティの仮想アプライアンスを使用して、Azure 上に HA ファイアウォール (FW) を設計するための体系的なアプローチについて説明します。
高可用性 NVA を設計するためのオプション
HA アーキテクチャをデプロイする場合、フェールオーバーを実現するためのオプションがいくつかあります。
- Azure API によって管理されるルート テーブル: このオプションでは、2 つのルート テーブル (1 つはアクティブ、1 つはパッシブ) を使用して、VNet/サブネットで実行されるすべてのサービスのアクティブなゲートウェイ IP の切り替えが行われます。
- Azure API によって管理されるフローティング IP: このオプションでは、アクティブ FW とスタンバイ FW の間を移動できるセカンダリ IP アドレスが FW で使用されます。
- Load Balancer による管理: このオプションでは、サブネットのゲートウェイ IP として機能する Azure Load Balancer が使用され、トラフィックがアクティブ FW に転送されます。 トラフィックのアクティブ/アクティブでの転送が可能であり、真の負荷分散が実現されます。
最初の 2 つのオプションの問題は、フェールオーバー自体が低速であることです。 FW でフェールオーバーを指示する必要があり、これは実質的には、新しいデプロイを通した Azure サービスの "再構成" になります。 デプロイの完了速度によっては、トラフィック フローが数分間ダウンします。 さらに、両方のファイアウォールが同時に動作しているアクティブ/アクティブ構成は許可されません。
そのため、3 番目のオプションが最も推奨されます。 ダウンタイムは、ロード バランサーをほぼ瞬時にスタンバイ ファイアウォールにフェールオーバーできる (アクティブ/パッシブの場合)、または障害が発生したファイアウォールから負荷を削除する (アクティブ/アクティブの場合) ことで、最小限に抑えられます。 ただし、トラフィック フローに影響を与えることと TCP パケットをステートフルにする必要があるため、ロード バランサーを "既定のゲートウェイ" として使用することはできません。
2 脚のファイアウォール
以下の図は、2 つの FW (FW-1 と FW-2)、1 つの外部ロード バランサー、および 1 台のバックエンド サーバー S1 から始まります。
このアーキテクチャは単純なセットアップであり、受信トラフィックで使用されます。 パケットがロード バランサーに到着し、その構成から宛先 FW が選択されます。 次に、選択されたファイアウォールによって、トラフィックがバックエンド (Web) サーバーに送信されます。 FW-1 で SNAT が有効になっている場合は、サーバー S1 でトラフィックが FW-1 の内部 IP から来ていることが認識され、それにより、パケットに対する応答も FW-1 に送信されます。 このシナリオでは、FW-2 へのフェールオーバーをすぐに実行できます。 送信トラフィックの場合、内部に別のロード バランサーを追加できます。 サーバー S1 がトラフィックを開始すると、同じ原則が適用されます。 トラフィックが内部 LB (iLB) に到着すると、外部解決のために NAT 変換を行うファイアウォールが選択されます。
3 脚のファイアウォール
ファイアウォールに別のインターフェイスを追加すると問題が発生し、"内部" ゾーン間で NAT 変換を無効にする必要があります。 この場合は、Subnet-B と Subnet-C を参照してください。
内部ゾーン (Subnet-B と Subnet-C) 間の L3 ルーティングは、どちらも NAT なしで負荷分散されます。 この設定は、ロード バランサーが含まれるトラフィック フローを別の見方で考えるとわかりやすくなります。 下の図は、内部ロードバランサー [iLB] が FW の特定の NIC にリンクされている様子を示しています。
L3 トラフィックでは (NAT なし)、S2 は S1 IP アドレスをソース アドレスと見なします。 そして S2 は (S1-IP が属する) Subnet B のリターン トラフィックを Subnet-C の iLB に送信します。 Subnet-B の iLB と Subnet-C の iLB では各セッションの状態が同期されていないため、負荷分散アルゴリズムによっては、FW-2 でトラフィックが終了する可能性があります。 既定では、FW-2 では最初の (緑色の) パケットがまったく認識されないため、接続が中断されます。
一部のファイアウォール ベンダーでは、ファイアウォール間の接続状態を維持しようとしていますが、接続状態をほぼ瞬時に同期して最新の状態に保つ必要があります。 ファイアウォール ベンダーによってこのセットアップが推奨されている場合は、ベンダーに確認してください。
この問題に対処する最善の方法は、それを排除することです。 上記の例の場合、このソリューションは Subnet-C を排除することを意味します。これにより、仮想化された VNet の利点を活かすことができます。
ネットワーク セキュリティ グループを使用してサブネット内のホストを分離する
1 つのサブネットに 2 つの VM がある場合は、2 つの間のトラフィックを分離する NSG を適用できます。 既定では、VNet 内のトラフィックは完全に許可されます。 NSG に "すべて拒否" ルールを追加すると、すべての VM が相互に分離されます。
VNet で同じバックエンド (仮想) ルーターを使用する
VNet またはサブネットで、Azure から単一のバックエンド ルーター システムを使用します。そのため、各サブネットに対してルーター IP を指定する必要はありません。 ルートの宛先は、同じ VNET 内の任意の場所でも、外部でもかまいません。
仮想化されたネットワークを使用して、すべてのサブネットのルートを制御できます。 これらのルートでは、別のサブネット内の 1 つの IP をポイントすることもできます。 上の図では、これは、2 つのファイアウォールの負荷分散を行う Subnet-D 内の iLB になります。 S1 でトラフィック (緑色) が開始されると、たとえば FW-1 に負荷分散されます。 その後、FW-1 により、S2 に接続されます (緑色)。 S2 は S1 の IP に応答トラフィックを送信します (NAT が無効化されているため)。 ルート テーブルにより、S2 は同じ iLB IP をそのゲートウェイとして使用します。 iLB ではトラフィックを最初のセッションに合わせることができるため、このトラフィックは常に FW-1 にポイントされます。 その後 FW-1 によりこれは S1 に送信され、同期トラフィックフローが確立されます。
この設定が機能するようにするには、FW では、Subnet-B および Subnet-C をデフォルトのサブネット GW に (内部的に) ポイントするルート テーブルを持つ必要があります。 そのサブネット GW は、その VNET のサブネット範囲内で最初に論理的に使用できる IP アドレスです。
リバース プロキシ サービスに与える影響
リバース プロキシ サービスをデプロイすると、 "通常は" FW の内側に配置されます。 代わりに、これを FW と "インライン" で配置して、実際には FW 経由でトラフィックをルーティングすることもできます。 この設定の利点は、リバース プロキシ サービスで、接続しているクライアントの元の IP が "認識" されることです。
この構成のため、Subnet-E のルート テーブルで、内部ロード バランサーを介して Subnet-B と Subnet-C をポイントする必要があります。 一部のリバース プロキシ サービスには、このネットワーク フロー内の FW を一斉に削除できる組み込みファイアウォールがあります。 組み込みのファイアウォールは、リバース プロキシから Subnet-B/C サーバーに直接ポイントします。
このシナリオでは、リターン トラフィックが FW から Subnet-B にフローして拒否されるのを回避するために、リバース プロキシで SNAT が必要になります。
VPN/ER
Azure では、Azure 仮想ネットワーク ゲートウェイを介して、BGP 対応/高可用性 VPN/ER サービスを提供しています。 ほとんどのアーキテクトは、これらをバックエンドまたはインターネットに接続されていない接続に対して保持します。 この設定は、これらの接続の内側にあるサブネットにも、ルーティング テーブルで対応する必要があることを意味します。 Subnet-B/C への接続に大きな違いはありませんが、リターン トラフィックの設計に違いがあります。図を参照してください。
このアーキテクチャでは、FW に到着するトラフィック (たとえば Subnet-B から Subnet-X へのトラフィック) が iLB に送信され、その後どちらかのファイアウォールに送信されます。 FW 内の内部ルートによって、トラフィックはSubnet-GW (Subnet-D で最初に使用可能な IP) に送り返されます。 トラフィックをゲートウェイ アプライアンス自体に直接送信する必要はありません。これは、Subnet-D の別のルートに、"仮想ネットワーク ゲートウェイ" をポイントしているサブネット X 用のルートがあるためです。 Azure ネットワークによって、実際のルーティングが処理されます。
Subnet-X からのリターン トラフィックは Subnet-D 内の iLB に転送されます。 GatewaySubnet には、Subnet-B-C から iLB をポイントするカスタム ルートもあります。 Subnet-D は iLB を経由しません。 これは、"通常の" VNET 間ルーティングとして扱われます。
図には含まれていませんが、Subnet-B/C/D/Gateway にも、iLB に対して Subnet-A をポイントしているルートが当然含まれています。 この配置により、FW をバイパスする "通常の" VNET ルーティングが回避されます。 これは、Azure のネットワーク スタックに従って、Subnet-A が VNET 内の別のサブネットになっているということです。 Subnet-A は DMZ やインターネットなどとして扱われますが、異なる方法で扱われることはありません。
まとめ
手短に言えば、オンプレミスの (物理/VLAN ベースの) ネットワークで多数の (仮想または物理的) インターフェイスを使用してファイアウォールを扱う方法は、Azure でそれらを扱う方法と同じではありません。 必要であれば (ある程度まで) 前の方法を実行し続けることはできますが、フェールオーバーのダウンタイムを最小限に抑えるためのより優れた方法があります。それは、アクティブ/アクティブ実装と "クリーン" ルーティング テーブルを使用することです。
すべてのトラフィックに対してロード バランサーを "ゲートウェイ" として使用する方法の詳細については、「高可用性ポートの概要」を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Roelf Zomerman | シニア クラウド ソリューション アーキテクト
次のステップ
コンポーネント テクノロジの詳細については、次を参照してください。
関連リソース
次の関連するアーキテクチャを確認してください。