Наличие в локальной сети IP-адресов, которые невозможно идентифицировать, является распространенной проблемой для энтузиастов, управляющих собственным сервером или умным домом. В данном случае под подозрением оказались три адреса: 192.168.4.22, 192.168.4.44 и 192.168.4.81. Устройств не было в системе Home Assistant, они не имели имен хостов и PTR-записей. Попытка использовать сервер Technitium DNS для отслеживания запросов провалилась, так как система находилась в процессе настройки высокой доступности и выдавала ошибку {«error»:»fetch failed»}.
Использование виртуальной машины как сетевого зонда
Для сканирования сети можно задействовать любое устройство на Linux с установленным curl, включая Raspberry Pi или виртуальные машины (LXC). В данном примере использовалась ВМ Home Assistant OS, работающая на Proxmox с включенным гостевым агентом QEMU. Это позволило получить доступ к оболочке в сегменте локальной сети с помощью цепочки: сессия в облаке — API Proxmox — гостевой агент — shell на LAN. Команда qm guest exec [номер ВМ] — ping -c 2 ip.address позволяет отправлять запросы изнутри ВМ, имитируя положение устройства в сети.
Принудительное обнаружение устройств в режиме энергосбережения
Первичная проверка через ping и ARP-таблицу оказалась малоэффективной. Многие Wi-Fi-устройства в режиме энергосбережения игнорируют ICMP-запросы. Чтобы их «разбудить», необходимо инициировать попытку TCP-соединения. Комбинация команды curl -s -m 2 http://192.168.4.44/ и последующий вызов ip neigh show 192.168.4.44 позволяет принудительно активировать устройство и получить его MAC-адрес в таблице соседей. Таким образом удалось подтвердить, что устройства 192.168.4.44 и 192.168.4.81 на самом деле активны.
Анализ открытых портов с помощью кодов ответа curl
Если в системе отсутствуют специализированные инструменты типа nmap или netcat, можно использовать коды завершения curl для сканирования портов. Код 7 означает отказ в соединении, 28 — превышение времени ожидания, а иные значения свидетельствуют о том, что сервис ответил. Для адреса 192.168.4.22 была проверена серия портов (7000, 8008, 8009, 8443, 5555, 6668). Выяснилось, что порт 8009 соответствует протоколу Google Cast, а 7000 — AirPlay.
Идентификация устройств через открытые API
Многие современные медиаустройства предоставляют данные о себе через неавторизованные точки доступа. Запрос curl http://192.168.4.22:8008/setup/eureka_info вернул имя устройства «Office TV», сборку Google Cast 3.72.446070 и уникальный идентификатор SSDP UDN. Дополнительная проверка порта 7000 через команду strings подтвердила наличие программного обеспечения «TCL», «Android» и «Smart TV Pro» с датой прошивки 11 марта 2026 года. Эти данные полностью совпали с записями в Home Assistant.
Анализ OUI для определения производителя
Для устройств без открытых портов, которые не взаимодействуют с Home Assistant напрямую, единственным идентификатором остается MAC-адрес. Первые три байта (OUI) указывают на производителя. Если локальные базы данных, такие как пакет Python netaddr, не содержат актуальной информации (ошибка NotRegisteredError), следует использовать онлайн-ресурсы, например maclookup.app. Это помогает выявить устройства, работающие через облачные протоколы, такие как Smart Life (Tuya). Несмотря на все усилия, некоторые устройства, например с OUI, зарегистрированным на Part II Research, могут оставаться неопознанными, так как идентификатор производителя в MAC-адресе не всегда прямо указывает на конкретную модель или назначение оборудования.
Особенности работы с сетевым зондом на базе HAOS
Важно учитывать, что оболочка (shell) в Home Assistant OS — это урезанная версия BusyBox. В ней отсутствуют такие привычные инструменты, как Python 3, а команда nc (netcat) работает нестабильно и часто не сообщает об успешном соединении даже в том случае, если порт достоверно открыт. Попытки использовать netcat для диагностики в этой среде могут привести к ложноотрицательным результатам, поэтому ставка на curl и анализ кодов возврата является более надежной стратегией при работе с «молчаливыми» устройствами.
Детализация процесса идентификации
В ходе сканирования порта 7000 на устройстве 192.168.4.22 выяснилось, что при запросе команда вернула код 0, в то время как порты 8009 и 8443 выдали код 52, означающий пустой ответ от сервера. Это подтвердило, что на этих портах действительно запущены службы (Google Cast и AirPlay), готовые к коммуникации. При обращении к эндпоинту /setup/eureka_info через порт 8008 удалось получить JSON-ответ, содержащий не только имя «Office TV», но и детальный SSDP UDN (329f5c1c-907b-2cff-d3e1-f3a9ebb94f94), который стал ключом к сопоставлению устройства с реестром Home Assistant, где оно числилось как media_player.office_tv.
После идентификации «офисного телевизора» проверка через настройки самого устройства подтвердила, что MAC-адрес полностью совпадает, хотя IP-адрес изменился из-за работы DHCP-сервера. Этот случай еще раз доказывает, что IP-адреса являются крайне ненадежными идентификаторами, и для долгосрочного отслеживания техники в локальной сети критически важно опираться на аппаратные MAC-адреса.
Анализ устройств с закрытыми портами
Для оставшихся двух устройств (192.168.4.44 и 192.168.4.81) сканирование около 35 портов, включая 5555 (протокол ADB) и 6668 (локальный протокол Tuya), не принесло результатов: все попытки соединения были либо отклонены, либо отфильтрованы. Шаблонный поиск по всем 14 устройствам в реестре Home Assistant также не дал совпадений. Это подтвердило, что данные гаджеты работают исключительно в режиме клиентов, взаимодействуя с облаком напрямую.
Проблемы с базами данных OUI
Попытка идентификации через локальный пакет netaddr для префикса 2890554 завершилась ошибкой NotRegisteredError. Выяснилось, что этот блок OUI принадлежит TCL и был зарегистрирован только в апреле 2025 года, поэтому стандартные офлайн-базы IEEE в системе его не распознавали. Это распространенная ловушка: вендоры регистрируют новые блоки постоянно, и использование устаревших локальных словарей приводит к ошибкам. Переход на онлайн-сервисы вроде maclookup.app является необходимым условием для работы с современным сетевым оборудованием.
Специфика «скрытых» устройств
Особое внимание привлек адрес 192.168.4.44. Данные приложения eero показали, что устройство подключается только к диапазону 2.4 ГГц и работает через кухонный узел сети. Первое подключение было зафиксировано 22 июня. Интересно, что OUI этого устройства указывает на компанию Part II Research (известную по бренду Macally), что вызывает вопросы, так как они не занимаются производством умных устройств для 2.4 ГГц. Это напоминает о важном правиле: OUI указывает лишь на того, кто зарегистрировал блок адресов, а не обязательно на реального производителя конечного устройства. В итоге, несмотря на все приложенные усилия, три устройства в сети остались «загадками», что является вполне допустимым для сложного домашнего окружения.
Особенности работы с сетевым зондом на базе HAOS
Важно учитывать, что оболочка (shell) в Home Assistant OS — это урезанная версия BusyBox. В ней отсутствуют такие привычные инструменты, как Python 3, а команда nc (netcat) работает нестабильно и часто не сообщает об успешном соединении даже в том случае, если порт достоверно открыт. Попытки использовать netcat для диагностики в этой среде могут привести к ложноотрицательным результатам, поэтому ставка на curl и анализ кодов возврата является более надежной стратегией при работе с «молчаливыми» устройствами.
Детализация процесса идентификации
В ходе сканирования порта 7000 на устройстве 192.168.4.22 выяснилось, что при запросе команда вернула код 0, в то время как порты 8009 и 8443 выдали код 52, означающий пустой ответ от сервера. Это подтвердило, что на этих портах действительно запущены службы (Google Cast и AirPlay), готовые к коммуникации. При обращении к эндпоинту /setup/eureka_info через порт 8008 удалось получить JSON-ответ, содержащий не только имя «Office TV», но и детальный SSDP UDN (329f5c1c-907b-2cff-d3e1-f3a9ebb94f94), который стал ключом к сопоставлению устройства с реестром Home Assistant, где оно числилось как media_player.office_tv. После идентификации «офисного телевизора» проверка через настройки самого устройства подтвердила, что MAC-адрес полностью совпадает, хотя IP-адрес изменился из-за работы DHCP-сервера. Этот случай еще раз доказывает, что IP-адреса являются крайне ненадежными идентификаторами, и для долгосрочного отслеживания техники в локальной сети критически важно опираться на аппаратные MAC-адреса.
Анализ устройств с закрытыми портами
Для оставшихся двух устройств (192.168.4.44 и 192.168.4.81) сканирование около 35 портов, включая 5555 (протокол ADB) и 6668 (локальный протокол Tuya), не принесло результатов: все попытки соединения были либо отклонены, либо отфильтрованы. Шаблонный поиск по всем 14 устройствам в реестре Home Assistant также не дал совпадений. Это подтвердило, что данные гаджеты работают исключительно в режиме клиентов, взаимодействуя с облаком напрямую.
Проблемы с базами данных OUI
Попытка идентификации через локальный пакет netaddr для префикса 2890554 завершилась ошибкой NotRegisteredError. Выяснилось, что этот блок OUI принадлежит TCL и был зарегистрирован только в апреле 2025 года, поэтому стандартные офлайн-базы IEEE в системе его не распознавали. Это распространенная ловушка: вендоры регистрируют новые блоки постоянно, и использование устаревших локальных словарей приводит к ошибкам. Переход на онлайн-сервисы вроде maclookup.app является необходимым условиями для работы с современным сетевым оборудованием.
Специфика «скрытых» устройств
Особое внимание привлек адрес 192.168.4.44. Данные приложения eero показали, что устройство подключается только к диапазону 2.4 ГГц и работает через кухонный узел сети. Первое подключение было зафиксировано 22 июня. Интересно, что OUI этого устройства указывает на компанию Part II Research (известную по бренду Macally), что вызывает вопросы, так как они не занимаются производством умных устройств для 2.4 ГГц. Это напоминает о важном правиле: OUI указывает лишь на того, кто зарегистрировал блок адресов, а не обязательно на реального производителя конечного устройства. В итоге, несмотря на все приложенные усилия, три устройства в сети остались «загадками», что является вполне допустимым для сложного домашнего окружения.
.jpg "Злоумышленники угнали прицепы с логотипами Nvidia, но внутри оказался только песок")
