Конфигурируем DHCP-серверы и настраиваем динамические обновления DNS. Dhcp журнал

Журнал аудита DHCP | Энциклопедия Windows

При включении журнал аудита предоставляет самую подробную информацию об ошибках в работе службы DHCP. Хотя журнал аудита по умолчанию включен, для проверки его включения можно выполнить такую последовательность действий.

1. Откройте оснастку DHCP.

2. Кликните правой кнопкой мыши на объекте сервера DHCP и выберите Свойства (Properties) из контекстного меню.

3. На вкладке Общие (General) проверьте состояние флажка Включить журнал аудита DHCP (Enable DHCP Audit Logging).

4. Перейдите на вкладку Дополнительно (Advanced) и обратите внимание на путь к файлу журнала.

5. Закройте окно свойств сервера DHCP.

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

Общие события аудита

Идентификатор события	Сообщение об ошибке	Возможная ошибка и действие по ее исправлению
00	Журнал запущен	Включен журнал аудита. Нет проблем
01	Журнал остановлен	Отключен журнал аудита. Это предполагает завершение диагностики. Если администратор не отключал журнал аудита, необходимо выяснить, кто это сделал!
02	Журнал был временно приостановлен из-за недостатка дискового пространства	Объем свободного дискового пространства стал меньше 20Мбайт (объем, принятый по умолчанию) или другого настроенного значения. Освободите дисковое пространство на сервере, удалив ненужные файлы и папки.
10	Клиенту выдан новый адрес IP	Новый клиент запросил и получил новый адрес IP
11	Клиент возобновил аренду	Клиент успешно возобновил аренду. Нет проблем.
12	Клиент освободил аренду	Клиент успешно освободил аренду. Нет проблем.
13	Адрес IP уже используется в сети	В процессе обнаружения конфликтов оказалось, что адрес IP, который сервер планировал выдать клиенту, уже находится в сети. Следовательно адрес не был выдан клиенту и использован другой адрес. Если сообщение появляется после восстановления базы данных DHCP, то это нормальное поведение, так как некоторые аренды могли выдаваться после выполнения резервного копирования. Если это не так, то необходимо найти клиентскую систему с этим адресом IP, так как скорее всего этот адрес был введен вручную в виде статического. Просмотрите динамические регистрации в доменной зоне DNS и найдите клиентский компьютер, которому соответствует этот адрес IP.
14	Запрос аренды не может быть выполнен из-за недостатка адресов в области	В области закончились свободные адреса IP. Для решения проблемы можно или увеличить количество адресов IP в данной области или уменьшить длительность аренды.
15	В аренде отказано	Клиент запросил возобновить аренду и ему было отказано. Обычно это связано с тем, что адрес IP уже связан с адресом MAC другой системы. Этот тип конфликта обычно связан с восстановлением базы данных DHCP из резервной копии.
20	Клиенту был выдан адрес BOOTP	Клиент получил адрес IP в аренду по протоколу BOOTP от маршрутизатора или агента ретрансляции DHCP. Это может означать нормальное поведение или отказ сервера DHCP в локальной подсети.

События аудита динамического обновления

Идентификатор события	Сообщение об ошибке	Возможная ошибка и пути ее устранения
30	Запрос на динамическое обновление DNS	Сервер DHCP отправил запрос на динамическое обновление данных зоны DNS. Нет проблем.
31	Отказ в динамическом обновлении DNS	Динамическое обновление завершилось неудачно. Убедитесь, что динамические обновления в соответствующей зоне включены. Убедитесь, что учетная запись компьютера, выполняющего роль сервера DHCP, входит в глобальную группу DnsUpdateProxy.
32	Динамическое обновление DNS завершено успешно	Динамическое обновление успешно завершено. Нет проблем.

События аудита неудачной авторизации

Идентификатор события	Сообщение об ошибке	Возможная ошибка и пути ее устранения
50	Недоступный домен	Сервер DHCP не в состоянии найти контроллер домена в своем домене. Проверьте наличие проблем в работе сети или доступность контроллеров домена.
51	Авторизация успешно завершена	Сервер DHCP получил разрешение на запуск в сети. Нет проблем.
52	Обновление до Windows Server 2003	Сервер обновлен до Windows Server 2003 и возможность обнаружения неавторизованных серверов DHCP была отключена. Нет проблем.
53	Кэшированная авторизация	Серверу DHCP разрешен запуск на основе кэшированной информации авторизации. Проверьте наличие контроллеров домена или сетевого подключения к контроллерам домена.
54	Авторизация завершилась неудачно	Сервер DHCP не был авторизован членом группы Администраторы предприятия (Enterprise Administrators)
55	Авторизация (обслуживание)	Сервер DHCP был успешно авторизован. Нет проблем.
56	Авторизация неудачна, обслуживание прекращено	Служба DHCP не была авторизована на запуск и остановлена операционной системой. Член группы Администраторы предприятия должен выдать авторизацию на запуск сервера DHCP
57	В домене найден сервер	В домене существует еще один авторизованный сервер DHCP. Нет проблем.
58	Сервер не может найти домен	Сервер DHCP не в состоянии найти свой домен. Проверьте подключение к сети контроллера домена и состояние контроллеров домена.
59	Отказ сети	Сервер DHCP не в состоянии определить авторизацию из-за отказа сети.
60	Нет включенных контроллеров доменов с поддержкой службы каталогов	Сервер DHCP в состоянии найти контроллер домена, например, Windows NT BDC, но не может найти ни одного контроллера домена с поддержкой Active Directory. Проверьте сетевое подключение контроллера домена на основе операционной системы Windows 2000 или Windows Server 2003 (сервер DHCP требует наличия таких контроллеров домена для проверки авторизации).
61	Найден сервер, принадлежащий домену службы каталогов	В сети найден еще один сервер, который принадлежит тому же домену Active Directory. Нет проблем.
62	В сети найден еще один сервер DHCP	Это может быть сервер злоумышленников. Найдите этот сервер и при необходимости отключите.
63	Перезапуск обнаружения злоумышленника	Сервер DHCP пытается установить контакт с контроллером домена для проверки авторизации. Нет проблем.
64	Нет интерфейсом с поддержкой DHCP	Сетевые устройства отсутствуют или не подключены к сети. Убедитесь, что сетевой адаптер отображается в списке устройств Диспетчера устройств (Device Manager). Кроме этого, для сетевого адаптера должен быть установлен и настроен протокол TCP/IP с указанием статического адреса IP. После этого необходимо проверить соединение с концентратором или маршрутизатором.

windata.ru

Конфигурирование DHCP::Журнал СА 5.2003

ДЕНИС КОЛЕСНИЧЕНКО

Конфигурирование DHCP

Для чего нужен протокол DHCP? DHCP – это протокол настройки узла, который автоматически назначает IP-адреса компьютерам. Протокол DHCP – это дальнейшее развитие протокола BOOTP. Последний разрешает бездисковым клиентам запускать и автоматически конфигурировать протокол TCP/IP. Протокол DHCP централизовано назначает IP-адреса в вашей сети и автоматически конфигурирует рабочие станции. Возможно, вы подумали, что в одной сети должен быть только один сервер DHCP, потому что в противном случае между серверами возникнет конфликт, а пострадавшим опять окажется клиент, который зависнет при загрузке. А вот и не так – в одной сети может быть несколько серверов DHCP. И это не только не отразится на производительности сети, но даже повысит надежность сети, если, например, один из серверов выйдет из строя.

Итак, установите пакет dhcp и включите поддержку динамических IP-адресов командой:

echo "1" > /proc/sys/net/ipv4/ip_dynaddr

Ясное дело, ничего не нужно делать, если поддержка динамических IP-адресов уже включена (в большинстве случаев это так). DHCP в Linux реализован в виде демона сервера (dhcpd) и демона клиента (dhcpcd). Демон сервера непосредственно отвечает за назначение IP-адресов клиентам при входе и выходе их из сети. Клиентский демон, как явствует из названия, запускается на стороне клиента.

Конфигурационным файлом для dhcpd является /etc/dhcp.conf. При запуске DHCP-сервера происходит выделение IP-адресов согласно содержащимся в файле /etc/dhcp.conf установкам. Выделенные адреса dhcpd регистрирует в файле dhcpd.leases, который обычно находится в каталоге /var/dhcpd.

Сейчас давайте рассмотрим простейшую конфигурацию, которую будем постепенно наращивать. Обратите внимание: чтобы внесенные вами в файл /etc/dhcp.conf изменения вступили в силу, демон dhcpd необходимо остановить и запустить снова. При этом используйте команду /etc/rc.d/init.d/dhcpd stop для останова демона и команду /etc/rc.d/init.d/dhcpd start для его запуска.

Файл /etc/dhcpd.conf

# Описание сети, указывающее, какая из подсетей будет обслуживаться. Указывается сетевой адрес и маска сети

subnet 192.168.0.0 netmask 255.255.255.0 {

# Маршрутизатор по умолчанию

option routers 192.168.0.1;

# Маска подсети 255.255.255.0

option subnet-mask 255.255.255.0;

# Установка домена по умолчанию и сервера NIS, если таковой используется

option nis-domain "domain.ru";

option domain-name "domain.ru";

# Адрес DNS-сервера, который будут использовать клиенты

option domain-name-servers 192.168.0.1;

# Диапазон адресов для клиентов

# 192.168.0.10-192.168.0.250

range 192.168.0.10 192.168.0.254;

# Сказать клиентам, чтобы отдали адрес через 21600 секунд (6 часов) после получения адреса

default-lease-time 21600;

# Забрать адрес самому через 28800 секунд (8 часов)

max-lease-time 28800;

}

Теперь будем постепенно усложнять конфигурацию. Каждая сетевая карточка имеет уникальный собственный MAC-адрес. Допустим, вам нужно связать какой-то MAC-адрес с определенным IP-адресом. Для этого воспользуйтесь конструкцией host:

host myhost {

hardware ethernet xx:xx:xx:xx:xx:xx;

fixed-address 192.168.0.9;

}

Ее нужно вставить в ту конструкцию подсети subnet, которой принадлежит назначаемый IP-адрес. Данная конструкция означает, что компьютеру с аппаратным адресом xx:xx:xx:xx:xx:xx будет назначен IP-адрес 192.168.1.9. Например:

subnet 192.168.0.0 netmask 255.255.255.0 {

    # прочие опции

    # …

    #

    host myhost {

           hardware ethernet 00:40:C7:34:90:1E;

           fixed-address 192.168.0.9;

                 }

}

Данный пример показывает, что аппаратному адресу 00:40:C7:34:90:1E будет сопоставлен IP-адрес 192.168.0.9. Обратите внимание, что IP-адрес хоста myhost 192.168.0.9 относится к подсети 192.168.0.0 и включен в инструкцию subnet подсети 192.168.0.0, а не какой-либо другой сети!

Существует довольно удобная утилита для просмотра всех MAC-адресов сетевых адаптеров в вашей сети – программа TCPNetView. Эта программа разработана Александром Горлачем, и загрузить ее вы можете по адресу http://www.enet.ru/~gorlach/netview (если вы не можете скачать эту программу, обратитесь ко мне). Правда, есть одно «но»: эта программа работает под Windows. В любом случае, если вы будете использовать эту программу, при настройке сервера вам не придется подходить к каждому компьютеру, чтобы узнать его MAC-адрес.

Теперь предположим, что вам необходимо обеспечить поддержку WINS, а на вашей машине установлен сервер Samba. В этом случае в конструкцию subnet нужно включить следующие директивы:

option netbios-name-servers 192.168.0.1;

option netbios-dd-server 192.168.0.1;

option netbios-node-type 8;

Примечание. Служба WINS (Windows Internet Name Service) используется для разрешения (перевода) имен NetBIOS в IP-адреса. Сервер WINS – это усовершенствованный сервер имен NetBIOS, разработан Microsoft для снижения широковещательного трафика.

Пакет Samba предназначен для использования протокола SMB (Server Message Block), который также еще называется протоколом NetBIOS. С помощью пакета Samba ваша машина, работающая под управлением Linux, ничем не будет отличаться от рабочей станции или сервера сети Microsoft.

Вот практически и все. Правда, еще можно добавить пару незначительных опций:

# определяем широковещательный адрес

option broadcast-address 192.168.2.255;

# включаем IP-Forwarding

option ip-forwarding on;

# можно добавить глобальную опцию:

server-identifier server.domain.ua;

Как обычно, дополнительную информацию можно получить, введя команду man dhcpd.conf. При настройке клиентов Windows следует активизировать режим «Получить IP-адрес автоматически» в свойствах TCP/IP (см. рис. 1). А при настройке Linux с помощью конфигуратора netconf – включить режим DHCP (см. рис. 2). Протокол DHCP подробно описан в RFC 1533, 1534, 1541, 1542, а протокол BOOTP описан в RFC 1532. Окончательный вариант конфигурационного файла приведен ниже.

Рисунок 1. Настройка Windows-клиента

Рисунок 2. Настройка Linux-клиента

Конфигурационный файл /etc/dhcpd.conf (окончательный вариант)

# Подсеть 192.168.0.0, маска сети 255.255.255.0

subnet 192.168.0.0 netmask 255.255.255.0 {

# Маршрутизатор по умолчанию

option routers 192.168.0.1;

# Маска подсети 255.255.255.0

option subnet-mask 255.255.255.0;

# Установка домена по умолчанию и сервера NIS, если таковой используется

option nis-domain "domain.ru";

option domain-name "domain.ru";

# Задание широковещательного адреса

option broadcast-address 192.168.0.255;

# Включение IP-Forwarding

option ip-forwarding on;

# Глобальная опция server-identifier:

server-identifier server.domain.ru;

# Адрес DNS-сервера, который будут использовать клиенты

option domain-name-servers 192.168.0.1;

# Диапазон адресов для клиентов

# 192.168.0.10-192.168.0.254

range 192.168.0.10 192.168.0.254;

# Сказать клиентам, чтобы отдали адрес через 21600 секунд (6 часов) после получения адреса

default-lease-time 21600;

# Забрать адрес самому через 28800 секунд (8 часов)

max-lease-time 28800;

option netbios-name-servers 192.168.0.1;

option netbios-dd-server 192.168.0.1;

option netbios-node-type 8;

# Описание трех клиентов клиентов (dhcp50, dhcp51, dhcp52) и их аппаратных адресов

    host dhcp50 {

           hardware ethernet 00:40:C7:34:90:1E;

# Обратите внимание на то, что вы должны использовать IP-адрес из указанного ранее диапазона адресов

# 192.168.0.10-254.

           fixed-address 192.168.0.50;

                  }

    host dhcp51 {

           hardware ethernet 00:40:C7:34:90:1F;

           fixed-address 192.168.0.51;

                  }

    host dhcp52 {

           hardware ethernet 00:40:C7:34:90:2A;

           fixed-address 192.168.0.52;

                  }

}

Вот практически и все. Все ваши вопросы и комментарии присылайте по адресу [email protected].

samag.ru

События DHCP ведения журнала для регистрации записей DNS

• 07.11.2017
• Время чтения: 3 мин

В этой статье

Область применения: Windows Server (канал точками годовой), Windows Server 2016Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

Журналы событий DHCP-сервера теперь содержат подробные сведения об ошибках регистрации DNS.DHCP server event logs now provide detailed information about DNS registration failures.

Примечание

