LSLB | ファーム | 更新 | HTTP プロファイル

カテゴリを表示

LSLB | ファーム | 更新 | HTTP プロファイル

所要時間

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

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

右上のセクションには 2 つのインジケーターがあります。 ボタンと ステータス.
四角い箱: クリックすると、LSLB ファームが停止します。
更新ボタン: クリックすると、ファームが再起動します。
再生ボタン: ファームがオフまたは非アクティブな場合は、クリックすると起動します。

以下に説明する各色は、 ステータス 与えられた 農場:
グリーン: 農場が UP すべてのバックエンドが実行されています。リダイレクトが設定されている可能性もあります。
レッド: 農場が ダウン または機能しません。
ブラック: を示す CRITICAL 損害。通常、ファームが稼働しているが、利用可能なバックエンドがない場合、またはメンテナンス モードになっている場合に発生します。
: があるときに表示されます 問題少なくとも 1 つのバックエンドがダウンしている場合でも、ファームは実行されている可能性があります。
オレンジ: を表します メインテナンス ファームは実行されているが、少なくとも 1 つのバックエンドがメンテナンス モードになっている場合に表示されます。

これらのカラーコードは、グラフィカルユーザーインターフェース全体で共通です。LSLBファームセクションで、これらのカラーコードに関する簡潔な説明をご覧ください。

HTTP(S)ファームプロファイルでは、HTTPヘッダーのX-Forwarded-Forには、デフォルトでクライアントのIPアドレスが入力されます。

リバースプロキシと同様に、各HTTP(S)ファーム(または仮想サービス)は複数のサービスを管理するため、1つのHTTP仮想IPアドレスとポート番号の組み合わせで、複数のロードバランシングされたWebサービスを処理できます。そのため、 HTTPファーム内には「サービス」と呼ばれるセクションがあり、仮想ホストの柔軟性を提供し、各サービスに対してバックエンドのリストを作成できます。

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

基本設定 #

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

名前。これは農場を容易に識別できる名前です。農場の名前を変更するには、まずその農場を停止する必要があります。新しい名前が既に使われていないことを確認してください。

仮想IPアドレスとポート番号。これらは、ファームが着信接続を待機する仮想IPアドレスとポート番号の組み合わせです。新しいIPアドレスとポート番号の組み合わせは、設定前に未使用で利用可能である必要があります。

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

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

HTTPSパラメータ #

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

    このオプションを有効にすると、SSL LabsでA+評価を獲得できるほど強力なセキュリティが実現します。

  • カスタムセキュリティこのコマンドを使用すると、 カスタム暗号 フィールド。
  • カスタム暗号このコマンドを使用すると、SSL接続時に許可または禁止する特定の暗号をカスタマイズできます。これは、 OpenSSL暗号 このコマンドは、 カスタムセキュリティ 設定されています。
  • SSL オフロードこのオプションを有効にすると、プロセッサが許可する場合、AES暗号をハードウェアでオフロードできます。これにより、SSL暗号化/復号化タスクのパフォーマンスを最適化できます。

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

有効な証明書。このリストでは、ファームで現在使用されている証明書を管理します。上下二重矢印を使用して証明書を上または下に移動したり、すべて無効にしたりできます。証明書の順序に注意してください。ホスト証明書より前にワイルドカード証明書を設定した場合、ワイルドカードが先に使用されます。

