Tutorial
MikroTik RouterOS opdatering & patch-guide
Sådan opdaterer og patcher du MikroTik RouterOS i en ISP-flåde: udgivelseskanaler, faseinddelt udrulning, backups, rollback og 2026-CVE'erne.
Resumé At opdatere MikroTik RouterOS på tværs af en ISP-flåde er en kontrolleret proces, ikke en handling med ét klik. Vælg en udgivelseskanal, der passer til dine SLA’er, tag backup af hver enhed, validér på en pilot, og rul derefter ud i topologibevidste bølger med en klar rollback-sti. I 2026 betyder det mere end nogensinde: en offentligt udnyttelig RouterOS-sårbarhed (CVE-2026-7668) og en frisk stable-udgivelse (7.23.1) betyder, at uopdaterede edge-routere er en aktiv risiko.
Hvad Er RouterOS-Patching for en ISP-Flåde?
RouterOS-patching er den disciplinerede proces med at løfte en population af MikroTik-enheder fra én RouterOS-version til en nyere for at rette sikkerhedshuller, stabilitetsfejl og adfærdsregressioner — uden at ødelægge de tjenester, der kører oven på dem. På en enkelt hjemmerouter er det en to-minutters opgave. På tværs af hundreder eller tusinder af CPE’er og edge-routere bliver det til et operationelt program: du har brug for en politik for udgivelseskanaler, en backup-standard, et staging-trin, en faseinddelt udrulning og en rollback-plan. Målet er let at formulere og svært at gøre i stor skala — hver enhed ender opdateret, og ingen af dem går ned undervejs.
Den fortjener en rigtig arbejdsgang, fordi en opgradering rører ved netop det, du ikke nemt kan nå igen, hvis den fejler: en router ved kundekanten, ofte bag CGNAT. Et dårligt push, der mister administrationsadgangen, bliver til et udkald. Derfor optimerer arbejdsgangen nedenfor først for sikkerhed og tilgængelighed, hastighed derefter.
Hvorfor Patche Nu: Sikkerhedsbilledet 2026
Patch-kadencen forbliver en stille baggrundsopgave, indtil en sårbarhed tvinger sagen, og 2026 giver konkrete grunde til at stramme den. CVE-2026-7668 er en out-of-bounds-læsning i RouterOS’ SCEP-endpoint med en score på CVSS 7.3 (Høj); den kan udløses eksternt, og en offentlig exploit findes. Separate advisories i denne cyklus dækker et problem med utilstrækkelig adgangskontrol i VXLAN-kilde-IP-validering (rettet i RouterOS 7.20 og senere) og et hukommelseskorruptionshul i SMB-tjenesten, som en uautoriseret angriber kan udløse med præparerede pakker.
MikroTiks vejledning er konsistent: hold RouterOS opdateret og bag en firewall, der blokerer utroværdige netværk. Den aktuelle stable-gren, RouterOS 7.23.1 (udgivet 2. juni 2026), retter også et BGP-hukommelseslæk og et stabilitetsproblem ved DHCPv4-snooping. Det er den almindelige grund til, at flåder har brug for en gentagelig patch-proces frem for ad hoc-opgraderinger.
Trin 1 — Vælg Den Rigtige Udgivelseskanal
RouterOS tilbyder mere end én gren, og valget er en politikbeslutning, ikke en præference. Stable-udgivelser udkommer hver par måneder med testede funktioner og rettelser; long-term-udgivelser modtager kun kritiske rettelser og sikkerhedsrettelser og ændrer sig langt mindre mellem versioner. For edge- og CPE-flåder hos ISP’er, der værdsætter forudsigelighed, er long-term-grenen ofte det rigtige standardvalg, mens stable reserveres til hardware eller funktioner, der kræver det. Uanset hvad du vælger: kør aldrig testing- eller development-builds i produktion. Dokumentér grenen pr. enhedsklasse, så beslutningen er gentagelig på tværs af teamet.
Trin 2 — Tag Backup og Eksportér Først
Opgradér aldrig uden et gendannelsespunkt. Opret både en binær backup (/system backup save) og en menneskelæsbar konfigurationseksport (/export file=), fordi eksporten overlever versionsskift og lader dig genopbygge, selv hvis en binær backup ikke kan gendannes på en anden build. Træk begge af enheden over i dit administrationssystem. Bekræft, at der er nok ledig lagerplads til de nye pakker, før du starter, og foretræk en kablet forbindelse eller konsolforbindelse — at opgradere over Wi-Fi eller en ustabil forbindelse er måden, routere bliver bricket midt i en skrivning. For enheder, hvor gendannelsesadgang er den egentlige bekymring, er vores Netinstall-gendannelsesguide reserven, når en opgradering går galt.
Trin 3 — Test på en Pilotenhed
Opgradér først én repræsentativ router, og hold øje med den. Vælg en enhed, der afspejler en produktionsklasse — samme model, samme rolle, lignende konfiguration — og anvend målversionen i et vedligeholdelsesvindue. Efter den genstarter, verificér versionen, bekræft at pakkerne er aktiveret, og gennemgå changeloggen for adfærdsændringer, der påvirker din konfiguration (firewall-semantik, standardtjenester, interfacenavngivning). Først når piloten er ren, autoriserer du den bredere udrulning. Dette ene trin forhindrer den dyreste fejltilstand: at opdage en regression, efter den allerede er sendt ud til tusind kunder.
Trin 4 — Rul Ud i Topologibevidste Bølger
Masseudrulning handler om rækkefølge og tempo, ikke om at trykke på en knap alle steder på én gang. Grupper enheder efter topologi, så kædede routere opdateres i sekvens — du vil ikke have, at en opstrøms router genstarter, før en nedstrøms enhed har hentet sine pakker. Definér bølger med deres egne vedligeholdelsesvinduer, og spor hver enhed i en afstemningsliste, så enhver enhed med et problem bliver sat i kø igen, ikke glemt. For at spare internetbåndbredde, lad enheder pege på en central router, der fungerer som et lokalt pakke-mirror; det styrer også, hvilken version flåden må hente.
En faseinddelt udrulning virker kun, hvis du faktisk kan nå hver enhed for at bekræfte, at den kom tilbage. Det er den operationelle hage ved CPE bag CGNAT — og hvor centraliseret administration tjener sit værd.
Trin 5 — Verificér, Rul Derefter Tilbage om Nødvendigt
Bekræft resultatet efter hver bølge: tjek den rapporterede version, bekræft at routerboard-firmwaren også blev opgraderet hvor relevant (/system routerboard upgrade), og validér, at de tjenester, du bekymrer dig om, leder trafik igennem. Hvis en enhed opfører sig forkert, gendan den tidligere binære backup, eller genopbyg fra RSC-eksporten, eller geninstallér den tidligere version med Netinstall som sidste udvej. Et patch-program er ikke „færdigt”, når den nye version er installeret — det er færdigt, når hver enhed er verificeret sund og hver undtagelse er sporet til afslutning.
Tips til Patching i Flådeskala
- Standardisér en enkelt hærdet baseline, så opgraderinger er forudsigelige. Vores best practices for Winbox-sikkerhed og guide til device-mode-sikkerhedsops definerer den baseline, som de fleste opgraderingsproblemer kan spores tilbage til.
- Begræns administrationsadgang til et VPN eller betroede IP’er før og efter opgraderinger, så en halvt opdateret flåde aldrig er eksponeret.
- Hold administrationsplanet tilgængeligt selv bag CGNAT, så verifikation og rollback ikke kræver et besøg på stedet.
- Gennemgå MikroTiks sikkerhedsadvisories efter en plan i stedet for at vente på en hændelse.
FAQ
Hvor ofte bør jeg opdatere RouterOS? Vurdér hver udgivelse mod din grenpolitik, og patch uden for plan, når et advisory berører tjenester, du eksponerer. Der er intet fast interval — kun en kadence drevet af risiko.
Stable eller long-term for en ISP-flåde? Long-term er det sikrere standardvalg for edge og CPE; brug stable, hvor du har brug for nyere hardwareunderstøttelse eller funktioner, efter validering i staging.
Hvad hvis en opgradering bricker en fjernenhed? Gendan fra backup eller RSC-eksport; hvis enheden er uden for rækkevidde, redd den med Netinstall. Derfor er en testet backup og en tilgængelig administrationssti obligatoriske før enhver bølge.
Patch Hele Din Flåde Uden Udkald
Den sværeste del af flåde-patching er ikke opgraderingen — det er at nå og verificere hver enhed bagefter, især CPE bag CGNAT. MKController centraliserer synligheden på tværs af din MikroTik-flåde, og NATCloud giver dig tilgængelighed indefra og ud uden port forwarding, så faseinddelte udrulninger, verifikation og rollback alle sker eksternt.