@ Карта сайта News Автора!

Bog BOS: Протокол BOOTP/DHCP

Последние изменения:
2022.06.27: sysadmin: тестирование настоящих SSD (KIOXIA CM6-V)

Последнее изменение файла: 2018.01.05
Скопировано с www.bog.pp.ru: 2023.10.01

Bog BOS: Протокол BOOTP/DHCP

BOOTP (Bootstrap Protocol) как и RARP обеспечивает определение с помощью специального сервера IP адреса клиента по его MAC адресу (например, при загрузке устройства, не имеющего возможности хранить свой собственный IP адрес), а также позволяет клиентам узнавать другие параметры загрузки (например, имя программы, загружаемой затем с помощью TFTP) и использует UDP в качестве протокола канального уровня. Это позволяет использовать маршрутизаторы (bootp relay) для передачи запросов и ответов из одного сегмента локальной сети в другой. Протокол DHCP (Dynamic Host Configuration Protocol) является надстройкой над BOOTP (для совместимости с bootp relay) и позволяет серверу выделять IP адреса клиентам динамически на ограниченный срок.

Протокол BOOTP

Порт сервера - UDP/67 (BOOTPS), клиента - UDP/68 (BOOTPC). Клиент делает широковещательный (255.255.255.255 - всем в локальной сети, номера которой я не знаю) запрос bootrequest (один нефрагментированный пакет): обязательно содержит аппаратный MAC адрес клиента и может содержать преполагаемый IP-адрес клиента, имя сервера и обобщенное имя файла для загрузки. Сервер отвечает пакетом bootreply (обычно unicast, т.к. MAC и IP адреса клиента ему известны): IP-адрес клиента, обобщенное имя файла замещается на полное имя файла исходя из конфигурации сервера, типа и адреса клиента и др. Собственно загрузка файла осуществляется клиентом с помощью протокола TFTP. Клиент должен быть в состоянии ответить на ARP запросы, чтобы мог работать TFTP-сервер.

Формат пакетов (в скобках упомянуты тэги /etc/bootptab и /etc/dhcpd.conf):

