В любой домашней сети живут устройства, о которых не думаешь: камера, телевизионная приставка, розетки. Они не открывают сайты и не просят обновлений — и поэтому про них мало что известно. При обходе сети я нашёл «неизвестную железку» с постоянным каналом наружу, а приставка оказалась устроена так, что обновить её «правильной» прошивкой невозможно в принципе. Плюс расчёт, во что обходится своя запись с камеры без облака.
Это одиннадцатая часть цикла «Домашняя инфраструктура».
Неизвестная железка
В таблице аренд роутера висело устройство без имени. Что о нём удалось узнать снаружи:
- все TCP-порты закрыты, на ping не отвечает, на обнаружение в сети (SSDP, mDNS) — тоже;
- в таблице ARP — живое,
reachable; - держит постоянный UDP-канал на один и тот же внешний адрес. В кэше DNS роутера (489 записей) нет ни одного имени, которое бы туда вело: адрес зашит в прошивку;
- в простое — около 0,5 Кбит/с: сердцебиение «я на связи».
По MAC-адресу и поведению это оказалась уличная камера — недорогая модель, которая работает через облако производителя. Смотреть картинку можно только их приложением, и картинка идёт через их сервер.
Почему такие камеры плохи устройством, а не качеством
- канал наружу открывает сама камера. Файрвол роутера в этом не участвует: входящих соединений нет, есть одно исходящее, которое никогда не закрывается. Кто может посмотреть картинку — решает облако, а не вы;
- всё через чужой сервер — отсюда задержки в приложении и зависимость от того, работает ли этот сервер;
- нет стандартных протоколов (RTSP, ONVIF): записать поток своим сервером нельзя;
- записи на дешёвой карте памяти, которая при круглосуточной записи живёт месяцы и умирает молча, а читать записи можно только их программой.
Главная претензия к таким системам: они проверяются только в момент, когда что-то случилось и нужно посмотреть запись. Карта умерла неделю назад, облако сменило условия, приложение обновилось и разлогинило — узнаёте вы об этом ровно тогда, когда запись нужна.
Своя запись без облака: расчёт
Требования к замене: поворотная, ночная съёмка, детекция движения, питание по кабелю (PoE), архив на неделю с перезаписью по кругу. Климат: обычно до −5, пару ночей за зиму −20.
Потянет ли сервер
Распознавание людей и машин на сервере с i3 2013 года — нет. Но камеры с детекцией делают его сами, а серверу остаётся писать поток без перекодирования — это около 5% ядра на камеру. Три-четыре камеры старый ноутбук вытянет, второй сервер не нужен.
Сколько нужно места на неделю
| Режим | Поток | Неделя |
|---|---|---|
| 1080p, H.265, круглосуточно | ~2 Мбит/с | ~150 ГБ |
| 2K, H.264, круглосуточно | ~4 Мбит/с | ~300 ГБ |
| только по движению | — | 15–40 ГБ |
На системном диске свободно меньше 30 ГБ, и даже 100 ГБ под архив было бы мало. А делить диск с сайтами нельзя: заполненный видеозаписью диск уронит всё остальное. Решение — отдельный жёсткий диск на 1 ТБ (не SSD: постоянная перезапись его быстро изнашивает) в отсек DVD-привода, отдельным разделом.
Выбор модели
Сравнил несколько моделей. Вывод получился неочевидный: автоматическое слежение за объектом есть не у всех морозостойких моделей, и наоборот. Его частично заменяет связка «тревога → поворот на заранее сохранённую позицию», которая есть почти везде. А приложение производителя нужно один раз — при первой настройке. Поэтому выбирать стоит по рабочей температуре и поддержке ONVIF, а не по тому, насколько приятное приложение.
План из семи шагов
- кабель PoE+ по всем восьми жилам до места установки;
- первичная настройка с отключённым облаком, отдельный пользователь для ONVIF;
- диск под архив отдельным разделом;
- запись отрезками по 10 минут с удалением по возрасту и по свободному месту;
- просмотр: дома — страница на сервере, снаружи — поддомен за прокси с паролем, на телефон — дополнительный поток низкого качества;
- сторож раз в час: пишется ли запись, растёт ли архив;
- камере запретить выход в интернет на роутере — облако ей больше не нужно.
Решение пока не принято, камера не выбрана — это план. Но его главная часть не зависит от модели: своя запись, свой сторож и запрет камере ходить наружу.
Приставка, которую нельзя обновить «правильно»
Вторая история — IPTV-приставка. Она на Linux и обновляется сама: раз в сутки спрашивает сервер настроек, какую версию прошивки ставить. Адрес этого сервера берётся по приоритету — зашитый жёстко, через протокол удалённого управления, из опций DHCP или по умолчанию.
Сервер настроек производителя узнаёт по внешнему адресу, какой у вас провайдер, и отдаёт его конфигурацию: прошивку провайдера и его сервер обновлений. Версия от провайдера была на три сборки старше официальной. Хотелось поставить официальную вручную — и тут выяснилась деталь: приставка сравнивает версии не по принципу «новее», а по принципу «отличается». Официальная прошивка простоит до ближайшей проверки, после чего приставка честно «обновится» обратно до версии провайдера.
Проверял механизм правилами журналирования на роутере: какие запросы приставка делает и куда. Механизм живой и работает как задумано. А заодно нашлась поломка, о которой была седьмая часть: запросы приставки шли не тем путём из-за общего адреса с заглушкой провайдера.
Мелочь RouterOS: найти временное правило по [find where src-address=…] не получилось — удалять удобнее по log-prefix, который вы сами задали при создании.
Не знаете, что за устройства сидят у вас в сети?
Пришлите таблицу аренд роутера — помогу опознать устройства и решить, кому из них стоит закрыть выход в интернет.
// загружаю комментарии…