Cisco ACNS キャッシング/ストリーミング コンフィギュレーション ガイド
プロキシ型キャッシング
プロキシ型キャッシング
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

プロキシ型キャッシング

プロキシ モードの動作

HTTP プロキシ キャッシング

HTTP 透過キャッシングおよびプロキシ キャッシング

SSL トンネリング

HTTPS 透過キャッシングおよびプロキシ キャッシング

HTTPS プロキシ機能

Content Engine のセキュリティ

HTTPS 統計レポート

HTTPS トランザクション ロギング

HTTPS TCP キープアライブ

透過 HTTPS キャッシングの概要

ブラウザの自動設定

FTP プロキシ キャッシング

FTP Over HTTP キャッシング

FTP およびキャッシング

FTP プロキシの設定例

プロキシ型キャッシング

この章では、非透過的なキャッシング、すなわちプロキシ型のキャッシングについて説明し、ACNS ソフトウェアがインストールされている Content Engine を使用するプロキシ型キャッシングの設定例を示します。

この章の構成は、次のとおりです。

「プロキシ モードの動作」

「HTTP プロキシ キャッシング」

「HTTP 透過キャッシングおよびプロキシ キャッシング」

「SSL トンネリング」

「HTTPS 透過キャッシングおよびプロキシ キャッシング」

「ブラウザの自動設定」

「FTP プロキシ キャッシング」

この章では、非透過モードで動作している Content Engine に関連する機能を説明します。 非透過モードでは、エンド ユーザの Web ブラウザで Cisco Content Engine の IP アドレスまたはホスト名を明示的に設定する必要があります。透過キャッシングのように、ユーザ要求を代行受信するためのレイヤ 4 スイッチや、WCCP 対応ルータなどの追加ハードウェアは必要ありません。多くのユーザは透過的なネットワーク キャッシングの配置に関心がありますが、一部のユーザは従来の非透過キャッシングを必要としています。 Content Engine で使用する透過キャッシングの設定の詳細は、「透過キャッシング」を参照してください。


) この章で使用される CLI コマンドの構文と使用方法については、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。


プロキシ モードの動作

図 5-1 では、プロキシ モードの Content Engine が次の順序でコンテンツをキャッシングする様子を示します。

1. ユーザ(Web クライアント)がブラウザから Web ページを要求します。

2. Content Engine に要求されたコンテンツがない(キャッシュ ミス)場合は、次のように動作します。

a. Content Engine がコンテンツを取得するためにリモートのオリジン Web サーバに接続します。

b. コンテンツが Content Engine に送られ、保存されます。

3. Content Engine がローカルに保存したコンテンツをユーザに送信します。

4. 以後、同じコンテンツに対して同じユーザまたは別のユーザから要求がある場合、Content Engine はその要求を透過的にローカル ストレージから処理します(キャッシュ ヒット)。

図 5-1 プロキシ モードの Content Engine を使用した Web キャッシング

 


) 非透過キャッシングでは、Web クライアントが明示的に Content Engine を指定する必要があります。 多数のクライアントをサポートする複数の Content Engine が導入されているときは、.pac ファイルを使用して、すべてのブラウザ クライアントを設定できます。 .pac ファイルを使用して組織内のすべてのブラウザを設定する方法については、「ブラウザの自動設定」を参照してください。


プロキシ型の要求は、Content Engine と同じ宛先 IP アドレスが付いて着信します。つまり、この要求はクライアントが明示的にその Content Engine に送信したものです。 Content Engine は、FTP、HTTPS、HTTP、MMS、および RTSP のプロキシ モードに対して、それぞれ 8 つまでの着信ポートをサポートします。着信プロキシ ポートは、透過モード サービスで使用されるものと同じポートにすることができます。着信プロキシ ポートは、Content Engine または Content Engine ファーム内の他の Content Engine 上で実行されている WCCP サービスを停止することなく変更できます。

プロキシ モードでは、Content Engine はそこに設定されているすべてのプロトコルに対応します。サポートされているプロトコルは、HTTP、HTTPS、FTP、MMS、および RTSP です。 Content Engine で受信したプロトコルのサポートが設定されていない場合、プロキシ サーバはエラーを戻します。たとえば、ポート 8080 で HTTP と HTTPS のプロキシ サービスを実行するように設定されている場合、このポートに着信した FTP 要求は拒否されます。

