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

目次

スタンドアロン 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 ネイティブ要求の IP ACL サポートの概要

非透過 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 キャッシングのディセーブル化

スタンドアロン Content Engine での TCP キープアライブの送信設定

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

「スタンドアロン Content Engine での TCP キープアライブの送信設定」

「スタンドアロン Content Engine での固定接続の設定」

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

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


) この章で使用する CLI(コマンドライン インターフェイス)コマンドの構文および使用方法については、『Cisco ACNS Software Command Reference』Release 5.4を参照してください。Content Distribution Manager に登録する Content Engine でのキャッシングの設定方法については、『Cisco ACNS Software Configuration Guide for Centrally Managed Deployments』Release 5.4を参照してください。


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

ここでは、Content Engine CLI を使用して、スタンドアロン Content Engine に従来型キャッシング サービス(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 スイッチング)

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

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

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

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

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

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

3. スタンドアロン Content Engine に、非透過(プロキシ)モードの従来型キャッシング サービスを設定します。

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

FTP-over-HTTP キャッシング

HTTPS プロキシ キャッシング

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

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

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

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

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

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

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

HTTPS 透過キャッシング

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

DNS キャッシング

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

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

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

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

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

「スタンドアロン Content Engine での DNS キャッシングの設定」

5. この時点で、次のいずれかの作業を実行できます。

TFTP サーバおよびゲートウェイの設定

Content Engine での固定接続の設定

キャッシュ クラスタのヒーリング モードまたは ICP の設定

Content Engine のストリーミング サービスの設定

Content Engine のコンテンツ サービスの設定

Content Engine の拡張設定

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

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

6. Content Engine に TFTP サーバおよびゲートウェイを設定します。

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

7. Content Engine に固定接続を設定します。

「スタンドアロン Content Engine での TCP キープアライブの送信設定」

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. 外部 Internet Content Adaptation Protocol(ICAP)サーバが存在するかどうかを判別します。

存在しない場合、作業 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 の拡張透過キャッシング機能の設定」

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

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

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

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

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

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

20. スタンドアロン Content Engine に、TACACS+ を使用したシステム アカウンティングを設定します。

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

21. スタンドアロン Content Engine に、IP Access Control List(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 がキャッシュされている CTE HTTP オブジェクトを HTTP 1.1 準拠クライアントに戻した場合、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 フォワード プロキシ キャッシングの設定」

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

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

ACNS ソフトウェア リリース 5.1 以前では、最大 8 つのアクティブ WCCP サービスが、WCCP Version 2 ルータ および Content Engine でサポートされていました。ACNS ソフトウェア リリース 5.2.1 以降では、最大 25 のアクティブ WCCP Verison 2 サービスがサポートされます。ACNS ソフトウェア リリース 5.2.1 では、17 の WCCP サービスが定義されていました。ACNS ソフトウェア リリース 5.3.1 では、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 Content Engine が、ポート 80 以外のポートで着信 HTTP 要求を受け入れるように設定します。

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 は、最大 Time To Live(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 ヘッダーが期限切れ時間を指定していない場合、 http age-multiplier および http max-ttl グローバル コンフィギュレーション コマンドを使用して、Content Engine でキャッシュ オブジェクトをエージング アウトできます。

また、ディスクに書き込まれる前に、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 オブジェクトに最短 TTL を設定するには、 http min-ttl および ftp min-ttl グローバル コンフィギュレーション コマンドを使用します。

HTTP set-cookies ヘッダーがあり、有効期限情報がなく、キャッシュできる可能性のあるバイナリ オブジェクトを Content Engine でキャッシュするには、 http cache-cookies グローバル コンフィギュレーション コマンドを使用します。

スタンドアロン Content Engine に HTTP キャッシュのフレッシュネスを設定する場合、Content Engine CLI または GUI を使用できます。

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 オブジェクトのコンテンツの新しさを再評価する場合の要求の処理方法を指定します。次に、Content Engine がすべての HTTP 要求のすべての HTTP オブジェクトを再評価するように設定する例を示します。

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 HTTP set-cookies ヘッダーがあり、有効期限情報がなく、キャッシュできる可能性のあるバイナリ オブジェクトと関連クッキーを、Content Engine がキャッシュするように設定します。

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


) 認証キャッシュのサイズが不足し、すべての認証ユーザに対して同時に対応できない場合には、Content Engine は、期限切れになっていない経過時間の古いエントリを削除します。


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

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

Content Engine CLI から設定する場合は、 http authentication グローバル コンフィギュレーション コマンドを使用します。 表7-4 を参照してください。

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

 

表7-4 http authentication 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

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

ttl

認証キャッシュ内のエントリの絶対 TTL を設定します。このオプションを使用できるのは、ACNS ソフトウェア リリース 5.2.1 以降だけです。デフォルトでは、このオプションは無効なので、TTL タイムアウトは発生しません。つまり、TTL 値に相対する作成時間に基づく認証キャッシュ エントリのタイムアウトはチェックされないことを意味しています。

minutes

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

header

HTTP 要求のスタイルがプロキシ サーバが存在しないことを示している場合、認証(ユーザ ID およびパスワード)に使用する HTTP ヘッダーを指定します。ヘッダーは 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 構文に基づいてキャッシュ ロードを認証します。

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

次に、Content Engine がエンド ユーザに認証クレデンシャル(ユーザ ID およびパスワード)を求めるときに、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 を指定できます。絶対 TTL を指定することにより、Content Engine から配信されるコンテンツの非アクティビティ タイムアウト機構にセキュリティが追加されます。絶対 TTL の期限が切れると、クライアント ブラウザの再認証が必要になり、有効なクレデンシャルの入力が必要になります。

何らかの認証方式による WCCP 対応ルータ リダイレクト モード、または NTLM 認証方式によるプロキシ リダイレクト モードの共有ワークステーション環境には、セキュリティに関する脆弱性が存在します。その場合、Content Engine では、認証キャッシュに保存されている認証レコードへの索引としてクライアントの IP アドレスを使用できます。したがって、あるユーザがワークステーションに入力した有効なクレデンシャルが認証キャッシュにキャッシュされていれば、他のユーザは自身のクレデンシャルを提供しなくても、同じワークステーションの使用が認証されます。この状況におけるセキュリティを強化するには、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 オブジェクトをキャッシュします。

Content Engine で、基本認証および NTLM 認証によって認証された両方のコンテンツをキャッシュするには、次のコマンドを使用します。

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
 

Content Engine 上で NTLM オブジェクト キャッシングがイネーブルになっている場合、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 がサーバから 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 を使用して、スタンドアロン Content Engine の標準 Web キャッシュ サービス(サービス 0)またはカスタム Web キャッシュ サービス(サービス 98)をイネーブルにして設定する場合、Content Engine GUI ウィンドウ(Web Cache ウィンドウ [ WCCP > Web Cache ] および Custom Web Cache ウィンドウ [ WCCP > Custom Web Cache ])で、各 WCCP サービスに適用するルータ リストを指定する必要があります。Custom Web Cache ウィンドウの使用についての詳細は、ウィンドウの HELP ボタンをクリックしてください。

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

標準 web キャッシュ サービス(サービス 0)は、単一の WCCP Version 1 対応ルータまたは 1 台以上の WCCP Version 2 対応ルータに対し、Content Engine のポート 80 だけに HTTP トラフィックをリダイレクトすることを許可します。スタンドアロン Content Engine のポート 80 でリダイレクトされた HTTP を受信するには、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 ~ FC000000 です。

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
 

表B-3 に示す web キャッシュ サービス(サービス 0)以外のサービスをサポートするには、Content Engine が WCCP Version 2 を実行している必要があります。Content Engine 上で WCCP Version 2 ではなく Version 1 をイネーブルにした場合には、単一 WCCP ルータだけを設定し、サポート対象のサービス(標準 web キャッシュ サービス)だけをサポートできます。Version 2 を使用する場合には、最大 8 の WCCP ルータを設定し、特定の WCCP サービスおよびサポート対象のすべての WCCP サービスをサポートできます。


ヒント Content Engine GUI を使用してスタンドアロン Content Engine 上で WCCP Version 1 または Version 2 をイネーブルにするには、WCCP > Enable WCCP の順に選択し、Version 1 または Version 2 オプション ボタンをクリックします。

ステップ 2 Web キャッシュ サービスをサポートするルータを指定する、ルータ リストを作成します。Content Engine の web キャッシュ サービスをサポートする、すべてのルータの IP アドレスまたはマルチキャスト アドレスを入力します。各種 WCCP サービスに対して複数の異なるルータを使用する場合には、複数のルータ リストを作成する必要があります。次に、単一のルータ(標準 web キャッシュ サービスを設定した IP アドレス 10.0.1.1 のルータ)だけを含む、ルータ リスト 1 を作成する例を示します。

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

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-cahce サービスをイネーブルにします。

Router(config)# ip wccp web-cache
 

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

Router(config)# interface type number
 

次に、ルータの Ethernet 0/1 インターフェイス 0/1 に標準 web キャッシュ サービスの実行を設定する例を示します。

Router(config)# interface ethernet 0/1
 

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

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


 

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

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

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

スタンドアロン Content Engine にカスタム Web キャッシュ サービスを設定するには、 wccp custom-web-cache グローバル コンフィギュレーション コマンドを使用します。Content Engine で custom-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 ~ FC000000 です。

dst-port-mask

(任意)パケット宛先ポート番号の照合に使用するマスクを設定します。

port _ hex_num

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

src-ip-mask

(任意)パケット送信元 IP アドレスの照合に使用するマスクを設定します。

src-port-mask

(任意)パケット送信元ポート番号の照合に使用するマスクを設定します。

router-list-num

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

num

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

port

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

port

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

assign-method-strict

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

hash-destination-ip

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

hash-destination-port

(任意)宛先ポートの負荷分散ハッシュを定義します。

hash-source-ip

(任意)送信元 IP アドレスの負荷分散ハッシュを定義します。

hash-source-port

(任意)送信元ポートの負荷分散ハッシュを定義します。

l2-redirect

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

mask-assign

(任意)Content Engine の配置にマスク方式を使用します。

password

(任意)認証パスワードを設定します。

key

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

weight

(任意)負荷分散の重みの比率を設定します。

percentage

パーセント値(0 ~ 100)

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

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

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

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


ステップ 1 スタンドアロン Content Engine 上で WCCP Version 2 をイネーブルにします。

ContentEngine(config)# wccp version 2
 

custom-web キャッシュ サービス(サービス 98)をサポートするには、Content Engine 上で WCCP Version 2 を実行している必要があります。 表B-3 に示す、標準 web キャッシュ サービス(サービス 0)以外の WCCP サービスを実行するには、WCCP Version 2 が必要です。


ヒント Content Engine GUI を使用してスタンドアロン Content Engine の WCCP をイネーブルにするには、WCCP > Enable WCCP の順に選択して、Version 1 または Version 2 オプション ボタンをクリックします。

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

次に、単一のルータ(custom-web キャッシュ サービスを設定した IP アドレス 10.0.1.1 のルータ)だけを含む、ルータ リスト 1 を作成する例を示します。

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 )で、custom-web キャッシュ サービスに適用するルータ リストを指定する必要があります。

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

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 ルータ上で custom-web-cahce サービス(サービス 98)をイネーブルにします。

Router(config)# ip wccp 98
 

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

Router(config)# interface type number
 

次に、Ethernet 0 インターフェイスに custom-web キャッシュ サービスの実行を設定する例を示します。

Router(config)# interface ethernet 0
 

ステップ 9 ルータが、cusbom-web キャッシュ サービスに発信インターフェイスを使用するように設定します。

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


 

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

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

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

スタンドアロン Content Engine および WCCPルータに、reverse-proxy サービス(サービス 99)を設定する手順は、次のとおりです。


ステップ 1 スタンドアロン Content Engine 上で WCCP Version 2 をイネーブルにします。

ContentEngine(config)# wccp version 2
 

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


ヒント Content Engine GUI を使用して、スタンドアロン Content Engine の WCCP Version 2 をイネーブルにするには、WCCP > Enable WCCP の順に選択して、Version 2 オプション ボタンをクリックします。

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

次に、単一のルータ(reverse-cache サービスを設定した IP アドレス 10.0.1.1 のルータ)だけを含む、ルータ リスト 1 を作成する例を示します。

ContentEngine(config)# wccp router-list 1 10.0.1.1
 

Content Engine GUI を使用してこの Content Engine のWCCP をイネーブルにして設定する場合には、Reverse Proxy ウィンドウ( WCCP > Reverse Proxy )で、reverse-proxy サービスに適用するルータ リストを指定する必要があります。

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

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 ルータ上で reverse-proxy サービス(サービス 99)をイネーブルにします。

Router(config)# ip wccp 99

ステップ 8 reverse-proxy サービスを実行するインターフェイスを指定します。

Router(config)# interface type number
 

次に、ルータの Ethernet 0 インターフェイスに、reverse-proxy サービスの実行を設定する例を示します。

Router(config)# interface ethernet 0
 

ルータが、reverse-proxy サービスに発信インターフェイスを使用するように設定します。ルータは、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 は、オリジン HTTPS サーバへの HTTPS クライアント要求を SSL ターミネーションまたはトンネリングによって処理します。

「HTTPS クライアント要求の SSL ターミネーションの概要」

「HTTPS クライアント要求のトンネリングの概要」

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

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

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

HTTPS クライアント要求の SSL ターミネーションの概要

Content Engine による HTTPS クライアント要求の SSL ターミネーションとは、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 ターミネーション機能を適正に実行するには、Content Engine 上に、オリジン HTTPS サーバの SSL 証明書 およびオリジン HTTPS サーバの秘密鍵をインストールする必要があります。Content Engine に適切な証明書と秘密鍵がインストールされている場合、SSL ターミネーション機能は、透過モードおよびプロキシ モードのどちらでも機能します。特定の要求コンテンツをキャッシュする場合には、これらのオリジン HTTPS サーバの適正な証明書および鍵を Content Engine にインポートし、Content Engine が、これらのオリジン HTTPS サーバからのコンテンツをキャッシュするように設定する必要があります。スタンドアロン Content Engine の場合、Content Engine CLI を使用して設定します。詳細は、「HTTPS キャッシングに使用する証明書と秘密鍵の設定」 を参照してください。

ACNS ソフトウェア リリース 5.2.1 以降では、要求された HTTPS サーバが Content Engine 上に設定されていれば、WCCP モードおよびマニュアル プロキシ モードで HTTPS 要求の SSL ターミネーションがサポートされます。それ以外の HTTPS トラフィックは、トンネリングされます。

HTTPS クライアント要求のトンネリングの概要

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

ACNS ソフトウェア リリース 3.0 以降は、HTTP 仕様に定義されている標準 HTTPS トンネリング方式である、CONNECT 方式による HTTPS トンネリングをサポートしています。

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

スタンドアロン Content Engine での HTTPS プロキシ キャッシングの設定

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

Content Engine で、Content Engine が HTTPS プロキシ サーバとして設定されているクライアント ブラウザからの HTTPS 要求を処理するには、Content Engine に HTTPS プロキシ モードを設定します。


) 着信 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 着信 プロキシ プロキシ ポートおよびcustom-web キャッシュ サービスを設定します。

