Categorynetwork

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.

Jó az öreg a háznál

Takarítottam a sufniban és a kezembe akadt egy 10 mbites HUB. Először elmosolyodtam, aztán elérzékenyültem: Istenem, amikor ilyenekből építettük a hálózatot… a gyerekek alsósok voltak, nekem pedig még volt hajam…
Majd jött a következő gondolat: megőrizzem? Menjen a lomtalanításra szánt cuccok közé?

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

1. Belehallgatni a hálózati forgalomba

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

2. Kici ócó NLB

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

From Segédlet

2.1 Multicast

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

From Segédlet

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

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

2.2 Unicast

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

From Segédlet

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

From Segédlet

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

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

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

From Segédlet

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

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

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

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

MAC

Járjuk körbe.

Miért nem érdemes MAC szűrést beállítani az otthoni vagy a céges wifinken?

Ezért.

(A link Fóti Marci blogjáról származik.)

Akkor mégis miért lehet érdemes?

Céges wifinél semmiképpen sem. Ott teljesen másképpen kell megállítani a betolakodót. A MAC szűrés csak hamis biztonságérzethez vezet, nem is beszélve a kellemetlen adminisztrációról.
Otthoni wifi AP esetében viszont mondhatjuk azt, hogy – hasonlóan az ajtónkhoz, vagy a kocsi biztonsági rendszeréhez – minél több akadályt gördítünk a behatoló elé, annál valószínűbb, hogy odébbáll.
Mondhatjuk?
Attól függ, ki a behatoló. Ha csak egy arra kóválygó wifiszomjas járókelő, vagy egy háromnapos emailmegvonásban szenvedő turista, akkor tökmindegy. A WPA/WPA2 úgyis megfogja. (Mert azért megfelelő jelszavas védelemre szükség van. Gondolom, senki nem rajong az ötletért, hogy az otthoni hálózatán idegenek kóricáljanak.) Sőt, ezeket az embereket még a WEP is megfogja, hiszen ritkán túrázik az ember hacker felszereléssel. Hasonlóan jó majomfogó az SSID elrejtése is, csak ebben az esetben nem tudunk üzenni a szomszédnak, hogy takarítson a kutyája után. (Az egyéb lehetőségekről nem is beszélve.)

From Segédlet

Amennyiben célzott támadás ellen szeretnénk védekezni, akkor viszont marad a WPA2, bazi hosszú, véletlenszerű pre-shared kulcssal. (Kevéssé tartom valószínűnek, hogy otthoni hálózatban legyen egy éppen ráérő RADIUS szerver.) Emellé az SSID elrejtése szintén hasznos lehet, a MAC szűréssel viszont csak kiröhögtetjük magunkat. Illetve megnehezítjük az életünket.
Ja, miért nem jó a rövid, értelmes szó WPA2 jelszónak? Ezért.

Mint láthatod, a WPA/WPA2 is törhető, igaz, szótárral.

Akit esetleg jobban is érdekel a téma, innen el tud indulni, az oldal linkjein lesz anyag bőven.

Tipikus

Az a mém megvan, hogy ‘váratlanul megjavult magától’?

Trust kapcsolat egy multi két leányvállalata között. A végpontok különböző országokban, a központ meg valahol Európában. Egyszer csak ügyfél jelzi, hogy nem működik a trust. Megnézem, tényleg.
Network ellenőrzés, kiderül, hogy valahol blokkolják az udp389-et. Levél elmegy mindegyik országba, plusz a központba: – Uraim, nézzenek utána, mi van a tűzfalakon/routereken? Levelek vissza. Kivétel nélkül mindenhonnan azt írják, hogy leellenőrizték és a port mindenhol engedélyezve van.

Csak éppen onnantól megint működik a trust.

Hát, megtörtént

Tudom, index cikket nem linkelünk, mert az mindenki olvassa, aki meg nem, az utálja. De most, a hír érdekessége miatt mégis kivételt teszek. Évtizedek óta mondogatjuk, hogy elfogy a kőolaj. Aztán mindig találnak valahol még egy kicsit. És évtizedek óta mondogatjuk, hogy elfogynak az IPv4 címek – amíg aztán tényleg elfogytak.

Emberek, aki eddig még nem vette komolyan a helyzetet: most jött el a legeslegutolsó pillanat, hogy nekiálljunk megtanulni, hogyan is néz ki az a fránya IPv6.

Apu, hod med be

