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

RouterOS <3 iPhone

Tegye fel a virtuális mancsát, aki tudta, hogy Android-os telefon lehet net uplink USB kapcsolattal egy MikroTik eszközön! v6.7, azaz 2013 óta benne van, de én korábban sose hallottam erről. Nyilván a mai telefonokon amúgy is meg tudod osztani wifin a mobilnetet, így ha esetleg nincs backup net pl. egy irodában és szolgáltatás megáll, akkor nem vagytok elzárva a külvilágtól. De mi van akkor, ha egy nagyobb hálózatról van szó, nagyobb terület, több AP, amit egy mobil wifi hotspot-ja nem tud helyettesíteni? Vagy ha wifin mégiscsak a céges hálóra kellene csatlakozni, mert csak úgy érhető el mondjuk egy szerver? Akkor csak tedd ezt:

Az apropó, ami miatt számomra is kiderült, hogy amúgy van ilyen funkció: v7.22-től már usb csatlakozós iPhone-okkal is működik ugyanez.

Log üzenetből script futtatás

A RouterOS log-olása eléggé személyre szabható – eldönthetjük, hogy milyen témájú log üzenetekre van szükségünk és azok milyen módon, hol tárolódjanak. Mostantól viszont azt is meg lehet tenni, hogy egy bizonyos témájú, vagy bizonyos prefix-et tartalmazó, vagy bizonyos tartalommal rendelkező üzenet megjelenése esetén egy script lefusson és pl értesítse a rendszergazdát egy eseményről, vagy meghozzon az eszköz valamilyen intézkedést, be/ki kapcsoljon egy funkciót, vagy futtasson le egy egyéni script programot. Pl: valamelyik ethernet interfész elveszíti a linkjét? Vagy éppen TCP syn flood-ot kap az eszköz? Mehet az értesítés a rendszergazdának emailben, vagy SMS-ben, hogy még az előtt tudjon lépéseket tenni, hogy júzerek panaszkodni kezdenének.

Itt a reverse-proxy

Eddig is volt arra lehetőség, hogy Reverse Proxy-t futtassunk a MikroTik-en, de csak container-ben és emiatt nem minden eszközön. Most érkezett egy natív RP.

Mire jó ez? Tegyük fel, hogy több belső szervered van, amiket eddig port forwarddal értél el. Mivel egy portot (pl. TCP 443) csak egyetlen belső címre irányíthatsz, maradt a bűvészkedés a nem szabványos portokkal: ilyenkor jött a nyűg, hogy az URL után oda kellett pötyögni a kettőspontot és a portszámot.

A reverse proxy viszont egy jobb kapuőr, amely a beérkező kéréseket nem a portszám, hanem a kért domain név (vagy URL útvonal) alapján irányítja a megfelelő belső szerverhez, miközben képes a titkosítást (SSL) is helyesen kezelni.”

Lengyelfutó kakukkgyalog

A lányom nevezte így egyszer gyerek korom egyik kedvenc rajzfilmsorozatát (fiatalok kedvéért: Kengyelfutó Gyalogkakukk). Na ebben az összes robbanó izére, meg kütyüre a képzeletbeli ACME cég volt ráírva.

Nem tehetek róla, de az ACME szóról még mindig ez a sorozat jut eszembe, pedig ez közben IT-s körökben egy rövidítés lett, mégpedig az Automatic Certificate Management Environment-é. Ez egy olyan protokoll, amely lehetővé teszi az SSL/TLS tanúsítványok igénylésének, telepítésének és megújításának teljes körű automatizálását a webszerverek és a tanúsítványkibocsátók között. Amikor pl. a MikroTik-en Let’s Encrypt tanúsítványt igényelsz, akkor a háttérben ez fut le.

v7.15-óta más kibocsátók ACME szolgáltatása is igénybe vehető volt, de csak egy, v7.22-től viszont már több ACME is megadható.

MLAGetett szamár

Pont a napokban beszélgettem valakivel bővebben az MLAG-ről (Multi-chassis Link Aggregation Group) és most jelentős változások jöttek ennél a funkciónál. De először az alapok, hiszen nem mindenki ismeri, hogy miről is szól ez: Tegyük fel, hogy van egy fontos szervered, ami be van kötve egy switch-re. Igen ám, de minél teljesebb redundanciára is szüksége lenne, tehát jó lenne ezt a szervert bekötni még egy switch-re, így ha az elsővel valami gond lenne, akkor is menne tovább a forgalom. Ez megoldható lenne RSTP-vel is, de az MLAG jobb választás lehet: egyrészt gyorsabban reagál gond esetén, másrészt pedig, ha mindkét link aktív, akkor terheléselosztás is mehet köztük.

Eddig az MLAG csak Marvell Presta switch chip-ekel szerelt eszközökön volt használható, ezek jelenleg (2026. március) a CRS300-as, 400-as, 500-as és 800-as eszközök, a CCR2116 és 2216, valamint az RDS. Mostantól az MLAG bármilyen eszközön beállítható! Ugyanakkor jelen állás szerint csak a fenti eszközökön működhet Hardware offload-dal együtt, viszont enélkül is jól jöhet pl. CHR-ek, vagy erős CPU-val szerelt routerek esetén.

A változás konfigurációs változással is jár: az MLAG beállítások beköltöznek a bridge interfészbe (eddig külön fül volt a bridge ablakon). Emiatt megváltozik az egyes beállítások szintaktikája. Csak egy példa: ami eddig CLI-n priority volt az MLAG menüben, az mostantól mlag-priority. Ezek miatt, ha már most is használsz MLAG-et és upgarde-elnél 7.22-re, vagy fölé, akkor mindenképpen legyen előtte mentés – ha esetleg utána úgy döntesz, hogy downgarde-elsz, akkor a megváltozott szintaktika miatt ezek a beállítások eltűnnek.

Hasznos továbbiak

• Mostantól netinstall során is megadható device-mode a és néhány beállítás a system/routerboard pontból
• Az App menüben megadható app-store URL, így más tárat is becsatolhatsz, valamint 3 további container-rel bővült a menü (jupyter-notebook, livebook, myip)
• A BGP add-path, unnumbered és multipath támogatást kapott, utóbbinak köszönhetően ECMP útvonalakat hozhat létre.
• A fetch parancs támogatja a HTTP/2-t ARM64 és x86/CHR eszközökön
• A HotSpot-ot be lehet kapcsolni Wireguard interfészen
• Az L009-es eszközre ARM64 is telepíthető. Az smips architektúra viszont helyhiány miatt elveszített néhány funkciót (ipscan, mac-scan, ping-speed, flood-ping)
• QDK mostantól winbox-ban is beállítható
• A bridge-ben RA (Router Advertisement) Guard jelent meg, ami nagyon leegyszerűstve a DHCP snooping IPv6-os megfelelője: ha valaki egy IPv6-os routert köt egy access portra, akkor az a router helyesen beállított RA guard esetén nem tudja magát gateway-ként behirdetni a hosztok felé.
• És a végére egy fekete ló, amit nem tudok hova tenni egyelőre, mert semmiféle dokumentáció nincs jelenleg: interface/wifi/network menü jelent meg CLI-n, amivel a changelog szerint magasabb szintű hálózati konfiguráció lehetséges. Egyelőre csak annyi látszik benne, hogy ott van néhány opció, amiknek a többsége az interface/wifi/configuration-ben is benne van. Később meglátjuk, hogy mi sül ki ebből.