Page 2 of 19

Kemp, az új TMG 05

2015-05-22 / / 6 Comments

Nos, eddig csak karcolgattuk a felszínt. Ne felejtsük el, ez egy loadbalancer, értelemszerűen ezen a területen kell neki nagyot domborítania.
Ha szigorúan nézzük, akkor egy szerver reverz proxyzása tulajdonképpen a terheléselosztás speciális esete, ekkor ugyanis csak egy szerver között kell elosztanunk a terhelést. Viszont ha már ezen a területen jók vagyunk, akkor nem nagy ugrás a terhelést két, vagy több szerver közé teríteni.

Nézzük először azt a reverz proxyt. Jelen esetben a felállás egyértelmű: van a belső hálón – vagy a DMZ-ben – egy szerverem, ennek egy, vagy több szolgáltatását szeretném a külvilág felől elérhetővé tenni.

A Kemp szóhasználatában virtuális szerverek léteznek. Egy virtuális szerver (VS) rendelkezik mindennel, mely módon kívülről látni szeretnénk: IP címmel, porttal (portokkal) és viselkedéssel. A virtuális szerver mögött van egy, vagy több real szerver: ezek a publikálandó szerverek. (Nem, a real nem azt jelenti, hogy fizikai szerver.) Értelemszerűen a real szervereknek is vannak paraméterei. (A real szervereket kiválthatják ún. SubVS-ek, azaz a virtuális szerverekbe ágyazott alsóbb szintű virtuális szerverek. Ez egy csoda dolog, de majd később foglalkozunk velük. Viszont nem árt tudni, hogy a virtuális szerverek mögött mindig van real szerver, azaz a SubVS-ek mögött is lenniük kell.)

Akkor jöjjenek az ábrák.

From Segédlet

Jelen állapotban így néznek ki a virtuális szervereim. Aki szeret előrerohanni, már most szétnézhet, mit is lát. Az első négy sorban az egyes belső szervereim (192.168.199.0/24) 3389-es portjait sorra kipublikálom a loadbalancer 10.19.64.21-es címén, különböző custom portokon. Ezek mindegyike egy-egy virtuális szerver. (Két real szerver erőforrás problémák miatt le lett kapcsolva.) Az ötödik sorban pedig a szegény ember Exchange publikációja látszik: a belső Exchange szerver 443-as portja ki lett forgatva a loadbalancer külső lábára. Látható, az eszközön nincs tanúsítvány (certificate installed: on the real server). Szerencsére a Kemp ennél sokkal-sokkal többre képes.

Vegyünk észre egy furcsaságot: mindegyik virtuális szerver L7 szinten üzemel. Egy sima portforward. Vajon miért?

De előtte nézzük meg, hogyan hozhatunk létre egy virtuális szervert.

From Segédlet

Add New gomb, alapbeállítások. Töltsük ki értelemszerűen. (A 4444-es külső portra fogok fordítani.)

From Segédlet

Amikor létrehoztuk, megjelenik az első kilométer hosszúságú beállítóablak. Ne tévesszen meg, hogy elfértünk egy képernyőn: csak azért, mert egy csomó almenüt bezártam.
De nem úszod meg, ki fogom nyitogatni. Mindet.
Egyelőre azt vedd észre, hogy a Real Servers ablakban egymás mellett van az Add New és az Add SubVS gomb. Én mondtam.

A Basic ablakban sok meglepetés nincs. A virtuális szervert ki tudom publikálni másik IP címen is. Ha pedig deaktiválom a szervert, akkor a nyitólapon az éppen nem működó szerverek narancssárga színben jelennek meg. (Nem olyan ronda pirossal, mint fentebb.)

From Segédlet

Ez már a Standard panel. A továbbiakban nem áll szándékomban minden sort külön elmagyarázni, azért a beállítások elég beszédesek. (Ne feledjük el, hogy az alap cél a terheléselosztás szerverek között, nem pedig a publikálás.)

From Segédlet

Az SSL beállítások. Elég karcsú. Ja. Addig, amíg nem engedélyezzük az SSL Acceleration funkciót. Akkor viszont akkora ablak lesz belőle, hogy ihaj.

From Segédlet

Én megmondtam. Na, ezekbe a beállításokba most biztosan nem fogunk belemenni. (SNI? Kiváncsi vagyok, kinél szólal meg a csengő.)

From Segédlet

Advanced panel. Itt lehet beállítani, ha az LB cluster egyik node-ja sem működik, akkor melyik szerver melyik portjára küldje a forgalmat. Állíthatunk külön default GW-t a virtuális szerver számára és külön Access List-et is.

From Segédlet

Adjuk már végre hozzá a real szervert. Látható, hogy jelen példában a DC RPC Endpoint Mapper szolgáltatását (135-ös port) publikálom ki. (Mert meszet ettem.) Ha L7 LB-t választunk, akkor a NAT-ot nem lehet megváltoztatni.

From Segédlet

Nos, ezt hoztuk össze. Látható, hogy átböktem L4-re a boszme nevű virtuális szervert, de egyébként semmi különös. Innentől már nyomulhatunk is a 4444-es portra, feltéve, hogy tudjuk, mire jó egy DC 135-ös portja.

Nem tartozik szorosan a tárgyhoz, de ha esetleg valaki nem ismeri, tudom ajánlani a portquery segédprogram-csomagot. Ez áll egy parancsoros programból és egy portqueryui.exe nevű grafikus felületből. Ezzel lehet letesztelni, hogy egy adott port nyitva van-e? Azért bánjunk óvatosan vele, IDS programok támadásnak vehetik, ha túl sokat szkennelünk vele. Nagy előnye a Windows gépekre jellemző port csomagok használata. Például tudja azt, hogy egy domain & trust működéshez milyen portokat kell vizsgálnia.

From Segédlet

Tudom, a hekkerprogramok ennél jóval többet tudnak, de hé, ez egy Microsoft által gyártott segédprogram!

Rögtön nézzük is meg vele, hogy mit csináltunk?

From Segédlet

Remek. Valaki figyel azon a 4444-es porton. Innentől törölhetjük is azt a böszme virtuális szervert.

Nem árt tudni, hogy nem minden esetben kell ennyire nulláról felépítenünk egy virtuális szervert. A Kemp oldaláról letölthető egy csomó template.

From Segédlet

Én például ennyit telepítettem. Valószínűleg nem fogom mindet használni, de már csak az is tanulságos, ha átnézegetem ezeket. A félreértések elkerülése végett, egyik sablonban sincs olyan dolog, melyeket a fenti képernyőkön nem láthattunk. (Illetve, de: az ESP és az SSO még be fog kavarni.) A lényeg, hogy már előre ki van töltve minden, amire szükségünk lehet.

A valóságban azért ennyire nem rózsás a helyzet. Először is tudnod kell, hogy neked éppen jó-e a kiválasztott sablon? Ha nem, akkor tudnod kell, melyik másik sablonból kell építkezned és utána mit kell rajta átállítanod.

From Segédlet

Sablont a virtuális szerver létrehozásánál lehet választani, rögtön az első képernyőnél. Ne lepődjünk meg, ha a fenti ábrákhoz képest _szűkebb_ lehetőségeink lesznek. Ha például RDP szolgáltatást publikálunk, akkor fel sem jön olyan lehetőség, hogy L4 LB. Ne kérdezd, miért. (De itt van a válasz arra a sok L7 értékre a VS-ek között.) Emellett egyszerűen nem kapunk meg néhány panelt. Úgy gondolták, hogy minek.

Nos, ennyi volt az egyszerű publikálás. Hamarosan belevágunk az SSL reencryption, a preautentikáció és az SSO világába, azaz az igazi Exchange publikációba. De most hosszabb szünet jön, mert egyelőre még nem akar kotta szerint muzsikálni az eszköz, nekem pedig éppen nincs időm rá.

Kemp, az új TMG 04

2015-05-20 / / 4 Comments

