Скрапинг трафика WebRTC в Janus

Автор этой статьи, автор проекта Janus, Лоренцо Миньеро, приедет в Пекин 25 октября, чтобы поделиться навыками разработки WebRTC-серверов и разработки Janus на семинаре «WebRTC Workshop» конференции RTC 2019, а также пообщаться с аудиторией. на небольшой площади.Количество мест ограничено.Запишитесь прямо сейчас:2019.rtcexpo.org/

Краткое содержание этой статьи: Скрапинг WebRTC-трафика кажется относительно простым, и в большинстве случаев так оно и есть: вам просто нужно установить что-то вродеtcpdumpилиwiresharkИнструмент захвата пакетов, а затем просмотреть сгенерированный файл, в большинстве случаев это будет файл .pcap или .pcapng. Эти действия полезны для диагностики проблем с подключением или других проблем, связанных с WebRTC: на самом деле wireshark может автоматически обнаруживать стандартные протоколы, такие как STUN, DTLS и т. д., которые вызывают озабоченность WebRTC PeerConnections.

Что является ключевым в этой статье?

Единственная проблема парсинга WebRTC-трафика заключается в том, что медиаконтент зашифрован. Это не проблема при проверке соединения STUN или рукопожатия DTLS, но это будет проблемой, когда вы хотите просмотреть пакеты RTP или RTCP, которые будут зашифрованы как SRTP и SRTCP. На самом деле, несмотря на то, что заголовок SRTP не зашифрован, вы можете перехватывать трафик в любой форме, но полезная нагрузка SRTP — нет, то есть вы не можете просмотреть ее содержимое.

Большую часть времени вам не нужно просматривать содержимое. Как и ожидалось, вы по-прежнему можете просматривать заголовки зашифрованных RTP-пакетов, наиболее часто используемую информацию. Во всяком случае, этого нельзя сказать о RTCP: на самом деле RTCP-сообщение может фактически содержать более одного пакета, а общего заголовка нет. Помимо этого, может сработать просмотр полезной нагрузки RTP.

Это означает, что захват зашифрованного трафика — это нормально, но захват незашифрованных данных для диагностических целей может быть лучше. К сожалению, это невозможно без посторонней помощи: на практике браузеры часто отправляют зашифрованные данные с помощью WebRTC, даже еслиНекоторые из них позволяют очищать незашифрованные данные.для тестирования, но вам все равно нужно полагаться на другие инструменты, чтобы заставить медиапоток заставить эту работу работать.

Входит Янус!

Как медиа-сервер WebRTC, Janus выполняет свою работу: фактически он существует на каждом медиа-пути PeerConnection. Кроме того, он может получать входящие и исходящие незашифрованные пакеты RTP и RTCP, поскольку устанавливает отдельный контекст безопасности для каждого однорангового соединения.

Мы подумали об этом год назад и, вдохновленные Firefox, впервые добавилиtext2pcapДля поддержки дампа используется простой подход:

1. ИспользуйтеAdmin API, чтобы начать сбор информации о файлах обработки Janus. 2. Все входящие и исходящие пакеты RTP/RTCP преобразуются в текстовый формат и сохраняются в соответствующих файлах. 3. После захвата используйте приложение text2pcap, чтобы преобразовать захваченный файл в формат, совместимый с Wiresharac или другими инструментами.

Синтаксис запроса прост:

POST /admin/sessionId/handleId
{
        "janus" : "start_text2pcap",
        "folder" : "<folder to save the dump to; optional, current folder if missing>",
        "filename" : "<filename of the dump; optional, random filename if missing>",
        "truncate" : "<number of bytes to truncate at; optional, won't truncate if 0 or missing>",
        "transaction" : "<random alphanumeric string>",
        "admin_secret" : "<password specified in janus.cfg, if any>"
}

Если вы знаете соответствующий сеанс и идентификатор дескриптора, вы можете легко сгенерировать код, чтобы начать захват дескриптора:

curl -X POST -H "Content-Type: application/json" -d '{"janus": "start_text2pcap", "folder": "/tmp", "filename": "my-test2pcap-dump.txt", "transaction": "123", "admin_secret": "janusoverlord"}' http://localhost:7088/admin/8412133783240844/2377476017639045

В итоге у вас получится такой текстовый файл:

I 18:47:14.126004 000000  80 e0 6c 5d [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
O 18:47:14.128251 000000  80 e0 04 83 [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
I 18:47:14.136577 000000  80 6f 54 8d [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
O 18:47:14.136659 000000  80 6f 03 9f [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]

Вы мало что можете сделать с этим файлом: мы видим некоторые пакеты ввода-вывода, сохраненные в какой-то момент, и мы можем видеть шестнадцатеричное значение полезной нагрузки с некоторой информацией об окружающей среде в конце каждой строки. Вам нужно передать его другим инструментам, таким как text2pcap, чтобы преобразовать его в файл, который вы можете прочитать:

text2pcap -D -n -l 1 -i 17 -u 1000,2000 -t '%H:%M:%S.' /tmp/my-test2pcap-dump.txt /tmp/my-test2pcap-dump.pcapng

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

Но разве сериализация текста не должна быть неэффективной?

Я рад, что вы задали этот вопрос!

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

Нам нужен другой способ сэкономить непосредственно в Януснеобработанный pcapвместо того, чтобы преобразовывать его в текстовый файл и обрабатывать позже. Этот метод имитирует парсинг текста, но с небольшим отличием: 1. Как и раньше, вы используете Admin API, чтобы начать парсинг файла в Janus, но с другим запросом. 2. Глобальные заголовки Pcap сохраняются перед сканированием. 3. Все входящие и исходящие пакеты RTP/RTCP сохраняются в виде файлов, но сначала создаются поддельные заголовки ethernet/IP/UDP и префикс заголовков пакетов pcap.

Вы могли заметить, что обработка записи здесь не включена: поскольку мы сохраняем непосредственно в файл pcap, это означает, что как только мы прекращаем парсинг, файл генерируется, эксплуатируется с использованием соответствующего инструмента. Кроме того, поскольку нет необходимости в текстовой сериализации, а требуется непосредственно в файл, этот процесс становится легковесным, его влияние в основном незначительно, и он хорошо сочетается с функцией записи мультимедиа в Janus.

Хотя вы используете другой метод для сохранения в виде файла .pcap и он называется start_pcap вместо start_text2pcap, он имеет точно такой же синтаксис, как и предыдущий: это означает, что вы можете предоставить ту же информацию, что и раньше, и сохранить ее, сокращенную или нет. Глядя на предыдущий пример, следующий формат запроса:

curl -X POST -H "Content-Type: application/json" -d '{"janus": "start_pcap", "folder": "/tmp", "filename": "my-pcap-dump.pcap", "transaction": "123", "admin_secret": "janusoverlord"}' http://localhost:7088/admin/8412133783240844/2377476017639045

Обратите внимание, что мы изменили только имя запроса и расширение целевого файла. Все остальное точно так же.

Все это страшно (мне лень пользоваться curl)

До сих пор мы объясняли, что Jauns предоставляет для извлечения незашифрованных данных и как использовать запрос Admin API, чтобы воспользоваться этой функцией. В любом случае, вы, вероятно, не захотите делать это вручную или через командную строку. К счастью, я подготовил фиктивный интерфейс для этих вещей!

В отчете Janus представлены некоторые доступные веб-демонстрации, включая интерфейс Admin API. Этот интерфейс находится вв предыдущих статьяхОн был подробно рассмотрен, особенно с использованием информации, которую он предоставляет для диагностики проблем. Мы не будем повторять эти детали, а сосредоточимся на том, как вы должны начать или остановить сканирование определенного файла в Janus. Конечно, мы предполагали, что выКонфигурация HTTP-плагинаBackend API API включена в.

Если у вас есть самая последняя версия презентации Janus, откройте API admin, попробуйте перемещаться по существующему сеансу, выберите определенную ручку. Вы должны увидеть до фактической обработки информации под названием «Открытый флажок».

Щелкните его следующим образом:

Большинство настроек должны быть четкими и простыми для понимания, так как мы рассмотрели их, когда рассматривали синтаксис запросов Admin API. Первый позволяет выбрать тип захвата, рассмотренный ранее, либо сохранить сразу в pcap, либо преобразовать в текстовый файл и затем обработать.

Затем вас попросят указать путь для сохранения файла:

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

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

Текущее состояние сканирования также отображается в информации о ручке:

После завершения захвата, с text2pcap или без него, используйте wireshark, и вы получите файл, который можно использовать. Предполагая, что используется Wireshark, интерфейс захвата выглядит следующим образом:

Как и ожидалось, мы видим два разных IP-адреса (10.1.1.1 и 10.2.2.2), которые обмениваются данными друг с другом через разные порты. Когда Janus захватывает трафик, 10.1.1.1:1000 всегда является адресом партнера, а 10.2.2.2:2000 всегда является собственным адресом Janus.

Конечно, сам Wireshark не может определить, является ли содержимое этих UDP-пакетов информацией RTP и RTCP. Это то, что нам нужно сказать, чтобы декодировать информацию о трафике в RTP.

После этого информация, отображаемая Wireshark, изменится:

Как видите, Wireshark отвечает за объяснение заголовка RTP и позволяет нам наблюдать и анализировать его. Можно сказать, что можно сказать нагрузке, которая будет расшифрована, и мы можем его увидеть.

Малоизвестная особенность Wireshark заключается в том, что он также поддерживает декапсуляцию некоторых медиакодеков. Это означает, что если вы сообщите Wireshark, что пакет содержит мультимедийную информацию, закодированную в определенном кодеке, он предоставит вам информацию о конкретном кодеке. В нем кодеки VP8 и H.264, так что если в настройках стабильно ассоциировать payload type 96 с VP8, то отображаемая информация снова изменится:

Хотя этот снимок экрана похож на предыдущий, есть некоторые ключевые отличия: например, обратите внимание, как столбец протокола преобразуется из RTP в VP8 для всех пакетов, упакованных в тип 96. Это означает, что Wireshark использует более продвинутое декодирование, а также может отслеживать полезную нагрузку: в случае VP8 это означает получение фактического содержимого медиапотока с префиксом описания полезной нагрузки VP8. Конечно, это выходит за рамки этой статьи, и их единственная цель — показать, как вы должны получить эту информацию: если вы хотите узнать больше о диагностике таких вещей, вы можете обратиться к отличной статье.статья,это изPhilipp Hanckeнаписано.