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

目次

キャッシング サービスの設定

Content Engine プロキシ キャッシングの概要

ネットワーク プロトコルとキャッシング

HTTP の設定

HTTP 接続の設定

HTTP キャッシュの設定

HTTP キャッシュ フレッシュネスの設定

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

再認証間隔の指定

拡張 HTTP キャッシュの設定

Content Engine へのその他の HTTP 要求方式の追加または変更

HTTP Cache Vary User Agent の設定

HTTP 宛先ポート制限の設定

HTTPS の設定

HTTPS 証明書の設定

Content Engine の HTTPS 証明書のフィルタリング

HTTPS 証明書グループの設定

Content Engine の HTTPS 証明書グループのフィルタリング

HTTPS キーの設定

Content Engine の HTTPS キーのフィルタリング

HTTPS プロキシの設定

HTTPS サーバの設定

Content Engine の HTTPS サーバのフィルタリング

SSL を使用した透過 HTTPS キャッシング

HTTP と HTTPS 発信プロキシの除外の設定

FTP の設定

FTP-over-HTTP キャッシング

FTP-over-HTTP 接続の設定

FTP-over-HTTP キャッシュ フレッシュネスの設定

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

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

ネイティブ FTP 接続の設定

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

ネイティブ FTP キャッシュのフレッシュネス設定

Inetd FTP サービスのイネーブル化

ネイティブ FTP カスタム メッセージの設定

FTP カスタム初期メッセージの記述の概要

FTP メッセージのダウンロードの設定

Content Engine の FTP メッセージ設定の表示

ネイティブ FTP カスタム メッセージのリセット

ネイティブ FTP カスタム メッセージのアップロード設定

TFTP の設定

TFTP の一般設定

TFTP プロキシ サーバの設定

TFTP ディレクトリの設定

WCCP 透過キャッシングでの DNS キャッシング ネーム サービスの設定

Content Engine の DNS キャッシング サーバの設定

Content Engine の DNS キャッシュにキャッシュ可能なリソース レコード

Content Engine の DNS サーバ バインディングの設定

Content Engine の DNS アドレス レコードのマッピングの設定

Content Engine の DNS 正規名レコードのマッピング設定

HTTP プロキシ キャッシングの DNS サーバの設定

ICP の設定

ICP クライアントの設定

ICP リモート クライアントの設定

ICP サーバの設定

ICP リモート サーバの設定

キャッシング サービスの設定

この章では、中央管理 Content Engine に関する従来のキャッシング サービス(HTTP、FTP[ファイル転送プロトコル][FTP-over-HTTP キャッシングおよびネイティブ FTP キャッシング]、Hypertext Protocol Secure [HTTPS]、DNS キャッシング)の設定方法について説明します。また、Content Engine およびデバイス グループの Trivial File Transfer Protocol(TFTP; 簡易ファイル転送プロトコル)ゲートウェイ、および Internet Cache Protocol(ICP)の設定方法についても説明します。この章の内容は、次のとおりです。

「Content Engine プロキシ キャッシングの概要」

「HTTP の設定」

「HTTPS の設定」

「HTTP と HTTPS 発信プロキシの除外の設定」

「FTP の設定」

「TFTP の設定」

「WCCP 透過キャッシングでの DNS キャッシング ネーム サービスの設定」

「HTTP プロキシ キャッシングの DNS サーバの設定」

「ICP の設定」

Content Engine プロキシ キャッシングの概要

キャッシングは、あとで取り込むために Web オブジェクトを保存しておく機能です。キャッシング サービスは、一般に使用されているルーティング方式(直接プロキシ ルーティングまたは透過リダイレクション)に関連付けられています。

直接プロキシ ルーティングに関連付けられているキャッシング サービスは、非透過モードで実装されていると表現されます。非透過モード キャッシングは、 非透過フォワード プロキシ キャッシング と表現されます。ACNS ネットワーク内での非透過モードのプロキシ キャッシングは、フォワード プロキシ サーバとして動作する Content Engine によって処理されます。直接プロキシ ルーティングを使用して、コンテンツ要求を Content Engine にルーティングする構成では、Content Engine はネットワーク ゲートウェイ デバイスとして動作し、Web クライアントの代理としてコンテンツを取得します。

透過リダイレクション ルーティングに関連付けられているキャッシング サービスは、 透過モード で実装されていると表現されます。ACNS ネットワーク内での透過モードのプロキシ キャッシングは、WCCP 対応ルータまたはレイヤ 4 スイッチと連携した WCCP キャッシング サービス用に設定された Content Engine によって処理されます。透過モード キャッシングは、ネットワーク内の Content Engine の配置に応じて、 透過フォワード プロキシ キャッシング または 透過リバース プロキシ キャッシング と表現されます。Content Engine は、Web クライアントに対して透過プロキシ サーバとして機能します。その場合、Content Engine は透過 フォワード プロキシ サーバとして動作しています。また、Content Engine は、Web サーバまたは Web サーバのグループのプロキシとして機能します(たとえば、本社にあるサーバ ファーム内の Web サーバ)。この場合、Content Engine は透過 リバース プロキシ サーバとして動作しています。

ネットワーク プロトコルとキャッシング

Web ブラウザ(Web クライアント)と Web サーバ間の相互通信は、既存の標準のアプリケーション層インターネット プロトコル(HTTP、HTTPS、FTPなど)を使用します。Content Engine では、Web コンテンツの受信、キャッシュ、送信を行うために、これらの標準プロトコルをサポートする必要があります。ACNS ソフトウェア製品の一部として、HTTP、FTP、TFTP、および HTTPS プロトコルに対するサポートが含まれています。


) 通常、コンテンツのストリーミングに使用するプロトコル(Microsoft Media Server [MMS] プロトコルおよび RealNetworks RTSP プロトコルなど)については、第 9 章「ストリーミング メディア サービスの設定」で説明します。


Content Engine は設定されているすべてのプロトコルを処理します。Content Engine が特定のプロトコルをサポートするように設定されていない場合、Content Engine はエラーを返します。たとえば、ポート 8080 が HTTP および HTTPS 用に設定されている場合、FTP 要求がこのポートに着信してもその要求は拒否されます。

Content Engine は、FTP、HTTPS、HTTP、MMS、および RTSP の非透過モードのキャッシング サービスに対して、それぞれ最大 8 つの着信ポートをサポートします。着信プロキシ ポートは、透過モード サービスで使用されているポートと共有することができます。対象となる Content Engine またはネットワーク内の他の Content Engine 上で実行されている WCCP サービスを停止しなくても、着信プロキシ ポートを変更できます。

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

HTTP の設定

Content Engine とデバイス グループの HTTP のパラメータを設定、変更、および表示するには、次の作業を実行します。

「HTTP 接続の設定」

「HTTP キャッシュの設定」

「HTTP キャッシュ フレッシュネスの設定」

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

「拡張 HTTP キャッシュの設定」

「Content Engine へのその他の HTTP 要求方式の追加または変更」

「HTTP Cache Vary User Agent の設定」

HTTP 接続の設定

HTTP 接続を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 設定する Content Engine の名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > HTTP Connections の順に選択します。HTTP Connection Settings for Content Engine ウィンドウが表示されます(図8-1 を参照)。 表8-1 で、このウィンドウ内のフィールドについて説明します。

図8-1 HTTP Connection Settings ウィンドウ

 

ステップ 4 ポート 80 以外のポートでも着信要求を受け入れるには、 Enable Incoming Proxy チェックボックスにチェックマークを付けます。

ステップ 5 List of Incoming Ports フィールドに、プロキシ サーバまたは Content Engine が要求を受信するために使用するポート番号を入力します。ポート番号の間にはスペースを入れます。

ステップ 6 発信プロキシ サーバまたは別の Content Engine で HTTP キャッシュ ミスの要求トラフィックを受信するには、 Enable Outgoing Proxy チェックボックスにチェックマークを付けます。

ステップ 7 インターネット プロキシ認証証明書をクライアントに要求する際に、ヘッダー 407 をクライアントに送信して HTTP 認証ヘッダー 407 を保存するには、 Preserve 407 headers チェックボックスにチェックマークを付けます。

透過モードで Content Engine に接続し、このチェックボックスにチェックマークを付けて 407 エラー コードを保存している場合は、ブラウザでは 407 エラー コードが認識されません。デフォルトでは、Content Engine はインターネット プロキシから送信された hop-to-hop 407(Proxy Authentication Required)エラー コードを削除します。

ステップ 8 すべての発信プロキシ サーバが故障している場合、ユーザ要求に指定されているオリジン サーバに要求を直接送信するには、 Use Origin Server チェックボックスにチェックマークを付けます。

ステップ 9 Outgoing Connection Timeout フィールドに、発信プロキシ サーバのプローブ時に使用するタイムアウト時間の値(マイクロ秒)を入力します。

ステップ 10 Outgoing Monitor Period フィールドに、発信プロキシ サーバを監視する間隔を秒単位で入力します。これは、発信プロキシ サーバへの照会を実行する時間です。発信プロキシ サーバの 1 台が使用不能になっている場合、ポーリング メカニズムによって、接続タイムアウト後に次のサーバへポーリングが実行されます。

ステップ 11 発信プロキシを設定します。

a. Outgoing Proxy という項目の下の Hostname フィールドに、発信プロキシ ホストのホスト名または IP アドレスを入力します。

最初に入力するホスト名または IP アドレスにより、その発信プロキシ サーバがプライマリ サーバに指定されます。HTTP プロキシのフェールオーバー機能用に、最大 8 つのバックアップ プロキシ サーバを設定できます。プライマリ プロキシ サーバが HTTP 接続要求に応答しない場合、プロキシ サーバのいずれかで要求を処理するまで、その要求はリスト内の次のプロキシ サーバへと順にリダイレクトされます。

b. Port フィールドに、直前のステップで指定した発信プロキシ ホスト名に対応するポート番号を入力します(Hostname フィールドに入力されたプライマリ サーバには、ポートが必要です)。

ステップ 12 プロキシ サーバ経由でコンテンツを受信するようにルート Content Engine が設定されている場合、オリジン サーバからコンテンツを取得する前に、ルート Content Engine 上で実行される取得機能についてプロキシ サーバの認証を受ける必要があります。取得機能の発信プロキシ認証を設定する手順は、次のとおりです。

a. Username フィールドに、認証を受けるユーザの名前を入力します。このユーザ名は、NTLM 認証と基本認証の両方に使用されます。

b. Password フィールドに、ユーザのパスワードを入力します。確認のために、Confirm Password フィールドに同じパスワードを再度入力します。入力したパスワードは、画面上では暗号化されます。

c. NTLM User Domain フィールドに、ユーザのアクセス権を認証するために使用される Windows NT LAN Manager(NTLM)サーバ ドメイン名を入力します。

d. 基本認証へのフォールバック用に NTLM ヘッダーの削除を許可しない場合は、 Disable basic authentication チェックボックスにチェックマークを付けます。

ACNS ソフトウェアは、複数のプロキシをサポートします。したがって、複数のプロキシに対してプロキシ認証情報を設定することもできます。

ステップ 13 この設定値を保存するには、 Submit をクリックします。

デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 

表8-1 HTTP Connection Settings

GUI パラメータ
機能
CLI コマンドまたはマニフェストのアトリビュート

Enable Incoming Proxy

ポート 80 以外のポートでも着信要求を受け入れるように Content Engine を設定します。

http proxy incoming

Space separated list of incoming HTTP ports

プロキシ サーバまたは Content Engine が要求を受信するために使用するポート番号。この番号の範囲は 1 ~ 65535 です。最大 8 つのポートを指定できます。

http proxy incoming ports

Enable Outgoing Proxy

HTTP キャッシュ ミス要求トラフィックを受信するように、発信プロキシ サーバ、または別の Content Engine を設定します(ICP または WCCP を使用しない)。

http proxy outgoing

Preserve 407 headers

407 HTTP 認証ヘッダーを保存します。これらのヘッダーは、クライアントがキャッシュ ミス トラフィックを要求する前に、プロキシ サーバに対してクライアント自身の認証を行う必要があることを示します。

http proxy outgoing preserve-407

Use Origin Server

イネーブルにすると、すべての発信プロキシ サーバが故障した場合に、オリジン サーバを使用して要求を処理します。ディセーブルにすると、すべての発信プロキシ サーバが故障した場合に、ユーザはエラー メッセージを受け取ります。

http proxy outgoing origin-server

Outgoing Connection Timeout

発信プロキシ サーバのプローブ時に使用するタイムアウト時間(マイクロ秒)。範囲は 200 ~ 5000000 です。デフォルト値は 300 マイクロ秒です。

http proxy outgoing connection-timeout microsecs

Outgoing Monitor Period

1 台の発信プロキシ サーバを監視する間隔(秒単位)を指定します。複数の発信プロキシ サーバが設定されている場合、これらは順次監視されます。デフォルト値は 200 秒です。

http proxy outgoing monitor seconds

Outgoing Proxy

Hostname

発信プロキシ サーバのホスト名または IP アドレスを使用して、複数の発信プロキシ サーバを設定します。

http proxy outgoing host { hostname | ipaddress }

Port

発信プロキシのホスト名に対応するポート番号

http proxy outgoing host { hostname | ipaddress } port 1-65535

Acquirer Outgoing Proxy Authentication


) これらの設定値は、マニフェスト ファイルでも指定できます(第 6 章「ACNS ネットワークのコンテンツ取得設定」 を参照)。


 

Username

認証されるユーザの名前を設定します。

マニフェスト ファイルのアトリビュート:

user

Password

ユーザ パスワードを設定します。

password

Confirm Password

ユーザ パスワードを確認します。

NTLM User Domain

ユーザ アクセスの認証に使用される NTLM サーバ ドメイン名を設定します。

ntlmUserDomain

Disable basic authentication

基本認証方式にフォールバックするために NTLM ヘッダーの削除を禁止します。

disableBasicAuth


) タスクバー内のアイコンを使用して実行できるほかの操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

HTTP キャッシュの設定

HTTP Cache Settings ウィンドウを使用すると、HTTP 要求のキャッシングに関するキャッシング パラメータを設定できます。

HTTP キャッシング パラメータを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 設定する Content Engine の名前の横にある Edit アイコンをクリックします。

ステップ 3 Applications > Web > HTTP > HTTP Caching の順に選択します。HTTP Caching for Content Engine ウィンドウが表示されます(図8-2 を参照)。 表8-2 で、このウィンドウ内のフィールドについて説明します。

図8-2 HTTP Caching for Content Engine ウィンドウ

 

ステップ 4 レイヤ 4 スイッチ(Cisco Content Services [CSS] スイッチなど)を使用したリダイレクトをイネーブルにするには、 L4 Switch Support チェックボックスにチェックマークを付けます。

ステップ 5 要求元 IP アドレスの削除をイネーブルにするには、 Anonymize Requests チェックボックスに
チェックマークを付けます。このオプションによって HTTP アノニマイザ機能が設定され、送信者の識別情報が匿名になります。

ステップ 6 クッキーを添付し、有効期限情報なしで提供されるオブジェクトのキャッシングをイネーブルにするには、 Cache Binaries with Cookies チェックボックスにチェックマークを付けます。これは、Set-cookie ヘッダーが添付されたバイナリ コンテンツに対する要求です。

ステップ 7 HTTP 要求に対する Nagle のアルゴリズムをディセーブルにするには、 Enable Fast Response チェックボックスにチェックマークを付けます。このオプションを使用する必要があるのは、クライアントからの多数の小サイズのバースト データに、即時かつタイムリーな応答が必要なサーバ アプリケーションがある場合だけです。Nagle のアルゴリズムをディセーブルにすると、データのバッファリングが無効になるため、パフォーマンスが低下します。

ステップ 8 Content Engine で Vary: User-Agent ヘッダーが付加された応答をキャッシュできるようにするには、 Enable Cache Vary User Agent チェックボックスにチェックマークを付けます。Cache Vary User Agent を設定するには、「HTTP Cache Vary User Agent の設定」 を参照してください。

ステップ 9 HTTP 要求内で要求されたコンテンツの長さを Content Engine で調べるようにするには、 Strict Length Checking チェックボックスにチェックマークを付けます。

ステップ 10 レイヤ 4 対応スイッチからのレイヤ 4 リダイレクト トラフィックに対して、Content Engine 上で IP スプーフィングをイネーブルにするには、 L4 Switch Spoof Support チェックボックスにチェックマークを付けます。

この機能をイネーブルにすると、Content Engine は自身からオリジン サーバに発信する要求について、クライアントの IP アドレスをソース IP アドレスとしてスプーフィングします。通常、Content Engine からオリジン サーバへの要求は、キャッシュ ミス時に実行されます。

ステップ 11 対象となる要求の HTTP 要求ヘッダーにホスト名が含まれており、それが Fully Qualified Domain Name(FQDN; 完全修飾ドメイン名)ではない場合に、Content Engine によって、要求ヘッダー内の元のホスト名が FQDN に書き換えられないようにするには、Do not modify request host header チェックボックスにチェックマークを付けます。 Do not modify request host header チェックボックスにチェックマークを付けます。

クライアント要求が、Content Engine によって代行受信される場合、Content Engine のデフォルト動作では、オリジン サーバの IP アドレスを DNS サーバに照会し、HTTP 要求転送時には、オリジン サーバの FQDN を使用します。オリジン サーバのホスト名が変更設定され、ホスト ヘッダー内に FQDN を使用していない場合、オリジン サーバは Content Engine の要求を処理できません。

Content Engine で要求ホスト ヘッダー内の FQDN を使用する場合、このチェックボックスのチェックマークは外したままにします。

ステップ 12 指定された最大サイズを超えるオブジェクトをキャッシュしない場合は、 Enforce Max Object Size チェックボックスにチェックマークを付けます。設定可能な上限サイズよりも大きいオブジェクトは、Content Engine に保存されなくなります。


) このチェックボックスのチェックマークを外すと、cfs(キャッシュ ファイル システム)のサイズの上限は、すべてのキャッシュ可能なオブジェクト対して 200 MB のままになります。


ステップ 13 Max Object Size フィールドに、最大オブジェクト サイズ(キロバイト)を指定します。

ステップ 14 オブジェクトを要求するたびに、Content Engine のキャッシュ内のオブジェクトを検証するようにするには、 URL Validation チェックボックスにチェックマークを付けます。

このオプションがイネーブルになっていると、キャッシュされたオブジェクトでホスト ヘッダーおよびサーバの IP アドレスの有効性に関してテストが行われます。ホスト ヘッダーおよびサーバの IP アドレスが有効の場合、コンテンツがキャッシュから配信されます。これらのパラメータの有効性テストに失敗した場合、オブジェクトはキャッシュから取得されず、キャッシュ ミスが発生します。

ステップ 15 no-cache 要求の管理方法を設定するには、 Client No Cache ドロップダウン リストからオプションを選択します。

Content Engine で no-cache 要求を無視する場合は、 ignore オプションを選択します。

no-cache クライアント要求を処理する前にその要求をオリジン サーバで再検証する場合は、 revalidate オプションを選択します。

このオプションを設定しない場合は、デフォルトの Do not set オプションを選択します。

ステップ 16 Range 要求(コンテンツ オブジェクトの一部のみの要求)を行い、対象となるオブジェクトがキャッシュになかった場合、HTTP 応答全体をキャッシュするには、 Enable Smart Range チェックボックスにチェックマークを付けます。このチェックボックスにチェックマークを付けると、Max Start フィールドと Max Interval フィールドが使用可能になります。

ステップ 17 Max Start フィールドに、キャッシュするオブジェクトに適用するクライアントの Range 要求内の最大開始オフセット値(バイト数)を指定します。範囲は 0~2147483647 です。デフォルトは 16384 です。

ステップ 18 Max Interval フィールドに、Range 要求内の連続した 2 つの範囲間すべてに適用される最大間隔(バイト数)を指定します。範囲は 0~2147483647 です。デフォルトは 16384 です。

Range 要求が両方の条件(オフセットおよび間隔)を満たし、キャッシュ ミスが発生した場合だけ、プロキシは通常の要求をオリジン サーバに発行し、その応答をキャッシュできる場合にはキャッシュし、Range 応答をクライアントに送信します。応答がキャッシュできない場合、応答全体がクライアントに送信されます。

ステップ 19 HTTP プロトコルを使用して大きなファイルを配信する場合に、セッションごとの最大ビット レートを制限するには、Default Bitrate フィールドにデフォルトのビット レートをkbps(キロビット/秒)で指定します。

ステップ 20 オリジン サーバの IP アドレスを特定するために、ホスト ヘッダーを常に解決するには、Always Resolve Host チェックボックスにチェックマークを付けます。

ステップ 21 この設定値を保存するには、 Submit をクリックします。

デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 

表8-2 HTTP キャッシュ設定

GUI パラメータ
機能
CLI コマンド

L4 Switch Support

Cisco Content Services(CSS)スイッチなどのレイヤ 4 スイッチを使用したリダイレクトをイネーブルにします。

http l4-switch enable

Anonymize Requests

要求側の IP アドレスの削除をイネーブルにします。このオプションは、HTTP アノニマイザ機能が設定され、送信者の識別情報が匿名になります。

http anonymizer enable

Cache Binaries with Cookies

クッキーを添付し、有効期限情報なしで提供されるオブジェクトのキャッシングをイネーブルにします。これら、Set-cookie ヘッダーが添付されたバイナリ コンテンツに対する要求です。

http cache-cookies

Enable Fast Response

HTTP 要求に対する Nagle のアルゴリズムを無効にします。このオプションを使用する必要があるのは、クライアントからの多数の小サイズのバースト データに、即時かつタイムリーな応答が必要なサーバ アプリケーションがある場合だけです。Nagle のアルゴリズムをディセーブルにすると、データのバッファリングが無効になるため、パフォーマンスが低下します。

http fast-response enable

Enable Cache Vary User Agent

Content Engine で Vary:User-Agentヘッダーが付加された応答をキャッシュできるようにするパラメータを設定します。

http cache-vary-user-agent enable

Strict Length Checking

Content Engine で、HTTP 要求内で要求されたコンテンツの長さを調べます。

http strict-request-content-length-checking enable

L4 Switch Spoof Support

レイヤ 4 対応スイッチからのレイヤ 4 リダイレクト トラフィックに対して、Content Engine 上で IP スプーフィングをイネーブルにします。

http l4-switch spoof-client-ip enable

Do not modify request host header

対象となる要求の HTTP 要求ヘッダーにホスト名が含まれており、それが FQDN ではない場合に、Content Engine によって元のホスト名が書き換えられないようにします。

http request-header host unmodified

Enforce Max Object Size

指定された最大サイズを超えるオブジェクトをキャッシュしません。


) このチェックボックスにチェックマークを付けると、cfs のサイズの上限は、すべてのキャッシュ可能なオブジェクト対して 200 MB のままになります。


 

http object max-size kbytes

Max Object size

最大オブジェクト サイズ(キロバイト数)

URL Validation

キャッシュ内のすべての要求されたオブジェクトを、オリジン サーバで再検証します。

http object url-validation enable

Client No Cache

no-cache 要求を管理する方法を設定します。

http client-no-cache-request { ignore | revalidate }

Enable Smart Range

Range 要求(コンテンツ オブジェクトの一部のみの要求)を行い、対象となるオブジェクトがキャッシュになかった場合、HTTP 応答全体をキャッシュします。

http smart-range enable

Max Start

