Hướng dẫn cập nhật & vá MikroTik RouterOS

Tóm tắt Cập nhật MikroTik RouterOS trên toàn đội thiết bị ISP là một quy trình được kiểm soát, không phải thao tác một-cú-nhấp. Hãy chọn kênh phát hành phù hợp với các SLA của bạn, sao lưu từng thiết bị, xác thực trên một thiết bị thí điểm, rồi triển khai theo các đợt có nhận biết cấu trúc liên kết với một lộ trình khôi phục rõ ràng. Năm 2026, điều này quan trọng hơn bao giờ hết: một lỗ hổng RouterOS có thể khai thác công khai (CVE-2026-7668) và một bản phát hành stable mới (7.23.1) đồng nghĩa với việc các router biên chưa được vá là một rủi ro đang hiện hữu.

Vá RouterOS cho Một Đội Thiết Bị ISP Là Gì?

Vá RouterOS là quy trình có kỷ luật nhằm nâng một tập hợp thiết bị MikroTik từ một phiên bản RouterOS lên một phiên bản mới hơn để khắc phục các lỗ hổng bảo mật, lỗi ổn định và sự thoái lui hành vi — mà không làm hỏng các dịch vụ đang chạy trên đó. Trên một router gia đình đơn lẻ, đây là một việc làm hai phút. Trên hàng trăm hoặc hàng nghìn CPE và router biên, nó trở thành một chương trình vận hành: bạn cần một chính sách kênh phát hành, một tiêu chuẩn sao lưu, một bước staging, một quá trình triển khai theo đợt và một kế hoạch khôi phục. Mục tiêu thì dễ phát biểu nhưng khó đạt được ở quy mô lớn — mọi thiết bị đều được vá, và không thiết bị nào bị mất kết nối trong quá trình đó.

Nó xứng đáng có một quy trình thực thụ vì việc nâng cấp chạm đến đúng thứ mà bạn khó tiếp cận lại nếu nó thất bại: một router ở biên phía khách hàng, thường nằm sau CGNAT. Một lần đẩy lỗi làm mất quyền truy cập quản trị sẽ trở thành một chuyến đi hiện trường. Vì vậy, quy trình bên dưới ưu tiên trước hết cho an toàn và khả năng tiếp cận, sau đó mới đến tốc độ.

Tại Sao Vá Ngay Bây Giờ: Bức Tranh Bảo Mật 2026

Nhịp độ vá vẫn là một công việc nền lặng lẽ cho đến khi một lỗ hổng buộc phải hành động, và năm 2026 đưa ra những lý do cụ thể để siết chặt nó. CVE-2026-7668 là một lỗi đọc ngoài giới hạn (out-of-bounds read) trong điểm cuối SCEP của RouterOS, được chấm điểm CVSS 7.3 (Cao); nó có thể bị kích hoạt từ xa và đã có mã khai thác công khai. Các khuyến cáo riêng trong chu kỳ này bao gồm một vấn đề kiểm soát truy cập không phù hợp trong xác thực source-IP của VXLAN (đã sửa trong RouterOS 7.20 trở lên) và một lỗ hổng hỏng bộ nhớ trong dịch vụ SMB mà một kẻ tấn công chưa xác thực có thể kích hoạt bằng các gói tin được tạo đặc biệt.

Hướng dẫn của MikroTik luôn nhất quán: giữ cho RouterOS được cập nhật và nằm sau một tường lửa chặn các mạng không tin cậy. Nhánh stable hiện tại, RouterOS 7.23.1 (phát hành ngày 2 tháng 6 năm 2026), cũng khắc phục một lỗi rò rỉ bộ nhớ BGP và một vấn đề ổn định của DHCPv4-snooping. Đây là lý do thông thường khiến các đội thiết bị cần một quy trình vá có thể lặp lại thay vì nâng cấp tùy hứng.

Bước 1 — Chọn Đúng Kênh Phát Hành

