投稿日: 25 年 2021 月 XNUMX 日

Contents [show]

HTTPファームプロファイルのグローバル設定

HTTP プロファイルは、HTTP プロトコルと HTTPS プロトコルの両方の OSI モデルのアプリケーション層でコンテンツの切り替えを管理します。受信リクエストの内容を分析し、URL、Cookie、ヘッダー、セッション情報などの特定のパラメーターに基づいてルーティングを決定することで、受信 Web トラフィックを複数のバックエンドリソースにインテリジェントに分散するプロファイルを設計しました。この情報を使用して、トラフィックを適切な (サービス) サーバープールに転送できます。

右上のセクションには 2 つのインジケーターがあります。アクションボタンと状態.

四角い箱: クリックすると、LSLB ファームが停止します。
更新ボタン：クリックするとファームが再起動します。
再生ボタン: ファームがオフまたは非アクティブな場合、クリックすると開始します。

以下に説明する各色は、状態与えられた牧場:

グリーン: 農場が UP すべてのバックエンドが実行されています。リダイレクトが設定されていることを意味する場合もあります。
レッド: 農場が ダウン または機能しない。
ブラック: を示します CRITICAL ダメージ。通常、ファームが稼働しているが利用可能なバックエンドがない場合、またはメンテナンスモードになっている可能性がある場合に発生します。
青: がある場合に表示します。問題。ファームは実行されている可能性がありますが、少なくとも XNUMX つのバックエンドがダウンしている場合があります。
オレンジ: を表します メインテナンス 。ファームは実行中だが、少なくとも XNUMX つのバックエンドがメンテナンスモードである場合を示します。

これらのカラーコードは、グラフィカルユーザーインターフェイス全体で同じです。それらについての簡潔な説明は、 LSLB ファームセクション.

HTTP（S）ファームプロファイルでは、HTTPヘッダー X-転送-についてデフォルトでは、クライアントIPアドレスが入力されます。

リバースプロキシと同様に、各 HTTP(S) ファーム (または仮想サービス) は複数のサービスを管理するため、XNUMX つの HTTP 仮想 IP とポートのペアで、負荷分散された複数の Web サービスを処理できます。したがって、と呼ばれるセクションがあります サービス HTTP ファーム内で仮想ホストの柔軟性を提供し、サービスごとにバックエンドのリストを作成できます。

各 HTTP(S) サービスは、 正規表現 (仮想ホストおよび URL パターンの場合) PCRE で、受信接続の HTTP ヘッダー内の特定のパターンを検索します。パターンが両方で一致する場合、仮想ホスト及び URLパターンフィールドに入力すると、その特定のサービスのバックエンドがそれらの受信接続を処理します。

基本設定

以下は、HTTP/S ファームプロファイルの基本的なパラメーターです。

お名前。農園を識別しやすい名前です。特定のファームの名前を変更するには、まずファームを停止する必要があります。新しい名前がまだ使用されていないことを確認してください。

仮想IPとポート. これらは、ファームが着信接続をリッスンする仮想 IP アドレスとポートのペアです。新しい IP アドレスとポートの組み合わせは、構成する前に未使用で使用可能である必要があります。

リスナー。このフィールドは、コンテンツスイッチングを実行するためのレイヤー 7 プロトコルを指定します。

HTTP。仮想サービスはプレーンな HTTP コンテンツのみを受信します。
HTTPS。仮想サービスは、セキュア HTTP コンテンツを受信し、SSL ハンドシェイクを管理し、セキュアな暗号設定、SSL 証明書 (ワイルドカードまたは SNI) などを処理して、SSL オフロードを実行します。これにより、実際のアプリケーションサーバーはこれらの重いタスクから解放されます。

HTTPSパラメータ

HTTPSパラメータ 以下見つけることができます。

SSLV2を無効にする, SSLV3を無効にする, TLSV1を無効にする, TLSV1.1を無効にする, TLSV1.2を無効にする。これらの各トグルボタンは、関連付けられた SSL または TLS バージョンを有効または無効にします。いずれかのプロトコルを無効にすると、それに関連付けられた暗号も無効になるため、お勧めできません。

暗号。このセクションでは、SSL 接続を強化するために使用する暗号のリストを作成します。クライアントとサーバーは、TLS プロトコルで保護された情報の交換を開始する前に、データの暗号化時に使用する暗号化キーと暗号を安全に交換または合意する必要があります。

使用する暗号を構成するには、次のオプションのいずれかを選択します。

