機械翻訳について

R NATed Trafficのモニタリング

この付録では、RUEIシステムがネットワーク・アドレス変換(NAT)デバイスの後に配置された場合に、ネットワーク・トラフィックのレポートを正確に取得する方法について説明します。

R.1 NATデバイス前の配置

RUEIではネットワーク・トラフィックのコピーを表示できることが重要です。 これは、コピー/SPANポートまたはTAPデバイスを使用して取得できます。

「図R-1」では、カスケード型デバイスの一般的な構成の概要を示します。 実際には、デバイス数ではこの図と異なる場合があっても、接続の順序は一般にこの図に示すとおりです。 ファイアウォール、SSLオフローダ(SSL暗号化トラフィック)およびロード・バランサ機能は、1つまたは2つのコンポーネントに組み込まれています。

図R-1 モニタリング・デバイスの配置

「図R-1デバイス・モニタリングの配置の説明」

ほとんどのネットワークでは、監視対象となる位置は、ファイアウォールのすぐ後ろ(またはすぐ前)、SSLオフローダのすぐ後ろ、およびロード・バランサのすぐ後ろの3つがあります。 これらは「図R-1」で示されます。 3つの候補者モニタリングのポジションに与える影響の概要については、「表R-1」で説明します。

表R-1 モニタリング・ポジションの特性

ポジション	サーバー/情報が使用可能か	クライアント/情報が使用可能か	SSL証明書が必要か
1	ヘッダーでの応答に入れる場合のみ	はい	あり脚注1
2	ヘッダーでの応答に入れる場合のみ	はい	いいえ
3	はい	NATデバイスからリクエスト・ヘッダーに入れて配信された場合のみ	いいえ

^脚注1

SSLオフロード・ポイントの前のデプロイメントでは、RUEIコレクタ・システムへのSSLキーのアップロードが必要になります。 これは、RUEIがSSLトラフィックを復号化できるようにするために必要です。

インターネット・サービスの場合、ロード・バランサは、外部クライアントがサービスにアクセスするために接続するポートをリスニングします。 ロード・バランサはリクエストをバックエンド・サーバーの1つに転送し、通常、バックエンド・サーバーがロード・バランサに応答します。 これにより、内部では機能が分離されていることをクライアントが認識していない場合でも、ロード・バランサがクライアントに応答できるようになります。 また、クライアントによるバックエンド・サーバーへの直接アクセスを防止し、社内ネットワークの構造が隠されるため、セキュリティ上の利点もあります。

RUEIシステムをネットワーク・アドレス変換(NAT)デバイスの前に配置することをお薦めします。 これにより、RUEIが即座に適用され、エンドユーザーの発信元IPアドレスをTCPレベルで確認します。 「図R-1」で表示される構成はネットワークによって異なる場合がありますが、通常、NATを実行するロード・バランサ・デバイスです。

IPアドレス変換がすでに行われたネットワーク・セグメントにRUEIをデプロイしていて、次の項で説明する構成手順を実行していない場合は、NATデバイスの単一IPアドレスのみがエンドユーザーのIPアドレスとしてレポートされます。 これは、レポートされるデータの正確性には悪影響を与えませんが、地理的なクライアント情報およびISPのクライアント情報が使用できなくなることを意味します。

注意:

RUEIモニタリング位置は常にVPN/圧縮解除デバイスよりも後にする必要があります。 これは、RUEIが暗号化デバイスと復号化デバイスの間のHTTP以外のトラフィックを読み取ることができないためです。

注意:

デバイスが異なるとRUEIデータ収集に対する影響も異なり、監視位置によってはネットワーク・パフォーマンス・メトリックまたはサーバー・パフォーマンス・メトリックのデータが失われる場合があります。 一般に、1の「図R-1」の位置には、最適なクライアント・ネットワーク・パフォーマンス・データが提供されますが、位置3にはサーバーのネットワーク・パフォーマンス・データが最適に提示されます。 たとえば、RUEIの場所として位置3を使用することにした場合、ページがクライアント・ブラウザに配信される前にページ配信の測定が行われることがあります。 この場合、RUEIで間違った(短すぎる)ネットワーク時間がレポートされることがあります。

