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

Настройка Avahi Reflector на Mikrotik

Настройка Avahi Reflector на Mikrotik, RouterOS

rkrisi

Guest

09.05.2020 12:10:00

Дорогие коллеги! Для устройств IoT мне нужно иметь возможность маршрутизировать mDNS широковещательный трафик через VLAN. Я видел, что это возможно только с помощью внешнего сервера (или, может быть, MetaRouter с OpenWRT, но, к сожалению, мой роутер — RB4011 — пока не поддерживает MetaRouter). Это не большая проблема, у меня уже есть Raspberry Pi, который работает только как локальный DNS-сервер (Pi-hole). Я думал установить на него avahi-reflector. Но я не знаю, какая должна быть правильная конфигурация для этого. Сейчас Pi подключён к одному из ether-портов роутера. Этот порт — untagged access port, который виден только в моей приватной VLAN, и настроено правило брандмауэра, разрешающее гостевой сети доступ к DNS-серверу. Всё работает отлично. Но теперь я не понимаю, как сохранить эти функции и одновременно использовать рефлектор. Если я правильно понял, в таком сценарии нужно оставить приватную VLAN untagged, а роутеру указать маршрутизировать гостевую VLAN для сервера Reflector как tagged. Это правильный подход? Не повлияет ли это на работу DNS-сервера? Полагаю, что в таком случае DNS-сервер будет доступен и из гостевой VLAN (в том числе его веб-интерфейс). Спасибо за помощь!

jwbtx

Guest

11.06.2020 22:04:00

Браво тебе за то, что не бросил ветку и продолжаешь делиться обновлениями! Я устанавливаю всё оборудование Unifi, но не хочу полностью отказываться от RouterOS. Моя задача — разделить сеть на LAN, IoT и NoT. Сейчас я отправляю все VLAN'ы в LAN. Я уже настроил политики, ограничивающие трафик к LAN — пока что не перенёс устройства на соответствующие SSID (VLAN), но у меня не включены mdns и «VLAN Filtering» на мостовом интерфейсе, так что ожидаю проблемы. Твоя запись вдохновила и помогла. Спасибо! jwb

rkrisi

Guest

12.06.2020 11:37:00

К сожалению, я застрял на этом. Отражение mDNS вроде работает нормально: принтеры, устройства AirPlay сразу появляются на каждом VLAN и функционируют как надо. Но вот устройства Chromecast и Spotify Connect, похоже, работают не идеально. Похоже, этим устройствам нужна дополнительная настройка помимо mDNS, но я не знаю, куда копать дальше…

RackKing Guest	#4 0 12.06.2020 13:26:00 У меня это работает с Chromecast — ты применял фильтры брандмауэра, которые пропускают трафик?

rkrisi

Guest

14.06.2020 16:53:00

Ну, похоже, у меня тоже всё работает. Пришлось сбросить настройки Wi-Fi на некоторых устройствах Chromecast, не знаю почему, но теперь вроде работает. Ты разрешаешь доступ для устройств Chromecast через брандмауэр с нескольких сетей? Я не полностью проверял это на своей гостевой сети (у которой нет доступа к локальной сети), но она тоже находит устройства Chromecast (правда, я ещё не пробовал с неё к ним подключаться), так что, видимо, для подключения этим устройствам нужен такой доступ?

rkrisi

Guest

14.06.2020 17:09:00

Извини, что не увидел твой ответ раньше! Да, «из коробки» это не заработает, но если используешь Unifi, то, возможно, у тебя будет лучший опыт с этим. Насколько я знаю, в Unifi встроен mDNS-ретранслятор, так что тебе просто нужно включить соответствующий переключатель. Как описано, этого должно хватить, но могут быть различия в устройствах. Если я полностью настрою это (пока, к сожалению, мало времени, поэтому я постепенно переношу свои устройства на IoT-сеть), возможно, сделаю полный пост о том, что нужно для работы.

rkrisi

Guest

03.07.2020 13:30:00

Итак, что у меня по прогрессу: устройства Chromecast полностью работают в основной сети. Гостевая сеть, похоже, не работает даже с включённым mDNS reflection. В гостевой сети всё заблокировано, кроме WAN-трафика. Как только я разрешаю vlan_guest сети доступ ко всему, устройства начинают появляться. Я не понимаю, что нужно добавить в файрвол для этого. Простого списка адресов с адресами устройств Chromecast явно недостаточно. Устройства Denon с Spotify Connect очень нестабильны. Приложение Denon HEOS работает отлично, а вот Spotify Connect — нет. Устройства Denon обычно не показываются в списке устройств, там только Chromecast. Но иногда они появляются, и, например, мой ПК и iPad всегда видят эти устройства Denon, а вот мой телефон и другие телефоны — нет...

RackKing

Guest

03.07.2020 13:57:00

Это зависит от того, как настроен ваш файрвол, но, думаю, нужно настроить переадресацию (разрешить) трафик с main на guest. Просто дайте гостевой сети доступ к Avahi reflector, если он, конечно, находится в основной сети.

rkrisi

Guest

03.07.2020 14:34:00

Ну, возможно, ты прав, поэтому я бы попробовал вот что. Ты хочешь разрешить трафик только к этому устройству? Но дело в том, что именно правило в цепочке input вызывало появление устройств Chromecast. Поэтому я добавил правило в цепочку input, а не в forward, которое разрешает доступ к всей сети из гостевой сети. Рефлектор имеет несколько (виртуальных) интерфейсов и собственный адрес в каждой подсети. Просматривая с помощью avahi-browse, я вижу, что он отражает весь трафик на каждый из своих интерфейсов. Я так понял, что это и есть суть рефлектора. На его локальном интерфейсе (тот, что в гостевой сети) я могу получить доступ к рефлектору.

RackKing

Guest

#10

03.07.2020 16:07:00

[/quote] Ну, возможно, ты прав, так что я бы попробовал вот что. Ты имеешь в виду разрешить трафик только к этому устройству? Но: именно правило в цепочке input вызвало появление устройств Chromecast. Поэтому я добавил правило в цепочку input, а не forward, которое разрешает доступ к всей сети из гостевой сети. Reflector имеет несколько (виртуальных) интерфейсов и собственный адрес в каждой подсети. Просматривая через avahi-browse, я вижу, что он отражает весь трафик на каждый интерфейс, который у него есть. Я думал, что именно это и есть смысл устройства отражателя. На его локальном интерфейсе (тот, который в гостевой сети) я могу получить доступ к reflector-у. [/quote] Да, отражатель может брать IP-адрес из каждой VLAN и отражать этот трафик. Но устройства-источник и получатель должны иметь возможность видеть друг друга, как отправитель и адресат. Правила input — это трафик, направленный самому маршрутизатору. Это может быть актуально для среды Unifi USG, где работает эта служба. Но в вашем случае нужно использовать правила forward. Я не дома, иначе выложил бы примеры. У меня, например, сеть Kids и Guest VLAN могут обнаружить Chromecast в моей основной сети и передавать на него контент. Мне нужно пересылать/принимать трафик с Kids/Guest (у меня это список адресов) на IP адреса Chromecast (их у меня несколько, поэтому тоже в списке). Возможно, у меня есть и обратные правила Chromecast > Kids/Guest, но точно не вспомню. «Просматривая avahi-browse, я вижу, что он отражает весь трафик на каждый интерфейс, который у него есть. Я думал, что именно это и есть смысл устройства отражателя» — думаю, это правильно, но всё равно нужно разрешить меж-VLAN взаимодействие. Ещё раз — многое зависит от того, как настроен ваш фаервол.

rkrisi

Guest

#11

03.07.2020 16:55:00

Да, у меня тоже есть список адресов с IP-адресами устройств Chromecast, и я добавил их в цепочку форварда, чтобы с любой сети можно было получить доступ к этим IP (дополнительных настроек там нет, всё просто пересылается на эти IP). Думаю, это то же самое, о чём ты говоришь (или нет?). Было бы здорово, если бы ты показал, как у тебя получилось это сделать. И чуть не забыл: я подключил телефон к гостевой сети, и он нашёл устройства Chromecast (кажется, здесь срабатывает какое-то кеширование, поэтому обнаружение не происходит каждый раз). Пока у меня не было правила для пересылки пакетов на IP Chromecast, я не мог подключиться к устройству (так что это логично).

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

Вот мои точные правила файрвола:
0 ;;; Разрешить установленные и связанные соединения
chain=input action=accept connection-state=established,related log=no log-prefix=""

1 ;;; Разрешить OpenVPN
chain=input action=accept protocol=tcp dst-port=1194 log=no log-prefix=""

2 ;;; Полный доступ VLAN_PRIVATE
chain=input action=accept in-interface-list=PRIVATE log=no log-prefix=""

3 ;;; Временное правило!
chain=input action=accept in-interface=vlan_iot log=no log-prefix=""

4 X chain=input action=accept in-interface=vlan_guest log=no log-prefix=""

5 ;;; Мультикаст IGMP
chain=input action=accept protocol=igmp in-interface-list=VLAN log=no log-prefix=""

6 ;;; Блокировать всё остальное
chain=input action=drop connection-state="" log=no log-prefix=""

7 ;;; Принять перенаправленные порты
chain=forward action=accept connection-state=new connection-nat-state=dstnat log=no log-prefix=""

8 ;;; Разрешить установленные и связанные соединения
chain=forward action=accept connection-state=established,related log=no log-prefix=""

9 ;;; Временное правило!
chain=forward action=accept in-interface=vlan_iot log=no log-prefix=""

10 ;;; Разрешить доступ к NAS
chain=forward action=accept dst-address=10.0.0.252 src-address-list=NAS log=no log-prefix=""

11 ;;; Разрешить стриминг в VLAN
chain=forward action=accept dst-address-list=Stream log=no log-prefix=""

12 ;;; Разрешить доступ в интернет только для VLAN
chain=forward action=accept connection-state=new in-interface-list=VLAN out-interface-list=WAN log=no log-prefix=""

13 ;;; Разрешить пересылку запросов из OpenVPN
chain=forward action=accept in-interface-list=PRIVATE log=no log-prefix=""

14 ;;; Блокировать всё остальное
chain=forward action=drop connection-state="" log=no log-prefix=""

rkrisi

Guest

#12

05.07.2020 18:47:00

Похоже, что на новом устройстве даже в моей приватной VLAN Chromecast не работают. В моей приватной VLAN всё доступно, и для отладки сейчас с сети IoT тоже разрешён весь трафик, но всё равно не получается заставить это работать. Я скачал Bonjour Browser, который показывает mDNS-трафик. В обеих сетях (Main и Guest) виден весь mDNS-трафик, и он может разрешать и показывать правильные mDNS-записи. Также сервисы, полностью зависящие от mDNS, работают корректно с самого начала (например, HomeKit, AirPlay, AirPrint (CUPS)). Значит, причина, по которой мои устройства Chromecast и Spotify Connect (HEOS) не работают нормально, скорее всего, в чём-то другом.

RackKing Guest	#13 0 06.07.2020 21:05:00 Извини, я забыл опубликовать правила для фильтров... Постараюсь заняться этим, как только доберусь до дома. Странно, что новое устройство не работает. Для чего вообще нужен этот igmp all?

rkrisi

Guest

#14

07.07.2020 09:51:00

Похоже, что некоторые устройства используют не только mDNS, но и IGMP для обнаружения других устройств. Даже Chromecast для Chrome указывает, что IGMP тоже необходим. Мои колонки Denon HEOS тоже требуют включения IGMP forwarding. И если посмотреть на это внимательнее, то именно это и не работает как надо. С mDNS, уверен, всё в порядке, а вот глядя на IGMP-пакеты в Wireshark, я не вижу ни одного пакета IGMP, который бы перенаправлялся с моего IoT VLAN в основную сеть…

rkrisi

Guest

#15

07.07.2020 23:07:00

Окей, возможно, я нашёл проблему, и может кто-то сможет помочь с правильной конфигурацией avahi reflector. Пересылка IGMP действительно нужна, но, судя по Wireshark, достаточно просто настроить IGMP Proxy, без заморочек с PIM. Проблема, похоже, в avahi-reflector, но точную причину я не знаю. Если я остановлю reflector, подожду немного, открою Spotify, а потом запущу reflector снова, то в списке устройств всё появляется корректно (даже Chromecast работает быстро и без проблем). Однако при перезапуске приложения Spotify устройства исчезают и не показываются, пока я снова не перезапущу reflector…

rkrisi

Guest

#16

08.07.2020 17:39:00

Наконец-то решил эту проблему! С точки зрения Mikrotik, всё было настроено правильно. Возможно, для некоторых устройств потребуется IGMP proxy, но PIM не нужен (хотя некоторые утверждают, что IGMP недостаточно, хоть в каждой инструкции и говорится, что используется именно IGMP), достаточно просто настроить простой IGMP-Proxy. Я перешёл с avahi на этот mdns reflector: https://github.com/kennylevinsen/mdns-repeater. Не знаю, в чём была проблема с avahi, ведь он частично работал: устройства Google Chromecast и вся техника Apple, как я уже говорил, функционировали нормально, но некоторые сервисы — нет. Вот почему я никогда не думал, что mDNS reflector работает неправильно: ведь некоторые вещи всё равно работали, да и просмотр mDNS-трафика показывал всё корректно. Однако после перехода на этот mdns reflector всё сразу заработало без проблем. К тому же теперь в каждом сервисе обнаружение работает быстрее. Есть более новая версия avahi-daemon (8.0), но у меня не было времени её собрать (пока недоступна через apt), возможно, она решит эти проблемы (но почему они вообще возникают — непонятно). В любом случае спасибо всем, кто пытался помочь! Было бы здорово, если бы Mikrotik добавил свой собственный mDNS reflector. Тогда всё сразу работало бы с первого раза, и не пришлось бы возиться с сторонними сервисами и устройствами.

chriscolden Guest	#17 0 12.08.2020 12:31:00 Спасибо. Я тоже никогда не задумывался, что avahi не работает как надо из-за того, что устройства появляются, а вот группы — нет. Думал, что это косяк Google. Перешёл сам и подсадил к другу mdns-repeater — теперь у обоих всё работает идеально. Ещё раз спасибо. Крис.

Читают тему

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