NAT traversal spiegato: come il desktop remoto P2P attraversa il tuo router.

Hai un solo IP pubblico e una dozzina di dispositivi dietro il router. Il tuo iPad è su rete cellulare, a tre reti di distanza. In qualche modo un'app di desktop remoto apre una connessione diretta dall'uno all'altro in meno di un secondo — di solito senza alcun relay in mezzo. Ecco come funziona davvero questa magia: ICE, STUN, TURN, hole punching e la scomoda verità sul NAT simmetrico.

Perché è importante

Immagina un martedì mattina. Il tuo Mac mini è a casa dietro un router con un solo indirizzo IPv4 pubblico. Il tuo iPad è sul treno, sulla rete mobile di un operatore con i suoi strati di traduzione degli indirizzi. Tra i due dispositivi ci sono almeno due NAT, probabilmente tre. Nessuna delle due macchine è raggiungibile da Internet per impostazione predefinita.

Eppure apri Remio sull'iPad, tocchi il Mac e un secondo dopo stai guardando il tuo desktop. Video e input scorrono direttamente tra i due dispositivi — nessun relay nel cloud, nessun proxy in mezzo che ricodifica il tuo schermo.

La tecnica che lo rende possibile ha un nome — NAT traversal — e dietro di sé una famiglia di protocolli ben definiti: STUN, TURN e ICE. Sono gli stessi protocolli che WebRTC usa per le videochiamate nel browser, ed è per questo che qualsiasi desktop remoto P2P moderno può evitare di far passare i fotogrammi del tuo schermo dal data center di una terza parte. Questo articolo spiega cosa fa ciascuno, perché esiste e come si combinano per trovare il percorso a latenza più bassa tra due dispositivi nascosti dietro i router.

Il problema del NAT in 60 secondi

Internet è stato progettato in modo che ogni dispositivo avesse il proprio indirizzo pubblicamente instradabile. Nell'intero spazio ci sono circa 4,3 miliardi di indirizzi IPv4 — tanti nel 1981, ma ovviamente non abbastanza alla fine degli anni '90.

Il rimedio fu il Network Address Translation. Il tuo router riceve un indirizzo IPv4 pubblico dal provider. In casa, ogni dispositivo riceve un indirizzo privato da un intervallo riservato (tipicamente 192.168.x.x o 10.x.x.x). Quando il tuo portatile invia un pacchetto, il router riscrive l'indirizzo di origine con il proprio IP pubblico, memorizza la corrispondenza e lo inoltra. Quando arriva la risposta, il router cerca la corrispondenza e riscrive la destinazione riportandola al tuo portatile.

Ecco esattamente perché le connessioni in entrata non funzionano per impostazione predefinita. Da fuori, il tuo portatile non ha un indirizzo; ce l'ha solo il router. Un pacchetto di uno sconosciuto verso ip-pubblico-del-tuo-router:5060 arriva a un router che non ha nessuna corrispondenza per esso e viene scartato.

Per un'app P2P, questa è l'intera partita. Entrambi i peer stanno dietro router che inoltrano pacchetti solo se ricordano di aver inviato qualcosa in uscita prima. Nessuno dei due può semplicemente «chiamare» l'altro — devono cooperare con i loro router per aprire un percorso temporaneo.

Hole punching: far rientrare il traffico dal firewall

Ecco il trucco. La tabella NAT del tuo router è indicizzata su una quintupla: IP di origine, porta di origine, IP di destinazione, porta di destinazione e protocollo. Quando il tuo dispositivo invia un pacchetto UDP in uscita a 1.2.3.4:5678, il router crea una voce temporanea che dice «se arriva un qualsiasi pacchetto UDP da 1.2.3.4:5678 verso il mio IP pubblico sulla porta X, inoltralo a questo dispositivo sulla porta Y».

Quella voce esiste per una finestra di tempo — tipicamente da 30 a 60 secondi — e poi scade se qualcosa non la rinnova. Durante quella finestra, qualsiasi pacchetto dall'indirizzo di destinazione viene accettato.

