A Mizu MikroTik sorozat a RouterOS legfontosabb változásairól szól. A sorozatban elsődlegesen az új funkciókra koncentrálunk, a javításokat csak nagyon indokolt, sokakat érintő esetben említek meg. Ebben a részben a v7.20 kerül terítékre:

Hallgasd meg útközben és később próbáld ki, vagy lapozz lejjebb és olvasd el a cikket!

Visszatértek a BGP instance-ek

A BGP-nél eddig is volt lehetőségünk arra, hogy kettő, vagy több instance-ünk legyen. 6-os verziónál konkrétan külön instance-eket lehetett létrehozni, v7-nél pedig eddig több Connection bejegyzéssel (és bennük különböző Router ID-val) lehetett több instance-ünk. Most visszakerül az explicit instance létrehozási lehetőség, azaz megjelent újra a BGP ablakon az Instances fül.

Arra figyelj, hogy ez olyan változás, ami nem downgrade-biztos: downgrade esetén az instance beállítások elszállhatnak és így a teljes BGP is, tehát ha BGP-zel és kipróbálnád a 7.20-at, akkor előtte készíts mentést, hogy ha esetleg vissza kell állnod korábbi verzióra, akkor legyen mihez nyúlnod!

EVPN támogatás

Mielőtt ebbe és a következő részbe belevágnánk, beszélnünk kell az SDN-ről (Software-defined Networking): ennek lényege, hogy szétválasztja a hálózat vezérlési síkját (control plane) és az adat síkját (data plane). A vezérlést egy központi controller végzi, amely logikailag irányítja az egész hálózatot, míg a switch-ek és routerek csak végrehajtják az utasításokat. A vezérlő gyakorlatilag meghatározza, hogy az egyes Ethernet keretekkel vagy IP csomagokkal mit tegyenek a vezérelt eszközök: hogyan, milyen szabály szerint és merre továbbítsák azokat. Mindez lehetővé teszi a dinamikus, programozható, automatizált hálózatmenedzsmentet, ami gyorsabb reagálást, jobb erőforrás-kezelést és skálázhatóságot biztosít.

Az SDN ideális dinamikus, modern környezetekhez – például adatközpontokhoz, felhőhálózatokhoz, multi-tenant rendszerekhez.

BGP esetén eddig is tudtunk L2/L3 VPN-eket létrehozni, de most lett olyan megoldás, ami újabb és ha kiforrja magát, akkor jobb lesz: ez az EVPN (Ethernet VPN).

• Itt a BGP adja a vezérlési síkot tehát ez osztja szét a résztvevő eszközök között a működéshez szükséges információkat
• Az MPLS, a VXLAN, vagy az SRv6 protokoll adhatja az adat síkot, tehát ezek közül valamelyikben valósul meg a lényegi adattovábbítás. Ezek közül a RouterOS jelenleg a VXLAN átvitelt támogatja.

Miért lehet jobb az EVPN, mint a sima BGP alapú VPN-ek?

• PL a multi-homing támogatás miatt, amikor egy végpont több VPN edge eszközhöz is csatlakozik és ezeken pl. terheléselosztás történhet.
• Vagy a MAC/IP mobilitás miatt: amikor egy VM egy másik szolgáltatói eszközre mozog, de megtarthatja akár ugyanazt az MAC és IP címet MAC flapping és ARP cache problémák nélkül.
• és azért is, mert Az EVPN nem adatforgalomból tanulja a MAC címeket, mint a klasszikus Layer 2 megoldások (pl. VPLS), hanem a BGP hirdeti őket, vezérlési síkon. Ez jelentősen csökkenti a broadcast/flood forgalmat, gyorsabb konvergenciát és jobb hálózati átláthatóságot eredményez, különösen nagy adatközponti környezetekben, ahol több ezer VM vagy konténer van jelen.

OpenFlow támogatás

Bár az EVPN nem tekinthető klasszikus értelemben SDN-megoldásnak, követi az SDN alapelveit (pl. vezérlési és adat sík szétválasztása), és SDN-kész – tehát jól integrálható vezérlőkkel.

Ezzel szemben az OpenFlow már ténylegesen egyfajta SDN megoldásnak tekinthető. Itt egy kontroller szoftver fér hozzá az eszközeinkhez (switch/router) és tölti, módosítja ezek forwarding tábláit. Olyan megoldásokban használják, ahol a hálózati eszközök adatforgalmi döntéseit központilag, dinamikusan akarják vezérelni. A cél nem egyszerűen az, hogy máshonnan konfiguráljuk a hálózatot, hanem hogy valós időben, automatizáltan tudjuk befolyásolni, hogy az egyes keretek/csomagok hogyan haladjanak a hálózatban. MikroTik alapon még nagyon az elején járunk, utoljára v6-ra volt OpenFlow, de megint csak: ha kiforrja magát, akkor nagyon hasznos lesz nagyobb hálózatoknál. A használatához az openflow csomagot kell telepíteni.

