Capitolo 2 Il problema

Nel corso di questo capitolo daremo un breve cenno alle tecniche d'indirizzamento in Internet, spiegando quali sono i problemi generali derivati dall'utilizzo d'indirizzi di rete privati. Esamineremo poi l'indirizzamento H.323, e vedremo i problemi particolari creati dal protocollo, che implicano la necessità di un proxy. Infine, presenteremo delle soluzioni già realizzate.

Indirizzamento in Internet: reti pubbliche e private

(La trattazione dell'argomento è volutamente non approfondita: in questa sede, infatti, serve solo per introdurre la problematica che ha portato allo svolgimento del presente lavoro.)

La caratteristica principale di Internet è di fondere in un'unica architettura un'infinità di reti locali, potenzialmente disomogenee, e di permettere la comunicazione tra computer attestati sulle diverse sottoreti.

Ogni nodo della rete Internet è connesso a una rete locale, la quale a sua volta è connessa ad Internet mediante nodi detti router, che hanno la funzione di instradare la comunicazione verso l'esterno. L'instradamento ha luogo in base a un indirizzo IP, che individua i singoli nodi in modo univoco su scala mondiale. Un indirizzo IP consiste in un gruppo di 4 byte, il che permette di indirizzare un numero di host pari a oltre quattro miliardi.

In origine lo spazio di indirizzamento era partizionato in una gerarchia a due livelli: un indirizzo IP era cioè suddiviso in una parte che identificava la sottorete di appartenenza dell'host in questione (Network-ID), e una parte che identificava l'host all'interno di tale sottorete (Host-ID).

In tal modo ogni router dovrà essere a conoscenza solo degli indirizzi dei router che "servono" una determinata sottorete: esso inoltrerà i pacchetti a tali router, delegando loro la consegna finale dei pacchetti. Lo stratagemma serviva a ridurre le dimensioni delle tabelle di routing, e a velocizzare quindi il passaggio dei pacchetti nei router.

Figura 2.1 Classi di indirizzi IP

Più avanti la gerarchia ha subito un'ulteriore suddivisione, che riportiamo in figura 2.1.

I bit più significativi dell'indirizzo IP identificano 5 differenti classi di indirizzi:

Classe A: il primo bit è 0; sette bit sono riservati al Network-ID e 24 all'Host-ID. Abbiamo cioè (2 alla 7) 128 reti di classe A, ciascuna delle quali ha un numero di host pari a circa 16 milioni (2 alla 24).
Classe B: i primi due bit sono 10; quattordici bit sono riservati al Network-ID e i rimanenti 16 all'Host-ID. Questo significa circa 16000 reti di classe B, ognuna con 65000 host
Classe C: i primi tre bit sono 110; 21 bit sono riservati al Network ID e 8 all'Host-ID. Abbiamo due milioni circa di reti di classe C, con 256 nodi per rete.
Classe D: i primi bit sono 1110; 28 bit di indirizzo multicast per oltre 250 milioni di canali
Classe E: i primi bit sono 1111; 28 bit per usi futuri e ricerca

Questa suddivisione è stata fatta per esigenze amministrative e funzionali, ma comporta un'inefficienza nell'allocazione degli indirizzi; a lungo andare, vista la crescita esponenziale del World Wide Web, ciò ha causato una scarsa disponibilità di indirizzi IP.

Un primo provvedimento "tampone" nei confronti di questo problema è stata l'introduzione degli indirizzi "privati" (RFC 1918); esistono dei gruppi di indirizzi IP che non vengono instradati dai router, come ad esempio 192.168.x.y, oppure 10.x.y.z, e possono essere riutilizzati nelle reti private di tutto il mondo per realizzare le Intranet, operanti con gli stessi protocolli e applicativi che funzionano via Internet.

Poiché non sono univoci, essi non vengono instradati dai router del "cuore" di Internet.

Come un host ne raggiunge un altro via Internet

Ogni nodo conosce, oltre al proprio indirizzo IP, una maschera di sottorete composta di serie di uno e zero, in numero complessivo di 32. Un qualsiasi nodo A opera un AND bit a bit tra la maschera e l'indirizzo IP del nodo B che deve raggiungere, ottenendo il Network-ID dell'host: se quest'ultimo appartiene alla stessa sottorete allora A può individuare l'indirizzo Ethernet del destinatario e inviargli i pacchetti direttamente. In caso contrario A invierà il pacchetto al proprio gateway (un router) verso Internet.

Figura 2.2 Reti Pubbliche e private

L'utente di un'applicazione Internet in realtà non conosce gli indirizzi IP dei nodi cui si vuole connettere, ma li identifica per mezzo di nomi simbolici, gli "indirizzi Internet": ad esempio, l'indirizzo Internet del computer dove risiede il sito Web del Dipartimento Infocom è quello in tabella.

Per facilità d'uso un indirizzo IP non viene mai espresso come stringa di bit, ma in vari formati; ciascuno strato della pila ISO-OSI, usa una propria convenzione di indirizzamento (vedi esempio in tabella).

Strato	Formato dell'indirizzo
Applicazione	http: // frontcom.ing.uniroma.it
Trasporto	80 (Socket TCP)
Rete	151.100.10.136 (indirizzo IP)
Data link	a:b:c:d:e:f (indirizzo Ethernet)

Tabella 2.3 Formati d'indirizzo (esempio)

Il processo che individua l'indirizzo IP associato ad un indirizzo Internet si dice RISOLUZIONE, e avviene mediante l'interrogazione di un particolare nodo, il Domain Name Server (DNS).

In un indirizzo del tipo host.dominio.tld si ha:

tld =Top Level Domain, dominio di primo livello, che può essere un identificativo geografico oppure una sigla del gruppo .com, .edu, .org, retaggio della Internet "made In USA".
dominio è un nome registrato presso le autorità competenti, descrittivo del servizio informativo offerto
host identifica univocamente la macchina di indirizzo host.dominio.tld

Quando un nodo generico A deve comunicare con un nodo B di indirizzo nodoB.dominio.tld, interroga il proprio DNS per conoscerne l'IP; quest'ultimo fornisce l'informazione se la possiede, oppure gira la richiesta a un altro DNS, secondo una gerarchia di "autorevolezza".

Il problema degli indirizzi privati per applicativi generici

Abbiamo già detto che gli indirizzi privati non vengono instradati dal generico router. Non c'è alcun impedimento fisico oppure di software; semplicemente, tali indirizzi non sono univoci. Un router che non sia direttamente connesso alla LAN che usa quegli indirizzi privati non saprebbe come instradare i pacchetti ad essi diretti. Per comunicare con le reti pubbliche le reti private necessitano quindi di strumenti di "traduzione" di indirizzi, quali NAT routers, proxy servers, etc.

Un piccolo esempio estremamente semplificato: supponiamo che un browser web su un host A attestato su una LAN a indirizzamento privato voglia aprire una pagina web che risiede su un server pubblico. Ci sarà una richiesta a un DNS (non scendiamo nel dettaglio) e una risposta; l'host A "riconosce" che l'indirzzo IP ottenuto non appartiene alla propria LAN, e invia il pacchetto con la richiesta al proprio gateway verso Internet. Quando la richiesta arriverà al server, questi manderà la pagina web all'indirizzo che trova nel pacchetto, che è privato; i router che la richiesta ha attraversato non instradano i pacchetti (è il primo router che attraversano che li scarta) e la pagina non arriverà a destinazione.

Risoluzione dei problemi generici

Proxy server

Per evitare una situazione quale quella descritta è comune l'uso di un proxy HTTP, vale a dire un processo che gira su una macchina che ha visibilità di entrambe le reti (possiede dunque un indirizzo pubblico e uno privato). Il browser sull'host privato presenta tutte le proprie richieste a un processo (il proxy) che si mette in ascolto su una porta ben nota, tiene traccia della richiesta dell'host A, e la fa in sua vece, fornendo al server il proprio indirizzo pubblico: la pagina richiesta arriva senza problemi al proxy, che la "gira" all'host richiedente.

Dispositivi NAT

Un'altra soluzione è l'uso del cosiddetto NAT, ovvero Network Address Translation. Un dispositivo NAT "traduce" un indirizzo IP usato in una rete in un differente indirizzo IP noto in un altra.

Chiamiamo una delle due rete "interna", ad esempio una LAN, e l'altra "esterna", ad esempio Internet.

Gli utenti della rete interna possono vedere quelli sulla rete esterna, ma non è vero il viceversa, dato che gli utenti interni comunicano esclusivamente attraverso il dispositivo di traduzione.

Ogni richiesta, entrante o uscente, deve passare attraverso un processo di traduzione, che è dinamico e trasparente alle applicazioni.

Tipicamente i dispositivi NAT permettono il passaggio di tutto il traffico uscente; l'informazione di indirizzamento di un pacchetto viene immagazzinata con un valore di timeout. I pacchetti che viaggiano in direzione opposta e che hanno indirizzi corrispondenti vengono ammessi sulla rete interna. Questa tecnica di creazione di regole dinamiche si chiama "pinholing" (letteralmente bucherellare).

Un dispositivo NAT mappa gli indirizzi di rete interna su uno o più indirizzi IP di rete esterna, e viceversa.

Ci sono due tipi di dispositivi NAT:

Dispositivi di traduzione di indirizzi di rete (NAT), che permettono a un'organizzazione di usare un pool di indirizzi privati per la comunicazione su una rete interna, e di condividere un piccolo insieme di indirizzi pubblici per comunicare con le reti esterne
Dispositivi di traduzione di indirizzo di porta (NAPT o PAT), che hanno un blocco di indirizzi privati e uno o più indirizzi pubblici; la differenziazione viene fatta sul numero di porta

Figura 2.3 Dispositivo NAT: esempio

Figura 2.4 Dispositivo PAT: esempio

2.2 Indirizzamento H.323

Network Address

Ogni entità H.323 ha almeno un indirizzo di rete, che identifica univocamente l'entità sulla rete. Alcune entità possono condividere un indirizzo di rete (ad esempio un terminale e un Media Controller colocati). Questo indirizzo è specifico della rete in cui si trova l'endpoint; tipi di reti differenti possono avere differenti formati di indirizzo di rete.

TSAPIdentifier

L'acronimo sta per Transport Service Access Identifier. Per ogni indirizzo di rete un'entità può avere diversi TSAPIdentifier: questi ultimi permettono il multiplexing di vari canali che condividono lo stesso indirizzo di rete.

Ogni endpoint ha uno TSAPIdentifier "ben noto" : quello del canale di segnalazione di chiamata.

I gatekeepers hanno anch'essi uno TSAPIdentifier "ben noto" , quello del canale RAS, e un indirizzo multicast, anch'esso ben noto, il Discovery Multicast Address.

Gli endpoint usano degli TSAPIdentifier dinamici per il canale di controllo H.245, per i canali audio, video e dati. I gatekeepers usano uno TSAPIdentifier dinamico per i canali di segnalazione di chiamata.

In parole povere, uno TSAPIdentifier non è altro che un numero di porta, che identifica in modo univoco la connessione TCP oppure UDP che l'applicazione H.323 sta usando.

Alias address

Ad ogni endpoint possono essere associati uno o più indirizzi alias: questi forniscono un metodo alternativo di indirizzamento, e includono indirizzi del tipo dialedDigits , PartyNumber (inclusi numeri di telefono privati o numeri E.164 pubblici), nomi H.323 (stringhe alfanumeriche che rappresentano nomi, indirizzi e-mail, etc.) e qualsiasi altro tipo definito nella Raccomandazione H.225.0.

Gli indirizzi alias saranno unici all'interno di una zona, e gatekeepers, Media Controllers e Media Processors non hanno indirizzi alias.

Per comodità di trattazione, useremo genericamente il termine "indirizzo", intendendo che, nei casi esaminati, esso sarà formato da due parti: una è l'indirizzo di rete, vale a dire l'indirizzo IP della macchina ove gira l'applicazione H.323, e che identifica univocamente tale macchina nell'ambiente di rete ove si trova; l'altra sarà un numero di porta, TCP oppure UDP, che identifica univocamente il protocollo (RAS, H.225, H.245, RTCP RTP) usato per lo scambio di dati su quella connessione.

TIPI DI INDIRIZZO IN UNA CHIAMATA H.323

Indirizzo	IP	Porta	Vincoli sulla porta
RAS	Esempio:151.100.10.136	1719 (UDP)	Fissa
H.225.0	Esempio:151.100.10.136	1720 (TCP)	Fissa
H.245	Esempio:151.100.10.136	Esempio: 23765 (TCP)	Dinamica, > 1024
RTCP	Esempio:151.100.10.136	Esempio: 5001 (UDP)	Dinamica, > 1024 , pari al numero di porta RTP più 1
RTP	Esempio:151.100.10.136	Esempio: 5000 (UDP)	Dinamica, > 1024

2.2.1 Chiamate H.323 : tutti i casi

In tutti i casi esaminati nel paragrafo gli endpoint e l'eventuale gatekeeper sono sulla stessa rete.

Chiamata diretta tra due endpoint senza registrazione a un gatekeeper.

Questo tipo di situazione prevede che un endpoint conosca almeno l'indirizzo H.225.0 dell'endpoint remoto col quale vuole comunicare. Per comodità chiamiamo i due endpoint Alice e Bob. Distinguiamo i vari passi con i quali si instaura la chiamata:

Alice crea una connessione TCP verso la porta 1720 di Bob; questa è una porta cosiddetta "ben nota" per l'H.323, ove i client si mettono in ascolto. Attraverso questa connessione i due endpoint si scambiano un indirizzo TCP, e cioè un numero di porta, dinamico (varia chiamata per chiamata, casualmente) e maggiore di 1024, da usare per la connessione H.245
Viene effettuata la connessione sulle porte negoziate attraverso il flusso H.225.0. Attraverso lo scambio dei messaggi H.245 vengono determinate le capacità degli endpoint, i codec audio e video, e viene stabilito chi dei due è Master e chi Slave. A questo punto Alice manda il messaggio Open Logical Channel, che contiene il suo indirizzo RTCP. Bob risponde con il messaggio OpenLogical Channel Acknowledge, che contiene il suo indirizzo RTCP e quello RTP. Gli indirizzi in questione sono semplicemente dei numeri di porte UDP: i numeri delle porte RTCP e RTP sono consecutivi, con RTP numero pari e RTCP uguale al numero dispari immediatamente superiore. Dato che i canali sono unidirezionali, la procedura viene ripetuta per entrambe le direzioni, e per ogni tipo di media che si vuole trasmettere (c'è uno scambio OLC-OLCACK per il video, uno per l'audio, etc.)
A questo punto sia Alice sia Bob conoscono le porte UDP alle quali mandare i pacchetti, e i flussi audio e video possono partire. Nella figura 2.5 abbiamo lo schema della chiamata.

Figura 2.5 Chiamata tra due endpoint sulla stessa rete

Chiamata tra due endpoint registrati allo stesso gatekeeper

In questo tipo di chiamata è sufficiente che gli endpoint conoscano l'alias H.323 dell'endpoint che vogliono contattare.

Alice manda un messaggio di Admission Request al gatekeeper sulla porta 1719: all'interno del messaggio è specificato l'alias H.323 del destinatario della chiamata. Il gatekeeper risolve l'indirizzo del chiamato, e restituisce, nel messaggio Admission Confirm, un indirizzo di segnalazione di chiamata H.225.0: nel caso presente (modalità direct) tale indirizzo è quello dell'endpoint chiamato (figura 2.6)
Alice adesso conosce l'indirizzo al quale mandare il setup a Bob: crea una connessione sulla porta ben nota 1720 e ripete la procedura vista nel caso precedente, negoziando la porta TCP sulla quale creare la connessione H.245
Inizia lo scambio di messaggi H.245 sulla connessione TCP creata: Terminal Capability Set, Master Slave Determination, informazioni sui canali logici.
Entrambi gli endpoint conoscono le porte UDP sulle quali mandare i flussi audio e video, e inizia la chiamata vera e propria. (vedi figura 2.6)

Figura 2.6 Modalità H.225 direct

Chiamata tra due endpoint registrati allo stesso gatekeeper; modalità H.225 routed

Alice manda un messaggio di Admission Request al gatekeeper, sulla porta 1719: all'interno del messaggio è specificato l'alias H.323 del destinatario della chiamata. Il gatekeeper risolve l'indirizzo del chiamato, e restituisce, nel messaggio Admission Confirm, il proprio indirizzo di segnalazione di chiamata
Alice manda il setup al gatekeeper anziché a Bob: quest'ultimo lo inoltra a Bob, il quale riceve come indirizzo di segnalazione di chiamata l'indirizzo del gatekeeper. Da questo punto in poi tutta la segnalazione H.225 passa attraverso il gatekeeper: il contatto diretto tra gli endpoint si limita ai messaggi H.245 e ai flussi RTCP e RTP.
Scambio di messaggi H.245 (direttamente tra gli endpoint sulla connessione TCP negoziata nella fase precedente)
Inizio della chiamata vera e propria.

Chiamata tra due endpoint registrati allo stesso gatekeeper, modalità H.245 routed

Alice manda un messaggio di Admission Request al gatekeeper, sulla porta 1719: all'interno del messaggio è specificato l'alias H.323 del destinatario della chiamata. Il gatekeeper risolve l'indirizzo del chiamato, e restituisce, nel messaggio Admission Confirm, il proprio indirizzo di segnalazione di chiamata
Alice manda il setup al gatekeeper, che lo inoltra a Bob; invece dell'indirizzo H.245 di Alice, il gatekeeper inserisce nel setup inoltrato a Bob il proprio indirizzo H.245.
Bob invia al gatekeeper il messaggio Connect, che contiene il proprio indirizzo H.245: da questo punto in poi tutto il controllo di chiamata passa per il gatekeeper, e gli unici flussi informativi che vengono scambiati direttamente tra i due endpoint sono quelli audio e video.

In questi esempi si è visto come le applicazioni basino la loro capacità di interagire sulla conoscenza dei reciproci indirizzi: nelle tabelle seguenti riassumiamo la situazione, relativamente a un endpoint

Chiamata diretta tra endpoint senza gatekeeper
Indirizzo	Provenienza
RAS: nessuno	Non necessario
H.225.0: endpoint remoto	Noto a priori
H.245: endpoint remoto	Negoziato in H.225
RTCP: endpoint remoto	Negoziato in H.245
RTP: endpoint remoto	Negoziato in H.245

Chiamata tra endpoint registrati allo stesso gatekeeper (modalità direct)
Indirizzo	Provenienza
RAS: gatekeeper	Noto a priori
H.225.0: endpoint remoto	Fornito dal gatekeeper
H.245: endpoint remoto	Negoziato in H.225
RTCP: endpoint remoto	Negoziato in H.245
RTP: endpoint remoto	Negoziato in H.245

Chiamata tra endpoint registrati allo stesso gatekeeper (modalità H.225 routed)
Indirizzo	Provenienza
RAS: gatekeeper	Noto a priori
H.225.0: gatekeeper	Fornito dal gatekeeper
H.245: endpoint remoto	Negoziato in H.225
RTCP: endpoint remoto	Negoziato in H.245
RTP: endpoint remoto	Negoziato in H.245

Chiamata tra endpoint registrati allo stesso gatekeeper (modalità H.225 e H.245 routed)
Indirizzo	Provenienza
RAS: gatekeeper	Noto a priori
H.225.0: gatekeeper	Fornito dal gatekeeper
H.245: gatekeeper	Fornito dal gatekeeper
RTCP: endpoint remoto	Negoziato in H.245
RTP: endpoint remoto	Negoziato in H.245

Il problema degli indirizzi privati nell'H.323

Chiamata diretta tra endpoint non registrati a un gatekeeper

Lo scenario è quello, estremamente semplice, della chiamata diretta vista nel paragrafo precedente. Supponiamo che Alice, host ad indirizzo privato, conosca l'indirizzo H.225 di Bob, host ad indirizzo pubblico.

Alice manda il messaggio di setup a Bob. Il pacchetto contenente il messaggio è destinato a un host che non si trova sulla stessa LAN di Alice e viene inviato al gateway verso la rete Internet, e instradato verso Bob.
Bob riceve il pacchetto, e all'interno trova l'indirizzo al quale inviare il messaggio di risposta, vale a dire quello di connect. L'indirizzo è quello H.225 di Alice, composto da un indirizzo di rete privata e da un numero di porta TCP. Il pacchetto viene inviato da Bob al proprio router di default, il quale non instrada i pacchetti diretti all'indirizzo privato. La chiamata non può avere luogo (vedi figura 2.7)

Figura 2.7 Chiamata diretta fallita

Nel caso in cui la chiamata iniziasse da Bob, fallirebbe ancora prima; infatti nel pacchetto IP che contiene il messaggio di setup il campo di destinazione contiene un indirizzo privato: il primo router incontrato scarterebbe il pacchetto, che non arriva ad Alice.

Raramente, però, si verifica il caso di una chiamata diretta: più comune è il caso in cui gli utenti che vogliono interagire sono registrati a un gatekeeper.

Chiamata tra due endpoint sulla stessa rete registrati allo stesso gatekeeper: modalità H.225 direct

Innanzitutto anticipiamo che la macchina sulla quale risiede il gatekeeper deve avere visibilità di entrambe le reti, per permettere la registrazione agli endpoint su rete pubblica e a quelli su rete privata. Questo significa che il gatekeeper si deve trovare su un router di confine tra le due reti, e che possa accettare registrazioni da entrambe.

Vediamo come si evolve la chiamata:

Alice manda un messaggio di Admission Request al gatekeeper sulla porta 1719: all'interno del messaggio è specificato l'alias H.323 del destinatario della chiamata. Il gatekeeper risolve l'indirizzo del chiamato, e restituisce, nel messaggio Admission Confirm, l'indirizzo di Bob.
Alice manda il messaggio di Setup, ma il pacchetto contenente tale messaggio ha nel campo destinazione un indirizzo privato, e viene scartato dal primo router che incontra. Chiamata fallita!

Senza esaminare nel dettaglio tutti i casi possibili, diremo che nel caso H.225 routed la segnalazione è inoltrata dal gatekeeper, e quindi i messaggi di Setup, Alerting e Connect arrivano a destinazione. In tali messaggi viene specificato un indirizzo H.245, formato da un numero di porta e da un indirizzo di rete privato, il che provoca il fallimento della chiamata per i motivi ampiamente specificati.

Nel caso H.225 e H.245 routed, anche il controllo di chiamata passa per il gatekeeper, e la chiamata viene instaurata; i flussi RTP e RTCP, d'altro canto, sono trasportati da pacchetti che hanno nella loro intestazione un indirizzo di destinazione privato, e non vengono instradati. La chiamata non è fallita, ma non è neanche molto utile, dato che, nel migliore dei casi, solo uno dei due endpoint riceverà l'audio inviato dall'altro.

Perchè serve un ALG

Abbiamo visto che, nel caso generale, il problema degli indirizzi privati viene risolto principalmente con due tipi di dispositivo: proxy server e dispositivi NAT.

Per una LAN "privata" il fatto che i suoi host non siano visibili dall'esterno, come accade usando i dispositivi menzionati, è un valore aggiunto dal punto di vista della sicurezza, tanto che tali dispositivi si trovano spesso accoppiati con un firewall. Un firewall è una barriera posta tra due reti, in genere una LAN privata e Internet, usata per evitare intrusioni indesiderate sulla rete privata.

I due tipi principali di firewall sono i Packet Filters e gli Application Level Gateway:

Packet Filter -I packet filters (filtri di pacchetti, letteralmente) bloccano il traffico indesiderato. Il metodo di filtraggio è basato sugli indirizzi IP e/o sui numeri di porta. Questo dispositivo esamina l'informazione contenuta nell'header di ogni pacchetto, e impone delle restrizioni (decide se inoltrare o meno il pacchetto) in base a una tabella di regole di filtraggio. Questo tipo di firewall usa tipicamente regole statiche per permettere ai dati desiderati di passare. Ci sono due tipi di regole statiche: ben note e configurabili. Un esempio di regola ben nota è la porta TCP 443 usata per il protocollo HTTPS. Questo indirizzo deve potere essere attraversato in ogni firewall, dato che i firewalls non sono capaci di decrittare i dati trasmessi su questa connessione "sicurizzata". Le regole configurabili consistono tipicamente di indirizzi sorgente e destinazione per i quali è ammesso spedire e ricevere dati attraverso il firewall. Si ha un range di indirizzi IP, numeri di porte TCP o UDP, e degli identificatori di protocollo.

Application Level Gateway - Gli ALG (gateway al livello di strato di applicazione) fungono da collegamento tra due reti; sono delle entità capaci di "guardare dentro" i messaggi di protocollo e di permettere di passare solo a quei messaggi conformi a certe politiche predefinite. A volte ci si riferisce erroneamente agli ALG come a dei proxy. C'è una differenza: gli ALG sono trasparenti alle entità che scambiano flussi multimediali, mentre i proxies non lo sono.

Sia firewall che NAT router hanno bisogno di sapere, per funzionare in maniera corretta , gli indirizzi IP e i numeri di porta relativi ai dati entranti o uscenti.

Abbiamo due alternative:

"Aprire" tutte le porte del firewall >1024, così da essere sicuri di far passare i messaggio H.245 e i flussi audio-video. Tale soluzione è impraticabile per motivi di sicurezza (perché allora mettere un firewall?)
Dato che H.323 inserisce gli indirizzi IP e le porte all'interno di messaggi di protocollo, fare in modo che il firewall o NAT che si trova al confine della rete privata abbia conoscenza del protocollo, così da poter leggere e, se necessario alterare, gli indirizzi e i numeri di porta: ci occorre un ALG.

Soluzioni già realizzate

Dato che il problema esposto è molto diffuso, altre soluzioni sono state realizzate. Accenniamo brevemente a tre di queste, descrivendone grossolanamente il funzionamento.

Opengatekeeper-Proxy

Soluzione realizzata da Marco Polci dell'università di Trieste, è un'estensione del progetto open-source opengatekeeper. Il punto di partenza è un gatekeeper, al quale sono state aggiunte varie funzionalità. Il funzionamento consiste nello scrivere in un buffer di ingresso i pacchetti che contengono i dati multimediali provenienti da uno dei due host, e scriverli in un buffer di uscita dal quale vengono "pescati" dalla parte di codice che li spedisce all'altro host. (Il tutto viene ripetuto nell'altra direzione).