È il buco della serratura che usano le app P2P. Se entrambi i peer conoscono l'indirizzo pubblico dell'altro, ognuno può inviare un singolo pacchetto UDP in uscita verso l'altro nello stesso momento. Il router di ciascuno apre una corrispondenza in uscita. Il primo pacchetto di ciascuno può benissimo essere scartato — l'altro router non ha ancora aperto la sua corrispondenza — ma il secondo pacchetto ha un posto dove andare. Da quel momento entrambi i router pensano di inoltrare una normale conversazione in uscita, e i due dispositivi parlano direttamente.

Si chiama UDP hole punching. È leggermente miracoloso, ben documentato (RFC 5128) e funziona per la grande maggioranza dei NAT consumer in circolazione. I casi restanti — NAT simmetrico, CGNAT, firewall aziendali — sono il motivo per cui TURN esiste.

L'hole punching non è un espediente. È il contratto esplicito attorno a cui è stato progettato il NAT: un pacchetto in uscita crea un permesso in entrata. Le app P2P inviano semplicemente il pacchetto in uscita di proposito.

STUN: «qual è il mio indirizzo pubblico?»

L'hole punching ha un prerequisito: ogni peer deve conoscere il proprio indirizzo visibile all'esterno per poter dire all'altro dove inviare i pacchetti. Quell'indirizzo non è visibile dall'interno del dispositivo. Il tuo iPad vede il proprio indirizzo Wi-Fi locale (192.168.1.42). Ciò che vede il resto di Internet dopo che il router ha riscritto il pacchetto è tutta un'altra cosa.

STUN — Session Traversal Utilities for NAT, RFC 5389 — è il piccolo protocollo che risolve il problema. Il flusso è quasi imbarazzante da quanto è semplice:

1. Il peer invia un pacchetto UDP a un server STUN pubblico. (Remio usa sia i server STUN pubblici di Cloudflare sia quelli di Google, per ridondanza.)
2. Il server STUN legge IP e porta di origine dal pacchetto — che sono, per definizione, l'indirizzo pubblico del peer dopo la traduzione NAT.
3. Il server STUN risponde con quell'indirizzo come contenuto: «Per quanto vedo io, sei 203.0.113.42:48291.»
4. Il peer ora sa quale indirizzo comunicare all'altro lato.

Quell'indirizzo visibile all'esterno si chiama candidato server-reflexive nella terminologia ICE. Non costa praticamente nulla — un solo round trip durante la configurazione della connessione e nessun sovraccarico di banda o latenza dopo che la connessione è stabilita. L'unico compito di STUN è presentare due peer l'uno all'altro; una volta che parlano, il server STUN non ha più alcun ruolo.

TURN: quando l'hole punching fallisce

L'hole punching funziona per la maggior parte dei NAT, ma non per tutti. I casi di fallimento sono reali, e un'app P2P che finge che non esistano semplicemente non riuscirà a collegare una fetta consistente di utenti.

I principali cattivi:

• NAT simmetrico. Un NAT che assegna una porta pubblica diversa per ogni destinazione distinta. STUN dice al tuo peer che sei sulla porta 48291 (perché è la porta che ha visto il server STUN), ma quando invii un pacchetto all'indirizzo del peer, il tuo router sceglie una porta diversa — diciamo 48317. Il router del peer rifiuta il pacchetto perché arriva da una porta inattesa. L'hole punching si rompe.
• NAT a livello di operatore (CGNAT). Le reti cellulari e molte reti di provider aggiungono un secondo NAT a livello di operatore. Potresti trovarti dietro due NAT senza saperlo, ed entrambi devono cooperare. Il CGNAT è spesso simmetrico e non hai accesso da amministratore.
• Firewall aziendali restrittivi. Alcune reti aziendali bloccano tutto l'UDP in uscita, oppure lo consentono solo verso destinazioni specifiche. L'hole punching ha bisogno di un percorso UDP; se non c'è, non ha alcuna possibilità.

Per questi casi il ripiego è TURN — Traversal Using Relays around NAT, RFC 5766. Un server TURN è un relay che entrambi i peer possono raggiungere perché ha un indirizzo pubblico che accetta sempre traffico in entrata. Ogni peer stabilisce una normale connessione TLS in uscita verso il server TURN (che qualsiasi NAT consente), e il server inoltra i byte tra i due lati.

