L'analisi del traffico RPC di Exchange su TCP/IP

Traduzione articoli Traduzione articoli
Identificativo articolo: 159298 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

Con Exchange Server, č talvolta necessario leggere e analizzare le tracce di sniffer quando la risoluzione dei problemi di comunicazione da server a server con comunicazione da client a server. Gli indirizzi di questo articolo RPC capta tra vari servizi di Exchange Server.

Informazioni

Mapper di punto di fine

Per comprendere le varie fasi attraversa un client RPC per connettersi a un determinato servizio, č necessario comprendere prima come Remote Procedure Call (RPC) ", noto come mapping degli endpoint contribuisce in caso contrario Exchange relativo assoldati per guadagnare numeri UUID di assistenza. Il mapping degli endpoint esegue una serie di attivitā, ma quello che siamo interessati a č la capacitā per farci sapere il numero di porta un servizio che si sta cercando č in ascolto sul. Č possibile classificare in genere dell'UUID dai primi 2 caratteri, per Microsoft Exchange 4.0 e 5.0:
A4 - ARCHIVIO
F5 - DIRECTORY
E1 - MAPPER DI ENDPOINT
Fateci richiedere nell'esempio seguente in cui desidera inviare un messaggio a Server ExchangeB ExchangeA Server (ExchangeA e ExchangeB si trovano nello stesso sito pertanto il meccanismo di comunicazione č RPC e in questo caso č su TCP/IP).

La prima cosa che deve eseguire ExchangeA č Fine Point Mapper del query ExchangeB per trovare in cui il MTA č in ascolto. Il motivo č il numero di porta che ogni Ascolta del servizio di Exchange puō modificare in avvii successivi. Il mapping degli endpoint č responsabile della verifica sulla quale č in ascolto quale servizio. Quando viene avviato un servizio di Exchange, si registra con il mapping degli endpoint e richiede il mapping degli endpoint da assegnare un numero di porta. Il mapping degli endpoint č sempre in ascolto sulla porta 135 per TCP/IP e UUID del mapper di endpoint č (E1AF8308 5D1F 27,9 C 9-91A4-08002B14A0FA).

