STUN Server: o que é, como funciona e onde é usado

O que é um STUN Server

STUN Server (Session Traversal Utilities for NAT) é um serviço de rede que opera sob o protocolo definido na RFC 5389 e atualizado na RFC 8489. A principal tarefa de um servidor STUN é fornecer ao cliente informações sobre seu próprio endereço IP público e porta, conforme vistos da rede externa, bem como determinar o tipo de dispositivo NAT entre o cliente e a internet.

A arquitetura STUN inclui dois componentes: um cliente STUN incorporado ao aplicativo (por exemplo, um navegador ou aplicativo nativo WebRTC) e um servidor STUN implantado na rede pública. O cliente envia uma Binding Request ao servidor, que em sua resposta indica o endereço IP e a porta de origem da solicitação — ou seja, os endereços públicos do cliente vistos pelo servidor. Ao comparar esses dados com seus endereços locais, o cliente pode determinar qual tipo de NAT está sendo usado em sua rede.

Protocolo STUN

STUN opera sobre UDP (porta 3478 por padrão) ou TCP (porta 3478 ou 5349 para TLS). Uma mensagem STUN consiste em um cabeçalho de 20 bytes e um número variável de atributos. O cabeçalho contém o tipo de mensagem (Binding Request, Binding Response, Binding Error Response), comprimento e um identificador de transação único (96 bits) que permite combinar solicitações e respostas. Cada Binding Response contém o atributo XOR-MAPPED-ADDRESS — o endereço externo do cliente, codificado com mascaramento para proteção contra ataques baseados em interceptação de tráfego STUN.

Como funciona um servidor STUN

Um servidor STUN opera em um protocolo simples de solicitação-resposta. O cliente atrás do NAT cria uma Binding Request e a envia ao servidor STUN. O servidor recebe o pacote, extrai o endereço IP de origem e a porta do remetente do cabeçalho UDP, então cria uma Binding Response, empacotando este endereço no atributo XOR-MAPPED-ADDRESS. A resposta é enviada de volta ao endereço de origem da solicitação.

O cliente recebe a resposta e extrai o XOR-MAPPED-ADDRESS, que contém o endereço IP externo e a porta atribuídos pelo dispositivo NAT. Em seguida, o cliente compara este endereço com seu endereço local (RFC 1919 — privado). Se os endereços coincidirem — o cliente não está atrás de NAT. Se diferirem — o cliente está atrás de NAT, e o endereço externo é usado como candidato para ICE (Interactive Connectivity Establishment) no WebRTC.

Processo de descoberta de NAT

Um servidor STUN permite determinar o tipo de NAT através de uma sequência de solicitações de teste. O cliente envia solicitações com diferentes flags (CHANGE-REQUEST) e analisa as respostas. O ciclo completo de descoberta inclui o envio de solicitações para diferentes endereços IP e portas do servidor STUN. Se o servidor responder a uma solicitação com uma porta alterada — o NAT é do tipo Restricted Cone. Se não responder a uma solicitação com porta e IP alterados — o NAT é do tipo Symmetric. Esta informação é fundamental para escolher a estratégia ICE no WebRTC.

Servidor STUN e tipos de NAT

Um servidor STUN pode detectar quatro tipos principais de NAT, cada um afetando diferentemente a capacidade de estabelecer uma conexão P2P. O tipo de NAT determina se o STUN pode permitir uma conexão direta entre dois clientes. Também determina qual candidato ICE — host, server reflexive ou relay — será usado para a conexão.

Symmetric NAT é o único tipo com o qual o STUN não consegue lidar. Com Symmetric NAT, cada nova solicitação para um novo host de destino recebe um endereço externo diferente (IP e/ou porta). Como o servidor STUN informa o endereço para a conexão com o próprio servidor STUN, este endereço é inadequado para conectar-se a outro cliente. Nesses casos, o WebRTC usa um servidor TURN para retransmitir o tráfego. De acordo com pesquisas (Ford et al., RFC 3489, 2003), cerca de 8–10% de todos os dispositivos NAT na internet são simétricos.

Uso do servidor STUN no WebRTC

Um servidor STUN é integrado ao WebRTC através da configuração do RTCPeerConnection. Um navegador ou aplicativo nativo usa o STUN para coletar candidatos ICE, que são então trocados através do Signaling Server. Na configuração do WebRTC, o servidor STUN é especificado no array iceServers com o prefixo stun: para UDP ou stuns: para conexões TLS.

Vamos considerar um exemplo de configuração de um servidor STUN em JavaScript ao criar uma RTCPeerConnection para uma aplicação 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 exemplo usa os servidores STUN públicos do Google (stun.l.google.com:19302). Ao criar uma oferta ou resposta, o navegador envia automaticamente uma Binding Request STUN para os servidores especificados, recebe o endereço externo (candidato server reflexive) e o adiciona à lista de candidatos ICE. Após coletar todos os candidatos, eles são enviados ao par remoto através do Signaling Server para tentar estabelecer uma conexão P2P direta.

Tipos de candidatos ICE e STUN

No processo ICE, existem três tipos de candidatos: host (endereço local), srflx (server reflexive — obtido do STUN) e relay (retransmitido através de TURN). O servidor STUN possibilita a criação de candidatos srflx, que têm prioridade maior que os candidatos relay porque uma conexão baseada em STUN é direta e não requer retransmissão. O processo ICE verifica todas as combinações de candidatos (locais e obtidos do STUN) de ambos os pares, começando pelas prioridades mais altas.

Limitações do protocolo STUN

Um servidor STUN tem limitações fundamentais relacionadas à arquitetura do protocolo. A principal limitação é a incapacidade de funcionar com Symmetric NAT, onde cada nova solicitação a um host externo recebe uma porta externa única. Neste caso, o endereço obtido do servidor STUN não pode ser usado para conectar-se a outro par porque o NAT criou uma ligação apenas para comunicação com o próprio servidor STUN.

A segunda limitação é que o STUN não fornece retransmissão de dados. Se a conexão P2P direta for impossível (ambos os pares atrás de Symmetric NAT), o STUN não oferece um caminho alternativo para transmissão de dados. Neste caso, um servidor TURN é necessário, que atua como um retransmissor de tráfego de mídia entre os pares, recebendo dados de um participante e enviando-os a outro através de seu endereço IP público.

• Symmetric NAT — o STUN não funciona com NAT simétrico porque o endereço externo é único para cada host de destino e não pode ser reutilizado para P2P.
• Firewall com inspeção profunda de pacotes — alguns firewalls bloqueiam o tráfego STUN detectando assinaturas do protocolo em pacotes UDP na porta 3478.
• IPv6 — em redes IPv6, o NAT normalmente não é usado, portanto o STUN não é necessário, mas o WebRTC em IPv6 pode usar candidatos host sem precisar de STUN ou TURN.
• Dependência de disponibilidade — o servidor STUN deve estar acessível ao cliente durante a fase de estabelecimento da conexão, caso contrário os candidatos srflx não serão coletados.
• Segurança — o protocolo STUN é vulnerável a ataques de amplificação se o servidor estiver mal configurado e responder a solicitações com endereço de origem falsificado.

Apesar das limitações, um servidor STUN continua sendo um componente crítico da infraestrutura WebRTC. Na maioria dos casos (80–90%), uma conexão P2P direta pode ser estabelecida usando STUN, o que evita os custos de retransmissão TURN e reduz a latência de transmissão de dados de mídia. Para aplicações WebRTC públicas, recomenda-se usar uma combinação de servidores STUN e TURN com fallback automático.