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:
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: 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:
# 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ò:
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.