Я использую второй адаптер Ethernet для глобальной сети моей виртуальной установки OPNsense в KVM/QEMU.
Все работает хорошо, но я заметил, что сам KVM-хост тоже получает IP-адрес и для него установлены маршруты. Я хочу только, чтобы виртуальный интерфейс OPNsense имел IP, а не интерфейс хоста.
Интерфейс на KVM-хосте выглядит так:
enx3c18a0057e95: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 178.119.13.164 netmask 255.255.240.0 broadcast 178.119.15.255
inet6 fe80::3e18:a0ff:fe05:7e95 prefixlen 64 scopeid 0x20<link>
inet6 2a02:181f:0:6061:4016:4dfa:8cbc:23b3 prefixlen 128 scopeid 0x0<global>
ether 3c:18:a0:05:7e:95 txqueuelen 1000 (Ethernet)
RX packets 4255467 bytes 5047527392 (4.7 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2983482 bytes 829553375 (791.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
но в /etc/network/interfaces не настроен IP:
auto enx3c18a0057e95
iface enx3c18a0057e95 inet manual
Также не работает dhclient.
Как ни странно, все остальные vnet, macvtap и virbr также имеют адреса APIPA 169.254.X.X. (см. таблицу маршрутов ниже)
Еще немного деталей:
root@svr:~# for vm in $(virsh list | grep running | awk '{print $2}'); do echo "$vm: " && virsh dumpxml $vm | grep "vnet" ; done
debian-vpn:
<target dev='vnet0'/>
<target dev='vnet1'/>
OPNsense:
<target dev='vnet2'/>
<target dev='vnet3'/>
root@svr:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.26a83932e330 no eno1
vnet0
vnet2
virbr2 8000.525400315d13 yes vnet1
vnet3
root@svr:~# ps aux | grep dhc
nobody 1298 0.0 0.0 11572 2276 ? S 16:19 0:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/VPN.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
root@svr:~# ip route
default via 192.168.1.1 dev br0 onlink
10.18.197.4/30 dev tap1 proto kernel scope link src 10.18.197.5
169.254.0.0/16 dev eno1 proto kernel scope link src 169.254.185.141
169.254.0.0/16 dev eno1.134 proto kernel scope link src 169.254.62.148
169.254.0.0/16 dev vnet1 proto kernel scope link src 169.254.77.229
169.254.0.0/16 dev vnet0 proto kernel scope link src 169.254.133.164
169.254.0.0/16 dev macvtap0 proto kernel scope link src 169.254.122.85
169.254.0.0/16 dev macvtap1 proto kernel scope link src 169.254.222.208
169.254.0.0/16 dev vnet3 proto kernel scope link src 169.254.174.42
169.254.0.0/16 dev vnet2 proto kernel scope link src 169.254.219.41
169.254.0.0/16 dev tap1 proto kernel scope link src 169.254.149.40
178.119.0.0/20 dev enx3c18a0057e95 proto kernel scope link src 178.119.13.164
178.119.0.1 dev enx3c18a0057e95 scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.7
192.168.101.0/24 dev virbr2 proto kernel scope link src 192.168.101.1
195.130.130.5 via 178.119.0.1 dev enx3c18a0057e95
195.130.131.5 via 178.119.0.1 dev enx3c18a0057e95
последние записи в таблице маршрутизации - это DNS-сервер, который каким-то образом подхватился по DHCP.
Как запретить интерфейсам получать IP-адрес на хосте и иметь его только на виртуальной машине?
Благодарность
