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

mDNS между VLAN с помощью только фильтров моста — Смотри, мама, без всяких контейнеров!

mDNS между VLAN с помощью только фильтров моста — Смотри, мама, без всяких контейнеров!, RouterOS

UpRunTech

Guest

01.02.2024 20:54:00

[ИЗМЕНЕНО: это была моя первоначальная версия, но теперь она заменена версией с MACVLAN ниже] У меня была задача на одном объекте: нужно было, чтобы устройства в VLAN2 видели Chromecasts, AppleTV и Airprint, которые находятся в VLAN1. Используя несколько идей, которые возникли у меня при подготовке поста про mDNS через Wireguard, я решил попробовать. Похоже, что у Mikrotik есть в разработке решение для mDNS в ROS, но пока его ждать нужно; а пока… На объекте стоит коммутатор CRS354 с IGMP snooping и роутер с PIM-SM, но, разумеется, это не помогает для mDNS между VLAN. Также в некоторых комнатах у меня есть hEX’ы, работающие как управляемые коммутаторы (с VLAN-фильтрацией), поэтому я попробовал на одном из hEX сделать следующее:

hEX имеет мост с VLAN-фильтрацией, где VLAN1 и VLAN2 размечены на Eth1, а на остальных портах — без тегов, как нужно. Я создал новый мост с именем BridgemDNS. Создал два VLAN-интерфейса (VLAN1 и VLAN2), родительским у которых был общий VLAN-фильтрованый мост. Порты из этих VLAN добавил в новый мост и настроил фильтрацию:

/interface bridge
add name=BridgemDNS protocol-mode=none

/interface bridge port
add bridge=BridgemDNS frame-types=admit-only-untagged-and-priority-tagged interface=VLAN1 pvid=1001
add bridge=BridgemDNS frame-types=admit-only-untagged-and-priority-tagged interface=VLAN2 pvid=1001

/interface bridge vlan
add bridge=BridgemDNS untagged=VLAN1,VLAN2 vlan-ids=1001

/interface bridge filter
add action=accept chain=forward comment="Allow mDNS" dst-address=224.0.0.251/32 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF dst-port=5353 in-bridge=BridgemDNS ip-protocol=udp mac-protocol=ip out-bridge=BridgemDNS src-port=5353
add action=drop chain=forward in-bridge=BridgemDNS out-bridge=BridgemDNS

/interface bridge nat
add action=src-nat chain=srcnat dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF to-src-mac-address=CC:2D:E0:14:64:AD

Итак, видно, что в первой части создаётся новый мост и порты VLAN настроены так, чтобы присоединиться к нему с PVID 1001. Таким образом, управляющий трафик второго уровня из VLAN1 и VLAN2 становится связанным. Очень важно, чтобы была фильтрующая drop-правила, которая блокирует весь двухсторонний L2-трафик, иначе был бы полный хаос. Правило перед drop — основное волшебное, которое пропускает только mDNS-трафик, а потом drop отбрасывает всё остальное.

Поначалу не происходило ничего заметного, пока я не сделал SRCNAT по MAC-адресу кадров, уходящих в сеть, используя MAC основного VLAN-фильтрованного моста (не моста mDNS) — CC:2D:E0:14:64:AD. Думаю, это связано с IGMP snooping, раздачей трафика на порты и гарантией того, что MAC известен в этой сети.

В итоге это сработало — mDNS широковещательный трафик пошёл в обе стороны. Основной роутер разрешил отправлять трафик с VLAN2 на VLAN1, и тогда Airplay заработал: Macbook в VLAN2 смог соединиться с AppleTV в VLAN1.

Дальше я проверил, можно ли разрешить только определённый mDNS-трафик между VLAN’ами:

/interface bridge filter
add action=accept chain=forward comment="Allow mDNS VLAN1" dst-address=224.0.0.251/32 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF dst-port=5353 in-bridge=BridgemDNS in-interface=VLAN1 ip-protocol=udp mac-protocol=ip out-bridge=BridgemDNS src-mac-address=34:FD:6A:03:A1:8B/FF:FF:FF:FF:FF:FF src-port=5353

