KEA

Материал из ALT Linux Wiki
Примечание: Статья в процессе написания
Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.


Общая информация

Kea DHCP — это современный DHCP-сервер с открытым исходным кодом, разработанный ISC (Internet Systems Consortium). Он предназначен для автоматического назначения IP-адресов и конфигурации сетевых параметров (маска подсети, шлюз, DNS-серверы и т. д.) устройствам в сети.

Основные модули Kea DHCP:

  • Kea-DHCPv4 – сервер для IPv4.
  • Kea-DHCPv6 – сервер для IPv6.
  • Kea-DHCP-DDNS – интеграция с динамическим DNS для обновления записей. Также известен под названием D2 (сокращение от "DHCP-to-DNS").
  • Kea-Control Agent (CA) – REST API для управления сервером.
  • Kea-Hooks – поддержка модулей расширения (например, аутентификация, логирование, HA).

Решаемые задачи:

  • Автоматическая раздача IP-адресов в больших сетях.
  • Гибкая настройка DHCP (резервация адресов, классы клиентов).
  • Поддержка распределённых DHCP-архитектур (High Availability в нескольких конфигурациях).
  • Интеграция с внешними системами (базы данных, DNS, Radius, ...).
  • Масштабируемость и высокая производительность.

Kea пришёл на смену устаревшему ISC DHCP и предлагает более современные функции, включая JSON-конфигурацию и REST API.

Внимание! Все нижеописанное было актуально на лето 2025 года, для версии kea 2.7.8


Миграция из ISC DHCP

Предпочтительно, конечно, создать конфигурации с "чистого" листа. Но в случае с необходимостью переноса файлов аренды или конфигурации со старого ISC DHCP можно воспользоваться инструментом keama - (Kea Migrator Assistant)

Прежде чем начать

Ниже рассмотрим несколько конфигураций для одиночного dhcp сервера, для раздачи адресов ipv4. Все файлы конфигураций находятся в каталоге /etc/kea/ и представляют собой текстовые файлы в JSON формате - kea-dhcp4.conf, kea-dhcp6.conf, kea-ctrl-agent.conf, kea-dhcp-ddns.conf. Из названия файлов понятно, какую службу они конфигурируют.

Для проверки синтаксиса конфигурационных файлов можно использовать встроенный валидатор 

Пример запуска: kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

В случае ошибок в файле будет выведено место ошибки и причина 

Syntax check failed with: /etc/kea/kea-dhcp4.conf:2.1: syntax error, unexpected {, expecting Dhcp4

Также для работы с конфигурационным файлом можно использовать утилиту командной строки jq, для проверки синтаксиса, форматирования, вывода произвольных секций из файла. 

Пример запуска: jq '.' /etc/kea/kea-dhcp4.conf > /dev/null

Перенаправление в /dev/null нужно для фильтрации вывода самого текста JSON и вывода только ошибок. Если ошибка в синтаксисе есть, она будет выведена, в противном случае будет выведен отформатированная JSON разметка 

Пример ошибки: jq: parse error: Unfinished JSON term at EOF at line 102, column 0

Для вывода произвольной секции из JSON файла можно воспользоваться такой формой запуска jq 

Пример получения массива pools: jq '.Dhcp4.subnet4[].pools' /etc/kea/kea-dhcp4.conf

Вывод будет примерно такой 

[
  {
    "pool": "192.168.150.128 - 192.168.150.249"
  }
]

DHCP

Примеры конфигураций

Простой одиночный dhcp4 сервер

Исходные данные
Сеть 192.168.150.0/24
Диапазон 192.168.150.100 - 192.168.150.249
Шлюз 192.168.150.1
DNS сервера 192.168.150.10, 192.168.150.9
Поисковый домен test.alt

-

Примечание: Полный перечень опций (option-data) которые могут будут переданы клиенту можно посмотреть по ссылке - https://kea.readthedocs.io/en/kea-2.7.8/arm/dhcp4-srv.html#dhcp4-std-options-list


Файл конфигурации /etc/kea/kea-dhcp4.conf будет выглядеть примерно так 

{
  "Dhcp4": {
    "valid-lifetime": 86400,
    "renew-timer": 43200,
    "rebind-timer": 75600,

    "interfaces-config": {
      "interfaces": [
        "enp1s0"
      ]
    },
    
    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/run/kea/kea4-ctrl-socket"
    },
    
    "lease-database": {
      "type": "memfile",
      "name": "/var/lib/kea/kea-leases4.csv", 
      "lfc-interval": 600
    },
    
    "subnet4": [
      {
        "id": 150,
        "subnet": "192.168.150.0/24",
        "pools": [
          {
            "pool": "192.168.150.128 - 192.168.150.249"
          }
        ],
        "option-data": [
          {
            "name": "routers",
            "data": "192.168.150.1"
          },
          {
            "name": "domain-name-servers",
            "data": "192.168.150.10, 192.168.150.9"
          },
          {
            "name": "domain-name",
            "data": "test.alt"
          },
          {
            "name": "domain-search",
            "data": "test.alt"
          }
        ]
      }
    ]
  }
}

Если нужна резервация адресов, можно добавить блок reservations в описание нужного subnet.

Примечание: Для справедливости можно отметить, что можно резервирование не привязывать к subnet, а делать глобально. Подробнее - https://kea.readthedocs.io/en/kea-2.7.8/arm/dhcp4-srv.html#reservations4-tuning.


Конфигурация с резервированием адресов 

{
  "Dhcp4": {
    "valid-lifetime": 86400,
    "renew-timer": 43200,
    "rebind-timer": 75600,

    "interfaces-config": {
      "interfaces": [
        "enp1s0"
      ]
    },
    
    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/run/kea/kea4-ctrl-socket"
    },
    
    "lease-database": {
      "type": "memfile",
      "name": "/var/lib/kea/kea-leases4.csv", 
      "lfc-interval": 600
    },
    
    "subnet4": [
      {
        "id": 150,
        "subnet": "192.168.150.0/24",
        "pools": [
          {
            "pool": "192.168.150.128 - 192.168.150.249"
          }
        ],

        "reservations": [
            {
                "hw-address": "1a:1b:1c:1d:1e:1f",
                "ip-address": "192.168.150.102"
            } ],

        "option-data": [
          {
            "name": "routers",
            "data": "192.168.150.1"
          },
          {
            "name": "domain-name-servers",
            "data": "192.168.150.10, 192.168.150.9"
          },
          {
            "name": "domain-name",
            "data": "test.alt"
          },
          {
            "name": "domain-search",
            "data": "test.alt"
          }
        ]
      }
    ]
  }
}

Для каждого адреса в резервации можно задать свой набор опций (option-data)

Конфигурация с резервированием адресов 

{
....
 "reservations": [
            {
                "hw-address": "1a:1b:1c:1d:1e:1f",
                "ip-address": "192.168.150.102"
            } ,           
             {
            "hw-address": "BC:24:11:85:73:08",
            "ip-address": "192.168.150.155",
            "hostname": "fedoradc1",
            "option-data": [
              {
                "name": "routers",
                "data": "192.168.150.111"
              },
              {
                "name": "domain-name-servers",
                "data": "192.168.150.200"
              },
              {
                "name": "domain-search",
                "data": "myfedora.test"
              },

            ]
          }            
            ],

        "option-data": [
          {
            "name": "routers",
            "data": "192.168.150.1"
          },
          {
            "name": "domain-name-servers",
            "data": "192.168.150.10, 192.168.150.9"
          },
          {
            "name": "domain-name",
            "data": "test.alt"
          },
          {
            "name": "domain-search",
            "data": "test.alt"
          }
        ]
....

Высокая доступность (HA, High Availability )

Kea-DHCP поддерживает три режима работы HA, каждый из которых имеет свои особенности:

High Availability Mode
Режим Нагрузка Роли серверов Отказоустойчивость Использование
Load Balancing Распределяется между серверами Оба primary (активные) Автоматический переход при отказе Для балансировки нагрузки
Hot-Standby Только на основном сервере primary (активный) + standby (горячий резерв) Быстрый переход на резерв Для минимального простоя
Passive-Backup Только на основном сервере primary (активный) + backup (холодный резерв) Ручное переключение (или скрипты) Для редких аварийных случаев

Какой режим выбрать?

  • Нужна максимальная отказоустойчивость и производительность? ― Load Balancing
  • Важен быстрый переход при аварии, но без балансировки? ― Hot-Standby
  • Резервирование "на всякий случай"? ― Passive-Backup

Для большинства сценариев Hot-Standby — оптимальный вариант.

Рассмотрим два варианта Hot-Standby и Load Balancing, с синхронизацией файла аренды (leases database) встроенным механизмом LFC (Lease File Cleanup). При этом, сам файл не реплицируется между HA серверами, для этого используется http запросы. При необходимости, особенно при использовании в больших сетях, вы можете заменить LFC на работу с СУБД (mysql/mariadb, postgresql)

Hot-Standby

Исходные данные
Количество серверов 2 (192.168.150.10 (dc), 192.168.150.9 (dc2) )
Сеть 192.168.150.0/24
Диапазон 192.168.150.100 - 192.168.150.249
Шлюз 192.168.150.1
DNS сервера 192.168.150.10, 192.168.150.9
Поисковый домен test.alt

-

Для реализации механизма HA, нужно добавить воспользоваться библиотеками расширения (hooks library), а именно libdhcp_lease_cmds и libdhcp_ha.so. Ноды кластера будут общаться с собой по 8001 порту (не стоит использовать 8000 порт, он резервирован за kea-ctrl-agent)

Файл конфигурации первого сервера (роль primary). Из важных параметров стоит отметить в секции high-availability - имя сервера и режим работы 

"this-server-name": "dc",
"mode": "hot-standby"

Ниже идет описание самих узлов (секция peers)с указанием роли и адресом взаимодействия.

Таким образом полная конфигурация для primary узла принимает вид 

{
  "Dhcp4": {

    "valid-lifetime": 86400,
    "renew-timer": 43200,
    "rebind-timer": 75600,
      
    "interfaces-config": {
      "interfaces": [ "enp1s0" ]
    },

    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/run/kea/kea4-ctrl-socket"
    },

    "lease-database": {
      "type": "memfile",
      "lfc-interval": 60
    }, 

    "hooks-libraries": [{
        "library": "/usr/lib64/kea/hooks/libdhcp_lease_cmds.so",
        "parameters": { }
    },
    {
        "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
        "parameters": {

    "high-availability": [
      {
        "this-server-name": "dc",
        "mode": "hot-standby",
        "heartbeat-delay": 10000,
        "max-response-delay": 30000,
        "max-ack-delay": 500,
        "max-unacked-clients": 5,
        "max-rejected-lease-updates": 10,
        
        "peers": [
          {
            "name": "dc",
            "url": "http://192.168.150.10:8001/",
            "role": "primary",
            "auto-failover": true
          },
          {
            "name": "dc2",
            "url": "http://192.168.150.9:8001/",
            "role": "standby",
            "auto-failover": true
          }
        ]
      }
    ]
    }
    }],


    "subnet4": [
      {
        "id": 150,
        "subnet": "192.168.150.0/24",
        "pools": [
          {
            "pool": "192.168.150.128 - 192.168.150.249"
          }
        ],

        "reservations": [
            {
                "hw-address": "1a:1b:1c:1d:1e:1f",
                "ip-address": "192.168.150.102"
            } ],

        "option-data": [
          {
            "name": "routers",
            "data": "192.168.150.1"
          },
          {
            "name": "domain-name-servers",
            "data": "192.168.150.10, 192.168.150.9"
          },
          {
            "name": "domain-name",
            "data": "test.alt"
          },
          {
            "name": "domain-search",
            "data": "test.alt"
          },
          {
            "name": "time-servers",
            "data": "192.168.150.10,192.168.150.9"
          }
        ]
      }
    ]
  }
}

Для standby узла нужно поменять параметр this-server-name

Load Balancing

Исходные данные те же самые, что в примере выше (для host-standby). Основное отличие, что сервера работают параллельно тем самым снимая нагрузку с одного узла.

Полная конфигурация для первого (primary) хоста. Отличия от режима hot-standby в секциях high-availability и peers 

{
  "Dhcp4": {
    "valid-lifetime": 86400,
    "renew-timer": 43200,
    "rebind-timer": 75600,
      
    "interfaces-config": {
      "interfaces": [ "enp1s0" ]
    },

    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/run/kea/kea4-ctrl-socket"
    },

    "lease-database": {
      "type": "memfile",
      "lfc-interval": 60
    }, 

    "hooks-libraries": [
      {
        "library": "/usr/lib64/kea/hooks/libdhcp_lease_cmds.so",
        "parameters": { }
      },
      {
        "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
        "parameters": {
          "high-availability": [
            {
              "this-server-name": "dc",
              "mode": "load-balancing",
              "heartbeat-delay": 10000,
              "max-response-delay": 30000,
              "max-ack-delay": 500,
              "max-unacked-clients": 5,
              "max-rejected-lease-updates": 10,
              "sync-timeout": 60000,
              "sync-page-limit": 10000,
              
              "peers": [
                {
                  "name": "dc",
                  "url": "http://192.168.150.10:8001/",
                  "role": "primary",
                  "auto-failover": true
                },
                {
                  "name": "dc2",
                  "url": "http://192.168.150.9:8001/",
                  "role": "secondary",
                  "auto-failover": true
                }
              ]
            }
          ]
        }
      }
    ],

    "subnet4": [
      {
        "id": 150,
        "subnet": "192.168.150.0/24",
        "pools": [
          {
            "pool": "192.168.150.128 - 192.168.150.249"
          }
        ],
        "reservations": [
          {
            "hw-address": "1a:1b:1c:1d:1e:1f",
            "ip-address": "192.168.150.102"
          }
        ],
        "option-data": [
          {
            "name": "routers",
            "data": "192.168.150.1"
          },
          {
            "name": "domain-name-servers",
            "data": "192.168.150.10, 192.168.150.9"
          },
          {
            "name": "domain-name",
            "data": "test.alt"
          },
          {
            "name": "domain-search",
            "data": "test.alt"
          },
          {
            "name": "time-servers",
            "data": "192.168.150.10,192.168.150.9"
          }
        ]
      }
    ]
  }
}

Для второго узла (secondary), нужно поменять параметр this-server-name.

Стоит отметить, что для режима Load Balancing, кроме ролей primary и secondary есть еще роль backup.

Роль backup — это "третий резервный сервер", который:

  • Не участвует в балансировке нагрузки (в отличие от primary/secondary).
  • Активируется только при отказе обоих основных серверов (primary и secondary).
  • Не получает DHCP-запросы в штатном режиме.

Если оба сервера (primary и secondary) выйдут из строя, backup возьмет на себя обслуживание клиентов. Сервер с ролью backup может находиться в другом дата-центре, снижая риски при локальных авариях (геораспределение).

Пример описания блока high-availability с backup ролью 

"high-availability": [
  {
    "this-server-name": "dc1",
    "mode": "load-balancing",
    "peers": [
      {
        "name": "dc1",
        "url": "http://192.168.150.10:8001/",
        "role": "primary",
        "auto-failover": true
      },
      {
        "name": "dc2",
        "url": "http://192.168.150.9:8001/",
        "role": "secondary",
        "auto-failover": true
      },
      {
        "name": "dc3",
        "url": "http://192.168.150.8:8001/",
        "role": "backup",
        "auto-failover": true
      }
    ]
  }
]

Passive-Backup

В конфигураци Passive-Backup, пассивном резервном копировании, используется только один активный сервер (primary) и, как правило, один или несколько резервных серверов (backup). Также допускается конфигурация пассивного резервного копирования без резервных серверов, но она ничем не отличается от работы одного сервера без функции высокой доступности.

