Агент-ретранслятор DHCP/BOOTP

Отдельно следует сказать о специальном агенте ретрансляции ВООТР/ DHCP. Работа протоколов ВООТР и DHCP основана на механизмах широковещания. Маршрутизаторы по умолчанию обычно не ретранслируют широковещательные рассылки, что может создать трудности для получения IP-адресов клиентами, находящимися в другой подсети. Передача широковещательных рассылок DHCP/BOOTP выполняется агентом ретрансляции. Под агентом ретрансляции DHCP понимается хост, который прослушивает подсети на наличие широковещательных сообщений DHCP/BOOTP и переадресовывает их на некоторый заданный DHCP-сервер. Использование агентов ретрансляции избавляет от необходимости устанавливать сервер DHCP в каждом физическом сегменте сети. Агент не только обслуживает прямые локальные запросы клиента DHCP и перенаправляет их на удаленные DHCP-серверы, но также возвращает ответы удаленных DHCP-серверов клиентам.

Авторизация DHCP-сервера

Прежде чем DHCP-сервер сможет приступить к процессу выделения адресов DHCP-клиентам, он предварительно должен быть авторизован. Авторизация DHCP-сервера является обязательным условием его нормального функционирования. Иными словами, в каталоге Active Directory должен быть создан объект, соответствующий установленному DHCP-серверу. Только после этого клиенты смогут работать с данным сервером. Все обязанности по осуществлению контроля над авторизацией DHCP-серверов возложены непосредственно на сами DHCP-серверы. Осуществляется это следующим образом. Служба DHCP-сервера при запуске обращается к Active Directory, чтобы просмотреть список IP-адресов авторизованных серверов. Если она не обнаруживает свой адрес в этом списке, она останавливает свою работу.

Для авторизации DHCP-сервера необходимо запустить оснастку DHCP и в контекстном меню объекта, расположенного в корне пространства имен утилиты, выбрать пункт Manage authorized servers (Управление авторизованными серверами). Система покажет список уже авторизованных DHCP-серверов. Нажмите кнопку Authorize (Авторизовать) и укажите имя авторизуемого DHCP-сервера или его IP-адрес. Выбранный сервер будет немедленно добавлен в список авторизованных серверов.

Безопасная регистрация доменных имен

Для зон, интегрированных в Active Directory, каждая ресурсная запись представляет собой объект каталога. Для таких зон можно задействовать механизм безопасной динамической регистрации (secure dynamic update). Этот механизм позволяет администратору управлять доступом к объектам, ассоциированным с ресурсными записями. Администратор может определить пользователей, которым разрешено изменять отдельные ресурсные записи. Например, администратор может определить группы пользователей, которым разрешено производить какие-либо изменения ресурсных записей.

Динамическая регистрация имен

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

В спецификации службы DNS определена возможность использования механизма динамической регистрации хостами своих доменных имен. В процессе динамической регистрации клиенты могут создавать и изменять ресурсные записи типа А и PTR. Контроллеры домена могут также динамически регистрировать ресурсные записи типа SRV.

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

Если клиент находится под управлением операционных систем Windows 2000/XP или Windows Server 2003, он может самостоятельно зарегистрировать свое имя в базе данных DNS-сервера. В этом случае регистрация осуществляется службой клиента DHCP компьютера. Остальные версии Windows (Windows 9.X/NT/ME) не способны динамически зарегистрировать свое доменное имя. В этой ситуации задача регистрации имени может быть возложена на службу сервера DHCP. Служба сервера DHCP, реализованная в Windows Server 2003, может зарегистрировать доменное имя одновременно с выделением в аренду IP-адреса. В этом случае, регистрация доменного имени происходит без участия клиента и незаметно для них.

Клиент предпринимает попытку зарегистрировать доменное имя в базе данных DNS-сервера в следующих ситуациях:

 происходит изменение IP-адреса. Операция динамической регистрации инициируется при любом изменении списка адресов хоста (добавление нового адреса, удаление или модификация существующего);

  выполнение утилиты командной строки Ipconfig с ключом /renew. В этом случае инициируется процесс выделения хосту в аренду нового IP-адреса (или набора адресов, если компьютер имеет несколько сетевых адаптеров);

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

 выполнение утилиты командной строки Ipconfig с ключом /registerdns. В результате происходит принудительное обновление доменного имени клиента в базе данных DNS-сервера.

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

Параллельно с механизмом динамической регистрацией имен DNS-сервер активизирует механизм очистки (scavenging) базы данных от устаревших ресурсных записей. Рассмотрим, каким образом процесс очистки позволяет удалить фантомы из базы данных записей.

С каждой ресурсной записью ассоциируется временная метка (timestamp), определяющая время ее создания. Ресурсная запись считается актуальной в течение определенного периода времени, называемого периодом стабильности (no-refresh interval). Обновление сведений о ресурсной записи в течение этого периода приводит к обновлению значения временной метки. Временная метка обновляется каждый раз, когда клиент обновляет ресурсную запись. Система ожидает обновления ресурсной записи в течение периода, который называется периодом обновления (refresh interval). Если для ресурсной записи истек период обновления, а она не была обновлена, запись помечается как устаревшая (aging). Все устаревшие ресурсные записи удаляются в процессе очистки базы. Этот процесс автоматически инициируется системой через определенные промежутки времени.

Использование утилиты DnsCmd

Подобная проверка может быть осуществлена при помощи стандартной системной утилиты DnsCmd.exe. Утилиту можно запускать непосредственно на DNS-сервере. В этом случае в параметрах утилиты можно не указывать имя сервера.

Для проверки зон можно использовать ключ /EnumZones:

С:\dnscmd /EnumZones

Enumerated zone list:

Zone count = 3

Zone name Type Storage Properties

Cache File

_msdcs.khsu.ru Primary AD-Forest Secure

khsu.ru Primary AD-Domain Secure

Command completed successfully.

Следует заметить, что в приведенном примере зона "." представляет ссылки на корневые серверы пространства имен DNS, загружаемые при запуске DNS-сервера. Поле Type определяет тип зоны. Поле storage определяет способ хранения зоны и область распространения изменений. Поле Properties позволяет получить информацию о свойствах зоны.

Для получения более подробной информации о зоне необходимо использовать ключ /ZoneInfo. Ниже приводится пример выполнения утилиты с этим ключом:

c:\dnscmd /Zoneinfo khsu.ru

Zone query result:

Zone info:

ptr = 00083140

zone name = khsu. ru

zone type = 1

update = 2

DS integrated = 1

data file = (null)

using WINS = 0

using Nbstat = 0

aging = 0

refresh interval =168

no refresh = 168

scavenge available = 3520930 Zone Masters

NULL IP Array.Zone

Secondaries NULL IP Array, secure sees

rectory partition = AD-Domain flags 00000015 zone DN

4>= DC=khsu.ru,cn=MicrosoftDNS,DC=DomainDnsZones, DC=khsu,DC=ru Command completed successfully.

Для получения информации о ресурсных записях определенной зоны необходимо выполнить утилиту с ключом /EnumRecords. Ниже приводится пример работы утилиты:

c:\dnscmd /EnumRecords khsu.ru _tcp /Type SRV

Returned records:

_gc [Aging:3520762] 600 SRV 0 100 3268 store.khsu.ru.

_kerberos [Aging:3520762] 600 SRV 0 100 88 store.khsu.ru.

_kpasswd [Aging:3520762] 600 SRV 0 100 464 store.khsu.ru.

_ldap [Aging:3520762] 600 SRV 0 100 389 store.khsu.ru.

Command completed successfully.

В приведенном примере отображаются все ресурсные записи типа SRV, содержащиеся в контейнере _tcp зоны khsu. ru.

Использование утилиты Nslookup

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

Основным диагностическим инструментом, позволяющим проверить способность DNS-сервера обрабатывать запросы, является утилита командной строки Nslookup.exe. Эта утилита является стандартным инструментом диагностики DNS-сервера и может использоваться совместно с любыми реализациями DNS-серверов. Еще более полную информацию может дать утилита NetDiag.exe, а на контроллерах домена — утилита DCdiag.exe.

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

Ниже приводится пример тестирования DNS-сервера — запрашивается адрес хоста main.khsu.ru!

с:\nslookup main.khsu.ru Server:root.khsu.ru

Address:192.168.1.1

Name:main.khsu.ru

Address: 192.168.1.6

В приведенном примере строка server указывает на DNS-сервер, в контексте которого осуществляется разрешение запросов с помощью утилиты Nslookup.

Изменение области репликации

В поле Replication (Репликация) вкладки General (Общие) окна свойств зоны указывается область распространения изменений в содержимом зоны. Это поле отображается только для зон, интегрированных в Active Directory. Фактически значение этого поля определяет раздел каталога, в котором хранится содержимое зоны. Соответственно, выбор раздела влияет на область репликации изменений. Нажав кнопку Change (Изменить), администратор может в открывшемся окне определить новое место хранения зоны (рис. 13.12). Перечень значений, предлагаемых администратору в этом окне, приведен в табл. 13.4.

Рис. 13.12. Изменение области распространения содержимого зоны

Таблица 13.4. Области распространения содержимого зоны

Область репликации		Описание
То all DNS servers in the Active Directory forest		Зона размещается в разделе приложений, доступном в пределах всего леса
To all DNS servers in the Active Directory domain		Зона размещается в разделе приложений, доступном в пределах отдельного домена
To all domain controllers in the Active Directory domain		Зона размещается в доменном разделе каталога. Этот способ размещения зоны необходимо выбирать, если в качестве носителей зоны используется Windows 2000 DNS
To all domain controllers specified in the scope of the following application directory partition		Зона размещается в разделе приложений, который создается администратором

Изменение типа зоны

На вкладке General (Общие) в поле Туре (Тип) отображается тип зоны. Администратор может в любой момент изменить его, нажав кнопку Change (Изменить). В открывшемся окне (рис. 13.11) администратор должен выбрать новый тип зоны. Обратите внимание, что установленный флажок Store the zone in Active Directory (Хранить зону в Active Directory) свидетельствует о том, что зона интегрирована в Active Directory. Поскольку этот способ хранения не допускает использование дополнительных носителей зон, выбор переключателя Secondary zone (Дополнительная зона) в качестве типа зоны приводит к тому, что данный флажок автоматически снимается и становится недоступным для изменения.

Рис. 13.11. Выбор типа зоны

Если зона хранится в Active Directory, администратор может регламентировать доступ к объектам пространства имен DNS на вкладке Security (Безопасность). Эту вкладку имеет каждый объект пространства имен DNS (домены, зоны, ресурсные записи).

Как работает DHCP

Когда новый DHCP-клиент подключается к сети, он запрашивает уникальный IP-адрес у DHCP-сервера. DHCP-сервер выделяет клиенту один адрес из пула адресов. Этот процесс (рис. 13.13) состоит из четырех шагов: 1) клиент DHCP запрашивает IP-адрес (DHCP Discover, обнаружение), 2) DHCP-сервер предлагает адрес (DHCP Offer, предложение), 3) клиент принимает предложение и запрашивает адрес (DHCP Request, запрос) и 4) адрес официально назначается сервером (DHCP Acknowledgement, подтверждение). Адрес клиенту предоставляется на определенный срок, называемый периодом аренды. По истечении половины этого срока клиент должен возобновить аренду. В противном случае, по истечении срока аренды, выделенный клиенту адрес возвращается в пул для повторного использования. В этой ситуации клиент должен инициировать процедуру получения IP-адреса с самого начала.

Рис. 13.13. Схема взаимодействия DHCP-сервера и DHCP-клиента

Конфигурирование зон

Администратор может изменить конфигурацию зоны по своему усмотрению в любой момент. Для выполнения изменений необходимо вызвать окно свойств зоны, выбрав в контекстном меню объекта, ассоциированного с зоной, пункт Properties (Свойства).

Рис. 13.10. Окно свойств зоны DNS, интегрированной в Active Directory

Окно свойств (рис. 13.10) обычной зоны состоит из пяти вкладок. В случае зоны, интегрированной в Active Directory, появляется шестая вкладка Security (Безопасность), на которой администратор может ограничить доступ к зоне и ее содержимому.

Механизм постоянных соединений

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

В Windows Server 2003 реализация службы WINS поддерживает механизм постоянного соединения с партнером по репликации. Данный механизм позволяет устанавливать соединение только один раз, после чего оно сохраняется активным. Любое изменение, осуществляемое в базе данных сервера, будет немедленно реплицировано на другие серверы, с которыми установлено постоянное соединение. Благодаря этому базы данных всех WINS-серверов будут всегда находиться в актуальном состоянии.

Механизм постоянных соединений позволяет поддерживать базы данных всех WINS-серверов в актуальном состоянии. Однако этот механизм требует, чтобы коммуникационные линии, соединяющие партнеров по репликации, были доступны постоянно. Как правило, механизм постоянных соединений используется в локальной сети. Если WINS-серверы соединяются по коммутируемым линиям, необходимо использовать обычный способ репликации.

Методы хранения зоны

Реализация службы DNS в Windows Server 2003 предлагает три метода хранения содержимого зоны:

 хранение зоны в отдельном файле;

 хранение зоны в доменном разделе каталога;

 хранение зоны в разделах приложений.

Хранение зоны в файле

Этот метод хранения является традиционным и единственным, описанным в спецификации службы DNS. Вся информация о содержимом зоны хранится в специальном текстовом файле. Имя файла образуется из названия зоны, к которому добавляется расширение dns. На DNS-сервере может быть размещено несколько зон. В этом случае каждая зона будет храниться в отдельном файле.

Именно такой метод хранения зоны используется подавляющим большинством реализаций DNS-серверов (в том числе и Windows NT DNS).

Метод хранения содержимого зоны в файле является достаточно простым и эффективным. Администратор может изменять этот файл при помощи любого текстового редактора. В случае необходимости администратор всегда сможет перенести зону на любой другой DNS-сервер, в том числе работающий не на платформе Windows.

Для размещения всех файлов, с которыми работает служба DNS (в том числе файлы зоны), используется каталог %SystemRoot%\system32\dns.

Хранение зоны в доменном разделе каталога

В результате интеграции службы DNS со службой каталога стало возможным размещение содержимого зоны в Active Directory. В этом случае зона представляется в виде объекта каталога контейнерного типа, внутри которого размещаются объекты, ассоциированные с ресурсными записями. Зона, содержимое которой хранится в каталоге, получила название зоны, интегрированной в Active Directory (Active Directory-integrated zone). Подобная схема хранения зоны может быть использована только в том случае, если служба DNS устанавливается на контроллере домена.

Для размещения содержимого зоны используется доменный раздел каталога. Совокупность объектов, ассоциированных с зонами DNS, размешается в объекте контейнерного типа MicrosoftDNS в дереве объектов того домена, к которому принадлежит сервер. Для размещения зоны используется класс объектов каталога dnszone, а для ресурсных записей — класс dnsNode.

Размещение зоны в каталоге позволяет задействовать множество механизмов службы каталога и, в первую очередь, подсистему репликации изменений. Поскольку зона и ресурсные записи рассматриваются в виде объектов, любое их изменение в одной из копий приводит к распространению этих изменений на все остальные копии. Это означает, что изменение зоны может производиться в контексте любого контроллера домена. Другими словами, любой DNS-сервер, установленный на контроллере домена, может выступать в качестве основного носителя для зоны, размещенной в каталоге. Администратор может создать столько носителей зоны, сколько имеется контроллеров домена.

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

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

Хранение зоны в разделах приложений

Этот метод хранения зоны впервые реализован в Windows Server 2003. Соответственно, он может быть использован только на контроллерах домена, работающих под управлением только этой операционной системы.

Для размещения содержимого зоны могут использоваться разделы приложений (application partitions). (Подробнее разделы приложений описаны в главе 18 "Основные концепции Active Directory".) По умолчанию для размещения содержимого зон в каталоге создаются два раздела приложений:  ForestDnsZones.<имя_DNS_леса> и DomainDnsZones.<имя_DNS_леса>. Однако администратор может создать и другие разделы приложений, которые и будут использоваться для хранения зон. В табл. 13.3 кратко описан каждый из этих разделов.



Таблица 13.3. Разделы приложений, по умолчанию используемые для размещения зоны

Раздел приложения	Описание
ForestDnsZon.es . <имя DNS леса>	Раздел приложений, доступный DNS-серверам в рамках всего леса доменов. Реплика раздела автоматически создается при установке DNS-сервера на любом контроллере в лесу. Соответственно, любой такой DNS-сервер будет выступать носителем зоны, размещенной в подобном разделе приложений
DomainDnsZones . <имя DNS леса>	Раздел приложений, доступный DNS-серверам в рамках домена. Реплика раздела автоматически создается при установке DNS-сервера на любом контроллере этого домена

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

Мониторинг DHCP-сервера

После того как DHCP-сервер настроен и функционирует, следует периодически осуществлять мониторинг его состояния. Для получения необходимого аналитического материала администратор может активизировать режим протоколирования событий. Для этого на вкладке General (Общие) окна свойств DHCP-сервера нужно установить флажок Enable DHCP audit logging (Разрешить запись журнала DHCP) (рис. 13.20). После этого вся информация, связанная с функционированием сервера DHCP, будет заноситься в текстовый файл журнала.

Рис. 13.20. Активизация режима протоколирования DHCP-сервера

Мониторинг и оптимизация

В Windows Server 2003 администратор может осуществлять мониторинг DNS-сервера и по его результатам оптимизировать соответствующие параметры настройки. Для этой задачи администратор может использовать следующие инструменты и возможности:

 системный монитор (Performance Monitor);

опции протоколирования;

 статистика по DNS-серверу;

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

Настройка механизма динамической регистрации доменных имен

Если нужно, чтобы регистрация доменных имен выполнялась непосредственно на уровне DHCP-сервера, необходимо в окне свойств объекта, ассоциированного с сервером, перейти на вкладку DNS и установить флажок Enable DNS dynamic updates according to the settings below (Разрешить динамические обновления в DNS в соответствии со следующими настройками) (рис. 13.19). Дополнительно нужно выбрать условия регистрации доменных имен в базе данных DNS. Сервер DHCP будет посылать сообщение службе DNS каждый раз, когда клиенту выдается IP-адрес.

Рис. 13.19. Активизация режима автоматической регистрации доменных имен в базе данных DNS

Настройка репликации между WINS-серверами

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

Настройка сервера

После того как программное обеспечение DNS-сервера было установлено на компьютер, необходимо выполнить его настройку. Фактически процедура начальной настройки DNS-сервера сводится к созданию необходимых зон, которые будут использоваться для хранения ресурсных записей. Если вы устанавливаете DNS-сервер одновременно с созданием первого контроллера домена в корпоративной сети, все операции по конфигурированию соответствующей DNS зоны будут выполнены непосредственно мастером установки Active Directory (Active Directory Installation Wizard). Разумеется, данный метод создания зоны является наиболее предпочтительным. В качестве альтернативы администратор может создать зону самостоятельно.

Необходимо помнить о том, что мастер установки Active Directory не создает на DNS-сервере зон обратного просмотра (reverse domain zone). Поэтому по окончании работы мастера администратор должен создать и настроить эту зону вручную.

В Windows Server 2003 создание корневого домена леса не приводит к автоматическому созданию корневого домена в пространстве имен DNS. Таким образом, администратор всегда может сконфигурировать первый установленный DNS-сервер для перенаправления запросов к внешнему пространству имен. Информация о вышестоящих серверах указывается на вкладке Forwarders (Перенаправление) окна свойств DNS-сервера. Например, администратор может указать на этой вкладке информацию о DNS-сервере Интернета.

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

 запрещать или разрешать использование зоны;

 изменять способ хранения зоны;

 разрешать динамическое обновление зоны.

Также можно настраивать начальные записи зоны (Start Of Authority, SOA), ресурсные записи, делегирование зон, списки оповещения, использование просмотра WINS, а также управлять зонами обратного просмотра (reverse zone).

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

 Оснастка DNS (DnsMgmt.msc) (рис. 13.7). Эта утилита предоставляет администратору графический интерфейс для управления DNS-серверами; она располагается в меню Administrative Tools (Администрирование).

 Утилита командной строки DnsCmd.exe. Утилита поставляется в составе Windows Server 2003. Утилита может быть использована, например, при создании пакетных файлов сценариев, а также в ситуации, когда администратор конфигурирует DNS-серверы через коммуникационные линии с ограниченной пропускной способностью.

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

 при изменении имени компьютера-сервера;

 при изменении имени домена для компьютера-сервера;

 при изменении IP-адреса компьютера-сервера;

 при удалении сервера DNS из сети;

 при изменении основного сервера (primary server) зоны.



Рис. 13.7. Окно оснастки DNS

Настройка статического отображения

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

 Динамически. Этот тип записей создается в базе данных сервера WINS-клиентами в процессе регистрации локальных NetBIOS-имен.

 Статически. Администратор создает записи вручную, определяя статическое отображение (static mapping) NetBIOS-имени на IP-адрес.

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

Обзор DHCP

Протокол DHCP представляет собой развитие протокола ВООТР (RFC 951 и 1084), позволявшего динамически назначать IP-адреса (в дополнение к удаленной загрузке бездисковых станций). При этом служба DHCP предоставляет все данные для настройки стека протоколов TCP/IP и дополнительные данные для функционирования определенных серверов. Рассмотрим основные понятия протокола DHCP.

 Область DHCP (scope). Под областью DHCP понимается административная группа, идентифицирующая полные последовательные диапазоны возможных IP-адресов для всех DHCP-клиентов в физической подсети. Области определяют логическую подсеть, для которой должны предоставляться услуги DHCP, и позволяют серверу задавать параметры конфигурации, выдаваемые всем DHCP-клиентам в подсети. Область должна быть определена прежде, чем DHCP-клиенты смогут использовать DHCP-сервер для динамической конфигурации TCP/IP.

 Суперобласти (superscope). Множество областей, сгруппированных в отдельный административный объект, представляет собой суперобласть. Суперобласти полезны для решения различных задач службы DHCP.

 Пул адресов (address pool). Если определена область DHCP и заданы диапазоны исключения, то оставшаяся часть адресов называется пулом доступных адресов (в пределах области). Эти адреса могут быть динамически назначены клиентам DHCP в сети.

 Диапазоны исключения (exclusion range). Диапазон исключения — ограниченная последовательность IP-адресов в пределах области, которые должны быть исключены из предоставления службой DHCP.

 Резервирование (reservation). Резервирование позволяет назначить клиенту постоянный адрес и гарантировать, что указанное устройство в подсети может всегда использовать один и тот же IP-адрес.

 Период аренды (lease). Под периодом аренды понимается отрезок времени, в течение которого клиентский компьютер может использовать выделенный IP-адрес. В момент истечения половины срока действия аренды клиент должен возобновить аренду, обратившись к серверу с повторным запросом. Следует помнить о том, что продолжительность периода аренды влияет на частоту обновления аренды (другими словами, на интенсивность обращений к серверу);

 Опции DHCP (option DHCP). Опции DHCP представляют собой дополнительные параметры настройки клиентов, которые DHCP-сервер может назначать одновременно с выделением IP-адреса. Сервер DHCP поддерживает более 30 опций DHCP согласно RFC 2132. В качестве примера опции DHCP можно привести следующие параметры: IP-адреса шлюза по умолчанию, WINS-сервера или DNS-сервера. Опции могут быть определены как для каждой области отдельно, так и глобально для всех областей, размещенных на DHCP-сервере. Кроме стандартных опций, описанных в спецификации протокола DHCP, администратор может определять собственные опции.

