| Oracle® Traffic Director管理者ガイド 11g リリース1 (11.1.1.9) B66436-05 |
|
 前 |
 次 |
この項には次の項目が含まれています。
16.3.11項「tadm --user=admin --host=myhostサブコマンドでは、なぜ指定したサブコマンドが実行されず、コマンド・シェルが起動されるのですか。」
16.3.14項「CLIへのアクセス時、パスワード入力のプロンプトが毎回表示されないようにCLIを構成することはできますか。」
16.3.16項「プール内のオリジン・サーバーをOracle WebLogic Serverに変更した後、これらは自動検出されませんが、動的検出は有効です。なぜですか。」
16.3.17項「Oracle Traffic Directorによって送受信されたリクエストおよびレスポンス・ヘッダーを表示するにはどのようにすればよいですか。」
16.3.18項「Oracle Traffic DirectorインスタンスのSSL/TLSの有効化はどのように行いますか。」
16.3.21項「SSL/TLSが有効なOracle Traffic Directorインスタンスへのテスト・リクエストの発行はどのように行いますか。」
16.3.23項「Oracle Traffic DirectorインスタンスとOracle WebLogic Serverオリジン・サーバー間のSSL/TLS通信の詳細の表示はどのように行いますか。」
16.3.24項「SSL/TLSが有効な特定のオリジン・サーバーは、起動しているにもかかわらず、ヘルス・チェックの後オフラインとマークされるのはなぜですか。」
16.3.25項「Oracle Traffic Directorはオリジン・サーバーにリクエストを転送する前にクライアントのソースIPアドレスを書き換えますか。」
16.3.26項「Oracle Traffic Directorから405ステータス・コードが返されるのはなぜですか。」
「CLIを使用した管理者のユーザー名およびパスワードの変更」の説明に従い、reset-admin-password CLIコマンドを実行します。
Oracle Traffic Director用語としての構成は、Oracle Traffic Directorインスタンスの実行時の動作を決定する一連の構成可能な要素(メタデータ)を指します。
詳細は、1.4項「Oracle Traffic Director用語集」を参照してください。
2.3.2項「管理コンソールへのアクセス」を参照してください。
管理サーバーに自己署名証明書があるため、ブラウザによって警告が表示されます。続行するには、証明書を信頼することを選択する必要があります。
構成ストア内のファイルは、管理コンソールまたはCLIのいずれかを使用して構成を編集すると、自動的に更新されます。Oracle Traffic Directorドキュメントに指示されている場合を除き、構成ストア内のファイルを手動で編集しないでください。
構成の変更を有効にするには、4.3項「構成のデプロイ」の説明に従い、構成をインスタンスにデプロイする必要があります。
インスタンスの構成ファイルを誤って編集した場合、および変更を保持し、構成のすべてのインスタンスにレプリケートする場合、4.5項「管理サーバーとノード間の構成の同期化」の説明に従い、構成をインスタンスから管理サーバーにプルできます。
構成を保存すると、行った変更が管理サーバーの構成ストア内に保存されます。構成のインスタンスに変更を反映するには、4.3項「構成のデプロイ」の説明に従い、構成をデプロイする必要があります。
「デプロイメント保留中」のメッセージは、構成を変更して、管理サーバーに保存する際に、管理コンソールに表示されます。これは、変更が、構成のインスタンスにはまだコピーされていないことを示します。
必要な構成変更を終えたら、4.3項「構成のデプロイ」の説明に従い、管理コンソールで「変更のデプロイ」をクリックするか、deploy-config CLIコマンドを実行することで、変更をすべてのインスタンスにデプロイできます。
インスタンスの構成ファイルを手動で編集すると、インスタンス構成デプロイ済のメッセージが管理コンソールに表示されます。これは、1つ以上のインスタンスの構成ファイルが、管理サーバーの構成ストア内に格納されている、対応する構成ファイルと異なっていることを示します。この場合に実行する必要のある操作の詳細は、4.5項「管理サーバーとノード間の構成の同期化」を参照してください。
管理コンソール・セッションが30分間非アクティブな状態が続いた場合、自動的に終了します。再度ログインする必要があります。
2.3.1項「コマンドライン・インタフェースへのアクセス」を参照してください。
指定したCLIサブコマンドが実行されるようにするには、--user、--hostなどの共通オプションを含むすべてのオプションの前にサブコマンドを指定する必要があります。そうしない場合、CLIでは、シェル・モードを起動しようとしていると見なされます。
CLIは、管理サーバーのSSLポートに接続されます。管理サーバーには、自己署名証明書があります管理サーバーに最初に接続するときに表示されるメッセージは、証明書を信頼するかどうかを選択するためのプロンプトです。正しいサーバーおよびポートに接続されていることを確認し、yを入力して証明書を信頼します。その後のCLIの起動では、警告メッセージは表示されません。
--helpオプションを使用してコマンドを実行し、コマンドのヘルプを参照してください。
はい。tadm_password=passwordの形式でファイルにパスワードを格納します。CLIコマンドを実行する際、--password-fileを使用して、パスワード・ファイルへのフル・パスを指定します。
動的検出が有効な場合、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インスタンスから別のサーバーへ変更する、またその逆を実行するには、次の操作を行います。
必要なオリジン・サーバーで新しいオリジン・サーバー・プールを作成し、古いプールを削除します。詳細は、第6章「オリジン・サーバー・プールの管理」を参照してください。
8.4項「ルートの構成」の説明に従い、新しいプールをポイントするように適切なルートを更新します。
5.4項「再起動が不要なOracle Traffic Directorインスタンスの更新」の説明に従い、reconfig-instance CLIコマンドを使用して、Oracle Traffic Directorを再構成します。
管理コンソールまたはCLIのいずれかを使用して、適切なルートを変更し、サーバー・ログへのリクエストおよびレスポンス・ヘッダーの記録を有効化できます。
管理コンソールの使用
2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。
ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。
ルートを構成する構成を選択します。
ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを構成する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。選択された仮想サーバーに現在定義されているルートがリストされます。
構成するルートの「名前」をクリックします。
ルート設定ページが表示されます。
ルート設定ページの「詳細設定」セクションに移動し、「オリジン・サーバーとの接続用のクライアント構成」サブセクションにスクロール・ダウンします。
「ログ・ヘッダー」チェック・ボックスを選択します。
「保存」をクリックします。
「変更のデプロイ」をクリックします。
CLIの使用
次の例に従い、set-route-propコマンドを実行します。
tadm> set-route-prop --config=soa --vs=soa.example.com --route=default-route log-headers=true
このコマンドにより、構成soaの仮想サーバーsoa.example.com内のdefault-routeという名前のルートと関連付けられているオリジン・サーバーとの間でOracle Traffic Directorが送受信するヘッダーのロギングが有効化されます。
更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイします。
この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。
次の例に示すように、ヘッダーはサーバー・ログに記録されます。
[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/11.1.1.7 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]
11.2.4項「リスナーのSSL/TLS暗号の構成」を参照してください。
11.4.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のデバッグに関する項を参照してください。
12.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.)
この問題を解決するには、次の例に従い、set-route-prop CLIコマンドを実行して、必要な仮想サーバー・ルートのオリジン・サーバー証明書の検証を無効化します。
tadm> set-route-prop --config=soa --vs=vs1 --route=route1 validate-server-cert=false
更新されたルートを有効にするには、次の例に従い、deploy-configコマンドを実行して構成をデプロイします。
tadm> deploy-config soa
この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。
Oracle Traffic DirectorはデフォルトでソースIPアドレスを書き換えます。それでも、クライアントIPアドレスはProxy-client-ipという追加のリクエスト・ヘッダーで送信されます。8.4項で説明するとおり適切なルートを構成することで、Proxy-client-ipやその他のリクエスト・ヘッダーをブロックしたり転送したりするようOracle Traffic Directorを設定できます。
HTTPリクエスト・ヘッダーをオリジン・サーバーに転送する際、Oracle Traffic Directorは大文字小文字の区別を維持できません。
HTTPリクエストが定義済ルートに指定されている条件に一致せず、構成にデフォルト(=unconditional)のルートが含まれていない場合、Oracle Traffic Directorから405ステータス・コードが返されます。このエラーはOracle Traffic Directorがリクエストの適切なルートを見つけられなかったことを意味しています。この状況は、obj.conf構成ファイル内でデフォルト・ルート(リクエストが他のどのルートの指定条件にも一致しなかった場合に使用されるルート)が手動で削除された場合にのみ発生する可能性があります。この問題を解決するには、管理者が適切なルートを作成する必要があります。
|
注意: デフォルト(=unconditional)のルートは管理コンソールやCLIで削除することはできません。また、手動で削除しないようにしてください。 |
Oracle Traffic Directorリリース11.1.1.9は、サポートするJDKの最小バージョンとしてJDK 7 u60を必要とします。Oracle Traffic Director 11.1.1.6は、それ自体の管理のためにJDKをバンドルしました。Oracle Traffic Director 11.1.1.9はJDK 7をバンドルしています。
次の手順で、JDKインストールのステータスを確認します。
Oracle Traffic Director 11.1.1.6/7のインストール時に、自分でインストールしたJDKを使用しなかった場合には、Oracle Traffic Director 11.1.1.9にアップグレードする際にJDKのバージョンを考慮する必要はありません。
Oracle Traffic Director 11.1.1.6/.7のインストール時に、自分でインストールしたJDKを使用した場合には、Oracle Traffic Director 11.1.1.9にアップグレードする際にJDKのバージョンとしてJDKバージョン7アップデート60またはそれ以上を準備する必要があります。
JAVA_HOME変数を適切に設定することも必要です。使用中の環境でJAVA_HOMEをJDK 6に設定していて、Oracle Traffic Director CLIコマンドを実行すると、次のエラーが表示される可能性があります。
$ORACLE_HOME/bin/tadm configure-server --user=user1 --instance-home=$INSTANCE_HOME/instance1 --server-user=root
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/sun/web/admin/cli/shelladapter/WSadminShell : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: com.sun.web.admin.cli.shelladapter.WSadminShell. Program will exit.
回避策: 使用中の環境でJAVA_HOMEを削除します。
