VLAN-ok kezelése MikroTiken

Vannak bizonyos megoldások a MikroTik RouterOS-en, amelyek, hát... legalábbis furcsának tűnnek egyéb network OS-ekhez képest, az egyik ilyen a VLAN-ok kezelése. Nem létezik olyasmi RouterOS alatt, hogy access port vagy trunk port, az van, amit összedrótozgatunk. Az alábbi parancsok például VLAN 1-3-ig, tagged VLAN kezelést biztosítanak az ether1 interfészen:

/interface vlan
add name="VLAN1" vlan-id=1 interface=ether1 disabled=no
add name="VLAN2" vlan-id=2 interface=ether1 disabled=no
add name="VLAN3" vlan-id=3 interface=ether1 disabled=no

Persze ezzel önmagában sokra nem megyünk, hiszen valahová tovább is kell kapcsolni ezeket a VLAN-okat, mondjuk access portokra. A következő döbbenet akkor éri a kezdő mikrotikest (például engem is), amikor kiderül, hogy amit mindenhol máshol access portnak hívnak, az itt tulajdonképpen nincs, de amit tehetünk, hogy mégis legyen, az sem az, hogy VLAN-okba tesszük a portokat, hanem:

/interface bridge
add name="BR1" disabled=no
add name="BR2" disabled=no
add name="BR3" disabled=no
/interface bridge port
add bridge=BR1 interface=ether2 disabled=no
add bridge=BR1 interface=ether3 disabled=no
add bridge=BR2 interface=ether4 disabled=no
add bridge=BR2 interface=ether5 disabled=no
add bridge=BR3 interface=ether6 disabled=no
add bridge=BR3 interface=ether7 disabled=no

Amint az a példából látható, a BR1 nevű bridge-hez az ether2-3, illetve a wlan1 port tartozik, a BR2-höz a ether4-5, a BR3-hoz pedig az ether6-7. Az itt definiált portcsoportok különálló VLAN-okként viselkednek, de természetesen az égvilágon semmi közük nincs az ether1 interfészen létrehozott trönkhöz, és az azon élő három tagged VLAN-hoz (némiképp emlékeztet egyébként mindez az autonóm Cisco AP-ken használatos BVI bridge group interfészekre). Az uplinken bejövő tagged VLAN-ok és a BR1, BR2, BR3 bridge-ek között úgy hozhatunk létre kapcsolatot, hogy a VLAN neveinkhez tartozó virtuális interfészeket szintén bepakoljuk a bridge-ekbe:

/interface bridge port
add bridge=BR1 interface=VLAN1  disabled=no
add bridge=BR2 interface=VLAN2  disabled=no
add bridge=BR3 interface=VLAN3  disabled=no

Ezzel eljutottunk oda, hogy az ether1-en bejövő tagged adatok megtalálják az útjukat az adott VLAN-on belül a MikroTik eszközre kapcsolt hostokig. De itt még nincs vége, ez csak az a módszer, ami minden MikroTik-en működik, egyes RouterBOARD-oknál ettől eltérő megoldást is lehet használni, attól függően, hogy milyen switch chip található a NYÁK-on. A RouterOS ugyanis nem fedi el a hardveres lehetőségeket, vannak hardverspecifikus parancsok a VLAN-ok kezelésére. A wiki.mikrotik.com-on található egy táblázat, ebből ki kell keresni, hogy a MikroTik eszközünkben milyen switch chip található, hogy támogatja-e a chip a port tükrözést, mekkora CAM táblát tud kezelni (MikroTik esetén ezt host table-nek hívják), vagy éppen azt, hogy hány VLAN-nal képes megbirkózni, és utána készíthetünk az adott switch chipre szabott VLAN konfigurációt, ami más RouterBOARD-on működésképtelen lehet. Beteges, nem igaz?

A LAN mint szolgáltatás

Már az előző poszt is esélyes volt a legalja címkére, de ott a mókolási faktor sokat emelt rajta, ez viszont tipikus legalja lesz, valahogy nálam ez gyakran a kiszervezéssel párosul. Van két telephelyünk messze-messze, ahol a LAN-t eszközöstül, mindenestül szolgáltatásként vesszük egy helyi IT-s cégtől. Ez teljesen rendben lévőnek hangzik, elvileg ugye a szerződésben definiálva vannak a szolgáltatási szintek (SLA), reakcióidők, felelősök stb. ezt a szolgáltatást legalább öt éve igénybe vesszük, bizonyos időközönként automatikusan megújul, az azért mindenesetre furcsa, hogy a pontos részleteket a network team nem ismeri, illetve az utóbbi időkben kiderültek érdekes dolgok. Mentségünkre szóljon, hogy senki nincs már a cégnél, akinek köze lehetett ennek a szerződésnek megkötéséhez, és valahogy a pozíciók átadása-átvétele körül elsikkadtak a részletek.

