Proxmox Weboberfläche nicht mehr erreichbar und pi.alert nicht erreichbar

[RudiP]

Gestern lief alles einwandfrei, heute morgen war die Proxmox Weboberfläche nicht mehr erreichbar. pi.alert läuft auf Proxmox und war nicht mehr erreichbar, pi.hole und HomeAssistant aber beide ansprechbar.
Diverse Neustarts führten nur dazu, das ab und zu mal die Weboberfläche von Proxmox erreichbar war, meist aber nur recht kurz.
Einmal war ich in die Konsole von pi.alert gekommen und ein "ip.addr" zeigte mir die IP 192.198.178.20. Das ist aber die vom Proxmox Server und nicht die von pi.alert.
In der Fritzbox wurde mir die IP 192.168.178.20 auch als von Proxmox belegt angezeigt, aber die von pi.alert wurde gar nicht angezeigt.
Ich habe dann über die Konsole am Proxmox PC mittels "pct stop 100" pi.alert angehalten.
Schwupps, war Proxmox wieder erreichbar.
Dann habe ich bei pi.alert unter Netzwerk das DHCP deaktiviert und die korrekte IP per Hand eingetragen. pi.alert wieder gestartet und schwupps, läuft wieder alles.
Wie es sein kann, das sich pi.alert die eigentlich vergebene und im Router auch eindeutig für Proxmox reservierte IP schnappen konnte, keine Ahnung. Sowas darf ja eigentlich überhaupt nicht passieren.
Aber für alle, die eventuell mal ähnliche Probleme haben, schreibe ich das hier mal auf.

 

[blurrrr]

Der PVE-Host sollte doch eigentlich eine statische IP haben (ausserhalb der DHCP-Range der Fritz!Box). Könnte evtl. sein, dass die .20 im DHCP der Fritz!Box wieder frei geworden ist und sich ggf. die pi-alert-Kiste die IP einverleibt hat? Grundsätzlich ist sowieso anzuraten, dass "alles was irgendwelche Art von Diensten" im Netz bereitstellt, mit einer statischen IP "ausserhalb" der DHCP-Range konfiguriert wird. Dann kann sowas nicht mehr passieren

eindeutig für Proxmox reservierte IP

Entweder sagt man wie es "ist" (statisch vergeben, ausserhalb der DHCP-Range), oder man vertraut einem Dienst (DHCP in diesem Fall). Ich persönlich halte nicht wirklich was von DHCP-Reservierungen. Fällt der Dienst mal aus oder wird ersetzt, ist erstmal Chaos angesagt, sofern man beim neuen Gerät nicht schon vor Einbindung ins Netz die entsprechenden Reservierungen neu angelegt hat.

 

[RudiP]

"frei geworden" kann ja nicht sein, wenn der Server ja läuft. Dazu ist die IP im Router ganz klar dem Gerät zugeordnet, also der MAC Adresse und durch das leased (oder wie sich das schreibt" sollte die IP ja auch einige Tage für dieses Gerät reserviert bleiben und auf gar keinen Fall neu vergeben werden.
Aber ja, hatte im Router den falschen Bereich für DHCP vergeben. Ab .20 durfte vergeben werden, nicht erst ab .21. Klar mein Fehler.

Dennoch hätte die neuanordnung der IP's niemals erfolgen dürfen.

 

[blurrrr]

"frei geworden" kann ja nicht sein, wenn der Server ja läuft.

Keine Ahnung, was da bei Dir schief gelaufen ist. ich kann Dir nur sagen, dass ich a) keine DHCP-Reservierungen nutze (tauscht man das Gerät mit den DHCP-Reservierungen aus, muss man wieder alles nachtragen - "bevor" das neue Gerät zum Einsatz im Netzwerk kommt, da ansonsten Chaos droht), b) den Dienste-anbietenden Geräten immer statische IPs zuweise (direkt am Gerät) und c) sich die statischen IP-Zuweisen auch immer ausserhalb der DHCP-Range befinden. Somit ist das alles strikt getrennt und ich hatte bisher nie Probleme. Selbst bei DHCP-Ausfall sind lediglich die Clients betroffen, der Rest funktioniert einfach weiter. Bei einem Routertausch sind lediglich die Netzinformationen wieder auf das vorherige anzupassen, fertig.

Also: Hypervisor -> statische IP direkt am Gerät, ausserhalb der DHCP-Range. Geht das derzeit nicht: DHCP-Range verkleinern (z.B. erst ab .30) und Geräte mit einer - vom DHCP bezogenen - IP aus dem Bereich .20-.30 nochmal kurz neustarten bzw. kurz vom Netz trennen und dann wieder verbinden. Alternativ kann man auch abwarten, bis der Client anfragt, ob er die IP behalten kann ("DHCP-Refresh (nur bei dynamischer Zuordnung)"), dann sollte der DHCP-Dienst auch automatisch neue IPs verteilen, da die alte bezogene IP nicht länger in der DHCP-Range liegt und somit darf der Client sie auch nicht behalten.