全て。このコマンドを選択すると、リッスンする HTTP(S) ファームが使用可能なすべての暗号スイートを管理します。これがデフォルトの設定です。
高度なセキュリティ. このコマンドは、次の暗号を有効にします。
```
kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED
```
このオプションを有効にすると、セキュリティが十分に強化され、 A+ 成績が上がる SSL研究所 .
カスタムセキュリティ。このコマンドを使用すると、独自の暗号をカスタマイズできます。カスタム暗号フィールド。
カスタム暗号。このコマンドを使用すると、SSL 接続を行うときに特定の暗号を許可または禁止するようにカスタマイズできます。と同じ形式の文字列である必要があります。 OpenSSL暗号 . このコマンドは、次の場合に表示されます。カスタムセキュリティ設定されています。

利用可能な証明書。これらは、デバイスにインストールされている利用可能な SSL 証明書です。それぞれを有効にするには、証明書を選択して矢印ボタンをクリックするか、証明書を [利用可能] ボックスから [有効] ボックスにドラッグアンドドロップします。複数の証明書、またはすべての証明書を有効/無効にすることもできます。

有効な証明書. このリストでは、ファームで現在使用されている証明書を管理します。上下の二重矢印でそれらを上または下に移動したり、すべてを無効にしたりすることもできます。証明書の順序を考慮してください。ホスト証明書の前にワイルドカード証明書を構成する場合、ワイルドカードが最初に使用されます。

詳細設定

Locationヘッダーを書き換える。有効にすると、ファームは強制的に会場及びコンテンツの場所クライアントに応答するヘッダー。それらがバックエンド自体または VIP の値を持ち、異なるプロトコルを使用している場合、応答は要求内の仮想ホストを表示するように変更されます。トグルボタンの場合、バックエンドを有効にして比較するが有効になっている場合、バックエンド IP アドレスのみが比較されます。これは、HTTP リスナーと同じサーバー上の HTTPS リスナーにリクエストをリダイレクトする場合に不可欠です。このフィールドがサービスセクションで設定されている場合、このディレクティブはそのサービスに対して無視されます。

HTTP動詞が受け入れられました。このフィールドは、HTTP クライアント要求を検証するために使用される HTTP メソッドを示します。クライアントのリクエストが許可されない場合は、クライアントにエラーが表示されます。各動詞には、追加の下位レベルの動詞があります。

標準HTTPリクエスト。標準のHTTPリクエスト（GET、POST、HEAD）
+拡張HTTPリクエスト。拡張HTTP要求（PUT、DELETE）
+オプションHTTP動詞。拡張HTTP要求（PUT、DELETE）
+標準WebDAV動詞。標準のWebDAV動詞（LOCK、UNLOCK、PROPFIND、PROPPATCH、SEARCH、MKCOL、MOVE、COPY、OPTIONS、TRACE、MKACTIVITY、CHECKOUT、MERGE、REPORT）。
+ MS拡張WebDAV動詞。 MS拡張WebDAV動詞（SUBSCRIBE、UNSUBSCRIBE、NOTIFY、BPROPFIND、BPROPPATCH、POLL、BMOVE、BCOPY、BDELETE、CONNECT）。
+ MS RPC拡張動詞。 MS RPC拡張動詞（RPC_IN_DATA、RPC_OUT_DATA）。

100を無視する。チェックすると、 100続行 プロパティは無効になります。 HTTP 1.1プロトコルによると、このヘッダーが送信されると、フォームデータは最初のリクエストで送信されません。代わりに、このヘッダーは100で応答するWebサーバーバックエンドに送信されます（続行）。これは、サーバーがリクエストヘッダーを受信し、クライアントがリクエスト本文の送信に進む必要があることを意味します（本文を送信する必要があるリクエストの場合、たとえばPOSTリクエスト）。リクエストの本文が大きい場合、不適切なヘッダーに基づいてリクエストがすでに拒否されているときにサーバーに送信するのは非効率的です。リクエストのヘッダーのみに基づいてリクエストを受け入れることができるかどうかをサーバーに確認させるには、クライアントは送信する必要があります期待：100継続最初のリクエストのヘッダーとして、続行する前に100 Continueステータスコードを受信したかどうかを確認します（または417 Expectation Failedを受信して続行しません）。

ログ。ファームトラフィックログを有効または無効にして、ロードバランサを通過するものをデバッグおよび分析します。

