Keine IP nach Umzug auf neuen host (Proxmox)

jrichter · 24. April 2021 um 01:25

Hallo Ersin,

kannst Du denn manuell eine ip konfigurieren? Z. B. so:

ip addr add 10.0.0.34/16 dev vmbr0

Wenn ja, dann mach das doch mal. Dann kannst Du die Weboberfläche aufrufen und dort mal die Netzkonfiguration checken.

Außerdem wäre noch der Output von „brctl show“ interessant.

Beste Grüße

Jörg

ersin · 24. April 2021 um 12:03

Hallo Jörg,

gute Idee, zu versuchen, der bridge eine weitere IP hinzuzufügen.
Werde ich gleich bei nächster Gelegenheit (am Mo) probieren.

Meine Überlegungen vor dem Umzug:
(das schreibe ich hier auf, weil mir dabei Vieles klarer wird und zum Nachlesen für später)

Im neuen Host stecken ja i.d.R andere NICs als im alten, d.h. deren Namen sind womöglich andere (je nachdem, ob onboard, PCI-slot u.a. Kriterien). Im vorliegenden Fall:

Host	NIC#1	#2	Kommentar
alt	enp1s0	enp2s0	1x-onboard + 1xNIC
neu	eno1	enp1s0f0 - enp1s0f3	1x-onboard + 4xNIC

Daher müssen im neuen Host die Zuordnungen der bridges den neuen Namen angepasst werden, weshalb in /etc/network/interfaces im altem & neuen Host (nach Vergewisserung, u.a. durch Raus- und Reinstecken der Kabel) die bridges wie folgt zugeordnet sind:

Host	bridge	NIC	IP	Kommentar
alt	vmbr0	enp1s0	10.0.0.20	grünes Netz
alt	vmbr1	enp2s0	DHCP	rotes Netz
neu	vmbr0	enp1s0f0	ohne IP	grünes Netz (sollte 10.0.0.34 sein)
neu	vmbr1	enp1s0f1	DHCP	rotes Netz

Trotzdem bleibt die „grüne” bridge ohne IP.

Daher denke ich, dass der Fehler irgendwo „ganz woanders“ liegt und bin gespannt auf deine Idee…

VG, ersin

Michael · 24. April 2021 um 12:35

Moment mal … wird die Schreibweise mit der /16 so auch akzeptiert?
Ich habe die Netzmaske in einer Extra-Zeile:

address 192.168.1.10
netmask 255.255.255.0
...

Bist du sicher, dass beides geht?
Was ist denn, wenn du die Schnittstelle zum Testen mal auf DHCP stellst und schaust, ob sie dann eine Adresse bekommt?
Ist die MAC überhaupt in der devices.csv eingetragen? Das müsste sie imho sein, damit der Rechner ins Internet darf…

Mehr fällt mir gerade nicht ein.
Viele Grüße,
Michael

alois · 24. April 2021 um 12:44

Hallo Michael,

das ist aber nicht /16, sondern /24

Gruß

Alois

ersin · 24. April 2021 um 13:04

Hallo Michael,

Bist du sicher, dass beides geht?

Bei Debian wird zwar oft explizit netmask angegeben, aber so ab Debian 8 (und Ubuntu sowieso) geht wohl beides. Hier weitere Beispiele.

VG, ersin

Cgsman · 25. April 2021 um 09:28

Hallo, Ihr beiden,

ja, beides geht.

Gruß Christoph

Michael · 25. April 2021 um 10:16

Ja, wir haben Subnetze und VLANs. Da sind /24er Netze richtig…
Aber in diesem Fall gehen mir nun auch die Ideen aus

Cgsman · 25. April 2021 um 11:47

Hallo,
also ich hab mir das oben genannte Schema nochmal angesehen: Das Besondere ist, dass durch die gateway-Anweisung, die nicht, wie sonst häufig, auf die externe Router-IP zeigt, sondern intern auf den OpnSense, es jetzt wirklich davon abhängig ist, ob der OpnSense die Anfragen auf die proxmox-Gui auch „durchlassen“ muss…hm…wahrscheinlich ist dann - ich habe mir die OpnSense-Konfigurationen nicht angesehen - dort eine Regel nicht aktiviert, die es braucht, um auf die Proxmox-Gui zu kommen.
„Verbiegen“ darf man das aber jetzt nicht mehr, weil sich sonst die vms nicht gegenseitig finden etc.
Tatsächlich kann man den Proxmox an ein zusätzliches reales Netzinterface binden, aber die Frage ist, wie man das Teil fernwarten möchte. (Meine Proxmox-Gui hängt in einem roten Netz).
Ansonsten empfiehlt es sich evtl. wirklich, die Opnsense-Konfiguration zu überprüfen !
L.G.
Christoph

