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

6 thoughts on “Kemp, az új TMG 05

  1. Sikerült belőni a végén? Felvetődött bennem pár dolog, amit szívesen kipróbálnék vele, de az Exchange publikációt pont nem tudom kipróbálni…

  2. Sikerült azóta belőnni? Én is most vagyok épp KEMP telepítés környékén, jó volna kevés szívással belőnni laborban mert se időm se energiám se kedvem magam kitapasztalni, csak muszáj miatt foglalkozok vele.

Leave a Reply

Your email address will not be published. Required fields are marked *