Oracle Cloud Infrastructureドキュメント

Load Balancerのルール・セット

ロード・バランサのリスナーのトラフィックに適用されるアクションで構成されるルール・セットを使用します。

ルール・セットとは、ロード・バランサに関連付けられ、そのロード・バランサ上の1つ以上のリスナーに適用されるルールの名前付きセットです。ルール・セットをリスナーに適用するには、最初に、ルールが含まれるルール・セットを作成します。ルールは、ロード・バランサ・リスナーでトラフィックに適用されるアクションを表すオブジェクトです。ルール・セットは、ロード・バランサの構成の一部になります。ロード・バランサのリスナーを作成または更新するときに、使用するルール・セットを指定できます。

ルール・セットには、次のタイプのルールを含めることができます:

ノート

ルール・セットは、HTTPリスナーにのみ適用されます。

リスナーの編集時に、既存のルール・セットを適用します。同じロード・バランサ上の複数のリスナーに同じルール・セットを適用できます。

ロード・バランサ間でルール・セットが共有されていません。別のロード・バランサで同じルール・セットを使用するには、そのロード・バランサに同一のルール・セットを新しく作成する必要があります。

ルール・セットでは最大20のルールを使用できます。最大50のルールをロード・バランサに関連付けることができます。

次のパス・ルート・セット管理タスクを実行できます:

ロード・バランサ・リスナーの管理の詳細は、ロード・バランサのリスナーを参照してください。

アクセス制御ルール

アクセス制御ルールでは、ユーザー指定のIPアドレスまたはアドレス範囲の一致条件に基づいてアプリケーション・リソースへのアクセスを許可します。アクセス制御ルールを指定しない場合、デフォルト・ルールではすべてのトラフィックが許可されます。アクセス制御ルールを追加すると、ロード・バランサによって、ルールと一致しないトラフィックはすべて拒否されます。

このサービスは、一致条件について、Classless Inter-Domain Routing (CIDR)形式(x.x.x.x/yまたはx:x::x/y)の文字列のみを受け入れます。

すべての受信トラフィックと一致させるには、0.0.0.0/0または::/0を指定してください。

ノート

IPv6値は、US Government Cloudリージョンでのみ許可されます。

アクセス方法ルール

アクセス方法ルールでは、関連付けられたリスナーで許可されるHTTPメソッドを指定します。ロード・バランサは、許可されていないリクエストをバックエンド・サーバーに転送せず、許可されたメソッドのリストとともに405 Method Not Allowedレスポンスを返します。許可されたメソッドの1つのリストのみを、指定したリスナーに関連付けることができます。

デフォルトでは、HTTPメソッド・レジストリで定義されている標準HTTPメソッドのみを指定できます。HTTPメソッドのリストは拡張可能です。カスタムHTTPメソッドを構成する必要がある場合は、My Oracle Supportに問い合せてテナンシから制限を削除してください。バックエンド・アプリケーションは、指定されたメソッドを処理できる必要があります。

次のリストは、デフォルトのHTTPメソッドを示しています:

デフォルトのHTTPメソッド

ACL

BASELINE-CONTROL

BIND

CHECKIN

CHECKOUT

CONNECT

COPY

DELETE

GET

HEAD

LABEL

LINK

LOCK

MERGE

MKACTIVITY

MKCALENDAR

MKCOL

MKREDIRECTREF

MKWORKSPACE

MOVE

OPTIONS

ORDERPATCH

PATCH

POST

PRI

PROPFIND

PROPPATCH

PUT

REBIND

REPORT

SEARCH

TRACE

UNBIND

UNCHECKOUT

UNLINK

UNLOCK

UPDATE

UPDATEREDIRECTREF

VERSION-CONTROL

URLリダイレクト・ルール

URLリダイレクト・ルールにより、受信HTTPリクエストを別の宛先URLにルーティングする方法を指定します。URLリダイレクト・ルールは、HTTPリスナーにのみ適用されます。特定のリスナーおよび指定したパスに対して各リダイレクト・ルールを構成します。リスナーは、特定の受信URLパスに対して1つのリダイレクト・ルールのみを保持できます。

