SlideShare ist ein Scribd-Unternehmen logo
1 von 133
ALMA MATER STUDIORUM – UNIVERSITÀ DI BOLOGNA
                SEDE DI CESENA
  SECONDA FACOLTÀ DI INGEGNERIA CON SEDE A
                   CESENA
     CORSO DI LAUREA IN INGEGNERIA DELLE
             TELECOMUNICAZIONI




               TITOLO DELL’ELABORATO

FUNZIONALITÀ AVANZATE PER L’INOLTRO
 DI PACCHETTI IP IN SISTEMI OPERATIVI
                LINUX




                          Elaborato in

LABORATORIO DI RETI DI TELECOMUNICAZIONI
                  L-A




    Relatore                                   Presentato da

  Cerroni Walter                           Zangheri Filippo




                          Sessione II
                   Anno Accademico 2005/2006
A Elisa,
luce dei miei occhi
Indice




Indice

 1. Introduzione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
 2. Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
            2.1 Reti informatiche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
                       2.1.1 Modello ISO/OSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
                                  2.1.1.1 Modularità. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
                                  2.1.1.2 Strato 1: fisico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
                                  2.1.1.3 Strato 2: linea. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
                                  2.1.1.4 Strato 3: rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
                                  2.1.1.5 Strato 4: trasporto. . . . . . . . . . . . . . . . . . . . . . . . . . 5
                                  2.1.1.6 Strato 5: sessione. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
                                  2.1.1.7 Strato 6: presentazione. . . . . . . . . . . . . . . . . . . . . . 6
                                  2.1.1.8 Strato 7: applicazione. . . . . . . . . . . . . . . . . . . . . . . 6
                       2.1.2 Architettura TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
                                  2.1.2.1 Strato di collegamento. . . . . . . . . . . . . . . . . . . . . . . 7
                                  2.1.2.2 Strato di rete: protocollo IP. . . . . . . . . . . . . . . . . . . 7
                                  2.1.2.3 Strato di trasporto. . . . . . . . . . . . . . . . . . . . . . . . . . 9
                                  2.1.2.4 Strato di applicazione. . . . . . . . . . . . . . . . . . . . . . . 10
            2.2 Routing nelle reti IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
                       2.2.1 Protocollo ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
                       2.2.2 Consegna: diretta e indiretta. . . . . . . . . . . . . . . . . . . . . . . . . 12
                       2.2.3 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
                       2.2.4 Decisione di routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
                       2.2.5 Protocolli e algoritmi di routing. . . . . . . . . . . . . . . . . . . . . . 15
                                  2.2.5.1 Algoritmi a cammino minimo. . . . . . . . . . . . . . . . 16
            2.3 Routing in Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
            2.4 Policy Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
 3. Kernel Linux e pacchetti IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
            3.1 Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
            3.2 Kernel Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


                                                            i
Indice




                    3.2.1 Scheduler dei processi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
                    3.2.2 Gestione della memoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
                    3.2.3 File System Virtuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
                    3.2.4 Comunicazione fra processi. . . . . . . . . . . . . . . . . . . . . . . . . 23
                    3.2.5 Sottosistema di rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
                               3.2.5.1 Dispositivi di rete. . . . . . . . . . . . . . . . . . . . . . . . . . 23
                               3.2.5.2 Implementazione delle funzionalità di rete. . . . . . 24
          3.3 Ricezione di pacchetti IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
                    3.3.1 Dalla scheda al kernel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
                    3.3.2 Processamento IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
                    3.3.3 Processamento locale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
          3.4 Instradamento IP in dettaglio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
                    3.4.1 Table lookup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
                    3.4.2 Attributi delle route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
                    3.4.3 Tabelle di routing multiple. . . . . . . . . . . . . . . . . . . . . . . . . . 30
                    3.4.4 Policy Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
          3.5 Controllo del traffico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
          3.6 Tunneling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4. Strumenti per il networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
          4.1 Netfilter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
                    4.1.1 Punti di hook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
          4.2 Iptables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
                    4.2.1 Tabelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
                    4.2.2 Configurazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
                    4.2.3 Match. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
                    4.2.4 Casi di interesse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
                               4.2.4.1 Match random. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
                               4.2.4.2 Match tos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
                               4.2.4.3 Target MARK. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
                               4.2.4.4 Target CLASSIFY. . . . . . . . . . . . . . . . . . . . . . . . . 45
                               4.2.4.5 Altri usi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
                    4.2.5 Estensioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
                               4.2.5.1 Aggiunta di un’estensione: modulo random. . . . . 47

                                                         ii
Indice




         4.3 Iproute2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
                   4.3.1 Funzionalità avanzate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
         4.4 Comando ip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
                   4.4.1 Gestione interfacce di rete. . . . . . . . . . . . . . . . . . . . . . . . . . . 53
                              4.4.1.1 ip link set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
                              4.4.1.2 ip link show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
                   4.4.2 Gestione indirizzi di rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
                              4.4.2.1 ip addr add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
                              4.4.2.2 ip addr delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
                              4.4.2.3 ip addr flush. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
                              4.4.2.4 ip addr show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
                   4.4.3 Gestione tabelle di routing. . . . . . . . . . . . . . . . . . . . . . . . . . 57
                              4.4.3.1 ip route add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
                              4.4.3.2 ip route change. . . . . . . . . . . . . . . . . . . . . . . . . . . 61
                              4.4.3.3 ip route replace. . . . . . . . . . . . . . . . . . . . . . . . . . . 61
                              4.4.3.4 ip route delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
                              4.4.3.5 ip route show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
                              4.4.3.6 ip route flush. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
                              4.4.3.7 ip route get. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
                   4.4.4 Gestione delle politiche di instradamento. . . . . . . . . . . . . . 64
                              4.4.4.1 ip rule add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
                              4.4.4.2 ip rule delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
                              4.4.4.3 ip rule flush. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
                              4.4.4.4 ip rule show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
                   4.4.5 Gestione tunnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
                              4.4.5.1 ip tunnel add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
                              4.4.5.2 ip tunnel change. . . . . . . . . . . . . . . . . . . . . . . . . . . 68
                              4.4.5.3 ip tunnel delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
                              4.4.5.4 ip tunnel show. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
                              4.4.5.5 Esempi di tunnel. . . . . . . . . . . . . . . . . . . . . . . . . . . 69
         4.5 Comando tc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
                   4.5.1 Discipline di accodamento. . . . . . . . . . . . . . . . . . . . . . . . . . 71
                              4.5.1.1 Token Bucket Filter. . . . . . . . . . . . . . . . . . . . . . . . 72

                                                       iii
Indice




                                4.5.1.2 tc qdisc add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
                                4.5.1.3 tc qdisc change. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
                                4.5.1.4 tc qdisc replace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
                                4.5.1.5 tc qdisc link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
                                4.5.1.6 tc qdisc delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
                                4.5.1.7 tc qdisc show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
                     4.5.2 Classi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
                                4.5.2.1 tc class add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
                                4.5.2.2 tc class change. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
                                4.5.2.3 tc class replace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
                                4.5.2.4 tc class show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
                     4.5.3 Filtri. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
                                4.5.3.1 tc filter add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
                                4.5.3.2 tc filter change. . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
                                4.5.3.3 tc filter replace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
                                4.5.3.4 tc filter delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
                                4.5.3.5 tc filter show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5. Esperimenti svolti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
           5.1 Informazioni preliminari. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
                     5.1.1 Preparazione hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
                     5.1.2 Preparazione software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
           5.2 Considerazioni iniziali: ripartizione del traffico. . . . . . . . . . . . . . . . . 82
                     5.2.1 Un passo indietro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
           5.3 Esperimento 1. Bilanciamento del carico. . . . . . . . . . . . . . . . . . . . . . 83
                     5.3.1 Topologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
                     5.3.2 Funzionamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
                     5.3.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
                                5.3.3.1 Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
                                5.3.3.2 Inoltratori. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
                                5.3.3.3 Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
                                5.3.3.4 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
                     5.3.4 Altre configurazioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
                                5.3.4.1 Sbilanciare il carico. . . . . . . . . . . . . . . . . . . . . . . . 89

                                                         iv
Indice




                     5.3.5 Esecuzione esperimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
                     5.3.6 Aumentare i percorsi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
                     5.3.7 Bilanciamento sulla base dei percorsi. . . . . . . . . . . . . . . . . . 92
           5.4 Considerazione ulteriore: ordinare i flussi. . . . . . . . . . . . . . . . . . . . . . 93
           5.5 Esperimento 2. Policy Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
                     5.5.1 Topologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
                     5.5.2 Funzionamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
                                5.5.2.1 Politica di instradamento. . . . . . . . . . . . . . . . . . . . 95
                     5.5.3 Configurazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
                                5.5.3.1 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
                     5.5.4 Esecuzione esperimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
                     5.5.5 Aumentare i percorsi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
                     5.5.6 Policy Routing e ripartizione del carico. . . . . . . . . . . . . . . . 99
                     5.5.7 Policy Routing senza iptables. . . . . . . . . . . . . . . . . . . . . . . 100
           5.6 Passo in avanti: assegnare la banda ai flussi. . . . . . . . . . . . . . . . . . . 100
           5.7 Esperimento 3. Limitazione della banda. . . . . . . . . . . . . . . . . . . . . . 101
                     5.7.1 Topologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
                     5.7.2 Funzionamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
                                5.7.2.1 Assegnazione della banda. . . . . . . . . . . . . . . . . . 103
                     5.7.3 Configurazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
                                5.7.3.1 Sorgente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
                                5.7.3.2 Inoltratore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
                                5.7.3.3 Destinazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
                                5.7.3.4 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
                     5.7.4 Altre configurazioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
                                5.7.4.1 Bloccare le bande. . . . . . . . . . . . . . . . . . . . . . . . . 107
                     5.7.5 Esecuzione esperimento. . . . . . . . . . . . . . . . . . . . . . . . . . . 109
                     5.7.6 Classificazione dei pacchetti con tc. . . . . . . . . . . . . . . . . . 111
                     5.7.7 Limitazione della banda per ogni interfaccia. . . . . . . . . . . 111
                     5.7.8 Aumento della complessità. . . . . . . . . . . . . . . . . . . . . . . . . 111
           5.8 Allegati. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
 6. Conclusioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
 Bibliografia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

                                                          v
Capitolo 1 - Introduzione




Capitolo 1. Introduzione

       Essendo open-source, Linux ha sempre goduto del contributo di tantissimi
sviluppatori, che nel tempo hanno donato al kernel le funzionalità derivanti dalle
loro conoscenze. Questo ha fatto in modo che si sviluppasse un sistema operativo
(liberamente utilizzabile e modificabile) estremamente flessibile e dotato di
caratteristiche d’avanguardia che lo pongono in una posizione di tutto rispetto nello
scenario dei sistemi operativi, commerciali e non.
Le necessità che gli amministratori di reti informatiche hanno oggi, nell’applicare le
politiche desiderate all’interno delle reti gestite, sono sempre più numerose e
riguardano sempre di più la gestione ottimale del traffico. Per soddisfare esigenze
sempre più dettagliate, sul mercato si trovano numerose soluzioni commerciali, più
o meno onerose e affidabili.
Con il passare degli anni, Linux ha costantemente visto accresciute e potenziate le
proprie funzionalità di rete, che al giorno d’oggi hanno raggiunto un elevato livello
di maturità, sia progettuale che implementativa. È importante notare, tuttavia, che si
tratta di un sistema operativo molto dinamico, in costante fase di miglioramento e
potenziamento.
In questo elaborato si andranno a discutere alcuni esperimenti eseguiti al fine di
comprendere quali siano le potenzialità che il kernel di Linux offre, per ciò che
concerne alcuni degli aspetti avanzati di gestione del traffico di rete.




                                           1
Capitolo 1 - Introduzione




                            2
Capitolo 2 - Routing




Capitolo 2. Routing

2.1 Reti informatiche
        Una rete informatica è un sistema di risorse finalizzate alla interconnessione
di un certo numero di calcolatori per permettere loro di scambiarsi informazioni. In
particolare le informazioni trasmesse dai calcolatori viaggiano raggruppate in
pacchetti di dati.
Le reti si caratterizzano almeno per:


        1. mezzi di trasmissione usati: segnali elettrici su cavo di conduttori,
            radiazione elettromagnetica guidata (fibra ottica) o in spazio libero (onde
            radio) con tecniche di trasmissione più o meno direttive a seconda che si
            tratti di collegamenti satellitari, ponti radio o reti locali senza fili
            (Wireless LAN);
        2. topologia: connessione a stella, a maglia più o meno completa, a bus, ad
            anello;
        3. protocolli di comunicazione usati.


A seconda del grado di complessità, le reti possono essere suddivise in sottoreti e
possono avvalersi di diversi mezzi di trasmissione, nonché di diverse topologie e
anche differenti protocolli.



2.1.1 Modello ISO/OSI
        OSI, acronimo per Open Systems Interconnection[1], è un’emanazione
dell’ISO, ente internazionale per gli standard. I suoi lavori cominciarono nel 1976 e
portarono ad un modello di riferimento (Reference Model) chiamato OSI-RM, che è
standard internazionale dal 1983 (ISO 7498).
Il gruppo di lavoro nacque con lo scopo di definire uno schema modulare e aperto
per la realizzazione di meccanismi di comunicazione automatici. Le finalità pratiche
che si intendevano raggiungere puntavano a limitare la proliferazione di protocolli

                                           3
Capitolo 2 - Routing




proprietari incapaci di interoperare con altri sistemi e fornire una visione del
problema a blocchi.



2.1.1.1 Modularità
        Nel modello ISO/OSI il problema della comunicazione viene suddiviso in
sette blocchi funzionali, ognuno dei quali dedicato a un problema specifico. Ogni
blocco riceve informazioni dallo strato inferiore e comunica la propria elaborazione
al blocco successivo. I blocchi, chiamati livelli o strati, formano una struttura a pila,
in quanto la comunicazione fluisce dagli strati superiori verso quelli inferiori nel
sistema trasmittente e percorre la strada opposta nel sistema ricevente.



2.1.1.2 Strato 1: fisico
        Alla base della pila OSI si trova lo strato fisico. Il suo scopo è attivare,
mantenere e disattivare la connessione fisica fra due entità di livello 2. Questo strato
è responsabile della definizione di tutti gli aspetti fisici relativi alla comunicazione.
In sostanza si deve fare in modo che l’informazione “1” trasmessa da un capo del
mezzo arrivi tale anche dall’altro capo.
In questo strato si trovano le definizioni meccaniche dei connettori, le specifiche
relative ai segnali elettrici, il significato che viene loro attribuito, le combinazioni e
le sequenze di segnali all’interfaccia necessarie al fine di regolarne il
funzionamento. Questo è l’unico strato che riguarda direttamente l’hardware, infatti
i successivi livelli trattano il problema da un punto di vista logico, operando sui
flussi di bit piuttosto che sui segnali elettrici.



2.1.1.3 Strato 2: linea
        Questo strato si occupa di attivare, mantenere e disattivare la connessione
fisica fra due entità di strato 3 e renderne affidabile il collegamento diretto (punto-
punto). Tipicamente le attività svolte sono:


        1. strutturazione dei flussi di dati in unità di dialogo chiamate trame;
        2. controllo e gestione degli errori di trasmissione;


                                              4
Capitolo 2 - Routing




       3. controllo di flusso: accorda la velocità del trasmettitore alla capacità di
           elaborazione del ricevitore;
       4. controllo di sequenza: verifica che le trame ricevute siano nella giusta
           sequenza;
       5. gestione del protocollo di accesso per un collegamento punto-
           multipunto.



2.1.1.4 Strato 3: rete
       Questo strato provvede a definire il concetto di rete, intesa come insieme di
sistemi autonomi che comunicano armonicamente entro un mezzo fisico di
trasmissione. Ha come scopo quello di far giungere le unità di informazione
(pacchetti) al destinatario, scegliendo la strada da percorrere attraverso la rete: si
occupa dunque del problema della commutazione dei pacchetti e la funzione che
svolge è chiamata routing (instradamento).
Occorre individuare i destinatari deve, quindi, essere previsto un sistema di
indirizzamento logico. Nel caso in cui si voglia costituire una rete unica che unisca
logicamente tutte le sottoreti, occorre che lo schema di indirizzamento sia
universale; occorre inoltre un protocollo di interconnessione di reti: da qui la
definizione di IP (Internet Protocol).



2.1.1.5 Strato 4: trasporto
       Questo strato ha lo scopo di fornire un canale sicuro da capo a capo (end-to-
end), svincolando gli strati superiori da tutte le problematiche di rete. Un compito
tipico è l’adattamento della dimensione delle sequenze di dati fornite dagli strati
superiori (file) a quella richiesta dalle reti (pacchetti). Viene denominata funzione di
pacchettizzazione e opera in entrambe le direzioni (frammentazione e
riassemblaggio).
Questo strato può avere altre funzioni, come controllo d’errore, di flusso, gestione
dei dati prioritari. Dal momento che non tutte le applicazioni hanno le stesse
esigenze in fatto di trasmissione dei dati, si definiscono due principali classi di
trasporto: connection-oriented (orientato alla connessione) e connectionless (non
orientato alla connessione)..

                                           5
Capitolo 2 - Routing




2.1.1.6 Strato 5: sessione
        Suddivide il dialogo fra applicazioni remote in unità logiche chiamate
sessioni. Una sessione deve essere individuata da opportuni parametri univoci,
aperta, eventualmente interrotta e ripresa per far fronte a vari eventi catastrofici:
perdita di dati, caduta della linea, momentaneo crash di uno dei due interlocutori.
Permette la chiusura ordinata del dialogo con la garanzia che tutti i dati trasmessi
siano arrivati a destinazione.



2.1.1.7 Strato 6: presentazione
        Adatta il formato dei dati usato dai due interlocutori (applicazioni)
preservandone il significato, attraverso l’uso di una sintassi di trasferimento.


2.1.1.8 Strato 7: applicazione
        È l’utente della rete e perciò non fornisce servizi a nessuno. Rappresenta un
programma applicativo che comunica con applicazioni remote nello svolgimento
dei propri compiti.



2.1.2 Architettura TCP/IP
        I protocolli attuali sono generalmente modulari, ma ciò non significa che
aderiscano pienamente al modello ISO/OSI, alcuni infatti possono racchiudere le
funzionalità di più livelli in uno unico oppure essere privi di alcuni livelli.
Oggi ISO/OSI è considerato un buon modello concettuale e un formidabile
strumento di insegnamento, ma non è mai diventato la base universale su cui
scrivere qualunque protocollo di comunicazione.
La famiglia di protocolli TCP/IP nasce negli anni ’70 del XX sec. da una ricerca
finanziata dal Dipartimento della Difesa statunitense e sono gli stessi protocolli
usati al giorno d’oggi in Internet[1]. La loro definizione è praticamente
contemporanea alla stesura del modello di riferimento OSI e hanno in comune con
esso la modularità.




                                            6
Capitolo 2 - Routing




2.1.2.1 Strato di collegamento
       L’architettura TCP/IP prevede un primo strato denominato collegamento, il
quale espleta le funzioni degli strati 1 e 2 di OSI. I protocolli che fanno parte della
famiglia TCP/IP possono appoggiarsi su una grande varietà di protocolli di
collegamento: PPP, ATM, IEEE 802.11, ma il più diffuso per le reti locali è
Ethernet. Questo è diviso in due sottolivelli, ognuno dei quali implementa uno
strato del modello OSI: Logical Link Control (LLC) e Media Access Control
(MAC). Il primo è dedicato alle operazioni logiche del protocollo, mentre il
secondo provvede alla comunicazione diretta con l’hardware.



2.1.2.2 Strato di rete: protocollo IP
       Il protocollo IP è definito dal RFC 791 (1981). Fu progettato per sistemi
interconnessi a commutazione di pacchetto ed implementa le funzionalità dello
strato di rete nell’architettura TCP/IP. Si prende carico della trasmissione di
datagrammi da sorgente a destinazione, identificati secondo uno schema di
indirizzamento a lunghezza fissa (32 bit). Se necessario procede alla
frammentazione dei datagrammi in pacchetti, e li riassembla.
IP è un protocollo non orientato alla connessione, esso è esplicitamente limitato per
fornire le sole funzioni necessarie alla consegna dei pacchetti: non sono previsti
meccanismi per l’aumento dell’affidabilità, né per il controllo di flusso o di
sequenza, non fornisce insomma un servizio di comunicazione affidabile, ma di tipo
best effort. L’affidabilità – ove necessaria – è demandata ai protocolli che si
appoggiano su IP. Oggi Internet si appoggia alla versione 4 di IP (IPv4).




                                          7
Capitolo 2 - Routing




      Figura 1. Formato di un generico pacchetto IP


      1. Version (versione): indica la versione utilizzata di IP, attualmente la
          versione 4 (IPv4).
      2. IHL (IP Header Length): lunghezza dell’intestazione, espressa in parole
          di 32 bit.
      3. Type of Service: indicazione sul tipo di servizio richiesto per questo
          pacchetto. È controverso, in quanto ha ripetutamente subito variazioni di
          significato negli anni. Attualmente è anche chiamato campo DS
          (Differentiated Services), e comprende 6 bit, come mostrato in figura,
          mentre gli ultimi due sono attualmente inutilizzati nelle applicazioni
          standard.
      4. Total Length: lunghezza totale del datagramma, espressa in bytes.
      5. Identification: valore intero che identifica univocamente un datagramma,
          si usa durante il riassemblaggio per risalire a quale datagramma
          appartengano i pacchetti (o frammenti).
      6. Flags: bit 0: non usato (sempre zero); bit 1 (Don’t Fragment): se settato
          indica che non si può frammentare il datagramma; bit 2 (More
          Fragments): se settato indica che quello corrente non è l’ultimo
          frammento di un datagramma frammentato.



                                        8
Capitolo 2 - Routing




        7. Fragment Offset: indica qual è la distanza del frammento corrente
            dall’inizio del datagramma, espressa in parole da 64 bit (dimensione del
            frammento elementare).
        8. Time To Live: tempo massimo di permanenza del datagramma nella rete,
            è decrementato ogni volta che si attraversa un nodo intermedio. Un
            datagramma con TTL pari a zero viene scartato.
        9. Protocol: indica il protocollo di livello superiore a cui appartengono i
            dati trasportati.
        10. Header Checksum: controllo di errore della sola intestazione, viene
            ricalcolato da ogni nodo attraversato dal datagramma.
        11. Source (Destination) Address: indirizzo sorgente (destinazione) del
            datagramma.
        12. Options: campo di lunghezza variabile contenente informazioni
            opzionali.
        13. Padding (riempimento): bit privi di significato in numero tale da fare in
            modo che il campo Options sia con certezza multiplo di 32 bit.



2.1.2.3 Strato di trasporto
        Fornisce servizio di connettività fra applicazioni che non risiedono sulla
stessa macchina. Lo fa attraverso l’uso delle porte, che servono a differenziare i
flussi di dati.
Il protocollo di trasporto orientato alla connessione è il TCP (Transmission Control
Protocol) (che implementa anche le funzionalità dello strato di sessione OSI), esso
permette l’instaurazione di una comunicazione affidabile, nel senso che si
preoccupa di garantire che tutti i dati siano consegnati al destinatario nella giusta
sequenza, senza perdite né ripetizioni. Viene utilizzato tutte le volte che in un
trasferimento di dati è importante la loro correttezza e che arrivino tutti quanti in
sequenza.
Il protocollo UDP (User Datagram Protocol) non è invece orientato alla
connessione, non instaura nessuna connessione: quando è pronto ad inviare i dati, lo
fa senza mai preoccuparsi della corretta ricezione. L’unico meccanismo di
affidabilità che implementa è un minimo controllo degli errori. Questo protocollo è


                                          9
