Dhcpd freebsd dhcpd conf

Dhcpd freebsd dhcpd conf

DHCP, или Dynamic Host Configuration Protocol (Протокол Динамической Конфигурации Хостов), описывает порядок, по которому система может подключиться к сети и получить необходимую информацию для работы в ней. Во FreeBSD используется реализация DHCP от ISC (Internet Software Consortium), так что вся информация, описывающая особенности, зависящие от реализации, относится к дистрибутиву ISC.

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

Когда на клиентской машине выполняется программа dhclient , являющаяся клиентом DHCP, она начинает широковещательную рассылку запросов на получение настроечной информации. По умолчанию эти запросы делаются на 68 порт UDP. Сервер отвечает на UDP 67, выдавая клиенту адрес IP и другую необходимую информацию, такую, как сетевую маску, маршрутизатор и серверы DNS. Вся эта информация даётся в форме «аренды» DHCP и верна только определенное время (что настраивается администратором сервера DHCP). При таком подходе устаревшие адреса IP тех клиентов, которые больше не подключены к сети, могут автоматически использоваться повторно.

Клиенты DHCP могут получить от сервера очень много информации. Подробный список находится в странице Справочника dhcp-options (5) .

Клиент DHCP от ISC, dhclient , полностью интегрирован во FreeBSD. Поддержка клиента DHCP есть как в программе установки, так и в самой системе, что исключает необходимость в знании подробностей конфигурации сети в любой сети, имеющей сервер DHCP. Утилита dhclient включена во все версии FreeBSD, начиная с 3.2.

DHCP поддерживается утилитой sysinstall . При настройке сетевого интерфейса из программы sysinstall первый вопрос, который вам задается, это «Do you want to try DHCP configuration of this interface?» ( «Хотите ли вы попробовать настроить этот интерфейс через DHCP?» ). Утвердительный ответ приведёт к запуску программы dhclient , и при удачном его выполнении к автоматическому заданию информации для настройки интерфейса.

Есть две вещи, которые вы должны сделать для того, чтобы ваша система использовала DHCP при загрузке:

Убедитесь, что устройство bpf включено в компиляцию вашего ядра. Чтобы это сделать, добавьте строчку pseudo-device bpf в конфигурационный файл ядра и перестройте ядро. Более подробная информация о построении ядер имеется в разделе Chapter 9 .

Устройство bpf уже является частью ядра GENERIC , которое поставляется вместе с FreeBSD, так что, если вы не используете другое ядро, то вам и не нужно его делать для того, чтобы работал DHCP.

Note: Те, кто беспокоится о безопасности, должны иметь в виду, что устройство bpf является также тем самым устройством, которое позволяет работать программам-снифферам пакетов (хотя для этого они должны быть запущены пользователем root ). Наличие устройства bpf необходимо для использования DHCP, но если вы чересчур беспокоитесь о безопасности, то вам нельзя добавлять устройство bpf в ядро только для того, чтобы в неопределённом будущем использовать DHCP.

Отредактируйте ваш файл /etc/rc.conf , включив в него следующее:

Note: Обязательно замените fxp0 именем интерфейса, который вы хотите настроить динамически.

Если dhclient в вашей системе находится в другом месте или если вы хотите задать дополнительные параметры для dhclient , то также укажите следующее (изменив так, как вам нужно):

dhclient требует наличия конфигурационного файла, /etc/dhclient.conf . Как правило, файл содержит только комментарии, а настройки по умолчанию достаточно хороши. Этот настроечный файл описан на страницах справочной системы по dhclient.conf (5) .

dhclient скомпонован статически и находится в каталоге /sbin . На страница Справочника dhclient (8) дается более подробная информация о dhclient .

dhclient-script является специфичным для FreeBSD скриптом настройки клиента DHCP. Он описан в dhclient-script (8) , но для нормального функционирования никаких модификаций со стороны пользователя не требуется.

В этом файле клиент DHCP хранит базу данных выданных к использованию адресов в виде журнала. На странице dhclient.leases (5) дается гораздо более подробное описание.

Этот раздел даёт информацию о том, как настроить систему FreeBSD для работы в качестве сервера DHCP на основе реализации пакета DHCP от ISC (Internet Software Consortium).

Для того, чтобы настроить систему FreeBSD на работу в качестве сервера DHCP, вам необходимо обеспечить присутствие устройства bpf (4) , вкомпилированного в ядро. Для этого добавьте строку pseudo-device bpf в файл конфигурации вашего ядра. Для получения более полной информации о построении ядер, обратитесь к Chapter 9 .

Устройство bpf уже входит в состав ядра GENERIC , поставляемого с FreeBSD, так что вам не нужно создавать собственное ядро для обеспечения работы DHCP.

Note: Те, кто обращает особое внимание на вопросы безопасности, должны заметить, что bpf является тем устройством, что позволяет нормально работать снифферам пакетов (хотя таким программам требуются привилегированный доступ). Наличие устройства bpf обязательно для использования DHCP, но если вы очень обеспокоены безопасностью, наверное, вам не нужно включать bpf в ваше ядро только потому, что в отдалённом будущем вы собираетесь использовать DHCP.

dhcpd.conf состоит из деклараций относительно подсетей и хостов, и проще всего описывается на примере:

Как только вы закончите составлять свой dhcpd.conf , вы можете продолжить работу запуском сервера при помощи следующей команды:

Если в будущем вам понадобится сделать изменения в настройке вашего сервера, то важно заметить, что посылка сигнала SIGHUP приложению dhcpd не приведёт к перезагрузке настроек, как это бывает для большинства даемонов. Вам нужно послать сигнал SIGTERM для остановки процесса, а затем перезапустить его при помощи вышеприведённой команды.

dhcpd скомпонован статически и расположен в каталоге /usr/local/sbin . Страницы справочной системы dhcpd(8), устанавливаемые портом, содержат более полную информацию о dhcpd .

dhcpd требует наличия конфигурационного файла, /usr/local/etc/dhcpd.conf , до того, как он будет запущен и начнёт предоставлять сервис клиентам. Необходимо, чтобы этот файл содержал все данные, которая будет выдаваться обслуживаемым клиентам, а также информацию о работе сервера. Этот конфигурационный файл описывается на страницах справочной системы dhcpd.conf(5), которые устанавливаются портом.

Читайте также:  Инструкция по установке принтера hp laser mfp 135w

Сервер DHCP ведёт базу данных выданной информации в этом файле, который записывается в виде протокола. Страницы справочной системы dhcpd.leases(5), устанавливаемые портом, дают гораздо более подробное описание.

dhcrelay используется в сложных ситуациях, когда сервер DHCP пересылает запросы от клиента другому серверу DHCP в отдельной сети. На страницах справочной системы dhcrelay(8), которые устанавливаются с портом, даётся более полное описание.

Источник

Руководство по dhcpd.conf

Содержание

ЧТО ЭТО ?

dhcpd.conf — файл конфигурации демона dhcpd

ОПИСАНИЕ

Файл dhcpd.conf содержит информацию о настройках
dhcpd, сервера DHCP разработанного в ISC

Файл dhcpd.conf имеет простой текстовый формат. Разбор файла производится
встроенным в dhcpd парсером. Файл может содержать дополнительные пробелы,
символы табуляции и пустые строки для придания более читабельного вида.
Ключевые слова не чувствительны к регистру. Комментарии могут располагаться
в любом месте, он только не в кавычках. Комментарии начинаются с символа #
и продолжаются до конца строки.

По существу файл состоит из секций-объявлений вида: имя_секции <…>.
В фигурных скобках могут быть заключены другие секции(подсекции) и параметры

Параметры используются для что бы определить поведение сервера:

  • что и как делать (например на какой срок выдавать адрес)
  • делать ли вообще (например выдавать ли адреса неизвестным клиентам)
  • какие дополнительные параметры, кроме IP адреса, предоставлять клиенту
    (например шлюз по умолчанию или адреса серверов DNS).

Секции-объявления используются для:

  • описания топологии сети
  • описания клиентов сети
  • описания адресов которые должны предоставлены клиентам
  • присвоить группу параметров одновременно в нескольким секциям

