web-dev-qa-db-ja.com

TAPインターフェイスの着信パケットがtcpdumpでは表示され、iptablesでは表示されないのはなぜですか？

プログラムはLinuxにパケットを注入します [〜＃〜] tap [〜＃〜] インターフェース（これらのパケットは仮想マシンからのものです）。具体的には、これらはDHCP要求です（つまり、UDPです）。 tcpdumpではパケットを表示できますが、iptablesではパケットを表示できません。また、ローカルDHCPサーバーにも到達しません。なぜそうしないのですか、どうすれば修正できますか？

Update：tap0インターフェースのアドレスに向けられたIPパケットを挿入しようとしました。 VM in tcpdump -i tap0]からARPリクエストが送信されるのを確認しましたが、ネットワークレイヤーが応答しません。ARPリクエストをVMに送信すると、VMはそれを確認し、ホスト（および応答はtcpdumpに表示されますが、それ以外の場合は失われます）。

別の観察：ifconfig tap0は、ホストに挿入されたパケットごとに、TXドロップパケットカウントが増加することを示しています。なぜTX？

# ifconfig tap0
…
          TX packets:0 errors:0 dropped:958 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

長い話：Linuxホスト（Ubuntu 10.04を実行）では、とりわけイーサネットカードをエミュレートする仮想マシンを実行しています。これは、ホストのネットワークスタックへのイーサネットパケットの注入とキャプチャを担当するヘルパープログラムと通信することによって行われます。仮想マシンはARMチップエミュレータであり、ヘルパープログラムはnicserverと呼ばれます。私が知っているのは ARMドキュメント =。

VMとホストの間にイーサネットリンクを確立したいと思います。その上にIPリンクが必要です。VMはDHCP経由でIPアドレスを取得します。 VMと他の世界との間の通信はホストとのみ通信したくないので、仮想ネットワークインターフェイスtap0を

tunctl -u gilles
ifconfig tap0 192.168.56.1 netmask 255.255.255.0 up
nicserver -p 7801 -a tap0 &

これでVMを起動し、tcpdump -n -i tap0 -vvを使用してDHCP要求を送信していることがわかります（DHCPクライアントはタイムアウトせず、ここでは1つのサンプル要求を示しています）。

tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
18:29:23.941574 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 576)
    0.0.0.0.68 > 255.255.255.255.67: [no cksum] BOOTP/DHCP, Request from 02:52:56:47:50:03, length 548, xid 0x238a7979, secs 46, Flags [none] (0x0000)
          Client-Ethernet-Address 02:52:56:47:50:03 [|bootp]

ホストにDnsmasqを設定してリクエストを処理しましたが、着信リクエストが表示されません。 Dnsmasqサーバーは着信要求さえも認識しません（私はそれを追跡しました）。そこで、Iptablesでパケットを観察してみました。 （すべてのフィルター/入力規則が表示されます。マングルまたはNAT規則はありません）。

Chain INPUT (policy ACCEPT 2366K packets, 5334M bytes)
 pkts bytes target     prot opt in     out     source               destination 
  119 39176 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:67 LOG flags 4 level 4 prefix `[DHCP request] '
  119 39176 DROP       udp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           udp dpt:67
    2   490 LOG        udp  --  tap0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 4 level 4 prefix `[in=tap0] '
   26  6370 ACCEPT     udp  --  tap0   *       0.0.0.0/0            0.0.0.0/0   
    0     0 ACCEPT     all  --  tap0   *       0.0.0.0/0            0.0.0.0/0   
 3864  457K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0

これらすべての着信DHCP要求はeth1にあります（そして、同僚やネットワーク管理者を怒らせないように、これらを無視しないように注意しています）。 tap0上のUDPパケットは、ローカルのSambaサーバーから送信されます。 tcpdumpで表示されるDHCP要求パケットが、パケットフィルターを通過していないようです。

着信ブロードキャストパケットがtcpdumpではなくiptablesでtap0に表示されるのはなぜですか（またはマシンでリッスンしているプログラムでも）？また、これらのパケットがイーサネットインターフェイスで受信された場合と同様に、これらのパケットが表示されるようにするには何を修正する必要がありますか？

linuxnetworkingiptablestunnelingtap
7
Gilles 'SO- stop being evil'

ここにさらに当て推量があります。これが役に立てば幸いですが、恥ずかしいほど間違っているかもしれません。

tap0には、カーネルネットワークスタックの端とプログラムインターフェイスの2つの端があります。 「nicserver」にtap0を指定すると、プログラムインターフェイスを使用して、tapデバイスで意図したとおりに接続されません。代わりに、nicserverはネットワークスタックの端から書き込みを行うだけで、プログラムインターフェイスの端からアプリケーションが読み取らないと、デバイスキューがオーバーフローすることになります。これは、ドロップされたパケットを説明しています。また、iptablesの結果を説明する可能性のあるパケットは配信されません。

Tcpdumpをtap0でキャプチャーさせると、tap0のプログラム・インターフェースの終わりに実際に接続し、実際にはパケットが表示されると思います。私はインターネットを検索しましたが、そのような動作を確認するための情報源が見つかりませんでした。この理論を改ざんするには、tap0をキャプチャして、パケットドロップとiptablesログにどのように影響するかを確認してください。

最後に、元の問題に対処するためのアドバイスです。代わりにループバックデバイスの使用についてはどうですか？そのようです：

nicserver -p 7801 -a lo
1
artistoex