システム サービスまたはネットワーク サービス用に予約されている TCP ポートは、透過モードまたはプロキシ モードでのサービスのプロキシ処理(たとえば、DNS や FTP)には使用しないでください。1 つのプロトコルに 9 つ以上のポートが必要な場合、管理者は複数の動的 WCCP サービスを設定できます。他のプロキシ サーバのアドレスが指定された FTP、HTTP、および HTTPS 要求が代行受信されると(透過モードのポートで受信)、その要求は proxy-protocols transparent コマンド パラメータに従って処理されます。

HTTP プロキシ キャッシング

http proxy incoming ports オプションを使用して着信プロキシ ポートを設定すると、Content Engine は、プロキシ型要求を Web ブラウザから非透過モードで受け入れます。着信プロキシ ポートは、コマンドラインの 1 行または複数行で最高 8 つまで指定できます。

HTTP ミス トラフィックをすべて親キャッシュに(ICP も WCCP も使用せずに)送信するように Content Engine を設定するには、 http proxy outgoing host ip-address port primary オプションを使用します。ここで、 host は発信プロキシ サーバのシステム名または IP アドレスで、 port はプロキシ要求を受け入れるために発信(アップストリーム)サーバが指定したポート番号です。 primary オプションを使用して、このホストをプライマリ プロキシとして設定します。 http proxy outgoing コマンドの詳細は、「プライマリ プロキシ フェールオーバーの設定」 を参照してください。

HTTP 透過キャッシングおよびプロキシ キャッシング

本社にプロキシ モードの Content Engine を配置し、リモート ロケーションの営業所に透過モードの Content Engine を配置する場合があります。 このような場合、リモートの Content Engine でキャッシュ ミスが起きると、その要求を本社の Content Engine に転送するよう決められることがあります。

proxy-protocols transparent original-proxy コマンドが入力されたとき、プロキシ サーバである Content Engine への HTTP 要求が、リモート ロケーションにある透過モードの Content Engine によって代行受信され、そのときにキャッシュ ミスが起きると、Content Engine はその要求を目的のプロキシ サーバに転送します。 このコマンドが入力されていなかった場合、Content Engine はその要求を最初に HTTP 要求が行われたオリジン サーバに転送します。このコマンドの使用方法については、「プロキシ型要求の処理」 を参照してください。

SSL トンネリング

SSL トンネリング プロトコルでは、プロキシ サーバをエンド ユーザとオリジン サーバ間のトンネルとして動作させることができます。クライアントは、HTTP 要求を使用して SSL トンネルを要求します。 これにより、Content Engine は https:// url 形式の CONNECT メソッド要求を処理し、HTTP を介した SSL トンネリングが可能になります。


ヒント プロキシがブラウザで明示的に設定されている場合だけ、ブラウザは HTTPS-over-HTTP 要求を開始します。 プロキシが明示的に設定されていない場合、ブラウザは HTTP-over-SSL 接続を開始します。これは TCP ポート 443 上で行われるので、Content Engine による代行受信は行われません。 Content Engine がこの要求を代行受信した場合であっても、その要求には何の処理も行われません。ポート 443 上の SSL はエンドツーエンドの暗号化を使用するので、中間にある透過デバイスにはランダム バイトのストリーム以外は何も見えません。


HTTPS 透過キャッシングおよびプロキシ キャッシング

Cisco ACNS 5.1 ソフトウェアでは、次の場合に HTTPS をサポートしています。

透過モードの Content Engine が、Web クライアントから別の HTTPS プロキシ サーバに送信された要求を代行受信する。

Content Engine を HTTPS プロキシ サーバとして使用するように設定されている Web クライアントから送信された HTTPS 要求を Content Engine が受信する。

いずれの場合も、Content Engine は直接または別のプロキシ サーバを介してオリジン サーバとの接続を行い、Web クライアントとオリジン サーバが Content Engine を介して SSL トンネルをセットアップできるようにします。


) SSL トンネリングの詳細は、「SSL トンネリング」を参照してください。


HTTPS プロキシ機能

表 5-1 では、HTTPS プロキシ機能に関連した ACNS CLI コマンドを説明しています。この CLI コマンドの入力順序は重要ではありません。

 

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

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

最高 8 つの着信プロキシ ポートをサポートする。

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

同じポート上で WCCP サービスと HTTPS 着信プロキシを設定する。
プロキシ ポートを透過サービスと共有する。

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

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

no https destination-port allow 443 563
https destination-port deny all

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

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

デフォルトの発信 HTTPS プロキシを使用する(使用可能な場合)。

