Tutorial
RouterOS frissítési és javítási útmutató
Hogyan frissítsd és javítsd a MikroTik RouterOS-t ISP-flottában: kiadási csatornák, fokozatos bevezetés, mentések, visszaállítás és a 2026-os CVE-k.
Összefoglaló A MikroTik RouterOS frissítése egy ISP-flottában ellenőrzött folyamat, nem egykattintásos művelet. Válassz az SLA-idhoz illő kiadási csatornát, ments minden eszközt, ellenőrizz egy piloton, majd vezess be topológiatudatos hullámokban, világos visszaállítási útvonallal. 2026-ban ez fontosabb, mint valaha: egy nyilvánosan kihasználható RouterOS-hiba (CVE-2026-7668) és egy friss stable kiadás (7.23.1) azt jelenti, hogy a javítatlan peremeszközök aktív kockázatot jelentenek.
Mi a RouterOS-javítás egy ISP-flotta esetében?
A RouterOS-javítás az a fegyelmezett folyamat, amelynek során a MikroTik eszközök egy populációját az egyik RouterOS-verzióról egy újabbra emeljük, hogy javítsuk a biztonsági réseket, a stabilitási hibákat és a viselkedésbeli regressziókat — anélkül, hogy elrontanánk a rajtuk futó szolgáltatásokat. Egyetlen otthoni routeren ez kétperces feladat. Több száz vagy ezer CPE és peremrouter esetén üzemeltetési programmá válik: szükséged van kiadási csatorna szabályzatra, mentési szabványra, staging lépésre, fokozatos bevezetésre és visszaállítási tervre. A cél könnyen kimondható és nagy léptékben nehéz elérni — minden eszköz végül javított lesz, és egyik sem esik ki közben.
Megérdemel egy valódi munkafolyamatot, mert egy frissítés pontosan azt érinti, amit nehéz újra elérni, ha elromlik: egy routert az ügyfél peremén, gyakran CGNAT mögött. Egy rossz kiküldés, amely elveszti a felügyeleti hozzáférést, kiszállássá válik. Ezért az alábbi munkafolyamat először a biztonságra és az elérhetőségre optimalizál, és csak másodsorban a sebességre.
Miért javíts most: a 2026-os biztonsági helyzet
A javítási ütem csendes háttérfeladat marad, amíg egy sérülékenység rá nem kényszerít, és 2026 konkrét okokat ad a szigorításra. A CVE-2026-7668 egy out-of-bounds olvasás a RouterOS SCEP-végpontjában, CVSS 7.3 (magas) pontszámmal; távolról kiváltható, és nyilvános exploit létezik. A ciklus külön tanácsadói egy nem megfelelő hozzáférés-vezérlési problémát fednek le a VXLAN forrás-IP-validálásban (javítva a RouterOS 7.20-ban és újabbakban), valamint egy memóriasérülési hibát az SMB-szolgáltatásban, amelyet egy hitelesítés nélküli támadó preparált csomagokkal válthat ki.
A MikroTik útmutatása következetes: tartsd a RouterOS-t naprakészen és olyan tűzfal mögött, amely blokkolja a nem megbízható hálózatokat. A jelenlegi stable ág, a RouterOS 7.23.1 (kiadva 2026. június 2-án), javít egy BGP memóriaszivárgást és egy DHCPv4-snooping stabilitási problémát is. Ez a hétköznapi oka annak, hogy a flottáknak ismételhető javítási folyamatra van szükségük az eseti frissítések helyett.
1. lépés — Válaszd ki a megfelelő kiadási csatornát
A RouterOS több ágat kínál, és a választás szabályzati döntés, nem preferencia. A stable kiadások néhány havonta jelennek meg tesztelt funkciókkal és javításokkal; a long-term kiadások csak kritikus és biztonsági javításokat kapnak, és sokkal kevesebbet változnak a verziók között. A kiszámíthatóságot értékelő ISP perem- és CPE-flották számára a long-term ág gyakran a helyes alapértelmezés, a stable pedig azokra a hardverekre vagy funkciókra van fenntartva, amelyek megkövetelik. Bármit is választasz, soha ne futtass testing vagy development buildet éles környezetben. Dokumentáld az ágat eszközosztályonként, hogy a döntés ismételhető legyen a csapaton belül.
2. lépés — Először ments és exportálj
Soha ne frissíts visszaállítási pont nélkül. Hozz létre bináris mentést (/system backup save) és ember által olvasható konfigurációs exportot (/export file=) is, mert az export túléli a verzióváltásokat, és lehetővé teszi az újraépítést akkor is, ha egy bináris mentés nem áll vissza egy másik buildre. Húzd le mindkettőt az eszközről a felügyeleti rendszeredbe. Indulás előtt erősítsd meg, hogy elég szabad tárhely van az új csomagokhoz, és részesítsd előnyben a vezetékes vagy konzolkapcsolatot — a Wi-Fi-n vagy ingatag kapcsolaton végzett frissítés az a mód, ahogy a routerek írás közben tönkremennek. Azoknál az eszközöknél, ahol a helyreállítási hozzáférés a valódi aggály, a Netinstall helyreállítási útmutatónk a tartalék, amikor egy frissítés balul üt ki.
3. lépés — Tesztelj egy pilot eszközön
Először egy reprezentatív routert frissíts, és figyeld. Válassz egy eszközt, amely tükröz egy éles osztályt — azonos modell, azonos szerep, hasonló konfiguráció —, és alkalmazd a célverziót egy karbantartási ablakban. Újraindítás után ellenőrizd a verziót, erősítsd meg, hogy a csomagok engedélyezve vannak, és tekintsd át a changelogot a konfigurációdat érintő viselkedésbeli változások (tűzfal-szemantika, alapértelmezett szolgáltatások, interfész-elnevezés) miatt. Csak amikor a pilot tiszta, akkor engedélyezed a szélesebb bevezetést. Ez az egyetlen lépés megelőzi a legdrágább hibamódot: egy regresszió felfedezését azután, hogy az már ezer ügyfélhez kiment.
4. lépés — Vezesd be topológiatudatos hullámokban
A tömeges bevezetés a sorrendről és a tempóról szól, nem arról, hogy mindenhol egyszerre megnyomsz egy gombot. Csoportosítsd az eszközöket topológia szerint, hogy a láncba kapcsolt routerek sorrendben frissüljenek — nem akarod, hogy egy felsőbb router újrainduljon, mielőtt egy alsóbb eszköz letöltötte volna a csomagjait. Határozz meg hullámokat saját karbantartási ablakkal, és kövess minden eszközt egy egyeztetési listában, hogy minden problémás egység visszakerüljön a sorba, ne pedig feledésbe merüljön. Az internetes sávszélesség csökkentésére irányítsd az eszközöket egy központi routerre, amely helyi csomagtükörként működik; ez azt is szabályozza, melyik verziót töltheti le a flotta.
A fokozatos bevezetés csak akkor működik, ha valóban el tudsz érni minden eszközt, hogy megerősítsd a visszatérését. Ez az üzemeltetési buktató a CGNAT mögötti CPE-knél — és itt térül meg a központosított felügyelet.
5. lépés — Ellenőrizz, majd szükség esetén állíts vissza
Minden hullám után erősítsd meg az eredményt: ellenőrizd a jelentett verziót, erősítsd meg, hogy a routerboard firmware-e is frissült, ahol alkalmazható (/system routerboard upgrade), és igazold, hogy a számodra fontos szolgáltatások átengedik a forgalmat. Ha egy eszköz hibásan működik, állítsd vissza a korábbi bináris mentést, vagy építsd újra az RSC-exportból, vagy végső esetként telepítsd újra a korábbi verziót Netinstall segítségével. Egy javítási program nem „kész”, amikor az új verzió telepítve van — akkor kész, amikor minden eszköz egészségesnek igazolt, és minden kivétel lezárásig követve van.
Tippek a flottaszintű javításhoz
- Szabványosíts egyetlen megerősített alapkonfigurációt, hogy a frissítések kiszámíthatók legyenek. A Winbox biztonsági legjobb gyakorlataink és a device-mode biztonsági üzemeltetési útmutatónk határozzák meg azt az alapkonfigurációt, amelyre a legtöbb frissítési probléma visszavezethető.
- Korlátozd a felügyeleti hozzáférést VPN-re vagy megbízható IP-kre a frissítések előtt és után, hogy egy félig javított flotta soha ne legyen kitéve.
- Tartsd a felügyeleti síkot elérhetőnek CGNAT mögött is, hogy az ellenőrzés és a visszaállítás ne igényeljen helyszíni látogatást.
- Tekintsd át a MikroTik biztonsági tanácsadóit ütemezés szerint, ahelyett, hogy incidensre várnál.
GYIK
Milyen gyakran frissítsem a RouterOS-t? Értékelj minden kiadást az ág-szabályzatod alapján, és javíts soron kívül, valahányszor egy tanácsadó az általad kitett szolgáltatásokat érinti. Nincs fix intervallum — csak egy kockázat által vezérelt ütem.
Stable vagy long-term egy ISP-flottához? A long-term a biztonságosabb alapértelmezés a peremre és a CPE-re; a stable-t ott használd, ahol újabb hardvertámogatásra vagy funkciókra van szükséged, miután stagingben validáltad.
Mi van, ha egy frissítés tönkretesz egy távoli eszközt? Állítsd vissza mentésből vagy RSC-exportból; ha az eszköz elérhetetlen, állítsd helyre Netinstallal. Ezért kötelező egy tesztelt mentés és egy elérhető felügyeleti útvonal minden hullám előtt.
Javítsd az egész flottádat kiszállások nélkül
A flottajavítás legnehezebb része nem a frissítés — hanem minden eszköz elérése és ellenőrzése utána, különösen a CGNAT mögötti CPE-knél. Az MKController központosítja a láthatóságot a teljes MikroTik flottád felett, a NATCloud pedig belülről kifelé biztosít elérhetőséget portátirányítás nélkül, így a fokozatos bevezetések, az ellenőrzés és a visszaállítás mind távolról zajlik.