+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблема с динамическим VLAN

Проблема с динамическим VLAN, RouterOS

pe1chl

Guest

02.05.2023 09:01:00

С сайта help.mikrotik.com: Список доступа

Подменю: /interface wireless access-list

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

Правила списка доступа обрабатываются по одному, пока не найдётся подходящее правило. Тогда выполняется действие, указанное в этом правиле. Если действие предусматривает принятие клиента, клиент принимается, при этом параметры его подключения могут быть переопределены на те, что указаны в правиле списка доступа.

Параметры правил списка доступа:

Параметры совпадения клиента:
address — MAC-адрес клиента
interface — необязательный интерфейс для сравнения с интерфейсом, к которому клиент фактически подключается
time — время дня и дни, когда правило действует
signal-range — диапазон силы сигнала клиента, при котором правило срабатывает
allow-signal-out-of-range — опция, разрешающая сигналу клиента находиться вне диапазона постоянно или в определённый промежуток времени
Параметры подключения:
ap-tx-limit — ограничение скорости передачи в сторону клиента
client-tx-limit — ограничение скорости передачи в сторону AP (применяется только к клиентам RouterOS)
private-passphrase — PSK-пароль для этого клиента, если используется алгоритм аутентификации PSK
vlan-mode — режим VLAN-тегирования, определяет, должен ли трафик от клиента маркироваться тегом (и сниматься при отправке клиенту)
vlan-id — VLAN ID, используемый при VLAN-тегировании

Эта тема посвящена параметрам «vlan-mode» и «vlan-id» в списке доступа. Я использую это с классическим беспроводным драйвером (не wifiwave2) и RouterOS v7.9. Беспроводной интерфейс настроен с «vlan-mode: use tag» и «vlan-id: фиктивное значение». Наблюдение: клиент, совпадающий по правилу списка доступа и получивший валидный VLAN, действительно подключается к этому VLAN для направленного трафика и широковещательного (ARP, DHCP). Но он НЕ получает мультимедийный трафик в этом VLAN, например Chromecast или IPv6 SLAAC. Если я устанавливаю vlan-id беспроводного интерфейса в какой-то валидный VLAN, все подключённые и совпадающие клиенты получают мультимедийный трафик из ЭТОГО VLAN, а не из своего, что приводит к назначению некорректного IPv6-адреса.

Есть ли у кого-то опыт с динамическим назначением VLAN для беспроводных клиентов? Я использую это, чтобы уменьшить количество WiFi SSID/виртуальных интерфейсов. На самом деле я не использую access-list, а применяю MAC-аутентификацию через RADIUS и user-manager с такими настройками в группе user-manager:

/user-manager user group
add attributes="Mikrotik-Wireless-Forward:1,Mikrotik-Wireless-VLANIDtype:0,Mikrotik-Wireless-VLANID:10" name=WiFi-Public outer-auths=pap

Это даёт такой же эффект, как установка vlan-id через список доступа, и проблема проявляется точно так же.

pe1chl

Guest

26.05.2023 13:19:00

Кто-нибудь ещё использует динамическое присвоение VLAN для беспроводной сети? Эта проблема сводит меня с ума… Хотелось бы хотя бы услышать, если кто-то может подтвердить её, или, может, у меня какой-то тонкий косяк в настройках. Даже саппорт уже месяц не отвечает на мой тикет SUP-114289…

bpwl

Guest

26.05.2023 21:55:00

Интересно также понаблюдать за поведением настройки VLAN на беспроводном интерфейсе. Например, когда ставишь её так, как ты сказал (без тега), клиент будет получать мультикасты со всех VLAN’ов с тегом. Но, конечно, он не смотрит на трафик с тегами (разве что, может, Windows, но у меня здесь нет Windows-машин). Если выставить "использовать тег" и выбрать один из существующих VLAN’ов, то клиент будет получать мультикасты именно с этого VLAN’а, но без тега. Независимо от VLAN, назначенного через access-list или radius.

