仮想サービスのポリシー

ポリシーを使用すると、ネットワークレイヤーのセキュリティ、HTTP セキュリティ、HTTP 要求、および HTTP 応答を高度にカスタマイズできます。ポリシーを使用して、セキュリティ、クライアント要求属性、またはサーバ応答属性を制御できます。ポリシーは、if-then ロジックと同様に、一致とアクションで構成されます。ロジックが true と評価されると、ポリシーに一致するため、NSX Advanced Load Balancer は対応するアクションを実行します。

ポリシーは、一致とアクションのペアである 1 つ以上のルールで構成されます。ルールには、多くの一致やアクションを含めることができます。1 つの仮想サービスに複数のポリシーを構成できます。ポリシーは、仮想サービスのデフォルトの動作を変更したり、一致の基準が満たされない場合に特定の接続、要求、または応答に対して無害なままにしたりすることができます。

ポリシーは共有されません。これらは仮想サービス単位で定義され、シンプルなポイントアンドクリック機能を目的としています。

より高度な機能については、『VMware NSX Advanced Load Balancer DataScript ガイド』を参照してください。

ポリシーは、仮想サービスエディタの [ポリシー] タブ内で構成されます。

ポリシーの優先順位付け

ポリシーを使用して、NSX Advanced Load Balancer 内の他の場所にある同様の機能を再作成できます。たとえば、HTTP から HTTPS への HTTP リダイレクトを生成するようにポリシーを構成できます。Secure-HTTP アプリケーションプロファイル内で同じ機能を構成できます。ポリシーは汎用プロファイルよりも具体的であるため、ポリシーが優先されます。

プロファイルがポート 443 を介して HTTP を HTTPS にリダイレクトするように設定され、ポリシーがポート 8443 で HTTP から HTTPS にリダイレクトするように設定されている場合、クライアントはポート 8443 に送信されます。（詳細については、『VMware NSX Advanced Load Balancer DataScript ガイド』の「実行の優先順位」を参照してください。）

仮想サービスには、4 つのタイプそれぞれに 1 つずつ、複数のポリシーを定義できます。定義されると、4 つのタイプのポリシーが次の優先順位で実装されます。

ネットワークセキュリティポリシー。
HTTP セキュリティポリシー。
HTTP 要求ポリシー。
HTTP 応答ポリシー。
DataScript ポリシー。
アクセスポリシー。

たとえば、トラフィックを破棄するように設定されたネットワークポリシーは、ヘッダーを変更するように設定された HTTP 要求ポリシーよりも優先されます。接続が破棄されるため、HTTP 要求ポリシーは実行されません。各ポリシータイプには複数のルールを含めることができます。ルールは、指定された順序で処理するために優先順位を付けることができます。これは、NSX Advanced Load Balancer ユーザーインターフェイス内の順序付きリストでポリシーを上下に移動することによって行われます。

一致 - アクション

すべてのポリシーは、一致ルールとアクションルールで構成されています。これは、概念的には if - then ロジックと似ています。管理者は、仮想サービスへのすべての接続、要求、または応答に一致基準を設定します。NSX Advanced Load Balancer は、一致基準を満たすすべてのトラフィックに対して構成済みのアクションを実行します。

複数のエントリを含む 1 つの一致は、「OR」演算として扱われます。たとえば、1 つの一致タイプに「marketing」、「sales」、「engineering」という基準が設定されていて、パスに「marketing」、「sales」、または「engineering」が含まれている場合、一致は true になります。

ルールに複数の一致が構成されている場合、アクションを実行するには、すべての一致タイプが true である必要があります。上のスクリーンショットでは、[パス] と [HTTP メソッド] の両方の一致が true である必要があります。これら 2 つの一致タイプ内で、その一致タイプが true になるにはエントリの 1 つのみが true である必要があります。HTTP メソッドの場合、クライアント要求のタイプは GET または HEADである必要があります。ポリシーごとに複数のルールを構成し、特定の順序で適用されるように構成できます。一致が適用されない場合、条件が自動的に満たされ、ポリシータイプに従って接続ごとにアクションが実行されます。

HTTP コンテンツに対する一致では、大文字と小文字が区別されません。これは、ヘッダー名と値、Cookie、ホスト名、パス、クエリに当てはまります。HTTP ポリシーの場合、NSX Advanced Load Balancer は URI (Uniform Resource Identifier) の一致をデコードされた HTTP URI と比較します。多くのブラウザと Web サーバは、人間が判読可能な形式のコンテンツを異なる方法でエンコードします。たとえば、ブラウザの URI エンコードでは、ドル記号「$」が「%24」に変換されることがあります。サービスエンジン (SE) は、一致基準に対して評価する前に「%24」を「$」に変換します。

ポリシーの作成

仮想サービスエディタは、仮想サービスを介した要求のフローを制御する 1 つ以上のルールで構成されるポリシーを定義します。

ポリシーを作成するには、次の手順を実行します。

