Bandwidth Limiting HOWTO

Transcript

1 Bandwidth Limiting HOWTO Introduzione Mi è stato chiesto di fornire un firewall, con GNU/Linux, che permettesse anche di limitare e gestire in modo intelligente, il traffico generato da alcuni host e/o destinato ad alcuni servizi in particolare. Il risultato delle mie prove è in questo HOWTO, che affronta la problematica, peraltro molto complessa, dal punto di vista pratico. Il mio obiettivo era quello di realizzare un sistema che permettesse di fare shaping della banda in uscita e di smistare il traffico originato da alcuni host della rete interna, o diretto verso particolari servizi esterni. Il metodo utilizzato è vario, ho infatti preso in considerazione diversi sistemi, partendo dal confronto delle soluzioni con CBQ e HTB, ma anche SQUID con i suoi delay pool, destinato però solo al controllo del traffico http, per finire con IPROUTE per lo smistamento del traffico La mia base di sperimentazione è stata un sistema centrale, un firewall/router con una struttura che prevedeva due linee di collegamento ad internet, una xdsl (eth1) e l altra DIAL- UP (ippp0) con un interfaccia verso la LAN interna (eth0). Una situazione abbastanza classica, dove però il firewall in questione, oltre a effettuare NAT e Filtering doveva effettuare shaping e redistribuzione del traffico sulle due linee. Per la sperimentazione mi sono avvalso di tre sistemi: 1. neo lo shaper ovvero il firewall connesso ad internet essenzialmente su connessione dialup ISDN a 64 kilobits 2. cam client della mini lan creata per i test 3. oberon altro client della mini lan usato per effettuare shaping differenti tra client della stessa rete. Per il firewall è stata utilizzata come distribuzione una Debian/Sarge con Kernel standard e con i software tc e ip installati. Dal punto di vista software non è stato aggiunto nulla, se non il frontend per iptables shorewall e alcuni tool di analisi della banda. Lo Shaping: QoS e TC Introduzione Con il termine di shaping e di shaper, lo strumento che permette di effettuarlo, intendiamo la possibilità di limitare e regimentare il traffico che passa per una determinata interfaccia. Questa funzione è permessa sui sistemi GNU/Linux dal kernel, che opportunamente configurato, consente tutta una serie di configurazioni per limitare il traffico in ingesso ed in uscita per una specifica interfaccia. Quality of Service e Traffic Control Prima di passare alla parte pratica ovvero all implementazione diretta dello shaping è bene vedere qualche concetto teorico sul TC (Traffic Control) e sul QoS (Quality of Service) Innanzitutto occorre ricordare che le nuove funzionalità del kernel permettono un maggior controllo e nuove funzionalità rispetto a quello che era consentito con il vecchio modulo shaper.o. Tra le caratteristiche principali ricordiamo la possibilità di impostare a priori la velocità di trasmissione dei dati in uscita da una determinata interfaccia, inoltre è possibile stabilire delle

2 priorità tra i pacchetti, smistarli in base alla destinazione, al tipo, ai bit TOS (Type Of Service) e su diverse linee. Esistono una serie di elementi che permettono di implementare queste caratteristiche: La Disciplina di accodamento: permette di effettuare lo scheduling dei pacchetti, e va associata alla scheda di rete Le Classi: servono per definire le differenti tipologie di traffico I Filtri: permettono di suddividere il traffico nelle varie classi definite La Disciplina di accodamento Detta anche qdisc rappresenta l'elemento fondante di questo metodo. Infatti tutti i pacchetti provenienti da una specifica interfaccia venogno accodati. E proprio sulla base della qdisc voluta che verrà prelevato e inviato attraverso l'interfaccia di output. La gestione della disciplina delle code è un argomento complesso, visto che ne esistono di diverso tipo, quella più nota e di default è la FIFO (First-IN/First-OUT). Secondo questa disciplina il primo pacchetto in ingresso e anche il primo in uscita. Possiamo definire questa disciplina la più semplice, visto che ne esistono altre molto più complesse ed elaborate (RED, CBQ, HTB, TBF e Prio). A seconda delle peculiari caratteristiche si possono scegliere quelle volute. Ad esempio la Class Based Queueing (CBQ) è qdisc principale e più utilizzata. E suddivisibile in classi a cui assegnare caratteristiche differenti e attraverso cui segmentare il traffico associandolo a classi ad esempio con banda differente. Una caratteristica di queste classi e di poter essere separate tra loro ma anche di prestarsi banda in caso di inutilizzo. Un limite di cui soffre questa qdisc e di non essere molto precisa nella suddivisone delle banda, a causa della difficoltà di allocazione delle risorse fisiche di banda. Ecco perché si utilizza spesso un altra qdisc la Hierarchical Token Bucket (HTB), semplice da configurare e molto più precisa nella suddivisone della banda, specie nel caso in cui si vogliano creare classi a cui assegnare una banda garantita. Anche questa soluzione permette di recuperare banda dalla classe parent nel caso in cui ne resti di inutilizzata. Comunque se non viene specificata una disciplina particolare verrà sempre usata quella di default (FIFO). Le Classi Con le classi si possono determinare delle sotto-sezioni a cui assegnare uno specifico bandwidth, la priorità voluta e molti altri parametri. In modo gerarchico ogni classe può avere ulteriori suddivisioni (sottoclassi) a cui associare una coda, che avrà il compito di gestire i pacchetti che in essa venogno accodati e decidere quali pacchetti inviare per primi ed il loro ordine. Ovviamente sarà compito della coda scartare eventuali pacchetti che non soddisfano le regole (limit) o le violano. I Filtri E attraverso i filtri che vengono effettivamente suddivisi i pacchetti e inviati verso le classi a cui sono stati associati. E proprio qui che sta la parte più interessante in cui si decide in base a quali caratteristiche un pacchetto debba essere associato ad una determina classe e per questo ad una determinata banda impostata. Le caratteristiche possono essere molte dall indirizzo sorgente o da quello di destinazione, oppure in base alla. porta destinazione o a quella sorgente. E anche possibile filtrare in base al marking da parte di iptables (mangle table). Il nostro Scenario

3 Utilizziamo una macchina gw/firewall con tre interface una eth0 sulla LAN interna l altra ippp0 verso internet Dial-Up e una eth1 verso una connessione internet xdsl. Per semplificare la descrizione e gli esempi ipotizziamo di effettuare lo shaping sull interfaccia eth0 per il traffico proveniente dalla LAN, verso l interfaccia dial-up ippp0. Infatti limitando il rate sull interfaccia interna verrà di conseguenza limitato anche sull ippp0 in uscita verso internet eth0 (default GW per la LAN)... eth1 ippp0 la distribuzione è una Debian/Sarge con Kernel e con i software tc e ip installati. # ip Usage: ip [ OPTIONS ] OBJECT { COMMAND help } where OBJECT := { link addr route rule neigh tunnel maddr mroute monitor xfrm } OPTIONS := { -V[ersion] -s[tatistics] -r[esolve] -f[amily] { inet inet6 ipx dnet link } -o[neline] } # tc Usage: tc [ OPTIONS ] OBJECT { COMMAND help } where OBJECT := { qdisc class filter action } OPTIONS := { -s[tatistics] -d[etails] -r[aw] -b[atch] file } Il comando tc E attraverso questo comando ed alcuni dei suoi sotto comandi che passa la programmazione delle nostre regole di shaping. Prenderci un po di confidenza prima di cercare una configurazione funzionante è una cosa da fare assolutamente. è il sottocomando per creare lo scheduler qdisc root cbq # tc qdisc help Usage: tc qdisc [ add del replace change get ] dev STRING [ handle QHANDLE ] [ root ingress parent CLASSID ] [ estimator INTERVAL TIME_CONSTANT ] [ [ QDISC_KIND ] [ help OPTIONS ] ] tc qdisc show [ dev STRING ] [ingress] Where: QDISC_KIND := { [p b]fifo tbf prio cbq red etc. } OPTIONS :=... try tc qdisc add <desired QDISC_KIND> help è il sottocomando per creare le classi e le sottoclassi (parent) # tc class help Usage: tc class [ add del change get ] dev STRING [ classid CLASSID ] [ root parent CLASSID ] [ [ QDISC_KIND ] [ help OPTIONS ] ] tc class show [ dev STRING ] [ root parent CLASSID ] Where: QDISC_KIND := { prio cbq etc. } OPTIONS :=... try tc class add <desired QDISC_KIND> help è il sottocomando che permette di associare le classi alle regole impostate

4 # tc filter help Usage: tc filter [ add del change get ] dev STRING [ pref PRIO ] [ protocol PROTO ] [ estimator INTERVAL TIME_CONSTANT ] [ root classid CLASSID ] [ handle FILTERID ] [ [ FILTER_TYPE ] [ help OPTIONS ] ] tc filter show [ dev STRING ] [ root parent CLASSID ] Where: FILTER_TYPE := { rsvp u32 fw route etc. } FILTERID :=... format depends on classifier, see there OPTIONS :=... try tc filter add <desired FILTER_KIND> help Predisposizione Kernel compilato con il supporto iptables e tc e masquerading configurato: Code maturity level options ---> [*] Prompt for development and/or incomplete code/drivers [CONFIG_EXPERIMENTAL] Networking Options --->... [*] QoS and/or fair queueing ---> [*] QoS and/or fair queueing (EXPERIMENTAL) [CONFIG_NET_SCHED] <M> CBQ packet scheduler [CONFIG_NET_SCH_CBQ] <M> CSZ packet scheduler [CONFIG_NET_SCH_CSZ] <M> The simplest PRIO pseudoscheduler [CONFIG_NET_SCH_PRIO] <M> RED queue [CONFIG_NET_SCH_RED] <M> SFQ queue [CONFIG_NET_SCH_SFQ] <M> TEQL queue [CONFIG_NET_SCH_TEQL] <M> TBF queue [CONFIG_NET_SCH_TBF] <M> GRED queue <M> Diffserv field marker <M> Ingress Qdisc [*] QoS support [CONFIG_NET_QOS] [*] Rate estimator [CONFIG_NET_ESTIMATOR] [*] Packet classifier API [CONFIG_NET_CLS] <M> TC index classifier <M> Routing table based classifier [CONFIG_NET_CLS_ROUTE4] <M> Firewall based classifier [CONFIG_NET_CLS_FW] <M> U32 classifier [CONFIG_NET_CLS_U32] <M> Special RSVP classifier [CONFIG_NET_CLS_RSVP] <M> Special RSVP classifier for IPv6 [CONFIG_NET_CLS_RSVP6] [*] Traffic policing (needed for in/egress) Impostazione del Masquerading per la LAN alle spalle del firewall: # echo 1 > /proc/sys/net/ipv4/ip_forward #iptables -t nat -A POSTROUTING s $INTERNAL_LAN -j MASQUERADE Configurazione manuale delle regole Proviamo a configurare manualmente le nostre regole di shaping sulla base di quello che abbiamo appreso fino ad ora. Le configurazioni mostrate utilizzano la qdisc maggiormente implementata ovvero la CBQ (Class Based Queueing). Vedremo alla fine della sezione anche degli esempi che prevedono l utilizzo dalla soluzione con il metodo della coda HTB (Hierarchical Token Bucket). Creiamo uno script di questo tipo, partendo dal presupposto che il nostro scopo è limitare il traffico verso le porte 80 e 21 di uno specifico host della nostra rete. Tale regola verrà applicata solo per tale host mentre tutti gli altri saranno liberi di sfruttare la connessione a piena banda.

5 Il traffico viene limitato agli host destinatari il cui traffico passa per l interfaccia della LAN interna eth0 a cui inviano il traffico e che successivamente sarà dirottate (già limitato) all interfaccia connessione ad internet (ippp0). #tc.rules CBQ qdisc # Questo comando crea e associa all'interfaccia eth0 lo scheduler qdisc root cbq tc qdisc add dev eth0 root handle 1 cbq bandwidth 100Mbit avpkt 1000 cell 8 # Questo comando crea la prima classe root, che ha come genitore il root handle 1:, ed è la classe in cui verranno poi #divideranno il bandwidth dei protocolli/ip scelti. tc class add dev eth0 parent 1: classid 1:10 cbq bandwidth 100Mbit rate 16Kbit weight 3 prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded # Questo comando crea e associa una classe all'interfaccia eth0, la classe parent è root 1:10 già creata tc qdisc add dev eth0 parent 1:10 handle 10 tbf rate 16Kbit buffer 10Kb/8 limit 15Kb mtu 1500 # Questi comandi permettono effettivamente di associare alla classe root. le regole (ip e porte) voluti per la #limitazione del traffico tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 80 0xffff match ip dst /32 classid 1:10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 21 0xffff match ip dst /32 classid 1:10 Il significato dei vari attributi viene ripreso in seguito, quando si vedrà la programmazione semplificata delle regole tramite script. Vediamo in uno schema semplificato le regole di programmazione che abbiamo inserito: In realtà la cosa migliore è utilizzare uno script dal nome cbq.init giunto alla versione 0.7.3, che ci offre un sistema mediato, più semplice ed intuibile per la configurazione del nostro shaper. In effetti basta configurare dei file dalla sintassi semplificata e decisamente intuibile, in cui inserire i parametri voluti e poi compilare lo script. A questo punto una volta avviato lo script le regole venogno impostate automaticamente. Con questo sistema si riesce a passare direttamente alla programmazione dello shaker anche se non si ha una grande confidenza con la materia. Vale ovviamente sempre la regola per cui sistemi di questo tipo vanno accuratamente testati per non incorrere in marchiano errori di programmazione, in grado a volte di minare la sicurezza del sistema o addirittura della rete alle sue spalle.

