2 894
contributi
Iproute2: differenze tra le versioni
m
→Aggiungere tabelle di routing
Wtf (discussione | contributi) |
Wtf (discussione | contributi) |
||
| (25 versioni intermedie di uno stesso utente non sono mostrate) | |||
| Riga 90: | Riga 90: | ||
Usa la tabella di routing "tab1" (invece di quella principale, vedere anche la sezione ''Aggiungere tabelle di routing'') quando un pacchetto arriva dall'IP <code>101.13.15.179</code>: | Usa la tabella di routing "tab1" (invece di quella principale, vedere anche la sezione ''Aggiungere tabelle di routing'') quando un pacchetto arriva dall'IP <code>101.13.15.179</code>: | ||
<pre># ip rule add from 101.13.15.179 table | <pre># ip rule add from 101.13.15.179 table tab1</pre> | ||
Usa la tabella di routing "tab1" (invece di quella principale) quando un pacchetto è diretto all'IP <code>101.13.15.179</code>: | Usa la tabella di routing "tab1" (invece di quella principale) quando un pacchetto è diretto all'IP <code>101.13.15.179</code>: | ||
<pre># ip rule add to 101.13.15.179 table | <pre># ip rule add to 101.13.15.179 table tab1</pre> | ||
Usa la tabella di routing "tab1" (invece di quella principale) quando un pacchetto è contrassegnato col valore 1: | Usa la tabella di routing "tab1" (invece di quella principale) quando un pacchetto è contrassegnato col valore 1: | ||
| Riga 101: | Riga 101: | ||
Si noti che è neceessario usare l'azione ''mark'' di iptables per contrassegnare i pacchetti e far quindi sì che la precedente regola funzioni. Considerare anche che l'abilitazione del ''reverse path filtering'' (si veda sezione più sotto) congiuntamente alla presenza di regole per SNAT e/o masquerading può portare allo scarto indesiderato dei pacchetti che si sono contrassegnati. | Si noti che è neceessario usare l'azione ''mark'' di iptables per contrassegnare i pacchetti e far quindi sì che la precedente regola funzioni. Considerare anche che l'abilitazione del ''reverse path filtering'' (si veda sezione più sotto) congiuntamente alla presenza di regole per SNAT e/o masquerading può portare allo scarto indesiderato dei pacchetti che si sono contrassegnati. | ||
Cancellare una singola regola: | |||
<pre># ip rule del pref [selector]</pre> | |||
dove <code>selector</code> è un numero di 5 cifre associato ad ogni regola (visibile col comando <code>ip rule</code>). | |||
Cancellare tutte le regole relative alla tabella "tab1": | Cancellare tutte le regole relative alla tabella "tab1": | ||
| Riga 126: | Riga 130: | ||
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. | 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: | |||
<pre># ip netns list</pre> | |||
Se non ne esistono viene restituita una stringa vuota. | |||
Creare un nuovo namespace di nome "test": | |||
<pre># ip netns add test</pre> | |||
Cancellare un namespace di nome "test": | |||
<pre># ip netns del test</pre> | |||
Eseguire un applicativo nel namespace "test": | |||
<pre># ip netns exec test ping 8.8.8.8</pre> | |||
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 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: | |||
<pre># ip netns add test</pre> | |||
Creazione di una coppia di interfacce di rete virtuali <code>vth0a</code> e <code>vth0b</code>. | |||
<pre># ip link add vth0a type veth peer name vth0b</pre> | |||
Trasferimento di <code>vth0b</code> in "test": | |||
<pre># ip link set vth0b netns test</pre> | |||
Eseguendo ora il comando <code>ip link list</code> si noterà che sarà presente solo <code>vth0a</code>, infatti <code>vth0b</code> risulterà visibile solo nel namespace "test" tramite il comando <code>ip netns exec test ip link list</code>. | |||
Attivare e configurare le necessarie interfacce di rete per il namespace test: | |||
<pre># ip link set veth0 up | |||
# ip netns exec test ip link set lo up | |||
# ip netns exec test ip addr add 192.168.1.101/24 dev vth0b | |||
# ip netns exec test ip link set vth0b up</pre> | |||
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 di un bridge di rete denominato <code>br0</code> (maggiori informazioni [[Ethernet Bridging | QUI]]) | |||
<pre># ip link add br0 type bridge | |||
# ip addr add 192.168.1.100/24 dev br0 | |||
# ip link set br0 up | |||
# ip link set enp3s0 master br0 | |||
# 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> | |||
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> | |||
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 == | ||