Ugrás a fő tartalomra

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:
  1. 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.
  2. 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ó.
  3. 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özben a gyerekek is itt szaladgálnak köztünk, és együtt kell élnünk, hogy szinte 0-24-ben be vagyunk zárva a lakásban.


Közben technikai oldalról sem egyszerű a helyzet, hiszen gondoskodni kell itthon is arról, hogy megfelelő Internet kapcsolatom legyen a folyamatos munkavégzés és gyerekek lekötése érdekében.

Abban a szerencsés helyzetben vagyok, hogy itthon meg tudtam oldani a redundáns csatlakozást az Internet-re, jelenleg az alábbi csatlakozási lehetőségek állnak rendelkezésre:
  1. KOAX alapú ED kapcsolat
  2. Mobil alapú LTE kapcsolat

Persze a "dual-home" csatlakozás nem minden, kell egy olyan eszköz is amellyel megvalósítható az egyidejű kétirányú csatlakozás, és nem árt, ha a kimenő forgalmak köz nem is végez terheléselosztást, legalább gyorsan tud váltani a két kapcsolat között. Csak erre a célra tökéletes megfelel bármilyen 10-20e forintos kategóriába eső eszköz, amiket ezen linken is elérhettek.

Most inkább üzleti célú, high-end eszközökkel foglalkoznék, nem csak azért mert ezek integrációjával foglalkozom a munkám során, hanem azért is, mert ezek a high-end eszközök, amik több szempontból is magasabb rendelkezésre állást biztosíthatnak:
  1. Hardver architektúra
  2. Szoftver követés
  3. Gyártói támogatás 
  4. Nem mellesleg olyan megoldások állnak rendelkezésre, mint például az SD-WAN.

SD-WAN alatt minden gyártó mást és mást ért, egyben viszont mindenki egyetért, ez pedig, hogy foglalkozni kell a témakörben a WAN kapcsolatok összefogásával és a terheléselosztás lehetőségével.
Ebben nekem van már személyes tapasztalatom, ugyanis 99999 Informatika jóvoltából lehetőségem nyílt rá, hogy itthon teszteljem a Fortigate SD-WAN képességeit.
Fortinet SD-WAN alatt sajnos csak a redundáns WAN kapcsolatok közti terheléselosztást érti, és kifejezetten SD-WAN orkesztráció nem áll rendlékezesre, pontosabban csak FortiManager bevonásával, ami azért a semminél mégis több.
Az SD-WAN feature Forti-OS 5.6 óta érhető el, az én "laboromban" jelenleg 6.0.9-es verzión fut egy FGT-60D amely mobil és vezetékes irányban biztosít stabil Internet kapcsolatot.

SD-WAN beállítása nem egy rocket science ennél a típusnál, de fontos, hogy beüzemelés első lépése legyen, ugyanis később szívhatunk a policy kialakításoknál
(mint ahogy én is tettem, amikor utólag csináltam meg az SD-WAN-t)

STEP 1 WAN kapcsolatok

A FGT-60D-nél rendelkezésre áll két dedikált WAN port, amiből ebben az install-ban 1-et használtam fel az KOAX alapú internet csatlakozás terminálására (értsd KábelNet).
Sajnos a szolgáltató eszköze - az IPTV szolgáltatás miatt - csak NAT módban tudja biztosítani az Internet szolgáltatást és nincs lehetőség bridge módra, így egy privát IP-t kapok a wan1 porton.
A szolgáltató DHCP-n biztosítja a privát IP-t, amit az IPTV miatt megint nem célszerű átállítani statikusra, szóval a szolgáltatói eszközben foglaltam fixen 1 db címet. (DHCP reservation)