TURN ha un costo reale. Ogni pacchetto video deve attraversare un salto di rete in più. Su un relay TURN regionale ciò aggiunge circa 30-80 millisecondi di latenza di andata e ritorno. Tra regioni diverse — per esempio un relay a Francoforte per un peer a Tokyo e uno a San Paolo — può essere 80-200 millisecondi. Anche l'operatore TURN paga la banda: ogni bit del tuo stream passa dalle sue tubature.

Ecco perché un'app ben progettata usa TURN solo quando l'hole punching ha dimostrabilmente fallito. ICE prende questa decisione in automatico.

ICE: provare ogni candidato in parallelo

Interactive Connectivity Establishment, RFC 8445, è la coreografia che lega tutto questo. ICE non sceglie una strategia in anticipo. Raccoglie ogni possibile indirizzo candidato per ciascun peer, scambia l'elenco completo con l'altro lato, poi fa sondare a entrambi gli stack ogni coppia di candidati in parallelo — in una gara per trovare la prima che funziona.

Per ogni peer, ICE di solito raccoglie:

• Candidati host — ogni indirizzo IP locale su ogni interfaccia di rete (Ethernet, Wi-Fi, interfacce virtuali, IPv4 e IPv6).
• Candidati server-reflexive — indirizzi pubblici appresi dai server STUN.
• Candidati relay — indirizzi allocati su un server TURN.

I due peer si scambiano questi elenchi attraverso un canale di segnalazione — per Remio, una piccola connessione WebSocket verso relay.remio.net che trasporta i candidati ICE e la descrizione della sessione WebRTC (l'SDP), e poi non ha più nulla da fare quando il flusso multimediale parte.

Una volta in possesso di entrambi gli elenchi, ICE avvia i controlli di connettività. Ogni peer invia un pacchetto STUN binding request su ogni coppia di candidati, in ordine di priorità. Le priorità sono pensate per preferire il percorso a latenza più bassa:

1. Da host a host — entrambi i peer sulla stessa rete locale. È il caso ideale: poche centinaia di microsecondi di latenza, nessun router coinvolto.
2. Da host a server-reflexive, o da server-reflexive a server-reflexive — peer su reti diverse, con hole punching attraverso i rispettivi NAT. È ciò che di solito significa in pratica «P2P su Internet».
3. Qualsiasi cosa che coinvolga un relay — ultima risorsa, usata solo quando tutti i percorsi a priorità più alta falliscono i controlli di connettività.

La prima coppia di candidati in cui riescono entrambe le direzioni viene nominata vincitrice, e il flusso multimediale parte lungo quel percorso. L'intero processo di solito si completa in molto meno di un secondo.

ICE raccoglie candidati anche in continuazione. Se a metà sessione compare un percorso migliore — per esempio il telefono lascia la rete cellulare ed entra nel Wi-Fi — ICE può rinominare il nuovo percorso senza interrompere la chiamata.

Perché Remio preferisce il P2P con decisione

Remio è un'app di desktop remoto, non una videochiamata. Il budget di latenza è spietato. Perché una sessione dia la sensazione di essere seduti davanti all'host, l'intera catena — cattura, codifica, rete, decodifica, rendering — deve essere minuscola: in LAN costa circa 8 ms, e il resto è la cadenza di aggiornamento a 60 Hz del tuo display (circa 16,7 ms per fotogramma). Ogni salto in più è un peccato.

Su una connessione P2P diretta in LAN, la parte di rete di quel budget è di circa 1-5 millisecondi di andata e ritorno. Non c'è relay; i byte vanno direttamente da un dispositivo all'altro. Con la catena di Remio fa circa 8 ms di elaborazione in LAN (misurati internamente; il resto è la cadenza di aggiornamento a 60 Hz del tuo display) — il tuo input arriva prima che sia disegnato il fotogramma successivo. La macchina remota è indistinguibile da una locale.

Su una connessione con relay TURN — anche regionale — la parte di rete sale a 30-80 millisecondi. La latenza totale percepita dall'utente diventa 40-100 ms. Ancora utilizzabile per la maggior parte dei lavori, ma si sente in un trascinamento veloce o in una sequenza rapida di clic. Il trackpad non sembra più del tutto tuo.

Questo scarto è il motivo per cui ci diamo tanta pena per tenere le sessioni in P2P. Lo stack WebRTC di Remio raccoglie candidati sia IPv4 sia IPv6, parla con più server STUN in parallelo e preferisce con decisione i percorsi diretti nella selezione delle coppie di candidati di ICE. Internamente usiamo perfino l'RTT misurato della connessione per classificare la rete — sotto i 15 ms sappiamo che è una LAN, quindi l'encoder parte alto e può usare molta più banda. Tutto ciò che è più lento viene trattato come WAN e regolato in modo più prudente.

E — è la parte che i concorrenti spesso omettono con discrezione — la connessione è cifrata end-to-end a prescindere dal percorso. Il tuo schermo non tocca mai i nostri server, e anche un relay TURN vede solo testo cifrato: le chiavi vengono negoziate direttamente tra i due peer durante la stretta di mano, prima che si muova un solo pixel. Che i byte passino in P2P o tramite TURN, né il server di segnalazione di Remio né l'operatore TURN possono leggerli. P2P significa solo che sul percorso dei dati non c'è nessuna terza parte.

Quando il relay è inevitabile (e va bene così)

A volte gli dei della rete dicono no. NAT simmetrico a entrambe le estremità, doppio CGNAT su un operatore cellulare con un provider rigoroso, un firewall aziendale che consente solo TLS in uscita verso provider cloud noti — sono configurazioni reali e comuni. In quei casi la sessione deve semplicemente passare da un relay, altrimenti non si fa.

Il backend TURN di Remio è Cloudflare Calls, che ci dà una rete globale di relay vicini alla maggior parte degli utenti. Quando ICE sceglie un percorso relay, l'esperienza passa da «sembra locale» a «sembra Splashtop» — ancora molto utilizzabile, ma si nota. La latenza aggiuntiva è di 30-80 ms per un relay regionale; tra regioni può arrivare a 200 ms.

La parte importante: i dati restano cifrati end-to-end. Cloudflare vede pacchetti UDP cifrati in una direzione e pacchetti UDP cifrati nell'altra. Può contare i byte per la fatturazione. Non può vedere il tuo schermo, le tue battute sulla tastiera né alcun contenuto della sessione. Non c'è nemmeno un punto di decifrazione lato Remio, perché nella catena non c'è nessun cloud Remio — gestiamo il servizio TURN tramite Cloudflare e non tocchiamo mai i contenuti.

È l'architettura che il nostro whitepaper sulla sicurezza descrive più nel dettaglio. In sintesi: P2P o relay, il modello di minaccia è lo stesso.

La via di fuga IPv6

IPv6 ha 340 undecilioni di indirizzi (3,4 × 10³⁸) — abbastanza per dare a ogni granello di sabbia della Terra il suo IP pubblico, con qualche migliaio di miliardi d'avanzo. In un mondo solo IPv6 il NAT è in gran parte superfluo. Due dispositivi compatibili con IPv6 possono semplicemente inviarsi pacchetti agli indirizzi l'uno dell'altro, e l'unico ostacolo è il firewall dell'host a ciascuna estremità.

Se hai IPv6 a casa e sul tuo operatore cellulare, potresti aver notato che alcune app si collegano più in fretta quando entrambe le estremità sono IPv6 — perché tutta la danza «raccogli candidati, sonda le coppie» ha meno ostacoli. Non c'è nessuna traduzione NAT da scoprire, nessun giro da STUN, solo indirizzi diretti.

Ma c'è un problema: nel 2026 la diffusione globale è ancora incompleta. Molti router domestici gestiscono IPv6 male o per niente. Molte reti aziendali bloccano per impostazione predefinita l'IPv6 in entrata. Alcuni operatori offrono IPv6 lato radio ma fanno il bridge verso IPv4 altrove. I percorsi puramente IPv6 verso IPv6 esistono ma non si può farvi affidamento come unico meccanismo.

Così Remio — come ogni seria infrastruttura P2P — raccoglie candidati sia IPv4 sia IPv6 e lascia che ICE li metta in gara. Se esiste un percorso IPv6 diretto che funziona, di solito vince per latenza. Altrimenti subentra IPv4 con hole punching. Se falliscono entrambi, relay. L'utente non vede nulla di tutto questo; la connessione si stabilisce e basta.

Come capire quale percorso sta usando la tua sessione

Curioso di sapere su quale percorso è finita la tua sessione? L'indicatore di connessione di Remio mostra il tipo in parole semplici — «Diretta» per il P2P, «Relay» per TURN. Il pannello delle statistiche per sviluppatori espone lo stato completo di WebRTC, compresi i tipi di candidato della coppia nominata (host, srflx, relay) e l'RTT misurato.

Qualche interpretazione veloce:

• RTT sotto i 5 ms, Diretta — sei sulla stessa LAN dell'host. Caso migliore. Sono raggiungibili circa 8 ms di elaborazione (il resto è la cadenza di aggiornamento a 60 Hz del tuo display).
• RTT da 5 a 15 ms, Diretta — stessa rete Wi-Fi ma con un salto in più su un access point o una mesh. Ancora ottimo.
• RTT da 15 a 80 ms, Diretta — sei su una rete diversa da quella dell'host, l'hole punching è riuscito. Il P2P su Internet funziona.
• RTT da 30 a 80 ms, Relay (regionale) — un NAT simmetrico o un NAT a livello di operatore ha sconfitto l'hole punching. È subentrato un TURN Cloudflare vicino.
• RTT da 80 a 200 ms, Relay — TURN su una distanza geografica maggiore, oppure tu e l'host siete in regioni molto diverse.

Se ripieghi in modo affidabile sul relay anche a casa, i soliti sospetti sono un modem del provider che fa NAT simmetrico, un CGNAT IPv4 sulla tua connessione domestica (più comune di quanto pensi tra i rivenditori di fibra) o un firewall troppo zelante che blocca l'UDP in entrata. La nostra guida per ridurre il lag del desktop remoto passa in rassegna i colpevoli più comuni, e la pagina sulla connessione diretta in LAN è la via rapida se entrambi i dispositivi sono nella tua rete.

Numeri di prestazioni nel mondo reale

Mettendo tutto insieme, ecco i valori di latenza che misuriamo in produzione sui diversi percorsi che può prendere una sessione Remio:

• P2P diretto in LAN: 1–5 ms di RTT di rete. End-to-end (dall'evento di input all'aggiornamento del pixel): circa 8 ms di elaborazione (il resto è la cadenza di aggiornamento a 60 Hz del tuo display) con il resto della catena che collabora.
• Stessa rete Wi-Fi con salti aggiuntivi: 5–10 ms di RTT di rete.
• Relay TURN, regionale: 30–80 ms di RTT di rete.
• Relay TURN, tra regioni: 80–200 ms di RTT di rete.
• Rete cellulare 4G/5G, P2P con hole punching: 40–100 ms di RTT di rete.

Corrispondono ai valori dei benchmark di Remio e spiegano perché fissiamo la soglia tra LAN e WAN a 15 ms di RTT — separa nettamente i percorsi diretti da qualsiasi relay (minimo 30 ms) o percorso cellulare (minimo 40 ms), con pochissimi falsi positivi.

Il NAT traversal è uno di quegli argomenti in cui i protocolli sono semplici uno per uno ma la combinatoria è ostica. La maggior parte degli utenti non avrà mai bisogno di sapere che ICE, STUN e TURN esistono — vivrà semplicemente un'app che si collega in fretta da ovunque a ovunque. I protocolli fanno il loro lavoro quando non ci si accorge di loro. Quando invece te ne accorgi — una sessione impiega un attimo di troppo, o «Diretta» diventa «Relay» — ora hai il modello mentale.

Per saperne di più sulla catena nativa di Remio e sulle scelte che trasformano 1–5 ms di latenza di rete in circa 8 ms di elaborazione (il resto è la cadenza di aggiornamento a 60 Hz del tuo display), vedi perché il nativo conta. Per il modello di minaccia sui percorsi relay, vedi il whitepaper sulla sicurezza. Oppure sfoglia le funzioni e scarica Remio per vederlo funzionare.