add action=drop chain=forward comment="Drop all other mDNS from VLAN1" dst-address=224.0.0.251/32 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF dst-port=5353 in-bridge=BridgemDNS in-interface=VLAN1 ip-protocol=udp mac-protocol=ip out-bridge=BridgemDNS src-port=5353

add action=accept chain=forward comment="Allow mDNS" dst-address=224.0.0.251/32 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF dst-port=5353 in-bridge=BridgemDNS ip-protocol=udp mac-protocol=ip out-bridge=BridgemDNS src-port=5353

add action=drop chain=forward in-bridge=BridgemDNS out-bridge=BridgemDNS

/interface bridge nat
add action=src-nat chain=srcnat dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF to-src-mac-address=CC:2D:E0:14:64:AD

Первое фильтрующее правило пропускает mDNS-трафик с VLAN1 на VLAN2 лишь с SRCMAC 34:FD:6A:03:A1:8B — это конкретный AppleTV. Следующее правило сбрасывает весь остальной mDNS-трафик с VLAN1 на VLAN2. Третье разрешает весь оставшийся mDNS-трафик, который идёт только с VLAN2 на VLAN1. И в конце идёт основное drop-правило, которое блокирует всё прочее в обе стороны, плюс SRCNAT по MAC.

На этом этапе Macbook видит только один AppleTV, а Airprint-принтер становится недоступен. Я продолжаю тестировать, но выглядит достаточно надёжно. IP-адреса VLAN-интерфейсам я не назначал. Может быть, тут есть какие-то побочные эффекты, хотя карта пакетов показывает, что пакеты через мост обрабатываются раньше, чем IP-пакеты.

Советую попробовать это на отдельном устройстве Routerboard в своей сети, как сделал я, а не на основном роутере и коммутаторах.

qqflexx

Guest

03.03.2024 09:26:00

Это действительно работает. Очень изящно и элегантно по сравнению с контейнерами (никакой зависимости от стороннего ПО). Спасибо!

/interface macvlan add interface=vlan10 name=macvlan10
/interface macvlan add interface=vlan80 name=macvlan80

/interface bridge add name=bridge-mdns protocol-mode=none
/interface bridge port add bridge=bridge-mdns interface=macvlan10
/interface bridge port add bridge=bridge-mdns interface=macvlan80

/interface bridge filter add action=accept chain=forward comment="Разрешить только mDNS" dst-address=224.0.0.251/32 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF dst-port=5353 in-bridge=bridge-mdns ip-protocol=udp mac-protocol=ip out-bridge=bridge-mdns src-port=5353
/interface bridge filter add action=drop chain=forward in-bridge=bridge-mdns out-bridge=bridge-mdns comment="Отбросить весь остальной L2 трафик"

/interface bridge nat add action=src-nat chain=srcnat dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF to-src-mac-address=[/interface bridge get [find name="bridge"] mac-address] comment="SNAT к основному VLAN мосту"

Есть ли какие-то (непреднамеренные?) минусы такого способа?

UpRunTech

Guest

03.03.2024 11:12:00

Пока что я так не думаю, но буду рад услышать аргументы против такого подхода. Единственное, что приходит в голову — это неправильная настройка или ошибка с правилом последней капли (или если оно отключено), что может привести к проблемам.

DarkNate Guest	#4 0 03.03.2024 12:40:00 Мне это кажется костыльным решением. Почему просто не использовать PIM-SM? Я несколько раз делился примером конфигурации PIM-SM на этом форуме, работает на последней стабильной версии ROS v7.

S8T8

Guest

03.03.2024 13:21:00

Привет, DarkNate, я попробовал твое предложение по PIM-SM, но это не сработало с принтерами, Chromecast и прочим... Поддержка сказала, что нам нужен мультикастовый ретранслятор (если нужно, могу вставить их ответ). Это должно было бы у тебя работать?

DarkNate Guest	#6 0 03.03.2024 15:58:00 Поделитесь полным ответом поддержки. Я не понимаю, почему маршрутизация multicast между VLAN в MikroTik такая запутанная.

S8T8

Guest

03.03.2024 19:59:00

… /routing pimsm instance add name="PIM-SM" disabled=no [+ Bridge set multicast-querier=no]
/routing pimsm interface-template add instance="PIM-SM" interfaces=LAN-VLAN,IoT-VLAN source-addresses=10.0.3.60

Достаточно ли этих двух строк кода, чтобы с LAN-VLAN найти принтер, подключённый к IoT-VLAN с IP 10.0.3.60? mDNS нельзя маршрутизировать между сетями через IGMP proxy или PIM, потому что он использует link-local (нероутируемый) multicast-адрес назначения. И к сожалению, RouterOS из коробки не поддерживает mDNS proxy.

UpRunTech

Guest

03.03.2024 20:34:00

PIM-SM не пропускает IPv4 mDNS. Только Бог знает, сколько я пытался заставить его работать — безрезультатно. PIM-SM отлично подходит для Chromecast, так как тот использует mDNS и обнаружение, совместимые с PIM-SM, но другие устройства, например принтеры или Airplay, обнаружить не удалось. У меня PIM-SM работал в VLAN-сетях и через соединения Wireguard и Zerotier. Во всех случаях, если не настроить что-то вроде фильтрации на мосту, как в моём предыдущем примере с Wireguard/EoIP или теперь с MACVLANS, IPv4 mDNS-трафик не проходит. Хак ли это? По-моему, нет, особенно для небольших случаев с парой VLAN, а таких, согласитесь, здесь подавляющее большинство — больше 90%. Но на больших объектах с огромным потоком mDNS-трафика я бы использовал такую схему с осторожностью, только с выборочной фильтрацией MAC-адресов и ограничением скорости через правила фильтрации моста. Пока Mikrotik не сделает в ROS что-то вроде повторителя mDNS, другого выхода нет, разве что запускать контейнеры, что возможно только на ARM и x86-устройствах.

DarkNate Guest	#9 0 04.03.2024 12:24:00 Кто-нибудь уже пробовал с этим поработать? https://help.mikrotik.com/docs/display/ROS/Group+Management+Protocol

UpRunTech

Guest

#10

04.03.2024 20:35:00

Спасибо за ваше предложение. Диапазон 224.0.0.0/24, похоже, не работает, даже если его добавить в GMP, вероятно, из-за второго абзаца на странице https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml. Возможно, я ошибаюсь — не в первый раз. Но вы ведь эксперт по протоколам в этом форуме. Скажите, что я делаю неправильно.

DarkNate

Guest

#11

05.03.2024 07:10:00

Ха-ха, я не эксперт, в отличие от других претендентов на звание эксперта в этом форуме или в индустрии в целом. Я просто парень, который любит играть с сетями. Не совсем понимаю, почему это работает или не работает, пока не было времени глубоко разбираться в маршрутизации мультикаста. Но я надеюсь, что кто-то со временем сможет нормально сделать «чистое» решение для маршрутизации мультикаста между VLAN и «чистый» способ организовать mDNS/локальный мультикаст между VLAN. Или, может быть, в будущем через IETF обновят спецификации mDNS/мультикаст обнаружения IPv6, чтобы официально разрешить межVLAN-маршрутизацию с флагом или процедурой, с правильными мерами безопасности на уровне протокола. Насколько я знаю, пока такого нет.

UpRunTech

Guest

#12

05.03.2024 10:04:00

Я прописал 224.0.0.251 в GMP, и он не появляется в таблице MDB на свиче. А вот 224.0.1.251, 224.1.1.251 и 224.1.0.251, прописанные одновременно в GMP, отображаются в таблице MDB. Я почти уверен, что Mikrotik придерживаются стандарта и не разрешают использовать 224.0.0.0/24 с протоколами PIM-SM и IGMP. Я даже просил их нарушить стандарт и добавить флаг для разрешения работы с PIM-SM, но пока ответа нет.

Эксперименты с mDNS и техникой фильтрации на мосту я проводил только с IPv4, не с IPv6 (там используется адрес ff02::fb), так как большинство, включая меня, пока избегают IPv6-маршрутизации, и большинство mDNS все еще работает поверх IPv4. Думаю, если у вас есть успехи с PIM-SM и mDNS, это потому, что вы используете маршрутизацию IPv6, и ff02:fb работает для вас и ваших устройств с IPv6.

Что касается техники фильтрации на мосту, самая простая версия должна отражать mDNS между портами на mDNS-мосту, фактически не отличаясь от некоторых пользовательских программ, например https://github.com/Gandem/bonjour-reflector/, которые просто копируют пакеты между VLAN на одном ethernet-интерфейсе. Я не эксперт в Go, но из кода проекта Bonjour-reflector (B-R) понятно, что он проверяет флаг DNS QR в теле пакета и рассылает его по всем известным VLAN-ам устройств, прописанным в .toml-файле. Если QR-флаг не установлен, проверяется MAC-адрес источника пакета, и рассылка происходит только по VLAN, соответствующим этому MAC.

Bridge-filter (B-F) не может проверять QR-флаг и рассылает mDNS-пакеты на все интерфейсы моста. B-R работает только с VLAN, а B-F подходит для любого интерфейса, входящего в мост, не только VLAN. Кроме того, B-F можно настроить более тонко — например, пропускать пакеты только от определённых MAC или (не проверял, но возможно) разрешать определённые MAC только на ограниченных портах моста с помощью списков интерфейсов. B-R переписывает MAC-адрес источника пакета на MAC интерфейса, через который идёт отражение. Техника фильтрации на мосту делает то же самое, но через SRCNAT, подменяя MAC на MAC основного моста (не mDNS-моста).

Если посмотреть опции фильтрации моста в ROS, то можно сделать настройки ещё точнее, задавая правила, которые разрешают или запрещают трафик на основе:
- Трафика между конкретными интерфейсами через списки входящих и исходящих мостов (используя списки интерфейсов)
- MAC-адресов источника
- Меток пакетов
И, судя по всему, можно контролировать даже скорость, чего B-R не умеет.

В общем, метод B-F может делать то же самое, что и B-R, с дополнительными возможностями, но без мороки с контейнерами, плюс он встроен в ROS нативно.

DarkNate

Guest

#13

05.03.2024 12:00:00

Да, все мои домашние сети/устройства и производственная сеть на 100% работают с IPv6 — включены, развернуты, только или в основном. Я перестал тратить время на устаревший IPv4 несколько лет назад. Советую тебе двигаться в сторону работы с маршрутизацией IPv6 multicast. Когда-нибудь IPv4 должны полностью убрать из стека протоколов.

mozerd

Guest

#14

05.03.2024 12:06:00

Хотя я полностью разделяю ваши чувства, много провайдеров до сих пор не поддерживают IPv6… очень неприятно это признавать. Мой старый провайдер [Rogers] поддерживал IPv6, а вот мой новый [Bell] пока нет. Надеюсь, что мой новый провайдер передумает, учитывая, что правительство США обязало всех перейти на IPv6 к 2025 году.

DarkNate Guest	#15 0 06.03.2024 06:32:00 mDNS использует IPv6 с локальной привязкой к сети…

donkeyKong Guest	#16 0 11.03.2024 22:20:00 Только что проверил это на своей домашней сети. Три разные VLAN, и всё работает идеально. Я избавился от небольшой виртуальной машины с Avahi, которая делала то же самое.

jlpedrosa Guest	#17 0 19.03.2024 02:06:00 @UpRunTech вы говорите: «Для ясности, мой основной мост, к которому подвязаны VLAN-интерфейсы, фильтруется по VLAN». Что вы имеете в виду под «моим основным мостом»? У меня роутер с несколькими интерфейсами, и каждый интерфейс подключается к свитчу, других мостов у меня нет. Не уверен, что вы сможете помочь. Я пробовал ваш метод с одним мостом, но... Ни в какую, Хосе. Спасибо заранее!

Читают тему

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