TCP/IP 上の Exchange RPC トラフィックを分析する方法

文書翻訳 文書翻訳
文書番号: 159298 - 対象製品
すべて展開する | すべて折りたたむ

目次

概要

Exchange Server では、サーバー間の通信やクライアントとサーバー間の通信のトラブルシューティングを行う際に、スニファのトレースを読み取って分析することが必要な場合があります。この資料では、さまざまな Exchange Server サービス間の RPC のスニファ トレースを分析する方法について説明します。

詳細

エンドポイント マッパー

特定のサービスに接続する際に RPC クライアントが実行するさまざまな段階的処理を理解するには、まず、リモート プロシージャ コール (RPC) サービス (エンドポイント マッパーとも呼ばれます) によって、Exchange がサービスの UUID 番号を検索する方法を理解する必要があります。エンドポイント マッパーではさまざまなタスクが実行されますが、ここで関係するのは、検索対象のサービスがリッスンしているポート番号を取得する機能です。Microsoft Exchange 4.0 および 5.0 では、通常、UUID 番号を先頭の 2 文字で分類できます。
A4 - ストア
F5 - ディレクトリ
E1 - エンドポイント マッパー
ExchangeA というサーバーから ExchangeB というサーバーにメッセージを送信する場合を例に挙げて説明します (ExchangeA および ExchangeB は同じサイト内にあるため、通信の機構は RPC です。この例では TCP/IP を使用して通信しています)。

ExchangeA で最初に実行する必要があるのは、ExchangeB のエンドポイント マッパーに問い合わせて、そのサーバーの MTA がリッスンしているポートを見つけることです。これが必要な理由は、各 Exchange サービスがリッスンするポート番号は、次にサービスが開始されるときには変更される可能性があるためです。エンドポイント マッパーでは、どのサービスがどのポートをリッスンしているかを追跡しています。Exchange サービスが開始されるとエンドポイント マッパーにそのサービスが登録され、エンドポイント マッパーにポート番号の割り当てが依頼されます。エンドポイント マッパーは、常に TCP/IP のポート 135 をリッスンしており、エンドポイント マッパーの UUID は (E1AF8308-5D1F-11C9-91A4-08002B14A0FA) です。

次の 11 個のフレームは、ExchangeA (ポート 3464) と ExchangeB のエンドポイント マッパー (ポート 135) の間の通信手順をすべて示しています。
1. TCP: ....S., len:    4, seq: 562005063-562005066, ack:         0, win:
   8192, src: 3464  dst:  135

2. TCP: .A..S., len:    4, seq: 875064831-875064834, ack: 562005064, win:
   8760, src:  135  dst: 3464

3. TCP: .A...., len:    0, seq: 562005064-562005064, ack: 875064832, win:
   8760, src: 3464  dst:  135

4. MSRPC: c/o RPC Bind:         UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA
   call 0x54004E  assoc grp 0x0  xmit 0x16D0  recv 0x16D0

5. MSRPC: c/o RPC Bind Ack:     call 0x54004E  assoc grp 0x33CFA  xmit
   0x16D0  recv 0x16D0

6. MSRPC: c/o RPC Request:      call 0x1  opnum 0x3  context 0x0  hint
   0x84

7. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x80  cancels
   0x0

8. TCP: .A...F, len:    0, seq: 562005292-562005292, ack: 875065044, win:
   8548, src: 3464  dst:  135

9. TCP: .A...., len:    0, seq: 875065044-875065044, ack: 562005293, win:
   8532, src:  135  dst: 3464

10. TCP: .A...F, len:    0, seq: 875065044-875065044, ack: 562005293, win:
   8532, src:  135  dst: 3464

11. TCP: .A...., len:    0, seq: 562005293-562005293, ack: 875065045, win:
   8548, src: 3464  dst:  135
				

フレーム 1 : ExchangeA から ExchangeB に Syn パケットが送信されます。

フレーム 2 : ExchangeB は、パケットの受信確認として SynAck パケットを送信します。

フレーム 3 : ExchangeA は、SynAck の受信確認を送信します。この時点で、ExchangeA と ExchangeB の間に TCP 接続が確立されます。

フレーム 4 : ExchangeA は、ExchangeB のエンドポイント マッパーにバインドを要求します。これは、Bind が送信されている対象の UUID 番号 (E1AF8308-5D1F-11C9-91A4-08002B14A0FA) によって、また dst: のポート番号によっても判断できます。

