Rákerestem.

Van.

Tegnap óta:

http://blogs.technet.com/b/exchange/archive/2011/12/05/released-exchange-server-2010-sp2.aspx

Letölthető innen:

http://www.microsoft.com/download/en/details.aspx?id=28190

Egyszer lett egy rövid kiesésem (egy-két perc). Erre fogta magát a DAG és szétesett. Nem ált helyre magátol, gyakorlatilag a Windows Cluster eszközeivel kellett szétszednem mert semmire sem reagált. Végülis újra össszeraktam és napirendre tértem a dolog felett.

Tegnapelőtt ráakadtam erre a cikkre. Végiggondolva az előző eset kísértetiesen hasonlított a cikkben leírtakra. Nosza rajta, szerezzük be a hotfixet, elvégre a fenti teszt DAG-om még létezik (azóta szerencsére nem volt vele újabb gond) valamint vár rám vagy három újabb DAG, csak azok már élesben.

Emlékeztem, hogy a Microsoftnak van egy webes formja ahol lehet hotfixet kérni. Meg is találtam itt.

Elküldtem az igénylést, erre ez a válasz jött tegnap:

Hello,

Thank you for contacting Microsoft Customer Service.

From the information you have provided in your message, I understand that you are located in Hungary. The Customer Service team you have reached is for North America. There are significant differences between North American versions of Microsoft products and those localized for your country.

You will be best assisted by the Microsoft subsidiary that specializes in your version of Microsoft products. You can reach them at +36 1 437 2800 or by visiting: http://www.microsoft.com/worldwide/phone/contact.aspx?country=Hungary

I hope the above information is useful. In case you require further assistance with regards to this issue, please feel free to contact us.

Thank you,

John

Microsoft Customer Service Representative

Na gratulálok. Hotfix nincs, ráadásul bődületes baromság, hogy különbség lenne a verziók között, ugyanis én a US English verzióhoz kértem fixet és nem a magyarhoz.

Azt találtam ki, hogy csinálok egy új e-mailt és bejelentkezem amerikaiként a formra. Meg is tettem. Amikor újra rákerestem a form címére (tegnap nem tettem el), megakadt a szemem az egyik találaton.

Egy próbát megér alapon össze is raktam az urlt: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2550886&kbln=en-us

Láss csodát, kaptam egy magyar nyelvű oldalt és 5 perc múlva a kezemben volt a hotfix, ahelyett hogy egy fél napot vártam volna az elutasításra.

Úgy döntöttünk, saját SAN tanúsítványt használunk, így első lépésben azt gyártjuk le. Certification snap-in, advanced, create a request. Itt kapjuk a következő ablakot.

From Segédlet

Először is pár szívélyes szóval megemlékeznék az UI tervezőjének felmenőági rokonairól. Hogy a szöszbe lehet olyan felületet tervezni, ahol nem látszik, mi kattintható választás és mi egyszerűen csak szöveg? Aki először jár erre, kénytelen az egérrel végigszkennelni az ablakot, figyelve, hol változik meg a kurzor.
Jó, nézzük a lehetőségeket. Aszongya, hogy… az Igazi Rendszergazda mindig a custom opciót választja, így akkor mehetünk is tovább.

From Segédlet

Mondjuk, nem fogunk dúskálni a lehetőségekben, az Igaz Rendszergazda egy kicsit meg is szeppen, mert egy kukkot sem ért a beállításokból, de aztán vállat von, biztosan jó lesz az alapértelmezés, és nyomja tovább bátran a varázslót. Elkészül a tanúsítvány, lecseréli az Exchange alatt, minden rendben, a napocska mosolyog, a madarak trilláznak. A belső hálóról működik az OWA, működik a MAPI, sehol nem jön fel tanúsítványhibára figyelmeztető ablak.

Kiexportáljuk a tanúsítványt, figyelve, hogy benne legyen a privát kulcs, felmásoljuk a TMG szerverre. Elkezdjük összerakni a web listenert. Elérkezünk oda, hogy kiválasszuk hozzá a tanúsítványt… de nincs. Azt mondja, hogy az a tanúsítvány, melybe az összes bizalmunkat helyeztük, az bizony inkorrekt. Hogy a manóba? Hiszen az Excange elfogadta, a kliensek elfogadták, az Active Directory elfogadta, a TMG tartományi tag, tehát a root CA tanúsítványa rajta van, a dátumok jók… akkor miért inkorrekt? Ezért.

Ott, amikor a custom sablont választottuk a tanúsítvány igénylésénél, ott csak V3-as (CNG) tanúsítványt igényelhettünk. Igenám, de ebből a tipusú tanúsítványból a TMG nem tudja kiolvasni a privát kulcsot, azaz úgy érzékeli, hogy nincs benne, azaz a tanúsítvány inkorrekt. Kuka.

Visszamegyünk ahhoz a bizonyos ablakhoz és most azt választjuk, hogy Active Directory Enrollment Policy.

From Segédlet

Itt már a jól ismert legördülő menü fogad, kiválasztjuk a V2-es Web Server sablont, és máris minden kiegyenesedik.

Rövid kitérő, ha valaki esetleg nemrég bújt volna még csak ki a tojáshéjból. Az Exchange-ben – eltekintve a régebbi verziók stm fájljaitól – egy adatbázis egy darab edb fájl. Ezen a fájlon belül vannak adattáblák, ahol az összetartozó adatok között pointerek teremtik meg a kapcsolatot. Amikor törlök egy levelet, akkor az egyik adattáblából törlődik a levél tartalma, és emellett törlődnek a rámutató pointerek is. Értelemszerűen hiába csökkennek az egyes adattáblák méretei, az edb fájl mérete nem csökken. A fájlon belül üres hely (whitespace) szabadul fel, de a sok, apró üres hellyel az Exchange nem tud mit kezdeni. Ekkor jön be a képbe az Online Maintenance folyamaton belül az Online Defragmentation, azaz online tömörítés: ez az edb fájlon belül az üres helyeket kimozgatja a fájl végére, így újra hasznosíthatók lesznek. Az online tömörítés, mint a neve is mutatja, online, azaz működés közben is végezhető. Csak éppen erőforrásigényes, emellett Exchange 2010 előtt szégyenlős is, ha túl nagy aktivitást észlel az adatbázison, akkor megáll. Márpedig az online tömörítés hiányában vészesen dagadni kezd az adatbázis. Sőt, ha valaki végiggondolja a folyamatot, akkor láthatja, hogy az online tömörítés mellett is dagadhat az adatbázis. Például kapunk egy tüskeszerű nagy terhelést. Egy nap alatt felhízik az adatbázis (betör egy spam), a felhasználók ugyan törlik a leveleket, de az online tömörítés csak az üres helyekkel tud játszani, az edb fájl méretével már nem. Ahhoz, hogy az utóbbi is csökkenjen, már más módszerekhez kell nyúlni.

Így jutottunk el az offline tömörítéshez. Ekkor lecsatoljuk az adatbázist és az edb fájlt átadjuk egy erre a célra kifejlesztett adatbázismatyizó programnak (eseutil). Ez nyit egy új, ideiglenes adatbázist, elkezdi átmásolni az értelmes tartalmat (nem, a levelekben már nem kutat értelmet), majd ha végzett, akkor az eredeti adatbázist törli, az ideiglenest pedig átnevezi. Visszacsatoljuk és jó esetben mindenki boldog.

Most jön egy újabb kitérő. Olvasdd el Paul Cunningham írását. Nagyon szépen körbejárja a témát, a végeredménnyel pedig csak egyetérteni lehet: az offline defrag nem az az elem, melyet a rendszeres, szabályozott karbantartási folyamatok során végzel. Mivel az offline defrag offline, és emellett kockázatos is, csak akkor van értelme, ha az adatbázis mérete már problémákat okoz. Pontosan miket is? Egyrészt kezd elfogyni a tárterület a diszken. Ekkor el lehet gondolkozni az offline tömörítésen, de ha nem szeretjük a kockázatot, akkor lehet bővíteni is a tárterületet. Másrészt – saját tapasztalataim szerint – az Online Maintenance időigénye az edb fájl fizikai méretével arányos. A nagy edb fájl hosszú Online Maintenance időt jelent és így már lehet, hogy a folyamat nem fér bele a kijelölt időablakba. Nyilván az időablakot ki lehet húzni, de ekkor összecsúsznak az adatbázisműveletek, neadjisten belecsúsznak a produktív időbe, ez persze újabb terhelés – és egész egyszerűen mire végetér egy online tömörítés, már megint töredezett az adatbázis. Értelemszerűen itt is eljárhatunk úgy, hogy bővítünk – több RAM/proci – de ennyire ne legyünk már nyulak. Ezzel ugyanis csak elodázzuk a probléma megoldását.

Ekkor úgy halványan felmerül az offline tömörítés utáni igény az IT csapatban. De biztos, hogy erre van szükségünk? Mi van, ha az adatbázis tényleg ekkora lett? (Jelzem, ha az adatbázis mérete meg lett tervezve, az összes postafiók mérete korlátos, akkor ez a kérdés érdektelen.) Ilyenkor lenne jó tudni, mennyi is a whitespace. Biztosan vannak szofisztikáltabb módszerek is, én egy közepesen bonyolult powershell parancsot szoktam használni:

get-mailboxdatabase | get-mailboxstatistics | measure-object -property itemcount,totalitemsize -sum

Ez a szerveren lévő összes adatbázisra kiírja, hogy mennyi item-et (levelet, kontaktot, naptárbejegyzést) tartalmaznak, illetve ezeknek mekkora az összesített méretük. Ugyanez létezik konkrét adatbázisra is:

get-mailboxstatistics -database name | measure-object -property itemcount,totalitemsize -sum
get-publicfolderstatistics | measure-object -property itemcount,totalitemsize -sum

Az adatbázisok fizikai méretét megtaláljuk a Windows Explorerben, ebből pedig tudni fogjuk, hogy az adatbázisban mennyi az adat jellegű tartalom adattartalma. Igen, nem véletlenül fogalmaztam ennyire körülményesen. A cikk elején is írtam, hogy az edb fájlban vannak olyan adattáblák is, melyek az adatok strukturálását, gyors elérését segítik. Ez az adatbázis overhead. Tervezéskor én 20%-kal szoktam dolgozni – mégem hidat méretezünk, ekkora pontosság bőven elég – azaz ha ennél jóval nagyobb a különbség, akkor tényleg itt van az ideje az offline tömörítésnek.

Vagy mégsem?

Jó hír azoknak, akik Exchange 2010-et üzemeltetnek, hogy ők már használhatják az offline tömörítést online is. Nem, nem golyóztam be, legalábbis még nem nagyon. Olvassuk vissza, mit csinál az eseutil: nem tudnánk ezt mi is elvégezni, az adatbázis lecsatolása nélkül? Létrehozunk egy új adatbázist, felcsatoljuk, a postafiókokat átmozgatjuk (csak az adattartalom megy át, a whitespace nem), a régi adatbázist lecsatoljuk, letöröljük. Kész. A kliensek nem a Mailbox szerverhez kapcsolódnak, hanem a CAS szerverhez, az meg mindig tudja, melyik adatbázisban van a felhasználó. Ezzel ki is húztuk az offline defrag mindkét méregfogát:
- Nem offline. Régebben könnyű volt az élet, ötkor megszólalt a gyárban a sziréna, a portás hatkor lehúzta a redőnyt, a rendszergazda ekkor kezdett ébredezni, majd éjjel lecsatolta az adatbázisokat és reszelgette. Manapság már nincs holtidő. A legtöbb alkalmazottnak van minimum egy emailképes kütyüje, és valami fura perverzióból éjjel is meg akarják nézni a leveleiket. Offline folyamat? Hogy gondolod.
- Bármennyire okos is az eseutil, egyszerűen nem tudjuk olyan alaposan paraméterezni, mit csináljon az értelmetlen adatokkal, mint ahogy egy postafiókmásolás esetében. Már nem kell rettegni attól, hogy az eseutil után kapunk egy annyira tömör adatbázist, hogy gyakorlatilag üres.

Nosza, nézzük azt a problémát. Elindítottam az outlook-ot a kliensen – erre közölte, hogy nincs Exchange szerver. Hoppá. Megpingettem, látta. Névre is, IP-re is. Mind a kettőt. Biztos az outlook2003 hülyéskedik – gondoltam – és beléptem egy másik tesztgépbe, ahol outlook2010 dolgozott. Ugyanaz. Ő sem látta az Exchange szervereket.
Mi a fenét csinálhattak a patch-ek?