Capitolo 2 - Routing




utilizzato soprattutto nelle trasmissioni audio/video attraverso la rete, nelle quali
non è di vitale importanza che tutti i pacchetti arrivino a destinazione, ma una
buona percentuale di essi, tale da permettere la fruizione del contenuto
multimediale da parte di un essere umano.



2.1.2.4 Strato di applicazione
        Lo strato che utilizza i servizi dello strato di trasporto è quello di
applicazione. Questo, come nel modello OSI, rappresenta il processo che fa uso
della rete per svolgere le proprie attività.


La famiglia di protocolli TCP/IP prevede anche l’esistenza di protocolli
direttamente incapsulati in IP, che non fanno uso di protocolli di trasporto. Questi
sono ad esempio ICMP (usato per la segnalazione) e OSPF (protocollo di routing).




Figura 2. Architetture OSI e TCP/IP a confronto




                                               10
Capitolo 2 - Routing




2.2 Routing nelle reti IP
       Il meccanismo che decide quale è il tragitto che un pacchetto deve seguire
per andare dal mittente al destinatario è chiamato routing[2] (instradamento).
Essendo IP un protocollo non orientato alla connessione, ogni pacchetto è instradato
in maniera indipendente dagli altri, ciò significa che i diversi pacchetti che
compongono uno stesso messaggio possono arrivare a destinazione attraverso
sequenze di nodi differenti; inoltre i pacchetti possono arrivare a destinazione in
maniera non ordinata, o alcuni di questi non arrivare affatto. le esigenze di integrità
e ordine non sono obiettivi dei meccanismi di routing, poiché i processi di routing
hanno visibilità solo dei singoli pacchetti e non di un messaggio nel suo complesso.
Coloro che effettuano l’instradamento dei pacchetti, e che tengono connesse l’una
all’altra le reti IP, sono macchine dette router.
Il metodo di instradamento utilizzato dal protocollo IP è alquanto semplice, esso
consiste nel trasferire il pacchetto da un nodo all’altro, fino a quello di destinazione,
attraverso salti (hop) successivi.



2.2.1 Protocollo ARP
       Il protocollo ARP (Address Resolution Protocol), come specificato da RFC
826, è un protocollo che fornisce la "mappatura" tra l'
                                                      indirizzo IP a 32bit (4byte) di
un’interfaccia e il suo indirizzo MAC, l'
                                        indirizzo fisico a 48bit (6 byte).
ARP è utilizzato in una rete di calcolatori che utilizzi il protocollo IP sopra una rete
di livello di collegamento che supporti il servizio di broadcast. Se questo servizio
non è disponibile, come ad esempio in ATM, devono essere utilizzati altri
meccanismi.
L'
 host che vuole conoscere l’indirizzo MAC di un altro host, di cui conosce
l'
 indirizzo IP, invia una richiesta ARP (ARP-request), contenente l'
                                                                  indirizzo IP
dell' di destinazione. La richiesta viene incapsulata in una trama di livello di
    host
collegamento indirizzata all’indirizzo broadcast di collegamento (per Ethernet è
FF:FF:FF:FF:FF:FF), così tutti i calcolatori della sottorete ricevono la richiesta.
In ciascuno di essi il protocollo ARP verifica se viene richiesto il proprio indirizzo
IP. L'
     host di destinazione che riconoscerà il proprio IP nel pacchetto di ARP-


                                           11
Capitolo 2 - Routing




request, provvederà ad inviare una risposta (ARP-reply) in unicast (un solo
destinatario) all'
                 indirizzo MAC sorgente. L’host che aveva inviato la richiesta, potrà
leggere l’indirizzo MAC desiderato nel campo indirizzo sorgente della trama di
risposta.
In questo modo, ogni host può scoprire l'
                                        indirizzo fisico degli altri host sulla stessa
sottorete.
Bisogna osservare che il protocollo ARP viene usato tutte le volte che un host
collegato ad una LAN deve inviare un messaggio ad un host sulla stessa LAN di cui
conosce unicamente l'
                    indirizzo di livello rete (IP), quindi lavora solo in sottoreti
locali (non può attraversare router).
In ogni calcolatore, il protocollo ARP tiene traccia delle risposte ottenute in una
apposita cache, per evitare di utilizzare ARP prima di inviare ciascun pacchetto. Le
voci della cache ARP vengono cancellate dopo un certo tempo di inutilizzo.



2.2.2 Consegna: diretta e indiretta
        La logica di funzionamento del routing è la seguente: il mittente – che è a
conoscenza del proprio indirizzo, della sottorete IP in cui è situato e dell’indirizzo
del destinatario – è in grado di sapere se il destinatario si trova nella sua stessa
sottorete oppure no. In caso affermativo viene effettuata consegna diretta[1]: il
pacchetto viene passato al protocollo di livello sottostante (livello 2 ISO/OSI,
Collegamento), in reti di tipo Ethernet, viene trovato l’indirizzo MAC del
destinatario usando il protocollo ARP, quindi il pacchetto IP è incapsulato dentro ad
una trama Ethernet, la quale viene spedita sulla rete. In questo caso il pacchetto IP
non attraversa alcun nodo intermedio.




                                         12
Capitolo 2 - Routing




       Figura 3. Consegna diretta di un pacchetto IP


Se, al contrario, l’indirizzo del destinatario non fa parte della stessa sottorete del
mittente, il pacchetto IP viene inviato – tramite consegna diretta – ad un router, il
quale se riesce a fare consegna diretta al destinatario, la effettua, altrimenti spedisce
il pacchetto ad un altro router, e così via. Se i router sono configurati in modo che le
loro informazioni siano consistenti fra loro, il pacchetto arriverà a destinazione.
Questa è detta consegna indiretta.




       Figura 4. Consegna indiretta di un pacchetto IP



2.2.3 Router
       Un router è un dispositivo fisico – oppure software che viene eseguito su un
calcolatore – il quale determina il successivo punto della rete a cui inoltrare un


                                           13
Capitolo 2 - Routing




pacchetto, nella sua strada verso la destinazione. I router formano una struttura
interconnessa e cooperante: i datagrammi passano dall’uno all’altro finché
raggiungono quello che può consegnarli direttamente al destinatario.
In un router sono presenti due funzioni distinte: routing e inoltro[2]. La funzione
di routing permette di decidere il percorso del pacchetto ed è volta a creare e
mantenere aggiornate le tabelle di routing locali attraverso lo scambio di
informazioni con gli altri router (usando protocolli di routing) e l’elaborazione
locale (usando algoritmi di routing). Occorre che questa funzione sia
standardizzata al fine di avere coerenza nel comportamento dei router.
La funzione di inoltro opera il trasferimento del pacchetto dall’interfaccia di
ingresso a quella di uscita, per farlo si avvale di un algoritmo di inoltro, il quale
prevede 3 fasi:

       1. estrazione dell’indirizzo destinazione dall’intestazione del pacchetto;
       2. consultazione della tabella di routing (table lookup);
       3. identificazione dell’interfaccia di uscita su cui inoltrare il pacchetto .


Le tabelle di routing contengono le informazioni necessarie per l’instradamento di
tutti i pacchetti che transitano attraverso il router. Ogni voce della tabella di routing
(route) è contraddistinta dai seguenti parametri:


       1. <indirizzo di destinazione> / <maschera>
       2. interfaccia di rete da usare per raggiungerla (alla quale sarà inoltrato il
           pacchetto);
       3. metodo di consegna (diretta o indiretta);
       4. indirizzo del prossimo nodo (next hop) a cui consegnare il pacchetto in
           caso di consegna indiretta;
       5. costo (metrica) per raggiungere la destinazione usando tale percorso.


Il costo può essere associato a qualsiasi parametro del percorso di rete cui si
riferisce, ad esempio può essere proporzionale all’inverso della larghezza di banda
offerta dal canale, oppure proporzionale alla lunghezza fisica del mezzo di
comunicazione, oppure legato al costo monetario dell’utilizzo di tale canale.


                                           14
Capitolo 2 - Routing




La consultazione della tabella avviene seguendo l’algoritmo longest prefix
match[2], ovvero vengono confrontate per prime le destinazioni che presentano la
maschera di rete più lunga, in quanto rappresentano destinazioni più specifiche. Al
limite la maschera ha 32 bit a “1”, che corrisponde ad un indirizzo singolo.



2.2.4 Decisione di routing
       Per ogni pacchetto che deve instradare, la funzione di instradamento del
router deve prendere la cosiddetta decisione di routing, che consiste nel decidere
verso quale interfaccia di rete inoltrare il pacchetto, perché questo venga trasmesso
lungo il canale a cui è connessa tale interfaccia.
Il metodo tradizionale – e più semplice – di prendere la decisione di routing è il
cosiddetto routing basato sulla destinazione (destination-driven routing), secondo
cui tale decisione è presa solo in base all’indirizzo di destinazione presente
nell’intestazione del pacchetto stesso.



2.2.5 Protocolli e algoritmi di routing
       Esistono due tipi di routing[2]: quello statico e quello dinamico, in quello
statico le informazioni presenti nelle tabelle non variano nel tempo e non dipendono
dallo stato del traffico nella rete, per modificarle occorre l’intervento manuale degli
amministratori di rete. Nel routing dinamico le tabelle sono create e periodicamente
aggiornate in modo automatico. Si presta facilmente alla variazione della decisione
di instradamento in base allo stato della topologia della rete o del traffico. In questo
caso i router si scambiano informazioni riguardanti la topologia della rete
utilizzando opportuni protocolli di routing.
Il routing può essere di tipo centralizzato o distribuito[2]. Nel caso centralizzato
un nodo centrale si occupa di raccogliere le informazioni riguardanti la topologia
della rete, calcolare le tabelle di routing per ogni altro router e consegnare ad
ognuno la propria.
Nel caso distribuito ogni router calcola le proprie tabelle di routing, lo può fare sulla
base di informazioni locali (informazioni che raccoglie da solo senza scambiare dati
con altri router) oppure distribuite: si fa un’idea della topologia della rete

                                           15
Capitolo 2 - Routing




attraverso lo scambio di dati con gli altri router. Deve quindi essere previsto un
modo per fare avvenire lo scambio di queste informazioni fra router: i protocolli di
routing servono a questo.
Algoritmo e protocollo di routing di un router vanno di pari passo, infatti il secondo
è conseguenza del primo.
Alcuni algoritmi non necessitano di protocolli, in quanto non hanno bisogno di
informazioni sulla topologia della rete, sono: Flooding (inondazione, replica il
pacchetto ricevuto in ingresso su tutte le altre interfacce, con qualche
miglioramento); Deflection Routing, chiamato anche Hot Potato (patata bollente,
inoltra il pacchetto sull’interfaccia che ha il minor numero di pacchetti nella coda di
trasmissione).



2.2.5.1 Algoritmi a cammino minimo
       Esistono altri algoritmi, come Distance Vector e Link State, i quali adottano
protocolli omonimi. Questo due tipi di algoritmi appartengono alla famiglia del
routing a cammino minimo[2]: attribuiscono ad ogni collegamento di rete una
lunghezza, ottengono informazioni dagli altri router, elaborano la loro visione di
quella che è la topologia della rete, cercano il cammino minimo che collega ogni
possibile sorgente con ogni possibile destinazione. In generale esistono diversi
cammini che collegano una sorgente con una destinazione, e se si usa sempre lo
stesso (il minimo) si rischia di congestionare sempre gli stessi tratti di rete, così si
ricorre ad un uso probabilistico della tabella di routing, ovvero instradando i
pacchetti anche lungo percorsi diversi da quello minimo, questo può creare
problemi per quanto riguarda la ricezione dei pacchetti fuori sequenza, ma tale
discorso esula dagli scopi di questo elaborato.
I protocolli di tipo Distance Vector sono semplici e richiedono poche risorse, ad
ogni passo ogni router invia ai propri vicini un vettore contenente la stima della
propria distanza da tutti gli altri router della rete (quelli di cui è a conoscenza), sono
lenti nella convergenza, hanno problemi di instabilità nel caso di particolari
interruzioni dei collegamenti, non sono adatti a topologie complesse, esistono
miglioramenti che ne riducono i problemi. Per eliminarli è stata creata
un’evoluzione di questi protocolli: Path Vector.


                                           16
Capitolo 2 - Routing




I protocolli Link State hanno come scopo fondamentale quello di permettere ad
ogni router di crearsi l’immagine della rete, per prima cosa vengono scoperti i
propri vicini, poi si misura la distanza da essi, infine si inviano le proprie
informazioni sui vicini a tutti gli altri router della rete con tecnica di tipo Flooding.
Sono protocolli robusti e performanti, ma richiedono più risorse in termini di banda
e potenza di calcolo dei singoli router.
I protocolli Distance Vector RIP (Routing Information Protocol, RFC 1058), RIP2
(RFC 2453), sono trasportati da UDP.
Il protocollo Link State OSPF (Open Shortest Path First RFC 1247, OSPF2 RFC
2328), incapsulato direttamente in IP (protocollo 89), è pensato appositamente per
gestire reti di grandi dimensioni, intrinsecamente diffusive o punto-punto, separare
logicamente gli host dai router. Permette di effettuare routing gerarchico, ovvero
scomporre la rete in porzioni, ognuna delle quali è sotto il controllo di un
sottoinsieme di tutti i router, i quali si scambiano messaggi relativi solo alla zona di
competenza (area di routing). Se questi router si trovano a dover instradare
messaggi non destinati a tale zona, li passano a router di livello gerarchico
superiore, che hanno una visione sempre più d’insieme della rete e sempre meno di
dettaglio. Esistono due livelli gerarchici: Autonomous System e Area (vedere
prossimo paragrafo).



2.3 Routing in Internet
       In Internet si usa il routing gerarchico e le aree di routing sono chiamate
Autonomous System[2] (AS). Un Autonomous System si definisce come rete di
calcolatori gestita da un unico ente, nella quale vengono imposte le stesse politiche
e gli stessi protocolli di routing. Occorre però accordarsi sull’utilizzo dello stesso
protocollo all’esterno: per poter realizzare un instradamento globale e consentire a
un datagramma di uscire dall’AS di origine e giungere ad una destinazione situata al
di fuori. Normalmente gli AS sono reti di dimensioni geografiche, ulteriormente
suddivise in aree di routing.
I protocolli di routing usati all’interno di un AS sono del tipo Interior Gateway
Protocol (IGP), fanno parte di questa famiglia RIP e OSPF; mentre quelli usati
internamente fanno parte della categoria Exterior Gateway Protocol (EGP).

                                           17
Capitolo 2 - Routing




Protocolli esterni sono: EGP (Exterior Gateway Protocol), BGP (Border Gateway
Protocol), ora alla versione 4 (RFC 1771). BGP è di tipo Path Vector.
I protocolli esterni utilizzano TCP per il trasporto, in quanto devono poter contare
su una comunicazione affidabile.
Per rendere più efficiente e performante la consultazione delle tabelle di routing dei
router di Internet, ovvero quelli che interconnettono fra loro più AS, si è imposta la
regola che ogni sottorete IP deve essere contenuta completamente dentro un AS, più
specificamente nella stessa area di routing. Infatti così facendo, ogni sottorete
occupa una sola riga nelle tabelle di routing dei router di bordo.



2.4 Policy Routing
       Significa instradamento basato su politiche prestabilite[2]. Fare Policy
Routing significa estendere il concetto base di routing introducendo due ulteriori
aspetti caratterizzanti, volti ad estendere il dominio di pertinenza dell’instradamento
sia dal punto di vista tecnico che da quello logico. Questi due nuovi aspetti sono:


     1. la possibilità di discriminare i pacchetti non solo in base al loro indirizzo
         di destinazione, ma anche in base a tutti gli altri campi dell’intestazione IP,
         nonché ciò che fa parte del contenuto informativo dei datagrammi;
     2. la possibilità di definire politiche di instradamento sulle quali basare le
         decisioni di routing.


Dal secondo punto scaturisce l’esigenza di riorganizzare il database delle
informazioni di routing: esso diviene una struttura più complessa, chiamata
Routing Policy DataBase (RPDB). Il RPDB riflette le politiche di instradamento
ed è la lista delle regole di routing definite dagli amministratori di rete. Queste
regole – come detto sopra – possono essere applicate ad ogni parametro dei
datagrammi.
Con il Policy Routing si perviene alla decisione di instradamento non scorrendo le
voci di una tabella di routing secondo la lunghezza del prefisso, ma applicando una
serie di regole in ordine di priorità – imposta dagli amministratori di rete stessi.
Ogni regola consiste in un selettore ed un’azione, se il selettore corrisponde al

                                           18
Capitolo 2 - Routing




pacchetto viene eseguita l’azione. In sistemi semplici l’azione consiste spesso nello
scegliere next hop e interfaccia di uscita.
Una possibile applicazione di Policy Routing è quella di instradare pacchetti relativi
a traffici prioritari lungo percorsi ritenuti più veloci o maggiormente affidabili,
oppure impedire l’inoltro nel proprio Autonomous System di traffico proveniente
da determinate sottoreti, o ancora, instradare il traffico proveniente da determinati
indirizzi verso determinati percorsi (source-driven routing).
Da quanto detto in precedenza riguardo gli Autonomous System, cioè che in essi
vengono applicate le medesime politiche di instradamento, si vede facilmente che i
router di bordo (quelli che interconnettono più AS) eseguono Policy Routing.




                                              19
Capitolo 2 - Routing




                       20
Capitolo 3 - Kernel Linux e pacchetti IP




Capitolo 3. Kernel Linux e pacchetti IP

3.1 Linux
       Linux è un sistema operativo nato nel 1991 dal progetto personale di un
laureando in informatica dell’università di Helsinki, in Finlandia. Tale Linus
Torvalds portò avanti il progetto prima in casa propria, poi ne fece la propria tesi di
laurea, infine decise di rendere pubblici i codici sorgenti e liberamente modificabili,
sotto la licenza GPL (Gnu General Public License). Il motivo dell’esistenza di
Linux è il fatto che Torvalds sentì il bisogno di utilizzare anche sul proprio
calcolatore domestico (PC con processore Intel 80386) le applicazioni di cui
usufruiva in ambiente accademico, che erano eseguite su calcolatori dotati del
sistema operativo Minix, discendente di Unix.
Da subito il progetto entusiasmò una discreta cerchia di programmatori che, sparsi
in tutto il mondo, cominciarono a scambiarsi idee, suggerimenti e risultati attraverso
la nascente Internet.
Oggi Linux è famoso per la grande flessibilità e potenza. La comunità degli
sviluppatori ha raggiunto proporzioni inimmaginabili allora, e Linus è ancora uno
dei programmatori più attivi. Esistono tantissime distribuzioni di Linux, che ne
esaltano diverse peculiarità, rendendo disponibili sistemi operativi altamente
specializzati.



3.2 Kernel Linux
        Il sistema operativo Linux si compone di programmi di sistema e kernel[3].
Il kernel di un sistema operativo in generale è il suo cuore; è la porzione di codice
che viene caricata per prima in memoria, trova la sua collocazione logica subito
sopra l’hardware e si occupa di fornire funzionalità alle altre componenti del
sistema operativo.
Linux ha un kernel di tipo monolitico, questo è infatti un unico grande blocco che
fornisce tutte le funzionalità, ma può avvalersi di moduli separati, i quali possono
essere compilati, caricati e rimossi dalla memoria indipendentemente dal resto del

                                           21
Capitolo 3 - Kernel Linux e pacchetti IP




kernel. Senza dubbio i moduli rappresentano uno dei maggiori punti di forza di
questo sistema operativo.
Il kernel Linux è suddiviso in cinque sottosistemi, ognuno dei quali gestisce la
propria area di competenza.



3.2.1 Scheduler dei processi
        Gestisce le politiche di accesso[3] al processore da parte dei vari processi; il
corretto accesso ai dispositivi hardware nella corretta tempistica; controlla che tutti
i processi abbiano accesso al processore in tempi ragionevoli. Le politiche di
scheduling sono applicate sia ai processi utente che a quelli relativi ad altri sistemi
componenti il kernel.
Questo sottosistema si compone di quattro moduli logici: quello che prende la
decisione di allocare il processore ad un processo, quello che dialoga con il
processore (ad esempio per ripristinare nei registri i valori afferenti il processo che
sta prendendo il controllo in un dato istante), quello che permette ai processi utente
di accedere solo alle interfacce esplicitamente esportate (ad esempio le chiamate di
sistema    per creare/distruggere nuovi processi) e, infine, il modulo che rende
possibile il dialogo fra gli altri moduli.



3.2.2 Gestione della memoria
        Gestisce le politiche di condivisione della memoria fisica[3]; le politiche di
accesso alle porzioni critiche di memoria; la possibilità di definire aree riservate
ad un solo processo; la memoria virtuale: fa credere ai processi che vi sia a
disposizione molta più memoria (RAM) rispetto a quella realmente disponibile,
copiando porzioni di memoria non usata in una determinata regione del disco fisso,
liberando così quella centrale per il processo in esecuzione. Definisce gli schemi e
le regole per un’equa assegnazione di memoria ai processi.




                                             22
Capitolo 3 - Kernel Linux e pacchetti IP




3.2.3 File System Virtuale
        Ha lo scopo di rendere possibile l’accesso a diversi dispositivi hardware, che
utilizzano differenti tipi di file system[3]; rendere possibile l’esecuzione di
differenti formati di file; usare la stessa interfaccia per accedere a qualsiasi tipo di
dispositivo e file system. Tutto ciò nel minor tempo, evitando perdite di dati e in
maniera sicura.
Il File System Virtuale permette di astrarre e fa in modo che un processo acceda alle
risorse senza sapere quale dispositivo hardware sta utilizzando. Qui sono definite le
politiche di utilizzo per i vari dispositivi (a blocchi e a caratteri) e le relative
interfacce, che vengono rese disponibili per i processi utente.
Il kernel possiede un modulo di device driver per ogni dispositivo hardware con cui
interfacciarsi.



3.2.4 Comunicazione fra processi
        Rende possibile il trasferimento di dati fra processi in esecuzione sulla stessa
macchina mettendo a disposizione un’interfaccia specifica e predisponendo i
meccanismi necessari, come ad esempio le pipe per la comunicazione diretta o lo
shared memory, meccanismo di comunicazione indiretta basato su aree di memoria
condivise fra più processi, i quali vi accedono in lettura e scrittura[3].



3.2.5 Sottosistema di rete
        Gestisce l’invio di dati all’esterno della macchina e la loro ricezione
attraverso i dispositivi di rete, nonché il processamento locale; fornendo un
adeguato livello di astrazione rispetto alle peculiarità del singolo dispositivo
hardware.



3.2.5.1 Dispositivi di rete
        Linux definisce le interfacce di rete come una classe di dispositivi a sé
stante[4], e le considera entità che inviano e ricevono pacchetti di dati, siano esse
fisiche o logiche, come nel caso del dispositivo di loopback, usato per trasferire dati

                                           23
Capitolo 3 - Kernel Linux e pacchetti IP




alla propria macchina. Ogni dispositivo ha il proprio device driver, che consiste in
un modulo del kernel in grado di comunicare direttamente con il controller (chip di
controllo) montato sul dispositivo. Per poter fare uso del dispositivo associato, il
modulo si deve registrare con il kernel durante la fase di avviamento della macchina
oppure all’atto del caricamento in memoria del modulo stesso.



