WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |   ...   | 13 |

«Internetworking Guide Microsoft Windows 2000 Server R Microsoft Press Межсетевое взаимодействие Microsof Windows 2000 Server ...»

-- [ Страница 7 ] --

Тип запрашиваемого сервиса. Примеры типов — Framed (для Service-Type' РРР-соедипений) и Login (для Telnet-соединении). Подробнее о типах сервисов RADIUS см. RFC 2138. Этот атрибут пред назначен для сервера IAS.

Тип разбиения на кадры входящих пакетов. Примеры — РРР, Framed-Pro tocol SLIP. Frame Relay и Х.25. Этот атрибут предназначен для сер вера IAS.

Телефонный номер NAS. Этот атрибут представляет собой Called-Station-ID строку символов. Для задания кодов областей можно использо вать синтаксис с. подстановкой по шаблону. Чтобы получать информацию об идентификаторе вызываемой станции в про цессе вызова, телефонная линия, оборудование и его драйвер должны поддерживать передачу такого идентификатора. В ином случае идентификатор вызываемой станции настраивает ся вручную для каждого порта.

Телефонный номер звонящего. Этот атрибут представляет со Cal!ing-Station-ID бой строку символов. Для задания кодов областей можно ис пользовать синтаксис с подстановкой по шаблону.

Тип несущей среды, используемой звонящим. Примеры — ана NAS-Port-Type логовые телефонные линии (также называемые «asyno), ISDN и туннели (или VPN').

День недели и время суток, когда принимается запрос на со Day-and-Time-Restrictions единение.

IP-адрес NAS (RADlUS-клиепта). Этот атрибут представляет Ciient-IP-Address собой строку символов, передаваемую серверу IAS. Для зада ния набора IP-сетей используется синтаксис с подстановкой пи шаблону.

(см. след, стр.} Удаленный доступ 318 ЧАСТЬ Таблица 8-3. (продолжение) Описание Атрибут Изготовитель (вендор) сервера доступа в сеть (NAS), запраши N AS-Manufacturer вающего аутентификацию. Сервер удаленного доступа Windows 2000 обозначается как Microsoft RAS NAS, Этот атри бут позволяет настраивать разные политики для разных изго товителей серверов NAS, являющихся RADIUS-клиентами сервера IAS. Атрибут NAS-Manufacturer предназначен для сер вера IAS.

Имя компьютера RADIUS-клиента, запрашивающего аутенти Client-Friendly-Name фикацию. Этот атрибут представляет собой строку символов, передаваемую серверу IAS. Для задания нескольких имен кли ентов можно использовать синтаксис с подстановкой по шаб лону.

Имена Windows-групп, в которые входит пользователь, выдав Windows-Groups ший запрос на удаленное соединение. Атрибута, который по зволял бы указывать имя конкретного пользователя, нет. Со здавать отдельную политику удаленного доступа для каждой группы не обязательно. Вместо этого можно использовать вло женные группы. Для сервера удаленного доступа или сервера IAS, входящего в домен Windows 2000 основного режима, реко мендуется применять универсальные группы.

Tunnel-Type Тип туннеля, создаваемого клиентом. Примеры типов тунне лей — РРТР и L2TP, используемые клиентами удаленного дос тупа и маршрутизаторами с соединением по требованию. Этот атрибут позволяет указывать такие параметры профиля, как методы аутентификации и шифрования для определенного типа технологии туннелирования.

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

Учтите также, что не каждый сервер NAS поддерживает все атрибуты, предназна ченные для серверов IAS.

Для атрибута Windows-Groups нельзя использовать встроенные локальные группы на автономном сервере удаленного доступа под управлением Windows 2000.

Remote Access Permission (Разрешение на удаленный доступ) Если все условия политики удаленного доступа выполняются, клиенту либо пре доставляется, либо не предоставляется разрешение на удаленный доступ. Это за висит от того, какой переключатель в свойствах политики выбран — Grant remote access permission (Предоставить право удаленного доступа) иди Deny remote access permission (Отказать в праве удаленного доступа).

Разрешение на удаленный доступ, заданное в учетной записи пользователя, имеет преимущество перед разрешением на удаленный доступ, указанным в политике уда ленного доступа. Если же в учетной записи разрешение на удаленный доступ ука зано как Control access through Remote Access Policy (Управление па основе по литики удаленного доступа), результат определяется политикой удаленного доступа.

ГЛАВА 8 Служба проверки подлинности в Интернете Проверка разрешения в учетной записи пользователя или политике удаленного доступа — лишь первый шаг в процессе принятия запроса на соединение. Д.ичее проверяются параметры в свойствах учетной записи пользователя и профиля по литики. Если параметры запроса на соединение не соответствуют параметрам в свойствах учетной записи пользователя или профиля, запрос на соединение откло няется.

По умолчанию разрешение на удаленный доступ в политике устанавливается как Deny remote access permission.

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

• Dial-in constraints (Ограничения по входящим звонкам);

• IP (IP);

• Multilink (Многоканальное подключение);

• Authentication (Проверка подлинности);

• Encryption (Шифрование);

• Advanced (Дополнительно).

Dial-in constraints Вы можете задать следующие ограничения на входящие звонки.

• Разъединение при простое. Время простоя, по истечении которого связь раз рывается. По умолчанию это свойство не установлено, и сервер удаленного дос тупа не разрывает простаивающее соединение.

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

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

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

Удаленный доступ 320 ЧАСТЬ • Входящие звонки только определенных типов. Конкретный тип несущей сре ды, например аналоговая телефонная линия, ISDN или VPN, который должен использовать вызывающий клиент, чтобы его запрос на соединение был принят.

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

J/ Параметры на вкладке IP позволяют указывать, может ли клиент запрашивать кон кретный IP-адрес, По умолчанию сервер удаленного доступа сам назначает IP-ад рес, и клиенту не разрешается запрашивать конкретный IP-адрес.

Эту вкладку можно использовать и для настройки фильтров в профиле политики удаленного доступа. Фильтры IP-пакетов в профиле ограничивают IP-трафик, пе редаваемый клиенту и/или принимаемый от клиента, методом исключения: либо разрешается, либо запрещается любой трафик, кроме указанного. Фильтры в про филе политики удаленного доступа применяются ко всем соединениям, соответ ствующим данной политике.

МиШЫ Вкладка Multilink (Многоканальное подключение) позволяет использовать много канальные подключения и указывать максимальное число портов, которые может задействовать какое-либо многоканальное подключение. Кроме того, Вы можете настроить политики ВАР, определяющие использование этого протокола и условия, при которых отключаются дополнительные каналы связи. Параметры многоканаль ных подключений и ВАР специфичны для средств удаленного доступа в Win dows 2000. По умолчанию многоканальные подключения не разрешены, а протокол ВАР отключен.

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

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

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

• No Encryption (Без шифрования). Шифрование не используется. Чтобы потре бовать шифрования, выберите любой другой уровень шифрования.

Служба проверки подлинности в Интернете ГЛАВА 8 • Basic (Основное). Для соединений по коммутируемым линиям и чере.ч VPN (па основе РРТР) применяется шифрование по методу МРРЕ (Microsoft Poini-to Pntnt Encryption) с 40-битным ключом, а для VPN-соединений на основе L2TP поверх IPSec -- шифрование по алгоритму DES с 40-битным ключом.

• Strong (Стойкое). Для соединений по коммутируемым линиям и через VPN (на основе РРТР) применяется шифрование по методу МРРЕ с 56-битным ключом, а для VPN-соединении на основе L2TP поверх IPSec — шифрование по алго ритму DES с 56-битным ключом.

• Strongest*. Для соединений по коммутируемым линиям и чере:;

VPN (на осно ве РРТР) применяется шифрование по методу МРРЕ со 128-битным ключом, а для VPN-соединений на основе L2TP поверх IPSec — шифрование по алгорит му 3DES со 128-битным ключом.

Advanced Дополнительные параметры предназначены для задания атрибутов RADIUS, пере даваемых сервером IAS клиенту RADIUS. Атрибуты RADIUS специфичны для процесса аутентификации черен RADIUS и игнорируются сервером удаленного доступа. По умолчанию атрибут Framed-Protocol установлен как РРР, а атрибут Service-Type— как Framed.

Сервер удаленного доступа использует лишь атрибуты Acct-Interim-Interval, Fra med-Protocol, Framed-MTU, Reply-Message и Service-Type.

Политика удаленного доступа по умолчанию Политика удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения) создается при включении службы маршрутизации и удаленного доступа. Она имеет следующую конфигурацию:

• условие Day-and-Time-Restrictions не ограничивает дни недели и время cyroic;

• выбран переключатель Deny remote access permission (Отказать в праве уда ленного доступа);

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

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

Профили вендоров Чтобы предоставить функциональность, не поддерживаемую стандартными атри бутами, некоторые поставщики используют особые атрибуты вендоров (vendor specific attributes, VSA). IAS позволяет создавать и изменять VSA. благодаря чему Вам доступны дополнительные возможности тех или иных серверов NAS.

* Этот уровень шифрования поддерживается только после установки Microsoft Encryption Pack, подпадающего под действие экспортных ограничений США. — Прим. трев.

ЧАСТЬ 2 Удаленный доступ Если для какого-то профиля требуется настроить более одного VSA, эти атрибуты нужно определенным образом упорядочить. Для упорядочения атрибутов исполь зуются кнопки со стрелками.

Пример Следующий пример демонстрирует процедуру добавления Cisco VSA в профиль.

Здесь просто показывается механизм добавления VSA, отвечающего стандарту (RFC). Особые атрибуты вендора Cisco уже доступны в IAS-словаре вендоров.

Особые атрибуты вендора Cisco соответствуют требованиям RADIUS RFC, предъ являемым к особым атрибутам вендоров (тип 26). Далее поясняется, как настроить атрибут Cisco для задания основного DNS-сервера.

• Vendor ID (Идентификатор вендора): 9. Это уникальный идентификатор для Cisco. Данное значение устанавливается автоматически, когда Вы выбираете Cisco в качестве вендора.

• Vendor Type (Тип вендора): 1. Это номер типа вендора для особых атрибутов вендора, которые имеют формат «атрибут-значение» (обозначаемый в докумен тации Cisco как «cisco-avpair»), • Data Type (Тип данных): String (Строковый).

• Format (Формат): если атрибут является обязательным, то формат выглядит как <протокол>: атрибут^значение.

Если атрибут необязательный, он отделяется от значения не знаком равенства, а звездочкой. В этом примере <протокол> - значение Cisco-атрибута «protocol» для конкретного типа авторизации. «Атрибут» и «значение*, представляют соответству ющую пару «атрибут-значение» (AV), определенную в спецификации Cisco TACACS+.

Это позволяет использовать и для RADIUS полный набор возможностей, доступ ных при авторизации через TACACS4-.

Атрибут Cisco для задания основного DNS-сервера выглядит так:

ip:dns-servers=10.10.10. ^ Чтобы добавить особый атрибут вендора в профиль входящих звонков:

1. В окне IAS выберите Remote Access Policies (Политика удаленного доступа), 2. Щелкните правой кнопкой мыши имя политики, в которой Вы хотите настро ить особый атрибут вендора, и выберите команду Properties (Свойства).

3. Щелкните кнопку Edit profile (Изменить профиль), откройте вкладку Advanced (Дополнительно) и щелкните кнопку Add (Добавить).

4. В списке атрибутов RADIUS дважды щелкните Vendor-Specific (Vendor-Specific).

5. Щелкните кнопку Add (Добавить).

6. В списке раздела Network access server vendor (Вендор сервера удаленного до ступа) выберите Cisco.

Щелкните переключатель Yes, it conforms (Да, соответствует) и нажмите кноп 7.

ку Configure Attribute (Настройка атрибута). В поле Vendor-assigned attribute number (Назначенный вендором номер атрибута) введите 1.

8. В поле Attribute format (Формат атрибута) выберите String (Строковый).

9. Б поле Attribute value (Значение атрибута) введите:

ip:dns-serversi=10.10.10. Служба проверки подлинности в Интернете ГЛАВА 8 Пример Следующий пример иллюстрирует, как добавить в профиль особый атрибут вендо ра 3Com/U.S. Robotics.

Примечание Пример 2 просто демонстрирует, как добавить в профиль VSA, несо ответствующий стандарту (RFC). Особые атрибуты вендора ЗСот/'U.S. Robotics уже доступны в IAS-словаре вендоров.

Особые атрибуты вендора U.S. Robotics не соответствуют рекомендованному фор мату VSA (тип 26), описанному в RFC 2138, Таким образом, все особые атрибуты вендора U.S. Robotics следует вводить в шестнадцатеричной форме.

Далее поясняется, как настроить атрибут U.S. Robotics для задания основного D\TS сервера.

• Vendor ID: 429. Это уникальный идентификатор для U.S. Robotics. Данное зна чение устанавливается автоматически, когда Вы выбираете U.S. Robotics в ка честве вендора.

• Indicator: Ox900F.

• Data Type: String.

• Format: шестнадцатеричный.

^ Чтобы указать IP-адрес 10,10.10.10 для основного DNS/NBNS-сервера:

В окне IAS выберите Remote Access Policies (Политика удаленного доступа).

1.

2. Щелкните правой кнопкой мыши имя политики, в которой Вы хотите настро ить особый атрибут вендора, и выберите команду Properties (Свойства).

3. Щелкните кнопку Edit profile (Изменить профиль), откройте вкладку Advanced (Дополнительно) и щелкните кнопку Add (Добавить).

4. В списке атрибутов RADIUS дважды щелкните Vendor-Specific (Vendor Specific) и щелкните кнопку Add (Добавить).

5. В разделе Network access server vendor (Вендор сервера удаленного доступа) щелкните переключатель Select from the list (Выбор из списка) и выберите из списка US Robotics, Inc.

6. Щелкните переключатель No, it doest not conform (Нет, не соответствует) и нажмите кнопку Configure Attribute (Настройка атрибута).

7. В поле Hexadecimal attribute value (Шестнадцатеричное значение атрибута) введите:

0х900т302еЗШ2е31302е31302е Подробнее о нестандартных атрибутах U.S. Robotics см. документацию на Ваше оборудование U.S. Robotics.

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

1, Проверяется первая политика в списке политик удаленного доступа. Если по литик удаленного доступа нет, запрос на соединение отклоняется.

Удаленный доступ 324 ЧАСТЬ 2. Если не все параметры запроса на соединение соответствуют данной политике удаленного доступа, проверяется следующая политика. Если политик удаленно го доступа больше нет, запрос на соединение отклоняется.

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

• Если разрешение установлено как Deny access (Запретить доступ), запрос на соединение отклоняется.

• Если разрешение установлено как Allow access (Разрешить доступ), приме няются параметры, ладанные в учетной записи пользователя и в профиле.

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

• Если параметры запроса на соединение соответствуют параметрам учетной записи пользователя и профиля, запрос на соединение принимается, Если Allow access или Deny access не задано, разрешение должно быть ука • зано как Control access through Remote Access Policy (Управление на осно ве политики удаленного доступа). Тогда проверяется разрешение на удален ный доступ о политике удаленного доступа.

• Если в политике разрешение установлено как Deny remote access permission (Отказать в праве удаленного доступа), запрос на соединение отклоняется.

Если в политике разрешение установлено как Grant remote access permission • (Предоставить право удаленного доступа), применяются параметры учетной записи пользователя и профиля.

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

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

Административные модели политик удаленного доступа Windows 2000 предусматривает три основных модели управления разрешениями на удаленный доступ и параметрами соединений:

• доступ на уровне пользователей;

• доступ на основе политик в домене Windows 2000 основного режима;

• доступ на основе политик в домене Windows 2000 смешанного режима.

Доступ на уровне пользователей В этой модели разрешения на удаленный доступ определяются разрешением, за данным на вкладке Dial-in (Входящие зконки) окна свойств учетной записи пользо вателя. Удаленный доступ разрешается или запрещается для каждого пользователя индивидуально выбором переключателя Allow access (Разрешить доступ) или Deny access (Запретить доступ).

Если в свойствах учетной записи пользователя разрешение на удаленный доступ установлено как Allow access или Deny access, оно переопределяет эквивалентное Служба проверки подлинности в Интернете ГЛАВА разрешение, указанное н политике удаленного доступа. Но параметры соединения определяются условиями политики удаленного доступа и настройками профиля.

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

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

• Явное разрешение. Разрешение на удаленный доступ в свойствах учетной за писи пользователя установлено как Allow access, и параметры запроса на со единение соответствуют условиям политики, параметрам профиля и параметрам входящих звонков в свойствах учетной записи данного пользователя.

• Явный запрет. Разрешение на удаленный доступ в свойствах учетной записи пользователя установлено как Deny access.

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

В Windows 2000 административная модель доступа на уровне пользователей экви валентна управлению удаленным доступом на RAS-сервере Windows NT 4.0.

Вы можете применять административную модель доступа па уровне пользователей на автономных серверах, серверах в домене Windows 2000 основного либо смешан ного режима или на серверах с домене Windows NT 4.0. Кроме того, эта модель при менима на серверах RAS или IAS под управлением Windows NT 4.0, Доступ на основе политик в домене Windows 2000 основного режима В этой модели разрешение на удаленный доступ в свойствах каждой пользователь ской учетной записи указывается как Control access through Remote Access Policy (Управление на основе политики удаленного доступа), поэтому реальные разреше ния на удаленный доступ определяются параметрами политики удаленного доступа.

При применении административной модели доступа на основе пол тик в доме i го Windows 2000 основного режима возможны три ситуации.

• Явное разрешение. Разрешение на удаленный доступ и политике удаленного доступа установлено как Grant remote access permission (Предоставить ripaj>o удаленного доступа), и параметры запроса на соединение соответствуют усло виям политики, параметрам профиля и параметрам входящих звонков в свой ствах учетной записи данного пользователя.

• Явный запрет. Разрешение на удаленный доступ в политике удаленного досту па установлено как Deny remote access permission (Отказать в праве удалепни го доступа).

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

ЧАСТЬ 2 Удаленный доступ Если при использовании данной административной модели Вы не добавляете свои политики удаленного доступа и не изменяете политику удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения), удаленный доступ запрещается всем пользо вателям. Изначально разрешение на удаленный доступ в политике по умолчанию указано как Deny remote access permission (Отказать в праве удаленного досту па). Если Вы смените этот вариант на Grant remote access permission (Предос тавить право удаленного доступа), удаленный доступ будет разрешен всем пользователям, Административная модель доступа на основе политик в домене Windows 2000 ос новного режима применима и на автономном сервере удаленного доступа, не вхо дящем в домен.