Korán reggel volt, az agyam még nem bootolt be rendesen, pusztán ezzel tudom magyarázni, hogy már első körben ész nélkül nekiálltam guglizni. Lett is egy csomó találat, egyik vadabb dolgot mondott, mint a másik. Mindegyik szálnak utánajártam, de minden rendben volt, ezek nem okozhatták a hibát.
Kimentem a konyhába, főztem egy kávét. Innentől mondhatom azt, hogy nekiálltam módszeresen felgöngyölíteni a problémát. Exchange szerver, eventlog. Minden rendben, viszont másfél órával ezelőtt tömérdek piros felkiáltójel. Hmm, hmm. Nagyon sok. Ezt most mind olvassam át? Eh, ez másfél órával ezelőtt volt, nekem meg most van bajom. Majd visszanézek, ha nincs jobb ötletem.
Nézzük az Exchange szolgáltatásokat. Na, itt köptem vissza kis híján a kávét. Az automatikusan induló Exchange szolgáltatások durván fele csak úgy lógott a levegőben, köztük persze az Exchange RPC is. Mind a két szerveren! Ez azért már tényleg izgalmas. Indítsuk újra. Sorra végignyomkodtam a start gombot és a szervízek elindultak. Ráküldtem még vagy 5 refresh-t, de a szolgáltatások makacsul működtek. Ez egyre rejtélyesebb. Valahogy nyugodtabb lettem volna, ha a szolgáltatások egyszer csak maguktól megálltak volna.

Na, mindegy. Nézzük az outlook mit lát. Mindent. Mind a kettő. Mind a két Exchange szerveren. Fejvakarás.
Gyorsan megnéztem, amit a kora reggeli kérdéssel kapcsolatban akartam, aztán amíg válaszoltam, be is ugrott a megoldás. A kora reggel. A patch.
Idősporolás miatt egyszerre nyomtam rá mindegyik szerveren a Windows Update gombra, aztán reggeli után egyszerre a Reboot gombra. Az öt szerver (két DC, két Exchange, egy TMG) egyszerre állt le és egyszerre indult újra. Csakhogy. Amikor az Exchange szerverek szolgáltatásai keresték volna az AD-t, az még sehol sem volt. Emiatt vésték tele piros felkiáltójellel az eseménynaplót. Később persze meglett az AD, de a szolgáltatások nem indultak el maguktól.

Tanulság? A reggeli kávé előtt soha ne pecseljünk.

Oké, értem én, a tanúsítványos játék soha nem volt igazán egyszerű. Illetve, ha megpróbáltuk egyszerűvé tenni, mindjárt drága lett. Csináljunk saját CA szervert? Hát, az elég macera, ráadásul ki fog csak úgy megbízni a szerverünkben? Kérjük meg az embereket, hogy léccilécci tegyék a szerverünk tanúsítványát a Trusted CA Servers tárolójukba? Aha. Akkor már inkább vegyünk egyet valamelyik nagy CA szervezettől. Persze, ez pénzbe kerül.
A jó hír az, hogy nem mindig. Ha például magánszemély vagy, akkor a Comodo-tól(1) ingyen kapsz levelezésre használható tanúsítványt.

(1) Vagy akinek jobban tetszik, InstantSSL. Mindenesetre, ahogy maguk állítják, ők a második legnagyobbak a piacon, azaz ahhoz mindenképpen elég nagyok, hogy az általuk kiadott tanúsítványt valószínűleg mindenhol elfogadják a világon.

Meggyőztelek? Remek. Akkor nyomjál is rá bátran a megrendelő gombra.
Illetve, ne, várj egy kicsit. Milyen böngészőt használsz?

Elmesélem, hogyan jártam. Miután megrendeltem a tanúsítványt, közölték, hogy nagyon örülnek és küldenek a subject-ként megadott emailcímre egy levelet, melyben leírják a további teendőket. Ez nem volt bonyolult, rá kellett kattintani egy linkre. (Vagy elmenni egy weboldalra és beírni a levélben megadott emailcím/jelszó párost.) Oké, katt. Nagy büdös error.

“The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID).”

Mi van? A Comodo-t már megint meghekkelték? Márpedig bármelyik módszerrel próbálkoztam, mindig ezt az üzenetet kaptam. Benéztem a böngésző (Chrome) beállításai közé, hátha valahol túl szigorúra van állítva a tanúsítványok kezelése, de nem találtam semmit.
Jó, nézzük a többi böngészőt. Kimásoltam a linket. Firefox. Egy abszolút értelmezhetetlen hibaüzenetet kaptam. Opera. Lefagyott. IE9. Na, ez végre meglepően őszinte volt, azt írta, hogy szerinte nem a megfelelő böngészőt használom.

Ilyenkor marad a gugli. Nos, mondanom sem kell, az üzenetnek semmi köze a valósághoz. Szokás szerint.
John Robbins írta le a frankót, igaz, ő egy fizetős Comodo (kódaláíró) tanúsítvánnyal szívott.

A quick round with Comodo support and I find out Chrome and IE 9 are definitely not supported. They sent me a link with their instructions for downloading the certificate. The first line had me shaking my head:
1) Open http://www.instantssl.com/code-signing/ in Internet Explorer (IE) 6 or 7 with ActiveX enabled. (Windows XP preferred)

Hát, izé. Most akkor szedjem le az IE9-et, tegyem fel az IE8-at, kapjam le a tanúsítványt, majd upgradeljek vissza IE9-re? Elég rondán hangzik. Próbáltam kreatívan értelmezni az IE9 korábbi üzenetét. Mi van, ha a tanúsítványigénylő folyamat során a Comodo belerakott egy sütit a böngészőbe, mely később kellett a tanúsítvány letöltéséhez? Hiszen ez is belefér az üzenetbe.
Újabb próbálkozás. Chrome-ból visszavonattam a kért tanúsítványt, simán megtette. Majd átléptem az IE9 alá, bízva abban, hogy a John írásától eltelt egy évben csak észrevették a Comodo-nál, hogy van IE9 is. Újabb igénylés, most IE alól léptem be a gmail fiókomba – és tadam. Megkaptam a tanúsítványt, be is tette a Personal fiókba. (Nyilván kimentettem, és eltettem biztos helyre is.)

Tulajdonképpen ennyi. A többi már egyéni szociális probléma: a gmail-t ugyanis eddig senki nem értesítette, hogy egy levelet alá is lehet írni, sőt, akár titkosíthatnám is. Az hagyján, hogy a webes felületen erre semmi lehetőségem sincs, de ha aláírt levelet kapok, azzal sem tud mit kezdeni a kliens.

From Segédlet

A képen is látható, hogy a feladó publikus kulcsát tartalmazó tanúsítványt és az email lenyomatát is magában foglaló bináris cuccot a gmail egyszerűen csak egy p7s csatolásnak mutatja, anélkül, hogy értelmezné. Körbedolgozni persze lehet, a gépemen van Outlook is, abba felvettem a gmail fiókomat, aztán legfeljebb az aláírt leveleket innen küldöm. Csak éppen borzasztóan nem elegáns a dolog, mivel ekkor az elküldött levél nem ugyanabba a Sent Item folderbe kerül, márpedig én az esetek 99,99%-ában a webes felületről levelezek.

