ホワイト ペーパー

ロード バランシング101：ファイアウォール サンドイッチ

Updated May 18, 2010
  • Share via AddThis

はじめに

これまで、ネットワークベースのハードウェア ロード バランサとその最新バージョンであるアプリケーション デリバリ コントローラ（ADC）の主な用途は、特にプレゼンテーション層でバックエンド アプリケーションに高可用性、拡張性、管理性を提供することでした。同様に、ルーターやファイアウォールのような他のネットワーク インフラストラクチャ コンポーネントにも同じメリットを提供します。特に、ADCの背後にファイアウォールを導入することには多くのメリットがあります（他の用途については、ホワイト ペーパー「ロード バランシング101：アプリケーション デリバリ コントローラへの進化」を参照してください）。このホワイト ペーパーでは、ADCを「ファイアウォール サンドイッチ」に実装して、ITインフラストラクチャ全体の可用性、拡張性、管理性を向上させる方法を紹介します。

可用性

ファイアウォールのロード バランシングの主な目的は、ファイアウォールの背後にあるすべてのサービスの高可用性を確保することです。何らかの形で冗長性を提供することで、組織のWebベースのサービスを常に利用可能にすることができます。これは単純なアクティブ/パッシブ ファイアウォール クラスタ ソリューションで簡単に実現できますが、ハードウェアベースのADCを使用すると、同じデバイスでサービスの可用性とフェイルオーバー サービスをサービスごとに可視化できるというメリットがあります。

例えば、プロキシベースのファイアウォールで、SMTPプロセスだけが応答しなくなったとします。アクティブ/パッシブ ファイアウォール クラスタ ソリューションは、通常、このタイプの障害を識別できません。その場合、唯一の解決策はすべての接続をスタンバイ ファイアウォールにフェイルオーバーすることであり、これによって他のサービスで正常に動作していた接続を阻害する可能性があります。ADCは、個々のサービスを監視するだけでなく、他のすべての接続に影響を与えずに、SMTPなどの個々のサービスをセカンダリ ファイアウォールにフェイルオーバーすることも可能です。

拡張性

アクティブ/パッシブ ファイアウォール クラスタ ソリューションには、うまく拡張できないという欠点もあります。1つのファイアウォールの容量を超えたら、増加した負荷を処理できるより大きなファイアウォールに交換するしか選択肢がありません。一方、ADCを使用すると、ファイアウォールを追加するだけで、必要に応じて負荷の増加に対応できます。

ADCのインテリジェンスにより、企業はサービスのニーズに基づいて容量を拡張することもできます。例えば、多くの組織で見られることですが、公開Webサイトのトラフィックが大幅に増加し、ファイアウォールに負担がかかっているとします。すべてのファイアウォールをアップグレードする代わりに、ADCを使用して、サイト構成の他の側面を変更することなく、すべてのWebサイト トラフィックを専用ファイアウォールに移動できます。これにより、公開Webサイトのセキュリティ インフラストラクチャを、組織の他のネットワーク環境のセキュリティ ニーズとは別に独立して拡張し、Webトラフィックが他のビジネスクリティカルなアプリケーションに影響を与えないようにすることができます。

管理性

最後に、ADCを使用すると、ファイアウォールの管理が非常に柔軟になります。さまざまな方法でサービス レベルのトラフィックを迅速かつインテリジェントに転送できるため、メンテナンスの実施（例えば、オフラインで作業する必要があるファイアウォールからトラフィックを誘導するなど）やソフトウェア、ハードウェア、およびポリシーのアップグレード（例えば、ユーザーを新しいシステムに切り替えて、問題が発生した場合は、その問題が解決するまでトラフィックを古いシステムに戻すなど）を行うことができます。また、既存のトラフィックにほとんど影響を与えずに、さまざまなビジネス グループ、イニシアチブ、またはその他のニーズに合わせて、異なるファイアウォール間でトラフィックをセグメント化することもできます。ADCを使用すると、SSL復号も実行できます。これにより、ファイアウォールは暗号化された通信（HTTPSなど）にポリシーを適切に適用できます。トラフィックの復号は、管理者がファイアウォール自体を通過する前または通過した後に、侵入検知システム（IDS）または侵入防止システム（IPS）を介してトラフィックをルーティングすることを選択した場合に役立ちます。