Конфигурация пассивного резервного копирования используется в ситуациях, когда администратор хочет использовать резервные серверы в качестве дополнительного хранилища для аренды адресов без использования полноценной системы отказоустойчивости. В этом случае при отказе основного сервера DHCP-сервис отключается и администратору требуется вручную перезапустить основной сервер для возобновления работы DHCP-сервиса. Администратор также может настроить один из резервных серверов для предоставления DHCP-сервиса клиентам, поскольку эти серверы должны иметь точную или почти точную информацию о выделенных арендах адресов.

Главное преимущество режима пассивного резервного копирования заключается в том, что он обеспечивает некоторую избыточность информации об аренде адресов, но при этом обеспечивает более высокую производительность ответа основного сервера на DHCP-запросы. Основному серверу не нужно ждать подтверждения обновлений аренды от резервных серверов, прежде чем отправлять ответ DHCP-клиенту. Это сокращает время отклика по сравнению со случаями балансировки нагрузки и горячего резерва, в которых сервер, отвечающий на DHCP-запрос, должен ждать подтверждения от другого активного сервера, прежде чем он сможет ответить клиенту.

Конфигурация primary узла 

{
  "Dhcp4": {

    "valid-lifetime": 86400,
    "renew-timer": 43200,
    "rebind-timer": 75600,
      
    "interfaces-config": {
      "interfaces": [ "enp1s0" ]
    },

    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/run/kea/kea4-ctrl-socket"
    },

    "lease-database": {
      "type": "memfile",
      "lfc-interval": 60
    }, 

    "hooks-libraries": [
    {
        "library": "/usr/lib64/kea/hooks/libdhcp_lease_cmds.so",
        "parameters": { }
    },
    {
        "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
        "parameters": {

    "high-availability": [
      {
        "this-server-name": "dc",
        "mode": "passive-backup",
        "heartbeat-delay": 10000,
        "max-response-delay": 30000,
        "wait-backup-ack": false,
        "peers": [
          {
            "name": "dc",
            "url": "http://192.168.150.10:8001/",
            "role": "primary"
          },
          {
            "name": "dc2",
            "url": "http://192.168.150.9:8001/",
            "role": "backup"
          }
        ]
      }
    ]
    }
    }],


    "subnet4": [
      {
        "id": 150,
        "subnet": "192.168.150.0/24",
        "pools": [
          {
            "pool": "192.168.150.128 - 192.168.150.249"
          }
        ],

        "reservations": [
            {
                "hw-address": "1a:1b:1c:1d:1e:1f",
                "ip-address": "192.168.150.102"
            } ],

        "option-data": [
          {
            "name": "routers",
            "data": "192.168.150.1"
          },
          {
            "name": "domain-name-servers",
            "data": "192.168.150.10, 192.168.150.9"
          },
          {
            "name": "domain-name",
            "data": "test.alt"
          },
          {
            "name": "domain-search",
            "data": "test.alt"
          },
          {
            "name": "time-servers",
            "data": "192.168.150.10,192.168.150.9"
          }
        ]
      }
    ]
  }
}

Для второго узла (backup) достаточно поменять опцию this-server-name

DHCP-DDNS

Вариантов настройки обновления записей DNS несколько. Все зависит от того, какой DNS сервер используется. Рассмотрим два варианта

SAMBA DNS (SAMBA_INTERNAL в SAMBA AD)

BIND9

Агент управления

kea-ctrl-agent — это веб-сервис (REST API), который предоставляет безопасный и стандартизированный способ удалённого управления другими компонентами Kea (DHCPv4, DHCPv6, DDNS) и получения от них статистики. Все общение с сервисом происходит в формате JSON.

Конфигурационный файл /etc/kea/kea-ctrl-agent.conf

Простейшая конфигурация, без авторизации, для всех интерфейсов 