Однако эта модель не годится при наличии сервера IAS или RAS под управлением Windows NT 4.O.

Если Вы применяете административную модель доступа на основе политик в до мене Windows 2000 основного режима и не используете группы для определения круга лиц, имеющих право удаленного доступа, убедитесь, что учетная запись Guest (Гость) отключена и что в ее свойствах выбран переключатель Deny access (Зап ретить доступ).

Доступ на основе политик в домене Windows 2000 смешанного режима В этой модели во всех учетных записях пользователей разрешение на удаленный доступ указывается как Allow access (Разрешить доступ), политика удаленного доступа по умолчанию удаляется и создаются новые политики, определяющие раз решенные типы подключений. На сервере удаленного доступа Windows 2000, вхо дящем в домен Windows 2000 смешанного режима, флажок Control access through Remote Access Policy (Управление на основе политики удаленного доступа) в окне свойств пользовательской учетной записи отсутствует. Если параметры запроса на соединение соответствуют условиям политики, параметрам профиля и параметрам входящих звонков в свойствах пользовательской учетной записи, то он принимается.

Эта модель применима и для сервера удаленного доступа Windows 2000, входяще го в домен Windows NT 4.0.

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

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

• Явный запрет. Параметры запроса на соединение соответствуют условиям по литики, но не свойствам профиля. Явный запрет в этой административной мо дели реализуется установкой флажка Restrict Dial-in to this number only (Раз решить вход только по номеру) на вкладке ограничений на входящие звонки и вводом телефонного номера, заведомо не используемому сервером удаленного доступа.

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

Служба проверки подлинности в Интернете ГЛАВА Если Вы не удалите политику удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подклю чения), псе пользователи получат право удаленного доступа.

При наличии серверов Windows NT 4.0 со службой маршрутизации и удаленного доступа административную модель доступа па основе политик в домене Win dows 2000 смешанного режима можно использовать, только если эти серверы скон фигурированы как RADI US-клиенты сервера IAS под управлением Windows 2000.

Для серверов RAS под управлением Windows NT Л.О эта модель неприменима.

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

Дополнительную информацию о политиках удаленного доступа и примерах их ис пользования см. в справочной системе Windows 2000 Server.

Учет в IAS В следующем разделе описываются средства учета, поддерживаемые IAS, и форма ты файла журнала IAS.

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

• собирать учетную информацию в режиме реального времени;

• хранить собранную учетную информацию в централизованном хранилище;

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

Если клиент настроен на учет через RADIUS, то в момент предоставления ему ка кого-либо сервиса он генерирует пакет Accounting Start, описывающий тип предо ставляемого сервиса и пользователя, которому этот сервис предоставляется, Пакот посылается на сервер учета RADIUS, который возвращает подтверждение о при еме данного пакета. По окончании использования сервиса клиент генерирует паю т Accounting Stop, описывающий тип предоставленного сервиса и такую статистику (необязательная часть), как длительность использования сервиса, число пходятш х и исходящих октетов или число входящих и исходящих пакетов. Этот пакет пере дается серверу учета RADIUS, который возвращает подтверждение о его приеме.

Пакет Accounting-Request (Start или Stop) направляется серверу учета RADIUS по сети. Если в течение заданного времени ответ не приходит, передача пакета повто ряется определенное число раз. Кроме того, в отсутствие ответа от основного сер 328 ЧАСТЬ 2 Удаленный доступ вера (если он выключен или недостижим) клиент может пересылать пакеты на до полнительный сервер или серверы. Передама пакетов на дополнительны)! сервер осуществляется либо после заданного числа неудачных попыток связаться с основ ным сервером, либо поочередно — то основному, то дополнительному серверу. Если серверу учета RADIUS не удается успешно записать учетный пакет, он не посыла ет клиенту подтверждение о его приеме. Так, если файл журнала переполнен, IAS начинает игнорировать поступающие пакеты с учетными данными. Это заставляет сервер NAS переключиться на резервный сервер IAS.

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

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

Формат базы данных следует использовать, если Вы хотите импортировать инфор мацию непосредственно в базу данных, а формат IAS — если Вам нужна более де тальная информация, не поддерживаемая форматом базы данных.

Примечание Файл журнала 1AS содержит все события IAS, связанные с пользова телями. События 1AS, относящиеся к системе или самой службе 1AS, записывают ся в системный журнал событий.

Аутентификация в IAS и режимы работы доменов lA/inrimiie nniu uno Windows В этом разделе основное внимание уделяется средствам аутентификации IAS и их поседению в различных режимах работы доменов Windows. Эта информация по лезна при принятии решений о выборе конкретного режима домена, в котором раз вертывается 1AS.

IAS способна аутентифицироиать запросы, принимаемые по протоколу RADIUS в доменах Windows 2000 основного или смешанного режима, доменах Windows NT 4. или в локальной базе учетных данных Windows 2000 на автономном сервере IAS.

Набор средств аутентификации 1AS, доступный администраторам, зависит от ре жима домена, в котором проходит аутентификация пользователя.

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

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

ГЛАВА 8 Служба проверки подлинности в Интернете • Возможность подключения удаленной сети к корпоративной. Маршруты для удаленной сети определяются как статические.

• Поддержка основных имен пользователей (user principal names, UPN).

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

Ниже приведен список средств аутентификации и управления удаленным досту пом, поддерживаемых сервером IAS, который входит в домен Windows 2000 основ ного режима.

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

• все разрешения на удаленный доступ, в том числе Allow access (Разрешить доступ), Deny access (Запретить доступ) и Control access through Remote Access Policy (Управление на основе политики удаленного доступа);

• идентификация звонящего;

• параметры ответного вызова;

• статический IP-адрес;

• статические маршруты.

• Поддержка UPN и универсальных групп.

• Поддержка EAP-TLS.

Чтобы сервер IAS мог обращаться к параметрам «ходящих звонков пользовательс ких учетных записей, хранящихся в Active Directory, on должен быть включен в группу безопасности RAS and IAS Servers (Серверы RAS и IAS). Для этого Вы мо жете воспользоваться оснасткой Active Directory Users and Computers (Active Directory - пользователи и компьютеры), зарегистрировать сервер IAS в оснастке Internet Authentication Service (Служба проверки подлинности в Интернете) или ввести команду netsh ras add registereclserver.

Домены Windows 2000 смешанного режима и домены Windows NT 4. Домены Windows 2000 смешанного режима используются в основном при перехо де с Windows NT 4.0 на Windows 2000. С точки зрения IAS, домен Windows смешанного режима — то же самое, что и доме!г Windows NT 4.0. Сервер IAS. со стоящий в домене Windows 2000 смешанного режима, поддерживает следующие средства аутентификации и управления удаленным доступом.

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

• разрешения удаленного доступа — только Allow access (Разрешить доступ) и Deny access (Запретить доступ). Отсутствие Control access through Remo te Access Policy (Управление па основе политики удаленного доступа) ус ложняет применение групп при управлении па основе политик, так как раз решение на удаленный доступ в учетной записи пользователя имеет боле';

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

раздел «Политики удаленного доступа* ранее в этой главе.

• Параметры ответного вызова.

ЧАСТЬ 2 Удаленный доступ Как и в доменах Windows 2000 основного режима, сервер IAS получает доступ к параметрам входящих звонков в свойствах пользовательских учетных записей, хра нящихся в Active Directory, если компьютер, на котором работает служба IAS, включен в группу безопасности RAS and IAS Servers (Серверы RAS и IAS). Для этого Вы можете воспользоваться оснасткой Active Directory Users and Computers (Active Directory - пользователи и компьютеры), зарегистрировать сервер IAS в оснастке Internet Authentication Service (Служба проверки подлинности в Интер нете) или ввести команду netsh ras add registeredserver.

Если сервер IAS входит в домен Windows NT 4.0 и пытается аутентифипировать пользователей в доверяемом домене Active Directory, он не получает доступа к Active Directory, так как учетную запись его компьютера нельзя включить в группу безопасности RAS and IAS Servers. Но Бы можете включить группу Everyone (Все) в группу Pre-Windows 2000 Compatible Access. Для этого воспользуйтесь командой net localgroup «Pre-Windows 2000 Compatible Access». В случае отрицательного результата введите команду net localgroup «Pre-Windows 2000 Compatible Access» everyone /add на контроллере домена и перезагрузите его.

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

Ниже перечислены средства аутентификации, поддерживаемые автономным серве ром IAS под управлением Windows 2000.

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

• вес разрешения на удаленный доступ, в том числе Allow access (Разрешить доступ), Deny access (Запретить доступ) и Control access through Remote Access Policy (Управление на основе политики удаленного доступа);

