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

Helyi DNS bejegyzések automatikusan

Párszor már korábban is kérdezték tőlem: lehet-e olyat csinálni, hogy amikor valaki címet kap egy DHCP szervertől, akkor készüljön hozzá egy automatikus DNS bejegyzés. Ezt eddig is meg lehetett csinálni, de szkript kellett hozzá: vagy lefuttattunk egy olyat pár percenként, ami összeszedte az összes lease-t és beírta a statikus DNS bejegyzések közé, vagy esetleg egy DHCP szerver lease script-et használhattuk. Mostantól viszont ez leegyszerűsödött: A DHCPv4 szerver és a Neighbor Discovery kapott egy olyan lehetőséget, hogy a lease-ekhez, vagy akár neighbor lista bejegyzésekhez ilyen statikus DNS bejegyzés készülhet:

Természetesen a hosztnév utáni utótag (mint a képen a local.mindenamimikrotik.hu) szabadon megadható.

Ez kisebb hálózatokban kifejezetten kényelmes lehet. Nem kell minden eszközt kézzel felvenni a static DNS listába, mégis lehet értelmes neveken hivatkozni rájuk és nem vagyunk mDNS-hez kötve, pláne nem feltétlenül kell mDNS Proxy-t beállítani, ha esetleg több (V)LAN van. Ráadásul ezekkel nehezebb dolgunk lenne, ha azt szeretnénk, hogy VPN klienseknél is működjenek a domain nevek és ezek alapján az elérések.

Gyorsabb biztonságos DNS

A DoH (DNS over HTTPS) egyre népszerűbb, ami nem csoda: olyan titkosítással jönnek-mennek a DNS kérdések és válaszok, mintha HTTPS lenne. Sőt, valójában az is, ahogy a neve mutatja. Sima DNS-nél a forgalmak titkosítatlanok, így egy támadó belenyúlhat mondjuk a válaszba és más IP-t adhat vissza, mint ami valóban hozzá van rendelve a domain-hez. DoH-nál ez szinte kizárt, de ennek ára is van: jóval nagyobb protokoll overhead, TLS negotiation a DNS kérések előtt, ráadásul, ha mindez HTTP/1.1 alapon megy, akkor a párhuzamos kérések kezelése is bajosabb.

Ezért jó hír, hogy ARM64 és x86/CHR eszközökre megjött erre a HTTP/2 támogatás, ami azt jelenti, hogy egy kapcsolatban több kérés is hatékonyabban küldhető a szervernek, kevesebb kapcsolatfelvételre és TLS egyeztetésre van szükség, így javul az egész funkció teljesítménye.

Reverse-proxy bővülése

A v7.22 egyik érdekes újdonsága volt a RouterOS natív reverse proxy funkciója. A v7.23-ban ez tovább bővült: megjelent hozzá az IPv6 és VRF támogatás, valamint az SNI logging.

Az IPv6 támogatás elég egyértelmű: ha már van reverse proxy a RouterOS-ben, akkor ne csak IPv4-es világban tudjon gondolkodni. A VRF támogatás már haladóbb, de komolyabb környezetekben nagyon hasznos lehet. Ha külön routing táblákkal, ügyfélkörnyezetekkel, szolgáltatási zónákkal vagy szeparált hálózati részekkel dolgozunk, akkor nem mindegy, hogy a reverse proxy melyik routing világban él.

Az SNI logging hibakeresésnél lehet hasznos. TLS kapcsolatnál az SNI alapján látható, hogy a kliens milyen hostnévre próbált csatlakozni. Ha több belső szolgáltatást publikálunk ugyanazon publikus IP mögött, ez sokat segíthet annak kiderítésében, hogy pontosan milyen névre érkeztek kérések.

Ettől a RouterOS még nem lesz teljes értékű enterprise load balancer vagy ADC, de a reverse proxy funkció most előrébb lépett. Kis környezetben, lab-ban, vagy egyszerűbb belső szolgáltatások publikálásánál egyre érdekesebb.

Biztonságosabb frissítés

A 7.23 egyik kevésbé látványos, de fontos újdonsága, hogy a RouterOS upgrade folyamat mostantól alapból HTTPS-en keresztül kapcsolódik a MikroTik frissítési szervereihez. Ez nem az a funkció, amitől az ember azonnal rohan frissíteni, de üzemeltetői szemmel jó irány: a frissítéshez kapcsolódó kommunikáció biztonságosabb csatornára került.

Emellett beállítható lett az is, hogy az upgrade HTTP-t vagy HTTPS-t használjon, illetve IPv4-et, vagy esetleg IPv6-ot. Ez főleg olyan környezetekben lehet érdekes, ahol szigorúbb tűzfalszabályok, proxyk vagy kontrollált kimenő kapcsolatok vannak.

