[SOLVED] VM in zweitem Subnetz

[Chris-E]

Liebes Forum,

ich hänge an der Netzwerkkonfiguration von Proxmox VE und möchte um Eure Hilfe bitten:

Mein Intel NUC hängt momentan kabelgebunden im 192.168.1.0/24 Subnetz und ist für die VMs mittels Bridge vmbr0 konfiguriert. Die VMs sind mit statischen IPs in diesem Netzwerk 192.168.1.0/24 konfiguriert, also z.B. 192.168.1.12/24.

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.11
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1
        bridge_ports eno1
        bridge_stp off
        bridge_fd 0

Bis hierher funktioniert alles soweit.

Nun zu meiner Frage: Ich möchte einige der VMs in ein anderes Subnetz hängen, welches für IoT/Heimautomatisierung reserviert ist, nämlich 192.168.2.0/24. Konkret möchte ich meinen älteren Raspberry Pi mit HomeAssistant ersetzen durch einen Docker-Container/IOTStack, welcher in einer VM auf dem NUC läuft und eine IP-Adresse im 192.168.2.0-er Subnetz erhalten soll, also z.B. 192.168.2.12/24.

Ich habe nun versucht, den NUC zusätzlich zum kabelgebundenen Ethernet via WIFI ins 192.168.2.0-er Subnetz zu verbinden und eine weitere Bridge vmbr1 für dieses Netzwerk zu konfigurieren.

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback
iface eno1 inet manual
iface wlxfcf528fa41be inet manual
        wpa-ssid xxx
        wpa-psk xxx

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.11
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1
        bridge_ports eno1
        bridge_stp off
        bridge_fd 0

auto vmbr1
iface vmbr1 inet static
        address 192.168.2.11
        netmask 255.255.255.0
        gateway 192.168.2.1
        dns-nameservers 192.168.1.1
        bridge_ports wlxfcf528fa41be
        bridge_stp off
        bridge_fd 0

Leider scheitert dies mit

● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2020-10-04 13:30:43 CEST; 2s ago
     Docs: man:interfaces(5)
  Process: 31638 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
 Main PID: 31638 (code=exited, status=1/FAILURE)

Oct 04 13:30:43 CJEsNUC systemd[1]: Starting Raise network interfaces...
Oct 04 13:30:43 CJEsNUC ifup[31638]: can't add wlxfcf528fa41be to bridge vmbr1: Operation not supported
Oct 04 13:30:43 CJEsNUC ifup[31638]: Waiting for vmbr1 to get ready (MAXWAIT is 2 seconds).
Oct 04 13:30:43 CJEsNUC ifup[31638]: RTNETLINK answers: File exists
Oct 04 13:30:43 CJEsNUC ifup[31638]: ifup: failed to bring up vmbr1
Oct 04 13:30:43 CJEsNUC systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Oct 04 13:30:43 CJEsNUC systemd[1]: networking.service: Failed with result 'exit-code'.
Oct 04 13:30:43 CJEsNUC systemd[1]: Failed to start Raise network interfaces.

Liegt das am fehlenden monitor-mode des WIFI-Interfaces? Allerdings krieg ich das auch nach einem sudo iw wlan0 set monitor none nicht hin.

Was ist in einer solchen Situation best practice? USB-Ethernet-Adapter für das zweite Netzwerk? Falls ja, dann mit obiger Konfiguration?

Danke für Eure Hilfe, viele Grüße,
Christoph

 

[Stefan_R]

I.d.R. ist es immer eine schlechte Idee WiFi für solche "Server"-Tasks zu verwenden. Falls das nicht umgänglich ist, unter Umständen einmal hier schauen: https://wiki.archlinux.org/index.php/Network_bridge#Wireless_interface_on_a_bridge . WiFi-Adapter machen öfter Probleme, deshalb empfehlen wir immer Kabel...

Die Frage ist ja grundsätzlich weshalb überhaupt ein zweites Kabel verwendet werden soll. Es ist ja durchaus möglich mehrere Subnetze über ein physisches Netzwerk zu legen, am besten dann noch mit VLANs oder dergleichen und einem Router falls Kommunikation zwischen den Netzen möglich sein soll.

 

[Chris-E]

Vielen Dank, kabelgebunden funktioniert es jetzt...

Noch ein Hinweis, ich musste natürlich noch das GW bei der zweiten Bridge löschen, so dass sich folgende Routen ergeben:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 vmbr0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 vmbr0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 vmbr1