☰

DHCPD очищает аренду при отключении клиента

tag-icon • tag-icon linux networking dhcp dhcpd
DHCPD очищает аренду при отключении клиента

Есть ли способ заставить ISC DHCPD инициировать истечение срока действия или освобождение статической аренды сразу после отключения клиента?

Я хочу запустить скрипт сразу после подключения клиента (событие DHCPD «при фиксации») и отключения (событие DHCPD «при истечении срока действия» или «при освобождении»).

В то время как первое работает как по маслу, последнее никогда не срабатывает. Есть какие-нибудь советы?

РЕДАКТИРОВАТЬ: Фрагмент конфигурации (с тестовым скриптом):

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

решение1

Если я правильно понял, для создания статической аренды у вас в конфигурации есть что-то вроде этого:

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

Это будет работать так, как вы ожидаете, но никогда не освободит этот IP-адрес (неважно, отправляет ли клиент DHCPRELEASE или нет), поскольку с точки зрения dhcpd это СТАТИЧЕСКИЙ IP-адрес.

Вам необходимо создать ДИНАМИЧЕСКИЙ IP (опять же, с точки зрения dhcpd), чтобы dhcpd отслеживал его. Вы можете сделать это так:

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

Чтобы сделать конфигурацию более гибкой, вы можете поместить объявления class-subclass и pool-range в разные файлы ивключатьих в основной dhcpd.conf

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

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

Как вы можете видеть, мы поместили каждого клиента в его собственный класс И подклассифицировали его в класс "static-ip". Это на случай, если вам нужна другая подсеть без назначения статического IP, например:

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

Затем вы должны запретить клиентам со статическим назначением IP-адресов получать IP-адреса из этой подсети (сотрицатьключевое слово).

Таким образом вы получаете ДИНАМИЧЕСКИЙ IP (с точки зрения DHCPD), но на самом деле он никогда не изменится (с точки зрения клиента)

решение2

DHCP обычно сохраняет аренду до истечения срока действия, пытаясь повторно выдать ту же аренду клиенту, который подключается позже. Он начнет освобождать кандидатов только тогда, когда на область действия будет оказываться давление со стороны новых клиентов.

Это позволяет клиентам повторно получать тот же адрес при повторном подключении без слишком большого интервала между сеансами и создает видимость почти статической адресации.

Возможно, ваши скрипты не срабатывают (по замыслу) до истечения таймера. Вы можете попытаться форсировать это, либо увеличив конкуренцию в области действия, либо сократив длительность таймера, чтобы ускорить процесс.

решение3

Благодаря @TomTom я глубже изучил RFC2131 и подтвердил следующее поведение статической аренды:

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

Причина, по которой я не нашел его раньше, заключается в следующем: "статическая аренда" называется "постоянный" внутри RFC и Ctrl+F не имеет встроенного ИИ (к сожалению)

Поэтому я все еще ищу работающий способ работы с клиентами, которые отключаются от сети.

Связанный контент