Бесшовный Wi-Fi, MikroTik RB951G-2HnD контроллер и точка доступа RBwAP2nD в роли CAP

Содержание

Я расскажу, как настроил бесшовный Wi-Fi в офисе на оборудовании MikroTik — роутер RB951G-2HnD в роли CAPsMAN-контроллера и точка доступа RBwAP2nD в роли CAP. Пользователи ходят по офису, а их устройства автоматически переключаются между точками без разрыва соединения.

Введение​

Когда мне поставили задачу организовать Wi-Fi в офисе на двух этажах, первое, о чём я подумал — как сделать так, чтобы сотрудники не замечали переключения между точками доступа. Постоянные разрывы во время созвонов и тормоза при переходе из кабинета в переговорку — это неприемлемо.

Решение нашлось в технологии CAPsMAN от MikroTik. Она позволяет управлять несколькими точками доступа с одного контроллера, задавая единый SSID и единые настройки. Пользователь подключается один раз и «не знает», что переходит между разными железками.

В этой статье я опишу весь путь — от начальной конфигурации роутера до финальной проверки роуминга. Статья охватывает два варианта разделения трафика плюс гостевую сеть с изоляцией.

Оборудование​

RB951G-2HnD — главный роутер, выступает как CAPsMAN-контроллер (и одновременно CAP, если нужно)


RBwAP2nD (wAP) — дополнительная точка доступа, управляемая контроллером (CAP)


Cisco SG110D-08HP — неуправляемый PoE-коммутатор между роутером и конечными устройствами


Кабель Ethernet для соединения устройств

Оба устройства MikroTik работают только в диапазоне 2,4 ГГц. Если нужен 5 ГГц — потребуются другие модели.

Адресация​

Почему /22 для пользователей​

Стандартная маска /24 даёт всего 254 адреса. Для офиса с запасом на рост это быстро становится тесно. Я использую /22 — четыре объединённых /24-подсети, дающие 1022 адреса для устройств.

Важное правило: /22 нельзя начинать с произвольного адреса. Третий октет должен быть кратен 4: 0, 4, 8 ... 44, 48 ... 88, 92 ...

Проверка: третий октет делится на 4 без остатка — подсеть правильная.

192.168.44.0/22 — (44 ÷ 4 = 11, остаток 0)
192.168.88.0/22 — (88 ÷ 4 = 22, остаток 0)
192.168.47.0/22 — (47 ÷ 4 = 11, остаток 3)
192.168.89.0/22 — (89 ÷ 4 = 22, остаток 1)

Итоговая адресация​

Все четыре блока не пересекаются.

Разбивка адресного пространства​

DHCP-пул в каждой /22 содержит 923 адреса. В /22-сети broadcast только один — самый последний адрес всего блока (47.255 и 91.255 соответственно). Промежуточные .255-адреса (44.255, 45.255, 46.255) являются валидными хостами и входят в пул.

Считаю для 44.0/22: 44.100–44.255 = 156, 45.0–45.255 = 256, 46.0–46.255 = 256, 47.0–47.254 = 255. Итого: 156 + 256 + 256 + 255 = 923.

Проверка: 923 (DHCP) + 98 (статика 44.2–44.99) + 1 (шлюз 44.1) + 1 (сеть 44.0) + 1 (broadcast 47.255) = 1024 = 4×256

Ещё 98 адресов зарезервировано под статику (принтеры, серверы, NAS).

Cisco SG110D-08HP и ограничение по VLAN​

SG110D-08HP — неуправляемый коммутатор. Он не понимает VLAN-теги, все порты работают в одном L2-домене. Разделить точки доступа и ПК через 802.1q не получится — только физически.

Это определяет выбор варианта:

Вариант 2 — физическое разделение: точки доступа напрямую в ether5 роутера, ПК через коммутатор на ether2–4. Четыре независимых сегмента. Управление, ПК, Wi-Fi и гости — каждый в своей подсети.

Вариант 1 — упрощённая схема: все устройства через коммутатор, ПК и Wi-Fi пользователи в одной подсети.

Гостевая сеть изолирована в обоих вариантах одинаково.

Вариант 1 — три подсети: ПК + Wi-Fi вместе / гости​

Схема подключения​

Важно: выполняю шаги на устройстве без существующей конфигурации. Стандартная заводская конфигурация MikroTik включает мост, IP 192.168.88.1 и DHCP-сервер — они конфликтуют с настройками ниже. Если роутер уже настраивался — сначала делаю сброс:


После сброса роутер перезагрузится без конфигурации. Подключаюсь к нему по MAC через Winbox.

Сразу после подключения устанавливаю пароль администратора — по умолчанию после сброса он пустой:

Шаг 0. Настройка WAN-интерфейса​

Прежде чем настраивать Wi-Fi и подсети, убеждаюсь что ether1 (WAN) подключён к провайдеру и получает адрес. В большинстве случаев достаточно DHCP-пользователя:


Если провайдер выдаёт статический IP — прописываю адрес и шлюз вручную:


Проверяю что интернет работает: /ping 8.8.8.8. Только после этого перехожу к следующим шагам.

Шаг 1. Обновление прошивки​

Обновляю пакеты RouterOS:


Примечание для RouterOS 7.x: команда download + ручной reboot заменена на /system package update install — она скачивает пакеты и перезагружает устройство автоматически. Поскольку статья ориентирована на 6.49.x, приведённая последовательность корректна.

После перезагрузки обновляю прошивку самой платы. Пакеты RouterOS и загрузчик routerboard — два независимых компонента: первая команда обновила ПО, но не загрузчик.


Проверить, нужно ли обновление: /system routerboard print — если поля current-firmware и upgrade-firmware совпадают, загрузчик уже актуален, повторная перезагрузка не нужна.