IPv6: több kontroll pool, RA és DHCPv6 környezetben

Fontos újdonság a DHCPv6 snooping . Ez nagyjából az IPv4-es DHCP snooping / Option 82 IPv6-os megfelelője: maga a Snooping segít kontrollálni, honnan, melyik portról érkezhet DHCPv6 információ a hálózaton, azaz megakadályozza egy rogue DHCP szerver működését (idegen routert LAN oldalát a hálózatra kötők, szevasztok!). Ráadásul Option 18 és Option 37 támogatással érkezett, ami meg a v4-es világ Option 82-jét tudja: plusz infókat ad hozzá a DHCP üzenetekhez és így a DHCP szerveren központilag láthatod, hogy melyik kliens melyik eszköz (jellemzően switch) melyik portjára csatlakozik.

IPv6 oldalon a 7.23 ezen kívül több, nem egy látványos „bekapcsolom és minden megváltozik” típusú újdonságot hoz, hanem néhány fontosabb finomhangolási lehetőséget. Ezek főleg azoknak lesznek érdekesek, akik nem csak annyit szeretnének, hogy „legyen valahogy IPv6”, hanem DHCPv6-PD-vel, RA-val és akár DHCPv6 szerverrel is hatékonyabban szeretnék üzemeltetni a hálózatot.

A from-pool-policy főleg DHCPv6-PD-s környezetben érdekes. Pontosabban szabályozható, hogyan vegyen fel a router címet egy IPv6 poolból, illetve mikor ne foglalja le kizárólagosan a prefixet más szolgáltatások elől. Ez például akkor hasznos, ha ugyanazt a /64-et szeretnénk a router interfészére tenni, RA/SLAAC-kal hirdetni, és közben DHCPv6 szerverrel is dolgozni belőle.

Router Advertisement oldalon is jött pár új kapcsoló. Beállítható lett, hogy a router figyelmen kívül hagyja az RA-ból érkező MTU-t vagy DNS szervereket. Ez például akkor jó, ha upstream irányból kapsz RA-t, de nem akarod vakon átvenni az összes benne lévő információt. Lehet, hogy az IPv6 route kell belőle, de a szolgáltató által hirdetett DNS szervereket nem szeretnéd használni.

Megjelent a router-advertisement-route-distance is. Ez globálisan állítja, hogy az RA-ból tanult IPv6 route-ok milyen distance értékkel kerüljenek be a routing táblába. Nem interfészenkénti finomhangolásról van szó, tehát nem ezzel fogsz tökéletes multi-WAN IPv6 prioritást építeni, de arra jó, hogy az RA-ból tanult útvonalak mennyire legyenek erősek a statikus, VPN-es vagy más dinamikus route-okhoz képest.

Appok és containerek: a router egyre inkább kis szolgáltatásplatform is

A v7.21-ben már elindult egy érdekes irány az App menüvel: a MikroTik elkezdte sokkal kényelmesebbé tenni a container-alapú szolgáltatások telepítését. A 7.23 ezt viszi tovább, elég látványosan.

Először is új App-ok érkeztek, összesen már 104 féle telepíthető egy néhány klikkel. Az újak között van irodai dokumentumkezelő, LoRa adatgyűjtő, levelező és kollaborációs szerver. A MikroTik eddig sem csak abban gondolkodott, hogy a router route-ol, NAT-ol és tűzfalaz, hiszen eddig is izgalmas új funkciókat kaptunk rendszeresen a frissítésekkel, de egyre inkább úgy érzem, hogy ez az egész Container/App vonal hosszú távon igazi midenessé teheti az eszközöket. Nyilván ez nem kisebb teljesítményű routerek világa, de egy erősebb eszköz akár komplett szolgáltatásplatform lehet.

Fontos új kapcsoló az appoknál a network-outgoing-access=yes/no. Ezzel megtiltható, hogy egy app kimenő kapcsolatokat kezdeményezzen. Ez főleg biztonsági szempontból érdekes: ha egy szolgáltatást helyben szeretnél használni, de nem akarod, hogy önállóan beszélgessen kifelé az internetre, akkor most erre van egy egyszerűbb eszközöd. Ez nem váltja ki a normális tűzfalszabályokat, de jó plusz védőkorlát. Ezen kívül restart parancs is érkezett az App-okhoz.

A Container-ek új lehetőségekkel bővültek: restart-policy=no/always/on-failure, stop-on-unhealthy, restart-count, restart-interval, restart-max-count – itt a dokumentáció még nem naprakész, de a nevükből elsőre arra lehet következtetni, hogy valamiféle automatikus restart lehetőséget nyújtanak, hogy ne a rendszergazdának kelljen egy esetlegesen nem működő kontérnert újraindítani, amikor már mindenki panaszkodik, hogy nem működik.

