☰

Arrendamientos limpios de DHCPD en caso de desconexión del cliente

tag-icon • tag-icon linux networking dhcp dhcpd
Arrendamientos limpios de DHCPD en caso de desconexión del cliente

¿Hay alguna manera de forzar que ISC DHCPD active la caducidad o la liberación para el arrendamiento estático justo después de la desconexión del cliente?

Quiero activar una secuencia de comandos justo después de que el cliente se conecte (evento DHCPD "al confirmar") y se desconecte (evento DHCPD "al caducar" o "al liberar").

Mientras que el primero funciona a las mil maravillas, los últimos nunca se activan. ¿Algún consejo?

EDITAR: Un fragmento de configuración (con script de prueba):

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);
  }
}

Respuesta1

Si entendí correctamente, para realizar un arrendamiento estático tienes algo como esto en tu configuración:

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

Esto funcionará como espera, pero nunca liberará esta dirección IP (no importa si el cliente envía DHCPRELEASE o no), porque es una IP ESTÁTICA desde el punto de vista de dhcpd.

Debes crear una IP DINÁMICA (nuevamente, desde el punto de vista de dhcpd), para que dhcpd la rastree. Puedes hacerlo así:

# 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
}

Para hacer su configuración más flexible, puede colocar declaraciones de clase-subclase y rango de grupo en diferentes archivos yincluirellos en dhcpd.conf principal

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

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

Como puede ver, colocamos a cada cliente en su propia clase Y lo subclasificamos en la clase "IP estática". Esto es en caso de que desee tener otra subred sin asignación de IP estática, por ejemplo:

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

Luego debe negar a los clientes con asignación de IP estática obtener IP de esta subred (condenegarpalabra clave).

De esta manera obtienes IP DINÁMICA (desde el punto de vista de dhcpd), pero en realidad nunca cambiará (desde el punto de vista del cliente)

Respuesta2

Por lo general, DHCP mantendrá la concesión hasta el momento de su vencimiento en un intento de volver a emitir la misma concesión a un cliente que se vuelva a conectar más tarde. Sólo comenzará a liberar candidatos cuando haya presión sobre el alcance por parte de nuevos clientes.

Esto permite a los clientes volver a adquirir la misma dirección cuando se conectan nuevamente sin un intervalo demasiado largo entre sesiones y da la apariencia de un direccionamiento casi estático.

Es posible que sus scripts no se activen (por diseño) hasta que expire el temporizador. Puede intentar forzar esto aumentando la contención en el alcance o reduciendo la duración del temporizador para acelerar el proceso.

Respuesta3

Gracias a @TomTom, profundicé en RFC2131 y confirmé este comportamiento de los arrendamientos estáticos:

...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...

La razón por la que no lo encontré antes es porque "arrendamientos estáticos" llamado "permanente"dentro de RFC y Ctrl+F no tiene IA incorporada (desafortunadamente)

Así que todavía estoy buscando una forma funcional de manejar a los clientes que se desconectan de la red.

información relacionada