• идентификация звонящего;

• параметры ответного вызова;

• статический IP-адрес;

• статические маршруты.

Автономные серверы Windows 2000 не поддерживают UPN, универсальные груп пы и KAP-TLS.

Параметры входящих звонков в свойствах учетных записей пользователей можно администрировать через Network and Dial-Up Connections (Сеть и удаленный дос туп к сети) или Local Users and Groups (Локальные пользователи и группы).

Различия в поведении 1AS под управлением Windows и Windows NT 4. Предыдущая версия IAS поставлялась в составе Windows NT 4.0 Option Pack. Здесь поясняются различия в поведении двух версий IAS.

Поведение IAS в Windows NT 4. • Если в процессе аутентификации не указывается имя домена, сервер IAS прове ряет пользователя только по локальной 6aje данных SAM.

Служба проверки подлинности в Интернете ГЛАВА • Не поддерживаются разрешения ответного вызова для любых объектов пользо вателей.

• Файлы журнала IAS записываются в кодировке ASCII.

Поведение IAS в Windows • В процессе аутентификации IAS разрешает имя пользователя без имени домена в следующей последовательности.

1. IAS находит в реестре домен но умолчанию, если таковой указан.

2. Если сервер IAS входит в какой-нибудь домен, аутентификация пользовате ля осуществляется в домене.

3. Если сервер IAS не входит ни в один домен, аутентификация пользователя осуществляется на основе локальной базы данных SAM.

• Поддерживаются разрешения ответного вызова для любых объектов пользо вателей, • Файлы журнала IAS записываются в колировке UTF-8.

Некоторые вопросы безопасности В этом разделе рассматриваются вопросы безопасности IAS и даются рекоменда ции по устранению возникающих проблем.

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

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

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

Брандмауэры Брандмауэр обеспечивает дополнительную защиту любых служб, работающих в какой-либо операционной системе. В качестве брандмауэра может выступать ком пьютер Windows NT или Windows 2000 с Microsoft Proxy Server или аналогичным программным пакетом от стороннего поставщика. Брандмауэр может работать на том же компьютере, что и сервер IAS.

Один из вариантов применения Proxy Server — скрытие IP-адреса сервера. В этом случае IP-адрес сервера IAS представляется IP-адресом прокси-сервера. Кроме того, Вы можете установить брандмауэры от сторонних поставщиков и пропускать толь ко UDP-трафик, который связан с сервером IAS и адресуется на порты, использус Удаленный доступ 332 ЧАСТЬ мые сервером RADIUS. Для большей защиты разрешите пропуск трафика к серве ру RADIUS лишь с определенных IP-адресов (NAS- иди RADIUS-нрокси).

Блокировка учетной записи удаленного доступа Функция блокировки учетных записей позволяет задавать число неудачных попы ток аутентификации, по достижении которого любые попытки подключения по дан ной учетной записи будут отклоняться. Подробнее о блокировке учетных записей удаленного доступа см. главу 7 «Сервер удаленного доступа» в этой книге.

Настройка и оптимизация 1} этом разделе Вы найдете рекомендации по тонкой настройке службы IAS и ее мониторингу. Здесь же дается информация, которая будет полезна при проверке производительности и работоспособности сервера IAS.

При тонкой настройке сервера IAS примите во внимание следующие соображения.

• Если IAS выполняет аутентификацию пользователя на контроллере домена Windows 2000 основного режима, па этом контроллере должен храниться гло бальный каталог.

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

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

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

• Рассмотрите возможность работы сервера IAS на контроллере домена с глобаль ным каталогом. Это снизит задержки в передане данных и увеличит пропуск ную способность.

• Для достижения максимально возможной пропускной способности укажите в соответствующем параметре реестра число запросов на аутентификацию, одно временно обрабатываемых сервером 1AS и контроллером домена. Информацию о нужном параметре реестра см. л справочной системе Windows 2000 Server, • Администратор может развернуть несколько серверов 1AS и использовать Win dows Load Balance Service (эта служба имеется только в Windows 2000 Advanced Server) для перенаправления всех серверов NAS на один IP-адрес, представля ющий пул серверов IAS.

ГЛАВА 8 Служба проверки подлинности в Интернете Мониторинг производительности и работоспособности сервера IAS Протокол аутентификации RADIUS различает функции клиента и сервера. При аутентификации через RADIUS клиенты посылают пакеты Access-Request, а сер веры отвечают пакетами Access-Accept, Access-Reject и Access-Challenge. Устройства NAS обычно выполняют функции клиента и реализуют МПЗ-клиент аутентифика ции RADIUS;

серверы IAS выполняют функции сервера и реализуют МПЗ-сервср аутентификации RADIUS.

При мониторинге производительности сервера 1AS чаще всего используются два счетчика оснастки Performance (Производительность):

• Access Request/sec (Запросов доступа/сек);

• Accounting Request/sec (Запросов учетных данных/сек), Наиболее часто используемые для IAS счетчики описываются в следующем разде ле. Подробнее о SNMP МТБ, поддерживаемых IAS, см. главу 10 «SNMP» в книге «Сети TCP/IP* из серии «Ресурсы Microsoft Windows 2000 Server».

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

«Unknown user name or bad password» («Неизвестное имя пользователя млн неправильный пароль >) «The specified user does not exist» («Пользователь с указанным именем не существует») «Тпе specified domain does not exist» («Указанный домен не существует») Не исключено, что пользователь ввел неправильное имя или пароль. Проверьте имя и пароль в его учетной записи и убедитесь, что они введены правильно и что эта учетная запись допустима для домена, в котором IAS аутентифицирует данного пользователя.

Также возможно, что правила замены сфер (realm replacement rules) заданы невер но или не в том порядке, и из-за этого контроллер домена не распознает имя пользо вателя. Исправьте правила замены сфер (см. справочную систему Windows Server).

Если сервер удаленного доступа является членом домена, а в ответе от пользовате ля нет имени домена, IAS подставляет имя домена, в который входит этот серпе) удаленного доступа. Чтобы IAS в таких случаях использовала имя другого доменг, присвойте нужное значение параметру DefaultDomain в разделе реестра (на ком пьютере с сервером IAS):

ЧАСТЬ 2 Удаленный доступ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan \PPP\ControlPromcols\BuiltIn Внимание Не модифицируйте реестр самостоятельно (с помощью редактора реест ра) — делайте это лить в крайнем случае, когда другого выхода нет, В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также тех, которые могут снизить быстродействие системы или привести к ее краху. Прямое редактирование реестра может повлечь за собой непредсказуемые последствия, и Вам придется переустанавливать Windows 2000. Для настройки и конфигурирова ния Windows 2000 по возможности используйте Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft).

Некоторые серверы NAS автоматически удаляют имя домена из имени пользовате ля перед его пересылкой серверу RADIUS. Отключите удаление имени домена из имени пользователя. Подробнее см. документацию на Ваш сервер NAS.

«The authentication type is not supported on this system» («Этот тип проверки подлинности не поддерживается на этом компьютере») Пользователь пытается задействовать метод аутентификации, не поддерживаемый на этом компьютере. Например, пользователю нужен тип ЕАР, не установленный на сервере. Для включения требуемого протокола измените профиль удаленного доступа.

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

"The user's information did not match a remote access policy» («Информация о пользователе не соответствует политике удаленного доступа») «The user is not allowed dial-in access to the network» («Этому пользователю не разрешен удаленный доступ к сети») «User attempted an unauthorized authentication method» («Пользователь пытался применить неразрешенный метод проверки подлинности») «User tried to connect from an unauthorized calling station» («Пользователь пытался подключиться через неразрешенную станцию вызова») «User tried to dial-In outside of permitted hours» («Пользователь пытался подключиться за пределами разрешенного времени») «User tried to connect by calling an unauthorized NAS phone number» («Пользователь пытался подключиться через неразрешенный телефонный номер NAS») «User tried to connect using an invalid port type» («Пользователь пытался подключиться через неправильный тип порта») «A constraint defined in the remote access policy tailed» («He выполнено ограничение, определенное в политике удаленного доступа») Доступ может быть запрещен пользователю одной из политик удаленного доступа.

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

ГЛАВА 8 Служба проверки подлинности в Интернете с неавторизованного телефонного номера или по недоступному для данного пользо вателя телефонному номеру NAS). Внесите соответствующие изменения в полити ки удаленного доступа.

Также возможен неверный порядок политик удаленного доступа. Запрос на соеди нение принимается или отклоняется первой политикой, условия которой соответ ствуют параметрам данного запроса. Переместите нужную политику с помощью кнопки Move Up (Вверх) выше по списку.

«The user has exceeded the dial-in lockout count» («Этот пользователь превысил счетчик блокировки входящих подключений») Если включена функция блокировки учетных записей, предыдущая неудачная по пытка соединения могла привести к блокировке учетной записи данного пользова теля. Если это так, увеличьте пороговое значение счетчика, используемого функ цией блокировки.

«The user's account is currently locked out and might not be legged on to» («Учетная запись этого пользователя в данный момент заблокирована и не может использоваться для входа в систему») Учетная запись пользователя блокирована, и аутентификация по ней невозможна.

«The user is not allowed dial-in access to the network» («Этому пользователю не разрешен удаленный доступ к сети») Пользователю может быть запрещен удаленный доступ. Проверьте, предоставлен ли пользователю удаленный доступ в учетных данных на контроллере домена или в оснастке Local Users and Groups (Локальные пользователи и группы). Эта инфор мация переопределяет любую политику, разрешающую доступ.

«The current configuration supports only local user accounts» («Текущая конфигурация поддерживав г только локальные учетные записи пользователей») IAS настроен на аутентификацию в локальной базе данных SAM, а пользователь не зарегистрирован в этой базе. В таком случае включите сервер IAS в Active Directory.

«The user's account domain is unreachaole» («Домен учетной записи пользователя недоступен») «The server is unavailable» («Сервер недоступен») «The specified domain did not exist» («Указанный домен не существует») «IAS could not access the Global Catalog» («IAS не имеет доступа к глобальному каталогу») Возможна проблема со связью между серверами NAS и IAS или между сервером IAS и контроллером домена или сервером глобального каталога. Для проверки свя зи с контроллером домена или сервером глобального каталога используйте г<оман ду ping. Если команда ping сработала, попробуйте подключиться к серверу коман дой net use \\имя_сервера\общии_ресурс. Если после этого в журнале IAS не по явилось никакой информации, проверьте по журналу событий Windows 2000, не было ли таймаута при попытке подключения.

Клиентский компьютер может быть настроен на CHAP, a Active Directory не скон фигурирована на использование нешифрованных паролей. Чтобы использовать протокол аутентификации CHAP, настройте профиль входящих подключений пользователя или группы на протокол CHAP. NAS и пользовательская программа лозвона до сервера (например, диспетчер подключений) должны быть настроены Удаленный доступ 336 ЧАСТЬ на аутентификацию по CHAP. Вы также должны включить CHAP на контроллере домена.

Некоторые серверы NAS распознают не все символы, которые IAS принимает для общих секретов. Попробуйте изменить общий секрет так, чтобы он состоял только из алфавитно-цифровых знаков.

Не исключено, что сервер NAS посылает пакеты, не соответствующие формату, ожидаемому IAS. Щелкните правой кнопкой мыши Internet Authentication Service (Служба проверки подлинности в Интернете) и выберите команду Properties (Свойства). Убедитесь, что флажок Log rejected or discarded authentication requ ests (Протоколирование отказов на запросы проверки подлинности) установлен, а жгем просмотрите журнал на предмет того, не посылаются ли какие-нибудь непод ходящие пакеты. Если дело обстоит именно так, то, возможно, придется определить в IAS какие-то особые атрибуты вендора.

Возможно, что серверу IAS не удается подключиться к домену. Убедитесь, что 1AS использует правильное имя домена. Если имя домена корректно, убедитесь, что сер вер 1AS входит в этот домен или что между этим доменом и доменом, к которому относится сервер IAS, существуют доверительные отношения.

У сервера 1AS нет разрешения на просмотр объектов пользователей в Active Direc tory. Включите сервер IAS в Active Directory.

Учетная запись пользователя находится в лесу Active Directory, отличном от леса, в который включен сервер IAS. Для перенаправления запроса на аутентификацию серверу IAS, который включен в другой лес Active Directory, используйте RADIUS прокси.

Пользователь пытается применить разрешенное 128-битное шифрование. В IAS такое шифрование тоже разрешено, но в службе маршрутизации и удаленного дос тупа — нет. Выберите в службе маршрутизации и удаленного доступа уровень шиф рования Strongest. (Если соответствующий переключатель отсутствует, установите Microsoft Encryption Pack.) Возможно, Вашему серверу NAS нужен метод маршрутизации Framed-Routing (с разбиением на кадры), а па сервере IAS он не разрешен. Включите этот метод мар шрут иза дин.

^ Чтобы включить метод маршрутизации Framed-Routing:

1. В оснастке IAS раскройте узел Remote Access Policies (Политика удаленного доступа), а затем дважды щелкните имя политики, применяемой к пользовате лям, которым не удается войти в систему.

2. Щелкните кнопку Edit Profile (Изменить профиль), перейдите на вкладку Advanced (Дополнительно) и щелкните кнопку Add (Добавить).

3. В списке доступных атрибутов RADIUS дважды щелкните атрибут Framed Routing (Framed-Routing).

4. В ноле со списком Attribute value (Значение атрибута) выберите None (None).

