Analizar el tráfico RPC de Exchange a través de TCP/IP

Seleccione idioma Seleccione idioma
Id. de artículo: 159298 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

Con Exchange Server, a veces debe leer y analizar trazas husmeador cuando solucionar problemas de comunicación de servidor a servidor junto con la comunicación cliente a servidor. Las direcciones de este artículo examina RPC entre varios servicios de Exchange Server.

Más información

Asignador de puntos finales

Para comprender las distintas fases recorre un cliente RPC para conectarse a un determinado servicio, se debe saber cómo llamar procedimientos remotos (RPC) de servicio ', en caso contrario se conoce como el asignador de extremos, ayudas Exchange en su búsqueda de números UUID de servicio. El asignador de extremos realiza una serie de tareas pero que nos interesa es su capacidad para indicarnos un servicio que estamos buscando está escuchando en el número de puerto. Se puede clasificar generalmente del UUID por sus dos primeros caracteres, para v4.0 de Microsoft Exchange y v5.0:
A4 - ALMACÉN
F5 - DIRECTORIO
E1 - ASIGNADOR DE EXTREMOS
Permítanos tomar en el siguiente ejemplo que ExchangeA servidor desea enviar un mensaje al servidor ExchangeB (ExchangeA y ExchangeB están en el mismo sitio, por lo tanto, el mecanismo de comunicación es RPC y en este caso es a través de TCP/IP).

Lo primero que debe realizar ExchangeA es asignador de puntos End del consulta ExchangeB para buscar donde está escuchando su MTA. La razón para esto es el número de puerto que puede cambiar cada Exchange servicio escucha en posteriores inicios. El asignador de extremos es responsable de qué servicio está escuchando en qué punto de seguimiento. Cuando se inicia un servicio de Exchange, se registra con el asignador de extremos y le pide el asignador de extremos para asignarlo a un número de puerto. El asignador de puntos finales siempre escucha en puerto 135 de TCP/IP y UUID del asignador de puntos finales (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA).