RouterOS cung cấp nhiều hơn một nhánh, và việc lựa chọn là một quyết định chính sách, không phải sở thích. Các bản phát hành stable ra mắt vài tháng một lần với các tính năng và bản sửa lỗi đã được kiểm thử; các bản phát hành long-term chỉ nhận các bản sửa lỗi quan trọng và bảo mật, thay đổi ít hơn nhiều giữa các phiên bản. Với các đội thiết bị biên và CPE của ISP vốn coi trọng tính dự đoán được, nhánh long-term thường là lựa chọn mặc định đúng đắn, còn stable được dành cho phần cứng hoặc tính năng đòi hỏi nó. Dù bạn chọn gì: tuyệt đối không chạy các bản testing hoặc development trên sản xuất. Ghi lại nhánh theo từng lớp thiết bị để quyết định có thể lặp lại trong cả nhóm.

Bước 2 — Sao Lưu và Xuất Cấu Hình Trước

Đừng bao giờ nâng cấp khi chưa có điểm khôi phục. Hãy tạo cả một bản sao lưu nhị phân (/system backup save) và một bản xuất cấu hình dễ đọc cho con người (/export file=), vì bản xuất tồn tại qua các lần đổi phiên bản và cho phép bạn dựng lại ngay cả khi một bản sao lưu nhị phân không thể khôi phục lên một bản build khác. Hãy kéo cả hai khỏi thiết bị về hệ thống quản lý của bạn. Xác nhận còn đủ dung lượng lưu trữ trống cho các gói mới trước khi bắt đầu, và ưu tiên kết nối có dây hoặc qua console — nâng cấp qua Wi-Fi hoặc một liên kết chập chờn là cách khiến router bị hỏng (bricked) ngay giữa lúc ghi. Với những thiết bị mà quyền truy cập khôi phục mới là mối lo thực sự, hướng dẫn khôi phục bằng Netinstall của chúng tôi là phương án dự phòng khi một bản nâng cấp gặp trục trặc.

Bước 3 — Kiểm Thử Trên Một Thiết Bị Thí Điểm

Hãy nâng cấp một router đại diện trước và theo dõi nó. Chọn một thiết bị phản ánh một lớp sản xuất — cùng kiểu máy, cùng vai trò, cấu hình tương tự — và áp dụng phiên bản mục tiêu trong một cửa sổ bảo trì. Sau khi nó khởi động lại, hãy xác minh phiên bản, xác nhận các gói đã được bật, và xem lại changelog để tìm các thay đổi hành vi ảnh hưởng đến cấu hình của bạn (ngữ nghĩa tường lửa, dịch vụ mặc định, cách đặt tên giao diện). Chỉ khi thiết bị thí điểm sạch sẽ, bạn mới cho phép triển khai rộng hơn. Riêng bước này ngăn chặn kiểu thất bại tốn kém nhất: phát hiện một sự thoái lui sau khi nó đã được đẩy đến cả nghìn khách hàng.

Bước 4 — Triển Khai Theo Đợt Có Nhận Biết Cấu Trúc Liên Kết

Triển khai hàng loạt là về thứ tự và nhịp độ, không phải bấm một nút ở mọi nơi cùng lúc. Hãy nhóm các thiết bị theo cấu trúc liên kết để các router nối chuỗi được cập nhật theo trình tự — bạn không muốn một router thượng nguồn khởi động lại trước khi một thiết bị hạ nguồn kịp tải các gói của nó. Hãy định nghĩa các đợt với cửa sổ bảo trì riêng, và theo dõi từng thiết bị trong một danh sách đối soát để bất kỳ đơn vị nào gặp sự cố đều được xếp lại hàng đợi, không bị bỏ quên. Để giảm băng thông internet, hãy trỏ các thiết bị đến một router trung tâm đóng vai trò package mirror cục bộ; điều này cũng kiểm soát phiên bản mà đội thiết bị được phép tải về.

