Exchange szakértői körökben sokat szoktunk azzal tréfálkozni, hogy a Transport az egyszerű, hiszen a nevében is ott van, hogy Simple (SMTP: simple mail transfer protocol). De, hogy ez mennyire nem igaz, azt talán az Exchange Server 2013 bizonyította be nekünk a legjobban. Ebben a rövid bejegyzésben az Exchange Server 2013 transport szolgáltatásának architektúráját fogom bemutatni a következő célzattal:

• misztikum eloszlatása azoknak akik már elkezdtek foglalkozni a témával
• misztifikáljuk azoknak akik még nem fogtak hozzá az ismerkedéshez, ezzel egyben pár kényelmetlenségtől megszabadítjuk

Bevezetés

Ha architektúrálisan nézzük, akkor a legnagyobb változás az Exchange Server 2013 esetében az, hogy a korábbi szerepkörökhöz képest lényegesen kevesebb, szám szerint két szerepkörünk van:

• Client Access Server (CAS)
• Mailbox Server (MBX)

A levéltovábbítás (transport) szempontjából ez jelentős változás. Korábban a levéltovábbításért az Exchange organizáción belül egy dedikált szerepkör a HUB-Transport felelt. (Egy lazán kapcsolt szerepkör az Edge amiről jelenleg nem fogok írni, az Exchange Server 2013 esetében –még- nincs Edge szerepkör.)

Az Exchange Server 2010 esetében a dedikált Hub-Transport szerepkör viszonylag egysImage may be NSFW.
Clik here to view.zerű architektúrával működött. Volt egy Windows szolgáltatás, MSExchangeTransport, ami az MSExchangeTransport.exe futtatható kódot indította el. Az MSExchangeTransport feladata volt, hogy, hogy gondos gazda módjára a worker processt (dolgozó méheket) elindítsa és gondoskodjon arról, hogy a dolgozó jól érezze magát. Amolyan modern főnök, földesúr stb.

A dolgozó process az edgetransport.exe. Ezt a technika nyelvére lefordítva azt mondhatjuk, hogy a TCP-25 –s porton valójában az edgetransport.exe hallgat, ő fogadja a bejövő kapcsolatokat. Az MSExchangeTransport.exe csak elindítja, ha kell újraindítja, vagy újra beindítja a dolgozót.

Ezt viszonylag egyszerűen ellenőrizhetjük, ha lekérdezzük egy Exchange Server 2010-es kiszolgálón azt, hogy a TCP-25-s porton melyik szolgáltatás hallgat:

Image may be NSFW.
Clik here to view.

Ennél az egyszerű architektúránál jóval komplikáltabb az Exchange Server 2013.

Transport Exchange Server 2013 módra

A következő áttekintő ábrán azt láthatjuk, hogy szerepkörönként elosztva milyen Windows szolgáltatások futnak és azok milyen futtatható állományt indítanak (fent a szolgáltatás neve, lent a futtatott állomány neve):

Image may be NSFW.
Clik here to view.

Első ránézésre elég sokkoló a látvány, ki vitte el a régi egyszerű architektúrát? Azonban ha az egyes szolgáltatások funkcióját megértjük akkor kevésbé lesz rémisztő. Ezért vegyük sorra az egyes szolgáltatásokat:

• CAS szerepkör
• MSExchangeFrontEndTransport– ez az egyetlen Transport szolgáltatás ezen a szerepkörön. Feladata, hogy fogadja az SMTP kapcsolatokat, az SMTP kommunikációban az EOH (End of Header folyamatig), majd a küldő számára transzparens módon továbbítsa, proxyzza a kapcsolatot egy általa kiválasztott Mailbox kiszolgálónak. Ez a szolgáltatás nem tárol leveleket, egyszerűen csak a kapcsolatot továbbítja a Mailbox szerepkörnek. A szolgáltatás a Image may be NSFW.
  Clik here to view.
• MBX szerepkör
• MSExchangeTransport– a régi  Exchange 2010-es HUB-Transport szerepkörnél megismert szolgáltatás, azonos funkcióval. Elindítja a dolgozót, az EdgeTransport.exe-t. SMTP funkciót nem lát el, ez látható abból is, hogy nem tartozik hozzá TCP listener.
• Image may be NSFW.
  Clik here to view.
