Текст книги "Самоучитель системного администратора"

Автор книги: Александр Кенин

сообщить о нарушении

Текущая страница: 10 (всего у книги 39 страниц) [доступный отрывок для чтения: 14 страниц]

адрес может быть определен по их упаковке (вторая часть адреса – это серийный

номер адаптера). Этот адрес достаточно просто определить, если сначала подклю-

чить клиента к сети любым способом (например, назначить адрес вручную или ав-

томатически), после чего воспользоваться утилитой arp (см. разд. «Протокол ARP»

ранее в этой главе).

Сам процесс резервирования не представляет сложности: достаточно в оснастке

управления DHCP-сервером ввести в окне операции резервирования имя клиента и

его MAC-адрес.

ПРИМЕЧАНИЕ

Обратите внимание, что для резервированного клиента DHCP-сервер позволяет уста-

новить свои, индивидуальные параметры протокола TCP/IP, отличные от параметров

области.

«Подстройка» DHCP под группы клиентов

Очень часто администраторы сети хотели бы, чтобы часть клиентов получала

IP-адреса из одного диапазона, а часть – из другого, возможно, с отличающимися

параметрами настройки протокола TCP/IP.

Существует всего несколько возможностей "выделить" различных клиентов, но

только для получения отличающихся параметров области (scope option).

Первая возможность – это резервирование клиентов. Для резервированных клиен-

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

клиента нужно точно знать его MAC-адрес.

Вторая возможность – это разделение клиентов по классам: классу вендоров

(vendor class) и классу пользователей (user class). Для клиентов класса администра-

тор может настраивать индивидуальные опции DHCP-сервера. Например, в DHCP

вендором считается производитель соответствующего программного обеспечения

операционной системы. В результате можно разделить клиентов с операционными

системами разных версий и вендоров.

ПРИМЕЧАНИЕ

Администраторы могут добавлять описания классов вендоров в параметры DHCP-

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

стройки соответствующего производителя.

Использование пользовательских классов доступно в серверах DHCP Microsoft, на-

чиная с версии 2000 и выше. Основное отличие от вендорского класса состоит

в том, что устанавливать принадлежность к классу могут сами пользователи (с по-

мощью команды ipconfig /setclassid <имя_подключения> <класс> ). Например, мож-

но применить пользовательские классы для осуществления различной настройки

TCP/IP-протокола мобильных и стационарных компьютеров.

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

операционной системы, которая потом будет тиражироваться раздельно по струк-

96

Глава 3

турам предприятия. Но для малых организаций применение пользовательских

классов обычно не востребовано.

Обслуживание DHCP-сервером других сегментов сети

С помощью одного DHCP-сервера администраторы могут раздавать IP-адреса раз-

личным сегментам своей сети. Для этого необходимо на DHCP-сервере создать об-

ласти с диапазонами адресов, соответствующими этим сегментам, и обеспечить

получение DHCP-сервером запросов из другого сегмента сети.

ПРИМЕЧАНИЕ

Для соединения сегментов могут использоваться RFC-1542-совместимые маршрути-

заторы, которые имеют возможность пропускать пакеты с запросом аренды адреса.

Однако обычно такая настройка достаточно трудоемка, требует внимательного анали-

за конфигурации сети и нечасто применяется на практике.

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

образом: вы создаете область и определяете для нее любой желаемый диапазон ад-

ресов. Однако раздавать из области адреса, не соответствующие диапазону собст-

венной подсети, DHCP-сервер не будет, пока не получит адресованного ему запро-

са из другого сегмента.

Такие запросы может формировать специальный агент – агент ретрансляции

DHCP (DHCP Relay Agent). Обычно используется агент ретрансляции, установлен-

ный на коммутационном оборудовании. Но можно задействовать и агент, входящий

в состав сервера маршрутизации и удаленного доступа (Routing and Remote Access

Server, RRAS).

Принцип работы агента ретрансляции DHCP достаточно прост. Агент прослушива-

ет сеть на наличие пакетов запроса аренды адреса. Если такой пакет получен, то

агент ожидает некоторое время (на случай, если в данном сегменте сети есть свой

DHCP-сервер, который и обслужит клиента; таким образом можно повысить отка-

зоустойчивость данного сегмента сети, дублируя локальный DHCP-сервер соответ-

ствующей областью на удаленном DHCP-сервере). Если запрос клиента остается

