Перейти к содержанию

Методология: как выяснить облачные зависимости камеры/IoT и что из этого маршрутизировать через Mihomo

Статус: Confirmed (принципы и вендор-примеры — по текущим официальным источникам, проверено 2026-09-24) + Observed (практический кейс владельца) + Historical (старые исследования, напр. XMEye) + Research (то, что требует наблюдения на конкретном устройстве)
Область применения: Keenetic + MagiTrickle + Mihomo; камеры и IoT при операторских ограничениях/белых списках, когда нужно «через прокси — только то, что нужно устройству»
Проверено на: текущие официальные страницы Dahua, Hikvision, Reolink, ветка TP-Link Community (все 2026-09-24); архитектура владельца — keenetic-auto-setup/ARCHITECTURE.md
Последняя проверка: 2026-09-24
Source of truth: официальная документация вендоров; живое наблюдение конкретного устройства; для архитектуры — код владельца
Provenance: raw-диалог NVR/WL.md (раздел про камеры; остальное диалога уже извлечено в статьи об именовании/маршрутизации/белых списках)

Что решаем

Задача выглядит как «сделать, чтобы камера работала при белых списках», и первое интуитивное решение — «положить всю камеру в прокси». Но у устройства обычно несколько классов внешних зависимостей, и через прокси нужен, как правило, только один из них. Эта статья — воспроизводимая методология: как выяснить, куда реально ходит конкретное устройство, как классифицировать эти зависимости и как построить минимальное правило вместо маршрутизации всего устройства.

Архитектурные понятия (политика vs сегмент vs SSID, ProxyN/mitun0, устройство vs правило) здесь не пересказываются — см. keenetic-policy-segment-ssid-naming.md и mihomo-keenetic-routing.md.

Confirmed principles

  • Облачная инфраструктура вендоров подвижна. Dahua прямо пишет в официальном FAQ: серверы Imou используют динамические IP, и приводит список доменов по функциям (проверено 2026-09-24). Отсюда практическое следствие: доменное знание стареет медленнее, чем IP-списки.
  • Устройство имеет несколько раздельных классов зависимостей: локальная сеть, NTP, DNS, обновления прошивки, облако управления (логин/регистрация), загрузка видео/картинок, логирование/телеметрия, push, P2P/relay-каналы. Dahua документирует именно такое разделение по функциям; Hikvision отдельно документирует STUN-порты.
  • Наблюдение конкретного устройства — более сильное доказательство, чем копирование старого интернет-списка. Конкретная камера может использовать 3–5 адресов из большого облачного хозяйства вендора (Observed в кейсе владельца; как принцип — вытекает из CDN/relay-динамики).
  • Маршрутизация всего устройства и маршрутизация выбранных назначений решают разные задачи: первая — простой надёжный путь при неизвестных зависимостях, вторая — минимизация прокси-трафика ценой поддержания правил (см. раздел «Два пути» ниже и статью именования §6).
  • Восстановление работоспособности камеры после смены её исходящей политики не доказывает появление входящего доступа (этот вывод уже зафиксирован в статье именования §5 — здесь применяется, не дублируется).

Вендор-примеры (по состоянию на 2026-09-24)

Примеры показывают, какого рода факты даёт вендор и как их использовать. Это не каталог и не полный список «облака вендора».

Hikvision / HiWatch → Hik-Connect

  • Официальная статья трoubleshooting Platform Access называет серверы dev.hik-connect.com, litedev.hik-connect.com, dev.us.hik-connect.com, litedev.us.hik-connect.com и STUN-порты 6002, 6800, 8555, 9010, 9020 (current vendor-confirmed, 2026-09-24).
  • Встречающиеся в RU-практике варианты *.hik-connectru.com, *.guardingvisionru.com — unverified: в старом исследовании сами помечены как требующие проверки на конкретной прошивке. Проверять наблюдением своего устройства.