Для стабильной работы CAPsMAN нужна RouterOS 6.49.x (рекомендую как наиболее стабильную для данного оборудования) или 7.x. Версию проверяю в System → Packages.

Шаг 2. Включение CAPsMAN​

Убеждаюсь, что пакет wireless включён. Включаю CAPsMAN:


Примечание: инструкция рассчитана на legacy CAPsMAN (пакет wireless). На новом оборудовании MikroTik (hAP ax², cAP ax и т.д.) под RouterOS 7.x пакет wireless заменён пакетом wifi, который использует несовместимый синтаксис /interface wifi capsman. Для RB951G-2HnD и RBwAP2nD пакет wifi недоступен — оборудование поддерживает только wireless.

Шаг 3. DNS-резолвер и NTP​

Настраиваю DNS до создания DHCP-серверов — иначе пользователи, которым роутер выдаёт свой IP как DNS-сервер, не смогут резолвить имена.


allow-remote-requests=yes обязателен: роутер будет выступать DNS-resolver'ом для всех внутренних сетей. Он кеширует ответы и форвардит запросы в 8.8.8.8/8.8.4.4. Без этого параметра роутер не отвечает на DNS-запросы даже если его IP указан как dns-server в DHCP.

Сразу настраиваю синхронизацию времени. Без NTP после перезагрузки роутер не знает текущего времени — метки в логах (/log print where topics~"wireless") будут бессмысленными.


Этот синтаксис (servers=) актуален для RouterOS 6.43+ и 7.x. Параметры primary-ntpaddr / secondary-ntpaddr устарели и работали только в версиях до 6.43.

Сразу устанавливаю часовой пояс — без него метки в логах будут в UTC, а не местном времени:


Замени Europe/Moscow на свой часовой пояс. Полный список доступных значений: /system clock print (поле time-zone-name) или в Winbox — System → Clock → Time Zone Name.

Проверить, что время синхронизировалось (через минуту после настройки):

Шаг 4. Профили безопасности​

Создаю два профиля — рабочий и гостевой:


WPA2-PSK с шифрованием AES-CCMP — правильный выбор для RouterOS 6.49.x и данного оборудования (802.11n). WPA3-SAE доступен в RouterOS 7.x с пакетом wifi на более современном железе.

disable-pmkid=yes — защита от PMKID-атаки. Без этого параметра злоумышленник может захватить PMKID из первого EAPOL-фрейма (без ожидания handshake клиента) и брутфорсить пароль сети оффлайн. С disable-pmkid=yes точка доступа не включает PMKID в фреймы ассоциации, что исключает этот вектор атаки. Параметр доступен в RouterOS 6.49.x и 7.x.

Шаг 5. Профили каналов​

Чтобы точки не мешали друг другу, использую разные каналы. В диапазоне 2,4 ГГц три непересекающихся канала: 1, 6 и 11.

Шаг 6. Access List для принудительного роуминга​

Настраиваю принудительный дисконнект пользователя при слабом сигнале — чтобы устройство не «висело» на далёкой точке:


Значение -75 dBm — хорошая отправная точка. Если переключение слишком агрессивное — ставлю -80. Если пользователь слишком долго держится за дальнюю точку — ставлю -70.

interface=any охватывает все CAPsMAN-интерфейсы, включая гостевой SSID — гостей при слабом сигнале тоже принудительно переключаем. Если нужно ограничить роуминг только рабочим SSID, укажи конкретные интерфейсы вместо any.

Как работает этот метод и при чём здесь 802.11r

Access List с reject — это принудительный дисконнект: контроллер разрывает соединение клиента с плохим сигналом, клиент самостоятельно ищет лучшую точку и переподключается. Ожидаемая потеря пакетов — 1–3 секунды.

Это не то же самое, что 802.11r (Fast BSS Transition) — стандарт, при котором переключение происходит на уровне Wi-Fi протокола и занимает 50–300 мс. Legacy CAPsMAN (пакет wireless, RouterOS 6.49.x) не поддерживает 802.11r. RouterOS 7.x с новым пакетом wifi и поддерживающим его оборудованием обеспечивает полноценный FT. На RBwAP2nD под RouterOS 6.49.x метод Access List — единственное доступное решение; 1–3 секунды при роуминге — ожидаемый результат.

Шаг 7. Гостевая сеть​

Гостевой мост создаю без физических портов. Трафик гостей попадает сюда через CAPsMAN datapath. Гости получают интернет, но не видят ни проводные ПК, ни рабочий Wi-Fi.


lease-time=1h — важно для гостевой сети. По умолчанию RouterOS выдаёт адреса на 3 дня: пул из 245 адресов заполнится ушедшими гостями, и новые подключиться не смогут. Час — разумный компромисс.

Для гостевой сети DNS указан напрямую на Google (8.8.8.8) — гостевой DNS-трафик изолируется от внутреннего кеша роутера. Для рабочих сетей DNS будет указывать на сам роутер (см. Шаг 11).

Ограничение скорости для гостей

Чтобы один гость не занял весь интернет-канал, добавляю Simple Queue. Значение 10M/10M — подбираю под ширину своего канала:


Важно: max-limit=10M/10M — это суммарный лимит для всей гостевой подсети: все подключённые гости вместе не превысят 10 Мбит/с в каждом направлении. Такое ограничение защищает канал от монопольного захвата. Если нужен лимит на каждого пользователя отдельно — это решается через Queue Tree + Mangle (выходит за рамки данной статьи).

Шаг 8. NAT для всех внутренних сетей​

Одно правило маскарадинга на выходном интерфейсе ether1 покрывает все внутренние подсети — проводные ПК, Wi-Fi пользователей и гостей:

Шаг 9. Firewall — защита WAN и изоляция гостей​

