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

КАК ЭТО СДЕЛАТЬ: mDNS и SSDP через Wireguard

КАК ЭТО СДЕЛАТЬ: mDNS и SSDP через Wireguard, RouterOS

UpRunTech

Guest

25.03.2023 22:47:00

Это руководство по настройке работы mDNS (Bonjour) и SSDP (для DLNA) через интерфейс Wireguard, связывающий два роутера Mikrotik на ROS7.7 и выше, без всяких сложностей вроде IGMP Proxy/PIM/Avahi/контейнеров. Во вложении показана реализация. Жирным шрифтом над флагом указаны реальные интерфейсы. Толстые вертикальные линии — общий сетевой уровень. Мосты роутеров не используют VLAN-фильтрацию, так как обычно она не нужна в таких домашних условиях.

Wireguard Сторона A:

/interface wireguard
add listen-port=13231 mtu=1412 name=Wireguard
/interface wireguard peers
add allowed-address=172.16.200.0/24 endpoint-address=site-b.com endpoint-port=13231 interface=Wireguard public-key="<side a's public key>"

/ip route
add disabled=no distance=1 dst-address=172.16.200.0/24 gateway=Wireguard pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10

Сторона B:

/interface wireguard
add listen-port=13231 mtu=1412 name=Wireguard
/interface wireguard peers
add allowed-address=172.16.100.0/24 endpoint-address=site-a.com endpoint-port=13231 interface=Wireguard public-key="<side b's public key>"

/ip route
add disabled=no distance=1 dst-address=172.16.100.0/24 gateway=Wireguard pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10

Это типовая конфигурация Wireguard, не забудьте разрешить в фаерволе входящий UDP на порт 13231 для трафика Wireguard. У меня MTU установлен на 1412 вместо дефолтных 1420, так как с одной стороны PPPoE. Подстройте под свою линию. Маршруты нужны, чтобы роутеры видели подсети друг друга.

EoIP Сторона A:

/interface eoip
add !keepalive local-address=172.16.100.254 mtu=1500 name=EoIP remote-address=172.16.200.254 tunnel-id=1

Сторона B:

/interface eoip
add !keepalive local-address=172.16.200.254 mtu=1500 name=EoIP remote-address=172.16.100.254 tunnel-id=1

Здесь настраиваем интерфейс EoIP. IPSEC не нужен, так как трафик идёт через Wireguard. Не забудьте добавить порт EoIP в основной мост на каждом конце.

Стороны A и B:

/interface bridge port
add bridge=BridgeMain interface=EoIP

Фильтрация моста

На этом этапе оба моста объединены в широковещательную домену, что может привести к беде — любые широковещательные запросы, включая DHCP, будут идти в обе стороны. Нам нужно пропускать только mDNS и SSDP, и ничего лишнего — это делается через Bridge Filter, мощную, но редко используемую функцию ROS.

Стороны A и B:

/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 ip-protocol=udp mac-protocol=ip out-interface=EoIP src-port=5353
add action=accept chain=forward comment="Allow SSDP" dst-address=239.255.255.250/32 dst-mac-address=01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF dst-port=1900 ip-protocol=udp log-prefix=SSDP mac-protocol=ip out-interface=EoIP
add action=drop chain=forward out-interface=EoIP
add action=drop chain=output out-interface=EoIP

Такая фильтрация сохраняет исходные MAC-адреса ethernet-кадров, начинающиеся с 01:, что нужно для правильного распространения в сети на другой стороне. Трафик mDNS, кажется, полностью идёт широковещательно. В пакетах mDNS есть IP-адреса сервисов, и после обнаружения клиент связывается с сервисом по обычному маршруту Wireguard на уровне 3. SSDP (DLNA) — это широковещательные запросы клиента для поиска серверов. Сервер отвечает юникастом на уровне 3, отправляя UDP-пакет обратно на тот IP и UDP-порт, с которых пришёл запрос.

В моём случае DLNA сервер — MythTV, но из-за проблемы безопасности 2014 года он отвечает только на широковещательные запросы из своих подсетей. Возможно, у других DLNA серверов похожая логика. Мне пришлось сделать DSTNAT и SRCNAT правила, чтобы обмануть его.

На роутере со стороны MythTV были такие NAT-правила. У роутера адрес шлюза 172.16.100.254, для удобства добавил адрес 172.16.100.253. ТВ на другой стороне — 172.16.200.237, MythTV — 172.16.100.200.

Правило src-nat заставляет IP ТВ выглядеть как из той же подсети, что и MythTV, когда проходит широковещательный запрос, при этом MAC-адрес остается исходным (01:...), позволяя распространить кадры в подсеть. Правило dst-nat переписывает юникаст-ответ MythTV, который думает, что отвечает на 172.16.100.253 (второй адрес роутера), на адрес ТВ 172.16.200.237, дальше по Wireguard. Все дальнейшие общения MythTV с ТВ идут уже по обычному маршруту и NAT не нужен.

/ip firewall nat
add action=src-nat chain=srcnat comment="SSDP broadcast" dst-address=239.255.255.250 src-address=172.16.200.237 to-addresses=172.16.100.253
add action=dst-nat chain=dstnat comment="SSDP unicast reply" dst-address=172.16.100.253 src-address=172.16.100.200 to-addresses=172.16.200.237

На основе этого примера можно попробовать использовать другие варианты, но это уже вне рамок данного руководства.

EoIP: VLANX, VPLS (?), OpenVPN TAP
Wireguard: L2TP, PPP, IPSec, OpenVPN TUN, GRE

Ссылки:

Wireguard: https://help.mikrotik.com/docs/display/ROS/WireGuard
EoIP: https://help.mikrotik.com/docs/display/ROS/EoIP
Bridge Firewall: https://help.mikrotik.com/docs/display/ROS/Bridging+and+Switching#BridgingandSwitching-BridgeFirewall
mDNS: https://en.wikipedia.org/wiki/Multicast_DNS
SSDP: https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
Обсуждение на форуме: http://forum.mikrotik.com/t/mdns-repeater-feature/148334/179

Valerio5000

Guest

11.04.2023 14:06:00

Привет, меня очень заинтересовал этот проект, только один вопрос: в вашем примере вы перенаправляете трафик mDNS / SSDP на конкретный IP. Как сделать так, чтобы весь трафик получали все подсети, а не один IP? (Я не эксперт в ROS).

UpRunTech

Guest

07.06.2023 20:21:00

Мне пришлось сделать это специально для MythTV. Он не реагирует на клиентские широковещательные запросы, если они приходят не с той же подсети(ей), что и сам MythTV, поэтому я обманул систему дополнительными правилами NAT, используя роутер как некий прокси-адрес, чтобы создать видимость, что широковещательный запрос пришёл с устройства в той же подсети. У других серверов SSDP/DLNA такой проблемы может и не быть — там нужно разбираться в каждом конкретном случае. Я проверял это недавно и смотрел записанное ТВ у себя дома на LG TV через встроенное приложение просмотра фото/видео. Если SSDP работает, сервер отображается как доступный вариант для просмотра в приложении.

Valerio5000

Guest

17.08.2023 18:12:00

Могу подтвердить, что всё работает, по крайней мере, что касается DLNA. В моей домашней сети есть DLNA-сервер (Synology NAS), подключённый к AC2 HAP. В доме в горах у меня есть HAP AC3 LTE, к которому я подключил телевизор Samsung 2010 года, и… идеально! Я увидел свой NAS в списке устройств ввода и без проблем смог просматривать фильмы.

Я настроил EoIP через Wireguard и применил правила в бриджевом фаерволе.

Вопрос: почему я не вижу RB удалённой сети в WinBox?

С помощью этого классного трюка можно ли использовать такие приложения, как LAN Messenger, или даже устроить LAN-вечеринку с игрой по локальной сети, где сервер находится в одной LAN, а клиенты — в противоположной?

UpRunTech Guest	#5 0 03.10.2023 19:55:00 Это использует другой процесс обнаружения, не mDNS и не SSDP. Тебе нужно будет разобраться, как работают эти протоколы, чтобы понять, какую фильтрацию мостов и NAT нужно настроить.

anav Guest	#6 0 27.10.2023 13:12:00 Валерио, если хочешь устраивать локальные вечеринки и более сложные сети, советую обновить роутер на тот, который поддерживает Zerotier — это было бы идеально для твоих задач.

UpRunTech

Guest

28.10.2023 04:47:00

Я протестировал PIM-SM через ту же самую ссылку Wireguard (конечно же отключив EoIP) и обнаружил следующее. mDNS не маршрутизируется PIM, как и ожидалось (ведь он предназначен только для локальной сети), даже при добавлении статического GMP для 224.0.0.251 на интерфейсах Bridge и Wireguard с обеих сторон. Chromecast’ы обнаруживаются с помощью SSDP/DIAL, которые устройство тоже поддерживает и которые совместимы с PIM. Приложение YouTube видит Chromecast на другой стороне и может на него трансляцию отправлять. А вот обнаружение принтеров через WSD в Windows, похоже, не работает, хотя вроде бы этот протокол совместим с PIM. В спецификации процесса WS-Discovery, кажется, говорится, что он тоже только для Link-Local. Следующим попробую Zerotier. Протокол WDS для обнаружения, страница 8 — https://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf DIAL v 2.2.1 страница 8 — http://www.dial-multiscreen.org/dial-protocol-specification

Amm0

Guest

28.10.2023 13:53:00

Один из подходов для ZeroTier — использовать flow rules, чтобы ограничить сеть ТОЛЬКО мультикастовым обнаружением (например, 224.0.0.0/24), а затем мостить интерфейсы ZT на нужный VLAN. Это позволяет WG (который, скорее всего, будет быстрее) использоваться для «обычного» (унікастового) трафика ПОСЛЕ того, как mDNS нашёл устройство. В большинстве случаев mDNS-запрос возвращает уникастовый IP-адрес, так что все настройки WG, файрвола и прочего применяются после того, как mDNS обнаружил устройство.

Теоретически можно иметь два или больше интерфейсов ZeroTier для одной и той же «сети обнаружения ZT», если хотите мостить mDNS/«мультикастовое обнаружение» на дополнительные VLAN — и поскольку flow rules ZeroTier ограничивали бы это мультикастом, петли не должны возникать. Это больше концепция, я пока не тестировал.

nichky

Guest

30.10.2023 03:49:00

/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 ip-protocol=udp mac-protocol=ip out-interface=EoIP src-port=5353
add action=accept chain=forward comment="Разрешить SSDP" dst-address=239.255.255.250/32 dst-mac-address=01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF dst-port=1900 ip-protocol=udp log-prefix=SSDP mac-protocol=ip out-interface=EoIP
add action=drop chain=forward out-interface=EoIP
add action=drop chain=output out-interface=EoIP
Очень хорошо. Просто небольшой вопрос: по сути, здесь вы разрешаете MAC-адрес конкретных устройств. Значит, сайт A==B может получить к ним доступ?

UpRunTech

Guest

#10

01.11.2023 20:58:00

Короче, тут ты как бы разрешаешь MAC-адреса конкретных устройств. Этот сайт A==B сможет получить доступ? Нет, ты заметишь, что это именно dst-mac-address, и я особо щепетильно проверяю, чтобы это был правильный мультикастовый Ethernet-адрес, связанный с этим мультикастовым IP. Если бы ты хотел разрешить только определённые src-mac, сначала пришлось бы пометить пакеты, а потом использовать эту метку как цель фильтра в указанных правилах разрешения. Единственные списки в bridge filter — это списки интерфейсов, но они тут не помогают.

nichky Guest	#11 0 02.11.2023 01:49:00 Мы ждем вторую часть, с Zerotier.

Valerio5000 Guest	#12 0 10.11.2023 13:10:00 Спасибо за поддержку! Мне нужно поддерживать разные локальные подсети, каждая со своим DHCP-сервером, чтобы они были независимы друг от друга. Это возможно с Zerotier?

UpRunTech

Guest

#13

08.02.2024 10:08:00

Я переключился с Wireguard на Zerotier на обоих роутерах Mikrotik в маршрутизируемом режиме, а не в режиме моста. В итоге пришлось восстановить туннель EoIP с фильтрацией mDNS-моста поверх ссылки Zerotier. Как ты и сказал, можно было бы поставить Zerotier в режим моста и добавить его как порт в основной мост на каждом конце, настроив в Zerotier фильтрацию, чтобы пропускать только mDNS-бродкасты, может быть, ещё ARP, плюс обычный уникастовый трафик. Теперь надо будет это проверить.

Valerio5000 Guest	#14 0 28.02.2024 08:02:00 +1

Читают тему

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