Analisar o tráfego RPC do Exchange sobre TCP/IP

Traduções deste artigo Traduções deste artigo
ID do artigo: 159298 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Com o Exchange Server, às vezes, você precisa ler e analisar rastreamentos de sniffer quando Solucionando problemas de comunicação do servidor-para-servidor junto com comunicação cliente a servidor. Este artigo aborda o RPC detecta entre vários serviços do Exchange Server.

Mais Informações

Mapeador de ponto final

Para entender os vários estágios passa um cliente RPC para se conectar a um determinado serviço, podemos deve primeiro compreender como Remote Procedure Call (RPC) Service ', caso contrário, conhecido como o mapeador de ponto de extremidade, Ajuda Exchange na sua busca de números UUID do serviço. O mapeador de ponto de extremidade executa uma grande variedade de tarefas, mas que estamos interessados em é a capacidade de nos dizer o número de porta um serviço que estamos procurando está escutando. UUID geralmente pode ser categorizadas por seus caracteres primeiro 2, para Microsoft Exchange v4.0 e v5.0:
A4 - ARMAZENAMENTO
F5 - DIRETÓRIO
E1 - MAPEADOR DE PONTO DE EXTREMIDADE
Vamos tomar o exemplo a seguir onde ExchangeA Server deseja enviar uma mensagem ao servidor ExchangeB (ExchangeA e ExchangeB são no mesmo site, portanto, o mecanismo de comunicação é RPC e nesse caso é sobre TCP/IP).

A primeira coisa que ExchangeA deve fazer é mapeador de ponto final do consulta ExchangeB para localizar onde seu MTA está escutando. O motivo para isso é o número da porta que pode alterar cada Exchange serviço escuta em inicializações subseqüentes. O mapeador de ponto de extremidade é responsável por qual serviço está escutando no ponto de controle. Quando um serviço do Exchange é iniciado, ele se registra com o mapeador de ponto de extremidade e solicita o mapeador de ponto de extremidade para atribuí-lo um número de porta. O mapeador de ponto de extremidade sempre está escutando na porta 135 para TCP/IP e UUID do mapeador de ponto de extremidade é (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA).