Вашему NAS может понадобиться сжатие для TCP/IP но методу Ван Якобсена (Van Jacobsen TCP/IP compression), не предлагаемое в IAS по умолчанию. Настрой те IAS на использование сжатия для TCP/IP по методу Van Jacobsen Служба проверки подлинности в Интернете ГЛАВА >• Чтобы настроить IAS на сжатие для TCP/IP по методу Van Jacobsen:

1. В оснастке IAS раскройте узел Remote Access Policies, а затем дважды шелк ните имя политики, применяемой к пользователям, которым не удается пойти в систему.

2. Щелкните кнопку Edit Profile, перейдите на вкладку Advanced и щелкните кнопку Add.

3. В списке доступных атрибутов RADIUS дважды щелкните атрибут Framed Compression (Framed-Compression).

4. В иоле со списком Attribute value выберите Van Jacobsen TCP/IP header compression (Van Jacobsen TCP/IP header compression).

Если на сервере NAS установлен параметр Framed-MTU, а на сервере IAS — пет, пользователи не смогут входить в систему. Проверьте параметр Framed-MTU в JAS и убедитесь, что он соответствует тому же параметру на сервере NTAS.

>• Чтобы изменить значение параметра Framed-MTU:

1. В оснастке IAS раскройте узел Remote Access Policies, а затем дважды щелк ните имя политики, применяемой к пользователям, которым не удается войти в систему.

2. Щелкните кнопку Edit Profile, перейдите на вкладку Advanced и щелкните кнопку Add.

3. В списке доступных атрибутов RADIUS дважды щелкните атрибут Framed MTU (Framed-*MTU).

4. В поле Attribute value введите значение, соответствующее настройкам NAS.

Если IAS возвращает пакет Access-Accept, используя сетевой адаптер, от личный от того, по которому был принят пакет Access-Request, сервер NAS не распознает та кой пакет, В этом случае проверьте настройки сервера IAS.

Если запрос возвращается через RADIUS-прокси, то не исключено, что он не под держивает некоторые необходимые расширения, например:

• если Вы хотите, чтобы Ваши пользователи аутентифицировались по ЕАГ.

RADIUS-прокси должен поддерживать цифровые подписи (в соответствии с расширениями RADIUS);

• если Вы хотите, чтобы Ваши пользователи подключались через принудитель ные туннели, RADIUS-прокси должен поддерживать шифрование пароля для туннеля;

• если для подключений требуется Microsoft Encryption, RADIUS-прокси должен поддерживать шифрование МРРЕ-ключей, Просмотрите документацию на свой RADIUS-прокси и проверьте, поддерживает ли он нужные Вам расширения.

Какая-то политика удаленного доступа может принимать запросы на соединение от пользователей, доступ которым должен быть запрещен. Проверьте список поли тик и убедитесь, что Вы не включили в одной из политик пользователей, доступ которым должен быть запрещен. Проверьте, не заданы ли свойства входящих звон ков объекта пользователя, переопределяющие параметры в политике удаленного 123ак. Удаленный доступ 338 ЧАСТЬ доступа. Также не исключено, что порядок перечисления политик неверен. Доступ предоставляется или запрещается первой же политикой, условия которой приме нимы к пытающемуся подключиться пользователю. Кнопка Move Up (Вверх) по зволяет переместить политику, запрещающую доступ пользователям, выше по списку.

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

В профиле входящих подключений политики удаленного доступа не выбрано СНАР-шифрование. Проверьте параметры профиля и убедитесь, что IAS настрое на на аутентификацию по CHAP. Также убедитесь, что сервер NAS настроен на этот метод (см. документацию на сервер NAS).

Кроме тото, контроллер домена должен быть настроен на хранение обратимо шиф руемых паролей.

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

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

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

Если служба маршрутизации и удаленного доступа сконфигурирована на аутен тификацию через RADIUS, доступ к политикам возможен только через оснаст ку IAS. Это сделано преднамеренно, Подробнее об устранении проблем с TAS см. справочную систему Windows Server.

Применение Network Monitor Если после проверки базовой конфигурации IAS решить проблему не удалось, ис пользуйте Network Monitor (NetMon) (Сетевой монитор) для трассировки и пос ледующего анализа данных.

Применяя NetMon для устранения проблем с IAS, учтите следующие соображения.

• NetMon должен быть установлен на компьютере, на котором работает сервер IAS.

• Если Вы используете NetMon в коммутируемой сетевой среде, то увидите лишь трафик, адресованный компьютеру, где запущен NetMon.

Об установке и использовании NetMon см. книгу «Сопровождение сервера* из серии «Ресурсы Microsoft Windows 2000 Server».

Для локализации источника проблем в работе RADIUS средствами NetMon нужно настроить его на фильтрацию пакетов RADIUS.

Служба проверки подлинности в Интернете ГЛАВА ^ Чтобы фильтровать RADIUS-пакеты в трассировочной информации NetMon:

1. Выполните трассировку в дробленной ситуации.

2. Выберите из меню Display (Отображение) команду Filter (Фильтр).

3. Выберите Protocol = = Any (Протокол = = Любой), а затем щелкните кнопку Edit Expression (Выражение). Выберите Disable All (Отключить все), чтобы отключить все протоколы. В лрааой секции укажите RADIUS protocol (Прото кол RADIUS) и щелкните Enable (Включить).

4. Щелкните кнопку ОК.

ГЛАВА Виртуальные частные сети Windows 2000 поддерживает виртуальные частные сети (virtual private networks.

VPN), позволяющие подключать удаленные клиенты и офисы к корпоративным сетям черед Интернет. Как специалист по сетям, Вы должны понимать области при менения виртуальных частных сетей, а также технологии и концепции, на которых они построены: РРТР (Point-to-Point Tunneling Protocol), L2TP (Layer Two Tunne ling Protocol), средства защиты, адресацию и маршрутизацию в VPN и т. д. Кроме того, здесь предполагается, что Вы хорошо знаете TCP/IP, IP-маршрутизацию, IP безопасность (IPSec) и сервер удаленного доступа Windows 2000.

В этой главе Обзор РРТР L2TP и IP-безонасностъ Защита виртуальных частных сетей Адресация и маршрутизация при использовании виртуальных частных сетей Виртуальные частные сети и брандмауэры Виртуальные частные сети и NAT Сквозные VPN-соединения Выявление и устранение проблем См. также • Подробнее о TCP/IP — главу 1 «Введение в TCP/IP» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server», • Об IPScc — главу 8 «IP-безопасность» в книге «Сети TCP/IP» из серии «Ре сурсы Microsoft Windows 2000 Server».

• Об одноадресной IP-маршрутизации — главу 3 «Одноадресная IP-маршрутиза ция» в этой книге.

• О маршрутизации с соединением по требованию — главу 6 «Маршрутизация с соединением по требованию» в этой книге.

Виртуальные частные сети ГЛАВА О сервере удаленного доступа Windows 2000 — главу 7 «Сервер удаленного до ступа» в этой книге.

Обзор Виртуальная частная сеть (virtual private network, VPN) — это расширение част ной сети, включающей соединения через общедоступные сети вроде Интернета.

VPK позволяет передавать данные между двумя компьютерами по общедоступным сетям, эмулируя свойства частного канала связи типа «точка-точка».

Для эмуляции канала связи «точка-точка* данные инкапсулируются в пакет с за головком, который содержит информацию о маршрутах, необходимую для пересил ки этого пакета в конечную точку по общедоступным сетям. Кроме того, передава емые данные зашифровываются. Злоумышленник, перехватив такие пакеты в об щедоступной сети, не сможет расшифровать их без соответствующих шифроваль ных ключей. Канал связи, при использовании которого частные данные инкапсу лируются и зашифровываются, называется VPN-соединением.

Логическую концепцию VPN иллюстрирует рис. 9-1.

VPN-соединение Рис. 9-1, Виртуальная частная сеть (VPN) VPN-соединение дает возможность пользователю, работающему дома или в доро ге, получать удаленный доступ к серверу своей организации через инфраструктуру общедоступных сетей, например через Интернет. С точки зрения пользователя, VPN — это соединение типа «точка-точка» между его компьютером (VPN-клиен том) и сервером организации (VPN-сервером). Конкретная инфраструктура обще доступной сети не имеет для него никакого значения, поскольку VPN-соедине Удаленный доступ 342 ЧАСТЬ ние создает такое впечатление, будто данные передаются по выделенному част ному каналу, VPN-соединения также позволяют организациям создавать маршрутизируемые подключения к территориально удаленным офисам и другим организациям по об щедоступным сетям тина Интернета, в то же время обеспечивая защиту коммуни кационных связей. Маршрутизируемое VPN-соединение (routed VPN connection) через Интернет на логическом уровне обрабатывается как выделенный WAN-канал.

Обладая свойствами как удаленных, так и маршрутизируемых соединений, VPN соединения позволяют организации заменить междугородные выделенные или ком мутируемые линии удаленного доступа на локальные выделенные линии или уда ленный доступ по коммутируемой линии к местному провайдеру Интернет-услуг (Internet service provider, ISP).

Элементы VPN-соединения VPN-соединение в Windows 2000 включает следующие элементы (рис. 9-2).

VPN-сервер. Компьютер, принимающий запросы на VPN-соединения от VPN-кли ентов. VPN-сервер поддерживает VPN-соединения удаленного доступа и VPN-со единения между маршрутизаторами. Подробнее см. раздел «VPN-соединения» да лее в этой главе.

VPN-клиент. Компьютер, инициирующий VPN-соединение с VPN-сервером. VPN клиент может быть автономным компьютером, используемым для удаленного дос тупа, или маршрутизатором, принимающим межмаршрутизаторные VPN-соедине ния. Компьютеры под управлением Windows NT версии 4.0, Windows 2000, Win dows 95 или Windows 98 могут создавать VPN-соединения удаленного доступа с VPN-сервером Windows 2000, а компьютеры под управлением Windows 2000 Server и Windows NT Server 4.0 и службы маршрутизации и удаленного доступа (Routing and Remote Access service, RRAS) — межмаршрутизаторные VPN-соединения с VPN-сервером Windows 2000. VPN-клиент может быть клиентом любой реализа ции РРТР (Point-to-Point Tunneling Protocol) или L2TP (Layer Two Tunneling Protocol) поверх IPSec (не только от Microsoft).

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

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

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

Протоколы тунпелирования (тупнелирующие протоколы). Коммуникационные стандарты, применяемые для управления туннелями и инкапсуляции конфиденци альных данных. (Туннелируемые данные также зашифровываются.) Windows включает протоколы тунпелирования РРТР и L2TP (см. разделы «РРТР» и «L2TP и IP-безопасность» далее в этой главе).

Виртуальные частные сети ГЛАВА Тупнелированные данные. Данные, которые обычно передаются по частному каналу связи типа «точка-точка».

Транзитная межсетевая среда. Открытая или общедоступная межсетевая среда, через которую передаются инкапсулированные данные. В случае Windows транзитной всегда является межсетевая IP-среда. Транзитной межсетевой средой может быть Интернет или частная JP-интрасеть.

Туннель "'{" ^><" NT VPN-соединение VPN-сервер ч,, vS, т~ч •Транзитная межсетевая среда VPN-клиент Рис. 9-2. Элементы VPN-соединения VPN-соединения Создание VPN-соединения во многом аналогично установлению соединения типа «точка-точка» по коммутируемой линии или при маршрутизации с соединением по требованию. Существует два типа VPN-соединений: VPN-соединение удаленного доступа (remote access VPN connection) и VPN-соединение между маршрутизато рами (router-to-router VPN connection).

VPN-соединение удаленного доступа Такое соединение инициируется клиентом удаленного доступа (компьютером ин дивидуального пользователя), который подключается к частной сети. VPN-сервер предоставляет доступ к своим ресурсам или ко всей сети, с которой он связан. Паке ты, передаваемые по VPN-соединению, генерируются клиентом удаленного доступ,!, Клиент удаленного доступа (VPN-клиент) аутентифицируется на сервере удаленно го доступа (VPN-сервере), а тот — на клиенте (в случае взаимной аутентификации).

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

Вызывающий маршрутизатор (VPN-клиент) аутентифицируется на отвечающем (VPN-сервере), а отвечающий — на вызывающем (в случае взаимной аутенти фикации).

Свойства VPN-соединений VPN-соединения, использующие РРТР и «L2TP поверх IPSec», обеспечивают:

• инкапсуляцию;

• аутентификацию (проверку подлинности);

344 ЧАСТЬ 2 Удаленный доступ • шифрование данных;

• назначение адресов и серверов имен.

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

Аутентификация Для VPN-соединений поддерживается аутентификация двух видов.

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

• Аутентификация и проверка целостности данных. Если Вы хотите гаранти ровать подлинность источника данных, передаваемых по VPN-соединению, и ис ключить вероятность их модификации в процессе передачи, то можете;

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

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

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

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

Подробнее об управлении шифровальными ключами применительно к технологи ям VPN в Windows 2000 см. раздел «Защита виртуальных частных сетей» далее в этой главе.

Назначение адресов и серверов имен При настройке VPN-сервера создается виртуальный интерфейс, чере;

^ который ус танавливаются все VPN-соединения. Когда VPN-клиент запрашивает VPN-соеди нение, на нем тоже создается виртуальный интерфейс. Далее виртуальный интер фейс VPN-клиента подключается к виртуальному интерфейсу VPN-сервера, и со здается VPN-соединение типа «точка-точка».

Виртуальным интерфейсам VPN-клиента и сервера должны быть назначены IP-ад реса. Их назначение осуществляется VPN-сервером. По умолчанию VPN-cepuep получает IP-адреса для себя и VPN-клиента через DHCP (Dynamic Host Configu Виртуальные частные сети ГЛАВА 9 ration Protocol), Вы можете задать статический пул IP-адресов, определяемый по идентификатору сети и маске подсети.