proxy-protocols transparent default-server

元の要求にある発信 HTTPS プロキシ サーバを使用する。

proxy-protocols transparent original-proxy

キャッシュ ミスの場合に着信 HTTPS 要求を送信クライアントに戻す。

proxy-protocols transparent reset

HTTPS プロキシ サーバである Content Engine は、最高 8 つのポートをサポートします。この Content Engine は、ポートを透過モード サービスおよび HTTP と共有できます。 プロキシ モードでは、Content Engine は https proxy incoming コマンドで指定されたポート上で HTTPS 要求を受け入れ、処理します。 他のプロキシ モードのポート上の HTTPS 要求はすべて、Content Engine のエラー処理設定に従って拒否されます。 透過モードでは、別の HTTPS プロキシ サーバに対する HTTPS プロキシ型の要求はすべて受け入れられます。 Content Engine は、透過的に受信したこれらの要求を proxy-protocols transparent コマンドに従って処理します。

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

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

宛先サーバがグローバル除外オプションで指定されている場合、宛先サーバに直接アクセスします。

宛先サーバがグローバル除外オプションで指定されず、要求が HTTP である場合、宛先サーバに直接アクセスします。

宛先サーバがグローバル除外オプションで指定されていない場合、発信プロキシ サーバにアクセスします。

Content Engine が別のプロキシ サーバに対するプロキシ要求を代行受信し、HTTPS 用に設定された発信プロキシがないときに、 proxy-protocols transparent default-server コマンドが実行される場合、Content Engine はその要求をクライアントが指定したプロキシ サーバではなく、宛先サーバに直接アドレス指定します。 ただし、Content Engine 上で proxy-protocols transparent reset コマンドが設定されているときにキャッシュ ミスが発生した場合は、クライアントが送信し透過的に代行受信された要求はすべてクライアントに戻され、要求されたオブジェクトは配信されません。

Content Engine のセキュリティ

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

no https destination-port allow 443 563

https destination-port deny all

これらのコマンドは、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 で設定されているときに、xxx ポートを使用して https://banking.wellsfargo.com にアクセスする要求がこの Content Engine にリダイレクトされる場合、xxx ポートへの接続は拒否されます。 この設定は、要求が Content Engine にリダイレクトされる透過的な配置、またはユーザが要求を直接 Content Engine に送る HTTPS プロキシ サーバ モードのいずれでも有効です。

HTTPS 統計レポート

接続統計だけを報告します。 要求と応答はセキュア トンネルを介して送信されるので、Content Engine は送信された要求の数や要求ごとのバイト数を特定できません。したがって HTTPS に対しては、要求と TPS(Transaction Per Second)の統計は入手できません。

HTTPS トランザクション ロギング

Content Engine は、Squid 構文に従って HTTPS トランザクションをトランザクション ログに記録します。1 つの HTTPS 接続に対して多数のトランザクションが実行されますが、ログ エントリは 1 つの接続ごとに 1 つ作成されます。 Content Engine は、SSL トンネルを介して伝送されたオブジェクトは認識せず、HTTPS サーバ名だけを認識します。

HTTPS TCP キープアライブ

キープアライブ メッセージが Content Engine からクライアントとエッジ Content Engine に送られていない場合、接続は切断されます。 ACNS ソフトウェア リリース 5.1では、ACNS システム管理者は、https tcp-rw-timeout グローバル設定コマンドを使用して、Content Engine で強制的にキープアライブ プローブを送ることができます。 HTTPS TCP キープアライブ機能が使用可能な場合、Content Engine は、TCP keepalive timeout、TCP keepalive probe count、TCP keepalive probe interval などのキープアライブ設定パラメータを使用して、TCP キープアライブをアイドル状態の HTTPS TCP 接続に送ります。

https tcp-rw-timeout timeout コマンドを使用すると、管理者は最大 3600 秒の読み取り・書き込みタイムアウトを設定でき、HTTPS キープアライブが指定された時間送信されます。 HTTPS 接続の場合、デフォルトのタイムアウト値は 5 分です。

透過 HTTPS キャッシングの概要

SSL を使用した透過 HTTPS キャッシングは、次のように機能します。

1. HTTPS サーバとして設定された Content Engine が、WCCP 対応ルータを介してリダイレクトされた HTTPS 要求を受信します。

2. Content Engine がオリジン サーバから取得した SSL 証明書を要求元の Web クライアントに送り、SSL 接続をネゴシエーションします。

