Category: transport

Miszter X és a fejléc tűzfal

2011-07-14 / / 2 Comments

Egyszer már piszkálgattam a receive konnektorokat, csakhogy ezek olyanok, hogy nem lehet sokáig piszkálatlanul hagyni őket.

De most egy kicsit más perspektívából szeretnék foglalkozni velük, sőt, nem is csak velük. Bemelegítésképpen nézzük meg ezt az ábrát.

From Segédlet

Szép ábra, sokat szoktam nézegetni. (Az eredeti, poszter méretben itt található.) De nem csak szép, hasznos is. (Tipikus háttérkép a desktopra.)
Nos, ha eleget nézegetjük, feltűnhet, hogy van egy elem, mely többször is szerepel rajta. Narancssárga téglalap és az van beleírva, hogy header firewall. Ahhoz képest, hogy mennyiszer szerepel, nem mondhatni, hogy túlzottan benne lenne a köztudatban.

Na, ezen szeretnék most javítani.

Első lépésben vizsgáljuk meg, mi is az a header, amit tűzfalazni kell. Nagy vonalakban az email (és most csak a belső részéről beszélek, a boríték jelen cikkben nem játszik) két részből áll: fejlécből és tartalomból. A fejlécen belül pedig megkülönböztetünk szabványos mezőket és nem szabványos (vagy ronda szóval élve kvázi-szabványos) mezőket. A szabványosakat RFC írja le, a nem szabványosakról nem ír semmit az RFC (azért nem szabványosak), de elterjedt, hogy az X betűvel kezdődő fejlécmezők gyakorlatilag bármiből állhatnak, bármit jelenthetnek. Azaz ezek a mezők gyártóspecifikusak: egy konkrét gyártó smtp szervere érteni fogja, mit akar üzenni neki egy másik, hasonló szerver, a többi smtp szerver meg nem foglalkozik ezekkel a mezőkkel.
A valóságban itt is lezajlott egy evolúció, néhány X-mező annyira elterjedt, hogy ma már a kitalálójától eltérő gyártók is használják.

Mire jók ezek a mezők? Rengeteg mindenre. A feladó smtp szerver belerak egy csomó információt, melyeket utána a többi smtp szerver is fel tud használni. Ide kerülhet bele, hogy a levél mikor lépett be az Exchange birodalomba, milyen autentikációs módszerrel jutott be, milyen transport rule-ok gyötörték meg a levelet, sima levél vagy journaling… és egy csomó egyéb dolog. Akár magunknak is gyárthatunk X-mezőket. (Igaz, ez a cikk még eventsink-kel dolgozik, de ügynökkel sem lehet sokkal bonyolultabb.) X-mezőbe kerül bele az például, hogy a levelet mennyire érezte szpemnek egy korábbi smtp szerver (Spam Confidence Level, SCL), illetve az is, hogy már átment egy vizsgálaton és ne vizsgálják többet.

Hoppá.

Bejelzett a vészcsengő? Egy szpemmer számára mi sem lenne egyszerűbb, mint rögtön az elején belerakni a levelekbe egy X-mezőt, miszerint ezt a levelet már ne vizsgálják, oszt jónapot.

Na, itt lép be a képbe a header firewall. Ez ugyanis azt csinálja, hogy – beállítástól függően – kipucolja akár az Exchange által használt X-mezőket, akár az egyéb fejlécmezőket a levelekből. Így bejövő levél esetében nem hiszünk el semmit a többi smtp szervernek, kimenő levél esetén nem adunk ki olyan információt, mely segíthet feltérképezni a belső rendszerünket.

Ennyit a bevezetésről, jöhet a vadulás.

Hogyan tudjuk aktivizálni a header firewallt? Hát, úgy, hogy letiltjuk. Gyárilag ugyanis általában működik. De nagyon nem mindegy, hogy kifelé megy a levél, vagy befelé jön, illetve a feladó smtp szerver milyen jogosultságokkal bír a konkrét (receive/send) konnektoron. Érzem, hogy ebből nehéz lesz érthetően kijönnöm, inkább írok egy példát. Egy konkrét receive konnektoron engedélyezem az Ms-Exch-Accept-Headers-Organization jogosultságot mondjuk az ExchangeServers jogosultsági csoportnak. Ebben az esetben, ha egy levél ezen a receive konnektoron keresztül jött be és a sessiont kezdeményező akárki tagja az ExchangeServers jogosultsági csoportnak, akkor a header firewall kussol, legalábbis az organizáció szintű X-mezőkkel kapcsolatban. (Az Exchange X-mezőknek két nagy csoportja van, az organizáció szintűek és az erdő szintűek. Az előző jogosultságnak az erdő szintű X-mezőkre vonatkozó párja az Ms-Exch-Accept-Headers-Forest jogosultság.) Ha a sessiont kezdeményező nem tagja az ExchangeServers permission groupnak, azaz tiltva van számára az a bizonyos accept-headers jogosultság, és a levél ezen a receive konnektoron keresztül jön be, akkor a header firewall már ugrik és gyapálja is ki az organizáció szintű X-mezőket. Értelemszerűen a send konnektorokkal is hasonlóan tudunk elbánni.

Szóval, jogosultság és jogosultsági csoportok. Emlékszünk?

From Segédlet

Látható, hogy gyárilag létezik néhány előre definiált jogosultsági csoport (permission group). Hogy még durvább legyen a helyzet, létezik néhány előre definiált receive konnektor tipus is.

From Segédlet

Gondolom, senkit nem lep meg, hogy mindegyikhez – tehát jogosultsági csoporthoz is és konnektortipushoz is – eleve be van állítva, hogy működjön a header firewall, vagy sem.

Na, ezt nem kis munka lesz nyomon követni.
Szerencsére annyira nagy sem.

Mind az organizáció, mind az erdő szintű X-mezőket illetően a receive konnektoroknál csak az internal tipusnál és csak az ExchangeServers jogosultsági csoportnál nem működik a header firewall, minden más esetben igen.
Send konnektor esetén némileg bonyolult a helyzet, ott gyárilag nem jogosultsági csoport van hozzárendelve a konnektorhoz, hanem security group. Nagy általánosságban elmondható, hogy ha internal tipusú konnektort gyártottunk, akkor az Exchange szervereket tartalmazó csoportoknál nem működik a header firewall, minden más esetben igen.

Jogos lehet a kérdés, hogy bele tudunk-e ebbe piszkálni? Nos, egy irányba igen. Ha nagyon megerőszakoljuk a rendszert, akkor be tudjuk állítani, hogy az Exchange szerverekre is vonatkozzon a tűzfal.

Azaz összességében elmondható, hogy az Exchange 2010 elég kegyetlenül bánik a saját X-mezőivel: se ki nem engedi, se be nem engedi azokat, de még bent is csak az ExchangeServers jogosultsági csoport élvez mentességet. És ezek közül sem mindegyik. Organizáció, illetve erdő szintű X-mező eleve csak a 2007-es verziótól felfelé létezik, azaz ha korábbi verziójú szerverről jön levél, akkor dolgozik a header firewall (mert vagy nincs benne ilyen X-mező, ha meg van, akkor biztosan sunyi módon került bele), illetve amennyiben korábbi verziójú Exchange szerverre megy a levél, akkor meg azért lép akcióba a header firewall, mert tök felesleges lenne az X-mezőket benne hagyni, a szerver úgysem értené.

Megjegyzem, a levélküldésbe nem csak konnektorokon keresztül kerülhetnek be a levelek. Tessék csak megnézni, a narancssárga téglalapok ott vannak minden kilométerkőnél.

  • Pickup könyvtár: Ide lehet manuálisan leveleket behajigálni. A header firewall működik.
  • Replay könyvtár: Ide kerülnek azok a levelek, melyek egyszer már bent voltak a queue-ban, csak éppen valamiért kikerültek onnan. Ha ez a queue Exchange2010-es volt (az X-Createdby X-mező értéke MSExchange14), akkor a header firewall békén hagyja a levelet, ha nem, akkor rávetődik.
  • Drop könyvtár: A külsős alkalmazások könyvtára, a foreign konnektorok révén ezen keresztül tudnak leveleket küldeni, fogadni. A header firewall aktív.
  • Store driver: A kapcsolat a mailbox adatbázis és az smtp motor között. A kifelé menő levelek esetében a header firewall kivágja az illetékes X-mezőket, a befelé jövő levelek esetében válogat: bizonyos X-mezők repülnek, mások maradhatnak. (Oké, pongyola voltam. Általánosságban elmondható, hogy a szpemekkel kapcsolatos X-mezők maradnak, a többiek nem. Az ugye tiszta, hogy ezeket az infókat csak a mi smtp szerverünk rakhatta bele a levélbe, mert a kintről jövő levelekből az Edge/Hub már korábban kivágta az ilyesmit, már ha léteztek egyáltalán.)
  • Delivery Status Notfication, DSN: A header firewall mindig kigyapálja az X-mezőket a DSN-be ágyazott eredeti levelekből.

Jó. A trükkös szpemekkel elbántunk. (Az SCL is X-mező, Exchange 2010-ben egész pontosan így hivják: X-MS-Exchange-Organization-SCL.) Az X-mezők kaptak egy tockost meg egy kokit, nem mennek kifelé, nem jönnek befelé. De jó-e az nekem, ha pl. egy alkalmazásszerverem az Exchange szerveren keresztül küld ki levelet, és ez az útvonal benne marad a levélben? Nevekkel együtt? Ki tudnám ezt gyapálni?
Ki.
A logika teljesen hasonló az organizáció illetve erdő szintű X-mezőkhöz. Ha egy konnektoron engedélyezve van egy identitás számára a Ms-Exch-Accept-Headers-Routing jogosultság, akkor a routing információk benne maradnak a levél fejlécében. Ha nem, akkor a header firewall kitörli azokat.
Nézzük az alapértelmezéseket. Receive konnektoron a a következő jogosultsági csoportok számára helyből engedélyezve van a jog (azaz tiltva a header firewall): Anonymous, ExchangeUsers, ExchangeServers, ExchangeLegacyServers, Partner. Valamennyi név a naptárban. (Vessünk egy pillantást a fenti ábrára: csak ezek vannak.) Hogy lehet akkor aktivizálni a header firewallt, hogy mégiscsak rúgja ki a routing információkat? Úgy, hogy Custom konnektort készítünk és nem adunk meg semmilyen jogosultsági csoportot. Vagy meglévő konnektorból töröljük ki az összeset. Vagy az Add-ADPermission paranccsal vesszük el egy-egy csoporttól a konkrét konnektoron a jogot.
A Send konnektorokok esetében nagyjából hasonló a helyzet, alapértelmezésben a routing információk maradnak, de ha akarjuk, akkor a jogosultság tiltásával a header firewall kiszedi azokat. Érdemes megemlíteni itt is az alternatív útvonalakat: a Replay, Drop könyvtárak, illetve az ügynökökön keresztül érkező levelek esetében a header firewall nem bántja a routing információkat. A Pickup könyvtár esetében mindig törlődnek a routing információk. Szintúgy a DSN-be ágyazott levelek esetében. A Store driver a kifelé menő levelek esetében töröl, a befelé jövők esetében nem. (Ez egy kicsit félrevezető lehet. A Store driver a mailbox és a hub transport szerepkör között dolgozik. Azaz ha jön egy levél a mailbox adatbázisból, melyet a kliens mondjuk MAPI-n keresztül rakott össze, annak a routing információit – ha vannak egyáltalán – nem engedjük ki. De a következő lépésben a hub transport szerver belerakja a saját routing információját és az már marad.)

A sok elmélet után jöjjön most egy konkrét példa. Van egy Oracle szerverünk, meg egy csomó alkalmazásunk. A szerveren fut egy smtp szerver is, az alkalmazások azon keresztül leveleznek, illetve a cégből kifelé egy Exchange szerveren keresztül. Hogyan tudjuk megoldani, hogy az internetre ne kerüljenek ki az Oracle szerverre vonatkozó routing információk? Úgy, hogy a szerver kap egy egyedi receive konnektort (csak az ő IP címe szerepel benne), a jogosultsági csoportok közül meg egyet sem adunk meg. Ekkor a konnektoron nem lesz Ms-Exch-Accept-Headers-Routing jogosultság, amit a header firewall úgy értelmez, hogy tiltva van – azaz törli az addigi routing információkat.
Aha. Viszont rögtön belefutunk abba, hogy ez egy open relay tipusú konnektor (igaz, csak egy IP címre), amelyhez Externally Secured autentikáció kell. Ez viszont kiköveteli az ExchangeServers jogosultsági csoportot. Megoldás: az Add-ADPermission paranccsal csak ezen a konnektoron deny-re állítjuk az ExchangeServers permission group jogosultságát az Ms-Exch-Accept-Headers-Routing elemi jognál.

Ezzel tulajdonképpen be is fejeződhetne a cikk. Beszéltünk 3 jogosultságról (Ms-Exch-Accept-Headers-Organization, Ms-Exch-Accept-Headers-Forest, Ms-Exch-Accept-Headers-Routing), arról, hogy mi történik, ha ezeket a jogosultságokat elvesszük, illetve arról, hogy mik a gyári beállítások. Úgy gondolom, hogy hasznos lehet a másik oldalról is ránézni az összerendelésekre: milyen jogosultságokkal rendelkeznek beépítetten az egyes jogosultsági csoportok?

