| Oracle® Fusion Middleware Oracle Traffic Directorの管理 12c (12.2.1.2.0) E82687-03 |
|
 前へ |
 次へ |
この項には次のサブセクションが含まれます:
Fusion Middleware Controlで「インスタンス構成デプロイ済」のメッセージが表示されるのはなぜですか。
プール内のオリジン・サーバーをOracle WebLogic Serverに変更した後、これらは自動検出されませんが、動的検出は有効です。なぜですか。
Oracle Traffic Directorによって送受信されたリクエストおよびレスポンス・ヘッダーを表示するにはどのようにすればよいですか。
SSL/TLSが有効なOracle Traffic Directorインスタンスへのテスト・リクエストの発行はどのように行いますか。
Oracle Traffic DirectorインスタンスとOracle WebLogic Serverオリジン・サーバー間のSSL/TLS通信の詳細の表示はどのように行いますか。
SSL/TLSが有効な特定のオリジン・サーバーは、起動しているにもかかわらず、ヘルス・チェックの後オフラインとマークされるのはなぜですか。
Oracle Traffic Directorはオリジン・サーバーにリクエストを転送する前にクライアントのソースIPアドレスを書き換えますか。
Oracle Traffic Director用語としての構成は、Oracle Traffic Directorインスタンスの実行時の動作を決定する一連の構成可能な要素(メタデータ)を指します。
詳細は、「Oracle Traffic Director用語集」を参照してください。
管理サーバーに自己署名証明書があるため、ブラウザによって警告が表示されます。続行するには、証明書を信頼することを選択する必要があります。
Fusion Middleware ControlまたはWLSTのいずれかを使用して構成を編集すると、構成ストア内のファイルが自動的に更新されます。Oracle Traffic Directorドキュメントに指示されている場合を除き、構成ストア内のファイルを手動で編集しないでください。
構成の変更を有効にするには、「構成の変更のアクティブ化」の説明に従ってインスタンスに対する構成をアクティブにする必要があります。
構成を保存すると、行った変更が管理サーバーの構成ストア内に保存されます。構成のインスタンスに変更を反映するには、「構成の変更のアクティブ化」の説明に従って構成をアクティブにする必要があります。
「デプロイメント保留中」のメッセージは、構成を変更して管理サーバーに保存する際に、Fusion Middleware Controlに表示されます。これは、変更が、構成のインスタンスにはまだコピーされていないことを示します。
必要な構成変更を終えたら、「構成の変更のアクティブ化」の説明に従い、Fusion Middleware Controlで「変更のデプロイ」をクリックするか、activate WLSTコマンドを実行することで、変更をすべてのインスタンスにデプロイできます。
インスタンスの構成ファイルを手動で編集すると、インスタンス構成デプロイ済のメッセージがFusion Middleware Controlに表示されます。これは、1つ以上のインスタンスの構成ファイルが、管理サーバーの構成ストア内に格納されている、対応する構成ファイルと異なっていることを示します。
Fusion Middleware Controlセッションは、30分間非アクティブな状態が続くと自動的に終了します。再度ログインする必要があります。
WLSTは、管理サーバーのSSLポートに接続されます。管理サーバーには、自己署名証明書があります管理サーバーに最初に接続するときに表示されるメッセージは、証明書を信頼するかどうかを選択するためのプロンプトです。正しいサーバーおよびポートに接続されていることを確認し、yを入力して証明書を信頼します。その後のWLSTの起動では、警告メッセージは表示されません。
動的検出が有効な場合、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インスタンスから別のサーバーへ変更する、またその逆を実行するには、次の操作を行います。
必要なオリジン・サーバーで新しいオリジン・サーバー・プールを作成し、古いプールを削除します。詳細は、「オリジン・サーバー・プールの管理」を参照してください。
「仮想サーバーのルートの構成」の説明に従い、新しいプールをポイントするように適切なルートを更新します。
「再起動が不要なOracle Traffic Directorインスタンスの更新」の説明に従い、softRestart WLSTコマンドを使用して、Oracle Traffic Directorを再構成します。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、適切なルートを変更し、サーバー・ログへのリクエストおよびレスポンス・ヘッダーの記録を有効にできます。
Fusion Middleware Controlの使用
「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が送受信するヘッダーのロギングが有効化されます。
詳細は、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスのotd_setRoutePropertiesコマンドを参照してください。
次の例に示すように、ヘッダーはサーバー・ログに記録されます。
[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]
次のコマンドを実行します。
$ 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のデバッグを参照してください。
「ログ・プリファレンスの構成」の説明に従い、ログ・レベルを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)
詳細は、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスのotd_setOriginServerPoolSslPropertiesコマンドを参照してください。
Oracle Traffic DirectorはデフォルトでソースIPアドレスを書き換えます。それでも、クライアントIPアドレスはProxy-client-ipという追加のリクエスト・ヘッダーで送信されます。「仮想サーバーのルートの構成」の説明に従って適切なルートを構成することで、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では削除できず、また、手動では削除しないでください。
