Проброс rtsp потока через роутер mikrotik

Как заставить работать RTSP поток с IP камеры через проброс портов?

Здравствуйте!
Немогу заставить VLC Player с инета показывать RTSP поток с IP камеры MISECU 720p, проброшенный через роутер. Сам RTSP на 554 порту проброшен, плеер якобы подключается, но картинки нет, т.к сам видео поток, судя по дампу пакетов, транслируется по UDP на портах, о которых сервер договаривается с клиентом в процессе SETUP, PLAY в RTSP запросах.

31 2e 73 64 70 2f 74 72 61 63 6b 49 eam=1.sd p/trackI 0090: 44 3d 31 20 52 54 53 50 2f 31 2e 30 0d 0a 43 53 D=1 RTSP /1.0..CS 00a0: 65 71 3a 20 34 0d 0a 55 73 65 72 2d 41 67 65 6e eq: 4..U ser-Agen 00b0: 74 3a 20 4c 69 62 56 4c 43 2f 32 2e 32 2e 36 20 t: LibVL C/2.2.6 00c0: 28 4c 49 56 45 35 35 35 20 53 74 72 65 61 6d 69 (LIVE555 Streami 00d0: 6e 67 20 4d 65 64 69 61 20 76 32 30 31 36 2e 30 ng Media v2016.0 00e0: 32 2e 32 32 29 0d 0a 54 72 61 6e 73 70 6f 72 74 2.22)..T ransport 00f0: 3a 20 52 54 50 2f 41 56 50 3b 75 6e 69 63 61 73 : RTP/AV P;unicas 0100: 74 3b 63 6c 69 65 6e 74 5f 70 6f 72 74 3d 35 38 t;client _port=58 0110: 38 39 30 2d 35 38 38 39 31 0d 0a 0d 0a 890-5889 1. 74 3b 6d TP/AVP;u nicast;m 00a0: 6f 64 65 3d 50 4c 41 59 3b 73 6f 75 72 63 65 3d ode=PLAY ;source= 00b0: 31 39 32 2e 31 36 38 2e 32 2e 32 35 30 3b 63 6c 192.168. 2.250;cl 00c0: 69 65 6e 74 5f 70 6f 72 74 3d 35 38 38 39 30 2d ient_por t=58890- 00d0: 35 38 38 39 31 3b 73 65 72 76 65 72 5f 70 6f 72 58891;se rver_por 00e0: 74 3d 34 30 30 30 30 2d 34 30 30 30 31 3b 73 73 t=40000- 40001;ss 00f0: 72 63 3d 30 30 30 30 31 42 43 43 0d 0a 43 61 63 rc=00001 BCC..Cac 0100: 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 70 72 69 76 he-Contr ol: priv 0110: 61 74 65 0d 0a 78 2d 44 79 6e 61 6d 69 63 2d 52 ate..x-D ynamic-R 0120: 61 74 65 3a 20 31 0d 0a 0d 0a ate: 1.. ..

Кроме 554, пробросил также 40000- 40001(UDP), похоже у камеры они постоянные, но картинки все ровно нет, а плеер никаких ошибок не выводит. Несколько пакетов на эти порты таки прилетает в процессе подключения, но не заводится.
С локальной сети все работает, и массивный трафик идет с 40000 порта камеры, иногда что то пролетает на 40001 на каждый раз разные пары UDP портов клиента. Что не так?

Средний 2 комментария

Источник

Перенаправление запросов (проброс портов) на Mikrotik

Обновлено: 20.04.2023 Опубликовано: 20.06.2017

Инструкция описывает процесс настройки перенаправления сетевых запросов с внешнего подключения на компьютеры в локальной сети.

Настройка проброса

Переходим по разделам IP — Firewall — NAT — Add New: Далее настройка выполняется в зависимости от того, какой сервис нужно опубликовать.

Примеры пробросов

RDP (удаленный рабочий стол)

• Chain — dstnat;
• Dst. Address — внешний IP-адрес;
• Protocol — rdp;
• Action — dst-nat;
• To Address — IP-адрес сервера, на который должно идти перенаправление.

* если данная настройка не сработает, меняем протокол на tcp и задаем порт RDP — по умолчанию, 3389.

WWW (80 или веб-сервер или http)

• Chain — dstnat;
• Dst. Address — внешний IP-адрес;
• Protocol — tcp;
• Dst. Port — 80;
• Action — dst-nat;
• To Address — IP-адрес сервера, на который должно идти перенаправление.

HTTPS

Настройка та же, что для 80 порта, но в место 80 пишем 443.

FTP

• Chain — dstnat;
• Dst. Address — внешний IP-адрес;
• Protocol — tcp;
• Dst. Port — 20,21;
• Action — dst-nat;
• To Address — IP-адрес сервера, на который должно идти перенаправление.

Видеонаблюдение