Передача зоны

Процесс синхронизации всех копий зоны, распределенных между множеством носителей, называется передачей зоны (transfer zone). Поскольку изменения могут вноситься только в копии основного носителя, передача зоны всегда осуществляется по направлению от основного носителя к дополнительному. Основной носитель зоны последовательно передает измененную копию зоны каждому дополнительному носителю по отдельности. Хотелось бы заметить, что базовым считается режим передачи, когда передается вся измененная зона целиком.

Время от времени дополнительные носители зоны обращаются к основному носителю зоны, сравнивая номера версий и выявляя факт изменения зоны. Периодичность этих обращений определяется интервалом обновления (refresh interval). С другой стороны, дополнительные носители могут быть извещены (notify) основным носителем о факте изменения зоны.

После того как обнаружен факт изменения, носители запрашивают передачу зоны. Если передача по каким-либо причинам не начинается, носители повторяют свой запрос через определенные промежутки времени, называемые интервалами повторения (retry interval). Если зона не была обновлена в течение периода, называемого интервалом истечения срока действия (expire interval), зона считается устаревшей и не может быть использована для разрешения имен. Интервал обновления, интервал повторения и интервал истечения срока действия определяются на уровне всей зоны посредством соответствующих параметров записи SOA.

Передача зоны инициируется при следующих обстоятельствах:

 истекает интервал обновления зоны;

 основной носитель извещает дополнительный носитель о факте изменения зоны;

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

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

Служба DNS, реализованная в Windows Server 2003, позволяет осуществлять передачу не всей зоны целиком, а частично — только произведенные изменения. Этот режим синхронизации получил название инкрементной передани зоны. Использование режима инкрементной передачи зоны позволяет снизить сетевой трафик вызванной репликацией между DNS серверами, поскольку в большинстве случаев изменения сводятся к добавлению или удалению из базы данных зоны одной-двух записей. В этой ситуации нет смысла передавать всю зону.

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

Переход от WINS к DNS

В Windows Server 2003 система доменных имен (DNS) рассматривается как основной способ именования ресурсов. Служба WINS используется исключительно по соображениям сохранения совместимости. Со временем администратор может реализовать полный переход от WINS к DNS, оставив в сети только одну службу имен. Процесс удаления из сети функционирующего WINS-сервера называется отзывом (decommissioning).

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

1. В пространстве имен оснастки WINS выберите WINS-сервер для отзыва. После этого перейдите к контейнеру Active Registrations (Активные регистрации).

2. В меню Action (Действие) выполните команду Show records for the selected owner (Найти по владельцу).

3. В открывшемся окне в списке only for selected owner (только для выбранного владельца) укажите WINS-сервер для отзыва и нажмите кнопку ОК.

4. В окне подробного просмотра выделите все элементы.

5. В меню Action (Действие) выберите команду Delete (Удалить).

6. В диалоговом окне Confirm WINS Record Delete (Подтверждение удаления записей) установите переключатель Tombstone WINS records on all WINS servers (Реплицировать удаление записи на другие серверы) и нажмите кнопку ОК.

7. Подтвердите удаление, нажав кнопку Yes (Да) в окне запроса.

8. В дереве выберите элемент Replication Partners (Партнеры репликации).

9. В меню Action (Действие) выполните команду Replicate Now (Запустить репликацию).

10. После проверки репликации выбранных записей на другие серверы остановите и удалите службу WINS на отозванном сервере.

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

Планирование

Перед использованием DNS в сети необходимо тщательно спланировать пространство имен DNS. При этом нужно определить, как будет применяться служба DNS и какие цели должны быть достигнуты в ходе ее развертывания. Вот вопросы, которые необходимо решить до установки службы.

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

 В какой сети будут установлены серверы DNS — в частной сети или в Интернете.

 Нужно ли использовать DNS для поддержки работы Active Directory?

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

Понятие области действия

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

Приступая к настройке службы DHCP, администратор должен создать отдельную область действия для каждой физической подсети. Если в сети имеется несколько DHCP-серверов, необходимо распределить имеющиеся диапазоны адресов между ними. Как правило, для каждой подсети должно быть как минимум два DHCP-сервера, способных выдать необходимый IP-адрес. Для этого имеющиеся диапазоны адресов делятся между двумя DHCP-серверами в некотором соотношении. При этом рекомендуется следующая схема. Для каждой подсети на ближайшем DHCP-сервере размещается 80 процентов имеющихся адресов. Остальные 20 процентов размещаются на одном из оставшихся DHCP-серверов. Этот сервер возьмет на себя обязанности по выдаче адресов для рассматриваемой подсети, если основной сервер выйдет из строя. Применение подобной схемы позволяет гарантировать, что ни один запрос клиента не останется без ответа.

Понятие опций

На уровне областей действия происходит управление процессом выдачи IP-адресов. Для решения задачи однообразного конфигурирования клиентов DHCP-сервер использует механизм опций (options). Опции позволяют предоставить DHCP-клиентам различную информацию о настройках компонентов стека протоколов TCP/IP. Каждая опция идентифицируется посредством уникального 8-разрядного кода, определяющего назначение опции. В спецификации DHCP определено несколько десятков разнообразных опций, в дополнение к которым корпорация Microsoft предложила несколько собственных.

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

Отдельно стоит сказать о возможности объединения DHCP-клиентов в специальные классы. Класс рассматривается в данном случае, как некая логическая группа компьютеров, объединенных по некоторому признаку. Например, в один класс можно объединить компьютеры, имеющие доступ к Интернету. Сетевые компоненты этих компьютеров могут требовать расширенной настройки. Чтобы отнести хост к некоторому классу, администратор должен использовать утилиту командной строки Ipconfig с ключом  /setclassid.

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

Посредник WINS

В спецификации службы WINS описываются три участника: WINS-сервер, WINS-клиенты, а также посредники WINS (WINS proxy). WINS-сервер обрабатывает запросы на регистрацию имен от WINS-клиентов, регистрирует их имена и соответствующие им IP-адреса, а также отвечает на запросы разрешения имен от клиентов, возвращая IP-адрес по имени, при условии, что это имя находится в базе данных сервера. В сети может быть установлено несколько WINS-серверов. Базы данных всех существующих WINS-серверов синхронизируются в результате процесса репликации (рис. 13.22).

Под посредником WINS понимается специальный WINS-клиент, который может обращаться к WINS-серверу от имени других хостов, не способных обратиться к WINS-серверу самостоятельно (рис. 13.23). WINS-посредники используются для поддержки хостов, осуществляющих разрешение NetBIOS- имен методом широковещательных рассылок. Аналогичным методом (путем рассылки широковещательных сообщений) данный тип хостов информирует другие сетевые хосты о занимаемом им NetBIOS-имени. При этом принято говорить, что данный хост работает в режиме b-узла. Поскольку широковещательные сообщения не ретранслируются маршрутизаторами, для нормальной работы сети возникает необходимость устанавливать WINS-серверы в каждой подсети (либо отказаться от клиентов, работающих в режиме b-узла). В качестве альтернативы администратор может сконфигурировать один из WINS-клиентов в качестве WINS-посредника.

Рис. 13.22. WINS-серверы

Рис. 13.23. Пример использования WINS-посредника

Хост, функционирующий в режиме b-узла, не подозревает о существовании WINS-посредника. Этот хост рассылает широковещательные запросы, которые принимаются всеми хостами подсети, в том числе и WINS-посредником. WINS-посредник переадресует эти сообщения WINS-серверу, информируя последний о регистрации или освобождении соответствующего имени. Аналогичным образом хост, функционирующий в режиме b-узла, обращается с широковещательным запросом на разрешение имени. Посредник WINS проверяет собственный локальный кэш имен, и если в нем не обнаружено запрашиваемое имя, переадресует запрос WINS-серверу (см. рис. 13.23).

Пространство имен DNS

Основным компонентом пространства имен DNS являются домены (domain). Домен рассматривается как группа сетевых хостов, объединенных по некоторому логическому признаку. Домены соединяются друг с другом при помощи отношений "родитель-потомок", образуя тем самым некоторую иерархию. Положение домена в этой иерархии определяет уровень домена.

В основании иерархического пространства имен DNS лежит домен, который называется корневым доменом (root domain) (рис. 13.1). Корневой домен является формальным элементом, символизирующим иерархичность пространства доменных имен, выступая в качестве родительского контейнера для всех доменов первого уровня.

Если домены выступают в роли контейнеров или узлов рассматриваемой иерархической структуры, то в качестве листьев выступают сведения о ресурсах этих доменов. Служба DNS определена в рамках стека протоколов TCP/IP, в котором для обозначения любого объекта сети используется понятие хост (host).

Рис. 13.1. Пространство имен DNS

Любой объект пространства имен DNS, будь это домен или хост, имеет имя, уникальное в пределах родительского контейнера. Это имя может быть образовано из символов латинского алфавита, цифр и знака тире ("—"). Некоторые версии DNS (включая реализацию DNS в Windows Server 2003) допускают использование в именах объектов символа подчеркивания ("_"), а также символов в формате UTF-8.

Хотелось бы отметить, что непосредственно к имени хоста в пространстве имен DNS не предъявляется требования уникальности в рамках всего пространства имен. Требуется, чтобы это имя было уникально только в рамках родительского контейнера.

Однако непосредственно имена объектов редко используются для их идентификации. Точно идентифицировать объект можно только при помощи его полного доменного имени (Fully Qualified Domain Name, FQDN). Полное доменное имя объекта образуется из имени объекта и суффикса DNS. Суффикс DNS представляет собой перечисление имен всех контейнеров (фактически доменов), находящихся между объектом и корнем пространства имен.

Единственным объектом пространства имен DNS, не имеющим имени, является корневой домен. Для ссылки на него используют точку ("."). В записи полного доменного имени завершающая точка, обозначающая корневой домен, обычно опускается.

В табл. 13.1 перечислены все элементы, образующие пространство имен DNS.

Таблица 13.1.Элементы пространства имен DNS

Элемент пространства имен	Описание	Пример
Корневой домен	Корень — самый высокий уровень доменной иерархии; домен без имени. При использовании в полном доменном имени указывается точкой в конце	Точка (.) или точка, стоящая в конце имени, например, "sample.mydomain.org."
Домен первого уровня (Тор-Level Domain, TLD)	Имя, состоящее из двух или трех символов, обычно указывающее страну (Россия — ш, Нидерланды — nl, Украина — иа и т. п.) или тип организации, использующей имя (com — коммерческая, mil — военная и т. д.)	Суффикс ".com" означает, что имя зарегистрировано фирмой или другой организацией для коммерческого использования в Интернете
Домен второго уровня (Second-Level Domain, SLD)	Имя произвольной (ограниченной) длины, зарегистрированное частным лицом или организацией для использования в Интернете. Такие имена всегда основаны на домене верхнего уровня, в зависимости от типа организации или географического местоположения	"mydomain.org." или просто "mydomain.org"— имя домена второго уровня (вымышленное)
Дочерние домены	Дополнительные домены, которые организация может создавать в пределах домена второго уровня. Применяются для отражения структурной иерархии различных подразделений больших организаций	"sample.mydomain.org." — дочерний домен домена второго уровня "mydomain. org."
Имя хоста или ресурса	Листья дерева имен DNS, задают определенный ресурс или хост	"host.sample.mydomain.org.", где host — имя хоста или какого-либо ресурса в сети

Проверка работоспособности DNS-сервера

По окончании процесса установки службы DNS необходимо проверить работоспособность сервера. Следует убедиться в том, что DNS-сервер поддерживает нужные зоны прямого и обратного просмотра, а также в том, что зоны могут динамически обновляться.

Развертывание DNS

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

 планирование;

 установка программного обеспечения DNS-сервера;

 настройка DNS;

 мониторинг и оптимизация.

Репликация WINS

Если в сети используется несколько WINS-серверов, для поддержания их баз данных в синхронизированном состоянии администратор может настроить между ними репликацию. Рис. 13.24 иллюстрирует ситуацию, когда репликация настроена между двумя WINS-серверами. В показанном на рисунке примере репликация осуществляется в обе стороны. То есть содержимое базы данных одного WINS-сервера реплицируется на другой WINS-сервер и наоборот. Однако возможны и другие варианты: как однонаправленная репликация, так и сложные топологии репликации (например, образующие кольцо). После настройки механизма репликации между WINS-серверами каждый из них будет располагать сведениями обо всех именах NetBIOS, зарегистрированных в корпоративной сети. Благодаря этому любой клиент будет иметь возможность разрешать NetBIOS-имена независимо от того, на каком из WINS-серверов эти имена были зарегистрированы.

Рис. 13.24. Репликация между WINS-серверами

Участвующие в репликации WINS-серверы называются партнерами по репликации. В зависимости от того, как именно WINS-сервер инициирует процедуру репликации, он может выступать в одном из трех качеств:

 передающий партнер (Push Partner). В этом сценарии WINS-сервер инициирует процесс репликации самостоятельно, извещая своих партнеров об изменении своей базы данных путем отправки специального сообщения;

 принимающий партнер (Pull Partner). В этом случае WINS-сервер запрашивает репликацию изменений у своего партнера по репликации с определенной периодичностью.

 передающий/принимающий партнер (Push/Pull Partner). Этот сценарий предполагает использование обоих вышеописанных методов инициации процесса репликации.

Ресурсные записи

Зона рассматривается как база данных, содержащая сведения об элементах пространства имен DNS. База данных состоит из записей, которые, согласно терминологии DNS, называются ресурсными записями (resource records). Каждая ресурсная запись имеет следующий синтаксис:  owner TTL class type RDATA

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

Таблица 13.2. Поля ресурсной записи

Имя поля		Описание
owner		Имя хоста или домена, к которому принадлежит ресурсная запись
TTL		32-разрядное число, определяющее интервал времени, в течение которого данная запись будет храниться в кэше DNS-сервера или DNS-клиента, до тех пор пока не будет удалена. Данное поле является необязательным. Если поле не определено, используется значение, определенное на уровне зоны (в записи SOA)
class		Определяет класс ресурсной записи. В настоящее время в данном поле всегда указывается IN
type		Указывает тип ресурсной записи. Существующие типы будут перечислены далее
RDATA		Данные ресурсной записи. Конкретное значение данного поля определяется типом ресурсной записи

Существует порядка двадцати типов ресурсных записей. Отдельного разговора заслуживает запись типа SOA (Start of Authority). Каждая зона имеет одну запись этого типа. Запись формируется непосредственно в момент создания зоны и определяет все ее параметры, в том числе и те, что регламентируют процесс распространения произведенных изменений между всеми ее носителями. Рассмотрим эти параметры.

Одним из важнейших параметров является номер версии (serial number) зоны. Номер версии позволят обнаружить факт изменения содержимого зоны. Дополнительные носители зоны периодически сверяют номер версии собственной копии с номером версии зоны основного носителя. Поэтому от номера версии требуется, чтобы он последовательно увеличивался с каждым изменением. Критическим является тот факт, что значение номера версии после изменения больше, чем до изменения. Величина разброса между номерами версии не имеет никакого значения.

Ниже приводится пример записи SOA для домена ayan. ru:

ayan.ru. IN SOA root.ayan.ru. administrator.ayan.ru.(

2002082000 ; номер версии

86400 ; интервал обновления (1 день)

86400 ; интервал повторения (1 день)

604800 ; истечение срока действия (7 дней)

86400 ); время жизни записей (1 день)

В этом примере запись SOA начинается с имени определяемого домена — ayan.ru. Доменное имя после ключевого слова SOA определяет основной сервер имен для данного домена root.ayan.ru. Следующее доменное имя (administrator.ayan.ru) определяет адрес электронной почты человека, отвечающего за администрирование зоны. В случае возникновения ошибок в работе DNS-сервера и процессе разрешения имен будет отправлено соответствующее сообщение по указанному адресу. Обратите внимание, что при записи адреса электронной почты не используется символ "@".

Обратите внимание на точку, которой оканчивается каждое доменное имя. Эта точка обозначает корневой домен пространства имен DNS. В данном случае использование этой точки обязательно.

Серверы DHCP, DNS и WINS

Службы DNS и DHCP являются ключевыми сетевыми службами в любой корпоративной сети, построенной на базе стека протоколов TCP/IP. Более того, в среде Windows Server 2003 наличие службы DNS является одним из обязательных условий развертывания службы каталога Active Directory. Служба DNS осуществляет разрешение символических доменных имен в соответствующие им IP-адреса. Удобным дополнением к службе DNS в среде Windows Server 2003 является служба DHCP, упрощающая процесс конфигурации сетевых хостов (в том числе выделение хосту IP-адреса). Кроме того, в среде Windows многими администраторами традиционно используется служба WINS, осуществляющая разрешение символических NetBIOS-имен в соответствующие IP-адреса. Хотя роль этой службы в Windows Server 2003 была значительно уменьшена за счет реализации механизма динамической регистрации доменных имен, служба WINS может по-прежнему использоваться для организации процесса разрешения имен (например, в процессе перехода с Windows NT на Windows Server 2003).

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

Схемы запросов

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

Всю работу по разрешению доменного имени выполняет DNS-сервер. В зависимости от обстоятельств, в процесс разрешения имени может быть вовлечен один сервер или несколько DNS-серверов.

Изначально для разрешения доменных имен использовался специальный текстовый файл, в котором перечислялись IP-адреса и соответствующие им имена компьютеров. Этот файл, получивший название HOSTS (хосты), помещается на сервере. Каждый клиент копировал этот файл и использовал его для разрешения имен. При необходимости разрешения имени клиент просматривает файл HOSTS с целью обнаружения интересующего имени. Подобная схема разрешения имен подходит для небольших статичных сетей. В большой динамичной сети поддержание файла HOSTS в актуальном состоянии на всех клиентах представляет собой трудно решаемую проблему. Служба DNS явилась альтернативой механизму разрешения имен посредством файла HOSTS.

Информация об объектах пространства имен DNS может быть распределена между множеством DNS-серверов. В этом случае DNS-серверы образуют иерархию, подобную иерархии пространства имен (рис. 13.2). В самом простом случае иерархия DNS-серверов может полностью повторять иерархию доменных имен. Каждый DNS-сервер хранит информацию только о части общего пространства имен. Это значит, что сервер самостоятельно способен разрешить только некоторую часть доменных имен. Если сервер не способен разрешить доменное имя самостоятельно, он передает этот запрос дальше, вверх по иерархии.

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

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



Рис. 13.2. Иерархия DNS-серверов

Существует две схемы запросов, которые могут использоваться для разрешения доменного имени: рекурсивные и итерационные (итеративные) запросы. Рассмотрим каждую из схем в отдельности.

В ответ на рекурсивный запрос (recursive query) клиента DNS-сервер должен возвратить либо IP-адрес, соответствующий запрашиваемому доменному имени, либо сообщение об ошибке, если это имя не может быть разрешено. В процессе разрешения запроса DNS-сервер рекурсивно предпринимает попытки обнаружить так называемые "ближайшие" серверы ("closest known" name servers). "Ближайшим" считается сервер, являющийся носителем зоны, в которой размещается домен, близкий к запрашиваемому. При этом поиск начинается от корневого сервера имен. Корневой сервер имен предоставляет ссылку на другой сервер имен, который, по его мнению, должен располагать сведениями о запрашиваемом хосте (или домене). Тот, в свою очередь, может предоставить ссылку на другой сервер имен и т. д. В конечном итоге будет найден сервер имен, располагающий сведениями о требуемом доменном имени.

Для пояснения рассмотрим пример (рис. 13.3). Допустим, сервер должен выполнить разрешение доменного имени www.ayan.ru. Первоначально DNS-сервер пытается обнаружить в собственной базе данных сведения о домене ауаn. ru. В случае если сведения о данном домене отсутствуют, DNS-сервер пытается обнаружить серверы имен для данного домена (при этом поиск осуществляется как в собственной базе данных, так и в кэше имен). Если соответствующие серверы имен не могут быть обнаружены, предпринимается аналогичная попытка для домена ru. В определенный момент DNS-сервер обратится к серверам корневого домена. Серверы имен корневого домена не располагают информацией о запрашиваемом домене. Но поскольку запрашиваемый домен располагается внутри домена ru, будет возвращена ссылка на серверы имен домена ru. Обращение к DNS-серверам домена ru даст информацию о серверах имен домена ayan.ru. Обратившись к серверу имен домена ayan.ru, DNS-сервер получит информацию об IP-адресе хоста www.ауаn.ru.





Рис. 13.3. Рекурсивный метод разрешения запросов

В случае получения итерационного запроса (iterative query) DNS-сервер просматривает собственную базу данных и кэш, пытаясь обнаружить в них сведения о запрашиваемом доменном имени. Если доменное имя не может быть разрешено DNS-сервером самостоятельно, клиенту будет возвращена ссылка на вышестоящий DNS-сервер. Клиент должен повторно отправить запрос указанному серверу имен. Тот, в свою очередь, просматривает собственную базу данных и возвращает либо адрес требуемого хоста, либо ссылается на другой сервер имен. На определенном этапе клиент свяжется с сервером имен, который располагает сведениями о запрашиваемом доменном имени. В этом сценарии основная нагрузка по разрешению имени возлагается на DNS-клиента.

Итерационные запросы могут использоваться в ситуации, когда или DNS-сервер, или DNS-клиент не поддерживают рекурсивные запросы (например, администратор может запретить на уровне DNS-сервера применение рекурсивных запросов).

На рис. 13.4 показан пример итерационного разрешения доменного имени. Допустим хост store.khsu.ru должен установить соединение с хостом movies.yahoo.com.



Рис. 13.4.Итерационный метод разрешения запросов

Для разрешения указанного доменного имени клиент предпринимает следующие шаги:

1. Клиент обращается к серверу имен, обслуживающему домен khsu.ru. Этот сервер имен не обладает информацией о запрашиваемом имени и возвращает клиенту ссылку на вышестоящий сервер имен (обслуживающий домен ru).

2. Клиент обращается к серверу имен, обслуживающему домен ru. Этот сервер имен не обладает информацией о запрашиваемом имени и возвращает клиенту ссылку на корневой сервер имен (домен ".").

3. Клиент обращается к корневому серверу имен. Корневой сервер имен обнаруживает, что запрашиваемое доменное имя принадлежит к домену com. Клиенту возвращается ссылка на сервер имен, обслуживающий домен com.

4. Клиент обращается к серверу имен, обслуживающему домен com. Данный сервер имен находит в своей базе данных записи о сервере имен, обслуживающем домен yahoo.com. Ссылка на этот сервер имен возвращается клиенту.

5. Клиент обращается к серверу имен, обслуживающему домен yahoo.com. Сервер имен находит в своей базе данных запись о хосте movies.yahoo.com. Соответствующий этому имени IP-адрес возвращается клиенту.

Служба DHCP

Каждому хосту, подключенному к сети на базе TCP/IP, должен быть назначен уникальный IP-адрес. Протокол DHCP (Dynamic Host Configuration Protocol, протокол динамической конфигурации хоста) был разработан как средство динамического выделения хостам IP-адресов. Протокол DHCP является открытым промышленным стандартом, упрощающим управление сетями на базе TCP/IP. Этот протокол может быть использован для централизованного управления процессом настройки стека протокола TCP/IP на клиентских машинах (речь идет о таких параметрах, как адрес шлюза по умолчанию или адрес DNS-сервера).

В спецификации протокола DHCP определяются два участника: DHCP-сервер и DHCP-клиенты. Служба клиента DHCP запрашивает у DHCP-сервера параметры для настройки стека протоколов TCP/IP. Служба сервера DHCP обрабатывает клиентские запросы, осуществляя выдачу в аренду IP-адреса из некоторого диапазона. Каждый адрес выделяется на определенный срок. По окончании этого срока хост должен либо продлить срок аренды, либо освободить адрес. Все удовлетворенные запросы пользователя фиксируются службой сервера DHCP в собственной базе данных. Подобное решение позволяет предотвратить выделение одного IP-адреса двум хостам. Одновременно с выдачей IP-адреса DHCP-сервер может также предоставить клиенту дополнительную информацию о настройках стека протоколов TCP/IP, такую как маска подсети, адрес шлюза и адреса серверов DNS и WINS.

Кажется совершенно очевидным, что поддержка этого протокола была реализована в операционной системе Windows Server 2003. В составе Windows Server 2003 реализован как DHCP-клиент (который устанавливается по умолчанию), так и DHCP-сервер (который может быть установлен и сконфигурирован администратором при необходимости). Реализованная в Windows 2000 Server поддержка протокола DHCP обладает характеристиками, перечисленными ниже.

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

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

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

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

 Автоматическая настройка клиентов. Служба DHCP-клиента в случае отсутствия в сети DHCP-сервера может выполнить необходимую настройку самостоятельно. Используя для работы временную конфигурацию стека протоколов TCP/IP, клиент продолжает попытки связаться с DHCP-сервером в фоновом режиме каждые 5 минут. При этом автоматическое назначение адреса всегда прозрачно для пользователей. Адреса для такого рода клиентов выбираются из диапазона частных сетевых адресов TCP/IP, которые не используются в Интернете.

 Новые специализированные опции и поддержка классов опций. Администратор может создавать собственные классы DHCP (используемые для конфигурации клиентов) в соответствии с необходимостью. Механизм пользовательских классов позволяет применять DHCP в заказных приложениях для сетей масштаба предприятия. Классы поставщиков (vendor classes) могут использоваться для настройки различных функций сетевого аппаратного обеспечения.



Следует также отметить функциональные возможности, которые были впервые добавлены в реализацию службы DHCP в Windows Server 2003.

 Возможность резервного копирования базы данных DHCP. В базе данных DHCP-сервера хранится информация о выданных клиентам IP-адресах, включая информацию о времени окончания аренды. Регистрация этой информации позволяет избежать повторного выделения уже выданных адресов. Повреждение этой базы данных может привести к тому, что работоспособность сети окажется под угрозой. Администратор может выполнять резервное копирование базы данных DHCP-сервера. Созданная резервная копия может использоваться впоследствии для восстановления работоспособности DHCP-сервера.

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

Служба DNS

Служба доменных имен, Domain Name System, DNS, является одним из важнейших компонентов сетевой инфраструктуры Windows Server 2003. Служба доменных имен осуществляет разрешение, или преобразование, символьных имен в IP-адреса. Клиенты доменов на базе Active Directory используют службу DNS для обнаружения контроллеров домена.

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

Служба WINS

Служба WINS (Windows Internet Name Service) обеспечивает поддержку распределенной базы данных для динамической регистрации и разрешения NetBIOS-имен. Служба WINS отображает пространство имен NetBIOS и адресное пространство IP друг на друга и предназначена для разрешения NetBIOS-имен в маршрутизируемых сетях, использующих NetBIOS поверх TCP/IP. Следует напомнить, что NetBIOS-имена используются ранними версиями операционных систем Windows как основной способ именования сетевых ресурсов. Служба WINS была разработана с целью упрощения процесса управления пространством имен NetBIOS в сетях на базе TCP/IP.

Основное назначение службы WINS заключается в разрешении NetBIOS-имен в IP-адреса. Процесс разрешения строится на основе базы данных WINS-сервера, содержащей отображения пространства NetBIOS-имен на пространство IP-адресов. Входя в сеть, клиент регистрирует свое имя в базе данных WINS-сервера. При завершении работы клиент отправляет сообщение WINS-серверу, извещая его об освобождении им зарегистрированного имени. На рис. 13.21 показан процесс взаимодействия WINS-клиента и WINS-сервера.

Рис. 13.21. Взаимодействие WINS-клиента и WINS-сервера

Реализация службы WINS в Windows Server 2003 характеризуется функциональными возможностями, перечисленными ниже.

 Постоянные соединения. Каждый WINS-сервер может быть настроен на обслуживание постоянного соединения с одним или большим количеством партнеров репликации. Это увеличивает скорость репликации и снижает затраты на открытие и завершение соединений.

 Управление "захороненными" записями. "Захороненными" (tombstoning) называются записи в базе данных WINS, которые были помечены для удаления. Информация о "захороненных" записях реплицируется между WINS-серверами, что позволяет синхронно удалить эти записи из всех копий базы данных WINS. Реализованный механизм управления позволяет администратору вручную удалять произвольные записи из базы данных WINS.

 Улучшенная утилита управления. Для управления WINS-сервером используется специальная утилита WINS, реализованная в виде оснастки ММС.

 Расширенная фильтрация и поиск записей. Улучшенная фильтрация и новые поисковые функции помогают находить записи, показывая только записи, соответствующие заданным критериям. Эти функции особенно полезны для анализа очень больших баз данных WINS.

 Динамическое стирание записей и множественный выбор. Эти особенности упрощают управление базой данных WINS. При помощи оснастки WINS можно легко манипулировать с одной (или более) записью WINS динамического или статического типа.

 Проверка записей и проверка правильности номера версии. Указанный механизм осуществляет проверку последовательности имен, размещенных в базах данных WINS-серверов. Проверка записей сравнивает IP-адреса, возвращаемые по запросу NetBIOS-имени с различных серверов WINS. Механизм проверки правильности номера версии проверяет номер владельца таблицы отображения "адрес-версия".

 Возможность экспорта базы данных WINS. При экспорте содержимое базы данных WINS-сервера сохраняется в текстовом файле с запятыми в качестве разделителей. Можно импортировать этот файл в различных форматах (в том числе и в формате Microsoft Excel).

 Динамическое обновление клиентов. Для возобновления регистрации локальных NetBIOS-имен не требуется перезапускать WINS-клиента. Обновление информации о зарегистрированных именах администратор может использовать утилиту Nbtstat.exe с параметром -гг.

 Консольный доступ только для чтения к оснастке WINS. Эта возможность предоставляется группе WINS Users (Пользователи WINS), которая автоматически создается в момент установки WINS-сервера. Добавляя членов к этой группе, можно предоставить доступ только для чтения к информации о WINS. Это позволяет пользователю, являющемуся членом указанной группы, просматривать (но не изменять!) параметры и содержимое базы данных WINS-сервера.

Создание области действия

Приступим к настройке службы DHCP. Для начала определим необходимые области действия. Запустите оснастку DHCP, которая находится в меню Administrative Tools (Администрирование). В результирующей панели оснастки вызовите контекстное меню объекта, ассоциированного с конфигурируемым DHCP-сервером, и выберите пункт New Scope (Новая область действия). Будет запущен мастер конфигурирования области действия.

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

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

Рис. 13.14. Предоставьте информацию о диапазоне адресов

В следующем окне мастера администратор может определить исключения из только что определенного диапазона. Могут иметься различные причины для этого. Администратор может исключать как отдельные адреса, так и целые диапазоны. Для исключения одиночного IP-адреса необходимо указать его в поле Start IP address (Начальный IP-адрес). Поле End IP address (Конечный IP адрес) необходимо оставить в этом случае пустым. После нажатия кнопки Add (Добавить) введенный адрес будет добавлен в список исключенных из диапазона адресов (рис. 13.15).

Перейдя к следующему окну мастера, необходимо определить для создаваемой области действия время аренды IP-адресов. Время аренды может быть определено на уровне дней, часов и даже минут. Хотя в стандарте протокола DHCP определена возможность аренды адреса на неопределенный срок (бесконечная аренда), реализация службы протокола в Windows Server 2003 не допускает сдачу адреса в бесконечную аренду.

Рис. 13.15. Определение исключений из диапазона адресов

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

Если вы решили воспользоваться помощью мастера в определении опций, вам будет предложено определить несколько наиболее важных опций DHCP.

 Адрес шлюза по умолчанию. Шлюз по умолчанию используется для маршрутизации пакетов, адресованных хостам в других подсетях. Если хост не располагает информацией о шлюзе по умолчанию, он не будет способен взаимодействовать с подобными хостами. В данной опции требуется определить адрес маршрутизатора, который будет осуществлять доставку пакетов хостам в других подсетях (рис. 13.16).

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

 Адреса WINS-серверов. WINS-серверы используются для организации процесса разрешения NetBIOS-имен хостов в IP-адреса этих хостов. Данная опция позволяет снабдить клиента адресами всех действующих в сети WINS-серверов. Так же, как и в случае с DNS-серверами, можно указать адреса нескольких WINS-серверов (рис. 13.18).



Рис. 13.16. Опция, позволяющая определить адреса шлюзов по умолчанию



Рис. 13.17. Опция, позволяющая определить адреса DNS-серверов и DNS-имени домена

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



Рис. 13.18. Опция, позволяющая определить адреса WINS-серверов



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

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

При использовании нескольких областей опции по умолчанию могут быть определены на уровне сервера. В этом случае данные опции будут унаследованы всеми областями. Для этого в контекстном меню контейнера Server Options (Опции сервера) необходимо выбрать пункт Configure Options (Настроить опции) и определить требуемые опции.

Структура DNS

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

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

Суперобласти

В службе DHCP, реализованной в рамках Windows Server 2003, разработчиками была реализована возможность создания суперобластей (superscope). Суперобласть представляет собой административное объединение стандартных областей. Использование суперобластей действия оправдано в ситуации, когда для одной подсети имеется несколько несмежных диапазонов IP-адресов. При этом каждый диапазон реализуется в виде отдельной области действия. Суперобласть действия выступает в качестве средства объединения получившихся областей действия.

Суперобласти используются для реализации в пределах одной физической подсети нескольких логических подсетей. Каждая логическая подсеть создается подмножеством адресов, заданных в рамках некоторой области, являющейся частью суперобласти. Согласно терминологии DHCP, в этом случае принято говорить о мультисетях (multinets).

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

Управление базой данных WINS

После того как в сети установлены WINS-серверы и между ними должным образом настроена репликация, служба WINS требует минимального вмешательства администратора. Тем не менее, существует ряд операций, выполнение которых требует участия администратора:

 сжатие базы;

 резервное копирование базы;

 проверка целостности базы.

Управление клиентами

Для клиентов Windows конфигурация DNS при настройке свойств TCP/IP для каждого компьютера включает следующие задачи:

 установка имени хоста DNS для каждого компьютера или сетевого подключения;

 установка имени родительского домена, которое помещается после имени хоста, чтобы формировать полное (fully qualified) имя домена для каждого клиента;

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

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

Упрощенные зоны

Упрощенная зона (stub zone) представляет собой копию зоны, содержащую только те ресурсные записи, которые необходимы для локализации DNS-серверов, являющихся носителями полной версии зоны. Основное назначение упрощенной зоны — идентификация DNS-серверов, которые способны выполнить разрешение доменных имен, принадлежащих к этой зоне.

Любая упрощенная зона состоит из следующих элементов:

 записи типа SOA, определяющей параметры зоны;

 записей типа NS, указывающих доменные имена DNS-серверов, выступающих носителями полной версии зоны;

 записей типа А, определяющих адреса DNS-серверов.

Упрощенные зоны позволяют облегчить и сократить процесс разрешения доменного имени. Рассмотрим пример. Допустим, на DNS-сервере, обслуживающем домен ayan.ru, содержится упрощенная зона для домена khsu.ru. В этом случае при поступлении запроса на разрешение имени www.khsu.ru DNS-сервер не будет использовать рекурсивный запрос на разрешение этого имени. Вместо этого запрос будет напрямую отправлен некоторому серверу имен домена khsu.ru, адрес которого будет извлечен из упрощенной зоны. Разрешение имени посредством рекурсивных запросов потребовало бы больше шагов, чем в случае использования упрощенной зоны. Следует обратить внимание на то, что в процесс разрешения доменного имени не вовлекаются корневые серверы DNS. Это имеет одно очень важное и полезное следствие.

Упрощенные зоны можно использовать для организации взаимодействия двух лесов доменов, реализующих собственные пространства имен DNS. В этом сценарии в каждом из лесов имеются собственные корневые серверы. Посредством упрощенных зон администратор может создавать ссылки на домены, расположенные в другом пространстве имен DNS.

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

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

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

Для установки сервера DNS нужно воспользоваться процедурами, описанными в разд. "Установка дополнительных сетевых компонентов" главы 12.

Можно также воспользоваться Мастером установки компонентов Windows'. для этого необходимо открыть панель управления, запустить утилиту Add/Remove Programs (Добавить/удалить приложения) и нажать кнопку Add/Remove Windows Component (Добавить/удалить компоненты Windows). В окне мастера (рис. 13.5) следует выбрать компоненты Windows для установки. Администратор может одновременно установить множество компонентов, для этого достаточно установить соответствующие флажки.

Рис. 13.5. Выбор компонентов Windows для установки

Выберите в списке пункт Networking Services (Сетевые службы) и нажмите кнопку Details (Подробнее). В открывшемся окне (рис. 13.6) установите флажок около компонента Domain Name System (DNS). Вернитесь в окно выбора устанавливаемых компонентов и щелкните на кнопке Next (Далее), чтобы приступить к установке. В процессе установки потребуется доступ к дистрибутивным файлам Windows Server 2003.

По окончании работы мастера служба DNS будет установлена на выбранный компьютер. Требуемые файлы будут скопированы на жесткий диск, программное обеспечение сервера можно использовать после перезапуска системы. В группе программ Administrative Tools (Средства администрирования) появится новый инструмент: оснастка DNS. Однако мастер производит установку на сервер только системных файлов. Чтобы служба DNS-сервера начала выполнять свои функции, необходимо должным образом ее сконфигурировать.

Рис. 13.6. Выбор сетевых компонентов для установки

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

Установка дополнительных DNS-серверов

Установка дополнительных DNS-серверов позволяет повысить надежность корпоративной сети и гарантировать разрешение пользовательских запросов даже в том случае, когда один из DNS-серверов выйдет из строя. Если вы устанавливаете DNS-сервер на контроллере домена, вы можете использовать его в качестве носителя зон, интегрированных в Active Directory. В противном случае сервер может использоваться в качестве дополнительного носителя.

Отдельно следует сказать о конфигурировании DNS-серверов в качестве носителя зон, интегрированных в Active Directory. Для размещения содержимого зоны по умолчанию используется раздел приложений. Реплики раздела приложений создаются администратором на контроллере домена вручную при помощи утилиты Ntdsutil.exe.

Установка и настройка DHCP-сервера

Для установки службы DHCP-сервера необходимо воспользоваться процедурами, описанными в разд. "Установка дополнительных сетевых компонентов" главы 12. После установки сервера в меню Administrative Tools (Администрирование) будет добавлен новый инструмент: оснастка DHCP. Эта утилита используется для настройки DHCP-сервера. Непосредственно после установки службы DHCP-сервера необходимо запустить ее при помощи оснастки Services (Службы). В случае если DHCP-сервер подключен к нескольким сетям, необходимо отключить привязку службы к тем подключениям, которым не требуется поддержка DHCP.

Компьютер, выбранный на роль DHCP-сервера, должен быть сконфигурирован со статическим IP-адресом.

Установка и настройка сервера WINS

Для установки службы WINS-сервера нужно воспользоваться процедурами, описанными в разд. "Установка дополнительных сетевых компонентов" главы 12. После установки службы WINS в меню Administrative Tools (Администрирование) появится новая оснастка WINS, которая предназначена для настройки и конфигурирования WINS-сервера (рис. 13.25).

Рис. 13.25. Окно оснастки WINS

Компьютер, выбранный на роль WINS-сервера, должен быть сконфигурирован со статическим IP-адресом.

Установка первого DNS-сервера

Приступая к развертыванию службы DNS в корпоративной сети, администратор должен принять решение о том, будет ли служба DNS создана до установки Active Directory, либо развертывание обеих этих служб будет проходить одновременно. В первом случае необходимо помнить, что до тех пор, пока не установлена служба каталога, вы сможете использовать только один метод хранения содержимого зоны — в виде текстового файла. Как следствие, часть функциональных возможностей будет недоступна. Поэтому рекомендуется осуществлять развертывание службы DNS и службы каталога Active Directory одновременно.

Если вы устанавливаете DNS-сервер одновременно с созданием первого контроллера домена в корпоративной сети, все операции по настройке DNS зоны будут выполнены мастером установки Active Directory (Active Directory Installation Wizard). Этот мастер будет подробно описан в главе 19 "Проектирование доменов и развертывание Active Directory". Если на момент запуска мастера DNS-сервер уже существует, администратору сначала придется вручную создать зону и произвести ее конфигурирование.

Рассматриваемый мастер автоматически создает в пространстве имен DNS все дочерние домены, потребность в которых возникает при создании доменов Active Directory. Однако перед созданием в лесу доменов нового дерева доменов администратор должен вручную создать на DNS-сервере соответствующую зону.

Мастер установки Active Directory не создает на DNS-сервере зон обратного просмотра (reverse domain zone). По окончании работы мастера администратору необходимо вручную создать эту зону и сконфигурировать ее. После этого, администратор должен выполнить регистрацию адресов и имен хостов в этой зоне (либо вручную, либо используя на хостах утилиту Ipconfig с ключом /registerdns).

В Windows 2000 при создании корневого домена леса Active Directory на автоматически устанавливаемом и конфигурируемом DNS-сервере создается зона "" корневого домена пространства имен DNS. Таким образом, создается изолированное пространство имен DNS, т. к. все запросы клиентов замыкаются на корневом DNS-сервере. Другими словами, клиенты не могут, используя этот DNS-сервер, разрешить запросы ко внешним пространствам имен (например, к Интернету).

В Windows Server 2003 зона корневого домена "." автоматически не создается. Таким образом, все запросы к Интернету могут разрешаться через корневые серверы, указанные на вкладке Root Hints (Корневые ссылки) в окне свойств DNS-сервера. Более того, администратор всегда может сконфигурировать первый установленный DNS-сервер для перенаправления запросов к внешнему пространству имен. Информация о вышестоящих серверах указывается на вкладке Forwarders (Перенаправление) окна свойств DNS-сервера. Например, администратор может указать на этой вкладке информацию о DNS-сервере Интернета (рис. 13.8). Позднее мы еще вернемся к рассмотрению этого вопроса.

В ходе создания корневого домена леса мастер установки Active Directory создает на DNS-сервере две зоны: зона для корневого домена леса и зона _msdcs. <имя_DNS_леса>. Обе создаваемые зоны по умолчанию являются интегрированными в Active Directory. Первая зона размещается в разделе приложений DomainDnsZones.<имя_DNS_леса>, а вторая в разделе приложении ForestDnszones.<HMH_DNS_лeca>. Таким образом, информация о первой зоне может реплицироваться на все DNS-серверы в домене, в то время как информация о второй зоне может реплицироваться на все DNS-серверы в лесе. Для примера на рис. 13.9 показано содержимое DNS-сервера после создания корневого домена леса khsu.ru.



Рис. 13.8. Конфигурирование механизма перенаправления запросов



Рис. 13.9. Две зоны создаются на DNS-сервере в процессе создания корневого леса доменов

Установка режима динамического обновления

Режим динамической регистрации устанавливается посредством параметра Allow dynamic updates (Разрешить динамическое обновление) вкладки General (Общие) окна свойств зоны. Чтобы разрешить динамическое обновление, установите значение этого параметра в Yes. Для активизации режима безопасного обновления необходимо установить значение в Only secure updates (Только безопасное обновление).

Возможности DNS-клиентов

В составе Windows Server 2003 имеется служба DNS-клиента. DNS-клиент осуществляет взаимодействие с DNS-сервером с целью разрешения доменных имен в IP-адреса. При этом реализация DNS-клиента в Windows Server 2003 характеризуется следующими возможностями:

 клиентское кэширование. Ресурсные записи (RR), полученные как ответы на запросы, добавляются в клиентский кэш. Эта информация хранится в течение заданного времени и может использоваться для ответа на последующие запросы;

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

 блокировка неотвечающих серверов DNS. Клиентская служба DNS использует список поиска серверов, упорядоченных по предпочтению. Этот список включает все серверы DNS, настроенные для каждого из активных сетевых подключений в системе. Система способна перестраивать этот список, основываясь на следующих критериях: предпочтительные серверы DNS имеют высший приоритет, а остальные серверы DNS чередуются. Неотвечающие серверы временно удаляются из списка.

и Windows Server 2003 обладает

