Сисадмин должен быть ленив. DHCP и динамический DNS::Журнал СА 8.2009
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Архив номеров
Контакты
   

  Опросы
  Статьи

Электронный документооборот  

5 способов повысить безопасность электронной подписи

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

 Читать далее...

Рынок труда  

Системные администраторы по-прежнему востребованы и незаменимы

Системные администраторы, практически, есть везде. Порой их не видно и не слышно,

 Читать далее...

Учебные центры  

Карьерные мечты нужно воплощать! А мы поможем

Школа Bell Integrator открывает свои двери для всех, кто хочет освоить перспективную

 Читать далее...

Гость номера  

Дмитрий Галов: «Нельзя сказать, что люди становятся доверчивее, скорее эволюционирует ландшафт киберугроз»

Использование мобильных устройств растет. А вместе с ними быстро растет количество мобильных

 Читать далее...

Прошу слова  

Твердая рука в бархатной перчатке: принципы soft skills

Лауреат Нобелевской премии, специалист по рынку труда, профессор Лондонской школы экономики Кристофер

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 9943
Комментарии: 0
Потоковая обработка данных

 Читать далее...

19.03.2018г.
Просмотров: 8155
Комментарии: 0
Релевантный поиск с использованием Elasticsearch и Solr

 Читать далее...

19.03.2018г.
Просмотров: 8259
Комментарии: 0
Конкурентное программирование на SCALA

 Читать далее...

19.03.2018г.
Просмотров: 5226
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 5912
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

Друзья сайта  

 Сисадмин должен быть ленив. DHCP и динамический DNS

Архив номеров / 2009 / Выпуск №8 (81) / Сисадмин должен быть ленив. DHCP и динамический DNS

Рубрика: Сети /  Сети

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

Сисадмин должен быть ленив
DHCP и динамический DNS

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

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

Динамическое конфигурирование сети позволяет решить ряд проблем. Во-первых, администратор освобождается от необходимости следить за настройками каждой отдельно взятой машины, вести учёт уже выданных адресов, дабы исключить конфликты. Во-вторых, изменение адреса DNS-сервера, шлюза доступа в Интернет или переход на другую подсеть IP-адресов уже не потребуют обхода всех компьютеров и ручной перенастройки. В-третьих, упрощается процедура расширения сети или подключение-отключение мобильных устройств.

Часто упоминают также экономию адресного пространства (когда 30 человек, работающих посменно, смогут довольствоваться 12-ю адресами), но поскольку сети на реальных IP‑адресах сейчас строят крайне редко, а в «серых» недостатка не бывает, более актуальной выглядит проблема простоя компьютеров, а не экономии адресов.

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

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

Если же у вас сравнительно небольшая бездоменная сеть, в составе которой к тому же есть машины с различными ОС, и вы хотите организовать динамическую конфигурацию сетевых параметров, то достаточно неплохим решением видится настройка DHCP-сервера на одной из UNIX-машин. В статье мы будем использовать FreeBSD.

Основы протокола DHCP

Начнём с рассмотрения общих принципов протокола динамической конфигурации хостов – DHCP. Этот протокол описан в RFC 2131 (некоторым расширениям посвящён RFC 2132 и другие документы) и решает задачу снабжения компьютеров необходимыми для работы в сети параметрами, такими как IP-адрес, маска подсети, шлюз по умолчанию, адреса DNS-серверов.

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

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

Стандартные рекомендации в этих случаях – для «динамичных» (например, тестовых или лабораторных) сетей задавать по возможности небольшое время аренды (один час или даже десять-пятнадцать минут); для стабильно работающих офисных сетей адреса можно выдавать и на неделю или даже месяц (за месяц перед предстоящей сменой параметров сети можно будет уменьшить максимальное время аренды до одного дня, а после изменений – вернуть обратно увеличенное время аренды). В любом случае имеет смысл пересмотреть значения по умолчанию (например, сервер ISC изначально использует 10-минутную аренду при максимальном времени владения IP-адресом 2 часа; для большинства сетей эти значения трудно назвать оптимальными).

Впрочем, невысокое время аренды не означает, что по его истечении клиент будет «отлучён от сети». Протокол DHCP предусматривает процедуру «продления аренды» клиентом, когда срок аренды истекает, но клиент ещё продолжает работать.

