Server TURN / STUN: cos’è ed a cosa serve?

Comprendere la comunicazione in tempo reale su Internet

Negli ultimi anni, il numero di applicazioni che richiedono comunicazioni in tempo reale è cresciuto in maniera esponenziale. Piattaforme di videoconferenza, strumenti di collaborazione remota, servizi VoIP, giochi online, sistemi di monitoraggio, dispositivi IoT e persino applicazioni di telemedicina richiedono tutti la possibilità di trasmettere audio, video e dati in tempo reale, con latenza minima e alta affidabilità.

Tuttavia, stabilire una comunicazione diretta tra due dispositivi su Internet è tutt’altro che banale, soprattutto a causa di NAT (Network Address Translation) e firewall che proteggono le reti private. È qui che entrano in gioco due protocolli fondamentali: STUN e TURN.

Il problema della NAT traversal

Per comprendere l’utilità dei protocolli STUN e TURN, è essenziale prima analizzare l’ostacolo principale che ostacola le comunicazioni peer-to-peer su Internet moderno: il cosiddetto NAT traversal, ovvero il superamento delle barriere imposte dal NAT (Network Address Translation).

Cos’è il NAT e perché viene utilizzato

La tecnologia NAT è ampiamente impiegata nei router e nei gateway di rete per consentire a più dispositivi presenti all’interno di una rete locale (LAN) di condividere un singolo indirizzo IP pubblico. In pratica, ogni dispositivo connesso alla rete domestica o aziendale ha un IP privato (es. 192.168.1.x, 10.0.0.x), mentre il router effettua una traduzione degli indirizzi per presentare al mondo esterno un singolo IP pubblico.

Questa operazione è fondamentale per due motivi principali:

• Risparmio degli indirizzi IPv4: gli indirizzi IPv4 disponibili sono limitati, e il NAT consente di riutilizzarli internamente.

• Sicurezza: i dispositivi dietro NAT non sono direttamente raggiungibili da Internet, il che riduce l’esposizione ad attacchi esterni.

Tuttavia, proprio questa barriera che protegge i dispositivi introduce una sfida non banale: la mancanza di raggiungibilità diretta. Dal punto di vista di un client esterno, un dispositivo dietro NAT non ha un’identità pubblica univoca, e il router non sa a quale host inoltrare eventuali richieste in ingresso, a meno che queste non siano state precedute da una connessione uscente (come nel caso di una richiesta HTTP).

Perché è un problema nelle comunicazioni peer-to-peer?

Questa limitazione è particolarmente problematica per le applicazioni che si basano su connessioni peer-to-peer (P2P), cioè connessioni dirette tra due dispositivi, senza passare da server intermedi. Esempi classici includono:

• Servizi VoIP (Voice over IP), come SIP o telefoni IP

• Piattaforme di videoconferenza

• Applicazioni WebRTC come Google Meet, Jitsi, Discord, ecc.

• Software di desktop remoto

• Giochi multiplayer con logica P2P

• Dispositivi IoT e smart home che devono inviare o ricevere comandi in tempo reale

In questi casi, entrambe le parti devono potersi raggiungere reciprocamente, e quindi devono conoscere i rispettivi indirizzi IP pubblici e le porte di comunicazione. Tuttavia, se entrambi i dispositivi si trovano dietro NAT diversi (un caso ormai molto comune), la connessione diretta diventa impossibile senza un meccanismo che aggiri questo ostacolo.

Le complessità dei vari tipi di NAT

A complicare ulteriormente le cose, non tutti i NAT si comportano allo stesso modo. Esistono diversi tipi di NAT, ognuno con caratteristiche e livelli di restrizione differenti:

• Full Cone NAT: una volta stabilita una mappatura tra IP/porta interna e pubblica, qualsiasi host può inviare pacchetti a quell’indirizzo pubblico e verranno inoltrati al client interno. È il più permissivo.

• Restricted Cone NAT: solo gli host esterni che hanno ricevuto pacchetti dal client possono inviare dati verso di lui.

• Port Restricted Cone NAT: come il precedente, ma la restrizione è applicata anche sulla porta remota.

• Symmetric NAT: crea una nuova mappatura per ogni connessione in uscita verso un host remoto. Questo è il più restrittivo ed è il principale nemico delle comunicazioni P2P.

Le applicazioni devono tenere conto di queste variabili e adattarsi dinamicamente. Ma, in assenza di strumenti di supporto, come STUN e TURN, una comunicazione diretta è spesso impossibile.

L’ulteriore ostacolo dei firewall

A peggiorare il quadro, entrano in gioco anche i firewall, sia a livello client che aziendale. Un firewall può bloccare le connessioni in ingresso o in uscita su porte specifiche, impedendo al traffico peer-to-peer di fluire. Alcuni firewall sono configurati per bloccare tutto il traffico UDP, il protocollo preferenziale per comunicazioni in tempo reale, rendendo ancora più ardua la stabilità delle connessioni.

