Home Assistant и IoT в разных VLAN: почему пропадают устройства и как настроить сеть

Зачем вообще выносить IoT в отдельный VLAN

Умный дом постепенно превращается в полноценную компьютерную сеть. В ней появляются Wi-Fi-реле, телевизоры, роботы-пылесосы, кондиционеры, камеры, видеодомофоны, шлюзы, зарядные станции, инверторы, ESPHome-устройства и другое оборудование.

Давать каждому такому устройству свободный доступ к рабочим компьютерам, NAS, административным интерфейсам и другим важным ресурсам не всегда разумно.

NIST прямо рекомендует владельцам домашних и небольших корпоративных сетей по возможности сегментировать сеть и размещать IoT-устройства с повышенным риском отдельно от обычных вычислительных устройств. Цель такой сегментации состоит в ограничении возможных последствий компрометации одного IoT-устройства.

Практичная схема сети с Home Assistant

Для дома с Home Assistant, камерами и несколькими Wi-Fi-точками можно использовать такую структуру:

Количество VLAN необязательно должно быть таким большим. Для квартиры зачастую достаточно Main, IoT и Guest.

В более сложном доме имеет смысл отдельно вынести камеры и сетевое оборудование.

Почему после переноса устройства в другой VLAN Home Assistant перестает его видеть

Представим:

Маршрутизатор умеет передавать обычный IP-трафик между сетями. Если правила firewall разрешают соединение, Home Assistant может напрямую обратиться к адресу 192.168.30.25.

Но автоматическое обнаружение может при этом не работать.

Причина в том, что многие устройства не сообщают свой адрес через обычный DNS-сервер. Они объявляют о себе посредством локальных механизмов discovery.

Home Assistant использует в том числе:

• mDNS / Zeroconf;
• SSDP;
• DHCP discovery;
• HomeKit discovery;
• Bluetooth;
• другие механизмы конкретных интеграций.

Официальная документация Home Assistant подтверждает использование mDNS/Zeroconf и SSDP для обнаружения сетевых устройств.

mDNS и Zeroconf: главная причина проблем между VLAN

mDNS, Multicast DNS, позволяет устройствам обнаруживать друг друга в локальной сети без обычного DNS-сервера.

Например, Home Assistant сам публикует в локальной сети сервис:

Поэтому приложение может автоматически обнаружить экземпляр Home Assistant, не заставляя пользователя вводить IP-адрес вручную.

Проблема заключается в том, что mDNS по своей природе ориентирован на локальный сетевой сегмент и обычно не маршрутизируется между VLAN как обычный unicast-трафик.

Что делает mDNS Reflector или Proxy

Маршрутизатор или отдельный сервис принимает mDNS-запрос в одном VLAN и повторно передает его в другом.

Так телефон или Home Assistant может обнаружить устройство, которое физически находится в другом VLAN.

SSDP: еще один протокол обнаружения

SSDP используется UPnP-оборудованием и рядом сетевых интеграций. Home Assistant также умеет автоматически запускать настройку интеграций по данным SSDP.

Поэтому возможна ситуация:

Это не противоречие. Unicast IP и multicast discovery являются разными механизмами.

Если интеграция позволяет указать IP вручную, устройство иногда можно подключить без межсетевого discovery. Но для некоторых протоколов этого недостаточно.

Какие правила firewall нужны для Home Assistant и IoT

Главная ошибка при сегментации состоит в одном из двух крайних подходов: либо разрешить IoT полный доступ в основную сеть, либо полностью запретить все связи.

Практичнее использовать принцип минимально необходимого доступа.

Конкретные порты зависят от интеграции. Нет универсального правила вида «открыть один порт Home Assistant и все заработает».

Некоторым интеграциям требуется инициировать соединение от Home Assistant к устройству, другим устройство само открывает соединение к серверу, а третьим дополнительно необходим multicast.

Нужно ли разрешать IoT доступ к Home Assistant

Не всегда.

Если Home Assistant самостоятельно подключается к устройству по его IP, часто достаточно разрешить:

и оставить новое соединение:

запрещенным.

Stateful firewall при этом пропустит ответ устройства на соединение, инициированное Home Assistant.

Но существуют интеграции, где устройство само подключается к Home Assistant, использует callback, webhook, MQTT или другой механизм. Тогда потребуется дополнительное правило.

Современные рекомендации NIST также сводятся к пониманию нормального сетевого поведения IoT-устройства и разрешению только необходимой коммуникации.

Matter и VLAN: здесь все сложнее

Matter нельзя рассматривать как обычное Wi-Fi-устройство, к которому достаточно открыть TCP-порт между двумя IPv4-подсетями.

Matter работает поверх IP и использует IPv6. Для обнаружения устройств используется mDNS.

Официальная документация Home Assistant прямо предупреждает: Matter зависит от локального IPv6 и mDNS multicast.

Почему Matter может перестать работать после сегментации

Причинами могут стать:

• отключенный IPv6;
• IPv6 не проходит между необходимыми сегментами;
• mDNS не распространяется;
• multicast filtering;
• неправильно настроенный IGMP snooping;
• изоляция Wi-Fi-клиентов;
• Thread Border Router расположен в другом недоступном сегменте;
• слишком сложная VLAN-топология.

Что рекомендует Home Assistant

Для устранения проблем разработчики рекомендуют держать Wi-Fi Matter-устройства, включая Thread Border Router, в том же VLAN, что и Home Assistant.

Для Thread-устройств должен существовать хотя бы один доступный Thread Border Router, подключенный к LAN Home Assistant.

Кроме того, IPv6 в Home Assistant должен быть включен.

Нужно ли поэтому отказаться от VLAN?

Нет. Но если Matter является значительной частью системы, сегментацию необходимо проектировать с пониманием IPv6 и multicast.

Схема «создам IoT VLAN, запрещу все между сетями и потом открою пару TCP-портов» для Matter часто не работает.

IP-камеры в отдельном VLAN

Камеры являются одним из лучших кандидатов для отдельного сетевого сегмента.

Для полностью локальной системы можно построить схему:

При этом самим камерам в некоторых системах вообще не требуется доступ в интернет.

Можно разрешить:

• NVR → камеры;
• Home Assistant → камеры или NVR;
• Main → NVR;

и запретить:

• камеры → Main;
• камеры → Management;
• камеры → интернет, если облачные функции не нужны.

Как это выглядит в UniFi

UniFi Gateway поддерживает mDNS Proxy между VLAN.

В актуальных версиях доступны режимы:

• Auto;
• Off;
• Custom.

Custom позволяет выбрать конкретные сети и типы mDNS-сервисов, которые необходимо пересылать.

Например, вместо передачи абсолютно всех mDNS-сервисов между Main и IoT можно оставить только нужные.

Multicast и Wi-Fi

Ubiquiti отдельно предупреждает, что чрезмерный broadcast и multicast может расходовать заметную часть Wi-Fi airtime.

Поэтому идея «включить все multicast-функции везде, чтобы точно работало» тоже не является оптимальной.

Сначала следует определить, каким устройствам действительно требуется discovery, а затем разрешать его между соответствующими сетями.

Как это реализовано в TP-Link Omada

Omada Controller также поддерживает пересылку mDNS между VLAN. Функция называется mDNS Repeater / Bonjour Service.

Можно задать:

• Client VLAN;
• Service VLAN;
• конкретный mDNS service ID.

Таким образом, например, пользовательская сеть может обнаруживать сервис в IoT VLAN без полного объединения двух подсетей.

Типовые ошибки при VLAN для Home Assistant

Home Assistant не видит устройство в другом VLAN: алгоритм диагностики

1. Определите IP устройства. Убедитесь, что оно действительно находится в ожидаемом VLAN.
2. Проверьте маршрутизацию. Может ли Home Assistant вообще обратиться к IP устройства?
3. Проверьте firewall. Не блокируется ли соединение между Servers и IoT?
4. Определите способ discovery. Использует ли интеграция mDNS, SSDP, DHCP или другой протокол?
5. Проверьте mDNS. Настроен ли reflector/proxy между необходимыми VLAN?
6. Попробуйте ручное добавление. Если интеграция позволяет указать IP, это поможет отделить проблему discovery от проблемы управления.
7. Для Matter проверьте IPv6. В Home Assistant IPv6 должен быть включен, а локальный multicast не должен блокироваться.
8. Проверьте Wi-Fi isolation. Client Isolation может полностью изменить локальную доступность устройств.
9. Проверьте multicast optimization. Некоторые настройки «оптимизации» multicast дают обратный эффект для систем умного дома.
10. Посмотрите журналы Home Assistant. Ошибка connection timeout и отсутствие discovery являются разными проблемами и требуют разного поиска причины.

Какую схему я считаю наиболее практичной

Для большинства домов нет необходимости создавать десять VLAN. Важно не количество сетей, а понятные границы доверия.

Home Assistant можно разместить либо в отдельной серверной сети, либо в доверенном сегменте и предоставить ему выборочный доступ к IoT.

При наличии большого количества Matter-устройств схему необходимо отдельно проверить с точки зрения IPv6, mDNS и Thread Border Router. Иногда более простая топология дает более надежный результат.

Вывод

Разделить компьютеры, камеры и IoT по VLAN технически несложно. Сложность начинается тогда, когда устройства должны продолжать обнаруживать друг друга и обмениваться локальными данными.

Home Assistant использует mDNS/Zeroconf, SSDP и другие механизмы discovery, поэтому обычного разрешения IP-трафика между двумя подсетями иногда недостаточно.

Для Matter ситуация еще чувствительнее: нужны локальный IPv6, mDNS и корректная работа multicast. Поэтому слишком агрессивная сегментация может привести к нестабильному commissioning и пропаданию устройств.

Практичная стратегия состоит не в том, чтобы «запретить все» или, наоборот, разрешить весь трафик между VLAN, а в том, чтобы определить реальные сетевые связи каждого класса устройств и открыть только необходимые.