☰

Locações limpas de DHCPD na desconexão do cliente

tag-icon • tag-icon linux networking dhcp dhcpd
Locações limpas de DHCPD na desconexão do cliente

Existe uma maneira de forçar o ISC DHCPD a expirar ou liberar para concessão estática logo após a desconexão do cliente?

Quero acionar um script logo após o cliente se conectar (evento DHCPD "ao confirmar") e desconectar (evento DHCPD "ao expirar" ou "ao liberar").

Embora o primeiro funcione perfeitamente, os últimos nunca são acionados. Algum conselho?

EDITAR: Um snippet de configuração (com script de teste):

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

Responder1

Se bem entendi, para fazer um arrendamento estático você tem algo assim na sua configuração:

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

Isso funcionará como esperado, mas nunca liberará esse endereço IP (não importa se o cliente envia DHCPRELEASE ou não) - porque é um IP ESTÁTICO do ponto de vista do dhcpd.

Você deve criar um IP DINÂMICO (novamente, do ponto de vista do dhcpd), para que o dhcpd o rastreie. Você pode fazer assim:

# 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 tornar sua configuração mais flexível, você pode colocar declarações de classe-subclasse e pool-range em arquivos diferentes eincluircoloque-os no dhcpd.conf principal

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

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

Como você pode ver, colocamos cada cliente em sua própria classe E o subclassificamos na classe "static-ip". Isto é caso você queira ter outra sub-rede sem atribuição de IP estático, por exemplo:

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

Então você deve negar clientes com atribuição de IP estático para obter IPs desta sub-rede (comnegarpalavra-chave).

Desta forma você obtém IP DINÂMICO (do ponto de vista do dhcpd), mas na verdade ele nunca mudará (do ponto de vista do cliente)

Responder2

O DHCP geralmente manterá a concessão até o prazo de expiração, na tentativa de reemitir a mesma concessão para um cliente que se reconecte posteriormente. Só começará a liberar candidatos quando houver pressão de novos clientes no escopo.

Isso permite que os clientes readquiram o mesmo endereço quando se conectam novamente, sem um intervalo muito longo entre as sessões e dá a aparência de um endereçamento quase estático.

É possível que seus scripts não sejam disparados (por design) até que o cronômetro expire. Você pode tentar forçar isso aumentando a contenção no escopo ou reduzindo a duração do cronômetro para agilizar o processo.

Responder3

Graças ao @TomTom, aprofundo-me no RFC2131 e confirmo este comportamento de arrendamentos 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...

A razão pela qual não o encontrei antes é porque "arrendamentos estáticos" chamado "permanente"dentro de RFC e Ctrl+F não possui IA integrada (infelizmente)

Portanto, ainda estou procurando uma forma funcional de lidar com clientes que se desconectam da rede.

informação relacionada