• EdgeTransport.exe– a dolgozó. Ez a komponens fogadja a bejövő SMTP kapcsolatokat. Látható hogy a TC P25, a TC P465 portokon hallgat, IPv4 és IPv6 címeken egyaránt. Két további high-range TCP porton is hallgat, azok nem a levéltovábbításhoz kapcsolódnak. Csak a TC P25 és a TCP 465 tartozik a levéltovábbításhoz.
• Image may be NSFW.
  Clik here to view.
• MSExchangeDelivery – az Exchange 2010 esetében a postaláda vagy nyílvános mappa adatbázisba történő kézbesítést egy store driver végezte, ami nem egy önálló processz volt, hanem az EdgeTransport.exe-ben volt (nagyon leegyszerűsítve). A store-ba történő kézbesítést az Exchange Server 2013 esetében az MSExchangeDelivery végzi. SMTP kapcsolatot a TCP 475-s porton keresztül fogad el, ahogy az a lenti képen is látható. További egy high-range TCP porton is hallgat a szolgáltatás aminek a levéltovábbítás szempontjából nincs szerepe.
• Image may be NSFW.
  Clik here to view.
• MSExchangeSubmission– amikor a felhasználó egy levelet elküld, akkor az Outbox (Póstázandó) mappájába helyezzük át. Az MSExchangeSubmission szolgáltatás a levelet az Outbox folderből kiveszi feldolgozza és továbbítja. Az MSExchangeSubmission szolgáltatás levelet soha nem fogad, csak küld

    Az egyes komponensek közti kapcsolatokat a következő áttekintő ábra mutatja:

Image may be NSFW.
Clik here to view.

A legfontosabb jellemzők:

• A CAS szervereken az MSExchangeFrontEndTransport.exe fogadja az SMTP kapcsolatokat a TCP25 vagy a TCP587-es portokon alapértelmezésben. Két SMTP receive connector van a CAS kiszolgálókon és ezek a receive connectorok határozzák meg, hogy valójában melyik portokon hallgat az MSExchangeFrontEndTransport.exe.
• A CAS szerver a bejövő SMTP levelet egy Mailbox szervernek továbbítja az End Of Header eseményt követően. Ez a továbbítás a Mailbox szerver EdgeTransport.exe-nek megy, vagy a TCP25, vagy a TCP465 portra. A CAS a TCP25-re vagy bármilyen általunk létrehozott receive-connectorra érkező kapcsolatokat a Mailbox szerver TCP25-re továbbít míg a TCP587-re érkező kapcsolatokat a TCP465-re továbbítja.
• Az EdgeTransport.exe nem végez közvetlen kézbesítést az adatbázisokba. A levelet a TCP475-s porton keresztül elküldi az MSExchangeDelivery.exe-nek ami RPC kapcsolaton keresztül elvégzi a levélkézbesítést az adatbázisba.
• Az MSExchangeSubmission.exe a levelet az EdgeTransport.exe-nek továbbítja TCP25-s porton keresztül.
• Az EdgeTransport.exe a levelet vagy
• egy másik SMTP kiszolgálónak küldi a TCP25-s portra
• a CAS kiszolgáló TCP717-es portjára, ha úgy van beállítva, hogy a CAS-on keresztül küldje a levelet (erről később még bővebben)

Egyéb kommunikáció a komponensek között nem történhet!

De miért jó ez?

Exchange Server 2010 esetében a HUB-Transport szerver fogadta a levelet és kézbesítette AD telephelyen belül a Store Driver segítségével az adatbázisba. Ez bizony RPC forgalom volt. Tételezzük fel, hogy van két kiszolgálónk, az egyik SMTP komponense fogadja a levelet, de a cél postaláda a másik kiszolgálón van. Ebben az esetben RPC kommunikáció megy a két kiszolgáló között. Amit nem szeretünk. Lassú, érzékeny a hálózati közegre stb.

