CategoryISA/TMG

Kemp, az új TMG 05

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

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

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

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

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.

UAG kampec

A funkcionalitását beleépítik a WAP-ba. A támogatása – a TMG-hez hasonlóan – még él egy darabig, de a halállistára már felkerült.
Részletesen: link.

Élet a TMG után

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

Együtt működés

Ügyfél úgy érezte, itt az ideje, hogy felrobbantsa felújítsa az informatikai rendszerét. Előbb-utóbb sor került a levelezésre is. A következő peremfeltételek szorongatták a projektet:

  • A telepített rendszernek a meglévőnél robusztusabbnak kell lennie. (Ezt nem volt nehéz megígérnünk.)
  • Licenszelési szempontból támadhatatlannak kellett lennie. Ez egész konkrétan azt jelentette, hogy mivel a felhasználók számához képest egynyolcadnyi Windows és Exchange CAL állt rendelkezésünkre, a többieknek valamilyen alternatív, de valamelyest igényes levelezést kellett biztosítanunk. (A maradék 7/8 egyébként laptopos-bolyongós külsős ember.)
  • Természetesen mindenki ragaszkodott hozzá, hogy mindenhonnan elérje a levelezését, minimum webes felületen és mobiltelefonon. Nyilván az utóbbit push metódussal.
  • A cégnek egy darab publikus IP címe van. A határon egy Cisco eszköz kezeli le a forgalmat.
  • A költségkeret adott volt. Emiatt fel kellett használnunk a korábbi licenszeket, így is éppenhogy maradt csak valami zsé új hardverre és licenszekre.
  • A meglévő rendszerhez képest Augeias istállója chipgyár tisztasággal bírt. Természetesen úgy kellett elvégezni az átalakítást, hogy minél kevesebb fennakadás legyen.
  • Függetlenül attól, hogyan oldjuk meg a levelezést, az összes alkalmazottnak ugyanazt a névteret – @cegnev.hu – kellett használnia. Egymás között is.
  • A meglévő levelezés nem veszhetett el, át kellett kerülnie az új levelezőszerverekre. Szerencsére public foldert nem használtak.

Hosszas tanakodás után egy Exchange-Zimbra kooperáció mellett döntöttünk. Zimbra esetében nyilván az Open Source Edition jöhetett csak szóba. A webes elérés evidens volt, a mobilokhoz pedig jó lesz a Z-push.
A router mögé egy ISA 2006 SP1 került. Sokat nem válogathattunk, ehhez volt licensz. Első elképzeléseink szerint majd ez osztja szét jól a https forgalmat.
Ja.

A TCP/IP-ből következően egy socketre (IP:port) csak egy listenert tudunk rakni. A HTTPS működéséből következően egy website-hoz csak egy tanúsítványt tudok hozzárendelni. Eddig oké.
Csakhogy az ISA belekeverte a mókába az autentikációt is, méghozzá listener szinten. Azaz ha olyat akarsz csinálni, hogy egy IP címen fogadsz a 443-as porton különböző belső szervereknek szánt forgalmat (a tanúsítvány SAN vagy wildcard), és ezek a belső szerverek háklisan autentikálnak… akkor nagy bajban vagy. Mert a listener autentikál. Pontosabban, meg lehet neki mondani, hogy ne autentikáljon, de ekkor senkinek sem autentikál és ráadásul még ez sem igaz… de erről majd később.