При присвоении параметров нескольким секциям одновременно, все параметры должны быть
определены перед определением любых секций зависящих от этих параметров.

Секции описывающие топологию сети включают следующие подсекции:

shared-network и subnet.
Если клиентам в подсети адреса назначаются динамически, то
инструкция range должна быть использована в секции
subnet. Для клиентов со статически назначенными адресами, или для конфигураций
в которых обслуживаются только известные клиенты, для каждого из них должен быть
описан параметр host
Если необходимо присвоить значения параметрам, в нескольких подсекциях,
которые не сгруппированы на основе принадлежности к одной подсети, то их можно
сгруппировать, поместив в секцию group.

Для каждой обслуживаемой подсети, и для каждой подсети к которой подключен dhcp сервер,
должны быть объявлены секции subnet, которые говорят серверу как распознать
какой адрес к какой подсети относится. Секция subnet требуется для каждой подсети
даже если в ней нет динамически выделяемых адресов.

Иногда случается что в одном физическом сегменте сосуществуют несколько IP подсетей.
Например в организации существует требование использовать 8-битные маски подсетей,
но сеть разрослась до размеров превышающих 254 хоста, в этом случае необходимо использовать
две подсети с 8-битными масками до тех пор пока новый ethernet сегмент не будет добавлен.
В этом случае секции subnet описывающие две эти подсети могут быть заключены в
секцию shared-network.

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

Когда клиент загружается, начальные параметры определяются в соответствующем клиенту
объявлении host, затем проверяется секция group (если она существует)
которая содержит в себе host, далее проверяется секция subnet соответствующая
подсети в которой находится клиент, после этого проверяется указаны ли какие-нибудь параметры
в секции shared-network(если есть), содержащей нашу подсеть, ну и наконец
проверяются глобальные параметры, которые могут быть указаны перед всеми объявлениями.

Когда dhcpd ищет секцию host для соответствующего клиента, он следует
следующим правилам:
сперва ищется объявление host где указан параметр fixed-address
и секция subnet или shared network совпадает с подсетью в которой
находится клиент. Если нет соответствующих записей, dhcpd ищет объявление host
без параметра fixed-address. Если подходящих записей не найдено, то dhcpd считает
что нет записей для этого клиента, даже если они есть для этого клиента в другой подсети.

ПРИМЕРЫ

Типичный файл dhcpd.conf выглядит примерно так:

Первая строка в примере — место для глобальных параметров. Это может быть
доменное имя организации, адреса DNS серверов (если они едины в пределах организации) и т.д.
Например

Как видно в примере 2, возможно задание адресов хостов через доменные имена
вместо цифровой записи IP адресов. Если разрешение указанного имени дает более
одного IP адреса (такое случается :), оба адреса предоставляются клиенту.

В примере 1 видно, что как секция shared-network так и секция subnet
могут иметь собственные параметры. Например сеть ISC-BIGGIE
принадлежит целому подразделению, например отделу учета и если этот
отдел в имеет собственный DNS-домен, то среди параметров специфических
для секции shared-network нужно было бы указать:

Ко всем подсетям объявленным в секции shared-network будет относиться
опция domain-name со значением «accounting.isc.org»
в отличие от «isc.org».

Наиболее очевидной причиной наличия
subnet-specific параметров является
наличие в каждой подсети собственного шлюза, к примеру в каждой секции
subnet должен быть указан параметр вида:

В последнем параметре адрес указан в числовой форме — это не обязательно,
если у вас определены различные имена для каждого интерфейса маршрутизатора,
то предпочтительнее указать именно имя. Однако во многих случаях есть только
одно имя для всех IP адресов маршрутизатора, и использование этого имени
в параметре routers становиться не возможным.

В примере
1 присутствует секция group, которая позволяет
задать параметры для трех хостов — zappo, beppo и harpo.
Как видите эти хосты находятся в домене test.isc.org. Используя объявление
group можно переопределить имя домена для указанных хостов:

Читайте также:  How to install exe on linux

Так же, учитывая имя домена(test), проведем эксперимент и исследуем
механизм выделения адресов сервером DHCP — установим некоторые
значения значительно меньше чем по умолчанию:

Как вы наверное заметили одни параметры начинаются с ключевого слова
option,
а другие нет. Параметры начинающиеся с option
соответствуют реальным параметрам, которые передаются клиентам.
Те же параметры что не начинаются на option используются
для управления поведением сервера DHCP (например на какой срок выдаются
адреса) или для указания параметров которые не являются опциональными
в протоколе DHCP (например server-name и filename).

В примере 1, каждый хост имеет
host-specific параметры.
Это может быть опция hostname, задающая имя хоста,
имя файла для загрузки (filename параметр) и адрес сервера
с которого этот файл должен быть загружен (next-server параметр).
Любой параметр может быть указан в любом месте где он имеет смысл, и
область действия параметра определяется секцией в которой он появляется.

Представте себе что у вас куча NCD X-Terminals разных моделей и Вы желаете
указать загрузочные файлы для каждой модели. Один из путей сделать это —
создать секции host для каждого терминала и используя объявление
group сгруппировать их по моделям:

ОБЪЯВЛЕНИЯ

Секция shared-network сообщает серверу DHCP что несколько IP-подсетей
используют один физический сегмент. Каждая подсеть в такой сети объявляется
внутри секции shared-network. Параметры указанные для shared-network
используются при загрузке клиента если значения указанные в секциях
subnet или host не переопределяют их. Если для какой-либо подсети
указан диапазон динамически раздаваемых адресов, эти адреса собираются в
общий пул и назначаются клиентам по мере необходимости. Нет способа различать
к какой IP-подсети принадлежит клиент.

Параметр Имя
— должнен быть именем этой «общей» сети. Это имя используется в
информационных и отладочных сообщениях и желательно что бы оно достаточно
полно описывало сеть. Имя может имет синтаксис обычного доменного имени( однако
никогда не используется в качестве такового), или это может быть произвольное
имя, заключенное в кавычки.

Секция subnet используется для предоставления серверу DHCP дополнительной информации —
принадлежит ли данный IP адрес указанной подсети. Еще эта секция используется для предоставления
клиентам специфичных для подсети параметров и для указания диапазонов динамически распределяемых
адресов.

Параметр
subnet-number
должен быть IP адресом или доменным именем которое резолвится
в номер подсети которую он описывает.

Параметр netmask
должен быть IP адресом или доменным именем которое резолвится в значение соответствующее
маске описываемой подсети.

Параметры subnet-number и
netmask однозначно определяют подсеть и принадлежность
IP адреса к этой подсети.

Затрудняюсь перевести следующий абзац 🙁

Although a netmask must be given with every subnet declaration, it is
recommended that if there is any variance in subnet masks at a site, a
subnet-mask option statement be used in each subnet declaration to set
the desired subnet mask, since any subnet-mask option statement will
override the subnet mask declared in the subnet statement.

Для любой подсети адреса которой присваиваются динамически, должен быть указан хотя бы один диапазон с
помощью секции range. В параметрах указывается начальный и конечный адреса диапазона. Все IP
адреса в диапазоне должны принадлежать той подсети к описанию которой относится секция range.
Параметр dynamic-bootp указывается в случае если предполагается назначать адреса из диапазона
клиентам по протоколу BOOTP. Если указан только один адрес, то параметр конец_диапазона может быть
опущен.

Необходима хотя бы
одна секция host
для каждого BOOTP клиента, обслуживаемого сервером.
Так же host
может быть указана для DHCP клиентов, хотя это и не обязательно, если только
не требуется раздача адресов только определенным клиентам.

Если требуется обеспечить выдачу фиксированных адресов и конфигурацию клиентов по протоколам DHCP
или BOOTP
в более чем одной подсети, то можно указать несколько адресов с помощью параметра
fixed-address
или указать несколько секций host

Если клиентские параметры меняются в зависимости от сети к которой подключен клиент, то необходимо
использовать множественные записи
host
.

имя_хоста
— имя идентифицирующее хост. Если в описании хоста опция hostname не указана, то
используется значение имя_хоста.