[ポリシータイプ]：まず、次のいずれかのカテゴリを選択して、追加するポリシータイプを選択します。
1. [HTTP セキュリティ]：HTTP セキュリティポリシーは、許可/拒否、HTTPS へのリダイレクト、静的ページでの応答などの定義済みアクションを実行します。
2. [ネットワークセキュリティ]：ネットワーク内のユーザー定義タイプのトラフィックを明示的に許可またはブロックするように構成されています。
3. [HTTP 要求]：HTTP 要求ポリシーを使用すると、HTTP 要求およびコンテンツの切り替えを操作し、また、クライアント HTTP 要求に基づいてカスタマイズされたアクションを実行できます。
4. [HTTP 応答]：HTTP 応答ポリシーはサーバからの応答を評価し、サーバの応答ヘッダーを変更するために使用できます。HTTP 応答ポリシーは、クライアントとサーバ間で Web サイトの名前を書き換える Apache Mod_ProxyPass 機能を提供するために、HTTP 要求ポリシーで最も頻繁に使用されます。
5. [DataScript]：DataScript は、データプレーントラフィックによってさまざまなイベントがトリガされると実行されます。
6. [アクセス]：SAML または Ping アクセスにアクセスポリシーを指定できます。
[ルールの作成]：プラスアイコンをクリックして新しいルールを作成し、新しいルールに関する次の情報を指定します。
1. [有効化または無効化]：デフォルトでは、新しいルールが有効になっています。緑色のスライダアイコンを灰色に切り替えてルールを無効化し、トラフィックに影響を及ぼさないようにすることができます。
2. [ルール名]：[ルール名] フィールドにルールの一意の名前を指定するか、システム生成のデフォルトの名前をそのまま使用します。
3. [ログの記録]：このルールでログの記録を有効にする場合は [ログの記録] を選択します。有効にすると、ルールの一致基準に一致する接続または要求のログが生成されます。仮想サービスがすでにすべての接続または要求をログに記録するように設定されている場合、このオプションは重複するログを作成しません。クライアントログには、一致したポリシータイプとルール名のエントリがフラグ付けされます。仮想サービスの [ログ] タブでポリシーのログを表示する場合、特定の接続または要求がエラーでない限り、ログは重要なログオプションの一部になります。この場合、デフォルトの重要でないログフィルタに表示できます。
4. [一致]：[新規一致を追加] ドロップダウンメニューを使用して、1 つ以上の一致を追加します。一致オプションは、作成するポリシータイプによって定義されたコンテキストによって異なります。ルールに一致が指定されていない場合、すべての接続または要求は true または一致と見なされます。
5. [アクション]：ドロップダウンメニューから、一致が true の場合に実行する 1 つ以上のアクションを追加します。使用可能なオプションは、作成するルールのタイプによって異なります。
6. [ルールの保存]：[ルールの保存] ボタンをクリックして、新しいルールを保存します。
[順序]：ルールは、リストに表示される順序で適用されます。たとえば、クライアント IP アドレスに基づいて接続を閉じるルールを追加し、その後にその IP アドレスから安全な HTTP (HTTPS) 接続に HTTP 要求をリダイレクトするルールを追加すると、NSX Advanced Load Balancer は要求を転送せずに接続を閉じます。ルールが目的の順序になるまで上下の矢印アイコンをクリックして、ルールが適用される順序を変更します。

ネットワークセキュリティ

次の表に、使用可能なネットワークセキュリティ一致基準と、一致した場合に実行される可能性のある構成可能なアクションの両方を示します。

注：

この機能は、NSX Advanced Load Balancer の IPv6 でサポートされています。


[一致]	[クライアントの IP アドレス]：クライアントの IP アドレスまたはクライアントアドレスのグループ。「-」を使用して範囲を指定します：10.0.0.0-10.1.255.255 「/」を使用してネットマスクを指定します：10.0.0.0/24
	[サービスポート]：仮想サービスが待機しているポート。
	[IP レピュテーション]：関連付けられている脅威に基づいて IP アドレスを識別または分類する IP レピュテーションサービス。
[アクション]	[ログの記録]：オプションを選択すると、アクションが呼び出されたときに NSX Advanced Load Balancer がログに記録します。
	[許可または拒否]：一致するトラフィックを明示的に許可または拒否します。拒否されたトラフィックには、システムがボリューム型攻撃またはサービス拒否攻撃を受けている場合を除き、リセット (RST) が発行されます。この場合、接続はサイレントに破棄されます。
	[レート制限]：[最大速度] フィールドで指定された 1 秒あたりの接続数を超えて接続を開かないように、クライアントを制限します。この数を超えるクライアントでは、超過した接続試行はサイレントに破棄されます。バーストサイズが有効になっている場合、クライアントが最近接続を開いていなくても、最大レートを超えてバーストする可能性があります。この機能は、TCP または UDP に適用できます。一致の基準に一致するすべてのクライアントは、1 つのバケットとして扱われます。たとえば、一致が定義されていない場合、すべての IP アドレスによって最大レートカウンタが増加します。すべての新しい接続クライアントでスロットルが発生します。クライアントごとのスロットルを有効にするには、仮想サービスの [詳細] タブを参照してください。このページのマニュアルには、スロットルの接続に関するより明確な説明も含まれています。

HTTP セキュリティポリシー

次の表に、使用可能な HTTP セキュリティ一致基準と、一致した場合に実行される可能性のある構成可能なアクションの両方を示します。