詳細設定 #

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

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

  • 標準HTTPリクエスト標準 HTTP リクエスト (GET、POST、HEAD)。
  • + 拡張HTTPリクエスト. 拡張 HTTP リクエスト (PUT、DELETE)。
  • + オプション HTTP 動詞. 拡張 HTTP リクエスト (PUT、DELETE)。
  • + 標準 WebDAV 動詞標準 WebDAV 動詞 (LOCK、UNLO​​CK、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 Continue を無視します。チェックされている場合、100 Continueプロパティは無効になります。HTTP 1.1 プロトコルによれば、このヘッダーが送信されると、フォーム データは最初のリクエストとともに送信されません。代わりに、このヘッダーは Web サーバーのバックエンドに送信され、100 (Continue) で応答します。これは、サーバーがリクエスト ヘッダーを受信し、クライアントがリクエスト ボディの送信に進む必要があることを意味します (ボディを送信する必要があるリクエストの場合。たとえば、POST リクエスト)。リクエスト ボディが大きい場合、不適切なヘッダーに基づいてリクエストがすでに拒否されているときにサーバーに送信するのは非効率的です。リクエスト ヘッダーのみに基づいてリクエストを受け入れることができるかどうかをサーバーにチェックさせるには、クライアントは最初のリクエストでExpect: 100-continue をヘッダーとして送信し、続行する前に応答で 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アドレスとポート経由で配信するためのコンテンツスイッチング機能を提供します。これにより、 Webアプリケーションを単一のドメインで統合し、仮想ホストURLリダイレクト永続性、およびサービスごとのバックエンドを管理できます。LSLBファーム内の各サービスには、さまざまなプロパティ、ヘルスチェック、永続性、ヘッダー管理、およびバックエンドリストがあります。正規表現を使用して、リクエストごとに使用するサービスを指定する条件に一致させることができます。

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

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

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

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

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

仮想ホストURLパターンの値は正規表現です。空欄の場合は、任意の値が一致します。両方のフィールドが一致しない場合は、次のサービスに進みます。少なくとも1つは使用することをお勧めします。下部に一致するものが検出されない場合、デフォルトとして機能します。

Location ヘッダーを書き換えます。有効にすると、サービスはクライアントからの応答でLocationおよびContent-locationヘッダーを変更するように強制されます。これらのヘッダーの値がバックエンド自体または VIP (ただしプロトコルが異なる) である場合、応答はリクエスト内の仮想ホストを表示するように変更されます。トグル ボタンを有効にしてバックエンドを比較すると、バックエンド IP アドレスのみが比較されます。これは、HTTP リスナーと同じサーバー上の HTTPS リスナーにリクエストをリダイレクトする場合に不可欠です。[有効化してバックエンドを比較] を選択すると、[ Location ヘッダーの書き換えのパスを有効にする]というフラグが使用可能になります。 [URL の書き換え]を使用している場合は、このフラグを有効にしてください。この値を有効にすると、URL 応答をチェックし、 [URL の書き換え]でルールが設定されている場合は応答を元のものに変更します。このフィールドを有効にすると、グローバル セクションの同じディレクティブが上書きされます。

リダイレクト #

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

リダイレクトの種類。リダイレクトには「デフォルト」「追加」の2種類があります。「デフォルト」タイプでは、URLがリダイレクト先の絶対ホストとパスとして使用されます。「追加」タイプでは、元のリクエストパスが指定したホストとパスに追加されます。

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

リダイレクトコード。リダイレクトHTTPコードには、301(恒久的な移動)、302(一時的な移動)、307(一時的なリダイレクト)など、いくつかの種類があります。

固執 #

永続性。このパラメータは、HTTPサービスがクライアントセッションをどのように管理するか、また安全なクライアントセッションを維持するためにどのHTTP接続を制御する必要があるかを定義します。永続性セッションの種類を選択すると、その有効期間(TTL、秒)が表示されます。

  • 持続性なしファーム サービスはクライアント セッションを制御しません。HTTP または HTTPS 要求は実際のサーバーに配信されます。
  • IP: クライアントアドレスクライアント IP アドレスは、実際のサーバーを介してクライアント セッションを開いたままにするために使用されます。
  • BASIC: 基本認証HTTP 基本認証ヘッダーは、クライアント セッションを制御するために使用されます。たとえば、Web ページがクライアントから基本認証を要求すると、HTTP ヘッダーには次のような文字列が含まれます。
    		HTTP/1.1 401 認証が必要です サーバー: HTTPd/1.0 日付: 土、27 年 2011 月 10 日 18:15:XNUMX GMT
    		WWW 認証: 基本領域 = "セキュア領域"
    		コンテンツタイプ: text/HTML コンテンツの長さ: 31
    

    次に、クライアントは次のヘッダーで応答します。

                    GET /private/index.html HTTP/1.1 ホスト: localhost
    		認証: 基本 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値) 持続セッションの存続時間(TTL)
  • クッキー: . HTTPヘッダーから読み取るHTTP Cookie変数を選択し、それを使用して一定時間クライアントセッションを維持できます。 永続セッション識別子 フィールドはプログラマーによって作成され、クライアント セッションを識別するために Web ページに埋め込まれます。例:
                    GET /spec.html HTTP/1.1 ホスト: www.example.org
                    クッキー: sessionidexample=75HRSd4356SDBfrte
    

    さらに、永続セッションの Time To Life (TTL) を構成する必要があります。この値は、クライアントとバックエンドが何もアクティビティをしていないときにロード バランサーが保存する時間を管理します。

  • HEADER: リクエストヘッダーHTTP ヘッダーのカスタム フィールドを使用して、クライアント セッションを識別できます。永続セッションの Time To Life と永続セッション ID を構成する必要があります。例:
                   GET /index.html HTTP/1.1 ホスト: www.example.org
                   Xセッション: 75HRSd4356SDBfrte
    

