Come si acquisisce il traffico su interfacce virtuali?

Vorrei catturare il traffico su interfacce virtuali Linux, a scopo di debug. Ho avuto modo di sperimentare con veth, tune dummyl'interfaccia tipi; su tutti e tre, ho difficoltà tcpdumpa mostrare qualcosa.

Ecco come ho impostato l'interfaccia fittizia:

ip link add dummy10 type dummy
ip addr add 99.99.99.1 dev dummy10
ip link set dummy10 up

In un terminale, guardalo con tcpdump:

tcpdump -i dummy10

In un secondo, ascoltalo con nc:

nc -l 99.99.99.1 2048

In un terzo momento, effettua una richiesta HTTP con curl:

curl http://99.99.99.1:2048/

Sebbene nel terminale 2 possiamo vedere i dati dalla curlrichiesta, non viene visualizzato nulla tcpdump.

Un tutorial Tun / Tap chiarisce alcune situazioni in cui il kernel potrebbe non inviare effettivamente alcun pacchetto quando si opera su un'interfaccia locale:

Guardando l'output di Tshark, non vediamo ... niente. Non c'è traffico che passa attraverso l'interfaccia. Questo è corretto: poiché stiamo eseguendo il ping dell'indirizzo IP dell'interfaccia, il sistema operativo decide correttamente che nessun pacchetto deve essere inviato "sul filo" e il kernel stesso risponde a questi ping. Se ci pensate, è esattamente cosa accadrebbe se si eseguisse il ping dell'indirizzo IP di un'altra interfaccia (ad esempio eth0): nessun pacchetto verrebbe inviato. Potrebbe sembrare ovvio, ma all'inizio potrebbe essere fonte di confusione (era per me).

Tuttavia, è difficile vedere come ciò possa applicarsi ai pacchetti di dati TCP.

Forse tcpdumpdovrebbe essere associato all'interfaccia in un modo diverso?

Il traffico passa attraverso l' lointerfaccia.

Quando un IP viene aggiunto a una casella, un percorso per quell'indirizzo viene aggiunto alla tabella "locale". Tutti i percorsi in questa tabella indirizzano il traffico sull'interfaccia di loopback.

È possibile visualizzare i contenuti della tabella 'locale' con quanto segue:

ip route show table local

Quale sul mio sistema è simile al seguente:

local 10.230.134.38 dev tun0  proto kernel  scope host  src 10.230.134.38 
broadcast 10.230.134.38 dev tun0  proto kernel  scope link  src 10.230.134.38 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 172.17.0.0 dev docker0  proto kernel  scope link  src 172.17.42.1 
local 172.17.42.1 dev docker0  proto kernel  scope host  src 172.17.42.1 
broadcast 172.17.255.255 dev docker0  proto kernel  scope link  src 172.17.42.1 
broadcast 192.168.0.0 dev enp6s0  proto kernel  scope link  src 192.168.0.20 
local 192.168.0.20 dev enp6s0  proto kernel  scope host  src 192.168.0.20 
broadcast 192.168.0.255 dev enp6s0  proto kernel  scope link  src 192.168.0.20 

Quindi, in pratica, se mando tutto il traffico a 10.230.134.38, 127.0.0.0/8, 127.0.0.1(ridondante) , 172.17.42.1o 192.168.0.20, il traffico otterrà instradato attraverso l'interfaccia di loopback, anche se quelle IP sono davvero su un'interfaccia diversa.

È possibile utilizzare tcpdumpcon qualsiasi interfaccia sull'host ( tcpdump -i any ...)

Ciò dovrebbe essere possibile invocando un secondo sistema (potrebbe anche essere una macchina virtuale su quell'host).

È possibile utilizzare DNATnella OUTGOINGcatena della nattabella e reindirizzare i pacchetti a un'interfaccia che il kernel non controlla. Devi rifletterli lì:

iptables -t nat -A OUTPUT -p tcp -d 99.99.99.1 --dport 2048 \
  -j DNAT --to-destination 1.2.3.4