Думаю, не лишним будет написать, что версия Router OS на точках доступа и контроллере должна быть одинаковой. Хотя из практики — работает c мелкими глюками и так. Пакет Wireless должен быть установлен на контроллере (HEAD) и само собой на AP (HEAD_AP). На этом основная настройка микротика закончена, но я рекомендую выполнить еще несколько настроек для удобства и безопасности. Создаем еще одну конфигурацию, в которой все остальные настройки оставляем те же самые, только меняем SSID и настройку безопасности.
CAPsMAN с двумя SSID — гостевая и рабочая сеть.
Внимание! Данная инструкция разработана для MikrotikOS v6.40
На других версиях может работать не корректно.
Рассмотри случай, когда на микротике нужно настроить CAPsMAN с двумя сетями, рабочей и гостевой.
Для начала нужно настроить два бриджа на микротике с гостевой и рабочей сетью.
За основу возьмём инструкцию по настройке хотспота на микротике
Для будущего удобства рекомендуем заменить часть стандартного конфига:
Это нужно для того, чтобы рабочая сеть была настроена на отдельный inet-bridge, а не просто на отдельный порт в микротике.
После настройки, у Вас получится полноценный хотспот с гостевой и рабочей сетью, в разных бриджах (hs-bridge и inet-bridge).
CAPSMAN на Mikrotik. « Blog of Khlebalin Dmitriy
Если вы хотите настроить в ручную каждый пункт, то воспользуйтесь инструкцией ниже.
3) Добавим datapath для hs-bridge
4) Добавим datapath для inet-bridge
5) Добавим security профиль для рабочей сети
2) Добавим все Lan интерфейсы в него
В CAPsMAN в разделе Channels создадим наш канал. Допустим будет частота 2412. Нажмаем плюсик и создадим канал Если локальные настройки будут идентичны настройкам CAPSMAN, это позволит не потерять нам Wi-fi клиентов в случае падения централизованного управления но опять же, должна быть предусмотрена, возможность, к примеру, выхода в интернет именно с локальной точки, то есть маршруты шлюзы и все такое. Дополнение srcnat можно использовать ещё в ситуации, когда на исходящем порту несколько ip адресов провайдер выделил диапазон адресов на одном проводном подключении.
Безопасность
Конфигурация по умолчанию уже не дает подключаться к роутеру из внешней сети, но основывается защита только на пакетном фильтре. Не забываем, про установку пароля на пользователя admin. Поэтому, в дополнение к фильтрации и паролю, я делаю следующие:
Доступность на внешних интерфейсах
Отключаю не нужные в домашней сети (и не во всех не домашних сетях) сервисы, а оставшиеся ограничиваю областью действия, указывая адреса, с которых можно к этим сервисам подключится.
Следующим шагом, будет ограничение на обнаружение роутера с помощью поиска соседей. Для этого, у вас должен быть список интерфейсов, где данный протокол может работать, настроим его:
Добавим в список discovery интерфейсы, на которых мы хотим, чтобы протокол Neighbors Discovey работал.
Теперь настроим работу протокола, указав список discovery в его настройках:
В простой, домашней конфигурации, в списке discovery могут быть интерфейсы, на которых может работать протокол доступа по MAC адресу, для ситуаций, когда IP не доступен, поэтому настроим и эту функцию:
Теперь, роутер станет «невидимым» на внешних интерфейсах, что скроет информацию о нем (не всю конечно), от потенциальных сканеров, и даже, лишит плохих парней легкой возможности получить управление над роутером.
Защита от DDoS
Теперь, добавим немного простых правил в пакетный фильтр:
И поместим их после правила defcon для протокола icmp.
RFC 1918
RFC 1918 описывает выделение адресных пространств для глобально не маршрутизируемых сетей. Поэтому, имеет смысл блокировать трафик от\к таким сетям, на интерфейсе, который смотрит к провайдеру, за исключением ситуаций, когда провайдер выдает вам «серый» адрес.
Поместите эти правила ближе к началу и не забудьте, добавить в список WAN интерфейс, смотрящий в сторону провайдера.
Довольно спорная технология, которая позволяет приложениям попросить роутер пробросить порты через NAT, однако, протокол работает без всякой авторизации и контроля, этого просто нет в стандарте, и часто является точкой снижающей безопасность. Настраивайте на свое усмотрение:
SIP Conntrack
Кроме всего прочего, стоит отключить модуль conntrack SIP, который может вызывать неадекватную работу VoIP, большинство современных SIP клиентов и серверов отлично обходятся без его помощи, а SIP TLS делает его окончательно бесполезным.
Mikrotik CAPsMAN на 2 SSID публичную и приватную | ItHelp
Отключаю не нужные в домашней сети (и не во всех не домашних сетях) сервисы, а оставшиеся ограничиваю областью действия, указывая адреса, с которых можно к этим сервисам подключится. Теперь, роутер станет невидимым на внешних интерфейсах, что скроет информацию о нем не всю конечно , от потенциальных сканеров, и даже, лишит плохих парней легкой возможности получить управление над роутером. Довольно спорная технология, которая позволяет приложениям попросить роутер пробросить порты через NAT, однако, протокол работает без всякой авторизации и контроля, этого просто нет в стандарте, и часто является точкой снижающей безопасность.
Конфигурации для 2.4 и 5 гГц.
Выберем, как пускать трафик с точек доступа:
Выберем ранее созданный профиль шифрования:
Выберем ранее созданные каналы для 2.4 гГц
Аналогично создадим конфигурацию cfg2 для 5гГц, выбрав каналом cannel_5GHz.
Защита от DDoS
Развёртывание сети 2.4гГц и 5гГц (Provisioning).
Довольно просто всё: для A/AN/AC развёртывается cfg2,4GHz для B/G/GN cfg2,4GHz
5 ГГц, на одной из точек, у меня нет, но тут все по аналогии.
Полезным будет изменить формат имени точек доступа в CAPsMAN:
Для генерации имени использовать префиксы 5gHz и 2.4gHz
Этот интерфейс можно не создавать, он по идее, должен создаться динамически.
Теперь пришло время перейти к клиентской точке доступа HEAD_AP:
Пытаюсь «повесить» ее на виртуальный интерфейс, так как на физическом у меня уже «висит» WDS, но тут ничего не происходит.
Вероятно все это можно «повесить», только на физический интерфейс, если я так сделаю, то отвалится WDS, 5ГГц интерфейса тут у меня нет, а так можно было бы оставить WDS на интерфейсе 2ГГц, а CAPs повесить на 5ГГц, но что есть, то есть, поэтому в данном случае возвращаюсь к проводу и вешаю вторую точку на провод.
Сразу разрешу подключение с удаленной точки в фаерволе, ее адрес по шнурку уже известен, 192.168.10.47
На клиентской точке HEAD_AP стало вот так:
Во-первых, появился динамический интерфейс:
И в RemoteCAP появится наша удаленная точка:
Остается один вопрос, как это все бриджевать и выпускать клиентов в инет.
Вариант (на CAPSMAN-это наша основная точка HEAD, галка LOCAL FORWARDING установлена).
Когда эта галка стоит, то клиенты видят друг друга через точку, через которую они подконнекчены (и у нас нет этого интерфейса на основной точке HEAD).
В этом случае мы должны на CAPe (то есть, в настройках нашей клиентской точки, выбрать бридж):
Второй вариант (на CAPSMAN-это наша основная точка HEAD, галка LOCAL FORWARDING снята).
Содержание: