STUN Server: qué es, cómo funciona y dónde se utiliza

Qué es un STUN Server

STUN Server (Session Traversal Utilities for NAT) es un servicio de red que opera según el protocolo definido en RFC 5389 y actualizado en RFC 8489. La tarea principal de un servidor STUN es proporcionar al cliente información sobre su propia dirección IP pública y puerto, tal como se ven desde la red externa, así como determinar el tipo de dispositivo NAT entre el cliente e internet.

La arquitectura STUN incluye dos componentes: un cliente STUN integrado en la aplicación (por ejemplo, un navegador o una aplicación nativa WebRTC) y un servidor STUN desplegado en la red pública. El cliente envía una solicitud de enlace (Binding Request) al servidor, que en su respuesta indica la dirección IP y el puerto de origen de la solicitud, es decir, las direcciones públicas del cliente que el servidor ve. Al comparar estos datos con sus direcciones locales, el cliente puede determinar qué tipo de NAT se utiliza en su red.

Protocolo STUN

STUN funciona sobre UDP (puerto 3478 por defecto) o TCP (puerto 3478 o 5349 para TLS). Un mensaje STUN consta de un encabezado de 20 bytes y un número variable de atributos. El encabezado contiene el tipo de mensaje (Binding Request, Binding Response, Binding Error Response), la longitud y un identificador único de transacción (96 bits) que permite emparejar solicitudes y respuestas. Cada Binding Response contiene el atributo XOR-MAPPED-ADDRESS, la dirección externa del cliente, codificada con enmascaramiento para protegerse contra ataques basados en la interceptación del tráfico STUN.

Cómo funciona un servidor STUN

Un servidor STUN funciona con un protocolo simple de solicitud-respuesta. Un cliente detrás de NAT crea una Binding Request y la envía al servidor STUN. El servidor recibe el paquete, extrae la dirección IP de origen y el puerto del remitente del encabezado UDP, luego crea una Binding Response, empaquetando esta dirección en el atributo XOR-MAPPED-ADDRESS. La respuesta se envía de vuelta a la dirección de origen de la solicitud.

El cliente recibe la respuesta y extrae la XOR-MAPPED-ADDRESS, que contiene la dirección IP externa y el puerto asignados por el dispositivo NAT. Luego, el cliente compara esta dirección con su dirección local (RFC 1919 — privada). Si las direcciones coinciden, el cliente no está detrás de NAT. Si difieren, el cliente está detrás de NAT y la dirección externa se utiliza como candidato para ICE (Interactive Connectivity Establishment) en WebRTC.

Proceso de descubrimiento de NAT

Un servidor STUN permite determinar el tipo de NAT mediante una secuencia de solicitudes de prueba. El cliente envía solicitudes con diferentes banderas (CHANGE-REQUEST) y analiza las respuestas. El ciclo completo de descubrimiento incluye el envío de solicitudes a diferentes direcciones IP y puertos del servidor STUN. Si el servidor responde a una solicitud con un puerto cambiado, el NAT es de tipo Restricted Cone. Si no responde a una solicitud con puerto e IP cambiados, el NAT es de tipo Symmetric. Esta información es crítica para elegir la estrategia ICE en WebRTC.

Servidor STUN y tipos de NAT

Un servidor STUN puede detectar cuatro tipos principales de NAT, cada uno de los cuales afecta de manera diferente la posibilidad de establecer una conexión P2P. El tipo de NAT determina si STUN puede permitir una conexión directa entre dos clientes. También determina qué candidato ICE — host, server reflexive o relay — se utilizará para la conexión.

Symmetric NAT es el único tipo con el que STUN no puede funcionar. Con Symmetric NAT, cada nueva solicitud a un nuevo host de destino obtiene una dirección externa diferente (IP y/o puerto). Dado que el servidor STUN informa la dirección para la conexión con el propio servidor STUN, esta dirección no es adecuada para conectarse a otro cliente. En tales casos, WebRTC utiliza un servidor TURN para retransmitir el tráfico. Según investigaciones (Ford et al., RFC 3489, 2003), aproximadamente el 8-10% de todos los dispositivos NAT en internet son simétricos.

Uso del servidor STUN en WebRTC

Un servidor STUN se integra en WebRTC a través de la configuración de RTCPeerConnection. Un navegador o aplicación nativa utiliza STUN para recopilar candidatos ICE, que luego se intercambian a través del Signaling Server. En la configuración de WebRTC, el servidor STUN se especifica en el array iceServers con el prefijo stun: para UDP o stuns: para conexiones TLS.

Veamos un ejemplo de configuración de un servidor STUN en JavaScript al crear una RTCPeerConnection para una aplicación WebRTC.

const config = {
    iceServers: [
        {
            urls: "stun:stun.l.google.com:19302"
        },
        {
            urls: "stun:stun1.l.google.com:19302"
        }
    ]
};

const pc = new RTCPeerConnection(config);

pc.onicecandidate = (event) => {
    if (event.candidate) {
        console.log("Candidato ICE:", event.candidate.candidate);
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Este ejemplo utiliza los servidores STUN públicos de Google (stun.l.google.com:19302). Al crear una oferta o respuesta, el navegador envía automáticamente una Binding Request STUN a los servidores especificados, recibe la dirección externa (candidato server reflexive) y la añade a la lista de candidatos ICE. Después de recopilar todos los candidatos, se envían al peer remoto a través del Signaling Server para intentar establecer una conexión P2P directa.

Tipos de candidatos ICE y STUN

En el proceso ICE, existen tres tipos de candidatos: host (dirección local), srflx (server reflexive — obtenido de STUN) y relay (retransmitido a través de TURN). El servidor STUN permite la creación de candidatos srflx, que tienen mayor prioridad que los candidatos relay porque una conexión basada en STUN es directa y no requiere retransmisión. El proceso ICE verifica todas las combinaciones de candidatos (locales y obtenidos de STUN) de ambos peers, comenzando por las prioridades más altas.

Limitaciones del protocolo STUN

Un servidor STUN tiene limitaciones fundamentales relacionadas con la arquitectura del protocolo. La limitación principal es la incapacidad de funcionar con Symmetric NAT, donde cada nueva solicitud a un host externo obtiene un puerto externo único. En este caso, la dirección obtenida del servidor STUN no puede utilizarse para conectarse a otro peer porque el NAT creó un enlace solo para la comunicación con el propio servidor STUN.

La segunda limitación es que STUN no proporciona retransmisión de datos. Si la conexión P2P directa es imposible (ambos peers detrás de Symmetric NAT), STUN no ofrece una ruta alternativa para la transmisión de datos. En este caso, se requiere un servidor TURN, que actúa como retransmisor de tráfico de medios entre los peers, recibiendo datos de un participante y enviándolos a otro a través de su dirección IP pública.

• Symmetric NAT — STUN no funciona con NAT simétrico porque la dirección externa es única para cada host de destino y no se puede reutilizar para P2P.
• Firewall con inspección profunda de paquetes — algunos cortafuegos bloquean el tráfico STUN detectando firmas del protocolo en paquetes UDP en el puerto 3478.
• IPv6 — en redes IPv6, normalmente no se usa NAT, por lo que no se requiere STUN, pero WebRTC en IPv6 puede usar candidatos host sin necesidad de STUN o TURN.
• Dependencia de disponibilidad — el servidor STUN debe ser accesible para el cliente durante la fase de establecimiento de conexión, de lo contrario no se recopilarán los candidatos srflx.
• Seguridad — el protocolo STUN es vulnerable a ataques de amplificación si el servidor está mal configurado y responde a solicitudes con dirección de origen falsificada.

A pesar de las limitaciones, un servidor STUN sigue siendo un componente crítico de la infraestructura WebRTC. En la mayoría de los casos (80-90%), se puede establecer una conexión P2P directa usando STUN, lo que evita los costos de retransmisión TURN y reduce la latencia de transmisión de datos multimedia. Para aplicaciones WebRTC públicas, se recomienda usar una combinación de servidores STUN y TURN con fallback automático.