необслуженным, то агент ретранслирует запрос в соседние сегменты сети. Если в

соседних сегментах есть DHCP-сервер, то он получает данный запрос и, поскольку

запрос отправлен с адреса другого сегмента сети, предоставляет в аренду адрес

именно того диапазона, из которого пришел запрос.

Для установки программного агента ретрансляции достаточно в настройках IP-

маршрутизации (IP Routing, пункт General) соответствующего сервера RRAS вы-

брать команду создания нового протокола маршрутизации и указать DHCP Relay

Agent. В настройках агента ретрансляции следует указать IP-адрес DHCP-сервера,

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

Далее нужно добавить в агент ретрансляции интерфейс (или несколько интерфей-

сов, если компьютер подключен к нескольким сегментам сети), через который бу-

дут пересылаться запросы аренды. Затем при необходимости следует отрегулиро-

вать порог ожидания ( boot threshold) – время, в течение которого будет ожидаться

Структура сети

97

ответ локального DHCP-сервера, и hop-count threshold – максимальное количество

маршрутизаторов, через которые может пройти этот пакет.

Порядок получения IP-адресов клиентами DHCP

Во многих случаях знание процедуры аренды IP-адреса может помочь в диагности-

ке неисправностей сети.

Первичное получение адреса

При включении компьютера клиент, настроенный на динамическое получение

адреса, передает широковещательную рассылку с запросом IP-адреса (запрос идет

от адреса 0.0.0.0 с маской 255.255.255.255). Это сообщение называется

DHCPDISCOVER. На этот запрос отвечают все DHCP-серверы сегмента сети, пред-

лагая IP-адрес. Соответствующее сообщение называется DHCPOFFER. Выделяе-

мые для аренды адреса на некоторый период резервируются и не предлагаются

другим клиентам.

Клиент ждет предложения по адресу от сервера DHCP одну секунду. Если оно не

приходит ни от одного сервера, то запрос аренды повторяется еще пять раз (через

увеличивающиеся промежутки времени приблизительно в течение 30 сек). Если

ответ от DHCP-сервера так и не получен, то клиент получает адрес по технологии

APIPA (см. разд. «Адресация APIPA» ранее в этой главе).

На первое полученное предложение от DHCP-сервера клиент отвечает широкове-

щательным сообщением (DHCPREQUEST), в котором содержится IP-адрес серве-

ра, выдавшего это предложение. После получения такого сообщения другие DHCP-

серверы освобождают зарезервированные ими IP-адреса, а сервер, предложение

которого принято, высылает подтверждение (DHCPACK). Только после получения

этого подтверждения клиент полностью инициализирует TCP/IP-протокол своего

сетевого адаптера.

Продление аренды

Запрос на продление аренды IP-адреса высылается после истечения половины пе-

риода аренды и при каждой перезагрузке системы. Для этого на сервер, выдавший

адрес, отправляется DHCPREQUEST-запрос. Если подтверждение получено

(DHCPACK), то клиент продолжает использовать текущие параметры конфигура-

ции. Если ответ не получен, то запросы на данный сервер повторяются. Перед

окончанием срока аренды и при отсутствии ответа от выдавшего IP-адрес DHCP-

сервера клиент высылает уже широковещательные запросы DHCPDISCOVER, пы-

таясь получить адрес от любого DHCP-сервера.

ПРИМЕЧАНИЕ

При отказе в аренде DHCP-сервером высылается специальный пакет DHCPNACK.

Если срок аренды закончился, а клиент не смог ни получить подтверждения от

"своего" DHCP-сервера, ни запросить новый IP-адрес, то текущие настройки

IP-протокола освобождаются, а клиент получает адрес по APIPA.

Если при перезагрузке операционной системы попытка обновления аренды адреса

неудачна и клиент не может установить связь со шлюзом по умолчанию, то теку-

98

Глава 3

щие настройки IP-адреса также освобождаются. Такая ситуация может свидетель-

ствовать о переносе компьютера в другой сегмент сети, поэтому он освобождает

свой адрес.

Диагностика и обслуживание DHCP-сервера

