Analýza provozu Exchange RPC nad protokolem TCP/IP

Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.

Projděte si také anglickou verzi článku:159298
Tento článek byl archivován. Je nabízen v takovém stavu, v jakém je, a nebude již nadále aktualizován.
Souhrn
S Exchange Server někdy potřebujete číst a analyzovat trasování programu pro sledování toku dat při odstraňování komunikace server server spolu s komunikace klient server. Tento článek adresy RPC sniffs mezi různé služby Exchange Server.
Další informace

Koncový bod mapovače

Pochopení různých fází prochází klient pro připojení k určité služby, jsme musíte nejprve porozumět volání vzdálené procedury (RPC) Service ', jinak, známý jako koncový bod mapovače pomůcek v jeho hledání čísla UUID služby Exchange. Mapovače koncový bod provádí různé úkoly, ale jeden jsme zajímají je schopnost nás na nenaslouchá služba jsme hledáte číslo portu. UUID's může obecně rozdělena první 2 znaky, pro Microsoft Exchange v4.0 a v5.0:
A4 - ÚLOŽIŠTĚ
ADRESÁŘ F5
MAPOVAČ E1
Sdělte nám trvat následující příklad ExchangeA Server chce odeslat zprávu na Server ExchangeB (ExchangeA a ExchangeB jsou ve stejné síti, proto je mechanismus komunikace RPC a v tomto případě je přes TCP/IP).

První věcí, které musí provést ExchangeA je ExchangeB dotazu End Point mapovače najít, kde jeho MTA naslouchá. Důvod pro toto je číslo portu na následné spuštění můžete změnit každý služba naslouchá Exchange. Mapovač koncový bod je zodpovědný za sledování, kterou služba poslouchá na které bodu. Spustí službu Exchange zaregistruje sám mapovače koncový bod a požádá mapovače koncový bod přiřadit číslo portu. Koncový bod mapovače vždy naslouchá na portu 135 pro TCP/IP a koncový bod mapovače UUID je (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA).

Následující 11 rámců zobrazit úplný konverzaci mezi ExchangeA (na portu 3464) a jeho ExchangeB mapovače koncový bod (na port 135):
1. TCP: ....S., len:    4, seq: 562005063-562005066, ack:         0, win:   8192, src: 3464  dst:  1352. TCP: .A..S., len:    4, seq: 875064831-875064834, ack: 562005064, win:   8760, src:  135  dst: 34643. TCP: .A...., len:    0, seq: 562005064-562005064, ack: 875064832, win:   8760, src: 3464  dst:  1354. MSRPC: c/o RPC Bind:         UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA   call 0x54004E  assoc grp 0x0  xmit 0x16D0  recv 0x16D05. MSRPC: c/o RPC Bind Ack:     call 0x54004E  assoc grp 0x33CFA  xmit   0x16D0  recv 0x16D06. MSRPC: c/o RPC Request:      call 0x1  opnum 0x3  context 0x0  hint   0x847. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x80  cancels   0x08. TCP: .A...F, len:    0, seq: 562005292-562005292, ack: 875065044, win:   8548, src: 3464  dst:  1359. TCP: .A...., len:    0, seq: 875065044-875065044, ack: 562005293, win:   8532, src:  135  dst: 346410. TCP: .A...F, len:    0, seq: 875065044-875065044, ack: 562005293, win:   8532, src:  135  dst: 346411. TCP: .A...., len:    0, seq: 562005293-562005293, ack: 875065045, win:   8548, src: 3464  dst:  135				

Rámec 1 - ExchangeA odešle paket SYN ExchangeB.

Rámce 2 - ExchangeB uznává paket s paket SynAck.

Rámec 3 - ExchangeA odešle potvrzení SynAck. Máme nyní připojení TCP mezi ExchangeA a ExchangeB.

Rámec 4 - ExchangeA je vazba mapovače ExchangeB jeho koncový bod. Jsme znát toto podle odesílá vazby na číslo UUID (E1AF8308-5D1F-11 C 9-91A4-08002B14A0FA) a také dst: číslo portu.

Rámec 5 - ExchangeB uznává vazby s BindAck. Máme nyní připojení RPC mezi ExchangeA a mapovače ExchangeB jeho koncový bod.