Важно про порядок правил: MikroTik применяет правила сверху вниз и останавливается на первом совпадении. Команда add всегда добавляет правило в конец таблицы. Если вы вставляете правила частями — убедитесь, что соблюдаете последовательность. Проверить текущий порядок: /ip firewall filter print.

Anti-spoofing: список RFC1918-адресов

Прежде чем добавлять правила фильтрации, создаю список приватных адресов. Без этой защиты атакующий может отправить из интернета пакет с поддельным src-адресом из диапазона 192.168.44.x — и он пройдёт через правила для «внутренних» сетей.


Защита роутера (цепочка input)


Почему anti-spoofing нужен в цепочке input: правило drop для WAN стоит последним. Но правила accept для внутренних src-адресов стоят выше него. Без anti-spoofing атакующий отправит из интернета пакет с src=192.168.44.5 — он совпадёт с правилом accept для 44.0/22 и получит доступ к Winbox/SSH до того, как дойдёт до WAN-drop.

Правило DHCP (protocol=udp dst-port=67): разрешает гостям оба типа DHCP-запросов. T1-renewal (unicast к 192.168.100.1, ~50% срока аренды) покрывался бы и с dst-address=, но T2-rebinding (broadcast к 255.255.255.255, ~87.5% срока аренды) не имеет фиксированного dst-адреса. Без этого правила при срабатывании T2 гостевое устройство теряло бы возможность продлить аренду до истечения аренды. Только UDP-порт 67 разрешён — остальные запросы от гостей к роутеру по-прежнему блокируются следующим drop-правилом.

ICMP (ping) к роутеру с внутренней сети уже покрыт правилом accept для 44.0/22 — отдельного правила не требуется.

Изоляция гостей (цепочка forward)

Гости получают интернет, но не видят внутреннюю сеть. Проводные ПК и Wi-Fi пользователи находятся в одной подсети 44.0/22, дополнительных правил для их связи не нужно.


Цепочка forward не имеет финального drop-all — трафик, не попавший под правила drop, проходит свободно: сотрудники, принтеры и серверы получают интернет и видят друг друга без дополнительных правил accept.

Про изоляцию гостей друг от друга: datapath.client-to-client-forwarding=no в CAPsMAN (Шаг 12) блокирует прямое L2-общение между гостями на уровне точки доступа — гость не может ARP-резолвить другого гостя. Правило src=100.0/24 dst=100.0/24 drop добавляет защиту на уровне L3: даже если гостевое устройство попытается отправить пакет другому гостю через роутер как шлюз, пакет будет отброшен. Оба механизма вместе полностью изолируют гостей друг от друга.

Отключение IPv6

RouterOS по умолчанию включает IPv6 и раздаёт адреса через SLAAC. Без отключения гостевые устройства получают IPv6-адреса и могут общаться через link-local — в обход IPv4-firewall.


Примечание об IPv6 провайдера: если ваш ISP предоставляет IPv6-адресацию на WAN и вам она нужна — не выполняйте эту команду. В таком случае потребуется отдельная настройка IPv6-firewall. Если провайдер работает только через IPv4 — отключайте смело.

Отключение неиспользуемых сервисов

По умолчанию RouterOS открывает Telnet, FTP, WebFig (HTTP и HTTPS) и API. Для типовой офисной установки достаточно только SSH и Winbox:


SSH (порт 22) и Winbox (порт 8291) остаются активными. www отключает WebFig по HTTP (порт 80), www-ssl — по HTTPS (порт 443). Если нужен браузерный доступ к роутеру — не добавляй их в список. api / api-ssl нужны только при управлении роутером через RouterOS API из внешних скриптов или систем мониторинга.

Шаг 10. Мост для всех пользователей и CAPsMAN​

Примечание: см. пояснение про [ find default=yes ] в аналогичном шаге Варианта 2.

Отключение STP на мостах

По умолчанию RouterOS включает RSTP на всех мостах. В этой топологии петель нет, поэтому RSTP только добавляет задержку — порт моста проходит negotiation (до 6 с) каждый раз при подключении или перезагрузке точки доступа. Отключаю:


После этого порты поднимаются мгновенно.

Отключение Neighbor Discovery на гостевой сети

RouterOS по умолчанию отправляет MNDP-пакеты (Neighbor Discovery) на все интерфейсы. Гость, подключённый к bridge-guest, может увидеть hostname роутера, его модель и версию RouterOS. Ограничиваю обнаружение только внутренней сетью:

Шаг 11. DHCP​

dns-server=192.168.44.1 — DNS-сервером для клиентов служит сам роутер. Он кеширует ответы (снижает задержку повторных запросов) и форвардит запросы во внешние серверы 8.8.8.8/8.8.4.4, настроенные в Шаге 3. При кратковременной недоступности Google DNS клиенты продолжают работать через кеш роутера. Гостевая сеть использует Google DNS напрямую (Шаг 7) — это разделяет DNS-трафик гостей и сотрудников.

lease-time=8h — разумный выбор для офисной сети. Восемь часов покрывают рабочий день; устройства, ушедшие вечером, освободят адреса к следующему утру.

При желании можно зарезервировать постоянные адреса для точек доступа по MAC ether1 — аналогично Варианту 2 (Шаг 10), только сервер будет dhcp-lan и адреса из диапазона 44.100–47.254:

Шаг 12. Конфигурации CAPsMAN​

Рабочий трафик идёт в bridge-lan, гостевой — в bridge-guest:


country — указываю свою страну. datapath.local-forwarding=no и datapath.client-to-client-forwarding=no — см. объяснение в Варианте 2, Шаге 13.

tx-power=17 — намеренно сниженная мощность (17 дБм ≈ 50 мВт, максимум для RBwAP2nD — 23 дБм). Меньшая зона покрытия каждой точки создаёт более чёткие границы между ними: устройство быстрее «отпускает» дальнюю точку и переключается на ближнюю.

