ローカル管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.2
スタンドアロン Content Engine に おける従来のキャッシング サービスの 設定
スタンドアロン Content Engine における従来のキャッシング サービスの設定
発行日;2012/02/02 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

スタンドアロン Content Engine に

従来のキャッシング サービスの設定の概要

スタンドアロン Content Engine における HTTP キャッシングの設定

スタンドアロン Content Engine における非透過 HTTP フォワード プロキシ キャッシングの設定

HTTP キャッシュ新鮮度の設定

認証済み HTTP キャッシュの設定

再認証の間隔の指定

HTTP 認証キャッシュ設定の表示

認証されたコンテンツのキャッシングの有効化

HTTP認証キャッシュ統計情報の表示

スタンドアロン Content Engine における透過 HTTP フォワード プロキシ キャッシングの設定

スタンドアロン Content Engine に対する標準 Web キャッシュ サービス(サービス 0)の設定

スタンドアロン Content Engine に対するカスタム Web キャッシュ サービス(サービス 98)の設定

スタンドアロン Content Engine における HTTP リバース プロキシ キャッシングの設定

スタンドアロン Content Engine における HTTPS キャッシングの設定

HTTPS クライアント要求の SSL 終了について

HTTPS クライアント要求のトンネリングについて

スタンドアロン Content Engine における HTTPS プロキシ キャッシングの設定

スタンドアロン Content Engine における HTTPS 透過キャッシングの設定

スタンドアロン Content Engine における HTTPS サーバの設定

HTTPS キャッシングに使用する証明書と秘密鍵の設定

HTTPS キャッシングに使用する証明書グループの設定

スタンドアロン Content Engine における HTTPS 発信プロキシ サーバの設定

任意の宛先ポートに対する不要アクセスの防止

スタンドアロン Content Engine における FTP キャッシングの設定

スタンドアロン Content Engine を使用したFTP キャッシングの概要

ネイティブ FTP キャッシングのサポートについて

FTP-Over-HTTP キャッシングのサポートについて

FTP キャッシュ 新鮮度について

ACNS 5.1 および 5.2 ソフトウェアのネイティブ FTPキャッシングに関する制約事項

スタンドアロン Content Engine における ネイティブ FTP キャッシングの設定

スタンドアロン Content Engine における FTP-over-HTTP キャッシングの設定

スタンドアロン Content Engine における TFTP サーバおよびゲートウェイの設定

スタンドアロン Content Engine 上での TFTP サービスおよびゲートウェイの使用

TFTP サーバおよびゲートウェイのイネーブル化

スタンドアロン Content Engine における TFTP サーバおよびゲートウェイの設定

スタンドアロン Content Engine における DNS キャッシングの設定

スタンドアロン Content Engine における DNS キャッシングについて

ドメイン ネーム解決の要件

DNS WCCP 透過代行受信の概要

DNS キャッシング ネーム サービス(サービス 53)用の DNS サーバの設定

スタンドアロン Content Engine に対する DNS キャッシング サービス(サービス 53)の設定

スタンドアロン Content Engine における DNS キャッシングのディセーブル化

永続接続の設定

永続接続のイネーブル化

永続接続のディセーブル化

Content Engine クラスタのヒーリング モードの設定

Content Engine クラスタの Internet Cache Protocol の設定

ICP クライアントとしてのスタンドアロン Content Engine の 設定

ICP サーバとしてのスタンドアロン Content Engine の 設定

スタンドアロン Content Engine に
おける従来のキャッシング サービスの設定

この章では、スタンドアロン Content Engine において従来のキャッシング サービス(HTTP、 FTP、HTTPS または DNS キャッシング)を設定する方法について説明します。 またこの章では、スタンドアロン Content Engine において、TFTP ゲートウェイ、永続接続、ヒーリング モード、および Internet Cache Protocol (ICP) を設定する方法についても説明します。 この章の構成は、次のとおりです。

「従来のキャッシング サービスの設定の概要」

「スタンドアロン Content Engine における HTTP キャッシングの設定」

「スタンドアロン Content Engine における HTTPS キャッシングの設定」

「スタンドアロン Content Engine における FTP キャッシングの設定」

「スタンドアロン Content Engine における TFTP サーバおよびゲートウェイの設定」

「スタンドアロン Content Engine における DNS キャッシングの設定」

「永続接続の設定」

「Content Engine クラスタのヒーリング モードの設定」

「Content Engine クラスタの Internet Cache Protocol の設定」


) この章で使用される CLI コマンドの構文と使用方法については、『 Cisco ACNS Software Command Reference, Release 5.2』を参照してください。 ローカル管理運用におけるメディア キャッシング サービス(WMT キャッシング、RTSP キャッシングおよび ストリーミング サービス)の設定方法については、「スタンドアロンContent Engine上の WMT ストリーミング メディア サービスの設定」および「スタンドアロンContent Engine の RTSP メディア サービスの設定」を参照してください。また、Content Distribution Manager に登録された Content Engine におけるキャッシングの設定方法については、『Cisco 中央管理配置に関する ACNS ソフトウェアコンフィギュレーション ガイド Release 5.2』を参照してください。


従来のキャッシング サービスの設定の概要

ここでは、スタンドアロン Content Engine 上で、Content Engine CLI を使用して従来のキャッシング サービス(HTTP、HTTPS、FTP、および DNS キャッシング)を設定する方法の概要を説明します。 Setup ユーティリティを使用して、一般的に使用されている 3 つの従来のキャッシング サービス(HTTP リバース プロキシ キャッシング、WCCP Version 2 を使用する HTTP 透過キャッシング、および、HTTP フォワード プロキシ キャッシング)を設定する方法については、「Setup ユーティリティを使用したスタンドアロン Content Engine の基本コンフィギュレーション設定」を参照してください。

図 6-1 は、スタンドアロン Content Engine において従来のキャッシング サービスを設定する方法を詳細に示しています。

図 6-1 スタンドアロン Content Engine における従来のキャッシング サービスの設定の詳細

 

表 6-1 は、スタンドアロン Content Engine 上で、Content Engine CLI を使用して従来のキャッシング サービス(HTTP、HTTPS、FTP および DNS キャッシング)を設定する作業のチェックリストです。 このチェックリストには、スタンドアロン Content Engine 上でこれらのサービスを設定する手順も含まれています。

 

表 6-1 スタンドアロン Content Engine における従来のキャッシング サービスの設定のチェックリスト

作業
追加情報および説明
従来のキャッシング サービスの基本設定を開始する
 

1. スタンドアロン Content Engine にクライアント要求を送信する、次のルーティング方式を1つ以上設定する。

直接プロキシ ルーティング(非透過)

透過リダイレクト(WCCP ルーティングまたはレイヤ 4 スイッチング)

直接プロキシ ルーティングについては、「直接プロキシ ルーティングを使用可能にするクライアント ブラウザとメディア プレーヤーの設定」を参照してください。

WCCP ルーティングについては、「WCCP 透過リダイレクションのスタンドアロン Content Engine の設定」を参照してください。

レイヤ 4 スイッチングについては、「リダイレクション方式としての レイヤ 4 スイッチングの設定」を参照してください。

2. 直接プロキシ ルーティングを使用する場合、*.pac ファイルを使用するかどうかを選択する。

使用しない場合、直接プロキシサーバとしてスタンドアロン Content Engine を直接指定するよう、各クライアント ブラウザを手動で設定する。 「クライアント ブラウザをスタンドアロン Content Engine に対して手作業で指向」を参照してください。

使用する場合は、プロキシ自動設定機能(PAC)ファイルを使用するよう、スタンドアロン Content Engine とクライアント ブラウザを設定する。 「PAC ファイルを使用したクライアント ブラウザの直接スタンドアロン Content Engine の指定」を参照してください。

3. スタンドアロン Content Engine 上で、非透過(プロキシ)モード従来方式キャッシングサービスを設定する。

HTTP フォワード プロキシ キャッシング

FTP-over-HTTP キャッシング

HTTPS プロキシ キャッシング

この章の次を参照してください。

「スタンドアロン Content Engine における非透過 HTTP フォワード プロキシ キャッシングの設定」

「スタンドアロン Content Engine における FTP-over-HTTP キャッシングの設定」

「スタンドアロン Content Engine における HTTPS プロキシ キャッシングの設定」

4. スタンドアロン Content Engine について、従来の透過モードキャッシングサービスを設定する。

HTTP リバース プロキシ キャッシング

ネイティブ FTP キャッシング

HTTPS 透過キャッシング

透過 HTTP フォワード プロキシ キャッシング

DNS キャッシング

この章の次を参照してください。

「スタンドアロン Content Engine における HTTP リバース プロキシ キャッシングの設定」

「スタンドアロン Content Engine における ネイティブ FTP キャッシングの設定」

「スタンドアロン Content Engine における HTTPS 透過キャッシングの設定」

「スタンドアロン Content Engine における透過 HTTP フォワード プロキシ キャッシングの設定」

「スタンドアロン Content Engine における DNS キャッシングの設定」

5. これで、次のいずれかの作業を行うことができます。

TFTP サーバおよびゲートウェイの設定を設定する。

永続接続を使用するよう Content Engine を設定する。

キャッシュ クラスタについて、ヒーリング モードまたは ICP を設定する。

Content Engine について、ストリーミング サービスを設定する。

Content Engine について、コンテンツ サービスを設定する。

Content Engine 上で、拡張設定を実施する。

監視およびトラブルシューティングを行う。

この表の作業 6 から 24 を参照してください。

6. Content Engine 上で TFTP サーバおよびゲートウェイを設定する。

「スタンドアロン Content Engine における TFTP サーバおよびゲートウェイの設定」を参照してください。

7. Content Engine 上で永続接続を設定する。

「永続接続の設定」を参照してください。

8. キャッシュ クラスタについて、ヒーリング モードを設定する。

「Content Engine クラスタのヒーリング モードの設定」を参照してください。

9. キャッシュ クラスタについて、Internet Cache Protocol (ICP) を設定する。

「Content Engine クラスタの Internet Cache Protocol の設定」を参照してください。

10. Content Engine 上で WMT キャッシングおよびストリーミング サービスを設定する。

「スタンドアロンContent Engine上の WMT ストリーミング メディア サービスの設定」

11. Content Engine 上で RTSP キャッシングおよびストリーミング サービスを設定する。

「スタンドアロンContent Engine の RTSP メディア サービスの設定」

コンテンツ サービスの設定(オプション)

スタンドアロン Content Engine 上でキャッシングおよびストリーミング サービスを設定した後、アクセス制御や URL フィルタリング、ICAP、および、ルールなどのコンテンツ サービスを設定できます。

従来のキャッシングにおけるコンテンツ サービスの設定
 

12. インターネットへのエンドユーザ アクセスを制御するかどうかを決定する(HTTP、 HTTPS および FTP-over-HTTP 要求についてのアクセス制御)。

必要ない場合は、作業 13 に進む。

制御する場合は、コンテンツの認証と許可を設定する(「スタンドアロンContent Engine のコンテンツ認証および許可の設定」を参照)。

13. URL フィルタリングを使用するかどうかを決定する。

必要ない場合は、作業 14 に進む。

使用する場合は、HTTP、HTTPS および FTP 要求に使用する URL フィルタリングを設定する(「スタンドアロンContent Engine 上での URL フィルタリングの設定」を参照)。

14. 外部 ICAP サーバが存在するかどうかを判断する。

必要ない場合は、作業15.に進む。

存在する場合は、HTTP および FTP-over-HTT 要求に使用する ICAP(Internet Content Adaptation Protocol)を設定する(「スタンドアロンContent Engine の ICAP サービスの設定」を参照)。

15. コンテンツ要求を処理するために特別な要件が必要かどうかを決定する。

必要ない場合は、作業16.に進む。

必要な場合は、HTTP、HTTPS、FTP-over-HTTP、WMT および RTSP 要求に使用するルールを設定する(「スタンドアロンContent Engine の Rules Template の設定」を参照)。

拡張設定作業を実施(オプション)

 

16. 拡張透過キャッシング機能(トラフィック バイパス、過負荷バイパス、フロー保護、IP スプーフィングなど)を設定する。

「スタンドアロンContent Engine の WCCP サービスの設定」

17. スタンドアロン Content Engine 上で追加のネットワーク インターフェイスを設定する。

「スタンドアロンContent Engine での追加のネットワーク インターフェイスと帯域幅の設定」

18. このスタンドアロン Content Engine 上で、インターフェイスおよびコンテンツ サービスの帯域幅を設定する。

「スタンドアロンContent Engine での追加のネットワーク インターフェイスと帯域幅の設定」

19. 設定やモニタリング、トラブルシューティングのために Content Engine にアクセスする管理ユーザについて、ログイン認証および許可を設定する。

「スタンドアロンContent Engine での管理ログイン認証と許可の設定」

20. TACACS+ を使用してアカウンティングを行うシステムについて、このスタンドアロン Content Engine を設定する。

「スタンドアロンContent Engine での AAA アカウンティングの設定」

21. スタンドアロン Content Engine 上で IP アクセス コントロール リスト(ACL)を設定する。

「スタンドアロンContent Engine での IP アクセス コントロール リストの作成と管理」

22. スタンドアロン Content Engine 用の TCP スタック パラメータを確認または変更する。

「スタンドアロンContent Engine での TCP スタック パラメータの表示と変更」

23. スタンドアロン Content Engine についてのシステム ロギング設定を確認または変更する。

「システム ロギング機能の使用」を参照してください。

監視およびトラブルシューティング

 

24. SNMP または ACNS ソフトウェア アラームを使用して、このスタンドアロン Content Engine を監視する。

「モニタリングおよびトラブルシューティング」

25. traceroute や ping などのツールを使用して、問題に対するトラブルシューティングを行う。

「モニタリングおよびトラブルシューティング」

スタンドアロン Content Engine における HTTP キャッシングの設定

HTTP は、Web ブラウザと Web サーバが通信するために Web 上で使用されている、主要なプロトコルです。 現在、2 種類の HTTP バージョンが共通して実装されています(HTTP 1.0 および HTTP 1.1)。 ACNS 5.x ソフトウェアは、HTTP 1.0 と HTTP 1.1 の両方をサポートしています。

HTTP は、TCP ポート 80(HTTP 用に予約されたポート)上で実行される、要求/応答プロトコルです。 クライアント(Web ブラウザ)は、Web サーバに要求を送り、Web サーバは、コンテンツを返します。 各要求や応答には、クライアントやサーバ、オブジェクトのさまざまなプロパティ、または、クライアントとWeb ブラウザ間の通信状況などを特定する、複数のヘッダーを含まれます。


) HTTP の詳細については、IETF RFC 1945(HTTP 1.0 仕様)および RFC 2616(HTTP 1.1 仕様)を参照してください。


表 6-2 は、ACNS ソフトウェア(リリース 5.2 以降)を実行している Content Engine でサポートされる HTTP キャッシング サービスをリストしています。 サポートされるサービスのタイプは、Content Engine に HTTP 要求をルートする方式によって異なります。

 

表 6-2 スタンドアロン Content Engine でサポートされる HTTP キャッシング サービス

HTTP キャッシング サービス
詳細
直接プロキシ モード

 

非透過 HTTP フォワード プロキシ キャッシング

「スタンドアロン Content Engine における非透過 HTTP フォワード プロキシ キャッシングの設定」を参照してください。

透過リダイレクト モード

 

透過 HTTP フォワード プロキシ キャッシング

「スタンドアロン Content Engine における透過 HTTP フォワード プロキシ キャッシングの設定」を参照してください。

透過 HTTP リバース プロキシ キャッシング

「スタンドアロン Content Engine における HTTP リバース プロキシ キャッシングの設定」を参照してください。

ACNS ソフトウェア リリース 5.1 以前のバージョンでは、最高 8 種類のアクティブ WCCP サービスが、WCCP Version 2 ルータ および Content Engine でサポートされていました。 ACNS 5.2 ソフトウェアは、最高 25 種類のアクティブ WCCP Version 2 サービスをサポートしていますが、現在定義されているのは 17 サービスだけです。 WCCP サービスのリストについては、 表B-3 を参照してください。

スタンドアロン Content Engine における非透過 HTTP フォワード プロキシ キャッシングの設定

Content Engine GUI または CLI を使用して、スタンドアロン Content Engine 上で HTTP プロキシ キャッシングを設定できます(非透過フォワード プロキシ サーバ)。

Content Engine GUI から、 Caching > HTTP Proxy の順に選択し、表示された HTTP Proxy ウィンドウを使用して、HTTP 接続設定を行います。 ウィンドウの使用についての詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から設定する手順は、次のとおりです。


ステップ 1 HTTP 要求を Content Engine に直接送信するよう、クライアント ブラウザを設定します(非透過フォワード プロキシ サーバ)。

これらのブラウザからの HTTP 要求が Content Engine に直接送信されるよう、クライアント ブラウザから Content Engine を直接指定します(直接プロキシ ルーティング)。 プロキシ自動設定機能(PAC ファイル)を使用できます。または、フォワード プロキシ サーバの IP アドレスおよびポート番号を指定することにより、クライアント ブラウザを手作業で設定することもできます。 このトピックに関する詳細は、「直接プロキシ ルーティングを使用可能にするクライアント ブラウザとメディア プレーヤーの設定」を参照してください。

ステップ 2 http proxy incoming port グローバル設定コマンドを使用して、ポート 80 以外のポート上で送信される HTTP 要求を受け取るよう、Content Engine を設定します。

http proxy incoming port

ここで、port は、スタンドアロン Content Engine がクライアント ブラウザから直接 HTTP 要求を受け取るために使用するポート番号です。 この番号の範囲は 1 ~ 65535 です。最高 8つのポートを指定できます。

次の例では、ポート 8080 上で受信 HTTP プロキシを設定します。同じコマンドラインで、最高 8 つの受信プロキシ ポートを設定できます。

ContentEngine(config)# http proxy incoming 8080
 

ステップ 3 必要に応じて、Content Engine における HTTP キャッシュ新鮮度を設定します(「HTTP キャッシュ新鮮度の設定」を参照)。

ステップ 4 必要に応じて、Content Engine における HTTP キャッシュ新鮮度を設定します(「認証済み HTTP キャッシュの設定」を参照)。


 

HTTP キャッシュ新鮮度の設定

HTTP 1.1 では、要求されたコンテンツがクライアント ブラウザに届く前にキャッシュ オブジェクトの新鮮度をチェックするよう、Content Engine を設定できます。 「新鮮オブジェクト」は、「古く」ないWeb オブジェクトです。キャッシュ オブジェクトは、次のいずれかの場合に、新鮮であると見なされます。

Content Engine が、オリジン サーバから新しくオブジェクトを取得した場合。

Content Engine が、キャッシュ オブジェクトの新鮮度をチェックするためにオリジン サーバと通信し、Content Engine がオブジェクトをキャッシュした後そのキャッシュ オブジェクトが変更されていないことを、オリジン サーバが確認した場合。

キャッシュ オブジェクトの経過時間が、新鮮期限を過ぎていない場合。 キャッシュ オブジェクトの経過時間は、Content Engine がオブジェクトの新鮮度をチェックするようオリジン サーバに明示的に通信しないで、オブジェクトが Content Engine のキャッシュに保存されている時間です。

If-Modified-Since(IMS)機能を使用して、コンテンツがクライアント ブラウザに届く前に、ローカル キャッシュに保存されているコンテンツの新鮮度を再確認するよう、スタンドアロン Content Engine を設定できます。 Content Engine は、次の場合に、キャッシュ コンテンツの新鮮度をチェックします。

Content Engine が、クライアント ブラウザから IMS メッセージを受信した場合。 これは、クライアント ブラウザのローカル キャッシュ設定で、ページがアクセスされるたびにキャッシュ ページの新鮮度をチェックするよう設定されている場合に起こります。

Content Engine が期限切れコンテンツについての要求を受け取る場合。


) クライアントがReload ブラウザ ボタンをクリックして、要求されたコンテンツをブラウザに再ロードすると、要求されたコンテンツを含むオリジン サーバとクライアントとの間に存在するすべての Content Engine によって、キャッシュ オブジェクトがリフレッシュされます。


Content Engine は、オリジン Web サーバに IMS 要求を送信することにより、キャッシュ内にある要求されたコンテンツの新鮮度を確認します。 Content Engine は、最長の存続可能時間 (TTL) が経過しても、オリジン Web サーバに IMS 要求を送信します。

コンテンツの新鮮度は、HTTP プロトコルの条件付き GET 機能を基本にしています。 コンテンツが Content Engine 上にキャッシュされてから変更された場合、Content Engine は、オリジン サーバから要求された情報を再度取得します。 HTTP プロトコルにおいて、条件付き GET 要求は、ドキュメントが Content Engine キャッシュに取得および保存されたとき、そのドキュメントとともに受信した Last-Modified 応答ヘッダーの値を使用します。 この値(最終更新日付およびキャッシュ ドキュメントの日付)は、If-Modified-Since 要求ヘッダーに送信されます。 条件付き GET 要求は、Last-Modified: ヘッダーからのタイムスタンプを使用し、 要求と一緒に If-Modified_Since ヘッダーに送信します。

