Introduzione
Questo documento descrive la necessità di Session Traversal Utilities per i server NAT (STUN), i tipi di configurazione di Network Address Translation (NAT) rispetto ai server STUN, il modo in cui NAT causa un problema in questa configurazione e nella soluzione.
Premesse
Lo scopo principale dei dispositivi NAT è quello di consentire ai dispositivi con indirizzi IP privati in una rete locale (LAN) di comunicare con i dispositivi negli spazi degli indirizzi pubblici, come Internet. Tuttavia, sebbene i dispositivi NAT debbano consentire agli host interni di connettersi allo spazio pubblico, quando si tratta di applicazioni Point-to-Point (P2P) come VoIP, videogame, WebRTC e condivisione di file in cui gli utenti finali devono agire sia come client che come server per mantenere la comunicazione bidirezionale, NAT fornisce difficoltà a stabilire tali connessioni UDP. Le tecniche di attraversamento NAT sono in genere necessarie per il funzionamento di queste applicazioni.
Necessità di NAT Traversal
La comunicazione vocale e video in tempo reale su Internet è diffusa oggi con diversi instant messenger (IM) molto diffusi che supportano le chiamate VoIP. Un grande ostacolo nell'adozione iniziale del VoIP è stato il fatto che la maggior parte dei PC o altri dispositivi si trovano dietro i firewall e utilizzano indirizzi IP privati. Più indirizzi privati (indirizzo IP e porta) nella rete sono mappati a un singolo indirizzo pubblico da un firewall con NAT. Il dispositivo terminale, tuttavia, non è in grado di rilevare l'indirizzo pubblico e, di conseguenza, non può ricevere traffico vocale dalla parte remota sull'indirizzo privato pubblicizzato nella comunicazione VoIP.
I processi UNSAF (Unilateral Self-Address Fixing) sono processi in cui alcuni endpoint di origine tentano di determinare o correggere l'indirizzo (e la porta) con cui sono noti a un altro endpoint, ad esempio per essere in grado di utilizzare i dati dell'indirizzo nello scambio di protocollo o per annunciare un indirizzo pubblico da cui ricevono le connessioni.
Le connessioni P2P in discussione sono quindi processi UNSAF. Un modo comune per le applicazioni P2P di stabilire sessioni di peering e mantenere NAT-friendly è quando utilizzano un server rendezvous indirizzabile pubblicamente per la registrazione e il peer discovery.
Utilità di attraversamento sessione per NAT
Come indicato nella RFC 5389, STUN fornisce uno strumento che si occupa dei NAT. Fornisce un mezzo per un endpoint per determinare l'indirizzo IP e la porta allocati da un dispositivo NAT che corrisponde al suo indirizzo IP privato e alla sua porta. Consente inoltre a un endpoint di mantenere attivo un binding NAT.
Tipi di implementazioni NAT
È stato osservato che il trattamento NAT di UDP varia tra le implementazioni. I quattro trattamenti osservati nelle implementazioni sono:
Coni completi: un NAT conico completo è un nodo in cui tutte le richieste provenienti dallo stesso indirizzo IP interno e dalla stessa porta sono mappate allo stesso indirizzo IP esterno e alla stessa porta. Inoltre, ogni host esterno può inviare un pacchetto all'host interno e inviare un pacchetto all'indirizzo esterno mappato.
Coni limitati: un NAT con coni limitati è un nodo in cui tutte le richieste provenienti dallo stesso indirizzo IP interno e dalla stessa porta sono mappate allo stesso indirizzo IP esterno e alla stessa porta. A differenza di un NAT a cono intero, un host esterno (con indirizzo IP X) può inviare un pacchetto all'host interno solo se l'host interno ha già inviato un pacchetto all'indirizzo IP X.
Coni con restrizioni di porta: un NAT con coni con restrizioni di porta è simile a un NAT con coni con restrizioni, ma la restrizione include i numeri di porta. In particolare, un host esterno può inviare un pacchetto, con indirizzo IP di origine X e porta di origine P, all'host interno solo se l'host interno aveva precedentemente inviato un pacchetto all'indirizzo IP X e alla porta P.
Simmetrico: per NAT simmetrico si intende una NAT in cui tutte le richieste provenienti dallo stesso indirizzo IP interno e dalla stessa porta verso una destinazione IP e un indirizzo IP specifici vengono mappate alla stessa porta e allo stesso indirizzo IP esterno. Se lo stesso host invia un pacchetto con lo stesso indirizzo di origine e la stessa porta, ma a una destinazione diversa, viene utilizzato un mapping diverso. Inoltre, solo l'host esterno che riceve un pacchetto può inviare un pacchetto UDP all'host interno.
Si consideri una topologia in cui l'origine (A, Pa) (dove A è l'indirizzo IP e Pa è la porta di origine) comunica con la destinazione (B, Pb) e (C, PC) tramite un dispositivo NAT.
| Tipo di implementazione NAT |
Fonte pubblica se destinata a (B, Pb) |
Origine pubblica se destinata a (C, Pc) |
La destinazione (ad esempio (B, Pb) ) può inviare traffico a (A, Pa)? |
| Coni completi |
(X1,Px1) |
(X1,Px1) |
Sì |
| Cono con restrizioni |
(X1,Px1) |
(X1,Px1) |
Solo se (A, Pa) ha inviato il traffico a B |
| Cono con restrizioni della porta |
(X1,Px1) |
(X1,Px1) |
Solo se (A, Pa) ha inviato il traffico a (B, Pb) |
| Simmetrico |
(X1,Px1) |
(X2,Px2) |
Solo se (A, Pa) ha inviato il traffico a (B, Pb) |
Problemi di NAT Traversal e NAT simmetrico
I server STUN rispondono alle richieste di binding STUN inviate dai client STUN e forniscono l'IP/porta pubblica del client. Ora, questa combinazione di indirizzo/porta viene utilizzata dal client STUN nella sua segnalazione di comunicazione peer-to-peer. Tuttavia, ora che l'endpoint utilizza lo stesso indirizzo/porta privato (si supponga che sia associato all'IP/porta pubblico fornito nella risposta STUN), il dispositivo NAT lo converte nello stesso IP ma su una porta diversa se viene utilizzata l'implementazione NAT simmetrica. In questo modo la comunicazione UDP viene interrotta perché la segnalazione ha stabilito la connessione in base alla porta precedente.
L'implementazione NAT dei router Cisco IOS® quando esegue PAT è simmetrica per impostazione predefinita. Pertanto, è previsto che si verifichino problemi di connessione UDP con questi router che eseguono NAT.
Tuttavia, l'implementazione NAT dei router Cisco IOS-XE quando esegue il PAT non è simmetrica. Quando si inviano due flussi diversi con lo stesso IP di origine e la stessa porta, ma a destinazioni diverse, l'origine ottiene NATED allo stesso IP e alla stessa porta globali interni.
La soluzione al problema
Da questa descrizione è chiaro che il problema può essere risolto se si esegue il mapping indipendente dall'endpoint.
Come stabilito dalla RCFC 4787: con EIM (Endpoint-Independent Mapping), il protocollo NAT riutilizza il mapping delle porte per i pacchetti successivi inviati dallo stesso indirizzo IP interno e dalla stessa porta (X:x) a qualsiasi indirizzo IP e porta esterni.
Da un client, quando l'host finale esegue i comandi nc -p 23456 10.0.0.4 40000 e nc -p 23456 10.0.0.5 50000, su due diverse finestre del terminale, di seguito sono riportati i risultati delle traduzioni NAT se si utilizza EIM:
Pro Inside global Inside local Outside local Outside global
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.4:40000 10.0.0.4:40000
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.5:50000 10.0.0.5:50000
Come si può notare, i diversi flussi di traffico con lo stesso indirizzo di origine e la stessa porta vengono convertiti nello stesso indirizzo/porta indipendentemente dalla porta/indirizzo di destinazione.
Sui router Cisco IOS, è possibile abilitare l'allocazione delle porte agnostiche dell'endpoint con il comando ip nat service enable-sym-port.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-15-mt-book/iadnat-fpg-port-alloc.html
Riepilogo
L'implementazione NAT di Cisco IOS è simmetrica per impostazione predefinita quando si utilizza Port Address Translation (PAT) e può causare problemi quando passa il traffico UDP P2P che richiede server come STUN per l'attraversamento NAT. Per eseguire questa operazione, è necessario configurare in modo esplicito EIM sul dispositivo NAT.
Feedback