Формат дополнительной информации (RFC 2132): первые 4 байта имеют значение 99.130.83.99, что позволяет определить ее наличие (может быть использовано другое согласованное значение, определяющее собственный формат этого поля). Далее расположен список элементов (имена и тексты в NVT ASCII). Каждый элемент имеет однобайтовую этикетку, описывающую его тип. Типы 0 и 255 состоят только из этикетки (0 - заполнитель, 255 - конец данных). Остальные типы элементов вторым байтом имеют длину элемента (в скобках упомянуты тэги /etc/bootptab и /etc/dhcpd.conf):

  1. маска подсети (sm, subnet-mask)
  2. смещение времени относительно UTC (в секундах, time-offset)
  3. список IP адресов маршрутизаторов (первый - предпочтительный, gw, routers)
  4. список IP адресов серверов времени (RFC 868, не NTP!)
  5. список IP адресов серверов имен (IEN 116, не DNS!)
  6. список IP адресов DNS серверов (domain-name-servers)
  7. список IP адресов серверов syslog (lg, log-servers)
  8. список IP адресов серверов "Quote of the Day" (RFC 865)
  9. список IP адресов серверов печати (LPR/LPD, RFC 1179)
  10. список IP адресов серверов Imagen Impress
  11. список IP адресов серверов поиска ресурсов (RFC 887)
  12. доменное имя хоста клиента, возможно только локальная часть (hn, host-name)
  13. число блоков в загрузочном файле (по 512 байт, до 64k, bs)
  14. имя файла для coredump
  15. имя домена клиента (domain-name)
  16. IP адрес swap сервера
  17. путь монтирования диска root
  18. имя файла (берется затем клиентом с помощью TFTP) с продолжением дополнительной информации
  19. должен ли клиент передавать пакеты с интерфейса на интерфейс, т.е. работать маршрутизатором (forwarding, ip-forwarding)
  20. разрешать ли source routing IP пакетов
  21. фильтры для source routing
  22. максимальный размер датаграммы для сборки клиентом (не менее 576)
  23. TTL для исходящих от клиента датаграмм
  24. время ожидания для алгоритма автораскрытия MTU (RFC 1191)
  25. таблица значений MTU для алгоритма автораскрытия MTU (RFC 1191)
  26. MTU интерфейса (не менее 68)
  27. все ли прямо подключенные подсети имеют одинаковый MTU
  28. широковещательный IP адрес локальной подсети
  29. использовать ли ICMP для автораскрытия маски подсети
  30. отвечать ли на ICMP запросы автораскрытия маски подсети
  31. использовать ли механизм поиска маршрутизаторов (RFC 1256, router-discovery)
  32. IP адрес сервера механизма поиска маршрутизаторов
  33. список статических маршрутов в виде списка пар: сеть (нельзя задавать 0.0.0.0), адрес маршрутизатора (а маска?)
  34. использовать ли "хвосты" в канальных кадрах (RFC 893)
  35. время жизни элементов ARP кеша (секунд)
  36. версия Ethernet: version 2 (RFC 894) или IEEE 802.3 (RFC 1042)
  37. TTL для исходящих от клиента TCP пакетов
  38. TCP keepalive interval
  39. TCP keepalive garbage option
  40. имя домена NIS
  41. список IP адресов серверов NIS
  42. список IP адресов серверов NTP (ntp-servers)
  43. информация в формате изготовителя оборудования
  44. список адресов серверов имен NetBIOS over TCP/IP (RFC 1001, RFC 1002)
  45. список адресов серверов NBDD NetBIOS over TCP/IP (RFC 1001, RFC 1002)
  46. тип узла NetBIOS over TCP/IP (RFC 1001, RFC 1002)
  47. область NetBIOS over TCP/IP (RFC 1001, RFC 1002)
  48. список IP адресов серверов шрифтов X Window System
  49. список IP адресов менеджеров дисплея (xdm) X Window System
  50. требуемый клиенту IP адрес (DHCPDISCOVER)
  51. запрашиваемое (DHCPDISCOVER, DHCPREQUEST) или предоставленное (DHCPOFFER) время аренды IP адреса (в секундах относительно момента запроса)
  52. использовать ли поля имени сервера и имени загрузочного файла для передачи дополнительных опций (DHCP)
  53. тип сообщения DHCP (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPDECLINE, DHCPACK, DHCPNAK, DHCPRELEASE, DHCPINFORM)
  54. идентификатор сервера DHCP (IP адрес), указывается сервером в DHCPOFFER, чтобы клиент мог различить предложения от различных серверов (возможно также указание в DHCPACK и DHCPNAK); указывается клиентом в DHCPREQUEST, чтобы показать, какое предложение он принял
  55. список кодов опций, значения которых клиент хочет узнать от сервера
  56. текст сообщения об ошибке (DHCPNAK, DHCPDECLINE)
  57. максимальный размер сообщения DHCP, которое клиент готов принять (DHCPDISCOVER, DHCPREQUEST)
  58. T1 - интервал времени (в секундах), через который клиент DHCP должен перейти в режим запроса подтверждения на право владения IP адресом (RENEWING), по умолчанию - 0.5 от срока аренды
  59. T2 - интервал времени (в секундах), через который клиент DHCP должен перейти в режим получения нового IP адреса (REBINDING), по умолчанию - 0.875 от срока аренды
  60. используется DHCP клиентом для указания варианта конфигурации (vendor class), сервер возвращает информацию только в формате изготовителя оборудования
  61. уникальный в подсети идентификатор клиента DHCP (например, MAC адрес или полное доменное имя), в протоколе BOOTP для идентификации клиента использовался его MAC адрес
  62. имя домена NIS+
  63. список IP адресов серверов NIS+
  64. имя TFTP сервера, если поле имени сервера использовано под дополнительные опции (DHCP)
  65. имя загрузочного файла, если поле имени загрузочного файла использовано под дополнительные опции (DHCP)
  66. список IP адресов Mobile IP Home Agent
  67. список IP адресов серверов SMTP (smtp-server)
  68. список IP адресов серверов POP3
  69. список IP адресов серверов NNTP
  70. список IP адресов серверов WWW (HTTP ?)
  71. список IP адресов серверов finger
  72. список IP адресов серверов IRC
  73. список IP адресов серверов StreetTalk
  74. список IP адресов серверов StreetTalk Directory Assistance
  75. тип пользователя (задаётся клиентом)
  76. информация от посредника (relay) о клиенте; содержит от 1 до 255 подопций: 1 - circuit ID, 2 - Remote ID
  77. системная архитектура клиента PXE
  78. версия универсального сетевого интерфейса PXE (UNDI)
  79. универсальный идентификатор клиента PXE (UUID)
  80. статические маршруты
  81. - 254: зарезервированы для локального использования (Tномер, option option-номер)