6 Per chi volesse invece approfondire gli aspetti di programmazione ed entrare nel dettagli delle regole consiglio l ottimo documento Controllo del traffico, shaping di Masetti Marco, reperibile all indirizzo: Installazione Vediamo adesso come ottenere ed utilizzare rapidamente lo script cbq.init-v0.7.3, per la programmazione semplificata del nostro shaker. Cominciamo con lo scaricare lo script e renderlo eseguibile: # cd /usr/src # mv /usr/src/cbq.init-v0.7.3 /sbin/cbq # chmod 0700 /sbin/cbq # wget Configurazione Basta editare lo script per comprenderne la sintassi e notare come la configurazione venga davvero semplificata e resa possibile anche a chi esperto della materia non è. Sintassi ### Device parameters # # DEVICE=<ifname>,<bandwidth>[,<weight>] mandatory # DEVICE=eth0,10Mbit,1Mbit # # <ifname> is the name of the interface you want to control # traffic on, e.g. eth0 # <bandwidth> is the physical bandwidth of the device, e.g. for # ethernet 10Mbit or 100Mbit, for arcnet 2Mbit # <weight> is tuning parameter that should be proportional to # <bandwidth>. As a rule of thumb: <weight> = <bandwidth> / 10 # # When you have more classes on one interface, it is enough to specify # <bandwidth> [and <weight>] only once, therefore in other files you only # need to set DEVICE=<ifname>. ### Filter parameters # # RULE=[[saddr[/prefix]][:port[/mask]],][daddr[/prefix]][:port[/mask]] Creare una directory /etc/sysconfig/cbq in cui depositare i propri script # mkdir /etc/sysconfig/cbq Esempi # cd /etc/sysconfig/cbq # vi cbq-10.ftp_http-network DEVICE=eth0,100Mbit,10Mbit

7 RATE=10Kbit WEIGHT=1Kbit PRIO=5 RULE=:80, /24 RULE=:20, /24 RULE=:21, /24 Limita il rate in download a 10 Kbit ~ 1,5 KB/s # vi cbq-15.posta-network DEVICE=eth0,100Mbit,10Mbit RATE=30Kbit WEIGHT=1Kbit PRIO=5 RULE=:110, /24 RULE=:25, /24 RULE=:143, /24 Limita il rate in download per la posta a 30 Kbit ~ 3,8 KB/s # vi cbq-20.audio-network DEVICE=eth0,100Mbit,10Mbit RATE=35Kbit WEIGHT=3Kbit PRIO=5 # Windows Media Player. RULE=:1755, /24 # Real Player RULE=:554, /24 RULE=:7070, /24 Limita il rate in download a 35 Kbit ~ 4,2 KB/s per alcuni servizi audio Sono stati scelti valori di rate molto bassi perché la linea su cui sono stati fatti i test è una linea ISDN a 64 kbits (8KBytes) e anche perché è più semplice vedere direttamente l efficacia dello shaper. Attivazione e disattivazione dello shaping # cbq Usage: cbq {start compile stop restart timecheck list stats} # cbq start # cbq stop Stampa delle regole Questo comando è molto utile perché ci mostra come lo shaper programma le table utilizzando il comando tc. # cbq compile 1- /sbin/tc qdisc del dev eth0 root 2- /sbin/tc qdisc add dev eth0 root handle 1 cbq bandwidth 100Mbit avpkt 1000 cell 8 3- /sbin/tc class change dev eth0 root cbq weight 10Mbit allot 1514

8 4- /sbin/tc class add dev eth0 parent 1: classid 1:10 cbq bandwidth 100Mbit rate 15Kbit weight 1Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded 5- /sbin/tc qdisc add dev eth0 parent 1:10 handle 10 tbf rate 15Kbit buffer 10Kb/8 limit 15Kb mtu /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst /32 classid 1:10 Vediamo il significato dei comandi nel dettaglio: 1- tc qdisc del dev eth0 root Questo comando elimina una qdisc root eventualmente preesistente già associata all interfaccia eth0, una sorta di flush delle regole per gli scheduler. 2- tc qdisc add dev eth0 root handle 1 cbq bandwidth 100Mbit avpkt 1000 cell 8 Questo comando crea e associa all'interfaccia eth0 lo scheduler qdisc root cbq e la identifica con handle 1, il bandwidth totale associato è 100Mbit, avpkt è la grandezza del pacchetto medio e serve per determinare il tempo di trasmissione. Il tempo di trasmissione è = a avpkt/bandwidth. Conviene farlo 400 unità più piccolo rispetto alla normale grandezza di un pacchetto. Nel nostro caso il suo valore è 1000 byte. 3- tc class change dev eth0 root cbq weight 10Mbit allot 1514 Questo comando modifica il peso (weight), un parametro per il tuning delle connessioni in genere è WEIGHT ~= RATE / tc class add dev eth0 parent 1: classid 1:10 cbq bandwidth 100Mbit rate 15Kbit weight 1Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded Questo comando crea la prima classe ROOT, che ha come genitore il root handle 1:, ed è la classe in cui verranno poi divideranno il bandwidth dei protocolli/ip scelti. In questo caso il bandwidth assegnata 100Mbit, priorità della classe 8. e allot nel caso ethernet è da impostare a 1514 (allot=mtu+mac), il weight è da scegliere proporzionale a rate, in genere 1/10 di rate. Il significato delle opzioni è: allot è un parametro formato dall'mtu + MAC header. è sempre più grande di avpkt*3/2. maxburst è il numero massimo di pacchetti che verranno trasmessi nel flusso più lungo dedicato alla classe prio è la priorità con cui vengono trattate le classi. Le classi con priorità uguale vengono trattate contemporaneamente. Esiste anche il parametro weight che dovrebbe servire per determinare il numero di byte che una classe può spedire ad ogni giro di schedulazione.. 5- tc qdisc add dev eth0 parent 1:10 handle 10 tbf rate 15Kbit buffer 10Kb/8 limit 15Kb mtu 1500 Crea e associa una classe all'interfaccia eth0, la classe parent è root 1:10 già creata. La classe è di tipo cbq, il rate 15Kbit buffer 10Kb/8 6- tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst /32 classid 1:10 I flussi in uscita si possono assegnare alle classi usando il comando: tc filter. Possiamo associare la nostra regola alla classe root, 1:. L IP di destinazione è /32 Il parametro u32 permette di filtrare i pacchetti in base al contenuto delle intestazioni evitando l'utilizzo del filtro dei pacchetti com il loro marcamento dei pacchetti, permettendo una maggior efficienza. Questo script usato con questo comando (cbq compile) è davvero molto utile perché è una sorta di generatore di regole, utile per poter creare le regole in una forma mediata e poi

9 programmarle con tc sul nostro sistema di shaping. In questo modo le regole diventano comprensibili. Limitazione delle risposta ICMP: un esempio semplice Proviamo a vedere questa semplice ed immediata applicazione di una regola di shaping sulla nostra interfaccia di rete e osserviamo il suo comportamento prima e dopo. Solo per poter verificare in modo semplice ed immediato se il nostro shaper funziona oppure no. In questo caso viene utilizzata, solo a titolo di esempio, una nuova tipologia di coda ovvero TBF. Per condurre il test inviamo dei pacchetti ICMP di una certa dimensione: # ping c 3 -s 512 PING ( ) 512(540) bytes of data. 520 bytes from : icmp_seq=1 ttl=55 time=204 ms 520 bytes from : icmp_seq=2 ttl=55 time=200 ms 520 bytes from : icmp_seq=3 ttl=55 time=208 ms ping statistics packets transmitted, 3 received, 0% packet loss, time 2023ms rtt min/avg/max/mdev = / / /3.642 ms Proviamo adesso a ridurre notevolmente il rate della nostra interfaccia: # tc qdisc add dev ippp0 root tbf rate 1kbit burst 1024 latency 100ms Ora riproviamo a effettuare il ping: # ping c 3 -s 512 PING ( ) 512(540) bytes of data. 520 bytes from : icmp_seq=1 ttl=55 time=219 ms 520 bytes from : icmp_seq=2 ttl=55 time=201 ms ping statistics packets transmitted, 2 received, 33% packet loss, time 2010ms rtt min/avg/max/mdev = / / /8.906 m Alcuni pacchetti vanno persi, lo shaper è entrato in funzione, verifichiamo anche se ha effettivamente droppato dei pacchetti: # tc -s qdisc show dev ippp0 qdisc tbf 8006: rate 1000bit burst 1023b lat 93.8ms Sent 2152 bytes 10 pkts (dropped 0, overlimits 1) Limitazione Download e Upload: un esempio più elaborato Vediamo un esempio un po più complesso in cui è possibile usare la qdisc cbq e la mangle table per poter marcare i pacchetti e limitarli sia nel DOWNLOAD che nell UPLOAD. In questo caso oltre alle regole di shaping impartire tramite tc, è necessario marcare i pacchetti tramite la mangle table (set-mark) e associarli alla coda specifica creata. Il sistema è un po più complesso ma molto versatile in quanto iptables permette una definizione molto specifica, per i pacchetti intercettati, basata su molte caratteristiche del pacchetto stesso (source o destination port, source o destination address, etc). Per fare questo immaginiamo il seguente scenario con 64 Kbits di banda massima a disposizione, e due eth0 (default GW per la LAN)

10 ippp0 (NET) eth0 interfaccia connessa alla LAN che vogliamo limitare in UPLOAD e DOWNLOAD ippp0 interfaccia connessa ad INTERNET Questo esempio mostra come utilizzare rapidamente uno script, reperito su web, e opportunamente modificato per limitare il traffico in upload e download, attraverso una normale connessione ad internet. L operazione richiede due passaggi il primo la configurazione dello script con definizione di alcuni parametri tra cui le interfacce ed i limiti voluti. Della nostra connessione ISDN a 64 kbits di banda disponibile assegniamo 32 kbit al download e 8 appena all upload. Imposteremo i parametri per la qdisc del download sull interfaccia interna (eth0) e quelli per l upload sull interfaccia esterna (ippp0). #!/bin/bash # rc.tc script TC=/sbin/tc DNLD=32Kbit # Limite per il DOWNLOAD DWEIGHT=4Kbit # DOWNLOAD Weight Factor in genere 1/10 del DOWNLOAD Limit UPLD=8KBit # Limite per l UPLOAD UWEIGHT=1Kbit # UPLOAD Weight Factor in genere 1/10 del UPLOAD Limit TOTBDWD=100kbit # TOT BAND interfaccia interna TOTBDWU=64kbit # TOT BAND interfaccia esterna LAN= eth0 # interfaccia interna NET= ippp0 # interfaccia esterna tc_start() { $TC qdisc add dev $LAN root handle 11: cbq bandwidth $TOTBDWD avpkt 1000 mpu 64 $TC class add dev $LAN parent 11:0 classid 11:1 cbq rate $DNLD weight $DWEIGHT allot 1514 prio 1 avpkt 1000 bounded $TC filter add dev $LAN parent 11:0 protocol ip handle 2 fw flowid 11:1 $TC qdisc add dev $NET root handle 10: cbq bandwidth $TOTBDWU avpkt 1000 mpu 64 $TC class add dev $NET parent 10:0 classid 10:1 cbq rate $UPLD weight $UWEIGHT allot 1514 prio 1 avpkt 1000 bounded $TC filter add dev $NET parent 10:0 protocol ip handle 1 fw flowid 10:1 } tc_stop() { $TC qdisc del dev $LAN root $TC qdisc del dev $NET root } tc_restart() { tc_stop sleep 1 tc_start } tc_show() { echo "" echo "$LAN:" $TC qdisc show dev $LAN $TC class show dev $LAN $TC filter show dev $LAN echo ""

11 } echo "$NET:" $TC qdisc show dev $NET $TC class show dev $NET $TC filter show dev $NET echo "" tc_count() { echo "" echo "$LAN:" $TC -s qdisc show dev eth0 $TC -s class show dev eth0 $TC -s filter show dev eth0 echo "" echo "$NET:" $TC -s qdisc show dev ippp0 $TC -s class show dev ippp0 $TC -s filter show dev ippp0 echo "" } case "$1" in start) echo -n "Starting bandwidth shaping: " tc_start echo "done" ;; stop) echo -n "Stopping bandwidth shaping: " tc_stop echo "done" ;; restart) echo -n "Restarting bandwidth shaping: " tc_restart echo "done" ;; show) tc_show ;; count) tc_count ;; *) esac echo "Usage: /etc/init.d/tc.sh {start stop restart show count}" ;; exit 0