Примечание про tx-power в cfg-guest: slave-конфигурация (VAP) разделяет физическое радио с мастером — несколько SSID на одном чипе работают через один передатчик. Параметр tx-power является настройкой радиоуровня и в slave-конфигурации определяется мастером (cfg-cap1 / cfg-cap2). Значение в cfg-guest технически избыточно и указано исключительно для документальной согласованности — фактическая мощность передачи одинакова для всех SSID на одном радио.

Два SSID на одном радио: каждая точка одновременно вещает рабочий SSID и гостевой (cfg-guest как VAP). На 2,4 ГГц это снижает суммарную пропускную способность на ~10–20%: радио вынуждено чередовать обслуживание клиентов двух SSID. Для типичной офисной нагрузки это незаметно, но при максимальной загрузке сети учитывайте этот фактор.

Почему cfg-guest не содержит channel=: гостевая конфигурация — это slave-конфигурация. Она поднимается как виртуальный AP (VAP) на том же физическом радио, что и мастер (cfg-cap1 или cfg-cap2), и канал наследует от него автоматически. Slave-конфигурация управляет только своим SSID, профилем безопасности и путём прохождения трафика (datapath) — то есть именно тем, что отличает гостевой SSID от рабочего.

Шаг 13. Провижининг​

comment= — указываю имя точки доступа, которой соответствует правило. Через несколько месяцев, когда потребуется добавить третью точку или изменить конфиг, сразу понятно какая строка к какой AP относится, не сверяясь с MAC-адресами.

action=create-dynamic-enabled создаёт CAPsMAN-интерфейс динамически — он исчезает из /caps-man interface print при отключении точки. Альтернатива create-enabled создаёт статический интерфейс, который остаётся в таблице постоянно. Для данной схемы различия незначительны: правила firewall привязаны к именам мостов (bridge-lan, bridge-guest), а не к именам CAPsMAN-интерфейсов.

Настройка точки доступа RBwAP2nD​

После сброса обновляю RouterOS на точке до той же ветки, что и на контроллере (6.49.x). Смешение мажорных веток между контроллером и CAP приводит к несовместимости и отказу провижининга.


После перезагрузки обновляю загрузчик платы:


Проверить версию: /system package print — убедиться, что установлен пакет wireless (а не wifi).


Задаю осмысленное имя до включения CAP-режима. При name-format=prefix-identity и name-prefix=cap имя CAPsMAN-интерфейса на контроллере формируется как prefix + identity. Если identity=wap-1, интерфейс получит имя capwap-1, а строки в логах будут: capwap-1: client disconnected.

Без явного имени identity по умолчанию — MikroTik на всех точках, и все интерфейсы получат одинаковое имя capMikroTik — различить их в логах будет невозможно.


Для второй точки — wap-2, для третьей — wap-3 и т.д.


wAP подключена через коммутатор. Получит адрес из пула 192.168.44.100–47.254.

Отключение IPv6 на точке доступа


При local-forwarding=no клиентский трафик туннелируется через контроллер, и IPv6 для клиентов уже заблокирован там. Однако сама точка в сети управления получает link-local IPv6-адрес и может быть уязвима к атакам через него — отключаю явно.

Watchdog — автоматическое восстановление при потере контроллера​

Если точка теряет связь с CAPsMAN и не может переподключиться — она зависает. Watchdog перезагружает её после длительной недоступности контроллера.

Выполняю непосредственно на точке доступа RBwAP2nD (не на роутере). Если вы планируете использовать RB951G-2HnD как вторую точку доступа (раздел ниже), Watchdog на роутере-контроллере не нужен: устройство является контроллером и его перезагрузка по недоступности самого себя не имеет смысла.


Как это работает: при потере контроллера планировщик взводится. Если за 10 минут контроллер не восстановился — точка перезагружается. Если контроллер вернулся раньше — перезагрузка отменяется.

Примечание о поведении планировщика: Netwatch запускает down-script при каждой минутной проверке, пока хост недоступен. В RouterOS 6.49.x повторный вызов set disabled=no на уже активном планировщике не сбрасывает счётчик — обратный отсчёт продолжается с момента первоначального взведения. Это подтверждённое поведение, паттерн работает корректно.

Параметр interval планировщика cap-reboot-pending — задержка до перезагрузки:

• interval=5m — агрессивно, для стабильных каналов.
• interval=10m — рекомендую как отправную точку.
• interval=20m — консервативно, при нестабильной связи.

При плановом обслуживании роутера — отключи Netwatch заранее: /tool netwatch set [find comment~"Watchdog"] disabled=yes, после работ снова включи.

RB951G как вторая точка доступа​

Если нужно, чтобы сам роутер тоже раздавал Wi-Fi, включаю его wlan1 как CAP, направленный на себя:


После включения роутер появится в /caps-man remote-cap print как ещё одна точка. Добавляю его MAC в провижининг по той же схеме.

Добавление новых точек доступа​

Масштабирование — один из главных плюсов CAPsMAN. Добавить новую точку занимает 5–10 минут.

Шаг 1. Подготовить новую точку​

Подключаю новую точку к компьютеру напрямую, вхожу в Winbox, делаю сброс и обновляю прошивку (см. раздел «Обновление прошивки точки доступа» выше). Затем настраиваю CAP-режим и Watchdog — так же как для первой точки.

Шаг 2. Подключить к сети и узнать MAC​

Подключаю точку в нужный порт. Точка автоматически найдёт контроллер и появится в списке — но без конфигурации, пока я не добавлю провижининг. На контроллере смотрю MAC нового радиоинтерфейса:


Нахожу новую строку — запоминаю значение RADIO-MAC.

Шаг 3. Выбрать канал​

