Show content

Основы работы в сети IP камер

Форум Системы безопасности / Форум Видеонаблюдение /

06.05.2014 11:38:58

думаете ip камерам/nvr необходима работа "нараспашку", минимально необходимого диапазона портов открыть и перебросить не достаточно? У меня из открытых для камер только лишь; 80, 8000, 554, 443, трансляция с этими портами работает.

Никакой необходимости выставлять ни IP-камеру, ни nvr - "голой жопой на улицу" НЕТ! Простого открытия правильных IP-портов - вполне достаточно.

Вы рекомендуете вынести все камеры в демилитаризированную зону, или я не так Вас понял?

Как Вы сами заметили в DMZ-те (в простых устройствах) - это работает только для одной камеры.

Так же DZM неудобен еще и потому что доступ из локальной сети - или становиться невозможным, или же весьма усложненным через жопу автогеном, что расшифровывается как: -смотреть локальные камеры - Вы конечно сможете, но смотреть Вы их уже будет через туже самую дыру - через которую получаете и весь входящий трафик интернета.

По большому счету - что технология NAT, что технология DMZ, что просто - переназначение портов по неким правилам - занимаются одним и тем же - конвертируют адреса.

Просто разные технологии - имеют различные уязвимости ко всевозможным атакам (DMZ - снаружи локальной сети т.е. со стороны интернета, NAT - изнутри локальной сети) - т.ч. выбирается та или иная технология как раз из требовании по безопасности и защищенности данных внутри локальной сети.

Ну а поскольку все технологии, так или иначе занимаются по существу одним и тем же - инкапскулируют IP пакет, узнают адрес получателя/отправителя, находят по неким прописанным им правилам замену входящих адресов на локально-внутренний (при передачи соответственно наоборот - внутренний - на наружный), ну и соответственно снова капсулируют пакет уже с новыми адресами - то фактически, скорость прохождения пакета через "железный" роутер, при данных операциях - будет зависит в основном от тех алгоритмов которые применяются роутером, т.е. в большей степени время прохождения пакета через роутер - будет зависит не от самой технологии (NAT vs DMZ), а зависеть оно будет от степени корявости микропрограммы конкретного роутера, ну и конечно от количества написанных администратором правил (оптимальных, или же нет) - которые должна исполнять эта самая микропрограмма железного роутера.

ИМХО - более удобным и более или менее безопасным (опять же на мой взгляд) - является система проброса портов с их подменой, причем с подменой именно по правилам, которые администратор как раз и может (более или менее) оптимизировать сам, причем оптимизировать и сточки зрения скорости прохождения пакетов и сточки зрения безопасности - причем как всей локальной сети находящейся за роутером, так и самих камер - выпущенных наружу.

Насколько я смог разобраться в инструкциях к Вашей железяке - в Вашем случае, достаточность создать 6 правил (по 2 на каждую из IP камер) одно под HTTP порт, второе под RTSP порт, но с их подменой в роутере для наружного подключения, т.е. по аналогии вот этому:

Это позволит Вам - работать с камерами внутри сети под их реальными (локальными) IP адресами и с неизменными портами ТCP/IP и RTSP (т.е. с портами по умолчанию).

При работе же извне - IP адресом доступа до ваших камер, будет Ваш статичный адрес, ну а доступ до конкретной камеры, - будет подразделяться уже по подменному IP-порту и в зависимости от способа подключения (HTTP или RTSP) и рулить этим доступом будет ваш роутер по правилам, которые Вы можете ему задать сами.

Но насколько я понимаю: - ровно всё это, - у Вас сегодня уже и сделано.

PS

но как-то VLC подхватывает и транслирует бодрее что-ли, поэтому чаще всего запускаю ее.

VLС - умеет получать видеопоток не только в TCP/RTPS, но и UDP/RPTS, а это как раз позволяет иметь меньшее время задержки прохождения пакетов, т.к. в UDP не требуется подтверждение об приеме или не приеме пакета, а это значит что не происходят пере запросы битых пакетов и не тратиться лишнее время на гарантированную доставку, ну и как следствие этого - меньшее время задержки при отображении картинки на экране - но при этом неизбежно и периодически возникающие артефакты в виде изображения рассыпающихся на квадратики при любых (мгновенных) перегрузках сети.

