VulcanManager

VulcanAppMix

Vulcanは、一例として次世代ファイアウォール（NGFW）の導入の際のパフォーマンステストに最適なソリューションを提供します。Vulcanを用いた包括的な試験によって、システムの信頼性・可用性の検証を行うことが可能です。

NGFW 機器のパフォーマンステストにおける注意点

実環境のアプリケーション・トラフィックを用いて NGFWを検証する場合、アプリケーショントラフィックを用いるだけでは無く、ユーザ毎に個別に発生する通信のトラフィックのエミュレーションを、どの様に実施するかが重要となります。

何故ならば、実環境に於けるユーザトラフィックの発生はランダムで有り、一定間隔で発生する事は有りません。

もしテストトラフィックが一定の接続数/秒（CPS）で生じる様な場合、NGFW はそのパターンを機械学習によって検出し、その接続の確立をブロックします。すると下図に示すように NGFW を通過するトラフィックは無くなり、パフォーマンス検証を行う事が出来ません。
即ちテストプラットフォームはNGFWに対して、実環境に則したトラフィックパターンを提供する必要が有ります。

VulcanAppMixによってこのようなエミュレートが可能となります。

スループット&キャパシティ検証

パフォーマンス検証に加え、NGFWの基本性能を測る事は、そのNGFWが与えられた環境下での使用に耐えうるか、否かを判断する上で必要となります。

スループット評価

ファイアウォールは全てのインバウンドとアウトバウンドのトラフィックを処理する為、スループットの検証を行うことが重要です。

NGFWの実際のパケット処理能力を検証するには、さまざまなサイズの UDP パケットを使用する必要があります。これにはVulcanの2つのテストポート間にNGFWを挿入し、複数の送信元および宛先IPアドレスを持つ固定長のパケットストリームを双方向に印加する必要があります。

この際、 UDPパケットは有効なサブネットを持ったIPアドレス及びポート番号を持ち、ペイロードにはダミーデータを包含します。

本検証はNGFWのパケット処理能力を測定し、QoSの処理能力に拘わるパケット転送エンジンの性能値を確認する事を目的としています。

本検証は以下の各パケットサイズを用い、パケットロスのない最高スループットを測定します。

• 64 Byte
• 128 Byte
• 256 Byte
• 512 Byte
• 1024 Byte
• 1514 Byte

最大コネクション数

ファイアウォールはTCPコネクションの状態をメモリのステートテーフルに保持するステートフルデバイスです。メモリは有限であるため、NGFW の維持できるTCPセッション数には限りが有ります。

よってTCP最大同時接続数の検証によって、NGFW性能の一部を確認する事が出来ます。

また、接続数/秒(CPS)を計測し、接続確立率の検証を行う必要も有ります。この値は、アプリケーションのQoSに強く影響を与える為、有効な検証となります。

• TCP 最大同時接続数（CC）

下図に示される検証では、アプリケーショントラフィックが存在しない状態でのTCP 最大同時接続数を測定しています。

実際にはこのようなトラフィックはほとんど見られませんが、NGFWのパフォーマンスを測る上で有効な検証項目となります。

各コネクションは、TCP 3ウェイハンドシェイク（SYN-SYN, ACK-ACK）で確立され、接続数が増えても維持される事が期待されます。コネクション数はそれ以上確立が出来なくなる迄、試行を続けます。



• データ転送を含む TCP 最大同時接続数（CC）

前出の試験に基づき、下図の検証では、TCPコネクションが確立された後にアプリケーショントラフィックを重畳してデータ伝送を行います。例として21 KB のアプリケーションデータ送信する場合、データを複数のTCPパケットに分割、送信して一つのTCPコネクション内でデータを転送できることを確認します。



• TCP 最大接続数/秒（CPS）

最大CPSは、TCP同時接続要求に対するNGFWの処理能力を決定します。実際にはこのようなトラフィックはほとんど見られませんが、NGFWのパフォーマンスを測る上で有効な検証項目となります。

