EDIT: WIP: Motivul principal pentru eșecurile explicate mai jos se datorează faptului că nu am afișat interfețele TAP gazdă la momentul potrivit, dacă permit QEMU să se ocupe de crearea dispozitivelor de robinet, totul funcționează conform așteptărilor. Voi investiga eșecul mai detaliat și voi oferi o explicație mai clară a problemei când o voi avea. Mulțumesc @anx pentru sfaturi!
Scop: alerga a dnsmasq în interiorul unei mașini virtuale gazdă QEMU, care deservește boot-urile net
de la un alt QEMU VM care rulează pe gazdă.
Aș dori ca VM dnsmasq să acționeze ca un gateway, cu un singur NIC ca
interfață WAN în amonte, cu un server DHCP în amonte și cealaltă
interfață o interfață LAN privată, la care vor fi alte VM
„conectat”, și va porni net de la dnsmasq care ascultă pe acest privat
interfață LAN.
În primul rând, pentru a permite VM-urilor să vorbească între ele, îmi creez propria mea punte
pe gazda,
link ip adauga nume vivianbr0 tip pod
link-ul ip setați vivianbr0
Pentru ca VM-urile să vorbească între ele prin puntea gazdă, voi avea nevoie de două
atingeți dispozitivele, unul pentru interfața LAN privată de pe VM-ul gateway și
altul pentru interfața de rețea unică a VM-urilor private,
ip tuntap add mode tap tap0 user cturner
ip tuntap add mode tap tap1 utilizator cturner
link-ul ip setat tap0 up
legătură ip setată tap1 sus
set link ip tap0 master vivianbr0
set link ip tap1 master vivianbr0
Pentru VM-ul gateway, folosesc un ISO Arch Linux în scopuri de testare,
VM-ul este pornit cu două NIC-uri, astfel,
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" \
`# Simulați cablul „în amonte” conectat cu rețea în modul utilizator” \
-utilizator netdev,id=net0,hostfwd=tcp::60022-:22,hostfwd=tcp::8080-:80,hostfwd=tcp::8081-:8000,hostfwd=tcp::2375-:2375 \
`# Și acum cel deconectat cu, cu rețele TAP` \
-netdev tap,id=net1,ifname=tap0,script=nu,downscript=nu \
-net bridge,br=vivianbr0 \
-m 4G \
-activare-kvm
Odată ce această mașină a pornit, văd următoarele în configurația podului,
brctl show vivianbr0
numele podului ID pod Interfețe activate STP
vivianbr0 8000.46954a1ad851 nu tap0
atingeți 1
atingeți 2
presupun atingeți 2 a fost creat de QEMU...
În interiorul acestui VM, există două ifaces. ens4 cu MAC
DE:AD:BE:EF:00:11 și ens5 cu MAC DE:AD:BE:EF:00:12. Înăuntrul acestuia
VM, încep 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
Aceasta începe fără eroare.
Acum încerc să pornesc un alt VM, pornit pe gazdă astfel,
qemu-system-x86_64 \
-mașină pc-q35-6.0,accel=kvm \
-m 1024 -smp 2,sockets=2,cores=1,threads=1 \
-netdev tap,id=net0,ifname=tap1,script=nu,downscript=nu \
-device virtio-net-pci,netdev=net0,bootindex=1,mac=DE:AD:BE:EF:00:13 \
-net bridge,br=vivianbr0 \
-enable-kvm \
-vga virtio
Dar nu reușește să pornească. Monitorizez vivianbr0 folosind tcpdump și
poate vedea cererile DHCP, dar nu există răspunsuri, nimic nu ajunge la dnsmasq care rulează în primul VM,
tcpdump -i vivianbr0 -nN
tcpdump: ieșire verbosă suprimată, utilizați -v[v]... pentru decodarea completă a protocolului
ascultare pe vivianbr0, tip link EN10MB (Ethernet), lungime instantanee 262144 octeți
12:21:39.585229 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Solicitare de la de:ad:be:ef:00:13, lungime 397
12:21:40.587741 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Solicitare de la de:ad:be:ef:00:13, lungime 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, Solicitare de la de:ad:be:ef:00:13, lungime 397
12:21:46.684448 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Solicitare de la de:ad:be:ef:00:13, lungime 397
12:22:30.609555 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Solicitare de la de:ad:be:ef:00:12, lungime 289
12:23:33.796148 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Solicitare de la de:ad:be:ef:00:12, lungime 289
12:24:38.673364 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Solicitare de la de:ad:be:ef:00:12, lungime 289
În mod ciudat, văd solicitări BOOTP de la de:ad:be:ef:00:13 (adresa MAC a VM-urilor de pornire prin net) iar din de:ad:be:ef:00:12 (NIC-ul privat al VM-ului gateway), indicând că ceva este prost configurat.
Cum pot face asta să funcționeze?
