Ugrás a fő tartalomra

Post, amivel jó ideje tartozok a Fortinet számára

Néhány hete pörgettem a linkdenin feed-et és fennakadt a szemem egy post-on. A bejegyzés rövid lényege annyi volt, hogy a Fortinet SD-WAN megoldása nem igazán jó multitenant környezetre VPN-re túl komplex és satöbbi és satöbbi... 

Nem véletlen indítottam Gartner Magic Quadrant-al, mert a személyes tapasztalataim, egészen mást mutatnak a gyártó ezen technológiájával kapcsolatban.

Röviden sok-sok csúsztatást tartalmazott és olyan hatást kelthetett, hogy xy gyártóhoz képest a Fortinet nagyon el van a maradva a piaci elvárásoktól (persze  nem mindegy melyik piac elvárásait kell nézni). 

Egy kicsit elgondolkodtam rajta és megállapítottam, magamban, hogy bástya olyan 10 évvel ezelőtt még egyet is értettem volna veled, de ma már egészen más helyzet, hiszen a gyártó sokat, ha nem a legtöbbet fejlődött ezen a téren az iparág többi részéhez képest és messze jár már Secure SD-WAN témakörben. Ezen a ponton bekapcsolt a lelkiismereti faktor, hiszen - jó pár éve már - de egy hasonló gondolkodásmódú cikket írtam, így annak helyesbítése gyanánt írok most néhány gondolatot a Fortinet SD-WAN megoldásról.

SD-WAN vagy NINCS  - Fortinet IGEN WAN!

A Fortinetnek sikerült "ráéreznie", hogy az SD-WAN fabric kialakításoknak a legnagyobb hibája a FABRIC marketing bullshithben rejtőzik, hiszen ezt jó néhány szakma beli instant vendor/technolgia lockin-nek érzékeli, helyesen. 

Hiszen, ha abc vagy xyz SD-WAN megoldását választod, akkor a telephelyeid összekötése / bekötése a központba onnantól csak a teljes stack összerakásával és alkalmazásával érhető el. Minden esetben teljes SD-WAN architektúrát kell összeraknod, aminek igen nagy "overhead"-je tud lenni egy cde gyártónál, hiszen a "valódi" SD (Sofware Defined) jelleg miatt a vezérlési sík (control plane) szerverei nélkülözhetetlenek  az adattovábbítási síkban (data plane) működő eszközök egymás közti kommunikációjához, ráadásul még ott a management is. Habár a rendszer nagyon nagy méretekre skálázható és multitenant képességet hordoz önmagában kis néhány telephelyes ügyfelek számára nem jó megoldás egy ilyen FABRIC kényszeredett alkalmazása.

Jó de a Fortinet-nek is vagy SECURITY Fabric megoldása az mié nem vendor lockin?


Nos a Fortinet Security Fabric egy opcionális funkció, amit, ha akarsz alkalmazol és bekötöd a végpont védelemtől a switchen át a log gyűjtésig mindent is a fabric-ba, ha nem akarod akkor pedig mindenre van 3rdParty megoldáshoz csatlakozási felület (API,  RADIUS / LDAP protocol stb...)

Ennek a megoldásnak a legnagyobb előnye a moduláris architektúrában rejlik... és SD-WAN rendszerek esetén is több kialakítású architektúrát építhetünk fel:

1. Manuális Self-orchestrated SD-WAN

A fenti pont röviden a kézi hajtányt jelenti, amikor Te kézzel meghatározod a Data / Control Plane (esetleg a management működését). A FortiGate-ek esetében megvan a lehetőséged arra, hogy központi irányító szerverek nélkül összerakj egy ADVPN támogatott, multi-VRF vagy multi VDOM (Ezt azért nem mindenkinek javaslom) ergo multitenant SD-WAN hálózatot, ahol a forgalom irányítását akár automatizált módon tudod az üzleti logika mentém alakítani. Akár az uderlay hálózat irányába, akár az overlay hálózat irányába. 

Hasonló rendszert cisco DMVPN hálózattal ivrf-el és esetleg policy-based routinggal lehet kialakítani, amiből a Software defined rész hiányzik.