{
"Control-agent": {
    "http-host": "0.0.0.0",
    "http-port": 8000,
    "control-sockets": {
        "dhcp4": {
            "socket-type": "unix",
            "socket-name": "kea4-ctrl-socket"
        },
        "dhcp6": {
            "socket-type": "unix",
            "socket-name": "kea6-ctrl-socket"
        },
        "d2": {
            "socket-type": "unix",
            "socket-name": "kea-ddns-ctrl-socket"
        }
    },
    "hooks-libraries": [
    ],
    "loggers": [
    {
        "name": "kea-ctrl-agent",
        "output-options": [
            {
                "output": "stdout",
                "pattern": "%-5p %m\n"
            }
        ],
        "severity": "INFO",
        "debuglevel": 0
    }
  ]
}
}

Примеры получения информации

Доступные команды 

[root@dc kea]#  curl -s -X POST http://192.168.150.10:8000/ -H "Content-Type: application/json" -d '{"command":"list-commands"}' | jq

[
  {
    "arguments": [
      "build-report",
      "config-get",
      "config-hash-get",
      "config-reload",
      "config-set",
      "config-test",
      "config-write",
      "list-commands",
      "shutdown",
      "status-get",
      "version-get"
    ],
    "result": 0
  }
]

Выданные ipv4 адреса 

[root@dc kea]#  curl -s -X POST http://192.168.150.10:8000/ -H "Content-Type: application/json" -d '{"command":"lease4-get-all",  "service": ["dhcp4"] }' | jq

[
  {
    "arguments": {
      "leases": [
        {
          "cltt": 1760518975,
          "fqdn-fwd": true,
          "fqdn-rev": true,
          "hostname": "host-16.test.alt",
          "hw-address": "52:54:00:17:6c:76",
          "ip-address": "192.168.150.128",
          "state": 0,
          "subnet-id": 150,
          "valid-lft": 86400
        },
        {
          "client-id": "01:52:54:00:73:6d:94",
          "cltt": 1760518971,
          "fqdn-fwd": true,
          "fqdn-rev": true,
          "hostname": "host-15.test.alt",
          "hw-address": "52:54:00:73:6d:94",
          "ip-address": "192.168.150.227",
          "state": 0,
          "subnet-id": 150,
          "valid-lft": 86400
        }
      ]
    },
    "result": 0,
    "text": "2 IPv4 lease(s) found."
  }
]

Получение текущего конфига kea-dhcp4 

[root@dc kea]#  curl -s -X POST http://192.168.150.10:8000/ -H "Content-Type: application/json" -d '{"command": "config-get", "service": ["dhcp4"] }' | jq

Применение нового конфигурационного файла (new-config.conf) 

