通过 TCP/IP 分析 Exchange RPC 通信

文章翻译 文章翻译
文章编号: 159298 - 查看本文应用于的产品
展开全部 | 关闭全部

本文内容

概要

与 Exchange Server 有时需要读取并分析嗅探器跟踪,在故障排除以及与客户端-服务器通信的服务器到服务器通信。此文章解决 RPC 探测之间不同的 Exchange 服务器服务。

更多信息

结束点映射程序

要了解了 RPC 客户端以连接到特定服务所经历的各个阶段,我们必须首先了解如何远程过程调用 (RPC) 服务,否则称为该终结点映射器服务 UUID 数字为其请求帮助 Exchange。 终结点映射程序执行各种任务,但我们感兴趣是它能够告诉我们,我们正在寻找一个服务正在侦听的端口号。 可以通过其第一次 2 个字符的 Microsoft Exchange v4.0 和 5.0 版通常分类 UUID 的:
a4 的存储区
f5 的目录
e1-终结点映射程序
让我们采取下面的示例 ExchangeA 服务器要将消息发送到 ExchangeB 服务器 (ExchangeA 和 ExchangeB 是在同一站点内因此通信机制是 RPC 和在这种情况下它是通过 TCP/IP)。

ExchangeA 必须执行在第一件事就是查询 ExchangeB 的结束点映射器以查找其 MTA 正在侦听的位置。其原因是服务侦听每个 Exchange 可以更改在随后的启动上的端口号。 终结点映射程序负责跟踪哪些服务正在侦听的点。 将启动 Exchange 服务时它本身注册终结点映射程序,并询问对终结点映射程序为其指定一个端口号。终结点映射器始终侦听端口 135,TCP/IP 和终结点映射程序的 UUID (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA)。

下面的 11 帧显示 ExchangeA (在端口 3464) 和 $ 在端口 135) 上的 ExchangeB 的终结点映射程序之间完成的对话:
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 的终结点映射程序。我们知道这 UUID 数 (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA) 它正在发送绑定到和在 dst: 端口号。

帧 5-ExchangeB 确认与一个 BindAck 绑定。 现在,我们有 ExchangeA 和 ExchangeB 的终结点映射器之间的 RPC 连接。

框架 6-ExchangeA opnum 0x3 的 RPC 请求向发送与正在寻找服务的 UUID 一起 ExchangeB (在这种情况下它是 ExchangeB 的 MTA)。 这是请求具有相应的 UUID 服务的端口号。

框架 7-ExchangeB 返回匹配此 UUID 的服务正在侦听的端口号。ExchangeA 有 ExchangeB 上查找该 MTA 所需的所有信息。

帧 8 到 11-关闭 TCP 连接 ExchangeA 和 ExchangeB 之间下。

现在,ExchangeA 知道端口号它需要连接到 ExchangeB 的 MTA。一个重要的注意事项是 Exchange MTA 会略有不同于大多数的 RPC 绑定的 RPC 绑定。它将执行这意味着,ExchangeA 必须绑定到 ExchangeB 不仅才能发送任何消息 ExchangeB 必须将绑定到 ExchangeA 一个双向握手。因此,您应看到一个 BindAck 后跟一个绑定,然后从另一服务器跟另一个 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 三次握手。

帧 4-ExchangeA MTA 绑定到 ExchangeB MTA。

帧 5-ExchangeB 确认与一个 BindAck 绑定。

框架 6-

框架 7-ExchangeA 发送与 opnum 0x0 RPC 请求。一个 opnum 0x0 是一种 MtaBind 调用。该操作将触发 ExchangeB 的 MTA ExchangeA 为颁发一个绑定,因为 MTA 的需要两个方法的连接。

框架 8-ExchangeB 承认它接收到框架 7。

通过这一次由 ExchangeB 11-我们 TCP 三握手 Framess 9。

框架 12-ExchangeB MTA 绑定到 ExchangeA 的 MTA。

框架 13-ExchangeA 确认与一个 BindAck 绑定。

框架 14-

框架 15-ExchangeB 发送与 opnum 0x1 RPC 请求。一个 opnum 0x1 是一种 MtaBindBack 调用。这建立双向对话 MTA 的需要。

