ライブラリ」＞「認証」のページでは、認証サーバーを設定し、クライアント側のBasicまたはForms、サーバー側のNTLMまたはBASICのオプションで認証ルールを作成することができます。
認証の設定 - ワークフロー
お客様のサービスに認証を適用するために、最低限以下の手順を実行してください。
1. Authentication Serverの作成。
2. 認証サーバーを使用する認証ルールを作成します。
3. 認証ルールを使用するflightPATHルールを作成します。
4. flightPATHルールのサービスへの適用
認証サーバー
動く認証方法を設定するには、まず認証サーバーを設定する必要があります。
· Add Server "ボタンをクリックします。
· このアクションにより、完成に向けて空白の行が作成されます。
|
オプション
|
説明
|
|
名前
|
サーバーを識別するための名前を付けます。この名前はルールで使用されます。
|
|
説明
|
説明文の追加
|
|
認証方法
|
認証方法の選択
LDAP - ユーザー名とパスワードを平文でLDAPサーバーに送信する基本的なLDAP。
LDAP-MD5 - 基本的なLDAPで、ユーザー名は平文、パスワードはMD5でハッシュ化され、セキュリティが強化されています。
LDAPS - LDAP over SSL。ADCとLDAPサーバー間の暗号化トンネル内でパスワードを平文で送信します。
LDAPS-MD5 - LDAP over SSL。ADCとLDAPサーバー間の暗号化されたトンネル内で、パスワードをMD5ハッシュ化してセキュリティを強化します。
|
|
ドメイン
|
LDAPサーバーのドメイン名を入れてください。
|
|
サーバーアドレス
|
認証サーバーのIPアドレスまたはホスト名の追加
LDAP - IPv4アドレスまたはホスト名。
LDAP-MD5 - ホスト名のみ（IPv4アドレスでは動作しません
LDAPS - IPv4アドレスまたはホスト名。
LDAPS-MD5 - ホスト名のみ（IPv4アドレスは動作しません）。
|
|
ポート
|
デフォルトでは、LDAPに389番ポート、LDAPSに636番ポートを使用します。LDAPおよびLDAPSのポート番号を追加する必要はありません。他の方法が利用可能になった場合は、ここで設定できるようになります
|
|
検索条件
|
検索条件はRFC4515に準拠する必要があります。例
(MemberOf=CN=Phone-VPN,CN=Users,DC=mycompany,DC=local)となっています。
|
|
検索ベース
|
この値は、LDAPデータベースでの検索の開始点となります。
例 dc=mycompany,dc=local
|
|
ログイン形式
|
必要なログイン形式をご利用ください。
ユーザー名 - このフォーマットを選択すると、ユーザー名のみを入力する必要があります。ユーザーが入力したユーザー情報やドメイン情報はすべて削除され、サーバーのドメイン情報が使用されます。
ユーザー名とドメイン - ユーザーは、ドメインとユーザー名の構文をすべて入力する必要があります。例： mycompany\gchristie OR someone@mycompany.サーバーレベルで入力されたドメイン情報は無視されます。
Blank - ADCは、ユーザーが入力したものをすべて受け入れて、認証サーバーに送信します。このオプションは、MD5 を使用する場合に使用します。
|
|
パスフレーズ
|
このオプションは、本バージョンでは使用されていません。
|
|
デッドタイム
|
このバージョンでは使用されていません
|
認証ルール
次の段階では、サーバー定義で使用する認証ルールを作成します。
|
フィールド
|
説明
|
|
名前
|
認証ルールの適切な名前を追加します。
|
|
説明
|
適切な説明を追加します。
|
|
ルートドメイン
|
サブドメイン間でのシングルサインオンが必要な場合を除き、この項目は空白にしておく必要があります。
|
|
認証サーバー
|
このドロップダウンボックスには、設定済みのサーバーが表示されます。
|
|
クライアント認証。
|
お客様のニーズに合った値をお選びください。
Basic (401) - この方法では、標準の401認証方式を使用します。
Forms - これは、ADCのデフォルトフォームをユーザーに表示します。フォームの中には、メッセージを追加することができます。以下のセクションで、アップロードしたフォームを選択できます。
|
|
サーバー認証
|
適切な値を選択してください。
None - サーバーに既存の認証機能がない場合は、この設定を選択します。この設定は、以前は何もなかったサーバーに、認証機能を追加できることを意味します。
Basic - サーバーで基本認証（401）が有効になっている場合は、「BASIC」を選択します。
NTLM - お使いのサーバーでNTLM認証が有効になっている場合は、「NTLM」を選択します。
|
|
フォーム
|
適切な値を選ぶ
Default - このオプションを選択すると、ADCは内蔵のフォームを使用します。
カスタム - 自分でデザインしたフォームを追加して、ここで選択することができます。
|
|
メッセージ
|
フォームに個人的なメッセージを追加します。
|
|
タイムアウト
|
ルールにタイムアウトを追加すると、それ以降はユーザーの再認証が必要になります。タイムアウトの設定は、フォームベースの認証でのみ有効です。
|
シングルサインオン
ユーザーにシングルサインオンを提供する場合は、Root Domainの欄にドメインを記入します。この例では、edgenexus.ioを使用しています。edgenexus.ioをルートドメインとする複数のサービスを用意すれば、ユーザーは一度だけログインすればよいことになります。以下のようなサービスを考えてみましょう。
· Sharepoint.mycompany.com
· usercentral. mycompany.com
· appstore.mycompany.com
これらのサービスは、1つのVIPに存在することも、3つのVIPに分散して存在することも可能です。usercentral.mycompany.com に初めてアクセスしたユーザーは、使用した認証ルールに応じてログインを求めるフォームが表示されます。同じユーザーがappstore.mycompany.comに接続すると、ADCによって自動的に認証されます。タイムアウトを設定することができ、このタイムアウト時間に達すると、強制的に認証が行われます。
フォーム
このセクションでは、カスタムフォームをアップロードすることができます。
カスタムフォームの作成方法
ADCが提供する基本フォームはほとんどの目的には十分ですが、企業がユーザーに独自のアイデンティティを提示したい場合もあるでしょう。そのような場合にユーザーに入力してもらうためのカスタムフォームを作成することができます。このフォームは、HTM形式またはHTML形式のいずれかでなければなりません。
|
オプション
|
説明
|
|
名前
|
フォーム名 = loginform
action = %JNURL% です。
メソッド＝POST
|
|
ユーザー名
|
構文: name = "JNUSER"
|
|
パスワードです。
|
name="JNPASS"
|
|
任意のメッセージ1:
|
%JNMESSAGE%。
|
|
任意のメッセージ2:
|
%jnauthmessage%。
|
|
イメージ
|
画像を追加したい場合は、Base64エンコーディングを使用してインラインで追加してください。
|
非常に基本的でシンプルなフォームのhtmlコード例
<HTML>
<HEAD
<title>sample auth form</title>
</HEAD>。
<BODY>
%JNMESSAGE%<br>。
<form name="loginform" action="%JNURL%" method="post"> USER: <input type="text" name="JNUSER" size="20" value=""></br>。
PASS：<input type="password" name="JNPASS" size="20" value="></br>。
<input type="submit" name="submit" value="OK">。
</form>。
</b> </b> </b> </b
</HTML>
カスタムフォームの追加
カスタムフォームを作成したら、「フォーム」セクションを使って追加することができます。
1. フォームの名前を決める
2. あなたのフォームをローカルにブラウズする
3. アップロードをクリック
カスタムフォームのプレビュー
アップロードしたばかりのカスタムフォームを表示するには、フォームを選択して「プレビュー」をクリックします。このセクションでは、不要になったフォームを削除することもできます。
キャッシュ
ADCは、内部メモリ内にデータをキャッシュすることができ、このキャッシュを定期的にADCの内部ストレージにフラッシュします。この機能を管理するための設定をこのセクションで説明します。
グローバルキャッシュの設定
最大キャッシュサイズ(MB)
この値は、Cache が消費する最大の RAM を決定します。ADC キャッシュはメモリ内キャッシュであり、再起動、リブート、およびシャットダウン操作後もキャッシュの永続性を維持するために定期的にストレージ媒体にフラッシュされます。この機能は、最大キャッシュサイズがアプライアンスのメモリーフットプリント（ディスクスペースではなく）内に収まる必要があり、利用可能なメモリーの半分以下であることを意味します。
希望のキャッシュサイズ（MB
この値は、キャッシュを切り詰めるための最適な RAM を示します。最大キャッシュサイズは、キャッシュの絶対的な上限を示しますが、希望キャッシュサイズは、キャッシュサイズの自動または手動によるチェックが行われたときに、キャッシュが達成しようとする最適なサイズを意図しています。最大キャッシュサイズと希望キャッシュサイズの間のギャップは、キャッシュサイズを定期的にチェックして期限切れのコンテンツを切り詰める間に、新しいコンテンツが到着したり重なったりすることに対応するために存在します。繰り返しになりますが、デフォルト値（30MB）を受け入れて、「モニター」→「統計」でキャッシュのサイズを定期的に確認し、適切なサイズにすることがより効果的です。
デフォルトのキャッシュタイム (D/HH:MM)
ここで入力された値は、明示的な有効期限のないコンテンツの寿命を表しています。デフォルトのキャッシング時間は、"no-store "ディレクティブやトラフィックヘッダーに明示的な有効期限がないコンテンツが保存される期間です。
つまり、"1/01:01"（デフォルトは1/00:00）と入力すると、ADCは1日分のコンテンツを保持し、"01:00 "は1時間分、"00:01 "は1分分のコンテンツを保持することになります。
キャッシング可能なHTTPレスポンスコード
キャッシュされるデータセットの一つにHTTPレスポンスがあります。キャッシュされるHTTPレスポンスコードは
· 200 - 正常なHTTPリクエストに対する標準的な応答
· 203 - ヘッダーは確定したものではなく、ローカルまたはサードパーティのコピーから収集したものです。
· 301 - リクエストされたリソースに新しいパーマネントURLが割り当てられました。
· 304 - 最後のリクエストから変更されていないため、ローカルにキャッシュされたコピーを使用する必要があります。
· 410 - リソースがサーバーで利用できなくなり、転送先のアドレスがわからない。
このフィールドは、最も一般的なキャッシュ可能なレスポンスコードがすでにリストアップされているため、注意して編集する必要があります。
キャッシュチェック時間 (D/HH:MM)
この設定は、キャッシュトリム操作の時間間隔を決定します。
キャッシュ・フィル・カウント
この設定は、一定の数の304が検出された場合に、キャッシュを埋めるための補助機能です。
キャッシュルールの適用
ここでは、キャッシュルールをドメインに適用することができます。
· レコードの追加」ボタンでドメインを手動で追加します。その際、完全修飾ドメイン名またはIPアドレスをドットデシマル表記で入力してください。例 www. mycompany.com または 192.168.3.1:80
· ドロップダウン矢印をクリックし、リストからドメインを選択する
· トラフィックが仮想サービスを通過し、仮想サービスにキャッシュ戦略が適用されている限り、このリストは入力されます。
· Caching Rulebase列をダブルクリックして、リストからキャッシュルールを選択します。
キャッシュルールの作成
このセクションでは、いくつかの異なるキャッシングルールを作成して、ドメインに適用することができます。
· レコードの追加」をクリックし、ルールの名前と説明を入力します。
· 条件を手動で入力するか、「条件の追加」を使って
選択ルールベースを使って条件を追加するには
· 含める」または「除外する」を選択
· すべてのJPEG画像を選択
· 追加マークをクリック
· 条件に「include *.jpg」が追加されていることがわかります。
· さらに条件を追加することができます。手動で追加する場合は、各条件を新しい行に追加する必要があります。条件」ボックスをクリックするまでは、ルールは同じ行に表示され、その後は別の行に表示されますのでご注意ください。
フライトパス
flightPATH」は、ADCに搭載されたトラフィック管理技術です。「flightPATH」は、HTTPやHTTPSのトラフィックをリアルタイムに検査し、条件に応じてアクションを実行することができます。
IPオブジェクトをルール内で使用する場合、flightPATHルールをVIPに適用する必要があります。
フライトパスルールは4つの要素で構成されています。
1. Details（詳細）では、flightPATH Name（フライトパス名）とアタッチ先のService（サービス）を定義します。
2. ルールのトリガーとなる条件を定義することができます。
3. アクションの中で使用できる変数を定義することができる評価
4. 条件が満たされたときに起こるべきことを管理するために使用されるアクション
詳細
詳細セクションには、利用可能なflightPATHルールが表示されます。このセクションでは、新しいflightPATHルールを追加したり、定義済みのルールを削除することができます。
新しいflightPATHルールの追加
|
フィールド
|
説明
|
|
フライトパス名
|
このフィールドは、flightPATHルールの名前です。ここで指定した名前は、ADCの他の部分に表示され、参照されます。
|
|
VSに適用
|
この列は読み取り専用で、flightPATHルールが適用されるVIPを示します。
|
|
説明
|
読みやすさのために用意された説明文を表す値。
|
flightPATHルールを追加する手順
1. まず、"Details "セクションにある "Add New "ボタンをクリックします。
2. ルールの名前を入力します。例 Auth2
3. ルールの説明を入力する
4. ルールがサービスに適用されると、[Applied To]列にIPアドレスとポートの値が自動入力されます。
5. 更新ボタンを押して変更内容を保存するのを忘れないでください。間違った場合は、キャンセルボタンを押して以前の状態に戻してください。
状態
flightPATH ルールは任意の数の条件を持つことができます。条件は AND で動作するため、アクションがトリガーされる条件を設定できます。OR条件を使用したい場合は、追加のflightPATHルールを作成し、正しい順序でVIPに適用します。
また、[Check] フィールドで [Match RegEx] を、[Value] フィールドで [RegEx] の値を選択して RegEx を使用することもできます。RegEx の評価が含まれることで、flightPATH の機能が大幅に拡張されます。
flightPATH条件の新規作成
状態
私たちは、ドロップダウン内にあらかじめ定義されたいくつかの条件を提供し、想定されるすべてのシナリオをカバーしています。新しい条件が追加された場合は、Jetpackのアップデートにより利用可能になります。
選択肢は以下の通りです。
|
コンディション
|
説明
|
例題
|
|
<form>（英語
|
HTMLフォームはサーバーにデータを渡すために使われる
|
例 "form doesn't have length 0"
|
|
GEO ロケーション
|
送信元IPアドレスとISO3166の国コードとの比較
|
GEO ロケーションが GB に該当する場合、または GEO ロケーションが Germany に該当する場合
|
|
ホスト
|
URLから抽出したホスト
|
www.mywebsite.com または 192.168.1.1
|
|
言語
|
language HTTPヘッダから抽出した言語
|
この条件では、Languagesのリストを含むドロップダウンが生成されます。
|
|
方法
|
HTTPメソッドのドロップダウン
|
GET、POSTなどを含むドロップダウン
|
|
オリジンIP
|
上流のプロキシがX-Forwarded-For（XFF）をサポートしている場合、真のOriginアドレスを使用します。
|
クライアントIPです。また、複数のIPやサブネットを使用することもできます。
10.1.2.0 /24 subnet
10\.1.2.3|10\.1.2.4 Use | for multiple IP's
|
|
パス
|
ウェブサイトのパス
|
/mywebsite/index.asp
|
|
POST
|
POSTリクエストメソッド
|
Webサイトにアップロードされるデータのチェック
|
|
問い合わせ
|
クエリの名前と値で、クエリ名か値も受け付けることができる
|
"Best=jetNEXUS" マッチはBest、バリューはedgeNEXUSの場合
|
|
問い合わせ文字列
|
? "文字以降のクエリ文字列全体
|
|
|
リクエストクッキー
|
クライアントから要求されたクッキーの名前
|
MS-WSMAN=afYfn1CDqqCDqUD::
|
|
リクエストヘッダー
|
Any HTTP Header
|
リファラー、ユーザーエージェント、From、Date
|
|
リクエストバージョン
|
HTTPバージョン
|
http/1.0またはhttp/1.1
|
|
レスポンスボディ
|
レスポンスボディに含まれるユーザー定義の文字列
|
サーバーアップ
|
|
応答コード
|
応答のHTTPコード
|
200 OK, 304 Not Modified
|
|
レスポンスクッキー
|
サーバーから送られてきたクッキーの名前
|
MS-WSMAN=afYfn1CDqqCDqUD::
|
|
レスポンスヘッダー
|
Any HTTP Header
|
リファラー、ユーザーエージェント、From、Date
|
|
レスポンスバージョン
|
サーバーから送られてきたHTTPバージョン
|
http/1.0またはhttp/1.1
|
|
ソースIP
|
オリジンIP、プロキシサーバーIP、またはその他の集約されたIPアドレスのいずれか
|
ClientIP、ProxyIP、FirewallIP。複数のIPやサブネットを使用することもできます。ドットはRegEXなので必ずエスケープしてください。例 10\\.1\.2\.3 は 10.1.2.3 です。
|
マッチ
一致」フィールドは、ドロップダウンまたはテキスト値のいずれかで、「条件」フィールドの値に応じて定義できます。例えば、ConditionがHostに設定されている場合、Matchフィールドは利用できません。Conditionが<form>に設定されている場合、Matchフィールドはテキストフィールドとして表示され、ConditionがPOSTに設定されている場合、Matchフィールドは適切な値を含むドロップダウンとして表示されます。
選択肢は以下の通りです。
|
MATCH
|
説明
|
例題
|
|
受け入れ
|
許容されるコンテンツタイプ
|
Accept: text/plain
|
|
Accept-Encoding
|
使用可能なエンコーディング
|
Accept-Encoding: <compress | gzip | deflate | sdch | identity>。
|
|
アクセプト・ランゲージ
|
回答に使用できる言語
|
Accept-Language: en-US
|
|
受け入れ範囲
|
このサーバーがサポートしているパーシャルコンテンツの範囲タイプ
|
Accept-Ranges: bytes
|
|
オーソライズ
|
HTTP認証用の認証情報
|
オーソライズされています。基本 QWxhZGRpbjpvcGVuIHNlc2FtZQ==。
|
|
チャージ・トゥー
|
要求された方法の適用にかかるコストの勘定情報を含む
|
|
|
Content-Encoding
|
使用されているエンコーディングの種類
|
Content-Encoding: gzip
|
|
Content-Length
|
レスポンスボディの長さをオクテット（8ビットバイト）で表したもの
|
Content-Length: 348
|
|
コンテンツタイプ
|
リクエストの本文のmimeタイプ（POSTおよびPUTリクエストで使用されます
|
Content-Type: application/x-www-form-urlencoded
|
|
クッキー
|
Set-Cookie（下記）でサーバーから送られてきたHTTPクッキー
|
Cookie: $Version=1; Skin=new;
|
|
日付
|
メッセージが発信された日付と時間
|
Date = "日付" ":" HTTP-date
|
|
ETag
|
リソースの特定のバージョンを示す識別子で、多くはメッセージダイジェストです。
|
ETag:"aed6bdb8e090cd1:0"
|
|
より
|
リクエストを行ったユーザーのEメールアドレス
|
From: user@example.com
|
|
If-Modified-Since
|
コンテンツが変更されていない場合に、304 Not Modifiedを返すことができる。
|
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
|
|
Last-Modified
|
リクエストされたオブジェクトの最終更新日（RFC2822形式）。
|
Last-Modified:Tue, 15 Nov 1994 12:45:26 GMT
|
|
Pragma
|
実装。リクエスト-レスポンスの連鎖のどこかで様々な効果をもたらす可能性のある特定のヘッダー。
|
Pragma: no-cache
|
|
リファラー
|
現在要求されているページへのリンクを辿った前のWebページのアドレス
|
リファラー：HTTP://www.edgenexus.io
|
|
サーバー
|
サーバーの名前
|
サーバーです。Apache/2.4.1 (Unix)
|
|
セット-クーキー
|
HTTPクッキー
|
セット-クーキーUserID=JohnDoe; Max-Age=3600; Version=1
|
|
User-Agent
|
ユーザーエージェントの文字列
|
User-AgentMozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
|
|
Vary
|
下流のプロキシに対して、将来のリクエストヘッダーをどのように照合し、
オリジンサーバーから
新たなレスポンスをリクエストするのではなく、キャッシュされたレスポンスを使用できるかどうかを判断する方法を指示します。
|
Vary:User-Agent
|
|
X-Powered-By
|
Webアプリケーションを支える技術（ASP.NET、PHP、JBossなど）を指定します。
|
X-Powered-By:PHP/5.4.0
|
センス
Senseフィールドはドロップダウン式のブール型フィールドで、DoesまたはDoesn'tの選択肢があります。
チェック
チェックフィールドでは、条件に対するチェック値を設定することができます。
選択できる項目は以下の通りです。Contain、End、Equal、Exist、Have Length、Match RegEx、Match List、Start、Exceed Length
|
CHECK
|
説明
|
例題
|
|
存在する
|
これは、条件の詳細を気にせず、存在するかしないかだけを気にするものです。
|
ホストが存在する
|
|
スタート
|
文字列は、Valueで始まります。
|
パス - Does - Start - /secure
|
|
終了
|
文字列の最後には、Value
|
パス - Does - End - .jpg
|
|
収録内容
|
この文字列には、以下の値が含まれています。
|
リクエストヘッダー - アクセプト - Does - Contain - image
|
|
イコール
|
文字列は「値」に等しい
|
ホスト - Does - Equal - www.jetnexus.com
|
|
長さ
|
文字列は、値の長さを持っています。
|
ホスト - Does - Have Length - 16
www.jetnexus.com = TRUE
www.jetnexus.co.uk = FALSE
|
|
Match RegEx
|
完全なPerl互換の正規表現を入力することができます。
|
Origin IP - Does - Match Regex - 10\...* | 11\...*
|
条件を追加する手順
新しい flightPATH 条件の追加はとても簡単です。その例を上に示します。
1. 条件エリア内の「新規追加」ボタンをクリックします。
2. ドロップダウンボックスから条件を選択します。ここではHostを例に説明します。フィールドに入力することもでき、ADCはドロップダウンで値を表示します。
3. Senseを選ぶ。例えば、Does
4. チェックを選びます。例えば、「Contain
5. 値を選択します。例えば、mycompany.com
上記の例では、ルールが完了するためには、両方ともTRUEでなければならない2つの条件があることを示しています。
· 1つ目は、要求されたオブジェクトが画像であるかどうかを確認することです。
· 2つ目は、URLのホストがwww.imagepool.com であるかどうかをチェックします。
評価
定義可能な変数を追加できるのは魅力的な機能です。通常のADCでは、スクリプトやコマンドラインのオプションを使ってこの機能を提供していますが、これは誰にとっても理想的ではありません。ADCでは、以下に示すように、使いやすいGUIを使って任意の数の変数を定義することができます。
flightPATH変数の定義には、4つのエントリーが必要です。
· Variable - これは変数の名前です。
· Source - ドロップダウンリストに表示されるソースポイント。
· 詳細 - ドロップダウンから値を選択するか、手動で入力します。
· Value - 変数が保持する値で、英数字または微調整用のRegExが使用できます。
内蔵変数。
組み込み変数はすでにハードコードされているので、これらのために評価エントリを作成する必要はありません。
アクション "セクションでは、以下のような変数が使用できます。
各変数の説明は、上の「条件」の表にあります。
· メソッド = $method$
· パス = $path$
· クエリストリング = $querystring$
· Sourceip = $sourceip$
· レスポンスコード（テキストには "200 OK "も含まれる） = $resp$
· ホスト = $host$
· バージョン = $version$
· クライアントポート = $clientport$
· Clientip = $clientip$
· ジオロケーション = $geolocation$"
|
ACTION
|
TARGET
|
|
アクション = リダイレクト 302
|
ターゲット = HTTPs://$host$/404.html
|
|
アクション＝ログ
|
ターゲット = $sourceip$:$sourceport$のクライアントが$path$ページをリクエストしました。
|
説明します。
· 存在しないページにアクセスすると、通常はブラウザの404エラーページが表示されます。
· 代わりに、ユーザーが使用した元のホスト名にリダイレクトされますが、不正なパスは404.htmlに置き換えられます。
· Syslogに "A client from 154.3.22.14:3454 has just requested the wrong.html page "というエントリが追加されます。
アクション
プロセスの次の段階では、flightPATHルールと条件に関連するアクションを追加します。
この例では、ユーザーが入力したURLを反映させるために、URLのパス部分を書き換えます。
· 新規追加」をクリックします。
· アクション」ドロップダウンメニューから「パスの書き換え」を選択します。
· ターゲット」欄に「$path$/myimages」と入力します。
· アップデートをクリック
このアクションでは、パスに/myimagesが追加されるので、最終的なURLはwww.imagepool.com/myimages となります。
flightPATHルールの適用
flightPATHルールの適用は、各VIP/VSのflightPATHタブ内で行われます。
· サービス」→「IPサービス」を選択し、flightPATHルールを割り当てるVIPを選択します。
· 以下のようなReal Serverのリストが表示されます。
· flightPATHタブをクリックします。
· 設定したflightPATHルール、またはサポートされている事前構築済みのルールのいずれかを選択します。必要に応じて複数のflightPATHルールを選択できます。
· 選択したセットを「Applied flightPATHs」セクションにドラッグ＆ドロップするか、>>矢印ボタンをクリックします。
· ルールは右側に移動し、自動的に適用されます。