Michael · 26. April 2021 um 05:55

Hallo Christoph – das verstehe ich nicht; bzw sehe ich es genau umgekehrt : Wenn du bei der OPNSense aus dem LAN kommst, kannst du in der Regel auch auf das OPNSense-WebUI (und auf das eigene Proxmox-WebUI dann sowieso!) zugreifen, während es bei Zugriff aus dem WAN per default aus gutem Grund verhindert wird.
Hier geht es ja --so wie ich es bisher verstanden habe-- gar nicht um einen Proxmox-Zugriff von außen sondern um das Problem, dass der Proxmox-Hypervisor aus irgendeinem Grund keine IP-Adresse auf vmbr0 hat??!

Vielleicht hilft es ja noch, sich den Status mit
brctl show anzusehen.

Ansonsten hier nochmal die offizielle Doku – auch dort wird die Netzmaske explizit angegeben. Vielleicht will Proxmox ja doch diese Syntax??
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_network_configuration

Ansonsten noch: Warum gibst du dem neuen Server nicht auch die .20 als IP-Adresse? Wenn es damit geht, weißt du, dass die OPNSense etwas blockiert…

Viele Grüße,
Michael

jrichter · 26. April 2021 um 06:45

Hallo,

solange der Proxmox keine IP hat, ist es völlig egal, ob die OPNSense irgendwas blockt. Das erste Problem ist die IP für vmbr0, alles andere kommt später.

Zum Debuggen gibt es nun schon mehrere Vorschläge:

die andere Syntax ausprobieren
eine IP-Adresse manuell vergeben - vielleicht gibt es ja irgendein Problem mit der Karte, was man so ausschließen könnte
die Einstellungen im Webinterface kontrollieren, vielleicht findet sich ja dort was

Wenn der Host für die vmbr0 eine IP hat, dann kann man weitere Tests anstellen (kommt man ins Internet, auf die OPNSense, …).

Beste Grüße

Jörg

Cgsman · 26. April 2021 um 08:25

stimmt, Jörg - das hab ich bei dem ganzen Hin und Her übersehen !

ersin · 26. April 2021 um 15:36

Hallo Jörg,

deine Idee, der bridge händisch eine weitere IP (in diesem Fall überhaupt erst eine) hinzuzufügen, hat mich ein gutes Stück weitergebracht:

Der einzige Zugang war bislang die Konsole direkt am Rechner. Nun gehts auch wieder via ssh und vor allem erreiche ich das WebIF und kann Einstellungen überprüfen.

Hier ein paar outputs, vllt. sieht ja jemand was Auffälliges oder Ungewöhnliches.

root@hv01:~# brctl show (der Lesbarkeit halber tabelliert)

bridge name	bridge id	STP enabled	interfaces
fwbr100i0	8000.5aaeedd25be0	no	fwln100i0
-	-	-	tap100i0
fwbr100i1	8000.427dc3436f23	no	fwln100i1
-	-	-	tap100i1
fwbr101i0	8000.7e6b83e950ac	no	fwln101i0
-	-	-	tap101i0
vmbr0	8000.b49691749214	no	enp1s0f0
-	-	-	fwpr100p0
-	-	-	fwpr101p0
vmbr1	8000.b49691749215	no	enp1s0f1
-	-	-	fwpr100p1