Tale soluzione non è trasparente agli utenti, che devono essere informati della presenza del proxy: a un terminale H.323 deve essere specificato cioè l'indirizzo al quale mandare i pacchetti RTCP/RTP. Lungi dall'essere un grosso disturbo per l'utente finale, questo può creare problemi in caso di malfunzionamento del proxy: non si può cambiare dinamicamente la direzione dei pacchetti contenenti i media. Se si volesse offrire una tolleranza ai guasti del sistema, sarebbe invece necessario poter cambiare la direzione del flusso RTP in maniera trasparente al terminale.

Modulo Coritel

Soluzione realizzata dallo studente Iurilli dell'Università La Sapienza di Roma quale tesi di laurea in Ingegneria, è un modulo del kernel versione 2.2.12 di Linux (contenuto in Linux Red Hat 6.2 , per esempio) per il NAT routing, che permette il passaggio delle connessioni H.323. Questo modulo evita il problema di dover decodificare i messaggi di protocollo; vengono analizzati i pacchetti contenenti i messaggi dopo la codifica ASN.1, e individuate delle maschere di bit che caratterizzano tali messaggi.

Il router fa un confronto bit a bit dell'intestazione dei pacchetti con tali maschere, e se ottiene un risultato positivo permette il passaggio ai pacchetti, dopo aver sostituito nella loro intestazione un'altra maschera di bit corrispondente a un indirizzo IP opportuno.

Tale soluzione è, a mio avviso, migliore di quella precedente, dato che non ha il problema di leggere e scrivere i pacchetti nei buffer, ma ne esamina semplicemente l'intestazione, riducendo di molto il carico di lavoro della macchina.

Il funzionamento è però limitato alla sola versione citata del kernel di Linux, e ha alcuni seri limiti: non prevede l'uso di un gatekeeper ( almeno nella sua prima realizzazione) e presenta la possibilità di mancata connessine tra due applicativi nel caso di più chiamate contemporanee.

RSIP Server per Linux

(http://openresources.info.ucl.ac.be/rsip/)

Soluzione che per certi versi è simile a quella da me realizzata, ma poco pratica in certi casi. Senza scendere nei particolari, questo server ha a disposizione un certo numero di indirizzi IP pubblici, e quando un host su rete privata vuole fare una chiamata H.323 viene allocato uno di questi indirizzi; all'endpoint su rete pubblica viene fornito come indirizzo dell'interlocutore l'indirizzo pubblico, e si usa il packet filter IPTables per fare NAT e far passare i pacchetti sulla rete privata.

Il funzionamento è assimilabile a quello di un PBX con molti interni e poche linee in uscita nella telefonia tradizionale.

Il grosso problema è che per fare 100 chiamate contemporanee ci vogliono 100 indirizzi IP pubblici da allocare in aggiunta a quelli che usa normalmente la rete per dati, e se si ha tutta quella disponibilità di IP pubblici li si usa direttamente, senza fare ricorso a quelli privati, e risolvendo il problema dela sicurezza con un firewall.

Page hosted at

Last Update ven gen 31 18:03:32 CET 2003