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

目次

スタンドアロン 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 キャッシングの概要

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

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

透過 FTP ネイティブ キャッシングの設定

非透過 FTP ネイティブ キャッシングの設定

スタンドアロン 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 キャッシングの無効化

TCP キープアライブを送信するためのスタンドアロン Content Engine の設定

スタンドアロン Content Engine での永続接続の設定

永続接続の有効化

永続接続の無効化

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

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

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

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

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

この章では、スタンドアロン Content Engine において従来のキャッシング サービス(HTTP、FTP 「FTP-over-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 キャッシングの設定

TCP キープアライブを送信するためのスタンドアロン Content Engine の設定

スタンドアロン Content Engine での永続接続の設定

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

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


) この章に記述されている CLI コマンドの構文と使用方法については、『Cisco ACNS Software Command Reference、Release 5.3』の資料を参照してください。Content Distribution Manager に登録された Content Engine のキャッシングの設定については、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3 』を参照してください。


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

ここでは、スタンドアロン Content Engine 上で、Content Engine CLI を使用して従来のキャッシング サービス(HTTP、HTTPS、FTP、および DNS キャッシング)を設定する方法の概要を説明します。図7-1 では、スタンドアロン Content Engine において従来のキャッシング サービスを設定する方法を詳細に示しています。

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

ローカル管理配置におけるメディア キャッシング サービス(WMT キャッシング、RTSP キャッシング、および ストリーミング サービス)の設定方法については、次の章を参照してください。

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

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

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

 

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

 

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

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

1. スタンドアロン Content Engine にクライアント要求の宛先を指示するために以下のルーティング方式の 1 つまたは複数を設定する。

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

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

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

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

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

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

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

「Yes」を選択した場合、プロキシ 自動コンフィギュレーション(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 を設定する。

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

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

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

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

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

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

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

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

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

「TCP キープアライブを送信するためのスタンドアロン 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 の RealMedia サービスの設定」

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

スタンドアロン 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(Internet Content Adaptation Protocol)サーバが存在するかどうかを判別する。

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

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

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

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

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

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

 

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

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

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

「スタンドアロン 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 についての
システム ロギング設定を確認または変更する。

「特定 URL のパフォーマンスのモニタリング」

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

 

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

「スタンドアロン Content Engine のモニタリングとトランザクション」

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

「スタンドアロン Content Engine のモニタリングとトランザクション」

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

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

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

HTTP 1.1 仕様では、Chunked Transfer Coding を使用してオブジェクトを転送できます。ACNS ソフトウェア リリース 5.1 以前では、chunked transfer encoded(CTE)オブジェクトのプロキシングはサポートされていましたが、これらのオブジェクトのキャッシングはサポートされていませんでした。

ACNS ソフトウェア リリース 5.2 以降では、CTE HTTP オブジェクトのキャッシングがサポートされています。同じ CTE オブジェクトに対するそれ以降の要求が、標準 HTTP キャッシングの新鮮度の基準を満たす場合、そのオブジェクトは Content Engine のキャッシュからフェッチされ、HTTP 1.1 準拠のクライアントに送信されます。HTTP 1.0 クライアントは、CTE をサポートしていません。そのため、オブジェクトが CTE フォーマットで格納されたとき、HTTP クライアントが HTTP 1.1 準拠でない場合、Content Engine はソース HTTP サーバからオブジェクトを取得する必要があります。

スタンドアロン Content Engine 上で CTE HTTP オブジェクトのキャッシングを有効にするには、 http cache-chunk-encoded enable グローバル設定コマンドを指定します。この機能を有効にした後で、 show statistics http request EXEC コマンドを使用して、この機能が正常に動作していることを確認できます。コマンド出力をチェックして、Content Engine が HTTP 1.1 準拠のクライアントにキャッシュ CTE HTTP オブジェクトを配信したあとで Chunked HTTP Responses フィールドの表示値が増加していることを確認してください。


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


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

 

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

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

 

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

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

透過リダイレクト モード

 

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

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

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

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

ACNS ソフトウェア リリース 5.1 以前のバージョンでは、最高 8 種類のアクティブ WCCP サービスが WCCP Version 2 ルータ および Content Engine でサポートされていました。ACNS ソフトウェア リリース 5.2 以降では、最大 25 個のアクティブな WCCP Version 2 サービスがサポートされるようになりました。ACNS ソフトウェア リリース 5.2 では、17 個の WCCP サービスのみが定義されました。ACNS ソフトウェア リリース 5.3 では、18 個の WCCP サービスが定義されます。サポートされる 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 ポート 80 以外のポートに着信する HTTP 要求も受け入れるように Content Engine を設定します。

ContentEngine(config)# http proxy incoming ports

ここで、 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
(end-of-request)
 

または

200 OK
(response headers)
(data)
(end-of-request)
 

応答が期限切れになる日時を示す、期限切れの応答もキャッシングに影響します。この応答ヘッダーは、要求が古くなる日時を示し、条件付き 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 キャッシュ オブジェクトの新鮮度係数を指定します

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

ステップ 2 HTTP キャッシュ オブジェクトが Content Engine キャッシュに保存される最短時間を設定します。次の例では、この最短時間が 10 分に設定されます。

ContentEngine(config)# http min-ttl 10
 

ステップ 3 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 よりもこの日付が優先されます。 表7-3 では、有効な範囲の値をリストしています。

 

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

時間単位
範囲

1 ~ 1825

1 ~ 43800

1 ~ 2628000

1 ~ 157680000

ステップ 4 Content Engine がキャッシュ内の HTTP オブジェクトのコンテンツ新鮮度を再確認する要求を処理するときに使用する方式を指定します。次の例では、各 HTTP 要求ごとにすべての HTTP オブジェクトを再確認するよう、Content Engine を設定します。

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

ステップ 5 HTTP オブジェクトのサイズの上限をキロバイト(KB)で設定します。次の例では、HTTP オブジェクトの最大サイズを 500 KB に設定します。

ContentEngine(config)# http object max-size 500
 

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


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

ContentEngine(config)# http cache-cookies
 

ステップ 7 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 から設定する場合は、 表7-4 で説明されているように、 http authentication グローバル設定コマンドを使用します。

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

 

表7-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.1 以降でのみ利用できます。デフォルトでは、このオプションは無効です。これは、実際には 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 (プロキシ認証が必要)を選択できます。

次の例では、エンド ユーザに認証のための証明情報(ユーザ ID とパスワード)を要求する際に、Content Engine がヘッダー 407 を使用するように設定します。

ContentEngine(config)# http authentication header 407
 

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


再認証の間隔の指定

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

ACNS ソフトウェア リリース 5.2.1 では、共有ワークステーション環境でのセキュリティを強化するために HTTP 認証キャッシュ エントリ用の絶対存在可能時間を指定できます。絶対 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 認証キャッシュ設定の表示

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

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 }

表7-5 では、これらのコマンド パラメータを示します。

 

表7-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 キャッシュ サービスを設定しておく必要があります(透過 HTTP フォワード プロキシ キャッシング)。

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 ]}

表7-6 では、コマンド パラメータを説明します。

 

表7-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
 

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


ヒント Content Engine GUI から WCCP > Enable WCCP の順に選択して、Version 1 または Version 2 オプション ボタンをクリックすることによっても、スタンドアロン Content Engine 上で WCCP Version 1 または 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 の Web Cache ウィンドウ( WCCP > Web Cache )で、指定されたルータ リストを Web キャッシュ サービスに対して指定する必要があります。

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

ContentEngine(config)# wccp web-cache 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 ルータの標準 Web キャッシュ サービスをオンにします。

Router(config)# ip wccp web-cache
 

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

Router(config)# interface type number
 

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

Router(config)# interface ethernet 0/1
 

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

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


 

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

スタンドアロン Content Engine が、ポート 80 以外にリダイレクトされた HTTP トラフィックを受け取ることができるようにするために、カスタム 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 キャッシュ サービス(サービス 98)を無効にするには、このコマンドの 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 ]}

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

 

表7-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)。範囲は、1 ~ 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 ポート)でリダイレクトできます。Content Engine 上でカスタム Web キャッシュ サービスを設定することにより、ユーザ定義の WCCP サービス(サービス 90 ~ 97)を設定する必要はなく、Content Engine は、複数ポートで HTTP 要求を代行受信できます。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 上で WCCP Version 2 を有効にできます。

ステップ 2 カスタム Web キャッシュ サービス(サービス 98)をサポートするルータを指定する、ルータ リストを作成します。この 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)だけをサポートし、リバース プロキシ サービス(サービス 99)はサポートしません。WCCP サービスのリストについては、 表B-3 を参照してください。


ヒント Content Engine GUI から WCCP > Enable WCCP の順に選択して、Version2 オプション ボタンをクリックすることによっても、スタンドアロン 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 を有効にし設定する場合は、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
 

リバース プロキシ キャッシュ サービスに送信インターフェイスを使用するように、ルータを設定します。ルータは、イーサネット インターフェイス 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)。HTTPS のデフォルト ポート番号は、HTTP のデフォルト ポート番号 80 ではなく、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.1 以降では、要求された HTTPS サーバが Content Engine 上で設定されている場合、Content Engine SSL は、WCCP モードと手動プロキシ モードの HTTPS 要求を終了し、残りの HTTPS トラフィックをトンネルさせます。

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

HTTPS 要求のトンネリングは、ACNS ソフトウェアが HTTPS クライアント要求に対してサポートするもう 1 つのモードです。このモードでは、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 要求を Content Engine が処理できるようにします。


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


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

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

 

表7-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(Content Engine A)を設定する方法を説明します。


ステップ 1 プロキシ モード要求の受信に使用するポート番号を設定します

ContentEngineA(config)# https proxy incoming ports
 

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

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

ContentEngineA(config)# https proxy incoming 8080 8081 9090
 

) 複数のポートを入力する場合は、ポート番号をそれぞれ空白で区切ります。


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

ステップ 2 Content Engine 用のプライマリ発信 HTTPS プロキシ サーバとして、1 台のプロキシ サーバを指定します。

ContentEngineA(config)# https proxy outgoing host host port primary
 

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
ContentEngineA(config)# https proxy outgoing host 10.1.1.2 220
 

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

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

ContentEngine A# show https proxy
 


 

スタンドアロン 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-cache サービス(サービス 70)をサポートするようにルータを設定します。

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

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

b. https-cache サービス(サービス 70)を実行するように Router A を設定します。

RouterA(config)# ip wccp 70
 

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

Router(config)# ip wccp 70 redirect out
 

ステップ 2 https-cache サービスをサポートするように Content Engine を設定します。

a. https-cache サービスをサポートするために使用されるルータのリストを設定します。この場合、ルータ リスト番号 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 オリジン サーバとして機能します)。

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

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 サーバのホスト名(abc1)を入力し、これらの設定を 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 (オプション) Content Engine で高度な HTTPS サーバ設定を行うことで、SSL 通信のあらゆる側面に関してより詳細に制御できます。

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

b. SSL Version 2 のみを使用するように、Content Engine を設定します。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 command option または 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>
 

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

表7-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 サーバとして使用する際の証明書と秘密鍵を作成、削除、およびインポートします。 表7-10 では、 https cert cert-name および https key key_name EXEC コマンドについて説明しています。

 

表7-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 コマンドを使用して、特定の名前を付けて証明書を作成、外部ソースから証明書をインポート、または、Content Engine から既存の証明書を削除します。


) 秘密鍵および証明書は、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 上で、証明書グループを作成、削除または形成します。 表7-11 では、 https certgroup cert-name EXEC コマンドのパラメータを説明しています。

 

表7-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
ContentEngineA(config)# https proxy outgoing host 10.1.1.2 220
 

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

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

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

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


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

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

宛先ポートへのアクセス防止は、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.bankabc.com のポート xxx にアクセスする要求が、WCCP 透過リダイレクトまたは直接プロキシ ルーティングのいずれかによって、この Content Engine にリダイレクトされる場合、xxx ポートへの接続は拒否されます。

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

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

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

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

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


) Content Engine GUI または CLI を使用して、スタンドアロン Content Engine 上で FTP キャッシングを設定できます。


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

スタンドアロン Content Engine では、次の 2 種類の使用モードで FTP キャッシングの設定ができます。

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

ネイティブ FTP モード。スタンドアロン Content Engine(透過プロキシ サーバ)が、ネイティブ FTP プロトコルのクライアントから送信された FTP 要求のコンテンツをキャッシュします。ACNS ソフトウェア リリース 5.3.1 以降では、ネイティブ FTP キャッシングは透過および非透過プロキシ モードでサポートされます(ネイティブ FTP キャッシングは、ACNS ソフトウェア リリース 5.1 および 5.2 で、透過プロキシ モードでのみサポートされます)。詳細については、「スタンドアロン Content Engine における FTP ネイティブ キャッシングの設定」を参照してください。

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

ContentEngine# ftp server.cisco.com
 

表7-12 では、サポートされる FTP キャッシングの使用モードとタイプを要約しています。

 

表7-12 サポートされる FTP キャッシングの使用モードとタイプ

使用
モード
説明
透過リダイレクション
直接プロキシ ルーティング
FTP-
over-
HTTP

Content Engine は HTTP プロトコルを使用しているクライアントによって直接送信された、特定の FTP URL のコンテンツをキャッシュします。