Сейчас я настроил беспроводной интерфейс на "использовать тег" и поставил неиспользуемый VLAN тег, чтобы клиенты хотя бы не получали чужие мультикасты. Но они всё равно не получают мультикасты, относящиеся к своему VLAN! В общем, похоже, это ожидаемое поведение.

Вот что, по моему мнению, происходит... Беспроводной интерфейс с "no tag" — то есть без обработки тегов и фильтрации, работает как тупой мост/коммутатор (с VLAN-фильтрацией ВЫКЛЮЧЕНО), он просто принимает и передаёт всё "как есть", независимо от присутствия тега VLAN в заголовке пакета. Именно так я и использую в PtP и PtMP соединениях, прокидывая все VLAN’ы по этим линкам. Access-list с указанным тегом и номером VLAN обрабатывает тег на уровне драйвера Wi-Fi (фильтрует пакеты конкретного VLAN, убирает тег перед отправкой и добавляет при приёме) по записи access-list для конкретного MAC-адреса (unicast).

А что с мультикастом/браудкастом для MAC из access-list? Насколько я знаю, в access-list нет записей для мультикаст MAC-адресов. Там может быть несколько записей с разными настройками VLAN для одного интерфейса WLAN и SSID, но для разных MAC-адресов. Для unicast понятно, какую запись из access-list использовать, опираясь на MAC. А для мультикаст/браудкаст — разных клиентов может иметь разные настройки VLAN в записях access-list. Как драйвер может понять, какую из них применять? Возможно, тогда остаётся только настройка интерфейса по умолчанию. Единственный способ для драйвера правильно выбрать и обработать VLAN — когда это unicast.

Так что, может, multicast helper всегда должен быть в режиме "full", чтобы все мультикасты/браудкасты преобразовывались в unicast. Интересно, достаточно ли умный этот multicast helper, чтобы использовать настройки VLAN из access-list, когда преобразует мультикаст в несколько unicast-пакетов, которые (???) могут иметь разные VLAN ID или нет (???)?

pe1chl

Guest

27.05.2023 14:00:00

Конфигурация помощника мультикаста (включена или выключена) никак не влияет на эту проблему… Конечно, обработка VLAN-тегов (внутри драйвера Wi-Fi) требует дополнительной обработки. Но не путём постоянной проверки списка доступа, а путём регистрации VLAN, определённого из списка доступа, в момент подключения вместе с записью о соединении — так можно отслеживать, кто на каком VLAN. И, похоже, это ЧАСТИЧНО реализовано, поскольку широковещательный трафик, вроде ARP, обрабатывается правильно. Копия трафика на MAC-адрес FF:FF:FF:FF:FF:FF рассылается всем станциям в этом VLAN, а не только MAC из списка доступа. Так что думаю, код, который проверяет MAC-адрес FF:FF:FF:FF:FF:FF, нужно изменить — чтобы он учитывал только младший бит в первом байте (или два младших бита). Это соответствует широковещательному трафику и всему мультикасту. Это решит проблему. Не думаю, что это что-то невозможное или необычное. Такая же функция на точках доступа Unifi работает отлично!

Amm0

Guest

27.05.2023 15:45:00

Я сегодня ленился и сделал то же самое: VLAN на каждый SSID… так что помочь не могу. Но один SSID с динамическим VLAN — теоретически, это лучшее решение (контроль по клиенту + меньше Wi-Fi маячков). Так что буду следить с интересом. Кажется, это должно работать так же, как «use-tag», и делать то же самое с MAC/RADIUS для мультимедиа, как и с другими перенаправленными пакетами… Похоже на баг. PIM или прокси не должны быть нужны, ведь сегмент ведь должен быть один из-за тегирования… Кстати, кто-нибудь знает, работает ли это (или должно работать) в wifiwave2?

bpwl

Guest

27.05.2023 17:18:00