次の例では、Content Engine がオリジン Web サーバに送信する IMS 要求を示しています。

GET /index.html HTTP/1.1
Server: www.cisco.com
Connection: keep-alive
If-Modified-Since: Tue 12 Sep 2000 10:07:04 GMT Accept: */*
 

コンテンツが変更されていない場合、オリジン Web サーバは、304 Not Modified メッセージで応答し、コンテンツは送信しません。

コンテンツが変更されている場合、新しいコンテンツが Content Engine に再度転送されます。 基本的に、オリジン Web サーバは、新しいコンテンツとともに、200 OK 応答も Content Engine に送信します。

次の例では、オリジン Web サーバから Content Engine IMS 要求に対して送信できる 2 つの応答を示しています。

304 Not Modified
(要求の末尾)
 

または

200 OK
(応答ヘッダー)
(データ)
(要求の末尾)
 

応答が期限切れになる日時を示す、期限切れの応答もキャッシングに影響します。 応答ヘッダーは、要求が古くなる日時を示し、条件付き GET 操作を使用した最新チェックがされずにクライアントに送信されることはありません。 キャッシュ オブジェクトの HTTP ヘッダーが期限切れ時間を指定していない場合、Content Engine は、 http age-multiplier および http max-ttl グローバル設定コマンドを使用して、キャッシュ オブジェクトをエージング アウトできます。

Content Engine は、各 Web オブジェクトがディスクに書き込まれる前にその期限切れ時間を計算することもできます。 Content Engine は、オブジェクトの経過時間(現在の日付 - 最終更新日付)および調整可能な新鮮度係数に基づいて、期限切れ時間を計算します。 最終更新日付は、エンドサーバのファイル システムから提供されます。

新鮮度係数は、 http age-multiplier グローバル設定コマンドのテキストおよびバイナリ パーセンテージ パラメータから得られます。 有効な age-multiplier 値は、0 ~ 100 % のオブジェクトの経過率です。 デフォルト値は、テキスト(HTML)の場合は 30 %、バイナリ オブジェクト(gifs など)の場合は 60 % です。 この日付を過ぎると、オブジェクトは古いものと見なされ、以後に要求があったときは、Content Engine によってコンテンツが新たに検索されます。

スタンドアロン Content Engine 上で HTTP キャッシュ新鮮度の設定を行うときは、次の点に注意してください。

キャッシュに保存できる HTTP オブジェクトの最大サイズを指定できます。 HTTP オブジェクトの最大サイズは、204,799 キロバイトです。 設定可能な上限を超えるサイズのオブジェクトは、Content Engine に保管されなくなります。

最短および最長の存続可能時間 (TTL) の設定値を使用して、キャッシュ内の HTTP オブジェクトの存続時間を制限できます。 デフォルトでは、HTTP キャッシング可能オブジェクトは、最短で 5 分、最長で 3 ~ 7 日(テキスト タイプのオブジェクトの場合は 3 日、バイナリ オブジェクトの場合は 7 日)保持されます。 オブジェクトに期限切れ日が明示的に指定されている場合は、この日付が、設定可能な TTL よりも優先されます。 デフォルト値は、テキスト ファイルに対しては 3 日間、バイナリ オブジェクトに対しては 7 日間です。

HTTP オブジェクトについては、 http min-ttl および ftp min-ttl グローバル設定コマンドを使用して最短 TTL を設定します。

http cache-cookies グローバル設定コマンドを使用して、Content Engine は、HTTP set-cookies ヘッダーを含みかつ明示的な有効期限満了の情報を含まずに処理されるバイナリ オブジェクトをキャッシングします。これらのオブジェクトも場合によってはキャッシングが可能です。

Content Engine CLI または GUI を使用して、スタンドアロン Content Engine 上の HTTP キャッシュの新鮮度の設定値が設定できます。

Content Engine GUI から場合は、 Cache > HTTP Freshness の順に選択し、表示された HTTP Freshness ウィンドウを使用します。 HTTP Freshness ウィンドウを使用して新鮮度の設定値を設定する方法に関する情報の詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から設定する手順は、次のとおりです。


ステップ 1 http age-multiplier グローバル設定コマンドを使用して、次の例のように、HTTP キャッシュ オブジェクトの新鮮度係数を指定します。

ContentEngine(config)# http age-multiplier text 50% bin 70%
 

ステップ 2 http min-ttl グローバル設定コマンドを使用して、HTTP キャッシュ オブジェクトが Content Engine キャッシュに保存される最短時間を設定します。 次の例では、この最短時間が 10 分に設定されます。

ContentEngine(config)# http min-ttl 10
 

ステップ 3 http max-ttl グローバル設定コマンドを使用して、次の例のように、HTTP キャッシュ オブジェクトの推定期限切れ日の上限を設定します。

ContentEngine(config)# http max-ttl days text 2 binary 4
ContentEngine(config#) http max-ttl hours text 1 hours binary 4
 

TTL は、推定期限切れ日に上限を設けます。 HTTP ヘッダーに期限切れ日が明示されている場合は、設定する TTL よりもこの日付が優先されます。 表 6-3 は、有効な範囲の値をリストします。

 

表 6-3 HTTP 新鮮度を決定する TTL 値の範囲

時間単位
範囲

1-1825

1-43800

1-2628000

1-157680000

ステップ 4 http reval-each-request グローバル設定コマンドを使用して、Content Engine がキャッシュ内の HTTP オブジェクトのコンテンツ新鮮度を再確認する要求を処理するときに使用する方式を指定します。

次の例では、各 HTTP 要求ごとにすべての HTTP オブジェクトを再確認するよう、Content Engine を設定します。

ContentEngine(config)# http reval-each-request all
 

ステップ 5 HTTP オブジェクトのサイズの上限をキロバイト(KB)で設定します。 Content Engine は、オブジェクトのサイズが指定された上限を超えた場合、オブジェクトを保存しません。 デフォルトは、HTTP オブジェクトにつき 204800 KB です。

次の例では、HTTP オブジェクトの最大サイズを 500 KB に設定します。

ContentEngine(config)# http object max-size 500
 

ステップ 6 バイナリ オブジェクトとその関連するクッキーをキャッシュするよう Content Engine を設定すると、これらは HTTP set-cookies ヘッダーを含んで明示的な有効期限満了の情報を含まずに提供されますが、場合によってはキャッシュが可能です。

ContentEngine(config)# http cache-cookies
 

ステップ 7 show http ttl EXEC コマンドを使用して、Content Engine のキャッシュ内の HTTP オブジェクトに対して行われた TTL 設定変更を表示します。

ContentEngine# show http ttl
Maximum time to live in days: text 3 binary 7
Minimum time to live for all objects in minutes: 5
 


 

認証済み HTTP キャッシュの設定

認証済み HTTP キャッシング機能を使用すると、基本認証および NT LAN Manager (NTLM) 認証済みのコンテンツをキャッシュに保存し、セキュリティを維持しながら複数のユーザにサービスできます。 認証済みオブジェクトをキャッシュに保存した場合、そのオブジェクトに対する(新しいユーザからの)以後の要求には認証が必要になります。 新しいユーザの認証ヘッダーを使用して、オリジン サーバに対してキャッシュ オブジェクトの再検証が行われます。 ユーザが許可を受けていない場合、サーバは 401(無許可)応答を送信します。 ユーザが許可を受けていて、オブジェクトが変更されていない場合は、キャッシュ オブジェクトがクライアントにサービスされます。


認証キャッシュに、すべての認証済みユーザを同時に保存する容量が不足している場合、Content Engine は、まだタイムアウトになっていない古いエントリから削除します。


Content Engine GUI または CLI を使用して、スタンドアロン Content Engine 上の HTTP 認証キャッシュのパラメータが設定できます。

Content Engine GUI から行う場合は、 Caching > Auth.Cache の順に選択し、表示された Authenticated Cache ウィンドウを使用します。 このウィンドウに関する詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から行う場合は、 表 6-4 で説明されているように、 http authentication グローバル設定コマンドを使用します。

http authentication { cache { max-entries entries | max-group-entries number | timeout minutes | ttl minutes } | header { 401 | 407 } | realm line }

 

表 6-4 http 認証 CLI コマンドのパラメータ

パラメータ
説明

cache

Content Engine 上の認証キャッシュに関連付けられるパラメータを設定します。

max-entries

認証キャッシュに保持されるエントリの最大数を設定します。

entries

Content Engine 上の認証キャッシュに保持されるエントリの最大数。 有効な値は 500 ~ 32000 エントリです。 これは、Content Engine 上で利用できる物理的リソースによって制限されます。

max-group-entries

認証グループ キャッシュに保持されるエントリの最大数を設定します。 これは、Content Engine 上の物理的リソースによって制限されます。 このオプションは、ACNS ソフトウェア リリース 5.2 以降でのみ利用できます。


ヒント グループ名のパターンを使用する場合は必ず、認証グループ キャッシュ内の最大グループ エントリ数を正しく設定してください。 この数値は、認証クエリーの実行中に戻されるグループの最大数に対応している必要があります(たとえば、AAA サーバ上で定義されたグループの総数など)。

number

Content Engine 上の認証グループ キャッシュに保持されるエントリの最大数。 有効な値は 500 ~ 12000 エントリです。 これは、Content Engine 上で利用できる物理的リソースによって制限されます。

timeout

認証キャッシュ中に記録のタイムアウト値を設定します。 アクティブでないエントリが削除される前に認証キャッシュに保持される時間を指定します。 記録が削除された後では、制限されたインターネット コンテンツにその後アクセスを実行する場合は、いつでも認証のためにサーバ検索を必要とします。 これは、Least Recently Used (LRU)の値です。 また、「アイドル タイム」としても参照されます。

minutes

ユーザの最後のインターネット アクセスから、認証キャッシュからユーザのエントリを削除するまでの分単位の時間(1 ~ 1440)。削除されると、再認証が必要になります。 デフォルト値は 240 分 (4 時間)であり、最短は 30 分、最長は 1440 分(24 時間)です。

ttl

認証キャッシュ内のエントリの絶対存続可能時間(TTL)を設定します。 このオプションは、ACNS ソフトウェア リリース 5.2 以降でのみ利用できます。 デフォルトでは、このオプションは無効です。これは、実際には TTL タイムアウトが存在しないことを意味しています。 これは、TTL 値に相対する作成時間に基づく認証キャッシュ エントリのタイムアウトについてはチェックが行われないことを意味しています。

minutes

認証キャッシュ エントリにエントリが作成されてから有効になっている最長時間を指定する分単位の時間(1 ~ 1440)。 最短の時間は 1 分、最大は 1440分(24 時間)です。 詳細は、「再認証の間隔の指定」を参照してください。

header

HTTP 要求のスタイルが、プロキシ サーバが存在しないことを示すとき、認証にどの HTTP ヘッダー(ユーザ ID およびパスワード)を使用するかを決定します。 ヘッダーは HTTP 401(無許可)、または HTTP 407(プロキシ認証必要)のいずれかです。 デフォルトは HTTP 401 です。

401

HTTP 401 を使用して、ユーザのクレデンシャルを照会します。

407

HTTP 407 を使用して、ユーザのクレデンシャルを照会します。

realm

基本 HTTP 要求認証に範囲ストリングを設定します。

line

認証対象となる範囲ストリング名。 デフォルトは、Cisco Content Engine です。

認証キャッシュに保持されるエントリの最大数は、32,000 です。最小数は、500 です。デフォルト値は、16,000 です。 必要な場合は、 http authentication max-entries グローバル設定コマンドを使用して、この Content Engine 上の認証キャッシュに保持されるエントリの最大数を設定してください。

認証キャッシュに、すべての認証済みユーザを同時に保存するための容量が不足している場合、Content Engine は、まだタイムアウトになっていないエントリのうち古いエントリから削除します。 各ユーザの最後のインターネット アクセス以後、認証キャッシュからそのユーザのエントリを削除するまでの時間のデフォルト値は、240 分(4 時間)です。 最短の時間は 1 分、最大は 1440 分(24 時間)です。 この時間が経過すると、Content Engine はアクセス制御サーバに対する再認証を要求します。

次の例では、認証キャッシュ内でエントリが有効である時間の長さが 1000 分に設定されます。

ContentEngine(config)# http authentication cache timeout 1000
 

LDAP、RADIUS、および TACACS+ をプロキシ リダイレクト モードで使用する場合、認証キャッシュ内に保持されている認証レコードは、入力されたユーザ名とパスワードによって索引化されます。 LDAP、RADIUS、および TACACS+ を WCCP 対応ルータのリダイレクト モードで使用する場合、索引化された認証レコードは、透過モードで要求を送信する Content Engine の IP アドレスになります。 NTLM サーバをプロキシ リダイレクト モード、または WCCP 対応ルータのリダイレクト モードのどちらかで使用する場合も、すべての認証レコードが、要求側クライアントの IP アドレスを使用して索引化されます。 デフォルトでは、Content Engine は、着信要求の URL 構文に基づいてキャッシュ ロードを認証します。

http authentication header グローバル設定コマンドを使用して、認証が失敗したときにクライアントにメッセージを送信するよう Content Engine を設定します。 http authentication header 401 (無許可)、または http authentication header 407 (プロキシ認証が必要)を選択できます。

次の例では、Content Engine が、エンド ユーザに認証のためのクレデンシャル情報(ユーザ ID とパスワード)を要求する際に、ヘッダー 407 を使用することを指定します。

ContentEngine(config)# http authentication header 407
 

) ACNS 5.2 ソフトウェアでは、リモートの syslog サーバに HTTP トランザクション ログ メッセージを送信する機能が新しく追加されました。 これにより、リモートの syslog サーバで HTTP 要求認証の失敗をリアルタイムに監視できます。 詳細は、「HPPT 要求認証障害のリアルタイムでのモニタリング」を参照してください。


再認証の間隔の指定

ACNS 5.1 ソフトウェアでは、クライアント ブラウザで、最初の認証を受けてから認証クレデンシャルの入力を再び指示するまでの時間の決定は、非アクティビティ タイマーを使用していました。 この非アクティビティ タイマーは、http authentication cache timeout グローバル設定コマンドで設定されます。 デフォルトでは、非アクティビティタイムアウト間隔は、8 時間でした。 つまり、認証された正当なユーザが最初に認証された後は、誰かがこのクライアント ブラウザを使用し続ける限り、クライアントは、誰かの認証クレデンシャルを再度入力する必要がありませんでした。

HTTP 認証キャッシュ エントリ用の絶対存在可能時間を指定する機能が ACNS 5.2 ソフトウェアに新しく追加され、これにより、共有ワークステーション環境でのセキュリティが強化されます。 絶対 TTL タイムアウトを指定するこの機能によって、Content Engine から提供されるコンテンツのための非アクティビティ タイムアウトのメカニズムに、セキュリティが加わります。 絶対 TTL の期限が切れた際、クライアント ブラウザは、再度認証が必要となり、有効なクレデンシャルを入力する必要があります。

いずれかの認証方式を使用した WCCP 対応ルータ リダイレクト モード、または、プロキシ リダイレクト モードおよび NTLM 認証方式を使用している共有ワークステーション環境には、セキュリティの脆弱性が存在します。 こうした場合、Content Engine は、クライアントの IP アドレスを認証キャッシュに保持されている認証レコード内の索引として使用し、これにより、同じワークステーションを使用している異なるユーザが、以前提示され認証キャッシュにキャッシュされている有効なクレデンシャルを持っている場合に、Content Engine は、自身の有効なクレデンシャルを提示していないユーザを認証することができます。 このシナリオにさらにセキュリティを追加するために、HTTP 認証キャッシュ エントリ用の絶対 TTLを設定できます。これは、キャッシュ内の認証キャッシュ エントリが有効である間の絶対時間を指定します。 エントリでキャッシュ検索が発生し、そのエントリに設定された TTL 時間を超えている場合、エントリは削除され、Content Engine は、クレデンシャルをユーザに照会します。

この機能をサポートするため、 http authentication cache グローバル設定コマンドに ttl オプションが追加されました。

ContentEngine(config)# http authentication cache ?
max-entries Maximum entries in authentication cache; this is subject to
physical resources on the platform
max-group-entries Maximum entries in authentication group cache; this is
subject to physical resources on the platform
timeout Amount of time between last access and cache removal
ttl Maximum amount of time from creation an entry is valid in
the cache
 

Internet Explorer ブラウザを使用する共有ワークステーション環境で絶対 TTL を有効に使用するためには、さらに注意が必要です。Content Engine がユーザにクレデンシャルを照会する際、このブラウザは、ワークステーションのログオン クレデンシャルを自動的に送信するようデフォルトで設定されています。 このため、絶対 TTL にセキュリティを追加するためには、ログオン クレデンシャルを Content Engine に有効な要求認証クレデンシャルにするべきではなく、また、Content Engine がユーザにクレデンシャルを照会する際、Internet Explorer ブラウザがログオン クレデンシャルを自動的に送信しないよう、セキュリティ設定を行う必要があります。 Internet Explorer ブラウザでこれを設定するには、Tools > Internet Options > Security > Internet (and/or the other zones) > Custom Level > User Authentication > Logon > Prompt for Username and Password の順に選択します。 このブラウザ設定を有効にするため、クレデンシャルの照会時に、401 HTTP 応答コードを受信する必要があります。これは、WCCP を使用する透過リダイレクトにおいてデフォルトです。 プロキシ リダイレクト モードで 401 HTTP 応答コードを使用するには、Content Engine の http authentication header 401 グローバル設定コマンドを使用します。


) 共有ワークステーション環境では、各ユーザが共有ワークステーションを離れる前にブラウザを閉じることが前提です。 ユーザがブラウザ セッション終了しない場合、ブラウザは、プロキシを使用してすでに認証されているセッションのクレデンシャルを自動的に送信するため、他のユーザが、自身のユーザ名およびパスワードのクレデンシャルを入力する必要なくこのブラウザ セッションを使用し続けることができます。


Internet Explorer ブラウザを使用する非共有ワークステーションについては、Tools > Internet Options > Security > Internet (and/or the other zones) > Custom Level > User Authentication > Logon > Automatic logon only in Intranet zone (または Automatic logon with current username and password ) の順に選択することにより、ログオン クレデンシャルを自動的に送信するよう、これらのワークステーション上の Internet Explorer ブラウザを設定します。 非共有ワークステーション ユーザのワークステーション ログオン クレデンシャルは、Content Engine で正常に認証されるクレデンシャルと同じである必要があります。 WCCP モードが使用されている場合のみ、これをブラウザで明示的に設定する必要があります。 プロキシ モードでは、クライアント ブラウザは常にクレデンシャルを送信します。

この絶対 TTL タイムアウト( ttl オプション)によって、認証キャッシュ エントリが有効であるとみなされる最長時間を絶対値で指定できます。 TTL タイムアウトは、分単位(1 ~ 1440)で指定されます。 最短の時間は 1 分、最大は 1440分(24 時間)です。 デフォルトで、この絶対 TTL タイムアウト オプションは Content Engine で無効になっています。

絶対設定値が短い場合、共有ワークステーション環境のセキュリティは向上しますが、認証サーバに行われる要求数も増加します。


) 既存の非アクティビティ タイムアウト(timeout オプション)は、絶対 TTL(ttl オプション)の影響を受けません。これらは互いに独立しています。 両方のタイムアウト(非アクティビティ タイムアウトおよび TTL タイムアウト)がContent Engine 上で設定された場合、そのエントリに最初に発生するタイムアウトによって、非アクティビティ タイムアウトと TTL タイムアウトのいずれかが発生するため、認証キャッシュ エントリはタイムアウトします。


HTTP 認証キャッシュ設定の表示

show http authentication EXEC コマンドを使用して、スタンドアロン Content Engine の現在の HTTP 認証キャッシュ設定を表示します。

ContentEngine# show http authentication
HTTP Authentication:
Header: Based on URL syntax
Realm: "Cisco Content Engine"
Cache Timeout: 480 (minutes)
Cache TTL: 240 (minutes)
Cache Maximum entries configured: 8000
Cache Maximum entries platform limit: 8000
Group Cache Maximum entries configured: 500
Group Cache Maximum entries platform limit: 1000

認証されたコンテンツのキャッシングの有効化

デフォルトでは、認証されたコンテンツは HTTP にキャッシュされません。 http cache-authenticated グローバル設定コマンドを使用して、このデフォルトのポリシーを変更できます。

http cache-authenticated { all | basic | ntlm }

表 6-5 にこれらのコマンド パラメータを示します。

 

表 6-5 http cache-authenticated CLI コマンドのパラメータ

パラメータ
説明

cache-authenticated

認証済みの Web オブジェクトをキャッシュに入れ、再検証します。

all

任意の認証スキーマ(基本認証または NTLM 認証)を使用して認証された Web オブジェクトをキャッシュします。

basic

基本認証方式を使用して認証された Web オブジェクトをキャッシュします。 基本認証は、ユーザ クレデンシャル情報を平文形式で送信するため、NTLM 認証ほど安全ではありません。

ntlm

NTLM 認証方式を使用して認証された Web オブジェクトをキャッシュします。

次の例では、基本認証済みコンテンツ、および NTLM 認証済みコンテンツ両方のキャッシングを Content Engine 上で可能にします。

ContentEngine(config)# http cache-authenticated all
 

次の例では、Content Engine 上で現在可能なオブジェクト キャッシングのタイプを確認する方法を示します。

ContentEngine(config)# show http cache-authenticated all
Basic authenticated objects are cached.
NTLM authenticated objects are cached.
 

次の例では、スタンドアロン Content Engine で NTLM オブジェクト キャッシングを可能にする方法を示します。

ContentEngine(config)# http cache-authenticated ntlm
 

NTLM オブジェクト キャッシングが Content Engine 上で有効になっている場合、Content Engine は、クライアントから NTLM HTTP 要求を受け取った際に要求コンテンツのキャッシュを検索します。 キャッシュ ヒットが発生した場合、Content Engine は、要求コンテンツをクライアントに送信します。 キャッシュ ミスが発生した場合、Content Engine は、オリジン サーバから要求コンテンツを取得し、コンテンツのローカル コピーをキャッシュして、要求コンテンツをクライアントに送信します。

キャッシュ オブジェクトは、Content Engine がクライアントにコンテンツを提供できる前に、同じオブジェクトを次の要求が認証できるよう、「NTLM 保護」としてタグ化されます。 キャッシュ ヒットが発生し、要求オブジェクトが NTLM 保護オブジェクトである場合、Content Engine はこのクライアントとサーバ間に保護接続が存在するかどうかを確認します。

保護接続が存在する場合、Content Engine は、プロキシ サーバ接続を使用して、if-modified-since (IMS) 要求をサーバに送信します。

Content Engine がサーバから 304 応答を受け取った場合、Content Engine は、キャッシュ コンテンツをクライアントに提供します。 Content Engine がサーバから 200 応答を受け取った場合、Content Engine は、新しいオブジェクトをキャッシュし、それをクライアントに提供します。 クライアントとサーバ間に保護接続が確立されていない場合、Content Engine は、IMS メッセージを使用して、保護接続の確立を試行します。

HTTP認証キャッシュ統計情報の表示

スタンドアロン Content Engine における認証キャッシュ統計情報を表示するには、 show statistics http-authcache EXEC コマンドを使用します。

「Dels TTL」は、絶対 TTLタイムアウト( http authentication cache ttl コマンド オプション)によって認証キャッシュから削除されたエントリの数を表示します。

「DelTimout」は、非アクティビティ タイマー( http authentication cache timeout コマンド オプション)によって認証キャッシュから削除されたエントリの数を表示します。

「Dels Other」は、他のあらゆる理由で認証キャッシュから削除されたエントリの数を表示します(たとえば、clear users request-authenticated EXECコマンドの入力によって削除されたエントリなど)。

スタンドアロン Content Engine における透過 HTTP フォワード プロキシ キャッシングの設定

透過リダイレクトを使用して、Content Engine に HTTP 要求を送信しているとき、Content Engine で次のキャッシング サービスを設定できます。

標準の Web キャッシュ サービス(サービス 0)。(「スタンドアロン Content Engine に対する標準 Web キャッシュ サービス(サービス 0)の設定」 を参照)

カスタム Web キャッシュ サービス(サービス 98)。(「スタンドアロン Content Engine に対するカスタム Web キャッシュ サービス(サービス 98)の設定」 を参照)

Content Engine GUI または CLI を使用して、スタンドアロン Content Engine 上でこれらのキャッシング サービスを設定できます。 Content Engine GUI を使用して、標準の Web キャッシュ サービス(サービス 0) またはカスタム Web キャッシュ サービス(サービス 98)をスタンドアロン Content Engine 上で有効化および設定する場合、次の Content Engine GUI ウィンドウで、指定されたルータ リストをこれらの各 WCCP サービスに対して指定する必要があります。 Web Cache ウィンドウ ( WCCP > Web Cache) 、および Custom Web Cache ウィンドウ( WCCP > Custom Web Cache) 。 Custom Web Cache ウィンドウの使用についての詳細は、ウィンドウの HELP ボタンをクリックしてください。

スタンドアロン Content Engine に対する標準 Web キャッシュ サービス(サービス 0)の設定

標準 Web キャッシュ サービス(サービス 0)は、HTTP トラフィックをスタンドアロン Content Engine にポート 80 のみでリダイレクトするために、1 つのWCCP Version 1 対応ルータ、または、複数の WCCP Version 2 対応ルータを許可します。 スタンドアロン Content Engine が、リダイレクトされた HTTP をポート 80 で受け取るようにするためには、Content Engine 上で標準 Web キャッシュ サービスを設定しておく必要があります。

WCCP Version 2 を使用して Web キャッシュ サービス(サービス 0)を実行するようスタンドアロン Content Engine を設定するには、 wccp web-cache グローバル設定コマンドを使用します。 このサービスを使用不可にするときは、このコマンドの no 形式を使用します。

wccp web-cache { mask {[ dst-ip-mask hex_num ] [ dst-port-mask port_ hex_num ] [ src-ip-mask hex_num ] [ src-port-mask port_ hex_num ]} | router-list-num num [ assign-method-strict ] [ l2-redirect ] [ mask-assign ] [ password key ] [ weight percentage ]}

表 6-6 にこれらのコマンド パラメータを示します。

 

表 6-6 wccp web-cache CLI コマンドのパラメータ

パラメータ
説明

mask

Content Engine の配置に使用されるマスクを設定します。 最小 1 、最大 4 まで設定します。

dst-ip-mask

(オプション) パケット宛先 IP アドレスを照合するために使用されるマスクを設定します。

hex_num

16 進数で定義される IP アドレス(たとえば、0xFC000000)。 範囲は、0x00000000 ~ FC00000 です。

dst-port-mask

(オプション) パケット宛先ポート番号を照合するために使用されるマスクを設定します。

port_hex_num

16 進数で定義される 宛先ポート(たとえば、0xFC00)。 ポート範囲は、0 ~ 65535 です。

src-ip-mask

(オプション) パケット ソース IP アドレスを照合するために使用されるマスクを設定します。

src-port-mask

(オプション) パケット ソース ポート番号を照合するために使用されるマスクを設定します。

router-list-num

ルータ リスト番号を設定します。

num

ルータ リスト番号(1 ~ 8)。

assign-method-strict

WCCP が設定されたアサインメント方式だけを完全に使用するよう設定します。

l2-redirect

(オプション) レイヤ 2 リダイレクトによるパケット転送。

mask-assign

(オプション) Content Engine の配置においてマスク方式を使用します。

password

(オプション) 認証パスワードを設定します。

key

WCCP サービスのパスワード キー。

weight

(オプション)負荷分散の重みの比率を設定します。

percentage

パーセント値(0 ~ 100)。

次のシナリオでは、スタンドアロン Content Engine および WCCP 対応ルータに対して、Web キャッシュ サービス(サービス 0)が設定されます。 ルータにこの WCCP サービスを設定することによって、WCCP ルータは、HTTP 要求をContent Engine のポート 80 に透過的にリダイレクトします。Content Engine にこのサービスを設定することによって、Content Engine は、リダイレクトされた HTTP 要求をポート 80 で受信します。 Content Engine は、リダイレクトされたHTTP 要求を受け取って処理する必要があると判断した場合、要求された情報がキャッシュにまだ保存されていなければ、オリジン サーバからこれを取得して、そのコンテンツがキャッシュ可能であればローカル ストレージにそのコピーをキャッシュし、その後、要求コンテンツをクライアント ブラウザに送信します。

スタンドアロン Content Engine および WCCPルータに対し、標準 Web キャッシュ サービス(サービス 0)を設定する手順は、次のとおりです。


ステップ 1 スタンドアロン Content Engine 上で、WCCP Version 1 または Version 2 を有効にします。

ContentEngine(config)# wccp version 1
 

または

ContentEngine(config)# wccp version 2
 

ステップ 2 Content Engine が、 表B-3 にリストされている Web キャッシュ サービス(サービス 0)以外のサービスをサポートするには、WCCP Version 2 を実行している必要があります。 この Content Engine 上で、WCCP Version 2 ではなく Version 1 を有効にする場合、サポートされるサービス(標準 Web キャッシュ サービス)だけをサポートするために、1 つの WCCP ルータだけを設定できます。これに対し、Version 2 を選択した場合は、特定の WCCP サービスをサポートするよう最大 8 つの WCCP ルータを設定でき、すべての WCCP サービスがサポートされます。


ヒント Content Engine GUI から WCCP > Enable WCCP の順に選択して、Version 1 または Version 2 オプション ボタンをクリックすることによっても、スタンドアロン Content Engine 上で WCCP Version 1 または Version 2 を有効にできます。

ステップ 3 Web キャッシュ サービスをサポートするルータを指定する、ルータ リストを作成します。 この Content Engine の Web キャッシュ サービスをサポートする、すべてのルータの IP アドレスまたはマルチキャスト アドレスを入力する。 各種 WCCP サービスに対して複数の異なるルータを使用する場合、複数のルータ リストを作成する必要があります。

この場合、ルータ リスト 1 に ルータが 1 つだけ含まれます(IP アドレス 10.0.1.1 をもつ、標準 Web キャッシュ サービスのためだけに設定したルータ)。

ContentEngine(config)# wccp router-list 1 10.0.1.1
 

Content Engine GUI を使用してこの Content Engine 上の WCCP を有効化および設定する場合は、Content Engine GUI の Web Cache ウィンドウ( WCCP > Web Cache ) で、指定されたルータ リストを Web キャッシュ サービスに対して指定する必要があります。

ステップ 4 このスタンドアロン Content Engine が、リダイレクトされた Web キャッシュ要求をポート 80 で受け入れていることを、指定されたルータ リストの WCCP 対応ルータに通知します。

ContentEngine(config)# wccp web-cache router-list-num 1
 

ステップ 5 グローバル設定モードを終了します。

ContentEngine(config)# exit
 

ステップ 6 実行コンフィギュレーションを不揮発性メモリに書き込みます。

ContentEngine# write memory
 

ステップ 7 ルータの WCCP Version 2 をオンにします。

Router# configure terminal
Router(config)# ip wccp version 2
 

ステップ 8 ルータの標準 Web キャッシュ サービスをオンにします。

Router(config)# ip wccp web-cache
 

ステップ 9 標準 Web キャッシュ サービスを実行するインターフェイスを指定します。

Router(config)# interface type number
 

次の例では、ルータの イーサネット インターフェイス 0/1 で Web キャッシュ サービスを実行するよう設定します。

Router(config)# interface ethernet 0/1
 

ステップ 10 標準 Web キャッシュ サービスの設定されているインターフェイス(たとえば、イーサネット インターフェイス 0/1)に着信する HTTP トラフィックをチェックするよう、ルータをチェックします。 ルータは、これらのパケットをスタンドアロン Content Engine にリダイレクトするべきかどうかを判断します。 この Content Engine は、リダイレクトされた HTTP 要求を この WCCP Version 2 ルータからポート 80 で着信する透過フォワード プロキシ サーバとして機能します。

Router(config-if)# ip wccp web-cache redirect in
 


 

スタンドアロン Content Engine に対するカスタム Web キャッシュ サービス(サービス 98)の設定

スタンドアロン Content Engine が、リダイレクトされた HTTP トラフィックをポート 80 以外で着信できるようにするために、カスタム Web キャッシュ サービス(サービス 98)をサポートするよう Content Engine を設定します。

wccp custom-web-cache グローバル設定コマンドを使用すると、Content Engine は、ユーザ指定のポート番号上で Cisco ルータを使用した WCCP Version 2 リダイレクト サービスを自動的に確立します。 Content Engine はこのとき、ポート 80 透過 Web キャッシングを中断しないまま、このポートを介したすべての HTTP 要求のキャッシングを実行します。 カスタム Web キャッシングを行うためには、WCCP Version 2 を実行しているルータ上でカスタム Web キャッシュ サービス(サービス 98)を有効にする必要があります。WCCP Version 1 は、カスタム Web キャッシュ サービスをサポートしません。

スタンドアロン Content Engine に対してカスタム Web キャッシュ サービスを設定するには、 wccp custom-web-cache グローバル設定コマンドを使用します。 Content Engine でカスタム Web キャッシュ サービスを無効にするには、このコマンドの no 形式を使用します。

wccp custom-web-cache { mask {[ dst-ip-mask hex_num ] [ dst-port-mask port _ hex_num ] [ src-ip-mask hex_num ] [ src-port-mask port_ hex_num ]} | router-list-num num port port [ assign-method-strict ] [ hash-destination-ip ] [ hash-destination-por t ] [ hash-source-ip ] [ hash-source-port] [ l2-redirect ] [ mask-assign ] [ password key ] [ weight percentage ]}

表 6-7 にこれらのコマンド パラメータを示します。

 

表 6-7 wccp custom-web-cache CLI コマンドのパラメータ

パラメータ
説明

mask

Content Engine の配置に使用されるマスクを設定します。 最小 1 から 最大 4 まで設定します。

dst-ip-mask

(オプション) パケット宛先 IP アドレスを照合するために使用されるマスクを設定します。

hex_num

16 進数で定義される IP アドレス(たとえば、0xFC000000)。 範囲は、0x00000000 ~ FC00000 です。

dst-port-mask

(オプション) パケット宛先ポート番号を照合するために使用されるマスクを設定します。

port _ hex_num

16 進数で定義されるポート マスク(たとえば、0xFC00)。 ポート範囲は、0 ~ 65535 です。

src-ip-mask

(オプション) パケット ソース IP アドレスを照合するために使用されるマスクを設定します。

src-port-mask

(オプション) パケット ソース ポート番号を照合するために使用されるマスクを設定します。

router-list-num

ルータ リスト番号を設定します。

num

ルータ リスト番号(1 ~ 8)。

port

ポート番号を設定します。

port

ポート リスト番号(1 ~ 65535)。

assign-method-strict

WCCP が設定されたアサインメント方式だけを完全に使用するよう設定します。

hash-destination-ip

(オプション)宛先 IP アドレスの負荷分散ハッシュを定義します(デフォルト)。

hash-destination-port

(オプション)宛先ポートの負荷分散ハッシュを定義します。

hash-source-ip

(オプション)ソース IP アドレスの負荷分散ハッシュを定義します。

hash-source-port

(オプション)ソース ポートの負荷分散ハッシュを定義します。

l2-redirect

(オプション) レイヤ 2 リダイレクトによるパケット転送。

mask-assign

(オプション) Content Engine の配置においてマスク方式を使用します。

password

(オプション) 認証パスワードを設定します。

key

WCCP サービスのパスワード キー。

weight

(オプション)負荷分散の重みの比率を設定します。

percentage

パーセント値(0 ~ 100)。

Content Engine が デバイスとのレイヤ 2 接続を確立しており、そのデバイスにレイヤ 2 リダイレクトの設定が行われている場合、 l2-redirect オプションは、Content Engine が、WCCP Version 2 対応ルータまたはスイッチからリダイレクトされたトラフィックを透過的に受信できるようにします。

weight パラメータは、Content Engine クラスタにリダイレクトされる負荷のパーセンテージを表します(たとえば、負荷の重みが 30 である Content Engine は、総負荷量の 30% を受け取ります)。 Content Engine クラスタ内のすべての重みパラメータの合計が 100 を超える場合、各 Content Engine の負荷パーセンテージは、その重みパラメータが総計を表すよう再計算されます。

次のシナリオでは、WCCP Version 2 を実行しているスタンドアロン Content Engine およびルータが、カスタム Web キャッシュ サービス(サービス 98)をサポートするよう設定されます。 この WCCP キャッシング サービスを設定することによって、WCCP Version 2 ルータは、透過的に HTTP トラフィックをContent Engine(透過フォワード プロキシ サーバ)に複数ポート(最大 8 ポート)でリダイレクトできます。 これにより、ユーザ定義の WCCP サービス(サービス 90 ~ 97)を設定する必要なく、複数ポートで HTTP 要求を代行受信するよう Content Engine を設定できます。 Content Engine およびルータに対するユーザ定義 WCCP サービスの設定方法については、「スタンドアロン Content Engine の WCCP サービスの設定」 および 「ルータでの WCCP サービスの設定」 を参照してください。

スタンドアロン Content Engine およびルータに対し、カスタム Web キャッシュ サービス(サービス 98)を設定する手順は、次のとおりです。


ステップ 1 スタンドアロン Content Engine 上で WCCP Version 2 を有効にします。

ContentEngine(config)# wccp version 2
 

Content Engine は、カスタム Web キャッシュ サービス(サービス 98)をサポートするために、WCCP Version 2 を実行している必要があります。 WCCP Version 2 は、 表B-3 にリストされている、標準 Web キャッシュ サービス(サービス 0)以外のすべての WCCP サービスに必要です。


ヒント Content Engine GUI から WCCP > Enable WCCP の順に選択して、Version 1 または Version 2 オプション ボタンをクリックすることによっても、スタンドアロン Content Engine 上で Version 2 を有効にできます。

ステップ 2 カスタム Web キャッシュ サービスをサポートするルータを指定する、ルータ リストを作成します。 この Content Engine の カスタム Web キャッシュ サービスをサポートする、すべてのルータの IP アドレスまたはマルチキャスト アドレスを入力します。 各種 WCCP サービスに対して複数の異なるルータを使用する場合、複数のルータ リストを作成する必要があります。

この場合、ルータ リスト 1 に ルータが 1 つだけ含まれます(IP アドレス 10.0.1.1 をもつ、カスタム Web キャッシュ サービスのためだけに設定したルータ)。

ContentEngine(config)# wccp router-list 1 10.0.1.1
 

Content Engine GUI を使用してこの Content Engine 上の WCCP を有効化および設定する場合は、Content Engine GUI の Custom Web Cache ウィンドウ ( WCCP > Custom Web Cache ) で、指定されたルータ リストをカスタム Web キャッシュ サービスに対して指定する必要があります。

ステップ 3 このスタンドアロン Content Engine が、リダイレクトされたカスタム Web キャッシュ要求をポート 31 で受け入れていることを、指定されたルータ リストの WCCP 対応ルータに通知します。

ContentEngine(config)# wccp custom-web-cache router-list-num 1 port 31
 

ステップ 4 グローバル設定モードを終了します。

ContentEngine(config)# exit
 

ステップ 5 実行コンフィギュレーションを不揮発性メモリに書き込みます。

ContentEngine# write memory
 

ステップ 6 ルータの WCCP Version 2 をオンにします。

Router# configure terminal
Router(config)# ip wccp version 2
 

ステップ 7 ルータの カスタム Web キャッシュ サービス(サービス 98)をオンにします。

Router(config)# ip wccp 98
 

ステップ 8 カスタム Web キャッシュ サービスを実行するインターフェイスを指定します。

Router(config)# interface type number
 

次の例では、ルータの イーサネット 0 インターフェイスでカスタム Web キャッシュ サービスを実行するよう設定します。

Router(config)# interface ethernet 0
 

ステップ 9 カスタム Web キャッシュ サービスに送信インターフェイスを使用するよう、ルータを設定します。

Router(config-if)# ip wccp 98 redirect out
 


 

スタンドアロン Content Engine における HTTP リバース プロキシ キャッシングの設定

リバース プロキシ サービス(サービス 99)は、WCCP Version 2 対応ルータが、透過リバース プロキシ サーバとして機能しているスタンドアロン Content Engine にリバース プロキシ パケットをリダイレクトすることを可能にする、定義済みの WCCP Version 2 サービスです。

ここでは、WCCP Version 2 対応ルータとスタンドアロン Content Engine を使用して WCCP サービスを設定する方法のシナリオ例を説明します。 このシナリオでは、WCCP Version 2 および リバース プロキシ サービス(サービス 99)を使用して、HTTP リバース プロキシ要求をポート 80 でContent Engine に透過的にリダイレクトします。Content Engine にこのサービスを設定することにより、Content Engine は、リダイレクトされた HTTP リバース プロキシ要求を処理します。 要求の処理の一部として、Content Engine は、要求された情報がまだキャッシュに保存されていない場合、オリジン サーバから情報を取得してローカル コピーをキャッシュし、その要求コンテンツをクライアント ブラウザに送信します。

スタンドアロン Content Engine および WCCPルータに対し、リバース プロキシ サービス(サービス 99)を設定するには、次の手順を行います。


ステップ 1 スタンドアロン Content Engine 上で WCCP Version 2 を有効にします。

ContentEngine(config)# wccp version 2
 

Content Engine は、リバース プロキシ サービスをサポートするために、WCCP Version 2 を実行している必要があります。 WCCP Version 1 は、標準 Web キャッシュ サービス(サービス 0)だけをサポートし、リバース プロキシ サービスはサポートしません。 WCCP サービスのリストについては、 表B-3 を参照してください。


ヒント Content Engine GUI から WCCP > Enable WCCP の順に選択して、Version 2 オプション ボタンをクリックすることによっても、スタンドアロン Content Engine 上で WCCP Version 2 を有効にできます。

ステップ 2 リバース プロキシ サービスをサポートするルータを指定する、ルータ リストを作成します。 この WCCP サービスをサポートするすべてのルータの IP アドレスまたはマルチキャスト アドレスを入力します。 各種 WCCP サービスに対して複数の異なるルータを使用する場合、複数のルータ リストを作成する必要があります。

この場合、ルータ リスト 1 に ルータが 1 つだけ含まれます(IP アドレス 10.0.1.1 をもつ、リバース プロキシ キャッシュ サービスのためだけに設定したルータ)。

ContentEngine(config)# wccp router-list 1 10.0.1.1
 

Content Engine GUI を使用してこの Content Engine のWCCP を有効化および設定する場合、Content Engine GUI ウィンドウで(Reverse Proxy ウィンドウ ( WCCP > Reverse Proxy) 、指定されたルータ リストをリバース プロキシ サービスに対して指定する必要があります。

ステップ 3 このスタンドアロン Content Engine が、リダイレクトされた リバース プロキシ キャッシュ要求をポート 80 で受け入れていることを、指定されたルータ リストの WCCP 対応ルータに通知します。

ContentEngine(config)# wccp reverse-proxy router-list-num 1
 

ステップ 4 グローバル設定モードを終了します。

ContentEngine(config)# exit
 

ステップ 5 実行コンフィギュレーションを不揮発性メモリに書き込みます。

ContentEngine# write memory
 

ステップ 6 ルータの WCCP Version 2 をオンにします。

Router# configure terminal
Router(config)# ip wccp version 2
 

ステップ 7 ルータのリバース プロキシ サービス(サービス 99)をオンにします。

Router(config)# ip wccp 99
 

ステップ 8 リバース プロキシ サービスを実行するインターフェイスを指定します。

Router(config)# interface type number
 

次の例では、ルータの イーサネット 0 インターフェイスでリバース プロキシ サービスを実行するように設定します。

Router(config)# interface ethernet 0
 

ステップ 9 リバース プロキシ キャッシュ サービスに送信インターフェイスを使用するよう、ルータを設定します。 ルータは、イーサネット インターフェイス 0 上のリバース プロキシ パケットをチェックして、これらのパケットを Content Engine(透過リバース プロキシ サーバ)に透過的にリダイレクトするべきかどうか判断します。

Router(config-if)# ip wccp 99 redirect out
 


 

スタンドアロン Content Engine における HTTPS キャッシングの設定

HTTPS プロトコルは、基本的に、Secure Socket Layer(SSL)トランスポート層で使用される HTTP プロトコルです。 SSL は、2 つのデバイス間(たとえば、クライアントとサーバ)に保護チャネルを提供するプロトコルです。 SSL は、公開鍵暗号法を使用して、クライアント ブラウザとサーバ間の通信のセキュリティとプライバシを保護します。 HTTPS は、https:// で始まる一意の URL を使用します(たとえば、https://abc.com)。 HTTP のデフォルトポートがポート 80 であるのに対し、HTTPS で使用されるデフォルト ポート番号は、ポート 443 です。

次のシナリオで説明するように、Content Engine は、SSL を終了させることも、また、オリジン HTTPSサーバにHTTPS クライアント要求をトンネルさせることもできます。

HTTPS クライアント要求の SSL 終了について

HTTPS クライアント要求のトンネリングについて

スタンドアロン Content Engine 上でさまざまなタイプの HTTPS キャッシングを設定する方法については、次を参照してください。

スタンドアロン Content Engine における HTTPS プロキシ キャッシングの設定

スタンドアロン Content Engine における HTTPS 透過キャッシングの設定

HTTPS クライアント要求の SSL 終了について

Content Engine SSL が HTTPS クライアント要求を終了する場合、これは、Content Engine が SSL 暗号化データを復号化することを意味しています。 Content Engine は、SSL 暗号化データを復号化することにより、HTTPS クライアント要求を平文で参照でき、これにより、これらの要求において多数の HTTP 処理タスク(キャッシング、ルール処理、フィルタリングなど)を実行できます。 ACNS ソフトウェア リリース 5.1 以降を実行している Content Engine は、この SSL 終了機能をサポートしています。 ACNS 5.2 以降を実行している Content Engine は、指定されたルールの定義に従って、HTTPS 要求を再書き込みおよびリダイレクトすることもできます。 Content Engine は、HTTPS 要求を終了する場合、大部分のルールを HTTPS 要求に適用できます(no-proxy、use-icap-service、use-proxy ルール アクションは、HTTPS キャッシングではサポートされません)。 詳細は、「スタンドアロンContent Engine の Rules Template の設定」を参照してください。

SSL 終了機能を適切に機能させるため、SSL 証明書 とオリジン HTTPS サーバの秘密鍵を Content Engine にインストールする必要があります。 Content Engine に適切な証明書と秘密鍵がインストールされている場合、SSL 終了機能は、透過モードとプロキシ モードのどちらでも機能します。 特定の要求したコンテンツをキャッシュする場合、これらのオリジン HTTPSサーバに適した証明書と鍵を Content Engine にインポートし、これらのサーバからコンテンツをキャッシュするようContent Engine を設定します。 スタンドアロン Content Engine の場合は、Content Engine CLI を使用してこれを実行します(「HTTPS キャッシングに使用する証明書と秘密鍵の設定」 を参照)。

ACNS 5.2 ソフトウェアでは、要求された HTTPS サーバが Content Engine 上で設定されている場合、Content Engine SSL は、WCCP モードと手動プロキシ モードの HTTPS 要求を終了し、残りの HTTPS トラフィックをトンネルさせます。

HTTPS クライアント要求のトンネリングについて

HTTPS 要求のトンネリングは、HTTPS クライアント要求に対して ACNS ソフトウェアがサポートする別のモードです。 このモードでは、Content Engine は、HTTPS クライアント要求において限定された処理だけをサポートします(非キャッシング サポート、および限定されたフィルタリング サポートなど)。

ACNS ソフトウェア リリース 3.0 以降のバージョンは、CONNECT メソッドを使用した HTTPS トンネリングをサポートしています。これは、HTTP 仕様で定義されている標準の HTTPS トンネリング方式です。

ACNS ソフトウェア リリース 5.1.5 以降のバージョンは、透過的にリダイレクトされた ネイティブ HTTPS トラフィックのトンネリングをサポートしています。 すなわち、Content Engine は、クライアントからネイティブ HTTPS トラフィックを受け入れ、オリジン HTTPS サーバにこれらの要求をトンネルさせることができます。 Content Engine は、こうしたトラフィックのフィルタリングを適用できますが、オリジン HTTPSサーバの証明書と鍵が Content Engine にインストールされていないため、実際の HTTPS コンテンツを参照しません。

スタンドアロン Content Engine における HTTPS プロキシ キャッシングの設定

HTTPS プロキシ キャッシングを使用した直接プロキシ ルーティングを使用して、HTTPS 要求を Content Engine に直接(クライアント ブラウザから HTTPS-over-HTTPに)送信します。 Content Engine は、これらのクライアント ブラウザに対して、非透過フォワード プロキシ サーバ(非透過 HTTPSプロキシ サーバ)として機能します。 Content Engine を直接指定するようクライアント ブラウザを設定する方法については、「クライアント ブラウザに直接スタンドアロン Content Engine を指定」 を参照してください。

HTTPS プロキシ モードで動作するよう Content Engine を設定して、この Content Engine を HTTPS プロキシ サーバとして使用するよう設定したクライアント ブラウザからの HTTPS要求が処理できるようにします。


) 受信 HTTPS プロキシ要求をサポートするには、DNS サーバを設定する必要があります(「DNS キャッシング ネーム サービス(サービス 53)用の DNS サーバの設定」 を参照)。


Content Engine GUI から行う場合は、 Caching > HTTPS Proxy の順に選択し、表示された HTTPS Proxy ウィンドウを使用します。 HTTPS Proxy ウィンドウを使用して HTTPS プロキシ キャッシングの設定を行う方法の詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から行う場合は、 https proxy グローバル設定コマンドを使用します( 表 6-8 を参照)。 CLI コマンドの入力順序は重要ではありません。

 

表 6-8 HTTPS プロキシ機能および関連 CLI コマンド

Content Engine CLI コマンド(省略構文)
HTTPS プロキシ機能

https proxy incoming ports 1 - 65535, ports, . . .

最大 8 つの受信プロキシ ポートをサポートします。

https proxy incoming ports 1 - 65535
wccp custom-web-cache . . .

HTTPS-over-HTTP 要求を代行受信するよう、HTTPS 受信 プロキシ プロキシ ポートおよびカスタム Web キャッシュ サービスを設定します。

no https destination-port allow 443 563

または
https destination-port deny all

すべての宛先 HTTPS ポートへの不要アクセスを拒否します。

proxy-protocols outgoing-proxy exclude list word
https proxy outgoing host { hostname | ip_address } port 1 - 65535

グローバル exclude オプションを使用して、発信 HTTPS プロキシ サーバを設定します。

proxy-protocols transparent default-server

使用可能な場合は、デフォルトの発信 HTTPS プロキシ サーバを使用します。

proxy-protocols transparent original-proxy

元の要求からの発信 HTTPS プロキシ サーバを使用します。

proxy-protocols transparent reset

キャッシュ ミスの間に、送信クライアントに対して受信 HTTPS 要求を戻します。

次のシナリオは、HTTPS-over-HTTP プロキシ キャッシングをサポートするようスタンドアロン Content Engine を設定する方法を説明します。


ステップ 1 https proxy incoming ports グローバル設定コマンドを使用して、プロキシ モード要求の受信に使用するポート番号を設定します。

https proxy incoming ports

ここで、 ports は、スタンドアロン Content Engine がクライアント ブラウザからの受信 HTTPS 要求を受け入れるポート(ポート 80 以外)です。 この番号の範囲は 1 ~ 65535 です。最高 8つのポートを指定できます。

次の例は、ポート 8080、8081 および 9090 でHTTPS 要求を受け入れるよう Content Engine を設定します。複数ポートを入力する場合は、ポート番号をそれぞれ 空白で区切ります。

ContentEngine(config)# https proxy incoming 8080 8081 9090
 

このコマンドを使用して、ポート 80 以外のポートで HTTPS-over-HTTP を受け入れるよう Content Engine を設定する場合は、それらの HTTPS 要求を Content Engine 上のそのポートに送信するよう、クライアント ブラウザも設定する必要があります。 詳細は、「クライアント ブラウザに直接スタンドアロン Content Engine を指定」を参照してください。

ステップ 2 https proxy outgoing host host port primary グローバル設定コマンドを使用して、プロキシ サーバを Content Engine に対するプライマリ発信 HTTPS プロキシ サーバとして割り当てます。ここで、

host は、HTTPS ミス トラフィックが送信される親キャッシュ(発信 HTTPS プロキシ サーバ)のホスト名または IP アドレスです。

port は、親キャッシュが Content Engine からキャッシュ ミス HTTPS-over-HTTP 要求を受け入れるために使用するポート番号です。

primary キーワードを使用して、指定のホストをプライマリ発信 HTTPS プロキシ サーバとして設定します。 primary キーワードで複数のサーバ(ホスト)を設定した場合、最後に設定されたサーバが、Content Engine に使用される プライマリ発信 HTTPS プロキシ サーバになります。

次の例では、Content Engine A が、キャッシュ ミス HTTPS トラフィック(ブラウザの HTTPS- over-HTTP 要求についてのキャッシュ ミス)をホスト 10.1.1.1 のポート 8088 へ送信するよう設定されます。Content Engine A に対するプライマリ発信 HTTPS プロキシ サーバとして、ホスト 10.1.1.1 が明示的に指定されます。ホスト 10.1.1.2 は、Content Engine A に対するバックアップ発信 HTTPS プロキシ サーバとして指定されます。

ContentEngineA(config)# https proxy outgoing host 10.1.1.1 8088 primary
ContentEngine(config)# https proxy outgoing host 10.1.1.2 220
 

ACNS ソフトウェア リリース 5.1.x 以前のバージョンでは、Content Engine に設定できる発信 HTTPS プロキシ サーバは 1 台だけでした。 ACNS 5.2 ソフトウェアでは、HTTPS-over-HTTP プロキシ要求に対し、最大 8 台の発信プロキシ サーバを指定できます。 最大 8 台の発信プロキシ サーバをサポートできる利点は、1 台の発信プロキシ サーバに障害が発生した場合に、Content Engine が次に指定されている発信プロキシ サーバにフェールオーバーされるため、冗長性が高まることです。 すべての発信要求は、プライマリ発信プロキシ サーバに送られます。 プライマリ プロキシ サーバに障害が発生した場合、要求はリストにある次のアクティブのプロキシ サーバに送られます。

ステップ 3 show https proxy EXEC コマンドを使用して、スタンドアロン Content Engine 上に現在設定されている 各 HTTPS プロキシ サーバの現在の状態を確認します。


 

スタンドアロン Content Engine における HTTPS 透過キャッシングの設定

HTTPS 透過キャッシングをサポートするよう Content Engine を設定するには、WCCP Version 2 HTTPS キャッシング サービス(HTTPS キャッシュ サービス[サービス 70])をサポートするよう Content Engine とルータを設定する必要があります。 https-cache サービスは、WCCP Version 2 対応ルータが、ポート 443 TCP トラフィックを代行受信して、この HTTPS トラフィックを Content Engine にリダイレクトできる、WCCP HTTPS キャッシング サービスです。この場合、Content Engine は、透過フォワード プロキシ サーバとして作動していることが前提です。これは、HTTPS 透過キャッシングのために設定されます。 Content Engine は、要求コンテンツを取得し、コンテンツがキャッシュ可能であれば、HTTPS 透過キャッシングを実行してコピーをローカルに保存し、要求コンテンツをクライアントに提供します。

ACNS 5.1.x ソフトウェアでは、https-cache サービスに対して、1 種類の代行受信モード(accept-only モード)しかサポートされませんでした。 accept-only モードを使用した場合、Content Engine は、設定された HTTPS サーバに送信された要求だけを受け入れることができます。

ContentEngine(config)# wccp https-cache router-list-num 1
 

または

ContentEngine(config)# wccp service-number 95 router-list-num 1 port-list 1 https-cache
 

上記の例では両方とも、HTTPS サーバが Content Engine 上で設定された場合(すなわち、 https server グローバル設定コマンドを使用して、Content Engine 上に IP アドレスまたはホスト名、および、オリジン HTTPS サーバの秘密鍵と証明書を指定した場合)、Content Engine は、リダイレクトされた HTTPS トラフィックだけを受け入れます。

ACNS 5.2 ソフトウェアでは、https キャッシュ サービス(サービス 70)に使用できる代行受信モード(accept-all モード)が、新たに追加されました。 accept-all モードが有効である場合、Content Engine は、Content Engine に設定されているオリジン HTTPS サーバに関係なく、すべての HTTPS 要求を代行受信します。 オリジン HTTPS サーバの秘密鍵または証明書が Content Engine に設定されていない場合、Content Engine は、要求を SSL 終了させる代わりに、オリジン HTTPS サーバへトンネルさせます(ACNS 5.1 ソフトウェアでは、Content Engine は、サポートするよう明示的に設定していない HTTPS 要求が送信された場合、それをHTTPS サーバにバイパスしていました)。

accept-all モードは、HTTPS トラフィックのフィルタリングをサポートするために追加されました。 次を参照してください。

ContentEngine(config)# wccp https-cache ?
accept-all Accept all https traffic by default
mask Specify mask used for CE assignement
router-list-num Router list number
 

accept-all モードは、従来の WCCP サービスと同様に機能します(デフォルトですべての Web トラフィックを代行受信する 標準 Web キャッシュ サービス[サービス 0] など)。 wccp https-cache accept-all オプションを使用すると、HTTPS キャッシュ( https-cache サービスをサポートする Content Engine)は、「accept all」モードで動作します(すなわち、すべての HTTPS トラフィックが Content Engine によって代行受信されます)。 wccp https-cache accept-all オプションを使用しない場合、Content Engine は、「accept only」モードで動作します。

Content Engine は、リダイレクトされた HTTPS 要求を標準 HTTPS ポート(デフォルト ポート 443)で受信します。 デフォルト ポート以外のポートで HTTPS トラフィックを代行受信するには、ユーザ定義の WCCP サービス(サービス 90 ~ 97)を設定します。 このトピックに関する詳細は、「ユーザ定義の WCCP サービスをサポートするためのスタンドアロン Content Engine の設定」を参照してください。

次のシナリオは、スタンドアロン Content Engine および WCCP Version 2 を実行している 1 つのルータ上で HTTPS 透過キャッシングを設定する方法を示します。


ステップ 1 HTTPS キャッシュ サービス(サービス 70)をサポートするようルータを設定します。

a. ルータ(たとえば、Router A とします)上で WCCP Version 2 を有効にします。

RouterA# configure terminal
RouterA(config)# ip wccp version 2
 

b. HTTPS キャッシュ サービス(サービス 70)を実行するよう Router A を設定します。

RouterA(config)# ip wccp 70
 

c. すべての発信 HTTPS トラフィックを代行受信するよう Router A を設定します。

Router(config)# ip wccp 70 redirect out
 

ステップ 2 HTTPS キャッシュサービスをサポートするよう Content Engine を設定します。

a. HTTPS キャッシュサービスをサポートするために使用されるルータのリストを設定します。 この場合、ルータ リスト番号 1 が作成され、これは、1 つのルータ(IP アドレス 10.2.202.1 である Router A)だけで構成されます。

ContentEngine(config)# wccp router-list 1 10.1.202.1
 

b. ルータ リスト 1にリストされているルータ(Router A)から透過的にリダイレクトされた HTTPS 要求を受け入れるよう、Content Engine を設定します。

ContentEngine(config)# wccp https-cache router-list-num 1
 

c. Content Engine 上で WCCP Version 2 を有効にします。

ContentEngine(config)# wccp version 2
 

d. Content Engine がすべての HTTPS トラフィックを代行受信し、秘密鍵や証明書が設定されていないサーバからの HTTPS トラフィックをトンネルさせるよう設定する場合、Content Engine 上で accept-all モードを有効にします。 この機能は、基本的に、フィルタリングを行うことを目的に使用されます(たとえば、トンネルされた HTTPS 要求をフィルタリングする SmartFilter ソフトウェアや Websense ソフトウェアを Content Engine で使用可能にするため)。

ContentEngine(config)# wccp https-cache accept-all
 

ステップ 3 HTTPS 要求をオリジン HTTPS サーバにトンネリングさせるのではなく、Content Engine がコンテンツをキャッシュする HTTPS オリジン サーバから、秘密鍵または証明書をロードします(すなわち、HTTPS オリジン サーバとして機能します)。

a. https EXEC コマンドを使用して、秘密鍵または証明書を Content Engine にロードします。

ContentEngine# https ?
cert Certificate management commands
certgroup Certificate chain management commands
key Private key management commands
 

詳細は、「HTTPS キャッシングに使用する証明書と秘密鍵の設定」を参照してください。

ステップ 4 必要に応じて、Content Engine 上に証明書グループを作成します。 この機能は、Content Engine によって SSL 終了される HTTPS 要求に対して使用されます。 詳細は、「HTTPS キャッシングに使用する証明書グループの設定」を参照してください。

ステップ 5 Content Engine 上で、基本 HTTPS サーバ設定を行います。 これらの基本設定は、Content Engine 上で HTTPS 透過キャッシングを有効にするために必要です。

a. https server server-name グローバル設定コマンドを使用して、Content Engine がコンテンツをキャッシュするオリジン HTTPS サーバのサーバ名を指定します。 たとえば、次の例では、「abc1」という名前のオリジン HTTPS サーバが Content Engine に設定されます。 サーバ名を指定した後、HTTPS 設定を行うためのサブモードが起動され、プロンプトが
ContentEngine(config-https)# に変わります。

ContentEngine(config)# https server abc1
ContentEngine(config-https)#
 

b. HTTPS 設定サブモードから、証明書、秘密鍵および HTTPS サーバのホスト名(abcl)を入力し、これらの設定を Content Engine で有効にします(サブモードから enableを入力します。下記参照)。 これらは、指定した HTTPS サーバのコンテンツ キャッシングを有効にするために必要な最低限の設定です。

ContentEngine(config-https)# cert ?
WORD Certificate name
ContentEngine(config-https)# key ?
WORD Private key name
ContentEngine(config-https)# host ?
WORD FQDN or ip address of the origin HTTPS server
ContentEngine(config-https)# enable
 

cert および key コマンド オプションを使用して、Content Engine をオリジン HTTPS サーバとして機能させるため、Content Engine が一連の SSL 証明書と鍵を使用できるように設定します。 Content Engine は、クライアントからの HTTPS トラフィックをデコードして、キャッシングや要求処理など、通常の HTTP 操作を行うことが可能になります. Content Engine は、キャッシュ ミス(またはキャッシュ検証)時に、オリジン サーバへの HTTPS 接続を開始して、複数のオリジン サーバからコンテンツを取り出します。 詳細は、「スタンドアロン Content Engine における HTTPS サーバの設定」を参照してください。

ステップ 6 必要に応じて、SLL 通信のあらゆる側面に関してより細かく制御できる高度な HTTPS サーバ設定を行います。

a. 証明書グループを設定します。 「HTTPS キャッシングに使用する証明書グループの設定」を参照してください。

b. Content Engine が SSL Version 2 だけを使用するよう設定します。 protocol-version sslv2-only コマンド オプションまたは https server name protocol-version sslv2-only グローバル設定コマンドを使用します。

ContentEngine(config-https)# protocol-version ?
sslv2-only Only use and understand SSL v2 protocol
sslv23-tlsv1 Use and understand SSL v2/v3 and TLS v1 protocols (default)
sslv3-only Only use and understand SSL v3 protocol
tlsv1-only Only use and understand TLS v1 protocol
 

または

CONTENTENGINE(config)# https server name protocol-version ?
sslv2-only Only use and understand SSL v2 protocol
sslv23-tlsv1 Use and understand SSL v2/v3 and TLS v1 protocols (default)
sslv3-only Only use and understand SSL v3 protocol
tlsv1-only Only use and understand TLS v1 protocol
 

c. 必要に応じて、特定の環境の要件に合わせて、デフォルトの HTTPS サーバ認証設定を変更します。 たとえば、serverauth ignore コマンド オプション(下記参照)、 または、 https server name serverauth ignore グローバル設定コマンドを使用して、HTTPS サーバ認証において発生する特定のエラーを無視します。

ContentEngine(config-https)# serverauth ignore ?
cert-not-yet-valid Ignore errors caused by using the certificate be
valid
domain-name Ignore errors due to domain name mismatch
expired-date Ignore certificate expiration errors
invalid-ca Ignore errors caused by an unrecognized CA
 

d. 必要に応じて、デフォルトのセッション キャッシュ設定を変更し、特定の要件に合わせた設定を行います。 session-cache コマンド オプション(下記)、または、 https server name session-cache グローバル設定コマンドを使用します。 たとえば、size オプションを使用して、SSL セッション キャッシュ サイズ設定を指定します。 デフォルトは、10,000 エントリです。 有効な値は 0 ~ 20,000 エントリです。

ContentEngine(config-https)# session-cache ?
size SSL session cache size setting
timeout SSL session cache timeout setting
 


 

スタンドアロン Content Engine における HTTPS サーバの設定

https server server-name グローバル設定コマンドを使用して Content Engine にオリジン HTTPS サーバ名を指定した後、指定された HTTPS サーバに使用する一連のパラメータを指定できます(下記の例を参照)。 これらのパラメータは、HTTPS 設定サブモードまたはグローバル設定モードから指定できます。

ContentEngine(config)# https server abc1
ContentEngine(config-https)#?
cert Select certificate to use for the HTTPS server
certgroup Select certificate chains for the HTTPS server
enable Enable caching of the HTTPS server
host Input hostname or ip address of the origin HTTPS serve
key Select private key to use for the HTTPS server
protocol-version SSL protocol versions for client/server communication
serverauth HTTPS server authentication commands
session-cache SSL session caching parameters tuning
<cr>
 

表 6-9 は、スタンドアロン Content Engine 上で HTTPS サーバ設定を行うためのグローバル設定コマンドを説明します。

表 6-9 HTTPS 透過キャッシングの設定に使用する CLI コマンド

コマンド
目的

https server name cert

https server name key

一連の SSL 証明書とキーを使用するように Content Engine を設定し、Content Engine をオリジン HTTPS サーバとして動作させます。 Content Engine はクライアントからの HTTPS トラフィックをデコードし、キャッシングや要求処理など通常の HTTP 操作を実行できます。 キャッシュ ミス(またはキャッシュ 検証)の際には、Content Engine はオリジン サーバとの HTTPS 接続を開始し、コンテンツをオリジン サーバから取り出すことができます。

https server name host

オリジン HTTPS サーバの IP アドレスを指定します。 このコマンドを使用する場合は、HTTPS サーバとして動作している本社の Content Engine の IP アドレスを使用します。 https server name enable グローバル設定コマンドを使用すると、この HTTPS サーバの使用が可能になります。

https server name protocol-version

クライアントと HTTPS サーバ間の通信を制御するために使用する SSL プロトコル バージョンを設定します。

https server name serverauth

HTTPS サーバへのアクセスに認証を使用できます。 また、無効な認証、ドメイン名の不一致、証明書の有効期限エラー、未認識の CA(認証機関)などの認証エラーを無視する認証も設定できます。 デフォルトでは、HTTPS サーバ認証は、Content Engine 上で有効になっています。 ignore コマンド オプションを使用して、HTTPS サーバ認証において発生する特定のエラーを無視します。

https server name session-cache

Content Engine 上の SSL セッションについて、サイズとタイムアウトを指定します。

size オプションを使用して、SSL セッション キャッシュ サイズ設定を指定します。 デフォルトは、10,000 エントリです。 有効な値は 0 ~ 20,000 エントリです。

timeout オプションを使用して、SSL セッション キャッシュ タイムアウト設定を指定します。 デフォルト値は 3,600 秒です。 有効な値は 1 ~ 86,400 秒です。

HTTPS キャッシングに使用する証明書と秘密鍵の設定

ACNS ソフトウェア リリース 5.1 以降のバージョンでは、HTTPS キャッシングをサポートするために、Content Engine CLI を使用して Content Engine に証明書と秘密鍵を設定することができます(Content Engine GUI では、この設定機能は現在サポートされていません)。

https EXEC コマンドを使用して、スタンドアロン Content Engine をHTTPS サーバとして使用する際の証明書と秘密鍵を作成、削除およびインポートします。 表 6-10 は、 https cert cert-name および https key key_name EXEC コマンドについて説明します。

 

表 6-10 https cert および https key EXEC コマンドに使用するパラメータ

パラメータ
説明

cert

証明書の作成、削除、およびインポートを可能にします。

cert-name

証明書の名前。

add-cert

外部ソースから証明書を追加します。

create

証明書に名前を定義します。

remove

指定した名前をもつ証明書を削除します。

key

秘密鍵の作成、削除、およびインポートを可能にします。

key_name

公開鍵および秘密鍵ペアの名前。

create

秘密鍵の名前を定義します。

import

外部ソースから秘密鍵をインポートします。

remove

指定した名前をもつ鍵を削除します。

url

秘密鍵または証明書の位置を指定する URL の使用を可能にします。

URL

秘密鍵または証明書の位置を指定する URL(HTTP、FTP-over-HTTPまたはHTTPS)。

https server グローバル設定コマンドを使用して、Content Engine が設定済みであることを前提とする HTTPS サーバに証明書と関連する鍵を割り当てて、鍵をそのサーバと関連付けることができます。 Content Engine は、HTTPS サーバに対して要求を作成する HTTPS クライアントに証明書を提示します。

https cert EXEC コマンドを使用して、特定の名前を付けて証明書を作成、外部ソースから証明書をインポート、または、既存の証明書を削除します。


) 秘密鍵および証明書は、PEM(Privacy-Enhanced Mail)形式である必要があります。 秘密鍵および証明書が、PKCS12(Public Key Cryptography Standards 12)形式である場合、Content Engine は、秘密鍵または証明書をインポートする際にこれらを内部で PEM に変換します。


HTTPS キャッシングに使用する証明書グループの設定

ACNS ソフトウェア リリース 5.1 以降のバージョンでは、HTTPS キャッシングをサポートするために、Content Engine CLI を使用して Content Engine に証明書グループを設定することができます(Content Engine GUI では、この設定機能は現在サポートされていません)。

証明書グループは、ルート認証局(Certificate Authority)からエンド エンティティまでの信頼関係チェーンを示すために形成されます。 エンド エンテイティの証明書を除く証明書グループ内の各証明書は、そのチェーン内で次の証明書に署名し、その証明書を信頼します。 エンド エンテイティの証明書は、証明書グループ内でこの証明書につながるすべての証明書が信頼できる場合にのみ信頼されます。 証明書グループを使用すると、HTTPS サーバの証明書が単一であるかのように見せることができますが、それ以外にもクライアントがすべての証明書をローカルでもつ必要がないという利点があります。 また、証明書グループを使用することによって、サーバの証明書を証明書グループと比較して HTTPS サーバを検証および認証することもできます。

https certgroup cert-name EXEC コマンドを使用して、スタンドアロン Content Engine 上で、証明書グループを作成、削除または形成します。 表 6-11 は、 https certgroup cert-name EXEC コマンドのパラメータを説明します。

 

表 6-11 certgroup EXEC コマンドのパラメータ

パラメータ
説明

certgroup

証明書グループの追加または削除を可能にします。

cert-name

証明書グループの名前。

import

証明書グループに対して証明書のチェーンを追加します。

create

指定した名前で証明書グループを作成します。

remove

指定した名前をもつ証明書グループを削除します。

スタンドアロン Content Engine における HTTPS 発信プロキシ サーバの設定

https proxy outgoing host グローバル設定コマンドを使用して、HTTPS 発信プロキシを使用するよう Content Engine を設定すると、すべての受信 HTTPS 要求が、この発信プロキシに送信されます。 proxy-protocols outgoing-proxy exclude グローバル設定コマンドは、HTTPS を含めて、すべてのプロキシ サーバ プロトコルに有効なグローバル プロキシ除外ドメインを指定します。

発信プロキシが設定されている場合、Content Engine は次のロジックを適用します。

宛先サーバがグローバル除外オプションによって指定されている場合、宛先 サーバに直接進む。

宛先サーバがグローバル除外オプションによって指定されず、要求が HTTPS でない場合、宛先サーバに直接進む。

宛先サーバがグローバル除外オプションによって指定されない場合、発信プロキシ サーバに進む。

Content Engine が別のプロキシ サーバに対するプロキシ要求を代行受信し、HTTPS 用に設定された発信プロキシがないときに、 proxy-protocols transparent default-server グローバル設定コマンドが起動される場合、Content Engine はその要求を、クライアントが意図したプロキシ サーバではなく、宛先サーバに直接アドレス指定します。 ただし、Content Engine 上で proxy-protocols transparent reset グローバル設定コマンドが使用され、キャッシュ ミスが発生した場合は、クライアントが送信し透過的に代行受信されたすべての要求は、クライアントに戻され、要求されたオブジェクトは、配信されません。 スタンドアロン Content Engine における HTTPS 発信プロキシの除外の設定に関する詳細は、「HTTP および HTTPS 発信プロキシの除外設定」 を参照してください。

次の例は、(非透過フォワード プロキシとして動作する)Content Engine を HTTPS プロキシ サーバとして設定し、クライアント ブラウザからの HTTPS 要求をポート 8081 で受信させる方法を説明します。

ContentEngine(config)# https proxy incoming 8081
 

この例では、Content Engine A が、キャッシュ ミス HTTPS トラフィック(HTTPS コンテンツ[HTTPS-over-HTTP 要求] についてのブラウザの要求におけるキャッシュ ミス)をホスト 10.1.1.1 のポート 8088 へ送信するよう設定されます。Content Engine A に対するプライマリ発信 HTTPS プロキシ サーバとして、ホスト 10.1.1.1 が明示的に指定されます。ホスト 10.1.1.2 は、Content Engine A に対するバックアップ発信 HTTPS プロキシ サーバとして指定されます。

ContentEngineA(config)# https proxy outgoing host 10.1.1.1 8088 primary
ContentEngine(config)# https proxy outgoing host 10.1.1.2 220
 

ACNS ソフトウェア リリース 5.1.x 以前のバージョンでは、Content Engine に設定できる発信 HTTPS プロキシ サーバは 1 台だけでした。 ACNS 5.2 ソフトウェアでは、最大 8 台の発信 HTTPS プロキシ サーバを使用するよう Content Engine を設定する機能が追加されました。 このトピックに関する詳細は、「スタンドアロン Content Engine の ためのプライマリおよびバックアップ プロキシ サーバの設定」を参照してください。

透過モードでは、別の HTTPS プロキシ サーバに対するすべての HTTPS プロキシ スタイルの要求が、受け入れられます。 Content Engine は、 proxy-protocols transparent グローバル設定コマンドに従って、透過的に受信されたこれらの要求を処理します。 このトピックに関する詳細は、「HTTP および HTTPS 発信プロキシの除外設定」を参照してください。

任意の宛先ポートに対する不要アクセスの防止

宛先ポートへのアクセスを制御(許可または拒否)するルールが設定されていない場合、Content Engine は、必要なセキュリティ レベルを提供できない場合があります。


注意 宛先ポートへのアクセスを制御するポリシーが設定されていない場合、Content Engine は、期待するレベルのセキュリティを提供できない場合があります。 そのため、宛先ポートに対して HTTPS トラフィックを許可または拒否する制限を設定することを強くお奨めします。 デフォルトの設定では、期待するレベルのセキュリティが提供されない場合があります。

Web ユーザが HTTPS サーバ以外のサーバに HTTPS トンネルを作成しないようにするために、宛先ポートへのアクセスを制限できます。 この制限は個別のポートまたはすべてのポートに適用できます。 制限ルールに矛盾がある場合には、個別のポート設定が 殿ll・ルールよりも優先し、蚤llow・ルールが 電eny・ルールよりも優先します。

宛先ポートへのアクセス防止は、WCCP 透過リダイレクト(WCCP Version 2 対応ルータが HTTPS要求を透過的に代行受信し、Content Engine へリダイレクトする仕組み)、および、直接プロキシ ルーティング(クライアント ブラウザが各自の HTTPS 要求を Content Engine に直接送信する仕組み)を使用してサポートされます。

Content Engine GUI または CLI(下記参照)を使用して、この機能を設定できます。 Content Engine GUI から行う場合は、 Cache > HTTPS Proxy の順に選択し、表示された HTTPS Proxy ウィンドウを使用して、宛先ポートを制限します。 HTTPS Proxy ウィンドウの使用方法に関する詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI を使用するには、次のコマンドを入力します。

ContentEngine(config)# https destination-port ?
allow Allow HTTPS traffic to port (443 and 563 allowed by default)
deny Deny HTTPS traffic to port (port under 1024 denied by default)
 

要求が Content Engine を通過しているとき、いずれかの宛先 HTTPS ポートへの不要のアクセスを防ぐには、次の一連のコマンドを使用します。

ContentEngine(config)# no https destination-port allow 443 563
ContentEngine(config)# https destination-port deny all
 

これらの一連のコマンドは、1024 より上、および 1024 より下のすべてのポートへのアクセスを拒否します。ポート 443、およびポート 563(標準の HTTPS ポート)に対しては、 no https destination-port allow 443 563 グローバル設定コマンドを使用して、明示的にアクセスを拒否する必要があります。


) TCP パケットおよび UDP パケットは、使用するアプリケーションによって定義されるポート番号を使用します。 一般的にポート範囲 0 ~ 255 は、FTP などの標準的な公的アプリケーションに使用され、ポート範囲 256 ~ 1023 は、各会社が非標準的なアプリケーションに使用します。 たとえば FTP はポート 21 を使用し、Telnet はポート 23 を使用します。1024 ~ 65,536 のポート番号には、制約がありません。したがって、いずれかのポート番号を介したアクセスを特別に拒否する場合に、最適な番号として使用できます。


たとえば、これらのコマンドが Content Engine で設定されており、https://banking.wellsfargo.com のポート xxx にアクセスする要求が、WCCP 透過リダイレクトまたは直接プロキシ ルーティングのいずれかによって、この Content Engine にリダイレクトされる場合、xxx ポートへの接続は拒否されます。

スタンドアロン Content Engine における FTP キャッシングの設定

ここでは、スタンドアロン Content Engine において利用できる FTP キャッシング機能の概要、および、次に示すさまざまなタイプの FTP キャッシングの設定方法を説明します。

スタンドアロン Content Engine における ネイティブ FTP キャッシングの設定

スタンドアロン Content Engine における FTP-over-HTTP キャッシングの設定

Content Engine は、プロキシ モードに設定されているときに、FTP スタイルの要求を HTTP 転送によって処理できます。 Content Engine が FTP 要求をクライアントから受信すると、キャッシュを検索して要求を処理します。 オブジェクトがキャッシュにない場合、Content Engine は、アップストリームの FTP プロキシ サーバからオブジェクトを取り出すか(このプロキシ サーバが設定されている場合)、またはオリジン FTP サーバからオブジェクトを直接取り出します。

ACNS ソフトウェア リリース 5.1 以降では、Content Engine(透過プロキシ サーバ)とWCCP Version 2 対応ルータを使用したネイティブ FTP キャッシングもサポートしています。 Content Engine GUI または CLI を使用して、スタンドアロン Content Engine 上で FTP キャッシングを設定できます。

スタンドアロン Content Engine を使用したFTP キャッシングの概要

ACNS ソフトウェア リリース 5.1 以降を実行しているスタンドアロン Content Engine では、次の 2種類の使用モードで FTP キャッシングの設定ができます。

ネイティブ FTP モード。スタンドアロン Content Engine(透過プロキシ サーバ)が、ネイティブ FTP プロトコルのクライアントから送信された FTP 要求のコンテンツをキャッシュします。

FTP-over-HTTP モード。非透過フォワード プロキシ サーバとして動作しているスタンドアロン Content Engine が、HTTP プロトコルを使用しているクライアントによって直接送信された、特定の FTP URL のコンテンツをキャッシュします。 これにより、ユーザは、HTTP プロトコルを利用しているブラウザを使用して、リモートの FTP サーバにあるファイルの送受信を行えます。

どちらのモードにおいても、Content Engine は、FTP プロトコルを使用して、FTP 要求のコンテンツを取得し、ローカルにキャッシュします。 これら 2 つの使用モードは、FTP 要求を発信するクライアントの使用するプロトコルが異なります。 FTP-over-HTTP モードにおいて、クライアントはブラウザ(HTTP プロトコル)を使用して FTP要求を発行します。 ネイティブ FTP モードにおいて、クライアントは、ネイティブ FTP プロトコルを使用して FTP要求を発行します。次に例を示します。

ContentEngine# ftp server.cisco.com

) ACNS ソフトウェア リリース 5.1 および 5.2 では、ネイティブ FTP キャッシングは、透過プロキシ モードの場合のみ使用でき、非透過プロキシ モードの場合は使用できません。 FTP 要求の透過リダイレクトは、WCCP Version 2 を使用した場合のみサポートされ、レイヤ 4 スィッチを使用した透過リダイレクトはサポートされません。

ネイティブ FTP 要求は、スタンドアロン Content Engine の HTTP トランザクション ログにロギングされます。


ネイティブ FTP キャッシングのサポートについて

FTP プロキシとして動作しているスタンドアロン Content Engine は、ファイルおよびディレクトリのフェッチに対して、パッシブ モードとアクティブ モードをサポートしています。 ネイティブ FTP キャッシング モードにおいて、 ftp proxy active-mode enable グローバル設定コマンドが使用された場合、Content Engine は、クライアントからのアクセスに使用されたモードと同じモード(アクティブまたはパッシブのいずれか)を使用して、FTP サーバへのデータ接続を行います。 ftp proxy active-mode enable コマンドが指定されない場合、Content Engine は、パッシブ モードを使用して、FTPサーバへのデータ接続を行います。

次に示す、 show ftp EXEC コマンドの出力結果の一部は、 ftp proxy active-mode enable グローバル設定コマンドを使用した場合に、Content Engine(ネイティブ FTP プロキシ サーバとして機能している非透過プロキシ サーバ)がクライアントのモード(アクティブまたはパッシブ)に従っていることを表します。

Content Engine(ネイティブ FTP プロキシ サーバ)は、FTP クライアントがアクティブ モードのデータ転送要求を発行した場合、FTP サーバとの間でアクティブ モードのデータ送受信を実行。

Content Engine は、FTP クライアントがパッシブ モードのデータ転送要求を発行した場合、FTP サーバとの間でパッシブ モードのデータ送受信を実行。

ContentEngine# show ftp
 
FTP Configuration
-----------------
 
WCCP FTP service status: ENABLED
Maximum size of a FTP cacheable object: 204800 KBytes
FTP data connection mode with Server: Adhere to Client's mode (active or passive)
 

Content Engine(ネイティブ FTP プロキシ サーバとして機能している非透過プロキシ サーバ)が、ネイティブ FTP 要求の作成に使用する URLの形式は、FTP ログイン名と転送モード(バイナリまたは ACSII ファイル転送モード)によって異なります。

FTP ログイン名が「匿名」ではなく実際のユーザ名である場合、文字列「*user*:*password*@&」が URL のホストの前に含まれます。

ファイルの転送に使用されているモードがバイナリ モードである場合、文字列「type=i」が URL の後ろに含まれます。 次の例は、バイナリ モードが使用されているときに、Content Engine が特定のユーザのために作成する URL 形式です。

ftp://*user*:*password*@10.100.200.5/home/myhome/mybinfile.obj;type=i
 

「匿名」ユーザ ログインおよびASCII ファイル転送モードの場合の URL には、いずれのフィールドも埋め込まれていません(下記の例を参照)。

ftp://10.100.200.5/home/myhome/mytextfile.txt
 

次の 2 つの例では、Content Engine を使ってネイティブ FTP を使用します。 1 つ目の例では、ユーザは、実際のユーザ名、「huff」でログインし、 FTP サーバから要求ファイル(test.c)を取得できます。 この場合、「huff」という名前を持つユーザの現行ディレクトリは「/home/huff」です。

ContentEngine# ftp server.cisco.com
Connected to server.cisco.com.
220 server.cisco.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.
Name (server:huff): huff
331 Password required for myserver.
Password:
230 User huff logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> pwd
257 "/home/huff" is current directory.
ftp> get /tmp/test.c
200 PORT command successful.
150 Opening BINARY mode data connection for /tmp/test.c (645 bytes).
226 Transfer complete.
645 bytes received in 0.00077 seconds (8.2e+02 Kbytes/s)
ftp> quit
ContentEngine#
 

次の例では、ユーザは、匿名ユーザとしてログインし、要求ファイル(test.c)が FTP サーバのドキュメント ルート ディレクトリ(「/」、これは、任意の匿名ユーザの現行ディレクトリです)にないため、これを取得できません。

ContentEngine# ftp server.cisco.com
Connected to server.cisco.com.
220 server.cisco.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.
Name (server:huff): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: test@cisco.com
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> pwd
257 "/" is current directory.
ftp>
ftp> passive
Passive mode on
ftp> get
(remote-file) /tmp/test.c
(local-file) test.c
local: test.c remote: /tmp/test.c
227 Entering Passive Mode (172.31.255.255)
550 /tmp/test.c: No such file or directory.
ftp>
ContentEngine#

FTP-Over-HTTP キャッシングのサポートについて

ACNS ソフトウェア リリース 5.1 以降は、URL で FTP プロトコルが指定されている場合に(たとえば、 ftp://ftp.mycompany.com/ftpdir/ftp_file )、プロキシ モードの HTTP 要求を使用した FTP URL クライアント要求のプロキシ処理とキャッシングをサポートします。 次に示す FTP-over-HTTP 要求の例は、エンドユーザが、ブラウザを使用して FTP サーバの一般的なファイルにアクセスする方法を表します。

ftp://ftp.funet.fi/pub/cbm/crossplatform/converters/unix/
 

これらの要求では、クライアントは、Content Engine との転送プロトコルとして HTTP を使用します。一方、Content Engine は、FTP サーバとの転送プロトコルとして FTP を使用します。 Content Engine が Web クライアントから FTP 要求を受信すると、まず、キャッシュを調べます。 オブジェクトがそのキャッシュにない場合、アップストリーム FTP プロキシ サーバ(設定されている場合)から、またはオリジン FTP サーバから直接、オブジェクトをフェッチします。

FTP プロキシは、認証されている FTP 要求だけでなく、匿名の FTP 要求もサポートします。 認証には base64 エンコーディングだけがサポートされます。 FTP プロキシは、RFC 1738 で定義されているすべての FTP URL 方式を受け入れます。 ftp://user@site/dir/file 形式の URL の場合、プロキシは認証の失敗応答を戻し、ブラウザはユーザがログイン情報を入力するポップアップ ウィンドウを表示します。

FTP プロキシでは、一般的に使用されている MIME タイプをサポートします。FTP プロキシを使用すると、クライアントに対応するヘッダーを添付したり、適切な転送タイプ(バイナリまたは ASCII)を選択したり、ブラウザで設定されているアプリケーションを使用して FTP ファイルを開くことができます。 不明なファイル タイプの場合、プロキシはデフォルトとしてバイナリ転送を使用し、このダウンロード ファイルを開かずに保存するようにブラウザに指示します。 FTP サーバが既知のフォーマットのディレクトリ リストを付けた応答を返す場合、FTP プロキシはフォーマットされたディレクトリ リストをクライアントに戻します。 このフォーマットされたディレクトリ リストには、ファイルまたはディレクトリの詳細な情報が含まれていて、ユーザはダウンロードの転送タイプを選択できます。

FTP キャッシュ 新鮮度について

ACNS 5.x ソフトウェアでは、HTTP オブジェクト、および FTP オブジェクトの新鮮度とキャッシュ ヒット率とのバランスを取るように調整することができます。 ACNS ソフトウェアのデフォルト パラメータに重み付けをして、キャッシュ ヒット率の最大化よりも新鮮度の高いコンテンツの確保を優先しています。この方法で古いコンテンツをサービスしてキャッシュ ヒット率を上げるという望ましくない状況を避けています。


ヒント テキスト オブジェクトとは、HTML ページを意味します。 バイナリ オブジェクトとは、GIF、JPEG など、その他すべての Web オブジェクトを意味します。


Content Engine GUI または CLI を使用して、スタンドアロン Content Engine に対して FTP キャッシュ オブジェクトの新鮮度設定値を設定することができます。これらのパラメータは、ディレクトリ リストに対しても、キャッシュ内の特定のオブジェクトに対しても設定できます。

Content Engine GUI から行う場合は、 Caching > FTP Freshness の順に選択し、表示された FTP Freshness ウィンドウを使用します。 このウィンドウに関する詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から行う場合は、 ftp object max-size グローバル設定コマンドを使用して、ネイティブ FTP キャッシングおよび FTP-over-HTTP キャッシングに使用する FTP オブジェクトの最大サイズを指定します。

FTP-over-HTTP キャッシングについては、 ftp age-multiplier , ftp max-ttl , ftp object , ftp reval-each-request 、および、 ftp min-ttl グローバル設定コマンドも使用できます。 次の例では、FTP-over-HTTP キャッシングに使用するディレクトリ リスト オブジェクトとファイル オブジェクトに対して、キャッシュの最大存続可能時間(Time To Live)を 3 日に設定します。

ContentEngine(config)# ftp max-ttl days directory-listing 3 file 3
 

次の例では、FTP-over-HTTP キャッシングにおいて、最短で 10 分、最長で 24 時間(1 日)、FTP オブジェクトをキャッシュ内に保持するように、Content Engine を設定します。

ContentEngine(config)# ftp min-ttl 10
ContentEngine(config)# ftp max-ttl hours directory-listing 24 file 24

ACNS 5.1 および 5.2 ソフトウェアのネイティブ FTPキャッシングに関する制約事項

ACNS ソフトウェア リリース 5.1 および 5.2 のネイティブ FTPキャッシング サポートに関する制約事項は次のとおりです。

FTP オブジェクトのサイズは最大 200 メガ バイト

FTP クライアントと FTP サーバ プルに対する帯域幅管理については未サポート

FTP クライアント要求における ToS(Type of Service) ビットの使用については未サポート

cdnfs への事前配信ファイルについては未サポート

ICAP については未サポート

非透過プロキシについては未サポート

プロキシ認証については未サポート

ICP については未サポート

ヒーリング モードについては未サポート

レイヤ 4 FTP リダイレクトについては未サポート

FTP 要求プロキシ ルールについては未サポート

MIN-TTL および AGING-HEURISTIC-TTL キャッシュ コントロール ノブ設定については未サポート

URL フィルタリング スキーマ(good リスト、bad リスト、N2H2、Websense および SmartFilter)についてはすべて未サポート

Macintosh FTP サーバからのファイルのキャッシングについては未サポート

FTP プロキシ サーバの「オフライン」操作については未サポート

スタンドアロン Content Engine における ネイティブ FTP キャッシングの設定

FTP サービス(サービス 60)は、WCCP Version 2 対応ルータから Content Engine 上の単一のポートにネイティブ FTP要求を透過的にリダイレクトできる WCCP キャッシング サービスです。 Content Engine は、要求された FTP コンテンツを取得し、(FTP キャッシングを実行して)ローカルにコピーし、要求コンテンツをそのクライアントに提供します。 ネイティブ FTP キャッシングについての基本的な情報は、「ネイティブ FTP キャッシングのサポートについて」 を参照してください。

スタンドアロン Content Engine(透過プロキシ サーバ)と WCCP Version 2 対応ルータを使用して、ネイティブ FTP キャッシングを設定する手順は、次のとおりです。


ステップ 1 wccp ftp router-list-number および wccp ftp mask グローバル設定コマンドを使用して、スタンドアロン Content Engine にネイティブ FTP キャッシングを設定します。 wccp ftp グローバル設定コマンドを使用して、FTP クライアントから FTP サーバへの FTP プロトコル トラフィックを WCCP 代行受信するよう設定します。

ContentEngine(config)# wccp ftp ?
mask Specify mask used for CE assignment
router-list-num Router list number
ContentEngine(config)# wccp ftp mask ?
dst-ip-mask Specify sub-mask used in packet destination-IP address
src-ip-mask Specify sub-mask used in packet source-IP address
ContentEngine(config)# wccp ftp router-list-num ?
<1-8> Router List Number
 

ステップ 2 ftp proxy active-mode グローバル設定コマンドを使用します。

ネイティブ FTP キャッシング モードにおいて、このコマンドが使用された場合、Content Engine は、クライアントからのアクセスに使用されたモードと同じモード(アクティブまたはパッシブのいずれか)を使用して、FTP サーバへのデータ接続を行います。 このコマンドが使用されない場合、Content Engine は、パッシブ モードを使用して FTP サーバへのデータ接続を行います。

ステップ 3 show wccp services EXEC コマンドを入力して、FTP プロキシに関する設定情報を表示します。

ContentEngine# show wccp services
Services configured on this Content Engine
Web-cache
Custom Web Cache
FTP Cache
RTSP
 

ステップ 4 show wccp modules EXEC コマンドを入力して、FTP キャッシング サービスが Content Engine 上で有効になっていることを確認します。

ContentEngine# show wccp modules
Modules registered with WCCP on this Content Engine
 
Module Socket Expire(sec) Name Supported Services
------ ------ ----------- --------------- ------------------
5 6 3 FTP Proxy FTP Cache
 
1 7 3 RTSP Proxy RTSP
 
0 8 3 HTTP Proxy Web Cache
Reverse Proxy
Custom Web Cache
WCCPv2 Service 90
WCCPv2 Service 91
WCCPv2 Service 92
WCCPv2 Service 93
WCCPv2 Service 94
WCCPv2 Service 95
WCCPv2 Service 96
WCCPv2 Service 97
 
ContentEngine# show wccp masks ?
custom-web-cache Custom web caching service
ftp FTP Proxy caching service
reverse-proxy Reverse Proxy web caching service
rtsp Media caching service
web-cache Standard web caching service

ステップ 5 show ftp EXEC コマンドを入力して、Content Engine のキャッシュ内の FTP オブジェクトに対して行われた設定変更を表示します。

ContentEngine# show ftp
FTP over HTTP Configuration
---------------------------
 
FTP heuristic age-multipliers: directory-listing 30% file 60%
Maximum time to live in days: directory-listing 3 file 7
Minimum time to live for all objects in minutes: 30
Incoming Proxy-Mode:
Configured Proxy mode FTP connections on ports: 80 8080
Outgoing Proxy-Mode:
Not using outgoing proxy mode.
Active mode of FTP transfer is enabled
Maximum size of a FTP cacheable object is 204800 KBytes
No object is revalidated on each request
 
FTP Configuration
-----------------
 
WCCP FTP service status: ENABLED
Maximum size of a FTP cacheable object: 204800 KBytes
FTP data connection mode with Server: Adhere to Client's mode (active or passive)
 

ステップ 6 ip wccp コマンドを使用して、WCCP Version 2 対応ルータにネイティブ FTP キャッシングを設定します。

a. ルータのネイティブ FTP キャッシング(サービス 60)をオンにします。

Router(config)# ip wccp 60
 

b. ネイティブ FTP キャッシング サービスを実行するインターフェイスを指定します。

Router(config)# interface type number
 

c. ネイティブ FTP キャッシング サービスに送信インターフェイスを使用するよう、ルータを設定します。

Router(config-if)# ip wccp 60 redirect out
 


 

スタンドアロン Content Engine における FTP-over-HTTP キャッシングの設定

Content Engine GUI または CLI を使用して、スタンドアロン Content Engine 上で FTP-over-HTTP キャッシングを設定できます。(非透過フォワード プロキシ サーバ) スタンドアロン Content Engine は、FTP-over-HTTP キャッシングを使用することで、クライアント ブラウザからの FTP-over-HTTP 要求に対する非透過フォワード プロキシ サーバとして機能します。 このタイプのキャッシングに関する基本的な情報は、「FTP-Over-HTTP キャッシングのサポートについて」 を参照してください。

Content Engine GUI から行う場合は、 Caching > FTP Proxy の順に選択し、表示された FTP Proxy ウィンドウを使用します。 FTP Proxy ウィンドウを使用して FTP-over-HTTP キャッシングの設定を行う方法に関する情報の詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から設定する手順は次のとおりです。


ステップ 1 ftp proxy incoming ports グローバル設定コマンドを使用して、プロキシ モード要求の受信に使用するポート番号を設定します。

ftp proxy incoming ports

ここで、 ports は、スタンドアロン Content Engine がポート 80 に加えてクライアント ブラウザから FTP-over-HTTP 要求受信を受け入れるポート番号です。有効なポート番号は、1 ~ 65535 です。最大 8 つのポートを指定できます。

次の例では、ポート 8080、8081 および 9090 で FTP-over-HTTP 要求(クライアント ブラウザからの FTP 要求)を受け取るよう Content Engine を設定します。同じコマンドラインで最大 8 つのポートを設定できます。

ContentEngine(config)# ftp proxy incoming 8080 8081 9090
 

このコマンドを使用して、ポート 80 以外のポートで HTTPS-over-HTTP を受け入れるよう Content Engine を設定する場合は、それらの HTTPS 要求を Content Engine 上のそのポートに送信するよう、クライアント ブラウザも設定する必要があります。 詳細は、「クライアント ブラウザに直接スタンドアロン Content Engine を指定」を参照してください。

ステップ 2 ftp object max-size グローバル設定コマンドを使用して、Content Engine キャッシュに保存される FTP オブジェクトの最大サイズを指定します。

次の例では、FTP オブジェクトの最大サイズを 2 メガバイト に設定します。

ContentEngine(config)# ftp object max-size 2000
 

ステップ 3 ftp reval-each-request all グローバル設定コマンドを使用して、すべての FTP-over-HTTP 要求に対するすべてのオブジェクトを、Content Engine に再検証させます。

ContentEngine(config)# ftp reval-each-request all
 

ステップ 4 ftp proxy outgoing host グローバル設定コマンドを使用して、Content Engine に使用する 1 台または複数台の発信 FTP プロキシ サーバを設定します。 発信 FTP プロキシ サーバのホスト名または IP アドレスを入力します。 プライマリ発信 FTP プロキシ サーバは、ICP または WCCP を使用せずにすべてのミス FTPトラフィックをこの Content Engine から送信させたい親キャッシュ(アップストリーム FTP プロキシ サーバ)です。

ACNS ソフトウェア リリース 5.2 より前のバージョンでは、FTP プロトコルに対して指定できる発信プロキシ サーバは、1 台だけでした。 ACNS 5.2 ソフトウェアでは、FTP-over-HTTP プロキシ要求に対し、最大 8 台の発信プロキシサーバを指定できます。 最大 8 台の発信プロキシサーバをサポートできる利点は、1 台の発信 プロキシ サーバに障害が発生した場合に、Content Engine が、次に指定されている発信プロキシ サーバにフェールオーバーされるため、冗長性が高まることです。 すべての発信要求は、プライマリ発信プロキシ サーバに送られます。 プライマリ プロキシ サーバに障害が発生した場合、要求はリストにある次のアクティブのプロキシ サーバに送られます。


ヒント show ftp proxy EXEC コマンドを使用して、スタンドアロン Content Engine 上に現在設定されている 各 FTP プロキシ サーバの現在の状態を確認します。

最初に指定された発信 FTP プロキシ サーバは、デフォルトでプライマリ発信 FTP サーバとして指定されます。 次の例では、Content Engine A が、キャッシュ ミス FTP トラフィック(FTP コンテンツ[FTP-over-HTTP 要求]についてのブラウザの要求におけるキャッシュ ミス)をホスト 10.1.1.1 のポート 8088 へ送信するよう設定されます。ホスト 10.1.1.1 は、Content Engine A に対するプライマリ発信 FTP プロキシ サーバとして指定されます。ホスト 10.1.1.2 は、Content Engine A に対するバックアップ発信 HTTPS プロキシ サーバとして指定されます。

ContentEngineA(config)# ftp proxy outgoing host 10.1.1.1 8088
ContentEngine(config)# ftp proxy outgoing host 10.1.1.2 220
 

ステップ 5 ftp proxy anonymous-pswd グローバル設定コマンドを使用して、匿名の FTP 操作の間に使用するパスワードを指定します。

ステップ 6 ftp proxy active-mode enable グローバル設定コマンドを使用して 、アクティブ モードをこの Content Engine 上で有効にします。

FTP-over-HTTP キャッシング モードにおいて、 ftp proxy active-mode グローバル設定コマンドを使用すると、Content Engine はまず、アクティブ モードを使用して FTP サーバへのデータ接続を試みます。 アクティブ モードが失敗すると、Content Engine は、パッシブ モードでデータ接続を試みます。

FTP-over-HTTP キャッシング モードにおいて、 ftp proxy active-mode コマンドを使用しない場合、Content Engine はまず、パッシブ モードを使用して FTP サーバへのデータ接続を試み、パッシブ モードが FTP サーバでサポートされていなければ、アクティブ モードに自動的に切り替えます。


 

スタンドアロン Content Engine における TFTP サーバおよびゲートウェイの設定

ACNS ソフトウェア Release 5.1 以降では、TFTP (Trivial File Transfer Protocol)ゲートウェイ機能によって、Content Engine は、ネイティブ TFTP を使用することでネットワーキング デバイスが要求するコンテンツ ファイルを配信する方式を提供します。 これによって、Content Engine は、TFTP-to-HTTP 変換または TFTP-to-FTP 変換を実行できるようになるため、システム管理者は専用 TFTP サーバを設定および管理して、TFTP 要求を処理する必要がなくなります。 この機能により、Content Engine は、クライアントからのネイティブ TFTP 要求をフロント エンドで受け入れ、その要求を HTTP または FTP プロトコルを使用してバック エンドで処理します。そのため、この機能は TFTP ゲートウェイと呼ばれます。

コンテンツ ファイルには、ルータ ソフトウェア イメージ、ルータ構成、IP フォンの構成ファイルなどが含まれています。 要求したファイルが Content Engine から取得できない場合、Content Engine はそのファイルをオリジン サーバから即座にキャッシュします。 キャッシング エンジンとして機能する Content Engine は、デバイスに代わってファイルをインターネットから取り出し、デバイスに転送します。 Content Engine のローカル キャッシュから転送することで、将来の同一のファイルに対するどのデバイスからの要求も満たします。

コンテンツ ファイルには、ルータ ソフトウェア イメージ、ルータ構成、セット トップ ボックス イメージ、IP 電話の構成ファイルなどが含まれています。 要求したファイルが Content Engine から取得できない場合、Content Engine はそのファイルをオリジン サーバから即座にキャッシュします。 キャッシング エンジンとして機能する Content Engine は、デバイスに代わってファイルをインターネットから取り出し、デバイスに転送します。 Content Engine のキャッシュから転送することで、将来の同一のファイルに対するどのデバイスからの要求も満たします。


) Content Engine は、透過的に代理受信された TFTP 要求をサポートしていません。 Content Engine にアドレス設定される各 TFTP サーバ要求の宛先アドレスは、Content Engine の IP アドレスにする必要があります。


Content Engine 上で TFTP がイネーブルになり、クライアントが、ファイルの TFTP 要求を送信すると、次のイベントが発生します。

1. Content Engine 上の TFTP サーバは、認証のために TFTP アプリケーションに割り当てられるアクセス コントロール リストをチェックします。

2. 要求が認証されると、TFTP サーバは、コンテンツ ファイルの TFTP 要求に指定されたディレクトリをチェックします。 その要求にディレクトリ パスがない場合、サーバは、ファイルのデフォルト ローカル ディレクトリを検索します。

3. 要求されたファイルがローカル ディレクトリにない場合、Content Engine 上の TFTP サーバ モジュールは、HTTP または FTP URL を作成して、それをキャッシング アプリケーションに送信します。

4. キャッシング アプリケーションは、要求されたファイルを最初にキャッシング ファイル システム (cfs)、次に事前配信されたコンテンツ (cdnfs)の中から検索します。 ファイルが見つかった場合、Content Engine 上の TFTP サーバにそのファイルが送信されます。

5. 要求されたファイルが見つからなかった場合、キャッシング アプリケーションは、URL で指定されたオリジン サーバからファイルを要求して、コンテンツをキャッシュします。

6. その後、キャッシュされたファイルは、Content Engine 上の TFTP サーバに送信され、TFT サーバは、ファイルを TFTP クライアントに送ります。 ファイルが見つからなかった場合は、404 「File not found(ファイルが見つかりません)」メッセージがクライアントに送信されます。

スタンドアロン Content Engine 上での TFTP サービスおよびゲートウェイの使用

スタンドアロン Content Engine 上で TFTP サービスおよびゲートウェイを設定して、TFTP 要求に応答してコンテンツをサービスするには、 tftp-server グローバル設定コマンドを次の 2 つの方法で使用します。

ローカル コンテンツをサービスする:これを行うには、Content Engine 上でローカル ディレクトリを設定し、TFTP サーバをイネーブルにする。これについては、次の「TFTP サーバおよびゲートウェイのイネーブル化」で説明されている。

リモート サーバからコンテンツをサービスする:これを行うには、Content Engine 上で、TFTP ゲートウェイ機能を設定する。これについては、次の「TFTP サーバおよびゲートウェイのイネーブル化」で説明されている。

TFTP サーバおよびゲートウェイがイネーブルのときに、TFTP 要求に完全なパス名が指定されていない場合、Content Engine は、デフォルトのローカル ディレクトリ内でファイルを検索して、その TFTP 要求に応答します。 完全なパス名が指定されている場合、Content Engine はそのパス名によって一致するローカル ディレクトリ内でファイルを検索します。 ファイルが見つからない場合は、HTTP または FTP プロトコルを使用して、要求をキャッシング エンジンとして機能している Content Engine に転送します。 ファイルがリモート サーバで見つかった場合、Content Engine はそのファイルをキャッシュして、要求を出したクライアントに送信します。 Content Engine は、それ以後そのファイルの要求に対して、自身のローカル キャッシュから応答します。 ファイルが見つからない場合、Content Engine は 404 「File not found」(ファイルが見つかりません)のメッセージを出して応答します。

デフォルトでは、TFTP サービスはディセーブルとなっており、TFTP サーバへのアクセスは拒否されます。

TFTP サーバに割り当てられているデフォルトのローカル ディレクトリは、 /tftpboot です。 ただし、このディレクトリは mkdir コマンドを使用して作成する必要があります。

TFTP タイムアウト値は 5 秒に固定されており、再試行回数は 5 回で固定されています。 これらの値を変更できません。

TFTP サーバおよびゲートウェイのイネーブル化

ローカル コンテンツに要求をサービスする手順は、次のとおりです。

1. inetd enable tftp グローバル コマンドを使用して、TFTP サービスを有効にします。

2. スタンドアロン Content Engine で、ローカル TFTP ディレクトリを次のように設定します。

a. mkdir コマンドを使用して、ローカル ディレクトリを作成する。

b. tftp-server dir コマンドを使用して、TFTP サーバに対するローカル ディレクトリを識別します。

1 つまたは複数のローカル ディレクトリを識別するのに tftp-server dir コマンドを使用するときは、最初に識別されたディレクトリがデフォルトのディレクトリになります。 識別しようとする各ディレクトリに対して、tftp-server dir コマンドを入力します。

TFTP サーバは、そのデフォルト ディレクトリ内で、完全修飾されたパス名を使用せずにファイルを検索します。 TFTP サーバは、TFTP 要求により目的のディレクトリが明示的に識別されている場合にのみ、他のローカル ディレクトリ内でファイルを検索します。

どのローカル ディレクトリも指定してない場合、 /tftpboot が自動的にデフォルト ディレクトリとして割り当てられます。 ただし、その場合でも、TFTP サーバが要求をサービス可能になる前に、 mkdir コマンドを使用して /tftpboot ディレクトリを作成する必要があります。

コンテンツのサービスをリモート サーバから行うために TFTP ゲートウェイを使用するには、TFTP サーバをイネーブルにして、TFTP ゲートウェイ(スタンドアロン Content Engine)が要求を送信するリモート サーバも識別する必要があります。 要求されたファイルが Content Engine のローカル ディレクトリ内に見つからないとき、Content Engine が要求を送信するサーバを 識別するには tftp-server gw proto コマンドを使用します。 このトピックに関する詳細は、次の「 スタンドアロン Content Engine における TFTP サーバおよびゲートウェイの設定 」を参照してください。

スタンドアロン Content Engine 上で TFTP サーバまたはゲートウェイをイネーブルにするには、次のステップを実行します。

1. inetd enable tftp グローバル設定コマンドを使用して、TFTP サービスをイネーブルにします。

2. ip access-list グローバル設定コマンドを使用して、TFTP サービスへのアクセスを許可するアクセス リストを定義します。

3. tftp-server access-list コマンドを使用して、前述のアクセス リストを TFTP サービスに適用します。

4. tftp-server コマンドの各種オプションを使用して、次の項で説明されているように、TFTP サーバを設定します。


) Content Engine は、透過的な TFTP 要求をサポートしていません。 Content Engine は、Content Engine ホスト名または IP アドレスを明示的に含む要求を受け入れるのみです。


スタンドアロン Content Engine における TFTP サーバおよびゲートウェイの設定

TFTP サーバは、ファイルに対して完全なディレクトリ パスを識別できないような要求を受け取ると、デフォルトのローカル ディレクトリ内でファイルを検索します。 どのローカル ディレクトリも指定してない場合、デフォルト ディレクトリは /tftpboot です。 このディレクトリはデフォルト ディレクトリとして自動的に割り当てられますが、その場合でも mkdir コマンドを使用して、このディレクトリ(または TFTP サーバに割り当てたその他ディレクトリ)を作成する必要があります。

1 つまたは複数のローカル ディレクトリを識別するのに tftp-server dir グローバル設定コマンドを使用するときは、最初に識別されたディレクトリがデフォルトのディレクトリになります。 識別しようとする各ディレクトリに対して、tftp-server dir グローバル設定コマンドを入力します。

TFTP サーバは、TFTP 要求により目的のディレクトリが明示的に識別されている場合にのみ、他のディレクトリ内でファイルを検索します。

tftp-server グローバル設定コマンドを使用して、TFTP サーバおよびゲートウェイの設定をスタンドアロン Content Engine で行う手順は、次のとおりです。


ステップ 1 tftp-server dir グローバル設定コマンドを使用して、TFTP 要求に完全パス名が含まれていない場合に、Content Engine が要求されたファイルを検索する、1 つまたは複数ローカル ディレクトリを識別します。

たとえば、次のコマンドを実行することにより、次の 2 つのローカル ディレクトリが設定されます。これらのディレクトリは、Content Engine が TFTP 要求を満たそうとして、試行するディレクトリです。

ContentEngine(config)# mkdir /local/mydir
ContentEngine(config)# mkdir /local/clients
ContentEngine(config)# tftp-server dir /local/mydir
ContentEngine(config)# tftp-server dir /local/clients
 

最初に指定されたディレクトリ、 /local1/mydir がデフォルトのディレクトリとみなされます。

ステップ 2 tftp-server access-list グローバル設定コマンドを使用して、TFTP サーバおよびゲートウェイにアクセスを許可する IP アクセス コントロール リスト (ACL) を識別します。

tftp-server access-list { acl-num | acl-name }

たとえば、TFTP アクセスが許可されるか、あるいは拒否されるかを判別するには、Content Engine がアクセス リスト 1 を検査するように設定します。

ContentEngine(config)# tftp-server access-list 1
 

ステップ 3 Content Engine がローカル ディレクトリで要求されたファイルを見つけられない場合、 tftp-server gw proto グローバル設定コマンドを使用して、TFTP ゲートウェイ機能をイネーブルにし、TFTP 要求が送信されるサーバを識別します

tftp-server gw proto { ftp | http} server { hostname | ip_address } [ name name passwd password] [ path directory ] pri priority


このコマンドの入力時には、プロトコル(FTP または HTTP)、サーバのホスト名または IP アドレス、および各サーバにアクセスするのに必要な認証情報を確認してください。 tftp-server gw proto グローバル設定コマンドを 2 回入力して、プライマリとバックアップの HTTP または FTP サーバを設定できます。 サーバをプライマリ(優先度 = 1)またはバックアップ(優先度 = 2)に指定するには、priority オプションを使用します。


表 6-12 に、 tftp-server gw proto グローバル設定コマンドに関するパラメータを示します。

 

表 6-12 tftp-server gw proto コマンドのパラメータ

パラメータ
説明

gw

Content Engine に TFTP ゲートウェイ機能を設定する。

proto

要求されたファイルがローカル ディレクトリ内で見つからないときに、TFTP の要求転送先であるオリジン サーバへのアクセスに使用されるプロトコルを設定する。

ftp

FTP プロトコルを使用して、オリジン サーバにアクセスする。

http

HTTP プロトコルを使用して、オリジン サーバにアクセスする。

server

オリジン サーバを設定する。

hostname

オリジン サーバのホスト名。

ip-address

オリジン サーバの IP アドレス。

name

(オプション)オリジン サーバへの認証に使用されるユーザ名を設定する。

name

(オプション)オリジン サーバへの認証に使用されるユーザ名。

passwd

(オプション)オリジン サーバへの認証に使用されるパスワードを設定する。

password

(オプション)オリジン サーバへの認証に使用されるパスワード。

path

(オプション)オリジン サーバ上でファイルを検索するためのパス名を設定する。

directory

(オプション)オリジン サーバ上でファイルを検索するためのパス名。

pri

オリジン サーバに優先度を設定する。

priority

オリジン サーバの優先度(1 または 2)。


 

次の例では、スタンドアロン Content Engine で TFTP サーバをイネーブルにする方法を示します。

ContentEngine(config)# inetd enable tftp
 

次の例では、192.168.1.0 のサブネットワーク上で FTP クライアントが TFTP サービスにアクセスするのを許可する標準アクセス リストを定義する方法を示しています。

ContentEngine(config)# ip access-list standard 1
ContentEngine(config-std-nacl)# ip access-list permit 192.168.1.0 0.0.0.255
ContentEngine(config-std-nacl)# exit
 

次の例では、Content Engine が TFTP 要求を満たそうとして、試行する 2 つのディレクトリの設定方法を示しています。

ContentEngine(config)# tftp-server dir /local1/mydir
ContentEngine(config)# tftp-server dir /local1/clients
 

最初に指定されたディレクトリ、 /local1/mydir がデフォルトのディレクトリとみなされます。

次のコマンドを実行すると、TFTP サービスへのアクセスを許可する IP アクセス リストが識別されます。

ContentEngine(config)# tftp-server access-list 1
 

次の例では、Content Engine がローカル ディレクトリでファイルを見つけられなかった場合、スタンドアロン Content Engine の TFTP ゲートウェイ機能をイネーブルにして、Content Engine が要求を転送する必要のある FTP サーバを識別する方法を示しています。 オリジン サーバへの認証に使用されるユーザ名とパスワードも設定します。

ContentEngine(config)# tftp-server gw proto ftp 192.168.100.1 pri 1 path /myremotedir name myuser passwd mypassword
 

ディレクトリ名 /myremotedir 、はリモート サーバからファイルを取得するのに Content Engine 上の ACNS キャッシング アプリケーションが送信する URL で使用されます。 この例での設定を使用して生成された URL は、次のようになります。

ftp://myuser:mypasswd@192.168.100.1/myremotedir/ requested-file-name

スタンドアロン Content Engine における DNS キャッシングの設定

ここでは、スタンドアロン Content Engine 上で DNS キャッシングを設定する方法を説明します。ここで説明する内容は、次のとおりです。

スタンドアロン Content Engine における DNS キャッシングについて

スタンドアロン Content Engine に対する DNS キャッシング サービス(サービス 53)の設定

スタンドアロン Content Engine における DNS キャッシングについて

DNS とは、ネットワーク ノードの名前を IP アドレスに変換するためにインターネットで使用されるシステムです。 DNS により、ネットワークは、要求に入力されたドメイン名を関連した IP アドレスに変換できます。 たとえば、エンド ユーザ(Web クライアント)がブラウザに
http://www.cisco.com と入力すると、DNS はそのドメイン名 cisco.com をそれに関連付けられた IP アドレスに変換して、エンド ユーザの要求を処理できるようにします(つまり、要求されたコンテンツを、Web クライアントに配信できるようにします)。

DNS キャッシングを使用すると、Content Engine は DNS エントリをキャッシュして、DNS サーバ解決のために何度も WAN にアクセスしないようにできます。 スタンドアロン Content Engine 上の DNS キャッシングをイネーブルにしている場合は、Content Engine は、最新の DNS クエリーの結果を以降の同じクエリーを迅速に解決する目的でキャッシングします。 このキャッシュ済みの情報は、クライアントの要求が以降にあるときに再度利用されます。 Content Engine は、DNS 情報を保存し、その情報を要求するクライアントに配信できる機能をもつことによって、DNS キャッシング サーバの働きをします。


注意 スタンドアロン Content Engine 上で WCCP 代行受信を使用して、DNS キャッシングを使用可能にすることを前提としています。

中央側で管理する ACNS ネットワークで、中央側で管理する Content Engine 上で WCCP 代行受信を使用する DNS キャッシング サービスを設定すると、どちらも同じポート(ポート 53)で DNS 要求が受信されるため、Content Router との競合が発生します。 そのため、Content Router と Content Engine は相互に排他的であるため、そのような環境で WCCP 代行受信を使用する DNS キャッシュ サポートを設定する必要はありません。 ただし、中央側で管理する ACNS ネットワークで、標準 DNS キャッシング サービス(WCCP 代行受信はサポートされていない)をイネーブルにできます。

スタンドアロン Content Engine 上で DNS キャッシングを設定するには、Content Engine の GUI または CLI を使用します。 Content Engine がドメイン ネーム解決に使用する DNS サーバの IP アドレスを指定し、Content Engine 上で DNS キャッシングをイネーブルにする必要があります。 デフォルトでは、DNS キャッシングは Content Engine 上でディセーブルになっています。

スタンドアロン Content Engine 上で DNS キャッシングをイネーブルにするには、次の作業を完了しておく必要があります。

DNS サーバのリストを指定します。ネットワークは、このリストを使用して、要求されたドメイン名を Content Engine がドメイン ネーム解決に使用する IP アドレスに変換します。

ローカル ドメインの名前を指定します。

DNS キャッシュ サイズ、つまり Content Engine の DNS キャッシュが保存する最大レコード数を指定します。

Content Engine 上で WCCP Version 2 DNS キャッシング サービス(DNS サービス [サービス 53])をイネーブルにします。

WCCP を使用して DNS 要求を透過的に代行受信することが、ACNS ソフトウェア リリース 5.1の機能に追加されています。 この機能をイネーブルにするには、Content Engine および WCCP Version 2 対応ルータ上で、WCCP Version 2 DNS キャッシング サービス(サービス 53)を設定する必要があります。 このトピックに関する詳細は、「DNS WCCP 透過代行受信の概要」を参照してください。

ドメイン ネーム解決の要件

ドメイン ネーム解決には、Content Engine に少なくとも 1 つの DNS ネーム サーバを設定しておく必要があります。 Content Engine に 1 つ以上の DNS ネーム サーバを設定するには、Content Engine GUI( System > DNS オプション)または CLI( ip name-server グローバル設定コマンド)を使用して、Content Engine 用の DNS サーバのリストを指定します。 この DNS サーバのリストの指定の詳細は、「DNS キャッシング ネーム サービス(サービス 53)用の DNS サーバの設定」を参照してください。

DNS WCCP 透過代行受信の概要

WCCP を使用した DNS 要求の透過代行受信の場合、Content Engine 上、または WCCP Version 2 をサポートするルータ上で、DNS キャッシング ネーム サービス(サービス 53)を設定する必要があります。

DNS プロセスは、次のような方法で WCCP プロセスと対話します。

バイパス リストを保持する。

DNS プロセスの存続を監視して、そのプロセスが要求を受け入れ可能であることを確認する。 応答するサーバが DNS キャッシュにない場合、DNS キャッシュは、応答可能なサーバが使用できる状態になるまでサービスを登録解除します。

WCCP DNS キャッシング サービスの設定および管理を行う(DNS サービス[サービス 53])。

デフォルトでは、ACNS DNS キャッシング サービス(サービス 53)は、オリジナル DNS サーバではなく、Content Engine 上で設定された DNS サーバを使用します。 Content Engine 上で DNS サーバのリストを設定する方法については、次の「DNS キャッシング ネーム サービス(サービス 53)用の DNS サーバの設定」を参照してください。

DNS キャッシング ネーム サービス(サービス 53)用の DNS サーバの設定

デフォルトでは、Content Engine は、ドメイン ネーム解決に設定された DNS サーバのリストにある DNS サーバを使用します。

設定された DNS サーバのリスト:ネットワークで使用され、Content Engine がドメイン ネーム解決に使用する DNS サーバのリストに追加されている DNS サーバ (この設定された DNS サーバのリストは、 ip name-server コマンドまたは System > DNS の Content Engine GUI を使用して作成されます)。

オリジナル DNS サーバ:元の要求からの DNS サーバ(以降は、オリジナル DNS サーバと呼びます)。

DNS WCCP 代行受信機能をイネーブルにした場合(つまり、サービス 53 が Content Engine および WCCP Version 2 対応ルータ上で設定されている場合)、 表 6-13 で説明されているように、 dns use-original-server グローバル設定コマンドを使用して、スタンドアロン Content Engine がドメイン ネーム解決に使用する DNS サーバを指定できます。

 

表 6-13 WCCP Version 2 代行受信を使用した DNS キャッシング サービス用の DNS サーバの指定

CLI コマンド(省略構文)
目的
ContentEngine(config)# dns use-original-server only
 

Content Engine 上で DNS キャッシング サービス(サービス 53)を設定して、設定された DNS サーバのリストにある DNS サーバ ではなく、オリジナル DNS サーバだけを使用する。

ContentEngine(config)# dns use-original-server after-configured
 

Content Engine 上で DNS キャッシュ サービスを設定して、設定された DNS サーバを最初に試行し、そのサーバが失敗した場合には、オリジナル DNS サーバを試行する。

ContentEngine(config)# dns use-original-server before-configured
 

Content Engine 上で DNS キャッシュ サービスを設定して、最初に オリジナル DNS サーバを試行してから、設定された DNS サーバを試行する。

ContentEngine(config)# no dns use-original-server

Content Engine 上で DNS キャッシュ サービスを設定して、設定された DNS サーバのリストのみを使用する。 これがデフォルトです。

Content Engine GUI または CLI を使用して、Content Engine に 1 つ、または複数の DNS サーバを設定できます。


) Content Engine GUI から行う場合は、System > DNS の順に選択し、表示された DNS ウィンドウを使用します。 このウィンドウに関する詳細は、DNS ウィンドウの HELP ボタンをクリックしてください。


スタンドアロン Content Engine に対する DNS キャッシング サービス(サービス 53)の設定

DNS キャッシング サービス(DNS サービス[サービス 53])とは、Content Engine が DNS名を解決するため、WCCP Version 2 対応ルータに対してクライアント要求を透過的に Content Engine へリダイレクトすることを許可する WCCP サービスです。 Content Engine が DNS 名を解決すると、後の DNS 要求に対して、これらの解決済みの名前を使用できるよう、解決済みの DNS 名はローカル側に保存されます。

スタンドアロン Content Engine の DNS キャッシングを設定する手順は、次のとおりです。


ステップ 1 ルータの WCCP Version 2 をオンにします。(WCCP Version 1 は DNS キャッシング サービスをサポートしていません)

Router# configure terminal
Router(config)# ip wccp version 2
 

ステップ 2 ルータの DNS キャッシング サービス(サービス 53)をオンにします。

Router(config)# ip wccp 53
 

ステップ 3 DNS キャッシング サービスを実行するインターフェイスを指定します。

Router(config)# interface type number
 

ステップ 4 DNS キャッシング サービスに送信インターフェイスを使用するよう、ルータを設定します。

Router(config-if)# ip wccp 53 redirect out
 

ステップ 5 Content Engine が WCCP Version 2 を使用するよう設定します。

ContentEngine(config)# wccp version 2
 

ステップ 6 DNS キャッシング サービスを実行するよう Content Engine を設定します。

ContentEngine(config)# wccp dns
 

ステップ 7 dns listen グローバル設定コマンドを使用して、新しいクライアント クエリを待ち受けするように DNS サーバ ポートを設定し、クエリ解決ルーチンを起動します。 ホスト名が IP アドレスに解決されると、そのアドレスはメモリ ベースの DNS キャッシュに保存されます。

次の例では、待ち受け側 IP アドレス、ポート番号、およびホスト名を最初に設定しています。 その後、Content Engine 上で DNS キャッシングを使用可能にします。

ContentEngine(config)# dns listen 10.1.1.0 port 53 hostname acme
 

dns listen 名が DNS 名と一致しない場合は、 dns pin グローバル設定コマンドを使用して IP アドレスをネーム マッピングに固定します。 dns pin グローバル設定コマンド ( both cname forward 、および reverse ) を使用すると、キャッシュ内の名前に対して IP アドレスを固定できます。 forward オプションはホスト名を IP アドレスにマップします。 reverse オプションは IP アドレスをホスト名にマップします。 both オプションは、forward と reverse の両方向のマッピングを実行します。 cname オプションは、正規名(CNAME)マッピングを挿入します。

ステップ 8 dns retry-period グローバル設定コマンドを使用して、未応答の要求が破棄される前の時間を設定します。

ステップ 9 dns retry-timeout グローバル設定コマンドを使用して、User Datagram Protocol (UDP) DNS 要求が上位の DNS サーバへ再送される間隔を設定します。

DNS プロトコルではパケットが欠落することがある UDP を使用しているため、DNS 要求の再送が要求元への負荷となります。 通常、再送は 3 秒間隔で応答を受信するまで続けられるか、応答がない場合、要求は 60 秒後にタイムアウトとなります。 DNS サーバがタイムアウトになると、そこで新しいアップストリーム サーバがクエリに選択されます。 クエリするサーバがアップストリームになくなると、最初に応答した DNS サーバは要求元のクライアントに DNS 失敗の応答を戻します。

ステップ 10 dns serial-lookup グローバル設定コマンドを使用して、最初に連絡した DNS サーバが応答しない場合は、設定済みのネーム サーバにこのスタンドアロン Content Engine クエリーを繰り返し送ります。

ステップ 11 dns enable グローバル設定コマンドを使用して、このスタンドアロン Content Engine 上で DNS サーバを起動します。

DNS サーバがイネーブルになると、システムに対するネーム サーバとして 127.0.0.1 のエントリが作成され、メモリ ベースの DNS キャッシュを始動します。

ContentEngine(config)# dns enable
 

ステップ 12 dns max-cache-memory グローバル設定コマンドを使用して、このスタンドアロン Content Engine の DNS キャッシュに保存できるリソース レコードの最大数を指定します (デフォルト設定値 10,000 レコードを使用する場合、この手順はオプションになります)。

システム リソース全体に過大な負荷がかからないようにするには、Content Engine のメモリの最大制限値を厳密に指定することが重要です。 次の例では、DNS キャッシュ サイズは 20,000 レコードに設定されています。

ContentEngine(config)# dns-cache size 20000
 

) Content Engine GUI を使用して最大の DNS キャッシュ サイズを設定するには、
Content Engine GUI から System > DNS の順に選択します。 表示された DNS ウィンドウを使用して、DNS キャッシュのサイズを指定し、Update をクリックします。



 

スタンドアロン Content Engine における DNS キャッシングのディセーブル化

Content Engine 上で DNS キャッシングをディセーブルにするには、 no dns-cache size グローバル設定コマンドを入力します。

ContentEngine(config)# no dns-cache size

永続接続の設定

Content Engine は、パフォーマンス向上のためにデフォルトで、サーバへの永続接続を使用します。 ACNS 5.0.7 ソフトウェアでは、 rule action no-persistent-connection グローバル設定コマンドが追加されました。 このコマンドにより、特定のドメイン、発信元および宛先 IP アドレス、あるいはポートをイネーブルまたはディセーブルにすることが可能になります。 このコマンドは、サーバが永続接続をサポートしていない場合に役立ちます。

永続接続のイネーブル化

スタンドアロン Content Engine 上で永続接続をイネーブルまたはディセーブルにするために、Content Engine GUI または CLI を使用できます。

ローカルに配置された Content Engine で、Content Engine GUI を使用して永続接続をイネーブルにするには、 Caching > Persist の順位選択します。 Connect も選択して、表示された Persistent Connections ウィンドウを使用します。 永続接続をイネーブルにするために Persistent Connections ウィンドウを使用する方法についての詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI を使用して、スタンドアロン Content Engine 上で永続接続をイネーブルにするには、 http persistent-connections グローバル設定コマンドを使用します。

ContentEngine(config)# http persistent-connections [all|client-only|server-only|timeout seconds]
 

Content Engine がタイムアウトになるまでの間、永続応答を待つ秒数を設定するには、 timeout オプションを使用します。

表 6-14 では、HTTP 永続接続のパラメータを説明します。

 

表 6-14 HTTP 持続接続 CLI パラメータ

パラメータ
説明

persistent-connections

永続接続の設定オプションを設定します。

all

(オプション)クライアントおよびサーバ接続を永続させます。

client-only

(オプション)クライアント接続のみを永続させます。

server-only

(オプション)サーバ接続のみを永続させます。

timeout

(オプション)永続接続のタイムアウト値を設定します。

seconds

永続接続がタイムアウトになる秒数を設定します(1 ~ 86400)。

永続接続のディセーブル化

すべての永続接続、クライアントのみの永続接続、またはサーバのみの永続接続をディセーブルにするには、 http persistent-connections [all | client-only | server-only | timeout seconds] グローバル設定コマンドの no 形式を使用します。

ContentEngine(config)# no http persistent-connections [all|client-only|server-only|timeout seconds]
 

特定のドメイン、IP アドレス、またはポートをディセーブルにするには、 rule action no-persistent-connection グローバル設定コマンドを次のように使用します。

ContentEngine(config)# rule action no-persistent-connection pattern-list list_num [protocol {http|https|ftp}]
 

rule action no-persistent-connection グローバル設定コマンドには、次のオプションがあります。

all :すべての接続に永続接続を使用しない。

client-only :クライアント接続だけには、永続接続を使用しない。

server-only :サーバ接続だけには、永続接続を使用しない。

次のサポートされているパターンのうち、1 つまたは複数を使用してパターン リストを作成することで、永続接続をディセーブルにする基準を指定できます。

src-ip

dst-ip

dst-port

url-regex

domain

header-field user-agent

header-field referer

header-field request-line

表 6-15 では、 rule action no-persistent-connection コマンド用の構文について説明します。

 

表 6-15 rule action no-persistent-connection コマンドのパラメータ

パラメータ
説明

action

規則によって取るべきアクションが示されます。

no-persistent-connection

永続接続の設定オプションを設定します。

pattern-list

パターン リストを設定します。

list_num

パターン リスト番号(1 ~ 512)

protocol

この規則と照合されるプロトコル。

http

この規則を HTTP プロトコルと照合します。

https

この規則を HTTPS プロトコルと照合します。

ftp

この規則を MMS プロトコルと照合します。

次の例では、パターンリストの 10 をもとに、ドメイン mywebsite.com に対しての永続接続をディセーブルにしています。

ContentEngine(config)# rule action no-persistent-connection server-only pattern-list 10
WARNING: rule action no-persistent-connection will affect end-to-end NTLM authentication to these servers
ContentEngine(config)#
 
ContentEngine# show rule all
Rules Template Configuration
----------------------------
Rule Processing Enabled
 
Actions :
 
rule action no-persistent-connection server-only pattern-list 100 protocol all
 
Pattern-Lists :
 
rule pattern-list 100 domain mywebsite.com
ContentEngine#
 

スタンドアロン Content Engine に規則を設定する、Rules Template 機能の使用についての詳細は、「スタンドアロンContent Engine の Rules Template の設定」を参照してください。

Content Engine クラスタのヒーリング モードの設定

ヒーリング モードにより、新たに追加された Content Engine は、キャッシュ ミス時に、Content Engine クラスタ内の他のすべての Content Engine を照会して、キャッシュ オブジェクトを取得できるようになります。オブジェクトがクラスタ内に見つからない場合、Content Engine は、発信プロキシ サーバ、またはオリジン サーバを通じて要求を処理します。 ヒーリング モードの Content Engine 「ヒーリング クライアント」と呼ばれます。Content Engine クラスタ内で、ヒーリング クライアントの要求に応答する Content Engine は、「ヒーリング サーバ」と呼ばれます。

1 台の Content Engine が、WCCP Version 2 を実行している既存の Content Engine クラスタに追加されると、この Content Engine は、Content Engine クラスタ内の別のキャッシュが以前に処理したコンテンツに対する要求を受け取る場合があります。 このイベントは、「ニアミス」と呼ばれます。これは、その要求が以前の Content Engine に送信されていたら、キャッシュ ヒットであったからです。 ニアミスは、Content Engine クラスタの全体的なキャッシュ ヒット率を低下させます。


) ヒーリング モードは、要求が透過的に Content Engine に転送されるときのみ、ヒーリング クライアント上で起動されます。 クラスタが要求を直接 Content Engine (非透過フォワード プロキシ サーバとして機能)に送信されるときは、ヒーリング モードは起動されません。


Content Engine ファームにある 1 台の Content Engine が、そのクラスタにある他の複数の Content Engine からキャッシュ オブジェクトを照会および取得できるようにするには、その 1 台の Content Engine 上でヒーリング モードをイネーブルにする必要があります。そのために、Content Engine GUI または CLI を使用して、スタンドアロン Content Engine 上で ヒーリング モードをイネーブルにします。

クラスタリング パラメータ(WCCP サービス クラスタに関連するパラメータ) Content Engine GUI で設定するには、 WCCP > Clustering と順に選択します。 Clustering を使用して、この Content Engine に対してこれらのパラメータを指定します。 これらのパラメータを指定するために Clustering ウィンドウを使用する方法についての詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI を使用して、スタンドアロン Content Engine 上でヒーリング モードをイネーブルにするには、 http cluster グローバル設定コマンドを使用します。

http cluster {heal-port number | http-port number | max-delay seconds | misses number }

表 6-16 では、http cluster コマンド パラメータを説明します。

 

表 6-16 ヒーリング モード CLI パラメータ

パラメータ
説明

cluster

Content Engine 上でキャッシュ クラスタ オプションを設定する。

heal-port

ヒーリング要求に対するヒーリング サーバの待ち受けポート。

number

ヒーリング サーバの待ち受けポート番号(1 ~ 65535)。 デフォルトは、14333 です。

http-port

ヒーリング Content Engine からの要求がクラスタ内の他の Content Engine に送信されるときに使用される HTTP ポート番号。 ヒーリング ポートのデフォルトのポート番号は、ポート 80 です。有効なポート番号は 1 から 65535 です。

number

HTTP 要求転送ポート番号(1 ~ 65535)。 デフォルトは、80 です。

max-delay

Content Engine クラスタからの応答の最長待機時間。

seconds

最大遅延の秒数(0 ~ 10)。

misses

Content Engine のヒーリング モードの持続期間

number

ヒーリング モードがディセーブルになるまでの合計ミス数(0 ~ 999)。

http cluster http-port グローバル設定コマンドを使用して、ヒーリング Content Engine (ヒーリング クライアント)からの要求が、ヒーリング サーバ(クラスタ内の他の Content Engine)に送信されるときに使用されるポート番号を指定します。 デフォルトのポート番号は、80 です。デフォルトの 80 以外のポートを設定することを選択する場合は、 http proxy incoming グローバル設定コマンドを使用して、設定されるポートが、クラスタ内のヒーリング サーバ上で指定されるポートと一致することを、確認する必要があります。 一致しない場合は、ヒーリング クライアントはヒーリング サーバからオブジェクトを取り出すことができません。

http cluster heal-port グローバル設定コマンドを使用して、ヒーリング クライアントがヒーリング クエリを送信するのに使用するポート番号、およびヒーリング サーバがヒーリング応答を送信するのに使用するポート番号を指定します。 デフォルトのポート番号は 14333 です。このデフォルトのポート番号を設定する場合、クラスタ内のすべての Content Engine が同じポート番号を使用していることを確認してください。

http cluster misses グローバル設定コマンドを使用して、前回のヒーリング モードのヒット応答以後、ヒーリング プロセスがディセーブルになるまでの間に、ヒーリング Content Engine がクラスタから受け取ることができる最大ミス数を指定します。 デフォルト値は 0 ミスです。

WCCP バケットの分配後、Content Engine はキャッシュを他の Content Engine から、キャッシュ ミスの度に移そうとします。Content Engine が目的のオブジェクトそのものを取り出すまでに近接のContent Engine からの応答を待つ最大秒数を設定できます。 デフォルト値は 0 秒です。 http cluster max-delay グローバル設定コマンドを使用して、ヒーリング要求をミスと見なす前に、ヒーリング Content Engine がクラスタからのヒーリング応答を待つ、 最大時間を秒数で指定します。

ヒーリング クライアントを使用可能にするには、少なくとも max-delay オプションと misses オプションを設定する必要があります。 http-port のデフォルト ポート番号は 80 です。デフォルト ポートを使用する場合は、 http-port を設定する必要はありません。 heal-port のデフォルト ポート番号は 14333 です。

次の例では、ヒーリング モード機能をイネーブルにするために、HTTP 要求をヒーリング サーバに転送するための HTTP ポートを設定し、ヒーリング要求をミスと見なす前に、クラスタからの応答を待つ最大遅延時間を秒数で設定します。さらに、ヒーリング クライアントでヒーリング モードがディセーブルになる前に、ヒーリング Content Engine (ヒーリング クライアント)がクラスタから受け取ることができる最大ミス数を設定します。

ContentEngine(config)# http cluster http-port 8080
ContentEngine(config)# http cluster max-delay 5
ContentEngine(config)# http cluster misses 5
 

ヒーリング クライアントをディセーブルにするには、少なくとも misses max-delay オプションのどちらかを次のように 0 に設定する必要があります。または、 http cluster misses および http cluster max-delay グローバル設定コマンドの no 形式を使用することもできます。

ContentEngine(config)# no http cluster misses
ContentEngine(config)# no http cluster max-delay

Content Engine クラスタの Internet Cache Protocol の設定

Internet Cache Protocol (ICP) は、Content Engine 間での通信、および従来のプロキシ プロトコルとの相互運用性のサポートに使用されるライトウェイト メッセージ形式です。 ICP は、Content Engine クラスタ(ファーム)内の近隣 Content Engine に存在する URL についての情報を交換するために使用されます。 Content Engine は、ICP の照会と応答をやり取りして情報を収集し、その情報を使用して、オブジェクトの取得先として最適な場所を選択します。

ICP は従来、Content Engine のクラスタ全体のサイズを単一の装置以上に拡張するために使用されていましたが、最近では ICP は、Content Engine クラスタ ソリューションのスケーリング手段として適していないことが判明しています。 現在は、トラフィックを透過ネットワーク Content Engine クラスタに向けて送信する手段が使われているので、Content Engine を配置するために ICP を使用する必要性は、ほとんどなくなりました。

ICPv2 プロトコルは、次の 2 つの標準文書として文書化されています。

RFC 2186: Internet Cache Protocol (ICP), Version 2

RFC 2187: Application of Internet Cache Protocol (ICP), Version 2


) ICP サーバ(近隣 Content Engine からの要求に対してサービスを提供する)、および ICP クライアント(要求を近隣 Content Engine に送信する)の両方として動作するための機能がサポートされています。


次の例では、Content Engine CLI を使用して、ICP parent の親と兄弟を特定のドメイン セットに制限する方法を示しています。

ContentEngine(config)# icp client add-remote-server 10.1.1.1 parent icp-port 3130 http-port 3128 domain_x.com domain_y.com domain_z.com
ContentEngine(config)# icp client add-remote-server 10.1.1.1 sibling icp-port 3130 http-port 3128 domain_a.com domain_b.com domain_c.com
ContentEngine(config)# icp client enable
ContentEngine(config)#
 

次で説明しているように、キャッシュ クラスタの一部であるスタンドアロン Content Engine の ICP を、Content Engine CLI または GUI を使用して設定することができます。

ICP クライアントとしてのスタンドアロン Content Engine の 設定

ICP サーバとしてのスタンドアロン Content Engine の 設定

ICP クライアントとしてのスタンドアロン Content Engine の 設定

ICP クライアント機能を使用して必要なオブジェクトをインターネットから取得する前に、ICP 照会を生成するように Content Engine クラスタを設定できます。 ICP を使用して、親および兄弟の関係にある Content Engine を階層的に構成できます。 Content Engine の階層内で、ICP の親は、基本的に ICP の兄弟より 1 階層上にあります。

スタンドアロン Content Engine は、親または兄弟のどちらにも設定できます。

親の Content Engine は、キャッシュ ミス時にデータを取得できます。

兄弟の Content Engine はデータを取得できず、代わりに要求を親の Content Engine に転送します。

Content Engine GUI または CLI を使用して、スタンドアロン Content Engine を ICP クライアントとして設定できます。

Content Engine GUI から設定する場合は、 Caching > ICP Proxy の順に選択し、ICP Client ウィンドウを使用します。 このウィンドウに関する詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から設定する場合は、 icp client グローバル設定コマンドを使用して、スタンドアロン Content Engine を ICP クライアントとして設定します。 ICP 機能をイネーブルにせずに行われた設定は、除去されるまでその構成内に保管されます。

表 6-17 では、 icp client グローバル設定コマンドのパラメータについて説明しています。

 

表 6-17 icp client コマンドの要約

コマンド
目的

icp client enable

ICP クライアントを Content Engine で使用可能にする。

icp client add-remote-server

リモート ICP クライアント サーバを追加する。

icp client exclude

ICP クライアント ローカル ドメインを除外する。

icp client max-fail

許容される再試行の最大数を設定する。 有効値は 0 ~ 100 です。デフォルトは 20 です。

icp client max-wait

Content Engine が要求されたデータをインターネットから直接取得する前に待つ時間の長さを設定する。

icp client modify-remote-server

ICP クライアント リモート サーバ パラメータを変更する。

次の例では、Content Engine CLI を使用して、ICP の親と兄弟を特定のドメイン セットに制限する方法を示しています。

ContentEngine(config)# icp client add-remote-server 172.16.0.0 parent icp-port 3130 http-port 3128 domain_x.com domain_y.com domain_z.com
 
ContentEngine(config)# icp client add-remote-server 172.16.0.0 sibling icp-port 3130 http-port 3128 domain_a.com domain_b.com domain_c.com
 
ContentEngine(config)# icp client enable
Icp Client started

ICP サーバとしてのスタンドアロン Content Engine の 設定

ICP サーバとして機能するようにスタンドアロン Content Engine を設定することもできます。 このように設定すると、Content Engine は、階層内の ICP 親クライアントと兄弟クライアントに対して ICP メッセージのマルチキャストを行い、Content Engine の階層を探査できます。

Content Engine GUI または CLI を使用して、スタンドアロン Content Engine を ICP サーバとして設定できます。

Content Engine GUI から設定する場合は、 Caching > ICP Server の順に選択し、表示された ICP Server ウィンドウを使用します。 このウィンドウに関する詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から設定する場合は、 icp server グローバル設定コマンドを使用して、スタンドアロン Content Engine を ICP サーバとして設定します。 ICP 機能をイネーブルにせずに行われた設定は、除去されるまでその構成内に保管されます。 表 6-18 では、 icp server グローバル設定コマンドのパラメータについて説明しています。

 

表 6-18 icp server コマンドの要約

コマンド
目的

icp server enable

ICP サーバを Content Engine で使用可能にする。

icp server http-port

ICP によって生成された要求を受信する Content Engine 上の HTTP プロキシ ポートを設定する。 範囲は 0 ~ 65535 です。デフォルトのポート番号は 3128 です。

icp server port

ICP 要求を受信する Content Engine 上の ICP サーバ ポートを設定する。 範囲は 0 ~ 65535 です。デフォルトのポート番号は 3130 です。