ZeroShell    Forum
   Feed Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth una interfaccia per il Captive Portal

      Cosa è?
      Screenshots
      Licenza
      Annunci
      Mailing List
      Forum
      English Forum
      Documentazione
      FAQ
      Hardware
      Download
      Update On-line
      Kerberos Tutorial  
      Note Legali
      Contattami


  Più in dettaglio:
      Hotspot Router
      Accounting
      Shibboleth SP
      Grafici e Prestazioni
      Net Balancer
      Router UMTS
      Proxy con Antivirus
      Filtri Web
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS e LDAP
      Certificati X.509
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional




QoS e Traffic Shaping in modalità Transparent Bridge

Lo scopo di questo documento è quello di descrivere la realizzazione di un bridge in grado di applicare regole di QoS (Quality of Service) sul traffico che lo attraversa. La scelta della modalità bridge è motivata dalla semplicità con cui questo componente può essere introdotto all'interno di una topologia di rete, senza doverne alterare i parametri che la caratterizzano quali la Subnet IP e il Default Gateway.
Così come rappresentato in Fig.1, aggiungeremo il QoS Bridge tra il router di collegamento a Internet e lo switch di livello 2 a cui sono connessi gli host della LAN. Si noti, che la semplicità della configurazione scelta, non influenza la generalità del procedimento che applicheremo, il quale potrà senz'altro essere applicato in topologie più complesse. Si tenga inoltre presente, che il procedimento resta ancora valido, anche se si configura ZeroShell per agire da Router di livello 3 invece che da Bridge. Vedremo infatti che le classi di QoS vengono attribuite direttamente alle interfacce di rete (Ethernet, VPN, PPPoE, Bond di VPN e Bridge) e non sono quindi influenzate dalla modalità di forwarding (routing o bridging) scelta.

QoS and Traffic Shaping in Bridge mode
Figura 1. QoS e Traffic Shaping in bridge mode.


Nella configurazione di esempio che seguirà, creeremo un certo numero di classi di traffico a cui assegneremo i classici parametri di QoS quali la Priorità di smistamento dei pacchetti, la Banda Minima Garantita in caso di rete congestionata e la Banda Massima non superabile neanche quando la rete non è congestionata. L'attribuzione di questi parametri alle diverse classi di qualità di servizio, così come la classificazione del traffico all'interno delle stesse, avverrà cercando di rispecchiare per quanto possibile un esempio concreto di utilità dell'applicazione di queste tecniche di traffic shaping.
Si farà ampio uso dei Filtri Layer 7, che con la tecnica del Deep Packet Inspection (DPI), che consiste nel guardare all'interno del contenuto dei pacchetti, permettono di classificare il traffico VoIP e peer-to-peer difficilmente classificabile con filtri sulle porte UDP e TCP del livello di trasporto. Più precisamente cercheremo di ottenere le seguenti funzionalità:
  • Classificare il traffico VoIP (Voice over IP) quale quello generato da connessioni SIP, H.323, Skype e MSN Messenger all'interno di una classe ad alta priorità e banda garantita assegnata. Così facendo si limita il tempo di latenza dei pacchetti in maniera da evitare disturbi nella riproduzione del video e della voce;
  • Limitare la banda massima disponibile per connessioni di tipo P2P (Peer to Peer) per file sharing che altrimenti tendono a saturare il link soprattutto in upstream;
  • Evitare che il traffico interattivo, come sessioni di SSH o telnet, possa subire fastidiosi ritardi nella risposta. Ciò si otterà assegnando tale traffico ad una classe ad alta priorità in modo da diminuirne la latenza;
  • Classificare il traffico bulk, cioè quello generato da trasferimenti ftp o mail via smtp, caratterizzato da flussi intensi ma che non necessitano di bassa latenza. In questo caso gli si assegnerà semplicemente una bassa priorità senza limitarne la banda.
Allo scopo di fissare le idee, nell'esempio che seguirà supporremo di avere un collegamento ad Internet asimmetrico di 4Mbit/s in downstream e di 2Mbit/s in upstream e di assegnare alle nostre classi di QoS i parametri riportati in Tabella 1


QoS ClassProtocolsPriorityGuaranteedMaximum
VOIPSIP, H.323, Skype, MSN MessengerHigh1Mbit/s 
P2PeMule, EDonkey, KaZaA, Gnutella, BitTorrent, Direct ConnectLow 256Kbit/s
SHELLssh, telnetHigh  
BULKftp, smtpLow  
DEFAULTUnclassifiedMedium  
Tab.1 Assegnazione dei parametri alle classi di QoS


Prima di iniziare a configurare il bridge Zeroshell per attuare la politica di QoS richiesta, è necessario chiarire da subito quanto segue:
  • Quando si applica una classe di QoS ad un'interfaccia di rete è importante tenere conto del fatto che si intende controllare il traffico uscente da quella interfaccia. Sul traffico entrante invece non si ha alcun controllo diretto. D'altra parte, l'unica cosa che si potrebbe fare sui pacchetti già arrivati su di un'interfaccia è di scartarli, anche se comunque essi hanno già consumato la banda in ingresso, nella speranza che il software che sta producendo tale traffico sull'altro peer, si accorga della perdita di pacchetti e riduca il flusso uscente per contrastare la perdita. Spesso questa situazione si verifica, cioè il software ha un feedback sulla connessione di rete che gli permette di modellare il traffico generato in base alla banda disponibile in quel momento. In particolare, se l'applicazione si basa sul livello di trasporto TCP (invece che UDP o altro), si ha la certezza che il traffico uscente sia regolato in base a quello realmente ricevuto, poiché lo stack TCP/IP implementato nei Kernel dei Sistemi Operativi, regola automaticamente la finestra TCP basandosi sui pacchetti di ACK ricevuti indietro correttamente. Ciò senza richiedere ulteriore impegno da parte del programmatore applicativo, che può in questa maniera tranquillamente prescindere dall'affidabiltà e dalla portata del link di rete con cui le sue applicazioni comunicano.
  • Dal punto precedente, sembrerebbe che Zeroshell non possa in alcuna maniera controllare il traffico in downstream, visto che applica le classi di QoS solo in uscita. In realtà ciò non è del tutto vero se si considera, con le dovute approssimazioni, quanto segue: in un router (o bridge) la somma dei flussi entranti e pari alla somma dei flussi uscenti (quasi come quando gli elettrotecnici dicono che la somma algebrica delle correnti entranti in un nodo è pari a zero). Ovviamente l'approssimazione è dovuta al fatto che anche un router (o bridge) ha i suoi processi locali di servizio che comunicano con l'esterno. Ma in generale si può ritenere tale traffico trascurabile rispetto a quello forwardato da un'interfaccia all'altra.
    Alla luce di quanto detto e con riferimento al nostro esempio illustrato in Fig.1, si deduce che se vogliamo controllare il traffico entrante da Internet nella LAN è necessario applicare le classi di QoS in uscita sull'interfaccia ETH00, mentre per controllare il traffico uscente dalla LAN verso Internet è necessario agire in uscita sull'interfaccia ETH01. Nell'esempio applicheremo le stesse classi di QoS con gli stessi parametri ad entrambe le interfacce, ma ovviamente è possibile impostare sulla stessa classe parametri di banda diversi in funzione dell'interfaccia a cui viene applicata la classe.
  • Questo documento è volutamente semplificato poiché si pone come obiettivo quello di descrivere l'implementazione di un sistema di traffic shaping mediante l'interfaccia web di Zeroshell. Tuttavia, le tecniche che sono alla base del QoS sono abbastanza complicate e dipendono molto dalla qdisc (Queueing Discipline) che si sceglie. Zeroshell realizza il QoS mediante la qdisc HTB (Hierachical Token Bucket) che è una tra le discipline di accodamento più flessibili e potenti. Con essa si può classificare e modellare il traffico collocando le classi in una struttura gerarchica a più livelli, ma la GUI di ZeroShell non permette di sfruttare tale caratteristica. Quanti vogliano sfruttare pienamente le potenzialità di questo strumento, necessitano di conoscere la sintassi del comando tc del pacchetto iproute2 nonché i dettagli di configurazione della qdisc HTB per poter eseguire la configurazione direttamente dalla shell.
La descrizione dell'implementazione del QoS transparent Bridge sarà suddivisa nelle sequenti sezioni allo scopo di semplificare la trattazione:

Rendere la configurazione permanente