[一致]	[クライアントの IP アドレス]：クライアントの IP アドレスまたはクライアントアドレスのグループ。「-」を使用して範囲を指定します：10.0.0.0-10.1.255.255 「/」を使用してネットマスクを指定します：10.0.0.0/24 事前定義された IP グループを使用します。これは位置情報に基づいて設定できます。
	[サービスポート]：仮想サービスが待機しているポート。 SNI 仮想ホスティングおよび拡張仮想ホスティングでは、サービス一致基準は、子仮想サービスの下のポリシーについて親仮想サービスと照合されます。
	[プロトコルタイプ]：HTTP または HTTPS。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	[HTTP メソッド]：クライアント要求によって使用されるメソッド。管理者が指定したいずれかのメソッドが true の場合、一致は true になります。使用可能なオプションは、GET、HEAD、POST、PUT、DELETE、OPTIONS、TRACE、CONNECT、PATCH、PROPFIND、PROPPATCH、MKCOL、COPY、MOVE、LOCK、UNLOCK です。
	[HTTP バージョン]：クライアントのバージョンが 0.9、1.0、または 1.1 の場合は true
	[パス]：パスまたはパスのグループ。パスはスラッシュ (/) で始まる必要はありません。比較のために、NSX Advanced Load Balancer は一致フィールドで指定された最初のスラッシュを自動的に省略します。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	[クエリ]：クエリまたはクエリのグループ。先頭の「?」または「&」文字を一致に追加しないでください。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	[ヘッダー]：ヘッダーが存在する場合、またはヘッダーが存在し、指定された値が含まれている場合は true
	[Cookie]：Cookie が存在する場合、またはヘッダーが存在し、指定された値が含まれている場合は true
	[Host ヘッダー]：要求の Host ヘッダー。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
アクション	[ログの記録]：オプションを選択すると、アクションが呼び出されたときに NSX Advanced Load Balancer がログに記録します。
	[許可]：一致した要求が、さらにポリシーまたは宛先プールサーバに対して続行できるようにします。
	[接続の終了]：要求が一致すると、NSX Advanced Load Balancer は FIN を介して要求を受信した TCP 接続を終了します。多くのブラウザは、終了していない複数の接続を開きます。ただし、これらの接続を介して送信された要求が接続の終了アクションをトリガする場合を除きます。
	[HTTPS へのリダイレクト]：SSL の目的のポートに一時的にリダイレクトして要求に応答します。
	[応答の送信]：NSX Advanced Load Balancer は、HTTP 状態コード 200（成功）、403（認証が必要です）、または 404（ファイルが見つかりません）を使用して HTTP 応答を処理できます。デフォルトのページは、これらの状態コードごとにブラウザによってレンダリングされます。代わりに、カスタム HTML ファイルをアップロードすることもできます。このファイルには、イメージやその他のファイルへのリンクを設定できますが、最初の HTML ファイルのみが保存され、応答の送信を介して提供されます。注：あらゆるタイプのファイルをローカル応答としてアップロードできます。ローカルファイルを構成するにはユーザーインターフェイスを使用することが推奨されます。API を使用してローカルファイルを更新するには、base64 ファイルをアウトオブバンドでエンコードし、エンコードした形式を API で使用します。
	[レート制限]：新しい接続の最大数、HTTP 要求、帯域幅（Mbps 単位）、およびクライアントとの間で同時に開いている接続の数を指定します。

注：

NSX Advanced Load Balancer ユーザーインターフェイスで使用可能な HTTP セキュリティポリシーオプション。既存の HTTP セキュリティポリシーを作成または編集するには、[アプリケーション] > [仮想サービス] に移動し、目的の仮想サービスを選択して、[HTTP セキュリティ] オプションを選択します。

HTTP 要求

HTTP 要求ポリシーを使用して HTTP 要求を操作できます。これらの要求は、サーバに転送される前に変更したり、コンテンツの切り替えの基盤として使用したり、破棄したりできます。HTTP 要求ポリシーは、HTTP プロファイルで構成されたレイヤー 7 仮想サービスにのみ適用できます。次の表に、HTTP 要求で使用可能な一致基準と、一致した場合に実行するように構成できるアクションを示します。

注：

この機能は、NSX Advanced Load Balancer の IPv6 でサポートされています。

HTTP 要求ポリシー


一致	クライアントの IP アドレス：クライアントの IP アドレスまたはクライアントアドレスのグループ。「-」を使用して範囲を指定します：10.0.0.0-10.1.255.255。「/」を使用してネットマスクを指定します：10.0.0.0/24。事前定義された IP グループを使用します。これは位置情報に基づいて設定できます。注： IPv6 アドレス形式のクライアント IP アドレスも使用できます。
	サービスポート：仮想サービスが待機しているポート。
	プロトコルタイプ：HTTP または HTTPS。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	HTTP メソッド：クライアント要求によって使用されるメソッド。管理者が指定したいずれかのメソッドが true の場合、一致は true になります。使用可能なオプションは、`GET`、`HEAD`、`POST`、`PUT`、`DELETE`、`OPTIONS`、`TRACE`、および `CONNECT` です。`PATCH`、`PROPFIND`、`PROPPATCH`、`MKCOL`、`COPY`、`MOVE`、`LOCK`、`UNLOCK` の追加オプションから選択することもできます。
	HTTP バージョン：クライアントのバージョンが 0.9、1.0、または 1.1 の場合は true
	パス：パスまたはパスのグループ。RFC 3986 に従って、パスは空であるか、スラッシュで始まります。HTTP 要求一致ポリシーの `beginswith` および `equals` 一致演算子の場合は、一致文字列をスラッシュで始めて一致させる必要があります。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2 では、パスは /marketing/index.html です。
	クエリ：クエリまたはクエリのグループ。先頭の「?」または「&」文字を一致に追加しないでください。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	ヘッダー：ヘッダーが存在する場合、またはヘッダーが存在し、指定された値が含まれている場合は true。
	Cookie：Cookie が存在する場合、またはヘッダーが存在し、指定された値が含まれている場合は true。
	Host ヘッダー：要求の Host ヘッダー。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
