Phân tích lưu lượng truy cập Exchange RPC trên TCP/IP

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này:159298
Bài viết này đã được lưu trữ. Bài viết được cung cấp "nguyên trạng" và sẽ không còn được cập nhật nữa.
TÓM TẮT
Với Exchange Server, bạn đôi khi cần để đọc và phân tích các dấu vết Licensekhi xử lý sự cố máy chủ đến máy chủ giao tiếp cùng với khách hàng-để-máy chủ giao tiếp. Bài viết này địa chỉ RPC sniffs giữa khác nhauDịch vụ Exchange Server.
THÔNG TIN THÊM

Kết thúc điểm Mapper

Để hiểu các giai đoạn ứng dụng khách RPC đi qua đểkết nối với một dịch vụ nhất định, trước hết phải hiểu làm thế nào từ xaDịch vụ thủ tục gọi (RPC)', nếu không được biết đến như Mapper điểm kết thúc,hỗ trợ Exchange trong quest của mình cho các con số UUID dịch vụ. Kết thúc điểm Mapperthực hiện một loạt các nhiệm vụ, nhưng là một trong những chúng tôi quan tâm đến khả năng của nócho chúng tôi biết số hiệu cổng một dịch vụ mà chúng tôi đang tìm kiếm lắng nghe trên.UUID của có thể được phân loại nói chung của các ký tự đầu tiên 2,Đối với Microsoft Exchange v4.0 và v5.0:
A4 - CỬA HÀNG
F5 - THƯ MỤC
E1 - ĐIỂM CUỐI MAPPER
Chúng ta hãy lấy ví dụ sau nơi máy chủ ExchangeA muốn gửi mộttin nhắn đến máy chủ ExchangeB (ExchangeA và ExchangeB nằm trong cùng một trang webdo đó cơ chế giao tiếp là RPC và trong trường hợp này nó quaTCP/IP).

Việc đầu tiên mà ExchangeA phải làm là truy vấn ExchangeB điểm kết thúcCông cụ bản đồ để tìm nơi nó MTA lắng nghe. Lý do của việc này là cảngsố lượng mỗi dịch vụ trao đổi lắng nghe trên có thể thay đổi ngày tiếp theokhởi. Điểm kết thúc Mapper có trách nhiệm theo dõi dịch vụ mànghe vào thời điểm đó. Khi một dịch vụ trao đổi bắt đầu, nó đăng kýchính nó với các công cụ bản đồ điểm kết thúc và yêu cầu các công cụ bản đồ điểm kết thúc để gán cho nósố hiệu cổng. Mapper điểm kết thúc luôn luôn lắng nghe trên cổng 135 choTCP/IP và công cụ bản đồ điểm kết thúc UUID là (E1AF8308-5D1F-11C9-91A4-08002B14A0FA).

11 Khung sau hiển thị hoàn toàn cuộc đàm thoại giữa ExchangeA(trên cổng 3464) và ExchangeB của điểm kết thúc Mapper (trên cổng 135):
1. TCP: ....S., len:    4, seq: 562005063-562005066, ack:         0, win:   8192, src: 3464  dst:  1352. TCP: .A..S., len:    4, seq: 875064831-875064834, ack: 562005064, win:   8760, src:  135  dst: 34643. TCP: .A...., len:    0, seq: 562005064-562005064, ack: 875064832, win:   8760, src: 3464  dst:  1354. MSRPC: c/o RPC Bind:         UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA   call 0x54004E  assoc grp 0x0  xmit 0x16D0  recv 0x16D05. MSRPC: c/o RPC Bind Ack:     call 0x54004E  assoc grp 0x33CFA  xmit   0x16D0  recv 0x16D06. MSRPC: c/o RPC Request:      call 0x1  opnum 0x3  context 0x0  hint   0x847. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x80  cancels   0x08. TCP: .A...F, len:    0, seq: 562005292-562005292, ack: 875065044, win:   8548, src: 3464  dst:  1359. TCP: .A...., len:    0, seq: 875065044-875065044, ack: 562005293, win:   8532, src:  135  dst: 346410. TCP: .A...F, len:    0, seq: 875065044-875065044, ack: 562005293, win:   8532, src:  135  dst: 346411. TCP: .A...., len:    0, seq: 562005293-562005293, ack: 875065045, win:   8548, src: 3464  dst:  135				

Khung 1 - ExchangeA sẽ gửi một gói Syn để ExchangeB.

Khung 2 - ExchangeB thừa nhận gói với một gói SynAck.

Khung 3 - ExchangeA sẽ gửi một acknowledge SynAck.Chúng tôi bây giờ có một kết nối TCP giữa ExchangeA và ExchangeB.

Khung 4 - ExchangeA là bắt buộc để ExchangeB của điểm kết thúc Mapper. Chúng tôi biếtĐiều này bởi UUID soá (E1AF8308-5D1F-11C9-91A4-08002B14A0FA) nó làGửi ràng buộc và cũng bởi dst: cảng số.