Nos, nézzük meg, hogy muzsikál az eszköz, mint router. De mielőtt mélyebben belemennénk, nem árt tudni, hogy nem routerként árulják. Senki ne várjon funkcióhegyeket, áttekinthetetlen beállítópaneleket.

Nagyjából ebből áll a készlet.

From Segédlet

Nem túl sok, de akár elég is lehet. A Route Management alatti első két menüpont a route tábla szerkesztéséhez kell, emellett van egy elég egyszerű VPN menüpont is. IPSec tunelling, közös titokkal. Egy VPN kapcsolatot ismer (egyelőre), de ehhez is plusz licensz kell. Sokatmondó, hogy a doksiban egy Azure csatlakozást mutatnak be.

Igazából az Access Control alatt vannak azok a dolgok, melyekre szükségünk lesz, ha kommunikálni szeretnénk az eszközön keresztül. ACL-ek. A panelen csak IP szinten állíthatunk fekete, illetve fehér listát. Port szinten nem. A packetfilter még durvább: bekapcsolod, vagy kikapcsolod. De erről még írok.

Első körben azt szerettem volna, ha a cucc routol a két hálózat között. A loadbalancer blogon azt írják (6-os pont), hogy alapértelmezésben a packetfilter ki van kapcsolva. Ha bekapcsoljuk, megöljük a routolást. A helyzet az, hogy egyik állítás sem igazán fedi a valóságot..
Engem például ez a képernyő fogadott.

From Segédlet

Hasonlítsd ezt össze a fenti linken lévő ábrával. A packetfilter engedélyezve van… és _nincs állítási lehetőség_. Újabb guglizás és meg is lett az eredmény.

From Segédlet

Először ki kell kapcsolni a GSLB-t, jelentsen ez bármit is.

From Segédlet

Utána pedig már ki/bekapcsolható a packetfilter.

Kikapcsoltam, két belső szerveren is elindítottam a windowsupdate-t… és nyálcsorgással a szám szélén csak néztem és néztem, hogyan jönnek le a csomagok… és csak néztem, csak néztem. Négy napig. Ez ugyanis egy elhanyagolt tesztkörnyezet volt korábban.

Valójában RRAS/ARR/WAP alapon szerettem volna összerakni egy Exchange kommunikációt a belső hálózat és a szimulált internet között, de beletört a bicskám. Nyilván a routolást azért meg lehetett volna csinálni, de jobban érdekelt a két másik komponens.

Hát, három szerver, egy kliens, legalább egy éve települtek és még soha nem láttak windowsupdate-t. Darabonként 200+ csomag, 2-3 GB. Mindez egy 20 mbps-re korlátozott csövön, egy erőforráshiányos virtuális infrastruktúrán. Úgy, hogy közben piszkálgattam is a routert. Még örülhetek is, hogy csak négy nap volt.

A megismeréshez a klasszikus rendszergazda filozófiát használtam: ignoráltam a manuált. Valószínűleg emiatt voltak a korábban írt szívások is.
Mostanra azért már jobban kiismertem ezt a packetfiltert.

1. Először is, tényleg ennyi. Gondoltam, belépek a karakteres felületen, hátha ott cizelláltabbak a menüpontok.

From Segédlet

Ennyi. Az Access Control Lists alatt ugyanaz van, mint a webes felületen. De mi lehet ez a Local Port Control? Nem ezt keresem?

From Segédlet

Oké. Next.

2. Később elolvasva a manuált (igen, opportunista disznó vagyok), az alábbiakat lehet elmondani erről a csodáról:

  • Ha ki van kapcsolva, akkor nem foglalkozik az ACL-ekkel. Se a tiltással, se az engedélyezéssel. Azaz a packetfilter csak és kizárólagosan arra szolgál, hogy nem ész nélkül routol, hanem az IP címekre korlátozott ACL-ek alapján.
  • A szerver publikálásokat a packetfilter beállítása nem érdekli. (De mindegyik virtuális szerveren állíthatunk külön ACL-eket, melyek a publikálás során figyelembe lesznek véve, ez viszont csak a konkrét virtuális szerver elérhetőségére fog vonatkozni.)
  • Ha a szerverek próbálnak kifelé kapcsolatot kezdeményezni bekapcsolt packetfilter esetén, akkor ha az SNAT (Server NAT) engedélyezve van, akkor megy nekik. Ha nem, akkor nem.
  • Bekapcsolt packetfilter esetén lehetőségünk van komplett interfészre forgalmat tiltani.

Ez az elmélet. Nem egészen vág egybe a tapasztalataimmal, de nem tudok mit mondani, hiszen eleinte ész nélkül állítgattam mindent. Lehet, belejátszott a tiltásokba a windowsupdate forgalom is. Nem tudom. De mára lement minden frissítés, a doksinak megfelelően beállítgattam mindent és most rendben működik. Ahogy kell neki.

Miket igértem még?

  • Hálózati kártyák között route/nat állítás. Ilyet nem találtam. Viszont globálisan is, illetve virtuális szerver szinten is állítható, ami szvsz pont elég jó megoldás.
  • A port forwarding gyakorlatilag bekerült a virtuális szerverek közé, így majd ott foglalkozom velük.
  • Protokoll alapú szűrés. Ilyet egyelőre nem találtam. Viszont van WAF (Web Application Firewall) és van olyan, hogy content rules. De ezekből ránézésre semmit nem értettem, nyilván doksit kell hozzájuk olvasni.
  • Látható, hogy edge routernek nem igazán praktikus. Nem tudom beállítani rajta például, hogy a belső hálóról mindenki, vagy akár csak egy részhalmaza a gépeknek, elérje a netet, de csak a 80/443-as portokon. A packetfilter/ACL páros csak IP szinten működik. Lehet játszani egy elérakott proxy szerverrel, de azt sem fogjuk tudni port szinten kontrollálni.
  • Igen, proxy. Ez a funkcionalitás hiányzik az eszközből, azaz a TMG kényelmes webproxy szolgáltatását nélkülözni leszünk kénytelenek. Reverse proxy van, szűrni ekkor valószínűleg a WAF-fal lehet, de proxy, az nincs. Kell elé valami opensource cucc.

Essen még pár szó a network interfészekről.
Alapvetően semmi különös, egyszerűen lehet konfigurálni.

From Segédlet

A beállítási lehetőségek magukért beszélnek. A VLAN Configuration gomb mögött VLAN ID-kat lehet a kártyához adni. Egyedül az Interface Bonding gomb gondolkoztathatja el a naív infomunkást, de ez gyakorlatilag a teaming, azaz így lehet összevonni több interfészt. Innentől nem ethX néven fogunk rájuk hivatkozni, hanem bondX néven. (Értelemszerűen ha bondolni akarunk, meg VLAN ID-ket is hozzáadni, akkor először a bond jön és utána adjuk csak hozzá VLAN ID-ket a bondx virtuális interfészhez.)

[Update]
Aztán eltelt egy újabb éjszaka és megint csak két szervert értem el RDP-n. Már kezdtem volna anyázni, amikor feltűnt, hogy most más a jelenség: az RDP kapcsolat létrejött ugyan (működött a telnet), egy pillanatra be is jött a távoli képernyő, aztán megszakadt a kapcsolat. Hmm? Itt van a megoldás: ez egy Remote Desktop Connection Manager bug. Szerencsére a javításhoz már nem kell Visual Studio-ban patkolni, egyszerűen le kell szedni a 2.7-es RDCM csomagot.
De azért felállt a szőr a hátamon, amikor a reggeli kávénál úgy tűnt, hogy megint vacakol a Kemp. (Innentől persze az is valószínű, hogy a korábbi RDP problémák is az RDCM memóriaproblémái miatt lehettek.)

Kemp, az új TMG 03

2015-05-18 / / 1 Comment

Bár úgy terveztem, hogy a következő írások már a tesztekről szólnak, de rögtön az elején belefutottam két pofonba. Mondhatni, ez egy bréking nyúz.