Соседние точки не должны работать на одном канале. Использую каналы 1, 6 и 11 по очереди — они не пересекаются в диапазоне 2,4 ГГц. Профили ch-1, ch-6 и ch-11 уже созданы в Шаге 5.

Шаг 4. Создать конфигурацию​

Шаг 5. Добавить провижининг​

Заменяю YY:YY:YY:YY:YY:YY на реальный MAC из Шага 2.

Шаг 6. Применить конфигурацию​

Точка подхватывает провижининг автоматически при следующем переподключении. Если нужно применить немедленно:


Проверяю что точка поднялась:


Вижу точку со статусом running и пользователей, которые к ней подключились.

Проверка работоспособности​

Мониторинг пользователей​

Вижу к какой точке подключён каждый пользователь, на каком SSID и с каким уровнем сигнала.

Проверка изоляции гостей​

С гостевого устройства пробую пинговать адрес из рабочей сети:


Ответа быть не должно — firewall блокирует. Пинг 8.8.8.8 при этом работает.

Заодно проверяю что с гостевого устройства нельзя открыть веб-интерфейс роутера по адресу 192.168.100.1 — правило в цепочке input его блокирует.

Тест роуминга​

Беру телефон с активным пингом (приложение Network Ping):

1. Подключаюсь к Office_WiFi рядом с первой точкой
2. Начинаю пинговать 8.8.8.8
3. Медленно иду в сторону второй точки
4. Наблюдаю момент переключения

При правильной настройке потеря пакетов при переключении — 1–3 секунды. Это ожидаемый результат при использовании метода Access List reject без 802.11r (см. Шаг 6). Для браузера и почты незаметно.

Просмотр логов​

Ищу строки вида capwap-1: client disconnected и capwap-2: client connected — это и есть роуминг в действии. Имена интерфейсов в логах формируются из prefix (cap) + identity точки (wap-1, wap-2 и т.д.) — именно поэтому важно задать осмысленное /system identity на каждой точке.

Диагностика CAPsMAN​

Если точка не появляется в /caps-man remote-cap print — проверяю по шагам:


Типичные причины отказа:

• radio-mac в provisioning не совпадает с реальным — убедитесь, что используете значение RADIO-MAC из /caps-man remote-cap print, а не MAC ether1. Это разные адреса одного устройства.
• Разные мажорные ветки RouterOS — контроллер на 6.49.x, точка на другой версии. CAPsMAN несовместим между ветками.
• Пакет wireless не установлен на точке (или установлен пакет wifi вместо wireless). Проверить: /system package print.
• Точка не видит контроллер по IP — убедитесь, что caps-man-addresses указывает на правильный IP контроллера (192.168.44.1 для Варианта 1), и точка получила адрес в подсети 44.0/22.

Если провижининг не применяется к точке, которая уже появилась в remote-cap:

Вариант 2 — четыре подсети: управление / ПК / Wi-Fi / гости​

Схема подключения​

Важно: выполняю шаги на устройстве без существующей конфигурации. Стандартная заводская конфигурация MikroTik включает мост, IP 192.168.88.1 и DHCP-сервер — они конфликтуют с настройками ниже. Если роутер уже настраивался — сначала делаю сброс:


После сброса роутер перезагрузится без конфигурации. Подключаюсь к нему по MAC через Winbox.

Сразу после подключения устанавливаю пароль администратора — по умолчанию после сброса он пустой:

Шаг 0. Настройка WAN-интерфейса​

Если провайдер выдаёт статический IP:


Проверяю что интернет работает: /ping 8.8.8.8. Только после этого перехожу к следующим шагам.

Шаг 1. Обновление прошивки​

Примечание для RouterOS 7.x: команда download + ручной reboot заменена на /system package update install. Поскольку статья ориентирована на 6.49.x, приведённая последовательность корректна.

После перезагрузки обновляю загрузчик:


Проверить: /system routerboard print — если current-firmware и upgrade-firmware совпадают, загрузчик уже актуален.

Шаг 2. Включение CAPsMAN​

Примечание: инструкция рассчитана на legacy CAPsMAN (пакет wireless). На новом оборудовании (hAP ax², cAP ax и т.д.) под RouterOS 7.x используется пакет wifi с несовместимым синтаксисом. Для RB951G-2HnD и RBwAP2nD пакет wifi недоступен.

Шаг 3. DNS-резолвер и NTP​

allow-remote-requests=yes обязателен: роутер выступает DNS-resolver'ом для всех внутренних сетей, кеширует ответы и форвардит запросы в 8.8.8.8/8.8.4.4.


Синтаксис servers= актуален для RouterOS 6.43+ и 7.x.

Сразу устанавливаю часовой пояс — без него метки в логах будут в UTC, а не местном времени:


Замени Europe/Moscow на свой часовой пояс. Полный список: /system clock print (поле time-zone-name) или в Winbox — System → Clock → Time Zone Name.

Шаг 4. Профили безопасности​

WPA2-PSK с шифрованием AES-CCMP — правильный выбор для RouterOS 6.49.x и данного оборудования (802.11n). disable-pmkid=yes — защита от PMKID-атаки: злоумышленник не сможет захватить PMKID из EAPOL-фрейма и брутфорсить пароль оффлайн. Подробнее см. аналогичный шаг в Варианте 1.

Шаг 5. Профили каналов​

В диапазоне 2,4 ГГц три непересекающихся канала: 1, 6 и 11.

Шаг 6. Access List для принудительного роуминга​

-75 dBm — хорошая отправная точка. Если переключение слишком агрессивное — ставлю -80. Если пользователь держится за дальнюю точку — ставлю -70.