キャッシュするオブジェクトに適用するクライアントの Range 要求内の最大開始オフセット値(バイト数)。範囲は 0~2147483647 です。デフォルトは 16384 です。

http smart-range max-start offset

Max Interval

Range 要求内の連続した 2 つの範囲間すべてに適用される最大間隔(バイト数)。範囲は 0~2147483647 です。デフォルトは 16384 です。

http smart-range max-start offset max-interval interval

Default Bitrate

大きな事前配信 HTTP ファイルに対する、最大ペーシング ビットレート(kbps 単位)。範囲は 0 ~ 2000000 です。デフォルトは 1500 kbpsです。

bitrate http default kbps

Always Resolve Host

オリジン サーバの IP アドレスを特定するために、ホスト ヘッダーを解決します。

http always-resolve-host


) タスクバー内のアイコンを使用して実行できるほかの操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

HTTP キャッシュ フレッシュネスの設定

Content Distribution Manager GUI の HTTP Cache Freshness Settings ウィンドウを使用すると、ACNS ネットワーク上の Content Engine に対して、HTTP キャッシュ オブジェクトのフレッシュネス パラメータを設定できます。これらのパラメータは、ディレクトリのリスト項目(ディレクトリの下にファイルとサブディレクトリがリスト表示される)またはキャッシュ内の特定のオブジェクトのいずれかについて設定できます。

HTTP フレッシュネス パラメータを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 設定する Content Engine の名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > HTTP Cache Freshness の順に選択します。HTTP Cache Freshness Settings ウィンドウが表示されます(図8-3 を参照)。 表8-4 で、このウィンドウ内のフィールドについて説明します。

図8-3 HTTP Cache Freshness Settings ウィンドウ

 

ステップ 4 HTTP キャッシュ フレッシュネス設定をイネーブルにするには、 Enable チェックボックスにチェックマークを付けます。このチェックボックスは、デフォルトでチェックマークが付いています。

ステップ 5 Text Object Age Multiplier フィールドの値を指定します。

この経過時間係数の値を指定すると、オブジェクトの前回の修正時点から経過した時間に特定のパーセント値を掛け、おおよその有効期限日を算出することで、Content Engine ではテキスト オブジェクトの存続時間を推定できます。この日付を過ぎるとオブジェクトは古いものとみなされ、以降に要求があったときには、Content Engine によって新たにオブジェクトが取得されます。有効な値は 0~100% です。デフォルト値は 30% です。

ステップ 6 Binary Object Age Multiplier フィールドの値を指定します。

この経過時間係数の値を指定すると、オブジェクトの前回の修正時点から経過した時間に特定のパーセント値を掛け、おおよその有効期限日を算出することで、Content Engine ではテキスト オブジェクトの存続時間を推定できます。この日付を過ぎるとオブジェクトは古いものとみなされ、以降に要求があったときには、Content Engine によって新たにオブジェクトが取得されます。有効な値は 0~100% です。デフォルト値は 60% です。

ステップ 7 Maximum Time-to-Live(TTL)Scale ドロップダウン リストから、単位時間( seconds hours minutes days )を選択します。

TTL では、推定有効期限日が上限値として設定されます。オブジェクトに有効期限日が明示的に指定されている場合は、その日付がここで設定した TTL よりも優先されます。

ステップ 8 Max Text Object TTL フィールドの値を指定します。 表8-3 に、TTL フィールドで有効な値を示します。

 

表8-3 HTTP フレッシュネスの TTL 値の範囲

単位時間
範囲

1 ~ 1825

1 ~ 43800

1 ~ 2628000

1 ~ 157680000

ステップ 9 Max Binary Object TTL フィールドの値を指定します。

使用する単位時間に応じた最大値については、 表8-3 を参照してください。

ステップ 10 Minimum TTL フィールドの値を指定します。

Minimum TTL は、キャッシュ内のオブジェクトの最小存続可能時間です。値の範囲は、0~86400 分です。デフォルト値は 30 分です。

ステップ 11 Re-evaluate Request ドロップダウン リストから、再評価要求の処理方法を選択します。

これらのパラメータをディレクトリのリスト項目(ディレクトリの下にファイルおよびサブディレクトリがリスト表示される)に適用するには、 text を選択します。

これらのパラメータをオブジェクトとディレクトリのリスト項目の両方に適用するには、 all を選択します。

TTL が適用されず、キャッシュ内のオブジェクトに有効期限日を設定しない場合には、 none を選択します。

ステップ 12 次の 2 つのステップでテキストと経過時間の修飾子(Age Modifier)を指定する場合は、 Enable If-Modified-Since チェックボックスにチェックマークを付けます。

ステップ 13 IMS Text Age Modifier (%) フィールドにパーセント値を指定します。この値は、再検証を行わずにテキスト オブジェクトを配信する経過時間のパーセント値です。

ステップ 14 IMS Binary Age Modifier (%) フィールドにパーセント値を指定します。この値は、再検証を行わずにバイナリ オブジェクトを配信する経過時間のパーセント値です。

ステップ 15 この設定値を保存するには、 Submit をクリックします。

デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 

表8-4 HTTP キャッシュ フレッシュネスの設定

GUI パラメータ
機能
CLI コマンド

Enable

HTTP キャッシュ フレッシュネスの設定をイネーブルにします。

--

Text Object Age Multiplier

オブジェクトの前回の修正時点から経過した時間に特定のパーセント値を掛け、おおよその有効期限日を算出することで、Content Engine ではテキスト オブジェクトの存続時間を推定できます。この日付を過ぎるとオブジェクトは古いものとみなされ、以降に要求があったときには、Content Engine によって新たにオブジェクトが取得されます。有効な値は 0~100% です。デフォルト値は 30% です。

http age-multiplier text num

Binary Object Age Multiplier

オブジェクトの前回の修正時点から経過した時間に特定のパーセント値を掛け、おおよその有効期限日を算出することで、Content Engine ではテキスト オブジェクトの存続時間を推定できます。この日付を過ぎるとオブジェクトは古いものとみなされ、以降に要求があったときには、Content Engine によって新たにオブジェクトが取得されます。有効な値は 0~100% です。デフォルト値は 60% です。

http age-multiplier text num binary num

Max TTL Scale

推定有効期限日を上限値として設定します。オブジェクトに有効期限日が明示的に指定されている場合は、その日付がここで設定した TTL よりも優先されます。

http max-ttl { days text textdays binary bindays | hours text texthours binary binhours | minutes text textminutes binary binminutes | seconds text textseconds binary binseconds }

Max Text Object TTL

値を指定します。

Max Binary Object TTL

値を指定します。

Minimum TTL

キャッシュ内のオブジェクトの最小存続可能時間。値の範囲は 0~86400 分です。デフォルト値は 30 分です。

http min-ttl minutes

Re-evaluate Request

再評価要求の処理方法を設定します。

http reval-each-request { all | none | text }

Enable If-Modified-Since(IMS)

IMS 修飾子をイネーブルにします。

http serve-ims

IMS Text Age Modifier

再検証を行わずにテキスト オブジェクトを配信する経過時間のパーセント値。

http serve-ims text percentage

IMS Binary Age Modifier

再検証を行わずにバイナリ オブジェクトを配信する経過時間のパーセント値。

http serve-ims text percentage binary percentage


) タスクバー内のアイコンを使用して実行できるほかの操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

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

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

認証済み HTTP キャッシング パラメータを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 設定する Content Engine の名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > Authenticated HTTP Caching の順に選択します。Authenticated HTTP Caching for Content Engine ウィンドウが表示されます(図8-4 を参照)。 表8-5 で、このウィンドウ内のフィールドについて説明します。

図8-4 Authenticated HTTP Caching for Content Engine ウィンドウ ― 上部

 

ステップ 4 Content Engine で認証済み HTTP キャッシュ設定の使用をイネーブルにするには、 Enable チェックボックスにチェックマークを付けます。

ステップ 5 Cache Authenticated Content ドロップダウン リストから、認証済みコンテンツをキャッシュするための認証方式を選択します。

任意の方式で認証された Web オブジェクトをキャッシュするには、 all を選択します。

基本認証または NTLM 認証済みの Web オブジェクトをキャッシュするには、ドロップダウン リストから basic または ntlm を選択します。

認証方式を削除するには、 Do Not Set を選択します。この選択項目は、 no http cache-authenticated basic コマンドと no http cache-authenticated ntlm コマンドに相当します。

ステップ 6 認証済みコンテンツから NTLM ヘッダーを削除するには、 Strip NTLM Headers チェックボックスにチェックマークを付けます。

チェックマークを付けると、Content Engine からクライアント ブラウザに送信される認証済みのコンテンツから NTLM ヘッダーが削除されます。この機能により、ブラウザは基本認証方式にフォールバックします。ブラウザでは、Microsoft IIS(Internet Information Service)サーバによって実行される基本スタイルの認証確認に照らして認証が行われます。

チェックマークが外されていると、応答内の NTLM ヘッダーは保持され、ブラウザは NTLM チャレンジによる認証を受けることになります。

ステップ 7 Content Engine の認証キャッシュに保存する最大エントリ数をイネーブルにするには、 Max Cache Authentication Entries チェックボックスにチェックマークを付けます。

ステップ 8 Max Cached Authenticated Entries フィールドに、キャッシュ内で保存されるエントリの最大数を入力します。デフォルト値は 32000 エントリです。

ステップ 9 Content Engine の認証グループ キャッシュに保存する最大エントリ数をイネーブルにするには、 Set Max Group Cached Authenticated Entries チェックボックスにチェックマークを付けます。

ステップ 10 Max Group Cached Authenticated Entries フィールドで、Content Engine の認証グループ キャッシュに保存する最大エントリ数を指定します。範囲は 500~12000 です。この最大値は、Content Engine の物理的なリソースにより異なります。

ステップ 11 Time Authenticated Entries are cached フィールドに、エントリへの最後のアクセスした以降、Content Engine のキャッシュからエントリを削除するまでの時間を分単位で入力します。範囲は 1 ~ 1440 分で、デフォルト値は 480 分です。

認証レコードのエントリは、指定の期間、キャッシュに保存されます。この期間の経過後、制限されたコンテンツへの以後のアクセスには、NTLM、RADIUS、または LDAP サーバを使用した再認証が必要です(再認証間隔の指定を参照)。

ステップ 12 認証キャッシュ内のエントリに対する絶対タイムアウトをイネーブルにして、ユーザが以前に認証されたブラウザを使用してアクセスを許可されることを減らすには、 Set Authentication Cache TTL チェックボックスにチェックマークを付けます。デフォルトでは、このチェックボックスにはチェックマークが付いていません。これは TTL タイムアウトが有効でないことを示しています。この場合、TTL 値から算出された作成時間に基づいて、認証キャッシュ エントリのタイムアウトがチェックされることはありません。

ステップ 13 Authentication Cache TTL(max valid time)フィールドで、認証キャッシュ エントリが作成後に有効とみなされる最大時間の絶対値を指定します。TTL タイムアウトは分単位で指定します。最小時間は 1 分、最大は 1440分(24 時間)です。

絶対 TTL 期間が経過すると、クライアント ブラウザでは再認証が必要となり、有効な証明書を入力する必要があります。絶対 TTL タイムアウトの設定機能によって、Content Engine から配信されるコンテンツの無活動タイムアウトに対するセキュリティが向上します。

Time Authenticated Entries are cached フィールド内のタイムアウト値は、絶対 TTL の影響を受けることはありません。2 つのタイムアウト値は互いに依存しません。Time Authenticated Entries are cached タイムアウト値と絶対 TTL タイムアウト値の両方が Content Engine 上に設定されている場合、認証キャッシュ エントリのタイムアウトは、そのエントリでどちらのタイムアウトが最初に発生するかによって異なります。

ステップ 14 ヘッダー内の認証メッセージを送信するには、 Re-Authenticate Header type ドロップダウン リストから 401 (Unauthorized)または 407 (Proxy Authentication Required)ヘッダー タイプのメッセージを選択します。メッセージを送信しない場合は、 Do not set を選択します(図8-5 を参照)。 表8-5 で、このウィンドウ内のフィールドについて説明します。

これらの認証ヘッダーは、認証キャッシュ内でエントリが見付からず、サーバの検索が必要な場合に、ユーザに証明書の照会を行うために使用されます。

図8-5 Authenticated HTTP Caching for Content Engine ウィンドウ ― 下部

 

ステップ 15 HTTP 認証レルム ストリングを変更するには、Basic Realm String フィールドに目的のストリングを入力します。

Cisco ACNS ソフトウェアを使用すると、Content Engine に接続したときに認証ポップアップ ウィンドウに表示されるレルムを設定できます。デフォルトのレルムは「Cisco Content Engine」です。この設定を使うことでレルムを再設定し、デバイスの性質を反映させることができます。

ステップ 16 ダウンストリームの Content Engine で HTTP ヘッダーをアペンドする場合は、 Append Headers チェックボックスにチェックマークを付けます。以降で説明するフィールドは、 Append Headers チェックボックスにチェックマークを付けた場合のみ使用します。

ステップ 17 Proxy Header Server フィールドに、プロキシ認証ヘッダーを受信するように設定されているサーバのホスト名または IP アドレスを入力します。

この設定が有効な場合、Content Engine はプロキシ認証ヘッダーを受信するように設定されているアップストリームの Content Engine プロキシまたはサーバに要求を送信するときに、要求にプロキシ認証ヘッダーをアペンドします。

プロキシ認証ヘッダーはホップバイホップ ヘッダーであるため、デフォルト動作ではアップストリームのプロキシまたはサーバに対するプロキシ認証ヘッダーはアペンドされません。この設定を有効にすると、このタイプのヘッダーを受信できるように設定されている特定のサーバにプロキシ認証ヘッダーを送信できます。

ステップ 18 「Via」ヘッダーが応答と返信内に含まれるようにするには、 Use Via Headers チェックボックスにチェックマークを付けます。

ステップ 19 Via ヘッダー内にカスタム ストリングを追加する場合は、Use Custom String Via Headers フィールドに 99 文字以内で入力します。

ステップ 20 WWW Authentication Server フィールドに、WWW 認証ヘッダーを受信するように設定されているサーバのホスト名または IP アドレスを入力します。

次に、条件のセットの例を示します。

WCCP が Content Engine に対してイネーブルになっている。

プロキシ認証(RADIUS、LDAP、TACAS、NTLM のいずれか)が Content Engine に対してイネーブルになっている。

WWW Authentication Server フィールドにホスト名として base2 を設定した。

クライアントが http://base2/ に要求を送信すると、Content Engine ではその要求を認証します。要求を base2 サーバに送信すると同時に、Content Engine はクライアントから受信した WWW 認証ヘッダーも送信します( base2 サーバは、WWW 認証ヘッダーを受信するように設定されています)。クライアントからの要求が base2 以外のサーバに対するものである場合、Content Engine は要求を認証し、クライアントから受信した WWW 認証ヘッダーは含めずに要求をサーバに送信します。

この設定は、プロキシ認証ヘッダーのアペンドの設定(Proxy Header Server フィールドで設定される)と同じです。

ステップ 21 X-Forwarded-For ヘッダーを使用してクライアントの IP アドレスを Web サーバに通知するには、 Use X-FWD-Headers チェックボックスにチェックマークを付けます。

ステップ 22 X-Forwarded-For ヘッダーで複数の IP アドレスのアペンド機能をイネーブルにするには、 Use X-FWD-Headers with Multiple IP Address チェックボックスにチェックマークを付けます。

このコマンドを指定し、さらに X-Forward-For ヘッダー がすでに存在する場合、Content Engine の IP アドレスが、ヘッダー内にある既存のクライアント IP アドレスにカンマ区切りでアペンドされます。

ステップ 23 ホスト ヘッダーをもたない HTTP/1.0 要求にこのヘッダーをアペンドするには、 Use Host Header チェックボックスにチェックマークを付けます。

ステップ 24 この設定値を保存するには、 Submit をクリックします。

デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 

表8-5 Authenticated HTTP キャッシュ設定

GUI パラメータ
機能
CLI コマンド

Enable

Content Engine の認証済み HTTP キャッシュの GUI 設定をイネーブルにします。

--

Cache Authenticated Content

認証済みコンテンツをキャッシュするための認証方式(all、basic、ntlm、Do Not Set)

[ no ] http cache-authenticated { all | basic | ntlm }

Strip NTLM Headers

認証済みコンテンツから NTLM ヘッダーを削除します。

http authenticate-strip-ntlm

Set Max Cached Authenticated Entries

Content Engine で、認証キャッシュに保存する最大エントリ数をイネーブルにします。

--

Max Cached Authenticated Entries

キャッシュに保存される最大エントリ数。デフォルト値は 32000 エントリです。

http authentication cache max-entries entries

Set Max Group Cached Authenticated Entries

Content Engine で、認証グループ キャッシュに保存する最大エントリ数をイネーブルにします。

--

Max Group Cached Authenticated Entries

Content Engine の認証グループ キャッシュに保存する最大エントリ数。範囲は 500~12000 です。この値は Content Engine の物理的なリソースにより異なります。

http authentication cache max-group-entries entries

Time Authenticated Entries are cached

エントリへの最後のアクセス以降、Content Engine のキャッシュからエントリを削除するまでの時間(分単位)。範囲は 1~1440 です。デフォルトは 480 分です。

http authentication cache timeout minutes

Set Authentication Cache TTL

Content Engine で、認証キャッシュ内のエントリに対する絶対タイムアウトをイネーブルにします。

--

Authentication Cache TTL(max valid time)

認証キャッシュ エントリの作成後、有効であるとみなされる最大時間。TTL タイムアウトは分単位で指定します。最小時間は 1 分、最大は 1440分(24 時間)です。

http authentication cache ttl minutes

Re-Authenticate Header type

ヘッダー内の認証メッセージを送信します。

http authentication header { 401 | 407 }

Append Response Headers

ダウンストリームの Content Engine で HTTP ヘッダーをアペンドします。

--

Proxy Header Server

プロキシ認証ヘッダーを受信するように設定されているサーバのホスト名または IP アドレス。

http append proxy-auth-header { ipaddress | hostname }

Use Via Headers

「Via」ヘッダーを応答と返信に追加します。

http append via-header

Use Custom String Via Headers

Via ヘッダー内にカスタム ストリングを追加します。

http append via-header custom string

WWW Authentication Server

WWW 認証ヘッダーを受信するように設定されているサーバのホスト名または IP アドレス。

http append www-auth-header { hostname | ipaddress }

Use X-FWD-Headers

X-Forwarded-For ヘッダーを使用してクライアントの IP アドレスを Web サーバに通知します。

http append x-forwarded-for-header

Use X-FWD-Headers with Multiple IP Address

X-Forward-For ヘッダーに複数の IP アドレスをアペンドします。

http append x-forwarded-for-header multiple-ip-address

Use Host Header

ホスト ヘッダーを HTTP/1.0 要求にアペンドします。

http append host-header


) タスクバー内のアイコンを使用して実行できるほかの操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

再認証間隔の指定

ACNS 5.1 ソフトウェアでは、初回の認証後、クライアントのブラウザに認証証明書を再入力するよう促すタイミングを決めるために、非アクティビティ タイマーを使用していました。この非アクティビティ タイマーは、HTTP 認証キャッシュ タイムアウト グローバル コンフィギュレーション コマンドで設定します。デフォルトでは、非アクティビティ タイムアウト期限は 8 時間でした。つまり、正規の認証を受けたユーザによって 1 度認証に成功すれば、使用者に関係なく同じクライアント ブラウザを使用し続けるかぎり、クライアントでユーザの認証証明書を再入力する必要はありませんでした。

ワークステーションの共有環境でのセキュリティを高めるため、ACNS 5.2.1 以降のソフトウェア リリースでは HTTP 認証キャッシュ エントリの絶対 TTL 値を指定できます。絶対 TTL タイムアウトの設定機能によって、Content Engine から配信されるコンテンツの無活動タイムアウトに対するセキュリティが向上します。絶対 TTL 期間が経過すると、クライアント ブラウザでは再認証が必要となり、有効な証明書を入力する必要があります。

いずれかの認証方式と WCCP 対応ルータのリダイレクション モード、またはプロキシのリダイレクション モードと NTLM 認証方式を使用しているワークステーションの共有環境では、セキュリティの脆弱性が存在します。このような環境の場合、Content Engine は、認証キャッシュに保存されている認証レコードのインデックスとして、クライアントの IP アドレスを使用します。そのため、同じワークステーションを使用する別のユーザが事前に有効なクレデンシャルを提示し、それが認証キャッシュ内にキャッシュされている場合、Content Engine では、自分自身の有効なクレデンシャルを提示していないユーザが認証されます。こうした環境でセキュリティを強化するには、HTTP 認証キャッシュ エントリの絶対 TTL 値を設定します。この値は、キャッシングされた認証キャッシュの絶対的な有効期限です。あるエントリに関してキャッシュ検索が実行され、設定した TTL 時間を超過している場合、そのエントリは削除されて、Content Engine によるユーザのクレデンシャルの照会が行われます。

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

拡張 HTTP キャッシュの設定

拡張 HTTP キャッシュを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 設定する Content Engine の名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > Advanced HTTP Caching の順に選択します。Advanced HTTP Caching for Content Engine ウィンドウが表示されます(図8-6 および図8-7 を参照)。 表8-6 で、このウィンドウ内のフィールドについて説明しています。

図8-6 Advanced HTTP Caching for Content Engine ウィンドウ ― 上部

 

ステップ 4 クライアントが要求を中断した場合でもオブジェクトのキャッシュを継続するには、Advanced HTTP Caching という項目の下にある Enable Cache on Abort チェックボックスにチェックマークを付けます。

ステップ 5 サーバからダウンロードするべきデータの残りキロバイト数が最大スレッシュホールドより小さい場合に、オブジェクトをキャッシュするには、 Use Max Threshold チェックボックスにチェックマークを付けます。

ステップ 6 Abort Max Threshold フィールドに、最大スレッシュホールドをキロバイト数で入力します。デフォルト値は 256 キロバイトです。

ステップ 7 サーバからダウンロードするべきデータの残りキロバイト数が最小スレッシュホールドより大きい場合に、オブジェクトをキャッシュするには、 Use Min Threshold チェックボックスにチェックマークを付けます。

ステップ 8 Abort Min Threshold フィールドに、最小スレッシュホールドをキロバイト数で入力します。デフォルト値は 32 キロバイトです。

ステップ 9 オブジェクトのダウンロード済みパーセント値が設定したスレッシュホールドのパーセント値よりも大きい場合に、オブジェクトをキャッシュするには、 Use Percent Threshold チェックボックスにチェックマークを付けます。

ステップ 10 Abort Percent Threshold フィールドに、スレッシュホールドのパーセント値を入力します。デフォルト値は 80% です。

ステップ 11 Content Engine ファーム内の Content Engine が、クラスタ内にある他の Content Engine にキャッシュ オブジェクトを照会し、これを取得できるようにするには、Cluster Settings という項目の下にある Enable Clustering チェックボックスにチェックマークを付けます。

ステップ 12 Cluster Heal Port フィールドに、ヒーリング Content Engine からの要求をクラスタ内にある他の Content Engine に送信するためのポート番号を入力します(デフォルト HTTP ポート 14333 を使用しない場合)。

Content Engine クラスタ内にある別の Content Engine からの照会に応答する Content Engine は、ヒーリング サーバと呼ばれます。クラスタからキャッシュ オブジェクトを要求する Content Engine は、ヒーリング クライアントと呼ばれます。