Серверы имея (DNS- и WINS-серверы) также назначаются в процессе установле ния VPN-соединения. VPN-клиент получает от VPN-сервера IP-адреса DNS- и WINS-серверов, относящихся к иптрасети, к которой подключен VPN-сервер.

VPN-соединения через Интернет или интрасети VPN-соединения удобны для подключения пользователей или сетей по безопасно му каналу связи типа «точка-точка». Типичные VPN-соединения осуществляются либо через Интернет, либо через интрасети.

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

Удаленный доступ через Интернет Клиент удаленного доступа — вместо того чтобы связываться с корпоративным или аутсорсинговым сервером доступа is сеть по междугородной связи — звонит мест ному ISP. Установив физическое соединение с местным 1SP, клиент удаленного до ступа инициирует VPN-соединение через Интернет с VPN-сервером своей органи зации. После создания VPN-соединения клиент удаленного доступа может обра щаться к ресурсам частной интрасети.

Схема удаленного доступа через Интернет показана на рис. 9-3.

г VPN-соединение Интрасеть Рис. 9-3. VPN-соединение, связывающее удаленный клиент с частной интрасетью Соединение сетей через Интернет Когда сети соединяются через Интернет (рис. 9-4). один маршрутизатор пересыла ет пакеты другому но VPN-соединению. С точки зрения маршрутизаторов, VPN действует как канальный уровень сети.

ЧАСТЬ 2 Удаленный доступ • VPN-соединение 'Туннель Выделенный • Выделенный Центральный или коммутируемый канал офис связи с ISP канал связи с ISP Рис. 9-4. VPN-соединение, связывающее две удаленные сети через Интернет Соединение сетей с использованием выделенных WAN-каналов. Маршрутизато ры офисов подключаются не через дорогостоящий междугородный выделенный WAN-канал, а через Интернет с использованием локальных выделенных WAN-ка налов связи с местными ISP. VPN-соединение инициируется одним из маршрути заторов. После соединения маршрутизаторы могут пересылать друг другу любой трафик.

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

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

Оба офиса можно подключить к Интернету по коммутируемым WAN-каналам, Но это реально, только если ISP поддерживает для своих заказчиков маршрутизацию с соединением по требованию;

в этом случае ISP, получив IP-дейтаграмму, которую нужно доставить заказчику, вызывает его маршрутизатор. Такой сервис предостав ляют лишь отдельные ISP.

VPN-соединения через интрасети Такое VPN-соединение использует преимущества поддержки IP-соединений в инт расети организации.

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

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

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

Схема удаленного доступа через интрасеть показана на рис. 9-5.

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

Бухгалтерия и отдел кадров подключаются к общей интрасети через компьютеры, работающие в качестве VPN-клиентов или серверов. Как только VPN-соединение установлено, пользователи любой из двух сетей могут обмениваться конфиденци альной информацией через корпоративную интрасеть, Рис. 9-6 иллюстрирует сети, соединенные интрасетью.

• VPN-соединение Защищенная Защищенная (скрытая) сеть (скрытая) сеть Рис. 9-6. VPN-соединение, связывающее две сети через интрасеть ЧАСТЬ 2 Удаленный доступ Комбинированные VPN-соединения через Интернет и интрасети VPN-соединения — гибкое средство для создания защищенных подключений типа «точка-точка». Менее распространены комбинированные VPN-соединения, также называемые сквозными (pass-through VPN connection) (рис. 9-7). Такое соединение позволяет удаленному клиенту, подключенному к интрасети одной компании, по лучить доступ через Интернет к ресурсам интрасети другой компании. В этом ва рианте VPN-соединение удаленного доступа достигает интрасети назначения через другую интрасеть и Интернет.

• VPN-соединение Туннель Интрасеть Интрасеть Рис. 9-7. Сквозное VPN-соединение Подробнее о сквозных VPN-соединениях см. раздел «Сквозные VPN-соединения» далее в этой главе.

Управление виртуальными частными сетями Управление виртуальными частными сетями ничем не отличается от управления любыми другими сетевыми ресурсами, и при использовании VPN-соединений (осо бенно через Интернет) следует тщательно продумать систему безопасности. Ответь те себе на следующие вопросы.

• Где должны храниться учетные данные пользователей?

• Как будут назначаться адреса VPN-клиентам?

• Кому разрешено создавать VPN-соединения?

• Как VPN-сервер будет аутентифицировать пользователя, пытающегося устано вить VPN-соединение?

• Как VPN-сервер будет регистрировать активность, связанную с VPN?

• Как добиться того, чтобы VPN-сервером можно было управлять на основе стан дартных протоколов и инфраструктуры сетевого администрирования?

Управление пользователями Поскольку хранить разные учетные записи на разных серверах для одного и того же пользователя и одновременно поддерживать их в актуальном состоянии слиш ком непрактично с административной точки зрения, большинство администрато ров создают главную базу учетных данных (master account database) на первичном контроллере домена или на сервере RADIUS (Remote Authentication Dial-In User Service). Это позволяет VPN-серверу передавать аутентификационные удостовере ния устройству, отвечающему за централизованную аутентификацию. При этом для удаленного доступа как по коммутируемой линии, так и через VPN применяется одна и та же пользовательская учетная запись.

Виртуальные частные сети ГЛАВА 9 Управление адресами и серверами имен VPN-сервер должен располагать запасом свободных IP-адресов, чтобы иметь воз можность назначать их своему виртуальному интерфейсу и VPN-клиентам при со гласовании параметров по JPCP (IP Control Protocol) в процессе установлении со единений. IP-адрес, назначенный VPN-клиенту, на самом деле присваивается его виртуальному интерфейсу.

VPN-серверы под управлением Windows 2000 по умолчанию получают IP-адреса для VPN-клиентов через DHCP, но Вы можете сконфигурировать статический пул IP-адресов.

Кроме того, VPN-серверу должны быть известны адреса DNS- и WINS-серверов, которые он назначает VPN-клиентам при согласовании параметров но IPCP (см.

главу 7 «Сервер удаленного доступа» в этой книге).

Управление доступом В Windows 2000 для управления удаленным доступом следует настроить парамет ры входящих звонков в свойствах пользовательских учетных записей и в соответ ствующих политиках удаленного доступа.

Доступ по пользовательской учетной записи Если Вы управляете доступом па уровне пользователей (индивидуально для каж дого пользователя), установите в параметрах их учетных записей разрешение на создание VPN-соединений как Allow access (Разрешить доступ). Если VPN-сервер обслуживает только VPN-соединения, удалите политику удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения) и создайте новую политику с подходящим име нем, например VPN access it' allowed by user account.

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

В качестве примера типичных настроек удаленного доступа через VPN выберите в свойствах политики удаленного доступа переключатель Deny remote access permis sion (Отказать в праве удаленного доступа), а условия и параметры профиля уста новите, как показано в таблицах 9-1 и 9-2. Подробнее о настройке этих параметров см. справочную систему Windows 2000 Server.