Как работает этот метод: Access List с reject — принудительный дисконнект, клиент самостоятельно ищет лучшую точку. Ожидаемая потеря пакетов — 1–3 секунды. Legacy CAPsMAN (пакет wireless, RouterOS 6.49.x) не поддерживает 802.11r (FT). На данном оборудовании 1–3 секунды при роуминге — ожидаемый результат.

Шаг 7. Гостевая сеть​

lease-time=1h — важно для гостевой сети. По умолчанию RouterOS выдаёт адреса на 3 дня: пул из 245 адресов заполнится ушедшими гостями. Час — разумный компромисс.

Для гостевой сети DNS указан напрямую на Google — гостевой DNS-трафик изолируется от внутреннего кеша роутера. Рабочие сети используют роутер как DNS-resolver (настраивается в Шагах 10 и 12).

Ограничение скорости для гостей


max-limit=10M/10M — суммарный лимит для всей гостевой подсети. Лимит на каждого пользователя отдельно — Queue Tree + Mangle (выходит за рамки данной статьи).

Шаг 8. NAT для всех внутренних сетей​

Шаг 9. Firewall — защита WAN, изоляция сетей и anti-spoofing​

Важно про порядок правил: MikroTik применяет правила сверху вниз и останавливается на первом совпадении. Команда add всегда добавляет правило в конец таблицы. Стандартный порядок в каждой цепочке: сначала accept для established/related, затем drop для invalid, затем anti-spoofing, затем специфические правила по адресам.

Проверить текущий порядок: /ip firewall filter print. При необходимости переместить правило: /ip firewall filter move [find comment~"фрагмент комментария"] destination=N.

Anti-spoofing: список RFC1918-адресов


Защита роутера (цепочка input)


Примечание: правило accept для 88.0/22 разрешает рабочим Wi-Fi пользователям открывать Winbox и SSH к роутеру. Если управление должно быть доступно только с сети администрирования (79.0/24) — удалите строку с 88.0/22.

Правило DHCP (protocol=udp dst-port=67): разрешает гостям оба типа DHCP-запросов. T1-renewal срабатывает примерно на 50% срока аренды и использует unicast к 192.168.100.1. T2-rebinding срабатывает примерно на 87.5% срока и отправляет broadcast к 255.255.255.255 — фиксированного dst-адреса нет. Без этого правила T2 блокировался бы следующим drop-правилом для 100.0/24, и гостевое устройство не могло бы продлить аренду до её истечения. Только порт 67 разрешён — все остальные запросы от гостей к роутеру по-прежнему блокируются.

Изоляция гостей и сети управления (цепочка forward)


Правила для 79.0/24 изолируют точки доступа от пользовательских сетей: если точка окажется скомпрометирована, она не сможет инициировать соединения к ПК или Wi-Fi клиентам. Ответный трафик (например, ответ на Winbox-запрос от admin-PC) по-прежнему работает — он попадает под первое правило established/related.

Про доступ проводных ПК к сети управления: правила выше не запрещают проводным администраторам (44.0/22) инициировать соединения к точкам доступа (79.0/24). Это намеренное поведение — сотрудники с проводных рабочих мест могут управлять APs через Winbox или SSH без дополнительной настройки. Если требуется строгая модель, при которой управление AP доступно исключительно из выделенной сети 79.0/24 — раскомментируй правило ниже:


Цепочка forward не имеет финального drop-all — трафик, не попавший под правила drop, проходит свободно. Сотрудники, принтеры и серверы получают интернет и видят друг друга без дополнительных правил accept.

Опционально: ограничение интернет-доступа для сети управления


Отключение IPv6


Примечание об IPv6 провайдера: если ваш ISP предоставляет IPv6-адресацию на WAN и вам она нужна — не выполняйте эту команду. В таком случае потребуется отдельная настройка IPv6-firewall. Если провайдер работает только через IPv4 — отключайте смело.

Отключение неиспользуемых сервисов


SSH (порт 22) и Winbox (порт 8291) остаются активными. www и www-ssl отключают WebFig по HTTP (порт 80) и HTTPS (порт 443) соответственно.

Шаг 10. Мост управления, CAPsMAN и DHCP для точек доступа​

dns-server=192.168.79.1 — точки доступа используют роутер как DNS-resolver (форвардит запросы в 8.8.8.8/8.8.4.4, настроенные в Шаге 3).

Примечание: [ find default=yes ] ищет запись по умолчанию в таблице CAPsMAN. Перед выполнением проверьте командой /caps-man manager interface print: если таблица пустая — выполни только команду add. Если команда set выдала :nothing was changed — это нормально.

Резервирование IP-адресов для точек доступа

MAC-адрес ether1 точки (именно им она делает DHCP-запрос; не путать с radio-mac для CAPsMAN) можно узнать двумя способами:

• На самой точке: /interface ethernet print
• На контроллере после первого подключения: /ip dhcp-server lease print

Адреса .10 и .11 находятся ниже динамического пула (79.20–79.50). Статическая аренда в RouterOS не требует, чтобы IP входил в пул. Если точка уже получила динамический адрес, удаляю старую аренду:

Шаг 11. Мосты для ПК и Wi-Fi пользователей​

Примечание о switch-offloading: RB951G-2HnD имеет встроенный switch-чип (AR8327N), который по умолчанию объединяет ether2–5 аппаратно. В Варианте 2 ether2–4 входят в bridge-lan, а ether5 — в bridge-mgmt: порты разделены по разным мостам, и аппаратный offloading для них отключается. Весь forwarding обрабатывается программно через CPU. Для небольшого офиса (трафик в пределах 100 Мбит/с) это не ощутимо, но стоит иметь в виду. Проверить состояние: /interface ethernet switch port print.

Отключение STP на всех мостах

По умолчанию RouterOS включает RSTP на всех мостах. В этой топологии петель нет — RSTP только добавляет задержку (до 6 с при подключении или перезагрузке точки). Отключаю на всех мостах:


Отключение Neighbor Discovery на гостевой сети

Шаг 12. DHCP для проводных ПК и Wi-Fi​

dns-server=192.168.44.1 / 192.168.88.1 — DNS-сервером для клиентов служит сам роутер. Он кеширует ответы и форвардит запросы в 8.8.8.8/8.8.4.4 (настроено в Шаге 3). При кратковременной недоступности Google DNS клиенты продолжают работать через кеш.

lease-time=8h — разумный выбор для офисной сети. Восемь часов покрывают рабочий день; устройства, ушедшие вечером, освободят адреса к следующему утру.

Шаг 13. Конфигурации CAPsMAN​

datapath.bridge определяет, куда уходит трафик пользователей — рабочие пользователи в bridge-wifi, гости в bridge-guest:


country — указываю свою страну. Значение влияет на максимальную мощность передатчика и разрешённые каналы.

tx-power=17 — намеренно сниженная мощность (17 дБм ≈ 50 мВт, максимум для RBwAP2nD — 23 дБм). Меньшая зона покрытия каждой точки создаёт более чёткие границы: устройство быстрее «отпускает» дальнюю точку.

tx-power в cfg-guest технически определяется мастером (cfg-cap1 / cfg-cap2), поскольку slave-конфигурация использует то же физическое радио. Значение указано для документальной согласованности.

datapath.local-forwarding=no — весь трафик туннелируется через контроллер. Важно: при перезагрузке роутера все пользователи на всех точках одновременно отключаются.

datapath.client-to-client-forwarding=no для гостей — запрещает прямое L2-общение между гостями через mDNS, SMB и прямые соединения.

Два SSID на одном радио: каждая точка вещает рабочий SSID и гостевой (VAP). На 2,4 ГГц это снижает суммарную пропускную способность на ~10–20%. Для типичной офисной нагрузки незаметно.

Почему cfg-guest не содержит channel=: slave-конфигурация (VAP) наследует канал от мастера (cfg-cap1 или cfg-cap2) автоматически.

Про маршрутизацию между сегментами: RouterOS автоматически маршрутизирует трафик между всеми подключёнными подсетями. Wi-Fi пользователи (88.0/22) и проводные ПК (44.0/22) видят друг друга — это намеренное поведение. Гостевая сеть изолирована правилами firewall из Шага 9.

Шаг 14. Провижининг​

comment= — указываю имя точки доступа для каждого правила. Упрощает управление при добавлении третьей, четвёртой точки.

action=create-dynamic-enabled создаёт CAPsMAN-интерфейс динамически — он исчезает из /caps-man interface print при отключении точки. Альтернатива create-enabled создаёт статический интерфейс, который остаётся в таблице постоянно. Для данной схемы различия незначительны: правила firewall привязаны к именам мостов (bridge-wifi, bridge-guest), а не к именам CAPsMAN-интерфейсов.

Настройка точки доступа RBwAP2nD​

После сброса обновляю RouterOS до той же ветки (6.49.x), что и на контроллере:


После перезагрузки обновляю загрузчик:


Проверяю: /system package print — убедиться, что установлен пакет wireless (не wifi).



Для второй точки — wap-2 и т.д. Без явного имени все интерфейсы получат одинаковое имя capMikroTik — различить их в логах будет невозможно.


wAP подключена в ether5 роутера. Получит адрес по DHCP из пула 192.168.79.20–50 и зарегистрируется на контроллере.

Отключение IPv6 на точке доступа

Watchdog — автоматическое восстановление при потере контроллера​

Выполняю непосредственно на точке доступа RBwAP2nD (не на роутере). Watchdog настраивается только на внешних точках доступа. Если вы планируете использовать RB951G-2HnD как вторую точку (раздел ниже), Watchdog на роутере-контроллере не нужен.


Как это работает: при потере контроллера планировщик взводится. Если за 10 минут контроллер не восстановился — точка перезагружается. Если контроллер вернулся раньше — перезагрузка отменяется.

В RouterOS 6.49.x повторный вызов set disabled=no на уже активном планировщике не сбрасывает счётчик — обратный отсчёт продолжается с момента первоначального взведения.

• interval=5m — агрессивно, для стабильных каналов.
• interval=10m — рекомендую как отправную точку.
• interval=20m — консервативно, при нестабильной связи.

При плановом обслуживании роутера — отключи Netwatch заранее: /tool netwatch set [find comment~"Watchdog"] disabled=yes, после работ снова включи.

RB951G как вторая точка доступа​

После включения роутер появится в /caps-man remote-cap print как ещё одна точка. Добавляю его MAC в провижининг по той же схеме.

Добавление новых точек доступа​

Шаг 1. Подготовить новую точку​

Сброс, обновление прошивки (см. раздел «Обновление прошивки точки доступа»), настройка CAP-режима и Watchdog.

Шаг 2. Подключить к сети и узнать MAC​

Запоминаю значение RADIO-MAC.

Шаг 3. Создать конфигурацию


Шаг 4. Добавить провижининг


Шаг 5. Применить конфигурацию

Точка подхватывает провижининг автоматически при следующем переподключении. Если нужно применить немедленно:


Проверяю что точка поднялась:


Вижу точку со статусом running и пользователей, которые к ней подключились.

Проверка работоспособности​

Мониторинг пользователей​

Проверка изоляции гостей​

С гостевого устройства проверяю все три внутренних сегмента:


Ответов быть не должно ни на один адрес — firewall блокирует. Пинг 8.8.8.8 при этом работает.

Заодно проверяю что с гостевого устройства нельзя открыть 192.168.100.1 — правило в цепочке input его блокирует.

Проверка связи между Wi-Fi и ПК​

С рабочего Wi-Fi устройства (88.0/22):