Rámec 6 - ExchangeA odešle RPC Request opnum 0x3 ExchangeB spolu s UUID služby je hledáte (v tomto případě je jeho ExchangeB MTA). Toto je číslo portu služby s odpovídající UUID požadavku.

Rámec 7 - ExchangeB vrátí číslo portu služby, který odpovídá této UUID poslouchá. ExchangeA má nyní veškeré informace potřebuje najít MTA v ExchangeB.

Rámce 8 až 11 - uzavření dolů připojení TCP mezi ExchangeA a ExchangeB.

Nyní, ExchangeA zná číslo portu musí připojit k jeho ExchangeB MTA. Důležitá poznámka zde je mírně odlišné než většina vazby RPC vytvoření vazby RPC ani Exchange MTA. Provádí obousměrný handshake, což znamená pouze ExchangeA nemá vazbu ExchangeB ale ExchangeB musí svázat ExchangeA před odeslány žádné zprávy. Proto by se měl zobrazit vazby následovaný BindAck potom jiného vazby ze serveru, následovaný jiným BindAck, jak je znázorněno níže.
1. TCP: ....S., len:    4, seq: 562005113-562005116, ack:         0, win:   8192, src: 3470  dst: 47642. TCP: .A..S., len:    4, seq: 875064881-875064884, ack: 562005114, win:   8760, src: 4764  dst: 34703. TCP: .A...., len:    0, seq: 562005114-562005114, ack: 875064882, win:   8760, src: 3470  dst: 47644. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE   call 0x1EBE80  assoc grp 0x0  xmit 0x16D0  recv 0x16D05. MSRPC: c/o RPC Bind Ack:     call 0x1EBE80  assoc grp 0x3150EAC1  xmit   0x16D0  recv 0x16D06. TCP: .AP..., len:  206, seq: 562005250-562005455, ack: 875064990, win:   8652, src: 3470  dst: 47647. MSRPC: c/o RPC Request:      call 0x1  opnum 0x0  context 0x0  hint   0x11E8. TCP: .A...., len:    0, seq: 875064990-875064990, ack: 562005792, win:    8082, src: 4764  dst: 34709. TCP: ....S., len:    4, seq: 875064951-875064954, ack:         0, win:    8192, src: 1969  dst: 173310. TCP: .A..S., len:    4, seq: 562005173-562005176, ack: 875064952, win:   8760, src: 1733  dst: 196911. TCP: .A...., len:    0, seq: 875064952-875064952, ack: 562005174, win:   8760, src: 1969  dst: 173312. MSRPC: c/o RPC Bind:         UUID 9E8EE830-4459-11CE-979B-00AA005FFEBE   call 0x6C645F65  assoc grp 0x0  xmit 0x16D0  recv 0x16D013. MSRPC: c/o RPC Bind Ack:     call 0x6C645F65  assoc grp 0x215D6F47   xmit 0x16D0  recv 0x16D014. TCP: .AP..., len:  192, seq: 875065087-875065278, ack: 562005282, win:   8652, src: 1969  dst: 173315. MSRPC: c/o RPC Request:      call 0x7DFE09C  opnum 0x1  context 0x0   hint 0x216. TCP: .A...., len:    0, seq: 562005282-562005282, ack: 875065335, win:   8377, src: 1733  dst: 196917. MSRPC: c/o RPC Response:     call 0x7DFE09C  context 0x0  hint 0x1C   cancels 0x018. MSRPC: c/o RPC Response:     call 0x1  context 0x0  hint 0x20  cancels   0x0				

Rámce 1 až 3 - jednou znovu naše handshake TCP tři způsobem.

Rámec 4 - ExchangeA MTA je vazba MTA ExchangeB.

Rámec 5 - ExchangeB uznává vazby s BindAck.

6 - Rámce

Rámec 7 - ExchangeA odešle požadavek RPC s opnum 0x0. Opnum 0x0 je volání MtaBind. To aktivují ExchangeB's MTA problém vazby ExchangeA, jako MTA potřebovat dva způsob připojení.

Rámec 8 - ExchangeB uznává přijatých rámců 7.

Framess 9 až 11 - náš TCP tři způsobem handshake iniciováno ExchangeB tento čas.

Rámec 12 - ExchangeB MTA vazbu k jeho ExchangeA MTA.

