DTLS

Прикрути ручной попингуй

ничего не понял. Поясни?

Ну проверь, что не по таймауту отвал происходит.

Ну точно нет по тайамуту. Чего там пинговать, мой сервер и мой домашний уютный комп (но тестил на неограниченном числе соединений с разных ИП, результат тот же). Сервер доступен, потерь пакетов нет. Или нужно в момент отвала пинговать?

Ты за это время уже давно бы прикрутил попингуй и доложил обстановку.

3 лицо, да. Я много ошибок подмены tls например вижу, стоит трафик завернуть в обход всё нормализуется

прикрутил попингуй

Брат не умничай, говори нормальным языком, что это означает? Пинговать в момент отвала? Если да, то это не тривиально, пока нет такой возможности

У меня сервер в EU 6 лет работает в похожей конфигурации стабильно. Решил в РФ перенести, началаося какой то фуфел... То порты сначала гнали, перерь вот это...о боже

Божечки. Это означает гонять какой-нибудь порожняк в момент простоя внутри сессии, продолжать наблюдение и доложить о результатах.

Я когда-то игрался с gost, в том числе пробовал и dtls. По wireshark было много потерь пакетов, в отличие от ws или tls. Так что да, это 3 рыло чудит.

это интересное наблюдение. я не гоняла DTLS в этой стране (но при случае попробую, ради интереса).

наверное, можно попробовать обфускаторы TLS сессий. они прекрасно работают с обычным TLS и даже не сильно мешают трафику. что-нить типа Obfuscation-Tunnel. но их довольно много, можно выбирать на вкус и цвет.

у меня не dtls, а обычный иногда портят, особенно когда в сторону клаудфлары

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

Эээ...а нет простоя. Я tcpdump смотрю. Там же webrtc, как минимум звук даже пустые фреймы генерирует и шлет в сеть. Ладно я еще погоняю сегодня, будь на связи

Ооо, обмазаться говном и приворитья скунсом - хорошая идея ))

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

Firewall закрывает assured udp-сессию по таймауту, как вариант. Раутер на чем работает ?

Привет ещё раз, Уважаемый. Локализовал проблемку, сессии отваливаются ровно через 7 сек., когда сервер перестает слать ответные UDP пакеты. А он их перестает почему то слать в ответ, ирод. Сессия может часа 3 нормально идти и прекратиться «внезапно». Сервер лежит в докере, смотрю через tcpdump на внешней erh0 трафик и вижу, что, например в течении часа сервер каждую секунду стабильно слал ответ клиенту (ну не ответ конечно, а что там я не знаю шлет, траф зашифрованный, может какую то диагностику типа twcc). Но факт что он перестает вообще слать пакеты клиенту. А клиент в течении этих 7 сек. стабильно продолжает слать серверу. Не знаю, может до докера не доходят или че. То есть я их вижу на фейсе, а доке не видит. Такое может быть?

Сервер определяет «отвал» по разному, то как «dtls notify closed» или тупо timeout (видимо когда сервер оповещение не успел принять или клиент не отправил или отправил и потерялось)

Вот так примерно выглядит сессия
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Server:9000 -> Client:4545
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Server:9000 -> Client:4545
...
ну вот так шлет каждую сек. пакеты сервер
...
43s.
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
Client:4545 -> Server:9000
50s.
прошло 7 сек., сервер не шлет ничего, клиент пишет disconnect
Сервер получает dtls close и «просыпается», начинает слать клиенту чего то там, но клиент уже в отрубе
Server:9000 -> Client:4545
Server:9000 -> Client:4545
Server:9000 -> Client:4545


Или другой вариант, сервер не видит dtls notify и после некоторого времени начинает слать клиенту в течении 30 сек. пакеты и после этого пишет что timeout - session destroy

Брат привет. Траф приходит на eth0 от клиента стабильно, я его вижу tcpdump. Прочитай выше сообщение, я там подробнее описал

Скунсы как раз мы )) Те, которые обмазываются и притворяются бесполезными желудями, которых даже кабаны обходят стороной

А что такое «assured udp»? Да откуда я знаю какой то роутер, я сервер арендую... Но я написал и им уже, грешу тоже и на них... уже была история с tcp-портами-конектами, отнекивались поначалу, но потом все же исправили... Но это все время, зря потерянное время, не знаешь где, когда и во что вляпаешься

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

кабаны не обходят, а всё записывают и ставят галочку напротив. Если где-то насрано, пришлют пёсиков спросить.

Ну, сервер не отвечает на keep-alive, увеличь таймауты, сними дамп с обоих сторон, сравни.

keep-alive это в dtls сессии? Сервер их сам шлет по таймеру или клиент должен запросить? А таймаут я как увеличу в Chrome? Он кажется в коде железно зашит... 7 секунд это я вычислил...и отвал...если сервер чего то там не пришлет. Вот сейчас висят норм 6 сессий больше часа(рекорд !). правда одна все таки отвалилась через 40 минут (сервер написал что timeout)... Сейчас ещё на клиенте wireshark запущу

Да не гони, чего они могут там наскребсти? Максимум отрубить VPN сессию, мне кажется вся возня вокруг этого. А ну ещё reset поганый прислать если на какой-нибудь сайт заходишь. раньше хоть ещё писали нормально что вот сайт в реестре бла бла, сейчас пофиг уже на все эти реестры

Посмотрел wireshark

Последние пакеты до отвала (C - Client (port 4547), S - Server (port 9000))

С => S
тут много обычного UDP с периодическим STUN Binding Request
....
C => S: STUN Binding Request
C => S: DTSLv1.2 Encrypted Alert (Content Type 21 (это как я понимаю и есть close notify, который определяет сервер))

S => C: STUN Binding Success Response
C => S: ICMP Unreachable (Port unreachable)

Сессия продержалась почти 3 часа

Получается клиент шлет сам оповещение о закрытии DTLS?

Из очевидного:

C => S: STUN Binding Request
C => S: DTSLv1.2 Encrypted Alert (Content Type 21)

Вот тут у тебя мог внешний порт у клиента измениться. stun логи ведет? Можешь сравнить в момент разрыва и переподключения,

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

Типичный таймаут, используемый роутерами - 30 секунд. Т.е. для того, чтобы UDP-соединение всегда было активно, нужно хотя бы раз в 29 секунд посылать пакет от сервера к клиенту. Лучше - чаще.

Про таймаут в 7 секунд я не слышал, и он выглядит довольно коротким… Но кто его знает, что там в дикой природе встречается.

В общем такая версия «на подумать».

эээ... вот порты я не проверял... А что порт менять это вообще нормально, такое бывает?

stun логи ведет

Да, там подробные логи chrome://webrtc-internals

И за NAT и без НАТо. Отрубаются все клиенты в один момент времени. По timeout или dtls close...

Т.е. для того, чтобы UDP-соединение всегда было активно, нужно хотя бы раз в 29 секунд посылать пакет от сервера к клиент

Трафик льется непрерывно. Клиент шлет без остановки и в теории и я по tcpdump смотрел

Ну эио ж udp. Конечно нормально, плюс этот процесс ты не контролируешь. Было бы странно ожидать, что провайдер будет тебе гарантировать внешний порт их как бы ограниченное количество на всех.

А что у тебя там на сервере? RTPEngine? Ты вроде писал, что на забугорном VPS не было проблем, а на ру появились?

А ОС и там и там одинаковые? Версии ядра и всё такое?

Недавно столкнулись с проблемой, что после обновления ядра, стал тупить RTPEngine. Рандомно, то есть голос, то односторонняя слышимость. Там где слышимость односторонняя была, в дампе видно было ( да и в логах тоже ), что не устанавливалась связность, между браузером и RTPEngine, DTLS не согласовывался.

Да нет, не из-за этого. Плюс у меня белый ИП. Плюс отваливаются одновременно все сессии у всех пользователей. Я и телефона тестил и с компа. Кстати через телефон всех больше как ни странно сессию держит (андроид chrome),

Пора на ип6 переходить..!

А что у тебя там на сервере?

SRS - китайцы делают. Китайцы вообще молодцы, код генерируют как танки, быстро и то что нужно

А ОС и там и там одинаковые? Версии ядра и всё такое?

Нет конечно, не одинаковые, тот сервер 6 лет уже как... дебиан, а на ру убунту полугодичная.

Эээ…а нет простоя. Я tcpdump смотрю. Там же webrtc

Так может тут речь идет именно про webrtc а не dtls?

Пффф...webrtc это стек, объединяющий 1000 технологий, в том числе dtls там используется

КЭП, это понятно. Мне непонятно, у тебя dtls в контексте webrtc или нет? ЗЫ это все к тому, что у меня был опыт, рвался webrtc, и причина там была в потере пакетов stun пингов (а dtls там вообще используется только для обмена сессионными ключами на стартовом хендшейке пиров)