La necessità di “scoprire” la propria identità pubblica

Affinché due peer possano stabilire una connessione diretta, devono sapere “chi sono” dal punto di vista di Internet. In altre parole, un dispositivo deve conoscere l’indirizzo IP pubblico e la porta su cui il router ha mappato la propria comunicazione. Tuttavia, non esiste un modo nativo nei browser o nei sistemi operativi per ottenere queste informazioni.

Ecco quindi che nasce la necessità di strumenti e protocolli che forniscano questo tipo di introspezione e facilitino la comunicazione tra peer. Da qui l’importanza del protocollo STUN (per scoprire l’identità pubblica) e, nei casi più complicati, del protocollo TURN (per relazionare i dati tramite un server terzo).

STUN: il primo passo per la connessione diretta

Cos’è STUN?

STUN, acronimo di Session Traversal Utilities for NAT, è un protocollo leggero e semplice che consente a un dispositivo di determinare il proprio indirizzo IP pubblico e la natura del NAT che lo protegge. STUN è descritto nella RFC 5389 ed è stato progettato per consentire alle applicazioni di scoprire come sono viste dall’esterno della propria rete.

Come funziona STUN?

Quando un client vuole stabilire una connessione con un altro peer, invia una richiesta STUN a un server STUN pubblico. Questo server risponde indicando l’indirizzo IP e la porta da cui è stata ricevuta la richiesta, che rappresentano l’identità pubblica del client. Questa informazione può poi essere condivisa con l’altro peer, nella speranza che entrambi riescano a stabilire una connessione diretta.

Il protocollo STUN non stabilisce la connessione in sé, ma è un mezzo di scoperta utile a preparare il terreno per la successiva negoziazione tra peer.

Limiti di STUN

Sebbene STUN sia estremamente utile, non è sempre sufficiente. Alcuni tipi di NAT (in particolare i Symmetric NAT) e firewall particolarmente restrittivi impediscono in ogni caso la connessione diretta. In questi casi, la comunicazione peer-to-peer fallisce, e c’è bisogno di un meccanismo di fallback: ed è qui che entra in gioco TURN.

TURN: il canale sicuro per ogni evenienza

Cos’è TURN?

TURN, acronimo di Traversal Using Relays around NAT, è un protocollo che consente a un client di inviare e ricevere dati attraverso un server relay situato su Internet. TURN è definito dalla RFC 5766 e rappresenta l’evoluzione del protocollo STUN, offrendo una soluzione affidabile in qualsiasi condizione di rete.

In poche parole, quando la connessione diretta tra peer non è possibile, TURN agisce come intermediario che riceve i pacchetti da un peer e li ritrasmette all’altro. Questo garantisce che la comunicazione possa avvenire in modo trasparente, anche se entrambi i dispositivi si trovano dietro NAT complicati o firewall restrittivi.

Come funziona TURN?

Il client contatta il server TURN e richiede l’allocazione di una risorsa (una coppia IP/porta). Una volta allocata, il client può utilizzare questo endpoint pubblico per ricevere pacchetti da altri peer. Quando un peer invia un pacchetto a quell’indirizzo, il server TURN lo ritrasmette al client vero e proprio, agendo da relay.

TURN, a differenza di STUN, consuma più risorse di rete, perché il traffico passa interamente attraverso il server TURN. Questo introduce una maggiore latenza e un consumo di banda significativo, motivo per cui TURN viene utilizzato solo come ultima risorsa, quando STUN fallisce.

STUN e TURN nel contesto WebRTC

WebRTC (Web Real-Time Communication) è una tecnologia che consente ai browser di comunicare in tempo reale utilizzando video, audio e dati. È utilizzata da servizi come Google Meet, Zoom, Jitsi, Discord e molti altri. WebRTC implementa nativamente i protocolli STUN e TURN come parte della propria architettura di connessione.

Durante la negoziazione tra due peer (fase di “signaling”), WebRTC utilizza un processo chiamato ICE (Interactive Connectivity Establishment) che mette alla prova varie “candidate” connessioni tra i peer:

1. Host candidates: connessioni dirette sulla rete locale.

2. Server reflexive candidates: connessioni ottenute tramite STUN.

3. Relay candidates: connessioni tramite server TURN.

L’algoritmo ICE seleziona dinamicamente il percorso più efficiente. Solo se le prime due opzioni falliscono, WebRTC utilizza TURN.

Coturn: lo standard de facto per STUN/TURN server open source

Quando si parla di implementazioni pratiche di STUN/TURN, è impossibile non menzionare coturn, il progetto open source più diffuso e supportato in questo ambito.

