Убедитесь, что действительно используется TLS для передачи данных. Снимите трафик соединения хотя бы у одного пользователя, у кого наблюдается проблема.
Добрый день! Подскажите, вы решили проблему? Тоже используем медиасуп и столкнулись с аналогичными проблемами. Установка TURN сервера COTURN на один сервер с mediasoup не помогла. Настройки coturn следующие:
listening-port=3478
tls-listening-port=5349
fingerprint
verbose
lt-cred-mech
user=USER:PASSWORD
realm=turn.example.ru
cert=/etc/letsencrypt/live/turn.example.ru/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.ru/privkey.pem
dh2066
no-tlsv1
no-tlsv1_1
syslog
cipher-list="ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384"
Запишите PCAP, чтобы понять, в чём может быть проблема. Либо выдайте мне доступ и проинструктируйте, как воспроизвести проблему.
Спасибо, что откликнулись. Можете связаться в скайпе со мной?
скайп - iluha90
Насколько понимаю, блокировка так или иначе затрагивает только библиотеку Pion, в частности supported_groups, который он отправляет.
Если у кого-то есть другие данные, или если кто-то может предоставить дамп трафика неработающей конфигурации, прошу написать мне или выложить дамп сюда.
У нас таже самая проблема, получается так, что от клиента трафик уходит, но другим уже не доходит. VPN решает проблему. Пробовали европейские сервера, снгшные и Российские - не работают. Сервера на территории США - работают для этих же российских клиентов.
Интересно. Мы с @diwenx обнаруживали, что ТСПУ исключает некоторые фильтры для трафика внутри России, но для США такого не видели. Можете назвать AS или хостера, где работает?
И кто-нибудь, запишите уже pcap’ы или дайте мне доступ к вашим системам, чтобы я их записал самостоятельно, или пришлите ссылку на какой-то публичный инстанс, где это развёрнуто.
AWS, регион N. Virginia
Нам пишут:
Наконец-то мем был обнаружен, проблема появляется у некоторых людей и оказывается, что актуальна только на старых версиях chromium. У нас стоит 91 и на ней ничего не работает. Пробовали заходить с 95 версии хрома, уже работает отлично
echo 16FEFF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001D00170018 | xxd -ps -r > chromium-clienthello-maybe.bin
00000000 16 fe ff 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 1d 00 17 00 18 |................|
00000070
supported_groups начинается с 0x6a.
chromium-maybe-91-clienthello-tspu-filtered.pcapng (680 Bytes)
As of 1 June 2022, the following WebRTC DTLS packets are getting filtered.
The filter is applied for both DTLS v1.0 in record (16 fe ff), which is used by both Chrome and Firefox in ClientHello, and DTLS v1.2 in record (16 fe fd), which is used at least by Jitsi Meet, all at offset 0. Then, 00 1D 00 17 00 18 at 0x6e offset or 0x59 offset or 0x6a offset is checked.
Old pattern and old offset 0x59, but with additional check for DTLS version:
16 FE [FD or FF] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1D 00 17 00 18 00
Old pattern and new offset 0x6e (used in the first ClientHello DTLS packet in Snowflake, the one without Cookie and with message sequence = 0), with additional check for DTLS version:
16 FE [FD or FF] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1D 00 17 00 18 00
Old pattern and new offset 0x6a, presumably Chromium <= 91:
16 FE [FF or FD] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1D 00 17 00 18
Обнаружил дополнительные смещения supported_groups, которые подвергаются блокировке.
Всего 7 штук. Номер в имени файла означает количество нулей после 16 FE FD/FF и до supported_groups.
webrtc-filtered.zip (1.3 KB)
I got a private message saying that all these offsets are filtered: 0x50, 0x54, 0x59, 0x6a, 0x6e, 0x7e, 0x82.
I guess the question is, is there a commonly used offset that is not filtered?
Your 7 discovered offsets match the report exactly.
$ unzip -l webrtc-filtered.zip
Archive: webrtc-filtered.zip
Length Date Time Name
--------- ---------- ----- ----
112 2022-06-01 00:30 webrtc-filtered-103.bin
116 2022-06-01 00:30 webrtc-filtered-107.bin
132 2022-06-01 00:30 webrtc-filtered-123.bin
136 2022-06-01 00:30 webrtc-filtered-127.bin
86 2022-06-01 00:30 webrtc-filtered-77.bin
90 2022-06-01 00:30 webrtc-filtered-81.bin
95 2022-06-01 00:30 webrtc-filtered-86.bin
--------- -------
767 7 files
>>> print(", ".join(sorted([hex(x+3) for x in (103, 107, 123, 127, 77, 81, 86)])))
0x50, 0x54, 0x59, 0x6a, 0x6e, 0x7e, 0x82
Firefox/newer Chrome versions are not filtered. WebRTC conferences like Jitsi Meet work in Firefox/Chrome just fine.
Подтверждаю, проблема решилась обновлением библиотеки клиента, где была уже 97 версия хромиума. Тестировали еще 96 версию - работает. 93я версия еще проблемная, 94ю версию не проверяли.
The filter for WebRTC payload with 103 zeros in the middle has been lifted. All other filters are still in place.
Заблочен DTLS HelloVerifyRequest c 20d байтными кукисами
Datagram size: 30
16 FE [FD or FF] offset 00
03 offset 0D
За последнюю неделю было много жалоб, количество растет. В клиенты подключены к Ростелекому.
Пакеты DTLS Client Hello уходят на сервер, но до сервера не доходят.
В пакете все тот же знакомы набор шифров.
Также есть клиенты на Ростелекоме, у которых все нормально
Год назад сталкивались с этой проблемой, потом замялась, жалобы перестали идти. Сейчас вновь активизировались.
Сталкивался ли кто-то вновь с данной проблемой?
Помогите пожалуйста у меня не слышно как говорит абонент что мне делать?