ステップ 13 Cluster HTTP Port フィールドに、ヒーリング Content Engine からの要求をクラスタ内にある他の Content Engine に送信するための HTTP ポート番号を入力します。デフォルトのポートは 80 です。

ステップ 14 Cluster Max Delay フィールドに、ヒーリング Content Engine がヒーリング Content Engine 応答を待つ最大時間(秒単位)を入力します。

ステップ 15 Cluster Misses フィールドに、最後のヒーリング モード ヒット応答以降に、ヒーリング Content Engine がクラスタから受信できる最大ミス数を入力します。

ステップ 16 Content Engine 上で永続接続を許可するには、Persistent Connections Setting 見出しの下にある Enable Persistent Connections チェックボックスにチェックマークを付けます(図8-7 を参照)。

図8-7 Advanced HTTP Caching for Content Engine ウィンドウ ― 下部

 

ステップ 17 Persistent Connections Type ドロップダウン リストから永続接続タイプを選択します。永続接続は、クライアントのみ、サーバのみ、または Content Engine 上の接続すべてに対して設定できます。

ステップ 18 Persistent Connection Timeout フィールドに、Content Engine が接続を終了する前に、アイドル状態の永続接続を維持しておく時間(秒単位)を入力します。デフォルト値は 600 秒です。

ステップ 19 Content Engine からキープアライブ プローブを送信して Content Engine で永続接続を可能にするには、TCP KeepAlive Settings という項目の下にある Enable TCP Keepalive チェックボックスにチェックマークを付けます。

HTTP 接続の場合、デフォルトのタイムアウト値は 5 分です。キープアライブ メッセージが Content Engine からクライアントとエッジ Content Engine に送信されない場合は、接続が終了します。HTTP TCP キープアライブ機能がイネーブルの場合、Content Engine は TCP キープアライブ タイムアウト、TCP キープアライブ プローブ カウント、TCP キープアライブ プローブ インターバルなどのキープアライブ設定パラメータを使用して、TCP キープアライブをアイドル状態の TCP 接続に送信し続けます。

ステップ 20 この設定値を保存するには、 Submit をクリックします。

保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 

表8-6 拡張 HTTP キャッシュの設定

GUI パラメータ
機能
CLI コマンド

Advanced HTTP Caching

Enable Cache On Abort

クライアントが要求を中断した場合でもオブジェクトのキャッシュを継続します。

http cache-on-abort enable

Use Max Threshold

サーバからダウンロードするべきデータの残りキロバイト数が最大スレッシュホールドより小さい場合に、オブジェクトをキャッシュします。

http cache-on-abort max-threshold max_thresh

Abort Max Threshold

最大スレッシュホールド(キロバイト数)

Use Min Threshold

サーバからダウンロードするべきデータの残りキロバイト数が最小スレッシュホールドより大きい場合に、オブジェクトをキャッシュします。

http cache-on-abort min-threshold min_thresh

Abort Min Threshold

最小スレッシュホールド(キロバイト数)

Use Percent Threshold

オブジェクトのダウンロード済みパーセント値が設定したスレッシュホールドのパーセント値よりも大きい場合に、オブジェクトをキャッシュします。

http cache-on-abort percent percenthresh

Abort Percent Threshold

スレッシュホールドのパーセント値

Cluster Settings

Enable Clustering

Content Engine ファーム内の Content Engine が、クラスタ内にある他の Content Engine にキャッシュ オブジェクトを照会し、これを取得できるようにします。

--

Cluster Heal Port

ヒーリング Content Engine からの要求をクラスタ内にある他の Content Engine に送信するためのポート番号(デフォルト HTTP ポート 14333 を使用しない場合)。

http cluster heal-port num

Cluster HTTP Port

ヒーリング Content Engine からの要求をクラスタ内にある他の Content Engine に送信するための HTTP ポート番号。

http cluster http-port num

Cluster Max Delay

ヒーリング Content Engine がヒーリング Content Engine 応答を待つ最大時間(秒単位)。

http cluster max-delay seconds

Cluster Misses

最後のヒーリング モード ヒット応答以降に、ヒーリング Content Engine がクラスタから受信できる最大ミス数。

http cluster misses num

永続接続設定

Enable Persistent Connections

Content Engine 上で永続接続を可能にします。

--

Persistent Connection Type

Content Engine 上での接続に対して、永続接続のタイプ(クライアントのみ、サーバのみ、すべて)を設定します。

http persistent-connections { all | server-only | client-only }

Persistent Connection Timeout

Content Engine が接続を終了する前に、アイドル状態の永続接続を維持しておく時間(秒単位)

http persistent-connections timeout seconds

TCP キープアライブ設定

Enable TCP Keepalive

Content Engine からキープアライブ プローブを送信します。

http tcp-keepalive enable


) タスクバー内のアイコンを使用して実行できるその他の操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

Content Engine へのその他の HTTP 要求方式の追加または変更

Content Engine では、該当する HTTP 要求方式がサポートされているかにどうかよって、HTTP 要求を承認または拒否します。HTTP 1.1 要求方式(たとえば、GET、HEAD、POST など)は、デフォルトでサポートされています。Web-Based Distributed Authoring and Versioning(WebDAV)などの非標準の要求方式はサポートされていません。

Content Engine がクライアントから非サポート方式の HTTP 要求を受信すると、ACNS ソフトウェアはその方式を非サポート方式リストに追加し、エラーをクライアントに送信します。要求方式を Content Engine でサポートされている方式のリストに追加するには、Creating New HTTP Method for Content Engine ウィンドウを使用します。

HTTP 要求方式を追加する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべて一覧表示されます。

ステップ 2 HTTP 要求方式を追加する Content Engine の名前の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > HTTP Method の順に選択します。HTTP Methods for Content Engine ウィンドウに、方式の名前とデバイス グループのソースが表示されます。Device Group Source カラムでは、Content Engine に設定が適用されているデバイス グループの名前が表示されます。

ステップ 4 Aggregate Settings では、 Yes オプション ボタンが選択されています。この場合、HTTP 方式が Content Engine と関連デバイス グループに対して適用されます。HTTP 方式を Content Engine だけに適用するには、 No オプション ボタンをクリックします。


) Aggregate Settings の Yes オプション ボタンを選択すると、Content Engine が属するデバイス グループに対して設定された HTTP 方式は変更または削除できません。これらの設定は読み取り専用です。ただし、Content Engine に対して設定されている HTTP 方式は変更できます。Aggregate Settings の No オプション ボタンを選択すると、Content Engine の HTTP 方式だけを表示または変更できますが、対応するデバイス グループの HTTP 方式は表示または変更できません。


ステップ 5 タスクバーから Create New HTTP Method アイコンをクリックします。Creating new HTTP method for Content Engine ウィンドウが表示されます。

ステップ 6 Method Name フィールドに、サポート対象の方式リストに追加する HTTP 要求方式の名前を入力します。

ステップ 7 この設定値を保存するには、 Submit をクリックします。HTTP Methods for Content Engine ウィンドウに、新規に追加された HTTP 方式が表示されます。


 

CLI を使用して新規 HTTP 要求方式を追加するには、 http add-method グローバル コンフィギュレーション コマンドを使用します。

HTTP Cache Vary User Agent の設定

Vary ヘッダーを使用して、応答をキャッシングする場合のパラメータの設定方法は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices( または Devices > Device Groups )の順に選択します。

ステップ 2 設定する Content Engine またはデバイス グループの横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > HTTP Cache User Agent の順に選択します。HTTP User Agents for Content Engine(または Device Group)ウィンドウが表示されます。

ステップ 4 タスクバー内の Create New HTTP User Agent アイコンをクリックします。Creating New HTTP User Agent ウィンドウが表示されます(図8-8 を参照)。 表8-7 で、このウィンドウ内のフィールドについて説明し、対応する CLI コマンドを示します。

図8-8 Creating New HTTP User Agent ウィンドウ

 

ステップ 5 SubString フィールドに、代わりの user-agent の検索中に照合で使用するストリングを入力します。

サブストリングの設定値は一意でなければなりません。Content Distribution Manager GUI は、サブストリング設定が重複しているとエラー メッセージを返します。

ステップ 6 CacheString フィールドに、オブジェクト キーを形成するストリングを入力します。

無効な文字は、一重引用符(')、二重引用符(")、縦棒(|)、疑問符(?)、スペースです。

ステップ 7 この設定を保存するには、 Submit をクリックします。ウィンドウが更新され、HTTP User Agents ウィンドウには新しい項目がリスト表示されます。エントリは 32 個まで作成できます。

ステップ 8 これらの設定を有効にするために、HTTP Caching for Content Engine ウィンドウ内の Enable Cache Vary User Agent チェックボックスにチェックマークを付けて、Content Engine をイネーブルにします(HTTP キャッシュの設定を参照)。

 

表8-7 HTTP Cache User Agent の設定

GUI パラメータ
機能
CLI コマンド

SubString

代わりの user-agent の検索中に照合で使用するストリングを設定します。最長文字数は 16 です。

http cache-vary-user-agent sub-string string cache-string string

CacheString

オブジェクト キーを形成するキャッシュ ストリングを設定します。最長文字数は 16 です。


 

HTTP 宛先ポート制限の設定

Cisco ACNS ソフトウェアでは、Content Distribution Manager GUI を使用して HTTP 宛先ポートのアクセス制限を設定できます。

HTTP 宛先ポート制限を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 宛先ポート制限を設定する Content Engine の横にある Edit アイコンをクリックします。選択した Content Engine の Device Home ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Web > HTTP > HTTP Destination Port Restrictions の順に選択します。HTTP Destination Port Restriction Settings ウィンドウが表示されます。デフォルトでは、このウィンドウには、選択したデバイスの現在の設定が表示されます。

ステップ 4 すべてのポートへのアクセスを許可するには、 Allow All Ports チェックボックスにチェックマークを付けます。


) デフォルトでは、Allow All Ports にはチェックボックスにチェックマークが付いています。これによって、ポート範囲 80~87 および 1024 より番号の大きいポートへのトラフィックが許可されます。


ステップ 5 Allow Port Range List フィールドに、トラフィックを許可するポート番号またはポート範囲を入力します。最大 8 個のポート番号またはポート範囲を、スペースで区切って入力できます。

ステップ 6 すべてのポートへのトラフィックを拒否するには、 Deny All Ports チェックボックスにチェックマークを付けます。


) ポート 1024 より小さい番号のポートはデフォルトで拒否されます。ただし、ポート範囲 80~87 は除きます。


ステップ 7 これらのポートへのトラフィックを許可するには、 Deny Port Range 1-79 チェックボックスのチェックマークを外します。

ステップ 8 これらのポートへのトラフィックを許可するには、 Deny Port Range 80-1024 チェックボックスのチェックマークを外します。

ステップ 9 Other Deny Port Range List フィールドに、トラフィックを拒否するポート番号またはポート範囲を入力します。最大 8 個のポート番号またはポート範囲を、スペースで区切って入力できます。


) Deny Port Range 1-79 および Deny Port Range 80-1024 の両方にチェックマークが付いている場合、Other Deny Port Range List フィールドには 6 個までしかポート番号またはポート範囲を入力できません。Deny Port Range 1-79 または Deny Port Range 80-1024 のいずれかにチェックマークが付いていると、Other Deny Port Range List フィールドでは、8 個ではなく、最大 7 個のポートを指定できます。


ステップ 10 この設定値を保存するには、 Submit をクリックします。デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。


 

CLI から HTTP 宛先ポート制限を設定するには、 http destination-port グローバル コンフィギュレーション コマンドを使用します。

HTTPS の設定

Content Engine とデバイス グループに対して HTTPS を設定、変更、および表示するには、以下の作業を実行します。

「HTTPS 証明書の設定」

「HTTPS 証明書グループの設定」

「HTTPS キーの設定」

「HTTPS プロキシの設定」

「HTTPS サーバの設定」

「HTTP と HTTPS 発信プロキシの除外の設定」

HTTPS 証明書の設定

デジタル証明書は、HTTPS クライアントに対して Content Engine がオリジン HTTPS サーバとして機能するためのクレデンシャルです。Content Distribution Manager GUI を使用すると、証明書の作成、外部ソースからの証明書のインポート、または既存の証明書の削除を行うことができます。

Creating New HTTPS Server for Content Engine ウィンドウまたは https server グローバル コンフィギュレーション コマンドを使用して Content Engine を設定した場合、HTTPS サーバに証明書を割り当て、キーを関連付けることができます。Content Engine はこの証明書を、対象となる HTTPS サーバへ要求を送信する HTTPS クライアントに提示します。

Content Engine は Apache サーバで使用される Privacy-Enhanced Mail(PEM)形式と Microsoft Internet Information Server(IIS)で使用される Public-Key Cryptography Standards(PKCS)#12 形式の証明書に対応します。

Content Engine は PEM 形式を内部で使用し、PKCS #12 形式の証明書を PEM 形式に自動的に変換します。別の形式の証明書を使用する場合は、事前にその証明書をサポートされている形式に変換する必要があります。

Content Engine の HTTPS 証明書を設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべて一覧表示されます。

ステップ 2 HTTPS 証明書を設定する Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 Contents ペインで、 Applications > Web > HTTPS > Certificates の順に選択します。HTTPS Certificates for Content Engine ウィンドウが表示されます。デバイス グループに対して作成された証明書は表示することはできますが、変更することはできません。

ステップ 4 HTTPS デジタル証明書を設定するには、タスクバーから Create New HTTPS Certificate アイコンをクリックします。 表8-8 で、このウィンドウ内のフィールドについて説明し、対応する CLI グローバル コンフィギュレーション コマンドを示します。

ステップ 5 Certificate Name フィールドで、証明書の名前を指定します。証明書の名前には、英数字、アンダースコア、およびハイフンだけを使用できます。証明書の名前の先頭には数字を指定できます。証明書の名前には 64 文字まで指定できます。

外部ソースから証明書をインポートして HTTPS サーバに関連付けるには、証明書を作成しておく必要があります。証明書の名前だけが CMS データベースに保存され、実際の証明書は Content Engine に保存されます。


) 作成した証明書の名前は変更できません。既存の証明書を削除してから、新しい証明書を作成する必要があります。


ステップ 6 Certificate URL フィールドで、証明書のインポート元外部ロケーションを指定します。この URL は、HTTP、FTP、または HTTPS を使用した有効な URL である必要があります。URL を指定し、変更を更新すると、証明書の値がインポートされます。

インポート値を含まない証明書の名前は Content Distribution Manager GUI には表示されますが、有効な値を持つ証明書だけが HTTPS サーバに関連付けられ、証明書グループに追加されます。1 つの URL から 2 つの異なる証明書をインポートし、2 つの異なる HTTPS サーバを同じ証明書に関連付けることができます。

Content Distribution Manager GUI を使用して証明書をインポートすると、タスクバーに新しいアイコン( Re-import )が表示されます。 Re-import アイコンを使用すると、インポートが失敗した場合に証明書を再度インポートすることができます。

ステップ 7 Username フィールドで、証明書のインポート元外部ソースへのアクセスに使用するユーザ名を指定します。外部ソースがパスワードで保護されている場合のみ、このフィールドに入力する必要があります。

ステップ 8 Password フィールドで、証明書のインポート元外部ソースにアクセスするユーザを認証するためのパスワードを指定します。外部ソースがパスワードで保護されている場合のみ、このフィールドに入力する必要があります。Confirm Password フィールドに、同じパスワードをもう一度入力します。

ステップ 9 この設定値を保存するには、 Submit をクリックします。

 

表8-8 HTTPS 証明書の設定

GUI パラメータ
機能
CLI コマンド

Certificate Name

証明書の名前

https server name cert cert_name

Certificate URL

証明書のインポート元の外部ロケーション。この URL は、HTTP、FTP、または HTTPS を使用した有効な URL である必要があります。

https server name host ipaddress または FQDN

Username

証明書のインポート元外部ソースにアクセスするためのユーザ名

--

Password

外部ソースにアクセスするユーザを認証するためのパスワード

--

Confirm Password

パスワードの入力を確認します。

--


) タスクバー内のアイコンを使用して実行できるその他の操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

Content Engine の HTTPS 証明書のフィルタリング

Content Distribution Manager GUI を使用すると、HTTPS 証明書を証明書の名前と URL でフィルタリングして、一部だけを表示できます。

フィルタ条件を設定して、条件に合った HTTPS 証明書を表示する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべてリスト表示されます。

ステップ 2 HTTPS 証明書をフィルタリングする Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが開き、左側に Contents ペインが表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTPS > Certificates の順に選択します。HTTPS
Certificates for Content Engine ウィンドウが表示されます。デバイス グループに対して作成された証明書は表示することはできますが、変更することはできません。

ステップ 4 タスクバーから Filter Table アイコンをクリックします。Filtering HTTPS Certificates for Content Engine ウィンドウが表示されます。

ステップ 5 Certificate Name ドロップダウン リストからフィルタ演算子を選択し、照合する証明書の名前を入力します。 表8-9 で、HTTPS 証明書のフィルタリングに使用するフィルタ演算子について説明します。

ステップ 6 Certificate URL ドロップダウン リストからフィルタ演算子を選択し、照合する証明書のロケーションを入力します。

ステップ 7 Submit をクリックします。HTTPS Certificates for Content Engine ウィンドウが再度開き、指定されたフィルタ条件に一致する証明書がすべて表示されます。

 

表8-9 HTTPS 証明書のフィルタリング

フィルタ演算子
説明

Like

入力されたストリングと同様の設定を持つ HTTPS 証明書が含まれます。0 文字以上の任意の文字についてワイルドカード検索を行うにはパーセント記号(%)を使用し、1 文字だけのワイルドカード検索を行うにはアンダースコア(_)を使用します。ストリングに「^」、「,」、「'」などの特殊文字が含まれている場合は、バックスラッシュ(\)をエスケープ文字として使用して、特殊文字の意味を無視します。エスケープ文字の後には「%」と「_」以外の文字を指定できます。エスケープ文字の後のワイルドカード文字は、リテラル文字として処理されます。

たとえば、名前が httpscer で始まり、任意の 1 文字で終る HTTPS 証明書を表示するには、Certificate Group Name フィールドに httpscer_ と入力します。Httpscer という名前の証明書は表示されません。

Not like

入力されたストリングと異なる設定を持つ HTTPS 証明書が含まれます。0 文字以上の任意の文字についてワイルドカード検索を行うにはパーセント記号(%)を使用し、1 文字だけのワイルドカード検索を行うにはアンダースコア(_)を使用します。ストリングに「^」、「,」、「'」などの特殊文字が含まれている場合は、バックスラッシュ(\)をエスケープ文字として使用して、特殊文字の意味を無視します。エスケープ文字の後には「%」と「_」以外の文字を指定できます。エスケープ文字の後のワイルドカード文字は、リテラル文字として処理されます。

たとえば、URL が ftp:// 以外で始まる HTTPS 証明書を表示するには、Certificate URL フィールドに %ftp:// と入力します。URL が https://a.com または http://a.com で始まる証明書はすべて表示されます。

In