A második WAN linknek a Fortigate 60D USB portján alakítottam ki.
FortiOS 5.4-től van lehetőség arra, hogy ne csak 4G-s mobil stick-et használjunk külső modemként, hanem egy MIFI routert használjunk erre a célra.
A MIFI routeren hasonlóan a KOAX modemnél csak privát IP beállítására van lehetőség, úgyhogy DHCP reservation 1 db fix cím, mellesleg ezen a porton a FGT-n sem lehet beállítani statikus IP-t csak DHCP kliensként tud működni.
A lakossági mobilnet ennél a szolgáltatónál Carrier Grade NAT mögött van, szóval ebben a kapcsolatban 3-as NAT-olás történik, a felhasználótól az Internetig. (Nem jó, de nem is tragikus)
 



STEP 2 SD-WAN interface

A következő lépés az, hogy ezeket a WAN kapcsolatokat összefogjuk 1 logikai entitássá, amit a FortiOS SD-WAN interface-nek hív.
  

Beállítjuk a default route-ot az SD-WAN interface-re és felvesszük a kimenő és bejövő policy-ket úgy, hogy SD-WAN interface-t használjuk...


A policy-król nem rakok fel képet - az már elég szenzitív információt tartalmaz - mindenkinek a saját képzeletére bízom a beállításokat.

Ez mind nagyon egyszerűnek tűnik eddig a pontig és valóban nem kell elbonyolítania konfigurációt, főleg otthoni felhasználásban és BRANCH-eknél sem feltétlenül, ha két egyforma SLA-val rendelkező és két egyforma átviteli kapacitást biztosító Internet vonalunk lenne.
DE
Alap esetben (round robin alapon) Source-Destination IP hash alapján csinálja a terheléselosztást az SD-WAN alkalmazás, ami nekem annyira nem jött be ebben a felállásban. Szerencsére van lehetőség arra, hogy performace SLA (PSLA) alapján, finom hangoljuk a terheléselosztást.

STEP3 Performace SLA

Ezt a pontot FortiOS 6.2-vel majd megnézzük újra, mert változott, de a lényeg nagyjából ugyanaz.
Lehetőségünk van mérni a különböző szolgáltatói irányokban az Interneten elérhető erőforrások minőségi paramétereit.
Milyen minőségi paramétereket?

  • Packet Loss - Csomagvesztési arány
  • Latency -  Késleltetés
  • Jitter - Késleltetés változása

Önmagában a Performance SLA-val lehetőségünk van a különböző irányok elosztására SD-WAN nélkül, ami azt jelenti, hogy a Performace SLA képes a routing táblát a minőségi paraméterek változása esetén frissíteni, de felhasználható SD-WAN szabály alapjaként is.
(vagy az első, vagy a második legyen, mert ha mindkettőt alkalmazzuk, abból furcsa anomáliák keletkezhetnek)


Hogy milyen erőforrások elérhetőségét szeretném vizsgálni, az attól függ, hogy üzleti szempontból mi a fontos, például számomra az 99999 Informatikában fellelhető publikus erőforrások elérése kritikus, de a feleségem is home-office-ban van, szóval az ő munkájához szükséges publikus hálózaton keresztül elérhető erőforrás mérése is ide tartozik.
Üzleti szempontokat nekünk ezek határozzák mert innen jönnek a fizetések...


Amikor létrehozzuk a Performance SLA mérést, akkor lehetőségünk van több távoli szervert beállítani, a mérési eredmények meghatározásánál.
Úgy tapasztaltam, hogy ez torzíthatja a mérési eredményt és indokolatlanul ronthatja a minőségi mutatókat, tehát a kritikus alkalmazások esetében, csak 1 szervert állítottam be mérési alapként. Fontos, hogy ahány szervert beállítunk minimum annyi SLA célt kell meghatároznunk, több lehet, kevesebb nem és mivel SD-WAN rule összeállításánál használom fel a PSLA-t, ezért nem engedélyezem a static route update-et. Szóval ezeknek a mért SLA paramétereire bízom majd a döntést az SD-WAN rule-ok összeállításánál során.

STEP4 SD-WAN rulez ;-)


SD-WAN rule-ok, szabályok határozzák meg azt, hogy a belső felhasználói vagy szerver zónáim, melyik WAN interface-en érhetik el a publikus erőforrásokat.




