透過 TCP/IP 分析 Exchange RPC 流量

文章翻譯 文章翻譯
文章編號: 159298 - 檢視此文章適用的產品。
全部展開 | 全部摺疊

在此頁中

結論

與 Exchange Server 有時候需要讀取和分析通天鼻追蹤進行疑難排解以及與用戶端對伺服器的通訊的伺服器對伺服器通訊時。此篇文章位址 RPC 竊聽各種 Exchange Server 服務之間。

其他相關資訊

結束點對應程式

若要了解不同階段 RPC 用戶端經歷來連線到一個特定的服務,我們必須先瞭解遠端的程序的呼叫 (RPC) 服務 ',否則稱為 「 端點對應程式 」 會協助 Exchange 服務 UUID 數字其任務中。 端點對應程式 」 會執行各種工作,但我們感興趣的一個能夠告訴我們聆聽的服務,我們要找的連接埠號碼。 UUID 的可以通常分類由 Microsoft Exchange V4.0 和 v5.0 其前 2 個字元:
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 傳送的 RPC 要求 opnum 0x3 到 ExchangeB 連同它正在尋找的服務 UUID (在這種情況下是 ExchangeB 的 MTA)。 這是要求與對應的 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 然後從其他伺服器後面跟著另一個 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。

Framess 9 到 11-我們 TCP 三向信號交換啟始 ExchangeB 的這一次。

框架 12-ExchangeB MTA 繫結至 ExchangeA 的 MTA。

框架 13-ExchangeA 會確認與一個 BindAck 繫結。

框架 14-

框架 15-ExchangeB 傳送的 RPC 要求 opnum 0x1]。opnum 0x1 是 MtaBindBack 呼叫。這設定兩個方式交談 MTA 的需要。

框架 16-ExchangeA 會確認收到框架 15。

圖文框 7 框架 17-ExchangeB 的回應。

框架 18-ExchangeA 的回應框架 15。

這說明了 RPC 連線的流量。上述範例說明特別典型之間的連接兩個 MTA。這個相同的交談會發生之間 「 其他各種 Exchange 服務也雖然 MTA 是唯一需要兩個方式對話來交換資訊的一。

本文中所含的資訊會使用其範例 MTA。重要的注意,是交談的相同類型會與任何及所有 Exchange RPC 通訊發生透過 TCP/IP。
  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 三個方式握您查看封包中使用的連接埠號碼是個別的交談的一部份。

網路監視器的目的和來源連接埠編號篩選中的很好的顯示篩選器將當作絕佳 aide 在確保交談有問題嗎確實屬於您查看封包。

一個其他重要附註透過 TCP 只是這篇文章位址 RPC。不論基礎的通訊協定是什麼,本文 RPC 片段保持不變。例如透過 IPX 的 RPC 會一起相當同樣除了 IPX 通訊就必須要建立之前以 RPC 更 TCP 必須建立 RPC 之前的方式相同。

屬性

文章編號: 159298 - 上次校閱: 2006年10月28日 - 版次: 3.4
這篇文章中的資訊適用於:
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
關鍵字:?
kbmt kbnetwork kbusage KB159298 KbMtzh
機器翻譯
重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤,就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本:159298
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。
依現狀不再更新的知識庫內容免責聲明
本文旨在說明 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