Ha esetleg kedved van még a témával kapcsolatos anyázást olvasni, tudom ajánlani Jason Perlow írását a zdnet-en. A cím önmagában is telitalálat és remekül illeszkedik hozzá az illusztráció is.

Az egyik az Exchange 2010 SP1 soron következő immár 6-os rollupja. Letölthető innen, további infók róla itt.

A másik egy igen bosszantó, ugyanakkor nem életbevágóan fontos hibát hivatott orvosolni. Ha az Exchange Management Console-t futtató gépen fenn van az IE9 és a Mailbox szerepkör tualjdonságait piszkáljuk akkor nem lehet becsukni a konzolt. Ezt az üzenetet kapjuk és csak a Task Managerből lehet kilőni az MMC-t: “You must close all dialog boxes before you can close Exchange Manaagement Console.”

Bővebben itt.

Az előző kettő itt található:

http://emaildetektiv.hu/2011/08/18/exchange-2010-owa-signature-image/

http://emaildetektiv.hu/2011/10/03/exchange-2010-owa-signature-image-2/

A cikk második részének megírása után, a szükséges elemeket felraktam az ügyfél rendszerébe, majd nyugodtan hátradőltem, hogy nincs több dolgom a témában, csak teríteni az aláírásokat, amint az ügyfél emberei kitöltik a megfelelő adatokat az AD-ban.

Néhány nap múlva kaptam néhány teszt felhasználót, akiknél megvoltak az adatok, legeneráltam az aláírásokat képpel együtt, felhasználók tesztelnek, …

puff nagy pofon, nem működik.

Én tesztelek náluk az ő gépükön vnc-vel. Nekem megy.

Pár nap közdés után valaki rájött (ez nem én voltam), hogy ha új levelet küldök akkor jó, ha egy beérkező levélre válaszolok, akkor már az OWA-ban is egy nagy büdös piros x van a kép helyett. Tesztelés, ez bizony egy bug a rendszerben.

Két dolgot tehetünk:

1. Lejelentjük az MS-nek a hibát és reménykedünk, hogy megoldják.

2. Keresek valami megkerülő megoldást.

Hétfő (2011/10/17):

Mindkettőnek nekiugrottunk. A kollégák lejelentették az MS,nek én pedig elkezdtem Transport Agentet írni.

Estére el is készült az Agent váza, de még nem volt az igazi. Kollégám megfogalmazása erre a teszt levélre:

“az jó. csak mert abban igaz, hogy nem jön meg, de legalább a charcode is szar”

Hazamentem, este lett egy újabb öttletem, de az már nem fért bele a napba.

Kedd (2011/10/18):

Hajnalban nekiláttam, megcsináltam az Agentet, hibátlanul működött a teszt környezetben.

Lejelentettem, hogy jó, kértem a telepítéshez időpontot (Nem mennek a dolgok hű bele balázs módra, mert, ha minimális esélye van némi szolgáltatáskiesésnek, akkor arról mindenkinek tudnia kell. Itt volt ilyen, mert bizonyos struktúraválltás miatt az OWA tanúsítványát is cserélni kellet, ami az SSL Host header miatt okoz egy-két perc fennakadást)

Kaptam időt estére/másnap hajnalra.

Szerda (2011/10/19):

Hajnalban felraktam mindent.

Reggel ügyfél tesztel,…

Eredmény: szar.

Egész nap más dolgom volt, nem tudtam vele foglalkozni.

Este indolklás nélkül jön egy kérés, hogy kapcsoljam ki az OWA-ban a html link szűrést. Nem tudtam vele foglalkozni, majd holnap.

Csütörtök (2011/10/20):

Hajnalban elkezdtem tesztelni, hogy tegnap miért nem megy. Ki is derült, hogy a disclaimer a ludas (mert kérem itt aláírás is van, meg jogi nyilatkozat is). Ugyanis amikor beteszi a levél végére a szöveget akkor kiszedte az általam az aláírás html img tag-jébe becsempészett role=”contetntinfo:embed” attributumot (pedig szerintem ez szabványos, a W3C-től szedtem, modjuk a tag lezáró /> jelből is kiszedte a pert ami pedig az xhtml-ben már kötelező). Tehát a probléma orvosolható, ha az én Agent-em magasabb prioritást kap mint a Transport Rule Agent.

Valahol a tesztelgetés közepén beállítottam a tegnapi kérést. Engedélyeztem a HTML linkeket. Ettől meggyógult az eredeti probléma.

Mi van?????

Valaki akkora ész volt, hogy rájött, a piros x-es gondot az OWA “Web Beacon and HTML Filter” nevű szűrője okozza. Mekkora ász!

Reggel vissza is kérdeztem a kollágától:

- Erre ki jött rá?
- tesztelték.
SAP levélben linkek, nem tudták megbökni
- de arra, hogy ez megoldja az aláírásban kép balhét?
- arra senki.

Most őszintén. Ennek mekkora az esélye?

Agent kukába, a megoldás:

Get-OWAVirtualDirectory | Set-OWAVirtualDirectory -FilterWebBeaconsAndHtmlForms DisableFilter

Ugyan ez csökkenti a rendszer biztonságát, de valamit valamiért.

folyt. köv.

Valószínűleg így gondolta Ken Lasko is, mert a blogján közreadott egy gyűjteményt: melyek azok az RFC-k, melyek érintik a Lync működését.

Ami nem működik:

Attól, hogy egy megbízott tanúsítvánnyal aláírt oldalról érkezik a kép, az Outlook még nem fogja megjeleníteni.

Ami viszont működik:

Ha az OWA kliensen ahonnan a levelet küldjük feltelepítjük az S/MIME bővítményt, akkor az aláírásban elhelyezett kép beágyazott képként belekerül az elküldött levélbe így az Outlook meg fogja jeleníteni. A képet ehhez a mutatványhoz is egy megbízott SSL oldalon kell elhelyezni, viszont ehhez jó a saját tanúsítványunk is mert ebben a fogadó oldalnak nem kell megbíznia, a feladónak viszont, igen, hogy be tudja ágyazni a képet.

Ezzel a kérdés meg is lenne oldva, de mi történik, ha nem csak saját magunknak szórakozásból csinálunk ilyet, hanem cégesen több száz gépen kell az S/MIME-ot telepíteni?

Az S/MIME OWA kiterjesztés tulajdonképpen egy IE bővítmény, ami MSI alapú telepítővel rendelkezik. Ez az Exchange szerveren alapból a C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\smime könyvtárban owasmime.msi néven szerepel. Ezt ki tudjuk tolni Group Policy-ból az érintett kliensekre. Ezzel ugyanakkor még nem vagyunk meg, mert a bővítmény nem kerül automatikusan engedélyezésre. Ahhoz, hogy engedélyezzük a Group Policy User Configuration/Policies/Administrative Template/Windows Components/Internet Explorer/Security Features/Add-on Management alatt fel kell venni a {3050F819-98B5-11CF-BB82-00AA00BDCE0B} kulcsot, 1-es értékkel. Ez engedélyezik a bővítmény használatát.

A tesztrendszeremhez kellett volna egy 32 bites Windows Server 2008. Msdn-es telepítőkulcsom még volt, telepítő médiám… a fene tudja. Úgy emlékeztem, hogy van, csak nem tudtam, hogy hol. Semmi baj, tudomásom szerint a Microsoft oldaláról letöltött eval verzió ugyanaz, a kulccsal simán lehet aktiválni.
Letöltöttem, kiajánlottam a virtuális gépnek, indít, nyelvválasztás… majd telepítő kód. Nosza, begépeltem.

Windows installation has encountered an error and needs to be restarted.

Ez volt a válasz. Ejnye már. Beindítottam a riadóláncot, kértem még néhány kódot. Mindegyikre ugyanezt a választ kaptam, függetlenül attól, hogy milyen tipusú kód volt.
Oké, ennyit az eval verzióról. Kuncsorogtam egy msdn verziójú telepítőt az msdn kódom mellé, azzal már gond nélkül felszaladt, úgy, hogy nem kért semmilyen kódot.

Botor dolog lenne persze azt mondani, hogy az eval szar, az msdn meg jó. A kettő között olyan 200 KB különbség van, azaz a két telepítő gyakorlatilag ugyanaz. Egy különbség van csak, de az elég groteszk ahhoz, hogy megérjen egy írást.

• Az msdn verzió annyival rövidebb, hogy nem kér semmilyen kódot. Feltelepíted, majd kapsz 3 napot, hogy aktiváld.
• Az eval verzió logikája, hogy nem kell hozzá kód, de 180 nap után a kardjába dől. Természetesen ezen időszak alatt, ha van rendes kulcsod, aktiválhatod és teljes értékű szervered lesz.

Eddig nincs is gond. Csakhogy valami mekkmester úgy gondolta, hogy utólag rárak még valami okosságot. Azt mondta, hogy milyen remek lenne, ha az eval verzióba már telepítés előtt be lehetne ütni a valós kódot, így két legyet ütünk egy csapásra. Berakták. Azzal a szubrutinnal együtt, amelyik online akarja leellenőrizni a kódot, hogy valós-e. Mindezt a telepítésnek abban a fázisában, amikor nemhogy mini operációs rendszer nincs a gépen, de még network sem. Trükkös, mi? Az ellenőrzés nyilván elhasal, bármilyen kódot is írsz be. Egyedül akkor megy tovább, ha üresen hagyod a mezőt. Gondolj bele, mennyi értelme van feltenni egy kérdést, de csak akkor továbbengedni a delikvenst, ha nem válaszol semmit.
És mindezt pluszban programozták bele a telepítőbe.
Finom.

Megjegyzés

Mindemellett el tudom képzelni, hogy pont fordítva történtek a dolgok és mind az eval, mind az msdn verzió a bolti változatból keletkezett, a kódbekérő rész részleges, illetve teljes kiműtésével. Sőt, még azt sem tartom kizártnak, hogy létezik valahol egy manual, ahol leírják, hogy az eval verziónál tilos bármit is beírni az ablakba. (A letöltési oldalon mindenesetre csak annyit említenek, hogy nem kötelező.) Még az is lehet, hogy nem akar online ellenőrizni, hanem egyszerűen csak kivették belőle a validáló rutint. Sok minden lehet. Ha így van, akkor ez az egész már nem tűnik annyira nagy hülyeségnek… de gányolásnak igen.

A UNIX sokkal komplikáltabb – az átlagos UNIX buherátornak sose jut eszébe, hogy is hívják ezen a héten a PRINT parancsot

Az Igazi Programozó

Valamikor jókat röhögtünk a fenti íráson… és meg sem fordult a fejünkben, hogy egyszer a Windows operációs rendszerben is – egyáltalán, az se fordult meg a fejünkben, hogy a Windowsból operációs rendszer lesz – hasonló káosz alakul ki a nevek és szintaktikák körül.

Összelapátoltam ebbe az írásba, pusztán csak úgy magamnak, néhány fontosabb változást. Olyan egyszerű – legalábbis régebben egyszerű – fogásokról lesz szó, melyek ma már némileg megbonyolódtak.

Winhttp

Ha proxy mögül neteztünk, és olyan programot kellett indítanunk, amelyik képtelen volt kiolvasni az Internet Explorerből a proxy beállításokat (pl. Windows Update), akkor volt szükség a winhttp proxy beállítására. Ezt nagyon egyszerűen lehetett megoldani, a proxycfg paranccsal:

proxycfg -p proxyservername:portnumber -> beállította a proxyszerver értékét a winhttp-ben,
proxycfg -d -> lenullázta a proxyszerver értékét a winhttp-ben.

A Windows 2008 szerverben kinyírták a proxycfg-t, a tudását pedig átadták a netsh-nak. Itt így néz ki a parancs:

From Segédlet

Server Manager

A Windows Server 2008-ban kapott végre értelmet a Server Manager konzol. Most nem részletezem, mi mindent lehet vele kavarni, hiszen nem a dedóban vagyunk. Gondolom, azzal sem mondok újat, hogy volt neki parancssoros verziója is, mellyel pontosan ugyanannyi csodát lehetett varázsolni, mint a grafikus konzollal. Ezt a programot hívták úgy, hogy servermanagercmd.
A Windows Server 2008 R2-ben viszont megszűnt ez a parancs. Pontosabban, beleolvadt a Powershell-be. Elindítjuk, betöltjük a ServerManager modult

import-module ServerManager

és tulajdonképpen megint megtehetünk mindent, amit korábban is, csak teljesen más szintakszissal. Life long learning.

Időszinkron

Ez az ősidőkben (NT4) még elég cifrán működött, de aztán finoman becsiszolódott. Tartományi környezetben a PDC emulátor FSMO szereppel ellátott tartományvezérlőt kell hozzászinkronizálni egy külső forráshoz, tőle pedig – a szolgálati út betartásával – megkapja a többi tartományvezérlő, még akkor is, ha az erdő több tartományból áll. A tartományi kliensek pedig értelemszerűen a tartományvezérlőhöz szinkronizálnak.
A PDC emulátor beállítása pofonegyszerű volt:

net time /querysntp -> Lekérdezte az ntp szerver nevét
net time /setsntp:time.kfki.hu -> Beállította az ntp szerver nevét

A Windows Server 2008 R2 ezt is nyugdíjba küldte. Bejött helyette a w32tm parancs, a szintakszis pedig finoman szólva is durván bonyolult lett:

w32tm /config /manualpeerlist:time.kfki.hu,0×8 /syncfromflags:MANUAL /reliable:yes
w32tm /config /update
net stop w32time
net start w32time
w32tm /resync

A szkript – mert ez már az – önmagában is megérne egy elemzést. Mivel még mindig nem dedó, ezt rátok bízom: a parancs létezik a korábbi Windows változatokban, mind kliens-, mind szerveroldalon, a w32tm /? parancsra elég részletes help jön fel. Egy dolgot nem ír a help: mi a búbánat az a 0×8 függelék az ntp szerver neve mögött? Erre egy KB cikk ad választ: ezzel a kapcsolóval állítjuk be, hogy az ntp kérést kliens módban küldje a gépünk.

Nos, kidobásról szó sem lehet. Jó lesz ez még valamire.

1. Belehallgatni a hálózati forgalomba

Képzeld el, hogy van egy router az internet felé, a belső hálón pedig egy NAS. Egyik sincs rootolva (mert egyáltalán nem vagyok olyan vadember, mint amilyennek néha látszom), az utóbbin valami linux klón alapú oprendszer van. A NAS-on beállítható, hogy küldjön emailben riasztást, ha bármi rendkivüli esemény történt. Beállítottam. Van mellette egy ‘teszt’ gomb. Megnyomtam. Szűkszavú üzenet: a levélküldés sikertelen.
?
Ha látnám a hálózati forgalmat, sokkal okosabb lennék. De egyik eszközön sincs sniffer, a switchelt hálózatban meg cseszhetem a promiszkusz módot. Nos, ekkor jön a jó öreg HUB. Beledugom a NAS-t, beledugom a laptopot, beledugom a routert, és már indulhat is a Wireshark.

2. Kici ócó NLB

Nem lesz rövid. Ahhoz, hogy érthető legyen a levezetés, kénytelen leszek alaposan kivesézni ezt az egész NLB katyvaszt, közben persze el is fogok kalandozni jobbra-balra. De nem lesz minden haszon nélkül az írás, legalábbis remélem.
Kezdjük ott, hogy milyen NLB technikák is léteznek?
Multicast és Unicast.
Mindkét módszernél azt kell valahogy megoldanunk, hogy habár egy csomagot csak egy unicast IP címre küldünk el, az mégis több géphez érkezhessen meg. Sőt, az a varázsló, aki ezt elvégzi, gondoskodjon arról is, hogy a célgépek közötti terhelés elosztása konfigurálható legyen. Még sőtebb, tudjuk szabályozni azt is, hogy a szétszórás csak bizonyos portok között történjen meg.
A varázslót hívják NLB-nek, illetve a Windows implementációját WNLB-nek.

From Segédlet

2.1 Multicast

Ebben az esetben az NLB node-ok hálózati kártyái kapnak egy plusz unicast IP címet (VIP) és egy plusz multicast MAC címet (VMACM), a meglévő unicast IP címük (IP1/IP2) és MAC címük (MAC1/MAC2) mellé.

From Segédlet

A node-ok személyes adatforgalmát a módosítás nem érinti. Használják az IP1/2 és MAC1/2 címeket, élnek, mint Marci Hevesen. A switchben is a MAC1/2 címek jelennek meg, hiszen ez szerepel a csomagok Ethernet keretében. A VIP címet felvettük a DNS-be, kihirdettük a cégnél. Jön is a kliens és rá akar csatlakozni az NLB szolgáltatására. (Az egyszerűség kedvéért legyen ez egy weblap, de bármi más is lehet, ami egy tcp porton keresztül érhető el.) A felhasználó beírja a böngészőbe a címet, a DNS visszaadja neki a VIP-et, a gép elküld egy ARP kérést a VIP címre. Ez broadcast, tehát mindenki felkapja. Az NLB magára ismer és küld egy ARP választ, benne a VMACM címmel. A kliens örül, megvan a cél MAC address, beteszi az Ethernet keretbe, megy a csomag. A switch érzékeli, hogy a csomag címzettje egy multicast MAC cím, alaphelyzetben ezeket gondolkodás nélkül kitolja mindegyik portra, tehát a csomag megérkezik az NLB-hez is, aki a saját szeszélye alapján továbbtolja valamelyik node-ra.
Okos? Okos. Működik? Háát…
Akadnak bajok.
Például egy másik kliens a router mögül próbálkozik. Ilyenkor a túloldali ARP kérést a router ragadja magához, hogy majd ő küld egy újabb ARP kérést a másik alhálózaton. Elküldi, visszakap egy olyan kombinációt, miszerint a cél node-nak unicast IP címe és multicast MAC címe van. – Ne te, már ne! – hőköl vissza és eldobja a csomagot. Kommunikáció meglőve. Ezt még kilőhetjük úgy, hogy a router ARP táblájába felvesszük statikus bejegyzésként a VIP-VMACM párost, ilyenkor nincs ARP kérdezz/felelek, a router helyből tudja a MAC címet, tehát mehet a csomag. (Hozzáteszem, hogy vannak olyan háklis routerek, melyek nem csak az ARP válaszban nem bírják elviselni a unicast IP – multicast MAC kombinációt, hanem úgy egyáltalán sem. Ekkor elfelejthetjük a Multicast NLB-t, vagy érdemei elismerése mellett nyugdíjazzuk a routert.)
Oké, router rendben. De mi van, ha az NLB akar küldeni egy csomagot a nyúlon routeren túlra? Kezdi azzal, hogy küld egy ARP kérést a router IP címére. Windows 2003-ig bezárólag az NLB csalt, mert az ARP kérést a MAC1/2 címről küldte, de a Windows 2008 már a VMACM címet teszi a kérésbe. Mit csinál ezzel a router? Úgy van, kidobja oda, ahová a szabálytalan csomagokat szokta. A kommunikáció megint meghalt. Kénytelenek leszünk az NLB node-ok ARP tábláját is módosítani, fel kell venni a router IP-MAC párosát statikus bejegyzésként. Ekkor nem kell megvárnunk, hogy a router válaszoljon a szabálytalan kérésünkre, menni fog a feloldás séróból is.
És még nincs vége a galibáknak.
Mit is írtam? A switchre küldött multicast MAC címet tartalmazó csomagot a switch alapból kiküldi minden portjára. Jó ez nekünk? Nem annyira. Gyakorlatilag elárasztjuk a switchre kötött egyéb hostokat tök felesleges csomagokkal. (Úgy is hívják a jelenséget, hogy flood.) Természetesen ez ellen is lehet védekezni, de itt már elgondolkodik a rendszergazda arról, hogy mennyire is igaz a Microsoft azon állítása, hogy az NLB olcsó és egyszerű technika.
Az egyik megoldás úgy néz ki, hogy okos switchünk van, ahol be tudjuk állítani, hogy a multicast csomagok mely portokon jelenhetnek csak meg. A többi port coki. Ez működik, de olyan nem elegáns. Ha figyelmetlenül valamiért átdugom másik portba az NLB lábát, akkor újra floodolok, ráadásul lehet, hogy csak akkor veszem észre, amikor vezig ordítva beront a gépterembe a hálózat lassúsága miatt. (Oké, jobb helyeken a vezig kártyája nem nyitja a gépterem ajtaját, de nem biztos, hogy adott esetben ez a hosszútávú megoldás.)
Sokkal elegánsabb, ha még okosabb switchet használunk, mely már tudja az IGMP snooping technikát. Ekkor persze az NLB-t is konfigurálni kell. Azt mondjuk neki, hogy az ARP válasz csomag mellé tegyen már egy IGMP Host Membership Report csomagot is. Erre a csomagokra általában csak a routerek vevők, de nekünk okos switchünk van, aki bele tud lesni (snoop) az IGMP csomagba, és innentől tudni fogja, hogy mely portok mögött van olyan host, amelyik multicast vevő. A többire nem küldi tovább a multicast MAC címmel rendelkező csomagokat.
Végül természetesen megoldás lehet az is, hogy az NLB két lábát külön VLAN-ba tesszük. Ekkor ugyan a csomagok továbbra is elárasztják a broadcast domaint (a switchnek azokat a portjait, melyek a VLAN-hoz tartoznak), de mivel csak a két NLB láb érintett, így a floodolást az érintett portokra korlátoztuk. Viszont gondoskodnunk kell a VLAN elérhetőségéről.

Nos, ennyi. Látható, hogy a megoldáshoz módosítani kell mind a router, mind a node-ok ARP tábláját és minimum menedzselhető switchekre van szükségünk, akár portot akarunk konfigurálni, akár VLAN-t akarunk kialakítani, az IGMP snoopingról már nem is beszélve. Ez bizony se nem kici, se nem ócó. (A moddolt firmware-es olcsó routereket most hanyagoljuk.)

2.2 Unicast

Ennél az NLB technikánál más a trükk. Az NLB lecseréli a node-ok címeit, egy közös VIP és VMAC címre. Mindkettő unicast, tehát semmi szükség a multicast-os trükközésekre. Mivel mind a két node címei megyegyeznek, a nekik küldött csomagok megérkeznek az NLB-hez, aki már tud velük játszani.

From Segédlet

Nyilván ez sem ennyire egyszerű. Például milyen MAC címet jegyez be a switch a node-ok portjaihoz? A VMAC-et? Azzal gond lesz, mert az elsőt be fogja jegyezni, a másodikat már nem, mivel ugyanaz a MAC nem jelenhet meg más porton is. Ezzel jól ki is heréltük az NLB-t, mert mindig csak egy portra menne a forgalom.
A trükk az, hogy NLB elmaszkolja a VMAC címet. Összedob mindkét node számára egy kamu MAC címet és ezt teszi az Ethernet keretbe. (Az ábrán MACK1 és MACK2.) A switch ezeket a címeket fogja bejegyezni a portokhoz.
Nézzük akkor a folyamatot. VIP-et bejegyeztük, kihirdettük, felhasználónk beírja a böngészőbe, a gépe elküld egy ARP kérést a VIP címre. Az NLB felkapja, belerakja az ARP keretbe a valódi VMAC értéket. (Az Ethernet keretben a kamu MAC cím van, de ez jelenleg senkit nem érdekel.) A kérdező megkapja, boldog. Összedobja a csomagot. Hogyan? Hát belerakja a frissen kapott VMAC értéket az Ethernet keretbe. Elküldi. Mit fog ezzel a csomaggal csinálni a switch? Hát, zavarba jön. Ilyen MAC cím nincs hozzárendelve egyik porthoz sem. Ilyenkor a standard eljárás az, hogy a switch kiküldi a csomagot minden portra és reménykedik abban, hogy valahonnan visszajön egy válasz és akkor majd bejegyzi jól. Hát, ezt most várhatja.
Lássuk a cifrázást.
A router jelen esetben nem háklis. Mind a VIP, mind a VMAC normális unicast címek. Suhannak a csomagok, mint olajos hal a vécélefolyóban.
Ellenben. Tud-e kommunikálni a két node egymással? Nézzük. Node1 küld egy ARP kérést a VIP címre. Az ARP keretben visszakapja a VMAC értéket. Ezt belerakja a küldendő csomag Ethernet keretébe… majd döbbenten észleli, hogy ez az ő MAC címe. Nem küldi sehova.
Legalábbis nem mindig. És nem mindet.
Ott van például az NLB heartbeat. Erről annyit kell tudni, hogy broadcast, az Ethertype értéke 0x886F és csak node szinten működik, azaz azt nem tudja megállapítani, hogy a port szabályokban megadott portokon tényleg fut-e valami szolgáltatás. Na, ez a kommunikáció például megy. Miért is? Hiszen mondtam: broadcast. Csak a célzott kommunikáció nem megy.
És az se mindig döglődik. Windows 2003 Sp1 óta pl van egy érdekes lehetőség. A registry-ben engedélyezhető (UnicastInterHostCommSupport) hálózati kártya szinten, hogy unicast node-ok is tudjanak egymással beszélgetni.
Ettől függetlenül ez a modell nem terjedt el. Gondoljunk bele, mit csinálnánk, ha rendszergazdaként be szeretnénk lépni konkrétan az egyik node-ra? Az NLB meg mindig a másikra dob. Idegbaj. Emiatt is szoktak berakni az NLB kártya mellé egy másik hálózati kártyát.

From Segédlet

