STUN ( Session Traversal Utilities for NAT ; originalmente Simple Traversal of User Datagram Protocol (UDP) a través de Network Address Translators ) es un conjunto estandarizado de métodos, incluido un protocolo de red, para atravesar puertas de enlace del traductor de direcciones de red (NAT) en aplicaciones de real- tiempo voz, video, mensajería y otras comunicaciones interactivas.
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 de Protocolo de Internet (IP) 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. hosts remotos. El protocolo requiere asistencia de un servidor de red de terceros (servidor STUN) ubicado en el lado opuesto (público) de la 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 asignación de direcciones y puertos. Este algoritmo no es confiable y solo se aplica a un subconjunto de dispositivos NAT implementados. El algoritmo consta de una serie de pruebas que debe realizar una aplicación. Cuando la ruta a través del diagrama termina en un cuadro rojo, la comunicación UDP no es posible y cuando la ruta termina en un cuadro amarillo o verde, la comunicación es posible. Los métodos de RFC 3489 resultaron demasiado poco confiables para hacer frente a la gran cantidad de diferentes implementaciones de NAT y escenarios de aplicación que se encuentran en las redes de producción. El protocolo y 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 que los protocolos de comunicaciones detecten y atraviesen traductores de direcciones de red que se encuentran en la ruta entre dos puntos finales de comunicación. Se implementa como un protocolo cliente-servidor liviano , que requiere solo componentes simples de consulta y respuesta con un servidor de terceros ubicado en una 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 Voz sobre Protocolo de Internet (VoIP) o un cliente de mensajería instantánea.
El protocolo básico funciona esencialmente de la siguiente manera: el cliente, que normalmente opera dentro de una red privada , envía una solicitud vinculante 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, como se observa desde la perspectiva del servidor. El resultado se ofusca mediante mapeo exclusivo o (XOR) para evitar la traducción del contenido del paquete por parte de puertas de enlace de capa de aplicación (ALG) que realizan una inspección profunda de paquetes en un intento de realizar métodos transversales de NAT alternativos.
Los mensajes STUN se envían en paquetes UDP ( Protocolo de datagramas de usuario ). Dado que 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 genera una sobrecarga adicional de red. En aplicaciones sensibles a la seguridad, STUN puede transportarse y cifrarse mediante Transport Layer Security (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.ejemplo.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 demultiplexar paquetes TLS y STUN. En caso de que no se encuentre ningún servidor STUN mediante 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 usarí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 están ubicados en redes privadas diferentes, cada uno 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 ICE ( Establecimiento de conectividad interactiva ) 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 configurar una llamada entre dos hosts.
La traducción de direcciones de red se implementa a través de diferentes esquemas de mapeo de direcciones y puertos, ninguno de los cuales está estandarizado.
STUN no es una solución transversal de NAT autónoma aplicable en todos los escenarios de implementación de NAT y no funciona correctamente con todos ellos. Es una herramienta entre otros métodos y es una herramienta para otros protocolos que tratan con el cruce de NAT, en particular el recorrido mediante retransmisión NAT (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 de puerto . En los casos de NAT de cono restringido o de cono restringido de puerto, el cliente debe enviar un paquete al punto final antes de que NAT permita paquetes desde el punto final hasta el cliente. STUN no funciona con NAT simétrica (también conocida como NAT bidireccional) que suele encontrarse en las redes de grandes empresas. Dado que la dirección IP del servidor STUN es diferente de 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.