仮想インターフェイス上のトラフィックをどのようにキャプチャしますか?


12

デバッグのために、Linux仮想インターフェイスでトラフィックをキャプチャしたいと思います。vethtunおよびdummyインターフェイスの種類を試しています。3つすべてで、tcpdump何かを表示するのに苦労しています。

ダミーインターフェイスの設定方法は次のとおりです。

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

1つの端末で、次のように監視しtcpdumpます。

tcpdump -i dummy10

すぐに、次の方法で試聴しますnc

nc -l 99.99.99.1 2048

3番目では、次を使用してHTTP要求を作成しますcurl

curl http://99.99.99.1:2048/

ターミナル2ではcurlリクエストからのデータを見ることができますが、からは何も表示されませんtcpdump

A TUN / TAPチュートリアル明確化カーネルは実際には1つのローカルインターフェイス上で動作しているすべてのパケットを送信しないことがあり、いくつかの状況:

tsharkの出力を見ると、何もありません。インターフェイスを通過するトラフィックはありません。これは正しいです。インターフェイスのIPアドレスにpingを送信しているため、オペレーティングシステムはパケットを「有線」で送信する必要がないと正しく判断し、カーネル自体がこれらのpingに応答しています。考えてみると、別のインターフェイスのIPアドレス(たとえばeth0)にpingを実行した場合に発生することです。パケットは送信されません。これは明白に聞こえるかもしれませんが、最初は混乱の原因になる可能性があります(私にとっては)。

ただし、これがTCPデータパケットにどのように適用されるかを確認するのは困難です。

たぶん、tcpdump別の方法インタフェースにバインドする必要がありますか?


なぜTCPパケットが発生しているのが見にくいのかわかりません。pingと同様に、これらはカーネルで処理されます。同じことが起こっています。
デロバート14

@derobert pingの場合、カーネルは応答できます。データパケットの場合、アプリケーションが応答できるように、インターフェイスを "オーバー"する必要があると思いました。
solidsnack

1
アプリケーションは、読み取り、書き込みなどを使用してカーネルと通信します。多くのネットワークアプリは、インターフェイスが存在することを認識する必要さえありません。トラフィックをそれらの1つを通過させるには、カーネルがそれを非ローカルとして認識する必要があります。たとえば、OpenVPNトンネルを設定すると、tun0を通過するトラフィックをキャプチャできます。(もちろん、tun0はアプリがカーネルと通信し、ユーザーランドにネットワークインターフェースを実装するための特別な方法です。これはOpenVPNの機能です。)
derobert 14

回答:


8

トラフィックは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.38127.0.0.0/8127.0.0.1(冗長)172.17.42.1または192.168.0.20、トラフィックがそれらのIPアドレスが別のインターフェイス上で実際にあるにもかかわらず、ループバックインターフェイスを介してルーティングされます。



0

これは、2番目のシステム(そのホスト上のVMであってもよい)を呼び出すことで可能になります。

テーブルDNATOUTGOINGチェーンで使用しnat、カーネルが制御しないインターフェイスにパケットをリダイレクトできます。それらをそこに反映する必要があります:

iptables -t nat -A OUTPUT -p tcp -d 99.99.99.1 --dport 2048 \
  -j DNAT --to-destination 1.2.3.4
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.