3.2.5.2 Implementazione delle funzionalità di rete
       L’implementazione delle funzionalità di rete in Linux è modellata sulla base
di BSD 4.3 – fra le prime versioni di Unix ad introdurre funzionalità di rete – ed in
particolare supporta tutta la gamma di protocolli TCP/IP[4]. La decisione di basarsi
su questa implementazione fu dettata dalla grande popolarità che godeva in quel
periodo e, dunque, in quel modo le applicazioni di rete sarebbero state facilmente
portabili da Linux alle altre piattaforme Unix e viceversa.
Proprio come i protocolli di rete stessi, Linux implementa la famiglia dei protocolli
Internet come una serie di strati software connessi tra loro.
Il kernel mette a disposizione delle applicazioni di rete un’interfaccia chiamata
“socket BSD”, che non solo supporta differenti forme di networking, ma è anche un
meccanismo di comunicazione tra processi. Un socket descrive un capo di una
comunicazione: due processi che comunicano fra loro hanno ciascuno il proprio. Un
socket può essere pensato anche come caso particolare di pipe, con la differenza che
non vi sono limiti di dati che un socket può contenere.
Un socket BSD può essere di varia natura:


       1. Flusso: la comunicazione è bidirezionale ed avviene all’interno di una
           connessione stabilita, la quale viene aperta, mantenuta, eventualmente
           interrotta e infine chiusa. Questo tipo di socket è supportato dal
           protocollo TCP.
       2. Datagramma: comunicazione bidirezionale senza garanzia sulla
           ricezione, la correttezza e la sequenza dei dati. Supportato da UDP.
       3. Grezzo: permette ai processi un accesso diretto ai protocolli inferiori per
           osservare, ad esempio, il flusso di informazioni – grezze appunto – che




                                          24
Capitolo 3 - Kernel Linux e pacchetti IP




           transitano lungo un’interfaccia, oppure forgiare direttamente pacchetti IP
           senza passare per protocolli di strato 4.
       4. Datagramma a consegna affidabile: molto simili ai socket di tipo
           Datagramma, ma garantiscono la consegna dei dati.
       5. Sequenza di pacchetti: assomigliano molto ai socket di tipo Flusso, ma
           i pacchetti hanno tutti la stessa dimensione.
       6. Pacchetto: non è standard BSD, ma un’estensione di Linux che permette
           alle applicazioni di accedere ai pacchetti al livello di dispositivo.


Linux supporta diverse classi di socket, dette anche famiglie di indirizzi, quella per
le comunicazioni attraverso protocolli TCP/IP prende il nome di “inet address
family”.



3.3 Ricezione di pacchetti IP
       Nella seguente descrizione si farà riferimento al caso di calcolatore
collegato ad una rete di tipo Ethernet, in quanto è la tipologia più diffusa e non
comporta differenze significative rispetto ad altre tecnologie.
La scheda Ethernet ha un indirizzo univoco impostato internamente e rimane in
costante ascolto sulla linea. Quando vede un pacchetto (trama) il cui indirizzo MAC
di destinazione corrisponde al proprio o a quello di broadcast dello strato di
collegamento, inizia a leggerlo memorizzandolo in una memoria di ricezione[5].



3.3.1 Dalla scheda al kernel
       Al compimento della ricezione del pacchetto, la scheda di rete genera una
richiesta di interruzione[5] (interrupt), forzando il processore ad eseguire una
determinata porzione di codice presente nel device driver della scheda di rete.
Durante questa esecuzione non può ricevere interruzioni.
Il device driver alloca una nuova struttura dati rappresentante la visione che il
kernel ha di un pacchetto; riempie questa struttura dati prelevando le informazioni
dalla memoria della scheda di rete; prepara il kernel per il prossimo passo della
ricezione: mette il pacchetto dentro la coda d’ingresso. Qui, se la coda è piena il

                                           25
Capitolo 3 - Kernel Linux e pacchetti IP




pacchetto viene scartato e perso per sempre. In questa fase vengono raccolti e fatti
convergere in un’unica coda, tutti i pacchetti provenienti da tutti i device driver di
tutte le interfacce. La coda porta al processamento del pacchetto da parte degli strati
superiori. Dal momento che questa operazione è eseguita con le interruzioni
disabilitate, deve essere molto veloce: non può effettuare lunghi controlli o altre
operazioni complesse perché il sistema sta potenzialmente perdendo pacchetti
durante l’esecuzione di questa funzione. Quindi quello che fa è identificare uno
stato di congestione della coda (con cinque possibili stati). In condizioni normali il
pacchetto è accodato e la funzione termina, riabilitando le interruzioni. Una routine
specializzata si occupa di estrarre dalla coda d’ingresso i pacchetti uno ad uno e di
eseguire in sequenza le routine di gestione dei protocolli specifiche per quel tipo di
pacchetto.



3.3.2 Processamento IP
        All’avvio del kernel, o quando viene creato un certo tipo di socket, si
registrano con il kernel determinate routine di gestione dei protocolli specificando
per quali tipi di pacchetti devono essere eseguite[5]. Quelle per pacchetti generici
vengono eseguite per prime, mentre per ultime sono invocate quelle relative a
specifici protocolli.
Ciò è eseguito per tutti i pacchetti presenti nella coda fino a quando non sono stati
processati un numero massimo di pacchetti, o non è trascorso troppo tempo
(tipicamente 10 ms).
Sul pacchetto IP si eseguono tutti i controlli iniziali, che principalmente riguardano
la verifica della sua integrità (checksum, campi dell’intestazione e lunghezza
minima significativa); se il pacchetto risulta corretto viene processato dallo stadio di
pre-instradamento (PREROUTING) di netfilter – la cui descrizione è rimandata al
capitolo seguente.
Successivamente viene eseguita una decisione di instradamento preliminare, si
controlla, infatti, se il pacchetto deve essere inoltrato ad un’altra macchina o se è
destinato a quella locale. Nel primo caso viene eseguito l’instradamento e il
pacchetto viene spedito all’esterno attraverso la giusta interfaccia, passando per gli
stadi di inoltro (FORWARD) e post-instradamento (POSTROUTING) di netfilter;

                                          26
Capitolo 3 - Kernel Linux e pacchetti IP




altrimenti procede verso gli strati superiori nel calcolatore locale. Il controllo passa,
poi, nelle mani della funzione del protocollo IP che si occupa del riassemblaggio
dei datagrammi, la quale – ove necessario – si fa carico della ricostruzione dei
datagrammi partendo dai loro frammenti. Fatto ciò, il pacchetto passa attraverso lo
stadio di ingresso (INPUT) di netfilter. Per quanto riguarda il processamento di
strato 3, questo si conclude eliminando l’intestazione IP al datagramma. Se il
pacchetto risulta appartenere ad un socket IP grezzo, si saltano i protocolli di strato
di trasporto arrivando direttamente alle applicazioni attraverso questo tipo di socket.
Tuttavia, molto più comunemente il pacchetto sarà diretto verso un ulteriore gestore
di protocollo dentro il kernel. Per determinare quale protocollo sia, si esamina il
campo Protocol dell’intestazione IP. A questo stadio è presente una lista che
contiene tutti i protocolli post-IP registrati al caricamento del kernel. Per ognuno di
questi protocolli è definita una funzione di ricezione dei pacchetti.



3.3.3 Processamento locale
        Appena determinato il protocollo, viene richiamata la sua funzione di
ricezione[6]. Vi sono grandi differenze nelle modalità di processare i pacchetti fra
TCP e UDP, in quanto quest’ultimo è molto meno complesso, non essendo
orientato alla connessione. Per quanto riguarda il TCP, vengono eseguiti i controlli
di integrità dell’intestazione, poi si cerca un socket a cui corrisponda il pacchetto in
questione, se non si trova, causa l’invio di un pacchetto ICMP di tipo “Destinazione
non raggiungibile” e scarta il pacchetto.
Se al socket era stato impostato un filtro, questo viene applicato per primo, e se il
pacchetto non corrisponde viene scartato. Il filtro può anche specificare una
dimensione massima, e se il pacchetto la eccede, viene “accorciato” fino a riportarlo
alla lunghezza desiderata.
Il viaggio del pacchetto procede secondo strade differenti a seconda dello stato
corrente del socket, giungendo infine ai processi che fanno uso delle funzionalità di
rete.
Il protocollo UDP esegue solo i controlli di integrità dell’intestazione e cerca di
attribuire il pacchetto ad un socket. Dopodiché il pacchetto è scartato oppure
passato al processo creatore del socket.

                                            27
Capitolo 3 - Kernel Linux e pacchetti IP




3.4 Instradamento IP in dettaglio
          La funzione di instradamento è richiamata ogni qual volta un pacchetto deve
essere trasmesso, sia che esso provenga dal calcolatore locale, sia che provenga da
una macchina remota. In quest’ultimo caso deve essere abilitata l’opzione di inoltro
dei pacchetti IP nel kernel affinché il pacchetto venga reinstradato, altrimenti è
scartato.



3.4.1 Table lookup
          Per sapere a quale interfaccia inoltrare il pacchetto, il kernel esegue il
cosiddetto table lookup (consultazione della tabella di routing).
Ogni route della tabella è caratterizzata da una chiave univoca[7] che consiste nel
prefisso, ovvero la coppia formata da indirizzo di rete e maschera (che indica la
lunghezza del prefisso), e opzionalmente il valore di Type Of Service (TOS). Un
pacchetto IP corrisponde alla route se i bit più significativi dell’indirizzo di
destinazione del pacchetto sono uguali a quelli del prefisso della route almeno fino
alla lunghezza del prefisso stesso (indicata dalla maschera), e se il TOS della route è
zero o uguale al TOS del pacchetto.
Se un pacchetto trova corrispondenza con più di una route, si seguono le seguenti
regole:


          1. si scelgono le route con prefisso più lungo, scartando quelle con prefissi
             più corti;
          2. se il TOS di qualche route rimanente è uguale al TOS del pacchetto,
             allora le route con TOS differente sono scartate;
          3. se fra le rimanenti non vi sono route con lo stesso valore di TOS del
             pacchetto, ma ve ne sono con TOS pari a zero, le altre sono scartate;
             altrimenti la consultazione della tabella di routing fallisce, il pacchetto è
             scartato.
          4. se rimane più di una route valida dopo i precedenti passaggi, sono
             selezionate le route con migliore valore di metrica (il minore);
          5. se esiste ancora più di una route, viene selezionata la prima fra esse.


                                            28
Capitolo 3 - Kernel Linux e pacchetti IP




Si noti l’ambiguità dell’affermazione al punto 5. Sfortunatamente Linux
storicamente accetta questa bizzarra situazione. Il senso delle parole “la prima fra
esse” dipende letteralmente dall’ordine in cui le route sono state aggiunte alla
tabella ed è praticamente impossibile tenere traccia di questo ordine in alcun modo.
A livello pratico il problema non si pone, in quanto tutti gli strumenti che Linux
mette a disposizione per manipolare le route non permettono la creazione di route
non univoche.
Naturalmente i passi per la selezione del percorso menzionati sopra non sono
seguiti nella maniera descritta, in quanto la tabella di routing nel kernel è mantenuta
in una apposita struttura dati che permette di raggiungere il risultato finale con il
costo computazionale minimo. Si può però dire che una route è identificata dalla
tripletta <prefisso, TOS, metrica>, che la contraddistingue univocamente all’interno
della stessa tabella.
Dopo ogni consultazione della tabella, Linux mantiene in una apposita memoria
cache la decisione presa, in modo tale che se dovrà instradare un pacchetto con le
stesse caratteristiche, non dovrà effettuare di nuovo il table lookup, ma userà tale
memorizzazione. Le voci di questa cache sono eliminate dopo un determinato
tempo di inutilizzo.



3.4.2 Attributi delle route
        Ogni tripletta si riferisce ad una precisa voce dentro la tabella di routing
(route). La route contiene le informazioni necessarie per inoltrare i pacchetti IP[7]:


        1. Interfaccia da utilizzare.
        2. Indirizzo del prossimo router (in caso di consegna indiretta).
        3. Indirizzo sorgente preferito da utilizzare quando si spediscono pacchetti
            verso le destinazioni coperte dal prefisso. Questo indirizzo deve essere
            assegnato ad un’interfaccia fisica. Questo entra in gioco quando si usano
            anche regole di iptables, discusse in seguito.
        4. MTU (Maximum Transfer Unit), massima lunghezza del datagramma IP
            che può essere spedito lungo quel percorso senza essere frammentato.



                                           29
Capitolo 3 - Kernel Linux e pacchetti IP




       5. finestra TCP, ovvero il massimo valore della finestra che TCP può
           indicare lungo questo percorso. Questo limita il numero di pacchetti che
           il calcolatore remoto può inviare a quello locale prima di ricevere una
           conferma di ricezione.
       6. RTT (Round Trip Time), il tempo iniziale stimato di andata e ritorno di
           un pacchetto. Influisce sulla velocità di trasmissione.
       7. Estensione della validità della route, può essere globale, a livello di
           collegamento o entro lo stesso calcolatore.
       8. Modalità di inserimento della route, può indicare che la route è stata
           aggiunta in seguito alla ricezione di un messaggio ICMP di tipo
           Redirect; oppure dal kernel durante l’autoconfigurazione o durante
           l’avvio del sistema. Può essere una route di tipo statico aggiunta
           dall’amministratore, o dal protocollo di scoperta dei router.


Una route può essere anche di tipo multipercorso (multipath), in questo caso
possiede indirizzo del prossimo nodo, interfaccia da usare e peso della scelta, per
ogni scelta indicata. Questo consente di ripartire i flussi di dati destinati ad una
stessa destinazione su cammini differenti in maniera casuale, ma rispettando il
valore dei pesi. Cioè se la route definisce due cammini diversi e i pesi sono 1 e 2,
allora su tre flussi di dati, uno viene instradato lungo il primo percorso e due
vengono instradati lungo il secondo percorso. Ma non vi è modo di stabilire a priori
quali flussi passano per un certo percorso.



3.4.3 Tabelle di routing multiple
       Linux ha la possibilità di gestire più tabelle di routing, sulla base delle quali
eseguire l’instradamento dei pacchetti[7]. Ogni tabella è identificata da un valore
numerico     da    1    a   255,    a     cui   corrisponde   un     nome    nel    file
/etc/iproute2/rt_tables.
Normalmente le route vengono aggiunte nella tabella main (254), che è quella usata
dal kernel per il calcolo dei percorsi.




                                           30
Capitolo 3 - Kernel Linux e pacchetti IP




Per default esiste almeno un’altra tabella, local (255), adibita a contenere le route
relative agli indirizzi locali e di broadcast. Tale tabella viene automaticamente
gestita dal kernel.
Le altre tabelle di routing multiple entrano in gioco quando si usa il Policy Routing.
In questo contesto l’identificatore della tabella di routing diviene effettivamente un
ulteriore parametro da aggiungersi alla tripletta <prefisso, TOS, metrica>. Quindi la
chiave di identificazione univoca di una route viene ad essere formata da <tabella,
tripletta>. Ciò comporta che si possono avere più route identiche contenute in
tabelle differenti.



3.4.4 Policy Routing
        Linux prevede la possibilità di eseguire Policy Routing sostituendo la
tradizionale maniera di instradamento dei pacchetti – basata sulla regola del prefisso
più lungo – con il Routing Policy DataBase o RPDB[7], che seleziona il percorso
appropriato attraverso l’esecuzione di un insieme di regole. Tali regole possono
avere molte identificazioni di diversa natura e quindi non hanno un ordinamento
naturale ad eccezione di quello imposto dall’amministratore di rete. In Linux il
RPDB consiste in una lista di regole ordinate secondo un valore numerico che ne
indica la priorità: zero è quella massima. Il RPDB permette esplicitamente di
impostare le regole sulla base di:


        1. indirizzo sorgente del pacchetto;
        2. indirizzo destinazione (come nel routing tradizionale);
        3. TOS;
        4. interfaccia d’ingresso;
        5. eventuale marchio impresso dal kernel al pacchetto nella fase di pre-
            instradamento.


Fondamentale è il punto 5, in quanto, attraverso l’uso di strumenti adeguati – i quali
sono discussi in seguito – si può raggiungere un elevatissimo grado di flessibilità
nella marcatura dei pacchetti ed aumentare a dismisura la capacità di Policy



                                           31
Capitolo 3 - Kernel Linux e pacchetti IP




Routing della macchina Linux, piegandola alle esigenze più minuziose degli
amministratori di rete.
Ogni regola del database consiste in un selettore e in un’azione. La lista è consultata
partendo dalla regola di priorità zero, per essere sicuri che i pacchetti destinati alla
macchina locale siano consegnati agli strati superiori e non ulteriormente instradati.
Viene applicato il selettore di ogni regola alle relative informazioni del pacchetto IP
considerato (sorgente, destinazione, TOS, interfaccia di ingresso, marchio). Se
viene trovata corrispondenza, viene eseguita l’azione relativa. L’esecuzione di
quest’azione comporta, normalmente, la scelta della tabella di routing su cui
effettuare il lookup. Dopodiché il kernel esegue il lookup sulla tabella specificata
usando la tradizionale regola di basarsi sulla destinazione del pacchetto e di partire
dalle route con prefisso più lungo.
L’azione relativa ad una regola può anche specificare che il pacchetto debba essere
scartato.
All’avvio della macchina, il kernel popola il database delle regole con le seguenti
tre:


        1. Priorità: 0; Selettore: qualsiasi pacchetto; Azione: lookup tabella local
            (255).
        2. Priorità: 32766; Selettore: qualsiasi pacchetto: Azione: lookup tabella
            main (254).
        3. Priorità: 32767; Selettore: qualsiasi pacchetto; Azione: lookup tabella
            default (253).


La regola di priorità zero non può essere eliminata né modificata.



3.5 Controllo del traffico
        Dopo che il sottosistema di rete ha preso la decisione di routing, il kernel sa
quale interfaccia di rete usare per spedire il pacchetto. Ogni device driver possiede
alcune informazioni riguardanti le modalità con cui accodare i pacchetti per la
particolare interfaccia a cui è connesso. Queste informazioni di accodamento sono



                                          32
Capitolo 3 - Kernel Linux e pacchetti IP




quello che gli sviluppatori di Linux chiamarono queuing discipline, ovvero
disciplina di accodamento[8].
Quando il kernel deve passare un pacchetto ad un’interfaccia di rete, accoda questo
pacchetto secondo la disciplina di tale interfaccia e immediatamente dopo, cerca di
tirar fuori – dalla testa della coda – quanti più pacchetti possibili da consegnare
all’interfaccia. L’applicazione di questo meccanismo risulta in un comportamento
dei pacchetti che ricalca la disciplina impostata.
Una disciplina di accodamento molto semplice può consistere in una singola coda,
in cui tutti i pacchetti sono inseriti nell’ordine di arrivo, e che è svuotata alla
massima velocità alla quale il dispositivo riesce a spedire i pacchetti sulla rete.
Discipline di accodamento più elaborate possono usare dei filtri per distinguere
diverse classi di pacchetti e processare ogni classe in maniera diversa, ad esempio
concedendo ad una classe una priorità maggiore rispetto le altre.
Discipline di accodamento e classi sono intimamente legate: la presenza delle classi
e le loro regole semantiche sono proprietà fondamentali delle discipline di
accodamento. I filtri possono essere combinati arbitrariamente con discipline e
classi.
Per aumentare la flessibilità, ogni classe ha la sua disciplina per l’accodamento dei
pacchetti. Questa disciplina può a sua volta avere più di una classe, e così via.
Le discipline di accodamento possono essere applicate anche ai pacchetti entranti,
indipendentemente dal fatto che questi pacchetti siano destinati alla macchina locale
o debbano essere instradati verso altri host.


Il controllo del traffico riguarda[9]:


    •   Shaping: consiste nel tenere sotto controllo la velocità di trasmissione. Non
        consiste solo nel limitarne la velocità, ma anche nel limitare i burst, cioè i
        picchi.
    •   Scheduling: consiste nell’impostare una diversa priorità per il tipo di traffico
        che ne ha bisogno, pur garantendo una determinata banda al traffico
        secondario. Si applica solo al traffico in uscita.
    •   Policing: è lo Shaping applicato ai pacchetti in ingresso.



                                             33
Capitolo 3 - Kernel Linux e pacchetti IP




   •   Dropping: quando la velocità dei pacchetti eccede una quantità definita,
       questi vengono scartati immediatamente senza essere processati.



3.6 Tunneling
        Con il temine tunneling (scavare tunnel) si intende la possibilità di creare e
gestire delle speciali connessioni chiamate tunnel. Un tunnel non è altro che una
connessione IP normale, nella quale il contenuto dei pacchetti non è rappresentato
da dati appartenenti ad un protocollo di trasporto, ma ad un altro protocollo di rete.
Una volta instaurato il tunnel, infatti, quando devono essere trasmessi, i dati utente
sono messi in un pacchetto di strato di trasporto, il quale è incapsulato in un
pacchetto di strato di rete (generico), che viene re-incapsulato in un pacchetto IP, il
quale poi è inserito in una trama di collegamento ed inizia il viaggio. L’entità
software che esegue l’incapsulamento dei pacchetti in un tunnel molto spesso
risiede su una macchina differente da quella che genera il pacchetto vero e proprio,
ad esempio il gateway di una LAN. Al lato della ricezione deve trovarsi un’entità in
grado di riconoscere un pacchetto che fa parte di un tunnel, quindi togliere il
“rivestimento” che questo comporta e instradare il pacchetto di dati significativi
verso il destinatario (o verso gli strati superiori presenti nella macchina stessa, a
seconda dei casi).
Le applicazioni di rete i cui dati passano attraverso un tunnel non se ne rendono
conto, l’operazione è del tutto trasparente nei loro confronti.
Vi possono essere diverse ragioni per usare tunnel, fra queste:


   •   Sicurezza/riservatezza: in questo caso l’entità che incapsula i pacchetti nel
       tunnel li cifra anche.
   •   Possibilità di interconnettere più LAN private, geograficamente distanti tra
       loro, senza dover ricorrere a sistemi dedicati e costosi. Infatti il tunnel si
       snoderà lungo Internet senza richiedere costi aggiuntivi.
   •   Possibilità di scambiare traffico incapsulato in protocolli di rete diversi da
       IPv4, usando reti IPv4. Un esempio è l’utilizzo di IPv6.




                                          34
Capitolo 3 - Kernel Linux e pacchetti IP




Linux rende possibile la creazione di tre grandi tipi di tunnel[10]:
       •   IPv4 in IPv4
       •   IPv6 in IPv4
       •   qualsiasi protocollo in GRE in IPv4




                                           35
Capitolo 3 - Kernel Linux e pacchetti IP




                                       36
Capitolo 4 - Strumenti per il networking




Capitolo 4. Strumenti per il networking

4.1 Netfilter
       Netfilter è un componente di Linux presente nelle versioni 2.4.x e 2.6.x[11].
È il successore riprogettato e altamente migliorato di ipchains (Linux 2.2.x) e
ipfwadm (Linux 2.0.x). Questa struttura permette il filtraggio e la manipolazione
dei pacchetti. Comprende due parti:


       1. Ogni protocollo definisce dei punti di aggancio (hook), IPv4 ne
           definisce cinque, i quali sono punti ben definiti lungo il viaggio dei
           pacchetti nella pila dei protocolli (protocol stack). In ciascuno di questi
           punti il protocollo richiamerà la struttura netfilter fornendo il pacchetto
           ed il numero identificativo dell’hook.


       2. Porzioni del kernel possono registrarsi per “ascoltare”, per ogni
           protocollo, differenti hook. Di conseguenza, quando un pacchetto è
           passato a netfilter, esso controlla se qualcuno si è registrato per quel
           determinato protocollo e hook; se sì, a ciascuno di essi è data, in ordine,
           una chance per esaminare (e possibilmente alterare) il pacchetto, per
           scartarlo, lasciarlo proseguire o per chiedere a netfilter di accodarlo
           verso lo spazio utente.



