MikroTik RouterOS atjaunināšanas gids

Kopsavilkums MikroTik RouterOS atjaunināšana visā ISP flotē ir kontrolēts process, nevis viena klikšķa darbība. Izvēlieties jūsu SLA atbilstošu laidiena kanālu, izveidojiet katras ierīces dublējumu, validējiet uz pilota, pēc tam ieviesiet topoloģijai atbilstošos viļņos ar skaidru atjaunošanas ceļu. 2026. gadā tas ir svarīgi kā nekad: publiski izmantojama RouterOS ievainojamība (CVE-2026-7668) un svaigs stable laidiens (7.23.1) nozīmē, ka nelaboti malas maršrutētāji ir aktīvs risks.

Kas Ir RouterOS Labošana ISP Flotei?

RouterOS labošana ir disciplinēts process, kurā MikroTik ierīču kopumu paceļ no vienas RouterOS versijas uz jaunāku, lai novērstu drošības ievainojamības, stabilitātes kļūdas un uzvedības regresijas — nebojājot uz tām strādājošos pakalpojumus. Uz vienas mājas maršrutētāja tas ir divu minūšu uzdevums. Pāri simtiem vai tūkstošiem CPE un malas maršrutētāju tas kļūst par operatīvu programmu: jums ir vajadzīga laidiena kanāla politika, dublēšanas standarts, staging solis, pakāpeniska ieviešana un atjaunošanas plāns. Mērķi ir viegli formulēt un grūti sasniegt lielā mērogā — katra ierīce paliek izlabota, un neviena no tām šī procesa laikā neizdziest.

Tas pelna īstu darbplūsmu, jo jauninājums skar to vienu lietu, ko neveiksmes gadījumā nav viegli atkal sasniegt: maršrutētāju klienta malā, bieži aiz CGNAT. Slikta ieviešana, kas pazaudē pārvaldības piekļuvi, kļūst par izbraukumu uz vietas. Tāpēc zemāk esošā darbplūsma vispirms optimizē drošību un sasniedzamību un tikai pēc tam ātrumu.

Kāpēc Labot Tagad: 2026. Gada Drošības Aina

Labošanas kadence paliek kluss fona uzdevums, līdz ievainojamība piespiež rīkoties, un 2026. gads sniedz konkrētus iemeslus to pastiprināt. CVE-2026-7668 ir robežu pārkāpšanas lasīšana RouterOS SCEP galapunktā ar novērtējumu CVSS 7.3 (augsts); to var iedarbināt attālināti, un pastāv publisks ekspluatācijas kods. Atsevišķi šī cikla paziņojumi attiecas uz nepietiekamas piekļuves kontroles problēmu VXLAN avota IP validācijā (izlabota RouterOS 7.20 un jaunākās) un atmiņas bojājuma ievainojamību SMB pakalpojumā, ko neautentificēts uzbrucējs var iedarbināt ar īpaši veidotām paketēm.

MikroTik vadlīnijas ir konsekventas: turiet RouterOS aktuālu un aiz ugunsmūra, kas bloķē neuzticamus tīklus. Pašreizējais stable zars, RouterOS 7.23.1 (izlaists 2026. gada 2. jūnijā), arī novērš BGP atmiņas noplūdi un DHCPv4-snooping stabilitātes problēmu. Tas ir parastais iemesls, kāpēc flotēm ir vajadzīgs atkārtojams labošanas process, nevis ad hoc jauninājumi.

1. Solis — Izvēlieties Pareizo Laidiena Kanālu

RouterOS piedāvā vairāk nekā vienu zaru, un izvēle ir politikas lēmums, nevis priekšroka. Stable laidieni iznāk ik pēc dažiem mēnešiem ar testētām funkcijām un labojumiem; long-term laidieni saņem tikai kritiskos un drošības labojumus, mainoties starp versijām daudz mazāk. ISP malas un CPE flotēm, kas novērtē paredzamību, long-term zars bieži ir pareizā noklusējuma izvēle, bet stable rezervēts aparatūrai vai funkcijām, kam tas nepieciešams. Lai ko jūs izvēlētos, nekad nedarbiniet testing vai development būvējumus ražošanā. Dokumentējiet zaru pēc ierīces klases, lai lēmums būtu atkārtojams visā komandā.

2. Solis — Vispirms Izveidojiet Dublējumu un Eksportu

Nekad nejauniniet bez atjaunošanas punkta. Izveidojiet gan bināru dublējumu (/system backup save), gan cilvēkam lasāmu konfigurācijas eksportu (/export file=), jo eksports pārdzīvo versiju maiņas un ļauj atjaunot pat tad, ja binārais dublējums neatjaunosies uz citu būvējumu. Novelciet abus no ierīces uz savu pārvaldības sistēmu. Pirms sākt pārbaudiet, vai jaunajām pakotnēm pietiek brīvas krātuves, un dodiet priekšroku vadu vai konsoles savienojumam — jaunināšana pa Wi-Fi vai nestabilu savienojumu ir veids, kā maršrutētāji tiek sabojāti rakstīšanas vidū. Ierīcēm, kur īstā raize ir atjaunošanas piekļuve, mūsu Netinstall atjaunošanas gids ir rezerves variants, kad jauninājums neizdodas.

3. Solis — Testējiet uz Pilotierīces

