Разработки в области DHCP и динамической DNS должны облегчить управление IP-адресами и именами доменов.


ОСНОВЫ TCP/IP
DHCP: ЗАКЛИНАНИЕ IP?
ХОСТ ПОД ЛЮБЫМ ДРУГИМ ИМЕНЕМ
КТО СТУЧИТСЯ В ДВЕРЬ КО МНЕ?
ДИНАМИЧЕСКИЕ ПАКЕТЫ
ПЕРЕКОНФИГУРАЦИЯ DHCP

Вследствие гигантского спроса на доступ в Internet и стремления больших и малых компаний построить идеальную корпоративную сеть Intranet, администраторы сетей сталкиваются с многочисленными сложностями в управлении IP-адресами и именами доменов. Последние разработки в области протокола динамической конфигурации хоста (Dynamic Host Configuration Protocol, DHCP) и динамической системы имен доменов (Domain Name Service) открывают перед ними новую альтернативу.

ОСНОВЫ TCP/IP

TCP/IP - это не один протокол, а скорее семейство или комплект взаимосвязанных протоколов. Протокол TCP связывает высокоуровневые сервисы с IP, а тот в свою очередь взаимодействует с протоколом канального уровня. На Рисунке 1 изображена иерархия семейства протоколов TCP/IP в сопоставлении с эталонной моделью ISO OSI.

Picture_1

Рисунок 1.
Стек протоколов TCP/IP показан в сравнении с эталонной моделью OSI. В иерархии TCP/IP протоколы TCP и IP служат связующими звеньями между высокоуровневыми и низкоуровневыми протоколами.

Сетевые устройства, использующие TCP/IP, такие как компьютеры, принтеры, маршрутизаторы и концентраторы, нуждаются в способе идентификации друг друга. Это достигается с помощью схемы адресации IP, при которой каждый объект, или "хост", получает числовой идентификационный код в виде четырех 8-разрядных сегментов (или октетов) из 32-разрядного адресного пространства, причем значение каждого сегмента варьируется от 0 до 255. Схема идентификации IP напоминает чем-то принцип образования телефонных номеров, согласно которому местоположение абонента определяется в соответствии с иерархией "код города-префикс АТС-номер".

Например, рабочая станция может иметь такой IP-адрес: 192.228.17.62. Он делится на две части - номер сети и номер хоста. Номер сети состоит из одного, двух или трех первых октетов в зависимости от класса сети, а оставшиеся октеты отводятся под номер хоста.

DHCP: ЗАКЛИНАНИЕ IP?

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

Данная процедура представляется весьма простой, но что делать, если под вашим попечительством находится сеть с более чем 10 000 узлами, причем ежедневно появляется несколько десятков или даже сотен новых систем? К тому же не стоит забывать об этих докучливых портативных компьютерах, пользователи которых подключают адаптеры PCMCIA к соединителям Категории 5 там, где им заблагорассудится. Учитывая количество человеко-часов, необходимых для разрешения проблемы дублирования IP-адресов вкупе с проведением новых инсталляций и диагностикой унаследованных систем, нет ничего удивительного в том, что организации, большие и малые, ищут иные решения.

Очевидный способ решить эту проблему состоит в том, что при загрузке хост спрашивает IP-адрес у указанного ему сервера, избавляя администратора от необходимости переконфигурации хоста при каждом его перемещении. Изначально протокол, известный как BOOTP, разрабатывался для того, чтобы бездисковые рабочие станции могли запрашивать и получать информацию о конфигурации у назначенного сервера по UDP. Будучи шагом в правильном направлении, BOOTP тем не менее не имел средств для динамического назначения IP-адресов, так что администратору все равно приходилось вручную указывать серверу, какой адрес он должен дать данному хосту.

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

В частности, DHCP применяет тот же самый формат пакетов, что и BOOTP, но если последний использует в поле опций только два типа сообщений (BootRequest и BootReply), то DHCP поддерживает семь типов сообщений (DhcpDiscover, DhcpOffer, DhcpRequest, DhcpAck, DhcpNak, DhcpDecline и DhcpRelease). Благодаря этому формату DHCP совместим как с клиентами BOOTP, так и с транслирующими агентами BOOTP. Несмотря на некоторые небольшие отличия в способе приобретения новой по сравнению с модифицированной конфигурацией, механизм начальной конфигурации весьма показателен для функционирования системы DHCP в целом.

При запуске клиент DHCP ищет сервер DHCP, посылая широковещательное сообщение DhcpDiscover. При получении действительного сообщения сервер DHCP возвращает широковещательное предложение DhcpOffer, помещая незанятый IP-адрес в поле YIADDR (данная аббревиатура расшифровывается как "ваш IP-адрес"). Клиент записывает предложенный IP-адрес в область идентификатора выбранного им сервера в сообщении DhcpRequest (на сообщение DhcpDiscover может ответить несколько серверов). При получении запроса сервер сравнивает содержащийся там идентификатор со своим собственным. Если ID не совпадают, сервер генерирует явное сообщение DhcpDecline; если ID совпадают, то сервер проверяет, свободен или занят запрашиваемый IP-адрес; если адрес свободен, он отправляет подтверждение DhcpAck, а в противном случае - DhcpNak (получив DhcpNak, клиент начинает весь процесс сначала).

При получении подтверждения (DhcpAck) клиент проверяет сообщение, в частности правильность адреса сети. Предположим, что адрес неправильный, тогда клиент отправляет сообщение DhcpDecline. Если же все хорошо, клиент переходит в так называемое связанное состояние (сервер фиксирует данные об адресе клиента в базе данных DHCP) и начинает пользоваться только что полученным адресом. В зависимости от режима (автоматическое повторное использование адреса возможно только при динамическом назначении) информация об аренде передается в виде идентификационной записи об условиях аренды в сообщении DhcpAck. Клиентские системы могут отказаться от аренды до истечения срока посредством отправки серверу сообщения DhcpRelease. DHCP поддерживает опции продления срока аренды, так что клиент может запросить предоставивший ему адрес сервер DHCP о продлении аренды, благодаря чему отпадает необходимость повторять процесс запроса адреса с нуля.

Несмотря на то что по сравнению со всеми предшествующими попытками автоматического назначения адресов DHCP является несомненным достижением, он не свободен от недостатков. Ввиду того, что DHCP использует клиент-серверную функциональную модель, клиент не может работать, если сервер DHCP не функционирует. Задание длительного срока аренды для предотвращения слишком частых запросов о продлении, а также установка более чем одного сервера DHCP для обслуживания новых запросов об аренде позволяют сделать эту модель более или менее отказоустойчивой. Если один сервер выйдет из строя, то при двадцатичетырехчасовой аренде у администратора будет достаточно времени для восстановления системы или установки новой машины с тем же самым пулом IP-адресов, что и у ее предшественника. Вообще говоря, клиенты DHCP начинают пытаться узнать о статусе сервера-арендодателя после того, как срок истек наполовину, и продолжают это делать периодически до полного окончания срока аренды, после чего при отсутствии данного сервера они обращаются за новым адресом к другому. Благодаря этому процессу клиент может продолжать функционировать, даже если прежний адрес недоступен.

Как указано в документе RFC 1541, опубликованном IETF, серверы DHCP, в отличие, например, от системы имен доменов, не могут обмениваться информацией для согласования базы данных об адресах. Вот почему администраторам, имеющим несколько серверов DHCP, необходимо задать свой диапазон адресов для каждого сервера, в противном случае разные клиенты могут автоматически получить одинаковые IP-адреса - что за гигантский шаг назад! Грустно об этом говорит, но рассматриваемые IETF предложения относительно DHCPv6 никак не затрагивают вопрос о взаимодействии серверов, оставляя решение этой проблемы на будущее.

ХОСТ ПОД ЛЮБЫМ ДРУГИМ ИМЕНЕМ

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