A szabályok sorrendjének is fontos szerepe van, főleg abban az esetben, ha a szabály konkrét forrás és cél hálózati címeket is tartalmaz, ezeket célszerű a sor elejére rakni.
Maga szabály összeállítása, igazából egy static route beállításhoz hasonlítható:
  • Meg kell határozni a forrásokat, legalább IP cím/tartomány vagy FQDN szinten, de szűkíthetek felhasználói csoportokra is.
  • Meg kell határozni a cél címet, vagy címeket, és lehetőség van konkrét alkalmazásra szűrni.
  • Meg kell határozni a kimenő interface-ket, amelyek felé mehet a forgalom (minimum 1)
  • Ki kell választanunk a PSLA-t ami alapján az SD-WAN route alakul, és meg kell határozni, hogy milyen minőségi paraméter alapján hozzunk döntést.
Ha semmilyen szabályt nem állítunk be, akkor is van egy implicit sor, ami alapján a terheléselosztás történik. A fentebbi képen pirossal bekeretezve.
Ennek a szabálynak a hangolása az, amely az összes forgalomra ami SD-WAN interface felé policy-ben engedélyezve van, hatással lesz.

Alap beállítás, hogy source és destination IP hash alapján csinálja az elosztást, de van másik 4 szempont ami alapján oszthatjuk az erőforrásokat. Például session számra súlyozhatunk:
Vagy átviteli sebességre elosztásra:
Éppenséggel adatmennyiséget is figyelembe vehetünk:

Terhelés elosztás algoritmusát, lehet csak kizárólag  a Source IP hash alapján alakítani, ennek nem sok értelmét látom egy round-robin jellegű terhelés elosztásnál.

Monitorozás

Az eredmény az SD-WAN szabályok mentén történő terheléselosztás, amiről SD-WAN monitoringban is meggyőződhetünk, ami két interface esetén,elég kevésnek tűnhet, de nem csak két WAN interface-t vonhatunk be SD-WAN megoldásba, hanem többet is, a maximum-ot az adott eszköz hardver kapacitása limitálja.


A működés/üzemeltetés ebben az installban egy kicsit problémás, ugyanis, ha valamilyen okból megszakad a MIFI routerrel a kapcsolat, akkor eddig csak újraindítással sikerült az SD-WAN interface részévé tenni újra. Sem CLI sem GUI beállítások nem hozták vissza a mobil irányú WAN kapcsolatot. Ezt majd 6.2+-ban újra meg fogom vizsgálni...

Summázva

Fortigate esetében az SD-WAN vagy SD-NINCS-re az a válaszom, hogy igen. Sok olyan megoldás elérhető benne, amely az SD-WAN általános architektúra elképzelésében is szerepel, viszont hiányzik belőle néhány elem amely teljes SD-WAN megoldássá teheti.
Ezeket a hiányosságokat is tudjuk pótolni, például ADVPN-nel és FortiManager-el, szóval ha befoltozzuk a hiányt kézzel, akkor SD-WAN, de önmagában a Fortigate egy nagyon jól megkomponált policy based router, ami SDN API segítségével automatizálható (6.2+), de még inkább SD-LESZ majd.

A következő bejegyzésig a legkevesebb amit tehetsz a jelenlegi pandémiás helyzetben:
stay@HOME
folding@HOME
https://newman.cloud/en/2020/03/28/foldinghome-in-your-datacenter/

Érdekesebb bejegyzések

FortiGate - SEC előfizetésen túl

Végre megvan az új NGFW a cégben, megvettétek 3 vagy 5 éves enterprise vagy utp bundle-ben és biztonságban érzitek magatok (Szárazabb, magabiztosabb érzés nem?), hiszen van IPS , webfilter, antivirus stb... security profile, ami megvédhet az ismert támadásokkal szemben. Nyugodtan "hátradőltök" és készítitek az auditokhoz szükséges riportokat a FortiAnalyzerből... biztonságban eltelik az 5 év és "váratlanul ér" előfizetés megújítása, nincs budget, pánikolva néztek valamilyen alternatív alsópolcos megoldást, amit még be tudtok szerezni és kidobnátok a jó hardvert, ami éveken keresztül stabilan szolgált titeket... Ne tegyétek! Mutatom milyen feature-ket használhattok tovább ingyen: Persze az alábbi megoldások nem minden végfelhasználónak jelentenek megoldást a problémákra és kihívásokra, de KKV szektorbnan vagy olyan esetekben, ahol nem szükséges IPS, anitvirus, webfilter, még jól használhatók tovább ezek a hardverek/szoftverek előfizetések nélkül. Fontos, ha egyébként...