no https destination-port allow 443 563
or
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 要求を戻します。

次に、スタンドアロン Content Engine に、HTTPS-over-HTTP プロキシ キャッシング サポートを設定する例を示します。


ステップ 1 着信プロキシ モード要求のポート番号を設定します。

ContentEngineA(config)# https proxy incoming ports
 

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

次に、Content Engine がポート 8080、8081、および 9090 で HTTPS 要求を受け入れるように設定する例を示します。複数のポートを指定するには、各ポートを空白で区切って入力します。

ContentEngineA(config)# https proxy incoming 8080 8081 9090
 

) 複数のポートを指定する場合には、各ポートを空白で区切って入力します。


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

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

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 へ送信するように設定する例を示します。ホスト 10.1.1.1 は、Content Engine A のプライマリ発信 HTTPS プロキシ サーバとして設定されます。ホスト 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 以前では、Content Engine に設定できる発信 HTTPS プロキシ サーバは 1 台だけでした。ACNS ソフトウェア リリース 5.2.1 では、HTTPS-over-HTTP プロキシ要求に対して、最大 8 台の発信プロキシ サーバを指定できます。最大 8 台の発信プロキシ サーバをサポートする場合の利点は、1 台の発信プロキシ サーバに障害が発生した場合、Content Engine は次に指定されている発信プロキシ サーバにフェールオーバーするので、冗長性が提供されることです。発信要求はすべて、プライマリ発信プロキシ サーバに転送されます。プライマリ プロキシ サーバに障害が発生すると、要求は、リストにある次のアクティブ プロキシ サーバに転送されます。

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

ContentEngineA# show https proxy
 


 

スタンドアロン Content Engine での HTTPS 透過キャッシングの設定

Content Engine で HTTPS 透過キャッシングをサポートするには、Content Engine およびルータに、WCCP Version 2 HTTPS キャッシング サービス(https-cache サービス [ サービス 70 ])のサポートを設定する必要があります。https-cache サービスは、WCCP Version 2 対応ルータが ポート 443 TCP トラフィックを代行受信し、(HTTPS 透過キャッシングが設定され、透過フォワード プロキシ サーバとして動作している)Content Engine に HTTPS トラフィックをリダイレクトできる、WCCP 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
 

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

ACNS 5.2 ソフトウェアには、https-cache サービス(サービス 70)用に、別の代行受信モード(accept-all モード)が追加されています。accept-all モードがイネーブルである場合、Content Engine は、Content Engine にオリジン HTTPS サーバが設定されているかどうかに関係なく、すべての HTTPS 要求を代行受信します。オリジン HTTPS サーバの秘密鍵または証明書が Content Engine に設定されていない場合、Content Engine は、要求の SSL ターミネーションを実行せずに、要求をオリジン HTTPS サーバへトンネリングします(ACNS 5.1 ソフトウェアの場合、サポートが設定されていない HTTPS サーバに宛てられた HTTPS 要求は、Content Engine によりバイパスされます)。

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 の設定」 を参照してください。

次に、WCCP Version 2 を実行しているスタンドアロン Content Engine および単一ルータに、HTTPS 透過キャッシングを設定する例を示します。


ステップ 1 https-cache サービス(サービス 70)をサポートするように、ルータを設定します。

a. ルータ(例では Router A)上で、WCCP Version 2 をイネーブルにします。

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

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

RouterA(config)# ip wccp 70
 

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

Router(config)# ip wccp 70 redirect out
 

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

a. https-cache サービスをサポートするルータのリストを設定します。次に、単一のルータ(IP アドレス 10.2.202.1 の Router A)だけを含む、ルータ リスト 1 を作成する例を示します。

ContentEngine(config)# wccp router-list 1 10.1.202.1
 

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

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 モードをイネーブルにします。この機能は、通常、フィルタリングを目的として使用します(たとえば、Content Engine で SmartFilter または Websense ソフトウェアを使用し、トンネリングされた HTTPS 要求をフィルタリングできます)。

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 サーバのホスト名(abcl)を入力し、これらの設定を Content Engine でイネーブルにします(次の例のように、サブモードで enableを入力します)。これらは、指定した HTTPS サーバのコンテンツ キャッシングをイネーブルにするために必要な最小限の設定です。

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

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

ステップ 6 (任意)SLL 通信の各種特性を詳細に制御するために、Content Engine 上で拡張 HTTPS サーバ設定を実行します。

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

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

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

または

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

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

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

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

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


 

スタンドアロン Content Engine での HTTPS サーバの設定

https server server-name グローバル コンフィギュレーション コマンドを使用して Content Engine にオリジン HTTPS サーバ名を指定したあと、設定した HTTPS サーバに一連のパラメータを指定できます(次の例を参照)。これらのパラメータは、HTTPS コンフィギュレーション サブモードまたはグローバル コンフィギュレーション モードから指定できます。

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

表7-9 に、スタンドアロン Content Engine 上で HTTPS サーバ設定を行うためのグローバル コンフィギュレーション コマンドを示します。

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

コマンド
目的

https server name cert

https server name key

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

https server name host

オリジン HTTPS サーバの IP アドレスを指定します。このコマンドを使用する場合は、HTTPS サーバとして動作しているセントラル オフィスの Content Engine の IP アドレスを使用します。この HTTPS サーバを使用できるようにするには、 https server name enable グローバル コンフィギュレーション コマンドを使用します。

https server name
protocol-version

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

https server name
serverauth

HTTPS サーバへのアクセスに、認証を使用できるようにします。また、無効な認証、ドメイン名の不一致、証明書の有効期限エラー、認識されない CA(認証局)などの認証エラーを無視するように設定できます。

デフォルトでは、HTTPS サーバ認証は、Content Engine 上でイネーブルになっています。HTTPS サーバ認証で特定のエラーを無視するには、 ignore コマンド オプションを使用します。

https server name
session-cache

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

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

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

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

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

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


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


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

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

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

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

 

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

パラメータ
説明

certgroup

証明書グループの追加、作成、または削除をイネーブルにします。

cert-name

証明書グループの名前

import

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

create

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

remove

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

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

https proxy outgoing host グローバル コンフィギュレーション コマンドを使用して、Content Engine が HTTPS 発信プロキシを使用するように設定すると、すべての着信 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 へ送信するように設定されます。ホスト 10.1.1.1 は、Content Engine A のプライマリ発信 HTTPS プロキシ サーバとして指定されます。ホスト 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 以前では、Content Engine に設定できる発信 HTTPS プロキシ サーバは 1 台だけでした。ACNS ソフトウェア リリース 5.2.1 には、Content Engine に最大 8 台の発信 HTTPS プロキシ サーバを設定できる機能が追加されています。詳細は、「スタンドアロン Content Engine の ためのプライマリおよびバックアップ プロキシ サーバの設定」 を参照してください。

透過モードでは、別の HTTPS プロキシ サーバに宛てられたすべての HTTPS プロキシ スタイル要求が受け入れられます。Content Engine は、 proxy-protocols transparent グローバル コンフィギュレーション コマンドの定義に基づいて、透過的に受信した要求を処理します。詳細は、「HTTP および HTTPS 発信プロキシの除外設定」 を参照してください。

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

宛先ポートへのアクセスを制御(許可または拒否)する規則が設定されていない場合、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 に FTP キャッシングを設定するには、Content Engine GUI または CLI を使用します。


