VoIP e NAT – Il protocollo STUN, parte prima

Tempo fa mi sono state sottoposte alcune domande riguardanti il VoIP, soprattutto come utilizzarlo in presenza di firewall e NAT che possono rendere impossibile la comunicazione a voce su IP. Dalla semplice risposta che mi ero proposto di scrivere, ne è scaturito qualcosa di un po’ più articolato, che prende di petto alcuni dei problemi nei quali incorrono gli utilizzatori del VoIP, tentando di dare una semplice spiegazione teorica. Il testo è diviso in due differenti parti, per dare al lettore il tempo di assimilare i contenuti in maniera graduale. L’inizio riprende alcune domande che mi sono state poste, per poi passare a un approfondimento teorico.

Ci sono altri protocolli che mi sarebbe utile avere?

Al limite il protocollo proprietario di Skype, se vuoi usare questo servizio per chiamare e ricevere, oppure IAX per il supporto dei centralini Asterisk. A dire la verità, il discorso sarebbe un poco più complesso, ma esula da ciò che ci interessa ora.

Ora, non penso proprio che tu possa implementare un centralino Asterisk a casa e comunque potresti interfacciarti tramite SIP.

Per Skype, si tratta di un protocollo proprietario. Questo dipende da te. Esistono in commercio, e li trovi in qualsiasi magazzino di elettronica (Mediaworld, Euronics, Saturn, per esempio), degli ATA Skype. Con questa soluzione, però, rimani vincolato a questa architettura, mentre con SIP puoi interfacciarti a parecchi provider VoIP sul mercato. Hai più soluzioni aperte, o come sarei tentato di dire, più Sorgenti Aperte.

Al limite, verifica di avere SIP2 (RFC 3261). Non starei ad approfondire i protocolli di trasporto e i codec: per un’utenza domestica sono dettagli che hanno poco senso. Prendi un prodotto “mainstream” e inizia a telefonare, vedrai che andrà tutto bene.

:: Supporto STUN: se stai dietro a un router, il supporto STUN ti
:: consente comunque di collegarti al provider VoIP.

Di cosa si tratta esattamente? Mi occorrono altri supporti?

Lo STUN (Simple Traversal of User Datagram Protocol Through Network Address Translators – RFC 3489) è un protocollo che permette di aggirare un problema che si verifica quando chi vuole usare il VoIP si trova dietro a un router o a un firewall.

In pratica, per instaurare una telefonata bisogna creare un circuito di dati fra due client che instaurano una connessione. Un circuito è identificato da una coppia di tuple INDIRIZZO:PORTA. In pratica, il canale di trasmissione si instaura nel seguente modo:

PORTA ————– PORTA
IP ————– IP

Cioè i due client devono conoscere i reciproci indirizzi IP e porte attraverso cui è possibile far scorrere il flusso di dati (la telefonata).

Quale è il problema? Il problema sta nel fatto che se hai un router di mezzo, tipico il router ADSL domestico, questo esegue un NAT (Network Address Translation – RFC 3022) tra l’indirizzo IP pubblico e l’IP del computer o dell’ATA usato per chiamare. Ovvero:

IP_INTERFACCIA_PROVIDER_VERSO_UTENTE
|
|
|
IP_INTERFACCIA_PUBBLICA_ROUTER_UTENTE
|
|
|
IP_INTERFACCIA_ETHERNET_INTERNA_ROUTER
|
|
|
IP_INTERFACCIA_ETHERNET_CLIENT_VOIP

Ora, come puoi ben vedere, il client che usi per chiamare, sia esso il PC di casa o l’ATA, sta in fondo alla catena e conosce solo il proprio indirizzo IP, tipicamente appartenente a una classe privata (192.168.x.x, 10.x.x.x, da 172.16.x.x a 172.31.x.x – BEST CURRENT PRACTICE 0005 – RFC 1918), non visibile da internet e quindi il tuo ATA o il programma che usi per effettuare le chiamate non conosce due informazioni fondamentali:

1. Quale è l’indirizzo IP che il provider ha assegnato in quel momento al router della propria rete
2. Quali sono le porte UDP (User Datagram Protocol) disponibili per ricevere i dati inviati dal dal provider VoIP e che consistono, primariamente, nel flusso di dati che contiene l’audio del proprio interlocutore.

Perché abbiamo bisogno di sapere queste due informazioni? Beh, ci vuole un po’ di teoria.

Quando ti colleghi a internet da dietro un firewall tu hai un IP privato, non raggiungibile da internet. Ma se richiedi una pagina a un server web, come fa questo a spedirtela, visto che non sa può raggiungere il tuo indirizzo privato che, per definizione, è irraggiungibile da internet?

Il trucco c’è, ma non si vede e si chiama Network Address Translation, detto anche NAT o IP Masquerading. Come funziona? Semplicemente, è il router a giocare un ruolo attivo: quando vede che il PC della rete privata tenta di stabilire una connessione verso l’esterno, gioca un piccolo scherzo ai pacchetti che lo attraversano per uscire e ne riscrive l’IP di origine. Già, perché ogni pacchetto porta in sé almeno quattro informazioni fondamentali: l’IP e la porta che lo hanno generato, l’IP e la porta verso cui è destinato. Il router, modifica l’IP di provenienza del pacchetto in uscita, facendolo corrispondere all’IP della propria interfaccia pubblica, facilmente raggiungibile da internet.

A questo punto, il server, il servizio, il corrispondente che voglia rispondere al pacchetto inviato, non dovrà fare altro che leggere l’IP di provenienza per sapere a quale indirizzo inviare la risposta. Ora, la risposta viene inviata all’indirizzo pubblico del router che, vedendosi arrivare il pacchetto sulla connessione sa già da dove si è originata quest’ultima e non fa altro che riscrivere l’IP di destinazione del pacchetto di risposta, per rinviarlo al computer (o ATA) nella rete interna che solo lui, il router, può vedere “dall’esterno”, visto che ha un piede fuori e uno dentro.

Il concetto fondamentale che sta dietro al NAT è quello della connessione: il router si “segna” gli indirizzi (e le porte) reali dei due estremi della connessione e poi opera le traduzioni appropriate affinché i due estremi abbiano l’illusione di comunicare direttamente.

Dove sta l’inghippo? Sta nell’eventualità in cui una connessione venga originata dall’esterno. In questo caso, chi sta fuori può solo indicare come destinatario l’indirizzo IP pubblico del router ma poi, quest’ultimo, non avendo alcuna connessione già attiva di riferimento, non sa dove reindirizzare i pacchetti. Questo a meno di utilizzare un bi-nat, chiamato anche full cone nat. In questo caso, ogni porta dell’IP pubblico del router viene mappata sulla corrispondente di un preciso indirizzo privato interno e si ha una situazione simile a quella in cui la macchina interna fosse esposta direttamente a internet.

Comunque, come fare il tuo computer a sapere a quale porta mettersi in ascolto? E, poi, sarà raggiungibile su una data porta, su protocollo UDP (User Datagram Protocol – STANDARD 00006)? Già, perché le connessioni VoiP utilizzano il protocollo RTP (Real-time Transport Protocol – STANDARD 00064), generalmente su porte UDP. O meglio, il protocollo RTP può usare come trasporto anche TCP (STANDARD 00001), SCTP (RFC 3309), etc., ma viene comunemente usato UDP dato che questo è il mezzo di trasporto ideale per le comunicazioni in streaming broadcast e multicast. Il perché è presto detto: a differenza del TCP che ha un meccanismo di controllo dell’integrità dei pacchetti, l’UDP non ce l’ha, risultando più veloce. Semplificando, nel momento di spedire un pacchetto, il TCP gli assegna un numero sequenziale che verrà letto dallo stack TCP del ricevente: se il pacchetto è arrivato nella giusta sequenza ed entro un tempo limite, il ricevente spedisce un OK al mittente e attende il pacchetto seguente. Gestendo le risposte, il mittente sa quali pacchetti sono arrivati correttamente, quali devono essere rispediti un’altra volta e quali nuovi pacchetti inviare.

