DHCP-сервер Kea: настройка адресов в локальной сети

Когда устройств становится больше нескольких, ручная настройка IP быстро превращается в источник конфликтов: два компьютера получают один адрес, на ноутбуке остаётся старый шлюз, а принтер после перезагрузки оказывается недоступен. DHCP решает эту задачу централизованно: клиент получает адрес и параметры сети на ограниченный срок — аренду.

В этом руководстве настроим DHCPv4 на базе ISC Kea и разберём, что происходит при выдаче адреса. Работайте сначала в изолированной виртуальной сети или лабораторном VLAN. Второй DHCP-сервер в рабочем сегменте способен выдать клиентам неверный шлюз и DNS. Не запускайте пример в производственной сети без согласования с администратором и проверки, какой сервер уже обслуживает сегмент.

Что DHCP передаёт клиенту

Минимально клиенту нужен IPv4-адрес и маска. Обычно сервер также сообщает маршрут по умолчанию и DNS-серверы. Дополнительно могут передаваться доменное имя, NTP, параметры загрузки и другие опции. DHCP не создаёт маршрутизацию и не настраивает DNS-сервис: он лишь сообщает клиенту значения. Если указать адрес несуществующего резолвера, аренда будет успешной, но имена перестанут открываться.

Первичное взаимодействие часто описывают как DORA: Discover, Offer, Request, Acknowledgement. Клиент ищет сервер, получает предложение, выбирает его и запрашивает аренду, после чего сервер подтверждает параметры. На продлении обмен может быть короче и сначала идти напрямую известному серверу. DHCPv4 использует UDP-порты 67 на сервере и 68 на клиенте.

План лабораторной сети

Возьмём отдельную сеть 192.168.50.0/24. Маршрутизатор имеет адрес 192.168.50.1, сервер Kea — 192.168.50.2, а реально настроенный локальный DNS — 192.168.50.53. Динамический пул займёт диапазон 192.168.50.100–192.168.50.199. Принтеру зарезервируем 192.168.50.20, то есть адрес вне динамического пула.

Перед настройкой убедитесь, что интерфейс сервера имеет постоянный адрес 192.168.50.2/24. DHCP-сервер не должен зависеть от аренды, которую сам выдаёт. Проверить текущее состояние можно командами:

ip -br address
ip route
ss -lunp | grep ':67 '

Последняя команда помогает обнаружить уже запущенный DHCPv4-процесс. Не завершайте неизвестную службу на рабочем сервере: выясните её назначение и владельца.

Установка и структура конфигурации

В Debian и Ubuntu имя пакета и службы зависит от версии дистрибутива. Обычно пакет называется kea-dhcp4-server, а конфигурация располагается в /etc/kea/kea-dhcp4.conf. Сначала сверяйте имена с репозиторием вашей ОС:

apt-cache policy kea-dhcp4-server
systemctl list-unit-files 'kea*'

Ниже — законченный пример для лаборатории. Замените enp1s0 на реальное имя интерфейса. JSON Kea строг к запятым и кавычкам, поэтому не редактируйте конфигурацию вслепую.

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "enp1s0" ]
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv"
    },
    "valid-lifetime": 3600,
    "renew-timer": 900,
    "rebind-timer": 1800,
    "subnet4": [
      {
        "id": 1,
        "subnet": "192.168.50.0/24",
        "pools": [
          { "pool": "192.168.50.100 - 192.168.50.199" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.168.50.1" },
          { "name": "domain-name-servers", "data": "192.168.50.53" }
        ],
        "reservations": [
          {
            "hw-address": "02:00:00:00:00:20",
            "ip-address": "192.168.50.20"
          }
        ]
      }
    ]
  }
}

Адрес 02:00:00:00:00:20 — вымышленный локально администрируемый MAC для примера. Возьмите MAC лабораторного клиента из ip link. Каталог базы аренд должен существовать и быть доступен пользователю службы Kea; не расширяйте права до 777. Сравните владельца с другими файлами пакета и рекомендациями дистрибутива.

Проверка до запуска

Kea умеет проверять синтаксис и часть логики без запуска демона:

sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

Успешная проверка не доказывает, что интерфейс существует, порт свободен, шлюз доступен, а DNS отвечает. Поэтому дополнительно проверьте интерфейс, маршруты и реальные сервисы. После успешного теста перезапустите именно найденную ранее службу, например:

sudo systemctl restart kea-dhcp4-server
sudo systemctl status kea-dhcp4-server --no-pager
sudo journalctl -u kea-dhcp4-server -n 50 --no-pager
sudo ss -lunp | grep ':67 '

Если в вашей ОС unit называется иначе, используйте его фактическое имя. Не запускайте одновременно сервис systemd и второй экземпляр kea-dhcp4 вручную.

Проверка с клиента

Подключите одну тестовую машину к изолированному сегменту и запросите аренду штатными средствами её ОС. На Linux сначала определите, NetworkManager, systemd-networkd или другой менеджер управляет интерфейсом. После получения адреса проверьте:

ip -br address
ip route
resolvectl status
ping -c 2 192.168.50.1
resolvectl query example.com

Ожидаемый адрес должен входить в пул, маршрут по умолчанию — вести через 192.168.50.1, а DNS — указывать только на действительно работающий 192.168.50.53. Если IP получен, но шлюз недоступен, проблема находится не в DNS. Если шлюз доступен, запрос по IP проходит, а имя нет — исследуйте DNS-опцию и резолвер.

Аренда, продление и исчерпание пула

valid-lifetime определяет срок аренды, а таймеры обновления и перепривязки задают моменты повторных попыток. Короткие аренды увеличивают служебный обмен, очень длинные медленно освобождают адреса ушедших устройств. Значения выбирают по характеру сегмента: гостевой Wi‑Fi и стабильная серверная сеть имеют разные требования.

Если пул исчерпан, увеличение срока аренды только усугубит ситуацию. Сначала посчитайте размер подсети и реально занятые аренды, найдите аномальное число клиентов, затем расширяйте пул или проектируйте новую подсеть. Не включайте в пул статические адреса маршрутизаторов, серверов и оборудования, если не используете согласованный механизм резервирования.

Несколько VLAN и DHCP relay

DHCP Discover изначально является широковещательным и маршрутизаторы обычно не пересылают его между подсетями. Для обслуживания нескольких VLAN применяют DHCP relay на маршрутизаторе или L3-коммутаторе. Relay передаёт серверу сведения о сегменте, чтобы Kea выбрал подходящий блок subnet4. Для каждого VLAN нужны отдельная подсеть, уникальный пул и правильный шлюз.

Размещать по DHCP-серверу в каждом VLAN необязательно. Но правила межсетевого экрана должны разрешать строго необходимый обмен relay с сервером. Не открывайте DHCP из интернета и не включайте сервер на интерфейсах, которые он не должен обслуживать.

Типичные ошибки

• Клиент получает адрес 169.254.x.x. Это link-local после неудачного получения аренды. Проверяйте VLAN, интерфейс Kea, порт 67, relay и журнал.
• Выдаётся неверный шлюз. Ищите второй DHCP-сервер и сравните данные аренды, а не только конфигурацию Kea.
• Резервирование не срабатывает. Проверьте идентификатор клиента, MAC и политику резервирований. Некоторые клиенты используют Client Identifier, а Wi‑Fi-устройства могут рандомизировать MAC.
• Служба не стартует. Сначала выполните -t, затем читайте журнал. Частые причины — неверный JSON, отсутствующий интерфейс, права на базу аренд и занятый порт.

Контрольный список перед рабочим внедрением

1. Сохранить резервную копию действующей конфигурации и базы аренд.
2. Зафиксировать подсеть, исключения, шлюз, DNS и время аренды.
3. Проверить конфигурацию Kea командой -t.
4. Испытать один клиент в отдельном VLAN.
5. Проверить журнал, выдачу адреса, маршрут, DNS и доступ к нужным сервисам.
6. Подготовить откат и окно изменений, затем подключать остальных клиентов.

Частые вопросы

DHCP назначает статический IP?

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

Можно ли поставить DNS равным адресу роутера?

Только если роутер действительно принимает DNS-запросы клиентов и корректно их обрабатывает. Сам факт наличия адреса шлюза этого не гарантирует.

Нужен ли DHCP для IPv6?

IPv6 может использовать Router Advertisement и SLAAC, DHCPv6 или их сочетание. Это отдельная архитектура; нельзя механически переносить роли DHCPv4 на IPv6.

Связанные материалы: расчёт подсетей и VLSM, диагностика DNS и настройка сети Linux через Netplan.

Документация

• RFC 2131: DHCP.
• ISC Kea: руководство DHCPv4.
• ISC Kea: конфигурация.

Статья может содержать партнёрские ссылки. Это не влияет на стоимость для вас, но помогает развивать блог.