バックエンド接続タイムアウト. この値は、ファームがバックエンドへの接続を待機する必要がある時間を秒単位で示します。通常はソケットオープン待ち時間となります。デフォルトでは、この値は 20 秒に設定されます。

復活したバックエンドをチェックする頻度. これは、ロードバランサーがバックエンドに到達可能かどうかを確認し、ブラックリストに登録されている実サーバーが稼働している場合はそれを取得するために待機する頻度です。新しいクライアント接続があるかどうかに関係なく、実サーバーが停止しているとマークされると、ファームはバックエンドを定期的にチェックします。デフォルトでは、この値は 10 秒に設定されます。

バックエンドの応答タイムアウト. この値は、ファームがバックエンドからの応答を待機する必要がある時間を秒単位で示します。デフォルトでは、この値は 45 秒に設定されます。

クライアント要求タイムアウト. この値は、ファームがクライアントの要求を待機する必要がある時間を示します。クライアントからデータを取得せずにこのタイムアウトに達すると、接続が終了します。デフォルトでは、この値は 30 秒に設定されます。

HTTPエラーメッセージ

パーソナライズされたエラーメッセージ。実サーバーから Web コードエラーが検出されると、ファームサービスはサイトにカスタムメッセージを表示します。エラーコード 414、500、501、および 503 については、パーソナライズされた HTML ページが表示されます。

414：リクエスト-URIが長すぎます。これは、URI が許可される最大文字数に達した場合の HTTP/S プロファイルによるエラーメッセージです。このエラーが発生した場合は、URL の長さを短くしてください。
500内部サーバーエラー. これは、バックエンドで予期しないコマンドが発生した場合の HTTP/S プロファイルによるエラーメッセージです。
501：実装されていません. これは、要求動詞がプロキシまたはバックエンドによって管理または認識されていない場合の HTTP/S プロファイルによるエラーメッセージです。
503：サービスを利用できません. これは、プロキシがリクエストに使用できるバックエンドを見つけられない場合の HTTP/S プロファイルによるエラーメッセージです。これは、すべてのバックエンドまたはサーバーがダウンしている場合、またはリクエストの正規表現が構成されたサービスと一致しない場合に発生する可能性があります。
WAF 403：禁止. これは、WAF が有効で、WAF エンジンがリクエストを拒否した場合の HTTP/S プロファイルによるエラーメッセージです。

ヘッダ

このセクションでは、リクエストヘッダーとレスポンスヘッダーをグローバルに追加、変更、削除し、構成されているすべてのサービスにアクションを適用できます。サービスセクションでヘッダーが設定されている場合、その設定は破棄されます。

このセクションで使用するアクションは次のとおりです。

ルールを作成. グローバルヘッダールールが作成されます。
削除. グローバルヘッダールールが削除されます。

このセクションでは、追加、変更、または作成することができます ヘッダ 下の画像に示すように、リクエストとレスポンス。

種類.

リクエスト：ヘッダーを削除。クライアントのHTTPリクエストから削除されるヘッダーパターン。
リクエスト：ヘッダーを変更する。クライアントのHTTPリクエストからヘッダーを変更します。
リクエスト：ヘッダーを追加. クライアントの HTTP 要求に追加されるヘッダー。
応答：ヘッダーを削除。バックエンドHTTP応答から削除されるヘッダーパターン。
応答：ヘッダーを変更してください。バックエンドHTTP応答からヘッダーを変更します。
応答：ヘッダーを追加. バックエンド HTTP 応答に追加されるヘッダー。

サービス設定

HTTP プロファイルを持つ LSLB ファーム内のサービスは、Web 仮想サービスにコンテンツスイッチング機能を提供し、複数の Web サービスとアプリケーションを 同じ仮想IPとPORT。これは Webアプリケーションを統一する 単一のドメインを通じて、 仮想ホストを管理する, URLを管理する, リダイレクトを設定する, サービスごとの永続性とバックエンドを設定する。 LSLB ファーム内の各サービスには、さまざまなプロパティ、ヘルスチェック、永続性、ヘッダー管理、およびバックエンドリストがあります。正規表現を使用して、リクエストごとに使用するサービスを指定する条件を一致させることができます。

各サービス一致条件は、優先モード (必要に応じて変更可能) で HTTP ファームプロファイルコアによってチェックされます。一致するサービスがない場合、ファームコアはエラー (HTTP エラー 503) を返します。このため、特定の複数サービスの定義が許可されています。 URL とホストのフィールドが定義されていない場合、すべてのリクエストが一致します。 HTTP サービス条件は、仮想ホストおよび/または URL パターンによって決定されます。