Routing filter varázsló

A 7-es RouterOS Routing filter-eit sokan szidták. Való igaz: a 6-os verzióhoz képest kényelmi szempontból visszalépés, hogy még winbox esetén is kézzel kell begépelni a szabályokat. Gondolom a régi rendszerre visszatérni már nem lehetséges, vagy lehet, hogy egyszerűen csak több problémát szülne egy újabb váltás, ezért egy varázslóval hidalták át a dolgot: a 6-os filterekre valamennyire hasonlító felületen tudunk új szabályokat létrehozni, amikből aztán 7-es szintaktika szerinti filter szabályok készülnek.

Ha még nem hallottál a routing filter-ekről: dinamikus routing protokollok esetén (pl. BGP, OSPF, ISIS) ezekkel lehet azt megszabni, hogy a te routered milyen route szabályokat fogadjon el más routerektől – és milyen paraméterekkel; illetve, hogy a te routered milyen route szabályokat hirdessen a többi eszköz felé. Ezen kívül ez az egyetlen mód, hogy connected, vagy egyéb dinamikus route-ok egyes jellemzőit megváltoztasd, vagy pl. kommentet fűzz hozzá.

Zoknit a forgalmakra!

Kaptunk egy új NAT action-t, amivel bizonyos forgalmakat SOCKS5 szerver felé továbbíthatunk. Az action egyelőre csak CLI-n használható, meg kell adni a feltételt, a socksify action-t és SOCKS szerver IP címét és portját.

A SOCKS egyébként egy proxy protokoll, ami lehetővé teszi, hogy egy kliens egy proxy szerveren keresztül kommunikáljon TCP, vagy UDP alapon egy másik géppel. Nem teljesen új a RouterOS-ben sem, mert SOCKS proxyt (mondjuk úgy: „szervert”) eddig is lehetett létrehozni a rendszerben. A socksify action-nel pedig kiválthatod a SOCKS klienst az eszközödön, hiszen a NAT szabály feltétele úgy is szólhat, hogy mondjuk a te összes forgalmad legyen átirányítva.

Liberal TCP tracking

Mielőtt erről beszélnénk, először connection tracking és connection state-ek. A RouterOS tűzfala úgynevezett statefull tűzfal: nyomon követi az aktív TCP kapcsolatokat, sőt kapcsolattá rendezi olyan „összegfüggő” csomagok halmazát is, amiknél igazából a Layer 4-es protokoll nem jár kapcsolat felvétellel, pl ICMP, UDP.

Egy példa: ha megpingetsz egy a állomásról egy b állomást, és arra 10mp-en belül jön válasz, akkor a két csomagot a tűzfal egy kapcsolathoz tartozóként fogja kezeli. Ha aztán újra megpingeted ugyanarról az a állomásról ugyanazt a b-t, mint előbb, akkor ez a tűzfal szerint még mindig ugyanaz a kapcsolat lesz.

A Connection tracking-nek működnie kell, ha pl. NAT-ot használsz, és még néhány más esetben is – általában nem kell vele foglalkozni, automatikusan bekapcsol, ha írsz mondjuk egy NAT szabályt.

A connection tracking még egy dolgot csinál: minden csomaghoz hozzá rendel egy úgynevezett connection state-et. Ezekből 4 van, az egyik igazából kakukktojás, mert az azt jelenti, hogy „egyik sem a maradék 3 közül” – ez az invalid connection state. Az ilyen csomagokra általános ajánlás, hogy dobja el ezeket a tűzfal.

Na de hogy lesz egy csomag invalid: tipikus (de nem kizárólagos) példa erre az, hogy amikor a tűzfal azt látja mondjuk egy átmenő TCP forgalom esetén, hogy a három fázisú kézfogás egyik lépése hiányzott. Mondjuk jön egy SYN-ACK (2. üzenet), úgy, hogy a SYN (1. üzenet) nem volt.

A RouterOS tűzfala eddig Loose TCP Tracking-et alkalmazott alapértelmezetten, ami a fentitől kicsit eltér: ha látta a tűzfal a TCP handshake 2. és 3. üzenetét, de az elsőt nem, akkor nem teszi invalid-ra a kapcsolatot (igazából a csomagokat, de mindegy, egyszerűsítsünk)