Служба DNS в Windows 2000 Server и Windows Server 2003 обладает общими функциональными возможностями, перечисленными ниже.

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

 Способность взаимодействия с другими реализациями DNS-серверов. Поскольку служба DNS построена на основе существующих стандартов, она успешно взаимодействует совместно с большинством других реализаций DNS, например, использующих программное обеспечение Berkeley Internet Name Domain (BIND).

 Поддержка Active Directory. Как уже упоминаюсь ранее, служба DNS является обязательным условием развертывания Active Directory. Служба DNS используется как основной механизм обнаружения ресурсов в Active Directory-доменах. В свою очередь, DNS-серверы могут использовать каталог Active Directory для размещения баз данных зон. При этом процесс репликации зон осуществляется непосредственно средствами Active Directory.

 Интеграция с другими сетевыми службами Microsoft. Служба DNS обеспечивает интеграцию с другими службами Windows и содержит функции, не описанные в RFC. Это касается интеграции со службами WINS и DHCP.

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

 Поддержка протокола динамического обновления в соответствии с RFC. Служба DNS позволяет клиентам динамически обновлять ресурсные записи при помощи динамического протокола обновления DNS (стандарт RFC 2136). Это облегчает администрирование DNS, избавляя от необходимости вносить эти записи вручную. Компьютеры под управлением Windows 2000, Windows XP и Windows Server 2003 могут динамически регистрировать свои доменные имена.



  Поддержка инкрементных передач зоны между серверами. Передача зоны осуществляется между DNS-серверами в качестве средства синхронизации отдельных экземпляров базы данных зоны. Стандартная процедура передачи зоны предполагает копирование всей базы данных зоны с одного сервера на другой. Инкрементная передача зоны позволяет копировать только сведения об изменениях.

 Поддержка новых типов ресурсных записей. Служба DNS обеспечивает поддержку нескольких новых типов ресурсных записей (RR): записи SRV (расположение службы) и АТМА (адрес ATM), что значительно расширяет возможности использования DNS в глобальных сетях.

Кроме того, реализация службы DNS в Windows Server 2003 имеет несколько новых функциональных возможностей, отличающих ее от реализации в предыдущих версиях Windows (в частности Windows 2000).

 Выборочное перенаправление запросов (Conditional forwarding). Данный механизм позволяет осуществлять перенаправление запросов клиентов на различные DNS-серверы, основываясь на информации о доменном имени, содержащемся в запросе. Механизм выборочного перенаправления может быть использован как средство организации взаимодействия двух лесов доменов, реализующих собственные пространства имен DNS.

 Упрощенные зоны (Stub Zones). Упрощенная зона представляет собой фрагмент зоны, содержащий только те ресурсные записи, что необходимы для нахождения DNS-серверов, являющихся носителями полной версии зоны. Основное назначение упрощенной зоны — идентификация DNS-серверов, которые способны выполнить разрешение доменных имен, принадлежащих к этой зоне.

 Новые способы хранения базы данных зоны в каталоге Active Directory. В случае, когда DNS-сервер установлен на контроллере домена, для размещения содержимого зоны могут использоваться специальные разделы при/южений (application partitions). При этом указанные разделы приложений могут размещаться только на тех контроллерах домена, которые являются DNS-серверами.

 Улучшенные механизмы обеспечения безопасности службы DNS. Система доменных имен (DNS) разрабатывалась как открытый протокол, что делает ее достаточно чувствительной к разнообразным атакам. В связи с этим в Windows Server 2003 разработчиками в реализацию службы DNS был добавлен целый ряд функциональных возможностей, направленных на защиту этой службы от различных атак (в том числе и от атак типа "отказ в обслуживании" — Denial of Services, DoS).



  Расширенные возможности протоколирования событий, связанных с функционированием DNS-сервера. В Windows Server 2003 администратор может получить в свое распоряжение более подробную аналитическую информацию о функционировании DNS-сервера. Эти сведения позволят ему, с одной стороны, получить информацию о режиме работы сервера, а с другой стороны, выявить причины неполадок в случае их возникновения.

 Поддержка протокола DNSSEC (DNS Security Extensions). Протокол DNSSEC определен в стандарте RFC 2535. Реализованная в Windows Server 2003 поддержка этого протокола позволяет DNS-серверам выступать в качестве дополнительных носителей DNSSEC-совместимых защищенных зон. Поддерживаются ресурсные записи типа KEY, SIG и NXT. Поддержка подписанных зон или ресурсных записей в Windows Server 2003 не реализована.

 Поддержка механизма EDNSO (Extension Mechanisms for DNS). Механизм  EDNSO позволяет использовать UDP-пакеты размером больше 512 октетов.

 Управление процессом автоматической регистрации серверов имен в базе данных зоны. В Windows Server 2003 администратор может запретить автоматическую регистрацию серверов имен (что фактически равносильно запрещению автоматического создания ресурсных записей NS-типа) в базе данных зоны.

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

Выборочное перенаправление запросов

Механизм выборочного перенаправления запросов (conditional forwarding) позволяет осуществлять перенаправление пользовательских запросов на другие DNS-серверы, основываясь на информации о доменном имени, включенном в запрос. Обычный режим перенаправления (forwarding) предполагает перенаправление всех запросов на определенный DNS-сервер или группу серверов. Фактически механизм выборочного перенаправления позволяет выполнять на DNS-сервере сортировку запросов. Некоторую часть запросов сервер способен разрешить сам, другая часть будет перенаправлена различным серверам имен.

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

Поскольку механизм выборочного перенаправления способен решать те же задачи, что и упрощенные зоны, очень трудно увидеть различия между ними. Какой из двух механизмов выбрать в той или иной ситуации? Механизм выборочного перенаправления позволяет перенаправить запросы пользователей по разрешению определенного доменного имени на конкретный DNS-сервер. Использование же упрощенных зон для разрешения определенного доменного имени дает ссылку на некоторый набор DNS-серверов, способных выполнить это разрешение. Поэтому, если администратору необходимо контролировать процесс обращения пользователей к корпоративным DNS-серверам (например, с целью управления нагрузкой на серверы или для сокращения нагрузки на линии связи с ограниченной пропускной способностью), он должен использовать механизм выборочного перенаправления.

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

Зоны

Деление доменного пространства имен между DNS-серверами осуществляется посредством механизма зон (zone). Зона представляет собой базу данных, в которой содержатся записи о соответствии некоторого множества доменных имен IP-адресам. Каждая зона представляет собой фрагмент доменного пространства имен. Следует рассматривать зоны как основной административный элемент, на уровне которого происходит как управление пространством имен в целом, так и управление процессом разрешения имен. Зоны, используемые для размещения содержимого обратных доменов, называются зонами обратного просмотра (reverse lookup zone).

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

Зону можно разместить на нескольких серверах. На каждом из вовлеченных DNS-серверов размещается отдельная копия зоны. Для поддержания этих копий в согласованном состоянии используется модель репликации с одним основным участником (single-master replication). Один из DNS-серверов выступает в качестве основного носителя зоны (primary zone). Только основной носитель зоны обладает возможностью вносить изменения в ее содержимое (другими словами, имеет право на запись).

Остальные DNS-серверы располагают копией зоны, доступной только для чтения. Эти серверы называются дополнительными носителями зоны (secondary zone). Изменения, произведенные в копии зоны основным носителем, реплицируются на дополнительные носители. Использование нескольких носителей зоны позволяет, с одной стороны, распределить нагрузку между несколькими серверами, а с другой стороны, реализовать некоторый уровень отказоустойчивости. В случае выхода из строя одного из носителей зоны разрешение имен будет осуществляться остальными носителями зоны.

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

Блокировка учетной записи

Архитектура системы безопасности предусматривает возможность блокирования учетной записи удаленного пользователя (account lockout). Эта возможность отменяет разрешение удаленного доступа для учетной записи пользователя после заданного числа неудавшихся попыток проверки подлинности. Путем конфигурирования механизма блокирования учетной записи администратор влияет на стойкость системы безопасности сервера удаленного доступа. Злоумышленники могут пытаться получить доступ к корпоративной сети путем подбора паролей в течение процесса аутентификации удаленного соединения. Подобные атаки, получившие название "словарных" (по причине использования специального словаря), предполагают отправку сотни, даже тысячи пар "имя-пароль" по списку, основанному на общих словах, именах или фразах.

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

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

 частоту обнуления счетчика неудавшихся попыток (нужно периодически сбрасывать счетчик неудавшихся попыток, чтобы предотвратить длительную блокировку учетной записи из-за ошибок пользователя при наборе пароля).

Чтобы разрешить возможность блокировки учетной записи, нужно изменить параметры в системном реестре Windows Server 2003.

Помните, что некорректное изменение системного реестра может привести к нарушению работоспособности системы. Поэтому перед изменением системного реестра необходимо сделать его резервную копию.

В случае сервера удаленного доступа настройка механизма блокировки учетных записей осуществляется посредством изменения значений параметров реестра, расположенных в ветви реестра HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout.

В этой ветви располагаются два параметра.

  Параметр MaxDeniais. Этот параметр определяет разрешенное количество неудачных попыток аутентификации. Для активизации механизма блокирования необходимо установить значение параметра MaxDeniais больше или равным 1. По умолчанию значение параметра MaxDeniais равно О, что означает запрет на блокировку учетной записи.

 Параметр ResetTime (mins). Данный параметр задает период времени (в минутах), по истечении которого сбрасывается счетчик неудачных попыток аутентификации. По умолчанию для параметра ResetTime (mins) установлено значение ОхЬ40 (2880 минут или 48 часов).

Описанные параметры создаются в реестре только после того, как администратор выполнил конфигурирование службы маршрутизации и удаленного доступа (Routing and Remote Access Service) в качестве сервера удаленного доступа.

Описанный выше способ конфигурирования режима блокирования учетных записей предполагает, что для аутентификации пользователей используется стандартная схема аутентификации. Если для аутентификации используется служба IAS и протокол RADIUS, настройка механизма блокировки учетных записей должна осуществляться при помощи групповых политик.

Диспетчер службы факсов

В составе службы факсов Windows Server 2003 поставляется специальная утилита Fax Service Manager (Диспетчер службы факсов) (рис. 14.26). Эта утилита предназначена для централизованного управления серверами, на которых установлены службы факсов. Администратор может использовать данную утилиту для следующих целей:

 управление службой факса;

 конфигурирование факс-модемов и управление ими;

 управление входящими и исходящими правилами маршрутизации факсов;

 конфигурирование режима протоколирования событий, связанных с отправкой факсов и функционированием службы факсов;

 управление очередями исходящих и входящих факсов;

Рис. 14.26. Оснастка Fax Service Manager

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

 конфигурирование режима архивирования;

 конфигурирование параметров передачи факсов.

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

В большинстве случаев для обеспечения безопасности удаленного подключения вполне достаточно использовать протоколы аутентификации, поддерживающие шифрованный обмен данными. В исключительных ситуациях, когда удаленному пользователю предоставляется доступ к критически важной информации, администратор может задействовать дополнительные механизмы проверки подлинности удаленного пользователя, предоставляемые Windows Server 2003:

 проверка идентификатора звонящего абонента (Caller ID);

 ответный звонок (Callback).

Групповая конференц-связь по IP

Поставщик услуг групповой конференц-связи IP (IP Multicast Conferencing Service Provider) — расширение для IP, позволяющее осуществлять эффективную групповую связь группы по LAN. При наличии группового IP-протокола пользователи посылают только одну копию данных группе IP-адресов для достижения всех получателей, которые хотят получить данные, с использованием самых коротких деревьев для определения пути. Без использования многоадресного вещания те же самые данные необходимо было бы передавать по сети несколько раз, по одной копии для каждого получателя, или передать широковещательно каждому пользователю в сети, что заняло бы полосу пропускания и время на обработку и передачу данных.

IР-телефония

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

Клиенты IP-телефонии используют телефон, подключенный к адаптеру PSTN, либо существующие аппаратные средства мультимедиа. IP-телефония поддерживает телефонную, звуковую и видеоконференц-связь, голосовую и видеопочту, а также службы видео по требованию (video on-demand). Возможности IP-телефонии могут эффективно использоваться средством Remote Assistance, а также программой Windows Messenger.

Использование базового брандмауэра

В рамках сервера удаленного доступа Windows Server 2003 реализован базовый брандмауэр (basic firewall), представляющий собой механизм динамической фильтрации пакетов. Брандмауэр является одним из механизмов обеспечения безопасности периметра сети, ограничивая трафик через сетевой интерфейс определенными типами пакетов. Администратор может разрешить прохождение через сетевой интерфейс (как правило, тот, что используется для подключения корпоративной сети к внешней сети) пакетов определенного типа, запретив прохождение всех остальных. Новым в Windows Server 2003 является возможность интеграции брандмауэра с механизмом NAT. Администратор может активизировать этот брандмауэр для сетевого интерфейса, используемого механизмом NAT в качестве точки взаимодействия с открытой сетью.

Базовый брандмауэр, реализованный в рамках сервера удаленного доступа Windows. Server 2003, может быть активизирован только для сетевого интерфейса, подключенного к внешней сети (такой, как Интернет).

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

Использование сервера удаленного доступа для обслуживания VPN-подключений

Сервер удаленного доступа под управлением Windows Server 2003 может обслуживать VPN-подключения, выступая в качестве VPN-сервера. Необходимо понимать, что фактически речь идет о все том же удаленном доступе к ресурсам корпоративной сети. Однако, в отличие от обычного удаленного доступа, взаимодействие клиента и сервера осуществляется по защищенному каналу, который реализуется за счет использования специальных протоколов туннелирования. Использование механизма виртуальных частных сетей (VPN) оправдано в ситуации, когда нельзя исключать риск перехвата конфиденциальных данных (например, если взаимодействие с удаленным клиентом реализуется через открытые общественные сети).

Если администратор планирует использовать сервер удаленного доступа для обслуживания VPN-подключений, он должен определить, какой из протоколов туннелирования будет использоваться для создания защищенного канала. Администратор должен выбрать между протоколом РРТР и протоколом L2TP. Протокол РРТР поддерживается всеми клиентами Microsoft (в том числе старыми версиями Windows). Минусом этого протокола является отсутствие механизмов, гарантирующих целостность передаваемых данных и подлинность участников соединения. Протокол L2TP свободен от этих недостатков. В целом он является более предпочтительным вариантом, нежели протокол РРТР. Протокол L2TP базируется на использовании протокола IPSec, поддержка которого реализована в операционных системах Windows 2000/XP и Windows Server 2003. Для использования протокола L2TP на других Windows-платформах (Windows 98/ME и Windows NT 4.0) требуется специальный клиент — Microsoft L2TP/IPSec Client, свободно доступный по адресу http://www.microsoft.com/windows2000/server/  evaluation/news/ bulletins/12tpclient.asp.

Если администратором в качестве средства создания защищенного канала был выбран протокол туннелирования L2TP, он должен определить, как именно будет осуществляться взаимная аутентификация участников VPN-соединения. Протокол IPSec, поверх которого функционирует протокол туннелирования L2TP, поддерживает два способа аутентификации участников соединения: цифровые сертификаты (речь идет о цифровых сертификатах, назначаемых компьютерам) и разделяемый ключ (pre-shared key). С точки зрения безопасности более надежным способом является использование цифровых сертификатов.

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

Использование широковещательных рассылок для разрешения имен

Сервер удаленного доступа под управлением Windows Server 2003 предоставляет возможность удаленным клиентам использовать широковещательные рассылки для разрешения доменных и NetBIOS-имен ресурсов, расположенных в корпоративной сети. Реализации сервера удаленного доступа в предыдущих версиях Windows допускают только один способ разрешения имен для клиентов удаленного доступа — использование серверов имен. В небольших сетях использование широковещательных рассылок избавляет администратора от необходимости развертывания серверов имен.

Широковещательные рассылки поддерживаются сервером удаленного доступа Windows Server 2003 по умолчанию. При этом реализуется следующая схема разрешения имен:

1. Клиент удаленного доступа предпринимает попытку разрешить некоторое имя, отправляя широковещательное сообщение через все имеющиеся сетевые интерфейсы (в том числе и через тот, что используется для соединения с сервером удаленного доступа).

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

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

Следует заметить, что механизм ретрансляции широковещательных запросов, активизированный на сервере удаленного доступа под управлением Windows Server 2003, доступен только клиентам удаленного доступа. Этот механизм позволяет выполнять разрешение имен методом широковещательных рассылок только для ресурсов локальной сети. Этот механизм не может быть использован клиентом, расположенным в локальной сети, для того, чтобы разрешить имя клиента удаленного доступа. Другими словами, механизм работает только в одну сторону.

Использование службы факсов

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

 Передача сообщения на титульном листе. Служба факсов позволяет передавать сообщения на титульном листе факса отдельно от документа. Используя утилиту Fax Cover Page Editor (Редактор титульных страниц факсов), администратор может создать любой титульный лист в соответствии с желаниями пользователя либо выбрать один из имеющихся шаблонов титульных листов. Мастер рассылки факсов автоматически вносит информацию о получателе и отправителе, нужно только ввести примечание и отослать факсимильное сообщение.

 Контроль процесса передачи факсов. Администратор может осуществлять контроль процесса передачи факсов (в том числе отслеживать ошибки) при помощи специальной утилиты Fax Monitor (Монитор факсов). Эта утилита вызывается из оснастки Fax Console (Консоль факсов) путем выбора одноименной команды в меню Tools (Сервис).

 Передача факсов из почтовых программ. Служба факсов работает также с некоторыми версиями Microsoft Exchange или Microsoft Outlook. В Outlook, например, можно передавать сообщения электронной почты и присоединенные документы получателям факсов. Необходимо настроить службу факсов, чтобы она работала с соответствующей учетной записью пользователя в Outlook. Для этого в программе Outlook нужно в настройках профиля пользователя на вкладке Services (Службы) добавить Fax Mail Transport (Почтовый транспорт факсов).

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

Коммуникационные службы

Данная глава посвящена рассмотрению основных коммуникационных служб, реализованных в Windows Server 2003. В первую очередь разговор пойдет о службе маршрутизации и удаленного доступа, позволяющей, в частности. внешним клиентам подключаться к корпоративной сети и использовать ее ресурсы. Здесь же рассматриваются организация виртуальных частных сетей, механизм трансляции сетевых адресов (NAT), а также служба факсов и IP-телефония.

Компоненты механизма трансляции сетевых адресов

Механизм трансляции сетевых адресов включает в себя следующие элементы:

 компонент преобразования. В этом качестве рассматривается компьютер (далее называемый компьютер-преобразователь адресов), выступающий в качестве транслятора сетевых адресов (NAT). Именно транслятор сетевых адресов является тем компонентом, который собственно и выполняет преобразование IP-адресов и номера портов пакетов TCP и датаграмм UDP, передаваемых между локальной сетью и внешней сетью;

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

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

Конфигурирование базового брандмауэра

Как уже упоминалось ранее, в рамках сервера удаленного доступа Windows Server 2003 реализован базовый брандмауэр, задача которого заключается в выполнении фильтрации проходящего через открытый интерфейс трафика. Чтобы активизировать базовый брандмауэр, необходимо на вкладке NAT/ Basic Firewall в окне свойств выбранного сетевого интерфейса (см. рис. 14.13) установить флажок Enable a basic firewall on this interface (Разрешить базовый брандмауэр на этом интерфейсе).

Необходимо помнить о том, что базовый брандмауэр применительно к механизму NAT может быть активизирован только для открытого интерфейса (т. е. интерфейса, подключенного к Интернету).

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

 фильтры входящих пакетов (Inbound Filters);

 фильтры исходящих пакетов (Outbound Filters).

Рис. 14.17. Настройка статического фильтра

Для фильтров каждого типа администратор должен определить действие, которое система будет выполнять для пакетов, отвечающих заданным критериям. На рис. 14.17 показан пример фильтра входящих пакетов. Этот фильтр может:

 отбрасывать пакеты, отвечающие перечисленным критериям. Этому режиму соответствует переключатель Receive all packets except those that meet the criteria below (Получать все пакеты, за исключением тех, которые отвечают указанным критериям);

 пропускать пакеты, отвечающие перечисленным критериям. Этому режиму соответствует переключатель Drop all packets except those that meet the criteria below (Отбрасывать все пакеты, за исключением тех, которые отвечают указанным критериям).

Конфигурирование хостов в локальной сети для работы с NAT

Хосты локальной сети также нуждаются в дополнительном конфигурировании. Каждый хост, который будет использовать механизм NAT, должен иметь соответствующую (согласованную с конфигурацией NAT) настройку стека протоколов TCP/IP:

 IP-адрес, принадлежащий к разрешенному диапазону частных адресов. В рассматриваемом нами примере он должен относиться к сети с идентификатором 192.168.0.0 и маской 255.255.255.0;

 маска подсети (255.255.255.0);

 в качестве шлюза по умолчанию должен быть указан IP-адрес локального сетевого интерфейса компьютера-преобразователя;

 в качестве DNS-сервера должен быть указан IP-адрес локального сетевого интерфейса компьютера-преобразователя;

 в качестве WINS-сервера должен быть указан IP-адрес локального сетевого интерфейса компьютера-преобразователя.

Конфигурирование механизма NAT с помощью программы-мастера

Механизм NAT может быть активизирован на любом компьютере под управлением Windows Sewer 2003. Для этого необходимо соответствующим образом сконфигурировать службу маршрутизации и удаленного доступа (Routing and Remote Access Service).

Как уже было замечено ранее, управление службой маршрутизации и удаленного доступа осуществляется из оснастки Routing and Remote Access. Если эта служба еще не настроена, в панели пространства имен оснастки вызовите контекстное меню объекта, ассоциированного с конфигурируемым сервером, и в нем выберите пункт Configure and Enable Routing and Remote Access (Конфигурировать и разрешить маршрутизацию и удаленный доступ). В окне Configuration (см. рис. 14.6) необходимо выбрать пункт Network address translation (NAT).

В окне NAT Internet Connection мастера Routing and Remote Access Server Setup Wiz.ard (рис. 14.11) администратор должен выбрать соединение, которое будет использоваться механизмом трансляции имен. Предполагается, что это соединение с Интернетом (или другой внешней сетью). Администратор может выбрать одно из существующих соединений, выбрав переключатель Use this public interface to connect to the Internet. В качестве альтернативы администратор может создать соединение по требованию, выбрав пункт Create a new demand-dial interface to the Internet. Соединение по требованию (demand-dial interface) используется, как правило, в случае повременного доступа в Интернет. Соединение устанавливается только в том случае, когда один из пользователей запрашивает доступ к ресурсам Интернета и по окончании работы пользователя разрывается.

При необходимости можно активизировать для выбранного сетевого интерфейса базовый брандмауэр. Для этого необходимо установить флажок Enable security on the selected interface by setting up Basic Firewall.

Мастер выполнит конфигурирование и запуск службы маршрутизации и удаленного доступа. Если для работы механизма NAT был выбран интерфейс соединения по требованию, система запустит мастер создания соединения по требованию.

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

 IP-адрес: 192.168.0.1

 маска подсети: 255.255.255.0

 шлюз по умолчанию — отсутствует



Рис. 14.11. Выбор сетевого интерфейса для работы механизма NAT

В данной конфигурации адрес для сетевого интерфейса в домашней сети выбирается из адресного интервала по умолчанию (задается идентификатором сети 192.168.0.0 и маской 255.255.255.0), который задается для компонента адресации преобразователя адресов. Если этот адресный интервал по умолчанию изменяется, то необходимо изменить и IP-адрес частного интерфейса компьютера-преобразователя адресов, чтобы он имел первый IP-адрес в заданном диапазоне. Использование первого IP-адреса из диапазона — рекомендуемый подход, а не требование для компонента преобразователя адресов.

