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

4 Comments

  1. hrongyorgy

    2015-05-20 at 15:54

    “SNAT (Server NAT)” Au. Vagy nem jott at a humor, vagy hiba van a vilagban.

    Ami a load balancing / packet filter kapcsolatat illeti, kis hattersztori.

    Mivel Linux van mogotte, nagyon jo esellyel a packet filter nem mas, mint az IPTables, annak minden funkcionalitasaval. Itt egyebkent van egy trukk: ott, ahol IP cimet var a rendszer, elfogad CIDR specifikaciot is, vagyis megadhato neki egy alhalozat (10.0.1.5/31) , ha a webfelulet nem anyazik ra, az alatta futo rendszer zokszo nelkul fogja tudomasul venni a feladatat.

    Az, hogy a publikalasok es a packet filter kulon eletet el, annak oka az IPTables felepiteseben keresendo. Nagyon leegyszerusitve 3 rulesettel dolgozik: INPUT, OUTPUT, es FORWARD, sorrendben a bejovo, a kimeno es az atmeno csomagok kezelesere. Minden rulesetnek megadhato egy alapertelmezett policy, ami akkor jut ervenyre, ha nincs egyezo szabaly az adott ruleseten. Namarmost, a csavar ott van, hogy azok a csomagok, amiknek valojaban nem a tuzfalgep a cimzettje, hanem egy mogotte levo gep, azok nem mennek at sem az INPUT se az OUTPUT agon, hanem egyenest a FORWARD-ba mennek be, amely alapertelmezes szerint ures, a default policy pedig ACCEPT. Ilyen esetben nincs semmifele faxni, gyakorlatilag portforwardolunk.

    Ami a loadbalancingot illeti, az a sejtes, hogy vagy HAproxy van mogotte, vagy valami hasonlo cucc, amit egyaltalan nem erdekelnek az IPTables INPUT/OUTPUT (vagyis a packet filter) szabalyai, minden valoszinuseg szerint a hatterben a rendszer automatikusan kinyitja az LB-zett portokat, a tobbit pedig mar a LB szoftveren belul konfiguralgatja be.

  2. Idézet a manuálból.

    “Use Address for Server NAT
    By default, when the LoadMaster is being used to SNAT Real Servers, the source IP address used on the internet is that of the LoadMaster. The Use Address for Server NAT option allows the Real Servers configured on the Virtual Service to use the Virtual Service as the source IP address instead.”

  3. hrongyorgy

    2015-05-21 at 06:44

    Atyauristen. /o\ Most komolyan, olyan emberek raktak ossze egy tuzfal-szeru appliance-t, akik megprobaljak ujraertelmezni a SNAT betuszo mogotti ertelmet? Ez… hat elsore a beteg szo ugrik be, de nincs igazan jobb szavam ra…

    Azert legkozelebb tedd oda, hogy (sic!), csak hogy egyertelmu legyen a helyzet

  4. Nem tűzfal. Load balancer. A legtöbbször az ilyennek nincs is külső lába, hanem a belső hálón oszt terhelést. Mint egy WNLB. Tűzfalnak azért gondolhatod, mert a cikksorozat arra a gondolatra lett felfűzve, hogy betöltheti-e ez az eszköz a TMG mögötti űrt? (Hogy még konkrétabb legyek: a TMG elsősorban tűzfal volt, reverz proxy és loadbalance képességekkel, a Kemp Loadmaster meg elsősorban load balancer / reverz proxy és csak másodsorban tűzfal. (De annak nem is igazán ajánlanám.)

Leave a Reply to hrongyorgy Cancel reply