Средств обеспечения безопасности нет, в ответ клиент может получить фальшивый пакет. Поэтому на периферии сети порты UDP/67 и UDP/68 должны быть заблокированы сетевым экраном, а на сервере BOOTP должны быть проделаны дырки в ipchains (привожу формат /etc/sysconfig/ipchains): 

-A input -s 0.0.0.0/0.0.0.0 68:68 -d 0.0.0.0/0.0.0.0 67:67 -p udp -j ACCEPT

Аналогичные дырки надо проделать для исходящих пакетов сервера и пакетов, пересылаемых DHCP прокси.

Если в ядре включена фильтрация поддельных IP-адресов (martian address filtering), то ее придется отключить (по крайней мере для адресов 0.0.0.0 и 255.255.255.255).

Экран можно усилить, заменив "универсальные" 0.0.0.0/0.0.0.0 на адреса ваших клиентов/сервера, но учитывайте, что исходящими IP адресами клиентов могут быть также 0.0.0.0, а входным - 255.255.255.255.

Протокол DHCP

Протокол DHCP использует тот же самый формат пакетов и те же UDP порты для обмена сообщениями между серверами и клиентами. Это позволяет DHCP серверу обслуживать BOOTP клиентов и использовать исторически сложившуюся инфраструктуру BOOTP прокси. DHCP не определяет политику назначения IP адресов и прочих параметров, а лишь обеспечивает механизм её реализации. Адрес может выделяться на ограниченный срок (выражается в секундах относительно момента запроса) или навсегда. DHCP позволяет свести настройку сетевых параметров клиентов к минимуму. В сети может быть установлено несколько серверов. Сервер должен хранить выделенные параметры при перезагрузках клиентов и сервера, чтобы по возможности выделять один и тот же адрес. При запросах клиент может идентифицироваться не только своим MAC адресом, но и специальной опцией "уникальный идентификатор клиента" (UUID или GUID). Аналогично сервер указывает свой IP адрес в опции "идентификатор сервера". Пакеты от клиента DHCP (тип bootrequest) могут быть следующих видов (задаётся опцией "тип сообщения DHCP"):

Ответные пакеты от сервера DHCP (тип bootreply) могут быть следующих видов (задаётся опцией "тип сообщения DHCP"):

Сервера BOOTP

Пакет bootp-2.4.3-7.i386.rpm (Red Hat Linux 5.2). Содержит программы bootpd и bootptest. Конфигурационный файл - /etc/bootptab (см. bootptab(8)): 

printer0:\
  :ht=ether:ha=ethernet-адрес:\
  :hn:vm=rfc1048:sm=маска-сети:ip=адрес-принтера:\
  :lg=адрес-syslog-сервера:\
  :sa=адрес-TFTP-сервера:\
  :T144="имя-TFTP-файла-с-параметрами-принтера":

Устанавливается и на нынешние версии Red Hat Linux, только надо создать файл /etc/xinetd.d (не забыть презапустить xinetd: "/etc/rc.d/init.d/xinetd reload") 

service bootps
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/bootpd
        server_args             = -i -d4 -t 1 /etc/bootptab
        disable                 = no
}

