11.12.2023, aktualisiert um 12:23:54 Uhr

4808

DHCP mit GUI

Hallo!

Ich suche gerade einen gut-funktionierenden HA-DHCP-Server mit GUI, der keine riesigen Lizenzkosten auslöst für 20-30 Netzwerksegmente.

Einfache Aufgaben sollten auf einer GUI möglich sein:

Leases einsetzen
Leases löschen
Leases "statisch" machen (Reservierung eintragen)

Meine bisherigen Punkte:

Windows DHCP

--> Fällt raus. Spätestens bei Gästenetzen explodieren die Lizenzkosten

DHCPd

Keine vernünftige GUI - höchstens Webmin

Stork ist (noch) sehr eingeschränkt

Mikrotik Router OS

Ausreichend, aber kein vernünftiges HA (leases werden nicht synchronisiert)

Habt ihr eine Idee für mich?

Danke und Grüße
Phil

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 13279503641

Url: https://administrator.de/forum/dhcp-mit-gui-13279503641.html

Ausgedruckt am: 22.12.2024 um 07:12 Uhr

40 Kommentare

Neuester Kommentar

Moin,

Und webmin als GUI-Aufsatz für den regulären dhcpd unter linux reicht nicht?

lks

*sense ?

(OPNsense, pfSense)

Servus,

habe mit HA keine praktische Erfahrung.
Wie schaut deine Firewall aus?
Kann es die vielleicht? Dein Setup schaut größer aus, ist die Firewall ev. bereits als Cluster aufgebaut?
Opnsense wäre was mit GUI.

Grüße, Stefan

für 20-30 Netzwerksegmente.

Als zentralen DHCP Server der alles Scopes beinhaltet und wo die 30 Segmente per DHCP Relay bedient werden oder wie hat man sich das vorzustellen?? 🤔
Oder willst du in 30 Segmenten jeweils 30mal einen separaten standalone DHCP Server betreiben??

Hallo!

Hallo, (wieso !)?

Ich suche gerade einen gut-funktionierenden HA-DHCP-Server mit GUI, der keine riesigen Lizenzkosten auslöst für 20-30 Netzwerksegmente.

Okay

Einfache Aufgaben sollten auf einer GUI möglich sein:
Leases einsetzen
Leases löschen
Leases "statisch" machen (Reservierung eintragen)

Okay.

Meine bisherigen Punkte:
Windows DHCP
--> Fällt raus. Spätestens bei Gästenetzen explodieren die Lizenzkosten

Das halte ich für ein Gerücht. Ein DHCP Server kann mehrere/beliebige Scopes verwalten. Seit wann kosten die Scopes Lizenzen?

Danke und Grüße
Phil

Gruss Penny.

Moin,

Das halte ich für ein Gerücht. Ein DHCP Server kann mehrere/beliebige Scopes verwalten. Seit wann kosten die Scopes Lizenzen?

der Scope kostet keine Lizenzen. Allerdings ist DHCP ein Service wie alle anderen Services und muss daher entsprechend lizenziert werden. Das gleiche gilt auch für DNS/WINS.

Gruß,
Dani

Zitat von @Dani:

Moin,

Das halte ich für ein Gerücht. Ein DHCP Server kann mehrere/beliebige Scopes verwalten. Seit wann kosten die Scopes Lizenzen?

der Scope kostet keine Lizenzen. Allerdings ist DHCP ein Service wie alle anderen Services und muss daher entsprechend lizenziert werden. Das gleiche gilt auch für DNS/WINS.

Beim Windows Server 2019 / 2022 Standard ist DHCP Dienst doch dabei. Wenn ich eine Lizenz kaufe, gilt diese auch für den DHCP Server. Oder irre ich mich?

Gruß,
Dani

Gruss Penny.

Und wie kalkulierst du die CALs dazu?

Zitat von @Penny.Cilin:
Wenn ich eine Lizenz kaufe, gilt diese auch für den DHCP Server. Oder irre ich mich?

Die Lizenz des Servers gilt auch für den DHCP. Das ist richtig. Nach meinem letzten Kenntnisstand brauchst du für jedes Gerät das vom Windows-DHCP eine IP bezieht aber eine CAL.

Manuel

Zitat von @manuel-r:

Zitat von @Penny.Cilin:
Wenn ich eine Lizenz kaufe, gilt diese auch für den DHCP Server. Oder irre ich mich?

Die Lizenz des Servers gilt auch für den DHCP. Das ist richtig. Nach meinem letzten Kenntnisstand brauchst du für jedes Gerät das vom Windows-DHCP eine IP bezieht aber eine CAL.

Manuel

Wenn man Geräte-CALs nimmt. Ansonsten braucht man eine User-CAL für jeden Benutzer, der die Geräte nutzt.

Grüße

lcer

Windows und seine Lizenzen ...

Es bieten sich IMO an:
PfSense, OPNsense mit CARP, Erläuterungen hier und hier.
Router OS mit VRRP, Anleitung hier

Mir sehen alle drei Lösungen grundsätzlich ähnlich aus. PfSense und OPNsense synchronisieren aber die Leases und das willst Du ja. Mit Router OS lässt sich das sicher über export/import scripten aber das wird wahrscheinlich nicht ganz einfach, wenn Lease-Änderungen an beiden Servern berücksichtigt werden müssen.

Also PfSense/OPNsense vielleicht mal auf den Funktionsbedarf checken.

Viele Grüße, commodity

Router OS mit VRRP

Nein!
VRRP ist kein DHCP sondern eine Gateway Virtualisierung. Völlig andere Baustelle die gar nix mit DHCP am Hut hat!

Der TO hat sich ja noch nicht dazu geäußert ob er den DHCP Server zentral mit DHCP Relay aus den Segmenten betreiben will. Das er 2mal OPN- oder pfSense in jedes seiner 30 Segmente schrauben will ist wohl eher nicht anzunehmen. 🤔
ISC-DHCP in zwei Linux VMs im HA Failover in Verbindung mit webmin wäre wohl die deutlich sinnvollere Alternative.
https://kb.isc.org/docs/aa-00502

Nein!

Jein

- Haste nicht gelesen?
Die Lösung realisiert DHCP-"HA" über VRRP. VRRP ist nicht die Lösung, sondern das Mittel zum Zweck, indem ein Interface geschaffen hat, was Master und Backup ansteuern können.

Viele Grüße, commodity

Dennoch rennen dabei ja dann 2 DHCP Server parallel ohne gemeinsame Lease Datenbank, da MT sowas nicht supportet. Würde zudem bedeuten das auch hier 2mal 30 = 60 Router beschafft werden müssten.
VRRP hat mit einem redundantem DHCP Server Setup nicht das Geringste zu tun. Sicher nicht die Lösung die der TO will, denn VRRP ist lediglich Gateway Sharing. Nicht mehr und nicht weniger.

Eine redundante DHCP Adressvergabe leistet es de facto nicht.

Sicher nicht die Lösung die der TO will

Wenn Du 5 Sek. in das Verständnis meines Beitrages investiert hättest, statt über das erste Keyword herzufallen, das Dich triggert, hättest Du erkannt, dass ich das nie als Lösung für den TO vorgeschlagen habe. Ich habe den für ROS beschriebenen Weg lediglich ins Verhältnis zu den Lösungen von OPNsense und PfSense gesetzt. Mein IMO unschwer nachzuvollziehendes Fazit war:

Also PfSense/OPNsense vielleicht mal auf den Funktionsbedarf checken.

Dein

Nein!

war hier ebenso wenig passend, wie der Vortrag zu VRRP

Ob die Lösung der Senses den Anforderungen des TO genügt, weiß ich nicht, wird er aber selbst beurteilen können.

Eine

gemeinsame Lease Datenbank

wäre wahrscheinlich der Königsweg, bedeutet aber, die Datenbank dann redundant auszulegen, sonst holt man sich hier den SPoF rein und es ist wieder kein HA. Dann wird's gleich nochmal ein bisschen komplexer. Da erscheint mir die Sync-Lösung der Senses doch etwas direkter.

Viele Grüße, commodity

Das er 2mal OPN- oder pfSense in jedes seiner 30 Segmente schrauben will ist wohl eher nicht anzunehmen. 🤔

ISC-DHCP in zwei Linux VMs im HA Failover in Verbindung mit webmin wäre wohl die deutlich sinnvollere Alternative.