На следующем этапе необходимо настроить маршрутизацию для выбранного сетевого интерфейса. Администратор должен создать статический маршрут, который будет по умолчанию использоваться данным сетевым интерфейсом. Для статического маршрута по умолчанию получатель — 0.0.0.0, маска подсети — 0.0.0.0. (Мастер конфигурирования создает такой маршрут автоматически.)

Если выбранный сетевой интерфейс не является интерфейсом с набором номера по требованию, в поле Gateway (Шлюз) необходимо также указать IP-адрес. Поскольку в данном случае устанавливается соединение "точка-точка", в этом поле может быть указан любой адрес. Применительно к интерфейсам с набором номера по требованию шлюз не указывается. Вместо этого необходимо установить флажок Use this route to initiate demand-dial connections (Использовать этот маршрут для создания соединения по требованию).

Компонент адресации преобразователя адресов назначает адреса только из одного диапазона, соответствующего одной подсети. Если механизм NAT активизирован для нескольких локальных сетевых интерфейсов, то подразумевается конфигурация с одной подсетью (где все локальные интерфейсы соединены с одной и той же сетью). Если локальные сетевые интерфейсы соответствуют различным сетям, связность между клиентскими компьютерами, которые получают адреса от преобразователя адресов, но находятся в разных сетях, невозможна.

Конфигурирование преобразования специальных портов и служб

Администратор может выполнить более точную настройку механизма NAT, выполнив конфигурирование специальных портов. Фактически администратор задает специфические правила трансляции пакетов, приходящих на определенные порты. Подобное решение позволяет обеспечить прозрачное функционирование корпоративных приложений поверх механизма NAT. Например, администратор может определить порядок трансляции пакетов, приходящих на порт 25 (протокол SMTP).

Расширенная настройка механизма преобразования портов осуществляется на вкладке Services and Ports (Службы и порты) в окне свойств открытого сетевого интерфейса. Администратору предлагается выбор из 13 предопределенных сетевых служб (рис. 14.18). При необходимости администратор может создать новые описания служб.

Для предопределенных служб администратор может определить только частный адрес хоста, на котором запущена указанная служба. Все остальные параметры изменены быть не могут. В процессе создания нового описания службы (правила преобразования), администратору необходимо определить следующие параметры (рис. 14.19):

 действительный адрес, для которого создается правило. По умолчанию предполагается адрес, используемый конфигурируемым интерфейсом. Если для интерфейса сконфигурирован пул адресов, в поле у переключателя On this address pool entry необходимо указать один из адресов этого пула;

 протокол (TCP или UDP) в группе переключателей Protocol;

 номер внешнего порта в поле Incoming port (Входящий порт). Это порт, на который будут приходить пакеты;

Рис. 14.18. Расширенная настройка преобразователя адресов

Рис. 14.19. Создание нового правила преобразования портов

 номер внутреннего порта в поле Outgoing port (Исходящий порт). Это порт, который будет использоваться для преобразования заголовка пакета;

 адрес хоста в корпоративной сети, на который будет выполняться перенаправление всех транслируемых пакетов подобного типа, в поле Private address (Адрес в частной сети).

Конфигурирование службы факсов

При первом запуске оснастки Fax Console (Консоль факсов) вызывается мастер Fax Configuration Wizard (Мастер настройки факсов), с помощью которого вы можете:

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

 выбрать используемый факс-модем и разрешить отправку и/или прием факсов;

 выбрать свои идентификаторы, по которым будут опознаваться передаваемые факсы;

 настроить опции печати и папки для сохранения копий принимаемых факсов.

Мастер настройки факсов можно вызвать в любой момент с помощью команды Tools | Configure Fax (Сервис Настройка факса) из меню оснастки Fax Console (Консоль факсов). Эта оснастка (рис. 14.23) является основным средством управления факсами. Папки принятых и отправленных факсов позволяют легко манипулировать документами, просматривать их и распечатывать.

Рис. 14.23. Оснастка Fax Console

При наборе номера факс использует информацию о способе набора, установленную в группе параметров Phone and Modem Options (Телефон и модем) на панели управления. В мастере отправки факсов Send a Fax есть функция отмены телефонных установок и набора номера телефона в том виде, в каком они введены. Утилита Fax Monitor (Монитор факсов) позволяет просматривать все события, связанные с передачей факсимильных сообщений. Можно установить ручной ответ на звонки, можно также использовать эту утилиту для отмены приема или передачи факсов.

Для подключения к службе факсов с удаленного компьютера используется обычный формат подключения удаленных принтеров: \\<имя_компьютера>\fах. Так же как и принтер, факс может публиковаться в каталоге Active Directory.

Механизм ответного вызова

Механизм ответного вызова (callback) представляет собой альтернативу проверки идентификатора звонящего абонента, позволяя серверу удаленного доступа убедиться в подлинности абонента, устанавливающего соединение. Получив звонок от клиента, сервер разрывает соединение ("вешая трубку") и осуществляет ответный вызов по номеру, определенному звонящим пользователем или заданному администратором. После того как клиент ответит, процесс установки соединения продолжится.

Сервер осуществляет обратный звонок только по окончании процедуры аутентификации и авторизации клиента. Другими словами, ответный звонок производится сервером только после того, как будут установлены подлинность пользователя и его полномочия на удаленное подключение.

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

 No callback (Нет ответного вызова). В данном режиме ответный звонок не производится. Сервер удаленного доступа устанавливает соединение сразу по окончании процедур аутентификации и авторизации.

 Set by caller (Устанавливается вызывающей стороной). Эта функция не повышает защищенность удаленного доступа, она полезна для клиентов, которые звонят из разных мест (регионов, городов, стран) и с разных телефонных номеров, снижая их затраты. Когда запрос на ответный вызов обрабатывается сервером удаленного доступа, происходят следующие события:

 сначала сервер определяет, являются ли имя пользователя и пароль верными;

 в случае успешного окончания процедуры аутентификации, на компьютере пользователя появляется диалоговое окно Callback (Ответный вызов);

 пользователь должен указать в диалоговом окне свой текущий номер телефона для ответного вызова. Этот номер передается серверу;

 запрос на ответный вызов закончен, связь разрывается;

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

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

 Always callback to (Всегда осуществлять ответный вызов по заданному номеру). Этот вариант наиболее приемлем для реализации дополнительного уровня защиты. Необходимо выбрать его и ввести номер телефона, с которым связано оборудование удаленного доступа пользователя. Когда запрос пользователя поступает на сервер удаленного доступа, происходят следующие события:

 сервер выполняет аутентификацию пользователя, запрашивающего удаленное соединение;

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

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

Механизмы управления конфигурацией удаленного подключения

Настройка параметров удаленного доступа для конкретного пользователя в Windows Server 2003 может быть выполнена двумя способами: либо при помощи специальных атрибутов учетной записи пользователя, либо посредством политик удаленного доступа.

Настройка NAT на уже сконфигурированном сервере удаленного доступа

Если в сети уже имеется функционирующий сервер удаленного доступа (другими словами, на этом компьютере имеется сконфигурированная служба маршрутизации и удаленного доступа), администратор может выполнить активизацию механизма NAT без использования специального мастера конфигурирования. Если интерфейс, обеспечивающий подключение к Интернету (например, соединение по требованию), уже имеется, то необходимо выполнить следующую последовательность действий:

1. Если в списке активных протоколов (узел IP Routing) отсутствует объект NAT/Basic Firewall, нужно добавить к списку протокол трансляции сетевых адресов (NAT). Для этого в пространстве имен оснастки Routing and Remote Access следует вызвать контекстное меню объекта IP Routing | General (Маршрутизация IP | Общие) и выбрать в нем пункт New Routing Protocol (Новый протокол маршрутизации) (рис. 14.12). В открывшемся окне необходимо выбрать значение NAT/Basic Firewall и подтвердить свой выбор, нажав кнопку ОК.

2. На следующем этапе требуется выбрать сетевые интерфейсы, которые будут работать с механизмом трансляции сетевых адресов. Вызовите контекстное меню контейнера NAT/Basic Firewall и выберите в нем пункт New Interface (Новый интерфейс). Из списка установленных интерфейсов необходимо выбрать требуемый. В открывшемся окне на вкладке NAT/ Basic Firewall, в зависимости от типа выбранного интерфейса, надо выполнить следующие действия (рис. 14.13):

 для сетевого интерфейса, подключенного к Интернету, необходимо установить переключатель Public interface connected to the Internet (Общий интерфейс, подключенный к Интернету) и установить флажок Enable NAT on this interface (Активизировать NAT для данного интерфейса). Чтобы активизировать механизм динамической фильтрации пакетов, надо установить флажок Enable a basic firewall on this interface (Активизировать базовый брандмауэр для данного интерфейса);

Рис. 14.12. Установка протокола трансляции сетевых имен

Рис. 14.13. Активизация механизма NAT для выбранного сетевого интерфейса

 для сетевого интерфейса, подключенного к локальной сети, необходимо установить переключатель Private interface connected to the private network (Частный интерфейс, подключенный к частной сети).

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

Как уже говорилось, для настройки параметров факса используется Мастер настройки факсов, с помощью которого можно задать как сведения об отправителе, так и параметры работы факсов. Эти параметры можно в любой момент просмотреть и/или изменить с помощью команды Tools | Sender Information (Сервис | Сведения об отправителе), вызываемой из оснастки Fax Console (Консоль факсов), а также с помощью утилиты Fax Service Manager. Параметры окна свойств факса во многом аналогичны параметрам окна свойств обычных принтеров. Исключение составляют параметры, перечисленные на вкладке Tracking (Отслеживание) (рис. 14.27).

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

Рис. 14.27. Вкладка Tracking окна свойств факса

в Windows Server 2003, характеризуется

Служба маршрутизации и удаленного доступа, реализованная в Windows Server 2003, характеризуется новыми функциональными возможностями, перечисляемыми ниже.

 Поддержка механизма разделяемых ключей для аутентификации в случае использования протоколов L2TP/IPSec. Разделяемым ключом (pre-shared key) называется последовательность символов, известная клиенту и серверу удаленного доступа. Этот ключ используется для аутентификации участников соединения удаленного доступа в ситуации, когда применяются защищенные протоколы L2TP/IPSec. Использование механизма разделяемых ключей позволяет администратору отказаться от развертывания инфраструктуры открытых ключей (Public Key Infrastructure, PKI).

 Интеграция механизма трансляции сетевых адресов (NAT) со встроенным брандмауэром. Реализованный в Windows Sewer 2003 встроенный брандмауэр может быть использован для фильтрации пакетов, обрабатываемых транслятором сетевых адресов. Благодаря этому администратор может обеспечить должный уровень безопасности корпоративной сети при организации ее взаимодействия с открытыми сетями (такими, как Интернет).

 Поддержка защищенных соединений, осуществляемых посредством протоколов L2TP/IPSec, механизмом трансляции сетевых адресов (NAT). Windows Server 2003 позволяет использовать механизм трансляции сетевых адресов для организации виртуальных частных сетей. Фактически речь идет о том, что соединение с виртуальной частной сетью может быть создано через интерфейс NAT.

 Поддержка широковещательного метода разрешения имен вместо использования серверов имен. В сети Windows Server 2003 пользователи могут использовать символические имена для ссылки на ресурсы. Однако для установки соединения эти имена должны быть разрешены в соответствующие IP-адреса. Традиционным методом разрешения имен в корпоративной сети является использование специальных серверов имен (таких, как WINS и DNS). Однако в небольших сетях развертывание этих служб может быть неоправданным. Чтобы предоставить удаленным пользователям возможность использования символических имен для ссылки на ресурсы корпоративной сети, администратор может разрешить использование широковещательных рассылок для разрешения этих имен в IP-адреса. В сетях, насчитывающих десятки и сотни удаленных пользователей, использование широковещательных рассылок может привести к падению производительности сети. С другой стороны, если корпоративная сеть реализована в виде нескольких физических подсетей, соединенных маршрутизаторами, использование широковещательных рассылок для разрешения имен может быть неэффективным, поскольку широковещательные сообщения маршрутизаторами не ретранслируются.



Далее следует отметить другие характерные особенности службы удаленного доступа Windows Server 2003, значительно расширяющие возможности администратора.

 Интеграция с Active Directory. Сервер удаленного доступа Windows Server 2003, являющийся частью домена Windows и зарегистрированный в каталоге, может обращаться к параметрам настройки удаленного доступа пользователя (например, к разрешениям удаленного доступа и параметрам ответного вызова), которые хранятся в Active Directory. После регистрации сервера удаленного доступа в Active Directory им можно управлять и отслеживать его состояние при помощи стандартных инструментов.

 Поддержка протокола аутентификации MS-CHAP версии 2. Протокол проверки подлинности запроса-подтверждения (Microsoft Challenge Handshake Authentication Protocol, MS-CHAP v2) предназначен для аутентификации участников соединения и создания ключей шифрования непосредственно во время установления соединения удаленного доступа. Протокол MS-CHAP v2 может быть также использован для аутентификации участников соединения при построении виртуальных частных сетей.

 Поддержка протокола аутентификации ЕАР. Расширяемый протокол аутентификации ЕАР (Extensible Authentication Protocol) позволяет использовать новые методы проверки подлинности участников подключения удаленного доступа, включая реализацию защиты, основанную на смарт-картах. Интерфейс ЕАР позволяет подключать модули проверки подлинности сторонних производителей.

 Поддержка протокола ВАР. Протокол распределения полосы пропускания ВАР (Bandwidth Allocation Protocol), а также протокол управления распределением полосы пропускания ВАСР (Bandwidth Allocation Control Protocol) повышают эффективность работы многоканальных РРР-соединений, динамически подключая или отключая дополнительные каналы, приспосабливаясь к изменению трафика.

 Механизм политик удаленного доступа. Под политикой удаленного доступа понимается набор условий и параметров настройки соединения, предоставляющих сетевым администраторам большую гибкость по установке и настройке разрешений удаленного доступа и атрибутов соединений.

 Поддержка клиентов удаленного доступа Macintosh. Служба маршрутизации и удаленного доступа Windows Server 2003 позволяет обслуживать подключение клиентов удаленного доступа Apple Macintosh, использующих протокол AppleTalk вместе с протоколом удаленного доступа ARAP (AppleTalk Remote Access Protocol) или с протоколом РРР.

 Поддержка широковещательных адресов IP (IP multicast). Используя механизм IGMP router and proxy версии 2 (маршрутизатор и посредник IGMP), сервер удаленного доступа может поддерживать обмен групповым IP-трафиком между клиентами удаленного доступа и Интернетом или корпоративной сетью.

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

Активизировав механизм NAT, администратор должен задать для каждого сетевого интерфейса диапазоны IP-адресов, которые будут использоваться данным механизмом для выполнения преобразования. Эта операция выполняется на вкладке Address Pool (Пул адресов) в окне свойств открытого сетевого интерфейса (рис. 14.16). Нажмите кнопку Add (Добавить) и в открывшемся окне задайте диапазон адресов. Диапазон определяется начальным адресом и маской подсети. При необходимости скорректируйте конечный адрес диапазона.

Рис. 14.16. Определение диапазона IP-адресов для преобразования

Если имеется несколько интервалов адресов, можно добавить каждый из них отдельно, нажав кнопку Add (Добавить).

Политики удаленного доступа

В Windows Server 2003 в качестве основного механизма однообразного конфигурирования отдельных компонентов системы используется механизм политик. Для управления удаленным доступом в Windows Sewer 2003 используются политики удаленного доступа (remote access policy). Под политикой удаленного доступа понимается набор условий и параметров соединения, которые предоставляют сетевому администратору больше возможностей в настройке разрешений удаленного доступа и атрибутов соединения. Фактически политика удаленного доступа представляет собой совокупность параметров, определяющих конфигурацию сетевого подключения.

При помощи политики удаленного доступа можно предоставлять разрешения удаленного доступа в зависимости от времени дня, дня недели, группы объектов, к которой принадлежит объект, ассоциированный с учетной записью звонящего пользователя, типа требуемого подключения (коммутируемое или VPN-подключение). Можно определить параметры настройки подключения, которые ограничивают максимальное время сеанса связи, тип аутентификации и шифрования, политику ВАР и фильтрацию IP-пакетов.

Важно помнить, что при использовании политик удаленного доступа соединение разрешается, только если параметры настройки соединения соответствуют, по крайней мере, одной из политик удаленного доступа (в соответствии со свойствами учетной записи пользователя и конфигурацией политики удаленного доступа). Если параметры настройки при попытке соединения не соответствуют ни одной из политик удаленного доступа, попытка соединения отклоняется независимо от свойств учетной записи пользователя. На серверах удаленного доступа под управлением Windows Server 2003 политика удаленного доступа конфигурируется с помощью оснастки Routing and Remote Access. На серверах IAS в среде Windows Server 2003 политика удаленного доступа управляется из оснастки Internet Authentication Service.

Элементы политики удаленного доступа

Политика удаленного доступа регламентирует две стороны процесса удаленного доступа к корпоративной сети: задает критерии, по которым происходит предоставление удаленного доступа к сети, а также определяет конфигурацию удаленного доступа. Эта задача выполняется посредством трех элементов политики удаленного доступа: условий, разрешений (прав) удаленного доступа, а также профилей. Рассмотрим эти элементы более подробно.

 Условия (policy conditions). Под условием политики удаленного доступа понимаются определенные значения одного или нескольких атрибутов, сравниваемые с параметрами попытки соединения. Если имеется несколько условий, то все условия должны соответствовать параметрам попытки соединения, которое сопоставляется политике. При попытке установить удаленное соединение служба маршрутизации и удаленного доступа последовательно просматривает список условий, определенных в рамках политики удаленного доступа (рис. 14.3). Значение атрибута, определенного в условии, сравнивается с аналогичным атрибутом клиента, устанавливающего соединение. В зависимости от того, выполнены или нет все перечисленные условия политики удаленного доступа, право удаленного доступа будет предоставлено или, наоборот, аннулировано. Список поддерживаемых атрибутов приведен в табл. 14.3.

Таблица 14.3. Атрибуты, используемые для формирования условий политики удаленного доступа

Атрибут	Описание
Authentication-Type (Тип аутентификации)	Протокол аутентификации, используемый клиентом, устанавливающим соединение. Данный атрибут позволяет администратору при необходимости потребовать для наиболее важных клиентов (с точки зрения уровня доступа) использования наиболее защищенного протокола аутентификации.
Called-Station-ld (Идентификатор вызванной системы)	Номер телефона сервера сетевого доступа. Этот атрибут — символьная строка. Можно использовать шаблон, чтобы задать коды городов. Необходимо позаботиться об установке телефонного номера для портов
Calling-Station-ld (Идентификатор вызывающей системы)	Номер телефона, использованный вызывающей системой. Этот атрибут — символьная строка. Можно использовать шаблоны, чтобы задать коды городов
Client-Friendly-Name (Имя клиента, дружественное название)	Название компьютера клиента RADIUS, который требует аутентификации. Этот атрибут — символьная строка. Можно использовать шаблон, чтобы задать имена клиентов. Этот атрибут предназначен для сервера IAS
Client-IP-Address (Клиентский IP-адрес)	IP-адрес клиента RADIUS. Этот атрибут — символьная строка. Можно использовать синтаксис шаблонов, чтобы определить IP-сеть. Этот атрибут предназначен для сервера IAS
Client-Vendor (Изготовитель клиента)	Имя изготовителя (поставщика) сервера сетевого доступа (NAS). У сервера удаленного доступа Windows Server 2003 изготовитель — "Microsoft RAS". Можно использовать этот атрибут, чтобы конфигурировать разные политики для различных NAS-поставщиков, которые являются клиентами RAIDUS (клиенты IAS). Этот атрибут предназначен для сервера IAS. Удостоверьтесь, что NAS настроен в качестве клиента RADIUS на сервере IAS
Day-And-Time-Restrictions (Ограничения по дню и времени)	День недели и время попытки соединения с сервером
Framed-Protocol (Протокол кадрирования)	Используемый тип кадрирования для входящих пакетов. Примеры — РРР, AppleTalk, SLIP, Х.25 и т. д. Этот атрибут предназначен для сервера IAS
NAS-Identifier (Идентификатор сервера сетевого доступа)	Имя, идентифицирующее сервер сетевого доступа (Network Access Server, NAS). Этот атрибут предназначен для сервера IAS
NAS-IP-Address (IP-адрес сервера удаленного доступа)	IP-адрес сервера сетевого доступа. Этот атрибут — символьная строка. Можно использовать синтаксис шаблона для сопоставления с образцом, чтобы определить IP-сети. Этот атрибут предназначен для сервера IAS
NAS-Port-Type (Тип порта NAS)	Тип носителей, используемых вызывающей стороной. Примеры — аналоговые телефонные линии (асинхронные линии), ISDN, туннели или виртуальные частные сети
Service-Type (Тип службы)	Тип требуемой службы. Этот атрибут разработан (предназначен) для сервера IAS
Tunnel-Type (Тип туннеля)	Протокол туннелирования, используемый для создания виртуального защищенного канала передачи данных (туннеля). В Windows Server 2003 поддерживаются два протокола туннелирования: РРТР и L2TP
Windows-Groups (Группы Windows)	Имена групп Windows, к которым принадлежит пользователь, делающий попытку соединения. Нет никакого атрибута для отдельного имени пользователя. Не нужно иметь отдельную политику удаленного доступа для каждой группы. Используя вложенные группы, можно перевести администрирование на уровень групп. Для сервера удаленного доступа или IAS при работе домена на функциональном уровне "Windows 2000 native" и выше администратор может использовать группы с универсальной областью действия. Запрещается использовать встроенные (built-in) группы независимо от их области действия (доменной или локальной)

<


/p>