12 La parte relativa alla coda è posto ora occorre impostare la mangle table, in questo caso per un intera sottorete: # less rc.mangle #!/bin/bash # rc.mangle script # Mark packets to route IPTABLES="/sbin/iptables" LAN= /24 #puliamo regole precedenti $IPTABLES -F -t mangle # Upload marking $IPTABLES -t mangle -A FORWARD -s $LAN -j MARK --set-mark 1 # Download marking $IPTABLES -t mangle -A FORWARD -d $LAN -j MARK --set-mark 2 Con questo secondo comando associamo le regole impostate alla mangle table. Ovviamente con iptables è possibile impostare le regole desiderate e applicare lo shaping per il download e per l upload, anche solo per host specifici o per porte particolari. La mangle table e la parte più critica, quella che permette attraverso la marcatura di alcuni pacchetti, di applicare effettivamente lo shaping e va ovviamente predisposta secondo le proprie esigenze. Per attivare il tutto: # /etc/init.d/rc.tc start # /etc/init.d/rc.mangle Verifichiamo lo shaping provando a fare del traffico sia in upload che in download: # tc -s class show dev eth0 class cbq 11:1 parent 11: rate 32000bit (bounded) prio 1 Sent bytes 275 pkts (dropped 0, overlimits 581) borrowed 0 overactions 183 avgidle 81 undertime 0 # tc -s class show dev ippp0 class cbq 10:1 parent 10: rate 8000bit (bounded) prio 1 Sent bytes 284 pkts (dropped 0, overlimits 147) borrowed 0 overactions 73 avgidle 8571 undertime 0 # iptables -L -t mangle Chain FORWARD (policy ACCEPT) target prot opt source destination MARK all /24 anywhere MARK set 0x1 MARK all -- anywhere /24 MARK set 0x2 In effetti in entrambi i sensi lo shaper ha agito marcando dei pacchetti in overlimit. In download otteniamo valori medi intorno a 3,8 kbytes e in upload, effettuato tramite un semplice put in ftp, valori intorno a 1 KBytes, esattamente come ci saremmo aspettati. Ho trovato questo sistema molto adatto e preciso per effettuare shaping sia in UPLOAD che in DOWNLOAD. Wondershaper: una soluzione alternativa Come si può notare molte sono le soluzioni possibili per configurare facilmente lo shaping. Anche questa è una comoda interfaccia, facile da configurare, forse limitata, che permette anche di interfacciarsi a Shorewall, come frontend per il firewall iptables.

13 Informazioni su questo progetto sono disponibili presso: Una volta scaricati gli script per lo shaping # wget Esistono due script, wshaper, basato su cbq e wshaper.htb basato su htb. Una volta rimossa l istruzione di exit che ne impedisce l utilizzo basta configurare le voci: DOWNLINK=16 velocità di UPLOAD in kilobits UPLINK=8 velocità di DOWNLOAD in kilobits DEV=ippp0 interfaccia su cui effettuare lo shaping Attenzione se DEV=Interfaccia esterna (NET) allora DOWNLINK è il valore di download e UPLINK quello di upload, per la rete locale alle spalle dello shaper. Se invece DEV=Interfaccia interna (LAN) allora DOWNLINK è il valore di upload e UPLINK quello di download, per la rete locale alle spalle dello shaper. Questo perché si utilizza l interfaccia esterna e ciò che è destination diventa source e viceversa. Opzionali sono le voci per la priorizzazione del traffico: # low priority OUTGOING traffic - you can leave this blank if you want # low priority source netmasks NOPRIOHOSTSRC= # low priority destination netmasks NOPRIOHOSTDST= # low priority source ports NOPRIOPORTSRC= # low priority destination ports NOPRIOPORTDST= Una volta eseguito lo script wshaper.htb: #./wshaper.htb + DOWNLINK=16 + UPLINK=8 + DEV=ippp0 + NOPRIOHOSTSRC= + NOPRIOHOSTDST= + NOPRIOPORTSRC= + NOPRIOPORTDST= + '[' '' = status ']' + tc qdisc del dev ippp0 root + tc qdisc del dev ippp0 ingress + '[' '' = stop ']' + tc qdisc add dev ippp0 root handle 1: htb default 20 + tc class add dev ippp0 parent 1: classid 1:1 htb rate 8kbit burst 6k + tc class add dev ippp0 parent 1:1 classid 1:10 htb rate 8kbit burst 6k prio 1 + tc class add dev ippp0 parent 1:1 classid 1:20 htb rate 7kbit burst 6k prio 2 + tc class add dev ippp0 parent 1:1 classid 1:30 htb rate 6kbit burst 6k prio 2 + tc qdisc add dev ippp0 parent 1:10 handle 10: sfq perturb 10 + tc qdisc add dev ippp0 parent 1:20 handle 20: sfq perturb 10 + tc qdisc add dev ippp0 parent 1:30 handle 30: sfq perturb 10 + tc filter add dev ippp0 parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff flowid 1:10 + tc filter add dev ippp0 parent 1:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:10

14 + tc filter add dev ippp0 parent 1: protocol ip prio 10 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:10 + tc filter add dev ippp0 parent 1: protocol ip prio 18 u32 match ip dst /0 flowid 1:20 + tc qdisc add dev ippp0 handle ffff: ingress + tc filter add dev ippp0 parent ffff: protocol ip prio 50 u32 match ip src /0 police rate 16kbit burst 10k drop flowid :1 Sempre sul solito link ISDN a 64 kilobits ho assegnato un massimo per il download di 16 kilobits. Un semplice test con wget mi conferma il funzionamento della limitazione: # wget :49: => `file.exe' Resolving Connecting to connected. HTTP request sent, awaiting response OK Length: 14,841,140 [application/x-msdos-program] 8% [======> 1.78K/s ~ kilobits effettivi ] 1,193, K/s ETA 1:35:43 Ovviamente per poter utilizzare questo script occorre che kernel e programmi (tc) siano presenti sul sistema, ma per il resto è davvero semplice e veloce, e permette in pochi secondi di effettuare una riduzione della banda sia in ingresso che in uscita. Per poter interfacciare questo comodo script con shorewall basta copiarlo sotto la directory delle configurazioni di shorewall con il nome di tcscript, dopo averlo ovviamente configurato: # cp wshaper.htb /etc/shorewall/tcstart # chmod u+x tcstart A questo punto nel file shorewall.conf abilitare il supporto per lo shaping esterno tramite file modificando le opzioni presenti in questo modo: #shorewall.conf TC_ENABLED=Yes CLEAR_TC=Yes Prima di riavviare shorewall è possibile impostare delle porte che abbiano priorità diversa, definendo un file dal nome tcrules, con una sintassi simile: #MARK SOURCE DEST PROTO PORT(S) CLIENT PORT(S) 1 fw /0 tcp 6881: fw /0 tcp : fw /0 tcp 80,443-2 fw /0 tcp - 80,443 Il mark 1 è per il traffico a bassa priorità Il mark 2 è per il traffico ad alta priorità (ad esempio il traffico http e https) A questo punto riavviare shorewall e lo shaping viene abilitato: # shorewall restart Setting up Traffic Control Rules... TC Rule "1 fw /0 tcp 6881: " added