Рассмотрим в общих чертах, как происходит процесс получения сетевых параметров (см. рис. 1):

  •  После загрузки система клиента отправляет широковещательный (по адресу 255.255.255.255) запрос DHCPDISCOVER, цель которого – поиск доступных в данной сети DHCP-серверов. В качестве транспорта используется протокол UDP; серверы ожидают запросы на порту 67, клиенты используют 68-й порт.
  •  Все DHCP-серверы, получившие этот запрос (как правило, распространение широковещательных запросов ограничивается одним сегментом локальной сети, поэтому речь идёт о серверах, размещённых в том же сегменте, хотя возможно и «проксирование» запросов в другие сегменты, о чём мы поговорим отдельно), отправляют (опять-таки, широковещательным пакетом, так как клиент ещё не имеет адреса) свои «предложения» DHCPOFFER, в которых указывают предлагаемый клиенту IP-адрес.
  •  Клиент выбирает одно из поступивших предложений (как правило, предпочтение отдаётся первому полученному ответу) и направляет запрос DHCPREQUEST, указывая, какой из предложенных адресов он хотел бы получить, а также сообщая свои «пожелания» по дополнительным параметрам.
  •  Сервер, направивший предложение, устроившее клиентскую систему, отвечает либо пакетом DHCPACK, подтверждающим, что клиенту выдан данный IP-адрес, либо пакетом DHCPNAK, в случае, если выделение данного адреса уже невозможно по тем или иным причинам. В последнем случае клиент будет вынужден начинать процесс получения адреса заново.

Рисунок 1. Обмен пакетами между клиентом и сервером

Рисунок 1. Обмен пакетами между клиентом и сервером

Если компьютер-клиент уже работал ранее в сети и когда-то получал IP-адрес, то в этом случае, как правило, он сразу начинает процесс получения сетевых параметров с запроса DHCPREQUEST, указывая свой «старый» адрес в надежде на то, что он свободен и сразу будет выдан снова тем же DHCP-сервером, с которым шла работа раньше. Если адрес действительно свободен и сервер готов предложить его этому же клиенту, клиент сразу получит DHCPACK и сможет приступать к работе.

В противном случае (IP-адрес занят другим клиентом либо DHCP-сервер, обслуживающий его, недоступен) клиенту придётся проходить всю процедуру, начиная с DHCPDISCOVER.

Ещё один момент – продление аренды. В процессе работы клиент не ждёт, когда аренда выданного ему адреса истечёт, и пытается продлить время его использования заранее, для чего отправляется всё тот же пакет DHCPREQUEST спустя некоторый интервал времени (renewal-time), часто называемый T1 (обычно составляет 50% от времени аренды). Если сервер, отвечающий за данный адрес, доступен и не имеет причин отказать в продлении аренды, то клиент получает DHCPACK и начинает «отсчитывать» срок аренды заново.

Если же ответ сервера отсутствует, то клиент продолжает использование адреса до истечения срока первоначальной аренды, но время от времени предпринимает попытки её продлить. Если к некоторому моменту времени (rebinding-time, или T2, обычно около 90% от времени аренды) попытки продления не увенчались успехом, клиент отправляет запрос DHCPDISCOVER, чтобы получить хоть какой-нибудь адрес до того, как он лишится возможности работать в сети.

Таким образом, относительно времени аренды можно сказать следующее:

  •  интенсивность запросов к DHCP-серверу будет обратно пропорциональна интервалу T1: чем он меньше, тем чаще клиенты будут обращаться за продлением аренды;
  •  продолжительность допустимого перерыва в работе сервера можно определить как разницу между временем аренды и значением T1: если клиент получает адрес на 48 часов, а запрашивать продление аренды начинает через 24 часа, то у администратора сети остаётся ещё 24 часа в запасе на решение проблем с сервером;
  •  «переходный период», в течение которого все клиенты гарантированно получат обновлённые параметры, равен времени аренды IP-адреса.

Помимо вышеупомянутых пакетов DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK и DHCPNAK, протоколом предусмотрены ещё три:

DHCPRELEASE – им клиент может освободить выданный ему адрес до истечения срока аренды;

DHCPDECLINE – так клиент сообщает серверу, что предложенный им адрес кем-то уже занят, проверка занятости адреса осуществляется ARP-запросом;

DHCPINFORM – этот пакет используется, если клиент уже получил IP-адрес из других источников, а у DHCP-сервера запрашивает лишь дополнительные параметры, такие как адреса шлюзов, DNS-серверов и т.п.