Во многих случаях причины сбоев регистрации записи DNS-сервера DHCP-серверами может быть отсутствие зоны Reverse\ просмотра DNS неправильно настроен или не настроена.In many cases, the reason for DNS record registration failures by DHCP servers is that a DNS Reverse-Lookup Zone is either configured incorrectly or not configured at all.

Следующие новые события DHCP поможет легко определить, когда отсутствуют зоны Reverse\ просмотра DNS или сбой из-за неправильно настроенный DNS-регистраций.The following new DHCP events assist you to easily identify when DNS registrations are failing because of a misconfigured or missing DNS Reverse-Lookup Zone.

ИДЕНТИФИКАТОРID СобытиеEvent ЗначениеValue

2031720317	DHCPv4.ForwardRecordDNSFailureDHCPv4.ForwardRecordDNSFailure	Вперед регистрации записи для IPv4-адрес %1 и полное доменное имя %2 произошла ошибка %3.Forward record registration for IPv4 address %1 and FQDN %2 failed with error %3. Это может быть, поскольку зону прямого просмотра для этой записи не существует на DNS-сервере.This is likely to be because the forward lookup zone for this record does not exist on the DNS server.
2031820318	DHCPv4.ForwardRecordDNSTimeoutDHCPv4.ForwardRecordDNSTimeout	Вперед регистрации записи для IPv4-адрес %1 и полное доменное имя %2 произошла ошибка %3.Forward record registration for IPv4 address %1 and FQDN %2 failed with error %3.
2031920319	DHCPv4.PTRRecordDNSFailureDHCPv4.PTRRecordDNSFailure	Регистрации записей PTR для IPv4-адрес %1 и полное доменное имя %2 произошла ошибка %3.PTR record registration for IPv4 address %1 and FQDN %2 failed with error %3. Это может произойти, если зона обратного просмотра для этой записи не существует на DNS-сервере.This is likely to be because the reverse lookup zone for this record does not exist on the DNS server.
2032020320	DHCPv4.PTRRecordDNSTimeoutDHCPv4.PTRRecordDNSTimeout	Регистрации записей PTR для IPv4-адрес %1 и полное доменное имя %2 произошла ошибка %3.PTR record registration for IPv4 address %1 and FQDN %2 failed with error %3.
2032120321	DHCPv6.ForwardRecordDNSFailureDHCPv6.ForwardRecordDNSFailure	Вперед регистрации записи для IPv6-адрес %1 и полное доменное имя %2 произошла ошибка %3.Forward record registration for IPv6 address %1 and FQDN %2 failed with error %3. Это может быть, поскольку зону прямого просмотра для этой записи не существует на DNS-сервере.This is likely to be because the forward lookup zone for this record does not exist on the DNS server.
2032220322	DHCPv6.ForwardRecordDNSTimeoutDHCPv6.ForwardRecordDNSTimeout	Вперед регистрации записи для IPv6-адрес %1 и полное доменное имя %2 произошла ошибка %3.Forward record registration for IPv6 address %1 and FQDN %2 failed with error %3.
2032320323	DHCPv6.PTRRecordDNSFailureDHCPv6.PTRRecordDNSFailure	Регистрации записей PTR для IPv6-адрес %1 и полное доменное имя %2 произошла ошибка %3.PTR record registration for IPv6 address %1 and FQDN %2 failed with error %3. Это может произойти, если зона обратного просмотра для этой записи не существует на DNS-сервере.This is likely to be because the reverse lookup zone for this record does not exist on the DNS server.
2032420324	DHCPv6.PTRRecordDNSTimeoutDHCPv6.PTRRecordDNSTimeout	Регистрации записей PTR для IPv6-адрес %1 и полное доменное имя %2 произошла ошибка %3.PTR record registration for IPv6 address %1 and FQDN %2 failed with error %3.
2032520325	DHCPv4.ForwardRecordDNSErrorDHCPv4.ForwardRecordDNSError	Произошел сбой регистрации записей PTR для IPv4-адрес %1 и полное доменное имя %2 ошибка %3 (%4).PTR record registration for IPv4 address %1 and FQDN %2 failed with error %3 (%4).
2032620326	DHCPv6.ForwardRecordDNSErrorDHCPv6.ForwardRecordDNSError	Вперед регистрации записи для IPv6-адрес %1 и полное доменное имя %2 не удалось (%4) Ошибка %3Forward record registration for IPv6 address %1 and FQDN %2 failed with error %3 (%4)
2032720327	DHCPv6.PTRRecordDNSErrorDHCPv6.PTRRecordDNSError	Произошел сбой регистрации записей PTR для IPv6-адрес %1 и полное доменное имя %2 ошибка %3 (%4).PTR record registration for IPv6 address %1 and FQDN %2 failed with error %3 (%4).

docs.microsoft.com

Аудит и устранение неисправностей DHCP в Windows Server

По умолчанию в Windows Server 2008 настроен аудит DHCP-процессов с записью информации в журналы.

Аудит DHCP

В устранении неисправностей DHCP-сервера вам помогут журналы аудита. По умолчанию оба протокола — IPv4 и IPv6 — производят запись в одни и те же журналы, но вы вольны настроить и раздельный аудит. Стандартное расположение журналов DHCP — %SystemRoot%\System32\DHCP. В этой папке помещены журналы для каждого дня недели. Файл журнала понедельника называется DhcpSrvLog-Mon.log, файл журнала вторника — Dhcp-SrvLog-Tue.log и т. д.

При запуске DHCP-сервера или наступлении нового дня в файл журнала записывается заголовок. В заголовке содержится сводка событий DHCP и значение событий. При остановке и запуске службы DHCP-сервер (DHCP Server) очистка файла журнала может не произойти. Она обязательно происходит по прошествии 24 часов с момента последней записи в журнал. Вам не нужно отслеживать использование дискового пространства службой DHCP-сервер (DHCP Server). Она по умолчанию настроена на ограничение используемого пространства. 

Включение и отключение аудита DHCP

Чтобы включить или отключить аудит DHCP, выполните следующие действия:

1. В консоли DHCP разверните узел нужного сервера. Щелкните правой кнопкой узел IPv4 или IPv6 и выберите Свойства (Properties).

2. На вкладке Общие (General) установите или сбросьте флажок Вести журнал аудита DHCP (Enable DHCP Audit Logging). Щелкните ОК.

