mDNS и Bonjour между VLAN: почему устройства умного дома перестают находить друг друга

Почему после VLAN всё «ломается»

Обычный IP-трафик между сетями можно разрешить маршрутизацией и firewall. Но многие устройства ищут друг друга не по заранее известному IP, а через локальное multicast-обнаружение.

Что такое mDNS

mDNS — Multicast DNS. Он позволяет устройствам разрешать имена и объявлять сервисы внутри локального сегмента без обычного DNS-сервера.

Ключевой момент: multicast link-local трафик предназначен для локального сегмента. Маршрутизатор обычно не пересылает его между VLAN автоматически.

Bonjour, zeroconf и mDNS — это одно и то же?

Почему одного firewall-правила недостаточно

Если просто разрешить UDP 5353 между двумя VLAN, это не всегда заставит устройства видеть друг друга. Multicast-пакеты не обязаны пересылаться маршрутизатором между L3-сегментами.

Поэтому обычно нужен специальный сервис:

• mDNS reflector;
• mDNS repeater;
• Bonjour gateway;
• Avahi reflector;
• аналогичная функция в контроллере UniFi, OpenWrt или другом шлюзе.

Reflector и repeater: в чём разница

Для пользователя важнее не название функции, а то, чтобы она работала только между нужными VLAN и не превращала сеть в один большой multicast-домен.

Типовая безопасная схема

mDNS можно отражать между Main ↔ IoT и Server ↔ IoT, но это не означает, что IoT должен иметь право инициировать любые соединения в Main.

Правильная логика firewall

1. Разрешить established/related. Ответный трафик уже разрешённых соединений.
2. Разрешить Home Assistant → IoT. Только нужные протоколы и адреса.
3. Ограничить IoT → Main. По умолчанию запрет, кроме явно нужных сервисов.
4. Включить mDNS reflector только между нужными VLAN.
5. Не открывать Guest в Main. Даже если гостям нужен Chromecast, лучше продумать отдельный сценарий.

Home Assistant и mDNS

Home Assistant использует zeroconf для автоматического обнаружения ряда интеграций. Если HA находится в отдельном серверном VLAN, а устройства — в IoT, discovery может перестать работать.

При этом ручное добавление по IP иногда продолжает работать, потому что unicast-маршрутизация разрешена. Это типичный признак того, что проблема именно в discovery, а не в общей связности между сегментами.

ESPHome между VLAN

ESPHome-устройства могут успешно работать по IP даже без mDNS, если Home Assistant знает их адрес. Но обнаружение по имени и автоматический zeroconf могут не работать между VLAN без reflector.

Matter и VLAN

Matter использует локальные механизмы discovery и commissioning, поэтому слишком жёсткая сегментация без mDNS/IPv6 может приводить к проблемам при добавлении устройств.

Особенно важно помнить, что Matter активно использует IPv6. Если между VLAN неправильно настроена IPv6-маршрутизация или фильтрация, один только mDNS reflector может не решить проблему.

AirPlay и AirPrint

AirPlay и AirPrint хорошо демонстрируют природу проблемы: устройство физически доступно по IP, но не появляется в списке, потому что клиент не видит его Bonjour-анонс.

После включения mDNS gateway принтер или Apple TV может появиться автоматически, но сами рабочие порты сервиса всё равно должны быть разрешены firewall.

Chromecast сложнее обычного mDNS

Для Chromecast одного mDNS может быть недостаточно. В зависимости от поколения устройств и клиента используются дополнительные multicast- и unicast-соединения.

Поэтому сценарий «виден, но не кастит» обычно означает, что discovery заработал, а рабочий трафик между VLAN всё ещё блокируется.

Почему не стоит отражать mDNS во все VLAN

• увеличивается multicast-шум;
• гостевые устройства начинают видеть лишние сервисы;
• упрощается разведка сети;
• сложнее понимать, какие сегменты реально связаны;
• можно случайно опубликовать принтер, NAS или медиасервис туда, где он не нужен.

Keenetic

На Keenetic задача зависит от версии KeeneticOS и конкретной архитектуры сегментов. Если mDNS между сегментами не поддерживается штатно в нужном сценарии, часто надёжнее строить discovery через отдельный сервис или не полагаться на mDNS там, где можно использовать фиксированные адреса.

При этом обычная межсегментная маршрутизация и firewall должны настраиваться отдельно от discovery.

UniFi

В UniFi Network есть функции mDNS/Bonjour для пересылки discovery между сетями. Но включать их стоит только для нужных VLAN.

После этого отдельно проверяют firewall rules и доступ к фактическим портам сервисов.

OpenWrt и Avahi

В OpenWrt популярный вариант — Avahi reflector или специализированный mDNS repeater. Avahi может отражать mDNS между интерфейсами, но интерфейсы нужно выбирать осознанно.

Не стоит включать reflector на WAN или на все интерфейсы подряд.

MikroTik

На MikroTik mDNS между VLAN традиционно решают через дополнительные механизмы или внешние сервисы, поскольку обычная L3-маршрутизация multicast link-local не заменяет Bonjour gateway.

Если discovery критичен, полезно заранее проверить возможности именно используемой версии RouterOS и архитектуру сети.

Как диагностировать проблему

1. Проверьте обычный ping/IP-доступ. Если IP доступен, маршрутизация работает.
2. Проверьте сервис вручную. Например, открыть веб-интерфейс или API по IP.
3. Проверьте UDP 5353. Есть ли mDNS-пакеты в каждом VLAN.
4. Включите reflector только между двумя нужными сетями.
5. Посмотрите, появилось ли устройство в discovery.
6. Если устройство видно, но сервис не работает — проверяйте рабочие порты firewall.

mDNS не заменяет обычный DNS

mDNS предназначен для локального discovery. Для стабильной инфраструктуры серверов, NAS, NVR и Home Assistant лучше использовать нормальный локальный DNS или фиксированные DHCP-reservation.

Не стоит строить всю домашнюю сеть только на именах .local.

Типичные ошибки

• разрешить UDP 5353 в firewall, но не включить reflector;
• включить reflector между всеми VLAN без ограничений;
• открыть IoT → Main целиком ради одного Chromecast;
• забыть про IPv6 в Matter-сценариях;
• полагаться только на mDNS вместо DHCP reservation;
• считать, что discovery = доступ к сервису;
• разрешить Guest видеть все Bonjour-сервисы;
• включить Avahi reflector на WAN.