A kérdések számát elnézve, amelyek az SD-WAN-nal kapcsolatban érkeztek hozzánk, a technológia már komolyan kezd gyökeret verni Oroszországban. A beszállítók természetesen nem tétlenkednek, és ajánlják a saját elképzeléseiket, míg néhány bátor úttörő már alkalmazza is ezeket a saját hálózatában.
Több mint másfél éve együttműködünk szinte minden beszállítóval, és a laboratóriumunkban rengeteg nemzetközi programozott megoldás architektúrájába beleástam. Külön kiemelést érdemel az SD-WAN a Fortinet-től, amely egyszerűen a tűzfal szoftverébe építette bele a forgalom egyensúlyozásának funkcióját a kommunikációs csatornák között. Ez az megoldás inkább demokratikus, ezért általában az olyan cégeknél figyelnek rá, amelyek még nem készülnek globális változásokra, de hatékonyabban szeretnék kihasználni a kommunikációs csatornáikat.
Ebben a cikkben szeretném bemutatni, hogyan kell konfigurálni és dolgozni a Fortinet SD-WAN-nal, kinek megfelelő ez a megoldás, és milyen buktatókkal találkozhatunk itt.
A SD-WAN piacának legkiemelkedőbb szereplői két típus közé sorolhatók:
1. Start-upok, amelyek a nulláról hozták létre az SD-WAN megoldásokat. A legjobban sikerült példa az ilyenek közül hatalmas fejlődési lehetőséghez jut, amikor nagy cégek vásárolják fel őket – ilyen például a Cisco/Viptela, VMWare/VeloCloud, Nuage/Nokia története.
2. Nagy hálózati beszállítók, akik az SD-WAN megoldásokat saját, programozható és menedzselhető hagyományos routereik továbbfejlesztésével hozták létre – ilyen történet például a Juniper, Huawei.
A Fortinetnek sikerült megtalálnia a saját útját. A tűzfal szoftverébe integrálták azokat a funkciókat, amelyek lehetővé teszik, hogy az interfészeiket virtuális csatornákba egyesítsék, és a terhelést egy olyan összetett algoritmusokkal egyensúlyozzák, amelyek a megszokott útválasztáshoz képest bonyolultabbak. Ezt a funkciót nevezték el SD-WAN-nak. Vajon Fortinet által megvalósított megoldás valóban SD-WAN-nak nevezhető? A piacon fokozatosan egyre inkább kialakul a megértés, hogy a Software-Defined azt jelenti, hogy a Control Plane elválik a Data Plane-től, különálló vezérlők és orkestrátorok léteznek. A Fortinetnek azonban ilyesmije nincs. A központosított menedzsment opcionális, és a Fortimanager hagyományos eszközével kínálják. De véleményem szerint nem érdemes absztrakt igazságot keresni, és időt pazarolni a kifejezések körüli vitákra. A való világban bármely megközelítésnek megvannak a maga előnyei és hátrányai. A legjobb megoldás az, ha megértjük ezeket, és képesek vagyunk olyan megoldásokat választani, amelyek megfelelnek a feladatoknak.
Megpróbálom a képernyőfelvételekkel a kezemben elmondani, hogyan néz ki és mit tud a Fortinet SD-WAN.
Hogyan működik minden
Tegyük fel, hogy két fiókhely közötti adatátviteli csatornák vannak. Ezek a csatornák egy csoportba összevonva úgy működnek, mint ahogyan a hagyományos Ethernet interfészek LACP-Port-Channel-be kerülnek. A régi motorosok emlékezhetnek a PPP Multilink-re – ez is egy megfelelő analógia. A csatornák lehetnek fizikai portok, VLAN SVI, vagy éppen VPN vagy GRE-alagutak.
A VPN vagy a GRE általában a fiókhálózatok helyi hálózatainak összekapcsolására használatosak az interneten. A fizikai portok pedig L2-kapcsolatok megléte esetén vagy dedikált MPLS/VPN-en való kapcsolódáskor kerülnek alkalmazásra, ha elfogadható számunkra a kapcsolat Overlay és titkosítás nélkül. Egy másik forgatókönyv, ahol a SD-WAN csoportban fizikai portokat használnak, az a helyi felhasználók interneten való forgalmának terheléselosztása.
A standunkon négy tűzfal és két VPN-alagút működik két „szolgáltató” mellett. A séma így néz ki:
A VPN-alagút interfész módban van beállítva, hogy hasonlítsanak egymásra az eszközök között olyan P2P-interfészeken, amelyek IP-címekkel rendelkeznek, és pingelhetők, így biztosítható, hogy a kapcsolat az adott alagúton keresztül működik. Ahhoz, hogy a forgalom titkosítva legyen és átmenjen a túloldalra, elegendő a forgalmat az alagútra irányítani. Az alternatíva a forgalom szűrése titkosítás céljából a tartománylisták segítségével, ami a konfiguráció bonyolódásával zavarba hozza az adminisztrátort. Nagy hálózatban az ADVPN technológia használható VPN kialakítására, ami a Cisco DMVPN vagy a Huawei DVPN megfelelője, amely leegyszerűsíti a beállítást.
Site-to-Site VPN konfiguráció két eszköz között BGP irányítással mindkét oldalon
„DC” (Data Center)
„BRN” (Fiók)
config system interface
edit "WAN1"
set vdom "Internet"
set ip 1.1.1.1 255.255.255.252
set allowaccess ping
set role wan
set interface "DC-BRD"
set vlanid 111
next
edit "WAN2"
set vdom "Internet"
set ip 3.3.3.1 255.255.255.252
set allowaccess ping
set role lan
set interface "DC-BRD"
set vlanid 112
next
edit "BRN-Ph1-1"
set vdom "Internet"
set ip 192.168.254.1 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.2 255.255.255.255
set interface "WAN1"
next
edit "BRN-Ph1-2"
set vdom "Internet"
set ip 192.168.254.3 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.4 255.255.255.255
set interface "WAN2"
next
end
config vpn ipsec phase1-interface
edit "BRN-Ph1-1"
set interface "WAN1"
set local-gw 1.1.1.1
set peertype any
set net-device disable
set proposal aes128-sha1
set dhgrp 2
set remote-gw 2.2.2.1
set psksecret ***
next
edit "BRN-Ph1-2"
set interface "WAN2"
set local-gw 3.3.3.1
set peertype any
set net-device disable
set proposal aes128-sha1
set dhgrp 2
set remote-gw 4.4.4.1
set psksecret ***
next
end
config vpn ipsec phase2-interface
edit "BRN-Ph2-1"
set phase1name "BRN-Ph1-1"
set proposal aes256-sha256
set dhgrp 2
next
edit "BRN-Ph2-2"
set phase1name "BRN-Ph1-2"
set proposal aes256-sha256
set dhgrp 2
next
end
config router static
edit 1
set gateway 1.1.1.2
set device "WAN1"
next
edit 3
set gateway 3.3.3.2
set device "WAN2"
next
end
config router bgp
set as 65002
set router-id 10.1.7.1
set ebgp-multipath enable
config neighbor
edit "192.168.254.2"
set remote-as 65003
next
edit "192.168.254.4"
set remote-as 65003
next
end
config network
edit 1
set prefix 10.1.0.0 255.255.0.0
next
end
config system interface
edit "WAN1"
set vdom "Internet"
set ip 2.2.2.1 255.255.255.252
set allowaccess ping
set role wan
set interface "BRN-BRD"
set vlanid 111
next
edit "WAN2"
set vdom "Internet"
set ip 4.4.4.1 255.255.255.252
set allowaccess ping
set role wan
set interface "BRN-BRD"
set vlanid 114
next
edit "DC-Ph1-1"
set vdom "Internet"
set ip 192.168.254.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.1 255.255.255.255
set interface "WAN1"
next
edit "DC-Ph1-2"
set vdom "Internet"
set ip 192.168.254.4 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.3 255.255.255.255
set interface "WAN2"
next
end
config vpn ipsec phase1-interface
edit "DC-Ph1-1"
set interface "WAN1"
set local-gw 2.2.2.1
set peertype any
set net-device disable
set proposal aes128-sha1
set dhgrp 2
set remote-gw 1.1.1.1
set psksecret ***
next
edit "DC-Ph1-2"
set interface "WAN2"
set local-gw 4.4.4.1
set peertype any
set net-device disable
set proposal aes128-sha1
set dhgrp 2
set remote-gw 3.3.3.1
set psksecret ***
next
end
config vpn ipsec phase2-interface
edit "DC-Ph2-1"
set phase1name "DC-Ph1-1"
set proposal aes128-sha1
set dhgrp 2
next
edit "DC2-Ph2-2"
set phase1name "DC-Ph1-2"
set proposal aes128-sha1
set dhgrp 2
next
end
config router static
edit 1
set gateway 2.2.2.2
et device "WAN1"
next
edit 3
set gateway 4.4.4.2
set device "WAN2"
next
end
config router bgp
set as 65003
set router-id 10.200.7.1
set ebgp-multipath enable
config neighbor
edit "192.168.254.1"
set remote-as 65002
next
edit "192.168.254.3"
set remote-as 65002
next
end
config network
edit 1
set prefix 10.200.0.0 255.255.0.0
next
end
A konfigurációt szöveges formátumban adom meg, mert véleményem szerint így a VPN beállítása kényelmesebb. Szinte minden beállítás mindkét oldalon azonos, szöveges formátumban pedig egyszerűen másolható. Ha ugyanezt a webes felületen csináljuk, könnyen hibázhatunk — elfelejthetünk egy jelölőt, vagy rossz értéket adhatunk meg.
Miután hozzáadtuk az interfészeket a bundléhoz
minden útvonal és biztonsági politika hivatkozhat rá, nem pedig azokra az interfészekre, amelyek belekerültek. Legalább meg kell engednünk a forgalmat a belső hálózatokból az SD-WAN-ba. Az ezekre vonatkozó szabályok létrehozásakor alkalmazhatunk védelmi intézkedéseket, mint például IPS, víruskereső és HTTPS felfedés.
A bundléhoz SD-WAN Szabályokat kell beállítani. Ezek olyan szabályok, amelyek meghatározzák a forgalom terheléselosztási algoritmusát. Hasonlítanak a Policy-Based Routing irányítópolitikáihoz, csak a forgalom politikába tartozásának eredménye nem a next-hop vagy a szokásos kimeneti interfész, hanem azok az interfészek, amelyeket az SD-WAN bundléba adunk, valamint a forgalom elosztásának algoritmusát.
A forgalmat az L3-L4 információ, a felismert alkalmazások, internetes szolgáltatások (URL és IP), valamint a felismert felhasználók munkaállomások és laptopok alapján lehet kiemelni a globális forgalomból. Ezután a kiemelt forgalomhoz az alábbi terheléselosztási algoritmusok közül lehet kijelölni egyet:
Az Interface Preferences listájában azok az interfészek választhatók ki, amelyek már fel vannak véve a bundelbe, és amelyek ezen típusú forgalmat kezelni fogják. Ha nem minden interfészt hozzáadsz, korlátozhatod, hogy pontosan milyen csatornákon halad, mondjuk, az elektronikus posta, ha nem akarod terhelni vele a drága, magas SLA-val rendelkező csatornákat. A FortiOS 6.4.1 verzióban lehetőség nyílt az SD-WAN bundle-ba felvett interfészek zónákba való csoportosítására, létrehozva például egy zónát a távoli telephelyekkel való kapcsolatra, és egy másikat a helyi internet-hozzáféréshez NAT használatával. Igen, a szokásos internetforgalom is egyensúlyozható.
A terheléselosztási algoritmusokról
Ami a Fortigate (a Fortinet tűzfala) forgalomcsatornák közötti elosztási képességét illeti, két érdekes opció van, amelyek nem túl elterjedtek a piacon:
Legalacsonyabb költség (SLA) – az összes olyan interfész közül, amely megfelel az SLA-nak, a legkisebb súlyt (cost) választja ki, amelyet a rendszergazda manuálisan állított be; ez a mód megfelelő az "ömbölyű" forgalom számára, mint például a biztonsági mentések és fájlátvételek.
Legjobb minőség (SLA) – ez az algoritmus, a szokásos késleltetés, jitter és csomagveszteség mellett, a Fortigate lehetőségét ad arra, hogy a csatornák minőségének értékeléséhez a csatorna aktuális terhelését is használja; ez a mód megfelelő az "érzékeny" forgalom számára, mint például a VoIP telefonálás és videokonferenciák.
Ezen algoritmusokhoz a kommunikációs csatorna teljesítménymérő beállítása szükséges – Performance SLA. Ez a mérő időszakonként (check interval) figyeli az SLA betartásának adatait: csomagveszteség (packet loss), késleltetés (latency) és jitter (jitter) az adatátviteli csatornában, és „elutasíthatja” azokat a csatornákat, amelyek jelenleg nem felelnek meg a minőségi küszöbértékeknek – túl sok csomagot vesznek el, vagy túl nagy késleltetést mutatnak. Ezenfelül a mérő figyeli a csatorna állapotát, és ideiglenesen eltávolíthatja azt a bundelből, ha többször is választ nem kapott (failures before inactive). A helyreállítás során, miután több egymás utáni válasz érkezett (restore link after), a mérő automatikusan visszaállítja a csatornát a bundelbe, és az adatok újra át fognak rajta áramlani.
Így néz ki a „mérő” beállítása:
A webes felületen teszteléshez elérhető protokollként az ICMP-Echo-request, HTTP-GET és DNS-kérés áll rendelkezésre. A parancssorban kicsit több lehetőség van: elérhető a TCP-echo és UDP-echo opció, valamint egy speciális minőségi mérési protokoll — TWAMP.
A mért eredményeket a webes felületen is láthatja:
És a parancssorban:
Hibaelhárítás
Ha létrehozott egy szabályt, de nem úgy működik, ahogy várta, érdemes megnézni a Hit Count értékét az SD-WAN Szabályok listájában. Ez megmutatja, hogy a forgalom egyáltalán illeszkedik-e a megadott szabályhoz:
A mérő beállításainak oldalán láthatja a csatorna paramétereinek időbeli változását. A pontozott vonal jelzi a paraméter küszöbértékét.
A webes felületen nyomon követheti, hogyan oszlik meg a forgalom a küldött/kapott adatmennyiség és a munkamenetek száma alapján:
Ezen kívül lehetősége van az adatok csomagjainak maximális részletességgel történő nyomon követésére. Valós hálózat működtetésekor számos routing, tűzfal és SD-WAN portok közötti terhelés-elosztási szabály halmozódik fel az eszköz konfigurációjában. Mindezek összetett módon kölcsönhatásba lépnek egymással, és bár a gyártó részletes ábrákat nyújt a csomagok feldolgozásának algoritmusáról, nagyon fontos, hogy lehetőség legyen a lehetőségek felvázolása helyett megnézni, hová vándorol valójában a forgalom.
Például a következő parancssor
diagnózis hibakeresési folyamat szűrő saddr 10.200.64.15
diagnózis hibakeresési folyamat szűrő daddr 10.1.7.2
diagnózis hibakeresési folyamat mutassa a függvény nevét
diagnózis hibakeresés engedélyezése
diagnózis hibakeresési nyomvonal 2
Két csomag nyomon követésére lehetőséget ad a forrás IP-cím 10.200.64.15 és a cél IP-cím 10.1.7.2.
Pingeljük meg a 10.7.1.2-t a 10.200.64.15-ről kétszer, és nézzük meg a konzol kimenetét.
Első csomag:
Második csomag:
Íme, az első csomagot a tűzfal kapta:
id=20085 trace_id=475 func=print_pkt_detail line=5605 msg="vd-Internet:0 egy csomagot kapott(proto=1, 10.200.64.15:42->10.1.7.2:2048) a DMZ-Office-tól. típus=8, kód=0, id=42, seq=0."
VDOM – Internet, Proto=1 (ICMP), DMZ-Office – az L3 interfész neve. Típus=8 – Echo.
Ehhez új munkamenet jött létre:
msg="allocate a new session-0006a627"
És az útvonalakra vonatkozó szabályok beállításaiban egyezést találtunk.
msg="Match policy routing id=2136539137: to 10.1.7.2 via ifindex-110"
Kiderül, hogy a csomagot az egyik VPN-alagútba kell küldeni:
"find a route: flag=04000000 gw-192.168.254.1 via DC-Ph1-1"
A tűzfal szabályai között engedélyező szabályt találunk:
msg="Allowed by Policy-3:"
A csomag titkosítva kerül a VPN-alagútba:
func=ipsecdev_hard_start_xmit line=789 msg="belép IPsec interfész-DC-Ph1-1"
func=_ipsecdev_hard_start_xmit line=666 msg="IPsec alagút-DC-Ph1-1"
func=esp_output4 line=905 msg="IPsec titkosítás/autentikáció"
A titkosított csomag a WAN-interfészhez tartozó átjáró címére kerül továbbításra:
msg="send to 2.2.2.2 via intf-WAN1"
A második csomag esetében minden hasonlóan történik, de egy másik VPN-alagútba kerül, és egy másik tűzfal porton távozik:
func=ipsecdev_hard_start_xmit line=789 msg="belép IPsec interfész-DC-Ph1-2"
func=_ipsecdev_hard_start_xmit line=666 msg="IPsec alagút-DC-Ph1-2"
func=esp_output4 line=905 msg="IPsec titkosítás/autentikáció"
func=ipsec_output_finish line=622 msg="küldés a 4.4.4.2 címre az intf-WAN2-n keresztül"
A megoldás előnyei
Megbízható funkcionalitás és felhasználóbarát felület. A funkciókészlet, amely a FortiOS-ban volt a SD-WAN megjelenése előtt, teljes egészében megmaradt. Tehát nem egy újonnan kifejlesztett szoftverről van szó, hanem egy érett rendszerről, amelyet egy megbízható tűzfal szállító biztosít. Hagyományos hálózati funkciókkal és egy könnyen kezelhető, felhasználóbarát webes felülettel. Sok SD-WAN szállítónak van olyan végberendezése, amely például Remote-Access VPN funkcióval rendelkezik?
80-as szintű biztonság. A FortiGate a tűzfal-megoldások között az élvonalba tartozik. Az interneten rengeteg anyag található a tűzfalak beállításáról és adminisztrációjáról, és a munkaerőpiacon számos biztonsági szakember is van, akik már elsajátították a szállító megoldásait.
Nulla ár a SD-WAN funkcióért. A SD-WAN hálózat FortiGate-en való kiépítése annyiba kerül, mint egy hagyományos WAN hálózat kiépítése, mert nem szükségesek további licencdíjak a SD-WAN funkciók megvalósításához.
Alacsony belépési küszöb árban. A Fortigate-nek jó eszközfajta-kategóriája van a különböző teljesítményekhez. A legkisebb és legolcsóbb modellek is jól szolgálják például egy 3-5 fős iroda vagy értékesítési pont kialakítását. Sok szállítónak nincsenek olyan alacsony teljesítményű és megfizethető modelljei.
Magas teljesítmény. A SD-WAN funkció forgalomelosztásra történő redukálása lehetővé tette a cég számára, hogy egy specializált SD-WAN ASIC-ot bocsásson ki, amely garantálja, hogy a SD-WAN működése nem csökkenti a tűzfal általános teljesítményét.
Lehetőség, hogy az iroda teljes egészében Fortinet berendezéseken valósuljon meg. Ez néhány tűzfal, kapcsolók, Wi-Fi hozzáférési pontok. Ilyen irodát könnyű és kényelmes kezelni – a kapcsolók és az hozzáférési pontok a tűzfalakon regisztrálódnak és azokról kezelhetőek. Így például így nézhet ki a kapcsoló port a tűzfal interfészén, amely a kapcsolót vezérli:
Nincs vezérlő, mint egyetlen hibahely. Ezen a szirelmet mutatja be maguk a szállítók, de ezt csak részben lehet előnyként említeni, mert azoknál a szállítóknál, ahol vannak vezérlők, azok hibatűrő biztosítása nem drága, általában csak kis számú számítási erőforrást igényel a virtualizációs környezetben.
Mire érdemes figyelni
Nincs megosztás a Control Plane és a Data Plane közöttEz azt jelenti, hogy a hálózatot manuálisan kell beállítani, vagy a már meglévő hagyományos kezelőeszközök, mint például a FortiManager, használatával. Azoknál a gyártóknál, ahol ez a felosztás megvalósult, a hálózat önállóan felépül. Az adminisztrátornak lehet, hogy csak a topológiát kell finomhangolnia, és esetleg valamit letiltania, de ez mindössze ennyi. Azonban a FortiManager előnye, hogy nemcsak tűzfalakat tud kezelni, hanem switcheket és Wi-Fi hozzáférési pontokat is, tehát gyakorlatilag a teljes hálózatot.
Feltételesen fokozott kezelhetőség. Mivel a hálózat beállításának automatizálására hagyományos eszközöket használnak, a SD-WAN bevezetésekor a hálózat kezelhetősége csak kis mértékben nő. Másrészt azonban az új funkciók gyorsabban elérhetővé válnak, mivel a gyártó először csak a tűzfal operációs rendszeréhez adja ki őket (ami azonnali használatot biztosít), majd később egészíti ki a szükséges kezelőfelületeket.
Egyes funkciók parancssorból elérhetők, de webböngésző felületen nem. Nem olyan ijesztő néha belépni a parancssorba, hogy valamit beállítsunk, mint az, hogy ne lássuk a webböngésző felületen, hogy valamit már valaki beállított a parancssorból. De ez általában a legújabb funkciókra vonatkozik, és fokozatosan, a FortiOS frissítéseivel a webböngésző funkciói fejlődnek.
Kinek ajánlott
Azoknak, akiknek nem sok fiókjuk van. Egy SD-WAN megoldás bevezetése bonyolult központi komponensekkel 8-10 fiók esetén valószínűleg nem éri meg – pénzt kell költeni a SD-WAN eszközökhöz szükséges licencekre és a központi komponensek virtualizálásához szükséges erőforrásokra. Egy kisvállalat esetén a szabad számítási erőforrások általában szűkösnek számítanak. A Fortinet esetén elég csak tűzfalakat vásárolni.
Azoknak, akiknek nagyon sok kis fiókjuk van. Sok gyártónál a megoldás minimális ára fiókonként viszonylag magas, ami az üzleti végfelhasználó szempontjából nem korszerű. A Fortinet vonzó áron kínál kis eszközöket.
Azoknak, akik még nem készek túllépni a határokon. Az SD-WAN bevezetése, vezérlőkkel, saját fejlesztésű útválasztással, valamint új hálózati tervezési és kezelési megközelítéssel egyes megrendelők számára túl komoly lépés lehet. Igen, ez a bevezetés végső soron segíthet optimalizálni a kommunikációs csatornák használatát és az adminisztrátorok munkáját, de először sok újat kell megtanulni. Azoknak, akik még nem állnak készen a paradigmaváltásra, de szeretnének többet kihozni a kommunikációs csatornáikból, éppen megfelelő a Fortinet megoldása.
Forrás: habr.com