Affinché la configurazione di ZeroShell diventi permanente e quindi sia ricaricata anche dopo il reboot del sistema è necessario creare ed attivare un database. Se si utilizza la versione Live CD è necessario che il sistema disponga di almeno un device di storage in lettura/scrittura collegato con interfaccia IDE, SATA, SCSI o USB. Se invece si utilizza la versione Compact Flash il database può essere memorizzato direttamente su di essa. Per la loro maggiore stabilità dovuta alla presenza del Journaling è consigliabile utilizzare un filesystem di tipo ext3 o ReiserFS. La formattazione e la creazione delle partizioni possono essere eseguite direttamente dalla GUI di ZeroShell, ma si raccomanda la massima attenzione in presenza di partizioni contenenti dati importanti.
Le operazioni da compiere per creare e attivare il database sono le seguenti:
  • Dalla sezione [Setup]->[Storage] selezionare la partizione in cui creare il database e premere il pulsante [Create DB];
  • Nella finestra che compare (vedi figura) inserire una descrizione per il database, digitare e confermare la password per l'utente admin, verificare che sulla ETH00 sia configurato l'indirizzo IP 192.168.0.75 e impostare il Default Gateway a 192.168.0.254.
  • Premere il pulsante [Create] per procedere alla creazione effettiva del database;
  • Attivare il database selezionandolo e premendo il pulsante [Activate]. Il sistema ripartirà con la nuova configurazione iniziale (vedi figura).
Terminata questa fase possiamo essere sicuri che qualsiasi configurazione successiva sarà memorizzata permanentemente.

Creare il bridge BRIDGE00(ETH00,ETH01)

In questa fase dobbiamo creare il BRIDGE00 e aggiungervi le interfacce di rete ETH00 e ETH01 in maniera che il traffico possa essere forwardato da un'interfaccia all'altra a livello 2. Tuttavia, si tenga presente, che quando un'interfaccia viene aggiunta ad un bridge, essa perde automaticamente gli eventuali indirizzi IP configurati e le VLAN. I problemi iniziano, come nel nostro caso, se si aggiunge ad un bridge l'interfaccia tramite cui siamo connessi con la web GUI di Zeroshell. È facile immaginare che non appena l'interfaccia perde il suo indirizzo IP non saremo più in grado di accedere al box ZeroShell tramite il browser. Per ovviare a ciò, esiste una funzione del menu della console di ZeroShell che crea un bridge, vi aggiunge un'interfaccia di rete a scelta dell'operatore e automaticamente migra tutta la configurazione (IP e VLAN) dall'interfaccia ethernet al bridge. Con questo metodo, che comunque presuppone la possibilità di accedere al sistema tramite console VGA o seriale RS232, si risolve il problema e la perdita di connettività è limitata al tempo necessario al bridge per passare in forwarding state (circa 15 secondi).
Vediamo di seguito i passi necessari per creare il BRIDGE00(ETH00,ETH01):
  • Accedere alla console di ZeroShell e premere il tasto "B" corrispondente alla funzione "Create a Bridge". Se non si è già autenticati sulla console viene richiesta la password dell'utente admin. Premere poi il tasto "y" per confermare di essere consapevoli di quello che si sta facendo. Scegliere poi l'interfaccia ETH00 premendo il tasto "1".
    Il bridge è stato così creato ed ha ereditato dalla ETH00 l'indirizzo IP 192.168.0.75. Dopo pochi secondi anche la connettività sarà ristabilita.
  • Adesso dobbiamo aggiungere anche la ETH01 al BRIDGE00. Per far ciò, dalla web GUI, nella sezione [Setup]->[Network] premere il pulsante [Configure] relativo all'interfaccia BRIDGE00 e spostare la ETH01 dalla lista "Available Interfaces" alla lista "Bridge Components" (vedi figura). Confermare e l'interfaccia ETH01 viene aggiunta anche essa al bridge (vedi figura)

Assegnare la banda globale alle interfacce del bridge