Os 11 quadros seguintes mostram a conversação completa entre ExchangeA (na porta 3464) e mapeador de ponto de extremidade do ExchangeB (na porta 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
				

Quadro 1 - ExchangeA envia um pacote SYN para ExchangeB.

Quadro 2 - ExchangeB confirma o pacote com um pacote SynAck.

Quadro 3 - ExchangeA envia uma confirmação do SynAck. Agora temos uma conexão TCP entre ExchangeA e ExchangeB.

O quadro 4 - ExchangeA é vinculação ao mapeador de ponto de extremidade do ExchangeB. Sabemos isso pelo número UUID (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA) está enviando o BIND para e também pelo dst: número da porta.

Quadro 5 - ExchangeB confirma a ligação com um BindAck. Agora temos uma conexão RPC entre ExchangeA e mapeador de ponto de extremidade do ExchangeB.

Quadro 6 - ExchangeA envia uma solicitação de RPC de numopc 0 x 3 para ExchangeB juntamente com o UUID do serviço que está procurando (nesse caso, ele é do ExchangeB MTA). Isso é para solicitar o número de porta do serviço com o UUID correspondente.

Quadro 7 - ExchangeB retorna o número porta que o serviço que corresponde a este UUID está escutando. ExchangeA agora tem todas as informações necessárias para localizar o MTA no ExchangeB.

Quadros 8 a 11 - fechamento para a conexão TCP entre ExchangeA e ExchangeB baixo.

Agora que ExchangeA sabe o número da porta ele precisa se conectar a ExchangeB MTA. Uma observação importante aqui é que o MTA do Exchange faz uma ligação RPC ligeiramente diferentes da maioria das ligações RPC. Ele executa um handshake bidirecional, ou seja, não apenas ExchangeA tem que vincular a ExchangeB mas ExchangeB deve vincular a ExchangeA antes de quaisquer mensagens podem ser enviadas. Portanto, você deve ver uma ligação seguido por um BindAck e outra ligação do outro servidor seguido por outro BindAck conforme ilustrado abaixo.
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
				

Quadros 1 a 3 - uma vez novamente nosso handshake TCP três de forma.

O quadro 4 - ExchangeA MTA está ligado ExchangeB MTA.

Quadro 5 - ExchangeB confirma a ligação com um BindAck.

6 - Quadro

Quadro 7 - ExchangeA envia uma solicitação de RPC com numopc 0 x 0. Um numopc 0 x 0 é uma chamada MtaBind. Isso irá disparar ExchangeB MTA para emitir um vínculo para ExchangeA como o MTA precisa de uma conexão bidirecional.

8 - Quadro ExchangeB confirma recebeu quadro 7.

Framess 9 a 11 - handshake TCP nossa três de modo iniciada pelo ExchangeB neste momento.

12 - ExchangeB MTA quadro está ligado ExchangeA MTA.

Quadro 13 - ExchangeA confirma a ligação com um BindAck.

14 - Quadro

Quadro 15 - ExchangeB envia uma solicitação de RPC com numopc 0 x 1. Um numopc 0 x 1 é uma chamada MtaBindBack. Isso é configurar a conversação da dois forma necessário do MTA.

16 - Quadro ExchangeA confirma que ele recebeu 15 quadros.

Resposta de quadro do 17 - ExchangeB para o quadro 7.

Do 18 - ExchangeA quadro resposta ao quadro 15.

Isso ilustra o fluxo de uma conexão RPC. O exemplo acima ilustra especificamente uma conexão típica entre duas MTA. Esse mesmo tipo de conversação ocorrerá entre os outros vários serviços do Exchange também Embora o MTA seja a única pessoa que precisa de uma conversação bidirecional para trocar informações.

As informações contidas neste artigo usa o MTA para seus exemplos. Uma observação importante é que o mesmo tipo de conversação acontecerá com qualquer e toda a comunicação RPC do Exchange sobre TCP/IP.
  1. O handshake de três vias TCP será estabelecido.

    O mapeador de ponto de extremidade é consultado para determinar em qual porta o serviço queria está escutando.

    Um vínculo e BindAck entre os dois serviços acontecerá estabelecer RPC comunicação.

    Opcional - uma série de solicitações e respostas com opnums será emitida.

    Opcional - A comunicação de RPC é encerrada.

    A conexão TCP é dividida com Fin pacotes.
  2. O mapeador de ponto de extremidade é consultado para determinar em qual porta o serviço queria está escutando.

    Um vínculo e BindAck entre os dois serviços acontecerá estabelecer RPC comunicação.

    Opcional - uma série de solicitações e respostas com opnums será emitida.

    Opcional - A comunicação de RPC é encerrada.

    A conexão TCP é dividida com Fin pacotes.
  3. Um vínculo e BindAck entre os dois serviços acontecerá estabelecer RPC comunicação.

    Opcional - uma série de solicitações e respostas com opnums será emitida.

    Opcional - A comunicação de RPC é encerrada.

    A conexão TCP é dividida com Fin pacotes.
  4. Opcional - uma série de solicitações e respostas com opnums será emitida.

    Opcional - A comunicação de RPC é encerrada.

    A conexão TCP é dividida com Fin pacotes.
  5. Opcional - A comunicação de RPC é encerrada.

    A conexão TCP é dividida com Fin pacotes.
  6. A conexão TCP é dividida com Fin pacotes.
Ao examinar os rastreamentos de sniffer de comunicações RPC ou qualquer comunicação TCP, é importante que você está ciente de que várias conversas podem estar ocorrendo simultaneamente. Não assuma que simplesmente porque um pacote de solicitação segue um pacote de BindAck esta solicitação veio a conversa em particular está interessado. Uma verificação rápida das portas de origem e destino com o TCP informará que se o pacote que você está vendo fizer parte da conversa você estiver interessado ou não. Se o número de porta destino e/ou a fonte for não o mesmo que os números de porta usados no handshake TCP três de forma, o pacote que você está vendo é parte de uma conversação separada.

Um filtro de exibição bom no Monitor de rede, filtragem nos números de porta de origem e destino servirá como uma grande ajuda em assegurar os pacotes que você está vendo realmente fazem parte de conversação em questão.

Uma outra Observação importante este artigo aborda RPC sobre TCP só é. Não importa o protocolo subjacente, a parte RPC deste artigo permanecerá inalterado. Por exemplo RPC através de IPX funcionaria exatamente da mesma forma, exceto a comunicação de IPX teria que ser estabelecida antes para RPC muito da mesma maneira que TCP deve ser estabelecida antes de RPC.

Propriedades

ID do artigo: 159298 - Última revisão: sábado, 28 de outubro de 2006 - Revisão: 3.4
A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
Palavras-chave: 
kbmt kbnetwork kbusage KB159298 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 159298
Aviso de Isenção de Responsabilidade sobre Conteúdo do KB Aposentado
Este artigo trata de produtos para os quais a Microsoft não mais oferece suporte. Por esta razão, este artigo é oferecido "como está" e não será mais atualizado.

Submeter comentários

 

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