Clients verlieren DHCP lease

V

Vengance

Renowned Member
May 21, 2016
271
12
83
34
Hi,

Ich nutze auf meinem Proxmox Server einen DHCP sowie radvd Server zur automatischen IP Vergabe.

Leider ist mir aufgefallen, dass die Clients nach einiger Zeit Ihre IPv4 Adresse verlieren.
Die IPv6 bleibt bestehen aber die IPv4 verschwindet. Ein reboot hilft hier, jedoch ist dann nach einiger Zeit auch hier die IP weg.

Anfangs fehlte mir der Eintrag "max-lease-time" in der DHCP config, diesen habe ich eben hinzugefügt und testweise 4 VMs erstellt.
Alle haben erfolgreich eine IP erhalten, jedoch war diese bei allen VMs nach recht zeitgleich nach ca 10min weg.

Die 10min entsprechen meiner default-lease-time, scheinbar erneuern die VMs irgendwie die Lease nicht?


Hat hier jemand eine Ahnung woran das liegen kann? Ich bin aktuell leider ziemlich ratlos.



Grüße und vielen Dank!
Ian





/etc/dhcp/dhcpd.conf
Code: 
ddns-update-style none;
default-lease-time 600;       
max-lease-time 7200;
authoritative;
subnet 0.0.0.0 netmask 0.0.0.0 {
  range 5.9.xxx.56 5.9.xxx.63;
  option subnet-mask 255.255.255.255;
  option routers 116.202.xxx.226;
  option domain-name-servers 1.1.1.1;
}
 
Hi,

Was sind die Clients hier? Ausschließlich VMs? Welches OS in welcher Version läuft dort?
Firewall aktiviert?

Eventuell auch mal tcpdump installieren und schauen ob die VMs eh zur Erneuerung der Lease überhaupt nachfragen.
tcpdump -i vmbr0 -vn port 67 and port 68

Hab hier einen dnsmasq unteranderem als dhcp server am PVE host laufen, dass klappt.
 
Hi Thomas,

Danke dir für die schnelle Rückmeldung.
Genau, die Clients sind alle KVM VMs auf Basis von Debian 10.

Danke für den Tipp mit tcdump, ich werde das später mal testen :)


Ich musste einen Workaround nutzen und das Subnet sowie Netmask auf "0.0.0.0" setzten, da ISC sonst meckert, dass das Subnet ein anderes ist, als die IP der Bridge.
Ich habe als IP die des Hostsystems genutzt und das Subnet auf die Bridge geroutet, da ich so alle Addressen aus dem Subnet zur Verfügung habe.

Ich hoffe das hängt nicht mit dem Fehler zusammen, aber ich denke nicht, da die erste Zuweisung der IP ja funktioniert.
 
Ein TCP Dump wird da Aufschluss geben, aber auch ein Blick in das Journal mit journalctl -f
Da siehst du genau was dein DHCP Server so tut. Wen ndu dort verworfene Anfragen findest mit dem Kommentar "wrong subnet" dann ist auf jeden Fall die Konfiguration des DHCP nicht so wie sie deine Netzwerkstruktur erfordert.
Wenn dein DHCP nur eine Schnittstelle in einem Netzwerk hat das nicht zu deinem Client Netz gehört, dann ist die sauberste Lösung ein DHCP Relay, oder deinem DHCP Server eine Schnittstelle in dem Netz zu geben wo du die Adressen brauchst.

Wir haben hier z.B. einen externen Standort mit einem gerouteten Netz und keine Möglichkeit unserem DHCP dort eine Adresse im Netz zu verpassen. Deshalb macht die Firewall an dem Standort den DHCP Relay Server. Dadurch können die Anfragen auf Layer 3 geroutet werden und der DHCP Server erfährt von der Firewall für welches Netzwerk eine Adresse benötigt wird.

Allgemein zu deiner Konfiguration:
Generell ist eine Konfiguration mit 0.0.0.0/0 als Netzwerk im DHCP nicht wirklich als Problemlösung geeignet. Gut Möglich das die Clients eine Antwort vom DHCP erhalten mit der sie nicht so viel anfangen können weil z.B. die Netzmaske nicht passt etc.
Sind das da in der Konfig tatsächlich deine Netze? Das passt alles nicht zusammen... Eine Netmask von 255.255.255.255 ist nicht gültig, sie passt auch nicht zu der Netmask die du bei subnet angegeben hast. Auch die IP Adressen sind (mal normale Netzmasken angenommen) alle in verschiedenen Netzen, so das Geräte unter 5.9.xxx.48/28 gar nicht mit dem Gateway kommunizieren können.
Die Netze und Netzmasken müssen schon zu deinem Netzwerk passen...
 