Anonymous (Anonymous user account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
– Ms-Exch-Accept-Headers-Routing

ExchangeUsers (Authenticated user accounts)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-Accept-Headers-Routing

ExchangeServers (Hub Transport servers, Edge Transport servers, Exchange Servers (Hub Transport server only), Externally Secured servers)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50
– Ms-Exch-Accept-Headers-Organization (Kivéve az Externally Secured servers.)
– Ms-Exch-Accept-Headers-Forest (Kivéve az Externally Secured servers.)

ExchangeLegacyServers (Exchange Legacy Interop security group)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50

Partner (Partner Server account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-Accept-Headers-Routing

És legvégül két link a témában jobban elmélyülni szándékozóknak:

Welcome

2010-12-14 / / 0 Comments

Az ember azt gondolná, hogy ezek a receive konnektorok olyan kicsi, ártalmatlan lények. Aztán ádehogy. (Nem véletlenül szoktam mondani, hogy a konnektorok közül ők a nőneműek. Elvégre az ő dolguk a behatolási engedélyek kiosztása.)

És ha olyan egyszerű lenne behangolni őket! De nem. Hiába tudod, mit szeretnél, ha egyáltalán nem olyan egyértelmű azt összekattogtatni. Az első két fül (general, network) még hagyján, itt minden érthető. De hogyan is kell értelmezni az authentication, illetve permission group fogalmakat? Hiszen mind a kettő ugyanazt jelenti, nem? Nem. Az autentikáció azt mondja meg, hogy a konnektor milyen autentikációs módszereket, milyen technikákat fogadjon. A permission group pedig azt, hogy – az autentikációs technológia alkalmazása után – kik, milyen csoportok férhessenek hozzá a konnektorhoz.
Hogy egy hasonlattal éljek. Odamész egy bankautomatához. Rá van írva, milyen kártyákat ismer. Pl. Visa és ECMC. Ha csak American Express kártyád van, akkor ez nem a te automatád, biztosan nem vehetsz ki pénzt belőle. Ha van ECMC kártyád, akkor bedugod, az automata felismeri, mehetsz tovább. (Ami persze nem jelent automatikusan pénzt, kell a pinkód, kell, hogy legyen zsé a kártyádon, kell, hogy legyen zsé az automatában, stb.)

From Segédlet
From Segédlet

Játszunk el egy kicsit a beállításokkal.

1. kísérlet

Authentication: Externally secured
Permission Groups: anonymous, exchange servers

Ez egy kikényszerített beállítás. Igazából azt szerettem volna elérni, hogy a konnektor teljesen nyitott legyen (ribanc), azaz mindenhonnan mindenkitől befogadjon minden levelet, függetlenül attól, hogy azok neki szóltak, vagy más, akár külső címzettnek. Ezt nevezik egyébként open relay-nek. Ehhez csak az anonymous-t akartam megadni, de a varázsló ragaszkodott hozzá, hogy be legyen kattintva az exchange servers jogosultsági csoport is. Őszintén szólva, fogalmam sincs miért. Hiszen az autentikációs módszernél azt mondtuk, hogy nem foglakozunk az autentikációval, eleve megbízunk a feladóban.

Eredmények:
Levélküldés bentről kintre: sikerült
Levélküldés kintről bentre: sikerült.
Levélküldés kintről kintre: sikerült.

(A tesztről pár szót. Telnet-tel kapcsolódtam a szerverre, a bent és a kint az gyakorlatilag belső, illetve külső feladót jelent. A siker pedig azt, hogy a szerver befogadta a levelet az smtp queue-ba. A továbbküldés – mely már a send konnektor dolga – most nem érdekelt.)

2. kísérlet

Authentication: semmi
Permission Groups: anonymous

Eredmények:
Kintről bentre: sikerült.
Bentről kintre: unable to relay
Kintről kintre: unable to relay.

Fura, nem? Az ember azt gondolná, hogy ez aztán az igazi open relay, nem autentikálunk és csak anonymous hozzáférést engedélyezünk. Ehhez képest igen durva az eredmény, a szerver csak befelé jövő levelet fogad. Már kifelé sem tudunk küldeni, még létező belső felhasználóval sem.

3. kísérlet

Elegem lett a kotyvasztásokból, gondoltam, megnézem, milyen lehetőségeket adnak a beépített tipusok. (Amikor létrehozunk egy receive konnektort, akkor sablonokból választhatunk. Az előző kettő custom sablon volt.)

From Segédlet

Authentication: TLS
Permission Groups: anonymous

Ez az internet sablon volt.

Eredmények:
Kintről bentre: sikerült.
Bentről kintre: unable to relay
Kintről kintre: unable to relay.

Gyakorlatilag ugyanaz történt, mint az előbbi esetben. Ami nem baj, hiszen pont ezt is akartuk: a receive konnektor mindenkitől elfogad levelet, feltéve, hogy a címzett belső ember.

4. kísérlet

Authentication: TLS, exchange server authentication
Permission Groups: exchange servers

A fenti kombináció az internal sablon.

Eredmények:
Hát, az most nincs. Rögtön az első próbálkozásnál, már a ‘mail from’ paraméternél ezt kaptam vissza: client was not autenticated. Ami teljesen rendben is van, hiszen nem vagyunk Exchange szerverek.
Mindenesetre éles rendszerben használva a konnektor remekül működik, a szerver elfogadja a kifelé menő leveleket.

Oké, játszottunk. Most viszont, a kísérletek fényében, rakjunk össze működő receive konnektorokat, különböző esetekre.

Edge Transport szerver

Én a magam részéről törölni szoktam az automatikusan létrejövőket, mert gyakorlatilag nem működnek. Ehelyett a következőket használom:

from corenet
Azok a levelek, melyeknek a címzettje kint van a nagyvilágban. A sablon, amelyikből a konnektor készül, az az internal(!), a network fülön csak a belső Exchange szervereket adom meg.

from internet
Azok a levelek, melyek kintről jönnek és a címzettjük a cégen belül van. A sablon, amelyikből készül, az internet, a network fülön a teljes IP tartományt (0.0.0.0 – 255.255.255.255) kell megadni.

relay
Mindenki, aki a DMZ-ből az Exchange SMTP szerverét használva próbál levelet küldeni. A sablon a custom, a beállítások az 1. kísérletben leírtak. A network fülön csak azokat az IP címeket adjuk meg, amelyek küldhetnek. (Ezzel azért bánjunk óvatosan, hisz ezekre az IP címekre nézve az Exchange szerver open relay lesz.)

Hub Transport szerver

A különbség az, hogy ez a szerver már bent van a belső hálózatban.

client
Gyári konnektor. Ha megnézed, egész érdekes portot használ (587). Ez az SMTP Submission protokoll portja. A történet arról szól, hogy ha van olyan felhasználónk, akinek van belső postafiókja (exchange users permission group), de nem Outlookból levelez, hanem bármilyen más levelezőklienssel (Thunderbird, Eudora, Pine, Pegasus és egyebek), akkor nem RPC-n adja fel a levelét, hanem azon a bizonyos SMTP Submission protokollon. Ha nincs ilyenünk, akkor nyugodtan tiltsuk le a konnektort, ha van, akkor pedig értelemszerűen állítsuk be az IP címeket a network fülön.

default
Ez a – szintén gyári – konnektor leginkább az internal sablonra hasonlít. Ezen annyit szoktam változtatni, hogy nem engedem a teljes IP tartományt, hanem csak a létező Exchange HTS/ETS szerverek IP címeit engedélyezem.

relay
Nagyjából megegyezik az Edge szervernél írtakkal. Annyi az összes különbség, hogy itt már a belső hálón vagyunk, ergo itt azon belső, de nem Exchange szerverek IP címeit adjuk meg, amelyeknek levelezési kényszerük van.

Megint back pressure

2010-09-29 / / 2 Comments

Emailben kaptam egy kérdést és ez ráébresztett arra, hogy talán érdemes lenne ejteni pár szót erről az ‘apróság’-ról.

Megint a back-pressure. Az ezerszer elátkozott. Rengeteget gyaláztam már, könyvben, is, blogban is.
Itt az ideje, hogy meg is védjem. Egy kicsit.

Az Exchange ESE adatbázis-kezelése tranzakciós alapú. Erről most nem akarok túl sokat írni, a lényeg az, hogy a friss, illetve a frissen használt adatok főleg a RAM-ban és a logfájlokban vannak, az adatbázisba csak akkor íródnak ki, ha az alkalmazás éppen ráér. Az elmélet gyenge pontja az, hogy mi történik akkor, ha éppen elfogy a tárterület az adatbázisok alól? A korábbi verziók védelméből létezik még két placeholder fájl a logkönyvtárban, de két lognyi hely… nem tudok olyan gyorsan pislogni, amilyen gyorsan az elfogy.
Ezért találták ki a back-pressure-t. Hogy amikor egy kritikus érték alá esik a szabad tárterület, az Exchange állítsa le tisztán az adatbázisokat (clean shutdown), mielőtt azok inkonzisztens állapotban dőlnének be (dirty shutdown). Megáll a levelezés? Bizony meg. De a tárterület bővítése után simán visszaindul.

Az elv oké. Nem azzal volt a baj. Hanem azzal, hogy a 2007-es RTM-ben – mely közel egy évig volt kint a piacon – ezt a kritikus értéket 4 GB-re tették. Azaz ha egy 10 GB-s partíciódból elfogyott 6, leállt a levelezés, a közepesen tájékozott admin pedig szaladgálhatott, mint pók a falon.
Nem csoda, ha ez a feature az első számú közellenség lett az Exchange rendszergazdák körében. Elméletileg, ha nem is egyszerűen, de lehet hangolgatni, ki is lehet kapcsolni – de ehhez ismerni kell az elvet. Itt követte el a második nagy hibát az MS. Én biztosisten, 40 pontos betűkkel írtam volna ki minden Exchange cikk fejlécébe, hogy vigyázz barátom, errefelé tombol a back-pressure.

Aztán az SP1-ben már finomítottak a gyakorlaton, a leállás már csak 500 MB alatt következik be, ami, valljuk be őszintén, teljesen rendben is van. Ellenben a tájékoztatás… az még mindig tré.

Ezen próbálok most javítani, egy extrém szopási lehetőség bemutatásával.

Ugyan írtam már róla, de talán annyira nem volt hangsúlyos a felvetés. Tudni kell, hogy az Exchange 2007 alatt már a queue is adatbázis! Azaz minden olyasmi elv is vonatkozik rá, mint ami a többi adatbázisra. Spec a back-pressure is!

Gondold el. Kis cég vagytok, nem akarsz túl nagy feneket keríteni a dolognak, az Exchange-t simán feltelepíted a C: meghajtóra. Az adatbázisok természetesen külön diszken vannak, szabad tárhely, mint a pelyva. Hol is van ilyenkor a queue? Hát a C:\Program files\exchrsrv alatt valahol.
Az élet vidáman megy tovább. A pagefile nő, nődögél, a patchek is zabálják a helyet a C:-n, meg ott van az az istentudja mennyi rejtélyes folyamat, melyek mind fogyasztják a rendszerpartíciót. De amíg megy a rendszer, a fene sem veszi észre. Aztán egyszer csak megáll a levelezés.
Az adatbázisoknál bőven van hely. Oké, a C:-n annyira nem, de kit érdekel most a C:?
Hát például a művelt Exchange admint.

When the back pressure limits for hard disk drive space utilization are set to their default levels, the hard disk drive that stores the message queue database on an Edge Transport server or Hub Transport server must always have a fixed amount of free hard disk drive space. In Exchange 2007 RTM, the amount of required free hard disk drive space is 4 GB. In Exchange 2007 SP1, the amount of required free hard disk drive space is 500 MB. If the available free space is less than the required amount of free hard disk drive space, the hard disk drive utilization level is considered high. Therefore, all message flow stops. In that case, you must follow one of these steps:
– Relocate the message queue database to a different hard disk drive that has more free space. For more information, see How to Change the Location of the Queue Database.
– Increase the values of the PercentageDatabaseDiskSpaceUsedHighThreshold, PercentageDatabaseDiskSpaceUsedMediumThreshold, orPercentageDatabaseDiskSpaceUsedNormalThreshold parameters.
http://technet.microsoft.com/en-us/library/bb201658(EXCHG.80).aspx

Durva pofon, nem?

Persze elkerülhető lett volna, ha:

  • Az Exchange alkalmazást nem a C:-re telepíted, hanem egy külön alkalmazáspartícióra, mondjuk D:-re – és ezt a partíciót nem is használod semmi másra. Ekkor a szabad hely csak egy extra nagy levéltömeg bezúdulásakor lenne képes elfogyni.
  • Használsz valamilyen monitorozást. Ne mondd azt, hogy a SCOM baromi drága. Akkor tegyél fel linuxon egy nagios-t, abszolút ingyen van és – többek között – a szabad tárterületet is tudja monitorozni.
  • Legfőképpen pedig ismerd meg az eszközt, amit használsz. Tudod, a törvény nem ismerete nem ment fel a következmények alól.

Tapétamániákusok, figyelem!

2009-11-19 / / 2 Comments

A TechEd-en egy előadáson tette ki az elóadó – Charlie Chung – ezt az ábrát egy ppt slide-ra. Én úriemberként csak diszkréten csikorgattam a fogamat: normális vagy, barátom? Egy ilyen bonyolult ábrát kivetíteni? Hát emellett akár fel is olvashatnád visszafelé az Alice Csodaországban-t (úgy sem lenne több értelme), akkor sem figyelne senki arra, miről is beszélsz. Egy ilyen bonyolult, ellenben roppant fontos ábra láttán mindenki igyekszik pillanatok alatt minél többet felszívni belőle. Dehogyis jut ilyenkor agysejt az előadó szövegének dekódolására.

Tiszta szerencse, hogy a Microsoft elérhetővé tette mindkettő diagramot a neten. Tehát mindenki, akit érint, mindenki, aki éppen nem tud milyen háttérteret a Windows képernyőjére, innen le tudja tölteni az Exchange 2010 Transport Server szerkezeti diagramjait.

IMCEA

2009-03-12 / / 5 Comments

Még a szék sem tudott megmelegedni alattam, amikor rögtön átpasszoltak nekem egy hibajegyet. Első ránézésre semmi különös, valaki nem kap meg minden levelet. Ilyesmi elő szokott fordulni, egyszerű nyomozás.

Viszonylag hamar kiderült, hogy nem. Kértem egy NDR-t, ahol is elég furcsa cím szerepelt:

IMCEAEX-_O=CEGNEVORG_OU=BUDAPEST_cn=Recipients_cn=UserAlias@cegnev.hu
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

Hát, nem csoda, hogy ilyen címet nem talált. Életemben nem láttam még hasonlót. Egyáltalán, mi a lópikula ez az IMCEAEX- címtipus?

Szerencsémre Jason Nelson meghallotta a segélykiáltásomat és azon nyomban írt is róla egy cikket. Indulásnak remek.

Tehát cím kapszulázás. Minden emailcím, amely úgy kezdődik, hogy IMCEA, az valami olyasmi, hogy értelmetlen, vagy nem létező smtp cím helyett gyárt egy létező smtp címet, de olyan szintaktikával, hogy az egyrészt értelmes smtp cím legyen, másrészt vissza lehessen belőle fejteni az eredeti, nem smtp címet.
Példaként Jason a korai, Exchange 4.0 időket említette, amikor simán előfordulhatott olyan eset, hogy a rendszerbe csak utólag került bele az Internet Mail Connector (IMC), azaz az SMTP protokoll. Az alapértelmezett levelezési cím X.400 volt, ergo egyáltalán nem volt biztos, hogy aki kifelé akart levelet küldeni, annak volt smtp címe is. Ilyenkor lépett színre Miranda, a Proxy – aki legyártott az eredeti címből egy smtp címet. Az IMCEA előtag tuti volt, utána jött a kiindulási cím tipusa, majd a kiindulási címből generált többi tag.
Nézzük meg ilyen szemmel az ismeretlen címet. IMCEAEX: EX tipusú cím. Hogy ez mi? Majd később meglátjuk. A többi viszont gyanúsan X.400 jellegű, de ha jobban megnézzük, mégsem az. De valahonnan nagyon ismerős. Gondolkozósarok, gondolj, gondolj…  aztán beugrott: legacyExchangeDN!  Megnéztem a konkrét felhasználónál és ezt találtam: /o=CEGNEVORG/ou=BUDAPEST/cn=Recipients/cn=UserAlias. Megérkeztünk.

Innentől kezdve kettéágazik a nyomozás:

  • Miért nem találja meg legacyExchangeDN alapján a létező postafiókot?
  • Miért próbálkozik egyáltalán ezzel a bonyolult módszerrel, amikor a felhasználónak van rendes smtp címe is?

Elkezdtem kisérletezgetni. A sok hasonlóság mellett azért van különbség is, például a keresett cím végén ott fityeg egy @cegnev.hu is. Nyilván a legacyExchangeDN értéket nem lehet módosítani – hiszen akkor elvesztené a felhasználó a postafiókját. De ha úgysem találja meg, akkor lehet azzal próbálkozni, hogy felveszünk neki egy X.500(!) címet. (Azért X.500, mert a legacyExchangeDN érték tulajdonképpen egy X.500 cím.) Mit is írnak itt?

The Lightweight Directory Access Protocol (LDAP) filter that is used for address resolution is described as follows:
* For the EX e-mail address type, the LDAP filter is based on the recipient legacyExchangeDN Active Directory attribute or the recipient proxyAddresses Active Directory attribute. The legacyExchangeDN Active Directory attribute takes precedence.
* For all other e-mail addresses types, the recipient proxyAddresses Active Directory attribute is used as the LDAP filter.

Azaz a címfeloldásnál a legacyExchangeDN csak precedenciát élvez. De ha nincs, akkor jó lehet az X.500 cím is.

Oké, miket érdemes módosítgatni. Arra viszonylag hamar rájöttem, hogy a konverzió során a ‘/’ jelből ‘_’ lesz, tehát ezek egyenértékűek. De ezt a kukaccégnévhu-t érdemes lenne kipróbálni.
Sajnos nem segített, aztán persze jobban elolvasva rájöttem, mennyire gyökér voltam.

The algorithm works like so (for the click challenged).  Alpha numerics:  Ok.  Slashes get converted to _.  Everything else gets “Plus” encoded.  That means there’s a + and the two digit hex value of the character. Finally the Exchange server’s primary domain is appended (so that hopefully replies get back to it).

Ergo ez a kapálózás nem vezetett sehova. A felhasználó legacyExchangeDN értéke teljesen rendben van.

Nézzük a második szálat, ránézésre úgyis ezen a nyomon lehet megfogni az egész jelenséget. Miért próbálkozik bekapszulázott címmel a normális smtp cím helyett?
Erről is van egy nagyon jó írás, itt.
Azt írja, hogy ha auto-complete módon írunk be címet, akkor az Outlook a cache-ből X.500-as címet varázsol elő. Ha a cache-ben rossz cím ragadt be, akkor tényleg nem lesz meg a címzett. Megoldás: törölni a cache-t, azaz a feladó profiljában az .n2k fájlt. (Illetve megemlíti megoldásként az általam is elkövetett X.500-as címmel való bűvészkedést.)
Ezzel csak két probléma volt:

  • Az ügyfélnél még mindig Outlook2000 a standard, az pedig nem használ auto-complete cache-t. Nincs .n2k fájl.
  • Amikor nekiálltam tesztelni, az ötödik küldésnél én is megkaptam a hibaüzenetet. Pedig addig az alkalomig soha nem küldtem még levelet a felhasználónak.

Kezdett frusztráló lenni az eset. Egyre jobban viszketett az eszkaláló izmom, de jelen esetben a továbbpattintás szóba sem jöhetett, mivel az Outlook 2000 már nem támogatott az MS részéről.
Vegyük sorra. A levelek nagy részét megkapja a felhasználó, tehát alapvetően megvan mindene: van smtp címe, van X.500 címe (legacyExchangeDN). Ő is tud levelezni mindenkivel. Előfordul viszont, amikor se smtp címe nincs – ezért jön feladó oldalról az IMCEAEX címkapszulázás – de ilyenkor legacyExchangeDN értéke sincs, mert a kikapszulázott címre sem kapja meg. Búvópatak? Láthatatlanná tévő köpönyeg? Miaf?
Persze ebben a korban már nem hiszünk a mesében: több tartományvezérlős környezetben simán előfordulhat, hogy egy tartományvezérlő megmakkan, aztán ha tőle kérdeznek, akkor hülye válasz jön, ha mástól, akkor meg jó. Ilyen például akkor lehet, ha az egyik DC-re nem működik a replikáció. Nosza, replmon, kérem az összes replikációs hibajelentést. Semmi. Üres halmaz. Ez ugye egyfelől jó hír, másfelől pedig meglehetősen frusztráló. Akkor most az van, hogy minden DC tökre ugyanazt az objektumot tartalmazza. De biztos, hogy DC-t kérdez a kliens? Illetve biztos, hogy az AD ldap adatbázisát? Hiszen ott van a globális katalógus, azaz jelen esetben a GAL. Meg ott van a pillanatkép a globális katalógusról, az OAB.  Valamelyik gépen sérült lenne a GC adatbázis? Ezt végülis le lehet ellenőrizni, ldp-vel rá lehet kapcsolódni, csak arra kell vigyázni, hogy ne a 389-es portot adjuk meg, hanem a 3268-ast.
De itt sincs semmi rendellenesség.

Jó, akkor elkezdtem vadul tesztelni. Outlook 2000/2003/2007. Egy idő után mindenhol megjelent a hiba. Ergo már biztosan nem kliens oldali problémáról van szó.

Nézzük, mit kapok OWÁ-ból.

Szöget. Kibújni a zsákból.

Amikor ki akartam választani a címzettet a GAL-ból, hibaüzenetet kaptam. Azt mondta, hogy az objektum vagy nem létezik, vagy korrupt lett vagy nincs hozzá jogosultságom elérni. Miután kipróbáltam néhányszor és volt, amikor láttam, volt amikor nem – így az az egy lehetőség maradt, hogy a felhasználó korrupt lett.
Kivégezni.

Kollégák lementették a postafiókját, feljegyezték a beállításait… majd törölték a felhasználót postafiókostól, később pedig újra létrehozták. (Választhattuk volna az autoritatív restore-t is, de valahogy inkább nem.) Azóta nincs hibaüzenet.

Case solved.

Mondjuk, a lelkem békéje nem állt teljesen helyre. Soha nem fogjuk megtudni, mi is volt a jelenség mögött. Akármi is volt, a törléssel eltávozott a rendszerből.
Manapság pedig az SLA fontosabb, mint a rejtélyek teljes felgöngyölítése.

Formás levél

2009-02-11 / / 3 Comments

Érdekes jelenségre hívta fel a figyelmemet az ügyfél egyik fejlesztője. Ha az Exchange 2007 OWÁ-ból küld html levelet, akkor a túloldalon már csak plain text-ként látszik. Miközben ha megnézzük a Sent Items folderben, ott bizony html.
Ez vajon mi lehet?

Ellenteszt. Mi van, ha Outlookból küldök html levelet? Úgy is érkezik meg.

Gyors teszt más cégek OWA rendszereiben – mindenhol ugyanez a jelenség.

Ez érdekes. Hiszen elméletileg nem szabadna, hogy különbség legyen a levélben, függetlenül attól, hogy OWÁ-ban vagy Outlookban állították elő. A formátumot saccra a Remote Domain objektumon lehet még utánállítani – és az egyformán kell vonatkozzon minden abba az irányba küldött levélre. De van egyáltalán ilyen állítási lehetőség a Remote Domain objektumokon? Bizony nincs. Legalábbis konzolból nincs.
Persze shellből van. Nézzük csak meg a get-remotedomain | fl parancs kimenetlét. Ott van, elbújva a többi tulajdonság közé a ContentType tulajdonság. Melynek értékei a következők lehetnek:

  • MimeHtmlText: Ha az eredeti levél text volt, akkor text MIME formátumba konvertál. Minden egyéb esetben html MIME formátumba.
  • MimeText: Text MIME formátumba konvertál.
  • MimeHtml: Html MIME formátumba konvertál.

Az alapértelmezés – a set-remotedomain parancs szerint – a MimeHtmlText beállítás. Ez jól is hangzik.

Csakhogy. Az én konkrét esetemben az volt, hogy MimeText.

Rögtön kérdések merültek fel:

  • Ha alapértelmezésben telepítettem, akkor miért nem az alapérték van beállítva?
  • Ha csak text MIME formátumban megy ki a levél, akkor hogyan mehetett ki Outlookból mégis html formátumban?

Jó magyar infomunkásként először azért beállítottam a MimeHtmlText értékét, leteszteltem – és tényleg ez volt a megoldás. Ment OWA alól a html levelezés.

Most már lehetett tipródni, mit is csináltunk. Mitől javult meg a rendszer?

Az első kérdésre viszonylag hamar meglett a válasz. Szűz rendszernél tényleg a MimeHtmlText az alapértelmezés. De ha 2003-ból migrálunk, akkor attól függően, hogy mi volt beállítva a kimenő levelek (Internet Message Formats) MIME kódolására, attól függően már más. Ha ott az volt, hogy ‘Provide message body as plain text’, akkor a migráció során a MimeText jön át. Azaz valószínűleg az összes helyen, ahol teszteltem, ez volt a beállítás a migráció előtt.

A második kérdésre a válasz már fogósabb egy kicsit. Logikusan gondolkodva, ha van egy organizáció szintű beállítás, de bizonyos levelekre vonatkozik, bizonyos levelekre meg nem, akkor léteznie kell legalább egy magasabb prioritású beállításnak, mely felülbírálja azt. Ezzel a témával kapcsolatban ezt a cikket találtam. Olvasgattam, olvasgattam… de nem akart összeállni a kép.

Mit is írnak a cikk vége felé?

Order of Precedence for Message Encoding Options
Exchange 2007 uses the order of precedence as described in the following list to determine the message encoding options for outgoing messages that are sent to recipients outside the Exchange organization:

  • Remote domain settings
  • Outlook settings
  • Mail user or mail contact settings

The list specifies the order of precedence from lowest to highest. A setting made at a higher level may override a setting made at a lower level.

Az utolsó pont szorulhat némi magyarázatra: az Outlook 2007-ben lehetőségünk van nekünk, személy szerint is bejelölgetni a kontaktokat (akár a sajátjainkat, akár a közöseket), hogy milyen formátumban szeretnénk nekik levelet küldeni.
Mondanom sem kell, ritka hülyén van megfogalmazva a szöveg. Hogyan értelmezzük a sorrendet? A higher level azt jelenti, hogy a legalsó a leggyengébb, a legfelső meg a legerősebb? De hát nem ez történt. Amikor beállítottam Outlook szinten, hogy html-ben akarok levelezni, akkor az úgy is ment ki, függetlenül attól, hogy remote domain szinten MimeText volt beállítva.
Megint a logikára kell hagyatkoznom. Ha ugyanis a felsorolás sorrendjét tekintem prioritási sorrendnek is, azaz fentről haladnék lefelé, akkor az a következőket jelentené:

  • Akárhogy is jelölném be a konkrét levél tipusát, ha a címzettre más típus van beállítva, akkor az utóbbi felülírja az elsőt.
  • Hiába van beállítva organizáció szinten a tartalomtípus, ha én a konkrét levelemben más adtam meg, akkor az lesz az erősebb. A levél úgy megy ki.

Ez már annyiból tetszetősebb, hogy ez lehetőséget ad megmagyarázni a jelenséget. Valamiért ha OWÁ-ból küldök html levelet, azt a remote domain nem úgy érzékeli, mintha Outlook-ból állítottam volna be, magasabb precedenciával. Tehát sima szövegként csomagolja MIMÉ-be. Ellenben amikor a remote domain objektumon azt állítom be, hogy vizsgálja meg a levelet, majd aszerint döntsön, akkor már felismeri, hogy ez eredetileg html levél volt – és így csomagolja MIMÉ-be.

Nagyon fontos. Amit a második kérdéssel kapcsolatban írtam, színtiszta spekuláció. Számomra így tűnik logikusnak. Ettől függetlenül abszolút máshogy is lehet.
Az életedet ne tedd fel rá.

Belehalni egy sajtóhibába

2009-01-22 / / 0 Comments

A projekt, mint egy elszabadult úthenger, száguldott tovább. Tegnap jutottunk el addig a lépésig, hogy növeljük a levéltovábbítás rendelkezésreállását, meg elosszuk a terhelést. Azaz berakjunk egy második HUB Transport szervert a meglévő mellé.
Hogy érthetőbb legyen az írás, összedobtam egy skiccet.

Nagyítás

Azaz van jobb oldalon egy CCR MBX szerver, előtte a HTS szerverek. A piros vastag vonal jelöli az Exchange 2007 – Exchange 2003 közötti routing group konnektort. Baloldalt pedig egy smarhost tartja a kapcsolatot a nettel. (A levegőben lógó vonalak egyéb, belső levelezési irányok.)
Kékkel jelöltem az újonnan berakott HTS szervert. HTS1 és HTS2 teljesen megegyező virtuális gépek.

Hogyan lesz ebből érdekes cikk? Hiszen a felállás egyszerű, mint a faék. Működnie kell, oszt jól van.

Csakhogy nem működött.

Abban a pillanatban, ahogy beraktam HTS2-t, bedőlt a kifelé menő levelezés – legalábbis a levelek jó része nem ment ki. A HTS2-n lévő várakozási sorokban pedig elkezdtek gyűlni a levelek. Egész pontosan így hívták az érintett queue-kat:

  • HTS1-xch2003
  • HTS1

A queue viewer azt mondta, hogy a legutolsó hibaüzenet ez volt:

451 4.4.0 Primary Target IP Address responded with :” 451 5.7.3 Cannot achieve exchange server authentication.” Attempted failover to alternate host but that did not succeed.Either there are no alternate hosts or delivery failed to all alternate hosts.”

Target IP. Valószínűleg a fejlesztőknek leesett volna a karikagyűrű az ujjukról, ha ki is írták volna, hogy jelen esetben ki is volt az a target, aki visszaröffent? HTS1? Xch2003? A smarthost?
Na, mindegy. Kezdjük el összerakni a kirakós játékot. A Google szerint ilyen probléma akkor van, ha Exchange 2007 szervert kötünk össze Exchange 2003 szerverrel (eddig jó) és a 2003-ason nincs engedélyezve az integrated autentikáció. Megnéztem, engedélyezve volt. Innentől a Google felejtős, más találat nem volt. Kénytelen voltam az eszemet használni.
A queue-k csak a HTS2-n látszottak. Viszont az első queue neve gyanúsan ugyanaz volt, mint az RGC-é. Lehetséges, hogy nem is az xch2003-2007 határon van a probléma? Mit is tanultunk az Exchange 2007 routolásról? Például azt, hogy queue at point of failure – azaz szállítási hiba esetén a levelek azon a szerveren várakoznak, amelyik legközelebb van a szakadáshoz.
Azaz nem az xch2003 és a HTS1 között van a hiba, hanem már a HTS1 előtt.

Nadehát… mi lehet itt? A közvetlenül egymás mellé bedugott két Exchange 2007 HTS szerver nem tud kommunikálni egymással?

Mindenesetre gyorsan lekötöztem az RSG lábát a HTS2-höz is (ez már nincs a rajzon), így a levelek nagy része huss, kirepült. De ettől a probléma nem oldódott meg. Hiszen még élt a HTS1 queue, és álltak ebben is levelek.

Jogos a kérdés, hogy ezek vajon milyen levelek lehettek? Milyen levelek azok, melyek a fenti rendszerben a CCR-en keletkeztek, a HTS2 átvette továbbításra, majd továbbküldte a HTS1-nek… hogy az továbbítsa vissza cuccot a CCR-nek. Elég bizarr kör, nemde?
Mit tanultunk még az Exchange 2007 routolásáról? Delayed fan out – azaz ha egy levélnek több címzettje van, akkor addig a pontig, amíg a levelek együtt mennek, lejátszódik egy direct relay, majd onnan megy minden csomag a maga útjára, további direct relay-vel. Azaz a vizsgált várakozási sorban azok a levelek álltak, melyeket olyan levelezési csoportoknak küldtek, amelyiknek volt tagja a CCR-en, de volt tagja vagy a külvilágban, vagy az xch2003 rendszerben… vagy bármelyik más célpontban. Ekkor lett volna egy direct relay a HTS1-re, majd onnan a CCR-en lévő postafiókoknak ment volna vissza is a levél.

De nem ment. Illetve…
Nyilván, telnet. Nyilván ‘ismeretlen parancs’ választ kaptam. Hogy mekkora biztonsági fenyegetést jelent Windows 2008 szerveren a default telepített telnet kliens… nem tudom. De én már sokadszor futok bele abba, hogy nincs… és már majdnem annyira frusztrál, mint az UAC.
Na, mindegy. Telepítve. Aztán boldogan telnetelgettem. És sikeresen. HTS2-n belépve, HTS1-re telnetelve, minden irányban elmentek a levelek. Csak a queue-ból nem ürültek.
Itt már kezdtem ingerült lenni.

Nézzünk már egy smtp logot. Hol is van? Az Exchange könyvtárban lévő smtpout könyvtár üres. Jó, akkor kapcsoljuk be az smtp logolást. Hol is kell?
Azt írják, hogy a logolást a send konnektoron kell beállítani.

Kérdés: hol van itt send konnektor? Egyáltalán, ki csinált itt send konnectort? Mert én biztosan nem.
Nem is kellett. Ugyanis amikor beteszünk egy AD site-ra egy második HTS szervert, automatikusan létrejön egy send konnektor a kettő között.
Megint tanulunk. Milyen send konnektorok is léteznek?

  • Explicit: Határozott ráutaló magatartással mi gyártjuk le, vagy a konzolból, vagy a shellből a new-sendconnector paranccsal. Jellegzetessége, hogy látszik: azaz mindkét menedzsment felületről nézegethetjük, konfigurálhatjuk.
  • Semi-explicit: Ugyan automatikusan keletkeznek, de a konnektorok látszódnak, konfigurálhatók. Tipikusan ilyenek az Edge szerver beállításakor az Edge-HTS send konnektorok.
  • Implicit: Automatikusan keletkeznek, nem látszanak, nem hozzáférhetők. Ha nem olvasgatnánk minden szabad percünkben Exchange szakkönyveket, nem is tudnánk róla, hogy léteznek.

Nyilván itt a legutolsóról van szó. Érezzük a bukfencet? Hogyan állítsunk be logolást egy olyan konnektorra, amelyhez semmi hozzáférésünk sincs? Marha egyszerű. Mint a viccben: rostáljuk át a sivatagot és ami fentmarad a rácson, az az oroszlán. Az alábbi írás szerint a következő parancsot kell kiadnunk, ha intra-organization send konnektort akarunk logoltatni:

Set-TransportServer “HTS2” -IntraOrgProtocolLoggingLevel Verbose

Ha kiadjuk… ugyanazt a kövér syntax errort kapjuk, mint amilyent én kaptam. A KB cikk ugyanis hibás. Kérjük le a get-help set-transportserver -full paranccsal a paraméterek listáját – és láthatjuk, hogy a helyes paraméter az -IntraOrgConnectorProtocolLoggingLevel. Ja, és ne lepődjünk meg, ha kigördül a képernyőről a szöveg. Nálam az EMS puffere 999 sor (több nem lehet), ebbe a paraméterlistának kábé a fele fért bele.

Viszont azt gondolom nem kell magyarázni, mi is történik. Azt mondtuk, hogy te, kedves HUB Transport szerver, logoljad lécci az összes send konnektorodat. És az összesben már benne van a szupertitkos is.
Transport szerver újraindít, ekkor ugye kénytelen megabajgatni a beragadt várakozási sort. Végre van log is. De milyen furcsa! HTS2 beehlózik HTS1-hez. HTS1 elsorolja, milyen kunsztokat tud. Majd páros lábbal kirúgja HTS2-t.

?

Gondolom, már hiányérzeted van. Miért nem ír ez a fazon a receive konnektorokról? Ordít, hogy ott lesz a hiba.
Először én is így gondoltam. Átnéztem többször is, az összeset.
– Milyen összeset? – kérdezhetnéd.
– Hát, a gyárit, meg a barkácsoltat – válaszolnám.

Miért is kell barkácsolni? Close Relay. Az ember a default (server) receive konnektoron állítja be, hogy a szóbajöhető IP tartományból mindenki bejöhessen, mindenféle autentikációt használhasson – eltekintve az anonymous hozzáféréstől. Emellett célszerű gyártani egy relay receive konnektort is, melyet úgy állítunk be, hogy ne kérjen autentikációt és engedélyezze az anonymous hozzáférést. De itt, a network fülön csak – és szigorúan csak – azokat a hostokat engedjük, melyek számára engedélyezzük a relay-t… és amelyek annyira rendszeridegenek, hogy kizárt velük minden együttműködés. (Tudom, ne mondjuk soha azt, hogy kizárt… mondjuk helyette azt, hogy egyik oldal sem akar annyi energiát beleölni a mutatványba, hogy összehozzunk egy tisztességes autentikációt. Inkább megbízunk egymásban.)

Nos, receive konnektorok többször is átnézve, ránézésre minden rendben. Pedig az eddigi nyomozásból 110 százalékra tudjuk, hogy kizárólag csak itt lehet a hiba.
Kiváncsiságból kikapcsoltam a relay konnektort. Abban a pillanatban kirepült az összes levél a queue-ból.

Oké. Akkor eddig megvolnánk. Idő? Még ma van. Igaz, éppenhogy csak. Mindenesetre a szemem már annyira kifolyt a helyéről, hogy amikor telefonálgatnom kellett, folyamatosan zárva tartottam. Addig is pihent.

Gyors mérleg: queue üres. Megvan a bűnös. Én viszont már használhatatlan vagyok. HTS2 lekapcsol, relay receive konnektor visszakapcsol. Ezzel el tud zakatolni az ügyfél… aztán holnap is nap lesz.
Hátha megálmodom, mi lehet a baj.

Nem hiszed el, megálmodtam.

Reggel felkeltem… és fogmosás közben lepörögtek előttem a konnektorokban lévő network listák. Bakker, a HTS2 mindkét receive konnektor szkópjában szerepel! Márpedig a relay konnektor a szigorúbb, tehát az lesz rá érvényes… ekkor viszont nem lesz engedélyezve számára az Exchange autentikáció!

Napközben volt éppen elég más dolgom is, az összeszedettség szobrát sem rólam mintázták volna, de délutánra összevakartam magam. (Két redbull, meg egy vizespohár kávé.) Háromkor bejelentettem, hogy éles teszt. A kollégáimnak elszürkült az arcuk. Szerettek volna otthon éjszakázni.
Lecsökkentettem azt az IP tartományt a relay receive konnektoron, mely magába foglalta a HTS2-t is. Majd bekapcsoltuk a HTS2-t. Queue viewer… és gyönyörűen üres.
– Na látjátok, nem kell beszarni – nyugtatgattam a többieket – megy ez.
Már majdnem pezsgőt bontottunk, amikor megjelent az első kézbesítetlen levél a HTS1 queue-ban.
– Miaf? – néztem bambán. Hiszen annyira biztos voltam az elméletemben.
– Figyelj, még egy olyan délutánt nem engedhetünk meg magunknak, mint tegnap – figyelmeztettek.
– Oké, tíz levélig elmegyünk. Ha addig nem tudom megoldani, akkor letiltjuk a relay konnektort és leállítjuk a HTS2-t.

Körülbelül hat levélnél jártunk, amikorra kiszúrtam, hogy a relay receive konnektor network listájában direktben is fel volt véve a HTS2 IP címe. Nyilván a tegnap esti eszetlen rodeó egyik fázisában tehettem egy bátortalan kisérletet. Gyorsan töröltem, pár perc várakozás – és a queue kiürült.
Győzelem. Ugyan vártunk még egy félórát, mielőtt megfújtuk volna a harsonákat – de én már rögtön biztos voltam a győzelemben: hiszen kiürült a feltorlódott queue. Ez már nem fog még egyszer feltorlódni.

Hátravolt még a nyomozás: hogyan történhetett meg egy ilyen félrekonfigurálás?

Ezt is megtaláltam. Nem voltam boldog. Én gépeltem el… méghozzá az implementációs tervben. Egy A4-es oldal méretű táblázatban voltak felsorolva azok az IP címek, akiknek engedélyezve volt a relay. (Az értékeket az Exchange 2003 rendszerből kellett átvinni a 2007-be.)
A táblázat valahogy így nézett ki (az értékek nem valósak):

  1. 192.168.100.0/24
  2. 192.168.101.0/24
  3. 192.168.102.0/24
  4. Meg vagy hatvan szóló IP cím

A harmadik helyen a jó érték az lett volna, hogy 192.168.102.0/25… azaz csak a tartomány alsó felének volt engedélyezve a relay. A HTS2 pedig ugyanezen tartomány felső felében volt.
És amennyire precíz vagyok, az implementáció során pontosan ezt a táblázatot pötyögtem be – így került bele mindkét konnektor szkópjába a HTS2.

Shame on me.

Tudom, a következőket fel lehet fogni egyfajta racionalizálásnak is… de ez nem fog visszatartani attól, hogy elmélkedjek egy kicsit az eseten.

Jó-e egy ilyen hiba a projektben? Dühöngjünk-e miatta? Vagy – és most nagyon meredeket mondok – örüljünk-e egy ilyen hibának?

Én az utóbbira szavazok. És nem csak azért, mert pontosan ezt állítja a talán legkedvesebb könyvemben – A zen és a motorkerékpár ápolásának művészete – Robert Pirsig is… hanem azért, mert én magam is ebben hiszek. Ha belefutsz egy hibába, és ellövöd rá az összes töltényedet, de a hiba makacsul megmarad… akkor ujjonganod kell. Mert a hiba rá fog kényszeríteni arra, hogy átlépd a határaidat… hogy olyan fegyvereket, olyan harcmodort találj ki, melyeket korábban nem ismertél. Az ilyen hiba tágítja a gondolkodásod horizontját.
Most például a valóságban is találkoztunk olyan – korábban csak elméletből ismert – jelenségekkel, mint a ‘queue at point of failure’ vagy a ‘delayed fan out’… megtanultuk, hogyan lehet send és receive konnektorokat logolni… és egyáltalán, elmélyedtünk a levéltovábbítás módjában, beleégettük a gondolkodásunkba a folyamat felépítését.
Innentől jobban fogjuk érteni, mi is történik a mélyben.

Konnektória

2008-02-27 / / 0 Comments

Ez az írás már hetek óta itt aszalódik a piszkozatok között, de valahogy úgy éreztem, hogy ábra nélkül nem igazán lenne élvezhető. (Nem mintha azzal valami nagy mámor lenne.)
Mostanra készült el.

Nagyítás

Értő szemű olvasók gondolom kapásból kiszúrják a hibát: igen, egy budapesti Exchange2000 szerver és egy vidéki Exchange 2000 szerver ugyanabban a routing groupban van, dacára annak, hogy egy igen vékonyka WAN vonal feszül a két telephely között.
Hát, igen. Exchange 2000 alatt még lehetett ilyesmit csinálni. Az Exchange 2007 alatt már nem annyira, az ugyanis routing group-ok helyett az AD telephelyeket használja.
Ezzel el is érkeztünk a rajzon található kaotikus állapothoz.

Igen, kénytelen voltam extra konnektorokat beledöfni az organizációba – ha el akartam kerülni azt, hogy vidék a vidékkel Budapesten keresztül levelezzen. A postafiók migrációról már nem is beszélve.

Össze is raktam. Át is migráltam 3 szerencsétlent a BP2-XCH2000 szerverről a BP2-XCH2007 szerverre. Meg is halt a levelezésük, legalábbis bizonyos irányokba.

Mi történhetett?
A Winroute látott valami konnektorszerűséget, méghozzá működőnek látta. Csak éppen unknown objektumként. De azért arra küldte a leveleket – csakhogy azok nem jutottak el odáig. (Megragadom az alkalmat, hogy itt is rúgjak egyet a Message Tracking Centerbe. Sokkal rosszabb lett, mint az Exchange 2003-ban volt.)
A levelek ott álltak a queue-ban. Dühömben levertem minden extra konnektort – a levelezés hamarosan be is indult, igaz bejárta a fél világot a levél, mire kitalált.
Menetközben jött az újabb sokk: a tesztuserek emailcíme evolválódott. kovacs.bela@leany.hu -> bela@leany.hu

Slatty. Ez az a hang volt, amikor a fejemre csaptam. Hát, persze. Email address policy – mint korábban is írtam, adatbázis szintre. Csakhogy a userek átkerültek másik szerverre, másik adatbázisba, mely még nem szerepelt a házirendben. A default policy meg – most nem részletezendő okból – ilyen idétlenke.
Kivettem, hogy ne essen a userekre a policy, emailcím visszaír, eredmény vár.
Semmi.
Szokásos körök: RUS (bár itt már nem kellene), OAB generálás, OAB lekérés gyakorisága 1 perc, SCP? Mindegyik CAS-ra leellenőriztem. Jöhetett a szokásos keresztúton kecskeáldozás, közben állandóan nyomkodva az outlookban a download OAB gombot. Semmi.
Adsiedit, összes DC-ről megnézve a proxyaddress tulajdonságot. mindenhol jó. Ldp-vel belekukkoltam a GC adatbázisába, jó.
Hol a francba ragadt be az a hülye emailcím?
Aztán egyszer csak eltűnt a 3 tesztuser a GAL-ból. Újabb rángatózások, majd leesett, hogy most ért körbe a lebontott konnektor hatása. (Ekkor indult be a levelezés is.)
Új konnektorokat álmodtam magamnak. (Más színes tintákkal szokott.)
Semmi javulás.
Küldtem néhány tesztlevelet. Megkapta. A benne lévő cím jó. Reply. Elment. Majd visszajött, hogy nincs olyan címzett, hogy bela@. Miért??
Aztán valahonnan beugrott, hogy minden felhasználónak, még a postafiókkal nem rendelkezőknek is van olyan tulajdonságuk, hogy ‘mail’. Eddig úgy tudtam, hogy csak megjelenítésre szolgál. Azért ránéztem. Bakker, ott volt. Létezik ugyanis egy automatizmus, mely amikor policy változtatja meg a default emailcímet, akkor átírja ezt a tulajdonságot is. Ha én, manuálisan változtatom meg, akkor nem. És úgy látszik, mégis van szerepe.
Átírtam, megrángattam a szálakat, hamarosan meg is jelentek a jó címek a GAL-ban. Méghogy öreg kutya nem tanul új trükköket….
De az OAB letöltés továbbra sem ment. Google. Néhány óra szenvedés. Aztán összedobtam egy új profilt (az egyik tesztalanynak) a gépemen. Működött. Tehát az outlook profilban romlott el valami. Remek. Új profil, kismillió új beállítások, új ost. Mondjuk, ki nem szarja le. Működik.

Csak a nyolc terminálablak bezárása eltartott egy negyedóráig.
Hajnali fél kettő. Mehettem haza.

Mondjuk nem aludtam jól. Valami zavart. De még reggel is. Éreztem, hogy nem kerek a történet.

Másnap reggel folytattam a levélküldési teszteket. Volna. De nem működött sem a Free/Busy, sem az OAB elérésem. (Ja, nem mondtam: az egyik teszt postafiók az én tesztfelhasználóm volt.) Agyalások, gyötrések. Valamiért nem fordul a dög a CAS-hoz – legalábbis nem jön fel a selfsigned certre figyelmeztető ablak. Próbaprofil másik – tegnap szintén elkutyult – felhasználóval. Működik. Azaz az én mapi profilomba ragadt be valami szemét. Csináltam magamnak egy újabbat. Aztán a sokadik OAB letöltési kisérletnél egyszer csak megjelent a CERT ablak. Onnantól már a régi profilomból is ment. Idióta.

Most már tényleg levelezési tesztek. Gáz: nem tudtam vidékre levelet küldeni. Visszafelé ment. Nyomozás. Winroute: A konnektor megint ledőlt. Letöröltem a francba. Nem változott semmi. Ilyen nincs. Most már csak az IP site link ívelt át a telephelyre, a címtár replikáció működött, de az Exchange routolás nem. Set-adsitelink, költségek különválasztása, akkor sem.

Ekkor tettem meg azt, amit jóval korábban kellett volna: oda-vissza telnet 25. Lefelé nem ment, lent viszont egyik szerverről a másikra igen. Tűzfal!! – ordítottam fel. Jött is egy tűzfalas ember. Elkezdtem demonstrálni neki:
– Látod, nem megy a 25 port. De ha teszem azt, a 135-öst adom meg, akkor sem… – mondtam, miközben pörgött a kezem… és a 135-ös port átment.
– Igen? – nézett rám kérdőn az ember.
– Any/any van? – hebegtem.
– Persze – bólintott.
– Bocs.

Mi a retek lehet? Transport szolgáltatások futnak. – Receive connector! – csaptam a fejemre. Autentikációk rendben. Network… és akkorát csaptam a fejemre, hogy lefordultam a székről. Egy, azaz egy szám el volt írva a három IP range közül az egyikben a Default smtp receive konnektornál. Így onnan nem fogadott el kapcsolatot. Ez a range pont az egyik pesti LAN volt, két Exchange szerverrel. Ráadásul következetes voltam: a tervben – a jól kidolgozott tervben! – gépeltem el a számot, és utána már mindkét helyen ész nélkül írtam be a rossz értékeket az implementáció során.

Innentől már csak a törmelékeltakarítás volt hátra. Mindent visszaállítani az eredeti elképzelés szerintire. Az összes CAS disztributálja az OAB-ot. Ekkor viszont nem megy az, hogy cegnev user belép a leánynál és letölti az OAB-ot. Szomorú lettem. Végül az lett, hogy anonymous autentikáció az autodiscovery, ews (availability) és oab website-okon. Igen, hőbörgött… de legalább működött.

Persze az OWA továbbra sem ment a vidéki telephelyen – de minden más, mint a svájci óra.