DHCPD limpa arrendamentos na desconexão do cliente

2

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

Eu quero disparar um script logo após o cliente se conectar (evento DHCPD "com commit") e desconectar (evento DHCPD "na expiração" ou "no lançamento").

Enquanto o primeiro funciona como um encanto, os últimos nunca são acionados. Algum conselho?

EDITAR : Um snipplet 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);
  }
}
    
por GeekMagus 20.12.2013 / 01:37

3 respostas

1

Se entendi corretamente, para fazer uma concessão estática, você tem algo assim em 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á este endereço IP (não importa se o cliente envia DHCPRELEASE ou não) - porque é o IP ESTÁTICO do ponto de vista do dhcpd.

Você deve criar um IP DINÂMICO (novamente, do ponto de vista do dhcpd), assim o dhcpd irá rastreá-lo. 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 subclasse de classe e de pool em arquivos diferentes e incluí-los 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 subclasse-o na classe "static-ip". Isto é no caso de você querer 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";
}

Em seguida, você deve negar os clientes com a atribuição de IP estático para obter IPs dessa sub-rede (com a palavra-chave deny ).

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

    
por 20.01.2016 / 09:55
2

O DHCP geralmente manterá o aluguel até o tempo de expiração, na tentativa de reemitir o mesmo aluguel para um cliente que se reconecta mais tarde. Só vai começar a liberar candidatos quando houver pressão sobre o escopo de novos clientes.

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

É possível que seus scripts não sejam acionados (por design) até que o temporizador expire. Você poderia tentar forçar isso aumentando a contenção no escopo ou reduzindo as durações do temporizador para agilizar o processo.

    
por 20.12.2013 / 09:39
0

Graças a @TomTom, aprofundo-me no RFC2131 e confirmo este comportamento de concessões estáticas:

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

O motivo pelo qual eu não o encontrei antes porque " estático arrenda " chamado " permanente " dentro do RFC e Ctrl + F não possui AI integrada ( infelizmente)

Portanto, ainda estou procurando uma maneira prática de lidar com clientes que se desconectam da rede.

    
por 20.12.2013 / 16:11