Jó téma, napokig lehetne cikkezni róla. Konkrétan arról van szó, hogyan nyúl bele a tűzfal a legegyszerűbb adatáramlásokba is. Melyekről persze kiderül, hogy nem is olyan egyszerűek.

Az első sztorink egy világméretű hálózaton történt. Két Exchange organizáció között kellett Free/Busy szinkront összelőni. A túloldal Amerikában volt, jó nagy időeltolódással. A kommunikáció enélkül is igen nehézkesen ment, ilyen környezetben nem egyszerű összehozni egy élő kapcsolatot, hogy mind a két oldalon ott üljön a megfelelő mérnök és szinkronban taperolják a billentyűzetet.

Előtte határozottan felhívtam a tűzfalas kollégák figyelmét, hogy a két host között any-any kapcsolatot kérek az oldalunkon. Belső hálózatról van szó, épp elég lesz az F/B szinkronnal játszanunk, első körben nem szeretnénk, ha a tűzfal bekavarna. (Utána lehet majd szigorítani.) Megigérték, beállították.

Eljött az idő. Próbálkoztunk. Nem működött. Kiderült, hogy a túloldali tűzfalon mindösszesen néhány portot engedélyeztek, csak éppen ezt a portlistát elfelejtették közölni. Mi viszont az Exchange megfelelő szolgáltatását nem korlátoztuk konkrét portokra. Némi gondot jelentett, hogy az általuk engedélyezett portokat nálunk már más Exchange szolgáltatások használták. Hasraütve kiválasztottunk néhányat a környékről (6xxx), a túloldalon engedélyezték a tűzfalon, nálunk ugye nem kellett.
Továbbra sem működött a szinkronizáció. Izzadtunk még egy sort, majd kölcsönös és sűrű sorry-k mellett befejeztük a közös munkát. Majd legközelebb.

Másnap a biztonság kedvéért rákérdeztem a helyi biztonsági erőknél, hogy tényleg any-any lett-e beállítva? Mellékeltem a konkrét portszámot is. Erre kaptam egy olyan választ, hogy jojózott a szemem. Ugyanis a véletlenszerű porttal pont beletaláltam egy általam még csak soha nem is hallott protokoll tartományába, melyet a konkrét tűzfalon nem engednek át direktben, hanem proxyznak. Innentől jókedvű anyázásba fordult a levelezés, én próbáltam elmagyarázni, hogy az any-any azt jelenti, hogy a két host között minden kommunikáció transzparens, ők viszont ragaszkodtak ahhoz, hogy az any-any az egy beállítás a szabályon, de nem érinti a különböző protokollproxykat.

A vége az lett, hogy kerestünk egy olyan portot, amelyiken biztosan nincs semmi trükközés, a következő partira az amik módosították a náluk lévő tűzfal szabályát, be is indult a kommunikáció.

A második sztori nem sokkal ezután esett meg egy kollégámmal és kisértetiesen hasonlított az előzőre.

Ügyfélnél két telephely, két AD site. Mindkettőn vannak Exchange Hub Transport szerverek. A jelenség: nem mennek át a levelek. Ott állnak a várakozási sorban, és azt mondják, hogy a túloldali szerver nem képes az Exchange szerver autentikációra. (Lásd a korábbi cikk.) A tűzfalas kolléga szerint a hostok között a kért portok engedélyezve vannak.
Ami alapvetően igaz is volt, de amikor megpróbáltak telnetelni, elég érdekes válaszokat kaptak. Lényeg a lényeg, a tűzfalas úriember csak azt felejtette el közölni, hogy a készüléken be van kapcsolva a MailGuard, amelyik meglehetősen szigorú ellenőrzést gyakorol az smtp forgalom felett: egyedül a HELO, MAIL, RCPT, DATA, RSET, NOOP és QUIT parancsokat támogatja, minden más tiltott. Igen, már az ESMTP és az AUTH is.
Nyilván a kikapcsolás után beindult minden.

Könyvek, csak jönnek

Elnézést a keresztpostázásért, de gondolnom kell azokra is, akik csak a szakmai blogot olvassák.

Kapaszkodj, mert nem lesz egyszerű.

Amikor lezártam a TCP/IP Alapok könyvet, még volt bennem egy jó adag hiányérzet. Annyi virág nyílik az alkalmazás rétegben. Oké, hogy a DHCP és a DNS példaként be lett mutatva, de egy csomó izgalmas téma még kibontatlan maradt.

Kapóra jött, hogy tervben volt egy TMG könyv. Összedugtuk a fejünket és azt találtuk ki, hogy lesz egy közös könyv: én írok a webes protokollokról, ezek biztonságosabbá tételéről, GT pedig a TMG-ről.

Aztán összeállt az anyag első fele. Az én blokkom három részből állt: jó 50 oldalon összefoglaltam a TCP/IP Alapok könyv lényegét, a maradék 170 pedig felszántotta – jó mélyre eresztett ekevassal – a webes protokollok témát (HTTP, FTP, SMTP), beleértve a biztonsági megfontolásokat (TLS, SSH, IPSec, VPN, RADIUS) is.
Jó erős anyag lett. Nézegettük. Nemcsak, hogy megállt a saját lábán, de még a kávét is ágyba hozta. Úgy döntöttünk, hogy inkább önálló kötetként adjuk ki, méghozzá hozzácsapva a TCP/IP könyvhöz. Mert utólag végigolvasva, sokkal inkább ahhoz passzol, mint a TMG-hez. (Mely blokk szintén bőven erős lesz ahhoz, hogy önállóan is megálljon.)

Most jön a kavarás része:

  • A teljes kéziratból kiemeltem azokat a részeket, melyeknek inkább a TCP/IP Alapokban volt a helye. Ezekkel szépen bővült a könyv.
  • Örömteli hír, hogy rengeteg visszajelzés érkezett a korábbi (1.1) könyvhöz. Ezekből lettek levelezések, tisztázások, melyek következtében egyrészt bővült az anyag, másrészt világosabb lett. Itt kell beismernem, hogy volt olyan terület az 1.1-ben (TCP folyamszabályozás), ahol alapvetően rosszul értelmeztem a koncepciót. Egy kedves olvasó helyretette a folyamatokat a fejemben, én pedig átírtam az egész fejezetet. (Részletes lista a könyv végén.)

Emiatt a két pont miatt váltott a könyv fő verziószámot. mostantól 2.0.

  • A kéziratból leválasztottam a bevezető fejezetet. Ebből a műtét során egy 42 oldalas füzet lett. Ez az anyag a keresztségben a ‘TCP/IP – 1 óra alatt’ nevet kapta. Bárkinek, akit elrémisztene a 350 oldalnyi bitekkel tömött szöveg, de azért szeretne egy átfogó képet kapni a TCP/IP működéséről, bátran tudom ajánlani.
  • A maradék 161 oldal pedig önálló könyvként jelent meg, pontosabban a TCP/IP Alapok könyv második köteteként.

Lássuk a végeredményt:

Fontos látni, hogy az utolsó két kötet képez egy egységet, mely nem kompatibilis az 1.1 verzióval. Ha érdekel a téma, akkor nyugodtan dobd ki a korábbi verziót és töltsd le ezt a kettőt. (És elnézést azoktól, akik kinyomtatták. Megnyugtatásként közlöm, hogy ekkora strukturális átalakítást már nem tervezünk, maximum hibajavítások lesznek még.)

Ezzel párhuzamosan nyilván bővült a letölthető könyvek listája is, immár 8 könyvre mutatnak linkek. (Kihasználom a lehetőséget és szólok, hogy az első kettőt mostanában ne töltsd le, ezerrel írom, illetve szerkesztem át az anyagot.)

Geek úr nyaral

Nem tudom, te hogyan vagy vele, én nagyon aggódós utazásszervező vagyok. Akkor nyugszom meg, ha előre minden le van foglalva, ki van fizetve. Igaz, ekkor meg azon szoktam parázni, hogy időben odaérünk-e mindenhová.

Tudtam, hogy hová akarunk menni a nyáron. Igaz, még január volt, de mivel konkrét eseményre terveztünk, az időpont biztos volt. Maga az esemény miatt jókora tömeg várható, a kiválasztott kemping pedig picike. Ráadásul éppen erős is a forint – ergo minden jel afelé mutat, hogy már most foglaljam le a szállást.

Elmentem a weblapra, megkerestem a Reservation menüpontot.

Nagyítás

Erre feljött egy iframe-be ágyazott webes form. Kitöltöttem az adatokat, rányomtam a ‘send’ gombra. Kaptam egy kövér 404-est.

Nagyítás

Nagyítás

Ez bizony baj. Lemenjek úgy, hogy nincs biztos szállás? Egy ilyen frekventált időpontban?

Akkor már inkább varázsoljunk.

Első lépés: keressük meg, melyik az az oldal, amely végül nem érhető el. Szerencsére a Wireshark mostanában gyakorlatilag bootoláskor indul, így nem okozott gondot a beröffentése. Eljátszottam ugyanezt a foglalást.

Nagyítás

A webes formok adatait az OK gomb megnyomására egy POST paranccsal szokták elküldeni a webes alkalmazás számára. Rakjuk össze a HOST headert és a POST paraméterét: www.veniceincoming/camp/.okmailnew.asp. Ennek az alkalmazásnak kellene átadni a kép alján található szép nagy emaildest változó értékét.
Csakhogy az alkalmazás sztrájkol. Vagy kiment pisilni. Nincs.

Ami elsőre gyanús, az a ‘.’ karakter az URI-ban. Nem szoktak. Írjuk be anélkül az egészet a böngésző címsorába: és rögtön egy alkalmazásoldali hibaüzenetet kapunk.
Első lépésnek jó. Megvan az alkalmazás, a hiba meg jogos, hiszen tényleg nem adtam át semmilyen paramétert.

Nosza.

Alapvetően két stratégia közül választhatunk. Kezdjük az ‘ököllel szöget falbaverős’ technikával.

Megkértem a Wireshark-ot, hogy az elkapott csomagokból rekonstruálja a teljes forgalmat.

GET /camp/auk.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.campingsannicolo.com/uk/contattaci-italiano.htm
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Ez volt a kemping weblapjának lekérése.

HTTP/1.1 200 OK
Date: Tue, 19 Jan 2010 18:19:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Length: 26933
Content-Type: text/html; Charset=windows-1252
Cache-control: private

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

<html>

Innen jött egy bazi nagy HTML lap. Miért is? Ugye elment egy GET kérés, arra jött egy 200 OK válasz. Nemrég tanultuk, hogy ennek a válasznak a message blokkjában jön vissza a lekért oldal. Mi választja el a message és a header blokkokat? Üres sor. És tényleg.

</body>

</html>

POST /camp/.okmailnew.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.veniceincoming.com/camp/auk.asp
Content-Length: 342
Cache-Control: max-age=0
Origin: http://www.veniceincoming.com
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

emaildest=info%40campingsannicolo.com&cognome=Jozsef&nome=Petrenyi&
email=jpetrenyi%40gmail.com&fax=&mese_arrivo=05&giorno_arrivo=21&anno_arrivo=2010&
totale_notti=3&numero_adulti=4&numero_bambini=&V-TADU=0&V-B2%2F10=0&V-R%2BAUTO=0&
V-CAMP=0&V-TG=0&N-TX2=0&N-TX4=0&N-R4%2F5=1&N-SP=0&N-LAV=0&N-BICI=0&N-ELE=1&
N-PARK=0&N-PARK-M=0&Note=&Submit=Send

Itt történik a lényeg. Először vége van a nagy HTML oldalnak. (Nyilván közben kitöltöttem a mezőket és rányomtam a Send gombra.) A POST paranccsal indul az adatok feltöltése. Egy csomó fejléc mező után jön az üres sor, majd a message blokkban ott figyel az a karakterlánc, melyet a form rakott össze és melyet az alkalmazásnak már jó étvággyal el kellene fogyasztania.

HTTP/1.1 404 Not Found
Content-Length: 1635
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 19 Jan 2010 18:20:12 GMT

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
<!HTML><!HEAD><!TITLE>The page cannot be found</TITLE>

De nem teszi meg, ehelyett visszajön egy 404-es hibakód. (Emlékszünk, kliens oldali hiba.) Azaz nincs olyan weblap – jelen esetben alkalmazás, melyet meg akartunk hívni.
Az üzenet message blokkjában még ott van egy formázott HTML üzenet is, hogy a nem kockafejűek is értsék, miről is van szó.

Nos, itt van előttünk a teljes folyamat. Minden parancsot, minden fejlécet, minden message blokkot ismerünk. Azt is tudjuk, hogy a POST parancsban van elgépelve az alkalmazás neve.

Mire várunk? Putty.

Nagyítás

Rácsatlakoztam a webszerver 80-as portjára. Soronként átmásoltam a parancsokat a Wireshark kimenetéből. Ahogy egy üres enter-rel jeleztem, hogy vége a parancsnak, rögtön meg is kaptam a weblapot.

Nagyítás

Ha ez most egy böngésző lett volna, akkor értelmezte volna a HTML kódot és szép, színesszagos weblapom lett volna. De most szöveges kliensem van, abban meg így néz ki a weblap.
Képzeletben kitöltöttük a formot, vissza szeretnénk küldeni.

Nagyítás

Vegyük észre, a küldés első sorát, a POST parancsot nem ész nélkül másoltam be. Töröltem a ‘.’ karaktert. A többi maradt. A message blokk utáni üres enter után el is ment a csomag.

Nagyítás

Sajnos kiábrándító eredménnyel. Hiába találtuk meg az alkalmazást, hiába adtunk át neki egy teljesen szabályos adatcsomagot, az alkalmazás hibát dobott. Maximum annyi vigaszt meríthetünk, hogy ez egy 500-as hibakód, azaz kliensként már jók vagyunk, most a szerver dobta el az agyát.

Mondtam, hogy van egy másik módszer is. Egyszerűbb is, elegánsabb is… de kevesebbet lehet belőle tanulni.

Első lépésben lementjük az iframe-ben lévő weboldal forráskódját. Remélem, ezt nem kell külön részleteznem.

Nagyítás

Megkeressük a form parancs action paraméterét. És tényleg, ott van a hibás hivatkozás az alkalmazásra. Kijavítjuk, méghozzá úgy, hogy nem a relatív hivatkozást hagyjuk benne – hiszen a HTML fájl most már itt van a lokális vinyónkon – hanem az abszolút URI-t. Elmentjük, megnyitjuk a böngészőnkben. Kitöltjük a formot, send.
Hiba.

Nagyítás

Ugye látjuk, hogy ez szószerint ugyanaz a hiba, mint amilyet a Puttyban kaptunk – csak itt a böngésző jelenítette meg a szöveget.

A hibaüzenetből egyébként annyit lehet látni, hogy ez egy asp.net alkalmazás, méghozzá a nevéből itélve egy levélküldő alkalmazás. Valószínűleg az lett volna a terv, hogy az alkalmazás emailben elküldi a kempingnek a regisztrációs adataimat – csakhogy a formból rosszul hívják meg, nincs megadva az a cím, ahová a csomagot küldeniük kellene.

Ez ellen már nem segít semmilyen trükközés. Megkerestem a kemping emailcímét és elküldtem nekik szép, ember által is érthető szöveges formában a foglalási igényemet.

– Az írás egy hamarosan megjelenő könyv része. –

Az IPv6 és az Exchange 2010 románca

Egy újabb bájos jelenség. Dave Goldmann címlistamágus blogjában olvastam egy aranyos sztorit.

Az Exchange 2010 ugye már csak Windows Server 2008 oprendszerre megy fel. Ez a windows viszont már helyből beépített IPv6 tudással települ fel. Ez az emberek egy részét nem szokta zavarani – de a szerverüzemeltetők között akad rendesen paranoiás alak is, akik úgy vélik, hogy amire nincs szükség, az ne is legyen fent. És kiveszik a pipát az IPv6 checkbox elől.

Nos, ők járnak úgy, mint David. Az Exchange 2010 szerverük harakirit követ el.

Apu, hod med be?

Az a rengeteg alkalmazás a másik számítógépre? Jó kérdés. Rengetegszer láttam már, hogy valaki tűzfal mögött akart elérni egy akármilyen alkalmazásszervert, megnyitott érzésre portokat… majd végül, belefáradva a nyomozásokba, bebillentette az any-any szabályt.

Nos, itt egy – szószerint – kimerítő lista arról, hogy mely alkalmazás mely portokat használja.

Mivel ez azért alapvetően levelezéscentrikus blog, itt van egy másik írás arról, hogy konkrétan az Exchange 2007 milyen portokat használ, amikor dolgozik.

Desszertként pedig álljon itt egy leírás arról, hogyan lehet az Exchange RPC szolgáltatásait egyetlen portra koncentrálni – azaz tűzfalbaráttá tenni. Igaz, ez Exchange 2000/2003-ra íródott, de a cikk végén megjegyzik, hogy a beállítások remekül működnek 2007 alatt is.

Spagetti routing tábla

Egyik ügyfelünknél beköltözött a nagy Sztochasztikus Vezetékelharapó az informatikai rendszerükbe. Időnként ugyanis az egyik kritikus telephelyükről nem érték el a központi Exchange szervert. Máskor viszont minden tökéletesen ment.
– Máskor tökéletesen ment? – kérdeztem vissza – Akkor hívjátok a networkos emberünket, mert ez nem Exchange hiba lesz.
És dobáltam tovább a dartsokat.

A networkos ember megnézte a routereket, switcheket, tűzfalakat… minden tökéletesen működött. Nem volt mit tenni, meg kellett várni egy üzemzavart. Meg is jött. Networkos ember ismét átnézett mindent. Alles oké. Csak éppen az Exchange szerver se telnet, se icmp szinten nem volt elérhető.
Vicces.
Aztán a kolléga tovább vizsgálódott, végül arckarmolás mellett felüvöltött: a rohadt istenit az Exchange szervernek!
Ekkor tettem le a nyílhegyeket. Lehet, hogy mégis érintve vagyok?

Mielőtt továbbmennénk, pár szó a hálózatról. Ez egy országos kiépítettségű hálózat, rengeteg telephellyel, subnettel, dmz-vel. Nem viccelek, a dmz-k mennyiségre kétszámjegyűek, nem ritka a két-három kijárattal bíró subnet sem. Nem is a szétszórt routerek kezelik a route logikát, hanem van középen egy RSP (Route Switch Processor), ő az ész. Meg a default gateway is mindenhol.
És akkor nézzük meg, mi borította ki a kollégát. Kéremszépen, megnézte az Exchange szerver route tábláját – és vagy 187 bejegyzést talált benne. 187 rosszat. Ez már nem volt annyira vicces.
Arra viszonylag hamar rájöttünk, mi történik: jön egy Outlook kliens valamelyik másik subnetből, az Exchange szerver meg felveszi annak a routernek a lábát a route táblába, ahonnan a kliens jött, természetesen a szabályban a kliens IP címe szerepel 255.255.255.255 maszkkal.
De miért is okozott ez a jelenség ekkora problémát?
Az elején mondtam, hogy az a bizonyos telephely borzalmasan kritikus az ügyfél számára. Ergo redundáns bérelt vonal van kihúzva, úgy, hogy a szolgáltatók sem azonosak. Ha ledől az egyik vonal, a routerek automatikusan átváltanak a másikra, az RSP is ennek megfelelően módosítja az útvonalakat. Csakhogy az a szerencsétlen helóta Exchange szerver minderről semmit sem tud, továbbra is a route táblájában lévő, immár fals kijárattal próbálkozik. Miért nem megy el az RSP-hez? Mert a 255.255.255.255 maszk szorosabban illeszkedik a csomagra, mint a default gateway maszkja.

Vadul elkezdtem keresni a neten, de nem igazán tudtam jól megfogalmazni a kérdésemet. Ha legalább a jelenség nevét tudnám. Végső menedékként dobtam egy körlevelet nagytudású, művelt cimboráimnak, hogy ki találkozott már ilyesmivel. Rövidesen meg is jött a válasz. Gömöri Zoli szerint a router dumál vissza a szervernek, hogy van egy rövidebb út Géza, mostantól menj arra, engem meg hagyj ki a buliból. Stone pedig megírta a jelenség nevét és azt, hogy hol lehet kikapcsolni. Imhol:

  • A jelenség – és a kulcs – neve: EnableICMPRedirects
  • Registry ág: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\

Ha az érték nulla, akkor a szerver magasról leszarja, mit mond a router.
Beállítottuk, az incidens elhárult.
Jöhetett a problémamegoldás. Biztos, hogy nem okoz galibát ez a registry módosítás? Mivel most már volt név a kezemben, körbenéztem. Találtam is egy ajánlást, hogyan védjük szervereinket (D)DOS ellen – hát például úgy, hogy a fenti értéket egyre állítjuk. Oké. Akkor ez a kérdés meg lett válaszolva.
De miért csak mostanában jelentkezett a hiba, régebben miért nem? Nos, kiderült, volt korábban egy RSP csere. A művelet tökéletesen sikerült, az új RSP remekül működött – csakhogy ez az ún. icmpredirect érték defaultban engedélyezett volt minden lábán. A réginél meg nyilván nem.
Azaz, ha biztosra akartunk menni, akkor nem csak az Exchange szerveren kellett beállítani, hogy ne figyeljen arra, mit mond a router – hanem a routeren is, hogy ne molesztálja a hostokat.
Most, és csak most mondhatjuk azt, hogy lekezeltük a problémát… írhatjuk végre a változásigénylést.