Обычно никаких проблем с использованием DHCP-сервера не возникает.

В противном случае следует включить протоколирование его работы (опция на од-

ной из вкладок консоли управления сервером). После выявления причин неисправ-

ностей для повышения производительности системы ведение журнала работы

DHCP-сервера следует отключить.

Сервер проводит фоновую дефрагментацию базы данных клиентов. Ручная (офлай-

новая) дефрагментация имеет смысл только в случае большой нагрузки на серверы

(более 1000 записей клиентов). При меньшем числе клиентов ручную дефрагмента-

цию (она проводится при помощи программы jetpack; которая требует предвари-

тельной остановки DHCP-сервера) рекомендуется проводить раз в несколько меся-

цев или еще реже.

При возникновении ошибок в базе достаточно просто исполнить операцию

reconcile для соответствующей области или всего сервера. При серьезных пробле-

мах допустимо остановить DHCP-сервер и удалить все файлы баз из его каталога.

После старта они будут воссозданы с пустыми значениями, которые потом снова

заполнятся по получении запросов.

DNS

В доменах Windows информация о необходимых для работы систем службах хра-

нит DNS. И основное количество проблем функционирования домена (службы ка-

талогов) связано именно с неверной настройкой администраторами службы DNS.

Поэтому стоит рассмотреть сервер DNS более подробно.

Термины DNS

DNS (Domain Name System, система доменных имен) – это служба разрешения

имен в сетях на основе протокола TCP/IP.

 Зоны DNS.

Зона DNS – это часть пространства имен, для которого DNS-сервер может вы-

полнять операции разрешения имен. Существуют зоны прямого и обратного

просмотра, которые на практике для удобства называют прямой и обратной зо-

нами.

Прямая зона позволяет по имени системы получать ее IP-адрес, обратная – по

IP-адресу "выдает" информацию об имени хоста. Поэтому если нужно по имени

компьютера узнать его адрес, то говорят о прямом разрешении имени. Если по

IP-адресу хотят получить имя компьютера, то в этом случае происходит обрат-

ное разрешение имени. Строго говоря, если в DNS зарегистрировано прямое раз-

решение имени, то должно быть зарегистрировано и обратное.

Структура сети

99

ПРИМЕЧАНИЕ

Отсутствие обратного разрешения имени является достаточно частой ошибкой в Ин-

тернете. Обычно владельцами прямой зоны данного домена и обратной зоны, которая

соответствует этому имени, являются разные люди (организации), поэтому в процессе

регистрации новых DNS-записей часто забывают создать соответствующую запись

обратной зоны.

Фактически прямые зоны соответствуют доменам некоторого уровня. Например,

зона ask.ru позволяет разрешить все запросы имен, относящихся к домену ask.ru.

Для разрешения обратных имен в домене самого верхнего уровня создана зона

in-addr.arpa. Названия зон обратного просмотра формируются добавлением к

этому имени слева имени трех октетов адреса сети в обратном порядке. Напри-

мер, для сети 195.161.192.0/24 имя обратной зоны будет 192.161.195.in-addr.arpa.

В большинстве случаев отсутствие регистрации в обратной зоне не мешает нор-

мальной работе в Сети. Однако оно может и привести к ошибкам в тех случаях,

когда необходимо установить по IP-адресу имя сервера. Например, при обмене

почтовыми сообщениями в настоящее время принято проверять принадлежность

сервера к тому домену, от имени которого он передает почту. Если обратное

разрешение имени не будет проведено, то система может получить отказ в

приеме почты.

 Первичная и вторичная зоны.

У создаваемых записей DNS должен быть один "хозяин". Чтобы все записи бы-

ли корректны, их необходимо вносить на одном DNS-сервере. В этом случае го-

ворят, что на таком DNS-сервере расположена первичная зона. Для отказоустой-

чивости на других серверах можно создать копии этой зоны: такие зоны будут

называться вторичными зонами. Вторичная зона содержит те же записи, что и

первичная, но в нее нельзя вносить изменения или добавлять новые записи. Эти

операции можно делать только для первичной зоны. В случае домена Windows

200 x и использования зоны DNS, интегрированной со службой каталогов, изме-

нения можно вносить на любом DNS-сервере такой зоны.

 Серверы имен зоны.