L'assegnazione della banda globale ad ognuna delle interfacce di rete coinvolte nel QoS è un'operazione fondamentale per il corretto controllo del traffico. Infatti, poiché il sistema non è in grado di stimare dinamicamente la disponibilità reale di banda, è necessario inserire una stima in base alla quale la banda verrà distribuita alle classi di traffico sottostanti. Vista la criticità di questi parametri potrà essere necessario variarli più volte prima di ottenere la qualità di servizio desiderata. Può convenire fare una stima per difetto ed aumentarla gradualmente, tenendo ben presente che se la banda realmente disponibile in un certo momento è inferiore alla nostra stima, il QoS in quel momento non darà i risultati attesi. Vediamo come procedere nel nostro caso:
  • Dalla sezione [QoS]->[Interface Manager] cliccare sul pulsante [Global Bandwidth] corrispondente all'interfaccia ETH00. Dalla finestra di dialogo che compare (vedi figura) impostare la banda massima e quella garantita a 4Mbit/s e confermare premendo [Save].
    Per capire perché abbiamo impostato questo valore di banda all'interfaccia ETH00, è necessario riguardare la figura Fig.1: si nota che il traffico in downstream (4Mbit/s) del collegamento a Internet entra dall'interfaccia ETH01 del bridge ed esce dalla ETH00. Poiché la qualità di servizio, come abbiamo già detto, si applica in uscita è evidente che per modellare il traffico in downstream è necessario agire sulla ETH00.
  • Cliccare questa volta sul pulsante [Global Bandwidth] relativo all'interfaccia ETH01. Poiché il collegamento a Internet è caratterizzato da una banda in upstream di 2Mbit/s impostare tale valore come banda massima e garantita.
  • Rendere effettive le impostazione premendo il pulsante [Activate last Changes].
Nota: nelle attuali versioni di Zeroshell, utilizzanti la qdisc HTB, l'impostazione della banda globale massima è quella che interviene nell'attribuzione della banda alle classi sottostanti. Il parametro di banda globale garantita invece ha valore puramente indicativo e non gioca alcun ruolo effettivo nella ripartizione di banda alle classi HTB sottostanti.

Creare le classi di QoS

Per creare le classi di qualità di servizio utilizzare il Class Manager (vedi figura) dalla sezione [QoS]->[Class Manager]. Si noti che inizialmente è presente soltanto la classe DEFAULT in cui confluisce tutto il traffico che non è classificato.
Procedere come segue:
  • Premere il pulsante [New] del "Class Manager" e inserire come nome della classe la stringa VOIP. Inserire una descrizione per la classe (per esempio "Voice over IP"), impostare la priorità High e assegnare una banda minima garantita di 1Mbit/s. Salvare poi la classe premendo il tasto [Save];
  • Con lo stesso procedimento creare la classe P2P con descrizione "File sharing peer to peer", impostare la priorità su Low e la banda massima a 256Kbit/s;
  • Creare la classe SHELL con descrizione "Interactive shell traffic" e alta priorità;
  • Creare la classe BULK con descrizione "Large data transfer" e bassa priorità.
La classe DEFAULT la lasciamo inalterata, cioè tutto il traffico non classificato avrà priorità media.

Aggiungere le classi di QoS alle interfacce del bridge

Create le classi di QoS all'interno del Class Manager è necessario assegnarle alle interfacce di rete di cui si vuole modellare il traffico uscente. Per far ciò procedere come segue:
  • Dalla sezione [QoS]->[Interface Manager] cliccare sul pulsante [Add Class] relativo all'interfaccia ETH00. Compare una finestra di dialogo (vedi figura) da cui, per ognuna delle classi VOIP, P2P, SHELL e BULK si deve premere il pulsante [Add] per aggiungerle all'interfaccia ETH00;
  • Aggiungere le stesse classi anche all'interfaccia ETH01 ripetendo lo stesso procedimento eseguito per la ETH00;
  • Abilitare il servizio di QoS per l'interfacce ETH00 e ETH01 tramite i flag relativi alla voce "On";
  • Salvare tutte le modifiche fatte premendo il tasto [Activate last Changes].
Si noti che si è attivata la Qualità di Servizio solo direttamente sulle interfacce componenti il bridge e non sull'interfaccia BRIDGE00 come si poteva erroneamente pensare di fare.
Arrivati a questo punto il servizio di QoS è attivo sul bridge, ma ancora tutto il traffico passa per le classi DEFAULT poiché non abbiamo ancora classificato opportunamente i pacchetti come descritto nel paragrafo successivo.

Associare i servizi alle classi di QoS

