Como alguém captura tráfego em interfaces virtuais?

Question

Eu gostaria de capturar o tráfego nas interfaces virtuais do Linux, para fins de depuração. Eu tenho experimentado com veth , tun e dummy tipos de interface; em todos os três, estou tendo problemas para obter tcpdump para mostrar qualquer coisa.

Aqui está como eu configurei a interface fictícia:

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

Em um terminal, observe-o com tcpdump :

tcpdump -i dummy10

Em um segundo, ouça com nc :

nc -l 99.99.99.1 2048

Em um terceiro, faça uma solicitação HTTP com curl :

curl http://99.99.99.1:2048/

Embora no terminal 2 possamos ver os dados da solicitação curl , nada aparece em tcpdump .

Um tutorial do Tun / Tap esclarece algumas situações em que o kernel pode não enviar nenhum pacotes quando um está operando em uma interface local:

Looking at the output of tshark, we see...nothing. There is no traffic going through the interface. This is correct: since we're pinging the interface's IP address, the operating system correctly decides that no packet needs to be sent "on the wire", and the kernel itself is replying to these pings. If you think about it, it's exactly what would happen if you pinged another interface's IP address (for example eth0): no packets would be sent out. This might sound obvious, but could be a source of confusion at first (it was for me).

No entanto, é difícil ver como isso pode se aplicar aos pacotes de dados TCP.

Talvez tcpdump deva ser vinculado à interface de uma maneira diferente?

    

Answer 1

O tráfego está passando pela interface lo .

Quando um IP é adicionado a uma caixa, uma rota para esse endereço é adicionada à tabela 'local'. Todas as rotas nesta tabela encaminham o tráfego pela interface de loopback.

Você pode visualizar o conteúdo da tabela "local" com o seguinte:

ip route show table local

Que no meu sistema tem esta aparência:

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 

Então, basicamente, se eu enviar tráfego para 10.230.134.38 , 127.0.0.0/8 , 127.0.0.1 (redundante) , 172.17.42.1 ou 192.168.0.20 , o tráfego será encaminhado pelo loopback interface, mesmo que esses IPs estejam realmente em uma interface diferente.

    

Answer 2

Você pode usar tcpdump com qualquer interface no host ( tcpdump -i any ... )

    

Answer 3

Isso deve ser possível invocando um segundo sistema (pode até ser uma VM nesse host).

Você pode usar DNAT na cadeia OUTGOING da tabela nat e redirecionar os pacotes para uma interface que o kernel não controla. Você tem que refletir lá:

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