| Oracle® Real User Experience Insightユーザーズ・ガイド リリース11.1 for Linux x86-64 B63041-01 |
|
 前へ |
 次へ |
この付録では、RUEIシステムをネットワーク・アドレス変換(NAT)デバイスの後に配置した場合に、どのようにして正確なネットワーク・トラフィック・レポートを作成できるかについて説明します。
『Oracle Real User Experience Insightインストレーション・ガイド』で説明しているように、RUEIでネットワーク・トラフィックのコピーを確認できることは非常に重要です。これは、コピー/SPANポートまたはTAPデバイスを使用して取得できます。
図O-1に、カスケード接続されたデバイスの代表的構成を示します。実際には、デバイス数ではこの図と異なる場合があっても、接続の順序は一般にこの図に示すとおりです。ファイアウォール、SSLオフローダ(SSL暗号化トラフィック)およびロード・バランサ機能は、1つまたは2つのコンポーネントに組み込まれています。
ほとんどのネットワークでは、監視対象となる位置は、ファイアウォールのすぐ後ろ(またはすぐ前)、SSLオフローダのすぐ後ろ、およびロード・バランサのすぐ後ろの3つがあります。これらを図O-1に示します。これら3つの監視対象位置の意味を表O-1に示します。
表O-1 監視対象位置の特性
| 位置 | サーバー/情報が使用可能か | クライアント/情報が使用可能か | SSL証明書が必要か |
|---|---|---|---|
|
1 |
ヘッダーでの応答に入れる場合のみ |
はい |
はい脚注1 |
|
2 |
ヘッダーでの応答に入れる場合のみ |
はい |
いいえ |
|
3 |
はい |
NATデバイスからリクエスト・ヘッダーに入れて配信された場合のみ |
いいえ |
脚注1 SSLオフロード・ポイントの前に配置する場合は、SSL鍵をRUEIコレクタ・システムにアップロードする必要があります。これは、RUEIがSSLトラフィックを復号化できるようにするために必要です。
インターネット・サービスの場合、ロード・バランサは、外部クライアントがサービスにアクセスするために接続するポートをリスニングします。ロード・バランサはリクエストをバックエンド・サーバーの1つに転送し、通常、バックエンド・サーバーがロード・バランサに応答します。これにより、内部では機能が分離されていることをクライアントが認識していない場合でも、ロード・バランサがクライアントに応答できるようになります。また、クライアントによるバックエンド・サーバーへの直接アクセスを防止し、社内ネットワークの構造が隠されるため、セキュリティ上の利点もあります。
RUEIシステムをネットワーク・アドレス変換(NAT)デバイスの前に配置することをお薦めします。これにより、RUEIが即座に適用され、エンドユーザーの発信元IPアドレスをTCPレベルで確認します。図O-1に示す構成はネットワークによって異なりますが、NATを実行するのは一般にロード・バランサ・デバイスです。
IPアドレス変換がすでに行われたネットワーク・セグメントにRUEIをデプロイしていて、次の項で説明する構成手順を実行していない場合は、NATデバイスの単一IPアドレスのみがエンドユーザーのIPアドレスとしてレポートされます。これは、レポートされるデータの正確性には悪影響を与えませんが、地理的なクライアント情報およびISPのクライアント情報が使用できなくなることを意味します。
|
注意: RUEIの監視位置は常にVPN/解凍デバイスよりも後ろである必要があります。これは、RUEIが暗号化デバイスと復号化デバイスの間のHTTP以外のトラフィックを読み取ることができないためです。 |
前述したように、発信元のエンドユーザーのIPアドレスを取得することは、正確な地理上のクライアント・レポートおよびISPによるクライアント・レポートを作成するために必要です。RUEIでは、IPアドレスは通常、クライアントから送信されたIPヘッダー・パケットから取得されます。IPパケットには、パケットの送信元および送信先の数値アドレスが含まれます。ただし、RUEIをNATデバイスの後ろに配置している場合は、このIPパケットにはエンドユーザーのIPアドレスでなくNATデバイスのIPアドレスが含まれます。
ただし、発信元の(エンドユーザー)IPアドレスは通常、NATデバイスからWebサーバーに送信されたHTTPヘッダーに保存されています。このような場合は、IPパケットでなくこのヘッダーの中でIPアドレスを検索するようRUEIに指定できます。
IPパケットではなくHTTPヘッダーを使用するように指定する手順は、次のとおりです。
「Configuration」→「Applications」→「Applications」の順に選択します。目的のアプリケーションをクリックします。または、目的のスイートかサービスを選択します。概要が表示されます。
「Advanced」タブ→「Client IP」タブの順にクリックします。
ヘッダーが定義されていない場合は、「Specify HTTP header(s)」項目をクリックします。または、「Edit」をクリックします。図O-2に示すダイアログが表示されます。
「HTTP header」フィールドを使用して、クライアントIPアドレスの取得元のリクエスト・ヘッダーを指定します。次に、「Add」をクリックします。ヘッダーが複数ある場合は、「Move up」と「Move down」コントロールを使用して、試行される順序を指定します。図O-2に示す例では、Akamaiヘッダーが最初に検索されます。ない場合は、HTTP proxyのクライアントIPヘッダーが使用されます。次に、「Save」をクリックします。
クライアントIPアドレスは、指定されたリクエスト・ヘッダーから導出できない場合には、IPヘッダー・パケットから取得されることに注意してください。クライアントIPアドレス・ソースの設定を変更すると、その内容が5～10分後にRUEIに表示されます。また、変更は現在収集されているデータにのみ適用され、履歴データには適用されません。RUEIをNATデバイスの後ろにデプロイしている場合は、HTTPヘッダーからエンドユーザーのIPアドレスを収集するための適切な方法を、アプリケーションおよびインフラストラクチャの管理チームに確認することを強くお薦めします。
応答するサーバーのIPアドレスを確認することも、役に立つ場合があります。たとえば、サーバー・ファームでページが低速か失敗しているという問題が発生した場合、関連するサーバーのIPアドレスが即座に確認可能であれば、この問題の解決までの時間は大幅に短縮されます。
これは、ロード・バランサに返信されるヘッダーに、応答するサーバーのIPアドレス(またはその他のID情報)を挿入すると確認できます。
図O-3にHTTPヘッダーの例を示します。これは、Mozilla FirefoxのLive HTTP headersプラグインのものであり、元のWebサーバーのID(www236)がHTTPヘッダーに移送された様子を示しています。
この例におけるヘッダーの要素名はxserverです。これはカスタム・ディメンションを使用して取得できます。この詳細は、3.11項「カスタム・ディメンションの使用」に記載されています。