Для каждой первичной зоны можно создать сколько угодно копий на других

серверах. Обычно в настройках DNS-серверов предусматриваются специальные

механизмы оповещений, которые обеспечивают синхронность записей первич-

ной зоны и ее копий на вторичных серверах. Но, если это не запрещено настрой-

ками DNS-сервера, вы можете создать на своем сервере вторичную зону, обнов-

ления которой будут осуществляться по некоему графику. В результате записи

такой копии могут оказаться неактуальны. Поэтому принято для домена опреде-

лять серверы имен, информация которых "официальна". Такие серверы называ-

ют NS-записями соответствующего домена. Обычно для каждого домена созда-

ется два или три NS-сервера. Если ответ на запрос разрешения имени получен от

NS-сервера, то он считается авторизованным, другие серверы возвращают неав-

торизованные ответы.

100

Глава 3

ПРИМЕЧАНИЕ

Это не значит, что в этом случае возвращаются неверные данные. DNS-сервер раз-

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

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

например, равным неделе, то в случае внесения изменений в первичную зону необ-

ходимо быть готовым к тому, что еще до недели после смены информации на

NS-сервере другие серверы DNS могут возвращать старые значения. То есть вы

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

имени, а часть – нет. Поэтому перед предполагаемой сменой записей DNS необхо-

димо уменьшить время их жизни и выждать период, равный старому времени жизни.

Это позволит сократить период такой неопределенности в разрешении имен. После

выполнения операции настройки следует вернуться к старым величинам, чтобы сни-

зить нагрузку на сеть и DNS-серверы.

Если вы предполагаете, что копия DNS-записей на сервере DNS неактуальна, то

следует выполнить операцию очистки кэша для соответствующей зоны. Для

этого необходимо в консоли управления сервером включить опцию отображе-

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

выполнить для нее очистку. При следующем запросе данных из этой зоны сер-

вер загрузит копию с того сервера DNS, на который настроена пересылка запро-

сов. Поэтому и эта операция также не гарантирует получение актуальной копии

записей. При рассмотрении проблемных ситуаций следует выяснить на офици-

альных ресурсах адреса NS-серверов данного домена и проверить записи с по-

мощью утилиты nslookup, подключаясь к соответствующему NS-серверу

(см. разд. «Обслуживание и диагностика неисправностей DNS-сервера» далее

в этой главе).

ПРИМЕЧАНИЕ

Для обновления записей DNS на клиентских компьютерах следует очистить кэш DNS-

записей (ipconfig /flushdns).

 Передача зон.

Так называется специальная операция копирования всех записей данной зоны с

одного DNS-сервера на другой. По соображениям безопасности передача зон

обычно разрешается только на заранее определенный администратором системы

список IP-адресов DNS-серверов. Если операция передачи зоны запрещена, то

вы не сможете создать на своем DNS-сервере вторичную зону для данного до-

мена.

 Делегирование зон.

Если на DSN-сервере создана, например, прямая зона для домена test.local, то

запись о домене третьего уровня level3.test.local должна содержаться на этом же

сервере. Если географически домен level3.test.local удален от основного домена,

то поддержание записей в его зоне на DNS-сервере становится не очень удоб-

ным. Проще поручить администратору этого домена вносить изменения в DNS-

записи самостоятельно, для чего используется процесс делегирования зоны. При

делегировании зоны DNS-сервер создает у себя запись, указывающую, что за-

просы разрешения имени для этой зоны должны перенаправляться на другой

DNS-сервер, на который проведено делегирование зоны.

Структура сети

101

 Stub-зона (зона-заглушка).

При делегировании зоны на исходном сервере сохраняется информация

о NS-сервере делегированной зоны. Поскольку администратор делегированной

зоны может изменять ее DNS-записи, то он может сменить и записи NS-сервера.

Если соответствующее изменение не будет внесено на сервер, который осущест-

вляет делегирование, то процесс разрешения имен будет нарушен (основной

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

и в результате будет формироваться неверный ответ).

Для исправления подобной ситуации в DNS-сервере Windows Server 2003 введе-

ны stub-зоны. При создании stub-зоны в ней определяются NS-записи делегиро-

ванной зоны. Причем если администратор делегированной зоны меняет эти