Vispirms atjauniniet vienu reprezentatīvu maršrutētāju un vērojiet to. Izvēlieties ierīci, kas atspoguļo ražošanas klasi — tas pats modelis, tā pati loma, līdzīga konfigurācija — un uzlieciet mērķa versiju apkopes loga laikā. Pēc pārstartēšanas pārbaudiet versiju, apstipriniet, ka pakotnes ir iespējotas, un izskatiet izmaiņu žurnālu attiecībā uz uzvedības izmaiņām, kas skar jūsu konfigurāciju (ugunsmūra semantika, noklusējuma pakalpojumi, saskarņu nosaukumi). Tikai tad, kad pilots ir tīrs, jūs autorizējat plašāku ieviešanu. Šis viens solis novērš visdārgāko kļūdas režīmu: regresijas atklāšanu jau pēc tam, kad tā piegādāta tūkstotim klientu.

4. Solis — Ieviesiet Topoloģijai Atbilstošos Viļņos

Masveida ieviešana ir par secību un tempu, nevis par pogas nospiešanu visur uzreiz. Grupējiet ierīces pēc topoloģijas, lai ķēdē savienoti maršrutētāji tiktu atjaunināti secīgi — jūs nevēlaties, lai augšupvērstais maršrutētājs pārstartētos, pirms lejupvērstā ierīce ir saņēmusi savas pakotnes. Definējiet viļņus ar to pašu apkopes logiem un izsekojiet katru ierīci saskaņošanas sarakstā, lai katra vienība ar problēmu tiktu atkārtoti ierindota, nevis aizmirsta. Lai samazinātu interneta joslas platumu, novirziet ierīces uz centrālo maršrutētāju, kas darbojas kā vietējais pakotņu spogulis; tas arī kontrolē, kuru versiju flote drīkst saņemt.

Pakāpeniska ieviešana darbojas tikai tad, ja jūs patiešām varat sasniegt katru ierīci, lai apstiprinātu, ka tā atgriezusies. Tas ir operatīvais āķis ar CPE aiz CGNAT — un tieši tur centralizēta pārvaldība atmaksājas.

5. Solis — Pārbaudiet, Tad Nepieciešamības Gadījumā Atjaunojiet

Pēc katra viļņa apstipriniet rezultātu: pārbaudiet ziņoto versiju, apstipriniet, ka routerboard programmaparatūra arī tika atjaunināta, kur tas attiecas (/system routerboard upgrade), un validējiet, ka jums svarīgie pakalpojumi laiž cauri trafiku. Ja ierīce darbojas nepareizi, atjaunojiet iepriekšējo bināro dublējumu, atjaunojiet no RSC eksporta vai kā pēdējo līdzekli pārinstalējiet iepriekšējo versiju ar Netinstall. Labošanas programma nav „pabeigta”, kad jaunā versija ir instalēta — tā ir pabeigta, kad katra ierīce ir pārbaudīta kā vesela un katrs izņēmums izsekots līdz noslēgumam.

Padomi Flotes Mēroga Labošanai

• Standartizējiet vienu nostiprinātu bāzes līniju, lai jauninājumi būtu paredzami. Mūsu Winbox drošības labākā prakse un ierīces režīma drošības operāciju gids definē bāzes līniju, uz kuru izsekojas vairums jauninājumu problēmu.
• Ierobežojiet pārvaldības piekļuvi līdz VPN vai uzticamiem IP pirms un pēc jauninājumiem, lai pusizlabota flote nekad nebūtu pakļauta.
• Saglabājiet pārvaldības plakni sasniedzamu pat aiz CGNAT, lai pārbaude un atjaunošana neprasītu apmeklējumu uz vietas.
• Izskatiet MikroTik drošības paziņojumus pēc grafika, nevis gaidiet incidentu.

BUJ

Cik bieži man vajadzētu atjaunināt RouterOS? Novērtējiet katru laidienu atbilstoši savai zara politikai un labojiet ārpus grafika ikreiz, kad paziņojums skar jūsu atvērtos pakalpojumus. Nav fiksēta intervāla — tikai riska vadīta kadence.

Stable vai long-term ISP flotei? Long-term ir drošāka noklusējuma izvēle malai un CPE; izmantojiet stable tur, kur nepieciešams jaunāks aparatūras atbalsts vai funkcijas, pēc validēšanas staging vidē.

Ko darīt, ja jauninājums sabojā attālu ierīci? Atjaunojiet no dublējuma vai RSC eksporta; ja ierīce nav sasniedzama, atgūstiet to ar Netinstall. Tieši tāpēc testēts dublējums un sasniedzams pārvaldības ceļš ir obligāti pirms katra viļņa.

Izlabojiet Visu Floti Bez Izbraukumiem uz Vietu

Grūtākā flotes labošanas daļa nav jauninājums — tā ir katras ierīces sasniegšana un pārbaude pēc tam, īpaši CPE aiz CGNAT. MKController centralizē redzamību visā jūsu MikroTik flotē, un NATCloud sniedz jums sasniedzamību no iekšpuses uz ārpusi bez portu pāradresēšanas, tāpēc pakāpeniskas ieviešanas, pārbaude un atjaunošana notiek attālināti.

Sāciet savu bezmaksas MKController izmēģinājumu