Шлюз mDNS Proxy в режиме Off/Custom не мешает шлюзу рассылать mDNS в изолированные/исключённые VLAN.

Шлюз mDNS Proxy в режиме Off/Custom не мешает шлюзу рассылать mDNS в изолированные/исключённые VLAN., UniFi Network

bennobroer

Guest

08.06.2026 13:44:00

EnvironmentGateway: UDM Pro MaxUniFi OS: 5.1.15 (Official release channel)UniFi Network: 10.4.57 (Official release channel)Firewall: Zone-Based FirewallРезюмеПри настройке Settings → Networks → Gateway mDNS Proxy = Off шлюз всё равно периодически отправляет mDNS-трафик обнаружения сервисов (UDP 5353) в VLAN, изолированный от остальной сети файрволом. Этот трафик перечисляет типы mDNS-сервисов и именованные экземпляры сервисов, которые исходят от устройств из других VLAN. Настройка ни на что не влияет.Проверено и воспроизведено при Off, при Custom (VLAN-скоуп настроен так, что изолированный VLAN не выбран) и после полной перезагрузки шлюза. Ничего из этого не помогает.Ожидаемое поведениеСогласно документации («Off полностью останавливает ретрансляцию mDNS-трафика») и опции Custom VLAN-скоупа, VLAN, исключённый из скоупа mDNS-прокси, не должен получать никакого mDNS-трафика, исходящего из других сетей.Фактическое поведениеСобственный интерфейс шлюза в изолированном VLAN отправляет mDNS PTR-запросы на 224.0.0.251:5353 примерно каждые 60 секунд, перечисляя типы сервисов и именованные экземпляры, принадлежащие устройствам из других VLAN. Пассивный хост в изолированном VLAN, который сам ничего не отправляет, всё равно получает этот непрерывный перечень.Шаги для воспроизведенияСоздать VLAN B и изолировать его (никаких меж-VLAN разрешений в/из других зон; только интернет).Установить Gateway mDNS Proxy = Off (также воспроизводится с Custom + VLAN B не выбран).На хосте в VLAN B выполнить: sudo tcpdump -i <iface> -n 'host <gateway-ip-on-B> and port 5353'.Наблюдать: примерно каждые 60 с шлюз отправляет mDNS PTR-запросы, перечисляющие сервисы из других VLAN. Сохраняется после перезагрузки шлюза.Наблюдаемый трафик (очищенный)Источник — IP-адрес интерфейса шлюза в изолированном VLAN; назначение — mDNS-мультикаст:<gw-ip>.5353 > 224.0.0.251.5353: PTR (QM)? _services._dns-sd._udp.local.
<gw-ip>.5353 > 224.0.0.251.5353: PTR (QM)? _airplay._tcp.local.
<gw-ip>.5353 > 224.0.0.251.5353: PTR (QM)? _raop._tcp.local.
<gw-ip>.5353 > 224.0.0.251.5353: PTR (QM)? _hap._tcp.local.
<gw-ip>.5353 > 224.0.0.251.5353: PTR (QM)? _ipp._tcp.local.
<gw-ip>.5353 > 224.0.0.251.5353: PTR (QM)? <redacted-hostname>._companion-link._tcp.local.
...плюс дополнительные вендорские типы сервисов и именованные экземпляры устройств из
других VLAN (отредактировано).
Первопричина (из read-only-инспекции на устройстве)Три процесса слушают UDP 5353 на шлюзе (ss -lunp):0.0.0.0:5353 users:(("avahi-daemon", ...))
0.0.0.0:5353 users:(("unifi-core", ...)) # два сокета
avahi-daemon — его рефлектор корректно отключён (/etc/avahi/avahi-daemon.conf → [reflector] enable-reflector=no). НЕ источник.unifi-core — использует Node.js-библиотеку bonjour-service (/usr/share/unifi-core/app/node_modules/bonjour-service/), привязанную к 0.0.0.0:5353, т.е. ко всем интерфейсам.ubntmdnsd — запускается каждую минуту через /etc/cron.d/mdns-job:* * * * * root /usr/sbin/ubntmdnsd -t10 -f /tmp/mdns_services.json -c /data/udapi-config/mdns.cache -s -j -w
выполняя сканирование обнаружения сервисов по всем интерфейсам.Настройка Gateway mDNS Proxy управляет только avahi-daemon (чей рефлектор и так уже отключён). ubntmdnsd (cron, каждую минуту) и bonjour-service из unifi-core сканируют все интерфейсы независимо от настройки прокси и независимо от Custom VLAN-скоупа, поэтому они продолжают отправлять mDNS в исключённые/изолированные VLAN. Именно поэтому Off, Custom и перезагрузка не дают эффекта — они действуют на другой компонент, а не на тот, что производит трафик. Периодичность всплесков ~60 с точно соответствует ежеминутному cron-заданию.Контролируемый тест подтверждает, что утечка идёт от шлюза, а не от хоста: когда собственный mDNS изолированного хоста полностью заблокирован на его локальном файрволе, ежеминутные всплески перечисления от шлюза продолжаются без изменений.Влияние на безопасностьVLAN, изолированный на L3 файрволом, всё равно получает — незапрошенно и непрерывно — полное перечисление экземпляров mDNS-сервисов (имена хостов, названия сервисов, читаемые метки зон/комнат) из остальной сети. Недоверенный или скомпрометированный хост в «изолированном» VLAN может пассивно составить карту инвентаря устройств других VLAN, не отправив ни единого пакета — что сводит на нет заявленную цель изоляции и контроля mDNS-прокси.Предлагаемое исправлениеСделать так, чтобы настройка Gateway mDNS Proxy (Off и Custom VLAN-скоуп) также управляла ubntmdnsd и bonjour-service из unifi-core, чтобы никакое mDNS-обнаружение не выполнялось на VLAN, исключённых из скоупа прокси, и не отправлялось в них. Например, ограничить набор интерфейсов ubntmdnsd и bonjour-service настроенным скоупом или пропускать cron-сканирование на исключённых интерфейсах.

LineNoise

Guest

13.09.2026 06:32:00

Похоже, это и есть корень проблемы с AppleTV, которую мы сейчас наблюдаем при использовании UDM Pros в паре со старым wifi-оборудованием Amplifi, работающим в режиме моста с отключёнными функциями IGMP. В частности, мы видим, что AppleTV по wifi работают как положено с другими беспроводными устройствами. AppleTV по проводу работают как положено с проводными устройствами. Но проблемы с mDNS, охватывающим проводную и беспроводную сети, быстро возникают, как только AppleTV перезагружаются для обновления ПО. Переключение mDNS Proxy в Off и обратно в auto или custom восстанавливает связь один раз, но как только любая AppleTV перезагружается, она отваливается с другой стороны сети. Даунгрейдом не занимался. Больше мороки, чем оно того стоит ради этой головной боли.

vanpatrick

Guest

30.08.2026 07:29:00

@UI-Team Добавляю точку данных, которая расширяет эту тему на UniFi OS 5.1.31, где поведение изменилось — и теперь ещё и засоряет логи зонального файрвола. Окружение: UCG-Fiber, UniFi OS 5.1.31, Network 10.5.67, зональный файрвол, изолированный IoT VLAN (политика блокировки IoT-to-Gateway-zone с конкретными разрешениями, включая разрешение mDNS, ограниченное портами 5353-to-5353). Наблюдается после автообновления с 5.1.19 до 5.1.31: помимо перечисления multicast, описанного выше, шлюз теперь также выполняет mDNS-запросы одноразового типа, исходящие с ЭФЕМЕРНЫХ портов. Видимый симптом в моей сети: примерно каждые ~60 секунд 40+ IoT-устройств (Meross, LIFX, ecobee, Aqara, Sensibo, SwitchBot, Hue, Apple TV...) отвечают в течение одной и той же секунды — unicast UDP, порт источника 5353, на случайные эфемерные порты назначения на IP VLAN-интерфейса шлюза, размер полезной нагрузки варьируется по устройствам (92-229 байт). Поскольку зональная политика блокирует IoT-to-Gateway, эти ответы создавали примерно 100K+ записей блокировки файрвола в день. Тайминг точно совпадает с этой строкой в примечаниях к выпуску Cloud Gateways 5.1.31: "Fixed an issue where remote mDNS hosts could not be discovered." Одноразовые запросы с эфемерных портов — это стандартный способ вызвать unicast mDNS-ответы (RFC 6762 раздел 5.1), так что это выглядит как намеренное изменение обнаружения — но, что согласуется с находками OP, оно работает независимо от выбора области прокси и генерирует ответный трафик, которому не могут соответствовать ранее существовавшие правила файрвола, построенные для классического mDNS 5353-to-5353. Обходной путь для потока логов (это только успокаивает логи файрвола — это не меняет поведение шлюза при зондировании): моё правило "Allow IoT mDNS to Gateway" было ограничено портами 5353-to-5353 на обоих концах, чему новые ответы больше не соответствуют. Изменение только соответствия ПОРТА НАЗНАЧЕНИЯ правила на список портов 1024-65535 (порт источника по-прежнему ограничен 5353, назначение по-прежнему только IP шлюза, только UDP) немедленно снизило ~3,650 блокировок в час до нуля, при этом привилегированные порты шлюза (53, 67, 161 и т.д.) остаются покрытыми политикой блокировки. +1 к предложенному OP исправлению: настройка Gateway mDNS Proxy (Off / Custom VLAN scope) должна управлять ВСЕМИ mDNS-компонентами на стороне шлюза — ubntmdnsd, bonjour-service и тем компонентом, который выполняет новое одноразовое обнаружение удалённых хостов. Также было бы полезно, если бы примечания к выпуску указывали на изменения поведения обнаружения, которые предсказуемо взаимодействуют с зональными файрволами.

LordofAgents

Guest

23.08.2026 19:18:00

@UI-Team Я тоже могу подтвердить эту проблему на UDR7. Я также использую сетевые функции как изоляцию, как заявлено, так что сейчас это утечка в этой изоляции. Не могли бы вы, пожалуйста, сказать нам, известно ли об этом и когда это будет исправлено?Спасибо!

sh-jacin

Guest

12.08.2026 04:50:00

@UI-Team Видим ровно ту же проблему, и она устраивает бардак с нашими принтерами (мы школа), и каждый принтер отображается на их маках по 2–10 раз.Окружение:- Шлюз: UDM-SE- Linux SH-Dream-Machine-SE, ядро 4.19.152-ui-alpine- mDNS-прокси на шлюзе: Custom (2 сети в области действия: Staff/VLAN 20, Student/VLAN 10; категории: Printers, AirPlay)Кратко:Это та же проблема, о которой сообщали здесь. Мы наблюдаем её независимо на своём UDM-SE и можем добавить чистое воспроизведение.Что мы выяснили:- ss -lunp на шлюзе показывает, что avahi-daemon и unifi-core оба слушают UDP 5353. Рефлектор avahi-daemon отключён (enable-reflector=no), что согласуется с тем, что он не является источником.- unifi-core держит 10 отдельных сокетов на 0.0.0.0:5353 — привязанных ко всем интерфейсам, без видимой осведомлённости о VLAN/области действия.- /etc/cron.d/mdns-job запускает /usr/sbin/ubntmdnsd -t10 -f /tmp/mdns_services.json -c /data/udapi-config/mdns.cache -s -j -b -u каждые 60 секунд, безусловно, по всем интерфейсам.- Наш mDNS-прокси на шлюзе настроен на Custom, с областью действия только Staff+Student. VLAN вне этой области (Management, VLAN 50) должен получать ноль межвланового mDNS от шлюза.Воспроизведение:tcpdump -i br50 -n "udp port 5353 and src host 10.10.50.1"В течение 70 секунд зафиксировано:10.10.50.1.38818 > 224.0.0.251.5353: PTR (QU)? _services._dns-sd._udp.local.br50 — это Management, не входит в область действия Custom mDNS Proxy. Собственный интерфейс шлюза на этом VLAN всё равно отправляет трафик обнаружения mDNS.Влияние: эта настройка ограничения по VLAN для нас — контроль безопасности/изоляции (Management/инфраструктурный VLAN не должен получать никакой трафик, исходящий из других VLAN), и она не делает то, что описывают UI и документация. Она также напрямую вызвала шторм самоконфликта имён принтеров (призрачные записи Bonjour, размножающиеся до сотен), который сломал печать в нескольких классах в нашу первую неделю возвращения. Изменение области действия на Custom, которое мы сделали, чтобы это «починить», никак не повлияло на реальный источник трафика.Просьба: может ли Ubiquiti подтвердить, что это известная проблема, отслеживаемая по указанному выше сообществу, и есть ли ETA или поддерживаемый обходной путь, не требующий ручного отключения cron-задачи ubntmdnsd (которая, как мы понимаем, откатится при прошивке

aking01

Guest

23.06.2026 08:01:00

Я вижу точно такое же на UCG-Fiber. Похоже, это вызывает штормы multicast в моей локальной сети. Шлюз также отправляет трафик обнаружения в мой WAN. Я вижу устройства за пределами моей сети, которые стучатся на мой WAN-интерфейс через 10001. Невозможно заблокировать исходящие запросы от шлюза, так как это не разрешено в правилах фаервола.

Oursmarthome Guest	#7 22.06.2026 13:48:00 @UI-Team Последнее обновление с моей стороны: Теперь я могу стабильно воспроизвести проблему и нашёл рабочее обходное решение. Полное отключение cron-задачи ubntmdnsd останавливает mDNS-трафик обнаружения, генерируемый шлюзом, на VLAN 3. В захватах пакетов больше не видно mDNS-трафика, исходящего от интерфейса шлюза. Остаётся только mDNS-трафик, генерируемый локальными устройствами. Самое главное — моя система SMA Sunny Island с тех пор работает полностью стабильно. До отключения ubntmdnsd я сталкивался с повторяющимися сбоями связи и отключениями. После его отключения больше не было никаких ошибок связи. Это явно указывает на то, что ubntmdnsd генерирует mDNS-трафик обнаружения на VLAN, которые исключены из конфигурации Gateway mDNS Proxy, и даже когда Gateway mDNS Proxy установлен в положение OFF. Может ли кто-нибудь из Ubiquiti подтвердить, является ли такое поведение намеренным или это известный баг, который будет исправлен в будущем релизе? Спасибо.

Читают тему (гостей: 1)