Beide müssen in jedes VLAN oder beide müssen DHCP Anfragen über Relays empfangen.

Die OPNSense ist doch auch nur Linux. Der Sinn oder Unsinn beider Varianten wäre für mich exakt: gleich

Eine Frage noch nebenbei: Wozu sollten die Leases bei einem Failover oder Switchover synchronisiert sein?

Wozu sollten die Leases bei einem Failover oder Switchover synchronisiert sein?

Hatte ich auch überlegt. Im Failover-Fall würden bestehende TCP-Connections aber durch den (ohne Sync) erfolgenden Wechsel der IP-Adresse im Failover-Fall abgebrochen und das werden einige Anwendungen nicht so mögen.

Viele Grüße, commodity

Zitat von @commodity:

Wozu sollten die Leases bei einem Failover oder Switchover synchronisiert sein?

Erstens kann RouterOS die Connection-Tracking-Tabelle via VRRP mit dem Backup-Router synchronisieren (Option sync-connection-tracking), zweitens arbeitet der Client erst mal mit seiner bestehenden Adresse weiter bis er sie nach Ablauf der halben Lease-Zeit erneuert, ergo bleibt die Verbindung für den Client unterbrechungsfrei sofern dieser beim Failover WAN-Seitig über die selbe externe IP nach außen geht. Klappt hier seit eh und jeh problemlos.
Der doppelte DHCP macht hier auch kein Problem da der DHCP vom Backup-Router eh erst aktiv wird wenn der Failover-Fall eintritt weil dieser auf das VRRP Interface gebunden ist, und das wird erst aktiv wenn der Master weg ist, es ist also immer nur ein DHCP gleichzeitig im Netz aktiv.

Gruß Katrin

@aqui
Ich möchte auf dem zentralen Firewallcluster (Fortigate) je Interface einen DHCP-Relay einrichten.

@Penny.Cilin
Jedes Device, das eine IP bekommt benötigt unter Windows eine CAL. Dadurch wird z.B. ein Gästenetz zum Problem

@commodity
RouterOS kann keine Leases synchronisieren. VRRP ist nur für die IP zuständig.

@NordicMike
Wenn die Leases nicht synchronisiert werden, muss ich entweder zwei Pools ohne Überlappung definieren, oder riskieren doppelte IPs beim Failover

kann RouterOS die Connection-Tracking-Tabelle via VRRP mit dem Backup-Router synchronisieren (Option sync-connection-tracking)

Zweitens ist ja klar, dann hängt das Problem an der Lease-Time - aber erstens ist wahrscheinlich der "Trick". Ist das dann so, dass es kein Problem gibt, weil es keinen Adresswechsel gibt? Und ist das wiederum nicht deshalb so, weil Du auch die Leases synchronisierst? Nur der Sync der Connection-Table allein führt doch nicht zur Neuvergabe derselben Lease - oder spielt die Connection-Table da auch eine Rolle?
Edit1: Ah, das Gerät fragt ja zunächst mit seiner bereits vergebenen Adresse. Dann ist das auch kein Problem.
Muss dann die Connection-Tracking-Tabelle überhaupt gesynct werden?
Jedenfalls ein super-Tipp! Wie immer

Aber der Kollege @aqui meint ja, mit Hilfe von VRRP könne man den Task des TO nicht lösen. Vielleicht beschreibst Du Dein Setup noch genauer und wo die Stärken/Schwächen liegen?

Viele Grüße, commodity

Edit 2: @Der-Phil
Ich verstehe den Post von KollegIn @8030021182 so, dass ein Sync der dynamischen Leases nicht erforderlich ist (siehe auch ein paar Zeilen höher bei Edit1. Die statischen Leases kannst Du syncen. Und doppelte IPs bekommst Du auch nicht, weil die Lease beim Failover ja dennoch nur von einem Server kommt. Wenn Du die Ranges identisch machst, sollte auch bei dynamischen Adressen sogar immer dieselbe IP-Adresse vergeben werden, solange die Lease am Client nicht abgelaufen ist.
Deshalb ist das wahrscheinlich auch bei den CARP-Lösungen der Senses nicht thematisiert. Kollege @nordic-mike hat es mit seiner Frage auf den Punkt gebracht.

Das mit dem fehlenden Sync sehe ich eben anders.

Client 1 bekommt IP1 als dynamisches Lease
Nach einem Failover macht der DHCP2 lediglich einen Ping zum Test, da er das Lease ja nicht kennt. Antwortet z.B. das Gerät nicht auf einen Ping, wird die IP doppelt vergeben.

Deswegen macht isc-dhcpd z.B. jederzeit ein Lease-Sync.

Zitat von @Der-Phil:
Client 1 bekommt IP1 als dynamisches Lease
Nach einem Failover macht der DHCP2 lediglich einen Ping zum Test, da er das Lease ja nicht kennt. Antwortet z.B. das Gerät nicht auf einen Ping, wird die IP doppelt vergeben.

Nein nix mit Ping quatsch, erst kommt mal der ARP-Request vom Fallback Router da dem die MAC ja noch nicht bekannt ist.
Erneuert der Client seine Lease steht seine alte IP vom Master-Router im Request-Paket, sofern die IP am Slave-DHCP in seinem Pool noch frei ist wird er diese IP dem Client in seinem Offer auch wieder anbieten.

Nach einem Failover macht der DHCP2 lediglich einen Ping zum Test

An welcher Stelle soll das erfolgen? Ein Ping erfolgt IMO nur auf den zweiten Router.
Edit: Ah, es gibt DHCP-Server, die einen Ping-Test machen.

@8030021182

sofern die IP am Slave-DHCP in seinem Pool noch frei ist wird er diese IP dem Client in seinem Offer auch wieder anbieten.

Besteht dann ohne Lease-Sync hier nicht das Problem, dass doppelte IP-Adressen auftreten können? Client A hat zB bereits IP .23 vom primären DHCP. Dann fällt dieser aus. Der Fallback-Server hat sie nicht in seiner Lease-Table und vergibt auf auf Anfrage von Client B evtl. die .23 neu.

@Der-Phil: Meinst Du deshalb, das der Sync gebraucht wird?

Viele Grüße, commodity

Zitat von @commodity:
Besteht dann ohne Lease-Sync hier nicht das Problem, dass doppelte IP-Adressen auftreten können? Client A hat zB bereits IP .23 vom primären DHCP. Dann fällt dieser aus. Der Fallback-Server hat sie nicht in seiner Lease-Table und vergibt auf auf Anfrage von Client B evtl. die .23 neu.

Jain, es wird natürlich vor der Vergabe immer gecheckt ob diese IP bereits belegt ist oder es einen Konflikt gibt und der Client bekommt dann im Fall der Fälle eine neue in einem Offer angeboten.
Da aber beide Router im selben Subnetz hängen und es dort auch keine doppelten IPs gibt kommt sowas bei einem Failover so gut wie nicht vor.

es wird natürlich vor der Vergabe immer gecheckt ob diese IP bereits belegt ist

mit dem Ping-Test?
Dann wäre es weiter ein Problem, wie Kollege @Der-Phil anmerkt, wenn das Gerät auf einen Ping nicht reagiert.

Viele Grüße, commodity

P.S.: Hier kann man echt was lernen. Danke Euch!

Zitat von @commodity:

es wird natürlich vor der Vergabe immer gecheckt ob diese IP bereits belegt ist

mit dem Ping-Test?

Nein. ICMP kann ein Rechner ja bekanntlich in seiner Firewall filtern und muss nicht darauf antworten, das läuft alles über die Lease-Tabelle des DHCP-Servers und ARP-Checks (Conflict-Detection) von Client und Server.

Ah, hier Answer 5 zitiert aus den RFC: https://superuser.com/questions/1604883/does-a-dhcp-server-really-check- ...
Der Client muss per ARP selbst prüfen, ob die angebotene Lease zulässig ist. Mein Hirn ist ein Sieb, das hatte ich schon mal gelernt...
Im Link steht das mit dem Ping auch hübsch erläutert.

Viele Grüße, commodity

Ohne ARP ja auch kein Ping. 😊

Wo Du Recht hast, hast Du Recht

Viele Grüße, commodity

Das Problem ist, dass weder der Client, noch der zweite DHCP _verlässlich_ prüfen können, ob eine IP im Einsatz ist, wenn sie gerade nicht kommuniziert.

Das ist alles maximal "95%ig".

Wieso? Der Client mach doch einen ARP-Broadcast. Wenn keiner antwortet, ist keiner da.

Beschreib mal ein Szenario für die vermeintlichen 5%.

Viele Grüße, commodity

Hallo,

Zitat von @commodity:

Wieso? Der Client mach doch einen ARP-Broadcast. Wenn keiner antwortet, ist keiner da.

Beschreib mal ein Szenario für die vermeintlichen 5%.

Viele Grüße, commodity

Na ja, in https://www.rfc-editor.org/rfc/rfc2131 Kapitel 2.2 / Seite 12 steht

 As a consistency check, the allocating
   server SHOULD probe the reused address before allocating the address,
   e.g., with an ICMP echo request, and the client SHOULD probe the
   newly received address, e.g., with ARP.

und auf Seite 5 wird erklärt:

o "SHOULD"  

        This word or the adjective "RECOMMENDED" means that there  
        may exist valid reasons in particular circumstances to ignore
        this item, but the full implications should be understood and
        the case carefully weighed before choosing a different course.

Theoretisch wäre es also RCF-Compliant, wenn der Client das nicht tut. Aber praktisch?

Allerdings: Wenn ich den TO richtig verstehe, möchte er eine Lösung, bei der eine DHCP-Datenbank redundant auf mehrere Server verteilt vorgehalten wird. Dazu muss man sagen, dass die Konzeption von DHCP dies nicht enthält. Was möglich ist, sind mehrere DHCP-Server mit nicht überlappenden DHCP-Scopes. Also Server A mit X.X.X.100-150 und Server B mit X.X.X.151-200. Das wäre RFC-Compliant, denn über das DHCP-Offer und DCHP-Acknowledgement würde das Funktionieren. Jegliche Form von darüber hinaus gehender Redundanz ist nicht mehr Original-DHCP. Alle DHCP-HA-Ansätze sind daher in irgendeiner Form unvollkommen. Eben weil DHCP dies primär nicht vorsieht.

Grüße

lcer

Kollege @commodity redet aber vom Client und du vom Server ("...server SHOULD probe..").
Das der Server optional einen Ping bzw. ARB Check macht oder machen sollte ist ja evident. Bei einem Client ist das aber nicht vorgesehen oder üblich.

Ja, falsche RFC vom Editor und auch falsches Kapitel. Maßgeblich ist wohl RFC5227, die hier schreiben:

a host implementing this specification MUST test to see if the address is already in use, by broadcasting ARP Probe packets.

Viele Grüße, commodity

Edit: Hier nochmal zur Veranschaulichung - nach Neustart eines Raspberrys:

Erst kommt der DHCP Request vom Raspberry,
dann vergibt der Router die Adresse per ACK, hier 10.68.20.101
bevor der Raspberry diese nutzt, broadcastet er 3x ein ARP Probe und
broadcastet abschließend, weil niemand anderes Anspruch auf die Adresse gemeldet hat, sein ARP Announcement.
Erst dann meldet er sich mit seiner IP-Adresse und ARPt die weiteren Geräte

Hallo!

OK, das hatte ich so nicht auf dem Schirm, dass der Client das Probing macht. Wisst ihr, ob sich gängige Geräte daran "halten"?

Wisst ihr, ob sich gängige Geräte daran "halten"?

Das ist keine Frage der Geräte, sondern des Betriebssystems. Windows macht das seit Vista und Linux auch schon länger - also Android sicher auch (Du kannst es aber wegkonfigurieren und es gibt offenbar auch mal Leute, die den Standard "vergessen" - dann aber auch fixen). Bei Apple könnte man, was Standards angeht, da ein Fragezeichen setzen (Duckundwech

).

Nein, im Ernst, ich gehe fest davon aus, auch Apple macht das. Mach doch dazu einen Fred auf.
Katrin hat uns ja leider verlassen, aber @aqui könnte dazu sicher was sagen

Jetzt sind wir wahrscheinlich bei 99,9 %. Mehr wird es nicht werden

Viele Grüße, commodity

Wisst ihr, ob sich gängige Geräte daran "halten"?

Das wüsstest du auch selber wenn du deine gängigen Geräte einfach mal mit dem Kabelhai belauschst! 😉
Und ja, Apple ist da natürlich auch Standard konform...