MikroTik CAPsMAN централно WiFi управление

Обобщение MikroTik CAPsMAN превръща едно RouterOS устройство в безжичен контролер, който конфигурира всяка точка за достъп от едно място. Вместо да влизате във всеки AP, за да смените SSID или парола, редактирате един профил и CAPsMAN го разпространява до целия флот. В RouterOS 7 контролерът е вграден в пакета wifi — без нужда от добавка. Това ръководство разглежда цялата верига: включете мениджъра, регистрирайте вашите AP като CAP, изградете правила за разгръщане, обезопасете контролния канал и мащабирайте модела на много обекти.

Какво е MikroTik CAPsMAN?

MikroTik CAPsMAN е вграденият безжичен контролер на RouterOS: Controlled Access Point system Manager, който съхранява конфигурацията за група точки за достъп и разгръща всяка от тях автоматично при свързване (MikroTik Documentation — AP Controller (CAPsMAN)). Мрежата се разделя на две роли — мениджърът (CAPsMAN), който съхранява SSID, настройки за сигурност и канали, и произволен брой CAP — точките за достъп, които осигуряват реалното радиопокритие и предават конфигурацията си нагоре към мениджъра.

Ползата е единен източник на истина за WiFi: сменяте паролата за гости веднъж и всеки CAP я наследява; добавяте AP и той се разгръща сам според правилата, които вече сте написали. Всяко устройство с лиценз Level 4 или по-висок може да работи като CAP (MikroTik Documentation — WiFi).

Стъпка 1 — Включете CAPsMAN мениджъра

Изберете устройството, което ще бъде контролер — често основният рутер, макар че всяко RouterOS 7 устройство с пакета wifi може да го хоства. Уверете се, че пакетът присъства под /system/package, след което включете мениджъра с /interface/wifi/capsman/set enabled=yes. Задайте package-path и upgrade-policy, ако искате CAP да изтеглят съответстващи wifi пакети от контролера, за да остане фърмуерът им подравнен (MikroTik Documentation — AP Controller (CAPsMAN)).

Контролерът вече слуша за CAP, но все още не управлява нищо — това идва от правилата в Стъпка 3. Обърнете внимание на интерфейса, на който слуша мениджърът: по подразбиране CAP го откриват през Layer 2, така че контролерът и точките за достъп трябва да споделят един широковещателен домейн по време на регистрацията или да са мостово свързани към такъв.

Стъпка 2 — Превърнете точките за достъп в CAP

На всяка точка за достъп предайте радиата ѝ на контролера. Включете CAP режим с /interface/wifi/cap/set enabled=yes, избройте интерфейсите, които AP трябва да предложи, чрез slaves-datapath и discovery-interfaces, и задайте caps-man-addresses, ако насочвате към контролера по IP, вместо да разчитате на откриване през Layer 2 (MikroTik Documentation — WiFi). Щом CAP открие мениджъра, локалната му радиоконфигурация се заменя с това, което CAPsMAN разгръща.

Хардуерът има значение тук: един CAP е толкова добър, колкото радиото му. Wi-Fi 6 и Wi-Fi 7 точки за достъп като MikroTik hAP be lite стават отлични CAP, защото CAPsMAN може да управлява по-новите им радиа централизирано, а настройката на честотния диапазон и каналите, която обикновено бихте правили за всяко устройство поотделно — от вида, разгледан в нашето ръководство за конфигуриране на WiFi 6 на MikroTik AX рутери — се превръща в профил, който пишете веднъж.

Стъпка 3 — Изградете конфигурации и правила за разгръщане

Тук CAPsMAN оправдава мястото си. Профилът за конфигурация определя SSID, сигурността (authentication-types, парола), държавата и плана за канали; datapath решава как трафикът на CAP достига до мрежата — мостово локално при AP или тунелиран обратно към контролера. Правилата за разгръщане след това съпоставят свързващите се CAP — по MAC на радиото, модел или идентичност — и прилагат правилната конфигурация автоматично (MikroTik Documentation — AP Controller (CAPsMAN)). Напишете /interface/wifi/provisioning add action=create-dynamic-enabled ..., за да се самоконфигурират новите AP, вместо да чакат вас.

Тъй като трафикът на CAP обикновено попада на мост, тази стъпка предполага, че вашият Layer 2 е чист; ако мостовете са ви нови, нашето ръководство за конфигуриране на мост в MikroTik покрива основите. И ето честното ограничение на CAPsMAN: той централизира WiFi в обхвата на един контролер. Самите контролери — по един на сграда, на клон, на кула — все още са отделни рутери, които трябва да поддържате синхронизирани. Точно този втори слой обслужва управлението на конфигурацията на флота на MKController: разпространете идентичен CAPsMAN профил до всеки контролер наведнъж и използвайте История на действията, за да видите кой какво е променил, кога и кой обект се е отклонил.

Стъпка 4 — Отделете управленски VLAN и обезопасете достъпа

Отнасяйте се към контролния канал на CAPsMAN като към инфраструктура, а не като към нещо второстепенно. Пренасяйте трафика между CAP и мениджъра през отделен управленски VLAN, дръжте го изцяло извън гостовите и клиентските SSID и ограничете на кои интерфейси мениджърът ще приема CAP. Управленският VLAN също така предотвратява всякакъв допир на приказлива клиентска мрежа до равнината, която управлява радиата ви (MikroTik community — CAPsMAN with management VLAN).

Централизираният контрол е нож с две остриета: едно грешно правило за разгръщане не поврежда един AP, а поврежда всички наведнъж. Преди да разпространите промяна на канал или сигурност из целия флот, искате резервно копие, към което да се върнете — и начин за достъп, ако промяната ви заключи навън. MKController пази ежедневни автоматични двоични резервни копия на всяко устройство — последните пет версии, в облака — и ви позволява да направите ръчно точно преди рискова промяна, така че една лоша CAPsMAN промяна се превръща във възстановяване с един клик до последното известно добро състояние, вместо в пътуване до обекта с конзолен кабел.

Стъпка 5 — Разгърнете CAPsMAN на всички обекти

Един контролер и шепа CAP са работа за един следобед. Истинската задача е десетият обект — крило на хотел, втора кула, клиентски кампус — всеки със собствен контролер зад LTE или Starlink и Carrier-Grade NAT, без публичен IP адрес, на който да се свържете, когато някой AP замлъкне. Това е стената, която уроците за един обект никога не споменават.

Това е истинската задача на читателя и мястото, където контролната равнина има най-голямо значение. MKController поддържа всеки контролер достъпен през сигурен изходящ тунел — без пренасочване на портове, без публичен адрес, както е описано подробно в нашето ръководство за отдалечено управление на MikroTik зад CGNAT (NATCloud) — разпространява идентични CAPsMAN профили из целия флот и следи наличността на устройствата на всеки обект, така че паднал CAP се появява — и, с Telegram известия, достига до вас — преди рецепцията да се обади. WISP и оператори на много обекти с MikroTik WiFi го използват, за да накарат двадесет обекта да изглеждат като едно табло.

Съвети

• Дръжте контролера и CAP на една и съща версия на wifi пакета на RouterOS 7; несъответствията карат CAP да отпадат и да се преразгръщат в цикли.
• Започнете с разгръщане create-dynamic-enabled, за да идват новите AP онлайн вече конфигурирани, след което затегнете до правила по модел, докато флотът расте.
• Използвайте datapath с локално мостване за обекти с висок трафик, за да не минават клиентските данни през контролера в обратна дъга.
• Именувайте профилите за SSID и сигурност по предназначение („guest“, „staff“), а не по местоположение, така че един профил да обслужва всеки обект еднакво.

Управлявайте WiFi, а не шкаф с рутери

CAPsMAN решава един флот от AP от един контролер. Един бизнес решава всеки контролер от едно място. MKController е точно тази контролна равнина: разпространение на конфигурация за целия флот, одит и история на конфигурациите, автоматични резервни копия и сигурен изходящ достъп до обекти зад CGNAT без публичен IP или пренасочване на портове, плюс наблюдение на наличността и Telegram известия, които извеждат паднал CAP, преди гост да забележи, че WiFi е спрял. Оператори с MikroTik на много обекти го използват, за да държат всяка локация на една вълна, без да пътуват.

Активирайте безплатния си пробен период на MKController