アクション	リダイレクト URL：クライアントを別のプロトコル、ポート、ホスト、またはパスにリダイレクトします。デフォルトでは、管理者がこれらのフィールドに入力しない限り、ホスト、パス、およびクエリは変更されません。パスフィールドには、先頭にスラッシュ文字「/」は必要ありません。HTTP から HTTPS への簡単なリダイレクトを作成するには、プロトコルを HTTPS に設定します。注：リダイレクトアクションは、他のアクションと一緒にスタックすることはできません。
	ヘッダーの変更：HTTP ヘッダーまたは Cookie の追加、置き換え、または削除を許可します。注：フィールド [機密性が高い] は、ヘッダーの変更アクション内に追加され、機密性の高いカスタム値をマスクします。
	URL の書き換え：ProxyPass 機能と同様に、このアクションにより、クライアントが要求した URL がサーバが理解できる URL に書き換えられます。たとえば、クライアントが www.avinetworks.com/sales を使用した場合、サーバはこれを sales.avinetworks.com に構成できます。パスフィールドには、先頭にスラッシュ文字「/」は必要ありません。
	コンテンツスイッチ：一致した要求をプール、またはそのプールを持つ特定のサーバに転送します。または、NSX Advanced Load Balancer は HTTP 状態コード 200（成功）、403（認証が必要です）、404（ファイルが見つかりません）、または 429（要求が多すぎます）を使用して HTTP 応答を処理できます。これらの状態コードごとにデフォルトのページが送信されるか、カスタム HTML ファイルがアップロードされます。注：あらゆるタイプのファイルをローカル応答としてアップロードできます。ローカルファイルを構成するにはユーザーインターフェイスを使用することが推奨されます。API を使用してローカルファイルを更新するには、base64 ファイルをアウトオブバンドでエンコードし、エンコードした形式を API で使用します。

機密性が高い

[機密性が高い] オプションは、[ヘッダーの変更] のカスタム値をマスクするために使用されます。[機密性が高い] フィールドが [ヘッダーの変更] アクション内に追加され、機密性の高いカスタム値を追加します。

機密性が高いフィールド（[機密性が高い]）は、カスタム値を機密性が高いとマークする必要があるかどうかを決定する HTTP ヘッダー値のフラグです。[機密性が高い] フィールドをオンにすると、[HTTP ポリシーセット] のアクションの [ヘッダーの変更] オプションのカスタム値がマスクされます。以下のスクリーンショットに例を示します。

注：

[機密性が高い] は変更できないフィールドで、HTTP ポリシーの作成時にのみ設定または設定解除できます。

ヘッダー値がマスクされているため、既存のヘッダーの更新は管理者にとって難しい場合があります。これを簡素化するために、NSX Advanced Load Balancer は、上のスクリーンショットに示すように、インデックス、つまりすべてのヘッダーを一意に識別する整数値を割り当てます。これは、あいまいさを取り除くのに役立ちます。インデックスは、NSX Advanced Load Balancer によって自動的に割り当てられます。インデックスを変更する必要がある場合は、CLI または API を使用して行うことができます。インデックスは一意の値にする必要があります。

HTTP ポリシーのカスタム値に機密フィールドを設定する CLI は次のとおりです。

+------------------------+----------------------------------------------------+
| Field                  | Value                                              |
+------------------------+----------------------------------------------------+
| uuid                   | httppolicyset-14be5dde-8ff2-4891-a930-a81b6f547d9b |
| name                   | test-HTTPPolicySet-0                               |
| http_request_policy    |                                                    |
|   rules[1]             |                                                    |
|     name               | Rule 1                                             |
|     index              | 1                                                  |
|     enable             | True                                               |
|     match              |                                                    |
|       vs_port          |                                                    |
|         match_criteria | IS_IN                                              |
|         ports[1]       | 80                                                 |
|     hdr_action[1]      |                                                    |
|       action           | HTTP_ADD_HDR                                       |
|       hdr              |                                                    |
|         name           | pqr                                                |
|         value          |                                                    |
|           val          | <sensitive>                                        |
|           is_sensitive | True                                               |
|       hdr_index        | 1                                                  |
| is_internal_policy     | False                                              |
| tenant_ref             | admin                                              |
+------------------------+----------------------------------------------------+

HTTP ポリシー QueryMatch

HTTP ポリシーでは、照合できるパラメータの 1 つが URI のクエリ文字列です。QueryMatch は、次の点で他の一致ターゲットと似ています。

クエリ文字列をカスタム文字列または文字列グループのリストと照合するために使用されます。
これは、[クエリを保持] ノブを使用して、クエリ文字列をアクションルール（リダイレクトまたは URL の書き換えアクション）にコピーするために使用されます。

一致基準の追加

クエリの一致でサポートされる一致操作は次のとおりです。


一致操作	説明
QUERY_MATCH_CONTAINS	クエリ文字列に構成済みの値が含まれています
QUERY_MATCH_DOES_NOT_CONTAIN	クエリ文字列に構成済みの値が含まれていません
QUERY_MATCH_EXISTS	クエリ文字列が URI に存在するかどうかを確認します
QUERY_MATCH_DOES_NOT_EXIST	クエリ文字列が存在しない（または空）かどうかを確認します
QUERY_MATCH_BEGINS_WITH	クエリ文字列が構成済みの値で始まっています
QUERY_MATCH_DOES_NOT_BEGIN_WITH	クエリ文字列が構成済みの値で始まっていません
QUERY_MATCH_ENDS_WITH	クエリ文字列が構成済みの値で終わっています
QUERY_MATCH_DOES_NOT_END_WITH	クエリ文字列が構成済みの値で終わっていません
QUERY_MATCH_EQUALS	クエリ文字列が構成済みの値と一致しています
QUERY_MATCH_DOES_NOT_EQUAL	クエリ文字列が構成済みの値と一致しません
QUERY_MATCH_REGEX_MATCH	クエリ文字列が構成された正規表現と一致します
QUERY_MATCH_REGEX_DOES_NOT_MATCH	クエリ文字列が構成された正規表現と一致しません