Сервер bootpd от HP в комплекте программ для JetDirect. Тестовая программа bootpquery делает запрос и выводит ответ BOOTP сервера. В качестве параметров можно указать MAC адрес клиента (если не совпадает с настоящим, то сервер д.б. возвращать широковещательный ответ) и имя сервера (ключ -s). Конфигурационный файл - /etc/bootptab (см. bootptab(8)): 

printer0:\
  :ht=ether:ha=ethernet-адрес:\
  :hn:vm=rfc1048:sm=маска-сети:ip=адрес-принтера:\
  :lg=адрес-syslog-сервера:\
  :sa=адрес-TFTP-сервера:\
  :T144="имя-TFTP-файла-с-параметров-принтера":

rpc.bootparamd в Solaris использует данные из /etc/bootparams, реализует специфическую для Sun RPC версию сервера, обеспечивающего дополнительные параметры для загрузки. Скрипт /etc/init.d/nfs.server (AKA /etc/rc3.d/S15nfs.server) запускает "/usr/sbin/rpc.bootparamd", если существует директория /tftproot. Если у вас нет бездисковых станций Sun, то он вам не нужен.

Сервер bootparamd в Red Hat Linux поставляется в виде пакета bootparamd-0.17-7 (RH 7.2) и реализует ту же самую специфическую для Sun RPC версию сервера, обеспечивающего дополнительные параметры для загрузки.

Столкнулся с забавной "плюшкой" firmware JetDirect: все IP-адреса в списке дополнительных элементов должны быть выровнены на границу слова, поэтому строки переменной длины (имена хостов и файлов) должны быть в конце списка, либо иметь четную длину. bootpd из поставки JetDirect знает об этом, а для dhcpd и стандартного bootpd пришлось менять имена хостов.

Сервер DHCP

Пакет dhcp-2.0pl5-8 (RH 7.2) или dhcp-3.0pl1-15 (RH 8.0) или dhcp-3.0.1-11 (FC3) или dhcp-3.0.5-7.el5 (CentOS5.1) содержит BOOTP/DHCP сервер dhcpd и прокси dhcrelay от ISC (имеются также пакеты dhclient и dhcp-devel). Поддерживается работа DHCP клиента, сервера и прокси. Обеспечивается динамическое изменение DNS. Перед выдачей динамического адреса клиенту запись об этом заносится в конец специального файла (dhcpd.leases(5), /var/lib/dhcp/dhcpd.leases) для страховки, т.е. правильным является последнее значение. Время от времени создаётся новый файл и переименовывается, чтобы размер файла не вырос до бесконечности. Файл содержит записи аренды, объявления хостов, групп и подгрупп в формате dhcpd.conf (объявления хостов, групп и подгрупп для объектов, динамически созданных с помощью OMAPI, см. ниже). Каждая запись аренды содержит выделенный IP-адрес, время начала и конца аренды в человеколюбивом формате (но в UTC), тип оборудования и MAC адрес, идентификатор клиента, host-name, abandoned (адрес нельзя было выдавать), текущее и следующее состояния аренды, agent.circuit-id и agent.remote-id (см. описание опций). В версии 3.0 убрана поддержка неизвестных серверу опций в виде "option-144", теперь их необходимо описывать явно. Журнал записывается на syslog, источник - DAEMON. Процедура запуска в файле /etc/rc.d/init.d/dhcpd (start, stop, restart, status). Параметры командной строки хранятся в файле /etc/sysconfig/dhcpd. Для обеспечения запуска при загрузке надо выполнить 

chkconfig --level 2345 dhcpd on

После запуска номер процесса сохраняется в файле /var/run/dhcpd.pid. После изменения конфигурационного файла /etc/dhcpd.conf (описание - dhcpd.conf(5), dhcp-options(5), dhcp-eval(5)) необходимо перезапустить сервер. Кроме сервера протокола BOOTP обеспечивает сервер протокола DHCP, поэтому имеет множество параметров настройки, но для каждого клиента BOOTP достаточно иметь секцию host в /etc/dhcpd.conf (subnet, естественно, общий для всей подсети), например, обеспечение загрузки сетевого принтера HP JetDirect для dhcp-2.0: 