框架 16-ExchangeA 承认它接收到第 15 帧。

框架 7 框架 17-ExchangeB 的响应。

第 15 帧框架 18-ExchangeA 的响应。

这阐释了流的 RPC 连接。上面的示例说明了两个 MTA 之间专门典型的连接。这种情况下此同一种对话会有其他各种 Exchange 服务也之间虽然 MTA 是仅有的一个需要两个方法对话交换信息的。

在这篇文章中所含信息使用 MTA 有关其示例。这种相同类型的对话将通过 TCP/IP 与任何及所有 Exchange RPC 通信会发生重要注释。
  1. 将建立 TCP 三向握手。

    终结点映射器被咨询以确定需要该服务正在侦听的端口上。

    绑定和 BindAck 两种服务之间将建立 RPC 发生通信。

    可选-将发出的请求和响应 opnums 与一系列。

    可选-结束的 RPC 通信。

    TCP 连接是断开与 Fin 数据包。
  2. 终结点映射器被咨询以确定需要该服务正在侦听的端口上。

    绑定和 BindAck 两种服务之间将建立 RPC 发生通信。

    可选-将发出的请求和响应 opnums 与一系列。

    可选-结束的 RPC 通信。

    TCP 连接是断开与 Fin 数据包。
  3. 绑定和 BindAck 两种服务之间将建立 RPC 发生通信。

    可选-将发出的请求和响应 opnums 与一系列。

    可选-结束的 RPC 通信。

    TCP 连接是断开与 Fin 数据包。
  4. 可选-将发出的请求和响应 opnums 与一系列。

    可选-结束的 RPC 通信。

    TCP 连接是断开与 Fin 数据包。
  5. 可选-结束的 RPC 通信。

    TCP 连接是断开与 Fin 数据包。
  6. TCP 连接是断开与 Fin 数据包。
查找通过 RPC 通信或任何 TCP 通信的嗅探器跟踪时, 非常重要您所知道的多个会话可以同时进行。不要假设的只是因为请求数据包遵循 BindAck 的数据包,此请求来自特定的对话,您所感兴趣。与 TCP 目标和源端口的快速检查将告诉您是否您正在查看该数据包是会话的一部分感或不。如果目标和/或源端口号是不相同三个 TCP 握手的您正在查看的包中使用的端口号是单独会话的一部分。

良好的显示筛选器筛选目标和源端口号上的网络监视程序中将作为一个很好有助于确保您正在查看的数据包执行确实属于对话中有问题。

其他重要的一个提示才此文章解决 RPC 通过 TCP。无论基础协议何谓本文的 RPC 介质保持不变。例如 IPX 上的 RPC 将起作用非常类似但 IPX 通信将不得不建立之前 RPC 得 RPC 之前,必须建立 TCP 相同的方式。

属性

文章编号: 159298 - 最后修改: 2006年10月28日 - 修订: 3.4
这篇文章中的信息适用于:
  • Microsoft Exchange Server 5.5 标准版
  • Microsoft Exchange Server 4.0 标准版
  • Microsoft Exchange Server 5.0 标准版
关键字:?
kbmt kbnetwork kbusage KB159298 KbMtzh
机器翻译
注意:这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇,语法或文法的问题,就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量,但是我们不保证机器翻译的正确度,也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。
点击这里察看该文章的英文版: 159298
Microsoft和/或其各供应商对于为任何目的而在本服务器上发布的文件及有关图形所含信息的适用性,不作任何声明。 所有该等文件及有关图形均"依样"提供,而不带任何性质的保证。Microsoft和/或其各供应商特此声明,对所有与该等信息有关的保证和条件不负任何责任,该等保证和条件包括关于适销性、符合特定用途、所有权和非侵权的所有默示保证和条件。在任何情况下,在由于使用或运行本服务器上的信息所引起的或与该等使用或运行有关的诉讼中,Microsoft和/或其各供应商就因丧失使用、数据或利润所导致的任何特别的、间接的、衍生性的损害或任何因使用而丧失所导致的之损害、数据或利润不负任何责任。
不再更新的 KB 内容免责声明
本文介绍那些 Microsoft 不再提供支持的产品。因此本文按“原样”提供,并且不再更新。

提供反馈

 

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