指定されたストリングのリストと共通の設定を持つ証明書が含まれます。ストリングは 1 つだけでも、複数をカンマで区切っても指定できます。指定するストリングにカンマまたは括弧が含まれる場合は、一重引用符(')を使用します。

たとえば、CER1、CER2、CER(3) という名前の証明書を表示するには、Certificate Name フィールドに (CER1,CER2,'CER(3)') または CER1,CER2,'CER(3)' と入力します。CER4、CER5 などの名前の証明書は表示されません。

Not in

指定されたストリングのリスト以外の設定を持つ証明書が含まれます。ストリングは 1 つだけでも、複数をカンマで区切っても指定できます。指定するストリングにカンマまたは括弧が含まれる場合は、一重引用符(')を使用します。

たとえば、CER1、CER2、CER(3) 以外の名前の証明書を表示するには、Certificate Name フィールドに (CER1,CER2,'CER(3)') または CER1,CER2,'CER(3)' と入力します。CER4、CER5 などの名前の証明書が表示されます。

Equal to

入力されたストリングと等しい設定を持つ証明書が含まれます。

たとえば、http://Location1 という URL からインポートされた証明書をすべて表示するには、Certificate URL フィールドに http://Location1 と入力します。
http://Location^1 からインポートされた証明書は表示されません。キーワード、特殊文字、またはワイルドカード文字は使用できません。

Not equal to

入力されたストリングと等しくない設定を持つ証明書が含まれます。

たとえば、http://Location1 以外の URL からインポートされた証明書をすべて表示するには、Certificate URL フィールドに http://Location1 と入力します。
http://Location^1 からインポートされた証明書は表示されます。キーワード、特殊文字、またはワイルドカード文字は使用できません。

 


 

HTTPS 証明書グループの設定

証明書グループは、ルート Certificate Authority(CA; 認証局)からエンド エンティティへの信頼関係のチェーンを表します。証明書グループ内の各証明書(エンド エンティティの証明書は除く)は、チェーン内の次の証明書に署名して、その証明書を信頼します。エンド エンティティの証明書は、この証明書に先行する証明書グループ内のすべての証明書が信頼できる場合にのみ信頼されます。証明書グループを使用すると、HTTPS サーバを単一の証明書のように扱うことができます。クライアントがすべての証明書をローカルに保持する必要がないというメリットもあります。また、サーバの証明書を証明書グループの証明書と比較することにより、証明書グループを使用して HTTPS サーバの確認と認証を行うこともできます。

Content Engine の HTTPS 証明書グループを設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべてリスト表示されます。

ステップ 2 HTTPS 証明書グループを設定する Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTPS > Certificate Groups の順に選択します。HTTPS Certificate Groups for Content Engine ウィンドウが表示されます。デバイス グループに対して作成された証明書グループは表示することはできますが、変更することはできません。

ステップ 4 HTTPS デジタル証明書グループを設定するには、タスクバーから Create New HTTPS Certificate Group アイコンをクリックします。HTTPS Certificate Group for Content Engine ウィンドウが表示されます。このウィンドウから、所定の名前で証明書グループを作成し、既存の証明書を指定して現在の証明書グループに追加できます。

ステップ 5 Certificate Group Name フィールドで、証明書チェーンとサーバ証明書の認証に使用する証明書グループの名前を指定します。証明書グループの名前には、英数字、アンダースコア、およびハイフンだけを使用できます。証明書グループの名前の先頭には、数字を指定できます。また、証明書グループの名前には最大 64 文字まで指定できます。


) 作成した証明書グループの名前は変更できません。既存の証明書グループを削除してから、新しい証明書グループを作成する必要があります。


ステップ 6 Certificate ドロップダウン リストから、証明書グループに追加する証明書の名前を選択します。HTTPS Certificates for Content Engine ウィンドウを使用して作成した証明書が、すべてリスト表示されます。証明書グループごとに最大 6 つの証明書を追加できます。

2 つの異なる証明書グループに、同じ組み合わせの HTTPS 証明書を指定できます。Certificate ドロップダウン リストからは、1 から 6 まで最大 6 つの証明書を選択できます。これらのドロップダウン リストの初期値は、 Do not set に設定されています。これらの証明書を証明書グループに追加する場合は、これらの証明書を順番通りに選択する必要があります。関連付けられた各証明書は一意でなければなりません。一意でない場合は、 Submit をクリックしたときにエラー メッセージが表示されます。

ステップ 7 証明書グループを削除するには、タスクバーから Delete HTTPS Certificate Group アイコンをクリックします。HTTPS サーバで参照されている証明書グループは削除できません。削除するには、証明書グループと HTTPS サーバの関連付けを解除する必要があります。

ステップ 8 HTTPS 証明書グループの一部だけを表示するには、タスクバーから Filter Table アイコンをクリックします。詳細は、「 Content Engine の HTTPS 証明書グループのフィルタリング 」を参照してください。

ステップ 9 設定済みの HTTPS 証明書グループの一覧表示画面に戻るには、タスクバーから View All HTTPS Certificate Groups アイコンをクリックします。

ステップ 10 この設定値を保存するには、 Submit をクリックします。

 

表8-10 HTTPS 証明書グループの設定

GUI パラメータ
機能
CLI コマンド

Certificate Group Name

証明書グループの名前

https server name certgroup chain certgroup_name

Certificate 1, 2, 3...

HTTPS サーバに対して使用する証明書チェーン

 


 

Content Engine の HTTPS 証明書グループのフィルタリング

Content Distribution Manager GUI を使用すると、HTTPS 証明書グループを証明書グループの名前でフィルタリングして、一部だけを表示できます。

フィルタ条件を設定して、条件に合った HTTPS 証明書グループを表示する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべてリスト表示されます。

ステップ 2 HTTPS 証明書グループをフィルタリングする Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが開き、左側に Contents ペインが表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTPS > Certificate Groups の順に選択します。HTTPS Certificate Groups for Content Engine ウィンドウが表示されます。デバイス グループに対して作成された証明書グループは表示することはできますが、変更することはできません。

ステップ 4 タスクバーから Filter Table アイコンをクリックします。Filtering HTTPS Certificate Groups for Content Engine ウィンドウが表示されます。

ステップ 5 Certificate Group Name ドロップダウン リストからフィルタ演算子を選択し、照合する証明書グループの名前を入力します。

ステップ 6 設定済みの HTTPS 証明書グループの一覧表示画面に戻るには、タスクバーから View All HTTPS Certificate Groups アイコンをクリックします。 表8-11 で、HTTPS 証明書グループのフィルタリングに使用するフィルタ演算子について説明します。

ステップ 7 Submit をクリックします。HTTPS Certificate Groups for Content Engine ウィンドウが再度開き、指定されたフィルタ条件に一致する証明書グループがすべて表示されます。

 

表8-11 HTTPS 証明書グループのフィルタリング

フィルタ演算子
説明

Like

入力されたストリングと同様の設定を持つ HTTPS 証明書グループが含まれます。0 文字以上の任意の文字についてワイルドカード検索を行うにはパーセント記号(%)を使用し、1 文字だけのワイルドカード検索を行うにはアンダースコア(_)を使用します。ストリングに「^」、「,」、「'」などの特殊文字が含まれている場合は、バックスラッシュ(\)をエスケープ文字として使用して、特殊文字の意味を無視します。エスケープ文字の後には「%」と「_」以外の文字を指定できます。エスケープ文字の後のワイルドカード文字は、リテラル文字として処理されます。

たとえば、名前が httpscer で始まり、任意の 1 文字で終る HTTPS 証明書を表示するには、Certificate Group Name フィールドに httpscer_ と入力します。Httpscer という名前の証明書は表示されません。

Not like

入力されたストリングと異なる設定を持つ HTTPS 証明書グループが含まれます。0 文字以上の任意の文字についてワイルドカード検索を行うにはパーセント記号(%)を使用し、1 文字だけのワイルドカード検索を行うにはアンダースコア(_)を使用します。ストリングに「^」、「,」、「'」などの特殊文字が含まれている場合は、バックスラッシュ(\)をエスケープ文字として使用して、特殊文字の意味を無視します。エスケープ文字の後には「%」と「_」以外の文字を指定できます。エスケープ文字の後のワイルドカード文字は、リテラル文字として処理されます。

たとえば、名前が httpscer 以外で始まる HTTPS 証明書グループを表示するには、Certificate Group Name フィールドに httpscer と入力します。Httpscer という名前のサーバは表示されます。

In

指定されたストリングのリストと共通の設定を持つ証明書グループが含まれます。ストリングは 1 つだけでも、複数をカンマで区切っても指定できます。指定するストリングにカンマまたは括弧が含まれる場合は、一重引用符(')を使用します。

たとえば、CER1、CER2、CER(3) という名前の証明書グループを表示するには、Certificate Name フィールドに (CER1,CER2,'CER(3)') または
CER1,CER2,'CER(3)' と入力します。CER4、CER5 などの名前の証明書グループは表示されません。

Not in

指定されたストリングのリスト以外の設定を持つ証明書グループが含まれます。ストリングは 1 つだけでも、複数をカンマで区切っても指定できます。指定するストリングにカンマまたは括弧が含まれる場合は、一重引用符(')を使用します。

たとえば、CER1、CER2、CER(3) 以外の名前の証明書グループを表示するには、Certificate Name フィールドに (CER1,CER2,'CER(3)') または
CER1,CER2,'CER(3)' と入力します。CER4、CER5 などの名前の証明書グループが表示されます。

Equal to

入力されたストリングと等しい名前を持つ証明書グループが含まれます。

たとえば、httpscer という名前の証明書グループを表示するには、Certificate Group Name フィールドに httpscer と入力します。Httpscer という名前の証明書グループは表示されません。キーワード、特殊文字、またはワイルドカード文字は使用できません。

Not equal to

入力されたストリングと等しくない名前を持つ証明書グループが含まれます。

たとえば、httpscer 以外の名前の証明書グループを表示するには、Certificate Group Name フィールドに httpscer と入力します。Httpscer という名前の証明書グループは表示されます。キーワード、特殊文字、またはワイルドカード文字は使用できません。

 


 

HTTPS キーの設定

秘密鍵は、公開鍵アルゴリズムで使用される 1 組の鍵のうち、一般に公開されない鍵です。通常、秘密鍵は、対称セッション鍵の暗号化、メッセージのデジタル署名、または対応する公開鍵で暗号化されたメッセージの復号化に使用されます。PKCS #12 は、ユーザの秘密鍵と証明書情報を保存し、転送するための移植用フォーマットです。Content Engine がオリジン HTTPS サーバとして動作するために使用する秘密鍵は、選択された証明書と一致しなければなりません。

Content Distribution Manager GUI を使用すると、所定の名前の鍵の作成、外部ソースからの鍵のインポート、または既存の鍵の削除を行うことができます。Content Engine の HTTPS キーを設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべてリスト表示されます。

ステップ 2 HTTPS キーを設定する Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 Contents ペインから、Applications > Web > HTTPS > Keys の順に選択します。HTTPS Keys for Content Engine ウィンドウが表示されます(デバイス グループに対して作成された鍵は表示することはできますが、変更することはできません)。

ステップ 4 タスクバーから Create New HTTPS Key アイコンをクリックして、HTTPS キーを設定します。Creating new HTTPS Key for Content Engine ウィンドウが表示されます。

ステップ 5 Key Name フィールドで、内部または外部 CA からインポートされる秘密鍵の名前を指定します。外部ソースから秘密鍵をインポートして HTTPS サーバに関連付けるには、秘密鍵を作成しておく必要があります。鍵の名前には、英数字、アンダースコア、およびハイフンだけを使用できます。鍵の名前の先頭には、数字を指定できます。また、鍵の名前には最大 64 文字まで指定できます。


) 作成した HTTPS キーの名前は変更できません。既存の鍵を削除してから、新しい鍵を作成する必要があります。CMS データベースには HTTPS キーの名前だけが保存されます。実際の証明書は Content Engine に保存されます。


ステップ 6 Key URL フィールドで、秘密鍵のインポート元外部ロケーションを指定します。この URL は、
HTTP、FTP、または HTTPS を使用した有効な URL である必要があります。URL を指定し、変更を更新すると、鍵の値がインポートされます。

インポート値を含まない鍵の名前は Content Distribution Manager GUI に表示されますが、有効な値を持つ鍵だけが HTTPS サーバに関連付けられます。1 つの URL から 2 つの異なる鍵をインポートし、2 つの異なる HTTPS サーバを同じ鍵に関連付けることができます。

Content Distribution Manager GUI を使用して鍵をインポートすると、タスクバーに新しいアイコン( Re-import )が表示されます。 Re-import アイコンを使用すると、インポートが失敗した場合に鍵を再度インポートすることができます。

ステップ 7 Username フィールドで、鍵のインポート元外部ソースへのアクセスに使用するユーザ名を指定します。外部ソースがパスワードで保護されている場合のみ、このフィールドに入力する必要があります。

ステップ 8 Password フィールドで、鍵のインポート元外部ソースにアクセスするユーザを認証するためのパスワードを指定します。外部ソースがパスワードで保護されている場合のみ、このフィールドに入力する必要があります。Confirm Password フィールドに、同じパスワードをもう一度入力します。

ステップ 9 HTTPS キーの一部だけを表示するには、タスクバーから Filter Table アイコンをクリックします。詳細は、「Content Engine の HTTPS キーのフィルタリング」を参照してください。

ステップ 10 設定済みの HTTPS キーの一覧表示画面に戻るには、タスクバーから View All HTTPS Keys アイコンをクリックします。

ステップ 11 この設定値を保存するには、 Submit をクリックします。

 

表8-12 HTTPS キーの設定

GUI パラメータ
機能
CLI コマンド

Key Name

鍵の名前

https server name key name password password

Key URL

秘密鍵のインポート元外部ロケーション

Password

秘密鍵ファイルを復号化するためのパスワード

 


 

Content Engine の HTTPS キーのフィルタリング

Content Distribution Manager GUI を使用すると、HTTPS キーを秘密鍵の名前と URL でフィルタリングして、一部だけを表示できます。

フィルタ条件を設定して、条件に合った HTTPS キーを表示する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべてリスト表示されます。

ステップ 2 HTTPS キーをフィルタリングする Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが開き、左側に Contents ペインが表示されます。

ステップ 3 Contents ペインから、Applications > Web > HTTPS > Keys の順に選択します。HTTPS Keys for ContentEngine ウィンドウが表示されます。デバイス グループに対して作成された鍵は表示することはできますが、変更することはできません。

ステップ 4 タスクバーから Filter Table アイコンをクリックします。Filtering HTTPS Keys for Content Engine ウィンドウが表示されます。

ステップ 5 Key Name ドロップダウン リストからフィルタ演算子を選択し、照合する鍵の名前を入力します。

ステップ 6 Key URL ドロップダウン リストからフィルタ演算子を選択し、照合する鍵のロケーションを入力します。

ステップ 7 設定済みの HTTPS キーの一覧表示画面に戻るには、タスクバーから View All HTTPS Keys アイコンをクリックします。 表8-13 で、HTTPS キーのフィルタリングに使用するフィルタ演算子について説明します。

ステップ 8 Submit をクリックします。HTTPS Keys for Content Engine ウィンドウが再度表示され、指定されたフィルタ条件に一致する鍵がすべて表示されます。

 

表8-13 HTTPS キーのフィルタリング

フィルタ演算子
説明

Like

入力されたストリングと同様の設定を持つ HTTPS キーが含まれます。0 文字以上の任意の文字についてワイルドカード検索を行うにはパーセント記号(%)を使用し、1 文字だけのワイルドカード検索を行うにはアンダースコア(_)を使用します。ストリングに「^」、「,」、「'」などの特殊文字が含まれている場合は、バックスラッシュ(\)をエスケープ文字として使用して、特殊文字の意味を無視します。エスケープ文字の後には「%」と「_」以外の文字を指定できます。エスケープ文字の後のワイルドカード文字は、リテラル文字として処理されます。

たとえば、名前が httpskey で始まり、任意の 1 文字で終る HTTPS キーを表示するには、Station Name フィールドに httpskey_ と入力します。Httpskey という名前の鍵は表示されません。

Not like

入力されたストリングと異なる設定を持つ HTTPS キーが含まれます。0 文字以上の任意の文字についてワイルドカード検索を行うにはパーセント記号(%)を使用し、1 文字だけのワイルドカード検索を行うにはアンダースコア(_)を使用します。ストリングに「^」、「,」、「'」などの特殊文字が含まれている場合は、バックスラッシュ(\)をエスケープ文字として使用して、特殊文字の意味を無視します。エスケープ文字の後には「%」と「_」以外の文字を指定できます。エスケープ文字の後のワイルドカード文字は、リテラル文字として処理されます。

たとえば、URL が ftp:// 以外で始まる HTTPS キーを表示するには、Media フィールドに %ftp:// と入力します。URL が https://a.com または http://a.com で始まるキーはすべて表示されます。

In

指定されたストリングのリストと共通の設定を持つ鍵が含まれます。ストリングは 1 つだけでも、複数をカンマで区切っても指定できます。指定するストリングにカンマまたは括弧が含まれる場合は、一重引用符(')を使用します。

たとえば、KEY1、KEY2、KEY(3) という名前の鍵を表示するには、Key Name フィールドに (KEY1,KEY2,'KEY(3)') または KEY1,KEY2,'KEY(3)' と入力します。KEY4、KEY5 などの名前の鍵は表示されません。

Not in

指定されたストリングのリスト以外の設定を持つ鍵が含まれます。ストリングは 1 つだけでも、複数をカンマで区切っても指定できます。指定するストリングにカンマまたは括弧が含まれる場合は、一重引用符(')を使用します。

たとえば、KEY1、KEY2、KEY(3) 以外の名前の鍵を表示するには、Key Name フィールドに (KEY1,KEY2,'KEY(3)') または KEY1,KEY2,'KEY(3)' と入力します。KEY4、KEY5 などの名前の鍵が表示されます。

Equal to

入力されたストリングと等しい設定を持つ鍵が含まれます。

たとえば、http://Location1 という URL からインポートされたすべての鍵を表示するには、Key URL フィールドに http://Location1 と入力します。
http://Location^1 からインポートされた鍵は表示されません。キーワード、特殊文字、またはワイルドカード文字は使用できません。

Not equal to

入力されたストリングと等しくない設定を持つ鍵が含まれます。

たとえば、http://Location1 以外の URL からインポートされたすべての鍵を表示するには、Key URL フィールドに http://Location1 と入力します。
http://Location^1 からインポートされた鍵は表示されます。キーワード、特殊文字、またはワイルドカード文字は使用できません。

 


 

HTTPS プロキシの設定

Cisco ACNS 5.x ソフトウェアでは、次の 2 つのシナリオで HTTPS をサポートします。

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

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

いずれの場合も、Content Engine はオリジン サーバへの接続(直接または別のプロキシ サーバ経由)を確立し、Web クライアントとオリジン サーバが、その Content Engine 経由で Secure Socket Layer(SSL)トンネルを設定できるようにします。


) HTTPS プロキシ要求をサポートするには、Domain Name System(DNS; ドメイン ネーム システム)サーバを設定する必要があります。詳細は、「HTTP プロキシ キャッシングの DNS サーバの設定」を参照してください。


HTTPS プロキシのパラメータを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Device Groups の順に選択します。デバイス グループを作成した場合は、Device Group ウィンドウが表示されます。


) HTTPS プロキシのパラメータは、各 Content Engine に対してか、またはデバイス グループに対して設定できます。ここでは、デバイス グループに対して HTTPS プロキシを設定する手順を説明します。


ステップ 2 設定するデバイス グループ名の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTPS > HTTPS Proxy の順に選択します。HTTPS Proxy Settings for Content Engine ウィンドウが表示されます(図8-9 および図8-10 を参照)。 表8-14 で、このウィンドウ内のフィールドについて説明します。

図8-9 HTTPS Proxy Settings ウィンドウ ― 上部

 

ステップ 4 Content Engine でポート 80 以外のポートに対する着信要求を受け入れるには、 Enable Incoming Proxy チェックボックスにチェックマークを付けます。

ステップ 5 List of Incoming Ports フィールドに、プロキシ サーバが使用するポート番号を入力します。複数の番号はスペースで区切ります。

ステップ 6 TCP サーバ接続のリード/ライト タイムアウトを設定するには、 Enable TCP チェックボックスにチェックマークを付けます。

ステップ 7 TCP Read/Write Timeout フィールドに、読み込みまたは書き込みタイムアウトの値を秒単位で入力します。範囲は 1~3600 で、デフォルトは 120 秒です。

ステップ 8 発信プロキシの使用をイネーブルにするには、 Enable Outgoing Proxy チェックボックスにチェックマークを付けます。

ステップ 9 HTTPS トラフィックをすべてのポートで許可する場合は、 Allow All Ports チェックボックスにチェックマークを付けます。

ステップ 10 HTTPS トラフィックをポート 443 で許可する場合は、 Allow port 443 チェックボックスにチェックマークを付けます。

ステップ 11 HTTPS トラフィックをポート 563 で許可する場合は、 Allow port 563 チェックボックスにチェックマークを付けます。

ステップ 12 Other Allow Port List フィールドに、HTTPS トラフィックを許可するポート番号のリストを入力します。各番号はスペースで区切ります。このフィールドは、発信プロキシがイネーブルな場合に必要です。範囲は 1~65535 です。最大 8 つのポートを設定できます。デフォルトで、ポート 443 と 563 が許可されます。

ステップ 13 HTTPS トラフィックをすべてのポートでブロックする場合は、 Deny All Ports チェックボックスにチェックマークを付けます。

ステップ 14 Deny Port List フィールドに、HTTPS 要求を拒否するポート番号のリストを入力します。各番号はスペースで区切ります。このフィールドは発信プロキシがイネーブルな場合に必要です。

範囲は 1~65535 です。最大 8 つのポートを設定できます。デフォルトで、ポート 1024 への HTTPS 要求が拒否されます。これにより、要求が Content Engine を経由する場合、HTTPS ポートへの不要なアクセスを防止できます。

ステップ 15 発信プロキシ設定フィールドをイネーブルにするには、 Enable Outgoing Proxy チェックボックスにチェックマークを付けます(図8-10 を参照)。

図8-10 HTTPS Proxy Settings ウィンドウ ― 下部

 

ステップ 16 すべての発信プロキシ サーバが故障した場合にオリジン サーバを使用するには、 Use Origin Server チェックボックスにチェックマークを付けます。このチェックボックスにチェックマークを付けると、設定されているすべてのプロキシ サーバが故障した場合に、Content Engine では状況に応じて、HTTPS ヘッダー内で指定されているオリジン サーバに HTTPS 要求をリダイレクトできます。このオプションがイネーブルでない場合、クライアントはエラー応答を受信します。このとき、応答エラーと読み取りエラーがクライアントに返されます。これは、これらのエラーがオリジン サーバまたはプロキシのどちらで生成されたかが検出できないためです。

ステップ 17 Outgoing Connection Timeout フィールドにマイクロ秒単位で値を入力します。この値は、発信プロキシ サーバがアクティブであるかどうかをプローブするまでのマイクロ秒数を指定します。

ステップ 18 Outgoing Monitor Period フィールドに値を入力して、Content Engine が指定された発信 HTTPS プロキシ サーバをポーリングする頻度を指定します。

Content Engine は、設定された発信プロキシ サーバの状態をバックグラウンドで監視します。指定された発信プロキシ サーバを特定の時間にポーリングするように Content Engine を設定して、サーバのアベイラビリティを監視できます。Outgoing Monitor Period は、プロキシ サーバをポーリングする時間です。モニタリング時間は 10 ~ 300 秒までの秒単位で指定できます。デフォルトのモニタリング時間は 60 秒です。発信プロキシ サーバの 1 台が使用不能である場合、ポーリング メカニズムによって接続がタイムアウト値(300000 マイクロ秒)に達するまで待機してから、次の発信プロキシ サーバにポーリングします。

ステップ 19 Outgoing Proxy Hostname フィールド 1~8 では、IP アドレスまたはホスト名を指定します(発信プロキシがイネーブルな場合)。最初のフィールドに設定したサーバが、Content Engine のプライマリ発信 HTTPS プロキシ サーバになります。このフィールドは発信プロキシがイネーブルな場合に必要です。

各 Content Engine には最大 8 台の HTTPS 発信プロキシ サーバを設定できます。一度に Content Engine が使用する設定済みの発信 HTTPS プロキシ サーバは、1 台だけです。複数のサーバを同時に使用することはできません。

ステップ 20 Outgoing Proxy Port フィールド 1~8 で、発信プロキシ サーバがプロキシ HTTPS 要求を受け入れるために使用するポート番号を指定します(発信プロキシがイネーブルな場合)(Hostname フィールドに入力されたプライマリ サーバにはポートが必要です)。

ステップ 21 この設定値を保存するには、 Submit をクリックします。

デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

表8-14 に、HTTPS プロキシ機能に対応した GUI パラメータと CLI コマンドを示します。CLI コマンドの入力順序は考慮の必要がありません。

 

表8-14 HTTPS プロキシ設定

GUI パラメータ
機能
CLI コマンド

Enable incoming proxy

ポート 80 以外のポートでも着信 HTTPS トラフィック要求を受け入れるように Content Engine を設定します。

https proxy incoming

List of incoming ports

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

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

Enable TCP

TCP Read/Write Timeout フィールドをイネーブルにします。

--

TCP Read/Write Timeout

TCP サーバ接続のリード/ライト タイムアウトを設定します。範囲は 1~3600 で、デフォルトは 120 秒です。

https tcp-rw-timeout seconds

Enable outgoing proxy

発信 HTTPS プロキシ サーバをイネーブルにします。

https proxy outgoing host { hostname | ipaddress } port 1-65535

Allow All ports

すべてのポートで HTTPS トラフィックを許可します。

https destination-port allow all

Allow port 443

ポート 443 で HTTPS トラフィックを許可します。

https destination-port allow 443

Allow port 563

ポート 563 で HTTPS トラフィックを許可します。

https destination-port allow 563

Other Allow Port List

HTTPS トラフィックを許可するポート番号のリスト(発信プロキシがイネーブルな場合に必要)。

範囲は 1~65535 です。最大 8 つのポートを設定できます。デフォルトで、ポート 443 と 563 が許可されます。

https destination-port allow port_num port_num port_num . . .

Deny All ports

すべてのポートで HTTPS トラフィックを拒否します。

https destination-port deny all

Deny Port List

HTTPS 要求を拒否するポート番号のリスト(発信プロキシがイネーブルな場合に必要)

https destination-port deny ports

Enable Outgoing Proxy

発信プロキシ設定パラメータを設定する GUI ウィンドウ内のフィールドをイネーブルにします。

--

Use Origin Server

HTTPS 要求を HTTPS ヘッダー内で指定されているオリジン サーバにリダイレクトします。

https proxy outgoing origin-server

Outgoing Connection Timeout

発信プロキシ サーバのプローブ時に使用するタイムアウト時間(マイクロ秒)。範囲は 200~5000000 です。デフォルト値は 300 マイクロ秒です。

https proxy outgoing connection-timeout microsecs

Outgoing Monitor Period

1 台の発信プロキシ サーバを監視する間隔(秒単位)を指定します。複数の発信プロキシ サーバが設定されている場合、これらは順次監視されます。デフォルト値は 200 秒です。

https proxy outgoing monitor seconds

Outgoing Proxy Hostname 1-8

HTTPS 発信プロキシ サーバの IP アドレスまたはホスト名

https proxy outgoing host { hostname | ipaddress }

Outgoing Proxy Port 1-8

HTTPS 発信プロキシ サーバのポート

https proxy outgoing host { hostname | ipaddress } port 1-65535


) HTTPS トラフィックは暗号化されているため、Web クライアントとオリジン サーバの間にある Content Engine や他のデバイスでは、このトラフィックは解読できません。HTTPS オブジェクトはキャッシュされません。



) タスクバー内のアイコンを使用して実行できるその他の操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