Сейчас ожидается выход новой пользовательской версии Windows — Windows 8. Самые свежие новости о новой системе можно узнать на сайте Microsoft, или через блог windows 8 (http://windows8center.ru/) — расчитанный на русскоязычных пользователей. Одно из самых значительных изменений в Windows 8, как ожидается, будет заключаться в полностью переработоном интерфейсе система-пользователь. Поживём-увидим — релиз намечен на весну 2012 года!

Изменение расположения журналов аудита DHCP

По умолчанию журналы DHCP хранятся в папке %SystemRoot%\System32\DHCP. Чтобы изменить расположение журналов DHCP, выполните следующие действия:

1. В консоли DHCP разверните узел нужного сервера. Щелкните правой кнопкой узел IPv4 или IPv6 и выберите Свойства (Properties).

2. Перейдите на вкладку Дополнительно (Advanced). В поле Журнал аудита (Audit Log File Path) отображен текущий путь папки с файлами журналов. Введите новое расположение или укажите его при помощи кнопки Обзор (Browse).

3. Щелкните ОК. Системе Windows Server 2008 потребуется перезапустить службу DHCP-сервер (DHCP Server). Щелкните Да (Yes), чтобы подтвердить действие. Служба будет остановлена и заново запущена.

 

Изменение используемого журналом пространства

В службе DHCP-сервер (DHCP Server) имеется система самоконтроля, проверяющая использование дискового пространства. По умолчанию максимальный размер всех журналов DHCP-сервера составляет 70 Мб. Размер каждого журнала составляет одну седьмую часть от этого пространства. При достижении сервером предела в 70 Мб или при превышении отдельным журналом выделенного для него пространства регистрация деятельности DHCP прекращается, пока не будут очищены файлы журналов или место не освободится каким-либо иным способом. Обычно это происходит в начале нового дня, когда сервер очищает файл журнала прошлой недели.

Параметры реестра, регулирующие объем журнала и другие параметры DHCP, находятся в разделе HKEY_LOCAL_MACHINE\SYSTEM\Current-ControlSet\Services\DHCPServer\Parameters.

Следующие параметры управляют регистрацией событий:

• DhcpLogFilesMaxSize Максимальный размер всех журналов. Стандартное значение — 70 Мб.

• DhcpLogDiskSpaceCleanupInterval Частота проверки использования диска и очистки журнала. Стандартный интервал — 60 мин.

• DhcpLogMinSpaceOnDisk Порог свободного пространства, необходимый для записи в журнал. Если свободное пространство на диске меньше установленного значения, запись в журнал временно прекращается. Стандартное значение — 20 Мб.

Параметр DhcpLogMinSpaceOnDisk не создается автоматически. Вы должны сами создать его и задать подходящее для вашей сети значение.

logi.cc

Новые возможности DHCP | Microsoft Docs

• 03.02.2018
• Время чтения: 5 мин

В этой статье

Область применения: Windows Server (канал точками годовой), Windows Server 2016Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

В этом разделе описываются функции протокол динамической настройки узла (DHCP), добавленные или измененные в Windows Server 2016.This topic describes the Dynamic Host Configuration Protocol (DHCP) functionality that is new or changed in Windows Server 2016.

Протокол DHCP является стандартом IETF Internet Engineering Task Force (), разработанным для облегчения управления и упрощения настройки узлов сети основе требование TCP/IP, например частной интрасети.DHCP is an Internet Engineering Task Force (IETF) standard that is designed to reduce the administrative burden and complexity of configuring hosts on a TCP/IP-based network, such as a private intranet. С использованием службы DHCP-сервера процесс настройки протокола TCP/IP на DHCP-клиентах происходит автоматически.By using the DHCP Server service, the process of configuring TCP/IP on DHCP clients is automatic.

В следующих разделах сведения о новых функциях и изменениях в функциональных возможностях для DHCP.The following sections provide information about new features and changes in functionality for DHCP.

Выбор параметров DHCP подсетиDHCP Subnet Selection Options

Протокол DHCP теперь поддерживает параметры 118 и 82 (sub-option 5).DHCP now supports options 118 and 82 (sub-option 5). Эти параметры можно использовать для прокси-сервера DHCP-клиентов и агенты ретрансляции для запроса IP-адрес для конкретной подсети, а также из определенного диапазона IP-адресов и область.You can use these options to allow DHCP proxy clients and relay agents to request an IP address for a specific subnet, and from a specific IP address range and scope.

Если вы используете DHCP-клиента прокси-сервера, который настроен с параметром DHCP 118, например (VPN) сервер виртуальной частной сети, на котором работает Windows Server 2016 и роль сервера удаленного доступа, VPN-сервер может запросить аренду IP-адреса для VPN-клиентов из определенного диапазона IP-адресов.If you are using a DHCP proxy client that is configured with DHCP option 118, such as a virtual private network (VPN) server that is running Windows Server 2016 and the Remote Access server role, the VPN server can request an IP address lease for VPN clients from a specific IP address range.

Если вы используете агента ретрансляции DHCP, которая настроена с параметром DHCP 82 sub\ вариант 5, агент ретрансляции может запросить аренду IP-адреса для DHCP-клиентов из определенного диапазона IP-адресов.If you are using a DHCP relay agent that is configured with DHCP option 82, sub-option 5, the relay agent can request an IP address lease for DHCP clients from a specific IP address range.

Дополнительные сведения см. в разделе параметры выбора подсети DHCP.For more information, see DHCP Subnet Selection Options.

Новые в журнале событий наличие ошибок регистрации DNS, DHCP-серверNew Logging Events for DNS Registration Failures by the DHCP Server

Теперь DHCP включает ведение журнала событий для случаев, в которых DHCP регистрации записей DNS server не будет выполнена на DNS-сервере.DHCP now includes logging events for circumstances in which DHCP server DNS record registrations fail on the DNS server.

Дополнительные сведения см. в разделе события DHCP ведения журнала для регистрации записи DNS.For more information, see DHCP Logging Events for DNS Record Registrations.

DHCP NAP не поддерживается в Windows Server 2016DHCP NAP Is Not Supported in Windows Server 2016

Рекомендуется использовать (NAP) защиты доступа к сети в Windows Server 2012 R2 и в Windows Server 2016 роли DHCP-сервер больше не поддерживает защиту доступа к сети.Network Access Protection (NAP) is deprecated in Windows Server 2012 R2, and in Windows Server 2016 the DHCP Server role no longer supports NAP. Дополнительные сведения см. в разделе компоненты, удаленные или не рекомендуемые к использованию в Windows Server 2012 R2.For more information, see Features Removed or Deprecated in Windows Server 2012 R2.

Поддержка защиты доступа к сети появилась роли DHCP-сервера в Windows Server 2008 и поддерживается в клиентских и серверных операционных системах Windows до Windows 10 и Windows Server 2016.NAP support was introduced to the DHCP Server role with Windows Server 2008, and is supported in Windows client and server operating systems prior to Windows 10 and Windows Server 2016. В следующей таблице перечислены поддержка защиты доступа к сети в Windows Server.The following table summarizes support for NAP in Windows Server.

Операционная системаOperating system Поддержка защиты доступа к сетиNAP support

Windows Server 2008Windows Server 2008	ПоддерживаетсяSupported
Windows Server 2008 R2Windows Server 2008 R2	ПоддерживаетсяSupported
Windows Server 2012Windows Server 2012	ПоддерживаетсяSupported
Windows Server 2012 R2Windows Server 2012 R2	ПоддерживаетсяSupported
В Windows Server 2016Windows Server 2016	Не поддерживаетсяNot supported

При развертывании защиты доступа к сети DHCP-сервер под управлением операционной системы, который поддерживает защиту доступа к сети могут функционировать как точка NAP для метода принудительного применения защиты доступа к сети DHCP.In a NAP deployment, a DHCP server running an operating system that supports NAP can function as a NAP enforcement point for the NAP DHCP enforcement method. Дополнительные сведения о DHCP в защиты доступа к сети см. в разделе контрольный список: реализация проекта принудительное применение DHCP.For more information about DHCP in NAP, see Checklist: Implementing a DHCP Enforcement Design.

В Windows Server 2016 DHCP-серверы не применяют политики защиты доступа к сети и областей DHCP, не может быть включен NAP.In Windows Server 2016, DHCP servers do not enforce NAP policies, and DHCP scopes cannot be NAP-enabled. DHCP клиентских компьютеров, которые также являются клиентами NAP отправить отчет о работоспособности (SoH) с DHCP-запрос.DHCP client computers that are also NAP clients send a statement of health (SoH) with the DHCP request. Если DHCP-сервер работает под управлением Windows Server 2016, данные запросы обрабатываются как при наличии не состояния работоспособности.If the DHCP server is running Windows Server 2016, these requests are processed as if no SoH is present. DHCP-сервер предоставляет обычный аренды DHCP на клиенте.The DHCP server grants a normal DHCP lease to the client.

Если RADIUS-прокси, отправлять запросы на проверку подлинности (NPS) сервера политики сети, поддерживающий NAP, серверы под управлением Windows Server 2016 этих клиентов NAP оцениваются сервер политики сети не NAP\ поддерживающий и сбоя обработки защиты доступа к сети.If servers that are running Windows Server 2016 are RADIUS proxies that forward authentication requests to a Network Policy Server (NPS) that supports NAP, these NAP clients are evaluated by NPS as non NAP-capable, and NAP processing fails.

См. также:See also

docs.microsoft.com

Расскажу-ка я вам сказку о DHCP option 119

11:44 pm - Расскажу-ка я вам сказку о DHCP option 119

Жил да был юзер в корпоративной сети. И было у него помимо Windows laptop'а некоторое количество Linux и Mac машин.Жил он не тужил пока коллеги не начали присылать ссылки типа http://somelocalserver12345/somefile.bin

И озадачился тогда этот юзер, почему ссылки работают на Windows но не работают на Linux/Mac.

Беглым поиском было обнаруженно что у Windows есть спрятанные настройки "Primary DNS suffix: europe.corp.example.com" и "DNS suffix search list: europe.corp.example.com, fi.example.com, corp.example.com, example.com".

Естественно для Linux/Mac машин от великого корпоративного DHCP сервера приходило только DNS Domain = "fi.example.com". Юзер конечно расстроился, но поскольку был "умным" написал в поддержку и попросил включить на DHCP сервере опцию domain-search (option 119). Поддержка оказалась обычной, виндовой, и в итоге впала в ступор на несколько дней, приведя в качестве отмастки "у нас тут вот в таком windows диалоге управления DHCP сервером такой опции нет". После пары дней препирательства запрос был проэскалирован до инженеров которые знали чуть больше и знали как обойти стандартные окошки. В итоге, при помощи этих инженеров герой нашей сказки договорился в реальном времени опробовать и потестировать изменения на стороне сервера и как оно скажется на клиенте.

Инженер начал прописывать. Вариант как в описанно в руководстве по Windows DHCP сервер "просто пропишите строку разделенную запятыми" естественно не подошел. Windows посылало строки как есть, разделенных нулевым байтом. Linux/Mac отказывались принимать такое непотребство и тупо игнорировали эти значения. Второй вариант был опробован с разными разделителями: пробел, точка с запятой и т.д. Аналогичный результат. Еще был опробован вариант Array of Strings. Надо ли упоминать что оно не заработало тоже ?

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

Дурное дело не хитрое - был написан простенький скриптик:

#!/usr/bin/env python -tt import sys hl = [] for d in sys.argv[1:]: for p in d.split("."): hl.extend(["0x%02x" % len(p)] + [ "0x"+c.encode("hex") for c in p ]) hl.append("0x00") print ",".join(hl)

На выходе из него получалось нечто такое:0x06,0x65,0x75,0x72,0x6f,0x70,0x65,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00

Всё вот это бедному инженеру приходилось прописывать в окошке найстройки Windows DHCP server. Причем сделать copy&paste было нельзя. оно жадало чтобы каждый байтик был введен отдельно...

Но скоро сказка сказывается да не скоро дело делается. Вбили, пробуем - работает... Кажется...Тесты показывают что Mac и Linux теряют значение DNS Domain если в ответе DHCP сервера присутсвует DNS domain-search.

Меняем строку, прописываем.0x02,0x66,0x69,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x06,0x65,0x75,0x72,0x6f,0x70,0x65,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00

Пробуем - получаем забавные результаты в /etc/resolv.conf:MacOS 10.7 (вроде как все хорошо): domain - отсутсвует.search fi.example.com europe.corp.example.com corp.example.com example.com

CentOS6/RHEL6:domain - отсутвуетsearch fi.example.com. europe.corp.example.com. corp.example.com. example.com.

Debian (stable/testing):domain fi.example.comsearch fi.example.com. europe.corp.example.com. corp.example.com. example.com.

OpenSuSE 11.4/12.1:domain - отсутвуетsearch fi.example.com europe.corp.example.com corp.example.com example.com

Ubuntu 11.04:domain fi.example.comsearch fi.example.com fi.example.com. europe.corp.example.com. corp.example.com. example.com.

Ubuntu 12.04:domain - отсутвуетsearch fi.example.com europe.corp.example.com corp.example.com example.com

Fedora 15 (какая была под рукой, local.org домен пришел из /etc/sysconfig/network:HOSTNAME=fvm.local.org):domain fi.example.comsearch fi.example.com fi.example.com. europe.corp.example.com. corp.example.com. example.com. local.org

Результат называется - "найдите 10 отличий".

Мораль сей басни такова: будьте осторожны со своими желаниями. Инженеры третьего уровня поддержки могут их исполнить побайтно вбивая продиктованную вами строчку. Но не факт что рельзультат будет вменяемым, поскольку в рядах dhcp клиентов разброд и шатания.

На последок "one more thing" ®: для Cisco так же надо эту опцию прописывать байтиками, хотя и в своем формате. Но там хоть есть copy&paste.

print "Cisco: " + "".join([(".%s" % (x[2:]) if i and not i % 2 else x[2:]) for i, x in enumerate(hl)]) Настроение: tired

lvader.livejournal.com

Конфигурируем DHCP-серверы и настраиваем динамические обновления DNS::Журнал СА 9.2009

СЕРГЕЙ СУПРУНОВ, инженер электросвязи широкого ИТ-профиля. В свободное время изучает FreeBSD и Python и пытается осмыслить свою нелюбовь к KDE

Конфигурируем DHCP-серверы и настраиваем динамические обновления DNS[1]

Клиент, конечно, всегда прав. Но ровно настолько, насколько ему это позволено сервером.

Установка и настройка DHCP-сервера ISC

Наиболее популярной реализацией DHCP-сервера в UNIX-подобных системах является dhcpd-разработка Internet Systems Consortium (ISC). По умолчанию в состав FreeBSD эта программа не входит. Она довольно легко устанавливается из коллекции «Портов»:

# cd /usr/ports/net/isc-dhcp30-server/

# make install

Но, к сожалению, на момент подготовки статьи единственная версия, которую можно было без проблем установить – 3.0.7, – была сильно устаревшей (в марте 2009 года официально прекращена её поддержка).

В итоге было принято решение ставить ISC DHCP версии 4.1.0 из исходников (команда «./configure --help» после распаковки позволит просмотреть доступные опции конфигуратора; возможно, некоторые из них вы захотите использовать):

# fetch http://ftp.isc.org/isc/dhcp/dhcp-4.1.0.tar.gz

dhcp-4.1.0.tar.gz 100% of 1061 kB 174 kBps

# tar xzvf dhcp-4.1.0.tar.gz

# cd dhcp-4.1.0

# ./configure

# make

# make install

После установки придётся вручную подготовить сценарий автозапуска. За основу можно взять какой-нибудь из имеющихся в /usr/local/etc/rc.d или /etc/rc.d. Я здесь немного схитрил и воспользовался сценарием из порта isc-dhcp-30-server:

# cd /usr/ports/net/isc-dhcp30-server

# mkdir work

# make apply-slist

# cp work/isc-dhcpd /usr/local/etc/rc.d/

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

Есть один важный момент – для работы DHCP-сервера ядро системы должно быть собрано с поддержкой псевдоустройства bpf (Berkeley packet filter; используется для получения «сырых» данных с интерфейса, в т.ч. широковещательных пакетов). В ядро GENERIC эта поддержка всегда включается, так что если вы не исключали её явно, то пересборка ядра потребоваться не должна.

Проверить, включено ли это устройство в ваше ядро, можно так:

$ grep bpf /usr/src/sys/`uname -p`/conf/`uname -i`

# The `bpf' device enables the Berkeley Packet Filter.

# Note that 'bpf' is required for DHCP.

device bpf # Berkeley packet filter

Теперь добавим в /etc/rc.conf пару строк (правда, это будет работать лишь при условии, что обработка переменных предусмотрена сценарием автозапуска; в isc-dhcpd, который мы «выдрали» из портов, она предусмотрена):

dhcpd_enable="YES"

dhcpd_ifaces="nfe0"

Основные параметры задаются в файле /usr/local/etc/dhcpd.conf (файл-пример будет установлен во время инсталляции).

Рассмотрим пример не сложной, но вполне работоспособной конфигурации:

# Доменное имя. Имена хостов клиентов будут дополняться до FQHN

option domain-name "example.org";

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

# Можно использовать и IP-адреса оных

option domain-name-servers ns1.example.org, ns2.example.org;

# «Умолчальное» и максимальное времена аренды адреса  в секундах

default-lease-time 3600;

max-lease-time 86400;

# Является ли сервер авторитативным

authoritative;

# Способ динамического обновления DNS.

# Подробнее поговорим позже, сейчас отключим

ddns-update-style none;

# Источник сообщений для записи логов через syslogd

log-facility local7;

# Объявление подсети

subnet 192.168.1.0 netmask 255.255.255.0 {

   range 192.168.1.200 192.168.1.249;

   option routers 192.168.1.1;

}

В самом начале файла размещаются глобальные параметры, которые при необходимости могут быть переопределены далее, в отдельных «объявлениях» подсетей и диапазонов. Обычно здесь задаются имя домена, список DNS-серверов (если используются одни и те же для большинства обслуживаемых сетей), значения для времени аренды (по умолчанию максимальное, при необходимости можно задать минимальное).

Параметр authoritative позволяет объявить сервер авторитативным (ответственным) в обслуживаемой сети. Отличие авторитативного сервера от «обычного» заключается в том, что последний игнорирует любые запросы адресов, которые не описаны в его конфигурации, в то время как авторитативный сервер в ответ на такие запросы отсылает DHCPNAK. Благодаря такому поведению клиент, перемещённый из другой подсети, сможет быстрее получить новый адрес (в ответ на DHCPREQUEST с адресом из прежней подсети он сразу получит DHCPNAK и приступит к получению нового адреса; в противном случае DHCPDISCOVER будет отправлен лишь по истечении тайм-аута на ожидание ответа). В то же время «случайные» DHCP-серверы (например, ошибочно запущенные с настройками из файла-примера) с меньшей вероятностью смогут помешать работе сети, поскольку, будучи неавторитативными, будут просто игнорировать «чужие» запросы DHCPREQUEST.

Для ведения логов (а они никогда лишними не будут), помимо объявления источника (facility) в конфигурации dhcpd, вам нужно будет сделать ещё две вещи: создать файл протокола (например, командой «touch /var/log/dhcpd.log») и добавить строку в /etc/syslog.conf:

local7.* /var/log/dhcpd.log

После чего syslogd нужно перезапустить:

/etc/rc.d/syslogd restart

Ну и не забудьте настроить ротацию данного лог-файла в /etc/newsyslog.conf.

Вернёмся к конфигурации dhcpd. Всё самое интересное содержится в описании подсети subnet. В нашем примере всё элементарно – строкой range мы задаём диапазон адресов, которые dhcpd сможет «сдавать в аренду» клиентам, опция routers задаёт список маршрутов по умолчанию. Ещё одна обязательная для работы в сети настройка – адреса DNS‑серверов – будет получена из глобальной опции domain-name-servers.

Обратите внимание на то, что именно по описанию subnet авторитативный сервер будет различать «допустимые» и «недопустимые» адреса. Так, сервер, запущенный с приведённой выше конфигурацией, в ответ на запрос (DHCPREQUEST) адреса 192.168.0.22 будет возвращать DHCPNAK (поскольку запрошенный адрес в известную ему подсеть не попадает), но «промолчит» при запросе адреса 192.168.1.22 (т.к. этот адрес, хотя и не включён ни в один из диапазонов range, является правильным для данной подсети и вполне может обслуживаться вторым DHCP-сервером; об этом чуть подробнее поговорим через раздел).

Помимо диапазона адресов и шлюза в описании подсети можно задать огромное множество дополнительных опций. Полный список поддерживаемых опций можно найти в справке: man dhcp-options(5).

Если несколько подсетей доступны через один интерфейс, то их объявления subnet должны быть вложены в объявление shared-network:

shared-network rl0-net {

    subnet 192.168.1.0 netmask 255.255.255.0 {

        range 192.168.1.100 192.168.1.199;

        option routers 192.168.1.1;

    }

    subnet 192.168.2.0 netmask 255.255.255.0 {

        range 192.168.2.100 192.168.2.199;

        option routers 192.168.2.1;

    }

}

Общие для всех подсетей опции можно вынести непосредственно в объявление shared-network – в этом случае они будут влиять на все объявления subnet.

Пулы и классы

Иногда возникает необходимость разделять клиенты по тому или иному признаку и выдавать им разные опции. Например, мы хотим клиентам, имя хоста которых начинается на «a» (например, «acer»), раздавать адреса из диапазона 10.0.0.10 – 10.0.0.19, а всем остальным – из 10.0.0.20 – 10.0.0.99. Для этого можно использовать объявление класса и два так называемых пула:

class "a-clients" {

  match if substring (option host-name, 0, 1) = "a";

}

 

subnet 10.0.0.0 netmask 255.255.255.0 {

   pool {

      allow members of "a-clients";

      range 10.0.0.10 10.0.0.19;

   }

   pool {

      deny members of "a-clients";

      range 10.0.0.20 10.0.0.99;

   }

}

То есть мы отнесли к классу a-clients клиентские машины согласно приведённому выражению, а затем создали два пула, в одном из которых разрешили обслуживание членов соответствующего класса, в другом, наоборот, запретили. Аналогично можно строить выражения по MAC-адресу (переменная hardware) и другим опциям. Подробнее о синтаксисе выражений, допустимых в конфигурации dhcpd, можно почитать на странице man dhcp-eval(5).

Помимо признака членства в определённом классе команды allow/deny поддерживают выражения unknown-clients (клиенты, не передавшие свои имена хостов), known-clients (соответственно передавшие) и all clients (любые клиенты). Подробности ищите в документации.

Фиксированные адреса

Иногда возникает необходимость более чётко контролировать получение адресов некоторыми хостами. Например, выход в Интернет требуется лишь некоторым компьютерам локальной сети, а на прокси-сервере доступ регулируется по IP-адресу. Можно «избранным» хостам назначать вручную адреса, не попадающие в интервал, обслуживаемый сервером. А можно воспользоваться механизмом назначения фиксированных адресов, который предоставляет dhcpd:

host acer {

   hardware ethernet 00:1b:38:22:8c:17;

   fixed-address 10.161.193.177;

}

Если добавить этот фрагмент в конфигурационный файл (и не забыть перезапустить dhcpd), то данный хост будет всегда получать указанный IP-адрес. Идентификация хоста будет осуществляться по MAC-адресу. IP-адреса, закреплённые таким образом за определёнными хостами, не должны попадать ни в один из диапазонов range.

Если нужно описать несколько хостов, имеющих много одинаковых опций, их можно объединить в группу:

group {

   ...общие опции...

   host acer { ...специфичные для хоста опции ...}

   host fuji { ...специфичные для хоста опции ...}

}

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

Особенности использования нескольких DHCP-серверов

В сравнительно больших сетях по соображениям надёжности и балансировки нагрузки обычно используют несколько DHCP-серверов. Очевидно, что при этом необходимо избегать «перекрытия» адресного пространства, когда один и тот же IP-адрес может быть выдан различными серверами. В противном случае возможен конфликт – ведь если сервер «А» выдаст клиенту некоторый адрес, то сервер «Б» по-прежнему будет считать его свободным и может выдать его другому клиенту (клиент, перед тем как принять IP-адрес, должен с помощью ARP-запроса убедиться, что тот свободен; это несколько снижает вероятность конфликта, но всё же не исключает его полностью).

Классическая рекомендация, известная как «правило 80/20», звучит так: один сервер (основной) должен обслуживать 80% адресов пула, второй сервер (вспомогательный) – оставшиеся 20%. Это позволит сети «продержаться» некоторое время на одном вспомогательном сервере в случае проблем с основным, при условии, что не все клиенты начнут запрашивать адреса одновременно. Правда, применяя это правило в своей сети, желательно убедиться, что именно основной сервер является более быстрым – иначе вспомогательный сразу раздаст свой пул клиентам, и при возникновении нештатной ситуации ему просто нечего будет им предложить. (В настройках сервера ISC можно задать параметр min-secs, задающий задержку в секундах перед выдачей ответа клиенту. Её использование на вспомогательном сервере повысит шансы на то, что первым будет отвечать основной.)

Возникает вопрос – а не будут ли мешать друг другу два авторитативных DHCP-сервера? Если у них будет одинаковое объявление подсети (но разные, непересекающиеся интервалы адресов, описанные в range), то запрос адреса из такой подсети, даже не попадающий в обслуживаемый конкретным сервером диапазон, не будет рассматриваться как «чужой» – сервер просто ничего не будет отвечать, позволяя тем самым обработать этот запрос другому серверу. Если этот «другой сервер» недоступен, то клиент, не дождавшись ответа на DHCPREQUEST, отправит запрос DHCPDISCOVER и будет благополучно обслужен оставшимся в строю сервером.

Некоторые серверы (в частности, ISC), поддерживают так называемый механизм DHC-FAILOVER (подготовка соответствующего стандарта остановилась на документе http://tools.ietf.org/html/draft-ietf-dhc-failover-12), предоставляющий двум серверам возможность разделять общий пул IP-адресов, синхронизируя информацию о выданных адресах и позволяя динамически подменять друг друга при необходимости.

Динамический DNS

Итак, задачу автоматического получения настроек компьютерами сети мы решили. Но остался ещё один вопрос – интеграция с DNS-сервером. Конечно, в большинстве сетей можно обойтись и без этого – доступ по имени обычно бывает нужен только на серверы, которые в свою очередь практически всегда настраиваются вручную, и потому статического DNS вполне достаточно. Но иногда всё же бывает удобно, когда каждый клиентский компьютер доступен в сети под своим именем (особенно если на постоянство IP‑адреса положиться нельзя), поэтому рассмотрим, как настроить динамическое обновление DNS-записей (предполагая, что в качестве DNS-сервера используется ISC BIND).

Прежде всего в настройках DNS-сервера нужно разрешить автоматические обновления:

# Объявляем ключ доступа (можно задавать и в каждой зоне, но так удобнее)

key DHCP_KEY {

   algorithm hmac-md5;

   secret "c20f9433f5f5ecf1f245a6112d7dd651";

};

# «Прямая» зона

zone "test.inr" {

   type master;

   allow-update { key DHCP_KEY; };

   file "master/test.inr";

};

# «Обратная» зона

zone "0.0.10.in-addr.arpa" {

   type master;

   allow-update { key DHCP_KEY; };

   file "master/0.0.10.in-addr.arpa";

};

То есть мы объявляем ключ DHCP_KEY (имя может быть любым) и затем указываем его как условие, при котором будет разрешено обновление зоны (в описании всех зон, которые должны автоматически обновляться). Для генерации ключа (в строке secret) можно воспользоваться утилитой mmencode:

$ echo 'Super secret key' | mmencode

U3VwZXIgc2VjcmV0IGtleQo=

Неплохо справляется с задачей утилита md5:

$ echo 'Super secret key' | md5

25ecc0ad8ba5c6b56d85c8ae9811e881

Хотя более «правильным» способом формирования ключа считается использование утилиты dhssec-keygen:

$ dnssec-keygen -a HMAC-MD5 -b 128 -n HOST test.inr

Ktest.inr.+157+41531

$ ls -l Ktest.inr.+157+41531.*

-rw------- 1 amsand amsand 52 11 авг 19:08 Ktest.inr.+157+41531.key

-rw------- 1 amsand amsand 92 11 авг 19:08 Ktest.inr.+157+41531.private

Здесь мы создаём «хостовый» ключ длиной 128 бит, используя алгоритм HMAC-MD5, с именем test.inr. В результате формируется два файла – ключ можно извлечь из любого.

Ну и для повышения безопасности (поскольку файл named.conf обычно доступен на чтение всем пользователям) оператор key выносят в отдельный файл, доступный на чтение только пользователю root, а в named.conf подключают его с помощью оператора include:

include "key.conf";

Вместо allow-update можно использовать более «мощную» секцию update-policy (дополнительно ограничим тип записей и поддомен):

zone "test.inr" {

   type master;

   update-policy {

      grant DHCP_KEY subdomain test.inr A TXT;

   };

   file "master/test.inr";

};

Теперь осталось внести некоторые изменения в конфигурацию DHCP:

# Указываем метод обновления (существует ещё ad-hoc, но он не рекомендуется)

ddns-update-style interim;

# Описываем тот же ключ (можно просто скопировать из named.conf – синтаксис тот же)

# Если оператор key вынесен в отдельный файл, можно, как и в named.conf, использовать оператор include:

### include "key.conf";

key DHCP_KEY {

   algorithm hmac-md5;

   secret "c20f9433f5f5ecf1f245a6112d7dd651";

}

# «Прямая» зона, которую нужно обновлять

zone test.inr {

   primary 10.0.0.220;

   key DHCP_KEY;

}

# «Обратная» зона, которую нужно обновлять

zone 0.0.10.in-addr.arpa {

   primary 10.0.0.220;

   key DHCP_KEY;

}

В параметре primary при описании зон указывается адрес первичного DNS-сервера, обслуживающего зону (т.е. того, на который следует отправлять обновления).

Теперь осталось убедиться, что пользователь, от имени которого выполняется процесс named (на FreeBSD это обычно bind), имеет право создавать файлы в каталоге /var/named/etc/namedb/master.

Если всё сделано правильно, то после того как клиент в следующий раз запросит адрес, в каталоге master появятся файлы, соответствующие файлам зон, с расширением jnl. Это – журналы обновлений, используемые сервером для восстановления соответствующей информации после перезагрузки. В них-то и будут храниться соответствующие ресурсные записи (в двоичном формате, поэтому их чтение ничего полезного вам не даст).

В случае проблем обращайтесь к лог-файлам. Ниже показаны два сообщения из /var/log/messages, с которыми приходится сталкиваться наиболее часто:

May 4 17:23:14 freetest dhcpd: if acer.example.org IN A rrset doesn't exist add acer.example.org 300 IN A 10.0.0.180: timed out.

May 4 17:27:23 freetest named[95949]: master/test.inr.jnl: create: permission denied

Первая запись в данном случае вызвана нестыковкой доменных имён – в конфигурации DHCP был задан «умолчальный» домен example.org, который нашим DNS-сервером не обслуживается. К сожалению, это не единственная причина возникновения тайм-аута – следует рассматривать также права доступа к соответствующим файлам, правила пакетных фильтров (если DHCP и DNS работают на разных машинах), правильность указания адреса DNS-сервера.

Вторая указывает на то, что процесс named не может создать jnl-файл в каталоге master. Очевидно, что проблема кроется в правах доступа – позаботьтесь, чтобы процесс named мог создавать файлы в каталоге master, и проблема исчезнет.

***

Как видите, DHCP – довольно мощный протокол, позволяющий автоматизировать весьма значительную часть процесса настройки сети. К сожалению, из-за некоторой «сырости» в плане стандартизации и определённых проблем безопасности о 100-процентной автоматизации пока говорить не приходится. Но это не мешает его использовать уже прямо сейчас.

Приложение

WIDE DHCP

Нужно сказать, что ISC DHCP – не единственный вариант. В коллекции портов можно найти ещё один DHCP-сервер – WIDE DHCP. Правда, этот проект трудно назвать «действующим» – текущая версия в «Портах» (1.4.0.6_2) практически не обновлялась с 2003 года, страничка проекта (http://www.sfc.wide.ad.jp/~tomy/dhcp/index-e.html) заброшена. Тем не менее с основной задачей он вполне справляется.

Установка из коллекции портов потребует дополнительной работы. Начало традиционно:

# cd /usr/ports/net-mgmt/wide-dhcp

# make install

В итоге в /usr/local/sbin появится файл dhcps, будет создан сценарий автозапуска, а также добавятся соответствующие man-страницы.

После этого нужно подправить сценарий автозапуска /usr/local/etc/rc.d/wide-dhcps.sh.sample (и переименовать его в wide-dhcps.sh). Мало того, что он в «старом» формате (т.е. не подготовлен для утилиты rcorder), так ещё и недоработан. Пришлось вручную ввести переменную PREFIX и добавить в строку запуска dhcps опции, определяющие местоположение конфигурационных файлов и баз данных. В этой же строке нужно указать интерфейсы, на которых dhcps должен работать.

Далее файлы dhcpdb.pool и dhcpdb.relay нужно будет создать вручную (по умолчанию в /etc, я изменил каталог на /usr/local/etc, как это принято во FreeBSD). Примеры можно найти в каталоге db_sample дистрибутива. Второй из них служит для указания маршрутизаторов, через которые доступны другие подсети, обслуживаемые этим DHCP-сервером, и в случае «линейной» структуры сети его можно оставить пустым (но сам файл должен существовать). Первый же – это основной конфигурационный файл. Приведу несложный пример:

# Создаём подсеть (сюда выносим общие параметры:

# маску, шлюз и широковещательный адрес)

subnet:snmk=255.255.255.0:rout=10.0.0.1:brda=10.0.0.255:

# Далее идут описания каждого адреса пула

# (первое поле – просто идентификатор записи,

# далее задаются IP-адрес, время аренды (по умолч. и макс.),

# а также подключается определённая выше конфигурация subnet)

ip198: :ipad=10.0.0.198:dfll=3600:maxl=7200:tblc=subnet:

ip199: :ipad=10.0.0.199:dfll=3600:maxl=7200:tblc=subnet:

Как видите, для каждого адреса пула нужно прописывать свою строку, но зато и каждому адресу можно выдать свои параметры. Используется тот же формат файла, что и для системных баз termcap, printcap и т.п.; список доступных параметров достаточно обширен (найти его можно на странице справки man dhcpdb.pool(5)).

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

Вопросы безопасности

К сожалению, безопасность протокола DHCP пока оставляет желать лучшего. Рабочими группами IETF предлагаются различные методы её повышения (например, аутентификация клиентов, см. RFC 3118), но они в большинстве своём ещё нигде не реализованы.

Пока же наиболее действенной является рекомендация закрыть UDP-порты 67 и 68 по периметру сети и по возможности более строго контролировать оборудование, работающее внутри.

DHCP Relay

Как упоминалось в первой части статьи, в протоколе DHCP активно используются широковещательные запросы, которые практически всегда отбрасываются маршрутизаторами. То есть их распространение обычно ограничено одним сегментом локальной сети.

Однако зачастую оказывается нецелесообразно устанавливать отдельный DHCP-сервер в каждом сегменте. В этом случае на помощь приходит способность большинства маршрутизаторов работать в режиме DHCP Relay, «перебрасывая» запросы и ответы между отдельными подсетями. Принцип работы такого «прокси-сервера» заключается в следующем: получив на одном из обслуживаемых интерфейсов широковещательный DHCP-запрос, он перенаправляет его (уже обычным, одноадресным пакетом) определённым в его конфигурации DHCP-серверам. Полученный ответ транслируется широковещательным (при необходимости) пакетом в ту подсеть, откуда пришёл исходный запрос.

Большинство аппаратных маршрутизаторов функцию DHCP Relay поддерживают. Если же роль маршрутизатора между вашими подсетями выполняет FreeBSD или Linux, то можно установить либо программу dhcrelay, входящую в состав пакета ISC DHCP, либо отдельный сервер из коллекции портов – /usr/ports/net/dhcprelay. Настройка в обоих случаях сводится к запуску этой программы с опциями, определяющими список прослушиваемых интерфейсов и список DHCP-серверов, которым запрос нужно ретранслировать. Во FreeBSD в случае программы dhcprelay для её автозапуска достаточно включить в /etc/rc.conf три строки:

dhcprelay_enable='YES'

dhcprelay_server='10.0.0.220'

dhcprelay_ifaces='ed0

Кстати, функция DHCP Relay в некотором роде повышает управляемость сети, поскольку позволяет явно задать список DHCP-серверов, с которыми следует работать.

Утилита nsupdate

В дистрибутиве ISC BIND есть утилита, позволяющая отправлять динамические обновления DNS. Она может пригодиться как для поиска проблем (например, если при выдаче клиенту адреса сервером DHCP обновление зоны не происходит, но через nsupdate зоны обновляются нормально, становится очевидным, что следует разбираться с конфигурацией dhcpd), так и для обновления зон «вручную».

Рассмотрим типичный пример работы:

$ nsupdate -v

> server 10.0.0.220

> key DHCP_KEY c20f9433f5f5ecf1f245a6112d7dd651

> update add new.test.inr 300 A 10.1.1.15

> show

Outgoing update query:

;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0

;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0

;; UPDATE SECTION:

new.test.inr. 300 IN A 10.1.1.15

> send

> quit

То есть мы объявляем DNS-сервер и секретный ключ, после чего командой update add помещаем в «очередь» команду на добавление соответствующей записи (300 в данном примере – время жизни записи). Командой show можно просмотреть текущее состояние «очереди», send отправляет данный пакет серверу. Если всё прошло нормально (а поскольку никаких сообщений об ошибках не выведено, то так и должно быть), то, запросив у DNS-сервера адрес для new.test.inr, вы получите 10.1.1.15. (Да, этот адрес не является допустимым для нашей подсети, но в эти «тонкости» DNS-сервер не вдаётся – он просто делает свою работу.)

Помимо интерактивного режима работы nsupdate позволяет выполнять команды из файла, что может оказаться полезным для автоматического выполнения обновлений. Подробности ищите в справке man nsupdate(8).

1. Страница официального сайта ISC DHCP – https://www.isc.org/software/dhcp.
2. Колисниченко Д. Конфигурирование DHCP. //Системный администратор, №5, 2003 г. – С. 12-14 (http://www.algoint.ru/?MenuItem=tech_dhcp2).
3. Иванов П. DHCP: искусство управления IP-адресами. – http://www.citforum.ru/internet/tifamily/dhcp.shtml.
4. Bog BOS: Протокол BOOTP/DHCP – http://www.bog.pp.ru/work/bootp.html.
5. RFC 2131. Dynamic Host Configuration Protocol – http://tools.ietf.org/html/rfc2131.
6. RFC 2132. DHCP Options and BOOTP Vendor Extensions – http://tools.ietf.org/html/rfc2132.
7. DHCP Failover Protocol – http://tools.ietf.org/html/draft-ietf-dhc-failover-12.
8. DHCP Failover – http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ciscoasu/nr/nr3.0/concepts/cg03.htm.
9. Authentication for DHCP Messages – http://www.ietf.org/rfc/rfc3118.txt.
10. Настройка статических маршрутов через DHCP в Windows и Linux – http://www.linux.by/wiki/index.php/FAQ_DHCP_routes.
11. RFC 2136. Dynamic Updates in the Domain Name System (DNS UPDATE) – http://www.ietf.org/rfc/rfc2136.txt.

samag.ru

---

Смотрите также

• 
  Журнал вайнах
• 
  Журнал спальня
• 
  Журнал рязгму
• 
  Журнал опозданий
• 
  Журнал chkdsk
• 
  Chkdsk журнал
• 
  Title журнал
• 
  Пасечный журнал
• 
  Уют журнал
• 
  Журнал конт
• 
  Журнал суши