STUN Server: cos'è, come funziona e dove viene utilizzato

Cos'è un server STUN

STUN Server (Session Traversal Utilities for NAT) è un servizio di rete che opera secondo il protocollo definito in RFC 5389 e aggiornato in RFC 8489. Il compito principale di un server STUN è fornire al client informazioni sul proprio indirizzo IP pubblico e sulla propria porta come visti dalla rete esterna, nonché determinare il tipo di dispositivo NAT tra il client e Internet.

L'architettura STUN include due componenti: un client STUN integrato nell'applicazione (ad esempio, un browser o un'applicazione nativa WebRTC) e un server STUN distribuito nella rete pubblica. Il client invia una Binding Request al server, che nella sua risposta indica l'indirizzo IP sorgente e la porta della richiesta — cioè gli indirizzi pubblici del client come visti dal server. Confrontando questi dati con i propri indirizzi locali, il client può determinare quale tipo di NAT viene utilizzato nella sua rete.

Protocollo STUN

STUN opera su UDP (porta 3478 predefinita) o TCP (porta 3478 o 5349 per TLS). Un messaggio STUN consiste in un'intestazione di 20 byte e un numero variabile di attributi. L'intestazione contiene il tipo di messaggio (Binding Request, Binding Response, Binding Error Response), la lunghezza e un identificatore di transazione univoco (96 bit) che consente di abbinare richieste e risposte. Ogni Binding Response contiene l'attributo XOR-MAPPED-ADDRESS — l'indirizzo esterno del client, codificato con mascheratura per proteggersi da attacchi basati sull'intercettazione del traffico STUN.

Come funziona un server STUN

Un server STUN opera con un semplice protocollo richiesta-risposta. Il client dietro NAT crea una Binding Request e la invia al server STUN. Il server riceve il pacchetto, estrae l'indirizzo IP sorgente e la porta del mittente dall'intestazione UDP, quindi crea una Binding Response, inserendo questo indirizzo nell'attributo XOR-MAPPED-ADDRESS. La risposta viene inviata all'indirizzo di origine della richiesta.

Il client riceve la risposta ed estrae XOR-MAPPED-ADDRESS, che contiene l'indirizzo IP esterno e la porta assegnati dal dispositivo NAT. Quindi il client confronta questo indirizzo con il proprio indirizzo locale (RFC 1919 — privato). Se gli indirizzi coincidono, il client non è dietro NAT. Se differiscono, il client è dietro NAT e l'indirizzo esterno viene utilizzato come candidato per ICE (Interactive Connectivity Establishment) in WebRTC.

Processo di scoperta del NAT

Un server STUN consente di determinare il tipo di NAT attraverso una sequenza di richieste di test. Il client invia richieste con flag diversi (CHANGE-REQUEST) e analizza le risposte. Il ciclo completo di scoperta include l'invio di richieste a diversi indirizzi IP e porte del server STUN. Se il server risponde a una richiesta con una porta modificata, il NAT è di tipo Restricted Cone. Se non risponde a una richiesta con porta e IP modificati, il NAT è di tipo Symmetric. Questa informazione è fondamentale per scegliere la strategia ICE in WebRTC.

Server STUN e tipi di NAT

Un server STUN può rilevare quattro tipi principali di NAT, ognuno dei quali influisce diversamente sulla possibilità di stabilire una connessione P2P. Il tipo di NAT determina se STUN può consentire una connessione diretta tra due client. Determina anche quale candidato ICE — host, server reflexive o relay — verrà utilizzato per la connessione.

Symmetric NAT è l'unico tipo con cui STUN non può funzionare. Con Symmetric NAT, ogni nuova richiesta a un nuovo host di destinazione riceve un indirizzo esterno diverso (IP e/o porta). Poiché il server STUN segnala l'indirizzo per la connessione al server STUN stesso, questo indirizzo non è adatto per connettersi a un altro client. In tali casi, WebRTC utilizza un server TURN per ritrasmettere il traffico. Secondo la ricerca (Ford et al., RFC 3489, 2003), circa l'8–10% di tutti i dispositivi NAT su Internet sono simmetrici.

Utilizzo del server STUN in WebRTC

Un server STUN viene integrato in WebRTC tramite la configurazione RTCPeerConnection. Un browser o un'applicazione nativa utilizza STUN per raccogliere i candidati ICE, che vengono poi scambiati tramite il Signaling Server. Nella configurazione WebRTC, il server STUN viene specificato nell'array iceServers con il prefisso stun: per UDP o stuns: per connessioni TLS.

Consideriamo un esempio di configurazione di un server STUN in JavaScript durante la creazione di una RTCPeerConnection per un'applicazione 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);

Questo esempio utilizza i server STUN pubblici di Google (stun.l.google.com:19302). Durante la creazione di un'offerta o risposta, il browser invia automaticamente una Binding Request STUN ai server specificati, riceve l'indirizzo esterno (candidato server reflexive) e lo aggiunge all'elenco dei candidati ICE. Dopo aver raccolto tutti i candidati, vengono inviati al peer remoto tramite il Signaling Server per tentare di stabilire una connessione P2P diretta.

Tipi di candidati ICE e STUN

Nel processo ICE, esistono tre tipi di candidati: host (indirizzo locale), srflx (server reflexive — ottenuto da STUN) e relay (ritrasmesso tramite TURN). Il server STUN consente la creazione di candidati srflx, che hanno una priorità maggiore rispetto ai candidati relay perché una connessione basata su STUN è diretta e non richiede ritrasmissione. Il processo ICE verifica tutte le combinazioni di candidati (locali e ottenuti da STUN) di entrambi i peer, iniziando dalle priorità più alte.

Limitazioni del protocollo STUN

Un server STUN ha limitazioni fondamentali legate all'architettura del protocollo. La limitazione principale è l'incapacità di funzionare con Symmetric NAT, dove ogni nuova richiesta a un host esterno riceve una porta esterna univoca. In questo caso, l'indirizzo ottenuto dal server STUN non può essere utilizzato per connettersi a un altro peer perché il NAT ha creato un binding solo per la comunicazione con il server STUN stesso.

La seconda limitazione è che STUN non fornisce ritrasmissione dei dati. Se la connessione P2P diretta è impossibile (entrambi i peer dietro Symmetric NAT), STUN non offre un percorso alternativo per la trasmissione dei dati. In questo caso, è necessario un server TURN, che funge da relay del traffico multimediale tra i peer, ricevendo dati da un partecipante e inviandoli a un altro attraverso il proprio indirizzo IP pubblico.

• Symmetric NAT — STUN non funziona con NAT simmetrico perché l'indirizzo esterno è univoco per ogni host di destinazione e non può essere riutilizzato per P2P.
• Firewall con ispezione approfondita dei pacchetti — alcuni firewall bloccano il traffico STUN rilevando firme del protocollo nei pacchetti UDP sulla porta 3478.
• IPv6 — nelle reti IPv6, il NAT solitamente non viene utilizzato, quindi STUN non è necessario, ma WebRTC su IPv6 può utilizzare candidati host senza bisogno di STUN o TURN.
• Dipendenza dalla disponibilità — il server STUN deve essere accessibile al client durante la fase di stabilimento della connessione, altrimenti i candidati srflx non verranno raccolti.
• Sicurezza — il protocollo STUN è vulnerabile ad attacchi di amplificazione se il server è configurato male e risponde a richieste con indirizzo di origine falsificato.

Nonostante le limitazioni, un server STUN rimane un componente critico dell'infrastruttura WebRTC. Nella maggior parte dei casi (80–90%), una connessione P2P diretta può essere stabilita utilizzando STUN, evitando i costi di ritrasmissione TURN e riducendo la latenza di trasmissione dei dati multimediali. Per le applicazioni WebRTC pubbliche, si consiglia di utilizzare una combinazione di server STUN e TURN con fallback automatico.