サポート対象外。

クライアント ブラウザが非透過 FTP-over-HTTP要求をContent Engine(非透過フォワード プロキシ サーバ)に直接送信します。

このタイプのキャッシングは非透過 FTP-over-HTTP キャッシングと呼ばれ、ACNS ソフトウェア リリース 5.0 以降でサポートされます。詳細については、「スタンドアロン Content Engine における非透過 FTP-over-HTTP キャッシングの設定」を参照してください。

ネイティブ
FTP

Content Engine は、ネイティブ FTP プロトコルの FTP クライアントから送信された FTP 要求のコンテンツをキャッシュします。

WCCP Version 2 対応ルータが FTP クライアントからの FTP ネイティブ要求を透過的に代行受信し、これらの要求を Content Engine(透過プロキシ サーバ) にリダイレクトします。

このタイプのキャッシングは透過 FTP ネイティブ キャッシングと呼ばれ、ACNS ソフトウェア リリース 5.1 以降でサポートされます。詳細については、「透過 FTP ネイティブ キャッシングの設定」を参照してください。

FTP クライアントが非透過 FTP ネイティブ要求を Content Engine(非透過フォワード プロキシ サーバ)に直接送信します。

このタイプのキャッシングは非透過 FTP ネイティブ キャッシングと呼ばれ、ACNS ソフトウェア リリース 5.3.1 以降でサポートされます。詳細については、「非透過 FTP ネイティブ キャッシングの設定」を参照してください。


) FTP 要求の透過リダイレクトは、WCCP Version 2 を使用した場合のみサポートされ、レイヤ 4 スィッチを使用した透過リダイレクトはサポートされません。


ACNS ソフトウェア リリース 5.3.1 では、FTP ネイティブ キャッシングと FTP-over-HTTP キャッシングを明確に区別するために、 ftp キーワードが ftp-over-http および ftp-native キーワードに置き換えられています。

ContentEngine(config)# ftp-over-http ?
age-multiplier FTP-over-HTTP caching heuristic modifiers
max-ttl Maximum time to live for objects in the cache
min-ttl Minimum time to live for objects in the cache (in minutes,
default is 30)
object Configuration of FTP object
proxy Configuration for incoming proxy-mode requests
reval-each-request Configuration of revalidation for every request
ContentEngine(config)#ftp-over-http
ContentEngine(config)# ftp-native ?
object Configuration of FTP object
proxy Configuration for proxy-mode requests
ContentEngine(config)#ftp-native
 

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

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

スタンドアロン Content Engine は、非透過 FTP-over-HTTP キャッシングを使用することで、クライアント ブラウザからの 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 プロキシ サーバ(ACNS ソフトウェア リリース 5.2.1 以降で設定されている場合)から、またはオリジン FTP サーバから直接、オブジェクトを取得します。

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

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

Content Engine CLI を使用して、スタンドアロン Content Engine において非透過 FTP-over-HTTP キャッシングを設定する手順は、次のとおりです。


ステップ 1 プロキシ モード FTP-over-HTTP 要求の受信に使用するポート番号を設定します

ContentEngine(config)# ftp-over-http proxy incoming ports
 

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

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

ContentEngine(config)# ftp-over-http proxy incoming 8080 8081 9090
 

無効なポート番号を入力した場合、その旨を通知するメッセージが表示されます。たとえば、FTP-over-HTTP 要求の着信ポートとしてポート 9002 を指定しようとすると、このポートは RealProxy アプリケーションに予約されていることが通知されます。次を参照してください。

ContentEngine(config)# ftp-over-http proxy incoming 9002
Port 9002 is reserved for application the Real_Proxy.
 

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

ステップ 2 Content Engine 上でトランザクション ロギングを設定します。

次の例では、Apache トランザクション ログ形式を使用するように Content Engine を設定してから、Content Engine においてトランザクション ロギングを有効にする方法を説明しています。

ContentEngine(config)# transaction-logs format apache
ContentEngine(config)# transaction-log enable
 

このトピックに関する詳細は、「トランザクション ロギングの有効化」を参照してください。

ステップ 3 FTP-over-HTTP キャッシングにおける FTP キャッシュ オブジェクトの新鮮度を設定します。これらのパラメータは、ディレクトリ リストに対しても、キャッシュ内の特定のオブジェクトに対しても設定できます。


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

a. FTP-over-HTTP キャッシングで Content Engine のキャッシュに保管する FTP オブジェクトの最大サイズを設定します。次の例では、FTP-over-HTTP キャッシングに対して FTP オブジェクト サイズの最大サイズを 2 メガバイトに設定しています。

ContentEngine(config)# ftp-over-http object max-size 2000
 

b. FTP-over-HTTP キャッシングについては、 ftp-over-http age-multiplier ftp-over-http max-ttl ftp-over-http reval-each-request 、および ftp-over-http min-ttl グローバル設定コマンドも使用できます。

次の例では、FTP-over-HTTP キャッシングに使用するディレクトリ リスト オブジェクトとファイル オブジェクトに対して、キャッシュの最大存続可能時間(Time To Live)を 3 日に設定しています。

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

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

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

c. Content Engine に各 FTP-over-HTTP 要求に対するすべてのオブジェクトを再検証するように強制します。

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

) ACNS 5.3.1 ソフトウェア リリースでは、ftp キーワードが ftp-over-http および ftp-native キーワードに置き換えられました。


ステップ 4 ftp-over-http proxy outgoing host グローバル設定コマンドを使用して、Content Engine に使用する 1 台または複数台の発信 FTP プロキシ サーバを設定します。発信 FTP プロキシ サーバのホスト名または IP アドレスを入力します。プライマリ発信 FTP プロキシ サーバは、ICP または WCCP を使用せずにすべてのミスした FTP トラフィックをこの Content Engine が宛先を指示することを望む親キャッシュ(アップストリーム FTP プロキシ サーバ)です。詳細については、 「プライマリ発信 FTP プロキシ サーバの指定」 を参照してください。

ステップ 5 ftp-over-http proxy anonymous-pswd global configuration コマンド を使用して、匿名の FTP-over-HTTP 操作の間に使用するパスワードを指定します。

ステップ 6 FTP-over-HTTP モードが使用できるように、この Content Engine 上でアクティブ モードを有効にします。

ContentEngine(config)# ftp-over-http proxy active-mode enable
 

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

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

ステップ 7 スタンドアロン Content Engine における現在の FTP-over-HTTP 設定を表示します。

ContentEngine(config)# exit
ContentEngine# show ftp-over-http
 

ステップ 8 このスタンドアロン Content Engine で処理された FTP-over_HTTP 要求の 統計情報を表示します。

ContentEngine# show statistics ftp-over-http
 

