В рубрику "IP-security" | К списку рубрик | К списку авторов | К списку публикаций
Несмотря на то что концепция VSaaS в общем случае звучит как "включи и работай", на деле все не всегда так просто. Существуют подводные камни, которые надо учитывать как создателям, так и пользователям облачных сервисов. Данный материал посвящен обзору не только сложностей, которые могут возникнуть при работе с VSaaS, но и решений этих сложностей. Существует два способа организации VSaaS – две модели получения видео от IP-камеры в облако. В первом случае сервер облачного сервиса подключается к камере, во втором – камера должна самостоятельно подключиться к облаку. Для каждого вида организации сервиса существуют свои особенности, которые необходимо учитывать пользователю при подключении.
Не все и не всегда, если речь идет о "классических" IP-камерах.
Модель 1
Если сервис построен по первой модели: сервер связывается с IP-камерой через программное обеспечение, инициализирует соединение и диагностирует состояние подключения; необходимо обратить внимание на то, как построена система пользователя. Когда IP-камеры подключаются к Интернету через роутер, для того чтобы сервер нашел камеру, сле дует выполнить проброс портов. Если пользователь обладает достаточной компетенцией, он может сделать это самостоятельно, настроив правило в FireWall роутера. Или же проброс портов и инициализация соединения могут быть произведены IP-камерой, но та должна поддерживать службу UPNp. При этом необходимо обращать внимание на совместимость используемой модели роутера и реализованной в IP-камере функции UPNp, поскольку разные производители реализуют ее по-разному.
Модель 2
Второй вариант организации сервиса предполагает использование специализированных IP-камер, созданных для использования в облаке производителя данных камер.
Модель 1
Если подключение осуществляется первым способом - облаком к IP-камере, пользователь должен обладать внешним ("белым") IP-адресом. В масштабе глобальной сети Интернет проблема исчерпания IPv4-адресов стоит очень остро, поэтому провайдеры все чаще предоставляют своим абонентам частные (или "серые") IP-адреса. Эти адреса не используются в сети Интернет, предназначены для применения в локальных сетях, а их распределение никем не контролируется. Так как в рамках глобальной сети Интернет "серых" адресов фактически не существует, облако не сможет подключиться к камерам пользователя, у которого "серый" IP-адрес. Узнать тип IP-адреса
пользователь может у провайдера, и в случае, если у него частный адрес, запросить смену на внешний. IP-адрес также должен быть статическим, то есть постоянным, привязанным к подключению. В случае динамического IP-адреса при каждой новой сессии он будет меняться, а значит, при первой же смене своего адреса IP-камера "вылетит" из облака.
Если адрес динамический, поможет сервис привязки IP-адреса к домену, например DynDNS . Пользователь может выбрать IP-камеру или роутер Wi-Fi со встроенным сервисом. DynDNS-клиент постоянно отправляет информацию DNS-серверу сервиса, тем самым сообщая о своем IP-адресе. Сервер службы DynDNS сохраняет последний IP-адрес пользователя и при обращении к пользовательскому доменному имени, полученному при регистрации, перенаправляет запрос на этот IP-адрес.
Если используется роутер Wi-Fi с поддержкой DynDNS для системы с несколькими IP-камерами, "белый" статический IP-адрес получает именно роутер, а камерам раздаются "серые" Чтобы и в этом случае система работала как надо, следует произвести проброс портов на роутере.
Модель 2
Если подключение к облачному серверу осуществляется IP-камерой, ее IP-адрес может быть как "белым", так и "серым", статическим или динамическим.
Хотя Интернет и является неотъемлемой частью современной жизни, операторы связи далеко не всегда могут обеспечить своих пользователей высококачественным и высокоскоростным интернет-соединением. Возможны перебои в работе каналов связи между IP-камерой и облаком. В большинстве случаев перебои каналов приводят к потере части видеоданных. Устранение неполадок на линии - процесс небыстрый, поэтому речь, как правило, идет далеко не о нескольких минутах потерянного видео.
Защитить себя от потерь при обрыве связи можно, используя IP-камеры со встроенной картой памяти – за счет синхронизации видеоархива облака с видеоданными, записываемыми на карту памяти камеры. После восстановления связи программное обеспечение, установленное на сервере оператора сервиса, будет "подтягивать" недостающую часть архива прямо с флеш-карты. В результате архив сохранится на сервере полностью.
Серьезным препятствием для широкого распространения облачного видеонаблюдения в России также является ограниченная пропускная способность интернет-каналов. Недостаточная ширина канала серьезно ограничивает объем передаваемой информации, тем самым не только причиняя неудобства пользователю, но и снижая уровень безопасности объекта. Об ограниченности каналов связи я уже писал в статье "Облачное видеонаблюдение: решение проблемы узких каналов связи" ("Системы безопасности", № 4/2013), поэтому на данном вопросе не буду останавливаться очень подробно.
Избежать неприятных сюрпризов при работе с VSaaS можно, зная о них заранее. Решения возникающих сложностей довольно просты, но учитывать их необходимо еще на этапе подбора оборудования и создания своей облачной видеосистемы. Итак, еще раз несколько правил для комфортного использования облака:
1. Если облачная система организована по модели подключения облака к IP-камере, пользователь должен обладать внешним статическим IP-адресом. Если соединение осуществляется через роутер, следует произвести проброс портов. Это можно сделать вручную или выбрав IP-камеру с функцией UPNp.
2. Для системы, в которой подключение к облачному серверу осуществляется IP-камерой, не имеет значения, частный у пользователя IP-адрес или внешний, статический или динамический.
3. Защитить себя от потери видео при обрыве связи с облаком помогут IP-камеры со встроенной картой памяти.
4. Снизить трафик при ограниченной пропускной способности интернет-канала можно с помощью видеоаналитики IP-камер, функции ранжирования видеоданных, снижения качества видеозаписи, выбора формата сжатия H.264 или построения гибридной системы.
Опубликовано: Журнал "Системы безопасности" #5, 2013
Посещений: 9868
Автор
| |||
В рубрику "IP-security" | К списку рубрик | К списку авторов | К списку публикаций