HTTPS サーバの設定

HTTPS サーバとキャッシング ソリューションを設定して、Content Engine を HTTPS オリジン サーバとして機能させることができます。この設定により、WAN トラフィックが減少し、データのセキュリティが向上します。これは、リモート ブランチ オフィスの認証されたクライアントが、HTTPS を使用して HTTPS サーバとして設定されているローカルの Content Engine にアクセスできるためです。

Content Engine ではクライアントからの HTTPS トラフィックを復号化し、キャッシングや要求処理などの通常の HTTP 処理を実行します。また、キャッシュ ミスまたはキャッシュ確認時には、Content Engine はオリジン サーバへの HTTPS 接続を開始し、オリジン サーバからコンテンツを取得します。

証明書、鍵、および証明書グループを使用する際には、次の制約事項があります。

有効なインポート値のない証明書は、証明書グループに関連付けることはできません。

証明書を付加されていない証明書グループは、HTTPS サーバに関連付けることはできません。

HTTPS サーバで使用される証明書は、変更または削除できません。

HTTPS サーバで使用される証明書グループは、変更または削除できません。

証明書グループに付加された証明書は、変更または削除できません。

HTTPS サーバで使用される鍵は、変更または削除できません。

Content Engine の HTTPS サーバを設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべてリスト表示されます。

ステップ 2 HTTPS サーバを設定する Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTPS > HTTPS Servers の順に選択します。HTTPS Servers for Content Engine ウィンドウが表示されます。

ステップ 4 Aggregate Settings では、 Yes オプション ボタンがデフォルトで選択されています。この場合、HTTP サーバが Content Engine と関連デバイス グループに対して適用されます。デバイス グループに対する HTTPS の設定は、変更または削除できません。この設定は読み取り専用です。ただし、Content Engine に対する HTTPS サーバは変更できます。Aggregate Settings の No オプション ボタンをクリックすると、Content Engine に対する HTTPS サーバだけを表示および変更できます。対応するデバイス グループの HTTPS サーバは表示されません。

ステップ 5 HTTPS サーバを設定するには、タスクバーから Create New HTTPS Server アイコンをクリックします。Creating new HTTPS Server for Content Engine ウィンドウが表示されます。

HTTPS サーバを設定するには、次の 3 種類の設定をする必要があります。

HTTPS Servers

Certificate Key/Associations

General HTTPS Settings

ステップ 6 HTTPS Server セクションでは、次の手順を実行します。

a. Name フィールドで、HTTPS サーバの名前を指定します。サーバ名には、アラビア数字、大文字と小文字のアルファベット、アンダースコア、ハイフン、ピリオドを使用できます。サーバ名は先頭の文字をアルファベットまたはアンダースコアにし、15 文字以内で指定します。

b. HTTPS サーバのキャッシングと SSL 終端をイネーブルにするには、 Enable チェックボックスにチェックマークを付けます。HTTPS サーバをイネーブルにする前に、ホスト名、証明書または証明書グループ、および秘密鍵を入力しておく必要があります。

c. Host Name フィールドで、HTTPS オリジン サーバの IP アドレスまたは完全修飾ドメイン名を指定します。2 つの異なる HTTPS サーバに同じホスト名を指定することはできません。

それぞれのアクティブ サーバには 1 つまたは複数の IP アドレスが関連付けられ、IP アドレスまたは 1 つまたは複数の IP アドレスに解決されるドメイン名として指定されます。Content Engine に着信する HTTPS 要求(WCCP 代行受信または直接プロキシを使用)は、サーバ設定と照合されます。要求のターゲット IP アドレスを、このアクティブ サーバに関連付けられた IP アドレスと比較することで、要求の処理が実行されます。

ステップ 7 Certificate Key/Associations セクションで、次の手順を実行します。

a. Server Certificate ドロップダウン リストから、HTTPS サーバの証明書グループを選択します。HTTPS Certificate Groups for Content Engine ウィンドウを使用して作成した証明書グループが、すべてこのリストに表示されます。

この証明書グループは、SSL クライアントに送信される SSL ハンドシェイクに含まれます。HTTPS サーバに対して一度に選択できる証明書グループは 1 つだけです。SSL バージョン 2 では、証明書グループをサポートしていません。

b. Authenticating Certificate Group ドロップダウン リストから、HTTPS サーバへのアクセスに必要な証明書チェーンと認証を選択します。HTTPS Certificate Groups for Content Engine ウィンドウを使用して作成した証明書グループが、すべてこのリストに表示されます。HTTPS サーバに対して一度に選択できる証明書グループは 1 つだけです。

SSL バージョン 2 では、証明書グループをサポートしていません。

c. Certificate ドロップダウン リストから、クライアントの認証時に Content Engine を HTTPS オリジン サーバとして機能させるための SSL 証明書を選択します。HTTPS Certificates for Content Engine ウィンドウを使用して作成した証明書が、すべてこのリストに表示されます。HTTPS サーバに対して一度に選択できる証明書は 1 つだけです。

d. Private Key ドロップダウン リストから、クライアントの認証時に Content Engine を HTTPS オリジン サーバとして機能させるための秘密鍵を選択します。この秘密鍵は選択された証明書と一致する必要があります。HTTPS Keys for Content Engine ウィンドウを使用して作成した鍵が、すべてこのリストに表示されます。HTTPS サーバに対して一度に選択できる鍵は 1 つだけです。

e. 秘密鍵ファイルが暗号化されている場合は、Private Key Password フィールドにこのファイルを復号化するためのパスワードを指定します。Confirm Password フィールドに、同じパスワードをもう一度入力します。

ステップ 8 General HTTPS Settings セクションでは、次の手順を実行します。

a. SSL cache size フィールドで、SSL セッションのキャッシュ エントリ数を指定します。これは、HTTPS オリジン サーバに接続することなくキャッシュに保存しておける最大エントリ数です。

b. SSL cache Timeout フィールドで、SSL セッションのキャッシュ タイムアウトを秒単位で指定します。この値を超えると、Content Engine はクライアントの認証のためにオリジン サーバに接続します。

c. Protocol Version ドロップダウン リストから、クライアントと HTTPS サーバ間の通信に使用するプロトコル バージョンを選択します。 表8-15 で、使用可能なプロトコル バージョンについて説明します。

d. HTTPS サーバのサーバ証明書認証をイネーブルにするには、 Enable Authentication チェックボックスにチェックマークを付けます。このオプションはデフォルトでイネーブルになっています。

e. 証明書が有効になる前に使用したために発生したエラーを無視するには、
Ignore CertNotNetYetValid Error チェックボックスにチェックマークを付けます。

f. ドメイン名の不一致によるエラーを無視するには、 Ignore DomainName Error チェックボックスにチェックマークを付けます。

g. 証明書の失効によるエラーを無視するには、 Ignore ExpiredDate Error チェックボックスにチェックマークを付けます。

h. 承認されていない CA に対するエラーを無視するには、 Ignore InvalidCA Error チェックボックスにチェックマークを付けます。

 

表8-15 プロトコル バージョン

プロトコル バージョン
説明

SSL v2

SSL バージョン 2 プロトコルのみの使用を適用します。

SSL v23 および TLS v1

SSL バージョン 2 またはバージョン 3 プロトコルおよび TLS(Transport Layer Security)バージョン 1 プロトコルの使用と解釈を適用します。

SSL v3

SSL バージョン 3 プロトコルのみの使用と解釈を適用します。

TLS v1

TLS バージョン 1 プロトコルのみの使用と解釈を適用します。

ステップ 9 この設定値を保存するには、 Submit をクリックします。


 

Content Engine の HTTPS サーバのフィルタリング

Content Distribution Manager GUI を使用すると、HTTPS サーバをフィルタリングして一部だけを表示できます。フィルタリングの条件には、サーバ名、ステータス(イネーブルまたはディセーブル)、ホスト名、SSL キャッシュ サイズ、SSL キャッシュ タイムアウト、プロトコル バージョン、サーバ証明書認証のステータス(イネーブルまたはディセーブル)、およびサーバ証明書認証のエラー追跡のステータス(イネーブルまたはディセーブル)があります。

フィルタ条件を設定して、条件に合った HTTPS サーバを表示する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべてリスト表示されます。

ステップ 2 HTTPS サーバをフィルタリングする Content Engine の横にある Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが開き、左側に Contents ペインが表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTPS > HTTPS Servers の順に選択します。HTTPS Servers for Content Engine ウィンドウが表示されます。

ステップ 4 タスクバーから Filter Table アイコンをクリックします。Filtering HTTPS Server Entries for Content Engine ウィンドウが表示されます。

ステップ 5 Name ドロップダウン リストからフィルタ演算子を選択し、照合するサーバの名前を入力します。

ステップ 6 Enable ドロップダウン リストからフィルタ演算子を選択し、2 番目のドロップダウン リストから HTTPS キャッシングがイネーブルなサーバを表示するかどうかを選択します。

ステップ 7 Host ドロップダウン リストからフィルタ演算子を選択し、照合するホストの IP アドレスまたは完全修飾ドメイン名を入力します。

ステップ 8 SSL cache Size ドロップダウン リストからフィルタ演算子を選択し、照合する SSL キャッシュのサイズを入力します。

ステップ 9 SSL cache Timeout ドロップダウン リストからフィルタ演算子を選択し、照合するタイムアウト(秒単位)を入力します。

ステップ 10 Protocol Version ドロップダウン リストからフィルタ演算子を選択し、照合する通信プロトコルのバージョンを入力します。

ステップ 11 Enable Authentication ドロップダウン リストからフィルタ演算子を選択し、サーバ証明書認証がイネーブルな HTTPS サーバを表示するかどうかを選択します。

ステップ 12 CertNotNetYetValid Error ドロップダウン リストからフィルタ演算子を選択し、証明書が有効になる前に使用したために発生したエラーを無視するよう設定された HTTPS サーバを表示するかどうかを選択します。

ステップ 13 Ignore DomainName Error ドロップダウン リストからフィルタ演算子を選択し、ドメイン名の不一致によるエラーを無視するよう設定された HTTPS サーバを表示するかどうかを選択します。

ステップ 14 Ignore ExpiredDate Error ドロップダウン リストからフィルタ演算子を選択し、証明書の失効によるエラーを無視するよう設定された HTTPS サーバを表示するかどうかを選択します。

ステップ 15 Ignore InvalidCA Error ドロップダウン リストからフィルタ演算子を選択し、承認されていない CA に対するエラーを無視するよう設定された HTTPS サーバを表示するかどうかを選択します。

ステップ 16 Submit をクリックします。HTTPS Servers for Content Engine ウィンドウが再度表示され、指定されたフィルタ条件に一致するサーバがすべて表示されます。

ステップ 17 設定済みの HTTPS サーバの一覧表示画面に戻るには、タスクバーから View All HTTPS Servers アイコンをクリックします。

 

表8-16 HTTPS サーバのフィルタリング

フィルタ演算子
説明

Like

入力されたストリングと同様の設定を持つ HTTPS サーバが含まれます。0 文字以上の任意の文字についてワイルドカード検索を行うにはパーセント記号(%)を使用し、1 文字だけのワイルドカード検索を行うにはアンダースコア(_)を使用します。ストリングに「^」、「,」、「'」などの特殊文字が含まれている場合は、バックスラッシュ(\)をエスケープ文字として使用して、特殊文字の意味を無視します。エスケープ文字の後には「%」と「_」以外の文字を指定できます。エスケープ文字の後のワイルドカード文字は、リテラル文字として処理されます。

たとえば、名前が httpscer で始まり、任意の 1 文字で終る HTTPS サーバを表示するには、Name フィールドに httpscer_ と入力します。Httpscer という名前のサーバは表示されません。

Not like

入力されたストリングと異なる設定を持つ HTTPS サーバが含まれます。0 文字以上の任意の文字についてワイルドカード検索を行うにはパーセント記号(%)を使用し、1 文字だけのワイルドカード検索を行うにはアンダースコア(_)を使用します。ストリングに「^」、「,」、「'」などの特殊文字が含まれている場合は、バックスラッシュ(\)をエスケープ文字として使用して、特殊文字の意味を無視します。エスケープ文字の後には「%」と「_」以外の文字を指定できます。エスケープ文字の後のワイルドカード文字は、リテラル文字として処理されます。

たとえば、名前が httpscer 以外で始まる HTTPS サーバを表示するには、Name フィールドに httpscer と入力します。Httpscer という名前のサーバは表示されます。

In

指定されたストリングのリストと共通の名前を持つサーバが含まれます。ストリングは 1 つだけでも、複数をカンマで区切っても指定できます。指定するストリングにカンマまたは括弧が含まれる場合は、一重引用符(')を使用します。

たとえば、CER1、CER2、CER(3) という名前のサーバを表示するには、Server Name フィールドに (CER1,CER2,'CER(3)') または CER1,CER2,'CER(3)' と入力します。CER4、CER5 などの名前のサーバは表示されません。

Not in

指定されたストリングのリスト以外の設定を持つサーバが含まれます。ストリングは 1 つだけでも、複数をカンマで区切っても指定できます。指定するストリングにカンマまたは括弧が含まれる場合は、一重引用符(')を使用します。

たとえば、CER1、CER2、CER(3) 以外の名前のサーバを表示するには、Server Name フィールドに (CER1,CER2,'CER(3)') または CER1,CER2,'CER(3)' と入力します。CER4、CER5 などの名前のサーバが表示されます。

Equal to

入力されたストリングまたは値と等しい設定、またはドロップダウン リストから選択された項目と一致する設定を持つサーバが含まれます。

たとえば、host1 というホスト名の HTTPS サーバを表示するには、Host フィールドに host1 と入力します。host2 というホスト名の HTTPS サーバは表示されません。キーワード、特殊文字、またはワイルドカード文字は使用できません。

Not equal to

入力されたストリングまたは値と等しくない設定、またはドロップダウン リストから選択された項目と一致しない設定を持つサーバが含まれます。

たとえば、SSLv2 プロトコル バージョンのみに対応する HTTPS サーバ以外を表示するには、Protocol Version フィールドに SSL v2 と入力します。SSLv3 プロトコル バージョンのみに対応する HTTPS サーバはすべて表示されます。キーワード、特殊文字、またはワイルドカード文字は使用できません。

Greater than

入力された値を上回る SSL キャッシュ サイズ、SSL キャッシュ タイムアウト、プロトコル バージョンを適用されたサーバが含まれます。

たとえば、SSL セッションのキャッシュ エントリ数が 1000 を超える HTTPS サーバを表示するには、SSL cache size フィールドに 1000 と入力します。キャッシュ サイズが 1000 未満の HTTPS サーバは表示されません。

Less than

入力された値未満の SSL キャッシュ サイズ、SSL キャッシュ タイムアウト、プロトコル バージョンを適用されたサーバが含まれます。

たとえば、SSL セッションのキャッシュ タイムアウトが 1000 秒未満の HTTPS サーバを表示するには、SSL cache timeout フィールドに 1000 と入力します。キャッシュ タイムアウトが 1000 秒以上の HTTPS サーバは表示されません。

Greater than or equal to

入力された値以上の SSL キャッシュ サイズ、SSL キャッシュ タイムアウト、プロトコル バージョンを適用されたサーバが含まれます。

たとえば、SSL セッションのキャッシュ エントリ数が 1000 を超える HTTPS サーバを表示するには、SSL cache size フィールドに 1000 と入力します。キャッシュ サイズが 1000 未満の HTTPS サーバは表示されません。

Less than or equal to

入力された値以下の SSL キャッシュ サイズ、SSL キャッシュ タイムアウト、プロトコル バージョンを適用されたサーバが含まれます。

たとえば、SSL セッションのキャッシュ タイムアウトが 1000 秒以下の HTTPS サーバを表示するには、SSL cache timeout フィールドに 1000 と入力します。キャッシュ タイムアウトが 1000 秒を上回る HTTPS サーバは表示されません。

 


 

SSL を使用した透過 HTTPS キャッシング

SSL 終端を使用した HTTPS クライアント要求のキャッシングでは、Content Engine による SSL 暗号化データの復号化が必要です。SSL 暗号化データを復号化すると、Content Engine では HTTPS クライアント要求をプレーン テキストとして処理し、このような要求に対してさまざまな HTTP 処理作業(キャッシング、ルール プロセッシング、フィルタリングなど)を実行できます。

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

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

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

3. クライアントからネゴシエートされた SSL 接続を使って HTTPS 要求が送信されます。

4. Content Engine でその要求を検証し、キャッシュ内を調べてから、通常の HTTP 要求処理を実行します。

5. Content Engine が自身のローカル ストレージから要求に応えることができる場合(キャッシュ ヒット)、要求されたコンテンツを SSL 接続を使って送信します。

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

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

SSL 終端機能が正常に機能するには、Content Engine に HTTPS オリジン サーバの SSL 証明書と秘密鍵をインストールする必要があります。Content Engine に有効な証明書と秘密鍵がインストールされていると、SSL 終端機能は透過モードとプロキシ モードの両方で動作します。特定の要求コンテンツをキャッシュするには、これらの HTTPS オリジン サーバに対する有効な証明書と鍵を Content Engine にインポートし、対象となる HTTPS オリジン サーバからコンテンツをキャッシュするように Content Engine を設定します。詳しくは、「HTTPS 証明書の設定」を参照してください。

HTTP と HTTPS 発信プロキシの除外の設定

透過キャッシング モードでは、Content Engine は別のプロキシに送信された要求を代行受信して、これらの要求を次の 2 つの宛先のいずれかに送信できます。

Default server ― これがデフォルト オプションです。Content Engine は、Web サーバから直接オブジェクトを取得するか、あるいは指定のプロトコルに対して発信プロキシを使用するように設定されている場合は、要求を発信プロキシに転送します。このシナリオでは、クライアント ブラウザの設定は無視され、サーバからオブジェクトを取得するために Content Engine の設定が使用されます。

Original proxy ― Content Engine はクライアントによる要求の本来の宛先であるプロキシに要求を転送します。このプロキシは、指定のプロトコルに対して Content Engine 自体で設定されている発信プロキシとは異なる可能性があります。

ACNS 5.x ソフトウェアでは、プロキシ転送からグローバルに除外される単一のドメイン名、ホスト名、または IP アドレスを管理者が指定することもできます。ドメインは、スペースで区切って ASCII ストリングとして入力します。IP アドレスにはワイルドカード文字 *(アスタリスク)を使用できます(例: 172.16.*.*)。ワイルドカード文字を含む宛先を指定した場合、要求は Content Engine プロキシおよびフェールオーバー プロキシをバイパスします。

プロキシ プロトコルのパラメータを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 設定する Content Engine の名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > Outgoing Proxy Exclusions の順に選択します。Outgoing Proxy Exclusions ウィンドウが表示されます(図8-11 を参照)。 表8-17 で、このウィンドウ内のフィールドについて説明します。

図8-11 Outgoing Proxy Exclusions 設定ウィンドウ

 

ステップ 4 別のプロキシに送信された要求を代行受信し、これらの要求をオリジン サーバまたは指定のプロキシ サーバに送信するには、 Enable Outgoing Proxy Exclusion チェックボックスにチェックマークを付けます。

ステップ 5 Outgoing Proxy Exclude List フィールドに、ドメイン名、IP アドレス、またはホスト名を、それぞれスペースで区切って入力します。ここに入力した項目は、プロキシ転送からグローバルに除外されます。また、アスタリスク(*)をワイルドカード文字として指定し、任意の条件に一致する IP アドレスを除外できます。

ステップ 6 プロキシ スタイルの要求に透過モードでの動作を設定するには、 Enable Transparent Mode チェックボックスにチェックマークを付けます。

ステップ 7 Transparent Proxy Mode ドロップダウン リストから、 default-server original-proxy 、または reset を選択します。 表8-17 で、これらのオプションについて説明します。

 

表8-17 プロキシ プロトコルの主要パラメータ

主要パラメータ
機能
CLI コマンド

Default-server

Content Engine は、Web サーバから直接オブジェクトを取得します。このオプションを使用すると、発信プロキシ サーバが設定されている場合は、プロキシ スタイル要求を発信プロキシ サーバに送信できます。発信プロキシ サーバが設定されない場合、要求はオリジン サーバと Content Engine によって処理されます。

proxy-protocols transparent default-server

Original-proxy

Content Engine は、クライアントが本来要求の宛先として指定したプロキシに要求を転送します。

proxy-protocols transparent original-proxy

Reset

透過プロキシ モードをリセットして、デフォルト サーバを使用します。キャッシュ ミス時に要求はクライアントに返されます。このモードでは、クライアントは要求されたオブジェクトを取得しません。

proxy-protocols transparent reset

ステップ 8 この設定値を保存するには、 Submit をクリックします。

デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。


) タスクバー内のアイコンを使用して実行できるほかの操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

FTP の設定

Content Engine およびデバイス グループの FTP 設定を実行、変更、および表示するには、次の作業を実行します。

「FTP-over-HTTP 接続の設定」

「FTP-over-HTTP キャッシュ フレッシュネスの設定」

「ネイティブ FTP 接続の設定」

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

「ネイティブ FTP キャッシュのフレッシュネス設定」

「Inetd FTP サービスのイネーブル化」

「ネイティブ FTP カスタム メッセージの設定」

Content Engine では、次の 2 つのモードで FTP キャッシングを設定できます。

FTP-over-HTTP モード。Content Engine(非透過フォワード プロキシ サーバ)は、HTTP プロトコルを使用するクライアントから、自身に対して直接送信された特定の FTP URL のコンテンツをキャッシュします。このモードを使用すると、ユーザは自分のブラウザ(HTTP プロトコル)を使用して、リモート FTP サーバ上のファイルにアクセス(ファイルを送受信)できます。

ネイティブ FTP モード。Content Engine は、ネイティブ FTP プロトコルでクライアントから送信された FTP 要求のコンテンツをキャッシュします。ACNS 5.4 では、ネイティブ FTP キャッシングは透過および非透過プロキシ モードでサポートされています(ACNS 5.1 および 5.2 ソフトウェア リリースでは、ネイティブ FTP キャッシングは透過プロキシ モードでのみサポートされていました)。

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


) FTP 要求の透過リダイレクトは、WCCP バージョン 2 のみでサポートされています。レイヤ 4 スイッチを使用した透過リダイレクトはサポートされていません。



) ACNS 5.3.1 ソフトウェアでは、FTP 関連コマンドに次の変更が行われました。

show ftp proxy EXEC コマンドは、 show ftp-native および show ftp-over-http に置き換えられています。

show statistics ftp EXEC コマンドは、 show statistics ftp-over-http および show statistics ftp-native に置き換えられています。

clear statistics ftp EXEC コマンドは、 clear statistics ftp-over-http および clear statistics ftp-native に置き換えられています。


 

FTP-over-HTTP キャッシング

ACNS 5.4 ソフトウェアでは、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 プロキシ サーバ(設定されている場合)から、またはオリジン FTP サーバから直接オブジェクトを取得します。

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

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

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

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

FTP-over-HTTP 接続の設定

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

Content Distribution Manager GUI を使用して FTP-over-HTTP 接続を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Device Groups の順に選択します。デバイス グループを作成した場合は、Device Group ウィンドウが表示されます(または、 Devices > Devices の順に選択します)。

ステップ 2 設定するデバイス グループ(または Content Engine)の名前の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 Contents ペインから、 Applications > Web > FTP > FTP Over HTTP Connections の順に選択します。FTP Connection Settings ウィンドウが表示されます(図8-12 を参照)。 表8-18 で、このウィンドウ内のフィールドについて説明します。

