Tutorial
Thiết Lập WiFi Tập Trung MikroTik CAPsMAN
Thiết lập MikroTik CAPsMAN trên RouterOS 7 để quản lý tập trung nhiều access point WiFi: quy tắc provisioning, config profile và điều khiển đa điểm.
Tóm tắt MikroTik CAPsMAN biến một thiết bị RouterOS thành một wireless controller cấu hình mọi access point từ một nơi duy nhất. Thay vì đăng nhập vào từng AP để đổi SSID hay mật khẩu, bạn chỉnh sửa một profile và CAPsMAN đẩy nó tới toàn bộ hệ thống. Trên RouterOS 7, controller được tích hợp sẵn trong gói wifi — không cần add-on nào. Hướng dẫn này đi qua trọn chuỗi công việc: bật trình quản lý, đăng ký các AP thành CAP, xây dựng quy tắc provisioning, bảo mật kênh điều khiển, và mở rộng mô hình ra nhiều địa điểm.
MikroTik CAPsMAN Là Gì?
MikroTik CAPsMAN là wireless controller tích hợp sẵn của RouterOS: một Controlled Access Point system Manager giữ cấu hình cho cả một nhóm access point và tự động provision từng thiết bị khi nó kết nối (Tài liệu MikroTik — AP Controller (CAPsMAN)). Mạng lưới được chia thành hai vai trò — manager (CAPsMAN), nơi lưu SSID, bảo mật và thiết lập channel, và bất kỳ số lượng CAP nào, tức các access point cung cấp vùng phủ sóng radio thực tế và giao cấu hình của chúng lên cho manager.
Điểm hấp dẫn là một nguồn sự thật duy nhất cho WiFi: đổi mật khẩu khách một lần và mọi CAP đều kế thừa; thêm một AP và nó tự provision theo các quy tắc bạn đã viết sẵn. Bất kỳ thiết bị nào có license Level 4 trở lên đều có thể đóng vai một CAP (Tài liệu MikroTik — WiFi).
Bước 1 — Bật trình quản lý CAPsMAN
Chọn thiết bị sẽ đóng vai controller — thường là router chính, dù bất kỳ thiết bị RouterOS 7 nào có gói wifi đều có thể đảm nhận. Xác nhận gói này hiện diện dưới /system/package, rồi bật trình quản lý bằng /interface/wifi/capsman/set enabled=yes. Đặt package-path và upgrade-policy nếu bạn muốn các CAP kéo gói wifi tương ứng từ controller để firmware của chúng luôn đồng bộ (Tài liệu MikroTik — AP Controller (CAPsMAN)).
Giờ controller đã lắng nghe các CAP nhưng chưa quản lý gì cả — điều đó đến từ các quy tắc ở Bước 3. Lưu ý interface mà trình quản lý lắng nghe: các CAP mặc định phát hiện nó qua Layer 2, nên controller và các AP nên chung một broadcast domain trong lúc đăng ký, hoặc được bridge hướng về một domain như vậy.
Bước 2 — Biến access point của bạn thành CAP
Trên mỗi access point, giao radio của nó cho controller. Bật chế độ CAP bằng /interface/wifi/cap/set enabled=yes, liệt kê các interface mà AP nên cung cấp qua slaves-datapath và discovery-interfaces, và đặt caps-man-addresses nếu bạn trỏ tới controller bằng IP thay vì dựa vào phát hiện Layer 2 (Tài liệu MikroTik — WiFi). Một khi CAP tìm thấy trình quản lý, cấu hình radio cục bộ của nó được thay thế bằng bất cứ thứ gì CAPsMAN provision.
Phần cứng có vai trò quan trọng ở đây: một CAP chỉ tốt ngang với radio của nó. Các AP Wi-Fi 6 và Wi-Fi 7 như MikroTik hAP be lite là những CAP tuyệt vời vì CAPsMAN có thể điều khiển các radio mới hơn của chúng một cách tập trung, và việc tinh chỉnh band cùng channel mà bình thường bạn phải làm trên từng thiết bị — kiểu công việc được trình bày trong hướng dẫn cấu hình WiFi 6 trên router MikroTik AX của chúng tôi — trở thành một profile bạn chỉ viết một lần.
Bước 3 — Xây dựng cấu hình và quy tắc provisioning
Đây chính là nơi CAPsMAN chứng minh giá trị của mình. Một configuration profile định nghĩa SSID, bảo mật (authentication-types, passphrase), quốc gia và kế hoạch channel; một datapath quyết định lưu lượng CAP đến mạng bằng cách nào — bridge cục bộ tại AP hay tunnel ngược về controller. Các quy tắc provisioning sau đó khớp các CAP đang kết nối — theo MAC của radio, model, hay identity — và tự động áp dụng đúng cấu hình (Tài liệu MikroTik — AP Controller (CAPsMAN)). Viết /interface/wifi/provisioning add action=create-dynamic-enabled ... để các AP mới tự cấu hình thay vì chờ bạn.
Vì lưu lượng CAP thường đổ về một bridge, bước này giả định Layer 2 của bạn đã sạch sẽ; nếu bridge còn mới mẻ với bạn, hướng dẫn cấu hình bridge MikroTik của chúng tôi trình bày phần nền tảng. Và đây là giới hạn thành thật của CAPsMAN: nó tập trung hóa WiFi trong tầm với của một controller. Bản thân các controller — mỗi tòa nhà, mỗi chi nhánh, mỗi trạm phát một cái — vẫn là những router riêng biệt mà bạn phải giữ đồng bộ. Lớp thứ hai đó chính là thứ mà tính năng quản lý cấu hình hàng loạt của MKController xử lý: đẩy một CAPsMAN profile đồng nhất tới mọi controller cùng lúc, và dùng Lịch sử thao tác để xem ai đã đổi cái gì, khi nào, và site nào đã trôi lệch.
Bước 4 — Tách riêng VLAN quản lý và bảo mật truy cập
Hãy đối xử với kênh điều khiển CAPsMAN như một hạ tầng, không phải một thứ nghĩ đến sau cùng. Truyền lưu lượng CAP-tới-manager trên một VLAN quản lý riêng, giữ nó hoàn toàn tách khỏi các SSID khách và client, và hạn chế những interface mà trình quản lý sẽ chấp nhận CAP. Một VLAN quản lý cũng ngăn một mạng client ồn ào chạm được vào lớp điều khiển các radio của bạn (Cộng đồng MikroTik — CAPsMAN với VLAN quản lý).
Kiểm soát tập trung là con dao hai lưỡi: một quy tắc provisioning sai không làm hỏng một AP, nó làm hỏng tất cả cùng một lúc. Trước khi bạn đẩy một thay đổi về channel hay bảo mật ra toàn hệ thống, bạn cần một bản sao lưu để có thể khôi phục — và một lối vào nếu thay đổi đó khóa bạn ra ngoài. MKController giữ sao lưu binary tự động hàng ngày cho mọi thiết bị — năm phiên bản gần nhất, trên đám mây — và cho phép bạn tạo một bản thủ công ngay trước một lần đẩy nhiều rủi ro, nên một lần đẩy CAPsMAN sai trở thành một cú khôi phục một-click về trạng thái tốt gần nhất thay vì một chuyến lái xe tới hiện trường với cáp console.
Bước 5 — Triển khai CAPsMAN trên mọi địa điểm
Một controller và một nắm CAP là công việc của một buổi chiều. Việc thực sự khó là địa điểm thứ mười — một khu phụ của khách sạn, một trạm phát thứ hai, một khuôn viên khách hàng — mỗi nơi có controller riêng nằm sau LTE hoặc Starlink và Carrier-Grade NAT, không có IP công khai để kết nối vào khi một AP im tiếng. Đó là bức tường mà các hướng dẫn một-site không bao giờ nhắc đến.
Đây mới là công việc thực sự cần hoàn thành của người đọc, và là nơi control plane quan trọng nhất. MKController giữ cho mọi controller luôn truy cập được qua một tunnel outbound an toàn — không port forwarding, không địa chỉ công khai, như đã trình bày chi tiết trong hướng dẫn quản lý từ xa MikroTik sau CGNAT (NATCloud) của chúng tôi — đẩy các CAPsMAN profile đồng nhất ra toàn hệ thống, và theo dõi tình trạng khả dụng của thiết bị tại từng site, nên một CAP bị chết sẽ hiện ra — và, với cảnh báo Telegram, đến được với bạn — trước khi quầy lễ tân gọi điện. Các WISP và nhà vận hành đa điểm chạy WiFi MikroTik dùng nó để biến hai mươi site cảm giác như một bảng điều khiển duy nhất.
Mẹo
- Giữ controller và các CAP trên cùng một phiên bản gói wifi RouterOS 7; sai lệch khiến CAP rớt và tái provision liên tục thành vòng lặp.
- Bắt đầu với provisioning
create-dynamic-enabledđể các AP mới lên mạng đã có cấu hình, rồi siết dần thành quy tắc theo từng model khi hệ thống lớn lên. - Dùng datapath bridge cục bộ cho các site lưu lượng cao để dữ liệu client không phải vòng ngược qua controller.
- Đặt tên SSID và security profile theo mục đích (“guest”, “staff”) thay vì theo địa điểm, để một profile phục vụ mọi site như nhau.
Quản lý WiFi, không phải một tủ rack router
CAPsMAN giải quyết một đội AP từ một controller. Một doanh nghiệp giải quyết mọi controller từ một nơi. MKController chính là control plane đó: đẩy cấu hình ra toàn hệ thống, audit và lịch sử cấu hình, sao lưu tự động, và truy cập outbound an toàn tới các site sau CGNAT mà không cần IP công khai hay port forwarding, cùng với giám sát khả dụng và cảnh báo Telegram làm lộ ra một CAP bị chết trước khi khách kịp nhận ra WiFi đã rớt. Các nhà vận hành chạy MikroTik trên nhiều địa điểm dùng nó để giữ mọi vị trí trên cùng một trang mà không cần lái xe đi.