Ответ должен приходить — RouterOS маршрутизирует между 88.0/22 и 44.0/22 по умолчанию.

Тест роуминга​

Беру телефон с активным пингом (приложение Network Ping):

1. Подключаюсь к Office_WiFi рядом с первой точкой
2. Начинаю пинговать 8.8.8.8
3. Медленно иду в сторону второй точки
4. Наблюдаю момент переключения

Потеря пакетов при переключении — 1–3 секунды (ожидаемый результат без 802.11r). Для браузера и почты незаметно.

Просмотр логов​

Ищу строки capwap-1: client disconnected и capwap-2: client connected.

Диагностика CAPsMAN​

Если точка не появляется в /caps-man remote-cap print:


Типичные причины отказа:

• radio-mac в provisioning не совпадает — используйте RADIO-MAC из /caps-man remote-cap print, не MAC ether1.
• Разные ветки RouterOS — контроллер 6.49.x и точка другой версии несовместимы.
• Пакет wireless не установлен на точке (проверить: /system package print).
• Точка не видит контроллер — проверьте caps-man-addresses=192.168.79.1 и что точка получила адрес в 79.0/24.

Принудительно применить провижининг:

Как увеличить диапазон адресов в будущем​

Если 923 DHCP-адресов станет мало — расширяю до /21 (2046 адресов для устройств).

Важно про CIDR-выравнивание: для /21 третий октет должен быть кратен 8. Число 44 не кратно 8 (44 ÷ 8 = 5, остаток 4), поэтому 192.168.44.0/21 — не валидный CIDR-блок. Адреса 44.x входят в выровненный блок 192.168.40.0/21 (40 ÷ 8 = 5, остаток 0 ), который охватывает 40.0–47.255 и включает всю текущую /22-сеть. Шлюз остаётся на 192.168.44.1 — это валидный адрес внутри нового /21-блока.

Меняю три места:

1. Маска интерфейса:


2. Пул DHCP:


Пул задаётся двумя диапазонами: новый блок 40.100–43.255 и исходный 44.100–47.254. Диапазон 44.2–44.99 (статика) намеренно исключён. Адреса 40.0–40.99 также исключены из пула — они зарезервированы под статику нового блока по той же логике (шлюз 40.1, принтеры/серверы 40.2–40.99 при необходимости). Если статика в новом блоке не нужна, пул можно начать с 40.2.

3. Сеть DHCP-сервера:


Правило кратности при смене маски:

/22 — третий октет кратен 4: 44 , 48 , 52 …
/21 — третий октет кратен 8: 40 , 48 … (44 ; нужный блок — 40.0/21, охватывает 40.0–47.255)
/20 — третий октет кратен 16: 32 , 48 … (44 ; нужный блок — 32.0/20, охватывает 32.0–47.255)

Резервное копирование конфигурации​

RouterOS предлагает два формата — рекомендую держать оба.

Бинарный бэкап — полный снимок конфигурации, включая пароли:


Файл office-wifi.backup скачиваю через Winbox (меню Files).

Важно: бинарный бэкап содержит все пароли в открытом виде. Шифрую:


Экспорт конфигурации — текстовый файл со всеми командами:


При восстановлении:


Резервное копирование точек доступа


Файл wap-1-config.rsc скачиваю через Winbox. Повторяю для каждой точки (wap-2-config и т.д.).

Итог​

Я получил централизованно управляемую Wi-Fi-сеть с единым SSID, автоматическим роумингом и изолированной гостевой сетью. Каждая пользовательская /22-подсеть содержит 923 DHCP-адреса и 98 адресов под статику. Гостевая сеть ограничена по скорости и времени аренды DHCP, IPv6 отключён на роутере и на каждой точке доступа. Firewall защищён от спуфинга RFC1918-адресов с WAN-интерфейса. Профили безопасности используют disable-pmkid=yes — защита от PMKID-атаки на пароли Wi-Fi. Неиспользуемые сервисы управления (Telnet, FTP, WebFig HTTP и HTTPS, API) отключены. Каждая точка доступа оснащена Watchdog для автоматического восстановления при потере связи с контроллером и получает осмысленное имя для идентификации в логах. STP отключён на всех мостах — порты поднимаются без задержки. DNS для рабочих сетей указан на роутер-кешер, который форвардит во внешние серверы. Часовой пояс установлен явно — метки в логах отображаются в местном времени.

Вариант 1 — проще в монтаже. Все устройства через коммутатор, ПК и Wi-Fi пользователи в одном сегменте 44.0/22.

Вариант 2 — максимальное разделение трафика. Четыре независимых сегмента. Точки доступа на отдельном порту ether5. Wi-Fi пользователи и проводные ПК маршрутизируются между собой, гостевая сеть полностью изолирована. Сеть управления (79.0/24) изолирована от Wi-Fi пользователей и гостей в обоих направлениях; точки доступа не могут инициировать соединения в сети ПК и Wi-Fi. Проводные администраторы (44.0/22) по умолчанию сохраняют доступ к точкам — это намеренное поведение для удобства управления; при необходимости полной изоляции см. опциональное правило в Шаге 9. Точки доступа получают постоянные IP по статическим DHCP-арендам (.10–.11 ниже динамического пула .20–.50).

Гостевая сеть изолирована в обоих вариантах одинаково — на уровне L2 (client-to-client-forwarding=no) и на уровне L3 (firewall).

Добавление новой точки — 5 минут: сброс, обновление прошивки, /system identity, RouterOS 6.49.x + пакет wireless, CAP-режим, IPv6 отключить, Watchdog, MAC в провижининг с comment=.

Если позже понадобится заменить Cisco SG110D-08HP на управляемый коммутатор с VLAN — Вариант 2 масштабируется без переделки конфига роутера.