3. Web クライアントがネゴシエーションされた SSL 接続内で HTTPS 要求を送信します。

4. Content Engine がその要求を検証し、キャッシュを確認した後、通常の HTTP 要求処理を実行します。

5. Content Engine がそのローカル ストレージから要求に応えられる場合は(キャッシュ ヒット)、SSL 接続を使用してその要求されたコンテンツを送り返します。

6. Content Engine がそのローカル ストレージから要求に応えられない場合は(キャッシュ ミス)、オリジン サーバとの接続を開始し、SSL 接続を介してその要求されたコンテンツを取得します。

7. Content Engine がその要求されたコンテンツをキャッシングし(可能な場合)、ネゴシエーションされた SSL 接続を介してコピーを要求元のクライアントにも送信します。


ヒント 特有のコンテンツが要求されキャッシングされる場合、ACNS システム管理者はこれらのサイトに適切な証明書およびキーを Content Engine にインポートし、これらのサイトのキャッシングを Content Engine に指示する必要があります。


表 5-2 では、透過 HTTPS キャッシングに関連した ACNS ソフトウェアの CLI コマンドを説明します。

表 5-2 透過 HTTPS キャッシングおよび関連する CLI コマンド

コマンド
説明

https server name

HTTPS サーバとキャッシング ソリューションを設定し、Content Engine をオリジン サーバとして稼働させます。 これにより、WAN トラフィックが減少し、データ セキュリティが向上します。これは、リモート営業所の権限をもつクライアントが、本社にある HTTPS サーバとして設定されている自身の Content Engine に HTTPS を使用してアクセスできるからです。

https server name cert

https server name key

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

https server name host

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

https server name protocol-version

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

https server name serverauth

HTTPS へのアクセスに認証を使用できます。 また、ACNS システム管理者は、無効な証明書、ドメイン名の不一致、証明書の有効期限エラー、未認識の CA(認証期間)などの認証エラーを無視する認証も設定できます。

HTTPS キャッシングの例

次の例では、Content Engine は HTTPS プロキシ サーバとして設定され、ポート 8081 上で HTTPS 要求を受け入れます。HTTPS プロトコルでは 1 つのポートだけがサポートされます。

ContentEngine(config)# https proxy incoming 8081
 

次の例では、Content Engine はポート 8880 で HTTPS 要求を発信プロキシ サーバ(10.1.1.1)に転送するように設定されます。

ContentEngine(config)# https proxy outgoing host 10.1.1.1 8880
 

次の例では、ドメイン名以外が発信プロキシ サーバに転送されます。

ContentEngine(config)# proxy-protocols outgoing-proxy exclude cruzio.com
ContentEngine(config)# proxy-protocols transparent default-server
 

次の例では、 show https all コマンドを使用して、ローカルの Content Engine に存在する HTTPS 関連の情報をすべて表示します。

ContentEngine# show https all
Incoming HTTPS proxy:
Incoming Proxy-Mode:
Not servicing incoming proxy mode connections.
Outgoing HTTPS proxy:
Not using outgoing proxy mode.
Destination port restrictions:
Allow 443 563
HTTPS caching certificate information:
HTTPS caching certificate group information:
HTTPS caching private key information:
Display all https server caching information:
ContentEngine#

ブラウザの自動設定

ACNS 5.x ソフトウェアでは、プロキシ自動設定ファイル( .pac ファイル)をサポートします。 ブラウザの自動設定 URL フィールドに Content Engine の IP アドレス、着信ポート番号、ファイル ディレクトリ、および .pac ファイル名を設定すると、プロキシ IP アドレスとポートの設定情報がプロキシ自動設定ファイルから取得されます。

proxy-auto-config download EXEC コマンドは、FTP サーバから Content Engine の現在の作業ディレクトリに、自動設定ファイルをダウンロードします。プロキシ自動設定ファイル機能を使用可能にするには、 proxy-auto-config enable グローバル設定コマンドを入力します。 新しい自動設定ファイルを Content Engineにダウンロードするたびに、 no proxy-auto-config enable および proxy-auto-config enable コマンドを入力してください。


) 自動設定ファイルをディスク /local1 または /local2 にダウンロードする前に、これら 2 つのディスク ロケーションを sysfs ボリュームとして設定する必要があります。


自動設定機能は、Microsoft Internet Explorer と Netscape のブラウザでサポートされています。ブラウザのプロキシ自動設定は、手作業で設定する必要があります。

