Серверная операционная система Microsoft Windows 2003
Коммуникационные службы
Данная глава посвящена рассмотрению основных коммуникационных служб, реализованных в Windows Server 2003. В первую очередь разговор пойдет о службе маршрутизации и удаленного доступа, позволяющей, в частности. внешним клиентам подключаться к корпоративной сети и использовать ее ресурсы. Здесь же рассматриваются организация виртуальных частных сетей, механизм трансляции сетевых адресов (NAT), а также служба факсов и IP-телефония.
Удаленный доступ
В самом простом приближении под корпоративной сетью принято понимать локальную сеть некоторой организации (или совокупность локальных сетей, соединенных между собой некоторым образом). Однако современные условия ведения бизнеса вносят свои поправки. Достаточно важной составляющей любой современной корпоративной сети являются пользователи, внешние по отношению к локальной сети. Это могут быть как мобильные пользователи (например, сотрудники корпорации, путешествующие с ноутбуками), так и стационарные (например, удаленный дилер компании). Важным является тот факт, что независимо от типа, этим пользователям периодически необходим доступ к ресурсам вашей корпоративной сети.
Данная проблема может быть решена посредством развертывания в корпоративной сети службы удаленного доступа (remote access service). Под удаленным доступом понимается решение, основанное на маршрутизации обращений подключающегося удаленного клиента в локальную сеть корпорации. Все приложения, посредством которых происходит доступ к ресурсам корпоративной сети, функционируют непосредственно на стороне клиента.
Следует также упомянуть про другую возможность организации доступа к ресурсам корпоративной сети — дистанционное управление (remote control). Под дистанционным управлением понимается решение, основанное на использовании удаленными пользователями программных и вычислительных ресурсов сервера. При этом также возможен доступ к ресурсам корпоративной сети. Однако все приложения, посредством которых этот доступ осуществляется, выполняются не на клиенте, а на сервере. Клиенту передаются только образы экрана. Данное решение реализуется при помощи служб терминалов (terminal services). Службы терминалов будут рассмотрены позднее, в главе 17 "Дополнительные сетевые службы".
Служба маршрутизации и удаленного доступа
В 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 является частью интегрированной Службы маршрутизации и удаленного доступа (Routing and Remote Access Service, RRAS). Пользователи устанавливают соединение с сервером удаленного доступа при помощи клиентского программного обеспечения удаленного доступа, которое имеется в составе любой версии Windows. Сервер удаленного доступа (под которым мы в дальнейшем подразумеваем любой компьютер под управлением Windows Server 2003, на котором установлена служба маршрутизации и удаленного доступа) аутентифицирует как пользователей, так и сеансы связи удаленных маршрутизаторов. Все службы, доступные пользователям, работающим в локальной сети (включая доступ к совместно используемым файлам и принтерам, доступ к вебсерверам и серверам электронной почты), доступны также и пользователям, подключающимся удаленно (через сервер удаленного доступа).
Клиент удаленного доступа использует стандартные средства для доступа к ресурсам. Например, на компьютере под управлением Windows XP подключение дисков и принтеров выполняется при помощи Проводника. Подключения постоянны: пользователи не должны повторно подключать сетевые ресурсы в течение сеанса удаленного доступа. Поскольку имена дисков и имена UNC (Universal Naming Convention, универсальное соглашение об именовании) полностью поддерживаются при удаленном доступе, большинство обычных действий пользователей и работа приложений остаются неизменными при работе через удаленный доступ.
в 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-трафиком между клиентами удаленного доступа и Интернетом или корпоративной сетью.
Устройства и порты службы удаленного доступа
|
Транспортные протоколы и удаленный доступ
При развертывании в корпоративной сети службы удаленного доступа необходимо учитывать транспортные протоколы, используемые в настоящий момент в локальной сети — это может повлиять на планирование, интеграцию и настройку удаленного доступа. Удаленный доступ в 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-адрес).
Стек протоколов 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 для разрешения имен. Кроме того, в небольших сетях администратор может активизировать механизм широковещательных запросов для разрешения имен (этот механизм мы рассматривали ранее в этой главе).
Стек протоколов NWLink
В принципе, клиенты удаленного доступа на базе Windows Server 2003 могут использовать стек протоколов NWLink (IPX/SPX-совместимый стек протоколов) для доступа к ресурсам Novell NetWare. Напомним, однако, что это возможно только с использованием механизма сетевых подключений, создаваемых в папке Network Connections. Служба маршрутизации и удаленного доступа (RRAS) протокол IPX больше не поддерживает.
Стек протоколов 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 для создания исходящего подключения.
Протоколы аутентификации пользователей
С точки зрения информационной безопасности любой удаленный пользователь должен быть аутентифицирован, прежде чем сможет получить доступ к ресурсам. Аутентификация происходит непосредственно при попытке клиента установить соединение с сервером удаленного доступа. Каждый пользователь, подключающийся удаленно к корпоративной сети, должен иметь на сервере или в каталоге 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);
Рассмотрим эти протоколы более подробно.
Протокол 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.
Протокол ЕАР
Протокол ЕАР (Extensible Authentication Protocol) представляет собой расширяемый механизм аутентификации, позволяющий унифицировать процесс проверки подлинности пользователей, предоставляя при этом участникам соединения возможность использования самых разнообразных схем аутентификации. Спецификация протокола ЕАР описывает способы подключения самых разнообразных схем аутентификации (в числе которых — смарт-карты, протокол RADIUS и т. п.). Можно рассматривать протокол ЕАР как универсальную платформу для реализации любых необходимых схем аутентификаций. Точная схема аутентификации, используемая участниками соединения, устанавливается в результате переговоров между клиентом удаленного доступа и сервером удаленного доступа.
Протокол ЕАР позволяет производить открытые переговоры между клиентом удаленного доступа и сервером удаленного доступа, состоящие из запросов сервера на получение аутентифицирующей информации и соответствующих ответов клиента. Например, если ЕАР используется совместно со смарт-картами, сервер удаленного доступа может отдельно запросить у клиента удаленного доступа название, PIN-код и емкость смарт-карты. Если на все вопросы получены удовлетворительные ответы, клиент удаленного доступа считается аутентифицированным и получает разрешение на удаленный доступ к сети.
Специальная схема проверки подлинности ЕАР называется типом ЕАР (ЕАР type). Для успешной проверки подлинности и клиент удаленного доступа, и сервер удаленного доступа должны поддерживать один и тот же тип ЕАР.
В Windows Server 2003 реализована поддержка двух типов ЕАР (EAP-MD5 CHAP и EAP-TLS). Однако при необходимости администратор может расширить функциональность протокола ЕАР, добавив поддержку других типов ЕАР. Для этого достаточно подключить соответствующие модули аутентификации. Необходимо, однако, помнить о том, что для успешной аутентификации соответствующий модуль должен быть подключен как на сервере удаленного доступа, так и на клиенте удаленного доступа.
Кроме того, в рамках Windows Server 2003 предусмотрена возможность передачи сообщений протокола ЕАР внутри сообщений протокола RADIUS (компонент БАР-RADIUS). Эта возможность может быть использована в ситуации, когда в сети эксплуатируется инфраструктура протокола RADIUS как основной механизм аутентификации. При этом инфраструктура RADIUS может быть использована для передачи сообщений протокола ЕАР.
Чтобы обеспечить проверку подлинности на базе ЕАР, необходимо:
разрешить ЕАР как протокол аутентификации на сервере удаленного доступа;
разрешить ЕАР, и, если требуется, настроить тип ЕАР для соответствующей политики удаленного доступа;
разрешить и настроить ЕАР на стороне клиента удаленного доступа.
Протокол CHAP
Протокол CHAP (Challenge Handshake Authentication Protocol) представляет собой механизм проверки подлинности типа "запрос-ответ", использующий схему хэширования MD-5 для необратимого преобразования пароля пользователя в уникальную последовательность символов. Оба участника соединения выполняют подобное преобразование. Благодаря этому по сети передается не сам пароль, а только хэшированная последовательность. Сервер сравнивает полученную последовательность с собственной копией и только в случае идентичности последовательностей пользователь считается аутен-тифицированным. В качестве одного из присущих протоколу недостатков можно отметить отсутствие механизмов взаимной аутентификации всех участников соединения.
Протокол аутентификации CHAP является стандартом Интернета (RFC 1994) и поддерживается множеством производителей программного обеспечения. В среде Windows Server 2003 протокол CHAP может быть использован для аутентификации клиентов удаленного доступа сторонних производителей.
Протоколы MS-CHAP и MS-CHAP v2
Протокол 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 ключ шифрования основывается на пароле пользователя и произвольной строке запроса. Каждый раз, когда пользователь подключается с тем же самым паролем, используется другой ключ |
|
Используется единый ключ шифрования для данных, передаваемых в обоих направлениях соединения |
Используются отдельные ключи шифрования, которые генерируются для передаваемых и получаемых данных |
Протокол SPAP
Протокол аутентификации SPAP (Shiva Password Authentication Protocol) использует для шифрования паролей реверсивный механизм шифрования Shiva. В среде Windows Server 2003 протокол SPAP может быть использован для организации соединений с Shiva LAN Rover. Эта схема проверки подлинности более безопасна, чем передача данных открытым текстом, но менее безопасна, чем CHAP или MS-CHAP. Связано это с тем, что протокол SPAP не предусматривает защиты от перехвата зашифрованных паролей, которые впоследствии могут быть использованы для несанкционированного доступа в систему (один и тот же пароль при выполнении операции шифрования будет давать одну и ту же последовательность).
Протокол РАР
Протокол PAP (Password Authentication Protocol) использует пароли, передаваемые открытым текстом, и является самым простым протоколом проверки подлинности пользователей. Обычно соединение на его основе устанавливается, если клиент удаленного доступа и сервер удаленного доступа не могут договориться о более безопасной форме проверки подлинности.
Протокол РАР предполагает передачу паролей пользователей открытым текстом. Всякий, кто перехватит пакеты процесса аутентификации, может легко прочитать пароль и использовать его для несанкционированного доступа к корпоративной сети. Фактически протокол РАР используется только в том случае, когда клиент и сервер удаленного доступа не поддерживают никаких других протоколов аутентификации. В этой ситуации передача пароля открытым текстом является единственной возможностью подтвердить полномочия пользователя.
С другой стороны, запретив использование протокола РАР, можно быть уверенным в том, что пароли пользователей никогда не будут передаваться по сети открытым текстом. Отключение протокола РАР позволит сделать процесс аутентификации более защищенным. Однако клиенты удаленного доступа, поддерживающие только протокол РАР, не смогут установить соединение с вашим сервером удаленного доступа.
Процедура аутентификации удаленного доступа
Аутентификация пользователей, подключающихся к серверу удаленного доступа под управлением Windows Server 2003, выполняется по следующему сценарию:
1. Клиент удаленного доступа инициирует процесс подключения к серверу удаленного доступа (например, набирает его телефонный номер).
2. Происходит физическое соединение (например, двух модемов).
3. Сервер отправляет запрос клиенту с требованием предоставить информацию о полномочиях подключающегося пользователя.
4. Клиент отправляет ответ серверу, в который включает запрашиваемую информацию. В зависимости от используемого протокола аутентификации, ответ пересылается по сети либо в открытом, либо в зашифрованном виде.
5. Сервер проверяет информацию, содержащуюся в ответе, обращаясь к каталогу Active Directory. В случае автономного сервера удаленного доступа для проверки полномочий пользователя используется локальная база данных учетных записей сервера.
6. Если учетная запись существует и не заблокирована, сервер принимает решение об установлении соединения в соответствии с политикой удаленного доступа и свойствами учетной записи пользователя для клиента удаленного доступа.
7. Если разрешена функция ответного вызова, сервер вызывает клиента и продолжает переговоры о соединении.
Процесс аутентификации предполагает проверку подлинности пользователя. Тем не менее, сам факт успешного прохождения процедуры аутентификации не означает, что пользователь автоматически получает доступ к корпоративной сети. После аутентификации удаленного пользователя и подключения клиента к корпоративной сети клиент удаленного доступа может обращаться только к тем сетевым ресурсам, для которых он имеет соответствующее разрешение. Клиенты удаленного доступа подчиняются общим принципам разграничения доступа Windows Server 2003 точно так же, как если бы они физически располагались в локальной сети. Другими словами, клиенты удаленного доступа не могут выполнять какие-либо действия, не имея достаточных на то полномочий, и не могут обращаться к ресурсам, для которых они не имеют соответствующих разрешений.
Можно ограничить клиента удаленного доступа доступом только к общим ресурсам сервера удаленного доступа, а не к ресурсам всей сети, к которой подключен сервер удаленного доступа. Администратор может управлять тем, какая информация будет доступна клиентам удаленного доступа, и ограничивать доступ пользователей в случае нарушения защиты.
Дополнительные механизмы проверки подлинности удаленного пользователя
В большинстве случаев для обеспечения безопасности удаленного подключения вполне достаточно использовать протоколы аутентификации, поддерживающие шифрованный обмен данными. В исключительных ситуациях, когда удаленному пользователю предоставляется доступ к критически важной информации, администратор может задействовать дополнительные механизмы проверки подлинности удаленного пользователя, предоставляемые Windows Server 2003:
проверка идентификатора звонящего абонента (Caller ID);
ответный звонок (Callback).
Проверка идентификатора звонящего абонента
Активизировав режим проверки идентификатора звонящего абонента (Caller ID), администратор может задать телефонный номер, с которого определенному пользователю разрешено осуществлять удаленное подключение. В процессе подключения информация о номере, с которого производится звонок, передается серверу удаленного доступа. Сервер проверяет идентификатор звонящего абонента с тем, что указан в настройках учетной записи пользователя. Если пользователь производит попытку соединения с другого номера, сервер удаленного доступа отклоняет ее.
Режим проверки идентификатора звонящего абонента должен поддерживаться всеми участниками удаленного подключения (вызывающей стороной,
телефонной сетью между вызывающей стороной и сервером удаленного доступа, а также сервером удаленного доступа). Поддержка указанного режима на стороне сервера удаленного доступа включает в себя, прежде всего, оборудование, отвечающее на вызов клиента. Это оборудование должно поддерживать передачу идентификатора звонящего абонента соответствующему встроенному драйверу Windows Server 2003, который, в свою очередь, поддерживает передачу идентификатора вызывающей стороны службе маршрутизации и удаленного доступа.
В случае, когда режим активизирован, но какая-то часть оборудования или программного обеспечения его не поддерживает, то устанавливающему соединение пользователю будет отказано в доступе.
Режим проверки звонящего абонента позволяет обеспечить большую степень безопасности для организации труда надомных работников (telecommuters). Недостаток описанного механизма заключается в том, что пользователь может получить удаленный доступ только с конкретной телефонной линии. Необходимо, однако, иметь в виду, что в России данная функциональная возможность недоступна на большинстве телефонных станций, кроме современных цифровых станций, устанавливаемых взамен старых, или коммерческих провайдеров телефонных услуг.
Механизм ответного вызова
Механизм ответного вызова (callback) представляет собой альтернативу проверки идентификатора звонящего абонента, позволяя серверу удаленного доступа убедиться в подлинности абонента, устанавливающего соединение. Получив звонок от клиента, сервер разрывает соединение ("вешая трубку") и осуществляет ответный вызов по номеру, определенному звонящим пользователем или заданному администратором. После того как клиент ответит, процесс установки соединения продолжится.
Сервер осуществляет обратный звонок только по окончании процедуры аутентификации и авторизации клиента. Другими словами, ответный звонок производится сервером только после того, как будут установлены подлинность пользователя и его полномочия на удаленное подключение.
Механизм ответного вызова активизируется на уровне отдельных пользователей (при условии, что им предоставлено разрешение удаленного доступа). Для каждого пользователя администратор может определить один из трех режимов.
No callback (Нет ответного вызова). В данном режиме ответный звонок не производится. Сервер удаленного доступа устанавливает соединение сразу по окончании процедур аутентификации и авторизации.
Set by caller (Устанавливается вызывающей стороной). Эта функция не повышает защищенность удаленного доступа, она полезна для клиентов, которые звонят из разных мест (регионов, городов, стран) и с разных телефонных номеров, снижая их затраты. Когда запрос на ответный вызов обрабатывается сервером удаленного доступа, происходят следующие события:
сначала сервер определяет, являются ли имя пользователя и пароль верными;
в случае успешного окончания процедуры аутентификации, на компьютере пользователя появляется диалоговое окно Callback (Ответный вызов);
пользователь должен указать в диалоговом окне свой текущий номер телефона для ответного вызова. Этот номер передается серверу;
запрос на ответный вызов закончен, связь разрывается;
сервер производит звонок клиенту по предоставленному им номеру ответного вызова;
после того как связь повторно установлена, клиент и сервер продолжают переговоры по установлению соединения.
Always callback to (Всегда осуществлять ответный вызов по заданному номеру). Этот вариант наиболее приемлем для реализации дополнительного уровня защиты. Необходимо выбрать его и ввести номер телефона, с которым связано оборудование удаленного доступа пользователя. Когда запрос пользователя поступает на сервер удаленного доступа, происходят следующие события: сервер выполняет аутентификацию пользователя, запрашивающего удаленное соединение; связь разрывается, сервер производит звонок клиенту по номеру ответного вызова, определенному в рамках его учетной записи; после того как связь повторно установлена, клиент и сервер продолжают переговоры по установлению соединения.
Удаленный доступ без выполнения процедуры аутентификации пользователя
Администратор может организовать удаленный доступ к корпоративной сети без необходимости выполнения аутентификации пользователя. Процедура аутентификации предполагает передачу клиентом серверу информации о полномочиях пользователя. В описываемом сценарии подобной передачи не происходит.
Имеется три способа организации удаленного доступа без выполнения процедуры аутентификации пользователя.
Проверка подлинности при помощи службы идентификации номера (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.
Блокировка учетной записи
Архитектура системы безопасности предусматривает возможность блокирования учетной записи удаленного пользователя (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 использует собственный механизм шифрования "точка-точка" (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 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 в случае маршрутизации с установкой соединения по требованию |
Настройка параметров учетной записи пользователя, используемых для конфигурирования удаленного доступа, выполняется на вкладке
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 не поддерживает механизм политик удаленного доступа.
Политики удаленного доступа
В 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) группы независимо от их области действия (доменной или локальной) |
Рис. 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) среде передачи. Если попытка соединения по коммутируемой среде не соответствует настройке, она отклоняется. По умолчанию это свойство не установлено, и сервер удаленного доступа разрешает все типы устройств передачи данных |
В 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), система применяет профиль удаленного доступа. Соединение будет установлено только в случае, когда параметры соединения удовлетворяют требованиям профиля удаленного доступа.
Протоколирование событий
Требования политики безопасности большинства предприятий предполагают регистрацию всех событий, связанных с действиями удаленных пользователей в рамках корпоративной сети. Сервер удаленного доступа 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.
Использование широковещательных рассылок для разрешения имен
Сервер удаленного доступа под управлением Windows Server 2003 предоставляет возможность удаленным клиентам использовать широковещательные рассылки для разрешения доменных и NetBIOS-имен ресурсов, расположенных в корпоративной сети. Реализации сервера удаленного доступа в предыдущих версиях Windows допускают только один способ разрешения имен для клиентов удаленного доступа — использование серверов имен. В небольших сетях использование широковещательных рассылок избавляет администратора от необходимости развертывания серверов имен.
Широковещательные рассылки поддерживаются сервером удаленного доступа Windows Server 2003 по умолчанию. При этом реализуется следующая схема разрешения имен:
1. Клиент удаленного доступа предпринимает попытку разрешить некоторое имя, отправляя широковещательное сообщение через все имеющиеся сетевые интерфейсы (в том числе и через тот, что используется для соединения с сервером удаленного доступа).
2. Сервер удаленного доступа получает широковещательный запрос на разрешение имени и проверяет собственный кэш имен на предмет наличия отображения необходимого имени на соответствующий IP-адрес. Если отображение найдено в кэше, информация о соответствующем IP-адресе будет возвращена клиенту. В противном случае широковещательный запрос будет ретранслирован сервером удаленного доступа через все локальные интерфейсы. Полученный сервером ответ будет возвращен клиенту удаленного доступа. При этом полученное отображение будет помещено в локальный кэш имен сервера удаленного доступа. Использование кэша позволяет избежать широковещательных обращений к ресурсам сети в случае, если другие клиенты обратятся с запросами на разрешение аналогичного имени.
3. Клиент удаленного доступа использует полученный IP-адрес для установки соединения с требуемым ресурсом.
Следует заметить, что механизм ретрансляции широковещательных запросов, активизированный на сервере удаленного доступа под управлением Windows Server 2003, доступен только клиентам удаленного доступа. Этот механизм позволяет выполнять разрешение имен методом широковещательных рассылок только для ресурсов локальной сети. Этот механизм не может быть использован клиентом, расположенным в локальной сети, для того, чтобы разрешить имя клиента удаленного доступа. Другими словами, механизм работает только в одну сторону.
Применение разделяемых ключей
Протокол туннелирования L2TP использует для шифрования пакетов протокол сетевого уровня IPSec. Применение протокола IPSec имеет свои характерные особенности. В частности, протокол содержит механизмы взаимной аутентификации всех участников соединения. В отличие от предыдущих версий, Windows Server 2003 предлагает два способа реализации этого процесса.
Использование цифровых сертификатов. Каждый из участников соединения получает специальный цифровой сертификат, который и используется для проверки его подлинности. Эта схема проверки подлинности гарантирует наиболее гибкую систему обеспечения безопасности. Однако от администратора в этом случае требуется развертывание в сети корпоративной службы сертификатов (Public Key Infrastructure, PKI) или конфигурирование хостов на работу с внешними службами сертификатов.
Использование разделяемых ключей. Под разделяемым ключом (pre-shared key) понимается некоторая последовательность символов (в формате Unicode), известная серверу удаленного доступа и клиенту. Для успешной аутентификации каждая из сторон должна подтвердить знание разделяемого ключа. Основным достоинством данного метода аутентификации является простота его реализации. Теперь, чтобы иметь возможность использовать протокол туннелирования L2TP, администратору не требуется развертывать в корпоративной сети систему сертификатов. Существенным недостатком, серьезно ограничивающим возможность применения данной схемы аутентификации, является использование единого общего разделяемого ключа для всех удаленных клиентов. Другими словами, все клиенты удаленного доступа, использующие протокол L2TP, должны быть сконфигурированы для использования одного и того же разделяемого ключа. Помимо того, что подобная схема аутентификации делает всю систему весьма уязвимой, в случае необходимости изменения ключа администратор должен выполнить переконфигурирование всех клиентов удаленного доступа.
Проблема автоматического изменения разделяемых ключей может быть решена администратором путем использования специального диспетчера подключений (Connection Manager). Если пользователи используют профили, создаваемые посредством этого диспетчера, изменение ключа будет выполнено автоматически после того, как обновленная версия профиля будет развернута пользователями на своих клиентских компьютерах.
Использование сервера удаленного доступа для обслуживания 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, необходимо соответствующим образом сконфигурировать службу маршрутизации и удаленного доступа (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. Выбор способа аутентификации клиентов удаленного доступа
Трансляция сетевых адресов (NAT)
Механизм трансляции сетевых адресов (Network Address Translation, NAT) осуществляет преобразование IP-адресов и номеров портов пакетов TCP и датаграмм UDP, которыми обмениваются локальная и внешняя (такая, как Интернет) сети. Наличие этого механизма позволяет организовать взаимодействие корпоративной сети с Интернетом простыми средствами, без привлечения специализированного программного обеспечения.
Преобразователь адресов в первую очередь разработан для подключения к открытым сетям (таким, как Интернет) небольших локальных сетей. Этот механизм не предназначен для соединения воедино нескольких разрозненных локальных сетей или подключения нескольких локальных сетей филиалов к общекорпоративной сети.
Компоненты механизма трансляции сетевых адресов
Механизм трансляции сетевых адресов включает в себя следующие элементы:
компонент преобразования. В этом качестве рассматривается компьютер (далее называемый компьютер-преобразователь адресов), выступающий в
качестве транслятора сетевых адресов (NAT). Именно транслятор сетевых адресов является тем компонентом, который собственно и выполняет преобразование IP-адресов и номера портов пакетов TCP и датаграмм UDP, передаваемых между локальной сетью и внешней сетью;
компонент адресации. Компьютер, выступающий в качестве транслятора сетевых адресов, предоставляет информацию о конфигурации IP-адреса другим компьютерам домашней сети. Компонент адресации представляет собой упрощенный DHCP-сервер, предоставляющий клиентам сведения о IP-адресе, маске подсети, IP-адресе шлюза по умолчанию, DNS-сервера (в качестве последних двух адресов используется IP-адрес непосредственно самого транслятора сетевых адресов). Все компьютеры в локальной сети (являющиеся клиентами NAT) должны быть сконфигурированы как клиенты DHCP, чтобы автоматически получать конфигурацию IP;
компонент разрешения имен. Компьютер с преобразователем адресов становится DNS-сервером и WINS-сервером для других компьютеров в домашней сети. Когда компьютер с преобразователем адресов получает запросы о разрешении имен, он пересылает запросы о разрешении имен серверам DNS и WINS в межсетевой среде, на которые он настроен, и возвращает ответы на компьютер в локальной сети.
Понятие частного адреса
Архитектура стека протоколов 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 выполняет их трансляцию в частные адреса.
Принципы действия 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
Редакторы 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, но и служебной информации в теле пакетов.
Развертывание механизма NAT в корпоративной сети
Рассмотрим процесс развертывания в корпоративной среде механизма NAT. Прежде чем приступить к конфигурированию службы маршрутизации и удаленного доступа (Routing and Remote Access Service), администратор должен выполнить ряд подготовительных операций.
Выбор схемы адресации
Для функционирования механизма 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-адреса.
Использование базового брандмауэра
В рамках сервера удаленного доступа Windows Server 2003 реализован базовый брандмауэр (basic firewall), представляющий собой механизм динамической фильтрации пакетов. Брандмауэр является одним из механизмов обеспечения безопасности периметра сети, ограничивая трафик через сетевой интерфейс определенными типами пакетов. Администратор может разрешить прохождение через сетевой интерфейс (как правило, тот, что используется для подключения корпоративной сети к внешней сети) пакетов определенного типа, запретив прохождение всех остальных. Новым в Windows
Server 2003 является возможность интеграции брандмауэра с механизмом NAT. Администратор может активизировать этот брандмауэр для сетевого интерфейса, используемого механизмом NAT в качестве точки взаимодействия с открытой сетью.
Базовый брандмауэр, реализованный в рамках сервера удаленного доступа Windows. Server 2003, может быть активизирован только для сетевого интерфейса, подключенного к внешней сети (такой, как Интернет).
В случае интеграции механизма NAT с базовым брандмауэром процесс трансляции адресов осуществляется следующим образом. Вся информация об отправителях и получателях пакетов заносится в специальную таблицу. Весь трафик, проходящий через рассматриваемый сетевой интерфейс, сравнивается с содержимым этой таблицы. Брандмауэр пропустит пакеты только для тех соединений, что были установлены хостами корпоративной сети. Остальные пакеты будут отброшены. Фактически подобная интеграция позволяет реализовать защиту корпоративной сети от проникновения в нее нежелательного внешнего трафика.
Разрешение входящего соединения
Механизм NAT может быть использован не только для организации доступа внутренних пользователей к ресурсам сети Интернет. Администратор может настроить механизм NAT таким образом, чтобы предоставить возможность внешним пользователям получать доступ к ресурсам локальной сети. Например, можно предоставить доступ внешним пользователям к ресурсам корпоративного веб-сервера, располагающегося внутри корпоративной сети. В данном случае принято говорить о входящем соединении (inbound connection).
Для обслуживания входящих соединений локальный хост, к ресурсам которого планируется предоставить доступ внешним пользователям, должен иметь статическую конфигурацию стека протоколов TCP/IP. Другими словами, информация о параметрах стека протоколов должна быть статически прописана администратором. Хосту должен быть предоставлен постоянный IP-адрес и определена маска подсети, определен шлюз по умолчанию (частный IP-адрес сервера удаленного доступа, на котором функционирует NAT) и сервер DNS (частный IP-адрес компьютера с NAT). Предоставленный хосту IP-адрес должен быть исключен из диапазона адресов, распределяемых сервером удаленного доступа с NAT.
После этого на сервере удаленного доступа необходимо настроить специальный порт. Специальный порт представляет собой статическое отображение действительного адреса и номера порта в частный адрес и номер порта. Специальный порт отображает входящее соединение от пользователя из Интернета в специфический адрес в частной сети.
Конфигурирование механизма 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 без использования специального мастера конфигурирования. Если интерфейс, обеспечивающий подключение к Интернету (например, соединение по требованию), уже имеется, то необходимо выполнить следующую последовательность действий:
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 (Частный интерфейс, подключенный к частной сети).
Выбор схемы выделения 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 для выделения адресов локальным хостам
Выбор схемы разрешения доменных имен
Помимо динамического выделения адресов хостам локальной сети, сервер удаленного доступа может выполнять разрешение доменных имен в локальной сети. Чтобы обеспечить подобную схему разрешения доменных имен, необходимо вызвать окно свойств контейнера 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, администратор должен задать для каждого сетевого интерфейса диапазоны IP-адресов, которые будут использоваться данным механизмом для выполнения преобразования. Эта операция выполняется на вкладке Address Pool (Пул адресов) в окне свойств открытого сетевого интерфейса (рис. 14.16). Нажмите кнопку
Add (Добавить) и в открывшемся окне задайте диапазон адресов. Диапазон определяется начальным адресом и маской подсети. При необходимости скорректируйте конечный адрес диапазона.
Рис. 14.16. Определение диапазона IP-адресов для преобразования
Если имеется несколько интервалов адресов, можно добавить каждый из них отдельно, нажав кнопку Add (Добавить).
Конфигурирование базового брандмауэра
Как уже упоминалось ранее, в рамках сервера удаленного доступа 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. Например, администратор может определить порядок трансляции пакетов, приходящих на порт 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 (Адрес в частной сети).
Конфигурирование хостов в локальной сети для работы с NAT
Хосты локальной сети также нуждаются в дополнительном конфигурировании. Каждый хост, который будет использовать механизм NAT, должен иметь соответствующую (согласованную с конфигурацией NAT) настройку стека протоколов TCP/IP:
IP-адрес, принадлежащий к разрешенному диапазону частных адресов. В рассматриваемом нами примере он должен относиться к сети с идентификатором 192.168.0.0 и маской 255.255.255.0;
маска подсети (255.255.255.0);
в качестве шлюза по умолчанию должен быть указан IP-адрес локального сетевого интерфейса компьютера-преобразователя;
в качестве DNS-сервера должен быть указан IP-адрес локального сетевого интерфейса компьютера-преобразователя;
в качестве WINS-сервера должен быть указан IP-адрес локального сетевого интерфейса компьютера-преобразователя.
Служба факсимильных сообщений
В 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) полученных и отправленных факсимильных сообщений.
Установка службы факсов
Служба факсов не устанавливается по умолчанию в ходе инсталляции операционной системы. Администратор должен установить ее самостоятельно, предварительно подключив к серверу факс-модем и настроив его соответствующим образом.
Для установки службы факсов можно выбрать задачу 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 (Факс).
Конфигурирование службы факсов
При первом запуске оснастки 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.
Использование службы факсов
Основные возможности службы факсов перечислены ниже.
Передача сообщения на титульном листе. Служба факсов позволяет передавать сообщения на титульном листе факса отдельно от документа. Используя утилиту
Fax Cover Page Editor (Редактор титульных страниц факсов), администратор может создать любой титульный лист в соответствии с желаниями пользователя либо выбрать один из имеющихся шаблонов титульных листов. Мастер рассылки факсов автоматически вносит информацию о получателе и отправителе, нужно только ввести примечание и отослать факсимильное сообщение.
Контроль процесса передачи факсов. Администратор может осуществлять контроль процесса передачи факсов (в том числе отслеживать ошибки) при помощи специальной утилиты
Fax Monitor (Монитор факсов). Эта утилита вызывается из оснастки Fax Console (Консоль факсов) путем выбора одноименной команды в меню
Tools (Сервис).
Передача факсов из почтовых программ. Служба факсов работает также с некоторыми версиями Microsoft Exchange или Microsoft Outlook. В Outlook, например, можно передавать сообщения электронной почты и присоединенные документы получателям факсов. Необходимо настроить службу факсов, чтобы она работала с соответствующей учетной записью пользователя в Outlook. Для этого в программе Outlook нужно в настройках профиля пользователя на вкладке
Services (Службы) добавить Fax Mail Transport (Почтовый транспорт факсов).
Прием факсимильных сообщений. Службу можно настроить для автоматического приема факсов, их сохранения на диске и печати на указанном принтере или автоматической передачи по электронной почте.
Редактор титульных страниц факсов
Утилита 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 (Мои документы) после установки службы факсов. При необходимости можно отредактировать скопированный титульный лист (при этом оригинал не будет изменен).
Диспетчер службы факсов
В составе службы факсов Windows Server 2003 поставляется специальная утилита Fax Service Manager (Диспетчер службы факсов) (рис. 14.26). Эта утилита предназначена для централизованного управления серверами, на которых установлены службы факсов. Администратор может использовать данную утилиту для следующих целей:
управление службой факса;
конфигурирование факс-модемов и управление ими;
управление входящими и исходящими правилами маршрутизации факсов;
конфигурирование режима протоколирования событий, связанных с отправкой факсов и функционированием службы факсов;
управление очередями исходящих и входящих факсов;
Рис. 14.26. Оснастка Fax Service Manager
управление разрешениями, правами владения и аудитом; конфигурирование режима архивирования; конфигурирование параметров передачи факсов.
Настройка принтера факсов
Как уже говорилось, для настройки параметров факса используется Мастер настройки факсов, с помощью которого можно задать как сведения об отправителе, так и параметры работы факсов. Эти параметры можно в любой момент просмотреть и/или изменить с помощью команды
Tools | Sender Information (Сервис | Сведения об отправителе), вызываемой из оснастки
Fax Console (Консоль факсов), а также с помощью утилиты Fax Service Manager. Параметры окна свойств факса во многом аналогичны параметрам окна свойств обычных принтеров. Исключение составляют параметры, перечисленные на вкладке
Tracking (Отслеживание) (рис. 14.27).
Данная группа параметров позволяет настроить механизм отслеживания основных этапов передачи факсов.
Рис. 14.27. Вкладка Tracking окна свойств факса
Телефония
В составе 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).
IР-телефония
В организациях обычно поддерживаются раздельные сети для передачи голоса, данных и видеоинформации. Поскольку все сети имеют различные транспортные требования и физически независимы, их установка, поддержка и реорганизация обходятся дорого. IP-телефония объединяет сети передачи голоса, видео и данных, используя общий транспорт IP для каждого из потоков, по-настоящему собирая отдельные сети в единую технологическую цепь.
Клиенты IP-телефонии используют телефон, подключенный к адаптеру PSTN, либо существующие аппаратные средства мультимедиа. IP-телефония поддерживает телефонную, звуковую и видеоконференц-связь, голосовую и видеопочту, а также службы видео по требованию (video on-demand). Возможности IP-телефонии могут эффективно использоваться средством Remote Assistance, а также программой Windows Messenger.
Поставщики услуг IP-телефонии
Интерфейс TAPI поддерживает стандарт Н.323 и стандарт групповой конференц-связи IP при помощи соответствующих служб Windows Server 2003. Стандарт Н.323 представляет собой всеобъемлющий стандарт ITU для передачи мультимедиа (голоса, видео и данных) по сетям без установления логического соединения, например, по IP-сетям и Интернету, которые не обеспечивают гарантированное качество обслуживания (QoS). Стандарт описывает управление вызовом, мультимедиа и шириной полосы пропускания для двухточечных и многоточечных конференций. Н.323 поддерживает стандартные звуковые и видеокодеры и декодеры и обеспечивает поддержку совместного использования данных по стандарту Т. 120. Н.323 — стандарт, не зависящий от сети, платформы и прикладного уровня, что позволяет любому терминалу, соответствующему Н.323, взаимодействовать с любым другим терминалом.
Групповая конференц-связь по IP
Поставщик услуг групповой конференц-связи IP (IP Multicast Conferencing Service Provider) — расширение для IP, позволяющее осуществлять эффективную групповую связь группы по LAN. При наличии группового IP-протокола пользователи посылают только одну копию данных группе IP-адресов для достижения всех получателей, которые хотят получить данные, с использованием самых коротких деревьев для определения пути. Без использования многоадресного вещания те же самые данные необходимо было бы передавать по сети несколько раз, по одной копии для каждого получателя, или передать широковещательно каждому пользователю в сети, что заняло бы полосу пропускания и время на обработку и передачу данных.