Az egyik ilyen dolog, hogy a szolgáltató reakciói alapján meg voltunk győződve, hogy legjobb esetben is csak 5/8-as támogatást várhatunk tőlük nem túl sebes megoldási időkkel. Bizonyos WAN átszervezések kapcsán az egyik említett telephelyen szükség volt némi LAN változtatásra, új VLAN-ok, link subnetek, ilyesmi, és sehogy nem tudtuk a karbantartási ablakot beletuszkolni az 5/8-as munkaidőkeretbe. Szóval már épp azon gondolkodtunk, hogy megkérjük a LAN szolgáltató céget, hogy vállaljanak az 5/8-as időkereten kívül munkát, amikor a főnököm főnöke közölte a szerződésre hivatkozva, hogy bizony 7/24 Gold++++  supportunk van, bármikor kérhetünk módosításokat.

Voltak azonban korábban is gyanús jelek: tavaly bekértem tőlük mindkét telephelyről a layer2-es dokumentációt, mert semmit nem találtam ezekről a site-okról, de azt válaszolták, hogy ilyesmi nekik sincs, viszont tudnak készíteni, ha kérjük. Különösebb gondolkodás nélkül rávágtam, hogy kérjük, bár már akkor sem értettem, hogyan tudnak támogatni olyasmit, amiről alapvető dokumentációk hiányoznak. No, el is készült a kért anyag, mivel nem túl nagyok a telephelyek, 2-300 port mindkettő, a layer2-es ábrák eszközökkel, VLAN színekkel, IP-kkel együtt is csupán 2 oldalt tettek ki. Egy hónap múlva jött egy belsős telefon, hogy milyen szolgáltatást kértem ettől a cégtől, és hol van az általuk küldött dokumentáció, merthogy dokumentáció címén egy 1000 euró + forgalmi adós tételünk van. Mondanom sem kell, azóta is nagy becsben tartjuk azt a PDF-et, mind a két oldalát.

Ezek után már azon cseppet sem csodálkoztam, amikor jöttek az újabb telefonok, hogy a konfiguráció módosításáért, akkor is, ha az csak egyetlen sor, száz eurót számolnak fel, a több ezer eurós havidíjon felül. Ilyenből is gyűjtöttünk egy párat az elmúlt időszakban.

A legjobb viszont mostanában történt, az egyik ilyen kiszervezett LAN-os telephelyen a felhasználók elkezdtek panaszkodni, hogy szakadozik a kapcsolatuk, hálózati problémáik vannak. A WAN hibakeresés semmilyen gondot nem mutatott, sőt, WAN szempontból kivételesen jó helyzetben van az említett telephely mind sávszélességet, mint késleltetést illetően, csomagvesztésről pedig gyakorlatilag nem volt historikus adat a monitorozó rendszerben, így hamar előkerült a LAN, mint lehetséges hibaforrás. Igen ám, de mi nem férünk hozzá az ottani eszközökhöz, így hibajegyet nyittatunk a szolgáltatónál, részletes hibajelenségekkel, időpontokkal, user kontakt információkkal stb. Ez történt egy pénteki napon. Aznap a hibajegy megnyitásán túl sokra nem jutottak (7/24-es support, néhány órás elhárítási idővel!). A következő hét elején már állt a bál, mert a probléma még mindig élt, megoldás sehol, mi meg csak a kezünket tudtuk széttárni, hiszen az adott telephelynek még a közelében sincs  networkös, az eszközöket pedig nem akartuk újraindíttatni hátha van valami a logokban. Ekkor már direkben megadtuk a szolgáltató elérhetőségét a felhasználóknak is, és végül sikerült nekik szerdára (!) kihívatni egy hálózati mérnököt. A mérnök kijött, szétnézett a rendezőhelyiségekben, tett néhány megjegyzést arra vonatkozólag, hogy 10+ éves eszközökön fut a LAN (amit ők szolgáltatnak), és hogy látott egy-két kósza hub-ot is, meg hogy milyen kevés log-ot tudnak tárolni ezek az öreg eszközök, majd elment úgy, hogy nem volt megoldás. Naivan azt gondoltam, hogy átnézi majd legalább a trönk portok konfigurációit, az STP beállításokat, vagy végez valamilyen tesztet, hoz esetleg gyártóspecifikus szoftvert, amivel adatokat gyűjt, leszűkíti a probléma forrását bizonyos eszközre, eszközökre, vagy hogy egyáltalán csinál valamit, bármit. A végén a mérnök távozása után maguk a felhasználók lokalizálták a probléma forrásaként az egyik switchet, majd arról átköttettek mindent az ottani IT-s sráccal más eszközökre. Máig nem tudjuk, mi baja lehetett annak a switchnek. Arra azért kíváncsi lennék, mennyit fizethettünk a kiszállásért, csak gyanítom, hogy ez ismét az ezer eurós kategória lehetett...

