Analysieren von Exchange RPC-Datenverkehr über TCP/IP

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 159298 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Mit Exchange Server müssen Sie manchmal lesen und Analysieren von Sniffer Ablaufverfolgungen, bei der Problembehandlung Server-zu-Server-Kommunikation zusammen mit Client-zu-Server-Kommunikation. Dieser Artikel Adressen überprüft RPC zwischen verschiedenen Exchange Server-Dienste.

Weitere Informationen

End Point Mapper

Um die verschiedenen Stufen zu verstehen, eine RPC-Client, durchläuft um zu einem bestimmten Dienst zu verbinden, wir müssen zunächst verstehen wie Remote Procedure Call (RPC)-Dienst ', andernfalls bekannt als die Endpunktzuordnung unterstützt Exchange seine Quest für Dienst UUID Zahlen. Die Endpunktzuordnung führt eine Reihe von Aufgaben, aber der wir interessiert sind ist die Fähigkeit, uns mitzuteilen, die Portnummer ein wir gesuchten Dienst abhört. UUID des können im Allgemeinen durch die ersten 2 Zeichen für Microsoft Exchange 4.0 und 5.0 kategorisiert werden:
A4 - SPEICHER
F5 - VERZEICHNIS
E1 - ENDPUNKT-MAPPER
Dauern uns das folgende Beispiel ExchangeA Server, möchte eine Nachricht an ExchangeB Server senden (ExchangeA und ExchangeB befinden sich in derselben Site daher die Kommunikationsmechanismus ist RPC und in diesem Fall über TCP/IP).

Der erste Schritt, die ExchangeA muss ist die Abfrage ExchangeB End Point Mapper suchen, in denen der MTA empfangsbereit ist. Der Grund dafür ist die Portnummer, die jeder Dienst überwacht Exchange bei zukünftigen Systemstarts ändern können. Die Endpunktzuordnung dient dem Nachverfolgen, welcher Dienst welchen Punkt abgehört wird. Wenn ein Exchange-Dienst gestartet wird, registriert sich selbst die Endpunktzuordnung und fordert die Endpunktzuordnung eine Anschlussnummer zugewiesen. Die Endpunktzuordnung hört immer auf Port 135 für TCP/IP und die Endpunktzuordnung UUID (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA) ist.

