Recorrido mediante relés alrededor de NAT

TURN ( Traversal Using Relays around NAT ) es un protocolo que facilita el acceso a través de traductores de direcciones de red (NAT) o cortafuegos para aplicaciones multimedia. Puede utilizarse con el Protocolo de Control de Transmisión (TCP) y el Protocolo de Datagramas de Usuario (UDP). Resulta especialmente útil para clientes en redes enmascaradas por dispositivos NAT simétricos . TURN no permite ejecutar servidores en puertos conocidos de la red privada a través de un NAT; su función es conectar a un usuario detrás de un NAT con un único par, como en el caso de la telefonía, por ejemplo.

TURN está especificado por RFC 8656. El esquema URI de TURN está documentado en RFC 7065 .  

La traducción de direcciones de red (NAT), un mecanismo que sirve para mitigar el problema del agotamiento de direcciones IPv4 durante la transición a IPv6 , presenta varias limitaciones. La más problemática es que NAT interrumpe el funcionamiento de muchas aplicaciones IP existentes y dificulta la implementación de nuevas. ^{[ 1 ]} Se han desarrollado directrices que describen cómo crear protocolos compatibles con NAT, pero muchos protocolos simplemente no pueden construirse siguiendo dichas directrices. Ejemplos de estos protocolos incluyen aplicaciones multimedia y de intercambio de archivos.

La utilidad Session Traversal Utilities for NAT (STUN) proporciona una forma para que una aplicación atraviese una NAT. STUN permite que un cliente obtenga una dirección de transporte (una dirección IP y un puerto) que puede ser útil para recibir paquetes de un par. Sin embargo, las direcciones obtenidas por STUN pueden no ser utilizables por todos los pares. Dichas 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 atravesar una NAT .

Una solución completa requiere un mecanismo que permita al cliente obtener una dirección de transporte desde la cual pueda recibir contenido multimedia de cualquier nodo que pueda enviar paquetes a Internet. Esto solo se puede lograr retransmitiendo los datos a través de un servidor ubicado en Internet. El protocolo TURN (Traversal Using Relays around NAT) permite al cliente obtener direcciones IP y puertos de dicho servidor de retransmisión.

Aunque TURN casi siempre proporciona conectividad a un cliente, su uso requiere muchos recursos del proveedor del servidor TURN. Por lo tanto, es recomendable utilizar TURN solo como último recurso, prefiriendo otros mecanismos (como STUN o la conectividad directa) cuando sea posible. Para ello, se puede utilizar la metodología de Establecimiento Interactivo de Conectividad (ICE) para determinar el método de conectividad óptimo.

El proceso comienza cuando un equipo cliente desea contactar con otro equipo para realizar una transacción de datos, pero no puede hacerlo debido a que ambos se encuentran detrás de sus respectivos NAT. Si STUN no es una opción porque uno de los NAT es simétrico (un tipo de NAT que no es compatible con STUN), se debe utilizar TURN.

En primer lugar, el cliente se comunica con un servidor TURN mediante una solicitud de asignación. Esta solicitud pide al servidor TURN que asigne algunos de sus recursos al cliente para que pueda comunicarse con otro servidor. Si la asignación es posible, el servidor asigna una dirección para que el cliente la utilice como repetidor y le envía una respuesta de "Asignación exitosa", que contiene una "dirección de transporte de retransmisión 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 pares y servidores. En otras palabras, cuando finalmente se establece contacto con un par y este envía información al servidor TURN para que la transmita al cliente, el servidor TURN utiliza los permisos para verificar que la comunicación entre el par y el servidor TURN sea válida.

Una vez creados los permisos, el cliente tiene dos opciones para enviar los datos: (1) puede usar el mecanismo Send o (2) puede reservar un canal mediante la solicitud ChannelBind. El mecanismo Send es más sencillo, pero contiene una cabecera más grande, de 36 bytes, que puede aumentar considerablemente el ancho de banda en una conversación retransmitida por TURN. Por el contrario, el método ChannelBind es más ligero: la cabecera es de solo 4 bytes, pero requiere la reserva de un canal que debe actualizarse periódicamente, entre otras consideraciones.

Mediante cualquiera de los dos métodos, envío o enlace de canal, el servidor TURN recibe los datos del cliente y los retransmite al par mediante datagramas UDP, cuya dirección de origen es la "Dirección de transporte retransmitida asignada". El par recibe los datos y responde, también mediante un datagrama UDP como protocolo de transporte, enviándolo a la dirección de retransmisión del servidor TURN.

El servidor TURN recibe el datagrama UDP del par, comprueba 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 comunicarse al menos 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, ya que permite atravesar más tipos de NAT, la comunicación TURN transmite toda la información a través del servidor, lo que requiere un ancho de banda mucho mayor que el del protocolo STUN. Este último, por lo general, solo resuelve la dirección IP pública y transmite la información al cliente y al par para que la utilicen en la comunicación directa. Por este motivo, el protocolo ICE exige el uso de STUN como primera opción y el uso de TURN únicamente en casos de NAT simétricas u otras situaciones en las que no se pueda utilizar STUN.

• Establecimiento de conectividad interactiva (ICE)
• Utilidades de recorrido de sesión para NAT (STUN)