注：

正規表現の一致では、文字列グループのみが使用されます。
正規表現の一致には、最大 10 個のキャプチャグループを含めることができます。

一致するエンコードされた文字列

NSX Advanced Load Balancer では、Query_Match の Match Decoded String オプションがサポートされています（以前はパスの一致でサポート）。このオプションを使用すると、エンコードされた (UTF-8) クエリ文字列と照合するか、デコードされたクエリ文字列と照合するかを指定できます。デフォルトでは、オプションが選択されています。

例 1：

Match_decoded のマークが解除され、URI /hello/test?efg=%21efg が送信されると、ルールが一致します。URI /hello/test?efg=!efg が送信された場合、ルールは一致しません。

例 2：

文字列 hello/test?efg=!efg または hello/test?efg=%21efg に Match_decoded がマークされている場合、文字列は両方とも hello/test?efg=!efg に変換されるため、両方とも一致します。

HTTP 要求キュー

HTTP 要求キューにより、バックエンドサーバが同時接続の最大数に達すると、NSX Advanced Load Balancer は受信した要求をキューに登録します。HTTP 要求をキューに登録すると、構成されたプールダウンアクションを実行せずに、新しい接続がサーバで使用可能になるまでの時間が提供されます。

HTTP 要求キューはデフォルトで無効になっています。この機能は、プールごとに有効にできます。機能が有効になっている場合、デフォルトのキュー長は 128 要求です。キューの長さは、1 から必要な量まで設定可能です。唯一の制限は、SE でメモリを使用できる必要がある点です。

キューの管理方法

キューに入っている要求は、最後の入力、先出し (LIFO) ベースで管理されます。たとえば、キューの長さが 128 の場合、NSX Advanced Load Balancer は飽和したサーバに対して最大 128 個の要求をキューに登録できます。キューに入れることができるのは GET 要求のみです。PUT 要求はキューに入れません。サーバは新しい要求を受け入れることができませんが、NSX Advanced Load Balancer はキューが保持できる要求の最大数まで、つまりキューの長さまで新しい要求をキューに入れます。キューがいっぱいで、サーバがまだ新しい要求を受け入れることができない場合、キューはバイパスされ、NSX Advanced Load Balancer 構成済みのプール停止アクションの新しい要求への適用を開始します。

サーバが新しい要求を再び受け入れられると、新しい要求に優先順位が与えられます。新しい要求は、キューに入っている要求よりも優先され、最初にサーバに送信されます。サーバに送信できる新しい要求がない場合にのみ、SE はキューから要求を送信します。これは、最新の要求、つまり最後にキューに入った要求から始まります。キューから最も古い要求ではなく、最近キューに入った要求を送信すると、新しい要求の一部が古い要求を再送信したり、クライアントが応答しないセッションを終了したりする可能性があるため、エンドユーザーへの影響を最小限に抑えることができます。サーバがいっぱいであるためにキューに要求を送信しても、エラーイベントは生成されません。キューがいっぱいの場合は、イベントが生成されます。

パーシステンスへの影響

HTTP 要求キューは、パーシステンスとともに使用できます。両方の機能が有効で、パーシステンスが特定のサーバに接続を維持する必要があり、そのサーバがいっぱいの場合、その接続の要求は、必要なサーバが使用可能な接続を持つまでキューに入ります。要求は別のサーバに送信されません。キュー内では、要求は上記のように LIFO ベースで引き続き管理されます。

HTTP キャッシュへの影響

HTTP キャッシュが有効になっていて、NSX Advanced Load Balancer がキャッシュ内にあるオブジェクトの要求を受信すると、NSX Advanced Load Balancer はサーバに対してオブジェクトを要求するのではなく、キャッシュからオブジェクトを送信して要求を処理します。この場合、要求を受信するための空き接続がサーバにない場合でも、要求をキューに登録する必要はありません。

キューサイズの推奨事項

SE には、構成された HTTP キューサイズをサポートするのに十分なメモリが必要です。

要求あたりの平均要求サイズが 2 KB の場合、キューの長さを 128 に設定するには、256 KB のメモリが必要です。キューサイズを大きくするには、適切な量のメモリを SE に割り当てる必要があります。

キュー長の変更の影響

キューの長さが変更されると、変更はすぐに有効になります。

キューの長さを増やすと、サーバが飽和している間にキューに入る要求が増えます。
キューの長さが減少し、新しいサイズが現在キューにある要求の数よりも小さくなると、NSX Advanced Load Balancer は、最も古い要求（最初にキューに入れられた要求）から順に、キューから余分な要求をすぐにドロップします。たとえば、キューの長さが 128 でキューがいっぱいの場合、キュー長を 64 に減らすと、キューから最も古い 64 個の要求が即座にドロップされます。

HTTP 要求キューの構成

プールの要求キューを有効にするには、次の手順を実行します。

[アプリケーション] > [プール] の順に移動します。
[作成] をクリックして新しいプールを作成するか、プール名の横にある [編集] アイコンをクリックします。
[詳細] タブに移動します。新しいプールを作成する場合は、名前を入力し、[次へ] を 2 回クリックします。
[プールの完全な設定] セクションで、[要求キュー] の横にある [有効] を選択します。
キューサイズを変更するには、[キュー長] フィールドで数値を編集します。特定の最大長の値はありません。この場合、SE でキューに使用できるメモリの量が実際の制限を示します。
新しいプールを構成する場合は、他のプール設定の構成を完了し、[保存] をクリックします。