Exchange Server 2013 esetében, hogy a Store kézbesítés egy önálló szolgáltatás lett (MSExchangeDelivery) és ahhoz tartozik egy önálló SMTP listener, azt jelenti, hogy az előző esetet feltételezve, a két kiszolgáló között SMTP kommunikáció lesz és nem közvetlenül a Store-t írjuk távolról. Ez egy fontos architektúrális lépés.

Következmények

Két fontos következménye van ennek az architektúrális módosításnak.

1, Az úgynevezett multi-role gépeken egImage may be NSFW.
Clik here to view.y ellentmondásba ütközünk a fenti világképünk ismerete mellett. A multi-role szerver az, amire a CAS és az MBX szerepkör is telepítve van. Ebben az esetben a fenti világképet figyelembe véve, két szolgáltatás hallgatna a TCP25-s porton:

• A CAS szerepkör MSExchangeFrontEndTransport szolgáltatása
• Az MBX szerepkör EdgeTransport.exe komponense

Ez viszont nem fordulhat elő, legalábbis úgy nem, hogy annak jó vége legyen. Ezért ezekben az esetekben az EdgeTransport.exe automatikusan a TCP2525-s porton hallgat, míg a TCP25 az MSExchangeFrontEndTransport szolgáltatásé. Itt azonban nagyon figyelni kell. Ugyanis amikor egy új receive-connector-t hozunk létre powershell segítségével az alapértelmezésben a multirole gépeken a Mailbox szerepkörhöz hozza létre a connectort. Tehát, ha multi-role gépünk van és szeretnénk egy új TCP25-n hallgató connectort létrehozni powershell-ből, az a Mailbox szerepkörhöz fog létrejönni. Vagyis az EdgeTransport.exe szeretne a TCP25-s porton hallgatni, ami már foglalt. Ezekben az esetekben használjuk a new-receiveconnector TransportRole paraméterét, amivel a connector a FrontEndTransport (CAS) szerepkörön hozható létre:

Image may be NSFW.
Clik here to view.

Pontosan ugyanez érhető el azzal, ha az EAC segítségével hozunk létre egy receive connImage may be NSFW.
Clik here to view.ectort, és a Role (szerepkör) beállításnál kiválasztjuk a megfelelő szerepkört. Ennek a hatását ne felejtsük el, ha:

• HubTransport – akkor az EdgeTransport.exe, vagyis a Mailbox szerepkört konfiguráljuk
• Frontend Transport – akkor az MSExchangeFrontEndTransport szolgáltatást, vagyis a CAS szerepkört konfiguráltuk

2, A másik következmény az, hogy a Mailbox kiszolgálóról a levél két úton is kimehet:

• A Mailbox kiszolgáló jogosult elküldeni a levelet a célállomásnak, ami lehet egy másik MaImage may be NSFW.
  Clik here to view.ilbox szerver, vagy lehet egy MX rekord alapján megtalált Interneten működő SMTP szerver, vagy egy Smart-Host
• Azonban a levelet küldheti a CAS kiszolgálón keresztül is. Ilyenkor a tényleges levélküldést a Mailbox kiszolgáló végzi, de úgy, hogy Layer4 nézetből nézve az valójában a CAS kiszolgálótól megy ki. Ilyenkor a Mailbox szerver a CAS kiszolgáló TCP717-es portjára küldi a forgalmat, a CAS pedig intelligens proxy módjára továbbítja az SMTP forgalmat a célkiszolgálónak. Ezt a funkciót a Send Connector beállításával szabályozhatjuk. A “proxy through client access server” funkció engedélyezésével a levél a korábban leírt módon jut el a célkiszolgálóhoz.

Zárszó

Talán ez a rövid összefoglaló sokadszori elolvasása után mindenkinek érthető lesz, hogy mi és miért változott és nem lesz ördögtől való a látvány amikor egy Exchange Server 2013-as kiszolgálón az alábbi gyárilag létrehozott receive connectorokat látja (a kép egy multirole kiszolgálón készült):

Image may be NSFW.
Clik here to view.

A játék indul, feltudod írni a fenti képen látható összes connector-hoz tartozóan:

• melyik szerepkörhöz tartozik? – ez elég egyszerű
• milyen porton hallgat?
• melyik Windows szolgáltatás vagy melyik futtatható állomány tartozik hozzá?

Image may be NSFW.
Clik here to view.