Analyse le trafic Exchange RPC sur TCP/IP

Traductions disponibles Traductions disponibles
Numéro d'article: 159298 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Avec Exchange Server, vous devez parfois lire et analyser des traces de sniffer lors de la résolution des problèmes de communication serveur-serveur avec communication client-serveur. Cet article adresses RPC détecte entre différents services Exchange Server.

Plus d'informations

Mappeur de point de fin

Pour comprendre les différents stades traverse un client RPC pour vous connecter à un service de certain, nous must d'abord comprendre comment l'appel de procédure distant service (RPC)», sinon connu en tant que le mappeur de point final, facilite Exchange sa quête pour les nombres UUID de service. Le mappeur de point final effectue diverses tâches, mais celui qui que nous intéresse est sa capacité à nous dire un service que nous are recherchez écoute sur le numéro de port. UUID peut être classés généralement par leurs 2 premières caractères, pour Microsoft Exchange version 4.0 et 5.0 :
A4 - MAGASIN
F5 - RÉPERTOIRE
E1 - MAPPEUR DE POINT DE TERMINAISON
Nous prendre l'exemple suivant où ExchangeA Server souhaite envoyer un message au serveur ExchangeB (ExchangeA et ExchangeB se trouvent dans le même site, par conséquent, le mécanisme de communication est RPC et dans ce cas, il est sur TCP/IP).

La première chose que ExchangeA doit faire est de mappeur de point de fin de requête ExchangeB pour trouver où son MTA est à l'écoute. La raison en est le numéro de port que chaque Exchange service écoute peut changer lors des démarrages ultérieurs. Le mappeur de point final est responsable du suivi de quel service écoute sur le point. Lorsqu'un service Exchange démarre, il s'enregistre avec le mappeur de point final et vous demande le mappeur de point final à lui attribuer un numéro de port. Le mappeur de point final écoute toujours sur le port 135 pour TCP/IP et UUID du mappeur de point final est (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA).

