Обзор протоколов STUN, TURN и ICE, их принципы работы с NAT и использование для VoIP

Введение При работе с IP-телефонией постоянно приходится сталкиваться с разного рода задачами связанными с сетью, т.к. эти области неразрывно связаны. В данной обзорной статье  рассматриваются протоколы STUN и ICE, их методы работы с NAT и практическое применение в работе с VoIP. Протокол STUN Название протокола – аббревиатура, можно расшифровать как Simple Traversal of UDP tрrough […]

Введение

При работе с IP-телефонией постоянно приходится сталкиваться с разного рода задачами связанными с сетью, т.к. эти области неразрывно связаны. В данной обзорной статье  рассматриваются протоколы STUN и ICE, их методы работы с NAT и практическое применение в работе с VoIP.

Протокол STUN

Название протокола – аббревиатура, можно расшифровать как Simple Traversal of UDP tрrough NAT или же по-русски «Простое прохождение UDP через NAT». Почему он нам интересен? Причина проста: как правило, многие устройства,  работающие по SIP’у, будь то голосовые шлюзы, ip-телефоны, софтфоны или же сами сервера с телефонии, по большей степени скрыты за NAT’ом. Это обусловлено по большей степени принципами безопасности и грамотной логикой построения сетей. Но периодически из-за этого возникают различные неприятные ситуации с прохождением, например, голосового потока. Для решения подобных проблем и был разработан этот STUN. Его основное назначение – дать возможность различным девайсам (за NAT’ом) узнать их public IP-адрес и найти пробросы портов. Как правило, STUN использует 3478 порт, которому обращается клиент (протокол является клиент-серверным).

Как это работает:

Устройством отправляется запрос к public IP STUN-сервера через маршрутизатор (шлюз), он, в свою очередь, перенаправляет его на STUN-сервер с внешним IP на порт 3478, ну а сервер отвечает устройству через маршрутизатор, сообщая, что запрос был сделан с внешнего IP маршрутизатора с определенного порта. Схема для наглядности:

Схема отправки запроса STUN-серверу и ответ

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

Протокол TURN

Теперь немного о протоколе TURN. Расшифровка названия —  Traversal Using Relays around NAT. Предназначается для работы с симметричным NAT’ом. Использует сервер для передачи данных от клиента (как и STUN является клиент-серверным протоколом) любому количеству устройств (пиров).

Принцип работы – грубо говоря, разбиение симметричного NAT на два не симметричных. А теперь немного подробнее:

Клиент с TURN-агентом отправляет сообщение на TURN-сервер для того, чтобы задетектить public IP-адрес (по аналогии со STUN), но вместо этого TURN-сервер посылает свои IP и порт. Клиент, как только получил от TURN-сервера данные, посылает их пиру. По тому же принципу работает и с противоположной стороны. Итогом получаем что голосовой и сигнальный трафик ходит через TURN-сервер (проксирование).

Изобразим этот процесс схематично для большей наглядности:

Схема работы TURN

Протокол ICE

Interactive Connection Establishment (интерактивное установление соединение) — это еще одно дополнение (суб-протокол) к протоколам STUN и TURN.

Основное назначение:

1. Собрать данные об интерфейсах
2. Проверить удаленные сервера STUN
3. Проверить удаленные сервера TURN
4. Проверить возможность установления соединения

Принцип работы довольно прост и тривиален: протокол последовательно собирает данные о возможности создания локального соединения между устройствами (пирами) по TCP или UDP. Если такой возможности нет, он проверяет возможность использования STUN во внешней сети, если и такой возможности не обнаруживается, ICE проверяет возможность использовать TURN во внешней сети (в том числе и проверяет доступность подключения к нескольким ближайшим TURN-серверам). После окончания сбора информации о структуре окружающей клиента сети, им (клиентом, создающим сессию) отправляется сообщение на TURN-сервер, содержащее полученную архитектуру ближайшей сети, а так же кидает запрос на создание сессии для пира, хранящий пачку IP-адресов, которые знает клиент. Пир соответственно отвечает множественными STUN-сообщениями по каждому из IP.

Рано или поздно, хотя бы одно из сообщений прилетит инициатору сессии, проскочив сквозь NAT. Как только клиент ответит на все такие сообщения, у пира появится карта сети по которой будет выбираться самый легкий для прохождения маршрут (этот процесс называется процедура номинирования пар) и выполняться проверка доступности между пиром и клиентом (могут ли они достучаться друг до друга). Приоритезация такая: без STUN – самый высокий приоритет, с использованием STUN – пониже, с TURN’ом – самый низкий. Ну и в конечном итоге, устанавливается соединение.