まず、少なくとも XNUMX つのバックエンドサーバーを作成してサービスに追加することが必要です。新しいサービスが適用されると、HTTP サービスはリストの順序で上から下に評価されます。ホストおよび/または URL フィールドで一致する最初のサービスがリクエストを処理します。これらのサービス条件は、URL またはホストパターンによって決定されます。

一致するサービス条件は次のとおりです。

仮想ホスト。この機能を使用すると、HTTP ファーム内の同じ仮想 IP とポートを使用して、ドメイン名に基づいて条件を定義できます。この条件を削除したい場合は、フィールドを空のままにすることができます。このフィールドでは、PCRE 形式の正規表現がサポートされています。

URLパターン。このフィールドの目的は、クライアントが要求している URL パスに基づいて Web サービスを識別することです。 URL は指定されたパターンに対して評価され、その構文が正しいかどうかが確認されます。この条件を無視したい場合は、フィールドを空のままにすることができます。このフィールドでは PCRE 形式の正規表現がサポートされており、高度なパターンマッチングが可能です。

仮想ホスト及び URLパターン値は正規表現です。空のままにすると、任意の値が一致します。両方のフィールドが一致する必要があります。そうでない場合、次のサービスにスキップします。下部に一致が検出されない場合のデフォルトとして、少なくとも XNUMX つを使用することをお勧めします。

Locationヘッダーを書き換える。有効にすると、サービスは強制的に変更されます会場及びコンテンツの場所クライアントに応答するヘッダー。それらがバックエンド自体または VIP の値を持っている場合 (ただし、プロトコルが異なる場合)、応答は要求内の仮想ホストを表示するように変更されます。トグルボタンの場合バックエンドを有効にして比較するが有効になっている場合は、バックエンド IP アドレスのみが比較されます。これは、HTTP リスナーと同じサーバー上の HTTPS リスナーにリクエストをリダイレクトする場合に不可欠です。バックエンドの有効化と比較が選択されると、フラグが呼び出されます位置ヘッダーの書き換えのパスを有効にする使えるようになる。で作業している場合は、このフラグを有効にします URLを書き換える. この値により、URL 応答の確認が強制され、ルールが構成されている場合は元の応答に変更されます。 URLを書き換える. このフィールドを有効にすると、グローバルセクションの同じディレクティブが上書きされます。

リダイレクト

サービスでリダイレクトオプションが有効になっている場合、すべてのリクエストが指定された URL に送信されるため、バックエンドサーバーが使用されない場合があります。

リダイレクトタイプ. 次の XNUMX つのリダイレクトタイプがあります。デフォルト及び追加。とともにデフォルト URL は、リダイレクト先の絶対ホストおよびパスとして取得されます。とともに追加を入力すると、元のリクエストパスがホストと指定したパスに追加されます。

リダイレクトURL. このパラメーターは、要求が応答された後にクライアントがリダイレクトされる場所を制御します。クライアント要求は、新しい URL にリダイレクトすることによって自動的に応答されます。リダイレクト値を設定すると、 バックエンドを構成しないでください このサービスで。もし仮想ホストと URLパターン一致すると、アプライアンスは HTTP 場所ヘッダー設定されたURLにリダイレクトされるためにクライアントへの応答。

リダイレクトコード. いくつかのリダイレクト HTTP コードを使用できます: 301 (完全に移動)、302 (一時的に移動)、または 307 (一時的なリダイレクト)。

固執

固執. このパラメーターは、HTTP サービスがクライアントセッションを管理する方法と、安全なクライアントセッションを維持するためにどの HTTP 接続を制御する必要があるかを定義します。持続性セッションのタイプを選択すると、その Time To Live TTL(秒) が表示されます。