DHCP-клиенты

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

Рассмотрим более подробно утилиту dhclient, входящую в состав FreeBSD. В простейшем случае её использование сводится к команде:

dhclient <имя_интерфейса>

Работа может сопровождаться диагностическими сообщениями, например:

# dhclient nfe0

 

DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 6

DHCPOFFER from 10.0.0.220

DHCPREQUEST on nfe0 to 255.255.255.255 port 67

DHCPACK from 10.0.0.220

bound to 10.0.0.198 -- renewal in 129600 seconds.

 

В случае если адрес будет получен, запустятся два демона dhclient (один с правами root, второй от имени пользователя _dhcp, что обеспечивает необходимое разграничение прав доступа), «привязанные» к соответствующему интерфейсу, которые возьмут на себя заботу о своевременном продлении аренды. При отключении интерфейса (команда ifconfig nfe0 down) демоны dhclient также будут остановлены.

Помимо настройки соответствующего интерфейса, DHCP-клиент может вносить изменения и в конфигурацию других сетевых служб: изменять /etc/resolv.conf согласно полученным от сервера адресам DNS-серверов, добавлять статические маршруты в таблицу маршрутизации и т.п.

Все полученные от DHCP-сервера параметры сохраняются в некотором файле для использования в будущем. В частности, из этого файла система узнаёт при последующей загрузке, получала ли она адрес ранее и можно ли сразу «попытать счастье», отправив DHCPREQUEST вместо DHCPDISCOVER. Например, во FreeBSD эти данные сохраняются в файлах /var/db/dhclient.leases.<имя_интерфейса>:

# cat /var/db/dhclient.leases.nfe0

lease {

  interface "nfe0";

  fixed-address 10.0.0.198;

  option subnet-mask 255.255.255.0;

  option routers 10.0.0.220;

  option domain-name-servers 10.0.0.220;

  option dhcp-lease-time 259200;

  option dhcp-message-type 5;

  option dhcp-server-identifier 10.0.0.220;

  option dhcp-renewal-time 129600;

  option dhcp-rebinding-time 226800;

  renew 2 2009/2/17 03:11:11;

  rebind 3 2009/2/18 06:11:11;

  expire 3 2009/2/18 15:11:11;

}

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

В большинстве случаев dhclient.conf пуст, и вам вряд ли потребуется изменять параметры по умолчанию. Но если всё же придётся, имейте в виду, что в этом файле можно изменить:

  •  временные параметры работы (тайм-аут ожидания ответа, интервал отправки повторных запросов и ряд других);
  •  перечень обязательных опций, которые сервер должен будет предоставить клиенту, а также желательных опций, которые клиент хотел бы получить от сервера;
  • значения опций по умолчанию (которые будут использоваться, если ни один из серверов не определит иное значение), а также значения тех опций, которые будут перекрывать или дополнять полученные от сервера;
  • адреса «плохих» DHCP-серверов, предложения которых будут отклоняться.