Một quá trình triển khai theo đợt chỉ hiệu quả nếu bạn thực sự có thể tiếp cận từng thiết bị để xác nhận nó đã trở lại. Đó chính là điểm vướng vận hành với CPE nằm sau CGNAT — và là nơi quản lý tập trung phát huy giá trị.

Bước 5 — Xác Minh, Rồi Khôi Phục Nếu Cần

Sau mỗi đợt, hãy xác nhận kết quả: kiểm tra phiên bản được báo cáo, xác nhận firmware routerboard cũng đã được nâng cấp ở những nơi áp dụng (/system routerboard upgrade), và xác thực rằng các dịch vụ bạn quan tâm vẫn truyền được lưu lượng. Nếu một thiết bị hoạt động sai, hãy khôi phục bản sao lưu nhị phân trước đó, hoặc dựng lại từ bản xuất RSC, hoặc cài lại phiên bản cũ bằng Netinstall như phương án cuối cùng. Một chương trình vá chưa “hoàn tất” khi phiên bản mới được cài đặt — nó hoàn tất khi mọi thiết bị được xác minh là khỏe mạnh và mọi ngoại lệ được theo dõi đến khi khép lại.

Mẹo cho Việc Vá Ở Quy Mô Đội Thiết Bị

• Chuẩn hóa một đường cơ sở (baseline) đã được tăng cường bảo mật duy nhất để việc nâng cấp trở nên dự đoán được. Các phương pháp hay nhất về bảo mật Winbox và hướng dẫn vận hành bảo mật device-mode của chúng tôi định nghĩa đường cơ sở mà phần lớn sự cố nâng cấp đều bắt nguồn từ đó.
• Hạn chế quyền truy cập quản trị vào một VPN hoặc các IP tin cậy trước và sau khi nâng cấp, để một đội thiết bị đã vá một nửa không bao giờ bị phơi bày.
• Giữ cho mặt phẳng quản trị có thể tiếp cận được ngay cả khi nằm sau CGNAT, để việc xác minh và khôi phục không cần đến tận nơi.
• Xem xét các khuyến cáo bảo mật của MikroTik theo lịch trình thay vì chờ đến khi xảy ra sự cố.

Câu Hỏi Thường Gặp

Tôi nên cập nhật RouterOS bao lâu một lần? Đánh giá từng bản phát hành theo chính sách nhánh của bạn, và vá đột xuất bất cứ khi nào một khuyến cáo ảnh hưởng đến các dịch vụ bạn phơi bày ra ngoài. Không có khoảng thời gian cố định — chỉ có một nhịp độ được dẫn dắt bởi rủi ro.

Stable hay long-term cho một đội thiết bị ISP? Long-term là lựa chọn mặc định an toàn hơn cho biên và CPE; dùng stable ở những nơi bạn cần hỗ trợ phần cứng hoặc tính năng mới hơn, sau khi đã xác thực trong staging.

Nếu một bản nâng cấp làm hỏng (brick) một thiết bị ở xa thì sao? Khôi phục từ bản sao lưu hoặc bản xuất RSC; nếu thiết bị không thể tiếp cận, hãy phục hồi bằng Netinstall. Đây là lý do một bản sao lưu đã kiểm thử và một đường quản trị có thể tiếp cận là bắt buộc trước mỗi đợt.

Vá Toàn Bộ Đội Thiết Bị của Bạn Mà Không Cần Đi Hiện Trường

Phần khó nhất của việc vá cả đội thiết bị không phải là việc nâng cấp — mà là tiếp cận và xác minh từng thiết bị sau đó, đặc biệt với CPE nằm sau CGNAT. MKController tập trung hóa khả năng quan sát trên toàn đội thiết bị MikroTik của bạn, và NATCloud mang lại khả năng tiếp cận từ trong ra ngoài mà không cần chuyển tiếp cổng, để các đợt triển khai, việc xác minh và khôi phục đều diễn ra từ xa.

Bắt đầu dùng thử MKController miễn phí