Логика ICE Схема работы ICE

Стоит отметить, что протокол ICE не очень подходит для ряда решений:

1. Если у нас большой прак оборудования
2. Если мы ведем запись на проксирующем сервере
3. Если у нас сложная структура сети с пересекающимися подсетями
4. Если очень критично время установки соединения

Вывод

В процессе изучения протоколов пришел для себя к выводу, что хоть ICE и считается довольно сильным протоколом, по сути своей, делающим всю грязную работу за STUN и TURN, его использование не всегда уместно и оправданно, стоит выбирать, каким из трех протоколов пользоваться, в зависимости от ситуации и поставленной задачи.

Введение в протоколы WebRTC — Интерфейсы веб API

В этой статье представлены протоколы, поверх которых построен WebRTC API.

Interactive Connectivity Establishment (ICE) «Установка интерактивного подключения» представляет собой каркас, позволяющий вашему веб-браузеру соединяться с узлами. Есть много причин, почему прямое соединение от узла A к узлу B просто не будет работать. Оно должно обойти межсетевые экраны, которые будут препятствовать открытию соединений, дать вам уникальный адрес, если, как в большинстве ситуаций, ваше устройство не имеет публичного IP-адреса, и передавать данные через сервер, если ваш маршрутизатор не позволяет вам напрямую соединяться с узлами. ICE использует некоторые из следующих технических приёмов, описанных ниже, для достижения этой цели:

Session Traversal Utilities for NAT (STUN) (акроним в акрониме) это протокол для нахождения и определения вашего публичного адреса и любых ограничений в вашем маршрутизаторе, которые препятствуют прямому соединению с узлом.

Клиент отправит запрос к STUN серверу в интернете, который ответит публичным адресом клиента и, доступен ли, или нет, клиент за NAT маршрутизатором.

Network Address Translation (NAT) используется для того, чтобы дать вашему устройству публичный IP-адрес. Маршрутизатор имеет публичный IP-адрес, а каждое устройство, подключённое к маршрутизатору имеет частный IP-адрес. Запросы будут транслированы от частного IP-адреса устройства к публичному IP-адресу маршрутизатора (с уникальным портом). Таким образом вам не нужен уникальный IP-адрес для каждого устройства, тем не менее, оно может быть обнаружено в интернете.

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

Некоторые маршрутизаторы, использующие NAT применяют ограничение, называемое «Симметричный NAT» (Symmetric NAT). Это означает, что маршрутизатор будет принимать соединения только от узлов, к которым вы ранее подключились.

Traversal Using Relays around NAT (TURN) предназначен для обхода ограничения «Симметричный NAT» путём открытия соединения с TURN сервером и ретрансляции всей информации через этот сервер. Вы создадите соединение с TURN сервером и сообщите всем узлам слать пакеты этому серверу, которые затем будут переправлены вам. Очевидно, что они приходят с некоторыми накладными расходами, поэтому это используется, только если нет других альтернатив.

Session Description Protocol (SDP) — это стандарт для описания мультимедийного контента соединения, как например: разрешение, форматы, кодеки, шифрование и т.д. Так, чтобы оба узла могли понять друг друга, после того как данные начнут передаваться. Это, в сущности, метаданные, описывающие содержимое, а не медиа контент сам по себе.

Last modified: 7 нояб. 2022 г., by MDN contributors

Введение в протоколы WebRTC — веб-API

В этой статье представлены протоколы, на основе которых построен API WebRTC.

Interactive Connectivity Establishment (ICE) — это структура, позволяющая вашему веб-браузеру подключаться к одноранговым узлам. Существует множество причин, по которым прямое соединение от узла А к узлу Б не работает. Он должен обходить брандмауэры, которые препятствуют открытию соединений, давать вам уникальный адрес, если, как и в большинстве ситуаций, ваше устройство не имеет общедоступного IP-адреса, и передавать данные через сервер, если ваш маршрутизатор не позволяет вам напрямую подключаться к одноранговым узлам. . Для этого ICE использует серверы STUN и/или TURN, как описано ниже.

Утилиты обхода сеанса для NAT (STUN) — это протокол для обнаружения вашего общедоступного адреса и определения любых ограничений в вашем маршрутизаторе, препятствующих прямому соединению с узлом.

Клиент отправит запрос на сервер STUN в Интернете, который ответит публичным адресом клиента и будет ли клиент доступен за NAT маршрутизатора.

