Jak przechwytywać ruch na interfejsach wirtualnych?

Chciałbym przechwytywać ruch na wirtualnych interfejsach Linuksa w celu debugowania. I zostały eksperymentowanie z veth, tuna dummyinterfejs rodzajów; we wszystkich trzech mam problem tcpdumpz pokazaniem czegokolwiek.

Oto jak skonfigurowałem fikcyjny interfejs:

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

W jednym terminalu obejrzyj go za pomocą tcpdump:

tcpdump -i dummy10

Po chwili posłuchaj go z nc:

nc -l 99.99.99.1 2048

Po trzecie, złóż żądanie HTTP za pomocą curl:

curl http://99.99.99.1:2048/

Chociaż w terminalu 2 możemy zobaczyć dane z curlżądania, nic się nie pojawia tcpdump.

TUN / TAP poradnik wyjaśnia pewne sytuacje, w których jądro może faktycznie nie wysyła żadnych pakietów, gdy ktoś pracuje na lokalnym interfejsie:

Patrząc na wyniki tsharka, widzimy ... nic. Przez interfejs nie ma ruchu. Jest to poprawne: ponieważ pingujemy adres IP interfejsu, system operacyjny poprawnie decyduje, że żaden pakiet nie musi być wysyłany „na drut”, a samo jądro odpowiada na te pingi. Jeśli się nad tym zastanowić, dokładnie tak by się stało, gdyby pingować adres IP innego interfejsu (na przykład eth0): żadne pakiety nie zostaną wysłane. Może się to wydawać oczywiste, ale na początku może być źródłem nieporozumień (dotyczyło mnie).

Trudno jednak zrozumieć, w jaki sposób mogłoby to mieć zastosowanie do pakietów danych TCP.

Może tcpdumppowinien być związany z interfejsem w inny sposób?

Ruch przechodzi przez lointerfejs.

Po dodaniu adresu IP do skrzynki trasa dla tego adresu jest dodawana do tabeli „lokalnej”. Wszystkie trasy w tej tabeli kierują ruchem przez interfejs pętli zwrotnej.

Możesz wyświetlić zawartość tabeli „lokalnej” w następujący sposób:

ip route show table local

Który w moim systemie wygląda następująco:

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 

Więc w zasadzie, jeśli wyślę żadnego ruchu 10.230.134.38, 127.0.0.0/8, 127.0.0.1(zbędne) , 172.17.42.1albo 192.168.0.20, ruch będzie się kierowany przez interfejs pętli zwrotnej, nawet jeśli te adresy IP są naprawdę na innym interfejsie.

Możesz używać tcpdumpz dowolnym interfejsem na hoście ( tcpdump -i any ...)

Powinno to być możliwe poprzez wywołanie drugiego systemu (może być nawet maszyną wirtualną na tym hoście).

Możesz użyć DNATw OUTGOINGłańcuchu nattabeli i przekierować pakiety do interfejsu, którego jądro nie kontroluje. Musisz je tam odzwierciedlić:

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