subnet ip-адрес-подсети netmask маска-подсети {
  host имя-принтера {
    hardware ethernet MAC-адрес;
    fixed-address IP-адрес;
    always-reply-rfc1048 on;
    next-server TFTP-сервер;
    option subnet-mask маска-подсети;
    option host-name "имя-принтера";
    option log-servers имя-сервера-syslog;
    option option-144 "имя-TFTP-файла-с-параметрами-принтера";
  }
}

Параметры запуска /usr/sbin/dhcpd:

Протокол OMAPI позволяет подсоединяться к серверу по TCP/7911 (с аутентификацией, TSIG), чтобы проверить его состояние или изменить конфигурацию или содержимое БД (просмотр, создание, удаление, просмотр и изменение атрибутов для объектов типа аренда, хост, группа, управление). Имеется командная оболочка omshell(1).

Прокси dhcrelay(8) транслирует запросы клиентов и ответы серверов между сегментами сети (конфигурационного файла нет):

Настройка сервера DHCP ISC

Конфигурационный файл имеет свободный текстовый формат. Комментарии начинаются со знака '#' и продолжаются до конца строки. Регистр ключевых слов значения не имеет. Файл состоит из утверждений двух типов: параметры и объявления. Объявления описывают топологию сети и группируют параметры. Объявления могут быть вложенными. Параметры и простые объявления завершаются точкой с запятой. Определяющие вложенную область действия объявления заключают её в фигурные скобки и не имеют завершающей точки с запятой. Параметры внутри объявления д.б. описаны до вложенных объявлений.

Для каждой подсети, к которой подключён DHCP сервер, должно быть объявление подсети subnet (даже если он её не обслуживает). Если подсети подключены к одному интерфейсу, то объявления этих подсетей д.б. помещены внутрь объявления shared-network. Кстати, с помощью bootp прокси через интерфейс могут быть видны сегменты, не подключённые непосредственно. Если адреса клиентам внутри подсети должны выделяться динамически, то необходимо объявить пул адресов внутри подсети pool (все пулы на одном интерфейсе - общие, невозможно определить к какой подсети на разделяемом интерфейсе принадлежит клиент). Для клиентов со статическими адресами необходимо поместить объявление host внутрь объявления подсети. Если требуется загружать клиента в различных подсетях, то для него можно описать несколько объявлений host (если ему необходимо назначить различные параметры в зависимости от подсети) или несколько параметров fixed-address в одном объявлении. Объявления различного типа с одинаковыми параметрами можно группировать внутри объявления group. Клиенты с динамически выделяемыми адресами могут быть сгруппированы согласно объявлению классов class (класс клиента определяется в момент запроса в соответствии с передаваемыми им опциями - например, идентификатором клиента). Имеется также грязный хак по распределению клиентов по подклассам исключительно с целью оптимизации времени работы сервера. Возможно объявление класса (spawning class), автоматически порождающего подклассы в зависимости от значения получаемого от клиента параметра. Имеются условные операторы. Перед объявлениями самого верхнего уровня могут быть указаны глобальные параметры. Пример смотри в предыдущем параграфе. Поиск параметров для клиента происходит в следующей последовательности (приоритет имеет более конкретная область действия):

  1. объявление host (по идентификатору клиента или MAC адресу; сначала просматриваются те, которые содержат фиксированный IP адрес, подходящий для подсети клиента, затем не содержащие фиксированных адресов)
  2. объявление class
  3. объявление pool (по IP адресу)
  4. объявление subnet (по IP адресу)
  5. объявление shared-network (по IP адресу)

Синтаксис: 

shared-network имя {
  [ параметры ]
  [ объявления ]
}
subnet IP-адрес-сети netmask маска {
  [ параметры ]
  [ объявления ]
}
range [ dynamic-bootp ] начальный-IP-адрес [ конечный-IP-адрес ];
  флаг dynamic-bootp разрешает выделение адреса из пула bootp клиентам