Преобразование сетевых адресов (NAT) используется для предоставления вашему устройству общедоступного IP-адреса. Маршрутизатор будет иметь общедоступный IP-адрес, а каждое устройство, подключенное к маршрутизатору, будет иметь частный IP-адрес. Запросы будут транслироваться с частного IP-адреса устройства на общедоступный IP-адрес маршрутизатора с уникальным портом. Таким образом, вам не нужен уникальный общедоступный IP-адрес для каждого устройства, но вы все равно можете быть обнаружены в Интернете.

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

Некоторые маршрутизаторы, использующие NAT, используют ограничение, называемое «Симметричный NAT». Это означает, что маршрутизатор будет принимать соединения только от пиров, к которым вы ранее подключались.

Обход с использованием ретрансляции вокруг NAT (TURN) предназначен для обхода ограничения симметричного NAT путем открытия соединения с сервером TURN и ретрансляции всей информации через этот сервер. Вы создадите соединение с сервером TURN и скажете всем одноранговым узлам отправлять пакеты на сервер, которые затем будут перенаправлены вам. Это, очевидно, связано с некоторыми накладными расходами, поэтому оно используется только в том случае, если нет других альтернатив.

Протокол описания сеанса (SDP) — это стандарт для описания мультимедийного содержимого соединения, такого как разрешение, форматы, кодеки, шифрование и т. д., чтобы оба одноранговых узла могли понимать друг друга во время передачи данных. По сути, это метаданные, описывающие контент, а не сам медиаконтент.

Таким образом, технически SDP — это не настоящий протокол, а формат данных, используемый для описания соединения, которое разделяет медиаданные между устройствами.

Документирование SDP выходит за рамки этой документации; однако здесь есть несколько вещей, на которые стоит обратить внимание.

Структура

SDP состоит из одной или нескольких строк текста UTF-8, каждая из которых начинается с односимвольного типа, за которым следует знак равенства ( "=" ), за которым следует структурированный текст, содержащий значение или описание, формат которого зависит от типа. Строки текста, начинающиеся с данной буквы, обычно называются « буква -строки». Например, строки с описаниями мультимедиа имеют тип 9.0031 «m» , поэтому эти строки называются «m-строками».

Для получения дополнительной информации

Дополнительные сведения о SDP см. в следующих полезных ресурсах:

• Спецификация: RFC 4566: SDP: Протокол описания сеанса
• Реестр IANA параметров SDP

Последнее изменение: 25 ноября 2022 г. , участниками MDN ICE использует комбинацию методов, включая утилиту обхода сеанса для NAT (STUN) и обход с использованием ретрансляционного NAT (TURN). Наличие преобразователя сетевых адресов (NAT) создает проблемы для реализации передачи голоса по IP (VoIP) и WebRTC.

