この章では、Oracle Traffic Directorの使用中に発生する可能性のある問題の診断および解決に使用できる手順および情報ソースについて説明します。
この章には次の項が含まれます:
この項では、Oracle Traffic Directorでの問題を診断および解決するために実行できる一連のタスクについて説明します。
システム構成が正しいかどうかを確認します。
サポートされているプラットフォームおよびオペレーティング・システムの詳細は、次にあるOracle Fusion Middlewareのサポートされるシステム構成を参照してください。
http://www./technetwork/middleware/ias/downloads/fusion-certification-100350.html
16.2項「一般的なエラーの解決方法」で、問題の解決方法を探します。
16.3項「よくある質問」に問題についての情報や解決方法が記載されているかどうかを確認します。
問題の診断を実行します。
サーバー・ログに記録されているメッセージを確認します。タイプがWARNING
、ERROR
およびINCIDENT_ERROR
のメッセージを探します。
エラー・メッセージに、タイプがWARNING
およびERROR
のメッセージがある場合、次の指示に従って問題を解決します。
INCIDENT_ERROR
メッセージは、原因不明の重大な問題を示します。Oracleサポートに連絡する必要があります。
サーバー・ログの冗長度を高め、問題の再現を試みます。
表 11-1「サーバー・ログ・レベル」にあるように、Oracle Traffic Directorではサーバー・ログについて、いくつかのログ・レベルがサポートされています。デフォルトのログ・レベルは、NOTIFICATION:1
です。最小の冗長度ログ・レベルは、INCIDENT_ERROR
で、このレベルでは、重大なエラー・メッセージのみが記録されます。TRACE:1
、TRACE:16
またはTRACE:32
レベルでは、ログはレベルに応じて冗長度が増しますが、より詳細な情報が提供され、問題の診断に活用できます。
ログの冗長度を高め、問題の再現を試みます。問題が再度発生したら、問題の原因を示すメッセージ・ログを確認します。
サーバー・ログ・レベルの変更の詳細は、11.3項「ログ・プリファレンスの構成」を参照してください。
16.4項「Oracleサポートへの連絡」の説明に従い、Oracleサポートに連絡します。
この項では、Oracle Traffic Directorの高可用性構成に関する問題を診断および解決するためのタスクについて説明します。
Oracle Traffic Director構成が2つのノード上にデプロイされている必要があります。詳細は、14.2項「フェイルオーバー・グループの作成および管理」を参照してください。
各フェイルオーバー・グループのルーターIDは一意である必要があります。
KeepAlivedがインストールされていることを確認します。通常、Oracle Traffic Directorインスタンスが実行されているExalogic計算ノード(またはVM)では、両ノードともデフォルトでKeepAlivedソフトウェアがインストールされています。KeepAlivedがインストールされていることを確認するには、次のコマンドを実行します。
rpm -qa | grep keepalived
KeepAlivedが正しくインストールされている場合、次のような出力が表示されます。
keepalived-1.2.2-1.el5
KeepAlivedがインストールされていない場合、RPMはソフトウェア・リポジトリ内にあります。
KeepAlived特有の情報は、/var/log/messages
にあるログで確認できます。
高可用性構成を正常に完了するには、正しいVIPアドレスと適切なサブネット・マスク(ネットマスク)のビットサイズを指定する必要があります。また、実際のネットマスク値ではなく、ネットマスクのビット数を指定する必要があります。詳細は、14.2.1項「フェイルオーバー・グループの作成」を参照してください。
この項では、次の問題の解決策を示します。
このエラーは、構成内の1つ以上のHTTPリスナーが、他のプロセスによってすでに使用中のTCPポート番号に割り当てられている場合に発生します。
[ERROR:32] startup failure: could not bind to port port (Address already in use) [ERROR:32] [OTD-10380] http-listener-1: http://host:port: Error creating socket (Address already in use) [ERROR:32] [OTD-10376] 1 listen sockets could not be created [ERROR:32] server initialization failed
次のコマンドを実行すると、指定のポートでリスニング中のプロセスを検出できます。
> netstat -npl | grep :port | grep LISTEN
構成済のHTTPリスナー・ポートが他のプロセスで使用中の場合は、ポートを解放するか、9.3項「リスナーの変更」の説明に従って変更します。
このエラーは、1024
までのHTTPリスナー・ポート(たとえば80
)を構成していて、Oracle Traffic Directorインスタンスを-root
以外のユーザーとして起動しようとした場合に発生します。
次のメッセージがサーバー・ログに書き込まれます。
[ERROR:32] [OTD-10376] 1 listen sockets could not be created [ERROR:32] [OTD-10380] http-listener-1: http://soa.example.com:80: Error creating socket (No access rights)
1024
までのポート番号は、Internet Assigned Numbers Authority (IANA)によって様々なサービスに割り当てられます。これらのポート番号にアクセスできるのは、root
ユーザーのみです。
この問題を解決するには、次のいずれかを行います。
1024
より上のポート番号(たとえば8080
)でOracle Traffic Directorを構成し、ポート80
で受信したリクエストを構成済Oracle Traffic DirectorポートにリダイレクトするIPパケット・フィルタリング・ルールを次のように作成します。
# /sbin/iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080 # /sbin/iptables -t nat -A PREROUTING -p udp -m udp --dport 80 -j REDIRECT --to-ports 8080
次の例に示すように、chkconfig
コマンドを実行し、サーバーの再起動時にiptables
サービスがデフォルトで起動されることを確認します。
# chkconfig --level 35 iptables on
xinetd
がシステム内にインストールされている場合、/etc/xinetd.d/
ディレクトリに次のエントリを含むファイル(たとえばotd
)を作成します。
service otd { type = UNLISTED disable = no socket_type = stream protocol = tcp user = root wait = no port = 80 redirect = 127.0.0.1 8080 }
このエントリにより、ポート80
で受けたすべての受信TCPトラフィックがローカル・マシンのポート8080
にリダイレクトされます。
詳細は、Linux xinetd
ドキュメントを参照してください。
Oracle Traffic Directorインスタンスの起動時、特定のパラメータの値(キープ・アライブ接続の最大数、接続キューのサイズ、オリジン・サーバーへの最大接続数)が、システムのファイル・ディスクリプタ制限に基づき自動的に割り当てられます。
ファイル・ディスクリプタ制限が非常に高い場合、未定義パラメータに自動割り当てされる値は、必要以上に高くなり、その結果、Oracle Traffic Directorで過度なメモリー量が消費されます。この問題を回避するには、キープ・アライブ接続の最大数(15.5.3項「キープ・アライブ設定のチューニング」)、接続キューのサイズ(15.3.4項「スレッド・プールおよび接続キュー設定のチューニング」)および個々のオリジン・サーバーへの最大接続数(6.3項「オリジン・サーバーの変更」)を明示的に構成します。
このLinuxのオペレーティング・システム・エラーは、割り当てられたファイル・ディスクリプタ数がシステムの制限に到達すると発生します。
次のメッセージがサーバー・ログに書き込まれます。
[ERROR:16] [OTD-10546] Insufficient file descriptors for optimum configuration.
このエラーを回避するには、Linuxのファイル・ディスクリプタ制限をデフォルトの1024から合理的な数に増やします。詳細は、15.2項「ファイル・ディスクリプタ制限のチューニング」を参照してください。
このエラーは、構成の一時ディレクトリを変更した後、インスタンスを停止せずに変更デプロイし、その後インスタンスを停止しようとすると発生します。一時ディレクトリは、構成のインスタンスのプロセスIDおよびソケット情報が格納される(管理ノード上)のディレクトリです。
このエラーが発生すると、次のメッセージがサーバー・ログに書き込まれます。
OTD-63585 An error occurred while stopping the server. For details, see the server log.
このエラーを回避する手順
構成の一時ディレクトリを変更した場合、構成のすべてのインスタンスをまず停止して、変更をデプロイし、次にインスタンスを起動します。
この問題を回避する手順
Oracle Traffic Directorインスタンスを停止します。
次のいずれかを実行して、構成の現在の一時ディレクトリを検出します。
次の例に示すように、otd_getConfigurationProperties
WLSTコマンドを実行します。
props = {} props['configuration'] = 'foo' otd_getConfigurationProperties(props) temp-path=/tmp/net-test-a46e5844 ...
Fusion Middleware Controlにログインし、必要な構成を選択して「詳細設定」を選択します。結果のページで、「一時ディレクトリ」フィールドを探します。
一時ディレクトリへのパスを記録します。
次のコマンドを実行して、実行中のインスタンスのプロセスIDを検出します。
cat temp_dir/pid
temp_dir
は、手順1で記録した一時ディレクトリへのフル・パスです。
このコマンドによって戻されるプロセスIDを記録します。
次のコマンドを実行して、プロセスを停止します。
kill pid
pid
は、手順2で記録したプロセスIDです。
Linuxシステムでは、デフォルトで/etc/cron.daily/tmpwatch
にあるcronスクリプトtmpwatchが毎日実行されるように設定されています。このスクリプトは、管理サーバー上のすべての/tmp
ディレクトリから240時間(10日)経過したファイルをすべて削除します。そのため、管理サーバーを10日間再起動しなかった場合、デフォルトpidファイルが削除されます。これは、10日後に管理サーバーを再起動できなくなることを意味します。
この問題を回避するには
temp-path
の場所を変更する: <otd-home>/admin-server/config/server.xml
ファイルで、temp-path
の値をサーバー・ユーザーが排他的な権限を持つ場所に変更します。たとえば、<temp-path>/var/tmp/https-test-1234</temp-path>
に変更します。加えて、新しいtemp-path
がtmpwatchスクリプトによって監視されないようにします。
cronスクリプトを変更する: cronスクリプトからtmpwatchの値240 /tmp
を削除します。tmpwatchの監視対象からディレクトリを除外するには、-X
/--exclude-pattern
オプションを使用します。このオプションの詳細は、tmpwatchのmanページを参照してください。
Oracle Traffic Directorではセッションの固定性が次のように維持されます。
Cookieベースのセッション持続
これは一般的なシナリオで、クライアントがWebサーバーやアプリケーション・サーバーからのcookieを受け入れる場合です。このシナリオでは、Oracle Traffic DirectorはHTTPトラフィックのロード・バランシングを行う際に、自身のcookieを使用してセッションを持続します。これにより、固定性リクエストつまりHTTPセッションcookieが含まれているリクエストは、そのcookieの生成元であるバックエンド・アプリケーション・サーバーに常にルーティングされます。
Oracle Traffic Director 11. 1.1.5を使用している場合で、バックエンド・アプリケーション・サーバーがデフォルトのJSESSIONID
以外のHTTPセッションcookieを使用している場合は、セッション持続が履行されるようOracle Traffic Directorを明示的に構成する必要があります。一方、Oracle Traffic Director 11.1.1.6の場合は、オリジン・サーバーからcookieを受信した時点でセッション持続が履行されます。
注意: Oracle Traffic DirectorでURIベースのセッション固定性を維持するには、WebLogic 10.3.xにパッチを追加する必要があります。 |
URIベースのセッション持続
このシナリオはあまり一般的ではありません。このシナリオではクライアント側でcookieが無効にされているため、バックエンドのWebサーバーまたはアプリケーション・サーバー側でURIにHTTPセッション情報を付加してセッション持続を維持します。
このシナリオでは、バックエンド・アプリケーション・サーバーによってURIにOracle Traffic DirectorのJRoute
cookieが付加される場合に、Oracle Traffic Directorでセッション持続を履行できます。WebLogic Server 10.3.6.2以上、12.1以上、GlassFish 2.0以上などのオリジン・サーバーには、このJRoute
cookieをURIに付加する機能が備わっています。そのため、Oracle Traffic DirectorでURIベースのセッション持続を維持できるのは、これらのオリジン・サーバーを使用している場合に限定されます。
この項には次のサブセクションが含まれます:
16.3.3項「初めてFusion Middleware Controlにアクセスする際、証明書の警告が表示されるのはなぜですか。」
16.3.5項「Fusion Middleware Controlで、構成の保存と構成のデプロイにはどのような違いがありますか。」
16.3.6項「Fusion Middleware Controlで「デプロイメント保留中」のメッセージが表示されるのはなぜですか。」
16.3.7項「Fusion Middleware Controlで「インスタンス構成デプロイ済」のメッセージが表示されるのはなぜですか。」
16.3.13項「プール内のオリジン・サーバーをOracle WebLogic Serverに変更した後、これらは自動検出されませんが、動的検出は有効です。なぜですか。」
16.3.14項「Oracle Traffic Directorによって送受信されたリクエストおよびレスポンス・ヘッダーを表示するにはどのようにすればよいですか。」
16.3.15項「Oracle Traffic DirectorインスタンスのSSL/TLSの有効化はどのように行いますか。」
16.3.18項「SSL/TLSが有効なOracle Traffic Directorインスタンスへのテスト・リクエストの発行はどのように行いますか。」
16.3.20項「Oracle Traffic DirectorインスタンスとOracle WebLogic Serverオリジン・サーバー間のSSL/TLS通信の詳細の表示はどのように行いますか。」
16.3.21項「SSL/TLSが有効な特定のオリジン・サーバーは、起動しているにもかかわらず、ヘルス・チェックの後オフラインとマークされるのはなぜですか。」
16.3.22項「Oracle Traffic Directorはオリジン・サーバーにリクエストを転送する前にクライアントのソースIPアドレスを書き換えますか。」
16.3.23項「Oracle Traffic Directorから405ステータス・コードが返されるのはなぜですか。」
16.3.23項「Oracle Traffic Directorから405ステータス・コードが返されるのはなぜですか。」
Oracle Traffic Director用語としての構成は、Oracle Traffic Directorインスタンスの実行時の動作を決定する一連の構成可能な要素(メタデータ)を指します。
詳細は、1.4項「Oracle Traffic Director用語集」を参照してください。
1.7.2項「Fusion Middleware Controlの表示」を参照してください。
管理サーバーに自己署名証明書があるため、ブラウザによって警告が表示されます。続行するには、証明書を信頼することを選択する必要があります。
Fusion Middleware ControlまたはWLSTのいずれかを使用して構成を編集すると、構成ストア内のファイルが自動的に更新されます。Oracle Traffic Directorドキュメントに指示されている場合を除き、構成ストア内のファイルを手動で編集しないでください。
構成の変更を有効にするには、3.3項「構成の変更のアクティブ化」の説明に従ってインスタンスに対する構成をアクティブにする必要があります。
構成を保存すると、行った変更が管理サーバーの構成ストア内に保存されます。構成のインスタンスに変更を反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成をアクティブにする必要があります。
「デプロイメント保留中」のメッセージは、構成を変更して管理サーバーに保存する際に、Fusion Middleware Controlに表示されます。これは、変更が、構成のインスタンスにはまだコピーされていないことを示します。
必要な構成変更を終えたら、3.3項「構成の変更のアクティブ化」の説明に従い、Fusion Middleware Controlで「変更のデプロイ」をクリックするか、activate
WLSTコマンドを実行することで、変更をすべてのインスタンスにデプロイできます。
インスタンスの構成ファイルを手動で編集すると、インスタンス構成デプロイ済のメッセージがFusion Middleware Controlに表示されます。これは、1つ以上のインスタンスの構成ファイルが、管理サーバーの構成ストア内に格納されている、対応する構成ファイルと異なっていることを示します。
Fusion Middleware Controlセッションは、30分間非アクティブな状態が続くと自動的に終了します。再度ログインする必要があります。
1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。
WLSTは、管理サーバーのSSLポートに接続されます。管理サーバーには、自己署名証明書があります管理サーバーに最初に接続するときに表示されるメッセージは、証明書を信頼するかどうかを選択するためのプロンプトです。正しいサーバーおよびポートに接続されていることを確認し、y
を入力して証明書を信頼します。その後のCLIの起動では、警告メッセージは表示されません。
--help
オプションを使用してコマンドを実行し、コマンドのヘルプを参照してください。
動的検出が有効な場合、Oracle Traffic Directorは、指定された間隔で、特定のヘッダーを含むHTTPリクエストを送信する必要があり、このヘッダーにより、プール内の指定されたオリジン・サーバーがOracle WebLogic Serverインスタンスであるかどうか、およびサーバーがクラスタに属しているかどうかが判別されます。TCPヘルス・チェック・リクエストに対するレスポンスでは、Oracle WebLogic Serverインスタンスの存在を特定するための十分な情報が提供されません。したがって、動的検出が有効な場合、ヘルス・チェック・プロトコルはHTTPに設定されている必要があります。
動的検出が有効な場合、Oracle Traffic Directorインスタンスが起動すると、構成済のオリジン・サーバーがOracle WebLogic Serverインスタンスであるかどうかが判別されます。
このため、たとえば、当初Oracle GlassFish Serverインスタンスをオリジン・サーバーとして構成していた場合、起動時にOracle Traffic Directorによって、オリジン・サーバーはOracle WebLogic Serverインスタンスではないことが判別されます。その後、オリジン・サーバーをOracle WebLogic Serverインスタンスで置き換え、次にOracle Traffic Directorにオリジン・サーバーが現在Oracle WebLogic Serverインスタンスであることをあらためて認識させるには、Oracle Traffic Directorインスタンスを再起動するか、再構成する必要があります。
再起動せずに、Oracle WebLogic Serverインスタンスから別のサーバーへ変更する、またその逆を実行するには、次の操作を行います。
必要なオリジン・サーバーで新しいオリジン・サーバー・プールを作成し、古いプールを削除します。詳細は、第5章「オリジン・サーバー・プールの管理」を参照してください。
7.4項「ルートの構成」の説明に従い、新しいプールをポイントするように適切なルートを更新します。
4.4項「再起動が不要なOracle Traffic Directorインスタンスの更新」の説明に従い、softRestart
WLSTコマンドを使用して、Oracle Traffic Directorを再構成します。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、適切なルートを変更し、サーバー・ログへのリクエストおよびレスポンス・ヘッダーの記録を有効にできます。
Fusion Middleware Controlの使用
1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
ルートを構成する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。
ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを編集する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。選択された仮想サーバーに現在定義されているルートがリストされます。
構成するルートの「名前」をクリックします。
ルート設定ページが表示されます。
ルート設定ページの「詳細設定」セクションに移動し、「オリジン・サーバーとの接続用のクライアント構成」サブセクションにスクロール・ダウンします。
「ログ・ヘッダー」チェック・ボックスを選択します。
「OK」をクリックします。
WLSTの使用
次の例に示すように、otd_setRouteProperties
コマンドを実行します。
props = {} props['configuration'] = 'foo' props['virtual-server'] = 'bar' props['route'] = 'route-1' props['log-headers'] = 'true' otd_setRouteProperties(props)
このコマンドにより、構成foo
の仮想サーバーbar
内のroute-1
という名前のルートと関連付けられているオリジン・サーバーとの間でOracle Traffic Directorが送受信するヘッダーのロギングが有効化されます。
この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。
次の例に示すように、ヘッダーはサーバー・ログに記録されます。
[2011-11-11T03:45:00.000-08:00] [net-test] [NOTIFICATION] [OTD-11008] [] [pid: 8184] for host 10.177.243.152 trying to OPTIONS / while trying to GET /favicon.ico, service-http reports: request headers sent to origin server(soa.example.com:1900) :[[ OPTIONS / HTTP/1.1 Proxy-agent: Oracle-Traffic-Director/12.2.1.0 Surrogate-capability: otd="Surrogate/1.0" Host: dadvma0178:1900 Proxy-ping: true X-weblogic-force-jvmid: unset Via: 1.1 net-test Connection: keep-aliv e ]] [2011-11-11T03:45:00.000-08:00] [net-test] [NOTIFICATION] [OTD-11009] [] [pid: 8184] for host 10.177.243.152 trying to OPTIONS / while trying to GET /favicon.ico, service-http reports: response headers received from origin server(soa.example.com:1900) :[[ HTTP/1.1 200 OK date: Fri, 11 Nov 2011 11:45:00 GMT server: Apache/2.2.17 (Unix) allow: GET,HEAD,POST,OPTIONS,TRACE content-length: 0 keep-alive: timeout=5, max=100 connection: Keep-Alive content-type: text/html]
10.1.4項「リスナーのSSL/TLS暗号の構成」を参照してください。
10.3.4項「証明書のリストの表示」を参照してください。
次のコマンドを実行します。
$ openssl s_client -host hostname -port portnumber -quiet
-quiet
オプションを省略すると、SSL/TLS接続についての情報(サーバーDN、証明書名、ネゴシエート済暗号スイート)が表示されます。
特定の暗号でテストするには、-cipher
オプションを指定します。
SSL/TLS接続が確立された後、次の例に示すように、HTTPリクエストを入力します。
GET /
詳細は、s_client
manページを参照してください。
SSL/TLS接続上のリクエストおよびレスポンスを監視するいくつかのツールを使用できます。ツールの1つの例として、ssltap
がありますが、このツールは、クライアントとOracle Traffic Director間のシンプルなプロキシとして機能し、転送される接続に関する情報を表示します。
次のコマンドを実行します。
$ ssltap -l -s otd_host:otd_port
たとえば、クライアントと、SSL/TLSが有効なOracle Traffic Directorリスナーsoa.example.com:1905
間の通信を監視するには、次のコマンドを実行します。
$ ssltap -l -s soa.example.com:8080
次のメッセージが表示されます:
Looking up "localhost"... Proxy socket ready and listening
デフォルトでは、ssltap
はポート1924をリスニングします。ブラウザを使用して、https://localhost:1924
を接続します。
次のような出力が表示されます。
Connection #1 [Tue Oct 25 04:29:46 2011] Connected to localhost:8080 --> [ (177 bytes of 172) SSLRecord { [Tue Oct 25 04:29:46 2011] type = 22 (handshake) version = { 3,1 } length = 172 (0xac) handshake { type = 1 (client_hello) length = 168 (0x0000a8) ClientHelloV3 { client_version = {3, 1} random = {...} session ID = { length = 0 contents = {...} } cipher_suites[29] = { (0x00ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA (0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA (0x0039) TLS/DHE-RSA/AES256-CBC/SHA (0x0038) TLS/DHE-DSS/AES256-CBC/SHA (0xc00f) TLS/ECDH-RSA/AES256-CBC/SHA (0xc005) TLS/ECDH-ECDSA/AES256-CBC/SHA (0x0035) TLS/RSA/AES256-CBC/SHA (0xc007) TLS/ECDHE-ECDSA/RC4-128/SHA (0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA (0xc011) TLS/ECDHE-RSA/RC4-128/SHA (0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA (0x0033) TLS/DHE-RSA/AES128-CBC/SHA (0x0032) TLS/DHE-DSS/AES128-CBC/SHA (0xc00c) TLS/ECDH-RSA/RC4-128/SHA (0xc00e) TLS/ECDH-RSA/AES128-CBC/SHA (0xc002) TLS/ECDH-ECDSA/RC4-128/SHA (0xc004) TLS/ECDH-ECDSA/AES128-CBC/SHA (0x0004) SSL3/RSA/RC4-128/MD5 (0x0005) SSL3/RSA/RC4-128/SHA (0x002f) TLS/RSA/AES128-CBC/SHA (0xc008) TLS/ECDHE-ECDSA/3DES-EDE-CBC/SHA (0xc012) TLS/ECDHE-RSA/3DES-EDE-CBC/SHA (0x0016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA (0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA (0xc00d) TLS/ECDH-RSA/3DES-EDE-CBC/SHA (0xc003) TLS/ECDH-ECDSA/3DES-EDE-CBC/SHA (0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA (0x000a) SSL3/RSA/3DES192EDE-CBC/SHA } compression[1] = { (00) NULL } extensions[55] = { extension type server_name, length [29] = { 0: 00 1b 00 00 18 64 61 64 76 6d 61 30 31 37 38 2e | .....soa. 10: 75 73 2e 6f 72 61 63 6c 65 2e 63 6f 6d | example.com } extension type elliptic_curves, length [8] = { 0: 00 06 00 17 00 18 00 19 | ........ } extension type ec_point_formats, length [2] = { 0: 01 00 | .. } extension type session_ticket, length [0] } } } }
これは、ブラウザからOracle Traffic Directorインスタンスに送信されるSSL/TLSのclient helloです。ブラウザから送信される暗号スイートのリストに注目してください。これは、ブラウザが処理するように構成された暗号スイートであり、プリファレンスの順序でソートされています。サーバーは、ハンドシェイク用の暗号スイートを選択します。クライアントによって指定された暗号スイートのいずれもサーバーに構成されていない場合、接続は失敗します。前述の例では、セッションIDが空ですが、これは指定されたサーバーとのキャッシュ済SSL/TLSセッションがブラウザにないことを示します。
Oracle Traffic Directorインスタンスのレスポンスは、次の出力のようになります。
<-- [ (823 bytes of 818) SSLRecord { [Tue Oct 25 04:29:46 2011] type = 22 (handshake) version = { 3,1 } length = 818 (0x332) handshake { type = 2 (server_hello) length = 77 (0x00004d) ServerHello { server_version = {3, 1} random = {...} session ID = { length = 32 contents = {...} } cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA compression method = (00) NULL extensions[5] = { extension type renegotiation_info, length [1] = { 0: 00 | . } } } type = 11 (certificate) length = 729 (0x0002d9) CertificateChain { chainlength = 726 (0x02d6) Certificate { size = 723 (0x02d3) data = { saved in file 'cert.001' } } } type = 14 (server_hello_done) length = 0 (0x000000) } } ] --> [
サーバーは、クライアントによって後続のリクエストに含められる暗号スイートTLS/RSA/AES256-CBC/SHA
とセッションIDを選択しました。
また、サーバーは、ブラウザが確認するための証明書チェーンも送信しました。ssltap
によって証明書がファイルcert.001
に保存されました。X.509証明書を解析できる任意のツールを使用して証明書を検査できます。たとえば、次のようなコマンドを実行します。
$ openssl x509 -in cert.001 -text -inform DER
注意: ssltap は、シングル・スレッドのプロキシ・サーバーです。したがって、これを使用して複数のリクエストを発行すると、リクエストはシリアライズされます。SSL/TLSを使用した同時リクエストでのみ発生する、アプリケーションの特定の問題を分析する必要がある場合、複数のssltap インスタンスを実行してください。 |
サーバーの起動スクリプトに-Dssl.debug=true
システム・プロパティを追加することで、Oracle WebLogic ServerインスタンスのSSLデバッグを構成します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLのデバッグに関する項を参照してください。
11.3項「ログ・プリファレンスの構成」の説明に従い、ログ・レベルをTRACE:32
に設定し、Oracle Traffic Directorサーバー・ログの冗長度を高めてください。
このエラーは、次のオリジン・サーバーで発生する可能性があります。
ホスト名ではなくIPアドレスを使用して、オリジン・サーバー・プールに構成されているSSL/TLSが有効なオリジン・サーバー。
動的に検出された、SSL/TLSが有効なOracle WebLogic Serverオリジン・サーバー。Oracle Traffic Directorは、ホスト名ではなくIPアドレスを使用してこのサーバーを参照します。
Oracle Traffic Directorは、IPアドレスを使用してこのようなオリジン・サーバーを参照しますが、オリジン・サーバーの証明書には、サーバーのホスト名が含まれています。したがって、ヘルス・チェック・リクエストに対して、オリジン・サーバーが証明書を提示すると、Oracle Traffic Directorはそれらの検証を試みますが成功しません。SSL/TLSハンドシェイクが失敗します。結果として、ヘルス・チェックでは、このようなオリジン・サーバーはオフラインと示されます。サーバー証明書の検証は、デフォルトで有効化されていることに注意してください。
サーバー・ログ・レベルをTRACE:32
に設定すると、この障害について記録された、次の例に示すようなメッセージを表示できます。
[2011-11-21T09:50:54-08:00] [net-soa] [TRACE:1] [OTD-10969] [] [pid: 22466] trying to OPTIONS /, service-http reports: error sending request (SSL_ERROR_BAD_CERT_DOMAIN: Requested domain name does not match the server's certificate.)
この問題を解決するには、次の例に示すように、otd_setOriginServerPoolSslProperties
WLSTコマンドを実行し、オリジン・サーバーのオリジン・サーバー証明書の検証を無効にします。
props = {} props['configuration'] = 'foo' props['origin-server-pool'] = 'origin-server-pool-1' props['validate-server-cert'] = 'false' otd_setOriginServerPoolSslProperties(props)
この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。
Oracle Traffic DirectorはデフォルトでソースIPアドレスを書き換えます。それでも、クライアントIPアドレスはProxy-client-ip
という追加のリクエスト・ヘッダーで送信されます。7.4項「ルートの構成」の説明に従って適切なルートを構成することで、Proxy-client-ip
やその他のリクエスト・ヘッダーをブロックしたり転送したりするようにOracle Traffic Directorを設定できます。
HTTPリクエスト・ヘッダーをオリジン・サーバーに転送する際、Oracle Traffic Directorは大文字小文字の区別を維持できません。
HTTPリクエストが定義済ルートに指定されている条件に一致せず、構成にデフォルト(=unconditional)のルートが含まれていない場合、Oracle Traffic Directorから405ステータス・コードが返されます。このエラーはOracle Traffic Directorがリクエストの適切なルートを見つけられなかったことを意味しています。この状況は、obj.conf構成ファイル内でデフォルト・ルート(リクエストが他のどのルートの指定条件にも一致しなかった場合に使用されるルート)が手動で削除された場合にのみ発生する可能性があります。この問題を解決するには、管理者が適切なルートを作成する必要があります。
注意: デフォルトのルート(=unconditional)は、Fusion Middleware ControlやWLSTでは削除できず、また、手動では削除しないでください。 |
オラクル社とサービス契約を結んでいる場合、Oracle Traffic Directorの問題について、Oracleサポート(http://support.
)に問合せできます。
Oracleサポートに連絡する前に
Oracleサポートに連絡する前に、次のことを行ってください:
このドキュメント(Oracle Traffic Director管理者ガイド)に記載されている適切な診断およびトラブルシューティングのガイドラインをすべて試してください。
発生している問題、または類似する問題が、OTNのディスカッション・フォーラム(http://forums./
)ですでに話し合われていないかどうか確認してください。
フォーラムで参照できる情報だけでは問題を解決できない場合は、フォーラムに質問を投稿します。フォーラムの他のOracle Traffic Directorユーザーが質問に答えてくれる場合があります。
可能な限り、問題が発生する前に実行した一連の操作を記述してください。
可能な場合、システムの元の状態をリストアし、記述した手順を使用して問題の再現を試みてください。再現可能な問題か、間欠的に起こる問題かが、これで確認できます。
問題を再現できる場合は、問題を再現する手順の絞込みを行います。小規模なテスト・ケースで再現できる問題は、大規模なテスト・ケースと比較すると一般的に診断が容易です。
問題を再現する手順の絞込みによって、Oracleサポートは可能性のある問題の解決策をより迅速に提供できます。
Oracleサポートに提供する必要がある情報
Oracleサポートに連絡する際には、次の情報を提供してください。
Oracle Traffic Directorのリリース番号。
問題が発生する直前に実行した操作など、問題についての簡単な説明。
管理インタフェースを使用したサポートが必要な場合、ヘルプを必要とするコマンドライン・サブコマンドの名前、またはFusion Middleware Control画面のタイトル。
エラーが発生した構成の構成ファイルが含まれるZipファイル。
INSTANCE_HOME/admin-server/config-store/config_name/current.zip
エラーのない構成の構成ファイルが含まれるZipファイル。
INSTANCE_HOME/admin-server/config-store/config_name/backup/date_time.zip
最新のサーバーおよびアクセス・ログ・ファイル。
注意: Oracleサポートにファイルを送る場合、Oracleサポートの担当者が、問題のトラブルシューティングにファイルを使用する前にその整合性を確認できるように、各ファイルにMD5チェックサム値を指定するようにしてください。 |