Рис. 14.3. Добавление условия политики удаленного доступа

 Право удаленного доступа (remote access permission). Условия, определяемые в рамках политики удаленного доступа, задают фильтры, по которым отбираются клиенты, устанавливающие соединение, с тем, чтобы в последующем принять решение о том, будет ли им предоставлено право удаленного доступа или нет. Администратор может предоставить клиентам, отвечающим определенным условиям, это право, установив в окне свойств политики удаленного доступа переключатель Grant remote access permission (Предоставить право удаленного доступа), или отказать в нем, установив переключатель Deny remote access permission (Запретить разрешение удаленного доступа). Право удаленного доступа может быть также предоставлено (или аннулировано) непосредственно на уровне учетной записи пользователя: Будучи определенно на обоих уровнях, право удаленного доступа, предоставленное на уровне учетной записи, перекрывает право, предоставленное в рамках политики удаленного доступа. Если право удаленного доступа на уровне учетной записи пользователя установлено в значение Control Access through Remote Access policy (Управление на основе политики удаленного доступа), удаленный доступ предоставляется в соответствии с параметрами политики. По умолчанию устанавливается значение Deny remote access permission (Отказать в праве удаленного доступа). Это означает, что по умолчанию политика удаленного доступа запрещает удаленный доступ для клиентов, отвечающих определенным условиям.

 Профиль (profile). После того как клиенту предоставлено право удаленного подключения к сети, необходимым этапом становится определение конфигурации этого подключения. Политика удаленного доступа регулирует этот этап посредством механизма профилей политики удаленного доступа. Профиль (рис. 14.4) представляет собой набор параметров, описывающих конфигурацию сетевого соединения. Эти параметры объединяются в шесть групп:

 параметры, ограничивающие входящие звонки (вкладка Dial-in Constraints). Эта группа параметров позволяет администратору управлять такими свойствами сетевого подключения, как время простоя соединения, после которого соединение разрывается, дни и время, когда разрешено устанавливать соединение и т. п. Перечень параметров этой группы приведен в табл. 14.4;



 параметры, определяющие способ назначения клиенту IP-адреса (вкладка IP). По умолчанию сервер удаленного доступа автоматически распределяет IP-адреса, и клиентам не разрешено запрашивать конкретные IP-адреса. Эта же группа параметров позволяет администратору настроить фильтрацию IP-трафика в соответствии с требуемым уровнем безопасности. Администратор может запретить прохождение определенного типа трафика между клиентом удаленного доступа и сервером удаленного доступа (либо напротив, ограничить весь трафик пакетами определенного типа — например, разрешить только НТТР-трафик);

 параметры, регламентирующие функциональные возможности многоканального подключения (вкладка Multilink). Эта группа параметров используется для разрешения многоканального подключения, для определения максимального числа портов, которые могут быть использованы входящими соединениями, а также для настройки протокола ВАР (Bandwidth Allocation Protocol), включая формирование политики, определяющей его использование. По умолчанию использование многоканального подключения и протокола ВАР запрещено. Для применения этих параметров сервер удаленного доступа должен иметь возможность установления многоканального соединения и установленный протокол ВАР;

 параметры, регламентирующие процесс проверки подлинности пользователей (вкладка Authentication). Данная группа параметров используется для задания протоколов аутентификации, разрешенных для конфигурируемого соединения. В случае если разрешается использование расширяемого протокола аутентификации ЕАР, администратор может также определить тип используемого расширения ЕАР. По умолчанию разрешаются только протоколы аутентификации MS-CHAP и MS-CHAP v2. Следует обратить внимание на то, что в рамках профиля определяются протоколы аутентификации, которые разрешены для использования клиентами. Чтобы механизмы аутентификации успешно работали, необходимо, чтобы аналогичные протоколы были разрешены также и на уровне сервера удаленного доступа;

 параметры, определяющие уровень защищенности передаваемых данных (вкладка Encryption). Эта группа параметров позволяет активизировать механизмы шифрования данных, передаваемых в рамках конфигурируемого соединения. Администратор может определить механизмы шифрования, которые будут при этом использоваться, и уровень стойкости используемых алгоритмов (определяется длиной используемого для шифрования ключа). По умолчанию разрешено шифрование МРРЕ;



 дополнительные параметры (вкладка Advanced). Эта группа параметров позволяет настроить дополнительные свойства для определения ряда атрибутов RADIUS, которые сервер IAS возвращает клиенту RADIUS. По умолчанию протоколом удаленного доступа (Framed-Protocol) является РРР и для параметра Service-Type установлено значение Framed. Единственные атрибуты, используемые сервером удаленного доступа, — Account-interim-interval, Framed-Protocol, Framed-MTU, Reply-Message и Service-Type.

Таблица 14.4. Параметры, ограничивающие входящие звонки

Параметр	Описание
Idle-Timeout (Разъединение при простое более ...)	Временной интервал, по истечении которого соединение будет прервано, если нет никаких действий. По умолчанию этот параметр не установлен, и сервер удаленного доступа не разрывает неактивное соединение
Session-Timeout (Максимальная продолжительность сеанса)	Максимальное время до разрыва соединения сервером удаленного доступа. По умолчанию это свойство не установлено, а сервер удаленного доступа не ограничивает время сеанса связи
Allow access only... (Разрешить входящие подключения только в эти дни и время)	Дни недели и часы для каждого дня, во время которых соединение разрешено. Если день и время попытки соединения не соответствуют настройкам, попытка соединения отклоняется. По умолчанию это свойство не установлено, и сервер удаленного доступа не анализирует данные параметры
Called-Station-ID (Разрешить вход только по номеру)	Заданный номер телефона, который вызывающая сторона должна набрать, чтобы установить соединение. Если номер соединения не соответствует заданному, попытка соединения отклоняется. По умолчанию это свойство не установлено, и сервер удаленного доступа позволяет устанавливать соединение с любого телефонного номера
NAS-Port-Type (Разрешить входящие звонки следующих типов)	Типы устройств, например модем, ISDN или VPN, который вызывающая сторона должна использовать для соединения. На практике администратор может, например, разрешить удаленные подключения только по беспроводной (802.11) среде передачи. Если попытка соединения по коммутируемой среде не соответствует настройке, она отклоняется. По умолчанию это свойство не установлено, и сервер удаленного доступа разрешает все типы устройств передачи данных

<


/p> В Windows Server 2003 существует возможность запретить обработку специальных параметров учетной записи пользователя, отвечающих за настройку конфигурации удаленного доступа. Для этого в окне редактирования профиля политики удаленного доступа (рис. 14.4) нужно перейти на вкладку Advanced (Дополнительно). На этой вкладке перечислены дополнительные параметры, определяющие свойства соединения. Чтобы добавить новый атрибут, необходимо нажать кнопку Add и выбрать в списке интересующий атрибут. Следует добавить атрибут Ignore-User-Dialin-Properties (со значением Microsoft в столбце Vendor) и дать ему значение True (Истина) (рис. 14.5).



Рис. 14.4. Окно свойств профиля политики удаленного доступа



Рис. 14.5. Определение значения атрибута Ignore-User-Dialin-Properties

Политика удаленного доступа по умолчанию

В процессе установки службы маршрутизации и удаленного доступа создается политика удаленного доступа по умолчанию (default policy). Эта политика удаленного доступа разрешает удаленный доступ к серверу удаленного доступа только в том случае, если устанавливающему входящее соединение пользователю предоставлено право удаленного доступа непосредственно на уровне его учетной записи. Политика по умолчанию имеет следующую конфигурацию:

 ограничения по дням недели и времени доступа не установлены;

 право удаленного доступа запрещено (флажок Deny remote access permission);

 все свойства профиля установлены в значения по умолчанию.

Порядок применения политик удаленного доступа

Каждый пользователь может подпадать под действие сразу нескольких политик удаленного доступа. Для получения доступа необходимо, чтобы пользовательский запрос удовлетворял всем параметрам хотя бы одной политики удаленного доступа, предоставляющей ему право удаленного подключения. При этом используется следующий порядок применения параметров политик удаленного доступа:

1. Проверяется первая политика в упорядоченном списке политик. Если подходящей политики не существует, то попытка соединения отклоняется.



2. Если не все условия политики соответствуют попытке соединения, то осуществляется переход к следующей политике. Если политик больше нет, попытка соединения отклоняется.

3. Если все условия политики соответствуют попытке соединения, то проверяется значение атрибута Ignore-User-Dialin-Properties данной политики удаленного доступа. Если атрибут имеет значение False, система проверяет наличие разрешение на удаленное подключение на уровне учетной записи пользователя, предпринимающего попытку соединения. Если на уровне учетной записи удаленный доступ запрещен (Deny access), то попытка соединения отклоняется. Если же удаленный доступ разрешается (Allow access), то система проверяет соответствие остальным свойствам пользователя и профиля удаленного доступа. Соединение устанавливается только в том случае, если параметры соединения соответствуют всем параметрам свойств учетной записи пользователя и свойств профиля. Администратор может не определять явно на уровне учетной записи пользователя разрешение на удаленное подключение, установив флажок Control access through Remote Access Policy (Управление доступом через политику удаленного доступа). В этом случае решение о предоставлении или отклонении удаленного доступа принимается исключительно на основании параметров политики удаленного доступа. Соединение будет установлено только в том случае, если на уровне политики (под которую подпадает рассматриваемый пользователь) установлено разрешение Grant remote access permission, при этом применяются свойства пользователя и свойства профиля.

4. Если значение атрибута Ignore-User-Dialin-Properties установлено равным True, настройки учетной записи пользователя игнорируются. При этом права на предоставление удаленного доступа определяются исключительно параметрами политики удаленного доступа. Если на уровне политики, под которую подпадает пользователь, ему отказано в разрешении на удаленный доступ (флажок Deny remote access permission), соединение будет отклонено. Если разрешение предоставлено (Allow remote access permission), система применяет профиль удаленного доступа. Соединение будет установлено только в случае, когда параметры соединения удовлетворяют требованиям профиля удаленного доступа.

Понятие частного адреса

Архитектура стека протоколов TCP/IP требует, чтобы каждый хост в сети имел уникальный IP-адрес. Это требование справедливо и для Интернета. Любой хост, подключающийся к Интернету, должен являться обладателем уникального IP-адреса. В целях упорядочивания процесса адресации распределением IP-адресов занимается специальный Информационный центр сети Интернет (Network Information Center, InterNIC). Согласно терминологии NAT, эти адреса называются действительными (public address). Как правило, предприятие получает действительный адрес (или пул адресов) от своего Интернет-провайдера, который, в свою очередь, получил некоторый диапазон действительных адресов от InterNIC.

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

В качестве альтернативы механизму трансляции сетевых адресов в сетях малых офисов или домашних сетях на базе Windows Server 2003 можно использовать механизм общего доступа к подключению Интернета (Internet Connection Sharing, ICS).

Поскольку механизм трансляции сетевых адресов изначально разрабатывался как инструмент организации взаимодействия локальной сети с Интернетом, центром InterNIC были зарезервированы специальные пулы IP-адресов. Адреса из этих пулов не могут быть использованы для именования хостов в Интернете. Эти адреса получили название частных адресов (private address). Частные адреса предназначены для адресации хостов в корпоративных сетях, использующих механизм NAT как простое средство интеграции с Интернетом.

Для частных адресов зарезервированы следующие диапазоны (задаются идентификатором подсети и маской):

 10.0.0.0с маской 255.0.0.0

 172.16.0.0с маской 255.240.0.0

 192.168.0.0 с маской 255.255.0.0

Более подробная информация о диапазонах адресов, зарезервированных для частных интрасетей, может быть получена из стандарта RFC 1597.

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

Поставщики услуг IP-телефонии

Интерфейс TAPI поддерживает стандарт Н.323 и стандарт групповой конференц-связи IP при помощи соответствующих служб Windows Server 2003. Стандарт Н.323 представляет собой всеобъемлющий стандарт ITU для передачи мультимедиа (голоса, видео и данных) по сетям без установления логического соединения, например, по IP-сетям и Интернету, которые не обеспечивают гарантированное качество обслуживания (QoS). Стандарт описывает управление вызовом, мультимедиа и шириной полосы пропускания для двухточечных и многоточечных конференций. Н.323 поддерживает стандартные звуковые и видеокодеры и декодеры и обеспечивает поддержку совместного использования данных по стандарту Т. 120. Н.323 — стандарт, не зависящий от сети, платформы и прикладного уровня, что позволяет любому терминалу, соответствующему Н.323, взаимодействовать с любым другим терминалом.

Применение разделяемых ключей

Протокол туннелирования L2TP использует для шифрования пакетов протокол сетевого уровня IPSec. Применение протокола IPSec имеет свои характерные особенности. В частности, протокол содержит механизмы взаимной аутентификации всех участников соединения. В отличие от предыдущих версий, Windows Server 2003 предлагает два способа реализации этого процесса.

 Использование цифровых сертификатов. Каждый из участников соединения получает специальный цифровой сертификат, который и используется для проверки его подлинности. Эта схема проверки подлинности гарантирует наиболее гибкую систему обеспечения безопасности. Однако от администратора в этом случае требуется развертывание в сети корпоративной службы сертификатов (Public Key Infrastructure, PKI) или конфигурирование хостов на работу с внешними службами сертификатов.

 Использование разделяемых ключей. Под разделяемым ключом (pre-shared key) понимается некоторая последовательность символов (в формате Unicode), известная серверу удаленного доступа и клиенту. Для успешной аутентификации каждая из сторон должна подтвердить знание разделяемого ключа. Основным достоинством данного метода аутентификации является простота его реализации. Теперь, чтобы иметь возможность использовать протокол туннелирования L2TP, администратору не требуется развертывать в корпоративной сети систему сертификатов. Существенным недостатком, серьезно ограничивающим возможность применения данной схемы аутентификации, является использование единого общего разделяемого ключа для всех удаленных клиентов. Другими словами, все клиенты удаленного доступа, использующие протокол L2TP, должны быть сконфигурированы для использования одного и того же разделяемого ключа. Помимо того, что подобная схема аутентификации делает всю систему весьма уязвимой, в случае необходимости изменения ключа администратор должен выполнить переконфигурирование всех клиентов удаленного доступа.

Проблема автоматического изменения разделяемых ключей может быть решена администратором путем использования специального диспетчера подключений (Connection Manager). Если пользователи используют профили, создаваемые посредством этого диспетчера, изменение ключа будет выполнено автоматически после того, как обновленная версия профиля будет развернута пользователями на своих клиентских компьютерах.

Принципы действия NAT

Для установки соединения используется уникальная связка "адрес-порт". Другими словами, с хостом, имеющим один IP-адрес, может быть установлено множество соединений. Однако каждое из этих соединений будет использовать различные порты. Как правило, механизм NAT используется в ситуации, когда несколько частных адресов отображаются на один действительный адрес.

Для пакетов, исходящих из NAT, частный адрес, указанный в заголовке пакета в поле отправителя, отображается в действительный адрес, выданный интернет-провайдером, а номер порта TCP/UDP отображается в другой номер порта TCP/UDP. Для пакетов, приходящих NAT, действительный адрес, указанный в заголовке пакета в поле получателя, отображается в оригинальный адрес интрасети (частный адрес), а номер порта TCP/UDP отображается обратно к оригинальному номеру порта TCP/UDP. При этом TCP- и UDP-порты выбираются динамически, чтобы отличить один компьютер внутри интрасети от другого. Механизм NAT поддерживает специальную таблицу, в которую заносятся сведения об отображениях. Благодаря этой таблице механизм поддерживает уже установленные соединения, .используя для передачи входящих пакетов ту же связку "адрес-порт", которая использовалась для установки соединения.

Для демонстрации принципов работы механизма NAT рассмотрим следующий пример. Допустим, имеется небольшая локальная сеть предприятия, в которой для адресации хостов используется идентификатор сети 192.168.0.0. Так же предприятию интернет-провайдером выделен некоторый адрес a.b.c.d. Механизм NAT отображает все частные адреса в сети 192.168.0.0 в IP-адрес a.b.c.d (рис. 14.10).

Рис. 14.10. Пример работы механизма NAT

Допустим, пользователь локальной сети предпринимает попытку соединиться с веб-сервером, имеющим действительный адрес e.f.g.h. В этом случае клиентский компьютер формирует IP-пакет со следующей информацией в заголовке:

 IP-адрес получателя: e.f.g.h

 IP-адрес отправителя: 192.168.0.10

 порт получателя: TCP-порт 80

 порт отправителя: TCP-порт 1025

Механизм NAT выполняет преобразование заголовка этого пакета в следующий заголовок:

 IP-адрес получателя: e.f.g.h

 IP-адрес отправителя: a.b.c.d

 порт получателя: TCP-порт 80

 порт отправителя: TCP-порт 5000

Обратите внимание, что вместо частного адреса хоста, расположенного в локальной сети, в качестве отправителя указывается действительный адрес компьютера-преобразователя. При этом информацию о выполненном преобразовании {192.168.0.10, TCP 1025} в {a.b.c.d, TCP 5000} компьютер запоминает в своей внутренней таблице.

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

 IP-адрес получателя: a.b.c.d

 IP-адрес отправителя: e.f.g.h

 порт получателя: TCP-порт 5000

 порт отправителя: TCP-порт 80

Механизм NAT анализирует полученный пакет и, используя собственную адресную таблицу, отображает действительные адреса в частные. По окончании преобразования пакет будет передан хосту во внутренней сети (в нашем случае по адресу 192.168.0.10). При этом пакет содержит следующую информацию в заголовке:

 IP-адрес получателя: 192.168.0.10

 IP-адрес отправителя: e.f.g.h

 порт получателя: TCP-порт 1025

 порт отправителя: TCP-порт 80

Процедура аутентификации удаленного доступа

Аутентификация пользователей, подключающихся к серверу удаленного доступа под управлением Windows Server 2003, выполняется по следующему сценарию:

1. Клиент удаленного доступа инициирует процесс подключения к серверу удаленного доступа (например, набирает его телефонный номер).

2. Происходит физическое соединение (например, двух модемов).

3. Сервер отправляет запрос клиенту с требованием предоставить информацию о полномочиях подключающегося пользователя.

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

5. Сервер проверяет информацию, содержащуюся в ответе, обращаясь к каталогу Active Directory. В случае автономного сервера удаленного доступа для проверки полномочий пользователя используется локальная база данных учетных записей сервера.

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

7. Если разрешена функция ответного вызова, сервер вызывает клиента и продолжает переговоры о соединении.

Процесс аутентификации предполагает проверку подлинности пользователя. Тем не менее, сам факт успешного прохождения процедуры аутентификации не означает, что пользователь автоматически получает доступ к корпоративной сети. После аутентификации удаленного пользователя и подключения клиента к корпоративной сети клиент удаленного доступа может обращаться только к тем сетевым ресурсам, для которых он имеет соответствующее разрешение. Клиенты удаленного доступа подчиняются общим принципам разграничения доступа Windows Server 2003 точно так же, как если бы они физически располагались в локальной сети. Другими словами, клиенты удаленного доступа не могут выполнять какие-либо действия, не имея достаточных на то полномочий, и не могут обращаться к ресурсам, для которых они не имеют соответствующих разрешений.

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

Протокол CHAP

Протокол CHAP (Challenge Handshake Authentication Protocol) представляет собой механизм проверки подлинности типа "запрос-ответ", использующий схему хэширования MD-5 для необратимого преобразования пароля пользователя в уникальную последовательность символов. Оба участника соединения выполняют подобное преобразование. Благодаря этому по сети передается не сам пароль, а только хэшированная последовательность. Сервер сравнивает полученную последовательность с собственной копией и только в случае идентичности последовательностей пользователь считается аутен-тифицированным. В качестве одного из присущих протоколу недостатков можно отметить отсутствие механизмов взаимной аутентификации всех участников соединения.

Протокол аутентификации CHAP является стандартом Интернета (RFC 1994) и поддерживается множеством производителей программного обеспечения. В среде Windows Server 2003 протокол CHAP может быть использован для аутентификации клиентов удаленного доступа сторонних производителей.

Протокол ЕАР

Протокол ЕАР (Extensible Authentication Protocol) представляет собой расширяемый механизм аутентификации, позволяющий унифицировать процесс проверки подлинности пользователей, предоставляя при этом участникам соединения возможность использования самых разнообразных схем аутентификации. Спецификация протокола ЕАР описывает способы подключения самых разнообразных схем аутентификации (в числе которых — смарт-карты, протокол RADIUS и т. п.). Можно рассматривать протокол ЕАР как универсальную платформу для реализации любых необходимых схем аутентификаций. Точная схема аутентификации, используемая участниками соединения, устанавливается в результате переговоров между клиентом удаленного доступа и сервером удаленного доступа.

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

Специальная схема проверки подлинности ЕАР называется типом ЕАР (ЕАР type). Для успешной проверки подлинности и клиент удаленного доступа, и сервер удаленного доступа должны поддерживать один и тот же тип ЕАР.

В Windows Server 2003 реализована поддержка двух типов ЕАР (EAP-MD5 CHAP и EAP-TLS). Однако при необходимости администратор может расширить функциональность протокола ЕАР, добавив поддержку других типов ЕАР. Для этого достаточно подключить соответствующие модули аутентификации. Необходимо, однако, помнить о том, что для успешной аутентификации соответствующий модуль должен быть подключен как на сервере удаленного доступа, так и на клиенте удаленного доступа.

Кроме того, в рамках Windows Server 2003 предусмотрена возможность передачи сообщений протокола ЕАР внутри сообщений протокола RADIUS (компонент БАР-RADIUS). Эта возможность может быть использована в ситуации, когда в сети эксплуатируется инфраструктура протокола RADIUS как основной механизм аутентификации. При этом инфраструктура RADIUS может быть использована для передачи сообщений протокола ЕАР.

Чтобы обеспечить проверку подлинности на базе ЕАР, необходимо:

 разрешить ЕАР как протокол аутентификации на сервере удаленного доступа;

 разрешить ЕАР, и, если требуется, настроить тип ЕАР для соответствующей политики удаленного доступа;

 разрешить и настроить ЕАР на стороне клиента удаленного доступа.

Протокол RADIUS

Протокол аутентификации Remote Authentication Dial-in User Service (RADIUS) рассматривается как механизм аутентификации и авторизации удаленных пользователей в условиях распределенной сетевой инфраструктуры, предоставляющий централизованные услуги по проверке подлинности и учету для служб удаленного доступа. Протокол RADIUS реализован в составе службы Internet Authentication Service (IAS), обеспечивающей централизованное управление аутентификацией, авторизацией и аудитом доступа на основании информации о пользователях, получаемой от контроллеров домена Windows Server 2003. Протокол RADIUS детально описан в открытых стандартах RFC 2138 и 2139. В рамках стандарта выделяются три компонента протокола) (рис. 14.1).

 Клиент RADIUS. Клиент RADIUS принимает от пользователей запросы на аутентификацию. Все принятые запросы переадресовываются серверу RADIUS для последующей аутентификации и авторизации. Как правило, в качестве клиента протокола RADIUS выступает сервер удаленного доступа.

 Сервер RADIUS. Основная задача сервера RADIUS заключается в централизованной обработке информации, предоставленной клиентами RADIUS. Один сервер способен обслуживать несколько клиентов RADIUS. Сервер осуществляет проверку подлинности пользователя и его полномочий. При этом в зависимости от реализации сервера RADIUS для проверки подлинности используются различные базы данных учетных записей. Реализованный в рамках службы Internet Authentication Service (IAS) сервер RADIUS способен в процессе проверки подлинности пользователя осуществлять взаимодействие со службой катаюга Active Directory.

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

Рис. 14.1. Компоненты протокола RADIUS

В рамках протокола RADIUS вводится понятие сферы (realm). Сферы используются для логической группировки клиентов RADIUS по некоторому признаку. Каждый клиент RADIUS может быть отнесен только к одной сфере. Информация о сфере RADIUS используется для выбора сервера RADIUS, который должен выполнить аутентификацию пользователя.

Протокол RADIUS является открытым стандартом Интернета. В силу этого он может использоваться для организации процесса аутентификации в гетерогенных сетях. Так, например, для аутентификации на UNIX-системах может использоваться информация об учетных записях пользователей из каталога Active Directory.

