Attraversamento NAT

NAT traversal è l'insieme di tecniche che consentono a due dispositivi dietro NAT separati di stabilire connessioni dirette. Senza di esso, i protocolli peer-to-peer dipendono interamente dai server di inoltro, il che aggiunge costi e latenza. Con esso, due telefoni dietro i router domestici possono comunicare direttamente attraverso Internet per gran parte della vita della connessione.

LIl problema di base

NAT (vedi il nostro articolo NAT) traduce le connessioni in uscita da IP privati ​​a un IP pubblico condiviso. Le connessioni in entrata senza una mappatura esistente non hanno destinazione: il NAT non sa a quale dispositivo interno inoltrare. Due dispositivi NAT non possono avviare connessioni tra loro; entrambi devono essere l'originatore.

STUN: "che aspetto ha il mio IP pubblico?"

STUN (Session Traversal Utilities for NAT), RFC 5389, è un semplice protocollo che consente a un dispositivo di scoprire il proprio IP pubblico/mappatura delle porte. Il dispositivo invia una richiesta di STUN ad un server STUN pubblico; il server risponde con l'indirizzo di origine osservato (che è la mappatura esterna del NAT). I server

STUN sono senza stato e gratuiti da eseguire. Google gestisce stun.l.google.com:19302; ne esistono molti altri. Il costo per eseguirne uno è trascurabile perché lo scambio di protocolli è minimo.

LIl pattern NAT-traversal più semplice

Per due dispositivi A e B dietro NAT:

1. A interroga STUN, apprende che la sua mappatura pubblica è X.
2. B interroga STUN, apprende che la sua mappatura pubblica è Y.
3. A e B si scambiano questi indirizzi tramite un canale di segnalazione (fuori banda, come un websocket attraverso il server dell'app).
4. A inizia a inviare pacchetti a Y; B inizia a inviare a X.
5. Entrambi i NAT vedono i pacchetti in uscita verso l'indirizzo dell'altro, creano le mappature necessarie e da quel momento in poi i pacchetti in entrata a quelle mappature vengono inoltrati internamente.
6. LIl percorso diretto da A a B ora funziona.

Questo è hole punching. Funziona quando entrambi i NAT sono ragionevolmente permissivi (cono pieno o cono limitato).

Tipi NAT e loro possibilità di perforazione

• NAT a cono pieno. Il più permissivo: qualsiasi host esterno può inviare all'IP/porta pubblica mappata. La perforazione funziona facilmente.
• NAT a cono limitato. Solo gli host esterni contattati in precedenza possono inviare. La perforazione funziona dopo che entrambe le parti hanno inviato almeno un pacchetto.
• Port-restricted-cone NAT. Limitato dall'host AND dalla porta. La perforazione funziona ancora, ma richiede che entrambe le parti inviino alla porta esatta.
• NAT simmetrico. Più restrittivo: la porta esterna è diversa per ciascuna destinazione, quindi la mappatura vista da STUN non prevede la mappatura per il traffico peer diretto. La perforazione in genere non riesce.

I NAT simmetrici sono comuni nelle distribuzioni NAT di livello carrier e in alcuni firewall aziendali. I peer dietro NAT simmetrici spesso non riescono a connettersi direttamente; hanno bisogno di un relè.

TURN: quando la perforazione fallisce

TURN (Traversal Using Relays around NAT), RFC 5766, è il fallback. Quando la connessione diretta non è possibile, entrambi i peer si connettono a un server TURN, che inoltra il traffico tra di loro. I server TURN vedono tutto il traffico multimediale: un costo di larghezza di banda significativamente maggiore rispetto a STUN.

Per i servizi di videochiamata (Zoom, Google Meet), l'esecuzione dei server TURN rappresenta una spesa operativa importante. Le stime suggeriscono che il 15-30% delle chiamate utilizza i relè TURN nonostante gli sforzi per massimizzare le connessioni dirette.

ICE: combinando tutto

ICE (Interactive Connectivity Constitutionment), RFC 8445, è il framework che utilizza STUN, TURN e la connettività diretta insieme. Il processo:

1. Ogni peer raccoglie tutti gli indirizzi dei candidati: interfacce locali, mappature pubbliche scoperte da STUN, prenotazioni di relè TURN.
2. I peer si scambiano elenchi di candidati completi tramite segnalazione.
3. Ogni peer tenta di connettersi a tutte le combinazioni di candidati remoti.
4. La prima combinazione funzionante diventa la connessione attiva. Diretto è preferito rispetto a ritrasmesso; latenza inferiore rispetto a quella superiore.
5. La connessione può essere rivalutata durante la chiamata se le condizioni cambiano.

WebRTC utilizza ICE per le connessioni browser peer-to-peer. Consulta il nostro articolo su WebRTC. La maggior parte dei protocolli P2P moderni utilizzano ICE o qualcosa di simile.

Perforazione UDP e perforazione TCP

La perforazione UDP è semplice (e l'impostazione predefinita per la maggior parte dei casi d'uso NAT-traversal). La perforazione del TCP è molto più difficile perché TCP richiede un handshake sincronizzato; entrambe le parti devono avviare le connessioni tra loro simultaneamente e i NAT devono consentire lo stato risultante. Alcuni NAT lo supportano; molti no. La maggior parte del traffico P2P che necessita di un trasporto affidabile utilizza protocolli basati su UDP (QUIC, livelli personalizzati di over-reliability UDP) anziché TCP.

NAT64 e IPv6

IPv6 non necessita di NAT: ogni dispositivo ha un indirizzo instradabile a livello globale. Teoricamente, IPv6 elimina l'attraversamento NAT. In pratica, l'implementazione parziale di IPv6 significa che alcuni endpoint sono solo IPv4 dietro NAT, altri sono direttamente raggiungibili IPv6 e NAT64/DNS64 si traduce tra di loro. Il risultato sono decisioni di routing più complesse ma connessioni dirette generalmente più semplici per endpoint compatibili con IPv6.

Cosa significa per gli utenti

In genere non pensi all'attraversamento NAT: le app lo gestiscono. Gli effetti visibili:

• Le videochiamate funzionano bene sulle reti domestiche (solitamente dirette o quasi dirette)
• Le chiamate dietro i firewall aziendali a volte peggiorano perché il traffico passa attraverso TURN
• Le chiamate su rete mobile a volte presentano problemi perché i NAT dell'operatore sono spesso simmetrici
• Il matchmaking P2P del gioco è più affidabile su alcune reti rispetto a altri

Per gli utenti che gestiscono i propri servizi: il passaggio a IPv6 e la graduale riduzione dell'implementazione NAT simmetrica hanno reso l'attraversamento NAT meno doloroso negli ultimi dieci anni.