☰

So führen Sie einen DNSMASQ in QEMU aus und stellen einen Netboot-Dienst für andere VMs bereit

tag-icon • tag-icon linux-networking qemu dnsmasq
So führen Sie einen DNSMASQ in QEMU aus und stellen einen Netboot-Dienst für andere VMs bereit

EDIT: WIP: Der Hauptgrund für die unten erläuterten Fehler liegt darin, dass ich die Host-TAP-Schnittstellen nicht zum richtigen Zeitpunkt aufgerufen habe. Wenn ich QEMU die Erstellung der Tap-Geräte überlasse, funktioniert alles wie erwartet. Ich werde den Fehler genauer untersuchen und eine klarere Erklärung des Problems liefern, wenn ich sie habe. Danke @anx für die Tipps!

Ziel: Führen Sie dnsmasqinnerhalb eines Hosts eine QEMU-VM aus, die Netboots von einer anderen, auf dem Host laufenden QEMU-VM bedient.

Ich möchte, dass sich die dnsmasq-VM wie ein Gateway verhält, mit einer Netzwerkkarte als Upstream-WAN-Schnittstelle, mit einem Upstream-DHCP-Server und der anderen Schnittstelle als privater LAN-Schnittstelle, an die andere VMs „angeschlossen“ werden und die einen Netboot vom dnsmasq ausführen, der auf dieser privaten LAN-Schnittstelle lauscht.

Damit die VMs miteinander kommunizieren können, erstelle ich zunächst meine eigene Brücke auf dem Host.

ip link add name vivianbr0 type bridge
ip link set vivianbr0 up

Damit die VMs über die Host-Bridge miteinander kommunizieren können, benötige ich zwei Tap-Geräte, eines für die private LAN-Schnittstelle der Gateway-VM und ein weiteres für die einzelne Netzwerkschnittstelle der privaten VM.

ip tuntap add mode tap tap0 user cturner
ip tuntap add mode tap tap1 user cturner
ip link set tap0 up
ip link set tap1 up
ip link set tap0 master vivianbr0
ip link set tap1 master vivianbr0

Für die Gateway-VM verwende ich zu Testzwecken ein Arch Linux ISO. Die VM wird mit zwei Netzwerkkarten gebootet.

 qemu-system-x86_64 \
    -drive file=arch-disk.qcow2,if=none,id=nvm \
    -device nvme,serial=deadbeef,drive=nvm \
    -cdrom archlinux-2021.09.01-x86_64.iso \
    -boot d \
    -device virtio-net-pci,romfile=,netdev=net0,mac="DE:AD:BE:EF:00:11" \
    -device virtio-net-pci,romfile=,netdev=net1,mac="DE:AD:BE:EF:00:12" \
    `# Simulate the plugged in "upstream" cable with user-mode networking` \
    -netdev user,id=net0,hostfwd=tcp::60022-:22,hostfwd=tcp::8080-:80,hostfwd=tcp::8081-:8000,hostfwd=tcp::2375-:2375 \
    `# And now the unplugged one with, with TAP networks` \
    -netdev tap,id=net1,ifname=tap0,script=no,downscript=no \
-net bridge,br=vivianbr0 \
    -m 4G \
    -enable-kvm

Sobald diese Maschine gebootet ist, sehe ich Folgendes in der Bridge-Konfiguration,

brctl show vivianbr0 

bridge name     bridge id               STP enabled     interfaces
vivianbr0               8000.46954a1ad851       no              tap0
                            tap1
                            tap2

Ich nehme an, tap2es wurde von QEMU erstellt ...

Innerhalb dieser VM gibt es zwei ifaces. ens4mit MAC DE:AD:BE:EF:00:11 und ens5mit MAC DE:AD:BE:EF:00:12. Innerhalb dieser VM starte ich dnsmasq,

ip addr add 10.42.0.1/24 dev ens5
dnsmasq -d --dhcp-range=10.42.0.10,10.42.0.100 --dhcp-script=/bin/echo --enable-tftp=ens5 --interface=ens5

Dies startet ohne Fehler.

Jetzt versuche ich, eine andere VM per Netboot zu starten, die auf dem Host wie folgt gestartet wurde:

qemu-system-x86_64 \
-machine pc-q35-6.0,accel=kvm \
-m 1024 -smp 2,sockets=2,cores=1,threads=1 \
-netdev tap,id=net0,ifname=tap1,script=no,downscript=no \
-device virtio-net-pci,netdev=net0,bootindex=1,mac=DE:AD:BE:EF:00:13 \
-net bridge,br=vivianbr0 \
-enable-kvm \
-vga virtio