1. Ne rúgd tökön magadat
Ez egyértelműen a saját hülyeségem. Utólag belegondolva logikus is, de mégis beszoptam.
A loadbalancernek van egy külső interfésze (eth0), ennek van egy IP címe. Ezen keresztül lehet elérni. Első kisérletnek ezen a címen kipublikáltam az Exchange szerver webes szolgáltatásait, nyilván https protokollon. Nem tesztelgettem, ezek még csak az első bátortalan kattogtatások voltak az UI-n. Aztán valamiért újra kellett indítanom az eszközt. És nem tudtam elérni a webes kezelőfelületét. Miért? Azért, mert az elérés az eth0 interfész IP címén a 443-as portra volt konfigurálva. Melyen frankón bejelentkezett az Exchange, amikor ráléptem. Hűha.
Brmennyire nem akartam ebbe a mélységbe leásni, be kellett lépnem a karakteres felületen. Hát, ha valaki arra gondolt, hogy itt kap egy klasszikus linux promptot, root jogosultsággal, nos, téved.

From Segédlet

Ez van. Egy karakteres képernyő, egy menüvel. És csak azt lehet tekergetni, amit a menü enged.
Szerencsére a hozzáférést lehet állítgatni. Local administration / web address.

From Segédlet

Gyorsan át is böktem a well-known 444-es portra, innentől már hozzáfértem a GUI-hoz. Felvettem egy másik IP címet az eth0 interfészre, átraktam erre az Exchange publikációt, a GUI elérést pedig a karakteres felületen visszaállítottam az eredeti portra. Utólag nem volt egy nagy ügy, de azért gondolkozhattam volna előtte. (Viszont itt van a megoldás arra az esetre, ha valaki nem dhcp-s környezetbe telepíti: a hostról be kell lépni a virtuális gépbe és beállítani a hálózati paramétereket.)

Csak kettő maradhat. Vagy mégsem?

Ha megnézed a tesztkörnyezetet mutató ábrát, láthatod, hogy a loadbalancer mögött négy virtuális gép figyel. Úgy igazából nem kell, hogy mind a négy gép kapcsolatban legyen a loadbalancerrel, hiszen csak az Exchange szerver és az rpx szerver szolgáltatásait terveztem publikálni, de különböző okok miatt (windows update, rdp hozzáférés) mind a négyet úgy állítottam be, hogy egyfelől a loadbalanceren keresztül elérjék a netet, illetve mindegyikről kipublikáltam az RDP szolgáltatást valami custom porton.
Na, ettől őrültem meg. Mind a négy gép hálózati szolgáltatása (subnet/DNS/DGW) tök ugyanúgy volt beállítva. A publikációik is ugyanarra a sémára épültek, eltekintve persze az egyedi portoktól. A DC-t és az Exchange szervert el is értem. Az RPX szervert és a munkaállomást viszont nem. Ezek a netet sem látták. Téptem a hajam. Wireshark. Semmi használható infó. Persze, hiszem a loadbalancer úgy volt beállítva, hogy ha valami nem jó, akkor eldobja a csomagokat, még RST-t sem küld vissza. (Nem mintha egy RST-vel boldogabb lettem volna.) Aztán jött egy váratlan váltás, hirtelen meghalt az Exchange/DC gépek elérhetősége, illetve internet hozzáférése, viszont hirtelen beindult a másik két gépé. Azaz nem konfigurációs hiba volt, egyszerűen a loadbalancer csak két párhuzamos kapcsolatot volt hajlandó kezelni.
Vakartam a fejemet. Erről eddig szó sem volt. Oké, elolvastam a doksikat, tudtam, hogy az ingyenes verziónál a sávszélesség le lett korlátozva 20 mbps-re.

From Segédlet

Látszik, ki is használtam. Windowsupdate két szerverre.

De a maximum két párhuzamos kapcsolatról sehol sem esik szó. Oké, ír a a cikk memóriakorlátról, de a mérések szerint nagyjából a rendelkezésre álló memória 10-15%-án üzemel a gép, a proci terhelése pedig maximum 10%. Egyelőre nem tudok mást mondani, mint hogy létezik darabszámra vonatkozó korlát. A tesztelésnél végülis nem zavar, terhelést elosztani lehet két szerver között is, de annak az elképzelésnek lőttek, hogy majd ezen a loadbalanceren kötöm össze a tesztelős alhálózataimat.

[Update1]
Aztán eltelt egy hétvége, miközben tekergettem ezt, meg azt. Először azt vettem észre, hogy hirtelen lett net mind a négy belső gépen. Nocsak. Vérszemet kaptam. RDP? Nem, az azért nem. Később felfigyeltem rá, hogy valahogy visszakapcsolódott a packetfilter. (Erről a jószágról hamarosan írok részletesebben is.) Kikapcsoltam, loadbalancer restart. Letöröltem az RDP publikálásokat, majd újra létrehoztam mindet. És innentől mind a négy működik. Ne kérdezd, mi volt a háttérben. Nem tudom.

[Update2]
Ma reggel megint fejreállt a publikálás. De most már tudom, hogy nem a Kemp volt a hibás. Részletek a következő írásban.

Kemp, az új TMG 02

2015-05-14 / / 1 Comment

Nem, még ebben a részben sem fogunk checkboxokat kattogtatni. Jelen írásban szeretném felvázolni, milyen teszteket tervezek, hová akarok eljutni. Emellett szeretném bemutatni a tesztkörnyezetet is.

From Segédlet

Nos, ez a játszótér. Habár az ábra szépen strukturált, de valójában csak a Microtik router, a laptopom és a Hyper-v szerver fizikai gép, minden más elem virtuális, természetesen a megfelelő virtuális switchekbe dugdosva. Ezt nem részletezem, úgyis tudod.
A DNS kicsit kacifántos, a szimulált internet miatt. A belső hálózaton (vt12.kft.net) sima AD van, az annak megfelelő DNS-sel. A forwardere a Homelab szerveren lévő DNS szerver. A loadbalancer eth0 lába szintén ugyanezt a DNS szervert használja. Ebben az a trükk, hogy ez a DNS szerver beelőzi az igazi internetes DNS szervereket, azaz akármelyik igazi zónát meg tudom rajta hamisítani, illetve fel tudok venni kamu, internetesnek tűnő zónákat. Logikus, hogy a C2013 kliensgép és a Hyper-v szerveren futó Hmail levelezőszerver is ezt a DNS szervert használja. A Homelab szerveren lévő DNS szerver forwardere a Microtik DNS szervere és innen már szabad az út az igazi internet felé. A laptopom nem vesz részt a kísérletben, onnan csak a Hyper-v szerveren lévő virtuális gépeket tekergetem a Hyper-v menedzseren keresztül.
Mivel alapvetően levelezési rendszer működését akarom tesztelni, értelemszerűen kell egy “internetes” levelezőszerver. Erre tökéletes az ingyenes, egyszerűen konfigurálható Hmail.
A kísérletben szereplő külső kliens nem véletlenül Windows 8.1: ebben már beépítve létezik egy metrós Posta program, mely ActiveSync-et használ. Emulált mobiltelefon helyett ezzel lehet tesztelni az Exchange ActiveSync (EAS) protokoll működését az ‘internet” felől.
A belső hálózaton szerepel még egy vt12-rpx01 nevű szerver: ezen majd egy teljesen kiépített RDS szerver (RemoteApp, RDweb, RDGW) publikálását szeretném tesztelni.

Nagyjából ennyit a környezetről. Nézzük a terveket.

1. Router

  • Az eszköz működjön routerként.
  • Route tábla szerkesztése.
  • Lehessen ki/bekapcsolni a natolást, esetleg külön beállítani az egyes hálózatok között.
  • Tudjam a routert konfigurálni: ACL-ek, port forwarding.
  • Konfigurálható packet filter, protokoll alapú szűrés.
  • Interfészeken VLAN-ok kezelése.

