Traversal Using Relay NAT

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

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

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

Стандарт TURN описан в RFC 5766, обновление TURN для поддержки IPv6 описано в RFC 6156. Схема URI для TURN документирована в RFC 7065.

Введение

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

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

Законченное решение требует средств, с помощью которых клиент мог бы получить транспортный адрес, на который он мог бы получать поток данных от любого peer-а который может передавать пакеты данных в публичный интернет. Это может быть достигнуто лишь путём ретрансляции данных через сервер, который находится в общедоступном Интернете. Эта спецификация описывает Traversal Using Relay NAT (TURN), протокол, который позволяет клиенту получить IP-адреса и порты от таких peer-ов.

Хотя TURN будет почти всегда обеспечивать подключение к клиенту, он создает большую нагрузку на провайдера TURN-сервера. Поэтому рекомендуется использовать TURN только в крайнем случае, предпочитая другие механизмы (например, STUN или прямое подключение), когда это возможно. Для достижения этого может использоваться методология Interactive Connectivity Establishment (ICE), чтобы найти оптимальное средство связи.

Протокол

Процесс начинается, когда клиентский компьютер хочет установить связь с другим узлом для передачи данных, но не может этого сделать, поскольку и клиент, и узел находятся за соответствующими NAT. Если STUN не является подходящим вариантом из-за того, что один из 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 или резервирование канала — TURN-сервер получает данные от клиента и ретранслирует их узлу с помощью UDP-дейтаграмм, которые содержат в качестве адреса отправителя «выделенный транспортный адрес ретранслятора». Узел получает данные и отвечает, снова используя UDP-дейтаграмму в качестве транспортного протокола, отправляя UDP-дейтаграмму на адрес ретранслятора на TURN-сервере.

TURN-сервер получает UDP-дейтаграмму от узла, проверяет разрешения, и если они действительны, пересылает её клиенту.

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

Хотя TURN более устойчив, чем STUN, в том смысле, что он помогает в преодолении большего количества типов NAT, коммуникация через TURN ретранслирует весь обмен данными через сервер, требуя гораздо большей серверной полосы пропускания, чем протокол STUN, который обычно только определяет внешний IP-адрес и передаёт информацию клиенту и узлу для использования ими в прямой коммуникации. По этой причине протокол ICE предписывает использование STUN в качестве первого средства и использование TURN только при работе с симметричными NAT или в других ситуациях, когда STUN не может быть использован.