LINUX.ORG.RU
Форум — Admin  

RTP over VPN потери ~100%

 , ,


1

2

Приветствую.

Через прокси mediamtx на централизованном сервере забирается стрим с условной «камеры», RTP в UDP, OpenVPN тоже UDP, VLC не показывает ничего (битрейт показывает порядка 10-20кбс), на прокси в логах потери ртп пакетов, если пущу трафик через TCP напрямую на проксю - видео показывает.

В чем может быть причина? Самое непонятное для меня - проблема всплывает на конкретных адресах, не везде, бывает уходит сама собой, что вообще можно продиагностировать?

Если глянуть tcpdump на сервере, то на впн интерфейсе вижу пакеты по 1472, которые местами уменьшаются до меньших величин, при этом если на сервере уже на интерфейсе с адреса, то всегда пакеты не более 784/780 байт, меньше могут, больше редкие исключения.

В traceroute криминала не вижу, до 30мс после 9 прыжков (но до шлюза провайдера или роутера, точно не знаю, адрес от stun сервера получаю)

★★★

Последнее исправление: wolverin (всего исправлений: 1)
← Посоветуйте по кубер и NixOS
Отдельный шлюз для виртуальных машин →

буферы уже все выкрутил на максимум, к примеру сейчас трафик порядка 200-300 мбит входящий из полосы в 1000, который заявляет таймвеб

net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 2)

Учитывая борьбу ркн с банообходчиками, возможно ты побочно попал под это. У тебя же все участники сети внутри страны расположены?

А ещё попробуй снизить mtu на внутреннем интерфейсе (это предположение наобум но вдруг из-за этого).

firkax ★★★★★
()
Ответ на: комментарий от wolverin

да внутри, ну а как то это выявить возможно?

Если снимешь tcpdump-ы на физическом ethernet-е на обоих концах соединения и будешь долго и мучительно их сравнивать - увидишь что какие-то пакеты потерялись например (с одного конца отправлены, на другой не пришли). Если да, то либо кто-то их случайно теряет по дороге (в том числе, возможно, из-за mtu), либо фильтры.

Если же все пакеты на месте - то проблема у тебя програмная где-то.

мту уменьшить на «камере»

Наверно. Я не до конца понял твою схему сети, речь была о том чтобы 1400 байтовых пакетов не создавал никто, а были все меньше 700.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

поставил отправку rtp пакетов в udp по 700 байт, проверил в tcpdump на сервере так и есть на vpn интерфейсе приходит не более этого значения (меньше тоже есть), при этом на внешнем интерфейсе с адреса приходят удп пакеты самого впн размером не более 760 байт - толку нет.

указание на «камере» значение мту для впн интерфейса 700/800 делает еще хуже - в родном варианте видео хоть когда то появляется, комбинация с пакетами в 700 байт тоже ничего не дает указание мту

wolverin ★★★
() автор топика
Ответ на: комментарий от anc

спасибо, пробую, текущий конфиг OpenVPN 2.4.11 в части «мту»

topology subnet


client-to-client
duplicate-cn

keepalive 10 120

cipher none

sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"

mute-replay-warnings

client-cert-not-required
username-as-common-name
script-security 2

fragment 1300
mssfix   1300

max-clients 16384
reneg-sec 86400
wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 3)

Если это железячная камера, то у нее может быть тупо кривая прошивка, не расчитанная на работу с MTU меньше 1500. Но еще можно проверить, работает ли pmtud на твоей сети. Лучше всего, когда icmp-ответы о необходимости фрагметации не сбиваются сетевым экраном)

Khnazile ★★★★★
()
Ответ на: комментарий от Khnazile

формально то все ходит (с камеры до прокси внутри впн), только видео почему то нет, либо задержка безумная

# ping -M do -s 1472 10.135.0.1
PING 10.135.0.1 (10.135.0.1) 1472(1500) bytes of data.
1480 bytes from 10.135.0.1: icmp_seq=1 ttl=64 time=27.6 ms
1480 bytes from 10.135.0.1: icmp_seq=2 ttl=64 time=27.4 ms
1480 bytes from 10.135.0.1: icmp_seq=3 ttl=64 time=30.0 ms
1480 bytes from 10.135.0.1: icmp_seq=4 ttl=64 time=27.8 ms
1480 bytes from 10.135.0.1: icmp_seq=5 ttl=64 time=27.7 ms
wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 1)
Ответ на: комментарий от wolverin

оке, в конфиге указано что mssfix 1300, поэтому тсп пакеты снаружи впн разбиваются до этого значения, но откуда берется цифра 780/784 для удп снаружи впн, даже если это разбиение одного 1472 на два, то я пробовал 1200 и все равно божественные 780 размеры…

настройка впн клиента

client
dev tun
proto udp

auth-nocache
resolv-retry infinite
nobind
topology subnet
pull
cipher none
ncp-disable
sndbuf 0
rcvbuf 0
fragment 1300
mssfix   1300
wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 2)
Ответ на: комментарий от anc

это изначальный конфиг, вдруг некорректно что то, поэтому привел, mtu-disc yes сейчас установлено, просто не вижу влияния это на что то, но я пробовал еще ставить tun-mtu 1400/1500, после чего клиенты подключаться перестали с варнингами в логах сервера на link-mtu

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 1)
Ответ на: комментарий от wolverin

mtu-disc yes сейчас установлено, просто не вижу влияния это на что то

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

пробовал еще ставить tun-mtu 1400/1500

1500 оно из каробки, а дальше уменьшайте кратным 40-ка, т.е. 1400 не айс, 1460, 1420, 1380. Посмотрел на свое разнообразие ручных установок разных лет, похоже остановился на 1380.

anc ★★★★★
()
← Посоветуйте по кубер и NixOS
Admin
Отдельный шлюз для виртуальных машин →