Серверы TURN (Traversal Using Relays around NAT)

TURN (Traversal Utilizing Relays around NAT) — это коммуникационный протокол, обеспечивающий взаимодействие систем тогда, когда прямые одноранговые каналы блокируются средствами NAT или сетевыми фильтрами. Протокол используется как основа работы TURN-серверов, которые функционируют в качестве промежуточного звена, перенаправляя потоки между клиентами и позволяя обмениваться информацией даже при жестких сетевых ограничениях.

С практической перспективы, TURN-сервера гарантируют стабильность работы цифровых сервисов (например, аудио и видеосвязи по технологии WebRTC), направляя пакеты через дополнительный узел при невозможности установить прямое соединение между абонентами. TURN-протокол закреплен как стандарт IETF (RFC 8656) и часто применяется вместе со STUN-протоколом в составе механизма обхода NAT для WebRTC.

STUN (Session Traversal Utilities for NAT) — это сетевой протокол, предназначенный для определения клиентом своего публичного IP-адреса и порта, отображаемых устройством NAT. Основное назначение STUN заключается в предоставлении минимально необходимой информации для установления прямого однорангового (peer-to-peer) соединения между участниками, находящимися за NAT.

В отличие от TURN, STUN-сервер не ретранслирует медиатрафик. Его задача сводится к обработке запроса от клиента и возврату внешнего сетевого идентификатора. Эти данные используются в механизме ICE (Interactive Connectivity Establishment) для формирования серверно-рефлексивных (server-reflexive) кандидатов и последующего согласования соединения между узлами в рамках WebRTC.

Роль TURN-протокола в WebRTC и коммуникациях в реальном времени

WebRTC (Web Real-Time Communication) использует схему ICE (Interactive Connectivity Establishment) для определения наилучшего маршрута передачи медиаданных между конечными узлами. ICE определяет доступность оконечных устройств друг для друга и при необходимости устанавливает между ними соединение по протоколам STUN или TURN.

Обычно WebRTC в первую очередь пытается создать подключение напрямую (через локальные адреса или внешние адреса, определенные при помощи STUN). Если STUN не достаточно (например, абоненты находятся за симметричным NAT), применяется TURN. Такой метод дает возможность обходить симметричный NAT, но приводит к росту задержки и нагрузке на сам NAT-сервер, так как трафик начинает идти через него, а не напрямую между клиентскими устройствами.

Следовательно, основная роль TURN состоит в обеспечении успешного соединения во время звонка или конференции даже тогда, когда прямое подключение по внешним или внутренним адресам оказывается недоступным.

STUN vs. TURN: в чем разница?

STUN и TURN — это взаимодополняющие сетевые протоколы, применяемые для обхода NAT, однако они решают различные задачи:

• STUN-протокол

Определяет публичный IP-адрес и сетевой порт устройства (его server-reflexive точку), формируя запрос к STUN-серверу. Такой механизм дает возможность двум клиентам наладить прямое соединение. После обмена адресами медиатрафик передается между устройствами без промежуточных серверов (peer-to-peer).

Однако ключевое ограничение STUN-протокола в том, что он не способен работать с некоторыми типами NAT (например, симметричным NAT). Данный метод остается предпочтительным при возможности его применения, так как не вносит дополнительных задержек из-за ретрансляции.

• TURN-протокол

Обеспечивает функцию ретрансляции в ситуациях, когда прямое соединение между клиентами недостижимо. В этом случае оба участника подключаются к одному TURN-серверу, который пересылает пакеты от одного клиента к другому.

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

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

Типичные сценарии использования TURN-протокола

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

Типичные сценарии:

• WebRTC-видеозвонки и конференции

Когда несколько участников запускают сетевую сессию, их программы формируют набор ICE-кандидатов. Если соединение невозможно через хостовые адреса или STUN (вследствие ограничений NAT), активируется TURN-протокол для передачи мультимедиа. Такой механизм обеспечивает стабильное продолжение вызова и предотвращает сбои связи.

• Корпоративные сети

Внутренние межсетевые экраны регулярно блокируют неизвестный UDP-трафик либо сужают исходящие подключения по номерам портов. TURN-сервер, запущенный на порту 443 с TLS, способен имитировать трафик под HTTPS и эффективно обходить подобные ограничения.

• Обход NAT для VoIP

URN гарантирует устойчивость P2P-подключений даже при активном использовании NAT, что особенно критично для VoIP-систем, где решающим аспектом выступает бесперебойная передача голоса: при сбоях связи или значительной задержке ухудшается качество разговоров, появляются разрывы речи и эхо.

Как функционирует TURN-протокол (процесс ретрансляции)?

Работу TURN-сервера можно условно разделить на несколько основных стадий:

• Размещение (Allocation)

Если клиент не способен установить прямое соединение с другим участником, он направляет запрос Allocate на TURN-сервер. В ответ сервер выделяет уникальный публичный IP-адрес и порт (транспортный адрес) для ретрансляции и возвращает его клиенту.

• Обмен кандидатами (Candidate Sharing)

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

• Ретрансляция данных (Data Relaying)

Клиенты направляют медиапакеты на адрес TURN-сервера, который пересылает их другому участнику. Для обеих сторон источником пакетов определяется IP-адрес TURN, что делает процесс ретрансляции полностью прозрачным.

• Контроль разрешений (Permission Enforcement)

TURN-сервер передает трафик исключительно между авторизованными клиентами, исключая риск несанкционированной пересылки данных.

Конфигурация TURN-сервера и особенности протокола

Перед внедрением TURN необходимо принимать во внимание ключевые условия и параметры конфигурации:

• Среда сервера

TURN-сервер может быть размещён как на выделенном физическом сервере, так и на виртуальной машине, главное чтобы он имел публичный IP-адрес доступный всем абонентам. Если сервер установлен за NAT, внешний IP следует прописать вручную, чтобы клиенты получали правильные relay-адреса.

• Порты и протоколы
• UDP (3478): основной способ передачи мультимедиа с минимальной задержкой.
• TCP (3478): применяется в качестве замены, если UDP заблокирован.
• TLS через TCP (5349): гарантирует шифрование и совместимость с брандмауэрами, но добавляет задержку.
• DTLS через UDP: предоставляет TLS-уровень защиты при сохранении производительности UDP.
• Аутентификация

Чтобы исключить открытые ретрансляторы, TURN требует учетных данных. В большинстве случаев используются либо долговременные учетные записи, либо ограниченные по времени токены, выдаваемые через REST API.

• Конфигурация

Основные параметры включают используемые порты, TLS-сертификаты, секретные ключи для аутентификации и диапазоны транспортных адресов.