Tutorial
Guia d'actualització MikroTik RouterOS
Com actualitzar i pegar MikroTik RouterOS en una flota d'ISP: canals de versió, desplegament gradual, còpies, rollback i els CVE de 2026.
Resum Actualitzar MikroTik RouterOS en una flota d’ISP és un procés controlat, no una acció d’un sol clic. Trieu un canal de versió que s’adapti als vostres SLA, feu còpia de cada dispositiu, valideu en un pilot i després desplegueu en onades conscients de la topologia amb un camí de rollback clar. El 2026 això importa més que mai: una vulnerabilitat de RouterOS explotable públicament (CVE-2026-7668) i una nova versió estable (7.23.1) signifiquen que els routers de vora sense pegar són un risc actiu.
Què És el Pegat de RouterOS per a una Flota d’ISP?
El pegat de RouterOS és el procés disciplinat de portar una població de dispositius MikroTik d’una versió de RouterOS a una de més nova per corregir vulnerabilitats de seguretat, errors d’estabilitat i regressions de comportament — sense trencar els serveis que s’hi executen al damunt. En un únic router domèstic és una tasca de dos minuts. A través de centenars o milers de CPE i routers de vora, esdevé un programa operatiu: necessiteu una política de canal de versió, un estàndard de còpia, un pas de staging, un desplegament gradual i un pla de rollback. L’objectiu és fàcil d’enunciar i difícil d’aconseguir a escala — cada dispositiu acaba pegat, i cap no es queda sense connexió en el procés.
Mereix un flux de treball real perquè una actualització toca l’única cosa que no podeu tornar a abastar fàcilment si falla: un router a la vora del client, sovint darrere de CGNAT. Un enviament dolent que perd l’accés de gestió es converteix en una visita de camp. Per això el flux de treball següent optimitza primer per la seguretat i l’abast, i en segon lloc per la velocitat.
Per Què Pegar Ara: El Panorama de Seguretat de 2026
La cadència de pegat continua sent una tasca silenciosa de fons fins que una vulnerabilitat força la qüestió, i el 2026 dona raons concretes per estrènyer-la. CVE-2026-7668 és una lectura fora de límits a l’endpoint SCEP de RouterOS amb puntuació CVSS 7.3 (alta); es pot activar de manera remota i existeix un exploit públic. Avisos separats d’aquest cicle cobreixen un problema de control d’accés indegut en la validació de la IP d’origen de VXLAN (corregit a RouterOS 7.20 i posteriors) i una vulnerabilitat de corrupció de memòria al servei SMB que un atacant no autenticat pot desencadenar amb paquets manipulats.
L’orientació de MikroTik és coherent: mantingueu RouterOS al dia i darrere d’un tallafoc que bloquegi les xarxes no fiables. La branca estable actual, RouterOS 7.23.1 (publicada el 2 de juny de 2026), també corregeix una fuita de memòria de BGP i un problema d’estabilitat de DHCPv4-snooping. Aquesta és la raó ordinària per la qual les flotes necessiten un procés de pegat repetible en lloc d’actualitzacions ad hoc.
Pas 1 — Trieu el Canal de Versió Adequat
RouterOS ofereix més d’una branca, i la tria és una decisió de política, no una preferència. Les versions estables surten cada pocs mesos amb funcions i correccions provades; les versions de llarg termini només reben correccions crítiques i de seguretat, i canvien molt menys entre versions. Per a les flotes de vora i CPE d’ISP que valoren la previsibilitat, la branca de llarg termini sovint és l’opció per defecte adequada, reservant l’estable per a maquinari o funcions que ho requereixin. Trieu el que trieu, no executeu mai compilacions de prova o de desenvolupament en producció. Documenteu la branca per classe de dispositiu perquè la decisió sigui repetible per a tot l’equip.
Pas 2 — Primer Còpia i Exportació
No actualitzeu mai sense un punt de recuperació. Creeu tant una còpia binària (/system backup save) com una exportació de configuració llegible (/export file=), perquè l’exportació sobreviu als canvis de versió i permet reconstruir fins i tot si una còpia binària no es pot restaurar sobre una compilació diferent. Descarregueu-les totes dues del dispositiu al vostre sistema de gestió. Confirmeu que hi ha prou emmagatzematge lliure per als paquets nous abans de començar, i preferiu una connexió cablejada o de consola — actualitzar per Wi-Fi o per un enllaç inestable és com els routers acaben malmesos a mig escriure. Per als dispositius on l’accés de recuperació és la veritable preocupació, la nostra guia de recuperació amb Netinstall és l’opció alternativa quan una actualització surt malament.
Pas 3 — Proveu en un Dispositiu Pilot
Actualitzeu primer un router representatiu i vigileu-lo. Trieu un dispositiu que reflecteixi una classe de producció — mateix model, mateix rol, configuració similar — i apliqueu la versió objectiu durant una finestra de manteniment. Després de reiniciar-se, verifiqueu la versió, confirmeu que els paquets estan activats i reviseu el changelog per detectar canvis de comportament que afectin la vostra configuració (semàntica del tallafoc, serveis per defecte, nomenclatura d’interfícies). Només quan el pilot és net, autoritzeu el desplegament més ampli. Aquest únic pas evita el mode de fallada més car: descobrir una regressió després que ja s’hagi enviat a mil clients.
Pas 4 — Desplegueu en Onades Conscients de la Topologia
El desplegament massiu és qüestió d’ordre i ritme, no de prémer un botó a tot arreu alhora. Agrupeu els dispositius per topologia perquè els routers encadenats s’actualitzin en seqüència — no voleu que un router amunt es reiniciï abans que un dispositiu avall hagi obtingut els seus paquets. Definiu onades amb les seves pròpies finestres de manteniment i feu seguiment de cada dispositiu en una llista de conciliació perquè qualsevol unitat amb un problema es torni a posar en cua, no s’oblidi. Per reduir l’amplada de banda d’internet, apunteu els dispositius a un router central que actuï com a mirall local de paquets; això també controla quina versió pot obtenir la flota.
Un desplegament gradual només funciona si realment podeu abastar cada dispositiu per confirmar que ha tornat. Aquest és l’entrebanc operatiu amb CPE darrere de CGNAT — i on la gestió centralitzada demostra el seu valor.
Pas 5 — Verifiqueu i Després Feu Rollback si Cal
Després de cada onada, confirmeu el resultat: comproveu la versió reportada, confirmeu que el firmware de la routerboard també s’ha actualitzat quan escaigui (/system routerboard upgrade) i valideu que els serveis que us importen deixen passar trànsit. Si un dispositiu funciona malament, restaureu la còpia binària anterior, o reconstruïu des de l’exportació RSC, o reinstal·leu la versió anterior amb Netinstall com a últim recurs. Un programa de pegat no està «fet» quan la versió nova està instal·lada — està fet quan cada dispositiu està verificat com a sa i cada excepció està seguida fins al tancament.
Consells per al Pegat a Escala de Flota
- Estandarditzeu una única línia base reforçada perquè les actualitzacions siguin previsibles. Les nostres bones pràctiques de seguretat de Winbox i la guia d’operacions de seguretat de mode dispositiu defineixen la línia base a la qual es remunten la majoria dels problemes d’actualització.
- Restringiu l’accés de gestió a una VPN o IP de confiança abans i després de les actualitzacions, perquè una flota mig pegada mai no quedi exposada.
- Mantingueu el pla de gestió abastable fins i tot darrere de CGNAT, perquè la verificació i el rollback no requereixin una visita in situ.
- Reviseu els avisos de seguretat de MikroTik segons un calendari en lloc d’esperar un incident.
PMF
Amb quina freqüència he d’actualitzar RouterOS? Avalueu cada versió respecte a la vostra política de branca i pegueu fora de cicle sempre que un avís afecti serveis que exposeu. No hi ha cap interval fix — només una cadència impulsada pel risc.
Estable o llarg termini per a una flota d’ISP? El llarg termini és l’opció per defecte més segura per a vora i CPE; useu l’estable on necessiteu compatibilitat amb maquinari més nou o funcions, després de validar en staging.
Què passa si una actualització malmet un dispositiu remot? Restaureu des de la còpia o l’exportació RSC; si el dispositiu és inaccessible, recupereu-lo amb Netinstall. Per això una còpia provada i un camí de gestió abastable són obligatoris abans de qualsevol onada.
Pegueu Tota la Vostra Flota Sense les Visites de Camp
La part més difícil del pegat de flota no és l’actualització — és abastar i verificar cada dispositiu després, especialment CPE darrere de CGNAT. MKController centralitza la visibilitat sobre la vostra flota MikroTik, i NATCloud us dona abast de dins cap a fora sense redirecció de ports, de manera que els desplegaments graduals, la verificació i el rollback es fan tots de manera remota.