持続性なし. ファームサービスは、クライアントセッションを制御しません。 HTTP または HTTPS リクエストは実サーバーに配信されます。
IP：クライアントアドレス. クライアント IP アドレスは、実サーバーを介してクライアントセッションを開いたままにするために使用されます。
基本：基本認証. HTTP 基本認証ヘッダーは、クライアントセッションを制御するために使用されます。たとえば、Web ページがクライアントからの基本認証を要求する場合、HTTP ヘッダーには次のような文字列が含まれます。
```
		HTTP/1.1 401 Authorization Required
		Server: HTTPd/1.0
		Date: Sat, 27 Nov 2011 10:18:15 GMT
		WWW-Authenticate: Basic realm="Secure Area"
		Content-Type: text/HTML
		Content-Length: 31
```
それからクライアントはヘッダで答えます：
```
                GET /private/index.html HTTP/1.1
		Host: localhost
		Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
```
この基本認証文字列は、クライアントセッションを識別するためのセッションのIDとして使用されます。
PARM: URI パラメータ。クライアントセッションを識別する別の方法は、ユーザーセッション識別子として使用されるセミコロン文字から分離されたURIパラメータを使用することです。例では http://www.example.com/private.php;EFD4Y7 パラメータはセッション識別子として使用されます。
URL：リクエストパラメータ. セッション ID が URL とともに GET パラメーターを介して送信される場合、このパラメーターは、クライアントセッション ID に関連付けられた名前が可能であることを示します。たとえば、次のようなクライアント要求 http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 パラメータで設定する必要があります持続セッション識別子 (この例では sid 値) 持続性セッションの Time to Life (TTL)
クッキー： . HTTP ヘッダーから読み取る HTTP Cookie 変数を選択し、それを使用して一定時間クライアントセッションを維持できます。で構成された Cookie 名 持続性セッション識別子 フィールドはプログラマによって作成され、クライアントセッションを識別するために Web ページに埋め込まれます。次に例を示します。
```
                GET /spec.html HTTP/1.1
                Host: www.example.org
                Cookie: sessionidexample=75HRSd4356SDBfrte
```
さらに、永続セッションの存続時間 (TTL) を構成する必要があります。この値は、クライアントとバックエンドにアクティビティがない場合にロードバランサーが節約する時間を管理します。
HEADER: リクエストヘッダー. HTTP ヘッダーのカスタムフィールドを使用して、クライアントセッションを識別することができます。永続セッションの Time To Life と永続セッション ID を設定する必要があります。例えば：
```
               GET /index.html HTTP/1.1
               Host: www.example.org
               X-sess: 75HRSd4356SDBfrte
```

クッキーインサート。定義されている場合、ロードバランサーは クッキー バックエンドの適切なキーを使用して、各応答で。セッションテーブルがフラッシュされたり、セッションが無効になったりしても、適切なバックエンドが選択されます。この機能により、実際のサーバーコードを変更してセッション Cookie を作成する必要がなくなります。

Cookie Name 作成され、クライアントリクエスト/バックエンドレスポンスに追加される Cookie の名前。のクッキーパス新しい Cookie が作成される URI または相対パスです。ドメイン全体に対して、文字を設定する必要があります。クッキードメインクッキーが作成されるドメインです。最後に、クッキーTTL は、Cookieがクライアントとバックエンドの間でメモリに保持される秒数です。このフィールドは0より大きくなければなりません。そしてこの時間はアクティビティのない時間に関連しています。アクティビティなしで指定された秒数を読み取った後、永続化セッションは削除されます。

農場の守護者

HTTP ファームは、基本的でネイティブなバックエンドヘルスチェックを提供しますが、アプリケーションが正常であることを確認するためのよりスマートなヒューリスティックバックエンドヘルスチェックには、Farmguardian 構成をお勧めします。

いくつかの組み込みまたはカスタマイズされた高度なヘルスチェックは、すでに作成されたファームガードチェックからこのサービスに割り当てることができます。

Farmguardianの詳細については、監視>>ファームガードのセクションから無料でダウンロードできます。

農場の保護者を選択すると、自動的に農場に適用されます。

HTTPSバックエンド. このチェックボックスは、現在のサービスで定義されているバックエンドサーバーが HTTPS プロトコルを使用しているため、データが送信前に暗号化されることをファームに示します。

バックエンド

また、バックエンド、HTTP ファームプロファイルでは、次のプロパティを構成できます。すべてのバックエンドは IPv4 または IPv6 で、ファーム VIP と同じ IP バージョンである必要があります。

ACTIONS. バックエンドを管理するには、次のアクションを使用します。
すでに作成されているバックエンドの場合：

メンテナンスを有効にする. バックエンドが以前に無効化されていた場合は、このアクションを使用します。実サーバーを保守モードにすることは、新しい接続がそのサーバーにリダイレクトされないことを意味します。メンテナンスモードを有効にするには、次の XNUMX つの方法があります。
- 排水モード。有効な場合、確立された接続と持続性を保持しますが、新しい接続を許可しません。
- カットモード。バックエンドに対してすべてのアクティブな接続を切断します
メンテナンスを無効にする. バックエンドがメンテナンスモードの場合は、このアクションを使用します。メンテナンスモードを無効にした後、実サーバへの新しい接続を再度有効にします。
削除. 選択した仮想サービスの構成を削除します。エイリアスが存在する場合、エイリアスは削除されません。