ファイアウォール サンドイッチの基本設計

ファイアウォール サンドイッチという名前は、ロード バランス型ファイアウォールの実装のほとんどに使用されている基本設計を表しています（図1を参照）。ファイアウォール自体がクライアント接続の意図的な宛先になることはほとんどないため、トラフィックはファイアウォールを介してインバウンドとアウトバウンドの両方向で透過的に転送される必要があります。したがって、サンドイッチの具材を挟むパンのように、ファイアウォールの両側にADCデバイスが必要です。

この設計には、注目すべきいくつかの興味深い点があります。まず、インターネット ルーターの外部インターフェイスを除いて、インフラストラクチャ全体がルーティング不可能なIPアドレス空間上に構築されています。これにより、ネットワークへの攻撃がインターネットから発生することは非常に困難になります。

ダイアグラム
図1：ファイアウォール サンドイッチの基本設計

次に、ADCペア#1の仮想サーバーがポート0にあることに注意してください。ポート0は「全ポート」の省略形です（同様に、0.0.0.0は全ネットワークの省略形です）。トラフィックを受信する各ポートに複数の仮想サーバーを設定し、ADCで他のすべてのトラフィックをブロックすることはもちろん可能で、ポート0を使用することにより、新しいサービスを追加するときに必要な設定の量が減ります。また、ファイアウォールの前でトラフィックをブロックするため、ファイアウォール ログ（またはそれに関連付けられたIDS）には、サイトに送信されるトラフィックの全体像が含まれません。ADCペア#2には、ポート80（Webトラフィック）用の特定の仮想サーバーがあります。これは、バックエンドでポート80を実行しているWebサーバーにトラフィックを分散しているためです。ポート0も同じように簡単に使用できますが、すべてのバックエンド サーバーで多数の重複サービスを実行している場合を除いて、一般的にはより使用が制限されます。

最後に、ADCペア#2のゲートウェイ（GW）を見ると、3つのアウトバウンド ファイアウォールすべてにトラフィックを分散するのは、実際にはプール、つまり「リバース仮想サーバー」であることがわかります。これにより、最初の接続後にファイアウォールに障害が発生すると、可用性の高いアウトバウンド ルートが提供されますが、非対称ルーティングで問題が起こる可能性があります（このドキュメント後半の「非対称ルーティング」セクションを参照）。

典型的なトラフィック フロー：インバウンド

典型的なWebサーバーのロード バランシング ソリューションでは、ADCにはクライアント トラフィックの宛先である仮想サーバーがあり、要求を終了させてから、アプリケーションをホストしているサーバーに直接、要求を分散します（ホワイト ペーパー「ロード バランシング101：基本」を参照）。前の図では、192.0.2.5のWebサイト（www.example.com）に関連付けられている有効なインターネットIPアドレスは、技術的にはどのデバイスのどのインターフェイスにも存在しません。では、ユーザーはどのようにしてWebサーバーに接続するのでしょうか？このソリューションには、「ネットワーク」または「ワイルドカード」仮想サーバー、通常の仮想サーバー、そしてちょっとしたルーティングのコツが必要です。トラフィック フローは以下のようになります。

  1. ユーザーがwww.example.comを要求し、192.0.2.5:80に解決されます。
  2. クライアントが最初にWebサイトに要求を送信します。
  3. SYN：192.168.1.1:5000 ? 192.0.2.5:80
  4. example.comは192.0.2.0ネットワークを所有しているため、クライアントのパケットはインターネットを介してルーティングされ、www.example.comのインターネット ルーターに到達します。
  5. ルーター1には、192.0.2.0ネットワークに到達するためのネクスト ホップ ルートが172.16.1.5であり、ADCペア#1の共有外部インターフェイスであることを示すルーティング エントリがあります。
  6. SYN：192.168.1.1:5000 ? 192.0.2.5:80ネクスト ホップ ルーター172.16.1.5
  7. ADCペア#1には、192.0.2.0/24ネットワーク全体を宛先とするトラフィックをリッスンするネットワーク仮想サーバーがあり、アドレス変換を行わないように設定されています。その仮想サーバーは、トラフィックを3つのファイアウォールに分散し、必要に応じてロード バランシングを行い、選択されたファイアウォールに要求をルーティングします。
  8. SYN：192.168.1.1:5000 ? 192.0.2.5:80ネクスト ホップ ルーター172.16.2.10
  9. ファイアウォールには、192.0.2.0ネットワークに到達するためのネクスト ホップが172.16.3.5であり、ADCペア#2の共有外部インターフェイスであるというルートが設定されています。
  10. SYN：192.168.1.1:5000 ? 192.0.2.5:80ネクスト ホップ ルーター172.16.3.5
  11. ADCペア#2には、192.0.2.5:80を宛先とするトラフィックをリッスンする通常の仮想サーバーがあり、接続を受信すると、バックエンド アプリケーション サーバー間で接続のロード バランシングを行います。
  12. SYN：192.168.1.1:5000 ? 192.0.2.5:80が
    SYN：192.168.1.1:5000 ? 172.16.4.11:80になります
  13. ADCペア#2には、172.16.4.0/24ネットワーク上にインターフェイスがあるため、応答するサーバーにパケットを送信するだけです。

