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ö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.
- KOAX alapú ED kapcsolat
- 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.
- Hardver architektúra
- Szoftver követés
- Gyártói támogatás
- 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.
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:
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