Ja, die IPs bzw Netze sind echt.
Ich habe keine andere Lösung gesehen, da das Netz, dass ich verteile eben von der IP der Bridge abweicht.

Die option-netmask ist die eigentliche Netmask, ich wüsste nicht, wieso /32 hier falsch ist, da die VMs eben jeweils eine einzelne IP bekommen.
Das der Gateway außerhalb des Netzwerks liegt, ist bei Hetzner völlig normal, hier setzt Debian wohl intern auch direkt die Routen.

Die VMs haben eine funktionierende IPv4 verbindung, ich werde später jedoch auch mal den output von journalctl -f überprüfen, ggfls passt das dem Client wirklich nicht.

Dann wüsste ich jedoch nicht, wie ich das lösen könnte.

Die Situation ist folgende, ich habe eine zusätzliche Bridge, die als IP die selbe Adresse hat, wie der NIC des Hostsystems.
Mein Subnet wird direkt auf diese Bridge geroutet.
So kann ich alle IPs meines Subnets nutzen.

Nun hat das jedoch dem DHCP Server nicht gepasst, da das Subnet, das er verteilen soll eben nicht zu der IP der Bridge passt.
 
Ah verstehe, das liegt bei Hetzner, gut da ist das mit den Gateways tatsächlich etwas anders. Ich finde das Konstrukt bei Hetzner etwas verwirrend, daher hoffe ich das ich die Konsequenzen daraus richtig verstanden habe.

Ich glaube an der Stelle ist es am einfachsten du gibst deinem DHCP Server eine weitere Schnittstelle die für dieses Netzwerk gedacht ist.

Wenn dein DHCP eine VM ist musst du nichts weiter tun als der VM eine neue Schnittstelle zu geben, die auf der selben Bridge liegt wie deine VMs und dort eine IP konfigurieren die zu dem Client Netz passt. So kennt dein DHCP dieses Netz und weiß auf welcher Schnittstelle er die Anfragen korrekt beantworten kann.

Sollte dein DHCP direkt auf dem Blech laufen, kannst du das ebenfalls auf eine ähnliche Weise lösen.
Angenommen deine Maschine nutzt vmbr0 für die Adresse des Hostsystems und deine Client VMs nutzen die Bridge vmbr1 in Proxmox mit ihrem eigenen Netz.
Du erstellst einfach in Proxmox eine "virtuelle" Bridge vmbr2 ohne physikalische Schnittstelle, verpasst dieser eine IP Adresse im Bereich der Clients und trägst vmbr2 in Proxmox als Slave-Schnittstelle von vmbr1 ein. Dadurch hat dein auf der Hardware laufender DHCP Server eine virtuelle Schnittstelle auf der virtuellen Bridge deiner Clients und kann direkt mit denen kommunizieren. Falls du keine Bridge auf der Hardware anlegen kannst, brauchst du entweder einen DHCP Relay, oder du migrierst deinen DHCP Dienst in eine VM.
 
Ok, ich glaube ich habe das Problem gelöst, ich werde das mal noch beobachten und mich notfalls nochmal zurück melden.

Folgende Situation:
Ich nutze zur Netzwerkconfiguration der VMs Cloud-Init.
Auf dem Host ist sowohl ein DHCP als auch Radvd Server installiert.

Da Proxmox via Cloud Init aktuell noch keine Möglichkeit bietet, SLAAC für die IPv6 Konfiguration zu wählen, habe ich hier DHCP genutzt, da ich festgestellt habe, dass nach einiger Zeit auf SLAAC umgestellt wird.
Scheinbar hat diese fehlerhafte DHCP Konfiguration jedoch gestört.

Ich habe nun via CloudInit IPv6 auf static gesetzt und keine IP angegeben. So wird das Interface zwar nicht konfiguriert, Debian bezieht jedoch dennoch die IP via SLAAC.

Ist nicht wirklich schön, scheint bisher aber zu funktionieren.
Ich hoffe, dass SLAAC für Cloudinit bald integriert wird.

Grüße und vielen Dank
Ian
 
Ok, ich muss wohl etwas zurückrudern.

IPv6 auf static zu setzten und das Interface unkonfiguriert zu lassen funktioniert nur, wenn ich IPv4 auf DHCP setzte.
Ansonsten wird einfach generell kein Interface konfiguriert, somit habe ich auch keine IPv4.

SLAAC Support für cloudinit wäre für mich daher essentiell.
@t.lamprecht wäre es irgendwie möglich, die Option hinzuzufügen?
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back