Traversal Using Relays around NAT ( TURN ) es un protocolo que ayuda a atravesar los traductores de direcciones de red (NAT) o firewalls para aplicaciones multimedia. Se puede utilizar 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 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 la telefonía, por ejemplo.
TURN está especificado por RFC 8656 . El esquema TURN URI está documentado en RFC 7065 .
Introducción
Los NAT, si bien brindan beneficios, también tienen inconvenientes. El más problemático de esos inconvenientes es el hecho de que rompen muchas aplicaciones IP existentes y dificultan la implementación de otras nuevas. 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.
Las utilidades de recorrido de sesión para NAT (STUN) proporcionan 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, es posible que las direcciones obtenidas por STUN no sean utilizables por todos los compañeros. Esas direcciones funcionan en función 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 solo se puede lograr mediante la transmisión de datos a través de un servidor que resida en la Internet pública. Traversal Using Relay 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 para el proveedor del servidor TURN. Por lo tanto, es deseable utilizar TURN solo como último recurso, prefiriendo otros mecanismos (como STUN o conectividad directa) cuando sea posible. Para lograrlo, la metodología del establecimiento de conectividad interactiva (ICE) se puede utilizar para descubrir los medios óptimos de conectividad.
Protocolo
El proceso comienza cuando una computadora cliente desea comunicarse con 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 los 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.
Primero, el cliente contacta a un servidor TURN con una solicitud de "Asignar". La solicitud Allocate le pide al servidor TURN que asigne algunos de sus recursos para el 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 retransmisor y envía al cliente una respuesta "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 servidor. En otras palabras, cuando un par finalmente es contactado y envía información al servidor TURN para ser transmitida al cliente, el servidor TURN usa los permisos para verificar que la comunicación del servidor entre pares es válida.
Una vez que se han creado los permisos, el cliente tiene dos opciones para enviar los datos reales, (1) puede usar el mecanismo de envío, o (2) puede reservar un canal usando 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 que se reserve 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 mismo nivel, comprueba 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 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 porque ayuda a atravesar más tipos de NAT, una comunicación TURN transmite toda la comunicación a través del servidor, lo que requiere mucho más ancho de banda del servidor que el protocolo STUN, que generalmente solo resuelve la dirección IP y los relés de cara al público. la información al cliente y compañeros 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 usar STUN.