Khung 5 - ExchangeB thừa nhận ràng buộc với một BindAck.Chúng tôi bây giờ có một kết nối RPC giữa ExchangeA và ExchangeB của điểm kết thúcCông cụ bản đồ.

Khung 6 - ExchangeA sẽ gửi một yêu cầu RPC opnum 0x3 để ExchangeB cùngvới UUID của dịch vụ đó tìm kiếm (trong trường hợp này nó làExchangeB của MTA). Điều này là để yêu cầu số hiệu cổng dịch vụ vớiUUID tương ứng.

Khung 7 - trả về ExchangeB cổng số mà các dịch vụ phù hợp vớiUUID này nghe trên. ExchangeA bây giờ có tất cả thông tin cần thiếtđể tìm MTA ngày ExchangeB.

Khung 8 thông qua 11 - đóng cửa kết nối TCP giữa ExchangeA vàExchangeB.

Bây giờ mà ExchangeA biết số hiệu cổng nó cần để kết nối với ExchangeB củaMTA. Một lưu ý quan trọng ở đây là Exchange MTA nào thì một ràng buộc RPC hơigắn bó với RPC khác với hầu hết. Nó thực hiện một bắt tay hai chiều, có nghĩa là,không chỉ nào ExchangeA có liên kết với ExchangeB nhưng ExchangeB phải ràng buộcExchangeA trước khi bất kỳ tin nhắn có thể được gửi. Vì vậy, bạn sẽ thấy mộtRàng buộc theo sau là một BindAck sau đó ràng buộc khác từ các máy chủ khác theo saubởi một BindAck như minh họa dưới đây.
1. TCP: ....S., len:    4, seq: 562005113-562005116, ack:         0, win:   8192, src: 3470  dst: 47642. TCP: .A..S., len:    4, seq: 875064881-875064884, ack: 562005114, win:   8760, src: 4764  dst: 34703. TCP: .A...., len:    0, seq: 562005114-562005114, ack: 875064882, win:   8760, src: 3470  dst: 47644. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE   call 0x1EBE80  assoc grp 0x0  xmit 0x16D0  recv 0x16D05. MSRPC: c/o RPC Bind Ack:     call 0x1EBE80  assoc grp 0x3150EAC1  xmit   0x16D0  recv 0x16D06. TCP: .AP..., len:  206, seq: 562005250-562005455, ack: 875064990, win:   8652, src: 3470  dst: 47647. MSRPC: c/o RPC Request:      call 0x1  opnum 0x0  context 0x0  hint   0x11E8. TCP: .A...., len:    0, seq: 875064990-875064990, ack: 562005792, win:    8082, src: 4764  dst: 34709. TCP: ....S., len:    4, seq: 875064951-875064954, ack:         0, win:    8192, src: 1969  dst: 173310. TCP: .A..S., len:    4, seq: 562005173-562005176, ack: 875064952, win:   8760, src: 1733  dst: 196911. TCP: .A...., len:    0, seq: 875064952-875064952, ack: 562005174, win:   8760, src: 1969  dst: 173312. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE   call 0x6C645F65  assoc grp 0x0  xmit 0x16D0  recv 0x16D013. MSRPC: c/o RPC Bind Ack:     call 0x6C645F65  assoc grp 0x215D6F47   xmit 0x16D0  recv 0x16D014. TCP: .AP..., len:  192, seq: 875065087-875065278, ack: 562005282, win:   8652, src: 1969  dst: 173315. MSRPC: c/o RPC Request:      call 0x7DFE09C  opnum 0x1  context 0x0   hint 0x216. TCP: .A...., len:    0, seq: 562005282-562005282, ack: 875065335, win:   8377, src: 1733  dst: 196917. MSRPC: c/o RPC Response:     call 0x7DFE09C  context 0x0  hint 0x1C   cancels 0x018. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x20  cancels   0x0				

Khung 1 đến 3 - một lần nữa bắt tay cách TCP ba của chúng tôi.

Khung 4 - ExchangeA MTA là bắt buộc để ExchangeB MTA.

Khung 5 - ExchangeB thừa nhận ràng buộc với một BindAck.

Khung 6-

Khung 7 - ExchangeA sẽ gửi một RPC yêu cầu với opnum 0x0. Một opnum 0x0 là mộtMtaBind cuộc gọi. Điều này sẽ kích hoạt các ExchangeB của MTA để phát hành một ràng buộc đểExchangeA như là MTA của cần một kết nối hai chiều.

Khung 8 - ExchangeB thừa nhận nó đã nhận được khung 7.

Framess 9 thông qua 11 - Our TCP ba cách bắt tay khởi xướng bởi ExchangeBThời gian này.

Khung 12 - ExchangeB MTA là bắt buộc để ExchangeA của MTA.

Khung 13 - ExchangeA thừa nhận ràng buộc với một BindAck.

Khung 14-

Khung 15 - ExchangeB sẽ gửi một RPC yêu cầu với opnum 0x1. Một opnum 0x1 là mộtMtaBindBack cuộc gọi. Đây thiết lập cuộc trò chuyện hai cách của MTA cần.

