Dhcp-client an tap-device via Bridge ...

[gxyz]

Ich versuche, ein tap-device auf ein physikalisches Interface zu bridgen - an sich eine banale Sache, die aber aus irgendwelchen Gründen nicht klappt. Letztlich soll das Konstrukt natürlich für eine virtuelle Maschine sein, aber auf's Minimum reduziert sieht das Ganze etwa so aus:

Code: Alles auswählen

brctl addbr br
ifconfig ethx up
tunctl -t tap0
ifconfig tap0 up
brctl addif br ethx tap0
ifconfig br up

Auf den 1. Blick scheint das auch zu tun (zumindest manche Pakete werden über die Bridge weitergeleitet), aber wenn ich auf tap0 einen DHCP-Client starte (dhclient -v tap0) und schaue, was über ethx weiterbefördert wird (tcpdump -i ethx), dann fehlt jedenfalls von den DHCP-Paketen jede Spur. (Nach ausgedehnter Web-Suche habe ich schon allerlei Variationen in der Reihenfolge und den genauen Parametern für obiges Setup versucht, die aber alle keinen Unterschied machen).

Hat vielleicht jemand eine schlaue Idee, wo das Problem liegt?

[gxyz]

... allmählich bin ich etwas ratlos - offensichtlich unterliege ich wohl irgendeinem grundsätzlichen Missverständnis bezüglich der Funktion einer Bridge unter Linux. Wie es scheint funktioniert ein Netz-Interface sobald es Mitglied einer Bridge ist nicht mehr als "normales" Interface: Wenn ich auf einem Rechner mit funktionierender Ethernet-Anbindung das Interface in eine Bridge aufnehme, ist die Maschine über IP nicht mehr erreichbar; z.B:

ifconig eth0 192.168.1.1
# -> alles schön, ping 192.168.1.1 von außen kommt an, ping nach außen ebenso

brctl addbr br; brctl addif br eth0; brctl br up
# manche Pakete wie z.B. arp-Requests werden über die Bridge weitergeleitetet, das meiste nicht:
# auf der Maschine lässt sich 192.168.1.1 noch anpingen, sonst IP-mäßig alles futsch.

Wenn ich stattdessen der Bridge selbst die ursprüngliche Adresse zuweise:
ifconfig eth0 0.0.0.0; ifconfig br 192.168.1.1
dann geht's wieder (allerdings ist die Bridge dann auch völlig nutzlos ;-)

Laut so ziemlich jeder Dokumentation zu der Linux-Bridge-Implementierung die ich finden kann soll sich der Kram eigentlich wie ein Netzwerk-Switch verhalten, also beliebige Ethernet-Pakete wenn bekannt ist hinter welchem Interface sie zu finden sind auf das betreffende Interface weiterleiten, ansonsten an alle Ports außer dem Ursprungsport. Soweit es darum geht, den Netzverkehr zwischen mehreren physikalischen Interfaces weiterzuleiten, klappt das ja auch genau so. In meinem Fall will ich allerdings mehrere virtuelle Interfaces auf einer Maschine über ein physikalisches Interface mit dem umliegenden Netzwerk verbinden.

In Bezug auf qemu (dafür soll das Ganze letztlich sein, der Rest sind eher Etüden) bin ich mir allerdings gar nicht so sicher: Ich dachte eigentlich, qemu würde direkt ein TAP-Interface erzeugen und in die Bridge aufnehmen. Wenn ich allerdings qemu so konfiguriere, wie an diversen Stellen für ein derartiges Setup beschrieben (Bridge vorkonfiguriert, Script zum Erzeugen eines TAP-Devices, "qemu ... -net nic, macddr=xx:yy: ...") sehe ich in dem Qemu-Fenster die angegebene MAC-Adresse, während das erzeugte TAP-Interface irgendeine andere MAC-Adresse bekommt. Es sieht also so aus, als würde qemu neben dem TAP-Interface noch ein weiteres virtuelles Interface erzeugen und das dann auf tap0 weiterleiten. Die erzeugten DHCP-Discovery-Pakete kann ich zwar auf tap0 und auch auf dem Bridge-Device sehen (natürlich nicht mit bloßem Auge, sondern mit tcpdump ;), an das physikalische Netz-Interface wird der Kram aber leider nicht weitergeleitet, so dass das Ergebnis das gleiche wie bei meinen Trockenübungen ist :-(

Falls jemand irgendwelche erhellenden Einsichten beitragen kann, wäre ich sehr dankbar ...

[Cae]

DHCP ist ein Broadcastprotokoll, und da eine Bridge routet, wird der Broadcast fallengelassen. Die Lösung wäre eine Art Repeater, der auf dem tun auf Broadcasts lauscht und sie am anderen Bridgeende wieder in die Wildbahn entlässt - und umgekehrt.
Vielleicht kann man das der Brigde auch direkt sagen?

Gruß Cae

[gxyz]

da eine Bridge routet, wird der Broadcast fallengelassen

... eine Bridge hat mit Routing rein gar nichts zu tun - ihre Aufgabe ist, Ethernet (d.h.: Link-Layer) -Frames zwischen den beteiligten Ports weiterzuleiten, und zwar an _alle_, es sei denn, es ist bekannt hinter welchem Port eine bestimmte MAC-Adresse erreichbar ist.

Allerdings gibt es offensichtlich diverse subtile Unterschiede im Verhalten von Software-Bridges und virtuellen Netz-Interfaces und ihren physikalischen Pendants. Alle diesbezüglichen Merkwürdigkeiten konnte ich noch nicht ergründen (z.B. weshalb mein eigentlich als Minimal-Test gedachtes DHCP-Beispiel nicht funktioniert) aber immerhin klappt's jetzt in dem Szenario, das ich eigentlich brauche (virtuelle Maschinen mit dem physikalischen Netz verbinden). Wie sich letztlich herausgestellt hat, gibt es Wechselwirkungen, falls auch eine Netfilter-Firewall aktiv ist (wie auf meinen Maschinen normalerweise immer). Etwas unerwartet (immerhin spielt sich ja alles innerhalb der gleichen Maschine ab) laufen auch die virtuellen Bridges über die FORWARD-chain und wenn dort (was normalerweise das einzig sinnvolle ist) als Policy "DROP" eingestellt ist, braucht es explizite Regeln um die Bridge-Pakete durchzulassen.

Ich bin ja ziemlich verblüfft, das anscheinend außer mir niemand Firewalls benutzt - im großen weiten WWW gibt es Dutzende von Beispielen speziell in Bezug auf qemu, in denen im wesentlichen immer das gleiche steht - der Hinweis auf netfilter findet sich leider nirgends :-(

(Übrigens gibt es diese Wechselwirkung auch nur, wenn wie im Fall von quemu die Bridge explizit "von Hand" angelegt ist - bei Virtualbox oder Vmware laufen im Bridge-Modus die Pakete einer virtuellen Maschinen nicht über die Netfilter-Chains)