URLリダイレクト・ルールを作成する場合、サービスがリダイレクト用の受信URLの評価に使用するパス文字列と一致条件を指定します。リダイレクトURLとレスポンス・コードも定義します。

受信パス文字列の評価

受信URLで評価するパス文字列(パターン)を指定します。例:

/video

また、リダイレクト用の受信URLを評価するときに適用する一致条件も指定します。使用可能な一致タイプは次のとおりです:

  • FORCE_LONGEST_PREFIX_MATCH

    システムでは、受信URLパスの開始部分が最適に最長一致するリダイレクト・ルール・パス文字列を検索します。

  • EXACT_MATCH

    受信URLパスは、指定されたパス文字列と完全に一致する必要があります。

  • PREFIX_MATCH

    受信URLパスの開始部分は、指定されたパス文字列と完全に一致する必要があります。

  • SUFFIX_MATCH

    受信URLパスの終了部分は、指定されたパス文字列と完全に一致する必要があります。

ノート

受信URLパス文字列に問合せを含めることはできません。

リダイレクトURLの構成

元のリクエストに適用されるリダイレクトURLを定義します。URLリダイレクト・ルールでは、次のURLコンポーネントが認識されます:

<protocol>://<host>:<port>/<path>?<query>

リテラル文字列を指定することも、任意のコンポーネントにトークンを指定することもできます。トークンは、受信HTTPリクエストURLから値を抽出します。トークンでは大/小文字が区別されます。たとえば、{host}は有効なトークンですが、{HOST}は無効です。

  • プロトコル

    リダイレクトURLで使用するHTTPプロトコル。有効な値はHTTPおよびHTTPSです。

    {protocol}トークンは、受信HTTPリクエストURLからプロトコルを抽出します。これは、このプロパティで唯一の有効なトークンです。

  • ホスト

    リダイレクトURLで使用する有効なドメイン名またはIPアドレス。

    {host}トークンは、受信HTTPリクエストURLからホストを抽出します。このプロパティでは、すべてのURLリダイレクト・トークンが有効です。任意のトークンを複数回使用できます。

    このプロパティでは、中カッコ{}はトークンを囲む場合にのみ有効です。

  • ポート

    リダイレクトURLで使用する通信ポート。有効な値には、1から65535までの整数が含まれます。

    {port}トークンは、受信HTTPリクエストURLからポートを抽出します。これは、このプロパティで唯一の有効なトークンです。

  • パス

    リダイレクトURLで使用するHTTP URLパス。リダイレクトURLからパスを省略するには、この値を空の文字列に設定します。

    {path}トークンは、受信HTTPリクエストURLからパス文字列を抽出します。このプロパティでは、すべてのURLリダイレクト・トークンが有効です。任意のトークンを複数回使用できます。

    パス文字列が{path}トークンで開始していない場合、スラッシュ/で開始する必要があります。

  • 問合せ

    リダイレクトURLで使用する問合せ文字列。リダイレクトURLからすべての受信問合せパラメータを省略するには、この値を空の文字列に設定します。

    {query}トークンは、受信HTTPリクエストURLから問合せ文字列を抽出します。このプロパティでは、すべてのURLリダイレクト・トークンが有効です。任意のトークンを複数回使用できます。

    問合せ文字列が{query}トークンで開始していない場合、疑問符で開始する必要があります。

    複数の問合せパラメータを単一の文字列として指定できます。各問合せパラメータはアンパサンド&で区切ります。

    指定した問合せ文字列のリダイレクトURLが?または&で終了する場合、最後の文字は切り捨てられます。たとえば、受信URLがhttp://host.com:8080/documentsで、問合せプロパティの値が?lang=en&{query}の場合、リダイレクトURLはhttp://host.com:8080/documents?lang=enになります。最後のアンパサンド&は、受信URLに{query}トークンを置換する値が含まれていないため、切り捨てられます。

