Tutorial
Централізований WiFi на MikroTik CAPsMAN
Налаштуйте MikroTik CAPsMAN на RouterOS 7 для централізованого керування точками WiFi: правила provisioning, профілі конфігурації та контроль локацій.
Коротко MikroTik CAPsMAN перетворює один пристрій RouterOS на бездротовий контролер, який налаштовує кожну точку доступу з єдиного місця. Замість того щоб заходити в кожну точку доступу, аби змінити SSID чи пароль, ви редагуєте один профіль — і CAPsMAN розсилає його всьому парку. У RouterOS 7 контролер вбудований у пакет wifi — жодних доповнень не потрібно. Цей посібник проходить весь ланцюжок: увімкнути менеджер, зареєструвати точки доступу як CAP, побудувати правила provisioning, захистити керуючий канал і масштабувати цю схему на всі локації.
Що таке MikroTik CAPsMAN?
MikroTik CAPsMAN — це вбудований у RouterOS бездротовий контролер: Controlled Access Point system Manager, який зберігає конфігурацію для групи точок доступу та автоматично налаштовує кожну з них при підключенні (Документація MikroTik — AP Controller (CAPsMAN)). Мережа поділяється на дві ролі — менеджер (CAPsMAN), який зберігає SSID, налаштування безпеки та каналів, і будь-яку кількість CAP, тобто точок доступу, що забезпечують власне радіопокриття й передають свою конфігурацію менеджеру.
Виграш — єдине джерело правди для WiFi: змініть гостьовий пароль один раз, і кожен CAP успадкує його; додайте точку доступу — і вона налаштує себе за правилами, які ви вже написали. Будь-який пристрій із ліцензією Level 4 чи вище може виконувати роль CAP (Документація MikroTik — WiFi).
Крок 1 — Увімкніть менеджер CAPsMAN
Виберіть пристрій, який виконуватиме роль контролера — часто це головний роутер, хоча ним може бути будь-який пристрій RouterOS 7 із пакетом wifi. Переконайтеся, що пакет присутній у /system/package, а потім увімкніть менеджер командою /interface/wifi/capsman/set enabled=yes. Задайте package-path і upgrade-policy, якщо хочете, щоб CAP підтягували відповідні пакети wifi з контролера й тримали прошивку узгодженою (Документація MikroTik — AP Controller (CAPsMAN)).
Тепер контролер слухає CAP, але ще нічим не керує — це прийде з правилами на Кроці 3. Зверніть увагу на інтерфейс, який слухає менеджер: за замовчуванням CAP виявляють його по Layer 2, тож під час реєстрації контролер і точки доступу мають бути в одному широкомовному домені або зведені до нього через bridge.
Крок 2 — Перетворіть точки доступу на CAP
На кожній точці доступу передайте її радіомодулі контролеру. Увімкніть режим CAP командою /interface/wifi/cap/set enabled=yes, перелічіть інтерфейси, які точка доступу має надати, за допомогою slaves-datapath і discovery-interfaces, і задайте caps-man-addresses, якщо ви вказуєте на контролер за IP, а не покладаєтеся на виявлення по Layer 2 (Документація MikroTik — WiFi). Щойно CAP знаходить менеджер, його локальна конфігурація радіо замінюється тим, що надає CAPsMAN.
Тут важливе залізо: CAP настільки хороший, наскільки хороший його радіомодуль. Точки доступу Wi-Fi 6 і Wi-Fi 7, як-от MikroTik hAP be lite, стають чудовими CAP, бо CAPsMAN може централізовано керувати їхніми новішими радіомодулями, а налаштування діапазону й каналу, яке зазвичай робиться на кожному пристрої окремо — на кшталт описаного в нашому посібнику з налаштування WiFi 6 на роутерах MikroTik AX — перетворюється на профіль, який ви пишете один раз.
Крок 3 — Створіть конфігурації та правила provisioning
Саме тут CAPsMAN виправдовує своє місце. Профіль configuration визначає SSID, безпеку (authentication-types, парольну фразу), країну та план каналів; datapath вирішує, як трафік CAP потрапляє в мережу — через bridge локально на точці доступу чи тунелем назад на контролер. Правила provisioning далі зіставляють CAP, що підключаються — за MAC радіо, моделлю чи ідентичністю — і застосовують потрібну конфігурацію автоматично (Документація MikroTik — AP Controller (CAPsMAN)). Напишіть /interface/wifi/provisioning add action=create-dynamic-enabled ..., щоб нові точки доступу налаштовувалися самі, а не чекали на вас.
Оскільки трафік CAP зазвичай потрапляє на bridge, цей крок передбачає, що ваш Layer 2 чистий; якщо bridge для вас новина, наш посібник з налаштування bridge на MikroTik охоплює основи. І ось чесне обмеження CAPsMAN: він централізує WiFi у межах досяжності одного контролера. Самі контролери — по одному на будівлю, на філію, на вишку — усе одно лишаються окремими роутерами, які треба тримати синхронізованими. Саме цей другий рівень бере на себе керування конфігурацією парку в MKController: розішліть ідентичний профіль CAPsMAN на всі контролери одразу та скористайтеся Історією дій, щоб бачити, хто що змінив, коли й на якому майданчику стався дрейф.
Крок 4 — Виділіть керуючий VLAN і захистіть доступ
Ставтеся до керуючого каналу CAPsMAN як до інфраструктури, а не як до чогось другорядного. Ведіть трафік від CAP до менеджера окремим керуючим VLAN, повністю тримайте його поза гостьовими та клієнтськими SSID і обмежте, на яких інтерфейсах менеджер прийматиме CAP. Керуючий VLAN також не дасть балакучій клієнтській мережі бодай торкнутися площини, що керує вашими радіомодулями (Спільнота MikroTik — CAPsMAN with management VLAN).
Централізоване керування має два боки: одне неправильне правило provisioning ламає не одну точку доступу, а всі одразу. Перш ніж розсилати зміну каналу чи безпеки на весь парк, вам потрібен бекап, до якого можна відкотитися — і спосіб зайти, якщо зміна заблокує доступ. MKController зберігає щоденні автоматичні бінарні бекапи кожного пристрою — останні п’ять версій, у хмарі — і дозволяє зняти ручний бекап просто перед ризикованим push, тож помилковий push CAPsMAN стає відновленням в один клік до останнього справного стану замість поїздки на майданчик із консольним кабелем.
Крок 5 — Розгорніть CAPsMAN в усіх локаціях
Один контролер і жменька CAP — справа на вечір. Справжня робота — це десятий об’єкт — готельний корпус, друга вишка, кампус клієнта — кожен зі своїм контролером за LTE чи Starlink і Carrier-Grade NAT, без публічного IP, куди можна подзвонити, коли точка доступу замовкає. Ось та стіна, про яку ніколи не згадують посібники про один майданчик.
Це і є справжня задача читача, і саме тут площина керування важить найбільше. MKController тримає кожен контролер доступним через захищений вихідний тунель — без прокидання портів, без публічної адреси, як докладно описано в нашому посібнику з віддаленого керування MikroTik за CGNAT (NATCloud) — розсилає ідентичні профілі CAPsMAN по всьому парку й відстежує доступність пристроїв кожної локації, тож упала точка доступу з’являється — а з оповіщеннями Telegram і доходить до вас — раніше, ніж подзвонять із рецепції. WISP та оператори кількох майданчиків на MikroTik WiFi використовують це, щоб двадцять точок відчувалися як одна панель.
Поради
- Тримайте контролер і CAP на одній версії пакета wifi RouterOS 7; розбіжності змушують CAP відпадати й переналаштовуватися по колу.
- Починайте з provisioning
create-dynamic-enabled, щоб нові точки доступу виходили в мережу вже налаштованими, а потім затягуйте правила до рівня окремих моделей у міру зростання парку. - Використовуйте datapath з локальним bridge для навантажених майданчиків, щоб клієнтські дані не робили гак через контролер.
- Іменуйте профілі SSID і безпеки за призначенням («guest», «staff»), а не за локацією, щоб один профіль однаково обслуговував кожен майданчик.
Керуйте WiFi, а не стійкою роутерів
CAPsMAN розв’язує один парк точок доступу з одного контролера. Бізнес розв’язує кожен контролер з одного місця. MKController і є тією площиною керування: розсилання конфігурації на весь парк, аудит та історія конфігурацій, автоматичні бекапи й безпечний вихідний доступ до майданчиків за CGNAT без публічного IP чи прокидання портів, плюс моніторинг доступності й оповіщення Telegram, що виявляють упалий CAP раніше, ніж гість помітить зникнення WiFi. Оператори, що керують MikroTik на багатьох майданчиках, використовують це, щоб тримати кожну локацію в курсі без поїздок.