Cos’è coturn?

Coturn è un server TURN/STUN conforme agli standard IETF, scritto in C e mantenuto attivamente su GitHub. Supporta sia STUN che TURN, oltre a funzionalità avanzate come:

• Autenticazione basata su username/password

• Supporto per TLS/DTLS

• Proxying IPv4 ↔ IPv6

• Supporto per connessioni TCP e UDP

• Integrazione con sistemi di autenticazione esterni

Coturn è adottato in numerosi progetti professionali, sia in ambienti self-hosted che in infrastrutture cloud, ed è spesso il backend per le funzionalità di comunicazione real-time su scala globale.

Perché scegliere coturn?

🔄 Affidabilità

Coturn è un progetto open source maturo, utilizzato da anni in ambienti produttivi, inclusi grandi sistemi VoIP, piattaforme di videoconferenza, giochi multiplayer e strumenti di collaborazione real-time. La sua stabilità operativa è stata ampiamente collaudata in scenari ad alto traffico e connessi a internet poco affidabili. Grazie a un ciclo di sviluppo attivo e a una community competente, ogni bug rilevante viene rapidamente corretto. È compatibile con una vasta gamma di client e non soffre delle instabilità comuni ad alcune implementazioni alternative.

🌐 Compatibilità

Coturn è pienamente conforme alle specifiche IETF (RFC 5389, RFC 5766, RFC 5780, RFC 6062, RFC 6156), il che garantisce un alto livello di interoperabilità con librerie e client WebRTC, SIP e VoIP. Questo significa che può essere integrato facilmente in ambienti eterogenei, senza dover ricorrere a workaround o personalizzazioni. Supporta sia i protocolli STUN che TURN, oltre a funzionalità avanzate come TURN-over-TLS, STUN con autenticazione long-term, e allocazioni TCP.

🚀 Scalabilità

Coturn è progettato per gestire carichi elevati: grazie alla sua architettura multithreaded e all’uso efficiente delle risorse di sistema, può supportare centinaia o migliaia di connessioni simultanee. È possibile distribuirlo dietro un load balancer oppure configurarlo per funzionare in cluster, rendendolo adatto tanto a piccoli progetti quanto a soluzioni enterprise su larga scala. La possibilità di integrare sistemi di logging e monitoraggio (es. tramite syslog o prometheus-exporter) consente di mantenerlo sotto controllo anche in ambienti mission-critical.

🔐 Sicurezza

La sicurezza è uno degli aspetti fondamentali di coturn: supporta autenticazione a lungo termine, TLS/DTLS per la cifratura dei flussi, limitazioni per IP, filtri per evitare l’abuso del server (ad es. per proxying non autorizzato) e può essere configurato per operare solo in ambienti ristretti o dietro VPN. Inoltre, è possibile abilitare restrizioni precise per evitare l’uso improprio da parte di terze parti, riducendo il rischio di attacchi di tipo relay abuse o DoS.

Per tutte queste ragioni, coturn è la scelta consigliata per chiunque voglia implementare una soluzione professionale di NAT traversal.

Per tutte queste ragioni, coturn si conferma la scelta ideale per chi ha bisogno di una soluzione professionale per superare le limitazioni imposte dai NAT e firewall, specialmente in contesti WebRTC e VoIP. È gratuito, altamente configurabile, stabile anche sotto carico intenso e supportato da una community tecnica competente. Sia che tu stia sviluppando un’applicazione di videoconferenza, un sistema di messaggistica o una piattaforma multiplayer, coturn rappresenta un pilastro solido su cui costruire.

Scenari d’uso reali

Vediamo alcuni esempi concreti in cui STUN e TURN sono fondamentali:

1. Videoconferenza aziendale

Una piattaforma di videoconferenza deve garantire che due utenti, anche dietro firewall aziendali differenti, possano comunicare senza problemi. STUN tenterà di facilitare la connessione diretta, ma se questa fallisce, TURN garantirà comunque la comunicazione tramite relay.

2. App di teleassistenza o desktop remoto

Strumenti come AnyDesk, TeamViewer o servizi di helpdesk IT devono poter stabilire una connessione anche in reti restrittive. Il fallback su TURN permette l’accesso remoto anche nei casi più complicati.

3. Videogiochi multiplayer peer-to-peer

Molti giochi online utilizzano una logica peer-to-peer per ridurre il carico sui server centrali. Grazie a STUN, i client possono scoprire il proprio IP pubblico e tentare connessioni dirette. Se non possibile, TURN assicura comunque la connessione.

4. IoT e dispositivi smart

Dispositivi come videocamere IP, citofoni smart o sensori intelligenti devono comunicare in tempo reale con app mobili. STUN e TURN abilitano questa comunicazione anche quando i dispositivi sono dietro NAT.