4.1.1 Punti di hook
       I cinque hook di IPv4 sono situati in punti strategici:


       1. PREROUTING (pre-instradamento): è attraversato da tutti i pacchetti
           entranti. È posizionato subito dopo il controllo di sanità dei pacchetti IP,
           subito prima del processo di routing, quando ancora il kernel non sa se il
           pacchetto è destinato alla macchina locale, oppure se è da instradare.



                                         37
Capitolo 4 - Strumenti per il networking




      2. INPUT (ingresso locale): è posizionato subito prima della funzione che
          passa il pacchetto nelle mani del processo, quindi subito prima che il
          pacchetto esca dallo spazio del kernel ed entri nello spazio utente.


      3. FORWARD (inoltro): prima dell’instradamento vero e proprio il kernel
          controlla se un pacchetto è destinato alla macchina locale o se deve
          essere instradato, nel caso in cui la decisione sia di instradarlo, il
          pacchetto viene instradato, quindi passa attraverso questo hook. Vi
          passano attraverso solo i pacchetti ricevuti che non sono destinati alla
          macchina locale, ma che vengono reinstradati verso altri host.


      4. POSTROUTING (post-instradamento): è attraversato da tutti i
          pacchetti uscenti dalla macchina, in quanto si trova subito prima che
          questi vengano spediti alla coda di uscita della scheda di rete prescelta.


      5. OUTPUT (uscita locale): è attraversato da tutti i pacchetti generati
          localmente. Dal punto di vista logico è chiamato prima che il kernel
          esegua l’instradamento di tali pacchetti, mentre di fatto la funzione di
          routing è chiamata prima (per comprendere l’indirizzo IP sorgente ed
          altre opzioni IP) e dopo, nel caso in cui il pacchetto sia stato modificato.




                                         38
Capitolo 4 - Strumenti per il networking




Figura 5. Punti di hook nel percorso dei pacchetti IP



4.2 Iptables
       Il componente più conosciuto che poggia sulla struttura di netfilter è
iptables. Iptables è una generica struttura a tabelle per la definizione di regole[11].
Queste regole si applicano ai pacchetti che netfilter fornisce ad ogni hook.
Si noti che iptables in sé non si registra a nessun hook, ma lo lascia fare ad altri
moduli. Il suo compito è di mantenere in memoria una lista di regole e informazioni
su dove i pacchetti provenienti da ciascun hook devono cominciare la traversata.
Iptables fa parte del corredo standard di applicazioni di praticamente tutte le
distribuzioni Linux, i sorgenti sono comunque facilmente reperibili e liberamente




                                          39
Capitolo 4 - Strumenti per il networking




scaricabili dal sito http://www.netfilter.org. La versione stabile attuale è la
1.3.5, la stessa che è stata utilizzata per eseguire gli esperimenti in laboratorio.



4.2.1 Tabelle
       Ogni regola all’interno di una tabella di iptables, consiste in un numero di
classificatori (match) ed una azione (target).
Le tabelle sono internamente suddivise in catene. Ogni catena contiene le regole
specifiche per il punto di hook corrispondente[2].
Quando netfilter passa un pacchetto a iptables, questo scorre regola per regola,
secondo l’ordine determinato dall’utente, le catene corrispondenti all’attuale punto
di hook per ogni tabella. Quando viene riscontrata corrispondenza fra i match di una
regola ed i parametri del pacchetto, allora viene eseguita l’azione corrispondente
alla regola. A seconda del tipo di azione, questa può interrompere lo scorrimento
delle regole oppure no.
Ogni catena ha una politica di default, che viene applicata nel caso in cui il
pacchetto non trovi riscontri con nessuna regola.
Vi sono tre tabelle standard in iptables: filter, nat, e mangle. La prima è stata
progettata espressamente per il filtraggio dei pacchetti, nei tre stadi di ingresso,
uscita e inoltro rispettivamente nei punti di hook INPUT, FORWARD e OUTPUT.
Questa tabella è usata per svolgere funzioni di firewall.
La tabella nat, come dice la parola stessa, è usata per la traduzione degli indirizzi:
ad esempio per effettuare NAPT (Network Address and Port Translation)
permettendo ai calcolatori di una rete IP privata di avere accesso a Internet; oppure
effettuare Port Forwarding per permettere ai calcolatori esterni di raggiungere
determinati servizi situati su macchine interne alla rete locale. Questa tabella
utilizza gli hook di PREROUTING, OUTPUT e POSTROUTING, ai quali
corrispondono tre catene omonime.
C’è infine la tabella mangle, la quale utilizza tutti i cinque hook, possiede quindi
cinque catene ed è usata per eseguire tutte le operazioni che non riguardano il
filtraggio e la traduzione degli indirizzi: effettuare logging, modificare ulteriori
campi dell’intestazione dei pacchetti – come il campo TOS – e contrassegnarli.



                                           40
Capitolo 4 - Strumenti per il networking




4.2.2 Configurazione
       Iptables si configura attraverso l’omonimo programma di sistema, il quale
permette di visualizzare lo stato corrente dell’insieme di regole, aggiungere nuove
regole, definire nuove catene, eliminare regole e catene definite dall’utente,
modificare le politiche di default per le catene standard (che non possono essere
rinominate né rimosse)[12].


Sintassi:
iptables -[A|D] chain rule-specification [options]
iptables -[R|I] chain num rule-specification [options]
iptables -D chain num [options]
iptables -[L|F|Z] [chain] [options]
iptables -[N|X] chain
iptables -E old-chain-name new-chain-name
iptables –P chain target [options]


Comandi:
-A chain Appende all’ultimo posto della catena
-D chain Elimina dalla catena la regola corrispondente
-D chain num Elimina la regola num (1 = prima) dalla catena
-I chain [num] Inserisce nella catena alla posizione num (default 1=prima)
-R chain num Sostituisce la regola num nella tabella soecificata
-L [chain] Mosrta il contenuto di una catena o di tutte
-F [chain] Elimina tutte le regole di una catena o di tutte
-Z [chain] Azzera i contatori in una catena o in tutte
-N chain Crea una nuova catena definita dall’utente
-X [chain] Elimina una catena definita dall’utente
-P chain target Cambia la politica di default della catena
-E old-chain new-chain Cambia nome alla catena


Opzioni:
-p [!] proto Protocollo: numero o nome, es. “tcp”



                                        41
Capitolo 4 - Strumenti per il networking




-s [!] address[/mask] Indirizzo IP sorgente
-d [!] address[/mask] Indirizzo IP destinazione
-i [!] input-name[+] Nome dell’interfaccia d’ingresso ([+] per wildcard)
-j target Azione di una regola
-m match Match esplicito
-n Output numerico per indirizzi e porte
-o [!] output-name[+] Nome dell’interfaccia di uscita ([+] per wildcard)
-t table Tabella da manipolare (default: “filter”)
-v Modalità prolissa
--line-numbers mostra i numeri delle linee quando fa il listato
-x Espande i numeri (mostra i valori esatti)
[!] –f trova corrispondenza solo con i frammenti dal secondo in poi
--modprobe=<command> prova ad inserire i moduli usando questo comando
--set-counters PKTS BYTES Imposta i contatori durante l’inserimento di una
                                    regola.


Ad ogni riavvio del sistema iptables azzera le proprie regole. Per rendere persistente
la configurazione esistono due strumenti distribuiti nel pacchetto.
Per salvare una configurazione:


 iptables-save > FILE


Per ripristinare una configurazione precedentemente salvata:


 iptables-restore < FILE


Una configurazione di iptables può facilmente essere resa persistente salvando –
con il primo comando – la configurazione che si intende mantenere; quindi
inserendo il secondo comando in uno script eseguito all’avvio del sistema.




                                         42
Capitolo 4 - Strumenti per il networking




4.2.3 Match
       La grande potenza che iptables mette a disposizione degli amministratori di
rete risiede, in massima parte, nella elevata finezza con cui è oggi possibile
classificare i pacchetti: sulla base non solo di tutti i parametri che fanno parte
dell’intestazione IP e TCP, ma, ad esempio, dello stato in cui si trova la connessione
TCP di cui un pacchetto fa parte, e molto altro.
Esistono due grandi famiglie di match: quelli impliciti e quelli espliciti; i primi
sono quelli che appaiono come opzioni nella lista precedente: indirizzo sorgente e
destinazione, porta sorgente e destinazione, interfaccia d’ingresso e uscita e
protocollo. Mentre per gli altri occorre esplicitamente indicare il nome del modulo
che implementa il match, attraverso -m <match>.
Esempio:


 iptables –t filter –A INPUT –m match ttl --ttl 128 -j DROP


In questo esempio tutti i pacchetti diretti alla macchina locale, con Time To Live
pari a 128 vengono scartati silenziosamente.



4.2.4 Casi di interesse
       Per ciò che concerne gli scopi di questo elaborato, le funzionalità di iptables
sfruttate sono le seguenti:


       1. tutti i match che permettono di distinguere diversi flussi di dati ed il
           match random.
       2. i target MARK e CLASSIFY.



4.2.4.1 Match random
       Non si riferisce ad alcun parametro dei pacchetti IP, semplicemente la
condizione è verificata in maniera casuale entro una ben precisa probabilità media
di occorrenza[13].



                                         43
Capitolo 4 - Strumenti per il networking




Sintassi:
iptables –t <tabella> -A <catena> 
   –m random [ --average <n> ] [ <altri match> ] -j <target>


Dove <n> indica la probabilità media (percentuale) con cui si verificherà la
soddisfazione del match random. Se non viene specificata alcuna media, si prende
quella di default, che è del 50%.


Esempio:
iptables -A INPUT –m random --average 80 –p icmp -j DROP


Nell’esempio si specifica una regola secondo cui i pacchetti ICMP destinati alla
macchina locale saranno scartati con l’80% di probabilità.



4.2.4.2 Match tos
       Permette di trovare corrispondenza con i pacchetti, basandosi sugli 8 bit del
campo Type Of Service dell’intestazione IP[14].


Sintassi:
iptables –t <tabella> -A <catena> -m tos –-tos <n> 
   -j <target>


Dove <n> rappresenta il valore del TOS con cui trovare la corrispondenza. Può
essere indicato con notazione decimale o esadecimale. Cinque valori possono essere
anche specificati sottoforma di stringa:


                Nome                Valore decimale      Valore esadecimale
            Minimize-Delay                  16                  0x10
     Maximize-Throughput                    8                   0x08
     Maximize-Reliability                   4                   0x04
            Minimize-Cost                   2                   0x02
            Normal-Service                  0                   0x00



                                           44
Capitolo 4 - Strumenti per il networking




4.2.4.3 Target MARK
       Un target utilizzato di frequente, anche quando si vuole sfruttare la potenza
di iptables in applicazioni esterne, è MARK, che effettua il contrassegno dei
pacchetti[14], può essere usato solo nella tabella mangle.


Sintassi:

iptables -t mangle –A <catena> <match> 
   -j MARK –-set-mark <n>


Dove <n> è proprio il contrassegno (o marchio) che verrà applicato a tutti i
pacchetti che corrispondano alla lista di selettori della regola. Può essere indicato
con notazione decimale o esadecimale, è un intero a 32 bit, quindi può andare da
0x00000000 a 0xFFFFFFFF.
Il marchio impresso ad un pacchetto non va a modificare i suoi dati e nemmeno
l’intestazione, ma rimane impresso in modo virtuale per tutto il tempo che il
pacchetto trascorre all’interno della macchina. Altre applicazioni possono leggere il
valore del marchio e quindi sfruttarlo per trattare i pacchetti in maniera differente a
seconda di come sono stati marchiati. Questo senza che debbano essere in grado di
distinguere i pacchetti, perché il lavoro è svolto tutto da iptables. Queste
applicazioni devono solo sapere come leggere il marchio.
Questo target non prevede l’interruzione, quindi dopo che un pacchetto è stato
contrassegnato, iptables continua a scorrere la lista delle regole.



4.2.4.4 Target CLASSIFY
       Questo target è usato per classificare i pacchetti in classi diverse. Le stesse
classi che vengono usate per l’accodamento dei pacchetti nelle discipline di
accodamento[13]. È usato in combinazione con altri strumenti per il controllo del
traffico, i quali si occupano di applicare determinate discipline e regole di
accodamento alle varie classi di pacchetti.




                                           45
Capitolo 4 - Strumenti per il networking




Sintassi:
iptables –t <tabella> -A <catena> <match> 
   -j CLASSIFY –-set-class <major>:<minor>


Dove <major>:<minor> rappresentano la classe in cui vengono fatti rientrare tutti
i pacchetti che trovano corrispondenza con i match della regola. Il significato di
questa sintassi verrà chiarito nella sezione dedicata alla suite iproute2.


L’uso di questo target nell’ambito del controllo del traffico è vivamente consigliato
dall’Autore in quanto si sfruttano la grande potenza di iptables, che non ha eguali, e
la sua grande semplicità d’uso.



4.2.4.5 Altri usi
       L’uso di iptables nello svolgimento degli esperimenti non si ferma qui.
Infatti è usato anche nello svolgimento di compiti non centrali, ma di supporto,
come la traduzione degli indirizzi per permettere ad alcuni calcolatori di accedere
ad Internet.


Esempio di traduzione degli indirizzi:
iptables –t nat -A POSTROUTING –o eth1 –s 192.168.1.0/24 
   -j MASQUERADE


Nell’esempio sopra riportato, tutti i pacchetti con indirizzo sorgente appartenente
alla sottorete specificata i quali, dopo il processo di routing, devono essere inviati al
dispositivo di rete indicato, subiscono una modifica tale per cui al loro indirizzo
sorgente originale viene sostituito quello dell’interfaccia di rete di uscita[13] (il
primario, se ne possiede più di uno). Questo processo è chiamato masquerading
(mascheramento).
Non è necessario inserire altre regole, in quanto la traduzione inversa – effettuata
sui pacchetti che vanno in direzione opposta, che devono raggiungere una macchina
con IP mascherato – è eseguita automaticamente tenendo traccia delle connessioni
con meccanismi interni.


                                           46
Capitolo 4 - Strumenti per il networking




4.2.5 Estensioni
       La struttura di iptables prevede che tutti i match e tutti i target siano costruiti
come moduli. Ciò rende relativamente semplice aggiungere nuovi moduli, che
espletino diverse funzioni: match, target, addirittura nuove tabelle[11].
Il team di netfilter è costantemente al lavoro[15], soprattutto per quanto riguarda i
moduli: si apportano continue modifiche e migliorie ai moduli presenti nel
pacchetto stabile, si testano e rendono stabili i moduli nuovi non ancora inseriti nel
pacchetto ufficiale, e infine si elaborano moduli dalle funzioni innovative.
Viene messo a disposizione uno strumento per gli utenti – un poco spericolati – che
vogliano aggiungere alla propria versione di iptables dei moduli non presenti perché
non ancora ritenuti adeguatamente stabili o perché non svolgono ancora tutte le
funzioni per cui sono stati programmati. Lo strumento è un’applicazione chiamata
patch-o-matic, ora divenuto patch-o-matic-ng (Next Generation).
Estendere le funzionalità di iptables è un’operazione di una certa portata, che
comporta anche la ricompilazione del kernel, da qui la necessità di un programma
che esegua in automatico le operazioni più delicate, come l’applicazione delle
modifiche (patch) ai sorgenti di iptables e del kernel.



4.2.5.1 Aggiunta di un’estensione: modulo random
       Ai fini degli esperimenti effettuati, è necessario aggiungere il match
random, perché non presente nella distribuzione dei calcolatori di laboratorio.
Di seguito sono riportati i passaggi compiuti sulla macchina netlab11. Si noti che i
passaggi descritti sono stati eseguiti utilizzando la distribuzione Linux Fedora Core
3, quindi potrebbero presentare differenze con le procedure da seguire su altre
distribuzioni[16].


Per prima cosa si deve scaricare il codice sorgente del kernel, facendo attenzione a
scaricare la giusta versione, in questo caso Fedora Core 3, kernel 2.6.9-1.667.
Wget http://download.fedora.redhat.com/ 
  pub/fedora/linux/core/3/i386/os/SRPMS/ 
  kernel-2.6.9-1.667.src.rpm




                                           47
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux

Weitere ähnliche Inhalte

Was ist angesagt?

Tesi Triennale - X509 e PGP
Tesi Triennale - X509 e PGPTesi Triennale - X509 e PGP
Tesi Triennale - X509 e PGPFabio Pustetto
 
Modellazione della dinamica di un liquido bifase mediante GPU CUDA
Modellazione della dinamica di un liquido bifase mediante GPU CUDAModellazione della dinamica di un liquido bifase mediante GPU CUDA
Modellazione della dinamica di un liquido bifase mediante GPU CUDAkylanee
 
Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web
Joseki : un server per interrogare risorse RDF attraverso un interfaccia WebJoseki : un server per interrogare risorse RDF attraverso un interfaccia Web
Joseki : un server per interrogare risorse RDF attraverso un interfaccia WebCyclope86
 
Il tutorial di Python
Il tutorial di PythonIl tutorial di Python
Il tutorial di PythonAmmLibera AL
 
GaPiL - Guida alla Programmazione in Linux
GaPiL - Guida alla Programmazione in LinuxGaPiL - Guida alla Programmazione in Linux
GaPiL - Guida alla Programmazione in LinuxAmmLibera AL
 
Tesi Laurea Sergio Taddia
Tesi Laurea Sergio TaddiaTesi Laurea Sergio Taddia
Tesi Laurea Sergio TaddiaSergio Taddia
 
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientaleInterfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientaleLuigi De Russis
 
Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...
Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...
Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...AmmLibera AL
 
Abstract Domenico Brigante
Abstract   Domenico BriganteAbstract   Domenico Brigante
Abstract Domenico Brigantedox82
 
Pattern Recognition Lecture Notes
Pattern Recognition Lecture NotesPattern Recognition Lecture Notes
Pattern Recognition Lecture NotesRobertoMelfi
 
Montalti - "Interactive Musical Agents" (2010, paper ITA)
Montalti - "Interactive Musical Agents" (2010, paper ITA)Montalti - "Interactive Musical Agents" (2010, paper ITA)
Montalti - "Interactive Musical Agents" (2010, paper ITA)Alessandro Montalti
 
Porting evolutivo di un’applicazione per la gestione di note spese in ambient...
Porting evolutivo di un’applicazione per la gestione di note spese in ambient...Porting evolutivo di un’applicazione per la gestione di note spese in ambient...
Porting evolutivo di un’applicazione per la gestione di note spese in ambient...enriconatella
 
Progetto e realizzazione di un sistema per la caratterizzazione su larga scal...
Progetto e realizzazione di un sistema per la caratterizzazione su larga scal...Progetto e realizzazione di un sistema per la caratterizzazione su larga scal...
Progetto e realizzazione di un sistema per la caratterizzazione su larga scal...guest85785c7
 
Il mio libro - My book (intro)
Il mio libro - My book (intro)Il mio libro - My book (intro)
Il mio libro - My book (intro)pls3d
 

Was ist angesagt? (20)

Tesi Triennale - X509 e PGP
Tesi Triennale - X509 e PGPTesi Triennale - X509 e PGP
Tesi Triennale - X509 e PGP
 
Modellazione della dinamica di un liquido bifase mediante GPU CUDA
Modellazione della dinamica di un liquido bifase mediante GPU CUDAModellazione della dinamica di un liquido bifase mediante GPU CUDA
Modellazione della dinamica di un liquido bifase mediante GPU CUDA
 
Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web
Joseki : un server per interrogare risorse RDF attraverso un interfaccia WebJoseki : un server per interrogare risorse RDF attraverso un interfaccia Web
Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web
 
My Thesis
My ThesisMy Thesis
My Thesis
 
Il tutorial di Python
Il tutorial di PythonIl tutorial di Python
Il tutorial di Python
 
A.Dionisi Thesis
A.Dionisi ThesisA.Dionisi Thesis
A.Dionisi Thesis
 
GaPiL - Guida alla Programmazione in Linux
GaPiL - Guida alla Programmazione in LinuxGaPiL - Guida alla Programmazione in Linux
GaPiL - Guida alla Programmazione in Linux
 
Tesi peiretti
Tesi peirettiTesi peiretti
Tesi peiretti
 
Tesi Laurea Sergio Taddia
Tesi Laurea Sergio TaddiaTesi Laurea Sergio Taddia
Tesi Laurea Sergio Taddia
 
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientaleInterfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
 
Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...
Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...
Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...
 
Abstract Domenico Brigante
Abstract   Domenico BriganteAbstract   Domenico Brigante
Abstract Domenico Brigante
 
Pattern Recognition Lecture Notes
Pattern Recognition Lecture NotesPattern Recognition Lecture Notes
Pattern Recognition Lecture Notes
 
Montalti - "Interactive Musical Agents" (2010, paper ITA)
Montalti - "Interactive Musical Agents" (2010, paper ITA)Montalti - "Interactive Musical Agents" (2010, paper ITA)
Montalti - "Interactive Musical Agents" (2010, paper ITA)
 
Porting evolutivo di un’applicazione per la gestione di note spese in ambient...
Porting evolutivo di un’applicazione per la gestione di note spese in ambient...Porting evolutivo di un’applicazione per la gestione di note spese in ambient...
Porting evolutivo di un’applicazione per la gestione di note spese in ambient...
 
7335 7345 sm
7335 7345 sm7335 7345 sm
7335 7345 sm
 
Progetto e realizzazione di un sistema per la caratterizzazione su larga scal...
Progetto e realizzazione di un sistema per la caratterizzazione su larga scal...Progetto e realizzazione di un sistema per la caratterizzazione su larga scal...
Progetto e realizzazione di un sistema per la caratterizzazione su larga scal...
 
domenicoCaputiTriennale
domenicoCaputiTriennaledomenicoCaputiTriennale
domenicoCaputiTriennale
 
Il mio libro - My book (intro)
Il mio libro - My book (intro)Il mio libro - My book (intro)
Il mio libro - My book (intro)
 
Manuale geogebra
Manuale geogebraManuale geogebra
Manuale geogebra
 

Andere mochten auch

Andere mochten auch (8)

sicurezza e php
sicurezza e phpsicurezza e php
sicurezza e php
 
Ip sec vulnerability
Ip sec vulnerabilityIp sec vulnerability
Ip sec vulnerability
 
FDCC - SCAP - Overview
FDCC - SCAP - OverviewFDCC - SCAP - Overview
FDCC - SCAP - Overview
 
Clonare mac os x
Clonare mac os xClonare mac os x
Clonare mac os x
 
Deftcon 2013 - Alessandro Rossetti & Massimiliano Dal Cero - OSint a supporto...
Deftcon 2013 - Alessandro Rossetti & Massimiliano Dal Cero - OSint a supporto...Deftcon 2013 - Alessandro Rossetti & Massimiliano Dal Cero - OSint a supporto...
Deftcon 2013 - Alessandro Rossetti & Massimiliano Dal Cero - OSint a supporto...
 
Openexp 2006
Openexp 2006Openexp 2006
Openexp 2006
 
Smau 2006
Smau 2006Smau 2006
Smau 2006
 
Sql injection - intro
Sql injection - introSql injection - intro
Sql injection - intro
 

Ähnlich wie Inoltro di pacchetti ip in sistemi linux

Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques Maurizio Cacace
 
Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...
Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...
Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...Domenico Schillaci
 
Tesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilità
Tesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilitàTesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilità
Tesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilitàRiccardo Melioli
 
Profilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzatiProfilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzatiPietro Corona
 
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...maaske
 
Monitoraggio di applicazioni software mediante modelli di Markov
Monitoraggio di applicazioni software mediante modelli di MarkovMonitoraggio di applicazioni software mediante modelli di Markov
Monitoraggio di applicazioni software mediante modelli di Markovrkjp
 
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...Gianluca Ritrovati
 
Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...
Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...
Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...Daniele Ciriello
 
Openfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistemsOpenfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistemsLorenzo Stacchio
 
Valutazione sperimentale di tecnologie per la gestione dei dati per workflow ...
Valutazione sperimentale di tecnologie per la gestione dei dati per workflow ...Valutazione sperimentale di tecnologie per la gestione dei dati per workflow ...
Valutazione sperimentale di tecnologie per la gestione dei dati per workflow ...Francesco De Giorgi
 
Publish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingPublish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingNicola Mezzetti
 
Un metodo di progettazione di reti locali con esigenze di qualità del servizio
Un metodo di progettazione di reti locali con esigenze di qualità del servizioUn metodo di progettazione di reti locali con esigenze di qualità del servizio
Un metodo di progettazione di reti locali con esigenze di qualità del servizioClaudio Bortone
 
Il Modello Pragmatico Elementare per lo sviluppo di Sistemi Adattivi - Tesi
Il Modello Pragmatico Elementare per lo sviluppo di Sistemi Adattivi - TesiIl Modello Pragmatico Elementare per lo sviluppo di Sistemi Adattivi - Tesi
Il Modello Pragmatico Elementare per lo sviluppo di Sistemi Adattivi - TesiFrancesco Magagnino
 
Strategie ingestigative in ambito di criminalità informatica
Strategie ingestigative in ambito di criminalità informaticaStrategie ingestigative in ambito di criminalità informatica
Strategie ingestigative in ambito di criminalità informaticapeppespe
 
Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codi...
Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codi...Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codi...
Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codi...danielenicassio
 
Sistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisitionSistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisitionAmmLibera AL
 
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...Davide Ciambelli
 

Ähnlich wie Inoltro di pacchetti ip in sistemi linux (20)

Sat howto
Sat howtoSat howto
Sat howto
 
Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques
 
Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...
Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...
Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...
 
Tesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilità
Tesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilitàTesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilità
Tesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilità
 
Profilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzatiProfilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzati
 
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
 
Monitoraggio di applicazioni software mediante modelli di Markov
Monitoraggio di applicazioni software mediante modelli di MarkovMonitoraggio di applicazioni software mediante modelli di Markov
Monitoraggio di applicazioni software mediante modelli di Markov
 
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
 
Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...
Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...
Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...
 
Openfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistemsOpenfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistems
 
Valutazione sperimentale di tecnologie per la gestione dei dati per workflow ...
Valutazione sperimentale di tecnologie per la gestione dei dati per workflow ...Valutazione sperimentale di tecnologie per la gestione dei dati per workflow ...
Valutazione sperimentale di tecnologie per la gestione dei dati per workflow ...
 
Publish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingPublish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based Routing
 
Un metodo di progettazione di reti locali con esigenze di qualità del servizio
Un metodo di progettazione di reti locali con esigenze di qualità del servizioUn metodo di progettazione di reti locali con esigenze di qualità del servizio
Un metodo di progettazione di reti locali con esigenze di qualità del servizio
 
Il Modello Pragmatico Elementare per lo sviluppo di Sistemi Adattivi - Tesi
Il Modello Pragmatico Elementare per lo sviluppo di Sistemi Adattivi - TesiIl Modello Pragmatico Elementare per lo sviluppo di Sistemi Adattivi - Tesi
Il Modello Pragmatico Elementare per lo sviluppo di Sistemi Adattivi - Tesi
 
Strategie ingestigative in ambito di criminalità informatica
Strategie ingestigative in ambito di criminalità informaticaStrategie ingestigative in ambito di criminalità informatica
Strategie ingestigative in ambito di criminalità informatica
 
Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codi...
Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codi...Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codi...
Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codi...
 
Sistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisitionSistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisition
 
Tesiandroid
TesiandroidTesiandroid
Tesiandroid
 
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
Tesi Specialistica - L'ottimizzazione delle risorse della Grid di EGEE median...
 
Dynamic Scheduling
Dynamic SchedulingDynamic Scheduling
Dynamic Scheduling
 

Mehr von Ce.Se.N.A. Security

Rilevamento di attacchi di rete tramite protocolli di monitoraggio per route...
 Rilevamento di attacchi di rete tramite protocolli di monitoraggio per route... Rilevamento di attacchi di rete tramite protocolli di monitoraggio per route...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per route...Ce.Se.N.A. Security
 
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...Ce.Se.N.A. Security
 
Exploit techniques - a quick review
Exploit techniques - a quick reviewExploit techniques - a quick review
Exploit techniques - a quick reviewCe.Se.N.A. Security
 
Msfpayload/Msfencoder cheatsheet
Msfpayload/Msfencoder cheatsheetMsfpayload/Msfencoder cheatsheet
Msfpayload/Msfencoder cheatsheetCe.Se.N.A. Security
 
Analisi sulla sicurezza di una autovettura moderna
Analisi sulla sicurezza di una autovettura modernaAnalisi sulla sicurezza di una autovettura moderna
Analisi sulla sicurezza di una autovettura modernaCe.Se.N.A. Security
 
Monitoraggio di mac address in lan
Monitoraggio di mac address in lanMonitoraggio di mac address in lan
Monitoraggio di mac address in lanCe.Se.N.A. Security
 
Crimini informatici e accesso abusivo
Crimini informatici e accesso abusivoCrimini informatici e accesso abusivo
Crimini informatici e accesso abusivoCe.Se.N.A. Security
 

Mehr von Ce.Se.N.A. Security (20)

Rilevamento di attacchi di rete tramite protocolli di monitoraggio per route...
 Rilevamento di attacchi di rete tramite protocolli di monitoraggio per route... Rilevamento di attacchi di rete tramite protocolli di monitoraggio per route...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per route...
 
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
Rilevamento di attacchi di rete tramite protocolli di monitoraggio per router...
 
Mona cheatsheet
Mona cheatsheetMona cheatsheet
Mona cheatsheet
 
Exploit techniques - a quick review
Exploit techniques - a quick reviewExploit techniques - a quick review
Exploit techniques - a quick review
 
Msfpayload/Msfencoder cheatsheet
Msfpayload/Msfencoder cheatsheetMsfpayload/Msfencoder cheatsheet
Msfpayload/Msfencoder cheatsheet
 
ICTF overview
ICTF overviewICTF overview
ICTF overview
 
Anonymous email
Anonymous emailAnonymous email
Anonymous email
 
Hacking reti wireless
Hacking reti wirelessHacking reti wireless
Hacking reti wireless
 
SELinux - overview
SELinux - overviewSELinux - overview
SELinux - overview
 
Analisi sulla sicurezza di una autovettura moderna
Analisi sulla sicurezza di una autovettura modernaAnalisi sulla sicurezza di una autovettura moderna
Analisi sulla sicurezza di una autovettura moderna
 
Sicurezza delle reti 802.11
Sicurezza delle reti 802.11Sicurezza delle reti 802.11
Sicurezza delle reti 802.11
 
Rilevamento intrusioni in wlan
Rilevamento intrusioni in wlanRilevamento intrusioni in wlan
Rilevamento intrusioni in wlan
 
Rainbow tables
Rainbow tablesRainbow tables
Rainbow tables
 
Network monitoring tramite snmp
Network monitoring tramite snmpNetwork monitoring tramite snmp
Network monitoring tramite snmp
 
Monitoraggio di mac address in lan
Monitoraggio di mac address in lanMonitoraggio di mac address in lan
Monitoraggio di mac address in lan
 
Insider attack
Insider attackInsider attack
Insider attack
 
Iena
IenaIena
Iena
 
Crimini informatici e accesso abusivo
Crimini informatici e accesso abusivoCrimini informatici e accesso abusivo
Crimini informatici e accesso abusivo
 
IENA
IENAIENA
IENA
 
BLUETOOTH SECURITY - part2
BLUETOOTH SECURITY - part2BLUETOOTH SECURITY - part2
BLUETOOTH SECURITY - part2
 

Kürzlich hochgeladen

IL CHIAMATO ALLA CONVERSIONE - catechesi per candidati alla Cresima
IL CHIAMATO ALLA CONVERSIONE - catechesi per candidati alla CresimaIL CHIAMATO ALLA CONVERSIONE - catechesi per candidati alla Cresima
IL CHIAMATO ALLA CONVERSIONE - catechesi per candidati alla CresimaRafael Figueredo
 
Esperimenti_laboratorio di fisica per la scuola superiore
Esperimenti_laboratorio di fisica per la scuola superioreEsperimenti_laboratorio di fisica per la scuola superiore
Esperimenti_laboratorio di fisica per la scuola superiorevaleriodinoia35
 
Storia dell’Inghilterra nell’Età Moderna.pptx
Storia dell’Inghilterra nell’Età Moderna.pptxStoria dell’Inghilterra nell’Età Moderna.pptx
Storia dell’Inghilterra nell’Età Moderna.pptxOrianaOcchino
 
Ticonzero news 148.pdf aprile 2024 Terza cultura
Ticonzero news 148.pdf aprile 2024 Terza culturaTiconzero news 148.pdf aprile 2024 Terza cultura
Ticonzero news 148.pdf aprile 2024 Terza culturaPierLuigi Albini
 
lezione di fisica_I moti nel piano_Amaldi
lezione di fisica_I moti nel piano_Amaldilezione di fisica_I moti nel piano_Amaldi
lezione di fisica_I moti nel piano_Amaldivaleriodinoia35
 
Esame finale - riunione genitori 2024.pptx
Esame finale - riunione genitori 2024.pptxEsame finale - riunione genitori 2024.pptx
Esame finale - riunione genitori 2024.pptxfedericodellacosta2
 
La seconda guerra mondiale per licei e scuole medie
La seconda guerra mondiale per licei e scuole medieLa seconda guerra mondiale per licei e scuole medie
La seconda guerra mondiale per licei e scuole medieVincenzoPantalena1
 
La produzione e la gestione degli Open Data
La produzione e la gestione degli Open DataLa produzione e la gestione degli Open Data
La produzione e la gestione degli Open DataGianluigi Cogo
 

Kürzlich hochgeladen (8)

IL CHIAMATO ALLA CONVERSIONE - catechesi per candidati alla Cresima
IL CHIAMATO ALLA CONVERSIONE - catechesi per candidati alla CresimaIL CHIAMATO ALLA CONVERSIONE - catechesi per candidati alla Cresima
IL CHIAMATO ALLA CONVERSIONE - catechesi per candidati alla Cresima
 
Esperimenti_laboratorio di fisica per la scuola superiore
Esperimenti_laboratorio di fisica per la scuola superioreEsperimenti_laboratorio di fisica per la scuola superiore
Esperimenti_laboratorio di fisica per la scuola superiore
 
Storia dell’Inghilterra nell’Età Moderna.pptx
Storia dell’Inghilterra nell’Età Moderna.pptxStoria dell’Inghilterra nell’Età Moderna.pptx
Storia dell’Inghilterra nell’Età Moderna.pptx
 
Ticonzero news 148.pdf aprile 2024 Terza cultura
Ticonzero news 148.pdf aprile 2024 Terza culturaTiconzero news 148.pdf aprile 2024 Terza cultura
Ticonzero news 148.pdf aprile 2024 Terza cultura
 
lezione di fisica_I moti nel piano_Amaldi
lezione di fisica_I moti nel piano_Amaldilezione di fisica_I moti nel piano_Amaldi
lezione di fisica_I moti nel piano_Amaldi
 
Esame finale - riunione genitori 2024.pptx
Esame finale - riunione genitori 2024.pptxEsame finale - riunione genitori 2024.pptx
Esame finale - riunione genitori 2024.pptx
 
La seconda guerra mondiale per licei e scuole medie
La seconda guerra mondiale per licei e scuole medieLa seconda guerra mondiale per licei e scuole medie
La seconda guerra mondiale per licei e scuole medie
 
La produzione e la gestione degli Open Data
La produzione e la gestione degli Open DataLa produzione e la gestione degli Open Data
La produzione e la gestione degli Open Data
 

Inoltro di pacchetti ip in sistemi linux

  • 1. ALMA MATER STUDIORUM – UNIVERSITÀ DI BOLOGNA SEDE DI CESENA SECONDA FACOLTÀ DI INGEGNERIA CON SEDE A CESENA CORSO DI LAUREA IN INGEGNERIA DELLE TELECOMUNICAZIONI TITOLO DELL’ELABORATO FUNZIONALITÀ AVANZATE PER L’INOLTRO DI PACCHETTI IP IN SISTEMI OPERATIVI LINUX Elaborato in LABORATORIO DI RETI DI TELECOMUNICAZIONI L-A Relatore Presentato da Cerroni Walter Zangheri Filippo Sessione II Anno Accademico 2005/2006
  • 2.
  • 3. A Elisa, luce dei miei occhi
  • 4.
  • 5. Indice Indice 1. Introduzione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Reti informatiche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1 Modello ISO/OSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1.1 Modularità. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1.2 Strato 1: fisico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1.3 Strato 2: linea. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1.4 Strato 3: rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1.5 Strato 4: trasporto. . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1.6 Strato 5: sessione. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1.7 Strato 6: presentazione. . . . . . . . . . . . . . . . . . . . . . 6 2.1.1.8 Strato 7: applicazione. . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2 Architettura TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2.1 Strato di collegamento. . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2.2 Strato di rete: protocollo IP. . . . . . . . . . . . . . . . . . . 7 2.1.2.3 Strato di trasporto. . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2.4 Strato di applicazione. . . . . . . . . . . . . . . . . . . . . . . 10 2.2 Routing nelle reti IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Protocollo ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 Consegna: diretta e indiretta. . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.4 Decisione di routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.5 Protocolli e algoritmi di routing. . . . . . . . . . . . . . . . . . . . . . 15 2.2.5.1 Algoritmi a cammino minimo. . . . . . . . . . . . . . . . 16 2.3 Routing in Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Policy Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3. Kernel Linux e pacchetti IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1 Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Kernel Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 i
  • 6. Indice 3.2.1 Scheduler dei processi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.2 Gestione della memoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.3 File System Virtuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.4 Comunicazione fra processi. . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.5 Sottosistema di rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.5.1 Dispositivi di rete. . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.5.2 Implementazione delle funzionalità di rete. . . . . . 24 3.3 Ricezione di pacchetti IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.1 Dalla scheda al kernel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.2 Processamento IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.3 Processamento locale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4 Instradamento IP in dettaglio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.1 Table lookup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.2 Attributi delle route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4.3 Tabelle di routing multiple. . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.4.4 Policy Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.5 Controllo del traffico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.6 Tunneling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4. Strumenti per il networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1 Netfilter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1.1 Punti di hook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2 Iptables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2.1 Tabelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.2.2 Configurazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2.3 Match. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.4 Casi di interesse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.4.1 Match random. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.4.2 Match tos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.4.3 Target MARK. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2.4.4 Target CLASSIFY. . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2.4.5 Altri usi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.5 Estensioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.5.1 Aggiunta di un’estensione: modulo random. . . . . 47 ii
  • 7. Indice 4.3 Iproute2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3.1 Funzionalità avanzate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4 Comando ip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.4.1 Gestione interfacce di rete. . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.1.1 ip link set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4.1.2 ip link show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4.2 Gestione indirizzi di rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.4.2.1 ip addr add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.4.2.2 ip addr delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.2.3 ip addr flush. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.2.4 ip addr show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.3 Gestione tabelle di routing. . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.4.3.1 ip route add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4.3.2 ip route change. . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.4.3.3 ip route replace. . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.4.3.4 ip route delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.4.3.5 ip route show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.4.3.6 ip route flush. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4.3.7 ip route get. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4.4 Gestione delle politiche di instradamento. . . . . . . . . . . . . . 64 4.4.4.1 ip rule add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.4.4.2 ip rule delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4.4.3 ip rule flush. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4.4.4 ip rule show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4.5 Gestione tunnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4.5.1 ip tunnel add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4.5.2 ip tunnel change. . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.4.5.3 ip tunnel delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.4.5.4 ip tunnel show. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.4.5.5 Esempi di tunnel. . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.5 Comando tc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.5.1 Discipline di accodamento. . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.5.1.1 Token Bucket Filter. . . . . . . . . . . . . . . . . . . . . . . . 72 iii
  • 8. Indice 4.5.1.2 tc qdisc add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.5.1.3 tc qdisc change. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.1.4 tc qdisc replace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.1.5 tc qdisc link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.1.6 tc qdisc delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.1.7 tc qdisc show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.2 Classi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.5.2.1 tc class add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.5.2.2 tc class change. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.5.2.3 tc class replace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.5.2.4 tc class show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.5.3 Filtri. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.5.3.1 tc filter add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.5.3.2 tc filter change. . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.5.3.3 tc filter replace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.5.3.4 tc filter delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.5.3.5 tc filter show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5. Esperimenti svolti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.1 Informazioni preliminari. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.1.1 Preparazione hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.1.2 Preparazione software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.2 Considerazioni iniziali: ripartizione del traffico. . . . . . . . . . . . . . . . . 82 5.2.1 Un passo indietro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.3 Esperimento 1. Bilanciamento del carico. . . . . . . . . . . . . . . . . . . . . . 83 5.3.1 Topologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.2 Funzionamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.3.1 Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.3.2 Inoltratori. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3.3.3 Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.3.4 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.4 Altre configurazioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.3.4.1 Sbilanciare il carico. . . . . . . . . . . . . . . . . . . . . . . . 89 iv
  • 9. Indice 5.3.5 Esecuzione esperimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.3.6 Aumentare i percorsi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.3.7 Bilanciamento sulla base dei percorsi. . . . . . . . . . . . . . . . . . 92 5.4 Considerazione ulteriore: ordinare i flussi. . . . . . . . . . . . . . . . . . . . . . 93 5.5 Esperimento 2. Policy Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.5.1 Topologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.5.2 Funzionamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.5.2.1 Politica di instradamento. . . . . . . . . . . . . . . . . . . . 95 5.5.3 Configurazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.3.1 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.4 Esecuzione esperimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.5.5 Aumentare i percorsi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.5.6 Policy Routing e ripartizione del carico. . . . . . . . . . . . . . . . 99 5.5.7 Policy Routing senza iptables. . . . . . . . . . . . . . . . . . . . . . . 100 5.6 Passo in avanti: assegnare la banda ai flussi. . . . . . . . . . . . . . . . . . . 100 5.7 Esperimento 3. Limitazione della banda. . . . . . . . . . . . . . . . . . . . . . 101 5.7.1 Topologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.7.2 Funzionamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.7.2.1 Assegnazione della banda. . . . . . . . . . . . . . . . . . 103 5.7.3 Configurazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.7.3.1 Sorgente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.7.3.2 Inoltratore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.7.3.3 Destinazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.7.3.4 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.7.4 Altre configurazioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.7.4.1 Bloccare le bande. . . . . . . . . . . . . . . . . . . . . . . . . 107 5.7.5 Esecuzione esperimento. . . . . . . . . . . . . . . . . . . . . . . . . . . 109 5.7.6 Classificazione dei pacchetti con tc. . . . . . . . . . . . . . . . . . 111 5.7.7 Limitazione della banda per ogni interfaccia. . . . . . . . . . . 111 5.7.8 Aumento della complessità. . . . . . . . . . . . . . . . . . . . . . . . . 111 5.8 Allegati. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 6. Conclusioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Bibliografia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 v
  • 10.
  • 11. Capitolo 1 - Introduzione Capitolo 1. Introduzione Essendo open-source, Linux ha sempre goduto del contributo di tantissimi sviluppatori, che nel tempo hanno donato al kernel le funzionalità derivanti dalle loro conoscenze. Questo ha fatto in modo che si sviluppasse un sistema operativo (liberamente utilizzabile e modificabile) estremamente flessibile e dotato di caratteristiche d’avanguardia che lo pongono in una posizione di tutto rispetto nello scenario dei sistemi operativi, commerciali e non. Le necessità che gli amministratori di reti informatiche hanno oggi, nell’applicare le politiche desiderate all’interno delle reti gestite, sono sempre più numerose e riguardano sempre di più la gestione ottimale del traffico. Per soddisfare esigenze sempre più dettagliate, sul mercato si trovano numerose soluzioni commerciali, più o meno onerose e affidabili. Con il passare degli anni, Linux ha costantemente visto accresciute e potenziate le proprie funzionalità di rete, che al giorno d’oggi hanno raggiunto un elevato livello di maturità, sia progettuale che implementativa. È importante notare, tuttavia, che si tratta di un sistema operativo molto dinamico, in costante fase di miglioramento e potenziamento. In questo elaborato si andranno a discutere alcuni esperimenti eseguiti al fine di comprendere quali siano le potenzialità che il kernel di Linux offre, per ciò che concerne alcuni degli aspetti avanzati di gestione del traffico di rete. 1
  • 12. Capitolo 1 - Introduzione 2
  • 13. Capitolo 2 - Routing Capitolo 2. Routing 2.1 Reti informatiche Una rete informatica è un sistema di risorse finalizzate alla interconnessione di un certo numero di calcolatori per permettere loro di scambiarsi informazioni. In particolare le informazioni trasmesse dai calcolatori viaggiano raggruppate in pacchetti di dati. Le reti si caratterizzano almeno per: 1. mezzi di trasmissione usati: segnali elettrici su cavo di conduttori, radiazione elettromagnetica guidata (fibra ottica) o in spazio libero (onde radio) con tecniche di trasmissione più o meno direttive a seconda che si tratti di collegamenti satellitari, ponti radio o reti locali senza fili (Wireless LAN); 2. topologia: connessione a stella, a maglia più o meno completa, a bus, ad anello; 3. protocolli di comunicazione usati. A seconda del grado di complessità, le reti possono essere suddivise in sottoreti e possono avvalersi di diversi mezzi di trasmissione, nonché di diverse topologie e anche differenti protocolli. 2.1.1 Modello ISO/OSI OSI, acronimo per Open Systems Interconnection[1], è un’emanazione dell’ISO, ente internazionale per gli standard. I suoi lavori cominciarono nel 1976 e portarono ad un modello di riferimento (Reference Model) chiamato OSI-RM, che è standard internazionale dal 1983 (ISO 7498). Il gruppo di lavoro nacque con lo scopo di definire uno schema modulare e aperto per la realizzazione di meccanismi di comunicazione automatici. Le finalità pratiche che si intendevano raggiungere puntavano a limitare la proliferazione di protocolli 3
  • 14. Capitolo 2 - Routing proprietari incapaci di interoperare con altri sistemi e fornire una visione del problema a blocchi. 2.1.1.1 Modularità Nel modello ISO/OSI il problema della comunicazione viene suddiviso in sette blocchi funzionali, ognuno dei quali dedicato a un problema specifico. Ogni blocco riceve informazioni dallo strato inferiore e comunica la propria elaborazione al blocco successivo. I blocchi, chiamati livelli o strati, formano una struttura a pila, in quanto la comunicazione fluisce dagli strati superiori verso quelli inferiori nel sistema trasmittente e percorre la strada opposta nel sistema ricevente. 2.1.1.2 Strato 1: fisico Alla base della pila OSI si trova lo strato fisico. Il suo scopo è attivare, mantenere e disattivare la connessione fisica fra due entità di livello 2. Questo strato è responsabile della definizione di tutti gli aspetti fisici relativi alla comunicazione. In sostanza si deve fare in modo che l’informazione “1” trasmessa da un capo del mezzo arrivi tale anche dall’altro capo. In questo strato si trovano le definizioni meccaniche dei connettori, le specifiche relative ai segnali elettrici, il significato che viene loro attribuito, le combinazioni e le sequenze di segnali all’interfaccia necessarie al fine di regolarne il funzionamento. Questo è l’unico strato che riguarda direttamente l’hardware, infatti i successivi livelli trattano il problema da un punto di vista logico, operando sui flussi di bit piuttosto che sui segnali elettrici. 2.1.1.3 Strato 2: linea Questo strato si occupa di attivare, mantenere e disattivare la connessione fisica fra due entità di strato 3 e renderne affidabile il collegamento diretto (punto- punto). Tipicamente le attività svolte sono: 1. strutturazione dei flussi di dati in unità di dialogo chiamate trame; 2. controllo e gestione degli errori di trasmissione; 4
  • 15. Capitolo 2 - Routing 3. controllo di flusso: accorda la velocità del trasmettitore alla capacità di elaborazione del ricevitore; 4. controllo di sequenza: verifica che le trame ricevute siano nella giusta sequenza; 5. gestione del protocollo di accesso per un collegamento punto- multipunto. 2.1.1.4 Strato 3: rete Questo strato provvede a definire il concetto di rete, intesa come insieme di sistemi autonomi che comunicano armonicamente entro un mezzo fisico di trasmissione. Ha come scopo quello di far giungere le unità di informazione (pacchetti) al destinatario, scegliendo la strada da percorrere attraverso la rete: si occupa dunque del problema della commutazione dei pacchetti e la funzione che svolge è chiamata routing (instradamento). Occorre individuare i destinatari deve, quindi, essere previsto un sistema di indirizzamento logico. Nel caso in cui si voglia costituire una rete unica che unisca logicamente tutte le sottoreti, occorre che lo schema di indirizzamento sia universale; occorre inoltre un protocollo di interconnessione di reti: da qui la definizione di IP (Internet Protocol). 2.1.1.5 Strato 4: trasporto Questo strato ha lo scopo di fornire un canale sicuro da capo a capo (end-to- end), svincolando gli strati superiori da tutte le problematiche di rete. Un compito tipico è l’adattamento della dimensione delle sequenze di dati fornite dagli strati superiori (file) a quella richiesta dalle reti (pacchetti). Viene denominata funzione di pacchettizzazione e opera in entrambe le direzioni (frammentazione e riassemblaggio). Questo strato può avere altre funzioni, come controllo d’errore, di flusso, gestione dei dati prioritari. Dal momento che non tutte le applicazioni hanno le stesse esigenze in fatto di trasmissione dei dati, si definiscono due principali classi di trasporto: connection-oriented (orientato alla connessione) e connectionless (non orientato alla connessione).. 5
  • 16. Capitolo 2 - Routing 2.1.1.6 Strato 5: sessione Suddivide il dialogo fra applicazioni remote in unità logiche chiamate sessioni. Una sessione deve essere individuata da opportuni parametri univoci, aperta, eventualmente interrotta e ripresa per far fronte a vari eventi catastrofici: perdita di dati, caduta della linea, momentaneo crash di uno dei due interlocutori. Permette la chiusura ordinata del dialogo con la garanzia che tutti i dati trasmessi siano arrivati a destinazione. 2.1.1.7 Strato 6: presentazione Adatta il formato dei dati usato dai due interlocutori (applicazioni) preservandone il significato, attraverso l’uso di una sintassi di trasferimento. 2.1.1.8 Strato 7: applicazione È l’utente della rete e perciò non fornisce servizi a nessuno. Rappresenta un programma applicativo che comunica con applicazioni remote nello svolgimento dei propri compiti. 2.1.2 Architettura TCP/IP I protocolli attuali sono generalmente modulari, ma ciò non significa che aderiscano pienamente al modello ISO/OSI, alcuni infatti possono racchiudere le funzionalità di più livelli in uno unico oppure essere privi di alcuni livelli. Oggi ISO/OSI è considerato un buon modello concettuale e un formidabile strumento di insegnamento, ma non è mai diventato la base universale su cui scrivere qualunque protocollo di comunicazione. La famiglia di protocolli TCP/IP nasce negli anni ’70 del XX sec. da una ricerca finanziata dal Dipartimento della Difesa statunitense e sono gli stessi protocolli usati al giorno d’oggi in Internet[1]. La loro definizione è praticamente contemporanea alla stesura del modello di riferimento OSI e hanno in comune con esso la modularità. 6
  • 17. Capitolo 2 - Routing 2.1.2.1 Strato di collegamento L’architettura TCP/IP prevede un primo strato denominato collegamento, il quale espleta le funzioni degli strati 1 e 2 di OSI. I protocolli che fanno parte della famiglia TCP/IP possono appoggiarsi su una grande varietà di protocolli di collegamento: PPP, ATM, IEEE 802.11, ma il più diffuso per le reti locali è Ethernet. Questo è diviso in due sottolivelli, ognuno dei quali implementa uno strato del modello OSI: Logical Link Control (LLC) e Media Access Control (MAC). Il primo è dedicato alle operazioni logiche del protocollo, mentre il secondo provvede alla comunicazione diretta con l’hardware. 2.1.2.2 Strato di rete: protocollo IP Il protocollo IP è definito dal RFC 791 (1981). Fu progettato per sistemi interconnessi a commutazione di pacchetto ed implementa le funzionalità dello strato di rete nell’architettura TCP/IP. Si prende carico della trasmissione di datagrammi da sorgente a destinazione, identificati secondo uno schema di indirizzamento a lunghezza fissa (32 bit). Se necessario procede alla frammentazione dei datagrammi in pacchetti, e li riassembla. IP è un protocollo non orientato alla connessione, esso è esplicitamente limitato per fornire le sole funzioni necessarie alla consegna dei pacchetti: non sono previsti meccanismi per l’aumento dell’affidabilità, né per il controllo di flusso o di sequenza, non fornisce insomma un servizio di comunicazione affidabile, ma di tipo best effort. L’affidabilità – ove necessaria – è demandata ai protocolli che si appoggiano su IP. Oggi Internet si appoggia alla versione 4 di IP (IPv4). 7
  • 18. Capitolo 2 - Routing Figura 1. Formato di un generico pacchetto IP 1. Version (versione): indica la versione utilizzata di IP, attualmente la versione 4 (IPv4). 2. IHL (IP Header Length): lunghezza dell’intestazione, espressa in parole di 32 bit. 3. Type of Service: indicazione sul tipo di servizio richiesto per questo pacchetto. È controverso, in quanto ha ripetutamente subito variazioni di significato negli anni. Attualmente è anche chiamato campo DS (Differentiated Services), e comprende 6 bit, come mostrato in figura, mentre gli ultimi due sono attualmente inutilizzati nelle applicazioni standard. 4. Total Length: lunghezza totale del datagramma, espressa in bytes. 5. Identification: valore intero che identifica univocamente un datagramma, si usa durante il riassemblaggio per risalire a quale datagramma appartengano i pacchetti (o frammenti). 6. Flags: bit 0: non usato (sempre zero); bit 1 (Don’t Fragment): se settato indica che non si può frammentare il datagramma; bit 2 (More Fragments): se settato indica che quello corrente non è l’ultimo frammento di un datagramma frammentato. 8
  • 19. Capitolo 2 - Routing 7. Fragment Offset: indica qual è la distanza del frammento corrente dall’inizio del datagramma, espressa in parole da 64 bit (dimensione del frammento elementare). 8. Time To Live: tempo massimo di permanenza del datagramma nella rete, è decrementato ogni volta che si attraversa un nodo intermedio. Un datagramma con TTL pari a zero viene scartato. 9. Protocol: indica il protocollo di livello superiore a cui appartengono i dati trasportati. 10. Header Checksum: controllo di errore della sola intestazione, viene ricalcolato da ogni nodo attraversato dal datagramma. 11. Source (Destination) Address: indirizzo sorgente (destinazione) del datagramma. 12. Options: campo di lunghezza variabile contenente informazioni opzionali. 13. Padding (riempimento): bit privi di significato in numero tale da fare in modo che il campo Options sia con certezza multiplo di 32 bit. 2.1.2.3 Strato di trasporto Fornisce servizio di connettività fra applicazioni che non risiedono sulla stessa macchina. Lo fa attraverso l’uso delle porte, che servono a differenziare i flussi di dati. Il protocollo di trasporto orientato alla connessione è il TCP (Transmission Control Protocol) (che implementa anche le funzionalità dello strato di sessione OSI), esso permette l’instaurazione di una comunicazione affidabile, nel senso che si preoccupa di garantire che tutti i dati siano consegnati al destinatario nella giusta sequenza, senza perdite né ripetizioni. Viene utilizzato tutte le volte che in un trasferimento di dati è importante la loro correttezza e che arrivino tutti quanti in sequenza. Il protocollo UDP (User Datagram Protocol) non è invece orientato alla connessione, non instaura nessuna connessione: quando è pronto ad inviare i dati, lo fa senza mai preoccuparsi della corretta ricezione. L’unico meccanismo di affidabilità che implementa è un minimo controllo degli errori. Questo protocollo è 9
  • 20. Capitolo 2 - Routing utilizzato soprattutto nelle trasmissioni audio/video attraverso la rete, nelle quali non è di vitale importanza che tutti i pacchetti arrivino a destinazione, ma una buona percentuale di essi, tale da permettere la fruizione del contenuto multimediale da parte di un essere umano. 2.1.2.4 Strato di applicazione Lo strato che utilizza i servizi dello strato di trasporto è quello di applicazione. Questo, come nel modello OSI, rappresenta il processo che fa uso della rete per svolgere le proprie attività. La famiglia di protocolli TCP/IP prevede anche l’esistenza di protocolli direttamente incapsulati in IP, che non fanno uso di protocolli di trasporto. Questi sono ad esempio ICMP (usato per la segnalazione) e OSPF (protocollo di routing). Figura 2. Architetture OSI e TCP/IP a confronto 10
  • 21. Capitolo 2 - Routing 2.2 Routing nelle reti IP Il meccanismo che decide quale è il tragitto che un pacchetto deve seguire per andare dal mittente al destinatario è chiamato routing[2] (instradamento). Essendo IP un protocollo non orientato alla connessione, ogni pacchetto è instradato in maniera indipendente dagli altri, ciò significa che i diversi pacchetti che compongono uno stesso messaggio possono arrivare a destinazione attraverso sequenze di nodi differenti; inoltre i pacchetti possono arrivare a destinazione in maniera non ordinata, o alcuni di questi non arrivare affatto. le esigenze di integrità e ordine non sono obiettivi dei meccanismi di routing, poiché i processi di routing hanno visibilità solo dei singoli pacchetti e non di un messaggio nel suo complesso. Coloro che effettuano l’instradamento dei pacchetti, e che tengono connesse l’una all’altra le reti IP, sono macchine dette router. Il metodo di instradamento utilizzato dal protocollo IP è alquanto semplice, esso consiste nel trasferire il pacchetto da un nodo all’altro, fino a quello di destinazione, attraverso salti (hop) successivi. 2.2.1 Protocollo ARP Il protocollo ARP (Address Resolution Protocol), come specificato da RFC 826, è un protocollo che fornisce la "mappatura" tra l' indirizzo IP a 32bit (4byte) di un’interfaccia e il suo indirizzo MAC, l' indirizzo fisico a 48bit (6 byte). ARP è utilizzato in una rete di calcolatori che utilizzi il protocollo IP sopra una rete di livello di collegamento che supporti il servizio di broadcast. Se questo servizio non è disponibile, come ad esempio in ATM, devono essere utilizzati altri meccanismi. L' host che vuole conoscere l’indirizzo MAC di un altro host, di cui conosce l' indirizzo IP, invia una richiesta ARP (ARP-request), contenente l' indirizzo IP dell' di destinazione. La richiesta viene incapsulata in una trama di livello di host collegamento indirizzata all’indirizzo broadcast di collegamento (per Ethernet è FF:FF:FF:FF:FF:FF), così tutti i calcolatori della sottorete ricevono la richiesta. In ciascuno di essi il protocollo ARP verifica se viene richiesto il proprio indirizzo IP. L' host di destinazione che riconoscerà il proprio IP nel pacchetto di ARP- 11
  • 22. Capitolo 2 - Routing request, provvederà ad inviare una risposta (ARP-reply) in unicast (un solo destinatario) all' indirizzo MAC sorgente. L’host che aveva inviato la richiesta, potrà leggere l’indirizzo MAC desiderato nel campo indirizzo sorgente della trama di risposta. In questo modo, ogni host può scoprire l' indirizzo fisico degli altri host sulla stessa sottorete. Bisogna osservare che il protocollo ARP viene usato tutte le volte che un host collegato ad una LAN deve inviare un messaggio ad un host sulla stessa LAN di cui conosce unicamente l' indirizzo di livello rete (IP), quindi lavora solo in sottoreti locali (non può attraversare router). In ogni calcolatore, il protocollo ARP tiene traccia delle risposte ottenute in una apposita cache, per evitare di utilizzare ARP prima di inviare ciascun pacchetto. Le voci della cache ARP vengono cancellate dopo un certo tempo di inutilizzo. 2.2.2 Consegna: diretta e indiretta La logica di funzionamento del routing è la seguente: il mittente – che è a conoscenza del proprio indirizzo, della sottorete IP in cui è situato e dell’indirizzo del destinatario – è in grado di sapere se il destinatario si trova nella sua stessa sottorete oppure no. In caso affermativo viene effettuata consegna diretta[1]: il pacchetto viene passato al protocollo di livello sottostante (livello 2 ISO/OSI, Collegamento), in reti di tipo Ethernet, viene trovato l’indirizzo MAC del destinatario usando il protocollo ARP, quindi il pacchetto IP è incapsulato dentro ad una trama Ethernet, la quale viene spedita sulla rete. In questo caso il pacchetto IP non attraversa alcun nodo intermedio. 12
  • 23. Capitolo 2 - Routing Figura 3. Consegna diretta di un pacchetto IP Se, al contrario, l’indirizzo del destinatario non fa parte della stessa sottorete del mittente, il pacchetto IP viene inviato – tramite consegna diretta – ad un router, il quale se riesce a fare consegna diretta al destinatario, la effettua, altrimenti spedisce il pacchetto ad un altro router, e così via. Se i router sono configurati in modo che le loro informazioni siano consistenti fra loro, il pacchetto arriverà a destinazione. Questa è detta consegna indiretta. Figura 4. Consegna indiretta di un pacchetto IP 2.2.3 Router Un router è un dispositivo fisico – oppure software che viene eseguito su un calcolatore – il quale determina il successivo punto della rete a cui inoltrare un 13
  • 24. Capitolo 2 - Routing pacchetto, nella sua strada verso la destinazione. I router formano una struttura interconnessa e cooperante: i datagrammi passano dall’uno all’altro finché raggiungono quello che può consegnarli direttamente al destinatario. In un router sono presenti due funzioni distinte: routing e inoltro[2]. La funzione di routing permette di decidere il percorso del pacchetto ed è volta a creare e mantenere aggiornate le tabelle di routing locali attraverso lo scambio di informazioni con gli altri router (usando protocolli di routing) e l’elaborazione locale (usando algoritmi di routing). Occorre che questa funzione sia standardizzata al fine di avere coerenza nel comportamento dei router. La funzione di inoltro opera il trasferimento del pacchetto dall’interfaccia di ingresso a quella di uscita, per farlo si avvale di un algoritmo di inoltro, il quale prevede 3 fasi: 1. estrazione dell’indirizzo destinazione dall’intestazione del pacchetto; 2. consultazione della tabella di routing (table lookup); 3. identificazione dell’interfaccia di uscita su cui inoltrare il pacchetto . Le tabelle di routing contengono le informazioni necessarie per l’instradamento di tutti i pacchetti che transitano attraverso il router. Ogni voce della tabella di routing (route) è contraddistinta dai seguenti parametri: 1. <indirizzo di destinazione> / <maschera> 2. interfaccia di rete da usare per raggiungerla (alla quale sarà inoltrato il pacchetto); 3. metodo di consegna (diretta o indiretta); 4. indirizzo del prossimo nodo (next hop) a cui consegnare il pacchetto in caso di consegna indiretta; 5. costo (metrica) per raggiungere la destinazione usando tale percorso. Il costo può essere associato a qualsiasi parametro del percorso di rete cui si riferisce, ad esempio può essere proporzionale all’inverso della larghezza di banda offerta dal canale, oppure proporzionale alla lunghezza fisica del mezzo di comunicazione, oppure legato al costo monetario dell’utilizzo di tale canale. 14
  • 25. Capitolo 2 - Routing La consultazione della tabella avviene seguendo l’algoritmo longest prefix match[2], ovvero vengono confrontate per prime le destinazioni che presentano la maschera di rete più lunga, in quanto rappresentano destinazioni più specifiche. Al limite la maschera ha 32 bit a “1”, che corrisponde ad un indirizzo singolo. 2.2.4 Decisione di routing Per ogni pacchetto che deve instradare, la funzione di instradamento del router deve prendere la cosiddetta decisione di routing, che consiste nel decidere verso quale interfaccia di rete inoltrare il pacchetto, perché questo venga trasmesso lungo il canale a cui è connessa tale interfaccia. Il metodo tradizionale – e più semplice – di prendere la decisione di routing è il cosiddetto routing basato sulla destinazione (destination-driven routing), secondo cui tale decisione è presa solo in base all’indirizzo di destinazione presente nell’intestazione del pacchetto stesso. 2.2.5 Protocolli e algoritmi di routing Esistono due tipi di routing[2]: quello statico e quello dinamico, in quello statico le informazioni presenti nelle tabelle non variano nel tempo e non dipendono dallo stato del traffico nella rete, per modificarle occorre l’intervento manuale degli amministratori di rete. Nel routing dinamico le tabelle sono create e periodicamente aggiornate in modo automatico. Si presta facilmente alla variazione della decisione di instradamento in base allo stato della topologia della rete o del traffico. In questo caso i router si scambiano informazioni riguardanti la topologia della rete utilizzando opportuni protocolli di routing. Il routing può essere di tipo centralizzato o distribuito[2]. Nel caso centralizzato un nodo centrale si occupa di raccogliere le informazioni riguardanti la topologia della rete, calcolare le tabelle di routing per ogni altro router e consegnare ad ognuno la propria. Nel caso distribuito ogni router calcola le proprie tabelle di routing, lo può fare sulla base di informazioni locali (informazioni che raccoglie da solo senza scambiare dati con altri router) oppure distribuite: si fa un’idea della topologia della rete 15
  • 26. Capitolo 2 - Routing attraverso lo scambio di dati con gli altri router. Deve quindi essere previsto un modo per fare avvenire lo scambio di queste informazioni fra router: i protocolli di routing servono a questo. Algoritmo e protocollo di routing di un router vanno di pari passo, infatti il secondo è conseguenza del primo. Alcuni algoritmi non necessitano di protocolli, in quanto non hanno bisogno di informazioni sulla topologia della rete, sono: Flooding (inondazione, replica il pacchetto ricevuto in ingresso su tutte le altre interfacce, con qualche miglioramento); Deflection Routing, chiamato anche Hot Potato (patata bollente, inoltra il pacchetto sull’interfaccia che ha il minor numero di pacchetti nella coda di trasmissione). 2.2.5.1 Algoritmi a cammino minimo Esistono altri algoritmi, come Distance Vector e Link State, i quali adottano protocolli omonimi. Questo due tipi di algoritmi appartengono alla famiglia del routing a cammino minimo[2]: attribuiscono ad ogni collegamento di rete una lunghezza, ottengono informazioni dagli altri router, elaborano la loro visione di quella che è la topologia della rete, cercano il cammino minimo che collega ogni possibile sorgente con ogni possibile destinazione. In generale esistono diversi cammini che collegano una sorgente con una destinazione, e se si usa sempre lo stesso (il minimo) si rischia di congestionare sempre gli stessi tratti di rete, così si ricorre ad un uso probabilistico della tabella di routing, ovvero instradando i pacchetti anche lungo percorsi diversi da quello minimo, questo può creare problemi per quanto riguarda la ricezione dei pacchetti fuori sequenza, ma tale discorso esula dagli scopi di questo elaborato. I protocolli di tipo Distance Vector sono semplici e richiedono poche risorse, ad ogni passo ogni router invia ai propri vicini un vettore contenente la stima della propria distanza da tutti gli altri router della rete (quelli di cui è a conoscenza), sono lenti nella convergenza, hanno problemi di instabilità nel caso di particolari interruzioni dei collegamenti, non sono adatti a topologie complesse, esistono miglioramenti che ne riducono i problemi. Per eliminarli è stata creata un’evoluzione di questi protocolli: Path Vector. 16
  • 27. Capitolo 2 - Routing I protocolli Link State hanno come scopo fondamentale quello di permettere ad ogni router di crearsi l’immagine della rete, per prima cosa vengono scoperti i propri vicini, poi si misura la distanza da essi, infine si inviano le proprie informazioni sui vicini a tutti gli altri router della rete con tecnica di tipo Flooding. Sono protocolli robusti e performanti, ma richiedono più risorse in termini di banda e potenza di calcolo dei singoli router. I protocolli Distance Vector RIP (Routing Information Protocol, RFC 1058), RIP2 (RFC 2453), sono trasportati da UDP. Il protocollo Link State OSPF (Open Shortest Path First RFC 1247, OSPF2 RFC 2328), incapsulato direttamente in IP (protocollo 89), è pensato appositamente per gestire reti di grandi dimensioni, intrinsecamente diffusive o punto-punto, separare logicamente gli host dai router. Permette di effettuare routing gerarchico, ovvero scomporre la rete in porzioni, ognuna delle quali è sotto il controllo di un sottoinsieme di tutti i router, i quali si scambiano messaggi relativi solo alla zona di competenza (area di routing). Se questi router si trovano a dover instradare messaggi non destinati a tale zona, li passano a router di livello gerarchico superiore, che hanno una visione sempre più d’insieme della rete e sempre meno di dettaglio. Esistono due livelli gerarchici: Autonomous System e Area (vedere prossimo paragrafo). 2.3 Routing in Internet In Internet si usa il routing gerarchico e le aree di routing sono chiamate Autonomous System[2] (AS). Un Autonomous System si definisce come rete di calcolatori gestita da un unico ente, nella quale vengono imposte le stesse politiche e gli stessi protocolli di routing. Occorre però accordarsi sull’utilizzo dello stesso protocollo all’esterno: per poter realizzare un instradamento globale e consentire a un datagramma di uscire dall’AS di origine e giungere ad una destinazione situata al di fuori. Normalmente gli AS sono reti di dimensioni geografiche, ulteriormente suddivise in aree di routing. I protocolli di routing usati all’interno di un AS sono del tipo Interior Gateway Protocol (IGP), fanno parte di questa famiglia RIP e OSPF; mentre quelli usati internamente fanno parte della categoria Exterior Gateway Protocol (EGP). 17
  • 28. Capitolo 2 - Routing Protocolli esterni sono: EGP (Exterior Gateway Protocol), BGP (Border Gateway Protocol), ora alla versione 4 (RFC 1771). BGP è di tipo Path Vector. I protocolli esterni utilizzano TCP per il trasporto, in quanto devono poter contare su una comunicazione affidabile. Per rendere più efficiente e performante la consultazione delle tabelle di routing dei router di Internet, ovvero quelli che interconnettono fra loro più AS, si è imposta la regola che ogni sottorete IP deve essere contenuta completamente dentro un AS, più specificamente nella stessa area di routing. Infatti così facendo, ogni sottorete occupa una sola riga nelle tabelle di routing dei router di bordo. 2.4 Policy Routing Significa instradamento basato su politiche prestabilite[2]. Fare Policy Routing significa estendere il concetto base di routing introducendo due ulteriori aspetti caratterizzanti, volti ad estendere il dominio di pertinenza dell’instradamento sia dal punto di vista tecnico che da quello logico. Questi due nuovi aspetti sono: 1. la possibilità di discriminare i pacchetti non solo in base al loro indirizzo di destinazione, ma anche in base a tutti gli altri campi dell’intestazione IP, nonché ciò che fa parte del contenuto informativo dei datagrammi; 2. la possibilità di definire politiche di instradamento sulle quali basare le decisioni di routing. Dal secondo punto scaturisce l’esigenza di riorganizzare il database delle informazioni di routing: esso diviene una struttura più complessa, chiamata Routing Policy DataBase (RPDB). Il RPDB riflette le politiche di instradamento ed è la lista delle regole di routing definite dagli amministratori di rete. Queste regole – come detto sopra – possono essere applicate ad ogni parametro dei datagrammi. Con il Policy Routing si perviene alla decisione di instradamento non scorrendo le voci di una tabella di routing secondo la lunghezza del prefisso, ma applicando una serie di regole in ordine di priorità – imposta dagli amministratori di rete stessi. Ogni regola consiste in un selettore ed un’azione, se il selettore corrisponde al 18
  • 29. Capitolo 2 - Routing pacchetto viene eseguita l’azione. In sistemi semplici l’azione consiste spesso nello scegliere next hop e interfaccia di uscita. Una possibile applicazione di Policy Routing è quella di instradare pacchetti relativi a traffici prioritari lungo percorsi ritenuti più veloci o maggiormente affidabili, oppure impedire l’inoltro nel proprio Autonomous System di traffico proveniente da determinate sottoreti, o ancora, instradare il traffico proveniente da determinati indirizzi verso determinati percorsi (source-driven routing). Da quanto detto in precedenza riguardo gli Autonomous System, cioè che in essi vengono applicate le medesime politiche di instradamento, si vede facilmente che i router di bordo (quelli che interconnettono più AS) eseguono Policy Routing. 19
  • 30. Capitolo 2 - Routing 20
  • 31. Capitolo 3 - Kernel Linux e pacchetti IP Capitolo 3. Kernel Linux e pacchetti IP 3.1 Linux Linux è un sistema operativo nato nel 1991 dal progetto personale di un laureando in informatica dell’università di Helsinki, in Finlandia. Tale Linus Torvalds portò avanti il progetto prima in casa propria, poi ne fece la propria tesi di laurea, infine decise di rendere pubblici i codici sorgenti e liberamente modificabili, sotto la licenza GPL (Gnu General Public License). Il motivo dell’esistenza di Linux è il fatto che Torvalds sentì il bisogno di utilizzare anche sul proprio calcolatore domestico (PC con processore Intel 80386) le applicazioni di cui usufruiva in ambiente accademico, che erano eseguite su calcolatori dotati del sistema operativo Minix, discendente di Unix. Da subito il progetto entusiasmò una discreta cerchia di programmatori che, sparsi in tutto il mondo, cominciarono a scambiarsi idee, suggerimenti e risultati attraverso la nascente Internet. Oggi Linux è famoso per la grande flessibilità e potenza. La comunità degli sviluppatori ha raggiunto proporzioni inimmaginabili allora, e Linus è ancora uno dei programmatori più attivi. Esistono tantissime distribuzioni di Linux, che ne esaltano diverse peculiarità, rendendo disponibili sistemi operativi altamente specializzati. 3.2 Kernel Linux Il sistema operativo Linux si compone di programmi di sistema e kernel[3]. Il kernel di un sistema operativo in generale è il suo cuore; è la porzione di codice che viene caricata per prima in memoria, trova la sua collocazione logica subito sopra l’hardware e si occupa di fornire funzionalità alle altre componenti del sistema operativo. Linux ha un kernel di tipo monolitico, questo è infatti un unico grande blocco che fornisce tutte le funzionalità, ma può avvalersi di moduli separati, i quali possono essere compilati, caricati e rimossi dalla memoria indipendentemente dal resto del 21
  • 32. Capitolo 3 - Kernel Linux e pacchetti IP kernel. Senza dubbio i moduli rappresentano uno dei maggiori punti di forza di questo sistema operativo. Il kernel Linux è suddiviso in cinque sottosistemi, ognuno dei quali gestisce la propria area di competenza. 3.2.1 Scheduler dei processi Gestisce le politiche di accesso[3] al processore da parte dei vari processi; il corretto accesso ai dispositivi hardware nella corretta tempistica; controlla che tutti i processi abbiano accesso al processore in tempi ragionevoli. Le politiche di scheduling sono applicate sia ai processi utente che a quelli relativi ad altri sistemi componenti il kernel. Questo sottosistema si compone di quattro moduli logici: quello che prende la decisione di allocare il processore ad un processo, quello che dialoga con il processore (ad esempio per ripristinare nei registri i valori afferenti il processo che sta prendendo il controllo in un dato istante), quello che permette ai processi utente di accedere solo alle interfacce esplicitamente esportate (ad esempio le chiamate di sistema per creare/distruggere nuovi processi) e, infine, il modulo che rende possibile il dialogo fra gli altri moduli. 3.2.2 Gestione della memoria Gestisce le politiche di condivisione della memoria fisica[3]; le politiche di accesso alle porzioni critiche di memoria; la possibilità di definire aree riservate ad un solo processo; la memoria virtuale: fa credere ai processi che vi sia a disposizione molta più memoria (RAM) rispetto a quella realmente disponibile, copiando porzioni di memoria non usata in una determinata regione del disco fisso, liberando così quella centrale per il processo in esecuzione. Definisce gli schemi e le regole per un’equa assegnazione di memoria ai processi. 22
  • 33. Capitolo 3 - Kernel Linux e pacchetti IP 3.2.3 File System Virtuale Ha lo scopo di rendere possibile l’accesso a diversi dispositivi hardware, che utilizzano differenti tipi di file system[3]; rendere possibile l’esecuzione di differenti formati di file; usare la stessa interfaccia per accedere a qualsiasi tipo di dispositivo e file system. Tutto ciò nel minor tempo, evitando perdite di dati e in maniera sicura. Il File System Virtuale permette di astrarre e fa in modo che un processo acceda alle risorse senza sapere quale dispositivo hardware sta utilizzando. Qui sono definite le politiche di utilizzo per i vari dispositivi (a blocchi e a caratteri) e le relative interfacce, che vengono rese disponibili per i processi utente. Il kernel possiede un modulo di device driver per ogni dispositivo hardware con cui interfacciarsi. 3.2.4 Comunicazione fra processi Rende possibile il trasferimento di dati fra processi in esecuzione sulla stessa macchina mettendo a disposizione un’interfaccia specifica e predisponendo i meccanismi necessari, come ad esempio le pipe per la comunicazione diretta o lo shared memory, meccanismo di comunicazione indiretta basato su aree di memoria condivise fra più processi, i quali vi accedono in lettura e scrittura[3]. 3.2.5 Sottosistema di rete Gestisce l’invio di dati all’esterno della macchina e la loro ricezione attraverso i dispositivi di rete, nonché il processamento locale; fornendo un adeguato livello di astrazione rispetto alle peculiarità del singolo dispositivo hardware. 3.2.5.1 Dispositivi di rete Linux definisce le interfacce di rete come una classe di dispositivi a sé stante[4], e le considera entità che inviano e ricevono pacchetti di dati, siano esse fisiche o logiche, come nel caso del dispositivo di loopback, usato per trasferire dati 23
  • 34. Capitolo 3 - Kernel Linux e pacchetti IP alla propria macchina. Ogni dispositivo ha il proprio device driver, che consiste in un modulo del kernel in grado di comunicare direttamente con il controller (chip di controllo) montato sul dispositivo. Per poter fare uso del dispositivo associato, il modulo si deve registrare con il kernel durante la fase di avviamento della macchina oppure all’atto del caricamento in memoria del modulo stesso. 3.2.5.2 Implementazione delle funzionalità di rete L’implementazione delle funzionalità di rete in Linux è modellata sulla base di BSD 4.3 – fra le prime versioni di Unix ad introdurre funzionalità di rete – ed in particolare supporta tutta la gamma di protocolli TCP/IP[4]. La decisione di basarsi su questa implementazione fu dettata dalla grande popolarità che godeva in quel periodo e, dunque, in quel modo le applicazioni di rete sarebbero state facilmente portabili da Linux alle altre piattaforme Unix e viceversa. Proprio come i protocolli di rete stessi, Linux implementa la famiglia dei protocolli Internet come una serie di strati software connessi tra loro. Il kernel mette a disposizione delle applicazioni di rete un’interfaccia chiamata “socket BSD”, che non solo supporta differenti forme di networking, ma è anche un meccanismo di comunicazione tra processi. Un socket descrive un capo di una comunicazione: due processi che comunicano fra loro hanno ciascuno il proprio. Un socket può essere pensato anche come caso particolare di pipe, con la differenza che non vi sono limiti di dati che un socket può contenere. Un socket BSD può essere di varia natura: 1. Flusso: la comunicazione è bidirezionale ed avviene all’interno di una connessione stabilita, la quale viene aperta, mantenuta, eventualmente interrotta e infine chiusa. Questo tipo di socket è supportato dal protocollo TCP. 2. Datagramma: comunicazione bidirezionale senza garanzia sulla ricezione, la correttezza e la sequenza dei dati. Supportato da UDP. 3. Grezzo: permette ai processi un accesso diretto ai protocolli inferiori per osservare, ad esempio, il flusso di informazioni – grezze appunto – che 24
  • 35. Capitolo 3 - Kernel Linux e pacchetti IP transitano lungo un’interfaccia, oppure forgiare direttamente pacchetti IP senza passare per protocolli di strato 4. 4. Datagramma a consegna affidabile: molto simili ai socket di tipo Datagramma, ma garantiscono la consegna dei dati. 5. Sequenza di pacchetti: assomigliano molto ai socket di tipo Flusso, ma i pacchetti hanno tutti la stessa dimensione. 6. Pacchetto: non è standard BSD, ma un’estensione di Linux che permette alle applicazioni di accedere ai pacchetti al livello di dispositivo. Linux supporta diverse classi di socket, dette anche famiglie di indirizzi, quella per le comunicazioni attraverso protocolli TCP/IP prende il nome di “inet address family”. 3.3 Ricezione di pacchetti IP Nella seguente descrizione si farà riferimento al caso di calcolatore collegato ad una rete di tipo Ethernet, in quanto è la tipologia più diffusa e non comporta differenze significative rispetto ad altre tecnologie. La scheda Ethernet ha un indirizzo univoco impostato internamente e rimane in costante ascolto sulla linea. Quando vede un pacchetto (trama) il cui indirizzo MAC di destinazione corrisponde al proprio o a quello di broadcast dello strato di collegamento, inizia a leggerlo memorizzandolo in una memoria di ricezione[5]. 3.3.1 Dalla scheda al kernel Al compimento della ricezione del pacchetto, la scheda di rete genera una richiesta di interruzione[5] (interrupt), forzando il processore ad eseguire una determinata porzione di codice presente nel device driver della scheda di rete. Durante questa esecuzione non può ricevere interruzioni. Il device driver alloca una nuova struttura dati rappresentante la visione che il kernel ha di un pacchetto; riempie questa struttura dati prelevando le informazioni dalla memoria della scheda di rete; prepara il kernel per il prossimo passo della ricezione: mette il pacchetto dentro la coda d’ingresso. Qui, se la coda è piena il 25
  • 36. Capitolo 3 - Kernel Linux e pacchetti IP pacchetto viene scartato e perso per sempre. In questa fase vengono raccolti e fatti convergere in un’unica coda, tutti i pacchetti provenienti da tutti i device driver di tutte le interfacce. La coda porta al processamento del pacchetto da parte degli strati superiori. Dal momento che questa operazione è eseguita con le interruzioni disabilitate, deve essere molto veloce: non può effettuare lunghi controlli o altre operazioni complesse perché il sistema sta potenzialmente perdendo pacchetti durante l’esecuzione di questa funzione. Quindi quello che fa è identificare uno stato di congestione della coda (con cinque possibili stati). In condizioni normali il pacchetto è accodato e la funzione termina, riabilitando le interruzioni. Una routine specializzata si occupa di estrarre dalla coda d’ingresso i pacchetti uno ad uno e di eseguire in sequenza le routine di gestione dei protocolli specifiche per quel tipo di pacchetto. 3.3.2 Processamento IP All’avvio del kernel, o quando viene creato un certo tipo di socket, si registrano con il kernel determinate routine di gestione dei protocolli specificando per quali tipi di pacchetti devono essere eseguite[5]. Quelle per pacchetti generici vengono eseguite per prime, mentre per ultime sono invocate quelle relative a specifici protocolli. Ciò è eseguito per tutti i pacchetti presenti nella coda fino a quando non sono stati processati un numero massimo di pacchetti, o non è trascorso troppo tempo (tipicamente 10 ms). Sul pacchetto IP si eseguono tutti i controlli iniziali, che principalmente riguardano la verifica della sua integrità (checksum, campi dell’intestazione e lunghezza minima significativa); se il pacchetto risulta corretto viene processato dallo stadio di pre-instradamento (PREROUTING) di netfilter – la cui descrizione è rimandata al capitolo seguente. Successivamente viene eseguita una decisione di instradamento preliminare, si controlla, infatti, se il pacchetto deve essere inoltrato ad un’altra macchina o se è destinato a quella locale. Nel primo caso viene eseguito l’instradamento e il pacchetto viene spedito all’esterno attraverso la giusta interfaccia, passando per gli stadi di inoltro (FORWARD) e post-instradamento (POSTROUTING) di netfilter; 26
  • 37. Capitolo 3 - Kernel Linux e pacchetti IP altrimenti procede verso gli strati superiori nel calcolatore locale. Il controllo passa, poi, nelle mani della funzione del protocollo IP che si occupa del riassemblaggio dei datagrammi, la quale – ove necessario – si fa carico della ricostruzione dei datagrammi partendo dai loro frammenti. Fatto ciò, il pacchetto passa attraverso lo stadio di ingresso (INPUT) di netfilter. Per quanto riguarda il processamento di strato 3, questo si conclude eliminando l’intestazione IP al datagramma. Se il pacchetto risulta appartenere ad un socket IP grezzo, si saltano i protocolli di strato di trasporto arrivando direttamente alle applicazioni attraverso questo tipo di socket. Tuttavia, molto più comunemente il pacchetto sarà diretto verso un ulteriore gestore di protocollo dentro il kernel. Per determinare quale protocollo sia, si esamina il campo Protocol dell’intestazione IP. A questo stadio è presente una lista che contiene tutti i protocolli post-IP registrati al caricamento del kernel. Per ognuno di questi protocolli è definita una funzione di ricezione dei pacchetti. 3.3.3 Processamento locale Appena determinato il protocollo, viene richiamata la sua funzione di ricezione[6]. Vi sono grandi differenze nelle modalità di processare i pacchetti fra TCP e UDP, in quanto quest’ultimo è molto meno complesso, non essendo orientato alla connessione. Per quanto riguarda il TCP, vengono eseguiti i controlli di integrità dell’intestazione, poi si cerca un socket a cui corrisponda il pacchetto in questione, se non si trova, causa l’invio di un pacchetto ICMP di tipo “Destinazione non raggiungibile” e scarta il pacchetto. Se al socket era stato impostato un filtro, questo viene applicato per primo, e se il pacchetto non corrisponde viene scartato. Il filtro può anche specificare una dimensione massima, e se il pacchetto la eccede, viene “accorciato” fino a riportarlo alla lunghezza desiderata. Il viaggio del pacchetto procede secondo strade differenti a seconda dello stato corrente del socket, giungendo infine ai processi che fanno uso delle funzionalità di rete. Il protocollo UDP esegue solo i controlli di integrità dell’intestazione e cerca di attribuire il pacchetto ad un socket. Dopodiché il pacchetto è scartato oppure passato al processo creatore del socket. 27
  • 38. Capitolo 3 - Kernel Linux e pacchetti IP 3.4 Instradamento IP in dettaglio La funzione di instradamento è richiamata ogni qual volta un pacchetto deve essere trasmesso, sia che esso provenga dal calcolatore locale, sia che provenga da una macchina remota. In quest’ultimo caso deve essere abilitata l’opzione di inoltro dei pacchetti IP nel kernel affinché il pacchetto venga reinstradato, altrimenti è scartato. 3.4.1 Table lookup Per sapere a quale interfaccia inoltrare il pacchetto, il kernel esegue il cosiddetto table lookup (consultazione della tabella di routing). Ogni route della tabella è caratterizzata da una chiave univoca[7] che consiste nel prefisso, ovvero la coppia formata da indirizzo di rete e maschera (che indica la lunghezza del prefisso), e opzionalmente il valore di Type Of Service (TOS). Un pacchetto IP corrisponde alla route se i bit più significativi dell’indirizzo di destinazione del pacchetto sono uguali a quelli del prefisso della route almeno fino alla lunghezza del prefisso stesso (indicata dalla maschera), e se il TOS della route è zero o uguale al TOS del pacchetto. Se un pacchetto trova corrispondenza con più di una route, si seguono le seguenti regole: 1. si scelgono le route con prefisso più lungo, scartando quelle con prefissi più corti; 2. se il TOS di qualche route rimanente è uguale al TOS del pacchetto, allora le route con TOS differente sono scartate; 3. se fra le rimanenti non vi sono route con lo stesso valore di TOS del pacchetto, ma ve ne sono con TOS pari a zero, le altre sono scartate; altrimenti la consultazione della tabella di routing fallisce, il pacchetto è scartato. 4. se rimane più di una route valida dopo i precedenti passaggi, sono selezionate le route con migliore valore di metrica (il minore); 5. se esiste ancora più di una route, viene selezionata la prima fra esse. 28
  • 39. Capitolo 3 - Kernel Linux e pacchetti IP Si noti l’ambiguità dell’affermazione al punto 5. Sfortunatamente Linux storicamente accetta questa bizzarra situazione. Il senso delle parole “la prima fra esse” dipende letteralmente dall’ordine in cui le route sono state aggiunte alla tabella ed è praticamente impossibile tenere traccia di questo ordine in alcun modo. A livello pratico il problema non si pone, in quanto tutti gli strumenti che Linux mette a disposizione per manipolare le route non permettono la creazione di route non univoche. Naturalmente i passi per la selezione del percorso menzionati sopra non sono seguiti nella maniera descritta, in quanto la tabella di routing nel kernel è mantenuta in una apposita struttura dati che permette di raggiungere il risultato finale con il costo computazionale minimo. Si può però dire che una route è identificata dalla tripletta <prefisso, TOS, metrica>, che la contraddistingue univocamente all’interno della stessa tabella. Dopo ogni consultazione della tabella, Linux mantiene in una apposita memoria cache la decisione presa, in modo tale che se dovrà instradare un pacchetto con le stesse caratteristiche, non dovrà effettuare di nuovo il table lookup, ma userà tale memorizzazione. Le voci di questa cache sono eliminate dopo un determinato tempo di inutilizzo. 3.4.2 Attributi delle route Ogni tripletta si riferisce ad una precisa voce dentro la tabella di routing (route). La route contiene le informazioni necessarie per inoltrare i pacchetti IP[7]: 1. Interfaccia da utilizzare. 2. Indirizzo del prossimo router (in caso di consegna indiretta). 3. Indirizzo sorgente preferito da utilizzare quando si spediscono pacchetti verso le destinazioni coperte dal prefisso. Questo indirizzo deve essere assegnato ad un’interfaccia fisica. Questo entra in gioco quando si usano anche regole di iptables, discusse in seguito. 4. MTU (Maximum Transfer Unit), massima lunghezza del datagramma IP che può essere spedito lungo quel percorso senza essere frammentato. 29
  • 40. Capitolo 3 - Kernel Linux e pacchetti IP 5. finestra TCP, ovvero il massimo valore della finestra che TCP può indicare lungo questo percorso. Questo limita il numero di pacchetti che il calcolatore remoto può inviare a quello locale prima di ricevere una conferma di ricezione. 6. RTT (Round Trip Time), il tempo iniziale stimato di andata e ritorno di un pacchetto. Influisce sulla velocità di trasmissione. 7. Estensione della validità della route, può essere globale, a livello di collegamento o entro lo stesso calcolatore. 8. Modalità di inserimento della route, può indicare che la route è stata aggiunta in seguito alla ricezione di un messaggio ICMP di tipo Redirect; oppure dal kernel durante l’autoconfigurazione o durante l’avvio del sistema. Può essere una route di tipo statico aggiunta dall’amministratore, o dal protocollo di scoperta dei router. Una route può essere anche di tipo multipercorso (multipath), in questo caso possiede indirizzo del prossimo nodo, interfaccia da usare e peso della scelta, per ogni scelta indicata. Questo consente di ripartire i flussi di dati destinati ad una stessa destinazione su cammini differenti in maniera casuale, ma rispettando il valore dei pesi. Cioè se la route definisce due cammini diversi e i pesi sono 1 e 2, allora su tre flussi di dati, uno viene instradato lungo il primo percorso e due vengono instradati lungo il secondo percorso. Ma non vi è modo di stabilire a priori quali flussi passano per un certo percorso. 3.4.3 Tabelle di routing multiple Linux ha la possibilità di gestire più tabelle di routing, sulla base delle quali eseguire l’instradamento dei pacchetti[7]. Ogni tabella è identificata da un valore numerico da 1 a 255, a cui corrisponde un nome nel file /etc/iproute2/rt_tables. Normalmente le route vengono aggiunte nella tabella main (254), che è quella usata dal kernel per il calcolo dei percorsi. 30
  • 41. Capitolo 3 - Kernel Linux e pacchetti IP Per default esiste almeno un’altra tabella, local (255), adibita a contenere le route relative agli indirizzi locali e di broadcast. Tale tabella viene automaticamente gestita dal kernel. Le altre tabelle di routing multiple entrano in gioco quando si usa il Policy Routing. In questo contesto l’identificatore della tabella di routing diviene effettivamente un ulteriore parametro da aggiungersi alla tripletta <prefisso, TOS, metrica>. Quindi la chiave di identificazione univoca di una route viene ad essere formata da <tabella, tripletta>. Ciò comporta che si possono avere più route identiche contenute in tabelle differenti. 3.4.4 Policy Routing Linux prevede la possibilità di eseguire Policy Routing sostituendo la tradizionale maniera di instradamento dei pacchetti – basata sulla regola del prefisso più lungo – con il Routing Policy DataBase o RPDB[7], che seleziona il percorso appropriato attraverso l’esecuzione di un insieme di regole. Tali regole possono avere molte identificazioni di diversa natura e quindi non hanno un ordinamento naturale ad eccezione di quello imposto dall’amministratore di rete. In Linux il RPDB consiste in una lista di regole ordinate secondo un valore numerico che ne indica la priorità: zero è quella massima. Il RPDB permette esplicitamente di impostare le regole sulla base di: 1. indirizzo sorgente del pacchetto; 2. indirizzo destinazione (come nel routing tradizionale); 3. TOS; 4. interfaccia d’ingresso; 5. eventuale marchio impresso dal kernel al pacchetto nella fase di pre- instradamento. Fondamentale è il punto 5, in quanto, attraverso l’uso di strumenti adeguati – i quali sono discussi in seguito – si può raggiungere un elevatissimo grado di flessibilità nella marcatura dei pacchetti ed aumentare a dismisura la capacità di Policy 31
  • 42. Capitolo 3 - Kernel Linux e pacchetti IP Routing della macchina Linux, piegandola alle esigenze più minuziose degli amministratori di rete. Ogni regola del database consiste in un selettore e in un’azione. La lista è consultata partendo dalla regola di priorità zero, per essere sicuri che i pacchetti destinati alla macchina locale siano consegnati agli strati superiori e non ulteriormente instradati. Viene applicato il selettore di ogni regola alle relative informazioni del pacchetto IP considerato (sorgente, destinazione, TOS, interfaccia di ingresso, marchio). Se viene trovata corrispondenza, viene eseguita l’azione relativa. L’esecuzione di quest’azione comporta, normalmente, la scelta della tabella di routing su cui effettuare il lookup. Dopodiché il kernel esegue il lookup sulla tabella specificata usando la tradizionale regola di basarsi sulla destinazione del pacchetto e di partire dalle route con prefisso più lungo. L’azione relativa ad una regola può anche specificare che il pacchetto debba essere scartato. All’avvio della macchina, il kernel popola il database delle regole con le seguenti tre: 1. Priorità: 0; Selettore: qualsiasi pacchetto; Azione: lookup tabella local (255). 2. Priorità: 32766; Selettore: qualsiasi pacchetto: Azione: lookup tabella main (254). 3. Priorità: 32767; Selettore: qualsiasi pacchetto; Azione: lookup tabella default (253). La regola di priorità zero non può essere eliminata né modificata. 3.5 Controllo del traffico Dopo che il sottosistema di rete ha preso la decisione di routing, il kernel sa quale interfaccia di rete usare per spedire il pacchetto. Ogni device driver possiede alcune informazioni riguardanti le modalità con cui accodare i pacchetti per la particolare interfaccia a cui è connesso. Queste informazioni di accodamento sono 32
  • 43. Capitolo 3 - Kernel Linux e pacchetti IP quello che gli sviluppatori di Linux chiamarono queuing discipline, ovvero disciplina di accodamento[8]. Quando il kernel deve passare un pacchetto ad un’interfaccia di rete, accoda questo pacchetto secondo la disciplina di tale interfaccia e immediatamente dopo, cerca di tirar fuori – dalla testa della coda – quanti più pacchetti possibili da consegnare all’interfaccia. L’applicazione di questo meccanismo risulta in un comportamento dei pacchetti che ricalca la disciplina impostata. Una disciplina di accodamento molto semplice può consistere in una singola coda, in cui tutti i pacchetti sono inseriti nell’ordine di arrivo, e che è svuotata alla massima velocità alla quale il dispositivo riesce a spedire i pacchetti sulla rete. Discipline di accodamento più elaborate possono usare dei filtri per distinguere diverse classi di pacchetti e processare ogni classe in maniera diversa, ad esempio concedendo ad una classe una priorità maggiore rispetto le altre. Discipline di accodamento e classi sono intimamente legate: la presenza delle classi e le loro regole semantiche sono proprietà fondamentali delle discipline di accodamento. I filtri possono essere combinati arbitrariamente con discipline e classi. Per aumentare la flessibilità, ogni classe ha la sua disciplina per l’accodamento dei pacchetti. Questa disciplina può a sua volta avere più di una classe, e così via. Le discipline di accodamento possono essere applicate anche ai pacchetti entranti, indipendentemente dal fatto che questi pacchetti siano destinati alla macchina locale o debbano essere instradati verso altri host. Il controllo del traffico riguarda[9]: • Shaping: consiste nel tenere sotto controllo la velocità di trasmissione. Non consiste solo nel limitarne la velocità, ma anche nel limitare i burst, cioè i picchi. • Scheduling: consiste nell’impostare una diversa priorità per il tipo di traffico che ne ha bisogno, pur garantendo una determinata banda al traffico secondario. Si applica solo al traffico in uscita. • Policing: è lo Shaping applicato ai pacchetti in ingresso. 33
  • 44. Capitolo 3 - Kernel Linux e pacchetti IP • Dropping: quando la velocità dei pacchetti eccede una quantità definita, questi vengono scartati immediatamente senza essere processati. 3.6 Tunneling Con il temine tunneling (scavare tunnel) si intende la possibilità di creare e gestire delle speciali connessioni chiamate tunnel. Un tunnel non è altro che una connessione IP normale, nella quale il contenuto dei pacchetti non è rappresentato da dati appartenenti ad un protocollo di trasporto, ma ad un altro protocollo di rete. Una volta instaurato il tunnel, infatti, quando devono essere trasmessi, i dati utente sono messi in un pacchetto di strato di trasporto, il quale è incapsulato in un pacchetto di strato di rete (generico), che viene re-incapsulato in un pacchetto IP, il quale poi è inserito in una trama di collegamento ed inizia il viaggio. L’entità software che esegue l’incapsulamento dei pacchetti in un tunnel molto spesso risiede su una macchina differente da quella che genera il pacchetto vero e proprio, ad esempio il gateway di una LAN. Al lato della ricezione deve trovarsi un’entità in grado di riconoscere un pacchetto che fa parte di un tunnel, quindi togliere il “rivestimento” che questo comporta e instradare il pacchetto di dati significativi verso il destinatario (o verso gli strati superiori presenti nella macchina stessa, a seconda dei casi). Le applicazioni di rete i cui dati passano attraverso un tunnel non se ne rendono conto, l’operazione è del tutto trasparente nei loro confronti. Vi possono essere diverse ragioni per usare tunnel, fra queste: • Sicurezza/riservatezza: in questo caso l’entità che incapsula i pacchetti nel tunnel li cifra anche. • Possibilità di interconnettere più LAN private, geograficamente distanti tra loro, senza dover ricorrere a sistemi dedicati e costosi. Infatti il tunnel si snoderà lungo Internet senza richiedere costi aggiuntivi. • Possibilità di scambiare traffico incapsulato in protocolli di rete diversi da IPv4, usando reti IPv4. Un esempio è l’utilizzo di IPv6. 34
  • 45. Capitolo 3 - Kernel Linux e pacchetti IP Linux rende possibile la creazione di tre grandi tipi di tunnel[10]: • IPv4 in IPv4 • IPv6 in IPv4 • qualsiasi protocollo in GRE in IPv4 35
  • 46. Capitolo 3 - Kernel Linux e pacchetti IP 36
  • 47. Capitolo 4 - Strumenti per il networking Capitolo 4. Strumenti per il networking 4.1 Netfilter Netfilter è un componente di Linux presente nelle versioni 2.4.x e 2.6.x[11]. È il successore riprogettato e altamente migliorato di ipchains (Linux 2.2.x) e ipfwadm (Linux 2.0.x). Questa struttura permette il filtraggio e la manipolazione dei pacchetti. Comprende due parti: 1. Ogni protocollo definisce dei punti di aggancio (hook), IPv4 ne definisce cinque, i quali sono punti ben definiti lungo il viaggio dei pacchetti nella pila dei protocolli (protocol stack). In ciascuno di questi punti il protocollo richiamerà la struttura netfilter fornendo il pacchetto ed il numero identificativo dell’hook. 2. Porzioni del kernel possono registrarsi per “ascoltare”, per ogni protocollo, differenti hook. Di conseguenza, quando un pacchetto è passato a netfilter, esso controlla se qualcuno si è registrato per quel determinato protocollo e hook; se sì, a ciascuno di essi è data, in ordine, una chance per esaminare (e possibilmente alterare) il pacchetto, per scartarlo, lasciarlo proseguire o per chiedere a netfilter di accodarlo verso lo spazio utente. 4.1.1 Punti di hook I cinque hook di IPv4 sono situati in punti strategici: 1. PREROUTING (pre-instradamento): è attraversato da tutti i pacchetti entranti. È posizionato subito dopo il controllo di sanità dei pacchetti IP, subito prima del processo di routing, quando ancora il kernel non sa se il pacchetto è destinato alla macchina locale, oppure se è da instradare. 37
  • 48. Capitolo 4 - Strumenti per il networking 2. INPUT (ingresso locale): è posizionato subito prima della funzione che passa il pacchetto nelle mani del processo, quindi subito prima che il pacchetto esca dallo spazio del kernel ed entri nello spazio utente. 3. FORWARD (inoltro): prima dell’instradamento vero e proprio il kernel controlla se un pacchetto è destinato alla macchina locale o se deve essere instradato, nel caso in cui la decisione sia di instradarlo, il pacchetto viene instradato, quindi passa attraverso questo hook. Vi passano attraverso solo i pacchetti ricevuti che non sono destinati alla macchina locale, ma che vengono reinstradati verso altri host. 4. POSTROUTING (post-instradamento): è attraversato da tutti i pacchetti uscenti dalla macchina, in quanto si trova subito prima che questi vengano spediti alla coda di uscita della scheda di rete prescelta. 5. OUTPUT (uscita locale): è attraversato da tutti i pacchetti generati localmente. Dal punto di vista logico è chiamato prima che il kernel esegua l’instradamento di tali pacchetti, mentre di fatto la funzione di routing è chiamata prima (per comprendere l’indirizzo IP sorgente ed altre opzioni IP) e dopo, nel caso in cui il pacchetto sia stato modificato. 38
  • 49. Capitolo 4 - Strumenti per il networking Figura 5. Punti di hook nel percorso dei pacchetti IP 4.2 Iptables Il componente più conosciuto che poggia sulla struttura di netfilter è iptables. Iptables è una generica struttura a tabelle per la definizione di regole[11]. Queste regole si applicano ai pacchetti che netfilter fornisce ad ogni hook. Si noti che iptables in sé non si registra a nessun hook, ma lo lascia fare ad altri moduli. Il suo compito è di mantenere in memoria una lista di regole e informazioni su dove i pacchetti provenienti da ciascun hook devono cominciare la traversata. Iptables fa parte del corredo standard di applicazioni di praticamente tutte le distribuzioni Linux, i sorgenti sono comunque facilmente reperibili e liberamente 39
  • 50. Capitolo 4 - Strumenti per il networking scaricabili dal sito http://www.netfilter.org. La versione stabile attuale è la 1.3.5, la stessa che è stata utilizzata per eseguire gli esperimenti in laboratorio. 4.2.1 Tabelle Ogni regola all’interno di una tabella di iptables, consiste in un numero di classificatori (match) ed una azione (target). Le tabelle sono internamente suddivise in catene. Ogni catena contiene le regole specifiche per il punto di hook corrispondente[2]. Quando netfilter passa un pacchetto a iptables, questo scorre regola per regola, secondo l’ordine determinato dall’utente, le catene corrispondenti all’attuale punto di hook per ogni tabella. Quando viene riscontrata corrispondenza fra i match di una regola ed i parametri del pacchetto, allora viene eseguita l’azione corrispondente alla regola. A seconda del tipo di azione, questa può interrompere lo scorrimento delle regole oppure no. Ogni catena ha una politica di default, che viene applicata nel caso in cui il pacchetto non trovi riscontri con nessuna regola. Vi sono tre tabelle standard in iptables: filter, nat, e mangle. La prima è stata progettata espressamente per il filtraggio dei pacchetti, nei tre stadi di ingresso, uscita e inoltro rispettivamente nei punti di hook INPUT, FORWARD e OUTPUT. Questa tabella è usata per svolgere funzioni di firewall. La tabella nat, come dice la parola stessa, è usata per la traduzione degli indirizzi: ad esempio per effettuare NAPT (Network Address and Port Translation) permettendo ai calcolatori di una rete IP privata di avere accesso a Internet; oppure effettuare Port Forwarding per permettere ai calcolatori esterni di raggiungere determinati servizi situati su macchine interne alla rete locale. Questa tabella utilizza gli hook di PREROUTING, OUTPUT e POSTROUTING, ai quali corrispondono tre catene omonime. C’è infine la tabella mangle, la quale utilizza tutti i cinque hook, possiede quindi cinque catene ed è usata per eseguire tutte le operazioni che non riguardano il filtraggio e la traduzione degli indirizzi: effettuare logging, modificare ulteriori campi dell’intestazione dei pacchetti – come il campo TOS – e contrassegnarli. 40
  • 51. Capitolo 4 - Strumenti per il networking 4.2.2 Configurazione Iptables si configura attraverso l’omonimo programma di sistema, il quale permette di visualizzare lo stato corrente dell’insieme di regole, aggiungere nuove regole, definire nuove catene, eliminare regole e catene definite dall’utente, modificare le politiche di default per le catene standard (che non possono essere rinominate né rimosse)[12]. Sintassi: iptables -[A|D] chain rule-specification [options] iptables -[R|I] chain num rule-specification [options] iptables -D chain num [options] iptables -[L|F|Z] [chain] [options] iptables -[N|X] chain iptables -E old-chain-name new-chain-name iptables –P chain target [options] Comandi: -A chain Appende all’ultimo posto della catena -D chain Elimina dalla catena la regola corrispondente -D chain num Elimina la regola num (1 = prima) dalla catena -I chain [num] Inserisce nella catena alla posizione num (default 1=prima) -R chain num Sostituisce la regola num nella tabella soecificata -L [chain] Mosrta il contenuto di una catena o di tutte -F [chain] Elimina tutte le regole di una catena o di tutte -Z [chain] Azzera i contatori in una catena o in tutte -N chain Crea una nuova catena definita dall’utente -X [chain] Elimina una catena definita dall’utente -P chain target Cambia la politica di default della catena -E old-chain new-chain Cambia nome alla catena Opzioni: -p [!] proto Protocollo: numero o nome, es. “tcp” 41
  • 52. Capitolo 4 - Strumenti per il networking -s [!] address[/mask] Indirizzo IP sorgente -d [!] address[/mask] Indirizzo IP destinazione -i [!] input-name[+] Nome dell’interfaccia d’ingresso ([+] per wildcard) -j target Azione di una regola -m match Match esplicito -n Output numerico per indirizzi e porte -o [!] output-name[+] Nome dell’interfaccia di uscita ([+] per wildcard) -t table Tabella da manipolare (default: “filter”) -v Modalità prolissa --line-numbers mostra i numeri delle linee quando fa il listato -x Espande i numeri (mostra i valori esatti) [!] –f trova corrispondenza solo con i frammenti dal secondo in poi --modprobe=<command> prova ad inserire i moduli usando questo comando --set-counters PKTS BYTES Imposta i contatori durante l’inserimento di una regola. Ad ogni riavvio del sistema iptables azzera le proprie regole. Per rendere persistente la configurazione esistono due strumenti distribuiti nel pacchetto. Per salvare una configurazione: iptables-save > FILE Per ripristinare una configurazione precedentemente salvata: iptables-restore < FILE Una configurazione di iptables può facilmente essere resa persistente salvando – con il primo comando – la configurazione che si intende mantenere; quindi inserendo il secondo comando in uno script eseguito all’avvio del sistema. 42
  • 53. Capitolo 4 - Strumenti per il networking 4.2.3 Match La grande potenza che iptables mette a disposizione degli amministratori di rete risiede, in massima parte, nella elevata finezza con cui è oggi possibile classificare i pacchetti: sulla base non solo di tutti i parametri che fanno parte dell’intestazione IP e TCP, ma, ad esempio, dello stato in cui si trova la connessione TCP di cui un pacchetto fa parte, e molto altro. Esistono due grandi famiglie di match: quelli impliciti e quelli espliciti; i primi sono quelli che appaiono come opzioni nella lista precedente: indirizzo sorgente e destinazione, porta sorgente e destinazione, interfaccia d’ingresso e uscita e protocollo. Mentre per gli altri occorre esplicitamente indicare il nome del modulo che implementa il match, attraverso -m <match>. Esempio: iptables –t filter –A INPUT –m match ttl --ttl 128 -j DROP In questo esempio tutti i pacchetti diretti alla macchina locale, con Time To Live pari a 128 vengono scartati silenziosamente. 4.2.4 Casi di interesse Per ciò che concerne gli scopi di questo elaborato, le funzionalità di iptables sfruttate sono le seguenti: 1. tutti i match che permettono di distinguere diversi flussi di dati ed il match random. 2. i target MARK e CLASSIFY. 4.2.4.1 Match random Non si riferisce ad alcun parametro dei pacchetti IP, semplicemente la condizione è verificata in maniera casuale entro una ben precisa probabilità media di occorrenza[13]. 43
  • 54. Capitolo 4 - Strumenti per il networking Sintassi: iptables –t <tabella> -A <catena> –m random [ --average <n> ] [ <altri match> ] -j <target> Dove <n> indica la probabilità media (percentuale) con cui si verificherà la soddisfazione del match random. Se non viene specificata alcuna media, si prende quella di default, che è del 50%. Esempio: iptables -A INPUT –m random --average 80 –p icmp -j DROP Nell’esempio si specifica una regola secondo cui i pacchetti ICMP destinati alla macchina locale saranno scartati con l’80% di probabilità. 4.2.4.2 Match tos Permette di trovare corrispondenza con i pacchetti, basandosi sugli 8 bit del campo Type Of Service dell’intestazione IP[14]. Sintassi: iptables –t <tabella> -A <catena> -m tos –-tos <n> -j <target> Dove <n> rappresenta il valore del TOS con cui trovare la corrispondenza. Può essere indicato con notazione decimale o esadecimale. Cinque valori possono essere anche specificati sottoforma di stringa: Nome Valore decimale Valore esadecimale Minimize-Delay 16 0x10 Maximize-Throughput 8 0x08 Maximize-Reliability 4 0x04 Minimize-Cost 2 0x02 Normal-Service 0 0x00 44
  • 55. Capitolo 4 - Strumenti per il networking 4.2.4.3 Target MARK Un target utilizzato di frequente, anche quando si vuole sfruttare la potenza di iptables in applicazioni esterne, è MARK, che effettua il contrassegno dei pacchetti[14], può essere usato solo nella tabella mangle. Sintassi: iptables -t mangle –A <catena> <match> -j MARK –-set-mark <n> Dove <n> è proprio il contrassegno (o marchio) che verrà applicato a tutti i pacchetti che corrispondano alla lista di selettori della regola. Può essere indicato con notazione decimale o esadecimale, è un intero a 32 bit, quindi può andare da 0x00000000 a 0xFFFFFFFF. Il marchio impresso ad un pacchetto non va a modificare i suoi dati e nemmeno l’intestazione, ma rimane impresso in modo virtuale per tutto il tempo che il pacchetto trascorre all’interno della macchina. Altre applicazioni possono leggere il valore del marchio e quindi sfruttarlo per trattare i pacchetti in maniera differente a seconda di come sono stati marchiati. Questo senza che debbano essere in grado di distinguere i pacchetti, perché il lavoro è svolto tutto da iptables. Queste applicazioni devono solo sapere come leggere il marchio. Questo target non prevede l’interruzione, quindi dopo che un pacchetto è stato contrassegnato, iptables continua a scorrere la lista delle regole. 4.2.4.4 Target CLASSIFY Questo target è usato per classificare i pacchetti in classi diverse. Le stesse classi che vengono usate per l’accodamento dei pacchetti nelle discipline di accodamento[13]. È usato in combinazione con altri strumenti per il controllo del traffico, i quali si occupano di applicare determinate discipline e regole di accodamento alle varie classi di pacchetti. 45
  • 56. Capitolo 4 - Strumenti per il networking Sintassi: iptables –t <tabella> -A <catena> <match> -j CLASSIFY –-set-class <major>:<minor> Dove <major>:<minor> rappresentano la classe in cui vengono fatti rientrare tutti i pacchetti che trovano corrispondenza con i match della regola. Il significato di questa sintassi verrà chiarito nella sezione dedicata alla suite iproute2. L’uso di questo target nell’ambito del controllo del traffico è vivamente consigliato dall’Autore in quanto si sfruttano la grande potenza di iptables, che non ha eguali, e la sua grande semplicità d’uso. 4.2.4.5 Altri usi L’uso di iptables nello svolgimento degli esperimenti non si ferma qui. Infatti è usato anche nello svolgimento di compiti non centrali, ma di supporto, come la traduzione degli indirizzi per permettere ad alcuni calcolatori di accedere ad Internet. Esempio di traduzione degli indirizzi: iptables –t nat -A POSTROUTING –o eth1 –s 192.168.1.0/24 -j MASQUERADE Nell’esempio sopra riportato, tutti i pacchetti con indirizzo sorgente appartenente alla sottorete specificata i quali, dopo il processo di routing, devono essere inviati al dispositivo di rete indicato, subiscono una modifica tale per cui al loro indirizzo sorgente originale viene sostituito quello dell’interfaccia di rete di uscita[13] (il primario, se ne possiede più di uno). Questo processo è chiamato masquerading (mascheramento). Non è necessario inserire altre regole, in quanto la traduzione inversa – effettuata sui pacchetti che vanno in direzione opposta, che devono raggiungere una macchina con IP mascherato – è eseguita automaticamente tenendo traccia delle connessioni con meccanismi interni. 46
  • 57. Capitolo 4 - Strumenti per il networking 4.2.5 Estensioni La struttura di iptables prevede che tutti i match e tutti i target siano costruiti come moduli. Ciò rende relativamente semplice aggiungere nuovi moduli, che espletino diverse funzioni: match, target, addirittura nuove tabelle[11]. Il team di netfilter è costantemente al lavoro[15], soprattutto per quanto riguarda i moduli: si apportano continue modifiche e migliorie ai moduli presenti nel pacchetto stabile, si testano e rendono stabili i moduli nuovi non ancora inseriti nel pacchetto ufficiale, e infine si elaborano moduli dalle funzioni innovative. Viene messo a disposizione uno strumento per gli utenti – un poco spericolati – che vogliano aggiungere alla propria versione di iptables dei moduli non presenti perché non ancora ritenuti adeguatamente stabili o perché non svolgono ancora tutte le funzioni per cui sono stati programmati. Lo strumento è un’applicazione chiamata patch-o-matic, ora divenuto patch-o-matic-ng (Next Generation). Estendere le funzionalità di iptables è un’operazione di una certa portata, che comporta anche la ricompilazione del kernel, da qui la necessità di un programma che esegua in automatico le operazioni più delicate, come l’applicazione delle modifiche (patch) ai sorgenti di iptables e del kernel. 4.2.5.1 Aggiunta di un’estensione: modulo random Ai fini degli esperimenti effettuati, è necessario aggiungere il match random, perché non presente nella distribuzione dei calcolatori di laboratorio. Di seguito sono riportati i passaggi compiuti sulla macchina netlab11. Si noti che i passaggi descritti sono stati eseguiti utilizzando la distribuzione Linux Fedora Core 3, quindi potrebbero presentare differenze con le procedure da seguire su altre distribuzioni[16]. Per prima cosa si deve scaricare il codice sorgente del kernel, facendo attenzione a scaricare la giusta versione, in questo caso Fedora Core 3, kernel 2.6.9-1.667. Wget http://download.fedora.redhat.com/ pub/fedora/linux/core/3/i386/os/SRPMS/ kernel-2.6.9-1.667.src.rpm 47