root@hv01:~# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether b4:96:91:74:92:14 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 2c:f0:5d:c7:f4:8c brd ff:ff:ff:ff:ff:ff
4: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
link/ether b4:96:91:74:92:15 brd ff:ff:ff:ff:ff:ff
5: enp1s0f2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether b4:96:91:74:92:16 brd ff:ff:ff:ff:ff:ff
6: enp1s0f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether b4:96:91:74:92:17 brd ff:ff:ff:ff:ff:ff
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b4:96:91:74:92:14 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.34/16 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::b696:91ff:fe74:9214/64 scope link
valid_lft forever preferred_lft forever
8: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b4:96:91:74:92:15 brd ff:ff:ff:ff:ff:ff
inet6 fe80::b696:91ff:fe74:9215/64 scope link
valid_lft forever preferred_lft forever
9: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i0 state UNKNOWN group default qlen 1000
link/ether 2e:af:78:f6:90:3f brd ff:ff:ff:ff:ff:ff
10: fwbr100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 5a:ae:ed:d2:5b:e0 brd ff:ff:ff:ff:ff:ff
11: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether 6e:e6:04:9c:02:79 brd ff:ff:ff:ff:ff:ff
12: fwln100i0@fwpr100p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i0 state UP group default qlen 1000
link/ether 5a:ae:ed:d2:5b:e0 brd ff:ff:ff:ff:ff:ff
13: tap100i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i1 state UNKNOWN group default qlen 1000
link/ether e6:76:9f:a2:98:9c brd ff:ff:ff:ff:ff:ff
14: fwbr100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 42:7d:c3:43:6f:23 brd ff:ff:ff:ff:ff:ff
15: fwpr100p1@fwln100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1 state UP group default qlen 1000
link/ether f6:7d:b8:28:17:5e brd ff:ff:ff:ff:ff:ff
16: fwln100i1@fwpr100p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i1 state UP group default qlen 1000
link/ether 42:7d:c3:43:6f:23 brd ff:ff:ff:ff:ff:ff
17: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr101i0 state UNKNOWN group default qlen 1000
link/ether 6e:6d:fa:d1:40:9b brd ff:ff:ff:ff:ff:ff
18: fwbr101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 7e:6b:83:e9:50:ac brd ff:ff:ff:ff:ff:ff
19: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether fe:a4:b8:92:97:c6 brd ff:ff:ff:ff:ff:ff
20: fwln101i0@fwpr101p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr101i0 state UP group default qlen 1000
link/ether 7e:6b:83:e9:50:ac brd ff:ff:ff:ff:ff:ff
root@hv01:~#

root@hv01:~# ip a | grep vmbr

2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
4: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.0.0.34/16 scope global vmbr0
8: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
11: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
15: fwpr100p1@fwln100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1 state UP group default qlen 1000
19: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
root@hv01:~#

Und hier ein screenshot von Node hv01-Network:

So weit so gut.

Das ursprüngliche Problem jedoch bleibt:

Die Zuweisung der IP innerhalb /etc/network/interfaces scheitert nach wie vor (aus mir immer noch unbekannten Gründen).

Aufgefallen ist mir die Spalte Autostart (No), weshalb ich probeweise Einträge wie auto enp1s0f0 oder allow-hotplug enp1s0f0 (entspricht Autostart unter ProxMox-WebIF) versucht habe: ohne Erfolg (wobei im alten server pve alles auch ohne diese Parameter funktioniert)

Mit der Hilfslösung „händisch IP zuweisen“ könnte man zur Not übergangsweise leben, aber da ist immer noch Problem #2:

Der host hat zwar eine Verbindung zur Firewall, kommt aber nicht raus ins Internet (alle anderen clients hingegen sehr wohl, wie etwa das admin-notebook, auf dem ich diesen Beitrag gerade schreibe) Und Ja, er ist korrekt (mit IP ~.34) in Firewall/Aliase eingetragen.

root@hv01:~# ping -c2 10.0.0.254
PING 10.0.0.254 (10.0.0.254) 56(84) bytes of data.
64 bytes from 10.0.0.254: icmp_seq=1 ttl=64 time=0.198 ms
64 bytes from 10.0.0.254: icmp_seq=2 ttl=64 time=0.197 ms
root@hv01:~# ping -c2 heise.de
connect: Network is unreachable
root@hv01:~# ping -c2 193.99.144.80
connect: Network is unreachable

Hab mal ein paar config-Dateien angeguckt:

root@hv01:~# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
10.0.0.34 hv01.linuxmuster.lan hv01
root@hv01:~# cat /etc/resolv.conf
search linuxmuster.lan
nameserver 10.0.0.254

Zum Vergleich der alte host pve (wo alles funktioniert)

root@pve:~# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
10.0.0.20 pve.pss.example pve
root@pve:~# cat /etc/resolv.conf
search pss.example
nameserver 10.0.0.254

Sieht alles OK aus, bis auf den den Unterschied zum alten host pve: der neue host hv01 hat die domain linuxmuster.lan.

Der alte host pve hingegen erreicht heise.de wie erwartet über fw und modem:

root@pve:~# traceroute heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 60 byte packets
1 firewall.linuxmuster.lan (10.0.0.254) 0.292 ms 0.272 ms 0.259 ms
2 192.168.1.1 (192.168.1.1) 0.746 ms 0.805 ms 1.461 ms
3 62.155.246.204 (62.155.246.204) 22.393 ms 22.908 ms 23.842 ms
4 217.5.109.10 (217.5.109.10) 27.839 ms 28.328 ms 29.087 ms
5 62.159.61.15 (62.159.61.15) 32.331 ms 32.852 ms 32.852 ms
6 82.98.102.19 (82.98.102.19) 32.286 ms 31.857 ms 32.217 ms
7 82.98.102.23 (82.98.102.23) 32.901 ms 32.965 ms 34.063 ms
8 * * *
9 * * *
10 * * *
11 212.19.61.13 (212.19.61.13) 24.967 ms !X * *
root@pve:~#

Soviel Input für jetzt.

VG, ersin

Cgsman · 26. April 2021 um 15:52

Hallo, ersin,

in der Tat sehe ich etwas: Bei der CIDR sollte tatsächlich eine Netzmaske stehen…also eben die bekannte CIDR-Notation mit slash und Bitanzahl für die gesetzten Bits (10.0.0.34/16)…
Wir hatten ja schon darüber gesprochen, ob die netmask…- Angabe ok ist - für Debian sicherlich, aber evtl. nicht für die Proxmox-Funktionalität ? (Ein Schuss ins Blaue, ich weiß ! Aber die CIDR stimmt definitiv so nicht !). Steht denn hintendran der Gateway ? (Muss !)

Gruß Christoph

Cgsman · 26. April 2021 um 16:10

Hallo, ersin,

habe eben mal - ich wohne nur 3 km von meiner Schule weg und wollte ohnehin nochmal mit dem Fahrrad … - bei mir die CIDR-Notation durch netmask (wie bei Dir) ersetzt … Netzwerk neu gestartet -damit habe ich meinen Proxmox abgeschossen und komme auch nicht mehr drauf (der hängt bei mir halt im roten Netz) …

Spricht also vieles dafür, die Netzmaske als /„xy“ anzugeben !
Evtl. würde ich sogar mal den nachfolgenden Kommentar weglassen…
Gruß Christoph

ersin · 26. April 2021 um 16:15

Hallo Cgsman,

Volltreffer! Das wars.
Nach der Korrektur geht wieder alles - wie beim alten host.

Witzigerweise übernimmt das WebIF von Proxmox an der Stelle sogar den Kommentar:

Tausend Dank - euch allen übrigens.
Wenn man so ganz alleine vor sich hin grübelt, sieht man manchmal vor lauter Bäumen den Wald nicht mehr.

Update: Ich versuche mal „forensisch“ zu rekonstruieren, wie der Fehler zustande kam: Vermutlich habe ich nach dem qm restore des Backups das WebIF aufgerufen, um a) zu gucken, ob es geht und b) bei der Gelegenheit gleich die IP des alten hosts (~.20/16) auf den neuen Wert (~.34/16) zu setzen und prompt das /16 vergessen (was mir in /etc/network/interfaces eher nicht passiert wäre) und so den Zugang zerschossen.

BG, ersin

Cgsman · 26. April 2021 um 17:31

Nachtrag:

Nachdem ich eben die Proxmox-Kiste direkt wieder aktiviert habe, hat mich interessiert, was eigentlich der Grund für das Fehlverhalten sein könnte - und ob man eine Art „Diagnosetool“ dafür gehabt hätte. (Ich finde das Verhalten des Proxmox übrigens ziemlich tückisch, denn wer ahnt schon, dass die erlaubte Debian-Schreibweise hier bei Proxmox nicht funktioniert ?)

Also: Ein
systemctl restart networking

bringt die Fehlermeldung gleich: Der „proxmox ifup“ meldet, dass er keinen „dev“-Parameter übergeben bekam (vermutl. ein script-Problem).

L.G. Christoph

Michael · 26. April 2021 um 18:14

Ich meine, dass du EINEN Kommentar pro Device angeben kannst – und der muss ganz am Ende stehen und durch ein <Enter> abgesetzt sein!
Ich wollte auch schon mal eine zweite Zeile Kommentar einfügen – das ist aber schief gegangen. Eigentlich ist es aber ja auch nicht so gedacht, dass man händisch in der /etc/network/interfaces herumfummelt — das sollte man eigentlich über das WebUI machen und da kann man den Kommentar so gar nicht eingeben…

Übrigens bin ich nun in Sachen „Eingabe der Netzmaske per CIDR-Notation“ auch stutzig geworden … ich habe bei mir definitiv die andere Syntax in der interfaces stehen:

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.10
        netmask 255.255.255.0
        gateway 192.168.1.1
        bridge_ports eno3
        bridge_stp off

Das wird vom WebUI aber passend umgesetzt und sieht dort automatisch so aus: Screenshot_20210426_202255
Es passt hier also!

Und da sieht man übrigens auch nochmal, dass es nur EIN Kommentarfeld gibt – und nicht in jeder Zeile eins…

jrichter · 27. April 2021 um 01:30

Hallo Ersin,

das war ja ein gemeines Problem! Da hat sich bei Proxmox offenbar was geändert, auch bei mir steht noch „netmask“ drin - und ich habe die Datei nie angefasst. Ist aber nicht die aktuelle Proxmox-Version.

Nur der Vollständigkeit halber: Dass du mit der manuell vergebenen IP nicht ins Internet kamst, lag mindestens am fehlenden Gateway (ip route add default via 10.0.0.254 dev vmbr0). Und dann muss bei der OPNSense die IP ohne Zwangsproxy konfiguriert sein.

Beste Grüße

Jörg

maxEG · 27. April 2021 um 07:52

Hallo
kleine Anmerkung dazu:
Bei mir haben Kommentare am Ende einer Zeile in der interfaces dazu geführt, dass nix mehr ging. Ich würde das prinzipiell nicht machen, lieber in die nächste Zeile LG
Max

ersin · 28. April 2021 um 16:08

Hallo Jörg,

Ja, in der Tat. Christoph alias Cgsman hat in einem Beitrag weiter oben das Verhalten von Proxmox etwas drastisch (aber nicht ganz zu unrecht) als „ziemlich tückisch“ bezeichnet.

An dieser Stelle nur eine tldr-Fassung (vllt. später mehr).

Das WebIF von Proxmox erlaubt (oder erfordert?) eine IP-Eingabe in CIDR-Notation, dies aber anscheinend ohne Überprüfung (der Plausibilität).
Eine fehlerhafte bzw. unvollständige Eingabe führt dazu, dass der host u.U. keine IP erhält und somit das WebIF nicht mehr erreichbar ist.

Bei der Fehlersuche kommen nun folgende Punkte erschwerend hinzu

der Begrüßungstext am Monitor (greeter unter /etc/issue) nach dem Start zeigt stets die IP, die bei der Installation von Proxmox eingegeben wurde, als jene an, unter der das WebIF zu erreichen sei. Auch nach einer nachträglichen Änderung der IP, oder wenn aufgrund einer fehlerhaften Eingabe im WebIF überhaupt keine IP zugewiesen ist, wird immer und stets diese Initial-IP angezeigt. Was in so einem Fall irreführend ist.
die Datei /etc/network/interfaces mit expliziter Angabe von Netmask wird, obwohl syntaktisch korrekt, nicht (oder nicht korrekt) eingelesen. Infolgedessen scheitert auf diesem Wege eine Korrektur. Diese Macke kostete mich die meiste Zeit bei der Fehlersuche (zig Neustarts nach zig Änderungen an interfaces.)
Proxmox basiert noch auf ifupdown, d.h. Änderungen am Netzwerk erfordern einen Neustart. Fehlersuche bei einem Netzwerkproblem erfordert unnötig viel Zeit. Von daher empfiehlt es sich, gleich ifupdown2 zu installieren, was Änderungen am Netzwerk ohne Neustart erlaubt. So kann man Ideen und Korrekturversuche schneller durchführen.

Weitergeholfen hat letztlich der Tipp von von Jörg, der bridge händisch eine IP zuzuweisen. So war wenigstens das WebIF wieder erreichbar und ich konnte dort die Konfiguration überprüfen, woraufhin der Fehler auch Dank den Argusaugen von Christoph alias Cgsman schnell gefunden wurde.
Um darüber hinaus auch ins Internet zu kommen, etwa um updates oder packages einzuspielen, ist natürlich noch ein Gateway erforderlich, worauf ebenfalls Jörg hingewiesen hat..

Werde ggf. später mehr darüber schreiben, welche Syntax von /etc/network/interfaces für Proxmox OK ist und welche scheitert (das scheint etwas buggy).

VG, ersin