CCIE #69065 - SRv6, most már tényleg átállunk IPv6-ra?

Röviden: NEM Hosszabban: Nem egészen, a teljes IPv6 átálláshoz nem elegendő csak a hálózat eszközök (több mint 10 éve meglévő) képességeit kihasználni, hanem ehhez a teljes informatikai iparágnak kellene paradigmaváltáson átmenni, ami azt jelenti, hogy a felhasználói (business és consumer) alkalmazásoknak minden kétséget kizáróan nagy rendelkezésre állással kellene támogatni a TCP/IPv6 stack-et (sok helyen tapasztaltam, hogy még a TCPv4-et sem sikerült minden kétséget kizáróan jól implementálni, de még operációs rendszerek szintjén sem). Viszont a szolgáltatók a publikus IPv4 kifogyást megelőzendő a szolgáltatói környezetet már migrálhatják IPv6-os hálózatra, ami megfordíthatja a korábbi, IPv6 over IPv4 (MPLS vPE6) vagy dual-stack (Internet) architektúrát  akár natív  IPv4 over IPv6 (SRv6) jellegű felállásra. A teljes képhez sok mindent tisztába kellene tenni, de élek az alkotói szabadsággal és úgy vagyok vele, hogy nem célom most itt mindenkit telekommunikációs mérnökké avanz...

CCIE SP v5.x Lerning journey #xxxxx3 Deep Dive of IGPs: OSPF part 1

 Everything what you do not want know about the OSPF! In a Service Provider network, one of the most important part is the IGP (Interior Gateway Protocol). Why? Because the network core convergence and routing strategy is depend on the IGP routing rules. If the IGP can not support some features what  are needed for the traffic engineering, it could be a  future operation or development problem. So SPs select IGPs which are satisfy every operational and business needs, and it will be a future proof protocol. Many of service providers typically choose OSPF or ISIS for IGP, because: - they are RFC and ITU-T conform, vendor independent protocols (in general) - they support MPLS traffic engineering features (OSPF opaque LSA 10 11) - link-state routing protocols, which means  that these can provide faster convergence than vector-path or distance vector protocols, and they are more scalable. What is OSPF?  OSPF (Open Shortest Path First) protocol is a dynamic link-stat...

Fortinet minősítési rendszer változások - avagy a FortiThanos lecsap

 A Fortinet bizonyos időszakonként megváltoztatja a vizsga rendszerét és minősítési rendszerét...  Amikor 2018-ban elkezdtem foglalkozni a Fortinet Network Security megoldásaival, akkor még "lázasan" NSE4 vizsgára készültem, ami FortiGate alapok mellett néhány advanced témát is érintett.  Ekkor már átesett a Fortinet egy vizsgarendszer átalakításon, és korábban FCNSP (Fortinet Certified Network Security Professional) minősítések lettek NSE4 minősítéssé. Még ebben az időszakban terveztem tovább lépni NSE7 szintre, ami akkor egy vizsgával megléphető volt aztán bummm! Jött a vizsgarendszer átalakítása és a korábban NSE1 - 8 minősítések új rendszerbe kerültek.. Az NSE1 - 3 -ből lett a az FCF ás FCA azaz Foundamental és Associate minősítések (ezek online elvégezhető tanfolyamok és nem proctored vizsgák) NSE4 + NSE5 vagy NSE6-ből lettek az az FCP minősítések (Professional) NSE7 vizsgákból illetve azok kombinációiból lettek az FCSS minősítések (Specialist)  NSE8 pedig FCX a...