Dahua / Imou

  • Официальный FAQ перечисляет домены (*.easy4ipcloud.com, *.easy4ip.com и др.) с указанием функции каждой группы: логин/регистрация, DMS, обновление прошивки, загрузка видео, логирование. Прямо сказано: серверы используют динамические IP (current vendor-confirmed, 2026-09-24).
  • Методологическая ценность: это образец «функциональной карты зависимостей», к которой надо стремиться при наблюдении своего устройства.

XMEye / Xiongmai

  • Старое исследование SEC Consult фиксировало домены (*.secu100.net, xmeye.com, xmsecu.com) и большой список IP. Historical: IP-адреса из исследования не использовать как правила — им годы, инфраструктура менялась. Домены — только как ориентир для опознания XMEye-трафика при наблюдении.
  • Практика сообщества: allowlist tplink.com, tplinkcloud.com, tplinknbu.com (current independently confirmed — ветка TP-Link Community жива, 2026-09-24). Поддержка TP-Link подтверждает, что камера использует обычный DNS роутера, но полный список cloud/relay адресов не публикует — то есть без наблюдения списка не собрать.
  • Официальная поддержка: при UID/P2P-доступе «нет назначенных портов — устройство использует случайные UDP-порты» (current vendor-confirmed, 2026-09-24). Следствие: фиксированный IP/порт-список для такого режима в принципе не подходит; годится только доменный уровень или маршрутизация устройства целиком.

Observed / historical

  • Observed (кейс владельца): назначение камер целиком в политику с выходом через ProxyN → Mihomo восстанавливало их работу при операторских БС — это был диагностический эксперимент, показавший, что проблема лежит в конкретных внешних зависимостях, а не в «сломанной камере».
  • Historical: IP-список XMEye из старого исследования (в raw-файле) — только provenance.
  • Research: точный состав и поведение RU-вариантов Hik-облака; актуальные relay/CDN-эндпоинты всех вендоров — проверяются наблюдением.

Практическая методология (ядро статьи)

Ограниченный рабочий цикл для конкретного устройства:

устройство
  ↓ (1) наблюдаем DNS
  ↓ (2) наблюдаем назначения/соединения
  ↓ (3) классифицируем зависимость
  ↓ (4) тестируем DIRECT vs Mihomo
  ↓ (5) строим минимальное правило
  ↓ (6) перепроверяем функции устройства

Что именно наблюдается — и чем это различается

  1. DNS-имена. Первичное свидетельство: устройству нужен этот домен. Наблюдается: MagiTrickle (он сам обрабатывает DNS сегментов из своего link:), или tcpdump на Entware на порту 53 соответствующего bridge-интерфейса. Применимость: MagiTrickle видит только DNS своей зоны охвата (link: + перехват транзитного DNS); tcpdump требует установленного Entware.
  2. Результирующие IP. Куда DNS сегодня разрешается. Полезно для проверки, но стареет быстро (см. Dahua dynamic-IP). Не является самостоятельным правилом без повторной проверки.
  3. Прямые IP-соединения без наблюдаемого DNS. Часть P2P/relay-каналов ходит на IP напрямую. Их видно только наблюдением соединений (tcpdump по хосту камеры / списку соединений), а не через DNS.
  4. CDN/relay-эндпоинты. Множественные, меняющиеся адреса за одним доменом (или без него). Практический признак: много разных IP, мало DNS, UDP/рандомные порты.
  5. Локальная LAN-коммуникация. Коммуникация с NVR/шлюзом/другими устройствами сегмента — не «облачность» вообще, в прокси не входит.

Инструменты и их применимость (ничего экзотического не требуется):

  • tcpdump -ni br0 host <camera-ip> на Entware — соединения и DNS камеры (применимо при установленном Entware);
  • журналы/классификация MagiTrickle — домены сегмента (применимо при покрытии интерфейса в link:);
  • Mihomo-дашборд (Connections) — куда ушёл уже попавший в Mihomo трафик;
  • официальные страницы вендоров (как выше) — функциональная карта зависимостей для сверки.

Классификация зависимости

Каждое наблюдаемое назначение относят к классу: local / NTP / update / cloud-control / media-upload / telemetry / P2P-relay. Это решает, что делать дальше: NTP и локальное обычно DIRECT; вопрос стоит только о классах, не проходящих через оператора при БС.