Ez az esemény viszont végre beindított valamit: döntés született arról, hogy ennek a cégnek mennie kell, és insourceolva lesz a LAN, mert ezt a szolgáltatási szintet lazán megugorjuk belső erőforrásokkal, több országnyi távolságból is. Azt már végképp nem értem, hogy miképp és miért, de mindkét telephelyen kiderült, hogy raktárban állnak öt év körüli Nortel eszközeink az 5000-es szériából, 8000-es szériából, nem is kevés, összesen kb. 1300 portnyi, szóval van miből kukázni -- enyém a megtisztelő feladat, hamarosan utazhatok. Addig is fel kell szívnom magam Nortel (mostanában Avaya) CLI-ből, legalább az olyan alap témákban mint a VLAN, STP, naplózás, SNMP, port security, basic routing, DHCP relaying, stacking, firmware kezelés, mert annyira nem mozgok otthonosan Nortel/Avaya fronton, viszont néhány hét múlva már rutinosan kell mennie.

PPPoE VLAN interfészen Vyatta alatt

Délután hosszasan vesződtem azzal, hogy egy VDSL modem mellé bekonfiguráljak egy Vyatta 6.2-es rendszert. Nem voltak nagy igények, csak a szokásosnak mondható dolgok, SPI tűzfal, NAT, DHCP, ilyesmi. Az egyetlen szokatlan dolog, hogy a Vyatta rendszerben egyetlen NIC-en, VLAN-okkal szerettem volna megoldani a LAN és a WAN kapcsolatot. Az interfész konfiguráció tehát első blikkre kb. így nézett ki:

interfaces {
    ethernet eth0 {
        duplex auto
        hw-id aa:aa:aa:aa:aa:aa
        speed auto
        vif 2 {
            pppoe 0 {
                connect-on-demand
                default-route auto
                mtu 1492
                name-server auto
                password DSLpassword
                user-id DSLusername
            }
        }
        vif 3 {
            address 192.168.0.1/24
        }
    }
    loopback lo {
    }
} 

Mondanom sem kell, nem ment. De hát mi a fene baja lehet? A modem elérhető volt a 2-es VLAN-on, a LAN oldalon is rendben volt a 3-as VLAN, a tesztkliens LAN oldalon megkapta DHCP-vel a szükséges adatokat a Vyattától, de valamiért a PPPoE nem jött össze. Persze rögtön kipróbáltam, hogy közvetlenül a modembe dugom a tesztklienst: csatlakozott. Jó, akkor lépjünk tovább, a tesztkliens VLAN2-ben, switchen keresztül vajon csatlakozik-e? Persze, így is működik. Hm... vajon a Vyatta-hoz használt trönk port jó? VLAN2 és VLAN3 is tagged, ahogy a Vyattán konfiguráltam? Ezzel sem volt gond. Akkor talán a Vyatta rendszerben használt NIC problémás? Neeem, simán kezeli a VLAN-okat, nincs vele gond.

Turkáltam a Vyatta doksikban, ez, ha lehetséges, még kevesebb eredménnyel zárult, hiába van a rendszerhez 1000+ oldal dokumentáció, arról, hogy Ethernet interfészen hogy lehet PPPoE-t beállítani, nem sokat mesélnek, a DSL-es példák is egytől egyig az előfizetéses SE verziójú Vyattában használható DSL modemkártyák beizzításáról szólnak, PPPoE over VLAN sehol.

Rendben, gondoltam, ha nincs más, akkor belenézünk tcpdumppal. Igen ám, de mibe? Kiderült, hogy a fizikai interfészen egy árva PPPoE-vel kapcsolatos bit sem megy át, se PADI, se PADO, semmi, hiába próbálgatom a connect interface pppoe0 parancsot. Itt azért már gyanús volt, hogy valami vyattás hülyeségbe szaladtam bele, talán nem is támogatott lehetőség a PPPoE over VLAN vagy hasonló.

