STUN ( Session Traversal Utilities for NAT ; originalmente Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators ) es un conjunto estandarizado de métodos, incluido un protocolo de red, para atravesar pasarelas de traductores de direcciones de red (NAT) en aplicaciones de voz, video, mensajería y otras comunicaciones interactivas en tiempo real.
STUN es una herramienta utilizada por otros protocolos, como el establecimiento de conectividad interactiva (ICE), el protocolo de inicio de sesión (SIP) y WebRTC . Proporciona una herramienta para que los hosts descubran la presencia de un traductor de direcciones de red y descubran la dirección IP ( protocolo de Internet ) y el número de puerto asignados, generalmente públicos, que el NAT ha asignado para los flujos del Protocolo de datagramas de usuario (UDP) de la aplicación a los hosts remotos. El protocolo requiere la asistencia de un servidor de red de terceros (servidor STUN) ubicado en el lado opuesto (público) del NAT, generalmente la Internet pública .
STUN se anunció por primera vez en RFC 3489; [1] el título se cambió en una especificación de un conjunto actualizado de métodos publicado como RFC 5389, conservando el mismo acrónimo. [2]
STUN se anunció por primera vez en RFC 3489. [1] La especificación original especificaba un algoritmo para caracterizar el comportamiento de NAT según el comportamiento de mapeo de direcciones y puertos. Este algoritmo no es confiablemente exitoso y solo es aplicable a un subconjunto de dispositivos NAT implementados. El algoritmo consiste en una serie de pruebas que debe realizar una aplicación. Cuando la ruta a través del diagrama termina en un recuadro rojo, la comunicación UDP no es posible y cuando la ruta termina en un recuadro amarillo o verde, la comunicación es posible. Los métodos de RFC 3489 demostraron ser demasiado poco confiables para hacer frente a la plétora de diferentes implementaciones de NAT y escenarios de aplicación encontrados en redes de producción. El protocolo y el método STUN se actualizaron en RFC 5389, conservando muchas de las especificaciones originales como un subconjunto de métodos, pero eliminando otras.
El título se cambió en una especificación de un conjunto actualizado de métodos publicado como RFC 5389, conservando el mismo acrónimo. [2]
STUN es una herramienta para protocolos de comunicaciones que permite detectar y atravesar traductores de direcciones de red que se encuentran en la ruta entre dos puntos finales de la comunicación. Se implementa como un protocolo cliente-servidor liviano , que requiere solo componentes de consulta y respuesta simples con un servidor de terceros ubicado en la red común y de fácil acceso, generalmente Internet . El lado del cliente se implementa en la aplicación de comunicaciones del usuario, como un teléfono de Protocolo de voz sobre Internet (VoIP) o un cliente de mensajería instantánea.
El protocolo básico funciona básicamente de la siguiente manera: el cliente, que normalmente opera dentro de una red privada , envía una solicitud de enlace a un servidor STUN en la Internet pública. El servidor STUN responde con una respuesta de éxito que contiene la dirección IP y el número de puerto del cliente, tal como se observa desde la perspectiva del servidor. El resultado se ofusca mediante un mapeo exclusivo o (XOR) para evitar la traducción del contenido del paquete por parte de las puertas de enlace de la capa de aplicación (ALG) que realizan una inspección profunda de los paquetes en un intento de realizar métodos alternativos de cruce de NAT.
Los mensajes STUN se envían en paquetes de Protocolo de datagramas de usuario (UDP). Dado que el UDP no proporciona un transporte confiable , la confiabilidad se logra mediante retransmisiones controladas por la aplicación de las solicitudes STUN. Los servidores STUN no implementan ningún mecanismo de confiabilidad para sus respuestas. [2] Cuando la confiabilidad es obligatoria, se puede utilizar el Protocolo de control de transmisión (TCP), pero induce una sobrecarga de red adicional. En aplicaciones sensibles a la seguridad, STUN puede ser transportado y cifrado por Seguridad de la capa de transporte (TLS).
Una aplicación puede determinar automáticamente un servidor STUN adecuado para las comunicaciones con un par en particular consultando el Sistema de nombres de dominio (DNS) para el registro de recursos del servidor stun (para UDP) o stuns (para TCP/TLS) ( SRV ), por ejemplo, _stun._udp.example.com. El número de puerto de escucha estándar para un servidor STUN es 3478 para UDP y TCP, y 5349 para TLS. Alternativamente, TLS también se puede ejecutar en el puerto TCP si la implementación del servidor puede desmultiplexar paquetes TLS y STUN. En caso de que no se encuentre un servidor STUN utilizando búsquedas DNS, el estándar recomienda que se consulte el nombre de dominio de destino para obtener registros de direcciones (A o AAAA), que se utilizarían con los números de puerto predeterminados. [2]
Además de utilizar el cifrado de protocolo con TLS, STUN también tiene mecanismos integrados de autenticación e integridad de mensajes a través de tipos de paquetes STUN especializados.
Cuando un cliente ha evaluado su dirección externa, puede usarla como candidata para comunicarse con sus pares compartiendo la dirección NAT externa en lugar de la dirección privada, a la que no pueden acceder los pares en la red pública.
Si ambos pares que se comunican se encuentran en redes privadas diferentes, cada una detrás de un NAT, los pares deben coordinarse para determinar la mejor ruta de comunicación entre ellos. Algunos comportamientos de NAT pueden restringir la conectividad entre pares incluso cuando se conoce el enlace público. El protocolo de establecimiento de conectividad interactiva (ICE) proporciona un mecanismo estructurado para determinar la ruta de comunicación óptima entre dos pares. Las extensiones del Protocolo de inicio de sesión (SIP) se definen para permitir el uso de ICE al establecer una llamada entre dos hosts.
La traducción de direcciones de red se implementa a través de varios esquemas diferentes de mapeo de direcciones y puertos, ninguno de los cuales está estandarizado.
STUN no es una solución de cruce de NAT autónoma que se pueda aplicar en todos los escenarios de implementación de NAT y no funciona correctamente con todos ellos. Es una herramienta entre otros métodos y una herramienta para otros protocolos en el manejo del cruce de NAT, en particular el cruce mediante NAT de retransmisión (TURN) y el establecimiento de conectividad interactiva (ICE).
STUN funciona con tres tipos de NAT: NAT de cono completo , NAT de cono restringido y NAT de cono restringido por puerto . En los casos de NAT de cono restringido o de cono restringido por puerto, el cliente debe enviar un paquete al punto final antes de que el NAT permita que los paquetes del punto final lleguen al cliente. STUN no funciona con NAT simétrica (también conocida como NAT bidireccional), que se encuentra a menudo en las redes de grandes empresas. Dado que la dirección IP del servidor STUN es diferente a la del punto final, en el caso de NAT simétrica, la asignación de NAT será diferente para el servidor STUN que para un punto final. TURN ofrece mejores resultados con NAT simétrica.