Les 11 trames suivantes montrent la conversation terminée entre ExchangeA (sur le port 3464) et Mappeur de point final du ExchangeB (sur le 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
				

Cadre 1 - ExchangeA envoie un paquet SYN à ExchangeB.

Cadre 2 - ExchangeB reconnaît le paquet avec un paquet SynAck.

Cadre 3 - ExchangeA envoie un accusé de réception de la SynAck. Nous disposons désormais d'une connexion TCP entre ExchangeA et ExchangeB.

Liaison d'image 4: ExchangeA à mappeur de point final du ExchangeB. Nous savons que cela par le nombre d'UUID (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA) qu'il envoie la liaison à ainsi que par le dst: numéro de port.

Cadre 5 - ExchangeB reconnaît la liaison avec un BindAck. Nous disposons désormais d'une connexion RPC entre ExchangeA et Mappeur de point final du ExchangeB.

Cadre 6 - ExchangeA envoie une demande de RPC d'opnum 0 x 3 ExchangeB avec l'UUID du service qu'il recherche (dans ce cas, il est de ExchangeB MTA). Cela consiste à demander le numéro de port du service avec l'UUID correspondante.

Cadre 7 - ExchangeB renvoie le numéro de port que le service qui correspond à l'UUID écoute. ExchangeA dispose maintenant de toutes les informations dont il a besoin pour rechercher le MTA sur ExchangeB.

8 À 11 - clôture la connexion TCP entre ExchangeA et ExchangeB de cadres.

ExchangeA connaît le numéro de port il doit se connecter à ExchangeB MTA. Une note importante ici est que le MTA Exchange effectue une liaison RPC légèrement différente de celle de la plupart des liaisons RPC. Il effectue une négociation bidirectionnelle, ce qui signifie que non seulement ExchangeA dispose-t-il sur Lier à ExchangeB mais ExchangeB doivent être liés aux ExchangeA avant de peuvent envoyer des messages. Par conséquent, vous devez voir une liaison suivie d'un BindAck puis une autre liaison à partir de l'autre serveur de suivi d'un autre BindAck comme illustré ci-dessous.
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
				

Cadres 1 à 3 - Once à nouveau notre connexion TCP trois temps.

Cadre 4 - MTA ExchangeA effectue la liaison ExchangeB MTA.

Cadre 5 - ExchangeB reconnaît la liaison avec un BindAck.

6 - Image

Cadre 7 - ExchangeA envoie une demande de RPC avec opnum 0 x 0. Un opnum 0 x 0 est un appel MtaBind. Cela déclenche ExchangeB MTA pour émettre une liaison à ExchangeA que le MTA ont besoin d'une connexion bidirectionnelle.

Cadre 8 - ExchangeB confirme qu'il reçu image 7.

Framess 9 à 11 - temps TCP nos trois initiée par ExchangeB ce moment.

Cadre 12 - ExchangeB MTA effectue la liaison ExchangeA MTA.

Cadre 13 - ExchangeA reconnaît la liaison avec un BindAck.

Cadre 14-

Cadre 15 - ExchangeB envoie une demande de RPC avec opnum 0 x 1. Un opnum 0 x 1 est un appel d'opération MtaBindBack. Cela consiste à configurer la conversation de deux façon besoin du MTA.

Trame 16 - ExchangeA confirme qu'il reçu image 15.

Cadre de 17 - ExchangeB réponse à image 7.

Cadre de 18 - ExchangeA réponse à image 15.

Cela illustre le flux d'une connexion RPC. L'exemple ci-dessus illustre spécifiquement une connexion classique entre deux MTA. Ce même type de conversation se produit entre les autres différents Services Exchange, ainsi bien que le MTA est le seul dont a besoin d'une conversation bidirectionnelle pour échanger des informations.

Les informations contenues dans cet article utilisent le service MTA pour ses exemples. Une note importante est que ce même type de conversation va se produire avec toutes les communications Exchange RPC sur TCP/IP.
  1. La négociation à trois voies TCP est établie.

    Le mappeur de point final est consulté à déterminer sur quel port le service voulu est à l'écoute.

    Une liaison et BindAck entre les deux services arrivera à établir RPC communication.

    Facultatif - série de demandes et réponses avec opnums sera émis.

    Facultatif - la communication RPC est terminée.

    La connexion TCP est rompue avec des paquets de fin.
  2. Le mappeur de point final est consulté à déterminer sur quel port le service voulu est à l'écoute.

    Une liaison et BindAck entre les deux services arrivera à établir RPC communication.

    Facultatif - série de demandes et réponses avec opnums sera émis.

    Facultatif - la communication RPC est terminée.

    La connexion TCP est rompue avec des paquets de fin.
  3. Une liaison et BindAck entre les deux services arrivera à établir RPC communication.

    Facultatif - série de demandes et réponses avec opnums sera émis.

    Facultatif - la communication RPC est terminée.

    La connexion TCP est rompue avec des paquets de fin.
  4. Facultatif - série de demandes et réponses avec opnums sera émis.

    Facultatif - la communication RPC est terminée.

    La connexion TCP est rompue avec des paquets de fin.
  5. Facultatif - la communication RPC est terminée.

    La connexion TCP est rompue avec des paquets de fin.
  6. La connexion TCP est rompue avec des paquets de fin.
Lors de la recherche par le biais de traces de sniffer de communications RPC ou toute communication TCP, il est important que vous êtes conscient que plusieurs conversations peuvent se produire simultanément. Ne supposez pas que simplement car un paquet de demande respecte un paquet BindAck cette demande provenant de la conversation particulière vous intéressent. Une vérification rapide des ports source et destination avec TCP vous indiquera que si le paquet que vous examinez fait partie de la conversation vous intéresse ou non. Si le numéro de port de destination et/ou de la source est pas la même façon que les numéros de port utilisés dans la connexion TCP trois temps, le paquet que vous examinez fait partie d'une conversation distincte.

Un filtre d'affichage correcte dans le Moniteur réseau, filtrage sur la destination et les numéros de port source servira d'une grande aide en vue d'assurer les paquets que vous examinez en effet appartiennent à la conversation en question.

Une autre Remarque importante ce adresses article RPC sur TCP n'est. Quel protocole sous-jacent, que la partie RPC de cet article reste identique. Par exemple RPC sur IPX fonctionnerait tout à fait de même, sauf la communication IPX serait doivent être établies avant pour RPC beaucoup de la même façon que TCP doit être établie avant RPC.

Propriétés

Numéro d'article: 159298 - Dernière mise à jour: samedi 28 octobre 2006 - Version: 3.4
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
Mots-clés : 
kbmt kbnetwork kbusage KB159298 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 159298
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Exclusion de responsabilité concernant les contenus obsolètes dans la Base de connaissances
Cet article concerne des produits pour lesquels Microsoft n'offre plus de support. Il est par conséquent fourni « en l'état » et ne sera plus mis à jour.

Envoyer des commentaires

 

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