典型的なトラフィック フロー：アウトバウンド

アウトバウンド トラフィック フローは、適切なファイアウォールを選択することを除けば、通常の導入とそれほど変わりません。理想的には、元のインバウンド接続が使用したのと同じファイアウォールを使用します（このドキュメントの後半の「実装における潜在的な問題」を参照）。インターネットまでのデフォルト ルートは以下のようになります。

  1. サーバーが要求に応答し、パケットを通常のデフォルト ゲートウェイに送信します。
  2. SYN/ACK：172.16.4.11:80 ? 192.168.1.1:5000デフォルトGW 172.16.4.5
  3. ADCペア#2は、これを負荷分散された接続の応答として認識し、アドレスを書き換えます。
  4. SYN/ACK：172.16.4.11:80 ? 192.168.1.1:5000が
    SYN/ACK：192.0.2.5:80 ? 192.168.1.1:5000になります
  5. ADCペア#2は、パケットを返すために使用するファイアウォールを選択できるようになりました。ここでの決定要因にはさまざまなことが影響しますが、この例では、元のSYNの送信元のファイアウォールにパケットをルーティングして戻します。
  6. SYN/ACK：192.0.2.5:80 ? 192.168.1.1:5000 ?、172.16.3.10経由でルーティング
  7. ファイアウォール1は応答を受信し、デフォルト ルートを介してパケットを転送するだけです。
  8. SYN/ACK：192.0.2.5:80 ? 192.168.1.1:5000 ?、デフォルトGW 172.16.2.5経由でルーティング
  9. ルーター1は、その内部インターフェイスでパケットを受信し、デフォルト ルートを介してインターネットにパケットを転送します。
  10. 最終的に、クライアントが応答を受け取ります。
  11. SYN/ACK：192.0.2.5:80 ? 192.168.1.1:5000

実装における潜在的な問題

この構成には、暗号化されたトラフィックの処理、非対称ルーティングの回避、ファイアウォール インターフェイスの増加に伴う複雑さの管理など、いくつかの潜在的な問題があります。

暗号化されたトラフィック

クライアント接続がHTTPではなくHTTPSの場合、トラフィックはファイアウォールを通過するときに暗号化されたままなので、ファイアウォールはどのようなペイロード検査も実施できません。この問題を簡単に解決するには、ADCペア#2内にアプリケーション ファイアウォールを実装するか、あるいはコンテンツを復号した後、実際のアプリケーションに送信する前にADCにコンテンツをIDS/IPS/WAFに転送させます。これにより、全く同じ構成を使用して、ファイアウォール境界内ですべてのセキュリティに対処できます。