重要

少なくとも1つのURLコンポーネント・フィールドに値を指定しないと、リダイレクト・ループが発生する可能性があります。

リダイレクトURLの手動構成

コンソールには、各URLコンポーネントのテキスト入力フィールドがあります。リダイレクトURL全体を手動で指定することもできます。

リダイレクトURLのパスおよび問合せプロパティに値を指定すると、トークンのリテラル文字を保持できます。バックスラッシュ\は、文字\、{、}のエスケープ文字として使用してください。たとえば、受信HTTPリクエストURLが/videoの場合、パス・プロパティ値の/example{path}123\{path\}は、リダイレクトURLでは/example/video123{path}として構成されます。

パスおよび問合せ文字列の例を示します:

  • /example/video/123は、リダイレクトURLでは/example/video/123と表示されます。

  • /example{path}は、受信HTTPリクエストURLで/video/123がパスである場合、リダイレクトURLでは/example/video/123と表示されます。

  • {path}/123は、受信HTTPリクエストURLで/example/videoがパスである場合、リダイレクトURLでは/example/video/123と表示されます。

  • {path}123は、受信HTTPリクエストURLで/example/videoがパスである場合、リダイレクトURLでは/example/video123と表示されます。

  • /{host}/123は、受信HTTPリクエストURLでexample.comがホスト名である場合、リダイレクトURLでは/example.com/123と表示されます。

  • /{host}/{port}は、受信HTTPリクエストURLでexample.comがホスト名、123がポートである場合、リダイレクトURLでは/example.com/123と表示されます。

  • /{query}は、受信HTTPリクエストURLで問合せがlang=enである場合、リダイレクトURLでは/lang=enと表示されます。

  • lang=en&time_zone=PSTは、リダイレクトURLではlang=en&time_zone=PSTと表示されます。

  • {query}は、受信HTTPリクエストでlang=en&time_zone=PSTが問合せ文字列である場合、リダイレクトURLではlang=en&time_zone=PSTと表示されます。受信HTTPリクエストに問合せパラメータが含まれない場合、{query}トークンは空の文字列としてレンダリングされます。

  • lang=en&{query}&time_zone=PSTは、受信HTTPリクエストでcountry=usが問合せ文字列である場合、リダイレクトURLではlang=en&country=us&time_zone=PSTと表示されます。受信HTTPリクエストに問合せパラメータが含まれない場合、この値はlang=en&time_zone=PSTとしてレンダリングされます。

  • protocol={protocol}&hostname={host}は、受信HTTPリクエストでプロトコルがhttp、ホスト名がexample.comである場合、リダイレクトURLではprotocol=http&hostname=example.comと表示されます。

  • port={port}&hostname={host}は、受信HTTPリクエストURLでポートが8080、ホスト名がexample.comである場合、リダイレクトURLではport=8080&hostname=example.comと表示されます。

レスポンス・コード

受信リクエストがリダイレクトされたときに返されるHTTPステータス・コードを指定できます。標準HTTP仕様によるリダイレクトに有効なレスポンス・コードは次のとおりです:

  • 301 Moved Permanently

  • 302 Found

  • 303 See Other

  • 307 Temporary Redirect

  • 308 Permanent Redirect

デフォルト値は302 Foundです。

リクエストおよびレスポンス・ヘッダー・ルール

リクエストおよびレスポンス・ヘッダー・ルールは、HTTPリクエストまたはレスポンス・ヘッダーを追加、変更または削除します。これらのルールは、メタデータをバックエンド・サーバーに渡して次のようなことをする際に役立ちます:

  • リクエストを送信したリスナーを識別します。

  • SSL終了についてバックエンド・サーバーに通知します。

