El protocolo TURN ( Traversal Using Relays around NAT ) es un protocolo que ayuda a atravesar 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). Es muy útil para clientes en redes enmascaradas por dispositivos NAT simétricos . TURN no ayuda a ejecutar servidores en puertos conocidos en la red privada a través de un 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 URI de TURN 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 direcciones IPv4 durante la transición a IPv6 , tiene varias limitaciones. La más problemática de estas limitaciones es el hecho de que NAT rompe 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. Algunos ejemplos de dichos protocolos incluyen aplicaciones multimedia y uso compartido de archivos.
Session Traversal Utilities for NAT (STUN) ofrece una forma para que una aplicación atraviese un 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. Esas direcciones funcionan según las condiciones topológicas de la red. Por lo tanto, STUN por sí solo no puede proporcionar una solución completa para atravesar un 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 solo se puede lograr retransmitiendo datos a través de un servidor que resida en la Internet pública. Traversal Using Relays around NAT (TURN) es un protocolo que permite a un cliente obtener direcciones IP y puertos de dicho relé.
Aunque TURN casi siempre proporciona conectividad a un cliente, requiere muchos recursos del proveedor del servidor TURN. Por lo tanto, es conveniente utilizar TURN solo como último recurso, prefiriendo otros mecanismos (como STUN o conectividad directa) cuando sea posible. Para lograrlo, se puede utilizar la metodología de establecimiento de conectividad interactiva (ICE) para descubrir los medios óptimos de conectividad.
El proceso comienza cuando un equipo cliente desea comunicarse con un equipo par para realizar una transacción de datos, pero no puede hacerlo debido a que tanto el cliente como el par se encuentran detrás de sus respectivos NAT. Si STUN no es una opción porque uno de los NAT es un NAT simétrico (un tipo de NAT que se sabe que no es compatible con STUN), se debe utilizar TURN.
En primer lugar, el cliente se comunica con un servidor TURN con una solicitud de "Asignación". La solicitud de asignación le pide al servidor TURN que asigne algunos de sus recursos para el cliente, de modo que pueda comunicarse con un par. Si la asignación es posible, el servidor asigna una dirección para que el cliente la utilice 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 pares y servidores. En otras palabras, cuando finalmente se contacta a un par y envía información al servidor TURN para que se la transmita al cliente, el servidor TURN utiliza los permisos para verificar que la comunicación entre pares y servidores TURN sea válida.
Una vez creados los permisos, el cliente tiene dos opciones para enviar los datos reales: (1) puede utilizar el mecanismo Send o (2) puede reservar un canal mediante la solicitud ChannelBind. El mecanismo Send es más sencillo, pero contiene un encabezado más grande, de 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 que se reserve un canal que debe actualizarse periódicamente, entre otras consideraciones.
Mediante cualquiera de los métodos, Send o channel binding, el servidor TURN recibe los datos del cliente y los retransmite al par mediante datagramas UDP, que contienen como dirección de origen la "Dirección de transporte retransmitida asignada". El par recibe los datos y responde, nuevamente utilizando 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 los NAT simétricos porque tanto el cliente como el par pueden al menos comunicarse 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 al par para que la utilicen en la comunicación directa. Por este motivo, el protocolo ICE exige el uso de STUN como primer recurso y el uso de TURN solo cuando se trata de NAT simétricos u otras situaciones en las que no se puede utilizar STUN.