2番目の解決策は、ファイアウォールに渡す前にパケットを復号処理するようにADC #1を設定することです。これを実現する方法はいくつかありますが、復号はファイアウォール境界の外部で行われるため、一般的には推奨されません。

非対称ルーティング

もう1つの一般的な問題は、ファイアウォールを介した非対称ルーティングに関係しています。インバウンド パケットがあるファイアウォールを通過し、戻りパケットが別のファイアウォールを通過する場合に問題が発生します。通常、ステートフル インスペクション ファイアウォールには、接続を開始し、確立された接続に含まれているパケットのみ通過を許可するルールがあります。そのため戻りパケットが別のファイアウォールに送られると、拒否されます。これにはいくつかの解決策があります。

1つ目は、ファイアウォール間で状態を共有できるようにして、すべてのファイアウォールが接続の状態を認識し、アウトバウンド パケットの通過を許可することです。これはすべてのファイアウォールで利用できるわけではなく、魅力的ではありますが、ファイアウォールの数が増えることでパフォーマンスの問題になることがよくあります。さらに、状態を共有することで、ファイアウォールのクラスタ全体が単一デバイスの状態テーブル容量に制限されるため、拡張性を損なう可能性があります。一方で、ファイアウォールに障害が発生した場合、すべての状態情報を再作成しなくても、既存のすべての接続を簡単に移動できます。そのため、他の方法でこの問題を解決しても、多くの組織が状態を共有しています。

非対称ルーティングの一般的な解決策として他に、パーシステンスの使用があります。通常、これは、ADCペア#1が最初に送信したのと同じファイアウォールに常に接続を送信すること、またはADCペア#2が常に同じWebサーバーに接続を送信することを意味します。この場合、ADC #2が（IPまたはメディア アクセス制御［MAC］によって）どのファイアウォールに元の接続を送信したかを記録し、同じファイアウォールに戻りパケットを送り返すことができるようにすることも重要です。本質的に、これは、最初の接続が確立された後、動的ロード バランシングを排除することにより、非対称ルーティングが発生しないようにすることを意味します。

これは通常、2つの方法のいずれかで行われます。1つ目は、HTTPトラフィックでのみ有効な方法ですが、ADCペア#1にHTTP Cookieを埋め込んで、ADCペア#2にトラフィックを返すファイアウォールを指示します。この方法はHTTPでのみ有効であるため（ADCペア#1で暗号化を解除しない限り、HTTPSでも機能しません）、他の選択肢がないADCを除いて、通常は実装されません。

ほとんどのADCベンダーは「ラスト ホップ」または「リバース パーシステンス」機能をサポートしています。この機能により、ADC #2は、元の要求を送ったデバイスのMACアドレスを通知する別の接続状態エントリを作成します。ADC #2は、従来の意味でルーティングするのではなく、トラフィックを受信元のファイアウォールのMACアドレスに転送するだけです。

ダイアグラム
図2：MACによるラストホップの戻りルーティング

元のトラフィック フロー（図2を参照）を見ると、192.0.2.5:80の仮想サーバーに向かうインバウンド トラフィックはADCペア#2で終了します。これが発生すると、ADCペア#2は、その接続を維持するために状態テーブル エントリを作成します。これには通常、低レベルのTCP接続特性と、（パーシステンス設定により）そのトラフィックの受信先として選択されたサーバーのIPが含まれます。ラストホップ機能を使用すると、ADCはパケットの受信元のファイアウォールのMACアドレスも記録します。この場合は、01:23:45:67:89:abです。

選択されたサーバーが応答してトラフィックをADCに送り返すと、ADCは通常のルート ルックアップを実行する代わりに、状態テーブルをチェックして、MACエントリを確認し、（送信元の宛先を仮想サーバーのIPに戻した後）クライアントの宛先IPで指定されたMACアドレスにパケットを転送します。ほとんどのADC実装で、これが自動のデフォルト構成であり、ユーザーの操作は必要ありません。

成長に伴う複雑性

