Keine IP nach Umzug auf neuen host (Proxmox)

Hallo zusammen,

irgendwie haben derzeit die Stolperfallen-Kobolde an mir ihren Spaß:
Nach dem Umzug laufen nun beide VMs auf dem neuen host:

  • Auf den Windows clients kann man sich wie gehabt anmelden, kommt ins Internet.
  • Komme auf das WebIF von der Firewall (OPNSense) und LMN-Server

So weit so gut.

Nach dem Starten des neuen Proxmox-servers kommt auch die übliche Meldung auf dem Monitor:

 ---
Welcome to the Proxmox Virtual Environment. Please use your web browser to
configure this server - connect to
  https://10.0.0.34:8006/
 ---

Anmerkung zur IP: Bei der Einrichtung von Proxmox auf dem neuen host hatte ich die IP 10.0.0.34 eingegeben, um sie nicht mit der IP 10.0.0.20 des alten hosts zu verwechseln.

Nur komme ich aber leider nicht auf das WebIF (Proxmox) des neuen hosts.
Überhaupt scheint der host keine IP zu haben.

ip a | grep vm

liefert zwar die Info, dass enp1s0f0, enp1s0f1 und die daran gebundenen bridges vmbr0 und vmbr1 UP sind, aber keine IP aufweisen. Ein ping, etwa auf die fw, zeigt

root@hv01:~# ping -c2 10.0.0.254
connect: network is unreachable

Mein Verdacht: auf dem alten host hatten die nics andere Bezeichnungen: eno1 und enp_irgendwas.
Auf dem neuen host (mit intel 4x-nic) heißen die natürlich anders (s.o). Liegt da etwa der Fehler? Wenn ja, wie kriege ich das korrigiert (auf die WebIF komme ich ja nicht ran)

Seltsam, seltsam, das alles, hat jemand ne Idee?

grüße, ersin

Update: hier ein Auszug aus /etc/network/interfaces

auto vmbr0
iface vmbr0 inet static
address 10.0.0.34 # green IP of vm host
netmask 255.255.0.0
gateway 10.0.0.254 # green IP of fw (OPNsense)
bridge-ports enp1s0f0
bridge-stp off
bridge-fd 0

auto vmbr1
iface vmbr1 inet manual
bridge-ports enp1s0f1
bridge-stp off
bridge-fd 0

Was mich (auch) irritiert: habe vmbr0 (intern, grün) und ~1 (extern, rot) nach Installationsanleitung konfiguriert. Im thread zum Thema LML7-4dummies… ist das genau anders rum.

Hallo, ersin,

ich kann nichts über die LM 7 sagen, habe mein Proxmox händisch für die LM 6.2 konfiguriert.
Du kannst mit ip a nachprüfen, wie Deine Netzwerkkarten heißen. Damit kannst Du ggf. die bridge-ports-Anweisungen korrigieren. Wenn Du Dir nicht sicher bist, ob Du von außen an die richtige Netzwerkkarte herangehst, um ins webinterface zu kommen (bei mir hängt da übrigens direkt das Router-Kabel dran, daher habe ich da eine class-C-Adresse für den Router), dann kurz mal das Router-Netzwerkkabel abziehen und wieder dranstecken, dmesg ausführen, die entsprechende Netzwerkkarte wird genannt.

L.G.
Christoph

Hallo ersin.
Über diese Meldung darfst du Dich bei Serverumzügen nicht wundern – bzw darfst du der angegeben IP unter Umständen auch nicht mehr glauben. Das wird bei der Installation so als greeter anelegt und bei einem Wechsel der IP nicht geändert! Darüber bin ich auch schon mal gestolpert.
Schau einfach mal unter /etc/issue – da steht das und Du kannst es auf die neue Adresse anpassen.

Viele Grüße,
Michael

Hallo Christoph und Michael,

> Du kannst mit ip a nachprüfen, wie Deine Netzwerkkarten heißen.
Das ist ja das Merkwürdige. Wie eingangs erwähnt, zeigt ip -a | grep vm zwar die (genannten) Netzwerkkarten und Bridges an – aber keine zugehörige IP. Ganz so, als ob sie keine hätten.

Werde morgen mal euren Hinweisen mit dmesg und etc/issue nachgehen.

Hi!
Hängt hinter den NICs auch was dran? mit dmesg kannst Du schauen, was bisher passiert ist. Steckt man ein Netzwerkkabel ab oder an, kommt da, welche NIC den link neu hat. So kannst Du rausfinden, welche physikalsiche Karte welchen Namen hat. Ggf. musst Du dann bei „bridged-ports“ den Namen anpassen.
Ansonsten nimm auch mal das ganze Netzwerk weg und hänge nur einen einzigen client an die Grüne Gegenstelle, nur zur Sicherheit.
LG
Max

Kann es sein, dass Du davon ausgehst, dass Du (unnötigerweise) den ip a - Ausdruck filtern musst ?
Also: Lass doch mal das „grep“ weg und überprüfe alleine mit ip a (vor allem die Namen der Netzwerkkarten: Wenn Du dann weißt, wie Deine Netzwerkkarten heißen, kannst Du die bridge-ports-Anweisungen korrigieren - darum geht es vermutlich im Kern).
L.G.

Es ist zum Mäusemelken:
nachdem ich beide Netzwerkkabel (grünes & rotes Netz) unter Beobachtung von dmesg -w raus- & reingesteckt und nochmals mit ip -a kontrolliert habe*, sind die NICs wie folgt benannt:

enp1s0f0 und enp1s0f1

Die Zuordnung der bridges vmbr0 und vmbr1 in /etc/network/interfaces (s.o.) ist demnach richtig.
Nun frage ich mich, warum beim Hochfahren der bridge vmbr0 keine IP zugeordnet wird.

Hier der output von dmesg | grep vmbr

[ 4.088700] vmbr0: port 1(enp1s0f0) entered blocking state
[ 4.088701] vmbr0: port 1(enp1s0f0) entered disabled state
[ 4.265117] vmbr1: port 1(enp1s0f1) entered blocking state
[ 4.265118] vmbr1: port 1(enp1s0f1) entered disabled state
[ 7.462872] vmbr1: port 1(enp1s0f1) entered blocking state
[ 7.462873] vmbr1: port 1(enp1s0f1) entered forwarding state
[ 7.464515] IPv6: ADDRCONF(NETDEV_CHANGE): vmbr1: link becomes ready
[ 7.720805] vmbr0: port 1(enp1s0f0) entered blocking state
[ 7.720806] vmbr0: port 1(enp1s0f0) entered forwarding state
[ 7.722481] IPv6: ADDRCONF(NETDEV_CHANGE): vmbr0: link becomes ready
[ 8.115763] vmbr0: port 2(fwpr100p0) entered blocking state
[ 8.115764] vmbr0: port 2(fwpr100p0) entered disabled state
[ 8.115826] vmbr0: port 2(fwpr100p0) entered blocking state
[ 8.115827] vmbr0: port 2(fwpr100p0) entered forwarding state
[ 8.452513] vmbr1: port 2(fwpr100p1) entered blocking state
[ 8.452514] vmbr1: port 2(fwpr100p1) entered disabled state
[ 8.452561] vmbr1: port 2(fwpr100p1) entered blocking state
[ 8.452562] vmbr1: port 2(fwpr100p1) entered forwarding state
[ 12.103705] vmbr0: port 3(fwpr101p0) entered blocking state
[ 12.103705] vmbr0: port 3(fwpr101p0) entered disabled state
[ 12.103748] vmbr0: port 3(fwpr101p0) entered blocking state
[ 12.103749] vmbr0: port 3(fwpr101p0) entered forwarding state

Vollständige Ausgabe von dmesg ist mit ~70KB ist zu groß für einen Beitrag, erlaubt sind 32KB)
(apropos, wie kriege ich längere Texte in eine scrollbare Box?)

Was mir auffällt, sind die Zeilen mit entered disabled state jeweils vor entered forwarding state
Irgendwas läuft da falsch, ich sehe leider (noch) nicht die Ursache.
Bin kurz davor, erneut einen qm restore mit der VM aus dem Backup zu starten.
Was meint Ihr?
__
*mit und ohne Filter | grep vm, den ich eingangs nur der Übersichtlichkeit halber angehängt hatte.

Die Frage ist ja: laufen denn in beiden Netzen ganz sicher DHCP Server, die erreichbar sind?