図8-12 FTP-Over-HTTP Connection Settings for Device Group ウィンドウ

 

ステップ 4 Anonymous FTP Password フィールドをアクティブにするには、 Enable Proxy Caching チェックボックスにチェックマークを付けます。

ステップ 5 Content Engine を FTP アクティブ モードで実行するには、 Enable Incoming Active Mode チェックボックスにチェックマークを付けます。アクティブ モードがイネーブルになると、Content Engine はアクティブ モードでオブジェクトの取得を試行します。アクティブ モードで失敗すると、Content Engine は再度パッシブ モードでオブジェクトの取得を試行します。

ステップ 6 ポート 80 以外のポートでも FTP-over-HTTP 着信要求を受け入れるには、 Enable Incoming Proxy チェックボックスにチェックマークを付けます。

ステップ 7 List of Incoming Ports フィールドに、FTP プロキシ サーバまたは Content Engine が要求を受信するために使用するポート番号を入力します。範囲は 1~65535 で、最大 8 つのポートを指定できます。

ステップ 8 Anonymous FTP Password フィールドに、FTP プロキシ サーバへのアクセスに必要な anonymous パスワード(wwwuser@cisco.com など)を入力します。デフォルトは anonymous@hostname です。

ステップ 9 Confirm Anonymous FTP Password フィールドに、FTP プロキシ サーバへのアクセスに必要な anonymous パスワードをもう一度入力します。

ステップ 10 発信プロキシ サーバまたは別の Content Engine で FTP キャッシュ ミスの要求トラフィックを受信するには、 Enable Outgoing Proxy チェックボックスにチェックマークを付けます。

ステップ 11 すべての発信プロキシ サーバが故障した場合にオリジン サーバを使用するには、 Use Origin Server チェックボックスにチェックマークを付けます。このチェックボックスにチェックマークを付けると、設定されているすべてのプロキシ サーバが故障した場合に、Content Engine では状況に応じて、FTP ヘッダー内で指定されているオリジン サーバに FTP 要求をリダイレクトできます。このオプションがイネーブルでない場合、クライアントはエラー応答を受信します。このとき、応答エラーと読み取りエラーがクライアントに返されます。これは、これらのエラーがオリジン サーバまたはプロキシのどちらで生成されたかが検出できないためです。

ステップ 12 Outgoing Connection Timeout フィールドにマイクロ秒単位で値を入力します。この値は、発信プロキシ サーバがアクティブであるかどうかをプローブするまでのマイクロ秒数を指定します。

ステップ 13 Content Engine が指定された発信 FTP プロキシ サーバをポーリングする頻度を指定するには、Outgoing Monitor Period フィールドに値を入力します。

Content Engine は、設定された発信プロキシ サーバの状態をバックグラウンドで監視します。指定された発信プロキシ サーバを特定の時間にポーリングするように Content Engine を設定して、サーバのアベイラビリティを監視できます。Outgoing Monitor Period は、プロキシ サーバをポーリングする時間です。モニタリング時間は 10~300 秒までの秒単位で指定できます。デフォルトのモニタリング時間は 60 秒です。発信プロキシ サーバの 1 台が使用不能である場合、ポーリング メカニズムによって接続がタイムアウト値(300000 マイクロ秒)に達するまで待機してから、次の発信プロキシ サーバにポーリングします。

ステップ 14 Outgoing Proxy Host Name フィールドに、発信 FTP プロキシのホスト名または IP アドレスを入力します。

ステップ 15 Outgoing Proxy Port フィールドに、ステップ 14 で指定した発信プロキシのホスト名に対応するポート番号を入力します。範囲は 1~65535 で、最大 8 つのポートを指定できます。プロキシ モードでは、Content Engine は指定のポートでのみ FTP 要求を受け入れ、処理します。他のプロキシ モードのポートでは、 FTP 要求はすべて拒否されます。

Content Engine は、anonymous と認証済み FTP 要求の両方をサポートします。URL が
ftp://user@site/dir/file の場合、プロキシは認証失敗応答を返し、ブラウザにはログイン情報の入力を求めるポップアップ ウィンドウが表示されます。

ステップ 16 この設定値を保存するには、 Submit をクリックします。

デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 

表8-18 FTP-over-HTTP 接続の設定

GUI パラメータ
機能
CLI コマンド

Enable Proxy Caching

Anonymous FTP Password フィールドをイネーブルにします。

--

Enable Incoming Active Mode

FTP アクティブ モードをサポートするように Content Engine を設定します。デフォルトはパッシブ モードです。

ftp-over-http proxy active-mode enable

Enable Incoming Proxy

ポート 80 以外のポートでも着信 FTP 要求を受け入れるように Content Engine を設定します。

ftp-over-http proxy incoming portnum

List of Incoming Ports

プロキシ サーバまたは Content Engine が FTP 要求を受信するために使用するポート番号。この番号の範囲は 1 ~ 65535 です。最大 8 つのポートを指定できます。

Anonymous FTP Password

発信 FTP プロキシ サーバへのアクセスに必要なパスワード

ftp-over-http proxy anonymous-pswd password

Confirm Anonymous FTP Password

発信 FTP プロキシ サーバへのアクセスに必要なパスワードをもう一度入力します。

--

Enable Outgoing Proxy

FTP キャッシュ ミスの要求トラフィックを受信するように、発信プロキシ サーバまたは別の Content Engine を設定します(ICP または WCCP を使用しない)。

ftp-over-http proxy outgoing

Use Origin Server

イネーブルにすると、すべての発信プロキシ サーバが故障した場合に、オリジン サーバを使用して要求を処理します。これをディセーブルにすると、すべての発信プロキシ サーバが故障した場合に、ユーザはエラー メッセージを受け取ります。

ftp-over-http proxy outgoing origin-server

Outgoing Connection Timeout

発信プロキシ サーバのプローブ時に使用するタイムアウト時間(マイクロ秒)。範囲は 200~5000000 です。デフォルト値は 300 マイクロ秒です。

ftp-over-http proxy outgoing connection-timeout microsecs

Outgoing Monitor Period

1 台の発信プロキシ サーバを監視する間隔(秒単位)を指定します。複数の発信プロキシ サーバが設定されている場合、これらは順次監視されます。デフォルト値は 200 秒です。

ftp-over-http proxy outgoing monitor seconds

Outgoing Proxy Hostname 1-8

複数の発信プロキシ サーバを設定します。発信 FTP プロキシ サーバのホスト名または IP アドレスを入力します。

ftp-over-http proxy outgoing host { hostname | ipaddress }

Outgoing Proxy Port 1-8

発信 FTP プロキシのホスト名に対応するポート番号

ftp-over-http proxy outgoing host { hostname | ipaddress } portnum


) タスクバー内のアイコンを使用して実行できるほかの操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

FTP-over-HTTP キャッシュ フレッシュネスの設定

Content Distribution Manager GUI の FTP Cache Freshness Settings ウィンドウを使用すると、ACNS ネットワーク上の Content Engine に対して、FTP キャッシュ オブジェクトのフレッシュネス パラメータを設定できます。これらのパラメータは、ディレクトリのリスト項目またはキャッシュ内の特定のオブジェクトのいずれかについて設定できます。

FTP フレッシュネス パラメータを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Device Groups の順に選択します。デバイス グループを作成した場合は、Device Group ウィンドウが表示されます(または、 Devices > Devices の順に選択します)。

ステップ 2 設定するデバイス グループ(または Content Engine)の名前の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 Contents ペインから、 Applications > Web > FTP > FTP Over HTTP Cache Freshness の順に選択します(図8-13 を参照)。 表8-20 で、このウィンドウ内のフィールドについて説明します。

図8-13 FTP-Over-HTTP Cache Freshness Settings ウィンドウ

 

ステップ 4 Content Engine で FTP キャッシュ フレッシュネス設定を有効にするには、 Enable チェックボックスにチェックマークを付けます。

ステップ 5 Directory Listing Age Multiplier フィールドの値を指定します。

この経過時間係数の値を指定すると、オブジェクトの前回の修正時点から経過した時間に特定のパーセント値を掛け、おおよその有効期限日を算出することで、Content Engine ではディレクトリの存続時間を推定できます。この日付を過ぎるとオブジェクトは古いものとみなされ、以降に要求があったときには、Content Engine によって新たにオブジェクトが取得されます。有効な値は 0~100% です。デフォルト値は 30% です。

ステップ 6 File Object Age Multiplier フィールドの値を指定します。

この経過時間係数の値を指定すると、オブジェクトの前回の修正時点から経過した時間に特定のパーセント値を掛け、おおよその有効期限日を算出することで、Content Engine ではテキスト オブジェクトの存続時間を推定できます。この日付を過ぎるとオブジェクトは古いものとみなされ、以降に要求があったときには、Content Engine によって新たにオブジェクトが取得されます。有効な値は 0~100% です。デフォルト値は 60% です。

ステップ 7 Max Time to Live(TTL)Scale ドロップダウン リストから、 days hours minutes 、または seconds を選択します。

TTL では、推定有効期限日が上限値として設定されます。オブジェクトに有効期限日が明示的に指定されている場合は、その日付がここで設定した TTL よりも優先されます。

ステップ 8 Max Directory Listing TTL フィールドの値を指定します。 表8-19 に、有効な値の範囲を示します。

 

表8-19 FTP フレッシュネスの TTL 値の範囲

単位時間
範囲

1 ~ 1825

1 ~ 43800

1 ~ 2628000

1 ~ 157680000

ステップ 9 Max File Object TTL フィールドの値を指定します。

使用する単位時間に応じた最大値については、 表8-19 を参照してください。

ステップ 10 Minimum TTL フィールドの値(分単位)を指定します。

Minimum TTL は、キャッシュ内のオブジェクトの最小存続可能時間です。値の範囲は、0~86400 分です。デフォルト値は 30 分です。

ステップ 11 次のステップで指定する最大オブジェクト サイズを適用するには、 Enforce Max Object Size チェックボックスにチェックマークを付けます。

ステップ 12 Max Object Size フィールドの値を指定します。

この値は、保存可能な最大オブジェクト サイズ(KB 単位)を表します。値の範囲は、1~204800 KB です。デフォルト値は、最大の 1048576 KB に設定されています。

ステップ 13 Re-eval Request ドロップダウン リストから、再評価要求の処理方法を選択します。

これらの FTP キャッシュ フレッシュネス パラメータは、ディレクトリのリスト項目
directory-listing )に適用するか、またはオブジェクトおよびディレクトリのリスト項目の両方( all )に適用することができます。TTL 値をこれらのパラメータに適用しない( none )こともできます。この場合、TTL は適用されず、キャッシュ内のオブジェクトに有効期限日は設定されません。

ステップ 14 この設定値を保存するには、 Submit をクリックします。

デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 

表8-20 FTP-over-HTTP Cache Freshness 設定

GUI パラメータ
機能
CLI コマンド

Enable

キャッシュ フレッシュネスの設定をイネーブルにします。

--

Directory Listing Age Multiplier

オブジェクトの前回の修正時点から経過した時間に特定のパーセント値を掛け、おおよその有効期限日を算出することで、Content Engine ではディレクトリの存続時間を推定できます。

ftp-over-http age-multiplier directory-listing dl_time file fo_time

File Object Age Multiplier

オブジェクトの前回の修正時点から経過した時間に特定のパーセント値を掛け、おおよその有効期限日を算出することで、Content Engine ではオブジェクトの存続時間を推定できます。

Max TTL Scale

ディレクトリ リスト項目またはファイル オブジェクトについて、最大 TTL の単位時間を設定します。

ftp-over-http max-ttl { days directory-listing dlmax_days file fmax_days | hours directory-listing dlmax_hours file fmax_hours | minutes directory-listing dlmax_min file fmax_min | seconds directory-listing dlmax_sec file fmax_sec }

Max Directory Listing TTL

ディレクトリ リスト項目の推定有効期限日に上限を設けます。

Max File Object TTL

ファイル オブジェクトの推定有効期限日に上限を設けます。

Minimum TTL

キャッシュ内のオブジェクトの最小 TTL

ftp-over-http min-ttl min_minutes

Enforce Max Object Size

指定された最大サイズを超えるオブジェクトをキャッシュしません。

ftp-over-http object max-size size

Max Object Size

保存できるオブジェクトの最大サイズ(KB 単位)

Re-eval Requests

再評価要求の処理方法を設定します。

ftp-over-http reval-each-request { all | none | directory-listing }


) タスクバー内のアイコンを使用して実行できるほかの操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

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

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

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

ACNS 5.4 ソフトウェアにおけるネイティブ FTP キャッシングに関する制限

ネイティブ FTP キャッシングのサポートに関しては、次の制約事項があります。

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

FTP クライアント要求と FTP サーバ プルに対する帯域幅の制御はサポートされていません。

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

cdnfs では事前配信ファイルはサポートされていません。

Internet Content Adaptation Protocol(ICAP)はサポートされていません。

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

Internet Cache Protocol(ICP)はサポートされていません。

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

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

FTP 要求のプロキシ ルールはサポートされていません。

MIN-TTL と AGING-HEURISTIC-TTL のキャッシュ制御ノブの設定はサポートされていません。

URL フィルタリング方式(good リスト、bad リスト、N2H2、Websense、SmartFilter)はサポートされていません。

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

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

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

透過モードでのネイティブ FTP キャッシングに対して Content Engine を設定するには、WCCP FTP ネイティブ サービス(サービス 60)を Content Engine 上で有効にする必要があります。FTP サービスは、WCCP バージョン 2 ルータによって、ネイティブ FTP 要求を透過的に Content Engine 上の単一ポートにリダイレクトするのを許可する WCCP キャッシング サービスです。Content Engine は要求された FTP コンテンツを取得し、コピーをローカルに保存し(ネイティブ FTP キャッシングを実行し)、要求されたコンテンツをクライアントに配信します。

透過ネイティブ FTP キャッシング用に WCCP サービスを設定する方法については、「Content Engine の WCCP のサービス設定」を参照してください。

ネイティブ FTP 接続の設定

ネイティブ FTP 接続を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices (または Devices > Device Groups )の順に選択します。

ステップ 2 設定する Content Engine またはデバイス グループの名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > FTP > Native FTP Connections の順に選択します。Native FTP Connections Settings ウィンドウが表示されます。 表8-21 で、このウィンドウ内のフィールドについて説明します。

ステップ 4 Content Engine をネイティブ FTP アクティブ モードで実行するには、 Enable Active Mode チェックボックスにチェックマークを付けます。アクティブ モードがイネーブルで、FTP クライアントがアクティブ モード データ転送要求を発行した場合、Content Engine はアクティブ モードでオブジェクトの取得を試行します(ネイティブ FTP アクティブ モードおよびパッシブ モードの概要を参照)。

ステップ 5 ネイティブ FTP プロキシ認証を有効にするには、 Enable Authentication チェックボックスにチェックマークを付けます( ネイティブ FTP 要求の認証の概要を参照)。

ステップ 6 ポート 21(標準 FTP ポート)以外のポートでも着信ネイティブ FTP 要求を受け入れるには、 Enable Incoming Proxy チェックボックスにチェックマークを付けます。

ステップ 7 List of Incoming Ports フィールドで、最大 8 個までの着信ポート番号を、スペースで区切って指定します(例:8021、9021 など)。

ステップ 8 この設定値を保存するには、 Submit をクリックします。

 

表8-21 ネイティブ FTP 接続設定

GUI パラメータ
機能
CLI コマンド

Enable Active Mode

Content Engine をネイティブ FTP アクティブ モードで実行します。

ftp-native proxy active-mode enable

Enable Authentication

ネイティブ FTP プロキシ認証をイネーブルにします。デフォルトはディセーブルです( ネイティブ FTP プロキシ認証設定時の考慮事項を参照)。

ftp-native proxy authentication enable

Enable Incoming Proxy

ポート 21 以外のポートでも着信ネイティブ FTP 要求をイネーブルにします。

ftp-native proxy incoming portnum portnum ...

List of Incoming Ports

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

 


 

ネイティブ FTP アクティブ モードおよびパッシブ モードの概要

FTP プロキシとして動作している Content Engine は、ファイルおよびディレクトリを取得する場合、パッシブ モードおよびアクティブ モードをサポートします。ネイティブ FTP キャッシング モードでは、アクティブ モードがイネーブルになっている場合、Content Engine は FTPサーバ とのデータ接続に関して、クライアントがその Content Engine へのアクセスに使用したのと同じモードを使用します。このとき、Content Engine はアクティブ モードとパッシブ モードのいずれでもかまいません。

アクティブ モードが有効になっていない場合、Content Engine はオリジン FTP サーバとのデータ接続に関して、パッシブ モードを使用します。

Content Engine でネイティブ FTP に対してクライアントのモード(アクティブまたはパッシブ)を引き継ぐと、次のようなことが発生します。

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

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

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

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

ファイル転送モードがバイナリ モードの場合、ストリング「;type=i」が URL の最後に含まれます。次に、バイナリ モードで 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 が NAT の後方に設置されている場合は、FTP クライアントとネイティブ FTP プロキシ間のパッシブ モードの転送は行われません。これは、NAT ファイアウォールによって Content Engine でコンジット IP アドレスを割り出すことがブロックされるためです。


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

非透過 FTP プロキシ サーバとして動作する Content Engine は、Reflection X クライアント、WS-FTP クライアント、および Unix または DOS のコマンドライン FTP プログラムなどの FTP クライアントからのネイティブ FTP 要求を受け入れます。ここでは、Content Engine(各種 FTP クライアントに対して非透過 FTP プロキシ サーバとして動作している)に直接ネイティブ FTP 要求を送信するために、これらのタイプの異なる FTP クライアントの設定例を示します。Content Engine へのプロキシ FTP 要求をクライアント側で設定する方法については、『Cisco ACNS Software Configuration Guide for Locally Managed Deployments』Release 5.4を参照してください。

次に、UNIX コマンドライン FTP プログラムを使用して、非透過 FTP プロキシ サーバとして動作する Content Engine へのプロキシ FTP 要求をクライアント側で設定する例を示します。この例では、10.9.192.10 は、FTP クライアントの IP アドレスで、10.9.192.11 は Content Engine の IP アドレスです。サーバの IP アドレス(abchost.company.com)は、FTP クライアントには表示されません。

この例では、FTP クライアントが FTP クライアント マシン上のローカル ポートを開放し、データ転送を行うために Content Engine がそのポートに接続します。クライアントがローカル ポートを開放する場合、このデータ転送を「アクティブ モード」転送といいます(この例では、「パッシブ モード」データ転送は示されていませんが、その場合、Content Engine が Content Engine 上のポートを開放し、クライアントに該当するポートに接続するように要求します)。

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

ネイティブ FTP キャッシュのフレッシュネス設定

ネイティブ FTP キャッシュのフレッシュネスを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices (または Devices > Device Groups )の順に選択します。

ステップ 2 設定する Content Engine またはデバイス グループの名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > FTP > Native FTP Cache Freshness の順に選択します。Native FTP Cache Freshness Settings ウィンドウが表示されます。

ステップ 4 Max Object Size フィールドの値を指定します。

この値は、保存可能な最大オブジェクト サイズ(KB 単位)を表します。値の範囲は、1~204800 KB です。デフォルト値は 4 KB です。

ステップ 5 この設定値を保存するには、 Submit をクリックします。


 

CLI からネイティブ FTP キャッシュのフレッシュネスを設定するには、 ftp-native object max-size コマンドを使用します。

Inetd FTP サービスのイネーブル化

Inetd(インターネット デーモンのこと。「アイ ネット ディー」と発音)は、特定のポートについて接続要求またはメッセージを待ち受けるプログラムで、これらのポートに関連するサービスを実行するためのサーバプログラムを開始します。

Inetd FTP サービスをイネーブルにする手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Device Groups の順に選択します。デバイス グループを作成した場合は、Device Group ウィンドウが表示されます(または、 Devices > Devices の順に選択します)。

ステップ 2 設定するデバイス グループ(または Content Engine)の名前の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 Contents ペインから、 Applications > Web > FTP > Inetd FTP の順に選択します。Inetd FTP Settings ウィンドウが表示されます。

ステップ 4 Content Engine で FTP サービスをイネーブルにするには、 Inetd Enable FTP Service チェックボックスにチェックマークを付けます。

ステップ 5 この設定値を保存するには、 Submit をクリックします。


 

CLI から Inetd FTP サービスをイネーブルにするには、 inetd enable ftp グローバル コンフィギュレーション コマンドを使用します。

ネイティブ FTP カスタム メッセージの設定

ACNS 5.4 ソフトウェアは、FTP プロキシの初期メッセージおよび ACL 拒否メッセージのカスタマイズをサポートします。ユーザは Content Engine にカスタム メッセージ ファイルをダウンロードし、リモート ホスト サーバにメッセージをアップロードできます。初期メッセージは、クライアントがプロキシ モードで Content Engine に接続した場合に、クライアントに返される FTP 応答です。ACL 拒否メッセージは、クライアントが設定済みの Access Control List(ACL; アクセス制御リスト)によってアクセスを拒否された場合に、クライアントに返される FTP 応答です(ACL の詳細設定については、 第 17 章「IP ACL の作成と管理」 を参照してください)。

FTP カスタム初期メッセージの記述の概要

プロキシ認証をイネーブルにする場合、ユーザがオリジン サーバにログインする前に、初期メッセージを使用してプロキシでの認証を求める必要があります。次に、その例を示します。

Welcome to ce-Boxman. BigCorp’s Content Engine for Native FTP Proxy. Please login to the proxy with your username and password.
 

また、プロキシ認証をイネーブルにしない場合、初期メッセージを使用して、ユーザに USER または SITE 方式でオリジン サーバへログインするよう通知する必要があります。次に、その例を示します。

Welcome to ce-Boxman. BigCorp’s Content Engine for Native FTP Proxy. Please login to the origin server using the 'username@server-hostname' format.
 
Welcome to ce-Boxman. BigCorp’s Content Engine for Native FTP Proxy. Please login to the origin server using the 'SITE server-hostname' command followed by the 'USER username' command.
 

FTP メッセージのダウンロードの設定

初期メッセージと ACL 拒否メッセージはデバイス グループ全体に設定したり、個々の Content Engine に設定したりできます。各メッセージ タイプは 1 つだけ Content Engine に設定できます。そのため、デバイス グループで Content Engine にメッセージを設定した場合、グループ内の個々の Content Engine に新しい FTP メッセージを設定することはできません。Content Engine にすでに FTP メッセージが存在している場合に、さらにメッセージを作成しようとすると、Content Distribution Manager GUI によって警告メッセージが表示されます。

Content Engine にメッセージをダウンロードするには、次の手順に従います。


ステップ 1 Content Distribution Manager GUI から、 Devices > Device Groups の順に選択します。

ステップ 2 設定するデバイス グループの横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > FTP > FTP Messages > Download の順に選択します。FTP Message Download for Device Group ウィンドウが表示されます。

ステップ 4 FTP Message ドロップダウン リストから、メッセージ タイプを選択します( welcome または acl-denied )。

ステップ 5 Download URL フィールドで、Content Engine に取得させるメッセージ ファイルの URL を入力します。HTTP、HTTPS、FTP プロトコルだけがサポートされます。

ステップ 6 この設定値を保存するには、 Submit をクリックします。メッセージが表示され、ファイル サイズを 16 KB以下にするよう求められます。続行する場合、 OK をクリックします。Content Engine は、その URL からメッセージを取得します。


 