Végül a Google kiköpte a választ, nem a PPPoE over VLAN a hiba forrása. Persze azóta elkevertem a linket, és már nem emlékszem, hogy mire kerestem pontosan, de mindegy is, a lényeg, hogy egy vyatta.org-os fórumbejegyzésben egy Vyatta alkalmazott leírta, hogy már egy ideje gond van ezzel a connect-on-demand dologgal, és ha azt kiszedjük a konfigból, minden jó lesz. És tényleg, a delete interfaces ethernet eth0 vif 1 pppoe 0 connect-on-demand parancs kiadása után minden a helyére került. Megjegyzem, ez azért bénaság egy olyan feltörekvő networkös cégtől, amelyik a vállalati piacra szeretne betörni. Kíváncsi lennék, hogy vajon csak az ingyenes Vyatta szoftververziókban van-e ilyen hiba vagy az előfizetéses változatokban is?

A tűzfalazás magasiskolája

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

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 szórási tartományok méretéről

Néhány éve, amikor elkezdtem a jelenlegi munkahelyemen dolgozni, egyszerűen sokkolt a gondolat, hogy azon a telephelyen, ahol én is ügyködni fogok, teljesen strukturálatlan a LAN layer3-ban. Az adott telephely legtöbb munkaállomása, a notebookok, a nyomtatók, a szerverek, a termelési gépek, az ilyen-olyan célhardverek, biszbaszok, beágyazott rendszerek, a hálózati eszközök management felülete, a szerverek iLO/RMC portjai, de még a céges wifi is egyetlen nagy /21-es hálózatban élt egymás mellett.

Komolyan azt gondoltam, hogy itt vége a világnak, hogy ez maga a fertő, a networkös pokol. Persze tudtam, hiszen korábban az interjúk során is elmondták, hogy az alkalmazásom egyik oka épp ez, hogy vannak úgymond anomáliák ezen a telephelyen, amiket meg kellene oldani, és hogy addig nem volt teljes állásban hálózatos ember. Mondanom sem kell ugye, minden létező szakkönyv szerint ellenjavallt az ilyen bazi nagyra felhízlalt broadcast domain, amiben még a legcsendesebb éjszakákon is működget nagyjából 1000 host, de volt olyan időszak, amikor a /21-es hálózat 2000-es gépszáma is elérhető távolságba került.

Most már lassan három éve élek együtt ezzel a dinoszaurusszal a munkahelyemen, és persze az évek során számos dolog letisztult, nagyon sok host, sok munkával, szervezéssel külön VLAN-okba került, innen is csippentettünk egy kicsit, onnan is, ezeknek a hostoknak ilyen VLAN, amazoknak amolyan került, de alapvetően a harminc-egynéhány VLAN mellett a  /21-es nagy hálózat ma is létezik, rengeteg benne a gazdátlan, fix IP-s host, melyek adminisztrációjával senki nem akar törődni, egészen addig, míg nincs vele valami baj, szóval a telephely életébe, működésébe szó szerint ezer szállal bele van fűzve a /21-es monstrum.

Azt gondolná az ember, hogy az elképzelhetetlen mennyiségű broadcast forgalom miatt itt nincs egyetlen ép host sem, de a helyzet valójában nem annyira vészes. A broadcast forgalom legnagyobb része egyébként az SMB/CIFS balgaságaiból adódik, rettenetesen szószátyár ez a protkollcsalád, és persze nálunk is SMB/CIFS-et natívan beszélő Microsoft OS-ek vannak leginkább a hostokon. De még ennek ellenére is az átlagos broadcast terhelés nagyából megáll 50-70 kbit/s környékén. Multicastot nem használunk, az egyetlen dolog, ami még rondíthat ezen az 50-70 kbit/s-on, az az elárasztásos (flood) forgalom. Ilyen floodként jelentkezik a switchek által nem ismert MAC-címre történő forgalmazás, amit a broadcast domain minden hostja megkap, mert a switch nem tudja, hogy melyik portjára switchelje, így kiteszi mindegyikre - sajnos vannak olyan "megoldások", amelyek építenek is erre az egyébként nem kívánatos jelenségre.

Hogy mit tapasztalhat az ember 50-70 kbit/s állandó broadcast mellett? Semmit. Nevetségesen kicsi ez a forgalom az elérhető 100 vagy 1000Mbit/s-os sebességhez viszonyítva, nincs érezhető, mérhető hatása a hostok működésére. Sajnos emiatt a döntéshozók sem értik meg az IP szegmentáció mielőbbi szükségességét. Biztos vagyok benne, hogy még csak nem is feszegetjük a technológia határait, és hogy egy hostokkal megpakolt /20-as vagy akár egy /19-es is működőképes lenne.

Azt azért nem állítom, hogy soha nincs gond egy ilyen méretű hálózattal alapvetően magára a méretére visszavezethető okok miatt. Egyszer például néhány kolléga úgy látta jónak, ha Norton Ghosttal, anélkül, hogy bármilyen hálózati támogatás lett volna hozzá, multicast üzemmódban terítenek image-eket néhány gépen. A switchek persze azonnal broadcastba fordították a multicast forgalmat, és tolták minden portjukon, ami csak a csövön kifért. Na, ezt már mindenki megérezte, 80 Mbit/s egy ekkora hálózat minden portján azonnal látványos eredmény ad. De ez egy extrém példa, és nem áll neki bárki multicast Ghost terítésnek, viszont látható, hogy ha a napi rutinfeladatokon nem is vérzik el a nagy szórási tartomány, biztonsági szempontból semmiképp nem javasolt.

Meggyőződésem, hogy amennyiben valaha is megszűnik ezen a telephelyen a /21, az biztonsági problémák miatt lesz. Gondoljunk csak bele, hogy egy ekkora szórási tartomány micsoda lehetőségeket tartogat a különféle layer2-es támadásokra, ARP spoofingra, STP támadásokra, de még egy egyszerű passzív broadcast forgalom gyűjtögetés is rengeteg értékes információval szolgál.Őszintén szólva nem is szeretek rá csatlakozni, inkább megyek wifin, ami azóta külön subnetbe került vagy remote access VPN-en (szintén külön subnet). Csak a kollégáim meg ne tudják... (tudják) :)

A legjobb szolgáltató

Alapvetően nem szeretném, ha a blog szolgáltatók vagy termékek fikázásáról szólna, de a mai esetet muszáj megírnom. A cégünknél az összes telephely esetén a külső tűzfalak, illetve a s2s VPN hálózat üzemeltetése ki van szervezve. Nos, ettől a cégtől kerestek ma telefonon, hogy nem érik el az egyik telephelyünkön az eszközüket, és hogy tudok-e erről valamit.

A kérdéses telephelyen kizárólag s2s VPN van, semmilyen egyéb bérelt vonali kapcsolat nem áll rendelkezésre. Kicsit furcsálltam azonban a dolgot, mert a telephelyen lévő monitorozott hostok mindegyike elérhető volt, semmilyen riasztást nem kaptunk kapcsolódó problémákról, szóval, semmi jelét nem láttam annak, hogy bármilyen probléma lenne az ottani tűzfallal vagy a VPN tunnellel.

Nem is volt, az egyetlen gond az volt, hogy a szolgáltatás kb. egy hónappal ezelőtti telepítése óta a külső cég nem készített az adott eszközön magának management VPN tunnelt, pedig ezt annak idején a kollégám nyomatékosan kérte tőlük, épp azért, hogy ne legyen probléma a tűzfal általuk történő adminisztrációjával. Ma viszont valamilyen különös okból kifolyólag észrevették ezt problémát.

Ezek után tehát felhívnak telefonon, hogy valószínűleg megállt az adott telephelyen a szolgáltatásuk, és hogy tapasztalunk-e bármilyen problémát? Mondom a servicedeskesüknek, hogy nem, sőt a VPN és a tűzfal szolgáltatás is üzemel a saját monitorozó rendszereink adatai alapján. "Hm... ez igazán jó hír" - jött a válasz - "Elnézést a zavarásért. Annyit még tudna segíteni, hogy mi a külső IP címe az adott telephelyen az eszközünknek?".

No, az hiszem, ennél a pontnál foszlott szét minden kiszervezett szolgáltatásba vetett hitem, ha volt ilyesmim egyáltalán, hiszen a szolgáltató a szolgáltatásával kapcsolatos alapvető adatokat, dokumentációkat nem ismeri (pl. külső IP cím), nem képes monitorozni azt a saját rendszerivel (management VPN tunnel hiánya), ráadásul a saját eszközével kapcsolatos probléma elhárításához tőlem, az ügyféltől kér segítséget... és persze a negyedév végén mindezért benyújtja a számlát is. Ez a tökéletes üzleti modell, valóságos aranybánya, ilyet szeretnék magamnak én is.