записи, то соответствующие изменения вносятся и в записи stub-зоны. В резуль-

тате гарантируется целостность процесса разрешения имен.

 Зона «точка».

Домен самого верхнего уровня, как я уже указывал ранее, принято называть

именем "точка". Если в DNS создать зону "точка" (зона с таким именем создает-

ся при установке службы каталогов с одновременной установкой и настройкой

сервера DNS), то это будет фактически означать, что данный сервер является

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

самостоятельно любые запросы имен. Если этот DNS-сервер не может разре-

шить имя, то его ответ будет сообщать, что такого хоста не существует.

ПРИМЕЧАНИЕ

При необходимости пересылки запросов DNS на другие серверы зону "точка" следует

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

Порядок разрешения имен в DNS

Для разрешения имен в DNS предусмотрено два типа запросов: итеративный и ре-

курсивный.

Итеративный запрос служит для получения от DNS-сервера, которому он направ-

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

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

нить все операции для разрешения имени. Обычно для этой цели необходимо вы-

полнить несколько запросов к различным серверам DNS.

Процесс определения имени с использованием итеративных запросов весьма тру-

доемок. Нужно найти NS-сервер для данного домена и затем запросить от него

данные по требуемому имени. Обычно клиенты все эти операции "возлагают" на

DNS-серверы, отправляя им рекурсивный запрос.

DNS-сервер после получения рекурсивного запроса просматривает собственный

кэш имен. Если он находит нужную запись и она еще не устарела, то это значение

возвращается клиенту. Если записи нет, то сервер предпринимает попытку поиска

сервера имен для домена, содержащегося в запросе. Чтобы найти такой сервер, за-

прос всегда отправляется на корневой сервер, а от него получают информацию по

102

Глава 3

домену первого уровня, запросом на домен первого уровня получают информацию

о NS-серверах домена второго уровня и т. д. После этого отправляется итеративный

запрос на NS-сервер соответствующего домена. Естественно, что большинство ин-

формации от корневых доменов уже кэшировано на данном сервере. Этим резко

снижается нагрузка на сеть и уменьшается время ответа на запрос. В результате

запросы "не доходят" до корневых серверов, но сама цепочка разрешения имени

всегда выполняется от корня до текущего домена.

Обычно администраторы локальных DNS-серверов настраивают свой сервер на пе-

ресылку (forwarding) запросов разрешения имен на тот или иной сервер DNS

(обычно это DNS-сервер провайдера). Тем самым вся процедура разрешения имен

будет выполняться уже другим сервером. Поскольку мощные серверы Интернета

обычно имеют существенно больший кэш и лучший канал подключения к глобаль-

ной сети, то таким способом достигается уменьшение времени ответа и снижение

трафика.

Основные типы записей DNS

При создании первичной зоны для своего домена следует обратить внимание на

создание некоторых специальных записей ресурсов ( resource records), которые по-

лезны для получения информации общего типа:

 SOA (Start of Authority).

Серийный номер зоны. В DNS автоматически увеличивается при любом измене-

нии записей зоны. Используется в операциях переноса зон (если номер изменил-

ся, то происходит обновление записей вторичной зоны). На практике принято

этот номер формировать на основе даты последнего изменения: год-месяц-день-

(время). Например, так: 20110810.

 NS (Name Server).

Адреса "официальных" серверов имен данной зоны. Эти серверы возвращают

авторизованные ответы.

 RP (Responsible Person).

Адрес электронной почты лица, ответственного за внесение изменений в записи

зоны. Наличие записи и поддержание ее актуальности желательно, чтобы в слу-

чае возникновения каких-либо вопросов по домену организации у специалистов

были реальные контактные данные. Обратите внимание, что символ "@" адреса

электронной почты заменяется на точку.

 A (Host Address).

Эта запись содержит информацию об имени системы и ее IP-адресе. Именно

этот тип записи добавляется в DNS-сервер при регистрации хостов.

 PTR (Pointer, указатель).

Так называется запись в обратной зоне. Настройками DNS локальных доменов

обычно предусматривается автоматическое создание (изменение) PTR-записи

при добавлении А-записи в прямую зону.

Структура сети

103

 CNAME (Canonical NAME).

Записи псевдонима. Используются, если хосту необходимо дать второе DNS-