Cookie #

Cookie挿入。この設定が有効になっている場合、ロードバランサーは各レスポンスにバックエンドの適切なキーを持つCookieを作成します。セッションテーブルがクリアされたり、セッションが無効になったりしても、適切なバックエンドが選択されます。この機能により、セッションCookieを作成するために実際のサーバーコードを変更する必要がなくなります。

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

ファームガーディアン #

HTTP ファームは基本的なネイティブのバックエンド ヘルス チェックを提供しますが、アプリケーションの正常性を確保するために、よりスマートなヒューリスティック バックエンド ヘルス チェックを行うには Farmguardian 構成が推奨されます。

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

Farmguardianに関する詳細については、「モニタリング」>>「Farmguardian」セクションをご覧ください。

ファームガーディアンを選択すると、ファームに自動的に適用されることに注意してください。

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

バックエンド #

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

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

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

ALIASバックエンド エイリアス (エイリアスが選択された場合)。
IP指定されたバックエンドの IP アドレス。
PORT現在の実サーバーのポート番号。
TIMEOUTバックエンドが応答するまでの時間。この値は、グローバル バックエンド接続タイムアウトのパラメータを上書きしますが、選択したこのファームに限定されます。
重量現在の実サーバーの重み値。重みが大きいほど、現在のバックエンドに配信される接続数が多くなります。デフォルトでは、重み値 1 が設定されます。使用可能な値の範囲は 1 ~ 9 です。
ステータス。 可能な値は次のとおりです。

  • Upファームが稼働しており、バックエンドは接続を受信する準備ができています。
  • Downファームは稼働しており、サービスはバックエンドが動作していないことを検出しました
  • メンテナンスバックエンドは管理者によって接続の受信準備ができていないとマークされています。このオプションはバックエンドのメンテナンスタスクに役立ちます。
  • 未定義バックエンドのステータスはチェックされていません。

PRIORITY現在の実サーバーの優先度の値。値が小さいほど優先度が高くなります。デフォルトのサービス優先度の値は 1 です。バックエンドに障害が発生すると、サービス優先度が 1 増加します。バックエンドが再び稼働すると、サービス優先度の値は 1 減少します。アクティブなバックエンドには、サービス優先度以下の優先度値が含まれます。
接続制限バックエンドが処理する同時接続の最大数。この値に達すると、バックエンドへの新しい接続はブロックされ、クライアントは HTTP 503 エラーを受け取ります。

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

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

URLを書き換える #

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

このセクションでは、URLリクエストがHTTPプロキシエンジンによって解析され、URLリクエストがパターンに一致する場合、設定された置換正規表現を使用してURLリクエストがクライアントに送信されます。バックエンドからロードバランサーが応答を受信すると、Rewrite Location Headerが「Enable path for Rewrite location Headers」の値でサービスに対して有効になっている場合にのみ、実際のURLへの変更が行われます。

例えば、Pattern に値/media/(.+)$が設定され、Replace に値/svc1/$1が設定されている場合、クライアントリクエスト https://vhost.domain.com/media/console は、値 https://vhost.domain.com/svc1/console とともにバックエンドに送信されます。

HTTPファームのIPDSルール #

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

zevenet ipds ビュー

IPDS ルールの 4 種類 (ブラックリスト、DoS、WAF、RBL) それぞれについて、利用可能と有効の 2 つのテーブルがあります。チェーン アイコンもあります。利用可能テーブルでは、利用可能なルールはすべて同じ種類であり、特定のファームに適用できることがわかります。有効テーブルでは、選択したファームに適用されているルールが同じ種類であることがわかります。また、各ルールにはステータス シンボルがあり、ルールが停止(赤色)か実行中(緑色)かを示します。

各ルールには編集アイコンをクリックすることでアクセスでき、ルールパラメータの変更やルールの開始/停止を行うことができます。このファームビュー内では新しいルールを作成することはできません。新しいルールはIPDSセクションから変更してください。

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

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

付属品 #

HTTPSリダイレクトの設定がいかに簡単かを知るには、ビデオをご覧ください。 RELIANOID.

📄 この文書をPDF形式でダウンロードする #

    EMAIL: *

    BetterDocsによって提供されています