2. Webproxy

  • Kifelé menő webes protokollok proxyzása.
  • Beavatkozás a webes protokollok kezelésébe (szűrés).

3. Reverse Proxy

  • Exchange 2013 szolgáltatások publikálása.
  • SMTP forgalom kezelése.
  • RDS szolgáltatások publikálása, az Exchange szolgáltatásokkal párhuzamosan.

4. Load Balancer

  • Két Exchange 2010 közötti terheléselosztás. (Igen, 2010. A tesztszerverem már nem bírna el olyan környezetet, ahol két 2013-as működne egymás mellett.)

5. Full terhelés
Hosszabb távon nem csak egy belső hálózatot tervezek a loadbalancer mögé. Homokozós/játszós hálózatból is lehet több. Aztán vannak tanfolyami környezetek, melyeket itthon is össze kell raknom, ha fel akarok készülni az oktatásra. (Bár ezeknél nem annyira fontos a külső elérés.) Aztán van egy csomó olyan ügyfél, akiknek az informatikai rendszerében vannak kritikus elemek. Ezeket lemodelleztem itthon, hogy tudjak rajtuk kisérletezni. Ezt a sok-sok alhálózatot jó lenne valahogy összerendezni, elérhetővé tenni. Valahogy.

Amit nem fogok tesztelni, illetve amiben nem vagyok biztos

  • Lync, illetve ADFS publikálások. Vannak hozzájuk template-k, de egyelőre ezek nem érdekelnek.
  • Minden, amihez ESP kell. Egyelőre nem világos, hogy az ingyenes verzióval mi a helyzet. (A template-kben választhatók ESP opciók, de nem tudom, hogy működnek-e? Ilyenekre gondolok, mint SSO, preautentikáció, illetve SMTP relay.)
  • Loadbalancer cluster, azaz magas rendelkezésreállás. Ez hiányzik az ingyenes verzióból.

És akkor most egy hosszabb kihagyás jön az írásokkal. Jelenleg még a tesztkörnyezet sincs teljesen készen és még nekem is hátravan többszáz oldal a Kemp dokumentációjából. Stay tuned.

Kemp, az új TMG 01

2015-05-12 / / 14 Comments

Marhára kíváncsi vagyok, hány embernek maradt benne a blog az RSS olvasójában. Persze, ebben én is hibás vagyok, mindenhol azt hirdettem, hogy kész, vége, kampec. Megszűnt. Se kedvem, se időm.
Csak szólok, mielőtt még túl nagy remények ébrednének, hogy olyan nagy terveim továbbra sincsenek a bloggal. Ezt a sorozatot megírom, mert érdekel és szeretném magamnak is dokumentálni a folyamatot. De utána valószínűleg megint pangás jön.

Akkor jöjjön a lecsó.

Amikor megszűnt a TMG, nem kicsi maszatolás kezdődött a Microsoft részéről. Nem akarok belemenni, még most is érzékeny számomra egy kicsit a téma. Abba sem akarok belemenni, mennyi kínos pillanatunk volt az ügyfeleinknél, akik mondjuk Exchange szervert szerettek volna publikálni, mi pedig megpróbáltunk ködösíteni. Az opensource proxyk valamin mindig elhasaltak, a Microsoft megoldásai (ARR, WAP) pedig… hagyjuk. A vége az lett, hogy az MS is azt tanácsolta, használjunk loadbalancert. Ők is azt teszik.

Nos, miért ne?

Emlékszem, öt-hét évvel ezelőtt a loadbalancerek árai valahol a csillagos égben jártak. Aztán elkezdtek lejjebb csúszni. Aztán néhány Exchange blogban megjelentek írások arról, hogy nocsak, Kemp. És tényleg. A Kemp loadbalancerek árai egészen barátiak (akkor $1500 körül volt a beszálló kategória, ma azt hiszem $2000, ezt vesd össze egy fizikai szerver, egy Windows Server és egy TMG licensz együttes árával), és ami a leginkább figyelemreméltó, rámozdultak arra a résre, mely a TMG kiütése után keletkezett: kijöttek egy ESP (Edge Security Pack) termékkel, mely pont azt tudja, mint a TMG. Az ESP árának ugyan nem néztem utána, de ha nincs szükséged a teljes funkcionalitására, akkor az alap loadbalancerhez le lehet tölteni template-ket, ezekben komplett benne vannak az adott MS szerverek publikálásához szükséges virtuális szerverek.

Szóval éreztem, hogy ezzel foglalkozni kellene, csak hát nekem itthon nem volt erre a célra még tíz dollárom sem. A végső lökést az adta meg, hogy kijött a virtuális platformokra telepíthető Free LoadMaster. Ez egy ügyesen lebutított termék, pont annyira, hogy produktív környezetben azért ne nagyon tudd használni, de ha meg akarsz vele ismerkedni tesztkörnyezetben, arra azért elég legyen.

A sorozat első részében addig fogunk eljutni, hogy leírom, hogyan lehet beszerezni, hogyan lehet telepíteni és legfőképpen hogyan lehet belicenszelni.

1. Letöltés
Ez a legegyszerűbb. (Mondjuk, nekem sikerült ezt is elrontanom.) A fenti linken van egy download menüpont. Ha még nincs regisztrált felhasználód a Kemp-nél, akkor csinálni kell egyet. Az emailcím szigorúan valódi kell legyen, mert ide fogják küldeni a licenszkulcsot. (Meg a későbbi reklámleveleket.)
Ha ezen túl vagy, lépjél be. Lesz egy form, itt lehet kiválasztani, hogy milyen verziójú VMware/Hyper-v host szervered van, aztán már jön is a csomag.

2. Telepítés
Amit letöltöttél, az egy kellően részletes telepítési segédlet és egy komplett virtuális gép. A manuál nem hosszú, érdemes elolvasni. (Húsz oldal, ebből négy oldal blabla.) Gyakorlatilag a virtuális gépet be kell importálni, na meg persze elő kell készíteni számára a terepet. Nem árt, ha már előtte megtervezed a tesztkörnyezetet és létrehozod a szükséges vswitcheket. Vigyázat, a Kemp eth0 interfészén internethozzáférést kell biztosítani! És nem csak a telepítés idejére, hanem folyamatosan. (Igen, ezen jelentget az anyacégnek. Ezért free.)
Na mindegy, kapcsoljuk be. Ha ügyesek vagyunk (azaz a virtuális gép konfigján már beállítottuk neki a megfelelő switchet, azaz egy olyat, amelyen elérhető a DHCP szolgáltatás is), akkor egy olyan IP címet fog mutatni a karakteres képernyő, melyen keresztül el is tudjuk érni a grafikus felületet a böngészőből. Ha nem, akkor szopunk.

From Segédlet

3. Licenszelés
Lépjünk be. (Kopp-kopp, szabad.) Mármint a webes felületen. A default felhasználónév és jelszó benne van a doksiban. Előbb-utóbb feljön egy licenszelő ablak. Lehet választani az online/offline változatok között. Én valamilyen okból az offline változatot választottam, ekkor egy emailben kapott szöveget kellett bemásolni egy formba. A licenszelés ezután simán lement. Fontos tudni, hogy ez a licensz 30 napra szól, azaz legkésőbb 30 naponta meg kell újítani. A gyakorlatban ez úgy néz ki, hogy ha a loadbalancer az eth0 lábával rajta van a neten, akkor minden nap bejelentkezik az anyacéghez és valamikor frissíti a licenszet. Ha 30 napnál tovább nincs számára net, akkor azt a loadbalancert elbuktuk, meghal.

4. Alapkonfigurálás
Rögtön az elején célszerű rendberakni az IP címet, illetve IP címeket. A DHCP által osztott címet átraktam a saját címtartományom fix IP-s részébe. Nyilván újra be kellett lépnem. Az eth0 interfészhez kapcsolódnak DNS/DGW beállítások is, bár ezeket trükkösen máshol kell megadni. (System Configuration, ezen belül Local DNS Configuration, illetve Route Management.) Állítsuk be a belső interface (eth01) IP címét is. A jelszó megváltoztatását csak azért nem írom le, mert ezt rögtön az elején maga az eszköz erőszakolja ki.

Ezzel gyakorlatilag készen is vagyunk, a loadbalancer működőképes.

Élet a TMG után

2013-07-19 / / 16 Comments

Az Exchange rendszerekkel foglalkozók különösen rossz néven vették, amikor a Microsoft kilőtte a TMG-t. Akárhogy is nézzük, az Exchange publikálásához ez egy remek eszköz volt: csont nélkül vitte az összes protokollt, már a DMZ-ben előautentikált, azaz a belső hálóra csak autentikált forgalmat engedett be, ráadásul magát a használt protokollokat is szűrte. A TMG után nem is maradt értelmes opció. Mi rengeteget szívtunk opensource megoldásokkal, de valamin mindegyik elhasalt. Maradt a hardveres loadbalancer, mint egyetlen szóbajöhető megoldás. Igaz ugyan, hogy ez nem autentikál és nem foglalkozik túl sokat a használt protokollok ellenőrzésével, de egyfajta packet filter tűzfal és persze forgalmat oszt.
A Microsoft a TMG kinyírása után hosszú ideig nem mondott semmt. Háát, izé… majd csak lesz valahogy.

A héten indult el egy sorozat az Exchange blogon, ahol immár részletesen körbejárják a lehetőségeket.

Az első írást Greg Taylor követte el és általánosságban járja körül a helyzetet. Hogy kell-e egyáltalán protokollszűrés és előautentikáció? Az nyert, aki arra tippelt, hogy immár nem kell. Természetesen kiosztja a fejlődésben elmaradt szekuritis embereket, sőt, tippeket ad, miket mondjon nekik az Exchange adminisztrátor, ha kötekednének. Ezzel túl sokat nem akarok foglalkozni, számomra a kulcs mondanivaló az, hogy már az MS sem használ preautentikációt a felhőiben – ellenben használ IDS-t. (Gondolom, itt némi slendriánság forog fenn, hiszen IPS-nek valamivel több értelme lenne.)
Illetve, mégis. Greg írja, hogy a CAS már DMZready, azaz nyugodtan mehet rá autentikálatlan forgalom. Oké, de mi van akkor, ha van rajta Mailbox szerepkör is? Mert szép az, hogy négy Exchange szerverrel meg tudjuk oldani a terheléselosztást, de a legtöbbünk azon sportol, hogy maximum két szerver van. Ekkor viszont nagyon hiányzik a TMG.
A lényeg, hogy a szerző bemutatja a versenyzőket: kiket küld a ringbe a Microsoft? Az egyik az ARR (Application Request Routing) – legalább annyira hülye név, mint az ISA vagy TMG, szóval a vonulat megvan – a másik a WAP (Web Application Proxy). Az első egy loadbalancer, a második már egy autentikálni is képes eszköz, igaz, ez csak OWA-t képes publikálni. (És persze kitart még az UAG is, de azt az Exchange esetében jobb hanyagolni.)
Még valami. Most nem kerestem utána, de nekem úgy rémlik, hogy az ARR eredetileg nem támogatta az Exchange-t. Jó látni, hogy most már igen.
Life in a Post TMG World

A második cikkben – mely egy háromrészes sorozat első írása – B. Roop Shankar kezdi el kivesézni, mi is ez, hogyan is működik ez a bizonyos ARR. Nagy vonalakban: ez egy IIS-be épülő modul. A trükkje az, hogy ismeri – és proxyzni is tudja – azokat a Microsoft által megerőszakolt protokollokat, melyeket más webproxyk nem tudnak. Természetesen képes több szerver között terheléselosztásra is.
Egy résznél jót vigyorogtam.

Then click on “Edit Feature Settings” and change the settings for “Maximum allowed content length” to the below.

Azaz a bűvös szám: 2147483648, azaz 2 a 31-ediken. A legtöbb, mi adható.
Vesdd össze ezt az alábbi idézettel, innen:

(Update 17 Apr 2012: Looks like there’s a content-length encoding disagreement between Microsoft and Apache that breaks Outlook anywhere.)

De ez is érdekes írás. Hogy miért is olyan fontos az a content length. Cuki. Hibakódot a ‘bytes’ mezőben küldeni. Ennyit a szabványokról.

Még egy észrevétel. Az ARR Vistától a Windows Server 2012-ig minden IIS-be belerakható, és ez jó. Amit nem tudok, az az, hogy képes-e korábbi Exchange szervereket is publikálni. (A cikk csak a 2013-assal foglalkozik.) Elméletileg működnie kellene, de nálam a nappali fala karón varjúkkal van kidekorálva: én már csak akkor hiszek el valamit, ha explicit leírva látom. (Pedig gugliztam, de így sem egyértelmű a helyzet.)
Reverse Proxy for Exchange Server 2013 using IIS ARR – Part 1

CAS Array 03/03 – Exchange 2013

2013-06-14 / / 9 Comments

Ez elméletileg a világ legrövidebb cikke lehetne: az Exchange 2013-ban nincs CAS Array. Pont.

De nem ússzuk meg ennyivel. Hiszen a CAS Array funkcionalitása hasznos volt. Valahol kell lennie valami hasonlónak.

Mindenekelőtt vizsgáljuk meg az előző írásban feltett két kérdést.

  1. Ha minden RPC forgalom RPC over HTTPS formában menne, szükségünk lenne-e marha drága loadbalancer készülékekre?
    A válasz egyértelműen az, hogy nem. A loadbalance algoritmus a layer7-ről lecsúszna a layer4-be, ott pedig már elboldogul egy sokkal olcsóbb reverse webproxy is.
  2. Át lehet-e terelni minden RPC forgalmat RPC over HTTPS-re?
    Ez már fogósabb kérdés. Mi dönti el, hogy az Outlook melyik metódussal próbálkozik? Gyakorlatilag a sikertelenség. Ha beállítjuk az Outlook profilunkban a belső szerver/CAS Array elérhetőségét, majd megadunk hozzá egy proxy szervert is, akkor az Outlook először megpróbálja RPC over TCP protokollon keresztül elérni a belső szervert. Ha a belső hálón van, akkor ez valószínűleg sikerül is neki. Ha a külső hálón van, akkor jó eséllyel nem. (Ha csak el nem konfigurálod.) Ilyenkor vált át RPC over HTTPS-re és támadja meg a proxyként megadott címet.
    Látható, hogy ha csak külső felhasználóink vannak, akkor a probléma megoldható. De ha már van belső felhasználónk is, akkor az először a belső címre próbálkozik, RPC over TCP-vel. Nyilván ezt blokkolhatjuk, vagy a CAS Array IP címének beállíthatunk valami marsbéli IP címet is – de ezekért súlyos timeout-tal, közvetve pedig felhasználói elégedetlenséggel fizetünk. Mivel az Outlook elsősorban a sima RPC-t favorizálja, így a belső hálón nem ússzuk meg a loadbalancert.

Itt jön be a képbe az Exchange 2013. Ebből ugyanis kidobták az RPC over TCP protokollt.
Elég markáns megoldása a problémának, nem mondom. Ezzel ugyanis teljesen megváltozott a leányzó fekvése. Mivel az Exchange 2013 CAS nem fogad el RPC over TCP-t, marad az RPC over HTTPS. Ez pedig már webes protokoll, melyet minden további nélkül tudunk loadbalancolni a Linux szerverünkkel. Aztán gondoljuk tovább: szükségünk van-e még az adatbázisok RPCClientAccessServer változójára? Miért lenne? Az Outlook már nem innen fogja megtudni a CAS szerver nevét. Ezért nincs szükség magára a CAS Array objektumra sem.
Ha nem innen, akkor viszont honnét? Hát az Autodiscover szolgáltatástól, mint minden más normális webes elérés az Exchange-ben. Az Outlook Anywhere szolgáltatásnak is lesz internalhostname és externalhostname paramétere, ahol az internalhostname mondja meg, melyik szervert kell támadnia bentről az Outlooknak.
Ismerős?
Na, ebből a névből lehet CAS Array-t faragni. Létrehozunk egy bejegyzést a DNS-ben, a megszokott outlook.cegnev.local névhez. Ez lehet egy kitüntetett CAS szerver IP címe, lehet DNS round robin formában az összes CAS szerver IP címe és természetesen lehet ez a reverse proxy szerverünk “külső” IP címe is. Aztán egyenként átírjuk az összes CAS szerverünkön az internalhostname paramétert erre a névre.

A CAS Array esetében láttuk, hogy kulcsfontosságú volt, mikor hoztuk létre. Jelen esetben ez már nem annyira lényeges. Amint átírtuk az értéket, az Autodiscover véges időn belül észleli a változásokat és szét is küldi.

CAS Array 02/03 – Amikor kezd bonyolódni az élet

2013-06-12 / / 3 Comments

Nos, nézzük meg alaposabban, mi is történik a különböző RPC kapcsolatok esetén, ha már van CAS Array objektumunk és rendesen be is lett állítva mind az adatbázisokban, mind az Outlook profilokban.

1. Sima RPC over TCP

From Segédlet

Ez egy viszonylag egyszerű eset. Van egy CAS Array, mondjuk outlook.cegnev.local. (Javasolt best practice.) Ennek az IP címét a DNS-ben úgy állítjuk be, hogy az egyik CAS szerverre, jelen esetben a CASy-ra mutasson. Az Outlook profilban az outlook.cegnev.local név szerepel, így az RPC kérés elmegy a CASy-ra, ott az MSExchangeRPC szolgáltatás a felhasználó MDBHome értéke alapján megkeresi, melyik Mailbox szerveren van éppen az aktív adatbázisa, és már proxyzza is a kérést.

2. Magas rendelkezésreállású RPC over TCP

From Segédlet

Magas rendelkezésreállás. Csináltunk DAG-ot, van több DC-nk, mind a hardverek, mind a network eszközök redundánsak. Most már csak az Exchange elérésének kellene annak lennie. Az RPC kommunikációt kétféleképpen tehetjük azzá:

  • Windows Load Balance Service, magunk között csak WLBS.
    Felejtős. Anyira, hogy a Microsoft sem ajánlja. Ha érdekelnek a részletek, akkor a legnagyobb hiányossága az affinitás. Pontosabban a hiánya. Csak akkor hagy figyelmen kívül egy node-ot, ha az már IP szinten sem érhető el. Exchange esetében van még egy durva hátrány: a failover cluster és a WLBS nem fér el egy gépen, tehát a korrekt megoldás még két Windows és még két Exchange licenszbe kerülne.
  • Hardware loadbalancer
    Ennyi pénzért már korrekt hardveres loadbalancer kapható. Ez ügyes, okos, mindent tud.

Tehát betettük a loadbalancer clustert a belső hálózatunkba. Cluster, mert ugye magas rendelkezésreállás. Belső háló, mert az RPC csak ott van értelmezve. Jól is néznénk ki, ha kintről is jönnének RPC kérések.
A CAS Array IP címe egyben a loadbalancer cluster virtuális IP címe. A kliensről ide érkezik be a kérés, a loadbalancer pedig a beállított konfigurációja alapján továbbítja a kérést valamelyik CAS szerver felé. Jelen esetben ez megint a CASy. Onnantól minden megy ugyanúgy, mint az előző esetben.

3. RPC over HTTPS

From Segédlet

Eddig beszéltünk a belső hálózatról. De mi van azokkal, akik valamilyen okból kifolyólag kívülről szeretnék elérni a postafiókjukat? Outlookból?
Erre találták ki az RPC over HTTPS-t. Az Outlook kliensben megadom az elérendő belső címet (outlook.cegnev.local), de mellette megadjuk a DMZ-ben elrejtett reverse proxy kinti nevét is. (Ez simán lehet egy mezei virtuális Linux egy akármilyen webszerverrel.) A reverse proxy tudja, hogy a kívülről jövő HTTPS kérést – mert ő csak ennyit lát belőle – melyik belső webszerverre kell dobnia. (Megjegyzem, itt már remekül lehet affinitást is konfigurálni – de webproxynál csak webes protokollokra működik.) A fenti ábrán a CASx webszervert választotta. A CASx terminálja a HTTPS csatornát. Itt bújik ki belőle az RPC és nekiáll keresni a CAS Array-t. A DNS vissza fogja dobni neki a beállított IP címet, a kérés továbbpattan, majd onnan megy minden, mint korábban.

4. Magas rendelkezésreállású RPC over HTTPS

From Segédlet

Ha már van egy loadbalancer készülékünk, mely az Exchange szerverek RPC szolgáltatásait proxyzza, simán használhatjuk arra is, hogy ugyanezen szerverek webszolgáltatásaival is megtegye ugyanezt. (Sajnos a Linux szervert nem tudjuk használni RPC proxyzásra, mert az már layer7.) Ettől persze egészen érdekes lesz a táncrend. A loadbalancer VIP címe van kiforgatva a külvilág felé, ide érkezik be a HTTPS forgalom. Az eszköz a HTTPS loadbalance paraméterek szerint dobja tovább a kérést egy tetszőleges CAS szervernek, ez megint a CASx. A CASx terminálja a HTTPS forgalmat, kibújik az RPC, keresi a CAS Array-t – mely jelen esetben megint a loadbalancer VIP címe. Viszont ekkor már RPC forgalomról beszélünk. A forgalom az RPC loadbalance szabályok szerint megy tovább, immár a CASy-ra, ahonnan már ismerjük a mókát.

Hogy tetszik?
Mert nekem nem túlzottan. Az utolsó két ábra olyan, mint egy Klampár-Jónyer pingpongmeccs. Muszáj ekkora adok-kapokba belemennünk?
Nem. Az MSExchangeRPC szolgáltatás képes arra, hogy megtalálja a rövidebb utat az erdőn keresztül.
De ehhez durván le kell szarnia az etikettet.
A valós működés az, hogy abban a pillanatban, amint egy CAS szerver kap egy proxyzandó kérést, mindent félretéve megpróbálkozik maga elérni az illetékes Mailbox szervert. Amennyiben ez sikerül, akkor a kérés már nem pattog tovább.

Tessék ezen egy kicsit elgondolkodni. Az utolsó két ábráról egyből látszik, hogy hülyeség. Valótlan. Már a CASx szerver megpróbálkozik elérni a Mailbox szervert és amennyiben sikerül neki, akkor a többi elem nem játszik.
Konkrétan letojja, hogy van-e CAS Array és mi a konfigurációja. Megpróbálja elérni a Mailbox szervert, és ha sikerül, akkor sínen vagyunk. Sőt, a sima RPC over TCP kapcsolatoknál sem foglalkozik egyik CAS szerver sem a CAS Array objektummal. Tőlük fel is fordulhat.

Fogadok, most összezavarodtál. A cikkek lényege éppen az lett volna, hogy megmutassam, mennyire fontos dolog ez a CAS Array objektum. Aztán kiderül, hogy a kutya sem használja. Írtam két hosszú cikket, ábrákat rajzoltam… majd kinyírtam a főhőst, mintha egy Trónok Harca szereplő lett volna. Ennek mi értelme?

Jó, pihenjünk meg egy kicsit.

Ha már lehiggadtunk, észre fogjuk venni, hogy tulajdonképpen minden rendben van: az MSExchangeRPC szolgáltatás akkor önállóskodik, amikor a kérés már elérte a CAS szervert; a CAS Array pedig arra szolgál, hogy a kliens elérje az első CAS szervert. A CAS Array nem tehet arról, hogy az RPC over HTTPS egy reverse proxyn keresztül jön be és már ez a proxy megmondja, melyik CAS szervert kell elérni. Az RPC over TCP protokoll esetében meg természetes, hogy a CAS szervereket nem érdekli a CAS Array: nem nekik találták ki. A CAS Array objektumot a MAPI kliensek használják.

Viszont ajánlanék a figyelmedbe két töprengenivalót.

  1. Ha minden forgalmat sikerülne RPC over TCP helyett RPC over HTTPS-re terelni, akkor szükség lenne-e a magas rendelkezésreállás biztosításához a drága loadbalancer cuccokra? Nem lenne-e elég helyettük az ingyenes Linux reverse proxy?
  2. Meg lehet-e oldani, hogy minden kliens forgalom RPC over HTTPS-en keresztül menjen?

CAS Array 01/03 – Alapozás

2013-06-09 / / 2 Comments

Már régóta terveztem írni egy részletesebb cikket az Exchange 2010 CAS Array működéséről, mert úgy tapasztaltam, hogy még a legprofibbak fejében sem tiszta teljesen a kép.

Kezdjük rögtön a fogalom tisztázásával. Sokan az ‘array’ névből egyből magas rendelkezésreállásra gondolnak, és összekeverik a loadbalance megoldásokkal. Hiba. Nagyon pongyola megfogalmazással a loadbalance feladata a kliens kérését egy adekvát szerveren futó szolgáltatás felé irányítani, míg a CAS Array feladata… tulajdonképpen ugyanez, de nagyon nem mindegy, mit értünk adekvát szerver kifejezés alatt, hol történik meg az irányítás… és természetesen terheléselosztásról szó sincs.

Mielőtt teljesen belebonyolódnék, kezdjük el boncolgatni az Exchange 2010 kliens oldali hozzáféréseit.
Vannak a tiszta webes hozzáférések. Ezekről túl sokat nem kell magyarázni, mindenki látott már webszervert, webes szolgáltatást. Aztán van az RPC over TCP, azaz a klasszikus MAPI. Ezt használja a vastag kliens – Outlook – de léteznek más külső alkalmazások is, mint például a Blackberry szerver. Ez nagyon nem webes hozzáférés: alaphelyzetben több tízezer port közül választhat kapcsolatonként egyet, illetve kell neki a 135-ös, ahol az endpoint mapper azt mondja meg, melyik is lett kiválasztva. (Szerencsére ez az egész konfigurálható, de jelen sorozatban ezzel nem foglalkozok.) Az Exchange-ben létezik az RPC-nek webre erőszakolt verziója is, az RPC over HTTPS, azaz az Outlook Anywhere. Itt az RPC forgalmat HTTPS csatornába gyömöszölték, így lett belőle webes adatforgalom.

Foglalkozzunk most egy kicsit részletesebben ezzel az RPC-vel. A 2010-es verzióban az RPC over TCP elérésben nagy változás történt: az Outlook kliensek immár nem közvetlenül a Mailbox szerverre kapcsolódnak, hanem egy baráti CAS szerverre, mely proxyzza az RPC kérést a Mailbox szerver felé. Innentől lesz érdekes a dolog. Honnét tudja az Outlook, hogy ki az a baráti CAS szerver, aki valószínűleg el fogja tudni érni a Mailbox szervert?

Amikor létrehozunk egy adatbázist, akkor annak az RPCClientAccessServer változójába beleíródik egy név. Ha magán a szerveren fut CAS szerepkör is, akkor a saját neve, ha nem, akkor az Exchange keres egy közeli, RPC-n elérhető CAS szervert és annak a nevét írja bele. Ez lesz az a CAS szerver, aki proxyzza a kérést az adott adatbázis felé.
Amikor a felhasználó létrehoz egy Outlook profilt a gépén, akkor az történik, hogy az Outlook kiolvassa, melyik adatbázisban van a felhasználó postafiókja, majd megkeresi ennek az adatbázisnak az RPCClientAccessServer értékét – és erre a szerverre állítja be a profilban a kapcsolódást.
Ez szépen működik is addig, amíg az a bizonyos CAS szerver elérhető. De mi van akkor, ha ledől? Az Outlook továbbra is a profilban lévő CAS szervert fogja ostromolni – sikertelenül. Hiába létezik másik CAS szerver és hiába tökéletesen egészséges az adatbázis, a felhasználó nem fér hozzá a postafiókjához.

Akár külön cikkben is lehetne részletezni, hogy mikor, mi történik. A pontos forgatókönyv csak a következőktől függ: az Exchange verziója, service pack száma, rollup pack száma, hány AD site-on vannak Exchange szerverek, használunk-e DAG-ot, loadbalancer-t, reverse proxy-t, vannak-e public foldereink és nem utolsósorban, milyen verziójú Outlook-ok vannak a cégnél.

Maradjunk annyiban, hogy ilyen esetben kisebb-nagyobb kényelmetlenségek történhetnek, melyek között szerepel az elérhetetlenség is.

Ennek a szituációnak az elegáns kezelésére találták ki a CAS Array-t.

A CAS Array egy meglehetősen absztrakt objektum az Active Directoryban. Van neki neve, FQDN értéke és egy listája, hogy mely CAS szerverek tartoznak bele. Ez egy AD site szintű objektum, azaz automatikusan a site-on belüli összes CAS szerver tagja lesz. A létrehozását nem fogom leírni, tele van ilyesmivel a net. Arról, hogy az FQDN értelmezhető legyen, nekünk kell gondoskodnunk, azaz létre kell hozni hozzá egy DNS bejegyzést.

Innentől kezdve ha kreálunk egy új adatbázist, akkor annak az RPCClientAccessServer értéke a CAS Array neve lesz. A MAPI kliensek a CAS Array nevét kapják meg. Itt jön be a képbe a DNS. A CAS Array IP címe magas rendelkezésreállású környezetben lehet a loadbalancer IP címe, egyébként pedig lehet egy általunk kiválasztott CAS szerver IP címe.
Nézzük, mi történik most a korábban vázolt példában. Azt mondtuk, hogy a Mailbox szerveren nincs CAS funkció, ezzel szemben van több különálló CAS szerverünk. Ha kidől az egyik, akkor semmi gond sincs, a DNS-ben átírjuk a CAS Array IP címét a másikra. Életszagúbb példa, hogy teszem azt, lecseréljük a CAS szerverünket. Megint csak elég átírni az IP címet a DNS-ben. A kliensek mindkét esetben gond nélkül veszik az akadályt, hiszen nem kell módosítani a profiljukban semmit. (Természetesen ezek a szituációk kezelhetőek CAS Array nélkül is, de sokkal nyögvenyelősebben. Természetesen a korábbi kiemelés megjegyzései most is érvényesek.)

Még egy apróság: a régi, azaz a CAS Array létrehozása előtti adatbázisokban az RPCClientAccessServer értéke nem változik meg magától, itt manuálisan kell módosítanunk. Hasonlóképpen a már létrejött Outlook profilokban sem történik meg magától az átállás, ehhez különféle varázslások kellenek. (Nem mindig, és nem minden varázslás működik minden esetben, de ebbe most megint ne menjünk bele.) Ezért szokták azt mondani, hogy Exchange 2010-es környezetben az első dolgunk legyen létrehozni a CAS Array-t, még azelőtt, hogy a kliensek hozzákapcsolódnának. (És persze a default adatbázisban írjuk át manuálisan az értéket.) Ezt célszerű megtenni még akkor is, ha nem foglalkozunk magas rendelkezésreállással, hiszen nem tudhatjuk, mit hoz a jövő, és a legótvarabb munka egy Exchange organizáció átvariálásakor a kilensek átkonfigurálása.

Mit fogunk ekkor látni? Ha megnézzük az Outlookban, akkor azt, hogy a kliensünk mind a webes kapcsolódásokban, mind az RPC-ben immár a CAS Array nevet használja, azaz azt az IP címet fogja támadni, amit mögé tettünk. Innentől bármikor nagyon könyen tudjuk terelni a forgalmat.

Két megjegyzés:

  • A fenti állítás nem teljesen igaz. A Public Folderek RPC elérése nincs proxyzva, tehát ott, ha mandinerből is, de a Mailbox szervert támadja a kliens.
  • Bárkiben felmerülhet az ötlet, hogy hoppá, itt olcsón lehet magas rendelkezésreállást létrehozni: a DNS-ben round robin módon felveszem ugyanarra a névre az összes CAS szervert. Ez jó addig, amíg mindegyik CAS szerver működik, de ha bármelyik ledől, arról a DNS nem fog tudni és simán kiadja a nem elérhető címeket is a hozzá fordulóknak.

Ennyi volt az alapozás. A következő írásban némileg mélyebben beleásunk a különböző RPC kapcsolódásokba, megvizsgáljuk, hogyan befolyásolja mindezt a loadbalancer, illetve a HTTPS csatornázás.

Copy/Paste a mi barátunk

2013-05-09 / / 0 Comments

Jelenleg egy Exchange 2013 alapú hosting infrastruktúra tervezésével foglalkozom. Mint kiderült bizonyos dolgok kikerültek a grafikus management felületből a korábbiakhoz képest. Például nincs OAB reszelés a felületen. A vége az lett, hogy nagyjából mindent PowerShell-ből kell megcsinálni. Ennek kapcsán az ember olvasgatja a helpet. Részletek különböző parancsok helpjeiből:

Get-Help New-DynamicDistributionGroup -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Get-Help New-AddressList -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Get-Help New-GlobalAddressList -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Tombol a copy/paste, ellenőrzés nélkül. Nyugi, ez már a 2010-ben is pontosan ugyanígy van a helpben.

Óvatosan az adatbázissal

2013-04-30 / / 1 Comment

Ez érdekes. Őszintén szólva, még nem merültem el a 2013-as Exchange rejtelmeibe, pedig már itt van az sp1 a cu1, lassan lehetne. Egyelőre inkább csak olvasgatok.
Például ezt az írást. Paul Cunningham emel ki egy első látásra meghökkentő mozzanatot az Exchange 2013 lelkivilágából: ha létrehozol egy mailbox adatbázist, akkor a cu1 utáni Exchange már figyelmeztet, hogy légy olyan kedves, indítsd újra az Information Store szolgáltatást. Ez, mint tudjuk, az összes adatbázis le- és visszacsatolását jelenti, azaz kemény szolgáltatáskiesést.

Azért ez megérdemel egy ‘ejha!’ füttyentést.

Aztán jön a magyarázat és ettől már valamivel érthetőbb lesz a helyzet, különösen, mivel kedvenc sorozatszereplőm, Scott Schnoll is feltűnik a darabban. Arról van szó, hogy a 2013-as Exchange (már az RTM is, csak az nem figyelmeztetett) nem egy az egyben foglalja le a memóriát az Information Store-nak, mint a korábbi verziók, hanem adatbázisonként. Azaz ha megjelenik egy új fiú a játszótéren, akkor mindenkinek abba kell hagynia a játékot, majd az IS újrakezdéskor igazságosan újraosztja az erőforrásokat.

Ettől persze még meredek volt így megoldani a problémát, de szerencsére tényleg nem olyan sűrűn szoktunk adatbázisokat létrehozni. Innentől pedig már csak a szervízhétvégéken fogunk.

ps.
A DAG üzemeltetőknek egy fokkal jobb a helyzetük, ók egy switchover/switchback párossal megúszhatják a leállást.

Exchange 2013 Setup + EAC

2013-04-19 / / 5 Comments

Nekiálltam az Exchange 2013-ra való átállásnak.

Miután az első 2013-as szerver nem abba a site-ba kerül ahol a schema master van, így a schema master site-jában kezdek neki, parancssorból a dolognak (PrepareSchema, PrepareAD, PrepareDomain)

2012-es member gép (ez sosem lesz Exchnange szerver):

Hisztizik, hogy RSAT AD DS kellene neki. Az nincs, ezen a gépen nem is lesz. Válasszunk mást.

2008 R2 DC, minden FSMO role tulajdonosa:

Hisztizik, hogy kéne neki egy .NET 4.0 – Ez átverés, a release notes-ból kiderül, hogy tulajdonképpen 4.5 kell neki. Nem ugrom be, felrakom a 4.5-öt

Kéne még egy Management Framework 3.0. Felrakom.

Ezek után lefutnak a szükséges dologk.

Csak azt tudnám, melyik idióta gyártott ilyen KÖTELEZŐ parancssori kapcsolót: /IAcceptExchangeServerLicenseTerms

Azt hiszem, ha az open világban valaki elkövetne egy hasonlót, keresztbe nyelné le a közösség.

Aki már egy kicsit utánanézett az Exchange 2013-nak az tudja (aki nem azt majd telepítés után fogja képen vágni), hogy az MMC alapú Exchange Management Console-nak vége, meghalt, eltemették.

Ami helyette van az a web alapú Exchange Administration Center.

Hosszas várakozás (2010 SP3, 2013 CU1) és némi küzdelem (Schema Upgrade másik site-on, millió tonna Windows Server Role, Feature, külön letöltendő telepíőkészlet, hatszáz újraindítás) árán sikerült a saját Exchange 2010-es infrastruktúrámba (homokozó) felraknom az első Exchange 2013-at.

A telepítő gyorsan meg is kérdezte, hogy akarom-e elindítani az Administrative Centert.

Akartam. Beléptem. Magyar.

Hogy az a…

Utálok magyarul szervert adminisztrálni.

Miért?

Nem, nem beszélek jobban angolul mint magyarul. Nem, nem felvágós úri hóbort. Hanem:

Ha valami bajom van, a magyar hibaüzenetekre, problémákra kb. 0 megoldást találok a neten.

Ok. Állítsuk át angolra:

Első ötlet: Átállítom az Internet Explorert angolra. Ez magyar, mert az operációs rendszer nyelve ugyan angol, viszont a területi beállítások magyarok, elsősorban a billentyűzet miatt. (Ez az átállítás sem egy matyóhímzés mióta az IE nyelvi beállításait integrálták a control panellel: Win8/IE10)

Kilépek az EAC-ból, becsukom az IE-t.

Megpróbálom elindítani az EAC-ot újra. Csempét nem gyártottak hozzá a start menűbe. Az IE history-ban sincs (vajon miért?). Google.

Kiderül, hogy a cím megyegyezik a 2010 ECP-vel. (https://server/ecp)

Bepötyögöm, belépek, kapok egy 2010-es OWA login ablakot. Mi vaaan?

Megpróbálom a gép összes lehetséges címével (loclhost, FQDN, IP). Mindre ugyanazt kapom vissza.

Google.

Kiderül, hogy abban az esetben, ha a mailbox még a 2010-es szerveren van akkor belépés után átirányít. Ez kikerülhető, ha így: https://server/ecp?ExchClientVer=15 adjuk meg a címet.

Sikerül. Belépek. Magyar.

Gondolkoz. Nézzük meg a postaláda nyelvét.

Belépek a 2010-es OWA-ba, kiderül, hogy magyar. Ok. Átállítom angolra.

IE becsuk, újra kinyit, EAC-ba belép. Magyar.

Get-MailboxRegionalSettings: látszik, hogy angol.

Vajon ez a beállítás honnan jön? AD.

Hopp. Nem azon a site-on van a 2013 mint a felhasználói postaláda 2010-e.

Get-MailboxRegionalSettings -DomainController <Exchange 2013 site DC>

Itt is angol.

Mi van, ha már lefutott a replikáció.

IE kilép, IE belép, EAC: Angol. – véééégre.