Perché parlare di Routing e NAT con esplicito riferimento al VoIP SIP? Il motivo è molto semplice: uno dei requisiti fondamentali affinché le telecomunicazioni VoIP funzionino correttamente è quello di predisporre e configurare una corretta infrastruttura di rete LAN, opportunamente collegata alla rete Internet. Non è infatti possibile installare correttamente un sistema Voice over IP ignorando gli aspetti legati al routing e al NAT.
Durante tutti i Corsi di formazione e Certificazione della VoIP Academy VoipVoice, il concetto di NAT per il VoIP viene trattato e discusso in maniera approfondita su più livelli. Le criticità relative al NAT in ambito VoIP devono sempre essere pianificate, previste e risolte prima ancora di procedere all’installazione dei telefoni e dei centralini VoIP. Anche la scelta degli apparati di routing da impiegare è fondamentale. Procedere per tentativi, senza far ricorso alle basi teoriche del protocollo SIP e dei meccanismi alla base del NAT, è una pessima idea.
Per rendere ogni installazione VoIP perfetta ed esente da problemi, è necessario che l’installatore conosca i principi di funzionamento del protocollo SIP e le modalità di possibile interazione tra il protocollo SIP e i meccanismi di NAT presenti nell’attraversamento dalle reti private verso quelle pubbliche.
Il NAT VoIP
Il NAT (Network Address Translation) è la tecnologia più comunemente utilizzata da firewall e router per consentire ai dispositivi presenti all’interno di una rete locale LAN, con indirizzi IP “privati”, di condividere un unico indirizzo IP pubblico. Un indirizzo IP privato è un indirizzo che può essere utilizzato solo all’interno della LAN, ma non è direttamente raggiungibile da Internet o al di fuori della rete LAN.
Affinché un dispositivo con un indirizzo IP privato possa comunicare con altri dispositivi su Internet, è necessario che vi sia una traduzione tra indirizzi IP privati e pubblici nel punto in cui la LAN si connette a Internet, cioè all’interno del firewall / router che si connette la LAN a Internet. Tale traduzione è comunemente chiamata NAT (Network Address Translation) e viene effettuata da un apparato router/firewall NAT. Molto spesso il NAT è anche denominato “IP Masquerading”.
Quando si parla genericamente di NAT, in realtà si opera una semplificazione. Sarebbe infatti più corretto parlare sempre di NAPT ossia di traduzione degli Indirizzi IP e delle rispettive porte di comunicazione (Network Address and Ports Translation). Questa considerazione è ancor più indispensabile quando si parla di NAT VoIP.
Come funziona il NAT ?
Il meccanismo di funzionamento del NAT è abbastanza semplice. Quando un dispositivo all’interno della LAN avvia una connessione con un dispositivo su Internet, il dispositivo invierà prima tutto il traffico al router NAT. Il router NAT sostituisce quindi l’indirizzo di origine, che è l’indirizzo privato del dispositivo, con il proprio indirizzo pubblico prima di trasferire il traffico alla sua destinazione su Internet. Quando riceve una risposta, il router NAT cerca nelle sue tabelle di traduzione (NAT mapping Table) per trovare l’indirizzo di origine iniziale del pacchetto. Una volta identificato il dispositivo sulla LAN ha originariamente avviato la connessione, il router inoltra la risposta a quel dispositivo. Si tratta, in sostanza di un processo continuo di traduzione di Indirizzi e porte tra l’ambito della rete “privata” e quella “pubblica”.
Ma cosa accade quando la connessione avviene da Internet verso la rete locale? In questo caso infatti non sarà chiaro con quale dispositivo sulla LAN si intenderà stabilire la connessione. Sarà necessaria una regola che indichi al router NAT come comportarsi con il traffico in entrata. Nel caso in cui la regola non sia presente, il router scarterà semplicemente il traffico e non stabilirà alcuna connessione. Il router NAT potrà instradare tutto il traffico in entrata ad un solo dispositivo oppure, come più comunemente avviene, utilizzare la tecnica del “Port Forwarding” per consentire al router NAT di passare le richieste di connessione in entrata a diversi dispositivi sulla LAN a seconda della tipologia di protocollo e di porta utilizzata.
Perché il NAT rappresenta una criticità nell’ambito del VoIP ?
Il protocollo SIP è particolarmente sensibile alla traduzione di indirizzi IP e porte. Il protocollo SIP è concepito come protocollo di segnalazione per avviare, modificare e concludere una chiamata. Esso non si occupa quindi direttamente della trasmissione dell’audio, che avviene attraverso il protocollo RTP, ma si preoccupa di istruire i dispositivi in merito agli indirizzi IP e alle porte sulle quali deve avvenire la trasmissione audio RTP.
Il meccanismo di funzionamento del NAT è identico anche quando si naviga su un sito Web utilizzando un PC connesso a Internet tramite un dispositivo NAT. Tuttavia, il protocollo HTTP utilizzato per la navigazione web è molto meno sensibile alle sostituzioni di indirizzi effettuate dal dispositivo NAT. Esso richiede richiede solo che il server web sia in grado di inviare risposte direttamente al browser tramite le stesse porte che sono state utilizzate per avviare il dialogo.
Sfortunatamente, SIP è notevolmente più complicato di HTTP perché implica la negoziazione a due vie tra il dispositivo client e il server. Un elemento essenziale di questa negoziazione è stabilire l’instradamento dei flussi multimediali audio. I flussi audio utilizzano il protocollo RTP e sono generalmente stabiliti direttamente tra endpoint utilizzando porte diverse da quelle utilizzate per i messaggi SIP. Le porte RTP entrano in uno stato di “ascolto” in base al quale possono accettare una nuova connessione da un dispositivo remoto. L’indirizzo IP e il numero di porta RTP sulle quali avviare l’audio, vengono scambiati tra i dispositivi attraverso un messaggio di Richiesta (INVITE) e il relativo messaggio di risposta (200 OK) . Questa fase si chiama “Setup della chiamata”. Gli endpoint devono connettersi tra loro sulle porte pubblicizzate per stabilire una connessione audio bidirezionale.
Il Protocollo SIP deve essere in grado di attraversare il NAT
Il protocollo SIP trasmette quindi i parametri necessari per avviare la comunicazione all’interno dello stesso messaggio SIP. Tali parametri includono l’IP e i numeri di porta utilizzati per la segnalazione e la trasmissione dei flussi multimediali. Un dispositivo SIP dietro NAT non sa molto di come esso verrà visto sulla rete Internet, conosce solo il proprio indirizzo IP locale e le porte sulle quali viene eseguita l’applicazione SIP. Una volta avviata la comunicazione con Internet, il dispositivo NAT traduce la combinazione “IP privato : porta” del dispositivo SIP connesso sull’interfaccia NAT privata in una mappatura temporanea di un “IP pubblico : porta” sull’interfaccia connessa a Internet.
Il NAT può provocare degli errori nella comunicazione VoIP SIP
Sono moltissime le circostanze in cui ci può essere un conflitto tra il protocollo SIP e il comportamento, a livello di NAT, di un router/firewall. Ecco gli errori più comuni:
- Durante la richiesta di registrazione sul server di un provider VoIP SIP (come ad es. VoipVoice), il telefono IP oppure il PBX comunica al Server SIP l’indirizzo e la porta sulla quale può essere raggiunto per instradare le chiamate in entrata. Molto spesso, quando la configurazione dell’apparato non è corrretta, l’indirizzo IP fornito al server di registrazione è l’indirizzo LAN privato del telefono IP e non l’indirizzo pubblico del router NAT. In questi casi, in assenza di meccanismi di correzione, il provider di servizi potrebbe non essere in grado di inviare messaggi SIP al telefono IP.
- quando un telefono SIP effettua una chiamata, invia una richiesta SIP INVITE. All’interno di tale richiesta, nella sezione SDP, invia anche l’indirizzo IP e la porta sulla quale si aspetta di ricevere il flusso audio. La connessione utilizzata per i messaggi SIP che iniziano e terminano le chiamate (flusso SIP) non è la stessa connessione utilizzata per inviare il flusso audio (flusso RTP). Il flusso audio viene sempre stabilito su una nuova connessione utilizzando un numero di porta completamente diverso da quello SIP. I router NAT normalmente consentono le connessioni in uscita, ma bloccano quelle in entrata. Ciò significa che il telefono potrebbe comunicare al dispositivo remoto di avviare una connessione streaming multimediale , ma il dispositivo remoto potrebbe non essere in grado di aprire la connessione perché bloccato dal dispositivo NAT.
I Sintomi di una chiamata VoIP con problemi di NAT
Ecco un elenco dei problemi più comuni che potresti incontrare in caso di configurazioni errate a livello di Telefono, Centralino o Router:
- Assenza di audio: la chiamata si avvia, il telefono squilla ma, alla risposta c’è silenzio in entrambe le direzioni.
- Audio monodirezionale: la chiamata si avvia, il telefono squilla ma, alla risposta puoi solo sentire la controparte ma non puoi essere ascoltato, o viceversa.
- Impossibilità di ricevere chiamate: Un altro sintomo è che tu possa chiamare altre persone, ma esse non possono chiamarti. Una variazione di questo comportamento è che altre persone possano chiamarti nei primi minuti dopo che il tuo telefono è stato registrato, ma non dopo 10 o 20 minuti.
Quali sono le soluzioni possibili per l’attraversamento NAT VoIP ?
Quando un telefono IP o un Centralino sono installati dietro NAT, i problemi possono essere creati dal dispositivo NAT stesso (router/firewall), dall’incapacità del telefono di comprendere correttamente il proprio posizionamento di rete o da una combinazione delle due eventualità. Poiché è un problema frequente e prevedibile, la maggior parte dei telefoni IP dispone di funzionalità integrate progettate per aiutarli ad analizzare il proprio ambiente di rete e per aiutare a superare i problemi dell’attraversamento NAT VoIP. Vi sono moltissimo metodi disponibili per il superamento delle barriere di NAT. Ogni professionista installatore dovrebbe conoscere nel dettaglio tutti questi metodi e sapere quale utilizzare in ogni precisa circostanza. La norma di riferimento per il NAT Traversal in ambito SIP è la RFC6314.
1 – STUN (Simple Traversal of UDP through NAT)
Lo STUN è un approccio standard per l’attraversamento di NAT. I dettagli tecnici sono pubblicati come RFC 3489. Richiede che il telefono IP possa accedere ad un server STUN da qualche parte su Internet. VoipVoice fornisce ad esempio il proprio server Stun all’indirizzo stun.voipvoice.it, sulla porta standard 3478. E’ disciplinato dalle RFC3489, RFC5389, RFC 8489
Come Funziona un Server STUN e quali informazioni fornisce?
Per poter utilizzare lo STUN è necessario comunicare al telefono IP l’indirizzo (o URL) di un server STUN su Internet. E’ sempre consigliabile utilizzare il server STUN consigliato dal proprio provider anche se non è obbligatorio. Il server STUN non prevede infatti un dialogo di autenticazione, quindi in genere qualsiasi telefono può utilizzare qualsiasi server STUN. Tutti i telefoni IP VoIP SIP recenti prevedono l’utilizzo di un server Stun.
Il telefono IP (o il Centralino IP) prima di effettuare qualsiasi tentativo di registrazione o chiamata, invia una serie di richieste al server STUN specificato. Il server STUN esegue alcuni semplici test per determinare cose come: Il telefono IP è dietro un dispositivo NAT? Qual è l’indirizzo IP esterno del dispositivo NAT? In che misura il dispositivo NAT applica le regole per il blocco delle connessioni UDP in entrata? Fa differenza per le connessioni in entrata se è già stata stabilita una connessione in uscita a quell’indirizzo remoto?
In sostanza le informazioni fornite da un server stun saranno due:
- Indirizzo IP pubblico utilizzato sul lato WAN dell’apparato Router/Firewall
- Tipologia di NAT e di PAT (Port Address Translation) utilizzata dal Router.
Una volta effettuate questi test il server STUN restituisce i risultati al telefono IP. Il telefono IP è quindi in grado di utilizzare queste informazioni per modificare i messaggi SIP che invia quando si registra oppure prima di effettuare la chiamata. All’interno del messaggio SIP verranno utilizzati gli indirizzi IP pubblici in luogo di quelli privati e le rispettive porte corrispondenti, in funzione della tipologia di NAT utilizzato.
Quali sono i limiti di utilizzo di un Server Stun ?
L’utilizzo del server STUN è principalmente indicato per il collegamento di Telefoni IP ad un provider VoIP o ad un Centralino VoIP in Cloud. Dovendo interrogare un server esterno, lo STUN introduce necessariamente un ritardo, più o meno avvertibile, nella composizione delle chiamate. Per questa ragione l’utilizzo dello STUN server è sconsigliabile in abbinamento ai Centralini IP per i quali esistono sistemi più efficaci: in primo luogo la configurazione di opportune regole di Port Forwarding e inserimento diretto dell’indirizzo IP statico pubblico utilizzato.
2 – Port Forwarding (Port Mapping)
Il concetto di Port Forwanding si riferisce ad un Router-Firewall. Il Port Forwarding, anche detto “Port Mapping”, si ottiene creando un’associazione (chiamata mappa) tra un indirizzo IP pubblico (WAN) con la rispettiva porta e un indirizzo IP privato (LAN) con la rispettiva porta. Il compito del Port Forwarding è quello di indirizzare il traffico dal mondo esterno al server appropriato all’interno di una rete TCP / IP locale. La norma RFC di riferimento è la RFC6886 .
NAT Statico e NAT Dinamico
A livello generale è infatti possibile distinguere due tecniche per la traduzione degli indirizzi di rete: il NAT Statico e il NAT Dinamico.
- Nel caso di NAT Dinamico, la tabella di NAT viene popolata automaticamente in funzione delle connessioni avviate da un Client della rete interna verso la rete esterna. Questa modalità di NAT è anche detta Ip Masquerading o IP Overloading. I Record della tabella di NAT in questo caso sono temporanei e il router li aggiorna dinamicamente in funzione delle connessioni attive.
- Nel casi di NAT Statico, la corrispondenza tra indirizzo IP e relative porte, private e pubbliche, viene definito con regole permanenti. Rispetto al NAT dinamico, il NAT statico presenta il vantaggio di poter rendere raggiungibili non solo i client che iniziano le sessioni di comunicazione, ma anche i server interni a una rete privata. In questo secondo caso, i record della tabella di NAT sono scritti in maniera permanente.
Il Port Mapping in ambito VoIP SIP
Quando si lavora con dispositivi VoIP SIP dietro ad un NAT, soprattutto nel caso di Centralini VoIP SIP, è fortemente consigliato operare con un NAT statico. Le porte che in genere dovrebbero essere inoltrate sono le seguenti:
- La porta di ascolto SIP principale: normalmente corrisponde con la porta 5060. Il protocollo può essere UDP oppure TCP
- Il Range di porte destinato allo scambio audio RTP e al flusso di controllo RTCP: per ogni comunicazione SIP è richiesta una porta per lo scambio audio/video multimediale (RTP – porta pari) e una porta per lo scambio delle informazioni di controllo (RTCP – porta dispari). In questo caso viene comunemente inoltrato un intervallo di porte piuttosto ampio (ad. es. 20000 -30000). Il protocollo utilizzato è sempre UDP.
Nel caso di Centralini VoIP Ip sarà sempre necessario configurare o conoscere la porta di ascolto SIP utilizzata e il relativo range di porte RTP/RTCP. Al fine di garantire la piena compatibilità con il protocollo SIP sarà sempre raccomandabile non utilizzare alcuna traduzione delle porte. In sostanza la porta “privata” di ascolto e quella “pubblica” dovranno sempre corrispondere. Questo particolare comportamento a livello di NAT è definito Static Port Mapping ed è quello raccomandato con qualunque PBX VoIP.
3 – Impostazione manuale dell’indirizzo IP pubblico
Alcuni dispositivi VoIP – Telefoni IP e Server SIP come Asterisk o 3CX – dispongono di parametri parametri configurabili che includono un’opzione per specificare l’indirizzo IP dell’interfaccia esterna sul dispositivo NAT. Quindi, ad esempio, se il vostro PBX basato su Asterisk è dietro NAT e presenta problemi ad effettuare le chiamate SIP con provider VoIP esterni, è molto probabile che si possa risolvere il problema impostando l’IP pubblico esterno (nel file SIP.CONF – parametro “externip”) e abilitando il Port Forwarding.
La connessione Internet con IP pubblico statico è un elemento indispensabile per l’installazione professionale di qualunque Centralino IP. In questi casi l’indirizzo IP Pubblico statico e il comportamento del router dovrebbero sempre essere conosciuti a priori. Sarebbe quindi totalmente inutile ed inefficiente procedere utilizzando un server stun o funzionalità quali il KeepAlive. L’utilizzo a priori dell’indirizzo IP pubblico unito ad un Port Forwarding operato con Static Port Mapping garantiscono sempre il migliore risultato in assoluto e la certezza di una piena funzionalità.
4 – Keep Alive
La funzionalità di Keep-Alive è particolarmente efficace con i telefoni IP SIP utilizzati con configurazioni di NAT Dinamico. E’ presente in tutti i moderni telefoni VoIP SIP. E’ disciplinato dalla RFC6223 del 2011.
Quando un telefono IP effettua la registrazione su un VoIP Provider, esso comunica il proprio IP pubblico e la propria porta di ascolto, magari recuperate attraverso un server Stun. Il provider VoIP memorizzerà l’IP e la porta del telefono e supporrà che rimangano gli stessi a meno che non venga effettuata una registrazione con una configurazione diversa.
In questo contesto stiamo però operando in configurazione di NAT dinamico. I Router provvedono a creare dinamicamente la mappa di NAT. Così facendo essi provvedono a creare nuovi record di NAT ma anche ad eliminare periodicamente i record relativi a connessioni inattive.
Il criterio di funzionamento del NAT keepalive è molto semplice: il telefono IP, utilizzando il kee-alive invia pacchetti molti piccoli (in genere dei pacchetti vuoi) dal telefono IP verso il provider. Questi pacchetti, inviati ad intervalli di tempo regolari, di 10 o 15 secondi, hanno il solo scopo di mantenere attive le connessioni. In questo modo i record presenti nella tabella di NAT del Router (NAT mappping table) vengono mantenuti attivi. Il valore di keep alive suggerito in abbinamento agli account SIP Voipvoice è di 15 secondi.
Alcuni Consigli per L’utilizzo della funzionalità di Keep Alive:
- Il NAT Keep-Alive è molto utile in combinazione con la funzionalità di STUN e con quella di Rport. L’utilizzo combinati di Stun + Keep Alive + Rport consente ai telefoni IP di superare la maggior part delle barriere di NAT (dinamiche). Questa combinazione è molto utile per i telefoni IP ma è sconsigliata per i PBX. Per questi ultimi è invece preferibile un ambiente più stabile e senza la variabilità di porte legata al NAT dinamico. Per i Centralino VoIP la configurazione Ideale è legata all’utilizzo di NAT statico con mappatura statice delle porte (static port mapping); l’IP pubblico deve essere pre-configurato nel PBX stesso. Poichè il NAT statico espone potenzialmente le porte ad un attacco è sempre suggerito l’utilizzo di filtri ACL sulle regole di NAT.
- Quando in una rete locale sono presenti più telefoni IP che si registrano su un PBX in cloud, senza l’ausilio di SBC, è vivamente consigliabile differenziare le porte SIP e RTP utilizzate da ogni telefono. Ciò evita la sovrapposizione delle porte sul lato pubblico e consente, nei casi più difficili, di utilizzare anche regole di NAT statico per i telefoni.
5 – SIP “Received” e “Rport”
La RFC3581 del 2003 ha introdotto un’estensione al protocollo SIP molto utile per superare le difficoltà legate alla gestione del NAT simmetrico. In particolare mi riferisco alle estensioni “Received” e “rport” presenti nell’header SIP “VIA”. Il funzionamento di queste due estensioni è piuttosto complesso e viene trattato nel dettaglio durante i corsi di Certificazione VoipVoice. Nel caso in cui non si conoscano le basi del protocollo SIP, è sufficiente considerare questi meccanismi come un ulteriore supporto al superamento delle barriere di NAT.
Cercando di semplificare l’argomento, durante una chiamata SIP, il chiamato invia le risposte al chiamante determinando le informazioni nell’header “Via” , che viene creata dal chiamante, durante la composizione delle richieste iniziali (ad esempio: INVITE). Negli ambienti reali, quando la maggior parte degli endpoint si trova dietro un NAT, di solito essi, (in assenza di meccanismi come quelli visti al punto 1 e 3) si presentano con i loro indirizzi privati, che non sono raggiungibili dai server esterni.
La prima cosa da fare quando un dispositivo SIP (Telefono IP o PBX) si presenta al provider con un IP e una porta privata è quella di correggere immediatamente la configurazione, utilizzando uno dei metodi appena visti (punti 1-4).
Ciononostante è possibile che un PBX legacy si presenti ai nostri server SIP VoipVoice utilizzando nell’intestazione VIA gli identificativi (IP e porta) della rete locale e richiedendo una chiamata a un server pubblico esterno alla rete. Quell’URI non è assolutamente raggiungibile dal server. Pertanto, le risposte non torneranno mai correttamente al chiamante.
Via: SIP / 2.0 / UDP 192.168.XX: 5060 ; branch = c7hr56789er9943652834456
Un soluzione a questo problema passa per l’utilizzo delle estensioni “Received” e “rport” dell’header “VIA”
Il parametro “received”
“received” è un parametro standard nell’intestazione Via, che contiene l’effettivo indirizzo sorgente da cui è stato ricevuto il pacchetto. Il parametro “ricevuto” viene generato se l’IP nell’intestazione Via è diverso dall’indirizzo di origine del pacchetto UDP.
Il parametro “rport” (response-port)
“Rport” è in realtà un analogo al parametro “ricevuto”, tranne che “rport” contiene una porta, non un indirizzo IP, definito in rfc3581. Quando un controllo dell’account utente genera una richiesta, può contenere un parametro “rport” vuoto nell’intestazione Via. Quando un UAS riceve una richiesta, esamina l’intestazione Via più in alto per verificare l’esistenza del parametro “rport” senza valore, se ce n’è uno, DEVE impostare il valore del parametro sulla porta di origine della richiesta.
La presenza del parametro “rport” sovrascrive anche la regola per la generazione del parametro “ricevuto”: UAS deve inserire un parametro “ricevuto” contenente l’indirizzo IP di origine da cui proviene la richiesta, anche se identico al valore specificato nell’intestazione Via.
Quelli che stiamo esponendo sono concetti piuttosto complicati se non si hanno presenti le basi del protocollo SIP. Proviamo però a fare un esempio più concreto. Supponiamo che il PBX legacy sia più evoluto e supporti l’estensione RFC3561. Esso aggiungerà un parametro “rport” vuoto (senza una porta specifica) nella sua header “via” prima di inviare il proprio INVITE.
INVITE
Via: SIP / 2.0 / UDP 192.168.XX: 5060 ; branch = c7hr56789er9943652834456; rport;
In questo caso supponiamo che l’IP pubblico di origine sia 87.0.0.1 e la porta di origine sia 12345. Il server SIP VoipVoice, che supporta anche rfc3581, aggiungerà i parametri “rport” e “riceived” alla risposta 200 OK. Se la porta non sarà stata modificata, verrà aggiunto il solo parametro “received”
Via: SIP / 2.0 / UDP 192.168.XX: 5060 ; branch = c7hr56789er9943652834456; rport = 12345; received = 87.0.0.1
Il server in questo caso non rimanda le risposte all’indirizzo IP e alla porta presenti nell’intestazione Via (192.168.XX: 5060), ma a quelle presenti nei parametri “rport” e “received”, ossia all’indirizzo esterno e alla porta esterna ( 87.0.0.1 : 12345 ). Il dispositivo router, che gestisce l’associazione NAT, ritrasmetterebbe correttamente le risposte al PBX legacy utilizzato.
Se la spiegazione è stata troppo complessa è sufficiente pensare che l’estensione RFC3581 e i parametri “received” e “rport” consentono di mandare la risposta SIP semplicemente “indietro da dove è venuta la richiesta!”.
Attenzione a non abusare delle estensioni!
Le estensioni “received” e “rport” sono state introdotte per compensare le lacune del protocollo SIP nel 2003. Nel frattempo il protocollo SIP stesso e le funzionalità dei moderni Centralini SIP si sono evolute. Per questa ragione, qualora si rilevi l’utilizzo di un IP e una porta privata, al posto del corretto indirizzo IP e porta pubblica, è indispensabile andare a correggere la configurazione del telefono o del PBX affinché l’INVITE e l’header “via” siano correttamente trasmesse. In caso contrario si potranno verificare i comuni problemi di chiamata riconducibili a problemi di NAT.