フレーム 5 : ExchangeB は、Bind の受信確認として BindAck を送信します。この時点で、ExchangeA と ExchangeB のエンドポイント マッパーの間に RPC 接続が確立されます。

フレーム 6 : ExchangeA は、RPC 要求の opnum 0x3 と共に検索対象のサービス (この例では ExchangeB の MTA) の UUID を ExchangeB に送信します。これは、該当する UUID を持ったサービスのポート番号を要求する動作です。

フレーム 7 : ExchangeB は、この UUID に対応するサービスがリッスンしているポート番号を返します。この時点で、ExchangeA は ExchangeB 上の MTA を見つけるために必要なすべての情報を取得しています。

フレーム 8 〜 11 : ExchangeA と ExchangeB の間の TCP 接続を閉じます。

これまでの動作で、ExchangeA は ExchangeB の MTA に接続するために必要なポート番号を取得しました。ここで重要なのは、Exchange の MTA では多くの RPC バインドとは少し異なる RPC バインドが行われることです。この場合に実行されるのは、双方向ハンドシェイクです。これは、メッセージを送信可能にするには、ExchangeA から ExchangeB へのバインドだけでなく、ExchangeB から ExchangeA へのバインドも行う必要があることを意味します。そのため、次の例で示されているように、Bind の後に BindAck が送信され、さらにもう一方のサーバーからもう 1 つ Bind が送信された後、BindAck が返されます。
1. TCP: ....S., len:    4, seq: 562005113-562005116, ack:         0, win:
   8192, src: 3470  dst: 4764

2. TCP: .A..S., len:    4, seq: 875064881-875064884, ack: 562005114, win:
   8760, src: 4764  dst: 3470

3. TCP: .A...., len:    0, seq: 562005114-562005114, ack: 875064882, win:
   8760, src: 3470  dst: 4764

4. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE
   call 0x1EBE80  assoc grp 0x0  xmit 0x16D0  recv 0x16D0

5. MSRPC: c/o RPC Bind Ack:     call 0x1EBE80  assoc grp 0x3150EAC1  xmit
   0x16D0  recv 0x16D0

6. TCP: .AP..., len:  206, seq: 562005250-562005455, ack: 875064990, win:
   8652, src: 3470  dst: 4764

7. MSRPC: c/o RPC Request:      call 0x1  opnum 0x0  context 0x0  hint
   0x11E

8. TCP: .A...., len:    0, seq: 875064990-875064990, ack: 562005792, win:
    8082, src: 4764  dst: 3470

9. TCP: ....S., len:    4, seq: 875064951-875064954, ack:         0, win:
    8192, src: 1969  dst: 1733

10. TCP: .A..S., len:    4, seq: 562005173-562005176, ack: 875064952, win:
   8760, src: 1733  dst: 1969

11. TCP: .A...., len:    0, seq: 875064952-875064952, ack: 562005174, win:
   8760, src: 1969  dst: 1733

12. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE
   call 0x6C645F65  assoc grp 0x0  xmit 0x16D0  recv 0x16D0

13. MSRPC: c/o RPC Bind Ack:     call 0x6C645F65  assoc grp 0x215D6F47
   xmit 0x16D0  recv 0x16D0

14. TCP: .AP..., len:  192, seq: 875065087-875065278, ack: 562005282, win:
   8652, src: 1969  dst: 1733

15. MSRPC: c/o RPC Request:      call 0x7DFE09C  opnum 0x1  context 0x0
   hint 0x2

16. TCP: .A...., len:    0, seq: 562005282-562005282, ack: 875065335, win:
   8377, src: 1733  dst: 1969

17. MSRPC: c/o RPC Response:     call 0x7DFE09C  context 0x0  hint 0x1C
   cancels 0x0

18. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x20  cancels
   0x0
				

フレーム 1 〜 3 : 前の例にも記載されている TCP の 3 方向ハンドシェイクが実行されます。

フレーム 4 : ExchangeA の MTA は、ExchangeB の MTA にバインドを要求します。

フレーム 5 : ExchangeB は、Bind の受信確認として BindAck を送信します。

フレーム 6 :

フレーム 7 : ExchangeA は、RPC 要求で opnum 0x0 を送信します。opnum 0x0 は MtaBind 呼び出しです。この動作により、MTA で必要な双方向接続として、ExchangeB の MTA から ExchangeA への Bind が発行されます。

フレーム 8 : ExchangeB は、フレーム 7 の受信確認を送信します。