Из любопытства, кто-нибудь знает, работает ли это (или должно работать) в wifiwave2? Пока есть только информация из релиз-ноутов (устройства ax ещё не покупал). Релиз-ноуты 7.7 *) wifiwave2 — добавлена опция установки per-client vlan-id в списке доступа (поддерживается только на интерфейсах 802.11ax) (только через CLI).

pe1chl

Guest

27.05.2023 17:31:00

Полностью согласен. У меня нет оборудования, способного запустить wifiwave2 (у меня есть 4011, но я не могу позволить себе потерять 2.4 ГГц), так что проверить не могу. Может, ты проведёшь эксперимент? Когда у тебя несколько точек доступа работают на VLAN (с использованием опции vlan tag в Wireless интерфейсе), можно просто добавить один пункт в access-list, который перенаправит одного клиента на другую сеть (назначив ему другой VLAN tag), и посмотреть, как это будет работать с, например, IPv6, Chromecast и другими multicast-приложениями. Это простой тест, который не требует полной перестройки всей конфигурации беспроводной сети, как у меня (и обнаружения проблемы уже после того, как всё сделано).

pe1chl

Guest

28.05.2023 09:00:00

Ну, я ошибался... Я неправильно предположил, что настройка «default» для multicast helper подойдёт для типичных многовещательных рассылок, таких как IPv6 RA или Chromecast, ведь с этой настройкой всё нормально работает, когда для беспроводного интерфейса настроена одна VLAN. Раньше у меня всё стабильно работало с такой конфигурацией, пока я не переключился на динамическое назначение VLAN. Но после того, что написал bpwl, я протестировал снова и выяснилось, что с multicast-helper=full всё действительно работает! А настройка «default» для multicast-helper на самом деле равнозначна «disabled». Кто это вообще придумал??? Я проверял, решит ли проблему отключение multicast helper, но не помогло. На самом деле между «default» и «disabled» никакой разницы. Теперь с настройкой multicast-helper=full я снова получаю корректный IPv6-адрес, и Chromecast тоже работает (между устройством на динамически назначенной VLAN и проводным устройством на нетегированном порту той же VLAN). Так что это вроде временное решение. Но я всё равно считаю это багом: для такого низкообъёмного «announcement» multicast-трафика всё должно работать и без multicast helper, как это работает для широковещательного трафика.

mkx

Guest

28.05.2023 11:53:00

На мой взгляд, требование полноценного multicast-хелпера в таком случае вполне понятно. Дело в том, что multicast-хелпер помогает точке доступа лучше «видеть» беспроводных клиентов, чтобы широковещательные и групповые рассылки доходили до каждого (даже спящего) клиента через unicast. Когда клиенты вынесены в отдельные VLAN (либо вручную настроенными ACL, либо через ответы Radius), осведомленность точки доступа о клиентах становится ещё важнее. Ей нужно направлять разные широковещательные и групповые рассылки (из разных VLAN) именно тем клиентам, которым они предназначены. То есть не просто преобразовывать широковещания и multicast в unicasts, а учитывать принадлежность клиента к конкретному VLAN.

pe1chl

Guest

#10

28.05.2023 16:19:00

Если подумать, то преобразование мультимеда в юникаст действительно может быть единственным способом заставить мультимед работать на одном WiFi SSID с динамически назначаемыми VLAN... Возможно, было бы лучше, если бы настройка multicast-helper «default» распознавала это и включала multicast helper для тех клиентов, у которых динамический VLAN.

Rewrite8 Guest	#11 0 16.11.2024 19:55:00 Привет, спасибо за твой пост. У меня та же проблема на RouterOS 6.49.17 с Wi-Fi, VLAN и списком доступа. В моём случае я хочу динамически назначать VLAN на основе MAC-адреса. Это работает нормально, но меня удивило, что IPv6 RA, похоже, отсутствует. Где можно настроить «multicast to unicast»?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры