Проблемы в работе ПО использующего WebRTC

Я проблему решил поднятием TURN на тех же серверах.
Причем при поднятии TURN на других, схема не работала. У нас медиа-сервер судя по всему не сильно гибок в сетевом плане и не мог поднять соединения с удаленным TURN.

У нас стоят и на тех же серверах, что и медиасервер, тоже. Пробовали с другими серверами в т.ч. в других странах.

Использование TCP/TCP+TLS с coturn не помогло в нашем случае.

Убедитесь, что действительно используется 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