ALIAS。別名が選択されている場合は、バックエンド別名。
IP. 特定のバックエンドの IP アドレス。
PORT. 現在の実サーバーのポート番号。
TIMEOUT. バックエンドが応答するのにかかる時間。この値は、グローバルなバックエンド接続タイムアウトのパラメーターをオーバーライドしますが、この選択されたファームに限定されます。
重量. 現在の実サーバーの重み値。重みが大きいほど、現在のバックエンドに配信される接続が多いことを示します。デフォルトでは、重み値 1 が設定されます。使用可能な値の範囲は 1 ～ 9 です。
PRIORITY. 現在の実サーバーのプライオリティ値。値が小さいほど優先度が高くなります。デフォルトのサービス優先度値は 1 です。バックエンドに障害が発生すると、サービス優先度は 1 増加します。バックエンドが再び稼働すると、サービス優先度値は 1 減少します。アクティブなバックエンドには、サービス優先度以下の優先度値が含まれます。 .
接続制限. バックエンドが処理する同時接続の最大数。この値に達すると、バックエンドへの新しい接続がブロックされ、クライアントは HTTP 503 エラーを受け取ります。

バックエンドフォームを追加します。

スルーアクションメニューボタンをクリックすると、選択した XNUMX つ以上のバックエンドに対して次のアクションを使用できます。
バックエンドを追加します。このコマンドは、バックエンド作成フォームを開きます。
上記のアクション: メンテナンスを有効にする (ドレイン及びカットモード）、メンテナンスを無効にする及び削除.

URLを書き換える

パターンをチェックして URL から文字列を取得し、置換します。いくつかの構成を追加できます。 URL の書き換えフェーズを終了する最後のフラグが設定されていない限り、それらはすべて着信 URL に順次適用され、他の Rewrite URLs パターンは評価されません。

このセクションでは、URLリクエストがHTTPプロキシエンジンによって分析され、URLリクエストが パターン 次に、URLリクエストがクライアントに送信されます。 交換する 正規表現が構成されています。ロードバランサーがバックエンドから応答を受信すると、値が次のサービスに対してRewrite Location Headerがアクティブ化された場合に備えて、実際のURLへの変更が行われます。 位置ヘッダーの書き換えのパスを有効にする.

たとえば、Patternが値で構成されている場合 /メディア/(.+)$ 値に置き換えます / svc1 / $ 1、クライアントリクエストhttps://vhost.domain.com/media/consoleは、値https://vhost.domain.com/svc1/consoleでバックエンドに送信されます

HTTPファームのIPDS規則

このセクションではIPDSルールを有効にします。リストには、さまざまな種類の保護とそれらを有効にするための選択ボックスが表示されます。詳細については IPDS >>ブラックリストルール, IPDS >> DoSルール, IPDS >> RBLルール or IPDS >> WAFルール特定のドキュメント

ブラックリスト、DoS、WAF、および RBL の XNUMX 種類の IPDS ルールのそれぞれについて、Available および enabled という XNUMX つのテーブルがあります。鎖のアイコンもあります。利用可能なテーブルの下に、利用可能なすべてのルールが同じ種類のものであり、特定のファームに適用できることがわかります。有効なテーブルに関しては、選択したファームに適用されるルールが同じタイプであることがわかります。ルールが停止しているかどうかを示す各ルールのステータスシンボルもあります。 （赤色） 色または実行中かどうか （緑色）.

編集アイコンをクリックすると、各ルールにアクセスできます。これにより、ルールパラメータを変更したり、ルールを開始/停止したりできます。このファームビュー内で新しいルールを作成することはできません。を通じてそれを変更します IPDS のセクションから無料でダウンロードできます。

ルールを追加するには、目的のルールをクリックしてから、右の一重矢印をクリックします。または、Shift キーを同時に押しながら、追加するルールを選択することで、複数のルールを選択できます。次に、右の一重矢印をクリックします。右二重矢印をクリックして、利用可能なすべてのブラックリストを追加することもできます。

XNUMXつ以上のルールを削除するには、それらを選択して左矢印をクリックするか、二重矢印をクリックしてすべてを削除します。