La cache di routing Linux per IPv4 è stata rimossa in Linux 3.6 (lasciando solo l'uso di un LPC-trie ottimizzato). Non c'è quindi modo con un sistema Linux con un sistema operativo successivo al 2012 di ottenere la cache di routing statistiche.
Un modo semplice per taggare l'uso del percorso predefinito è posizionare un realm valore su questa rotta. Un pacchetto corrispondente a questo percorso (piuttosto che a un percorso più specifico che utilizza lo stesso gateway) verrà identificato come avente il valore di realm specificato. Quindi, se il percorso predefinito era 192.0.2.1 tramite eth0 , il percorso verrebbe impostato ad esempio in questo modo:
ip route add default via 192.0.2.1 proto static realm 10
Oppure puoi modificare un percorso predefinito precedente (senza realm) sostituendo add con change , senza interruzioni.
Questo tag realm può quindi essere riutilizzato almeno in altri due sottosistemi di rete:tc filter ... route o nft ... meta rtclassid di nftables .
Controllo del traffico
tc è piuttosto rozzo e di solito funziona a livello di interfaccia. Il modo più semplice per allegare un filtro è usare il prio qdisc, il qdisc di classe più semplice. Le sue proprietà di priorità specifiche non verranno effettivamente utilizzate. Quindi seguendo l'esempio precedente:
tc qdisc add dev eth0 root handle 1: prio
Ora aggiungi il filtro con un'azione vuota (e con un pref ordina e continua control per consentire ulteriori filtri simili se necessario), solo per avere statistiche su di esso:
tc filter add dev eth0 parent 1: protocol ip pref 1 route to 10 action continue
Ora ogni pacchetto IP che corrisponde al route realm 10 verrà mostrato nelle statistiche utilizzando tc -s filter show dev eth0 . Esempio:
# tc -s filter show dev eth0
filter parent 1: protocol all pref 1 route chain 0
filter parent 1: protocol all pref 1 route chain 0 fh 0xffff000a to 10
action order 1: gact action continue
random type none pass val 0
index 1 ref 1 bind 1 installed 48 sec used 4 sec
Action statistics:
Sent 12230 bytes 79 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Nota:entrambi inoltrati e i pacchetti originati localmente corrispondono, il che potrebbe essere un problema per le misurazioni.
nftables
nftables qui non verrà utilizzato per fare alcun tipo di firewalling, ma solo per incrementare alcuni contatori.
nftables installa solo gli hook di netfilter richiesti, piuttosto che tutti quelli disponibili, quindi di solito ha un footprint minore rispetto a iptables . Qui abbiamo solo bisogno di una regola che corrisponda al regno:questo è il ruolo di rtclassid espressione - con un contatore sopra. Se è per pacchetti originati localmente, usa semplicemente output gancio. L'hook di inoltro corrisponderà solo ai pacchetti inoltrati.
nft add table ip mystats
nft add chain ip mystats forward '{ type filter hook forward priority 0; policy accept; }'
nft add rule ip mystats forward meta rtclassid 10 counter
Che darebbe ad esempio in seguito:
# nft list ruleset
table ip stats {
chain forward {
type filter hook forward priority filter; policy accept;
meta rtclassid 10 counter packets 1453 bytes 118264
}
}
L'azzeramento del valore è possibile solo se memorizzato in un oggetto con nome, il set di regole sarebbe invece (da caricare con nft -f file ):
table ip mystats {
counter defaultroutecount { }
chain forward {
type filter hook forward priority filter; policy accept;
meta rtclassid 10 counter name "defaultroutecount"
}
}
Quindi nft list counters o nft reset counters visualizzerà (o visualizzerà e resetterà) il suo contenuto.