Можем ли мы ограничить диапазон клиентских портов для элемента GStreamer rtspsrc?
Мы работаем в строго контролируемой сетевой среде (в производстве), где нам необходимо блокировать порты, используемые для определенных целей.
В настоящее время нам необходимо открыть поток RTSP для какой-либо камеры, и мы маршрутизируем обратный трафик в зависимости от используемых портов (поскольку IP-адреса каждого производственного экземпляра могут сильно различаться).
Правила маршрутизатора в настоящее время работают нормально, но последнее правило — направлять весь трафик (еще не перехваченный предыдущими правилами) в ящик по умолчанию A. Похоже, что маршрутизатор слишком мало заботится об IP-адресах, вместо этого он направляет пакеты на определенные разъемы, к которым подключены машины. Итак, когда я говорю A или B, на самом деле это физический разъем на задней панели маршрутизатора.
Однако мы хотим иметь возможность направлять потоки камер GStreamer, инициированные из другого ящика B, обратно в этот ящик.
В настоящее время, когда я делаю netstat -na на B (в незаблокированной среде разработки), я вижу, что потоки RTSP используют различные клиентские порты от 35100 до 58712. Это гель с содержимым /proc/sys/net/ipv4/ip_local_port_range, на котором изображен 32768 60999.
Например (где .20.20 — машина B, а .30.30 — камера:
tcp 0 0 172.24.20.20:36250 172.24.30.30:8091 ESTABLISHED
Я подумал, что будет достаточно установить port-range в структуру props, используемую при создании элемента rtspsrc. Однако установка 4500-4999 по-прежнему приводит к тому, что вывод netstat показывает использование клиентских портов выше 30000.
Предполагается ли port-range управлять этими портами, используемыми для обратной потоковой передачи с камеры, или это для чего-то другого?
Если последнее, то как мы можем ограничить порты, используемые для потоковой передачи?
В качестве дополнительной информации, если необходимо, это словарь свойств и код, используемый для установки свойств элемента rtspsrc:
props = {
"protocols": "tcp",
"drop-on-latency": True,
"do-retransmission": False,
"latency": 100,
"port-range": "4500-4999",
"buffer-mode": 1,
}
elem = self.gstreamer.ElementFactory.make("rtspsrc", "source")
for name, prop in props.items():
elem.set_property(name, prop)
Ответы 1
Хорошо, многие часы тщательного просмотра исходного кода элементов RTSP и RTP, а также лучшее понимание того, как все это работает под обложкой, выявили тот факт, что ограничение портов работает только тогда, когда вы используете протокол UDP, а не ПТС как у меня.
Я заметил, что когда я использовал Wireshark для мониторинга подключения VLC к камере, он содержал предложение client_port=58100-58101 в строке SETUP, передаваемой камере. Этого пункта, в котором указаны порты RTP и RTCP, которые будут использоваться сервером, не было при запуске моего приложения.
Ограничение порта сохраняется в элементе независимо от протокола, но когда приходит время формировать сообщение SETUP, функция gst_rtspsrc_create_transports_string() конструирует его следующим образом (переформатировано для удобства чтения):
if (protocols & GST_RTSP_LOWER_TRANS_UDP) {
GST_DEBUG_OBJECT(src, "adding UDP unicast");
if (add_udp_str) {
g_string_append(result, "/UDP");
}
g_string_append(result, ";unicast;client_port=%%u1-%%u2"); // HERE.
} else if (protocols & GST_RTSP_LOWER_TRANS_UDP_MCAST) {
GST_DEBUG_OBJECT(src, "adding UDP multicast");
if (add_udp_str) {
g_string_append(result, "/UDP");
}
g_string_append(result, ";multicast");
if (src->next_port_num != 0) {
if ((src->client_port_range.max > 0)
&& (src->next_port_num >= src->client_port_range.max)) {
goto no_ports;
}
g_string_append_printf(result, ";client_port=%d-%d", // HERE.
src->next_port_num, src->next_port_num + 1);
}
} else if (protocols & GST_RTSP_LOWER_TRANS_TCP) {
GST_DEBUG_OBJECT(src, "adding TCP");
g_string_append(result, "/TCP;unicast;interleaved=%%i1-%%i2"); // NOT HERE.
}
Здесь вы можете видеть, что крайне важное предложение client_port=<low>-<high> добавляется только для одноадресной и многоадресной рассылки UDP, а не TCP.
Именно этот пункт определяет, к каким портам должен подключаться сервер RTSP для обратного трафика.
И действительно, изменение свойства protocols на udp решает проблему, гарантируя использование только нужных портов.