Los marcos siguientes 11 mostrar la conversación completa entre ExchangeA (en el puerto 3464) y el asignador de puntos finales del ExchangeB (en el puerto 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
				

Marco 1 - ExchangeA envía un paquete SYN ExchangeB.

Marco 2 - ExchangeB confirmará el paquete con un paquete SynAck.

Marco 3 - ExchangeA envía una confirmación de la SynAck. Ahora tenemos una conexión TCP entre ExchangeA ExchangeB.

Marco 4 - ExchangeA se enlace al asignador de puntos finales del ExchangeB. Lo sabemos por el número UUID (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA) envía el enlace a y también por el dst: número de puerto.

Marco 5 - ExchangeB confirma el enlace con un BindAck. Ahora tenemos una conexión RPC entre ExchangeA asignador de extremos del ExchangeB.

Marco 6 - ExchangeA envía una solicitud de RPC de opnum 0 x 3 ExchangeB junto con el UUID del servicio está buscando (en este caso es ExchangeB MTA). Esto es para solicitar el número de puerto del servicio con el UUID correspondiente.

Marco 7 - ExchangeB devuelve el número de puerto que está escuchando el servicio que coincida con este UUID. ExchangeA tiene ahora toda la información que necesita para buscar el MTA en ExchangeB.

Marcos de 8 a 11 - cierre hacia abajo de la conexión TCP entre ExchangeA ExchangeB.

Ahora que ExchangeA conoce el número de puerto necesita conectarse a ExchangeB MTA. Una nota importante aquí es que el MTA de Exchange realiza un enlace RPC ligeramente diferente a la mayoría de los enlaces RPC. Realiza un enlace bidireccional, es decir, no sólo tiene ExchangeA enlazar a ExchangeB sino ExchangeB debe enlazar a ExchangeA antes de enviar los mensajes. Por lo tanto, debería ver un enlace seguido por un BindAck después otro enlace del servidor seguido por otro BindAck tal como se muestra a continuación.
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
				

Marcos 1 a 3 - una vez más nuestro TCP tres vías.

Marco 4 - ExchangeA MTA se está enlazando a MTA ExchangeB.

Marco 5 - ExchangeB confirma el enlace con un BindAck.

6 - Trama

Marco 7 - ExchangeA envía una solicitud de RPC con opnum 0 x 0. Un opnum 0 x 0 es una llamada MtaBind. Esto desencadenará ExchangeB MTA para emitir un enlace a ExchangeA el MTA necesite una conexión bidireccional.

Marco 8 - ExchangeB Confirma que recibió el 7 de marco.

Framess 9 a 11 - TCP de nuestro tres vías iniciadas por ExchangeB este momento.

Marco 12 - ExchangeB MTA está enlazando a ExchangeA MTA.

Marco 13 - ExchangeA confirma el enlace con un BindAck.

14 - Trama

Marco 15 - ExchangeB envía una solicitud de RPC con opnum 0 x 1. Un opnum 0 x 1 es una llamada MtaBindBack. Esto es configurar la conversación bidireccional necesidad del MTA.

16 - Marco ExchangeA Confirma que recibió el 15 de marco.

Respuesta del 17 - ExchangeB marco a marco 7.

Respuesta del 18 - ExchangeA marco a marco 15.

Esto ilustra el flujo de una conexión RPC. El ejemplo anterior ilustra específicamente una conexión normal entre dos MTA. Este mismo tipo de conversación ocurrirá entre los otros diversos servicios de Exchange así aunque el MTA es el único que necesita una conversación bidireccional para intercambiar información.

La información contenida en este artículo utiliza el MTA para sus ejemplos. Una nota importante es que este mismo tipo de conversación ocurrirá con cualquier y toda la comunicación RPC de Exchange a través de TCP/IP.
  1. Se establecerá el protocolo de enlace de tres vías TCP.

    El asignador de puntos finales se consulta para determinar en qué puerto está escuchando el servicio deseado.

    Ocurrirá un enlace y BindAck entre los dos servicios RPC de establecer comunicación.

    Opcional - se emitirá una serie de solicitudes y respuestas con opnums.

    Opcional - finaliza la comunicación RPC.

    La conexión TCP se divide con paquetes de fin.
  2. El asignador de puntos finales se consulta para determinar en qué puerto está escuchando el servicio deseado.

    Ocurrirá un enlace y BindAck entre los dos servicios RPC de establecer comunicación.

    Opcional - se emitirá una serie de solicitudes y respuestas con opnums.

    Opcional - finaliza la comunicación RPC.

    La conexión TCP se divide con paquetes de fin.
  3. Ocurrirá un enlace y BindAck entre los dos servicios RPC de establecer comunicación.

    Opcional - se emitirá una serie de solicitudes y respuestas con opnums.

    Opcional - finaliza la comunicación RPC.

    La conexión TCP se divide con paquetes de fin.
  4. Opcional - se emitirá una serie de solicitudes y respuestas con opnums.

    Opcional - finaliza la comunicación RPC.

    La conexión TCP se divide con paquetes de fin.
  5. Opcional - finaliza la comunicación RPC.

    La conexión TCP se divide con paquetes de fin.
  6. La conexión TCP se divide con paquetes de fin.
Cuando busca trazas de Rastreador de las comunicaciones RPC o cualquier comunicación de TCP, es importante que se tenga en cuenta que varias conversaciones pueden estar produciéndose simultáneamente. No suponga que simplemente porque un paquete de solicitud sigue un paquete de BindAck esta solicitud procede de la conversación concreta le interesa. Una comprobación rápida de los puertos de origen y de destino con TCP le indicará que si el paquete que está viendo es parte de la conversación está interesado o no. Si el número de puerto de destino y origen es no igual que los números de puerto utilizados en las vías TCP tres, el paquete que está viendo es parte de una conversación independiente.

Un filtro de presentación buena dentro de un monitor de red, filtrado en los números de puerto de origen y destino actuará como un excelente aide asegurar los paquetes que está viendo realmente pertenecen a la conversación en cuestión.

Otra una nota importante es este direcciones de artículo RPC a través de TCP sólo. Independientemente del protocolo subyacente, la parte RPC de este artículo permanece igual. Por ejemplo RPC a través de IPX funcionaría de forma bastante similar excepto la comunicación de IPX tendría que establecerse antes para RPC mucho de la misma manera que TCP debe establecerse antes de RPC.

Propiedades

Id. de artículo: 159298 - Última revisión: sábado, 28 de octubre de 2006 - Versión: 3.4
La información de este artículo se refiere a:
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
Palabras clave: 
kbmt kbnetwork kbusage KB159298 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 159298
Renuncia a responsabilidad de los contenidos de la KB sobre productos a los que ya no se ofrece asistencia alguna
El presente artículo se escribió para productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.

Enviar comentarios

 

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