Iproute2: differenze tra le versioni

← Differenza precedente

Iproute2 (visualizza wikitesto)

Versione delle 20:42, 11 ago 2023

10 088 byte aggiunti , 11 ago 2023

m

→‎Aggiungere tabelle di routing

Wtf

2 894

contributi

@@ Riga 20: / Riga 20: @@
 <br/>
 <br/>
-{{Versioni compatibili}}
+{{Versioni compatibili}}{{Gateway-Router}}
 == Comandi ==
@@ Riga 52: / Riga 52: @@
 === Gestione interfacce ===
-Aggiungere un indirizzo all'interfaccia eth0:
+Aggiungere un indirizzo all'interfaccia <code>eth0</code>:
 <pre># ip address add 192.0.2.10/24 dev eth0</pre>
 Cancellare un indirizzo associato all'interfaccia eth0:
 <pre># ip address delete 192.0.2.10/24 dev eth0</pre>
-Attivare l'interfaccia eth0:
+Attivare l'interfaccia <code>eth0</code>:
 <pre># ip link set dev eth0 up</pre>
-Disattivare l'interfaccia eth0:
+Disattivare l'interfaccia <code>eth0</code>:
 <pre># ip link set dev eth0 down</pre>
 Svuotare la cache arp per tutte le interfacce:
 <pre>ip neigh flush all</pre>
+Aggiungere un secondo indirizzo all'interfaccia <code>eth0</code>:
+<pre># ip address add 192.0.2.20/24 dev eth0</pre>
+che come si vede non presenta alcuna differenza con l'assegnazione del primo indirizzo. Con <code>iproute2</code> infatti gli indirizzi aggiuntivi vengono semplicemente assegnati direttamente all'interfaccia, senza bisogno di creare alcun alias (come invece chiedeva <code>ifconfig</code>), tuttavia per questioni di retrocompatibilità è opportuno e consigliato definire anche un'etichetta che segua le regole del vecchio <code>ifconfig</code>.<br>
+Il precedente comando diviene quindi:
+<pre># ip address add 192.0.2.20/24 dev eth0 label eth0:0</pre>
+Si noti che gli indirizzi aggiuntivi possono anche appartenere a subnet diverse, non devono cioè necessariamente appartenere alla stessa subnet del primo indirizzo dichiarato.<br>
+Cancellare tutti gli indirizzi aggiunti all'interfaccia <code>eth0</code>
+<pre># ip address flush dev eth0 scope global</pre>
+Creare un'interfaccia virtuale (''vlan'' 802.1q, da non confondere con ''veth'' interfaccia ethernet virtuale) per <code>eth0</code>
+<pre># ip link add link eth0 name eth0.1 type vlan id 1</pre>
+Rimuovere l'interfaccia virtuale appena creata
+<pre># ip link delete eth0.1</pre>
 === Instradamento ===
@@ Riga 69: / Riga 81: @@
 Aggiungere una rotta che passa per ppp0:
 <pre># ip route add 192.0.2.0/25 dev ppp0</pre>
+Impostare ppp0 come gateway predefinito:
+<pre># ip route add default dev ppp0</pre>
+Impostare l'IP 192.0.2.1 come gateway predefinito:
+<pre># ip route add default via 192.0.2.1</pre>
+=== Regole ===
+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 tab1</pre>
+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 tab1</pre>
+Usa la tabella di routing "tab1" (invece di quella principale) quando un pacchetto è contrassegnato col valore 1:
+<pre># ip rule add from all fwmark 1 table 1</pre>
+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":
+<pre># while ip rule delete from 0/0 to 0/0 table tab1 2>/dev/null; do true; done</pre>
+== 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
+#
+     local
+     main
+     default
+       unspec
+#
+# local
+#
+#1      inr.ruhep
+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:
+<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 ==
+Sebbene questa tecnica non sia strettamente legata a iproute2 vale comunque la pena spiegare brevemente cosa sia poiché la sua abilitazione potrebbe creare problemi quando si vuole contrassegnare i pacchetti in transito, ovvero usare il comando <code>fwmark</code> della suite in congiunzione al bersaglio "mark" di iptables (modulo conntrack).
+In poche parole il ''reverse path filtering'' non è altro che un metodo del kernel per verificare che l'indirizzo di provenienza specificato nell'header del pacchetto stesso sia effettivamente instradabile dall'interfaccia della macchina che lo riceve. Tale verifica è principalmente atta a scartare quei pacchetti che sono stati fraudolentemente modificati per mostrare un indirizzo IP di provenienza diverso da quello reale (''ip spoofing'', molto usato ad esempio negli attacchi ''DDOS'').
+Questa funzione può essere facilmente abilitata o disabilitata editando le seguenti due variabili contenute nel file <code>nano /etc/sysctl.conf</code>:
+<pre>
+net.ipv4.conf.default.rp_filter
+net.ipv4.conf.all.rp_filter
+</pre>
+Assegnando un valore di '''0''' il ''reverse path filtering'' viene disabilitato, mentre assegnando il valore '''1''' viene attivato. In teoria è anche possibile assegnare un valore di compromesso (almeno in Red Hat e derivate), cioè '''2''', che comporta l'accettazione del pacchetto se questo può essere instradato da almeno una delle interfacce della macchina che riceve il pacchetto. È anche possibile aggiungere/modificare la medesima direttiva in modo che questa si applichi ad un interfaccia specifica, ad esempio scrivendo <code>net.ipv4.conf.eth0.rp_filter</code> si finirebbe per modificare il comportamento della sola interfaccia '''eth0'''.
+Val la pena rammentare che nel file <code>nano /etc/sysctl.conf</code> è anche possibile impostare la variabile per abilitare l'inoltro dei pacchetti, cioè <code>net.ipv4.ip_forward</code>.
+Il file <code>/etc/sysctl.conf</code> può anche essere modificato digitando i comandi in modo simile a quanto qui sotto scritto:
+<pre>sysctl -w "net.ipv4.conf.all.rp_filter=1" net.ipv4.conf.all.rp_filter = 1</pre>
+È anche possibile modificare i valori delle due suddette variabili modificando direttamente i relativi processi, ovvero editando i "file" <code>rp_filter</code> contenuti nelle opportune sottocartelle di <code>/proc/sys/net/ipv4/conf/</code> (ogni sottocartella corrisponde ad una diversa interfaccia). Volendo modificare tutti i processi è possibile eseguire il seguente comando:
+<pre># for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 >| $f ; done</pre>
+Da notare che le modifiche ai processi non sono permanenti, ovverro andranno perdute al prossimo riavvio di sistema.
 == Approfondimenti ==
@@ Riga 81: / Riga 215: @@
 {{Autori
 |Autore = [[Utente:Wtf|Wtf]] 00:10, 22 gen 2019 (CET)
-|Numero_revisori=1
+|Numero_revisori=0
 }}
 [[Categoria:Network tools]][[Categoria:E-zine]]