Системы видеонаблюдения могут работать на различных портах, поэтому первым делом обращаемся к инструкции системы, с которой необходимо работать.

В данном примере рассмотрим проброс RTSP.

• Chain — dstnat;
• Dst. Address — внешний IP-адрес;
• Protocol — udp;
• Dst. Port — 554;
• Action — dst-nat;
• To Address — IP-адрес сервера, на который должно идти перенаправление.

* RTSP работает по протоколам TCP и UDP. В данном примере правило настроено для последнего.

Почтовая система Zimbra

Для нормальной работы почтовой системы необходимо пробросить следующие порты:

• 25 — основной порт для обмена почтой по протоколу SMTP.
• 80 — веб-интерфейс для чтения почты (http).
• 110 — POP3 для загрузки почты.
• 143 — IMAP для работы с почтовым ящиком с помощью клиента.
• 443 — SSL веб-интерфейс для чтения почты (https).
• 465 — безопасный SMTP для отправки почты с почтового клиента.
• 587 — SMTP для отправки почты с почтового клиента (submission).
• 993 — SSL IMAP для работы с почтовым ящиком с помощью клиента.
• 995 — SSL POP3 для загрузки почты.
• 5222 — для подключения к Zimbra по протоколу XMPP.
• 5223 — для защищенного подключения к Zimbra по протоколу XMPP.
• 7071 — для защищенного доступа к администраторской консоли.
• 8443 — SSL веб-интерфейс для чтения почты (https).
• 7143 — IMAP для работы с почтовым ящиком с помощью клиента.
• 7993 — SSL IMAP для работы с почтовым ящиком с помощью клиента.
• 7110 — POP3 для загрузки почты.
• 7995 — SSL POP3 для загрузки почты.
• 9071 — для защищенного подключения к администраторской консоли.

Важно отметить, что не все перечисленные порты понадобятся именно вам. Если мы не планируем использовать POP3, то и соответствующие порты для него пробрасывать не нужно.

Сама настройка на микротике будет такой:

• Chain — dstnat;
• Dst. Address — внешний IP-адрес;
• Protocol — tcp;
• Dst. Port — 25,80,110,143,443,465,587,993,995,5222,5223,9071,7071,8443,7143,7993,7110,7995;
• Action — dst-nat;
• To Address — IP-адрес сервера, на который должно идти перенаправление.

NAT Loopback (nat reflection)

Проброс не будет работать для внутренней сети, если исходящий внешний IP совпадает с тем, на котором опубликован сервис. Предположим, что у нас внешний адрес 95.161.166.156 и мы хотим пробросить порты 80 и 443. Все попытки к нему подключиться из внутренней сети будут заканчиваться ошибкой Connection Timeout.

Для решения задачи публикации сервиса клиентам внутренней сети есть два классическим способа:

1. Разделять ответы DNS таким образом, чтобы внутренние пользователи получали внутренний адрес, а внешние — внешний. Полезные материалы на эту тему — Настройка Split DNS на одном сервере Bind и Установка и примеры настройки Dnsmasq.

2. Использовать специальные правила при создании пробросов, которые отделяли бы внутренние запросы от внешних. Это может называться NAT Loopback или NAT Reflection.

В рамках нашей инструкции мы рассмотрим второй метод. Нам нужно создать два правила: первое — для проброса из внутренней подсети на внутренний адрес; второе — маскарадинг.

• Chain — dstnat;
• Src. Address — внутренняя подсеть;
• Dst. Address — внешний IP-адрес;
• Protocol — tcp;
• Dst. Port — 80,443;
• Action — dst-nat;
• To Address — IP-адрес сервера, на который должно идти перенаправление.

• Chain — srcnat;
• Src. Address — внутренняя подсеть;
• Dst. Address — IP-адрес сервера, на который должно идти перенаправление;
• Protocol — tcp;
• Dst. Port — 80,443;
• Action — masquerade;

Источник

Проброс rtsp потока через роутер mikrotik

Обнаружена блокировка рекламы: Наш сайт существует благодаря показу онлайн-рекламы нашим посетителям. Пожалуйста, подумайте о поддержке нас, отключив блокировщик рекламы на нашем веб-сайте.

Mikrotik и настройка RTSP для видеопотока с IP камеры

Всем привет. Помогите пожалуйста расколдовать загадку. Я в RouterOS не спец, и вообще от сетевых технологий далёк, но постараюсь максимально внять и понять тех, кто откликнится на помощь.

Имеем китайскую IP камеру TH38E5 с последней прошивкой, подключена к MikroTik hAP lite classic (RB941-2nD) с привязкой к 192.168.88.12, провайдер выдаёт статический белый IP, предположим 99.99.99.99. В настройках камеры доступ по 80 порту и 554. Плюс какой-то порт для PTZ, но это не интересует.
В Микротике сделал проброс портов, в том числе и для RTSP 554й порт.
Но, по rtsp ни одна прога не может подключится к камере и получить видеопоток ни в локалке ни из внешки((
Веб морда камеры доступна отовсюду.

/ip firewall filter add action=accept chain=forward connection-nat-state=dstnat in-interface=ether1 add action=accept chain=forward comment="forward and related connections" connection-state=established,related disabled=yes add action=drop chain=forward connection-state=invalid disabled=yes add action=accept chain=input connection-state=established,related disabled=yes add action=drop chain=input connection-state=invalid disabled=yes /ip firewall nat add action=masquerade chain=srcnat add action=masquerade chain=srcnat src-address=192.168.88.0/24 add action=dst-nat chain=dstnat dst-port=554 in-interface=ether1 protocol=tcp to-addresses=192.168.88.12 to-ports=554 add action=dst-nat chain=dstnat dst-address=99.99.99.99 dst-port=554 in-interface=bridge protocol=tcp src-address=192.168.88.0/24 to-addresses=192.168.88.12 to-ports=554 add action=dst-nat chain=dstnat dst-port=52777 in-interface=ether1 protocol=tcp to-addresses=192.168.88.12 to-ports=80 add action=dst-nat chain=dstnat dst-address=99.99.99.99 dst-port=52777 in-interface=bridge protocol=tcp src-address=192.168.88.0/24 to-addresses=192.168.88.12 to-ports=80 add action=dst-nat chain=dstnat dst-port=554 in-interface=ether1 protocol=udp to-addresses=192.168.88.12 to-ports=554

Конечно возможно стоит копать в настройках самой камеры, но всё же, как-то хочется убедится что в Микротике всё нормально. Как можно проверить проброс портов и убедится что при запросе по rtsp Микротик действительно направляет к камере, и как посмотреть что отвечает камера?

Vlad-2 Модератор Сообщения: 2531 Зарегистрирован: 08 апр 2016, 19:19 Откуда: Петропавловск-Камчатский (п-ов Камчатка) Контактная информация:

1) надеюсь в роутере Вы отключили веб-морду самого роутера на 80-м порту?
(IP-Services, www) ?
1.1) Управляеть надо/очень желательно только через утилиту Winbox

2) В Файрволе, в закладке NAT = рекомендую пробросы портов переместить выше, относительно правил
маскарада (ибо внутри роутера, пробросы обрабатываются раньше маскарада)
2.1) У Вас два правила маскарада, и то правило, где нет указания исходящей сети,
оно более глобально, и вдобавок оно стоит первее, поэтому оно и выполняется,
а второе правило — холостое, срабатывать оно не будет успевать.
Так что тут Вы перемудрили. Надо оставить одно.

3) НО всё это мелочи, главные ошибки тех, кто пытается сделать пробросы:

а) устройство, на которое мы(Вы) делаете проброс — оно должно быть правильно
настроено, а именно: у камеры Вашей должен быть обязательно задан шлюз,
и шлюз этот должен быть — локальный адрес роутера. Так что проверьте камеру
тоже, кроме адреса, маски, ШЛЮЗ должен быть обязательно задан (камера
должна знать куда ей «отвечать» на пришедшие запросы).

б) и ещё самая большая ошибка — при созданий правил проброса, проверять работу пробросов
надо с другого физического канала. То есть мы как бы приоткрыли дверь снаружи,
а многие начинающие делают пробросы, но лезут изнутри в эти же двери, и конечно же ошибка.
Самый простой способ, не выходя из дому: включаете на смартфоне режим ТОЧКИ доступа,
подключаете ноутбук через эту точку на смартфоне и уже работая в Интернете через смартфон,
и соответственно через сотового оператора, доходите до своего роутера снаружи и пытаетесь
зайти на камеру по открытому порту.
Для тестов на 5-10 минут (даже если нет на смартфоне включенного трафика), думаю
такой тест всё равно можно сделать. и сильно отразиться на балансе телефона.

И вот самые простые работающие правила пробросов (как пример Вам, ибо у Вас там тоже много лишнего)

/ip firewall nat add action=dst-nat chain=dstnat comment=mTorrents dst-port=1313 in-interface=pppoe-out1-RTK protocol=tcp to-addresses=192.168.0.11 to-ports=1313 add action=dst-nat chain=dstnat comment=mTorrents dst-port=1313 in-interface=pppoe-out1-RTK protocol=udp to-addresses=192.168.0.11 to-ports=1313 

На работе(ах): 2xCCR1016-12G, RB3011UiAS и hAP lite (RB941)
Дома: CCR1016-12G, RBcAP2n (standalone), RB wAP LTE kit
Для тестов(под рукой): RB3011UiAS, hAP mini (RB931) и что-то ещё по мелочи
MTCNA
MTCRE

Источник