El recorrido mediante retransmisiones alrededor de NAT ( TURN ) es un protocolo que ayuda a atravesar traductores de direcciones de red (NAT) o firewalls para aplicaciones multimedia. Puede usarse con el Protocolo de control de transmisión (TCP) y el Protocolo de datagramas de usuario (UDP). Es más útil para clientes en redes enmascaradas por dispositivos NAT simétricos . TURN no ayuda a ejecutar servidores en puertos conocidos de la red privada a través de NAT; admite la conexión de un usuario detrás de un NAT a un solo par, como en telefonía, por ejemplo.
TURN está especificado en RFC 8656. El esquema TURN URI está documentado en RFC 7065.
La traducción de direcciones de red (NAT), un mecanismo que sirve como medida para mitigar el problema del agotamiento de las direcciones IPv4 durante la transición a IPv6 , viene acompañada de varias limitaciones. La más problemática de estas limitaciones es el hecho de que NAT interrumpe muchas aplicaciones IP existentes y dificulta la implementación de otras nuevas. [1] Se han desarrollado pautas que describen cómo construir protocolos "compatibles con NAT", pero muchos protocolos simplemente no se pueden construir de acuerdo con esas pautas. Ejemplos de tales protocolos incluyen aplicaciones multimedia y uso compartido de archivos.
Session Traversal Utilities for NAT (STUN) proporciona una forma para que una aplicación atraviese una NAT. STUN permite a un cliente obtener una dirección de transporte (una dirección IP y un puerto) que puede ser útil para recibir paquetes de un par. Sin embargo, es posible que las direcciones obtenidas por STUN no sean utilizables por todos los pares. Esas direcciones funcionan dependiendo de las condiciones topológicas de la red. Por lo tanto, STUN por sí solo no puede proporcionar una solución completa para el cruce de NAT.
Una solución completa requiere un medio por el cual un cliente pueda obtener una dirección de transporte desde la cual pueda recibir medios de cualquier par que pueda enviar paquetes a la Internet pública. Esto sólo se puede lograr transmitiendo datos a través de un servidor que reside en la Internet pública. El recorrido transversal mediante retransmisiones alrededor de NAT (TURN) es un protocolo que permite a un cliente obtener direcciones IP y puertos de dicha retransmisión.
Aunque TURN casi siempre proporciona conectividad a un cliente, requiere muchos recursos para el proveedor del servidor TURN. Por lo tanto, es deseable utilizar TURN sólo como último recurso, prefiriendo otros mecanismos (como STUN o conectividad directa) cuando sea posible. Para lograrlo, se puede utilizar la metodología Interactive Connectivity Establishment (ICE) para descubrir los medios óptimos de conectividad.
El proceso comienza cuando una computadora cliente quiere contactar a una computadora par para una transacción de datos, pero no puede hacerlo debido a que tanto el cliente como el par están detrás de las respectivas NAT. Si STUN no es una opción porque una de las NAT es una NAT simétrica (un tipo de NAT que se sabe que no es compatible con STUN), se debe utilizar TURN.
Primero, el cliente contacta a un servidor TURN con una solicitud de "Asignación". La solicitud Allocate le pide al servidor TURN que asigne algunos de sus recursos al cliente para que pueda contactar a un par. Si la asignación es posible, el servidor asigna una dirección para que el cliente la use como retransmisión y le envía una respuesta de "Asignación exitosa", que contiene una "dirección de transporte retransmitida asignada" ubicada en el servidor TURN.
En segundo lugar, el cliente envía una solicitud CreatePermissions al servidor TURN para crear un sistema de verificación de permisos para las comunicaciones entre servidores. En otras palabras, cuando finalmente se contacta a un par y envía información al servidor TURN para transmitirla al cliente, el servidor TURN utiliza los permisos para verificar que la comunicación entre el servidor TURN y el par es válida.
Una vez creados los permisos, el cliente tiene dos opciones para enviar los datos reales: (1) puede utilizar el mecanismo de envío o (2) puede reservar un canal mediante la solicitud ChannelBind. El mecanismo de envío es más sencillo, pero contiene un encabezado más grande, 36 bytes, que puede aumentar sustancialmente el ancho de banda en una conversación retransmitida TURN. Por el contrario, el método ChannelBind es más ligero: el encabezado tiene solo 4 bytes, pero requiere reservar un canal que debe actualizarse periódicamente, entre otras consideraciones.
Utilizando cualquiera de los métodos, envío o enlace de canal, el servidor TURN recibe los datos del cliente y los retransmite al par utilizando datagramas UDP, que contienen como dirección de origen la "Dirección de transporte retransmitida asignada". El par recibe los datos y responde, nuevamente usando un datagrama UDP como protocolo de transporte, enviando el datagrama UDP a la dirección de retransmisión en el servidor TURN.
El servidor TURN recibe el datagrama UDP del par, verifica los permisos y, si son válidos, lo reenvía al cliente.
Este proceso evita incluso las NAT simétricas porque tanto el cliente como el par pueden al menos hablar con el servidor TURN, que ha asignado una dirección IP de retransmisión para la comunicación.
Si bien TURN es más robusto que STUN en el sentido de que ayuda a atravesar más tipos de NAT, una comunicación TURN retransmite toda la comunicación a través del servidor, lo que requiere mucho más ancho de banda que el protocolo STUN, que normalmente solo resuelve la dirección IP pública y retransmite la información al cliente y a sus pares para que la utilicen en la comunicación directa. Por esta razón, el protocolo ICE exige el uso de STUN como primer recurso y el uso de TURN solo cuando se trata de NAT simétricas u otras situaciones en las que no se puede utilizar STUN.