67. Служба dhcp.
Разработанная Microsoft реализация протокола TCP/IP позволяет создавать сети и обеспечивает связь между компьютерами. Стек протоколов TCP/IP включает 4 уровня: сетевого интерфейса, Интернета, транспортный и прикладной. По умолчанию клиент с Windows 2000 автоматически получает сведения о конфигурации TCP/IP от службы DHCP; однако некоторые компьютеры требуют выделения статичного IP-адреса. Для каждого сетевого адаптера, использующего TCP/IP, надо определить IP-адрес, маску подсети и шлюз по умолчанию.
Спужба DHCP собирает и выделяет конфигурационную информацию TCP/IP, автоматами присваивая DHCP-клиентам IP-адреса и иные данные TCP/IP. Внедрение службы DНСР может разрешить массу проблем, связанных с ручной настройкой TCP/IP.
DHCP представляет стандарт стека протоколов TCP/IP, упрощающий обслуживание IP-конфигурации. DHCP — это расширение протокола Bootstrap Protocol (BOOTP), основанного на протоколе UDP/IP. BOOTP позволяет загружающемуся узлу динамически конфигурировать себя.
При каждом запуске клиент DHCP запрашивает у сервера DHCP:
IP-адрес;
маску подсети;
дополнительные значения, например, адрес шлюза по умолчанию, адрес сервера DNS или WINS.
Получив запрос на IP-адрес, сервер DHCP выбирает информацию об IP-адресе из пула адресов, определенных в его БД, и предлагает эти данные клиенту DHCP. Если клиент принимает предложение, сервер DHCP выделяет ему на определенный срок IP-адрес.
Ручная и автоматическая настройка TCP/IP
Чтобы понять преимущества использования службы DHCP для настройки TCP/IP на клиентских компьютерах, сравним ручную настройку TCP/IP и автоматическую.
Ручная настройка TCP/IP
Пользователи могут выбрать IP-адрес произвольно, а не получать его у сетевого администратора. Применение некорректных адресов может вызвать сбои в работе сети, которые сложно отследить.
Поскольку IP-адрес, маски подсети и шлюз по умолчанию задаются вручную, то это может привести к разным проблемам – от проблем со связью, до идентичных IP-адресов
При частом перемещении компьютеров из одной подсети в другую усложняется администрирование. Например, чтобы клиент мог устанавливать связь из нового места, администратору придется изменить его IP-адрес и шлюз по умолчанию.
Настройка TCP/IP с использованием DHCP
Для настройки TCP/IP пользователям не надо обращаться к сетевому администратору за сведениями об IP-адресе. Служба DHCP предоставляет всем клиентам DHCP нужную, конфигурационную информацию.
Действительные сведения об IP-адресе гарантируют корректность конфигурации, избавляя пользователя от большинства проблем с сетью, источник которых трудно определить.
Наличие в каждой подсети серверов DHCP полностью избавляет от проблем с ручной перенастройкой IP-адресов, масок подсети и шлюзов по умолчанию, возникающих при перемещении компьютера из одной подсети в другую. Один сервер DHCP способен выделять IP-адреса нескольким сетям.
Аренда DHCP
Служба DHCP предоставляет клиентским компьютерам сведения об IP-адресе. Этот процесс называется арендой DHCP и имеет место в одном из следующих случаев:
на клиенте DHCP впервые инициализирован пакет протоколов TCP/IP;
клиент запросил определенный IP-адрес и получил отказ, возможно, в связи с тем что сервер DHCP отозвал предоставленный адрес;
клиент, ранее арендовавший IP-адрес и освободивший его, запросил новый адрес;
Примечание: выделенный DHCP-сервером IP-адрес можно освободить вручную, запустив в командной строке утилиту ipconfig с параметром /release.
Выделение IP-адреса клиенту DHCP производится сервером DHCP в четыре этапа:
DHCPDISCOVER,
DHCPOFFER,
DHCPREQUEST
DHCPACK .
DHCPDISCOVER
Это первый этап выделения IP-адреса с использованием DHCP. Сначала клиент инициализирует ограниченную версию TCP/IP и производит широковещательную рассылку сообщения DHCPDISCOVER, запрашивая местоположение DHCP-сервера и сведения об IP-адресе. Поскольку клиент не знает IP-адреса сервера DHCP, в качестве исходного адреса применяется 0.0.0.0, а конечного - 255.255.255.255. Сообщение DHCPDISCOVER содержит аппаратный адрес клиента и имя компьютера, по которому сервер DHCP может определить клиента, отославшего запрос.
DHCPOFFER
Это второй этап. Все серверы DHCP, получившие запрос на выделение IP-адреса и имеющие правильную клиентскую конфигурацию, производят широковещательную рассылку сообщения DHCPOFFER, включающего:
аппаратный адрес клиента;
предлагаемый IP-адрес;
маску подсети;
период аренды адреса;
идентификатор сервера (IP-адрес предлагающего сервера DHCP).
Широковещание используется, поскольку у клиента еще нет IP-адреса. Клиент DHCP выбирает IP-адрес из первого полученного предложения. Сервер DHCP, предлагающий IP-адрес, резервирует его, чтобы не предложить другому клиенту.
OHCPREQUEST
Третий этап наступает после того, как клиент примет сообщение DHCPOFFER от хотя бы одного сервера DHCP и выберет IP-адрес. Клиент производит широковещательную рассылку сообщения DHCPREQUEST всем серверам DHCP, сообщая им, что он уже принял предложение.
DHCPREQUEST включает идентификатор сервера (IP-адрес), предложение которого было принято клиентом. Затем остальные серверы DHCP отзывают свои предложения и сохраняют IP-адреса для следующих запросов.
DHCPACK
Последний этап процесса выделения IP-адреса с использованием DHCP наступает после того как сервер DHCP, чье предложение было принято, выполнит широковещательную рассылку положительного подтверждения клиенту. Подтверждение распространяется в форме сообщения DHCPACK, содержащего действительный IP-адрес и, возможно, другую конфигурационную информацию.
При получении клиентом подтверждения выполняется полная инициализация TCP/ IP, и клиент считается привязанным клиентом DHCP. После этого клиент может использовать для связи TCP/IP.
DHCPNACK
В случае неудачи на этапе DHCPREQUEST сервер DHCP производит широковещательную рассылку отрицательного подтверждения (DHCPNACK). Это происходит в одном из случаев:
клиент пытается получить свой предыдущий IP-адрес, который уже недоступен;
IP-адрес неверен, поскольку компьютер был перемещен в другую подсеть.
Получив отрицательное подтверждение, клиент возобновляет процесс получения IP-адреса с использованием DHCP.
Примечание Если в компьютере несколько сетевых адаптеров, привязанных к TCP/IP, процесс DHCP осуществляется отдельно для каждого. Служба DHCP выделяет каждому адаптеру уникальный и действительный IP-адрес.
Продление аренды и освобождение IP-адреса
По прошествии половины периода, на который был выделен IP-адрес, клиенты DHCP пытаются продлить его аренду. Для этого клиент посылает сообщение DHCPREQUEST прямо выделившему адрес серверу DHCP.
Если он доступен, то продлевает аренду и отсылает клиенту сообщение DHCPACK с новым временем аренды и обновленными параметрами конфигурации. Получив подтверждение, клиент обновляет свою конфигурацию.
Примечание: При каждом перезапуске клиент DHCP пытается получить у исходного сера dhcp свой старый IP-адрес. Если эта попытка окажется неудачной и время аренды еще не кончилось, то клиент DHCP будет использовать старый IP-адрес до следующей попытки продления аренды.
Если по прошествии половины времени аренды клиент DHCP не сможет продлить ее на исходном сервере DHCP, по истечении 87,5% времени аренды клиент начнет широковещательную рассылку пакета DHCPREQUEST для связи с любым доступным сервером DHCP. Сервер DHCP может ответить либо сообщением DHCPACK (продление аренды), либо DHCPNACK (принудительная инициализация клиента и получение им другого IP-адреса).
По истечении срока аренды или получив сообщение DHCPNACK, клиент DHCP должен сразу прекратить использование занятого IP-адреса. Затем клиент возобновляет процесс аренды DHCP для получения нового IP-адреса.
Продление аренды IP-адреса с помощью ipconfig
Чтобы отослать серверу DHCP сообщение DCHPREQUEST и получить обновленные параметры и период аренды, запустите в командной строке ipconfig с ключом /renew. Если сервер DHCP недоступен, клиент продолжит использовать текущие параметры конфигурации, предоставленные DHCP.
Освобождение IP-адреса с помощью ipconfig
Чтобы отослать серверу DHCP сообщение DHCPRELEASE и освободить занимаемый клиентом DHCP IP-адрес, запустите в командной строке ipconfig с ключом /release.
Это полезно, если необходимо перемещение клиентского компьютера в другую сеть и ему не нужен старый IP-адрес. После выполнения этой команды связь с клиентом с применением TCP/IP прекращается.
Определение области DHCP
Прежде чем сервер DHCP сможет предоставить клиентам DHCP IP-адреса, надо определить область DHCP — пул действительных IP-адресов, которые могут быть выделены клиентам DHCP.
Создавая область DHCP следует помнить:
для каждого сервера DHCP надо определить не менее одной области;
из области следует исключить статичные IP-адреса;
для централизации администрирования и выделения IP-адресов, специфичных для конкретной сети, на сервере DCHP можно определить несколько областей; подсети можно присвоить лишь одну область;
серверы DHCP не обмениваются информацией об областях, поэтому, создавая области на нескольких серверах DHCP, убедитесь, что в этих областях нет пересекающихся IP-адресов — это поможет избежать проблем с идентичными IP-адресами.
68. Служба DNC.
DNS — это распределенная база данных в сетях TCP/IP для преобразования имен компьютеров (имен узлов) в IP адреса.
WINS преобразует NetBIOS-имена в IP-адреса, а DNS — имена узлов в IP-адреса.
IP-имена узлов, разрешенные с помощью DNS или других средств, обеспечивают следующие преимущества:
IP-имена хостов более дружественны, т. е. запоминать IP-имена легче, чем IP-адреса;
IP-имена узлов более стабильны, чем IP-адреса. IP-адрес сервера может измениться, а имя сервера останется прежним;
IP-имена хостов позволяют пользователям подключаться к локальным серверам по тем же правилам именования, что и в Интернете.
Пространство имен домена
Это схема именования, обеспечивающая иерархичную структуру БД DNS. Каждый узел представляет раздел БД DNS и называется доменом.
БД DNS индексируется по имени, т. е. у каждого домена должно быть имя. При добавлении доменов в иерархичную структуру имя родительского домена добавляется к именам дочерних доменов (поддоменов).
Структура пространства имен домена включает корневой домен, домены верхнего и второго уровней и имена узлов.
В Windows 2000 домен — это объединение компьютеров и устройств, администрируемых как одно целое.
В DNS домен — это узел представляющий раздел БД DNS.
Корневой домен
Корневой домен находится на вершине иерархии и обозначается точкой (.). Корневой домен Интернета обслуживается несколькими организациями, в том числе и Network Solutions, Inc.
Домены верхнего уровня
Домены верхнего уровня являются 2- или 3-символьными кодами имен. Домены верхнего уровня распределяются по типу или географическому расположению организации: Gov, com, edu, org, ru
Домен верхнего уровня может включать домены второго уровня и имена хостов.
Домены второго уровня
Такие организации, как Network Solutions, Inc., выделяют и регистрируют для частных лиц и организаций домены Интернета второго уровня.
Домен второго уровня может включать как узлы, так и поддомены. Допустим, microsoft.com включает компьютеры, например, ftp.microsoft.com, и поддомены, например, dev.microsoft.com.
Правила именования доменов
При создании пространства имен домена следует:
Ограничивать число уровней домена. Обычно записи узлов должны стоять на 3 или 4, но не более, чем на 5 уровней ниже по иерархии DNS. При увеличении числа уровней увеличивается объем задач администрирования.
Использовать уникальные имена. Чтобы в пространстве имен DNS были лишь уникальные имена, в домене не должно быть поддоменов с идентичными именами.
Использовать простые уникальные имена.
Зоны пространства имен домена
Зона — это отдельная часть пространства имен домена. Зоны позволяют делить пространство имен домена на управляемые секции.
Для распространения административных задач по группам пространство имен домена делится на несколько зон.
Зона должна охватывать непрерывное пространство имен домена. Например, можно создать зону, охватывающую sales.microsoft.com и родительский домен microsoft.com, поскольку эти зоны связаны (рис. 9-11).
Используемые в зоне привязки «IP-адрес/имя» хранятся в файле БД зоны. Каждая зона прикреплена к определенному домену — корневому домену зоны. Файл БД зоны может содержать сведения не обо всех поддоменах корневого домена зоны.
Серверы имен DNS
Хранят файлы БД зон. На сервере могут размещаться БД нескольких зон. Сервер имен обладает полномочиями в пространстве имен, охватываемом зоной.
В зоне должен иметься хотя бы один сервер имен, но их может быть и несколько. Один из них содержит мастер-файл БД этой зоны, или первичный файл БД зоны. Изменения в конфигурации зоны, например добавление доменов или хостов, обрабатываются на сервере, содержащем первичный файл БД зоны. Все остальные серверы имен, связанные с данной зоной, являются резервными и содержат вторичные файлы БД.
Наличие множества серверов имен дает некоторые преимущества.
Передача зоны — дополнительные серверы имен получают от сервера, содержащего первичный файл БД зоны, копию этого файла. Это называется передачей зоны. Резервные серверы периодически обращаются к серверу, содержащему первичный файл БД, за обновленными сведениями о конфигурации зоны.
Избыточность — при сбое сервера, содержащего первичный файл БД зоны, в работу включаются резервные серверы.
Повышение скорости доступа удаленных клиентов — при наличии удаленных клиентов дополнительные серверы имен позволят снизить трафик запросов в низкоскоростных каналах связи с ГВС.
Снижение нагрузки — дополнительные серверы имен уменьшают нагрузку на сервер, содержащий первичный файл БД зоны. Кроме того, благодаря БД Active Directory Windows 2000 поддерживает хранилище зоны, интегрированное с каталогом. Зоны, хранимые подобным образом, содержатся в дереве Active Directory в объекте-контейнере Domain. Каждая зона, интегрированная с каталогом, хранится в объекте-контейнере зоны DNS, которому присваивается имя зоны.
Обзор процесса разрешения имен
Разрешение имен — это процесс преобразования имен в IP-адреса, похожий на поиск имени в телефонной книге, где имя связано с номером телефона. Например, подключаясь к Web-узлу компании Microsoft, используется имя www.microsoft.com. DNS разрешает это имя в соответствующий IP-адрес. Привязки «IP-адрес/имя» хранятся в распределенной БД DNS.
Серверы имен DNS разрешают прямые и обратные запросы на поиск имени. Прямой запрос разрешает имя в IP-адрес. Обратный запрос разрешает IP-адрес в имя. Сервер имен может разрешать запросы лишь для той зоны, в которой он обладает полномочиями. Если сервер не может разрешить запрос, он передает его другому серверу имен, который сможет это сделать. Для снижения DNS-трафика в сети сервер имен кэширует результаты запроса.
Прямой запрос на поиск имени
Для разрешения имен служба DNS использует модель клиент — сервер. Клиент передает прямой запрос на поиск имени локальному серверу имен. Этот сервер разрешает запрос сам или передает его другому серверу имен.
На рис. 9-12 показан процесс запроса клиентом IP-адреса, соответствующего имени www.microsoft.com; цифры соответствуют следующим этапам.
Клиент передает прямой запрос на поиск имени www.microsoft.com локальному серверу имен.
Локальный сервер имен проверяет файл БД своей зоны на наличие соответствующей связки «IP-адрес/имя». Не имея полномочий в домене microsoft.com, локальный сервер имен передает запрос одному из корневых серверов DNS, запрашивая разрешение имени узла. Корневой сервер возвращает ссылку на серверы имен домена corn.
Локальный сервер имен посылает запрос серверу имен домена corn, и тот возвращает ссылку на серверы имен домена microsoft.
Локальный сервер имен посылает запрос на сервер имен домена mierosoft, и тот принимает запрос. Обладая правами в этой части пространства имен домена, сервер имен домена mierosoft возвращает локальному серверу имен IP-адрес, соответствующий имени www.microsoft.com.
Локальный сервер имен посылает IP-адрес клиенту.
Разрешение имени завершено, и теперь клиент может обратиться к узлу www.micro-soft.com, используя его IP-адрес.
Кэширование на сервере имен
При обработке запроса сервером имен для получения ответа, возможно, придется отправить несколько запросов. Выполняя запросы, сервер выясняет расположение других серверов имен, обладающих правами в соответствующих частях пространства имен. Для снижения трафика сервер имен кэширует результаты этих запросов.
При получении результата:
сервер имен кэширует результат запроса на некоторый срок (TTL); этот период (по умолчанию — 60 минут) определяется зоной, предоставившей результаты запроса; ttl задается через оснастку DNS;
после того как сервер поместил результаты запроса в кэш, начинается обратный отсчет времени;
по истечении TTL сервер имен удаляет результаты запроса из кэша.
Кэширование результатов запроса позволяет серверу быстрее разрешать другие запросы, обращенные к той же части пространства имен домена.
Небольшой TTL позволит гарантировать, что данные о пространстве имен домена не устарели. Хотя такие значения TTL и повышают нагрузку на сервер имен, а длительные периоды сокращают сроки разрешения имен, клиент будет получать устаревшую информацию, пока не истечет TTL и не будет выполнен новый запрос к этой части пространства имен домена.
Обратный запрос на поиск имени
Разрешает имя в IP-адрес; служебные программы используют обратные запросы для вывода имен узлов. Кроме того, некоторые приложения реализуют защиту, основанную на подключении с использованием имен, а не IP-адресов.
Поскольку распределенная БД DNS индексируется по имени, а не по IP-адресу, при обработке обратного запроса должен производиться полный перебор всех доменных имен. Для решения этой проблемы создан специальный домен второго уровня in-addr.arpa.
Этот домен придерживается той же иерархичной системы именования, но основывается не на доменных именах, а на IP-адресах:
поддоменам присваиваются имена, соответствующие IP-адресам (4 последовательности цифр, разделенные точками);
порядок последовательностей цифр IP-адреса меняется на противоположный;
организации администрируют поддомены домена in-addr.arpa, основываясь на назначенных им IP-адресах и маске подсети.
Например, организация, которой выделен диапазон IP-адресов от 169.254.16.0 до 169.254.16.255 с маской подсети 255.255.255.0, обладает полномочиями в отношении домена 16.254.169.in-addr.arpa.
зоны прямого просмотра
Зона прямого просмотра позволяет генерировать прямые запросы поиска имени. Для работы службы DNS на сервере имен надо сконфигурировать не менее одной зоны прямого просмотра.
Существуют зоны трех типов:
Active Directory-integrated (Интегрированная в Active Directory). Главная копия новой зоны, использует для хранения и репликации файлов зоны службу Active Directory. Зоны такого типа обеспечивают безопасное обновление и интегрированное хранение. Стандартные зонные передачи не осуществляются — файл БД зоны реплицируются одновременно с хранилищем Active Directory.
Standard primary (Основная). Главная копия новой зоны, хранится как обычный текстовый файл. Администрирование и поддержка основной зоны осуществляется на том компьютере, где была создана. Зоны такого типа упрощают обмен DNS-данными с другими серверами DNS, хранящими данные в виде текста.
Standard secondary (Дополнительная). Реплика существующей зоны, хранится в обычных текстовых файлах и доступна только для чтения. Для создания дополнительной зоны надо сначала создать основную. При создании надо указать основной DNS-сервер, который передает информацию о зоне на сервер имен, содержащий дополнительную зону. Дополнительные зоны создаются для обеспечения избыточности и уменьшения нагрузки на сервер имен, содержащий основной файл БД зоны.
Обычно зоне присваивается имя наивысшего домена в иерархии, охватываемой зоной, т. е. имя корневого домена зоны. Например, зоне, включающей домены microsoft.com и sales.microsoft.com, будет присвоено имя microsoft.com.
Файл зоны - это имя файла БД, по умолчанию состоящее из имени зоны с расширением .dns. Например, если имя зоны — microsoft.com, файл БД по умолчанию будет называться micro-soft.corn.dns.
При передаче зоны с другого сервера можно импортировать существующий файл зоны. Перед созданием новой зоны этот файл надо поместить в папку конечного компьютера %systemroot%\System32\DNS. Зона передается одним из двух способов: полным (запрос AXFR) и добавочным (запрос IXFR).
AXFR — стандартный способ передачи информации о зоне и по сути представляет собой копирование файла зоны.
Помимо AXFR, Windows 2000 поддерживает и запрос IXFR, который меньше загружает линию связи, так как реплицируются только изменения в конфигурации зоны.
Зоны обратного просмотра позволяют генерировать обратные запросы на поиск имени.
Эти зоны не обязательны, однако они нужны для работы утилит устранения неполадок и для фиксирования в файлах журнала служб IIS имени узла вместо его IP-адреса.
Типы зон - ответствуют типам зон прямого просмотра: интегрированная в Active Directory, основная и дополнительная.
Динамическое обновление службы DNS
Служба DNS включает возможность динамического обновления — Dynamic DNS (DDNS). При использовании DNS после изменений в конфигурации домена, в отношении которого сервер имен обладает полномочиями, надо вручную обновить файл БД зоны на первичном сервере имен.
При использовании DDNS серверы имен и клиенты сети автоматически обновляют файлы БД зоны.
Можно определить список авторизованных серверов, которые будут выполнять динамическое обновление. Список может включать дополнительные серверы имен, контроллеры домена и другие серверы, выполняющие регистрацию клиентов в сети, например сервер WINS или DHCP.
Обновление проходит в несколько этапов.
Клиент при помощи запроса SOA находит для регистрируемой записи первичный сервер DNS и полномочную зону.
Клиент посылает найденному DNS-серверу заявление или предварительное обновление, чтобы убедиться в регистрации записи. Если запись не зарегистрирована, клиент посылает соответствующий пакет динамического обновления для регистрации записи
В случае сбоя при обновлении клиент попытается зарегистрировать запись на другом первичном сервере DNS, если в зоне, обладающей полномочиями для данной записи есть несколько главных серверов. Если все первичные серверы не смогут выполнить динамическое обновление, через 5 минут будет произведена повторная попытка а в случае неудачи — еще одна через 10 минут. Если и на этот раз произойдет ошибка, счетчик попыток обнуляется, и через 50 минут клиент заново попытается зарегистрировать запись.
Каждый компьютер с Windows 2000 пытается зарегистрировать свои записи А и PTR. Запись А, или запись ресурса адреса узла, содержит привязку «IP-адрес/имя»; PTR-запись, или запись ресурса указателя, содержит привязку «IP-адрес/имя» для компьютера, отсылающего подтверждение регистрации. Службой, фактически генерирующей динамические обновления DNS, является клиент DHCP.
DDNS и DHCP
DDNS взаимодействует со службой DHCP для поддержки синхронизированных привязок «IP-адрес/имя», соответствующих сетевым узлам. По умолчанию служба DHCP позволяет клиентам добавлять в зону свои записи А, сама же служба DHCP добавляет в зону запись PTR. По истечении срока аренды IP-адреса служба DHCP удаляет из зоны обе эти записи.