Что можно делать с клиентской машины при взаимодействии с dns и dhcp
Сетевые сервисы относятся к ядру вашей сети, той основе, на которой все строится. По убеждениям автора это достаточно простые, однако, от этого не менее важные сервисы.
DHCP – сервис, который позволяет устройству в сети динамически получать IP адрес и некоторые настройки сети от центрального сервера. Если Ваш компьютер настроен на динамическое получения IP адреса, то при загрузке он будет отправлять широковещательные запросы, в надежде, что ему ответит DHCP сервер. DHCP сервер даст ответ, тогда компьютер даст запрос на получение IP от этого сервера, предоставив ему свой мак-адрес. В ответ сервер выдаст IP или сообщит, что это невозможно.
Службы DNS и DHCP могут быть установлены на различных серверах и сетевых устройствах. Начиная от домашних роутеров, и заканчивая отдельными серверами, специально выделенными под эти задачи. При планировании сети важно правильно выбрать месторасположение и количество серверов, обеспечивающих надежную работу этих сервисов.
Например, для отказоустойчивости DHCP можно настроить несколько серверов, а для DNS помимо избыточности устанавливают внутренние и внешние DNS-сервера.
Настройка DNS и DHCP серверов может быть выполнена как ОС Windows так и Linux. В зависимости от выбранной платформы могут быть различные преимущества и особенности настройки. Например, в Windows 2012 появилась возможность поднять службу DHCP в отказоустойчивом режиме и использовать безопасные подключения для DNS. Для того, чтобы установить сетевые службы DNS и DHCP на серверах Windows необходимо поднять соответствующие роли. Дальнейшая настройка зависит от параметров вашей сети.
Работа ActiveDirectory тесно связана с сервисом DNS. Установить службы DNS можно в процессе поднятия роли ADDS, таким образом, установка DNS сервера будет произведена на контроллере домена. DHCP, кстати также имеет интеграцию с доменом: доменная машина не получит IP от DHCP сервера, если он не активирован в AD.
Для установки DNS и DHCP сервера требуется, чтобы сам сервер имел статический IP. Также на момент установки серверов крайне рекомендуется уже иметь разработанный план подсетей, областей и исключений. Также не стоит забывать о правильной конфигурации сетевого оборудования. Например, получение ip адреса от DHCP сервера будет работать в рамках одного широковещательного домена. Если вы используйте оборудование Cisco и несколько vLan, для каждого из них нужно прописать ip-helper с указание ip адреса DHCP сервера. В случае использования другого сетевого оборудования нужно найти механизмы для настройки этого функционала. После установки роли, подключиться к службам для дальнейшего управления можно с помощью консоли, которая находится в меню инструментов для администрирования.
Дальнейшая настройка DHCP сервера требует конфигурирования хотя бы одной области, в рамках которой будет указан пул выдаваемых IP адресов, адреса, которые нужно исключить из выдачи, а также резервирования. Резервировать IP адрес нужно для того, чтобы этот адрес выдавался автоматически, но только одному единственному устройству. В качестве уникального идентификатора используется MAK адрес сетевого интерфейса устройства, которому требуется выдать IP. Кроме этих настроек также можно указать ряд сетевых параметров (options), которые будут получены вместе с IP адресом. Например, шлюз и DNS сервера сети, прокси-сервера для выхода в Интернет, параметры PXE для загрузки устройства по сети, а также многое другое.
Для дальнейшей настройки DNS сервера потребуется создание хотя бы одной прямой и, при необходимости, обратной зоны, указать необходимость динамических обновлений и настроить пересылку запросов. Для настройки можно использовать готовый мастер, вызвать который можно из меню консоли управления DNS.
При создании зоны нужно указать ее тип. Существует 3 типа зон:
- Основная. Используется непосредственно для управления записями Зоны.
- Дополнительная. Является копией основной и может выдавать информацию о записях зоны, однако не позволяет редактирование.
- Зона-заглушка. Хранит в себе только информацию о NS-серверах зоны, упрощая процесс разрешения имен и администрирования DNS.
После того как зона создана. Ее нужно наполнить требуемыми записями.
Наиболее используемые из них
- A (АААА для IPv6)– ставит имя в соответствие IP адресу.
- CNAME – псевдоним для записи A
- MX – адрес почтового шлюза для доменной зоны.
- NS – адреса серверов, обслуживающих зону.
- TXT – запись произвольных двоичных данных.
- PTR – ставит IP адрес в соответствие имени.
Есть еще другие, такие как SOA, SRV и пр.
Нужно отметить, что другие DNS сервера обновляют информацию о вашей зоне с некоторой задержкой, соответственно, нужно помнить, что, несмотря на то, что изменения DNS зоны применяются незамедлительно, говорить об однозначном отсутствии ошибок в разрешении имен можно только через 48 часов после применения изменений.
Одной из частых задач, возникающих при установке собственного DNS сервера является перенос зоны от провайдера. Для этого необходимо:
- Создать дополнительную зону.
- Стянуть все данные с основной зоны при помощи синхронизации.
- Сделать зону основной
- Изменить для нее NS сервера.
Говоря о создании резервной копии важно понимать, что сам сервис разворачивается за несколько минут и основными данными, которые подлежат защите, является:
- Для DHCP: дамп настроек сервера и областей.
- Для DNS: дамп настроек и зон.
Методов защиты этой информации существует великое множество. Какой из способов выбрать – решать Вам.
Данный текст был призван пролить свет на необходимость и принципы работы сетевых сервисов DNS и DHCP в инфраструктуре Вашего предприятия.
Если у Вас остались вопросы, Вы всегда можете получить консультацию наших специалистов или обратиться за помощью по внедрению продуктов, [email protected]
Администрирование: MikroTik, Ubiquiti, Провайдер запись закреплена
Добрый вечер, прошу помощи с вопросом, не могу понять смысл задания.
Что можно делать с клиентской машины при взаимодействии с DNS и DHCP?
Не могу понять и смысл вопроса. Зачем днс взаимодействовать с dhcp и как, это протоколы разных уровней.
Андрей Кателин
Задание звучит: установить виртуалку, развернуть домен, подключиться к домену и проработать вопрос: Что можно делать с клиентской машины при взаимодействии с DNS и DHCP.
Владислав, спросить преподавателя, какого хрена он от вас хочет, задавая этот вопрос.
Но преподаватель наверняка в ответ спросит, какого хрена вы делали на занятиях весь семестр
Так что безопаснее начать с методички или чужих конспектов - там наверняка найдётся ответ, причём написанный прямым текстом.
А что там написано именно у вашего преподавателя - мы здесь не угадаем.
Разработки в области DHCP и динамической DNS должны облегчить управление IP-адресами и именами доменов. ОСНОВЫ TCP/IP DHCP: ЗАКЛИНАНИЕ IP? ХОСТ ПОД ЛЮБЫМ ДРУГИМ ИМЕНЕМ КТО СТУЧИТСЯ В ДВЕРЬ КО МНЕ?
Разработки в области DHCP и динамической DNS должны облегчить управление IP-адресами и именами доменов.
Вследствие гигантского спроса на доступ в Internet и стремления больших и малых компаний построить идеальную корпоративную сеть Intranet, администраторы сетей сталкиваются с многочисленными сложностями в управлении IP-адресами и именами доменов. Последние разработки в области протокола динамической конфигурации хоста (Dynamic Host Configuration Protocol, DHCP) и динамической системы имен доменов (Domain Name Service) открывают перед ними новую альтернативу.
ОСНОВЫ TCP/IP
TCP/IP - это не один протокол, а скорее семейство или комплект взаимосвязанных протоколов. Протокол TCP связывает высокоуровневые сервисы с IP, а тот в свою очередь взаимодействует с протоколом канального уровня. На Рисунке 1 изображена иерархия семейства протоколов TCP/IP в сопоставлении с эталонной моделью ISO OSI.
Рисунок 1.
Стек протоколов TCP/IP показан в сравнении с эталонной моделью OSI. В иерархии TCP/IP протоколы TCP и 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 является несомненным достижением, он не свободен от недостатков. Ввиду того, что DHCP использует клиент-серверную функциональную модель, клиент не может работать, если сервер DHCP не функционирует. Задание длительного срока аренды для предотвращения слишком частых запросов о продлении, а также установка более чем одного сервера DHCP для обслуживания новых запросов об аренде позволяют сделать эту модель более или менее отказоустойчивой. Если один сервер выйдет из строя, то при двадцатичетырехчасовой аренде у администратора будет достаточно времени для восстановления системы или установки новой машины с тем же самым пулом IP-адресов, что и у ее предшественника. Вообще говоря, клиенты DHCP начинают пытаться узнать о статусе сервера-арендодателя после того, как срок истек наполовину, и продолжают это делать периодически до полного окончания срока аренды, после чего при отсутствии данного сервера они обращаются за новым адресом к другому. Благодаря этому процессу клиент может продолжать функционировать, даже если прежний адрес недоступен.
Как указано в документе RFC 1541, опубликованном IETF, серверы DHCP, в отличие, например, от системы имен доменов, не могут обмениваться информацией для согласования базы данных об адресах. Вот почему администраторам, имеющим несколько серверов DHCP, необходимо задать свой диапазон адресов для каждого сервера, в противном случае разные клиенты могут автоматически получить одинаковые IP-адреса - что за гигантский шаг назад! Грустно об этом говорит, но рассматриваемые IETF предложения относительно DHCPv6 никак не затрагивают вопрос о взаимодействии серверов, оставляя решение этой проблемы на будущее.
ХОСТ ПОД ЛЮБЫМ ДРУГИМ ИМЕНЕМ
Вообще говоря, компьютерам проще работать с числами, в то время как людям - со словами. То же самое справедливо и в отношении IP-адресов. DNS разрабатывалась специально для того, чтобы пользователи могли обращаться к хостам по именам, а не по IP-адресам. Благодаря DNS пользователь может задать доменное имя хоста в виде цепочки слов с точкой в качестве разделителя - данный формат идентифицирует иерархическим образом имя хоста внутри сетевого домена. Сервер DNS ищет запрошенное имя в своей базе данных и сообщает соответствующий IP-адрес.
КТО СТУЧИТСЯ В ДВЕРЬ КО МНЕ?
Теперь, когда серверы DHCP могут динамически назначать IP-адреса, которыми DNS должна управлять, мы хотели бы иметь и динамическую службу DNS, чтобы она автоматически модифицировала таблицу соответствия имен доменов согласно новым назначениям DHCP. Современный стандарт не обеспечивает базы для динамической модификации таблицы имен доменов согласно назначениям DHCP; однако проект стандарта, рассматриваемый IETF, вкупе с рыночным прессингом, усилившимся в результате появления разработок нескольких производителей, должен в конце концов привести к появлению нового стандарта в ближайшие несколько лет.
Некоторые динамические системы 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
Появление протокола Dynamic Host Configuration Protocol (DHCP) заметно упростило жизнь сетевых администраторов. Если раньше IP-адреса приходилось задавать вручную (хорошо еще, если с центральной консоли), то теперь эта процедура выполняется автоматически. Протокол DHCP был предложен в 1993 г.
Появление протокола Dynamic Host Configuration Protocol (DHCP) заметно упростило жизнь сетевых администраторов. Если раньше IP-адреса приходилось задавать вручную (хорошо еще, если с центральной консоли), то теперь эта процедура выполняется автоматически.
Протокол DHCP был предложен в 1993 г., его развитием занимается специальная рабочая группа (DHC WG), входящая в состав IETF. Наиболее полное современное описание DHCP содержится в документе RFC 2131 (март 1997 г.), который пришел на смену более ранним редакциям RFC 1531 и 1541. В настоящее время DHCP имеет статус предварительного стандарта.
DHCP появился не на пустом месте — различные схемы управления IP-адресами в сетевой среде предлагались и раньше (см. врезку «Распределение IP-адресов. »). Однако эти схемы имеют по крайней мере один из двух недостатков — не допускают динамического назначения IP-адресов либо позволяют передавать от сервера на станцию-клиент лишь небольшое число параметров конфигурации.
При разработке протокола DHCP преследовалась цель устранить оба ограничения. Требовался механизм, который позволил бы ликвидировать стадию ручного конфигурирования компьютеров, поддерживал многосегментные сети, не требуя наличия DHCP-сервера в каждой подсети, не конфликтовал с существующими сетевыми протоколами и компьютерами, имеющими статичную конфигурацию, был способен взаимодействовать с ретранслирующими агентами протокола BOOTP и обслуживать BOOTP-клиентов, наконец, допускал управление передаваемыми параметрами конфигурации. Что касается более узких задач, то DHCP должен был обеспечивать уникальность сетевых адресов, используемых разными компьютерами сети в данный момент, сохранение прежней конфигурации клиентской станции после перезагрузки клиента или сервера, автоматическое присвоение параметров конфигурации вновь подключенным машинам.
Сравнивая протоколы BOOTP и DHCP, нельзя не отметить появления в DHCP новых услуг. Во-первых, в этом протоколе предусмотрен механизм автоматической выдачи IP-адресов во временное пользование с возможностью их последующего присвоения новым клиентам. Во-вторых, клиент может получить от сервера все параметры конфигурации, которые ему необходимы для успешного функционирования в IP-сети.
Управление IP-адресами
Протокол DHCP поддерживает три механизма выделения адресов: автоматический, динамический и ручной. В первом случае клиент получает постоянный IP-адрес, в последнем DHCP используется только для уведомления клиента об адресе, который администратор присвоил ему вручную. Оба эти варианта не таят в себе чего-либо принципиально нового, а вот динамический механизм заслуживает детального рассмотрения.
Выдача адреса в аренду производится по запросу клиента. DHCP-сервер (или группа серверов) гарантирует, что выделенный адрес до истечения срока его аренды не будет выдан другому клиенту; при повторных обращениях сервер старается предложить клиенту адрес, которым тот пользовался ранее. Со своей стороны, клиент может запросить пролонгацию срока аренды адреса либо, наоборот, досрочно отказаться от него. Протоколом предусмотрена также выдача IP-адреса в неограниченное пользование. При острой нехватке адресов сервер может сократить срок аренды адреса по сравнению с запрошенным.
Не исключено, что клиента не устроит ни одно из серверных предложений. Тогда вместо DHCPREQUEST он снова выдаст в сеть запрос DHCPDISCOVER, а серверы так и не узнают, что их предложения отклонены. Именно по этой причине сервер не обязан резервировать помещенный в DHCPOFFER адрес.
Заметим, что исходя из определенной сетевым администратором политики сервер может выдать клиенту адрес, отличающийся от запрошенного (даже при доступности последнего), вообще отказать в предоставлении адреса или предложить адрес, относящийся к другой подсети. Более того, DHCP-сервер вообще не обязан реагировать на каждый поступивший запрос DHCPDISCOVER. Это предоставляет администратору возможность контролировать доступ к сети, например разрешив серверу отвечать только тем клиентам, которые предварительно зарегистрировались с помощью специальной процедуры.
При пролонгировании аренды клиент проходит два состояния — обновления адреса (RENEWING) и обновления конфигурации (REBINDING). Первое наступает примерно на половине срока аренды адреса (так называемый момент T1), второе — по истечении приблизительно 7/8 полного времени аренды (момент T2); для рассинхронизации процессов реконфигурирования разных клиентов значения этих временных меток рандомизируются с помощью случайной добавки.
Не исключено, однако, что ответ DHCPACK не придет до окончания срока аренды. Тогда клиент обязан немедленно прекратить выполнение любых сетевых операций и заново начать процесс инициализации. Если запоздавший ответ DHCPACK все-таки поступит, клиенту рекомендуется сразу же возобновить работу под прежним адресом.
Параметры конфигурации
Хранение параметров сетевой конфигурации станций-клиентов является второй услугой, предоставляемой DHCP-сервером. В создаваемой базе данных на каждого клиента заводится отдельная запись с уникальным ключом-идентификатором и строкой конфигурационных параметров.
Роль идентификатора может играть пара , которая позволит использовать аппаратный адрес сразу в нескольких подсетях, либо пара , позволяющая серверу взаимодействовать с клиентом, перемещенным в другую подсеть.
Что касается собственно параметров конфигурации, то их набор, поддерживаемый протоколом DHCP, определен в спецификациях RFC 1122, 1123, 1196 и 1256. В него входят выданный адрес, срок его аренды, назначавшиеся ранее адреса, а также максимальный размер реассемблируемого пакета, перечень фильтров для нелокальной маршрутизации от источника, адрес, используемый в широковещательных пакетах, параметры статических маршрутов и т.д. Впрочем, из всей совокупности допустимых параметров (а их более 30) в процессе инициализации могут передаваться только те, которые действительно необходимы для работы клиента либо определяются спецификой конкретной подсети.
Недостатки DHCP
Освобождая сетевых администраторов от множества рутинных операций, DHCP оставляет нерешенными ряд проблем, которые рано или поздно могут возникнуть в реальной сетевой среде.
К недостаткам этого протокола прежде всего следует отнести крайне низкий уровень информационной безопасности, что обусловлено непосредственным использованием протоколов UDP и IP. В настоящее время не существует практически никакой защиты от появления в сети несанкционированных DHCP-серверов, способных рассылать клиентам ошибочную или потенциально опасную информацию — некорректные или уже задействованные IP-адреса, неверные сведения о маршрутизации и т.д. И наоборот, клиенты, запущенные с неблаговидными целями, могут извлекать конфигурационные сведения, предназначенные для «законных» компьютеров сети, и тем самым оттягивать на себя значительную часть имеющихся ресурсов. Понятно, что возможности административного ограничения доступа, о которых говорилось выше, не способны закрыть эту брешь в системе информационной безопасности.
По мнению некоторых экспертов, в настоящее время DHCP недостаточно отказоустойчив. Протоколу явно недостает механизма активного уведомления клиентов об экстремальных ситуациях (например, о систематической нехватке адресов) и серверного подтверждения об освобождении адреса, иногда в сети наблюдаются всплески числа запросов на повторное использование адресов и т.д. Впрочем, работа над протоколом еще не завершена, и не исключено, что некоторые недостатки будут устранены в последующих редакциях.
Приступая к написанию статьи, автор ставил себе целью изложить основные принципы DHCP, которые позволили бы читателю получить представление о работе этого протокола, а также сопоставить его с другими механизмами распределения сетевых адресов. Многие детали при этом остались за кадром, однако следует иметь в виду, что DHCP еще не приобрел статуса индустриального стандарта, поэтому в ближайшее время могут увидеть свет новые его модификации.
Тем не менее, как частенько бывает в сетевой индустрии, механизмы DHCP уже реализованы в продуктах ряда производителей. К счастью, любые изменения в алгоритмах его работы легко учесть на программном уровне, так что, приобретая серверное или клиентское программное обеспечение определенной компании, можно не опасаться заточения в неприступную крепость патентованных решений. Скорее, следует обратить внимание на то, насколько удачно конкретная реализация DHCP вписывается в имеющуюся вычислительную среду и взаимодействует с другими сетевыми службами, в частности с DNS. Публикуемые в этом номере результаты сравнительных испытаний DNS- и DHCP-серверов (см. статью «Игра в имена») способны стать неплохим подспорьем для пользователя.
Стоит принять во внимание и слабые стороны протокола, о которых говорилось выше. Внедряя в своей сети средства DHCP, администратор должен быть готов к возникновению проблем принципиального характера. Остается только надеяться, что их количество уменьшится в стандартизованном варианте протокола DHCP.
BOOTP, DRARP, TFTP, ICMP, NIP — вероятно, это еще не полный перечень протоколов, в той или иной мере претендующих на решение задачи управления IP-адресами и конфигурацией в сетевой среде. Не исключено, что после стандартизации DHCP довольно быстро вытеснит их со сцены, однако на сегодняшний день многие из названных протоколов нередко упоминаются в литературе и используются в готовых продуктах.
Подобно DHCP, протокол Bootstrap Protocol (BOOTP) сегодня также имеет статус предварительного стандарта и рекомендован к применению консорциумом IETF. Именно его следует считать непосредственным предшественником DHCP. Появившиеся в 1993 г. дополнения расширили перечень конфигурационных параметров, охватываемых протоколом BOOTP. Более того, к настоящему времени даже предложена модификация BOOTP, поддерживающая динамическое назначение IP-адресов.
Протокол Reverse Address Resolution Protocol (RARP), впервые описанный в июне 1984 г. (RFC 903), используется компанией Sun Microsystems и рядом других производителей, в частности, для запуска бездисковых рабочих станций. Основной принцип его работы сводится к тому, что клиент должен самостоятельно отыскать свой IP-адрес, а не принять адрес, выделенный сервером. Сравнительно недавно появился динамический вариант этого протокола (Dynamic RARP, DRARP), реализующий алгоритм автоматического присвоения IP-адресов. Стоит отметить, что изначальный вариант RARP не поддерживает передачу клиенту каких-либо параметров конфигурации (кроме IP-адреса), в том числе применяемых при маршрутизации. В результате один сервер RARP способен обслуживать только одну локальную сеть.
Упрощенный вариант FTP — протокол Trivial File Transfer Protocol (TFTP) — увидел свет около 20 лет назад, его вторая версия описана в документе RFC 783. Фактически TFTP предоставляет транспортный механизм для передачи с сервера загрузочного образа клиентской системы.
Наконец, протокол Network Information Protocol (NIP) был разработан в конце 80-х гг. сотрудниками Массачусетского технологического института в качестве распределенного механизма для динамического присвоения IP-адресов в сетях Ethernet.
Отметим еще спецификации RFC 1122 и 1123, которые используются рядом протоколов (в том числе DHCP). Они содержат требования к процедуре изменения конфигурации компьютеров сети и, кроме того, предлагают сценарий первоначального конфигурирования бездисковых станций.
Время от времени можно встретить утверждение о том, что протокол DHCP и технология виртуальных частных сетей (VLAN) нацелены на решение одной и той же проблемы: они должны обеспечить свободное перемещение клиентов в сетевой среде. В действительности за приведенными выше аббревиатурами скрываются две совершенно разные концепции, причем подход на базе виртуальных ЛС является гораздо более революционным.
DHCP-сервер и ретранслирующие агенты позволяют так настроить параметры конфигурации компьютера, что после вывода из одной подсети и подключения к другой он сразу же становится полноправным членом новой подсети (поскольку конфигурация перемещенной машины изменяется автоматически). Если к тому же реализована поддержка динамического сервера доменных имен (Dynamic DNS), компьютер обретает свое прежнее имя.
Сетевое оборудование, наделенное средствами динамического формирования виртуальных ЛС, дает возможность так определить конфигурацию сети, что независимо от того, к какому порту концентратора или коммутатора будет подключена станция-клиент, она получит те же IP-адрес и имя и попадет в состав заранее описанной виртуальной локальной сети. Распределение же MAC-адресов по виртуальным ЛС может задаваться самой конфигурацией сети. Другой вариант предполагает, что IP-адреса распознаются по пакетам, которые поступают от станций-клиентов.
Итак, различия между протоколом DHCP и технологией VLAN можно суммировать следующим образом:
- DHCP изменяет конфигурацию перемещаемого компьютера, тогда как в сети с поддержкой VLAN изменение претерпевает сетевой порт, к которому подключается компьютер;
- динамическое изменение конфигурации средствами DHCP требует наличия DHCP-сервера, ретранслирующего агента в каждом маршрутизаторе и поддержки данного протокола клиентским ПО TCP/IP. В случае использования технологии виртуальных локальных сетей одна и та же схема VLAN должна поддерживаться всеми концентраторами (коммутаторами) сети, что открывает широкий простор для патентованных реализаций;
- DHCP позволяет сконфигурировать новую клиентскую станцию, а средства VLAN — нет;
- протокол DHCP служит прежде всего для обеспечения максимально динамичного конфигурирования сети, разделенной на подсети по территориальному признаку. Основное же назначение технологии VLAN состоит в объединении пользователей не по географическому, а по какому-либо иному, например функциональному, принципу (в соответствии с характером их деятельности или ролью в бизнесе компании).
Как ясно из этого краткого сравнения, одновременное использование в сети протокола DHCP (или его прообраза BOOTP) и средств VLAN может привести к серьезным конфликтам. Так, если группировка клиентов в виртуальные локальные сети осуществляется на основе IP-адресов источника (т.е. заранее заданной конфигурации), то получение конфигурационных данных по сети от DHCP-сервера исключается.
Хотя службы DNS в общем просты, в их работе бывают определенные нарушения. Довольно часто причиной этих нарушений оказываются неясные формулировки или плохо документированные параметры в различных диалоговых окнах Windows. В данной статье рассматриваются типичные неполадки DNS, которые доставляют немало хлопот администраторам.
Сбой динамического обновления
Управление DNS в домене упрощается благодаря возможности динамического обновления записей A и PTR на серверах DNS клиентами Windows. Таким образом, если в интегрированной с AD зоне на предприятии используется IP-адресация, клиентские компьютеры могут динамически обновлять AD, добавляя в нее свои новые IP-адреса. Но иногда можно заметить, что клиентские компьютеры не пополняют записей DNS новыми адресами. Чтобы корректно выполнить обновление, необходимо разрешить динамическое обновление на сервере DNS. Для этого требуется открыть окно свойств зоны DNS и выбрать режим Secure only for Dynamic updates (экран 1).
Затем следует открыть диалоговое окно Advanced TCP/IP Settings сетевого адаптера на клиентской системе, выбрать вкладку DNS и убедиться, что установлен флажок Register this connection’s addresses in DNS.
Наконец, клиентская служба DHCP (не только клиентская служба DNS) выполняет регистрацию DNS и должна функционировать на каждом компьютере. Даже если DHCP не используется для назначения IP-адресов, клиентская служба DHCP должна работать на всех компьютерах для динамического обновления записей DNS.
По умолчанию клиент обновляет записи DNS при начальной загрузке, при изменении IP-адреса или имени либо при выполнении команды ipconfig/registerdns. Кроме того, клиент повторно регистрирует IP-адрес через каждые 24 часа.
Падение производительности из-за клиентской службы DNS
При запуске клиентской службы DNS все записи из hosts-файла загружаются в кэш. Если для блокирования доступа к нежелательным именам узлов используется очень большой hosts-файл, эта служба может существенно замедлять работу компьютера. В таком случае ее стоит отключить.
Обычно отключение клиентской службы DNS не влияет на преобразование DNS. Тогда возникает вопрос, зачем вообще нужна такая служба.
Дело в том, что наличие клиентской службы DNS — не обязательное требование для преобразования имен; она лишь повышает эффективность и гибкость этого процесса. Главная цель клиентской службы DNS — обеспечить локальное кэширование записей DNS. В сущности, служба представляет собой сервер DNS. Вместо того чтобы опубликовать базу данных записей DNS, она просто кэширует ранее преобразованные записи DNS для ускорения будущих операций. Помимо кэширования, служба оптимизирует сетевые соединения путем приоритизации записей о ресурсах на основе сетевого местоположения, скорости и готовности.
Клиентская служба DNS также управляет списком серверов DNS, настроенных на компьютере. Как и в случае с записями о ресурсах, служба выбирает наиболее подходящий сервер DNS из списка серверов на основе местоположения в сети, скорости и готовности.
Обязательная оптимизация правил брандмауэра
Если брандмауэр настроен на передачу любых запросов на сервер DNS, то необходимы правила, препятствующие злоупотреблениям со стороны посторонних лиц. DNS-запросы обычно поступают в UDP-порт 53 из порта-источника с номером более 1023. Сервер DNS отвечает с порта-источника 53 на тот же порт, используемый клиентом. Большинство брандмауэров c проверкой пакетов на соответствие заданным условиям может обслуживать ответы DNS, поэтому для управления запросами достаточно одного правила.
Если размер ответа на запрос превышает 512 байт, то сервер DNS сообщает клиенту, что ответ усечен. Клиент может повторно представить запрос с Extended DNS, в котором используются UDP-ответы большего размера, или клиент может повторно послать запрос через TCP. Если разрешены запросы TCP, необходимо правило, разрешающее поступление пакетов в TCP-порт 53 из порта-источника с номером более 1023. Если известно, что сервер DNS не отвечает на запросы размером более 512 байт, то порт можно оставить закрытым. В некоторых серверах DNS UDP- или TCP-порт 53 используется в качестве порта-источника и порта назначения для запросов сервер-сервер, поэтому, возможно, придется соответствующим образом настроить брандмауэр.
Каким образом Windows опрашивает несколько серверов DNS
По умолчанию Windows сначала запрашивает указанный первым сервер DNS на первичном сетевом адаптере. Если этот сервер не отвечает в течение секунды, Windows посылает запрос на указанный первым сервер DNS на любом другом сетевом адаптере компьютера. Если ответ не получен в течение двух секунд, Windows посылает запрос всем серверам DNS на всех сетевых адаптерах компьютера. Если в течение двух секунд ни один сервер не откликается, Windows вновь посылает запрос всем серверам и ждет четыре секунды. При необходимости запрос всем серверам повторяется, и ожидание длится восемь секунд.
Windows вносит коррективы в список опрашиваемых серверов DNS в зависимости от условий работы сети. Если ни один из серверов DNS для адаптера не отвечает на запросы, Windows предполагает, что произошел отказ сети, и не запрашивает серверы через этот адаптер в течение 30 секунд. Если один сервер DNS на сетевом адаптере возвращает отрицательный ответ на запрос, Windows не посылает повторных запросов ни на один из серверов DNS этого адаптера. Кроме того, Windows может изменить порядок опроса серверов DNS в пользу сервера, который отвечает быстрее других.
Медленная процедура настройки из графического интерфейса
Чтобы настраивать конфигурации большого числа серверов DNS на клиентских компьютерах, нужен более простой и эффективный метод, чем использование графического интерфейса Windows. Попробуем применить утилиты, запускаемые из командной строки. Чтобы получить список всех серверов DNS клиента, следует ввести команду
c:>netsh interface ip
show dns
Очистить список серверов DNS сетевого адаптера можно с помощью команды
c:>netsh interface ip
set DNS «Local Area Connection»
static none
где «Local Area Connection» — имя сетевого адаптера.
Чтобы добавить сервер DNS для сетевого адаптера («Local Area Connection» — имя сетевого адаптера), нужно ввести
:>netsh interface ip
set DNS «Local Area Connection»
static 192.168.0.1
Проблемы домена DNS
Ошибки в настройке параметров DNS — типичная причина неполадок в доменах Windows. Самый быстрый способ проверить параметры — выполнить преобразование самого имени домена, что можно сделать с помощью команды
c:>nslookup
Эта команда должна выдать список IP-адресов, которые указывают на каждый из контроллеров домена. Если получены иные результаты, необходимо проверить настройки DNS.
Проверить конфигурацию DNS можно, выполнив быстрый тест сетевой конфигурации на любом компьютере Windows XP или Windows Server 2003. В командной строке нужно ввести
c:>netsh diag show test
При этом выполняется эхо-тестирование всех серверов DNS и шлюзов в конфигурации TCP/IP. Если имеется набор ресурсов Microsoft Windows Server 2003 Resource Kit, то можно применить команду netdiag или dnsdiag
C:>netdiag /test:dns
C:>dnsdiag
c:> echo ls -d
nslookup —
BIND — акроним, а не глагол
Когда отключать рекурсию?
Блокирование узлов Internet
Дополнительные советы по DNS
Чтобы сбалансировать нагрузку от DNS-запросов, сервер DNS использует циклическую ротацию для прохода по списку IP-адресов, равномерно распределяя трафик между различными серверами. При упорядочении с сетевой маской сервер DNS пытается выдать IP-адрес узла, физически расположенного ближе всех к клиенту. Для этого сервер DNS просматривает несколько первых октетов IP-адреса, предполагая, что сервер с IP-адресом, похожим на адрес клиента, будет ближе всего расположен к нему физически. По умолчанию сервер DNS отдает предпочтение любому адресу хоста в одной сети класса C с клиентом.
Может показаться, что нельзя одновременно применить циклическую систему и упорядочение с сетевой маской, но, как показано на экране A, Windows позволяет сочетать оба метода. Если выбраны оба метода, Windows проверяет список IP-адресов узла, чтобы выяснить, насколько близко IP-адрес в списке соответствует IP-адресу клиента. Если обнаружено совпадение, этому IP-адресу будет назначен более высокий приоритет для циклической ротации. Результат: сервер DNS выполняет циклическую ротацию IP-адресов, но чаще выбирает ближайшие к клиенту серверы.
Интеграция DNS и Active Directory
При установке DNS на контроллере домена (DC) Windows можно сохранить зонные файлы не в простых текстовых файлах, а в базе данных Active Directory (AD). Возникает вопрос: зачем тогда интегрировать зону с AD?
В большинстве случаев интеграция зон DNS с AD приносит много преимуществ, главное из которых — более эффективная репликация. В зонах, интегрированных с AD, автоматизирована репликация записей DNS между серверами. Репликация AD — репликация с несколькими «ведущими», то есть можно внести изменение на любом DC, и это изменение будет автоматически распространено по домену. Для зон DNS, которые не интегрированы с AD, необходимо назначить первичные и вторичные серверы DNS. Изменения обычно вносятся на первичном сервере, который обновляет все вторичные.
Читайте также: