In questo capitolo mostriamo dove si dovrebbe intervenire per risolvere il problema presentato, e spieghiamo la scelta dell'ambiente di partenza, costituito da un Gatekeeper e da un Media Controller. Dopo un approfondimento sul protocollo H.245 presentiamo gli strumenti usati per giungere alla soluzione.
3.1 Cosa deve fare il proxy
Nel capitolo precedente si è visto che un proxy H.323 deve essere un ALG, entità che ha la possibilità di intervenire sui messaggi di protocollo e, se necessario, cambiarne il contenuto. Vediamo ora dove deve intervenire questa entità nel flusso di una chiamata.
Tabella 3.1 Messaggi H.225 sui quali il proxy deve intervenire
|
PDU |
Scenario |
Azioni principali |
|
Setup |
Richiesta per l'instaurazione di una nuova chiamata; arriva sul canale di segnalazione (porta ben nota) |
|
|
Connect |
Restituito dal chiamato al chiamante |
|
|
Release complete |
Può essere spedito da entrambi |
|
|
Alerting |
Spedito dal chiamato |
Inoltrare con un corretto Call Reference Value |
|
Tutte le altre PDU |
Inoltrare con un corretto Call Reference Value |
Tabella 3.2 Messaggi H.245 sui quali il proxy deve intervenire
|
PDU |
Scenario |
Azioni principali |
|
Open Logical Channel |
Spedito da chi vuole aprire un canale |
|
|
Open Logical Channel Ack |
Il ricevente accetta la richiesta di apertura del canale |
|
|
Open Logical Channel Reject |
Il ricevente rifiuta l'apertura di un canale |
|
|
Close Logical Channel |
Spedito da chi vuole chiudere un canale |
|
|
End Session |
Una delle due parti vuole chiudere tutti i canali e terminare la chiamata |
|
|
Tutte le altre PDU |
Inoltrare la PDU |
Sostanzialmente i livelli ai quali si deve intervenire sono due: il primo è la gestione dei protocolli H.323 e H.245, e il secondo, a più basso livello, è il passaggio fisico dei pacchetti UDP che trasportano i media. La figura 3.1 illustra il concetto.
Figura 3.1 Decomposizione funzionale del proxy H.323
3.2 Gatekeeper e Media Controller
Abbiamo già parlato di questi due componenti nel primo capitolo, descrivendone in dettaglio le funzioni; richiamiamo brevemente quelle di interesse.
Funzionalità del gatekeeper
|
Denominazione |
Significato |
Obbligatoria/opzionale |
|
Address Resolution |
Traduzione da indirizzi alias in indirizzi IP |
Obbligatoria |
|
Admission Control |
Controllo di accesso al servizio |
Obbligatoria |
|
Routing H.225 |
Inoltro della segnalazione di chiamata |
Opzionale |
|
Routing H.245 |
Inoltro del controllo di chiamata |
Opzionale |
Funzionalità del Media Controller
Gestione del flusso H.245 nel caso di conferenze a più di due partecipanti: gli endpoint non scambiano i messaggi di controllo di chiamata direttamente, ma li inviano all'MC, il quale li smista ai vari terminali che partecipano alla conferenza, dopo averli processati e, eventualmente, modificati. Un esempio: tre terminali vogliono instaurare una conferenza multipunto. Il terminale A può trasmettere audio secondo il codec G.711, mentre gli altri due hanno nel loro capability set ( un elenco associato a ogni terminale che comprende i codec che il terminale è in grado di decodificare e le funzionalità supportate) tutti i codec: il Media Controller invierà a tutti e tre i terminali un messaggio in cui stabilisce come codec il G.711
L'idea di base
Realizzare il proxy H.323 come un modulo di un gatekeeper: facendo lavorare quest'ultimo in modalità H.225 e H.245 routed, ci si può preoccupare della sola parte relativa al passaggio da una rete all'altra dei pacchetti che trasportano i flussi multimediali (vedi figura 3.2).
Figura 3.2 Gatekeeper e smistatore di pacchetti
Questo scenario richiede al gatekeeper e alla macchina sulla quale risiede dei requisiti ben precisi:
Il primo requisito non è affatto difficile da realizzare: basta montare due schede di rete su un PC.
Il problema nasce sugli altri due: i gatekeeper esistenti si "legano" a una sola interfaccia di rete, rilevandone l'indirizzo IP e immagazzinando come proprio indirizzo H.225 , da usare nelle procedure di chiamata viste, la combinazione indirizzo IP+porta ben nota TCP 1719.
Questo crea un ulteriore problema sul tipo di endpoint da usare. Supponiamo che la situazione sia quella in figura.
Figura 3.3 Gatekeeper a cavallo tra Internet e una rete privata
Il gatekeeper gira su una macchina che ha due interfacce di rete: le due reti sulle quali si affaccia hanno piani di indirizzamento differenti: una è una sottorete collegata a Internet, con indirizzi pubblici, e l'altra una sottorete di classe C di indirizzi privati 10.244.116.x. Il processo gatekeeper si "lega" all'interfaccia pubblica, per accettare registrazioni da Internet.
Gli endpoint sulla rete privata, in fase di registrazione, mandano una Gatekeeper Request all'indirizzo multicast ben noto, e ottengono dal gatekeeper un indirizzo IP che non appartiene alla loro sottorete; non tutti gli endpoint , a questo punto, sono capaci di completare ugualmente la registrazione (ad esempio Microsoft Netmeeting ne è capace, mentre Gnomemeeting no).
Analogamente, non tutti i gatekeeper supportano la registrazione da parte di endpoint con indirizzi IP appartenenti a una sottorete differente da quella cui appartiene il gatekeeper.
Si è scelto di usare un gatekeeper commerciale, funzionante su sistema operativo Linux Red Hat 7.1 ( Kernel 2.4), che può registrare endpoint indipendentemente dal loro indirizzo, e che è capace di inoltrare la segnalazione di chiamata a cavallo tra due reti.
In un primo test si è visto che due endpoint che avevano ultimato correttamente la procedura di registrazione riuscivano a raggiungersi, facendo "squillare il telefono" l'uno dell'altro. Questo indica che veniva completato lo scambio di messaggi in figura: l'endpoint Alice manda un'ARQ al gatekeeper GK, il quale restituisce nell'ACF il proprio indirizzo di segnalazione H.225. Alice manda il Setup a tale indirizzo, e GK "passa" tale messaggio sull'altra rete. A sua volta Bob compie la procedura ARQ-ACF, e manda il messaggio di Connect a GK, che, di nuovo, lo passa sull'altra rete (vedi figura 3.4).
Figura 3.4 H.225 routing
Una volta confermata la possibilità di routing H.225 tra due reti, rimaneva da vedere se il gatekeeper aveva la capacità di fare routing anche per il controllo H.245. Non sono stati fatti test in questo senso, per il motivo che andiamo a spiegare.
Il gatekeeper usato viene messo in commercio insieme a un Media Controller, che è un vero e proprio proxy H.245. Tale software può girare sulla stessa macchina del gatekeeper o anche su un'altra; una volta configurato il gatekeeper per riconoscere la presenza dell' MC, tutti i messaggi H.245 vengono gestiti da quest'ultimo.
Il software che realizza l'MC è fornito nella forma di una applicazione di esempio dal funzionamento elementare, e di un set di API (Application Program Interface), cioè di funzioni compatibili con lo stack H.323 realizzato dal fornitore del software. Per ogni messaggio H.245 ricevuto, l'MC immagazzina determinati parametri, cui le API fornite permettono un accesso parziale.
Scelta progettuale definitiva
La scelta progettuale operata è stata di:
Per quanto riguarda il passaggio dei pacchetti da una rete all'altra lo strumento usato è IPTables, il packet filter del sistema operativo Linux. Tale strumento viene di solito usato come firewall, e quindi permette un controllo "porta per porta" molto efficace. Questa funzionalità ha dato al software realizzato un valore aggiunto in termini di sicurezza. Di IPTables parleremo in un paragrafo successivo. Approfondiremo ora il funzionamento dei protocolli H.245 e RTCP.
3.3 Il protocollo H.245
La Raccomandazione H.245 specifica la sintassi e la semantica dei messaggi informativi scambiati dai terminali, come pure le procedure che essi devono usare per negoziazione di tipo "in-band" all'inizio della comunicazione o durante la stessa.
Questa raccomandazione descrive un certo numero di servizi, alcuni dei quali usufruibili da tutti i terminali, e altri solo da un sottoinsieme di questi.
Vengono definite delle procedure per permettere lo scambio di capacità dati e audiovisuali; per richiedere la trasmissione di una particolare forma di audio e video (codec); per gestire i canali logici usati per il trasporto delle informazioni audio, video e dati; per stabilire quale dei due terminali sia master e quale slave per scopi di gestione dei canali logici; per trasportare vari segnali di controllo e indicazioni; per controllare il bit rate di ciascun canale logico e di tutto il multiplex; per misurare il round trip delay tra un terminale e l'altro, etc.
La sintassi dei messaggi viene definita mediante la notazione ASN.1, e la semantica definisce il significato dei messaggi, fornendo inoltre delle restrizioni alla sintassi dell'ASN.1.
Il protocollo H.245 è stato creato per essere indipendente dal meccanismo di trasporto sottostante, ma s'intende che debba essere usato con uno strato di trasporto affidabile, che garantisca il corretto arrivo a destinazione dei dati.
Vediamo ora un elenco delle funzionalità per le quali vengono usati i messaggi H.245: verranno commentate solo quelle che risultano di interesse per il nostro caso specifico.
3.3.1 Tipi di messaggio H.245
I messaggi H.245 si dividono in quattro tipi fondamentali:
I messaggi di richiesta provocano l'esecuzione di un'azione da parte del terminale che li riceve, e richiedono una risposta (conferma) immediata.
I messaggi di risposta vengono inviati in seguito alla ricezione di un messaggio di richiesta. Quelli di comando impongono un'azione, ma non richiedono una risposta esplicita.
Infine, i messaggi di indicazione sono solo delle informazioni, che non richiedono né un'azione né una risposta esplicita.
Con riferimento alle funzionalità esaminate nel primo paragrafo del capitolo, diamo qualche esempio: nella tabella 3.3 sono illustrati tutti i possibili messaggi che due terminali possono scambiare nel corso della procedura di Master Slave Determination, mentre nella tabella 3.4 troviamo quelli relativi alle procedure di gestione dei canali logici.
Tabella 3.3 Messaggi della procedura MSD
|
Denominazione |
Tipo |
Significato |
|
Master Slave Determination |
Richiesta |
Chiede al ricevente di decidere chi sia il master |
|
Master Slave Determination Acknowledge |
Risposta |
Restituisce il risultato della decisione |
|
Master Slave Determination Reject |
Risposta |
Respinge la richiesta di Master Slave Determination |
|
Master Slave Determination Release |
Indicazione |
In caso di timeout evita che la richiesta rimanga appesa |
Tabella 3.4 Messaggi delle procedure relative all'apertura e chiusura di canali logici
|
Denominazione |
Tipo |
Significato |
|
Open Logical Channel |
Richiesta |
Richiede l'apertura di un canale logico unidirezionale con verso "uscente" dal mittente |
|
Open Logical Channel Acknowledge |
Risposta |
Accetta la richiesta di connessione mediante canale logico |
|
Open Logical Channel Reject |
Risposta |
Rifiuta la connessione |
|
Open Logical Channel Confirm |
Indicazione |
Nel caso di canali bidirezionali informa che il canale è aperto in entrambe le direzioni |
|
Close Logical Channel |
Richiesta |
Usato dal mittente per chiudere una connessione logica |
|
Close Logical Channel Acknowledge |
Risposta |
Conferma la chiusura della connessione |
|
Request Channel Close |
Richiesta |
Il mittente richiede all'endpoint remoto di chiudere un canale |
|
Request Channel Close Acknowledge |
Risposta |
L'endpoint remoto conferma che la connessione verrà chiusa |
|
Request Channel Close Reject |
Risposta |
L'endpoint remoto rifiuta di chiudere la connessione |
|
Request Channel Close Release |
Indicazione |
In caso di timeout evita che la richiesta rimanga appesa |
3.3.2 Codifica dei messaggi: ASN.1
L'acronimo significa Abstract Syntax Notation 1, ed è la denominazione di un linguaggio formale, astratto e non ambiguo, che si propone (nientemeno) di rappresentare ogni tipo di dato che può essere scambiato tra due macchine, a livello di strato di applicazione (e quindi indipendentemente da hardware, sistema operativo, etc.).
Esso permette di descrivere anche strutture dati complesse, incluse quelle con campi di lunghezza variabile o campi la cui presenza è opzionale.
La codifica di un messaggio nella notazione ASN.1 consiste sostanzialmente nella trasformazione dello stesso in una serie di bit, che verranno poi trasmessi al processo applicativo residente sulla macchina remota e riconvertiti in messaggio da utilizzare; l'effettiva codifica binaria utilizzata è specificata nelle raccomandazioni X.690 (basic encoding rules o BER) e 691 (packet encoding rules o PER).
BER permette la decodifica dei dati a sistemi che hanno conoscenza della notazione ASN.1 ma non della procedura specifica con la quale i dati sono stati formati; in altre parole il tipo di dato è codificato insieme al valore del dato stesso.
PER viene usata quando sia il trasmittente che il ricevente si aspettano che i dati abbiano una certa struttura nota ad entrambi; ha una ridondanza molto bassa ed è molto più efficiente.
I messaggi H.245 usano la codifica PER: per semplicità di decodifica viene usata la variante cosiddetta "allineata", che forza i messaggi ad utilizzare un numero intero di ottetti, e ad usare, se è il caso, bit di riempimento posti a zero (padding).
Si hanno tipi di dato semplici, quali BOOLEAN e INTEGER, e tipi aggregati, simili alle strutture e agli array dei linguaggi di programmazione più comuni, fino a tipi molto complessi come i seguenti:
H261VideoCapability ::= SEQUENCE
{
qcifMPI INTEGER (1..4) OPTIONAL, -- units 1/29.97 Hz
cifMPI INTEGER (1..4) OPTIONAL, -- units 1/29.97 Hz
temporalSpatialTradeOffCapability BOOLEAN,
...
}
VideoCapability ::= CHOICE
{
nonStandard NonStandardParameter,
h261VideoCapability H261VideoCapability,
h262VideoCapability H262VideoCapability,
h263VideoCapability H263VideoCapability,
is11172VideoCapability IS11172VideoCapability,
...
}
Figura 3.5 Notazione ASN.1
Real Time Protocol
L'acronimo RTP sta per Real-Time Protocol: esso è un protocollo che fornisce dei servizi di trasporto end-to-end per dati con caratteristiche real-time, quali audio e video interattivi.
Questi servizi includono l'identificazione del tipo di payload, la numerazione delle sequenze, il timestamping e il monitoraggio del trasporto.
Le applicazioni tipicamente usano RTP su UDP, per sfruttarne i servizi di multiplexing e di checksum; tuttavia RTP può essere usato con altri protocolli sottostanti di rete o di trasporto.
RTP supporta la trasmissione di dati verso destinazioni multiple usando la distribuzione multicast, se supportata dagli strati sottostanti.
RTP non fornisce alcun meccanismo per assicurare la consegna dei dati a tempo debito, né alcuna altra garanzia di qualità di servizio, ma fa affidamento sullo strato sottostante per queste funzionalità, qualora esso le supporti.
Non garantisce la consegna dei pacchetti nell'ordine di trasmissione, né assume che lo strato sottostante sia affidabile e consegni i pacchetti in sequenza.
I numeri di sequenza inclusi in RTP permettono a chi riceve di ricostruire la sequenza di trasmissione, ma i numeri di sequenza dei pacchetti possono anche essere usati per stabilire la corretta collocazione di un pacchetto, ad esempio nella decodifica video, senza per questo decodificare i pacchetti in sequenza.
La mancanza di una funzionalità di ritrasmissione in caso di perdita di un pacchetto (come ad esempio nel protocollo TCP) è dovuta alla natura real-time dei dati: se il pacchetto fa parte di una conversazione audio, deve arrivare entro un certo intervallo di tempo, legato alla dimensione del buffer in ricezione. Se giunge, per così dire, "fuori tempo massimo", viene scartato perché non più significativo; se non giunge affatto non ha senso chiederne la ritrasmissione all'applicazione remota.
Nonostante RTP sia stato creato per soddisfare i bisogni di partecipanti a conferenze multimediali, non è limitato a queste particolari applicazioni: può essere usato anche nell'immagazzinamento di dati di tipo continuo, nella simulazione interattiva distribuita e in applicazioni di misura e di controllo.
Real Time Control Protocol
Il protocollo RTP è affiancato da un altro protocollo, detto RTCP.
Il protocollo di controllo RTCP è bastato sulla trasmissione periodica di pacchetti di controllo da parte dei partecipanti a una conferenza, facendo uso dello stesso meccanismo di trasporto usato per i dati.
Il protocollo sottostante deve provvedere al multiplexing dei dati e dei pacchetti di controllo, per esempio usando differenti porte UDP.
RTCP ha quattro funzioni:
La funzione primaria è quella di fornire un feedback sulla qualità della distribuzione dei dati. Questa è una parte importante del ruolo dell'RTP come protocollo di trasporto, ed è correlata al controllo di flusso e di congestione. Questo feedback può essere usato direttamente da una codifica di tipo adattativo, e comunque è fondamentale per diagnosticare guasti nella distribuzione dei dati. Inoltre, nel caso di una conferenza multipunto, i partecipanti possono valutare se, in caso di problemi, questi siano globali o locali
RTCP trasporta un identificativo per ciascuna sorgente di flusso RTP, detta Canonical Name, che identifica ogni partecipante ad una conferenza, e permette, in caso di flussi correlati (ad esempio audio e video trasmessi da uno stesso endpoint) di sincronizzarli correttamente
Le prime due funzioni richiedono che tutti i partecipanti a una conferenza mandino pacchetti RTCP, e quindi, al crescere del numero dei partecipanti, la frequenza di invio viene diminuita, per evitare un forte aumento di traffico sulla rete
Una quarta funzione, opzionale, è quella di convogliare, nel caso di conferenze multicast, informazioni di sessione, per conferenze non a stretto controllo.
In una chiamata audio, dopo le varie contrattazioni, le applicazioni residenti su endpoint remoti "conoscono" una coppia di porte: una di queste è usata per i dati audio, l'altra per il controllo RTCP.
L'applicazione di audioconferenza usata da ciascun partecipante spedisce dati audio in piccoli spezzoni di 20 ms, per esempio; ogni spezzone viene preceduto da un header RTP, e a loro volta header RTP e dati audio vengono inseriti in un pacchetto UDP (vedi figura 3.6).
Figura 3.6 Pacchettizzazione dei dati audio
L'header RTP contiene un informazione temporale e un numero di sequenza che permette al ricevitore di ricostruire correttamente la sequenza di trasmissione. Il sequence number può essere usato dal ricevitore anche per valutare il numero di pacchetti persi durante la trasmissione.
Periodicamente, inoltre, l'applicazione audio spedisce un pacchetto RTCP chiamato Receiver Report, nel quale sono contenute delle statistiche di ricezione, che descrivono la qualità dei dati ricevuti, e l'identificativo del mittente.
Ripetiamo ancora una volta che i controlli sull'header RTP non vengono effettuati a livello di protocollo, ma, se hanno luogo, è l'applicazione di audioconferenza che li effettua.
3.4 Strumenti a disposizione
Dopo aver esposto il problema e presentato lo scenario di partenza, esaminiamo gli strumenti che abbiamo a disposizione.
3.4.1 Accesso ai messaggi H.245 mediante API
Il gatekeeper e il Media Controller sono due processi software distinti, che comunicano tra loro scambiandosi dei segnali. Nei rispettivi file di configurazione viene specificato l'indirizzo IP al quale l'uno deve "cercare" l'altro: una volta fatti partire i due processi aprono ciascuno una propria finestra di log, nella quale annunciano di essere a conoscenza delle reciproche esistenze.
Il gatekeeper funzionerà in modalità H.225 e H.245 routed; inoltrerà "personalmente" i messaggi H.225, mentre nella contrattazione H.225 darà come indirizzo H.245 quello del Media Controller, il quale si incaricherà dell'inoltro dei messaggi H.245.
Funzionamento del Media Controller
Le fasi nelle quali interviene l'MC nel corso di una chiamata sono:
Per i nostri scopi interveniamo solo nella terza fase. Per ogni conferenza in corso ci sarà uno scambio di messaggi H.245, relativi a tale fase. Il Media Controller tiene traccia dei canali logici, numerandoli, e segue l'evoluzione di ciascun canale con un diagramma di stato. L'MC considera "entranti" i messaggi che riceve e "uscenti" quelli che inoltra. Ad ogni evento (l'arrivo o l'inoltro di un messaggio) ci spostiamo in un diverso stato del diagramma.
Illustriamo il concetto riferendoci alla generica chiamata, per la quale mettiamo in evidenza i soli messaggi H.245 che ci interessano.
Figura 3. Funzionamento del Media Controller
Open Logical Channel: contiene indirizzo RTCP del mittente
Open Logical Channel Acknowledge; contiene indirizzo
RTCP e RTP del mittente
L'applicazione riceve i messaggi, ne legge il
contenuto, e ne riproduce una copia sui
parametri della quale può intervenire prima
dell'inoltro all'endpoint di destinazione
Lo scambio di messaggi illustrato in figura avviene per ogni canale di dati che si vuole aprire tra i due endpoint ( e quindi una volta per l'audio, una per il video, etc.), e per ciascuna direzione, se si tratta di canali unidirezionali (audio e video sono unidirezionali, mentre il canale dati T.120 è bidirezionale).
L'applicazione software "Media Controller" interpreta lo scambio di messaggi visto secondo i due diagrammi di stato in figura: gli eventi sono rappresentati con degli ovali, mentre gli stati con dei rettangoli.
Diagramma di stato per il canale aperto da Alice
Il Media Controller, ricevuto un messaggio, ne memorizza i parametri in una struttura dati apposita, dalla quale poi (è il processo che abbiamo chiamato duplicazione del messaggio) "ricostruisce" il messaggio uscente.
Le API fornite insieme all'MC permettono l'accesso a tale struttura dati, e offrono la possibilità di cambiare il valore di alcuni campi: ne verrà fuori un messaggio H.245 diverso da quello che è stato ricevuto, modificato secondo i nostri scopi.
3.4.2 Lo sniffer di pacchetti: Ethereal
Ethereal è un'applicazione open-source, attualmente inclusa in tutte le maggiori distribuzioni Linux, quali Red Hat, Mandrake, Suse, etc., ma disponibile anche per il sistema operativo Windows.
Ethereal è un analizzatore di rete (in gergo sniffer); collegato il PC sul quale gira lo sniffer a una LAN, si possono esaminare gli header dei pacchetti IP che circolano su tale LAN. Il programma è strutturato modularmente: per ogni protocollo esiste un modulo capace di eseguirne la decodifica, e di presentare "in chiaro" le informazioni rilevanti. Mano a mano che si succedono le versioni, lo sniffer aggiunge moduli, e acquista la capacità di "leggere dentro" pacchetti che trasportano informazioni relative ai protocolli più disparati.
Figura 2. Ethereal: esempio di cattura pacchetto.
Esiste una versione di Ethereal che ha un modulo relativo all'H.323, aggiunto da un programmatore della Philips; tale versione ( la 0.8.15, per la cronaca) offre la possibilità di decodificare tutti i protocolli coinvolti in una chiamata H.323, e di verificare i valori di tutti i parametri.
Va da sé che questo è lo strumento ideale per analizzare i pacchetti contenenti i messaggi, e controllare i risultati delle modifiche effettuate al codice di partenza.
Un packet filter è un software che "guarda" nell'header dei pacchetti, e in base a quello che vi legge ne decide il fato; può decidere di scartarli, come se non fossero mai esistiti, oppure di accettarli, oppure ancora di respingerli (li scartiamo ma avvertiamo chi ce li ha spediti), e altre cose ancora.
In Linux il packet filtering è inserito nel kernel, sotto forma di un modulo.
Dalle versioni del kernel 2.4.x tale modulo fa parte di un ambiente più ampio detto NetFilter. NetFilter è configurato in 3 "tabelle", ognuna delle quali è costituita da vari filtri. A sua volta ogni filtro contiene delle regole: una regola è una definizione del tipo "Se l'header del pacchetto ha queste caratteristiche allora fai questa cosa"; l'azione da compiere sul pacchetto si chiama "target".
Riassumiamo lo schema in una.tabella!.
|
Tabelle |
Catene presenti nella tabella |
Target validi nella tabella |
|
FILTER |
INPUT FORWARD OUTPUT |
ACCEPT DROP REJECT RETURN QUEUE STOLEN REPEAT |
|
NAT |
OUTPUT PREROUTING POSTROUTING |
DNAT SNAT MASQUERADE REDIRECT |
|
MANGLE |
OUTPUT PREROUTING |
MARK TOS |
Esempio: come i pacchetti attraversano la tabella FILTER
La tabella di filtro contiene altri tre filtri predefiniti, detti "catene del firewall", o semplicemente "catene".
Le tre catene vengono chiamate INPUT, FORWARD e OUTPUT, e sono rappresentate in figura dagli ovali omonimi.
Una catena consiste in una lista di regole: se il pacchetto non corrisponde alle caratteristiche cercate si passa alla regola successiva. Esaurita la lista di regole il kernel guarda qual è la "politica" predefinita della catena (ad esempio DENY, oppure ACCEPT), per decidere cosa fare del pacchetto. Il funzionamento si può riassumere nei seguenti punti:
IPTables ci dà la possibilità di agire a diversi livelli, dalla singola regola alla creazione di una nuova catena. Vediamo qualche esempio
Operazioni su una singola regola
Ogni regola specifica un insieme di condizioni che il pacchetto deve soddisfare, e un "target", ovvero le azioni da compiere sul pacchetto se questo soddisfa le condizioni elencate.
Ad esempio, per aggiungere una regola alla catena INPUT della tabella FILTER che scarti i pacchetti ICMP provenienti dall'host di indirizzo IP 10.244.116.50, il comando è:
>iptables A INPUT s 10.244.116.50 p icmp j DROP
e va interpretato nel modo seguente:
Specifiche di filtraggio
Operazioni su intere catene
La tabella di NAT
Questa è la tabella che ci interessa maggiormente, dato che ci offre la possibilità di cambiare l'indirizzo sorgente o destinazione di un pacchetto IP: è questa che useremo per far passare i pacchetti UDP che trasportano i dati real-time da una rete all'altra.
Distingueremo tra DNAT, e cioè Destination NAT, e SNAT, cioè Source NAT; il primo andrà a intervenire nel campo destination e il secondo nel campo source del pacchetto IP esaminato.
Le regole che aggiungeremo in questa tabella saranno aggiunte dal codice realizzato: vedremo i dettagli nel prossimo capitolo