前のセクションの設計はそれほど複雑ではなく、ファイアウォールに「レッグ」、つまりインターフェイスが2つ（外部と内部に1つずつ）しかありません。多くのファイアウォール実装には、それ以上ではないにしても、少なくとも3つあります。この設計を十分に活用するには、トラフィックが両方向に正しくルーティングされるように、各レッグにADCタイプのデバイスが必要です。インターフェイスの数が増えると、これは非常に複雑になり、トラブルシューティングが難しくなります。設計は基本的には同じで、最大で8本のレッグを持つファイアウォール サンドウィッチが正常に導入されていますが、複雑さが潜在的な問題となります。

ファイアウォール障害からの復旧

ファイアウォールに障害が発生するとどうなるでしょうか？もちろん、最初のクライアント接続の前にファイアウォールに障害が発生した場合には、ADCはクライアント接続を機能しているファイアウォールにリダイレクトするだけです。この設計では、これをサービス単位で実行できることを忘れないでください。ファイアウォールがSMTPトラフィックを処理できないが、HTTPを処理できる場合、ADCは引き続きHTTPトランザクションをそのファイアウォールに送信しますが、SMTPトラフィックは他のファイアウォールに送信します。潜在的な問題を引き起こす障害には、1）インバウンド パケットを通過させた後、戻りパケットを通過させる前にファイアウォールに障害が発生した場合と、2）完全な接続が確立されて使用された後、ファイアウォールに障害が発生した場合の2つがあります。

前者の場合、問題は、ADCペア#2が既に機能していない元のファイアウォールにトラフィックを送り返そうとすることです。幸い、このシナリオでは、クライアント接続がタイムアウトになり、クライアントは接続要求の再送信を試みます。接続要求は、今度はインバウンド要求で機能しているファイアウォールを通過するため、ユーザーにほとんど何も影響を与えることなく問題は解決されます。

後者の場合は、実際にはクライアント エクスペリエンスに大きな影響を与えます。接続が機能しているファイアウォールに確実に送られるようにすることにも、同じ問題が関係しています。ただし、ここでは方向（インバウンドか、アウトバウンドか）に関係なく、パケットは、これまで接続を確認していないファイアウォールに行き着くことになります。ファイアウォール間で状態の共有が実装されていない限り、接続は失敗し、クライアントは再接続してセッションを最初からやり直すことになります。このシナリオの良い点は、これは実際には長命のTCP接続にのみ影響し、その場合でも、ユーザーが再接続すると、サービスに再び接続されることです。FTPは影響を受けますが、HTTP v1.0はほとんど影響を受けません。

興味深いことに、フルプロキシ接続（クライアントとサーバーへの独立した接続）を実装するADCには、少なくともクライアントの観点から、こうした障害も軽減できる解決策があります。例えば、クライアント接続がADCペア#1で終了し、このペアがサービスへの独自の接続を確立する状況を考えてみます。ファイアウォールに障害が発生し、接続を再開する必要がある場合、再起動が必要なのはADCペア#1とサーバーの間の接続であり、必ずしもクライアントからの接続である必要はありません。これにはいくつかの標準外の設定が必要であり、個々のプロトコルに依存しますが、この解決策はファイアウォールの障害をクライアントから簡単に隠すことができます。

この解決策全体の本当のメリットの1つは、問題のファイアウォールがサービスに戻されると、すぐに新しい接続に使用できるようになり、ユーザーへのさらなる影響がないことです。

まとめ

このドキュメントで紹介した構成は、考えられる数百もの導入オプションのうち最も単純な例ですが、アプリケーション デリバリ コントローラの背後にファイアウォールを導入することのメリットを示すには十分です。導入は、最終的には、組織の特有のニーズと既存のインフラストラクチャ、そして取得、運用、管理コストをどのように評価するかで決まります。

ファイアウォール サンドイッチのこの基本概念は、SSLアクセラレータ、IDS/IPS、ルーターやプロキシ サーバーなど、ステートフルかどうかに関係なく、多くの透過型および半透過型デバイス、つまりより優れた可用性、拡張性、管理性を必要とするあらゆるインライン デバイス全体のトラフィックを管理するために使用できます。