たとえば、コマンド出力には、Content Engine で受信された FTP-over-HTTP 要求の数、FTP-over-HTTP ヒットとミスの数、および Content Engine がオリジン FTP サーバに、または指定された発信プロキシ サーバに転送した FTP-over-HTTP 要求の数が示されます。また、コマンド出力には
FTP-over-HTTP エラーの数も示されます。

ステップ 9 (オプション)。Content Engine における FTP-over-HTTP 統計情報をクリアします。

ContentEngine# clear statistics ftp-over-http
 

) ACNS ソフトウェア リリース 5.3.1 では、show ftp proxy EXEC コマンドが show ftp-over-http および show ftp-native EXEC コマンドに置き換えられました。

ACNS ソフトウェア リリース 5.3.1 では、show statistics ftp EXEC コマンドがshow statistics ftp-over-http および show statistics ftp-native EXEC コマンドに置き換えられました。ACNS ソフトウェア リリース 5.3.1 では、clear statistics ftp EXEC コマンドが clear statistics ftp-over-http および clear statistics ftp-native EXEC コマンドに置き換えられました。



 

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

ここでは、スタンドアロン Content Engine での FTP ネイティブ キャッシングの設定方法について説明します。

「透過 FTP ネイティブ キャッシングの設定」

「非透過 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 プロキシ サーバの「オフライン」操作については未サポート

ACNS ソフトウェア リリース 5.3.1 では、上記の制限事項のすべて(非透過プロキシの未サポートを除く)が引き続き適用されます。ACNS ソフトウェア リリース 5.3.1 では、FTP ネイティブ モードにおいて非透過プロキシのサポートが追加されました。この機能の詳細については、「非透過 FTP ネイティブ キャッシングの設定」を参照してください。

透過 FTP ネイティブ キャッシングの設定

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

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

ContentEngine(config)# ftp-native proxy active-mode ?
enable Adhere to client's mode for native FTP
 

ftp-native proxy active-mode enable コマンドが指定されない場合、Content Engine は、パッシブ モードを使用して、オリジン FTP サーバへのデータ接続を行います。

Content Engine が ネイティブ FTP においてクライアントのモード(アクティブまたはパッシブ)に従った場合は、次のような状況になります。

Content Engine(FTP ネイティブ プロキシ サーバ)は、FTP クライアントがアクティブ モードのデータ転送要求を発行した場合、オリジン FTP サーバに対し、または FTP サーバからのアクティブ モードによるデータ転送を実行する。

Content Engine は、FTP クライアントがパッシブ モードのデータ転送要求を発行した場合、FTP サーバに対し、または FTP サーバからのパッシブ モードによるデータ転送を実行する。

ネイティブ FTP 要求に対して Content Engine で作成される 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
 

「匿名」ユーザ ログインおよび ACSII ファイル転送モードの場合の 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#
 

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


ステップ 1 Content Engine において FTP ネイティブ アクティブ モードを有効にします。

ContentEngine(config)# ftp-native proxy active-mode enable
 

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

ステップ 2 Content Engine 上でトランザクション ロギングを設定します。

次の例では、Apache トランザクション ログ形式を使用するように Content Engine を設定してから、Content Engine においてトランザクション ロギングを有効にする方法を説明します。

ContentEngine(config)# transaction-logs format apache
ContentEngine(config)# transaction-logs enable
 

詳細については、「トランザクション ロギングの有効化」を参照してください。

ステップ 3 FTP ネイティブ キャッシングでの FTP オブジェクトの最大サイズを指定します。このパラメータは、ディレクトリ リストに対しても、キャッシュ内の特定のオブジェクトに対しても設定できます。次の例では、FTP ネイティブ キャッシングでの FTP オブジェクト サイズの最大サイズを 2 メガバイト に設定します。

ContentEngine(config)# ftp-native object max-size 2000
 

ステップ 4 Content Engine において、透過 FTP ネイティブ キャッシングを設定します。

FTP 要求の透過リダイレクトは、WCCP Version 2 を使用した場合のみサポートされ、レイヤ 4 スィッチを使用した透過リダイレクトはサポートされません。

a. FTP ネイティブ要求をこの Content Engine にリダイレクトする際に使用するルータのリストを設定します。次の例では、1 台の WCCP Version 2 ルータ(IP アドレス 10.77.157.41 を持つルータ)を組み込むようルータ リスト 1 を設定する方法を示します。

ContentEngine(config)# wccp router-list 1 10.77.157.41
 

b. リダイレクトされた FTP ネイティブ要求を Content Engine が受け入れる元のルータ リストを指定します。次の例では、ルータ リスト 1 に含まれているルータにリダイレクトされた FTP ネイティブ要求を受け入れるように Content Engine を設定する方法を示します。

ContentEngine(config)# wccp ftp-native router-list-num 1
 

ステップ 5 WCCP ルータにおいて、FTP ネイティブ要求を透過的に代行受信し、代行受信した FTP ネイティブ要求を Content Engine(FTP プロキシ サーバの役目をする)にリダイレクトするように、ルータを設定します。

a. ルータでサービス 60 を有効にします。

Router(config)# ip wccp 60
 

サービス 60 は、WCCP Version 2 対応ルータから Content Engine 上の単一ポートに FTP ネイティブ要求を透過的にリダイレクトできる、事前定義済みの WCCP Version 2 キャッシング サービスです。Content Engine は、要求された FTP コンテンツを取得し、ローカルにコピーを保存し、要求されたコンテンツを要求元に配信します。

b. サービス 60 を実行するインターフェイスを指定します。

Router(config)# interface type number
 

c. サービス 60 に対して発信インターフェイスを使用できるようにルータを設定します。

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

ステップ 6 FTP プロキシが Content Engine 上で有効になっていることを確認します。

ContentEngine# show wccp modules
Modules registered with WCCP on this Content Engine
 
Module Socket Expire(sec) Name Supported Services
------ ------ ----------- --------------- ------------------
2 13 4 WMT Proxy WMT
 
3 14 4 MMSU WMT Proxy MMSU
 
6 15 4 WMT-RTSPU RTSPU
 
1 16 4 RTSP Proxy RTSP
 
0 17 3 HTTP Proxy Web Cache
Reverse Proxy
Custom Web Cache
HTTPS 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
 
5 22 3 FTP Proxy FTP
ContentEngine#
 

ステップ 7 透過 FTP ネイティブ キャッシング(次のコマンド出力で「FTP」と表示される)が Content Engine 上で設定されていることを確認します。

ContentEngine# show wccp services
Services configured on this Content Engine
Web Cache
Reverse Proxy
RTSP
WMT
MMSU
DNS
FTP
RTSPU
HTTPS Cache
ContentEngine#
 