Эту функцию можно увидеть в действии, если у вас есть выход в Internet. После установления соединения с местным оператором откройте окно приглашения на ввод команды и запустите утилиту ping для поиска данного хоста по имени или номеру. Например, введя ping network-mag.com, вы получите ответ, где указано, что IP-адрес данного хоста 198.71.19.34, а его настоящее имя - whiz.mfi.com.

Данный запрос обрабатывается агентом хоста, известного как resolver. Этот агент связывается затем с серверами имен, обслуживающими различные поддеревья в иерархии доменов. При регистрации нового домена первичные серверы имен генерируют соответствующую запись, после чего она распространяется между другими серверами имен в Internet. В ping IP-адрес можно указать непосредственно, так что обращение к DNS не потребуется (см. технические детали в www.ds.internic.net/rfc/rfc1035.txt).

КТО СТУЧИТСЯ В ДВЕРЬ КО МНЕ?

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

Вообще-то, термин "динамическая DNS" относится к системам, в которых ссылки таблицы DNS на динамически назначаемые IP-адреса хостов обновляются автоматически. Классический пример приложений этого типа можно найти в мобильной вычислительной среде, где пользователь портативного компьютера переходит из одной подсети в другую в пределах одного и того же здания, или пользователи сервера удаленного доступа должны связываться с несколькими различными серверами DHCP или PPP. При переходе хоста laptop.network.com с одного соединения на другое, он запрашивает новый IP-адрес у доступного сервера DHCP, а тот в свою очередь просит сервер имен модифицировать таблицу соответствия адресов. Эта функция автоматического обновления позволяет другим компьютерам находить laptop.network.com по имени, а приложениям и разделяемым ресурсам, использующим идентификацию по имени, нормально работать вне зависимости от IP-адреса хоста на данный момент.

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

В определенном смысле и DHCP и DNS не хватает того, что есть у другого: DHCP не обладает такой функцией DNS, как распространение таблиц DNS между серверами, а DNS - функцией динамического обновления информации DHCP. Эволюция обеих систем привела к своеобразной модификации проблемы курицы и яйца. Являясь наследником BOOTP, DHCP не имеет механизма для обращения к записям DNS о ресурсах для установления соответствия между полным доменным именем (Fully Qualified Domain Name, FQDN) и IP-адресом. В результате сервер DHCP делает неверные предположения относительно записей клиента DNS о ресурсах A и PTR.

В отсутствии стандарта компании IBM, Quadritek Systems и Isotro Network Management разработали программное обеспечение серверов DHCP и динамической DNS для решения этой проблемы следующим образом: сначала оно выполняет функцию сервера DHCP по динамическому назначению IP-адреса для данного клиента, а затем функцию динамического сервера DNS по размещению обновленной информации о соответствии имен. Такие системы находятся пока в младенческом состоянии и не отличаются поддержкой разнообразных клиентских платформ.

Кроме того, динамическая DNS представляет собой парадокс с точки зрения безопасности. Хорошо защищенные системы используют зачастую автономные или статические хранилища идентификаторов и конфигурационной информации для предотвращения несанкционированного изменения. Однако по своей природе эта стратегия вступает в противоречие с концепцией постоянно доступной, динамически модифицируемой клиент-серверной базы данных.

Представьте себе на мгновение, что злоумышленник посылает IP-адрес своей машины в качестве обновления открытому серверу DNS и, таким образом, занимает место настоящего хоста. В действительности эта проблема состоит из двух: проверка клиента и авторизация обновления DNS. Недавно принятый документ RFC 2065 предлагает расширить структуру записей DNS для поддержки использования криптографических цифровых сертификатов наряду с оснащенными функциями защиты агентами (resolver) и приложениями для заделки имеющихся "дыр" в системе защиты DNS.

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

OS/2 Warp Server 4.0 компании IBM представил на всеобщее обозрение "истинно" динамическую DNS (Warp DNS автоматически обновляется в соответствии с данными DHCP), причем он решает и проблему безопасности посредством реализации двух уровней цифровых подписей на основе механизма открытых ключей RSA для идентификации транзакций (с помощью защищенного, генерируемого клиентом ключа или с помощью защищенного, генерируемого сервером ключа, назначаемого клиенту).