R.2 エンドユーザーIPアドレスの取得

前述したように、発信元のエンドユーザーのIPアドレスを取得することは、正確な地理上のクライアント・レポートおよびISPによるクライアント・レポートを作成するために必要です。 RUEIでは、IPアドレスは通常、クライアントから送信されたIPヘッダー・パケットから取得されます。 IPパケットには、パケットの送信元および送信先の数値アドレスが含まれます。 ただし、RUEIをNATデバイスの後ろに配置している場合は、このIPパケットにはエンドユーザーのIPアドレスでなくNATデバイスのIPアドレスが含まれます。

ただし、発信元の(エンドユーザー)IPアドレスは通常、NATデバイスからWebサーバーに送信されたHTTPヘッダーに保存されています。 このような場合は、IPパケットでなくこのヘッダーの中でIPアドレスを検索するようRUEIに指定できます。

IPパケットではなくHTTPヘッダーを使用するように指定する手順は、次のとおりです。

1. 構成→アプリケーション→アプリケーションの順に選択します。 目的のアプリケーションをクリックします。 または、目的のスイートまたはサービスを選択します。 概要が表示されます。
2. 拡張タブ→クライアントIPタブの順にクリックします。
3. ヘッダーが定義されていない場合は、HTTPヘッダーの指定項目をクリックします。 または、編集をクリックします。 「図R-2」に示すダイアログを表示します。

   図R-2 クライアントIPソースの編集

   
   「図R-2クライアントIPソースの編集の説明」
4. 追加するヘッダーのタイプを選択します。 「HTTPヘッダー」はHTTPリクエストから導出され、「TCPヘッダー」はTCPオプション・フィールドから導出されます。 現在使用可能なTCPヘッダーはAkamaiのみで、SSL暗号化トラフィックの転送時に使用されます。

   注意:

   これはIpv4アドレスだけをサポートしています。

5. ヘッダーフィールドを使用して、クライアントIPアドレスの取得元のリクエスト・ヘッダーを指定します。 次に、追加をクリックします。 ヘッダーが複数ある場合は、上に移動と下に移動コントロールを使用して、試行される順序を指定します。 「図R-2」に示した例では、Akamaiヘッダーが最初に検索されます。 ない場合は、HTTP proxyのクライアントIPヘッダーが使用されます。 次に、保存をクリックします。

指定されたリクエスト・ヘッダーのいずれかからクライアントIPアドレスを導出できなかった場合、そのアドレスはIPヘッダー・パケットから取得されます。 HTTPヘッダーに複数の論理クライアントIPアドレスが存在する場合は、最初の論理クライアントIPアドレスが取得されます。 クライアントIPアドレス・ソース設定は、変更すると5分から10分後にRUEI内に表示されます。 また、変更は、現在収集されているデータにのみ適用され、履歴データには適用されません。RUEIがNATデバイスの背後にデプロイされている場合は、HTTPヘッダーからエンド・ユーザーIPアドレスを収集するのに適した方法で、アプリケーション管理チームとインフラストラクチャ管理チームの両方を確認して確認することをお薦めします。

R.3 返信中のWebサーバーのIPアドレスの取得

応答するサーバーのIPアドレスを確認することも、役に立つ場合があります。 たとえば、サーバー・ファームでページが低速か失敗しているという問題が発生した場合、関連するサーバーのIPアドレスが即座に確認可能であれば、この問題の解決までの時間は大幅に短縮されます。

これは、ロード・バランサに返信されるヘッダーに、応答するサーバーのIPアドレス(またはその他のID情報)を挿入すると確認できます。

「図R-3」は、HTTPヘッダーの例を示しています。 これは、Mozilla FirefoxのLive HTTP headersプラグインのものであり、元のWebサーバーのID(www236)がHTTPヘッダーに移送された様子を示しています。

図R-3 HTTPヘッダーの例

「図R-3 HTTPヘッダーの例の説明」

この例におけるヘッダーの要素名はxserverです。 これはカスタム・ディメンションを使用して取得できます。 これについては、「カスタム・ディメンションの操作」で詳しく説明します。