I seguenti 11 frame mostrano la conversazione completa tra ExchangeA (su porta 3464) e Mapper di endpoint del ExchangeB (sulla 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
				

Il frame 1 - ExchangeA invia un pacchetto SYN ExchangeB.

Frame 2 - ExchangeB riconosce il pacchetto con un pacchetto SynAck.

Frame 3 - ExchangeA invia una conferma del SynAck. Disponiamo ora di una connessione TCP tra ExchangeA e ExchangeB.

Frame 4 - ExchangeA č associazione al mapper di endpoint dell'ExchangeB. Sappiamo questo per l'invio di binding per il numero UUID (E1AF8308 5D1F 27,9 C 9-91A4-08002B14A0FA) e anche per la destinazione: numero di porta.

Frame 5 - ExchangeB riconosce l'associazione con un BindAck. Disponiamo ora di una connessione RPC tra ExchangeA e Mapper di endpoint del ExchangeB.

Frame 6 - ExchangeA invia una richiesta RPC di numop 0 x 3 ExchangeB con l'UUID del servizio di ricerca (in questo caso č ExchangeB MTA). Si tratta di richiedere il numero di porta del servizio con il corrispondente UUID.

Frame 7 - ExchangeB restituisce il numero di porta che il servizio che corrisponde a questo tipo di UUID č in ascolto su. ExchangeA sono state raccolte tutte le informazioni necessarie per trovare il servizio MTA su ExchangeB.

Con frame 8 a 11 - chiusura la connessione TCP tra ExchangeA e ExchangeB verso il basso.

Ora che ExchangeA conosce il numero di porta č necessario connettersi ExchangeB MTA. Di seguito una nota importante č il MTA di Exchange un binding RPC leggermente diverso da quello la maggior parte dei binding RPC. Consente di eseguire un handshake bidirezionale, ovvero, non solo č ExchangeA associare a ExchangeB ma ExchangeB necessario associare a ExchangeA prima di inviare i messaggi. Di conseguenza, verrā visualizzato un binding seguita da un BindAck quindi un'altra associazione da altri server seguito da un altro BindAck, come illustrato di seguito.
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
				

Con frame 1 a 3 - volta nuovamente l'handshake TCP tre vie.

Frame 4 - ExchangeA MTA č l'associazione al MTA ExchangeB.

Frame 5 - ExchangeB riconosce l'associazione con un BindAck.

6 - Frame

Frame 7 - ExchangeA invia una richiesta RPC con numop 0 x 0. Un numop 0 x 0 č una chiamata di MtaBind. Questo genererā ExchangeB MTA per emettere un binding per ExchangeA necessitā di una connessione bidirezionale del MTA.

8 - Frame ExchangeB riconosce ricevuto frame 7.

9 Framess tramite handshake di 11 - il TCP tre vie autore ExchangeB questo momento.

Frame 12 - ExchangeB MTA č associato ExchangeA MTA.

Frame 13 - ExchangeA riconosce l'associazione con un BindAck.

14 - Frame

Frame 15 - ExchangeB invia una richiesta RPC con numop 0 x 1. Un numop 0 x 1 č una chiamata di MtaBindBack. Questa configurazione č la conversazione bidirezionale necessitā del MTA.

Frame 16 - ExchangeA riconosce ricevuto frame 15.

Risposta frame del 17 - ExchangeB Frame 7.

Risposta frame del 18 - ExchangeA Frame 15.

Questo č illustrato il flusso di una connessione RPC. Nell'esempio sopra riportato viene illustrato in modo specifico una normale connessione tra due MTA. Questo stesso tipo di conversazione verrā eseguita tra gli altri vari servizi di Exchange nonché anche se il MTA č l'unico che richiede una conversazione bidirezionale per lo scambio di informazioni.

Le informazioni contenute in questo articolo utilizza il servizio MTA per relativi esempi. Una nota importante č che lo stesso tipo di conversazione verrā effettuata con tutte le comunicazioni di Exchange RPC su TCP/IP.
  1. Verrā stabilita l'handshake a tre vie TCP.

    Il mapping degli endpoint viene consultato per determinare su quale porta il servizio desiderato č in ascolto.

    Un binding e BindAck tra i due servizi accadrā a RPC di stabilire comunicazioni.

    Facoltativo - una serie di richieste e risposte con opnums verrā emesso.

    Facoltativo - viene terminata la comunicazione RPC.

    La connessione TCP č suddiviso con pacchetti Add.
  2. Il mapping degli endpoint viene consultato per determinare su quale porta il servizio desiderato č in ascolto.

    Un binding e BindAck tra i due servizi accadrā a RPC di stabilire comunicazioni.

    Facoltativo - una serie di richieste e risposte con opnums verrā emesso.

    Facoltativo - viene terminata la comunicazione RPC.

    La connessione TCP č suddiviso con pacchetti Add.
  3. Un binding e BindAck tra i due servizi accadrā a RPC di stabilire comunicazioni.

    Facoltativo - una serie di richieste e risposte con opnums verrā emesso.

    Facoltativo - viene terminata la comunicazione RPC.

    La connessione TCP č suddiviso con pacchetti Add.
  4. Facoltativo - una serie di richieste e risposte con opnums verrā emesso.

    Facoltativo - viene terminata la comunicazione RPC.

    La connessione TCP č suddiviso con pacchetti Add.
  5. Facoltativo - viene terminata la comunicazione RPC.

    La connessione TCP č suddiviso con pacchetti Add.
  6. La connessione TCP č suddiviso con pacchetti Add.
Durante la ricerca tramite sniffer tracce di comunicazioni RPC o tutte le comunicazioni TCP, č importante sapere che pių conversazioni possono essere eseguiti simultaneamente. Non dare per scontato che semplicemente poiché un pacchetto di richiesta segue un pacchetto di BindAck questa richiesta proviene da determinata conversazione si č interessati. Una rapida verifica le porte di destinazione e di origine con TCP consentirā di determinare che se il pacchetto che si sta esaminando fa parte della conversazione si č interessati o non. Se č il numero di porta di destinazione e/o di origine non come numeri di porta utilizzati nell'handshake TCP tre modo, il pacchetto che si sta esaminando fa parte di una conversazione distinta.

Un filtro di una buona visualizzazione all'interno di Network Monitor, filtro per la destinazione e i numeri di porta origine fungerā da un grande aide nel garantire che i pacchetti che si sta esaminando effettivamente si appartengono alla conversazione in questione.

Una nota importante č solo questo indirizzi articolo RPC su TCP. Indipendentemente il protocollo sottostante, la parte RPC di questo articolo rimane invariata. Ad esempio RPC su IPX funzionerebbe in modo molto simile ad eccezione della comunicazione di IPX č necessario stabilire prima RPC molto nello stesso modo che TCP devono essere stabilite prima RPC.

Proprietā

Identificativo articolo: 159298 - Ultima modifica: sabato 28 ottobre 2006 - Revisione: 3.4
Le informazioni in questo articolo si applicano a:
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
Chiavi: 
kbmt kbnetwork kbusage KB159298 KbMtit
Traduzione automatica articoli
Il presente articolo č stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non č sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, pių o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non č la sua. Microsoft non č responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 159298
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.
Dichiarazione di non responsabilitā per articoli della Microsoft Knowledge Base su prodotti non pių supportati
Questo articolo č stato scritto sui prodotti per cui Microsoft non offre pių supporto. L?articolo, quindi, viene offerto ?cosė come č? e non verrā pių aggiornato.

Invia suggerimenti

 

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