ルール・セットでサイト・セキュリティを強化する方法の例を示します:

  • ヘッダーを追加して、外部ドメインがサイトをインラインフレーム化することを防止します。

  • バックエンド・サーバーによって送信された"Server"などのデバッグ・ヘッダーを削除します。このアクションは、バックエンドの実装詳細を隠蔽するために役立ちます。

  • "strict-transport-security"ヘッダーを適切な値とともにレスポンスに追加します。このヘッダーは、サイトへのアクセスがHTTPSのみであることを保証するために役立ちます。

  • "x-xss-protection"ヘッダーを適切な値とともに追加します。このヘッダーは、最新のブラウザに組み込まれたクロスサイト・スクリプティング(XSS)保護を強制するために役立ちます。

  • "x-content-type"ヘッダーを適切な値とともに追加します。このヘッダーは、コンテンツ・タイプのシフトに基づく攻撃を防止するために役立ちます。

ノート

組込みのホスト・ヘッダーやHTTP X-ヘッダーと説明されているX-ヘッダーのいずれかを追加または削除しても、ヘッダー値は削除もオーバーライドもされません。かわりに、これらのアクションを実行することで、他の値を追加したり、ヘッダーを複製したりできます。

例: ロード・バランサがSSLを終了したことをWebLogicに通知する

SSLターミネーションを実行するようにロード・バランサを構成できます。通常は、バックエンド・アプリケーションでこのアクションを通知する必要があります。たとえば、HTTPS WebLogic E-Commerceのオンライン・トランザクション処理では、WL-Proxy-SSLヘッダーを検索して、リクエストがSSL経由で送信されたことを確認します。ルール・セットを使用して、このヘッダーをロード・バランサ・リスナーに追加できます。

ノート

セキュリティー上の理由から、WebLogicの管理コンソールで WebLogic Plugin Enabledボックスを選択しないかぎり、WebLogicはこのヘッダーを無視します。

  1. 次の設定でルール・セットを作成します。詳細は、ルール・セットの作成を参照してください。

    • 「アクション」リストから「リクエスト・ヘッダーの追加」オプションを選択します。

    • ヘッダーの名前としてWL-Proxy-SSLと入力します。

    • ヘッダーの値を設定します:

      • ロード・バランサがSSL終了を実行するように構成されている場合は、この値をtrueに設定します。

      • SSL終了ポイントがプラグインを実行するWebサーバーにある場合は、この値をfalseに設定します。

  2. リスナーを作成するか、既存のリスナーを編集して、新しいルール・セットを追加します。詳細は、「リスナー」を参照してください。

HTTPヘッダー・ルール

HTTPヘッダー・ルールでは、HTTPヘッダーのサイズ、およびヘッダー内で許可する文字を指定します。

  • HTTPヘッダー・ルールのHTTPヘッダー・バッファ・サイズは、HTTPクライアント・リクエスト・ヘッダーおよびバックエンド・サーバー・レスポンスの読取りに使用されるバッファのサイズをデフォルトの8KBから最大64KBに増やします。バッファはオーバーフロー制御に使用されます。各リクエストまたはレスポンスのヘッダー行はこのバッファに収まる必要があります。したがって、大きいHTTPヘッダー行を使用するアプリケーションでは、このパラメータをチューニングする必要があります。
  • HTTPヘッダー・ルール「HTTPヘッダーで無効な文字を許可」を使用すると、HTTPヘッダーに数字、ハイフンおよびアンダースコアを含めることができます。

HTTPヘッダー・ルールの実装の詳細は、ルール・セットの作成を参照してください。

最大リスナー接続ルール

最大リスナー接続ルールを使用すると、すべてのIPアドレスに統一された最大数のリスナー接続の両方を適用でき、また、識別する個々のIPアドレスのその均一値に対するオーバーライドも指定できます。

  • 特定の最大値が設定されていないすべてのIPアドレスに適用されるデフォルトの最大接続値を設定できます。このデフォルトの最大値を設定しない場合、IPがリスナーに対して行うことができる接続数に制限はありません。

  • デフォルトの最大接続値をオーバーライドする1つ以上のIPアドレスの最大値を設定することもできます。

最大リスナー接続ルールの実装の詳細は、「ルール・セットの作成」を参照してください。