Khung 16 - ExchangeA thừa nhận nó đã nhận được 15 khung.

Khung - ExchangeB của 17 phản ứng để khung 7.

Khung 18 - ExchangeA đáp ứng cho khung 15.

Điều này minh họa dòng chảy của một kết nối RPC. Ví dụ trênminh họa đặc biệt là một điển hình kết nối giữa hai MTA. Này như nhauloại hội thoại sẽ xảy ra giữa khác nhau trao đổiCác dịch vụ là tốt mặc dù MTA là chỉ có một mà cần một hai chiềuhội thoại để trao đổi thông tin.

Thông tin trong bài viết này sử dụng MTA cho các ví dụ của nó. Mộtquan trọng lưu ý này là cùng loại của các cuộc trò chuyện sẽ xảy ra với bất kỳ vàtất cả các trao đổi RPC giao tiếp trên TCP/IP.
  1. Bắt tay ba chiều TCP sẽ được thành lập.

    Điểm kết thúc Mapper tư vấn để xác định trên cổng các dịch vụ mà muốn lắng nghe.

    Một ràng buộc và BindAck giữa hai dịch vụ sẽ xảy ra với thiết lập RPC thông tin liên lạc.

    Tùy chọn - một loạt các yêu cầu và phản ứng với opnums sẽ Ban hành.

    Tùy chọn - giao tiếp RPC kết thúc.

    Kết nối TCP phá vỡ với các gói vây.
  2. Điểm kết thúc Mapper tư vấn để xác định trên cổng các dịch vụ mà muốn lắng nghe.

    Một ràng buộc và BindAck giữa hai dịch vụ sẽ xảy ra với thiết lập RPC thông tin liên lạc.

    Tùy chọn - một loạt các yêu cầu và phản ứng với opnums sẽ Ban hành.

    Tùy chọn - giao tiếp RPC kết thúc.

    Kết nối TCP phá vỡ với các gói vây.
  3. Một ràng buộc và BindAck giữa hai dịch vụ sẽ xảy ra với thiết lập RPC thông tin liên lạc.

    Tùy chọn - một loạt các yêu cầu và phản ứng với opnums sẽ Ban hành.

    Tùy chọn - giao tiếp RPC kết thúc.

    Kết nối TCP phá vỡ với các gói vây.
  4. Tùy chọn - một loạt các yêu cầu và phản ứng với opnums sẽ Ban hành.

    Tùy chọn - giao tiếp RPC kết thúc.

    Kết nối TCP phá vỡ với các gói vây.
  5. Tùy chọn - giao tiếp RPC kết thúc.

    Kết nối TCP phá vỡ với các gói vây.
  6. Kết nối TCP phá vỡ với các gói vây.
Khi tìm kiếm thông qua sniffer dấu vết của thông tin RPC, hoặc bất kỳ TCPgiao tiếp, điều quan trọng là bạn phải biết rõ rằng nhiềucuộc hội thoại có thể xảy ra cùng một lúc. Đừng cho rằng đó chỉ đơn giảnbởi vì một gói dữ liệu yêu cầu sau một gói BindAck yêu cầu này đếntừ cuộc trò chuyện cụ thể bạn quan tâm đến. Một kiểm tra nhanh chóng củacác cảng đích và nguồn với TCP sẽ cho bạn biết nếu gói bạnđang tìm kiếm tại là một phần của cuộc đàm thoại mà bạn quan tâm hay không. Nếusố hiệu cổng đích và/hoặc nguồn là không giống như cổngcác con số được sử dụng trong ba cách TCP bắt tay, gói bạn đang tìm kiếmlà một phần của một cuộc trò chuyện riêng biệt.

Một bộ lọc tốt hiển thị trong màn hình mạng, lọc vào các điểm đếnvà các con số cổng nguồn sẽ phục vụ như là một phụ tá tuyệt vời trong việc bảo đảm các góibạn đang tìm lúc làm thực sự thuộc về cuộc đàm thoại trong câu hỏi.

Một lưu ý quan trọng khác là sửa địa chỉ bài RPC qua TCP chỉ. Khôngvấn đề gì giao thức nằm bên dưới là, mảnh RPC bài viết nàyvẫn giữ nguyên. Ví dụ RPC qua IPX sẽ làm việc khá tương tựngoại trừ IPX giao tiếp có thể là thành lập trước khi RPC nhiềutrong cùng một cách TCP phải được thành lập trước RPC.
Netmon Network Monitor

Cảnh báo: Bài viết này được dịch tự động

Thuộc tính

ID Bài viết: 159298 - Xem lại Lần cuối: 12/04/2015 15:46:27 - Bản sửa đổi: 2.0

Microsoft Exchange Server 5.5 Standard Edition, Microsoft Exchange Server 4.0 Standard Edition, Microsoft Exchange Server 5.0 Standard Edition

  • kbnosurvey kbarchive kbnetwork kbusage kbmt KB159298 KbMtvi
Phản hồi