ステップ 8 (オプション)。 wccp ftp-native mask グローバル設定コマンドを使用して、着信透過 FTP ネイティブ要求に対する Content Engine の割り当てで使用されるマスクを指定します。たとえば、 dst-ip-mask コマンド オプションを使用して、リダイレクトされたパケットの宛先 IP アドレスに一致するようにマスクを設定します。宛先 IP アドレス マスクは、16 進数(たとえば、0xFC000000)として定義されます。その範囲は、0x00000000 から FC000000 です。

ContentEngine(config)# wccp ftp-native 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-native mask
 

WCCP サービスでのマスクの指定の詳細については、「マスク負荷分散方式を使用するレイヤ 2 転送の設定」を参照してください。

ステップ 9 l2-redirect オプションを入力して、パケット転送方式として(GRE とは反対の)レイヤ 2 リダイレクションを指定します。 mask-assign オプションを入力して、FTP ネイティブ キャッシング サービスの負荷分散方式として(デフォルトのハッシュ アサイメント方式とは反対の)マスク アサイメントを指定します。

ContentEngine(config)# wccp ftp-native router-list-num 1 l2-redirect mask-assign
WCCP configuration for FTP succeeded.
Please remember to config WCCP service 60 on the corresponding router.
ContentEngine(config)#
 

ステップ 10 透過 FTP ネイティブ要求でのマスクに関する設定を表示します。

ContentEngine# show wccp masks ftp-native
 

ステップ 11 現在の FTP ネイティブ プロキシ設定を表示します。

ContentEngine# show ftp-native
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)
Incoming Proxy-Mode:
Configured Proxy mode Native FTP connections on ports: 1 2 3 4 5 6 7 8
 

ステップ 12 このスタンドアロン Content Engine で処理された FTP ネイティブ要求の統計を表示します。

ContentEngine# show statistics ftp-native
 

コマンド出力には、Content Engine で受信された FTP ネイティブ要求の数、GET 要求に対する FTP ネイティブ ヒットとミスの数、およびこの Content Engine で受信された FTP ネイティブ PUT 要求の数が示されます。

ステップ 13 Content Engine における FTP ネイティブ統計をクリアします。

ContentEngine# clear statistics ftp-native
 

) ACNS ソフトウェア リリース 5.3.1 では、show ftp proxy EXEC コマンドが show ftp-over-http および show ftp-native EXEC コマンドに置き換えられました。

ACNS ソフトウェア リリース 5.3.1 では、show statistics ftp EXEC コマンドがshow statistics ftp-over-http および show statistics ftp-native EXEC コマンドに置き換えられました。ACNS ソフトウェア リリース 5.3.1 では、clear statistics ftp EXEC コマンドが clear statistics ftp-over-http および clear statistics ftp-native EXEC コマンドに置き換えられました。



 

非透過 FTP ネイティブ キャッシングの設定

ACNS ソフトウェア リリース 5.3.1 では、非透過 FTP ネイティブ要求のプロキシングとキャッシングのサポートが追加されました。この新機能を使用すると、Content Engine においてプロキシ モードで FTP クライアントからの FTP ネイティブ要求を処理できます。

Content Engine で FTP クライアントからの FTP ネイティブ要求(たとえば、Reflection X、WS-FTP クライアント、UNIX または DOS コマンドライン FTP プログラム) FTP ネイティブ要求)を受信すると、その要求は Content Engine で処理されます。要求されたコンテンツがすでにローカル キャッシュに格納されている場合、Content Engine はそのコンテンツを FTP クライアントに配信します。格納されていない場合、Content Engine は、オリジン FTP サーバに対する FTP 要求を実行して要求されたコンテンツを取得し、続いてコンテンツをローカル キャッシュに格納します。このタイプのキャッシングは、 非透過 FTP ネイティブ キャッシング と呼ばれます。ネイティブ FTP 要求は、スタンドアロン Content Engine の HTTP トランザクション ログにロギングされます。

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


) Content Engine が NAT の背後にある場合は、Content Engine にはコンジット IP アドレスがわからないため、FTP クライアントと FTP ネイティブ プロキシの間のパッシブ モード転送は行えません。


スタンドアロン Content Engine において非透過 FTP ネイティブ キャッシングを設定する手順は、次のとおりです。


ステップ 1 プロキシ モード FTP 要求(FTP ネイティブ要求)の受信に使用するポート番号を設定します

ContentEngine(config)# ftp-native proxy incoming ports
 

ports は、スタンドアロン Content Engine が FTP クライアントから着信要求(ネイティブ FTP 要求)を受け入れる際のポート数です。有効なポート番号は 1 ~ 65535 です。最高 8 つの着信ポートを指定できます。

次の例では、FTP クライアントからの FTP ネイティブ要求を 8 つのポート(ポート 8501、8502、8503、8504、8505、8506、8507、および 8508)で受け入れるように、Content Engine を設定します。最高 8 つまでの着信プロキシ ポートを同一コマンドラインで設定できます。次に例を示します。

ContentEngine(config)# ftp-native proxy incoming 8501 8502 8503 8504 8505 8506 8507 8508
 

ftp-native proxy incoming コマンドを再入力した場合、Content Engine は、再設定され、直前に入力した ftp-native proxy incoming コマンドで指定されているポートのみを使用します。たとえば、次の ftp-native proxy incoming コマンドを入力した場合、Content Engine は着信プロキシ ポートとして次の 8 つの指定ポートを使用します。

ContentEngine(config)# ftp-native proxy incoming 8501 8502 8503 8504 8505 8506 8507 8508
 

ただし、次の ftp-native proxy incoming コマンドを再入力した場合、Content Engine は、着信プロキシ ポートとしてポート 8501 のみを使用し、その他の 7 つの設定済みポートを着信プロキシ ポートとして使用しないように再設定されます。

ContentEngine(config)# ftp-native proxy incoming 8501
 

無効なポート番号を入力した場合、その旨を通知するメッセージが表示されます。たとえば、プロキシ モード FTP ネイティブ要求の着信ポートとしてポート 554 を指定しようとすると、このポートは Content Engine 上で実行される RTSP ゲートウェイに予約されていることが通知されます。次に例を示します。

ContentEngine(config)# ftp-native proxy incoming 554
Port 554 is reserved for application the RTSP_Gateway.
 

ステップ 2 FTP ネイティブ キャッシングで Content Engine のキャッシュに保管する FTP オブジェクトの最大サイズを設定します。このパラメータは、ディレクトリ リストに対しても、キャッシュ内の特定のオブジェクトに対しても設定できます。

ContentEngine(config)# ftp-native object max-size size
 

次の例では、FTP ネイティブ キャッシングでの FTP オブジェクト サイズの最大サイズを 2 メガバイト に設定しています。

ContentEngine(config)# ftp-native object max-size 2000
 

ステップ 3 Content Engine 上でトランザクション ロギングを設定し有効にします。

次の例では、Content Engine は、Apache トランザクション ログ形式を使用してから、Content Engine においてトランザクション ロギングを有効にするように設定しています。

ContentEngine(config)# transaction-logs format apache
ContentEngine(config)# transaction-logs enable
 

詳細については、「トランザクション ロギングの有効化」を参照してください。

ステップ 4 Content Engine において FTP ネイティブ アクティブ モードを有効にします。

ContentEngine(config)# ftp-native proxy active-mode enable
 

ステップ 5 FTP ネイティブ要求を直接 Content Engine に送信するようにFTP クライアント(クライアント側)を設定します。詳細については、次の「非透過 FTP ネイティブ キャッシングのクライアント側の設定」を参照してください。

ステップ 6 View the current FTP native proxy configuration.

ContentEngine# show ftp-native
 

ステップ 7 このスタンドアロン Content Engine で処理された FTP ネイティブ要求の統計情報を表示します。

ContentEngine# show statistics ftp-native
 

ステップ 8 Content Engine における FTP ネイティブ統計情報をクリアします。

ContentEngine# clear statistics ftp-native
 

) ACNS ソフトウェア リリース 5.3.1 では、show ftp proxy EXEC コマンドが show ftp-native および show ftp-over-http EXEC コマンドに置き換えられました。

ACNS ソフトウェア リリース 5.3.1 では、show statistics ftp EXEC コマンドがshow statistics ftp-over-http および show statistics ftp-native EXEC コマンドに置き換えられました。ACNS ソフトウェア リリース 5.3.1 では、clear statistics ftp EXEC コマンドが clear statistics ftp-over-http および clear statistics ftp-native EXEC コマンドに置き換えられました。



 

非透過 FTP ネイティブ キャッシングのクライアント側の設定

非透過 FTP プロキシ サーバの役目をする Content Engine は、Reflection X クライアント、WS-FTP クライアント、Unix または DOS コマンドライン FTP プログラムなどの FTP クライアントからの FTP ネイティブ要求を受け取ることができます。ここでは、FTP ネイティブ要求を直接 Content Engine に(すなわち、非透過 FTP プロキシ サーバの役目をする)送信するように、これらのさまざまなタイプの FTP クライアントを設定する方法について例を示します。

次の例では、Windows ベースの Reflection X クライアント ソフトウェアを使用して Content Engine にクライアント側のプロキシ FTP 要求を設定する方法を示しています。


ステップ 1 Windows の Start メニューから、 Programs > Reflection > FTP Client の順に選択します。FTP サイトに接続ウィンドウが表示されます(図7-2 を参照)。

図7-2 FTP サイトに接続する際の Reflection X クライアント ソフトウェアの使用

 

ステップ 2 Connect to FTP Site ウィンドウにリストされた FTP サイトの 1 つを選択します。

ステップ 3 Properties ボタンをクリックします。選択した FTP サイトの Properties ウィンドウが表示されます(図7-3 を参照)。

図7-3 Properties ウィンドウ

 

ステップ 4 General タブから、 Security ボタンをクリックします。Security Properties ダイアログボックスが表示されます(図7-4 を参照)。

図7-4 Securities ダイアログボックス

 

ステップ 5 Securities ダイアログボックスで、次の手順を実行します。

a. Proxy server チェックボックス(Proxy タブ内)を選択します。

b. Server type ドロップダウン メニューから Passthrough エントリを選択します。

ステップ 6 Configure ボタンをクリックします。Passthrough Server ダイアログボックスが表示されます(図7-5 を参照)。

図7-5 Passtrough Server ダイアログボックス

 

ステップ 7 Passthrough Server ダイアログボックスで、次の手順を実行します。

a. Style ドロップダウン メニューから username@servername エントリを選択します。

b. Server name エディットボックスに Content Engine のホスト名、または IP アドレスを入力します。

c. Passthrough authentication チェックボックスにチェックマークが付いていないことを確認してください。

d. OK をクリックして、Passthrough Server ダイアログボックスをクローズし、Securities ダイアログボックスに戻ります。

ステップ 8 Securities ダイアログボックスで、 OK をクリックして戻り、Securities ダイアログボックスをクローズします。

ステップ 9 Properties ウィンドウ(図7-3)で、Connection タブをクリックします。

ステップ 10 Connection タブ(図7-6)で、TCP ポートを Content Engine の FTP ネイティブ着信プロキシ ポートに設定します。

図7-6 Properties ウィンドウの Connection タブ

 

TCP ポート フィールドには、「非透過 FTP ネイティブ キャッシングの設定」ステップ 1 ftp-native proxy incoming port グローバル設定コマンドを使用して指定したポート番号(たとえば、ポート 7780)と同じポート番号を入力する必要があります。

ステップ 11 Connection タブで、 Apply をクリックし、続いて OK をクリックして、Connect to FTP Site ウィンドウに戻ります(図7-2 を参照)。

ステップ 12 Reflection X クライアントが FTP サイトに接続できることを確認します。

a. Connect to FTP Site ウィンドウで、 Connect ボタンをクリックします。Reflection FTP ダイアログボックスが表示され、パスワードの入力を求められます(図7-7 を参照)。

図7-7 [Reflection FTP パスワード] ダイアログボックス

 

b. パスワードを入力し、 OK をクリックします。


 

WS-FTP は、Windows ベース デスクトップからリモート マシンにファイルを転送するのに使用する Windows ベースの FTP クライアントです。このソフトウェア(Ipswitch, Inc. のライセンス ソフトウェア)を使用すると、Windows ベース コンピュータから単一のファイル転送を実行できます。次の例では、Windows ベースの WS-FTP クライアント ソフトウェアを使用して Content Engine にクライアント側のプロキシ FTP 要求を設定する方法を示しています。


ステップ 1 Windows の Start メニューから、 Programs > Ipswitch WS_FTP_Home > WS_FTP Home の順に選択します。WS_FTP Home ウィンドウが表示されます(図7-8 を参照)。

図7-8 FTP サイト(FTP サーバ)に接続する際の WS-FTP クライアント ソフトウェアの使用

 

ステップ 2 File メニューから、 Connect > Connection Wizard の順に選択します。

ステップ 3 サイト名(接続先の FTP サーバの名前)を入力します。

ステップ 4 FTP サーバの IP アドレスを入力します。

ステップ 5 FTP サーバのユーザ名とパスワードを入力します。

ステップ 6 接続タイプとして FTP を選択します。

ステップ 7 Finish ボタンをクリックします。

ステップ 8 Tool メニューから、 Option > Firewall の順に選択します。

ステップ 9 New ボタンをクリックします。

ステップ 10 Content Engine(このクライアントの非透過プロキシ サーバの役目をする)の名前と IP アドレスを入力します。

ステップ 11 タイプとして Script (fwsc)を選択します。このオプションでは、ファイアウォール スクリプトの使用を指定します。

ステップ 12 プロキシ ポート番号を入力します。

「非透過 FTP ネイティブ キャッシングの設定」ステップ 1 ftp-native proxy incoming port グローバル設定コマンドを使用して指定したポート番号(たとえば、ポート 7780)と同じポート番号を入力する必要があります。

ステップ 13 Okay をクリックします。

ステップ 14 Firescript エディタをクリックして、エディタを開きます。

ステップ 15 ファイアウォール スクリプトを作成します。

ステップ 16 Firescript エディタで、作成したファイアウォール スクリプトのコンテンツを貼り付けます。

次の例は、Firescript エディタに貼り付けられるファイアウォール スクリプトのサンプルのコンテンツを示します。

[fwsc]
author=cisco
version=1
verdate=2004.11.23
required=HostUserId,HostPassword,HostAddress
connectto=firewall
 
[comment]
This script is similar to the "site hostname" script except that
the following line at the beginning of the script section is
removed:
send (" ") {}
 
[script]
 
send ("SITE %HostAddress") {}
 
send ("USER %HostUserId")
{
case (300..399) :
continue;
 
case any :
return (false) ;
}
 
send ("PASS %HostPassword")
{
case (200..299) and contains(lastreply, "ACCOUNT") and not
isempty(HostAccount) :
continue;
 
case (300..399) :
continue;
 
case (200..299) :
jump success;
 
case any :
return (false) ;
}
 
send ("ACCT %HostAccount")
{
case (200..299) :
jump success;
 
case any:
return (false);
}
 
label success;
gossl;
return (true);
 
====================================
 

ステップ 17 このファイアウォール スクリプトをデフォルトのロケーションにファイルとして保存します。

ステップ 18 Tool メニューから、 Options > Firewall の順に選択します。

ステップ 19 FTP 要求のプロキシングに使用する Content Engine を選択します。これは、この手順のステップ 10 で指定した Content Engine です。

ステップ 20 Edit をクリックします。

ステップ 21 script <fswc>(firescript name)としてタイプ フィールドを選択します。


ヒント ファイアウォール スクリプトは、実際は、サイトまたはユーザ名の形式を内部にもつ Content Engine を使用してプロキシングします。

ステップ 22 WS-FTP Home ウィンドウから、 Tool > Site Manager の順に選択します。Site Manager ウィンドウが表示されます(図7-9 を参照)。

図7-9 Site Manager ウィンドウ

 

ステップ 23 Site Manager ウィンドウで、すでに作成されているサイト(たとえば、「wrq.com」)をクリックし、続いて Edit をクリックします。Site Options ウィンドウが表示されます(図7-10 を参照)。

図7-10 Site Options ウィンドウ

 

ステップ 24 Site Options ウィンドウで、 Advanced をクリックします。

ステップ 25 表示された Firewall ドロップダウン リストで、すでに設定済みの Content Engine を選択します。


 

次の例では、UNIX コマンドライン FTP プログラムを使用して、非透過 FTP プロキシ サーバの役目をする Content Engine に、クライアント側のプロキシ FTP 要求を設定する方法を示しています。

shell# ftp -d 2.9.192.11 8501
Connected to 2.9.192.11.
220-Welcome to FTP-proxy.
220-Login to origin server using the 'USER username@server-hostname' command,
or 220 Login to origin server using the 'SITE server-hostname' and
'USER username' commands.
Name (2.9.192.11:admin): smartuser@abchost.company.com
331 Password required for smartuser.
Password:
230 User smartuser logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
dir
---> PORT 2,9,192,10,81,212
200 PORT command successful.
---> LIST
150 Opening ASCII mode data connection for /bin/ls.
total 8
-rw-r--r-- 1 nobody abc 5496 Jan 31 2002 boot
-rw-r--r-- 1 nobody abc 143 Oct 24 2001 cop
226 Transfer complete.
ftp> quit
---> QUIT
shell#

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

ACNS ソフトウェア リリース 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 プロトコルを使用してバック エンドで処理します。

コンテンツ ファイルには、ルータ ソフトウェア イメージ、ルータ構成、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 サーバに送信され、TFTP サーバは、ファイルを 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 は「File not found(ファイルが見つかりません)」の 404 メッセージを出して応答します。

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

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

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

TFTP サーバおよびゲートウェイの有効化

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


ステップ 1 Content Engine で TFTP サービスを有効にします。

ContentEngine(config)# inetd enable 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 Content Engine で TFTP サービスを有効にします。

ContentEngine(config)# inetd enable tftp
 

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

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

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


 


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


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

TFTP サーバは、ファイルに対して完全ディレクトリ パスを識別できないような要求を受け取ると、デフォルトのローカル ディレクトリ内でファイルを検索します。どのローカル ディレクトリも指定してない場合、デフォルト ディレクトリは /tftpboot です。このディレクトリはデフォルト ディレクトリとして自動的に割り当てられますが、その場合でも mkdir EXEC コマンドを使用して、このディレクトリ(または 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 サーバおよびゲートウェイにアクセスを許可する 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 ゲートウェイ機能を有効にし、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 オプションを使用します。


表7-13 では、 tftp-server gw proto グローバル設定コマンドに関するパラメータを示しています。

 

表7-13 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
 

次の 2 つのローカル ディレクトリを設定します。これらのディレクトリは、Content Engine が TFTP 要求を満たそうとして試行するディレクトリです。

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

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

Specify the IP access list that should be used to permit access to the TFTP service:
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 キャッシングを使用可能にすることを前提としています。

中央側で管理する ANCS ネットワークにおいて、中央側で管理する 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 対応ルータ上で設定されている場合)、 表7-14 で説明されているように、 dns use-original-server グローバル設定コマンドを使用して、スタンドアロン Content Engine がドメインの名前解決に使用する DNS サーバを指定できます。

 

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

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

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

dns use-original-server after-configured
 

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

dns use-original-server before-configured
 

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

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 名を使用できるようにするために、解決済みの 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 サービス 53 を実行するインターフェイスを指定します。

Router(config)# interface type number
 

ステップ 4 サービス 53 に対して発信インターフェイスを使用できるようにルータを設定します。

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

ステップ 5 WCCP Version 2 を実行するように Content Engine を設定します。

ContentEngine(config)# wccp version 2
 

ステップ 6 サービス 53 を実行するように Content Engine を設定します。

ContentEngine(config)# wccp dns
 

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

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

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

DNS 待ち受け名が DNS 名と一致しない場合は、 dns pin グローバル設定コマンドを使用して IP アドレスをネーム マッピングに固定します。The 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 このスタンドアロン Content Engine 上で DNS サーバを始動します。

ContentEngine(config)# dns enable
 

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


ステップ 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

TCP キープアライブを送信するためのスタンドアロン Content Engine の設定

デフォルトでは、Content Engine はキープアライブを自動的に送信しません。HTTP 接続で TCP キープアライブを送信するようにスタンドアロン Content Engine を設定するには、 http tcp-keepalive enable グローバル設定コマンドを使用する必要があります。 http tcp-keepalive enable コマンドを入力すると、Content Engine は HTTP 接続で 75 秒ごとにキープ アライブを送信します。応答が受信された場合、Content Engine は引き続き 75 秒ごとにキープアライブを送信します。応答が受信されない(デバイスが応答しない)場合、Content Engine は 90 秒間待ち、ミスをログに記録します。4 つのミスのあと、Content Engine は HTTP 接続がダウンしているとみなして、接続をクローズします。

tcp keepalive-probe-cnt グローバル設定コマンドを使用して接続をクローズする前に Content Engine がデバイスへの接続を試行する回数を指定します。試行回数の範囲は 1 ~ 10 回で、デフォルトは 4 回です。

tcp keepavlive-probe-interval グローバル設定コマンドを使用して、Content Engine が TCP キープアライブを送信する周期を指定します。間隔の範囲は 1 ~ 120秒です。デフォルトは 75 秒です。

tcp keepalive-timeout グローバル設定コマンドを使用して、ミスをログに記録する前に Content Engine が応答を待つ(デバイスが応答しない)ように、Content Engine を設定します。タイムアウト時間の範囲は 1 ~ 120秒です。デフォルトは 90 秒です。

スタンドアロン Content Engine での永続接続の設定

パフォーマンス向上のために Content Engines は、デフォルトで、サーバへの永続接続を使用します。ACNS ソフトウェア リリース 5.0.7 以降では、 rule action no-persistent-connection グローバル設定コマンドを使用すると、特定のドメイン、ソース、宛先 IP アドレス、またはポートの永続接続を無効または有効にできます。このコマンドは、サーバが永続接続をサポートしていない場合に役立ちます。

永続接続の有効化

永続接続でアイドル状態タイムアウト期間(デフォルトでは 600 秒)を指定されると、Content Engine の接続は永続接続状態になります。HTTP 永続接続をイネーブルすると、キープアライブは不要となり、Content Engine は、アイドル状態タイムアウト期間が経過するまで、接続をオープンしたままにします。


) Content Engine はキープアライブを自動的に送信しません。HTTP 接続で TCP キープアライブを送信するように Content Engine を設定するには、http tcp-keepalive enable グローバル設定コマンドを入力する必要があります。


永続接続で応答またはデータが送信されると、アイドル状態期間が再開します。HTTP 永続接続は、クライアントかサーバ、またはその両方に設定できます。

スタンドアロン 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]
 

表7-15 では、HTTP 永続接続のパラメータを説明しています。

 

表7-15 HTTP 永続接続 CLI パラメータ

パラメータ
説明

persistent-connections

永続接続の設定オプションを設定します。

all

(オプション)クライアントおよびサーバ接続を永続させます。

client-only

(オプション)クライアント接続のみを永続させます。

server-only

(オプション)サーバ接続のみを永続させます。

timeout

(オプション)永続接続のタイムアウト値を設定します(アイドル状態タイムアウト期間)。

seconds

持続接続がタイムアウトになる秒数を設定します(1 ~ 86400)。

永続接続は、最初の要求が行われるまで(たとえば、GET 要求)、または永続接続でデータのフローが開始するまで、スタートしません。永続接続で最初の要求または送信データがない場合、読み取り/書き込み(rw)タイムアウト設定が有効になります。データの送信または受信が終わる前に接続がアイドル状態になる場合も、rw タイムアウト設定が使用されます。この場合、接続は、rw タイムアウト設定で指定した期間にわたってタイムアウトになります。データの読み取り/書き込みについても、rw タイムアウト設定は、 tcp server-rw-timeout および tcp client-rw-timeout グローバル設定コマンドを使用して、サーバまたはクライアントのいずれかに設定できます。デフォルトでは、サーバとクライアントの両方について、rw タイムアウトは、120 秒に設定されています。このトピックに関する詳細は、「スタンドアロン Content Engine 上での TCP パラメータの表示または変更」を参照してください。

永続接続の無効化

スタンドアロン Content Engine において、すべての永続接続、クライアントのみの永続接続、またはサーバのみの永続接続を無効にするには、 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

表7-16 では、 rule action no-persistent-connection コマンド用の構文について説明しています。

 

表7-16 rule action no-persistent-connection コマンドのパラメータ

パラメータ

説明

action

規則によって取るべきアクションが示されます。

no-persistent-connection

永続接続の設定オプションを設定します。

pattern-list

パターン リストを設定します。

list_num

パターン リスト番号(1 ~ 512)

protocol

この規則が照合されるプロトコル。

http

この規則を HTTP プロトコルと照合します。

https

この規則を HTTPS プロトコルと照合します。

ftp

この規則を FTP プロトコルと照合します。

次の例では、パターンリストの 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(非透過フォワード プロキシ サーバとして機能)に送信されるときは、ヒーリング モードは起動されません。


Content Engine ファームにある 1 台の Content Engine が、そのクラスタにある他の複数の Content Engines からキャッシュ オブジェクトを照会および取得できるようにするには、その 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 }

表7-17 では、http cluster コマンド パラメータを説明しています。

 

表7-17 ヒーリング モード CLI パラメータ

パラメータ
説明

cluster

Content Engine 上でキャッシュ クラスタ オプションを設定します。

heal-port

ヒーリング要求に対するヒーリング サーバの待ち受けポート。

number

ヒーリング サーバのリスニング ポート番号(1 ~ 65535)。デフォルトは、14333 です。

http-port

ヒーリング Content Engine からの要求がクラスタ内の他の Content Engine に送信されるときに使用される HTTP ポート番号。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 CLI または GUI を使用して、スタンドアロン Content Engine を ICP クライアントとして設定できます。

Content Engine GUI から設定する場合は、 Caching > ICP Client の順に選択し、ICP Client ウィンドウを使用します。このウィンドウに関する詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI から設定する場合は icp client グローバル設定コマンドを使用して、スタンドアロン Content Engine を ICP クライアントとして設定します。ICP 機能を有効にせずに行われた設定は、除去されるまでその構成内に保管されます。

表7-18 では、 icp client グローバル設定コマンドのパラメータについて説明しています。

 

表7-18 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 機能を有効にせずに行われた設定は、除去されるまでその構成内に保管されます。

表7-19 では、 icp server グローバル設定コマンドの関するパラメータについて説明しています。

 

表7-19 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 です。