HTTP 応答ポリシー

HTTP 応答ポリシーはサーバからの応答を評価し、サーバの応答ヘッダーを変更するために使用できます。これらのポリシーは通常、リダイレクトを書き換えたり、HTTP 要求ポリシーと組み合わせて使用したりして、Apache の ProxyPass と同様のサーバ名書き換え機能をクライアントに提供します。

内部から外部へのホスト名マッピングを作成する場合は、仮想サービスの詳細セクションで、より簡単なホスト名変換機能を使用することを検討してください。HTTP 応答の一致時に、クライアントデータに基づく一致基準が元のクライアント要求に対して評価されます。たとえば、クライアントが /fruit.htm を要求し、要求ポリシーがパスを /cheese.htm に変更した場合、パスの応答一致ルールは、クライアントから送信された未変更の元のパス (/fruit.htm) と比較されます。次の表に、HTTP 応答で使用可能な一致基準と、一致が行われるときに実行するように構成できるアクションを示します。


一致	クライアントの IP アドレス：クライアントの IP アドレスまたはクライアントアドレスのグループ。「-」を使用して範囲を指定します。 10.0.0.0-10.1.255.255 「/」を使用してネットマスクを指定します。 10.0.0.0/24 geo-location に基づいて定義された IP グループを使用します。
	サービスポート：仮想サービスが待機しているポート。
	プロトコルタイプ：HTTP または HTTPS。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	HTTP メソッド：クライアント要求によって使用されるメソッド。管理者が指定したいずれかのメソッドが true の場合、一致は true になります。
	HTTP バージョン:クライアントのバージョンが .9、1.0、または 1.1 の場合は True。
	パス：パスまたはパスのグループ。パスは「/」で始まります。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	クエリ：クエリまたはクエリのグループ。先頭の「?」または「&」文字を一致に追加しないでください。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	ヘッダー：ヘッダーが存在する場合、またはヘッダーが存在し、指定された値が含まれている場合は true。
	Cookie：Cookie が存在する場合、またはヘッダーが存在し、指定された値と等しい場合は true。
	Host ヘッダー：要求の Host ヘッダー。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	Location ヘッダー：Location ヘッダーは、Web サイトによっては存在しない場合があります。
	HTTP 状態：200（成功）、404（ファイルが見つかりません）、などの応答の状態。状態はカンマで区切るか、範囲を指定することができます。例：301, 302, 307, 308, 300-599。
	応答ヘッダー：サーバから送信された特定のヘッダーに基づいた一致。
アクション	ログの記録：[ログの記録] チェックボックスをオンにすると、アクションが呼び出されたときに Vantage がログに記録します。
	ヘッダーの変更：HTTP ヘッダーまたは Cookie の追加、置き換え、または削除を許可します。
	Location ヘッダーの書き換え：Location ヘッダーを変更します。内部名と外部名間のプロキシに役立ちます（www.avinetworks.com/sales から sales.avinetworks.com/ など）。

DataScript

DataScript は、データプレーントラフィックによってさまざまなイベントがトリガされると実行されます。1 つのルールで、さまざまなイベント中にさまざまなコードを実行できます。

詳細については、『VMware NSX Advanced Load Balancer DataScript ガイド』の「DataScript イベント」を参照してください。

アクセス

アクセスポリシーは、SAML、PingAccess、JWT、または LDAP アクセスに対して指定できます。

SAML

[SAML] オプションを選択した場合は、次の詳細を指定します。

[SSO ポリシー]：仮想サービスに適用されている SSO ポリシーを指定します。
[エンティティ ID]：このノードの SAML エンティティ ID を指定します。
[SSO URL]：IDP でプログラミングする SAML シングルサインオン URL を指定します。
[セッション Cookie 名]：認証済みセッションの HTTP Cookie 名を指定します。
[セッション Cookie のタイムアウト]：Cookie タイムアウトを分単位で指定します。
[SSL キー]：ドロップダウンメニューから SSL キーを選択します。

PingAccess

[PingAccess] オプションを選択した場合は、次の詳細を指定します。

[SSO ポリシー]：仮想サービスに適用されている SSO ポリシーを指定します。

[SSO ポリシーの作成] ボタンクリックして SSO ポリシー作成します。次の詳細を指定します。

[名前]：SSO ポリシーの名前を指定します。
[タイプ]：ドロップダウンリストから SSO ポリシーのタイプを選択します。ドロップダウンリストで使用できるオプションは次のとおりです。
- JWT
- LDAP
- OAUTH/OIDC
- PingAccess
- SAML
[デフォルトの認証プロファイル]：ユーザーの検証に使用する認証プロファイルを指定します。
[認証ルール]：[追加] ボタンをクリックして、認証の詳細を追加します。

JWT

[JWT] オプションを選択した場合は、次の詳細を指定します。

[SSO ポリシー]：仮想サービスに適用されている SSO ポリシーを選択します。
[対象]：リソースサーバを識別する一意の対象を指定します。
[トークンの場所]：トークンの場所として [認可ヘッダー] または [URL クエリ] を選択します。

LDAP

[LDAP] オプションを選択した場合は、次の詳細を指定します。

[SSO ポリシー]：仮想サービスに適用されている SSO ポリシーを指定します。
[基本レルム]：認証リクエストがクライアントに提示されると、基本レルムは、アクセスしているレルムをクライアントに示します。
[サーバ 1 台あたりの接続数]：単一の基本認証 LDAP プロセスによる LDAP サーバへの同時接続数を指定します。
[キャッシュサイズ]：データプレーンで使用される LDAP 基本認証情報キャッシュのサイズを指定します。
[バインドタイムアウト]：LDAP サーバへの接続に適用される LDAP 基本認証のデフォルトのバインドタイムアウトを指定します。
[要求のタイムアウト]：LDAP サーバへの接続に適用される LDAP 基本認証のデフォルトのログインまたはグループ検索要求のタイムアウトを指定します。
[接続タイムアウト]：LDAP サーバへの接続に適用される LDAP 基本認証のデフォルトの接続タイムアウトを指定します。
[再接続タイムアウト]：LDAP サーバへの接続に適用される LDAP 基本認証のデフォルトの接続タイムアウトを指定します。
[サーバフェイルオーバーのみ]：フェイルオーバーのみの場合に LDAP 基本認証で複数の LDAP サーバが使用されることを示すには、このボックスをオンにします。

すべての必要な詳細を指定した後、[保存] ボタンをクリックします。

ポリシートークン

より複雑なシナリオでは、管理者はデータをある場所からキャプチャして別の場所に適用できます。NSX Advanced Load Balancer では、この目的で使用できる変数とトークンの使用がサポートされています。

変数を使用して、HTTP 要求および HTTP 応答ポリシーのヘッダーの変更アクションに動的データを挿入できます。$client_ip と $vs_port の 2 つの変数がサポートされています。たとえば、HTTP 要求に origin_ip という新しいヘッダーを追加し、値を $client_ip に設定して、クライアントのソースアドレスをヘッダーの値として挿入できます。

トークンを使用して、HTTP ホスト名またはパスの特定の部分を検索して並べ替えることができます。たとえば、元の要求 http://support.avinetworks.com/docs/index.htm を http://www.avinetworks.com/support/docs/index.htm に書き換えることができます。トークンは、HTTP ホストおよび HTTP パスに使用できます。トークンは元の URL から取得されます。Host ヘッダーのトークン区切り文字は「.」で、URL パスでは「/」になります。

例 1


元の要求 URL：	サポート	avinetworks	com	docs	index.htm
トークン：	host[0]	host[1]	host[2]	path[0]	パス [1]

上記の例では、クライアント要求は HTTP ホストと HTTP パスに分類されています。ホストとパスの各セクションは、ホストとパスの区切り文字「.」および「/」に従ってさらに分類されます。ホストまたはパストークンは、ヘッダー、ホスト、またはパスを書き換えるアクションで使用できます。この例では、 http://www.avinetworks.com/support/docs/index.htm のリダイレクトは要求を docs.avinetworks.com/support/docs/index.htm に送信します。

host[0]、host[1]、host[2] の規則を使用するだけでなく、コロンを使用して、システムがホストまたはパスの最後まで継続する必要があるかどうかを示すことができます。たとえば、host[1:] は avinetworks を使用し、その後にさらにホストフィールドが続くことを意味します。結果は avinetworks.com となります。これは、多くのレベルを含む可能性のあるパスで特に便利です。トークンは、path[2:5] などの範囲を指定することもできます。ホストトークンとパストークンは、「h」および「p」のように省略することができます（たとえば h[1:] および p[2]）。

URL の書き換え、リダイレクト、および Location ヘッダーの書き換えアクションでは、URL のホストコンポーネントをトークンの観点から指定できます。トークンには、既存のホストおよび URL のパスコンポーネントの定数文字列またはトークンがあります。

例 2

新しい URL：region.avinetworks.com/france/paris/index.htm


要求 URL	paris	france	avinetworks	com	region	index.htm
トークン：	host[0]	host[1]	host[2]	host[3]	path[0]	パス [1]
新しいホスト：	path[0].host[2:]
新しいパス：	/host[1]/host[0]/path[1]

Example 3


要求 URL	www1	avinetworks	com	sales	foo	index.htm	auth=true
トークン：	host[0]	host[1]	host[2]	path[0]	パス [1]	path[2]	（クエリ）
新しいホスト：	www.host[1:]
新しいパス：	/host[0]/path[0:]
クエリ：	クエリを有効のままにする
新しい URL：	www.avi.com/www1/sales/foo/index.htm?auth=true

ホストヘッダーに FQDN ではなく IPv4 アドレスが含まれていて、URL の書き換えまたはリダイレクトアクションがホストトークンを参照している場合（たとえば、host[0]、host[1,2] などなど）、ルールアクションはスキップされ、次のルールが評価されます。
Host ヘッダーまたはパスに含まれるトークン数が、アクションで参照されているトークンよりも少ない場合、ルールアクションはスキップされます。たとえば、Host ヘッダーのホスト名にトークンが 3 つしかない場合（ホスト名が www.avinetworks.com で、トークンの host[0] が www、host1 が avinetworks、host2 が com）を考えます。アクションが host[4] を参照している場合、ルールアクションはスキップされます。
HTTP 応答の Location ヘッダーに IPv4 アドレスが含まれ、応答ポリシーアクションがホストトークンを参照する Location ヘッダーを書き換えると、ルールアクションはスキップされます。
ルールエンジンは、ホストアドレスの 8 進数または 16 進数の IPv4 アドレスを認識しません。つまり、Host ヘッダーに 8 進数または 16 進数の IPv4 アドレスがあり、アクションが host1 などのホストトークンを参照している場合、ルールアクションはスキップされません。
複数の Host ヘッダーを持つ HTTP 要求を受信すると、最初の Host ヘッダーが使用されます。
RFC に従って、HTTP 1.1 要求には空でない Host ヘッダーが必要です。空のヘッダーが見つかると、NSX Advanced Load Balancer から 400 「要求が正しくありません」という HTTP 応答が返されます。
HTTP 処理は、デコードされた URI に対して実行されます。