Rámec 13 - ExchangeA uznává vazby s BindAck.

14 - Rámce

Rámec 15 - ExchangeB odešle požadavek RPC s opnum 0x1. Opnum 0x1 je volání MtaBindBack. Toto je nastavení konverzace dvě způsobem nutné MTA.

Rámec 16 - ExchangeA uznává přijatých rámců 15.

Odpověď na rámec 17 - ExchangeB's na snímek 7.

Odpověď na rámec 18 - ExchangeA's 15 rámce.

Tato ukázka toku připojení RPC. Výše uvedený příklad ilustruje konkrétně typické připojení mezi dvěma MTA. Tento stejný druh konverzace se stane mezi ostatní různých Exchange služby i, ačkoli MTA je jediným potřebuje konverzace dvě způsob výměny informací.

Informace obsažené v tomto článku používá MTA pro jeho příklady. Důležitá poznámka je tento stejný typ konverzace se stane s veškeré komunikace Exchange RPC nad protokolem TCP/IP.
  1. Bude vytvořeno třícestné TCP.

    Koncový bod mapovače kontroloval k určení, na kterém portu nenaslouchá služba chtěli.

    Vazby a BindAck mezi dvě služby se stane RPC navázat komunikaci.

    Volitelné - bude vystaven řada požadavky a odpovědi s opnums

    Volitelné – tato komunikace RPC je ukončena

    Připojení TCP je porušena s pakety fin.
  2. Koncový bod mapovače kontroloval k určení, na kterém portu nenaslouchá služba chtěli.

    Vazby a BindAck mezi dvě služby se stane RPC navázat komunikaci.

    Volitelné - bude vystaven řada požadavky a odpovědi s opnums

    Volitelné – tato komunikace RPC je ukončena

    Připojení TCP je porušena s pakety fin.
  3. Vazby a BindAck mezi dvě služby se stane RPC navázat komunikaci.

    Volitelné - bude vystaven řada požadavky a odpovědi s opnums

    Volitelné – tato komunikace RPC je ukončena

    Připojení TCP je porušena s pakety fin.
  4. Volitelné - bude vystaven řada požadavky a odpovědi s opnums

    Volitelné – tato komunikace RPC je ukončena

    Připojení TCP je porušena s pakety fin.
  5. Volitelné – tato komunikace RPC je ukončena

    Připojení TCP je porušena s pakety fin.
  6. Připojení TCP je porušena s pakety fin.
Při hledání prostřednictvím programu pro sledování toku dat trasování komunikace RPC nebo veškeré komunikace protokolu TCP je důležité, jste si vědomi, že více konverzací, může být vyskytují současně. Není předpokládají, jednoduše protože paketu Request následuje paket BindAck dodané tento požadavek z konkrétní konverzace vás zajímají. Rychlá kontrola zdrojové a cílové porty s TCP vám sdělí, pokud prohlížíte paket je součástí konverzace vás zajímají nebo Ne. Pokud je číslo portu zdrojového a cílového žádné stejný jako port čísel použitých v handshake způsobem TCP tři prohlížíte paket je součástí samostatné konverzace.

Filtr vhodné zobrazení v rámci sledování sítě filtrování na cílové a čísla portů zdroj bude sloužit jako skvělý aide v zajištění pakety prohlížíte ve skutečnosti nepatří do dotyčný konverzace.

Jeden další důležitá Poznámka pouze je adresy tohoto článku RPC přes TCP. Bez ohledu na novinky podkladové protokol RPC část tohoto článku zůstane stejné. Protokol RPC over IPX, by například pracovat poměrně podobně, s výjimkou komunikace IPX by musel být navázáno před k RPC mnohem stejným způsobem jako TCP musí být vytvořeno před RPC.
Sledování sítě netmon

Upozornění: Tento článek je přeložený automaticky

Vlastnosti

ID článku: 159298 - Poslední kontrola: 12/04/2015 15:46:18 - Revize: 3.4

Microsoft Exchange Server 5.5 Standard Edition, Microsoft Exchange Server 4.0 Standard Edition, Microsoft Exchange Server 5.0 Standard Edition

  • kbnosurvey kbarchive kbmt kbnetwork kbusage KB159298 KbMtcs
Váš názor