TCPコネクション確立後1バイトのデータを送信した後、直ちにそのコネクションを解放します。その後、確立数を増加させながら、試行を続けます。NGFWが設定した立ち上がり時間内に新規接続の確立が出来なくなる迄、試行を続けます。



• HTTP 最大接続数/秒（CPS）

NGFW はアプリケーションアウェアの為、TCPのペイロードを検査します。本検証では、 1バイトの HTTP 応答を用いた場合の NGFWの最高HTTPセッションレートを測定します。これは、秒間辺りの理論上の最高値を測定します。

クライアントとサーバーは、キープアライブなしでHTTP 1.1以上を使用します。以下の図に示すように、クライアントは TCP コネクションを確立した後、1つのHTTPリクエストを送信し、直ちにコネクションの解放処理を開始します。サーバーはクライアントからのリクエストを受信すると同時に、1バイトのHTTPレスポンスを送信します。

これは、リクエストが送信された時点でTCP コネクションが直ちに解放される事となります。ここでTCP コネクションが同時に発生した場合は NGFWにより遅延が発生したと考えられます。

NGFWが新規TCP コネクションの確立をできなくなるまで、コネクション数を増やしながら試行を続けます。



• HTTP 最大トランザクション/秒（TPS）

本検証では、HTTP 応答を用いた場合の NGFW の最高 HTTP 処理レートを測定します。

クライアントとサーバーは、キープアライブなしで HTTP 1.1 以上を使用します。以下の図に示すように、クライアントは 1 つのTCP コネクションを開き、 複数個の HTTP リクエストを送信した後、直ちにコネクションの解放処理を開始します。サーバーはクライアントからのリクエストを受信すると同時に、1 バイトの HTTP レスポンスを送信します。

これにより、複数回に及ぶ HTTP トランザクションがすべて終了するまで TCP コネクションが開いたままになります。

この処理は1 つの TCP コネクションに複数個の HTTP トランザクションが含まれるため、前述の試験に存在し得たTCP CPS が起因のボトルネックを解消することができます。

NGFW が新規 TCP コネクションの確立を処理できなくなるまで、HTTP リクエスト数を増やしながら試行を続けます。

HTTP キャパシティテスト

このテストでは、NGFWにパケットサイズやCPSを変え、HTTP エンジンに負荷を与えた際、ネットワークトラフィックにどのような影響を与えるかを検証します。

ステートフルTCPの確立は、NGFWメモリ内のテーブルを監視することを意味し、ステートレスのトラフィックに比してNGFWの負荷は高くなります。

本検証の目的は、実環境に近いテスト環境を提供することです。

各 HTTP トランザクションでは、クライアントから1 つの HTTP GET リクエストパケットが送信され、サーバーはリクエストパケット受信後、直ちにHTTP レスポンスパケットを送信します。各パケットのペイロードには、様々な負荷を想定したバイナリとASCII 文字組み合わせたデータが包含しています。

本検証は、下表のように、CPSとレスポンスサイズが異なる条件を用いて実施する必要があります。

SSL/TLS パススルー スループットテスト

NGFWの本領を発揮させる為に、SSL/TLS トラフィックをNGFWの前段で復号化することが強く推奨されています。しかしながら、企業や組織ではポリシーの問題から復号化することは通常ありません。したがって、NGFWはコンテンツ検査のために暗号化トンネルを終了させることなく、SSL/TLS トラフィックを通過させなければなりません。

しかし、NGFWベンダーによってはSSL/TLS トラフィックのパススルー性能は大きく異なります。

TCPペイロードにSSL/TLS トラフィックが存在すると、NGFWのリソースが影響を受ける場合が有ります。これはいくつかの NGFWがSSL/TLSトラフィックの処理を非暗号化トラフィックとは異なる手法で実装していることを意味します。

したがって、NGFWの正確な性能を検証するためには、実環境で暗号化された様々なアプリケーショントラフィックを使用することが重要となります。