zu meinem Verständnis zu DHCP: in /etc/network/interfaces wird der bridge vmbr0 ja manuell eine IP zugeordnet, die vmbr1 hingegen erhält (manuell) keine IP (wohl aber erhält die 2. virtuelle NIC der fw eine externe IP via DHCP des Modems (das webIF der Fritzbox zeigt das Gerät „firewall“ unter 192.168.1.34).

Das Merkwürdige ist ja, dass die Windows-clients alle ins Internet kommen und (natürlich) sowohl server (10.0.0.1) als auch fw (~254) anpingen können, aber nicht den vm host.
Der wiederum meldet stur network is unreachable (klar, weil er keine IP hat).

Ich schreibe diesen Beitrag von dem admin-notebook aus im grünen Netz, von dem ich normalerweise das vpe webIF aufrufe (auf die jeweiligen webIFs, Dashboard von OPNSense und Schulkonsole, komme ich).

Zeichne deinen Aufbau mal auf… Ich kann nicht mehr folgen

der Aufbau entspricht der Skizze aus der Anleitung oberhalb Virtuelle Maschinen starten, wobei

Skizze		bei mir		Bemerkung
vmbr0-eno1	-enp1s0f0
vmbr1-eno2	-enp1s0f1
10.0.0.1	10.0.0.1	VM: linuxmuster.net server (kommt ins Internet)
10.0.0.10	10.0.0.10	Admin-PC/Notebook (kommt ins Internet)
10.0.0.20	10.0.0.34	Host (Proxmox) network is unreachable
10.0.0.254	10.0.0.254	VM: Firewall (kommt ins Internet)

Von den Windows clients und dem Admin-Notebook aus komme ich ins Internet und kann server und fw anpingen – nicht aber den vm host, der hat keine IP (mir völlig schleierhaft, warum).

Werde morgen /etc/network/interfaces Zeichen für Zeichen genauestens inspizieren.
Irgendwo muss ja der Fehler liegen.

Hallo Ersin,

hast du dich daran gehalten?

Punkt 4. Shutdown des Hosts

Beste Grüße

Thorsten

Ach sooooo, dein Proxmox läuft im gleichen LAN wie die anderen Clients. Könnte es sein, dass du dessen IP nicht in der OPNSense freigegeben hast? Da ist doch per default ein kleiner Bereich von IP Adressen freigegeben… gehört dein Hypervisor dazu??

Hallo Ersin,

poste doch mal die Ausgabe von „ip a“ oder „ifconfig -a“ und die /etc/network/interfaces.

Beste Grüße

Jörg

Hallo Thorsten,

Ich meine Ja – aber auch danach habe ich zig-mal neu gestartet, um Einträge zu übernehmen
(werde bei nächster Gelegenheit das Paket ifupdown2 installieren, damit das ohne Neustart geht).

BG, ersin

Ich meinte das hier:
https://docs.linuxmuster.net/de/latest/systemadministration/network/default-access-rules.html
Dort unter: Zugriff ohne ProxyFirewall | Aliase

Hallo Jörg,

Ja, mach ich, sobald ich (heute so gegen 11:30) wieder an der Schule bin…
Wollte mir diese Sachen ohnehin genauer angucken, weil ich dort den Fehler (oder Hinweise drauf) vermute.

BG, ersin

Update 11:50:
hier die Daten, ich seh da nix ungewöhnliches. Aber vllt. fällt euch was auf.

/etc/network/interfaces

network interface settings; autogenerated

Please do NOT modify this file directly, unless you know what

you’re doing.

If you want to manage parts of the network configuration manually,

please utilize the ‚source‘ or ‚source-directory‘ directives to do

so.

PVE will preserve these directives, but will NOT read its network

configuration from sourced files, so do not attempt to move any of

the PVE managed interfaces into external files!

auto lo
iface lo inet loopback
iface eno1 inet manual
iface enp1s0f0 inet manual
iface enp1s0f1 inet manual
iface enp1s0f2 inet manual
iface enp1s0f3 inet manual

auto vmbr0
iface vmbr0 inet manual
address 10.0.0.34 # green IP of vm host
netmask 255.255.0.0 # CIDR 16
gateway 10.0.0.254 # green IP firewall (OPNSense)
bridge-ports enp1s0f0
bridge-stp off
bridge-fd 0

auto vmbr1
iface vmbr1 inet manual
bridge-ports enp1s0f1
bridge-stp off
bridge-fd 0

output 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: 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
4: 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
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
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 56:38:c4:1c:33:c4 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 4a:18:06:1a:40:a0 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 ce:56:7b:c5:52:76 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 4a:18:06:1a:40:a0 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 aa:e1:2b:6e:6c:bb 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 7e:bc:8e:7a:b2:17 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:e9:9c:ab:b7:1e 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 7e:bc:8e:7a:b2:17 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 7e:ca:61:3c:f4:d0 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 ca:bb:61:fa:2c:0a 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 b6:92:95:ba:a0:46 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 ca:bb:61:fa:2c:0a brd ff:ff:ff:ff:ff:ff

(Anm.: das einleitende # bewirkt hier Fettdruck, weiß jemand, wie ich längeren Text in eine scrollbare Box bekomme?)

Hallo Michael,

Ja, hab ich (auf das Dashboard von OPNSense komme ich ja, daher extra vergewissert, weil der neue Host ja nicht mehr die IP ~20 hat, sondern ~34).

BG, ersin

Hallo Ersin,

schreibe mal in die /etc/network/interfaces:

iface vmbr0 inet static

(static statt manual - manual heißt, dass Du das Device zur Laufzeit manuell konfigurierst, static heißt, dass es mit den angegebenen Werten konfiguriert werden soll).

Beste Grüße

Jörg

Guckst Du hier!