RTSP за NAT на камере от XM

[2Dem]

Оказалось провайдер тестирует блокировку по протоколу, дали совет перейти на более прозрачный для кого надо протокол. Хотя через некоторое время тест закончился, но удалось отлично понять, что openvpn потухнет, а тот же ipsec прекрасно работает в любом случае.

За WG ни чего не говорили?

А это как раз второй протокол, который будет нельзя. Третий Shadowsocks. Как я понял, их использование видят, но понять что в них либо сложно, либо дорого, вот их и решили резать без анализа содержимого. Причем, что интересно, если с WG соединение сразу ломается, то Опен вроде бы работает, но скорости либо нет совсем, либо пинг в десятки тысяч. Шейду не пробовали.

[GenaSPB]

ну WG прежде еще надо поймать на каком порту он будет. Ну или как-то сложно анализировать трафик, чтобы понять что это он.

[2Dem]

ну WG прежде еще надо поймать на каком порту он будет. Ну или как-то сложно анализировать трафик, чтобы понять что это он.

Для ловли Wg им порт даже не нужен, они его на другом уровне ловят. Сначала палят рукопожатие хостов и после буквально пары ожидаемых для данного протокола полученных пакетов последующий udp-траффик нафиг блокируется.
А вот Опен походу сложнее вычислять, особенно когда он в tcp и на 443 порту, поэтому его скоростью зажимают, но с просветами.

[Veniamin-kHz]

Ну почему же сразу провайдер. Вы сейчас просто завернули данные в канал, которому пофиг на ваши пробросы. Я к тому, что ходящие слухи совсем не слухи. И скоро этот ваш OpenVPN будет тупо гаситься по форме, а не по содержанию, так как сейчас он очень легко определяется и уже были прецеденты его блокировки. Поэтому советую либо детальнее покопаться в поисках проблемы, либо переходить на более актуальные протоколы VPN.

VPN поднят на роутере проброс портов в этом случае всё-равно нужен, без него работать не будет. Ошибка там может быть, только если её делать намеренно, в правиле проброса меняется только Source Zone (с WAN на VPN). Копаться там больше просто не с чем. Начнут блокировать OpenVPN - буду искать другой вариант.

В целом завернуть все в VPN хорошее решение нежели пробрасывать порты, но что касаемо проброса rtsp его надо пробрасывать 1 в 1. т.е. если на камере 554, то и открываем 554. Если пробрасываем 1554, то и на камере надо выставить его на 1554 порту. И еще бывают траблы при использовании + кодеков и 265.

Насчёт проброса 1 в 1 - как-то сомнительно, если только предполагать какой-то специфический косяк в прошивке роутера, в любом случае, проверял и 1 в 1 и с другими портами во всех возможных комбинациях. Насчёт кодеков на камере особого выбора нет: либо 265, либо 265X (что бы это ни значило), их смена ни на что не влияет, тоже проверял.

[2Dem]

VPN поднят на роутере проброс портов в этом случае всё-равно нужен, без него работать не будет. Ошибка там может быть, только если её делать намеренно, в правиле проброса меняется только Source Zone (с WAN на VPN).

Что-то тут не то. Такое ощущение, что вы путаете открытие и проброс портов, а рассказываете про правила маршрутизации.

[kROOT]

За WG ни чего не говорили?

Этот тоже легко блокернуть, а вот амнезия с ее рандомными пакетами согласования сильно сложнее, а ставить для бытового потребления вообще элементарно, я удивился как далеко шагнула вперед автоматизация сисадминства, достаточно зарегать vds и передать логин и пароль программе, которая все сама настроит.

[Veniamin-kHz]

Что-то тут не то. Такое ощущение, что вы путаете открытие и проброс портов, а рассказываете про правила маршрутизации.

Вот стандартное окно настроек проброса портов в интерфейсе LuCI в OpenWRT, в одном случае в "Source zone" ставится WAN, в другом случае VPN.

[2Dem]

Что-то тут не то. Такое ощущение, что вы путаете открытие и проброс портов, а рассказываете про правила маршрутизации.

Вот стандартное окно настроек проброса портов в интерфейсе LuCI в OpenWRT, в одном случае в "Source zone" ставится WAN, в другом случае VPN.

В openwrt так информацию не показывают, для такого есть стоковая прошивка роутера, где все само автоматом делается. Понять, что в openwrt происходит можно, в данном случае, через iptables -nvL.

[GenaSPB]

Что-то тут не то. Такое ощущение, что вы путаете открытие и проброс портов, а рассказываете про правила маршрутизации.

Вот стандартное окно настроек проброса портов в интерфейсе LuCI в OpenWRT, в одном случае в "Source zone" ставится WAN, в другом случае VPN.

Ок. А VPN тогда куда открываете? Если просто на внешний какой-то ресурс, типа своей VPS или той-же амнезии и тут начинает работать, то вас провайдер парит насчет белого IP, либо блокирует 554 порт.

[2Dem]

Ок. А VPN тогда куда открываете? Если просто на внешний какой-то ресурс, типа своей VPS или той-же амнезии и тут начинает работать, то вас провайдер парит насчет белого IP, либо блокирует 554 порт.

Не, он ВПН-сервер на роутере поднимает, а подключается к нему клиентами и смотрит картинку. Так что да, тут либо провайдер с портами мутит, либо как я уже ранее написал, непонимание что есть что.

[Veniamin-kHz]

Не, он ВПН-сервер на роутере поднимает, а подключается к нему клиентами и смотрит картинку. Так что да, тут либо провайдер с портами мутит, либо как я уже ранее написал, непонимание что есть что.

Да, надо было сразу схему указать, а то не очень понятно было: PC (OpenVPN Server) <-> Router-1 <---ISP---> Router-2 (OpenVPN Client) <-> Camera