curl -X POST http://192.168.150.10:8000/ -H "Content-Type: application/json" -d @new-config.json
Внимание! Формат нового файла должен начинатся с указания команды, сервиса, и полного нового конфига. Если каких то опций в конфиге не будет (к примеру вы отправите только секцию option-data, то сервис будет неработоспособен) 
{ 
 "command": "config-set",
 "service": ["dhcp4"], 
 "arguments": {
   "Dhcp4": {
   // и здесь, все что касается новой настройки dhcp4
  }
}
Внимание! Важная информация
  • config-set - применяет конфигурацию в памяти (без записи в файл)
  • Для сохранения в файл используйте config-write - сохраняет текущую конфигурацию из памяти в файл.
  • Всегда проверяйте config-get конфигурацию перед применением

Для разграничения доступа к разным командам служит секция authentication в конфигурации Control Agent (kea-ctrl-agent.conf) 

.....
"authentication": {
            "type": "basic",
            "realm": "Kea Control Agent",
            "clients": [
                {
                    "user": "admin",
                    "password": "secret123",
                    "user-context": {
                        "allowed-commands": ["*"]
                    }
                },
                {
                    "user": "operator", 
                    "password": "readonly123",
                    "user-context": {
                        "allowed-commands": ["config-get", "lease4-get-all", "lease4-get", "stat-lease4-get", "version-get", "status-get", "list-commands"]
                    }
                },
                {
                    "user": "monitor",
                    "password": "monitor123", 
                    "user-context": {
                        "allowed-commands": ["lease4-get-all", "lease4-get", "stat-lease4-get", "version-get", "status-get"]
                    }
                }
            ]
        },
.....

Таким образом мы создали, разные учетные записи, с доступом к разным командам. Использование выглядит так 

curl -u monitor:monitor123 -X POST http://192.168.150.10:8000/ -H "Content-Type: application/json" -d '{ "command": "config-get","service": ["dhcp4"] }'

Кроме allowed-commands, можно добавить allowed-services, для уточнения к каким сервисам данная команда может применятся.

Логины, пароли также можно хранить не в открытом виде, а в специальном файле (chmod 0600, chown _kea:_kea) 

....
  "authentication": {
        "type": "basic",
        "realm": "Kea Control Agent",
        "directory": "/etc/kea",
        "clients": [
            {
                "user": "kea-api", 
                "password-file": "kea-api-password.txt" 
           }
        ]
    }      
...

HOOKS

Hooks libraries (библиотеки хуков) в Kea DHCP позволяют расширять и настраивать поведение DHCP-сервера без модификации его исходного кода. Они дают возможность выполнять пользовательские сценарии при определённых событиях, что делает Kea гибким и адаптируемым под различные задачи.

Доступные хуки находятся в пакете kea-hooks и на момент написания статьи это следующий список. Из названия библиотеки можно понять реализуемый ей функционал 

$ rpm -ql kea-hooks | awk -F '/' '/.so/ {print $NF}'
libddns_gss_tsig.so
libdhcp_bootp.so
libdhcp_class_cmds.so
libdhcp_ddns_tuning.so
libdhcp_flex_id.so
libdhcp_flex_option.so
libdhcp_ha.so
libdhcp_host_cache.so
libdhcp_host_cmds.so
libdhcp_lease_cmds.so
libdhcp_lease_query.so
libdhcp_legal_log.so
libdhcp_limits.so
libdhcp_mysql.so
libdhcp_perfmon.so
libdhcp_pgsql.so
libdhcp_ping_check.so
libdhcp_radius.so
libdhcp_run_script.so
libdhcp_stat_cmds.so 
libdhcp_subnet_cmds.so

Пример работы с hook library

В качестве наглядного примера работы - выберем библиотеку libdhcp_run_script, которая позволяет вызывать свои обработчики на разные события в работе kea-dhcp. Попробуем отследить события выдачи адреса ipv4 и записать это в отдельный файл.

Для этого в блок hooks-libraries добавим загрузку нужной нам библиотеки libdhcp_run_script с двумя параметрами:

  • name - это сам скрипт который будет вызван
  • sync - нужно ли ждать завершения работы скрипта, укажем что нет т.е. false
...
 "hooks-libraries": [
    {
        "library": "/usr/lib64/kea/hooks/libdhcp_run_script.so",
        "parameters": {
          "name": "/etc/kea/dhcp-lease-logger.sh",
          "sync": false,
        }
     }
 ]
...

Текст скрипта приложен ниже. Название события передается скрипту в первом параметре при вызове, используемые переменные для каждого события описаны в документации к библиотеке - https://kea.readthedocs.io/en/kea-2.7.8/arm/hooks.html#libdhcp-run-script-so-run-script-support-for-external-hook-scripts 

#!/bin/bash

lease4_renew() {
 echo "$(date): DHCP renew - IP ${LEASE4_ADDRESS}, MAC ${QUERY4_HWADDR}" >> /var/log/kea-leases.log
}

case "$1" in
    "lease4_renew")
        lease4_renew
        ;;
esac

не забываем дать права на файл /var/log/kea-leases.log пользователю _kea и сделать скрипт исполняемым. 

[root@dc kea]# chmod +x /etc/kea/dhcp-lease-logger.sh
[root@dc kea]# touch /var/log/kea-leases.log
[root@dc kea]# chown _kea: /var/log/kea-leases.log

Перезапускаем службу kea-dhcp4 и видим в файле /var/log/kea-leases.log регистрацию наших событий. 

[root@dc kea]# tail -1 /var/log/kea-leases.log
Wed Jul 16 11:16:05 +05 2025: DHCP renew - IP 192.168.150.227, MAC 52:54:00:73:6d:94

Внешние ссылки