Warum werden eingehende Pakete auf einer TAP-Schnittstelle mit tcpdump angezeigt, nicht jedoch mit iptables?

Ein Programm fügt Pakete in eine Linux- TAP- Schnittstelle ein (diese Pakete stammen von einer virtuellen Maschine). Dies sind insbesondere DHCP-Anforderungen (also UDP). Ich kann die Pakete mit, tcpdumpaber nicht mit sehen iptablesund sie erreichen auch nicht den lokalen DHCP-Server. Warum nicht und wie behebe ich das?

Update : Ich habe versucht, IP-Pakete zu injizieren, die an die Adresse der tap0Schnittstelle gerichtet sind. Ich sehe die ARP-Anforderungen, die von der VM eingehen tcpdump -i tap0, aber die Netzwerkschicht antwortet nicht. Wenn ich ARP-Anforderungen an die VM sende, werden diese angezeigt und Antworten an den Host gesendet (und die Antworten werden in angezeigt, gehen tcpdumpaber ansonsten verloren).

Eine weitere Beobachtung: ifconfig tap0zeigt, dass die Anzahl der gesendeten TX-Pakete für jedes Paket, das auf den Host injiziert wird, erhöht wird. Warum 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)

Die lange Geschichte: Auf einem Linux-Host (unter Ubuntu 10.04) verwende ich eine virtuelle Maschine, die unter anderem eine Ethernet-Karte emuliert. Dies geschieht durch die Kommunikation mit einem Hilfsprogramm, das für das Injizieren und Erfassen von Ethernet-Paketen auf dem Netzwerkstapel des Hosts zuständig ist. Die virtuelle Maschine ist ein ARM-Chip-Emulator, und das Hilfsprogramm wird aufgerufen nicserver. Ich weiß nur, was in der ARM-Dokumentation zu finden ist .

Ich möchte eine Ethernet-Verbindung zwischen der VM und dem Host herstellen und darüber hinaus eine IP-Verbindung. Die VM erhält ihre IP-Adresse über DHCP. Ich möchte keine Kommunikation zwischen der VM und dem Rest der Welt, nur mit dem Host, also habe ich eine virtuelle Netzwerkschnittstelle tap0mit erstellt

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

Jetzt starte ich die VM und sehe, dass sie DHCP-Anforderungen mit sendet tcpdump -n -i tap0 -vv(der DHCP-Client läuft nicht ab, ich zeige hier nur eine Beispielanforderung):

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]

Ich habe Dnsmasq auf dem Host eingerichtet, um die Anforderungen zu bearbeiten, aber es werden keine eingehenden Anforderungen angezeigt. Der Dnsmasq-Server sieht nicht einmal die eingehenden Anfragen (ich habe es gespannt). Also habe ich versucht, die Pakete mit Iptables zu beobachten. (Alle Filter- / INPUT-Regeln werden angezeigt; es gibt keine Mangle- oder Nat-Regeln.)

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

Alle diese eingehenden DHCP-Anfragen sind aktiviert eth1(und ich achte darauf, diese nicht zu ignorieren, um meine Kollegen und meinen Netzwerkadministrator nicht zu verärgern). Diese UDP-Pakete tap0stammen vom lokalen Samba-Server. Die DHCP-Anforderungspakete, die ich mit tcpdump sehe, scheinen den Paketfilter nicht zu durchlaufen!

Warum sehe ich eingehende Broadcast-Pakete tap0mit, tcpdumpaber nicht mit iptables(oder mit Programmen, die auf dem Computer abhören)? Und was muss ich reparieren, damit diese Pakete so angezeigt werden, als würden sie über eine Ethernet-Schnittstelle übertragen?

— Gilles 'SO - hör auf böse zu sein'
quelle

Versuchen Sie vielleicht, physdev Matching Iptables zu verwenden, und prüfen Sie, ob sich dadurch die Art und Weise ändert, wie Sie den Datenverkehr sehen. iptables -A INPUT -p udp --dport 67 -m physdev --physdev-in tap+ -j LOG --log-level 4 --log-prefix "[in=tap0] "

— Tim Kennedy

-m physdevwird normalerweise mit Bridges und Tap-Schnittstellen verwendet. Ich weiß, dass Sie nicht versuchen, die Tap-Schnittstelle mit Ihrem Eth zu verbinden, aber ich frage mich, ob die Verwendung von physdev zur Anpassung an die Schnittstelle den Datenverkehr irgendwie ändert, um sie sichtbar zu machen. Ich habe jedoch keine Ahnung, ob es funktionieren oder etwas ändern wird.

— Tim Kennedy

@ TimKennedy ändert nichts. Mehr Seltsamkeit: Wenn ich sage nicserver, dass ich sie verwenden soll eth0, werden sogar tcpdumpkeine Pakete angezeigt . Dies könnte ein Problem sein nicserver, aber ich möchte immer noch wissen, wie Pakete von tcpdumpon tap0und nicht von gesehen werden können iptables.

— Gilles 'SO - hör auf böse zu sein'

wenn Sie laufen tcpdumpmit -p, kann tcpdumpimmer noch die Pakete sehen? (-p beschränkt das tcpdumpVersetzen der Benutzeroberfläche in den Promiscuous-Modus.) Da iptablesdie Benutzeroberfläche nicht in den Promiscuous-Modus versetzt wird, erhalten Sie einen genaueren Vergleich mit dem, was iptablesangezeigt wird.

— Tim Kennedy

Fügen Sie Ihr Protokollziel in die Vorbereitungskette ein. Ich empfehle auch das schöne iptables-Flussdiagramm auf Wikipedia.

— artistoex

Hier gibt es weitere Vermutungen. Ich hoffe, das ist hilfreich, aber es kann genauso peinlich falsch sein.

tap0 hat zwei Enden, das Ende des Kernel-Netzwerkstapels und die Programmschnittstelle. Es scheint mir, wenn Sie 'nicserver' mit tap0 versorgen, wird es nicht über die Programmschnittstelle so angehängt, wie es mit tap-Geräten beabsichtigt ist. Stattdessen schreibt nicserver einfach vom Ende des Netzwerkstapels darauf, und wenn keine Anwendung vom Ende der Programmschnittstelle gelesen wird, wird die Gerätewarteschlange überfüllt. Dies erklärt die verworfenen Pakete. Außerdem werden keine Pakete zugestellt, was das Ergebnis von iptables erklären könnte.

Ich denke, wenn Sie tcpdump auf tap0 erfassen lassen, wird es tatsächlich an das Ende der Programmschnittstelle von tap0 angehängt, und voila, Sie sehen die Pakete. Ich habe im Internet gesucht, aber keine Quelle gefunden, um ein solches Verhalten zu bestätigen. Um diese Theorie zu verfälschen, erfassen Sie tap0 und sehen Sie, wie sich dies auf Paketverluste und das iptables-Protokoll auswirkt.

Zum Schluss noch ein Rat, der sich mit Ihrem ursprünglichen Problem befasst: Wie wäre es stattdessen mit der Verwendung des Loopback-Geräts? Wie so:

nicserver -p 7801 -a lo

— artistoex
quelle