15 TC Rule "1 fw /0 tcp :6891 " added TC Rule "2 fw /0 tcp 80,443 - " added TC Rule "2 fw /0 tcp - 80,443 " added Processing /etc/shorewall/tcstart... L avvenuta configurazione la si può verificare con i comandi appositamente predisposti: # shorewall show classifiers # shorewall show tc Quest ultimo comando mostra anche l effettivo dropping dei pacchetti in eccesso, testimonianza dell effettiva applicazione dello shaping: a # shorewall show tc Shorewall Traffic Control at neo - mar gen 10 19:06:11 CET 2006 Device eth0: qdisc pfifo_fast 0: bands 3 priomap Sent bytes 767 pkts (dropped 0, overlimits 0) Device ippp0: qdisc htb 1: r2q 10 default 20 direct_packets_stat 0 ver 3.17 Sent bytes 178 pkts (dropped 0, overlimits 152) Comandi per la verifica Vediamo alcuni comandi generici che permettono di ottenere informazioni circa la configurazione e lo stato di funzionamento dello shaping. Utilizzano tc show e possono quindi essere utilizzati con una qualsiasi delle soluzioni proposte. Ad esempio con questo comando (-s[tatistics]) possiamo verificare il dropping, informazioni che ci mostra inequivocabilmente il funzionamento dello shaping. # tc -s class show dev eth0 class cbq 1: root rate Kbit (bounded,isolated) prio no-transmit Sent bytes 461 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 81 undertime 0 class cbq 1:10 parent 1: leaf 10: rate 10000bit (bounded) prio 5 Sent bytes 88 pkts (dropped 19, overlimits 0) borrowed 0 overactions 0 avgidle undertime 0 class tbf 10:1 parent 10: Con questo -d[etails] ottenere informazioni maggiormente dettagliato sulla configurazione del nostro shaper: # tc -s -d qdisc qdisc cbq 1: dev eth0 rate Kbit cell 8b (bounded,isolated) prio no-transmit/8 weight 10486Kbit allot 1514b level 1 ewma 5 avpkt 1000b maxidle 1us Sent bytes 72 pkts (dropped 12, overlimits 80) sta effettivamente tagliando backlog 7p borrowed 0 overactions 0 avgidle 81 undertime 0 qdisc tbf 10: dev eth0 rate 32000bit burst 10Kb/8 mpu 0b lat 1.2s Sent bytes 47 pkts (dropped 12, overlimits 129) backlog 7p

16 qdisc pfifo_fast 0: dev ippp0 bands 3 priomap Sent bytes 2523 pkts (dropped 0, overlimits 0) Con wget proviamo effettivamente se viene tagliata la banda: # wget :24: => `file.exe' Resolving Connecting to connected. HTTP richiesta inviata, aspetto la risposta OK Lunghezza: 14,841,140 [application/x-msdos-program] 0% [ ] 74, K/s ETA 2:59:35 Altri comandi # cbq list ### eth0: queueing disciplines qdisc cbq 1: rate Kbit (bounded,isolated) prio no-transmit qdisc tbf 10: rate 10000bit burst 10Kb lat 4.0s ### eth0: traffic classes class cbq 1: root rate Kbit (bounded,isolated) prio no-transmit class cbq 1:10 parent 1: leaf 10: rate 10000bit (bounded) prio 5 class tbf 10:1 parent 10: ### eth0: filtering rules filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 match /ffff0000 at 20 match c0a81100/ffffff00 at 16 filter parent 1: protocol ip pref 100 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:10 match /ffff0000 at 20 match c0a81100/ffffff00 at 16 filter parent 1: protocol ip pref 100 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:10 match /ffff0000 at 20 match c0a81100/ffffff00 at 16 ### ippp0: queueing disciplines qdisc pfifo_fast 0: bands 3 priomap # cbq stats ### eth0: queueing disciplines qdisc cbq 1: rate Kbit (bounded,isolated) prio no-transmit Sent bytes 236 pkts (dropped 25, overlimits 337) backlog 10p borrowed 0 overactions 0 avgidle 79 undertime 0 qdisc tbf 10: rate 10000bit burst 10Kb lat 4.0s Sent bytes 107 pkts (dropped 25, overlimits 674) backlog 10p ### eth0: traffic classes class cbq 1: root rate Kbit (bounded,isolated) prio no-transmit Sent bytes 236 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 81 undertime 0 class cbq 1:10 parent 1: leaf 10: rate 10000bit (bounded) prio 5 Sent bytes 97 pkts (dropped 25, overlimits 0)

17 backlog 10p borrowed 0 overactions 0 avgidle undertime 0 class tbf 10:1 parent 10: ### eth0: filtering rules filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 match /ffff0000 at 20 match c0a81100/ffffff00 at 16 filter parent 1: protocol ip pref 100 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:10 match /ffff0000 at 20 match c0a81100/ffffff00 at 16 filter parent 1: protocol ip pref 100 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:10 match /ffff0000 at 20 match c0a81100/ffffff00 at 16 ### ippp0: queueing disciplines qdisc pfifo_fast 0: bands 3 priomap Sent bytes 433 pkts (dropped 0, overlimits 0) Approfondimenti sulla configurazione di cbq E possibile limitare il traffico sia in ingresso che in uscita con una semplice Configurazione. Poniamo il seguente esempio: # # # INTERNET---eth0 - linux -eth *-[client] # # # Immaginiamo di voler limitare il traffico da internet verso il nostro client a 28Kbit # e il traffico nella direzione opposta a 128Kbit. Occorre Configurare due filtri su eth0 (client to # internet) e eth1 (internet to client): # # cbq-028.internet client # # DEVICE=eth1,10Mbit,1Mbit # RATE=28Kbit # WEIGHT=2Kbit # PRIO=5 # RULE= # destination address DOWNLOAD # # # cbq-128.client internet # # DEVICE=eth0,10Mbit,1Mbit # RATE=128Kbit # WEIGHT=10Kbit # PRIO=5 # RULE= , # source address UPLOAD # Sintassi # RULE=[[saddr[/prefix]][:port[/mask]],][daddr[/prefix]][:port[/mask]] Comandi utili

18 Vediamo alcuni comandi sempre di tc, utili un po in tutte le situazioni di configurazione: Eliminare una regola: # tc qdisc del dev ippp0 root Visualizzare le regole: # tc -s class show dev eth0 Visualizzare le statistiche in tempo reale: # tc -s class show dev eth0 # watch -n1 tc -s class ls dev eth0 Controllo via web Esiste un modulo per Webmin, che consente di programmare facilmente lo shaping dal proprio browser. Il modulo è stato sviluppato apposta per lo script cbq.init. Basta installare il modulo direttamente da webmin Una volta configurato, basta indicare il path dello script e la directory contenente le configurazioni: Permette di gestire cbq, riavviando o fermandolo, di creare nuove classi oppure di modificare quelle già create:

19 La Qdisc HTB Come anticipato esiste un altra qdisc supportata da Linux che permette di configurare lo shaping in alternativa a quella CBQ. E la qdisc HTB. Vediamo una sua implementazione, del tutto analoga alla precedente attraverso uno script, htb.init, del tutto simile a quello cbq.init, che permette attraverso la configurazione di alcuni file di impostare le regole di shaping in modo altrettanto agevole. La differenza tra questa soluzione e quella precedente consiste essenzialmente che con htb si può specificare eventualmente un surplus di banda da assegnare ad una classe, nel caso in cui questa sia disponibile. Questa operazione viene effettuata tramite il parametro CEIL, particolarmente utile nelle configurazioni standard dove si vuole tagliare la banda alla base, ma la si vuole comunque distribuire se disponibile. Per prima cosa scarichiamo o script ed alcuni file di esempio che semplificano il lavoro di configurazione: # wget # wget # mv tb.init-v0.8.5 /sbin # chmod 0700 /sbin/htb #mkdir /etc/sysconfig/htb # cd /etc/sysconfig/htb # tar tvfz htb-lartc.tar.gz # htb Usage: htb {start compile stop restart timecheck list stats} Vediamo come sfruttare gli esempi per effettuare una configurazione simile a quella fatta con CBQ. All interno dei file di configurazione occorre utilizzare una serie di parametri tra cui il parametro RATE per indicare la banda assegnata, con CEIL si indica la banda massima che può essere utilizzata prendendone in prestito dalla classe parent, se quest ultima risulta inutilizzata. Occorre poi specificare il valore di BURST per ogni classe, mentre la priorità nei confronti delle altre classi, indicata con il valore PRIO e opzionale. Con il parametro DEFAULT si specifica la classe in cui includere i pacchetti non classificati attraverso un altro metodo. Ipotizziamo sempre la situazione della connessione attraverso un interfaccia isdn del tipo ippp0, con al massimo 64 kbit di banda a disposizione ovvero 8 KBs. Lo shaping lo effettueremo sull interfaccia entrante connessa alla LAN, ovvero eth0.

20 eth0 (default GW per la LAN) ippp0 Procediamo in questo modo, creando una serie di script in /etc/sysconfig/htb: eth0: definisce l interfaccia su cui fare shaping ed alcuni parametri di default opzionali eth0-2.root: imposta la banda totale disponibile eth0-2:10.www: imposta la banda assegnata la servizio http eth0-2:20.smtp: imposta la banda assegnata al servizio http N.B. Attenzione ai nomi dei file usati apposta per suddividere le sottoclassi. La sintassi utilizzata è questa: # $HTB_PATH/<ifname>-<clsid>(:<clsid>)*<description> Vediamo gli script: # cd /etc/sysconfig/htb # less eth0 # default ID per il traffico non classificato DEFAULT=30 R2Q=100 # less eth0-2.root # root class contenente il bandwidth totale RATE=64kbit # less eth0-2:10.www # classe per il traffico HTTP in uscita RATE=16kbit # 2 K/Bs CEIL=16kbit LEAF=sfq RULE=*:80, # less eth0-2:20.smtp # classe per il traffico SMTP in uscita RATE=16kbit # 2 K/Bs CEIL=16kbit BURST=16k LEAF=sfq RULE=*:25 # less eth0-2:30.ftp # classe per il traffico FTP in uscita RATE=8kbit # 1 K/Bs CEIL=8kbit BURST=8k LEAF=sfq RULE=*:20 RULE=*:21

21 # less eth0-2:40.dfl # default class per il traffico non classificato RATE=1Kbit CEIL=1Kbit BURST=15k LEAF=sfq Attenzione specificando il valore CEIL si può assegnare una banda inutilizzata della root class, questo permette di ottenete valori di banda superiori a quelli indicate con il parametro RATE. Un altro tipo di configurazione permette invece di suddividere la banda assegnandone maggiormente ad alcuni host rispetto ad altri. Nel caso dell accesso ai sito web (porta 80): # less eth0-2.root # root class contenente il bandwidth totale RATE=64kbit # less eth0-2:10.www # classe per il traffico uscita dell host RATE=8kbit # 1 K/Bs CEIL=8kbit LEAF=sfq RULE=*:80, # less eth0-2:20.www # classe per il traffico uscita dell host RATE=16kbit # 2 K/Bs CEIL=16kbit LEAF=sfq RULE=*:80, # less eth0-2:30.www # classe per il traffico uscita dell host RATE=32kbit # 4 K/Bs CEIL=32kbit LEAF=sfq RULE=*:80, Se volessimo invece differenziare la banda sulla base dell host di destinazione potremmo configurare la coda htb in questo modo: # less eth0-2.root # root class contenente il bandwidth totale RATE=64kbit # less eth0-2:10.www # classe per il traffico in ingesso da RATE=8kbit # 1 K/Bs CEIL=8kbit RULE= :80, Da questo sito si scarica a ~ 1KB/s # less eth0-2:20.www

22 # classe per il traffico in ingresso da RATE=32kbit # 4 K/Bs CEIL=32kbit RULE= :80, Da questo sito si scarica a ~ 4KB/s. Notare la virgola finale indica il source address Questa configurazione permette di limitare la banda verso i server web di questi specifici host, verso tutti gli altri si viaggerà a banda piena. Anche per il metodo con htb esiste un modulo di webmin analogo che permette la configurazione via web delle regole di filtro. # wget Installazione e configurazione sono del tutto simili a quelli visti per il modulo CBQ. Controllo della banda in ingresso Proviamo adesso a effettuare shaping solo sulla banda in ingresso, ad esempio se volessimo evitare che tutta la nostra banda venga esaurita da un webserver a cui gli utenti internet accedono possiamo effettuare lo shaping, allo stesso modo visto prima ma in questo caso agiremo sull interfaccia esterna, nel nostro caso ippp0, che è quella effettivamente esposta su internet. Vediamo gli script: # cd /etc/sysconfig/htb # less ippp0 # default ID per il traffico non classificato DEFAULT=30 R2Q=100 # less ippp0-2.root # root class contenente il bandwidth totale RATE=64kbit # less ippp0-2:10.www # classe per il traffico HTTP in ingresso RATE=16kbit # 2 K/Bs CEIL=16kbit LEAF=sfq RULE=*:80, # indica il SOURCE IP Con questa semplice regola tutto il traffico proveniente da internet verso il mio server web, posto per il nostro test su IP dinamico su linea ISDN, viene limitato a 16 kbit, al massimo 2KB. Come possiamo effettivamente verificare se provassimo a scaricare da un accesso esterno la nostra velocità di download non supererebbe i 2 KBs. # wget :07: => `file.exe' Connecting to :80... connected. HTTP request sent, awaiting response OK

23 Length: 122,342 [application/x-msdos-program] 96% [========================================================================= ============> ] 118, K/s ETA 00 Verifichiamo anche che lo shaper stia effettivamente tagliando la banda: # htb stats ### ippp0: queueing disciplines qdisc htb 1: r2q 10 default 0 direct_packets_stat 0 Sent bytes 78 pkts (dropped 3, overlimits 129) backlog 13p Estendiamo i concetti appena visti ad una configurazione completa per il controllo e la limitazione della banda in ingresso verso i servizi web, come potrebbero essere quelli di una server farm, con priorizzazione del traffico web al di sopra di tutti gli altri. Potrebbe avere una configurazione di questo tipo: 512 Kbit di banda entrante suddivisa in questo modo: # cd /etc/sysconfig/htb L interfaccia connessa ad internet è la eth1 che passa per un normale router ADSL con banda 2Mbit/512Kbit. # less eth1 # default ID per il traffico non classificato DEFAULT=30 R2Q=100 # less eth1-2.root # root class contenente il bandwidth totale in ingresso RATE=512KBit

24 # less eth1-2:10.www # classe per il traffico HTTP in ingresso RATE=256kbit CEIL=100kbit LEAF=sfq RULE=*:80, # less eth1-2:20.ftp # classe per il traffico FTP in ingresso RATE=128kbit CEIL=64kbit LEAF=sfq RULE=*:80, # less eth1-2:30.smtp # classe per il traffico SMTP in ingresso RATE=64kbit CEIL=16kbit LEAF=sfq RULE=*:25, # less eth1-2:40.pop3+imap # classe per il traffico POP3+IMAP in ingresso RATE=64kbit CEIL=16kbit LEAF=sfq RULE=*:110, RULE=*:143, In questo caso di cui sono state mostrate le configurazioni per esteso, è stato scelto di assegnare la banda eventualmente disponibile (parametro CEIL), in maggioranza sempre al server web, quelle che si presume debba essere il servizio reso maggiormente disponibile. Va da sé che ognuno può utilizzare queste configurazioni per gestire come meglio crede lo shaping in ingresso verso i propri servizi. Configurazione di HTB con il marking (mangle table) Vediamo anche un esempi di configurazione che preveda l uso della mangle table, che consente una maggior flessibilità per il controllo di source e destination port/address. Vediamo sempre per il controllo della banda in ingresso: # less ippp0 # default ID per il traffico non classificato DEFAULT=30 R2Q=100 # less ippp0-2.root # root class contenente il bandwidth totale RATE=64kbit # less ippp0-2:10.www # classe per il traffico HTTP in uscita

25 RATE=16kbit # 2 K/Bs CEIL=16kbit LEAF=sfq RULE=*:80, MARK=1 Impostiamo la mangle table per tutto il traffico http (source destination): # iptables -A PREROUTING -t mangle -p tcp --sport 80 --j MARK --set-mark 1 # iptables -A PREROUTING -t mangle -p tcp --dport 80 --j MARK --set-mark 1 # iptables -L -n -t mangle MARK tcp / /0 tcp spt:80 MARK set 0x1 MARK tcp / /0 tcp dpt:80 MARK set 0x1 Test dello shaping con Iperf Per poter verificare bene la banda a disposizione e verificare che questa venga limitata effettivamente, andiamo oltre il dato fornitoci come download rate da wget, ed utilizziamo iperf, il noto tool client/server pe effettuare misurazioni di banda. E necessario installare ed avviare su di un punto remoto, al di fuori della nostra rete, iperf come server in modo da poter effettuare i test. server:~# iperf -s Facciamo il test dal client, ricordandoci che la nostra banda è quella di una connessione ISDN a canale singolo, quindi ci aspettiamo 64k kbits, bit più bit meno. client:~# iperf -c Client connecting to , TCP port 5001 TCP window size: 16.0 KByte (default) [ 5] local port 4618 connected with port 5001 [ 5] sec 104 KBytes 64.8 Kbits/sec Risorse Shorewall traffic shaping Introduzione Vediamo anche utilizzando Shorewall come è possbile effettuare il traffic shaping. La nuova versione 3.0 ben lo supporta, inserendo alcuni file ad hoc: tcdevices, tcclasses e tcrules. Nel caso in cui si volesse interfacciare le proprie regole di tc in modo passivo basta abilitare in shorewall.conf le direttive: TC_ENABLED=Yes CLEAR_TC=Yes

26 Ed inserire i propri comandi in un script dal nome /etc/shorewall/tcrules. Questo argomento è stato trattato in precedenza nella sezione relativa all uso del Wondershaper. Nel caso in cui si volesse invece configurare tc usando i file e le regole di shorewall si può usare una configurazione come quella di seguito presentata. Configurazione tcdevices #INTERFACE IN-BANDWITH# download OUT-BANDWIDTH#upload ippp0 64kbit 64kbit #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE tcclasses ########################################################## ##################### #INTERFACE MARK RATE CEIL PRIORITY OPTIONS ippp0 1 20kbit 5kbit 1 tcp-ack ippp0 2 15kbit 5kbit 3 ippp0 3 10kbit full 3 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE tcrules ########################################################## ##################### #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) 1:P / /0 icmp echo-request 1:P / /0 icmp echo-reply 2:P /0 all 2:P $FW /0 all 3:P /0 all #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE Verifica regole con shorewall # shorewall show tc Shorewall Traffic Control at neo - lun gen 2 14:50:14 CET 2006 Device eth0: qdisc pfifo_fast 0: bands 3 priomap Sent bytes pkts (dropped 0, overlimits 0) Device ippp0: qdisc pfifo_fast 0: bands 3 priomap Sent bytes 6383 pkts (dropped 0, overlimits 0) # shorewall show mangle Chain tcpre (1 references) pkts bytes target prot opt in out source destination 0 0 MARK icmp -- * * / /0 icmp type 8 MARK set 0x1 0 0 MARK icmp -- * * / /0 icmp type 0 MARK set 0x1