フレーム 9 〜 11 : 今度は ExchangeB によって、前述の TCP 3 方向ハンドシェイクが開始されます。

フレーム 12 : ExchangeB の MTA は、ExchangeA の MTA にバインドを要求します。

フレーム 13 : ExchangeA は、Bind の受信確認として BindAck を送信します。

フレーム 14 :

フレーム 15 : ExchangeB は、RPC 要求で opnum 0x1 を送信します。opnum 0x1 は MtaBindBack 呼び出しです。この動作により、MTA で必要な双方向通信がセットアップされます。

フレーム 16 : ExchangeA は、フレーム 15 の受信確認を送信します。

フレーム 17 : フレーム 7 に対する ExchangeB からの応答です。

フレーム 18 : フレーム 15 に対する ExchangeA からの応答です。

以上は、RPC 接続の手順を示したものです。上記の例では、2 つの MTA 間の一般的な接続が具体的に説明されています。情報交換のために双方向通信が必要となるのは MTA だけですが、これと類似した種類の通信手順が、他の各種 Exchange サービス間でも同様に実行されます。

この資料に記載した情報では、例として MTA を使用しました。重要なことは、これと類似した種類の通信手順が、TCP/IP 上のすべての Exchange RPC 通信で実行されるということです。
  1. TCP 3 方向ハンドシェイクが確立されます。

    対象のサービスがどのポートをリッスンしているかを確認するため、エンドポイント マッパーへの問い合わせが実行されます。

    2 つのサービス間で Bind および BindAck が発行され、RPC 接続が確立されます。

    (必要に応じて) 一連の要求および応答で opnum が発行されます。

    (必要に応じて) RPC 通信を終了します。

    Fin パケットで、TCP 接続が切断されます。
  2. 対象のサービスがどのポートをリッスンしているかを確認するため、エンドポイント マッパーへの問い合わせが実行されます。

    2 つのサービス間で Bind および BindAck が発行され、RPC 接続が確立されます。

    (必要に応じて) 一連の要求および応答で opnum が発行されます。

    (必要に応じて) RPC 通信を終了します。

    Fin パケットで、TCP 接続が切断されます。
  3. 2 つのサービス間で Bind および BindAck が発行され、RPC 接続が確立されます。

    (必要に応じて) 一連の要求および応答で opnum が発行されます。

    (必要に応じて) RPC 通信を終了します。

    Fin パケットで、TCP 接続が切断されます。
  4. (必要に応じて) 一連の要求および応答で opnum が発行されます。

    (必要に応じて) RPC 通信を終了します。

    Fin パケットで、TCP 接続が切断されます。
  5. (必要に応じて) RPC 通信を終了します。

    Fin パケットで、TCP 接続が切断されます。
  6. Fin パケットで、TCP 接続が切断されます。
RPC 通信や TCP 通信のスニファ トレースを調査する際には、同時に複数の通信処理が発生している可能性があることを意識することが重要です。要求パケットの後に BindAck が続いているという単純な理由だけで、それが調査の対象となっている特定の通信で発生した要求であると見なすことはできません。TCP で使用されている送信先と送信元のポートを確認するだけで、参照しているパケットが調査対象の通信処理の一部かどうかがわかります。送信先または送信元のポート番号が TCP 3 方向ハンドシェイクで使用されているポート番号と同じでない場合、参照しているパケットは別の通信処理で使用されているパケットです。

ネットワーク モニタの表示には、送信先や送信元のポート番号に基づいてフィルタ処理する、便利なフィルタ機能があります。この機能を使用することにより、対象としている通信処理のパケットのみを確実に参照することができます。

もう 1 つ重要なことは、この資料で説明しているのは TCP 経由の RPC のみであることです。下位層のプロトコルに何が使用されていても、この資料に記載されている RPC のパケット部分は変わりません。たとえば、IPX 経由の RPC を使用する場合は、RPC よりも先に TCP の接続を確立する必要があったのと同じように、RPC よりも先に IPX の通信を確立する必要がある以外は、まったく同様の処理が実行されます。

プロパティ

文書番号: 159298 - 最終更新日: 2006年7月25日 - リビジョン: 3.3
この資料は以下の製品について記述したものです。
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
キーワード:?
kbnetwork kbusage KB159298
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"
サポート期間が終了した「サポート技術情報」資料に関する免責事項
この資料は、マイクロソフトでサポートされていない製品について記述したものです。そのため、この資料は現状ベースで提供されており、今後更新されることはありません。

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com