Служба проверки подлинности в Интернете

Поддержка функций сервера RADIUS, а также посредника RADIUS реализована в Windows Server 2003 в рамках Службы проверки подлинности в Интернете (Internet Authentication Service, IAS). Эта служба позиционируется как механизм централизованной аутентификации и авторизации пользователей, использующих различные способы подключений к сети. Служба IAS интегрирована с другими базовыми службами Windows Server 2003, такими, как служба маршрутизации и удаленного доступа и служба каталога Active Directory. Служба маршрутизации и удаленного доступа использует службу IAS для аутентификации и авторизации пользователей, подключающихся к сети удаленно. Фактически в случае развертывания в корпоративной сети службы IAS серверы удаленного доступа не выполняют процесс аутентификации пользователей. Все обязанности по проверке подлинности пользователей берет на себя служба IAS. При этом служба каталога рассматривается службой IAS как хранилище информации об учетных записях пользователей.

Преимущество использования IAS для аутентификации и авторизации пользователей особенно очевидно в гетерогенных сетях, реализующих различные механизмы подключений к сети (беспроводной доступ, коммутируемые подключения, а также VPN-подключения). Поддержка этого протокола реализована на многих современных платформах, что позволяет использовать его в межплатформенных решениях.



Рис. 14.2. Окно оснастки Internet Authentication Service

Управление службой IAS осуществляется при помощи оснастки Internet Authentication Service (рис. 14.2). Настройка конфигурации IAS осуществляется через механизм политик удаленного доступа, речь о которых пойдет позже в рамках этой главы.

Развертывание службы IAS

Служба IAS не устанавливается по умолчанию в процессе развертывания Windows Server 2003. В случае необходимости администратор должен выполнить установку службы самостоятельно, используя процедуры, описанные в разд. "Установка дополнительных сетевых компонентов" главы 12.

Протокол РАР

Протокол PAP (Password Authentication Protocol) использует пароли, передаваемые открытым текстом, и является самым простым протоколом проверки подлинности пользователей. Обычно соединение на его основе устанавливается, если клиент удаленного доступа и сервер удаленного доступа не могут договориться о более безопасной форме проверки подлинности.

Протокол РАР предполагает передачу паролей пользователей открытым текстом. Всякий, кто перехватит пакеты процесса аутентификации, может легко прочитать пароль и использовать его для несанкционированного доступа к корпоративной сети. Фактически протокол РАР используется только в том случае, когда клиент и сервер удаленного доступа не поддерживают никаких других протоколов аутентификации. В этой ситуации передача пароля открытым текстом является единственной возможностью подтвердить полномочия пользователя.

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

Протокол SPAP

Протокол аутентификации SPAP (Shiva Password Authentication Protocol) использует для шифрования паролей реверсивный механизм шифрования Shiva. В среде Windows Server 2003 протокол SPAP может быть использован для организации соединений с Shiva LAN Rover. Эта схема проверки подлинности более безопасна, чем передача данных открытым текстом, но менее безопасна, чем CHAP или MS-CHAP. Связано это с тем, что протокол SPAP не предусматривает защиты от перехвата зашифрованных паролей, которые впоследствии могут быть использованы для несанкционированного доступа в систему (один и тот же пароль при выполнении операции шифрования будет давать одну и ту же последовательность).

Протоколирование событий

Требования политики безопасности большинства предприятий предполагают регистрацию всех событий, связанных с действиями удаленных пользователей в рамках корпоративной сети. Сервер удаленного доступа Windows Server 2003 позволяет регистрировать все события, связанные с аутентификацией удаленных пользователей, в специальных журналах. Анализ подобных журналов может позволить администратору выявить попытки несанкционированного проникновения в систему, определить периоды максимальной и минимальной нагрузки на сервер.

Строго говоря, сервер удаленного доступа Windows Server 2003 поддерживает два типа регистрации событий. В первом случае речь идет о событиях, связанных с функционированием службы маршрутизации и удаленного доступа в целом. Эти события регистрируются в системном журнале Windows Server 2003 (System log). Информация, содержащаяся в этом журнале, используется для разрешения проблем, вызванных сбоями в работе компонентов системы.

Во втором случае сервер удаленного доступа под управлением Windows Server 2003 регистрирует события, связанные с аутентификацией удаленных пользователей. На основе регистрируемой информации можно проследить использование удаленного доступа и попытки аутентификации. Регистрация особенно полезна для оперативного решения проблем при работе с политиками удаленного доступа. Для каждой попытки аутентификации регистрируется название политики удаленного доступа, в соответствии с которой была принята или отклонена попытка установления соединения. Информация о регистрируемых событиях может быть сохранена в файле журнала, либо сохраняться в базе данных (под управлением MS SQL Server). Используемые для регистрации событий журналы располагаются в папке %SystemRoot%\system32\LogFiles. Журналы хранятся в формате IAS 1.0 или IAS 2.0.

В качестве альтернативы текстовым файлам (которые неудобны для анализа) администратор может сохранять информацию о событиях в базе данных. Для соединения с базой данных используется интерфейс ODBC. Соответственно, перед регистрацией событий администратор должен сконфигурировать ODBC-соединение.

Регистрация событий, связанных с проверкой подлинности удаленных пользователей, возможна только в том случае, если используется стандартный механизм аутентификации Windows (Windows accounting). В случае применения для аутентификации пользователей протокола RADIUS администратор должен задействовать механизмы протоколирования событий службы IAS.

Протоколы аутентификации пользователей

С точки зрения информационной безопасности любой удаленный пользователь должен быть аутентифицирован, прежде чем сможет получить доступ к ресурсам. Аутентификация происходит непосредственно при попытке клиента установить соединение с сервером удаленного доступа. Каждый пользователь, подключающийся удаленно к корпоративной сети, должен иметь на сервере или в каталоге Active Directory соответствующую учетную запись. Пароль, сопоставленный этой учетной записи, и используется для аутентификации пользователя.

Для аутентификации удаленных пользователей нельзя использовать те же механизмы, что используются в локальной сети. Специалистами разработан целый ряд специальных механизмов, получивших название протоколов аутентификации удаленных пользователей. В Windows Server 2003 реализована поддержка следующих протоколов:

 протокол RADIUS (Remote Authentication Dial-In User Service);

 протокол ЕАР (Extensible Authentication Protocol);

 протокол MS-CHAP (Microsoft Challenge Handshake Authentication Protocol);

 протокол MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol version 2);

 протокол CHAP (Challenge Handshake Authentication Protocol);

 протокол SPAP (Shiva Password Authentication Protocol);

 протокол PAP (Password Authentication Protocol);

Рассмотрим эти протоколы более подробно.

Microsoft Challenge Handshake Protocol) представляет

Протокол MS-CHAP ( Microsoft Challenge Handshake Protocol) представляет собой реализацию протокола CHAP, предложенную компанией Microsoft. В отличие от CHAP, для хэширования паролей применяется алгоритм MD4. Существует две версии протокола MS-CHAP. Вторая версия протокола MS-CHAP (MS-CHAP v2) предлагает более эффективный механизм аутентификации (табл. 14.1). В частности, реализован механизм взаимной аутентификации. Сервер удаленного доступа по окончании процедуры аутентификации клиента удаленного доступа предоставляет ему информацию о собственных полномочиях. Соединение не считается установленным до тех пор, пока клиент не удостоверится в подлинности сервера удаленного доступа.

Таблица 14.1. Сравнение протоколов MS-CHAP версий 1 и 2

Проблемы MS-CHAP версии 1	Решение в MS-CHAP версии 2
Кодирование ответа по схеме LAN Manager, которое используется для обратной совместимости со старыми клиентами Microsoft удаленного доступа, использует слабое шисррование	MS-CHAP v2 более не поддерживает ответы, закодированные по схеме LAN Manager
Кодирование пароля по схеме LAN Manager использует слабое шифрование	MS-CHAP v2 более не поддерживает передачу изменений паролей, закодированных по схеме LAN Manager
Возможна только однонаправленная проверка подлинности. Клиент удаленного доступа не может проверить, соединился он с подлинным или с ложным (подставным) сервером удаленного доступа	MS-CHAP v2 поддерживает двустороннюю проверку подлинности, также называемую взаимной проверкой подлинности. Клиент удаленного доступа проверяет, к тому ли серверу удаленного доступа он подключился
При 40-разрядном шифровании ключ шифрования основывается на пароле пользователя. Каждый раз, когда пользователь подключается с тем же самым паролем, будет сгенерирован тот же самый ключ	При использовании MS-CHAP v2 ключ шифрования основывается на пароле пользователя и произвольной строке запроса. Каждый раз, когда пользователь подключается с тем же самым паролем, используется другой ключ
Используется единый ключ шифрования для данных, передаваемых в обоих направлениях соединения	Используются отдельные ключи шифрования, которые генерируются для передаваемых и получаемых данных

Проверка идентификатора звонящего абонента

Активизировав режим проверки идентификатора звонящего абонента (Caller ID), администратор может задать телефонный номер, с которого определенному пользователю разрешено осуществлять удаленное подключение. В процессе подключения информация о номере, с которого производится звонок, передается серверу удаленного доступа. Сервер проверяет идентификатор звонящего абонента с тем, что указан в настройках учетной записи пользователя. Если пользователь производит попытку соединения с другого номера, сервер удаленного доступа отклоняет ее.

Режим проверки идентификатора звонящего абонента должен поддерживаться всеми участниками удаленного подключения (вызывающей стороной, телефонной сетью между вызывающей стороной и сервером удаленного доступа, а также сервером удаленного доступа). Поддержка указанного режима на стороне сервера удаленного доступа включает в себя, прежде всего, оборудование, отвечающее на вызов клиента. Это оборудование должно поддерживать передачу идентификатора звонящего абонента соответствующему встроенному драйверу Windows Server 2003, который, в свою очередь, поддерживает передачу идентификатора вызывающей стороны службе маршрутизации и удаленного доступа.

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

Режим проверки звонящего абонента позволяет обеспечить большую степень безопасности для организации труда надомных работников (telecommuters). Недостаток описанного механизма заключается в том, что пользователь может получить удаленный доступ только с конкретной телефонной линии. Необходимо, однако, иметь в виду, что в России данная функциональная возможность недоступна на большинстве телефонных станций, кроме современных цифровых станций, устанавливаемых взамен старых, или коммерческих провайдеров телефонных услуг.

Разрешение входящего соединения

Механизм NAT может быть использован не только для организации доступа внутренних пользователей к ресурсам сети Интернет. Администратор может настроить механизм NAT таким образом, чтобы предоставить возможность внешним пользователям получать доступ к ресурсам локальной сети. Например, можно предоставить доступ внешним пользователям к ресурсам корпоративного веб-сервера, располагающегося внутри корпоративной сети. В данном случае принято говорить о входящем соединении (inbound connection).

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

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

Развертывание механизма NAT в корпоративной сети

Рассмотрим процесс развертывания в корпоративной среде механизма NAT. Прежде чем приступить к конфигурированию службы маршрутизации и удаленного доступа (Routing and Remote Access Service), администратор должен выполнить ряд подготовительных операций.

Развертывание сервера удаленного доступа

Чтобы обеспечить работу сервера удаленного доступа на Windows Server 2003, необходимо соответствующим образом сконфигурировать службу маршрутизации и удаленного доступа (Routing and Remote Access Service). Для управления этой службой используется оснастка Routing and Remote Access, которая располагается в меню Administrative Tools (Администрирование). Данная оснастка может использоваться в качестве инструмента для управления всеми серверами удаленного доступа под управлением Windows Server 2003, установленными в пределах корпоративной сети.

В ходе инсталляции системы устанавливаются все программные компоненты, необходимые для функционирования службы маршрутизации и удаленного доступа. Однако по окончании установки эта служба отключена. Прежде чем администратор сможет запустить данную службу, он должен выполнить ее конфигурирование, определив ее роль.

Конфигурирование службы маршрутизации и удаленного доступа осуществляется при помощи специального мастера Routing and Remote Access Server Setup Wizard. Для запуска этого мастера необходимо в пространстве имен оснастки вызвать контекстное меню объекта, ассоциированного с сервером, и выбрать в нем пункт Configure and Enable Routing and Remote Access (Конфигурировать и разрешить маршрутизацию и удаленный доступ). При помощи указанного мастера администратор может сконфигурировать сервер в качестве маршрутизатора, сервера удаленного доступа, активизировать на нем механизм трансляции сетевых адресов. В контексте нашей темы, рассмотрим процесс конфигурирования сервера удаленного доступа.

Перед выполнением процедуры конфигурирования сервера удаленного доступа необходимо принять решение по следующим вопросам:

 каким образом будет осуществляться распределение IP-адресов между клиентами удаленного доступа? Существует два варианта решения этой проблемы. Первый вариант предполагает использование корпоративного DHCP-сервера. Во втором случае клиенты получают IP-адреса непосредственно от сервера удаленного доступа из некоторого статического пула, определенного администратором;

  какое максимальное количество входящих подключений будет использоваться? От ответа на этот вопрос зависит то, сколько модемов, ориентированных на подключение удаленных пользователей, потребуется подключить к серверу удаленного доступа;

 какая модель конфигурирования параметров удаленного подключения будет использоваться? Параметры удаленного подключения могут задаваться на уровне учетных записей отдельных пользователей или определяться политикой удаленного доступа. На этапе развертывания сервера удаленного доступа должны быть произведены все необходимые настройки учетных записей пользователей, а также определены параметры политик удаленного доступа;

 какая будет использоваться схема аутентификации? Имеется два варианта — либо аутентификация выполняется непосредственно сервером удаленного доступа, либо используются средства протокола RADIUS и службы аутентификации IAS. Использование службы аутентификации IAS и протокола RADIUS оправдано в ситуации, когда в сети имеется несколько серверов удаленного доступа. В этом случае администратор имеет возможность реализовать централизованное управление процессом аутентификации пользователей.

Запустив мастер конфигурирования сервера удаленного доступа, необходимо перейти к окну Configuration (Конфигурация), в котором мастер предлагает определить роль конфигурируемого сервера (рис. 14.6). Выберите пункт Remote access (dial-up or VPN) и перейдите к следующему окну.

В окне "Remote Access" (рис. 14.7) необходимо уточнить функции, которые будет выполнять конфигурируемый сервер. Если сервер должен обслуживать обычные модемные подключения удаленных пользователей, необходимо установить флажок Dial-up. Флажок VPN следует устанавливать только в том случае, если сервер должен также обслуживать VPN-подключения внешних пользователей (подключающихся, например, через Интернет).

Далее требуется определить способ предоставления подключающимся клиентам IP-адресов, необходимых для работы в корпоративной сети (рис. 14.8).





Рис. 14.6. Определение роли службы маршрутизации и удаленного доступа



Рис. 14.7. Определение типов подключений, которые будут разрешены на конфигурируемом сервере удаленного доступа



Рис. 14.8. Указание способа предоставления клиентам IP-адреса

Выбор опции Automatically (Автоматически) означает использование DHCP-сервера. Если администратор хочет выделять адреса из статического пула, необходимо выбрать опцию From a specified range of addresses (Из определенного диапазона адресов). В последнем случае администратор должен будет задать этот диапазон в следующем окне.

И, наконец, в последнем окне мастера (рис. 14.9) необходимо ответить на запрос об использовании сервера RADIUS — т. е. выбрать схему аутентификации пользователей. Если аутентификация будет выполняться непосредственно сервером удаленного доступа, необходимо выбрать опцию No, use Routing and Remote Access to authenticate connection requests (Нет, использовать для аутентификации запросов службу маршрутизации и удаленного доступа). В случае использования для аутентификации сервера RADIUS необходимо выбрать значение Yes, set up this server to work with a RADIUS server (Да, настроить этот сервер для работы с RADIUS-сервером).

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



Рис. 14.9. Выбор способа аутентификации клиентов удаленного доступа

Редактор титульных страниц факсов

Утилита Fax Cover Page Editor (рис. 14.24) позволяет администратору осуществлять редактирование шаблонов титульных листов, которые используются в процессе передачи пользователями факсов. Можно создавать общие титульные листы, чтобы совместно использовать их из нескольких профилей. По умолчанию служба факсов включает четыре общих шаблона титульных листов. При передаче факса шаблон получает информацию, предоставленную пользователем в окне Sender Information (Сведения об отправителе), вызываемого из меню Tools (Сервис) оснастки Fax Console (Консоль факсов), и автоматически добавляет ее к передаваемому титульному листу.

Можно использовать существующие (стандартные) титульные листы (файлы с расширением cov). В меню Tools (Сервис) оснастки Fax Console необходимо выбрать команду Personal Cover Pages (Личные титульные страницы) и в открывшемся окне (рис. 14.25) нажать кнопку Сору (Копировать).

Рис. 14.24. Редактор титульных страниц позволяет быстро создать фирменные бланки на основе имеющихся шаблонов

Рис. 14.25. Перечень персональных титульных страниц

Пользователь может выбрать стандартный титульный лист и скопировать его в папку Fax | Personal Coverpages, появляющуюся в папке My Documents (Мои документы) после установки службы факсов. При необходимости можно отредактировать скопированный титульный лист (при этом оригинал не будет изменен).

Редакторы NAT

Работа NAT базируется на анализе заголовков пакетов. Преобразователь адресов извлекает из заголовка пакета информацию о IP-адресах и номерах портов отправителя и получателя пакетов и в соответствии с полученными данными принимает решение о трансляции пакета. Для нормального функционирования механизма NAT необходимо, чтобы требуемая информация содержалась в заголовке пакета.

Существует целый ряд приложений и протоколов, которые размешают информацию об IP-адресе и номере TCP/UDP-порта непосредственно в теле пакета. В качестве примера можно привести протокол FTP, который для команды FTP PORT передает десятичное представление IP-адреса в теле команды. Если NAT неправильно транслирует IP-адрес внутри команды FTP, то могут возникнуть проблемы установки соединения.

Кроме того, существуют протоколы, вообще не использующие для передачи данных протоколы TCP или UDP (большинство протоколов использует для доставки пакетов транспортные протоколы TCP или UDP). Например, транспортный протокол РРТР не использует для доставки данных протоколы TCP или UDP. Вместо заголовков TCP или UDP используется специальный заголовок обшей инкапсуляции маршрутизации (Generic Routing Encapsulation, GRE) и специальное поле Tunnel ID для идентификации потока данных. Если бы NAT не транслировал это поле, то передача данных при помощи протокола РРТР через NAT была бы невозможна.

В подобных ситуациях администратор имеет возможность выполнить конфигурирование механизма NAT при помощи специального редактора. Редактор NAT представляет собой устанавливаемый компонент, позволяющий корректно изменять нетранслируемую иным способом информацию — так, чтобы она могла быть передана через механизм NAT. Редактор NAT позволяет сконфигурировать механизм NAT для трансляции и коррекции не только заголовков IP, TCP и UDP, но и служебной информации в теле пакетов.

Шифрование данных

По соображениям безопасности удаленный доступ к любой конфиденциальной информации должен осуществляться только по защищенному каналу. В ситуации, когда для организации удаленного доступа используются общественные телефонные линии (либо линии, по которым нельзя исключить "снятие" информации), для создания защищенного канала необходимо применять специальные механизмы шифрования. Эти механизмы позволя ют шифровать весь сетевой трафик, передаваемый между клиентом и сервером удаленного доступа. Сервер удаленного доступа должен быть настроен на использование только шифрованного обмена данными. Любой клиент, устанавливающий соединение с подобным сервером, должен поддерживать заявленные механизмы шифрования, иначе соединение не производится.

При коммутируемом соединении можно защитить данные, зашифровав их на пути между клиентом и сервером удаленного доступа. Для коммутируемых сетевых соединений Windows Server 2003 использует собственный механизм шифрования "точка-точка" (Microsoft Point-to-Point Encryption, МРРЕ). Для применения механизма МРРЕ необходимо активизировать протоколы аутентификации MS-CHAP или EAP-TLS.

В случае соединения с виртуальной частной сетью (VPN-подключение) данные могут быть защищены путем их шифрования на пути между концами виртуальной частной сети. Необходимо применять шифрование данных для VPN-подключения, если частные данные передаются по сети общего пользования (например, через Интернет), где всегда есть риск перехвата данных. В Windows Server 2003 выбор схемы шифрования данных, передаваемых через VPN-подключение, определяется используемым протоколом туннелиро-вания. Для протокола РРТР шифрование осуществляется с помощью механизма МРРЕ, а в случае протокола L2TP посредством протокола IPSec. Следует заметить, что в последнем случае не требуется использования каких-то специальных протоколов аутентификации удаленных пользователей (в случае механизма МРРЕ, напомним, обязательно использование протокола аутентификации MS-CHAP или EAP-TLS).

Поскольку шифрование данных выполняется между VPN-клиентом и VPN-сервером, то на соединении между клиентом удаленного доступа и интернет-провайдером оно уже не является необходимым.

Служба факсимильных сообщений

В Windows Server 2003 (как и в Windows XP) реализована специальная служба факсов (Fax Service), позволяющая администратору организовать отправку и получение факсимильных сообщений на базе персонального компьютера, оборудованного факс-модемом. Идея использования компьютера в качестве факса не нова. В настоящее время на рынке программного обеспечения присутствует масса приложений, реализующих данный сервис. Реализация специальной службы непосредственно в составе операционной системы позволяет отказаться от использования дополнительного программного обеспечения.

В Windows Server 2003 факсы рассматриваются как принтеры. В частности, получить информацию об установленных факсах и их состоянии можно в окне Printers and Faxes (рис. 14.20). При этом факсы могут выступать в качестве устройств общего доступа (shared devices). Обращение к факсам осуществляется так же просто, как и обычная печать документа. Чтобы послать по факсу документ, достаточно просто выбрать в меню приложения, в котором данный документ открыт, команду Print (Печать). При передаче понадобится добавить только информацию о получателе и заметки в мастере Send Fax Wizard (Мастер отправки факсов) — и факс будет отправлен. Альтернативный вариант — непосредственный вызов этого мастера с помощью команды Send a fax (Отправка факса). Работа с данным мастером не вызывает никаких сложностей и не требует обучения пользователя.

Команда Print (Печать) обычно присутствует в текстовых процессорах, электронных табличных процессорах и в приложениях других типов. Дополнительно можно использовать почтовые программы, чтобы одновременно посылать электронную почту и факсимильные сообщения.

Рис. 14.20. Доступ к установленным факсам

Для передачи факсов Windows Server 2003 использует многостраничный формат изображений TIFF (Tagged Image File Format). Можно сканировать отпечатанные документы и полученные изображения отправлять по факсу. Не требуется преобразовывать существующую графику в формат TIFF перед передачей факса — служба факсов сделает это автоматически. Служба факсов также содержит компонент для предварительного просмотра (Imaging Preview) полученных и отправленных факсимильных сообщений.