Объявления Host сопоставляются с реальными DHCP или BOOTP клиентами путем сравнения опции
dhcp-client-identifier указанной в секции host со значением предоставленным клиентом, или
если клиент не предоставляет dhcp-client-identifier, то путем сравнения опции hardware
и
аппаратного (mac) адреса клиента. Клиенты BOOTP нормально не предоставляют dhcp-client-identifier,
так что при работе по протоколу BOOTP необходимо использовать mac-адреса.

Секция group используется для присвоения одного или нескольких параметров группе
объявлений. Параметры могут быть одновременно присвоены группе секций hosts, shared networks,
subnets, или даже groups.

ALLOW and DENY

Параметры allow
и deny
используются для контроля над поведением демона dhcp в отношении
различных видов запросов.

Ключевое слово
unknown-clients

Параметр unknown-clients используется что бы сообщить серверу как поступать с
неизвестными клиентами. По умолчанию выдача адресов неизвестным клиентам разрешена.

Параметр bootp сообщает серверу dhcp обрабатывать или нет bootp-запросы.
По умолчанию bootp-запросы разрешены.

Параметр booting сообщает серверу обрабатывать ли запрос конкретного клиента.
Имеет смысл только если присутствует в описании host и действует только на
соответствующий хост. По умолчанию разрешено, в противном случае хост не сможет получать
свой адрес и другие параметры.

ПАРАМЕТРЫ

Время
— промежуток времени в секундах, на который выделяется адрес клиенту, в случае
если клиент самостоятельно не указал время использования адреса.

Время
— максимальный промежуток времени в секундах, на который выделяется адрес клиенту.

hardware тип_железа аппаратный_адрес;

Для того что бы BOOTP клиент был опознан сервером, его mac-адрес должен быть объявлен с помощью
параметра hardware в секции host

Параметр тип_железа
— тип физического интерфейса. В настоящее время используются только

Читайте также:  Как поменять пароль для пользователя linux

ethernet
и token-ring
и возможно скоро будет реализованы другие типы, особенно
fddi
.

аппаратный_адрес
— записывается как набор шестнадцатеричных значений ( от 0 до ff ) разделенных
двоеточиями.

should be a set of hexadecimal octets (numbers from 0 through ff)
seperated by colons. Параметр hardware можно использовать и для DHCP клиентов.

Параметр filename указывает имя файла, используемого для начальной загрузки клиента.
имя_файла

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

Параметр server-name используется, что бы сообщить клиенту имя сервера который его обслуживает.
Имя_сервера — имя сервера, сообщаемое клиенту.

Параметр next-server используется для указания клиенту адреса сервера с которого должен быть
получен загрузочный файл (тот самый файл что указан в параметре filename). Имя_сервера
может быть IP адресом или доменным именем. Если этот параметр не указан, то используется адрес DHCP
сервера.

Параметр fixed-address используется для назначения одного или нескольких постоянных адресов
клиенту. Параметр может присутствовать только в секции host. Если указано более одного
адреса, то клиенту будет присвоен адрес соответствующий подсети к которой подключен клиент в данный
момент. Если нет адресов соответствующих подсети в которую включен клиент, то считается что этот
клиент не соответствует объявлению host и эти адреса ему не присваиваются. Каждый адрес
может быть IP адресом или доменным именем, которое резолвится в один или несколько IP адресов.

Параметр dynamic-bootp-lease-cutoff устанавливает момент времени в который все адреса назначенные
клиентам BOOTP должны быть освобождены. Так как клиенты BOOTP не имеют возможности продлить
срок использования полученных адресов и не могут определить что срок аренды истек, то по умолчанию
клиентам BOOTP адреса выделяются на неограниченный срок. Однако в некоторых случаях оказывается
полезным установить параметр dynamic-bootp-lease-cutoff, например в учебном заведении
при окончании семестра или в ночное время когда предприятие не работает а все компьютеры выключены.

дата
— срок окончания действия всех адресов выделенных BOOTP клиентам. Дата указывается
в следующем формате:

W ГГГГ/ММ/ДД ЧЧ:ММ:СС

W — день недели в виде числа от 0 (воскресенье) до 6 (суббота).

ДД — день месяца 1..31

СС — секунды 0..59