スタンドアロン 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 キャッシングは、透過プロキシ モードおよび非透過プロキシ モードでサポートされます(ACNS ソフトウェア リリース 5.1 および 5.2 では、ネイティブ FTP キャッシングは透過プロキシ モードでのみサポートされます)。詳細は、「スタンドアロン 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 要求のコンテンツをキャッシュします。

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.4.1 では、非透過 FTP ネイティブ要求のプロキシ認証をサポートするために、 ftp-native proxy コンフィギュレーション コマンドに authentication オプションが追加されました。詳細は、「非透過 FTP ネイティブ要求の要求認証の設定」 を参照してください。

ACNS ソフトウェア リリース 5.4.1 では、Content Engine 上で実行しているネイティブ FTP プロキシ サービスへのアクセスを許可または拒否する IP ACL をサポートするために、 ftp-native コンフィギュレーション コマンドに access-list オプションが追加されました。

ContentEngine(config)# ftp-native ?

access-list Configure access-lists for ftp-native proxy-mode and
transparently redirected connections
object Configuration of FTP object
proxy Configuration for proxy-mode requests
 

詳細は、「IP ACL による ネイティブ FTP アクセスのコントロール」 を参照してください。

ACNS ソフトウェア リリース 5.3.1 では、FTP-over-HTTP キャッシングと FTP ネイティブ キャッシングを明確に区別するために、 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
 

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-over-HTTP キャッシングの設定

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

非透過 FTP-over-HTTP キャッシングでは、スタンドアロン Content Engine は、クライアント ブラウザからの FTP-over-HTTP 要求に対する非透過フォワード プロキシ サーバとして動作します。ACNS ソフトウェア リリース 5.1 以降では、URL に FTP プロトコルが指定されている場合( ftp://ftp.mycompany.com/ftpdir/ftp_file など)、プロキシ モードの HTTP 要求を使用した FTP URL クライアント要求のプロキシとキャッシングがサポートされます。

次に、エンドユーザがブラウザを使用して FTP サーバの一般ファイルにアクセスする場合の FTP-over-HTTP 要求の例を示します。

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

FTP プロキシは、一般的に使用されている MIME タイプをサポートし、クライアントに対応するヘッダーを添付し、適切な転送タイプ(バイナリまたは 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 つのポートを指定できます。

次に、Content Engine が、クライアント ブラウザからの FTP-over-HTTP 要求をポート 8080、8081 および 9090 で受信するように設定する例を示します。同じコマンド ラインで、最大 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 コマンドを使用して、Content Engine がポート 80 以外のポートで FTP-over-HTTP 要求を受け入れるように設定する場合には、クライアント ブラウザが FTP-over-HTTP 要求をそのポートに送信するように、ブラウザを設定する必要があります。詳細は、「スタンドアロン Content Engine をクライアント ブラウザの直接の宛先として指定」 を参照してください。

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

次に、Content Engine 上で Apache トランザクション ログ形式を使用し、トランザクション ロギングをイネーブルに設定する例を示します。

ContentEngine(config)# transaction-logs format apache
ContentEngine(config)# transaction-logs 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 キャッシングのディレクトリ リスト オブジェクトとファイル オブジェクトに対して、キャッシュの最大 TTL を 3 日間に設定する例を示します。

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

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

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 プロキシ サーバは、Content Engine が、ICP または WCCP を使用せずに、キャッシュ ミスのすべての FTP トラフィックを送信する親キャッシュ(アップストリーム FTP プロキシ サーバ)です。詳細は、 「プライマリ発信 FTP プロキシ サーバの指定」 を参照してください。

ステップ 5 ftp-over-http proxy anonymous-pswd グローバル コンフィギュレーション コマンド を使用して、anonymous(匿名)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
 


 

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

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

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

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

ACNS ソフトウェア リリース 5.1 および 5.2 では、FTP ネイティブ キャッシングのサポートに、次のすべての制約が適用されます。

1. FTP オブジェクトの最大サイズは 200 メガバイトです。

2. FTP クライアント要求と FTP サーバ プルの帯域幅管理はサポートされません。

3. FTP クライアント要求の Type of Service(ToS; サービス タイプ)はサポートされません。

4. cdnfs の事前配信ファイルはサポートされません。

5. ICAP はサポートされません。

6. 非透過プロキシはサポートされません。

7. プロキシ認証はサポートされません。

8. ICP はサポートされません。

9. ヒーリング モードはサポートされません。

10. レイヤ 4 スイッチ FTP リダイレクトはサポートされません。

11. FTP 要求プロキシ ルールはサポートされません。

12. MIN-TTL および AGING-HEURISTIC-TTL キャッシュ コントロール ノブ設定はサポートされません。

13. URL フィルタリング スキーマ(good リスト、bad リスト、N2H2、Websense および SmartFilter)はサポートされません。

14. Macintosh FTP サーバからのファイルのキャッシングはサポートされません。

15. FTP プロキシ サーバのオフライン操作はサポートされません。

ACNS ソフトウェア リリース 5.3.x では、制約 6(非透過プロキシの非サポート)を除き、前述の 15 の制約がすべて適用されます。ACNS ソフトウェア リリース 5.3.1 では、FTP ネイティブ モード用の非透過プロキシのサポートが追加されました。詳細は、「非透過 FTP ネイティブ キャッシングの設定」 を参照してください。

ACNS ソフトウェア リリース 5.4.x では、次の 2 つの制約を除き、前述の 15 の制約がすべて適用されます。

制約 6(非透過プロキシの非サポート)

制約 7(非透過ネイティブ FTP 要求のプロキシ認証の非サポート)

ACNS ソフトウェア リリース 5.4.1 では、非透過 FTP ネイティブ要求用のプロキシ認証(Content Engine での要求認証)のサポートが追加されました。ACNS ソフトウェア リリース 5.4.1 では、非透過 FTP ネイティブ要求のプロキシ認証をサポートするために、 ftp-native proxy コンフィギュレーション コマンドに authentication オプションが追加されました。ACNS ソフトウェア リリース 5.4.1 以降は、非透過 FTP ネイティブ要求の認証について、RADIUS、TACACS+、および LDAP をサポートしています。

デフォルトでは、ftp-native プロキシ認証機能はディセーブルです。FTP プロトコルは本質的に安全ではないので、セキュア チャネル上で配信される方法(HTTP など)と異なり、認証クレデンシャルがネットワーク上で傍受され、ユーザのクレデンシャルが流出する可能性があります。ftp-native プロキシ認証機能をイネーブルにするには、次のコマンドを使用します。

ContentEngine(config)# ftp-native proxy authentication enable
 

FTP ネイティブ要求の IP ACL サポートの概要

ACNS ソフトウェア リリース 5.4.1 では、IP ACL を使用して、スタンドアロン Content Engine 上で実行している FTP プロキシ サービスへのアクセスを許可または拒否することができます。詳細は、「IP ACL による ネイティブ FTP アクセスのコントロール」 を参照してください。

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

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

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

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


) Content Engine が NAT の背後にある場合、Content Engine は転送先の IP アドレスを認識できないので、FTP クライアントと FTP ネイティブ プロキシ間との転送にパッシブ モードを使用できません。


ACNS ソフトウェア リリース 5.4.1 以降では、非透過 FTP ネイティブ要求のプロキシ認証(Content Engine での認証)がサポートされています。Content Engine に拡張 Squid またはカスタム ロギングのいずれかの形式が設定されていれば、プロキシ認証中に FTP クライアント(Reflection X クライアントなど)から提供されたユーザ名がトランザクション ログにロギングされます。

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


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

ContentEngine(config)# ftp-native proxy incoming ports
 

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

次に、Content Engine の 8 つのポート(ポート 8501、8502、8503、8504、8505、8506、8507、8508)で FTP クライアントからの FTP ネイティブ要求を受け入れるように設定する例を示します。次の例のように、同じコマンドラインに最大 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 MB に設定する例を示します。

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

ステップ 3 (任意)Content Engine が IP ACL を使用して、Content Engine 上で実行しているネイティブ FTP プロキシ サービスへのアクセスを許可または拒否するように設定します。

ContentEngine(config)# ftp-native access-list in {std-acl-num | std-acl-name}
ContentEngine(config)# ftp-native access-list out {ext-acl-num | ext-acl-name}
 

たとえば、192.168.1.9 サブネットワーク上の FTP クライアントに対して、Content Engine 上で実行しているネイティブ FTP プロキシ サービスへのアクセスを許可する標準アクセス リストを定義するには、次のコマンドを使用します。

ContentEngine(config)# ip access-list standard 3
ContentEngine(config-std-nac1)# permit 192.168.1.0 0.0.0.255
ContentEngine(config-std-nac1)# exit
ContentEngine(config)#
 

作成した標準 IP ACL(access list 3)をネイティブ FTP プロキシ サービスに対応付け、Content Engine 上で標準 IP ACL をイネーブルにします。

ContentEngine(config)# ftp-native access-list in 3
 

Content Engine は、指定した IP ACL(ACL_3 など)を、ネイティブ FTP 着信トラフィックに適用します。


) ACNS ソフトウェア リリース 5.4.1 では、IP ACL を使用して、スタンドアロン Content Engine 上で実行している FTP プロキシ サービスへのアクセスを許可または拒否することができます。詳細は、「IP ACL による ネイティブ FTP アクセスのコントロール」 を参照してください。


ステップ 4 (任意)カスタム acl-denied メッセージを作成し、Content Engine にダウンロードします。Content Engine は、ネイティブ FTP プロキシ サービス用に定義された IP ACL に基づいて着信接続を拒否した場合、FTP クライアント(Reflection X クライアント、WS-FTP クライアント、または UNIX または DOS コマンドライン FTP プログラムのクライアントなど)に対して、このカスタム メッセージを表示します。

a. acl-denied メッセージを作成し、テキスト ファイルとして保存します(たとえば、myserver.com というサーバ上の errors ディレクトリに warning.txt というファイル名で保存します)。カスタム acl-denied メッセージのファイル サイズは、最大 16 KB です。

次に、myserver.com というサーバ上の errors ディレクトリに warning.txt ファイルをアップロードする例を示します。

ContentEngine# ftp-native custom-message upload acl-denied
http://www.myserver.com/errors/ftp-native-acl-denied.txt
 

b. ftp-native-acl-denied.txt ファイルを Content Engine にダウンロードします。

ContentEngine# ftp-native custom-message download acl-denied
http://www.myserver.com/errors/ftp-native-acl-denied.txt
 

c. Content Engine にダウンロードしたカスタム acl-denied メッセージの内容を表示します。

ContentEngine# show ftp-native custom-message acl-denied ftp-native-acl-denied.txt
 

ステップ 5 (任意)FTP クライアントが Content Engine にプロキシ モード接続した場合、カスタム welcome メッセージを表示するように設定します。

a. テキスト エディタを使用してカスタム welcome メッセージを作成し、テキスト ファイル(welcome.txt など)として保存します。

b. HTTP、HTTPS、または FTP プロトコルを使用して、サーバに welcome.txt ファイルをアップロードします。カスタム welcome メッセージのファイル サイズは、最大 16 KB です。

次に、myserver.com というサーバ上の mgmt ディレクトリに welcome.txt ファイルをアップロードする例を示します。

ContentEngine# ftp-native custom-message upload welcome
http://www.myserver.com/mgmt/welcome.txt
 

c. Content Engine に welcome.txt ファイルをダウンロードします。

ContentEngine# ftp-native custom-message download welcome
http://www.myserver.com/errors/welcome.txt
 

d. ダウンロードしたファイルが存在することを確認します。

ContentEngine# show ftp-native custom-message
welcome
acl-denied
ContentEngine#
 

e. ダウンロードしたカスタム welcome メッセージの内容を表示します。

ContentEngine# show ftp-native custom-message welcome
Welcome to the Content Engine that is acting as your FTP proxy.
Login to the proxy using the proxy username and password.
 

) 詳細は、「FTP ネイティブ要求に対する FTP プロキシ応答用のカスタム メッセージの作成」 を参照してください。


ステップ 6 FTP クライアント(UNIX コマンドライン FTP プログラムなど)を使用して Content Engine に要求を送信し、Content Engine が FTP クライアント(Reflection X クライアント、WS-FTP クライアント、または UNIX または DOS コマンドライン FTP プログラムなど)から着信 FTP 接続を受信した場合、カスタム welcome メッセージが表示されるかどうかを確認します。

次に、FTP クライアントから Content Engine(IP アドレス 172.31.255.255)のポート 8501 にネイティブ FTP 要求を送信する例を示します。着信 FTP 接続が受け入れられると、Content Engine から FTP クライアントに対して、カスタム welcome メッセージが表示されます。

shell# ftp ñd 172.31.255.255 8501
Connected to 172.31.255.255
220 Welcome to the Content Engine that is acting as your FTP proxy. Login to the proxy using username and password.
 

ステップ 7 Content Engine にトランザクション ロギングを設定し、イネーブルにします。

ACNS ソフトウェア リリース 5.4.1 以降では、Content Engine に拡張 Squid またはカスタム ロギング形式のいずれかが設定されていると、プロキシ認証中に FTP クライアントから提供されたユーザ名がトランザクション ログにロギングされます。

次に、Content Engine で拡張 Squid トランザクション ログ形式を使用し、トランザクション ロギングをイネーブルにする例を示します。

ContentEngine(config)# transaction-logs format extended-squid
ContentEngine(config)# transaction-logs enable
 

カスタム トランザクション ロギング形式を使用する場合には、 transaction-logs format custom コマンドの設定時に、 %u 形式指定子を使用する必要があります。詳細は、「トランザクション ロギングのイネーブル化」 を参照してください。

ステップ 8 Content Engine 上で FTP ネイティブ アクティブ モードをイネーブルにします。

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

ステップ 9 (任意)Content Engine 上で、FTP プロキシ認証機能をイネーブルにします。

デフォルトでは、この機能はディセーブルです。FTP プロトコルは実質的には安全ではないので、セキュア チャネル上で配信される方法(HTTP など)と異なり、認証クレデンシャルがネットワーク上で傍受され、ユーザのクレデンシャルが流出する可能性があります。

ContentEngine(config)# ftp-native proxy authentication enable
 

ftp-native proxy authentication enable コマンドを入力したとき、Content Engine 上に認証サービス(RADIUS、LDAP、NTLM、または TACACSなど)が設定されていないと、メッセージが表示されます。FTP プロキシ認証機能をイネーブルにする前に、Content Engine 上に認証サービスを設定する必要があることを通知するメッセージです。

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

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

ContentEngine# show ftp-native
 

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

ContentEngine# show statistics ftp-native
 

コマンド出力に、Content Engine が受信した FTP ネイティブ GET 要求数、GET 要求の FTP ネイティブ ヒット数とミス数、および Content Engine が受信した FTP ネイティブ PUT 要求数が表示されます。ACNS ソフトウェア リリース 5.4.1 以降では、コマンド出力に、透過 FTP ネイティブ要求数、非透過 FTP ネイティブ要求数、ネイティブ FTP プロキシ認証要求数、失敗したネイティブ FTP プロキシ認証要求数も表示されます。

ステップ 13 Content Engine 上の FTP ネイティブ統計情報をクリアします。

ContentEngine# clear statistics ftp-native
 


 

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