Служба маршрутизации и удаленного доступа

В Windows Server 2003 реализована Служба маршрутизации и удаленного доступа (Routing and Remote Access Service, RRAS), позволяющая удаленным пользователям подключаться к корпоративным вычислительным сетям. При этом подключение может быть выполнено как по коммутируемой линии, так и через виртуальные частные сети (Virtual Private Network, VPN). При коммутируемом соединении клиент удаленного доступа устанавливает коммутируемую связь для подключения к физическому порту на сервере удаленного доступа, используя некоторую службу-посредника для передачи данных, например аналоговый телефон, ISDN или Х.25. Наиболее типичный пример коммутируемого доступа — установление соединения клиентом удаленного доступа при помощи модема, т. е. путем набора телефонного номера одного из портов сервера удаленного доступа.

Соединение с виртуальной частной сетью (или VPN-подключение) представляет собой защищенное соединение типа "точка-точка" через сеть общего пользования (например, Интернет) или большую корпоративную сеть. Поддержка службой удаленного доступа механизма виртуальных частных сетей позволяет устанавливать безопасное соединение с корпоративной сетью через различные открытые сети (такие, например, как Интернет). Для эмуляции прямого соединения данные инкапсулируются специальным способом, т. е. снабжаются специальным заголовком, который предоставляет информацию, необходимую для маршрутизации, чтобы пакет мог достигнуть 'адресата. Получателем пакета является VPN-клиент либо VPN-сервер. Часть пути, по которому данные следуют в инкапсулированном виде, называется туннелем.

Для организации безопасной виртуальной частной сети перед инкапсуляцией данные шифруются. Перехваченные по пути следования пакеты невозможно прочитать без ключей шифрования. Участок VPN соединения, на котором данные передаются в зашифрованном виде, и называется, собственно, виртуальной частной сетью. Сервер удаленного доступа в случае использования механизма виртуальных частных сетей выступает в качестве посредника, осуществляя обмен данными между клиентом VPN и корпоративной сетью. При этом сервер удаленного доступа осуществляет все необходимые преобразования данных (шифрование/дешифрование). Для этого используются специальные протоколы туннелирования (tunneling protocols). VPN-клиент и VPN-сервер должны использовать один и тот же протокол туннелирования, чтобы создать VPN-соединение. В службе удаленного доступа в Windows Server 2003 реализована поддержка протоколов туннелирования РРТР и L2TP.

Специальные параметры учетной записи пользователя

В Windows Server 2003 вся информация о пользователях (в том числе и удаленных) размещается в каталоге Active Directory в виде объектов, ассоциированных с учетными записями, или в локальной базе учетных записей.

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

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

Параметры		Описание
Remote Access Permission (Разрешение на удаленный доступ)		Данный параметр является важным с точки зрения того, что он определяет, разрешен ли явно некоторому пользователю удаленный доступ или нет. Администратор может использовать этот параметр для того, чтобы явно запретить удаленный доступ либо делегировать решение данного вопроса политике удаленного доступа. В последнем случае выбирается опция Control access through Remote Access Policy (Управление на основе политики удаленного доступа). Необходимо, однако, помнить, что даже в том случае, когда доступ явно разрешен, он может быть запрещен на других уровнях (условиями политики удаленного доступа, параметрами учетной записи пользователя или свойствами профиля)
Verify Caller-ID (Проверка идентификатора вызывающей стороны)		Если это свойство разрешено, сервер проверяет телефонный номер вызывающей стороны. Если он не соответствует определенному номеру, попытка соединения отклоняется
Callback Options (Параметры ответного вызова)		Если это свойство разрешено, то при установке соединения сервер запрашивает у вызывающей стороны указываемый ею телефонный номер или использует телефонный номер, заданный сетевым администратором, а затем производит ответный вызов. Данная функциональная возможность позволяет соблюсти должный уровень безопасности при подключении удаленных пользователей, разрешая звонки только с проверенных телефонных номеров
Assign a static IP-address (Выделить постоянный IP-адрес)		Если это свойство разрешено, рабочей станции, с которой удаленно подключается рассматриваемый пользователь, назначается определенный IP-адрес. Статический IP-адрес может потребоваться, например, для нормальной работы специального программного обеспечения
Apply Static Routes (Использовать статическую маршрутизацию)		Если это свойство разрешено, можно определять ряд статических маршрутов IP, которые добавляются в таблицу маршрутизации сервера удаленного доступа после установки соединения. Этот параметр предназначен для учетных записей пользователей, с которыми работают маршрутизаторы Windows Server 2003 в случае маршрутизации с установкой соединения по требованию

<
/p> Настройка параметров учетной записи пользователя, используемых для конфигурирования удаленного доступа, выполняется на вкладке Dial-in (Входящие звонки) в окне свойств объекта, ассоциированного с учетной записью пользователя, в оснастке Active Directory Users and Computers (Active Directory — Пользователи и компьютеры). В случае автономного сервера удаленного доступа для конфигурирования аналогичных параметров учетной записи используется оснастка Local Users and Groups (Локальные пользователи и группы).

Опция Control access through Remote Access Policy (Управление на основе политики удаленного доступа) доступна только для серверов удаленного доступа, работающих под управлением Windows 2000 или Windows Server 2003. В случае сервера удаленного доступа, работающего под управлением Windows NT 4.0, в домене, находящемся на функциональном уровне "Windows 2000 native" или выше, данная опция будет автоматически заменяться опцией Deny Access (Запретить доступ). Это обусловлено тем, что сервер удаленного доступа Windows NT не поддерживает механизм политик удаленного доступа.

Стек протоколов AppleTalk

Клиенты, использующие стек протоколов AppleTalk, имеют фактически две возможности для получения удаленного доступа к ресурсам корпоративной сети:

 клиенты Apple Macintosh могут устанавливать соединение с сервером удаленного доступа Windows Server 2003, используя специальный протокол удаленного доступа ARAP из стека протоколов AppleTalk. При этом стек протоколов AppleTalk используется в качестве транспорта;

 клиенты Apple Macintosh могут устанавливать соединение с сервером удаленного доступа Windows Server 2003 при помощи протокола удаленного доступа РРР и транспортного стека протоколов AppleTalk. В такой конфигурации клиенты удаленного доступа получают параметры настройки AppleTalk от сервера удаленного доступа с использованием протокола управления АТСР, являющегося частью стека протоколов AppleTalk, как это определено в RFC 1378.

В Windows Server 2003 функциональные возможности удаленного доступа по протоколу AppleTalk реализованы исключительно для поддержки клиентов удаленного доступа Apple Macintosh. Клиент удаленного доступа Windows Server 2003 не может использовать стек протоколов AppleTalk для создания исходящего подключения.

Стек протоколов NWLink

В принципе, клиенты удаленного доступа на базе Windows Server 2003 могут использовать стек протоколов NWLink (IPX/SPX-совместимый стек протоколов) для доступа к ресурсам Novell NetWare. Напомним, однако, что это возможно только с использованием механизма сетевых подключений, создаваемых в папке Network Connections. Служба маршрутизации и удаленного доступа (RRAS) протокол IPX больше не поддерживает.

Стек протоколов TCP/IP

Стек протоколов TCP/IP — один из наиболее популярных транспортных протоколов. Его возможности маршрутизации и масштабирования предоставляют максимальную гибкость при организации корпоративной сети. Перед администратором имеются две проблемы, связанных с использованием стека протоколов TCP/IP для реализации удаленного доступа:

 выделение клиенту IP-адреса;

 разрешение имен.

Каждый удаленный компьютер, подключающийся к серверу удаленного доступа под управлением Windows Server 2003 при помощи РРР и TCP/IP, автоматически получает IP-адрес. Этот адрес может быть выделен DHCP-сервером или выбран из статического диапазона IP-адресов, назначенных серверу удаленного доступа администратором. Если сервер удаленного доступа использует для получения IP-адресов службу DHCP, то он запрашивает 10 IP-адресов от DHCP-сервера. Сервер удаленного доступа назначает себе первый IP-адрес, полученный от DHCP-сервера. Оставшиеся адреса распределяются между клиентами удаленного доступа по мере установления соединений. IP-адреса освобождаются после отключения клиентов и используются многократно. Когда сервер удаленного доступа использовал все 10 IP-адресов, он запрашивает еще 10 адресов. Если DHCP-сервер по каким-либо причинам оказывается недоступен, то сервер удаленного доступа автоматически генерирует IP-адреса в диапазоне от 169.254.0.1 до 169.254.255.254. Другой источник адресов — статический пул IP-адресов, который задается в виде IP-адреса и маски.

Для разрешения символических имен клиенты могут использовать следующие методы:

 для разрешения доменных имен — службу DNS и файл HOSTS;

 для разрешения NetBIOS-имен — службу WINS и файл LMHOSTS.

Серверы удаленного доступа поддерживают все эти методы разрешения имен. Сервер удаленного доступа предоставляет клиентам IP-адреса серверов DNS и WINS. Клиенты удаленного доступа в малых сетях, где IP-адреса не изменяются, могут использовать файлы HOSTS или LMHOSTS для разрешения имен. Кроме того, в небольших сетях администратор может активизировать механизм широковещательных запросов для разрешения имен (этот механизм мы рассматривали ранее в этой главе).

Телефония

В составе Windows Server 2003 реализован API-интерфейс телефонии (Telephony API, TAPI) версии 3.1, обеспечивающий функциональные возможности систем клиент-сервер. Благодаря данному интерфейсу прикладные телефонные программы на клиентском компьютере могут связываться с выделенным компьютером-сервером, который функционирует как шлюз с телефонным коммутатором. Интерфейс TAPI также является основой для реализации в прикладных программах различных функций телефонии (например, для набора номера, для переадресации звонков, для речевой почты, для идентификации звонящего, для организации средствами компьютеров конференц-связи).

Имеются две формы интеграции компьютера и телефонии: с применением технологий классической телефонии и IP-телефонии. Классическая телефония использует коммутируемые телефонные сети общего пользования (Public Switched Telephony Networks, PSTN), что обеспечивает создание клиент-серверных телефонных систем, а IP-телефония позволяет использовать компьютерную конференц-связь по локальным сетям (LAN), глобальным сетям (WAN), либо через Интернет. В состав Windows Server 2003 входит ряд стандартных служб доступа — поставщиков телефонных услуг, реализующих различные функции.

Рис. 14.28. Службы доступа к телефонии в Windows Server 2003

Перечень поддерживаемых поставщиков можно получить на вкладке Advanced (Дополнительно) окна Phone and Modem Options (Телефон и модем) (рис. 14.28).

Трансляция сетевых адресов (NAT)

Механизм трансляции сетевых адресов (Network Address Translation, NAT) осуществляет преобразование IP-адресов и номеров портов пакетов TCP и датаграмм UDP, которыми обмениваются локальная и внешняя (такая, как Интернет) сети. Наличие этого механизма позволяет организовать взаимодействие корпоративной сети с Интернетом простыми средствами, без привлечения специализированного программного обеспечения.

Преобразователь адресов в первую очередь разработан для подключения к открытым сетям (таким, как Интернет) небольших локальных сетей. Этот механизм не предназначен для соединения воедино нескольких разрозненных локальных сетей или подключения нескольких локальных сетей филиалов к общекорпоративной сети.

Транспортные протоколы и удаленный доступ

При развертывании в корпоративной сети службы удаленного доступа необходимо учитывать транспортные протоколы, используемые в настоящий момент в локальной сети — это может повлиять на планирование, интеграцию и настройку удаленного доступа. Удаленный доступ в Windows Server 2003 поддерживает транспортные протоколы TCP/IP, IPX/SPX и AppleTalk как указано в таблице:

Протоколы		Удаленный клиент Windows Server 2003, Windows XP или Windows 2000		Сервер удаленного доступа Windows Server 2003
TCP/IP		X		X
IPX		X		-
AppleTalk		-		X

Это означает, что можно интегрировать сервер удаленного доступа на базе Windows Server 2003 в существующую сеть Microsoft, UNIX, Apple Macintosh (по протоколу удаленного доступа РРР) или в сеть Apple Macintosh (по протоколу удаленного доступа ARAP). Клиенты удаленного доступа Windows Server 2003 могут также подключаться к серверам удаленного доступа по протоколу SLIP (вероятнее всего, на базе UNIX). При установке удаленного доступа любые протоколы, уже установленные на компьютере (TCP/IP и AppleTalk), автоматически разрешаются к использованию удаленного для доступа на входящих или исходящих подключениях. Для каждого выбранного стека протоколов требуется определить, будет ли открыт доступ к локальной сети или только к серверу удаленного доступа (по умолчанию разрешен доступ ко всей сети). Если предоставляется доступ к локальной сети с использованием стека протоколов TCP/IP, необходимо будет произвести дополнительную настройку клиента (например, определить IP-адрес).

Удаленный доступ

В самом простом приближении под корпоративной сетью принято понимать локальную сеть некоторой организации (или совокупность локальных сетей, соединенных между собой некоторым образом). Однако современные условия ведения бизнеса вносят свои поправки. Достаточно важной составляющей любой современной корпоративной сети являются пользователи, внешние по отношению к локальной сети. Это могут быть как мобильные пользователи (например, сотрудники корпорации, путешествующие с ноутбуками), так и стационарные (например, удаленный дилер компании). Важным является тот факт, что независимо от типа, этим пользователям периодически необходим доступ к ресурсам вашей корпоративной сети.

Данная проблема может быть решена посредством развертывания в корпоративной сети службы удаленного доступа (remote access service). Под удаленным доступом понимается решение, основанное на маршрутизации обращений подключающегося удаленного клиента в локальную сеть корпорации. Все приложения, посредством которых происходит доступ к ресурсам корпоративной сети, функционируют непосредственно на стороне клиента.

Следует также упомянуть про другую возможность организации доступа к ресурсам корпоративной сети — дистанционное управление (remote control). Под дистанционным управлением понимается решение, основанное на использовании удаленными пользователями программных и вычислительных ресурсов сервера. При этом также возможен доступ к ресурсам корпоративной сети. Однако все приложения, посредством которых этот доступ осуществляется, выполняются не на клиенте, а на сервере. Клиенту передаются только образы экрана. Данное решение реализуется при помощи служб терминалов (terminal services). Службы терминалов будут рассмотрены позднее, в главе 17 "Дополнительные сетевые службы".

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

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

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

 Проверка подлинности при помощи службы идентификации номера (DNIS-авторизация).

 Проверка подлинности при помощи автоматического определения номера (ANI/CLI-аутентификация).

 Вход в сеть под гостевой учетной записью.

Проверка подлинности при помощи службы идентификации номера

Служба идентификации номера (Dialed Number Identification Service, DNIS) осуществляет аутентификацию попытки соединения, основываясь на номере, набранном вызывающей стороной. Сервис DNIS возвращает телефонный номер, который был набран вызывающей стороной. Так, например, компания может предоставить своим клиентам специальный номер, по которому они могут всегда получить доступ к базе данных службы технической поддержки.

Эта услуга предоставляется большинством современных телефонных компаний (в США и других странах; в России ситуация отличается). Для распознавания DNIS-соединений и применения параметров, соответствующих соединению, необходимо разрешить доступ без проверки подлинности и создать политику удаленного доступа, которая использует идентификатор набранного номера (Called-Station-ID) в качестве условия авторизации клиента.

Проверка подлинности при помощи автоматического определения номера

Специальный сервис ANI/CLI (Automatic Number Identification/Calling Line Identification) позволяет выполнить аутентификацию соединения, основываясь на информации о телефонном номере вызывающей стороны. Сервис ANI/CLI возвращает номер вызывающей стороны. Так же как и в предыдущем случае, указанная услуга предоставляется большинством современных телефонных компаний (в США и других странах). Для распознавания ANI/CLI-соединений и применения параметров, соответствующих соединению, необходимо разрешить доступ без проверки подлинности и создать политику удаленного доступа, которая использует идентификатор вызывающей стороны (Calling-Station-ID) в качестве условия успешной аутентификации. Эта аутентификация отличается от аутентификации по идентификатору вызывающего пользователя (Caller-ID). В случае аутентификации по идентификатору вызывающего пользователя (Caller-ID) вызывающая сторона все равно должна предоставить информацию об имени пользователя и сопоставленном ему пароле. В случае же сервиса ANI/CLI передача имени и пароля не требуется.

Вход в сеть под гостевой учетной записью

Отдельно следует отметить возможность удаленного доступа к сети без необходимости прохождения процедуры аутентификации, когда для идентификации вызывающей стороны используется гостевая учетная запись. По умолчанию в процессе установки Windows Server 2003 всегда создается заблокированная изначально учетная запись Guest, которой предоставлены минимальные полномочия в системе. При этом вызывающей стороне не требуется как-либо идентифицировать себя (другими словами, вызывающая сторона не посылает серверу удаленного доступа имя пользователя или пароль).

При необходимости администратор может использовать любую учетную запись в качестве гостевой учетной записи. Для этого требуется отредактировать системный реестр сервера удаленного доступа. Гостевая учетная запись определяется параметром HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\RemoteAccess\Policy\Default User Identity.

Установка службы факсов

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

Для установки службы факсов можно выбрать задачу Set up faxing в окне Printers and Faxes или на панели управления выбрать опцию Add or Remove Programs и в мастере установки компонентов Windows (Add/Remove Windows Components Wizard) установить флажок напротив Fax Services и нажать кнопку Next (Далее) (рис. 14.21).

Рис. 14.21. Выбор установки службы факсов

В следующем окне мастер предложит выбрать — будет ли устанавливаемый факс доступен для сетевых пользователей или нет (в последнем случае предполагается, что пользоваться факсом могут только зарегистрировавшиеся локально пользователи) (рис. 14.22). Чтобы сделать факс доступным для сетевых пользователей, необходимо выбрать переключатель Share the fax printer (Сделать факс общим).

Рис. 14.22. Разрешение сетевым пользователям доступа к факсу

После установки службы факсов в папке Printers and Faxes (Принтеры и факсы) появляется команда Send a fax (Отправка факса), а в подменю Start | All Programs | Accessories | Communications (Пуск | Все программы \ Стандартные | Связь) — группа утилит Fax (Факс).

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

На сервере удаленного доступа под управлением Windows Server 2003 установленное сетевое оборудование отображается в виде ряда устройств и портов. Под устройством (devices) понимается аппаратное или программное обеспечение, которое предоставляет службе удаленного доступа порты для установки соединений "точка-точка". Различают устройства физические (такие, например, как модем) и виртуальные (например, VPN-подключение). Устройство может поддерживать как один порт (например, модем), так и несколько портов (например, модемный пул, способный предоставить 64 независимых входящих аналоговых коммутируемых соединения). Протоколы РРТР или L2TP — примеры виртуальных многопортовых устройств. Каждый из этих туннельных протоколов поддерживает несколько одновременных VPN-подключений.

Под портом (port) понимается отдельный канал устройства, способный поддерживать одно соединение "точка-точка". Для однопортовых устройств типа модема понятия "устройство" я "порт" совпадают. Для многопортовых устройств порт представляет собой часть устройства, посредством которого может быть установлено отдельное соединение "точка-точка". Например, адаптер ISDN имеет два В-канала. В этом случае адаптер ISDN рассматривается как устройство, а каждый В-канал как порт, поскольку соединение "точка-точка" может быть установлено раздельно по каждому из В-каналов.

Выбор схемы адресации

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

Частные адреса

Внутри корпоративной сети необходимо использовать IP-адреса, специально зарезервированные организацией InterNIC для частных IP-сетей (см. выше). По умолчанию механизм NAT выбирает адреса для частной сети из диапазона с идентификатором 192.168.0.0 и маской 255.255.255.0.

Если внутри корпоративной сети использовать адреса, не принадлежащие к диапазонам, определенным InterNIC, вполне может оказаться, что используется идентификатор IP-сети другой организации, имеющей выход в Интернет. Этот случай называется некорректной или накладывающейся (overlapping) IP-адресацией. В случае накладывающейся адресации доступ к ресурсам Интернета, использующим аналогичные адреса, становится невозможным. Например, если для адресации хостов в локальной сети используется подсеть 1.0.0.0 с маской подсети 255.0.0.0, то пользователи сети не смогут получить через NAT доступ к ресурсам Интернета с адресами из этого же диапазона.

Действительные адреса

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

Если был выдан ряд адресов, количество которых является степенью 2 (2, 4, 8, 16 и т. д.), имеется вероятность, что диапазон можно выразить при помощи одного IP-адреса и маски подсети. Например, если организации провайдером были выделены четыре действительных адреса 200.100.100.212, 200.100.100.213, 200.100.100.214 и 200.100.100.215, то их можно представить как один адрес 200.100.100.212 с маской подсети 255.255.255.252. В ситуации, когда IP-адреса нельзя выразить в виде IP-адреса и маски подсети, необходимо ссылаться на них как на диапазон или ряд диапазонов, указывая начальный и конечный IP-адреса.

Выбор схемы разрешения доменных имен

Помимо динамического выделения адресов хостам локальной сети, сервер удаленного доступа может выполнять разрешение доменных имен в локальной сети. Чтобы обеспечить подобную схему разрешения доменных имен, необходимо вызвать окно свойств контейнера NAT/Basic Firewall в пространстве имен оснастки Routing and Remote Access. В открывшемся окне следует перейти на вкладку Name Resolution (Разрешение имен) (рис. 14.15) и установить флажок Clients using Domain Name System (DNS) (Клиенты используют службу DNS).

Рис. 14.15. Включение разрешения доменных имен через механизм NAT

Зачастую требуется, чтобы соединение с Интернетом устанавливалось в тот момент, когда один из расположенных в частной сети хостов отправляет запрос на разрешение имени компьютеру с NAT. Чтобы реализовать подобную схему, необходимо установить флажок Connect to the public network when a name needs to be resolved (Подключаться к общей сети, когда требуется разрешение имени) и выбрать в списке Demand-dial interface (Интерфейс вызова по требованию) требуемый интерфейс.

Выбор схемы выделения IP-адресов локальным хостам

Сервер удаленного доступа, на котором активизирован механизм NAT, может осуществлять автоматическое конфигурирование локальных хостов посредством протокола DHCP. Чтобы разрешить подобную схему выделения IP-адресов хостам локальной сети, необходимо вызвать окно свойств контейнера NAT/Basic Firewall в пространстве имен оснастки Routing and Remote Access. В открывшемся окне надо перейти на вкладку Address Assignment (Выделение адресов) и установить флажок Automatically assign IP addresses by using the DHCP allocator (Автоматически назначать IP-адреса с использованием DHCP) (рис. 14.14). Поля IP address и Mask позволяют администратору задать номер подсети, к которой будут относиться конфигурируемые клиенты DHCP в локальной сети. При необходимости, нажав кнопку Exclude (Исключить), администратор может исключить некоторые адреса из этого диапазона.

Рис. 14.14. Разрешение использования протокола DHCP для выделения адресов локальным хостам

---

---