Таблица 9-1. Условия политики удаленного доступа для подключения через VPN на основе параметров учетной записи Условие Настройки Virtual (VPN) [Virtual (VPN)J NAS-Port-Type Если Вы хотите определить для РРТР- и Ь2ТР-соединений разные параметры аутентификации и шифрования, создайте отдельные политики удаленного дос у па, д которых установите условие Tunnel-Type (Tunnel-Type) либо как Point-to point Tunneling Protocol (Point-to-Point Tunneling Protocol), либо как Layer Two Tunneling Protocol (Layer Two Tunneling Protocol).

350 ЧАСТЬ 2 Удаленный доступ Таблица 9-2. Параметры профиля политики удаленного доступа для подключения через VPN на основе параметров учетной записи Вкладка в окне профиля Настройки Authentication Установите флажки Microsoft encrypted authentication version (MS-CHAP v2) [Шифрованная проверка (Microsoft, версия 2, (Проверка подлинности) MS-CHAP v2)J и Microsoft encrypted authentication (MS-CHAP) [Шифрованная проверка подлинности Microsoft (MS-CHAP)l Encryption (Шифрование) Выберите переключатель Basic (Основное), Strong (Стойкое) или Strongest* и сбросьте флажок No Encryption (Без шифрования) Доступ по принадлежности к группам Если Вы управляете удаленным доступом на уровне групп, укажите разрешение удаленного доступа во всех учетных записях пользователей как Control access through Remote Access Policy (Управление на основе политики удаленного досту па). Создайте какую-нибудь группу Windows 2000, членам которой будет разреше но устанавливать VPN-соединения удаленного доступа. Если VPN-сервер обслужи вает только VPN-соединения, удалите политику удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения) и создайте новую политику с подходящим именем, напри мер VPN access if member of VPN-allowed group.

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

Таблица 9-3. Условия политики удаленного доступа для подключения через VPN на основе принадлежности к группам Windows Условие Настройки Virtual (VPN) [Virtual (VPN)] NAS-Port-Type Windows-Groups Группа Windows 2000. члены которой имеют право создавать VPN-соединения Таблица 9-4. Параметры профиля политики удаленного доступа для подключения через VPN на основе принадлежности к группам Windows Вкладка в окне профиля Настройки Authentication Установите флажки Microsoft encrypted authentication version (MS-CHAP v2) [Шифрованная проверка (Microsoft, версия 2, (Проверка подлинности) MS-CHAP v2)"| и Microsoft encrypted authentication (MS CHAP) [Шифрованная проверка подлинности Microsoft (MS CHAP)] Encryption (Шифрование) Выберите переключатель Basic (Основное), Strong (Стойкое) или Strongest и сбросьте флажок No Encryption (Без шифрования) Этот уровень шифрования поддерживается только после установки Microsoft Encryption Pack, подпадающего под действие экспортных ограничений США. — Прим, перев.

Виртуальные частные сети ГЛАВА В качестве примера типичных настроек удаленного доступа через VPN только для членов определенной группы выберите в свойствах политики переключатель Grant remote access permission (Предоставить право удаленного доступа), а условия и параметры профиля установите, как показано в таблицах 9-3 и 9-4. Подробнее о настройке этих параметров см. справочную систему Windows 2000 Server.

Управление аутентификацией VPN-сервер можно настроить на поддержку аутентификации через Windows или RADIUS. Если в качестве провайдера аутентификации выбрана Windows, удосто верения пользователей, пытающихся установить VPN-соединения, проверяются обычными средствами аутентификации Windows.

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

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

Сервер RADIUS может не только отвечать на запросы на основе собственной базы данных, но и выступать в роли клиентского интерфейса другого сервера базы дан ных, например универсального сервера ODBC (Open Database Connectivity) или первичного контроллера домена под управлением Windows 2000. Последний может находиться как на машине, где установлен сервер RADIUS, так и на другом компь ютере. Кроме того, сервер RADIUS способен работать как прокси-клиент для уда ленного сервера RADIUS.

Протокол RADIUS описан в RFC 2138 и 2139. Подробнее о протоколе RADIUS и сервере RADIUS, также называемом службой IAS (Internet Authentication Service) см. главу 8 «Служба проверки подлинности в Интернете» в этой книге.

Управление учетом В качестве службы учета VPN-сервер может использовать Windows или RADIUS.

В первом случае учетная информация записывается в файл журнала на VPN-сер вере, во «тором — сообщения с учетной информацией поступают на сервер RADII'S.

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

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

Управление сетью Если на компьютер с Windows 2000, работающий в качестве VPN-сервера, устано вить службу SNMP, он сможет действовать в среде SNMP (Simple Network Mana gement Protocol) как агент SNMP. VPN-сервер регистрирует управляющую инфор Удаленный доступ 352 ЧАСТЬ манию в различных идентификаторах объектов МШ II (Management Information Base), которые устанавливаются со службой SNMP. Объекты МШ II документиро ваны в RFC 1213.

РРТР РРТР (Point-to-Point. Tunneling Protocol) инкапсулирует кадры РРР (Point-to-Point Protocol) в IP-дейтаграммы для передачи через межсетевую IP-среду, например Интернет или частную интрасеть. РРТР документирован в RFC 2637.

Для создания, поддержания и закрытия туннеля протокол РРТР использует TCP соединение, известное под названием «управляющее РРТР-соединенис» (РРТР control connection), а для инкапсуляции РРР-кадров как туннелированных данных — модифицированную версию GRE (Generic Routing Encapsulation). Собственно дан ные инкапсулированных РРР-кадров можно шифровать и/или сжимать.

РРТР требует наличия межсетевой IP-среды между РРТР-клиентом (VPN-клиен том, использующим протокол туннелирования РРТР) и РРТР-сервером (VPN-сер вером, использующим тот же протокол). РРТР-клиент может быть уже подключен к межсетевой IP-среде, через которую достижим РРТР-сервер, либо он может доз ваниваться до сервера доступа в сеть (NAS) и устанавливать IP-соединение — так же, как и пользователь, получающий доступ в Интернет по коммутируемой линии.

Аутентификация, выполняемая при создании VPN-соединения на основе РРТР, осуществляется с применением тех же механизмов, что и при установлении РРР соединепий, — например, ЕАР (Extensible Authentication Protocol), MS-CHAP (Microsoft Challenge-Handshake Authentication Protocol), CHAP, SPAP (Shiva Pass word Authentication Protocol) и PAP (Password Authentication Protocol). РРТР на следует методы шифрования и/или сжатия полезных данных РРР от протокола РРР. В случае Windows 2000 для шифрования этих данных по методу МРРЕ (Micro soft Point-to-Point Encryption) следует использовать либо EAP-TLS (SAP-Transport Level Security), либо MS-CHAP.

МРРЕ обеспечивает шифрование не на всем пути передачи данных (между клиен тским приложением и сервером, на котором размещен ресурс или сервис;

, исполь зуемый этим приложением), а лишь при их прохождении по каналу. Для шифрова ния на всем пути передачи данных нужно использовать IPSec, который будет шиф ровать IP-трафик после создания РРТР-тупнеля.

РРТР-сервер на основе Интернет-стандартов представляет собой VPN-сервер с поддержкой РРТР;

при этом один из его интерфейсов подключен к Интернету, а другой — к интрасети.

Поддержание туннеля с помощью управляющего РРТР-соединения Управляющее Р РТР-соединение устанавливается между динамически назначаемым TCP-портом РРТР-клиента и зарезервированным ТСР-нортом 1723 РРТР-серве ра. По этому соединению РРТР управляет вызовами и передает управляющие со общения, используемые для поддержания РРТР-туннеля. К ним относятся Р РТР сообщения Echo-Request и Echo-Reply, позволяющие распознавать обрыв связи между РРТР-клиентом и сервером. Пакет, передаваемый по управляющему РРТР соединению состоит из IP- и TCP-заголовков, управляющего РРТР-сообщения, а также заголовка и концевой части канальною уровня (рис, 9-8).

ГЛАВА 9 Виртуальные частные сети Концевая Заголовок Управляющее часть канального IP TCP канального РРТР-сообщ&ние уровня уровня Рис. 9-8. Пакет, передаваемый по управляющему РРТР-соединению В таблице 9-5 перечислены основные управляющие РРТР-сообщсння, передавае мые по управляющему РРТР-соединению. Конкретный РРТР-туннель для всех управляющих РРТР-сообщений идентифицируется но ТСР-соедииению.

Таблица 9-5. Основные управляющие РРТР-сообщения Сообщение Описание Start-Control-Connection-Request Посылается РРТР-клиентом для установления управ,гя ющего соединения. До передачи любых других РРТР сообщений для каждого РРТР-туннеля нужно создат.

свое управляющее соединение.

Start-Control-Connection-Reply Посылается РРТР-сервером в ответ па сообщение SUirt Control-Connection-Request.

Посылается РРТР-клиентом для создания РРТР-туш.с Outgoing-Call-Request ля. В это сообщение включается идентификатор вызова (Call ID), используемый в GRE-заголовке для определе ния туннелируемого трафика, передаваемого по кон кретному туннелю.

Outgoi ng-Call - Reply Посылается РРТР-сервером в ответ на сообщение Outgoing-Call-Request.

Посылается РРТР-клиентом или сервером для провер Echo-Request ки активности соединения. Если ответ на.это сообщение не поступает, РРТР-туннель через определенное врем и закрывается.

Ответ на сообщение Echo-Request.

Echo-Reply Примечание: РРТР-сообщения Echo-Request и Echo Reply не имеют никакого отношения к ЮМР-сообщени ям Echo Request (Эхо-запрос) и Echo Reply (Эхо-ответ), Посылается РРТР-сервером всем VPN-клиентам, чтоиы WAN-Error-Notify сообщить о какой-либо ошибке, возникшей на РРР интерфейсе РРТР-сервера.

Посылается РРТР-клиентом или сервером для установ Set-Link-Info ки согласованных РРР-параметров.

Посылается РРТР-клиентом для закрытия туннеля.

Call-Clear-Request Посылается РРТР-сервером в ответ на сообщение Call Call-Disconnect-Notify Clear-Request или по другим причинам. Указывает, чти туннель должен быть закрыт.

Посылается РРТР-клиентом или сервером для уведом Stop-Control-Connection-Request ления другой стороны о закрытии управляющего соеди нения.

Ответ на сообщение Stop-Control-Conncction-Request.

Stop-Control-Connection-Reply Детальные сведения о точной структуре управляющих РРТР-сообщений см. в RFC 2637.

Удаленный доступ 354 ЧАСТЬ Туннелирование данных средствами РРТР Такое туннелирование осуществляется путем многоуровневого инкапсулирования.

Структура данных, тунпелирошнньтх средствами РРТР, показана на рис. 9-9.

Шифрованные полезные Концевая Заголоаок да иные РРР канального IP-загоповсж РРР-заголовок (IP- или 1РХ-йеИаграмш канального SRE-заголовок либо NetBEUI-кади уровня Рис. 9-9. Данные, туннелированные средствами РРТР Инкапсуляция РРР-кадра Исходные полезные данные РРР зашифровываются и инкапсулируются в кадр с РРР-заголовком (РРР-кадр). Затем этот кадр инкапсулируется в пакет с модифи цированным GRE-заголовком. GRE документирован в RFC 1701 и 1.702 и изначаль но был разработан в качестве простого универсального механизма инкапсуляции данных, передаваемых через межсетевые IP-среды. GRE является клиентским про токолом IP и использует идентификатор IP-протокола 47.

GRE-заголовок модифицируется для РРТР следующим образом.

• Бит подтверждения указывает на наличие 32-битного поля подтверждения.

• Поле ключа заменяется 16-битными полями длины полезных данных и иденти фикатора вызова. Последнее устанавливается РРТР-клиеитом при создании РРТР-туннеля.

• Добавляется 32-битное поле подтверждения.

Внутри GRE-заголовка в поле типа протокола записывается значение Ох880В, ис пользуемое как значение EtherType для РРР-кадра.

Примечание GRE иногда используется ISP для пересылки информации о маршру тизации внутри своих сетей. Чтобы эта информация не пересылалась на маршру тизаторы Интернет-магистралей (Internee backbone routers), ISP отфильтровывают GRE-трафик на интерфейсах, подключенных к Интернет-магистралям. В результа те такой фильтрации создавать РРТР-туннели с использованием управляющих РРТР-сообтцений можно, но пересылать данные, туннелированные средствами РРТР, нельзя. Если Вы подозреваете наличие именно этой проблемы, свяжитесь со своим IS Р.

Инкапсуляции GRE-пакета GRE-пакет далее инкапсулируется в пакет с IP-заголовком, в котором указывают ся IP-адреса отправителя и получателя (в роли которых выступают РРТР-клиент и сервер).

Инкапсуляция канального уровня Для передачи по локальной сети (LAN) или WAN-каналу созданная на предыду щем этапе IP-дейтаграмма инкапсулируется в пакет с заголовком и концевой час тью канального уровня, применяемого на данном физическом интерфейсе. Напри мер, при передаче через Ethernet-интерфейс IP-дейтаграмма инкапсулируется в пакет с Ethernet-заголовком и концевой частью, а при передаче по WAN-каналу Виртуальные частные сети ГЛАВА 9 типа «точка-точка» (аналоговой телефонной линии или ISDN) — в пакет с РРР заголовком и концевой частью.

Обработка туннелированных данных Получив туннелированные средствами РРТР данные, РРТР-клиент или сервер выполняет следующие операции.

1. Обрабатывает и удаляет заголовок и концевую часть канального уровня.

2. Обрабатывает и удаляет IP-заголовок.

3. Обрабатывает и удаляет GRE- и РРР-заголовки.

4. Расшифровывает и/или декомпрессирует полезные данные РРР (если это нужно), 5. Обрабатывает полезные данные или пересылает их.

РРТР-пакеты и сетевая архитектура Windows Рис. 9-10 иллюстрирует путь, который проходят туннелированные данные (от VPN клиента по VPN-соединению удаленного доступа, установленному с помощью ана логового модема) через компоненты сетевой архитектуры Windows 2000. Вот что происходит на этом пути.

1. IP- или IPX-дейтаграмма либо NetBEUI-кадр передается соответствующим про токолом через NDIS (Network Driver Interface Specification) на виртуальный интерфейс, представляющий VPN-соединение.

2. NDIS передает пакет NDISWAN, который расшифровывает и/или декомпресси рует данные и предоставляет РРР-заголовок, включающий только поле иденти фикатора РРР-протокола. Поля флагов и PCS (Frame Check Sequence) не до бавляются. Это предполагает, что на LCP-этапе процесса установления РРР-со единения было согласовано сжатие полей адреса и управления. Подробнее о РРР и LCP см. главу 7 «Сервер удаленного доступа» в этой книге.

3. NDISWAN передает данные драйверу протокола РРТР, который инкапсулирует РРР-кадр в пакет с GRE-заголовком. В поле идентификатора вызова в GRE-;

;

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

4. Полученный пакет драйвер протокола РРТР передает драйверу протоколов TCP/IP.

5. Этот драйвер инкапсулирует туннелированные средствами РРТР данные в па кет с IP-заголовком и передает его через NDIS интерфейсу, представляющему соединение удаленного доступа с местным ISP.

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

7. NDISWAN передает полученный РРР-кадр минипорт-драйверу WAN, представ ляющему аппаратные средства удаленного доступа, например асинхронный порт (в случае модемного соединения).

Примечание Бы можете согласовать использование шифруемого РРР-соединения по коммутируемому соединению с ISP. Однако делать это не рекомендуется, так как данные, передаваемые по туннелю, уже зашифрованы. Дополнительный уровень шифрования может отрицательно повлиять на производительность.

Удаленный доступ 356 ЧАСТЬ — Пакет начинает свой путь отсюда NDIS NDISWAN Х.25 ISDN ' Шифрованные полезные данные РРР Концевая IP-заголовок GRE-заголовок РРР-заголовок (IP- или IPX-дейтаграмма часть РРР РРР-заголовок пайс NetBElfl-кадр), i.. :

Структура конечного пакета Рис. 9-10. Обработка РРТР-пакета в сетевой архитектуре Windows Network Load Balancing и РРТР Компонент Network Load Balancing к Windows 2000 Advanced Server позволяет со здать кластер РРТР-сервсров для более надежной поддержки VPN-соединений.

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

t. Сконфигурируйте каждого участника кластера как РРТР-сервер Windows 2000.

Подробнее на эту тему см. справочную систему Windows 2000 Server.

2. Настройте набор РРТР-ссрверов как кластер Network Load Balancing. Подроб нее о настройке Network Load Balancing см. справочную систему Windows Advanced Server. Настраивая Network Load Balancing на каждом РРТР-сервере, разрешите балансировку сетевой нагрузки на интерфейсе, принимающем запро сы на РРТР-соединения. Учтите, что этому интерфейсу назначаются IP-адрес кластера и выделенный IP-адрес. Чтобы избежать проблем при создании РРТР шединений с РРТР-клиентами Windows 95. Windows NT 4.0 и Windows 98, уда лите выделенный IP-адрес на интерфейсе, принимающем запросы на РРТР-со единения. Для этого на каждом РРТР-сервере кластера используйте окно свойств TCP/IP, открываемое через апплет Network and Dial-up Connections (Сеть и удаленный доступ к сети).

3. Удаление выделенного IP-адреса не позволит удаленно управлять индивидуаль ными серверами с использованием ;

->того IP-адреса. Поэтому для удаленного управления отдельными РРТР-серверами в кластере нужно установить на каж дом сервере дополнительный LAN-интерфейс и подключить его к сегменту сети, отличному от того, к которому подключен интерфейс, принимающий запросы на РРТР-соединения, У РРТР-сервера Интернета обычно имеется дополнитель ный интерфейс интрасети. После удаления выделенного IP-адреса на Интернет Виртуальные частные сети ГЛАВА интерфейсе Вы сможете удаленно управлять этим Р РТР-серне ром ш интрасети (но не из Интернета).

Примечание Пока Вы не удалите выделенный IP-адрес РРТР-сервсра, входящего is кластер, РРТР-клиенты Windows 95, Windows NT 4.0 и Windows 98, вероятно, не смогут подключаться к нему. Это связано с тем, что такие клиенты посылают сши запросы на IP-адрес кластера, а индивидуальный РРТР-сервер может ответить на запрос не с кластерного, а с выделенного IP-адреса. В последнем случае РРТР-кли еит обнаружит, что ответ поступил с IP-адреса, отличного от того, на который он посылал запрос, сочтет это нарушением безопасности РРТР-соединения и разор вет связь.

L2TP и IP-безопасность L2TP (Layer Two Tunneling Protocol) — это комбинация РРТР и L2F (Layer Forwarding), технологии, предложенной компанией Cisco® Systems. Inc. Чтобы два несовместимых протокола туннелирования не конкурировали на рынке и не запу тывали заказчиков, IETF распорядился скомбинировать эти две технологии в один протокол туннелирования, который сочетал бы в себе лучшие качества РРТР и L2F.

L2TP документирован в RFC 2661, L2TP инкапсулирует РРР-кадры, передаваемые по сетям IP, X.25. Frame Relay тии ATM. В настоящее время определен стандарт только на L2TP поверх IP. При пере даче по межсетевой IP-среде 1-2ТР-кадры инкапсулируются как UDP-сообщения.

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

L2TP использует UDP-сообщения в межсетевых IP-средах для управления тунне лями и передачи туннелированных данных. Полезные данные инкапсулированных РРР-кадров могут быть зашифрованы и/или сжаты;

однако Ь2ТР-клиенты под уп равлением Windows 2000 не могут использовать МРРЕ для L2TP-coe;

7iineHHfl. По этому шифрование для таких соединений реализуется за счет IPSec-прогокола ESP.

Windows 2000 позволяет создавать L2TP-coe/TmneHH#, не шифруемые с помощью IPSec (IP-безопасность). Но в таком случае Вы не получите VPN-соединение, не скольку конфиденциальные данные, инкапсулируемые L2TP, окажутся незашиф рованными. Нешифруемые Е2ТР-соединения можно использовать в качестве вре менной меры при устранении каких-либо проблем с поддержкой соединении L2TP поверх IPSec;

при этом Вы исключаете IPSec-процессы аутентификации п согласования.

L2TP требует наличия межсетевой IP-среды между Ь2ТР-клиентом (VPN-клиен том, использующим протокол тупнелирования L2TP и IPSec) и L2TP-cepnepoM (VPN-сервером, использующим тот же протокол и IPSec). Е2ТР-клиент может быть уже подключен к межсетевой IP-среде, через которую достижим Е2ТР-сервер, либо он может дозваниваться до сервера NAS и устанавливать IP-соединение — так же как и пользователь, получающий доступ в Интернет по коммутируемой линии.

Аутентификация, выполняемая при создании L2TP-туннелей, осуществляется с применением тех же механизмов, что и при установлении РРР-соединений, — на пример, ЕАР, MS-CHAP, CHAP, SPAP и PAP.

ЧАСТЬ 2 Удаленный доступ L2TP-сервер на основе Интернет-стандартов представляет собой сервер удаленно го доступа с поддержкой L2TP;

при этом один из его интерфейсов подключен к Интернету, а другой — к интрасети.

Пакеты с информацией, управляющей Ь2ТР-туннелем, и туннелированными дан ными имеют одинаковую структуру.

Поддержание туннеля с помощью управляющих 1_2ТР-сообщений L2TP — в отличие от РРТР — не требует для поддержания туннеля отдельного TCP-соединения. Ь2ТР-трафик передается между Ь2ТР-клиентом и сервером в виде UDP-сообщений. В Windows 2000 для этого используется UDP-порт 1701.

Примечание 1.2ТР-клиент и сервер в Windows 2000 всегда используют UDP-порт 1701. Однако Ь2ТР-сервер под управлением Windows 2000 поддерживает L2TP клиенты, работающие с другим UDP-портом.

Управляющие сообщения L2TP поверх IP посылаются как UDP-дейтаграммы. В варианте, реализованном в Windows 2000, эти I'DP-дейтаграммы передаются в виде зашифрованных полезных данных IPSec-протокола ESP (рис. 9-11), •'-.• Концевая Концевая Заголовок -. Кошевая часть ISP канального IP- ШР~ часть ESP- L2TP заголовок заголовок заголовок сообщение часть ESP Authentication канального уровня :

уровня • ' L Шифруется IPSec Рис. 9-11. Управляющее Ь2ТР-сообщение Поскольку TCP-соединение не используется, L2TP — чтобы гарантировать достав ку Ъ2ТР-сообщений — применяет их упорядочение (message sequencing). Поля Next-Received (по аналогии с TCP-полем подтверждения) и Next-Sent (по анало гии с TCP-полем номера последовательности) внутри управляющего 1.2ТР-сооб щения предназначены для слежения за последовательностью сообщений. Пакеты, выпадающие из должной последовательности, отбрасываются. Поля Next-Sent и Next-Received могут также использоваться для упорядоченной доставки и управ ления потоком туннелировапных данных.

L2TP поддерживает по несколько вызовов на каждом туннеле. С этой целью в уп равляющем Ь2ТР-сообщении в L2TP-заголовке туннелированных данных присутству ют поля идентификатора туннеля и идентификатора вызова (для данного туннеля).

Основные управляющие Ь2ТР-сообщения перечислены в таблице 9-6.

Таблица 9-6. Основные управляющие Ь2ТР-сообщения Сообщение Описание Start-Control-Conitection-Request Посылается Ь2ТР-клиситом для установления уп равляющего соединения. До передачи любых других L2TP-сообщений для каждого Ь2ТР-туннеля нужно создать свое управляющее соединение.

Виртуальные частные сети ГЛАВА Таблица 9-6. (продолжение) Сообщение Описание Посылается L2TP-cepBepOM в ответ на сообщение Siart- Control- Connection-Reply Start-Control-Cormection-Request (см. также ниже).

Start-Control-Connection-Connected Посылается L2TP-клиентом в ответ на сообщение Starc-Control-Connection-Reply.

Outgoing-Call-Request Посылается Ь2ТР-клиентом для создания L2TP туннеля. В это сообщение включается назначенный идентификатор вызова (Assigned Call ID), определя ющий конкретный вызов по данному туннелю.

Посылается Ь2ТР-сервером в ответ на сообщение Outgoing-Call-Reply Outgoing-Cail-Rcquest.

Start-Control-Connection-Connected Посылается Ь2ТР-клиентом в ответ на сообщение Outgoing-Call-Reply.

Helio Посылается 1,2ТР-клиентом или сервером для про верки активности соединения. Если прием этого сообщения не подтверждается, Ь2ТР-тукнель через определенное время закрывается.

Посылается Ь2ТР-ссрвером всем VPN-клиентам, WAN-Error-Notify чтобы сообщить о какой-либо ошибке, возникшей на РРР-интерфейсе L2TP-cepsepa.

Посылается LSTP-клиентом или сервером для уста Set-Link-Info новки согласованных РРР-параметров.

Call-Disconnect-Notify Посылается Ь2ТР-сервером или клиентом для уве домления другой стороны о том, что данный вызов в данном туннеле должен быть завершен.

Посылается L2TP-сервером или клиентом для уве Stop-Control-Conncction-Notification домления другой стороны о том, что туннель должен быть закрыт.

Детальные сведения о точной структуре управляющих Ь2ТР-сообщений см. в про екте Интернет-документа по L2TP.

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

Структура данных, туннелированпых средствами L2TP, показана на рис. 9-12.

•" • Полезные данные Коневая Концевая Заголовок (Р-заго- ESP-зшъ УОР-за- 12ГР-за- РРР-за- РРР рр-ляи Квицевая часть ESP часть канального ловок ловок гшовок головои голавок IPX-дейтаграмма часть KSP Authentication канал ьяого уровня либо NetBEUI-кадр) уровня Шифруется Подписывается для аутентификации по IPSec-поотоколу ESP Рис. 9-12. Инкапсуляция Ь2ТР-пакета 360 ЧАСТЬ 2 Удаленный доступ Инкапсуляция L2TP Изначальные полезные данные РРР инкапсулируются с использованием РРР- и Ь2ТР-заголовков.

Инкапсуляция UDP Пакет, инкапсулированный L2TP, инкапсулируется в сообщение с UDP-заголОБКОМ, а порты отправителя и получателя устанавливаются как 1701.

Инкапсуляция IPSec UDP-сообщение зашифровывается па основе политики IP-безопасности и инкап сулируется в пакет с заголовком и концевой частью ESP (Encapsulating Security Payload);

кроме того, добавляется концевая часть ESP Authentication, необходимая для аутентификации по IPSec-протоколу ESP.

Инкапсуляция IP IPSec-пакет инкапсулируется в IP-дейтаграмму с IP-заголовком, который содержит IP-адреса отправителя и получателя, соответствующие VPN-клиенту и серверу.

инкапсуляция канального уровня Для передачи по локальной сети или WAN-каналу созданная на предыдущем этапе IP-дейтаграмма инкапсулируется в пакет с заголовком и концевой частью каналь ного уровня, применяемого на данном физическом интерфейсе. Например, при пе редаче через Ethernet-интерфейс IP-дейтаграмма инкапсулируется в пакет с Ether net-заголовком и концевой частью, а при передаче по WAN-каналу типа «точка-точ ка» (аналоговой телефонной линии или ISDN) — в пакет с РРР-заголовком и кон цевой частью.

Обработка данных, туннелированных L2TP поверх IPSec Получив данные, туннелированные средствами L2TP поверх IPSec, 1_2ТР-клиент или сервер выполняет следующие операции.

1. Обрабатывает и удаляет заголовок и концевую часть канального уровня, 2. Обрабатывает и удаляет IP-заголовок.

3. Используя концевую часть "ESP Authentication, проверяет подлинность полез ных данных IP и ESP-заголовка.

4. Используя ESP-заголовок, расшифровывает зашифрованную часть пакета.

5. Обрабатывает UDP-заголовок и передает Ь2ТР-пакет протоколу L2TP.

6. L2TP считывает содержимое полей идентификатора туннеля и идентификатора вызова в L2TP-заголовке, чтобы определить конкретный 1.2ТР-туинель.

7. Идентифицирует по РРР-заголовку полезные данные РРР и передает их драй веру соответствующего протокола для обработки.

Пакеты L2TP поверх IPSec и сетевая архитектура Windows 2QOQ Рис. 9-13 иллюстрирует путь, который проходят туннелированные данные (от VPN клиента по VPN-соединению удаленного доступа, установленному с помощью ана логового модема) через компоненты сетевой архитектуры Windows 2000. Вот что происходит на этом пути.

Виртуальные частные сети ГЛАВА 1. IP- или IPX-дейтаграмма либо NetBEUI-кадр передается соответствующим протоколом через NDIS на виртуальный интерфейс, представляющий VP\"-co ед и пение.

2. NDIS передает пакет NDISWAN, который декомпрессирует данные (при необ ходимости) и предоставляет РРР-заголовок, включающий только поле иденти фикатора РРР-протокола. Поля флагов и FCS не добавляются, 3. ND1SWAN передает РРР-кадр драйверу протокола L2TP, который инкапсули рует этот кадр в пакет с Ь2ТР-заголовком. В поля идентификаторов туннеля и вызова в Ь2ТР-заголовке записываются значения, идентифицирующие туннель и вызов.

4. Полученный пакет драйвер протокола L2TP передает драйверу протоколов TCP/IP и уведомляет его о том, что данный Ь2ТР-пакет следует отправить как UDP-сообщение с UDP-порта 1701 клиента в UDP-порт 1701 сервера (при этом указываются IP-адреса клиента и сервера).

5. Драйвер протоколов TCP/IP формирует IP-пакет, добавляя необходимые II*- и UDP-гшголовки. Далее этот IP-пакет анализируется IPSec и приводится в соот ветствие с текущей политикой IP-безопасности. В зависимости от параметров политики IPSec шифрует UDP-часть IP-пакета и добавляет требуемые заголо вок и концевые части ESP. Перед началом ESP-пакета добавляется исходный [Р.чаголовок со значением в поле протокола, равным 50. Затем драйвер протоко лов TCP/IP передает полученный пакет через NDIS интерфейсу, представляю щему соединение удаленного доступа с местным ISP.

6. NDIS передает пакет NDISXVAN, который добавляет РРР-заголовок и концег:ую часть.

7. NDIS WAN передает полученный РРР-кадр минипорт-драйверу WAN, представ ляющему аппаратные средства удаленного доступа.

| Пакет начинает — свай путь отсюда ' NDIS Концевая РРР-за- fP-заго- ESP-заго- УОР-за- ШР-аа- РРР-за- Концева;

;

* часть ESP головок повок ловок гояоаок fonmoK голшзок часть ESP Authentication часть PF'P Структура конечного пакета Рис. 9-13. Обработка Ь2ТР-пакета в сетевой архитектуре Windows ЧАСТЬ 2 Удаленный доступ Примечание Вы можете согласовать использование шифруемого РРР-соединения по коммутируемому соединению с ISP. Однако делать это не рекомендуется, так как данные, передаваемые по туннелю, уже зашифрованы. Дополнительный уровень шифрования может отрицательно повлиять на производительность.

Защита виртуальных частных сетей Защита — важный элемент VPN. В следующих разделах описываются средства за щиты, поддерживаемые РРТР и L2TP поверх IPSec для VPN-соединений.

РРТР-соединения РРТР обеспечивает аутентификацию пользователей и шифрование данных.

Аутентификация пользователей с помощью РРР Пользователь, запрашивающий РРТР-соединение, аутентифицируется по одному из РРР-протоколов аутентификации: ЕАР, MS-CHAP, CHAP, SPAP или PAP. Для РРТР-соединений настоятельно рекомендуется использовать EAP-TLS в сочетании со смарт-картами либо MS-CHAP версии 2, поскольку именно эти протоколы под держивают взаимную аутентификацию и являются самыми безопасными методами обмена удостоверениями.

Шифрование методом МРРЕ РРТР поддерживает шифрование методом МРРЕ, который основан на алгоритме RSA (Rivest-Shamir-Adleman) RC4. МРРЕ доступен только при использовании EAP-TLS или MS-CHAP (версии 1 или 2).

МРРЕ оперирует с 40-, 56- или 128-битными шифровальными ключами. 40-битный ключ предназначен для обратной совместимости с клиентами под управлением опе рационной системы, отличной от Windows 2000. По умолчанию VPN-клиент и сер вер договариваются о применении самого стойкого ключа из числа поддерживае мых. Если VPN-сервер требует более стойкого ключа, не поддерживаемого VPN клиентом, запрос на соединение отклоняется.

Изначально МРРЕ был разработан для шифрования данных на пути их передачи по каналу связи тина «точка-точка», где пакеты принимаются в том порядке, в ка ком они были отправлены, и потери пакетов невелики. В такой среде расшифровка очередного пакета зависит от результатов расшифровки предыдущего.

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

Фильтрация пакетов средствами РРТР VPN-сервер на основе РРТР обычно снабжен двумя физическими интерфейсами:

один подключен к общедоступной сети (например, к Интернету), другой — к част ной интрасети. Кроме того, у него имеется виртуальный интерфейс, соединяющий Виртуальные частные сети ГЛАВА 9 его со всеми VPN-клиентами. Чтобы VPN-сервер мог пересылать трафик между VPN-клиентами, ПА всех его интерфейсах нужно включить поддержку ТР-пересыл ки. Однако включение поддержки пересылки между двумя физическими интерфей сами приводит к тому, что VPN-сервер перенаправляет весь IP-трафик из общедо ступной сети в интрассть. Для защиты интрасети от постороннего трафика Вы дол жны настроить фильтрацию пакетов в РРТР так, чтобы VPN-сервер передавал дан ные только между VPN-клиентами и интрасетью и блокировал обмен пакетами между интрасетью и потенциально опасными пользователями общедоступной сети.

Фильтрацию пакетов средствами РРТР можно настроить либо на VPN-сервере, либо на промежуточном брандмауэре (см. раздел «Виртуальные частные сети и брандмауэры» далее в этой главе).

Соединения L2TP поверх IPSec «L2TP поверх IPSec» обеспечивает аутентификацию пользователей, взаимную аутентификацию компьютеров, шифрование, аутентификацию данных и проверку их целостности.

Аутентификация пользователей с помощью L2TP поверх IPSec Аутентификация VPN-клиента осуществляется на двух уровнях: сначала проверя ется подлинность компьютера, затем — пользователя, IPSec аутентификация компьютеров Взаимная аутентификация компьютеров VPN-клиента и сервера выполняется пу тем обмена машинными сертификатами при создании IPSec-протоколом ESP со поставления безопасности (security association, SA). IPSec SA устанавливается на в го ром этапе процесса IPSec-согласования;

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

Для использования L2TP поверх JPSec у VPN-клиента и сервера должны быть ма шинные сертификаты. Вы можете получать их автоматически, выбрав в Group Policy (Групповая политика) автоматический запрос сертификатов, или вручную — через оснастку Certificates (Сертификаты). Подробнее на эту тему см. справочную систему Windows 2000 Server.

LZTP-эутентификация на уровне пользователей Пользователь, запрашивающий Ь2ТР-соединение, аутентифицируется по одному из РРР-протоколов аутентификации: ЕАР, MS-CHAP, CHAP, SPAP или PAP. Посколь ку процесс установления РРР-соединения защищается средствами шифрования IPSec, можно использовать любой метод РРР-аутентификации. Взаимная аутенти фикация на уровне пользователей выполняется только при выборе MS-CHAP v или EAP-TLS.

Аутентификация 12ТР-туннеля В процессе установления Ь2ТР-туннеля протокол L2TP позволяет аутентифици ровать конечные точки этого туннеля. Эта операция называется аутентификацией Ь2ТР-туннеля. По умолчанию Windows 2000 ее не выполняет. Подробнее о и i стройке Windows 2000 на аутентификацию Ь2ТР-туннеля см. по ссылке Microsoft Knowledge Base на Web-странице http://windows.microsoft.com/windows2000/res kit/web resources.

Удаленный доступ 364 ЧАСТЬ Шифрование с помощью L2TP поверх IPSec Метод шифрования выбирается при установлении IPSec SA. Доступные методы шифрования включают:

• DES с 56-битным ключом;

• 3DES (Triple DES), использующий три 56-битных ключа и предназначенный для сред с жесткими требованиями к безопасности.

Так как IPSec рассчитан на межсетевые IP-среды, в которых возможна потеря па кетов и их доставка в неверпом порядке, каждый IPSec-пакет зашифровывается независимо от других IP Sec-пакетов.

Исходные шифровальные ключи генерируются в процессе IP See-аутентификации.

При соединениях с шифрованием по методу DES новые шифровальные ключи ге нерируются через каждые 5 минут или 250 Мб переданной информации, а при со единениях с шифрованием по методу 3DES — каждый час или через каждые 2 Гб переданной информации. Для соединений, защищаемых АН, новые хэш-ключи тоже генерируются каждый час или через каждые 2 Гб переданной информации, Подробнее об IPSec см. главу 8 «IP-безопасность» в книге «Сети TCP/IP» из се рии «Ресурсы Microsoft Windows 2000 Server».

Аутентификация данных и проверка их целостности средствами L2TP поверх IPSec Аутентификация и проверка целостности данных реализуется одним из следующих алгоритмов:

• НМАС (Hash Message Authentication Code) MD5 (Message Digest 5) — генери рует 128-битный хэш аутентифипированных полезных данных;

• НМАС SHA (Secure Hash Algorithm) — генерирует 160-битный хэш аутентифи цированных полезных данных.

Фильтрация пакетов средствами L2TP поверх IPSec Как и в случае VPN-соединений на основе РРТР, включение поддержки пересылки между интерфейсами общедоступной сети и интрасети приводит к тому, что VPN сервер перенаправляет весь IP-трафик из общедоступной сети в интрасеть. Для за щиты интрасети от постороннего трафика Вы должны настроить фильтрацию па кетов средствами L2TP поверх IPSec так, чтобы VPN-сервер передавал данные только между VPN-клиентами и интрасетью и блокировал обмен пакетами между иптрасетыо и потенциально опасными пользователями общедоступной сети.

Фильтрацию пакетов средствами L2TP поверх IPSec можно настроить либо на VPN-сервере, либо на промежуточном брандмауэре (см. раздел «Виртуальные час тные сети и брандмауэры* далее в этой главе).

Адресация и маршрутизация при использовании виртуальных частных сетей Чтобы понять, как работают виртуальные частные сети (VPN), Вы должны разоб раться в том, как создание VPN-соединений удаленного доступа и VPN-соедине нии между маршрутизаторами влияет на адресацию и маршрутизацию. VPN-соеди нение образует виртуальный интерфейс, которому нужно назначить соответствую Виртуальные частные сети ГЛАВА 9 щий IP-адрес;

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

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

IP-адреса и VPN-клиент удаленного доступа VPN-клиент удаленного доступа перед созданием VPN-соединения с VPN-серве ром сначала подключается к Интернету и из-за этого получает два IP-адреса:

• при установлении РРР-соедииения NAS-сервер ISP присваивает клиенту обгний IP-адрес (в IPCP-пропессе согласования);

• при создании VPN-соединения VPN-сервер (в ГРСР-пропессе согласования) назначает клиенту IP-адрес из диапазона адресов своей интрасети. Этот ТР-ад рес может быть общим (видимым в Интернете) или частным (невидимым в Интернете) в зависимости от того, какие адреса используются в данной интра сети — общие или частные.

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

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

Пример адресации при удаленном доступе показан на рис. 9-14. В данной интрасе ти используются частные адреса, и, кроме того, тупнелированпые данные переда ются в виде IP-дейтаграмм.

Маршруты по умолчанию и клиенты удаленного доступа Когда клиент удаленного доступа дозванивается до ISP, он обычно получает общий IP-адрес от NAS-сервера ISP. При этом адрес основного шлюза в IPCP-пропессе согласования не назначается. Поэтому, чтобы иметь возможность обращаться по любым адресам в Интернете, клиент удаленного доступа добавляет в свою таблицу маршрутизации маршрут по умолчанию, использующий интерфейс удаленного до ступа, подключенный к ISP В результате клиент может посылать IP-дейтаграммы NAb серверу 1SP, через который они перенаправляются на нужные адреса R Интернете.

Если у клиента удаленного доступа нет других TCP/IP-интерфейсов, именно этч схема ему и нужна. Но она может вызвать проблемы в случае клиентов удаленного доступа, имеющих LAN-подключение к какой-либо интрасети. В этом вариант'.' маршрут по умолчанию уже существует и указывает па локальный маршрутизатор Удаленный доступ 366 ЧАСТЬ интрасети. Когда клиент удаленного доступа устанавливает соединение со своим ISP, исходный маршрут по умолчанию остается в таблице маршрутизации, но по лучает метрику с более высоким значением. Кроме того, добавляется новый марш рут по умолчанию с меньшей метрикой, соответствующий подключению к ISP.

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

Клиент удаленного доступа под управлением Windows 2000 создает такой маршрут автоматически (по умолчанию).

• Общие адреса ~ Частные адреса IP-адрес назначения: IP-адрес назначения:

VPN-сервер целевая интрасеть IP-адрес источника: IP-адрес источника:

выделяется ISP выделяется VPN-сервер Данные 1CP РРР IP 6RE IP приложения г ШР ISP VPN-соединение Клиент удаленного доступа Рис. 9-14, Общие и частные адреса в данных, туннелированных РРТР ^ Чтобы запретить создание маршрута по умолчанию:

1 В свойствах TCP/IP объекта соединения удаленного доступа откройте диалого вое окно Advanced TCP/IP Settings (Дополнительные параметры TCP/IP), пе рейдите на вкладку General (Обшие) и сбросьте флажок Use default gateway on remote network (Использовать основной шлюз в удаленной сети), Чтобы обеспечить связь как с адресами в интрасети, так и с адресами и Интернете, пока активно соединение с ISP, не сбрасывайте флажок Use default gateway on remote network, а в таблицу маршрутизации на клиенте удаленного доступа добавь те маршруты к интрасети. Эти маршруты можно добавить как статические (коман Виртуальные частные сети ГЛАВА дои route) или, если в интрасети используется протокол марифутизации RIP Пер сии 1, воспользоваться службой Route Listening Service для прослушивания тра фика RiP vl и динамического добавления нужных маршрутов. Тогда после соеди нения с ISP все адреса в интрасети будут достижимы через маршруты к интрасети, а все адреса в Интернете — через маршрут по умолчанию.

Маршруты по умолчанию и VPN-соединения через Интернет Когда клиент удаленного доступа дозванивается до ISP, он добавляет в свою таб лицу марифутизации маршрут по умолчанию, использующий соединение с JSP (рис. 9-15). С этого момента ему доступны все адреса в Интернете через маршру тизатор ш NAS-сервере ISP.

г Маршрут по умолчанию Интрасеть Рис. 9-15. Маршрут по умолчанию, созданный после установления соединения с ISP Когда VPN-клиент создает VPN-соединение, в его таблицу маршрутизации добав ляются еще один маршрут по умолчанию и маршрут к хосту, которые указывают IP-адрес сервера туннелирования (рис. 9-16). Прежний маршрут по умолчанию со храняется, но его метрика увеличивается. Добавление нового маршрута по умолча нию означает, что все адреса в Интернете, кроме IP-адреса сервера туннелирова ния, недостижимы до закрытия VPN-соединения.

г VPN-соединение Туннель - Маршрут по умолчанию ISI Интрасеть Рис. 9-16. Маршрут по умолчанию, созданный после инициации VPN-соединения Удаленный доступ 368 ЧАСТЬ Как и в случае клиента удаленного доступа, подключающегося к Интернегу, созда ние VPN-клиентом удаленного доступа VPN-соединения с частной интрасетью че рез Интернет влечет за собой одно из следующих последствий:

• пока VPN-соединение неактивно, адреса в Интернете достижимы, а в интрасе ти — пет;

• пока VPN-соединение активно, адреса в интрасети достижимы, а в Интернете — нет.

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

Л что касается VPN-клиентов, которым после установления VPN-соединения ну жен одновременный доступ и к интрасети, и к Интернету, то конкретное решение зависит от типа адресации в интрасети. Но в любом случае объект VPN-соедине ния следует настроить так, чтобы новый основной шлюз не добавлялся. Тогда пос ле создания VPN-соединения маршрут по умолчанию будет по-прежнему указывать адрес NAS-сервера ISP, что позволит обращаться по любым адресам в Интернете.

Исходя из тина адресации в интрасети одновременный доступ к ресурсам интрасе ти и Интернета реализуется следующим образом.

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

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

Перекрывающиеся или недопустимые адреса. Если в интрасети используются перекрывающиеся (overlapping) или недопустимые (illegal) адреса (идентификато ры IP-сетей, которые не являются частными и либо не зарегистрированы в Inter NIC, либо получены от ISP), эти IP-адреса могут дублировать общие адреса в Ин тернете. Если в таблицу маршрутизации на VPN-клиенте добавляются статические постоянные маршруты с перекрывающимися адресами, то совпадающие: с ними ад реса в Интернете недостижимы.

В каждом из этих случаев в таблицу маршрутизации на VPN-клиенте нужно до бавлять статические постоянные маршруты к идентификаторам сетей, используе мым в интрасети. Постоянные маршруты записываются в реестр, В Windows NT 4. с Service Pack 3 (или выше) и в Windows 2000 постоянные маршруты на самом деле не добавляются в таблицу IP-маршрутизации (и невидимы команде route print в Windows 2000) до тех пор, пока IP-адрес шлюза не станет достижимым. А это про исходит после установления VPN-соединения.

Каждый маршрут добавляется следующей командой:

ROUTE ADD <идентификатор_сети_для_интрасети> HASK <маска_сети> <1Р-адрес_виртуального_интерфейсаУРН-сервера> -р IP-адрес шлюза в командах route для каждого маршрута интрасети — это IP-адрес виртуального интерфейса VPN-сервера, а не его Интернет-интерфейса.

ГЛАВА Э Виртуальные частные сети Вы можете определить IP-адрес виртуального интерфейса VPN-сервера но IP-ад ресу интерфейса Internal (Внутренний), раскрыв в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) узлы IP Routing (IP-маршрутизация) и General (Общие). Если IP-адреса для VPN-клиентов и удаленного доступа к се тям выделяются через DHCP, то IP-адрес виртуального интерфейса VPN-сервера является первым ТР-адресом, полученным от DHCP. Если Вы сконфигурировали статический пул IP-адресов, то IP-адрес виртуального интерфейса VPN-сервера — первый IP-адрес из этого пула. Вы можете выяснить IP-адрес виртуального интер фейса VPN-сервера и таким способом: дважды щелкните объект активного VPN соединения и в диалоговом окне Status (Состояние) перейдите на вкладку Details (Сведения).

Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |   ...   | 13 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.