ポリシーでの正規表現の一致

NSX Advanced Load Balancer では、ポリシーアクションで使用できるトークンとして正規表現キャプチャを使用できます。これらの正規表現キャプチャは、ポリシーで構成された一致ルールの URI と一致する正規表現パターン文字列から取得されます。

正規表現の一致とトークンを構成する手順は次のとおりです。

URI 一致に使用する正規表現パターンのリストを含む文字列グループオブジェクトを作成します。正規表現トークンを生成するために必要な正規表現キャプチャ（括弧内の文字列パターン）の使用に注意してください。
[テンプレート] > [グループ] > [文字列グループ] の順に移動します。[CREATE] をクリックします。文字列の名前とタイプを指定します。

[ポリシー] で、[基準] フィールドに [正規表現パターン一致] が選択された一致ルールを作成し、必要な文字列グループを添付します。

正規表現キャプチャを、対応するアクションルールのトークンとして使用できるようになりました。GUI では、SG_RE[] を使用してこれらのトークンにアクセスできます。これらのトークンは、要求パスと一致した文字列グループリストの最初の文字列から取得されます。
クエリ文字列からの正規表現キャプチャは、必要なキャプチャグループにインデックスを付けるために SG_RE_Q を使用してアクションルールからアクセスできます。

例

正規表現文字列：^/hello/(.*)/world/(.*)$

要求パス：/hello/foo/world/bar


正規表現	要求パス	トークン	新しいパス	新しいパス
^/hello/	/hello/		SG_RE[0]/SG_RE[1] /	/foo/bar /
(.*)	/foo/	SG_RE[0]
/world/	/world/
(.*)$	bar	SG_RE[1]

注意事項と制限

正規表現の一致では、文字列グループのみが使用されます。
正規表現の一致には、最大 10 個のキャプチャグループを含めることができます。

一致	クライアントの IP アドレス：クライアントの IP アドレスまたはクライアントアドレスのグループ。「-」を使用して範囲を指定します：10.0.0.0-10.1.255.255。「/」を使用してネットマスクを指定します：10.0.0.0/24。事前定義された IP グループを使用します。これは位置情報に基づいて設定できます。注： IPv6 アドレス形式のクライアント IP アドレスも使用できます。
	サービスポート：仮想サービスが待機しているポート。
	プロトコルタイプ：HTTP または HTTPS。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	HTTP メソッド：クライアント要求によって使用されるメソッド。管理者が指定したいずれかのメソッドが true の場合、一致は true になります。使用可能なオプションは、`GET`、`HEAD`、`POST`、`PUT`、`DELETE`、`OPTIONS`、`TRACE`、および `CONNECT` です。`PATCH`、`PROPFIND`、`PROPPATCH`、`MKCOL`、`COPY`、`MOVE`、`LOCK`、`UNLOCK` の追加オプションから選択することもできます。
	HTTP バージョン：クライアントのバージョンが 0.9、1.0、または 1.1 の場合は true
	パス：パスまたはパスのグループ。RFC 3986 に従って、パスは空であるか、スラッシュで始まります。HTTP 要求一致ポリシーの `beginswith` および `equals` 一致演算子の場合は、一致文字列をスラッシュで始めて一致させる必要があります。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2 では、パスは /marketing/index.html です。
	クエリ：クエリまたはクエリのグループ。先頭の「?」または「&」文字を一致に追加しないでください。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
	ヘッダー：ヘッダーが存在する場合、またはヘッダーが存在し、指定された値が含まれている場合は true。
	Cookie：Cookie が存在する場合、またはヘッダーが存在し、指定された値が含まれている場合は true。
	Host ヘッダー：要求の Host ヘッダー。例：https://www.avinetworks.com/marketing/index.html?a=1&b=2
アクション	リダイレクト URL：クライアントを別のプロトコル、ポート、ホスト、またはパスにリダイレクトします。デフォルトでは、管理者がこれらのフィールドに入力しない限り、ホスト、パス、およびクエリは変更されません。パスフィールドには、先頭にスラッシュ文字「/」は必要ありません。HTTP から HTTPS への簡単なリダイレクトを作成するには、プロトコルを HTTPS に設定します。注：リダイレクトアクションは、他のアクションと一緒にスタックすることはできません。
	ヘッダーの変更：HTTP ヘッダーまたは Cookie の追加、置き換え、または削除を許可します。注：フィールド [機密性が高い] は、ヘッダーの変更アクション内に追加され、機密性の高いカスタム値をマスクします。
	URL の書き換え：ProxyPass 機能と同様に、このアクションにより、クライアントが要求した URL がサーバが理解できる URL に書き換えられます。たとえば、クライアントが www.avinetworks.com/sales を使用した場合、サーバはこれを sales.avinetworks.com に構成できます。パスフィールドには、先頭にスラッシュ文字「/」は必要ありません。
	コンテンツスイッチ：一致した要求をプール、またはそのプールを持つ特定のサーバに転送します。または、NSX Advanced Load Balancer は HTTP 状態コード 200（成功）、403（認証が必要です）、404（ファイルが見つかりません）、または 429（要求が多すぎます）を使用して HTTP 応答を処理できます。これらの状態コードごとにデフォルトのページが送信されるか、カスタム HTML ファイルがアップロードされます。注：あらゆるタイプのファイルをローカル応答としてアップロードできます。ローカルファイルを構成するにはユーザーインターフェイスを使用することが推奨されます。API を使用してローカルファイルを更新するには、base64 ファイルをアウトオブバンドでエンコードし、エンコードした形式を API で使用します。