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.21 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!

Az elején egy gyors kitérő: a MikroTik végre a 7-es verziónál is ketté választotta a stable és long term channel-t. Technikailag eddig is külön voltak, de tartalmában nem, mindkét channel-ben ugyanaz a verzió volt, így igazi long term megoldásról nem beszélhettünk. Eddig. Az új 7.21-es verzió stable kiadás lett, a 7.20-as pedig long term, amit várhatóan hosszabb ideig fognak javítgatni komolyabb funkcióbeli változtatás nélkül. Aki korábban is a long term kiadásokra esküdött, az most végre megkapta.

Container telepítés sokkal egyszerűbben

Egy container telepítése, ha nincs hozzá kész tutorial, vagy találat a dokumentációban elég szívás tud lenni: envlist-ek, mount-ok, default értékek…

De most megérkezett az Apps menü, amiből egy klikkel tudsz jelen állás szerint 80 féle containert-t telepíteni! Mindössze a container csomag kell hozzá, engedélyezni a device-mode-ban, egy tároló ext4, vagy btrfs fájlrendszerrel, egy gyors setup (tároló és default bridge választás) és mehet is! A container-ek CPU, RAM, diszk és hálózat használata pedig monitorozható az app bejegyzésen

Jelenleg arm64 és x86 architektúrán működik.

Ezen kívül arm64 és x86 architektúrán az USB portra videó capture eszközök köthetőek be, amik aztán átadhatók egy container-nek és Bluetooth eszköz támogatás is érkezett. Pluszban azt is megszabhatjuk, hogy egy container mely CPU-kat/magokat használhatja.

Változás néhány tool-ban

Mostantól a Winbox-ban Bandwidth test-nél, speedtest-nél, ping-nél vagy traceroute-nál megadsz egy domain nevet, akkor a saját DNS szolgáltatását használja az eszköz a feloldásra. Eddig csak az IP menü DNS pontjában megadott DNS resolver-eket használta, ezért ha pl. egy static-ba felvett, vagy éppen Adlist-en szereplő domain-t ping-ettél, akkor nem éppen az elvárt működés volt. Mostantól, ha pl. van egy saját akár nem létező domainre szóló DNS bejegyzésed, akkor a ping az abban megadott címre fog menni. Egyébként ez CLI-n ping és traceroute esetén már korábban is így működött.

Certificate és web szolgáltatás változások

Még a 7.19-es verziónál érkezett meg a Trusted root store, amiben a megbízható legfelsőszintű tanúsítványok vannak. Ezzel az eszközöd önállóan le tudja ellenőrizni pl. egy HTTPS fetch, egy DoH kérés, Adlist letöltés, vagy egy SSTP kérés során a szerver tanúsítványának a megbízhatóságát. Most tovább okosodott a megoldás, hiszen mostantól már azt is meg tudod adni, hogy mely funkciókra legyenek megbízhatóként kezelve a tanúsítványok.

Ezen kívül, ha létrehozol, vagy beimportálsz egy új tanúsítványt, akkor meg tudod adni, hogy az eszközöd mely funkciók számára tartsa nyilván megbízhatóként – ez tovább növeli a rendszer biztonságát, de csak ha ki is használod: ha mondjuk importálsz egy tanúsítványt, akkor lehetőleg ne hagyd a „minden is be van pipálva” default beállításon, hanem csak arra tedd megbízhatóvá, amire tényleg használni fogod.

Jelenleg egy már meglévő/importált, vagy éppen kért (pl. Let’s Encrypt) tanúsítvány trust store paraméterein utólag csak CLI paranccsal tudsz módosítani.

Félig meddig a certificate-ekhez is tartozik egy másik újítás: mostantól be lehet azt állítani, hogy a web szerver szolgáltatások pontosan mely „alszolgáltatás” esetén működjenek: eddig vagy be-, vagy kikapcsoltuk ezeket és ha be-, akkor TCP 80-on, vagy 443-on bármit meg lehetett tenni. Mostantól szűrhetünk: mondjuk ne legyen webfig, de azért ACME-val lehessen Certificate-et igényelni/megújítani és menjen a REST API is.

Wifi CAPsMAN újdonságok

Röviden, ha már ismered a CAPsMAN-t: a Wifi CAPsMAN-ben most már tudsz Wifi 6-os és 7-es eszközökön manager forwarding módot alkalmazni ráadásul a CAP és a manager közti hasznos adatforgalom titkosítással is ellátható.

Ha pedig meglévő wifi CAPsMAN rendszered van, akkor is érdemes lehet frissíteni, ugyanis megérkeztek a Unsolicited (kéretlen) BSS Transition Management Request-ek támogatása. Ez a 802.11v szabvány része és a hálózat hatákonyságát növeli

Ha úgy érzed, hogy ezzel megvagy és pontosan tudod, hogy miről beszélek, el tudod mondani magadban pl. a manager forwarding mód előnyeit, akkor ugorhatsz is a következő részre. Ellenkező esetben olvass tovább.

A CAPsMAN alapjai:

Kezdjük ott (hiszen nem biztosan nem mindenki ismeri), hogy mi is az a CAPsMAN. Ez a MikroTik megoldása arra, hogy ha több AP-t egy eszközből szeretnél vezérelni. Ideális sok AP-s hálózatokban, amikor nem akarod az összes eszközt egyenként beállítgatni és egy helyen láthatod az összes felcsatlakozott klienst is. A rendszer részei ilyenkor egy manager (bármilyen RouterOS eszköz) és CAP-ek (Controled Access Point), azaz a menedzselt, AP-ként is működő eszközök. Nem összekeverendő a CAP hardverekkel, bármilyen wireless-es MikroTik lehet ebben az esetben CAP