CLI からネイティブ FTP カスタム メッセージをダウンロードするには、 ftp-native custom-message download EXEC コマンドを使用します。

Content Engine の FTP メッセージ設定の表示

個々の Content Engine の FTP メッセージを表示するには、次の手順に従います。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 表示する Content Engine の Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > FTP > FTP Messages > Download の順に選択します。FTP Message Download for Content Engine ウィンドウが表示されます。

ステップ 4 Content Engine のデバイス グループから設定したり、個々の Content Engine から設定したものも含めてFTP メッセージ設定をすべて表示するには、 Aggregate Settings:Yes オプション ボタンをクリックします。

Content Engine のみに設定されたメッセージは、リスト項目の隣にある Edit アイコンで特定できます。

Content Engine のデバイス グループから設定されたメッセージは、リスト項目の隣にある View only アイコンで特定できます。

ステップ 5 個々の Content Engine に設定されている FTP メッセージのみを表示するには、 Aggregate Settings:No オプション ボタンをクリックします。


 

ネイティブ FTP カスタム メッセージのリセット

ネイティブ FTP カスタム初期メッセージまたは ACL 拒否メッセージを変更する場合、リセット(または削除)オプションを使用します。メッセージをリセットするには、次の手順に従います。


ステップ 1 個々のデバイスからメッセージ設定をリセットするには、 Devices > Devices の順に選択し、Content Engine の Edit アイコンをクリックします。

ステップ 2 Contents ペインから、 Applications > Web > FTP > FTP Messages > Download の順に選択します。FTP Message Download for Content Engine ウィンドウが表示されます。

ステップ 3 個々の Content Engine に設定されているすべてのメッセージをリセットするには、タスクバーの Trash アイコンをクリックします。このアクションを確認するには、 OK をクリックします。

ステップ 4 初期メッセージだけをリセットするには、初期メッセージの Edit アイコンをクリックします。Modifying FTP Message for Content Engine ウィンドウで、タスクバーの Trash アイコンをクリックします。このアクションを確認するには、 OK をクリックします。

ステップ 5 ACL 拒否メッセージだけをリセットするには、ACL 拒否メッセージの Edit アイコンをクリックします。Modifying FTP Message for Content Engine ウィンドウで、タスクバーの Trash アイコンをクリックします。このアクションを確認するには、 OK をクリックします。

ステップ 6 デバイス グループのメッセージ設定をリセットするには、 Devices > Device Groups の順に選択します。

ステップ 7 設定するデバイス グループの横にある Edit アイコンをクリックします。

ステップ 8 Contents ペインから、 Applications > Web > FTP > FTP Messages > Download の順に選択します。FTP Message Download for Device Group ウィンドウが表示されます。

ステップ 9 デバイス グループに設定したすべてのメッセージをリセットするには、タスクバーの Trash アイコンをクリックします。このアクションを確認するには、 OK をクリックします。

ステップ 10 初期メッセージだけをリセットするには、初期メッセージの Edit アイコンをクリックします。
Modifying FTP Message for Device Group ウィンドウで、タスクバーの Trash アイコンをクリックします。このアクションを確認するには、 OK をクリックします。

ステップ 11 ACL 拒否メッセージだけをリセットするには、ACL 拒否メッセージの Edit アイコンをクリックします。Modifying FTP Message for Device Group ウィンドウで、タスクバーの Trash アイコンをクリックします。このアクションを確認するには、 OK をクリックします。


 

CLI からネイティブ FTP カスタム メッセージをリセットするには、 ftp-native custom-message reset { acl-denied | all | welcome } EXEC コマンドを使用します。

ネイティブ FTP カスタム メッセージのアップロード設定


) アップロード設定は、メッセージ ファイルのダウンロード設定が済んでいる場合のみ設定できます。また、アップロード設定は、個々のデバイスに対してのみ設定できます(デバイス グループについてはアップロード機能がサポートされていません)。


カスタム メッセージ ファイルを Content Engine からリモート サーバにアップロードするには、次の手順に従ってネイティブ FTP カスタム メッセージのアップロードを設定します。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 設定する Content Engine の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > FTP > FTP Messages > Upload の順に選択します。FTP Message Upload Settings for Content Engine ウィンドウが表示されます。

ステップ 4 FTP Message ドロップダウン リストから、メッセージ タイプを選択します( welcome または acl-denied )。

ステップ 5 カスタム メッセージ ファイルを FTP プロトコルを使用して指定のホスト、ディレクトリ、およびファイル名にアップロードするには、次の設定を完了します。

FTP Server Address フィールドに、メッセージ ファイルをアップロードするリモート ホストのホスト名、または IP アドレスを入力します。

FTP Server Directory フィールドに、ホスト サーバのディレクトリ名を入力します。

FTP Server Filename フィールドに、ファイル名を入力します。

ステップ 6 FTP Server Username フィールドに、リモート FTP サーバへのアクセスに使用するユーザ名を入力します。

ステップ 7 FTP Server Password フィールドに、リモート FTP サーバへのアクセスに使用するパスワードを入力します。

ステップ 8 パスワードを確認するために、Confirm Password フィールドにパスワードをもう一度入力します。

ステップ 9 この設定値を保存するには、 Submit をクリックします。


 

CLI からネイティブ FTP カスタム メッセージをアップロードするには、 ftp-native custom-message upload EXEC コマンドを使用します。

TFTP の設定

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

コンテンツ ファイルには、ルータ ソフトウェア イメージ、ルータ設定、セット トップ ボックス イメージ、IP フォン設定ファイルなどが含まれます。要求されたファイルが Content Engine から入手できない場合、Content Engine は要求デバイスの代わりに動作し、オリジン サーバからファイルを取得してキャッシュします。次に、Content Engine はファイルを要求元であるデバイスに転送します。任意のデバイスがそれ以降に同じファイルを要求すると、Content Engine のキャッシュからそのファイルが転送されます。

Content Engine とデバイス グループに対して TFTP 設定を実行、変更、および表示するには、次の作業を完了します。

「TFTP の一般設定」

「TFTP プロキシ サーバの設定」

「TFTP ディレクトリの設定」

TFTP の一般設定

Content Engine では、クライアントからの TFTP 要求を処理する際、ネイティブ TFTP 要求を受け入れ、ローカル側で設定されたディレクトリまたはオリジン サーバから、FTP または HTTP を使用してコンテンツを取得します。セット トップ ボックスやルータなどのコンテンツ デバイスでは、ルータ ソフトウェア イメージ、セット トップ ボックス イメージ、およびルータ設定をダウンロードするために TFTP 要求を実行します。Content Engine によって、TFTP 要求を処理するための専用 TFTP サーバを設定および管理することなく、TFTP から HTTP または TFTP から FTP への変換が可能になります。

Content Engine で TFTP サービスをイネーブルにし、ネットワーキング デバイスからの TFTP 要求を処理できるようにする手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 目的の Content Engine の横にある Edit アイコンをクリックします。Modifying Content Engine ウィンドウが開き、左側に Contents ペインが表示されます。

ステップ 3 Contents ペインから、 Applications > Web > TFTP > TFTP General Settings の順に選択します。TFTP Settings for Content Engine ウィンドウが表示されます。 表8-22 で、このウィンドウ内のフィールドについて説明し、対応する CLI グローバル コンフィギュレーション コマンドを示します。

ステップ 4 特定の Content Engine で TFTP サービス アプリケーションを実行できるようするには、 Inetd Enable TFTP Service チェックボックスにチェックマークを付けます。

このチェックボックスにチェックマークを付けると、Content Engine では要求されたコンテンツを取得することによって TFTP 要求を処理できます。このチェックボックスのチェックマークを外すと、Content Engine で TFTP サービスがディセーブルになります。

ステップ 5 Content Engine が同時にサービスする TFTP 要求の最大数を設定するには、Maximum Number of TFTP Connections フィールドの値を入力します。デフォルトの要求数は 200 です。範囲は 0~300 です。

ステップ 6 この設定値を保存するには、 Submit をクリックします。

保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。


) タスクバー内のアイコンを使用して実行できるほかの操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。


 

表8-22 TFTP の一般設定

GUI パラメータ
機能
CLI コマンド

Inetd Enable TFTP Service

Content Engine で TFTP サービスをイネーブルにします。

inetd enable tftp

Maximum Number of TFTP Connections

Content Engine で同時にサービスする TFTP 要求の最大数を指定します。

tftp max-connections number

 


 

TFTP プロキシ サーバの設定

要求されたファイルが Content Engine に存在しない場合、Content Engine はオリジン サーバに対して HTTP または FTP 要求を行ってコンテンツを取得します。要求されたコンテンツはキャッシュに保存され、TFTP クライアントに送信されます。それ以降に TFTP クライアントから同じコンテンツに対する要求があると、Content Engine 上の cfs または cdnfs ディレクトリからファイルが転送されます。

オリジン サーバは、プライマリ サーバとセカンダリ バックアップ サーバの 2 台まで設定できます。プライマリ サーバに障害が起きると、Content Engine 上で実行中の TFTP サーバ アプリケーションでは、セカンダリ バックアップ サーバからのコンテンツ取得が試行されます(設定されている場合)。2 台のオリジン サーバに優先順位を付けることで、プライマリ サーバとセカンダリ サーバを区別します。

TFTP プロキシ サーバを設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 目的の Content Engine の横にある Edit アイコンをクリックします。Modifying Content Engine ウィンドウが開き、左側に Contents ペインが表示されます。

ステップ 3 Contents ペインから、 Applications > Web > TFTP > TFTP Proxy の順に選択します。TFTP Proxy for Content Engine ウィンドウが表示されます。

ステップ 4 タスクバーから Create New TFTP Proxy アイコンをクリックします。Creating New TFTP Proxy for Content Engine ウィンドウが表示されます(図8-14 を参照)。表8-23 で、このウィンドウ内のフィールドについて説明し、対応する CLI グローバル コンフィギュレーション コマンドを示します。

図8-14 Creating New TFTP Proxy for Content Engine ウィンドウ

 


) TFTP プロキシ サーバは 2 台のみ指定できます。3 台目の TFTP プロキシ サーバを作成しようとすると、ポップアップ ウィンドウが表示され、各サーバに一意の優先順位を設定する必要があるため、2 台の TFTP プロキシ サーバしか指定できないことが通知されます。


ステップ 5 Protocol ドロップダウン リストから、プロキシ サーバが TFTP 要求を処理するために使用するプロトコル( HTTP または FTP )を選択します。

ステップ 6 TFTP Gateway Server フィールドに、TFTP プロキシ サーバのホスト名または IP アドレスを入力します。

ステップ 7 HTTP プロトコルのデフォルト ポート設定を変更するには、Port フィールドにポート番号を入力します。

ステップ 8 Priority ドロップダウン リストから、コンテンツを各オリジン サーバに照会する際の優先順位( LOW または HIGH )を選択します。

この優先順位を指定することで、プライマリ サーバとセカンダリ バックアップ サーバが区別されます。優先順位が高いプロキシ サーバがプライマリ オリジン サーバになり、最初にコンテンツが照会されます。プロトコルが同じか異なるかに関係なく、2 台のオリジン サーバに同じ優先順位を設定することはできません。

ステップ 9 Directory Path フィールドに、プロキシ サーバ上に存在するファイルへのパスを入力します。要求されたコンテンツが置かれているディレクトリを指定する完全パスまたは相対パスを入力できます。

ステップ 10 プロキシ サーバにログインする場合のユーザ認証の詳細を指定するには、 Configure User チェックボックスにチェックマークを付けます。このチェックボックスにチェックマークが付いていない場合は、ユーザの詳細情報を入力できません。

ステップ 11 User Name フィールドに、リモート サーバで使用されるユーザのログイン ID を入力します。


) HTTP または FTP を使用する場合、認証済みオブジェクトは Content Engine にキャッシュされません。これらのオブジェクトをキャッシュするには、tftp-server gw コマンドの Username および Password フィールドを空白にします。FTP と使用する場合、この設定は anonymous のアクセスを許可することになります。


ステップ 12 Password フィールドに、プロキシ サーバにアクセスするユーザの認証に使用されるユーザ パスワードを入力します。Confirm Password フィールドに、同じパスワードをもう一度入力します。画面に表示されるパスワードは、暗号化されます。

ステップ 13 この設定値を保存するには、 Submit をクリックします。

 

表8-23 TFTP プロキシ設定

GUI パラメータ
機能
CLI コマンド

Protocol

プロキシ サーバが TFTP 要求を処理するために使用するプロトコル(HTTP または FTP)

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

TFTP Gateway Server

TFTP プロキシ サーバのホスト名または IP アドレス。

Port

プロキシ サーバが HTTP プロトコルに使用するポート。デフォルトの HTTP ポート番号は 80 です。

tftp-server gw proto http server { hostname | ipaddress } [ port port_num ]

Priority

コンテンツをオリジン サーバに照会する際の優先順位(LOW [2] または HIGH [1])

Directory Path

プロキシ サーバ上に存在するコンテンツへのパス。要求されたコンテンツが置かれているディレクトリを指定する完全パスまたは相対パスを入力できます。

Configure User

プロキシ サーバにログインするためにユーザの認証情報を指定するためのフィールドをイネーブルにします。

User Name

リモート サーバで使用されるユーザのログイン ID

Password

プロキシ サーバにアクセスするユーザを認証するためのパスワード。

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

Confirm Password

--


 

TFTP ディレクトリの設定

TFTP クライアントがコンテンツを要求すると、Content Engine で実行されている TFTP サーバ アプリケーションは、指定されたディレクトリを検索してコンテンツを提供します。要求内でディレクトリ パスが指定されていない場合、デフォルトのディレクトリが使用されます。TFTP クライアントがアクセスできる TFTP ディレクトリとして、最大 8 つを指定できます。

TFTP で使用するディレクトリを設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 目的の Content Engine の横にある Edit アイコンをクリックします。Modifying Content Engine ウィンドウが開き、左側に Contents ペインが表示されます。

ステップ 3 Contents ペインから、 Applications > Web > TFTP > TFTP Directory の順に選択します。TFTP Directory Settings for Content Engine ウィンドウが表示されます(図8-15 を参照)。

図8-15 TFTP Directory Settings ウィンドウ

 

ステップ 4 TFTP Directory Settings セクションで、 Configure TFTP Directories チェックボックスにチェックマークを付けて、TFTP ディレクトリの設定をイネーブルにします。

このチェックボックスにチェックマークが付いていない場合、このウィンドウ内の他のフィールドは使用できません。このチェックボックスには、デフォルトでチェックマークが付いていません。Configure TFTP Directories チェックボックスのチェックマークを外すと、設定されたすべての TFTP ディレクトリが削除されます。

ステップ 5 デフォルト ディレクトリを設定するために、Directory 1 フィールドに、TFTP サーバ アプリケーションが使用するディレクトリへの完全絶対パスを入力します。TFTP ディレクトリのリストに設定された最初のディレクトリが、デフォルト ディレクトリとなります。

TFTP ディレクトリは、8 つまで設定できます。ディレクトリ パスは重複して指定できません。

ステップ 6 この設定値を保存するには、 Submit をクリックします。

デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 


) タスクバー内のアイコンを使用して実行できるほかの操作については、表3-3の「Content Distribution Manager GUI のアイコン」を参照してください。



 

CLI を使用して TFTP ディレクトリを設定するには、 tftp-server dir directory グローバル コンフィギュレーション コマンドを使用します。

WCCP 透過キャッシングでの DNS キャッシング ネーム サービスの設定

WCCP を使用した DNS 要求の透過代行受信では、管理者は WCCP バージョン 2 をサポートする Content Engine およびルータ上で DNS キャッシング ネーム サービス(WCCP サービス グループ番号 53)を設定する必要があります。

DNS のプロセスでは次の方法で WCCP のプロセスと通信を行います。

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

DNS プロセスのアクティブ ステートをモニタリングして、DNS が要求を受け入れ可能か確認する。DNS キャッシュに対応するサーバがない場合、受け入れ可能なサーバができるまでキャッシュはサービスの登録を停止する。

WCCP サービス(DNS キャッシング ネーム サービス)を設定し管理する。

1 台または複数の Content Router を使用する中央管理 ACNS ネットワークでは、登録済みの Content Engine 上で WCCP 代行受信を使用して DNS キャッシング ネーム サービスを設定すると、Content Router との競合が発生します。これは、Content Router と Content Engine が、同一ポート(ポート 53)で DNS 要求を待ち受けるためです。このため、Content Router を使用する中央管理環境では、WCCP 代行受信を使用して DNS キャッシュ サポートを設定できません。ただし、このような環境では、標準の DNS キャッシング ネーム サービス(WCCP 代行受信をサポートしない)をイネーブルにすることができます。

Content Engine で DNS 要求を代行受信する利点は、次のとおりです。

WCCP リダイレクト リストまたはバイパス エントリ経由で使用されているサーバを制御できます。また、使用されていないサーバへの要求を Content Engine で代行受信し、それらを他のサーバに再発行することで、サーバを制御できます。

DNS サーバは、必要に応じて簡単に更新および変更できます。

DNS キャッシュ ヒットによりパフォーマンスが向上します(応答時間が早くなり、帯域幅の使用量が減少します)。

複数のフォワーダにそれぞれの DNS キャッシュを用意し、ネットワークをパーティショニングできます。これにより、次のことが実現されます。

WAN 上で DNS トラフィックを効率的に制御できます。

Content Engine は要求を別のアップストリーム サーバに発行できるため、1 台または複数のサーバの故障に備えることができます。

通常、特に高遅延性の相互接続で要求が集中して発生した場合に、このパーティショニングによりパフォーマンスが向上します。

Content Engine の DNS キャッシング サーバの設定

Content Engine の DNS キャッシング サーバ設定値を設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内で登録されているすべてのデバイスがリスト表示されます。

ステップ 2 DNS キャッシング サーバ設定値を設定する Content Engine の Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

Contents ペインから、 Applications > DNS > DNS Caching Server の順に選択します。DNS Caching Server Settings for Content Engine ウィンドウが表示されます。 表8-25 で、このウィンドウ内のフィールドについて説明し、対応する CLI グローバル コンフィギュレーション コマンドを示します。

ステップ 3 Enable DNS Caching チェックボックスにチェックマークを付けて、受信側ポートを設定してから、DNS サーバを起動して IP アドレスに対するドメイン名を解決します(Content Engine の DNS サーバ バインディングの設定を参照)。DNS サーバを有効にすると、システムのネーム サーバとして 127.0.0.1 というエントリが作成され、メモリベースの DNS キャッシュがポート 53 で開始されます。


) WCCP を使用した DNS 要求の透過代行受信をイネーブルにするには、Content Engine と WCCP バージョン 2 ルータ上で WCCP DNS キャッシング ネーム サービス(サービス ID 53 の WCCP サービス)を設定する必要があります。


ステップ 4 Lookup Name Servers Recursively チェックボックスにチェックマークを付けて、プライマリ ネーム サーバへの要求が失敗した場合に、設定されている各ネーム サーバを順次照会できるようにします。このオプションは、元の要求には単一の DNS サーバだけが含まれているため、Content Engine で設定されている DNS サーバを使用するように DNS キャッシュを設定した場合のみ有効です(詳細は、ステップ 6 を参照)。

ステップ 5 Use Expired Cache Entries チェックボックスにチェックマークを付けて、DNS キャッシュ内のリソース レコードを有効期限が切れても使用できるようにします。

チェックマークが付いていると、DNS キャッシュでは有効期限切れのリソース レコードが自身のキャッシュ内にある場合、そのレコードを使用してユーザ要求を処理します。同時に、DNS キャッシュは新規に検索を開始して、キャッシュされたオブジェクトを再度有効にします。失効したリソース レコードによる処理は、特にアップストリーム DNS が低速または応答していない場合に役立ちます。失効したレコードは、エントリが新規のレコードで更新されるまで引き続き使用するか、または Least Recently Used(LRU)アルゴリズムを使用してキャッシュから削除します。

ステップ 6 Use Origin Server ドロップダウン リストから、Content Engine(DNS キャッシング ネーム サーバ)が透過 DNS 要求を処理するために使用する方式を選択します。 表8-24 で、このリスト内のオプションについて説明します。

DNS キャッシング ネーム サーバが、WCCP 対応ルータからリダイレクトされた透過 DNS 要求を処理するために使用する方式を設定できます。これらの透過 DNS 要求には、パケット ヘッダーに元の宛先サーバが含まれています。ただし、Content Engine には複数の DNS ネーム サーバを設定できるため、DNS キャッシング ネーム サーバでは、元の要求パケット ヘッダーで指定されている元の DNS サーバを使用するか、Content Engine で設定されている DNS ネーム サーバを使用するか、またはその両方を使用するかを設定できます。

 

表8-24 Use Origin Server のオプション

オプション
説明

Do Not Set

Content Engine で設定されている DNS サーバだけを使用します。このオプションがデフォルトで選択されています。

Only

元の要求で指定されている DNS サーバだけを使用します。

After-configured

Content Engine で設定されている DNS ネーム サーバを使用します。これらのサーバが故障した場合は、元の要求パケットで指定されている DNS サーバを使用します。

Before-configured

元の要求で指定されている DNS サーバを使用します。このサーバが故障した場合は、Content Engine で設定されている DNS ネーム サーバを使用します。

ステップ 7 Maximum Size of Cache フィールドで、DNS キャッシュ メモリの最大サイズを MB 単位で指定します。キャッシュで使用される割り当てメモリのデフォルト サイズは 5 MB です。DNS サーバが動作する領域には厳密な最大メモリの上限値を指定し、システム全体のリソースに必要以上に負担をかけないように注意してください。

ステップ 8 Minimum TTL フィールドで、リソース レコードをキャッシュに保存する最小時間を指定します。デフォルト値は 1 秒です。存続可能時間が経過すると、キャッシュされた応答が再度検証されます。応答がキャッシュから処理される場合、応答が有効になるにはキャッシュ内の適切なリソース レコードがすべて有効でなければなりません。最小存続可能時間は、最大存続可能時間より小さくなければなりません。適切に指定しないと、送信時にエラー メッセージが表示されます。

ステップ 9 Maximum TTL フィールドで、リソース レコードをキャッシュに保存する最大時間を指定します。デフォルト値は 86400 秒です。この時間が経過すると、キャッシュされたリソース レコードは失効します。最大存続可能時間は、最小存続可能時間より大きくなければなりません。適切に指定しないと、送信時にエラー メッセージが表示されます。

DNS プロトコルは UDP を使用しているため、パケットは消失したりドロップしたりする可能性があります。DNS 要求を再送信する義務は、要求側にあります。通常、応答が受信されるまで 3 秒ごとに再送信が開始されます。応答が受信されない場合は、その要求は 90 秒後にタイムアウトします。DNS サーバがタイムアウトすると、新しいアップストリーム サーバが選択され、照会を行います。アップストリームで照会するサーバがこれ以上ない場合は、サーバが DNS 失敗応答を要求元のクライアントに返します。

ステップ 10 Retry Period フィールドで、応答のない要求が廃棄されるまでの時間を指定します。デフォルト値は 90 秒です。

ステップ 11 Retry Timeout フィールドで、アップストリーム DNS サーバに送信される UDP DNS 要求の再送信間隔を指定します。デフォルト値は 3 秒です。

ステップ 12 この設定値を保存するには、 Submit をクリックします。デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 

表8-25 DNS キャッシング サーバ設定