имя.

 MX (Mail eXchanger).

Запись хранит IP-адрес сервера электронной почты (SMTP-сервера), который

обслуживает данный домен. Чтобы на данный домен можно было отправлять

электронную почту, в базе DNS для домена должна быть обязательно создана

MX-запись. В целях резервирования может быть создано несколько MX-

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

почта отправляется на адрес, содержащийся в MX-записи с наименьшим весом.

Если этот сервер не отвечает, то делаются попытки отправить почту на адреса,

соответствующие MX-записям с другими весами в порядке их возрастания.

 SRV (Запись службы).

Специальный тип записи, используемый для обнаружения в домене служб (на-

пример, службы IP-телефонии и т. п.). Записи о системных службах Windows ав-

томатически создаются службой каталогов. Ручное добавление записей осуще-

ствляется при настройке дополнительных продуктов в соответствии с прилагае-

мой технической документацией.

ПРИМЕЧАНИЕ

Кроме описанных существуют и другие типы записей, предназначенные, например,

для DNSSEC, IPv6 и т. п., но мы не будем их касаться в этой книге.

Установка сервера DNS

Сервер DNS можно установить только на компьютер со статическим IP-адресом.

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

вания организации, может правильно разрешать неполные имена. То есть он должен

сообщить правильный адрес как на запрос для test.mydomain.local, так и для запро-

са на имя test. Для этого необходимо, чтобы основной DNS-суффикс компьютера,

на котором устанавливается сервер DNS, совпадал с суффиксом имени домена

организации. Соответствующие настройки выполняются в параметрах TCP/IP-

протокола, статически устанавливаемых для сетевого адаптера сервера DNS.

Для установки службы DNS-сервера достаточно выбрать соответствующую опцию

среди добавляемых компонентов (выбрать роль). В целях отказоустойчивости ин-

формационная система должна быть настроена на использование нескольких сер-

веров DNS.

После запуска службы DNS следует уточнить некоторые параметры настройки. Во-

первых, если сервер должен разрешать имена сети Интернет, то следует удалить

зону "точка" (если такая создана при установке) и указать IP-адреса тех серверов

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

таковых указываются DNS-серверы провайдера.

Далее следует создать на сервере DNS необходимые зоны. Эта операция выполня-

ется при помощи соответствующего мастера. Следует учесть, что если сервер

104

Глава 3

предназначен для разрешения имен домена Windows и является контроллером до-

мена, то оптимальным решением будет создание зоны, интегрированной со служ-

бой каталогов. Такой вариант позволит использовать службы Windows для репли-

кации данных между серверами DNS. При этом зона DNS на каждом сервере фак-

тически будет являться первичной (допускать внесение изменений), а сами

данные – безопасными (при работе с зоной будет применена действующая

в Windows система безопасности).

Интегрированная в службу каталогов система имен реплицируется в Windows 200 х

по всем контроллерам домена. Начиная с ОС Windows Server 2003, добавлена воз-

можность размещения зоны DNS в собственных разделах каталога. Это позволяет

реплицировать интегрированные в службу каталогов зоны только на серверы DNS

либо домена, либо леса, в зависимости от того, какой раздел вы создаете, исходя из

структуры организации. Создание такого раздела выполняется из оснастки управ-

ления DNS-сервером (соответствующая команда меню сервера).

Для зон, обслуживающих домен Windows, обязательно должна быть включена оп-

ция динамического обновления. В целях безопасности следует выбрать вариант

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

служба DHCP была настроена на запуск не от системной учетной записи, а от име-

ни специально созданного для такой цели пользователя.

Если вы не хотите регистрировать всех клиентов в DNS, то можно настроить сервер

DNS так, чтобы он перенаправлял неразрешенные запросы имени на WINS-сервер.

Для этого в настройках DNS-сервера в свойствах зоны на вкладке WINS следует

включить опцию пересылки запросов на WINS-сервер и указать соответствующие

IP-адреса.

После установки и настройки основных параметров DNS-сервера необходимо вы-

полнить его первичную проверку. Для этого следует в свойствах сервера на вкладке

мониторинга включить опции проверки как работы самого сервера, так и правиль-

ности перенаправления запросов и провести тест, после чего проверить коррект-