Per associare un servizio a cui vogliamo applicare il QoS alla relativa classe si utilizza il Classificatore. Si nota subito che questo componente, in Zeroshell, ha un aspetto molto simile al Firewall. Infatti la somiglianza è talmente tanta, che si deduce che sono la stessa cosa se non per il fatto che ai classici target del firewall (Accept, Drop, ...) si sostituiscono i nomi delle classi del Class Manager. In altre parole, il traffico viene intercettato con le stesse modalità e condizioni che si utilizzerebbero nel firewall, ma le azioni da compiere sono l'associazione alle classi di QoS.
Procediamo dunque a classificare i servizi come segue:
  • Selezionare il Classificatore dalla sezione [QoS]->[Classifier] (vedi figura). Premere il pulsante [Add] per inserire la prima regola nel classificatore che riguarderà il traffico P2P per file sharing. Compare la finestra di dialogo (vedi figura) in cui bisogna abilitare i flag relativi ai protocolli "Peer-to-Peer" e poi selezionare la target class P2P. Tramite il pulsante [Confirm] confermare la regola di classificazione;
  • Adesso è il turno del traffico VoIP. Cominciamo dal protocollo SIP selezionandolo dai filtri Layer 7 e scegliendo la target class VOIP (vedi figura). La stessa operazione va ripetuta anche per i protocolli H323, Skype to Skype e MSN Messenger;
  • Per classificare il traffico interattivo all'interno della classe SHELL si sfrutta il fatto che un server ssh risponde sulla porta TCP 22 mentre un server telnet sulla porta TCP 23. Sono necessarie in tutto 4 regole poiché si deve considerare sia il traffico destinato a tali porte, sia quello proveniente da queste. Come esempio vediamo solo quello relativo ai pacchetti destinati alla porta TCP 22;
  • Per classificare il traffico BULK generato dal trasferimento di messaggi di posta elettronica, si sfrutta il fatto che un server smtp risponde sulla porta TCP 25 (vedi figura);
  • Benché il protocollo ftp utilizzi la porta TCP 21 come porta per stabilire la connessione iniziale e come porta di controllo, i trasferimenti di dati avvengono invece su porte casuali. Per tale motivo è necessario utilizzare i filtri L7 (vedi figura); per classificare i trasferimenti ftp nella classe QoS BULK.
  • Per salvare e attivare le regole del classificatore premere il tasto [Save].
Nota: sicuramente il classificare il traffico come appartenente ad un certo servizio è l'operazione più complessa nel realizzare il QoS. Non sempre è facile stabilire, mediante parametri di rete come l'indirizzo IP sorgente e destinazione o di trasporto quali le porte TCP e UDP, il tipo di traffico. Abbiamo visto, che un aiuto fondamentale ci viene dato dai filtri Layer 7 (L7-filter), che grazie alle regular expression e a metodi di connection tracking possono individuare il tipo di protocollo a livello di applicazione, cioè guardando all'effettivo contenuto dei pacchetti. Tuttavia, si badi bene a non abusare di questo metodo di classificazione per due motivi. Il primo è che filtrare guardando al payload dei pacchetti può avere un dispendio notevole in termini di CPU utilizzata e ciò può essere proibitivo su macchine non dotate di una discreta potenza di calcolo. Il secondo motivo è che per alcuni protocolli, gli L7-filter presentano il fenomeno dell'overmatching, cioè alcuni pacchetti non appartenenti ad un protocollo vengono classificati come tali. Altre volte si verifica il contrario (fenomeno di undermatching) in cui pacchetti appartenenti ad un protocollo non vengono individuati come tali. In generale, si dovrebbe evitare di utilizzare i filtri di livello 7 quando è possibile individuare un servizio tramite condizioni di altro tipo. Supponiamo per esempio, che tutte le videoconferenze H323 avvengano utilizzando sempre la stessa MCU (Multipoint Conferencing Unit): in tal caso invece di individuare tutto il traffico H.323 utilizzando i filtri L7 è meno dispendioso in termini di CPU, individuare i pacchetti mediante l'indirizzo IP della MCU.

Visualizzare le statistiche di QoS

Giunti a questo punto il QoS bridge è ormai funzionante. Per controllare che il traffico sia classificato nella maniera che ci si aspetta è possibile visualizzare le statistiche dalla sezione [QoS]->[Statistics] (vedi figura). Per ognuna della interfacce su cui è abilitata la qualità di servizio sono riportate le classi disponibili e per ogni classe viene riportata la configurazione (Priorità, Banda Massima e Banda Garantita), il numero di byte effettivamente classificati nonché il Rate, cioè il numero di bit al secondo trasmessi dalla classe di QoS. Inoltre, è possibile ottenere un grafico ottenuto con MRTG che riporti contemporaneamente il traffico classificato in una determinata classe e quello totale di un'interfaccia. Maggiori dettagli possono essere trovati qui.



    Copyright (C) 2005-2016 by Fulvio Ricciardi