host имя-хоста {
  [ параметры ]
  [ объявления ]
}
group {
  [ параметры ]
  [ объявления ]
}
class "имя-класса" {
  [ match ... ]
  [ spawn with option имя-опции ]
  [ lease limit максимальное-число-клиентов-в-классе ]
  [ параметры ]
}
subclass "имя-класса" константа;
subclass "имя-класса" константа {
  [ параметры ]
}
if условие {
  [ параметры ]
} [ elsif условие {
      [ параметры ]
} ]
 ...
  [ else {
      [ параметры ]
} ]

log (приоритет, выражение)
   и куда это всё девается?

Для управления доступом в любой области объявления могут быть использованы утверждения allow, deny или ignore (аналогично deny, но без записи сообщения в журнал), указаны значения по умолчанию:

Для управления выделением адресов из пула внутри объявления пула могут быть использованы утверждения allow и deny со следующими параметрами (они обрабатываются до выделения адреса):

Параметры (там, где возможно, приведены значения по умолчанию):

Условие в операторе if/elsif в зависимости от значения опций в запросе задаётся в виде булевского выражения (null в любой части выражения приводит к результату null для всего выражения)

Значение параметра может задаваться в виде выражения. Выражения также используются для условных описаний параметров. Имеются следующие выражения по извлечению данных:

Сервер поддерживает протокол восстановления (failover, draft-ietf-dhc-failover-07.txt) - два DHCP сервера разделяют общий пул динамически распределяемых адресов и подменяют друг друга в случае падения. Протокол не стандартизован (и недодуман) до конца - чувствуйте себя бета-тестерами, если хотите. Описание опускаю.

Сервер поддерживает (описание опускаю) протокол динамического обновления DNS, используя следующие алгоритмы (задаётся параметром ddns-update-style - требуется указать хотя бы none, иначе сервер не запустится; TSIG и DNSSEC не реализованы):

Возможно назначить выполнение блока операторов при наступлении одного из типов событий: выделение адреса (commit), освобождение (release), истечение времени аренды (expiry).

Настройка ISC DHCP сервера для обслуживания PXE клиентов.

Клиенты DHCP

Пакет dhclient-3.0.1-30_FC3 (FC3) содержит клиент протокола DHCP от ISC. Пытается настроить все активные широковещательные интерфейсы, делая широковещательные запросы на них к серверам DHCP. Конфигурационный файл - /etc/dhclient.conf (dhclient.conf(5)); список арендованных адресов - /var/lib/dhcp/dhclient.leases (dhclient.leases(5) и описание объявления lease в dhclient.conf), его можно подсунуть клиенту, если ожидается отсутствие DHCP сервера. Для управления клиентом можно использовать тот же OMAPI протокол, что и для управления сервером: приостановка работы, возобновление работы с переконфигурацией всех интерфейсов, завершение работы. Для обновления использует не широковещательный запрос, а непосредственный IP адрес сервера, выдавшего IP адрес. Параметры запуска:

Синтаксис файла конфигурации такой же, как и у файла конфигурации сервера. Параметры и объявления:

Скрипт dhclient-script вызывается dhclient для установки интерфейса до выдачи запроса серверу, при проверка предложенного адреса, для полной установки интерфейса, при проверке предустановленой аренды при отсутствии сервера и при полном отсутствии информации об адресе. При вызове передаётся переменная окружения reason:

Если DHCP сервер раздаёт адреса NTP серверов, то на сервере NTP необходимо добавить в /etc/sysconfig/network строку PEERNTP=no, иначе dhclient будет "улучшать" /etc/ntp.conf.

Microsoft Windows 2000 Server запрашивает (идентификатор клиента - его MAC адрес; vendor class identifier - "MSFT 5.0"):

Ссылки
@ Карта сайта News Автора!

Bog BOS: Протокол BOOTP/DHCP

Последние изменения:
2022.06.27: sysadmin: тестирование настоящих SSD (KIOXIA CM6-V)
TopList
Copyright © 1996-2023 Sergey E. Bogomolov; www.bog.pp.ru