Пример файла можно посмотреть в справке (man dhclient.conf(5). Пожалуй, чуть подробнее следует остановиться на дополнительных опциях (полное описание вы найдёте на страницах справки dhcp-options(5). Наиболее полезные среди них: routers (шлюзы по умолчанию), domain-name-servers (DNS-серверы), static-routes (статические маршруты). Также можно указать имена smtp-, pop-, www-серверов, задавать TTL, MTU и другие параметры функционирования сети. Все эти опции можно либо задать вручную в настройках клиента, либо запросить у сервера.

Таким образом, набор доступных опций и возможность в определённой степени управлять их значениями позволяют вам занимать любую промежуточную позицию между двумя крайностями – «всё настраивать вручную» и «всё слепо получать от сервера».

Клиенты в Linux и Windows

В системах GNU/Linux в подавляющем большинстве случаев в качестве DHCP-клиента используется либо рассмотренная выше dhclient разработки ISC, либо программа dhcpcd (при желании её можно установить и во FreeBSD). Рассмотрим чуть подробнее вторую.

Запуск осуществляется командой:

dhcpcd <интерфейс>

где <интерфейс> – имя интерфейса, который будет обслуживаться клиентом dhcpcd. Дополнительно в командной строке можно задать ряд опций, таких как имя хоста, время аренды, запретить запрос шлюзов по умолчанию, адресов DNS-серверов и т.п. (см. man dhcpcd(8). Полученные от сервера данные сохраняются в файле dhcpcd-<интерфейс>.lease или dhcpcd-<интерфейс>.info, точное месторасположение которого зависит от системы (обычно /var/lib/dhcpcd).

Команда:

dhcpcd -k <интерфейс>

позволяет досрочно освободить полученный IP-адрес.

В системах MS Windows DHCP-клиент, как водится, спрятан глубоко в недра системы (в библиотеку dhcpcsvc.dll). Для динамического получения IP-адреса в свойствах протокола TCP/IP соответствующей сетевой карты выбирается опция «Получить IP-адрес автоматически». Вручную обновление IP-адреса можно выполнить с помощью утилиты ipconfig: ipconfig /release высвободит используемый в данный момент адрес, ipconfig /renew запросит адрес повторно.

Хранятся настройки DHCP-клиента и данные, полученные от сервера (текущий IP-адрес, маска подсети, адреса шлюзов и DNS-серверов, время истечения срока аренды, значения T1 и T2) в реестре, в ветви [HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\Tcpip\Parameters\ Interfaces]. Хотя без нужды туда лучше не лазить.

***

В этой части мы рассмотрели общие вопросы работы службы DHCP и наиболее популярных DHCP-клиентов. Следующая будет посвящена настройке DHCP-сервера и динамическим обновлениям DNS.

Приложение

Диагностические утилиты

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

Поэтому рекомендую установить маленькую (всего 75 Кб), но полезную утилиту – dhcping (есть в Портах). Принцип её действия заключается в следующем: утилита отправляет указанному серверу (обычным, не широковещательным, запросом) пакет DHCPREQUEST с просьбой выдать адрес 0.0.0.0. Любой разумный сервер (при условии, что он объявлен как авторитативный) ответит на это пакетом DHCPNAK. По этому ответу dhcping определяет, что сервер работоспособен, и завершает сеанс пакетом DHCPRELEASE.

Вы же получите на экране результат:

# dhcping -s 10.0.0.220

Got answer from: 10.0.0.220

В случае отсутствия ответа утилита так и сообщит: «no answer». Только имейте в виду, что такая проверка годится лишь для «авторитативных» серверов – все остальные просто проигнорируют неправильный DHCPREQUEST. Настройку серверов мы рассмотрим во второй части статьи.

Ещё одна полезная утилита – dhcpdump. Указав в качестве параметра имя интересующего вас интерфейса, вы получите расшифровку всех зафиксированных на нём DHCP-пакетов (см. рис. 2).

Рисунок 2. Один из пакетов, обработанных dhcpdump

Рисунок 2. Один из пакетов, обработанных dhcpdump

Как видите, информация исчерпывающая и может оказаться полезной как для решения проблем, так и для изучения работы того или иного клиента или сервера. Наименования полей соответствуют протоколу (дополнительную информацию можно получить на странице http://ru.wikipedia.org/wiki/DHCP).

В частности, на рисунке показан запрос DHCPREQUEST, сделанный клиентом acer (10.0.0.198) в надежде продлить аренду своего адреса.

«Встроенные» DHCP-серверы

Если ваша сеть совсем небольшая, а от DHCP-сервера требуется лишь раздача основных параметров (IP-адреса, маски, шлюза и адресов DNS-серверов), то в наши дни вам необязательно возиться с поиском пригодной для выполнения данной задачи машины, инсталляцией каких-то пакетов, их настройкой и последующим поддержанием работоспособности. Существует большое число устройств, способных взять на себя настройку сети при вашем минимальном участии.

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

Аппаратные маршрутизаторы также практически все имеют функцию DHCP-сервера, независимо от класса и стоимости устройства. Правда, нужно иметь в виду, что маршрутизаторы «низшего ценового диапазона», так же как и большинство DSL-модемов, жёстко передают в качестве шлюза по умолчанию свой адрес, не позволяя это изменить. То есть использовать такие устройства в качестве выделенного DHCP-сервера, когда за маршрутизацию отвечает другая «железка», будет весьма затруднительно.

Также DHCP-сервер можно найти в некоторых коммутаторах уровня Layer3. Только не путайте эту функцию с DHCP-Relay (способностью транслировать DHCP-запросы в другие подсети) – последняя встречается довольно часто, в то время как коммутатор с полноценным DHCP-сервером нужно ещё поискать.

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

 


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru