A mostanában -- illetve már egy éve -- futó WAN átszervezős projektünk keretein belül belefutottam egy újabb szánalmas problémába. A projektben soron következő néhány telephelyhez igen sok tűzfalszabály kapcsolódik az egyik legfontosabb site-unk tűzfalában, ami azért gond, mert ezeket a szabályokat a WAN migrációval párhuzamosan kell megváltoztatni, más zónákba kell majd kerülniük ezeknek a szabályoknak, zónákból is elég sok van, az említett telephelyekhez kapcsolódó szabályokból még több, szóval gyanús, hogy nem lesz a dologból sikertörténet.
Még annyit érdemes tudni, hogy a tűzfal többek közt a fontos site-on is ki van szervezve, és nincs közös irányelvek alapján dolgozó belső csapatunk a tűzfalas kérdésekre, ráadásul az ezzel foglalkozó emberek is jönnek-mennek. Van persze egy alapvető biztonsági szűrés a tűzfalas kérésekre, de itt nagyjából meg is áll minden egységesítési törekvés. Ha ezt még megfűszerezzük azzal, hogy a tűzfal szolgáltatást nyújtó cég sem ugyanazokra az emberekre delegálja a kéréseinket (értelemszerűen), akkor azért nagyjából el lehet képzelni, hogy hogyan néz ki egy-egy ilyen kiszervezett tűzfal. A legkisebb bajom az, hogy nincs egységes megközelítés, hogy mikor használjunk pl. a szabályok SRC és DST mezőiben sima IP-t, IP-t netmaskkal, szimbolikus, külön definiált neveket vagy a belső DNS-eken feloldott domainneveket, szóval ez teljesen ötletszerű, és ember legyen a talpán, aki egy-egy szabályról ránézésre megállapítja, hogy honnan hová tilt vagy engedélyez bizonyos forgalmat.
Épp azon lamentáltam a tűzfalszabályokat böngészgetve, hogy hogyan lenne érdemes ezt megközelíteni, amikor megpillantottam a GUI-n a "Column settings" opciót... és igen, volt benne "Count" mező is, bekapcsoltam, majd jött a döbbenet. A már említett fontos telephely tűzfalszabályainak 76 százaléka szemét. Nem volt azokon a szabályokon semmilyen forgalom a tűzfal utolsó firmware frissítése óta, ami azért nem két napja történt (148). Jó, ebből a 76%-ból lejön valamennyi, például bizonyos VPN tunnelekhez kapcsolódó szabályok, amely tunnelek csak akkor kezdenek el érdemben forgalmazni, ha szakad a bérelt vonal itt vagy ott, de azért a 76 százalék az 76 százalék. Tiszta sor: nincs gazdája a rendszernek, a szabályok csak bekerülnek, olykor többször is, és valójában sem a cégünk, sem a tűzfalat szolgáltató cég nem törődik a rendszerrel.
Szóval megkérdeztem a főnököt, hogy mit szólna, ha azt a jó néhány száz szabályt, ahol 0 bájt volt a forgalom, töröltetnénk, utána már könnyebb lesz a WAN migráció. Meglátjuk, mit szól hozzá.
2011-03-15
Firmware frissítés 3ComOS-t futtató XRN (IRF) switch stacken
Korábban már érintőlegesen volt szó a 3ComOS-ről, ami tavaly ugye mindenestül a HP kezébe került, de gyakorlatilag ugyanez a szoftver fut a Huawei és a H3C eszközökön is. Ma ismét előszedhettem a 3ComOS ismereteimet, a nemzeti ünnep ugyanis kiváló alkalom a szoftverfrissítések terítésére. Aki ismeri valamennyire a korábbi 3Com, illetve a jelenlegi HP, H3C, Huawei vonalat, az tudja, hogy egészen élhető stack technológia van ezekben a vasakban, viszont a stack a szoftverfrissítés során nem nagy előny. Az XRN vagy újabban IRF stackek nem állnak ugyanis össze, csak akkor, ha pontosan azonos a szoftververzió a stack unitjain. Innentől viszont érdemes észnél lenni, hogy mikor, mit csinál az ember, és bizony a hivatalos dokumentumok sem viszik túlzásba a stack-es szoftverfrissítési folyamat ismertetését. Vannak persze ezekhez a dolgokhoz is management eszközök (3Com Network Director, HP Intelligent Management Center), amivel GUI-n összekattintgatja az ember a frissítést, viszont ha elég sok stackünk van, akkor ilyen vagy olyan okból mindig akad egy-kettő, ahol elhasal a GUI és jöhet a mindenható CLI-s bütykölgetés.
Az első lépés a hely felszabadítás a beépített flash modulokon, nem mindegyik típusnál fér ugyanis el két különböző szoftververzió egymás mellett, nyilván a nagyobb, drágább eszközökön ez nem gond, de ha access stackekről van szó, akkor a helyhiány mindennapos probléma lehet a frissítéskor. A dir /all /fabric paranccsal egyszerre ki tudjuk listázni az összes uniton a fájlokat unitonkénti bontásban:
Az első lépés a hely felszabadítás a beépített flash modulokon, nem mindegyik típusnál fér ugyanis el két különböző szoftververzió egymás mellett, nyilván a nagyobb, drágább eszközökön ez nem gond, de ha access stackekről van szó, akkor a helyhiány mindennapos probléma lehet a frissítéskor. A dir /all /fabric paranccsal egyszerre ki tudjuk listázni az összes uniton a fájlokat unitonkénti bontásban:
<HOSTNAME>dir /all /fabricA listából láthatjuk, hogy mennyi szabad hely van még unitonként, illetve azt, hogy mely fájlokat futtatja aktuálisan a rendszer. A fenti példában látható, hogy az s3n03_03_02s168p06.app a bootloadernek megadott rendszer image, a webGUI-hoz pedig az s3p04_03.web fájlból veszi az adatokat az OS, hely viszont még egyszer ugyanennyihez nincs (általában a többi uniton is ugyanez a helyzet). Ilyenkor le kell egyenként törölgetni a fájlokat minden unitról a delete paranccsal (delete unit1>flash:/s3n03_03_02s168p06.app), majd ugyanez a unit2-vel, unit3-mal... illetve a műveletet érdemes megismételni a web package-ekre (*.web) is. Valami ilyesmit fogunk kapni eredményül:
Directory of unit1>flash:/
1 (*) -rw- 10199 Mar 10 2011 08:43:52 3comoscfg.cfg
2 -rwh 293 Mar 02 2011 01:56:03 private-data.txt
3 -rw- 9705 Feb 29 2008 12:00:00 3comoscfg.def
4 (*) -rw- 4171170 Mar 15 2011 15:56:51 s3n03_03_02s168p06.app
5 (*) -rw- 981062 Mar 15 2011 16:00:08 s3p04_03.web
7239 KB total (2055 KB free)
Directory of unit2>flash:/
... a többi unit adatai...
<HOSTNAME>dir /all /fabricA hely csak a recycle-bin ürítés után szabadul fel ténylegesen, amit egyetlen paranccsal meg tudunk tenni minden unitra a reset recicle-bin /fabric kapcsolójával. Ebben az állapotban nem jó, ha újraindulnak eszközök, mert nem fognak tudni bebootolni (természetesen konzolról vissza lehet küzdeni magunkat, de jobb az ilyesmit elkerülni, ha van rá mód), így mihamarabb másoljuk fel minden unitra a friss szoftvert:
Directory of unit1>flash:/
1 (*) -rw- 10199 Mar 10 2011 08:43:52 3comoscfg.cfg
2 -rwh 293 Apr 02 2008 01:56:03 private-data.txt
3 -rw- 9705 Feb 29 2008 12:00:00 3comoscfg.def
4 -rw- 4171170 Mar 15 2011 15:56:51 [s3n03_03_02s168p06.app]
5 -rw- 981062 Mar 15 2011 16:00:08 [s3p04_03.web]
7239 KB total (2055 KB free)
Directory of unit2>flash:/
... a többi unit adatai...
<HOSTNAME>reset recycle-bin /fabric
Squeeze the recycle bins in fabric ? [Y/N]:y
Unit1 reset success!
Unit2 reset success!
Unit3 reset success!
Unit4 reset success!
Unit5 reset success!
Unit6 reset success!
tftp 10.10.10.10 get s3n03_03_02s168p11.app unit1>flash:/s3n03_03_02s168p11.appA fájlokat egyébként elegendő egyszer letölteni a stackre, és onnantól lehet a unitok közt is másolgatni a copy paranccsal. Bizonyos frissítésekhez új bootloader (*.btm) is jár, ilyenkor ezt is le kell töltenünk minden unitra:
tftp 10.10.10.10 get s3n03_03_02s168p11.app unit2>flash:/s3n03_03_02s168p11.app
stb.
tftp 10.10.10.10 get s3p04_04.web unit1>flash:/s3p04_04.web
tftp 10.10.10.10 get s3p04_04.web unit2>flash:/s3p04_04.web
stb.
tftp 10.10.10.10 get s3o04_04.btm unit1>flash:/s3o04_04.btmHa felmásoltuk a szoftvereket, jöhet a használatba vétel, be kell állítanunk (még a régi) bootloaderhez az új szoftver image-t -- természetesen minden egyes uniton:
tftp 10.10.10.10 get s3o04_04.btm unit2>flash:/s3o04_04.btm
stb.
<HOSTNAME>boot boot-loader unit1>flash:/s3n03_03_02s168p11.appHa van bootloader frissítés, akkor azt is minden uniton be kell állítani (a beállítás után egyébként a *.btm fájlok törölhetők, de ha ott maradnak, az sem számít):
The specified file will be booted next time on unit 1!
<HOSTNAME>boot boot-loader unit2>flash:/s3n03_03_02s168p11.app
The specified file will be booted next time on unit 2!
stb.
<HOSTNAME>boot bootrom unit1>flash:/s3o04_04.btmVégül a friss web package beállítása következik, már ahol szükség van egyáltalán ilyesmire. Ezt nem kell unitonként állítani, egyszer kell kiadni a következő parancsot:
This will update Bootrom on unit 1. Continue? [Y/N] y
Upgrading Bootrom, please wait...
Upgrade Bootrom succeeded!
<HOSTNAME>boot bootrom unit2>flash:/s3o04_04.btm
This will update Bootrom on unit 2. Continue? [Y/N] y
Upgrading Bootrom, please wait...
Upgrade Bootrom succeeded!
stb.
<HOSTNAME>boot web-package s3p04_04.web mHa mindennel elkészültünk, akkor jöhet a stack újraindítása a reboot paranccsal.
2011-03-14
A Babel routing protokoll
Épp az OpenWRT oldalán böngésztem a híreket (egyre türelmetlenebbül várom a tavalyi 10.3-as verzió frissítését), amikor olvasom, hogy holnapután Barcelona mellett lesz a "Wireless Battle Mesh v4". Hát az meg mi? No, nem mintha elmennék vagy ilyesmi, de sosem hallottam még csak hasonlóról sem, ezek meg már a negyediket rendezik...
Némi kutakodás után, bár sokkal okosabb nem lettem, arra jutottam, hogy ez valamiféle perverz geek találkozó, ahol tényleg foglalkoznak wifivel, de a hangsúly nem ezen van, hanem a routingon. Egy-egy ilyen esemény alkalmával összedobnak egy mesh hálózatot, amelyben minden egyes eszközön (a mesh gráf csúcsai) routeolás folyik és valamilyen irányító protokoll fut.
Itt jön a lényeg, hogy milyen protokollt érdemes választani? A rádiós hálózatok ugyanis a vezetékesekkel szemben számos meglepetést tartogathatnak. Változhat például a topológia az eszközök mozgatása, ki-be kapcsolása nélkül is, az épp aktuális rádiós viszonyok függvényében, és a vezetékes világban megszokott, gyakorlatilag kétállapotú összeköttetések (a mesh gráf élei) -- amelyek ugye vagy működnek vagy nem -- helyett előfordulhatnak olyan "működő" kapcsolatok, amelyek érdemi információtovábbításra nem alkalmasak, mert igen jelentős rajtuk a csomagvesztés.
A legizgalmasabb az egészben, hogy új irányító protokollokat tesztelnek és hasonlítanak össze egymással ezen a mesh hálózaton. Részt lehet venni bármilyen nyílt forrású implementációval, ami működőképes OpenWRT alatt. Az külön poén, hogy ilyenek tényleg vannak, a felhívás szerint ezen a negyedik mesh találkozón a Babel, a B.A.T.M.A.N., a BMX (B.A.T.M.A.N. Experimental) és az OLSR protokollok biztosan szerepelnek. Egy picit utánaolvastam mindnek, és találtam egy összehasonlító elemzést is, amely szerint a Babel a nyerő.
Ezek után a Babel doksit végig is nyálaztam, kiderült, hogy ez egy új távolságvektor-alapú protokoll, az említettek közül ez a legfiatalabb, kifejezetten mesh wifihez készült, de állítólag vezetékes környezetben is megállja a helyét. A teljesség igénye nélkül a protokoll néhány fontosabb jellemzője:
Gyaníthatóan ez a kis összegzés több kérdést vet fel, mint amennyit megválaszol, a végső válaszok a protokoll dokumentációjában érhetők el.
Némi kutakodás után, bár sokkal okosabb nem lettem, arra jutottam, hogy ez valamiféle perverz geek találkozó, ahol tényleg foglalkoznak wifivel, de a hangsúly nem ezen van, hanem a routingon. Egy-egy ilyen esemény alkalmával összedobnak egy mesh hálózatot, amelyben minden egyes eszközön (a mesh gráf csúcsai) routeolás folyik és valamilyen irányító protokoll fut.
Itt jön a lényeg, hogy milyen protokollt érdemes választani? A rádiós hálózatok ugyanis a vezetékesekkel szemben számos meglepetést tartogathatnak. Változhat például a topológia az eszközök mozgatása, ki-be kapcsolása nélkül is, az épp aktuális rádiós viszonyok függvényében, és a vezetékes világban megszokott, gyakorlatilag kétállapotú összeköttetések (a mesh gráf élei) -- amelyek ugye vagy működnek vagy nem -- helyett előfordulhatnak olyan "működő" kapcsolatok, amelyek érdemi információtovábbításra nem alkalmasak, mert igen jelentős rajtuk a csomagvesztés.
A legizgalmasabb az egészben, hogy új irányító protokollokat tesztelnek és hasonlítanak össze egymással ezen a mesh hálózaton. Részt lehet venni bármilyen nyílt forrású implementációval, ami működőképes OpenWRT alatt. Az külön poén, hogy ilyenek tényleg vannak, a felhívás szerint ezen a negyedik mesh találkozón a Babel, a B.A.T.M.A.N., a BMX (B.A.T.M.A.N. Experimental) és az OLSR protokollok biztosan szerepelnek. Egy picit utánaolvastam mindnek, és találtam egy összehasonlító elemzést is, amely szerint a Babel a nyerő.
Ezek után a Babel doksit végig is nyálaztam, kiderült, hogy ez egy új távolságvektor-alapú protokoll, az említettek közül ez a legfiatalabb, kifejezetten mesh wifihez készült, de állítólag vezetékes környezetben is megállja a helyét. A teljesség igénye nélkül a protokoll néhány fontosabb jellemzője:
- A Babel által használt metrika a prokollt futtató szomszédos eszközök közötti kommunikációra épül, az eszközök Hello üzeneteket küldenek szomszédaiknak, amelyekre azok az "I Heard You" (IHU) választ kapják. Az üzenetváltások sikeressége alapján a babeles eszköz költséget számol minden egyes szomszédjához, értelemszerűen a költség annál kisebb, minél kevesebb a sikertelen üzenetváltás.
- A protokoll alapvetően a Bellman-Ford algoritmusra épít (periodikus frissítések minden szomszédtól és ezen frissítések alapján a legalacsonyabb költségű útvonal kiválasztása, illetve a végtelenig számlálás), bizonyos megszorításokkal.
- Ilyen megszorítás, hogy egy adott router nem vesz tudomást egy másikhoz vezető frissítésekről, amíg azok kisebb költségűek, mint a rajta nyilvántartott eddigi legkisebb költség az adott célhoz (a nagyobb költségűeket pedig épp azért hagyja figyelmen kívül, mert ott nagyobb a költség, így nem éri meg átváltani rájuk).
- Az előző pont, bár megakadályozza a hurkok kialakulását, a topológia módosulásakor route-ok használhatatlanná válásához vezet, ezért a Babel által küldött frissítésekben szekvenciaszámok is szerepelnek, és egy frissítés átmegy a szűrőn, ha a szekvenciaszám nagyobb, mint az eddig látott szekvenciaszám.
- A szekvenciaszám növelését kérhetik is a routerek egymástól, minden routernek saját szekvenciaszáma van. A szekvenciaszám-növelési kérelmek jelentősen felgyorsítják a konvergenciát.
- Ha azonos prefixet meghirdet több eszköz is, akkor azokat a prefixeket a Babel külön entitásként kezeli, vagyis mindenki a hozzá "közelebbi" forrást fogja használni.
- Támogatja az IPv4-et és az IPv6-ot is.
Gyaníthatóan ez a kis összegzés több kérdést vet fel, mint amennyit megválaszol, a végső válaszok a protokoll dokumentációjában érhetők el.
2011-03-02
DHCP relay agent NAT-olt hálózatban: esélytelen
Adott egy telephelyünkön egy több subnetre osztott LAN, minden subnetben a LAN router a DHCP relay agent, ez így eddig tiszta sor, semmi meglepő nincs benne. Na most vannak persze olyan subnetek is ezen a telephelyen, amelyek nincsenek Layer 3 összeköttetésben a telephely egyéb részeivel, ezer oka lehet, a legtöbb persze nem szakmai, mindenesetre ilyesmi dolgot kell elképzelni:
A gondok természetesen akkor kezdődnek, amikor a 192.168.1.0/24-ben mégiscsak akadnak hostok amelyek a többi subnettel kommunikálnának. Persze ilyenkor a network admin kaján vigyorral közli, hogy látjátok-látjátok, nem kellett volna azt a subnetetet így oda tenni, megmondtuk mi annak idején, hogy olyan hálózatot válasszatok, ami illeszkedik a globális címzési rendszerünkbe és a telephelyen használt supernetben benne van.
Aztán a vigyor, meg a címzési tervek gyorsan eltűnnek, amikor kiderül, hogy itt most nem "légből kapott", "ködös" elvekhez kell ragaszkodni, hanem a felmerülő üzleti igényeket kell gyorsan, pontosan kiszolgálni, és nincs apelláta: a 192.168.1.0/24-nek tudnia kell kommunikálni, most, nincs sem idő, sem erőforrás, sem hajlandóság az utált subneten belüli 150+ statikus IP-s hoston címváltásra (vagyis nem lehet belőle semmilyen körülmények közt sem pl. 10.10.15.0), és igazából csak a VLAN99-ből kell elérni egy-két külső dolgot, "hát már ennyit sem lehet rátok bízni?" stb.
Száz szónak is egy a vége, meg kell patkolni, egy végzetes napon a VLAN99 NAT-olva rácsatlakozik a VLAN10-re. Aztán jönnek az újabb és újabb problémák, amelyek fel sem merülnének ugye, ha a VLAN99 rendes subnet lenne, olyanok például, hogy egyik-másik adatbázis szervert a VLAN99-ben mégiscsak el kellene érni kívülről, legyen port forward, ezt ide, azt oda, akkor persze jön a kérdés, hogy miért nem lehet a belső adatbázis-szervereket kívülről pingelni, aztán újabb és újabb port forwardok, persze az egész rögtön biztonsági kérdéseket is felvet, mert természetesen a VLAN99-ben nincs szabványos kliensvédelem, hiszen az úgyis "szeparált", szóval egy-két év alatt ebből egy teljesen dokumentálatlan össze-vissza rugdosott rendszert lehet felépíteni, amihez senki nem nyúl szívesen, akik meg használják, elégedetlenek.
Na, most ott tart a dolog, hogy a VLAN99-ben be kellene vezetni a központi DHCP szolgáltatást, és persze sikerült ráfutni a DHCP relay agent beüzemelése közben egy elég alapvető problémára: NAT-olt hálózat felé nem fog menni a relayezés, hiszen a relay agent még csak kiküldi a VLAN99-ből a DHCP üzeneteket a DHCP szerver felé, azonban a relay agent és a DHCP szerver közt már unicast forgalom zajlik, amely kommunikációban a relay agent a belső, a DHCP szervertől távolabbi lábának az IP-jével vesz részt (pl. 192.168.1.1), így a DHCP szerver hiába küldené vissza a választ a default gatewayen... Persze így vagy úgy folytatódni fog a hályogkovácsolás, át lehet azt a DHCP-t küldeni ezer más módon.
Az egészben a legbosszantóbb, hogy az üzleti oldal még mindig, sok év után sem látja, hogy itt az alapkoncepció hibás, ugyanakkor újabb és újabb dolgokat építene az ingatag alapokra. Erős IT-t szeretnék, ahol nem engedik ki az IT kezéből az IT-ra tartozó döntéseket.
A gondok természetesen akkor kezdődnek, amikor a 192.168.1.0/24-ben mégiscsak akadnak hostok amelyek a többi subnettel kommunikálnának. Persze ilyenkor a network admin kaján vigyorral közli, hogy látjátok-látjátok, nem kellett volna azt a subnetetet így oda tenni, megmondtuk mi annak idején, hogy olyan hálózatot válasszatok, ami illeszkedik a globális címzési rendszerünkbe és a telephelyen használt supernetben benne van.
Aztán a vigyor, meg a címzési tervek gyorsan eltűnnek, amikor kiderül, hogy itt most nem "légből kapott", "ködös" elvekhez kell ragaszkodni, hanem a felmerülő üzleti igényeket kell gyorsan, pontosan kiszolgálni, és nincs apelláta: a 192.168.1.0/24-nek tudnia kell kommunikálni, most, nincs sem idő, sem erőforrás, sem hajlandóság az utált subneten belüli 150+ statikus IP-s hoston címváltásra (vagyis nem lehet belőle semmilyen körülmények közt sem pl. 10.10.15.0), és igazából csak a VLAN99-ből kell elérni egy-két külső dolgot, "hát már ennyit sem lehet rátok bízni?" stb.
Száz szónak is egy a vége, meg kell patkolni, egy végzetes napon a VLAN99 NAT-olva rácsatlakozik a VLAN10-re. Aztán jönnek az újabb és újabb problémák, amelyek fel sem merülnének ugye, ha a VLAN99 rendes subnet lenne, olyanok például, hogy egyik-másik adatbázis szervert a VLAN99-ben mégiscsak el kellene érni kívülről, legyen port forward, ezt ide, azt oda, akkor persze jön a kérdés, hogy miért nem lehet a belső adatbázis-szervereket kívülről pingelni, aztán újabb és újabb port forwardok, persze az egész rögtön biztonsági kérdéseket is felvet, mert természetesen a VLAN99-ben nincs szabványos kliensvédelem, hiszen az úgyis "szeparált", szóval egy-két év alatt ebből egy teljesen dokumentálatlan össze-vissza rugdosott rendszert lehet felépíteni, amihez senki nem nyúl szívesen, akik meg használják, elégedetlenek.
Na, most ott tart a dolog, hogy a VLAN99-ben be kellene vezetni a központi DHCP szolgáltatást, és persze sikerült ráfutni a DHCP relay agent beüzemelése közben egy elég alapvető problémára: NAT-olt hálózat felé nem fog menni a relayezés, hiszen a relay agent még csak kiküldi a VLAN99-ből a DHCP üzeneteket a DHCP szerver felé, azonban a relay agent és a DHCP szerver közt már unicast forgalom zajlik, amely kommunikációban a relay agent a belső, a DHCP szervertől távolabbi lábának az IP-jével vesz részt (pl. 192.168.1.1), így a DHCP szerver hiába küldené vissza a választ a default gatewayen... Persze így vagy úgy folytatódni fog a hályogkovácsolás, át lehet azt a DHCP-t küldeni ezer más módon.
Az egészben a legbosszantóbb, hogy az üzleti oldal még mindig, sok év után sem látja, hogy itt az alapkoncepció hibás, ugyanakkor újabb és újabb dolgokat építene az ingatag alapokra. Erős IT-t szeretnék, ahol nem engedik ki az IT kezéből az IT-ra tartozó döntéseket.
Feliratkozás:
Bejegyzések (Atom)