• Коммуникационное программное обеспечение
• Коммуникационный дизайн
• Установление мультимедийного сеанса WebRTC
• Технология передачи голоса по IP с использованием SIP Брандмауэр и хочет зарегистрировать свое местоположение у регистратора SIP, расположенного в общедоступном Интернете. SIP-устройство имеет немаршрутизируемый частный IP-адрес 192.168.0.10. SIP-устройство регистрирует свое местоположение у регистратора как sip:[email protected]:5060. Это сообщает регистратору, что с Бобом можно связаться по IP-адресу 19.2.168.0.10 на порту 5060 (порт SIP по умолчанию). Этот частный IP-адрес не имеет значения для устройства в общедоступном Интернете, и регистратор не знает, как связаться с Бобом.

  Второй пример связан с проблемами при отправке мультимедиа по транспортному протоколу реального времени (RTP). Алиса звонит Бобу, и приглашение Алисы содержит протокол описания сеанса (SDP) с ее локальным IP-адресом 10.1.1.10 и медиа-портом 1234. Боб принимает приглашение Алисы с его SDP, содержащим его локальный IP-адрес 192.168.0.10 и медиа-порт 1234. Оба этих IP-адреса адреса не имеют смысла за пределами частной локальной сети каждого человека, и ни одна из сторон не будет получать RTP-пакеты другой стороны.

  На рис. 1 показано типичное развертывание ICE с двумя агентами пользователя (UA), взаимодействующими через SIP (или другой сигнальный протокол, который выполняет обмен сообщениями SDP с предложением/ответом). ICE использует SIP, а это означает, что обход SIP через NAT должен обеспечиваться другим механизмом. ICE позволяет UA, которые изначально ничего не знают о своей топологии, получить достаточно информации о топологии, чтобы найти пути связи.

  Каждый из двух UA находится за NAT с неизвестными свойствами. Они способны обмениваться сообщениями SDP посредством обмена предложением/ответом, используемого для настройки мультимедийных сеансов между UA через SIP-сервер. Кроме того, ICE использует серверы STUN/TURN, каждый UA может иметь свой собственный или использовать один и тот же сервер. Оба UA имеют список транспортных адресов, которые можно использовать для связи с другим агентом. ICE используется для определения того, какие адреса могут соединяться друг с другом, и метода, используемого для установления этого соединения через NAT.

  Для выполнения ICE UA должны идентифицировать все адреса-кандидаты, транспортные адреса. Транспортные адреса представляют собой комбинацию IP-адреса и порта для определенного транспортного протокола. Существует три типа кандидатов:

  1. Host Candidate — транспортный адрес, связанный с локальным интерфейсом UA
  2. Relayed Candidate — транспортный адрес, связанный с сервером TURN (может быть получен только с сервера TURN)
  3. Серверный рефлексивный кандидат – преобразованный адрес на общедоступной стороне NAT (полученный либо с сервера STUN, либо с сервера TURN)

  На рисунке 2 показано отношение этих кандидатов к UA.

  После того, как UA1 соберет всех своих кандидатов, он упорядочивает их в порядке приоритета от высшего к низшему и отправляет их UA2 в атрибутах в сообщении предложения SDP. UA2 выполняет тот же сбор кандидатов и отправляет ответ SDP со своим списком кандидатов. Каждый UA берет два списка кандидатов и объединяет их в пары, чтобы получить пары кандидатов. Каждый UA собирает их в контрольные списки и планирует проверки подключения, транзакцию запроса/ответа STUN, чтобы увидеть, какие пары работают. На рис. 3 показаны компоненты пар кандидатов, составляющих контрольный список UA.

  Результатом тестирования обоих агентов является четырехэтапное рукопожатие на тех же самых портах, которые будут использоваться для мультимедиа. На рис. 4 показана базовая проверка подключения.

  ICE назначает одного из агентов «Контролирующим агентом», а другого — «Контролируемым агентом». Управляющий агент использовал допустимые пары кандидатов, чтобы назначить пару для использования в качестве носителя. Можно использовать два метода номинации:

  • Обычная номинация — проверки продолжаются до тех пор, пока не будет найдена хотя бы одна допустимая пара кандидатов. Управляющий агент выбирает из допустимых пар и отправляет второй запрос STUN по этой паре с флагом, чтобы сообщить узлу, что это тот, который назначен для использования.
  • Агрессивная номинация — Флаг номинации отправляется с каждым запросом STUN, как только первая проверка завершается успешно, обработка ICE для этого медиапотока завершается, и второй запрос STUN не требуется.

  На рис. 5 показан пример обеих номинаций.

  Каждая пара кандидатов в контрольном списке имеет связанное с ней состояние. Состояние назначается агентом пользователя после того, как контрольный список был вычислен. Возможны пять состояний:

  • Frozen — Эту пару можно проверить только после перевода в состояние ожидания. Чтобы войти в состояние ожидания, сначала должна пройти какая-то другая проверка.
  • Ожидание — Как только эта пара станет самой приоритетной в контрольном списке, будет выполнена проверка.
  • Выполняется — Для этой пары отправлен чек, и транзакция выполняется
  • Успешно — Успешный результат проверки пары.
  • Failed — Неверный результат проверки пары.

  На рис. 6 показана диаграмма состояний для пар-кандидатов.

  На рис. 7 показана упрощенная топология, которую мы будем использовать в примере потока связи ICE. Оба UA используют ICE и агрессивное назначение, если они являются контроллером. Оба просто используют один и тот же сервер STUN (который не требуется, но показан в этом примере для простоты), который прослушивает запросы привязки STUN. UA1 находится за NAT, который имеет свойство сопоставления, независимое от конечной точки, и свойство фильтрации, зависящее от адреса.

  На рисунке 8 показан поток этого примера связи ICE. После получения кандидата хоста со своего локального IP-адреса UA1 отправляет запрос привязки STUN для получения рефлексивного кандидата (сообщения 1–4). NAT создает привязку для запроса, который становится рефлексивным кандидатом сервера для RTP. Используя серверного рефлексивного кандидата, UA1 отправляет сообщение с предложением на UA2 (сообщение 5). UA2 переходит к получению рефлексивного кандидата сервера (сообщения 6 и 7), который идентичен своему кандидату хоста, поскольку не находится за NAT. Избыточный кандидат отбрасывается, остается только кандидат-хозяин.