次の例では、FTP サーバから Content Engine に自動設定ファイルをダウンロードする方法を示しています。

ContentEngine# proxy-auto-config download 172.16.10.10 remotedirname theproxyfile.pac
 

次の例では、Content Engine 上でブラウザの自動設定をイネーブルにします。

ContentEngine(config)# proxy-auto-config enable
 

次の例では、ブラウザのプロキシ自動設定の URL フィールドに入力する URL 構文を示しています。

http://ContentEngine-IPaddress:portnumber/theproxyfile.pac


ヒント http proxy incoming portnumber グローバル設定コマンドで指定されるポート番号を使用して、プロキシ着信ポートを設定します。 たとえば、ポート 8080 を http proxy incoming 8080 コマンドで指定する場合は、このヒントの上にある URL のポート番号に 8080 を使用してください。


FTP プロキシ キャッシング

ACNS 5.1 ソフトウェア リリースでは、Content Engine は次のタイプの FTP キャッシングをサポートしています。

FTP over HTTP

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

FTP Over HTTP キャッシング

Content Engine における FTP プロキシ キャッシングとは、FTP over HTTP 要求を処理する機能を指します。Web ブラウザとキャッシュ間の伝送は HTTP を介して行われ、キャッシュはオリジン FTP サーバへの FTP 転送を開始します。


ヒント Content Engine が FTP トラフィックをキャッシングするのは、クライアントが FTP 要求のプロキシ サーバとして Content Engine を使用する場合だけです。 Web クライアントから FTP サーバに直接送信された FTP トラフィックが、透過的に Content Engine によって代行受信された場合、それらのトラフィックはすべて非 HTTP トラフィックとして処理されます。 Web ブラウザのプロキシが明示的に設定されていない場合、ブラウザはエンドツーエンドの FTP 接続を開始し、Content Engine による代行受信は行われません。


ftp proxy コマンドを使用すると、WCCP が使用可能ではない環境、またはクライアント ブラウザが従来の FTP プロキシ サーバを使用するように設定されている環境で、Content Engine が稼働できるようになります。

ftp proxy incoming port オプションは、プロキシ サーバが要求の受信に使用するポート番号を指定します。この番号は、1 ~ 65535 にすることができます。最大 8 つの着信プロキシ ポートを設定できます。 これらの着信プロキシ ポートを、透過モード サービスと共有したり、Content Engine がサポートしているその他のプロキシ モード プロトコル(HTTP や HTTPS など)とも共有できます。 ftp proxy incoming port オプションは、デフォルトで使用不可になっています。


) Content Engine は、FTP プロキシ用に設定されたポート上だけで FTP 要求を受け入れ、処理します。 他のプロキシ モードのポート上の FTP 要求はすべて、Content Engine のエラー処理設定に従って拒否されます。


