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/