非透過 FTP プロキシ サーバとして動作する Content Engine は、Reflection X クライアント、WS-FTP クライアント、UNIX または DOS コマンドライン FTP プログラムなどの FTP クライアントからの FTP ネイティブ要求を受け入れることができます。ここでは、これらの各種 FTP クライアントが、FTP クライアントの非透過 FTP プロキシ サーバとして動作している Content Engine に対して、FTP ネイティブ要求を直接送信するように設定する例を示します。


) ACNS ソフトウェア リリース 5.4.1 では、非透過 FTP ネイティブ要求のプロキシ認証(Content Engine での認証)のサポートが追加されました。Content Engine に拡張 Squid ロギングまたはカスタム ロギングのどちらかのロギング形式が設定されている場合、プロキシ認証中に FTP クライアント(Reflection X クライアント、WS-FTP クライアント、UNIX または DOS コマンドライン FTP プログラムのクライアントなど)によって提供されるユーザ名が、トランザクション ログにロギングされます。FTP プロキシ認証機能の詳細は、「非透過 FTP ネイティブ要求の要求認証の設定」 を参照してください。


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


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

図7-2 Reflection X クライアント ソフトウェアによる FTP サイトへの接続

 

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

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

図7-3 Properties ウィンドウ

 

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

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

 

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

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

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

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

図7-5 Passthrough 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 port フィールドには、「非透過 FTP ネイティブ キャッシングの設定」ステップ 1 で、 ftp-native proxy incoming port グローバル コンフィギュレーション コマンドに指定したポート番号と同じポート番号を入力する必要があります。

ステップ 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 Password ダイアログボックス

 

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


 

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


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

図7-8 WS-FTP クライアント ソフトウェアを使用した FTP サイト(FTP サーバ)への接続

 

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

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

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

ステップ 5 FTP サーバのユーザ名および IP アドレスを入力します。

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

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

ステップ 8 Tools メニューから、 Options > Firewall を選択します。

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

ステップ 10 (クライアントの非透過プロキシ サーバとして動作している)Content Engine の名前および IP アドレスを入力します。

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

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

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

ステップ 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 Tools メニューから、 Options > Firewall を選択します。

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

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

ステップ 21 type フィールドで、script <fswc>(firescript 名)を選択します。


ヒント 実際には、ファイアウォール スクリプトは、内部的にサイトまたはユーザ名形式で Content Engine にプロキシされます。

ステップ 22 WS-FTP Home ウィンドウで、 Tools > 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 10.1.1.50 8501
Connected to 10.1.1.50
220 Welcome to FTP-proxy. Login to the proxy using username and password.
Name (10.1.1.50:admin): smartuser@abchost.company.com
---> USER smartuser
331 Password required for smartuser.
Password:
---> PASS XXXX
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' followed by the 'USER username' command.
ftp> site host.abchost.com
---> SITE host.abchost.com
220 via2.abchost.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.
ftp> user anonymous
---> USER anonymous
331 Guest login ok, send your complete e-mail address as password.
Password:
---> PASS XXXX
230 Guest login ok, access restrictions apply.
ftp> quit
---> QUIT
shell#
 

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