GUI パラメータ
機能
CLI コマンド

Enable DNS Caching

受信ポートが設定されたあとに、DNS サーバでの IP アドレスに対するドメイン名の解決を可能にします。

dns enable

Lookup Name Servers Recursively

プライマリ ネーム サーバへの要求が失敗した場合、設定済みネーム サーバを順に照会できるようにします。

dns serial-lookup

http dns-cache serial-lookup

Use Expired Cache Entries

DNS キャッシュ内のリソース レコードを有効期限が切れていても使用します。

dns user-expired enable

Use Origin Server

DNS キャッシング ネーム サーバが WCCP 対応ルータからリダイレクトされた透過 DNS 要求を処理するために使用する方式を設定します。

dns use-original-server { only | after-configured | before-configured }

Maximum Size of Cache

DNS キャッシュ メモリの最大サイズ(MB 単位)

dns max-cache-memory mbytes

Minimum TTL

リソース レコードをキャッシュに保存する最小時間

dns min-ttl seconds

Maximum TTL

リソース レコードをキャッシュに保存する最大時間

dns max-ttl seconds

Retry Period

応答されない要求が廃棄されるまでの時間

dns retry-period seconds

Retry Timeout

アップストリーム DNS サーバに送信される UDP DNS 要求の再送信間隔

dns retry-timeout seconds

 


 

Content Engine の DNS キャッシュにキャッシュ可能なリソース レコード

ACNS ソフトウェアを使用する Content Engine は、代行受信デバイスを介する DNS サーバ(転送側または再帰サーバ)に対して発行された DNS 要求を代行受信できます。要求を受信すると、Content Engine はキャッシュされた応答がある場合、その応答をクライアントに送信します。キャッシュ応答が有効になるには、必須のセクション(Answer、Authority、Additional)に適切なリソース レコードがすべて含まれている必要があります。これらのリソース レコードが削除されたり、失効したりした場合、その要求は送信用にキューイングされます。

表8-26 で、Content Engine の DNS キャッシュにキャッシュ可能なリソース レコードについて説明します。

 

表8-26 キャッシュ可能なリソース レコード

レコード
説明

A

アドレス レコード

HINFO

ホスト情報

NULL

ヌル レコード

TXT

テキスト ストリング

WKS

既知のサービスの説明

NS

ネーム サーバ レコード

CNAME

正規名

MB

メール ボックスのドメイン名

MD

メールの宛先

MF

メール フォワーダ

MG

メール グループ メンバー

MR

メール リネーム ドメイン

PTR

ポインタ レコード

MX

メール交換

SOA

権限のソース

他のリソース レコードはキャッシュされませんが、これらを要求するクライアントにパス スルーされます。DNS キャッシング ネーム サービスは、RFC 1035 で規定されているように DNS 応答の圧縮をサポートします。これには、キャッシュで生成される応答も含まれます。キャッシュで照会に対するサーバ応答が認識されない場合は、その応答をキャッシングせずにクライアントにパス スルーします。このアクションにより、標準以外のクライアントまたはサーバの処理が中断する回数が減少します。

Content Engine の DNS サーバ バインディングの設定

Content Engine の DNS サーバのバインディングを設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内で登録されているすべてのデバイスがリスト表示されます。

ステップ 2 DNS キャッシュが要求の受信に使用する IP アドレスとポート番号を設定する Content Engine の Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Applications > DNS > DNS Server Binding の順に選択します。DNS Server Bindings for Content Engine ウィンドウが表示されます。

ステップ 4 タスクバーから Create New Server Binding アイコンをクリックして、DNS サーバがクライアント要求を受信するための IP アドレスとポート番号を設定します。Creating New DNS Server Binding for Content Engine ウィンドウが表示されます。


) DNS サーバがクライアント要求用に設定されたインターフェイス IP アドレスで受信を実行していない場合、さらに、DNS サーバ バインディングのエントリが最大の 16 エントリに達していない場合にのみ、DNS サーバ バインディングを新規作成できます。

DNS サーバですべてのインターフェイス IP アドレスが受信に使用されている場合、「DNS Service is already listening on all IP Addresses.」という警告メッセージが表示されます。

DNS サーバ バインディングのエントリがすでに 16 エントリの最大数に達している場合は、「DNS Server Binding Entries have reached their maximum limit of 16.」という警告が表示されます。


ステップ 5 DNS キャッシング ネーム サーバが特定のインターフェイス IP アドレスか、または Content Engine で設定されているすべての IP アドレスで受信するように設定します。

DNS キャッシング ネーム サーバが特定のインターフェイス IP アドレスで受信するように設定するには、 Listen on IP Address オプション ボタンをクリックし、ドロップダウン リストから IP アドレスを選択します。プライマリ インターフェイスに関連付けられたすべての IP アドレス、または Content Engine に設定された他のインターフェイスが表示されます。ドロップダウン リストのインターフェイス IP アドレスは、オプション ボタンをクリックしたあとでのみ選択できます。

DNS キャッシング ネーム サーバが Content Engine で設定されているすべての IP アドレスで受信するように設定するには、 Listen on all IP Addresses オプション ボタンをクリックします。ホスト名は IP アドレスに対して解決されると、メモリベースの DNS キャッシュに保存されます。

ステップ 6 Port フィールドで、DNS キャッシング サーバがクライアント要求を受信するポートを指定します。範囲は 1~65535 です。設定されたポート番号が、Content Engine 上で動作する他のアプリケーションで使用されていないことを確認します。


Listen on IP Address が設定されている場合、DNS キャッシング サーバは特定の IP アドレスとこのポートで受信します。Listen on All IP Addresses が設定されている場合、DNS キャッシング サーバは Content Engine で設定されているすべての IP アドレスとこのポートで受信します。


ステップ 7 Hostname フィールドで、IP アドレスにマップされる受信側のホスト名を指定します。

ステップ 8 この設定値を保存するには、 Submit をクリックします。設定されたポート番号が Content Engine で動作する他のアプリケーションで使用されている場合は、DNS キャッシュの受信側でエラーが発生することを警告するダイアログ ボックスが表示されます。

Listen on All IP Addresses が設定されている場合、DNS キャッシュ サーバがクライアント要求をすべての IP アドレスで受信するように設定すると、その他の DNS サーバ バインディング設定がすべて削除されることを警告するダイアログ ボックスが表示されます。 OK をクリックして実行します。

DNS Server Bindings for Content Engine ウィンドウに、設定された DNS キャッシュの受信側の設定が表示されます。


 

CLI を使用して、DNS キャッシング ネーム サーバが特定のインターフェイス IP アドレスまたは Content Engine で設定されているすべての IP アドレスで待ち受け受信するように設定するには、次のグローバル コンフィギュレーション コマンドを使用します。

dns listen { all | ipaddress } port port_num hostname hostname

Content Engine の DNS アドレス レコードのマッピングの設定

DNS サーバでは、自身が有効となるホストの DNS 名を認識し、自身のキャッシュ内でその名前を IP アドレスにマップする必要があります。DNS キャッシュの受信側が DNS 名と一致しない場合は、マッピング タイプを指定して IP アドレスを名前マッピングに登録します。

Content Engine で DNS ホスト名の IP アドレスへのマッピングを設定する手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内の設定済みデバイスタイプがすべてリスト表示されます。

ステップ 2 IP アドレスとホスト名を統計的にマップする Content Engine の Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Request Routing > DNS > A-Record Mapping の順に選択します。DNS A-Record Mappings for Content Engine ウィンドウが表示されます。

ステップ 4 タスクバーから Create New DNS A-Record Mappings アイコンをクリックします。Creating New DNS A-Record Mapping for Content Engine ウィンドウが表示されます。

ホスト名または正規名(DNS CNAME Record Mappings ウィンドウで設定)を設定し、マッピング設定の合計が最大の 256 に達した場合は、エラー メッセージが表示されます。

ステップ 5 Mapping Type ドロップダウン リストから、キャッシュ内での名前に対応する IP アドレスを検索する方式を選択します。 表8-27 で、このドロップダウン リストのオプションについて説明します。

 

表8-27 Mapping Type のオプション

オプション
説明

Forward

ホスト名を IP アドレスに対してマップします。

Reverse

IP アドレスをホスト名に対してマップします。

Both

両方を正逆双方向にマップします。

ステップ 6 Hostname フィールドで、IP アドレスにマップされるホスト名を指定します。ホスト名の重複はできません。また、先頭はアルファベット文字で指定し、256 文字を超えてはなりません。

例外として、次の場合はホスト名の重複ができます。

ホスト名が Forward(正方向)マッピング タイプで設定されている場合、同じホスト名を Reverse(逆方向)マッピング タイプで設定できます。

その反対に、ホスト名が Reverse(逆方向)マッピング タイプで設定されている場合、同じホスト名を Forward(正方向)マッピング タイプで設定できます。

ステップ 7 IP Address フィールドで、双方向、正方向、または逆方向にマッピングする IP アドレスを指定します。クライアント照会が受信されると、設定されているホスト名がここで指定した IP アドレスのいずれかに解決されます。最初の IP アドレスは必須のエントリです。


) IP アドレスは順序通りに指定する必要があります。適切に指定しないと、送信時にエラー メッセージが表示されます。


ステップ 8 この設定値を保存するには、 Submit をクリックします。

Delete DNS A-Record Mapping アイコンをクリックして正規名にマップされたアドレス レコードを削除した場合は、エラー メッセージが表示されます。アドレス レコードを削除するには、先にマッピングを削除する必要があります。


 

CLI から DNS ホスト名の IP アドレスへのマッピングを設定するには、次のグローバル コンフィギュレーション コマンドを使用します。

dns pin { forward hostname ipaddress | reverse hostname ipaddress | both hostname ipaddress }

Content Engine の DNS 正規名レコードのマッピング設定

DNS サーバでは、自身が有効となるホストの DNS 名を認識し、自身のキャッシュ内でその名前を IP アドレスにマップする必要があります。DNS キャッシュの受信側が DNS 名と一致しない場合は、IP アドレスを名前マッピングに登録したあとに、別名のリソース レコードをアドレス レコードにマップします。

Content Engine で DNS 正規名をアドレス レコードにマッピングする手順は、次のとおりです。


ステップ 1 Devices > Devices の順に選択します。Devices ウィンドウが表示され、ACNS ネットワーク内で登録されているすべてのデバイスがリスト表示されます。

ステップ 2 正規名(CNAME)マッピングを指定する Content Engine の Edit アイコンをクリックします。Device Home for Content Engine ウィンドウが表示されます。

ステップ 3 Contents ペインから、 Request Routing > DNS > CNAME Record Mapping の順に選択します。DNS CNAME Record Mappings for Content Engine ウィンドウが表示されます。

ステップ 4 タスクバーから Create New DNS CNAME Record Mappings アイコンをクリックします。Creating New DNS CNAME Record Mapping for Content Engine ウィンドウが表示されます。


) 正規名を設定する際、マッピング設定の合計が最大の 256 に達している場合は、エラー メッセージが表示されます。


ステップ 5 Canonical Name フィールドで、アドレス リソース レコードにマップされる正規名を指定します。正規名は最大 8 個のアドレス レコードにマップできます。別名の重複はできません。また、先頭はアルファベット文字で指定し、256 文字を超えてはなりません。

ステップ 6 A-Record ドロップダウン リストから、キャッシュ内で正規名に対して検索するアドレス レコードを選択します。最初の A-record は必須のオプションです。

A-record ドロップダウン リストには、設定されている正方向および双方向のマッピング タイプのアドレス レコードがすべて表示されます。1 つまたは複数の一意の A-record を CNAME レコードに関連付けることができます。


) A-record は順序通りに指定する必要があります。適切に指定しないと、送信時にエラー メッセージが表示されます。


ステップ 7 この設定値を保存するには、 Submit をクリックします。


 

CLI を使用して DNS 正規名のアドレス レコードへのマッピングを設定するには、 dns pin cname records グローバル コンフィギュレーション コマンドを使用します。

HTTP プロキシ キャッシングの DNS サーバの設定

DNS は、入力されたドメイン名を対応する IP アドレスに変換する機能です。Content Engine 上に DNS キャッシングを設定するには、次の作業を完了します。

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

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

Content Engine 上の DNS キャッシュが保存するレコードの最大数を指定します。この設定により、Content Engine 上の DNS キャッシュのサイズが決定されます。

Content Engine 上の DNS キャッシングをイネーブルにします。

デフォルトでは、Content Engine 上の DNS キャッシング ネーム サービスには、オリジナル DNS サーバではなく、設定済み DNS サーバ リスト内の DNS サーバが使われます。

オリジナル DNS サーバ ― オリジナルの要求による DNS サーバ(オリジナル DNS サーバと呼ぶ)

設定済み DNS サーバ リスト ― ネットワークで使用され、ドメイン名解決のために Content Engine が使う DNS サーバ リストに載っている DNS サーバ

Content Engine の DNS サーバ設定値を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 設定する Content Engine の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 Contents ペインから、 General Settings > Services > DNS の順に選択します。HTTP DNS Cache Settings ウィンドウが表示されます(図8-16 を参照)。 表8-28 で、このウィンドウ内のフィールドについて説明し、対応する CLI グローバル コンフィギュレーション コマンドを示します。

図8-16 HTTP DNS Cache Settings ウィンドウ

 

ステップ 4 DNS キャッシングをイネーブルにするには、 Enable DNS Caching of DNS Entries for Http Proxy チェックボックスにチェックマークを付けます。

ステップ 5 Maximum Cached DNS Entries フィールドに、レコードを保存するために一時的に使用する DNS キャッシュ ハッシュ テーブルのサイズ(MB 単位)を入力します。範囲は 5~512 です。

ステップ 6 プライマリ ネーム サーバへの要求が失敗した場合に、各設定済みネーム サーバを順に照会できるようにするには、 Enable Serial Lookup チェックボックスにチェックマークを付けます。

ステップ 7 Local Domain Name フィールドで、DNS キャッシュに使用するローカルドメイン名を入力します。

ステップ 8 DNS Servers フィールド リストで、ホスト名を IP アドレスに解決するためにネットワークが使用する DNS サーバ リストを入力します。DNS サーバは8 つまで設定できます。リスト内の各項目は、スペースで区切ります。

ステップ 9 この設定値を保存するには、 Submit をクリックします。デフォルト設定またはデバイス グループの設定を適用した後に、保存されていない変更内容がある場合、「Click Submit to Save」というメッセージが現在の設定の横に赤く表示されます。 Reset をクリックして、ウィンドウを以前の設定に戻すこともできます。 Reset ボタンが表示されるのは、デフォルトまたはデバイス グループ設定を適用して現在のデバイス設定が変更され、その変更が更新されていない場合だけです。

 

表8-28 HTTP プロキシ DNS キャッシュ設定

GUI パラメータ
機能
CLI コマンド

Enable DNS Caching of DNS Entries for HTTP Proxy

システム内で DNS キャッシングをイネーブルにします。

dns enable

Maximum Cached DNS Entries

DNS レコードを一時的に保存するために使用される、DNS キャッシュ ハッシュ テーブルの最大サイズを指定します。

dns max-cache-memory

Enable Serial Lookup

プライマリ ネーム サーバへの要求が失敗した場合、各設定済みネーム サーバを順に照会できるようにします。

dns serial-lookup

Local Domain Name

DNS キャッシュに使用するローカル ドメイン名。

ip domain-name name1 name2 name3

List of DNS Servers

要求されたドメインを IP アドレスに変換するためにネットワークが使用する DNS サーバ。

ip name-server

 


 

ICP の設定

ICP は、ライトウェイト メッセージ形式で、Content Engine 間での通信、および従来のプロキシ プロトコルとのインターオペラビリティをサポートするために使用されます。ICP は、Content Engine ファーム内の近隣 Content Engine に存在する URL についての情報交換に使用されます。Content Engine は、ICP クエリーと応答をやり取りして情報を収集し、その情報を使用してオブジェクトの取得先として最適なロケーションを選択します。

ICP は従来、キャッシュ クラスタ全体のサイズを単一の装置以上に拡張するために使用されていましたが、最近では ICP はキャッシュ クラスタ ソリューションのスケーリング手法として適していないことが判明しています。現在は、トラフィックを透過ネットワーク キャッシュ クラスタに向けて送信する手法が使用されているため、キャッシュを配置する以外に ICP を使用する必要性はほとんどなくなりました。

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 に送信する)の両方の動作がサポートされています。


ICP クライアントの設定

ICP クライアント機能を使用して必要なオブジェクトをインターネットから取得する前に、ICP クエリーを生成するように Content Engine ファームを設定できます。

ICP 機能を使用して、親および兄弟関係にある Content Engine を階層的に構成できます。Content Engine は、親または兄弟のいずれにも設定できます。キャッシュ ミス時に、親の Content Engine はデータを取得できますが、兄弟関係の Content Engine はデータを取得できず、代わりに要求を親の Content Engine に転送します。

ICP クライアント機能を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。Devices ウィンドウが表示されます。

ステップ 2 設定する Content Engine の名前の横にある Edit アイコンをクリックします。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > ICP > Client の順に選択します。ICP Client Settings ウィンドウが表示されます(図8-17 を参照)。 表8-29 で、このウィンドウ内のフィールドについて説明します。

図8-17 ICP Client Settings ウィンドウ

 

ステップ 4 ICP クライアントのクエリーをイネーブルにするには、 Enable チェックボックスにチェックマークを付けます。

ステップ 5 Maximum Reply Wait Time フィールドで、ICP 応答のタイムアウト値(秒単位)を指定します。

ステップ 6 Number of Failures フィールドで、応答しない ICP サーバを有効なサーバのリストから除外する前に、各 Content Engine で許容される失敗数を指定します。

ステップ 7 Excluded Domains フィールドに、ICP クエリーから除外するドメインを入力します。

ステップ 8 この設定値を保存するには、 Submit をクリックします。

表8-29 で、Content Distribution Manager GUI に表示される ICP クライアントの設定値について説明し、対応する CLI グローバル コンフィギュレーション コマンドを示します。

 

表8-29 ICP クライアントのパラメータ

GUI パラメータ
機能
CLI コマンド

Enable

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

icp client enable

Maximum Reply Wait Time

Content Engine が要求されたデータをインターネットから直接取得するまで待機する時間を設定します。範囲は 1~30 秒で、デフォルト値は 2 秒です。

icp client max-wait timeout

Number of Failures

応答しない ICP サーバをリストから除外する前に、各 Content Engine で許容される失敗数を設定します。範囲は 0 ~ 100 で、デフォルト値は 20 回の失敗です。

icp client max-fail retries

Exclude Domains

ローカル ドメインを ICP キャッシング サービスから除外します。

icp client exclude domainnames

 


 

ICP リモート クライアントの設定

Content Distribution Manager GUI を使用して、リモート ICP クライアントを ICP クライアント リストに追加する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 設定する Content Engine の名前の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > ICP > Remote Clients の順に選択します。

ステップ 4 Create New ICP Remote Client アイコンをクリックします。Creating New ICP Remote Client ウィンドウが表示されます。

ステップ 5 Client Name フィールドに、ICP リモート クライアントのホスト名または IP アドレスを入力します。

ステップ 6 Content Engine が指定したクライアントの親サーバとして動作するように設定するには、 Fetch Misses チェックボックスにチェックマークを付けます。Content Engine がクライアントの要求を満たすことができない場合、Content Engine はその要求を別のサーバまたはインターネットに転送します。

ステップ 7 この設定値を保存するには、 Submit をクリックします。


 

CLI から ICP サーバ リモート クライアントを設定するには、次のグローバル コンフィギュレーション コマンドを使用します。

icp server remote-client { hostname | ipaddress } { fetch | no-fetch }

ICP サーバの設定

Content Engine を、ICP サーバとして機能するように設定することもできます。これにより、Content Engine は階層内の ICP 親クライアントと兄弟クライアントに対して ICP メッセージのマルチキャストを行い、Content Engine の階層をプローブできます。

ICP サーバ機能を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 設定する Content Engine の名前の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > ICP > Server の順に選択します。ICP Server Settings for Content Engine ウィンドウが表示されます(図8-18 を参照)。 表8-30 で、このウィンドウ内のフィールドについて説明し、対応する CLI グローバル コンフィギュレーション コマンドを示します。

図8-18 ICP Server Settings ウィンドウ

 

ステップ 4 ICP サーバのクエリーをイネーブルにするには、 Enable チェックボックスにチェックマークを付けます。

ステップ 5 ICP Port フィールドで、ICP 要求をサーバ上で受信するポートを指定します。

ステップ 6 HTTP Port フィールドで、ICP で生成された要求をサーバ上で受信する HTTP ポートを指定します。

ステップ 7 この設定値を保存するには、 Submit をクリックします。

 

表8-30 ICP サーバ CLI コマンドの要約

GUI パラメータ
機能
CLI コマンド

Enable

ICP サーバをイネーブルにします。

icp server enable

ICP Port

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

icp server http-port port

HTTP Port

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

icp server port icpport


 

ICP リモート サーバの設定

Content Distribution Manager GUI を使用して、リモート ICP サーバを ICP サーバ リストに追加する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Devices の順に選択します。

ステップ 2 設定するデバイス グループ名の横にある Edit アイコンをクリックします。Contents ペインが左側に表示されます。

ステップ 3 Contents ペインから、 Applications > Web > HTTP > ICP > Remote Servers の順に選択します。

ステップ 4 Create New ICP Remote Servers アイコンをクリックします。Creating New ICP Remote Server ウィンドウが表示されます(図8-19 を参照)。 表8-31 で、このウィンドウ内のフィールドについて説明し、対応する CLI グローバル コンフィギュレーション コマンドを示します。

図8-19 Creating New ICP Remote Server 設定ウィンドウ

 

ステップ 5 Server Name フィールドに、ICP リモート サーバのホスト名または IP アドレスを入力します。

ステップ 6 設定された ICP サーバが親サーバとして機能し、キャッシュ ミス データを取得できるようにするには、 Parent チェックボックスにチェックマークを付けます。このボックスにチェックマークを付けない場合、設定された ICP サーバはキャッシュ ミス データを取得しません。

ステップ 7 ICP Port フィールドに、ICP クエリーの受け入れ先となる ICP サーバ上の ICP ポートを入力します。範囲は 1~65535 で、デフォルト ポートは 3130 です。

ステップ 8 HTTP Port フィールドに、プロキシ スタイルの要求が転送される ICP サーバ上の HTTP ポートを入力します。範囲は 1~65535 で、デフォルト ポートは 3128 です。

ステップ 9 この ICP サーバに送信される ICP 要求を、特定のドメインから発信されたものだけに限定する場合は、Excluded Domains フィールドに除外ドメインを入力します。それ以外の場合は、すべての ICP 要求(「ローカル ドメイン」として指定されたものを除く)がこの ICP サーバに転送されます。

ステップ 10 この設定値を保存するには、 Submit をクリックします。

 

表8-31 ICP リモート サーバの設定

GUI パラメータ
機能
CLI コマンド

Server Name

ICP リモート サーバのホスト名または IP アドレス

icp client add-remote-server { hostname | ipaddress } { parent | sibling } icp-port icpport http-port httpport [ restrict domainnames ]

Parent

設定された ICP サーバが親サーバとして機能して、キャッシュ ミス データを取得できるようにします。

ICP Port

ICP クエリーを受け入れるポート

HTTP Port

プロキシ スタイルの要求が転送される ICP サーバのポート

Excluded Domains

リスト内のドメインを除外します。