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

Введение

При работе с 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 маршрутизатора с определенного порта. Схема для наглядности:

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

Протокол TURN

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

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

Клиент с TURN-агентом отправляет сообщение на TURN-сервер для того, чтобы задетектить public IP-адрес (по аналогии со STUN), но вместо этого TURN-сервер посылает свои IP и порт. Клиент, как только получил от 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 не очень подходит для ряда решений:

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

Вывод

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