アプリケーション プロファイルは、アプリケーション タイプに基づいて仮想サービスの動作を決定します。
アプリケーション プロファイルのタイプとそのオプションについて、後続のセクションで説明します。
TCP/UDP プロファイルへの依存関係
仮想サービスに関連付けられているアプリケーション プロファイルは、基盤となる TCP/UDP プロファイルに依存していることがあります。たとえば、HTTP アプリケーション プロファイルは、仮想サービスで使用される TCP/UDP プロファイル タイプが [TCP プロキシ] タイプに設定されている場合にのみ使用できます。仮想サービスに関連付けられたアプリケーション プロファイルは、サービスのアプリケーション プロトコル（HTTP など）をプロキシし、そのプロトコルに適した機能を実行するようにサービス エンジン (SE) に指示します。
NSX Advanced Load Balancer のアプリケーション プロファイル
NSX Advanced Load Balancer でアプリケーション プロファイルを表示するには、 の順に移動します。
NSX Advanced Load Balancer には、作成したアプリケーション プロファイルとそのタイプがすべて次のように表示されます。
この画面では、次の機能が実行できます。
[検索] アイコンをクリックして、アプリケーション プロファイルの名前を入力することによる検索を開始する。
新しいアプリケーション プロファイルを作成する。
アプリケーション プロファイルの [編集] アイコンをクリックして構成を変更する。
既存のアプリケーション プロファイルが仮想サービスに割り当てられていなければ削除する。
プロファイルが仮想サービスに関連付けられている場合は、プロファイルを削除できません。この場合、エラー メッセージに、アプリケーション プロファイルを参照している仮想サービスが一覧表示されます。システム標準プロファイル（以下の図に示す）のいずれも削除できません。
アプリケーション プロファイルの作成/編集
[作成] をクリックし、処理するトラフィックに応じて、アプリケーション プロファイルのタイプをドロップダウン メニューから選択します。
- DNS
-
DNS トラフィック処理のデフォルトです。
- HTTP
-
レイヤー 7 HTTP トラフィック処理のデフォルトです。
- L4
-
仮想サービスでアプリケーション固有のプロファイルを使用していない場合のキャッチオールです。
- L4 SSL/TLS
-
仮想サービスが SSL 暗号化されていてアプリケーション固有のプロファイルを使用していない場合のキャッチオールです。
- SIP
-
SIP トラフィック処理のデフォルトです。
- Syslog
-
Syslog トラフィック処理のデフォルトです。
アプリケーション プロファイルの構成を [新規アプリケーション プロファイル] 画面で行います。
選択したアプリケーション プロファイルに関係なく、[新規アプリケーション プロファイル] 画面と [アプリケーション プロファイルの編集] 画面とで同じインターフェイスが共有されます。
HTTP プロファイル
HTTP アプリケーション プロファイルでは、NSX Advanced Load Balancer をいずれかの HTTP トラフィックのプロキシにすることができます。リダイレクト、コンテンツの切り替え、クライアント要求へのサーバ応答の書き換えなど、HTTP 固有の機能が仮想サービスに適用される場合があります。この設定は、HTTP プロファイルに関連付けられているすべての HTTP サービスに適用されます。HTTP 固有のポリシーまたは DataScript は、仮想サービスに直接添付することもできます。
最大ヘッダー数
max_header_count ノブでは、HTTP 要求と応答のヘッダーの合計数を定義します。max_header_count のデフォルト値は 64、値の範囲は 0 ～ 4,096 です。ヘッダーの数が指定の値を超えると、次に示すように、重要なアプリケーション ログを含む HTTP 要求が NSX Advanced Load Balancer で拒否されます。
NSX Advanced Load Balancer コントローラにログインし、次に示すように、アプリケーション プロファイル
System-HTTP を configure applicationprofile モードで使用して最大ヘッダー数の値を設定します。
[admin:ctrl]: > configure applicationprofile System-HTTP [admin:ctrl]: applicationprofile> http_profile [admin:ctrl]: applicationprofile:http_profile> max_header_count [admin:ctrl]: applicationprofile:http_profile> max_header_count 256 Overwriting the previously entered value for max_header_count [admin:ctrl]: applicationprofile:http_profile> save [admin:ctrl]: applicationprofile> save
[最大ヘッダー数] オプションを NSX Advanced Load Balancer ユーザー インターフェイスで有効化するには、 の順に移動し、[クライアントの最大ヘッダー数] の値を入力します。
X-Accel ヘッダーのパススルー
NSX Advanced Load Balancer では、クライアントに送信する HTTP 応答に X-Accel ヘッダーを渡すことがサポートされています。ここでのヘッダーには次のようなものがあります。
X-Accel-Expires
X-Accel-Redirect
X-Accel-Limit-Rate
X-Accel-Buffering
X-Accel-Charset
HTTP アプリケーション プロファイルでは新しい構成ノブ、pass_through_x_accel_headers をサポートします。デフォルトでは、このフィールドは False に設定されています。つまり、NSX Advanced Load Balancer ではクライアントに送信する HTTP 応答に X-Accel ヘッダーを渡しません。True に設定した場合、NSX Advanced Load Balancer ではクライアントに送信する HTTP 応答に X-Accel ヘッダーを渡します。
X-Accel-Buffering の付いたオブジェクトがキャッシュされ、ユーザーがその構成を変更する場合、それはそのユーザーがキャッシュをクリアして有効にすることを想定したものです。
X-Accel ヘッダーのパススルーを有効化するには、次に記載する構成手順に従います。
[admin:ctrl]: > configure applicationprofile System-HTTP [admin:ctrl]: applicationprofile> http_profile [admin:ctrl]: applicationprofile:http_profile> pass_through_x_accel_headers Overwriting the previously entered value for pass_through_x_accel_headers [admin:ctrl]: applicationprofile:http_profile> save [admin:ctrl]: applicationprofile> save
全般構成
- [接続の多重化]
-
このオプションは、HTTP 1.0 および 1.1 要求の切り替えとサーバ TCP 接続の再利用の動作を制御します。これにより、NSX Advanced Load Balancer はサーバが維持する開いている接続の数を減らし、アイドル状態のサーバ間で要求をより適切に分散できるため、サーバの過負荷を軽減し、エンドユーザーのパフォーマンスを向上させることができます。サーバへの接続の正確な削減は、クライアント接続の存続期間、HTTP バージョン、および要求/応答が接続を利用する頻度によって異なります。「接続」は TCP 接続を指し、「要求」は HTTP 要求とその後の応答を意味することを理解することが重要です。HTTP 1.0 および 1.1 では、一度に 1 つの要求/応答のみが開いている TCP 接続を通過できます。このボトルネックについては、宛先 Web サイトへの TCP 接続を同時に 6 つほど開くことで軽減しようとするブラウザが多いのです。
- [WebSocket プロキシ]
-
WebSocket を有効にすると、仮想サービスはクライアントのアップグレード ヘッダー要求を受け入れます。サーバが WebSocket を待機している場合、クライアントとサーバ間の接続がアップグレードされます。WebSocket は全二重 TCP プロトコルです。接続は最初は HTTP 経由で開始されますが、正常にアップグレードされると、NSX Advanced Load Balancer によるすべての HTTP 解析が停止し、接続は通常の TCP 接続として扱われます。
注：NSX Advanced Load Balancer では HTTP/2 WebSocket をサポートします。NSX Advanced Load Balancer バージョン 22.1.3 以降では、WebSocket クライアントとサーバが同じ HTTP バージョンであればサポートするのに加え、HTTPv2 の WebSocket クライアントと HTTPv1 のサーバの組み合わせもサポートします。
- [X-Forwarded-For]
-
このオプションを使用すると、NSX Advanced Load Balancer は、要求がサーバに渡されるときに、X-Forwarded-For (XFF) ヘッダーを HTTP 要求ヘッダーに挿入します。XFF ヘッダーの値には、元のクライアントの送信元 IP アドレスが含まれています。Web サーバは、サービス エンジンの送信元 NAT アドレスを誤って反映するレイヤー 3 IP アドレスを使用する代わりに、このヘッダーを使用してクライアントの操作をログに記録できます。このオプションを有効化すると、[XFF の代替名] フィールドが表示され、XFF ヘッダーの挿入でカスタム HTTP ヘッダー名を使用できるようになります。指定された XFF ヘッダーまたはカスタム名がクライアント要求にすでに存在する場合、そのヘッダーのすべてのインスタンスが最初に削除されます。既存のインスタンスを削除せずにヘッダーを追加するには、HTTP 要求ポリシーを使用します。
要求に含まれる X-Forwarded-For ヘッダーを 1 つ以上保持するため、NSX Advanced Load Balancer 22.1.3 以降では、[X-Forwarded-For] を有効化すると、[XFF ヘッダー処理] のオプションが使用できます。
[XFF ヘッダーの置き換え] を選択すると、次の例に示すように、すべての受信 X-Forward-For ヘッダーを、NSX Advanced Load Balancer で作成したヘッダーに置き換えます。
[XFF ヘッダーの付加] を選択すると、次の例に示すように、すべての受信 XFF ヘッダーと一緒にクライアント IP アドレスを付加します。
[新しい XFF ヘッダーの追加] を選択すると、次の例に示すように、新しい XFF ヘッダーと、クライアント IP アドレスを追加します。
[アプリケーション プロファイル] 画面は、次のように表示されます。
- [クライアント IP アドレスの保存]
-
このオプションをクリックすると、NSX Advanced Load Balancer SE は、SE からバックエンド アプリケーション サーバへのロード バランシングされた接続の送信元 IP アドレスとして、独自の IP アドレスではなくクライアント IP アドレスを使用します。このオプションを有効にするには、SE グループで IP ルーティングを有効にすることが前提条件です。クライアント IP アドレスの保持は、仮想サービスの SNAT と相互に排他的です。HTTP(s) アプリケーション プロファイルからの接続多重化は、クライアント IP アドレスの保持で使用できません。
- [保存]
-
トップ メニューで別のタブを選択して編集を続行するか、[保存] を選択して [アプリケーション プロファイル] タブに戻ります。
多重化とパーシステンス
次の表に、パーシステンスに応じた多重化動作の相違を示します。
多重化 |
パーシステンス |
動作 |
|---|---|---|
有効 |
無効 |
クライアント接続とその要求は、サービス エンジンのサーバ側から分離されます。 要求は、サーバへの新しい接続または既存の接続を使用して、プール内のこれらのサーバ間でロード バランシングされます。 サーバへの接続は、どのクライアントからの要求でも共有できます。 |
有効 |
有効 |
クライアント接続とその要求は、単一サーバに送信されます。 これらの要求は、同じサーバに保持されている他のクライアントと接続を共有する場合があります。 HTTP 要求のロード バランシングはありません。 |
無効 |
有効 |
NSX Advanced Load Balancer では、クライアントから受信した接続ごとに、サーバへの新しい TCP 接続を開きます。 接続は他のクライアントと共有されません。 同じクライアントからのすべての接続を介して受信したすべての要求は、1 台のサーバに送信されます。 HTTP クライアント ブラウザは多数の同時接続を開く場合があり、クライアント接続の数はサーバ接続の数と同じになります。 |
無効 |
無効 |
クライアントとサーバ間の接続は 1 対 1 です。 要求は、開始したのと同じ接続に残ります。 同じクライアントからの複数の接続が、使用可能なサーバ間で分散される場合があります。 |
セキュリティ構成
HTTP アプリケーション プロファイルの [セキュリティ] タブでは、プロファイルに関連付けられている HTTP アプリケーションのセキュリティ構成を制御します。.
[セキュリティ情報]
HTTP セキュリティ構成は、仮想サービスで HTTPS がどのように処理されなければならないかに影響します。仮想サービスが HTTP 専用に構成されている場合、このセクションで説明する HTTPS 構成は適用されません。仮想サービスが HTTPS、または HTTP と HTTPS 用に構成されている場合にのみ、これらの設定が有効になります。
ポリシーまたは DataScript を使用して、よりきめ細かい設定を構成することもできます。
フィールド |
説明 |
|---|---|
[常時 SSL] |
このオプションで、次のすべてのオプションが有効になります。これにより、HTTPS トラフィックに推奨されるセキュリティが提供されます。 |
[HTTP から HTTPS へのリダイレクト] |
HTTP サービス ポート（SSL 無効）と HTTPS サービス ポート（SSL 有効）の両方で構成された単一の仮想サービスの場合、この機能はクライアントを安全でないポートから安全なポートに自動的にリダイレクトします。たとえば、ブラウザに www.avinetworks.com と入力したクライアントは、自動的に https://www.avinetworks.com にリダイレクトされます。仮想サービスに HTTP と HTTPS の両方のサービス ポートが構成されていない場合、この機能は有効になりません。2 つの仮想サービス（1 つは HTTP を使用し、もう 1 つは HTTPS を待機する同じ IP アドレス上にある）の場合は、プロトコルとポートを手動でリダイレクトする HTTP 要求ポリシーを作成する必要があります。 |
[Secure Cookies] |
NSX Advanced Load Balancer が仮想サービスのプール内のバックエンド サーバの SSL プロキシとして機能している場合、NSX Advanced Load Balancer は SSL 経由でクライアントと通信します。ただし、NSX Advanced Load Balancer が（SSL 経由ではなく）HTTP 経由でバックエンド サーバと通信すると、サーバは誤って HTTP として応答を返します。その結果、Secure とマークされなければならない Cookie がそのようにマークされません。Secure Cookies を有効にすると、サーバの Cookie に Secure フラグが付きます。これにより、クライアントはこの Cookie のみを HTTPS 経由で仮想サービスに送信するように指示します。この機能は、SSL/TLS ターミネーションが有効になっている仮想サービスに適用された場合にのみ有効になります。 |
[HTTP Strict Transport Security (HSTS)] |
Strict Transport Security では、ヘッダーを使用して、このサイトへのアクセスは SSL/TLS 経由でのみ行う必要があることをクライアント ブラウザに通知します。HSTS ヘッダーは、エラー応答を含むすべての HTTP 応答で送信されます。この機能は、クライアントの安全な SSL/TLS セッションが安全でない HTTP を介して接続することを強制する中間者攻撃を軽減します。HSTS には、SSL/TLS 設定を指定の日数の間有効にしておく必要があることをクライアントに通知する期間設定があります。 必要に応じて、[サブドメインを含める] ディレクティブを HTTP Strict-Transport-Security ヘッダーに挿入します。このディレクティブを挿入すると、HSTS ポリシーが、この HSTS ホストに、またホストのドメイン名のサブドメインがあればそこにも適用されることが、ユーザー エージェントに通知されます。この設定は、SSL/TLS を終了するように構成された仮想サービスでのみ有効になります。
注：
仮想サービスが SSL/TLS をサポートするように一時的に設定され、HSTS が設定されている場合、HTTP にグレースフルにダウングレードすることはできません。クライアント ブラウザは、HTTP 経由でサイトを受け入れることを拒否します。HSTS が有効な場合、クライアントは自己署名証明書を受け入れません。 |
[HttpOnly Cookie] |
NSX Advanced Load Balancer では、コントローラによって生成された Cookie に Cookie に HTTP-Only 属性を有効化する CLI コマンドについて確認するには、「HTTP-Only フラグを有効化する CLI コマンド」を参照してください。 |
[サーバのリダイレクトを HTTPS に書き換え] |
仮想サービスがクライアント SSL/TLS を終了し、HTTP としてサーバに要求を渡すと、多くのサーバはクライアントへの接続が HTTP であると見なします。そのため、サーバによって生成される絶対リダイレクトには、http://www.avinetworks.com などのプロトコルが含まれる場合があります。サーバが location ヘッダーに HTTP を含むリダイレクトを返す場合、この機能はそれを HTTPS に書き換えます。また、サーバが IP アドレスのリダイレクトを返した場合は、クライアントによって要求されたホスト名に書き換えられます。サーバがクライアントによって要求された以外のホスト名のリダイレクトを返す場合、それらは変更されません。
注：
リダイレクトの書き換え時によりきめ細かな設定が必要な場合は、HTTP 応答ポリシーの作成を検討してください。この機能は、仮想サービスに HTTP と HTTPS の両方のサービス ポートがある場合にのみ有効になります。 |
[X-Forwarded-Proto] |
このオプションを有効にすると、NSX Advanced Load Balancer は、サーバに送信される HTTP 要求に X-Forwarded-Proto ヘッダーを挿入します。これにより、クライアントが HTTP または HTTPS を介して NSX Advanced Load Balancer に接続したかどうかがサーバに通知されます。この機能は、任意の HTTP または HTTPS 仮想サービスで有効になります。 |
HTTP-Only フラグを有効化する CLI コマンド
[admin:admin-controller2]: > configure applicationpersistenceprofile System-Persistence-Http-Cookie[admin:admin-controller2]: applicationpersistenceprofile> http_cookie_persistence_profile [admin:admin-controller2]: applicationpersistenceprofile:http_cookie_persistence_profile> http_only [admin:admin-controller2]: applicationpersistenceprofile:http_cookie_persistence_profile> save [admin:admin-controller2]: applicationpersistenceprofile> save
+-------------------------------|---------------------------------------+ |Field |Description | +-------------------------------+---------------------------------------+ |uuid |applicationpersistenceprofile-04ca34e1 | |name |System-Persistence-Http-Cookie | |persistence_type |PERSISTENCE_TYPE_HTTP_COOKIE | |server_hm_down_recovery |HM_DOWN_PICK_NEW_SERVER | |http_cookie_persistence_profile| | | cookie_name |VAJOSFML | | key[1] | | | name |40015eba-ee51-40c6-8f8d-06e2ec0516e9 | | aes_key |b'WX9pow2nYKYTfENMZSdwODZQu8e37Zdraoovt| | always_send_cookie |False | | http_only |True | | is_federated |False | | tenant_ref |admin | +-------------------------------+---------------------------------------+
HTTP から HTTPS へのリダイレクト
セキュリティを確保するため、業界のベスト プラクティスは、すべての HTTP トラフィックが HTTPS として SSL 暗号化されているようにすることです。通常のエンドユーザーは、要求で URL を入力するときに HTTPS プロトコルを指定しないため、最初の要求は HTTP 経由で到着します。SSL 終端サービスを提供できる NSX Advanced Load Balancer では、HTTP ユーザーによる HTTPS へのリダイレクトも処理する必要があります。HTTP から HTTPS へのリダイレクトは、次のいずれかの方法で有効化できます。
[アプリケーション プロファイル] の [セキュリティ] 構成
[アプリケーション プロファイル] で [HTTP から HTTPS へのリダイレクト] を構成
アプリケーション プロファイルで [サーバのリダイレクトを HTTPS に書き換え] を構成
HTTP 要求ポリシーを使用
アプリケーション プロファイルで [HTTP から HTTPS へのリダイレクト] を構成
仮想サービスが HTTP（通常はポート 80）と HTTPS（通常は SSL の ポート 443）の両方に構成されている場合は、アタッチされている HTTP アプリケーション プロファイルを使用して HTTP から HTTPS へのリダイレクトを有効化します。
の順に移動し、目的の仮想サービスを選択して、右側の [編集] アイコンをクリックします。
[設定] で、[プロファイル] セクションに移動します。
[System-HTTP] プロファイルを選択し、[編集] アイコンをクリックします。
[セキュリティ] で [HTTP から HTTPS へのリダイレクト] を選択します。
[保存] をクリックします。
[System-Secure-HTTP] プロファイルは、[System-HTTP] プロファイルと似ていますが、[常時 SSL] では [HTTP から HTTPS へのリダイレクト] オプションがデフォルトで有効になっています。
アプリケーション プロファイルで [サーバのリダイレクトを HTTPS に書き換え] を構成
[サーバのリダイレクトを HTTPS に書き換え] オプションは、[アプリケーション プロファイル] の [セキュリティ] タブ内にあります。このオプションでは、リダイレクトの Location ヘッダーを HTTP から HTTPS に変更し、また、ハードコードされたポートがあれば削除します。
相対リダイレクトは変更されず、絶対リダイレクトのみ変更されます。 したがって、両方のオプションを有効化しておくことをお勧めします。
このプロファイル設定は、HTTPS が構成されていない仮想サービスには影響しません。
次の例は、サーバから送信される Location ヘッダーを示すものです。
http://www.test.com:5000/index.htm
NSX Advanced Load Balancer で Location ヘッダーを書き換え、次の URL をクライアントに送信します。
https://www.test.com/index.htm
HTTP 要求ポリシーを使用
よりきめ細かに行うには、HTTP 要求ポリシーを使用します。
の順に移動し、目的の仮想サービスを選択して、右側の [編集] アイコンをクリックします。
[ポリシー] タブで、[HTTP 要求] を選択します。
[作成] (+) アイコンをクリックします。
サービス ポート を [一致ルール] のドロップダウン リストから選択して、[ポート] フィールドに 80 と入力します。
ルールを保存します。オプションで、必要な条件を追加して、リダイレクトを実行するタイミングを決定します。
[アクション] セクションで、[リダイレクト] をドロップダウン メニューから選択します。続いて、プロトコルを HTTPS に設定します。これにより、リダイレクト ポートが 443 に、リダイレクト応答コードが 302（一時的なリダイレクト）に設定されます。
HTTP 要求ポリシーのセットアップはすぐ簡単に行えて、影響するのは一度に 1 つの仮想サービスのみです。
クエリを追加
リダイレクト アクションを HTTP 要求ポリシーに追加するには、[add_string] を使用します。
[keep_query] フィールドが有効化されている場合、最終リダイレクト URI に対しては受信要求のクエリ パラメータが使用されます。
[add_string] フィールドは、クエリ文字列をリダイレクト URI に付加するものです。
keep_query と add_string がどのように機能しているかを把握するには、http://test.example.com/images?name=animals を受信要求のサンプルとして、要求が http://google.com にリダイレクトされると考えてください。
|
|
リダイレクト リンク |
|---|---|---|
有効 |
未構成 |
http://google.com/images?name=animals |
無効 |
未構成 |
http://google.com/images?name=animals |
有効 |
「 |
http://google.com/images?name=animals&type=cats&color=black |
無効 |
「 |
http://google.com/images?name=animals&type=cats&color=black |
CLI 構成は次のとおりです。
[admin:abc-controller]: > configure httppolicyset vs1-Default-Cloud-HTTP-Policy-Set-0 [admin:abc-controller]: httppolicyset> http_request_policy [admin:abc-controller]: httppolicyset:http_request_policy> [admin:abc-controller]: httppolicyset:http_request_policy> rules index 1 [admin:abc-controller]: httppolicyset:http_request_policy:rules>[admin:abc-controller]: httppolicyset:http_request_policy:rules> redirect_action [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action> [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action> add_string images=cat keep_query [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action> status_code http_redirect_status_code_302 [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action> port 80 [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action> host [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action:host> type uri_param_type_tokenized [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action:host> tokens [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action:host:tokens> type uri_token_type_string str_value www.google.com [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action:host> save [admin:abc-controller]: httppolicyset:http_request_policy:rules:redirect_action> save [admin:abc-controller]: httppolicyset:http_request_policy:rules> save [admin:abc-controller]: httppolicyset:http_request_policy> save [admin:abc-controller]: httppolicyset> save +------------------------+----------------------------------------------+ | Field | Value | +------------------------+----------------------------------------------+ | uuid | httppolicyset-2ee5<truncated> | | | | | name | vs1-Default-Cloud-HTTP-Policy-Set-0 | | http_request_policy | | | rules[1] | | | name | Rule 1 | | index | 1 | | enable | True | | match | | | method | | | match_criteria | IS_IN | | methods[1] | HTTP_METHOD_GET | | redirect_action | | | protocol | HTTP | | host | | | type | URI_PARAM_TYPE_TOKENIZED | | tokens[1] | | | type | URI_TOKEN_TYPE_STRING | | str_value | www.vmware.com | | tokens[2] | | | type | URI_TOKEN_TYPE_STRING | | str_value | www.google.com | | port | 80 | | keep_query | True | | status_code | HTTP_REDIRECT_STATUS_CODE_302 | | add_string | images=cat | | is_internal_policy | False | | tenant_ref | admin | +------------------------+----------------------------------------------+
DataScript を使用したリダイレクト
粒度と再利用性を最大限に高めるには、DataScript を使用してリダイレクト動作を構成します。
DataScript を追加するには、次手順を実行します。
の順に移動し、目的の仮想サービスを選択して、編集オプションをクリックします。
の順に移動します。
[DataScript の追加] をクリックします。
[実行するスクリプト] をクリックします。
[DataScript の作成] をクリックします。
[新しい DataScript セット] 画面の [イベント] で、[追加] をクリックします。
[追加] ドロップダウン メニューで、[HTTP 要求] を選択します。
[HTTP 要求イベント スクリプト] テキスト ボックスに、次のスクリプトを入力して保存します。
if avi.vs.port() ~= "443" then avi.http.redirect("https://" .. avi.http.hostname() .. avi.http.get_uri()) end
クライアント SSL 証明書の検証
NSX Advanced Load Balancer では、信頼できる認証局 (CA) と構成済みの証明書失効リスト (CRL) と比較対照して、クライアントが提示する SSL 証明書を検証することができます。さらにオプションを使用すると、HTTP ヘッダーを介して証明書情報をサーバに渡すことができるようになります。
フィールド |
説明 |
|---|---|
[検証タイプ] |
SSL 証明書に基づいてクライアント検証を有効にします。次のいずれかを選択します。
|
[PKI プロファイル] |
公開鍵基盤 (PKI) プロファイルには、構成済みの認証局 (CA) と CRL が含まれています。検証が 要求 に設定されている場合、PKI プロファイルは必要ありませんが、検証が 必須 に設定されている場合は必須です。 |
[HTTP ヘッダー名] |
オプションで、NSX Advanced Load Balancer はクライアントの証明書またはその一部をサーバに送信する新しい HTTP ヘッダーに挿入できます。ヘッダーを挿入するには、このフィールドを使用してヘッダーの名前を決定します。 |
[HTTP ヘッダー値] |
[HTTP ヘッダー名] フィールドとともに使用される [値] フィールドは、サーバに送信される HTTP ヘッダーに挿入するクライアント証明書の部分を決定するために使用されます。プラス アイコンを使用すると、さらにヘッダーを挿入できます。このアクションは、HTTP ポリシーまたは DataScript によって実行されるアクションに追加される場合があります。これらのアクションは、宛先サーバに送信される要求にヘッダーを挿入するためにも使用できます。 |
圧縮
圧縮は、Gzip アルゴリズムを使用してテキストベースのデータのサイズを削減するための HTTP 1.1 標準です。HTML、JavaScript、CSS のようなテキスト コンテンツ タイプは、通常の圧縮率が約 75% です。つまり、20 KB のファイルをインターネット経由で送信する前に 5 KB に圧縮すると、送信時間が同様の割合で短縮されるのです。
圧縮により、NSX Advanced Load Balancer からクライアントへの応答で HTTP gzip 圧縮が有効になります。
[圧縮] タブを使用すると、アプリケーション プロファイルの HTTP 圧縮設定を表示したり編集したりできます。
達成された圧縮率は、仮想サービスの [クライアント ログ] タブを使用して表示できます。これには、仮想サービスの [分析] タブでフル クライアント ログを有効化して一部またはすべてのクライアント要求をログに記録することを要求される場合があります。ログには、各 HTTP 応答の圧縮率を示すフィールドが含まれます。
キャッシュで圧縮を有効化することが強く推奨されます。この 2 つを同時にすると、コンテンツの圧縮にかかる CPU コストが大幅に削減されます。圧縮とキャッシュの両方が有効になっている場合、index.html ファイルなどのオブジェクトは 1 回のみ圧縮する必要があります。オブジェクトが圧縮されると、後続の要求に対しては圧縮されたオブジェクトはキャッシュから提供されます。NSX Advanced Load Balancer では、クライアント要求ごとにオブジェクトを再圧縮する必要はありません。圧縮をサポートしていないクライアントの場合、NSX Advanced Load Balancer は非圧縮バージョンのオブジェクトもキャッシュします。
次の表の説明に従って、圧縮の構成を行います。
フィールド |
説明 |
|---|---|
[圧縮の有効化] |
このオプションをオンにすると、圧縮が有効になります。このオプションを有効化すると、圧縮の他の設定も表示されます。 |
[圧縮モード] |
圧縮モードでは、圧縮のレベルをクライアントごとに変えることが可能です。たとえば、低速モバイル クライアントには圧縮レベルをアグレッシブなものにして、ローカル イントラネットからの高速クライアントの圧縮は無効化するようなフィルタが作成できます。クライアントと利用可能なサービス エンジンの CPU リソースに基づいて設定を動的に調整するには、[自動] が推奨されます。
|
[圧縮可能なコンテンツ タイプ] |
このフィールドでは、圧縮の対象となる HTTP コンテンツ タイプを決定します。圧縮可能なタイプのリストが含まれている文字列グループをドロップダウン メニューから選択します。 |
[Accept-Encoding ヘッダーの削除] |
このフィールドでは、HTTP 1.1 クライアントによって送信され、圧縮されたコンテンツを受け入れることができることを示す Accept-Encoding ヘッダーを削除します。サーバに要求を送信する前に要求からヘッダーを削除すると、NSX Advanced Load Balancer は、サーバが応答を圧縮しないようにすることができます。NSX Advanced Load Balancer のみが圧縮を実行します。 |
[バッファ数] |
圧縮出力に使用するバッファの数を指定します。 |
[バッファ サイズ] |
圧縮出力に使用される各バッファのサイズを指定します。ページ サイズの倍数にするのが理想的であることは述べるまでもないことです。 |
[通常レベル] |
通常の圧縮用に選択されたコンテンツに適用する圧縮のレベルを指定します。 |
[アグレッシブ レベル] |
アグレッシブ圧縮用に選択されたコンテンツに適用する圧縮のレベルを指定します。 |
[ウィンドウ サイズ] |
圧縮で使用されるウィンドウ サイズを指定します。最終的には 2 の累乗に丸められます。 |
[ハッシュ サイズ] |
圧縮で使用されるハッシュ サイズを指定します。最終的には 2 の累乗に丸められます。 |
[応答コンテンツの長さ] |
圧縮を有効化する応答コンテンツの最小長を指定します。 |
[最大の低 RTT] |
クライアント RTT がこのしきい値を超える場合は、応答で通常の圧縮を有効にします。 |
[最小の高 RTT] |
クライアント RTT がこのしきい値を超える場合は、応答でアグレッシブ圧縮を有効にします。 |
[モバイル ブラウザ ID] |
モバイル ブラウザを識別してアグレッシブ圧縮を有効化する値を選択します。 |
カスタム圧縮
カスタム圧縮フィルタを作成するには、次の手順を実行します。
[+圧縮フィルタ]をクリックしてカスタム フィルタを作成します。
[圧縮フィルタの追加] セクションで、次のように構成します。
フィールド
説明
[フィルタ名]
フィルタの一意の名前を指定します（オプション）。
[一致ルール]
クライアントが（クライアント IP アドレスまたはユーザー エージェント文字列経由で）圧縮対象かどうかを、関連するアクションを使用して判断します。クライアント IP アドレス ルールとユーザー エージェント ルールの両方が入力されている場合、圧縮アクションを有効にするには両方とも true である必要があります。
[クライアント IP アドレス] は、IP グループを使用して、対象となるクライアント IP アドレスを指定できます。たとえば、すべての内部 IP アドレス範囲のリストを含む Intranet と呼ばれる IP グループです。[次に含まれる] ボタンをクリアすると、このロジックが逆になります。つまり、内部 IP ネットワークに属していないクライアントがフィルタに一致します。
[ユーザー エージェント] は、クライアントの User-Agent 文字列を文字列グループに含まれる適格なリストと照合します。User-Agent は、クライアントが使用しているブラウザまたはデバイスのタイプを示すヘッダーです。System-Devices-Mobile グループには、一般的なモバイル ブラウザの HTTP User-Agent 文字列のリストが含まれています。
[アクション] セクションでは、一致基準を満たすクライアントまたは要求に対する動作、特に使用される HTTP 圧縮レベルを決定します。
フィールド
説明
[アグレッシブ圧縮]
Gzip レベル 6 を使用し、テキスト コンテンツを約 80% 圧縮します。これにより、NSX Advanced Load Balancer とクライアントの両方からより多くの CPU リソースが必要になります。
[通常の圧縮]
Gzip レベル 1 を使用し、テキスト コンテンツを約 75% 圧縮します。これにより、圧縮率と、NSX Advanced Load Balancer とクライアントの両方で使用される CPU リソースが適切に組み合わされます。
[圧縮なし]
圧縮は無効になります。同じデータセンター内など、非常に高速で高帯域幅、低遅延の接続からアクセスするクライアントの場合、圧縮によって実際には送信時間が遅くなり、不要な CPU リソースが消費される可能性があります。
HTTP キャッシュ
NSX Advanced Load Balancer は HTTP コンテンツをキャッシュできるため、クライアントのページ ロード時間を短縮し、サーバと NSX Advanced Load Balancer の両方のワークロードを軽減できます。サーバが logo.jpg などの応答を送信すると、NSX Advanced Load Balancer はそのオブジェクトをキャッシュに追加し、同じオブジェクトを要求する後続のクライアントに提供できます。これにより、サーバに送信される接続および要求の数を減らすことができます。
キャッシュと圧縮を有効にすると、NSX Advanced Load Balancer はテキストベースのオブジェクトを圧縮し、圧縮されたバージョンと圧縮されていない元のバージョンの両方をキャッシュに保存できます。圧縮をサポートするクライアントからの後続の要求はキャッシュから応答されます。つまり、NSX Advanced Load Balancer は毎回すべてのオブジェクトを圧縮する必要がなくなり、圧縮ワークロードが大幅に軽減されます。
構成されているキャッシュ ポリシーに関係なく、オブジェクトはキャッシュの対象である場合にのみキャッシュできます。一部のオブジェクトはキャッシュの対象とならない場合があります。
デフォルトでは、キャッシュは無効化されています。[キャッシュを有効化] をクリックして、キャッシュに固有のオプションを構成します。
フィールド |
説明 |
|---|---|
[X-Cache] |
NSX Advanced Load Balancer は、キャッシュからクライアントに送信された応答に対して、X-Cache というラベルの HTTP ヘッダーを追加します。このヘッダーは情報提供のみを目的としており、オブジェクトが中間キャッシュから提供されたことを示します。 |
[Age ヘッダー] |
NSX Advanced Load Balancer は、キャッシュから提供されるコンテンツに、オブジェクトが中間キャッシュにある秒数をクライアントに示すヘッダーを追加します。たとえば、元のサーバで、オブジェクトは 10 分後に期限切れとなると宣言していて、そのオブジェクトが NSX Advanced Load Balancer キャッシュに 5 分間存在している場合、クライアントでは、オブジェクトをローカルでさらに 5 分間のみキャッシュしなければならないことを認識します。 |
[Date ヘッダー] |
サーバによって Date ヘッダーが追加されなかった場合は、NSX Advanced Load Balancer が HTTP キャッシュから提供されたオブジェクトに Date ヘッダーを追加します。このヘッダーは、オブジェクトがサーバによって NSX Advanced Load Balancer の HTTP キャッシュに最初に送信された日時をクライアントに示します。 |
[キャッシュ可能オブジェクトのサイズ] |
NSX Advanced Load Balancer HTTP キャッシュに格納できるオブジェクト（画像、スクリプトなど）の最小サイズと最大サイズ（バイト単位）。100 バイト未満のほとんどのオブジェクトは Web ビーコンであり、画像オブジェクトではあってもキャッシュされてはならないものです。 |
[キャッシュの有効期限] |
中間キャッシュは、古いコンテンツを提供しないことを保証できる必要があります。キャッシュ制御など、コンテンツをキャッシュできる期間を示すヘッダーをサーバが送信すると、NSX Advanced Load Balancer はこれらの値を使用します。サーバから有効期限のタイムアウトが送信されず、NSX Advanced Load Balancer で新しい状態をしっかりと確定できない場合、NSX Advanced Load Balancer では [キャッシュの有効期限] で指定した期間を超えてオブジェクトを保存することはありません。 |
[ヒューリスティックな有効期限] |
サーバからの応答オブジェクトに Cache-Control ヘッダーが含まれていないが If-Modified-Since ヘッダーが含まれている場合、NSX Advanced Load Balancer では、この時間を利用してキャッシュ制御の有効期限を計算します。この有効期限は、このオブジェクトの [キャッシュの有効期限] の設定よりも優先されます。 |
[クエリ引数を含むキャッシュ URL] |
このオプションを使用すると、URI にクエリ引数が含まれているオブジェクトをキャッシュできます。このオプションを無効にすると、これらのオブジェクトがキャッシュされなくなります。有効にすると、要求は対象の URI クエリと照合されます。クエリを含む URI の例を、この後に 2 つ示します。1 つ目の例は、一般的な検索をキャッシュする正当なユースケースであり、2 つ目はキャッシュに対するセキュリティ上の責任をもたらす一意の要求である可能性があります。
|
[キャッシュ可能な MIME タイプ] |
このオプションでは、キャッシュ可能なオブジェクトのリストを静的に定義します。これは、System-Cacheable-Resource-Types などの文字列グループの場合も、NSX Advanced Load Balancer でキャッシュしなければならない MIME タイプのカスタム カンマ区切りリストの場合もあります。このフィールドに MIME タイプが表示されない場合、デフォルトでは、NSX Advanced Load Balancer は、すべてのオブジェクトがキャッシュ可能であると見なします。 |
[キャッシュ不可能な MIME タイプ] |
キャッシュできないオブジェクトのリストを静的に定義します。これにより、キャッシュ可能なリストとは逆の拒否リストが作成されます。 |
HTTP DDoS
分散型サービス拒否 (DDoS) セクションでは、HTTP および基盤となる TCP プロトコルの緩和制御を構成できます。デフォルトでは、NSX Advanced Load Balancer は多くのタイプの攻撃から自身を保護するよう構成されています。たとえば、仮想サービスが SYN フラッド攻撃の対象になっている場合、NSX Advanced Load Balancer は SYN Cookie を有効にして、接続を開く前にクライアントを検証します。以下に示すオプションの多くは、アプリケーションにとってデータのバーストが正常である可能性があるため、それほど簡単ではありません。NSX Advanced Load Balancer には、最適な保護を確保するためにデフォルトの動作を変更するためのノブが用意されています。
以下で説明する DDoS 設定に加えて、NSX Advanced Load Balancer では、[詳細] プロパティ ページで構成した仮想サービスとプールへの接続制限を実装することもできます。仮想サービスは、[ネットワーク セキュリティ ポリシー] セクションで接続速度制限とバースト制限を使用して構成することもできます。これらの設定は個々の仮想サービスおよびプールに適用されるため、プロファイル内では構成されません。
HTTP 制限
HTTP ベースのサービス拒否攻撃を軽減するための最初の手順は、クライアントからのヘッダーと要求を転送するためのパラメータを設定することです。これらの設定の多くは、HTTP SlowLoris 攻撃と SlowPOST 攻撃のバリエーションから保護します。この攻撃では、クライアントが有効な接続を開き、要求ヘッダーを非常にゆっくりとストリーミングするか、ファイルを POST します。このタイプの攻撃は、バッファと接続を結び付けることでサーバ（この場合は SE）を過負荷状態にすることを目的としています。
以下に定義されている制限を超えるクライアントでは、その TCP 接続がリセットされ、ログが生成されます。このことが、クライアントが新しい接続を開始するのを妨げたり、同じクライアントが開いている可能性のある他の接続を中断したりすることはありません。
フィールド |
説明 |
|---|---|
[クライアント ヘッダーのタイムアウト] |
クライアントが要求の完全なヘッダーを正常に送信できる最長時間を設定します。デフォルトは 10 秒です。 |
[HTTP キープ アライブ タイムアウト] |
HTTP 1.0 または 1.1 接続がアイドル状態になる最長時間を設定します。これは、クライアントから NSX Advanced Load Balancer への通信にのみ影響します。NSX Advanced Load Balancer からサーバへのキープ アライブは、接続多重化機能によって制御されます。 |
[クライアント本文のタイムアウト] |
クライアントがメッセージ本文を送信する最長時間を設定します。通常、これはオブジェクトを POST（アップロード）しているクライアントにのみ影響します。デフォルト値の 0 は、このタイムアウトを無効にします。 |
[受け入れ後のタイムアウト] |
TCP 3 ウェイ ハンドシェイクが完了すると、クライアントは要求ヘッダーの最初のバイトを送信するのにこれだけの時間をかけます。最初のバイトを受信すると、このタイマーは満たされ、クライアント ヘッダーのタイムアウト（上記）が開始されます。 |
[Keep-Alive ヘッダーの送信] |
これをオンにすると、HTTP keep-alive ヘッダーがクライアントに送信されます。 |
[アプリのキープアライブ タイムアウトを使用] |
上記のパラメータをチェックして keep-alive ヘッダーがクライアントに送信されるようにする場合は、タイムアウト値を指定する必要があります。このチェック ボックスをオフにすると、NSX Advanced Load Balancer は [HTTP キープ アライブ タイムアウト] フィールドで指定された値を使用します。オンにすると、アプリケーションによって送信されたタイムアウトが考慮されます。 |
[クライアント Post の本文サイズ] |
クライアント要求の本文の最大サイズを設定します。これは、通常、クライアント POST のサイズを制限します。この値を 0 に設定すると、このサイズ制限が無効になります。 |
[クライアント要求のサイズ] |
クライアント要求内のすべてのヘッダーの最大合計サイズを設定します。 |
[クライアント ヘッダー サイズ] |
クライアント要求の 1 つのヘッダーの最大サイズを設定します。 |
レート制限
このセクションでは、クライアントがサイトと通信する速度を制御します。有効なレート制限ごとに、次の 3 つの設定があります。
フィールド |
説明 |
|---|---|
[しきい値] |
指定された期間内に接続、パケット、または HTTP 要求の定義されたしきい値が発生したときに、クライアントがレート制限に違反しました。 |
[期間] |
指定された期間内に接続、パケット、または HTTP 要求の定義されたしきい値が発生したときに、クライアントがレート制限に違反しました。 |
[アクション] |
クライアントがレート制限を超えた場合に実行するアクションを選択します。オプションは、制限が TCP 制限か HTTP 制限かによって異なります。
|
[1 つのクライアントからの接続のレート制限] |
1 つのクライアント IP アドレスから仮想サービスへのすべて接続でレートを制限します。 |
[1 つのクライアントからすべての URL への要求のレート制限] |
1 つのクライアント IP アドレスから仮想サービスのすべての URL に送信される HTTP 要求でレートを制限します。 |
[すべてのクライアントから 1 つの URL への要求のレート制限] |
すべてのクライアント IP アドレスから 1 つの URL へのすべての HTTP 要求でレートを制限します。 |
[1 つのクライアントから 1 つの URL への要求のレート制限] |
任意の 1 つのクライアント IP アドレスからの任意の 1 つの URL へのすべての HTTP 要求のレートを制限します。 |
[1 つのクライアントからすべての URL への失敗した要求のレート制限] |
クライアントからの要求の失敗数が指定の期間のしきい値を超えた場合、その期間中は、そのクライアントからのすべての要求のレート制限をします。クライアントは IP アドレスに基づいて追跡されます。要求はクライアント側またはサーバ側のエラー状態コードに基づいて失敗と見なされます。これは、NSX Advanced Load Balancer がログを記録する方法およびメトリック サブシステムが失敗した要求をマークする方法と同じです。 |
[すべてのクライアントから 1 つの URL への失敗した要求のレート制限] |
URI への要求の失敗数が指定の期間のしきい値を超えた場合、その期間中は、その URI へのすべての要求のレート制限をします。要求はクライアント側またはサーバ側のエラー状態コードに基づいて失敗と見なされます。これは、NSX Advanced Load Balancer がログを記録する方法およびメトリック サブシステムが失敗した要求をマークする方法と同じです。 |
[1 つのクライアントから 1 つの URL への失敗した要求のレート制限] |
クライアントから URI への要求の失敗数が指定された期間のしきい値を超えた場合、その期間、クライアントから URI へのすべての要求のレートを制限します。要求はクライアント側またはサーバ側のエラー状態コードに基づいて失敗と見なされます。これは、NSX Advanced Load Balancer がログを記録する方法およびメトリック サブシステムが失敗した要求をマークする方法と同じです。 |
[1 つのクライアントからすべての URL へのスキャンのレート制限] |
クライアントを自動的に追跡し、良好、不良、および不明の 3 つのグループに分類します。クライアントは IP アドレスに基づいて追跡されます。NSX Advanced Load Balancer スキャン検出システムがクライアントの正常に完了した要求の履歴を作成すると、クライアントが「良好」グループに追加されます。履歴が不足している場合、クライアントは「不明」グループに追加されます。履歴に要求の失敗が記録されているクライアントは、「不良」グループに追加されます。このクライアントの要求は、「不明」クライアントのグループよりも厳格なしきい値に基づいてレートが制限されます。NSX Advanced Load Balancer スキャン検出システムは自身を自動的に調整します。これにより、NSX Advanced Load Balancer によるトラフィック パターンの変更に応じて「良好」、「不良」、「不明」のクライアント IP グループのメンバーが動的に変更されます。つまり、Web サイトへの変更によってほとんどのユーザーに大規模な障害（404 エラーなど）が発生した場合、NSX Advanced Load Balancer は適応し、すべてのクライアントをサイトのスキャンを試みているとマークしません。 |
[すべてのクライアントからすべての URL へのスキャンのレート制限] |
前の制限と同様ですが、すべてのクライアントからのスキャンは、個別ではなく単一のエンティティとして制限されます。すべてのクライアントがまとめて制限に達すると、次に失敗した要求を送信するクライアントはリセットされます。 |
あらゆるタイプのファイルをローカル応答としてアップロードできます。ローカル ファイルを構成するにはユーザー インターフェイスを使用することが推奨されます。API を使用してローカル ファイルを更新するには、base64 ファイルをアウトオブバンドでエンコードし、エンコードした形式を API で使用します。
DNS プロファイル
DNS アプリケーション プロファイルでは、NSX Advanced Load Balancer による要求応答処理を指示する設定を指定します。
フィールド |
説明 |
|---|---|
[DNS サーバから返された IP の数] |
このオプションでは、DNS サービスによって返される IP アドレスの数を指定します。デフォルト値は 1 です。すべての IP アドレスを返すには 0 を入力します。それ以外の場合、有効な範囲は 1 ～ 20 です。 |
[TTL] |
提供された DNS 応答が DNS サービスの申請者によって有効と見なされる秒数（デフォルトは 30）。有効な範囲は 1 ～ 86,400 秒です。 |
[サブネットのプレフィックス長] |
この長さは、DNS クライアント サブネット (ECS) オプションと連携して使用されます。受信要求に ECS オプションがなく、プレフィックス長が指定されている場合、NSX Advanced Load Balancer は、アップストリーム サーバに渡された要求に ECS オプションを挿入します。有効な長さの範囲は 1 ～ 32 です。 |
[EDNS 拡張の処理] |
このオプションを使用すると、DNS サービスでは DNS 用拡張メカニズム (EDNS) を認識できるようになります。EDNS 拡張機能が解析され、ログに記録されます。GSLB サービスの場合、EDNS サブネット オプションを使用して、ロード バランシングを制御できます。EDNS がサポートされます。 |
[ネガティブ TTL] |
このオプションでは、DNS 仮想サービスによって提供される SOA (Start of Authority) レコードの最小 TTL 値を秒単位で指定します。SOA は、この DNS 仮想サービスで所有する権限ドメインに対応します。ネガティブ TTL は、0 ～ 86400 の範囲の値です。 |
[無効な DNS クエリ処理 (のオプション)] |
要求の処理中にエラーが発生した場合に DNS サービスで行わなければならないのはクライアントのドロップかクライアントへの応答かを指定します。デフォルトでは、このような要求は応答なしでドロップされます。パススルー プールが構成されている場合は、このプールに渡されます。応答に設定すると、適切な応答がクライアントに送信されます。たとえば、レコードが存在しない場合は NXDOMAIN 応答、クエリがサポートされていない場合は空の NOERROR 応答などです。 |
[空の応答で AAAA クエリに応答] |
このオプションを有効にすると、IPv4 レコードしかない場合に、DNS サービスが AAAA クエリに空の応答で応答するようになります。 |
[1 つのクライアントからの接続のレート制限] |
1 つのクライアント IP アドレスからこのプロファイルが適用される DNS 仮想サービスへの接続を制限します。デフォルト (=0) は、レート制限なしと解釈されます。 |
[しきい値] |
[期間] フィールドで指定した時間値で処理される接続、要求、またはパケットの最大数を指定します（正当な値の範囲は 10 ～ 2,500）。数値が大きいほど、レート制限が発生します。0 より大きい数値を指定すると、[期間] フィールドは必須になります。 |
[期間] |
NSX Advanced Load Balancer がしきい値の超過を監視する期間（秒単位）。許容範囲は 1 ～ 300 です。NSX Advanced Load Balancer は、受信要求レートを超えた場合に計算して指定されたアクションを実行します。このレートは、時間範囲に対する最大数の比率です。 |
[アクション] |
レート制限が必要な場合に実行する 3 つのアクション（[レポートのみ]、[SYN パケットのドロップ]、または [TCP RST の送信]）のいずれかをプルダウンから選択します。 |
[クライアント IP アドレスの保存] |
このオプションを有効化すると、クライアント IP アドレスがバックエンドにパススルーされます。バックエンド DNS サーバが想定した内容、クライアント IP アドレスを提供されたときに実行する処理を理解しておいてください。このオプションは、接続多重化と互換性がありません。 |
[有効なサブドメイン] |
サブドメイン名のカンマ区切りの許可リスト。このプロファイルが関連付けられている DNS 仮想サービスによって提供されるサブドメインを識別します。それ以外はすべて処理されません。このオプションの最適な使用方法は、GSLB のコンテキストで使用することです。その場合の GSLB DNS の唯一の目的は、提供されているグローバル アプリケーションに対応する IP アドレスを返すことです。有効なサブドメインは、「次で終わる」セマンティックとして構成されています。 |
[権限のあるドメイン名] |
GSLB DNS の SE が FQDN から IP アドレスへの信頼性のある変換を提供できる、カンマ区切りのドメイン名のセット。これらのドメインのサブドメインで、NSX Advanced Load Balancer に DNS レコードがない FQDN のクエリはドロップされるか、NXDOMAIN 応答が送信されます（上記の無効な DNS クエリに設定されたオプションに応じて）。権限のあるドメイン名は、「次で終わる」セマンティックとして構成されています。 |
サブドメイン内のすべてのラベルと信頼できるドメイン名は完全である必要があります。たとえば、alpha.beta.com、delta.beta.com、delta.eta.com、および gamma.eta.com が有効な FQDN であるとします。GSLB DNS が 4 つの FQDN のそれぞれに対するクエリに信頼性のある応答を返す場合は、beta.com と eta.com の 2 つの信頼できるドメインを識別できます。「eta」は完全なラベルではなく、また alpha.beta.com または delta.beta.com のいずれとも一致しないため、eta.com だけを規定するだけでは不十分です。
システム DNS プロファイルでは、EDNS オプションはデフォルトで有効になっています。NSX Advanced Load Balancer が古いバージョンから新しいバージョンへアップグレードされている場合、既存の DNS プロファイルでは EDNS がデフォルトで有効になっていません。ただし、同じ NSX Advanced Load Balancer Controller に新しい DNS プロファイルが作成された場合、EDNS はデフォルトで有効になります。
L4 プロファイル
L4 プロファイルは、アプリケーション レイヤー プロキシを必要としない仮想サービスに使用されます。
L4 プロファイルを使用することは、仮想サービスのアプリケーション プロファイルを none に設定することと同じです。
レート制限は、1 つのクライアント IP アドレスから仮想サービスに送信される TCP 接続または UDP パケットの数に設定できます。
フィールド |
説明 |
|---|---|
[しきい値] |
指定された期間内に接続 (TCP) またはパケット (UDP) の定義されたしきい値に達したときに、クライアントがレート制限に違反しました。 |
[期間] |
指定された期間内に接続 (TCP) またはパケット (UDP) の定義されたしきい値に達したときに、クライアントがレート制限に違反しました。 |
[アクション] |
クライアントがレート制限を超えた場合に実行するアクションを選択します。
|
Syslog プロファイル
Syslog アプリケーション プロファイルを使用すると、NSX Advanced Load Balancer で Syslog プロトコルをデコードできます。このプロファイルは、仮想サービスが Syslog を理解するように設定し、ネットワーク プロファイルをストリームごとの解析で UDP に設定します。
SIP プロファイル
SIP プロファイルを使用すると、NSX Advanced Load Balancer で SIP アプリケーションのトラフィックを処理できます。このプロファイルは、NSX Advanced Load Balancer 経由の SIP トラフィックで許可されるトランザクション タイムアウトを定義します。タイムアウトを 16 ～ 512 秒の範囲内で構成します。