URL が FTP プロトコルを指定している場合(たとえば、GET ftp://ftp.cisco.com/pub/cao/READM )、Content Engine は FTP 要求を受け入れます。これらの要求では、クライアントは Content Engine とのトランスポート プロトコルとして HTTP を使用します。一方、Content Engine は FTP サーバとのトランスポート プロトコルとして FTP を使用します。

Content Engine は、FTP ファイル オブジェクト、およびディレクトリ リストの両方をキャッシュ ファイル システム(cfs)にキャッシングします。Content Engine は、FTP サーバからの通常のディレクトリ リストを HTML に変換します。これには、クライアント ユーザがクリックしてファイルをダウンロードできるリンクが付いています。

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

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

Content Engine は、サーバ名、ドメイン名、サーバの IP アドレスとポート、クライアントの IP アドレス、および URL に基づいて、FTP 要求に Rules Template を適用できます。

Content Engine は、Squid 構文に従って FTP トランザクションをトランザクション ログに記録します。

FTP およびキャッシング

ACNS ソフトウェア リリース 5.0 は、URL で FTP プロトコルが指定されている場合に(たとえば、 ftp://ftp.mycompany.com/ftpdir/ftp_file )、プロキシ モードの HTTP 要求を使用した FTP URL クライアント要求のプロキシ処理とキャッシングをサポートします。これらの要求では、クライアントは、Content Engine とのトランスポート プロトコルとして HTTP を使用します。一方、Content Engine は、FTP サーバとのトランスポート プロトコルとして FTP を使用します。

FTP over HTTP では、エンドユーザは、リモート FTP サーバのファイルへのアクセス(ファイルの送受信)に Web ブラウザを使用できます。 次の例では、エンドユーザが FTP サーバの一般的なファイルにアクセスできる FTP over HTTP 要求を示します。

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

ACNS ソフトウェア リリース 5.1 では、HTTP を使用して送信された要求だけでなく、ネイティブ FTP プロトコルで送信されたクライアントの FTP 要求もサポートします。 一般的に FTP はアプリケーション ソフトウェアでの配信に使用されるので、ネイティブ FTP を使用すると FTP プロキシ プロトコル要求が強化され、これらの要求にキャッシング サービスが提供されます。

FTP プロキシでは、ファイルとディレクトリのフェッチにパッシブ モードとアクティブ モードをサポートします。 デフォルトの FTP モードは、パッシブ モードです。 パッシブ モードが FTP サーバでサポートされていない場合、Content Engine は自動的にアクティブ モードに切り替えます。 ftp proxy active-mode enable コマンドが設定されている場合は、FTP はまずアクティブ モードでファイルをフェッチします。 アクティブ モードが失敗すると、FTP はパッシブ モードで再びそのファイルをフェッチします。

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

Content Engine が FTP トラフィックをキャッシングするのは、クライアントが FTP 要求のプロキシ サーバとして Content Engine を使用する場合だけです。 Web クライアントから FTP サーバに直接送信された FTP トラフィックが、透過的に Content Engine によって代行受信された場合、それらのトラフィックはすべて非 HTTP トラフィックとして処理されます。

FTP プロキシは、最高 8 つの着信ポートをサポートします。 これらの着信プロキシ ポートを、透過モード サービスと共有したり、Content Engine がサポートしているその他のプロキシ モードのプロトコル(たとえば、HTTP や HTTPS)とも共有できます。 プロキシ モードでは、Content Engine は FTP プロキシが設定されているポート上でのみ FTP 要求を受け入れ、処理します。 他のプロキシ モードのポート上の FTP 要求はすべて、Content Engine のエラー処理設定に従って拒否されます。

Content Engine は、サーバ名、ドメイン名、サーバの IP アドレスとポート、クライアントの IP アドレス、および URL に基づいて、FTP 要求に Rules Template を適用できます。

Content Engine は、Squid 構文に従って、FTP トランザクションをトランザクション ログに記録します。 URL トラッキングが使用可能な場合、Content Engine は FTP トランザクション情報を syslog に記録します。 syslog のエントリの先頭には、<ftp> が付いています。

FTP プロキシの設定例

ここでは、CLI を使用して Content Engine を FTP プロキシとして設定する方法を例を挙げて説明します。

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

ContentEngine(config)# ftp proxy incoming 8080 8081 9090
 

次の例では、前例で入力されたリストから、FTP プロキシ ポートを 1 つ削除します。ポート 8080 と 9090 は、引き続き FTP プロキシ ポートのままです。

ContentEngine(config)# no ftp proxy incoming 8081
 

次の例では、すべての FTP プロキシ ポートを使用不可にします。

ContentEngine(config)# no ftp proxy incoming
 

次の例では、ポート 8888 上に IP アドレス 172.16.76.76 のアップストリーム FTP プロキシを設定します。

ContentEngine(config)# ftp proxy outgoing host 172.16.76.76 8888
 

次の例では、FTP サーバと交信するときに Content Engine が使用する匿名のパスワードを指定します。 デフォルトのパスワードは anonymous@hostname です。

ContentEngine(config)# ftp proxy anonymous-pswd newstring@hostname
 

次の例では、Content Engine がキャッシュに保存する FTP オブジェクトの最大サイズ(キロバイト数)を設定します。デフォルトでは、キャッシュに保存できるオブジェクトの最大サイズには制限がありません。

ContentEngine(config)# ftp object max-size 15000
 

次の例では、すべての FTP 要求に対するオブジェクトを Content Engine に再検証させます。

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

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

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

次の例では、Content Engine でネイティブ 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: jdoe): jdoe
331 Password required for jdoe.
Password:
230 User jdoelogged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> pwd
257 "/home/jdoe" 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#
 
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:jdoe):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> get
(remote-file) /tmp/test.c
(local-file) test.c
local: test.c remote: /tmp/test.c
227 Entering Passive Mode (128,107,193,244,96,191)
550 /tmp/test.c: No such file or directory.
ftp>
ContentEngine#
 

) Content Engine の FTP プロキシ キャッシングを設定する方法の詳細については、「FTP 接続の設定」を参照してください。