Iproute2
| Iproute2 | ||
|---|---|---|
| ||
|
Quando i tools classici non bastano per configurazioni di rete complesse, viene in soccorso la suite iproute2: il futuro del networking.
| ||
| Link agli articoli: |
pmate 09:22, 17 feb 2010 (CET)
 Versioni Compatibili Tutte le versioni supportate di Debian |
| Gateway-Router |
|
Sommario |
Comandi
Informazioni
Visualizzare le informazioni di tutte le interfacce:
ip addr ip address show
Visualizzare le informazioni di una specifica interfaccia, per esempio eth0:
ip address show dev eth0
Visualizzare le rotte della tabella di routing predefinita (cioè di quella principale):
ip route show ip route show table main
Visualizzare tutte le regole correntemente in vigore:
ip rule show
Visualizzare tutte le regole correntemente in vigore della sola tabella predefinita:
ip rule show table main
Visualizzare la tabella ARP comprendente tutte le interfacce:
ip neighbor show
Gestione interfacce
Aggiungere un indirizzo all'interfaccia eth0:
# ip address add 192.0.2.10/24 dev eth0
Cancellare un indirizzo associato all'interfaccia eth0:
# ip address delete 192.0.2.10/24 dev eth0
Attivare l'interfaccia eth0:
# ip link set dev eth0 up
Disattivare l'interfaccia eth0:
# ip link set dev eth0 down
Svuotare la cache arp per tutte le interfacce:
ip neigh flush all
Aggiungere un secondo indirizzo all'interfaccia eth0:
# ip address add 192.0.2.20/24 dev eth0
che come si vede non presenta alcuna differenza con l'assegnazione del primo indirizzo. Con iproute2 infatti gli indirizzi aggiuntivi vengono semplicemente assegnati direttamente all'interfaccia, senza bisogno di creare alcun alias (come invece chiedeva ifconfig), tuttavia per questioni di retrocompatibilità è opportuno e consigliato definire anche un'etichetta che segua le regole del vecchio ifconfig.
Il precedente comando diviene quindi:
# ip address add 192.0.2.20/24 dev eth0 label eth0:0
Si noti che gli indirizzi aggiuntivi possono anche appartenere a subnet diverse, non devono cioè necessariamente appartenere alla stessa subnet del primo indirizzo dichiarato.
Cancellare tutti gli indirizzi aggiunti all'interfaccia eth0
# ip address flush dev eth0 scope global
Creare un'interfaccia virtuale (vlan 802.1q, da non confondere con veth interfaccia ethernet virtuale) per eth0
# ip link add link eth0 name eth0.1 type vlan id 1
Rimuovere l'interfaccia virtuale appena creata
# ip link delete eth0.1
Instradamento
Aggiungere una rotta che passa per 129.0.2.1 (gateway):
# ip route add 192.0.2.128/25 via 192.0.2.1
Aggiungere una rotta che passa per ppp0:
# ip route add 192.0.2.0/25 dev ppp0
Impostare ppp0 come gateway predefinito:
# ip route add default dev ppp0
Impostare l'IP 192.0.2.1 come gateway predefinito:
# ip route add default via 192.0.2.1
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 101.13.15.179:
# ip rule add from 101.13.15.179 table tab1
Usa la tabella di routing "tab1" (invece di quella principale) quando un pacchetto è diretto all'IP 101.13.15.179:
# ip rule add to 101.13.15.179 table tab1
Usa la tabella di routing "tab1" (invece di quella principale) quando un pacchetto è contrassegnato col valore 1:
# ip rule add from all fwmark 1 table 1
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:
# ip rule del pref [selector]
dove selector è un numero di 5 cifre associato ad ogni regola (visibile col comando ip rule).
Cancellare tutte le regole relative alla tabella "tab1":
# while ip rule delete from 0/0 to 0/0 table tab1 2>/dev/null; do true; done
Aggiungere tabelle di routing
È possibile aggiungere altre tabelle di routing oltre a quella principale. Per fare ciò è sufficiente editare il file /etc/iproute2/rt_tables 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ì:
# # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 1 tab1
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.
Network namespaces
Elencare i namespaces attualmente esistenti:
# ip netns list
Se non ne esistono viene restituita una stringa vuota.
Creare un nuovo namespace di nome "test":
# ip netns add test
Cancellare un namespace di nome "test":
# ip netns del test
Eseguire un applicativo nel namespace "test":
# ip netns exec test ping 8.8.8.8
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 enp3s0. 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.
Si procederà dunque alla creazione di un namespace "test" in bridge con enp3s0 tramite un interfaccia ethernet virtuale. Si ipotizza inoltre per semplicità che tutti i dispositivi/interfacce siano configurati per utilizzare la subnet 192.168.1.0/24.
Creazione del namespace:
# ip netns add test
Creazione di una coppia di interfacce di rete virtuali vth0a e vth0b.
# ip link add vth0a type veth peer name vth0b
Trasferimento di vth0b in "test":
# ip link set vth0b netns test
Eseguendo ora il comando ip link list si noterà che sarà presente solo vth0a, infatti vth0b risulterà visibile solo nel namespace "test" tramite il comando ip netns exec test ip link list.
Attivare e configurare le necessarie interfacce di rete per il namespace test:
# 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
Poiché la premessa è stata quella di mettere in bridge l'interfaccia vth0a con enp3s0 alla prima non è stato assegnato alcun indiritto IP.
Creazione di un bridge di rete denominato br0 (maggiori informazioni QUI)
# 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
Aggiunta di una rotta predefinita per il namespace "test" (è necessario indicare l'ip di br0)
ip netns exec test ip route add default via 192.168.1.100
A questo punto è possibile forzare un qualsiasi applicativo ad usare l'interfaccia enp3s0 semplicemente digitando:
# ip netns exec test "stringa_comando"
Nel caso si desidere eseguire l'applicativo senza i privilegi di root sarà sufficiente modificare il precedente comando nel seguente modo:
# ip netns exec test su -c "stringa_comando" nome_utente_non_privilegiato
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. tab1), 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 fwmark 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 nano /etc/sysctl.conf:
net.ipv4.conf.default.rp_filter net.ipv4.conf.all.rp_filter
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 net.ipv4.conf.eth0.rp_filter si finirebbe per modificare il comportamento della sola interfaccia eth0.
Val la pena rammentare che nel file nano /etc/sysctl.conf è anche possibile impostare la variabile per abilitare l'inoltro dei pacchetti, cioè net.ipv4.ip_forward.
Il file /etc/sysctl.conf può anche essere modificato digitando i comandi in modo simile a quanto qui sotto scritto:
sysctl -w "net.ipv4.conf.all.rp_filter=1" net.ipv4.conf.all.rp_filter = 1
È anche possibile modificare i valori delle due suddette variabili modificando direttamente i relativi processi, ovvero editando i "file" rp_filter contenuti nelle opportune sottocartelle di /proc/sys/net/ipv4/conf/ (ogni sottocartella corrisponde ad una diversa interfaccia). Volendo modificare tutti i processi è possibile eseguire il seguente comando:
# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 >| $f ; done
Da notare che le modifiche ai processi non sono permanenti, ovverro andranno perdute al prossimo riavvio di sistema.
Approfondimenti
Manpages
man ip
Sitografia
| Guida scritta da: Wtf 00:10, 22 gen 2019 (CET) |  Debianized 20%
|
| Estesa da: | |
| Verificata da: | |
|
Verificare ed estendere la guida | Cos'è una guida Debianized | |