Valójában jelenleg két CAPsMAN létezik: az egyikkel wlan interfészeket lehet vezérelni (wlan CAPsMAN), a másikkal pedig wifi interfészeket (wifi CAPsMAN). A wlan vs wifi interfészek közti különbségekről itt olvashatsz bővebben.

A CAPsMAN alapjairól bővebben ebben a videóban találsz infókat.

A CAPsMAN bizonyos esetekben segítheti a gyorsabb és okosabb wifi roamingot is, így akár 2 AP esetén is lehet értelme. Erről itt találsz bővebb infót.

A CAPsMAN forgalomirányítása:

Ilyen hálózatnál eldöntendő kérdés, hogy kire bízzuk a forgalomirányításai döntések meghozatalát. Az egyik mód a manager forwarding. Ennek előnye, hogy ilyenkor a legegyszerűbb a CAP-ek beállítása: gyakorlatilag 2-3 klikk és megvan, egy nagyobb hálózatnál rengeteg idő megspórolható. Ilyenkor a CAP-ek minden forgalmat a manager-nek küldenek egy speciális keretbe csomagolva és ő dönt a forgalmakról. Igen ám, de ez csak akkor jó megoldás, ha a manager és a CAP-ek ugyanazon a LAN-on vannak.

Ha a manager másik LAN-ban van, akkor nem annyira jó ötlet a wifi kliensek összes forgalmát átküldeni neki, hanem inkább közvetlenül a gateway-ra kellene küldeni, hogy ne terheljük agyon a hálózatot. Vagy ha a manager felhőben van: ennél a módnál minden forgalmat először a felhőbe küldünk és ott route-olja a manager a valódi cél felé, meg a válaszokat is vissza – nem túl hatékony működés.

Ilyenkor jön képbe a local forwarding mód: a CAP-ek önállóan döntenek a forgalomirányításról, köztük és a manager között minimális forgalom lesz, csak vezérlési, kapcsolatfenntartási forgalmak mennek. Hátránya ennek a módnak, hogy ilyenkor a CAP-eken több beálltás kell, ha pedig vendég wifit is akarunk, akkor meg már VLAN-ok is kellenek.

A wlan CAPsMAN esetén mind a két mód elérhető volt a kezdetektől. Viszont wifi CAPsMAN-nél csak a local forwarding működött eddig. A 7.21-es verziótól lehet manager forwarding-ot is beállítani, de csak Wifi 6-os és 7-es eszközökön. Ha egy Wifi 5-ös eszközt okosítasz fel wifi interfészesre, azon jelenleg továbbra is csak a local forwarding mehet.

A manager forwarding mode használható titkosítással is: a menedzsment forgalmak mindenképpen titkosításra kerülnek, ez így volt már a wlan CAPsMAN-nél is. Wifi CAPsMAN-nél viszont a kliensek manager és adott CAP között közlekedő hasznos adatforgalmára is ráhúzható egy titkosítás. Ennek viszont ára van: a manager CPU terhelése eléggé megnőhet, ahogy ebben a videóban be is mutattam.

A CAPsMAN működéséről, beállításáról, tippekről/trükkökről szól a MikroTik Online Klub legfrissebb anyaga. A fenti videó is ennek a része és az első három részt itt teljes egészében meg tudod nézni.

A többinek a tartalmát pedig itt láthatod. Bármilyen szintű klubtagsággal azonnal hozzáférhetsz!

Hasznos továbbiak

• A Hotspot szerver helyben tárolt user-ei TOTP támogatást kaptak. Tehát úgy tudsz kétfatkotors hitelesítést bevezetni a Hotspot felhasználókra, hogy nem kell hozzá RADIUS szerver, vagy User manager. A TOTP-ről van anyag szintén a MikroTik Online Klubban.
• Az OpenVPN szerver mostantól IPv6 útvonalakat is tud push-olni
• A DHCPv4 szerver TR-101 támogatást kapott, ezzel plusz infók adhatóak át a kliensekről a RADIUS szervernek
• A route-oknál ha bekapcsoljuk a Check gateway-t ping alapúra, akkor meg lehet változtatni azt, hogy hány sikertelen egymás utáni ping után legyen az útvonal unreachable állapotú és mennyi legyen a ping-ek timeout-ja és a gyakorisága. (Routing menü Settings pontja)
• A User manager RadSec támogatást kapott, így egy RADIUS kliensek és manager közti kommunikáció biztonságosabbá tehető
• RPS (Receive Packet Steering) támogatás érkezett arm64-re, ami a bejövő forgalmak CPU magok közti szétosztásában segíthet. Ne kapcsold be addig, amíg nem tapasztalsz olyat, hogy egy mag normál forgalmak mellett agyon van terhelve, míg a többi pihen. Tipikusan egy interfészen beeső nagyobb mennyiségű enkapszulált forgalmak (pl PPP VPN-ek) esetén lehet értelme.
• A RAW filterben TOS érték és maszk alapon is engedélyezhetünk/szűrhetünk forgalmakat (sima filter-ben eddig is lehetett)
• Jövőálló IPSec? A jóslatok szerint a kvantumszámítógépekkel a mostani titkosítások törhetők lesznek. Egy most elkapott IPSEc csomag később várhatóan kinyitható lesz. Hacsak… nem kezded el használni már most Post-Quantum Pre-shared Key (PPK) és a Quantum Key Distribution (QDK) megoldásokat, amik most megérkeztek
• Az első, eredeti SXT LTE (RBSXTLTE3-7) mostantól nem kap LTE csomag frissítést, azon a 7.20.x az utolsó LTE csomag verzió
• A MACsec Hardware offload támogatást kapott az alábbi eszközökön: RB5009, hAP ax3, Chateau ax ether1
• A BGP megkapta az RFC 9234 alapú route leak prevention-t.