Время указывается в GMT, а не местное.

Параметр dynamic-bootp-lease-length используется для указания срока на
который выделяется адрес BOOTP клиенту. В некоторых организациях возможна ситуация
что по прошествии определенного времени можно быть уверенным что выделенный адрес
уже не используется. Период задается числом секунд. Если клиент перезагружается
в момент когда срок указанный в этом параметре еще не истек, то период аренды
адреса заново устанавливается в указанное значение. Таким образом часто перезагружаемые
BOOTP клиенты могут постоянное удерживать свой адрес. Необходимо заметить
что при настройке параметра, следует быть осторожным.

Параметр get-lease-hostnames сообщает серверу dhcp следует ли выполнять преобразование
IP адресов в соответствующие им имена и использовать полученные имена в качестве значения параметра
hostname. Если значение параметра — истина, тогда преобразование выполняется для каждого адреса в
диапазоне. По умолчанию или если значение — ложь, преобразование не выполняется.

Если параметр use-host-decl-names имеет значение — on (включено), то для каждого объявления
хоста, находящегося в зоне действия параметра, значение использованное в объявлении host<> предоставляется
клиенту в качестве его имени.

Дополнительный параметр option host-name указанный в объявлении host<> имеет больший приоритет
по сравнению с use-host-decl-names что позволяет переопределить имя хоста при включенном
use-host-decl-names

Обычно DHCP сервер предполагает что конфигурационная информация описывающая сегмент сети правильна и «авторитетна»
Так что если клиент запрашивает IP адрес и сервер знает что этот адрес не правилен, то сервер ответит клиенту
сообщением DHCPNAK, что является предложением клиенту отказаться от этого адреса и запросить новый.

Если до конфигурации DHCP сервера каким-то образом допустили кого-нибудь кто не является сетевым администратором и
даже не претендует на это звание, то в соответствующей секции нужно указать параметр
«not authoritative»

Обычно, бывает достаточно написать not authoritative; в начале файла конфигурации. Однако, если сервер
поддерживает несколько различных сегментов, то лучше объявлять авторитетность сервера в пределах
обслуживаемых им подсетей.

Если параметр use-lease-addr-for-default-route установлен в «on» для соответствующего сегмента сети, то
вместо посылки клиенту значения указанного в дополнительном параметре option routers ( или не посылки ничего
если адреса маршрутизаторов не заданы ), клиенту посылаются IP адреса уже назначенные сервером. На клиенте это
вызывает запросы ARP по всем этим адресам, что может быть очень полезным если ваш маршрутизатор сконфигурирован
как proxy ARP.

Некоторые BOOTP клиенты ожидают ответа от сервера в стиле RFC1048, но сами не следуют RFC1048 при посылке
запросов. Если в вашей сети имеется такой проблемный клиент, который не воспринимает параметры передаваемые
ему сервером и если в логах появляется сообщение «(non-rfc1048)» , то можно воспользоваться
этим параметром.

Если у вас все клиенты требуют работы в стиле RFC1048, то можно использовать параметр always-reply-rfc1048
.
Параметр может быть указан в любом объявлении в этом случае воздействует только на тех клиентов, которые
соответствуют указанной зоне действия.

Параметр
server-identifier отсылается клиенту и должен являться IP адресом
DHCP сервера, правильными для той подсети в которой находится клиент и достижимым
для всех клиентов этой подсети.

Использование
server-identifier не рекомендовано, единственная причина использования —
переопределить значение по умолчанию если оно по какой-нибудь причине не верно. Значением
по умолчанию является первый IP адрес из присвоенных физическому интерфейсу на который пришел
клиентский запрос.

Обычно параметр server-identifier используется когда физический интерфейс с несколькими
IP адресами, и адрес сообщаемый сервером клиенту не подходит некоторым или всем клиентам
обслуживаемым этим интерфейсом. Другой частый случай когда для интерфейса определен алиас
и необходимо что бы клиенты использовали именно его.

Задание значения для параметра dhcp-server-identifier эквивалентно использованию
параметра server-identifier.

Источник

Поделиться с друзьями
КомпСовет
Adblock
detector