Russian Users MikroTik | Форум пользователей MikroTik

В логике ошибка: надо тогда для каждого рабочего устройства два правила писать - одно будет разрешать ему в основную, другое - запрещать в гостевую.

Но при таких вводных я бы уже все-таки сделал единую SSID, и раскидывал бы на основе маков по разным vlan'ам, как предлагал изначально.

xvo писал(а): ↑21 июл 2021, 23:22 В логике ошибка: надо тогда для каждого рабочего устройства два правила писать - одно будет разрешать ему в основную, другое - запрещать в гостевую.

Но при таких вводных я бы уже все-таки сделал единую SSID, и раскидывал бы на основе маков по разным vlan'ам, как предлагал изначально.

И почему-то не сработало!
Правила были такие

MAC:xx-yy-zz-00-11-22
SSID Regexp:имярабочейсети
Action: Accept
=========================
MAC:xx-yy-zz-00-11-22
SSID Regexp:имярабочейсети5ггц
Action: Accept
============================

И сразу за ними запрещающие
MAC:xx-yy-zz-00-11-22
SSID Regexp:имягостевойсети
Action: Reject
==========================
MAC:xx-yy-zz-00-11-22
SSID Regexp:имягостевойсети5ггц
Action: Reject

Правила поместил выше правила разрешающего вход в гостевую есть и правила общего сброса!

Так а не из-за той же рандомизации?

Вообще, получается, что если брать в расчет то, что на любом устройстве всегда можно включить рандомизацию, то подход с запретом для определенных маков вообще нельзя считать надежным.
То есть разрешать определенным макам - логично.
А запрещать надо всем, кроме - что само по себе уже противоречит идее гостевой сети.

Так что пилите vlan'ы :)

xvo писал(а): ↑22 июл 2021, 11:34 Так а не из-за той же рандомизации?

Не, это была тествоая машинка со старым свисточком D-Link.

xvo писал(а): ↑22 июл 2021, 11:34 Вообще, получается, что если брать в расчет то, что на любом устройстве всегда можно включить рандомизацию, то подход с запретом для определенных маков вообще нельзя считать надежным.
То есть разрешать определенным макам - логично.
А запрещать надо всем, кроме - что само по себе уже противоречит идее гостевой сети.

Да, верно. Но если так подумать - то запрет всем в подключении - это как бы хорошо.. И рандомность маков - тут не играет роли.. Страшнее тогда MAC-spoofing! Тут уже можно включить паранойю и каждому клиенту дать еще пароль на устройство.. А вообще видимо да - для таких кейсов нужно расширять контроль сети и делать VLAN.

1nc0gn1t0man писал(а): ↑22 июл 2021, 12:39 Страшнее тогда MAC-spoofing! Тут уже можно включить паранойю и каждому клиенту дать еще пароль на устройство..

Авторизацию сертификатами через radius и dot1x :)
Но вопрос уже в целесообразности.

xvo писал(а): ↑22 июл 2021, 13:16

1nc0gn1t0man писал(а): ↑22 июл 2021, 12:39 Страшнее тогда MAC-spoofing! Тут уже можно включить паранойю и каждому клиенту дать еще пароль на устройство..

Авторизацию сертификатами через radius и dot1x :)
Но вопрос уже в целесообразности.

Именно так.. А в этом то и дело.. Сейчас пока нет смысла даже VLANы вводить.

1nc0gn1t0man писал(а): ↑22 июл 2021, 14:21 Сейчас пока нет смысла даже VLANы вводить.

Если у вас не local forwarding на капсмане, то их даже протягивать никуда не надо, достаточно все внутри контроллера переделать.

1nc0gn1t0man писал(а): ↑21 июл 2021, 22:13
уточню - то есть заходим например через тот же Winbox в Interfaces и там где красным capsman подписал "managed by CAPsMAN" открываем свойства и снимаем галку с пункта внизу "Default Authentificate" во вкладке "Wireless" ТОЛЬКО НА интерфейсах wifi - которые "отвечают" за НЕгостевую зону. А оба нижних правила отключаем.

У Капсмана свой ACL
Если точки под управлением CAPsMan то открываем вкладку WINBOX/CAPsMAN/Access List и все настройки делаем здесь. Настройки на вкладке Wireless не работают когда интерфейс управляется капсманом, поэтому красным и предупреждает