A másik fontos irány a memóriahasználat korlátozása. A 7.23-ban globálisan és container-enként is állítható lett a maximális memóriahasználat. Ez routeren különösen fontos, mert itt a container csak vendég. Nehogy már egy elszabadult container megegyen minden errőforrást az alap hálózati funkciók elől!

Switching és access hálózati újdonságok

A 7.23-ban több olyan újdonság is érkezett, ami nem klasszikus „routeres” funkció, hanem inkább switch-es, access hálózati vagy komolyabb infrastruktúrás környezetben érdekes. Az egyik ilyen a DHCPv6 snooping, amit az IPv6 résznél már említettem.

IPv4 oldalon is finomodott a DHCP snooping / Option 82 világ: külön állítható lett a dhcp-agent-circuit-id és a dhcp-agent-remote-id. Azaz a rendszergazda mondhatja meg, hogy egy switch pontosan milyen infóval egészítse ki a DHCP üzeneteket, amik aztán megjelennek a DHCP szerveren. Sajnos ezzel kapcsolatban van egy szerintem első ránézésre rossz módosítás is: a v7.23 DHCP szervere a kapott infókat hex-formátumban jeleníti meg, tehát nem egy jól olvasható string-et kapunk. Remélem, ezt hamarosan megváltoztatják, vagy esetleg a winbox-ban eldönthetővé teszik a megjelenítés módját.

A 7.23-ban a hardware offload QoS része is változott. Ez nem csak annyit jelent, hogy kaptunk pár új kapcsolót, hanem a MikroTik egyszerűsítette a QoS konfigurációt: több korábban kézzel állítandó rész automatikusabb lett, például a DSCP / PCP alapú QoS profil-hozzárendelés is. Magyarul, ha egy forgalom már meg van jelölve például DSCP vagy VLAN priority értékkel, a RouterOS könnyebben tudja azt a megfelelő QoS profilhoz kötni, kevesebb kézi mappinggel.

Másik fontos újdonság a lossless traffic class – eszközfüggő, nem minden switch-en érhető el. Ez olyan forgalmi osztályt jelent, ahol a cél az, hogy torlódás esetén se egyszerű csomagdobással kezelje a switch a helyzetet. Ehhez olyan mechanizmusok jöhetnek képbe, mint az ECN vagy a PFC. Az ECN még csomagdobás előtt jelzi a torlódást az erre képes végpontoknak, a PFC pedig bizonyos prioritási osztályoknál képes „megállítani” a küldést, hogy ne vesszenek el csomagok.

A CRS800-as eszközökön egyébként az ECN és PFC még hiányzott, ezt most pótolták. Szintén ezek az eszközök VRF támogatást kaptak L3 hardware offload mellett.

Hasznos továbbiak

• A mangle táblában megjelent a drop action.
• A log action e-mail küldésnél megjelent a CC mező, ami automatizált értesítéseknél jól jöhet.
• A remote logolás TLS támogatást kapott, ami biztonságosabb távoli logküldésnél hasznos.
• A Let’s Encrypt lett az alapértelmezett ACME directory, most már nem kell kézzel megadni.
• Appoknál használható lett az XFS fájlrendszer is.
• App telepítésnél van portütközés-ellenőrzés.
• A file-okhoz copy, head és tail parancsok érkeztek.
• /disk smart-info is elérhető lett, ami storage-os / containeres környezetben hasznos.
• Ext4, Btrfs és XFS fájlrendszerekhez check/repair lehetőség érkezett.
• Az export kapott path paramétert, ami célzottabb mentéseknél és automatizálásnál hasznos.
• MACsec oldalon elérhető lett az aes-gcm-xpn-128 cipher, főleg nagyobb forgalmú L2 titkosított linkekhez.
• USB oldalon bekerült az ax88179_178a driver, ami bizonyos USB Ethernet adaptereknél lehet hasznos.
• IoT oldalon érkezett Wiliot támogatás is. A Wiliot az úgynevezett ambient IoT világába tartozik: apró, elem nélküli, cimke méretű és formátumú tagekkel / szenzorokkal lehet fizikai tárgyakat, csomagokat vagy termékeket követni, például raktári, logisztikai vagy ellátási láncos környezetben. Elem, akksi nincs, tehát nem kell x év után cserélni, de akkor honnan kapják az energiát? Ez rf-jelekkel történik, ehhez kell egy bridge/energizer és fontos limitáció, hogy ez a működés még nincs implemetálva a MikroTik-nél, így erről a funkcióról bővebben várhatóan majd egy későbbi kiadásban írok.