2. Automatikus Self-orchestrated SD-WAN

7.2? vagy 7.4? FortiOS-től elérhető felületen egy wizard, ami segít neked automatikusan kialakítani egy alapkonfigurációt SD-WAN HnS topológiára, CP-vel és DP-vel együtt, ha jól tudom egyetlen feltétel a FortiGate-ek Security Fabric-ba szervezése.

3. Automatikus Cloud-Orchestrated SD-WAN

A FortiGate eszközökön régóta vágyott és jó ideje elérhető funkció, hogy FortiGate Cloud (vagy mittén hogy hívják most) lehetőséget ad arra neked, hogy a eszközöket a Fortinet felhőjéből menedzselve tudod összekattintani az SD-WAN topológiádat. Természetesen a felhő nincs ingyen, de más normális Enterprise gyártóknál is kell érte valamilyen előfizetést kötni az eszközhöz.

Ehhez hasonló például a Meraki megoldása csak kisebb szabadság fokkal, de a Catalystra átnevezett routerek SD-Routing funkciója.

4. Automatic Orchestrated SD-WAN

Miért lett ez külön kategória Cloud-tól? A FortiGate megoldásainál kb mindegy lenne, hogy a menedszement és az orchesztráció honnan zajlik, de más gyártóknál nem így van, hiszen a menedzsment és az orchesztráció módja is befolyásolja a:

  • hardvert és a rajta futó szoftvert
  • a kiegészítő rendszerek alkalmazhatóságát
  • integráció típusát, a 3rdParty támogatást
Így ebben a kategóriában azt a megoldást kell érteni, amikor megépítetted a Központi mendzsment-et, a Központi adatgyűjtést és optimalizáló réteget, és ebbe csatlakoznak be a vezérlési sík és az adattovábbítási sík elemei.

A FortiGate-ek esetén megvan a lehetőséged arra, hogy a fenti 4 ponton végig evolválva tudj architektúrát alakítani. A mai világban az architektúrának nem csak a stabilitása fontos, hanem a rugalmassága, ami lehetővé teszi a cégek számára a fejlődési utat, és úgy gondolom, hogy minden cég a saját érettségi szintjének megfelelő módot tud választani egy komplex (mert minden WAN megoldás, ami igazi üzleti értéket terem valamennyire komplex lesz) rendszer bevezetésére.

A korábbi cikkemnek a lezárása tehát a Fortinet architektúrája SD-LETT (teljesen SD-WAN) egy ideje már 🎉.

UI:
"Annak, aki azzal jön, hogy ez egy UTM tűzfal nem való ebbe a rétegbe, pedig azt üzenem, hogy ez egy (harver) appliance, aminek van UTM funkciója is, a HW SW kialakítás pedig ugyanolyan üzembiztossá teszi mint más kisebb tudású appliance-ket, szóval ha akarom használom (Secure) Routernek, nem lesz kevésbé stabil mint a másik gyártó kevesebb tudással (sőtt)"

Fogok még cikket írni a multitenant képességekről...


Érdekesebb bejegyzések

Hálózat-virtualizáció a gyakorlatban - ACI fabric E01

Cisco ACI Kellett már nekünk mint egy falat kenyér, hogy végre történjen ebben VLAN-okba költözött posványos DC rendszerekkel valami... valami új. Mit tegyünk, ha hálózati infrastruktúrát az határozza meg, hogy adott VLAN-ok, hol vagy hol nem szerepelhetnek az infrastruktúrában, ha egy létesítést 8 különböző IT vezetőnek kell jóváhagyni, ha a felelősség tolása másra fontosabb, mint a projekt végrehajtása. Cisco ACI-ról írni nehéz dolog egy olyan alternatív IT valóságban, ami ma Magyarországon van... Mert amíg azzal küzdünk bizonyos helyeken, hogy az ultrafontos IT app egy 486-os gépen fut, ami csak 10M half-ot tud, addig nem tudjuk a 20 éve EoS demarkációs switch-et lecserélni, a lassan szintén EoS státuszba kerülő "legújabb" Nexus switch-re. Addig felesleges bárminek is a infrastruktúrában alkalmazás centrikusnak lenni, amíg az alkalmazásunkat támogató csapat az eniac-os lyukkártyás időszakon mereng, és még mindig nem fogadja el 21 századot. Mint azt egy korábbi be...