Akkor nézzük, miből élünk. Egy külső IP címünk van, azaz a socketből már csak a porttal tudunk játszani. Tudnánk. Csakhogy az Android alap Activesync kliense – legalábbis a Samsung telcsiken – nem enged portszámot beírni. Mivel a külsősök között informatikus még csak elvétve sincs, szóba sem jöhet, hogy letöltetünk velük valami appot. Ha létezik egyáltalán jó ingyenes. Tehát a Z-push és az Exchange ActiveSync (EAS) https forgalomnak ugyanazon a porton kell bejönnie, azaz ugyanaz a listener kell, hogy lekezelje. Ugyanazzal az autentikációval. Fincsi. (Nagyjából igaz ez a webes elérésekre is. A felhasználó kiszalad a világból, ha ilyen címet kell megjegyeznie, hogy https://exchange.cegnev.hu:50443/owa.)

Oké, nézzük, be tudjuk-e gyötörni egy autentikáció alá ezt a négy forgalmat. Az OWA és az EAS berakható, jelenleg is így működik. A listener FBA-t használ, azaz formon keresztül bekéri a credential adatokat, valamelyik DC-ről autentikál, az autentikáció delegáció basic, azaz http/basic autentikációval dobja át a credentialt az Exchange szervernek. Mivel az egész kommunikáció HTTPS alatt megy, így a basic nem probléma. Viszont, mivel az autentikációt – beleértve az autentikáló szervert is! – a listenerben állítjuk, a Zimbra esetében gond lesz. Lehetne úgy persze, hogy a Zimbra felhasználókat felvesszük az AD-be, majd onnan autentikál a levelezőszerver – de ez már Windows CAL. Az meg nincs.

From Segédlet

Mik a szóbajöhető opciók? Domain, egyéb AD, Radius. Az első kapásból kiesik. A másodiknál fel kellene húzni egy Samba szervert a Zimbrán, a harmadiknál pedig kellene egy-egy Radius szerver mind a Windows tartományba, mind a Zimbra mellé. (Ez egy külön szépség a listener struktúrában. Egy listener csak egyféle autentikációt ismer. Habár azt meg tudom csinálni, hogy a bejelentkezéskor megadott domainnév alapján más és más Radius szerver autentikáljon, de azt nem, hogy a bejelentkezéskor megadott domainnév alapján az egyik esetben Windows LDAP tartományból, a másik esetben külső Radiusból autentikáljon.)
Na jó. Kérdés a linuxos kollégához: meg-e lehet-e oldani? E? Fejcsóválás. Ha sima postfix lenne, akkor menne, de a Zimbra ennél kompaktabb cucc. Ha a megkerülésével piszkálnak bele az alatta lévő dolgokba, azok nem maradnának ott állandóan.

Jó. Ez az irány nem működik. Az Exchange autentikációs beállításai nem jók a Zimbrának.

From Segédlet

Akkor mi a jó? Nem húzom az időt, egyfajta beállítással tudtam csak átgyömöszölni a Zimbra forgalmát: a listeneren kikapcsoltam az autentikációt, a szabályban pedig az autentikáció delegálásánál azt adtam meg, hogy a kliensek a célszerveren közvetlenül autentikálnak. Ekkor feljött a Zimbra FBA autentikációs képernyője. Ez ugyan nem öröm, hiszen általánosságban azért csak jobb az, ha már a tűzfal lerendezi az autentikációt, de ez van. Igenám, de jó lesz-e ez az Exchange-nek? Elméletileg jó lehet. A nagykönyv szerint, ahogy korábban is írtam, az a helyes beállítás, ha a listeneren form-based autentikációt állítunk be, a szabályban a delegálásnál basic autentikációt, az Exchange szerveren pedig szintén basic-et. (A tanúsítványokról most nem értekeznék külön. Az se volt egyszerű kör, de végül mind a két rendszert befaragtuk ugyanazon CA alá.) Ezt a konfigot rúgtam fel, úgy, hogy beraktam az autentikáció nélküli listenert, a szabályban átírtam a delegálást közvetlenre, az Exchange szerveren meg engedélyeztem az FBA-t. Bentről szépen működött is – kintről viszont azt kaptam vissza, hogy a szerver elzárkózott a kapcsolat elől. Jött némi vajákolás, engedélyeztem az FBA-t közvetlenül az Exchange IIS alatt is az OWA könyvtáron, de nulla eredménnyel. Megnéztem az ISA logot – és jó magasra felugrott a szemöldököm. Beérkezik kintről a https, az ISA terminálja… majd az Exchange felé már http-n megy tovább, mely próbálkozást az Exchange – jogosan – undorral dob el. De miért? A szabályban a bridging fül alatt nincs engedélyezve a http. Akkor ezt most hogyan? Ellenteszt. Visszaállítottam mindent, rögtön https-sel próbálkozott az ISA, az Exchange pedig elfogadta. Furdalt a kiváncsiság, megnéztem az itthoni tesztrendszeremben ugyanezt TMG-vel – és ugyanez lett az eredmény is. Fura. Ha azt mondom a TMG-nek, hogy ne erőlködjön az autentikációval egy linux szerver felé, akkor nem is variál… ha viszont ugyanezt mondom neki egy Exchange szerverrel kapcsolatban, akkor átvált http-re, még akkor is, ha ez nincs neki engedélyezve.

Nos, ennyi volt a történet. Szomorú sóhajjal arrébb rúgtam az ISA szervert és betettünk elé egy Apache proxyt. Ez ugyanis nem tűzfal, de nem is fenyegetés elleni gateway, azaz nem foglalkozik az autentikációval. Terminálja a HTTPS kapcsolódást, a host header alapján tudja, milyen irányba kell továbbdobnia a kérést, immár egy új HTTPS kapcsolattal. Azaz az OWA és EAS mehet az ISA egyik hálókártyájára, a klasszikus listenerrel, a Zimbra forgalma meg mehetne az ISA másik lábára a ‘ne nyúlj hozzá’ listenerrel. (Azért használtam feltételes módot, mert a linuxos vonalnak nem ez lett a vége, de így is lehetett volna.)

Megjegyzem, ha az ISA tudná az SNI-t (Server Name Indication), akkor még sokkal egyszerűbb lenne a dolog, akkor már a HTTPS terminálása előtt tudná a megcélzott host nevét, és ennek alapján ő maga tudna forgalmat szeparálni. De nem tudja. (Talán az UAG. De azt nem ismerem.)

Tulajdonképpen ezzel a webes eléréseket lerendeztük. Az SMTP, na az szintén jó móka volt, de most hagyjuk. Ugyanis hátravolt még egy publikáció: egy belső RDS szerver alkalmazásait is ki kellett publikálnunk a külsősök felé. RdWeb, RDGW. Csakhogy: 1 IP cím. Az RDGW pedig ugyanazon a 443-as porton szeretne nyomulni, amelyiken már így is nagy a zsúfoltság. Az Exchange listenerje nem volt jó neki, innentől úgy gondoltam, ugyanazzal a trükkel bánok el vele, mint a Zimbrával: az Apache átdobja egy újabb virtuális kártyára, azon pedig olyan listenert csinálok neki, amilyet szeretne.
Jó. De milyet szeretne?

  • Egyik módszer
    Ez egy tipikus MS howto a Technet Library-ből. Semmi extra, a jó öreg “pofabe” módszer: a listener nem autentikál, a delegáció pedig közvetlen.
  • Másik módszer
    Ez egy cikk az isaserver.org-ról, Marc Grote írta. Határozottan unortodox módszert követett, a listener autentikáció integrated (azaz ntlm), a delegáció kerberos constrained.
  • Harmadik módszer
    Egy másik cikk a Technet magazinból, viszont ezt két MS nagyágyú jegyzi: Shinder és Diogenes. A trükk az, hogy mivel itt ugyanazt az /RPC/* website-ot publikáljuk, mint az Outlook Anywhere esetében, hát csináljunk meg mindent az Exchange varázslóval. A listener autentikáció basic, a delegálás közvetlen.

Erre szokták azt mondani, hogy a bőség zavara. Kipróbáltam mind a hármat. Egyik sem működött.
Ahhoz már hozzászoktam, hogy nekem valahogy mindig jobban emelkedik a pálya, mint másoknak, de azért a függőleges fal még mindig meg tud lepni.
Az RDS szerver oldalán minden rendben volt, rdweb, rdgw, tanúsítványok, házirendek. (Pedig itt sem volt egyszerű a pálya, ha próbáltál már eligazodni a kilométer hosszú nevek között egy _magyar_ nyelvű szerveren, akkor tudod, miről beszélek.) Odáig mindegyik módszerrel eljutottam, hogy az rdweb oldalon megjelentek az rdp ikonok. (A harmadik módszernél pluszban felvettem az /rdweb/* útvonalat.) Utána viszont állandóan csak autentikációs ablakokat kaptam, akármit is csináltam, akármilyen credential-t adtam meg.
A megoldás természetesen pofonegyszerű, de az autentikációra utaló hiba megzavart, ezért állandóan csak azzal gyötörtem magamat. Beletelt egy napba, mire a fejemre csaptam és felhúztam a DMZ-be egy Windows7 gépet és közvetlenül arról próbálkoztam. Természetesen mind a három módszer működött, szó sem volt autentikációs hibákról.
Egész egyszerűen az Apache nem tudja proxyzni az RPC over HTTPS-t, azaz nem fog menni az RDP over HTTPS sem. Amíg csak az RDweb-ig megyek, addig oké, az tiszta HTTPS… de utána váltunk, az indián meg elhasal. Kész szerencse, hogy az Outlook Anywhere nem volt benne a projekt szkópjában, mert az sem működne.

A többi már nem túl érdekes. Az ügyfél kapott egy ultimátumot, miszerint vagy szerez egy másik IP címet, vagy kilógatjuk az RDS szervert valami lehetetlen porton, persze ebben az esetben övé a felelősség a biztonsági kockázatért. (Sőt, ha már lúd, legyen kövér, ebben az esetben kérünk még egy IP címet és kiváltjuk az Apache proxyt is. Mert mégiscsak egy spof, meg plusz kockázat.)
De ez már nem technológia probléma.

A lelkes TMG

Apróság, nem is akkora nagy szívás, de a kognitív energiák elszivárgása képes némi fogcsikorgatást előidézni.

Van a DMZ-ben egy levelezőszervered – mondjuk egy Exchange Edge – és az SMTP portját egy TMG szerveren keresztül szeretnéd kipublikálni. Ez nem lehet komoly feladat, a varázsló 2004 óta szinte semmit sem változott. Illetve…

From Segédlet

Ez bizony egy zavarbaejtő kérdés. Azt mondja, van másik, van jobb… miért használod ezt a régi szutykot?

Ne dőljünk be neki.

Ha ugyanis az általa felajánlott E-mail Policy varázslóval publikálunk, akkor a szerverünk SMTP portja nem lesz elérhető kintről. Még ha véres verítékkel szétkonfiguráljuk a TMG-t, akkor sem. Egy apróságot ugyanis elfelejt a kuruzsló közölni: E-mail Policy-t csak és kizárólag akkor tudunk használni a TMG-n, ha telepítünk rá egy Exchange Edge szervert is.

Az már egy teljesen más téma, hogy a fenti felállásban igencsak elgondolkodtató, hogy az Edge szervert ne a DMZ-be tegyük, hanem a TMG-re. Az integráltság ugyan növekszik – és ezzel vétünk a KISS-elv ellen – de megspórolunk egy Windows Server 2008 R2 licenszt. Amennyiben viszont más gyártó smarthostját használjuk, akkor nyomjunk pánikszerűen egy No-t és haladjunk tovább.

Kosztüm

Adott a feladat, publikáljunk egy Exchange 2010 OWA szolgáltatást TMG-n keresztül. Ez ma már egyáltalán nem pilótavizsgás munka, nosza.

Ú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.

NIS

Az alábbi videón két medve beszélget a biztonságról: Yuri Diogenes és Tom Shindler. Az első 20 percben eldörmögnek arról, mi mindennel is foglalkoznak mostanában, az utolsó tíz percben viszont Yuri tart egy érdekes bemutatót arról, hogyan is tudja megvédeni a még nem naprakészre patch-elt hálózatunkat egy jól konfigurált NIS (Network Inspection Service) a TMG-n. (Feltéve persze, hogy a támadás szignatúrája már ismert és a NIS meg is kapta a frissítést.)
 

 

A blokkoló anonymous

Nicsak, most látom, hogy Yuri ugyanúgy megszívta, mint én anno.
Csak nála szépen le van írva a megoldás is.

Ne mentsd a cache-t

Az idegenek köztünk élnek, azaz egy félelmetesen bravúros nyomozás leírása Yuri Diogenes blogján.

Espéegy a porcelánboltban

Arról, hogy kijött az Exchange2010 SP1, szándékosan nem írtam semmit. Aki nem tudja meg tizenhét forrásból egy napon belül, az vagy traktorbelsőben él, vagy nem is érdekli a dolog. Azt is leírták sokan, sok helyen, hogy mi újdonságokat hozott a rendszerbe.

Foglalkozzunk most azzal, hogy mi mindent nyírt ki? Nem szándékosan persze, de hát így sikerült.

1.
Henrik Walther írt rögtön az elején egy cikket arról, hogy milyen meglepetésekre készüljünk fel.

2.
Aztán nem sokkal később az Exchange blogon jelent meg egy írás arról, hogy milyen problémák derültek ki nem sokkal az SP1 kibocsátása után.

3.
Végül Yuri Diogenes tett ki a blogjára egy cikket arról, hogy ne, hangsúlyozom, ne tegyél olyat, hogy a TMG E-mail Protection rendszeredben lévő Exchange 2010 Edge szerverre ráhúzod az SP1-et. Amennyiben mégis ilyet tettél volna, akkor ne, hangsúlyozom, ne nyúlj semmihez, mert csak tovább rontod a helyzetet. Várd meg a hotfixet, a fiúk a bányában ezerrel dolgoznak. (Hasonló tanáccsal szolgál a hivatalos ISA/TMG blog is.)

Javítócsomagok

Lassan el lehet kezdeni éles környezetbe is telepítgetni. ;))

TMG 2010 SP1

És aki esetleg lemaradt volna róla:

Exchange 2007 SP3

Tanujj tinó

Nincs ám elfelejtve ez a blog, remek ötleteim vannak – csak idő nincs hozzá.(Ha valaki tud nagy tételben olcsón, vevő vagyok rá.)

Most is csak egy gyors hivatkozás lesz, mondhatni a delicious helyett ide jegyzem fel ezt a remek linket. Yuri Diogenes egy postban összefoglalta, milyen linkeken jut információkhoz az, aki el szeretne mélyülni a TMG rejtelmeiben.
Csak annyit tudok hozzátenni, hogy hajrá, megéri.

Szabálylista nyomtatása

Egyik ügyfelünknél megérett a helyzet arra, hogy gatyába rázzuk az ISA 2004 szerverük szabálylistáját. Évek hosszú során a tűzfal konfigurációja használhatatlanná evolválódott, bátran növelve ezzel az univerzum entrópiáját.

Ez egyben azt is jelentette, hogy nem halogathattam tovább a dokumentálás problémáját.

Az természetes, hogy az ISA konfig rendesen (automatikusan) mentve van. De ami nem igazán jött össze, az a szabályrendszer kiexportálása valami ember által emészthető formába. Fel is raktam anno az ISA Best Practice Analyzer-t, a Health Check része működött is, de az Isainfo a legváltozatosabb hibaüzenetekkel szállt el. Egy ideig még foglalkoztam is vele, de nem sok sikerrel. Más tool meg nem volt.
Maradtunk a mentéseknél.

De most nagyon kellett egy átlátható forma, mert konszolidálni monitorról, azt bizony nem lehet. Szöveges fájl, excel tábla… bármi, amit ki lehet nyomtatni, össze lehet firkálni.

Az első áttörés az volt, hogy az Isainfo-t kell használni. Nem, nem hülyültem meg… a helyzet az, hogy két Isainfo van. Az egyik az, melyet le lehet tölteni Jim Harrison oldaláról, a másik az, melyet beleintegráltak az ISA BPA-ba. A kettő között van egy árnyalatnyi különbség: az előbbi működik. Illetve van még egy: a két változat nem ugyanazt az xml struktúrát használja, azaz nem tudják egymás riportjait felolvasni.

Oké, feltelepítettem külön is (nem nagy ügy, javascript, fel kell csak másolni), elkészült az xml, majd a mellécsomagolt hta alkalmazással meg is tudtam jeleníteni. 1:0.

De hogy lesz ebből papír alapú lista? Hiába kerestem a ‘print’ nyomógombot, az istennek sem találtam. Hmm… hmm… Na jó, a gugli a barátunk (szószerint, mert egy igazi baráthoz méltóan már mindent tud rólunk), keressünk. Találtam is egy fórumot, ahol ezzel foglalkoznak. Odáig elmentek, hogy levelet írtak az alkotónak, hogy ugyan tegyen már bele egy ‘print’ gombot a programba. Erre ugyan nem jött válasz, de hamarosan megszületett a megoldás:

I sent Jim Harrison a suggestion to add printing to the HTA but got no reply. What I did was to hack out the right-click handler so that I can at least right-click => Print.

Azaz nyomj az alkalmazáson belül egy jobbklattyot és válaszd ki a menüből a print opciót.

Ugyanis mindenki ezerrel felejtette el, hogy ez nem exe, hanem hta alkalmazás. Azaz önállóan futtatható, web alapú. Azaz mindazon opciók működnek a jobbklattyra, mint amelyek egy böngészőben.

Innentől persze már egyszerű az élet. Jobb kattintás, Select All, majd az egész szöveg mehet át egy txt fájlba, melyet utána már úgy faragok, ahogy akarok.

Trükkös HTTPS

Az ember már azt hiszi, ismeri az ISA szervert – aztán az mégis meg tudja lepni.

Jött a kérés az ügyféltől, hogy egy kollégájuk szeretne elérni egy weblapot a 8443-as porton. – Na, megint egy istentől, embertől elrugaszkodott webmester – gondoltam – akinek túl kerek szám a 80-as.

De gond egy szál se, pillanatok alatt összedobtam a megfelelő szabályt.
– Teszteljetek! – írtam vissza.

Nem működött.

Ekkor néztem meg jobban, miről is van szó. Jé, ez https. Persze, csaptam a fejemre, csak én lehetek annyira vak, hogy nem ismerem fel, hogy a portszám csak egy számjegyben különbözik a 443-as https porttól.
– Aha, szóval ez egy szupertrükkös webmester – konstatáltam – aki így akarja átvágni a rosszfiúkat. Szvsz elég béna megoldás, ha én portszkennelnék, simán felvenném ezt is a listára, oszt jól van. Cserébe szopatják a tűzfal mögül érkezőket.

Na, mindegy, nézzük, mi van a logban.

The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests.

Kösz, Csoki. Most, hogy már tudom, hogy a legtöbb böngésző a 443-as portot használja az SSL-hez, most már biztosan nyugodtabban fogok aludni.

Némileg persze bosszantott, hogy nagyon nem értettem ezt az egészet. Miért nem engedélyezett? Hiszen tettem rá szabályt. Nehogymár ne lehessen tűzfalszabállyal egy tetszőleges portot kiengedni? A webproxy nem fogadná el? Azon lehet ugyan https portot állítani, de az nagyon nem erről szól. (Akar a fene proxykat láncolni.)

Irodalmazás. Azaz google.

Nos, kérem a megoldás az, hogy az a kis egyszerű webproxy fogadja a kéréseket a saját bekonfigurált portján – általában 8080 – majd ha https-re kell továbbmennie, akkor bepróbálkozik a 443-as porton. Ha ettől eltérő portot adok meg az URL-ben – mint ahogy a szorgos user ezt is tette – akkor döbbenet és lefagyás következik. Az a port nincs engedélyezve a webproxy számára, mint kimenő ssl port.
Természetesen létezik rá megoldás, Shinder bácsi – ki más – írt is róla: el kell menni a www.isatools.org oldalra, le kell tölteni az isa_tpr.js szkriptet (van 2006-os is)… aztán a többit már lásd ott.

Azért ez a rész külön tetszett :

Note that if you have unbound the Web Proxy filter from the HTTP protocol, then Firewall and SecureNAT client connections made through the ISA firewall will not be redirected to the Web Proxy Filter. In this case, you can create a Protocol Definition for the alternate SSL port and then create an Access Rule allowing outbound access to that protocol.

Pislant a hálókártya

Erre az esetmegoldásra nem leszek büszke, de tanulság azért akad benne.

Nagyon fontos ügyfél (habár hülyeség, mindegyik az) telefonál, hogy megállt a cégnél az internetelérés. Különböző okok miatt az ISA webproxy-ra gyanakszik. Mivel internet nélkül nincs élet, így a bejelentés magas prioritású.
A megoldást nehezíti, hogy magát a belső hálózatot nem mi üzemeltetjük, abszolút semmi hozzáférésünk sincsen. Csak az ISA-t kezeljük mi.

Megnéztem a logokat, mi is a helyzet a webforgalommal: a 80-as porton remekül hasítottak a bitek, még a vizsgálat közben is. Leellenőriztem, hogy ez valós forgalom-e. Az volt. Ment vissza a levél: Kedves Ügyfél, te valamit nagyon benéztél, az ISA-n gyönyörűen megy a http.

Amire jött az indignált válasz, hogy márpedig ez nem megy. Biztos, hogy jó forgalmat néztem?

Bakker. Nem. Hiszen a böngészők webproxy kliensek, akik a webproxy filter listening portján érik el az ISA-t. A 80-as porton csak akkor megy webes forgalom, ha nem webproxy kliens forgalmaz. A konkrét esetben a webproxy filter egy lehetetlen porton (na jó, annyira nem, de akkor sem írom le) figyelt, arra rákeresve rögtön dőltek is a denied connection üzenetek.

Hát, ez már mindjárt más. Akkor itt tényleg baj van.

Event log. Tele volt gyönyörű kövér 14118-as hibákkal. Azt mondja:

Description: The Web Proxy filter failed to bind its socket to IP address port xxxx. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.

A részletes hibakód: 0x80072740.

Néhány perc keresgélés után meg is lett a magyarázat. (Komolyan mondom, ma egy informatikusnál az internetes keresési képesség a második legfontosabb készség. Az első az angol nyelv ismerete.) Itt van a KB cikk.
(Ne keverjük össze ezzel a másik cikkel: habár a hibaüzenet ugyanaz, de ez az írás arra az esetre vonatkozik, amikor IIS is fut az ISA mellett.)

Akkor most mi is a hipotézisünk? A hétvégén valószínűleg volt egy rövid időszak, amikor leesett a link az ISA szerver belső lábáról. Ekkor a Windows Server 2003 le is kapcsolta a konkrét hálózati kártyát. Ezt hívják úgy, hogy Media Sense… és feature. Igenám, de amikor visszajön a link és feléled a hálózati kártya, az ISA szerver webproxy filtere nem képes rákapaszkodni a kijelölt portjára. Támadhatják őt a böngészőkből a kliensek, nincs bind. (A pikáns az, hogy a netstat szerint persze ott figyel a megadott porton.) Megoldás? Újra kell indítani a Microsoft Firewall klienst.
Majd.
Eddigre ugyanis az ügyfél morogva beröffentett egy linux proxy-t, mondván ők nem érnek rá. Annyiból igazuk is volt, hogy az ISA nem csak az internet felé forgalmaz, hanem a nagyon fontos anya- és társvállalatok felé is, azt a forgalmat meg még egy percre sem lehet megszakítani szolgáltatás újraindításával.
Majd este.

Addig volt időm körbenézni – és sikerült be is igazolnom a hipotézist: abban a 10 percben, amikor az ISA log szerint megállt a webproxy filter, ott figyelt két bejegyzés a system event logban is:
Warning Event 4: Adapter xxxxxxx Adapter Link Down.
Majd pár perccel később:
Information: Adapter xxxxxxx Adapter Link Up.

A többi már annyira nem érdekes, késő este újra lett indítva a szervíz, minden a helyére került.

Ja, a tanulság: ISA szerveren lehet, hogy nem hülyeség letiltani a Media Sense opciót.
(Windows Server 2008-ban alaphelyzetben le is van.)

Exchange 2007 Edge és az ISA

Nem vagyok egy ISA guru (őszintén nem is használom és piszokul nem is értek hozzá), ezért csak röviden írom le a mai küszködésem végeredményét. Próbáltam beüzemelni egy Edge szervert ami az ISA által kifeszített DMZ-ben lakott.

Az Edge és a Hub transport valahogy nem akart kommunikálni egymással ezért a levelezés nagyon nem akart menni. Se be se ki. A protocol log-ból az derült ki, hogy amikor az Edge kapcsolódott a Hub-hoz próbált egy TLS csatornát kialakítani, amibe belehalt azzal, hogy az X-ANONYMOUSTLS ESMTP parancsra kapott egy nagy büdös 5.5.1 Unrecognized command választ. Nem tudtam mire vélni a dolgot, túrtam a netet, de választ azt nem találtam (persze ugyanezt a kérdést megtaláltam itt). Sokkszori kísérletezés és a TLS kapcsolgatása után megleltem a megoldást.

Az ISA SMTP Filtere nem ismeri a fenti parancsot ezért kiszűri. A DMZ és a belső háló között az ISA-n kikapcsoltam az SMTP Filtert (persze a 25-ös port átengedése az maradt) és most megy mint a kisangyal.