Die folgenden 11 Frames anzeigen die vollständige Kommunikation zwischen ExchangeA (auf Anschluss 3464) und des ExchangeB-Endpunktzuordnung (auf Port 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
				

Frame 1 - ExchangeA sendet ein SYN-Paket zu ExchangeB.

Frame 2 - ExchangeB bestätigt das Paket mit einem Paket SynAck.

Rahmen 3 - ExchangeA sendet ein Acknowledge der SynAck. Wir haben nun eine TCP-Verbindung zwischen ExchangeA und ExchangeB.

Frame 4 - ExchangeA wird an die Endpunktzuordnung des ExchangeB Binding. Wir wissen dies durch die er gebunden, sendet UUID-Anzahl (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA) als auch nach der dst: Anschlussnummer.

Frame 5 - ExchangeB bestätigt die Bindung mit einer BindAck. Wir haben nun eine RPC-Verbindung zwischen ExchangeA und ExchangeB der Endpunktzuordnung.

Rahmen 6 - ExchangeA, ExchangeB zusammen mit dem UUID des Dienstes gesucht wird sendet eine RPC-Anforderung der Nummer 0 x 3 (ist in diesem Fall ExchangeB des MTA). Dadurch wird die Anschlussnummer des der Dienst mit dem entsprechenden UUID anfordern.

Frame 7 - ExchangeB gibt die Portnummer, der der Dienst, der dieser UUID entspricht überwacht zurück. ExchangeA hat jetzt alle es den MTA auf ExchangeB gefunden benötigten Informationen.

Rahmen, 8 bis 11 - schließen Sie die TCP-Verbindung zwischen ExchangeA und ExchangeB.

Jetzt, dass ExchangeA die Anschlussnummer weiß Sie Verbindung mit der ExchangeB muss MTA. Ein wichtiger Hinweis Hier ist der Exchange-MTA eine RPC-Bindung etwas anders als die meisten RPC-Bindungen unterstützt. Er führt einen bidirektionalen Handshake, d. h., nicht nur hat ExchangeA ExchangeB gebunden, sondern ExchangeB muss an ExchangeA binden, bevor alle Nachrichten gesendet werden können. Daher sollte eine Bindung gefolgt von einem BindAck und einer anderen Bindung des anderen Servers gefolgt von einem anderen BindAck wie unten dargestellt angezeigt werden.
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
				

Frames 1 bis 3 - einmal erneut unsere drei TCP-Handshakes.

Frame 4 - ExchangeA-MTA ist zum ExchangeB MTA binden.

Frame 5 - ExchangeB bestätigt die Bindung mit einer BindAck.

6 - Frame

Frame 7 - ExchangeA sendet eine RPC-Anforderung mit der Nummer 0 x 0. Eine Nummer 0 x 0 ist ein MtaBind-Aufruf. Dadurch wird die ExchangeB des ausgelöst MTA, eine Bindung an ExchangeA ausstellen, wie der MTA eine zwei-Wege-Verbindung benötigen.

Frame 8 - ExchangeB bestätigt Empfang Frame 7.

Framess 9 bis 11 - unsere TCP drei Wege-Handshake durch ExchangeB dieses Mal initiiert.

Frame 12 - ExchangeB MTA wird Bindung an ExchangeA des MTA.

Frame 13 - ExchangeA bestätigt die Bindung mit einer BindAck.

14 - Frame

Frame 15 - ExchangeB sendet eine RPC-Anforderung mit der Nummer 0 x 1. Eine Nummer 0 x 1 ist ein MtaBindBack-Aufruf. Dies ist die zwei-Wege-Kommunikation der MTA muss einrichten.

Frame 16 - ExchangeA bestätigt er 15 Rahmen empfangen.

Frame 17 - ExchangeB der Antwort auf Frame 7.

18 - ExchangeA des Rückmeldungsrahmen Frame 15.

Dies ist der Datenfluss einer RPC-Verbindung. Im Beispiel oben wird insbesondere eine typische Verbindung zwischen zwei MTA veranschaulicht. Diese dieselbe Art der Unterhaltung zwischen der anderen verschiedene Exchange-Dienst sowie geschieht, obwohl der MTA nur eine zwei-Wege-Unterhaltung zum Austausch von Informationen benötigt.

In diesem Artikel enthaltene Informationen verwendet der MTA für seinen Beispielen. Ein wichtiger Hinweis ist diese dieselbe Art der Unterhaltung alle Exchange-RPC-Kommunikation über TCP/IP ausgeführt wird.
  1. TCP-Dreiwege-Handshake wird hergestellt werden.

    Die Endpunktzuordnung wird überprüft, um festzustellen, an welchem Anschluss der Dienst sollte abhört.

    Eine Bindung und BindAck zwischen zwei Diensten geschieht RPC herstellen Kommunikation.

    Optional ? eine Reihe von Anforderungen und Antworten mit Opnums ausgegeben wird.

    Optional ? die RPC-Kommunikation beendet wird.

    Die TCP-Verbindung wird mit End Pakete aufgeteilt.
  2. Die Endpunktzuordnung wird überprüft, um festzustellen, an welchem Anschluss der Dienst sollte abhört.

    Eine Bindung und BindAck zwischen zwei Diensten geschieht RPC herstellen Kommunikation.

    Optional ? eine Reihe von Anforderungen und Antworten mit Opnums ausgegeben wird.

    Optional ? die RPC-Kommunikation beendet wird.

    Die TCP-Verbindung wird mit End Pakete aufgeteilt.
  3. Eine Bindung und BindAck zwischen zwei Diensten geschieht RPC herstellen Kommunikation.

    Optional ? eine Reihe von Anforderungen und Antworten mit Opnums ausgegeben wird.

    Optional ? die RPC-Kommunikation beendet wird.

    Die TCP-Verbindung wird mit End Pakete aufgeteilt.
  4. Optional ? eine Reihe von Anforderungen und Antworten mit Opnums ausgegeben wird.

    Optional ? die RPC-Kommunikation beendet wird.

    Die TCP-Verbindung wird mit End Pakete aufgeteilt.
  5. Optional ? die RPC-Kommunikation beendet wird.

    Die TCP-Verbindung wird mit End Pakete aufgeteilt.
  6. Die TCP-Verbindung wird mit End Pakete aufgeteilt.
Bei der Suche über Sniffer Ablaufverfolgungen von RPC-Kommunikation oder alle TCP-Kommunikation ist es wichtig, dass Sie sich bewusst sind, dass mehrere Themen gleichzeitig auftreten können. Führen Sie nicht davon aus, die einfach weil ein Request-Paket ein Paket BindAck folgt, die diese Anforderung von bestimmte Unterhaltung stammen Sie interessiert sind. Eine schnelle Überprüfung mit TCP-Ports Ziel und Quelle erfahren Sie, wenn das Paket gerade an der Unterhaltung Teil ist Sie interessiert oder nicht sind. Wenn die Ziel und/oder Quelle Port Zahl ist keine die gleiche wie die Portnummern verwendet die drei TCP-Handshakes des Pakets angezeigt werden Teil einer separaten Unterhaltung ist.

Ein gute Anzeigefilter in Netzwerkmonitor, Filter auf das Ziel und Quelle Portnummern dient als eine große Hilfe beim Sicherstellen der Pakete, denen an, deren Eigenschaften Sie ansehen, tatsächlich die fragliche Unterhaltung angehören.

Ein wichtiger Hinweis ist nur in diesem Artikel Adressen RPC über TCP. Unabhängig das zugrunde liegende Protokoll bleibt der RPC-Teil dieses Artikels. Beispielsweise funktioniert RPC-über IPX sehr ähnlich, außer die IPX-Kommunikation müsste vor RPC viel in die gleiche Weise eingerichtet werden TCP vor RPC eingerichtet werden muss.

Eigenschaften

Artikel-ID: 159298 - Geändert am: Samstag, 28. Oktober 2006 - Version: 3.4
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
Keywords: 
kbmt kbnetwork kbusage KB159298 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 159298
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Disclaimer zu nicht mehr gepflegten KB-Inhalten
Dieser Artikel wurde für Produkte verfasst, für die Microsoft keinen Support mehr anbietet. Der Artikel wird deshalb in der vorliegenden Form bereitgestellt und nicht mehr weiter aktualisiert.

Ihr Feedback an uns

 

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