По словам Глена Стампа, эксперта по динамическому IP в IBM-Raleigh, компания заняла выжидательную позицию, пока статус Secured DNS (DNSSEC) RFC 2065 не будет окончательно определен; однако он дал ясно понять, что IBM рассматривает вопросы защиты как вопросы чрезвычайной важности. Согласно утверждению Стампа, следующая версия OS/2 Warp Server будет иметь дополнительные функции защиты вместе с улучшенными функциями DHCP и динамической DNS корпоративного уровня.

Хотя динамическая DNS в Warp Server 4.0 является определенным шагом вперед, клиентская поддержка ограничена Warp Connect и AIX. Однако бета-версию клиента для Windows 95 можно найти на узле Web компании IBM, и она должна появиться в окончательном виде, когда эта статья выйдет в свет. Конфигурация DHCP осуществляется с помощью графического интерфейса в две колонки, а он в свою очередь генерирует конфигурационный файл ASCII, редактирование которого можно производить и вручную. Правда, функции сервера запускаются с помощью команд. Хотя графический интерфейс динамической DNS в версии 4.0 отсутствует, конфигурационный GUI на базе Java находится в стадии разработки для следующей версии, появление которой запланировано на осень. Также работа ведется и над взаимодействием с функциями DHCP ОС Windows NT 4.0, однако поддержка Windows NT 3.51 в настоящее время не планируется.

Windows NT Server 4.0 компании Microsoft имеет улучшенные по сравнению с версией 3.51 функции DHCP и DNS, но полноценных функций динамической DNS у него нет, так как обновление информации об именах возможно только для клиентов WINS (Windows Internet Naming Service). В результате DNS в Windows NT 4.0 не имеет связи с DHCP. Хотя в интерактивной документации по NT 4.0 утверждается, что NT поддерживает стандартный DHCP, система тем не менее не поддерживает BOOTP, а это в случае сетей, где есть устаревшее оборудование, может привести к проблемам взаимодействия.

NetWare/IP компании Novell, поставляемый вместе с IntranetWare, предоставляет пользователям NetWare поддержку сервера DHCP, причем конфигурация осуществляется с помощью утилиты DHCP Configuration Utility (DHCPCFG) со стандартным интерфейсом "а ля" NLM. DHCPCFG автоматически обнаруживает подсети, к которым сервер DHCP подключен, создавая профиль подсети для каждой, причем позднее профиль может быть отредактирован. Утилита допускает создание профилей для подсетей вручную, если сервер не имеет с ними прямого соединения. Реально сервер выполняет свои функции посредством dhcpsrvr.nlm.

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

ДИНАМИЧЕСКИЕ ПАКЕТЫ

Ирония заключается в том, что окончательное объединение функциональности DHCP и динамической DNS будет скорее всего осуществлено не самими поставщиками сетевых ОС, а вторичными поставщиками, чьи системы мегауправления IP работают поверх данных операционных систем. Эти поставщики способны предоставить исключительно надежные решения.

Утилиты управления IP предлагают несколько поставщиков, но среди них мы бы хотели выделить: Quadritek Systems и Isotro Network Management. Продукты обеих компаний обладают широким диапазоном функций управления и позволяют осуществлять миграцию к IP в масштабах предприятия. Таким образом, в вопросах DHCP и динамической DNS эти компании знают, что делать.

Когда этот номер выйдет из печати, Quadritek должна уже выпустить версию 3.1 своей системы QIP для управления IP. Данная версия будет поддерживать обновления сервера DHCP не только на HP-UX, SunOS, Sun Solaris и AIX 4.1.2, но и на Windows NT. QIP уже имеет клиентов управления для Windows 3.1, Windows 95 и Windows NT, а также Unix и Motif/X11R5.

