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.

BGP gondok Juniper és Fortigate eszközök közt

Másfél hete volt egy igen kellemes leállásunk. Az ERP rendszerünk ki van szervezve külső szolgáltatóhoz, ahová rendeltünk egy bérelt vonalat és van egy backup VPN tunnelünk is. Ez elvileg ugye teljesen kerek, a bérelt vonal és a VPN-hez használt internet két különböző szolgáltatótól jön, BGP-t futtatunk mindenhol, a megoldás ki volt tesztelve átadáskor, gond egy szál sem, minden ment, a BGP peerek látták egymást bérelt vonalon és a VPN-en is, a bérelt vonal megszakításakor a forgalom gond nélkül átállt a backup VPN-re, ráadásul a peer-ek maguk is redundáns eszközök, szóval nagyjából tankönyvi megoldás volt, látszólag.

Na, ehhez képest két hete pénteken világvége volt, megállt az ERP site felé a bérelt vonal, mert valahol Észak-Európában elvágtak egy optikát, a backup VPN tunnel pedig hiába működött, az ERP site-ról nem jöttek a BGP frissítések, így nem volt elérhető az ERP rendszerünk.

Villámgyors megoldásként néhány jól irányzott statikus route jól jött volna, de a site-to-site VPN ki van szervezve (network teamen kívüli, felülről jött döntés), a VPN eszközeinkhez kizárólag read only hozzáférésünk van, csak a VPN szolgáltató helpdeskjén keresztül kérhetők módosítások. A másik oldal, az ERP site szintén ki van szervezve, az ottani VPN eszköz része az ERP szolgáltatáscsomagnak, szintén csak (egy másik) helpdesken keresztül érhető el. Na most el lehet képzelni, hogy micsoda tempóban oldódnak meg az ilyen helpdesk kérések, főleg ha két, egymástól független szolgáltatónak kell együttműködnie. Nagyjából mire megjavult a bérelt vonal, addigra állt össze a BGP peering is az ERP site és a VPN hubunk közt. A network team meg begyűjtött egy kb. hatórás ERP leállást.

Az az érdekes, hogy senki nem tudja, mitől állt meg a backup VPN-en a BGP. Illetve nem is állt meg teljesen, a VPN hubtól érkező prefixeket ERP site-on futó eszköz látja, viszont az ERP site-ról nem érkezik semmi a VPN hubhoz. A VPN hub egy Fortigate 620B cluster, az ERP site-on pedig valamilyen Juniper holmikon futó virtuális eszközöket kaptunk VRRP-ben. Az ERP-s network supportosok szerint a Juniper virtuális eszközünkön nincs olyan parancs, mint az IOS-ben show ip bgp neighbors x.x.x.x advertised-routes, így nem tudják megnézni, hogy mit küldenek adott BGP peer felé. A Forigate eszközön pedig eltűnt a neighborök közül a Juniper eszköz.

Megoldás gyanánt mind a Fortigate mind a Juniper eszközökön újraindították a BGP processzt, amitől a dolog megjavult (tehát nem tűzfalas gond volt), de nem vagyok meggyőződve arról, hogy ez hosszú távon is működőképes lesz. Ma kaptunk backup VPN éles tesztelésre egy kis időt, és ma éppen minden működött úgy, ahogy kell, de nem volt igazán meggyőző az ERP szolgáltatónknál dolgozó networkös kolléga, aki a múltkori állás okaival kapcsolatban annyit mondott, hogy "bad luck". Statikus route lesz a vége, már látom előre.

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

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.