¿Cómo se captura el tráfico en las interfaces virtuales?

Me gustaría capturar el tráfico en las interfaces virtuales de Linux, con fines de depuración. He estado experimentando con veth, tuny dummytipos de interfaz; en los tres, tengo problemas tcpdumppara mostrar algo.

Así es como configuro la interfaz ficticia:

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

En una terminal, míralo con tcpdump:

tcpdump -i dummy10

En un segundo, escúchalo con nc:

nc -l 99.99.99.1 2048

En un tercero, haga una solicitud HTTP con curl:

curl http://99.99.99.1:2048/

Aunque en la terminal 2 podemos ver los datos de la curlsolicitud, no aparece nada tcpdump.

Un tutorial Tun / Tap aclara algunas situaciones en las que el núcleo puede no enviar ningún paquete cuando uno está operando en una interfaz local:

Mirando la salida de tshark, vemos ... nada. No hay tráfico pasando por la interfaz. Esto es correcto: dado que estamos haciendo ping a la dirección IP de la interfaz, el sistema operativo decide correctamente que no es necesario enviar ningún paquete "en el cable", y el núcleo mismo está respondiendo a estos pings. Si lo piensa, es exactamente lo que sucedería si pinchara la dirección IP de otra interfaz (por ejemplo, eth0): no se enviarían paquetes. Esto puede sonar obvio, pero podría ser una fuente de confusión al principio (lo fue para mí).

Sin embargo, es difícil ver cómo esto podría aplicarse a los paquetes de datos TCP.

Tal vez tcpdumpdebería estar vinculado a la interfaz de una manera diferente?

El tráfico pasa por la lointerfaz.

Cuando se agrega una IP a un cuadro, se agrega una ruta para esa dirección a la tabla 'local'. Todas las rutas en esta tabla enrutan el tráfico a través de la interfaz de bucle invertido.

Puede ver el contenido de la tabla 'local' con lo siguiente:

ip route show table local

Que en mi sistema se ve así:

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 

Así que, básicamente, si envío a todo el tráfico 10.230.134.38, 127.0.0.0/8, 127.0.0.1(redundante) , 172.17.42.1o 192.168.0.20, el tráfico se enruta a través de obtener la interfaz de bucle de retorno, a pesar de que esas IPs son realmente en una interfaz diferente.

Puede usar tcpdumpcon cualquier interfaz en el host ( tcpdump -i any ...)

Esto debería ser posible invocando un segundo sistema (puede ser incluso una VM en ese host).

Puede usar DNATen la OUTGOINGcadena de la nattabla y redirigir los paquetes a una interfaz que el núcleo no controla. Tienes que reflejarlos allí:

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