Con UDP no. Vi è una verifica sull’integrità del singolo pacchetto, ma non della connessione. Il protocollo UDP non sa se un pacchetto è arrivato nella giusta sequenza e in tempo. Ed è per questo che nelle comunicazioni multimediali che utilizzano questo protocollo di trasposto può capitare di trovare buchi e interruzioni nella trasmissione: non vi è modo di richiedere il reinvio di un pacchetto perso e non è previsto, a livello di protocollo, un meccanismo di ritrasmissione dei dati.

Comodo ma poco affidabile: non dovendo fermarsi a controllare cosa è arrivato e cosa no, che cosa bisogna rinviare e cosa no, il protocollo UDP consente di inviare dati a una velocità maggiore rispetto al TCP, ma non assicura una corretta trasmissione.

Ora, abbiamo visto come un client possa trovarsi dietro a un router, ma anche a due o tre, dipende dal tipo di rete in cui è immerso e a seconda della sua topologia si possono riscontrare quattro diversi tipi di NAT (RFC 4008):

Full Cone: è un tipo di NAT che prevede una corrispondenza biunivoca fra indirizzo esterno del router/firewall e indirizzo interno di un unico client: Quando un client con un preciso indirizzo IP interno spedisce un pacchetto verso l’esterno, il suo IP/PORTA di origine vengono rimappati sul corrispondente IP/PORTA pubblici del router/firewall. Se un pacchetto viene inviato a una PORTA/IP pubblica del router, questo viene reindirizzato a 1 indirizzo preciso della rete interna. In pratica è come se una sola macchina della rete interna venisse a trovarsi sul perimetro esterno, quasi come se la sua scheda di rete avesse l’indirizzo pubblico del router. Quasi come.

Restricted Cone: Come per il Full Cone NAT, 1 IP/PORTA interno è mappato sull’IP/PORTA esterno del router/firewall. A differenza del Full Cone NAT, dall’esteno possono raggiungere l’IP interno solo quei pacchetti che fanno parte di una connessione stabilita dal client interno verso l’esterno. In pratica, i pacchetti di una connessione autonomamente generata dalla rete esterna al router, non vengono reindirizzati al all’IP/PORTA del client della rete interna, mentre vengono rimappati quelli che “tornano” dall’esterno come risposta a pacchetti generati da una connessione proveniente dal client della rete interna. E’ la configurazione classica di un router/firewall domestico.

Port Restricted Cone: Assomiglia al Restricted Cone NAT, con un’ulteriore restrizione sulle porte: un pacchetto proveniente dalla rete esterna al router/firewall e dotato di una precisa tupla IP/PORTA può essere reindirizzato verso il client della rete interna solo se il client della rete interna ha PRIMA inviato un pacchetto al medesimo IP/PORTA del mittente. In pratica, se una macchina esterna ha come indirizzo 88.22.56.98 e ha spedito un pacchetto dalla porta 16643, questo raggiungerà il client della rete interna, passando attraverso il router/firewall, solo se PRIMA il client della rete interna avrà mandato un pacchetto all’indirizzo 88.22.56.98, sulla porta 16643.

Symmetric: Un Symmetric NAT è qualcosa di “unico”: come nel full nat, una connessione originata da una IP/PORTA interna verso un IP/PORTA esterna avrà una mappatura IP/PORTA pubblica sull’interfaccia esterna del router. La differenza risiede nella destinazione e nella “dinamicità” del mapping: ogni volta che o l’IP o la PORTA di destinazione cambiano, verrà utilizzato un mapping diverso sull’interfaccia esterna del router, ovvero una differente combinazione IP/PORTA pubblica. In più, solo l’host esterno che riceve un pacchetto può replicare con un pacchetto UDP verso l’host con indirizzo privato. Questa è una configurazione tipica di una rete aziendale.

