Traversal Using Relays around NAT ( TURN ) — это протокол , который помогает в обходе сетевых трансляторов адресов (NAT) или брандмауэров для мультимедийных приложений. Он может использоваться с Transmission Control Protocol (TCP) и User Datagram Protocol (UDP). Он наиболее полезен для клиентов в сетях, замаскированных симметричными устройствами NAT . TURN не помогает в запуске серверов на известных портах в частной сети через NAT; он поддерживает подключение пользователя за NAT только к одному одноранговому узлу, как, например, в телефонии.
TURN определен в RFC 8656. Схема TURN URI задокументирована в RFC 7065.
Трансляция сетевых адресов (NAT), механизм, который служит мерой для смягчения проблемы исчерпания адресов IPv4 при переходе на IPv6 , сопровождается различными ограничениями. Самым проблемным из этих ограничений является тот факт, что NAT нарушает работу многих существующих IP-приложений и затрудняет развертывание новых. [1] Были разработаны руководящие принципы, описывающие, как создавать «дружественные NAT» протоколы, но многие протоколы просто невозможно построить в соответствии с этими руководящими принципами. Примерами таких протоколов являются мультимедийные приложения и обмен файлами.
Session Traversal Utilities for NAT (STUN) предоставляет один из способов для приложения пройти NAT. STUN позволяет клиенту получить транспортный адрес (IP-адрес и порт), который может быть полезен для получения пакетов от однорангового узла. Однако адреса, полученные STUN, могут не использоваться всеми одноранговыми узлами. Эти адреса работают в зависимости от топологических условий сети. Поэтому STUN сам по себе не может предоставить полное решение для обхода NAT.
Полное решение требует средства, с помощью которого клиент может получить транспортный адрес, с которого он может получать медиа от любого однорангового узла, который может отправлять пакеты в публичный Интернет. Это может быть достигнуто только путем ретрансляции данных через сервер, который находится в публичном Интернете. Traversal Using Relays around NAT (TURN) — это протокол, который позволяет клиенту получать IP-адреса и порты от такого ретранслятора.
Хотя TURN почти всегда обеспечивает подключение к клиенту, это ресурсоемко для провайдера сервера TURN. Поэтому желательно использовать TURN только в крайнем случае, предпочитая другие механизмы (такие как STUN или прямое подключение), когда это возможно. Для этого можно использовать методологию Interactive Connectivity Establishment (ICE) для поиска оптимальных средств подключения.
Процесс начинается, когда клиентский компьютер хочет связаться с одноранговым компьютером для транзакции данных, но не может этого сделать, поскольку и клиент, и одноранговый компьютер находятся за соответствующими NAT. Если STUN не подходит, поскольку один из NAT является симметричным NAT (тип NAT, известный как несовместимый со STUN), необходимо использовать TURN.
Сначала клиент связывается с сервером TURN с запросом "Allocate". Запрос Allocate просит сервер TURN выделить некоторые из своих ресурсов для клиента, чтобы он мог связаться с одноранговым узлом. Если выделение возможно, сервер выделяет клиенту адрес для использования в качестве ретранслятора и отправляет клиенту ответ "Allocation Successful", содержащий "выделенный ретранслируемый транспортный адрес", расположенный на сервере TURN.
Во-вторых, клиент отправляет запрос CreatePermissions на сервер TURN, чтобы создать систему проверки разрешений для одноранговой связи. Другими словами, когда с одноранговой связью наконец-то связываются и она отправляет информацию обратно на сервер TURN для передачи клиенту, сервер TURN использует разрешения для проверки того, что одноранговая связь с сервером TURN является допустимой.
После создания разрешений у клиента есть два варианта отправки фактических данных: (1) он может использовать механизм Send или (2) он может зарезервировать канал с помощью запроса ChannelBind. Механизм Send более прост, но содержит больший заголовок, 36 байт, что может существенно увеличить пропускную способность в ретранслируемом TURN-разговоре. Напротив, метод ChannelBind легче: заголовок составляет всего 4 байта, но он требует резервирования канала, который необходимо периодически обновлять, среди прочих соображений.
Используя любой из методов, Send или Channel Binding, сервер TURN получает данные от клиента и ретранслирует их одноранговому узлу с помощью UDP-дейтаграмм, которые содержат в качестве исходного адреса «Выделенный ретранслируемый транспортный адрес». Одноранговый узел получает данные и отвечает, снова используя UDP-дейтаграмму в качестве транспортного протокола, отправляя UDP-дейтаграмму на адрес ретрансляции на сервере TURN.
Сервер TURN получает одноранговую UDP-датаграмму, проверяет разрешения и, если они действительны, пересылает ее клиенту.
Этот процесс обходит даже симметричные NAT, поскольку и клиент, и одноранговый узел могут, по крайней мере, взаимодействовать с сервером TURN, который выделил ретрансляционный IP-адрес для связи.
Хотя TURN более надежен, чем STUN, поскольку он помогает в прохождении большего количества типов NAT, связь TURN ретранслирует всю связь через сервер, требуя гораздо большей пропускной способности сервера, чем протокол STUN, который обычно разрешает только публичный IP-адрес и ретранслирует информацию клиенту и одноранговому узлу для использования их в прямой связи. По этой причине протокол ICE предписывает использование STUN в качестве первого средства, а использование TURN — только при работе с симметричными NAT или в других ситуациях, когда STUN использовать невозможно.