Aber es bootet nicht. Ich überwache die vivianbr0Nutzung tcpdumpund kann die DHCP-Anfragen sehen, aber es gibt keine Antworten, nichts erreicht den dnsmasq, der in der ersten VM läuft,

tcpdump -i vivianbr0 -nN
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vivianbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:21:39.585229 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:00:13, length 397
12:21:40.587741 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:00:13, length 397
12:21:40.700038 IP6 fe80::6ce2:2aff:fe94:ba48.5353 > ff02::fb.5353: 0 [7q] PTR (QM)? _nfs._tcp.local. PTR (QM)? _ftp._tcp.local. PTR (QM)? _webdav._tcp.local. PTR (QM)? _webdavs._tcp.local. PTR (QM)? _sftp-ssh._tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _afpovertcp._tcp.local. (118)
12:21:42.619968 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:00:13, length 397
12:21:46.684448 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:00:13, length 397
12:22:30.609555 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:00:12, length 289
12:23:33.796148 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:00:12, length 289
12:24:38.673364 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:00:12, length 289

Seltsamerweise sehe ich BOOTP-Anfragen von de:ad:be:ef:00:13(der MAC-Adresse der Netboot-VMs)und von de:ad:be:ef:00:12(die private Netzwerkkarte der Gateway-VM), was darauf hinweist, dass eine Konfiguration schwerwiegend ist.

Wie kann ich das zum Laufen bringen?

Antwort1

Ihre Schritte für zwei Gäste sind in Ordnung, ich habe gerade Ihr Setup repliziertbis zum Zeitpunkt des Adressen-Leasings. Ich könnte IPs von einer VM, auf der DNSMASQ läuft, an eine VM verteilen, auf der ein DHCP-Client läuft.

Überprüfen Sie Folgendes:

  • nicht verbundene Tap-Geräte können nicht aufgerufen werden
    • sichtbar am DOWNStatus in der ip a lAusgabe des Hosts (sollte UNKNOWNoder lauten UP)
      • Wenn Sie QEMU das Tap-Gerät erstellen lassen, qemu-bridge-helperwird es angezeigt
      • Wenn Sie ein Skript verwenden, rufen Sie das Gerät dort auf
      • andernfalls müssen Sie ip link set tapN upeinige Zeit nach dem Start der VM
  • MAC-Adressen müssen eindeutig sein
    • sichtbar in etherAdresse in ip a lin den Gästen
    • Liste gelernter (nicht-Host-)Macs, z. B. brctl showmacs br0solltezweiEinträge mit einem Alterungstimer ungleich Null
  • Pakete über iptables löschen
    • prüfen /proc/sys/net/bridge/bridge-nf-call*, ob br_netfilterdas Modul geladen ist
    • Fügen Sie eine Protokollierungsregel hinzu, für IPv4 etwa iptables -A FORWARD -j LOG --log-prefix "forward dropped"vor dem Löschen oder vor einer DROP-Richtlinie für die FORWARD-Tabelle
    • ignorieren /sys/class/net/br*/bridge/nf_call_*(ich weiß nicht, warum diesedürfenausgeschaltet sein, wenn die Filterung eingeschaltet ist)

Andere bemerkenswerte Dinge, die ich beim Testen gefunden habe:

  • Qemu hat die vnet_hdrOption auf meinen Tap-Geräten hinzugefügt. Das erscheint sinnvoll und hätte bei Bedarf über die Qemu-Befehlszeile deaktiviert werden können.
  • Manchmal ging meine (Scope-Link) Route für die Brücke verloren. Ich muss noch herausfinden, wie das überhaupt passieren konnte.

Zu Ihrem Versuch, das Testen durch die Bindung an das Tap-Gerät zu vereinfachen...

dnsmasq wird in einer QEMU-VM ausgeführt

Soweit ich weiß, sind Persistent-Tap-Geräte unbrauchbar, bis sie tatsächlich angeschlossen sind. Sie können also nur das vollständige Setup sinnvoll testen:

  • Möchten Sie dnsmasq auf dem Host ausführen?
    • Schließen Sie es dann an das Bridge-Gerät an.
  • oder möchten Sie dnsmasq in einer VM ausführen?
    • dann an die entsprechende Netzwerkschnittstelle anschließeninnendiese VM

--interface=tap0

Hinweis: Verwenden Sie --bind-interfacesdiese Option, um dnsmasq anzuweisen, nicht mehr nur den Datenverkehr von anderen Schnittstellen zu verwerfen, sondern tatsächlich eine Bindung herzustellen, und sich daher beim Start mit unbrauchbaren Einstellungen ausführlich zu beenden.

verwandte Informationen