Most megérkezett egy még engedékenyebb mód: a Liberal TCP Tracking, ami már csak akkor tesz egy kapcsolatot invalid-dá, ha abban olyan RESET üzenet érkezik, aminek problémás a sorszáma (out of window RST segment)

Mire lehet ez jó? Tegyük fel, hogy van egy nem RFC szerint működő, TCP kapcsolatokat létrehozó eszközöd. Mondjuk régi eszköz, régóta nem frissülő firmware-rel. Vagy mondjuk egy TCP kapcsolat aszimmetrikusan halad: egyik irány NAT-olva van, a másik nem. Ezek a Loose Tracking szerint akár invalid csomagokat is eredményezhetnek és mivel az általános ajánlás az invalid csomagok dobása, ezért ezekben az esetekben a kapcsolatok nem működnének. A Liberal Tracking viszont nem teszi eszeket feltétlenül invalid-dá és így működhetnek a kapcsolatok.

Akkor hát állítsa át mindenki szorgalmasan a Connection Tracking-et Liberal módra? NE! Ennek biztonsági kockázatai vannak, egy támadó könnyebben kijátszhatja a connection tracking-et spoof-olt csomagokkal, elhiteti a tűzfallal, hogy egy valid kapcsolat épült. Illetve kitettebb lesz a rendszer hijack, vagy injection támadásoknak is. Csak akkor kapcsold be a Liberal TCP trackinget, ha például azt tapasztalod, hogy egy bizonyos eszköz nem tud TCP kapcsolatokat felépíteni a Loose tracking esetén.

Container bővítések

Ha Docker container-eket futtatsz MikroTik-en, akkor a következő fejlesztések hasznosak lehetnek számodra:

• külön log a container-eknek, 100 sor/container
• container in container setup létrehozásának a lehetősége
• több veth rendelése egy container-hez
• parancs lefuttatása a container-ben a RouterOS konzoljából “/container/shell cmd= user=” – bár nem néztem meg, de gondolom nincs akadálya, hogy egy ilyen parancsot script-be tegyél, amit utána akár SMS-sel is elindíthatsz.
• conteiner-enkénti memória limit létrehozása és monitorozása
• repull parancs
• read-only monuntolása mappáknak, illetve fájloknak. Ja, igen: mostantól fájl is mount-olható, nem csak mappa.
• hardver elemekhez történő direkt hozzáférés támogatása
• több környezeti változó lista (envlist) hozzárendelhető egy container-hez
• bővített, beszédesebb üzenetek: például, ha egy tar fájl kicsomagolása nem sikerül – így az oka is jobban felderíthető
• shutdown esetén a container-ek is szabályosan leállnak

Hasznos továbbiak

• smips architektúránál a Hotspot egy külön csomag lett, így ha nincs rá szükség, akkor tárhelyet spórólhatunk
• a fájl listából (Files gomb) is egyszerűen indíthatunk Back-To-Home file share-t
• Winbox + WiFi ablak: a CAPsMAN gomb, amivel Manager-t tudsz indítani, átkerült Remote CAP fülről a WiFi fülre
• DHCP kliens konfigurálásakor figyelmeztetést kapunk, ha dot1x-es interfészt adtunk meg. Ezen kívül a kimenő csomagok DSCP és VLAN prioritás értéke beállítható
• a DHCP setup wizard egy plusz lépéssel bővült, checkbox pipálással kell megadnunk, ha más DNS szervert adnánk meg a klienseknek és nem a routert.
• megszűnt a lora csomag, minden funkciója átkerült a iot csomagba. Az iot-bt-extra csomag pedig újabb USB dongle-okat támogat
• IPSec teljesítmény javítás az IPQ-6010 chip-pel szerelt eszközökön. Ilyen pl. a hAP ax2 és ax3 is
• a sniffer mostantól pcapng formátumban ment, ami tartalmazza az interfész nevét és a csomag irányát, az időbélyeg pedig nanoszekundumos lett.
• elméletileg a PoE out switch-eknél az a helyzet, hogy ha újraindítod, akkor a rá csatlakoztatott PoE eszközök nem indulnak újra, kivéve, ha a PoE vezérlő is firmware frissítést kap. Lassan szokássá válik, hogy kap, 7.18-nál és 7.19-nél is ez volt és most is: az at és bt szabványú PoE vezérlők is frissülnek, tehát a frissítés a rá csatlakozott PoE eszközökben is rövid áramszünetet okoz.
• a DLNA (média szerver funkció) felismeri mostantól a flac fájlokat.