В предыдущей статье мы рассказали об одной из сфер применения Flussonic Watcher и кратко о том, зачем нужен Flussonic Agent. А ещё раньше о том, как агент может решить проблемы безопасности при передаче видеопотока. И везде мы отвечали на вопросы «Зачем?», но очень кратко касались вопроса «Как?».
Как мы уже писали, основная проблемой при запуске большой сети видеонаблюдения — настройка видимости камеры из интернета. Для ее решения есть три классические схемы:
- Установка проксирующих серверов OpenVPN.
- Ручной проброс портов.
- Назначение белых IP-адресов для каждой камеры.
OpenVPN
Распространенный и наиболее простой способ — это организация OpenVPN туннеля. Его выбирают прежде всего потому, что для большинства дешевых камер прошивка собирается с помощью buildroot, а в нем уже есть OpenVPN и он легко включается.
На камере прописывается сертификат подключения и адрес OpenVPN сервера. Затем стриминговый сервер в облаке видит камеру через OpenVPN сервер и забирает с нее видео. Однако, OpenVPN требует наличия еще одного сервера рядом, удваивая ваши серверные затраты.
Управление сервером, на который придет камера, находится на самом устройстве Быстро добавить новый сервер вместо сгоревшего и отправить камеру на него не получится — надо менять DNS. А на пути между вашим DNS-сервером и камерой обязательно появится удобный кеширующий на сутки чужой DNS-сервер, который будет заботливо подставлять старый адрес OpenVPN сервера.
Ко всему прочему, OpenVPN требует больше ресурсов из-за того, что он делает больше, чем нужно для этой задачи. Организуется полноценный туннель, который пропускает трафик через ядро linux. В случае с Flussonic Agent и Flussonic Media Server этого не происходит — весь трафик приходит и остается в одном процессе, При гигабите входящего видео это очень ощутимо.
Ручной проброс портов
Port Forwarding — перенаправление портов или ручной проброс портов — позволяет обращаться из интернета к IP-камере, которая находится во внутренней сети за маршрутизатором, использующим NAT. Доступ осуществляется перенаправлением трафика определенных портов с внешнего адреса маршрутизатора на адрес выбранного устройства в локальной сети. Минусы ручного проброса портов это:
- Настройка каждого роутера и каждой камеры очень сложна и занимает непозволительно много времени.
- По открытому порту может зайти кто угодно. То есть на лицо явное дыра в безопасности.
- Вся нагрузка по трафику ложится на раздающую камеру и раздающий канал, а они упадут уже на третьем клиенте.
- По RTSP камера будет отдавать рассыпающуюся картинку.
Назначение белых IP-адресов
Покупка «белых» IP-адресов для каждой IP-камеры решает проблему доступа из-за NAT, но может быть адекватным решением только, если у вас не очень большое количество камер. В противном случае организация видеонаблюдения станет просто невыгодным предприятием.
Flussonic Agent
Каждая из этих схем обладает достоинствами и недостатками. Объединяет их два фактора: применимость лишь к небольшой сети видеонаблюдения и невозможность организовать режим Plug-n-play для абонента и автоматизацию процесса для администраторов сервиса. Flussonic Agent как раз и закрывает эти проблемы, позволяя нашим клиентам упростить запуск сервиса. Программа устанавливается на все камеры, передает нужную информацию для активации и связи камеры с пользователем в биллинг или напрямую в Flussonic Watcher и начинает отдавать видео на стриминговый сервер оператора.
Также, как и с OpenVPN сервером, в агенте существует привязка к DNS, но всё-таки обеспечить failover небольшой виртуалки, на которой запущен только веб-интерфейс и управляющий сервер гораздо проще, чем failover высоконагруженного сервера с толстым каналом.
С какими камерами работает Flussonic Agent
Мы можем запустить Flussonic Agent почти всех камерах, работающие под Linux. Важный момент — нам нужна оригинальная прошивка устройства. На данный момент отработана установка агента на уличных камерах на базе HiSilicon, TI DaVinchi и MIPS роутерах на базе dd-wrt.
Как работает Flussonic Agent
Самое интересное. Подготовленная нами прошивка с агентом устанавливается вендором на заводе или прошивается сами оператором. После того, как камера с установленной прошивкой попадёт к клиенту и будет в первый раз запущена, реализуется следующая схема работы:
1. При включении камеры в сеть и подключении к интернету запускается Flussonic Agent.
2. Агент подключается к серверу с Flussonic Media Server, на котором устанавливается Flussonic Watcher, и сообщает о том, что он готов к передаче видео. Этот сервер является управляющим и называется в терминологии агента: endpoint. Здесь камера получает контрольную информацию, авторизуется и переходит через connection upgrade в наш собственный протокол.
3. Если Flussonic Watcher узнал агента (происходит взаимная проверка пароля), то он передает агенту информацию об одном из запущенных серверов Flussonic Media Server на который как раз и пойдет передача видеотрафика. Такой Flussonic Media Server в терминологии агента называется streampoint. Также endpoint может передать команду быстро переключиться на другой streampoint для того, чтобы отработать ситуацию с выходом из одного из стримеров в кластере Flussonic Media Server.
4. После подключения к Flussonic Media Server агент ожидает команду на открытие соединения. Оно похоже на SSH туннель. Когда Flussonic Media Server решает забрать видео с камеры, он обращается к агенту с просьбой организовать TCP-туннель. По этому туннелю может передаваться как видео с RTSP, так и скриншоты с камеры.
В Flussonic Agent также реализована возможность переключатся между основным и резерным управляющим сервером (endpoint) и стриминговыми серверами Flussonic Media Server.
Безопасность доставки видео
Помимо основной задачи нам было важно защитить камеры от взлома и видеопоток от перехвата. Большинство китайских устройств очень слабо защищены даже от простейших бэкдоров. Flussonic Agent умеет шифровать видеопоток с помощью TLS шифрования, исключая любые проникновения третьих лиц в процесс передачи данных.
Кейс внедрения Flussonic Agent в Тайланде
Чтобы понять принципы работы Flussonic Agent и плюсы его внедрения, стоит рассмотреть пример внедрения. К нам обратился клиент, который покупал Flussonic Media Server для того, чтобы пользователи могли из офиса смотреть на солнечные пляжи Тайланда, впечатляться, а затем бежать покупать путевки. Развитие работы с камерами привело его к оказанию услуги OTT VSaaS. Это означает, что клиент забирает видео с камер, которые устанавливаются в ресторанах, кафе и других публичных местах Тайланда, и даёт доступ к видео как в записи, так и в прямой трансляции.
Но в Тайланде есть две глобальные проблемы с интернетом:
- Дорогой внешний интернет: от $80 в месяц за мегабит. Если видео с камер выходит за границу Тайланда, то это автоматически может добавить очень много денег к ежемесячному чеку.
- Качество интернета. Ещё в 2011-м году по Тайланду висели объявления «high speed 1 mbit». Сейчас ситуация получше, но всё равно 4-х мегабитный поток с камеры из ресторана ставит под вопрос предоставление Wi-Fi посетителям, что в этой стране очень актуально.
Конечно, видеонаблюдение в ресторанах можно оказать и с помощью обычного китайского регистратора с приложением p2p cloud, но у такого подхода есть множество минусов:
- Регистратор требует внешнего IP адреса. В Тайланде такая услуга стоит от $30 до $60 в месяц.
- Регистратор отдает наружу видео столько раз, сколько придет клиентов. С учётом вышеописанных проблем с интернетом отдать видео более чем паре клиентов уже проблема
- Регистратор скорее всего потребует настройку проброса портов на роутере, а в свете Mirai возможно ещё и общения с провайдером по поводу разблокировки нужных портов.
- Если забирать видео по RTSP с китайского оборудования, то почти гарантированно столкнешься с багом которого нет.
Наш клиент и предлагает услугу, которая решает эти проблемы. В Тайланде на арендованном сервере был установлен Flussonic Watcher, а экземпляр программного комплекса зарегистрирован у нас, чтобы можно было войти через мобильное приложение. Для решения вышеуказанных проблем на камеры устанавливается наш агент, с которым камера превращается в полный Plug And Play: принесли, повесили, включили — видео на сайте.
Чтобы обеспечить такой уровень сервиса мы много работали с клиентом, вплоть до советов какие камеры покупать и у каких производителей. Также нам было важно, чтобы все камеры были фирмы «XM». Это очень часто встречающийся noname-бренд, который делает устройства достаточно приличного качества и при этом очень недорогие. Hikvision, конечно, лучше XM, но и дороже.
Производители камер прислали немного другие устройства, но мы были к этому готовы и подготовили несколько прошивок. Они были разработаны таким образом, чтобы камеры сразу шли к нужному экземпляры Flussonic Media Server. Клиент самостоятельно установил прошивки на камеры и запустил услугу. Ещё пару моментов нам пришлось исправлять уже удаленно на установленных камерах из-за проблем, вызванных совсем уж специфичным интернетом в Таиланде, но они были легко устранены.
Итог
Как вы видите, Flussonic Agent может значительно упростить запуск видеонаблюдения, обходя как внутренние технические проблемы, так и внешние, связанные с особенностями интернета в данном географическом регионе. В следующих статьях мы расскажем о том, как происходит интеграция Flussonic Watcher с биллингом оператора.
Комментарии (16)
rt3879439
20.01.2018 13:34Можете написать статью о том, как потрошить прошивки? Я пробовал разобраться с прошивкой одной глючной камеры, но ни с какими утилитами я не получил положительного результата.
ZigFisher
21.01.2018 18:40Вы не сообщили производителя, модель и SoC камеры. Напишите, попробуем вместе.
От этого зависит и метод распаковки. Некоторые примеры были тут и на GT.
CherryPah
22.01.2018 10:17если походить по ссылкам из статьи можно найти историю как разбирали и чинили прошивку на камере
habrahabr.ru/post/219537
ZigFisher
21.01.2018 18:46Спасибо за статью, было достаточно интересно.
Сообщите пожалуйста, какого размера исполняемых файлов и библиотек вам удалось достичь?
Ведь не секрет, что в некоторых камерах места, ну как кот наплакал.
Свои задачи я решил путём интеграции в прошивки к камерам XM небольшой утилитки VTUNd, которая строит L2/L3 туннель на мой сервер, а китайское облако отключил. Ну и скриптов и утилиток еще докинул до кучи в прошивку.erlyvideo
21.01.2018 23:09не занимаясь сжатием получается порядка 350 килобайт.
ZigFisher
22.01.2018 00:01Туннель + шифрация + какие-то свои алгоритмы = 350k
Достаточно хороший результат. Мои искренние поздравления!ZigFisher
22.01.2018 11:41+1Минусующих заело что-ли, что разговор пошел в техническую сторону? Повторюсь — указанный выше результат вполне хорош. Любой туннель с более-менее адекватной шифрацией для Embedded систем будет занимать не менее 160-220 килобайт.
Занимаюсь сейчас моддингом прошивок к камерам XM на базе SoC HI3518E, с интеграцией в камеры низшей ценовой категории, которые с флешкой 8 Mb, дополнительных возможностей в виде поддержки USB WiFi/Flash/3Gmodem, туннелей для создания своего «облака» (повторить сможет каждый на роутере/сервере с одним белым IP), подключения датчиков и исполнительных устройств. Так что немного «в теме» как достаточно непросто происходит там борьба за каждые свободные 50-10 килобайт.
erlyvideo
23.01.2018 09:04я не знаю, за что минусуют, если честно.
Очень легко написать минимальнейший кусок кода, который работает на стенде, но мы поддерживаем большое разнообразие окружений (т.е. свой libevent, свой ssl), плюс к этому на некоторых камерах нам приходится добавлять юзера, ведь сейчас начали борьбу с мираи, поэтому надо тащить ещё обвязку к этому.
Rewire_getz
22.01.2018 12:15Почему при ручном пробросе портов камера по RTSP будет отдавать рассыпающуюся картинку?
ZigFisher
22.01.2018 19:20+1Не принимайте это утверждение дословно.
Просто при пробросе портов камера может отдавать картинку, которая будет рассыпаться. Дело в том, что во многих камерах бинарник, который является RTSP сервером еще выполняет кучу дополнительных функций и старые прошивки, особенно, работают на грани фола. И каждый «чих», в данном случае трансляция адресов, пусть и не на самой камере, вносит некий дисбаланс в эту хрупкую конструкцию. Выше давали ссылки на статью, там всё достаточно хорошо и подробно объясняется.
erlyvideo
23.01.2018 09:07да, есть статья про баг, которого нет.
Если вкратце, то ситуация такая: китайские программисты обнаружили что если слать видео по TCP, то сокет начинает блокироваться и возникают дропы фреймов на захвате. А потом они обнаружили, что если перевести сокет в неблокирующий режим, то блокировки и дропа fps не будет. Но при этом не сделали всю ту обвязку, которая нужна вокруг неблокирующих сокетов.
Поэтому если хоть чуток проседает сеть (а это бывает в 99,9999999% случаев), то большие кадры (кейфреймы т.е.) при моментальной отправке в сеть частично теряются юзерлендом на камере. Бороться с этим чрезвычайно сложно.
vrangel
Основной недостаток такого подхода — зависимость от чужой инфраструктуры, ведь endpoint сервер всегда остается в вашей зоне ответственности. И установить у себя его нельзя по вашей политике.
А в целом продукт интересен.
erlyvideo
как раз не так. endpoint здесь — это экземпляр флюссоника, который стоит у вас. Его адрес пишется в конфиг при первом запуске агента и потом агент ходит уже к нему, т.е. к серверу у вас.
vrangel
Спасибо за ответ. Тогда разрешите более общий вопрос: Все ли элементы системы могут находиться у владельца сервиса? Если да, то мы с менеджерами Erlyvideo не поняли друг-друга.
erlyvideo
на самом старте камера один раз идет к нам, что бы выяснить, куда идти дальше. Потом она уже общается только с вашими серверами.
Этот момент мы менять не будем, потому что зашивать в прошивку адрес клиента мы не будем. За все годы работы ни разу не было ситуации, что бы клиент с первого раза выбрал себе домен для камер раз и навсегда. Мы всем говорим, что надо выбрать и потом не менять, все говорят ага и меняют.