ftp-native サービス(サービス 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 サーバとのデータ接続に、クライアントが Content Engine にアクセスしたときと同じモード(アクティブまたはパッシブ)を使用します。

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 サーバとアクティブ モードでデータを送受信します。

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

Content Engine がネイティブ FTP 要求用に作成する URL の形式は、FTP ログイン名および転送モード(バイナリまたは ASCII ファイル転送モード)によって異なります。

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

ファイル転送モードがバイナリ モードの場合には、URL の最後に文字列「;type=i」が含まれます。次に、バイナリ モードが使用された場合に、Content Engine が作成する特定ユーザ用の URL 形式の例を示します。

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

次の例のように、「anonymous(匿名)」ユーザ ログインおよびASCII ファイル転送モードの URL には、追加フィールドは含まれません。

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

次に、Content Engine でネイティブ FTP を使用する場合の 2 つの例を示します。最初の例では、ユーザは実際のユーザ名「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#
 

次の例では、ユーザは anonymous(匿名)ユーザとしてログインしますが、要求したファイル(test.c)を取得できません。このファイルが、anonymous(匿名)ユーザ用のホーム ディレクトリである 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 にアクセスしたときと同じモード(アクティブまたはパッシブ)を使用します。このコマンドを指定しない場合、Content Engine はオリジン FTP サーバへのデータ接続にパッシブ モードを使用します。

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

次に、Content Engine 上で Apache トランザクション ログ形式を使用し、トランザクション ロギングをイネーブルに設定する例を示します。

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

詳細は、「トランザクション ロギングのイネーブル化」 を参照してください。

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

ContentEngine(config)# ftp-native object max-size ?
<1 - 204800> Maximum size of a caceable object in Kbytes (default is 204800)
 

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

FTP 要求の透過リダイレクションがサポートされるのは、WCCP Version 2 を使用する場合だけです。レイヤ 4 スイッチを使用した透過リダイレクションはサポートされません。

a. FTP ネイティブ要求を Content Engine にリダイレクトするルータのリストを定義します。次に、単一の WCCP Version 2 ルータ(IP アドレス 10.77.157.41のルータ)だけを含む、ルータ リスト 1 を設定する例を示します。

ContentEngine(config)# wccp router-list 1 10.77.157.41
 

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

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

ステップ 5 (任意)Content Engine が IP ACL を使用して、ネイティブ FTP プロキシ サービスへのアクセスを許可または拒否するように設定します。

ContentEngine(config)# ftp-native access-list in {std-acl-num | std-acl-name}
ContentEngine(config)# ftp-native access-list out {ext-acl-num | ext-acl-name}
 

詳細は、「IP ACL による ネイティブ FTP アクセスのコントロール」 を参照してください。

ステップ 6 WCCP ルータ上で、ルータが FTP ネイティブ要求を透過的に代行受信し、FTP プロキシ サーバとして動作している Content Engine に要求をリダイレクトするように設定します。

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
 

ステップ 7 Content Engine 上で FTP プロキシがイネーブルであることを確認します。

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#
 

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

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

ステップ 9 (任意) wccp ftp-native mask グローバル コンフィギュレーション コマンドを使用して、着信透過 FTP ネイティブ要求用の Content Engine の割り当てに使用するマスクを指定します。たとえば、リダイレクトされたパケットの宛先 IP アドレスと一致するマスクを設定するには、 dst-ip-mask コマンド オプションを使用します。宛先 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 転送のマスク負荷分散方式の設定」 を参照してください。

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

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

ContentEngine# show wccp masks ftp-native
 

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

ContentEngine# show ftp-native
 

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

ContentEngine# show statistics ftp-native
 

コマンド出力に、Content Engine が受信した FTP ネイティブ GET 要求数、GET 要求の FTP ネイティブ ヒット数とミス数、および Content Engine が受信した FTP ネイティブ PUT 要求数が表示されます。ACNS ソフトウェア リリース 5.4.1 以降では、コマンド出力に、透過 FTP ネイティブ要求数、非透過 FTP ネイティブ要求数、FTP ネイティブ プロキシ認証要求数、失敗した FTP ネイティブ プロキシ認証要求数も表示されます。

ステップ 14 Content Engine 上の FTP ネイティブ統計情報をクリアします。

ContentEngine# clear statistics ftp-native
 


 

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

ACNS ソフトウェア リリース 5.1 以降では、TFTP ゲートウェイ機能により、Content Engine で、ネイティブ TFTP を使用しているネットワーキング デバイスから要求されたコンテンツ ファイルを配信できます。Content Engine が TFTP から HTTP または TFTP から FTP への変換を実行するので、システム管理者は、TFTP 要求を処理するために専用 TFTP サーバを設定し、管理する必要はありません。この機能により、Content Engine は、クライアントからのネイティブ TFTP 要求をフロント エンドで受け入れ、その要求を HTTP または FTP プロトコルを使用してバック エンドで処理します。

コンテンツ ファイルには、ルータ ソフトウェア イメージ、ルータ設定、セット トップ ボックス イメージ、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 クライアントに戻されます。ファイルが見つからなかった場合、404 「File not found(ファイルが見つかりません)」メッセージがクライアントに送信されます。

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

tftp-server グローバル コンフィギュレーション コマンドを使用して、スタンドアロン Content Engine に TFTP サービスおよびゲートウェイを設定し、TFTP 要求への応答として、次の 2 つの方法で コンテンツを配信できます。

ローカル コンテンツの配信 ― Content Engine にローカル ディレクトリを設定し、TFTP サーバをイネーブルにします。「TFTP サーバおよびゲートウェイのイネーブル化」を参照してください。

リモート サーバからのコンテンツの配信 ― Content Engine に TFTP ゲートウェイ機能を設定します。「TFTP サーバおよびゲートウェイのイネーブル化」を参照してください。

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

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

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

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

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

要求に対してローカル コンテンツを配信する手順は、次のとおりです。


ステップ 1 Content Engine 上で TFTP サービスをイネーブルにします。

ContentEngine(config)# inetd enable tftp
 

ステップ 2 次の手順で、スタンドアロン Content Engine にローカル TFTP ディレクトリを設定します。

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

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

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

TFTP サーバは、完全パス名のないファイルを、デフォルトのディレクトリから検索します。TFTP サーバは、TFTP 要求に特定のディレクトリが指定されている場合に限り、他のローカル ディレクトリからファイルを検索します。

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


 

TFTP ゲートウェイを使用してリモート サーバからコンテンツを配信するには、TFTP サーバをイネーブルにし、TFTP ゲートウェイ(スタンドアロン 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 のホスト名または IP アドレスが明示的に含まれている TFTP 要求だけを受け入れます。


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

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

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

TFTP サーバは、TFTP 要求に特定のディレクトリが明示的に指定されている場合に限り、他のディレクトリからファイルを検索します。

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


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

次に、Content Engine が TFTP 要求に応答するために使用する 2 つのローカル ディレクトリを設定する例を示します。

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 }

次に、Content Engine が、アクセス リスト 1 を使用して TFTP アクセスの許可または拒否を判別するように設定する例を示します。

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

ステップ 3 TFTP ゲートウェイ機能をイネーブルにし、要求されたファイルがローカル ディレクトリに存在しない場合、Content Engine が 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 オプションを使用します。


Content Engine は、HTTP または FTP 用として、認証されたオブジェクトをキャッシュしません。これらのオブジェクトをキャッシュする場合には、 tftp-server gw コマンドのユーザ名とパスワード フィルードを空白のままにします。FTP の場合、この設定は、anonymous(匿名)アクセスの許可と同じになります。

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

ステップ 4 スタンドアロン Content Engine 上で TFTP サーバをイネーブルにします。

ContentEngine(config)# inetd enable tftp
 

a. 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
 

b. Content Engine が TFTP 要求に応答するために使用する 2 つのローカル ディレクトリを設定します。

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

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

c. TFTP サービスへのアクセスを許可する IP アクセス リストを指定します。

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

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

リモート サーバでファイルを検索するために、Content Engine 上の ACNS キャッシング サービスが送信する URL に、ディレクトリ名/myremotedir を使用します。この設定例では、次の URL が作成されます。

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


 

スタンドアロン Content Engine での DNS キャッシングの設定

ここでは、スタンドアロン Content Engine での Domain Name System(DNS; ドメイン ネーム システム)キャッシングの設定方法について説明します。説明する内容は、次のとおりです。

「スタンドアロン Content Engine での DNS キャッシングの概要」

「スタンドアロン Content Engine での DNS キャッシング サービス(サービス 53)の設定」

スタンドアロン Content Engine での DNS キャッシングの概要

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

DNS キャッシングにより、Content Engine は DNS エントリをキャッシュできるので、DNS サーバ解決のために毎回 WAN にアクセスする必要がなくなります。スタンドアロン Content Engine で DNS キャッシングをイネーブルにすると、Content Engine は、以降での同じクエリーを迅速に解決するために、最新の DNS クエリーの結果をキャッシュします。キャッシュされた情報は、クライアントからの以降の要求に使用されます。Content Engine は、DNS 情報を保存し、その情報を要求するクライアントに配信することによって、DNS キャッシング サーバとして動作します。


注意 スタンドアロン Content Engine 上で、WCCP 代行受信を使用した DNS キャッシングをイネーブルにする必要があります。

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

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

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

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

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

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

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

ACNS ソフトウェア 5.1 では、WCCP を使用した DNS 要求の透過的な代行受信がサポートされています。この機能をイネーブルにするには、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 キャッシュに応答可能なサーバがない場合、応答可能なサーバが使用できる状態になるまで、サービスの登録は解除されます。

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 コマンドまたは Content Engine GUI の System > DNS を使用して作成します)

オリジナル DNS サーバ ― 元の要求からの DNS サーバ(オリジナル DNS サーバ)

DNS WCCP 代行受信機能をイネーブルにすると(Content Engine および WCCP Version 2 対応ルータにサービス 53 を設定)、 表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])は、WCCP Version 2 対応ルータから Content Engine にクライアント要求を透過的にリダイレクトし、Content Engine で DNS 名を解決する WCCP サービスです。Content Engine は、DNS 名を解決すると、以降の DNS 要求に解決名を使用できるように、解決した DNS 名をローカルに保存します。

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


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

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

ステップ 2 ルータ上で dns キャッシング サービス(サービス 53)をイネーブルにします。

Router(config)# ip wccp 53
 

ステップ 3 サービス 53 を実行するインターフェイスを指定します。

Router(config)# interface type number
 

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

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

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

ContentEngine(config)# wccp version 2
 

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

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

ステップ 8 dns retry-period グローバル コンフィギュレーション コマンドを使用して、未応答の要求を廃棄するまでの経過時間を設定します。

ステップ 9 dns retry-timeout グローバル コンフィギュレーション コマンドを使用して、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

スタンドアロン Content Engine での TCP キープアライブの送信設定

デフォルトでは、Content Engine は、キープアライブを自動的には送信しません。スタンドアロン Content Engine が HTTP 接続上に TCP キープアライブを送信するように設定するには、 http tcp-keepalive enable グローバル コンフィギュレーション コマンドを入力する必要があります。 http tcp-keepalive enable コマンドを入力すると、Content Engine は、HTTP 接続上に 75 秒間隔でキープアライブを送信します。応答を受信すると、Content Engine は、75 秒間隔でキープアライブを送信し続けます。応答を受信しない(デバイスが応答しない)場合、Content Engine は 90 秒待機してからミスを記録します。ミスが 4 回続くと、Content Engine は HTTP 接続がダウンしているとみなし、接続を終了します。

接続を終了する前に、Content Engine がデバイスへの接続を試行する回数を指定するには、 tcp keepalive-probe-cnt グローバル コンフィギュレーション コマンドを使用します。カウントは 1 ~ 10 で、デフォルトは 4 回です。

Content Engine が TCP キープアライブを送信する間隔を指定するには、 tcp keepavlive-probe-interval グローバル コンフィギュレーション コマンドを使用します。設定できる間隔は、1 ~ 120 秒です。デフォルトは 75 秒です。

(デバイスから応答がない場合)Content Engine がミスを記録する前に待機する秒数を指定するには、 tcp keepalive-timeout グローバル コンフィギュレーション コマンドを使用します。タイムアウトの値は、1 ~ 120 秒です。デフォルトは 90 秒です。

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