Nem mondanám, hogy egyszerűsödik, mi? Számok, szaggatott nyilak, minden, ami szem-szájnak ingere.
Az alapprobléma az, hogy melyik kártyán legyen beállítva a default gateway. Mindkettőn nem javasolt, mint ahogy a Windows erre figyelmeztet is. Na jó, akkor melyik legyen a nagy hatótávolságú, routeren is átlátó kártya és melyik az, amelyik csak a subneten beszélget? Hülye kérdés. Nem így fogjuk rendezni a helyzetet. Egyszerűen beállítjuk a normál kártyát első számú kártyának (erre kerül a default gateway), az NLB kártyát meg második számúnak. Így bármelyik kártyán is jön be csomag, kifelé a normál kártyán fog menni.
Ha hagyják.
A Vista/Windows Server 2008 vonulat óta a hálózati kártyák összelinkelése alaphelyzetben tiltott. Azaz ha az NLB kártyán jön be egy csomag, akkor az nem tud kimenni a másik kártyán. Ehhez netsh segítségével rá kell linkelni az NLB kártya forgalmát a normál kártyára. Ekkor már ki tud menni.
Windows Server 2008 esetén ugyanezt másképpen is el tudjuk érni. Modellváltás. A Windows Server 2008 alaphelyzetben az ún. Strong Host modellt használja. A korábbi szervertermékek a Weak Host modellt alkalmazták, mely azt jelenti, hogy az operációs rendszernek semmi kifogása sincs az ellen, hogy multihomed (több hálókártyás) rendszerben az egyik kártyán keresztül el lehessen érni a másik kártyán futó szolgáltatásokat. A mi esetünkben ez azzal jár, hogy a Windowst át kell váltani a Weak Host modellre. Naná, ezt is netsh-val, méghozzá kártyaszinten, azon belül is külön küldő, illetve külön fogadó irányban.
Zsong már a fejed? Pedig még nincs vége.
Nézzük át, mi is történik ilyenkor. VIP publikálva, felhasználó gépétől jön az ARP kérés a VIP címre. Ez broadcast, kimegy mindenhová, az NLB felkapja. A válaszba belerakja a VIP és a VMAC értékeket. A visszamenő csomag viszont már a konkrét gép valós hálózati kártyáján megy ki, annak a MAC címe kerül bele az Ethernet keretbe… de ez megint senkit nem érdekel. A túloldalon kicsomagolják az ARP keretet, a következő csomag Ethernet keretébe már az onnan jövő MAC (VMAC) kerül, ez kikerül minden switch portra (mert ismeretlen), az NLB felkapja, a válaszcsomag megint a normál kártyáról megy ki… és így tovább.

Akkor most gondoljuk végig, mi a helyzet flood téren?
Hát, ugye, van. Éppen az előbb jártuk körbe.
Védekezési lehetőség? Nos, az IGMP itt nem játszik, hiszen nincs multicast. Emiatt a switch portját sem tudjuk multicastra konfigurálni. Bizony, egyedül a VLAN felosztás segít, azaz megint drága, menedzselhető switch kell.

És ez az a pont, ahol az eddig csendben üldögélő HUB végre szerepet kap.

From Segédlet

Mi az a csoda, amit a HUB tud? Hát az, hogy nagyjából akkor élte a fénykorát, amikor az NLB-t kitalálták. Erősebbet mondok: az NLB-t a HUB-hoz találták ki, ez az eszköz az NLB ideális játszótere. Miért? Mert a HUB abszolút nem foglalkozik a MAC címekkel. Nem azon a szinten dolgozik. Nagy ívben tojik arra, hogy mit bűvészkedünk a keretekben az L2 címzésekkel. Ez majd a később elszaporodó és egyre okosabb switchek problémája lesz.
Nézzük meg, mit is csináltunk. Az NLB hálókártyákat nem közvetlenül dugtuk be a switchbe, hanem beraktunk eléjük egy HUB-ot. Ennek már csak egy uplinkje kerül bele a switchbe. Mennyi? Egy.
Járjuk körbe ismét a folyamatot. A switch portjára két MAC is rákerül, a kamu MACK1 és a MACK2. A kliens elindít egy ARP kérést, ez broadcast, kikerül a HUB-ra, az NLB felkapja. Valamelyik normál hálókártyáról válaszol, az ARP keretben a VMAC. Kliens következő csomagjában az Ethernet keretben a VMAC, beérkezik a switchbe… ahol megint nem lesz ilyen MAC egyik portnál sem, tehát megint floodolunk.
Izé. Nem maradt itt ki valami?
Dehogyisnem.
A switchben most már csak egy helyen jelenne meg a VMAC, tehát nincs szükség maszkolásra. Egyszerűen kikapcsoljuk: MaskSourceMac érték nullára állítása a registryben. Ekkor kapjuk a fenti ábrán látható szituációt. A HUB letojja, hogy két lábán is ugyanaz a MAC – a VMAC – jelenik meg. Hiszen nála meg se jelenik, nem érzékeli. (Ezért piros.) Az uplinken – függetlenül attól, hogy melyik node-tól jött – csak a VMAC jelenik meg, tehát ez kerül rá a portra. A kliens ARP kérésére az NLB válaszol. Maszkolás nincs, tehát mind az Ethernet, mind az ARP keretbe a VMAC kerül. (De az Ethernet keret még mindig nem érdekli a klienst. A switchet annál inkább.) A kliens a VMAC címre küldi az újabb csomagot, a switchen van ilyen MAC a portoknál, tehát flood kilőve, a csomag csak a HUB-ra jut ki.

Nézzük meg, mit csináltunk. Van egy borzasztó gagyi, nem menedzselhető switchünk és egy, a sufniból előkukázott HUB. Mindösszesen egy plusz kábelbe, illetve egy registry állításba került és tökéletesen működő NLB megoldásunk van.
Tényleg jó néha az öreg a háznál.

Ps1.
Felvetődhet, hogy jó-jó, de mi a helyzet a sebességgel? A switch már jó eséllyel gigás. Hogyan lesz ezzel összhangban a 10 mbites HUB? Melyik piacon lehet venni gigás HUB-ot? A helyzet nem ennyire rossz. Nézzük csak meg, hogyan forognak a csomagok. A szerverre – konkrétan az NLB kártyára – küldött csomagok tényleg keresztülmennek a HUB-on, de a szerverről a kliens felé menő forgalom már közvetlenül a switchre megy. Legtöbbször a kliens csak vezérlő utasítást küld a szerver felé, az pedig adathalmazokat tol vissza – azaz a HUB pont ott szűk keresztmetszet, ahol egyébként sem nagyok az igények.

Ps2.
A cikknek ezzel még nincs vége. Az első célt elértük, látjuk, hogy a HUB-ot tényleg tudjuk még mire használni. De a téma még nincs körbejárva: mi a helyzet például a virtuális környezettel?