DHCPD-Clean-Leases bei Trennung des Clients

DHCPD-Clean-Leases bei Trennung des Clients

Gibt es eine Möglichkeit, ISC DHCPD zu zwingen, direkt nach der Trennung der Clients das Ablaufen oder Freigeben einer statischen Lease auszulösen?

Ich möchte ein Skript auslösen, direkt nachdem der Client eine Verbindung herstellt (DHCPD-Ereignis „beim Commit“) und die Verbindung trennt (DHCPD-Ereignis „bei Ablauf“ oder „bei Freigabe“).

Während das erste wie am Schnürchen läuft, werden die letzten nie ausgelöst. Irgendwelche Ratschläge?

BEARBEITEN: Ein Konfigurationsausschnitt (mit Testskript):

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.40 192.168.1.49;

  on commit {
    set ip = binary-to-ascii (10, 8, ".", leased-address);
   execute ("/usr/local/bin/dhcp-test", "commit", ip);
  }
  on release {
    set ip = binary-to-ascii (10, 8, ".", leased-address);
    execute ("/usr/local/bin/dhcp-test", "release", ip);
  }
  on expiry {
    set ip = binary-to-ascii (10, 8, ".", leased-address);
    execute ("/usr/local/bin/dhcp-test", "expiry", ip);
  }
}

Antwort1

Wenn ich das richtig verstanden habe, müssen Sie zum Erstellen eines statischen Leases so etwas in Ihrer Konfiguration haben:

host static-1 {
    hardware ethernet 00:01:02:03:04:05;
    fixed-address 192.168.1.40;
}

Dies funktioniert wie erwartet, gibt diese IP-Adresse jedoch nie frei (es spielt keine Rolle, ob der Client DHCPRELEASE sendet oder nicht), da es sich aus der Sicht von DHCP um eine STATISCHE IP handelt.

Sie müssen eine DYNAMISCHE IP erstellen (wiederum aus der Sicht von dhcpd), damit dhcpd sie verfolgen kann. Sie können dies folgendermaßen tun:

# First create pseudo class
class "static-ip" { match suffix(hardware, 6); }

# Here you will declare all MAC of your clients and make it a subclass of "static-ip"
# class "<UNIQ-CLASSNAME>" { match if suffix(hardware, 6) = <CLIENT-MAC-ADDRESS>; } subclass "static-ip" <CLIENT-MAC-ADDRESS>;
# Example
class "static-1" { match if suffix(hardware, 6) = 00:01:02:03:04:05; } subclass "static-ip" 00:01:02:03:04:05;

# Next allocate an address for every client (inside subnet declaration):

subnet 192.168.1.0 netmask 255.255.255.0 {
  on commit {
    set ip = binary-to-ascii (10, 8, ".", leased-address);
   execute ("/usr/local/bin/dhcp-test", "commit", ip);
  }
  on release {
    set ip = binary-to-ascii (10, 8, ".", leased-address);
    execute ("/usr/local/bin/dhcp-test", "release", ip);
  }
  on expiry {
    set ip = binary-to-ascii (10, 8, ".", leased-address);
    execute ("/usr/local/bin/dhcp-test", "expiry", ip);
  }

 # pool { range <ip-addr>; allow members of "<UNIQ-CLASSNAME>"; }
   pool { range 192.168.1.40; allow members of "static-1"; }
 # pool { range 192.168.1.41; allow members of "static-2"; }
 #... so on
}

Um Ihre Konfiguration flexibler zu gestalten, können Sie Klassen-Unterklassen- und Poolbereichsdeklarationen in verschiedene Dateien einfügen undenthaltensie in die Haupt-dhcpd.conf

#dhcpd.conf
authoritative;
min-lease-time ...;
... etc.

include "/path/to/classes.conf";
include "/path/to/subnet.conf";

Wie Sie sehen, haben wir jeden Client in seine eigene Klasse eingeordnet UND ihn in die Klasse „static-ip“ untergeordnet. Dies ist für den Fall, dass Sie ein weiteres Subnetz ohne statische IP-Zuweisung haben möchten, zum Beispiel:

subnet 192.168.2.0 netmask 255.255.255.0 {
 range 192.168.2.10 192.168.2.100;
 deny members of "static-ip";
}

Dann müssen Sie Clients mit statischer IP-Zuweisung den Zugriff auf IPs aus diesem Subnetz verweigern (mitleugnenStichwort).

Auf diese Weise erhalten Sie eine DYNAMISCHE IP (aus der Sicht von dhcpd), die sich jedoch tatsächlich nie ändern wird (aus der Sicht des Clients).

Antwort2

DHCP behält die Lease im Allgemeinen bis zum Ablaufzeitpunkt bei und versucht, dieselbe Lease an einen Client erneut auszugeben, der sich später erneut verbindet. Es werden nur dann Kandidaten freigegeben, wenn der Umfang durch neue Clients belastet wird.

Dadurch können Clients bei der nächsten Verbindung ohne zu lange Intervalle zwischen den Sitzungen dieselbe Adresse erneut abrufen und es entsteht der Eindruck einer nahezu statischen Adressierung.

Es ist möglich, dass Ihre Skripte (absichtlich) nicht ausgeführt werden, bis der Timer abgelaufen ist. Sie können versuchen, dies zu erzwingen, indem Sie entweder die Konflikte im Bereich erhöhen oder die Timerdauer verkürzen, um den Vorgang zu beschleunigen.

Antwort3

Dank @TomTom habe ich mich eingehender mit RFC2131 befasst und dieses Verhalten statischer Leases bestätigt:

...DHCP supports three mechanisms for IP address allocation.  In
"automatic allocation", DHCP assigns a permanent IP address to a
client.  In "dynamic allocation", DHCP assigns an IP address to a
client for a limited period of time (or until the client explicitly
relinquishes the address).  In "manual allocation", a client's IP
address is assigned by the network administrator, and DHCP is used
simply to convey the assigned address to the client. 

    Dynamic allocation is the only one of the three mechanisms that
allows automatic reuse of an address that is no longer needed by the
client to which it was assigned...

Der Grund, warum ich es nicht früher gefunden habe, ist: "statische Mietverträge" angerufen "dauerhaft" in RFC und Strg+F hat keine eingebaute KI (leider)

Ich suche also immer noch nach einer funktionierenden Methode, mit Clients umzugehen, die die Verbindung zum Netzwerk trennen.

verwandte Informationen