Як можна фіксувати трафік на віртуальних інтерфейсах?

Я хотів би захопити трафік на віртуальних інтерфейсах Linux для налагодження. Я експериментував з veth, tunі dummyінтерфейсом типу; на всіх трьох, у мене виникають труднощі змусити tcpdumpщось показати.

Ось як я налаштував фіктивний інтерфейс:

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

В одному терміналі дивіться це за допомогою tcpdump:

tcpdump -i dummy10

За секунду послухайте це за допомогою nc:

nc -l 99.99.99.1 2048

По-третє, зробіть HTTP-запит curl:

curl http://99.99.99.1:2048/

Хоча в терміналі 2 ми можемо бачити дані curlзапиту, з них нічого не з’являється tcpdump.

Tun / Tap підручник прояснює деякі ситуації , коли ядро не може фактично посилати будь-які пакети , коли один працює на локальному інтерфейсі:

Дивлячись на вихід царкви, ми бачимо ... нічого. Трафік не проходить через інтерфейс. Це правильно: оскільки ми пінгуємо IP-адресу інтерфейсу, операційна система правильно вирішує, що жоден пакет не потрібно надсилати "по дроту", а саме ядро ​​відповідає на ці пінг. Якщо ви подумаєте про це, саме те, що буде, якби ви пінговували IP-адресу іншого інтерфейсу (наприклад, eth0): жодні пакети не надсилалися б. Це може здатися очевидним, але спочатку може бути джерелом плутанини (це було для мене).

Однак важко зрозуміти, як це могло поширюватися на пакети даних TCP.

Можливо, tcpdumpслід прив'язати до інтерфейсу іншим способом?

Трафік йде через loінтерфейс.

Коли в поле додається IP-адреса, маршрут до цієї адреси додається до таблиці "локальний". Усі маршрути в цій таблиці прокладають трафік через інтерфейс зворотного зв'язку.

Ви можете переглянути вміст "локальної" таблиці за допомогою наступного:

ip route show table local

Що в моїй системі виглядає приблизно так:

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 

Отже, якщо я надсилаю будь-який трафік на 10.230.134.38( 127.0.0.0/8, 127.0.0.1(надлишковий) , 172.17.42.1або 192.168.0.20, трафік буде направлятись через інтерфейс зворотного зв'язку, хоча ці IP-адреси дійсно є на іншому інтерфейсі.

Ви можете використовувати tcpdumpз будь-яким інтерфейсом на хості ( tcpdump -i any ...)

Це повинно бути можливим шляхом виклику другої системи (може бути навіть VM на цьому хості).

Ви можете використовувати DNATу OUTGOINGланцюжку natтаблиці та перенаправляти пакети на інтерфейс, який ядро ​​не контролює. Ви повинні відобразити їх там:

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