デフォルトでは、Content Engines は、パフォーマンスを向上するために、サーバへの固定接続を使用します。ACNS ソフトウェア リリース 5.0.7 以降では、 rule action no-persistent-connection グローバル コンフィギュレーション コマンドを使用して、特定のドメイン、送信元および宛先 IP アドレス、またはポートの固定接続をディセーブルまたはイネーブルに設定できます。このコマンドは、サーバが固定接続をサポートしていない場合に便利です。

固定接続のイネーブル化

Content Engine は、固定アイドル タイムアウト(デフォルトでは 600 秒)が経過するまで、固定接続を保持します。HTTP 固定接続をイネーブルにした場合、キープアライブの送信は不要で、Content Engine はアイドル タイムアウトが経過するまで、接続を持続します。


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


固定接続上で応答またはデータが転送されると、アイドル タイムアウトはリセットされます。HTTP 固定接続は、クライアント、サーバ、またはその両方に設定できます。

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

Content Engine GUI を使用して、スタンドアロン Content Engine の固定接続をイネーブルにするには、 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 要求など)が送信されるか、データ転送が開始されるまでは、固定接続は開始されません。固定接続上で最初の要求またはデータが送信されない場合、read-write(rw)-timeout 設定が適用されます。データの送受信が完了する前に、何らかの理由で接続がアイドルになった場合にも、rw-timeout 設定が適用されます。この場合、接続は、rw-timeout の設定値に基づいてタイムアウトになります。読み書きデータの rw-timeout は、 tcp server-rw-timeout および tcp client-rw-timeout グローバル コンフィギュレーション コマンドを使用して、サーバまたはクライアントのいずれかに設定します。サーバおよびクライアントのデフォルトの rw-timeout 値は、いずれも 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#
 

Rules Template 機能を使用したスタンドアロン Content Engine のルール設定の詳細は、「スタンドアロン Content Engine の Rules Template の設定」 を参照してください。

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

ヒーリング モードにより、新たに追加した Content Engine のキャッシュ ミス時に、Content Engine クラスタの他のすべての Content Engine にクエリーを送信し、キャッシュ オブジェクトを取得することができます。オブジェクトがクラスタ内に存在しない場合、Content Engine は、発信プロキシまたはオリジン サーバを使用して要求を処理します。ヒーリング モードの Content Engine を、 ヒーリング クライアント と呼びます。クラスタ内で、ヒーリング クライアントの要求に応答する Content Engine を、 ヒーリング サーバ と呼びます。

WCCP Version 2 を実行している既存の Content Engine クラスタに Content Engine を追加した場合、新しい Content Engine は、Content Engine クラスタ内の他の Content Engine によって以前に保存されたコンテンツに対する要求を受信することがあります。このイベントは、 ニアミス と呼ばれます。要求が他の Content Engine に送信されていれば、キャッシュ ヒットになるからです。ニアミスは、Content Engine クラスタの全体的なキャッシュ ヒット率を低下させます。


) ヒーリング モードは、要求が Content Engine に透過的にリダイレクトされる場合に限り、ヒーリング クライアント上で起動します。クライアントが、(非透過フォワード プロキシ サーバとして動作している)Content Engine に直接要求を送信する場合には、ヒーリング モードは起動しません。


Content Engine クラスタ内の Content Engine が、クラスタ内の他の Content Engine にクエリーを送信し、キャッシュ オブジェクトを取得できるようにするには、Content Engine GUI または CLI を使用して、スタンドアロン Content Engine のヒーリング モードをイネーブルに設定する必要があります。

Content Engine GUI を使用して、クラスタリング パラメータ(WCCP サービス クラスタの関連パラメータ)を設定するには、 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)

ヒーリング Content Engine(ヒーリング クライアント)がヒーリング サーバ(クラスタ内の他の Content Engine)に要求を送信するときに使用するポート番号を指定するには、 http cluster http-port グローバル コンフィギュレーション コマンドを使用します。デフォルトのポート番号は、ポート 80 です。ポート 80 以外のポートを設定する場合には、 http proxy incoming グローバル コンフィギュレーション コマンドを使用して、クラスタ内のヒーリング サーバに指定されているポート番号と一致していることを確認する必要があります。一致していない場合、ヒーリング クライアントはヒーリング サーバからオブジェクトを取得できません。

ヒーリング クライアントがヒーリング クエリーを送信するポート番号、およびヒーリング サーバがヒーリング応答を送信するポート番号を指定するには、 http cluster heal-port グローバル コンフィギュレーション コマンドを使用します。デフォルトのポート番号は 14333 です。デフォルト以外のポートを設定する場合には、クラスタ内のすべての Content Engine で同じポート番号を使用する必要があります。

最後のヒーリング モードのヒット応答後、ヒーリング プロセスをディセーブルにするまでに、ヒーリング Content Engine がクラスタから受信できる最大ミス数を指定するには、 http cluster misses グローバル コンフィギュレーション コマンドを使用します。デフォルト値は 0 ミスです。

WCCP バケットの分配後、Content Engine は、キャッシュ ミスが発生するごとに、他の Content Engine からキャッシュを移行しようとします。Content Engine がオブジェクトを取得する前に、ネイバからの応答を待機する最大秒数を設定できます。デフォルトは 0 秒です。ヒーリング要求をミスと判断する前に、ヒーリング Content Engine がクラスタからのヒーリング応答を待機する最大秒数を指定するには、 http cluster max-delay グローバル コンフィギュレーション コマンドを使用します。

ヒーリング クライアントをイネーブルにするには、少なくとも 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 の親と兄弟を、特定のドメイン セットに制限する例を示します。

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 クライアント機能を使用して要求されたオブジェクトをインターネットから取得する前に、Content Engine クラスタを設定して、ICP クエリーを生成できます。ICP では、親および兄弟の関係にある Content Engine を階層的に構成できます。Content Engine の階層では、ICP の親は、基本的に ICP の兄弟よりも 1 レベル上の階層にあります。

スタンドアロン Content Engine は、親または兄弟のどちらにも設定できます。

親の Content Engine は、キャッシュ ミス時にデータを取得できます。

兄弟の Content Engine はデータを取得できず、代わりに要求を親の Content Engine に転送します。

スタンドアロン Content Engine を ICP クライアントとして設定するには、Content Engine GUI または CLI を使用します。

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

Content Engine CLI から設定するには、 icp client グローバル コンフィギュレーション コマンドを使用し、スタンドアロン Content Engine を ICP クライアントとして設定します。ICP 機能をイネーブルにしないで行った設定は、除去されるまで設定内に保管されます。

表7-18 に、 icp client グローバル コンフィギュレーション コマンドのパラメータを示します。

 

表7-18 icp client コマンドの要約

コマンド
目的

icp client enable

Content Engine 上で ICP クライアントをイネーブルにします。

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 の 設定

スタンドアロン Content Engine は、ICP サーバとして動作するように設定することもできます。これにより、Content Engine は、階層内の ICP 親クライアントと兄弟クライアントに対して ICP メッセージをマルチキャスト転送し、Content Engine の階層を確認できます。

スタンドアロン Content Engine を ICP サーバとして設定するには、Content Engine GUI または CLI を使用します。

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

Content Engine 上で ICP サーバをイネーブルにします。

icp server http-port

ICP で生成された要求を待ち受ける、Content Engine 上の HTTP プロキシ ポートを設定します。範囲は 0 ~ 65535 です。デフォルトのポート番号は 3128 です。

icp server port

ICP 要求を待ち受ける、Content Engine 上の ICP サーバ ポートを設定します。範囲は 0 ~ 65535 です。デフォルトのポート番号は 3130 です。