SD-WAN vagy SD-NINCS II. epizód Cisco (Viptela) 1

Cisco SD-WAN első rész Bevezető Élek az alkotói szabadság jogával, és ellentétben az eddigiekkel kicsit rövídítek a post címén. Eredetileg ez a sorozat Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS II.rész Cisco (Viptela) 1 címet kapta volna, csak hát: Kib@#&0tul hosszú lenne. Az SD-WAN témakör önmagában megér egy post sorozatot. A Cisco SD-WAN-ról sok mindent lehet írni, így ez is megér egy önálló post sorozatot. Cisco SD-WAN-nak nem kis történelmi háttere van már, hiszen a megoldást szakmai berkekben leánykori néven viptelának is hívják. A Cisco 2017 májusában fejezte be a Viptela akvizícióját, és termékeit saját megoldásként, immáron 3 éve Cisco SD-WAN megoldás részeként kínálja az ügyfelei felé. Azért hivatkozunk a szakzsargonban Viptela néven a megoldásra, mert a Cisco-nak további SD-WAN megoldásai léteznek, illetve léteztek: SD-BRANCH (ENCS platform) Meraki SD-WAN IWAN (performance routing alapú, APIC-EM vezérelt kezdeményezés, ami sajnos kihalt )...

Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS I. epizód Fortigate

SD-WAN vagy SD-NINCS I. rész Ez a bejegyzés sorozat ötlete, akkor merült fel bennem, amikor különböző gyártók SD-WAN-nak titulált megoldásait próbáltam összegezni magamban... Figyelemebe véve az alap elképzelést és a technikai megvalósíthatóságot, három kategóriát állítottam fel ezekre megoldásokra: SD-WAN megoldások - melyek biztosítják a transzport agnosztikus átvitelt, lehetőséget adnak a szolgáltatótól független topológia kialakítására központi orkesztráció és kontroll segítségével, továbbá az üzleti alkalmazások számára északi irányú API integrációra adnak lehetőséget. SD-NINCS megoldások - melyek marketing anyagokban szerepeltetik az SD-WAN-t, viszont technikai oldalról csak egy jól komponált policy based routing, ami  maximum megvalósítható. SD-LESZ megoldás - valahol a kettő között... Fortigate SD-WAN Március 13-ka óta HOME-OFFICE-ban dolgozom. Nem volt egyszerű az átállás, legalábbis mentálisan mindenképpen megterhelő a napi feladatok elvégzése úgy, hogy k...

IPAR 4.0 - Okos megoldások, hülyén megvalósítva

IPAR 4.0 Telekommunikációs és informatikai berkekben, az IPAR 4.0 eszközöket valahogy úgy definiáljuk, hogy ipari cuccok amik IP hálózaton is kommunikálnak... Természetesen ez egy durva egyszerűsítés, de ebből a szögből nézve a gyártásban betöltött szerepe nem annyira fontos, mint a hálózatban elfoglalt helye. Ezek olyan tipikusan beágyazott-rendszer alapú megoldások, melyek saját operációs rendszerrel rendelkezhetnek, és IP kommunikációra, egy már korábban lefejlesztett általában valamilyen linux alapú kernel modult használnak. Az ilyen eszközök mondhatni semmilyen tűzfal vagy végpontvédelmi megoldással nem rendelkeznek, kommunikációjuk az adatgyűjtő berendezésekkel általában nem titkosított, így potenciális veszélyforrást jelentenek a hálózatunkban. Nos eddigi tapasztalataim alapján az IoT és/vagy SMART termékek terén az, hogy minél olcsóbban, minél több szolgáltatást legyenek képesek nyújtani a végfelhasználó felé. A ipari plc-k vezérlő szoftvere - amin keresztül menedzs...