2 894
contributi
Iproute2: differenze tra le versioni
m
→Aggiungere tabelle di routing
Wtf (discussione | contributi) |
Wtf (discussione | contributi) |
||
| (17 versioni intermedie di uno stesso utente non sono mostrate) | |||
| Riga 110: | Riga 110: | ||
<pre># while ip rule delete from 0/0 to 0/0 table tab1 2>/dev/null; do true; done</pre> | <pre># while ip rule delete from 0/0 to 0/0 table tab1 2>/dev/null; do true; done</pre> | ||
=== Network namespaces | == Aggiungere tabelle di routing == | ||
È possibile aggiungere altre tabelle di routing oltre a quella principale. Per fare ciò è sufficiente editare il file <code>/etc/iproute2/rt_tables</code> ed aggiungere in coda i nomi delle tabelle aggiuntive, avendo cura di specificare anche il relativo ID. Per esempio per aggiungere una sola tabella di nome ''tab1'' e ID=1 sarebbe sufficiente che il contenuto del predetto file si presentasse così: | |||
<pre> | |||
# | |||
# reserved values | |||
# | |||
255 local | |||
254 main | |||
253 default | |||
0 unspec | |||
# | |||
# local | |||
# | |||
#1 inr.ruhep | |||
1 tab1 | |||
</pre> | |||
Il vantaggio di avere più tabelle di routing è chiaramente quello di poter stabilire rotte diverse (e/o cambiare le priorità) per i pacchetti a seconda di alcuni criteri di confronto. | |||
In combinazione con la funzione '''namespace''' (vedere sotto) diviene inoltre facile instradare in modo differente i pacchetti di applicativi diversi (sfruttando ad esempio l'IP di provenienza dei dati, anche se gli applicativi girano sulla stessa macchina e la scheda di rete è una sola). | |||
== Network namespaces == | |||
Elencare i namespaces attualmente esistenti: | Elencare i namespaces attualmente esistenti: | ||
| Riga 126: | Riga 148: | ||
Nota: il succitato comando fallisce se prima non si è provveduto a creare una "connessione" col namespace predefinito, cioè quello globale in cui normalmente avvengono tutti i processi. | Nota: il succitato comando fallisce se prima non si è provveduto a creare una "connessione" col namespace predefinito, cioè quello globale in cui normalmente avvengono tutti i processi. | ||
=== Esempio 1 === | |||
OBIETTIVO: su un sistema con molteplici interfacce di rete si vuole forzare un'applicazione ad usare una certa interfaccia di rete fisica, ad esempio <code>enp3s0</code>. In tal modo diviene possibile applicare alla suddetta applicazione regole di firewall e/o routing sfruttando condizioni basate anche solo su l'interfaccia di rete e/o l'indirizzo IP.<br/> | |||
Si ipotizza per semplicità che tutti i dispositivi/interfacce siano configurati per utilizzare la subnet <code>192.168.1.0/24</code>. | Si procederà dunque alla creazione di un namespace "test" in bridge con <code>enp3s0</code> tramite un interfaccia ethernet virtuale. Si ipotizza inoltre per semplicità che tutti i dispositivi/interfacce siano configurati per utilizzare la subnet <code>192.168.1.0/24</code>. | ||
Creazione del namespace: | Creazione del namespace: | ||
<pre># ip netns | <pre># ip netns add test</pre> | ||
Creazione di una coppia di interfacce di rete virtuali <code>vth0a</code> e <code>vth0b</code>. | Creazione di una coppia di interfacce di rete virtuali <code>vth0a</code> e <code>vth0b</code>. | ||
| Riga 147: | Riga 169: | ||
Poiché la premessa è stata quella di mettere in bridge l'interfaccia <code>vth0a</code> con <code>enp3s0</code> alla prima non è stato assegnato alcun indiritto IP. | Poiché la premessa è stata quella di mettere in bridge l'interfaccia <code>vth0a</code> con <code>enp3s0</code> alla prima non è stato assegnato alcun indiritto IP. | ||
Creazione bridge di rete | Creazione di un bridge di rete denominato <code>br0</code> (maggiori informazioni [[Ethernet Bridging | QUI]]) | ||
<pre>#ip link add br0 type bridge | <pre># ip link add br0 type bridge | ||
#ip addr add 192.168.1. | # ip addr add 192.168.1.100/24 dev br0 | ||
#ip link set br0 up | # ip link set br0 up | ||
#ip link set enp3s0 master br0 | # ip link set enp3s0 master br0 | ||
#ip link set veth0 master br0</pre> | # ip link set veth0 master br0</pre> | ||
Aggiunta di una rotta predefinita per il namespace "test" (è necessario indicare l'ip di <code>br0</code>) | |||
<pre>ip netns exec test ip route add default via 192.168.1.100</pre> | |||
<pre> | A questo punto è possibile forzare un qualsiasi applicativo ad usare l'interfaccia <code>enp3s0</code> semplicemente digitando: | ||
# | <pre># ip netns exec test "stringa_comando"</pre> | ||
Nel caso si desidere eseguire l'applicativo senza i privilegi di root sarà sufficiente modificare il precedente comando nel seguente modo: | |||
# | <pre># ip netns exec test su -c "stringa_comando" nome_utente_non_privilegiato</pre> | ||
</pre> | |||
Come anticipato all'inizio se ora si definisce una regola di routing nel namespace globale (cioè quello predefinito) tale per cui tutti i dati provenienti da 192.168.1.100 sono per esempio instradati con una tabella di routing alternativa (es. <code>tab1</code>), l'effetto finale è che tale regola interesserà solo gli applicativi che sono stati lanciati usando il namespace "test". | |||
== Reverse path filtering == | == Reverse path filtering == | ||