ность разрешения имен как внутренней сети, так и внешней (если сервер DNS ис-

пользуется и для разрешения имен Интернета) с помощью команды nslookup

(см. разд. «Обслуживание и диагностика неисправностей DNS-сервера» далее

в этой главе).

ПРИМЕЧАНИЕ

При создании домена одновременно с установкой DNS прямая зона создается авто-

матически. Зону обратного разрешения следует создать вручную.

Записи домена Windows

Если на сервере DNS зарегистрирована зона, соответствующая домену Windows, то

в этой зоне должны присутствовать специализированные записи, которые опреде-

ляют нахождение служб каталогов домена. Данные записи создаются автоматиче-

ски через некоторое время после установки службы каталогов.

Структура сети

105

Разделение DNS

Все большее число сотрудников начинают использовать мобильные компьютеры

для доступа к ресурсам организации как изнутри локальной сети, так и из Интерне-

та. В целях сокращения затрат на изменение конфигураций персональных компью-

теров следует выполнять настройки программного обеспечения так, чтобы доступ

к сетевым ресурсам локальной сети осуществлялся единообразно, независимо от

того, выполняется подключение из локальной или глобальной сети. Реализуется

такое требование разделением DNS ( DNS split).

Технология разделения DNS подразумевает, что разрешение имен локальной сети и

Интернета для одного доменного имени настраивается на различные DNS-серверы.

Суть решения будет понятна из рассмотрения двух возможных ситуаций.

 Одинаковые имена локального домена и домена Интернета.

Если имя домена Windows совпадает с именем домена Интернета, то единствен-

ная необходимая операция – это правильная настройка публикации внутренних

ресурсов в глобальной сети. Когда клиент локальной сети пытается получить

доступ к каким-либо ресурсам, он запрашивает их месторасположение у локаль-

ного, внутреннего сервера DNS. Этот сервер возвращает клиенту внутренний

адрес ресурса, к которому и осуществляется подключение (рис. 3.11).

Рис. 3.11. Разделение DNS

106

Глава 3

На сервере DNS, обслуживающем домен Интернета этой же организации, необ-

ходимо настроить А-запись соответствующего ресурса на внешний адрес бранд-

мауэра данной организации, а на брандмауэре настроить публикацию внутрен-

него ресурса таким образом, чтобы запрос, приходящий на брандмауэр и адре-

сованный на данное имя, перенаправлялся на локальный адрес ресурса.

В результате, независимо от точки подключения, запрос клиента всегда будет

доставлен на один и тот же локальный ресурс системы.

При использовании технологии разделения DNS клиент локальной сети и ком-

пьютер Интернета при разрешении одного и того же имени будут обращаться к

различным DNS-серверам. В результате локальный клиент будет обращаться по

локальному адресу, а клиент Интернета перешлет запрос на брандмауэр органи-

зации, который и перенаправит его на локальный адрес запрашиваемого ресурса.

 Различные имена локального домена и домена Интернета.

Если "внутреннее" и "внешнее" имена домена организации не совпадают, то на

внутреннем сервере DNS необходимо создать первичную зону для домена с

"внешним" именем. Далее в этой зоне следует создать записи, соответствующие

именам систем, предоставляющих необходимые службы (естественно, что изме-

нение записей этой зоны должно выполняться только вручную), причем в каче-

стве IP-адресов этих записей должны быть указаны локальные IP-адреса систем.

Таким образом, на внутренних DNS-серверах будет по две зоны: зона, соответ-

ствующая "внутреннему" домену Windows (реальные внутренние названия ком-

пьютеров локальной сети), и зона с "внешним" именем (фактически содержащая

синонимы, вторые имена только для компьютеров, публикующих ресурсы

в глобальной сети). Так же, как и в предыдущем примере, следует настроить

публикацию внутренних ресурсов на брандмауэре организации.

Клиентов необходимо настроить (в том числе и в локальной сети) на подключе-

ние к ресурсам по внешним именам. Если клиент обратится к почтовому серверу

изнутри организации, то он запросит внутренний сервер DNS об адресе, соот-

ветствующем внешнему имени почтовой системы. Поскольку на внутреннем

сервере DNS существует одноименная первичная зона, то сервер будет считать-