Considerazioni sulla sicurezza

L’impiego dei protocolli STUN e soprattutto TURN comporta una serie di rischi e implicazioni di sicurezza che non devono essere sottovalutati, soprattutto in contesti di produzione o in ambienti esposti pubblicamente su internet. TURN, in particolare, agendo come relay del traffico tra due peer, espone la propria infrastruttura a potenziali abusi, se non viene opportunamente protetta.

⚠️ TURN e rischio di abuso (DDoS, relay non autorizzato)

Poiché un server TURN può inoltrare traffico da e verso peer remoti, può essere sfruttato come ponte per:

• Attacchi DDoS riflessivi, dove il traffico viene instradato tramite TURN per mascherare l’origine dell’attacco.

• Abuso di larghezza di banda, da parte di client malintenzionati che usano il relay per bypassare restrizioni geografiche o firewall.

• Esfiltrazione di dati o comunicazioni non autorizzate.

Senza una rigida autenticazione, chiunque conosca l’IP del server può tentare di usarlo come relay gratuito.

✅ Autenticazione e gestione degli accessi

Per prevenire gli abusi, è fondamentale che i server TURN siano protetti da un sistema di autenticazione robusto. Coturn supporta nativamente l’autenticazione:

• Long-term: con credenziali statiche preconfigurate.

• Dinamica (TURN REST API): che genera token temporanei firmati con HMAC e scadenza, particolarmente utile per ambienti WebRTC.

L’uso della TURN REST API è oggi fortemente consigliato, in quanto consente di limitare temporalmente e granularmente l’accesso ai client legittimi.

Inoltre, è possibile:

• Limitare l’accesso a specifici intervalli IP.

• Impostare timeout e limiti di banda per sessione.

• Integrare sistemi di rate limiting per proteggersi da connessioni massicce o automatizzate.

• Abilitare il logging completo delle allocazioni TURN, utile per rilevare comportamenti sospetti o investigare anomalie.

🔒 Uso di TLS e DTLS

La protezione delle comunicazioni deve avvenire non solo a livello applicativo, ma anche a livello di trasporto. Coturn supporta:

• TURN over TLS (TCP+TLS)

• TURN over DTLS (UDP+DTLS)

• STUN over TLS/DTLS

Queste modalità criptano i flussi di segnalazione e media, impedendo intercettazioni da parte di soggetti terzi e migliorando la privacy e l’integrità delle comunicazioni tra peer.

L’uso di TLS/DTLS è particolarmente raccomandato in contesti sensibili, in cui i peer si trovano in reti non fidate (es. Wi-Fi pubblici, ambienti aziendali misti, sessioni WebRTC).

🛡️ Una configurazione sicura con coturn

Coturn mette a disposizione tutti gli strumenti necessari per implementare un’infrastruttura TURN sicura:

• Autenticazione dinamica con scadenza

• Filtri IP e controllo delle allocazioni

• Supporto TLS e DTLS

• Logging dettagliato per auditing e diagnostica

• Possibilità di eseguire il servizio con privilegi limitati

Una configurazione attenta e consapevole consente di mitigare i rischi e proteggere l’infrastruttura da tentativi di abuso o attacchi esterni. È fondamentale includere la sicurezza nella fase iniziale della progettazione, e non come misura correttiva successiva.

L’adozione di STUN e TURN è indispensabile per garantire la comunicazione diretta in scenari di NAT traversal. Tuttavia, non è “plug and play”: è necessario accompagnare l’implementazione con misure di sicurezza tecniche, organizzative e procedurali.

Coturn, se correttamente configurato, rappresenta una soluzione affidabile, sicura e altamente controllabile, perfetta per ambienti in cui la sicurezza non è un optional ma un requisito.

Conclusione

I protocolli STUN e TURN sono componenti fondamentali per abilitare le comunicazioni in tempo reale su Internet. STUN consente la scoperta degli indirizzi pubblici e la negoziazione delle connessioni dirette, mentre TURN garantisce una soluzione di fallback in qualsiasi scenario, anche il più complesso.

Senza questi protocolli, tecnologie come WebRTC semplicemente non funzionerebbero in molti ambienti reali. Ed è proprio per questo motivo che, nella progettazione di servizi VoIP, videoconferenza o comunicazione peer-to-peer, è essenziale predisporre server STUN/TURN affidabili, sicuri e performanti.

Se stai valutando l’installazione e la configurazione di un server TURN/STUN per la tua infrastruttura, noi di MANAGED SERVER SRL abbiamo un’esperienza consolidata nell’implementazione e nella gestione di server basati su coturn. Possiamo aiutarti a progettare una soluzione scalabile, sicura e ad alte prestazioni, adatta al tuo caso d’uso specifico.