Il tutto suona un po’ strano? Ebbene si, in effetti le definizioni di nat si sprecano e variano a seconda delle implementazioni e, direi, delle mode.

Comunque, due client che vogliano iniziare una comunicazione SIP (RFC 3261) si trovano generalmente in questa messe di problemi: di solito ognuno di loro sta dietro uno o più router/firewall, conosce solo il proprio IP interno e non sa nemmeno a quali restrizioni è sottoposto il traffico.

Ma cosa è, a grandi linee, SIP? Prendendo direttamente dal preambolo della RFC 3261 che lo descrive, SIP, Session Initiation Protocol, è un protocollo a livello di applicazione utilizzato per creare, modificare e terminare sessioni con uno o più partecipanti, sessioni che possono includere telefonate via internet, distribuzione di contenuti multimediali e conferenze multimediali. Nel momento stesso in cui un interlocutore viene invitato (signaling) in una sessione, il protocollo SIP veicola in questo invito una serie di informazioni riguardanti i tipi di media che possono essere utilizzati in modo che tutti i partecipanti possano adottare uno o più media comuni, anche contemporaneamente, attraverso i quali scambiare i dati.

Non solo, SIP è in grado di utilizzare una serie di proxy server dedicati per veicolare al meglio le richieste verso l’utente, per autenticare e autorizzare gli utenti all’utilizzo di un dato servizio, implementare le regole di routine delle chiamate e offrire in genere servizi all’utente. In più, SIP offre una funzione di registrazione che permette agli utenti di inviare ai proxy le informazioni riguardanti la loro posizione, in modo da facilitare il routine delle chiamate.

Attenzione, però: SIP è un protocollo a livello di applicazione, non un protocollo di trasporto e non ha nemmeno il controllo totale delle comunicazioni che contribuisce a gestire. Ciò significa che serve a far comunicare le applicazioni, non a veicolare i dati e, infatti, può essere pensato come un componente che sta al di sopra di altri protocolli come RTP (Real-Time Transport Protocol – RFC 1889), RTSP (Real-Time Streaming Protocol – RFC 2326), MEGACO (Media Gateway Control Protocol – RFC 3015), SDP (Session Description Protocol – RFC 2327). SIP non fornisce quindi un vero e proprio servizio di comunicazione ma solo un insieme di funzioni di base per iniziare, gestire e terminare le connessioni, gestite a loro volta da altri protocolli più specifici.

Volendo, si può pensare a SIP come a uno strumento di localizzazione: consente di localizzare i partecipanti a una conversazione e di scoprire quali funzioni multimediali sono in grado di condividere.

Ora, però, torniamo sull’argomento STUN. Dato che due client sono normalmente dietro un NAT, come possono questi arrivare a conoscere il proprio indirizzo pubblico, da comunicare al proxy cui registrarsi, le porte UDP disponibili e la modalità di NAT adottata?

Qui entra in gioco il protocollo STUN, basato su un’architettura client/server: il client è implementato nell’applicazione VoIP, o nell’ATA, il server all’interno di proxy dedicati visibili su internet.

Il punto di svolta sta proprio in questo “visibili su internet”: un provider VoIP che voglia rendere più semplice ai propri utenti una chiamata può creare un proxy STUN che abbia un indirizzo pubblico raggiungibile su internet: sarà il proxy ricevere una richiesta dal client posto sulla rete privata, ad analizzare dall’esterno il router/firewall che impedisce la libera comunicazione e a inviare verso la rete privata tutte le informazioni necessarie ad aggirare il blocco.

Ma come?

• Categoria: VoIP
• Tag: Applicazioni, FON, Ftp, Internet, Mac, Pc, Skype, Web