Тест DIRECT vs Mihomo

Для подозрительного класса — целенаправленный тест: «этот домен/IP через Mihomo, остальное камеры — DIRECT» → функция работает? Потом обратный тест (без правила) → падает? Пара тестов привязывает функцию к зависимости.

Модель функциональной проверки

Успех — не «камера онлайн». Проверять функции раздельно, чтобы понять, какая зависимость к какой функции относится:

  • регистрация/логин в облако;
  • живой просмотр (внутри сети / извне);
  • запись/воспроизведение;
  • уведомления/push;
  • P2P/relay-доступ из внешней сети;
  • проверка обновлений (если актуально);
  • переподключение после обрыва WAN.

Не нужно тестировать всё для каждого вендора — достаточно функций, ради которых устройство вообще используют; остальное — по мере возникновения вопросов.

Доменные правила vs IP-правила

Предпочитать доменные, когда

  • вендор документирует домены (Dahua, Hikvision — подтверждено);
  • адреса за ними подвижны (CDN/relay, dynamic IP);
  • домен виден в DNS и доступен классификации MagiTrickle — тогда правило живёт на уровне «куда устройство хочет», а не «куда это разрешилось сегодня».

IP-правила уместны, когда

  • устройство соединяется напрямую с IP без наблюдаемого DNS;
  • узкий актуальный тест доказал назначение.

Но любая IP-фиксация обязана нести: дату, контекст устройства/модели, статус Observed — и не претендовать на универсальность, пока вендор не задокументировал этот адрес. Публиковать большие IP-allowlist-ы — анти-паттерн (см. Historical-кейс XMEye).

Чего не утверждать про P2P

  • «все камеры всегда ходят через cloud relay» — не подтверждается: у Hikvision есть документированные STUN-порты, у Reolink — случайные UDP-порты, поведение зависит от вендора/режима/прошивки;
  • «телефон соединяется прямо с камерой» — без наблюдения конкретной пары устройство↔приложение это догадка;
  • «весь P2P — это STUN/TURN» и «вот эти домены — полное облако вендора» — вендоры сами полных списков не публикуют (TP-Link — прямой пример).

Где архитектура непрозрачна — так и писать: непрозрачна; решается наблюдением.

Два пути в архитектуре владельца

Маршрутизация устройства целиком

камера → политика Keenetic → ProxyN/mitun0 → Mihomo → proxy

Роли: диагностический базлайн (доказывает, что проблема во внешних зависимостях) и простой fallback, когда зависимости неизвестны или их слишком много.

Селективная маршрутизация

камера → обычная маршрутизация для большей части трафика
      → выявленная cloud/P2P зависимость → MagiTrickle/policy → Mihomo

Роль: минимальный проксируемый трафик ценой ведения правил по результатам наблюдения.

Ни один из путей не «всегда лучше»: при неизвестной карте зависимостей честнее начать с устройства целиком и уточнять, чем гадать правилами (подробное сравнение — в статье именования §6).

Что подтверждено, а что нет

Confirmed:

  • вендор-факты из раздела «Вендор-примеры» (текущие официальные страницы, 2026-09-24): Dahua — домены по функциям + динамические IP; Hikvision — серверы Platform Access + STUN-порты; Reolink — случайные UDP-порты при UID/P2P; TP-Link — домены из практики сообщества + отказ публиковать полный список;
  • принципы раздела «Confirmed principles», поскольку опираются на эти источники и документированную архитектуру владельца.

Observed:

  • диагностический эксперимент владельца с камерами (device-wide через ProxyN → Mihomo восстановил работу при БС).

Historical:

  • IP-список XMEye из исследования SEC Consult; RU-доменные варианты Hik-облака из старого диалога — не проверены.

Research / needs live observation:

  • фактический состав зависимостей любой конкретной камеры; поведение её relay/CDN; полнота любых доменных списков — всё это методология предписывает выяснять наблюдением, а не принимать на веру.

Источники и provenance

Связанные материалы