06.05.2014 12:09:24

UDP/RPTS, а это как раз позволяет иметь меньшее время задержки прохождения пакетов, т.к. в UDP не требуется подтверждение об приеме или не приеме пакета, а это значит что не происходят пере запросы битых пакетов и не тратиться лишнее время на гарантированную доставку, ну и как следствие этого - меньшее время задержки при отображении картинки на экране

Вот этот фокус к сожалению проделать не удалось пока, не знаю как "заставить" VLC обращаться к камере исключительно по UDP, обходя TCP. Адрес типа udp://ipadress:номерпорта плейер не открывает, выдает ошибку, нужно обязательно набирать как rtsp://ipadress:номерпорта.

Правило переадресации порта 554 на роутере ставил принудительно только UDP, но тогда связь не устанавливается, только если разрешаешь tcp и udp вместе тогда поток можно смотреть удаленно.

06.05.2014 12:41:14

Правило переадресации порта 554 на роутере ставил принудительно только UDP, но тогда связь не устанавливается, только если разрешаешь tcp и udp вместе тогда поток можно смотреть удаленно.

TCP Вам нужна в любом случае: - по ней происходит авторизация.

Ну про то что VLC умеет читать поток UDP - это я где-то читал (но не помню где), причем - вполне возможно что в Вашем случае (когда Вы открыли оба протокола tcp & udp) - он автоматически начал видеопоток получать в udp.

У вас смарт-сниффер какой либо есть?

Если есть, то запустите его на приемной машине и посмотрите в каком именно протоколе идет видеопоток при работе на VLC, вполне возможно что это и будет UDP/RTSP.

; ;; ;; ;;;; ;

06.05.2014 12:57:31

TCP Вам нужна в любом случае - по ней происходит авторизация.

да уж, без tcp ну никак. Я даже провел тест, отключил на камере авторизацию по rtsp и разрешил анонимные подключения, есть такая возможность в панели управления, но все равно одного udp оказывается недостаточно, что-то видимо кроме авторизации еще шлется по tcp.

У вас смарт-сниффер какой либо есть?

снифер на своей стороне не запускал, но мониторил удаленно роутер с момента подключения к камерам. Сначала в потоке открыты порты и по tcp и udp. Но потом udp не остается, в основном используется tcp.

А потом остается tcp

29.12.2016 15:44:52

Пример того, как можно научиться настраивать IP-камеры.https://www.youtube.com/watch?v=F8b6HlkF3ts

;

30.12.2016 08:04:01

Пример того, как можно научиться настраивать IP-камеры.https://www.youtube.com/watch?v=F8b6HlkF3ts

Мужик с MacBook сидит, обламывается, так как сервер "макрогоп" только для Windows? ;-D

06.01.2017 20:14:06

Приветствую уважаемые гуру сетевой безопасности ))

Цитаты из открытых авторитетных источников:

Что такое RTSP RTSP расшифровывается как Real Time Streaming Protocol — потоковый протокол реального времени — по сути это протокол управления вещанием, он позволяет выполнять несколько команд, такие как «старт», «стоп», «переход на определённое время». Протокол этот подобен HTTP в реализации, тоже есть заголовки, тоже всё передаётся в текстовом виде. Вот основные его команды из спецификации:

  • OPTIONS — возвращает список поддерживаемых методов (OPTIONS, DESCRIBE и т.д.);
  • DESCRIBE — запрос описания контента, описывает каждый трек в формате SDP;
  • SETUP — запрос установки соединений и транспорта для потоков;
  • PLAY — старт вещания;
  • TEARDOWN — остановка вещания.

И особенность RTSP в том, что он сам по себе не передаёт нужные нам видео данные! Целый протокол только для установления связи.

Полная статья тут: https://habrahabr.ru/post/117735/

07.01.2017 22:54:06

И что?

15.01.2017 17:41:07

Как подключить IP-камеру (теория и практика)

;

https://www.youtube.com/watch?v=iY93JvI4LhI

16.01.2017 21:02:52

Спасибо помогли и мне в данном вопросе