Система Quadritek реализует уникальный подход к управлению IP: и имеющиеся, и планируемые сегменты учитываются таким образом, что новые назначения IP-адресов в подсети делаются системой активными автоматически. Система представляет единую точку управления всеми серверами DNS и DHCP, в том числе обширные возможности управления арендой, адресами и обновлением конфигурации. QIP импортирует существующие таблицы DHCP и DNS в центральную базу данных, заменяя оригинальные функции системы хоста на свои собственные, после чего база данных исходной системы обновляется из этой центральной системы управления. Администратор NT должен будет сначала импортировать данные IP в QIP, а затем отключить полностью сервис DHCP, после чего QIP берет на себя выполнение всех функций IP и DNS. "При развертывании кем-либо сервера управления QIP он получает одну базу данных, отвечающую за всю корпорацию, и эта база данных берет на себя заботу об обновлении многочисленных удаленных баз данных вне зависимости от того, на какой платформе они находятся", - говорит Малкольм Хейвуд, вице-президент Quadritek.

Isotro предлагает свою систему NetID в версиях для Unix и Windows. NetID имеет серверы DHCP и динамической DNS, Web Gateway для доступа к Internet и обширный комплект инструментов для управления IP. Корпоративное издание имеет лицензию на трех пользователей, поддерживает базы данных Sybase и Oracle в качестве центрального хранилища всей идентификационной информации о хостах, а также включает Admin Tool, Export Tool, Import Tool и Scheduler.

С помощью NetID Admin Tool администратор может просматривать всю информацию об идентификации, управлять доступом пользователей и конфигурировать систему с помощью определяемых полей, записей о ресурсах, опций BOOTP, шаблонов, системных моделей и многооконного интерфейса. Администратор может непосредственно инициировать функции импорта и экспорта из Admin Tool или, при желании, из Export Tool и Import Tool. С помощью последнего инструмента идентификационную информацию можно загрузить из существующих файлов с данными о зонах DNS, хост-файлов Unix, табличных файлов BOOTP или пользовательских текстовых файлов, созданных из электронных таблиц или баз данных. Система имеет опции для управления опциями DHCP и BOOTP на уровне всей сети, подсети и хоста.

ПЕРЕКОНФИГУРАЦИЯ DHCP

Следующий год станет, вероятно, весьма бурным периодом в эволюции DHCP и динамической DNS, но для этого IETF и другие группы должны остановить свой выбор на каком-то одном стандарте. Если вы читали нашу статью внимательно, то, должно быть, заметили, что стандарт DHCP не описывает сообщения DhcpReconfigure. Вы совершенно правы, это дело DHCPv6, предлагаемой структуры для передачи информации DHCP узлам IPv6. Оставайтесь с нами, гонки должны быть интересными...


Кирк Демари - президент Computer Tutors, группы, занимающейся консультациями, обучением, программными разработками и услугами по доступу в Internet. С ним можно связаться по адресу: 72331.1353@compuserve.com.

ТАБЛИЦА 1 - АНАТОМИЯ ЗАПИСЕЙ DNS О РЕСУРСАХ СОГЛАСНО RFC 1034

Владелец Имя домена, в котором находится запись о ресурсе (Resource Record, RR) 16-разрядное значение, определяющее тип ресурса в RR
Тип A Адрес хоста
CNAME Канонический псевдоним
HINFO Идентификатор ЦПУ и ОС, используемые хостом
MX Идентификатор почтовый сервер в домене
NS Официальный сервер имен в домене
PTR Указатель на другую часть пространства имен доменов
SOA Идентификатор начало зоны
Класс 16-разрядное значение, идентифицирующее семейство протоколов или экземпляр протокола
IN Межсетевая система
CH Хаотическая система
TTL Время жизни RR, 32-разрядное значение в секундах указывает как долго запись о ресурсе должна находиться в кэше
RDATA Тип, класс и соответствующие данные, описывающие ресурс
A Для класса IN - это 32-разрядный IP-адрес; для класса CH - это имя домена плюс 16-разрядный восьмеричный адрес Chaos
CNAME Имя домена
MX 16-разрядное предпочтительное значение, за которым следует имя хоста, желающего выступить в роли почтового сервера для домена владельца
NS Имя хоста
PTR Имя домена
SOA Поля зоны полномочий