Avanti Indietro Indice

5.1 Tabelle di routing multiple

Si presenta però spesso la necessità di inviare traffico differente attraverso interfacce differenti, oppure di avere degli stessi indirizzi ip su diverse interfacce di rete.

Nei kernel precedenti al 2.2 e utilizzando comandi diversi da ip era quasi impossibile utilizzare un firewall linux in queste situazioni. Attualmente invece, è possibile utilizzare più tabelle di routing.

Immaginiamo quindi di avere, per esempio, due connessioni ad internet, una attraverso un provider ``serio'', per la nostra sala macchine, dove la banda è garantita e deve essere riservata per il traffico dei clienti, ed una connessione ADSL per il nostro ufficio.

In questo caso, una soluzione (sebbene non la migliore ma abbastanza didattica) potrebbe essere quella di mantenere le due reti il più possibile separate, introducendo un firewall con 4 interfacce:

  1. la prima collegata alla rete degli uffici
  2. la seconda collegata alla rete del provider ADSL
  3. la terza collegata alla rete della sala macchine
  4. la quarta collegata al provider serio
In questo caso il vostro router linux dovrebbe instradare i pacchetti differentemente, a seconda che vengano o siano destinati all'ufficcio o alla sala macchine.

Per fare questo utilizzando il nuovo comando ip è possibile creare due tabelle di routing distinte: una per la sala macchine e il provider serio, l'altra per l'ufficio e per la linea adsl.

Iniziamo quindi dando un'occhiata nella directory /etc/iproute2 (o /etc/iproute a seconda della distribuzione che state usando). In questa directory vengono mantenuti tutta una serie di file utilizzati dal comando ip per convertire numeri in nomi e viceversa.

Tutte le informazioni vengono infatti memorizzate dal kernel in formato numerico, mentre per noi poveri esseri umani è spesso più facile utilizzare dei nomi.

Se deste per esempio un'occhiata al file rt_protos, sempre nella directory /etc/iproute, vedreste le parole ``static'', ``boot'' o ``redirect'' di cui vi parlavo prima (quando vi descrivevo il significato del campo proto) precedute dal numero utilizzato internamente dal kernel. Allo stesso modo, nel file rt_scopes potreste vedere le associazioni tra scope indicato in formato numerico e lo scope mostrato da ip; nel file rt_dsfield le associazioni utilizzate per la gestione dei servizi differenziati e nel file rt_realms i realm utilizzati (purtroppo non se ne parelrà in questo documento). Infine, nel file rt_tables, troverete le associazioni tra l'identificativo delle varie tabelle di routing ed il loro nome.

Aprite dunque questo file con il vostro editor preferito ed aggiungete una riga del tipo

252     smacchine
Dove 252 è semplicemente un numero non utilizzato e smacchine un nome arbitrario per la nostra nuova tabella di routing (abbiamo appena battezzato la tabella 252 come ``smacchine'').

Notate però che le righe precedeute da un ``#'' sono commenti, e che probabilmente nel vostro file tutte le righe sono commentate. Questo principalmente per un motivo: il comando ip mantiene direttamente tutte le associazioni tra quelle che sono le tabelle standard ed i numeri corrispondenti, e, per evitare confusione, farà in modo da elegantemente ignorare ogni riga nel file di configurazione che vada a modificarle.

Per aggiungere dei route a questa nuova tabella è sufficiente utilizzare i soliti comandi indicando però esplicitamente il nome della tabella.

Immaginiamo quindi che

  1. l'interfaccia di rete eth-off collegata agli uffici abbia come indirizzo 10.0.0.1 e che gli uffici utilizzino come netmask 255.255.255.0.
  2. l'interfaccia di rete eth-adsl collegata al provider adsl abbia un indirizzo dinamico assegnato da un server dhcp.
  3. l'interfaccia di rete eth-smac collegata alla sala macchine abbia come indirizzo 1.2.3.1 e che questa rete utilizzi come netmask 255.255.255.240.
  4. l'interfaccia di rete eth-serio collegata al provider serio abbia come indirizzo 1.2.3.2 e che sia collegata direttamente al router (tramite crossover) del provider con indirizzo 1.2.3.14.
Ipotizzando di aver già impostato correttamente gli indirizzi ip sulle varie schede di rete, ci troveremmo quindi ad una situazione simile (con ip addr show) alla seguente:
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth-off: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:04:8e:a2:da brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth0
3: eth-adsl: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:04:8e:a2:db brd ff:ff:ff:ff:ff:ff
4: eth-smac: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:04:8e:a2:dc brd ff:ff:ff:ff:ff:ff
    inet 1.2.3.1/28 brd 1.2.3.15 scope global eth0
5: eth-serio: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:04:8e:a2:dd brd ff:ff:ff:ff:ff:ff
    inet 1.2.3.14/32 brd 192.168.200.255 scope global eth0
Ma vediamo di analizzare la situazione prima di proseguire. Per quanto riguarda eth-off, non credo che vi sia alcun problema: è configurata in una delle maniere più standard possibili. eth-adsl, invece, non è stata attivata: questo principalmente perchè se ne occuperà pump (o dhcpcd -- sono entrambi dei client dhcp) entro poco. eth-smac ha come indirizzo quello sopra indicato (1.2.3.1) e come netmask un /28. Questo perchè 255.255.255.240 in formato binario si può scrivere come 11111111.11111111.11111111.11110000, cioè con 28 ``uno'' (si può anche calcolare in questo modo: 255 (il massimo) - 240 = 16 (ok, 15, ma arrotondiamolo alla potenza di 2 più vicina), 16 si può esprimere utilizzando al più 4 bit (4 = logaritmo base 2 di 16, 2**4 è proprio uguale a 16) -- 32 - 4 = 28). Ok, andando avanti, eth-serio ha come indirizzo ip 1.2.3.14/32. Teoricamente però, 1.2.3.14 si dovrebbe trovare sulla rete collegata ad eth-smac. E' per questo che la netmask è stata specificata con un /32: ad indicare che nessun altro computer di tale rete è raggiungibile tramite questa interfaccia. Vediamo però cosa ha fatto il kernel in automatico sulle nostre tabelle di routing:

  # ip route show table main
    127.0.0.0/8 dev lo  scope link 
    10.0.0.0/24 dev eth-off proto kernel scope link src 10.0.0.1 
    1.2.3.0/28 dev eth-smac proto kernel scope link src 1.2.3.1
  # ip route show table smacchine
  #
Ok, prima di tutto non è stata aggiunta alcuna entry per l'interfaccia eth-serio nella tabella main (quella di default): questo soprattutto perchè dal punto di vista del kernel eth-serio non è collegata ad alcuna rete (ricordate il /32?).

In secondo luogo, la tabella smacchine è completamente vuota. L'unico modo per aggiungere delle entry in tabelle diverse da quella di default è quello di richiederlo esplicitamente.

Ipotizzando quindi di riuscire a fare in modo che i nostri server utilizzino la tabella ``smacchine'' anziché la tabella main, in questa tabella dovranno essere presenti sicuramente le seguenti entry:

Vediamo quindi di aggiungere queste entry:
  # ip route add 1.2.3.0/28 dev eth-smac table smacchine
  # ip route add 1.2.3.2 dev eth-serio table smacchine
  # ip route add 10.0.0.0/24 dev eth-off table smacchine
  # ip route add default via 1.2.3.2 dev eth-serio table smacchine
Le particolarità iniziano qui dalla seconda riga: in caso il router dovesse contattare il computer con indirizzo 1.2.3.2 utilizzerebbe questa riga piuttosto che la prima in quanto è quella che corrisponde per un numero maggiore di bit. In questo caso, è indispensabile perchè tutto funzioni correttamente specificare come scheda di rete eth-serio. In pratica, è come se con la prima riga avessimo detto al kernel che ``tutti i computer con indirizzo 1.2.3.0/28 sono raggiungibili tramite eth-smac'', e con la seconda ``tranne 1.2.3.2, che è raggiungibile tramite eth-serio''.

Infine, la quarta riga indica che per raggiungere internet è possibile utilizzare il gateway con indirizzo 1.2.3.2, che, dalla seconda riga, si trova su eth-serio.

Ci manca ancora un passo però per arrivare ad una configurazione ``funzionante'': dire al kernel in quali situazioni utilizzare la tabella ``smacchine'' invece della tabella ``main''.

Per fare questo, è necessario utilizzare il comando ``ip rule'' (regole ip). Nel nostro caso basterebbe qualcosa del tipo

  # ip rule add from 1.2.3.0/28 lookup smacchine 
  # ip rule add to 1.2.3.0/28 lookup smacchine
per dire al kernel di utilizzare la tabella smacchine per tutto ciò:
  1. che proviene da 1.2.3.0/28
  2. che è destinato a 1.2.3.0/28
Infine, dobbiamo assegnare un indirizzo ip all'interfaccia eth-adsl ed un route di default per la tabella main. Per fare questo, possiamo semplicemente utilizzare ``dhcpcd -i eth-adsl'' per richiedere tramite dhcp le informazioni mancanti.

E' importante notare che è fondamentale lasciare la tabella di default per gli uffici e la linea ADSL ed utilizzare un'altra tabella per i server. Questo principalmente perchè comandi come pump o dhcpcd non consentono ancora di specificare quale tabella dovrà essere modificata con le informazioni reperite tramite dhcp o bootp, ed andranno quindi a modificare la tabella di main.


Avanti Indietro Indice