Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
Неш\Aiders 1Неш\Aiders 1
Неш\
Aiders 1
Неш\
Aiders 1
виртуапьных частных сетей в среде
WINDOWS 2000
Вззпяд эксперта на развертывание виртуапьных частных сетей в среде Windows 2000
Тадеуш Фортенбери
JVI.R.T.UAL. PRIVATE. NETWORKING
Thaddeus Fortenberry
Проектирование. в.ирту.ап.ьнь1х...час.т.нь.1Х.с.ете.й.вхреде
Тадеуш Фортенбери
Издательский дом "Вильяме"Москва • Санкт-Петербург • Киев2002
ISBN 5-8459-0240-1 (рус.)ISBN 1-57870-246-1 (англ.)ISBN 5-8459-0240-1 (рус.)ISBN 1-57870-246-1 (англ.)
ISBN 5-8459-0240-1 (рус.)
ISBN 1-57870-246-1 (англ.)
ISBN 5-8459-0240-1 (рус.)
ISBN 1-57870-246-1 (англ.)
ББК 32.973.26-018.2.75
Ф80
УДК 681.3.07
Издательский дом "Вильяме"
Зав. редакцией С.Н. Тригуб
Перевод с английского и редакция А.П. Сергеева
По общим вопросам обращайтесь в Издательский дом "Вильяме"
по адресу: info@williamspublishing.com, http://www.willia mspublishing com
Фортенбери, Тадеуш.
Ф80Проектирование виртуальныхчастныхсетейв среде Windows2000.:Пер.сангл.-
М. : Издательский дом "Вильяме", 2002. — 320 с. : ил. — Парал. тит. англ.
ISBN 5-8459-0240-1 (рус.)
В этой книге рассматривается разработка виртуальных частных сетей с помо- шью средств операционной системы Windows 2000. Здесь приводится описание инструментальных средств и методов, позволяющих проектировать различные виртуальные частные сети, предназначенные для выполнения самых разнообразных задач. Пошаговые процедуры, включенные в состав практически каждой главы, позволяют применять на практике изложенные теоретические сведения.
Книга рассчитана на пользователей средней и высокой квалификации.
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками соответствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и запись на магнитный носитель, если на это нет письменного разрешения издательства New Riders Publishing.
Authorized translation from the English language edition published by New Riders Publishing, Copyright © 2001
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher.
Russian language edition published by Williams Publishing House according to the Agreement with R&I Enterprises International, Copyright © 2002
© Издательский дом "Вильяме", 2002
© New Riders Publishing, 2001
Оглавление
Глава 1. Виртуальные частные сети. Введение21
Глава 2. Основы развертывания виртуальных частных сетей33
Глава 3. Виртуальные частные сети и Windows 200049
Глава 4. Протокол туннелирования "точка-точка" (PPTP)59
Глава 5. Сертификаты79
Глава 6. Протокол безопасности Internet (IPSec)109
Глава 7. Протокол туннелирования уровня 2 (L2TP)149
Глава 8. Прокси-серверы и серверы NAT169
Глава 9. Диспетчер подключений, политики удаленного доступа и служба IAS203
Глава 10. Маршрутизация и фильтрация225
Глава 11. Определение имен в Windows 2000245
Глава 12. Использование Active Directory в сетях VPN259
Приложение A. История и предмет виртуальных частных сетей 279
Приложение Б. Устранениепроблем289
Приложение В. Связь между протоколами
IPSec Windows 2000 и Cisco295
Приложение Г. Перспективы развития
сетевых технологий и VPN313
Содержание
Введение19
Глава 1. Виртуальные частные сети. Введение21
Историческая справка: виртуальные частные сети21
Принципы функционирования виртуальных частных сетей23
Альтернативные службы26
Прозрачные сетевые службы (TLS)26
Защищенная удаленная аутентификация (SRA) вызовов RPC26
Уровень защищенных сокетов (SSL)27
Общие методы применения виртуальных частных сетей27
Удаленная регистрация пользователей28
Сетевые каналы связи с филиалами офисов28
Внутренние сети29
Другие преимущества виртуальных частных сетей31
Резюме32
Глава 2. Основы развертывания виртуальных частных сетей33
Терминология33
Разработка проектов34
Дороговизна сетевого доступа35
Безопасность данных36
Методы несанкционированного доступа к сетевому трафику38
Развертывание виртуальных частных сетей43
Концепции проектирования сетей с использованием
технологии туннелирования46
Сетевая архитектура46
Сетевая топология46
Брандмауэры47
Резюме48
Глава 3. Виртуальные частные сети и Windows 200049
Active Directory50
Протокол РРТР51
Протокол L2TP52
Протокол IPSec53
Обмен ключей Internet (IKE)54
Протокол NAT54
Диспетчер подключений55
Сервер сертификатов55
Динамический DNS56
Гибко настраиваемый сетевой трафик56
Упрощенная настройка машрутизатора57
Резюме58
Глава 4. Протокол туннелирования “точка-точка” (РРТР)59
Принцип функционирования протокола РРТР60
Свойства протокола РРР60
Основы функционирования РРТР61
Шифрование РРТР62
Безопасность и протокол РРТР63
Процедура 4.1. Изменение настроек безопасности, заданных по умолчанию 66
Повышение производительности66
Процедура 4.2. Конфигурирование сервера для доступа клиентов РРТР67
Процедура 4.3. Конфигурирование связей офисных филиалов с помощью подключений типа "шлюз-шлюз" протокола РРТР69
Процедура 4.4. Конфигурирование клиентов для связи с серверами РРТР76
Резюме78
Глава 5. Сертификаты79
Понятие о сервере сертификатов79
Цифровые подписи81
Сертификаты Х.509 версии 381
Центр сертификации82
Доверительные отношения и иерархия ЦС83
Корневые иерархии83
Перекрестная иерархия сертификатов84
Регистрация сертификатов84
Проверка подлинности сертификата85
Отзыв сертификатов86
Модель хранилища сертификатов86
Реализация сервера сертификатов в виртуальных частных сетях88
Процедуры, обеспечивающие использование сертификатов Windows 200089
Процедура 5.1. Установка и конфигурирование центра сертификации89
Процедура 5.2. Конфигурирование Active Directory
с целью автоматического развертывания сертификатов91
Процедура 5.3. Запрос сертификата вручную с помощью консоли ММС93
Процедура 5.4. Использование Web-инструмента95
Процедура 5.5. Конфигурирование настроек Web-безопасности на ЦС предприятия96
Процедура 5.6, Присвоение сертификата смарт-карте на сервере97
Процедура 5.7, Присвоение сертификата смарт-карте для клиента98
Процедура 5.8. Конфигурирование сети VPN с помощью L2TP99
Процедура 5.9. Настройка процесса аутентификации, основанного на сертификатах102
Резюме108
Глава 6. Протокол безопасности Internet (IPSec)109
Коммуникации, выполняемые с ПОМОЩЬЮ протокола IPSec110
Транспортный режимПО
Туннельный режим111
Драйвер IPSec и стек протоколов TCP/IP111
Заголовок аутентификации113
Инкапсуляция полезной нагрузки системы безопасности (ESP)115
Независимость приложений116
Протоколы IPSec и SSL117
Выбор среды протокола IPSec118
Дополнительная информация о туннельном режиме IPSec119
Управление политиками IPSec120
Обзор функционирования протокола IPSec120
Поддержка безопасности по схеме “точка-точка”, реализуемой для двух систем в домене125
Создание пользовательской политики IPSec128
Установка туннеля IPSec между двумя узлами131
Конфигурирование целевого шлюза138
Проверка и мониторинг политики IPSec143
Активизация регистрации протокола IPSec144
Создание многих политик IPSec146
Резюме147
Глава 7. Протокол туннелирования уровня 2 (L2TP)149
Область применения протокола Windows 2000 L2TP/IPSec149
Протоколы L2TP и РРТР150
Транспортные возможности151
Процесс аутентификации151
Доставка пакетов152
Сертификаты152
Трансляция адресов153
Подробности реализации протокола L2TP154
Безопасность154
Детали реализации подключений, использующих протокол L2TP155
Аутентификация156
Шифрование L2TP157
Настройки протокола обмена ключей Internet158
Изменение характеристик ключа шифрования159
"Время жизни" ключа159
Ограничение ключа сеанса159
Методы обмена ключей (НЗ)160
Фаза один: основной режим обмена ключей160
Фаза два: скоростной режим для "времени жизни"161
Управление энергопотреблением161
Процедуры L2TP/ IPSec161
Процедура 7.1. Просмотр сертификата компьютера162
Процедура 7.2. Переход от протокола РРТР к протоколу L2TP163
Процедура 7.3. Изменение политики удаленного доступа163
Процедура 7.4. Мониторинг подключения L2TP164
Процедура 7-5. Создание политики IPSec для использования совместно
с L2TP/lPSec, применяющего предварительно распределенные ключи166
Резюме168
Глава 8. Прокси-серверы исерверы NAT169
Прокси-сервер170
Прокси-сервер приложения170
Прокси-сервер SOCKS171
Функции прокси-сервера: быстродействие и безопасность171
Быстродействие171
Безопасность171
Недостатки прокси-серверов172
Сервер трансляции сетевых адресов173
Преимущества сервера NAT174
Недостатки серверов NAT175
Брандмауэры175
Граничные серверы176
Трансляция сетевых адресов в Windows 2000176
Windows 2000 Professional: совместное использование подключений Internet 176
Windows 2000 Server полнофункциональный сервер NAT178
Различные серверные сетевые проекты179
Различные клиентские сетевые проекты185
Клиентские брандмауэры185
Клиентская служба сервера NAT186
Применение гибридных решений для клиентских подключений187
Поддержка двух подключений в местоположении удаленного офиса188
Применение прокси-сервера в качестве конечной точки туннеля189
Применение сервера NAT в качестве конечной точки туннеля190
Вкладывание туннелей из удаленных сетей
для достижения безопасности по схеме "точка-точка"191
Резюме по распределенным сетевым проектам192
Конфигурирование прокси-серверов и серверов NAT192
Установка совместно используемого подключения к Internet (ICS)192
Установка сервера NAT с помощью RRAS194
Процедура 8.2. Установка сервера NAT с помощью RRAS195
Общий доступ к подключению VPN201
Процедура 8.3. Совместный доступ к подключению VPN201
Резюме202
Глава 9. Диспетчер подключений, политики удаленного доступа и служба IAS203
Диспетчер подключений203
Использование диспетчера подключений204
Требования206
Реализация206
Политики удаленного доступа207
Свойства удаленного подключения для пользовательской учетной записи207
Политика удаленного доступа в Windows 2000209
Условия209
Права доступа211
Профиль212
Политики удаленного доступа и сервер Windows NT 4.0 RRAS Server216
Служба аутентификации Internet (1AS)217
Реализация в Windows NT217
Реализация в Windows 2000217
Свойства IAS217
Интеграция со службой RRAS219
Причины использованияRADIUS219
Инсталляция и конфигурирование службы IAS219
Резюме223
Глава 10. Маршрутизация и фильтрация225
Маршрутизация в Windows 2000225
Виды маршрутизации в Windows 2000226
Защищенные маршрутизируемые соединения228
Маршрутизация со стороны клиента229
Стандартный шлюз229
Недействительные постоянные маршруты233
Вопросы маршрутизации234
Зашита при маршрутизации235
Дополнительные вопросы клиентской маршрутизации235
Автоматическая частная IP-адресация (APIPA)237
Туннели и маршрутизация238
Фильтрация пакетов239
Размещение туннельного сервера перед брандмауэром240
Защита внутренних ресурсов241
Размещение туннельного сервера за брандмауэром242
Резюме244
Глава 11. Определение имен в Windows 2000245
Определение имен для туннельных клиентов246
Процедура 11.1. Конфигурирование клиента
с целью регистрации имени хоста для туннельного подключения247
Определение имен для домашней сети/филиала офиса248
Конфигурирование сервера DNS
для среды домашней сети/сети филиала офиса249
Определение имен для разъединенных сетей252
Определение имен в среде Active Directory, основанной
на использовании сетей VPN253
Сети HappyVPN Networks — учебный пример254
Взаимосвязь между серверами определения имен филиала офиса258
Резюме258
Глава 12. Использование Active Directory в сетях VPN259
Репликация260
Средство контроля согласованности базы знаний261
Приведение в действие процесса репликации вручную263
Срочная репликация ActiveDirectory263
Репликация с одним мастер-доменом и VPN264
Оптимизация265
Проект узла сети266
Проект узла сети для VPN266
Топология узла сети267
Компоненты топологии узлов268
Развертывание AD270
Преобразование IP-адресов270
Преобразование IP-портов брандмауэра/NAT-сервера для Active Directory271
Репликация с применением протокола SMTP273
Связывание узлов сети с VPN274
Выводы275
Модель сети HappyVPN275
Резюме277
Приложение А. История и предмет виртуальных частных сетей279
Ранние годы279
Провайдеры услуг Internet280
Частные сети281
Справочная модель OSI281
Уровень 1: физический уровень282
Уровень 2: канальный уровень282
Уровень 3: сетевой уровень283
Уровень 4: транспортный уровень284
Уровень 5: уровень сеанса284
Уровень 6: уровень представления285
Уровень 7: уровень приложения285
Документы RFC, описывающие сети VPN285
Приложение Б. Устранение проблем289
Факторы, приводящие к возникновению проблем289
Утилиты PPTPCLNT и PPTPSRV290
Производительность29I
Обшие вопросы и советы по устранению проблем292
Включение регистрации для сервера RRAS293
Разрешение проблем, связанных с протоколом IPSec293
Утилита Network Monitor294
Сканеры портов294
Резюме294
Приложение В. Связь между протоколами
IPSec Windows 2000 и Cisco295
Установка сети296
Настройка политики безопасности Windows 2000297
Конфигурирование Cisco IPSec308
Тестирование310
Резюме312
Приложение Г. Перспективы развития сетевых технологий и VPN313
Прогноз развития VPN и направления совершенствования Windows313
Предметный указатель316
Об авторе
Тадеуш Фортенбери (Thaddeus Fortenberry), имеющий степени MCSE и MCT, является главным экспертом в области виртуальных частных сетей, реализуемых на платформе Windows. В качестве программного менеджера компании Compaq (направление виртуальные частные сети) занимается разработкой глобальных спецификаций технологии туннелирования, а также развертыванием туннельных серверов. Имеет опыт работы с Windows NT, начиная с первой версии. Тадеуш работал в службе поддержки, специализируясь в области VPN, а также сетевых вычислений. Его функции заключались в оказании помощи участникам программы Windows 2000 Rapid Deployment Program (Программа быстрого развертывания Windows 2000), инициированной компанией Microsoft. Также Тадеуш Фортенбери принимал участие в администрировании и развертывании Qtest Active Directory для компании Compaq — второй по масштабности предварительной версии Windows 2000 Active Directory. Помимо этого он являлся главным архитектором тестовых сетей Happy VPN. Эти сети представляют собой продукт развертывания Active Directory в распределенной рабочей сети. При этом используются лишь подключения VPN, реализуемых с использованием технологий туннелирования Windows 2000.
О соавторе
Дэвид Нейлан (David Neilan), имеющий степень MCSE, уже более девяти лет работает в области компьютерных/сетевых технологий. Последние пять лет его деятельность связана с обеспечением безопасности локальных сетей и Internet. Около четырех лет он имел дело с компанией Intergraph, занимавшейся разработкой графических систем и сетями. Также Дэвид работал с платформами Digital Equipment (брандмауэры DEC и безопасность сетевых вычислений), принимал участие в обеспечении безопасности сетей LAN/WAN и Internet в компании Online Business Systems. Недавно он открыл собственную консалтинговую фирму. Сотрудники фирмы занимаются разработкой сетевой инфраструктуры для Windows 2000 с целью поддержки защищенных подключений LAN/WAN для различных компаний, использующих Internet при создании защищенных частных виртуальных сетей. Дэвид является бета-тестером программных продуктов компании Microsoft и операционных систем, начиная с Windows for Workgroups 3.11. Также он принимал участие в тестировании Windows 2000 на ранних стадиях разработки этой операционной системы.
Сведения о технических редакторах
Все редакторы внесли свой посильный вклад в выполнение технической экспертизы в процессе создания книги Проектирование виртуальных частных сетей в среде Windows2000, При написании книги именно эти профессионалы просматривали весь материал, изучая техническое содержание, организационную структуру и расположение. Их советы способствовали тому, чтобы создаваемая книга лучше соответствовала запросам читателей и содержала наиболее ценную техническую информацию.
Гэри Олсен (Gary Olsen) является консультантом в отделе поддержки пользователей компьютерной корпорации Compaq, имеет степень бакалавра по технической специальности и степень магистра в области компьютерной индустрии, которую он получил в университете Бригхэма Янга (Brigham Young University), В области компьютерных технологий работает с 1983 г. Гэри Олсен около двух лет сотрудничал с компанией Microsoft по программе Windows 2000 Rapid Deployment Program (RDP), поддерживая группы новостей бета-тестеров. Вместе с инженерами компании Microsoft выполнял работу по проверке замеченных погрешностей и их устранению, написанию статей, созданию обзоров для учебных курсов и тестированию бета-версий операционных систем. Также он руководил учебным курсом по Windows 2000 для технического персонала компании Compaq и проводил консультации для заказчиков компаний Compaq и Microsoft в области Active Directory. Гэри Олсен на нескольких конференциях и Web-форумах представлял проект Active Directory, а также в течение последних двух лет выполнял функции администратора Enterprise общеизвестного домена Qtest Windows 2000 компании Compaq; является автором книги Служба Active Directory: разработка и внедрение, выпушенной издательским домом "Вильяме".
Нейл Рустон (Neil Ruston) администрирует систему Perot Systems в лондонском отделении крупного швейцарского банка. В области компьютерных технологий работает около 10 лет. В самом начале своей карьеры разрабатывал и внедрял локальные сети NetWare 2/3/4. Имеет сертификат CNE 4. Затем он занимался разработкой сетей на базе Windows NT и получил степень MCSE. Участвовал в проекте Joint Development Program (JDP) компании Microsoft, создавал и внедрял Active Directory и топологию DNS как часть программы JDP. Работал с Windows 2000, начиная со 2-й бета-версии.
Жан де Клерк (Jan De Clercq) является старшим консультантом Группы технологического лидерства (Technology Leadership Group (TLG)) компании Compaq. Основные его интересы сосредоточены в области обеспечения безопасности при передаче коммерческих электронных сообщений и на особенностях реализации платформ Microsoft, Жан де Клерк принимал участие в создании многих технических документов для компании Compaq, написал ряд статей в журналах, посвященных реализации сетей VPN в Windows 2000. Также неоднократно выступал как докладчик на конференциях Microsoft, на конференции RSA и на конференции ЕМА. Жан де Клерк участвовал В нескольких проектах компании Compaq, посвященных обработке больших массивов учетных записей. Эти проекты имели отношение к вопросам обеспечения безопасности, а также связаны с Windows и технологией РК1. В течение последнего года он выполнял функции консультанта по вопросам безопасности при реализации нескольких крупных разработок программных продуктов на базе Windows 2000.
Уоррен Бэркли (Warren Barkley) более 10 лет работает в технологическом секторе экономики. Он имеет степени нескольких колледжей и обладает рядом индустриальных сертификатов. Мистер Бэркли работал консультантом по сетевым инфраструктурам во многих крупных и небольших организациях. Кроме того, он является автором нескольких технических разработок, связанных с сетевыми вычислениями и вопросами обеспечения безопасности. Вместе с женой и двумя сыновьями Уоррен Бэркли проживает в районе Сиэтла.
Патрик "Швейцарец" Рамсей (Patrick ""Swissman” Ramscier), имеющий степени CCNA, GSEC, CISSP, является старшим штатным консультантом в фирме Exodus Communications, Inc. Фирма Exodus выполняет функции ведущего провайдера при проведениикомплексногоInternet-хостингадляпредприятий,важныеоперации которых выполняются в Internet. Карьера Патрика Рамсея начиналась с роли системного администратора UNIX. Последние 12 лет участвовал в проведении обзоров архитектуры безопасности на корпоративном уровне, устранении "узких мест", реализовал поддержку подключений VPN, сетей и систем безопасности операционных систем (UNIX-Solaris, Linux, BSD и Windows NT). Он также производил обучение, вел исследовательскую работу и внедрял практические разработки. Патрик имеет степень бакалавра в области бизнеса и работает над докторской/магистерской диссертацией в области компьютерных технологий.
Посвящение
Этот труд посвящается моей бабушке и матери, которые всегда поддерживали мои проекты.
Благодарности
Я благодарен Гэри Олсену за то, что работал вместе со мной около 26 месяцев. От Гэри я узнал много полезной и ценной информации, он является самым интеллигентным и добросердечным собеседником из тех, с кем мне приходилось общаться в жизни. Гэри внес существенный вклад в дело написания главы 12, а также применил на практике свои познания ведущего эксперта в области Active Directory.
Я благодарен всем сотрудникам издательства New Riders за их терпение и чуткость. Мои особые благодарности адресованы Терезе Джин (Theresa Gheen), Элисон Джонсон (Allison Johnson) и Гранту Манрою (Grant Munroe). У меня непрерывно возникали проблемы при совмещении основных обязанностей и обязательств по работе над книгой. Эти сотрудники неизменно вежливо напоминали мне о рабочем графике, которому необходимо следовать.
Я хотел бы принести благодарности Джефу Баббу (Jeff Babb), Брюсу Варфорду (Bruce Warford), Майклу Трабалку (Michael Trabalka), Элджин Браун (Eljin Brown) и Джереми Джонс (Jeramy Jones) за то, что они позволяли мне пользоваться офисными услугами на своих рабочих местах.
Я благодарен Мэтту Вилльямсону (Matt Williamson) и Стефену Край ку (Shephen Craike) за проведенные вместе со мной месяцы в Сиэтле. Также, Мэтт, благодарю тебя за то, что позволил отвлекать тебя всевозможными вопросами.
Благодарю моих коллег по последнему месту работы в Ассоциации университетов Оук Ридж (Oak Ridge Associated Universities), поскольку без приобретенного там опыта я не смог бы работать над теми вопросами, которые заботят меня сейчас.
Также благодарю Донни Маклин (Donnie Macklin) за постоянную поддержку и за те напоминания, которые ей приходилось делать во время работы над проектом.
Наконец, благодарю мою любимую подругу Аманду Уайтинг (Amanda Whiting), которая упорно поддерживала этот проект, хотя меня иногда и посещала неуверенность в своих силах.
От издательства
Вы, читатель этой книги, и есть главный ее критик и комментатор. Мы ценим ваше мнение и хотим знать, что было сделано нами правильно, что можно было сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно услышать и любые другие замечания, которые вам хотелось бы высказать в наш адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать электронное письмо или просто посетить наш Web-сервер, оставив свои замечания, — одним словом, любым удобным для вас способом дайте нам знать, нравится или нет вам эта книга, а также выскажите свое мнение о том, как сделать наши книги более подходящими для вас.
Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, а также ваш e-mail. Мы внимательно ознакомимся с вашим мнением и обязательно учтем его при отборе и подготовке к изданию последующих книг. Наши координаты:
E-mail; infoSwilliamspublishing,com
WWW: http://www.willia1n5publi5hing.com
16
Предисловие
На начальных этапах разработки Windows 2000 компания Microsoft активно вовлекала в работу основных заказчиков, что позволило создать программный продукт, отвечающий всем современным требованиям. Этот подход реализовался с помощью программы Rapid Deployment Program (RDP), а позднее —■ программы Joint Deployment Program (JDP). Каждая из этих программ включала два отдельных этапа, На первом этапе, когда возникала масса затруднений, около 250 заказчиков выразили согласие на тесное сотрудничество с компанией Microsoft. Они развернули сотни рабочих станций и серверов и выполняли работу по совершенствованию среды разработки. На следующем этапе необходимо было работать с представителями различных партнеров компании Microsoft, которые действительно "болели" за Microsoft и работали на ее благо, поддерживая ранние версии операционной системы. В течение 22 месяцев уже только 20 служащих, не являющихся сотрудниками компании Microsoft, выполняли эту работу; автор и являлся одним из этих 20-ти, будучи представителем этого проекта компании Compaq.
Самым волнуюшим моментом данного проекта являлось следующее обстоятельство. Несмотря на то, что мы представляли конкурирующие компании, однако, тесно и плодотворно сотрудничали с представителями компании Microsoft. Все мы служили одной цели: изучать запросы и поддержать заказчиков в рамках программы RDP/JDP. Независимо от того, интересы каких компаний представлялись, все члены команды могли положиться друг на друга и оказывали взаимную помощь с целью достижения общей цели, С учетом основных технологий Windows 2000 формировались соответсгвуюшие подгруппы. И хотя автор являлся членом группы по сетевым вычислениям, которая специализировалась на виртуальных частных сетях, он регулярно сотрудничал с представителями других групп при работе над специальными проектами и разработками. В обязанности всех занятых сотрудников входило посещение еженедельных собраний. На этих собраниях представители различных групп разработчиков обсуждали достоинства и недостатки операционной системы Windows 2000. Каждый из нас мог высказать свои замечания относительно тех вопросов, с которыми сталкивались заказчики RDP/JDP. Также все участники могли наблюдать процесс разработки приложения в компании Microsoft.
И самым важным для меня результатом этой деятельности является осознание тех невероятных усилий, которые предпринимаются при координировании разработки программного продукта во всей его сложности и масштабности. В качестве сетевого администратора мне уже приходилось внедрять программные продукты компании Microsoft. При обнаружении неточностей в процессе внедрения программы я испытывал некоторую тревогу. До тех пор, пока я не оказался участником процесса разработки, не представлялось возможным в полной мере оценить масштабность задачи по разработке операционной системы. Достаточно просто специализироваться в определенной технологической области. До чего же сложно разработать программный код для выполнения определенной задачи и гарантировать при этом, что этот код не повлияет негативным образом на другую часть операционной системы при различных способах развертывания технологии. В то же время весь процесс координирования не может спеиимизироваться с учетом данной технологии, а должен представлять собой завершенный программный продукт. Следует учесть, что процесс тестирования должен выполняться таким образом, чтобы его нельзя было обобщить. В результате приходим к масштабному тестированию, которое требует огромных усилий. И участие заказчиков в этом процессе тестирования было поистине находкой.
Иногда затруднительно гарантировать успешное функционирование данного продукта совместно с другими программными продуктами, разработанными одной и той же фирмой. Компания Microsoft выступает спонсором многих технических разработок, привлекая конкурентов к выполнению тестирования межоперационного взаимодействия. Поскольку технологии появляются и развиваются достаточно быстро, до-
вольно трудно гарантировать превосходное функционирование всех продуктов в средах различных типов. Автор верит, что именно RDP/JDP поможет в этом, поскольку Windows 2000 развертывается в чрезвычайно различных средах, и многие затруднения, которые обнаружились на ранних стадиях разработки, уже устранены.
Тадеуш выражает уверенность в том, что стратегия предварительной разработки увенчалась крупным успехом. Операционная система Windows 2000 является, по многим показателям, совершенно новым продуктом, и для его изучения и тестирования потребуются постоянные усилия. При внедрении Windows 2000 важно полностью представлять диапазон возможностей этого проекта, например, разработку Active Directory с помощью подключений VPN. Программа RDP/JDP помогает вскрыть эти возможности. Она также служит моделью, которая помогает при реализации сетей VPN учесть все особенности функционирования системы еще до ее внедрения. И автор верит, что с ПОМОЩЬЮ подобного подхода можно спроектировать рабочую сеть для тестирования, а также четко очертить испытательную среду, которая позволит создавать и точную документацию, и выполнить тестирование.
Именно благодаря тем возможностям, которые представились автору в программе RDP/JDP, в задачи которой входила разработка версий VPN для множества реальных заказчиков, накопились бесценные для процесса внедрения советы и стратегии, обсуждаемые в этой книге.
Позвольте мне начать со следующего довольно неожиданного заявления. Я вовсе не собирался создавать руководство по виртуальным частным сетям (VPN), которое включало бы лишь понятия и теории. Вместо этого целью создания книги является описание методов конфигурирования Windows 2000, обеспечивающих применение сетей VPN, a также обоснование необходимости использования этих технологий. Для этого в книгу включены размышления о преимуществах и недостатках большого числа конфигураций, а также пошаговые процедуры их настройки. После просмотра содержания книги читатель сможет создавать и внедрять данную технологию в среде собственной сети.
В книге обсуждаются возможности технологий VPN в Windows 2000, однако, комментарии по документам RFC не входят в спектр вопросов, рассматриваемых в книге. Вообще говоря, книга рассчитана на разработчиков и администраторов сетей, которые желают знать, каким образом следует производить настройку сети. Если вас интересуют подробности каждого пакета и детализированный анализ принципов работы, следует обратиться к приложениям данной книги. Там содержится материал, в котором обсуждаются не только технологии VPN в Windows 2000, но также и стандарты IETF. Опираясь на собственный опыт, я, тем не менее, прихожу к выводам, что сетевые администраторы, как правило, не интересуются деталями технологических разработок. Их больше заботят способы внедрения этих технологий, меры по обеспечению безопасности и поддержка функционирования сетей. Исходя из собственного опыта, я предлагаю непосредственный, удобный в применении подход, который позволяет внедрять виртуальные частные сети на рабочем месте каждого пользователя.
Вопросы, обсуждаемые в книге
Операционная система Windows 2000 включает большое число новых технологий, предназначенных для сетевых администраторов. ОС Windows NT 4.0 поддерживает подключения VPN, которые действительно представляют “вешь в себе". При работе с Windows 2000 среда VPN должна координироваться с большим количеством других служб, что гарантирует ее гибкое и завершенное развертывание. Эта книга представляет собой не только введение в эти службы, но также включает и обсуждение вопросов, относящихся к их развертыванию.
В отличие от большинства книг, посвященных VPN, диапазон обсуждаемых здесь вопросов не ограничивается клиентским доступом к корпоративной сети. Также обсуждается и большое число других моментов, например, развертывание Active Directory с помощью подключений, основанных на туннелях. (Большое количество тестов, выполненных в течение двух последних лет, показало, что возможно конфигурирование полностью функциональной и надежной в работе среды каталогов, которая полностью базируется на использовании сетей VPN.)
Не имеет значения, какой тип имеет внедряемая среда VPN, необходимо лишь помнить о том, что сеть VPN нуждается в гибком подходе, поскольку постоянно изменяются корпоративные задачи и технологии. Теоретически возможна любая разработка. Однако, при разработке сетевой конфигурации необходимо выполнить детальный разбор всего проекта. Тогда можно гарантировать, что проект будет отвечать запросам клиентов. В этой книге объясняется достаточно большое количество технологий и стратегий, которые позволят вам преуспеть в достижении поставленной цели.
Структура книги
Главы в этой книге располагаются с учетом принципа “от простого к сложному". Сначала излагается самая общая информация, затем она усложняется, а затем рассматриваются специальные подходы, которые используются при развертывании VPN
на платформе Windows 2000. Необязательно последовательно читать предложенные главы. Однако, следует учесть, что в каждой главе рассматривается специальный набор вопросов, связанных с виртуальными частными сетями, и может служить отдельным руководством. Главы в книге расположены в следующей последовательности.
Главы 1 и 2 содержат основные понятия, связанные стуннелированием. Данный материал имеет большое значение для администраторов, незнакомых с туннелированием, и позволяет ознакомиться с кругом задач, выполняемых с применением этой технологии.
Главы с 3 по 7 содержат сведения по отдельным технологиямтуннелирования, которые включены в состав Windows 2000. В этих главах не только содержится информация о реальных протоколах типа РРТР, IPSec и L2TP, но также помешены сведения о службах, обеспечиваю шик развертывание технологий туннелирования.
В главах с 8 по 12 подробно рассматриваются вопросы, которые имеют значение при реализации технологий туннелирования в отделениях офисов и домашних средах LAN; содержится информация как о среде маршрутизации (включая RRAS и 1AS), так и сведения о NAT, DNS и Active Directory. В результате рассмотрения этих сведений нетрудно прийти к выводу, что в проект оборудования для филиалов офисов целесообразно включить распределенные доменные контроллеры.
В приложениях рассматриваются дополнительные вопросы, которые варьируются от контекстной информации относительно VPN (сведения о модели OS1 и связанных с VPN документами RFC) до сведений относительно конфигурирования м аршрутизатора Cisco в качестве туннельного клиента для туннельного сервера Windows 2000. Здесь также можно найти информацию относительно основных ошибок и сбоев, Происходящих при развертывании туннелей, а также изложение перспективных возможностей VPN.
На протяжении всей книги рассказывается, каким образом и почему необходимо внедрять технологию VPN в сетевой среде Windows 2000. Если мне удастся передать свой бесценный опыт читателю, последний приобретет весьма полезные знания об особенностях применения этой технологии.
Соглашения, используемые в книге
В этой книге используются следующие соглашения.
Нумерованные процедуры (например, процедура 4.1) включаютпошаговую инструкцию, применяемую при осуществлении определенных конфигураций или процессов.
Врезки, советы и примечания включают ценные сведения, дополняющие обычный текст.
Моноширинный шрифт указывает код или какие-товведения, которые обособлены от остального текста. Этот же шрифт применяется для выделения адресов URL.
Полужирный шрифт указывает на текст, который вводится читателем вручную.
1
Виртуальные частные сети. Введение
В последние годы персонал многих компаний испытывает необходимость в установке сетевых подключений к центральным офисам. Возрастает спрос на недорогие защи- шенные подключения, устанавливаемые между удаленными пользователями и офисами. Несмотря на то, что выделенные каналы и арендованные линии зарекомендовали себя в качестве надежного и безопасного средства связи, затраты на их реализацию не приемлемы для большинства компаний. Виртуальные частные сети (VPN — Virtual Private Network) имитируют возможности частной сети. Они функционируют на базе существующей общедоступной сетевой инфраструктуры, в роли которой обычно используется Internet. Именование "виртуальная" применяется по той причине, что на основе физических подключений формируется логическая связь. Клиентские приложения не зависят от типа реального физического подключения и маршрутизируют трафик безопасным образом с использованием возможностей Internet, В результате обеспечивается безопасная передача данных в частной сети. После создания и конфигурирования сети VPN приложения не различают виртуальные и физические адаптеры.
При корректной установке виртуальной частной сети в глобальной сети (WAN — wide area network) объединяются возможности общедоступных сетей (например, Internet), Frame Relay и Asynchronous Transfer Mode (ATM). Причем удаленное подключение трактуется как частная сеть. Если инфраструктура VPN определена и сконфигурирована, поддерживается "гладкая" интеграция, а сеть рассматривается в качестве частной сети.
Историческая справка:
виртуальные частные сети
Итак, почему же сети VPN заняли современное положение в мире информационных технологий? Буквально еще несколько лет назад понятия сетей VPN еще не существовало, За относительно небольшой период времени, в течение которого возрос уровень требований со стороны корпораций к установке подключений между пользователями, сети VPN прошли всестороннюю проверку и были существенно усовершенствованы.
Несколько производителей (IBM, Microsoft и Cisco Systems, Inc.) в середине 90-х годов приступили к разработке технологий туннелирования. И хотя некоторые программные продукты, типа IPX и SNA на основе туннелирования, стали доступны еще несколько лет назад, они были жестко привязаны к используемым средам, вследствие чего их применение было ограниченным. Для промышленного применения необхо-
дима была технология туннелирования, с помошью которой было стандартизировано применение всех типов трафика. Крупный шаг в направлении станда рти зации был сделан благодаря внедрению набора протоколов TCP/IP.
В 1996 году несколько производителей программного обеспечения обратили внимание на возможности сетей VPN. При этом многие из этих компаний объединили свои усилия, начав разработку протокола туннелирования. В ходе выполнения этих разработок были реализованы два основных решения VPN: протокол туннелирования "точка- точка" (РРТР — Point-to-Point Tunneling Protocol), созданный компаниями Microsoft, Ascend, 3Com и US Robotics, а также протокол перенаправления уровня 2 (L2F — Layer 2 Forwarding), созданный фирмой Cisco. Поскольку оба эти решения имеют специфическую привязку к производителям, их возможности по взаимодействию с программными продуктами ограничиваются приложениями от определенных поставщиков.
Протоколы РРТР и L2F являются протоколами туннелирования, относящимися ко 2му уровню модели взаимодействия отрытых систем (OSI — Open Systems Interconnection). При проектировании этих протоколов учитывалось их взаимодействие с транспортными протоколами Internet, относящимися к уровню 3, такими как Apple Talk, IP и IPX. Для выполнения данной задачи в протоколах РРТР и L2F была реализована усовершенствованная версия стандарта РРР уровня 2, в которой с помощью последовательных связей были реализованы различные транспортные протоколы уровня 3. Пакеты уровня 3 инкапсулировались во фреймах РРР, а затем упаковывались в IP-пакеты с целью транспортировки в сети, основанной на использовании IP, Поскольку ни один из протоколов не поддерживает функции по шифрованию, аутентификации и обеспечению целостности данных, имеющие критическое значение для сетей VPN, все эти компоненты должны добавляться в виде отдельных процессов. Обсуждению протокола РРТР посвящена глава 4.
Поскольку существующие протоколы туннелирования имели существенные недостатки, в 1997 голу начался процесс стандартизации и планирования. Начало этому процессу положило появление транспортного протокола уровня 2 (L2TP) и протокола обеспечения безопасности в Internet (IPSec), разработанных комитетом Internet Engineering Task Force (IETF). Поскольку протоколы L2TP и IPSec явились результатом скоординированных действий нескольких производителей, при их создании повышенное внимание уделялось взаимодействию этих протоколов с программными продуктами.
Обладая возможностями протокола уровня 2, L2TP обеспечивает многопротокольную поддержку в IP-сети. Следовательно, в этом случае речь идет не о единственном протоколе, а о нескольких различных транспортных протоколах. Спецификация L2TP не определяет встроенных функций по обеспечению безопасности данных. Поэтому в целях обеспечения безопасного режима передачи данных используется протокол IPSec, Протокол L2TP рассматривается в главе 7.
После того, как технология туннелирования была усовершенствована до того уровня, когда она стала доступной для администраторов, туннельные клиенты стали весьма распространенными. Помимо этого ОС Windows NT обеспечила для администраторов поддержку основных сетевых функций, предлагая такие возможности, как аудит, ведение учетных записей и систему оповещений. Благодаря этому были облегчены внедрение и мониторинг нового программного продукта.
В 1998 году сети VPN были снова усовершенствованы. Появилась возможность централизованного контроля со стороны пользователя, улучшились методы управления сетью, усовершенствованы методы аутентификации и шифрования. Компания Microsoft продолжала работы в области усовершенствования протокола туннелирования Windows NT 4.0, совершенствуя систему аутентификации и безопасности. Было модернизировано множество клиентов, в результате чего они были оснащены программным обеспечением туннельных клиентов, имеющих более совершенную конфигурацию.
В 1999 году эффективность сетей VPN значительно возросла за счет появления новых возможностей, таких как модель аутентификации, основанная на стандартах, облег-
ченный интерфейс конфигурирования сервера, а также дополнительные инструментальные средства, применяемые для конфигурирования клиентов. Новая модель аутентификации допускала использование смарт-карт, применяемых в ходе реализации доступа со стороны клиентов. Подобный подход повышает степень безопасности, а также улучшает интеграцию сетей VPN с устройствами заказчика. В результате сети VPN стали широко использоваться удаленными пользователями. Также существенно возрос удельный вес сетей VPN, применяемых для связи между удаленными офисами корпорации.
Сети VPN получили свое дальнейшее развитие в операционной системе Windows 2000. Было разработано безопасное управляемое решение туннелирования, стоимость которого была меньшей по сравнению со стоимостью аппаратных средств и/или решений, основанных на использовании выделенных линий. Компания Microsoft всегда была сторонницей активного внедрения технологий VPN в составе Windows 2000, поскольку заранее предвидела, что уже в ближайшем будущем сети VPN станут важным элементом корпоративных сетей. ОС Windows 2000 обеспечивает не только встроенную поддержку протоколов IPSec, L2TP и РРТР, но также предлагает полный набор служб обеспечения безопасности. Эти возможности ранжируются от полной службы аутентификации удаленных пользователей (RADIUS — Remote Authentication Dial-In User Service) до расширяемого протокола аутентификации (ЕАР — Extensible Authentication Protocol). Службы VPN Windows 2000 подробно обсуждаются в главе 3.
Принципы функционирования виртуальных частных сетей
Как отмечалось ранее, виртуальная частная сеть представляет собой "частный туннель", проложенный с использованием общедоступной инфраструктуры. Для эмулирования частной сетевой связи в сети VPN происходит инкапсуляция данных вместе с заголовком, который включает сведения относительно маршрутизации. Подобный подход позволяет передавать данные по общедоступной сети (обычно. Internet) от источника до места назначения. Для эмуляции канала частной связи сеть VPN шифрует инкапсулируемые данные, которые пересылаются с учетом всех требований по обеспечению конфиденциальности, аутентификации и гарантированной целостности. Если пакеты перехватываются в процессе передачи по общедоступной сети, их данные не могут быть считаны без применения ключей шифрования. Подключение, при установке которого осуществляется инкапсуляция и шифрование данных, именуется подключение VPN (или туннельное подключение).
Сеть VPN поддерживается разнообразными устройствами. В настоящее время существует возможность связать сервер Windows 2000 с маршрутизатором, воспользовавшись зашифрованным туннелем. Можно также подключать сервер Windows 2000 к любому другому устройству Windows 2000, к брандмауэру и т.д. При этом основным условием является поддержка со стороны этих устройств стандартных протоколов и механизмов шифрования.
А теперь будет рассмотрена схема сети, основанной на использовании туннеля, которой и посвящена эта книга. При использовании любой сети VPN преследуется цель обеспечения безопасности передаваемых по сети данных. При этом данные должны быть защищены независимо от сетевой среды, по которой они перемещаются.
Простое подключение VPN, реализуемое в Internet, показано на рис. 1.1.
Приступая к планированию сети VPN, необходимо определить цели реализуемого проекта. Технология туннелирования может применяться с помощью большого количества методов, и ее использование позволяет получить преимущества при реализации большинства сетевых решений. В ходе планирования следует выбрать решение, обеспечивающее эффективное и стабильное функционирование.
Во многих компаниях имеются сотрудники, которые проводят много времени в путешествиях, используя при этом удаленные узлы (например, в домашних условиях), Эти сотрудники должны иметь доступ к корпоративной сети. Причем наличие этой возможности не должно зависеть от места пребывания сотрудника, а при передаче данных должны гарантироваться определенные меры безопасности. В прошлом подобные соединения устанавливались исключительно с помощью технологии удаленного доступа по коммутируемым телефонным линиям, что было весьма дорогостоящим. В настоящее время многие домашние пользователи используют кабельные модемы и модемы DSL, что позволяет значительно ускорить осуществляемые коммуникации. Однако эти типы подключений являются дорогостоящими. Поэтому довольно затруднительно, а иногда и просто невозможно использовать подобный подход при установке прямого подключения в ходе создания корпоративных сетей. С другой стороны, туннельное подключение VPN обеспечивает для пользователей высокоскоростное подключение к сети, реализуемое за более низкую цену.
Рис. 1.1, Туннельный клиент, получающий доступ к корпоративной сети с помощью туннеля
Туннельное подключение предоставляет пользователю возможность устанавливать подключение к Internet с применением широкого спектра технологий независимо от того, находится он в дороге или дома. После установки подключения в Internet "открывается" туннель в корпоративную сеть. В этом случае Internet используется в роли своего рода транспортного механизма, который позволяет отказаться от использования междугородных телефонных линий связи. Помимо этого туннельное подключение не зависит от способа доступа к Internet, поэтому путешествующие пользователи смогут свободно перемещаться из отеля в отель, не испытывая при этом каких- либо неудобств при подключении к корпоративной сети. Подобная высокая степень мобильности обеспечивает существенную экономию денежных средств. Многие компании располагают доступом к номерам типа 1-800, с помошью которых обеспечивается удаленный доступ из любого местоположения, хотя счета за пользование телефоном в этом случае могут вырасти до астрономических размеров. Мне приходилось работать в нескольких компаниях, которым ежемесячно приходили телефонные счета на сумму до миллиона долларов. Причина появления столь огромных сумм заключалась в том, что путешествующие сотрудники позволяли себе "роскошь телефонного общения". Именно сокращение подобных затрат является первым, чрезвычайно ощутимым, результатом развертывания среды туннелирования.
Учитывая полную стоимость реализации стратегии сетевого доступа, следует обращать внимание на все элементы решения. Решение, основанное на использовании модема, вызывает множество проблем. Модемные стойки дороги, их следует часто обновлять, также в данном случае отсутствует поддержка некоторых новых технологий подключения. Для организации поддержки широкого спектра сред соединения требуются большие накладные расходы на администрирование. Использование туннельного
решения позволяет корпорации избежать больших затрат при использовании модема и подключениях к провайдерам услуг Internet. Если появляются проблемы при реализации доступа клиента к Internet, он обращается к службе технической поддержки провайдера услуг Internet, а не ишет подсказку внутри самой корпорации. Кроме этого провайдер услуг Internet может предложить клиентам высокоскоростные решения, которые для большинства компаний являются непрактичными.
Туннель
Использование термина “туннель ” обусловлено тем, что при реализации туннельного подключения устанавливается связь между двумя системами, которая будет независимой от фактического маршрута. Если между двумя компьютерами, один из которых находится в Бостоне, а второй — в Сиэтле, установлена связь, при ее реализации в Internet может использоваться до 12 транзитных участков. Однако при установке туннеля между двумя компьютерами в Internet можно реализовать их непосредственное взаимодействие друг с другом. Это возможно, поскольку туннель устанавливается вдоль прямого логического маршрута, а не в соответствии с физическим непрямым маршрутом. Благодаря использованию логического маршрута, функционирование приложения не зависит от фактического количества транзитных участков, используемых при установке связи между клиентом и сервером туннеля. В данном случае туннель рассматривается в качестве отдельного транзитного участка.
Если обратиться к истории, то можно заметить, что еше в телефонных сетях общего назначения использовались описанные выше возможности по установке подключения "точка-точка". Однако эти сети применялись только для осуществления речевых коммуникаций и были полностью непригодными для осуществления передачи данных и сетевых коммуникаций, осуществляемых в современных условиях. Благодаря успешному развитию Internet, вместо использования арендованных линий и выделенных корпоративных модемов все шире применяются сети VPN. На современном этапе эволюции можно отметить параллельное сосуществование частных сетей и сетей общего назначения, относящихся к следующему поколению. Однако, исходя из сути решений VPN, можно сделать вывод, что рассматриваемые отдельные инфраструктуры не столь отличны друг от друга. Все идет к тому, что вскоре возникнет проблема использования обширных возможностей Internet с целью установки подключений при одновременном сокращении расходов на осуществление этой операции. Развитию решений VPN в Internet способствовали следующие причины:
высокая стоимость внедрения и поддержки частных сетей;
постояннорастущее число удаленных и мобильных пользователей;
увеличивающееся количествоприложений, имеющих отношение к сетям, таких как приложения электронной почты, а также другие коммуникационные приложения;
постоянная потребность в поддержке взаимодействия с заказчиками в интерактивном режиме;
процесс объединения сетевых технологий, таких как телефония и/или мультимедийные приложения (видеоконференции).
Желательно, чтобы при любой направленности развития сетевых технологий постоянно возрастала и необходимость в совершенствовании высокоскоростных сетей VPN. Вследствие этого при создании сетей должны учитываться возможности, которые будут удовлетворять потребностям ближайшего будущего.
Альтернативные службы
Альтернативными называются службы, поддерживающие возможности, аналогичные VPN, без использования среды туннелирования. Каждая из подобных служб имеет свои преимущества и недостатки, которые и будут рассмотрены в данном разделе. Сотрудникам корпораций, взвешивающим все доводы при обращении к среде туннелирования, следует проанализировать эти возможности и определить наилучшее решение, применяемое в конкретной ситуации.
Прозрачные сетевые службы (TLS)
Прозрачные сетевые службы (TLS — Transparent LAN Services) являются высокоскоростными службами, обеспечивающими поддержку межсетевого взаимодействия. При использовании этих служб в некоторой степени сглаживаются сложности, связанные с технологиями глобальных сетей. Используя TLS, провайдер услуг подключает локальную корпоративную сеть таким образом, что она взаимодействует в сети со стандартным сетевым сегментом.
Служба TLS обеспечивает следующие преимущества:
провайдер услуг конфигурирует и поддерживает сетевые каналы связи;
провайдер услуг отвечает за поддержку этой связи;
есликорпорацияиспользует FrameRelay,то в этомслучаеотперсонала,под
держивающего службу TLS, потребуется минимальный уровень дополнительных сведений (поскольку служба TLS тесно связана с Frame Relay).
Недостатки TLS:
служба не может использоваться повсеместно. Обычно она доступна только в больших городах, но эта ситуация постепенно изменяется в лучшую сторону;
стоимость использования этой службы довольно высока. Предлагая эту службу заказчикам, провайдеры услуг имеют определенный доход, что увеличивает сумму, вносимую заказчиком;
гибкость функционирования данной службы зависит от квалификации провайдера услуг. Если провайдер услуг предлагает только определенные технологии, возможности пользователя существенно ограничиваются. Правда, в этом случае он может поменять провайдера.
Защищенная удаленная аутентификация (SRA) вызовов RPC
Аутентификация (SRA 1^™^^— Secure Remote Authentication) защищенных вызовов RPC объединяет механизм RPC с аутентификацией пользователя, а также, обычно, со стандартом шифрования данных (DES — Data Encryption Standard). Задачей, выдвигаемой при использовании защищенного вызова RPC, является создание системы безопасности, которая может применяться всеми пользователями. С помощью SRA пользователи могут регистрироваться на любом удаленном компьютере (точно так же, как и на локальной системе), а пользовательские регистрационные пароли являются своего рода паспортами, обеспечивающими безопасность в сети.
При использовании SRA достигаются следующие преимущества:
SRA позволяет довольно гибко получать безопасный доступ к удаленным системам;
SRA великолепно поддерживается некоторыми платформами UNIX.
Недостатки SRA:
каждая программа аутентификации пользователей, основанная на RPC, может использовать защищенные вызовы RPC, однако, некоторые программы следует модифицировать с целью поддержки RPC;
эта технология не столь широко распространена, ее взаимодействие с другими программными продуктами ограничено. Обычно она используется только на платформе UNIX;
SRA не является сетевым решением "сеть-сеть"; это решение основано на конкретном приложении.
Уровень защищенных сокетов (SSL)
Многие Web-узлы применяют технологию уровня защищенных сокетов (SSL — Secure Sockets Layer). В этом случае обеспечение безопасности основано на использовании Web. Поэтому приложение можно разворачивать таким образом, что обеспечивается возможность шифрования данных, передаваемых в общедоступной сети. Эта технология может являться альтернативной по отношению к технологии сетей VPN и использоваться совместно с определенными приложениями, применяюшимися на удаленных узлах.
При реализации технологии SSL данные зашифровываются таким образом, что расшифровать их может только тот пользователь, кому они предназначены. При реализации SSL используется шифрование и декодирование данных, что гарантирует сохранность передаваемой информации.
Применение SSL обеспечивает следующие преимущества:
гарантируется безопасная передача данных. Приложение передает данные через общую сеть, обеспечивая их защиту на пути от сервера к клиенту;
основывается на Web-стандартах Internet, поэтому технология SSL может использоваться большинством современных Web-броузеров;
допускается "разгон" аппаратного обеспечения.
Недостатки SSL:
для использования SSL приложения должны обновляться или же переписываться;
технология SSL не является сетевым решением типа "сеть-сеть"; это решение основывается на конкретном приложении.
Общие методы применения виртуальных частных сетей
Для внедрения виртуальных частных сетей доступны несколько методов. С использованием технологии, приводящей к созданию туннелированной рабочей сети, можно выполнять любую конструкторскую разработку. Однако, для определенных видов деятельности использование этой технологии более плодотворно. В книге рассматриваются три способа применения сетей VPN:
удаленная регистрация пользователей;
поддержка сетевой связи с филиалами офисов;
внутренние сети.
Удаленная регистрация пользователей
В настоящее время решение VPN чаще всего используется для поддержки удаленных пользователей. Это решение легко реализуется на практике, причем результаты внедрения просто потрясают, позволяя существенно и экономить на затратах. Приложения, использующие сети VPN, позволят удаленным пользователям, находящимся дома либо в дороге, подключаться к туннельному серверу, а не к корпоративному модемному пулу. Обычно это достигается путем установления соединения между пользователем и сетью общего назначения, например Internet, которая затем применяется протоколом "точка-точка" (РРР), используемым при подключении клиента к корпоративному туннельному серверу.
При этом инфраструктура сети общего назначения не играет особой роли, поскольку подключение VPN устанавливается один раз. Клиентская среда маршрутизации настраивается в соответствии с логической связью. С точки зрения клиента VPN является соединением "точка-точка", которое устанавливается между клиентом и туннельным сервером. В сетях VPN подключившийся пользователь может иметь то же тип доступа к ресурсам, которым он обычно располагает при доступе к корпоративной сети.
Сетевые каналы связи с филиалами офисов
Ранее, когда корпорация располагала несколькими удаленными узлами, для поддержки удаленного сетевого трафика необходимо было пользоваться арендованными выделенными каналами, принадлежащими местной телекоммуникационной компании. Каждый узел должен был располагать необходимым аппаратным обеспечением, размещенным по обе стороны арендованной линии. Корпорации на каждом узле должны были располагать надежными подключениями, имеющими прогнозируемое поведение.
Недостатком подобной конфигурации являлись большие накладные расходы. Например, при аренде корпорацией линии TI, проложенной между Бостоном и Калифорнией. которая устойчиво функционирует независимо от времени суток, ежемесячные затраты на поддержку составляют несколько тысяч долларов. Причем, в эти затраты не входит стоимость инсталляции сети, Кроме того, довольно трудно точно оценить требуемую скорость передачи данных. Поэтому, либо сетевой администратор должен весьма точно оценить потребности корпорации, либо самой корпорации предстоит оплачивать услуги частично используемой связи.
Основным моментом, связанным с реализацией глобальных сетей на основе технологии VPN, является быстродействие подключения к Internet, устанавливаемого для каждого конечного пользователя туннеля. По идее, Internet имеет достаточный запас устойчивости, который позволяет при наличии сбоев в функционировании достаточно последовательных связей выполнить копирование с помощью технологий маршрутизации. Поэтому, чрезвычайно важно с обеих сторон туннеля иметь быструю и надежную связь с Internet. Самое медленное подключение к Internet определяет общий уровень быстродействия для туннеля. Если на одной стороне туннеля реализовано подключение со скоростью 56 Кбит/с, обе стороны замедляются до этого уровня независимо от скорости подключения на противоположном конце туннеля. Некоторые провайдеры услуг Internet предлагают гарантированные подключения к Internet, что позволяет обеспечить высоконадежное подключение для корпораций. Однако, подобная услуга влечет и существенное повышение стоимости подключения.
Применение сетей VPN позволяет корпорации заменить довольно дорогие арендованные линии связи туннельными соединениями, которые связывают отдельные узлы и филиалы офисов (рис. 1.2). После конфигурирования среды маршрутизации исчезает всякое серьезное отличие между логическими связями и арендованными линиями,
Поскольку протоколы туннелирования могут использовать существующую сеть общего назначения, сокращаются затраты, связанные с применением арендованных линий. При этом уменьшаются административные расходы по обслуживанию этих линий. Кроме того, типичная выделенная линия зарезервирована постоянно, однако в часы, не относящиеся к часам "пик", наблюдается избыточная пропускная способность сети (это явление характерно в том случае, если компания платит за сетевой трафик, но не выбирает его в полном объеме). При использовании сетей VPN, в случае отсутствия потребности в канале связи, он просто будет отключен. При возникновении повторной необходимости в установке связи VPN автоматически переустанавливает подключение и направляет через него трафик.
Филиал офиса
ю.ох.о
Рис. 1.2. Обеспечение связи с типичным филиалом офиса
Источником "головной боли", имеющим отношение к любой корпорации, предоставляющей услуги выделенных линий для сетевой инфрастуктуры VPN, являются проблемы безопасности и надежности. Стратегия предоставления выделенных линий применялась уже много лет; они носят частный характер и используют проверенную технологию, соответствующую индустриальным стандартам. С другой стороны, сети VPN могут использовать общедоступные незащищенные сетевые подключения.
К счастью, по мере эволюции технологий VPN, разрешение вопросов безопасности можно доверять все возрастающей аудитории пользователей Internet. При этом постоянно повышается степень надежности самой Internet. Например, если какой- либо маршрут или связь, влияющие на производительность Internet, выходят из строя, за разрешение этой проблемы принимается множество людей. До того момента, пока неполадки не будут устранены, задействуются резервные линии связи.
Реальное преимущество использования сетей VPN заключается в гибкости и масштабируемости среды. В книге будет обсуждаться установка сетей филиалов, полностью независимых от провайдеров услуг Internet. Если быстродействие канала связи является недостаточным для имеющегося количества подключенных пользователей, Операционная система Windows 2000 позволяет увеличить количество каналов связи в Internet. В результате логический канал связи продолжает функционировать в прежнем режиме, может даже немного быстрее. При этом сушественно уменьшаются затраты. Вопросы развертывания среды Active Directory в сетях VPN рассматриваются в главе 12.
Внутренние сети
Как отмечалось ранее, конечная цель создания защищенной сети заключается в шифровании сетевого трафика повсеместно на пути между исходным и конечным пунктами. В большинстве реализаций VPN зашифрованными являются клиентские
коммуникации с туннельным сервером, однако, сетевой трафик в корпоративной сети не кодируется. В большинстве сред это решение является подходящим, но очень важные данные требуют полного шифрования на маршруте передачи.
Операционная система Windows 2000 может шифровать данные для всех типов подключений (в глобальных и локальных сетях). Все больше и больше корпораций приходят к выводам, что наличие открытых сетевых коммуникаций приводит к серьезному риску для системы безопасности. Если же сетевой трафик будет зашифрован, злоумышленнику будет труднее перехватить и выбрать ценные данные. При использовании Windows 2000 разработчики сетей могут определять зоны безопасности внутри корпорации, используемые для защиты некоторых важных ресурсов. При этом менее важные ресурсы остаются открытыми (рис. 1.3).
Открытые ресурсы
Термин "открытые ресурсы относится к передаче незашифрованных данных. Администраторы и разработчики сетей должны проявлять осторожность, когда имеют дело с какими-либо данными, передаваемыми "открыто", поскольку в этом случае их можно легко просмотреть и прочитать с помощью программ анализаторов сетевых пакетов либо сетевых мониторов.
Корпоративная сеть
Рис. 1.3. Зоны безопасности внутренней сети.
В качестве примера, демонстрирующего недостатки подобной конфигурации, рассмотрим структуру сети, требующую зашифрованного доступа к серверу отдела кадров. Подобное шифрование приводит к реализации защите данных, передаваемых по двустороннему каналу связи, который установлен по отношению к серверу. Но в случае, если сервер выполняет хостинг некритических файлов, шифрование данных не требуется. Эта тема обсуждается подробнее в главе 6.
Наиболее важным свойством, проявляющимся в случае добавления сетевого шифрования, является возможностьфункциональных
без измененияприложений и переобучения пользователей. В случае с
Windows 2000 положительный момент заключается в том, что реализация свойств безопасности становится относительно простой.
При использовании сетей VPN возникает вполне предсказуемое затруднение, пров том, что система "несет бремя" шифрования и декодирования всех данных, передающихся сетевыми серверами. К счастью, эта проблема решается использования оборудования, берущего на себя выполнение криптографических задач (разгрузка центрального процессора). Управление ключами, которое является встроенным в Windows 2000, приводит кувеличению сетевого трафика.
Пользователь имеет возможность управлять частотой использования шифрования, новываясь на потребностях сети и системы безопасности.
Другие преимущества виртуальных частных сетей
Сетиимеют множество других применений, и еще большее число областей
использования появится впо мере роста популярности этой технологии. Те
лекоммуникационные компании используют сетевые каналы VPN для передачи речевого и широковещательного трафика, а также в некоторых других целях. По мере эволюции в направлении полностьюсреды чтобы современный под
ход к проектированию сетей был коренным образом изменен.
Используя возможности сетей VPN, предлагаемые Windows 2000, можно решать следующие задачи:
уменьшитьзатратынаподдержкусетипримернонаЗС~83% согласно различ
ным оценкам аналитиков;
повысить степень надежности благодаря резервированиючастот сети
общего назначения;
практически неограниченная дальность действия, обеспечивающая доступ удаленных пользователей к корпоративным узлам в обычном режиме;
сетевые подключения между компаниями, находящимися в раз
личных государствах;
усовершенствованный контроль и улучшенное управление для передаваемых данных.
Благодаря использованию виртуальных частных сетей можно настроить одну отдельно взятую систему для обеспечения доступа к Internet и корпоративным ресурсам. При этом не требуются отдельные маршрутизаторы, модемные стойки или серверы удаленного доступа. В данном случае также упрощается расширение сети, изменение конфигурации и выполнение обновлений. Единственный сетевой канал обеспечивает использование оптимальной скорости передачи данных, исключая необходимость выполнения дополнительных подписок (выделенные линии) и простоя канала (коммутируемые телефонные линии). Кроме того, при использовании сетей VPN упрощается проектирование сети, выполнение сетевых операций, а также облегчаются задачи сетевого администрирования.
Резюме
Наступило время для внедрения в производственной среде виртуальных частных сетей. По мере того, как все больше производителей создают программное и аппаратное обеспечение, предназначенное для работы с сетями VPN, все больше пользователей используют эти сети в качестве составной части своих производственных сетей. Теперь, когда Microsoft обеспечила полноценную поддержку сетей VPN в составе Windows 2000, лидирующие компании переходят на применение этих высокотехнологичных решений, позволяющих увеличить степень гибкости сетевых конфигураций и сэкономить немалые средства.
2
Основы развертывания виртуальных частных сетей
Приступая к обсуждению различных возможностей технологии туннелирования Windows 2000, нужно очертить круг необходимых понятий и терминов. Рассматриваемая терминология не является специфичной для Windows 2000, ее можно применять при использовании практически каждого программного продукта, имеющего отношение к сетям VPN. После уточнения терминологии, применяемой в книге, в главе обсуждается важный вопрос: "Каким образом развертываются виртуальные частные сети?" Сначала необходимо четко обрисовать круг задач, решаемых в конкретной среде, затем определить, отвечает ли туннелирование этим запросам. В главе также рассматривается большое число нештатных ситуаций. которые возникают при попытках получения доступа к сетям со стороны хакеров. В результате пользователь может осознавать важность зашиты серверов. В конце главы рассматриваются основные проектные решения, связанные с туннельными сетями.
Терминология
А теперь приступим к определению некоторых понятий, связанных с сетями VPN. При этом нужно ознакомиться со следующими терминами.
Сервер VPN (известен под именем туннельного сервера). Компьютер, который получает доступ к VPN-соединениям с помощью VPN-клиентов. Сервер VPN может поддерживать удаленный доступ для подключений VPN либо подключений типа “ маршрутизатор- маршрутизатор” ("узел-узел"). Сервер VPN подключен к общедоступной сети. В книге в роли туннельного сервера в первую очередь рассматривается Windows 2000, но существует также большое количество туннельных серверов других типов.
Клиент VPN (известен под именем туннельного клиента). Компьютер, иниции- руюший VPN-подключение к серверу VPN. В качестве клиента VPN может использоваться отдельный компьютер, поддерживающий удаленный доступ для подключения VPN или маршрутизатора, реализующего подключение VPN на уровне "маршрутизатор-маршрутизатор". В книге преимущественно рассматриваются клиенты VPN Windows 2000, Windows 98 и Windows NT 4.
Туннель. Логическая связь между туннельным клиентом и сервером. При реализации этой связи зашифровываются и инкапсулируются данные. После создания туннеля возможна пересылка данных с его помощью без использования шифро-
вания, однако использовать подобное подключение VPN не рекомендуется, поскольку пересылаемые данные могут перехватываться и просматриваться.
Граничный сервер. Этот туннельный сервер является внешним сервером частной сети компании, Обычно все, что находится "за" этим сервером (в корпоративной сети) представляет собой трафик "открытых фреймов", который может быть легко перехвачен. Если фреймы захватываются в частной сети, безопасность трафика будет "под угрозой" даже в том случае, если в сети используется туннель, установленный по направлению к граничному серверу. В результате этот сценарий не позволяет в полной мере поддерживать систему безопасности, реализуемую по схеме "точка-точка". В качестве граничного сервера может выступать брандмауэр или же какая-либо система, не выполняющая других функций, кроме обработки туннельного трафика.
Безопасность, реализуемая по схеме "точка-точка". Меры безопасности, реализуемые по схеме "точка-точка", воплощаются на практике в качестве пути от клиента до фактического сервера назначения. При передаче данных по этому пути происходит их шифрование на всем протяжении. Поскольку технология, которая требует практического внедрения безопасности по схеме "точка-точка", появилась совсем недавно, в настоящее время в большей части проектов используется на границе корпоративной сети специфический туннельный сервер. Если безопасность соблюдается в полной мере, не имеет значения, где именно перехватываются фреймы. На всех этапах передачи данных выполняется их шифрование. В то же время в большинстве проектов на границе корпоративной сети используется специальный туннельный сервер, а шифрование выполняется только на пути между клиентом и туннельным сервером.
Произвольный туннель. Пользовательский или клиентский компьютер может формировать VPN-запрос для конфигурирования и создания произвольного туннеля. В этом случае компьютер пользователя выступает в роли конечной точки, а также играет роль туннельного клиента. Для клиента должен1 быть установлен соответст- вуюший туннельный протокол. Этот протокол требуется при создании многих сетевых проектов, поскольку со стороны корпоративных сетей в общем случае невозможно установить общий контроль над домашними локальными сетями. Использование туннельных клиентов в качестве фактических конечных точек уменьшает степень потенциального риска для системы безопасности.
Принудительный туннель. Туннель, который сконфигурирован и создан с использованием сервера удаленного доступа, обеспечивающий поддержку сетей VPN. При использовании принудительного туннеля компьютер пользователя не выступает в роли конечной точки туннеля. Туннельной конечной точкой является другое устройство, сервер с удаленным доступом. Этот сервер располагается между компьютером пользователя и туннельным сервером и функционирует как туннельный клиент. Подобная конфигурация позволяет использовать туннель одновременно нескольким клиентам, работающим в филиале или в домашней локальной сети. При этом несколько компьютеров могут совместно использовать отдельный канал.
Разработка проектов
Перед тем, как приступить к развертыванию сетей VPN, следует задуматься над очевидным вопросом, который заботит многих администраторов: "Для чего следует внедрять VPN?” Существует множество причин, благоприятствующих внедрению сетей этого типа. Наиболее значимые из них подробно рассматриваются в следующих разделах. Если вы заинтересованы в развертывании сетей VPN, потребуется ознако-
миться с преимуществами, возникающими в подобной ситуации. Может именно перечень имеющихся преимуществ позволит получить исчерпывающий ответ на вопрос относительно цели внедрения сетей VPN.
Дороговизна сетевого доступа
Учитывая все возрастающий объем затрат, связанных с аппаратным и программным обеспечением, а также затраты на модернизацию имеющейся техники, компании проявляют заинтересованность в других решениях. Эти решения, с одной стороны, должны отвечать технологическому прогрессу, а с другой стороны, — привести к минимизации накладных расходов. Рассматривая различные альтернативные решения, можно прийти к выводу, что именно сети VPN позволяют получить существенную экономию денежных средств. В этом случае удаленные пользователи смогут установить локальную телефонную связь с Internet из любого местоположения, а затем использовать это соединение для поддержки связи с вычислительными ресурсами корпорации. Подобный подход позволяет компаниям не тратить средства на приобретение модемных стоек, а также не отказываться от вложений с целью поддержки и обновления существующих модемов. Помимо этого, существенно экономятся средства, затрачиваемые на оплату междугородных телефонных переговоров с удаленными пользователями.
При использовании сетей VPN значительно возрастают доходы филиалов офисов, поскольку туннельное соединение позволяет поддерживать двустороннюю связь с корпоративными серверами и ресурсами без использования дорогостоящих выделенных линий и специального оборудования. Другое преимущество заключается в возможности быстрого и эффективного открытия филиалов офисов, поскольку в данном случае устанавливаемые подключения не зависят от определенного провайдера линии. В этом случае также сокращается время, затрачиваемое на установку соединения. Если для установки выделенной линии требуется около 6-12 недель, для инсталляции DSL или кабельного модема — около 2—3 недель, то установка удаленного подключения занимает немногим более 24 часов. Помимо этого, появляется возможность установки более скоростных подключений к Internet, в результате чего обеспечивается более быстрое соединение с филиалами офисов с помощью сетей VPN. Также следует учитывать, что в случае изменения задач, выполняемых филиалом офиса, значительно дешевле модифицировать подключение VPN, чем модернизировать выделенную линию.
Большинство корпораций озабочены проблемами безопасности для данных на том или ином уровне, что находит отражение в процессе проектирования сети. Несанкционированный доступ к данным может привести к крупным материальным потерям. Например, при обращении к услугам банка клиент всерьез заинтересован в конфиденциальности его персональных данных. В то же время производственные компании заинтересованы в том, чтобы сохранять в тайне от конкурентов результаты своих разработок.
Довольно затруднительно точно оценить объем денежных средств, который затрачивается на поддержку безопасности при различных уровнях защиты данных, передаваемых с помощью сетевых соединений. Разработчику сети следует провести переговоры с различными командами в составе корпорации с целью выполнения сегментирования и идентификации критических данных и/или серверов. Затем на базе Windows 2000 можно определить политики и зоны безопасности, основываясь на текущем проекте сети.
Если пользователь из Калифорнии желает воспользоваться своим портативным компьютером для получения доступа к корпоративной сети в Нью-Йорке, ему придется воспользоваться телефонным номером 1-800 или, что еще хуже, установить непосредственную связь по междугородному каналу связи. Конечно же, в качестве альтернативы можно воспользоваться возможностями сетей VPN. Все большее число пользователей выбирают этот подход не только потому, что часто находятся в командировке, но также и потому, что переходят на надомный труд. В пользу данного выбора имеется множест-
во доводов. Например, согласно результатам исследования производительность при надомном труде намного выше, чем при работе в офисе, поэтому более гибкой становится и политика найма на работу. Например, в компании Compaq тысячи служащих трудятся дома в течение полного рабочего дня. При этом довольно быстро распространяется обычай обеспечивать связь между подобными филиалами офисов с помощью сетей VPN. Благодаря использованию подобного подхода, обеспечивается доступ к определенным уникальным возможностям, которые недоступны для портативных компьютеров.
Чтобы полностью устранить необходимость в междугородных телефонных переговорах, удаленные пользователи должны получать локальный доступ с помощью глобального провайдера услуг Internet (ISPJ. Используя соединение с internet, можно устанавливать подключение VPN к корпоративному туннельному серверу. Большинство провайдеров услуг Internet позволяют поддерживать VPN-трафик, И, несмотря на то, что некоторые провайдеры используют патентованное программное обеспечение, можно сконфигурировать клиенты с целью обеспечения эффективного соединения. Даже провайдеры, ориентированные на нужды потребителя, например, провайдеры сети AOL, могут конфигурироваться с целью поддержки подключений VPN в корпоративных сетях. Однако, в любом случае важно внимательно ознакомиться с контрактом, заключаемым с провайдером услуг Internet, чтобы уточнить, входит ли услуга поддержки подключений VPN в перечень предоставляемых услуг.
Если компания располагает филиалами по всему миру, использование выделенных линий, обеспечивающих связь с этими офисами, обходится очень дорого. В то же время каждый филиал может быть подключен к Internet. В этом случае подключение может обеспечиваться с ПОМОЩЬЮ сетей VPN, которые поддерживают те же службы, что и выделенные линии. Эта возможность является настраиваемой, позволяет изменять конфигурацию, а также не зависит от конкретного провайдера услуг Internet.
Ранее описанный подход может использоваться в том случае, если компании необходимо в интересах поставщика соединить две разрозненные сети. Например, предполоЖИМ, что компании Compaq и Microsoft имеют туннельный сервер, позволяющий устанавливать двустороннее соединение с обеими сетями. В этом случае клиент, работаю- ший с двумя корпорациями одновременно, может эффективно связываться с обеими компаниями, используя технологии туннелирования. Этот процесс может протекать в виде отдельных сеансов связи, а также осуществляться в параллельном режиме.
Многие компании применяют VPN-технологии вместо выделенных линий для установки связи с узлами и сетями своих партнеров. Применение таких технологий обеспечивает все преимущества выделенных линий, а также позволяет существенно экономить на стоимости подключения. Вполне возможна такая ситуация, когда клиенты обеих сетей получают доступ к ресурсам каждой сети.
Безопасность данных
Меры безопасности, призванные защитить данные от доступа извне, получили в последнее время широкое распространение. Операционная система Windows 2000 предлагает широкий спектр возможностей, которые значительно облегчают реализацию мер безопасности в рамках существующей инфраструктуры. Структура сети позволяет реализовать систему безопасности, которая делится на несколько уровней. Если требуется соблюдать безопасность в полном объеме, следует рассматривать пассивный сетевой мониторинг, аутентификацию сетевого доступа, обновление данных, безопасность, основанную на приложениях, а также некоторые другие методы. Поскольку в данной книге преимушественно рассматривается проектирование сетей, уделяется внимание вопросам безопасности, связанным с использованием сети, а также их связям с разработкой сетей VPN.
При работе с Windows 2000 разработчики могут создавать защищенный маршрут от источника к месту назначения, а также в обратном направлении. В таком случае организации, заинтересованные в соблюдении мер безопасности, могут использовать Windows 2000 в новом свете. Ранее подобные подходы были либо вообще невозможны, либо требовали использования нестандартных аппаратных решений. На данном уровне возможно использовать шифрование, опираясь на встроенные возможности протокола IPSec, а также, благодаря использованию связанных политик по конфигурированию параметров подключения.
Уровень сетевой безопасности бывает удовлетворительным в том случае, если реализуется безопасность по схеме "точка-точка". В этом случае сетевой трафик контролируется в каждой точке в ходе процесса передачи данных, а корпорация может быть уверена в соблюдении безопасного прохождения трафика. Подобный тип шифрования не является специфичным для сетей VPN. Он может применяться в локаль- ных/глобальных сетях, а также при использовании туннелей.
В прошлом многие корпорации использовали параллельные сети с целью разделения трафика. Подобный прием препятствовал обычному перехвату данных, передаваемых в отдельной сети. В этом случае в “защищенной сети" не оставалось открытых и доступных сетевых портов, что является общепринятой практикой в стандартных сетях. Реализация подобного подхода обходится очень дорого, поскольку корпорации должны не только обеспечивать функционирование двух полностью разделенных сетей, но также вынуждены разделять аппаратное обеспечение и персонал. Кроме того, практически невозможно гарантировать, что защищенная сеть будет полностью безопасной, поскольку методы прослушивания информации, циркулирующей по сетям, постоянно совершенствуются.
В настоящее время корпорации могут при шифровании различных групп трафика или ресурсов использовать разные политики. Такой подход приводит к образованию зон безопасности. Например, база данных, связанная с финансами, должна находиться в зоне безопасности более высокого уровня, а принтер — в зоне безопасности более низкого уровня. После того, как разработчик определит, какие ресурсы находятся в тех или иных зонах, можно сформировать группу конфигурационных политик Active Directory, где и будут отражаться эти особенности проекта.
При работе с Windows 2000 организация может использовать агрессивный механизм защиты, направленный на пресечение несанкционированных попыток проникновения в сеть. Возможно, большие затраты времени на отслеживание трафика VPN являются непозволительной роскошью, однако, подобный подход позволяет учесть потенциальные "проколы" в системе безопасности и попытаться устранить их.
На первом этапе внедрения мер безопасности требуется определить сетевую топологию компании; если речь идет о крупной организации, то подобный процесс весьма затруднен. В этом случае разработчику потребуется отследить каждый сегмент, каждый брандмауэр, каждое подключение к Internet и даже не аутентифицированные связи с отделами или серверами.
Если разработчик намерен развернуть защищенную сетевую среду, воспользовавшись при этом организационными мерами, этому процессу должны способствовать все сотрудники корпорации; в противном случае соблюдение сетевой безопасности будет под вопросом. Даже один из сотрудников, использующий телефонную линию при работе на своем настольном компьютере с ОС Windows 98, может запустить сервер удаленного доступа Plus Pack, в результате чего возникнет серьезная угроза для сетевой безопасности. Сетевой администратор имеет массу возможностей для того, чтобы воспрепятствовать этому, и самая главная из этих возможностей заключается в использовании компьютерных политик. Команда, обеспечивающая безопасность, обычно и определяет компьютерные политики организации. В некоторых отраслях промышленности общее направление подобной политики определяется регулирующими агентствами.
Совет
Исходя из опыта автора, самым важным моментом гарантирования безопасности при функционировании сети является наличие исчерпывающего представления о проекте данной сети. Нужно представлять исключительно все, от соединительных кабелей до политик, которых придерживаются ваши клиенты. Важно располагать документацией, отражающей конфигурацию сети, тогда ее трафик нетрудно проследить и ясно представить. Также можно будет приступать к исследованию необычного или трудно прогнозируемого трафика. В любом случае во главу угла ставится ознакомление с документацией, поскольку именно подобный мониторинг и метод поддержки при функционировании сети предполагает слаженную работу всей группы.
Методы несанкционированного доступа к сетевомутрафику
Иногда создается впечатление, что, практически, каждые несколько дней появляется новый вирус, метод несанкционированного доступа к данным или же очередная выведенная из строя сеть. В последнее время появляется множество программных продуктов, обеспечивающих Предотвра щение попыток несанкционированного доступа к сетевым данным. Эти программы могут применяться для отслеживания отклонений в "поведении" сети или серверов, предупреждая возможность несанкционированного доступа. Подобный подход существенно отличается от сканирования, предпринимаемого с целью обнаружения стандартного вируса. В последнем случае приходится ожидать, когда вирус "атакует" систему, а затем уже предпринимать попытки его устранения.
Большинство доступных программ, идентифицирующих попытки несанкционированного доступа к сети, служит для "отражения" всех возможных видов несанкционированного доступа. Если фиксируется попытка незаконного "вторжения" в сеть, сетевому администратору направляется соответствующее извещение или же запускается программа, обеспечивающая защиту сетевых ресурсов, либо выполняются оба этих действия. На рынке программного обеспечения предлагается большое количество пакетов, предотвращающих нежелательное проникновение в сеть. Однако я настоятельно советую использовать лишь программные продукты известных фирм.
Сетевому администратору следует учитывать тот факт, что попытки несанкционированного доступа к сети подразделяются на следующие типы:
атаки, приводящие к отказу в обслуживании;
имитация адреса;
проникновение хакеров во время сеанса связи;
сетевые анализаторы пакетов ;
атаки, приводящие к раскрытию ключей;
изменение данных;
"человек посередине";
ответные атаки ;
метод "грубого взлома";
подбор паролей и атаки со словарем;
социальные атаки.
Каждая из этих разновидностей атак обсуждается в следующих разделах.
Атаки, приводящие к отказу в обслуживании
Атаки, приводящие к отказу в обслуживании, представляют собой наиболее распространенную форму "взлома" системы безопасности, В процессе осуществления подобной атаки хакер столь сильно насыщает трафиком сетевой интерфейс, что сервер перегружается и не может отвечать на запросы. Другая разновидность подобной деятельности заключается в том, что хакер пересылает на компьютер специальные пакеты, содержащие недостоверную информацию. Это приводит к сбоям в функционировании операционной системы компьютера. Подобный подход не слишком продуктивен, поскольку в результате хакер не получает доступа к ценной информации. В данном случае хакер имеет единственную цель, которая заключается в нарушении нормального функционирования сети.
Ранее для предотвращения атак, приводящих к отказу в обслуживании, существовало сравнительно немного возможностей. Большинство пользователей пытались изолировать источник атаки, а затем сконфигурировать свои брандмауэры таким образом, чтобы полностью блокировать трафик по отношению к данному источнику. Однако, подобный подход не приводил к успешному отражению атаки, если физической "интервенции" подвергался администратор сети. ОС Windows 2000 позволяет таким образом сконфигурировать сервер, что существенно уменьшается принципиальная возможность подобной атаки. Для конфигурирования сервера применяются фильтры, и, что еще лучше, используются политики IPSec, которые блокируют трафик, если он не вызван какой-либо необходимостью.
Ни один сервер, доступный в сети, не может быть полностью защитен от атак, приводящих к отказу в обслуживании. Но если сервер сконфигурирован должным образом, то в этом случае существенно снижается риск подобных вторжений.
Имитацияадреса
Используя особенности структуры сетей TCP/IP, хакеры могут "вводить в заблуждение" целевые системы. Они вынуждают их воспринимать сетевые пакеты таким образом, как будто бы они направляются из других местоположений. Компьютер, нахо- дяшийся за пределами брандмауэра, может "обмануть" компьютер, расположенный в зоне, контролируемой брандмауэром. В этом случае ваш брандмауэр может "поверить", что весь связанный трафик порождается внутри корпоративной сети. В результате, используя внешний компьютер, можно получить доступ к внутренним сетевым ресурсам, который останется не зафиксированным.
Процесс "имитации" возможен в силу того, что набор протоколов TCP/IP является независимым от нижних уровней сетевой модели OSI. Вследствие несовершенства маршрутизации пакетов, а также из-за недостатков, проявившихся при конструировании заголовков, практически невозможно гарантировать подлинность источника конкретного пакета. Если трафик пересылается из точки А в точку Б, в точке Б предполагается, что трафик действительно передается из точки А.
Атаки, приводящие к отказу в обслуживании, могут производиться с помощью серверов лавинной адресации. Причем, в этом случае используются пакеты, исходный адрес которых не определяется. Обычно для "обмана" используется IP-адрес исходного пакета, который оказывается недостижимым. Чаше всего используется имитация частного адреса. И когда сервер откликается на трафик, он получает сообщение ICMP Destination Unreachable (Цель недостижима). С целью уменьшения риска возникновения подобных ситуаций следует добавить к серверу фильтр, который пропускает все пакеты, за исключением тех, исходный адрес которых является стандартным частным адресом типа 10.0.0.0, 172.16.0.0 или 192.168.0.0. Более подробная информация о настройке фильтров содержится в главе 10.
Проникновение хакеров во время сеанса связи
Проникновение хакеров во время сеанса связи происходит в том случае, если сеанс связи, установленный между источником А и сервером Б, незаконно перехватывается и копируется. Как правило, хакер выполняет перехват сеанса TCP, установленного между двумя компьютерами. Поскольку аутентификация обычно выполняется в начале сеанса с использованием незашифрованного трафика, система хакера получает возможность принять участие в сеансе связи двух систем.
Затем хакер может сконфигурировать компьютер таким образом, чтобы сопоставить свой адрес с адресом реального компьютера или сервера, который может участвовать в сеансе связи. Компьютер хакера может выступить в роли почтового сервера вашей корпорации или просто "обмануть" систему проверки достоверности, пересылая ей ее же IP пакеты.
В то время, когда компьютер хакера имитирует почтовый сервер корпорации, все клиенты пересылают или получают электронные сообщения хакеру, а не на реальный сервер. Все это время система хакера собирает всю пересылаемую ей информацию. К тому времени, когда сетевой администратор обеспокоится фактом неподобающего функционирования почтового сервера, возможно, "подложная" система хакера уже отключится от сети, а хакер соберет всю нужную ему информацию. Таким образом, происходит стандартная утечка данных.
Проникновение хакеров во время сеанса связи можно предупредить путем шифрования данных, передаваемых в сети. При анализе перехваченных данных хакер должен сначала расшифровать их. Кроме того, компьютер, направляющий данные, должен отменять трафик, который перехвачен "неопознанной" системой.
Сетевые анализаторы пакетов, недостаточная степень конфиденциальности
Сетевой анализатор пакетов представляет собой устройство, предназначенное для захвата всего трафика сети, Ранее, в эпоху первых сетей, сетевые анализаторы пакетов были весьма дорогостоящими и редко встречались. Теперь же, благодаря внедрению операционных систем Windows NT и Windows 2000 (и даже Windows NT Workstation), в комплекте с которыми поставляются простейшие версии сетевых анализаторов пакетов, эти устройства являются широко распространенными. При сетевых коммуникациях в Ethernet данная проблема теряет свою остроту, поскольку каждый сегмент сети Ethernet изолирован с помощью порта.
Сетевой анализатор пакетов может применяться для просмотра всего трафика, передаваемого по локальной сети. Если трафик закодирован, анализатор пакетов просто передает данные в исходном виде. Если же данные открыты и незашифрованны, они могут быть с успехом просмотрены. Сетевой анализатор пакетов является одним из универсальных инструментов, служащих для диагностики возникающих сетевых проблем. Однако, он также может служить и хакеру в его стремлении нанести ущерб системе.
Атаки, приводящие к раскрытию ключей
Атаки, приводящие к раскрытию ключей, успешно выполняются в том случае, если хакер получает доступ к ключам, ПОЗВОЛЯЮЩИМ выполнять шифрование и дешифрование данных, и затем перехватывает данные. Поскольку в этом случае ключ перестает выполнять свои функции, хакер получает возможность расшифровывать и просматривать данные. Обычно этот прием используется в том случае, если для ключа применяется набор строк, поскольку в этом случае ключ не изменяется длительное время. Очевидно, что для предотвращения подобного несанкционированного доступа следует вместо статического ключа использовать динамический ключ.
Подобные типы атак были широко распространены ранее, когда передача ключей по сети осуществлялась с помощью различных методов, не обеспечивающих безопасность. Подобный метод атаки также применялся в том случае, если система оказывалась "взломанной", а хакер получал ключи доступа к этой системе. Конечно же, подобная атака может быть достаточно успешной и сегодня, когда секреты становятся общедоступными. И администратор системы должен нести ответственность за то, чтобы ключи не стали всеобщим достоянием.
Если среда поддерживает процедуру динамического изменения ключа, например, Internet Key Exchange (IKE), вероятность перехвата ключа сильно уменьшается, поскольку подобный ключ невозможно подобрать вручную. Кроме того, этот ключ изменяется периодически либо по определенному расписанию, либо при передаче определенного объема данных. Поэтому, даже при успешном подборе ключа, хакер сможет получить доступ только к небольшой части данных.
В рамках технологии IKE используется подход, получивший название Perfect Forward Secrecy(PFS), когда при изменении ключа применяется долговременный ключ, а кратковременные ключи создаются по мере необходимости. Даже если хакер узнает долговременный ключ, он не сможет получить доступ к данным без кратковременного ключа. Более подробно о технологии IKE можно узнать из главы 6,
Изменение данных
Подобный прием используется при перехвате трафика, который пересылается из точки А в точку Б. Затем данные изменяются и направляются в точку Б. В точке Б неизвестно, что трафик был изменен после его отсылки из точки А, а в точке А отсутствуют сведения о том, что трафик изменялся еще до того, как попал в точку Б.
Хакер может установить системы перехвата трафика и выполнять поиск необходимых данных с помощью шаблонов данных или ключевых слов. Затем эти шаблоны или ключевые слова заменяются фальсифицированными данными. Например, процесс может выполнять поиск стандартного формата номера кредитной карточки Visa. Верный учетный номер кредитной карточки Visa сохраняется в базе данных, а затем его исходное значение заменяется поддельным номером. В результате предотвращается успешное завершение транзакции, причем в распоряжение хакера поступает достоверный учетный номер кредитной карточки Visa.
Для предотвра щен ия подобных атак проще всего выполнять шифрование данных, передаваемых по сети. В этом случае использование шаблона поиска ни к чему хорошему не приводит, а в распоряжение хакера поступают лишь зашифрованные данные, которые не могут быть просмотрены.
"Человек посередине"
В данном случае речь идет об изменении тех данных, которые не должны изменяться. Эти данные должны анализироваться, сохраняться или служить в качестве образца. "Человек посредине" имеет полную власть над данными на пути их перемещения из точки А в точку Б. Весь секрет заключается в том, что ни в точке А, ни в точке Б неизвестно о том, что данные перехвачены. При этом "человек посередине" получает над этими данными всю полноту власти. Данные можно изменить или даже похитить, и все пройдет без малейшего риска обнаружения.
Хакер может удалить пример исходного общего ключа и сохранить его в базе данных. Затем можно создать фальшивую пару частного/общего ключей, присоединить ее к исходному сообщению и переслать сообщение по месту назначения. Если среда плохо настроена, именно этот сфальсифицированный общий ключ, поступивший из исходной системы, может использоваться для шифрования сообщений. В этом случае хакер может дешифровать любое сообщение, которое пересылается с использованием сфальсифицированного частного ключа, который к тому же и создан самим хакером.
Основным отличием подобного подхода от пассивного мониторинга сети является тот факт, что хакер имеет полный контроль над данными, которые передаются между исходным пунктом и местом назначения. Атаки типа "человек посредине" обычно представляют собой комбинацию нескольких разновидностей атак.
Ответная атака
Ответная атакавыполняется в том случае, если хакер перехватывает и регистрирует трафик, направленный из точки А в точку Б, а затем ретранслирует его в точку Б. При этом используется информация, которая была собрана в результате выполненного ранее перехвата данных. Ответный трафик неупорядочен, а его поведение трудно предсказуемо, что приводит к непредсказуемым последствиям для целевого компьютера.
Даже если хакер не может считывать перехваченные данные, он может послать позднее ответное сообщение. В данном случае им перехватывается трафик с после- дуюшей его ретрансляцией на целевой компьютер. Примером осуществления подобной атаки может послужить случай, недавно происшедший с автором этой книги. Как-то раз он слушал музыку, воспроизводимую в режиме реального времени, из Internet. Его сотрудник, не разделявший моих музыкальных пристрастий, перехватил поток данных за несколько секунд и ретранслировал его по тому же самому каналу. Подобные действия привели в "полное замешательство" аудиоплейер, который зафиксировал ошибку, а также прекратил воспроизведение "наступательной" музыки,
Атака методом “грубого взлома"
Атака методом "грубого взлома" происходит обычно в том случае, когда данные зашифрованы с помощью какого-либо известного алгоритма. Однако поскольку хакер не знает ключ, после перехвата зашифрованных данных ему приходится использовать МОЩНЫЙ компьютер для "взлома" зашифрованных данных путем подбора ключа.
В прошлом этот метод был довольно неэффективным. Однако, учитывая мошь современных процессоров и скорость, с которой могут подбираться ключи, хакер, использующий метод "грубого взлома", может представлять серьезную угрозу. В настоящее время в его распоряжении имеется инструментальный набор (такой как LOpthcrack, предназначенный для "взлома" паролей Windows NT), с помощью которого можно будет реализовать собственное аппаратное решение, с помощью которого возможно осуществление "взлома" ключей.
Один из наиболее простых методов, используемый для затруднения использования метода "взлома", заключается в увеличении частоты смены ключей. Этот вопрос необходимо учитывать при определении компьютерных политик. Также следует принимать во внимание тот факт, что в Internet доступно множество утилит, позволяюших реализовать на практике метод "взлома".
Подбор паролей и атаки со словарем
Как и следует из названия, программа подбора паролей представляет собой процедуру, при реализации которой компьютер "пытается" подобрать пароли, обычно путем выбора слов из словаря с последующим добавлением широко распространенных символов. В связи с этим следует проинструктировать пользователей сети относительно важности применения защищенных паролей, включающих символы в различных регистрах, числа и знаки пунктуации. Даже имея дело с подготовленными пользователями, неплохо было бы ужесточить политики с тем, чтобы пользователи выбирали пароли, удовлетворяющие заранее определенным критериям.
Стратегии социальных атак
Возможно наиболее распространенным методом обхода системы безопасности является использование "человеческого фактора". Можно установить самый высокий уровень шифрования, выбрать замысловатый пароль, а также составить наилучшие планы организации системы безопасности организации, но если хакер выдает себя за сотрудника службы технической поддержки и убеждает пользователя сообщить пароль по телефону, все планы обеспечения безопасности сети не достигнут цели.
Социальные атаки не ограничиваются телефонными звонками; пользователи, записывающие свои пароли на клочках бумаги, рискуют их рассекретить перед сотрудниками, посетителями офиса либо даже перед швейцаром.
Общепринятой практикой городских хакеров является обыск мусорных контейнеров с целью нахождения бумажных листков с записанными паролями. Наилучшей зашитой в этом случае является реализация плана тренировок для всех пользователей сети. Имеются также другие стратегии, например, стратегии, основанные на использовании смарт-карт и сертификатов, позволяющие предотвратить проблему. Все сводится к тому, что пользователи должны осознать возможный риск и придавать вопросам обеспечения безопасности наивысший приоритет.
Резюме по методам сетевых атак
Наиболее важный вывод в связи с наличием сетевых атак заключается в том, что при наличии незащищенного сетевого трафика (в большинстве случаев) передаваемые данные оказываются незащищенными. Если пользователь, подключившийся к сети (авторизованный или неавторизованный), прослушивает трафик, он может захватить любые передаваемые данные. Если шифрование данных не выполняется, даже новичок сможет перехватывать все почтовые сообщения, направляемые от различных компьютеров, а также считывать частную почту в момент ее передачи. Подобные атаки отличаются от атак, направленных на сервер. Намного труднее атаковать сервер, поскольку в этом случае придется иметь дело с правами доступа, основанными на использовании сервера, либо со списками управления доступом (ACL), служащими в качестве системы безопасности.
Основной целью применения виртуальных частных сетей является защита данных, передаваемых по сети такими уязвимыми приложениями, как Telnet, FTP и РОРЗ. Хотя в настоящее время сетевые администраторы обеспечивают защиту от простого перехвата имен пользователей и паролей, благодаря повсеместному шифрованию сетевых данных обеспечивается полная безопасность сетевой информации. Подобный уровень безопасности обеспечивает защиту корпоративных данных во всех сетях, локальных и глобальных.
Развертывание виртуальных частных сетей
Теперь, когда вы наслышаны о методах, позволяющих использовать преимущества сетей VPN, будут рассмотрены некоторые типичные примеры развертывания этого типа сетей.
Во избежание использования междугородной связи либо звонков по номеру 1-800 (и связанных с эти затрат), внешний клиент может воспользоваться Internet для установки VPN-соединения с корпоративной сетью, как показано на рис. 2.1.
Два выделенных узла либо удаленные каналы связи с провайдером услуг Internet могут иметь связи VPN. В качестве примера можно рассмотреть соединения офисного филиала, показанные на рис. 2.2.
Туннелирование через корпоративную сеть во многом напоминает удаленный доступ через Internet за исключением того, что клиент и целевые сети находятся в корпоративной сети. Благодаря этому пользователи подучают доступ к защищенным или скрытым сетям, как показано на рис. 2.3.
Рис. 2.2. Соединение через InternetРис. 2.2. Соединение через Internet
Рис. 2.2. Соединение через Internet
Рис. 2.2. Соединение через Internet
может применяться для подключения двух или более защищенных либо скрытых сетей, находящихся в одной и той же корпоративной сети, основываясь на безопасности учетных записей. В качестве примера обратите внимание, каким образом скрытые сети подключаются с помощью VPN-соединения через внутреннюю сеть предприятия (рис. 2.4).
Кроме того, туннель, связывающий две сети, может иметь другой туннель, как показано на рис. 2.5. Подобная конфигурация иногда используется для разрешения вопросов, связанных с многопротокольной средой, а также иногда требуется для выполнения нестандартных сетевых проектов. Другой причиной использования туннеля внутри туннеля является шифрование IP-трафика, необходимое для создания системы безопасности
сетьсетьРис. 2.3. Удаленный доступ в корпоративной сетиРис. 2.3. Удаленный доступ в корпоративной сети
сеть
сеть
Рис. 2.3. Удаленный доступ в корпоративной сети
Рис. 2.3. Удаленный доступ в корпоративной сети
Если провайдер услуг Internet имеет доступ к службе VPN, поддерживаемые провайдером услуг Internet службы VPN могут применяться для ссылки на отдельные У3' лы путем инициирования туннеля, идущего от сетевых связей через сеть VPN провайдера услуг Internet. Подобная конфигурация приведена на рис. 2.6.
Корпоратн»'® сеть
Рис. 2.4. Подключение к корпоративной среде
Рис. 2.5. Туннель внутри другого туннеля
Рис. 2.6. Туннелирование по направлению к службе TPN, поддерживаемой провайдером услуг Internet
Концепции проектирования сетей
с использованием технологии туннелирования
Поскольку вы начали рассмотрение принципов функционирования технологии туннелирования, важно понять, какое место занимает эта технология в вашей среде. Хотя большинство проектов сетей VPN могут быть реализованы благодаря гибкости используемой технологии, некоторые проекты будут реализованы лучше других. Выбор лучшего проекта для конкретной среды связан с выбором сетевой архитектуры. При этом нужно рассмотреть несколько вопросов, связанных с определением сетевой инфраструктуры, сетевой технологии и брандмауэров.
Сетевая архитектура
Изначально сетевой администратор должен быть знаком с текущей сетевой средой. Для перехода к защищенной сетевой среде нужно внимательно изучить имеющуюся сетевую топологию. Это может быть довольно затруднительным, особенно при больших размерах сети. Неплохим методом отслеживания внешних связей является анализ телефонных счетов. Счета телефонной компании позволяют получить статистику применения выделенных линий, а также каналов связи, которые могли быть установлены ранее. Автор имел дело с сетями, которые настолько разрослись либо претерпели столько объединений, что никто не мог подробно описать все имеющиеся связи. До тех пор, пока эти данные не будут найдены и задокументированы, неизбежны проблемы с обеспечением безопасности, а также некоторые технические сложности.
Еще одна проблема, заботящая сетевого администратора, заключается в выборе поддерживаемого протокола. Все больше и больше сетей переходят на исключительное использование набора протоколов TCP/IP. Однако это правило имеет некоторые исключения. Инфраструктура сетей VPN может требовать поддержку протоколов IPX, AppleTalk, NetBEUI, а также некоторых других протоколов. Перед тем, как устанавливать сеть VPN, необходимо определиться с используемыми типами протоколов.
Например, потребуется принять решение, стоит ли продолжать поддерживать протокол IPX для наследственных серверов NetWare. Если Ваш туннельный сервер является сервером Windows 2000 и клиенты по-прежнему нуждаются в получении доступа к серверам NetWare, им придется воспользоваться РРТР либо L2TP для доступа к корпоративной сети, поскольку эти протоколы допускают использование IPX. Подобные требования к выбору протокола также влияют на конфигурацию маршрутизатора и клиента. Подобные дополнительные соображения по поводу конфигурации обязательно должны быть составной частью плана развертывания.
Сетевая топология
Сетевая топология играет важную роль в разработке плана корпоративной сети VPN. Во-первых, необходимо располагать исчерпывающими сведениями относительно среды маршрутизации. Клиенты и серверы VPN должны найти свое место в сетевой инфраструктуре маршрутизации. В противном случае инфраструктуру придется изменять с не- лью приспособления к сетям VPN. При настройке маршрутизации сетей VPN доступна огромное количество опиий по настройке маршрутизации, и для каждой сети имеются свои особенности, а также устанавливаются собственные каналы связи.
Сетевая топология является критически важной при разработке решения на основе сетей VPN, обеспечивающих связь с филиалами офисов. Разрабатываемый проект должен вписываться в рамки существующей инфраструктуры, иначе новые сетевые маршруты могут быть нефункциональными.
Сетевой администратор должен иметь ясное представление относительно особенностей протоколов TCP/IP и маршрутизации, а также знать принципы функционирования существующей сети. После появления туннельных серверов, даже в случае необходимости обеспечения доступа клиента должно быть решено множество вопросов. Необходимо сформулировать план, согласно которому разрабатывать компоненты DDNS, параметры области доступа DHCP, маршруты, загрузку сети, внешние адреса, а также некоторые другие вопросы. Ни один из этих проектов не может планироваться до тех пор, пока не будут полностью изучены существующая сетевая инфраструктура и топология.
Брандмауэры
При проектировании виртуальных частных сетей чрезвычайно важно учитывать конфигурацию брандмауэра. В больших организациях, имеющих не один брандмауэр, возникает общая проблема, связанная с тем, что не все брандмауэры конфигурируются одинаковым образом. Фактически многие компании имеют различные типы брандмауэров, подключенных самым разным путем. Поскольку эти устройства обеспечивают развертывание сетей VPN, чрезвычайно важно обеспечить совместимость их конфигурации во всей организации. Необязательно использовать брандмауэры одного типа, важно получать при их использовании одни и те же результаты.
Конфигурирование брандмауэра является довольно сложной задачей, поскольку приходится учитывать демилитаризованные зоны, настройки транзитных протоколов, а также списки ACL. Чрезвычайно важно, чтобы сетевой администратор координировал и управлял настройками брандмауэра с точки зрения их связи с сетями VPN. Поскольку брандмауэр является одним из ключевых компонентов сети, некорректная его настройка приводит к выходу из строя всей сети. Подробно эти вопросы будут освещены в главе 8.
В некоторых сетевых средах брандмауэры не устанавливаются даже на удаленных узлах. В подобных сетях применяется так называемая фильтрация пакетов (фильтрация пакетов представляет собой разновидность "брандмауэра", блокирующего неавторизованный трафик). Помимо этого некоторые клиенты удаленного доступа, используя сетевую политику либо вручную, могут инициализировать фильтрацию пакетов во время подключения к сети VPN. Использование подобных стратегий позволяет гарантировать отсутствие неавторизованного трафика, направляемого ресурсам корпоративной сети, подключенной к Internet с помощью VPN. К вопросам использования фильтрации пакетов требуется подходить, учитывая потребности корпоративной сети.
Многие разработчики сетей VPN используют односторонним либо двусторонним образом инициированные соединения, при установке которых используются свойства маршрутизации, выполняемой по требованию, службы маршрутизации и удаленного доступа (RRAS — Routing and Remote Access Service). Подобный подход диктует необходимость определения среды маршрутизации для сети VPN. При этом также определяется метод реализации зон безопасности, создаваемых с учетом маршрутизации.
Резюме
По мере обзора методов развертывания технологии туннелирования очень важно представлять, каким образом эта технология может быть развернута в конкретной среде. Вряд ли можно найти две различных компании, имеющие подобную сетевую инфраструктуру, и, наверное, невозможно создать руководство, в котором были бы описаны все возможные типы сетевых конфигураций. Аккуратно используя технические сведения о свойствах туннелирования Windows 2000, формулируя цели, которые должны быть достигнуты, а также учитывая существующую конфигурацию сетевой среды, вы сможете определить план развертывания, который будет выполняться "без сучка, без задоринки”.
3
Виртуальные частные сети и Windows 2000
Внедрение технологий виртуальных частных сетей в среде Windows 2000 имело определяющее значение при формировании межплатформенных сетей VPN. В отличие от ранее наблюдавшейся ситуации, программное обеспечение VPN, включенное в состав Windows 2000, начало соответствовать стандартам комитета Инженерной группы решения конкретной задачи Internet (IETF — Internet Engineering Task Force) (ранее применялись патентованные стандарты Microsoft). Благодаря этому облегчилось взаимодействие с другими операционными системами, которое к тому же стало требовать меньше усилий со стороны сетевых администраторов.
Хотя технология туннелирования появилась еще в Windows NT 4.0, но там она выступала в виде своего рода "надстройки". Операционная система Windows 2000 создавалась уже на основе этой технологии, причем в процессе создания были реализованы многочисленные новые свойства. Многие из этих свойств напрямую связаны со средой туннелирования; другие свойства позволяют внедрять новые методы эффективного использования технологии туннелирования. Помимо этого Microsoft проделала большую работу в плане обеспечения безопасного и эффективного развертывания среды VPM. Далее будут приведены примеры новых свойств в Windows 2000.
Active Directory.
Протокол туннелирования "точка-точка" (РРТР - - Point-to-Point Tunneling Protocol).
Протокол туннелирования уровня 2 (L2TP — Layer 2 Tunneling Protocol).
Протокол обеспечения безопасности в Internet (IPSec - - Internet Protocol Security).
Обмен ключей в Internet(IKE — Internet Key Exchange).
Трансляция сетевого адреса (NAT — Network Address Translation).
Диспетчер подключений (Connection Manager).
Сервер сертификатов (Certificate Server).
Система динамического именования доменов (DDNS — Dynamic Domain Name System) .
Active Directory
Если вы имеете представление относительно Windows 2000, то наверняка слышали о таком примечательном объекте, как Active Directory. С появлением Active Directory в сетевом программном обеспечении Microsoft управление ресурсами и пользователями стало чрезвычайно простым. Объект Active Directory оказывает влияние практически на каждый компонент Windows 2000. Это связано с тем, что большинство компонентов конфигурируются и поддерживаются с помощью Active Directory централизованным образом. Все новые приложения, относящиеся к типу BackOffice, разрабатываются для платформы Windows 2000. При этом реализуется интеграция с Active Directory. Диапазон приложений варьируется от Exchange 2000, Internet Security и Acceleration Server до протокола динамического конфигурирования хоста (DHCP —Dynamic Host Configuration Protocol).
В большинстве книг, посвященных технологиям туннелирования, описывается клиентский доступ к корпоративным сетям. Это, возможно, наиболее важное применение технологии VPN, хотя в последнее время появляется все больше и больше компаний, применяющих технологии VPN для обеспечения связи между филиалами, а также для распределения доменных контроллеров. С того времени, как автор этой книги начал работу с Windows 2000, значительно улучшилась технология конфигурирования сетей. Улучшения явились следствием зрелости технологий VPN. Благодаря этим технологиям разработчики получили возможность проектировать сети с применением смешанных технологий, а также создавать эффективные и недорогие проекты сетей.
Проект HappyVPN
Как-то я решил проверить теорию на практике и приступил к развертыванию структуры Active Directory, поддерживающей исключительно сети VPN. Эта структура должна была охватывать многие местоположения в Internet. Проект получил название Happy VPN, а его цель заключалась в тестировании различных технологий, а также в подтверждении моей собственной теории, согласно которой возможно создать распределенную сеть, вообще не использующую выделенные линии. Результатом подобного эксперимента, наряду с приобретенным опытом, явилась разработка технологий клиентского доступа, являющихся предметом рассмотрения данной книги. Многие из рассматриваемых возможностей не описаны в документации либо никогда не использовались в реальных сетях, поэтому автору пришлось протестировать множество решений. Б результате проведенных экспериментов и тестов были отобраны наилучшие технологии.
Работа над проектом выполнялась два года, и к концу этого периода было реализовано полнофункциональное развертывание Active Directory, использующее исключительно подключения VPN. В результате значительно облегчилась установка связи с новыми филиалами офисов, упростилось осуществление изменения ранее созданных каталогов, появились возможности осуществления мониторинга репликации на другие узлы, развертывать приложения на удаленных узлах, а также решать множество других задач, отказавшись от применения выделенных линий.
При разработке любой сети проектирование каналов связи не является слишком сложным, но все же уровень детализации, достигаемый при конфигурировании Active Directory, позволяет реализовать систему репликации таким образом, что даже низкоскоростные каналы связи будут полнофункциональными. Многие из этих вопросов будут рассмотрены в главе 12.
Еще в Windows NT 4.0 у администратора была возможность разрешить или запретить удаленный доступ к сетям VPN путем назначения определенных прав доступа. С появлением Windows 2000 эта возможность была усовершенствована, благодаря чему пользователь получил возможность разрешать или запрещать доступ к политике уда-
ленного доступа. Политика удаленного доступа может быть просмотрена в процессе выполнения запроса на подключение, причем процесс оценки производится с использованием параметров, определенных администратором. Например, если требуется разрешить пользовательский доступ в промежутке между десятью часами вечера и шестью часами утра, для решения этой задачи можно соответствующим образом настроить политику удаленного доступа.
Политика удаленного доступа включает определение множества свойств, отличных от простого планирования. Эти свойства варьируются от определения типа туннеля и разрешения доступа к некоторым группам безопасности до добавления атрибутов Ascend RADIUS.
Примечание
Во время разработки сети в рамках проекта Happy VPN в политике удаленного доступа я обнаружил настройку типа туннеля, которая оказалась особенно полезной при переходе от протокола РРТР (первая фаза) к протоколу L2TP.
Протокол РРТР
Протокол туннелирования "точка-точка" (РРТР) появился еще в операционной системе Windows NT 4.0. Он является наиболее широко используемым протоколом VPN. Благодаря хорошей поддержке и простоте использования, с помощью этого протокола реализуются наиболее практичные решения, подходящие для большинства сред. Все современные версии операционных систем Microsoft имеют встроенную поддержку РРТР. Этот протокол также поддерживается многими предыдущими версиями операционных систем. Для этого достаточно было загрузить пакеты обновлений, доступные в Web. Помимо этого со временем появились клиенты, не имеющие отношения к Microsoft, которые являются свободно распространяемыми и могут быть загружены из Internet.
Протокол РРТР для Windows 2000 подвергся значительной переработке по сравнению с его первоначальной реализацией в Windows NT 4.0. В процессе доработки были устранены ошибки в системе безопасности, а также увеличилось быстродействие. Протокол РРТР использует технологию шифрования "точка-точка" фирмы Microsoft (МРРЕ — Point-to-Point Encryption), применяемую для шифрования с целью обеспечения безопасности сети. Протокол РРТР также использует подключение TCP, известное под названием РРТР Control Connection (Соединение контроля РРТР) с целью создания, поддержки и прерывания туннеля. Также применяется модифицированная версия протокола обобщенной инкапсуляции (GRE - - Generic Routing Encapsulation) с целью инкапсуляции фреймов РРТР, используемых в качестве туннельных данных. Дополнительные сведения о протоколе РРТР можно найти в документе RFC 2637. Этот протокол более подробно будет обсуждаться в главе 4.
Чаше всего приверженность протоколу РРТР критикуется в силу того, что он является патентованным решением Microsoft. Я полагаю, что эта проблема не является слишком серьезной, хотя в начале это негативно отразилось на репутации Microsoft. Одно из преимушеств определения либо использования стандартов в данном случае заключается в том, что пользователи, работающие в различных средах и имеюшие разный уровень подготовки, могут тестировать новую технологию. В главе 4 кратко рассматриваются затруднения, возникшие в тот момент, когда обнаружилось, что реализация протокола РТР для Windows NT 4.0 оказалась небезопасной при его начальном развертывании.
Эти затруднения были разрешены в версии протокола РРТР для Windows 2000. Данная версия протокола является быстродействующей, простой в использовании и может использоваться большинством сетевых устройств.
Протокол L2TP
В то время как Microsoft представила на рассмотрение комитета по стандартам IETF протокол PPTP 2.0, фирма Cisco представила протокол перенаправления уровня 2 (L2F - Layer 2 Forwarding). После рассмотрения этих предложений комитет IETF предложил двум компаниям объединить обе технологии с целью облегчения создания патентованных протоколов. В результате появился протокол туннелирования уровня 2 (L2TP - Layer 2 Tunneling Protocol). Протокол L2TP использует протокол инкапсуляции нагрузки системы безопасности (ESP — Encapsulating Security Payload) IPSec. Этот протокол используется для выполнения шифрования (описан в документе RFC 2661). Протоколы L2TP и I PSec подробно описаны в главе 7.
Рассматривая некоторые дополнительные компоненты, требуемые для эффективного развертывания протоколов L2TP/IPSec, сетевой администратор задается вопросом: "Для чего нужно переходить на использование протокола РРТР?" Ответ заключается в том, что протокол L2TP/IPSec позиционировался в качестве стандарта IETF, и большинство разработчиков сетей адаптировались к нему. Наиболее приятное отличие от протокола РРТР проявляется в том, что небольшое количество поставщиков, работающих изначально с фирмой Microsoft, теперь могут реализовать сетевые решения различных производителей, отличных от Microsoft.
Благодаря использованию подхода, основанного на применении новых стандартов компании Microsoft, появляются аппаратные устройства, снимающие с центрального процессора "бремя обязанностей" по шифрованию туннельных данных. В настоящее время практически каждая крупная операционная система располагает клиентами, реализованными на основе этих стандартов, которые либо разрабатываются сторонними производителями, либо входят в состав операционной системы.
Подобный подход обладает недостатком, который заключается в том, что большинство программных продуктов и их модификаций еще не подготовлены к его восприятию. Обычно используется метод разделения подключений. В этом случае трафик, реализуемый в соответствии с протоколом L2TP/IPSec, не проходит через устройство NAT. Эта проблема может быть разрешена различными методами, хотя в подобной ситуации лучше всего обновить используемый стандарт NAT. До тех пор, пока этого не произойдет, необходимо при работе с клиентами, имеющими отношение к серверу NAT, пользоваться протоколом РРТР.
Различия между протоколами РРТР и L2TP
Несмотря на то, что тип поддерживаемых туннельных клиентов обычно диктует туннельную технологию, между протоколами РРТР и L2TP/IPSec имеются и некоторые иные различия. Во-первых, туннели РРТР могут проходить через сервер NAT, в то время как подобная возможность отсутствует в случае с туннелями L2TP/IPSec (глава 8). Во-вторых, вместо использования ресурсов центрального процессора протокол L2TP/IPSecпозволяет задействовать возможности плат разгрузки криптографического аппаратного обеспечения, выполняющего все задачи по шифрованию и декодированию данных. При использовании протокола РРТР эта возможность недоступна. И, наконец, в процессе обычного развертывания протокола L2TP/IPSec требуется использование машинных сертификатов, что приводит к усложнению процесса развертывания сетей VPN. Существуют также и другие технические различия, но мы остановимся на наиболее простых примерах.
Протокол L2TP сам по себе не нуждается в машинных сертификатах, поскольку IPSec может применяться в качестве механизма шифрования. Взаимная аутентификация, использующая компьютерные сертификаты клиента и сервера, станет возможной в том случае, когда будет установлен IPSec со стороны ассоциации безопасности (SA). Этот вопрос будет рассмотрен подробнее в главе 6.
Протокол IPSec
Протокол безопасности Internet (IPSec — Internet Protocol Security) является, возможно, наиболее важным инструментом обеспечения сетевой безопасности. Важность этой технологии для современной вычислительной среды объясняется следующими обстоятельствами:
существует возможность перехвата трафика, направленного по сетевым коммуникациям, независимо от типа коммуникаций и их местонахождения. Это влечет за собой необходимость защиты всего объема трафика вне зависимости от типа используемой среды (локальные, глобальные, беспроводные сети, виртуальные частные сети, и так далее);
компании не могут идти по пути создания новых версий своих приложений. Это обходится слишком дорого (наглядным примером послужила модернизация программного обеспечения с целью преодоления пресловутой "проблемы 2000 года’’);
при обеспечении безопасности трафика следует учитывать, что при этом не должна снижаться производительность. При выполнении шифрования данных в сети нецелесообразно совершать масштабные обновления в сети;
поддержка ключа шифрования должна быть удобной и выполняться в автоматизированном режиме. При зашите данных не следует использовать пароль или какой-либо иной секрет, который можно переправить с помощью электронной почты для ознакомления с ним других пользователей.
Протокол IPSec поддерживает систему безопасности, которая позволяет осуществить полный, но наряду с этим достаточно "прозрачный" контроль над безопасностью при функционировании всех приложений и служб. Этот протокол можно применять при работе с локальными либо глобальными сетями, а также в случае выполнения удаленного доступа. Реализация версии протокола IPSec Windows 2000 основана на использовании стандартов, что влечет за собой совместимость не только с операционными системами Microsoft, но и с операционными системами других производителей. И, что самое важное, эта технология представляет собой стандарт IETF, разработанный и проверенный с учетом интересов всех основных пользователей Internet. Более подробная информация по этому вопросу содержится в главе 6.
Протокол IPSec в Windows 2000
В Windows 2000 протокол IPSec выполняет три основные функции, перечисленные ниже.
L2TP поверх IPSec (L2TP/IPSec). В Windows 2000 протокол L2TP интегрируется с помощью политики IPSec, которая отвечает за процесс шифрования, аутентификации данных и целостность туннеля.
Протокол IPSec в транспортном режиме. Протокол IPSec поддерживает защиту данных с помощью шифрования всего трафика локальных и глобальных сетей. Конкретные параметры основаны на конфигурации политики протокола IPSec. Сеть или сетевой администратор могут для всех или только для определенных клиентов заблокировать сервер или службу в определенной конфигурации.
Протокол IPSec в режиме туннелирования. Рассматриваемая конфигурация позволяет воспользоваться истинной средой в режиме туннелирования, которая в этом случае будет независима от протокола L2TP. ОС Windows 2000 поддерживает этот режим, но, вообще говоря, он включается с целью связывания различных сетей с помощью метода "шлюз-шлюз Туннельный режим протокола IPSec позволяет пропускать лишь трафик TCP/IP,а конфигурация туннелей может быть весьма сложной.
Реализация протокола IPSec для Windows 2000 поддерживает интеграцию с системой безопасности Windows 2000 в следующих областях:
централизованное администрирование политики по обеспечению безопасности с помощью IPSec на уровне Active Directory;
гибкое конфигурирование системы безопасности;
поддержка IKE для автоматизированного управления ключами и соглашением по безопасности;
поддержка инфраструктуры общего ключа (PKI), предварительно разделенного ключа, а также аутентификации Kerberos.
Стандарт IPSec усилиями IETF был завершен в 1998 году и, в основном, изложен в документе RFC 2401. В настоящее время единственной операционной системой Microsoft, поддерживающей протокол IPSec, является Windows 2000. Однако, протокол IPSec поддерживается большим числом поставщиков операционных систем, не относящихся к Microsoft, а также различным аппаратным обеспечением. Кроме того, программное обеспечение некоторых сторонних производителей создается с учетом использования протокола L2TP/IPSec в ранних версиях операционных систем Microsoft и в других операционных системах. Более подробно эти вопросы рассматриваются в главе 6.
Обмен ключей Internet (IKE)
Какой бы тип шифрования не использовался, еще до того момента, когда данными, зашифрованными с помощью протокола IPSec, можно будет обмениваться между компьютерами, необходимо установить некую взаимосвязь. Эта взаимосвязь именуется ассоциацией безопасности (SA — security association). С помощью SA две системы приходят к согласию на предмет того, каким образом происходит обмен и защита данных. Метод IKE (Обмен ключей Internet — Internet Key Exchange) представляет собой стандартный метод IETF, обеспечивающий согласование безопасности и обмен ключей.
Метод IKE централизует контроль над согласованием безопасности, генерирует и управляет аугентифицированными ключами, используемыми для обеспечения безопасности при передаче данных. Кроме того, IKE позволяет администратору настраивать характеристики процесса обмена ключами (например, частоту обмена ключами). Таким образом уменьшается вероятность подбора ключа и декодирования перехваченных данных.
В настоящее время разработано большое количество методов, реализующих обмен ключей, причем некоторые из них используют протокол IPSec. Однако стандартным является метод IKE, а идеология Windows 2000 не предполагает использование нестандартных решений. И снова, благодаря стандартному подходу к использованию этой технологии, Windows 2000 может взаимодействовать с операционными системами, отличными от операционной системы или устройств Microsoft.
Протокол NAT
Протокол трансляции сетевых адресов (NAT ««Мм Network Address Translation) обеспечивает использование несколькими клиентами одного подключения. 8 результате применения протокола клиенты и ресурсы могут совместно использовать сетевые подключения. В данном случае речь идет о логических подключениях (VPN), а также о физических подключениях (например, сетевые карты). Протокол NAT выполняется на уровнях 3 и 4 сетевой модели OSI. В результате выполнения протокола пакеты изменяются таким образом, как будто бы они направляются через сервер NAT. Протокол NAT выполняет трансляцию трафика таким образом, что внутренние клиенты могут использовать
диапазон частных адресов, привязанный посредством сервера NAT к единственному общему сетевому адресу. Этот принцип противоположен принципу функционирования прокси-сервера уровня 7, когда клиентские приложения вынуждены сами обращаться к прокси-серверу, а изменение пакетов выполняется перед их отправкой клиентом,
Операционная система Windows 2000 поставляется вместе с двумя различными реализациями протокола NAT. Операционная система Windows 2000 Professional поставляется совместно с протоколом разделения подключений Internet (ICS — Internet Connection Sharing), обеспечивающим поддержку общедоступного соединения с помощью NAT. Конфигурирование протокола ICS не относится к числу простых задач. В состав операционной системы Windows 2000 Server входит не только ICS, но и полный спектр возможностей NAT, которые могут быть сконфигурированы в окне службы маршрутизации и удаленного доступа (RRAS — Routing и Remote Access Service) подключаемого модуля консоли управления Microsoft (ММС — Microsoft Management Console). Имейте в виду, что ICS и RRAS NAT основаны на технологиях NAT. Единственное отличие проявляется при реализации этой технологии.
Диспетчер подключений
Если при установке и конфигурировании подключения Internet и туннеля к корпоративной сети проявляются какие-либо затруднения, вполне вероятно, что потребуется помощь. В этой ситуации может оказаться полезным диспетчер подключений (Connection Manager), благодаря которому сетевой администратор может определять профили при конфигурировании клиентов таким образом, что они будут действительно поддерживаться.
Изначально диспетчер подключений входил в состав Windows NT 4.0 Server Option Pack, но затем этот программный продукт был усовершенствован и включен в состав ОС Windows 2000. И теперь, благодаря применению Windows NT 4.0 Server Option Pack, администраторы получили возможность быстро развертывать как службы удаленного доступа, основанные на применении модемов, так и сети VPN. Спектр задач, выполняемых с использованием этого программного продукта, охватывает как поддержку телефонных номеров провайдеров услуг Internet и/или адресов туннельного сервера, так и возможность развертывания приложений. В книге не рассматривается пошаговое руководство по созданию профилей диспетчера подключений, поскольку эти сведения изложены в справочной документации по Windows 2000. Более подробная информация по этому вопросу содержится в главе 9.
Сервер сертификатов
В Windows 2000 технологии VPN могут использовать сертификаты двумя основными методами: при аутентификации пользователя в процессе регистрации, а также в качестве сертификатов компьютеров, которые требуются для протоколов L2TP/IPSec. Несмотря на то, что протокол РРТР не использует сертификаты компьютеров, в корпорациях все шире распространяется практика, заключающаяся в использовании более сложного процесса регистрации, чем требование стандартного ввода имени пользователя и пароля. Сетевая архитектура может потребовать наличия смарт-карты, содержащей сертификат пользователя, требуемый для выполнения аутентификации всех регистрации VPN.
Протокол L2TP требует наличия сертификатов компьютеров, в результате чего установка сервера VPN на базе протокола РРТР существенно отличается от установки сервера VPN на базе протокола L2TP/IPSec. Если необходимо обратиться к серверу, поддерживающему клиенты L2TP/IPSec, обязательно присутствие инфраструктуры сертификатов.
Сервер сертификатов появился еще в Windows NT 4.0 Server Option Pack. Операционная система Windows 2000 может быть интегрирована вместе с Active Directory или же установлена отдельно. Сервер сертификатов выпускает стандартные сертификаты, хотя клиенты могут применять любой требуемый тип сертификата. С целью удовлетворения требований к сертификатам со стороны технологий VPN в Windows 2000 можно применять серверы сертификатов сторонних производителей, однако, обычно лучше воспользоваться решением от Microsoft. Объект Windows 2000 Active Directory позволяет клиентам, имеющим в каталоге корректные учетные записи для своих компьютеров, автоматически выпускать машинные сертификаты, используя сервер сертификатов. В этом случае интегрированный сервер сертификатов может выпускать, контролировать и обновлять сертификаты. Более подробно этот вопрос рассматривается в главе 5.
Динамический DNS
В Windows 2000 появилась RFC-совместимая динамическая система именования доменов (DDNS — Dynamic Domain Name System), которая позволяет реализовать динамическую регистрацию имен хостов в зонах. В этом случае компьютеры и связи VPN могут регистрироваться уже в момент подключения. Система DDNS, используя виртуальные частные сети, коренным образом изменяет весь процесс преобразования имен.
Ранее, используя протокол РРТР в Windows NT 4.0, клиенты располагали двумя возможностями для регистрации имен компьютера. Имя NetBIOS можно было регистрировать с помощью системы имен Internet Windows (WINS — Windows Internet Name System) либо вовсе не регистрировалось. Это приводило к появлению массы проблем. Если клиент, не работающий под управлением Windows, связывался с сервером РРТР, этот клиент вовсе мог обходиться без имени NetBIOS, и поэтому имя не регистрировалось. Также, поскольку при формировании имени NetBIOS не учитывается никакая иная информация, кроме обычного пространства имен, вполне возможно появление конфликтов между именами.
ОС Windows 2000 позволяет клиенту регистрировать имя хоста и название домена при подключении к туннелю. Кроме того, если туннельный сервер имеет клиентов, для которых не установлен DDNS, можно воспользоваться сервером DHCP для обработки распределения адресов TCP/IP клиентов, а также для регистрации DDNS. Таким образом, устаревшие клиенты могут пользоваться преимуществами DDNS, даже если они непосредственно не поддерживают регистрационный процесс.
При развертывании среды Active Directory на основе подключений VPN с точки зрения регистрации важно выполнять работу продуманно, выполняя непрерывный контроль, Желательно, чтобы при регистрации определенных клиентов в некоторых местоположениях требовалась установка DDNS для филиалов, которые могли бы изменяться. Подобный подход должен быть основополагающим при формировании плана сети.
Объект Active Directory практически не требует DDNS, однако использование DDNS значительно облегчает процесс развертывания и управления Active Directory. Протокол DDNS также поддерживает решения, позволяющие динамически изменять IP-адреса, которые являются типичными для большинства сред VPN. Более подробно вопросы, связанные с протоколом DDNS, рассматриваются в главе 11.
Гибко настраиваемый сетевой трафик
Все службы в Windows 2000 настраиваются, основываясь на потребностях и возможностях сети. Объект Active Directory конфигурируется с учетом времени, частоты и способа, с помощью которого выполнена репликация. Данный уровень конфигурирования позволяет администратору изменять проект Active Directory, основываясь на скорости передачи и наличии связей, устанавливаемых по случайному закону.
ОС Windows 2000 учитывает требования качества обслуживания (QoS — Quality of Service), которое позволяет операционной системе на базе определенного критерия выделять приоритеты в сетевом трафике. Протокол JPSec имеет некоторые ограничения, но при работе в среде VPN приоритеты могут быть назначены именно логическим связям. Например, более высокий приоритет можно установить для потокового трафика в режиме реального времени по сравнению с процессами стандартной загрузки FTP.
Упрощенная настройка машрутизатора
При использовании Windows NT 4.0 Server одним из самых сложных периодов при развертывании VPN с использованием конфигураций настраиваемой сети является реализация среды маршрутизации. В Windows 2000 эта проблема решается таким образом, что администратор может конфигурировать среду маршрутизации. Также в этом случае можно использовать туннельный клиент, что значительно увеличивает гибкость, достигаемую при использовании сети. В Windows 2000 появились следую- шие усовершенствования, связанные с маршрутизацией.
OSPF. В Windows 2000 реализована полная поддержка протокола первоочередного открытия кратчайшего пути (OSPF I-'I-— Open Shortest Path First), что позволяет выполнять динамическое обновление маршрутов и поддерживать соединение для корпоративных аппаратных маршрутизаторов.
RIP. В Windows 2000 обеспечивается полная поддержка информационного протокола маршрутизации (RIP — Routing Information Protocol) версий 1 и 2.
Улучшенные возможности статической маршрутизации. С помощью интерфейсов удаленного подключения по требованию записи статичного маршрута для VPN направляются вместо IP-адресов к объектам подключения. В этом случае таблица маршрутизации присоединяется к динамически изменяемым IP-адресам после выполнения подключения.
Статические маршруты после подключений. Если Active Directory функционирует в "собственном" режиме, администратор может присваивать статические маршруты в качестве присоединенных при реализации подключений к пользовательским объектам в Active Directory.
Упрощенное присваивание статических IP-адресов. В "собственном" режиме администратор может резервировать статические IP-адреса на базе пользовательского объекта в Active Directory.
В отличие от других VPN-решений программные продукты компании Microsoft имеют исторически предопределенные ограничения для клиентов. Это связано с тем, что полноразмерный трафик использует туннельное подключение к заданному по умолчанию шлюзу. В результате весь трафик — как корпоративный сетевой трафик, так и весь трафик Internet — должен проходить через корпоративную сеть. Это решение вызвано необходимостью поддерживать дополнительные меры безопасности. В главе 10 обсуждается вопрос о соответствующем планировании и вводе ПОДХОДЯЩИХ настроек безопасности. Этого можно добиться без ущерба для безопасности, и подобный подход позволяет увеличивать производительность и добиться большей гибкости при обработке трафика, ограниченного Internet.
Резюме
При работе с Windows NT 4.0 администратору приходилось устанавливать Option Pack, обновлять системный реестр и применять сервисные пакеты. В результате можно было пользоваться виртуальными частными сетями. В Windows 2000 все эти, а также многие другие возможности встроены изначально. В настоящее время администраторы могут поддерживать довольно быстрое, легкое в использовании и удобное для администрирования решение VPN. Операционная система Windows 2000 поставляется вместе с технологиями, обеспечивающими установку и работу с сетями VPN.
4
Протокол туннелирования
"точка-точка" (PPTP)
При работе с VPN -технологиям и чаше всего используется протокол туннелирования "точка-точка" (РРТР — Point-to-Point Tunneling Protocol). Причина подобного положения дел заключается в том, что компания Microsoft позиционировала этот протокол, предназначенный для серверных операционных систем, на рынок для общего пользования. Протокол РРТР представляет собой расширение протокола РРР (Point- to-Point Protocol), который разрабатывался для осуществления удаленного доступа при использовании обычных телефонных линий.
Протокол РРТР был анонсирован комитетом Internet Engineering Task Force (IETF) в 1996 году. Его полная реализация была выполнена в первой версии Windows NT 4.0. Сетевая технология РРТР представляет собой расширение протокола удаленного доступа РРР, который определен комитетом IETF и описан в документе RFC 1171 как "The Poinr-to- Point Protocol for the Transmission of Multi-Protocol Datagrams over Point- to-Point Links" ("Протокол "точка-точка", предназначенный для передачи многопротокольных дейтаграмм с помощью подключений "точка-точка"). Протокол РРТР инкапсулирует фреймы РРР в 1Р-дейтаграммы, а затем осуществляет их передачу с помощью IP-сетей, например, с помощью Internet или внутренней частной сети. Описание протокола РРТР можно найти в документе RFC 2637.
Одним из крупных преимуществ протокола РРТР является относительная простота его развертывания. Инфраструктура сетей VPN может быть довольно сложной, особенно если используется среда маршрутизации, процесс аутентификации и тому подобные компоненты. Достаточно просто выполнить развертывание протокола РРТР в случае стандартного удаленного доступа. Еще меньше забот может потребовать реализация простого решения РРТР VPN при поддержке доступа для удаленных пользователей, а также пользователей Internet. Протокол РРТР не требует установки сервера сертификатов, также не нужен сервер аутентификации какого-либо специального типа. Можно реализовать довольно простое решение на основе аналогичной аутентификации Windows, используемой при выполнении удаленного развертывания.
Часто компании, использующие Windows 2000, реализуют туннельные решения на базе протокола РРТР, когда также поддерживается протокол туннелирования уровня 2 (L2TP - Layer 2 Tunneling Protocol) и протокол безопасности IP (IPSec — IP Security). Благодаря использованию этой конфигурации, бизнес-процесс перемещается в плоскость решения на основе использования IPSec, причем не требуется применять исключительно протокол IPSec. Компании могут и в дальнейшем поддерживать клиенты Windows 9x и Windows NT 4,0, которые не используют решение на базе протоколов L2TP/IPSec.
В этом случае также важно обеспечение поддержки домашних локальных сетей. Во многих подобных средах для совместного использования подключения с Internet применяется сервер трансляции сетевых адресов (NAT — Network Address Translation). В то же время протокол IPSec не может направлять данные через устройство, обеспечивающее совместное применение подключения, если это устройство не маршрутизирует соответствующий протокол. Более подробные сведения по этой теме можно найти в главах 6 и 10.
Расширение РРТР, созданное на основе РРР, разрабатывалось ведущими производителями, которые сформировали так называемый форум РРТР. Среди участников этого форума такие компании, как Microsoft, Ascend, 3Com (USRobotics), Copper Mountain и ECI Telematics. Несмотря на то, что темпы распространения протокола РРТР изначально были не слишком высокими (речь об этом пойдет в данной главе), в настоящее время этот протокол является одним из самых распространенных протоколов VPN. Причина подобного успеха частично заключалась в триумфальном шествии программных продуктов Windows, а также в простоте и удобстве в применении самого протокола.
Принцип функционирования протокола РРТР
Протокол РРТР использует РРР в качестве протокола удаленного доступа, осуществляющего пересылку многопротокольных данных в сетях TCP/IP. Протокол РРР разделен на уровни, выполняющие задачи установки подключения, конфигурирования и тестирования с помощью протокола управления связями (LCP — Link Control Protocol). После инициализации протокола LCP с целью передачи трафика для определенного набора протоколов могут применяться протоколы управления сетями (NCP — Network Control Protocol). Это означает, что в рамках стандартной реализации протокола РРТР могут применяться и встраиваться все основные возможности протокола РРР. Несмотря на то, что с технической точки зрения можно инкапсулировать практически любой протокол, на форуме РРТР было принято решение относительно поддержки лишь протоколов IP, IPX и NetBEUI. В этом случае пакеты помешаются во фреймы РРР, которые пересылаются путем создания связи "точка-точка" между компьютером-отправителем и компьютером-получателем. Протокол РРР описывается в документе RFC 1661.
Свойства протокола РРР
Если рассмотреть историю развития протокола РРР и учесть, что он разрабатывался, в основном, для аналоговых подключений, может быть весьма отрадным тот факт, что данный протокол столь эффективно поддерживает туннельные подключения. Процесс развития и обогащения спецификации РРР продолжался несколько лет, а ее эффективность была проверена благодаря тестированию со стороны множества пользователей. Модификации РРР, включенные в реализацию РРТР, для установки туннеля используют следующие возможности и процессы РРР.
* Извещение об адресе. Извещение об адресе позволяет серверу информировать удаленного клиента об его IP-адресе, используемом для установки данного подключения. При этом клиенты получают возможность запрашивать IP-адреса, а также поддерживать альтернативные конфигурации. Опции РРР также позволяют передавать клиенту адреса сервера имен как Internet, так и NetBIOS. Более подробная информация по этому вопросу содержится в документе RFC 1877.
* Аутентификация пользователя. Аутентификация пользователя может выполняться с помощью протокола РРР, протокола аутентификации с помощью пароля (РАР — Password Authentication Protocol), протокола аутентификации с предварительным согласованием вызова (CHAP ,—^—< Challenge-Handshake Authentication Protocol) и протокола Microsoft CHAP (MS-CHAP).
Расширяемый протокол аутентификации (ЕАР — Extensible ЛиАепйсайоп Protocol)
С целью применения некоторых из наиболее устойчивых методов аутентификации комитет IETF определяет расширяемый протокол аутентификации РРР (ЕАР) в документе RFC 2284. Подобный подход позволяет применять несколько механизмов аутентификации, откладывая выбор определенного механизма на период аутентификации (вместо использования фазы контроля подключения). Вследствие этого аутентификатор может затребовать информацию еще до уточнения типа механизма аутентификации. В результате сервер отвечает за применение различных методов аутентификации, а аутентификатор РРР просто передает запрос о выполнении аутентификации.
Поддержка нескольких протоколов. Поддержка нескольких протоколов важна для тех сред, где для обеспечения сетевых подключений TCP/IP применяются протоколы, отличные от TCP/IP, например, Internet. Протоколы могут взаимодействовать в пределах одной и той же связи путем простого выполнения дополнительных протоколов NCP. Протокол РРР поддерживает практически каждый из вспомогательных протоколов, однако реализация Windows 2000 поддерживает лишь протоколы IPX, NetBEUI и TCP/IP.
Мониторинг канала связи. Если клиент или сервер выполняют мониторинг статуса сети, в этом случае применяется соответствующий механизм. Возможности по мониторингу связи являются встроенными и также обеспечивают посылку эхо-пакетов на уровне канала связи. Благодаря этому обеспечивается периодическая проверка функционирования канала связи.
Установка подключения с использованием протокола РРТР обычно включает три этапа. Каждый этап является логическим продолжением предыдущего; если на каком- либо из этапов происходит сбой, процесс установки подключения не может продолжаться. Далее описывается каждый из трех этапов.
Подключения и коммуникации РРР. Клиент РРТР использует протокол РРР для выполнения подключения к Internet. После установки РРР-подключения выполняется аутентификация пользователя. Аутентификация должна происходить до начала выполнения фазы протокола на сетевом уровне. Это подключение использует протокол РРР для инициализации подключения и шифрования пакетов данных.
Контрольное подключение РРТР. Используя подключение к Internet, установленное с помощью РРР, протокол РРТР создает контрольное подключение между клиентом и сервером. При установке этого подключения используется протокол TCP.
Туннелирование данных РРТР. Протокол РРТР создает IP-дейтаграммы, содержащие ззаши фрованиые пакеты РРР, которые пересылаются с помощью туннеля РРТР серверу РРТР. Этот сервер выполняет "демонтаж" IP-дейтаграмм, расшифровывает пакеты РРР и направляет расшифрованные данные по месту назначения в частной сети,
Основы функционирования РРТР
Протокол РРТР функционирует на втором уровне модели OSI (канальный уровень). Этим он отличается от протокола IPSec, который выполняется на уровне 3. Протокол РРТР инкапсулирует пакеты РРР с помощью обновленной версии протокола обобщенной инкапсуляции маршрутизации (GRE — Generic Routing Encapsulation). Протокол РРР включает методы, предназначенные для выполнения инкапсуляции различных типов дейтаграмм, передаваемых по обычным линиям телефонной связи. Спецификации РРР также определяют два набора протоколов: LCP, предназначенного для установки, конфигурирования и тестирования подключения, а также ряда
протоколов NCP, предназначенных для установки и конфигурирования различных протоколов сетевого уровня. Поскольку протокол РРТР выполняется на уровне 2 модели OSI, он может передавать по туннелю и другие протоколы, отличные от IP. В средах Windows NT 4.0 и Windows 2000 протокол РРР инкапсулирует пакеты IP, IPX и NetBEUI во фреймы РРР, а затем осуществляет их передачу, формируя связь "точка- точка" между исходной и целевой системами.
Шифрование РРТР
С целью поддержки безопасности при передаче данных по туннелю протокол РРТР применяет два патентованных свойства, которые основаны на возможностях по обеспечению безопасности данных протокола РРР. Одна из этих возможностей служит для аутентификации пользователя, а другая — для соблюдения конфиденциальности передаваемых данных. В рамках протокола РРР поддерживаются следующие методы аутентификации: протокол аутентификации с помощью пароля (PAP — Password Authentication Protocol), протокол аутентификации Shiva, выполняемой с помощью пароля (SPAP — Shiva Password Authentication Protocol), протокол аутентификации с предварительным согласованием вызова (CHAP — Challenge Handshake Authentication Protocol), протокол аутентификации по методу "вызов-квитирование установления связи" Microsoft (MS-CHAP — Microsoft Challenge Handshake Authentication Protocol) версии 1 и 2, а также расширяемый протокол аутентификации (ЕАР — Extensible Authentication Protocol). Эти протоколы используются для аутентификации пользователя. После того, как полномочия пользователя аутентифицированы относительно Active Directory (или домена Windows NT), заключительный сеанс предназначен для шифрования пользовательских данных. Компания Microsoft внедрила протокол управления сжатием (ССР — Compression Control Protocol), предназначенный для включения данных, применяемых для согласования процесса шифрования.
Протокол шифрования "точка-точка" Microsoft (MPPE — Microsoft Point-to-Point Encryption) применяется для шифрования данных при установке подключений VPN РРТР. В операционной системе Windows 2000 используется как усиленная (128битовый ключ), так и стандартная (40-битовый ключ) схемы шифрования МРРЕ. Протокол МРРЕ поддерживает защиту данных при их передаче между РРТР- подключениями и туннельным сервером, используя потоковый шифр RC4. Падение производительности при использовании RC4 для задач шифрования довольно невелико, поскольку при использовании шифра RC4 применяются лишь 14 избыточных инструкций для каждого байта, что довольно мало по сравнению с другими потоковыми шифрами. Кроме того, задачи шифрования для РРТР выполняются только в режиме ядра, а не в более затратном пользовательском режиме.
Все версии Windows 2000 включают 40-битовую версию шифра; 128-битовая версия шифра доступна только в США и Канаде. Как сервер, так и клиент для выполнения шифрования должны поддерживать на этом уровне 128-битовые ключи шифрования. Как 128-битовые, так и 40-битовые версии шифра поддерживаются всеми клиентами Microsoft, совместимыми с протоколом РРТР. Соответствующая стратегия развертывания для глобальной среды поддерживается на уровне корпорации. Чтобы план развертывания "шел в ногу" с постоянно изменяющейся законодательной базой технологий, необходимо постоянно сотрудничать с командой, обеспечивающей соблюдение мер безопасности в организации.
Безопасность и протокол РРТР
Как и в любой другой области, имеющей отношение к сетевым вычислениям, важно выработать реалистичный подход при рассмотрении практического уровня безопасности, который в процессе развертывания может обеспечить сетевой администратор.
При упоминании о протоколе РРТР многие представители отраслей компьютерной промышленности припоминают негативные обстоятельства, связанные с первоначальным появлением версии Windows NT 4.0 протокола РРТР. Некоторые специалисты в области сетевых вычислений отмечали большое количество чрезвычайно серьезных проблем, связанных с внедрением протокола Windows NT 4.0 РРТР. Среди основных проблем упоминалась следующая: при пассивном мониторинге потока РРТР система может выполнять сбор данных, которые требуется обезопасить.
В разделе рассматриваются вопросы безопасности, относящиеся к протоколу Windows NT 4.0 РРТР. Также обсуждаются методы преодоления затруднений при реализации Windows 2000, характерные для начального периода. Подобный подход к изложению поможет осознать, каким образом протокол РРТР выполняется в настоящее время.
В 1998 году Брюс Шнейер (Bruce Schneier) и Мадж (Mudge) создали технический документ, именуемый “Cryptanalysis of Microsoft's point-to-Point Tunneling Protocol (РРТР)" ("Криптоанализ протокола туннелирования "точка-точка" фирмы Microsoft (PPTP)”). В этой статье были проанализированы особенности реализации РРТР в Windows NT 4.0, в результате чего авторы пришли к выводу, что основные недостатки этого процесса не кроются в самой природе РРТР. Причина затруднений коренится, в основном, в процессе реализации протокола, который выполнялся компанией Microsoft. С этим документом, а также с аналитическим обзором попыток реализации компанией Microsoft протокола РРТР можно ознакомиться на Web-узле http:// www.counterpane.com/pptp.html. В отчете отмечено, что при реализации версии для Windows NT 4.0 наблюдались перечисленные ниже недостатки.
Хеширование пароля. Недостаточно хорошо спроектированные алгоритмы позволяют хакерам получать доступ к пользовательскому паролю.
Протокол аутентификации по методу "вызов/ответ". Недостаточная продуманность проекта позволяет хакеру имитировать сервер.
Шифрование. Ошибки при реализации позволяют получать доступ к зашифрованным данным.
Ключ шифрования. Обычные пароли приводят к тому, что ключи могут "раскрываться" даже при использовании 128-битового ключа шифрования.
Канал управления. Неаутентифицированные сообщения позволяют хакерам "взламывать" серверы РРТР.
Эти проблемы привели к тому, что в Internet стали доступны огромные объемы информации. Авторы отчета пришли к выводам, что в силу этих недостатков стал возможен перехват следующих данных:
IP-адрес туннельного клиента;
IP адрес туннельного сервера;
количество виртуальных туннелей РРТР, которые определяются сервером;
версия удаленных ключей для клиента;
имя NetBIOS для клиента;
IP-адрес внутреннего туннеля, который передается клиенту;
внутренние серверные адреса DNS, которые передаются клиенту;
пользовательское имя клиента;
достаточный объем информации для захвата хеш-пароля пользователя.
Вполне логично предположить, что после публикации этой статьи многие компании пересмотрели свои планы по внедрению сетей VPN. Одновременно с этим компания Microsoft приступила к пересмотру политики безопасности. В операционной системе Windows 2000 были не только устранены некоторые из недостатков алгоритма шифрования в реализации протокола PPTP, но также была перестроена организация потоковых кодов.
Основные проблемы, отмеченные в статье, относились к протоколу MS-CHAP версии 1. Протокол РРТР основывался на системе безопасности протокола РРР, а также задействовал возможности протокола МРРЕ с целью поддержки конфиденциальности данных, закодированных с применением алгоритма шифрования RC4. С целью инициализации этих взаимосвязей, а также в целях аутентификации в домене Windows NT в процессе шифрования используется протокол MS-CHAP.
Протокол MS-CHAP версии 1 позволяет клиенту проходить процесс аутентификации на сервере или домене Windows NT. Причем для получения ответной клиентской аутентификации на сервере не требуется генерирование отклика. Протокол MS-CHAP поддерживает методы аутентификации LAN Manager (LanMan) и Windows NT 4.0. Так же, как и в случае с использованием модели аутентификации с применением недостаточно сложных паролей, протокол MS-CHAP версии 1 обеспечивает недостаточный уровень безопасности. Это связано с тем, что процесс аутентификации LanMan уязвим по отношению к стандартным атакам со словарем в силу следующих причин:
символы преобразуются с использованием верхнего регистра, что приводит к уменьшению количества возможных паролей;
облегчается процесс сравнения известных паролей других пользователей с неизвестными паролями, поскольку хеш является прогнозируемым и не изменяется;
пароль разбивается на две части, которые можно анализировать в независимом порядке;
протокол, изменяющий исходный пароль, уязвим по отношению к операции "воровства" паролей.
Важно отметить, что реализация протокола РРТР в Windows 2000 гарантирует более основательную защиту информации, чем это было в случае с Windows NT 4.0. Компания Microsoft добилась подобного успеха благодаря внедрению "заплат безопасности", начиная еще с Windows NT 4.0.
Самым важным нововведением в сравнении с первоначальной версией протокола Windows NT 4.0 РРТР стал новый протокол MS-CHAP, в котором были предприняты улучшения в системе безопасности. Подобное обновление выполнялось для клиентов Windows 9x и NT, Обновленный вариант системы безопасности также был включен в состав Windows 2000.
В протоколе MS-CHAP версии 2 были устранены следующие проблемы, которые имели место в версии 1:
MS-CHAP версии 2 поддерживает взаимную аутентификацию между клиентом и сервером, что препятствует серверам хакеров маскироваться под легитимные серверы;
больше не поддерживается LanMan, благодаря чему хеш LanMan не может просматриваться с целью "взлома" паролей. В настоящее время процесс аутентификации должен реализоваться с использованием доменов Windows NT или Windows 2000;
разработан новый протокол, позволяющий изменять пароль в защищенном режиме, а устаревшие протоколы больше не поддерживаются;
вовсеключишифрованиявключеныданные, которыеуникальныдлятекущего
сеанса. В направлениях пересылки и получения при установке связи используются отдельные ключи шифрования;
ключи МРРЕ изменяются для каждого пакета, что позволяет выполнять шифрование без использования состояния. Протокол МРРЕ применяет метод шифрования RC4, а ключи шифрования согласуются с пожеланиями полномочных представителей пользователей.
Изменения, внесенные компанией Microsoft, позволили устранить "слабые звенья" в подсистеме безопасности протокола РРТР версии 1. Однако важно отметить, что меры безопасности при установке связи полностью зависели от пароля, который вводился пользователем. Даже при наличии усовершенствований в системе безопасности в случае, если пользователь вводит простой пароль, сеть может быть "взломана" с по- мошью стандартных атак со словарем.
Администратор сети должен убедиться в том, что пользователи не применяют простые пароли. Используемые пароли должны включать числа, символы верхнего регистра, распределенные случайным образом, слова, расположенные в обратном порядке, акронимы, знаки пунктуации, а также любые иные приемы, затрудняющие атаки со словарем с целью подбора пароля. Пользователи должны реально осознавать, как важно защитить от посягательств со стороны внешних пользователей подключения, установленные с частной сетью.
С другой стороны появляется определенный риск для системы безопасности, поскольку Windows 2000 по умолчанию поддерживает протокол MS-CHAP в версиях 1 и 2, как показано на рис. 4.1. Для установки максимально защищенной среды необходимо сконфигурировать настройки безопасности службы маршрутизации и удаленного доступа (RRAS — Routing and Remote Access Service) исключительно для поддержки протокола MS-CHAP версии 2. При осуществлении шагов процедуры 4.1 будет продемонстрировано, каким образом вносятся изменения в конфигурацию.
Рис. 4. L Параметры аутентификации, задан- ные no умолчанию
Процедура 4.1.Изменение настроек безопасности,
заданных по умолчанию
Выберите команды меню Start ф Programs ф Administrative Tools ■* Routing and Remote Access Service (Пуск Ф Программы ф Администрирование с£- Маршрутизация и удаленный доступ).
Щелкните правой кнопкой мыши на имени сервера, выберите опцию Properties (Свойства), выделите вкладку Security (Безопасность), а затем щелкните на кнопке Authentication Methods (Методы проверки подлинности) (рис. 4.1).
Выберите протокол MS-CHAP версии 2, а также отмените выбор протокола MS- CHAP версии 1.
Если администратор указывает настройки безопасности, определяющие поддержку протокола MS-CHAP версии 2, всем клиентам придется установить поддержку протокола MS-CHAP версии 2. Для клиентов Windows 9x существует лишь одна возможность поддержки MS-CHAP версии 2. Для этого требуется загрузить и установить программное обеспечение удаленного доступа к сети версии 1.3 или более поздней. Это программное обеспечение можно бесплатно загрузить с Web-узла компании Microsoft (http://www.microsoft.com).
Повышение производительности
В пакете Service Pack 5 для Windows NT 4.0 и в Windows 2000 фирма Microsoft реализовала режим без поддержки состояния. Иногда подобный режим называется режимом без поддержки истории, который применялся при обработке пакетов, для которых достигалось согласование. В этом случае МРРЕ изменяет ключ для сеанса после обработки каждого пакета.
В режиме без поддержки состояния продесс декодирования пакетов не зависит от ранее обрабатываемых пакетов. Изменение ключей, происходящее после каждой передачи пакета, приводит к резкому увеличению системной нагрузки, связанной с шифрованием. В результате протокол РРТР перед выполнением повторной синхронизации не обязан ожидать возврата пакетов после завершения циркуляции по всей сети. В результате, при использовании сетей с высокими потерями, например, Internet, существенно повышается производительность. Помимо этого становятся невозможными атаки синхронизации ключа МРРЕ. Режим без поддержки состояния появился в модуле обновления безопасности и производительности протокола РРТР (РРТР Security and Performance Update) для Windows NT 4.0, а в Windows 2000 определяется по умолчанию.
Существуют три общих конфигурации протокола РРТР. Каждая из них будет подробно рассматриваться в разделе.
Конфигурирование сервера для доступа клиентов РРТР.
Конфигурирование филиалов офисов с помощью подключений РРТР "шлюз-шлюз".
Конфигурирование клиента для связи с серверами РРТР.
Только что завершенная инсталляция Windows 2000 не настроена для приема вхо- дяших туннельных подключений. Администратор должен выполнить несколько шагов с целью установки подобных подключений. Шаги процедуры 4.2 демонстрируют, каким образом конфигурируется сервер при установке доступа для подключений РРТР.
Процедура 4.2. Конфигурирование сервера
для доступа клиентов РРТР
Чтобы сконфигурировать и активизировать службу RRAS, воспользуйтесь следую- ши ми шагами.
Если установлена ОС Windows 2000, доступ к подключаемому модулю RRAS MMC осуществляется путем выбора пункта меню Start => Programs =» Administrative Tools =*■ Routing and Remote Access (Пуск Cv" Программы С> Администрирование ^ Машрутизация и удаленный доступ).
Правойкнопкимышищелкнитена именисервераи выберитеопциюConfigure and
Enable Routing and Remote Access (Настроить и включить маршрутизацию и удаленный доступ).
В окне Setup Wizard (Мастер установки) щелкните на кнопке <Next> (Далее).
Выберите опцию Manually Configured Server (Сервер, настраиваемый вручную), щелкните на кнопке <Next> (Далее), затем щелкните на кнопке <Finish> (Готово).
Запустите службу.
Правой кнопкой мыши щелкните на опции Ports (Порты), а затем выберите опцию Properties (Свойства).
Если нет необходимости поддерживать протокол L2TP, дважды щелкните на опции L2TP, отмените выбор опции Remote Access Connections (inbound Only) (Подключения удаленного доступа (только входящие)), отмените установку флажка Demand-Dial Routing Connections (Inbound and Outbound) (Подключения по требованию (входящие и исходящие)), затем щелкните на кнопке <ОК>.
Если требуется установить дополнительные порты РРТР, дважды щелкните на опции РРТР, задайте количество необходимых портов (рис. 4.2). После этого дважды щелкните на кнопке <ОК>.
Рис. 4.2. Установка максимального количества портов РРТР
Хотя это и не обязательно, но все же желательно с помощью правой кнопки мыши щелкнуть на имени сервера и перезапустить службу RRAS.
Чтобы изменить заданную по умолчанию настройку пула адресов, щелкните правой кнопкой мыши на имени сервера, затем выберите опцию Properties (Свойства), щелкните на вкладке IP и затем сконфигурируйте необходимую IP-среду.
П. Чтобы отказаться от использования протокола MS-CHAP версии 1, а также определить какие-либо иные настройки безопасности на странице свойств сервера, выберите вкладку Security (Безопасность), щелкните на кнопке Authentication Methods (Методы проверки подлинности) и внесите необходимые изменения (рис. 4.3). Дважды последовательно щелкните на кнопке <ОК>.
Для добавления какого-либо маршрута дважды щелкните на пункте IP Routing (IP- маршрутизация) , затем выберите ОПЦИЮ Static Routing (Статические маршруты). Установите любые подсети, требуемые для вашей среды.
Для добавления статического маршрута щелкните правой кнопки мыши на правой панели и выберите ОПЦИЮ New Static Route (Новый статический маршрут).
Выберите соответствующий интерфейс, а затем введите IP-информацию для вашей среды, как показано на рис. 4.4.
Рис. 4.З. Конфигурирование параметров аутентификацииРис. 4.З. Конфигурирование параметров аутентификацииРис. 4.4. Ввод параметров маршрутизацииРис. 4.4. Ввод параметров маршрутизации
Рис. 4.З. Конфигурирование параметров аутентификации
Рис. 4.З. Конфигурирование параметров аутентификации
Рис. 4.4. Ввод параметров маршрутизации
Рис. 4.4. Ввод параметров маршрутизации
Если в вашей сетевой среде используются другие протоколы маршрутизации, щелкните правой кнопки мыши на опции General (Общие) и в контекстном меню выберите пункт New Routing Protocol (Новый протокол маршрутизации).
Выберите требуемый протокол, затем щелкните на кнопке <ОК>.
Настройте протокол маршрутизации, определив необходимые параметры.
Операционная система Windows 2000 может использоваться в качестве граничного сервера для подключения удаленных офисов. Шаги процедуры 4.3 демонстрируют, каким образом определить туннели на базе протокола РРТР, которые связывают филиалы с центральным офисом.
Групповой комп тот ер
Групповой компьютер представляет собой систему, в которой установлены два или более сетевых интерфейсов. Эти компьютеры часто конфигурируются в качестве маршрутизаторов, соединяющих две отдельные сети.
Процедура 4.3. Конфигурирование связей офисных филиааллоовв сс помощью подключений типа "шлюз-шлюз" протокола РРТР
Установите Windows 2000 на граничном групповом сервере для каждого узла.
Настройте и подключите внешний интерфейс к Internet.
Определите структуру подсети для частных сетей.
Настройте и включите службу RRAS на каждом граничном сервере, как описано ниже.
Если установлена операционная система Windows, для получения доступа к подключаемому модулю RRAS ММС необходимо выбрать команду меню Start => Programs ^ Administrative Tools Ч> Routing and Remote Access (Пуск сф Программы сф Администрирование =& Маршрутизация и удаленный доступ).
Правой кнопкой мыши щелкните на имени сервера и выберите опцию Configure and Enable Routing and Remote Access (Настроить и ВКЛЮЧИТЬ маршрутизацию и удаленный доступ).
После открытия окна RRAS Server Setup Wizard (Мастер установки сервера RRAS) щелкните на кнопке <Next> (Далее).
В появившемся окне можно осуществить выбор среди большого количества опций. Рекомендуется установить сервер и определить все настройки вручную, что позволит получить нужную конфигурацию. Выберите пункт Manually Configured Server (Сервер, настраиваемый вручную) и щелкните на кнопке <Next> (Далее).
Для завершения выполнения мастера установки щелкните на кнопке <Finish> (Готово).
На этом этапе может отобразиться предостережение, говорящее о том, что сервер не может быть добавлен в перечень корректных удаленных серверов в Active Directory (рис. 4.5). Причина заключается в том, что система сконфигурирована с учетом использования Active Directory, но при выполнении мастера подключение не было установлено. Теперь необходимо убедиться в том, что сервер вручную добавлен в группу RRAS and IAS Servers (Серверы RRAS и IAS) в Active Directory.
Рис. 4.5. Необходимо вручную добавить сервер RRAS в группу безопасности Active Directory
Щелкните на кнопке <Yes> (Да) для запуска службы, На этом конфигурирование службы RRAS завершено.
Этот шаг не является обязательным. Большое число сетевых конфигураций требует наличия статичного пула адресов для каждого из отдельных подключений VPN. По умолчанию применяется сервер DHCP, Если сервер DHCP недоступен, Windows
2000 присваивает адрес автосети (169.254.0.0). Можно также сконфигурировать статичный пул адресов для каждой из конфигураций RRAS на узле, как описано ниже.
Правой кнопкой мыши щелкните на имени сервера в подключаемом модуле RRAS, затем выберите опцию Properties (Свойства).
Выберите вкладку IP.
Установите переключатель Static Address Pool (Статический пул адресов) и шелк- ните на кнопке Add (Добавить).
Введите диапазон тех IP-адресов, которые необходимо передать для подключенных клиентов (рис. 4.6). Удостоверьтесь в том, что имеется количество адресов, достаточное для установки всех потенциальных связей. Также проверьте, что данный диапазон адресов соответствует среде маршрутизации и не используется в каком-либо другом месте сети. (Эта мера предосторожности поможет избежать конфликтов IP-адресов.) Дважды щелкните на кнопке <ОК>.
Рис. 4.6. Добавление пула IP-адресов
Определите и организуйте имена узлов с учетом поддержки соглашений о наименовании для объектов подключений. Благодаря этому для каждого конца туннеля можно инициировать связь, как показано на рис. 4.7.
Создайте учетные записи службы VPN. На этом этапе возможен выбор двух ОПЦИЙ. Первая опция позволяет создавать учетные записи в базе данных локального компонентного сервера.
На рабочем столе правой кнопкой мыши щелкните на значке My Computer (Мой компьютер) и в контекстном меню выберите опцию Manage (Управление).
Выберите опцию Local Users and Groups (Локальные пользователи и группы), затем щелкните на пункте Users (Пользователи). Правой кнопкой мыши щелкните на правой панели, затем выберите опцию New User (Новый пользователь).
Создайте учетную запись пользователя, имя которого удовлетворяет соглашениям о наименовании. Эти соглашения определяются при инициализации двунаправлен- ных подключений. Также потребуется в описании идентифицировать тип учетной записи. Удостоверьтесь в том, что пароль защищен в достаточной степени, затем
выберите опцию Password Never Expires (Срок действия пароля не ограничен). Щелкните на кнопке <Create> (Создать).
Правой кнопкой мыши щелкните на только что созданной учетной записи, выберите опцию Properties (Свойства) и щелкните на вкладке Dial-In (Входные звонки) (рис. 4.8). Обратите внимание, что заданной по умолчанию настройкой является Control Access Through Remote Access Policy (Управление на основе политики удаленного доступа). В зависимости от сетевой среды может возникнуть необходимость в выборе другой опции, например, Assign a Static IP Address (Статический IP-адрес пользователя) или Apply Static Routes (Использовать статическую маршрутизацию), Затем щелкните на кнопке <0К>.
Вторая возможность заключается в создании учетных записей с ПОМОЩЬЮ Active Directory.
Выберите команду Start ф Programs Ф Administrative Tools ф Active Directory ф Users and Computers (Пуск => Программы ф Администрирование ф Active Directory - пользователи и компьютеры).
Я настойчиво рекомендую создавать подразделение (OU), которое является специфичным для всех учетных записей службы VPN. Подобный подход позволяет применять настройки Group Policy (Групповая политика), а также организовывать структуру учетных записей. Правой кнопкой мыши щелкните на опции Domain (Домен), выберите пункт New (Создать), затем выберите пункт Organizational Unit (Подразделение). Введите имя нового подразделения, затем щелкните на кнопке <ОК>.
Правой кнопкой мыши щелкните на новом подразделении, затем выполните команду New ф User (Создать ф Пользователь).
Введите данные в соответствующие поля, руководствуясь соглашением о наименовании, приведенном в диаграмме (рис. 4.7). На первом экране введите полное
имя пользователя, а также онное имя, затемна кнопке
(Далее).
Введите достаточно засекреченный пароль и установите флажок Password Never Expires (Срок действия пароля не ограничен). Щелкните на кнопках и <Finish> (Готово).
Правой кнопкой мышина
ко что созданном имени пользователя и выделите опцию Properties (Свойства). Заполните поле описания с целью определения этой учетной записи в виде VPN Service Account (Учетная запись службы VPN).
Выделите вкладку(Входные звон
ки). Если ваш домен функционирует в собственном режиме, обеспечивается доступ к опциям Control Access Through Remote Access Policy (Управление на нове политики удаленногоVerify
Caller-ID(Проверятьидентификатор),
Assign a Static IP Address (Статический IP-
Рис. 4.8. Свойства пользовательского ного доступаРис. 4.8. Свойства пользовательского ного доступаадрес пользователя) и Apply Static Routesстатическую маршрутизацию)
Рис. 4.8. Свойства пользовательского ного доступа
Рис. 4.8. Свойства пользовательского ного доступа
(как показано на рис. 4.9). Если доступ к этим опциямдомен функ
ционирует в смешанном режиме. Если не переключиться в собственный режим, будет невозможно настраивать политику удаленного доступа. (Если потребуется изменить смешанный режим на собственный, воспользуйтесь справочной системой Windows 2000.) Щелкните на кнопке <ОК>.
Также рекомендуется создать группу безопасности, в которую войдут все учетные записи VPN. Правой кнопки мыши щелкните на только что созданном подразделении и выполните команду NewGroup (СоздатьГруппа). Присвойте группе
легко узнаваемое имя. Сохраните заданную по умолчанию настройку для опции Group Scope (Область действия группы), аGlobal (Глобальная) и заданную
по умолчанию настройку опции Group Type (Тип группы), а именно, Security (Группа безопасности). Щелкните на кнопке
Выберите опцию All VPN Service Accounts (Все учетные записиVPN), пра
вой кнопкой мыши щелкните на выделенной области, затем выберите опцию Add Members to Group (Добавить участников в группу).
Выполните скроллинг с целью просмотра опции VPN Service Account (Учетная записьVPN)длясозданнойгруппыбезопасности,какпоказанонарис.4.10.
Выберите эту группу и щелкните на кнопке <ОК>.
Сконфигурируйте политику удаленного доступа, позволяющую активизировать доступ. Политика удаленного доступа должна быть сконфигурирована на обоих концах канала связиВ целях конфигурирования можно применить большое
во доступных опций. Воспользуйтесь следующими шагами, которые описаны ниже.
Выберите команды Start Programs Administrativeand Remote
Access (Пуск Программы Администрированиеи удаленный
доступ). Дважды щелкните на опции Remote Access Policies (Политики удаленного доступа) и затем дважды щелкните на опции Allow Access if Dial-In Permission Is Enabled (Разрешить доступ, если разрешены удаленные подключения).
Рис. 4.9. Настройки пользователя основываются на политике удаленного доступа
Рис. 4.10. Выбор группы безопасности
Обратите внимание, что ОПЦИЯ Deny Remote Access Permission (Отказать в праве удаленного доступа) выбрана по умолчанию. Щелкните на кнопке <Add> (Добавить) для просмотра атрибутов, которые могут быть применены для политики, Двумя важными атрибутами являются Tunnel Type (Тип туннеля), определяю- шин применяемые туннельные протоколы, а также Windows Group (Группа Windows). Последний атрибут отключает или активизирует доступ для группы безопасности Windows. В сетях HappyVPN предоставлены права доступа на постоянной основе. При этом не определяются какие-либо другие атрибуты. При использовании среды подобного типа выберите опцию Grant Remote Access Permission (Предоставить права удаленного доступа) и щелкните на кнопке <ОК>.
Создайте объекты подключения, используя определенные соглашения о наименовании, руководствуясь приведенными ниже указаниями.
• В окне подключаемого модуля Routing and Remote Access (Маршрутизация и удаленный доступ) дважды щелкните на позиции Routing Interfaces (Интерфейсы маршрутизации). Правой кнопкой мыши щелкните на правой панели и выделите опцию New DemandDial Interface (Создать новый интерфейсвызова по требованию), как показано на рис. 4.11.
В окне мастера Demand-Dial Interface Wizard (Мастер интерфейса вызова по требованию) щелкните на кнопке <Next> (Далее). Введите наименование интерфейса, используя в качестве руководства диаграмму, описывающую двунаправленные иниииализирован- ные подключения (рис. 4.12). Щелкните на кнопке <Next> (Далее).
Рис. 4.11. Определениеинтерфейса, выполняющего удаленное подключение по требованиюРис. 4.11. Определениеинтерфейса, выполняющего удаленное подключение по требованию
Рис. 4.11. Определениеинтерфейса, выполняющего удаленное подключение по требованию
Рис. 4.11. Определениеинтерфейса, выполняющего удаленное подключение по требованию
i>«nm*i L"<i UiUv(»«» w».«d
Select rherw* by v*«h IM new nfw lere wl be known
5*cl а IWhefa tot dacwxl <W Wertw* A conww puck» ■ ю м«е HN**
*■ neb*»* w *M le wehtwycemicl
'| NM. ] CW J
Puc. 4.12. Наименование интерфейса, выполняю-щего удаленное подключение по требованию
На следующем экране выберите опцию Connect Using Virtual Private Networking (VPN) (Подключаться с использованием виртуальной частной сети (VPN)). Щелкните на кнопке <Next> (Далее).
Поскольку при развертывании сети VPN используется только протокол РРТР, выберите опцию Point to Point Tunneling Protocol (РРТР) (Протокол туннелирования "точка-точка" (PPTP)). Обратите внимание, что можно выбрать флажок Automatic
Selection (Автоматический выбор) и установить атрибут в полититке удаленного доступа таким образом, что он будет иметь значение РРТР. Щелкните на кнопке <Next> (Далее).
Введите название хоста или IP-адрес для сервера, с которым устанавливается соединение.
Удостоверьтесь,чтоустановленфлажокRouteIPPacketsontheInterface
(Перенаправлять пакеты IP на этот интерфейс). Щелкните на кнопке <Next> (Далее).
На следующем экране введите учетные данные исходящего подключения. Удостоверьтесь в том, что используются имена пользователей, соответствующие диаграмме описания двунаправленных инициализированных подключений (рис. 4.7). Обратите внимание, что при наличии в локальной пользовательской базе данных вашего компонентного сервера ранее созданных учетных записей пользователя в поле Domain (Домен) нужно ввести наименование сервера. Если подобные учетные записи отсутствуют, введите имя домена, где находятся эти учетные записи. Щелкните на кнопке <Next> (Далее), а затем щелкните на кнопке <Finish> (Готово).
Повторите эти шаги для граничного сервера, подключенного к другому концу канала связи.
Добавьте статические маршруты для каждого узла, воспользовавшись объектом подключения.
Дважды щелкните на опциях IP Routing (1Р-маршрутиэация) и Static Routes (Статические маршруты). Правой кнопкой мыши щелкните на правой панели и выберите опцию New Static Route (Создать статический маршрут) (рис. 4.13).
Щелкните на только что созданном интерфейсе. В результате появится диалоговое окно, показанное на рис. 4.14. Укажите параметры целевой сети, введите соответстВуЮЩУЮ маску подсети, проверьте настройки метрики и щелкните на кнопке <ОК>.
Если нужно определить несколько целевых сетей, повторяйте предыдущий шаг до тех пор, пока не охватите все сети, доступные с помощью данного интерфейса.
Повторяйте шаги 10 и 11 до тех пор, пока не будут созданы все связи и маршруты ко всем узлам.
Вручную инициализируйте каждое подключение, воспользовавшись следующими шагами:
удостоверьтесь, что подключение является двунаправленным;
проверьте наличие подключения, выполнив его прозвон.
Несмотря на то, что чаще всего при корпоративном развертывании туннельных клиентов используются инструментальные средства автоматизированной конфигурации, например, Connection Manager (Диспетчер подключений), это все же не обязательно. Желательно, чтобы клиенты сами заботились о выполнении конфигурирования, что повлечет за собой увеличение степени гибкости при выполнении настроек. Как всегда применяемый подход зависит от текущих нужд сетевого проектирования. В процедуре 4.4 описывается типичный процесс, используемый при создании вручную клиентской конфигурации на базе протокола РРТР.
статического маршрутастатического маршрутаPuc, 4.14, Выбор интерфейса, удаленное подключение по требованию для статического маршрутаPuc, 4.14, Выбор интерфейса, удаленное подключение по требованию для статического маршрута
статического маршрута
статического маршрута
Puc, 4.14, Выбор интерфейса, удаленное подключение по требованию для статического маршрута
Puc, 4.14, Выбор интерфейса, удаленное подключение по требованию для статического маршрута
Процедура 4.4. Конфигурирование клиентов для связи
с серверами РРТР
Правой кнопкой мышина значке My Network Placesсетевое окру
жение) и выберите опцию Properties (Свойства).
Дваждына значке Make New Connection (Создание нового подключения), затемщелкнитенакнопке(Далее). ВыберитеопциюConnecttoPrivateNetwork
Through the(Подключение к виртуальной частной сети через Интернет), затем
щелкните на кнопке(Далее).
Введите имя FQDN или IP-адрес туннельного сервера и щелкните на кнопке (Далее).
Укажите, доступно ли подключение VPN для всех профилей или только для текущего профиля. Щелкните на кнопке (Далее).
Если подключение используется совместно (с помощью NAT или ICS), выберите Enable InternetConnection Sharing forthis Connection (Разрешить общий доступ для этого подключения). Для подтверждения выбранных опций щелкните на кнопках(Далее) и (Да).
Выберите для подключения дружественное имя, затем щелкните на кнопке <Finish> (Готово).
Введите имя пользователя и пароль, которыйэто подключение.
Если для среды нужно изменить дополнительные настройки, щелкните на кнопке Properties (Свойства).
Заданная по умолчанию конфигурация предназначена для подключения к стандартному шлюзу данной системы. Если не требуется выбирать стандартные настройки, щелкните на вкладке Networking (Сеть), выберите опцию TCP/IP (Протокол Интернетаи щелкните на кнопке(Свойства).
Щелкните на кнопке(Дополнительно) и отмените выделение опции
Use Default Gateway on Remote Network (Использовать стандартныйв удален
ной сети) (рис. 4.15). Дважды щелкните на кнопке
Для использования протокола РРТР со стороны подключения вместо создания обязательной части политикивыберите тип опции Type of VPN Server I Am
Calling (Типсервера VPN), соответствующий(рис. 4.16). Щелк
ните на кнопке
Для проверки подключения дважды щелкните на новом подключении VPN.
Ailvitncrdll P, IP Settings
GsiwW |0H5 | WHS I 0f*™|
x onlyyou
a
beon theto the
network.
рис.типарис.типаОпцияпо умолчаниюОпцияпо умолчаниюf Ute del** 0*ew« on remote network
рис.типа
рис.типа
Опцияпо умолчанию
Опцияпо умолчанию
Резюме
Несмотря на то, что в Windows 2000 появились новые технологии туннелирования, протокол РРТР будет применяться еше длительное время. Протокол РРТР претерпел значительные изменения с момента появления его первой версии для Windows NT 4, В результате возросла производительность, и была усовершенствована система безопасности. Протокол РРТР никогда не предназначался для обеспечения высокого уровня безопасности, подобно протоколу IPSec. Однако, если сервер сконфигурирован должным образом, безопасность при передаче информации гарантируется при поддержке разнообразных клиентов и сетей.
5
Сертификаты
Одной из целей разработки Windows 2000 явилось радикальное решение проблемы виртуальных частных сетей (VPN), причем самым важным моментом в обеспечении безопасности сети является гарантия безопасных сетевых подключений. Как уже отмечалось ранее, компания Microsoft допустила просчеты при выпуске первых версий протокола туннелирования "точка-точка" (PPTP) и версии 1 протокола аутентификации по методу "вызов-квитирование установления связи" фирмы Microsoft (MS-CHAP vi), и поэтому не решается повторить свой первый "печальный опыт". Одним из результатов подобного положения вешей является шаг к поддержанию стандартных задач со стороны Инженерной группы решения конкретной задачи Internet (IETF —— Internet Engineering Task Force). Данные стандарты были проверены и подтверждены многими представителями данной отрасли, вследствие чего считаются более надежными в применении.
Непосредственным результатом данных исследований является внедрение стандартных технологий сертификатов. Благодаря встроенному стандартному клиенту и серверу сертификатов Windows 2000, обеспечивается средство взаимодействия с другими технологиями сертификатов, что свидетельствует о надежности примененной при разработке этой операционной системы технологии.
Понятие о сервере сертификатов
Операционная система Windows 2000 включает систему служб, протоколов и стандартов, позволяющих в сети устанавливать и управлять инфраструктурой обеспечения безопасности информации, основываясь на технологии общедоступных ключей. Инфраструктура открытого ключа системы Windows 2000 (РК1 — Public Key Infrastructure) зависит от служб сертификатов, используемых для выпуска и управления цифровыми сертификатами. Сервер сертификатовполностью интегрируется с Active Directory и многими другими службами, благодаря чему системы могут использовать данную технологию при распределении и управлении сертификатами.
Назначение сертификатов заключается в предоставлении большего объема сведений, чем обычные имя пользователя и пароль, требуемые при выполнении аутентификации. При их использовании можно назначать права и характеристики, варьирующиеся в зависимости от типов сертификата. Также сертификаты могут применяться для выполнения следующих действий:
обеспечение защищенного доступа к Web-узлу, основываясь на сертификате пользователя;
ссылки на защищенные Web-подключения с установленным протоколом уровня защищенных сокетов (SSL — Secure Sockets Layer);
защищенная почтовая программа, гарантирующая подлинность, сохранность и конфиденциальность почтового сообщения;
присвоение кодового значения программе, гарантирующего подлинность авторства этой программы;
регистрация смарт-карт в домене Windows 2000;
зашифрованная файловая система (EFS — Encrypted File System);
протокол безопасности Internet(IPSec — Internet Protocol Security);
приложения и системы с настраиваемой системой безопасности.
В главе рассматривается инфраструктура PKI, которая является ключевой технологией для распределенных и неоднородных компьютерных сред, требующих наличия за- щишенной системы для обеспечения аутентификации и конфиденциальности данных.
Фирма Microsoft приводит неплохой пример, проводя аналогию между принципом действия данных отношений и системой водительских прав. В деловых кругах обычно доверяют удостоверению личности по водительским правам, поскольку всем хорошо известно, как протекает процесс выдачи прав и связанное с ним проведение удостоверения личности. То же самое происходит и с сертификатом, поскольку центр серти- фикации(СА — Certificate Authority) выполняет ту же самую процедуру, что и фирма BMV: он является поручителем удостоверения личности в мире цифровых технологий.
Шифрование методом симметричного КЛЮЧА — процесс преобразования простого текста в зашифрованный с помощью одного и того же ключа и алгоритма. Примерами технологий, использующих шифрование методом симметричного ключа, могут служить протокол SSL с ключом сеанса (только защищенный канал SSL, а не аутентификация SSL), применяемый для шифрования сетевых данных, а также протокол Kerberos, использующий долговременные общие ключи между клиентами и центром распределения ключей. Алгоритмы симметричных ключей можно классифицировать на две категории: потоковые шифры, выполняющие поразрядное кодирование данных (RC4 — пример группового шифра), и блочные шифры, кодирующие данные по группам разрядов (RC2 — пример блочного шифра, размер блока которого равен 64 разряда).
Шифрование методом открытого ключа представляет технику асимметричного шифрования, при реализации которой два различных ключа выполняют взаимно дополняющие операции на основе одних и тех же алгоритмов. Алгоритмы с открытым ключом являются слишком медлительными при шифровании большого объема данных, поэтому в этих целях используются алгоритмы с асимметричным ключом. Последние алгоритмы относятся к алгоритмам специального назначения, например, алгоритмам RSA, использующимся при обмене ключами и цифровыми подписями. Алгоритм цифровой подписи (DSA — Digital Signature Algorithm), разработанный Федеральным правительством США, используется исключительно для выполнения цифровых подписей. Алгоритм Диффи-Хеллмана (Difiie-Hellman) используется для согласования или передачи ключей между двумя сторонами,
Хеширование представляет процесс ввода переменных (например, сообщение), в реэультате выполнения которого осуществляется вывод данных с фиксированной длиной строк (значение хеш-функции). Существует два уровня шифрования, выполняемого с помощью алгоритмов хеширования. Алгоритмы хеширования MD5, MD2 и MD4 производят 128-разрядные значения. Эти алгоритмы были разработаны лабораторией RSA Laboratories. Защищенный алгоритм хеширования (SHA— Secure Hash Algorithm), разработанный Федеральным правительством США, генерирует 160-разрядные значения. При этом данный алгоритм считается более безопасным, поскольку генерирует более длинные разряды хеширования.
Коды аутентификации сообщений (MAC — Message Authentication Code) имеют сходство с хеш-кодами, за исключением того, что помимо данных для MAC требуется ключ сеанса в качестве вводимой информации, применяемой для вычисления значения хеш-
функции. Для повторного вычисления одного и того кода MAC потребуется ключ сеанса, а также данные, позволяющие установить связь между двумя сторонами. Поэтому обе стороны должны располагать ключом сеанса для создания одного и того же кода MAC.
Цифровые подписи
Благодаря цифровым подписям, обеспечивается механизм удостоверения подлинности переданных данных, а также идентифицируется личность, подписавшая сообщение или данные. Отправитель использует частный ключ в операции цифровой подписи, а получатель использует общедоступный ключ отправителя для удостоверения его подписи.
В силу того, что сами по себе цифровые подписи являются простыми данными, они могут передаваться вместе с защищаемыми ими данными. Они могут вкладываться в документ или присоединяться, например, к почтовому сообщению. Подпись, требующая более медленный алгоритм криптографии с общедоступным ключом, обычно использует значение хеш-функции данных, а затем подписывает данное значение. Это более практично, чем подписывание большого количества документов.
Использование сертификатов является весьма важным при выполнении цифровых подписей, шифровании и связывании ключей, используемых в учетных записях. Сертификаты связывают идентичность ключей субъекта (в основном, значение открытого ключа) с обшей идентичностью. В качестве стандарта сертификатов была выбрана спецификация Х.509. Существуют два типа сертификатов Х.509: версия 1, не поддерживающая расширения, и версия 3, поддерживающая расширения.
Краткая история версии Х.509
Сертификат Х.509 версии 1, появившийся в 1988 год)’, стал широко распространенным, однако по причине низкой степени интеграции приложений наблюдалосъ некоторое ограниченное использование сертификатов.
Сертификат Х.509 версии 2 включал поддержку уникальных идентификаторов субъекта и эмитента, в результате чего обеспечивалось повторное использование имен субъекта и/или эмитента в течение всего времени применения сертификата. Немного позже оказалось, что повторное использование имен небезопасно, вследствие чего для сертификатов не следует использовать уникальные идентификаторы. По этой причине сертификат версии 2 не нашел широкого применения.
Сертификат Х.509 версии 3, представленный в 1996 году, поддерживал расширения, причем любой пользователь мог задать расширение и включить его затем в сертификат, Одним из таких расширений является Key Usage, ограничивающее использование ключей при выполнении определенных задач. Можно установить приоритеты расширений для усиления действия, направленного на использование сертификата. Версия 3 обычно принимается как стандарт, поэтому все текущие приложения, основанные на сертификатах, должны поддерживать данную версию.
Сертификаты Х.509 версии 3
В промежутке между версиями 1 и 3 спецификации Х.509 произошло довольно много изменений, В следующем перечне описываются некоторые характерные признаки версии 3.
Поле Subject (Субъект), в котором указывается конечный объект, содержит имя пользователя, которому был выдан сертификат.
В поле Issuer (Эмитент) идентифицируетсяцентр ЦС по имени.
Серийный номер сертификата — это уникальный номер, выданный ЦС, благодаря которому происходит идентификация сертификата среди всех сертификатов, выпушенных ЦС.
Открытый ключ субъекта фактически является значением общедоступного ключа сертификата данного пользователя, для которого существует соответствующий частный ключ.
Период достоверности определяет время, в течение которого будет действителен сертификат. Значение времени может измеряться в месяцах или годах; обычно сертификаты выдаются на один или два года для объекта или на больший срок ДЛЯ ЦС, в зависимости от используемой длины ключа. Обычно для периода достоверности устанавливаются даты Not-Before (He перед этим) и Not-After (He после этого). Это означает, что какое бы ни было текущее время, оно должно соответствовать датам, указанным в рассматриваемом окне проверки подлинности.
Расширения сертификатов предлагают дополнительную информацию, которая может включать такие сведения, как почтовое имя, частота использования сертификата (например, аутентификация клиента или защищенная почта), политики ЦС или используемые ими действия. И конечно же ЦС подписывает сертификат, в результате чего обеспечивается проверка его подлинности.
Центр сертификации
Центр сертификации (СА — Certificate Authority) — это служба, ответственная за выдачу сертификатов для инфраструктуры с открытым ключом. В роли ЦС может выступать общедоступный коммерческий сервер в Internet, либо какой-либо корпоративный сервер. Сертификаты могут использоваться различными способами, начиная с разрешения выполнять регистрацию с помощью смарт-карт, и завершая шифрованием электронной почты.
В силу того, что центр сертификации является частью структуры Windows 2000, было бы неплохо установить и сконфигурировать, по крайней мере, элементарную структуру сертификатов практически для любой компании.
Центр сертификации выпускает четыре типа сертификатов.
Сертификаты с автоподписыо .Центр сертификации может выпускать сертификаты сам для себя. В данном случае мы имеем дело с сертификатами с автоподписью. Корневой ЦС имеет сертификат с автоподписью, благодаря чему устанавливаются полномочия иерархии.
Подчиненные сертификаты ЦС. Сервер ЦС может выпускать сертификаты для других серверов ЦС, назначая затем их официальными серверами сертификатов в данной иерархии. Это очень важный момент, поскольку во многих проектах эти ЦС будут выдавать сертификаты клиентам.
Сертификаты регистрации авторизации. Центр ЦС может также выдавать сертификаты администраторам. В данном случае речь идет об учетных записях, которые могут выступать в роли другой учетной записи с целью выполнения регистрации или других операций.
Сертификаты для конечных компонентов,например, компьютеров или пользователей. При выдаче сертификатов приложения или операционные системы могут быть сконфигурированы таким образом, что будут использовать модель безопасности, основанную на сертификатах. Это предотвратит попытки пользователей или системы в получении доступа к ресурсам без сертификата, относящегося к доверенной иерархии сертификатов.
Иерархия сертификатов
Иерархия сертификатов ^^* это структура, основанная на доверительных отношениях безопасности. Простая иерархия представляет собой корневой сервер ЦС с подчиненными серверами ЦС, которые выдают сертификаты клиентам. Поскольку иерархия основана на доверительных отношениях, то выданному сертификату доверяют на всех уровнях иерархического дерева. Можно создать множество типов отношении между серверами ЦС, начиная с многочисленных уровней подчиненных серверов ЦС и заканчивая одноранговыми серверами ЦС. Общий поток, установленный между ними, всегда будет иметь форму доверительных отношений.
Доверительные отношения и иерархия ЦС
Чтобы сервер ЦС заслуживал доверие, он должен предлагать некоторые службы или информацию пользователям сертификатов для подтверждения своей идентичности, При этом также потребуется доказать, что пользователь или служба, удостоверяющие себя с помощью данного сертификата, являются именно теми, за кого себя выдают. Если подобное подтверждение отсутствует, клиент не может гарантировать подлинность происхождения сертификата, вследствие чего безопасность не гарантируется.
Сервер ЦС также обеспечивает статус аннулирования сертификата. Если полномочия сертификата отменяются, то ЦС должен проинформировать об этом пользователей данного сертификата. Благодаря этому, в результате отмены полномочий сертификата становится невозможным осуществление доступа с его помощью. Кроме того, ЦС должен указывать политики и практики, руководствуясь терминами, определяющими выпуск сертификатов, а также методику защиты ключей, поддержку аудита и выполнение подобных операций.
Как правило, отношения ЦС основываются на полных иерархиях и/или простых отношениях типа “родитель-потомок". Существует два типа иерархии: корневые иерархии и перекрестные иерархии сертификатов.
Корневые иерархии
Сервер ЦС может быть либо подчиненным, либо корневым, но никогда не выступает в обеих ипостасях одновременно. Корневая иерархия обладает одним очень важным свойством: корневой сервер ЦС может быть автономным. При проектировании среды сертификата важно учитывать систему безопасности с частным ключом ЦС, поскольку при атаке или дискредитации вся иерархия и цепь сертификатов становятся недействительны.
Корневая иерархия устанавливается обычно на трех уровнях.
Корень. Точка доверия иерархии с автоподписью. После определения структуры корневой сервер обычно переходит в автономный режим работы.
Сервер ЦС второго уровня. Этот сервер ЦС определяет организационные политики. Благодаря политикам ЦС, можно отделять корневой сервер, поскольку он может переходить в автономный режим. Также существует возможность выделения применимости сертификатов по признакам географии, политик или какому-либо другому признаку, устанавливаемому корпорацией для определенных политик. Например, можно установить серверы политик ЦС для Северной и Южной Америки, а затем отделить цепи, находящиеся под ними. Можно также установить иерархию с помошью приложения, что, в основном, относится к финансовым приложениям. В некоторых случаях серверы ЦС политик можно сделать автономными или интерактивными в зависимости от их применения; но опять же, это зависит от требований безопасности, выдвигаемых конкретной организацией.
Серверы ЦС, выдающие сертификаты. Этот сервер ЦС отвечает за выдачу сертификатов конечным компонентам. Данный сервер должен функционировать в интерактивном режиме, поскольку ему необходимо обслуживать запросы сертификатов.
Другим преимуществом корневых иерархий является их способность к масштабированию, а также возможность изоляции одного определенного сервера UC. Другими словами, изменения, вносимые в определенный сервер ЦС или используемые им политики, не влияют на всех остальных пользователей.
Перекрестная иерархия сертификатов
В перекрестной иерархии сертификатов серверы ЦС могут быть как корневыми, так и подчиненными. Данная конфигурация не поддерживает автономные корневые каталоги, поскольку ЦС предполагается использовать в роли как корневого каталога, так и подчиненного элемента. Это зависит от инфраструктуры PKI, с помощью которой удостоверяется цепь. Перекрестная иерархия обычно используется для соединения отдельных PKI путем создания перекрестных сертификатов, не прибегая к отношениям явного доверия.
Благодаря использованию перекрестной сертификации, один сервер СА сертифицирует другой, и наоборот: сервер ЦС1 перекрестно сертифицирует сервер ЦС2, а сервер ЦС2 перекрестно сертифицирует сервер ЦС1. Это означает, что ЦС1 является одновременно и корневым в своей собственной иерархии, и подчиненным — в иерархии ЦС2. Проблему в структуре перекрестной сертификации представляет масштабируемость, поскольку структура должна управлять большим количеством отношений и доверительными транзитивными отношениями. Поэтому очень важно проконтролировать фактическое количество отношений (применяя перекрестную сертификацию). Перекрестная сертификация иногда используется в тех случаях, когда компания имеет множество структур сертификатов, которые непросто свести к одной структуре. Причина этого явления заключается в том, что серверы ЦС производятся различными по- ставшиками программного обеспечения. Также может играть роль метод развертывания сертификатов наравне с зависимостями приложений.
Еще одна проблема заключается в доступности перекрестных сертификатов, поскольку они не являются частью естественной цепи. Как правило, сертификаты не содержат информацию, указывающую на применение перекрестных сертификатов. Иерархии перекрестных сертификатов обычно зависят от каталога, не обязательно существующего на глобальном уровне в Internet или в корпоративной сети (если компании физически отделены друг от друга).
Регистрация сертификатов
Регистрация представляет собой процесс, в ходе осуществления которого клиенты получают сертификаты с целью установки безопасных подключения. Возможно, регистрация сертификатов является наиболее сложным моментом, возникающим в процессе использования PKI, Определение и конфигурирование инфраструктуры, бесспорно, является необходимым, однако при выдаче сертификатов клиентам потребуется учитывать все возможные ситуации, возникающие с тысячами индивидуальных потенциальных клиентов.
Существуют два типа регистрации.
Регистрация в интерактивном режиме. В этом случае клиент может составить запрос в интерактивном режиме и незамедлительно получить на него ответ. Сервер ЦС в этом случае должен будет аутентифицировать пользователя, используя определенный тип сетевой аутентификации, например, с помощью пароля.
Регистрация в автономном режиме. В этом случае клиенту может быть выдан сертификат, несмотря на то, что сертификат непосредственно не запрашивается на сервере. Аутентификация администратором ЦС должна производиться от имени клиента, поскольку клиент не может непосредственно запросить сертификат. Ответ сервера на запрос сертификата вернется позднее с помощью одного из множества механизмов типа электронной почты, диска или другого допустимого варианта.
При регистрации сертификата генерируется ключ, хотя пара ключей уже существует. Генерирование ключа может выполняться с помощью клиента, сервера или аппаратного устройства наподобие смарт-карты. При генерировании клиентского ключа частный ключ никогда не отображается в сети и не попадает на сервер. Этап генерирования серверного ключа включает приложение, для которого требуется архивировать ключи шифрования. Эта операция обычно имеет место в том случае, если требуется восстановить ключ, например, при использовании служащими защищенной электронной почты (так называемый метод дуальной пары ключей). При использовании смарт-карты ключ никогда не предъявляется даже хост-компьютеру. Поэтому этот метод считается самым надежным.
Ключи могут быть как двойного, так и одинарного применения. Ключ двойного применения может использоваться в операциях подписи и кодирования. В модели ключа одиночного применения ключ может использоваться только для подписи или только для шифрования. В этом случае не допускается применение ключа двойного назначения. В зависимости от применяемого приложения, могут поддерживаться обе модели. Большинство серверов удостоверений сертификатов, включая Windows 2000, могут издавать сертификаты многоразового использования.
Обычные запросы сертификатов, посылаемые серверу ЦС через сеть, могут выдаваться с помощью Web-приложения или электронной почты. Данные запросы обычно форматируются в стандарте шифрования методом открытого ключа (PKCS #10— Public Key Cryptography Standard). Они поддерживаются не только серверами ЦС компании Microsoft, но и большинством других ПС.
В ответ на запрос сертификата сервер ЦС может либо ответить отказом, либо вернуть сертификат. Сервер ЦС может также вернуть сообщение PKCS #7, что является способом возврата сертификата вместе с родительским сертификатом или цепью сертификатов, имеющей отношение к данному сертификату. Сообщение PKCS #7 подписывается сервером ЦС с целью подтверждения его подлинности и того, что оно пришло с запрашиваемого ЦС.
Проверка подлинности сертификата
Чтобы гарантировать подлинность сертификата, его необходимо проверять. Проверка сертификата требует выполнения многих действий. Клиент должен построить цепь от сертификата конечного компонента (самый нижний уровень) до доверенного самоподписывающегося корневого сертификата. Чтобы построить цепь, клиент сначала пытается найти родительский сертификат. В сертификате клиент использует такую информацию, как имя эмитента, которому необходим родительский сертификат, объектное имя которого соответствует имени эмитента. Помимо того, клиент может использовать поле, называемое Authority Key Identifier (Идентификатор ключа удостоверения), которое явно определяет родительские сертификаты. Если у клиента нет сертификатов в локальном хранилище, он может использовать другую информацию. В данном случае логика построения цепи может распространяться на сеть, в результате чего происходят попытки поиска родительского сертификата, используя определенную сертификатную информацию, например, доступ к информации удостоверения.
В процессе выполнения проверки следует учитывать важный момент, который заключается в том, что в любом участке цепи сертификатов необходимо проверять подписи. Поскольку подписывается каждый сертификат, клиент должен найти открытый ключ, который может использоваться для проверки данного сертификата. Для проверки выданного сертификата также потребуется найти родителей. Затем клиент заимствует общий ключ у родительского сертификата и использует его для проверки подписи у полученного сертификата. Данная процедура используется для всего маршрута, вплоть до корневого сервера. Затем в силу того, что сертификат обладает свойством автоподписи, на корневом уровне клиент для проверки подписи используется открытый ключ в корневом сертификате, поскольку для его проверки не существует более совершенного криптографического метода. Клиент должен доверять корневому сертификату ЦС. Обладания сертификатом еще недостаточно; корневой ЦС должен быть "закрепителем доверия".
Несмотря на то, что сертификат может быть корректным с точки зрения криптографии, он должен быть корректен и по времени. Если какие-либо из расширений сертификата не распознаются логикой верификации, основанной на построении цепи, (например, расширение, обозначаемое как критическое, если оно не является ожидаемым), то сертификат отклоняется. Это может вызвать конфликты при выполнении разных операций, когда различные приложения или центры ЦС размешают собственные расширения в своих сертификатах.
Отзыв сертификатов
Отзыв сертификатов является одной из наиболее важных услуг, обеспечиваемых ЦС, Центр сертификации выдает сертификат на определенный период времени (по умолчанию, на два года), однако сертификат следует отзывать перед окончанием периода действия. Центр сертификации публикует списки отозванных сертификатов (CRL - Certificate Revocation List). Эти списки включают серийные номера сертификатов, которые связаны с серийными номерами, идентифицирующими определенные выданные сертификаты. Если в списке CRL появляется серийный номер, то это означает, что сертификат был аннулирован перед окончанием срока его действия. Списки CRL подписываются и имеют периоды действия, определяющие время их существования. Они могут быть опубликованы согласно настройкам расписания, однако обычно период публикации определяется количеством аннулированных сертификатов, а также тем, каким образом со стороны текущего статуса будет обрабатываться процесс аннулирования.
При использовании приложений, использующих сертификаты, выполняется запрос проверки отзыва. Если при осуществлении этого процесса клиент проверяет сертификат, при этом используется метод шифрования. Благодаря этому, можно удостовериться в отсутствии факта отзыва сертификата. Информация о том, был ли отозван сертификат, может отсылаться клиентскому приложению. В зависимости от используемого приложения, ЦС может дать ответ о невозможности найти список CRL для данного ЦС. В этом случае затруднительно установить, был ли отозван сертификат.
Служба сертификатов Windows 2000 включает также поддержку дополнительного расширения сертификата, Х.509 v3, который поддерживает источник распределения списков отозванных сертификатов. Данное свойство является основой для выполнения автоматической проверки списков CRL.
Модель хранилища сертификатов
Если пользователь или система запрашивают сертификат, фактический сертификат должен обрабатываться определенным устройством, которое выполняет функции по хранению и управлению сертификатами. В данном случае речь идет о хранилище сер-
тификатов. Проверяя сертификаты и устанавливая доверительные отношения по отношению к определенному ЦС, важно знать используемую модель хранилища сертификатов. Операционная система Windows 2000 обычно хранит сертификаты локальным образом в запрашивающей системе. Хранилище сертификатов может включать ряд отличающихся сертификатов из различных центров ЦС. Ниже приводится список, в котором определяются свойства хранилища сертификатов.
Корневые сертификаты с автоподписью с отношениями явного доверия хранятся в корневом хранилище, поскольку никто не может проверить с применением метода шифрования. Важно отметить, что корневое хранилище может быть изменено пользователем или с помощью объектов групповой политики (GPO — Group Policy Objects). Это становится возможным в силу ТОГО, что проверка не может выйти за рамки самоподписывающегося корневого сертификата. Не следует недооценивать степень важности подобных отношений явного доверия. Без них было бы довольно трудно гарантировать безопасность.
Хранилище ЦС — место размещения всех других типов сертификатов с автоподписью, не предполагающих отношений доверия, например, подчиненных или промежуточных сертификатов, используемых в процессе построения цепи.
Персональное хранилище — место размещения пользовательских или компьютерных сертификатов, поскольку в локальной системе существуют соответствующие им частные ключи. Там, где сертификат указывает на смарт-карту, должен быть компонент смарт-карты, либо сертификат может использоваться в чистой программной среде как, например, провайдер хранилища, определенный по умолчанию.
Хранилище доверия используется для сторонних ЦС. Здесь они могут быть сертифицированы без применения отношений явного доверия, используемых в различных целях. Хранилище доверительных отношений содержит список доверия сертификатов для подписанных доверительных отношений. Списки доверия содержат хеши корневых сертификатов, которым доверяет клиент. В зависимости от имеющегося ЦС устанавливаются ограничения на отображаемый хеш, используя который ЦС может выдать сертификаты для выполнения определенных задач.
Хранилища доверия
Если клиенту необходимо доверять ЦС при решении любых задан, можно поместить сертификат в корневом хранилище. Если в этом нет необходимости, создайте настраиваемый список CTL, применяемый в целях дальнейшего ограничения доверия, Создав список CTL, поместите его в хранилище доверия и ограничьте его в рамках одной задачи, например, выполнение подписи электронного сообщения. Таким образом, гарантируется сертификация другого PKL однако компьютерная среда не является открытой для всех типов и назначений сертификатов, выдаваемых ЦС.
Служба каталогов пользователей (User Directory Service) отображает вид сертификатов, которые были опубликованы в Active Directory для пользовательского объекта. Можно публиковать определенные сертификаты в каталоге с тем, чтобы можно было их найти и отправить зашифрованное почтовое сообщение, не прибегая к первоначальной отправке подписанного сообщения и дальнейшему обмену. Благодаря этому, можно просмотреть, что было опубликовано в каталоге на уровне пользователя или уровне компьютера.
Реализация сервера сертификатов
в виртуальных частных сетях
Эта книга создавалась в качестве руководства по применению виртуальных частных сетей. Несмотря на то, что тема сертификатов довольна важна и заслуживает написания отдельной книги, в данном пособии рассматриваются только те вопросы, которые касаются сетей VPN.
Во многих организациях в настоящее время имеется множество служащих или групп служащих, которые управляют безопасностью среды. Для администратора туннелей сотрудничество с администраторами безопасности имеет большое значение. Администраторам необходимо ответить на основной вопрос: имеют ли клиенты, входящие в сеть, сертификаты, выпушенные доверяемым сервером сертификатов?
В системе Windows NT 4.0 было возможно (и очень привычно) разворачивание туннельного сервера вообще без использования сервера сертификатов, Туннельный администратор по-прежнему может разворачивать сервер Windows 2000 (с протоколом РРТР) без применения сервера сертификатов, но при установке протоколов L2TP и IPSec этот сервер весьма пригодится.
Можно выдавать сертификаты для всех типов туннелей. С помощью протокола расширяемой аутентификации (ЕАР — Extensible Authentication Protocol) администратор может распространить указания для всех подключений РРТР на использование пользовательских сертификатов для аутентификации. Это решение может быть реализовано наравне с развертыванием сетей VPN, целиком основанных на выпушенных корпорациями смарт-картах. Для корпорации, заботящейся о своей безопасности, — это отличный способ гарантирования безопасности при получении доступа к корпоративной сети. Это побуждает выдвигать в процессе регистрации физическое требование — использование смарт-карты. В результате, хакер не сможет получить доступ, располагая только именем пользователя и паролем.
Если даже ваша организация не изменяет радикально среду размещения и применения туннельных серверов и клиентов, тем не менее, возможно, что серверу придется и в дальнейшем поддерживать несколько различных опций подключения. Вероятно, в пользовательском плане разворачивания будет установлено направление развития туннельной среды, а также установлена полная поддержка инфраструктуры сертификатов, с тем, чтобы ни одна комбинация "клиент/конфигурация" не смогли начать ее применение. Туннельному серверу, по-прежнему, придется в течение некоторого времени поддерживать традиционную регистрацию имени пользователя и пароля (без применения сертификатов). В большинстве случаев не следует полагать, что возможна реализация переключения по принципу "вырезать-очистить".
Обычно большинство сред сертификатов относятся к одной из двух категорий:
компания не располагает существующей структурой сертификатов (эта ситуация является распространенной среди небольших или средних организаций, и ее довольно легко исправить);
организация имеет существующую инфраструктуру сертификатов, однако требует разворачивания сетей VPN. Эта ситуация является обычной в случае крупных корпораций, и детали процесса разворачивания в данной среде могут быть весьма сложными.
Сервер сертификатов Microsoft в плане развертывания Windows 2000 предлагает, вероятно, наилучший метод развертывания сети VPN. Возможности, присущие серверу сертификатов Microsoft, характерны и для многих других программных продуктов, однако поскольку эта книга не посвящена подробному рассмотрению сертификатов, стоит ознакомиться с тем, каким образом развертываются сертификаты с помощью
сервера сертификатов фирмы Microsoft. Можно интегрировать сертификаты сторонних производителей с целью выдачи машинных сертификатов для развертывания сети VPN, однако каждый сертификат является уникальны^ для определенного программного продукта. Для администратора важно осознать последствия использования любого сертификата, а также гарантировать, что сервер стороннего производителя является полностью совместимым с потребностями среды VPN.
Сертификаты Windows 2000
Как уже говорилось ранее, Windows 2000 использует сертификаты весьма интенсивно. Сертификаты требуются даже при запуске DCPromo. Если не найден сервер сертификатов, то сертификат будет генерироваться случайным образом для процесса. Это справедливо за исключением тех случаев, когда отсутствует практический метод отслеживания данных автоматически генерируемых сертификатов. Поскольку в этом случае применяется подход, ориентированный на использование сертификатов, вообще говоря, неплохо было бы располагать сервером ЦС при развертывании Windows 2000.
Несмотря на то, что обычно организация уже имеет структуру сертификатов, воэмож- но, возникает потребность добавления в иерархию сервера сертификатов Microsoft с целью развертывания доверяемых сертификатов. Эта цель преследовалась при разработке многих программных продуктов. По сути, многие сертификаты могут стыковаться непосредственно с решением Windows 2000 PKI. Это происходит, в основном, благодаря тому, что сервер сертификатов Windows 2000 представляет собой решение, основанное на стандартах.
Если организация не располагает существующей структурой сертификатов, и единственной причиной для установки этой структуры является удовлетворение требований протокола IPSec, попробуйте установить интегрированный сервер сертификатов Microsoft в Active Directory. Эта процедура довольно проста, она обычно предусматривает установку и конфигурирование с целью выполнения автоматического развертывания, но очень часто пользователь об этом просто забывает. Данный подход обычно используется в небольших организациях, которым не требуется владеть сложной структурой сертификатов.
В сетях VPN применение сертификатов возможно с помощью одного из следующих методов:
развертывание машинных сертификатов для IPSec;
развертывание смарт-карт или других решений на основе сертификатов для регистрации в сетях VPN;
установка соответствия между сертификатами и специфическими учетными записями (обычно учетные записи службы).
В следующих разделах представлены инструкции по установке и настройке сервера сертификатов, обеспечивающего развертывание сертификатов в среде сетей VPN.
Процедуры, обеспечивающие использование сертификатов Windows 2000
Следующие процедуры ознакомят пользователя с методами установки сервера сертификатов, применяемого для развертывания сертификатов в сетях VPN. Шаги процедуры 5.1 демонстрируют метод установки и конфигурирования центра сертификации.
Процедура 5.1. Установка и конфигурирование центра сертификации
Для установки и конфигурирования центра сертификации выполняются следующие действия.
Выберите команду StartSettingsControl PanelAdd/Remove Programs
Add/Remove Windows Components (ПускНастройкаПанельУста
новка и удаление программ Добавление и удаление компонентов Windows).
Установите флажок Certificate Services (Службы сертификации). При этом отображается предупреждение о невозможности переименования сервера или изменении его членства в домене, если только вначале не будут удалены эти службы.
ните на кнопках <Yes> (Да) и(Далее) (если установлены службы термина
лов, щелкните на кнопке <Next> еще раз).
Выберите типсертификации, требуемый для данной среды (рис. 5.1). В
проекте HappyVPN используется корневой ЦС предприятия, поскольку среда требует автоматического развертывания машинных сертификатов. При импорте существующих сертификатов установите флажок Advanced Options (Дополнительные возможности); если же требуется установить новый центрвыберите
переключатель Enterprise (Предприятие) и щелкните на кнопке(Далее).
Центры сертификации
Ниже описаны четыре типа ЦС.
Корневой ЦС предприятия. В данном случае речь идет о корневом сервере находящемся на вершине иерархии. Он должен быть установлен ранее, чем будет какой-либо другой сервер, находящийся на нижнем уровне. Несмотря на что этот серверDirectory, он может быть установлен насервере.
Подчиненный ЦС предприятия. В данном случае подразумевается подчиненный ЦС, получающий сертификат с корневого сервера. Обычно в этой роли используется сервер,за выдачу сертификатов клиентам. Поскольку данный центр
сертификации также определяется как корпоративный сервер сертификации, он нуждается в использовании Active
Изолированный корневойэтого сервера аналогичны полномочиям сер
вера корневого ЦС предприятия с тем лишь отличием, что для него не нужна структура Active Directory. Поскольку он не работает непосредственно с Active Directory, то существуют ограничения свойств Active Directory, ориентированные на сертификаты.
подчиненныйсерверподчиненному ЦС предпри
ятия с тем отличием, что он не требует наличия Active Directory.
Заполните поля формы СА Identifying Information (Сведения о центре сертификации) информацией, с помошью которой определяется роль сертификатов (рис. 5.2). Единственное требуемое для заполнения поле — СА Name (Имя ЦС), однако, желательно было бы заполнить форму как можно подробнее, с целью облегчения опознания выданных сертификатов. Щелкните на кнопке(Далее).
Если ваша среда выдвигаеттребования к организации хранения базы
данных сертификатов, следует изменить настройки, заданные по умолчанию. Это обычно имеет значение только в том случае, если конфигурируется громоздкая структура сертификатов и учитываются вопросы производительности при осуществлении дисковых операций ввода/вывода. Если подобные требования отсутствуют, щелкните на кнопке(Далее).
После установки центра сертификации потребуется перезапустить службу Internet Server (Информационный сервер Internet). Затем щелкните на кнопке <ОК>.
Перейдите в меню кнопки Start (Пуск) и выполните команду ProgramsAdministrative
Tools Certification Authority (Программы о АдминистрированиеЦентр сертификации).
Запустите консоль СА ММС. (рис. 5.3).
Рис. 5.1. Четыре типа центров сертификацииРис. 5.1. Четыре типа центров сертификацииРис. 5.2. Ввод сведений о сертификатеРис. 5.2. Ввод сведений о сертификатеРис. 5.3. Запуск центра сертификацииРис. 5.3. Запуск центра сертификации
Рис. 5.1. Четыре типа центров сертификации
Рис. 5.1. Четыре типа центров сертификации
Рис. 5.2. Ввод сведений о сертификате
Рис. 5.2. Ввод сведений о сертификате
Рис. 5.3. Запуск центра сертификации
Рис. 5.3. Запуск центра сертификации
В процедуре 5.2 демонстрируется процесс конфигурирования Active Directory с целью автоматического развертывания сертификатов.
Процедура 5.2. Конфигурирование Active Directory
с целью автоматического развертывания сертификатов
Получите доступ к меню кнопки Start (Пуск) и выберите команду Programs ^ Administrative Tools сф Active Directory Users and Computers (Программы ф Администрирование =3 Active Directory— пользователи и компьютеры).
Обычно при автоматической установке администратор высказывает пожелание, чтобы все компьютеры домена выпускали сертификаты. Благодаря этому достигается более совместимая среда домена. Не обязательно, но вполне возможно конфигурировать только отдельные подразделения. Однако в среде проекта HappyVPN
9191Процедура 5.2. Конфигурирование Active Directory...
91
91
используется политика домена. Правой кнопкой мышина пункте
Domain (Домен) и выберите пункт Properties (Свойства).
Щелкните на вкладке Group Policy (ГрупповаяОбычно должна модифицироваться заданная по умолчаниюDomain Policy (Политика домена), однако
конкретное выполняемое действие зависит от конфигурации групповых политик Если в среде реализуется поддержка множества политик, обратитесь к конфигурации каталога для определенияполитики, которую следует
Выберите политику и щелкните на кнопке <Edit>
Дваждына значках Computer ConfigurationsWindows SettingsSecurity
SettingsPublic Key PoliciesAutomatic Certificate Request Settings (Конфигурации
компьютераНастройки WindowsНастройкиПолитики открытого
ключаНастройки автоматического запроса сертификата). Затем правой кнопкой
мышив правой панели и в контекстном меню выберите команду New
Automatic Certificate Request (Создать Автоматический запрос сертификата) (рис. 5.4).
с. Новый автоматический запрос сертификата
После запуска мастера Automatic Certificate Request Setup Wizard (Мастер настройки автоматического запроса сертификата)на кнопке(Далее). В окне
List of Certificate(Список шаблонов сертификатов) выводятся все шаблоны
По умолчанию определяется шаблон Computer and Domain Controller (Контроллер компьютера и домена), кромевключены также и дополнительные
шаблоны. Сервер сертификатов HappyVPN поддерживает Enrollment Agent (Computer)регистрациии протоколОбычно компьютер
ный сертификат разворачивается автоматически, поскольку предполагается, что если компьютер может добавлять объект компьютера в Active Directory, то для разрешается получение компьютерного сертификата. Выберите объект Computer (Компьютер) и щелкните на кнопке(Далее).
ВыберитеЦС. В данном окне (рис. 5.5) приведен перечень всех
ЦС; проект HappyVPN располагает лишь одним ЦС. Удостоверьтесь в том, что выбран соответствующий ЦС и щелкните на кнопке(Далее).
Для закрытия окна мастера щелкните на кнопке <Finish> (Готово). В списке Automatic Certificate Request (Автоматический запрос сертификата) отображается компьютерный сертификат.
Перейдите в командную строку и введите следующую команду: secedit / refreshpolicy машинная_политика. В результате отобразится следующее сообше- ние: Group policy propagation from the domain has been initiated for this computer. It may take a few minutes for the propagation to complete and thenewpolicytotake effect.PleasecheckApplicationLogforerrors,
if any. (Для данного компьютера началась передача групповых политик из домена. Для завершения передачи и начала действия новой политики может потребоваться несколько минут. Пожалуйста, проверьте Журнал приложений на предмет ошибок, если таковые имеются).
Рис. 5.5. Выбор подходящего центра сертификации
Откройте приложение Event Viewer(npocMOTp событий), затем дважды щелкните на значке Application Log (Журнал приложений) для просмотра сведений об изменениях. После выполненных настроек ЦС начинает выдачу машинных сертификатов для компьютеров, образующих домен. Это происходит в том случае, когда настройки GPO повторно применяются с клиентской стороны.
Некоторым конфигурациям не присуще автоматическое развертывание сертификатов: В таких случаях клиент сможет вручную запросить сертификат с сервера сертификатов, а затем использовать его в дальнейшем. Процедура 5.3 позволяет ознакомиться с процессом запроса сертификата с помощью консоли Microsoft Management Console (ММС).
Процедура 5.3. Запрос сертификата вручную
с помощью консоли ММС
J. Чтобы использовать консоль сертификатов ММС для ручного запроса и установки сертификата, выберите пункт меню Start =* Run (Пуск Ф Выполнить), введите ммс и щелкните на кнопке <ОК>.
Выберите команду Console < Add/Remove Snap in (Консоль ^ Добавить/Удалить оснастку) и щелкните на кнопке <Add> (Добавить).
В правой панели выберите пункт Certificates (Сертификаты) и щелкните на кнопке
<Add>(Добавить).
В окне Certificates (Оснастка диспетчера сертификатов) выберите переключатель Computer Account (Эта оснастка всегда будет управлять сертификатами для учетной записи компьютера). Щелкните на кнопке <Next> (Далее). Выберите переключатель Local Computer (Эта оснастка всегда управляет локальным компьютером (тем, на котором выполняется эта консоль)) и щелкните на кнопке <Finish> (Готово). Щелкните на кнопке <Close> (Закрыть) в списке Add (Добавить), затем щелкните на кнопке <ОК>.
В левой панели щелкните на значке Certificates (Сертификаты), затем щелкните на значке Personal (Личные). После этого отобразится перечень всех сертификатов в локальном персональном хранилище. Если система не выдавала сертификаты (ни в ручном, ни в автоматическом режиме), папка Certificate (Сертификат) отображаться не будет. Правой кнопкой мыши щелкните на правой панели и выберите команду АИ Tasks Ф Request New Certificate (Все задачи с> Запросить новый сертификат) (рис. 5.6).
Puc. 5.6. Запрос нового сертификата
После этого запускается Certificate Request Wizard (Мастер запроса сертификата). Щелкните на кнопке <Next> (Далее).
В списке Certificate Template (Шаблоны сертификатов) содержатся все шаблоны, доступные для запрашивающего компьютера.Выберите значок Computer
(Компьютер) и щелкните на кнопке <Next> (Далее).
Введите легко узнаваемое имя и описание сертификата, затем щелкните на кнопке <Next> (Далее) (рис.5.7).
вВШПШХЗЕЗНВМВВВВВВМВГГ.а^ё 5?л1
tertfkarеf rWtjfy'wrnewHf гнетущ
rou cxigrt^H екы «1C decrNXcn That h#^ you quiddYtiwilft N*dfk
Tyr^v е!ием#у Пам Ml deKrlpttoTifcxtbe mmс.е*уг«м»
Puc. 5, Z Ввод легко узнаваемого имени для сертификата
Щелкните на кнопке <Finish> (Готово). После этого отображается подтверждение, сообщающее о том, что запрос сертификата выполнен успешно.
Если дважды щелкнуть на папке Certificate (Сертификаты), находящейся в папке Personal (Личные), можно увидеть список всех сертификатов, выданных для системы,
Примечание
Если запрос цс был направлен через сервер трансляции сетевого адреса (NAT - Network Address Translation), может возникнуть сбой. Причины сбоя заключаются в использовании облегченного протокола доступа каталогов (LDAP— Lightweight Directory Access Protocol), который не может обеспечивать передачу трафика через серверы NA Т. В этом случае появляется сообщение об ошибке в форме Failed Requests (Сбойные запросы) для сервера сертификатов. В этом случае модуль политики блокирует запрос, поскольку имя запрашивающего пользователя не зарегистрировано, Для устранения этой проблемы можно воспользоваться Web-инструментом, входящим в комплект поставки сервера сертификатов Windows 2000. Этот инструмент применяется при запросе сертификатов либо для экспорта сертификатов вручную из ЦС с последующей их доставкой клиенту. Возможно даже придется перестроить среду NA Т.
Запрос сертификата с помощью Web-инструмента имеет множество преимуществ. Можно развертывать сертификаты на многих клиентах, например, UNIX. Macintosh и других. Благодаря этому, сервер, не являющийся составной частью Active Directory, может запрашивать сертификаты. При использовании подобного инструмента увеличивается степень гибкости, достигаемая при развертывании сертификатов, и также существенно облегчается работа администратора (ему не придется упаковывать вручную и распределять сертификаты). Для использования Web-инструмента по работе с сертификатами выполните действия процедуры 5.4.
Процедура 5.4. Использование Web-инструмента
Откройте окно броузера (Internet Explorer или любой другой стандартный броузер), В поле Address (Адрес) введите http: / / имя^сервера/certsiv, где ИМЯ сервера — имя ЦС.
В появляющемся регистрационном окне введите сведения об учетной записи, которая обладает правами доступа домена на запрос сертификата. Введите данные и щелкните на кнопке <ОК> (рис. 5.8).
Рис. 5.8. Ввод сведений, связанных с паролем, для Web-запроса
Выберите опцию Request a Certificate (Запрос сертификата) и щелкните на кнопке <Next>(Далее).
Выберите опцию Advanced Request (Расширенный запрос) и щелкните на кнопке <Next> (Далее).
Процедура 5.4. Использование Web-инструмент а
Выберите опцию Submit a Certificate Request to This CA Using a Form (Выполнить запрос сертификата для данного ЦС с помощью формы).
Для протокола IPSec доступны два шаблона. Шаблон IPSec Online предназначен для использования системами Windows 2000, имеющими записи в Active Directory. Шаблон IPSec Offline обычно используется совместно с запросом сертификата PKCS #10, предназначенным для систем, отличных от Windows 2000. Тем не менее, этот шаблон можно применять в системе Windows 2000. Для этого выберите шаблон IPSec Offline. Заполните поля Name (Имя) и Email (Адрес электронной почты), затем дважды их про-
верьте в целях гарантирования того, что эти поля подходят для вашей среды. Установите флажок Use Local Machine Store (Использовать хранилище локального компьютера) и щелкните на кнопке Submit (Выполнить) (рис. 5.9).
Рис. 5.9. Использование хранилища локального компьютераРис. 5.9. Использование хранилища локального компьютера
Рис. 5.9. Использование хранилища локального компьютера
Рис. 5.9. Использование хранилища локального компьютера
В результате выполнения указанных выше действий отображается сообщение о выдаче сертификата. Получив такое сообщение, щелкните на кнопке Install This Certificate (Установить сертификат). Затем выводится сообщение о корректной установке сертификата.
Если сервер сертификатов является ЦС предприятия, важно подтвердить, что безопасность установлена корректно перед тем, как Web-службы станут доступными в сети. Подобное подтверждение выполняется при выполнении шагов процедуры 5.5.
Процедура 5.5. Конфигурирование настроек Web-безопасности на ЦС предприятия
Выберите пункты меню Start Ф Programs ^ Administrative Tools ф Internet Service Manager (Пуск со Программы ^ Администрирование ф Диспетчер спужб Интернета). В левой панели щелкните на значках Default Web Site (Веб-узел по умолчанию), CertSrv. Затем правой кнопкой мыши щелкните на значке CertSrv и выберите пункт Properties (Свойства).
Выберите вкладку Directory Security (Безопасность каталога) и щелкните на кнопке <Edit> (Изменить) в разделе Anonymous Access and Authentication Control (Анонимный доступ и проверка подпинности). Отмените все установленные флажки, кроме Integrated Windows Authentication (Встроенная проверка подлинности Windows) (рис. 5.10).
Дважды щелкните на кнопках <ОК>. Закройте окно Internet Service Manager (Диспетчер служб Интернета).
Поскольку все больше компаний размещают важные службы в Internet, вопрос обеспечения безопасности при выполнении ссылок на эти данные становится весьма важным. Изо дня в день все больше компаний требуют большего уровня безопасности, чем обычная регистрация с использованием имени пользователя и пароля. Подход с применением смарт-карт является наиболее удачным и стандартным решением текущих "физических" добавлений, хотя кроме этого разрабатываются биометрические и некоторые другие решения. В Windows 2000 включена поддержка смарт-карт, поэтому корпоративные пользователи постепенно переходят на использование смарт-карт при получении доступа к сетям VPN.
Имейте в виду, что сертификаты, запра-
к«гм* м«*,>!к«гм* м«*,>!Viiud Deedoy | Docuremi Dtwaxy 5wuty | HTTP Heedwt | Cmfur f <*«i | • Алогувоив есвам aid e^fwdewon eontrd» ,C rwt* »-<1пугеиг eccw i »r«l edit fheejfherfcMcn №*№* for Ih* wtuoi£дViiud Deedoy | Docuremi Dtwaxy 5wuty | HTTP Heedwt | Cmfur f <*«i | • Алогувоив есвам aid e^fwdewon eontrd» ,C rwt* »-<1пугеиг eccw i »r«l edit fheejfherfcMcn №*№* for Ih* wtuoi£дРис. 5.10. Установите лишь флажок integrated Windows AuthenticationРис. 5.10. Установите лишь флажок integrated Windows Authenticationшиваемые для смарт-карт, не совпадают с машинными сертификатами, требуемыми протоколом IPSec. Первый тип сертификатов представляет собой пользовательские сертифи-
к«гм* м«*,>!
к«гм* м«*,>!
Viiud Deedoy | Docuremi Dtwaxy 5wuty | HTTP Heedwt | Cmfur f <*«i | • Алогувоив есвам aid e^fwdewon eontrd
» ,C rwt* »-<1пугеиг eccw i »r«l edit fhe
ejfherfcMcn №*№* for Ih* wtuoi£д
Viiud Deedoy | Docuremi Dtwaxy 5wuty | HTTP Heedwt | Cmfur f <*«i | • Алогувоив есвам aid e^fwdewon eontrd
» ,C rwt* »-<1пугеиг eccw i »r«l edit fhe
ejfherfcMcn №*№* for Ih* wtuoi£д
Рис. 5.10. Установите лишь флажок integrated Windows Authentication
Рис. 5.10. Установите лишь флажок integrated Windows Authentication
каты, связанные с отдельным пользователем, который является определенным для смарт- карты. Кроме того, поскольку Windows 2000 включает протокол EAP, становится возможным требование регистрации, основанной на сертификатах (обычно в форме смарт-карт, как для L2TP/lPSec, так и для РРТР).
В процедурах 5.6 и 5.7 описываются действия по назначению сертификата смарт-карте из сервера и клиента (соответственно). Обычно, если запрос выполняется на сервере, администратор сертификатов ответственен за присвоение сертификата; если запрос происходит на клиенте, то за его назначение несет ответственность клиент. То, как организация фактически определяет процесс и политики, зависит от требований самой организации,
Процедура 5.6. Присвоение сертификата смарт-карте
на сервере
Выберите пункты меню Start cS Programs ^ Administrative Tools C> Certification Authority (Пуск C> Программы l=> Администрирование Ф Центр сертификации). В левой панели щелкните на значке Policy Settings (Параметры политики). Затем правой кнопкой мыши щелкните в правой панели и в контекстном меню выберите пункт New e> Certificate to Issue (Создать -^ Выдаваемый сертификат) (рис. 5.11).
Выберите пункт Smart Card Logon (Вход со смарт-картой) и/или Smart Card User (Пользователь со смарт-картой) в зависимости от того, что требуется в конкретной ситуации. (В проекте HappyVPN используется опция входа со смарт-картой.) Щелкните на кнопке <ОК>.
Рис. 5./L Выбор нового выдаваемого сертификата
Процедура 5.7. Присвоение сертификата смарт-карте
для клиента
Установите аппаратную поддержку устройств смарт-карт, допускаемых Windows 2000.
Запустите Internet Explorer и введите адрес http://имя_сервера/certstM, где имя_ серн ера — имя цс. В командной строке укажите сведения об учетной записи, которая имеет права доступа для запроса сертификата.
Выберите опцию Request a Certificate (Запрос сертификата), а затем щелкните на кнопке <Next> (Далее).
Выберите опцию Advanced Request (Расширенный запрос), затем щелкните на кнопке <Next> (Далее).
В раскрывающемся меню Certificate Template (Шаблоны сертификата) выберите шаблон Smart Card Logon (Вход со смарт-картой). Укажите ЦС, провайдер службы шифрования(С5Р — Cryptographic Service Provider), сертификат пользователя, а также регистрируемого пользователя.
Щелкните на кнопке <Submit> (Выполнить).
Соответствие между сертификатами и учетными записями
В проекте Happy VPNNetworks изначально использовались централизованные учетные записи служб каталога, однако при этом проявлялась проблема проверки подлинности учетной записи. Учетную запись следует удостоверять с целью инициализации ссылки, однако и ссылку следует инициализировать для удостоверения учетной записи. Эта проблема не является серьезной при использовании модели единственного домена с контроллерами доменов, расположенными в филиалах офисов. Однако и в данной ситуации граничный сервер сможет удостоверить учетную запись в контроллере локального домена. Эта проблема имеет значение для дочерних доменов, установленных в филиалах офисов.
С целью решения проблемы в проекте HappyVPN произошел отход от централизованного пула учетных записей службы; вместо этого требуемые учетные записи поддерживают-
ся базой данных локальных пользователей удаленного компонентного сервера. Поэтому, даже при отсутствии ссылки компонентный сервер сможет удостоверить учетную запись. Основная проблема подобного подхода заключается в том, что требуются дополнительные усилия на управление учетными записями для распределенных серверов.
Изначально в большей части развертываемых сетей VPN для Windows 2000 использовались сертификаты исключительно для протоколов L2TP/IPSec. В ходе выполнения процедуры 5.8 пользователь ознакомится с процессом основной установки, настройки сервера сертификатов с применением простой конфигурации (предполагается отсутствие структуры сертификатов) и дальнейшего конфигурирования туннелей L2TP/lPSec.
Процедура 5.8. Конфигурирование сети VPN
с помощью L2TP
Для установки и конфигурирования сервера сертификатов выберите пункты меню Start ^ Settings ф Control Panel ^ Add/Remove Programs ^ Add/Remove Windows Components (Пуск С> Настройка => Установка и удаление программ с? Добавление и удаление компонентов Windows).
Установите флажок Certificate Services (Службы сертификации). При этом отображается сообщение о невозможности переименования сервера или изменения его членства в домене, если только сначала не будут удалены службы сертификации. Щелкните на кнопке <Yes> (Да), затем щелкните на кнопке <Nexl> (Далее). (Если установлены службы терминалов, щелкните на кнопке <Next> еше раз).
Выберите требуемый для вашей среды тип сервера сертификатов (рис. 5.1). Проект HappyVPN использует корневой ЦС предприятия, поскольку среда требует автоматического развертывания машинных сертификатов. При импортировании существующих сертификатов установите флажок Advanced Options (Дополнительные возможности); в противном случае выберите Enterprise (Предприятие) и щелкните на кнопке <Next>.
Заполните поля формы СА Identifying Information (Сведения о центре сертификации) информацией, с помощью которой определяется роль сертификатов (рис.5.2). Щелкните на кнопке cNext>.
Подтвердите размещение базы данных сертификатов и определите, требуется ли для текущей среды сетевая папка, применяемая для хранения информации о конфигурации. Щелкните на кнопке <Next>.
Если на сервере выполняется Internet Information Server (Информационный сервер Internet), отображается сообщение, которое гласит, что служба будет остановлена на время установки сервера сертификатов. Щелкните на кнопке <ОК>.
Щелкните на кнопке <Finish> (Готово) для прекращения выполнения мастера Add Windows Component Wizard (Мастер компонентов Windows).
После этого появляется возможность развертывания сертификатов на подключенных системах. В данном случае можно осуществить выбор между развертыванием сертификатов в автоматическом или ручном режиме. Далее подробнее описываются оба варианта. Первый вариант заключается в выборе автоматического развертывания. В проекте HappyVPN Networks был выбран режим автоматического развертывания машинных сертификатов. В этом случае потребуется выполнить указанные ниже действия.
Откройте меню кнопки Start (Пуск) и выберите пункты меню Programs е> Administrative Tools Active Directory Users and Computers (Программы ф Администрирование сф Active Directory — пользователи и компьютеры) В левой панели окна правой кнопкой мыши щелкните на имени домена вашего ЦС и выберите пункт Properties (Свойства).
Щелкните на вкладке Group Policy (Групповая политика), щелкните на значке Default Domain Policy (Политика домена, заданная по умолчанию) и выберите опцию Edit (Изменить). В правой панели дважды щелкните на пункте Computer Configuration (Конфигурация компьютера) и выберите команды Windows Settings Ф Security Settings Ф Public Key Policies ф Automatic Certificate Request Settings (Настройки Windows ф Настройки безопасности Ф Политики открытого ключа ф Настройки автоматического запроса сертификата) (рис. 5.4).
После появления окна Automatic Certificate Request Setup Wizard (Мастер настройки автоматического запроса сертификата) щелкните на кнопке <Next>. В списке Certificate Template (Шаблоны сертификатов) выберите Computer (Компьютер) и щелкните на кнопке «Next*.
Выберите ЦС, который ответственен за выдачу сертификатов для данного домена. Щелкните на кнопках <Next> и <Finish> (Готово).
Закройте окно Group Policy и на экране Group Policy Property (Свойство групповой политики) щелкните на кнопке <ОК>.
Чтобы активизировать политику домена выберите пункт меню Start ф Run (Пуск ^ Выполнить) и введите команду secedit/refreshpolicy политика-Компьютера. Данная команда инициирует распространение политики. Для завершения этого процесса потребуется несколько минут, после чего начнет действовать новая политика. Обратитесь к журналу приложений с целью выявления каких-либо ошибок.
Второй вариант развертывания сертификатов на подключенных системах заключается в том, что данный процесс выполняется вд^чную-Для того чтобы вручную зарегистрировать компьютерные сертификаты, администратор может использовать сертификаты ММС. В этом случае потребуется выполнить описанные далее действия.
Сначала зарегистрируйтесь в системе в качестве администратора. Затем откройте меню кнопки Start (Пуск) и выполните команды Run ф ММС ф Console ф Add/Remove Snap-in (Выполнить ф ММС ф Консоль ф Добавить/удалить оснастку).
На экране Add/Remove Snap-In (Добавить/удалить оснастку) щелкните на кнопке <Add> (Добавить), выберите Certificate Standalone Snap-In (Сертификаты) и щелкните на кнопке <Add>.
В диалоговом окне Certificate Snap-In (Оснастка диспетчера сертификатов) установите переключатель Computer Account (Эта учетная запись всегда будет управлять сертификатами для учетной записи компьютера) и щелкните на кнопке <Next>
Выберите Local Computer (Эта оснастка всегда управляет локальным компьютером (тем на котором выполняется эта консоль)) (если вы зарегистрированы на компьютере, на котором выполняется консоль) и щелкните на кнопке <Finish> (Готово). Затем шелкните на кнопке <Close> (Закрыть) в окне Add Standalone snap-in (Добавить изолированную оснастку) и щелкните на кнопке <0К> в окне Add/Remove Snap-In (Добавить/удалить оснастку). В левой панели дважды шелк- ните на значке Certificates (Сертификаты) для просмотра всех категорий сертификатов, находящихся в локальном компьютере.
Дважды щелкните на папке Personal (Личные) и выполните команду Action ф All Tasks е£> Request New Certificate (Действие => Все задачи => Запросить новый сертификат) (рис. 5.12). После этого открывается окно мастера Certificate Request Wizard (Мастер запроса сертификатов). Затем щелкните на кнопке <Next>.
Выберите шаблон Computer Certificate Template (Шаблон компьютерного сертификата). При установке флажка Advanced Options (Дополнительные параметры) можно будет выбрать провайдера CSP. Установите этот флажок (для просмотра соответствующих опций) и шелкните на кнопке <Next>.
Поскольку в проекте HappyVPN Networks используется заданный по умолчанию провайдер Microsoft RSA Cryptographic Provider, не требуется вносить какие-либо изменения 5.13). на кнопке
7* Console RootXCertikatM (I «. ^1 Ctnn0iXw>\Pe*tnrkJ7* Console RootXCertikatM (I «. ^1 Ctnn0iXw>\Pe*tnrkJAction yew terottn Ф» 7 FVx3Certf tcetei...Action yew terottn Ф» 7 FVx3Certf tcetei...Al TaskAl TaskNew Taskpad View...New Taskpad View...негенегеiRefreshExport tot...iRefreshExport tot...-. pj я r □ a I OtlW* Type-. pj я r □ a I OtlW* TypeFind Certificates..Find Certificates..Request Мен- Certificate-Request Мен- Certificate-ri^ ".ri^ "..-Wd.-WdH*H*eeЗапрос нового сертификатаЗапрос нового сертификата
7* Console RootXCertikatM (I «. ^1 Ctnn0iXw>\Pe*tnrkJ
7* Console RootXCertikatM (I «. ^1 Ctnn0iXw>\Pe*tnrkJ
Action yew terottn Ф» 7 FVx3Certf tcetei...
Action yew terottn Ф» 7 FVx3Certf tcetei...
Al Task
Al Task
New Taskpad View...
New Taskpad View...
неге
неге
iRefresh
Export tot...
iRefresh
Export tot...
-. pj я r □ a I OtlW* Type
-. pj я r □ a I OtlW* Type
Find Certificates..
Find Certificates..
Request Мен- Certificate-
Request Мен- Certificate-
ri^ ".
ri^ ".
.-Wd
.-Wd
H*
H*
e
e
Запрос нового сертификата
Запрос нового сертификата
Puc.службы шифрования
Если установлено несколько центровзапрос направляется другому серверу сертификатов. Удостоверьтесь в корректности ЦС ина
кнопке
Введите легко распознаваемое имя и описание сертификата. Щелкните на кнопкезатем щелкните на кнопке(Готово).
Подтвердите, что мастер успешно выполнил запрос сертификата,
Подтвердите получение сертификата, найдя его в окне подключаемого модуля Certificates (Сертификаты) (рис. 5.14).
Удостоверьтесь, что в иепи между источником и конечным пунктом отсутствуют серверы NAT, Лучше всего выполнить это, проанализировав сетевое окружение.
Вручную активизируйте каждое подключение.
Удостоверьтесь в том, что подключение является двунаправленным. Важно удостовериться в том, что оба направления настроены на использование одного и того же протокола — L2TP. Проще всего это сделать, запустив сеанс терминала на противоположном конце туннеля. При этом производится наблюдение за процессом подключения, устанавливаемого с обеих сторон. Если уже установлены фильтры ограничения всего трафика (за исключением трафика туннеля), было бы проще, если бы кто-то контролировал этот процесс со стороны.
Проверьте наличие подключения с помощью эхо-тестирования.
Рис. J. 14. Просмотр локального сертификата
Первоначально при развертывании сетей в рамках проекта HappyVPN использовались учетные записи службы сетей VPN, однако смарт-карты обеспечивают преимущества благодаря установке безопасности сертификатов. Дополнительная безопасность связана с тем, что для получения доступа к серверу придется предпринимать дополнительные действия. Тем не менее, при использовании смарт-карт не обеспечивается хорошее решение для филиалов офисов, поскольку в этом случае приходится вводить пин-код.
Существуют и другие способы использования регистрации, основанной на сертификатах. Процедура 5.9 демонстрирует процесс конфигурирования филиалов, в результате чего становится возможным применение сертификатов в процессе регистрации.
Процедура 5.9. Настройка процесса аутентификации, основанного на сертификатах
Удостоверьтесь в том, что на маршрутизаторе установлен машинный сертификат.
Чтобы поддерживать подключения филиалов (маршрутизатор-маршрутизатор), ЦС должен быть способным выдавать сертификаты маршрутизаторов (автономный запрос).
Дважды щелкните на ЦС и выберите Policy Settings (Параметры политики). Затем правой кнопкой мыши щелкните в правой панели и выберите команду New ^ Certificate to Issue (Создать ф Выдаваемый сертификат).
Просмотрите перечень шаблонов сертификатов и выберите Router (Offline Request) (Маршрутизатор (Автономный запрос)). Щелкните на кнопке <ОК>.
Удостоверьтесь в том, что домен сконфигурирован с целью автоматического развертывания сертификатов или в том, что участвующим компьютерам вручную выданы сертификаты.
Удостоверьтесь в том, что ЦС сконфигурирован для Web-регистрации.
Создайте учетные записи пользователя в домене, который будет использоваться маршрутизаторами при установке удаленного подключения. Учетные записи службыдля проектаNetworks находятся вподразделении. В
данном примере аутентификации сертификата в роли филиала выступает а центральным маршрутизатором является KnoxRoute.
Откройте Internet Explorer и укажите IP-адрес или компьютерное имя ЦС. В конец адреса URL добавьтеЗатем выберите опцию Request a
(Запросить сертификат) ина кнопке
Выберите опцию Advanced Request (Дополнительный запрос) и щелкните на кнопке <Next>.
Щелкните на кнопке Submit a Certificate Request to This CA Using a Form (Передать запрос сертификата данному ЦС с помощью формы). Затемна кнопке
Заполните поле Advanced Certificate Request (Запрос дополнительного сертификата). В поле со списком Certificate Template (Шаблон сертификата) укажите Router (Offline Request) (Маршрутизатор (Автономныйкак показано на рис. 5.15. В поле
Name (Имя) введите имя пользователя, используемое вызывающим маршрутизатором, В разделе Key Options (Параметры ключа) укажите опцию Mark Keys as Exportable and Use Local Machine Store (Пометить ключи как экспортируемые и использовать хранили- щелокальногокомпьютера).Щелкнитенакнопке<Submit>(Выполнить).
Выборшаблона
На странице Certificate Issue Page (Страницасертификатов) щелкните на
кнопкеThis(Установить сертификат). После завершения
ки сертификата закройте окно Explorer.
Откройте окно консоли ММС Local Certificate (Локальный сертификат) и щелкните на пунктах меню Personal ^ Certificates (Личные ■^ Сертификаты). Проверьте, был ли найден выданный сертификат пользователя. Затем правой кнопкой мыши шелкните на значке Certificate и выберите команду All Tasks^ Export (Все задачи ф Экспорт).
В результате выполнения этих действий запускается мастер Certificate Export Wizard (Мастер экспорта сертификатов). Щелкните на кнопке <Next>, отметьте опции No (Нет) и Do Not Export the Private Key (He экспортировать закрытый ключ). Щелкните на кнопке <Next>.
Выберите опиию DER Encoded Binary X.509 (рис. 5.16) и шелкните на кнопке <Next>.
txport Г* for mN
Ce-tihcatst cei be «^portedл * v«Hy rf flefixmete
Seed the fere* *эи мн to umi
« tjtx wrsdHty*. A wii q^
Г U>4A wxooeCX.Xli^XlX)
^ Cnvttw te MeiS-W Syntax Stinriord - PK3 #7 Cert^caws (. P7B)
Г
<|*i |I|
Puc. 5.16. Выбор корректного формата для файла экспорта
Введите имя файла сертификата, который будет экспортироваться. Щелкните на кнопках <Next> и <Finish>.
Подтвердите сообщение мастера Export Wizard (Мастер экпорта) об успешной регистрации процесса экспорта.
Организованное хрипение сертификатов
При выходе из окна мастера Export Wizard система создает новый файл сертификата. Обратите внимание, что сертификат также остается в хранилище сертификатов того компьютера, на котором был создан. Подтвердив создание фаф^а сертификата, можно удалить сертификат из хранилища во избежание возможной путаницы.
Для сопоставления сертификата соответствующему пользователю откройте окно консоли Active Directory— Users and Computers (Active Directory— пользователи и компьютеры). В меню View (Вид) выберите пункт Advanced Features (Дополнительные функции). В левой панели щелкните на папке Users (Пользователи) или соответствующей папке Organizational Unit (Подразделение), где хранятся учетные записи службы VPN.
Правой кнопкой мыши щелкните на учетной записи пользователя, для которой предназначен сертификат, и выберите опцию Name Mappings (Отображения имен) (рис. 5.17).
Выберите вкладку Х.509 Certificates (Сертификаты Х.509). Щелкните на кнопке Add, найдите файл сертификата и шелкните на кнопке <0реп> (Открыть).
В окне Add Certificate (Добавить сертификат) шелкните на кнопке <ОК>. В диалоговом окне Security Identify Mapping (Отображение идентификации безопасности) щелкните на кнопке <ОК>.
Рис. 5. 1 7. Установка соответствия с учетной записью
Для экспорта сертификата маршрутизатора (автономный запрос) удаленной учетной записи в файл . PFX вернитесь в консоль ммс Certificates (Сертификаты). Правой кнопкой мыши щелкните на том же сертификате, выберите команду АП Tasks ф Export (Все задачи ф Экпорт). В результате снова запускается мастер Export Wizard (Мастер экспорта).
Щелкните на кнопке <Next>. Затем выберите опцию Yes, Export the Private Key (Да, Экспортировать закрытый ключ). Щелкните на кнопке Next. Установите флажок Delete the Private Key if the export is successful (Удалить закрытый -ключ, если экспорт был успешен). Отметьте флажок Include All Certificates in the Certification Path if v Possible (Включить все сертификаты в путь сертификации, если возможно) (рис. '5.18). Щелкните на кнопке cNext>.
Export f fc Format CwtfkXW cenbe exported h » variety g/ № t Croats,
falsethefOTiMyouivwtto ft ...i« ■•.,
Г*.
Г-- .
^ E»W<Ni WornettanEndvnge • RX1 #11 (.*•) P M/k' ei cwtftcM* in ike cwtAcMw fiihTye»<A>|
F Ел«Ы« strong protection <r*r>« И1Л, НТ 1.0 SR ^ ^e} I* ЙЙ» the prrvete te# 'the export № succtssM
Puc. 5.18. Выбор формата файла экспорта
Введите и подтвердите пароль ДЛЯ частного ключа. Щелкните на кнопке <Next>.
Укажите имя файла с расширением . PFX и щелкните на кнопке <Next> (Далее). Щелкните на кнопке <Finish>.
Подтвердите успешное завершение выполнения мастера Certificate Export Wizard.
Используя учетную запись Knox Route. получите доступ к Web-регистрации сервера сертификатов (рис. 5.19). Выберите опиито Request a Certificate (Запрос сертификата) и щелкните на кнопке <Next>.
^Dtr<к9 Irrt-ner
Put. 5.19. Запрос нового сертификата с помощью Web-формы
Щелкните на кнопке Advanced Request (Дополнительный запрос) и шелкните на кнопке <Nexl>.
Щелкните на кнопке <Submit a Certificate Request to the CA Using a Form> (Выполнить запрос сертификата ЦС с помощью формы). Щелкните на кнопке <Next> (Далее).
В разделе Certificate Template (Шаблон сертификата) выберите пункт Router (Offline Request) (Маршрутизатор (Автономный запрос)) (рис. 5.15). В поле Name (Имя) введите имя учетной записи службы VPN. В разделе Key Options (Параметры ключа) выберите опцию Mark Keys As Exportable (Пометить ключи как экспортируемые) и установите флажок Use Local Machine Store (Использовать хранилище локального компьютера). Щелкните на кнопке Submit (Выполнить).
Щелкните на кнопке <lnstall the Certificate> (Установить сертификат). Подтвердите успешную установку нового сертификата.
Выполните экспорт сертификата. Перейдите в консоль ММС сертификата, дважды щелкните на пункте Certificates (Local Computer) (Сертификаты (Локальный компьютер)) и выберите команду Personal о Certificates (ЛичныеСертификаты). Затем
правой кнопкой мыши щелкните на вновь созданном сертификате и выберите команду All Tasks <- Export (Все задачи сА Экспорт).
В окне мастера Certificate Export Wizard (Мастер экспорта сертификатов) щелкните на кнопке <Next> Выберите опцию No, Do Not Export the Private Key (Нет, не экспортировать закрытый ключ) и шелкните на кнопке <Next>.
Выберите опцию DER Encoded Binary Х.509 (рис. 5.16). Щелкните на кнопке <Next> (Далее).
Введите путь и имя для файла -CER Щелкните на кнопке <Next>.
Щелкните на кнопке <Finish> и подтвердите успешный экспорт.
Вернитесь в Active Directory. Поместите учетную запись службы для центрального маршрутизатора, правой кнопкой мыши щелкните на опции Account (Учетная запись), выберите пункт Name Mappings (Отображения имен) (рис.5.17).
В диалоговом окне Security Identity Mapping (Отображение идентичности безопасности) выберите вкладку Х.509 Certificates (Сертификаты Х.509) и щелкните на кнопке <Add> (рис. 5.20). Выберите соответствующий файл . CER и щелкните на кнопке <Ореп> (Открыть).
Щелкните на кнопке <ОК> в окне Add Certificate (Добавить сертификат), после чего щелкните на кнопке <ок> в диалоговом окне Security Identity Mapping (Отображение идентичности безопасности) (рис. 5.21).
Рис. 5.2ft Установка сертификатаРис. 5.2ft Установка сертификатаРис. 5.2/. Вид отображенного сертификатаРис. 5.2/. Вид отображенного сертификата
Рис. 5.2ft Установка сертификата
Рис. 5.2ft Установка сертификата
Рис. 5.2/. Вид отображенного сертификата
Рис. 5.2/. Вид отображенного сертификата
Перейдите в консоль ММС сертификатов. Правой кнопкой мыши щелкните на соответствующем сертификате и выберите команду All Tasks ^ Export (Все задачи ф Экспорт).
В окне мастера Certificate Export Wizard (Мастер экспорта сертификатов) щелкните на кнопке <Next>. Выберите опцию Yes, Export the Private Key (Да, экспортировать закрытый ключ). Установите флажок Include All Certificates in the Certification Path if Possible (Включить все сертификаты в путь сертификации, если возможно). Затем установите флажок Delete the Private Key if the Export is Successful (Удалить закрытый I ключ при успешном экспорте) и щелкните на кнопке <Next>.
Введите пароль и его подтверждение. Щелкните на кнопке <Next>.
Определите путь и имя для файла , PFX , затем щелкните на кнопке <Next>.
Щелкните на кнопке <Finish> и подтвердите успешное завершение операции экспорта.
Конфигурирование доверия филиала по отношению к развернутым сертификатам
Для конфигурирования доверия филиала по отношению к развернутому сертификату выполните следующие действия.
Отправьте администратору филиала файл удаленной учетной записи сертификата пользователя.
В офисной системе филиала сконфигурируйте маршрутизаторы для установления отношений доверия сертификатов для значений регистрации. Для этого измените следующий ключ системного реестра, присвоив ему значение 1:
НКЕ Y_LOCAL_MACHINE\System\CurrentControlSet\Services\RasManXPPP\EAP\13\ IgnoreRevocationOffline
Резюме
При использовании новых решений, заключающихся в развертывании сетей VPN в среде Windows 2000, оказалось, что основные проблемы связаны с выдвигаемыми требованиями относительно размещения структуры сертификата с целью использования протокола L2TP/IPSec. На основании сведений, представленных в данной главе, можно сделать вывод, что применение сервера сертификатов является весьма несложным. При этом можно воспользоваться рядом преимуществ, обеспечиваемых операционной системой Windows 2000. В больших организациях важно, чтобы все запланированные действия, выполняемые туннельным администратором, соотносились с действиями администратора сертификатов. Благодаря этому, можно гарантировать, что их действия будут скоординированы.
6
Протокол безопасности Internet (IPSec)
Одной из основных задач при работе в Internet является создание открытого набора протоколов, которые обеспечивали бы взаимодействие различных систем. С течением времени успехи, достигнутые в деле поддержки открытых и простых коммуникаций между системами, привели к экспоненциальному росту сети Internet. Однако этот процесс до сих пор таит в себе ряд проблем, особенно в сфере обеспечения безопасности.
Глобальный рынок с течением времени все чаше начинает использовать преимущества, предлагаемые Internet. Многие современные компании связывают успех своего бизнеса с работой в Internet. С помощью этой глобальной сети распространяется информация, имеющая огромное значение, особенно в таких сферах человеческой деятельности как медицина, военное дело, официальные сообщения на уровне правительств и широкий спектр иной информации. Путем фальсификации данных можно расстроить весь бизнес, а зачастую, и создать угрозу жизни людей.
Поскольку применение Internet сулит большие преимущества, весьма важно найти надежные средства, обеспечивающие безопасность передаваемых данных. Наряду с тем, что решение может быть довольно специфично, при реализации системы безопасности следует учитывать следующие основные факторы:
не следует переписывать приложения. Если допустить вероятность переписывания приложений, то большие затраты при реализации этого решения приведут к тому, что внедрение подобных приложений во многих средах станет затруднительным;
не стоит применять специальное аппаратное обеспечение;
не требуется повторно разрабатывать проект сети, поскольку защищенные данные должны передаваться в той же самой сети, что и незащищенные данные;
допускается минимальное снижение производительности системы и сети;
технология должна быть гибкой и настраиваемой с учетом применения различных сред;
затраты на администрирование не должны быть чрезмерно велики.
Коммуникации, выполняемые с помощью протокола IPSec
Еще до того, как в среде Windows 2000 будет установлен протокол безопасности (IPSec — Internet Protocol Security), следует ясно представлять основополагающие моменты, на которых зиждется применяемое решение по шифрованию.
Протокол IPSec использует несколько стандартных технологий шифрования. Все они определены в документах RFC I825, а также в соответствующих описаниях версий и в прочей документации. Несмотря на то, что протокол IPSec изначально предназначался для работы со стандартом IPv6, вследствие необходимости в реализации решения по шифрованию, этот протокол был реализован уже при использовании стандарта IPv4.
Протокол IPSec использует следующие технологии:
технология обмена ключей по методу Диффи-Хеллмана (Diffie-Hellman), используемая для распространения ключей между системами в общедоступной сети;
шифрование по методу открытого ключа, используемое для реализации обмена ключами по методу Диффи-Хелмана (Diffie-Hellman), в результате чего гарантируется договоренность между обеими сторонами;
поддержка стандартных хеш-алгоритмов, использующих ключи при аутентифи- капни пакетов;
поддержка нескольких алгоритмов шифрования, применяемых при выполнении задач по шифрованию;
поддержка цифровых сертификатов Х.509, используемых для удостоверения открытых ключей.
В результате применения указанных выше технологий был разработан протокол IPSec. Этот протокол представляет собой стандарт, разработка которого инженерной группой по решению конкретной задачи Internet (IETF Internet Engineering Task Force) велась на протяжении двух лет. Работа по определению протокола IPSec для использования в качестве промышленного стандарта началась в декабре 1998 года, а завершилась реализацией этого протокола в составе операционной системы Windows 2000.
В настоящее время при реализации протокола IPSec применяются два режима (транспортный и туннельный). Наряду с этим существует несколько разновидностей протокола IPSec. Среди них: аутентификация заголовка (АН — Authentication Header), инкапсуляция полезной нагрузки системы безопасности (ESP — Encapsulating Security Payload) и обмен ключей Internet Key Exchange (IKE — Internet Key Exchange). Как правило, транспортный режим применяется для выполнения шифрования в сети LAN/WAN, а туннельный режим чаше всего используется при шифровании "шлюз- шлюз". Эти протоколы можно использовать в любых режимах, а протокол АН поддерживает проверку исходных данных для получаемых пакетов, целостность данных, а также предотвращение автоматического ответа. Протокол ESP выполняет те же самые функции, что и протокол АН, но дополнительно к этому реализует шифрование передаваемых данных. Протокол IKE отвечает за обмен ключами, что позволяет системам согласовывать ключ, который необходим для шифрования и декодирования.
Транспортный режим
Безопасность при передаче пакета, реализуемая на пути от первичного источника к конечному месту назначения, обычно использует транспортный режим, реализуемый с помощью протокола IPSec. Целью применения транспортного режима IPSec является обеспечение полномасштабной зашиты "точка — точка" (от источника — к месту назначения). Протоколы АН и ESP обновляют транспортный заголовок путем пере-
хвата пакетов, перемешающихся из транспортного на сетевой уровень. Транспортный режим характеризуется двумя особенностями. Этот режим не связан с типом физического подключения, и маршрутизаторы при передаче данных не изменяют ничего, за исключением заголовка на сетевом уровне.
Туннельный режим
Как упоминалось ранее, компания Microsoft внедрила стандарт протокола IPSec, реализованный IETF, при разработке Windows 2000. Это означает, что реализация протокола IPSec в Windows 2000 осуществляется в двух режимах: транспортном и туннельном. Туннельный режим IPSec довольно сильно отличается от туннеля L2TP/lPSec, реализованного на базе протокола РРР, который использует в задачах по шифрованию транспортный режим протокола IPSec. Подробное рассмотрение протокола L2TP/IPSec производится в главе 7.
В туннельном режиме драйвер IPSec создает новый заголовок Internet Protocol (IP) вне исходного пакета и размещает внутри весь исходный пакет, используя его в качестве содержимого для нового IP-заголовка (рис. 6.1).
Несмотря на то, что Windows 2000 реализует туннельный режим протокола IPSec, на самом деле он не предназначается для реализации таких возможностей, как клиентский доступ. Причиной реализации подобного режима являлась необходимость обеспечения стандарта при подключениях "шлюз-шлюз" для тех устройств, которые не могут использовать протокол L2TP/IPSec. Процедура конфигурирования туннеля IPSec довольно сложна, а маршрутизация, реализованная для туннелей, может быть весьма необычной. Также следует учитывать то, что места назначения должны иметь статичные IP-адреса, поскольку политика протокола IPSec не допускает, чтобы в качестве точки назначения туннеля IPSec выступало название хоста.
Исходный пакет
.за гол.за голЗалмТСР I ДанныеЗалмТСР I Данные
.за гол
.за гол
ЗалмТСР I Данные
ЗалмТСР I Данные
Инкапсулированный пакет
Новый засол IP | Засол ESPЗагол TCP |Данный Завершитель ESP Аутентификация ESP
Зашифрованный
-——■в
Интегрированное хеш-покрытие
Детали аутеит ESPКлючевой хеш IДетали аутеит ESPКлючевой хеш IДетали загол ESP
Детали аутеит ESP
Ключевой хеш I
Детали аутеит ESP
Ключевой хеш I
Индекс ПарамПослед #последов НачВепор
Детали завершителя ESP
Заполнение ДлинаЗап I СледЗагол
Рис. 6.1. Детали пакета IPSec ESP, передаваемого в туннельном режиме
Драйвер IPSec и стек протоколов TCP/IP
Протокол IPSec реализован, в основном, на IP-уровне стека протоколов TCP/IP. Драйвер IPSec находится посередине IP-уровня, непосредственно под фильтром IP- пакетов и над уровнем повторной сборки фрагментированных пакетов. Если активизирована политика IPSec, протокол IPSec обрабатывает все IP-пакеты, поступающие в компьютер или передаваемые этим компьютером.
Приложения находятся над этими уровнями поверх Winsock и непосредственно под уровнем QoS. Приложение открывает подключение Winsock, в результате чего система безопасности IPSec становится "прозрачной".
Драйвер IPSec является драйвером режима ядра, разработанным компанией Microsoft. Этот драйвер обрабатывает все входящие и исходящие IP-пакеты. В данном случае применяются IP-фильтры IPSec (но не фильтры RRAS) с целью определения того, следует ли применить политику IPSec. Спецификация фильтра IP включает следующие моменты:
идентификатор сетевого протокола;
тип фильтра;
исходный IP-адрес;
исходную IP-маску подсети;
исходный порт;
конечный IP-адрес;
IP-маска конечной подсети;
порт назначения.
Если IP-заголовок и транспортный заголовок пакета совпадают с этими параметрами, требуется ассоциация безопасности (security association, SA). С помощью этой ассоциации IP-пакет преобразуется в форму протокола IPSec, которая определяется подобным образом. Если между источником и назначением не установлена ассоциация безопасности (SA), драйвер использует IKE для его установления. Пакет ожидает, пока завершится этот процесс, а затем выполняет пересылку пакета. Если SA не может быть установлено, пакет отменяется.
При получении пакета проверяется его соответствие с помошью драйвера IPSec. При этом применяются фильтры IPSec. Существует три типа фильтров: блокирую- ший, пропускающий и обычный. Применение блокирующего фильтра приводит к тому, что драйвер отменяет пересылку пакета. Пропускающий фильтр способствует тому, что драйвер обеспечивает получение и отсылку пакета. Использование обычного фильтра приводит к тому, что драйвер требует вмешательства ассоциации безопасности, а обработка пакета производится в соответствии со свойствами этой ассоциации. Исключениями из этого правила являются широковещательные рассылки, многоабонентские рассылки, а также протоколы RSVP, IKE и Kerberos.
Отправка и получение пакетов реализуется с помощью стека протоколов TCP/IP (рис. 6,2). При этом данные передаются непосредственно через уровень IPSec по направлению к уровню NDIS. Интерфейс NDIS 5.0 обеспечивает возможность разгрузки, благодаря чему обеспечивается аппаратное ускорение процесса шифрования IPSec, Кроме того, существуют так называемые платы разгрузки, которые выполняют важную функцию отправки данных для сегментов TCP. Если через подключение TCP пропускается большой объем данных, стек выполняет одномоментную опережающую отсылку данных, а платы разгрузки разбивают сегменты TCP, образуя небольшие IP- пакеты (в противовес функциям стека протоколов TCP/IP).
Платы разгрузки
В роли плат разгрузки обычно используются быстродействующие сетевые адаптеры Ethernet, оборудованные микросхемой шифрования. Операционная система определяет наличие плат, могущих выполнять задачи шифрования/декодирования в рамках прото - кола IPSec с помощью драйвера, который связывается с этой платой. Весь объем сетевого трафика, проходящего через компьютер, направляется через микросхему сетевого адаптера, обеспечивающую выполнение процесса шифрования/декодирования. В результате существенно уменьшается нагрузка на центральный процессор сервера, поскольку выполнение задач шифрования приводит к потреблению значительных вычие-
лительных ресурсов. Важно отметить, что возможности плат разгрузки ограничены количеством обрабатываемых ими потоков IPSec. Нужно четко представлять все эти моменты еще до приобретения какого-либо аппаратного обеспечения.
Winsock
Провайдер служб QoS
Стек протоколов TCP/IPСтек протоколов TCP/IPTCPUDPICMPRawTCPUDPICMPRaw
Стек протоколов TCP/IP
Стек протоколов TCP/IP
TCP
UDP
ICMP
Raw
TCP
UDP
ICMP
Raw
APi перехвата с помощью • брандмауэраAPi перехвата с помощью • брандмауэраФильтр IP-пакетовФильтр IP-пакетов
APi перехвата с помощью • брандмауэра
APi перехвата с помощью • брандмауэра
Фильтр IP-пакетов
Фильтр IP-пакетов
IPSec
Фрагментация/ловторная сборка
Минипорты, распределенные по уровнямМинипорты, распределенные по уровнямМинипортыЛВС/ГВСМинипортыЛВС/ГВС■ 1ланировщик пакетов■ 1ланировщик пакетовPPTP L2TPPPTP L2TPNDIS 5.0NDIS 5.0Разгрузка: контрольнаясумма, IPSec, отсылкабольших фрагментов TCPРазгрузка: контрольнаясумма, IPSec, отсылкабольших фрагментов TCP
Минипорты, распределенные по уровням
Минипорты, распределенные по уровням
Минипорты
ЛВС/ГВС
Минипорты
ЛВС/ГВС
■ 1ланировщик пакетов
■ 1ланировщик пакетов
PPTP L2TP
PPTP L2TP
NDIS 5.0
NDIS 5.0
Разгрузка: контрольнаясумма, IPSec, отсылкабольших фрагментов TCP
Разгрузка: контрольнаясумма, IPSec, отсылкабольших фрагментов TCP
Рис. 6.2. Архитектура стека протоколов TCP/IP Windows
Если аппаратная штата реализует перенос задачи TCP/IP на уровень NDIS, в системе становится доступным большой объем вычислительных ресурсов центрального пронес - сора, используемых для обработки входящих пакетов, зашифрованных с использованием протокола IPSec. Платы различных производителей немного различаются между собой, поэтому сетевому администратору необходимо внимательно изучить все имеющиеся возможности и, возможно, скорректировать ранее принятое решение. Подобное аппаратное обеспечение, как правило, выпускается двумя производителями (Intel и 3Com). В ближайшем будущем можно надеяться на появление других решений, однако даже при использовании этих плат можно достичь значительного увеличения производительности, поскольку эти устройства берут на себя выполнение процесса шифрования. Эти платы могут использоваться одновременно лишь небольшим количеством ассоциаций безопасности, и если ваш туннельный сервер должен поддерживать большое число клиентов, желательно, чтобы в одной системе устанавливалось несколько плат.
Заголовокаутентификации
Протокол АН является одним из лвух протоколов IPSec; в его задачи входит и защита IP-дейтаграмм в Windows 2000. Этот протокол поддерживает проверку источника данных для передаваемых пакетов, целостность данных, а также наличие зашиты, блокирующей ответ, однако, он не выполняет шифрование трафика. В списке протоколов ему присваивается номер пятьдесят один (51). Протокол АН обеспечивает строгую иела- стность и аутентификацию пакетов с помощью метода шифрования CHECKSUM, примененного ко всему пакету. Исключением являются некоторые изменяемые поля, такие как Time To Live (Время существования) и Type Of Service (Тип службы). Эти изменяющиеся поля содержатся в IP-заголовке и обновляются при передаче пакета по сети.
Заголовок АН IPSec вставляется непосредственно после исходного IP-заголовка и содержит несколько компонентов, как показано на рис. 6.3. В следующем списке ука-
эаны компоненты стандартного IP-пакета, который был изменен, в результате чего появился пакет АН IPSec.
Поле Next Header (Следующий заголовок) указывает на данные, следующие за заголовком АН. В транспортном режиме здесь указывается протокол верхнего уровня, реализующий систему безопасности. В туннельном режиме здесь указывается значение четыре (4), что свидетельствует о том, что имеется инкапсуляция типа IP-B-1P (IPv4).
Поле Payload Ьег^ЩДлина полезной нагрузки) применяется для указания длины заголовка с помощью 32-разрядных слов, из которых вычитается 2.
Поле Reserved (Зарезервировано) не используется; ему следует присвоить значение нуль.
Поле Security Parameter Index (SPI, индекс параметра безопасности) является меткой, которая указывает на пакет, принадлежащий определенной SA. Ассоциация SA устанавливается между двумя компьютерами. В ходе осуществления этого процесса также устанавливается договоренность по поводу применяемого SPI. Подобные ассоциации и параметры, установленные по согласованию, передаются в составе каждого пакета, а затем применяются в ходе финальной обработки пакетов после их получения.
Поле Sequence Number (Номер последовательности) представляет собой 32- разрядное число, которому присваиваются значения, начиная с 1. Благодаря этому, получатели могут узнать, что именно этот пакет является текущим. Если трафик перехвачен в сети и затем возобновляется в некоторой точке при осуществлении коммуникаций, он будет игнорироваться. Появление устаревших номеров последовательности чисел указывает на то, что трафик не соответствует дате отправки пакетов. В Windows 2000 реализация протокола IPSec АН обладает такой особенностью, что получатель всегда может выполнить так называемую проверку отклика. Пользователь проверяет номера последовательности и убеждается в том, что была получена именно текущая информация.
И, наконец, в конце заголовка IPSec находится ключевой хеш. Наличие этого элемента гарантирует аутентификацию и целостность пакета. В связи с этим речь идет о функции CHECKSUM (CHECKSUM шифрования), вычисляемой перед отсылкой пакета. Если отправитель может удостоверить этот хеш при получении пакета, получатель может быть уверен в том, что пакет не изменился за время его передачи.
Исходный пакет
Преобразованный пакетПреобразованный пакетИнтегрированное хеш-покрытие (исключая измененные тля в IP-заголовке)Интегрированное хеш-покрытие (исключая измененные тля в IP-заголовке)
Преобразованный пакет
Преобразованный пакет
Интегрированное хеш-покрытие (исключая измененные тля в IP-заголовке)
Интегрированное хеш-покрытие (исключая измененные тля в IP-заголовке)
Детали заголовка АН
След, заголовок}Длина ПолезНагр} Зареэерв | ИндексПарамПослед |#лослед[ Ключевой хеш |
Рис. 6.3. Пакет IPSec АИ
Инкапсуляция полезной нагрузки
системы безопасности (ESP)
На рис. 6.4 показано, каким образом IPSec ESP обрабатывает исходный IP-пакет, преобразовывая его в пакет формата IPSec для ESP. При этом обеспечивается конфиденциальность, аутентификация источника данных, возможность противодействия отклику, а также службы обеспечения целостности данных для IP. Протокол ESP выполняет те же задачи. что и АН, и, кроме того, реализует шифрование данных.
Исходный пакет
I Исход, загол IP | ЗаголТСР | Данные 'П
ДобавленныйДобавленныйВключенныйПреобразованный пакет
Добавленный
Добавленный
Загол ESPЗагол ESPЗагол TCP । Данные Завершитель ESPЗагол TCP । Данные Завершитель ESPАутент ESPАутент ESP
Загол ESP
Загол ESP
Загол TCP । Данные Завершитель ESP
Загол TCP । Данные Завершитель ESP
Аутент ESP
Аутент ESP
Зашифрованный
Интегрированное хеш-покрытие
ИндексПарамПослед#последовНачВекторИндексПарамПослед#последовНачВекторДетали загол ESPДетали загол ESPДетали аутент ESPКлючевой хешДетали аутент ESPКлючевой хеш
ИндексПарамПослед
#последов
НачВектор
ИндексПарамПослед
#последов
НачВектор
Детали загол ESP
Детали загол ESP
Детали аутент ESP
Ключевой хеш
Детали аутент ESP
Ключевой хеш
Детали завершителя ESP
Заполнение1 ДлинаЗаполн СледЗагол
Рис. 6.4. Преобразование пакета с помощью протокола инкапсуляции полезной нагрузки безопасности
В следующем списке содержатся компоненты стандартного 1Р-пакета, который был преобразован в пакет IPSec ESP.
ЗаголовокESPследуетза исходнымIP-заголовком,какв туннельном,таки в
транспортном режимах (он включает поле SPI). Это значение, используя адрес места назначения и протокол в IP-заголовке, идентифицирует соответствующее соглашение по безопасности, которое используется при обработке пакета. Затем шифруются данные, представляющие собой содержимое исходного IP-пакета.
Затем следует заголовок TCP, данные и завершитель ESP. Завершитель ESP отвечает за шифрование и синхронизацию данных в соответствии с ограничениями, устанавливаемыми с помощью байтов. Поле Pad Length (Длина заполнения) определяет, какой объем заполняемых данных необходимо добавить, чтобы получатель смог восстановить фактическую длину данных полезной нагрузки. Поле Pad Length является обязательным для заполнения, поэтому даже если оно не заполнено, отображается фактическое значение длины.
Интегрированное хещ-покрытиесодержит все данные, начиная от заголовка ESP, заканчивая завершителем ESP. С помощью завершителя ESP заголовок TCP кодируется, что позволяет защитить заголовок ESP с помощью механизма целостности, обеспечиваемого хэшем. При этом возможен просмотр данных. Зашифрованные пакеты могут быть декодированы после достижения пункта назначения.
Исходные IP-пакеты преобразуются в пакеты, отформатированные с помощью протокола IPSec. Здесь важно учитывать то, что пакеты по-прежнему остаются IP- пакетами версии 4. Подобная обратная совместимость позволяет пакетам использовать все имеющиеся IP-сети.
Совместимость с сетями IPv4 характеризуется некоторыми исключениями. Если некоторое устройство в сети пытается просматривать содержимое пакета, не ограничиваясь ознакомлением с IP-заголовком, происходит сбой. Так происходит при выполнении некоторых приложений, которые выполняют поиск заголовков TCP, UDP или других протокольных полей в самом пакете. Поскольку эти элементы не шифруются, просмотр пакетов подобных типов затруднен.
Служба трансляции сетевых адресов (NAT — Network Address Translation) является хорошим этому примером. Служба NAT нуждается в просмотре номеров портов для исходного порта TCP и для порта места назначения, поэтому может транслировать пакет. Поскольку протокол IPSec шифрует пакет, NAT не может просматривать значения портов и, поэтому, не может их изменять. Даже при использовании формата АН, хеш-покрытие охватывает IP-заголовок. Если исходный адрес и адрес места назначения обновляются, в хеш-покрытие включаются флаги, а пакет отклоняется, поскольку представляет риск нарушения безопасности.
Поэтому, при использовании форматов IPSec АН или IPSec ESP серверы NAT представляют атаку типа "человек посередине", что приводит к сбою при выполнении протокола IPSec. Хотя возникновение подобной проблемы может потребовать от сетевого администратора внесения изменений в проект сети, сбои при функционировании на самом деле демонстрируют тот факт, что IPSec точно выполняет поставленную перед ним задачу.
Независимость приложений
Как отмечалось ранее, идеальный протокол безопасности должен функционировать без каких-либо обновлений со стороны приложения. На рис. 6.5 показаны два компьютера, объединенные с помощью сети. Компьютер, находяшийся слева, выполняет приложение, которое нуждается в установлении соединения с системой, находя- шейся справа. Поэтому компьютер, находящийся слева, является инициатором^ компьютер, находяшийся справа, — ответчиком.
ИнициаторWindows 2000ИнициаторWindows 2000ОтветчикWindows 2000ОтветчикWindows 2000
Инициатор
Windows 2000
Инициатор
Windows 2000
Ответчик
Windows 2000
Ответчик
Windows 2000
Рис, 6.5. Протокол fPSec, реализующий соглашение согласно протоколу обмена ключей Internet
Приложение или служба клиента организована над уровнем Winsock. Приложение, находящееся с одной стороны, открывает сокет, устанавливает подключение обычным образом, не учитывая при этом какие-либо моменты, имеющие отношение к IPSec.
Следующий перечень кратко описывает процесс, при выполнении которого ключ совместно используется источником и местом назначения зашифрованного трафика.
Приложение или служба направляет трафик вниз, в стек протоколов TCP/IP, а стек протоколов передает трафик драйверу IPSec.
Пакеты, направленные драйверу IPSec, сравниваются с фильтрами. В данном примере в действие вступает договоренность о безопасности. Затем драйвер IPSec вызывает службу IKE.
Служба IKE просматривает фильтр, с которым сравниваются пакеты, а также отслеживает его действия. Затем 1КЕ при рассмотрении эффекта действия фильтра. знакомится с необходимыми методами по обеспечению безопасности, которые применяются при обработке данного пакета.
Протокол IKE направляет трафик порта 500 UDP к месту назначения, информация о котором извлекается из исходного пакета.
Пакет помещается в очередь драйвера IPSec, ожидая завершения выполнения соглашений по безопасности. Если приложение продолжает пересылку пакетов, драйвер IPSec отменяет ее, сохраняя только последний пакет, который обрабатывается фильтром. Обычно, установка первоначальных соглашений занимают менее одной секунды (хотя это зависит от используемой сети, а также от того, насколько быстро выполняется согласование трафика, реализующего передачу данных между двумя компьютерами).
Протокол IKE применяет порт 500 UDP для передачи трафика и устанавливает все параметры, необходимые для установки безопасного соединения между компьютерами, а также обеспечения безопасности определенного трафика.
Протокол IKE также реализует обмен номерами SPI. В этом случае каждая из сторон знает, какая метка используется в пакете для пересылки получателю.
Получатель выбирает SPI и пересылает его инициатору.
К концу "переговоров" между системами уже существует материал для реализации совместно используемого ключа, который не может быть перехвачен "по пути".
На этом этапе между двумя системами уже имеется соглашение, учитывающее параметры безопасности, которые используются для защиты трафика. Для ответчика в роли этих параметров выступает новая входящая и исходящая ассоциация безопасности (SA), которая соответствует входящему и исходящему SA для инициатора.
Затем драйвер IPSec обрабатывает пакет в соответствии с материалом ключа, форматами и алгоритмами безопасности, а также выполняет его отправку,
Протоколы IPSec и SSL
В дополнение к IPSec протокол Secure Sockets Layer (SSL) представляет собой другую возможность по обеспечению безопасности, реализуемой в соответствии с алгоритмом "точка-точка". В этом случае обеспечивается безопасность сетевого трафика, который передается внутри корпорации либо за ее пределы, с помощью Internet. Оба программных продукта получили широкое распространение, поэтому целесообразно сравнить их, выявляя ключевые аналогии и отличия. Протокол SSL применяет протокол TCP, поэтому требуется, чтобы приложения поддерживали безопасность SSL и точно представляли, каким образом поддерживается подключение SSL. Как сервер, так и клиент должны учитывать, что SSL-сеанс представляет собой метод коммуникации, реализуемой между двумя системами. Требование подобной осведомленности приложения и отличает протокол SSL от протокола IPSec.
Важно отметить, что подобные подходы приводят к различиям в решении задач по обеспечению безопасности. Каждый из этих подходов играет важную роль в обеспечении сетевой безопасности, Также важно отметить, что как для протокола IPSec, так и для протокола SSL имеются решения аппаратной разгрузки. Однако, если на сервер установить плату разгрузки SSL, невозможно использовать протокол IPSec и, наоборот (при использовании платы разгрузки IPSec нельзя использовать протокол SSL).
Поэтому, при конфигурировании аппаратного обеспечения сервера важно полностью представлять задачи, решение которых обеспечивается с помощью этого сервера. Также следует точно представлять, каким образом каждый поставщик аппаратного обеспечения может помочь вам в процессе разработки.
Выбор среды протокола IPSec
Как обсуждалось в предыдущих главах, сетевому администратору следует знать о том, какие вопросы и цели ставятся в процессе проектирования сети. Выбор варианта развертывания протокола IPSec на самом деле зависит от типа трафика, топологии сети, а также от того, где именно применяются меры безопасности.
Если сетевая среда нуждается в реализации безопасности по схеме "точка-точка", очевидно, следует остановиться на протоколе IPSec. Протоколы РРТР и L2TP не обеспечивают простую поддержку безопасности по схеме “точка-точка". Администраторы, ответственные за безопасность сети в вашей организации, должны создавать и развертывать такой сорт корпоративных политик, которые позволят защитить трафик в соответствии с запросами и целями данной корпорации. Обычно не требуется защищать каждый бит трафика, передаваемого от каждого клиента и сервера. Желательно, составить перечень систем, приложений и/или протоколов, безопасность которых следует обеспечить. Несмотря на эффективность протокола IPSec, при его использовании появляются дополнительные сложности при передаче сетевого трафика, а также при функционировании систем, выполняющих шифрование и декодирование трафика.
Хорошим примером трафика, не требующего шифрования, является Web-трафик, передаваемый через брандмауэр. Поскольку трафик, генерируемый различными Web- северами в Internet, не кодируется, не имеет большого смысла шифровать его при прохождении через внутреннюю сеть. С другой стороны, примером трафика, который обязательно следует кодировать, является трафик, генерируемый базами данных отдела кадров. Обычно этот трафик содержит конфиденциальные сведения, которые нуждаются в защите.
Мне бы не хотелось подробно рассматривать вопросы, связанные с определением целей сетевого проектирования, перед выполнением разработки сети. Как уже не раз отмечалось в книге, можно прекрасно спроектировать любую сеть, но при этом требуется обеспечить ее эффективное функционирование. Сетевой проект должен быть упрощен в максимальной степени.
При использовании протокола IPSec следует четко представлять задачи, стоящие перед вашей корпорацией. Желательно определить зоны безопасности для ЛВС/ГВС, а также определить цель, которая преследуется при развертывании туннельного сервера. Для решения, связанного с протоколом IPSec, реально существуют только три основных типа развертывания, связанные с использованием технологий VPN в Windows 2000.
Поддержка перемещающихся пользователей. При использовании этого решения можно выбирать один из двух протоколов: РРТР или L2TP. Протокол РРТР устанавливается довольно быстро и легко, обеспечивая возможность перемещения пользователей. Изначально протокол L2TP требует больше времени на поддержку, поскольку в этом случае устанавливается сервер сертификатов. Однако после развертывания компьютерных сертификатов, клиенты уже не замечают особой разницы.
Подключения VPN типа“шлюз-шлюз". При реализации этого решения доступны три основные возможности. И снова протокол РРТР может поддерживать передачу данных между узлами, в то время как протокол L2TP может быть сконфигурирован в качестве туннеля, установленного между двумя маршрутизаторами. Третья возможность, обеспечиваемая протоколом IPSec в туннельном режиме, заключается в обеспечении связи между двумя шлюзами. Этот вариант идеально подходит для подключения к внешним маршрутизаторам, а также оказывается
полезной при решении проблем обратных путей, которые иногда появляются в крупных сетях, в состав которых входит несколько граничных серверов. В качестве внешнего маршрутизатора может использоваться любое устройство, совместимое с протоколом IPSec, — от маршрутизатора Cisco до IP-протокола.
Безопасность, реализуемая по схеме "точка-точка", на отрезках клиент-сервер, сервер-сервер и клиент-клиент. Транспортный режим IPSec может поддерживать полную безопасность при функционировании любой сети и полностью сконфигурирован с учетом запросов этой среды.
Имейте в виде, что для этих решений, несмотря на использование одних и тех же технологий, существенно отличается используемый метод развертывания. Каждое из этих трех решений требует радикально иного подхода при анализе настроек и конфигураций безопасности. Необходимо определить собственный подход, чтобы составить мнение об особенностях каждого из вариантов развертывания протокола.
Дополнительная информация о туннельном режиме IPSec
Компания Microsoft предполагала, что туннельный режим IPSec используется, в основном, для связей с посторонними операционными системами или аппаратными устройствами. На самом же деле туннель IPSec грядет на смену протоколам РРТР и L2TP.
Основным замечанием, связанным с туннельным режимом протокола IPSec в Windows 2000, является тот факт, что после создания туннельного канала связи IPSec, он не будет отображаться в качестве интерфейса службы маршрутизации и удаленного доступа (RRAS— Routing and Remote Access Service). Поэтому служба RRAS не может идентифицировать это подключение. Параметры маршрутизации должны применяться к подсети или IP-адресам. Это во многом ограничивает функциональные возможности RRAS при использовании туннелей IPSec. Это замечание имеет большое значение, поскольку стандарты туннелей IPSec претерпевали изменение в процессе разработки Windows 2000, а также потому, что большинство заказчиков могли решать свои задачи посредством подключения, установленного с ПОМОЩЬЮ протокола L2TP/lPSec.
Другое замечание, связанное с туннельным режимом IPSec состоит в том, что для идентификации конечной точки туннеля IPSec невозможно использовать полностью определенное доменное имя (FQDN — Fully Qualified Domain Name). Эта возможность обычно присутствовала в ранних версиях Windows 2000, но отсутствует в современных версиях. Дело в том, что потенциальный риск, который исходит от не аутентифицированных конечных точек, может "сыграть злую шутку" с доменным именем. Протоколы L2TP и РРТР поддерживают систему FQDN.
Исходя из практических соображений, протокол L2TP для поддержки туннельных служб практически столь же эффективен в использовании, сколь и туннельный режим IPSec. Использование протокола L2TP не влечет столь больших накладных расходов, поскольку этот протокол отвечает за. туннелирование и управление туннелем, в то время как протокол IPSec поддерживает безопасность. Также протокол L2TP имеет огромное преимущество. поскольку значительно проще конфигурируется, определяя интерфейс с помощью службы RRAS. Кроме того, протокол L2TP может выполняться в многопротокольных средах, в то время как туннельный режим IPSec поддерживает только протокол TCP/IPSec,
В настоящее время в Windows 2000 существует возможность с помощью транспортного режима IPSec поддерживать обобщенную систему безопасности, реализуемую по схеме "точка-точка". Однако подобный подход не рекомендуется при развертывании систем в Internet. Транспортный режим IPSec удобен при использовании в локальной сети, обеспечивая защиту трафика "клиент-сервер" или "сервер-сервер".
Управление политиками IPSec
Если домен включает тысячи клиентов. контроль параметров сетевой безопасности довольно проблематичен и сопряжен с крупными административными затратами. Поскольку сеть формируется для решения потенциально сложных задач, политики IPSec включаются в качестве встроенной возможности в Windows 2000 Active Directory.
При промышленном развертывании Active Directory все клиенты Windows 2000 могут быть сконфигурированы с ПОМОЩЬЮ групповой политики. Эта возможность обеспечивает один из методов распространения политики IPSec среди членов домена. Групповая политика может применяться на локальном уровне, на узле, домене и на уровне подразделения. Все сетевые администраторы, выполняя развертывание протокола IPSec, должны иметь четкое представление о важности роли, которую играют групповые политики в Windows 2000.
Груп новые политики определяются в Active Directory и могут присваиваться домену или подразделению на любом уровне (если компьютерные учетные записи представлены в этих подразделениях). Эта возможность позволяет администратору домена развернуть зону протокола IPSec по всему домену при минимальном личном вмешательстве с его стороны.
При выполнении начальной загрузки компьютеров, которые являются членами Active Directory, они получают объекты групповой политики и узнают о сушествова- нии политики IPSec. Затем агент политики IPSec копирует политику IPSec из Active Directory и реализует ее для клиента. Также IPSec может иными способами реализовать преимушество развертывания групповой политики. Например, если клиент нуждается в подтверждении других корневых сертификатов, администратор может определять эти сертификаты в качестве части групповой политики. Их можно конфигурировать с помощью доверительных списков сертификатов, а также воспользоваться политикой автоматического конфигурирования сертификатов.
Политика автоматического конфигурирования заключается в том, что компьютер за получением сертификата обращается к определенному серверу сертификатов. Использование политики автоматического конфигурирования наилучшим образом подходит для сертификатов в том случае, если для клиентов Windows 2000 поддерживаются службы удаленного доступа. В этом случае клиенты нуждаются в компьютерном сертификате для аутентификации IPSec и поддержки переговоров по протоколу IKE с защищенным сервером. Операционная система Windows 2000 всегда использует сертификаты для ведения переговоров IPSec с системами, поэтому проше всего установить групповую политику автоматического конфигурирования при использовании протокола L2TP IPSec для развертывания системы удаленного доступа. Клиенты и члены домена должны оставаться аутентифицированными с целью добавления к домену учетной записи компьютера, однако, именно такая же процедура выполняется и без развертывания сертификата.
Обзор функционирования протокола IPSec
К счастью, фактическое использование политики IPSec не обязательно основывается на тех политиках, которые включены в заданную по умолчанию инсталляцию Windows 2000. К сожалению, этот процесс не так прост, как подключение встроенной политики, а также немедленное использование настроек сервера, которые будут полностью функциональными в сети. Заданные по умолчанию настройки активизируются таким образом, что администратор может изучать их поведение или применять их в качестве моделей для пользовательских политик (рис. 6.6).
На первом этапе сетевой администратор должен спланировать весь процесс. В приведенном ниже списке содержатся типичные задачи, которые потребуется выполнить администратору при планировании процесса развертывания IPSec:
проанализируйте трафик сети и удостоверьтесь в том, что он является защищенным;
определите, каким образом сервер и политика наилучшим образом соответствует конкретной сетевой топологии;
■ учитывайте, что обеспечение безопасности трафика потребует некоторых затрат времени (потребуется учесть все виды серверов и трафика, включая такие вопросы, как заданные по умолчанию шлюзы, мониторинг и т.п.
Рис. 6.6. Политика IPSec, установленная для объектов Active Directory
Важно понимать, каким образом среда, где реализуется политика в целом, соответствует клиенту и серверу, которые являются членами домена Windows 2000. Хорошим примером этого является клиент настольного компьютера, который является участником домена, сконфигурированного для пересылки трафика без применения протокола IPSec. Если сервер назначения выполняет запрос на предмет использования протокола IPSec, тем не менее, в данном случае выполняется клиент настольного компьютера. При этом клиент выполняет исключительно политику отклика и не является инициатором переговоров IKE. К моменту завершения этого процесса клиент не обязан шифровать трафик для серверов, которые не требуют использования протокола IPSec, Однако клиент шифрует трафик для серверов, обрабатывающих защищенные данные.
Рассмотрим, что произойдет, если на сервере определяется политика IPSec. В Windows 2000 Active Directory применяется протокол Kerberos версии 5 в качестве заданного по умолчанию решения, обеспечивающего безопасность. Также остается поддержка безопасности, основанной на использовании LAN Manager (LanMan) в целях обеспечения обратной совместимости. Поскольку протокол IPSec не поддерживается в Windows NT 4.0, необходимо всегда использовать систему безопасности, реализованную с помощью протокола Kerberos. Серверы Windows 2000 по умолчанию изначально применяют Kerberos, поэтому нет необходимости выполнять специальную настройку в этом случае.
На рис. 6.7 и в последующих шагах кратко описывается базовый процесс по установке соглашения IPSec, основанного на использовании Kerberos. Обратите внимание, что в этом примере все участники сконфигурированы с целью установки доверительных отношений по отношению к любым участникам домена. Они обычно используются при реализации большинства вариантов развертывания Active Directory.
Сервер использует политику безопасности в том случае, когда требуется направить трафик от IP-адреса по любому IP-адресу места назначения. В данном случае будет защищен весь входящий и исходящий трафик.
При загрузке клиента осуществляется поиск контроллера домена, который затем конфигурируется в соответствии с политикой безопасности. После регистрации компьютера первым делом он получает полномочия Kerberos, что позволяет ему получать доступ к объектам политики.
Клиентская политика(только отклик)Клиентская политика(только отклик)-Выполняйте чистую отсылку, защищайте трафик только в случае запроса.Участники домена доверия.»-Выполняйте чистую отсылку, защищайте трафик только в случае запроса.Участники домена доверия.»Установленные ассоциациибезопасности IPSecУстановленные ассоциациибезопасности IPSec•Обеспечьте безопасность для любого трафика, исходящего в любом направлении.•Обеспечьте безопасность для любого трафика, исходящего в любом направлении.Участники домена доверия.»Участники домена доверия.»Рис. 6. 7. Соглашение IPSec на базе протокола KerberosРис. 6. 7. Соглашение IPSec на базе протокола Kerberos
Клиентская политика
(только отклик)
Клиентская политика
(только отклик)
-Выполняйте чистую отсылку, защищайте трафик только в случае запроса.
Участники домена доверия.»
-Выполняйте чистую отсылку, защищайте трафик только в случае запроса.
Участники домена доверия.»
Установленные ассоциациибезопасности IPSec
Установленные ассоциациибезопасности IPSec
•Обеспечьте безопасность для любого трафика, исходящего в любом направлении.
•Обеспечьте безопасность для любого трафика, исходящего в любом направлении.
Участники домена доверия.»
Участники домена доверия.»
Рис. 6. 7. Соглашение IPSec на базе протокола Kerberos
Рис. 6. 7. Соглашение IPSec на базе протокола Kerberos
После того, как клиент получает полномочия билета, предоставляющего билет (TGT— Ticket Granting Ticket) -ИЛИ Kerberos, объекты политики копируются для клиента из Active Director}'. Групповая политика может присваиваться на различных уровнях, а также оцениваться в определенном порядке. Клиент отсылает начальный запрос на осуществление коммуникации в виде простого текста, поскольку соответствующая политика позволяет выполнять пересылку обычного трафика.
Назначения политик*
В рассматриваемом примере объекты политики установлены на уровне домена. Если на уровне подразделения установлены дополнительные политики, на компьютере в любой данный момент времени применяется только одна политика IPSec. Когда клиент запускается для просмотра политик, начиная с верхней части домена, спускаясь вниз по дереву, действенным оказывается самый низкий уровень политики IPSec для подразделений. Эта политика IPSec применяется Windows 2000 по отношению к компьютеру. В’ опыи- чие от групповых политик, политики IPSec не объединяются в составе Windows 2000.
В данном примере обеспечивается доступ к трафику на защищенном компьютере. Заданная по умолчанию политика защищенного сервера допускает входящий простой текст, разрешенный для незащищенного подключения. Затем сервер откликается, используя протокол IPSec.
На защищенном сервере приложение откликается на запрос клиента, а этот отклик должен обрабатываться фильтром политики. С помощью этой политики фильтр утверждает, что весь трафик, имеющий любое место назначения, должен быть защищен с помощью IP-адресов сервера.
Настройки политики переключают соглашение IKE обратно к клиенту, поскольку исходящий пакет в качестве пункта назначения рассматривает IP-адрес клиента.
Сервер запрашивает билет из контроллера домена, поскольку в качестве метода установки доверия используется протокол Kerberos.
Центрраспределенияключей(KDC —KeyDistributionCenter)откликаетсяобрат
но в ответ на запрос сервера с помощью билета, выданного на проведение переговоров с этим клиентом. Затем сервер внедряет этот билет в соглашение IKE. Этот билет применяется именно в целях аутентификации, но не для шифрования, с последующей поддержкой со стороны клиентов.
Клиент использует заданное по умолчанию правило отклика, которое позволяет отзываться на запросы защищенной сети. Заданное по умолчанию правило отклика также утверждает, что клиент доверяет участникам домена.
Правило сервера также доверяет участникам домена, поэтому сервер предлагает метод аутентификации Kerberos и пересылает клиенту для подтверждения полномочия Kerberos.
После завершения установки соглашения клиент и сервер устанавливают канал безопасности IPSec, реализованный по схеме "точка-точка".
В этом примере с целью поддержки протокола IPSec были внесены только три изменения: оба компьютера должны подключаться к домену (что является типичным); клиент получает политику домена, в которой утверждается, что он должен быть ответчиком; сервер конфигурируется в качестве инициатора IPSec.
Подобным образом обеспечивается безопасность всей сети. Однако имеется одно очевидное замечание, которое касается клиентов, не поддерживающих протокол IPSec, например, Windows 98. Эти клиенты не могут успешно использовать приложения на данном сервере.
При загрузке системы из Active Directory берутся следующие сведения: полномочия Kerberos и настройки политики. Помимо этого настройки политики требуют выполнения автоматического конфигурирования, выполняемого с помощью сервера сертификатов, обеспечивающего выдачу компьютерных сертификатов. Клиентские системы имеют два набора полномочий, — полномочия Kerberos и сертификаты.
Когда клиент подключается с корпоративной сети, находясь вне нее (например, если пользователь использует переносной компьютер), и желает воспользоваться туннелем с помощью протокола L2TP/IPSec, пользователю сначала придется получить сертификат. Можно воспользоваться автоматической настройкой, но для этого потребуется, чтобы на начальном этапе подключение устанавливалось не с протоколом L2TP/lPSec. Обычно в этом используется протокол РРТР. При этом не обязательно требуется автоматическое конфигурирование, поскольку клиент может устанавливать подключение с помощью протокола РРТР, а затем запрашивать сертификат, находясь на Web-странице сервера сертификатов. И напоследок, с целью использования протокола L2TP/IPSec удаленными пользователями следует уточнить план развертывания доверенных сертификатов. Дополнительная информация по этому вопросу находится в главе 5.
Протокол IKE согласует безопасность для протокола L2TP, а также применяет для аутентификации подключения сертификат, который был получен в качестве участника домена. Аналогичный контроль над доступом можно установить с помощью протокола РРТР, но подобный контроль будет основан только на ID пользователя и на пароле либо на смарт-карте, используемой в качестве средства по идентификации пользователя. С помошью протокола L2TP IPSec применяет сертификат компьютера. Как клиент, так и сервер удаленного доступа должны располагать взаимным сертификатом доверия для обеспечения безопасности IPSec.
С помощью протокола IPSec в сконфигурированной подходящим образом инфраструктуре сетевой администратор может с помощью Kerberos легко защитить все серверы, находящиеся в составе домена. Система безопасности является довольно "прозрачной" и распространяется на все объекты, начиная от корпоративных серверов Exchange, завершая серверами базы данных Oracle, выполняющими финансовые приложения. Трафик, обрабатываемый мэйнфреймом, может быть защищен даже с помощью Microsoft SNA Server.
Несмотря на то, что протокол iPSec поддерживает безопасность на довольно высоком уровне, не обеспечивается безопасность в некоторых протоколах. Протокол IPSec не защищает следующие пакеты, либо они не могут быть включены в фильтры IPSec. Некоторые из этих пакетов желательно изменять при разработке будущих сервисных пакетов, но на сегодняшний день не реализована защита следующего трафика:
трафик IKE — порт 500;
протокол Kerberos — UDP и TCP порт 88;
протокол резервирования ресурсов (RSVP — Resource Reservation Protocol).
Защита этих протоколов не предусмотрена проектом Windows 2000. Протокол IKE требует инициализации сеанса IPSec, а другие протоколы считаются достаточно важными, чтобы исключить их целевую поддержку со стороны Kerberos и QoS. В данном случае может быть инициирована атака отказа от обслуживания, но внедрение фильтрации RRAS или применение фильтров подключения с целью блокировки портов TCP и UDP может уменьшить степень риска. Необходимо только удостовериться в том, что сетевой проект не вступит в противоречие с требованиями подключения, реализуемыми при использовании IPSec, В качестве очевидного примера обратите внимание на фильтрацию порта 500 и примените протокол IPSec, поскольку протокол IKE использует этот порт для установки сеансового соглашения.
Сетевые среды, в которых используются решения IPSec сторонних производителей, могут применять пользовательские политики и поддерживать связь с помощью IPSec. Компания Microsoft проводит большую работу по упрочению взаимодействия IPSec с большим числом различных платформ. Большинство основных операционных систем смогут применять протокол IPSec уже в ближайшем будущем. Сетевой администратор может легко обеспечить безопасность сети, используя большое количество решений либо задействуя Kerberos в качестве метода аутентификации, либо применяя сертификаты.
При разработке схемы IPSec для вашей корпорации воспользуйтесь следующими соображениями и проанализируйте имеющиеся требования к безопасности сети:
идентифицируйте серверы, располагающие данными, которые следуетзащищать;
идентифицируйте группы пользователей или системы, которые будут связываться с этими серверами безопасности;
проанализируйте степень риска для бизнеса в случае, если обычный текст будет перехвачен в сети;
идентифицируйте в сети строгую, среднюю и слабую зоны безопасности.
После идентификации областей, которые нуждаются в зашите, необходимо определить и конфигурировать требования политики для каждой из этих систем. Эти требования ДОЛЖНЬЕ точно соответствовать запросам, связанным с безопасностью. Следующие указания помогут определить зоны безопасности в сети:
♦ если принимается решение относительно того, стоит ли использовать шифрование (а также выбирается тип шифрования), либо определяется, требуется ли выполнять проверку целостности, следует представлять, какие требования предъявлять в процессе защиты, а также определить, сколь строгой она должна быть;
изучите сеть и ее топологию, а также примите решение, каким образом контролировать политики, поддерживающие развертывание защищенного сервера;
• определите, каков объем затрат и персонального участия потребуется для развертывания настраиваемой среды безопасности Windows 2000.
Наконец, желательно выполнить небольшой пробный тест с тем, чтобы сетевые администраторы могли удостовериться в том, что выполняется среда IPSec. В качестве части теста выполните захват сетевой информации и проанализируйте трафик с целью подтверждения эффективности мер по защите трафика.
Поддержка безопасности по схеме "точка-точка", реализуемой для двух систем в домене
При использовании следующих процедур можно сконфигурировать профессиональную систему Windows 2000 с целью выполнения коммуникации с сервером Windows 2000, используя возможности протокола IPSec. Обе системы входят в состав домена HappyVPN, который сконфигурирован для автоматического развертывания компьютерных сертификатов, используемых каждым компьютером.
Примечание
Все процедуры, описанные в этой главе, вытекают одна из другой. Поэтому важно рассматривать их в последовательном порядке.
Шаги процедуры 6.1 демонстрируют! каким образом настраиваются компьютеры с целью мониторинга протокола IPSec.
Процедура 6.1. Установка компьютеров для мониторинга протокола IPSec
ннI cv«z^r / /Ivjvn#*- Unfit ЦЛ S#CW YjhJuws л» i ум? tWiwiI cv«z^r / /Ivjvn#*- Unfit ЦЛ S#CW YjhJuws л» i ум? tWiwiИ .*101 *1И .*101 *1twtwV^ ^ L*wrl« 1 О - 23 ® ' □ (Qi ; 6? JillV^ ^ L*wrl« 1 О - 23 ® ' □ (Qi ; 6? JillI Ска в т -ШУI Ска в т -ШУh»e| рлуяе»! |_] C***ROM* I CertirkeUf (local Com t ! Local ComovteiPodcyi»j ^ Computer Conhyrh»e| рлуяе»! |_] C***ROM* I CertirkeUf (local Com t ! Local ComovteiPodcyi»j ^ Computer Conhyr'MW -'MW -1 i "г-r1 i "г-rИ Gent (Rrapond Only) Corremxwete normally (unt... No B5»ci>e5ervw(Requli... Rorel IPtrafhc, elweytr*,,. No 1ЁЗ Server (RwjuertSecu.. Pty MIP traffic, aHmreq. . NoИ Gent (Rrapond Only) Corremxwete normally (unt... No B5»ci>e5ervw(Requli... Rorel IPtrafhc, elweytr*,,. No 1ЁЗ Server (RwjuertSecu.. Pty MIP traffic, aHmreq. . NoIWMesr-!.IWMesr-!.Puc. 6.8. Заданные по умолчанию политики IPSecPuc. 6.8. Заданные по умолчанию политики IPSec
н
н
I cv«z^r / /Ivjvn#*- Unfit ЦЛ S#CW YjhJuws л» i ум? tWiwi
I cv«z^r / /Ivjvn#*- Unfit ЦЛ S#CW YjhJuws л» i ум? tWiwi
И .*101 *1
И .*101 *1
tw
tw
V^ ^ L*wrl« 1 О - 23 ® ' □ (Qi ; 6? Jill
V^ ^ L*wrl« 1 О - 23 ® ' □ (Qi ; 6? Jill
I Ска в т -ШУ
I Ска в т -ШУ
h»e| рлуяе»! |
_] C***ROM
* I CertirkeUf (local Com t ! Local ComovteiPodcy
i»j ^ Computer Conhyr
h»e| рлуяе»! |
_] C***ROM
* I CertirkeUf (local Com t ! Local ComovteiPodcy
i»j ^ Computer Conhyr
'MW -
'MW -
1 i "г-r
1 i "г-r
И Gent (Rrapond Only) Corremxwete normally (unt... No B5»ci>e5ervw(Requli... Rorel IPtrafhc, elweytr*,,. No 1ЁЗ Server (RwjuertSecu.. Pty MIP traffic, aHmreq. . No
И Gent (Rrapond Only) Corremxwete normally (unt... No B5»ci>e5ervw(Requli... Rorel IPtrafhc, elweytr*,,. No 1ЁЗ Server (RwjuertSecu.. Pty MIP traffic, aHmreq. . No
IWMesr-!.
IWMesr-!.
Puc. 6.8. Заданные по умолчанию политики IPSec
Puc. 6.8. Заданные по умолчанию политики IPSec
пьютерной политики, а затем в контекстном меню выберите пункт Computer Configuration ф Windows Settings ф Security Settings Ф Local Policies (Настройка компьютера ф Настройки Windows ^ Настройки безопасности Ф Локальные политики). Дважды щелкните на пункте Audit Policy (Политика аудита).
Рис. 6.8. Политики IPSec, установленные по умолчанию
2. Дважды щелкните на записи Audit Logon Events (События регистрации аудита). Под опцией Local Policy Settings (Настройки локальной политики) выберите пункт Audit Success and Failure (Успех или неудача аудита). Щелкните на кнопке <ОК>.
В процедуре 6.2 демонстрируется, каким образом конфигурируются два сервера в составе одного и того же домена с целью установки подключения с помощью протокола IPSec, Один из серверов требует установки протокола IPSec; другой сервер устанавливает соглашение IPSec, если это требуется по месту назначения. Политики, заданные по умолчанию, применяют протокол Kerberos в качестве метода первоначальной аутентификации, а также могут устанавливать соглашение с контроллером домена Windows 2000, не обращая дополнительного внимания на параметры безопасности.
Процедура 6.2. Присваивание политик безопасности IPSec
Находясь на одном компьютере (Banshee) дважды щелкните на значке IP Security Policy (Политика IP-безопасности), находящемся в левой панели консоли ММС. Правой кнопкой мыши щелкните на опции Secure Server (Защищенный сервер) и в контекстном меню выберите опцию Assign (Присвоить).
На другом компьютере (Athlon) правой кнопкой мыши щелкните на значке Client (Клиент) и в контекстном меню выберите опцию Assign (Присвоить).
НаходясьнакомпьютереAthlon,протестируйтекомпьютерBanshee,послечего
отобразится отклик, говорящий о том, что достигнуто соглашение IPSec.
В окне IPSec Monitor (Монитор IPSec) отображается соглашение по безопасности, заключенное между этими двумя системами (рис. 6.9).
Просмотрите окно приложения Event Viewer (Просмотр событий) и подтвердите, что в перечень попала запись, сообщающая об успешном достижении соглашения. Она может иметь следующий вид:
Просмотрите окно приложения Event Viewer (Просмотр событий) и подтвердите, что в перечень попала запись, сообщающая об успешном достижении соглашения. Она может иметь следующий вид:
6.9. Мониторинг трафика
IKE security association
Mode: Key Exchange ModeMode)
Peer Identity:
based Identity:
Peer IP Address: 10.0.2.55
Filter:
Source IP Address 10.0.2.55
Source IP Address Mask
Destination IP Address 10.0.2.50
Destination IP Address Mask
Protocol 0
Source Port 0
Destination Port 0
Parameters:
ESPAlgorithm DES CBC
Algorithm SHA
Lifetime (sec)
После инициализации процесса, связанного с соглашением по безопасности, протестируйте компьютер Athlon, что должнок успеху,
Если результаты тестирования неутешительными, может возникнуть не
обходимость в повторном запуске службы IPSec Policy Agent (Агент политики IPSec). Просмотрите окно Event Viewer (Просмотр событий), гдепомешаться сле-
сообщение:
Received 100in the clear from 10.0.2.50 which
should have been secured. This could be a temporary
glitch; if it persists please stop and restart the IPSec
Policy Agent service on this machine.
Если отображается подобное сообщение, заново запустите службу iPSec Policy Agent (Агент политики IPSec). Если подобный подход не решает проблемы, дважды щелкните на настройках политик.
Если один из компьютеров сконфигурирован с учетом использования протокола IPSec, система, использующая протокол IPSec, всегда инициирует зашифрованное подключение.
Создание пользовательской политики IPSec
Во многих ситуациях сетевой дизайн или требования системы безопасности требуют применения пользовательской политики IPSec. Зачастую проблемы возникают в случае, если требуется установить безопасное подключение, а компьютеры не принадлежат одному и тому же домену. После определения зон безопасности в сети необходимо на базе этого плана создать пользовательские политики IPSec.
В процедуре 6.3 подробно описывается, каким образом создается пользовательская политика, соответствующая плану зон безопасности в сети.
Процедура 6.3. Создание новой политики
Находясь напервомкомпьютере,вправой панели ММСщелкнитеправойкнопкоймы
ши, затем выберите опцию Create IP Security Policy (Создать политику IP-безопасности). Находясь на входном экране мастера, щелкните на кнопке <Next> (Далее).
Присвойте имя политике IPSec, Test Policy, затем щелкните на кнопке <Next> (рис. 6.10).
Отмените установку флажка Activate the Default Response Rule (Активизировать ответную роль, заданную по умолчанию), в результате чего для данной политики можно будет определить пользовательское правило. Затем щелкните на кнопке <Next>.
Удостоверьтесь в том, что установлен флажок Edit Properties (Изменить свойства), затем щелкните на кнопке <Finish> (Готово).
Рис. 6.10. Создание пользовательской политики IP-безопасности
Удостоверьтесь в том, что установлен флажок Add Wizard (Мастер установки) и щелкните на кнопке <Add> (Добавить) для запуска мастера Add New Rule Wizard (Мастер добавления новой роли). Находясь в начальном экране мастера. щелкните на кнопке <Next>.
Сохраните заданную по умолчанию настройку This Rule Does Not Specify a Tunnel (Правило не определяет туннель) (рис. 6.11). Затем щелкните на кнопке <Next>.
Сохраняйте заданную по умолчанию настройку All Network Connections (Все сетевые подключения) и щелкните на кнопке <Next>.
Выберите метод аутентификации. Правило поддерживает следующие три возможности:
Kerberos. Протокол Kerberos задан по умолчанию в Windows 2000, и если все участники находятся в одном домене, это будет лучшим вариантом, поскольку облегчается конфигурирование.
Безопасность, основанная на применении сертификатов. Можно использовать сертификаты для инициализации ассоциации безопасности. Они совместимы со многими системами сертификации, включая Microsoft, Entrust, VeriSign и Netscape.
Предварительно совместно используемая строка. Использование предварительно совместно используемых строк является наиболее нежелательным методом обеспечения безопасности. Если строка будет сфальсифицирована, невозможно гарантировать конфиденциальность. Однако подобный метод можно использовать в том случае, если поддерживаются внешние операционные системы или устройства.
Поскольку домен HappyVPN представляет автоматически развертываемые компьютерные сертификаты, выберите опцию Certificates ^ Browse (Сертификаты Ф Просмотр), затем выделите соответствующий сертификат (рис. 6.12). После этого щелкните на кнопке <Next>.
Ал FS«c MrM Mow pecMli lotKW e tM*c <i prwMn ntemefwc* Mf >•« «•Wt, level d ■ *■.< pw*e cqrretSerx h*W two orplrtАл FS«c MrM Mow pecMli lotKW e tM*c <i prwMn ntemefwc* Mf >•« «•Wt, level d ■ *■.< pw*e cqrretSerx h*W two orplrt$O«cA< *■ kxnei «ndcwi *» th* У «едя* mi$O«cA< *■ kxnei «ndcwi *» th* У «едя* mil* Th» в***1пбй x*c#, ekrvMl* Th» в***1пбй x*c#, ekrvM<* IheMrwiorxtiort в KXiee hr **• Fedden<* IheMrwiorxtiort в KXiee hr **• FeddenAuthenikatixHi Method
Ал FS«c MrM Mow pecMli lotKW e tM*c <i prwMn ntemefwc* Mf >•« «•Wt, level d ■ *■.< pw*e cqrretSerx h*W two orplrt
Ал FS«c MrM Mow pecMli lotKW e tM*c <i prwMn ntemefwc* Mf >•« «•Wt, level d ■ *■.< pw*e cqrretSerx h*W two orplrt
$O«cA< *■ kxnei «ndcwi *» th* У «едя* mi
$O«cA< *■ kxnei «ndcwi *» th* У «едя* mi
l* Th» в***1пбй x*c#, ekrvM
l* Th» в***1пбй x*c#, ekrvM
<* IheMrwiorxtiort в KXiee hr **• Fedden
<* IheMrwiorxtiort в KXiee hr **• Fedden
T о «У molhpk euihenticMon method], etii the rtfti^plutoMereomoleiirfllhe
ijjdijjdSei If* HHete^hertiMeion inethedtor**; :ecuiiyi* ^* Wreow* 2OQ3 OHM* lteber-1 "Л.огс*«г4
ijjd
ijjd
[CMhedaB*ioW*er^h«ix|r-nN ML $HN l<
"3"3Put. 6.11. Конечная точка туннеля отсутствуетPut. 6.11. Конечная точка туннеля отсутствуетРис. 6.12. Использование сертификата в качестве метода аутентификацииРис. 6.12. Использование сертификата в качестве метода аутентификацииСfflhfl topmiec? B>*S* егЬ^^^ммжгкв^
"3
"3
Put. 6.11. Конечная точка туннеля отсутствует
Put. 6.11. Конечная точка туннеля отсутствует
Рис. 6.12. Использование сертификата в качестве метода аутентификации
Рис. 6.12. Использование сертификата в качестве метода аутентификации
Протокол IPSec требует наличия сертификата
Если в вашей среде отсутствует сервер сертификатов, компания Microsoft в целях тестирования поддерживает доступ к серверу сертификации по адресу h t tp: // sectestcal.rte.microsoft.com. Для того чтобы воспользоваться этим сервером, выполните следующие шаги.
Выберите пункт Standalone Root (RSA 2048) (Автономный корень). Обратите внимание, что RS/i представляет собой аббревиатуру, состоящую из имен трех специалистов в области шифрования: Рона Ривеста (Ron Rivest), Ади Шамира (Adi Shamir) и Леонарда А1де.мана (Leonard Aldeman). Они в 1978 году втроем внедрили очень сложный двухключевои (асимметричный) алгоритм шифрования данных, который в настоящее время является заданным по умолчанию стандартом асимметричного шифрования.
Запросите сертификат и щелкните на кнопке <Next> (Далее).
Выберите пункт Advanced Request (Расширенный запрос) и щелкните на кнопке <Next>.
Выполните запрос сертификата, используя форму.
Установите флажок Use Local Machine Store (Использовать хранилище локального компьютера).
Щелкните на кнопке < Submit* (Выполнить).
Выберите опцию Install This Certificate (Установить сертификат).
В качестве части новой политики IPSec сначала нужно создать перечень IPSec Filter (Фильтры IPSec). Процедура 6.4 основана на предыдущих процедурах, среди которых имеется и процедура по созданию списка фильтров.
Процедура 6.4. Конфигурирование списка фильтров IPSec
В списке IP Filter (IP-фильтры) щелкните на кнопке <Add> (Добавить). Присвойте новому списку фильтров имя Test Policy Filter List (рис. 6.13).
Удостоверьтесь в том, что установлен флажок Use Add Wizard (Использовать мастер установки) и щелкните на кнопке <Add> (Добавить). Для продолжения щелкните на кнопке <Next> (Далее).
В раскрывающемся списке выберите опцию My IP Address (Мой IP-адрес). Щелкните на кнопке <Next>.
Puc. 6.13. Именование списка фильтров политикиPuc. 6.13. Именование списка фильтров политикиВыберите определенный IP-адрес из раскрывающегося списка, а затем введите адрес TCP/IP второго компьютера (рис. 6.14). Щелкните на кнопке <Next>.
Puc. 6.13. Именование списка фильтров политики
Puc. 6.13. Именование списка фильтров политики
IP Тм№ь O«t<*iM№n
Sped/ he definition eddien Ы Ihe IP uaflic
ti«**ui *t»*e
«*Ado**- | ie . a " g . ba
<B** I H^T ] Cev* J<B** I H^T ] Cev* JSu»#w*e* |. ^b'j
<B** I H^T ] Cev* J
<B** I H^T ] Cev* J
Puc. 6.14. Определение адреса назначения
Сохраните заданную по умолчанию настройку Any Protocol (Любой протокол) и щелкните на кнопке <Next>.
Щелкните на кнопке <Finish> (Готово), а затем щелкните на кнопке <Close> (Закрыть) для завершения работы мастера.
Теперь новый фильтр появляется в списке Filter (Фильтр). Выберите переключатель, находящийся возле опции Test Policy Filter List (Тестирование списка фильтров политики). Щелкните на кнопке <Next>.
После создания списка фильтров для новой политики IPSec потребуется определить действия, выполняемые с помощью этих фильтров. Процедура 6.5 демонстрирует методику конфигурирования действия фильтров IPSec.
Процедура 6.5. Конфигуирование действия фильтра IPSec
Удостоверьтесь в том, что установлен флажок Use Add Wizard (Использовать мастер установки) и щелкните на кнопке <Add> (Добавить).
Щелкните на кнопке <Next^- (Далее).
Присвойте действию фильтра IPSec имя Test IPSec Policy Filter Action. Щелкните на кнопке <Next>.
На экране Filter Action General Options (Общие параметры действия фильтра) сохраните заданные по умолчанию настройки Negotiate Security (Соглашение о безопасности) и щелкните на кнопке <Next>.
Сохраните заданную по умолчанию настройку Do Not Communicate with Computers That Do Not Support IPSec (He подключаться к компьютеру, который не поддерживает IPSec). Затем щелкните на кнопке <Next>.
Сохраните заданную по умолчанию настройку Encapsulated Secure Payload (Инкапсулировать полезную нагрузку безопасности). Таким образом будет шифроваться весь трафик. Щелкните на кнопке <Next>.
Щелкните на кнопке <Finish> (Готово).
Выберите переключатель опции Test IPSec Policy Filter Action (Проверить действие фильтра политики IPSec) и щелкните на кнопке <Next>.
Щелкните на кнопке <Finish>.
Щелкните на <Close> (Закрыть) для сохранения настроек.
Таким образом, завершается конфигурирование первого компьютера. Второй компьютер конфигурируется аналогичным образом, с внесением соответствующих изменений в IP-адрес на шагах 3 и 4 процедуры 6.4.
Установка туннеля IPSec между двумя узлами
Обычно, если создаются каналы связи для филиалов офисов, сети желательно основывать на базе двунаправленных каналов связи L2TP/IPSec, установленных между узлами. Вполне вероятно, что некоторые из ваших филиалов офисов включают устройства, которые еще не поддерживают протокол L2TP/IPSec, В этом случае необходимо сконфигурировать туннель IPSec. В рассматриваемом примере в качестве устройства филиала офиса используется система, отличная от Windows 2000. В качестве подобного устройства может выступать сервер любого типа или сетевое устройство. Для конфигурирования туннеля IPSec необходимо следовать инструкциям различных производителей других устройств. Но это устройство должно совпадать с устройством, подключенным к компьютеру, где выполняется Windows 2000, независимо от типа устройства, применяемого для осуществления связи.
Чтобы создать канал связи типа "шлюз-шлюз", обеим сторонам должны присваиваться статические IP-адреса. В рассматриваемом примере оба граничных сервера являются серверами Windows 2000, однако, желательно, чтобы на одном из шлюзов выполнялась сторонняя операционная система. В проекте HappyVPN этот прием применяется для обеспечения связи узла KnoxRoute с узлом EastOakRidge. Оба этих узла имеют частные сети, IP-адреса которых находятся в диапазоне 10.0.X.0.
Первым шагом является конфигурирование на обеих системах подключенных модулей MMC, благодаря чему значительно облегчается навигация в окнах управляющих программ. Для облегчения конфигурирования туннеля удобнее всего настроить пользовательскую комбинацию подключаемых модулей MMC. В процедуре 6.6 демонстрируется, каким образом можно добиться положительного результата.
Процедура 6.6. Конфигурирование системных подключаемых модулей ММС
Щелкните на пунктах меню Start cO Run (Пуск ^ Выполнить) и в отобразившемся окне введите команду ММС. Затем щелкните на кнопке <OK>.
Щелкните на кнопке <Add> (Добавить) и выполните команду Certificates Computer Account (Сертификаты Учетная записьЩелкните на кнопкевыберитеLocal Computer (Локальный компьютер), затем
на кнопке <Finish> (Готово).
Выберите опцию Computer Management (Управлениещелкните на кнопке
<Add>, затем выберите опцию Local Computer (Локальный компьютер) и щелкните на кнопке(Готово).
Выберите опцию Group Policy (Групповая политика) и щелкните на кнопке <Add> (Добавить). Удостоверьтесь в том, что выбрана опция Local Computer (Локальный компьютер), ина кнопке <Finish>.
Закройте окно Add Snap-In (Добавить оснастку). Удостоверьтесь в том, что подключаемые модули были установлены, и щелкните на кнопке <ОК>.
Поскольку политика для филиала офиса будет пользовательской, необходимо выполнить ее создание. Необходимая методика описывается в процедуре 6.7.
Процедура 6.7. Создание новой политики
Выбрав опцию Local Computer Policy (Политика локального компьютера), дважды щелкните на опциях Windows SettingsSecurity Settings (Настройки WindowsНа
стройки безопасности), затем выберите опцию IP Security Policies on Local Machine (Политики IP-безопасности на локальном компьютере).кнопкой мыши
щелкните на правой панели и в контекстном меню выберите опцию Create New IP Security Policy (Создать новую политику IP-безопасности) (рис.
/J. Создание пользовательской политики
В окне мастера IP Security Policy Wizard (Мастер политики IP-безопасности) щелкните на кнопкеНазовите политику так, чтобы администратор мог
легко ееи затем щелкните на кнопке
Отмените заданное по умолчанию правило отклика в IP Security Policy (Политика IP- безопасности). Щелкните на кнопке
Удостоверьтесь в том, что не установлен флажок Edit Policy Properties (Свойства менения политики), и щелкните на кнопке <Finish> (Готово).
В процедуре 6.8 описывается, каким образом создается списокреали-
поддержку туннелямежду узлами.
Процедура 6.8. Создание нового списка фильтров, используемого для инициализации туннеля отк
Правой кнопкой мыши щелкните на правой панели и выберите опцию ManageFilter
Usts and Filter Actions (Управлять спискамиидействиями фильтров) (рис.
Выберите опцию Add New Filter List (Добавить новый список фильтров).
7.-7.-' i 'бfcraolett*D ы| ftcffcfti|Name ;SII у) Cownunkete normally (uns.., No~NoFor elForIPNo' i 'бfcraolett*D ы| ftcffcfti|Name ;SII у) Cownunkete normally (uns.., No~NoFor elForIPNoILJ Сомой Root•Poky-I iti "_J Software Settings B Q Windows SettingsILJ Сомой Root•Poky-I iti "_J Software Settings B Q Windows SettingsСIPSecEd Secure Server (R«jjr. fejseiverСIPSecEd Secure Server (R«jjr. fejseiver; e; eScitols (St artup/ShutdoA ^Seccrty SettingsЛ* LS Local Poides$ LjPJAcKeyPolld»Д iPSetutyPokiMOfScitols (St artup/ShutdoA ^Seccrty SettingsЛ* LS Local Poides$ LjPJAcKeyPolld»Д iPSetutyPokiMOf№ ijj Adrrirtsttative Templates ?» 4H '^v Cohfkauratlon-№ ijj Adrrirtsttative Templates ?» 4H '^v Cohfkauratlon-Оoete j? Security PokyОoete j? Security Poky
7.-
7.-
' i 'бfcraolett*D ы
| ftcffcfti
|Name ;SI
I у) Cownunkete normally (uns.., No~
No
For el
ForIPNo
' i 'бfcraolett*D ы
| ftcffcfti
|Name ;SI
I у) Cownunkete normally (uns.., No~
No
For el
ForIPNo
ILJ Сомой Root
•
Poky
-
I iti "_J Software Settings B Q Windows Settings
ILJ Сомой Root
•
Poky
-
I iti "_J Software Settings B Q Windows Settings
С
IPSec
Ed Secure Server (R«jjr. fejseiver
С
IPSec
Ed Secure Server (R«jjr. fejseiver
; e
; e
Scitols (St artup/ShutdoA ^Seccrty Settings
Л
* LS Local Poides
$ LjPJAcKeyPolld»
Д iPSetutyPokiMOf
Scitols (St artup/ShutdoA ^Seccrty Settings
Л
* LS Local Poides
$ LjPJAcKeyPolld»
Д iPSetutyPokiMOf
№ ijj Adrrirtsttative Templates ?» 4H '^v Cohfkauratlon
-
№ ijj Adrrirtsttative Templates ?» 4H '^v Cohfkauratlon
-
Оoete j? Security Poky
Оoete j? Security Poky
Ы—-1—,——-—J -t!
of
.списками
Назовите этот фильтр таким образом, чтобы администраторы могли легко его идентифицировать. В данном примере используются название KnoxRoute
to EastOakRidge (имя_подсети), как показано на рис. 6.17.
Щелкните на кнопке(Добавить) для запуска мастера IPWizard (Мастер
IP-фильтров) и затемна кнопке(Далее), Выделите определенную
IP-подсеть для использования в качестве источника. Определите подсеть, которая является локальной для граничного сервера. Затем удостоверьтесь в том, что была изменена корректная маска подсети. Щелкните на кнопке
Выберите определенную IP-подсеть для использования в качестве сети назначения. Снова удостоверьтесь в том, что маска подсети корректно задана для данной сети. Шелкните на кнопке
ВыберитеAny IP Protocol Type (Любой тип IP-протокола). Это приведет к
инициализации туннеля слюбогокоторый располагает адре
сом подсети места назначения.
Установите флажок Edit Properties (Изменить свойства) и щелкните на кнопке (Готово).
Отмените установку флажка Mirrored (Зеркальный), поскольку к туннельным фильтрам не применяется отражение (рис. 6.18),
Щелкнитенавкладке Description(Описание)и введитетоназвание,котороеис
пользовалось для наименования фильтра. Такой подход поможет другим пользователям идентифицировать данный туннель при использовании инструментов проведения мониторинга. Щелкните на кнопке <0К>.
Поскольку KnoxRoute из проекта HappyVPN может размешаться в четырех подсетях, для добавления дополнительных адресов источников необходимо повторить шаги 1-8. Щелкните на <С1о5е>(Закръпъ) для сохранения результатов работы.
Процедура 6.9 показывает, каким об
разом создается список фильтров для ус
тановки туннеля IPSec между узлами в обратном направлении.
Рис. 6.17. Именование списка фильтровРис. 6.18. Отмена выбора опции MirroredРис. 6.17. Именование списка фильтровРис. 6.18. Отмена выбора опции MirroredПроцедура 6.9. Создание нового списка фильтров для получения доступа к туннелю, установленному между EastOakRidge и KnoxRoute
Рис. 6.17. Именование списка фильтровРис. 6.18. Отмена выбора опции Mirrored
Рис. 6.17. Именование списка фильтровРис. 6.18. Отмена выбора опции Mirrored
Щелкните на кнопке <Add> (Добавить) снова для добавления другого нового фильтра.
Присвойте этому фильтру то же самое имя, которое легко идентифицируется администраторами. В данном примере фильтр проложен от EastOakRidge (имя_подсети) до KnoxRoute (имя_подсети), как показано на рис. 6.19.
Щелкните на кнопке <Add> для запуска мастера IP Filter Wizard (Мастер IP-Фильтра) и шелкните на кнопке <Next> (Далее). Выделите определенную IP-подсеть для источника. Укажите подсеть, которая является локальной для граничного сервера. Удостоверьтесь в том, что в корректную маску подсети внесены изменения. Щелкните на кнопке <Next>.
Выделите определенную IP-подсеть для целевой сети. Снова удостоверьтесь в том, что маска подсети корректна для этой сети. Щелкните на кнопке <Next> (Далее).
Выберите опцию Any IP Protocol Type (Любой тип IP-протокола). В этом случае туннель инициируется с помощью протокола, для которого местом назначения является спроектированная целевая подсеть.
Установите флажок Edit Properties (Изменить свойства) и шелкните на кнопке <Finish> (Готово).
Отмените установку флажка Mirrored (Отраженный), поскольку туннельные фильтры не могут отражаться.
Щелкните на вкладке Description (Описание) и введите то же самое название, которое применялось для имени фильтра. Это поможет идентифицировать туннель с помощью инструментов, используемых для осуществления мониторинга. Щелкните на кнопке <ОК=>.
Рис. 6.19. Списки Новых добавляемых фильтров
Для поддержки четырех подсетей Knox Route, необходимо повторить процедуру 6.9 для каждой из целевых подсетей. После завершения этой процедуры щелкните на кнопке <Close> (Закрыть) для выполнения сохранения. Можно сконфигурировать структуру маршрутизации, которая позволит избежать этого, но в данном примере отдельные подсети добавляются вручную.
После определения фильтров создается действие фильтра для туннеля IPSec, установленного между этими узлами, как описывается в процедуре 6.10.
Процедура 6.10. Создание метода действия фильтра с целью обеспечения безопасноституннеля
Выберите вкладку Manage Filter Actions (Управление действиями фильтра). Заданные по умолчанию действия фильтра не будут ПОДХОДЯЩИМИ для IPSec, поскольку все они позволяют поддерживать незащищенный трафик (рис. 6.20).
Для создания нового действия выберите команду <Add> (Добавить). После этого запустится мастер Filter Action Wizard (Мастер действия фильтра). Щелкните на кнопке <Next> (Далее) и именуйте действие таким образом, чтобы его легко можно было идентифицировать администратору. Щелкните на кнопке <Next>,
Удостоверьтесь в том, что выбрана опция Negotiate Security (Соглашение о безопасности) и щелкните на кнопке <Next>.
Удостоверьтесь в том, что установлен флажок Do Not Communicate with Computers That Do Not Support IPSec (He устанавливать связь с компьютерами, не поддерживающими протокол IPSec) и щелкните на кнопке <Next> (рис. 6.21).
Выберите уровень безопасности для IP-трафика (рис. 6.22). В большинстве конфигураций может применяться уровень безопасности High (Высокий) (ESP), но если ваша сеть нуждается в специальных настройках безопасности, их можно конфигурировать с помощью пользовательских настроек. Не используйте уровень безопасности Medium (Средний), поскольку в этом случае трафик не будет шифроваться. Щелкните на кнопке <Next>.
Установите флажок Edit Properties (Изменить свойства) и щелкните на кнопке <Finish> (Готово).
IP
UntugolPFitaljia Montoe File Aciws |
to
descibe the tec-j+p ci дм глЫЖ.
we sharedIP
pofcw
fie# Ache# w
HmmD*»oif<rjn
FermiPermit unsecured IP packets to...
Request Security [Optional)Accepts unsecuredcommunrcali.
toflommurieahontoflommurieahon* porwce»irex>oe eirn<npwi ihwdDr>a »ct»* f#*>4c[Г I'd b*Mtye»cne< <■**<*»**#<••1doIPS«fo#hin#»^-*irr> * MMWJ WB Ihwdn w. Mjpfwc f^mr. hw o,4*w #ou г*^щ toiecni^riekt* porwce»irex>oe eirn<npwi ihwdDr>a »ct»* f#*>4c[Г I'd b*Mtye»cne< <■**<*»**#<••1doIPS«fo#hin#»^-*irr> * MMWJ WB Ihwdn w. Mjpfwc f^mr. hw o,4*w #ou г*^щ toiecni^riektAdd . I £*■■ | а«ехпч [ p Uw«dd^itedI | 1|Add . I £*■■ | а«ехпч [ p Uw«dd^itedI | 1|<»«* I »MI I C«N I<»«* I »MI I C«N IReoube SeemlyAttWU unseouJed comrniriicab.
toflommurieahon
toflommurieahon
* porwce»irex>oe eirn<npwi ihwdDr>a »ct»* f#*>4c[
Г I'd b*Mtye»cne< <■**<*»**#<••
1doIPS«
fo#hin#»^-*irr> * MMWJ WB Ihwdn w. Mjpfwc f^mr. hw o,4*w #ou г*^щ toiecni^riekt
* porwce»irex>oe eirn<npwi ihwdDr>a »ct»* f#*>4c[
Г I'd b*Mtye»cne< <■**<*»**#<••
1doIPS«
fo#hin#»^-*irr> * MMWJ WB Ihwdn w. Mjpfwc f^mr. hw o,4*w #ou г*^щ toiecni^riekt
Add . I £*■■ | а«ехпч [ p Uw«dd^ited
I | 1|
Add . I £*■■ | а«ехпч [ p Uw«dd^ited
I | 1|
<»«* I »MI I C«N I
<»«* I »MI I C«N I
Puf. tfA Выбор методабезопасно-дляPuf. tfA Выбор методабезопасно-дляРис. 6.23. Блокирование незащищенногоРис. 6.23. Блокирование незащищенного
Puf. tfA Выбор методабезопасно-
для
Puf. tfA Выбор методабезопасно-
для
Рис. 6.23. Блокирование незащищенного
Рис. 6.23. Блокирование незащищенного
Добавление действия к новомуДобавление действия к новомуРис. 6.21. Определение порядка подключения к компьютерам, не поддерживающим протокол IPSec
Добавление действия к новому
Добавление действия к новому
If
Т
к
The *• ee*#t «MuMi * MW •» W*M> WTed te F ►*■
*811Ё6ййта*гйЯ
Dwe n! tw «гоум»! MjweuiU »щ ^гепоУес
C Se*r.*A**<eiedHe*|
Эм f4te а#*МБ rrftfwdW кН wl nee bi wwxitei
Отмените установку флажка Accept UnsecuredBut Always Respond
Using IPSecно при этом всегда использовать прото
кол IPSec) (рис. 6.23). В этом случае устанавливается более высокий уровень безопасности, который применяется ко всему трафику. Для сохранения результатов выполненных действийна кнопках <ОК> и <Close> (Закрыть).
Затем требуется определить правила туннеля IPSec, установленного между двумя узлами. Используемый в этом случае алгоритм реализован спроцедуры
Процедура 6.11. Создание новых правил для политики
Правой кнопкой мыши щелкните на имени новой политики и в контекстном меню выберите опцию Properties (Свойства). На странице Properties удостоверьтесь в том, что установлен флажок Use Add Wizard (Использовать мастер приложений) и щелкните на кнопке <Add> (Добавить).
НаэкранеAddSecurityRule (Добавитьправилобезопасности)щелкнитенакнопке
<Next> (Далее). С помощью туннелей IPSec требуется определить конечную точку туннеля. Введите внешний IP-адрес целевого шлюза, завершающего туннель. Затем щелкните на кнопке <Next>
Данная система имеет несколько типов подключений, поэтому для использования сетевого типа подключения установите флажок Local Area Network (LAN) (Локальная сеть (ЛВС)). Щелкните на кнопке <Next>.
Выберите подходящий метод аутентификации. Сущестует техническая возможность использования протокола Kerberos для туннеля IPSec, однако, контроллер домена Windows 2000 должен присутствовать с двух сторон туннеля. Однако в большинстве конфигураций безопасность основана на применении сертификатов. Эти сертификаты должны развертываться на концах туннеля IPSec перед его развертыванием. Если у стана вл ивается подключение к шлюзу, который не поддерживает сертификаты, можно применить предварительный общий ключ. Выберите опцию Certificate (Сертификат) и щелкните на кнопке <Browse> (Просмотр). Найдите и выделите тот сертификат, который использовался для данного подключения (рис. 6.24) и щелкните на кнопке <ОК>. Затем щелкните на кнопке <Next>.
Выберите список фильтров, которые используются из локального шлюза для целевого шлюза (определен на шаге 2). Щелкните на кнопке <Next>,
rlr<t LenNMdlrивrlr<t LenNMdlrивРис. 6.25. Выбор подходящего действия фильтраРис. 6.25. Выбор подходящего действия фильтраВыделите действие фильтра, которое определено для рассматриваемого туннеля (рис. 6.25). Затем щелкните на кнопке <Next>.
rlr<t LenNMdlrив
rlr<t LenNMdlrив
Рис. 6.25. Выбор подходящего действия фильтра
Рис. 6.25. Выбор подходящего действия фильтра
SelecttheCwtlfketfiAuthcxtyt^M you reqwflfor IPSec Authentic uticn when mingthii security riie.
iMuedto ~_ J kMby J inten*,.. | Frtir^^
L/jwrrtSqn Trust fjetw.VeriSign..Secure E„,vareyn...6/1/202»
ISveriSIgnTrustNetw...VeriSign...SecureE. .Ve*Bgn .5/18/201
QUTNxl$eRfHt41er..UTN-U5...ServarA,..UTN-U..7/9/201»
г^5«*.лв51у|ко(АСА2Secures,..SecureE...Japan C. .9/15/202
OK Cent J Sow Cetr «t»JOK Cent J Sow Cetr «t»JРис. 6.24. Выбор подходящего сертификатаРис. 6.24. Выбор подходящего сертификата1У Certiegn Autor oed.. ,CertMgn...Secure E...CertSlgn...6/26/ZOl |
OK Cent J Sow Cetr «t»J
OK Cent J Sow Cetr «t»J
Рис. 6.24. Выбор подходящего сертификата
Рис. 6.24. Выбор подходящего сертификата
Щелкните на кнопке <Finish> (Готово).
Вернитесь к окну IPSec Tunnel Properties (Свойства туннеля IPSec) для определения другого правила, применяемого по отношению к входящему туннелю IPSec. Щелкните на кнопке <Add> (Добавить) снова для выполнения этой операции. В окне мастера Security Rule Wizard (Мастер безопасности ролей) щелкните на кнопке <Next> и определите внешний адрес для локального шлюза входящего туннеля. Снова щелкните на кнопке <Next>.
Установите флажок Local Area Network (LAN) (Локальная вычислительная сеть (ЛВС)). Щелкните на кнопке <Next>.
Выберите соответствующий метод аутентификации. В проекте HappyVPN используется безопасность на основе сертификатов, поэтому щелкните на кнопке <Browse> (Просмотр), выберите локальный сертификат и щелкните на кнопке <ОК>. По возвращении к окну Rule Wizard (Мастер правил) щелкните на кнопке <Next>.
П. Выберите фильтр, который определен по направлению от целевого шлюза к локальному шлюзу. Это выполняется для входящих туннельных подключений.
Выберите действие фильтра, которое определено предварительно для туннеля [PSec (рис. 6.25).
Щелкните на кнопке <Finish>, затем щелкните на кнопке <Close> (Закрыть). Не назначайте эту политику в данный момент времени.
Конфигурирование целевого шлюза
На другой стороне подключения "шлюз-шлюз" необходимо определить аналогичную политику IP-безопасности. В этом случае обе граничных системы инициируют связь и получают доступ к туннелю. На этот момент времени была сконфигурирована одна сторону туннеля, теперь необходимо перейти к конфигурированию другой его стороны. Если речь идет о посторонней операционной системе, следуйте процедуре, специфичной для этой операционной системы. В данном примере на иной стороне туннеля установлен другой сервер Windows 2000. Шаги по выполнению этой конфигурации перечислены в процедуре 6.12.
Процедура 6.12. Создание новой политики IPSec
Получив предварительный доступ к опции Local Computer Policy (Политика локального компьютера), дважды шелкните на пункте Windows Settings (Настройки Windows), затем выберите пункты меню Security Settings ^ IP Security Policies on Local Machine (Настройки безопасности Cv Политики IP-безопасности на локальном компьютере). Правой кнопкой мыши шелкните в правой панели и выберите опцию Create New IP Security Policy (Создать новую политикуIP-безопасности).
Находясь в окне мастера IP Security Policy Wizard (Мастер политики IP-безопасности) шелкните на кнопке <Next> (Далее). Назовите политику таким образом, чтобы администратор мог легко ее идентифицировать, затем шелкните на кнопке <Next>.
ОтменитевыборзаданногопоумолчаниюправилаоткликадляполитикиIP-
безопасности. Затем шелкните на кнопке <Next>.
Удостоверьтесь в TOM, что не установлен флажок Edit Policy Properties (Изменение свойств политики), затем щелкните на кнопке <Finish> (Готово).
Правой кнопкой мыши щелкните в правой панели, затем в контекстном меню выберите пункт Manage IP Filter Lists and Filter Actions (Управлять списками IP- фильтров идействиями фильтров).
Установите флажок Add New Filter List (Список добавления нового списка фильтров).
Назовите фильтр таким образом, чтобы он мог быть легко идентифицирован администратором. В данном примере используется имя EastOakRidge (имя_подсети) to KnoxRoute (имя_подсети), как показано на рис. 6.26.
Рис. 6.26. Ввод названия для списка IP-фильтров
Щелкните на кнопке <Add> (Добавить) для запуска мастера IP Filter Wizard (Мастер IP-фильтров), затем щелкните на кнопке <Next>. Выделите определенную IP- подсеть для этого источника. Определите подсеть, которая является локальной для граничного сервера. Удостоверьтесь в том, что изменена корректная маска подсети. Щелкните на кнопке <Next>.
Выделите определенную IP-подсеть в целевой сети. Снова удостоверьтесь в том, что в этой сети используется корректная маска подсети. Щелкните на кнопке <Next>.
Выберите опцию Any IP Protocol Type (Любой тип IP-протокола). В этом случае туннель инициализируется с помощью любого протокола, для которого в качестве цели используется целевая подсеть.
Установите флажок Edit Properties (Изменить свойства) и щелкните на кнопке <Finish> (Готово).
Отмените установку флажка Mirrored (Отраженный), поскольку туннельные фильтры не могут отражаться.
Щелкните на вкладке Description (Описание) и введите то же самое название, которое было назначено фильтру. После этого можно будет идентифицировать туннель, используя инструментальные средства осуществления мониторинга. Щелкните на кнопке <ОК>.
Поскольку структура сети Knox Route проекта HappyVPN представлена четырьмя подсетями, необходимо повторить процедуру 6.12 для внесения дополнительных исходных адресов. Щелкните на кнопке <Close> (Закрыть) для сохранения результатов изменений. Можно сконфигурировать структуру маршрутизации, которая позволит исключить этот момент, но в данном примере производится ручное добавление отдельных подсетей.
В процедуре 6.13 показывается, каким образом создается список фильтров для противоположного направления туннеля IPSec.
Процедура 6.13. Создание нового списка фильтров для инициализации туннеля от KnoxRoute до EastOakRidge
Правой кнопкой мыши щелкните в правой панели и в контекстном меню выберите пункт Manage IP Filter Lists and Filter Actions (Управление списками IP-фильтров и действиями фильтров).
Установите флажок Add New Filter List (Добавить новый список фильтров).
Присвойте фильтру имя, которое будет легко идентифицироваться администраторами. В данном примере используется имя KnoxRoute (имя_подсети) to EastOakRidge (имя_подсети), как показано на рис. 6.27.
Рис. 6.27. Ввод имени для списка IP-фильтров
Щелкните на кнопке <Add> (Добавить) для запуска мастера IP Filter Wizard (Мастер IP-фильтров), затем щелкните на кнопке <Next>. Выберите определенную IP- подсеть для этого источника. Определите подсеть, которая является локальной для граничного сервера. Удостоверьтесь в том, что была изменена корректная маска подсети. Щелкните на кнопке <Next>.
Выделите определенную JP-подсеть для целевой сети. Снова, удостоверьтесь в том, что для данной сети корректна маска подсети. Затем шелкните на кнопке <Next>.
Выберите опцию Any IP Protocol Type (Любой тип IP-протокола). В этом случае туннель инициализируется с помощью любого протокола, для которого в качестве цели используется целевая подсеть.
Установите флажок Edit Properties (Изменить свойства) и щелкните на кнопке <Finish> (Готово).
Отмените установку флажка Mirrored (Отраженный), поскольку туннельные фильтры не могут отражаться.
Щелкните на вкладке Description (Описание) и введите то же самое название, которое было назначено фильтру. После этого можно будет идентифицировать туннель, используя инструментальные средства осуществления мониторинга. Щелкните на кнопке <ОК>.
Поскольку структура сети KnoxRoute проекта HappyVPN представлено четырьмя подсетями, необходимо повторить процедуру 6.13 для внесения дополнительных исходных адресов. Можно сконфигурировать структуру маршрутизации, которая исключит этот момент, но в данном примере добавление отдельных подсетей производится вручную. После завершения работы шелкните на кнопке <Close > (Закрыть) для сохранения результатов.
Процедура 6,14 позволит выполнить следующий этап, который заключается в создании действия фильтра, применяемого со стороны филиала офиса для туннеля IPSec.
Процедура 6.14. Создание метода действия фильтра с целью обеспечения безопасности туннеля
Выберите вкладку Manage Filter Actions (Управление действиями фильтра). Заданные по умолчанию действия фильтра не соответствуют IPSec, поскольку не приводят к обеспечению зашиты трафика.
Чтобы создать новое действие, выберите команду <Add> (Добавить). В результате запустится мастер Filter Action Wizard (Мастер действия фильтра). Щелкните на кнопке <Next> (Далее) и назовите действие таким образом, чтобы его можно было легко идентифицировать администраторам. Затем снова щелкните на кнопке <Next>,
Подтвердите выбор опции Negotiate Security (Переговоры о безопасности) и щелкните на кнопке <Next>.
\. Подтвердите, что установлен флажок Do Not Communicate with Computers That Do Not Support IPSec (He подключаться к компьютерам, которые не поддерживают IPSec) и щелкните на кнопке <Next>.
Выберите уровень безопасности. Большинство конфигураций могут использовать уровень безопасности High (Высокий) (ESP), но если ваша система нуждается в специальных настройках безопасности, их можно сконфигурировать отдельно. Не используйте уровень безопасности Medium (Средний), поскольку в этом случае трафик не шифруется. Щелкните на кнопке <Next>.
Установите флажок Edit Properties (Изменение свойств) и шелкните на кнопке <Finish> (Готово).
' ' Отмените установку флажка Accept Unsecured Communication, But Always Respond Using IPSec (Допускать незащищенную связь, но при этом всегда использовать протокол IPSec) (рис. 6.28), В этом случае устанавливается более высокий уровень безопасности, который применяется ко всему трафику. Для сохранения результатов выполненных действий щелкните на кнопках <OK> и <Close> (Закрыть).
Рис. 6.28. Блокирование незащищенного трафика
В процедуре 6.15 показывается, каким образом создаются правила для туннеля IPSec на стороне филиала офиса.
Процедура 6.15. Создание новых правил для политики
Правой кнопкой мыши шелкните на имени новой политики и в контекстном меню выберите опцию Properties (Свойства). Находясь на странице Properties (Свойства), удостоверьтесь в том, что установлен флажок Use Add Wizard (Использовать мастер установки), и щелкните на кнопке <Add> (Добавить).
Находясь в окне мастера Add Security Rule Wizard (Мастер добавления ролей безопасности), щелкните на кнопке <Next> (Далее). Конечная точка туннеля должна определяться с помощью туннелей IPSec. Введите внешний IP-адрес для целевого шлюза, завершающего туннель. Снова щелкните на кнопке <Next>.
Данная система имеет несколько типов подключения, поэтому для типа сети выберите опцию Local Area Network (LAN) (Локальная вычислительная сеть (ЛВС)). Затем щелкните на кнопке <Next>.
Выделите опцию Certificate (Сертификат) и щелкните на кнопке <Browse> (Просмотр). Найдите и выделите тот сертификат, который будет применяться для данного подключения, и щелкните на кнопке <ОК>. Затем щелкните на кнопке <Next>.
Выберите список фильтров, которые используются на пути от локального до целевого шлюза (определены на шаге 2). Щелкните на кнопке <Next>.
Выберите действие фильтра для данного туннеля. Щелкните на кнопке <Next>.
Щелкните на кнопке <Finish> (Готово).
Для возврата к окну IPSec Tunnel Properties (Свойства туннеля IPSec) и определения другого правила для входящего туннеля IPSec щелкните на кнопке <Add> (Добавить). После этого запустится на выполнение мастер Security Rule Wizard (Мастер ролей безопасности). Щелкните на кнопке <Next>, определите внешний адрес локального шлюза для входящего туннеля, затем щелкните на кнопке <Next> снова,
Выберите опцию Local Area Network (LAN) (Локальная вычислительная сеть (ЛВС)). Щелкните на кнопке <Next>.
Выберите опцию Certificate-Based Security (Безопасность, основанная на сертификатах), щелкните на кнопке <Browse> (Просмотр), выделите локальный сертификат и щелкните на кнопке <ОК>. После возврата в окно Rule Wizard (Мастер правил) щелкните на кнопке <Next>.
И. Выделите фильтр, который определен на пути от целевого шлюза до локального шлюза. Это выполняется для входящих туннельных подключений (рис. 6.29).
Рис. 6.29. Выбор списка подходящих IP-фильтров
Выделите действие фильтра, который предварительно определен для туннеля IPSec.
Щелкните на кнопках <Finish> (Готово) и <Close> (Закрыть).
Проверка и мониторинг политики IPSec
Важно иметь возможность тестирования и наблюдения за эффектом применения политик IPSec. Эти политики позволяют значительно увеличить гибкость работы, но при работе со сложными сетевыми средами могут обнаружиться недостатки, связанные с непродуманным конфигурированием политик. Удостоверьтесь в том, что фильтры были проверены. Процедура 6.16 содержит шаги, позволяющие выполнить проверку сети.
Процедура 6.16. Проверка политики IPSec
Присвойте новую политику IPSec, используя подключаемый модуль в обеих системах.
Выполните тестирование подключения между компьютерами. При первоначальном выполнении этой операции отображается окно Negotiating IP Security (Договоренность относительно IP-безопасности). Снова выполните тестирование подключения, после чего должен отобразиться успешный отклик второго компьютера (рис. 6.30).
Рис. 6.30. Тестирование подключения с помощью утилиты pingРис. 6.30. Тестирование подключения с помощью утилиты ping
Рис. 6.30. Тестирование подключения с помощью утилиты ping
Рис. 6.30. Тестирование подключения с помощью утилиты ping
Восстановите окно IPSec Monitor и просмотрите подробности соглашения по безопасности, которое установлено между этими компьютерами (рис. 6.31).
Откройте окно Network Monitom просмотрите трафик, установленный между двумя компьютерами (рис. 6.32).
Puc.Puc.др fib Edit йяйу ТО* t^ Wlrdx I*др fib Edit йяйу ТО* t^ Wlrdx I*I21*1»•••• j> tec lUtMir bet НАС M4t _' l-^ctl •, , >h,t_A _ j 6et OtheiAxoo. hollaLrtl-gtALsrjwvu.is»xs.o.i.tisxutwnXIOJT6M1UTI-3lLXirrIOC*!.IS»XO.O111ММГ8Ж11ite.iwmLTti-otixirDtoeu.hiio оt<iемпжнI)о.зюенLXTi eiiAirDlocalis»lo crtibaxbuiAtO.1701ZBlira-OILLSrbLOCALMFAO.O.t.CtВЛЖКВХ1440.Э70И»Xiri-OIALIFDI ОСАХMF40.0.t.MВАЛПП1I21*1»•••• j> tec lUtMir bet НАС M4t _' l-^ctl •, , >h,t_A _ j 6et OtheiAxoo. hollaLrtl-gtALsrjwvu.is»xs.o.i.tisxutwnXIOJT6M1UTI-3lLXirrIOC*!.IS»XO.O111ММГ8Ж11ite.iwmLTti-otixirDtoeu.hiio оt<iемпжнI)о.зюенLXTi eiiAirDlocalis»lo crtibaxbuiAtO.1701ZBlira-OILLSrbLOCALMFAO.O.t.CtВЛЖКВХ1440.Э70И»Xiri-OIALIFDI ОСАХMF40.0.t.MВАЛПП1Захват сетевого трафика с помощьюMonitorЗахват сетевого трафика с помощьюMonitor
Puc.
Puc.
др fib Edit йяйу ТО* t^ Wlrdx I*
др fib Edit йяйу ТО* t^ Wlrdx I*
I21*1
»•••• j> tec lUtMir bet НАС M4t _' l-^ctl •, , >h,t_A _ j 6et OtheiA
xoo. hollaLrtl-gtALsrjwvu.is»xs.o.i.tisxutwn
XIOJT6M1UTI-3lLXirrIOC*!.IS»XO.O111ММГ8Ж11
ite.iwmLTti-otixirDtoeu.hiio оt<iемпжн
I)о.зюенLXTi eiiAirDlocalis»lo crtibaxbui
AtO.1701ZBlira-OILLSrbLOCALMFAO.O.t.CtВЛЖКВХ1
440.Э70И»Xiri-OIALIFDI ОСАХMF40.0.t.MВАЛПП1
I21*1
»•••• j> tec lUtMir bet НАС M4t _' l-^ctl •, , >h,t_A _ j 6et OtheiA
xoo. hollaLrtl-gtALsrjwvu.is»xs.o.i.tisxutwn
XIOJT6M1UTI-3lLXirrIOC*!.IS»XO.O111ММГ8Ж11
ite.iwmLTti-otixirDtoeu.hiio оt<iемпжн
I)о.зюенLXTi eiiAirDlocalis»lo crtibaxbui
AtO.1701ZBlira-OILLSrbLOCALMFAO.O.t.CtВЛЖКВХ1
440.Э70И»Xiri-OIALIFDI ОСАХMF40.0.t.MВАЛПП1
Захват сетевого трафика с помощьюMonitor
Захват сетевого трафика с помощьюMonitor
Активизация регистрации протокола IPSec
Если пользовательские политики не выполняются корректно, может возникнуть необходимость в регистрации согласования безопасности IPSec. Созданный журнал затруднительно просматривать, но в этом случае можно идентифицировать сбой. же, если связаться с центром поддержки, можно получить доступ к весьма полезным сведениям. Более подробная информация по этому поводу содержится в приложении В. Процедурапозволяет ознакомиться с процессом настройкиIPSec.
Процедура 6.17. Настройка регистрации
Выберите пункты меню Start Run (Пуск Выполнить), В отобразившемся окне введите Regedt32 и щелкните на кнопке <ОК> для получения доступа к редактору системного реестра.
Дважды шелкните на ветви
Выберите ключ
Дважды шелкните на опции Policy Agent (Агент
Правой кнопкой мыши шелкните в правой панели, затем в контекстном меню выберите команду Edit Add Key (Правка Добавить ключ).
В качестве имени ключа введите Oakley (обратите внимание на соблюдение регистра символов).
Дважды шелкните на позиции Oakley. Затем правой кнопкой мыши шелкните в левой панели и выполните команду New DWORD ValueЗначение
Введите наименование значения(обратите внимание на соблюдение
регистра символов).
Дважды шелкните на значении и присвойте записи DWORD значение 1 (рис. 6.33). Затем шелкните на кнопке <ОК>,
4П| 2£14П| 2£1й' RvyKtry f <Ыпг
4П| 2£1
4П| 2£1
RegistryEd*
--® UJPerfFrocjl±1PlugPtoyci LJPdcyAgentEnumQ IPSECPofcyStofe•£3 Security•^ ОеИеуE-_J PptpMlniport+® UJPerfFrocjl±1PlugPtoyci LJPdcyAgentEnumQ IPSECPofcyStofe•£3 Security•^ ОеИеуE-_J PptpMlniport+NameName5)Ф*«*)5)Ф*«*)ttUIJIiaililllll REGDWORDttUIJIiaililllll REGDWORDREG.SEREG.SEp(set)0p(set)0••Pi Ptemk3 giiosaPi Ptemk3 giiosaM 3 QilOwnt ft: LJ q<l24C ffi£l qEiooRasAcdКi- 2J ResIZtpM 3 QilOwnt ft: LJ q<l24C ffi£l qEiooRasAcdКi- 2J ResIZtpMy ComputerWyiY.LOCAL _МАСН!НЕ\5¥5ттСиг'ег<1дхт&с1^^My ComputerWyiY.LOCAL _МАСН!НЕ\5¥5ттСиг'ег<1дхт&с1^^
-
-
® UJPerfFrocj
l±1PlugPtoy
ci LJPdcyAgent
Enum
Q IPSECPofcyStofe
•£3 Security
•^ ОеИеу
E-_J PptpMlniport
+
® UJPerfFrocj
l±1PlugPtoy
ci LJPdcyAgent
Enum
Q IPSECPofcyStofe
•£3 Security
•^ ОеИеу
E-_J PptpMlniport
+
Name
Name
5)Ф*«*)
5)Ф*«*)
ttUIJIiaililllll REGDWORD
ttUIJIiaililllll REGDWORD
REG.SE
REG.SE
p
(set)
0
p
(set)
0
•
•
Pi Ptemk
3 giiosa
Pi Ptemk
3 giiosa
M 3 QilOwnt ft: LJ q<l24C ffi£l qEioo
RasAcd
К
i- 2J ResIZtp
M 3 QilOwnt ft: LJ q<l24C ffi£l qEioo
RasAcd
К
i- 2J ResIZtp
My ComputerWyiY.LOCAL _МАСН!НЕ\5¥5ттСиг'ег<1дхт&с1^^
My ComputerWyiY.LOCAL _МАСН!НЕ\5¥5ттСиг'ег<1дхт&с1^^
6.33. Включение регистрации
Перейдите в окно командной строки и введите команду net stop& net
start poticyagent.
Найдите журнал в каталогеlog (рис. 6.34).
Рис. 6.34. Просмотр журнала Oakley
Создание многих политик IPSec
Как видите, создание нескольких политик IPSec требует больших затрат времени. Компания Microsoft в состав инструментального набора Windows 2000 Resource Kit включила средство, предназначенное для облегчения работы с более крупными сетями, позволяя сетевому администратору формировать сценарий процесса, используемого при создании политик.
Инструмент командной строки IPSECPOL позволяет администратору создавать политики IPSec, используя большое число переключателей и опций. Этот инструмент может применяться в двух взаимно исключающих режимах: статическом и динамическом. По умолчанию используется динамический режим.
Динамический режим непосредственно связан с политикой Policy Agent (Агент политики), которая активна только при выполнении службы агента политик. Этот режим не будет активным после повторной зафузки или после того, как запустится служба IPSec, Динамическая политика часто применяется наряду с политикой, основанной на DS.
Если выполняется IPSECPOL, устанавливается правило IPSec, политика IKE или оба этих объекта. При установке политики IPSec в интерфейсе пользователя появляется эквивалент "правил IР-безопасности” ("IP Security Rule"). При определении туннельной политики необходимо дважды выполнять IPSECPOL — один раз для исХОДЯЩИХ фильтров и конечной точки исходящего туннеля, а другой раз для ВХОДЯЩИХ фильтров и конечной точки входящего туннеля.
В статическом режиме создается или обновляется сохраненная политика. Эта политика может быть использована снова и дольше всего сохраняется при активизации деятельности. В статическом режиме используется большая часть синтаксиса, относящегося к динамическому режиму, но и также добавляются возможности, которые позволяют реализовать выполнение на уровне политики. В статическом режиме можно создавать именованные политики и правила.
При определении этих политик с помощью IPSECPOL можно использовать переключатель /? для просмотра справочных данных.
Резюме
В Windows 2000 компания Microsoft внедрила протокол IPSec таким образом, что позволило создать полностью защищенную среду. Протокол IPSec, будучи решением IETF, обладает большими преимуществами. Именно IPSec позволяет Windows 2000 работать с аппаратным обеспечением и другим программным обеспечением, используя зашифрованный формат. В будущем большинство программных продуктов, независимо от того, имеют они отношение к программному или аппаратному обеспечению, будут выпускаться с учетом поддержки протокола IPSec. Это позволит обеспечить безопасность на межплатформенном уровне, что ранее было недостижимо.
7
Протокол туннелирования уровня 2 (L2TP)
Как уже упоминалось в главе 1, протокол туннелирования уровня 2 (L2TP — Layer 2 Tunneling Protocol) был разработан компаниями Microsoft и Cisco с учетом рекомендаций Инженерной группы решения конкретной задачи Internet (IETF - Internet Engineering Task Force). Эти рекомендации были направлены на разработку стандартного протокола. В результате, в процессе разработки протокола L2TP, начиная с 1996 года, компании Microsoft и Cisco заняли лидирующие позиции. Современный вариант протокола L2TP представляет собой комбинацию протокола туннелирования "точка- точка" (РРТР — Point-to-Point Tunneling Protocol) и протокола направления уровня 2 (L2F — Layer 2 Forwarding), разработанного компанией Cisco.
Справедливо утверждение, что протокол РРТР порожден средой Microsoft LAN, a протокол L2F появился благодаря использованию маршрутизаторов и функционированию провайдеров услуг Internet (ISP — Internet service provider). Обе эти спецификации были представлены на рассмотрение группы IETF. Участники группы IETF отметили наличие аналогии между этими двумя технологиями и пришли к выводу о целесообразности использования протокола L2TP, предста мяюшего собой комбинацию протоколов РРТР и L2F. В этой комбинации представлены наиболее удачные возможности как протокола РРТР, так и протокола L2F. Таким образом, исключается возможная конкуренция на рынке двух несовместимых программных продуктов.
Область применения протокола Windows 2000 L2TP/IPSec
При разработке протокола L2TP в составе Windows 2000 компания Microsoft преследовала цель создания стандарта IETF, реализованного в виде межсетевого протокола VPN, обеспечивающего возможности удаленного доступа. Протокол L2TP дополняет протокол РРТР, который рассматривается как патентованный протокол компании Microsoft. Операционная система Windows 2000 позиционируется в качестве наиболее удачной платформы VPN, которая включает следующие программные решения: протокол L2TP, интерфейсы удаленного доступа по требованию, протокол безопасности Internet (IPSec - Internet Protocol Security), службу маршрутизации и удаленного доступа (RRAS — Routing and Remote Access Service), удаленную сетевую обработку (DUN — Dial-Up Networking), диспетчер подключений (Connection Manager) и набор телефонных книг администрирования диспетчера подключений (Connection Manager Administration Kit Phonebooks).
Путем объединения свойств протокола L2TP, основанных на протоколе туннелирования "точка-точка" (РРР — Point-to-Point Protocol), с возможностями по обеспечению безопасности протокола IPSec, компания Microsoft позиционировала на рынке первый клиент VPN. При этом также обеспечивалось серверное решение VPN. Ниже указаны некоторые цели, которые принимались во внимание при разработке протоколов Windows 2000 L2TP/IPSec.
Достижение максимальной степени безопасности при передаче туннельного трафика L2TP. Компания Microsoft постаралась избежать повторения неприятного инцидента, подобного происшедшему в 1998 году. В этом году была опубликована статья, содержащая перечень "слабых мест", характерных для реализации протокола РРТР в Windows NT 4.0.
Наличие в протоколе L2TP изменяющихся уровней безопасности, которые могут взаимодействовать с программными продуктами сторонних производителен на основе подключений. Компания Microsoft при создании Windows 2000 серьезно отнеслась к соблюдению промышленных стандартов. Важно представлять, что даже при использовании обоих стандартов, как L2TP, так и IPSec, конкретная реализация может поддерживать различных клиентов, если они подключились к серверу.
Администраторы имеют возможность легко выбирать соответствующие уровни безопасности даже в том случае, если они не имеют детального представления о функ- [тонировании протокола IPSec. Многие туннельные серверы в настоящее время выполняют Windows NT 4.0 и протокол РРТР, который относительно несложен при реализации. Поскольку протокол L2TP был слишком трудоемким в реализации, все меньше администраторов изъявляют желание перейти от протокола РРТР к протоколу L2TP/IPSec.
Использование в Windows 2000 уже существующей реализации протокола IPSec с целью поддержки служб безопасности. В этом случае упрощается процесс развертывания, а также гарантируется непротиворечивость программного продукта.
Протоколы L2TP и РРТР
Протокол L2TP напоминает протокол РРТР, поскольку предназначен для реализации удаленного доступа. Однако протокол L2TP не пытается выполнять проверку собственной безопасности. Вместо этого используется транспортный режим инкапсуляции нагрузки безопасности IPSec (ESP — IPSec Encapsulating Security Payload). Эта особенность протокола L2TP является весьма полезной, поскольку IPSec в настоящее время фактически является промышленным стандартом и представляет собой органическую часть стека протокола TCP/IP, относяшегося к базовым операционным системам. Вследствие широкой распространенности этого протокола весьма нежелательно появление "дыр" в системе безопасности. Описание протокола L2TP сформулировано в документе RFC 2661.
Первый вопрос, с которым сталкиваются туннельные администраторы Windows NT 4.0, обычно звучит так: "В чем состоит различие, проявляющееся при развертывании протоколов L2TP и РРТР?" Фактически в этом случае проявляются два различия. Протокол L2TP требует использования сервера сертификатов, а туннели L2TP не могут проходить через сервер трансляции сетевых адресов (NAT — Network Address Translation). Если же туннель проложен, между протоколами L2TP и РРТР в Windows 2000 RRAS нет существенных отличий.
Как следует из названия, протокол L2TP является сетевым протоколом уровня 2. Многие из преимуществ, присущих как протоколу РРТР, так и протоколу уровня 2, можно встретить и в протоколе L2TP. Технологии уровня 2 применяются и основываются на су- шествующих технологиях РРР, таких как сетевой протокол управления (NCP — Network Control Protocol) и протоколы аутентификации доступа. Протокол уровня 2 не нуждается в
установке дополнительного программного обеспечения, реализующего поддержку стека IP-протоколов. Туннелирование уровня 2 позволяет достойно отражать различного рода атаки, благодаря наличию процедуры дополнительной аутентификации пользователей, а также возможностям туннельной аутентификации. Протокол РРР включает возможности пакетов IP, IPX и NetBEUI, передаваемых в составе фреймов РРР, а также осуществляет передачу инкапсулированных пакетов РРР, используя подключение "точка-точка". Протокол L2TP может применяться в существующих сетях в качестве протокола туннелирования. Причем, в данном случае речь идет как о внутренних, так и о внешних сетях, если только не осуществляется передача данных через сервер NAT.
Транспортные возможности
В отличие от протокола РРТР, который использует протокол управления передачей (TCP — Transmission Control Protocol). фреймы L2TP передаются с помощью протокола пользовательских дейтаграмм (UDP — User Datagram Protocol). Благодаря этому, можно реализовать как поддержку туннелей, так и тун нели рова ние данных. Информация, заключенная во фреймах РРР, может шифроваться, подвергаться сжатию, или же по отношению к ней может применяться тот или другой метод. В отличие от протокола РРТР клиенты Windows 2000 L2TP никогда не используют протокол шифрования "точка-точка" фирмы Microsoft (MPPE — Microsoft Point-to-Point Encryption) для поддержки подключений. Следует отметить, что передаваемые данные в общем случае не кодируются. Протокол L2TP бесполезен при решении задач шифрования, если они полностью отличны от тех задач, которые решаются с помощью протокола РРТР. Протокол IPSec вполне адекватен для выполнения задач шифрования.
Процесс аутентификации
Протоколы L2TP и РРТР также обладают всеми свойствами по поддержке безопасности, которые присущи протоколу РРР. Эти протоколы используют одну и ту же спецификацию. Сюда включаются несколько опций аутентификации, применимые для каждого пользователя, например, протокол аутентификации по методу "вызов/квитирование связи" (CHAP — Challenge-Handshake Authentication), Microsoft CHAP (MS-CHAP) версии 1 и 2 и расширяемый протокол аутентификации (ЕАР — Extensible Authentication Protocol). Также осуществляется аутентификация конечных точек туннеля, в результате чего хакеры лишаются возможности создания неаутенти- фицированных туннелей и получения доступа к корпоративным данным.
Поскольку процесс туннелирования может выполняться во многих средах, обеспечение безопасности является весьма важным. Протокол L2TP может использоваться совместно со смарт-картами и брандмауэрами. При использовании брандмауэров нужно учитывать одну существенную особенность, важную при работе с корпоративным сервером. Брандмауэры необходимо конфигурировать с целью выполнения перенаправления данных, используя IP-протокол 50 для IPSec ESP. Исходя из требований к безопасности, которые специфичны для корпоративной сети, протокол L2TP может использоваться совместно с шифрованием туннеля либо шифрованием, реализованным по схеме "точка-точка".
Как и в случае с протоколом РРТР, при использовании протокола L2TP должна быть доступной сеть, установленная между клиентом и сервером. Клиент L2TP может быть предварительно подключен к Internet, но если это не так, устанавливается другое подключение. Это подключение может устанавливаться путем включения другого объекта подключения, который определен при установке первоначальной связи с Internet. Например, если при установке обычного коммутируемого подключения к Internet со скоростью передачи данных 56 Кбит/с необходимо обеспечить доступ к корпоративным ре-
сурсам, достаточно просто щелкнуть мышью на объекте подключения сервера VPN. Этот объект сконфигурирован таким образом, что должен находиться в Internet еше до того, как будет установлено подключение к туннельному серверу. В результате объект первым устанавливает подключение к Internet.
Доставка пакетов
Обычно туннельное подключение устанавливается с целью обеспечения канала связи между удаленным клиентом (или узлом) и корпоративной сетью. Разработчики сетей должны оценивать вероятность успешного передачи пакетов на пути от отправителя к месту назначения. Если в результате реализации удачного проекта сети вероятность доставки данных по месту назначения оказывается исключительно высокой, вы получите массу благодарностей. Если же передача пакетов данных не является надежной, канал связи будет заблокирован из-за предпринимаемых многочисленных попыток повторной передачи данных.
Решение, основанное на применении протокола L2TP, в этом случае обеспечивает удачный баланс. В отличие от протокола РРТР, поддержка туннеля со стороны протокола L2TP реализуется не для отдельного подключения TCP. Протокол L2TP может контролировать и управлять трафиком, который пересылается в виде сообщений U DP. В операционной системе Windows 2000 клиенты и серверы L2TP используют порт UDP, имеющий номер 1701.
Протокол L2TP формирует очередь сообщений, в результате чего гарантируется доставка сообщений L2TP. Контрольное сообщение Ь2ТРвключает поля Next-Received (Следующий полученный) и Next-Sent (Следующий отправленный), поддерживающие последовательность всех управляющих сообщений. Поля Next-Sent и Next-Received также используются для последовательной отправки и управления потоком туннелированных данных. Пакеты, не включенные в последовательность, отбрасываются и должны передаваться повторно.
Сертификаты
Как указывалось ранее, между развертыванием протоколов L2TP и РРТР существуют два основных отличия. Первое отличие заключается в том, что обычно протокол L2TP/IPSec для всех клиентов требует наличия компьютерного сертификата. Для развертывания сертификатов проще всего с помощью Active Directory сконфигурировать производственный серверный сертификат сервера. В этом случае процедура автоматического развертывания протокола доступна для всех компьютеров, подключенных к данному домену.
Можно изменять поведение протокола L2TP/lPSec, которое задано по умолчанию, Вместо обязательной установки сервера сертификатов можно применять ключ, предварительно расп ространенный среди пользователей. Такой подход полезно использовать в том случае, если сетевая среда включает внешние L2TP. которые не поддерживают безопасность, основанную на использовании сертификатов. Шаги, осуществляемые при реализации этого процесса, описаны в конце этой главы, в разделе "Процедуры L2TP/!PSec".
Также возможно создавать подключения L2TP в Windows 2000, которые не будут шифроваться. Подключение L2TP, не использующее кодирование, может применяться при устранении проблем, возникающих при использовании подключений L2TP, При этом устраняется процесс аутентификации IPSec, а также процесс переговоров. Незашифрованное подключение VPN представляет собой туннель, который полностью открыт для выполнения пассивного мониторинга и захвата данных.
Предотвращение автоматического создания фильтра службами RRAS
Чтобы препятствовать службе RRAS создавать фильтр для трафика L2TP в автоматическом режиме, следует добавить значение системного реестра Prohibit/PSec. Если значению ProhibitlPSec присвоено значение 1, сервер не создает фильтр в автоматическом режиме для использования вместе с агентством по выдаче сертификатов. Вместо этого выполняется проверка локальной политики или политики Active Directory IPSec. Для внедрения данной конфигурации воспользуйтесь следующими шагами:
Запустите редактор системного реестра (Regedt32.exe).
Найдите в системном реестре следующий ключ.
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters
Откройте меню Edit (Правка), выберите опцию Add Value (Добавить значение), затем добавьте следующую величину в системный реестр:
Имя значения: ProhibitlpSec
Тип данных: REG_DWORD
Значение: 1
Перезапустите компьютер для внесения произведенных изменений.
Трансляция адресов
Другое важное отличие процесса развертывания протокола L2TP от развертывания протокола РРТР относится к серверам NAT. Протокол L2TP осуществляет контроль и передачу данных с помощью одного и того же транспортного механизма, устанавливая соответствующим образом заголовок. В заголовке указывается, является ли данное сообщение контрольным или же сообщением, содержащим данные. Устройство NAT функционирует с протоколами UDP и TCP, просто манипулируя в пакетах номерами портов (UDP или TCP) и отслеживая источник и место назначения. Таким образом в IP-заголовке выполняется трансляция IP-адреса для потока трафика. Поскольку протокол L2TP выполняется с помощью протокола UDP, протокол L2TP имеет возможность проходить через окно NAT; однако, поскольку для защиты протокола L2TP операционная система Windows 2000 применяет транспортный режим IPSec, переме- щениеданных при наличии NAT будет невозможным,
Упомянутое выше ограничение приобретает серьезное значение в связи с тем, что в настоящее время существует множество сетевых устройств, которые используют линии цифровой подписки(О8Ь) и подключения кабельного типа. Если ваша компания собирается приобрести устройство этого типа, поинтересуйтесь у производителя, каким образом устраняется недостаток. Эта проблема хорошо известна, и во многих документах RFC предлагаются методы решения. Конечно, возможна ситуация, когда для конкретного устройства приемлемое решение не может быть найдено. В этом случае рассмотрите вариант расположения устройства в конце туннеля или использования протокола РРТР. Особенность данной ситуации заключается в том, что туннельным администраторам приходится поддерживать протоколы РРТР и L2TP в течение сравнительно небольшого отрезка времени, Используя преимущества протокола L2TP, администраторы разрабатывают туннельную среду, что облегчает переход к протоколу L2TP в ближайшем будущем.
Не забывайте о том, что, хотя протокол L2TP/IPSec не передается через сервер NAT, он может транслироваться с помощью брандмауэра, основанного на NAT. Большинство представленных на рынке брандмауэров имеют возможность направлять протокол IP Protocol 50(IPSec ESP), в результате чего становится доступным решение вышеупомянутой проблемы. К сожалению, данное решение не подходит для домашних офисов, поскольку стоимость полнофункционального брандмауэра довольно высока.
753753Трансляция адресов
753
753
Подробности реализации протокола L2TP
Протокол L2TP был разработан совместно компаниями Cisco и Microsoft, поэтому внедрение протокола L2TP весьма напоминает процесс внедрения протокола IPSec. Поскольку при этом применяется спецификация, соответствуюшая стандарту IETF, все большее число производителей при реализации процесса туннелирования используют версии, основанные на использовании решения L2TP. При рассмотрении различных вариантов решений L2TP, предлагаемых поставщиками, необходимо учитывать следующие различия. Некоторые из этих различий препятствуют процессу осуществления связи или же приводят к существенному изменению планов по реализации подключения.
Важно учитывать некоторые особенности программных продуктов, предлагаемых на рынке. Встречаются совместно используемые устройства (устройства NAT), которые предназначены для работы с L2TP и IPSec. Однако, если внимательно ознакомиться с требованиями по внедрению этого программного продукта, можно заметить, что он поддерживает протокол L2TP только в туннельном режиме IPSec (при этом не поддерживается шифрование для транспортного режима протокола IPSec). He поддерживается и протокол L2TP/IPSec в заданной по умолчанию конфигурации Windows 2000 (а также Б большинстве других программных продуктов). Поскольку именно эта область вызывает потенциальные затруднения, необходимо четко разбираться в некоторых особенностях, связанных с протоколом L2TP.
Безопасность
Протокол IPSec удобно применять для решения задач шифрования, благодаря использованию дополнительного механизма. При этом для решения задач шифрования на уровне ядра применяется драйвер IPSec. Кроме того, поскольку в Windows 2000 реализован транспортный режим IPSec, значительно повышается общая степень безопасности. Протокол L2TP не применяет IPSec в туннельном режиме, поэтому для всех подключений L2TP в транспортном режиме используется встроенный фильтр. (Туннельному администратору не приходится конфигурировать эти фильтры вручную) При реализации протокола L2TP/IPSec можно довольно просто заблокировать туннельные серверы. Кроме ТОГО, поскольку IPSec является промышленным стандартом, все больше сторонних производителей программного обеспечения предпочитают связывать Windows 2000 и другие операционные системы.
Если пользователь уяснит преимущества использования протокола IPSec, его наверняка удивит следующее обстоятельство. В туннельном режиме вместо IPSec целесообразнее применять транспортный режим комбинации протоколов L2TP/IPSec. Данное решение является более приемлемым в силу следующих причин.
ТуннельныйрежимIPSecтребуетиспользованиястатическихIP-адресов,втовремя
как протокол L2TP может использовать полностью определенное доменное имя (FQDN — Fully Qualified Domain Name). Представьте себе туннельного администратора, который потребует у всех клиентов (включая пользователей портативных компьютеров, использующих режим перемещения) наличия статических IP- адресов, которые к тому же нельзя изменять! Это просто невозможно на практике.
Протокол L2TP поддерживает многопротокольные среды. В современной сетевой среде необходимость поддержки нескольких протоколов не является обязательной. Это связано с тем, что все больше и больше сетей в качестве основного протокола применяют TCP/IP. Однако, во многих сетях по-прежнему поддерживаются и другие протоколы.
Протокол L2TP создает интерфейсы в RRAS. Благодаря этому, туннельный администратор получает возможность назначать протоколы маршрутизации, а также выполнять различные другие задачи.
Конфигурирование протокола L2TP не представляет особых проблем. Заключительный вывод состоит в том, что, хотя туннельный режим iPSec и является частью операционной системы, он недостаточно полно реализован, что несколько затрудняет процесс конфигурирования.
Детали реализации подключений, использующих протокол L2TP
Что произойдет, если клиент подключается к туннельному серверу, используя протокол L2TP? В следующих шагах описывается процесс установки сеанса.
Если клиент связывается с туннельным сервером VPN, используя тип подключения, определенный как L2TP, клиент автоматически создает политику IPSec, если она еще не установлена для данного клиента.
Если политика IPSec уже создана, протокол L2TP просто внедряет правило безопасности, которое защищает весь трафик. При этом используются настройки безопасности, которые определены с помощью имеющейся политики. Если для системы не установлены политики IPSec, протокол L2TP создает собственное правило безопасности IPSec. В этом случае IPSec фильтрует трафик и приводит к установке соглашения по обмену ключей (IKE — Internet Key Exchange). В этом случае протокол L2TP выступает в роди приложения, пересылая трафик в 1701 порт UDP. Драйвер IPSec фильтрует этот трафик и вызывает протокол IKE. Затем устанавливается соглашение со шлюзом, поскольку шлюз определяет целевой IP-адрес для исходящего пакета L2TP UDP порта 1701. Источник инициирует подключение L2TP для клиента, используя адреса источника и шлюза, в результате чего активизируется протокол IPSec. После того, как процесс переговоров IPSec будет завершен, для трафика L2TP, пересылаемого через порт 1701 UDP, устанавливается протокол IPSec ассоциации безопасности (SA). Меры безопасности применяются только по отношению к трафику; при этом не блокируются данные, передаваемые хосту, а также никакие иные данные, передаваемые серверу. Чтобы блокировать данный хост, необходимо применять другие политики IPSec или политики маршрутизации фильтра. Эта связь согласуется с настройками шифрования, установленными в диалоговом окне интерфейса сетевого пользователя: No Encryption (Шифрование отсутствует), Request Encryption but Allow Clear (Шифрование требуется, но разрешаются пароли в виде простого текста), Encryption Only (Только шифрование) или Strong Encryption Only (Только строгое шифрование). Сначала необходимо произвести согласование с наиболее строгим режимом шифрования. Затем, если возникает в том необходимость, можно попытаться выбрать более слабый режим шифрования, продолжая этот процесс до момента установки соглашения. После достижения соглашения выполняется аутентификация безопасности IPSec, установленной между лэптопом и шлюзом. В процессе установки соглашения IPSec применяются компьютерные сертификаты, которые определяют, следует ли доверять клиентам и серверам.
Устанавливается туннельное соглашение L2TP, вследствие чего IPSec защищает трафик туннельного контроля, а также данные, передаваемые с помощью этого туннелю. С помощью идентификатора и пароля пользователя протокол L2TP производит аутентификацию сервера VPN. При использовании смарт-карты в этом случае производится аутентификация на основе сертификата.
Если при использовании Windows 2000 Server1 аутентификация не выполняется, возможна реализация этого процесса с помощью протокола RADIUS, относящегося к серверу Microsoft Internet Authentication Server (IAS). Данный сервер может выполнять проверку идентификатора и пароля пользователя домена. Ко времени завершения выполнения протокола L2TP устанавливается туннель, основанный на РРР, использующий безопасность протокола iPSec. При этом также завершается выполнение аутентификации пользователя с ПОМОЩЬЮ идентификатора и пароля либо смарт-карты, использующей сертификат.
На этом этапе установка туннеля завершается.
Клиентская настройки типа туннеля
На странице свойств подключения VPNимеется вкладка Network (Сеть), на которой находится опция, определяющая тип сервера VPN, с которым устанавливается соединение. Возможные варианты значений опции; Automatic (Автоматическое), РРТР или L2TP. При выборе варианта Automatic сначала происходит обращение к протоколу L2TP, а если подключение не было установлено, используется протокол РРТР. Чаще всего причина сбоя при установке подключения заключается в том, что отсутствует компьютерный сертификат, а между клиентом и сервером устанавливается сервер NA Т, Система запоминает, какой тип подключения был реализован, и именно этот тип будет применяться снова, при установке повторного подключения.
Шлюз удаленного доступа обеспечивает настройку большого количества других опций, позволяющих администратору обеспечивать детализованное управление сетями VPN. Эти политики удаленного доступа включают такие моменты, как время дня, элементы управления удаленным доступом пользователя и тип туннельного сеанса. На рис. 7.1 показан пример пакетауправления L2TP.
Заголовок канала .данныхЗаголовок канала .данных1Р-заго-ловок1Р-заго-ловокЗаголовокIPSec ESPЗаголовокIPSec ESPЗаголовок СообщениеЗаголовок СообщениеIPSec ESPIPSec ESPЗавершительаутентифика-IPSec ESPЗавершительаутентифика-IPSec ESPЗавершитель канала данныхЗавершитель канала данных
Заголовок канала .
данных
Заголовок канала .
данных
1Р-заго-
ловок
1Р-заго-
ловок
Заголовок
IPSec ESP
Заголовок
IPSec ESP
Заголовок Сообщение
Заголовок Сообщение
IPSec ESP
IPSec ESP
Завершитель
аутентифика-
IPSec ESP
Завершитель
аутентифика-
IPSec ESP
Завершитель канала данных
Завершитель канала данных
'—Зашифровано с помощью IPSec
Рис. 7.1. Пакет управления L2TP
Аутентификация
Клиент располагает двумя методами, позволяющими ему выполнять аутентификацию с помощью протокола L2TP:
протокол L2TP аутентифицирует пользователя в домене Windows 2000; пока проверка не завершится, трафик не принимается;
протокол IPSec с помощью сертификатов выполняет аутентификацию между двумя компьютерами, используя отношение взаимного доверия по отношению к шлюзу.
Протокол L2TP/lPSec функционирует аналогично процессу стандартного клиентского доступа с применением межузловых туннелей, которые также именуются межшлюзовыми туннелями. Данная конфигурация является обычной при установке связи между центральным офисом и филиалами либо домашними офисами корпорации. Как упоминаюсь ранее, протокол IPSec реализует защиту этого трафика, а протокол L2TP выполняет его инкапсуляцию. Еще до установки подключений с филиалами офисов необходимо определиться с методом аутентификации. Во многих случаях существует зависимость от учетной записи службы VPN, которая просто является учет- нои записью, используемой для поддержки удаленного подключения. Очевидным не-
достатком, проявляющимся в этом случае, является тот факт, что при фальсификации данной учетной записи, фальсифицируется вся сеть. Как указывалось в главе 6, можно установить соответствие между сертификатами и учетными записями и требовать сертификат пользователя для поддержки шлюзовых подключений. Данное решение является лучшим, поскольку процесс аутентификации требует наличия сертификата, который значительно труднее поддается фальсификации.
Как и в случае с реализацией любого сценария VPN, основная цель заключается в обеспечении защиты всего передаваемого трафика. В случае использования туннеля удаленного доступа трафик защищен только на пути от клиента в Internet до адреса другого шлюза. Поскольку в данном случае устанавливается сеть в соответствии со схемой "клиент-шлюз", а не согласно схеме "точка-точка", внутренний мониторинг этой сети будет затруднен. Желательно, чтобы протокол IPSec развертывался таким образом, чтобы безопасность обеспечивалась для всего передаваемого трафика. Для достижения этой цели потребуется объединить возможности протокола L2TP и межшлюзовых подключений.
Рассмотрим данный пример с точки зрения полной безопасности по схеме "точка- точка". Клиент офисного филиала пытается установить подключение к серверу центральной корпоративной сети, для которого применяется протокол IPSec. Подключение к офисному филиалу представляет собой межшлюзовый туннель L2TP/IPSec, который поддерживается с помощью выделенных граничных серверов. Когда клиент с помощью протокола IPSec связывается с сервером, между клиентом и местом назначения формируется соглашение по безопасности. Однако, при этом отсутствует взаимодействие с протоколом L2TP/IPSec. При использовании данной конфигурации клиент не знает, каким образом передается подключение по месту назначения и обратно. Граничный сервер выполняет маршрутизацию трафика независимо от того, будет зашифрован трафик или нет.
Шифрование L2TP
Уровень шифрования определяется при установке IPSec SA. В Windows 2000 поддерживаются два алгоритма шифрования:
шифрование DES, реализуемое с помощью 56-битового ключа;
тройной DES(3DES), использующий три 56-битовых ключа (шифрование с помощью первого ключа, декодирование с ПОМОЩЬЮ второго ключа, который отличен от первого, повторное шифрование с помощью третьего ключа).
Протокол IPSec был разработан для сетей, функционирующих на базе IP- протокола. В этом случае пакеты часто "теряются", или же нарушается порядок их следования в последовательности. Вследствие этого каждый пакет IPSec декодируется независимо от других пакетов IPSec.
Для туннелей, которые шифруются с использованием алгоритма DES, новые ключи шифрования генерируются после каждых 5 минут работы или после передачи 250 мегабайтов данных. Для туннелей, которые шифруются с использованием шифра 3DES, новые ключи генерируются по истечении каждого часа работы или после передачи 2 гигабайтов данных. Ключи для первоначального шифрования формируются в процессе аутентификации IPSec.
Если клиент инициирует подключение L2TP. полпрограммы RRAS используют информацию, полученную от объекта подключения. С помощью этой информации выделяется уровень шифрования, который запрашивается драйвером IPSec. Подпрограммы RRAS требуют немедленного достижения соглашения IKE и до установки туннеля L2TP ожидают завершения процесса согласования. Таким образом, RRAS усиливает уже определенный уровень шифрования IPSec (рис. 7.2).
Заголовок канала данныхЗаголовок канала данныхIP-заголовокIP-заголовокЗаголовокIPSec ESPЗаголовокIPSec ESPЗаголовок UDP -Заголовок UDP -Сообщение L2TPСообщение L2TPЗаголовок РРРЗаголовок РРРПолезная нагрузка РРР (IP-дейтаграммы, IPX-дейтаграммы, фреймы NetBEUIПолезная нагрузка РРР (IP-дейтаграммы, IPX-дейтаграммы, фреймы NetBEUIЗавершительIPSec ESPЗавершительIPSec ESPЗавершитель аутентификации IPSec ESPЗавершитель аутентификации IPSec ESPЗавершитель канала данныхЗавершитель канала данных
Заголовок канала данных
Заголовок канала данных
IP-заголовок
IP-заголовок
Заголовок
IPSec ESP
Заголовок
IPSec ESP
Заголовок UDP -
Заголовок UDP -
Сообщение L2TP
Сообщение L2TP
Заголовок РРР
Заголовок РРР
Полезная нагрузка РРР (IP-дейтаграммы, IPX-дейтаграммы, фреймы NetBEUI
Полезная нагрузка РРР (IP-дейтаграммы, IPX-дейтаграммы, фреймы NetBEUI
Завершитель
IPSec ESP
Завершитель
IPSec ESP
Завершитель аутентификации IPSec ESP
Завершитель аутентификации IPSec ESP
Завершитель канала данных
Завершитель канала данных
'—31ашифровано
:с помощью завершителя аутентификации IPSec EPS
Рис. 7.2. Пакет данных L2TP
Настройки протокола обмена ключей Internet
Важное значение имеет понимание настроек и конфигурирования протокола обмена ключей (IKE — Internet Key Exchange). Протокол IPSec может применять большое количество параметров шифрования, например, дайджест сообщений (MD5 - Message Digest 5) и защищенный хеш-алгоритм (SHA1 - - Secure Hash Algorithm). Группа Диффи-Хеллмана (Diffie-Hellman) сконфигурирована в качестве фазы 1 (основной режим) для настроек по изменению ключа и считается основным ключом. Новые ключи, которые генерируются во время фазы II защиты данных (скоростной режим), формируются на базе основного ключа Диффи-Хеллмана (Diffie-Hellman) фазы 1. Это справедливо в том случае, если не применяется фаза II усовершенствованного уровня секретности (Perfect Forward Secrecy). В следующей таблице описан основной режим обмена ключами IKE, который определен по умолчанию.
Название политики IKE
Основной режим обмена ключами MS IPSec 1SAKMP, заданный по умолчанию
Основной режим времени существования Основной режим PFS Основной режим списка предложений
480 минут (8 часов)
Не требуется, доступенпри необходимости
3DES с SHA1, DH группа 2 (1024 бита)
3DES с MD5, DH группа 2 (1024 бита)
DES с SHA1, DH группа 2 (1024 бита)
DES с SHA1, DH группа 1 (768 битов)
DES с MD5, DH группа 2 (768 битов)
40-битовый DES с SHA1, DH экспорт (512 битов)
40-битовый DES с MD5, DH экспорт 2 (512битов)
Как ОПЦИИ MD5, так и опции SHAI поддерживают максимальное взаимодействие, причем по направлению "сверху-вниз" указан порядок предпочтения этих режимов. Алгоритмы 3DES и Диффи-Хеллмана (Diffie-Hellman) (DH) группы 2 находятся на верхнем уровне, поскольку именно они являются наиболее строгими и генерируют ключи, достаточные для установки соглашения 3DES, реализуемого в быстром режиме.
Алгоритм DES применяется с SHA1 с помощью DH группы 2. При этом обеспечивается механизм более строгого шифрования, чем при выборе 56-битового алгоритма DES. Причина появления подобного механизма заключается в широком распространении успешных попыток "вскрытия" 56-битового ключа, причем на выполнение подобной операции требуется не столь уж много времени. Кроме того, частое и быстрое обновление ключей можно реализовать с помощью основного ключа группы 2 (1024-
битовый), что позволяет достичь улучшенной безопасности. Учитывая тот факт, что для сбора полезной информации необходим полный поток данных, частые обновления ключей позволяют достичь усиленной безопасности (по сравнению с безопасностью сеанса той же силы, которая базируется на использовании одного ключа). Единственным недостатком частого обновления ключа является наличие дополнительного трафика, генерируемого в ходе выполнения настоящего процесса. Вследствие этого необходимо произвести оценку требований, предъявляемых к безопасности данных, и определить, следует ли для вашей среды изменять заданные по умолчанию настройки.
В версиях Windows 2000, предназначенных для других стран, отключаются возможности, связанные с использованием 3DES, DH Group 2. Так, во французской версии отключены алгоритмы 3DES, DH группы 2 и DES DH группы 1, оставлен лишь 40-битовый DES с подключением экспортом DH. Но снова можно варьировать скорость изменения ключа, что позволяет достигать более высокого уровня безопасности.
Изменение характеристик ключа шифрования
Сложность применяемых методов шифрования основывается на изменениях ключа, который поддерживается между системами, совместно использующими данные. Если среда выдвигает определенные требования к безопасности, можно различными способами настраивать процесс обмена ключами. В следующих разделах подробно рассматриваются несколько подобных методов.
"Время жизни" ключа
Настройки "времени жизни" определяют частоту, с которой генерируется новый ключ. Когда "время жизни" ключа истекает и требуется новый ключ, заново устанавливается соглашение по SA. Подобный процесс генерации новых ключей называется динамическим возобновлением ключа (dynamic rekeying) или регенерацией ключа (key regeneration). "Время жизни" определяет скорость изменения нового ключа, которая известна как регенерация с указанием определенных интервалов. Изменение ключа гарантирует, что, если хакер получит доступ к ключу в одной части подключения, использующего шифрование, все подключение не будет сфальсифицировано. Известно, что Windows 2000 устанавливает в качестве заданной по умолчанию настройки автоматическую регенерацию ключа. Эта настройка поддерживает некий баланс между производительностью и достигаемым уровнем безопасности. Однако, можно отменить эту настройку и указать (в минутах) "время жизни" для основного ключа, используя ключ сеанса или же значение Perfect Forward Secrecy (PFS). Действие фильтра при соответствующей IPSec-политике должно обновляться, что повысит скорость изменения ключа.
Для администратора важно представлять, какой вклад вносится при изменении настроек, заданных по умолчанию. Если ключи изменяются слишком часто, трафик для изменения ключа является чрезвычайно требовательным к ресурсам. Если ключи изменяются с недостаточной частотой, меры безопасности, устанавливаемые для туннеля, становятся неэффективными. По мнению автора, желательно сохранить настройку, заданную по умолчанию.
Ограничение ключа сеанса
Повторяющиеся изменения одного и того же основного ключа могут при определенных обстоятельствах приводить к фальсификации данного ключа. Один и тот же основной ключ может применяться более одного раза, если соглашение по безопасности попадает во временной интервал, установленный для компьютера. Можно ограничить число попыток использования определенного ключа, указывая ограничение на сеанс
применения ключа. Основной ключ PFS определяет методику генерирования нового ключа. Если администратор конфигурирует PFS, ключ должен на каждой фазе использоваться для зашиты информации в процессе передачи. Однако данный ключ не может применяться для генерирования дополнительных ключей. Кроме того, как сам ключ, так и информация, которая использовалась при создании предыдущего ключа, не могут применяться при формировании нового ключа. Подобный подход существенно ограничивает зависимость от общих данных, которые можно фальсифицировать.
Основной ключ PFS должен применяться с определенной предосторожностью, поскольку он требует повторной аутентификации. В результате осуществления этого процесса появляются дополнительные издержки, связанные с передачей служебной информации. Когда основной ключ PFS конфигурируется на одном из концов туннеля, его применение возможно на обоих концах этого туннеля. Если используется подобная конфигурация, игнорируется ограничение на ключ сеанса, поскольку PFS всякий раз запускает процесс повторной генерации ключа.
Методы обмена ключей (НЗ)
Поскольку для реализации задач шифрования протокол L2TP применяет средства IPSec, администратор может с учетом запросов среды изменять заданную по умолчанию методику обмена ключей, основанную на политике IPSec. Одним из наиболее распространенных изменений является повторное конфигурирование параметров обмена ключей.
Фаза один: основной режим обмена ключей
Настройки основного режима обмена ключа ЖЕ определяют методику основного режима IKE/Oakley. Именно последняя методика задает уровень секретности материала для основного ключа, а также алгоритмические комбинации, которые используются при защите зашифрованной части соглашения IKE. Настройки поддерживаются с помощью указанного ниже ключа системного реестра. Они также позволяют выполнять расширенный контроль над заданным по умолчанию поведением:
HKEY_LOCAL^t4ACHINE\SYSTEM\CurrentCdntrolSet\Services\PolicyAgent\Oakley KinLifeTime: REG_DWORD: Default 8 hours (28,000 seconds)
Этот ключ устанавливает минимальное "время жизни" для ключа, который применяется при шифровании процесса обмена Oakley. Если политика задает значение, меньшее, чем MinLifeTime, применяется значение MinLifeTime.
Если речь идет об активной политике, параметры основного режима обмена ключей уже определены. Эти настройки могут существенно замедлить выполнение протокола L2TP, как это часто происходит при работе в основном режиме или в скоростном режиме обновления ключа, использующем PFS.
Алгоритм DH группы 2 требуется в том случае, если в качестве алгоритма по обеспечению безопасности трафика выбирается 3DES. В этом случае алгоритм DH группы 2 выбирается и выполняется всегда. Довольно часто при этом не выдвигается требование по повторной аутентификации с применением сертификатов, поэтому не следует изменять заданное по умолчанию значение, равное 8 часам. Чтобы оценить влияние данной настройки, ответьте на следующий вопрос: "Если сертификат отменяется, как быстро выполняется проверка отмены сертификата?" Если администратор выполняет отмену сертификата, желательно прервать подключение, причем для этого лучше всего в ручном режиме закрыть туннель. "Время жизни" основного режима SA не превышает установленную дату истечения и срок существования данного сертификата.
Фаза два: скоростной режим для "времени жизни"
В скоростных режимах IKE/Oakley используются ключи шифрования, которые формируются на базе основного режима ключа Диффи-Хеллмана (Diffie-Hellman). Эти ключи обновляются каждый час, формируя таким образом для сред "маршрутизатор-маршрутизатор" вполне пригодное значение "времени жизни”, равное 1 часу (эквивалентно 500 Мбайт переданной информации).
Информация о "времени жизни" подвергается согласованию, причем применяется самое малое значение из тех, которые используются инициатором и ответчиком. Значения, заданные по умолчанию для скоростного режима IPSec, поддерживаются в системном реестре на базе каждого подключения L2TP и применяются с помошью агента политики IPSec. Эти настройки достаточно сконфигурировать на сервере, а не на клиентах; сервер использует для "времени жизни" самые маленькие ограничения, которые используются клиентами. В Windows 2000 туннели L2TP/IPSec типа "сервер- сервер" применяют те же самые параметры.
Информация о поведении IKE включена в рассмотрение, поскольку некоторые среды могут специализироваться с учетом определенных характеристик ключа. В общем случае не рекомендуется изменять заданные по умолчанию настройки. Обычно это приводит к ухудшению эффективности пользования туннелем. Если же возникла необходимость в изменении этих настроек для конкретной среды, обратите сначала внимание на соблюдение мер безопасности.
Управление энергопотреблением
Обычно портативные компьютеры функционируют в энергосберегаюшем режиме. Эта особенность поддерживается в реализации протокола L2TP для Windows 2000. Если же для портативного компьютера установлен режим энергосбережения при поддержке подключения L2TP/IPSec, может сократиться "время жизни" IPSec SA. Если же клиент "засыпает" при пересылке сервером данных IPSec, происходит "потеря" этих данных.
Если клиент "спит", а сервер инициирует запрос о скоростном режиме обновления ключа, самого обновления не происходит, а скоростной режим SA завершается. Однако, фильтры сервера не удаляются и, поскольку "время существования" основного режима IPSec по умолчанию равно 8 часам, весь этот процесс поддерживается сервером.
Когда клиент "пробуждается", драйвер IPSec обслуживает таймеры, которые были установлены в соответствии с "временем жизни" SA. Затем клиент с помощью сервера пытается возобновить соглашение о скоростном режиме и/или основном режиме. Затем соглашения устанавливаются в скоростном режиме, поскольку сервер по- прежнему использует основной режим SA, который ссылается на скоростной режим. Также устанавливаются соглашения относительно клиентского основного режима, но при этом на сервере переписывается применяемый ранее основной режим SA.
Процедуры L2TP/IPSec
После рассмотрения теоретических основ методики развертывания L2TP/IPSec можно переходить к реальным конфигурациям. Несмотря на то, что в главе обсуждаются несколько настроек системного реестра и пользовательских конфигурации, стандартные настройки хорошо зарекомендовали себя в большинстве применяемых сред.
В зависимости от способа конфигурирования структуры сертификатов, клиенты могут получать сертификаты при автоматическом развертывании. При этом используются клиентские запросы, направляемые из подключаемого модуля Certificate (Сертификат) консоли ММС, Web-браузер или же некоторые другие методы.
Независимо от способа передачи сертификата клиенту, если клиент не имеет этого сертификата, выполнение iPSec будет неудачным. В этом случае не сможет реализовываться протокол L2TP, использующий IPSec. Если клиент не может подключиться к серверу L2TP, первый шаг на пути диагностики возникшей проблемы заключается в проверке того, располагает ли клиент корректным сертификатом, требуемым для реализации подключения. Метод просмотра сертификата компьютера демонстрируется в процедуре 7.1.
Процедура 7.1. Просмотр сертификата компьютера
Выберите команды Start ^ Run (Пуск ^ Выполнить). В командной строке Run введите ммс и щелкните на кнопке <ок>.
Щелкните на кнопке <Add> (Добавить) и выберите команду Certificates ф Computer Accounts (Сертификаты ^ Учетные записи компьютеров). Щелкните на кнопке <Next> (Далее). Затем выберите опцию Local Computer (Локальный компьютер) и щелкните на кнопке <Finish> (Готово).
Закройте окно Add Snap-In (Добавление оснастки). Проверьте, что подключаемый модуль был установлен и щелкните на кнопке <ОК>.
Раскройте папки Certificates и Personal, затем щелкните на кнопке < Certificates^ (Сертификаты). При этом отобразятся все сертификаты, хранимые на локальном компьютере (рис. 7.3).
Рис. 7.З. Просмотр сертификатов на локальном компьютерс
В главе 6 уже рассматривалось, что, как правило, при развертывании сертификатов компьютера для подключений L2TP нужно на одном и том же сервере VPN поддерживать как протокол РРТР, так и протокол L2TP. Хотя данная конфигурация туннельного сервера и задана по умолчанию, может сложиться такая ситуация, когда в сети используется только протокол L2TP. По умолчанию в Windows 2000 клиент должен попытаться сначала применить протокол L2TP, а затем перейти к протоколу РРТР. Если клиент изначально не получает сертификат, он может получить его во время первого подключения, реализованного с помощью протокола РРТР.
Чтобы удостовериться в наличии сертификатов, развернутых с помощью протокола L2TP, можно воспользоваться двумя методами. Первый метод состоит в конфигурировании клиента, требуемого для подключения L2TP. Однако, при этом необходимо использование расширенной конфигурации, что существенно затрудняет процесс проверки. В этом случае для развертывания сертификата компьютера могут возникнуть большие накладные расходы на администрирование. Если ваша организация выполняет развертывание компьютерных сертификатов на клиентских системах, можно воспользоваться процессом, который описан в процедуре 7.2.
Процедура 7.2. Переход от протокола РРТР
к протоколу L2TP
Правойкнопкоймышищелкнитенаобъектеподключения,которыйпредставляет
собой подключение к серверу VPN. В контекстном меню выберите опцию Properties (Свойства).
Щелкните на вкладке Networking (Сеть).
Выделите тип сервера VPN, с которым устанавливается соединение, затем щелкни - те на пиктограмме "стрелка вниз" и выберите пункт L2TP.
Другой метод для установки подключения L2TP состоит в изменении политики удаленного доступа, которая обычно применяется при конфигурировании сервера. С помощью политики удаленного доступа администратор может глобальным образом устанавливать стандарты для всех типов подключений с туннельным сервером. В про- цедуре7.3 показывается, каким образом это реализуется на практике.
Процедура 7,3. Изменение политики удаленного доступа
Находясь на туннельном сервере, выберите пункты меню Start =о Programs с> Administrative Tools =о Routing and Remote Access Service (Пуск =о Программы со Администрирование ф Служба маршрутизации и удаленного доступа).
В левой панели дважды щелкните на элементе Remote Access Policies (Политики удаленного доступа).
В правой панели дважды щелкните на соответствующей политике. Щелкните на кнопке <Add> (Добавить) и добавьте условие.
Выберите опцию Tunnel Type (Тип туннеля) и щелкните на кнопке <Add> (рис. 7.4). Щелкните на кнопке <ОК>. Теперь заданная по умолчанию политика включает определение времени и требование, говорящее о том, что в качестве туннеля выбирается L2TP.
Поскольку подключения L2TP установлены, можно просматривать их с помошью утилит IPSec Monitor и Network Monitor. В этом случае можно получить основные сведения о взаимосвязях IPSec на обоих концах туннеля L2TP/IPSec. Для осуществления мониторинга этой взаимосвязи воспользуйтесь шагами процедуры 7.4.
" hdecl Attribute HBj
Select the type of attrbule to add, and then cfck the Add button.
Attribute typer
NameI Description
Cakd-Slation-ld CaSngStatIon-idClrent-Friendly Name Client IP Adders Ctent-Vendor Day-And-Trne-Reiu*:.. F ramed-Prolocd NAS-ldentilieiHAS 4P Addie» NAS-Port-Type Service TypeИИ5ЭВЕЕ1Wrdows-GroupsCakd-Slation-ld CaSngStatIon-idClrent-Friendly Name Client IP Adders Ctent-Vendor Day-And-Trne-Reiu*:.. F ramed-Prolocd NAS-ldentilieiHAS 4P Addie» NAS-Port-Type Service TypeИИ5ЭВЕЕ1Wrdows-GroupsPhone rtirnbep dated by user
Cakd-Slation-ld CaSngStatIon-id
Clrent-Friendly Name Client IP Adders Ctent-Vendor Day-And-Trne-Reiu*:.. F ramed-Prolocd NAS-ldentiliei
HAS 4P Addie» NAS-Port-Type Service Type
ИИ5ЭВЕЕ1
Wrdows-Groups
Cakd-Slation-ld CaSngStatIon-id
Clrent-Friendly Name Client IP Adders Ctent-Vendor Day-And-Trne-Reiu*:.. F ramed-Prolocd NAS-ldentiliei
HAS 4P Addie» NAS-Port-Type Service Type
ИИ5ЭВЕЕ1
Wrdows-Groups
Phone number from which cal originated Friendly name I oi the RADIUS clienl. (IAS only) IP ««rett of RADIUS ciert. [IAS опИ Manufacturer ol RADIUS proi^i ffl NAS (IAS orl Time peiiods and days ol week during which mt . The protocol to be used
String identifying the NAS originating therequ<«t IP bddiei-i of the NAS w -gunMing the request ^ Type ol physical port used by the NAS aigmalin Type of service user net requested T tunneling protocols to be used
I Ajd... | tweei |I Ajd... | tweei |Windows groups thal user belong) Io
I Ajd... | tweei |
I Ajd... | tweei |
OKCwcel 1 Apply
Puc. 7.4. Атрибут Tunnel Type
Процедура 7.4. Мониторинг подключения L2TP
Инициируйте подключение L2TP между двумя серверами.
Выберите пункты меню Start =t- Run (Пуск => Выполнить), затем введите команду IPSecmon. Щелкните на кнопке <ОК>. Выберите пункт Options (Параметры), сократите период, определенный опцией Refresh (Обновить), и щелкните на кнопке <ОК>. После этого перечисляются соглашения по безопасности L2TP, определенные с помощью правила L2TP. Это позволит получить общие сведения и подтвердить установление этого подключения (рис. 7.5).
Щелкните на кнопке <Start> (Пуск) и выберите опции Programs ф Administrative Tools d> Network Monitor (Программы ^ Администрирование Cv Сетевой монитор). Выберите интерфейс, применяемый для подключений L2TP, и затем перехватите трафик. Если трафик отображается, можно указать фильтр для просмотра, что облегчает обработку трафика L2TP.
Используйте протокол ESP, поскольку протокол L2TP использует транспортный режим IPSec ESP (рис. 7.6).
Утилиты IPSecMon и Network Monitor помогают администратору при диагностике ситуаций, которые могут воспрепятствовать успешной реализации туннельных подключений L2TP. Поскольку трафик, который перехватывается утилитой Network Monitor, обычно кодируется, трудно получить относительно него большой объем информации. Однако, можно легко установить источник, место назначения и номер SPI для использования в качестве ссылки при просмотре журнальных файлов Oakley. Эти файлы Oakley хранятся в каталоге %systemroot%\deDug.
Если Windows 2000 L2TP связываются с внешними операционными системами, текущая реализация которых не поддерживает IKE, подключение "шлюз-шлюз" может устанавливаться с помощью предварительно распространенных ключей. В процедуре 7.5 описывается методика установки подобного подключения.
\U2Sj\U2SjPcicy WarneSecovy - Filar Nam#Бхмлсе AddonDwt. Adder j _ PtoiMciS?c.PalDeriL2TPRuhE8PD... NoNaflWv.ATHLON intern...EDGESERVER UDP1701o IPcicy WarneSecovy - Filar Nam#Бхмлсе AddonDwt. Adder j _ PtoiMciS?c.PalDeriL2TPRuhE8PD... NoNaflWv.ATHLON intern...EDGESERVER UDP1701o I- ISAMPADakWy S latticeCaHeyMainMode;- ISAMPADakWy S latticeCaHeyMainMode;■ iPSEt Sr «lines-— AcbveAMociaiion$1Confidential Bytes Sent87,002Confidential Bytes Received90J 98Authenticated Byte*Sent109,760Authenticated Byte* Received *113,606Bad SR Packets0Packed N oi Decked0Packeii NotAuthenticated0KeyAdditions5■ iPSEt Sr «lines-— AcbveAMociaiion$1Confidential Bytes Sent87,002Confidential Bytes Received90J 98Authenticated Byte*Sent109,760Authenticated Byte* Received *113,606Bad SR Packets0Packed N oi Decked0Packeii NotAuthenticated0KeyAdditions5Oekley Quick Mcxiee5So/iAttodalont0Authentication F»Met0Oekley Quick Mcxiee5So/iAttodalont0Authentication F»Met0tPSecurityisenabtedonthis computetPSecurityisenabtedonthis computePMC. 7.5. Просмотр подключения L2TPc помощью [PSecMonPMC. 7.5. Просмотр подключения L2TPc помощью [PSecMon
\U2Sj
\U2Sj
Pcicy WarneSecovy - Filar Nam#Бхмлсе AddonDwt. Adder j _ PtoiMciS?c.PalDeri
L2TPRuhE8PD... NoNaflWv.ATHLON intern...EDGESERVER UDP1701o I
Pcicy WarneSecovy - Filar Nam#Бхмлсе AddonDwt. Adder j _ PtoiMciS?c.PalDeri
L2TPRuhE8PD... NoNaflWv.ATHLON intern...EDGESERVER UDP1701o I
- ISAMPADakWy S lattice
CaHeyMainMode;
- ISAMPADakWy S lattice
CaHeyMainMode;
■ iPSEt Sr «lines-—
AcbveAMociaiion$1
Confidential Bytes Sent87,002
Confidential Bytes Received90J 98
Authenticated Byte*Sent109,760
Authenticated Byte* Received *113,606
Bad SR Packets0
Packed N oi Decked0
Packeii NotAuthenticated0
KeyAdditions5
■ iPSEt Sr «lines-—
AcbveAMociaiion$1
Confidential Bytes Sent87,002
Confidential Bytes Received90J 98
Authenticated Byte*Sent109,760
Authenticated Byte* Received *113,606
Bad SR Packets0
Packed N oi Decked0
Packeii NotAuthenticated0
KeyAdditions5
Oekley Quick Mcxiee5
So/iAttodalont0
Authentication F»Met0
Oekley Quick Mcxiee5
So/iAttodalont0
Authentication F»Met0
tPSecurityisenabtedonthis compute
tPSecurityisenabtedonthis compute
PMC. 7.5. Просмотр подключения L2TPc помощью [PSecMon
PMC. 7.5. Просмотр подключения L2TPc помощью [PSecMon
•'* 11* Ъч <№< у M<H*tOT
5 «хх «у Аееооааопс
Puc 7,6. Просмотр подключения L2TP с помощью Newark Monitor
Процедура 7.5. Создание политики
для использования совместно с L2TP/IPSec, применяющего предварительно распределенные ключи
Выберитеменю Start(ПускВведите ММС и
на кнопке <ОК>.
Выберите команды ConsoleAdd/Remove Snap-In (КонсольДобавить/удалить оснастку). Щелкните на кнопке(Добавить), Выберите опцию IP Security Policy
Management (Управление политикой IP-безопасности).
Щелкните на кнопке <Add>. Выберите опциюComputer (Локальный компьютер) ина кнопкеЗатемна кнопках
(Закрыть) и <ОК>.
Правой кнопкой мыши щелкните на опции IP Security Policies on Local Machine (Политики IP-безопасности на локальном компьютере) и выберите пункт Create IP Security Policyполитику IP-безопасности).
В окне мастера IP Security Policy Wizard (Мастер политик IP-безопасности) щелкните на кнопке(Далее).
Введите Policy Name (Имя политики), которое идентифицирует политику L2TP Shared-Key. Щелкните на кнопке
Находясь в окне RequestsSecure Communication (Запросыкоммуни
каций), отмените установку флажка Active Default Response Rule (Активное правило по умолчанию). Щелкните на кнопке
Проверьте установку флажка Edit Properties (Изменение свойств), затем щелкните на кнопке <Finish> (Готово).
Получитедоступк страницесвойствдлявашейполитики.НавкладкеRules
(Правила)на кнопке <Add> (Добавить). После этого запускается мастер IP
Security Rule Wizard (Мастер правил IP-безопасности). Щелкните на кнопке
Проверьте, что установлен флажок This Rule Does Not Specify a Tunnel (Правило не указывает туннель) и щелкните на кнопке
На экране Network Type (Тип сети) выделите All Network Connections (Все сетевые подключения) и щелкните на кнопке
Выберите опцию Use This String to Protect the Key Exchange (Preshared Key) (Использовать эту строку для защиты обмена ключей (предварительно распространенный и введите предварительно распространенный ключ (рис. 7.7). (Обратите внимание, что в этом примере применяется очень простой ключ, а в реальной рекомендуется применять более сложный ключ.) Щелкните на кнопке
Находясь в списке IP Filter (IP-фильтр), щелкните на кнопке <Add>.
Введите название вашего IP-фильтра и щелкните на кнопке
После запуска на выполнение мастера IP Filter Wizard (Мастер IP-фильтра) щелкните на кнопке
Выберите определенный IP-адрес и введите исходный адрес для исходного сервера Щелкните на кнопке
Выберите определенный IP-адрес и введите целевой адрес сервера назначения RRAS. Щелкните на кнопке
В качестве типа IP-протокола укажите UDP. Щелкните на кнопке <Next>.
В разделе IP Protocol Port (Порт IP-протокола) выберите опцию From This Port (С этого порта), введите 1701 и выберите опцию То Any Port (К любому порту) (рис. 7.8). Щелкните на кнопке <Next>.
Рис. 7.7. Ввод строки предварительно распространенного ключаРис. 7.7. Ввод строки предварительно распространенного ключаРас. 7.8. Выбор порта протоколаРас. 7.8. Выбор порта протокола
Рис. 7.7. Ввод строки предварительно распространенного ключа
Рис. 7.7. Ввод строки предварительно распространенного ключа
Рас. 7.8. Выбор порта протокола
Рас. 7.8. Выбор порта протокола
Установите флажок Edit Properties (Изменить свойства) и щелкните на кнопке <Finish> (Готово).
Проверьте, что установлен флажок Mirrored (Зеркально отраженный). Щелкните на кнопке <0К>.
Щелкните на кнопке <Close> (Закрыть) для закрытия экрана IP Filter (IP-фильтр).
В списке IP Filter выберите новый IP-фильтр, Щелкните на кнопке <Next>.
В списке Filter Actions (Действия фильтра) выберите опцию Require Security (Требуется безопасность) (рис. 7.9). Щелкните на кнопке <Next>
ft/c. 7.9. Выбор соответствующего действия фильтраft/c. 7.9. Выбор соответствующего действия фильтраРис. 7.10. Очистка флажка Accept Unsecured CommunicationРис. 7.10. Очистка флажка Accept Unsecured Communication
ft/c. 7.9. Выбор соответствующего действия фильтра
ft/c. 7.9. Выбор соответствующего действия фильтра
Рис. 7.10. Очистка флажка Accept Unsecured Communication
Рис. 7.10. Очистка флажка Accept Unsecured Communication
.Дополнительно: если сервер конфигурируется в режиме блокировки, измените требуемое действие безопасности, затем отмените установку флажка Accept Unsecured Communication, but Always Respond Using IPSec (Разрешать незащищенные подключения, но всегда отвечать с помощью IPSec) (рис. 7.10).
Щелкните на кнопке <Next>. Щелкните на кнопках <Finish> и <Close>.
Если на другой стороне туннеля находится система Windows 2000 RR AS, сконфигурируйте другой сервер, следуя в точности шагам, описанным выше, включая шаги 16 и 17. Даже если кажется более логичным поменять исходный и целевой адреса, не делайте этого. Если оставить все, как есть, можно установить подключение, которое инициировано в обоих направлениях.
Если сервер поддерживает несколько общедоступных ключей, для каждого из новых подключений нужно определять дополнительные правила.
Резюме
При каждом развертывании сервера VPN используется протокол L2TP. Вследствие некоторых ограничений, связанных с протоколом L2TP (типа требований Windows 2000 и невозможности передачи данных через сетевое устройство, поддерживающее общедоступное подключение), нежелательно, чтобы множество сред использовали этот протокол. Однако, если ваш туннельный сервер установлен с учетом поддержки этого стандарта, довольно просто добавлять новых клиентов. Речь идет о клиентах, на которых установлено новое программное и аппаратное обеспечение. Именно это обеспечение выпускается в настоящее время. В результате его применения обеспечивается безопасность для сетевого VPN-решения.
8
Прокси-серверы и серверы NAT
Серверы трансляции сетевых адресов (NAT — Network Address Translation) и прокси-серверы создавались с целью преодоления ограничений диапазона общедоступных адресов TCP/IP, Попутно при этом внедрялся дополнительный уровень безопасности, позволяющий за внешним адресом скрывать внутренний хост. В современных условиях практически невозможно найти корпоративную сеть, в составе которой отсутствует устройство, отделяющее ее от Internet.
Большая часть компьютеров в корпоративных сетях имеет специальные "не присваиваемые" IP-адреса, среди которых можно встретить следующие;
Ю.х.х.х
172.l6.xx - 172.32.Х.Х
Х.Х
МАСКА 255.0.0.0
МАСКА 255.255.0.0
МАСКА 255.255.0.0
Хотя эти адреса выглядят довольно необычно, их можно применять в любой локальной сети. Для обеспечения безопасности всей сети рекомендуется выполнять фильтрацию этих адресов. Однако, этот процесс довольно редко реализуется провайдерами услуг Internet, поскольку при осуществлении фильтрации с использованием нескольких правил или списков доступа значительно снижается быстродействие. В этом случае трафик достигает лишь первого маршрутизатора Internet, а затем "теряется".
Администраторы локальных сетей вручную назначают диапазоны адресов в случае, если частные сети определены за устройствами, поддерживающими общедоступное подключение. Сервер Microsoft Proxy Server фактически определяет эти диапазоны в качестве стандартного поведения с целью определения таблицы локальной области.
В следующем списке приводится подробный перечень большого числа факторов, которые способствуют широкому распространению серверов NAT и прокси-серверов.
Короткий период существования новых компьютерных технологий способствует тому, что во многих домах "уживаются" несколько компьютеров различных моделей. Все больше и больше пользователей намереваются наряду с обращением к Internet совместно использовать локальные ресурсы. Связь между локальными компьютерами обеспечивается с помощью локальных сетей. Устройство для поддержки совместно используемых подключений, типа прокси-сервера или сервера NAT, позволяет нескольким системам использовать одно и то же подключение к Internet.
Руководители многих корпораций уже давно пришли к выводу, что значительно эффективнее использовать надомную форму организации труда служащих. В этом случае осуществляется более гибкая форма организации труда, а также достигается существенная экономия, Большинство подобных распределенных отделений офисов нуждаются в определенных решениях по организации общедоступных подключений, которые поддерживаются прокси-серверами и серверами NAT.
Новые сетевые технологии позволяют в домашних условиях обеспечивать такой уровень услуг, который ранее был просто недостижим. Подключения DSL, ISDN, кабельное подключение, а также другие типы подключений к Internet обеспечивают широкий спектр возможностей для пользователей домашних сетей.
Наравне с новыми возможностями, которые стали доступными после появления быстродействующих подключений к Internet, в домашних сетях повышается степень риска при передаче данных. В настоящее время требуется обеспечение безопасности не только корпоративных сетей, но также и узлов распределенных домашних офисов и даже систем домашних сетей.
Серверы NAT позволяют компаниям изменять типы доступа или провайдеры доступа к Internet (ISP) без повторного конфигурирования внутренних компьютеров.
Поскольку серверы NAT и прокси-серверы рассматриваются в связи с туннелями, неплохо привести некоторые соображения по каждому из этих решений. Существуют два основных типа прокси-серверов: прокси-серверы приложения и прокси SOCKS.
Прокси-сервер
Как и следует из названия, прокси-сервер оказывает влияние на поведение клиентского компьютера. Это означает, что все приложения, выполняемые клиентом, должны учитывать наличие прокси-сервера.
Прокси-объекты, как правило, применяются для контроля (или мониторинга) исхо- дяшего трафика. Некоторые прокси-приложения кэшируют запрашиваемые данные, снижая тем самым уровень требований к пропускной способности данных со стороны подключения, и ограничивают доступ к этим данным для следующего пользователя. Также контролируется деятельность клиентов, использующих ресурсы Internet.
Прокси-сервер приложения
Если клиент в частной сети запрашивает Web-страницу из Internet, запрос направляется прокси-серверу. Большинство прокси-серверов сначала выполняют проверку на предмет того, была ли кэширована эта страница в локальном хранилище данных. Если страница была кэширована, прокси-сервер выполняет проверку запрашиваемой версии страницы, возвращая кэшированную копию страницы клиенту, обратившемуся с запросом. Если подобная копия отсутствует, производится выборка этой страницы с узла Internet, кэширование ее копии в локальном хранилище, а затем возвращение страницы.
Обычно при объяснении принципа функционирования прокси-сервера производится его сравнение с клиентом, который подключается к компьютеру с помощью Telnet. На втором этапе производится подключение компьютера, на котором выполнена регистрация, к внешнему миру. Прокси-сервер приложений автоматизирует описанный процесс. Когда клиент получает доступ к внешнему миру с помощью Telnet, данные сначала передаются прокси-серверу, а затем прокси-сервер подключается к требуемому серверу и возвращает данные клиенту частной сети, откуда они поступали. Как правило, при реа- лизании этого процесса клиент должен знать о существовании прокси-сервера.
Поскольку прокси-серверы обрабатывают и "осведомлены" обо всех подключениях, использующих определенные протоколы, они могут регистрировать все действия клиентов. Многие компании при обеспечении безопасности пользуются исключительно журналами прокси-серверов. Прокси-сервер можно сконфигурировать для фильтрации "несоответствующих" слов, поступающих с узлов, посещаемых пользователями. Кроме того, прокси-серверы можно сконфигурировать таким образом, что они будут выполнять просмотр файлов при загрузке на предмет обнаружения вирусов. При этом не требуется выполнять дополнительное конфигурирование.
Прокси-серверы приложений могут аутентифицировать пользователей, а также настраиваются для предоставления определенных прав некоторым пользователям или группам. До того, как устанавливается соединение с "внешним миром", сервер может запросить пользователя о предварительной регистрации или же просто просмотреть текущие полномочия домена. Вследствие этого журналы могут включать некоторые подробности о зарегистрированных пользователях (дополнительно к сведениям об адресе TCP/IP, который довольно часто изменяется).
Прокси-сервер SOCKS
Внутреннее устройство прокси-сервера SOCKS весьма напоминает устройство старинного телефонного коммутатора. Этот сервер просто связывает ваше подключение с внешним подключением, используя в качестве посредника систему. Большинство серверов SOCKS обрабатывают только подключения, имеющие тип TCP, для которых могут устанавливаться серьезные ограничения (несмотря на наличие большого количества решений, реализующих полный сетевой доступ). Подобно серверам NAT, серверы SOCKS не поддерживают аутентификации пользователя, но ведут записи о подключениях каждого пользователя-
Функции прокси-сервера: быстродействие и безопасность
С помощью сервера, выполняющего передачу внешней информации внутренним компьютерам, прокси-серверы позволяют отделять среду частной сети от общедоступной среды Internet. Поскольку прокси-серверы "осведомлены" о приложениях, передающих трафик, в этом случае реализуется довольно серьезная система безопасности. Прокси-серверы не только передают пакеты по сети, но также функционируют в качестве брандмауэра. Кроме того, большинство прокси-серверов выполняют операции кэширования, проверяют версии содержимого и, если версии совпадают, предоставляют клиенту локальную копию файла вместо выполнения его повторной загрузки из Internet. В результате применения подобного подхода значительно улучшается общая производительность всех клиентов частной сети.
Быстродействие
В большинстве сетевых сред пользователи просматривают Web-узел с целью получения доступа к определенным Web-страницам. Причем, в этом случае происходит кэширование Web-страниц для всех пользователей, даже в том случае, когда доступ к странице имеет только один из пользователей. Некоторые прокси-серверы, такие как Microsoft Proxy, могут просматривать локальную сеть и автоматически обновлять кэш в автономном режиме. При наличии множества кэшированных Web-страниц существенно повышается скорость просмотра в Web. Также ускоряется функционирование и других служб, поскольку на них будет меньше сказываться трафик в Web.
Безопасность
В общем случае прокси-сервер реализует более серьезную систему безопасности, чем сервер NAT, поскольку он получает предварительные сведения относительно обрабатываемых приложений. В этом случае прокси-сервер устанавливает буфер между внутренними клиентами и Internet. Благодаря этому уменьшается вероятность взаимодействия с
клиентами различных "опасных" приложений, которыми изобилует Internet. Следует отметить, что большинство прокси-серверов регистрируют различные проходящие через нихданные, а также отслеживают различные типы информации.
Обычно для серверов, которые требуют прямого доступа из Internet, создается так называемая экранируемая подсеть (или DMZ). Таким образом гарантируется безопасность, поскольку серверы фактически не находятся ни в Internet, ни во внутренней сети. Благодаря этому DMZ конфигурируется в более открытом режиме, чем в случае с частной сетью, включающей клиентов. Подобная гибкость требуется для некоторых служб, которые в настоящее время являются распространенными для Web-серверов. Кроме того, DMZ устанавливает взаимосвязи между клиентскими частными сетями и DMZ. В результате эти сети становятся еще более открытыми. Это возможно не только вследствие технологических особенностей DMZ, но также благодаря определению настроек безопасности и организации подсетей в соответствии с запросами пользователей. Для большинства домашних сетей использование подобного уровня безопасности и сложности является нецелесообразным. Однако, при связывании в сеть филиалов офисов применение DMZ оправдывает себя.
Ограничение доступа к определенным узлам также входит в перечень основных обязанностей прокси-сервера. Сервер может использовать технические приемы, блокирующие доступ к определенным узлам Internet со стороны работников компании (разумеется, в случае, если эти узлы не соответствуют определенным требованиям). Некоторые серверы даже могут контролировать отдельные списки серверов с ограничениями для групп пользователей, которым присвоены различные уровни безопасности.
Недостатки прокси-серверов
В качестве недостатка можно отметить тот факт, что при наличии прокси-сервера процесс настройки клиента значительно усложняется. Каждый клиент необходимо конфигурировать с учетом запросов прокси-сервера. В настоящее время большинство новых прокси-серверов используют технические приемы, позволяющие облегчить выполнение подобной задачи. Утилита по конфигурированию клиентов Microsoft Ргохувыполняет большой объем работы по причине наличия дополнительного компонента, информирующего уровень Winsock о наличии прокси-сервера. В этом случае прокси-сервером могут пользоваться приложения, не знающие о наличии проксисервера, но подготовленные к использованию уровня Winsock.
Не забывайте, что прокси-сервер функционирует на уровне приложения модели OSI. По этой причине ограничиваются функциональные возможности некоторых протоколов, которые нельзя использовать совместно с прокси-сервером. Например, клиенты не могут передавать через прокси-сервер пакеты протокола контроля сообщений (ICMP — Internet Control Message Protocol), поэтому в данном случае эхо-тестирование не выполняется. Аналогично, среда NetBIOS клиента не учитывает наличия прокси-сервера, поэтому клиент не может выполнять функции NetBIOS (типа NET USE). Также с помощью прокси-службы нельзя передавать пакеты протоколов туннелирования "точка-точка" (РРТР — Point-to- Point Tunneling Protocol) и протокола туннелирования уровня 2 (L2TP — Layer 2 Tunneling Protocol).
А теперь рассмотрим пример, иллюстрирующий необходимость осведомленности клиентской системы о наличии прокси-сервера. Предположим, что используется протокол передачи файлов (FTP — File Transfer Protocol). Пользователи многократно конфигурируют свои браузеры Internet с использованием информации о прокси-сервере даже в том случае, если не выполняется процедура конфигурирования. Если пользователь в строке адреса браузера вводит команду ftp://ftp.microsoft.com,браузер может связаться с сервером, поскольку он получает информацию о наличии прокси-сервера. Однако, если пользователь переходит в командную строку и вводит команду ftp ftp.microsoft.com, подклю-
чение не реализуется, Это связано с тем, что в среде командной строки отсутствует информация о прокси-сервере. Сведения о прокси-сервере доступны на уровне командной строки только в том случае, если уровень Winsock осведомлен о наличии прокси-сервера. В Microsoft Proxy Sewer это достигается путем поддержки процедуры конфигурирования прокси-клиента, которая, используя автоматизированную подпрограмму, реализует конфигурирование браузера и Winsock.
Помимо этого прокси-серверы требуется своевременно обновлять с целью поддержки новых приложений. Также полезным является участие пользователя в конфигурировании портов и настроек. Эта функция сети является чрезвычайно важной, поскольку она влияет на безопасность самой сети. Если порты приложения были открытыми на протяжении длительного срока, существует опасность получения доступа к внутренним ресурсам, даже если этого не требуется в данный момент времени. Если степень открытости проксисервера является недостаточной, внутренние приложения не могут корректно выполняться. В обязанности администратора прокси-сервера включается проведение соответствующих исследований, а также принятие решения относительно того, какие именно приложения и конфигурации будут поддерживаться на данном прокси-сервере.
Сервер трансляции сетевых адресов
Подобно прокси-серверам, сервер NAT обеспечивает совместное использование несколькими клиентами единственного подключения к внешней сети типа Internet. Однако, в данном случае для совместного использования подключения применяется совершенно иной подход. Самое главное отличие заключается в том, что сервер NAT выполняется на сетевом и транспортном уровнях модели OSL но не на уровне приложений.
Основное отличие между сервером NAT и прокси-сервером заключается в том, что при обращении к прокси-серверу клиентские приложения должны быть осведомлены о наличии прокси-сервера, пересылая в этом случае запросы прокси-серверу вместо получения прямого доступа к Internet. При работе с сервером NAT у клиента создается впечатление того, что он непосредственно подключен к Internet, Сервер NAT фактически изменяет пакеты во время их прохождения через сервер.
Если протокол приложения содержит сведения относительно IP-адреса, сервер NAT может изменять эти данные. Во избежание подобной проблемы сервер NAT Windows 2000 осуществляет замену частного IP-адреса и порта на общедоступный адрес и отображенный порт. В результате, целевой компьютер "считает", что в качестве источника выступает внешний интерфейс сервера NAT.
Сервер NAT в процессе трансляции обновляет IP-адрес и номера портов TCP/UDP для пакетов. Обычно трансляция сетевого адреса основывается на трансляции следующих данных.
IP-адресов в IP-заголовке.
Номеров TCP-порта в TCP-заголовке.
Номеров UDP-порта в UDP-заголовке.
Этой информации достаточно для реализации служб сервера NAT по обновлению пакета. Затем соответствующий трафик возвращается порождающему его клиенту. Любая трансляция, при осуществлении которой не учитываются эти три позиции, требует выполнения дополнительной работы со стороны компонентов программного обеспечения, именуемых редакторами М Т. Редактор NAT выполняет обновления IP- пакета, не достигающие уровня базовой трансляции.
В следующем перечне описываются две распространенных ситуации, требующие использования редакторов NAT.
IP-адрес, TCP-порт или UDP-порт хранятся в виде полезнойнагрузки. Сервер FTP сохраняет IP-адреса в FTP-заголовке для команды FTP PORT. Если сервер NAT не выполняет должным образом трансляцию IP-адреса в заголовке FTP и изменяет пакет, подключение будет нарушено.
TCP или UDP не применялись для идентификации потока данных. Туннели РРТР не используют заголовки TCP или UDP. Вместо этого применяется заголовок обобщенной инкапсуляции маршрутизации (GRE— Generic Routing Encapsulation) и идентификатор туннеля, который сохраняется в заголовке GRE, определяя при этом поток данных. Если сервер NAT не выполняет надлежащим образом трансляцию идентификатора туннеля в заголовке GRE, подключение будет нарушено.
В Windows 2000 существуют редакторы NAT для следующих протоколов.
FTP.
ICM Р.
РРТР.
NetBIOS поверх TCP/IP.
Для некоторых протоколов программное обеспечение прокси-сервера также включено в состав протокола маршрутизации Windows 2000 NAT. Используемые при этом программы активизируют службу NAT, выступающую в роли прокси-сервера, обеспе- чиваюшего взаимодействие протоколов и клиентов. Это программное обеспечение включает следующие позиции.
Н.323
Direct Play
Регистрация ILS, основанная на использовании LDAP
Вызов удаленныхпроцедур(КРС — Remote Procedure Call)
Преимущества сервера NAT
Поскольку клиенты могут находиться в частной сети, локальная сеть может поддерживать стандартные не назначаемые IP-адреса (Ю.х.х.х, 172.16.Х.Х—172.32.х.х и 192.168.х.х), как это и происходит в случае с прокси-сервером. В результате обеспечивается "приватизация" сети, когда для получения доступа к ресурсам Internet пользователи еще могут активизировать эти клиенты.
Большинство приложений передаются через сервер NAT без всяких проблем и изменений. В Windows 2000 поддерживается FTP, ICMP и РРТР наравне с редакторами NAT.
Ниже описываются некоторые дополнительные преимущества, связанные с применением сервера NAT.
Сервер NAT прост в установке, и после завершения конфигурирования он является самодостаточным.
Сервер NAT обеспечивает функционирование наследственных приложений даже в том случае, если они не учитывают наличия Winsock и прокси-сервера.
Сервер NAT обеспечивает коммуникации с внешними клиентскими компьютерами, причем в этом случае не накладываются какие-либо дополнительные требования, за исключением возможности использования TCP/IP.
Множество недорогих аппаратных решений NAT доступны для малых офи- сов/домашних офисов (SOHO — Small Office/Home Office).
Редакторы NAT поддерживают серверы ICMP (Ping) и РРТР, используемые при передаче пакетов через сервер.
Недостатки серверов NAT
Серверы NAT защищены в гораздо меньшей степени, чем прокси-серверы. Эти типы серверов просто изменяют пакеты, в то время как прокси-сервер должен получить информацию о приложении, породившем данный трафик. Многие администраторы рассматривают сервер NAT в качестве стандартного маршрутизатора, и это мнение не лишено оснований. Достаточно просто загрузить клиентские инструментальные средства, которые реализуют обход серверов NAT. Однако, зависеть от системы безопасности в "приватизированной" сети не всегда целесообразно.
Однако, если сервер был установлен с помощью соответствующего пакета фильтрации, вполне возможно “осмотреться1 и обеспечить безопасность в большинстве случаев. Учитывая эти моменты, крайне нежелательно использовать базовую службу NAT в качестве замены для брандмауэра.
Даже при использовании редактора NAT невозможно выполнить трансляции с использованием протоколов, не ПОЗВОЛЯЮЩИХ изменять информацию IP-заголовка. В результате передача пакетов данных нескольких протоколов через сервер NAT будет невозможной. Эти протоколы перечислены ниже.
Протокол безопасности Internet (IPSec — Internet Protocol Security).
Облегченный протокол доступа к каталогам (LDAP -- Lightweight Directory Access Protocol).
Простой протокол сетевого управления (SNMP— Simple Network Management Protocol).
Вызов удаленныхпроцедур (RPC — Remote Procedure Call).
Компонентная объектная модель (COM — Microsoft Component Object Model).
Чтобы избежать появления подобных проблем, необходимо найти другое решение для вашего устройства, поддерживающего общедоступное подключение, или же перестроить используемую сетевую архитектуру.
Брандмауэры
Довольно нелегко обобщить описание брандмауэров, поскольку каждое правило имеет большое число исключений. Брандмауэры уже применяются давно и обычна основаны на системах UNIX, хотя в последние годы возникли и другие модификации. Например, компания Microsoft выпустила программный продукт брандмауэра под названием Internet Security and Acceleration (ISA) Server 2000, основанный на Windows 2000. В этом программном продукте объединены возможности нескольких брандмауэров.
В общем случае брандмауэры основаны на использовании серверов NAT, проксисерверов либо применяют возможности обоих серверов, Им также присущи некоторые пользовательские дополнения. Большинство брандмауэров можно применять в частных сетях, а большинство из них выполняют кэширование Web-узлов для клиентов.
Следует отменить, что, несмотря на то, что в разделе книги, посвященном использованию прокси-серверов и серверов NAT, рассматриваются всевозможные правила и руководства, вся эта информация "повисает в воздухе", когда речь идет о свойствах брандмауэров. Брандмауэры, основанные на NAT, не обязательно пропускают трафик IPSec. Многие брандмауэры могут направлять протоколы, которые реализуют множество возможностей.
В качестве примера рассмотрим возможности Microsoft ISA Server. Этот программный продукт реализует комбинацию возможностей прокси-серверов и серверов NAT, а также другие дополнительные свойства. Таким образом, вы обращаетесь к продукту, учитывающему требования приложения, когда это необходимо. В этом случае также возможна обработка таких потоков данных, как трафик РРТР, пересекающий службу.
Брандмауэры достаточно дорогостоящи в эксплуатации, Они являются узко специализированными, И, если сетевой администратор разрабатывает сеть, необходимо первым делом учитывать наличие брандмауэра. Вопросам инсталляции и конфигурирования брандмауэров посвяшены целые книги. Администратор туннеля должен гарантировать прохождение туннельного трафика через брандмауэр или же работу с использованием брандмауэра таким образом, чтобы обеспечивались необходимые функциональные возможности и уровень безопасности.
Граничные серверы
Термин граничный сервер в последнее время становится все более популярным. Подобное название получил сервер, расположенный последним, на краю проектируемой сети. Обычно в роли подобного сервера выступают брандмауэры, но также может использоваться система любого другого типа. При развертывании проекта HappyVPN туннельные серверы Windows 2000 обеспечивают фильтрацию пакетов, сконфигурированную с целью обеспечения зашиты сети.
Поскольку Windows 2000 включает службы сервера NAT, прокси-серверы получили широкое распространение. Сетевые запросы все более ориентируются на частную и/или динамическую адресацию. Каким образом это обстоятельство оказывает влияние на развертывание сетей VPN? Начнем рассмотрение этого вопроса с перечисления некоторых фактов.
Пакеты РРТР могут перемещаться через сервер NAT Windows 2000.
Пакеты L2TP/lPSec не могут перемещаться через сервер NAT.
Пакеты РРТР и IPSec не могут передаваться через прокси-сервер, если только другая служба не направит их.
Брандмауэры обычно могут передавать весь трафик VPN, однако, перед их установкой не мешает в этом убедиться.
Трансляция сетевых адресов в Windows 2000
Операционная система Windows 2000 поддерживает две реализации NAT. Свойство совместного использования подключений Internet (Internet Connection Sharing) присуще практически всем версиям Windows 2000 и именно это свойство позволяет Windows 2000 Professional совместно использовать подключения с помощью сервера NAT.
Windows 2000 Professional: совместное использование подключений Internet
Компания Microsoft первоначально анонсировала сервер NAT в операционной системе Windows 98 Second Edition. Эта версия представляла собой простой и не настраиваемый сервер, позиционирующийся в качестве решения обобщенной среды для домашних пользователей, совместно использующих подключения, которые завершаются на их рабочих станциях. Сервер NAT включен в версию Windows 2000 Professional в качестве объекта, реализующего совместное использование подключений (ICS— Internet Internet Connection Sharing), разработанного в качестве эквивалента службы Windows 98.
Использование ICS на компьютере, устанавливающем подключение к Internet, является обычным явлением. Подключение может реализоваться с помощью удаленного доступа или путем соединения с другим устройством (например, с модемом DSL). Объект ICS поддерживает трансляцию сетевого адреса, адресацию и службы определения имен для всех компьютеров локальной сети.
Клиенты локальной сети могут использовать приложения Internet, такие как Internet Explorer, таким образом, как будто бы они непосредственно подключены к Internet. В этом случае не требуется выполнения какого-либо конфигурирован и я, поскольку пакеты обновляются при перемещении через службу NAT.
При этом может возникнуть необходимость в конфигурировании определенных приложений и служб на компьютере 1CS, в результате чего они будут функниониро- вать требуемым образом в составе обшедоступного интерфейса. Можно определить исходящий порт для определенного приложения, а также ассоциировать соответствующие порты с помошью любого трафика, передающегося в обратном направлении. Иногда подобная конфигурация необходима при проведении сетевых игр в Internet.
Кроме того, если службы входящего сервера поддерживаются с помощью подключения ICS, необходимо определить входящий порт и затем указать на сервере внутренний IP-адрес, который действительно соответствует определенной службе. Например, если FTP-сервер конфигурируется в частной сети, объект ICS допускает соответствие порта 21 адресу, выделенному из Internet. Тогда для каждой конкретной службы можно сконфигурировать отдельный сервер.
Объект ICS также располагает службой, именуемой распределитель DHCP (DHCP Allocator). Эта служба является производной для сервера с протоколом динамического конфигурирования хоста (DHCP — Dynamic Host Configuration Protocol) и разрешает конфигурирование локальных клиентов для получения адресов, которые поддерживаются DHCP. Компания Microsoft не поддерживает полную службу DHCP в Windows 2000 Professional. Поэтому в отличие от полного сервера DHCP, DHCP Allocator не является настраиваемым и располагает установленными диапазонами и опциями.
При выполнении 1CS проке и-служба системы доменных имен (DNS ^^——“_— Domain Name System) обращается к порту 53 и передает DNS все запросы с помощью совместно используемого устройства. В этом случае система Professional конфигурируется для использования в качестве DNS. При конфигурировании локальной DNS в частной сети для клиентов появляются дополнительные трудности.
В операционной системе Windows 2000 Professional автоматически конфигурируются несколько настроек. Пользователь не может изменять перечисленные ниже настройки, определенные по умолчанию.
IP-адрес внутреннего интерфейса является заданным по умолчанию шлюзом для частной сети (J92.168.OJ) с маской подсети 255.255.255.0.
Включается свойство AutoDial, поэтому, если доступ к ресурсу требуется вне локальной подсети, Windows 2000 Professional автоматически подключается к внешнему подключению.
Объект ICS включает заданный по умолчанию статический IP-маршрут для локальной частной сети, проложенный по направлению к внешнему общедоступному подключению,
Распределитель DHCP устанавливается, начиная с диапазона адресов 192.168.0.0 и маски подсети 255.255.255.0. Этот диапазон не конфигурируется.
Объект ICS активизирует DNS-прокси, который передает все DNS-запросы порта 53 по адресу, который настраивается для совместно используемого устройства. При этом используется служба ICS.
Объект ICS, учитывая наличие не изменяемых настроек, может показаться довольно ограниченным по своим возможностям. Однако следует иметь в виду, при разработке ICS преследовалась цель создания простого и легкого метода совместного использования подключений. Если требуется обеспечить большую степень гибкости для подключения, граничный сервер должен выполнять Windows 2000 Server, на котором установлена полнофункциональная версия NAT.
Windows 2000 Server: полнофункциональный сервер NAT
В отличие от свойств, включенных в состав Windows 2000 Professional, Windows 2000 Server содержит предельно гибкую версию NAT, являющуюся составной частью службы маршрутизации и удаленного доступа (RRAS — Routing and Remote Access Service). Эта версия является настраиваемой в большинстве сетевых сред. Интерфейс реализован в виде подключаемого модуля RRAS в качестве дополнительного протокола маршрутизации. Ниже перечислены некоторые из основных отличий между ICS и полнофункциональным сервером NAT.
Внутренний IP-адрес может выбираться в любом диапазоне адресов. В отличие от ICS, служба RRAS NAT позволяет выполнять простое конфигурирование внутренних IP- адресов подсети. Подобный подход позволяет серверу NAT поддерживать существующие подсети, которые могут встраиваться в уже существующие сети.
Свойство AutoDial может легко отключаться с помощью службы RRAS NAT. Наряду с дополнительными конфигурационными возможностями RRAS, среди свойств подключения имеется настройка удаленного доступа. Это свойство не является слишком нужным, если подключение к Internet установлено на постоянной основе, как, например, при использовании DSL или кабельной сети. Однако, при работе с интернациональными узлами подобный подход может сыграть существенную роль.
Могут легко добавляться дополнительные статические маршруты или протоколы маршрутизации. Поскольку службы NAT поддерживаются в RRAS, все возможности RRAS могут использоваться совместно с интерфейсами NAT.
Возможно конфигурирование полнофункционального сервера DHCP вместо службы DHCP Allocator. В этом случае можно использовать стандартные опции DHCP. Поскольку сервер NAT также является сервером DHCP, важно сконфигурировать эту службу для ответов на запросы с использованием внутреннего интерфейса.
Диапазон адресов DHCP Allocator может изменяться. Также можно перенаправлять настройки DNS на внутренний адрес. Во многих филиалах офисов используется отдельная система DNS для внутреннего определения имен. Если сеть была создана таким образом, что сервер NAT использует DNS ISP, стандартные опции DHCP позволяют устанавливать отдельные настройки для внутренних клиентов. Так удобнее поступить, несмотря на то, что сервер ICS можно сконфигурировать таким образом, что он будет указывать на внутреннюю систему DNS.
Служба RRAS NAT позволяет гибко реагировать на запросы приложения и располагает ОПЦИЯМИ по конфигурированию служб. Несмотря на то, что большая часть приложений может выполняться без проблем в среде со стандартными ди нам и - ческими назначениями портов, некоторые приложения требуют выполнения статических назначений. Также служба RRAS обеспечивает дополнительные конфигурации для статических портов и назначений IP-адресов.
Служба RRAS NAT может отображать внешние IP-адреса на внутренний адрес и порт. Подобный подход позволяет системам в частной сети взаимодействовать с внешними службами. Это свойство также позволяет разделять службы на отдельные частные системы.
Совет
Одна из наиболее часто встречающихся проблем при работе с ICS и NA Т связана с периодом ознакомления нового администратора с различными возможностями Windows 2000. Часто администраторы предпринимают попытку одновременного обращения к обеим службам. И, несмотря на то, что Microsoftсознательно затрудняет реализацию подобной возможности, все же это возможно.
Различные серверные сетевые проекты
При планировании среды VPN приходится сталкиваться с бесконечным количеством возможностей. Для получения полного представления о влиянии имеющихся отличий проектов необходимо обладать познаниями на уровне сетевого или туннельного администратора. В следующих разделах перечисляются некоторые возможности, которые учитываются при проектировании. При этом обсуждаются их преимущества и недостатки. Первый проект представлен на рис. 8.1.
Рис. 8.1. Размещение туннельного сервера под прикрытием брандмауэра
Эта конфигурация, допускающая размещение туннельного сервера за брандмауэром, поддерживает установленный брандмауэр. на котором выполняется протокол направления прямо в Internet. Данная система является единственной, реализующей непосредственное подключение к Internet. Она сконфигурирована для передачи соответствующих протоколов и портов, служащих для поддержки не только туннельного сервера, но также и удовлетворяет потребности клиентов в инструментальных средствах Internet.
Ниже перечисляются преимущества, появляющиеся в результате помещения туннельного сервера за брандмауэром.
При реализации этого проекта обеспечивается единственная точка подключения к Internet, что значительно упрощает мониторинг и управление.
Значительно проще формируются проекты сетей.
В роли брандмауэра может выступать посторонняя система, которая специфицируется в качестве брандмауэра, а не подключаемого модуля. Комбинация различных операционных систем приводит к достижению более высокого уровня безопасности.
е Данная конфигурация, возможно, не потребует использования нового аппаратного обеспечения, исключая туннельный сервер.
Туннельный сервер не подключен непосредственно к Internet. Брандмауэр передает на туннельный сервер только трафик, относящийся к туннелю.
Ниже приводится перечень недостатков, проявляющихся при помещении туннельного сервера за брандмауэром.
Поскольку в данном случае имеется только единственная точка подключения к Internet, увеличивается риск появления атак со стороны хакеров. Чрезвычайно важно иметь план действий на случай сбоя в работе аппаратного обеспечения.
Существует вероятность негативного влияния на скорость передачи данных в корпоративной сети в зависимости от туннельного трафика. Поскольку брандмауэр обрабатывает весь трафик, важно, чтобы аппаратное обеспечение учитывало возможности удовлетворения повышенных требований к пропускной способности.
Для большинства администраторов задача направления трафика на сервер корпоративной сети без предварительной аутентификации не является любимым занятием, Причем, это совершенно не зависит от того, является трафик защищенным или нет.
В следующем проекте брандмауэр не только выполняет свойственные ему функции, но также функционирует в качестве туннельного сервера для внешних клиентов (рис. 8.2).
Ниже описываются преимущества, достигаемые при помещении брандмауэра и туннельного сервера в одной и той же системе.
При реализации этого подхода обеспечивается единственная точка подключения к Internet, что значительно упрощает мониторинг и управление системой.
В роли брандмауэра может выступать посторонняя система, которая выступает именно в роли брандмауэра, а не подключаемого модуля. Соединение различных операционных систем обычно способствует более успешной реализации мер защиты.
Данная конфигурация, скорее всего, не потребует установки нового аппаратного обеспечения.
Ниже описываются недостатки, проявляющиеся при размещении брандмауэра и туннельного сервера в одной системе.
Лишь последние версии брандмауэров используют интерфейсы программирования приложений брандмауэров в Windows 2000 (API), поэтому данное решение может потребовать программного обеспечения сторонних производителей вместо использования функциональных возможностей туннелей Windows 2000. При использовании этих программных компонентов обеспечивается не столь эффективная практическая реализация технологии VPN или же не используются на практике многие свойства Windows 2000. И, наконец, придется затратить немало усилий на администрирование для реализации процесса развертывания брандмауэров с учетом полной поддержки платформы Windows 2000.
Поскольку в данном случае имеется только единственная точка подключения к Internet, увеличивается вероятность атак со стороны хакеров. Чрезвычайно важно иметь план действий на случай сбоя в работе аппаратного обеспечения.
Рис. 8.2. Брандмауэр и туннельный сервер выступают в качестве одной и той же системыРис. 8.2. Брандмауэр и туннельный сервер выступают в качестве одной и той же системыПоявляется вероятность негативного влияния
Рис. 8.2. Брандмауэр и туннельный сервер выступают в качестве одной и той же системы
Рис. 8.2. Брандмауэр и туннельный сервер выступают в качестве одной и той же системы
на скорость передачи данных в корпоративной сети в зависимости от туннельного трафика. Поскольку брандмауэр обрабатывает весь объем трафика, важно,
чтобы аппаратное обеспечение учитывало повышенные требования, предъявляемые к пропускной способности аппаратного обеспечения.
В следующих схемах размещения туннельного сервера в области DMZ применяется существующий брандмауэр, а также добавляется область DMZ (или применяется существующая область DMZ) с целью установки туннельного сервера. В данной конфигурации входящий зашифрованный трафик просто передается туннельному серверу, который аутентифицирует трафик, декодирует его и передает обратно бранлмау- эру. Затем открытый трафик передается назад в локальную внутреннюю сеть. При этом используются маршруты, определенные в списках управления доступом (ACL — Access Control List). Соответствующая иллюстрация приведена на рис. 8.3.
Зо*а WZ
Рис. 8.3. Размещение туннельного сервера в области DMZ
Среди преимуществ этого проекта можно отметить следующие.
Довольно легко устанавливать туннельный сервер в области DMZ, поскольку большинство корпораций уже располагают определенными ранее DMZ.
Туннельный сервер не подключен напрямую к Internet, и брандмауэром направляется лишь трафик, имеющий отношение к туннелю.
t В этом проекте обеспечивается единственная точка подключения к Internet, что значительно упрощает процесс мониторинга и управления.
В роли брандмауэра может использоваться внешняя система, которая в данном случае выступает именно в роли брандмауэра, а не подключаемого модуля. Объединение различных операционных систем обычно способствует достижению большего уровня безопасности.
Данная конфигурация быстрее всего не потребует установки нового аппаратного обеспечения.
Недостатки, проявляющиеся при размещении туннельного сервера в области DMZ.
Большинство администраторов не проявляют склонность к работе с незашифрованным трафиком в области DMZ (выбор между использованием ACL либо отказом от применения ACL).
Поскольку в данном случае имеется только единственная точка подключения к Internet, увеличивается вероятность атак со стороны хакеров. Чрезвычайно важно иметь план действий на случай сбоя в работе аппаратного обеспечения.
Возможно негативное влияние на скорость передачи данных в корпоративной сети (в зависимости от туннельного трафика). Поскольку брандмауэр обрабатывает весь трафик, важно, чтобы аппаратное обеспечение учитывало наличие повышенных требований к пропускной способности аппаратного обеспечения.
Следующая рассматриваемая конфигурация аналогична той, которая приводилась на рис. 8.3, с одним отличием: туннельный сервер в данном случае является групповой системой, а внутренний интерфейс связан непосредственно с локальной корпоративной сетью (рис. 8.4).
Рис. 8.4 Размещение туннельного сервера в DMZи в корпоративной сети
Преимущества размещения туннельного сервера в области DMZ и в корпоративной сети будут следующими.
Довольно легко добавить туннельный сервер к DMZ, поскольку большая часть корпораций уже располагает определенными областями DMZ.
Туннельный сервер не связан непосредственно с Internet, и с помощью брандмауэра передается только трафик, имеющий отношение к туннелю.
Если весь трафик проходит через брандмауэр, возможна только одна точка подключения к Internet. Вследствие этого значительно сложнее реализовать меры безопасности для данной системы, но значительно облегчается мониторинг и управление системой.
В качестве брандмауэра может выступать внешняя система, которая в данном случае является именно брандмауэром, а не подключаемым модулем. Соединение различных операционных систем обычно способствует достижению большей степени безопасности.
Данная конфигурация, скорее всего, не потребует модернизации аппаратного обеспечения.
Брандмауэр просто передает зашифрованный трафик туннельному серверу; в его функции не входит обработка дешифруемого трафика.
Довольно просто сконфигурировать туннельный сервер для корпоративных клиентов, которые нуждаются в установке исходящих туннелей.
Недостатки данного проекта будут следующими.
Поскольку в данном случае имеется только единственная точка подключения к Internet, увеличивается вероятность атак со стороны хакеров. Чрезвычайно важно иметь план действий на случай сбоя в работе аппаратного обеспечения.
Брандмауэр должен обладать возможностью направлять трафик IPSec с целью обработки трафика L2TP.
Возможно негативное влияние на скорость передачи данных в корпоративной сети (в зависимости от туннельного трафика). Поскольку брандмауэр обрабатывает весь трафик, важно, чтобы аппаратное обеспечение учитывало наличие повышенных требований к пропускной способности аппаратного обеспечения.
В альтернативном варианте проекта брандмауэр помещается непосредственно в Internet. При этом он сконфигурирован для передачи всего трафика, имеющего отношение к туннелю, групповому туннельному серверу. Внутренний интерфейс туннельного сервера непосредственно связан с локальной корпоративной сетью. В качестве заданного по умолчанию клиентского маршрута в Internet применяется Microsoft Proxy Server, который затем передает трафик либо брандмауэру, либо туннельному серверу, в зависимости от места назначения (рис. 8.5).
Преимущества нахождения брандмауэра непосредственно в Internet и размещения туннельного сервера между брандмауэром и прокси-сервером проявляются в следующем.
Туннельный сервер не связан непосредственно с Internet, и с помощью брандмауэра направляется только трафик, имеющий отношение к туннелю.
При реализации подобного подхода допускается единственная точка подключения к Internet, что значительно упрощает процесс мониторинга и управления.
В роли брандмауэра может использоваться внешняя система, которая в данном случае выступает именно в роли брандмауэра, а не в качестве дополнительного модуля. Соединение различных операционных систем обычно способствует достижению более высокого уровня безопасности.
Брандмауэр просто передает зашифрованный трафик туннельному серверу; в его обязанности не входит обработка дешифруемого трафика.
Облегчается конфигурирование туннельного сервера для корпоративных клиентов, которые нуждаются в установке исходящих туннелей.
Использование Microsoft Proxy Server для локальных корпоративных сетей обеспечивает все преимущества WinProxy и технологии кэширования при обеспечении безопасности для брандмауэра.
Ниже перечислены недостатки этого варианта проекта.
Поскольку в данном случае имеется только единственная точка подключения к Internet, увеличивается вероятность атак со стороны хакеров. Чрезвычайно важно иметь план действий на случай сбоя в работе аппаратного обеспечения.
Появляется возможность негативного влияния на скорость передачи данных в корпоративной сети (в зависимости от туннельного трафика). Поскольку брандмауэр обрабатывает весь трафик, важно, чтобы аппаратное обеспечение подбиралось с учетом повышенных требований, предъявляемых к скорости передачи данных.
Данная конфигурация быстрее всего потребует приобретения дополнительного аппаратного обеспечения.
Поскольку проект шлюза, как минимум, включает три системы, с этой инсталляцией ассоциируются инвестиции в аппаратное обеспечение и затраты на администрирование.
Брандмауэр и/или прокси-сервер можно сконфигурировать для одного подключения к Internet, а туннельный сервер использовать в качестве отдельного подключения. Оба сервера будут групповыми, а внутренние интерфейсы подключаются непосредственно к локальной корпоративной сети. Этот проект показан на рис. 8.6.
СерверMicrosoft ProxyСерверMicrosoft ProxyТуннельный серверТуннельный серверБрандмауэа/г рокси серверБрандмауэа/г рокси серверРис. 8.5. Туннельный сервер находится между брандмауэром и прокси-серверомРис. 8.5. Туннельный сервер находится между брандмауэром и прокси-серверомРис. 8.6. Туннельный сервер и бранд.мау- эр подключены к InternetРис. 8.6. Туннельный сервер и бранд.мау- эр подключены к Internet
Сервер
Microsoft Proxy
Сервер
Microsoft Proxy
Туннельный сервер
Туннельный сервер
Брандмауэа/г рокси сервер
Брандмауэа/г рокси сервер
Рис. 8.5. Туннельный сервер находится между брандмауэром и прокси-сервером
Рис. 8.5. Туннельный сервер находится между брандмауэром и прокси-сервером
Рис. 8.6. Туннельный сервер и бранд.мау- эр подключены к Internet
Рис. 8.6. Туннельный сервер и бранд.мау- эр подключены к Internet
Преимущества данного проекта, реализующего подключение к Internet туннельного сервера и брандмауэра, проявляются в следующем.
В качестве брандмауэра может использоваться внешняя система, которая в данном случае выступает в роли именно брандмауэра, а не в качестве дополнительного модуля. Соединение различных операционных систем обычно обеспечивает достижение большей степени безопасности.
Довольно просто сконфигурировать туннельный сервер для корпоративных клиентов, которые нуждаются в установке исходящих туннелей.
Если Microsoft Proxy Server применяется для корпоратиеного брандмауэра, реализуются все преимущества WinProxy и технологий кэширования.
В данном случае существует не единственная точка подключения к Internet; в результате трафик по направлению к туннельному серверу и от него может быть полностью независим от брандмауэра/прокси. Вероятно, данная конфигурация является наиболее быстродействующей.
Туннельный сервер может быть блокирован при использовании фильтрации пакетов, а также конфигурироваться таким образом, чтобы не реагировать на любой трафик, не ОТНОСЯЩИЙСЯ к туннелю.
Недостатки данного проекта проявляются в следующем.
Это не единственная точка подключения к Internet. Хакер может предпринять атаку на оба сервера.
Многие компании нуждаются в большом объеме документации и в усиленном менеджменте при отслеживании систем, которые подключены как к Internet, так и к корпоративной сети и поддерживают маршрутизацию. Административные затраты возрастают, если дополнительные системы добавляют подключения корпоративной сети к Internet,
Некоторые администраторы заботятся о внедрении сервера Windows 2000, который помогает достичь компромисса с установленной безопасностью локальной корпоративной сети до тех пор, пока функционирующая система оправдывает себя.
Учитывая изложенные выше соображения, автор пришел к выводу, что удобнее всего использовать подключение к Internet туннельного сервера и брандмауэра. Автор принимает схему с прохождением туннельного трафика через брандмауэр, поскольку в этом случае применяется отдельное свойство операционной системы. Однако, при всем этом он отдает предпочтение кэшированию и свойствам конфигурирования Microsoft Proxy. В главе 10 описание процесса маршрутизации несколько усложняется, поскольку в рассмотрение вводится конфигурация, которая зависит от структуры корпоративной подсети. Однако, учитывая требования к безопасности и производительности проекта, данная схема является наиболее предпочтительной для автора.
Различные клиентские сетевые проекты
При работе с большинством сетей из сектора SOHO туннельные администраторы должны учитывать особенность этих сетей, а также обеспечивать рекомендации для пользователей сетевых сред этих типов. Во многих случаях рассмотренные конфигурации можно применять либо по отношению к местоположению филиала офиса, либо к местоположению домашнего офиса, поскольку многие из возникающих в данных случаях проблем являются аналогичными.
Очевидной целью, учитываемой при развертывании туннельного сервера любого типа, является гарантирование безопасности подключения, удобство в работе и надежность. Обычно при развертывании сетей VPN возникают проблемы с маршрутизацией клиентов туннелей. По умолчанию, если подключение основывается на стандартном объекте подключения, Windows 2000 устанавливает подключение VPN к корпоративной сети как для заданного по умолчанию шлюза системы. При реализации подобного подхода происходит генерирование трафика, направляемого от подсоединенного компьютера, не содержащегося в локальной подсети, В сторону подключения VPN. Это удобно только в случае корпоративных сетей, но если клиент при подключении к корпоративной сети пытается получить доступ к Internet, весь трафик должен проходить через VPN, корпоративную сеть и обходить корпоративные брандмауэры. Многие пользователи не заинтересованы в этом, поскольку такой способ медленнее, чем непосредственный доступ к сети. Кроме того, корпоративные брандмауэры отслеживают всю деятельность клиента, даже в том случае, когда клиент поддерживает независимое подключение к Internet.
Подобное стандартное поведение можно изменить, используя фильтрацию, маршрутизацию или комбинацию этих процессов. Более подробно эти вопросы рассматриваются в главе 10. В следующих примерах обратимся к вопросам, которые обсуждались в предыдущем разделе. Вопросы, связанные с обеспечением безопасности, здесь обсуждаться не будут.
Клиентские брандмауэры
Установка брандмауэра по местоположению клиента (рис. 8.7) приводит к появлению наиболее удачного проекта, который, однако, редко применяется на практике. В этом случае полнофункциональный брандмауэр выполняет все необходимые задачи в
удаленном местоположении. Такой подход приводит к значительным накладным расходам. Проблема заключается не только в высокой стоимости при установке брандмауэра, но также и в том, что несутся большие административные затраты на его управление. В ближайшем будущем должны появиться другие программные продукты, которые помогут решить эту проблему. Вполне возможно с помощью Active Directory
реплицировать заданную по умолчанию конфигурацию брандмауэра и распространить информацию по филиалам офисов. Вследствие больших затрат автор не рекомендует развертывать полномасштабные брандмауэры в местоположениях филиалов офисов.
Однако, более простые версии брандмауэров обходятся значительно дешевле.
Преимущества, реализуемые при поддержке брандмауэра на стороне клиента VPN.
Брандмауэр может обеспечивать улучшенную защиту для удаленного местоположения, а также гарантировать безопасную связь.
Поскольку большинство брандмауэров могут направлять IP-протоколы, клиенты получают возможность пользоваться как протоколом РРТР, так и протоколом L2TP/IPSec.
Клиенты, которые сконфигурированы для связи с корпоративной сетью, могут при этом использовать брандмауэр, а также обеспечивать безопасный путь от корпоративной сети к конечной точке клиента. Если трафик наблюдается в локальной сети, он остается защищенным
Многие брандмауэры поддерживают определенную технологию Web-кэширования, которая ускоряет просмотр в Web для удаленного местоположения.
Если реальный компьютер поддерживает подключения из удаленных местоположений, брандмауэр может поддерживать почти любой тип подключения, не обращая внимания на то, имеет ли это подключение тип ISDN, DSL или даже является удаленным подключением.
Рис. 8.7. Размещение брандмауэра в местоположении клиентаРис. 8.7. Размещение брандмауэра в местоположении клиентаместоположении кли-местоположении кли-Недостатки, проявляющиеся при размещении брандмауэра в
Рис. 8.7. Размещение брандмауэра в местоположении клиента
Рис. 8.7. Размещение брандмауэра в местоположении клиента
местоположении кли-
местоположении кли-
ента, будут следующими.
Поддержка брандмауэров является дорогостоящей как с точки зрения аппаратного, так и программного обеспечения.
Большинство современных брандмауэров довольно сложны при установке и конфигурировании, что приводит к крупным административным затратам (однако, эти затраты можно сократить, используя предварительно сконфигурированные элементы).
Для корпоративного администратора важно гарантировать непрерывную поддержку процесса конфигурирования брандмауэров. Если локальный пользователь изменяет конфигурацию, невозможно обеспечение безопасности,
Клиентская служба сервера NAT
Обычно для поддержки совместно используемого подключения к Internet используется простой комплект NAT (рис. 8.8). Эта служба поддерживается Windows 2000, также поддержка этой службы реализуется со стороны других, более специфических аппаратных решений. Даже некоторые кабельные провайдеры и провайдеры DSL разворачивают полные инфраструктуры на базе частных сетей, использующих общедоступное под-
ключение к Internet. Однако, несмотря на широкое использование совместного доступа с помощью NAT, с точки зрения туннельного администратора самой главной проблемой является невозможность передачи протокола L2TP/IPSec с помощью сервера NAT. Обычно этому обстоятельству сопутствуют предложения об изменении стандарта NAT и/или стандарта IPSec. И только вопросом времени является создание более простой процедуры передачи пакетов обоих протоколов, используя туннельный трафик.
Ниже перечислены преимущества подключения, реализуемого с помощью сервера NAT.
Относительная дешевизна. Некоторые из новых аппаратных решений, обеспечи- лающие внедрение серверов NAT, обходятся немногим более 100 долларов США.
Этот проект является весьма несложным в реализации. Большинство аппаратных устройств конфигурируется предварительно; пользователь просто подключает устройство и работает с ним. Даже при использовании Windows 2000 конфигурирование не представляет особой сложности.
Клиенты, которые сконфигурированы для связи с корпоративной сетью, могут связываться с помощью сервера NAT и поддерживать безопасный путь из корпоративной сети до конечной точки клиента. Если трафик прослеживается в локальной сети, он остается безопасным.
Если Windows 2000 поддерживает подключения, желательно поддерживать большинство известных типов соединений, среди которых ISDN, DSL или даже удаленные подключения.
Недостатки, проявляющиеся при использовании службы NAT, будут следующими.
Служба NATнеобеспечиваетвысокойстепенизащиты.Длятуннельногоадми
нистратора важно гарантирование того, чтобы набор NAT мог располагать определенными сконфигурированными фильтрами пакетов.
Служба NAT не передает протокол IPSec, поэтому туннели должны быть модернизованы с учетом использования протокола РРТР.
Применение гибридных решений для клиентских подключений
Многие из новых прокси-серверов (включая и сервер Internet Security and Acceleration (Безопасность и ускорение доступа в Internet) компании Microsoft) обладают некоторыми свойствами службы NAT. В этом случае прокси-серверы выглядят таким образом, как будто они обрабатывают туннельный трафик, хотя речь идет об объединении служб (рис. 8.9).
Преимущества объединения служб NAT с прокси-серверами будут следующими.
Прокси-сервер является защищенным, а также может обеспечивать защиту для удаленного местоположения.
Поскольку сервер NAT может обрабатывать трафик РРТР, клиенты могут прокладывать туннель через граничный сервер.
Клиенты, сконфигурированные для связи с корпоративной сетью, могут СВЯЗЬ! - ваться с помощью брандмауэра и поддерживать безопасный путь от корпоративной сети до клиентской конечной точки. Если трафик просматривается в локальной сети, он по-прежнему остается защищенным.
Прокси-серверы поддерживают технологию Web-кэширования, которая ускоряет просмотр в Web для удаленного местоположения.
Прокси-сервер может поддерживать большинство типов подключений, к которым относятся ISDN, DSL или даже удаленные подключения.
При использовании этой конфигурации проявляются некоторые недостатки.
Протокол IPSec не поддерживается с помощью службы NAT.
Прокси-сервер довольно сложен при установке и конфигурировании, что приводит к большим издержкам при администрировании (однако, они могут быть уменьшены при использовании предварительно сконфигурированных элементов или сценариев).
Для корпоративных администраторов важно гарантировать непрерывное конфигурирование граничного сервера, Если локальный пользователь изменяет конфигурацию, невозможно гарантировать соблюдение безопасности.
Рис. 8.8. Использование протокола РРТР с по- Рис 8.9. Туннелирование с использованием гибридного мощью службы NATподключения общедоступного устройства
Поддержка двух подключений в местоположении удаленного офиса
Другая возможность, реализуемая при установке системы защиты для филиала офиса, заключается в использовании двух серверов, непосредственно находящихся в Internet (рис. 8.10). Один из серверов поддерживает прокси-службы; другой поддерживает маршрутизацию и/или службы NAT. Клиенты используют прокси в качестве заданного по умолчанию шлюза, и прокси пересылает туннельному клиенту весь трафик, предназначенный для корпоративной сети. Если установлена маршрутизация для сети VPN, которая разрешена для известных подсетей, туннельный клиент может быть простым маршрутизатором, что является идеальным решением для отраслевого офиса. Если туннельный клиент получает лишь один адрес, данное подключение совместно используется клиентами удаленной локальной сети. Подобный подход вполне себя оправдывает, но, как всегда, некоторые приложения не могут эффективно выполняться совместно со службами NAT.
Преимущества использования двух граничных серверов в удаленном местоположении проявляются в следующем.
Прокси-сервер является защищенным и может поддерживать безопасность удаленного местоположения.
Сервер N АТ/ маршрутизатор может быть сконфигурирован с целью обеспечения исключительно туннельного трафика, в результате чего гарантируется безопасность.
Рис, 8.10. Два подключения к Internet
Трафик может быть разделен междудвумя подключениями к Internet.
Поскольку набор NAT/маршрутизатор является конечной точкой туннеля, реализуется полная поддержка протокола IPSec.
В качестве набора NAT/маршрутизатор может выступать аппаратное устройство.
Трафик можно легко определить, а также управлять им в удаленной локальной сети.
Некоторые недостатки, проявляющиеся при установке двух граничных серверов на удаленном узле.
Для реализации этого проекта необходимо дополнительное аппаратное обеспечение.
Большинство провайдеров Internet испытывают дополнительную нагрузку при наличии нескольких IP-адресов.
При наличии двух серверов в Internet повышаются требования к управлению.
Трафик корпоративной сети может быть незашифрованным в локальной сети. Чтобы избежать этого, следует сконфигурировать политику IPSec таким образом, чтобы выполнялось кодирование трафика на пути от клиентов LAN до граничного сервера.
Заданная по умолчанию конфигурация допускает получение доступа к корпоративной сети для всех локальных клиентов. Чтобы этого избежать, следует сконфигурировать политику IPSec с учетом шифрования трафика, направленного от клиентов LAN к граничному серверу.
Применение прокси-сервера
в качестве конечной точки туннеля
При использовании этой конфигурации прокси-сервер является туннельным клиентом в дополнение к тому, что имеется подключение к Internet (рис. 8.11). Локальная сеть определена для прокси-сервера, а таблица маршрутизации должна быть сконфигурирована таким образом, чтобы гарантировать надлежащую маршрутизацию либо в Internet, либо в корпоративной сети.
Некоторые преимущества использования прокси-сервера в качестве конечной точки туннеля описаны ниже.
Прокси-сервер обеспечивает безопасность.
Если корпоративные клиенты нуждаются в установке исходящих туннелей, довольно легко сконфигурировать соответствуюши м образом туннельный сервер.
Если Microsoft Proxy Server применяется для корпоративного брандмауэра, обеспечиваются все преимущества Win Proxy и технологий кэширования.
Некоторые недостатки, связанные с использованием прокси в качестве конечной точки клиентского туннеля.
Туннельные клиенты должныограничиваться функциями уровня приложения, и они не могут выполнять команды NetBIOS. Данное ограничение может быть отнесено к свойству, зависящему от требований клиентов, так, как будто все это требуется только для поддержки функциональных возможностей терминального сервера для корпоративных серверов.
Трафик корпоративной сети будет незащищенным в локальной сети, что позволяет локальным клиентам сети получать доступ к корпоративной сети. Для блокирования доступа необходимо сконфигурировать политику IPSec таким образом, что потребуется шифрование трафика, направленного от клиентов LAN к граничному серверу,
Применение сервера NAT в качестве конечной точки туннеля
При использовании этой конфигурации сервер NAT является туннельным клиентом в дополнение к имеющемуся подключению к Internet (рис. 8.12). И снова требуется, чтобы таблица маршрутизации была сконфигурирована и гарантировала надлежащую маршрутизацию либо в Internet, либо в корпоративной сети.
Рис. 8.11. Прокси-сервер, выступающий в роли Рис 8.12. Сервер NAT является конечной точ- конечной точки туннелякой туннеля
Ниже описаны некоторые преимущества, проявляющиеся при назначении серверу NAT роли туннельного клиента, причем сервер NAT в данном случае поддерживает подключение к Internet.
Этот проект достаточно легко настраивается. Можно использовать аппаратные устройства или компьютер под управлением Windows 2000. Независимо от того, какой вариант используется, конфигурирование довольно несложно и легко выполнимо.
Если Windows 2000 поддерживает подключения, желательна поддержка большинства типов соединений независимо от того, относятся ли они к ISDN, DSL или же являются удаленными подключениями.
Клиенты не нуждаются в конфигурировании, поскольку пакеты изменяются с помощью сервера NAT.
Некоторые недостатки, проявляющиеся при использовании этой конфигурации.
Сервер NAT не обеспечивает должного уровня безопасности. Можно настроить фильтрацию пакетов, но это существенно увеличит расходы на администрирование.
Некоторые протоколы не функционируют при использовании сервера NAT.
Вкладывание туннелей из удаленных сетей для достижения безопасности по схеме "точка-точка"
Что же происходит с безопасностью, реализованной по схеме “точка-точка”? Конечно, с помощью серверов NAT и прокси-серверов можно достичь подобного эффекта, но в процессе конфигурирования неоднократно потребуется выполнять дополнительные действия. Если сервер, к которому получен доступ из удаленного местоположения, содержит важные данные, сетевой администратор может потребовать выполнения шифрования с применением протокола IPSec для всего трафика, передающегося по направлению к серверу и от него. На рис. 8.13 показано, каким образом можно реализовать вкладывание туннелей для обеспечения коммуникации и при этом обеспечивать завершенное решение по схеме “точка-точка”.
Преимущества схемы вкладывания туннелей для поддержки безопасности по схеме точка-точка".
Полная защищенность трафика.
Поскольку туннель, связывающий удаленное местоположение, просто передает трафик, решение относительно необходимости трафика "точка-точка" основывается на политике iPSec либо по отношению к местоположению источника, либо относительно места назначения (или в обоих этих местах). В результате, туннельного подключения обеспечивается передача в сети открытого или зашифрованного трафика без дополнительного конфигурирования.
Если для проекта туннеля не требуется абсолютной зашиты, недостатки перевешивают преимущества применения IPSec. Недостатки данного проекта следующие.
Эту среду довольно сложно конфигурировать, но делать это необязательно. После того, как будет сконфигурировано подключение к удаленным узлам, все политики и настройки каталогов реализуются при инициировании формальной регистрации.
Вложенные туннели уменьшают производительность.
Резюме по распределенным сетевым проектам
Конечно, представленный перечень возможных конфигураций не является исчерпывающим. Однако, этим перечнем можно пользоваться как указателем, что поможет сетевым администраторам определить проект и основные направления при разработке сети. Многие организации пожелают ограничить подключения и полностью отделить подключение к Internet от корпоративного трафика. Такой подход вполне возможен и потребует только небольшой модификации приведенных в перечне проектов.
Конфигурированиепрокси-серверов
и серверов NAT
Теперь, когда были изложены основные понятия, связанные с развертыванием серверов NAT и прокси-серверов, рассмотрим процедуры конфигурирования в Windows 2000. В этом разделе не уточняется процесс конфигурирования прокси-сервера, поскольку конфигурация прокси-сервера, имеющая отношение к сетям VPN, основывается на использовании службы RRAS в Windows 2000.
Установка совместно используемого подключения к Internet (ICS)
Обычно, для конфигурирования 1С5применяют два сетевых устройства. Одним из них является сетевой адаптер Ethernet для частной сети, а другим — устройство, выполняющее работу с подключением к Internet. В качестве последнего может применяться другой сетевой адаптер Ethernet или, возможно, удаленное подключение. В описываемом примере 1CS применяется для совместного использования сетевого адаптера Ethernet, подключенного к маршрутизатору ISDN. Для этого примера, адаптеры Ethernet получают наименования “общедоступный” и "частный". В процедуре 8.1 иллюстрируются шаги по установке совместно используемого подключения к Internet на компьютере Windows 2000.
Процедура 8.1. Установка совместно используемого подключения к Internet
Правой кнопки мыши щелкните на значке My Network Places (Мое сетевое окружение) и в контекстном меню выберите опцию Properties (Свойства). Правой кнопкой мыши щелкните на общедоступном интерфейсе Ethernet и выберите опцию
Properties (Свойства). Выберите вкладку Sharing (Общий доступ). Установите флажок Enable Internet Connection Sharing for This Connection (Разрешить общий доступ для этого подключения) (рис. 8.14).
Щелкните на опции Settings (Настройки). Вкладка Applications (Приложения) позволяет администратору конфигурировать приложения, которые нуждаются в использовании определенных ответных портов. Если щелкнуть на кнопке <Add> (Добавить), можно ввести название приложения, а также исходящий порт для него (рис. 8.15). Затем можно указать ответные порты, преобразовав их в статические порты. Обычно этого делать не требуется, поскольку большинство современных сетевых приложений разрешают динамическое распределение ответных портов. Поскольку в этом примере ни одно из приложений не нуждается в указании ответных портов, щелкните на кнопке <Cancei> (Отмена).
Ihtem^tCoDnectJon Shar ingApphrahonО E3
fcjame ofapplication;
fiemote server port number;
I
Р ICP С JJDP
Incoming retpcnse ports:
j4-iSi. 1300-1310.1450!
TCP: ■ г1
UDP Г"
01Cared |
Рис. 8.14. Свойства внешнего интерфейсаРис. 8.15. Добавление определений пр^ожеиия
Щелкните на вкладке Services (Службы) (рис. 8.16). В большинстве конфигураций граничный сервер имеет только один общедоступный IP-адрес, и не все службы выполняются на граничном сервере, В этом примере для игрового сетевого сервера Unreal Tournament конфигурируется новая служба, Щелкните на кнопке <Add>.
Введите название службы, затем укажите порт для этой службы. В случае с игрой Unreal Tournament приложение использует несколько портов, поэтому для каждого из портов следует повторять указанные выше шаги. Выберите протокол, укажите внутренний IP-адрес сервера, выполняющего эту службу, и щелкните на кнопке <ОК> (рис. 8.17).
Если используются заданные по умолчанию записи, при выборе записи появляется окно с запросом относительно ввода внутреннего IP-адреса (рис. 8.18). Описание и номера порта определяются предварительно и не могут изменяться. Щелкните на кнопке <ОК>.
После добавления всех приложений и служб щелкните на кнопке <ОК> для завершения процесса установки. После этого отобразится диалоговое окно, информирующее о том, что для частного сетевого IP-адреса было присвоено значение 192.168.0.1. Щелкните на кнопке Yes (Да) (рис. 8.19).
Удостоверьтесь в том, что все локальные клиенты сконфигурированы с учетом использования динамических IP-адресов, затем протестируйте подключение.
Рис. 8.16. Определенная службаРис. 8.16. Определенная службаРис. 8.17. Установкановой службыРис. 8.17. Установкановой службы
Рис. 8.16. Определенная служба
Рис. 8.16. Определенная служба
Рис. 8.17. Установкановой службы
Рис. 8.17. Установкановой службы
Puc. 8.181 Направление указанной службы вовнутреннюю систему
Рис. 8.19. Диапазон частных IP-адресовРис. 8.19. Диапазон частных IP-адресов
Рис. 8.19. Диапазон частных IP-адресов
Рис. 8.19. Диапазон частных IP-адресов
Установка сервера NAT с помощью RRAS
Если сеть нуждается в дополнительной гибкости, желательно, чтобы на граничном сервере выполнялась операционная система Windows 2000 Server, а сервер NAT был сконфигурирован с применением службы RRAS. Сервер NAT можно конфигурировать с помощью подключаемого модуля маршрутизации и удаленного доступа (Routing and Remote Access). При выполнении процедуры 8.2 демонстрируется, каким образом сервер NAT устанавливается с помощью RRAS.
Процедура 8.2. Установка сервера NAT с помощью RRAS
Щелкните на меню кнопки < Start* (Пуск) и выберите команду Program Files с» Administrative Tools => Routing and Remote Access (Программы =0 Администрирование сф Маршрутизация и удаленный доступ). Активизируйте службу RRAS (если она еще не активизирована до этого момента).
Примечание
Автор рекомендует всегда выбирать опцию Manual (Вручную) в окне мастера. Если система имеет несколько физических сетевых интерфейсов, иногда мастер выбирает неправильную карту. Вместо устранения подобных ошибок проще воспользоваться установкой в ручном режиме. После завершения конфигурирования запустите эту службу. Дважды щелкните в левой панели на опции IP Routing (IP-маршрутизация), правой кнопкой мыши щелкните на опции General (Общие) и выделите опцию New Routing Protocol (Новый протокол маршрутизации).
Выберите опцию Network Address Translation (NAT) (NAT — преобразование сетевых адресов) и щелкните на кнопке <ОК> (рис. 8.20).
Рис. 8.20. Выбор протокола преобразования сетевых адресов
Дважды шелкните на ОПЦИИ Network Address Translation (NAT — преобразование сетевых адресов) левой панели, Затем правой кнопкой мыши шелкните в правой панели и выберите опцию New Interface (Новый интерфейс) (рис. 8.21).
Перечисляются все интерфейсы, как логические, так и физические. Выберите интерфейс, который является общедоступным для частной сети (рис. 8.22). (Не забывайте, что в этом примере интерфейсы именуются Public и Private с целью облегчения идентификации.) Щелкните на кнопке <ОК>.
Выберите опцию Public Interface Connected to the Internet (Общедоступный интерфейс, подключенный к Internet) и установите флажок Translate TCP/UDP Headers (Преобразовывать заголовки TCP/UDP) (рис. 8.23).
Щелкните на вкладке Address Pool (Пул адресов). Если ISP выделяет более одного адреса для подключения, эти адреса могут быть идентифицированы в качестве адресного пула. Если для сетевого проекта требуется использование в частной сети дополнитель-
ных компьютеров для установки соответствия с общедоступным адресом, необходимо определить пул. Провайдер ISP проекта HappyVPN для текущего подключения выделяет пять адресов. Чтобы определить пул адресов, щелкните на кнопке <Add> (Добавить). Для общедоступного адреса заполните поля опций Start Address (Начальный адрес), Mask (Маска) и End Address (Конечный адрес) (рис. 8.24). Щелкните на кнопке <ОК>.
Рис. 8.21. Определение интерфейсов
Рис. 8.22. Выбор подходящего интерфейса
Если сеть создана с учетом обеспечения полной доступности сервера в Internet, служба RRAS может установить соответствие между внешним и внутренним адресами. Не забывайте, что в результате выполнения этой операции частный компьютер полностью отображается в Internet. В итоге он становится мишенью для атак хакеров так же, как будто находится непосредственно в Internet. Однако, это свойство удобно в случае его применения для серверов, использующих большое число портов. Вместо отображения всех портов просто выводится IP-адрес. Щелкните на
кнопке <Reservations> (Резервирования), Введите внешний адрес (он должен находиться в пределах определенного адресного пула), укажите внутренний адрес и установите флажок Allow Incoming Sessions to This Address (Разрешить входящие сеансы для этого адреса). Если флажок не установлен, сервер NAT в дополнение к отображению порта просто отобразит трафик, исходящий от определенного внутреннего адреса к общедоступному адресу (рис. 8.25).
Рис. 8.23. Определение общедоступного интерфейсаРис. 8.23. Определение общедоступного интерфейса
Рис. 8.23. Определение общедоступного интерфейса
Рис. 8.23. Определение общедоступного интерфейса
Рис. 8.25. Отображение внешнего адреса на внутреннюю системуРис. 8.25. Отображение внешнего адреса на внутреннюю систему
Рис. 8.25. Отображение внешнего адреса на внутреннюю систему
Рис. 8.25. Отображение внешнего адреса на внутреннюю систему
В списке резервирования щелкните на кнопке <ОК>.
Выберите вкладку Special Ports (Специальные порты). В этом случае сервер NAT установит соответствие между определенными портами и внутренними серверами. Если некоторая система поддерживает определенные службы, для различных серверов вместо отображения всего адреса можно отображать отдельные порты. Такой подход удобно использовать, если ваш ISP предоставляет только один адрес. С помощью этой конфигурации можно, используя один IP-адрес, распределять различные службы по разным внутренним системам. Щелкните на кнопке <Add> (Добавить).
Puc. 8.24. Определение пула адресов для внутренних систем
Введите информацию для отображения порта. Если ISP выделяет несколько адресов, можно отобразить адрес, который определен в адресном пуле для определенного отображения порта. Определите ВХОДЯЩИЙ порт (порт 80 в рассматриваемом примере), а затем определите внутреннюю систему, которая получает трафик (рис. 8.26). И, наконец, определите порт, куда передается трафик. Обратите внимание, что для внутреннего сервера применяется другой порт. В этом случае внутренний Web-сервер поддерживает внешнюю Web-страницу, используя порт 8080. Если одновременно с этим поддерживается внутренняя Web-страница, можно по-прежнему применять для нее заданную по умолчанию настройку. Щелкните на кнопке <ОК>.
Рис. 8.26. Определение интерфейсов
Щелкните на кнопке <ОК> для закрытия страницы свойств общедоступного интерфейса.
П. Правой кнопкой мыши щелкните в правой панели и выделите опцию New Interface (Новый интерфейс).
Выберите частный интерфейс, который может использовать общедоступный интерфейс. Щелкните на кнопке <ОК>.
Выберите опцию Private Interface Connected to a Private Network (Частный интерфейс, подключенный к частной сети). Обратите внимание, что если сервер поддерживает маршрутизацию между несколькими частными интерфейсами, каждый из них для использования общедоступного интерфейса должен быть определен как частный интерфейс. Щелкните на кнопке <ОК>.
Правой кнопкой мыши щелкните на опции Network Address Translation (Преобразование сетевого адреса) на левой панели и в контекстном меню выберите опцию Properties (Свойства) (рис. 8.27).
При регистрации, заданной по умолчанию, отслеживаются только ошибки. Щелкните на вкладке Translation (Преобразование). Настройки, заданные по умолчанию и определяющие продолжительность интервала времени, обычно хорошо согласуются с большинством сред, однако, может возникнуть необходимость их изменения в зависимости от типа передаваемого сетевого трафика (рис. 8.28).
Щелкните на вкладке Applications (Приложения). Находясь на этой вкладке, можно конфигурировать приложения, которые нуждаются в использовании определенных ответных портов. Чтобы выполнить эти операции, щелкните на кнопке <Add>, введите название приложения и укажите исходящий порт. Затем укажите ответные порты и преобразуйте их в статические порты (рис. 8.15). Обычно, приложения не
требуют этого, поскольку большинство современных сетевых приложений разрешают динамическое распределение для ответных портов. В этом примере ни одно из приложений не требует этого, поэтому щелкните на кнопке (Отмена).
Рис. 8.27. Отображение опций
8.28,приложения
Щелкните на вкладке Address Assignment (НазначениеСэтой
вкладки можнозаданную поподсеть, которую DHCP
Allocator передает внутренним клиентам. Если локальная сеть применяет полный DHCP независимо от того, на данной системе находится ли он или на другом локальном сервере, отмените установку флажка Automatically Assign IP Addresses by Using DHCP (Автоматически назначать IP-адрес с помощью8.29). Это
приведет к отключению службы DHCP
Щелкните на вкладке Name(Определение имени). Если сервер NAT отвечает за передачувнутренней системе DNS, активизируйте это ок
но. Если во внутренней сети установлен DNS, отмените выбор этой опции, а службы NAT при этом будут просто передавать запросы от внутренней системы подобно исходящему трафику любого иного типа. В DNSопреде
ляется имя в локальном пространстве имен, и затем направляются корневым сер- внешниеЩелкните на кнопке <ОК>.
Чтобы наблюдать динамическое отображение, справой кнопки мыши
щелкните на открытом общедоступном интерфейсе и выделите опцию Show Mappings (Показать отображения) (рис. 8.30).
Рис. 8.29. Отображения для клиентов
Рис. 8.30. Общий доступ к интерфейсу,по
В таблице Mapping Table приведены все активные отображения, которые обрабатываются сервером. Обратите внимание, что показаны IP-адрес, порты и протоколы (рис. 8.31).
Рис 8.31. Активные отображения
Общий доступ к подключению VPN
Несмотря на то, что подключения к Internet общедоступны, также можно пользоваться общим доступом к любому типу интерфейса из тех, которые включены в RRAS Если подключение VPN определено как интерфейс в RRAS, эту связь можно использовать совместно. Тогда все частные интерфейсы, определенные в NAT, передают трафик с помощью общедоступного интерфейса. И хотя могут возникать достаточно серьезные нарушения мер безопасности, довольно просто совместно использовать эти связи.
Туннельные администраторы должны учитывать, что совместно использоваться может отдельный инициированный туннель. а не аутентифицированные локальные пользователи могут с помощью этой связи передавать и получать трафик. При определенных обстоятельствах довольно выгодно реализовать совместный доступ к подключению VPN для других пользователей. Шаги, приводящие к этому, рассматриваются в процедуре 8.3.
Процедура 8.3. Совместный доступ к подключению VPN
Правой кнопкой мыши щелкните в правой панели и выделите опцию New Interface (Новый интерфейс). Выберите VPN-интерфейс для совместного использования и щелкните на кнопке <ок>.
Этот текст иногда является источником недоумения для пользователя, однако, выберите опцию Public Interface Connected to the Internet (Общедоступный интерфейс, подключенный к Internet) (рис. 8.32). Активизируйте опцию Translate TCP/UDP Headers (Преобразовывать заголовки TCP/UDP). Щелкните на кнопке <ОК>.
Это подключение использует полномочия, определенные в интерфейсе, что разрешает с помощью службы NAT передачу через подключение VPN любого трафика, который блокируется при использовании параметров маршрутизации. Помните, что служба NAT не занимается вопросами аутентификации; трафик просто просматривается и передается так, как это определено с помощью конфигурирования RRAS.
I V-Iwurk Address TrdnstalkHi Properties - Compaq: - tdylur Str... El I□
General | Address Pod j Special Portt [
H3NetworkAddress Translation (NATjlnteilsce
<* Private nt erf ace connected to private network ^ jpytiiclril»^
P 1гат1МеТСРЛЮР headers (recorrvnended)
T hit option aftowr other computer® la tend end receive data through tht? interface
I ж I Cancel
Puc. 8.32. Совместный доступ к интерфейсу,подключаемому по требованию
Резюме
Устройства, поддерживающие общий доступ к подключению, а также брандмауэры чрезвычайно важны при разработке проектов туннелей, что необходимо учитывать при планировании. Невозможно сконфигурировать и развернуть эффективную среду VPN без координации усилий с администратором этих систем и создателем сети. Кроме того, непрактично приступать к разработке полной туннельной среды и не учитывать возрастающих запросов со стороны пользователей домашних сетей. В настоящее время разрабатываются дополнительные технологии, которые приведут к формированию дополнительных ограничений на совместное использование и безопасность подключений. Все это способствует снижению стоимости при внедрении основных технологий.
9
Диспетчер подключений, политики удаленного доступа и служба MS
Одной из целей создания этой книги является краткое описание шагов, выполняемых в процессе развертывания среды VPN в корпорации. Трудности, появляющиеся в процессе достижения этой цели, связаны с тем, что многие области, затрагивающие процесс разработки, напрямую зависят от нужд вашей корпорации. В этой главе читатель познакомится с некоторыми дополнительными областями, которые могут оказать значительное влияние на процесс разработки. Здесь вы не найдете конкретные инструкции, ибо детали конфигурирования зависят от общего проекта сети. В главе рассматриваются три основных темы.
Диспетчер подключений (Connection Manager). Этот инструмент входит в состав Windows 2000 и позволяет администраторам выполнять развертывание сложных клиентов, облегчая задачи самих пользователей. Это приложение обеспечивает облегченный процесс реализации простого одноступенчатого процесса регистрации для пользователей туннелей, а также удаленных пользователей. При этом сначала определяется устанавливаемая клиентская часть.
Политика удаленногодоступа(RemoteAccessPolicy).В отличиеотWindowsNT4.0,
Windows 2000 позволяет устанавливать различные настройки, которые позволяют активизировать службу RRAS Благодаря этому, настройки и изменения становятся более централизованными и управляемыми.
Служба аутентификации в Internet (1AS — Internet Authentication Service). В состав Windows 2000 входит сервер службы аутентификации удаленных пользователей (RADIUS — Remote Authentication Dial-In User Service), который удовлетворяет потребности в аутентификации в большинстве собственных и посторонних сред. Протокол RADIUS является стандартным промышленным протоколом, используемым для авторизации, аутентификации, а также службы учета, реализующий обеспечение доступа подключений.
Диспетчер подключений
Диспетчер подключенийподдерживает подключения к Internet и внутренней корпоративной сети. При этом становятся доступными гораздо больше свойств, чем при использовании стандартных подключений удаленного доступа. В частности, появляются возможно-
сти по осуществлению пользовательской настройки, а также возникает расширенный набор функций. В результате этого становится возможным обеспечение централизованного подхода к управлению подключениями. Помимо этого, набор администрирования Internet Explorer (IEAK — Internet Explorer Administration Kit) обеспечивает поддержку диспетчера подключений, рассматривая его в качестве одного из параметров подключений.
Диспетчер подключений является весьма гибким инструментом и может использоваться практически в любой среде. К числу наиболее важных свойств относится обеспечение возможности для администратора по установке утилит и приложений на различных стадиях осуществляемого процесса подключения. Несмотря на существование известных ограничений в изменяющейся конфигурации удаленных модемов (ограниченная поддержка возможностей обратного дозвона и многофункциональных утилит модемов), многие из этих ограничений могут быть преодолены путем создания или включения дополнительных приложений, которые могут запускаться на выполнение с помошью диспетчера подключений.
Фирма Compaq развернула диспетчер подключений путем обработки результатов анализа потребностей в модемах удаленного доступа отдельно от среды обеспечения доступа VPN. Эта методика является весьма эффективной в применении при работе с постоянно растущим количеством клиентов, которые располагают постоянными подключениями (DSL или кабельное подключение). Фирма Compaq также "породила" процесс диспетчера подключений для VPN, используя другие решения по организации удаленного доступа. В худшем случае, процесс подключения к Internet, а также к корпоративным туннельным серверам трактуется в виде двухступенчатого процесса, в ходе осуществления которого Windows 2000 подключается в качестве клиента.
Использование диспетчера подключений
Фирма Microsoft при разработке диспетчера подключений стремилась создать своего рода управленческий каркас, сосредоточенный вокруг каналов связей, которые специальным образом предназначаются для клиентов удаленного доступа. В данном случае речь идем об области, относящейся к корпоративным администраторам, поскольку при этом возникает необходимость в загрузке определенных объектов (например, телефонных книг, применяемых при выборе номера доступа ближайшего сервера).
В силу указанных выше причин, сетевому администратору приходится поддерживать сервер телефонных книг. Каждый раз, когда клиент удаленного доступа подключается к корпоративной сети, он проверяет сервер телефонных книг на предмет существования новой телефонной книги. Если телефонная книга обнаружена, клиент выполняет ее загрузку в системе. В силу возможности осуществления подобной операции конечный пользователь может разъезжать по миру и всегда иметь возможность подключаться к любому поддерживаемому местоположению, используя номер телефона удаленного доступа. Корпоративный администратор в этом случае может указать, какой из провайдеров в состоянии обеспечивать удаленный доступ для подопечных ему пользователей. В США компании, как правило, выбирают подключение к определенным провайдерам услуг Internet, в то время как в Европе может потребоваться выбрать другого провайдера. Пользователи могут выбирать провайдеров, основываясь на стоимости и качестве оказываемых ими услуг.
Компании, выполняющие развертывание сетевых сред на основе диспетчера подключений, могут настраивать внешний вид пользовательского интерфейса. Например, диспетчер подключений может быть сконфигурирован таким образом, что подключения удаленного доступа настраиваются индивидуальным образом. В результате, стоит только пользователю щелкнуть мышью на каком-либо логотипе, как он тут же будет подключен к определенному провайдеру услуг Internet. Логотипы могут быть анимированы, в результате чего клиенты могут визуально наблюдать процессы, происходя- шие при установке подключений удаленного доступа.
Помимо этого, туннельные администраторы могут конфигурировать подключения VPN, поскольку в модели Windows 2000 подключения VPN практически идентичны подключениям удаленного доступа, особенно, если учитывать подход, принятый при разработке интерфейсов пользователей. Диспетчер подключений может поддерживать одноступенчатый процесс регистрации в Internet, а также на туннельном сервере одновременно, если речь идет о корпоративной сетевой среде.
Диспетчер подключений обеспечивает развертывание подключений с помощью нескольких методов.
Мастер набора администрирования диспетчера подключений (СМАК — Connection Manager Administrator Kit) обеспечивает для клиентов просмотр пользовательской графики, значков, сообщений, справки, а также телефонных книг. В результате создается среда, которая является уникальной для корпорации.
Для пользователей могут поддерживаться пользовательские телефонные книги. Телефонная книга может быть автоматически загружена, поэтому любые изменения номеров доступа должны осуществляться в централизованном порядке.
Диспетчер подключений может "размножать" приложения и действия. В результате этого клиенты могут выполнять программы в различных точках во время осуществления процесса подключения, включая момент регистрации, отключения, а также действия, предшествующие установке подключения и туннеля,
Клиенты могут выполнять несколько копий диспетчера подключений с целью поддержки множества профилей, которые могут выполняться одновременно. В результате сначала выполняется подключение к провайдеру услуг Internet, а затем — к корпоративному туннельному серверу.
МастерСМАКможет создаватьпрофильслужбы,азатем развертыватьегов качест
ве исполняемого файла, который может распространяться путем выполнения загрузки либо путем его включения в качестве стандартной клиентской конфигурации.
Пользовательский интерфейс подключений в Windows 2000 был значительно упрощен по сравнению с предыдущими версиями Windows. Для этого интерфейса характерна страница свойств, содержашая множество вкладок, позволяющая пользователю определять новые свойства для каждого подключения. В интерфейсе подключений все подключения локальных и глобальных сетей представлены в одной папке. Пользователь может запустить мастер создания нового подключения (Make a New Connection Wizard), затем выполнить шаги, необходимые при создании нового подключения для службы RAS, а также для обеспечения связей удаленного доступа сетей VPN. Если в системе был установлен сетевой интерфейс, Windows 2000 сконфигурирует и активизирует подключение автоматически, предполагая наличие корректных драйверов.
Основная цель, которая преследовалась при разработке диспетчера подключений, заключается в упрощении процесса удаленного доступа. Пользовательский интерфейс подключений был разработан с учетом нужд конечного пользователя; при использовании этого приложения сетевой администратор может передавать параметры подключения клиентам, в результате чего подключения VPN могут управляться централизованным образом. Подобная настройка является весьма полезной для очень больших предприятий и провайдеров услуг Internet, которые испытывают значительные затруднения с системами Windows NT 4, Windows 95 и Windows 98 (при конфигурировании и администрировании большого количества конечных систем). При этом пользователи могут применять результирующие параметры, полученные в ходе развертывания диспетчера подключений, поскольку диспетчер телефонных книг весьма "прозрачно" включается в инфраструктуру пользовательских интерфейсов подключений.
Набор СМАК распространяется в комплекте поставки Windows 2000 Server в качестве дополнительного компонента Windows, входящего в состав группы инструментов мониторинга и управления. Большинство администраторов используют этот набор в
качестве отдельного сервера с целью создания и тестирования профилей диспетчера подключений. Для инсталляции набора СМАК можно воспользоваться приложением установки/удаления программ Windows. Клиентские процедуры диспетчера подключений встроены во все версии операционной системы Windows 2000 Server.
Требования
Диспетчер подключений поддерживается указанными ниже операционными системами Microsoft и требует около I Мбайт свободного дискового пространства на клиентском компьютере. Настоятельно рекомендуется установка на клиентском компьютере наиболее современных сервисных пакетов, выступающих в качестве составной части стандартной конфигурации.
Ниже перечислены операционные системы, поддерживающие клиентов диспетчера подключений Windows 2000.
Windows 98.
Windows 95.
Windows NT Workstation версии 4.0 или более поздней.
Диспетчер подключений требует установки протокола TCP/IP, для поддержки удаленного подключения — телефонные АР! Microsoft (TAPI — Microsoft Telephony API), a для реализации подключений VPN понадобятся протоколы туннелирования "точка- точка" (РРТР — Point-to-Point Tunneling Protocol) или транспортный протокол уровня 2 (L2TP — Layer 2 Transport Protocol). После установки диспетчера подключений на клиентских компьютерах будет автоматически инсталлировано требуемое программное обеспечение, поддерживаемое операционными системами. Исключение из этого правила наблюдается в Windows NT 4.0, где пользователю приходится вручную устанавливать протокол РРТР. Следует отметить, что в Windows 95 и в первых версиях Windows 98 требовалось инсталлировать обновление DUN 1.3 до установки диспетчера подключений. Необходимость в этом возникала в том случае, если использовался протокол аутентификации по методу "вызов/квитирование установки связи" фирмы Microsoft (MS-CHAP - Microsoft Challenge-Handshake Authentication Protocol) версии 2 (настоятельно рекомендуется воспользоваться именно этим протоколом). Как и в случае с другими формами установки диспетчера подключений, можно воспользоваться процедурой, которая будет проверять клиентское программное обеспечение VPN, а также выполнять его обновление (в случае необходимости).
Пакет инсталляции диспетчера подключений также включен в состав пакета инсталляции Internet Explorer 5 (или более поздней версии). Благодаря этому, пользователи могут устанавливать приложения Internet Explorer и диспетчера подключений в ходе выполнения одной простой процедуры.
Реализация
Наиболее важной частью. реализуемой в ходе процесса определения параметров диспетчера подключений, является следование соответствую щему руководству, которое Microsoft позиционирует в качестве составной части мастера. Фирма Microsoft рекомендует воспользоваться следующим руководством в качестве метода подготовки к созданию профилей для диспетчера подключений.
Первая фаза: планирование.
Вторая фаза: разработка пользовательских элементов.
Третья фаза: выполнение мастера СМАК и создание служебного профиля.
Четвертая фаза: подготовка к интеграции, доставке и инсталляции.
Пятая фаза: проверка доставляемых объектов.
Шестая фаза: поддержка пользователей.
Каждая из этих фаз подробно описывается фирмой Microsoft в соответствующих справочных документах СМАК. Также существует множество мастеров и шаблонов, которые будут полезными туннельному администратору при построении практически любой сети.
Политики удаленного доступа
С появлением Windows 2000 понятие "гибкость операционной системы" обрело новый смысл. В частности, администратор получил возможность конфигурирования параметров удаленных и туннельных клиентов с целью определения политик для точек сетевого доступа. В операционной системе Windows 2000 эти политики могут определяться либо на туннельном сервере, либо на сервере IAS. Конкретное действие зависит от выбранного типа аутентификации туннельного сервера (аутентификация Windows или RADIUS).
В Windows NT 4.0 вводятся ограничения на параметры, которые могут устанавливаться для удаленных пользователей с помощью диспетчера пользователей. Как правило, администратор может лишь контролировать, могут или не могут пользователи иметь права удаленного доступа, а также устанавливать различные параметры обратного дозвона. В Windows 2000 появились некоторые новые свойства, которые обеспечивают более высокий уровень управляемости для удаленных пользователей.
В Windows 2000 свойства удаленного подключения основываются на пользовательских учетных записях и политиках удаленного доступа. В роли политик удаленного доступа выступают условия и настройки, которые обеспечивают для сетевого администратора должный уровень гибкости при авторизации попыток подключения. Администраторы нуждаются в обеспечении контроля над доступом к корпоративной сети с помощью соединений удаленного доступа или туннельных подключений, проложенных через Internet.
Туннельный администратор может конфигурировать несколько политик удаленного доступа, определяющих различные настройки. Подключение будет авторизовано только в том случае, если настройки подключения соответствуют, как минимум, одной из политик удаленного доступа. Эти подключения являются субъектом условий, налагаемых на свойства удаленного доступа для пользовательской учетной записи и свойства политик удаленного доступа. Если настройки, использованные при осуществлении попытки подключения, не соответствуют, как минимум, одной из политик удаленного доступа, пользователь не может подключиться, несмотря на имеющиеся свойства пользовательской учетной записи.
До тех пор, пока настройки системы безопасности не требуют перехода к серверу IAS, политики удаленного доступа администрируются с помощью подключаемого модуля RRAS. Если же осуществляется переход к серверу IAS. политики удаленного доступа администрируются с помощью службы аутентификации Internet.
Свойства удаленного подключения для пользовательской учетной записи
Пользовательские учетные записи для автономного сервера или сервера, основанного на использовании Active Directory и выполняющегося в собственном режиме, содержат набор свойств удаленного доступа, которые используются для определения того, были ли разрешены попытки удаленного доступа, предпринимаемые пользователем. Доступ к этой странице свойств можно получить с помощью подключаемого модуля Local Users and Сгоир5(Локальные пользователи и группы) на автономном сервере либо с помощью подключаемого модуля Active Directory Users and Computers (Пользователи и компьютеры Active Directory) (рис. 9.1).
Рис. 9.1. Страница свойств пользователя
Атрибуты пользовательской учетной записи, используемые при осуществлении удаленного доступа, описаны ниже.
• Remote Access Permission (Dial-In or VPN) (Разрешение на удаленный доступ (VPN или модем)). Вообще говоря, эта настройка эквивалентна соответствующей настройке Windows NT 4.0. Она используется для указания того, был ли удаленный доступ разрешен явно, запрещен либо же определен с помощью политик удаленного доступа. Даже если доступ был явно разрешен в настройках пользовательских свойств, условия политики удаленного доступа по-прежнему могут блокировать установку подключения.
По умолчанию, учетные записи, созданные на автономном сервере удаленного доступа или в домене, который выполняется в собственном режиме Windows 2000, установлены с применением опции Control Access Through Remote Access Policy (Управление на основе политики удаленного доступа). Для новых учетных записей, созданных с использованием домена смешанного режима Windows 2000, назначается опция Deny Access (Запретить доступ).
» Verify Caller-ID (Проверять идентификатор) При выборе этой настройки сервер проверяет телефонный номер входящего вызова. Если этот номер не соответствует заданному телефонному номеру, попытка подключения будет заблокирована.
Как правило, клиент, телефонная система, находящаяся между вызывающим пользователем и сервером удаленного доступа, а также сервер удаленного доступа должны поддерживать свойство идентификации входного звонка. Компоненты, выполняющие процесс идентификации на сервере удаленного доступа, включают автоответчик, поддерживающий передачу информации о номере звонящего абонента, а также соответствующий драйвер Windows 2000. В задачу этого драйвера входит передача информации определителя номера службе RRAS.
Если в свойствах пользователя была сконфигурирована идентификация номера для входного звонка, и ни один компонент не поддерживает передачу информации определителя номера, попытка подключения будет заблокирована.
Callback Options (Ответный вызовсервера). Если выбрана эта ОПЦИЯ, сервер выполняет обратный вызов клиента во время установки подключения. При этом используется один из телефонных номеров, определенных клиентом, либо специфический телефонный номер, установленный сетевым администратором. В собственном режиме Windows 2000 поддерживается до 128 символов; во всех других режимах это количество ограничивается 48 символами.
Assign a Static IP Address (Статический IP-адрес пользователя). Если выбрано это свойство, специфические IP-адреса назначаются пользователю, реализовавшему подключение.
Apply Static Routes (Использовать статическую маршрутизацию). С помощью этой опции администратор может определять набор статических IP-маршрутов, добавленных в клиентскую таблицу маршрутизации после того, как подключение было установлено. (Эта настройка обсуждается более подробно в разделе 10.)
Политика удаленного доступа в Windows 2000
В Windows 2000 используются свойства пользовательских учетных записей и политики удаленного доступа для активизации подключений или назначения свойств подключениям. В политике удаленного доступа определяются условия и параметры, описывающие характеристики подключений. Можно также определить параметры подключения, такие как время простоя до момента отключения, требуемый метод аутентификации, а также многие другие параметры. Также возможно создать политики, которые будут оцениваться, и комбинированные настройки, воздействующие на оценки запросов входящих подключений.
В модели аутентификации Windows, заданной по умолчанию, для туннельного сервера назначается и поддерживается политика удаленного доступа (в среде RRAS). Если используется модель аутентификации RADIUS (IAS), для сервера IAS поддерживается политика удаленного доступа. Благодаря этому, несколько туннельных серверов могут использовать одну и ту же политику удаленного доступа. Помимо этого, если сервер IAS обслуживает подключения удаленного доступа, как в случае с подключениями VPN, администратор может конфигурировать множество настроек для обеих сред для одного и того же решения аутентификации.
Служба RRAS использует политики удаленного доступа в три этапа. Сначала конфигурируется политика с использованием условий, затем оцениваются права доступа входящего запроса на подключение, а напоследок применяется профиль подключения.
Условия
Условия включают один или больше атрибутов, которые сравниваются с настройками, используемыми при попытке подключения. Настройки должны соответствовать условиям, в результате чего попытки подключения будут успешными.
Для просмотра атрибутов политики удаленного доступа потребуется открыть подключаемый модуль RRAS или IAS, в зависимости от используемого типа аутентификации сервера.
Для использования аутентификации Windows перейдите к меню кнопки <Start> (Пуск) и выберите команду Programs ^Administrative Tools |=> Routing and Remote Access (Свойства с? Администрирование ^ Маршрутизация и удаленный доступ). Дважды щелкните на значке Remote Access Policy (Политика удаленного доступа), затем дважды щелкните на стандартной записи в правой панели, затем установите флажок Allow Access if Dial-In Permission Is Enabled (Разрешить доступ, если включены права удаленного доступа). Для просмотра опций щелкните на кнопке <Add> (Добавить).
При выборе аутентификации RADIUS перейдите к серверу IAS и выберите команду Start => Programs => Administrative Tools => Internet Authentication Service (Пуск ^^ Программы СО Администрирование С? Служба аутентификации Internet). Дважды щелкните на значке Remote Access Policy (Политика удаленного доступа), затем дважды щелкните на стандартной записи в правой панели, затем установите флажок Allow Access if DialIn Permission Is Enabled (Разрешить доступ, если включены права удаленного доступа), Для просмотра опций щелкните на кнопке <Add> (Добавить) (рис. 9.2).
Рис. 9,2. Атрибуты политики удаленного доступа
В следующем списке описаны атрибуты политики удаленного доступа.
Called-Station-ID (Идентификатор вызываемой станции). Телефонный номер, применяемый пользователем для подключения к серверу удаленного доступа. Для получения сведений относительно идентификатора вызываемой станции во время осуществления вызова телефонная линия, аппаратное обеспечение, а также аппаратный драйвер Windows 2000 должны поддерживать передачу идентификатора вызываемой станции. В противном случае идентификатор вызываемой станции придется назначать вручную для каждого порта. Этот атрибут представляет собой строку символов.
Calling-Station-ID (Идентификатор вызывающей станции) Телефонный номер, с которого поступил вызов. Этот атрибут представляет собой строку символов.
Client- Friendly- Name (Дружественное клиентское имя). Дружественное имя клиентского компьютера RADIUS, запрашивающего аутентификацию. Этот атрибут предназначен для сервера IAS и представляет собой строку символов.
Ciient-IP-Address (Клиентский IP-адрес). IP-адрес клиентского компьютера RADIUS, запрашивающего аутентификацию. Этот атрибут предназначен для сервера 1AS и представляет собой строку символов.
Client-Vendor (Поставщик клиента). Поставщик прокси-сервера RADIUS или сервера удаленного доступа, запрашивающего выполнение аутентификации. Этот атрибут может применяться для конфигурирования отдельных политик для различных серверов удаленного доступа, которые являются клиентами RADIUS по отношению к серверу IAS. Сервер удаленного доступа на сервере IAS должен конфигурироваться в качестве клиента RADIUS. Этот атрибут предназначается для сервера IAS.
; Day-And-Time-Restrictions (Ограничения по дням и часам). Этот атрибут позволяет администратору указывать период времени, в течение которого разрешается удаленный доступ. Заданные день и время связаны с днем и временем сервера, выполняющего авторизацию, но не зависят от часового пояса, находясь в котором клиент предпринимает попытки получения доступа.
Framed-Protocol (протокол, выполняющий разбиение на фреймы). Тип разбиения на фреймы для ИСХОДЯЩИХ пакетов. В качестве примеров можно рассматривать фреймы РРР, SLIP, Frame Relay и Х.25. Этот атрибут предназначается для сервера IAS.
NAS-Identifier (Идентификатор NAS). Имя сервера сетевого доступа (NAS). Этот атрибут предназначен для серверов IAS и представляет собой строку символов.
NAS-IP-Address (IP-адрес NAS). IP-адрес сервера NAS. Этот атрибут предназначен для серверов IAS и представляет собой строку символов.
NAS-Port-Type (Тип порта IAS). Тип среды, используемой вызывающим устройством. В качестве примеров можно рассматривать аналоговые телефонные линии (асинхронные), ISDN, а также туннели либо сети VPN.
Service-Type (Тип службы). Тип запрашиваемой службы. В качестве примеров можно рассматривать службы, управляющие последовательностью фреймов (такие как подключения РРР) и службы регистрации (такие как подключения Telnet). Этот атрибут предназначен для серверов IAS.
Tunnel-Type (Тип туннеля). Тип туннеля, созданного запрашивающим клиентом Ц PPTP или L2TP. Это условие можно использовать для указания настроек профиля, таких как методы аутентификации и сложность метода шифрования, использованного для туннеля.
Windows-Groups (Группы Windows). Имена групп Windows 2000, к которым принадлежит пользователь. В данном случае не существует атрибута условия для указанного имени пользователя или подразделения организации.
Права доступа
После того, как были оценены условия политики удаленного доступа, политика обеспечивает либо запрещает регистрацию для пользователя. Благодаря этому, туннельный администратор может создавать политику, которая определяет условия, предотвращающие регистрацию. Помните о том, что подобная техника неприменима к пользовательским учетным записям; она лишь будет применимой ко всем запросам на входяшие подключения.
Для просмотра перечня условий политики удаленного доступа потребуется открыть окно подключаемого модуля RRAS или IAS (выбор открываемого модуля зависит от типа аутентификации, сконфигурированного для используемого сервера).
В случае с аутентификацией Windows перейдите к меню кнопки Start (Пуск) и выберите меню Programs ф Administrative Tools ф Routing and Remote Access (Программы => Администрирование Ф Маршрутизация и удаленный доступ). Дважды щелкните на пункте Remote Access Policy (Политика удаленного доступа).
В случае с использованием аутентификации RADIUS перейдите к серверу IAS и выберите пункты меню Start Ф Programs ф Administrative Tools => Internet Authentication Service (Пуск ф Программы ф Администрирование Ф Служба аутентификации Innernet). Дважды щелкните на пункте Remote Access Policy (Политика удаленного доступа), после чего на экране отобразится страница свойств, показанная на рис. 9.3. По умолчанию выбрана опция Deny Remote Access Permission (Запретить права удаленного доступа).
Профиль
После того, как подключение былок нему будут применяться свой
ства профиля удаленного доступа (рис. 9.4). Благодаря использованию профиля, навливается среда для подключения, а также определяется количество параметров.
Ниже перечислены параметры профиля.
Dial-in constraints (Ограничения позвонкам).
IP.
(Многоканальное подключение).
Authentication (Проверка подлинности).
Encryption (Шифрование).
Advanced (Дополнительно).
Рис. 9.З. Настройки условийудаленРис. 9.З. Настройки условийудален11 hl r*.tl «fl Prnlilr11 hl r*.tl «fl PrnlilrПВПВOW-hComband |№| Mi#Mt
Рис. 9.З. Настройки условийудален
Рис. 9.З. Настройки условийудален
11 hl r*.tl «fl Prnlilr
11 hl r*.tl «fl Prnlilr
ПВ
ПВ
Mhertioel» i EnoypMn ] Mvsne*d
Checkare allowed
Г j£>^tblaAijthe^
Select
I '3 c<r<T" I I
P Mrroiolt Encrypted AxxhenbMtm ww\^ (MS CHAP v?]
Г MiuotchEncryoledAi/tie-<ic6fjcn |Ni><HAPl
P Egciypted Authentication (CHAP)
Г UnenyyptedAufterticahon (PAP. SPAPl
-
|— Atow temcle ff” ctenti Ю connect without negcliat ng
' ^y authentication method
OK | Leo- |&<*
- Рис. 9.4. Настройкизвонков для профиля
доступа
Вкладка Dial-In Constraints
Щелкните на вкладке Dial-In Constraints (Ограничения по входящим звонкам) для просмотра опций, показанных на рис. 9.5. Эти ограничения позволяют администратору определять параметры для входящих подключений.
Параметры, показанные на рис. 9.5, определены следующим образом.
If Idle(Разъединение при простое более). Эта настройка определя
ет период простоя, который допускает перед тем, как подключение будет разорвано. По умолчанию определяются сеансы, которые никогда не прерываются.
Restrict Maximum Session To (Максимальная продолжительностьЭта
стройка определяет максимальный период времени, в течение которого существует подключение. Сервер удаленного доступа прерывает подключение после того, как прошло время, определяющее максимальную продолжительность сеанса. Настройка, заданная по умолчанию, не предусматривает каких-либо ограничений.
Глава 9. Диспетчер подключений, политики удаленного доступа...
Restrict Access to the Following Days and Times (Разрешить входящие подключения только в эти дни и время). Определяет период времени, в течение которого разрешается установка подключения. Если была предпринята попытка подключения в период времени, который не был определен в графике, эта попытка будет отклонена. По умолчанию график не устанавливается. Если график все же был определен, сервер не разрывает подключения, которые были уже установлены в период времени, когда не допускаются попытки подключения.
Restrict Dial-In to This Number Only (Разрешить вход только по номеру). Эта опция позволяет администратору определить телефонный номер, который должен использоваться клиентами с тем, чтобы разрешалась установка подключения. Если используется другой номер, попытка подключения будет отклонена. По умолчанию выбирается настройка No Restrictions (Без ограничений), в результате чего сервер удаленного доступа допускает удаленный доступ с помощью всех номеров дозвона.
Restrict Dial-In Media (Разрешить входящие звонки следующих типов). Эта настройка позволяет администратору специфические типы ВХОДЯЩИХ звонков, такие как модем, ISDN или туннель, которые клиент должен использовать для разрешенных подключений. Если клиент предпринимает попытки подключения, используя другие типы ВХОДЯЩИХ звонков, подобные попытки отклоняются. По умолчанию подобная опция не устанавливается, поэтому сервер допускает входящие звонки всех типов.
Рис. 9.5. Настройка ограничений по входящим звонкам в профиле, определяющем входящие подключения
Вкладка IF
Вкладка IP (рис. 9.6) позволяет администратору определять параметры свойств TCP/IP для входящих подключений.
Параметры принимают следующие значения.
IP Address Assignment Policy (Политика назначения IP-адресов). Администратор может позволять клиентам запрашивать специфический IP-адрес, используемый подключением. По умолчанию сервер автоматически распределяет IP-адрес. ис-
пользуемый статическим пулом адресов либо протоколом динамического конфигурирования хоста (DHCP — Dynamic Host Configuration Protocol), как определяется настройками сервера.
IP Packet Filters (Фильтры IP-пакетов). Администратор может конфигурировать фильтры пакетов, которые будут применяться во время установки подключения. Эти фильтры оказывают влияние на подключение после его установки. Причем в этом случае конфигурируются фильтры по направлению "к клиенту" и "от клиента". Подобная фильтрация применима ко всем подключениям, которые соответствуют политике удаленного доступа.
Рис. 9.6. Конфигурирование IP-информации в профиле, определяющем входящие подключения
Вкладка Multilink
Эта вкладка используется для поддержки многоканальных связей с клиентами удаленного доступа. Полезность подобной техники диктуется тем, что в этом случае допускается связывание подключений в случае одновременно устанавливаемых подключений, что позволяет устанавливать подключения с помощью отдельных каналов связи. Щелкните на вкладке Multilink (Многоканальное подключение) для получения доступа к настройкам многоканального подключения политики удаленного доступа.
По умолчанию используются настройки для сервера. Администратор может отключать многоканальное подключение и ограничивать клиентов единственным портом. Также существует возможность установки многоканального подключения с последующим ограничением максимального количества портов. Администратор может сконфигурировать политики протокола распределения пропускной способности (ВАР Bandwidth Allocation Protocol), в результате чего обеспечивается дополнительное динамическое связывание линий в случае необходимости. Для сервера удаленного доступа должны быть установлены опции Multilink и ВАР (на странице свойств Multilink профиля).
Вкладка Authentication
На вкладке Authentication (Проверка подлинности) администратор может определять тип аутентификации, обеспечивающий доступ к серверу удаленного доступа. Не следует использовать "слабые" методы аутентификации либо аутентификацию с использованием простых текстовых паролей в среде VPN. Можно применять несколько методов ау-
тентификации, которые оказываются полезными в случае, если корпорация применяет различные методы (например, может осуществляться переход от использования стандартного имени пользователя и пароля к регистрации, основанной на применении смарт-карт). Сервер удаленного доступа должен располагать соответствующими типами аутентификации, установленными для свойств аутентификации профиля.
Примечание
По умолчанию Windows 2000 поддерживает протоколы MS-CHAP версий 1 и 2. Туннельному администратору рекомендуется всегда отключать протокол MS-CHAP версии 1 во избежание выполнения пассивного мониторинга. В результате выполнения этого процесса может возникнуть потенциальная угроза безопасности системы, как описывается в главе 4.
Вкладка Encryption
Политика удаленного доступа позволяет администратору указывать тип шифрования, используемый клиентами при подключении. Опции, показанные на рис. 9.7, описываются в следующем перечне.
No Encryption (Без шифрования). При выборе этой опции обеспечивается подключение, не использующее шифрование. Если требуется шифрование, не устанавливайте опцию No Encryption.
Эта настройка не рекомендуется для использования в среде VPN. Поверьте мне на слово, что если туннельный сервер сконфигурирован с учетом использования опции No Encryption, он будет полностью открытым для нежелательных "гостей"; в результате этого использование туннеля является бессмысленным. Мне неизвестны никакие условия, за исключением периода тестирования, которые оправдывают использование этой опции.
Basic (Основное). Эта опция применяется совместно с удаленными подключениями, а также подключениями VPN, основанными на использовании протокола РРТР и протокола шифрования Microsoft "точка-точка" (МРРЕ — Microsoft Point-to-Point Encryption). При использовании последнего протокола применяется 40-битовый ключ. При использовании протокола L2TP для подключений VPN, основанных на IPSec, применяется 56-битовое шифрование DES.
Strong (Стойкое). Эта опция применяется для удаленных подключений, а также подключений VPN, основанных на использовании протокола РРТР. При этом применяется протокол МРРЕ наравне с 56-битовым ключом. При использовании протокола L2TP для подключений VPN, основанных на IPSec, применяется 56-битовое шифрование DES.
Strongest (Наиболее стойкое). Эта опция доступна лишь для версий Windows 2000, распространяемых в США. При обработке удаленных подключений, а также подключений VPN, основанных на использовании протокола РРТР, применяется МРРЕ наравне с 128-битовым ключом. При использовании протокола L2TP для подключений VPN, основанных на IPSec, применяется шифрование 3DES.
Вкладка Advanced
Администратор может устанавливать дополнительные свойства, позволяющие указывать атрибуты RADIUS, которые отсылаются клиенту RADIUS сервером IAS. Атрибуты RADIUS применяются только по отношению к аутентификации RADIUS и игнорируются сервером удаленного доступа. По умолчанию опции Framed-Protocol присваивается значение РРР, а типу службы Service-Type присваивается значение Framed (рис. 9.8).
Сервер удаленного доступа использует лишь атрибуты Account-Interim-Interval, Reply-Message и Service-Type. Однакомно
гие другие атрибуты, которые используются в качестве части стандартной ции RADIUS и характерны для настроек, специфичных для производителя.
IPIPRulheriiK.^oriEncwiion | AdvancedRulheriiK.^oriEncwiion | AdvancedNOTE These encryption xsJi#^ apply only to the Windows 2003 Routing and RefroteAccMt Service,NOTE These encryption xsJi#^ apply only to the Windows 2003 Routing and RefroteAccMt Service,Select the lewfel ofbyprofit*
IP
IP
RulheriiK.^oriEncwiion | Advanced
RulheriiK.^oriEncwiion | Advanced
NOTE These encryption xsJi#^ apply only to the Windows 2003 Routing and RefroteAccMt Service,
NOTE These encryption xsJi#^ apply only to the Windows 2003 Routing and RefroteAccMt Service,
•
I?
PSl'otg
ОГ ] Caned | йМ*
9.7. Конфигурирование настроек шифрования Рис. 9.8. Могут применяться атрибуты
Политики удаленного доступа и сервер Windows NT 4.0 Server
Лишь немногие корпорации могут отказаться от использования всех серверов удаленного доступа Windows NT 4.0. Конечно, лучше всего серверы удаленного доступа максимально быстро перевести на платформу Windows 2000, поскольку в этом случае обеспечивается эффективная работа в среде доменов Windows NT 4.0. Однако осуществление подобного перехода является не всегда возможным. В следующем перечне очерчены некоторые соображения, имеющие отношение к политике удаленного доступа, обосновывающие необходимость перехода в среду Windows 2000 вместо поддержки туннельных серверов Windows NT 4.0.
Серверудаленногодоступана базе WindowsNT4.0неможет использоватьна
стройки политики удаленного доступа Windows 2000.
Если сервер удаленного доступа Windows NT 4.0 использует собственный домен Windows 2000 с целью получения свойствподключений пользователь
ской учетной записи, опция Control Access Through Remote Access Policy доступом с помощью политики удаленного доступа) интерпретируется как Deny Access (Запретить доступ).
Если был изменен каталог Windows NT 4.0, пользовательские учетные записи будут сконфигурированы таким образом, что будут активизированы права доступа подключения. При этом им будет присвоено значение Allow Access
(Разрешить доступ). Пользовательские учетные записи обновляются до Windows 2000. При этом конфигурируются права доступа входящих подключений таким
образом, что отключаются права доступа входящих подключений, для которых присвоено значение Control Access through Remote Access Policy (Управлять доступом с помощью политики удаленного доступа).
Служба аутентификации Internet (IAS)
Во многих корпоративных средах оборудование, обеспечивающее удаленный доступ, включает несколько устройств. Причем эти устройства имеют различные типы и выпушены различными производителями. При работе со средами подобных типов администраторы нуждаются в стандартном способе, обеспечивающем управление доступа для клиентов. Подобный стандарт получил наименование RADIUS. Фирма Microsoft реал изовала стандарт RADIUS в службе аутентификации Internet (IAS). Протокол RADIUS представляет собой протокол среды клиент/сервер, при использовании которой клиенты RADIUS посылают запросы аутентификации и учета серверу RADIUS. Сервер RADIUS проверяет полномочия аутентификации удаленного доступа для учетных записей, а также журналы, регистрирующие события.
Реализация в Windows NT
Многие туннельные администраторы, карьера которых начиналась в качестве администраторов больших сетей, при работе с Windows NT 4.0 склоняются в пользу решения RADIUS. При выборе другого решения появляются трудности, связанные с генерированием запросов туннельного сервера для конкретных доменных контроллеров при осуществлении запросов регистрации. В Windows NT 4.0 отсылаются запросы на аутентификацию любому доменному контроллеру, ответившему первым, независимо от его местоположения во внутренней сети. Контроль этого процесса возможен с помощью нескольких методов, однако простейшим из них является направление запроса серверу RADIUS, который может выступать в роли доменного контроллера либо иметь управляемую взаимосвязь с конкретным доменным контроллером.
Реализация в Windows 2000
В Windows 2000 описанное выше поведение было изменено в пользу конфигура- НИИ, использующей узлы и службы, однако RADIUS обеспечивает механизированный путь сбора данных регистрации, которые недоступны при использовании обычной аутентификации Windows.
Реализация сервера RADIUS известна в качестве компонента IAS Microsoft Windows 2000 Server. При ее использовании выполняется централизованная аутентификация, авторизация, аудит и учет пользователей, которые были подключены к сети с помощью сетей VPN и свойств удаленного доступа.
Служба IAS реализует стандарт IETF протокола RADIUS, который позволяет использовать однородную или разнородную сеть при работе с оборудованием удаленного доступа или сетей VPN. Поскольку при этом обеспечивается поддержка сред удаленного доступа и сетей VPN, довольно просто поддерживать соответствующий подход во всех случаях удаленной аутентификации.
Свойства IAS
Служба 1AS представляет собой фантастическую комбинацию технологий, обеспечивающих простое управление. При этом по-прежнему обеспечивается поддержка для стандартных протоколов и атрибутов, разработанных различными поставщиками, В приведенном ниже перечне кратко описаны основные свойства IAS.
Централизованная аутентификация пользователя. Служба IAS поддерживает множество протоколов аутентификации и позволяет администратору использовать практически любой тип метода аутентификации, удовлетворяющий требованиям аутентификации.
Поддержка всех распространенных методов аутентификации. Служба IAS поддерживает следующие протоколы аутентификации:
протокол аутентификации по паролю (РАР— Password Authentication Protocol);
протокол аутентификации по методу "вызов/квитирование установки связи" (CHAP — Challenge Handshake Authentication Protocol);
протокол аутентификации по методу "вызов/квитирование установки связи" фирмы Microsoft (MS-CHAP— Microsoft Challenge Handshake Authentication Protocol) версий 1 и 2;
расширяемый протокол аутентификации (ЕАР — Extensible Authentication Protocol), допускающий использование смарт-карт, сертификатов, временных паролей и маркерных карт;
служба идентификации за входным номером (DN1S — Dialed Number Identification Service), представляющая собой форму аутентификации, основанную на номере, вызываемом пользователем;
служба автоматической идентификации по номеру (ANI — Automatic Number Identification Service), представляющая собой форму аутентификации на основе номера вызывающего пользователя (идентификация по входному номеру);
гостевая аутентификацияили субдоговорное удаленное подключение (также называемое оптовое удаленное подключение). В данном случае речь идет о контракте, заключенном между корпорацией и провайдером услуг Internet, в рамках выполнения условий которого провайдер услуг Internet позволяет служащим компании подключаться к сети провайдера услуг перед тем, как будет установлен туннель VPN по направлению к частной сети компании.
Централизованная авторизация пользователя. Для обеспечения подключающимся пользователям соответствующих прав доступа к сети служба IAS аутентифицирует пользователей в доменах М icrosoft Windows NT 4.0 и Windows 2000 Active Directory. В результате этого доменные контроллеры Windows будут отвечать за управление репликацией, а сервер IAS выполняет простой запрос каталога.
Централизованный аудит и учет применимости. Поддержка стандарта RADIUS позволяет службе IAS собирать записи об использовании, отправленные службой NAS в какой-то единственный момент времени. Служба 1AS регистрирует информацию аудита и применимости в журнальных файлах. Служба IAS поддерживает формат журнального файла, который может непосредственно экспортироваться в базе данных, совместимых со стандартом Open Database Connectivity (ODBC).
Примечание
В инсталляции Windows 2000, определенной по умолчанию, генерируется текстовый файл, который может быть экспортирован в базу данных. Однако, используя набор IAS Software Development Kit, администратор может непосредственно экспортировать данные применимости/аудита в базу данных ODBC.
Удаленный мониторинг. Мониторинг службы IAS может осуществляться с помощью приложения Event Viewer, системного монитора или посредством простого протокола сетевого управления (SNMP — Simple Network Management Protocol).
Интеграция со службой RRAS
Служба IAS интегрирована в состав службой RRAS. Причем в этом случае разделяются политики удаленного доступа и возможности по выполнению учета. Благодаря этому администратор может разворачивать службу RAS на небольших узлах. При этом не требуется устанавливать отдельный централизованный сервер IAS. В этом случае также становится возможным выполнять масштабирование вплоть до построения централизованной модели управления удаленным доступом в случае, если в вашей организации установлено несколько серверов RRAS.
В результате этого служба 1AS может функционировать совместно с RRAS с целью реализации единой точки администрирования удаленного доступа к сети, реализуемого на основе субдоговорного удаленного подключения, удаленного подключения по требованию и доступа с помощью сети VPN. Помимо этого, политики IAS на большом центральном узле могут быть экспортированы на независимый сервер RRAS, находящийся на малом узле.
Причины использования RADIUS
Как правило, если текущий сетевой проект включает инфраструктуру RADIUS, желательно, чтобы туннельные серверы также были включены в это пространство. Но как быть в том случае, если в вашей среде не установлены службы RADIUS? В среде операционной системы Windows NT 4 во многих крупных сетях проявлялись проблемы управления в процессе ответа доменных контроллеров на запросы регистрации. Фактически это привело к тому, что некоторые организации стали рассматривать возможность применения решений RADIUS по отношению к туннельной среде.
В Windows 2000 были решены многие проблемы, характерные для процесса аутентификации на основе Windows NT 4. В этой новой операционной системе был осуществлен переход к использованию конфигурации на основе узлов и служб Active Directory. Теперь туннельный сервер органически вписывается в определение подсети Active Directory, в результате чего стал возможным логический подход к принятию решения относительно того, какой доменный контроллер будет опрашиваться запросом на аутентификацию. Если сервер не может определить, какой доменный контроллер сгенерировал запрос (с помощью определений подсети), он будет принимать решение на основе эхо-тестирования LDAP.
Смет
Я по-прежнему остаюсь поборником идеи среды аутентификации, основанной на использовании RADIUS. Экспериментальным путем было доказано, что в этом случае ускоряется процесс регистрации, а также все серверы сетевого доступа принимают участие в одном и том же процессе аутентификации. Помимо этого, если используется RADIUS, туннельный сервер не будет иметь ни малейшего отношения к каталогу или домену. Он будет просто выступать в роли автономного сервера, поскольку содержит всю информацию, требуемую в конфигурации RRAS для запроса аутентификации из сервера RADIUS.
Инсталляция и конфигурирование службы IAS
Шаги, описанные в процедуре 9.1, позволят вам выполнить инсталляцию сервера IAS. Используемая при этом система, как правило, представляет собой автономный сервер, входящий в состав домена Windows 2000. Учитывайте ограничения, накладываемые на структуру, в состав которой входят смешанные серверы Windows NT 4.0. Можно сконфигурировать сервер IAS Windows 2000 в домене Windows NT 4, но при этом обеспечиваются ограниченные функциональные свойства. Описанная ниже процедура предназначена для домена Windows 2000.
Процедура 9.1. Инсталляция и конфигурирование службы IAS
Для инсталляции службы JAS перейдите в Control Panel (Панель управления) и выберите опции Add/Remove Programs => Add/Remove Windows Components «❖ Networking Services => internetAuthentication Service (Установка и удаление программ =>Добавление и удаление КОМПОнентов Windows Ф Сетевые службы Ф Служба проверки подлинности в Интернете). Если ПОтребуется, вставьте установочный диск CD-ROM Windows 2000 Server/Advanced Server CD.
После завершения установки службы IAS выберите команду Start о Program Files сф Administrative Tools Ф Internet Authentication Service (Пуск |ф Программы ^ Администрирование Ф Служба проверки подлинности в Интернете). После этого отобразится экран, показанный на рис. 9.9.
Находясь в левой панели, щелкните на пункте Clients (Клиенты).
Щелкните правой кнопкой мыши и в контекстном меню выберите пункт New Client (Новый клиент).
Введите дружественное имя, используя которое сервер удаленного доступа будет принимать запросы клиентов на подключение (рис. 9.10). Оставьте значение RADIUS для поля Protocol (Протокол). Затем щелкните на кнопке <Next> (Далее).
Введите имя или IP-адрес клиента удаленного доступа. Обратите внимание, что возможно определять различные типы поставщиков для клиента.
Примечание
По мере возможности используйте стандарт RADIUS. Однако если ваш клиент RADIUS представляет другого поставщика, может потребоваться обеспечение большего количества функциональных свойств. В этом случае может оказаться полезныл» выбор конкретного варианта стандарта RADIUS для данного клиента.
Рис. 9.9. Инсталляция, заданная по умолчанию, для службы аутентификации internet
Также возможно установить так называемый "общий секрет", который позволяет обеспечить безопасность для связи, установленной между сервером удаленного доступа и сервером IAS (рис. 9.11). Затем щелкните на кнопке <Finish> (Готово).
Рис. P. 10. Ввод имени и протокола для клиента
Рис . 9.1 7. Ввод информации о клиенте RADIUS
Примечание
В большинстве современных реализации протокола RADIUS используется общий секрет, представляющий собой обычный пароль (будем надеяться, весьма сложный для разгадывания). Этот пароль сервер и клиент могут использовать для того, чтобы убедиться в использовании корректного сервера при передаче или приеме информации. В ближайшем будущем станут более распространенными серверы, поддерживающие цифровые подписи. В этом случае будет обеспечиваться более "прозрачная" и защищенная взаимосвязь между серверами и клиентами RADIUS.
Помните о том, что, поскольку аутентификация основана на использовании службы IAS, все настройки политики удаленного доступа должны применяться по отношению к серверу IAS. Находясь на сервере удаленного доступа (выбранного на шаге 6), перейдите к меню кнопки Start (Пуск) и выберите команды меню Programs о Routing and Remote Access (Программы с> Маршрутизация и удаленный доступ).
Щелкните правой кнопкой мыши на сервере и в контекстном меню выберите пункт Properties (Свойства).
Выберите вкладку Security (Безопасность).
Выберите тип службы проверки подлинности RADIUS Authentication (RADIUS — проверка подлинности). В качестве службы учета выберите RADIUS Accounting (RADIUS - учет) (рис. 9.12).
Процедура 9.1. Инсталляция и конфигурирование службы IAS 221
OK | Caned | блоуOK | Caned | блоуРис. 9.12. Выбор службы RADIUS с помощью настроек безопасностиРис. 9.12. Выбор службы RADIUS с помощью настроек безопасностирис. 9.13. Добавление информации для сервера RADIUSрис. 9.13. Добавление информации для сервера RADIUS
OK | Caned | блоу
OK | Caned | блоу
Рис. 9.12. Выбор службы RADIUS с помощью настроек безопасности
Рис. 9.12. Выбор службы RADIUS с помощью настроек безопасности
рис. 9.13. Добавление информации для сервера RADIUS
рис. 9.13. Добавление информации для сервера RADIUS
Щелкните на кнопке <Configure> (Настроить), находящейся возле опций настроек
службы проверки подлинности, и щелкните на кнопке <Add> (Добавить).
В появившемся диалоговом окне (рис, 9.13) укажите имя сервера IAS. Если при выполнении шага 7 был определен секрет, щелкните на кнопке <Change> (Изменить) и введите определенный ранее секрет.
Примечание
Если в вашей среде установлено несколько серверов RADIUS, что является типичной ситуацией в большинстве сетей, конфигурация службы RRAS может включать такие настройки, как длительность ожидания для каждого сервера (настройка Time-out), начальную оценку для сервера (Initial Score) и номер порта сервера (Рон). Обратите внимание, что в прежних модификациях серверов RADIUS использовался порт 1645 для аутентификации и порт 1646 — для учета. Можно сконфигурировать сервер RADIUS для прослушивания обоих портов, но туннельные серверы должны располагать отдельными записями в случае, если требуются старый и новый порты.
Щелкнув на кнопке <Add> (Добавить), подтвердите, что сервер IAS отображается в списке, затем щелкните на кнопке <ОК>. В результате отображается сообщение, информирующее пользователя о том, что сервер RRAS должен быть перезапущен для того, чтобы изменения возымели эффект (рис. 9.14). Щелкните на кнопке <ОК>.
Puc. 9.14. Требуется перезапуск сервера RRAS.Puc. 9.14. Требуется перезапуск сервера RRAS.
Puc. 9.14. Требуется перезапуск сервера RRAS.
Puc. 9.14. Требуется перезапуск сервера RRAS.
Вернитесь обратно к вкладке Security (Безопасность) и щелкните на кнопке <Configure>, находящейся возле опций настройки учета RADIUS.
Повторите шаги 11-14 и установите сервер IAS.
17,Для перезапуска сервера RRAS, находясь в левой панели, шелкните правой кнопкой мыши на имени сервера, в контекстном меню выберите пункт All Tasks (Все задачи) и щелкните на кнопке <Restart> (Перезапуск).
Резюме
Многие из проблем, проявлявшихся при разворачивании сетей VPN в среде Windows NT 4.0, а также на других платформах, были связаны с недостаточной степенью гибкости, обеспечиваемой этими платформами. Если принимать во внимание наличие всеобъемлющей туннельной среды, Windows 2000 обеспечивает такой уровень гибкости, который до этого не предоставлялся ни одним программным продуктом, реализующим сети VPN. Диспетчер подключений обеспечивает автоматическое конфигурирование клиентов, а также реализует централ изованное управление. Политики удаленного доступа разрешают определение параметров для каждого из подключений на наивысшем уровне детализации. Протокол RADIUS позволяет применить подход, основанный на стандартах, по отношению к задачам аутентификации и учета.
223223Резюме
223
223
10
Маршрутизация и фильтрация
Организация туннелей средствами Windows 2000 представляет собой лишь первую часть процесса конфигурирования сети. После организации туннелей среда маршрутизации должна быть определена таким образом, чтобы подключенные к сети компьютеры могли эффективно использовать туннельные связи. Кроме того, для зашиты сетевой среды на туннельных серверах могут быть определены фильтры, которые не только усиливают защиту, но и повышают эффективность сетевого технического решения.
Сетевые решения, рассматриваемые в этой книге, опираются на использование TCP/IP, ибо в большинстве сред применяется исключительно этот набор протоколов, а большая часть реализаций сетей VPN так или иначе пересекается с Internet. С другой стороны, всякое рассмотрение TCP/IP неминуемо влечет за собой обсуждение вопроса IP- маршрутизации. В этой главе предполагается, что у читателя имеется определенное представление об IP-маршрутизации, и поэтому ее основы здесь не излагаются.
Реализация TCP/IP в Windows 2000 должна быть осуществлена до развертывания Active Directory или других технологий туннелирования.
Маршрутизация в Windows 2000
Благодаря применению сетей VPN, проявляются сложности, связанные с возникновением сотен связей, динамически изменяющихся в туннельной среде. Именно поэтому организация среды маршрутизации может оказаться намного более сложным делом, чем формирование типичной сетевой среды с выделенными линиями связи. Тем не менее, при правильном планировании у разработчика сетевой архитектуры появляется возможность спроектировать среду, поддерживающую динамические связи, обеспечивающую нужные маршруты и корректно функционирующую в большинстве случаев.
Наилучший подход к проблеме маршрутизации в среде VPN состоит в том, чтобы определить связи, набросав инфраструктуру сети, а затем представив их себе таким образом, как будто они не имеют отношения к VPN. После установки подключений клиент уже не видит никакой разницы между локальной службой и той, что подключается по каналу связи VPN. Вместо этого клиенту становится известно, что он удален от другого конца маршрутизатора на один транзитный участок. Тот факт, что туннель проходит по Internet, не должен вводить в заблуждение. Ведь приложениям недоступны маршрутизаторы, находящиеся между обоими концами туннеля, и поэтому им безразлично количество транзитных участков, находящихся на протяжении всего туннеля (если только это не сказывается на скорости передачи данных по выбранному маршруту).
Я принадлежу к числу убежденных сторонников выполнения туннельными серверами только тех задач, которые они обязаны выполнять — и не более того. Если приходится поддерживать работоспособность такой небольшой сети, как HappyVPN, то
для этого вполне подойдут статические маршрутизаторы. В такой сети существует
лишь незначительное число частных узлов, поэтому и среду маршрутизации поддерживать в данном случае несложно. В службу Windows 2000 RRAS вполне могут быть добавлены такие протоколы маршрутизации, как протокол маршрутной информации (Routing Information Protocol — RIP) или протокол маршрутизации с определением кратчайшего маршрута (Open Shortest Path First ~ OSPF), однако прежде, чем использовать эти протоколы, необходимо убедиться в их пригодности для данной среды.
Идеальное решение состоит в конфигурировании туннельных серверов для прослушивания существующих корпоративных маршрутизаторов, а также в настройке и поддержке выполняемых ими функций маршрутизации на основании информации, получаемой от маршрутизаторов. Первоначально туннельные серверы содержат пул статических маршрутов, которые отражают особенности корпоративной подсетевой среды. В сложной сети такая ситуация может быстро выйти из-под контроля, поскольку администратор туннеля вынужден поддерживать маршрутную информацию при выполнении той же самой функции администраторами маршрутизаторов.
В Windows 2000 предоставляются возможности не только маршрутизации, но и фильтрации протоколов. Такие задачи, как блокирование порта 139 TCP/IP по отношению к протоколу NetBIOS, благодаря чему этот порт оказывается защищенным со стороны Internet, приобретают важное значение при организации защиты любого сервера, подвергающегося атакам с целью нарушения системы защиты.
Фильтрация представляет собой важную часть процесса установки полноценного и защищенного VPN-сервера. Если для некоторых портов этого сервера реализована фильтрация информации, сервер просто игнорирует весь трафик, который определяется параметрами фильтра. Если же блокируется весь трафик, за исключением туннельного трафика, являющегося типичным для внешнего интерфейса туннельных серверов, сервер никак не реагирует на трафик любого другого типа.
Виды маршрутизации в Windows 2000
В Windows 2000 имеется ряд новых возможностей, имеющих отношение к маршрутизации. В последующих разделах подробно рассматриваются различные способы маршрутизации в Windows 2000.
Статическая маршрутизация
Статическая маршрутизация применялась в наборе протоколов TCP/IP с момента его возникновения. Эта технология хорошо знакома сетевым администраторам, однако в современных сетях она, как правило, не применяется вследствие потенциально больших административных накладных расходов на поддержание маршрутов. Тем не менее, статическая маршрутизация вполне пригодна для небольших сетей, где маршрутная информация изменяется нечасто. Статические маршруты используются лишь в особых случаях, хотя сетевую среду следует, по возможности, проектировать таким образом, чтобы избежать поддержки любого типа маршрутизации, которая может оказаться избыточной.
К преимуществам применения статической маршрутизации относятся следующие:
исключение сетевого трафика, формируемого при использовании протоколов динамической маршрутизации;
усиление степени зашиты, поскольку в данном случае таблицы маршрутизации не передаются;
обеспечение единственного маршрута между двумя неизменными конечными точками.
Недостатки статической маршрутизации:
увеличение административных накладных расходов в связи с необходимостью поддерживать маршрутную среду вручную;
потеря маршрута при выходе из строямаршрутизатора;
отсутствие возможности выравнивания нагрузки,
Протокол RIP (для IP-сетей)
Протокол RIP предназначен для передачи маршрутной информации в небольших и средних по размеру сетях, насчитывающих до 1500 клиентов. В Windows 2000 поддерживаются версии 1 и 2 протокола RIP, причем версия 2 отличается возможностью поддержки групповых сообщений, простой проверки пароля, масок подсети переменной длины, а также сред бесклассовой междоменной маршрутизации (CIDR — Classless Inter-Domain Routing).
К преимуществам применения протокола RIP относятся следующие:
автоматическоеобновление информации, содержащейся в таблице маршрутизации;
возможность для маршрутизаторов реагировать на постоянные изменения в маршрутной среде;
поддержка со стороны всех IP-маршрутизаторов;
поддержка интерфейсов обеспечения каналов связи по требованию;
наличие RI Р-ориентированной среды, благодаря которой клиенты имеют возможность пользоваться службой RIP Listener (Приемник протокола маршрутной информации).
Недостатки протокола RIP:
большие таблицы маршрутизации, которые могут обусловить задержки при совместном использовании маршрутной информации, а следовательно, привести к неработоспособности маршрутов;
периодически выдаваемые маршрутные сообщения, которые могут обусловить увеличение сетевого трафика;
ограниченная степень масштабируемости.
Автостатическая маршрутизация
При автостатической маршрутизации входные данные статической маршрутизации обновляются автоматически с помощью протокола RIP. Это своего рода гибрид статической маршрутизации и протокола RIP. В данном случае статические маршруты автоматически добавляются в таблицу маршрутизации после запроса маршрутов в соединении с использованием R1P по заданному графику.
Преимущества автостатической маршрутизации:
обладает всеми достоинствами стандартного протокола R1P;
типичный для RIP трафик ограничивается, благодаря плановому обновлению.
Недостаток автостатической маршрутизации состоит в следующем:
любые изменения, происходящие до планового обновления, не будут отражены в маршрутной среде.
Маршрутизация с определением кратчайшего маршрута
Протокол OSPF предназначен для обмена маршрутной информацией в больших и сверхбольших сетях. Для расчета маршрутов по таблице маршрутизации в протоколе OSPF применяется алгоритм определения кратчайшего маршрута (SPF- Shortest Path First). В соответствии с этим алгоритмом рассчитывается кратчайший маршрут между маршрутизатором и всеми сетями, с которыми он связан. В отличие от протокола R1P, в OSPF не происходит обмена элементами таблицы маршрутизации, а вместо
этого маршрутизаторы OSPF поддерживают карту сети, которая обновляется после каждого изменения топологии сети. Эта карта, называемая также базой данных состояния связи, синхронно поддерживается всеми маршрутизаторами OSPF и используется для расчета маршрутов по таблице маршрутизации.
Преимущества протокола OSPF:
незначительныесетевые накладные расходы;
применение OSPF во многих маршрутизаторах, а следовательно, и в организациях;
поддержка небольших таблицмаршрутизации в среде OSPF.
Недостатки протокола OSPF:
для среды OSPF может потребоваться весьма сложное конфигурирование;
для формирования сообщений о состоянии связи и расчета маршрутов по таблицам маршрутизации могут потребоваться значительные ресурсы.
Маршрутизация по протоколу IGMP
Протокол обмена сообщениями между группами в Internet (IGMP — Internet Group Messaging Protocol) представляет собой вариант групповой маршрутизации, который позволяет посылать одну копию маршрутной информации во многие пункты назначения. Элементы таблицы групповой пересылки сообщений TCP/IP вводятся посредством протокола IGMP. При внедрении этого протокола маршрути заци и в службе RRAS интерфейсы маршрутизации могут быть добавлены в конфигурацию IGMP в двух следующих режимах: маршрутизатора и прокси.
Реализация протокола IGMP в среде Windows 2000 не предполагает полную поддержку функций группового маршрутизатора, однако допускает групповую пересылку сообщений клиентам IGMP, непосредственно подключенным к одной и той же подсети, используемой в качестве маршрутизатора. В Windows 2000 могут использоваться существующие маршрутизаторы, которые действительно обладают возможностями групповой маршрутизации.
Преимущества протокола IGMP:
возможность получение группового трафика в малых сетях с помощью IGMP, не прибегая к услугам полноценного группового маршрутизатора;
возможность объединения IGMP с существующим групповым трафиком, включал групповую передачу по протоколу RIP версии 2.
Недостатки протокола IGMP:
реализация протокола IGMP в Windows 2000 не предполагает полную поддержку функций группового маршрутизатора.
не допускается поддержка одних подсетей внутри других.
Защищенные маршрутизируемые соединения
В распределенной сетевой среде весьма важной может оказаться задача обеспечения зашиты маршрутизируемых соединений. Независимо от выбранного способа маршрутизации конечная цель любого разработчика сети заключается в эффективной поддержке ее целостности. Многим сетевым инженерам приходится принимать меры по защите важной информации в подсетях внутренней сети предприятия. Если нарушитель способен получить доступ к информации на этом уровне, то обеспечение безопасности подобной сети может быть в значительной степени сомнительным. Для обеспечения защиты маршрутизатора в Windows 2000 используются два следующих основных метода:
определение IP-адресов тех маршрутизаторов, которые могут входить в маршрутную среду. Такая возможность существует, благодаря поддержке аутенти- фикании защищенных маршрутов с помощью стандартных паролей, поддерживаемых протоколами RIP и OSPF;
использование возможностей протоколаiPSec для блокировки маршрутизаторов, Если между маршрутизаторами установлены фильтры IPSec, весь трафик, проходящий между ними, может быть зашифрован. Установка протокола IPSec на пути между маршрутизатором Windows 2000 и внешним маршрутизатором (в частности, маршрутизатором Cisco) может иметь ряд последствий. Вместо протокола Kerberos или сертификата в данном случае, возможно, придется воспользоваться общим ключом. Более подробные сведения о связывании маршрутизаторов Windows и Cisco приведены в приложении В.
Безусловно, в Windows 2000 поддерживается несколько вариантов маршрутизации. Так, для автономных или небольших сетей достаточно наличия туннельных серверов, выбирающих маршруты с помощью статической маршрутизации или протокола RIP. А для сети крупной организации следует попытаться связать туннельную маршрутизацию с маршрутизаторами данной организации.
Маршрутизация со стороны клиента
Маршрутизация со стороны клиента является, без сомнения, самым непонятным и сложным вопросом, возникающим в связи с реализацией компанией Microsoft технологии туннелирования. Разочарование в этом случае возникает тогда, когда клиент подключен непосредственно к Internet. При установлении туннеля клиент заменяет в стандартный шлюз подключения Internet на подключение VPN. Это приводит к тому, что весь трафик, связанный с Internet и внутренней сетью организации, направляется по внутренней сети организации. Следует отметить, что в различных организациях возникающие при этом проблемы решаются совершенно по-разному.
В одних организациях применяются внутренние служебные правила, согласно которым изменение маршрутизации клиентов служит основанием для прекращения связи, а в других — маршрутизация клиентов используется в качестве стандартной конфигурации. Мне потребовалось некоторое время, чтобы уяснить проблемы маршрутизации со стороны клиента, проявляющиеся в результате столь разительных отличий стратегий различных компаний, Рассмотрим этот вопрос более подробно в последующих разделах.
Стандартный шлюз
В данном случае стандартный шлюз, или маршрут, пролегает через маршрутизатор, в качестве которого служит сервер трансляции сетевых адресов (NAT — Network Address Translation), подключенный к Internet. Как правило, сервер NAT получает IP-адрес в виде параметра протокола динамической конфигурации хоста (DHCP , I- —■ Dynamic Host Configuration Protocol) в момент соединения с провайдером услуг Internet (1SP). Однако, в связи с тем, что этот сервер поддерживает службы сервера NAT, внешние адреса недоступны клиентам туннеля, и поэтому они используют частные адреса.
Для проверки стандартного маршрута лучше всего просто перейти в режим командной строки и ввести команду route print.Образец стандартной таблицы маршрутизации, применяемой в рассматриваемом здесь примере системы, приведен на рис. 10.1.
На данном рисунке компьютер, находящийся за NAT-сервером, использует для своего стандартного шлюза адрес 10.0.2.1 NAT-сервера. Как показывает результат выполнения команды route print, первый элемент таблицы маршрутизации, 0.0.0.0,
указывает на необходимость следования по стандартному маршруту, если при этом не выполняется поиск адреса в подсети 10.0.2.0.
Теперь необходимо подключиться к туннельным серверам, установить новый сетевой объект, шелкнув правой кнопкой мыши на списке My Network Places (Мое сетевое окружение) и выбрать пункт Properties (Свойства). Затем следует воспользоваться мастером создания нового канала связи VPN. После того как будет установлено соединение, отображается среда маршрутизации, как показано на рис. 10.2.
Рис. 10.1. Стандартный шлюз без туннеля
Рис. 10.2. Результат подключения, реализо ванного с применением стандартного шлюза
Как видно из данного рисунка, в таблице маршрутизации теперь находятся два элемента 0.0.0.0, причем исходный элемент был изменен и имеет метрику 2, а новый — метрику 1. При соединении с туннельным сервером последний предоставляет IP-адрес 20.47.41.9, указывая на то, что если искомый IP-адрес не находится в диапазоне адресов 10.0.2.0, клиент передаст этот адрес стандартному шлюзу. Единственным исключением из этого правила является IP-адрес 200.114.71.17, который соответствует внешнему интерфейсу для туннельного сервера, с которым было установлено соединение. Вообще говоря, туннелю известно, каким образом взаимодействовать с указанным выше туннельным сервером.
Применение стандартного шлюза в туннельной маршрутизации является используемым по умолчанию режимом выполнения сетевых продуктов компании Microsoft. В итоге, при такого рода маршрутизации клиентам туннеля приходится вводить информацию прокси-сервера, а также другую информацию корпоративного характера, обеспечивающую доступ к ресурсам Internet, хотя в данном случае имеется непосредственное подключение к
Internet. Как правило, при этом снижается производительность, а трафик, проходящий через туннельные серверы и корпоративную сеть, существенно возрастает.
С другой стороны, можно предоставить клиентам сведения о различных подсетях внутри корпоративной сети, а стандартному шлюзу — возможность устанавливать, как и раньше, подключение к Internet. Для этого перейдите в область Properties (Свойства) модуля VPN Client (Клиент виртуальной частной сети) и выберите ОПЦИЮ Networking Configuration ^ TCP/IP Advanced Settings (Конфигурирование сети => Дополнительные параметры TCP/IP). Отмените установку флажка Use Default Gateway on Remote Network (Использовать стандартный шлюз в удаленной сети). После того как соединение будет установлено повторно, генерируется таблица маршрутизации, приведенная на рис. 10.3.
!■ : Command Prompt!■ : Command Promptfictivc Route Nctwrk DestinationИ.Й.И.010.0.2.010.9.2-5]10.255.255.25520.0.0.020-47,41 .120 .47,41.1320.255.255.255127,0.0.0200.114.71,1?221.И.М,И224.0<«.й255.255- 255 Л55Default Gateway^gfictivc Route Nctwrk DestinationИ.Й.И.010.0.2.010.9.2-5]10.255.255.25520.0.0.020-47,41 .120 .47,41.1320.255.255.255127,0.0.0200.114.71,1?221.И.М,И224.0<«.й255.255- 255 Л55Default Gateway^gHRDHRD0x40090040x400900400 53 45 00 00 0000 53 45 00 00 00WIN <PMVSLII>> InterimWIN <PMVSLII>> InterimPersistent Routes NonePersistent Routes NoneИх2 ,, .Ий 0Й ffi .iff aS 33fnr.al Гн:2Н<П РСГ Fast ЕЫкйчип ЙИаеСе .......... » • ,» . .’.W- ^1e ■—— лл л■ ■ . —. • „ IIWe ■ ■ I.. I, — , ■, .,■...Их2 ,, .Ий 0Й ffi .iff aS 33fnr.al Гн:2Н<П РСГ Fast ЕЫкйчип ЙИаеСе .......... » • ,» . .’.W- ^1e ■—— лл л■ ■ . —. • „ IIWe ■ ■ I.. I, — , ■, .,■...255.255.255.255255 255 255 255255.0.0 .И255.255.255,255 224,0,0.9 224-9.0.0255.255.255.25510.0.2,1255.255.255.255255 255 255 255255.0.0 .И255.255.255,255 224,0,0.9 224-9.0.0255.255.255.25510.0.2,1iNotnaakИ.И.И.И26$ J.^Zt^.H 255.255.255 -255 255-2S5.2SS.aS5iNotnaakИ.И.И.И26$ J.^Zt^.H 255.255.255 -255 255-2S5.2SS.aS5Gateway 1И.0,2Л 1И.И.2.ЫGateway 1И.0,2Л 1И.И.2.Ы10.0.2.51 20,47.41,13 20.47.41.13127.9,0.120.47.41.13127.И.0Л1И.6.2 Л10.0,2.5120-47.41 ЛЗ10.9.2Л110.0.2.51 20,47.41,13 20.47.41.13127.9,0.120.47.41.13127.И.0Л1И.6.2 Л10.0,2.5120-47.41 ЛЗ10.9.2Л1lot efface 10,0.2.51 1И.И.2.51 127.0.0.1 10.0.2,51 20.47.41.13 29.47.41.13127.0.0.1 20.47.41.13127-И.0.1 10,0.2-51 1И.И.И.М 20.47-41.131И.Й-2.51lot efface 10,0.2.51 1И.И.2.51 127.0.0.1 10.0.2,51 20.47.41.13 29.47.41.13127.0.0.1 20.47.41.13127-И.0.1 10,0.2-51 1И.И.И.М 20.47-41.131И.Й-2.51
!■ : Command Prompt
!■ : Command Prompt
fictivc Route Nctwrk Destination
И.Й.И.0
10.0.2.0
10.9.2-5]
10.255.255.255
20.0.0.0
20-47,41 .1
20 .47,41.13
20.255.255.255
127,0.0.0
200.114.71,1?
221.И.М,И
224.0<«.й
255.255- 255 Л55
Default Gateway^g
fictivc Route Nctwrk Destination
И.Й.И.0
10.0.2.0
10.9.2-5]
10.255.255.255
20.0.0.0
20-47,41 .1
20 .47,41.13
20.255.255.255
127,0.0.0
200.114.71,1?
221.И.М,И
224.0<«.й
255.255- 255 Л55
Default Gateway^g
HRD
HRD
0x4009004
0x4009004
00 53 45 00 00 00
00 53 45 00 00 00
WIN <PMVSLII>> Interim
WIN <PMVSLII>> Interim
Persistent Routes None
Persistent Routes None
Их2 ,, .Ий 0Й ffi .iff aS 33fnr.al Гн:2Н<П РСГ Fast ЕЫкйчип ЙИаеСе .......... » • ,» . .’.W- ^1e ■—— лл л■ ■ . —. • „ IIWe ■ ■ I.. I, — , ■, .,■...
Их2 ,, .Ий 0Й ffi .iff aS 33fnr.al Гн:2Н<П РСГ Fast ЕЫкйчип ЙИаеСе .......... » • ,» . .’.W- ^1e ■—— лл л■ ■ . —. • „ IIWe ■ ■ I.. I, — , ■, .,■...
255.255.255.255
255 255 255 255
255.0.0 .И
255.255.255,255 224,0,0.9 224-9.0.0
255.255.255.255
10.0.2,1
255.255.255.255
255 255 255 255
255.0.0 .И
255.255.255,255 224,0,0.9 224-9.0.0
255.255.255.255
10.0.2,1
iNotnaak
И.И.И.И
26$ J.^Zt^.H 255.255.255 -255 255-2S5.2SS.aS5
iNotnaak
И.И.И.И
26$ J.^Zt^.H 255.255.255 -255 255-2S5.2SS.aS5
Gateway 1И.0,2Л 1И.И.2.Ы
Gateway 1И.0,2Л 1И.И.2.Ы
10.0.2.51 20,47.41,13 20.47.41.13
127.9,0.1
20.47.41.13
127.И.0Л
1И.6.2 Л
10.0,2.51
20-47.41 ЛЗ
10.9.2Л1
10.0.2.51 20,47.41,13 20.47.41.13
127.9,0.1
20.47.41.13
127.И.0Л
1И.6.2 Л
10.0,2.51
20-47.41 ЛЗ
10.9.2Л1
lot efface 10,0.2.51 1И.И.2.51 127.0.0.1 10.0.2,51 20.47.41.13 29.47.41.13
127.0.0.1 20.47.41.13
127-И.0.1 10,0.2-51 1И.И.И.М 20.47-41.13
1И.Й-2.51
lot efface 10,0.2.51 1И.И.2.51 127.0.0.1 10.0.2,51 20.47.41.13 29.47.41.13
127.0.0.1 20.47.41.13
127-И.0.1 10,0.2-51 1И.И.И.М 20.47-41.13
1И.Й-2.51
Pue. 10.3. Результат отмены установки флажка Use Default Gateway on Remote Network
При сохранении первоначального элемента 0.0.0.0 таблицы маршрутизации для NAT-сервера 8 итоге получен IP-адрес 20.47.41.13. Следует отметить, что туннельный сервер предоставляет адреса из динамически изменяющегося пула туннельных адресов. Информация, предоставляемая этим туннельным сервером, позволяет клиенту туннеля оперировать выбранным маршрутом по любому IP-адресу, найденному в подсети 20.0.0.0. Таким образом, поиск любых пунктов назначения в подсетях 0.0.2.0 или 20.0.0.0 охватывает всю маршрутную среду, в результате чего можно получить прямой доступ к ресурсам, воспользовавшись наиболее экономичным маршрутом.
Так что же происходит в том случае, если в корпоративной сети имеются другие подсети помимо тех, с которыми непосредственно соединен туннельный сервер? Предположим, например, что в корпоративной сети используется не только подсеть 20.0.0.0, но и подсеть 155.0.0.0. Маршрут, выбираемый для подсети 155.0.0.0, не является туннелем, а передается стандартному шлюзу, подключенному к Internet. В итоге, этот маршрут оказывается неработоспособным.
Для разрешения подобного затруднения проще всего добавить маршрут для клиента. В Windows 2000 имеется новый инструмент, функционирующий в режиме командной строки, который позволяет выполнять значительный объем работы по конфигурированию сети. Команда ROUTE может использоваться во всех версиях Windows 2000, однако при конфигурировании сервера рекомендуется все же использовать команду netsh.Tcm не менее, в приведенном ниже примере используется команда ROUTE.
Синтаксис этой команды следующий:
Route add 155.0.0.0 mask 255.0.0.0 20.47.41.13 -р
где 155.0.0.0 — пункт назначения, 255.0.0.0 — маска подсети, 20.47.41.13 — шлюз, а ~р - указывает на постоянство маршрута.
Команда NETSH
В1 Windows 2000 Server и более поздних версиях появилась новая команда NETSH, кото- рал способна конфигурировать практически все, что находится в среде RRAS. Для ввода постоянного маршрута используется следующий синтаксис этой команды:
Netsh routing ip add persistentroute 155.0.0.0 255.0.0.0 "interface name" nhop=20.47.41.13
Благодаря тому, что команда netsh осведомлена относительно имен интерфейсов, вполне возможным оказывается ввод тех маршрутов, которые нехарактерны для конкретных IP-адресов, как того требует команда ROUTE ADD. Это позволяет использовать интерфейсы на основе VPNс динамически изменяющимися IP-адресами.
Рассмотрим таблицу маршрутизации, приведенную на рис. 10.4. Как следует из данного рисунка, в данном случае сконфигурирован трафик, предназначенный для передачи в подсеть 155.0.0.0 непосредственно по IP-адресу, предоставленному туннельным сервером.
Однако, подобный подход имеет один недостаток. Большинство туннельных серверов передают IP-адреса входящим клиентам динамически: из статического пула либо посредством DHCP. В результате разъединения и повторного соединения с туннельным сервером, как правило, получается другой IP-адрес, который делает недействительным введенный постоянный маршрут. На рис. 10.5 показано, что IP-адрес 20.47.41.13 заменен адресом 20.47.41.15, в результате чего маршрут для подсети 155.0.0.0 оказывается уже недействительным.
RF1E3IIRF1E3II:Нчитгк Dr-tin-U ion:Нчитгк Dr-tin-U ionИ.Й.ИЛИ.Й.ИЛHirtcMok И.И.П.ИHirtcMok И.И.П.И1И.Р.Г . I1И.Р.Г . I10.0.2.5110.0.2.512» ЛЛ.Н 20.47-41.1 20.47.41.132» ЛЛ.Н 20.47-41.1 20.47.41.13255.И.Ы.И256.256.255.255255.И.Ы.И256.256.255.255127.И Л. 110.fL2.5120.47.41.1320.47.41 -13127 Л Л 1127.И Л. 110.fL2.5120.47.41.1320.47.41 -13127 Л Л 11И.И.2.51 1 IL Й,2.51 19.7 .Й.В.1 10.0.2.51 20.47--11. I I1И.И.2.51 1 IL Й,2.51 19.7 .Й.В.1 10.0.2.51 20.47--11. I I127. ИЛЛ127. ИЛЛ«.«.и«.«.и26.17,41.1126.17,41.112Й.17.-И .1112?.0,H.L20.47-It,132Й.17.-И .1112?.0,H.L20.47-It,13• L 71 .17221-И. В.И• L 71 .17221-И. В.И25Б.2ЬБ.2ЬБ.25Б25Б.2ЬБ.2ЬБ.25Б224 Л.U.И224 Л.U.И20.47.41-1310.И. 2.11Н.И.2.512И.47.-Н ,1320.47.41-1310.И. 2.11Н.И.2.512И.47.-Н ,13127.И.0.1. £8.4 ’ 1 а10.0.2.5110.И Л. 51127.И.0.1. £8.4 ’ 1 а10.0.2.5110.И Л. 51УсГ^нЦ G.itcwayУсГ^нЦ G.itcwayHI.И.HI.И.I И.И.2.51I И.И.2.51(jwumtXKj HiwiiH
RF1E3II
RF1E3II
:
Нчитгк Dr-tin-U ion
:
Нчитгк Dr-tin-U ion
И.Й.ИЛ
И.Й.ИЛ
HirtcMok И.И.П.И
HirtcMok И.И.П.И
1И.Р.Г . I
1И.Р.Г . I
10.0.2.51
10.0.2.51
2» ЛЛ.Н 20.47-41.1 20.47.41.13
2» ЛЛ.Н 20.47-41.1 20.47.41.13
255.И.Ы.И
256.256.255.255
255.И.Ы.И
256.256.255.255
127.И Л. 1
10.fL2.51
20.47.41.13
20.47.41 -13
127 Л Л 1
127.И Л. 1
10.fL2.51
20.47.41.13
20.47.41 -13
127 Л Л 1
1И.И.2.51 1 IL Й,2.51 19.7 .Й.В.1 10.0.2.51 20.47--11. I I
1И.И.2.51 1 IL Й,2.51 19.7 .Й.В.1 10.0.2.51 20.47--11. I I
127. ИЛЛ
127. ИЛЛ
«.«.и
«.«.и
26.17,41.11
26.17,41.11
2Й.17.-И .11
12?.0,H.L
20.47-It,13
2Й.17.-И .11
12?.0,H.L
20.47-It,13
• L 71 .17
221-И. В.И
• L 71 .17
221-И. В.И
25Б.2ЬБ.2ЬБ.25Б
25Б.2ЬБ.2ЬБ.25Б
224 Л.U.И
224 Л.U.И
20.47.41-13
10.И. 2.1
1Н.И.2.51
2И.47.-Н ,13
20.47.41-13
10.И. 2.1
1Н.И.2.51
2И.47.-Н ,13
127.И.0.1. £8.4 ’ 1 а
10.0.2.51
10.И Л. 51
127.И.0.1. £8.4 ’ 1 а
10.0.2.51
10.И Л. 51
УсГ^нЦ G.itcway
УсГ^нЦ G.itcway
HI.И.
HI.И.
I И.И.2.51
I И.И.2.51
f'ers latent Unutej:Hr tvnrk Adilrwa*ISb.H.O.Hf'ers latent Unutej:Hr tvnrk Adilrwa*ISb.H.O.HРис. 105 В результате использования динамического адреса туннеля постоянный маршрут может оказаться недействительнымРис. 105 В результате использования динамического адреса туннеля постоянный маршрут может оказаться недействительным
f'ers latent Unutej:Hr tvnrk Adilrwa*
ISb.H.O.H
f'ers latent Unutej:Hr tvnrk Adilrwa*
ISb.H.O.H
Рис. 105 В результате использования динамического адреса туннеля постоянный маршрут может оказаться недействительным
Рис. 105 В результате использования динамического адреса туннеля постоянный маршрут может оказаться недействительным
NvlnA'-k <i*t«'\*AV Athlfi ■ s
255.0.И.И 70.47.11.13
Рис. 10,4. Результат добавления постоянного маршрута в туннель (после установки подключения)
Недействительные постоянные маршруты
Для исключения недействительных постоянных маршрутов имеется несколько способов, каждый из которых рассматривается ниже со всеми присущими ему преимущества ми и недостатками.
Первый способ состоит в написании командного файла для поиска строк в команде IPConfign последующего формирования команды route add. К преимуществам такого подхода относятся следующие:
командныйфайлдаетклиентамвозможностьвводитькакиеугодномаршруты
без изменения конфигурации туннельного сервера;
разные командные файлы способны поддерживать клиентов любого типа.
К недостаткам такого подхода относятся следующие:
развертывание командных файлов в большинстве сред оказывается непрактичным;
многим пользователям не нравится предпринимать дополнительные шаги для установления соединения;
вероятность появления недействительных маршрутов в данном случае довольна высока;
ввод или удаление внутренних подсетей превращается в сущий кошмар, а централизованное управление ими затруднительно либо вообще невозможно.
Второй способ заключается в запуске на выполнение модуля Windows 2000 Server и установке конечных точек туннеля с помощью службы RRAS. К преимуществам такого подхода относятся следующие:
не происходит увеличения трафика, проходящего через туннель;
расширяются возможности службы RRAS.
К недостаткам такого подхода относятся следующие:
стоимость и сложность применения Windows 2000 Server для каждого клиента туннеля делают такой подход непрактичным;
в связи с тем, что конфигурирование каждого сервера осуществляется индивидуально, возникают трудности с поддержкой и сопровождением каждого участка сети;
многим пользователям не нравится предпринимать дополнительные шаги по установке соединения;
вероятность появления недействительных маршрутов в данном случае довольно высока;
ввод или удаление внутренних подсетей превращается в сущий кошмар, а централизованное управление ими затруднительно либо вообще невозможно.
Третий способ состоит во включении сценарного процесса к среде диспетчера подключений (Connection Manager). К преимуществам такого подхода относятся следующие:
упрощение поддержки, поскольку в ее основу в данном случае положено развертывание диспетчера Connection Manager;
пригодность для всех сетевых продуктов Windows;
обеспечение одношаговой регистрации пользователей.
К недостаткам подобного подхода относятся следующие:
непригодность для работы с внешними операционными системами; .
усложнение ввода или удаления внутренних подсетей.
Четвертый способ заключается в загрузке службы RIP Listener со стороны клиентов. К преимуществам такого подхода относятся следующие:
простота добавления или удаления внутренних подсетей;
предоставление администраторам корпоративных маршрутизаторов возможности владеть маршрутной средой.
К недостаткам такого подхода относятся следующие:
обязательное наличие операционной системы Windows NT или Windows 2000, установленной для клиентов;
неработоспособность протокола RIP во многих средах;
увеличение сетевоготрафика, проходящего через туннель.
Пятый способ состоит в применении протокола DHCP для Передачи маршрутов. К преимуществам такого подхода относятся следующие:
поддержка клиентов всех типов (при условии что они соответствуют описанию протокола DHCP в документе RFC);
простота ввода или удаления подсетей;
увеличение трафика только во время инициализации туннеля.
Недостаток такого подхода состоит в следующем:
в настоящее время реализация протокола DHCP в Windows 2000 не обеспечивает простого метода, используемого для конфи гурирова ни я подобного режима (в следующей версии данной операционной системы это положение, вероятно, изменится, но и в этом случае такой режим должны также поддерживать клиенты).
И последний способ состоит в применении атрибута пользователя Windows 2000 для передачу) статических маршрутов. К преимуществам этого подхода относятся следующие:
простота ввода или удаления подсетей;
увеличение трафика только во время инициализации туннеля;
конфигурирование такого режима посредством Active Directory.
К недостаткам такого подхода относятся следующие:
обязательность собственного режима Windows 2000 для домена;
обязательность клиентов Windows 2000 для туннеля;
обязательность выполнения клиентами регистрации в Active Directory при установлении каждого соединения.
Вопросы маршрутизации
В предыдущем разделе был рассмотрен ряд способов исключения недействительных постоянных маршрутов. Почему же этот вопрос по-разному решается в различных организациях? Как отмечалось выше, одни организации полагают, что применение маршрутизации клиентов служит основанием для прекращения связи, а другие развертывают туннели, используя такую маршрутную среду в качестве стандартной конфигурации.
На первый взгляд такое различие зависит, главным образом, от имеющейся степени риска нарушения защиты используемой конфигурации. Если клиент соединен как с Internet, так и с корпоративной сетью, может ли нарушитель получить доступ к подключенному таким образом компьютеру, проникнуть в систему и войти в корпоративную сеть без всякой аутентификации средствами защиты? Однако подобный вариант может оказаться маловероятным в силу ряда причин, которые изложены далее.
Общедоступный IP-адрес типичного клиента постоянно изменяется, поскольку большинство клиентов туннеля получают динамически изменяющиеся адреса от различных провайдеров услуг Internet. Это весьма усложняет использование клиентов в качестве "мишени для нападения".
Большинство клиентов не имеют отношения к трафику маршрутизации. Это вынуждает нарушителя изобретать изощренные способы нарушения защиты для имитации внутреннего адреса с целью сформировать определенного рода маршрут, проходящий через клиента. На столь непростое дело способны лишь немногие нарушители.
Даже если нарушитель получит доступ к корпоративным ресурсам, любой доступ ограничивается внутренней структурой зашиты. Несмотря на то, что для доступа ко многим внутренним Web-страницам аутентификация не требуется, определенного рода аутентификация обязательна для всех наиболее ценных серверов и служб.
Защита при маршрутизации
Если анализ системы безопасности позволяет сделать вывод о малой вероятности угрозы нарушения зашиты при маршрутизации клиентов, в чем суть возникающих проблем? Дело в том, что полномочия администраторов корпоративных сетей не распространяются на сети филиалов офисов. Следовательно. если служащий филиала или работающий на дому сотрудник, пользующийся локальной сетью, устанавливает связь с корпоративной средой, администраторам нелегко обнаружить факт несанкционированного доступа к корпоративной сети, реализуемого через туннельную среду.
Допустим, например, что у работающего на дому сотрудника имеется локальная сеть, подключенная к корпоративному туннельному серверу, который обеспечивает коллективное использование соединения и разрешает связь входящих туннелей с корпоративной средой. Это дает возможность сотруднику осуществлять несанкционированный доступ к корпоративной сети. При этом установление входящего соединения все еще будет ограничиваться дополнительными средствами защиты, однако тот факт, что трафик может передаваться по корпоративной сети VPN, является фактором риска нарушения системы безопасности.
Если данный сотрудник не несет личную ответственность за обеспечение безопасности сетевых каналов связи, эта проблема его не интересует. В итоге, сеть подвергается угрозе нарушения защиты независимо от того, используется ли при этом маршрутизация клиентов либо другой вид маршрутизации. Наилучшие гарантии зашиты в данном случае дает правильное обучение пользователей и разработка действенных процедур, устанавливающих ответственность клиентов.
Окончательное решение по данному вопросу должно быть принято в каждой организации в зависимости от ее собственных требований к защите. В ряде организаций, в которых мне приходилось работать (особенно финансовых), требовалась полная блокировка корпоративной среды с помощью маршрутизации, фильтров и любых других средств, которые призваны предотвратить нарушение системы безопасности. Поэтому очень важно, чтобы разработчик сетевой архитектуры и группы обеспечения безопасности системы работали над проектом вместе, принимая такие решения, которые обеспечат надлежащую защиту наряду с эффективной работой пользователей.
Дополнительные вопросы клиентской маршрутизации
Администратор туннеля обязан знать, какой должна быть установлена связь с сетями, находящимися в его ведении. Операционная система Windows 2000 Server в этом отношении допускает большую степень гибкости. Несмотря на то, что подобная гибкость считается сильной стороной данного программного продукта, она может вы-
звать некоторые проблемы, когда дело доходит до гарантии безопасности корпоративной сети. Главным образом, это связано с тем, что администратору будет непросто узнать о том, что клиент туннеля подключается к нескольким сетям и конфигурирует свои каналы связи, устанавливая шлюзы между сетями не надлежашим образом.
Имеющаяся в составе Windows 2000 служба маршрутизации и удаленного доступа (RRAS — Routing and Remote Access Service) обеспечивает формирование эффективной среды маршрутизации, которая способна снять ограничения, возникающие при проектировании и эксплуатации сетей. В частности, служба RRAS может быть использована для создания логических интерфейсов, которые фактически разделяют каналы связи VPN с множеством сетей. Помимо применения логических интерфейсов, служба RRAS исключает зависимость сервера от конкретного IP-адреса, используя вместо этого интерфейс в качестве идентификатора маршрута. Благоларя тому, что маршруты основываются на интерфейсе, сервер может параллельно соединяться с полностью изолированными сетями и безболезненно использовать ресурсы каждой такой сети на основании выбранных маршрутов.
Помимо выбора эффективных маршрутов на основании каналов связи VPN служба RRAS выполняет функцию сервера NAT, позволяющую создавать связи с разъединенными сетями, каждая из которых определяет конкретный адрес для туннеля. Эти единичные соединения могут совместно использоваться несколькими компьютерами в частной сети. Это позволяет использовать в частной сети одновременно несколько связей с разъединенными сетями, как показано на рис. 10.6.
Рис. 10.6. Основная топология сети, разъединенной с ПОМОЩЬЮ службы RRAS
На рисунке сервер Windows 2000 Server используется в единственной частной локальной сети в качестве клиента туннеля между сетями (корпоративные сети А и Б). Сервер может одновременно устанавливать и поддерживать связи с обеими сетями, имея в то же время прямой доступ к Internet. Кроме того, сервер может использовать совместно с клиентами каналы связи корпоративных сетей и подключение к Internet.
Такое совместное использование соединений может иметь определенные последствия для администраторов на обоих концах туннеля. Они не только должны быть обеспокоены тем, что сервер может подвергнуться нападению из Internet, но и тем, что
пользователи сети корпоративной сети А могут получить доступ к ресурсам корпоративной сети Б, и наоборот. И хотя такие соединения могут быть защищены, этот вопрос все же решает администратор сервера.
Важно также отметить. что обнаружить факт атаки корпоративных туннельных серверов будет непросто. Даже если бы ресурсы и были подвержены угрозе нападения, туннельному серверу был бы доступен лишь особенно активный клиент, а именно, сервер NAT Windows 2000. Обнаружить угрозу нарушения системы безопасности на корпоративном туннельном сервере практически невозможно, поскольку контроль трафика осуществляется после того, как пакеты данных покинут пределы туннельного сервера. Процесс определения имен может несколько усложниться при подключении к нескольким сетям, поскольку имена NetBIOS не могут использоваться в частной сети при поиске ресурсов в двух разъединенных сетях. При этом не гарантируется, что одно и то же имя не будет использовано в отдельных сетях, поскольку с точки зрения каждой из этих сетей конфликт не предполагается. Это вынуждает использовать в частной сети полностью определенное имя домена (Fully Qualified Domain Name - FQDN) для любого сервера, к которому осуществляется доступ. Более подробные сведения о конфигурировании системы именования доменов (DNS -- Domain Name System), используемой для реализации подобного рода среды, приведены в главе 11,
Как и в случае с большинством сетевых соединений, наилучший способ защиты заключается в доведении до пользователей важности обеспечения защиты, а также в реализации строгих процедур, закрывающих "бреши" в системе безопасности. Мне не кажется совершенно неверной такая организация сетевого канала связи. На самом деле, связывание локальной сети с несколькими сетями могло бы оказаться весьма полезным, если бы локальный администратор до конца понимал последствия такого шага. Однако при этом администратор туннеля должен полностью представлять степень возможного риск нарушения защиты в подобной конфигурации.
Автоматическая частная IP-адресация (АИРА)
В Windows 98 появилось новое СВОЙСТВО, AutoNet, которое в Windows 2000 получило другое название: автоматическая частная IP-адресация (APIРА — Automatic Private IP Addressing). B APIPA используется частный адрес класса В из пространства адресов 169.254, что означает возможность выбора одного из 65 тысяч адресов.
Благодаря применению механизма разрешения конфликтов DHCP в Windows 2000, гарантируется уникальность используемого адреса. Если APIPA и обнаруживает конфликт. то попытка его разрешения предпринимается до тех пор, пока не будет найден свободный адрес. А между тем, клиент продолжает зондировать сеть на предмет обнаружения сервера DHCP.
Технология APIPA применяется в качестве программного обеспечения малых учрежденческих и домашних локальных сетей (SOHO — Small OfTice/Home Office), в состав которых не включается сервер DHCP. В этом случае после загрузки клиент осуществляет поиск сервера DHCP. Если результаты поиска оказались неудачными, клиент назначает для себя сетевой адрес, недоступный при попытках доступа из Internet.
Как правило, APIPA применяется в тех случаях, когда к единственной локальной сети подключено небольшое число конечных систем. Компания Microsoft рекомендует использовать сервер DHCP, если в сети присутствует маршрутизатор либо к ней подключено значительное количество пользовательских систем. Если же в сети установлен сервер DHCP, механизм APIPA вообще не применяется, поскольку посылаемый клиентом запрос IP-адреса обрабатывается сервером DHCP.
Если две системы подключены к одной и той же частной сети, они могут взаимодействовать друг с другом, причем ручная настройка набора протоколов TCP/IP в этом случае не требуется. Если же клиентам требуется соединение с Internet, то для этого может
быть сконфигурировано такое устройство, как сервер NAT или прокси-сервер, который организует шлюз между адресуемой частным образом локальной сетью и Internet.
Как правило, служба NAT имеет некоторые встроенные функции DHCP, причем пользовательские системы, подключенные к локальной сети, могут обнаруживать сервер DHCP и получать от него требуемый адрес. Подобным образом подменяется роль API РА.
Если сервер DHCP не функционирует либо клиент не может реализовать связь при подключении к сети своей клиентской системы, в этом случае используется адрес APIPA. Если же сервер DHCP доступен, клиент обнаруживает его и получает свой адрес. В связи с тем, что сервер DHCP может простаивать длительное время, в небольших корпоративных сетях могут возникнуть определенные сложности, поскольку в этом случае клиенты начнут назначать для себя частные IP-адреса после выполнения перезагрузки системы.
При конфигурировании туннельного сервера в Windows 2000 пул адресов не определяется, следовательно, сервер DHCP недоступен для предоставления адресов, поэтому клиенты туннеля получают адрес APIPA. В некоторых случаях это вообще не представляет никакой проблемы, что, однако зависит как от конфигурации маршрута, так и от типа подключаемых сетей. В связи с возможными затруднениями в маршру- гизании не рекомендуется запускать туннельный сервер, используя APIPA, В качестве альтернативы можно без труда определить пул адресов, используемых в случае недоступности сервера DHCP.
В некоторых сетевых средах применение APIPA нежелательно. Режим APIPA может также отключаться на стороне клиентов, Для выполнения этой операции потребуется перейти к следующему ключу системного реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\l nterfасез\имя_адаптера
и создать запись типа DWORD:
IPAutoconfigurationEnabled: REG_DWORD
Для отмены поддержки APIPA в выбранном сетевом адаптере данному элементу можно присвоить значение 0. Если же элемент IPAutoconfigurationEnabled отсутствует, по умолчанию предполагается значение 1, указывающее на применение APIPA,
Если установлено несколько сетевых адаптеров, для отмены поддержки APIPA во всех установленных адаптерах достаточно присвоить элементу I?AutoconfigurationEnabled значение 0 в следующем ключе системного реестра:
HKEY LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Туннели и маршрутизация
Когда клиенты туннелей соединяются с туннельными серверами, обеспечивающими доступ к корпоративной сети, конфигурация маршрутов осуществляется довольно просто. Если клиенту требуется доступ к каким-либо ресурсам в корпоративной сети, он просто отправляет по туннелю трафик, а туннельный сервер осуществляет передачу этого трафика,
Что же, однако, происходит при передаче ресурсов в обоих направлениях? В этом случае маршрутизация значительно усложняется. Если, например, имеются филиалы офисов с контроллерами доменов, тогда необходима поддержка двунаправленной среды, в которой инициирование туннеля возможно на обоих его концах, причем маршрут должен быть известен и на том, и на другом конце туннеля. Это так называемый двунаправленный инициированный туннель.
По определению, все туннели являются двунаправленными. Если клиент инициирует туннель, а в это время пользователь регистрируется на туннельном сервере, мож-
но провести эхо-тестирование клиента так же, как и сам клиент может провести эхо- тестирование сервера. Результаты такого эхо-тестирования со всей очевидностью показывают двунаправленный характер трафика. Сложность заключается в том, что маршрутная среда на туннельном сервере не обновляется, а ресурсам корпоративной сети неизвестно о том, что они могут быть направлены клиенту по туннелю.
Для обновления маршрутной среды на туннельном сервере в Windows 2000 применяется простой метод присвоения имен. Если взять в качестве примера место расположения одного из филиалов в сети HappyVPN, то можно заметить, что в данной сети необходима поддержка трафика, приходящего в филиал и уходящего из него, поскольку в каждом филиале имеется контроллер домена. Ведь различные функции Active Directory требуют выполнения репликации в том или ином направлении, и поэтому, как следует из рис. 10.7, среда VPN должна быть достаточно гибкой, чтобы поддерживать такую возможность.
КлскЯаЛеКлскЯаЛеKnoxflouteXEastOakHiageKnoxflouteXEastOakHiageEastOakSdgeEastOakSdgeEastOakflidgeXKnoxfloirte
КлскЯаЛе
КлскЯаЛе
KnoxflouteXEastOakHiage
KnoxflouteXEastOakHiage
EastOakSdge
EastOakSdge
Имя интерфейса/Имн пользователя
Рис. 10.7. Двунаправленные инициированные туннели
Для определения двунаправленных инициированных связей достаточно согласовать имена интерфейсов с именем пользователя учетной записи службы. В данном примере сеть Knox Route связана с сетью EastOak Ridge. Таким образом, в сети KnoxRoute необходимо присвоить интерфейсу имя EastOakRidge и создать учетную запись с именем KnoxRoute. В сети EastOakRidge интерфейс называется KnoxRoute, a соответствующая учетная запись — EastOakRidge.
Службу RRAS не интересует, где именно находится учетная запись. Если каждая учетная запись хранится на местном сервере-участии ке, необходимо лишь определить имя сервера в пространстве домена среди параметров интерфейса, относящихся к регистрации.
Когда связь инициируется на одной стороне, это же происходит и на другой ее стороне. Если проанализировать состояние подключения, обе стороны туннеля окажутся соединенными между собой. Это дает возможность определять маршруты на каждой стороне туннеля, способной его инициировать.
Фильтрация пакетов
Если запустить мастер установки службы RRAS (RRAS SetupWizard), с его помощью можно автоматически настроить среду RRAS с учетом применения туннельного сервера. Обычно я этого не делаю, поскольку предпочитаю последовательно настраивать различные параметры. Если же воспользоваться упомянутым мастером, будут автоматически настроены фильтры сервера с целью обеспечения его безопасности. При этом важно понимать, какие именно фильтры устанавливаются этим мастером, чтобы результаты установки не показались неожиданными.
Как правило, данный мастер пытается выбрать внешний интерфейс, к которому должны применяться устанавливаемые фильтры, однако практика показывает, что в этом случае часто выбираются внутренние интерфейсы. Если фильтры применяются к внутреннему интерфейсу, покинуть туннельный сервер может только туннельный трафик, направляющийся во внутреннюю сеть, что не годится для большинства сред.
Для анализа фильтров, установленных с помощью упомянутого мастера, перейдите в меню <Start> (Пуск) и выберите команду Programs ^ Administrative Tools о Routing and Remote Access Service (Программы, Администрирование =0> Служба маршрутизации и удаленного доступа). Дважды щелкните на элементе IP Routing (IP-маршрутизация) в левой части
окна, выберите опцию General (Общие), щелкните правой кнопкой мыши на внешнем интерфейсе в правой части окна. В контекстном меню выберите элемент Properties (Свойства), затем щелкните на кнопке Input Filters (Входные фильтры). При этом входные и выходные фильтры должны быть одинаковыми, Применяемые фильтры показаны на рис. 10.8. Подробные сведения об их применении приведены в конце этой главы.
Рис. 10.8. Фильтры сервера VPN, настраиваем мые мастером по умолчаниюРис. 10.8. Фильтры сервера VPN, настраиваем мые мастером по умолчанию
Рис. 10.8. Фильтры сервера VPN, настраиваем мые мастером по умолчанию
Рис. 10.8. Фильтры сервера VPN, настраиваем мые мастером по умолчанию
Рис. 10.9. Туннельный сервер может быть размещен перед брандмауэромРис. 10.9. Туннельный сервер может быть размещен перед брандмауэром
Рис. 10.9. Туннельный сервер может быть размещен перед брандмауэром
Рис. 10.9. Туннельный сервер может быть размещен перед брандмауэром
Размещение туннельного сервера перед брандмауэром
Если туннельный сервер находится между Internet и внутренней корпоративной сетью, брандмауэр размешается либо перед туннельным сервером, либо после него, как показано на рис. 10.9. Так или иначе, важно защитить туннельный сервер от всего Поступающего трафика, кроме туннельного трафика. Если сеть не является испытательной, функции туннельного сервера не следует смешивать с другими функциями. Ведь если туннельный сервер выполняет другие функции, в частности, Web-сервера, защита в этом случае вообще не может быть строгой, что увеличивает вероятность атаки, приводящего к отказу обслуживания.
Как правило. для зашиты внутренней сети в брандмауэре применяется фильтрация пакетов. В соответствии с этим методом брандмауэр отвергает весь трафик, если он не указан как допустимый- Для этой цели может быть настроен туннельный сервер или брандмауэр, либо то и другое устройство.
Когда туннельный сервер находится перед брандмауэром, к интерфейсу с Internet должны быть применены фильтры пакетов, пропускающие только входящий и выХОДЯЩИЙ трафик VPN по указанному IP-адресу внешнего интерфейса туннельного сервера. Ниже перечислены преимущества такой конфигурации:
если корпоративный брандмауэр не пересылает протоколы, появляется возможность настроить доступ к сети;
брандмауэр может быть настроен на ограничение доступа клиентов туннеля к внутренним ресурсам;
размещение туннельного сервера непосредственно в Internet позволяет повысить производительность в среде, обеспечивающей высокую пропускную способность;
блокировке может подлежать весь доступ, осуществляемый как из корпоративной сети, так и в эту сеть, за исключением туннельного трафика;
брандмауэр способен регистрировать конкретные действия, поскольку трафик шифруется при прохождении через брандмауэр;
с помощью такойконфигурации иногда оказывается лроше предоставитьклиен- там туннеля услуги кэширования на сервере, чем применять специально для этой цели отдельный сервер.
Размещение туннельного сервера перед брандмауэром обладает также рядом следующих недостатков:
в случае атаки туннельный сервер оказывается на переднем крае защиты;
многие разработчики сетей предпочитают, чтобы службы брандмауэра предоставляли внешние операционные системы (в частности, UNIX), что позволяет внести в сеть разнообразие и тем самым усилить ее защиту от возможных атак.
Защита внутренних ресурсов
Если внешний интерфейс находится в Internet, необходимость его зашиты вполне очевидна, однако совсем другое дело внутренний интерфейс, обеспечивающий некоторую защиту внутренних ресурсов. После того как пул адресов будет определен как статический или назначаемый сервером DHCP, станет точно известен диапазон адресов, предоставляемых подключаемым клиентам. Следовательно, в качестве дополнительной зашиты во внутреннем интерфейсе можно определить выходной фильтр, который пропускает только указанный диапазон IP-адресов.
Несмотря на то, что подобный подход не препятствует пользователям сети совместно использовать общую туннельную связь вместе с таким устройством коллективного использования соединения, как сервер NAT или прокси-сервер, прямая маршрутизация или пересылка пакетов клиентами при этом не допускается. А поскольку упомянутый выше выходной фильтр не ограничивает возможности клиентов или сервера, имеет смысл использовать его в качестве дополнительной меры безопасности.
Настройка фильтров пакетов туннельного сервера на передачу пакетов протокола РРТР
Большинство туннельных серверов можно настроить на ограничение любого трафика, за исключением туннельного трафика. В приведенном здесь примере осуществляется настройка фильтров пакетов на пропускание только протокола туннелирования "точка- точка" (РРТР — Point-to-Point Tunneling Protocol). На режим фильтрации Drop All Packets Except Those That Meet the Criteria Below (Отвергнуть все пакеты, кроме тех, что удовлетворяют указанным критериям) настраиваются перечисленные далее входные фильтры.
Трафик обслуживания туннеля. Целевой IP-адрес внешнего адаптера туннельного сервера, адрес подсети 255.255.255.255, а порт назначения TCP 1723.
Туннельные данные. Целевой IP-адрес внешнего адаптера туннельного сервера, адрес подсети 255.255.255.255, а также идентификатор 47 протокола IP,
Если сервер обеспечивает двунаправленную туннельную связь или исходящие соединения, прохождение трафика обслуживания туннеля должно быть разрешено в обоих направлениях. IP-адрес назначения внешнего адаптера туннельного сервера, адрес полсети 255,255.255.255, а также исходный порт TCP 1723.
После настройки входных фильтров можно настроить и выходные фильтры. На режим фильтрации DropAll Packets Except Those That Meet the Criteria Below (Отвергнуть все пакеты, кроме тех, что удовлетворяют указанным критериям) настраиваются перечисленные ниже выходные фильтры.
Трафик поддержки туннеля. Исходный IP-адрес внешнего адаптера сервера VPN, адрес подсети 255-255.255.255, а также порт TCP 1723.
Туннельные данные. Исходный IP-адрес внешнего адаптера туннельного сервера, адрес подсети 255.255.255.255, а также идентификатор 47 протокола IP.
Если сервер обеспечивает двупаправленную туннельную связь или исходящие соединения, прохождение трафика поддержки туннеля должно быть разрешено в обоИХ направлениях. IP-адрес источника внешнего адаптера туннельного сервера, адрес подсети 255.255.255.255, а также порт назначения TCP 1723.
Настройка фильтров пакетов туннельного сервера на пропускание протокола L2TP/IPSec
В связи с тем, что в протоколе РРРТ используются разные параметры настройки, необходимо учитывать возможные потребности в использовании протокола туннелирования второго уровня (L2TP— Layer 2 Tunneling Protocol) и протокола безопасности в Internet (IPSec — IP Security). На режим фильтрации Drop All Packets Except Those That Meet the Criteria Below (Отвергнуть все пакеты, кроме тех, что удовлетворяют ука- данным критериям) настраиваются перечисленные далее входные фильтры.
Обмен ключей в Internet (IKE — Internet Key Exchange). Целевой IP-адрес внешнего адаптера туннельного сервера, адрес подсети 255.255.255.255, а также порт UDP 500.
Трафик L2TP. Целевой IP-адрес внешнего адаптера туннельного сервера, адрес подсети 255.255.255.255, а также порт UDP 1701.
После конфигурирования входных фильтров можно настроить на режим фильтрации Drop All Packets Except Those That Meet the Criteria Below (Отвергнутьвсе пакеты, кроме тех, что удовлетворяют указанным критериям) перечисленные ниже выходные фильтры.
Обменключейв Internet(IKE).IP-адресисточникавнешнегоадаптератуннель
ного сервера, адрес подсети 255.255.255.255, а также порт UDP 500.
Трафик L2TP. Исходный IP-адрес внешнего адаптера туннельного сервера, адрес подсети 255.255.255.255, а также порт UDP 170I.
Для трафика IPSec ESP (IP-протокол 50) фильтры не требуются, поскольку фильтры IPSec активизируются до использования фильтров RRAS.
Размещение туннельного сервера за брандмауэром
Если туннельный сервер находится за брандмауэром, последний может быть настроен на фильтрацию трафика. Общепринято размешать внешний интерфейс туннельного сервера в нейтральной зоне с тем, чтобы туннельный сервер мог разделять общее пространство с другими внешне ориентированными серверами, как показано на рис. 10.10.
Брандмауэр важно настроить таким образом, чтобы не нарушать выполнение любых других задач. В этом разделе перечислены фильтры, которые могут быть использованы в брандмауэре, пропускающем исключительно туннельный трафик, однако если брандмауэр обеспечивает услуги и ряда других служб, эти фильтры будут ограничивать трафик, необходимый другим приложениям. Для обеспечения работоспособности выбранной конфигурации брандмауэра в конкретной среде следует непременно поддерживать тесный контакт с поставщиком брандмауэра.
К преимуществам размещения туннельного сервера за брандмауэра относятся следующие:
брандмауэр оказывается на переднем крае защиты от атак со стороны Internet;
если брандмауэр защищает туннельный сервер, его блокировка может быть не столь жесткой.
К недостаткам размещения туннельного сервера за брандмауэром относятся следующие:
брандмауэр должен быть в состоянии направлять протоколы.
брандмауэр сможет регистрировать лишь незначительные сведения о туннельном трафике, который он пересылает, поскольку содержимое этого трафика шифруется.
Настройка фильтров пакетов брандмауэра на передачу пакетов протокола РРТР
Для пропускания брандмауэром трафика, имеющего отношение к протоколу РРТР, режим фильтра- НИИ Drop All Packets Except Those That Meet the Criteria I Below (Отвергнуть все пакеты, кроме тех, что удовлетворяют указанным критериям) следует установить для таких входных фильтров.
Рис. 10.10. Размещение туннельного сервера за брандмауэромРис. 10.10. Размещение туннельного сервера за брандмауэромТрафик поддержки туннеля. Целевой IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также порт назначения TCP 1723.
Рис. 10.10. Размещение туннельного сервера за брандмауэром
Рис. 10.10. Размещение туннельного сервера за брандмауэром
Туннельные данные. Целевой IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также идентификатор 47 протокола IP.
Если сервер обеспечивает двунаправленную туннельную связь или исходящие соединения, прохождение трафика, обеспечивающего поддержку туннеля, должно производиться в обоих направлениях. Целевой IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также исходный порт TCP 1723.
После настройки входных фильтров можно настроить на режим фильтрации Drop All Packets Except Those That Meet the Criteria Below (Отвергнуть все пакеты, кроме тех, что удовлетворяют указанным критериям) перечисленные ниже выходные фильтры.
Трафик поддержки туннеля. Исходный IP-адрес находящегося в нейтральной зоне адаптера VPN-сервера, а также порт TCP 1723.
Туннельные данные. Исходный IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также идентификатор 47 протокола IP.
Если сервер обеспечивает двунаправленную туннельную связь или исходящие соединения, прохождение трафика, реализующего поддержку туннеля, должно производиться в обоих направлениях. Исходный IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также порт назначения TCP 1723.
Настройка фильтров пакетов брандмауэра на передачу пакетов протокола L2TP/IPSec
Следует иметь в виду, что трафик L2TP/TPSec не сможет передаваться службой NAT. В связи с этим, при размещении брандмауэра перед туннельным сервером, он должен быть в состоянии пересылать трафик IPSec, не пользуясь услугами службы NAT. Поэтому необходимо проконсультироваться у поставщика брандмауэра, обладает ли его устройство такой возможностью.
Для конфигурирования протокола L2TP/IPSec с учетом использования режима фильтрации Drop All Packets Except Those That Meet the Criteria Below (Отвергнуть все пакеты, кроме тех, что удовлетворяют указанным критериям) могут быть настроены следующие входные фильтры.
Обмен ключей в Internet (IKE). Целевой IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также порт UDP 500.
Трафик L1TP. Целевой IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также порт UDP 1701.
Трафик IPSec ESP. Целевой IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также идентификатор 50 протокола IP.
После настройки входных фильтров можно настроить на режим фильтрации Drop All Packets Except Those That Meet the Criteria Below (Отвергнуть все пакеты, кроме тех, что удовлетворяютуказанным критериям) следующие выходные фильтры.
Обмен ключей в Internet (IKE). Исходный IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также порт UDP 500.
Трафик L2TP. Исходный IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также порт UDP 1701.
Трафик IPSec ESP. Исходный IP-адрес находящегося в нейтральной зоне адаптера туннельного сервера, а также идентификатор 50 протокола IP.
Для протокола L2TP фильтры не требуются, поскольку трафик L2TP шифруется в виде трафика IPSec ESP.
Выбор наиболее подходящего метода фильтрации пакетов осуществляет разработчик архитектуры корпоративной сети. В некоторых сетях возможно применение комплексных технических решений. Аналогично, все более распространенным становится применение двух типов брандмауэров, между которыми устанавливается нейтральная зона, благодаря чему появляется возможность воспользоваться особенностями каждого такого технического решения.
Резюме
Правильное понимание особенностей маршрутной среды туннельного сервера и ее влияния на разработку сети имеет решающее значение. Я отношу себя к сторонникам клиентской маршрутизации, поскольку такой подход обеспечивает повышение производительности И, на мой взгляд, не представляет серьезной угрозы для системы безопасности при правильном выборе конфигурации. Мне также кажется чрезвычайно важным обеспечение блокировки туннельного сервера с помощью стойких фильтров независимо от его расположения относительно брандмауэра.
11
Определение имен в Windows 2000
С момента выхода в свет версии Windows NT 4.0 и до появления Windows 2000 компанией Microsoft несколько раз изменялась система определения имен. Тем не менее, многие аспекты этой системы проявляются в Windows 2000 в той же степени, в какой они проявлялись в Windows NT 4.0. В Windows 2000 представлена динамическая система именования доменов (DDNS — Dynamic Domain Name System), позволяющая клиентам выполнять регистрацию имен хостов с помощью сервера DNS, в отличие от использовавшегося в предыдущих версиях подхода с применением статической системы DNS. Благодаря этому, Microsoft перешла от изначально использовавшегося соглашения о наименовании на базе системы NetBIOS до устойчивой среды наименования, которая является более практичной с учетом широкой сферы ее применения.
На первом этапе разработки Windows 2000 Microsoft объявила, что в чистой сети на базе Windows 2000 использование службы имен Internet для Windows (WINS ■ ■ Windows Internet Naming Service) и системы NetBIOS не имеет особого смысла. Несмотря на это, практика показала, что, невзирая на отсутствие устаревших клиентов, необходимо иметь эффективную среду NetBIOS (обычно сервер WINS). Это связано с тем, что некоторые современные приложения Windows по-прежнему используют интерфейсы API NetBIOS. Как правило, это нецелесообразно, поскольку во многих средах поддерживаются системы Windows 95/98 и Windows NT 4.0. Однако, при удовлетворении указанных выше потребностей важно не только выполнять развертывание Active Directory (AD), но также и устанавливать туннельную среду. При развертывании сети VPN должны не только удовлетворяться потребности среды наименования, реализованной на базе системы NetBIOS, но и поддерживаться сервер DDNS с тем, чтобы в ближайшем будущем это могло способствовать полному переходу исключительно в среду DNS.
К счастью, с точки зрения конечного пользователя, благодаря эффективно разработанной инфраструктуре наименования, клиенты даже и не подозревают о том, каким образом определяются исходные имена ресурсов. Когда пользователь указывает имя определенного ресурса, он должен знать или хотя бы иметь представление о том, как оно будет определяться. Важен сам факт определения имени, а также прогнозируемое выполнение приложения.
Все администраторы Windows NT 4.0 знакомы со стандартным порядком выполнения определения имен, Порядок следования событий в заданной по умолчанию конфигурации определения имен представлен в табл. 11.1.
Таблица 11.1. Стандартный порядок определения имен
Определение имени хоста
Определение имени NetBIOS
Локальное имя хоста
Файл хостов
Система DNS (включая кэш DNR)
Кэш NetBIOS
Система WINS
Широковещательная рассылка
Файл LMHost
Кэш NetBIOS
Система WINS
Ш ироковешательная рассылка
Файл LMHost
Файл Host
Система DNS (включая кэш DNR)
В целом, описанный процесс определения имен в Windows 2000 не особо изменился. Тем не менее, так же, как в случае с Windows NT 4.0, данный порядок можно изменить вручную. Важно отметить, что при использовании Active Directory поведение Windows 2000 зависит от применения системы DNS. Многие объекты AD находятся лишь на сервере DNS. Из этого наверняка следует, что сбои в работе в структуре DNS могут повлечь за собой прекращение функционирования Active Directory.
Внедрение различных проектов испытательной сети HappyVPN началось со второй половины 1998 года, и на сегодняшний день можно с уверенностью заявить, что основной причиной возникновения различных проблем явилась плохо спроектированная среда DNS. Если определение имен с помощью DNS не функционирует, это сказывается на многих других компонентах. Прежде, чем начнется эксплуатация сети, важно удостовериться в эффективности функционирования инфраструктуры DBS. От этого в абсолютной степени зависит использование Active Directory.
Определение имен для туннельных клиентов
При подключении туннельного клиента к туннельному серверу устанавливаются параметры протокола TCP/IP, включая адреса серверов WINS и DNS в корпоративной сети. Это обычно достигается с помощью следующих трех методов:
туннельный сервер передает пакеты протокола динамической конфигурации хоста (DHCP — Dynamic Host Configuration Protocol), поддерживающего адреса с опциями определения области доступа, которые определяют IP-адреса сервера;
туннельный сервер поддерживает статический пул адресов, а адреса сервера имен, используемые сервером, передаются обратно клиенту;
туннельный сервер располагает адресами сервера имен, которые аннулируют указанные выше настройки.
Обычно клиент подключается к сети Internet с помощью провайдера услуг Internet (ISP), который предоставляет клиенту адрес сервера DNS. Таким образом, конфигурируется клиент определения имен в Internet для данного логического либо физического адаптера. При подключении клиента к туннельному серверу определяется новый логический адаптер, свойства которого включают IP-конфигурацию, передающуюся клиенту.
Клиент отсылает запросы имен первому серверу DNS для всех адаптеров, ожидает две секунды, а затем отсылает запрос на все известные ему серверы DNS. Благодаря клиентскому маршруту, определяется, каким образом клиент получает доступ к различным серверам имен. Об этом подробнее рассказывается в главе 10. Если клиент использует туннель в качестве заданного по умолчанию шлюза, то, вероятно, что адрес DNS, предоставляемый провайдером услуг Internet, не применяется. Весь трафик
передается в корпоративную сеть, а запрос на определение имен обрабатывается корпоративными серверами имен еше до того, как он будет направлен по адресу DNS, предоставляемому провайдером услуг Internet. Если клиент находится за корпоративным брандмауэром, то брандмауэр должен разрешить прохождение трафика через порт 53, в результате чего обеспечивается успешная обработка запросов.
Если клиент конфигурируется для выполнения маршрутизации соответствующего трафика в направлении заданного интерфейса, в процессе определения имен обычно достигается логический результат. Система DNS, предоставляемая провайдером услуг Internet, обеспечивает определение имен ресурсов Internet, а корпоративный сервер выполняет определение имен корпоративных ресурсов.
Клиенты Windows 2000 также имеют возможность регистрировать имена своих хостов. Подобная регистрация может производиться не только провайдером услуг Internet, но также и выполняться на узле сети VPN. Это означает, что в отличие от варианта с применением Windows NT 4.0 можно создать зону DNS. которая будет определять имена всех активных клиентов на корпоративных серверах. Можно создать такую зону, как, например, tunnelclients.internal.happyvpn.net, с тем, чтобы внутренние серверы смогли бы фактически определять динамически изменяющиеся IP-адреса любых туннельных клиентов. Однако эта настройка не задается по умолчанию, поскольку некоторые пользователи не видят в ней необходимости. Тем не менее, данное свойство можно довольно просто настроить и использовать в дальнейшем, следуя пунктам процедуры 11,1.
Процедура 11.1. Конфигурирование клиента с целью регистрации имени хоста для туннельного подключения
L Правой кнопкой мыши щелкните на объекте подключения туннельного интерфейса, определенного для клиента, затем выберите пункт Properties (Свойства).
Щелкните на вкладке Networking (Сеть).
Выберите компонент Internet Protocol (TCP/IP), затем выберите пункт Properties.
Щелкните на кнопке <Advanced> (Дополнительно).
Для просмотра опций, представленных на рис. 11.1, щелкните на вкладке DNS.
Если необходимо присоединить настраиваемый суффикс вместо суффикса, заданного по умолчанию, который выдается туннельным сервером, установите переключатель Append These DNS Suffixes (Добавить данные суффиксы DNS), а затем щелкните на кнопке <Add> (Добавить). Введите имя зоны и снова щелкните на кнопке <Add>.
Установите флажок Register This Connection's Addresses in DNS (Зарегистрировать адреса данных подключений на сервере DNS).
Важно отметить, что, если туннельный сервер использует сервер DHCP для управления IP-адресами туннельных клиентов, то сервер DHCP может конфигурироваться для выполнения динамической регистрации туннельных клиентов. Это имеет большое значение при поддержке разнообразных клиентов, особенно если некоторые из них не знают, как следует регистрироваться с помощью DDNS. Данная процедура известна под наименованием Fully Qualified Domain Name (FQDN) Option 81 (Опция 81 полностью определенного имени домена). Эта опция включает несколько полей, позволяющих клиенту извещать сервер DHCP относительно необходимости регистрации в пакете DHCPREQUEST. Сами поля перечислены далее.
Code (Код). Код опции.
Len (Длина). Длина данной опции.
Flags (Флаги). Определение типа службы.
0. Клиент, который отвечает за регистрацию записи хоста.
I. Клиент запрашивает сервер DHCP о регистрации записи хоста.
2. Сервер DHCP, который отвечает за регистрацию записи хоста клиента независимо от настроек клиента.
RCODE1. Определяет ответный код, отсылаемый сервером клиенту.
RCODE2. Пространство поддержки RCODE1
Имя домена. Имя FQDN клиента.
Благодаря описанной выше структуре, клиенты, использующие Windows 2000 или более ранние версии, могут регистрировать все адреса TCP/IP на сервере DDNS. Конечный результат достигается даже в том случае, если клиенты не знают о существовании DDNS, например, клиенты Windows 95, имена хостов которых представлены в DDNS.
Рис. 11.1. Связи VPN, регистрирующие имя хоста для туннельной связиРис. 11.1. Связи VPN, регистрирующие имя хоста для туннельной связиОпределение имен для домашней сети/филиала офиса
Рис. 11.1. Связи VPN, регистрирующие имя хоста для туннельной связи
Рис. 11.1. Связи VPN, регистрирующие имя хоста для туннельной связи
Домашняя сеть/филиал офиса может представлять пример более сложной среды, используемой при определении имен. Основная причина возрастающей степени сложности заключается в том, что обеспечивается больше возможностей при проектировании. В данном разделе представлено три распространенных сценария.
Первый сценарий. Если туннельный клиент является конечным пунктом туннеля, и туннель просто проложен через какое-то совместно используемое устройство, процесс установки напоминает установку стандартного клиента (рис. 11.2). Различие состоит в том, что конфигурация внутреннего интерфейса может указывать на устройство, совместно использующее подключение к Internet, а затем запросы имен передаются провайдеру услуг Internet.
Второй сценарий. Граничный сервер является конечным пунктом туннеля, и конфигурация DNS присоединяется к конфигурации IP (рис. 11.3). Когда запрос имени отсылается граничному серверу, последний передает запрос основному серверу имен,
Третий сценарий. Сервер DNS, являющийся локальным для домашней се- ти/филиала офиса, клиенты которого обращаются к локальному серверу DNS для определения имен, представлен на рис. 11.4. Сервер DNS должен знать, каким образом следует передавать запросы корпоративным серверам DNS с целью определения имен внутренних ресурсов.
Рис. 11.2. Домашняя сеть с туннелями, проходящими через сервер NATРис. 11.2. Домашняя сеть с туннелями, проходящими через сервер NATРис. 11.4, Сервер NAT также является конечным пунктом туннеля, использующим локальный сервер DNSРис. 11.4, Сервер NAT также является конечным пунктом туннеля, использующим локальный сервер DNS
Рис. 11.2. Домашняя сеть с туннелями, проходящими через сервер NAT
Рис. 11.2. Домашняя сеть с туннелями, проходящими через сервер NAT
Рис. 11.4, Сервер NAT также является конечным пунктом туннеля, использующим локальный сервер DNS
Рис. 11.4, Сервер NAT также является конечным пунктом туннеля, использующим локальный сервер DNS
Конфигурирование сервера DNS для среды домашней сети/сети филиала офиса
В Windows 2000 Server появилась возможность по выполнению и поддержке полноценной службы DDNS. Поэтому, если на компьютерах филиала офиса потребуется установить Windows 2000 Server, лучше всего сконфигурировать локальный сервер DNS. Данное решение обеспечивает следующие преимущества:
с помощью локального сервера DNS появляется возможность администрирования собственных зон, используя наиболее подходящие для локальной сети методы;
можно сконфигурировать локальный объект Active Directory в локальной сети;
все локальные клиенты могут динамически регистрировать сами себя независимо от состояния подключения;
локальный сервер DNS может в значительной степени ускорять процесс определение локального имени, а также может быть связан с локальным сервером WINS;
сервер DNS может быть сконфигурирован для выполнения перенаправления в сторону провайдера услуг Internet либо может передавать запросы непосредственно корневому серверу (подобная гибкость позволяет создать сетевое окружение, не зависящее от провайдера услуг Internet);
сервер DNS может быть сконфигурирован для выполнения направления корпоративным серверам;
все результаты могут быть кэшированы, в результате чего повышается быстродействие процесса определения имен.
Данная конфигурация имеет также и некоторые недостатки, к числу которых можно отнести следующие:
локальный администратор должен администрировать сервер;
локальный администратор должен быть знаком с сервером DNS.
Некоторые среды устанавливаются таким образом, что сервер DNS в домашней се- ти/сети филиала офиса просто отсутствует. Это связано с тем, что достигается уровень сложности, который просто неприемлем для многих локальных сетей. Тем не менее, если некоторым домашним сетям/сетям филиалов офиса данная задача все же под силу, подобный тип конфигурации настоятельно рекомендуется в силу описанных выше преимуществ. В процедуре 11.2 перечислены действия по установке сервера DNS в локальном офисе.
Процедура 11.2. Конфигурирование сервера DNS для домашней сети/сети филиала офиса
В панели управления выберите позиции Add/Remove Programs => Add/Remove Windows Components G> Networking Services Ф Details (Добавление и удаление программ с^ Добавление и удаление компонентов Windows ф Сетевые службы ф Состав) и установите флажок Domain Name System (DNS).
Установив сервер DNS, перейдите в меню кнопки <Start> (Пуск) и выберите пункты меню Programs ■=?■AdministrativeTools Е> DNS (ПрограммыфАдминистрирование=>DNS).
Если требуется поддерживать локальные зоны, создайте и сконфигурируйте необходимые для вашей среды зоны. Если необходимость в установке зон отсутствует, то в роли используемого сервера выступает сервер, выполняющий исключительно операцию кэширования.
В правой панели правой кнопкой мыши щелкните на имени сервера и выберите пункт Properties (Свойства) (рис. 11.5).
В поле свойств щелкните на вкладке Forwarders (Пересылка).
Установите флажок Enable Forwarders (Разрешить пересылку) и укажите корпоративный сервер DNS, который будет получать запросы (рис. 11.6),
Если требуется, чтобы сервер не подключался к провайдеру услуг Internet, а запрашивал непосредственно корневой сервер, удостоверьтесь, что флажок Do Not Use Recursion (He использовать рекурсию) не установлен. Если же этот флажок будет установлен, то сервер будет определен как рекурсивный (ведомый), в результате чего все запросы, не определяемые локально, будут отсылаться согласно указанной пересылке.
Есливсежетребуется,чтобы серверпередавалзапросы,а такжеобрабатывалза
просы Internet-имен, укажите также адрес DNS, предоставляемый провайдером услуг Internet. Данная конфигурация не вполне приемлема, поскольку невозможно (используя поддерживаемые способы) сконфигурировать "умные устройства пересылки" в текущей версии операционной системы. Единственное, что можно сделать при работе с этим экраном, — указать серверу DNS, какое устройство пересылки следует использовать первым.
Данная конфигурация представляет собой конфигурацию типа "сервер-сервер", поэтому, если в состав домашней сети/сети филиала офиса включено более одного сервера DNS, ее следует применить к каждому из них. Повторите описанные действия для каждого сервера DNS.
Puc. IL5, Выбор свойств для сервера DNSPuc. IL5, Выбор свойств для сервера DNS
Puc. IL5, Выбор свойств для сервера DNS
Puc. IL5, Выбор свойств для сервера DNS
251251Puc. 11. 6. Конфигурирование пересылки длясервера DNS
251
251
Процедура 11.2. Конфигурирование сервера DNS...
Определение имен для разъединенных сетей
Как уже отмечалось в главе 10, теперь не представляет никакой сложности подключать домашнюю сеть/сеть филиала офиса одновременно к многочисленным сетям и результативно управлять средой маршрутизации. Учитывайте, что потребуется определить, обеспечит ли подобный процесс конфигурирования сети достаточный уровень безопасности.
Если маршрутизация была сконфигурирована корректно, клиенты домашней се- ти/сети филиала офиса могут успешно выполнять эхо-тестирование IP-адресов локальной сети, узлов корпоративных сетей А и Б (рис. 11.7). Остается только определить имена для всех трех сетей.
Рис. 11.7 Одновременный доступ к разъединенным сетям
Первый вопрос, возникающий при работе с разъединенными сетями, заключается в том, что в этом случае следует навсегда забыть об использовании имен NetBIOS. В силу того, что сети разъединены, каждая из них должна содержать одни и те же имена NetBIOS, в результате чего процесс определения имен становится невозможным. Это означает, что с целью эффективного определения имен они должны быть именами FQDN. В Windows 2000 данное свойство полностью поддерживаемо, но, тем не менее, пользователям домашней сети/сети филиала офиса не мешает попрактиковаться, чтобы изменить используемые методы поиска компьютеров в сети.
Вероятно, единственный практический способ поддержки подобного типа сетевого окружения заключается в установке локального сервера DNS в домашней сети/сети филиала офиса. Несмотря на имеющийся локальный сервер DNS, было бы нецелесообразно просто добавить устройства пересылки для каждого из корпоративных серверов DNS, поддерживающих различные разъединенные сети, поскольку устройства пересылки не определяются доменным именем, Поэтому, например, если клиенту понадобится сервер с именем server.corpb.com, он не сможет уведомить сервер DNS о направлении данного запроса на сервер DNS в корпоративной сети Б. В этом случае клиент просто обратится к списку устройств пересылки, определенных в порядке перечисления в конфигурации DNS.
Несмотря на то, что указанное выше свойство официально не поддерживается компанией Microsoft, реализации его на практике можно достичь путем изменения списка корневых ссылок. Чтобы уведомить сервер о наличии авторизованного сервера имен для определенных доменов, можно добавлять записи в список корневых ссылок.
Вот как обычно функционирует список корневых ссылок, находящийся в файле cache, tins. Существуютсерверы с именами . com, . net, а также некоторые другие; использование точки обозначает процесс добавления записей, с помощью которых сервер DNS определяет, какой сервер является авторизованным для доменов corpa.com и ccrpb.com. В процедуре 11.3 представлены действия, выполняющие добавление таких записей.
Процедура 11.3.
Добавление пользовательских записей в файл Cache.DNS
Откройте файл С:\WINNT\system32\dns\cache.dns, используя приложение Notepad (Блокнот).
Добавьте доменные записи, используя тот же формат, который применяется для списка корневых ссылок (рис. 11.8).
Закройте файл, сохранив перед этим информацию.
Перейдите в консоль DNS MMC, правой кнопкой мыши щелкните на сервере, выберите пункт Properties (Свойства) и щелкните на вкладке Root Hint (Корневая ссылка). Обратите внимание, что в этом случае записи не отображаются.
Рис- 11.8. Изменение файла cache.dns
Примечание
Несмотря на то, что данная процедура довольно обычна в среде администраторов UNIXDNS, другие администраторы могут быть незнакомы с подобным потенциальным решением проблемы. Это связано с тем, что Microsoft официально не поддерживает добавление записей в список корневых ссылок. Несмотря на наличие подобных моментов, рассмотренная выше технология является весьма эффективной.
Определение имен в среде Active Directory, основанной на использовании сетей VPN
В данной главе описываются основные конфигурации для клиентов, подключающихся к корпоративной сети, а также рассматриваются обеспечиваемые при этом преимущества. Поэтому несложно будет начать развертывание сети филиала офиса, используя узлы сети VPN вместо выделенных линий. Подобная цель выдвигалась при
Определение имен в среде Active Directory, основанной на использовании
сетей VPN253
разработке сети HappyVPN, которая оказалась весьма жизнеспособной. Далее приведен перечень преимуществ, реализуемых в случае использования этого решения.
В значительной степени сократились затраты на подключение. В случае использования стандартного локального подключения к общедоступной сети (Internet) вместо выделенных линий значительно сокращаются накладные расходы.
Улучшена степень масштабируемости. Если филиалу офиса потребуется дополнительная полоса пропускания данных или он изменит свое размещение, изменения в сеть можно внести быстро и просто.
Способность филиала использовать услуги любого провайдера Internet. Главным критерием в этом случае является наличие базового доступа к Internet. Благодаря этому, компания может контролировать свои затраты, выбирая того провайдера, который лучше всего удовлетворял бы ее потребности.
Высокая степень гибкости сети. Применяя методы, которые никогда ранее не использовались, рассматриваемое решение предлагает высокую степень гибкости. Это связано с тем, что сервер DNS может быть сконфигурирован для запроса списка корневых подсказок, а подключения основаны на использовании обобщенного подключения к Internet.
Сети HappyVPN Networks - - учебный пример
В качестве основы при рассмотрении вопроса относительно среды определения имен в разделе подробно описывается испытательная сеть (HappyVPN Networks), a также процесс ее настройки.
Корпорация HappyVPN Networks имеет два офиса в Кноксвилле, штат Теннесси (Knoxville, Tennessee), один из которых является штаб-квартирой корпорации, а другой — филиалом офиса. В рамках проекта также поддерживаются два филиала офиса в Оук Ридже, штат Теннесси (Oak Ridge, Tennessee). Компания HappyVPN Networks динамически развивается, и ей нужен такой проект сети, который сможет максимально безболезненно удовлетворять потребности, возникающие при стремительном росте количества филиалов.
Кроме того, клиентам филиалов офисов требуется быстрый и простой доступ к ресурсам, как из корпоративной сети, так и из Internet. Потребности клиентов в одновременном корпоративном и Internet-доступе порождают множество вопросов безопасности, которые бьши освещены в главе 10. Администраторы должны конфигурировать сеть не только с целью предоставления пользователям нужных им сетевых возможностей, но также и с целью удовлетворения требований политик корпоративной безопасности.
Проектирование сети VPN
Первый шаг в разработке сети VPN заключается в определении потребностей компании. Ниже представлены некоторые соображения, которые учитываются во время проектирования сети HappyVPN Networks.
Пользователи. В сети HappyVPN Networks пользователи свободно перемешаются, используя портативные компьютеры, поэтому проект сети должен гарантировать не только поддержку подключений филиалов, но также и поддержку удаленных пользователей.
Подключения. Все филиалы сетей HappyVPN Networks имеют независимые подключения к Internet. Для двух местоположений, штаб-квартира (Headquarters) и филиал в Сиэттле (Seattle), используются статические IP-адреса. Все остальные узлы имеют динамические IP-адреса, которые управляются либо с помощью регистрации динамических IP-адресов на общедоступном сервере DDNS (например, DynDNS.org или TZO.COM), либо с помощью конфигурирования
апплета DDNS, который выполняет регистрацию в штаб-квартире DNS. Цель данной процедуры заключается в том, чтобы сделать определяемыми динамические IP-адреса филиалов офисов.
Можно сконфигурировать граничный сервер на базе Windows 2000 с целью использования встроенных возможностей регистрации и простой регистрации внешнего интерфейса с помощью общедоступного сервера DDNS системы Windows 2000, установленного в штаб-квартире корпорации. В связи с этим в определенный момент времени потребуется зарегистрировать доменное имя, в то же время избежать применения клиентских приложений.
Аппаратное обеспечение. В рассматриваемых филиалах офисов можно было бы использовать множество различных проектов. При тестировании процесса развертывания сетей HappyVPN применялось несколько различных сетевых проектов, некоторые из них работали великолепно, а другие обладали определенными недостатками.
На следующих рисунках демонстрируются три опробованных проекта. Система, ответственная за выполнение всех задач, представлена на рис.! 1.9.
Используя данную опцию, одна система ответственна за выполнение всех задач. Для наших целей используется групповая система, устанавливаемая как в Internet, так и во внутренней сети. Она отвечает за совместное использование подключений Internet для клиентов филиалов офисов, поэтому с целью обеспечения безопасности настраивается фильтрация пакетов. В задачи сервера входит управление сервером DDNS, функционирование в роли сервера каталогов, туннельного клиента и управление сервером WINS для филиала офиса.
Преимуществом использования данного типа системы является возможность использования только одного сервера в месте размещения филиала.
При использовании подобного типа систем проявляются следующие недостатки:
данная конфигурация чрезвычайно проблематична в плане конфигурирования и обслуживания (отчет времени таймаута для различных служб представлял постоянную проблему, которая длительное время не разрешалась с момента запуска сервера);
сервер является единственным местом возникновения сбоев;
фильтрация пакетов была затруднена из-за сложности конфигурирования сети;
сервер DDNS по умолчанию регистрирует все интерфейсы независимо от настроек конфигурации сети (для изменения подобного порядка действий потребуется изменение системного реестра);
весьма трудно обеспечить безопасность данной конфигурации в силу незащищенного по сути обычного сервера NAT (кроме того, вместе со всеми выполняемыми службами данного набора большое значение имеет потенциальный риск для системы безопасности).
Ниже приведены две системы, одна из которых выполняет подключение, а другая — функции контроллера домена (рис. 11.10).
Конфигурация, представленная на рис. 11.10,обеспечивает следующие преимущества:
при реализации этого проекта доменный контроллер помещается вне Internet, благодаря чему гораздо проще обеспечивается безопасность;
сервер DDNS может эффективно функционировать, не требуя изменений системного реестра (конфигурация сервера DDNS обычная, поэтому среда VPN не требует особого внимания, поскольку в случае использования подобной среды не требуется доменный контроллер);
благодаря разделению служб, реализуется несложный процесс фильтрации пакетов;
в силу того, что контроллер домена является единой системой NIC (контроллер сетевого интерфейса), данная конфигурация весьма проста в использовании;
служба сервера NAT может обрабатывать весь трафик Internet, не прибегая к разделению среды VPN, поскольку администраторы управляют схемой частной подсети.
Рис, 11.10. Данный филиал офиса включает отдельные системы для гран им - ного сервера и контроллера доменаРис, 11.10. Данный филиал офиса включает отдельные системы для гран им - ного сервера и контроллера доменаРис. 11.9. Филиал офиса использует одну систему для выполнения всех задачРис. 11.9. Филиал офиса использует одну систему для выполнения всех задачДанная конфигурация имеет также и следующие недостатки:
Рис, 11.10. Данный филиал офиса включает отдельные системы для гран им - ного сервера и контроллера домена
Рис, 11.10. Данный филиал офиса включает отдельные системы для гран им - ного сервера и контроллера домена
Рис. 11.9. Филиал офиса использует одну систему для выполнения всех задач
Рис. 11.9. Филиал офиса использует одну систему для выполнения всех задач
серверNATнеможет обеспечитьвысокуюстепеньбезопасности(онможет
справиться с фильтрацией пакетов, однако подобная фильтрация должна применяться корректно);
для использования на практике данной конфигурации требуется наличие двух систем;
могут возникать проблемы с сервером NAT при обработке трафика LDAP (эти действия постоянно выполняются Active Directory).
Был также испытан проект комбинированной сети, который предполагал совмещение преимущества туннельной среды и прокси-сервера. Известно, что можно выполнять прокси-сервер на граничном сервере туннеля, однако, в этом случае потребуется обеспечить максимальную степень безопасности сети. К прокси-серверу были добавлены маршруты частной подсети. В результате этого, несмотря на использование прокси в качестве заданного по умолчанию шлюза, он будет осведомлен в том, что частные маршруты ведут к туннельному серверу. Одна система, используемая в качестве туннельного сервера, а вторая — в качестве прокси-сервера, представлена на рис. ll.il. За этими системами установлен контроллер домена.
Комбинированная сеть обеспечивает следующие преимущества:
отсутствует сервер NAT (туннельный сервер/клиент заблокирован для любого типа доступа, за исключением передачи туннельного трафика, поэтому он отбрасывает все, исключая туннельный трафик).
прокси-сервер считается более безопасным, чем NAT (при этом он также допускает Web-кэширование и реализует некоторые другие возможности);
сервер DDNS может выполняться эффективно, не требуя выполнения изменений в системном реестре. Конфигурация DDNS будет самой обычной, поэтому среда VPN не требует особого внимания (дополнительная причина подобного положения вещей заключается в том, что для среды VPN не требуется доменный контроллер);
поскольку доменный контроллер представляет единую систему контроллера сетевых интерфейсов, данная конфигурация проще в управлении.
Филиал офиса
Рис. 11.11. Рассматриваемый проект включает два сервера: один выполняет функции сервера NAT, второй предназначен для размещения прокси-служб
Данный проект сети имеет также и следующие недостатки:
требуется установка трех систем (можно было бы объединить прокси-клиент и туннельный клиент, однако, в результате этого повышается нагрузка на граничный сервер);
При использовании двух граничных серверов провайдеру услуг Internet потребуется выделить два IP-адреса.
Важно отметить, что, используя среду VPN, сетевой администратор может разработать произвольное решение. Вопрос роли проекта очень важен, поэтому на практике была доказана высокая эффективность второго и третьего сетевых проектов (рассматриваются выше).
Взаимосвязь между серверами определения имен филиала офиса
Можно отметить еще раз, что службы определения имен могут применяться в сети несколькими способами. Допуская, что сетевая инфраструктура существует и работает, среды DDNS и WINS можно сконфигурировать таким образом, как если бы подключения VPN были бы обычными выделенными линиями связь. Основная цель, преследуемая в этом случае, заключается в использовании пропускной способности каналов связи наиболее эффективными способами.
При разработке сети HappyVPN использовался типичный проект "колесо и спина”, реализующий репликацию WINS. Кроме того, репликация была спланирована таким образом, чтобы ее трафик происходил в нерабочее время.
Сеть предлагает три выбора, включающие среду DNS: использование для репликации вторичных устройств, устройств пересылки либо применение репликации, интегрируемой в состав Active Directory. Если модель домена включала единственный уровень, то решение, интегрированное в структуре Active Directory, работало неплохо, и поэтому не возникало необходимости в использовании вторичных устройств в филиалах офисов. Тем не менее, если Active Directory имеет дочерние домены, необходимо проанализировать характеристики пропускной способности с целью определения того, как часто клиентам филиалов офисов потребуется определять имена, не включенные в проект сети филиала. Обычно клиенты филиалов офисов определяют только локальные ресурсы, поэтому было бы более эффективно просто добавить устройство пересылки. Благодаря этому, отпадает необходимость в создании заполняющего трафика вторичных устройств, используя туннельное подключение. Очень важно уяснить в полном объеме потребности удаленных клиентов, а также иметь определенные соображения по поводу используемой пропускной способности для принятия решения относительно используемого проекта.
Резюме
Прежде чем начинать развертывание сетей филиалов офисов, потребуется уяснить требования, предъявляемые к системе безопасности. При этом необходимо принимать во внимание вопрос возможности предоставления клиентам филиалов офисов непосредственного доступа к Internet. Если ваша сеть является высоко защищенной, было бы неплохо передать весь трафик через туннельную среду, в результате чего центральная сеть сможет обрабатывать любой вид трафика, направленный в Internet. При подключении пользователя к Internet это уменьшает степень быстродействия, однако, приводит к увеличению степени безопасности.
Определив подключения VPN, забудьте об их существовании. Я предпочитаю использовать отдельные системы для управления отдельными ролями. Если подключение VPN автоматически открывается при необходимости, а фильтры и маршруты применяются корректно, контроллер домена и клиент никогда не смогут определить, что в данном случае используется туннель, а не выделенная линия связи.
12
Использование Active Directory в сетях VPN
Как только развитие технологии виртуальных частных сетей (VPN) достигло уровня, существующего в Windows 2000, вполне возможным стало появление распределенных, производственных и сетевых каналов связи, использующих сети VPN вместо выделенных линий связи. Это дает возможность весьма эффективного и недорогого развертывания контроллеров домена (DC — Domain Controller), реализующих связь с филиалами офисов с помощью одних каналов VPN.
В настоящей главе рассматриваются особенности сетей VPN, которые оказывают влияние на репликацию Active Directory (AD). О репликации AD более подробно рассказывается в книге Гэри Олсена Служба Active Directory: разработка и внедрение, выпущенной издательским домом "Вильяме" в 2001 году. В упомянутой книге проиллюстрирован весь процесс функционирования и репликации AD, а в данной главе особенности этого процесса рассматриваются лишь в связи с сетями VPN, поскольку здесь предполагается, что читатель знаком с моделью репликации AD.
В начале своей деятельности в составе группы сетевой поддержки Windows 2000 в компании Microsoft я принял решение, что для проверки всех возможностей данного программного продукта лучше всего развернуть крупную распределенную сеть, предназначенную для связи с филиалами компании, реализуемой с помощью каналов связи VPN, а не выделенных линий. Именно так и возникла сеть HappyVPN.
Как следует из предыдущих глав, среда VPN оказывается настолько гибкой, что позволяет проектировать практически любую сеть. Тем не менее, в процессе проектирования необходимо принять во внимание преимущества и недостатки каждого технического решения, учитывая особенности функционирования сетевой среды и корпоративные интересы данной организации.
Прежде чем обращаться к рассмотрению различных методов развертывания AD в среде VPN, выполним краткий обзор процесса репликации AD.
В Windows 2000 радикальным образом изменен способ организации и поддержки информации в доменах. Так, в Windows 2000 применяется модель репликации с несколькими мастер-доменамивместо присущего Windows NT 4 .0 подхода, который состоит в использовании единственного главного контроллера домена (PDC — Primary Domain Controller) и нескольких резервных контроллеров домена (BDC — Backup Domain Controller). Модель репликации с несколькими мастер-доменами, применяемая в Windows 2000, обладает рядом следующих преимуществ над моделью с одним мастер-доменом.
Улучшенная степень масштабируемости. Благодаря тому, что любой контроллер домена допускает изменения в любом месте сети, репликация не зависит от наличия единственного доступного компьютера (при условии наличия сетевой связи). Это
способствует сокращению нагрузки на один компьютер и обеспечению наращивания базы данных, не прибегая к ограниченным ресурсам единственного компьютера.
Сокращенный поток трафика. Если в Windows NT периодически передается большой объем данных, то в Windows 2000, в зависимости от установленного графика, посылаются небольшие фрагменты данных (атрибуты) — это так называемая репликация на уровне атрибутов Как показывает практика, такой способ позволяет сократить сетевой трафик, благодаря распределению нагрузки в течение большего периода времени и репликации лишь одного атрибута объемом в несколько байтов по сравнению с несколькими тысячами байтов данных соответствующего объекта.
Прогнозируемый трафик сообщений. В целях реализации сетевого планирования допускается прогнозирование трафика сообщений во время осуществления репликации.
Отказоустойчивость. Благодаря тому, что на каждом контроллере домена имеется копия разделов Schema (Схема), Configuration (Конфигурация) и Domain (Домен), при выходе из строя одного компьютера целостность баз данных на остальных компьютерах не нарушается. При последующем подключении отказавшего компьютера к сети происходит обновление содержащейся на нем базы данных,
Разрешение конфликтов. Благодаря надежности, достигнутой при реализации данной функции, гарантируется отсутствие в базе данных дублируемых объектов или атрибутов.
Репликация с промежуточным накоплением. Эта опция дает возможность контроллеру домена, в котором имеются изменения, передавать их ближайшим контроллерам домена, а те, в свою очередь, обеспечивают передачу изменений дальше. Такая возможность оказывается весьма полезной при проектировании технического решения, связанного с репликацией в тех сетях на основе VPN, в которых филиалам офисов могут быть доступны сетевые каналы связи с изменяющейся пропускной способностью.
В Windows 2000 невозможно обнаружить инфраструктуру сети средствами Active Directory, а следовательно, и те физические маршруты, по которым должна быть выполнена репликация. Эта особенность имеет весьма важное значение при рассмотрении AD в качестве распределенной среды, зависящей от передачи данных между контроллерами домена.
Репликация
Репликация AD представляет собой механизм, который может быть использован для обеспечения каждого контроллера домена обновленной копией Active Directory. Применение схемы репликации с несколькими мастер-доменами, когда в каждом контроллере домена имеется перезаписываемая копия AD, представляет собой определенные трудности не только для проектирования, но и для администрирования AD. Вопросы проектирования, возникающие в среде VPN, по существу те же, что и в полностью маршрутизированной традиционной среде ГВС- Для решения этих вопросов требуется правильное представление о следующих свойствах.
Средство контроля согласованности базы знаний (Knowledge Consistency Checker). Это основной элемент репликации AD.
Срочная репликация. События, которые непосредственно запускают процесс репликации, могут оказывать значительное влияние на сеть VPN.
Эффективность и репликация сетевого трафика. В Windows 2000 допускается довольно скрупулезный контроль трафика репликации, что имеет решающее значение для среды VPN, Ведь степень предсказуемости трафика репликации весьма высока.
Чтобы получить общее представление о наиболее важных особенностях Active Directory, необходимо практическое знание следующих вопросов; средство контроля согласованности базы знаний (КСС — Knowledge Consistency Checker), выполнение репликации вручную, срочная репликация Active Directory, а также эффективность и репликация сетевого трафика.
Средство контроля согласованности базы знаний
Средство КСС несет ответственность за формирование топологии репликации. Оно отвечает за реализацию следующих моментов.
Анализ топологии узлов сети, сконфигурированной в подключаемом модуле Sites and Services (Сетевые узлы и службы) и хранящейся в виде объектов АО- При этом создаются объекты подключения, допускающие репликацию между контроллерами домена.
Установка подключений между контроллерамидомена, на которых выполняется КСС, внутри узла сети. Как правило, КСС выполняется на всех контроллерах домена.
Установка подключений между контроллерами домена, на которых выполняется КСС, в разных узлах сети.
Определение контроллера домена для размещения генератора межузловой топологии сети (ISTG — Inter-Site Topology Generator), который осуществляет конфигурацию межузловой топологии сети, соединяющей мостовые серверы (BHS - Bridgehead Servers). При этом также обеспечивается преодоление последствий отказов, когда генератор ISTG оказывается недоступным,
Установка нового сервера BHS, если существующий сервер недоступен в течение заданного периода времени при условии, что этот BHS не сконфигурирован вручную в качестве наиболее предпочтительного.
Выполнение перечисленных выше задач через каждые 15 минут (по умолчанию).
Предостережение
Конфигурирование BHS в качестве наиболее предпо чти тельного приводит к отмене отказоустойчивой функции, присущей КСС. Это означает, что, если сервер BHS оказывается недоступным, новый сервер должен быть сконфигурирован вручную (как правило, для этого создается несколько наиболее предпочтительных BHS) При этом отменяется также отказоустойчивая функция, присущая ISTG.
Функции КСС играют решающую роль в процессе репликации. Однако, длительная проверка топологии сети может отрицательно сказаться на производительности контроллера домена.
Автоматически формируемые объекты подключения
Средство КСС автоматически формирует объекты подключения, которые имеют жизненно важное значение для процесса репликации. Если репликация прерывается, то это скорее всего происходит из-за отсутствия или бездействия объекта подключения, о чем свидетельствуют соответствующие сообщения, которые появляются в журнале событий службы каталогов. Поэтому для обеспечения работоспособности процесса репликации важно контролировать подобные объекты. Ниже перечислен ряд следующих важных аспектов, касающихся объектов подключения.
Объекты подключения имеют однонаправленный (односторонний) характер. Для организации двунаправленной связи необходимо установить два соединения.
Объекты ручного подключения никогда не удаляются с помощью КСС. Если КСС согласует наличие подключения в том месте, где существует ручное под-
ключение, автоматическое подключение в этом случае не создается. Однако, если КСС не находит целесообразным установку подключения, в этом случае остается ручное подключение.
Подобно любому другому объекту, объект подключения реплицируется в AD. Объекты подключения могут быть созданы с помощью подключаемого модуля AD Sites and Services или утилиты командной строки repadmin /add. Утилита repadminflocrynHa с ПОМОЩЬЮ инструментов поддержки (Support Tools), устанавливаемых с системного CD-ROM Server или Advanced Server.
Для запуска процесса репликации достаточно щелкнуть правой кнопкой мыши на объекте в консоли ММС Sites and Services и выбрать опцию Replicate Now (Реплицировать). В данном случае реализуется так называемая операция "вытягивания’ (Pull),
Операция "выталкивания (Push) доступна в области Server Options (Режимы работы сервера) диспетчера репликации (Replication Monitor). Пользоваться операцией "выталкивания" следует осторожно, поскольку она приводит к принудительному внесению изменений на всех доступных контроллерах домена.
Для приведения в действие процесса репликации между двумя контроллерами домена может быть также использована утилита командной строки repadmin /sync. И в этом случае выполняется операция ‘'вытягивания".
Диспетчер репликации
Диспетчер репликации (Replication Monitor) является важным инструментом, входящим в состав Windows 2000 Server и более поздних версий этой операционной системы. Он не устанавливается по умолчанию, поэтому для его установки следует перейти к каталогу поддержки на дистрибутивном CD-ROM. После установки инструментов поддержки (Support Tools) для обеспечения доступа к диспетчеру Replication Monitor достаточно выбрать пункты меню Start ^ Windows 2000 Support Tools I» Tools -* Active Directory Replication Monitor (Пуск ср Инструменты поддержки Windows 2000 ^ Инструментальные средства => Монитор репликации Active Directory).
Объекты ручного подключения
Иногда КСС создает объекты подключения для сложной сети с большим числом узлов отнюдь не оптимальным образом. Поэтому вполне возможны случаи, когда объекты подключения создаются вручную, если, например, требуется воспрепятствовать выполнению КСС своих функций, либо это необходимо сделать с целью поиска неисправностей. Потребность в создании объектов подключения вручную может возникнуть по одной из следующих причин.
Контроллердоменаневыполняетрепликацию(входящейилиисходящейин
формации). Такое может произойти по целому ряду причин. В частности, вследствие сбоев в системе именования доменов (DNS — Domain Name System) или из-за отсутствия связности узлов сети. Ручное соединение между сбойным и другим контроллером домена может быть установлено с целью осуществления процесса репликации, в то время как устраняется истинная причина сбоя.
Потребность в незамедлительном запуске процесса репликации может возникнуть при отсутствии подключения, сформированного с помощью КСС. Если изменения в одном контроллере домена должны неза медлительно распространиться на другой контроллер домена, но этому мешает объект подключения, сформированный посредством КСС, тогда ручное подключение между двумя контроллерами домена может быть установлено с помощью функции Replicate Now. Примером тому служит обноатение групповой политики, создание или видоизменение учетной записи, из-
меление свойств топологии узлов сети и другие ситуации, в которых не приходится ждать восстановления нормального режима репликации. Прибегать к подобному методу репликации нет нужды в том случае, если между контроллерами домена существует подключение, установленное с помощью объекта подключения, сформированного посредством КСС. Тогда для запуска процесса репликации ручное подключение не требуется. Описанный выше способ применяется только в тех случаях, когда соединение между контроллерами домена отсутствует.
Если требуется установить соединение с критически важным контроллером домена, в частности, с сервером глобального каталога или основным контроллером домена, то вместо того, чтобы решать эту задачу с помощью КСС, можно сформировать ручные подключения между теми или иными контроллерами домена, которые раньше не были соединены.
Приведение в действие процесса репликации вручную
При добавлении или удалении филиалов офисов во время конфигурирования сети VPN иногда бывает полезно принудить КСС к проверке топологии сети незамедлительно. Для этого следует получить доступ к подключаемому модулю Sites and Services, раскрыть окно, соответствующее пиктограмме Site (Узел сети), а затем раскрыть окно пиктограммы Server (Сервер). После этого нужно щелкнуть правой кнопкой мыши на пиктограмме NTDS Settings (Параметры настройки NTDS) и в контекстном меню выбрать элемент All Tasks - Check Replication Topology (Все задачи - Проверка топологии репликации). После этого КСС создаст новые объекты подключения и удалит старые, не ожидая повторения обычного цикла своего функциейирования. Несмотря на то, что этот процесс происходит в подключаемом модуле последовательно для каждого отдельного сервера, диспетчер Replication Monitor может осуществить принудительную синхронизацию всех серверов.
Срочная репликация Active Directory
Некоторые изменения, происходящие в контроллере домена и связанные с защитой, могут рассматриваться как срочные или чрезвычайно важные, чтобы ожидать их распространения по всей доступной сети. Теоретически, даже при внесении весьма важных изменений в систему безопасности, потенциальный риск ее нарушения остается до тех пор, пока не будет осуществлена репликация этих изменений. Процесс немедленной репликации всегда запускается при следующих видоизменениях.
Перемещение мастер-узла с дескриптором относительной идентификации (RID - Relative Identity) или хранителя ролей FSMO на другой компьютер. При этом новый компьютер присваивает дескрипторы RID всем контроллерам данного домена. В отсутствие такой возможности дескрипторы RID оказались бы недоступными при создании новой учетной записи.
Разрешение блокировки учетной записи или изменение стратегии блокировки учетной записи, в результате чего учетная запись блокируется после определенного числа повторных попыток.
Изменение секретной информации длялокальных полномочий защиты (LSA — Local Security Authority), в частности, изменение пароля в учетной записи компьютера.
Изменение стратегии назначения паролей для домена.
Репликация с одним мастер-доменом и VPN
По умолчанию срочная репликация доступна только внутри узла сети. В типичной развернутой сети VPN это, как правила, не оказывает влияния на трафик, поскольку узлы сети могут быть определены в разных местах. Для организации срочной репликации между узлами сети можно установить режим Change Notification (Изменение уведомления) (для подключения рассматриваемого узла сети) либо разместить все контроллеры домена в одном узле сети (что, как правило, невозможно).
При изменении пароля происходит обмен весьма важной информацией. При этом изменение пароля на локальном контроллере домена немедленно реплицируется с помощью вызовов удаленных процедур (RPC) на контроллер домена, выполняющего роль эмулятора единственного мастер-домена гибких операций(Р8МО — Flexible Single Master of Operations) на главном контроллере домена (PDC Emulator). Это происходит немедленно, даже если PDC не находится в том же узле сети, что и контроллер домена, инициирующий обмен данными. После этого изменения распространяются путем обычной репликации на другой контроллер домена. Когда пользователь регистрируется в системе с новым паролем и его аутентификация осуществляется контроллером домена, до которого упомянутые выше изменения еще не дошли, пароль оказывается недействительным. Вместо отказа в запросе на регистрацию этот контроллер домена связывается с эмулятором PDC Emulator, чтобы проанализировать изменения, о которых ему еше неизвестно. После анализа произведенных изменений он подтверждает запрос.
Вопрос изменения пароля имеет весьма важное значение, особенно если принять во внимание способ, посредством которого в сети на основе VPN поддерживается связь между узлами. Если граничный сервер ограничивает туннель, пользователь не сможет зарегистрироваться до тех пор, пока график туннельного сервера не разрешит ему соединиться. Если же, напротив, трафик репликации планируется, исходя из конфигурации AD, изменение пароля все еще допускает инициирование и проверку достоверности имени пользователя в туннеле.
Как и в большинстве вариантов развертывания сетей на основе VPN, важное значение приобретает корректное использование пропускной способности. При этом весьма важно спроектировать эффективное распределение трафика между узлами сети. На трафик репликации оказывают влияние следующие факторы,
Сжатие данных осуществляется во время процесса репликации между узлами, но не внутри узла сети, причем данные объемом менее 50 Кбайт вообще не сжимаются.
Сжатие данных приводит к сокращению трафика приблизительно на 10% относительно его исходной величины. Как упоминалось выше, одним из возможных вариантов организации срочной репликации является создание всех контроллеров домена на одном и том же узле сети. Это имеет весьма серьезные последствия для сетевого трафика, особенно при наличии значительных изменений. Трафик регистрации, результаты поиска с использованием облегченного протокола службы каталогов (LDAP — Lightweight Directory Access Protocol) и прочие данные передаются без сжатия.
В Windows 2000 допускается весьма плотно планируемая репликация, что дает администратору возможность полного контроля над тем, когда и как часто выполняется репликация.
Самый интенсивный трафик возникает при следующих условиях.
Во время запуска компьютера и регистрации клиента.
Во время репликации серверов глобального каталога.
Во время выполнения DCPromo.
Вкрупных базах данных AD с несколькими разделами.
Оптимизация
Наиболее узким местом практически любых сетевых технических решений, с которым приходится бороться администраторам сетей, является ограниченная пропускная способность. Когда развертывание Active Directory осуществляется на основании каналов связи VPN, вопрос ограничения пропускной способности становится еще более острым. Для разрешения подобных затруднений при развертывании сети HappyVPN мне пришлось попросить многих специалистов в области Active Directory определить те настройки, которые администратор может выполнить для оптимизации системы в отношении сетевого трафика, связанного с AD.
Стандартная установка Active Directory по замыслу компании Microsoft предназначена для использования в большинстве сетевых технических решений. Тем не менее, в попытке сократить сетевой трафик и тем самым оказать влияние на функциональные возможности данного программного продукта можно воспользоваться следующими настройками.
AD Replication (Репликация активного каталога). Сроки исполнения и конфигурация узла сети, в том числе определение наименее затратных вариантов репликации между узлами сети с более скоростными подключениями.
Bidirectional Replication (Двунаправленная репликация). Это дает возможность одной стороне запускать операции ■вытягивания и "выталкивания" во время передачи данных AD контроллерами домена.
Browsing (Просмотр). Управление списком просмотра NetBIOS.
Certificate Server (Сервер сертификатов). Определение срока действия сертификата и обновление CRL.
DNS Transfer (Передача данных с сервера доменных имен). Настройка передачи информации о зонах таким образом, чтобы она происходила по определенному графику, если зоны не интегрированы в AD. В противном случае эта настройка может быть выполнена в виде части процесса настройки репликации всего каталога.
File Replication Service (FRS) Immediate (Немедленный ввод в действие службы репликации файлов). Запуск немедленной репликации файлов. Если в данной среде имеется целый ряд файлов, передаваемых указанной службой, тогда весьма важно спланировать моменты времени, когда это должно произойти.
FSMO Role Holders (Хранители ролей FSMO). Настройка логического размеше- ния и количества хранителей ролей. При этом наиболее важные хранители ролей FSMO должны непременно располагаться в легкодоступных сетях.
ксс Runtime (Рабочий цикл КСС). Конфигурация сетевых узлов и служб (Sites and Services) должна непременно допускать формирование связей между узлами сети посредством КСС логичным и эффективным образом.
Kerberos (Система защиты с шифрованием "Цербер"). Если трафик билетов Kerberos перемещается по дереву при наличии разветвленной иерархической структуры домена, тогда для ускорения этого процесса, возможно, имеет смысл настроить сокращенные доверительные отношения вручную для непосредственного перехода к общему домену.
License Server Replication (Репликация сервера лицензирования). Установка периодичности репликации сервера лицензирования. При этом сервер лицензирования должен быть сконфигурирован таким образом, чтобы его репликация осуществлялось не чаще, чем это предусмотрено в настройках, определенных по умолчанию.
Machine Account Password (Пароль для учетной записи компьютера). Указание периодичности автоматического обновления пароля компьютера.
Policy Refresh Time (Время обновления политики). Управление периодичностью репликации групповой политики.
User Password Changes (Изменение пользовательского пароля). Указание периодичности подобных изменений в соответствии с выбранной стратегией. Как упоминалось выше, это может привести к формированию значительного по величине трафика. Данное обстоятельство следует учитывать при определении периодичности изменения пользователями своих паролей.
Сонет
Сотрудник компании Microsoft Андре ас Лютер (Andreas Luther) провел, вероятно, наиболее обширное исследование в области трафика репликации. Он опубликовал получен - ные данные в книге “Практические заметки к созданию служб активного каталога масштаба предприятия" (Building Enterprise Active Directory Services: Notes from the Field), которая выпущена издательством Microsoft Press и, в частности, снабжена электронными таблицами для расчета трафика репликации.
Проект узла сети
Проект узла сети определяет, насколько успешной или, наоборот, неудачной может оказаться репликация. Что касается развертывания AD на основе инфраструктуры VPN, то в данном случае этот аспект проектирования сети может иметь не столь важное значение.
Компания Microsoft разработала для администратора AD способ конфигурирования вручную топологии узла сети, используя подключаемый модуль Active Directory Sites and Services. При этом необходимо определить маршруты, а также затраты на их использование для эффективной репликации. Используя топологическую схему узла, можно создать интерфейс между AD и физической сетью. Это фактически оказывает влияние не на инфраструктуру сети, а на то, как существующая инфраструктура используется.
Возможность проектирования логической топологии узла сети обеспечивает ряд существенных преимуществ, хотя это и может оказаться довольно опасным делом, ибо ничто не может воспрепятствовать созданию администратором неверной топологии. Поэтому администратор, несуший ответственность за поддержание правильной конфигурации сетевых узлов и служб (которая должна быть достаточно статической), должен иметь полное представление о конкретной сети. При изменении сети должен выполняться процесс, предупреждающий об этом лицо, ответственное за управление узлом сети. В противном случае процесс репликации может быть нарушен.
Проект узла сети для VPN
Распространенный подход к развертыванию сетей VPN состоит в определении различных мест в качестве отдельных узлов сети. Такой подход вполне приемлем до тех пор, пока количество отдельных узлов сети не возрастет до 300. После этого для определения структуры соединения инструментальному средству КСС потребуется столько времени и ресурсов, что в итоге контроллеры домена могут прекратить нормальное функционирование. В последующих выпусках и служебных пакетах рассматриваемого программного продукта это положение, безусловно, будет исправлено, Однако, в настоящее время можно избежать указанного затруднения, если проект узла сети допускает практическое применение обходных путей.
Совет
Практическое ограничение количества узлов сети имеет весьма важное значение. Если конкретная топология включает более 250-300 узлов сети, необходимо принимать во внимание последствия такого решения, поскольку конфигурирование слишком большого числа узлов сети (вместе с контроллерами домена) может привести к значительному ухудшению производительности контроллеров домена, а также нарушению процесса репликации. Некоторые обходные пути выхода из данного положения рассмотрены в статьях Q244368 и Q242780, содержащихся в базе знаний компании Microsoft. В этих статьях описан ряд простых способов устранения подобного затруднения, в том числе и отключение КСС Однако, такое решение представляется весьма радикальным.
В упомянутой выше книге Гэри Олсена описан ряд подходов к решению данной проблемы, благодаря основательному планированию процесса проектирования. К таким подходам относится использование ‘ суперузлов сети" ("Super Sites"), а также отмена автоматически формируем ыхмостов, связывающих узлы сети (Site Link Bridges), и создание их вручную ради сокращения времени, которое требуется КСС для формирования топологии.
Топология узла сети
Топология узла сети выполняет функции интерфейса между физической сетью и структурой домена. Она точно моделирует физическую сеть и образует структуру репликации домена или его схему, а также контексты именования конфигурации из структуры домена.
Всякий раз, когда по какой-либо причине выполняется поиск контроллера домена, прежде всего предпринимается попытка найти в узле сети компьютер, который удовлетворяет данному запросу. В качестве источника запросов может служить DCPromo, обычная репликация AD, поиск AD, запрос сервера DFS или даже запрос пользователя на регистрацию. Следовательно, схема и конфигурация узла сети имеют весьма важное значение для обеспечения оптимального поиска сервера, способного удовлетворить данный запрос и эффективно решить поставленную задачу.
Взаимосвязь структуры домена (доменов, пользователей, компьютеров, системы безопасности и прочего), топологи узла сети и физической сети показана на рис. 12.1, Топология узла сети и физическая сеть называются также логической и физической моделями соответственно. Топология узла, которая, по существу, служит в качестве интерфейса между AD и физической сетью, должна определяться разработчиком системной архитектуры и впоследствии поддерживаться администратором сети масштаба предприятия. Эффективность репликации зависит от того, насколько точно разработчик системной архитектуры создаст логическую модель физической сети. Если она окажется неточной, репликация будет выполняться несогласованно, Q чем будут свидетельствовать сообщения об ошибках в журнале событий.
Структура домена
Рис. 12.1. Уровни репликации Active Directory
Следовательно, при создании топологии узла сети весьма существенно иметь правильное представление о физической сети, включая следующие аспекты:
маршрутизируемые и немаршрутизируемые сегменты сети;
удаленные подключения;
скорости передачи данных по линии в каждом канале связи ГВС и используемая пропускная способность;
любые особые ограничения на сетевой трафик (например, если приложение находится на конкретном узле сети, то трафик репликации, возможно, потребуется ограничить в данном узле сети определенными часами работы).
Компоненты топологии узлов
Создание топологии узла сети предполагает довольно близкое знакомство с ее компонентами, описанными в последующих разделах. Наиболее важные вопросы, касающиеся каждого компонента, заслуживают дополнительного исследования.
Узлы
Узел сети представляет собой совокупность одной или более подсетей и, как правило, определяется географическим местом расположения, в частности, городом, комплексом зданий или даже отдельным зданием. Соединение подсетей внутри узла сети должно быть "качественным" (т.е. реализующим скорость передачи данных 10 Мбит/с или более). При типичном развертывании сети на основе VPN указанные выше подсети соединяются туннелем. Кроме того, они могут быть связаны с помо- шью любого другого вида физического сетевого соединения.
Серверный объект
Серверный объект создается во время выполнения DCPromo, т.е. в процессе формирования контроллера домена и установки AD. Серверные объекты отличаются от компьютерных объектов, поскольку в их основу положены принципы организации защиты. Компьютер, который выполняет функции контроллера домена, содержит серверный объект в контейнере конфигурации, находящемся ниже узлов сети (Sites). Кроме того, он содержит компьютерный объект, который находится в контейнере домена (как правило, в организационной единице (OU) контейнера домена) Несмотря на то, что оба указанных выше объекта существуют раздельно, связь между ними устанавливается с помощью объекта NTDS Settings.
Глобально уникальный идентификатор сервера
При создании контроллера домена с помощью DCPromo запись DNS с его каноническим именем (cname) регистрируется ниже подзоны .msdcs в корневой зоне DNS. С помощью этой записи глобально уникальный идентификатор (GUID) сервера преобразуется в его IP-адрес. Все записи cname, относящиеся ко всем контроллерам домена, находятся только в корневой зоне. Во время репликации подобная запись используется в каждой транзакции. В связи с этим для успешного выполнения процесса репликации приходится устанавливать связь с сервером DNS, расположенным в корневой зоне, для получения доступа к данной записи. Следовательно, возможность установления связи и доступность серверов DNS корневой зоны имеет решающее значение для успешного выполнения процесса репликации.
Объект NTDS Settings
Этот объект реализует связь между серверным и компьютерным объектами контроллера домена, а отдельный атрибут данного объекта определяет контроллер домена в качестве сервера глобального каталога (Global Catalog Server). Кроме того, с помощью объекта устанавливается 15-минутный интервал репликации для объектов внутри узла сети. Подобный объект представляет активный каталог (Active Directory) на сервере. Если активный каталог удален (или его ранг понижен), соответствующий объект NTDS Settings удаляется из активного каталога, а серверный объект остается.
Подключения
Подключения представляют собой СВЯЗИ, создаваемые автоматически посредством КСС либо вручную администратором AD. График подключения (Connection Schedule) определяется в области свойств объекта подключения (Connection Object) подключаемого модуля Sites and Services. По умолчанию периодичность репликации внутри узла сети устанавливается через каждые 15 минут. Каждое подключение наследует этот устанавливаемый по умолчанию график от объекта NTDS Settings, когда оно устанавливается посредством КСС. При изменении графика в автоматически установленном соединении КСС удалит и установит это подключение повторно. Это приведет к потере определенного ранее графика и возврату к используемому по умолчанию графику с 15-минутным интервалом репликации. При попытке изменить график в автоматически сформированном объекте появится предупреждение, в котором запрашивается необходимость превратить объект в единицу, созданную вручную.
Подсети
В данном контексте под термином ‘"подсети на самом деле подразумевается процесс преобразования подсетей в узлы сети. Несмотря на то, что это лишь дополнительная возможность, приводящая к формированию предупреждений в журнале событий, в результате неправильного преобразования подсетей в узел сети получается неэффективная топология репликации и столь же неэффективный поиск контроллеров домена по Netlogon. При развертывании сетей VPN решающее значение имеет правильное определение подсетей в конфигурации сетевых узлов и служб (Sites and Services). Если же они определены неправильно, это приводит к неэффективному использованию пропускной способности, а значит, и к существенным задержкам для пользователей и различных служб.
Связи узлов сети
Связи узлов сети создаются вручную для соединения двух или более узлов. Они содержат информацию о планировании, затратах и периодичности репликации и могут быть настроены на использование транспортного протокола TCP/IP или SMTP. Связи узлов сети определяют все соединения между этими узлами. Кроме того, связи узлов сети, созданные вручную, особенно пригодны для сетей VPN, благодаря тому уровню гибкости сети, который могут обеспечить логические, а не физические связи. В частности, для повышения эффективности использования маршрутов репликации имеется возможность определить ряд маршрутов, по которым может быть выполнена репликация на различные узлы сети.
Затраты на связи узлов сети
Подобные затраты представляют собой произвольную величину, устанавливаемую для связи узла сети. Она используется в КСС для определения первоначального маршрута репликации при наличии нескольких маршрутов между контроллерами домена. Именно здесь вступает в действие принцип моделирования физической сети. При
этом разработчик сетевой архитектуры должен обратить внимание на физическую сеть, а также на скорость (и надежность) передачи данных по линии между узлами сети Windows 2000. Дешевле всего обходятся наиболее скоростные и надежные физические линии связи.
График использования связей узла сети
На основании графика использования связей узла сети администратор может установить периодичность, а также отключение и включение режима репликации в определенное время дня для выполнения процесса репликации между узлами сети. Периодическая репликация приостанавливается, когда режим репликации отключается по графику использования связей узла сети, а затем возобновляется по тому же графику.
Развертывание AD
Чтобы определить способ развертывания контроллеров домена в филиалах офисов, необходимо исследовать четыре основных варианта репликации. Каждый из этих вариантов будет подробно рассмотрен в последующих разделах. Итак, имеются следующие четыре сценария репликации:
преобразование IP-адресов;
преобразование IP-портов бра ндмаузра/N АТ-сервера для Active Directory;
репликация по протоколу SMTP;
связывание узлов сети с VPN.
Во всех сетевых технических решениях Internet служит в качестве сети, которая соединяет основной сетевой узел и филиалы офисов, причем для этого может быть использована любая сеть. В филиалах офисов применяются частные сети, отделяемые друг от друга сервером трансляции сетевого адреса (NAT— Network Address Translation).
Как и во всем, что касается VPN, в данном случае имеется множество возможностей направить в нужное русло разработку сетевой инфраструктуры. Эти возможности можно разделить на две основные категории: преобразование сетевых ресурсов и применение встроенных технологий репликации.
Преобразование IP-адресов
В таком варианте сетевого технического решения на брандмауэре/NAT-cepBepe филиала внешний IP-адрес преобразуется во внутрисистемный адрес контроллера домена. При этом любой трафик, направляемый по преобразованному таким образом адресу, передается непосредственно контроллеру домена (рис. 12.2).
ФилиалПреобразование IP-адресов
Преобразование IP-адресов
Рис. 12.2. Преобразование IP-адресов для брандмауэра/сервера NA Т внутреннего контроллера домена
К преимуществам данного варианта сетевого технического решения относятся следующие:
на техническом уровне такое решение оказывается вполне пригодным, поскольку после преобразования адреса весь трафик репликации направляется контроллеру домена;
в связи с тем, что связьосуществляется по преобразованному адресу, тотфакт, что сервер NAT вообще не передает трафик LDAP, особых затруднений не вызывает.
К недостаткам данного варианта сетевого технического решения относятся следующие:
такое техническое решение требует наличия второгодействительного IP-адреса;
преобразованный IP-адрес де7лает контроллер домена незащищенным со стороны внешней сети (это все равно, что сделать его незащищенным со стороны Internet);
в связи с тем, что IP-адрес, используемый для контроллеров домена, должен быть настоящим (преобразованным) адресом, возникает затруднение с регистрацией в DNS частного адреса (это затруднение можно обойти, для чего придется отключить процесс автоматической регистрации в динамической системе именования доменов (DDNS)).
Преобразование IP-портов брандмауэра/NAT-сервера для Active Directory
Для эффективного функционирования служб Active Directory в Windows 2000 требуется ряд портов. В частности, для выполнения различных функций службы Windows 2000 NAT (как и большинства других служб NAT) допускается преобразование портов с учетом использования внутренних ресурсов (табл. 12.1). Это дает трафику возможность проходить через назначенные порты NAT-сервера. Соответствующий пример приведен на рис. 12.3.
Рис. 12.3. Преобразование 1Р-портов для брандмауэра/сервера NA Т во внутренний контроллер домена
Таблица
12.1. Порты Windows 2000 Active Directory
Порт
Протокол
Функция
42
TCP
Репликация WINS
53
UDP
Определение имени DNS
53
TCP
DNS
67
UDP
Аренда для протокола DHCP (ВООТР)
68
UDP
Аренда для протокола DHCP
88
UDP
Протокол Kerberos
Окончание табл. 12.1
Порт
Протокол
Функция
135
TCP
Служба размещения, RPC, преобразователь RPC ЕР, диспетчер WINS, диспетчер DHCP
137
UDP
Служба преобразования имен NetBIOS, последовательность регистрации, доверительные отношения в NT 4.0, защищенный канал NT 4.0, опосредованная проверка, просмотр, печать
137
TCP
Регистрация в WINS
138
UDP
Служба дейтаграмм NetBIOS, последовательность регистрации, доверительные отношения в NT 4.0, репликация каталогов в NT 4.0, защищенный канал NT 4.0, опосредованная проверка, регистрация в сети NetLogon, просмотр, печать
139
TCP
Сеансовая служба NetBIOS, NBT, SMB, совместное использование файлов, печать, последовательность регистрации, доверительные отношения в NT 4.0, репликация каталогов в NT 4.0, защищенный канал NT 4.0, опосредованная проверка, инструменты администрирования в NT 4.0
389
UDP
Протокол LDAP
636
UDP
Протокол LDAP
750
UDP
Аутентификация Kerberos
750
TCP
Аутентификация Kerberos
751
UDP
Аутентификация Kerberos
751
TCP
Аутентификация Kerberos
752
UDP
Сервер паролей Kerberos
753
UDP
Сервер регистрации пользователей Kerberos
754
TCP
Подчиненный режим распространения в Kerberos
888
TCP
Среда регистрации и передачи
1025
TCP
Репликация каталогов
1109
TCP
Протокол POP, используемый совместно с Kerberos
2053
TCP
Демультиплексор Kerberos
2105
TCP
Зашифрованная с помощью Kerberos регистрация в системе, Гlogin
3268
Глобальный каталог
3269
Глобальный каталог
К преимуществам данного варианта сетевого технического решения относятся следующие:
на техническом уровне такое решение оказывается вполне пригодным (при этом после преобразования всех адресов трафик репликации направляется контроллеру домена);
в данном случае потребуется только один IP-адрес;
в связи с тем, что IP-адрес не подлежит преобразованию, некоторые службы оказываются защищенными от непосредственного воздействия из внешней сети.
К недостаткам данного варианта сетевого технического решения относятся следующие:
многие порты, играющие весьма важную роль, отображаются непосредственно во внутренний контроллер домена и делают наиболее важные службы незащи- шенными от атаки, предпринятой с целью нарушения системы безопасности;
трафикрепликации направляется в динамически изменяющийся порт, доступ к которому должен быть ограничен, благодаря изменению системного реестра на всех контроллерах домена, подключенных к сети с преобразованным портом;
при установке любых приложений, имеющих отношение к AD, в частности, Exchange 2000, необходимо обеспечить адресацию всех портов для правильного их преобразования;
настройка таких портов представляет собой сложную задачу, отнимающую немало времени (добавление фильтров для граничного сервера еще более усложняет задачу);
в связи с тем, что IP-адрес, фактически используемый для контроллеров домена, должен быть настоящим (преобразованным) адресом, возникает затруднение с регистрацией в DNS частного адреса (это затруднение можно обойти, для чего придется отключить процесс автоматической регистрации в DDNS).
Репликация с применением протокола SMTP
Когда появились первые сведения о простом протоколе электронной почты (SMTP— Simple Mail Transfer Protocol), перспективы его применения вызвали повсеместно большой энтузиазм. Протокол SMTP дает возможность осуществить связь между сетью и сервером при отсутствии прямой связи посредством агентов ретрансляции SMTP. Именно таким образом и работает большинство почтовых систем (рис. 12.4).
Рис. 12.4. Применение репликации по протоколу SMTP для репликации AD
К преимуществам применения репликации по протоколу SMTP относятся следующие:
использование агента ретрансляции SMTP, благодаря которому контроллер домена защищен от непосредственных атак с целью нарушения защиты из внешней сети;
в данном случае требуется только один внешний IP-адрес;
протоколSMTPдаетмногиморганизациямвозможностьиспользоватьужесу
ществующую инфраструктуру SMTP.
К недостаткам применения репликации по протоколу SMTP относят следующие:
репликации по протоколу SMTP подлежат только данные домена и инфраструктуры;
в связи с тем, что во всех инструментах (в частности, в подключаемых модулях управления AD) используются вызовы RPC, эти инструменты нельзя использовать наравне с протоколом SMTP;
для SMTP требуется отдельный домен;
одновременная репликация доменной информации по протоколам TCP/IP и SMTP не допускается, поэтому осуществить передачу данных по протоколу SMTP в одном направлении, а по протоколу IP — в другом весьма затруднительно.
Примечание
При проведении испытаний нами была обнаружено, что применение протокола SMTP связано с большими трудностями, поэтому пользоваться им вообще не рекомендуется. Мне представляется, что любые насущные потребности можно удовлетворить, благодаря модернизации сети с целью применения другой технологии. Испытания протокола SMTP в компании Microsoft проводились, в основном, на двух контроллерах домена в одной и той же сети. Несмотря на полезность таких испытаний, они не охватывают большую часть практических реализаций протокола SMTP. Ведь если два контроллера домена могут взаимодействовать в одной и той же сети, то зачем вообще применять протокол SMTP?
Связывание узлов сети с VPN
В данном варианте сетевого технического решения два узла сети с независимым подключением к Internet соединены с сетью VPN. При этом канал связи VPN должен представлять собой двунаправленное инициируемое подключение с тем, чтобы трафик мог проходить по сети в обоих направлениях, как показано на рис. 12.5. Следует заметить, что компания Microsoft рекомендует именно такой вариант, причем он подробно рассматривается в ряде статей, доступных в Technet.
Реализация IP-сети с помощью каналов VPN
Реализация IP-сети с помощью каналов VPN
Рис. 12.5. Применение канала связи УРН для связывания двух узлов сети
К преимуществам связывания узлов сети с VPN относятся следующие:
все контроллеры домена защищены от непосредственного воздействия из Internet;
трафик, проходящий по Internet, подлежит шифрованию, благодаря применению туннельной технологии;
в связи с тем, что для соединения, как правило, используются частные сети, услуги службы NAT для осуществления связи не нужны (тем не менее, служба NAT может быть использована для поддержки клиентов в обоих узлах сети в отношении трафика Internet, но не осуществления связи с другим узлом);
благодаря тому, что для среды AD поддерживается частная сеть, в данном случае вполне достаточно стандартных возможностей DDNS;
контроллеры домена не будут вообще ничего знать о том, что трафик направляется по туннелю, поскольку настройка туннеля возлагается на граничные серверы;
если во внешних интерфейсах граничных серверов используется клиент DDNS, то в этом случае статические внешние IP-адреса не нужны (если при этом не применяется туннельный режим IPSec).
К недостаткам связывания узлов сети с VPN относятся следующие:
сервер должен обеспечивать поддержку туннеля в узлах сети;
в данном случае весьма важное значение приобретает разработка подсетей (несмотря на то, что во всех узлах сети могут быть использованы подсети частной сети, каждая такая подсеть требует соответствующего согласования и поддержки для обеспечения эффективной маршрутизации).
Выводы
Проверка упомянутых выше основных и других вариантов сетевых технических решений с очевидностью показала, что наиболее пригодным из них является сеть на основе VPN. После определения логических связей и выбора маршрутов такие сети оказались достаточно независимыми.
Итак, придя к подобным выводам, я разработал сеть HappyVPN, которая допускала подключение какого угодно числа филиалов офисов. Как уже не раз упоминалось, прежде, чем приступать к решению вопросов более высокого порядка, очень важно создать работоспособную сетевую инфраструктуру.
Модель сети HappyVPN
На протяжении всей эволюции проекта HappyVPN мы опробовали целый ряд технических решений, которые нам казались вполне работоспособными, однако, на практике это не подтвердилось.
Труднее всего было установить связь между узлами сети во время выбора маршрута и определения имен DNS, Первоначально мы попытались обозначить конечную точку туннеля в качестве DNS для филиала, однако, это оказалось проблематичным. Кроме того, маршрутную среду следовало разработать таким образом, чтобы внутренний активный каталог (Active Directory) оказался совершенно независимым от способа его соединения с другими подсетями. Такой подход существенно упрощает сетевое техническое решение.
Многие варианты технических решений для филиалов офисов рассматриваются в главе 10.
В каждом узле пробного варианта сети HappyVPN для филиала офиса поддерживается сеть О.О.Х.О класса С, а в центральном узле — четыре отдельных подсети класса С. Следует заметить, что каждая такая подсеть должна быть согласована и не может быть одной и той же подсетью. В каждом туннельном сервере используется статический пул адресов, определенных в диапазоне 10.99.Х.0. Это было всего лишь техническое решение, а не требование к сети. Как обнаружилось, для существенного упрощения настройки маршрутизации туннельные связи должны иметь адреса из подсетей, отличных от тех, что используются в филиале офиса. В итоге среда туннельных адресов становится известной только на концах туннеля, а клиенту или серверу в каждом внутреннем узле сети эти адреса окажутся вообще неизвестны, и поэтому этот клиент или сервер будут просто пропускать любой внешний трафик на используемый по умолчанию шлюз. Соответствующий пример приведен на рис. 12.6.
Следует отметить, что каждая туннельная связь представляет собой двунаправленную инициируемую связь. Было бы практически нецелесообразным проектировать
сеть, которая не могла бы поддерживать трафик, проходящий в обоих направлениях, для инициализации туннеля. Если в конкретной среде приходится уделять особое внимание величине трафика или тому, сколько раз устанавливаются связи, туннельный сервер может быть сконфигурирован таким образом, чтобы допускать соединения только по определенному графику.
Рис. 12.6. Инфраструктура подсети Happy VPN, расположенной между
четырьмя узлами сети
При развертывании сети HappyVPN мне показалось весьма важным попытаться сконфигурировать все наиболее распространенные технические реализации Active Directory в филиалах офисов. Их можно разделить на следующие три категории.
В филиале отсутствуют локальные контроллеры домена, однако, ресурсы обеспечиваются с помощью локального файлового сервера, который выполняет также функции сервера определения имен. Все ресурсы (как клиентов, так и файлового сервера) ОТНОСЯТСЯ к центральному домену.
В филиале имеется одноранговый контроллер домена (аналогичный домену, размешенному в центральной штаб-квартире компании), определенный в отдельном узле сети. Этот контроллер выполняет также функции DNS и глобального каталога.
В филиале имеется дочерний домен, определенный в отдельном узле сети. Контроллер этого домена выполняет также функции DNS и глобального каталога.
Одним из наиболее важных аспектов конфигурирования Active Directory является определение подсетей в конкретном домене. Это дает возможность настраивать сервер в одном узле сети (в частности, в центральном узле). Благодаря высокой степени связности такого узла, его можно затем целиком переместить в сеть филиала офиса. Если подсети определены правильно. то при изменении IP-адреса нового сервера последний должен быть размещен в подходящем для него узле сети.
Для крупной и территор и ал ьно-рас п ределенн ой организации, в каждом филиале которой требуется отдельный контроллер домена, вполне возможно превышение максимального числа в 300 узлов сети, с которым может практически справиться ксс. В этой
области ведутся многочисленные исследования, в результате которых появляются новые стратегии развертывания структур узлов сети, позволяющие преодолеть указанное ограничение с помощью принципов многоуровневой архитектуры. Эти стратегии подробнее рассматриваются в упоминавшейся выше книге Гэри Олсена. Если в конкретной организации необходимо определить значительное число узлов сети, этот вопрос, безусловно, потребует дополнительного исследования. Следует отметить, что вопрос использования сетей VPN решается независимо от ограничений, присущих Active Directory.
Резюме
В настоящее время Windows 2000 можно сконфигурировать с учетом создания сетевой среды, основанной исключительно на технологии VPN. Этот факт был подтвержден на практике развертыванием сети HappyVPN и другими сетевыми проектами. При этом важное значение приобретает логическое развертывание AD с соответ- ствуюшей конфигурацией узлов сети, правильная настройка системы определения имен, оптимизация Пропускной способности разворачиваемой сети. Для эффективного конфигурирования сетевой среды могут потребоваться дополнительные исследования и некоторые практические усилия, однако, по завершении проектирования сеть оказывается достаточно независимой. Возможность проектирования таких сетей позволила полностью изменить наши представления о распределенной сетевой среде.
История и предмет виртуальных частных сетей
Широко известная сегодня сеть Internet начинала свою историю с проекта, финансируемого правительством Соединенных Штатов. Проект возник в 1962 году, когда командование военно-воздушных сил США (USAF) сформулировало задание компании RAND Corporation (www.rand.org) на предмет разработки методов, позволяющих сохранить контроль и управление над вооружением и бомбардировщиками в случае попытки ядерного нападения.на США.
В ответ компания RAND Corporation предоставила документ, созданный Полем Бэ- раном (Paul Вагап), который описывал несколько способов. с помощью которых ВВС США могли бы "выжить" в случае ядерной атаки. Заключительный вывод документа предусматривал создание распределенной сети, которая охватывала бы всю территорию США. Разработанная сеть носила децентрализованный характер, в результате чего в случае атаки любого из узлов (городов) сеть могла бы продолжать функционировать.
Документ предусматривал создание распределенной сети, использующей переключаемые пакеты. В ходе переключения пакетов происходит разбиение данных на дейтаграммы (пакеты), которые помечаются с целью обозначения источника и пункта назначения доставляемой информации. При осуществлении переключения пакетов маршрутизаторы направляют пакеты с одного компьютера на другой до тех пор, пока информация не достигает целевого компьютера. Этот подход довольно сильно отличался от подхода, применяемого в локальных вычислительных сетях того времени. В результате применения этого подхода клиент оставался в неведении относительно подробностей доставки пакета в целевое местоположение. Конечным результатом явилось создание отказоустойчивой сети, на функционирование которой не оказывает влияние изменение маршрута.
Ранние годы
В 1968 году Агентство по поддержке передовых исследовательских проектов (ARFA — Advanced Research Project Agency) заключило контракт с компанией BBN на создание частной сети, функционирование которой основывалось на результатах, изложенных в документе Поля Бэрана. В качестве механизма переключения для каждого узла компьютерной сети компания BBN выбрала миникомпьютер Honeywell.
Первоначальная сеть состояла из четырех узлов.
Калифорнийский университет в Лос-Анджелесе.
Стэндфордский исследовательский институт (SR1) в Стэнфорде.
Калифорнийский университет, Санта Барбара.
Университет штата Юта.
Эти узлы были объединены с ПОМОЩЬЮ выделенных линий связи, обеспечивающих скорость передачи данных до 56 Кбит/с, а сама сеть получила название ARPANET. На протяжении следующих лет происходило подключение к сети все новых и новых узлов, включая первые международные узлы, подключенные в 1973 году. В 1983 году протокол управления передачей/межсетевой протокол (TCP/IP -- Transport Control Protocol/lntemet Protocol) стал основным протоколом ARPANET, придя на смену протоколу управления сетью (NCP — Network Control Protocol). Протокол TCP/IP обеспечивает возможность взаимной связи для различных компьютерных систем. В эти же годы была разработана система именования доменов (DNS — Domain Name System), Благодаря системе DNS, появилась возможность вместо цифровой записи воспользоваться привычными именами, сформулированными на чистейшем английском языке.
В 1994 году сеть ARPANET разделилась на две отдельных сети. Одна из вновь созданных сетей, MILNET, стала использоваться исключительно в военных целях. Вторая сеть сохранила имя своего родителя, ARPANET, и была предназначена для продолжения передовых исследований.
В 1984 году компьютерная и научная сеть (CSNET — Computer and Science Network), созданная Национальным научным фондом (NSF — National Science Foundation) еще в 1981 году, была модернизирована, в результате чего скорость передачи данных возросла с 56 Кбит/с до 1,5 Мбит/с (характеристики линии типа. Т1). Эта новая сеть получила название NSFNET. В 1990 году оригинальная сеть ARPANET "ушла в отставку", а на смену ей пришла сеть NSFNET.
Провайдеры услуг Internet
В 1995 году компания NSF заявила о том, что прямые подключения к сети NSFNET будут запрещены. В этом же году компания заключила договор с MCI, Sprint, BBN, и ANS о предоставлении доступа в NSFNET. Эти четыре компании получили возможность продавать права доступа к сети NSFNET, используя свои частные сети; таким образом, они стали первыми провайдерами услуг Internet. В то время, когда сеть NSFNET использовалась исключительно в учебных и исследовательских целях, появился коммерческий Internet. В настоящее время множество компаний работают над описанием технологии, обеспечиваюшей распространенные сетевые услуги.
В 1982 году термин "Internet" был определен как "сети, объединенные с использованием протокола TCP/IP". В настоящее время Internet включает множество сетей, функционирующих в частном порядке. Некоторые из этих сетей охватывают весь земной шар; диапазон действия других не превышает несколько квадратных миль. Конечные пользователи этих сетей ранжируются, начиная от 500 самых богатых компаний мира (перечень Fortune 500, издающийся в Нью-Йорке), заканчивая вашей бабушкой, проживающей в Греции.
Для того, чтобы пользователи одного провайдера Internet могли общаться с пользователями другого провайдера, обе сети должны пересекаться в некотором месте. На раннем этапе существования internet треть пользователей подключалась к нейтральным общедоступным сетям. Компании, которые хотели бы обеспечить доступ в Internet, подключались к этим общедоступным сетям для обмена сообщениями с другими сетями, связанными между собой.
Частные сети
По причине резко возросшего интереса к Internet за последние несколько лет общедоступные сети стали перегружаться из-за генерации избыточного трафика. В силу этого наблюдалось падение производительности: точки доступа к общедоступной сети просто не справлялись с обработкой трафика, возникающего в объединенных сетях.
В ответ на возникновение этой проблемы компании изобрели новые и весьма прогрессивные методы обработки возросшего трафика. Все это привело к возникновению концепции создания взаимосвязанных частных сетей. Частная взаимосвязь — это прямое подключение между двумя сетями, созданное с единственной целью реа- лизании обмена трафиком. Такой метод обеспечивает эффективный контроль произ- водителъности, реализуемый при обмене трафиком. Частная взаимосвязь также позволяет улучшить пропускную способность и упростить процесс планирования.
Справочная модель OSI
Модель взаимодействия открытых систем (OSI I■■ Open Systems Interconnection) определяет фундамент, на котором построены все сетевые вычисления. Для большинства читателей модель OS1, наверное, не является новым понятием. Но если это не так, то беспокоиться не стоит. В следующем разделе содержится достаточный объем информации, позволяющий понять суть излагаемого материала.
Модель OSI представляет собой семиуровневую архитектурную модель, разработанную Международной организацией по стандартизации (ISO — International Organization for Standardization) и Международным телекоммуникационным союзом по поддержке телекоммуникаций (ITU-T — International Telecommunications Union-Telecommunications). Эта модель помогает разработчикам лучше освоить процесс создания и эксплуатации сетевого программного обеспечения. В рамках этой книги рассматриваются свойства сетей, а также то, каким образом основные принципы ссылочной модели OSI интегрируются в приложеНИЯХ, реализующих коммуникации между устройствами.
Каждый уровень в модели OSI имеет собственную характеристику и предназначен для выполнения своих собственных задач. При этом определяются некоторые свойства, которые должны быть реализованы аппаратным и программным обеспечением. Хотя, благодаря программному обеспечению или техническим средствам, многочисленные уровни модели OSI могут пересекаться, каждый уровень является независимым от других.
Взаимодействие между уровнями осуществляется путем выполнения определенного набора действий. Это дает возможность программистам обеспечивать нужные свойства в каждом уровне, не беспокоясь о взаимодействии с программным обеспечением, которое было (или будет) создано для других уровней модели OSI. Другими словами, каждый уровень взаимодействует некоторым образом со следующим уровнем, используя набор служб и протоколов.
Семь уровней модели OSI приведены на рис. А. 1. В следующих разделах производится краткий обзор каждого уровня, начиная с физического уровня. Физический уровень является основным уровнем, реализующим передачу пакетов стеком протоколов.
Большинство программных продуктов, предназначенных для использования в сетях, включают разделы, ответственные за выполнение функций модели OSI, Например, WWW-броузер не просто выводит данные на экран. Он также отвечает за сбор данных с сервера WWW по вашему запросу. Действия, которые в этом случае фактически происходят в Internet, заключаются в выборке данных. При этом задействуются все семь уровней модели OSI. Программное обеспечение WWW-броузера WWW может реализовывать уровни4-7модели OSI или может просто использовать 6 и 7 уровни модели OSI, во всем остальном полагаясь на операционную систему компьютера.
7Уровень приложений
6Уровень представления
5Уровень сеанса
4Транспортный уровень
3Сетевойуровень
2Канальный уровень
1Физический уровень
Рис. АЛ. Модель OSI и ее уровни,
Уровень 1: физический уровень
Физический уровеньсправечной модели OSI определяет электрические и механические спецификации физического подключения, установленного между двумя сетевыми устройствами. Спецификации физического уровня определяют такие характеристики, как уровень напряжения, синхронизация изменения напряжения, скорость передачи физических данных, максимальное расстояние передачи, а также физические соединители.
Уровни напряжения
Изменение уровней напряжения на физическом уровне фактически определяет нули и единицы в двоичной (или цифровой) системе. Уровень напряжения +5 В соответствуй ет двоичной единице; уровень напряжения О В соответствует двоичному нулю.
Физический уровень несет ответственность за передачу и прием битов. Битам присваиваются значения 0 и 1. Это единственный уровень модели OSI, который непосредственно взаимодействует с различными типами коммуникационных устройств.
Уровень 2: канальный уровень
Канальный уровеньосуществляет поиска полного начального адреса пакета. Этот уровень несет ответственность за поддержку надежных коммуникаций на физическом уровне сетевых сегментов. Спецификация данного уровня определяет характеристики извещений об ошибках, адресацию физического уровня, контроль потока, сетевую типологию, а также систему построения последовательности фреймов дейтаграмм.
Ниже перечислены спецификации этого уровня:
извещение об ошибке передает сообщение на высшие уровни модели OSI о том, что произошла ошибка;
адресация физического уровня определяет методы, с помощью которых сетевые устройства ссылаются на канальный уровень;
контроль потока ограничивает передачу данных, что позволяет избежать "захлебывания" адресата данными;
топология сети определяет методы, с помощью которых устройства прикрепляются к физическому уровню (шинная или кольцевая конфигурация);
процесс построения последовательности фреймов дейтаграмм позволяет гарантировать, что фреймы, которые были переданы в неправильном порядке, возвращаются обратно в нужном порядке.
Канальный уровень преобразует сообщение в последовательность фреймов данных, а затем добавляет адреса физического уровня. Фрейм данных состоит из шести разделов:
индикатор начала;
исходный адрес;
целевой адрес;
контрольная часть, которая реализует выполнение специальных инструкций;
фактические данные;
сегмент контроля ошибок, использующий контроль с помощью циклического избыточного кода (CRC— Cyclical Redundancy Checksum).
Институт инженеров по электротехнике и электронике(|ЕЕЕ — Institute of Electrical and Electronic Engineers) производит дополнительное разделение канального уровня на два подуровня: уровень управления логическим каналом связи (LLC — Logical Link Control) и уровень контроля доступа к среде (MAC — Media Access Control).
Уровень LLC
Уровень управления логическим каналом связи (LLC) контролирует коммуникации, осуществляемые между устройствами, с помощью единого канала связи. Уровень L ЕСопределяетс я в спецификации IEEE 802.2 и поддерживает службы, ориентированные на подключения, либо службы, не использующие подключения. Эти службы используются протоколами высшего уровня. В спецификации IEEE 802.2 определяется количество полей в системах канального уровня, что дает возможность увеличивать количество протоколов высшего уровня, разделяющих единственный физический канал связи.
Уровень MAC
Уровень контроля доступа к среде (MAC) реализует управление протоколом, обеспечивающим доступ к физической сетевой среде.
Спецификация IEEE MAC определяет адреса MAC, которые дают возможность активизировать несколько устройств с целью их уникальной идентификации на канальном уровне.
Уровень 3: сетевой уровень
Сетевой уровеньобеспечивает маршрутизацию и связанные с ней функциональные свойства таким образом, что несколько отдельных сетевых сегментов могут объединяться в одну сеть. На этом уровне осуществляется адресация программного обеспечения (логическая адресация).
Логическая адресация на сетевом уровне подобна формату почтового адреса, реализованного в виде "город, штат и ZIP-код" Этот формат является стандартным для почтовой службы США. Адреса программного обеспечения позволяют вам "попасть в нужный город" в то время как аппаратный адрес определяет полный начальный адрес.
На сетевом уровне рассматривается "корректный городской адрес". Когда сообщение достигает этого уровня, к нему прикрепляется директива, указывающая началь-
283283Уровень 3: сетевой уровень
283
283
ный и конечный адреса сообщения. Затем директива определяет наилучший путь для передачи пакета через сеть. Этот способ известен как маршрутизация, и он осушеств- ляется с помощью маршрутизаторов. Маршрутизация требуется только в том случае, если данные были посланы из устройства одного сетевого сегмента на устройство, подключенное к другому сетевому сегменту.
Уровень 4: транспортный уровень
Транспортный уровеньфункнионирует в качестве уровня "подготовки к отгрузке". Главной задачей транспортного уровня является поддержка коррекции ошибок, мультиплексирование и управление потоком данных.
Обнаружение ошибок относится к числу основных обязанностей транспортного уровня. В процессе обнаружения ошибки определяется, действительно ли было изменено первоначальное состояние данных, переданных через уровни модели OSI. Подобная проверка обычно осуществляется с помощью механизма контрольной суммы. Благодаря тому, что коррекция ошибок поддерживается на одном из уровней модели OSI, программисты приложений не должны беспокоиться относительно осуществления коррекции ошибок в программах, выполняющихся на других уровнях модели OSI.
Мультиплексирование обеспечивает разделение одного физического канала связи программами, относящимся к нескольким приложениям. Управление потоком данных гарантирует, что устройство передачи данных не отошлет их быстрее, чем может обработать устройство получения данных.
Надежными и ненадежными поставщиками называют процессы, реализующие два типа передачи данных на транспортном уровне. Надежная доставка напоминает сертифицированную почту. Она не гарантирует безупречную доставку, но предполагает, что пересылаемый материал является весьма важным. При осуществлении ненадежной доставки транспортный уровень не проверяет наличие ошибок, Это не означает бесполезность данного метода. Данный способ транспортировки может использоваться в сети, характеризующейся высокой степенью надежности, либо в том случае, когда отдельный пакет содержит завершенное сообщение. В таком случае подобный пакет именуется дейтаграммой.
Уровень 5: уровень сеанса
Уровень сеансаупорядочивает коммуникации, осуществляемые между двумя приложениями, работающими с сетевыми устройствами. Процесс коммуникации в этом случае осуществляется в трех режимах:
симплексный;
полудуплексный;
дуплексный.
Каждый режим использует собственные средства осуществления коммуникации. Симплексный режим представляет собой односторонний диалог; говоря другими словами, пока с одной стороны передается информация, с другой стороны осуществляется процесс получения этой информации. Такую же ситуацию можно было наблюдать в старые добрые времена, когда передача информации осуществлялась по телеграфу,
При использовании полудуплексного режима коммуникация осуществляется в поочередном режиме. То же самое происходит при разговоре между двумя людьми по телефону: двое собеседников не могут говорить одновременно.
Дуплексный режим основывается на управлении потоком данных и позволяет осуществить двусторонние коммуникации. Управление потоком данных используется только тогда, когда скорость функционирования двух взаимодействующих узлов не совпадает, и один из них передает информацию быстрее, чем получает второй узел.
Уровень 6: уровень представления
Уровень представленияимеет дело с типом данных, пересылаемых между двумя взаимодействующими приложениями. Приложения могут находиться на одном и том же компьютере, либо размешаться на серверах, находящихся в противоположных точках Земного шара. В любой ситуации применяется модель OSI, позволяющая реализовать одни и те же методы.
Как упоминалось в предыдущем разделе, значение слова "представление" означает отображение данных. Уровень представления дает возможность удостовериться в том, что данные, посланные с уровня приложения одной системы, могут быть использованы на уровне приложения другой системы.
Уровень представления действует как транслятор по отношению к данным, поддерживаемым на уровне приложения. Данные преобразовываются (в случае необходимости), затем отсылаются на следующий уровень.
Уровень 7: уровень приложения
Уровень приложенияпредстааляет собой окно интерфейса, с которым взаимодействует конечный пользователь. Некоторые общие примеры могут использоваться для демонстрации функционирования уровня приложения: регистрации на удаленном маршрутизаторе, загрузка сообщения электронной почты (в общих чертах), загрузка файла в Web-броузере. Это только некоторые примеры, демонстрирующие возможности уровня приложения. Используя эти приложения, можно даже не подозревать о существовании остальных шести уровней справочной модели OSI, осуществляющих все необходимые коммуникации.
Документы RFC, описывающие сети VPN
Документы запросов для комментариев (RFC — Requests for Comments) содержат большую часть информации, имеющую отношение к протоколам TCP/IP и Internet. В книге рассматривались основные стандарты, но для получения полного представления относительно используемых технологий, изучения фундаментальных технологических основ, а также для получения сведений относительно дальнейшего развития технологий потребуется ознакомиться с документами RFC. He считая некоторых исключений, документы RFC перечисляются в обратном хронологическом порядке и могут быть найдены на Web-узле http:/ /www.rfc-editor.org.
RFC 2716, “PPP ЕАР TLS Authentication Protocol." В. Aboba, D. Simon. October 1999.
RFC 2712, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).” A. Medvinsky, M. Hur. October 1999.
RFC 2709, "Security Model with Tunnel-Mode IPSec for NAT Domains." P. Srisuresh. October 1999.
RFC 2694, "DNS Extensions to Network Address Translators (DNS_ALG).” P. Srisuresh. G. Tsirtsis, P. Akkiraju, A. Heffernan. September 1999.
RFC 2693, “SPKI Certificate Theory." C. Ellison, B. Frantz. B. Lampson, R. Rivest, B. Thomas, T. Ylonen. September 1999.
RFC 2692, "SPKI Requirements." C. Ellison. September 1999.
RFC 2685, "Virtual Private Networks Identifier." B. Fox, B. Gleeson. September 1999.
RFC 2667, "IP Tunnel MIB.” D. Thaler. August 1999.
RFC 2663, "IP Network Address Translator (NAT) Terminology and Considerations." P. Srisuresh, M. Holdrege. August 1999.
RFC 2661, "Layer Two Tunneling Protocol L2TP." W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B, Palter. August 1999.
RFC 2647, "Benchmarking Terminology for Firewall Performance." D. Newman. August 1999.
RFC 2637, “Point-to- Point Tunneling Protocol (PPTP),” K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn. July 1999.
RFC 2631, “Diffie-Hellman Key Agreement Method." E. Rescorla. June 1999.
RFC 2630, "Cryptographic Message Syntax." R. Housley. June 1999.
RFC 2628, "Simple Cryptographic Program Interface (Crypto API).” V. Smyslov. June 1999.
RFC2627,"KeyManagementforMulticast:IssuesandArchitectures."D. Wallner,E.
Harder, R. Agee. June 1999.
RFC 2621,"RADIUS AccountingServerM1B.”G.Zorn, B. Aboba. June1999.
RFC 2620,"RADIUS AccountingClientMIB."B.Aboba, G. Zorn. June1999.
RFC 2619, "RADIUS Authentication Server MIB." G. Zorn, B, Aboba. June 1999.
RFC 2618, "RADIUS Authentication Client MIB." B. Aboba, G. Zorn. June 1999.
RFC 2607, "Proxy Chaining and Policy Implementation in Roaming." B. Aboba, J. Volfbrecht. June 1999.
RFC 2588, "IP Multicast and Firewalls. " R. Finlayson. May 1999.
RFC 2587, "Internet X.509 Public Key Infrastructure LDAPv2 Schema." S. Boeyen, T. Howes, P. Richard. June 1999.
RFC 2585, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP." R. Housley, P. Hoffman. May 1999.
RFC 2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol— OCSP." M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. June 1999.
RFC 2559, "Internet X.509 Public Key Infrastructure Operational Protocols—LDAPv2.” S. Boeyen, T. Howes, P. Richard. April 1999.
RFC 2548, "Microsoft Vendor-Specific RADIUS Attributes." G. Zorn. March 1999.
RFC 2541, "DNS Security Operational Considerations." D. Eastlake. March 1999.
RFC 2537, “RSA/MD5 KEYs and SIGs in the Domain Name System (DNS).” D. Eastlake. March 1999.
RFC 2528, "Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates.” R. Housley, W. Polk. March 1999.
RFC 2527, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework." S. Chokhani, W. Ford. March 1999,
RFC 2521, “ICMP Security Failures Messages." P. Kara, W. Simpson. March 1999.
RFC 2511, "Internet X.509 Certificate Request Message Format." M. Myers, C. Adams, D. Solo, D. Kemp. March 1999.
RFC 2510, "Internet X.509 Public Key Infrastructure Certificate Management Protocols." C. Adams, S. Farrell. March 1999.
RFC 2504, "Users' Security Handbook." E. Guttman, L. Leong, G. Malkin. February 1999.
RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile." R. Housley, W. Ford, W. Polk, D. Solo, January 1999.
RFC 2437, "PKCS #1: RSA Cryptography Specifications Version 2.0." B. Kaliski, J. Staddon. October 1998.
RFC 2420, "The PPP Triple-DES Encryption Protocol (3DESE)." H. Kummert. September 1998.
RFC 2419, “The PPP DES Encryption Protocol, Version 2 (DESE-bis).” K, Sklower, G. Meyer. September 1998.
RFC 2391, "Load Sharing Using IP Network Address Translation (LSNAT).” P. Srisuresh, D. Gan. August 1998.
RFC 2341, "Cisco Layer Two Forwarding (Protocol) ‘L2F.’” A. Valencia, M. Littlewood, T. Kolar. May 1998.
RFC 2340, "Nortel's Virtual Network Switching (VMS) Overview." B. Jamoussi, D. Jamieson, D. Williston, S. Gabe. May 1998.
RFC 2315,"PKCS7: Cryptographic MessageSyntax Version1-5."B.Kaliski.March 1998.
RFC 2314,"PKCS10: Certification RequestSyntax Version1-5."B.Kaliski.March 1998.
RFC 2284, "PPP Extensible Authentication Protocol (EAP).” L. Blunk, J. Vollbrecht. March 1998.
RFC 2212, "Specification of Guaranteed Quality of Service." S. Shenker, C. Partridge, R. Guerin. September 1997.
RFC 2211, "Specification of the Control-Load Network Element Service." J. Wroc lawski. September 1997.
RFC 2210, "The Use of RSVP with IETF Integrated Services." J. Wroclawski. September 1997.
RFC 2209, "Resource ReSerVation Protocol (RSVP)-Version One, Message Process Rules." R. Braden, L. Zhang. September 1997.
RFC 2208, "Resource ReSerVation Protocol (RSVP)—Version One Applicability Statement: Some Guidelines on Deployment." A. Mankin, ed., F. Baker, B. Braden, S. Bradner, M. O'Dell, A. Romanow, A. Weinrib, L. Zhang. September 1997.
RFC 2207, "RSVP Extensions for IPSEC Data Flows." L. Berger, T. O'Malley. October 1997.
RFC 2205, "RSVP Version One—Function Specification." R. Braden, ed., L. Zhang, S. Breson, S. Herzog, S. Jamin. September 1997.
RFC 2196, "Site Security Handbook." B. Fraser, ed. September 1997.
RFC 2139, "RADIUS Accounting." C. Rigney. April 1997.
RFC 2138, "Remote Authentication Dial In User Service (RADIUS).” C. Rigney, A. Rubens, W. Simpson, S. Willens. April 1997.
RFC 2132, "DHCP Options and BOOTP Vendor Extensions." S. Alexander, R. Drorns. March 1997.
RFC 2131, "Dynamic Host Configuration Protocol (DHCP)." R. Droms. March 1997.
RFC 2125, "The PPP Bandwidth Allocation Protocol (BAP)/ The PPP Bandwidth Allocation Control Protocol (BACP).” C. Richards, K. Smith. March 1997.
RFC 2118, "Microsoft Point-to-Point Compression (MPPC) Protocol." G, Pall. March 1997.
RFC 2104, “HMAC: Keyed-Hashing for Message Authentication. " H. Krawczyk, M. Bellare, R. Canetti. February 1997.
RFC 2085, “HMAC-MD5 IP Authentication with Replay Prevention." M. Oehler, R. Glenn. February 1997.
RFC 2040, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms. " R. Baldwin, R. Ri vest. October 1996.
RFC1994,"PPPChallengeHandshakeAuthenticationProtocol(CHAP)."W.Simpson.
August 1996.
RFC 1969, "The PPP DES Encryption Protocol (DESE).” K. Sklower, G. Meyer. June 1996.
RFC 1968, "The PPP Encryption Control Protocol (ECP)." G. Meyer. June 1996.
RFC 1962, "The PPP Compression Control Protocol(ССР)” D. Rand. June 1996.
RFC 1949, "Scalable Multicast Key Distribution." A. Ballardie. May 1996.
RFC1918. "Address AllocationforPrivateIntranets. "Y.Rekhtr,B.Moskowitz,D.
Karrenberg, G. J. de Groot, E. Lear. February 1996.
RFC 1915, "Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol." F. Kastenholz. February 1996.
RFC 1884, “IPVersion Six Addressing Architecture." R. Hinden, S. Deering, ed. December 1995.
RFC 1883, “Internet Protocol Version Six (IPv6) Specifications." S. Deering, R. Hinden. December 1995.
RFC 1881, "IPv6 Address Allocation Management." IAB, IESG. December 1995.
RFC 1852, "IP Authentication Using Keyed SHA.” P. Metzger, W. Simpson. December 1995.
RFC 1851, "The ESP Triple DES Transform." P. Kam, P. Metzger, W. Simpson. August 1995.
RFC 1828, "IP Authentication Using Keyed MD5.” P. Metzger, W. Simpson. August 1995.
RFC 1827, "IP Encapsulating Security Payload (ESP).” R. Atkinson. August 1995.
RFC 1826, "IP Authentication Header." R. Atkinson. August 1995.
RFC 1825, "Security Architecture for the Internet Protocol." R. Atkinson. August 1995.
RFC 1794, "DNS Support for Load Balancing." T. Brisco. April 1995.
RFC 1702, "Generic Routing Encapsulation over IP Version Four Networks." S. Hanks, T.
Li, D. Farinacci, P. Traina. October 1994.
RFC 1701, "Generic Routing Encapsulation (GRE).” S. Hanks, T. Li, D. Farinacci, P. Traina. October 1994.
RFC 1661, "The Point-to-Point Protocol (PPP).” W. Simpson, ed. July 1994.
RFC 1631, "The IP Network Address Translator (NAT).” K. Egevang, P. Francis. May 1994.
RFC1535,"ASecurityProblemandProposed Correction withWidelyDeployedDNS
Software." E. Gavron. October 1993.
RFC 1531, "Dynamic Host Configuration Protocol (DHCP)." R. Droms. October 1993.
RFC 1510, "The Kerberos Network Authentication Service (v5).” J. Kohl, C. Neuman. September 1993.
RFC 1472, “The Definitions of Managed Objects for the Security Protocols of the Point-to- Point Protocol." E. Kastenholz. June 1993.
RFC 1321, “The MD5 Message-Digest Algorithm." R. Rivest April 1992.
RFC 1170, "Public Key Standards and Licenses." R. Fougner. January 1991.
RFC 1108, "U.S. Department of Defense Security Options for the Internet Protocol." S. Kent. November 1991.
Б
Устранение проблем
Учитывая большое количество факторов, оказывающих влияние на среду VPN, большое значение имеет отлаженная методика устранения возникающих проблем.
Необходимость разработки подобной методики диктуется практикой. Например, порой встречается утверждение, что туннельное подключение функционирует медленнее, чем удаленное подключение, устанавливаемое с помощью модемов корпоративной службы RAS. При этом конечные пользователи полагают, что телефонный канал связи функционирует быстрее любого туннельного подключения. Но это утверждение в корне неверно. В данном случае возникают проблемы с конкретным подключением VPN, для устранения которых потребуются разработки методики устранения проблем. При этом потребуется целенаправленное исследование самых различных моментов, связанных с разными предметными областями.
Факторы, приводящие к возникновению проблем
При работе в виртуальных частных сетях требуется учитывать множество факторов, обеспечивающих поддержку эффективного канала связи с корпоративными сетями. В ходе процесса устранения возникших проблем сначала потребуется установить причины, приведшие к появлению данной проблемы. Некоторые из факторов, которые могут оказать серьезное воздействие на туннельную среду, перечислены ниже.
Быстродействие клиентского подключения к Internet. Как правило, провайдеры услуг Internet переоценивают показатели пропускной способности своих каналов связи. Причина подобного положения вещей весьма проста: деньги. Провайдеры заявляют о наличии некоторой скорости клиентского доступа, по достижению которой выявляется факт совершенно недостаточной пропускной способности каналов доступа в Internet, требуемой для поддержки клиентов.
Путь, установленный к туннельному серверу. Необходимо проанализировать путь и количество транзитных участков, которые будут преодолеваться при получении фактического доступа к туннельному серверу. Этот фактор очень сильно сказывается на производительности туннеля, даже если он был установлен ранее. Обращайте внимание не только на количество транзитных участков, но также и на время задержки между транзитными участками. Хорошим примером в этой ситуации являются огромные различия, проявляющиеся при использовании локального туннельного сервера и сервера, находящегося на другом "конце света".
Быстродействие туннельного сервера. Если туннельный сервер не в состоянии поддерживать на должном уровне трафик, особенно при необходимости выполнения шифрования и декодирования, клиенты ощутят на себе падение производительно-
сти. В этой ситуации потребуется разработать базовую стратегию оценки производительности сервера, а также сравнить показатели быстродействия сервера и пользователей, устанавливающих туннель и осуществляющих доступ к ресурсам.
Быстродействие корпоративной сети. Сразу же после подключения к туннелю начинает сказываться быстродействие внутренней сети, находящейся за туннельным сервером. Если быстродействие этой сети является недостаточным либо существует слишком много транзитных участков, замедляется трафик в корпоративной сети. Например, туннельный клиент может подключиться к туннелю и получить великолепный по качеству Доступ к почтовому серверу, но при этом может чрезмерно замедляться быстродействие какого-либо сервера внутренней сети предприятия. Это может означать перегруженность каналов связи сервера внутренней сети предприятия.
Быстродействие целевого сервера. Если сервер, к которому подключается клиент, является слишком медленным, скорость подключения будет совершенно недостаточной независимо от типа подключения. Величина быстродействия в этом случае определяется корпоративным провайдером услуг Internet.
Простейший способ начать применять методику устранения проблем заключается в выполнении простой трассировки маршрутов для ключевых точек сетевого пути, ведущего от туннельного клиента к корпоративному целевому местоположению. В большинстве реализаций туннелей не допускается трафик ICMP через брандмауэр или туннельный сервер, поэтому придется выполнять трассировку последнего маршрутизатора перед тем, как применять устройства, генерирующие трафик ICMP.
Выполнение утилиты- Tracer!
Для выполнения трассировки маршрутов придерживайтесь следующих шагов:
Щелкните на кнопке <Start> (Пуск).
Выберите команду Run (Выполнить),
Введите команду CMD и щелкните на кнопке <ок>.
Введите команду TRACERIадрес. В качестве параметра адрес может использоваться имя хоста, включающее буквы и цифры, например, Host.happyvpn.com, либо численный адрес TCP/IP (216.82.49.34).
С «отношения между пропускными способностялш, обеспечиваемыми провайдерами услуг Internet
В большинствеслучаев невозможно декларировать соотношение между величиной пропускной способности каналов связи, предоставляемых клиентам, и существующим значением этого параметра для провайдеров услуг Internet. Этот вопрос должен решаться в индивидуальном порядке клиентами, выбирающими новых провайдеров услуг Internet. По моему глубокому убеждению, большинство провайдеров услуг Internet ведут достаточно разнузданную рекламную кампанию. Но я все же надеюсь, что, начиная с некоторого момента времени, они все же открыто сообщают потенциальным клиентам о соотношении между максимальной заявленной скоростью подключения и реальным значением пропускной способности. В настоящее время большинство потенциальных клиентов вынуждены полагаться на отзывы относительно быстродействия каналов связи, предлагаемыхразличными провайдерами услуг■ Internet.
Утилиты PPTPCLNT и PPTPSRV
Большинство новых пользователей туннелей испытывают затруднения в связи с установкой администратором фильтров на туннельном сервере. Причиной затруднений в этом случае будет отключение поддержки протокола ICMP. Конечно, это действие, прежде всего, направлено на обеспечение защиты сервера, но при этом наблюдается весьма не-
приятный побочный эффект. Суть такого эффекта заключается в тон, что клиенты никогда не смогут получать отклик, в результате чего нарушается функционирование утилит эхо-тестирования (ping) и трассировки маршрутов (trace route). Фирма Microsoft в комплект протокола PPTP включила утилиту ping, которая выполняет тестирование каналов связи, поддерживаемых протоколом РРТР. С помощью этой утилиты специалист в области тестирования получает информацию, которая позволяет убедиться в том, что сеть, проложенная между клиентом и сервером, полностью сконфигурирована для работы с протоколом РРТР.
Утилита Microsoft включает два компонента. Первый из них, PPTPSRV.exe, выполняется в области нахождения сервера. Этот компонент не обязательно должен выполняться на реальном сервере, но обязательным является требование относительно его выполнения в том же самом сетевом пространстве, иначе результаты тестирования будут недостоверными.
Для продолжения процесса тестирования клиенту потребуется выполнять второй компонент, PPTPCLNT.exe, указав при этом адрес TCP/IP сервера, выполняющего серверную утилиту. Клиентская утилита обеспечивает для клиента процесс ввода текста, передаваемого серверу. После того, как текст был получен серверной утилитой, будет подтвержден факт установки канала связи РРТР.
Эта утилита является достаточно устаревшей, но свою задачу она выполняет превосходно. Благодаря ее использованию, можно получить ответ на фундаментальный вопрос относительно того, может ли клиент установить туннель РРТР. После этого специалист по тестированию может приступать к выяснению других проблем.
Производительность
Количество транзитных перехбдов на пути от клиента к туннельному серверу зависит от провайдеров услуг Internet сервера и клиента. Наилучший метод исключения неэффективных маршрутов, ведущих к целевому местоположению, заключается в выборе провайдеров, имеющих хорошую репутацию и достаточно разветвленные сети. Если же вы имеете дело с малоизвестными провайдерами услуг Internet, то в этом случае возрастает вероятность того, что количество транзитных переходов будет велико, а зависимость от имеющегося пути — поистине разочаровывающей.
В моей практике встречались корпорации, проблемы которых были связаны с высокими значениями временных задержек для туннелей. В этом случае можно “десенсибилизировать” туннельный сервер РРТР путем увеличения параметра повторной передачи данных, определенного в записи системного реестра. Как правило, подобная практика не рекомендуется, поскольку при этом увеличивается время задержки в случае, если отключение было реализовано на физическом уровне. Однако, в некоторых случаях подобные действия помогают предотвратить возможное "разрушение" туннеля. В документации Microsoft подобная методика фигурирует под кодом Q154674. При этом используются следующие настройки ключа системного реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Paraineters\PPTe TcpMaxDataRetransmissions
Тип данных: REG_DWORD
Диапазон значений: O-OxFFFFFFFF
Значение, заданное по умолчанию: 9h
Не следует устанавливать величину значения, превышающую 27h; обычная настройка для сетей с высоким значением параметра задержки равна 18h.
Также обычно предполагается, что туннельный сервер должен быть многопроцессорной системой, поскольку в этом случае возможно распределение нагрузки, связанной с шифрованием/декодированием, на различных процессорах. Подобная методика важна не только с точки зрения обеспечения производительности, но также и с точки зрения безопасности (в этом случае на туннельном сервере не могут выполняться никакие другие процессы). Накладные затраты, связанные с использованием выделенного сервера, являются минимальными. Это связано с обшей тенденцией уменьшения затрат, наблюдаю-
шейся при переходе от подключений удаленного доступа и выделенных линий к сетям VPN. Кроме того, в случае поддержки других сетевых служб можно неосторожно создать потенциальные "дыры" в системе безопасности конфигурации туннельного сервера.
Довольно затруднительно давать точные рекомендации по поводу выбора аппаратных средств, ибо требования к аппаратному обеспечению полностью зависят от потребностей сети и клиентов. Конечно, сервер Windows 2000, выполняющий протокол L2TP/!PSec, сможет использовать преимущества сетевых плат разгрузки. Подобное технологическое решение, в свою очередь, помогло бы сместить акценты в сторону увеличения степени шифрования /декодирования.
Если в ходе выполнения трассировки были обнаружены "узкие места" в корпоративной сети, эта проблема может быть разрешена сетевым администратором. Подобные "узкие места" во внутренней сети могут быть найдены при условии выполнения эффективного тестирования. Важность локализации "узких мест" объясняется тем, что они оказывают влияние не только на пользователей туннеля, но и на любых пользователей внутренней сети.
И напоследок отметим, что если целевое вычислительное устройство перегружено и наблюдается падение его быстродействия, это может негативно сказаться на быстродействии всей туннельной среды. Подобная перегрузка может быть легко выявлена в ходе трассировки, поскольку в этом случае будут наблюдаться высокие значения времени задержки.
Общие вопросы и советы по устранению проблем
Если туннельные клиенты не могут подключаться к туннельному серверу, проверьте систему на предмет возникновения проблем, перечисленных в следующем обширном списке.
Порты VPN (PPTP и/или L2TP) не воспринимают входящие запросы.
При выполнении сервера не используются порты VPN.
Сервер не располагает достаточным количеством IP-адресов для обеспечения ими входящих клиентов. Адреса могут распределяться из статического пула адресов либо назначаться сервером DHCP.
Требуемые протоколы (IPX или NetBEUI) не сконфигурированы для входящих туннелей.
Не поддерживается требуемый протоколтуннелирования. Если туннельный сервер выполняет протокол L2TP, а клиенты используют протокол РРТР, подключение установить не удастся;
Установленные свойства политики удаленного доступа предотвращают подключение клиентов. Помните о том, что в случае использования аутентификации RADIUS политика удаленного доступа должна конфигурироваться для сервера IAS.
Привилегии, обеспечиваемые пользовательской учетной записью, запрещают выполнение подключений со стороны пользователей (разумеется, если не используется политика удаленного доступа).
Клиенты не могут быть аутентифицированы вследствие того, что процедура аутентификации не может получить доступ к Active Directory или серверу RADIUS. Убедитесь в том, что сервер(ы) были добавлены в группу безопасности серверов RAS и IAS.
Для сервера VPN, который входит в состав домена Windows 2000, выполняющего аутентификацию в смешанном или собственном режиме Windows 2000, существует группа безопасности серверов RAS и 1AS. Если эта группа не существует, необходимо ее создать, установить тип группы Security (Безопасность), а значению параметра области доступа группы присвоить Domain Local (Локальный домен).
Для группы безопасности серверов RAS и IAS были установлены права доступа Read (Чтение) (для объектов доступа серверов RAS и IAS). Учетная запись компьютера сервера VPN должна быть участником групп безопасности серверов RAS и IAS. Если в группы безопасности серверов RAS и IAS добавляется или удаляется из них компьютер сервера VPN, подобное изменение не приводит к появлению немедленного эффекта. Быстрейший метод активизации подобного эффекта заключается в выполнении перезагрузки компьютера сервера VPN.
Группа Everyone (Каждый) была добавлена в Группу обеспечения совместимости доступа в версии, предшествующей версии Windows 2000. В этом случае потребуется выполнить проверку туннельного сервера, выполняющего Windows NT 4,0, на предмет использования домена, реализующего смешанный режим Windows 2000.
Клиенты должны иметь машинный сертификат для установки туннеля в случае, если клиенты для установки туннелей используют протокол L2TP/IPSec.
Включение регистрации для сервера RRAS
В ходе осуществления процесса устранения проблем, связанных с туннельными клиентами, важно задействовать максимальный объем регистрации, допустимый для сервера RRAS. Для достижения этого выполните следующие шаги:
Выберите пункты меню Start Ф Programs ф Administrative Tools ф Routing and Remote Access (Пуск ф Программы фАдминистрирование ф Маршрутизация и удаленный доступ).
В правой панели щелкните на имени сервера, затем выберите команду Properties (Свойства).
Щелкните на вкладке Event Logging (Регистрация событий).
Щелкните на кнопке <Log the Maximum Amount of lnformation> (Регистрировать максимум информации), затем установите флажок Enable Point-to-Point (РРР) Logging (Включить регистрацию "точка-точка" (РРР)).
Разрешение проблем, связанных с протоколом IPSec
Разрешение проблем, связанных с протоколом IPSec, осуществляется с помощью двух различных методов. Рекомендуется просто выполнить утилиту IPSECMON. Для запуска на выполнение этой утилиты воспользуйтесь следующими шагами,
Щелкните на пунктах меню Start Ф Run (Пуск Ф Выполнить) и введите IPSECMON.
Если процесс использования утилиты является весьма активным, стоит уменьшить время обновления. В результате процесс обновления будет осуществляться быстрее, чем в случае использования стандартных настроек. Изменение этой настройки осуществляется путем щелчка на кнопке <0ptions> (Опции) и изменения значения на любое другое, отличное от 15 секунд. Я обычно использую значение, равное 3 секундам.
Результаты вычислений показывают все активные ассоциации протокола беэопас- ности IPSec, включая туннели L2TP/IPSec, Установка также отображает дополнительные сведения, которые облегчают процесс отслеживания активных ссылок и попыток подключений.
Если при работе с протоколом IPSec возникают какие-либо проблемы, будет нелишним перейти к просмотру журналов. К сожалению, журналы IPSec являются несколько сложными и трудными для восприятия. Но в любом случае просмотр журналов обычно позволяет определить, в каком месте находится источник проблемы. Для активизации функции регистрации воспользуйтесь следующими шагами.
Используя редактор Regedt32, измените ключ системного реестра HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley. Если ключ Oakley не существует, придется его создать,
Добавьте значение Debug типа REG_DWORD для ключа Oakley.
Значению Debug присвойте 1 для включения регистрации. (Значение 0 отключает процесс регистрации.) Файл Oakley.log создается в системном каталоге.
Согласно моим исследованиям, для протокола L2TP/IPSec характерны две типичных ошибки, проявляющиеся в следующих ситуациях: либо в распоряжении клиента отсутствует локальный машинный сертификат, который генерирует событие, либо клиент находится за сервером NAT. Перед использованием этих возможностей их потребуется детально исследовать.
Утилита Network Monitor
Как и с другими типичными случаями сетевых вычислений, наилучший метод устранения проблем, проявляющихся при использовании туннелей, заключается в использовании утилиты Network Monitor (Сетевой монитор). При этом становится возможным исследование сетевого трафика. Мониторинг сетевого трафика должен производиться в одной или обеих конечных точках туннеля. Если вместо этого попытаться выполнить мониторинг трафика в туннеле (при условии его кодирования), полученная информация будет бесполезной. Кроме того, если приложение Network Monitor выполняется для туннельного сервера, можно наблюдать процесс аутентификации и все этапы обмена данными, выполняющиеся при установке туннеля. И, наконец, можно просматривать трафик после того, как туннельный сервер выполнит его декодирование.
Сканеры портов
Я являюсь сторонником тестирования конфигурации фильтров или политик IPSec, установленных для клиентов и серверов, с помощью анализатора портов (или сканера). Во многих корпорациях практикуется проверка настроек безопасности подключенных клиентов с помощью анализатора. При этом используется метод случайной выборки. Благодаря этому, туннельный администратор может обнаружить, позволяют ли клиенты генерирование неавторизованного трафика, проходящего через подключенные туннели.
Кроме того, требуется проверка (обычная и двойная) настроек безопасности для туннельных серверов, Поскольку существует вероятность того, что клиентские IP-адреса носят динамический характер, в этом случае появляются дополнительные проблемы. В противовес этому сервер обычно выполняет присваивание статических адресов или имен хостов. Если в серверной среде имеется "дыра" в системе безопасности, необходимо ее обнаружить до того, как сервер будет официально функционировать в оперативном режиме.
Резюме
Наиболее важный этап в диагностике проблем, проявляющихся при работе с сетями VPN, заключается в изучении структуры сети. Благодаря этому, можно понять природу возникшей проблемы. Согласно моим исследованиям большинство проблем проявляются при маршрутизации.
После того, как вы пришли к мнению относительно корректности сетевого проекта, необходимо установить источник проблемы. Довольно непрактично разрешать проблемы методом "проб и ошибок", поскольку обычная конфигурация туннеля включает множество переменных.
в
Связь между протоколами IPSec
Windows 2000 и Cisco
Конфигурирование конечных точек туннеля осуществляется с применением нескольких методов. Этот процесс становится все более распространенным при взаимодействии различных устройств, функционирующих под управлением различных операционных систем. Чаще всего подобное взаимодействие осуществляется с помощью канала связи, который Windows 2000 устанавливает с целью обеспечения связи между сервером Windows 2000 и устройством Cisco. Подобная связь может создаваться различными методами, однако, наиболее распространенными являются выполнение протокола IPSec в туннельном режиме (связь типа "шлюз-шлюз") и конфигурирование канала связи типа "шлюз-шлюз" с помощью протокола L2TP/IPSec. С точки зрения пользователей Windows наиболее простым является конфигурирование канала связи L2TP/IPSec, но при этом следует учитывать тот факт, что в настоящее время многие устройства все еще не поддерживают этот стандарт.
Хотя могут использоваться оба типа туннелей, основанных на IPSec, в данном приложении рассматривается наиболее сложный из них. Это связано с тем, что существует множество устройств, отличных от устройств Cisco, которые могут нуждаться в выполнении подобного конфигурирования.
В настоящем приложении описывается создание зашифрованного туннеля на основе протокола IPSec, соединяющего сервер Windows 2000 и маршрутизатор Cisco. Назначение подобного туннеля заключается в поддержке подключения "точка-точка", при установке которого выполняется шифрование всех данных, передающихся между двумя различными сетями. В рассматриваемом примере весь трафик из подсети 172.16.9.0 направляется в подсеть 10.10.10.0 (то же самое можно сказать относительно трафика, передающегося в обратном направлении). При этом происходит шифрование трафика, генерируемого между сетевым адаптером сервера Windows 2000 IPSec (192,168.100.1) и интерфейсом Ethernet (192.168.100.2) машрутизатора Cisco.
Примечание
При конфигурировании маршрутизаторов Cisco должна использоваться версия операционной системы Cisco IOS 12. 0(7)t или более старшая; хотя более ранние версии поддерживают IPSec, их применение не рекомендуется.
Большинство маршрутизаторов Cisco, начиная от модели 800 и лучше, могут работать с IOS и IPSec .
Установка сети
Полное понимание проблем, связанных с проектированием сети и специфическим конфигурированием туннеля, является весьма важным. Для установки туннеля типа "шлюз-шлюз", поддерживающего клиентские службы на обоих концах туннеля, необходимо убедиться в том, что выполнено эффективное конфигурирование процесса маршрутизация (без конфликтов и "прогалин"). Когда я разрабатываю проект сети, я всегда рисую будущую сеть на листе бумаги, а также включаю информацию подсетей для всех соответствующих частей сети. Благодаря этому, можно сделать наглядным проект сети и предотвратить случайное "забывание" отдельных компонентов.
На рис. В. 1 показан статический маршрут, который был установлен на сервере Windows 2000 IPSec и обеспечивает коммуникации из подсети 172.16.9.0, проходящие через подсеть 10.10.10.0.
192.168.100.1192.168.100.1Весь трафик из подсети 172.16.9.0, направляемый в подсеть 10.1010,0 (это же касается обратного трафика), будет зашифрован.Весь трафик из подсети 172.16.9.0, направляемый в подсеть 10.1010,0 (это же касается обратного трафика), будет зашифрован.Этот трафик проходит между сетевым адаптером сервера Wini 000 IPSec (192.168.100) и интерфейсом Ethernet (192.168.100.2)Этот трафик проходит между сетевым адаптером сервера Wini 000 IPSec (192.168.100) и интерфейсом Ethernet (192.168.100.2)192.168.100.2192.168.100.2машрутизатора Cisco.машрутизатора Cisco.Клиент 3Клиент 410.10.10.210.10.10.3Клиент 3Клиент 410.10.10.210.10.10.3
192.168.100.1
192.168.100.1
Весь трафик из подсети 172.16.9.0, направляемый в подсеть 10.1010,0 (это же касается обратного трафика), будет зашифрован.
Весь трафик из подсети 172.16.9.0, направляемый в подсеть 10.1010,0 (это же касается обратного трафика), будет зашифрован.
Этот трафик проходит между сетевым адаптером сервера Wini 000 IPSec (192.168.100) и интерфейсом Ethernet (192.168.100.2)
Этот трафик проходит между сетевым адаптером сервера Wini 000 IPSec (192.168.100) и интерфейсом Ethernet (192.168.100.2)
192.168.100.2
192.168.100.2
машрутизатора Cisco.
машрутизатора Cisco.
Клиент 3Клиент 4
10.10.10.210.10.10.3
Клиент 3Клиент 4
10.10.10.210.10.10.3
Рис. В. /. Сетевая диаграмма
Подобные действия могут выполняться с помощью команды ROUTE консоли Command, как показано в следующем примере:
С:> route add -p 10.10.10.0 mask 255.255.255.0 192.166.100.1
Поскольку брандмауэр (172.16.9.1) является стандартным шлюзом для подсети 172.16.9.0, в данном случае будет добавлен тот же статический маршрут, что и в ранее рассмотренном примере. Таким образом, если клиентский компьютер в подсети 172.16.9.0 пытается взаимодействовать с компьютером в подсети 10.10.10.0, он сначала проверяет собственные таблицы маршрутизации. Если для требуемой сети не найден определенный маршрут для требуемой подсети, осуществляется взаимодействие со стандартным шлюзом. Этот компьютер передает запрос серверу IPSec, который также включает определенный маршрут и передает запрос через туннель IPSec маршрути за -
тору Cisco, а затем — в подсеть 10.10.10.0. Маршрутизатор Cisco является стандартным шлюзом для подсети 10.10.10.0 и включает определенный маршрут, который проложен обратно к серверу IPSec с целью обработки всего трафика, не связанного с локальной подсетью.
При осуществлении только что описанного процесса маршрутизация требуется для обеспечения коммуникаций между подсетями еще до того, как будет установлено подключение IPSec. Этот процесс должен быть настроен и протестирован еще до выполнения конфигурирования протокола IPSec.
Настройка политики безопасности Windows 2000
В Windows 2000 политики безопасности используются для контроля над методами использования протокола IPSec. Политика безопасности встраивается с ПОМОЩЬЮ списков фильтров и их действий. В результате обеспечиваются более гибкие и масштабируемые средства, обеспечивающие контроль безопасности IPSec.
Доступ к политикам, фильтрам и правилам обеспечивается с помощью консоли управления Microsoft(MMC - Microsoft Management Console). Для этой консоли настраиваются подключаемые модули политик 1Р-безопасности. Для реализации подобного доступа выполните следующие шаги.
В меню кнопки <Start> (Пуск) выберите команду Run (Выполнить) и введите ммс В результате выполнения этих действий запускается на выполнение пустая консоль управления Microsoft. В меню Console (Консоль) выберите команду Add/Remove Snap-In (Добавить/Удалить подключаемый модуль).
В появившемся диалоговом окне выберите команду Add (Добавить), затем выделите необходимые подключаемые модули.
ааu » и с ^iu » и с ^i"75552=5"75552=5Пу «viiet* 1Н Inlet: «vr^ertdtydFLecvpyПу «viiet* 1Н Inlet: «vr^ertdtydFLecvpyн«чн«чIГ Ь* ~] й-ww* |IГ Ь* ~] й-ww* |b'eija* rt*LMb'eija* rt*LMЛ72«10Ю10Ю^00 U*tw. ^PpeiKi I'- WlfilG0e»f^l690Л72«10Ю10Ю^00 U*tw. ^PpeiKi I'- WlfilG0e»f^l690■"sS■"sSMiuwruetv: |Х«»#.ГА«.Аао,|Miuwruetv: |Х«»#.ГА«.Аао,|
а
а
u » и с ^i
u » и с ^i
"75552=5
"75552=5
Пу «viiet* 1Н Inlet: «vr^ertdtydFLecvpy
Пу «viiet* 1Н Inlet: «vr^ertdtydFLecvpy
н«ч
н«ч
IГ Ь* ~] й-ww* |
IГ Ь* ~] й-ww* |
b'eija* rt*LM
b'eija* rt*LM
Л72«10Ю10Ю^00 U*tw. ^PpeiKi I'- WlfilG0e»f^l690
Л72«10Ю10Ю^00 U*tw. ^PpeiKi I'- WlfilG0e»f^l690
■"sS
■"sS
Miuwruetv: |Х«»#.ГА«.Аао,|
Miuwruetv: |Х«»#.ГА«.Аао,|
Рис. B.2. Доступ к спискам IP-фильтров и действиям фильтров
В условиях рассматриваемого примера выберите ОПЦИЮ IP Security Policy Management (Управление политикой IP-безопасности), щелкните на кнопке <Add> (Добавить), выберите опцию Local Computer (Локальный компьютер) и щелкните на кнопке <Finish> (Готово). Затем щелкните на кнопках <Close> (Закрыть) и <ОК>.
В результате описанных выше действий настраивается консоль ММС политики безопасности IPSec. Параметры настройки консоли ММС можно сохранить на рабочем столе, что позволит облегчить доступ к ней в будущем. Для выполнения этих операций в меню Console (Консоль) выберите команду Save As (Сохранить как), затем укажите подходящее имя и сохраните настройки на рабочем столе.
Перед созданием новой политики безопасности потребуется установить два новых списка фильтров, контролирующих фактическое применение протокола IPSec. Процесс контроля осуществляется на основе исходного и целевого IP-адресов (а также на основе протокола, но в данном примере может быть выбран любой протокол). В рассматриваемом примере два списка фильтров, именуемые А-В и В-А, указывают направление передачи трафика (подсети А = 172.16.9.0 и В = 10.10.10.0). Соответствующие иллюстрации приведены на рис. B.2 - В.4.
—-.An IF Ai fat A <cn<xned lV -**<*• Aot tr• •« ••>• -'***? itixwr: IP"-, • ad^e-.w «^er*x*<,xibec***r*dHoanelRMei—-.An IF Ai fat A <cn<xned lV -**<*• Aot tr• •« ••>• -'***? itixwr: IP"-, • ad^e-.w «^er*x*<,xibec***r*dHoanelRMei
—-.An IF Ai fat A <cn<xned lV -**<*• Aot tr• •« ••>• -'***? itixwr: IP
"-, • ad^e-.w «^er*x*<,xibec***r*dHoanelRMei
—-.An IF Ai fat A <cn<xned lV -**<*• Aot tr• •« ••>• -'***? itixwr: IP
"-, • ad^e-.w «^er*x*<,xibec***r*dHoanelRMei
AM«:u>C | Pitiaeol | Diicx*r [AM«:u>C | Pitiaeol | Diicx*r ['■■■■■■■■■№F*d*« | izz is . 5 " оSibwmwi | 765755*7 75S~ 0Oatfwwxjn «M«t к ■ - -—— -■|аю**с1?$<»п*Дюлачи! | io ,iu.u. оSxtmi ir*4, I 755 . ?№ . ?55 . 0'■■■■■■■■■№F*d*« | izz is . 5 " оSibwmwi | 765755*7 75S~ 0Oatfwwxjn «M«t к ■ - -—— -■|аю**с1?$<»п*Дюлачи! | io ,iu.u. оSxtmi ir*4, I 755 . ?№ . ?55 . 0Г Myyid AI,3*»di»»deit*tiiiiwowietW«iwixc»<ri6 do;'jn*X' »M«i:«kГ Myyid AI,3*»di»»deit*tiiiiwowietW«iwixc»<ri6 do;'jn*X' »M«i:«kРис. B.3. Свойства фильтра А-ВРис. B.3. Свойства фильтра А-ВВ данном примере фильтру протокола присваивается значение Any (Любой), а опция Mirrored (Отраженный) остается неотмеченной.В данном примере фильтру протокола присваивается значение Any (Любой), а опция Mirrored (Отраженный) остается неотмеченной.
AM«:u>C | Pitiaeol | Diicx*r [
AM«:u>C | Pitiaeol | Diicx*r [
'■■■■■■■■■№
F*d*« | izz is . 5 " о
Sibwmwi | 765755*7 75S~ 0
Oatfwwxjn «M«t к ■ - -—— -■
|аю**с1?$<»п*Д
юлачи! | io ,iu.u. о
Sxtmi ir*4, I 755 . ?№ . ?55 . 0
'■■■■■■■■■№
F*d*« | izz is . 5 " о
Sibwmwi | 765755*7 75S~ 0
Oatfwwxjn «M«t к ■ - -—— -■
|аю**с1?$<»п*Д
юлачи! | io ,iu.u. о
Sxtmi ir*4, I 755 . ?№ . ?55 . 0
Г Myyid AI,3*»di»»deit*tiiiiwowietW«iwixc»<ri6 do;'jn*X' »M«i:«k
Г Myyid AI,3*»di»»deit*tiiiiwowietW«iwixc»<ri6 do;'jn*X' »M«i:«k
Рис. B.3. Свойства фильтра А-В
Рис. B.3. Свойства фильтра А-В
В данном примере фильтру протокола присваивается значение Any (Любой), а опция Mirrored (Отраженный) остается неотмеченной.
В данном примере фильтру протокола присваивается значение Any (Любой), а опция Mirrored (Отраженный) остается неотмеченной.
An IP №w lit w c impmed d mulck ®W In tie» e-*- fr.J<*e .-ix*^ IP end* net end piotocde ter» be oc«ibr*l rto one IP Ite»An IP №w lit w c impmed d mulck ®W In tie» e-*- fr.J<*e .-ix*^ IP end* net end piotocde ter» be oc«ibr*l rto one IP Ite»fceccrmonfceccrmonAdi,Adi,Ш10100 to 1711630Ш10100 to 1711630Ra.:Ra.:•|B«"«r |Г* UieAddvTitOtd•|B«"«r |Г* UieAddvTitOtdHtodtott- ^«ototri 1 $<MC*Pql I Df«*MlrnPprt I SoKceWSHww ■ taitj^dHtodtott- ^«ototri 1 $<MC*Pql I Df«*MlrnPprt I SoKceWSHww ■ taitj^dНо Л-ГНо Л-ГAWAWWVWV-Aw^cIPSub. 1010 Щ0-Aw^cIPSub. 1010 Щ0Iilter Protwiiir*Iilter Protwiiir*‘л*«‘ j y*xO M*‘л*«‘ j y*xO M*ithrr Propertie*ithrr Propertie*212Si212SiAd*e: ang | Pioiccd | Deacwtxri |Ad*e: ang | Pioiccd | Deacwtxri |*J(MC»**>t;i*J(MC»**>t;ijPAdd,-.; j . 10 . 10 . aSubnet ^e* | 255 . 255 . 255 , 0jPAdd,-.; j . 10 . 10 . aSubnet ^e* | 255 . 255 . 255 , 0Mnyed AfcarAVchjwH’eti vrfhtheftiict oppose tomce and<ki*nx<xi edde: >e;Mnyed AfcarAVchjwH’eti vrfhtheftiict oppose tomce and<ki*nx<xi edde: >e;
An IP №w lit w c impmed d mulck ®W In tie» e-*- fr.J<*e .-ix*^ IP end* net end piotocde ter» be oc«ibr*l rto one IP Ite»
An IP №w lit w c impmed d mulck ®W In tie» e-*- fr.J<*e .-ix*^ IP end* net end piotocde ter» be oc«ibr*l rto one IP Ite»
fceccrmon
fceccrmon
Adi,
Adi,
Ш10100 to 1711630
Ш10100 to 1711630
Ra.:
Ra.:
•|B«"«r |
Г* UieAddvTitOtd
•|B«"«r |
Г* UieAddvTitOtd
Htodtott- ^«ototri 1 $<MC*Pql I Df«*MlrnPprt I SoKceWSHww ■ taitj^d
Htodtott- ^«ototri 1 $<MC*Pql I Df«*MlrnPprt I SoKceWSHww ■ taitj^d
Но Л-Г
Но Л-Г
AW
AW
WV
WV
-Aw^cIPSub. 1010 Щ0
-Aw^cIPSub. 1010 Щ0
Iilter Protwiiir*
Iilter Protwiiir*
‘л*«‘ j y*xO M*
‘л*«‘ j y*xO M*
ithrr Propertie*
ithrr Propertie*
212Si
212Si
Ad*e: ang | Pioiccd | Deacwtxri |
Ad*e: ang | Pioiccd | Deacwtxri |
*J(MC»**>t;i
*J(MC»**>t;i
jPAdd,-.; j . 10 . 10 . a
Subnet ^e* | 255 . 255 . 255 , 0
jPAdd,-.; j . 10 . 10 . a
Subnet ^e* | 255 . 255 . 255 , 0
Mnyed AfcarAVchjwH’eti vrfhtheftiict oppose tomce and
<ki*nx<xi edde: >e;
Mnyed AfcarAVchjwH’eti vrfhtheftiict oppose tomce and
<ki*nx<xi edde: >e;
С
Рис. ВЛ Свойства фильтра В-А
После создания двух новых фильтров необходимо определить способ шифрования потоков данных. Выполнение подобных операций осуществляется с помощью вкладки Manage Filter Actions (Управление действиями фильтра). Для получения доступа к этой вкладке потребуется выполнить следующие шаги.
В консоли ММС правой кнопкой мыши щелкните на элементе IP Security Policies (Политики IP-безопасности).
В контекстном меню выберите пункт Manage IP Filter Lists and Filter Actions (Управ- лятьспискамиIP-фильтровидействиямифильтров).
Щелкните на вкладке Manage Filter Actions (Управлять действиями фильтра) (рис. B.5).
Выделите действие фильтра Require Security (Требуется безопасность) и щелкните на кнопке <Edit> (Изменить). После этого отобразится диалоговое окно, показанное на рис. В.6.
Рис. 5.Manage Filter
Рис.обеспечения безопасности
В операционных системах Windows 2000 и Cisco IOS поддерживаются различные комбинации методов DES (или 3DES), использующих алгоритмы МО5(либо SHA1) для выполнения шифрования данных и обеспечения их целостности- При использовании этой конфигурации интеграция MD5 с шифрованием DES не обеспечивает использование аутентификации пакетов.
При выполнении конфигурирования убедитесь в том, что выбрана опция Negotiate Security (Договоренность о безопасности). В этом случае Windows 2000 пытается выбирать методы обеспечения безопасности последовательно до тех пор, пока не будет найден метод, подходящий для партнеров по системе безопасности.
После того, как были созданы два новых списка фильтров, приступим к созданию новой политики безопасности.
Для получения доступа к мастеру Create New Security Policy (Создание новой политики безопасности) откройте ранее созданную консоль ММС политики IP-безопасности, правой кнопкой мыши щелкните на опции IP Security Policies on Local Machine (Политики IP- безопасности на локальном компьютере), а затем выберите опцию Create IP Security Policy (Создать политику IP-безопасности). В результате откроется окно мастера, показанное на рис. В.7. Для продолжения щелкните на кнопке <Next> (Далее).
H'M ДИШД'1Ш JLlfl,Eg—Bt^ ■.--i^
t; £oni* wvx>;m o*Q t# У * ВЭ жВи 2U
[^^,**' Vow (rg-t« | > - 6®,Q^ ^ ^^
Тгн | Sortos |1 Mey АйрюсI
^ТТв^^Тоаё””-”*!^^*^
M СКЯЯЕЯЖ2С5Е££121С311ЯНН1,K• ***** r»>*< ««иг** u^.. мо
*Mer*W IP f** b<> «d fUw oction> he. **W toepoe шм*у uw .. Mo
ХДТИз»
itR»wv*whMNi.i
Ne** Tespad vie*» .
tip»tUff...tip»tUff...Рис. B. 7. Окно мастера IP Security PolicyРис. B. 7. Окно мастера IP Security Policy
tip»tUff...
tip»tUff...
Рис. B. 7. Окно мастера IP Security Policy
Рис. B. 7. Окно мастера IP Security Policy
Введите имя новой политики безопасности, а также ее краткое описание, шелкните на кнопке <Next>, отмените установку флажка Activate Default Response Rule (Активизировать правило отклика, заданное по умолчанию), затем щелкните на кнопке <Next> еще раз. Оставьте установленным флажок Edit Properties (Свойства редактирования) и щелкните на кнопке <Finish> (Готово) (рис. В.8).
В результате выполнения перечисленных выше действий отображается окно, показанное на рис. В.9.
III I'HIINI Н ■■■■■■В^ ^^^
IP Security Poirv NwNew Ы aecwty poky erd «**n* p*r « 4 beN detoctonIP Security Poirv NwNew Ы aecwty poky erd «**n* p*r « 4 beN detoctoni^tcr^wi^tcr^w
IP Security Poirv Nw
New Ы aecwty poky erd «**n* p*r « 4 beN detocton
IP Security Poirv Nw
New Ы aecwty poky erd «**n* p*r « 4 beN detocton
i^tcr^w
i^tcr^w
швеишвеиReguetlt tot Secut £оммм:э1кжSpeciy htw lh» p*y (Wtpordt Kt IVWi «< tecW <У<г^чтж:аскГкReguetlt tot Secut £оммм:э1кжSpeciy htw lh» p*y (Wtpordt Kt IVWi «< tecW <У<г^чтж:аскГк
швеи
швеи
Reguetlt tot Secut £оммм:э1кж
Speciy htw lh» p*y (Wtpordt Kt IVWi «< tecW <У<г^чтж:аскГк
Reguetlt tot Secut £оммм:э1кж
Speciy htw lh» p*y (Wtpordt Kt IVWi «< tecW <У<г^чтж:аскГк
Tht detail rexponte л* *#>pnr>c < И iw <v» г.о«ЧМ* »IM <*э*з« WU*^ ***** m ex*ci Me ettes Tо u»4rrwc4e w**. •*> l Jiul^ »v^ t^x»^ti ted^Vi to tKvwco*vMne*cnTht detail rexponte л* *#>pnr>c < И iw <v» г.о«ЧМ* »IM <*э*з« WU*^ ***** m ex*ci Me ettes Tо u»4rrwc4e w**. •*> l Jiul^ »v^ t^x»^ti ted^Vi to tKvwco*vMne*cnРис. B.8. Создание новой политики IP-безопасностиРис. B.8. Создание новой политики IP-безопасности
Tht detail rexponte л* *#>pnr>c < И iw <v» г.о«ЧМ* »IM <*э*з« WU*^ ***** m ex*ci Me ettes Tо u»4rrwc4e w**. •*> l Jiul^ »v^ t^x»^ti ted^Vi to tKvwco*vMne*cn
Tht detail rexponte л* *#>pnr>c < И iw <v» г.о«ЧМ* »IM <*э*з« WU*^ ***** m ex*ci Me ettes Tо u»4rrwc4e w**. •*> l Jiul^ »v^ t^x»^ti ted^Vi to tKvwco*vMne*cn
Рис. B.8. Создание новой политики IP-безопасности
Рис. B.8. Создание новой политики IP-безопасности
Для создания политики с помощью ранее сконструированных фильтров щелкните на кнопке <Add>, затем на отобразившемся экране щелкните на кнопке <Next>.
В дальнейшем будут созданы два новых правила безопасности. Для удаленного маршрутизатора Cisco введите IP-адрес, который будет представлять конечную точку туннеля, по которому передаются данные в подсеть 10.10.10.0 (рис, В. 10).
В первом диалоговом окне, показанном на рис. В, 11, выберите опцию, которая обеспечивает ввод предварительного общего ключа. Поскольку может использоваться протокол Windows 2000 Kerberos или сертификаты Х.509, подобный тип ключа упрощает операции, выполняемые для данной копии операционной системы. Введите предварительный общий ключ, щелкните на кнопке <Next>, затем выберите первый список IP-фильтров, который был создан ранее (А-В).
Рис. В. 9. Изменение новых свойств политики IP-безопасности
Ы**-11(* *<#«h<*i4iki M.«o«*out* .<fF. .U •*-,**.*>> -Hi»*деоНу *y#e nt a awJ v;Mt i.xwiu w»*en rm$ лило»
$ev<#i wmi^^w i;ii*# jmH^M
l»w (Ji <>ж iw* •«* »hrr^i
<• )rwik#e»<Ki^rHe e^wi<«и< ty111’ p<k>>- •
197 . IGH . 100 .
*Ь*> { I • Cmee, • |
Puc. fi. /ft Настройки туннеля и сети
{.Iе-VtЯДДУГП———F^g»К .- -_/'/'
Autfcmlh.d™ Mnthnd То *М nN* *****tN*x» «ЛюЛ *»t#e«ri*l»** «йи у#н»й*у*е IP КфЦМуМА wv4 &* th»ir*W «udmtf«ггН^^МЬ» If»- »^м»г цй Г Wn*wi 3XX- jHe» * *t*<x VI pK*oeoi| Г ute*tellio»rraRt*!CefVa«»*viHowlCA!■
tl^lie- -‘nyl |t /* f Hwl^ v*«-«iy» l|ee<t*«M*1»»Yf
Puc. fi.//. Методы аутентификации и правила безопасности
Щелкните на кнопке <Next>, после чего появится диалоговое окно, показанное на рис. B. 12. В этом окне можно выбрать действие фильтра Require Security (Требуется безопасность), которое было показано на рис. В.5. В результате выполнения этого действия контролируется начало процесса достижения договоренности при использовании протокола IPSec.
Щелкните на кнопке <Next>. На следующем экране мастера (рис. В. 12) убедитесь в том, что не был установлен флажок Edit Properties (Редактирование свойств), затем щелкните на кнопке <Finish> (Готово). После этого будет осуществлен обратный переход в диалоговое окно основной политики безопасности.
Теперь потребуется установить второй фильтр, который применяется по отношению к трафику, передающемуся из подсети 10.10.10.0. Для этого щелкните на кнопке <Add>, затем на следующем окне мастера щелкните на кнопке <Next> (рис. В. 13),
Определите локальную точку завершения туннеля IPSec. Обратившись к рис. ВЛ, можно убедиться в том, что в роли локальной точки завершения выступает сетевой адаптер на сервере Windows 2000, который является ближайшим к маршрутизатору Cisco. Щелкните на кнопке <Next> (Далее).
Как и прежде, выберите опцию All Network Connections (Все сетевые подключения) и щелкните на кнопке ^exi:*. В появившемся диалоговом окне введите предварительный общий ключ.
После выбора второго фильтра (В-А, созданного ранее) щелкните на кнопках <Require Security* (Требуется безопасность), <Next> (Далее) и <Finish>.
Теперь в вашем распоряжении находятся два правила, настраиваемые подобным образом, которые обеспечивают контроль передаваемых между двумя сетями данных, На следующем этапе потребуется проверить настройки Key Exchange (Обмен ключей).
Рис. В. /2. Выбор действия фильтра
Эти настройки контролируют метод, с помощью которого начальные устройства, взаимодействующие друг с другом с помощью протокола IPSec, осуществляют аутентификаЦИЮ и коммуникацию ключей, требуемых для выполнения шифрования передаваемых данных. Доступ к этим настройкам осуществляется на вкладке General (Общие) страницы свойств, соответствующей новой созданной политике IP-безопасности (рис. В.14).
R*« |GroV|
8ГД Srcwi# । >* t kv <wrwi*m *r < w<h *« crnfuw:
r° 5vciM/fUrv
0- в□ Dyrwwc0- в□ Dyrwwc*tN*tNflawed Keyflawed Key£*£*Ю heЮ heI r*w*eh!i,iRt<f>rI r*w*eh!i,iRt<f>rDNeJ Reipcntvк Mbeto»DNeJ Reipcntvк Mbeto»Рис. B. 13. Создание второго правила IP-безопасностиРис. B. 13. Создание второго правила IP-безопасности
0- в
□ Dyrwwc
0- в
□ Dyrwwc
*tN
*tN
flawed Key
flawed Key
£*
£*
Ю he
Ю he
I r*w*eh!i,i
Rt<f>r
I r*w*eh!i,i
Rt<f>r
DNeJ Reipcntvк Mbeto»
DNeJ Reipcntvк Mbeto»
Рис. B. 13. Создание второго правила IP-безопасности
Рис. B. 13. Создание второго правила IP-безопасности
Доступ к настройкам обмена ключами становится возможным после щелчка на кнопке <Advanced> (Дополнительно). Три опции, находящиеся на этой вкладке, обычно контролируют процесс создания, частоту создания, а также время существования основного ключа.
После щелчка на кнопке <Methods> (Методы) обеспечивается доступ к диалоговому окну Key Exchange Security Methods (Методы обеспечения безопасности при обмене ключей). В этом диалоговом окне отображается перечень методов безопасности, исполыуемых для зашиты объектов при выполнении аутентификации и обмена ключей (рис. В.15).
Протокол обмена ключей Internet (IKE — Internet Key Exchange), который использовался в данном примере, представляет собой метод шифрования DES, объединенный с методом MD5. При этом также задействуется метод хеширования, применяемый данными ключами (алгоритм Диффи-Хелмана группы ((Diffie-Hellman Group !))■
И снова, настройка, находящаяся в верхней части списка, вероятнее всего будет использоваться совместно с маршрутизатором Cisco.
На этом настройка политики IP-безопасности сервера Windows 2000 завершена. На следующем этапе производится конфигурирование маршрутизатора Cisco.
егзяншшЕваЕил!^^
Сп** lfh*w В*_^ . .D G^ Q О • *ltfjy!
Qgiier* ^ t***^ ’ * - ЗЗ.'Й IX # С* tf el 5: ' 5 Jfrw f #*»»«« J ^tar# '(Линии«I1' —СQgiier* ^ t***^ ’ * - ЗЗ.'Й IX # С* tf el 5: ' 5 Jfrw f #*»»«« J ^tar# '(Линии«I1' —С
Qgiier* ^ t***^ ’ * - ЗЗ.'Й IX # С* tf el 5: ' 5 J
frw f #*»»«« J ^tar# '(Линии«I1' —С
Qgiier* ^ t***^ ’ * - ЗЗ.'Й IX # С* tf el 5: ' 5 J
frw f #*»»«« J ^tar# '(Линии«I1' —С
po«5" ftw*wnpo«5" ftw*wnri*M W*«*. IK (li f 3<C fQ to 140ri*M W*«*. IK (li f 3<C fQ to 140вязвавпанеевезз1-:. дшг ЕчЕйЗИЗЕяЗЕйяД *#«Уг Ne id grrw*** a rew к»), dM> •*»,F м-MHteeMiwil дегеии • new See ** e*y lerurtii* dwo d«rt«w •*#w» woA •**«*y^nwh JIrlwnei f лу Cerheny t>l) U X*db*n ЖЛ kr*f devetond by Ыьнж* w>3 CwoSyileni. lidвязвавпанеевезз1-:. дшг ЕчЕйЗИЗЕяЗЕйяД *#«Уг Ne id grrw*** a rew к»), dM> •*»,F м-MHteeMiwil дегеии • new See ** e*y lerurtii* dwo d«rt«w •*#w» woA •**«*y^nwh JIrlwnei f лу Cerheny t>l) U X*db*n ЖЛ kr*f devetond by Ыьнж* w>3 CwoSyileni. lidPuc. В. 14. Страница свойств политики IP-безопасностиPuc. В. 14. Страница свойств политики IP-безопасности
po«5" ftw*wn
po«5" ftw*wn
ri*M W*«*. IK (li f 3<C fQ to 140
ri*M W*«*. IK (li f 3<C fQ to 140
вязвавпанеевезз1-:. дш
г ЕчЕйЗИЗЕяЗЕйя
Д *#«Уг Ne id grrw*** a rew к»), dM> •*»,
F м-
MHteeMiwil дегеии • new See ** e*y lerurtii
* dwo d«rt«w •*#w» woA •**«*
y^nwh J
Irlwnei f лу Cerheny t>l) U X*db*n ЖЛ kr*f devetond by Ыьнж* w>3 CwoSyileni. lid
вязвавпанеевезз1-:. дш
г ЕчЕйЗИЗЕяЗЕйя
Д *#«Уг Ne id grrw*** a rew к»), dM> •*»,
F м-
MHteeMiwil дегеии • new See ** e*y lerurtii
* dwo d«rt«w •*#w» woA •**«*
y^nwh J
Irlwnei f лу Cerheny t>l) U X*db*n ЖЛ kr*f devetond by Ыьнж* w>3 CwoSyileni. lid
Puc. В. 14. Страница свойств политики IP-безопасности
Puc. В. 14. Страница свойств политики IP-безопасности
Рис. В. 15. Методы обеспечения безопасности при выполне-нии обмена ключеи
Конфигурирование Cisco IPSec
Стандартный процесс установки и конфигурирования маршрутизатора Cisco не относится к предметной области данной книги. В связи с этим в разделе рассматриваются исключительно компоненты файла настройки, имеющие отношение к протоколу IPSec.
После включения электропитания либо перезагрузки маршрутизатора Cisco производится загрузка операционной системы из флэш-памяти. В результате этого определяются стандартные настройки маршрутизатора. Поскольку для каждого маршрутизатора требуется определение индивидуальных настроек, ОС маршрутизатора считывает их из файла конфигурации. Доступ к этому файлу в обычном режиме (и считывание данных) невозможен, но он может редактироваться с ПОМОЩЬЮ редактора в стиле командной строки.
Первый раздел файла конфигурации содержит начальную информацию для IKE. В результате выполнения команды Crypto IsakmpPolicy 100 создается новая политика аутентификации IKE. В условиях этой политики можно определять параметры, необходимые для достижения договоренности с другим устройством IPSec. В конце команды можно использовать любое число, которое изменяется в пределах от 1 до 10000. Это число указывает приоритет записи по отношению к подобным записям. Можно также создать различные записи, имеющие разные уровни шифрования для отличающихся подключений.
Для методов шифрования и аутентификации могут быть оставлены стандартные настройки (DES и SHA). В рассматриваемом примере используется стандартный метод шифрования DES совместно с алгоритмом хеширования MD5. Можно также использовать метод шифрования 3DES совместно с SHA, однако эти настройки соответствуют тем настройкам, которые устанавливаются для политики IP-безопасности Windows 2000.
Команда Pre-Share настраивает протокол IKE с учетом использования вручную определенных ключей для данного подключения. Также можно воспользоваться опцией RSA-Sig, которая позволяет применять сертификаты Х.509, предоставленные центром выдачи сертификатов (СА). Когда устройство IPSec, которому назначен IP- адрес, предпринимает попытки создания ассоциации безопасности (SA), два компьютера начинают процесс переговоров, основываясь на значении предварительного общего ключа, сконфигурированного для использования обеими системами.
Как отмечалось ранее, маршрутизатор может быть сконфигурирован для использования сертификатов, которые связаны с парами предварительно созданных ключей RSA и могут быть настроены для применения с ПОМОЩЬЮ одного из следующих методов.
Без СА (НС), маршрутизатор аутентифинирует сам себя при работе с устройством IPSec, используя созданные вручную зашифрованные ключи RSA Этот метод требует предварительного создания ключей и копирования общедоступного компонента между двумя устройствами.
Вместе с 04, маршрутизатор аутентифицирует сам себя на удаленном устройстве путем отсылки сертификата этому устройству. Каждое устройство должно отсылать свой собственный сертификат, который был выдан и проверен СА. Этот процесс является функциональным в силу того, что каждый сертификат устройства IPSec инкапсулирует общий ключ маршрутизатора RSA. Каждый сертификат аутентифицируется СА, а все задействованные маршрутизаторы распознают СА в качестве агентства по авторизации. Подобный процесс именуется IKE с сигнатурой RSA.
Метод, используемый при обмене информацией между маршрутизатором Cisco и СА, именуется протоколом регистрации сертификатов (СЕР — Certificate Enrollment Protocol). Центр СА должен поддерживать протокол СЕР с целью автоматизации процесса регистрации; если этот протокол не поддерживается, должен применяться метод регистрации вручную. Этот процесс может выполняться путем создания запроса формага PKCS 10 (вручную или на основе файла). Такой запрос может быть отправлен по
электронной почте или передан СА вручную (на дискете). Сертификат генерируется на базе запроса, который может отсылаться обратно устройству IPSec и импортироваться.
Для генерирования ключей RSA воспользуйтесь следующими командами (перед этим перейдите в режим конфигурирования командной строки маршрутизатора):
crypto key generate rsa [используемые-клавиши]
Для отображения генерируемых клавиш RSA воспользуйтесь следующей командой: show crypto key mypubkey rsa
Операционная система IOS, использующая Cisco IPSec, может запрашивать сертификаты у Microsoft, VeriSign, Netscape и доверенных центров СА.
Центры СА также могут аннулировать сертификаты для устройств, которые больше не используют протокол IPSec. Аннулированные сертификаты не распознаются как корректные другими устройствами IPSec. Аннулированные сертификаты перечислены в списке аннулирования сертификатов (CRL — Certificate Revocation List). В этом списке может проверяться каждый узел перед тем, как будет принять другой сертификат узла.
Прилн'чшше
Протокол СЕР был разработан в качестве протокола управления сертификатами фирмами Cisco и VeriSign. Он представлял собой раннюю реализацию синтаксиса запроса сертификатов (CRS -- Certificate Request Syntax), который входит в число стандартных предложений Инженерной группы решения конкретной задачи Internet (IETF — Internet Engineering Task Force). Протокол СЕР определяет, каким образом устройство взаимодействует с СА. При этом также указывается порядок выборки открытого ключа С/4, метод регистрации устройства СА, а также методика выборки CRL. Протокол СЕР использует криптографические стандарты открытого ключа RSA (PKCS) 7 и 10 в качестве технологий компонентов ключей. Рабочая группа инфраструктуры открытого ключа IETF (PKIX) проводит работу в области стандартизации протокола, выполняющего функции CRS либо эквивалентные, Когда стандарт IETF стабилизируется, Cisco добавит для него поддержку.
В следующем фрагменте кода демонстрируются команды, которые используются для конфигурирования маршрутизатора с учетом применения политики криптографии для начального шифрования и ведения переговоров относительно аутентификации. При этом используется хеширование и форма криптографии в виде справочных сообщений. Начальные переговоры защищаются и шифруются с помощью "предварительного общего пароля thisisatest. В данном случае осуществляются коммуникации с другим устройством IPSec, имеющим IP-адрес 192.168.100.1.
crypto isakmp policy 100 hash md5
authentication pre-share
crypto isakmp key thisisatest address 192.168.100.1 I
В следующем фрагменте кода приводится пример команд, которые могут реализовывать применение ключевых пар RSA:
crypto isakmp policy 101 hash md5
authentication rsa-sig
Набор трансформации определяет правила, которые будут применяться при аутентификации и шифровании данных, передаваемых между устройствами IPSec. Эти данные могут представлять собой комбинацию интеграции данных и адреса без использования шифрования (АН), а также интеграции данных с шифрованием (ESP).
В следующем перечне описываются доступные комбинации опций шифрования и аутентификации, имеющиеся в текущей версии Cisco IOS:
ah-md5-hmac ah-sha-hmac
Трансформация AH-HMAC-MD5
Трансформация AH-HMAC-SHA
comp-lzs
esp-des esp-md5-hmac esp-null esp-sha-hmac
IP-сжатие, использующее алгоритм сжатия LZS
Трансформация ESP с помощью шифра DES (56 битов)
Трансформация ESP с помощью аутентификации HMAC-MD5
Трансформация ESP без применения шифра
Трансформация ESP с помощью аутентификации HMAC-SHA
В следующем
примере кода производится конфигурирование маршрутизатора, в
результате чего предлагается либо осуществляется договоренность относительно двух различных типов шифрования (из предыдущего списка):
crypto ipsec transform-set SEC-TEC esp-des esp-md5-hmac
Команда crypto map вызывает ранее созданный набор трансформации, а также связывает его с другим устройством IPSec и списком доступа. В этом списке определяется поток данных между указанными подсетями:
I
crypto map SEC-TEC-MAP 10 ipsec-isakmp
set peer 192.168.100.1
set transform-set SEC-TEC
match address 101
access-list 101 permit ip 172.16.9.0 0.0.0.255 10.10.10.0 0.0.0.255 access-list 101 permit ip 10.10.10,0 0.0.0.255 172.16.9.0 0.0.0.255
В последнем разделе просто связывается определенная карта шифрования с соответствующим интерфейсом Ethernet:
i
interface EthernetO/O
ip address 192.168.100.2 255.255.255.0
no ip diiected-broadcast no ip reroute-cache
crypto map SEC-TEC-MAP
Тестирование
Перед тем, как будет реализована любая конфигурация IPSec, потребуется протестировать инсталляцию сети, таблицы маршрутизации и настройки клиентского IP- адреса. В ходе тестирования можно удостовериться в том, что требуемые коммуникаЦИИ между подсетями действительно имеют место. Процесс эхо-тестирования может быть начат с клиента в одной подсети в направлении клиента, относящегося к другой подсети (в данном случае может использоваться утилита tracert). После того, как системы Cisco и Windows 2000 были сконфигурированы и активизированы, потребуется повторить тестирование. В результате вы можете убедиться в том, что сетевые подключения по-прежнему существуют.
Воспользуйтесь утилитой IpsecmonH файлом Oakley.logc целью мониторинга процесса инициализации и создания ассоциаций ключей безопасности. Благодаря этому, администратор может осуществлять мониторинг фактической активности, имеющей отношение к IPSec. а также проверять корректность выполняемых в этом случае действий. Если сервер поддерживает несколько туннелей, что является типичным для многих конфигураций, важно присвоить им отдельные имена. В этом случае туннели могут быть легко идентифицированы путем просмотра с оответствующе й туннельной информации с помощью утилиты IPSecmon.
Для проведения дальнейшего тестирования потребуется подключить хаб к подсети 192.168.100.0, что позволяет подключить третий компьютер, на котором выполняется инструментальное средство Microsoft Network Monitor. В результате у вас появляется возможность перехватывать пакеты, циркулирующие между клиентами I и 3 (клиенты находятся в отдельных подсетях; для получения дополнительных сведений обратитесь к рис. В.1). Этот тест должен быть выполнен до и после конфигурирования туннеля IPSec.
Дейтаграммы IPSec и IP
В настоящий момент времени протокол IPSec может применяться только по отношению к однонаправленным 1Р-дейтаграммам. Поскольку рабочая группа IPSec все еще не может работать с распределениями групповых ключей, протокол IPSec не может работать с широковещательными IP-дейтаграммами.
Если используется трансляция сетевых адресов (NA Т — Network Address Translation), можно конфигурировать статические трансляции NAT, что позволяет обеспечить корректное выполнение протокола IPSec. Как правило, трансляция NA Т может выполниться до того, как маршрутизатор выполняет инкапсуляцию IPSec; говоря другими словами, IPSec должен обрабатывать глобальные адреса.
Ниже показан полный файл конфигурации Cisco, который используется маршру- тIизатором Cisco 3600 в данном тестовом сценарии:
version 12,0
service timestamps debug uptime
service timestamps log uptime
service password-encryption
hostname Crypto i
enable secret 5 $1$X3.0$lJ8mP8t8PbJeXaPnSihah/
enable password 7 09434D1A1006
I
ip subnet-zero
ip domain-list sec-tec.net
ip domain-name sec-tec.net
ip name-server 172.16.9.1 !
crypto isakmp policy 100
hash md5
authentication pre-share
crypto isakmp key thisisatest address 192.16B.100.1 i
crypto ipsec transform-set 5EC-TEC esp-des esp-mdS-hmac
crypto map SEC-TEC-MAP 10 ipsec-isakmp
set peer 192.16B.100.1
set transform-set SEC-TEC
match address 101
interface EthernetO/O
ip address 192.166.100.2 255.255.255.0
no ip directed-broadcast
no ip mroute-cache
crypto map SEC-TEC-MAP
interface Serial0/0
no ip address
no ip directed-broadcast
no ip mroute-cache
shutdown
i
interface Ethernetl/0
ip address 10.10.10.1 255.255.255.0
no ip directed-broadcast
no ip mroute-cache !
ip default-gateway 192.169.100.1
ip classless
ip route 172.16.9.0 255.255.255.0 192.168.100.1 i
access-list101 permitip172,16.9.0 0.0.0.25510.10.10.00.0.0.255
access-list101 permitip10.10.10.0 0.0.0.255172.16.9.00.0.0,255
j
line con 0
exec-timeout О О
password 7 00071A150754
login
transport input none
line aux 0
line vty 0 4
password 7 070C285F4D06
login
end
Резюме
Устройства Cisco могут быть сконфигурированы для использования протокола L2TP/IPSec или IP Sec в туннельном режиме. Поскольку для туннельного режима протокола IPSec в Windows 2000 присуши некоторые ограничения, по возможности используйте L2TP/IPSec. Возможности конфигурирования туннельного режима IPSec позволяют администраторам обеспечивать успешное взаимодействие между любыми продуктами IPSec, совместимыми со стандартами IETF.
Перспективы развития сетевых технологий и VPN
Сетевые технологии являются одним из наиболее динамических направлений развития в компьютерной индустрии. Благодаря созданию операционной системы Windows 2000, технологии VPN совершили гигантский прорыв и заняли достойное место. Последующие версии продуктов семейства Windows 2000 приведут к упрочению позиций, завоеванных этим программным продуктом.
Одна из наиболее важных сетевых возможностей состоит в совмещении всех типов коммуникативных технологий для поддержки единой базисной структуры. Путем интегрирования в Active Directory все большего числа программных продуктов можно выполнять централизованное конфигурирование сетевых решений. При этом репликация Active Directory используется в качестве ссылки на параметры конфигурирования.
Если вы выполняете функции архитектора сети, убедитесь в том, что современные сетевые разработки поддерживают перспективные технологии, связанные с VPN. К сожалению, даже если вы четко представляете направления развития этих технологий, невозможно точно наметить пути развития конкретной инфраструктуры. Однако использование научных предположений позволяет более уверенно ориентироваться в этом вопросе.
Прогноз развития VPN и направления совершенствованияWindows
Для более успешного прогнозирования направлений развития сетевых технологий желательно познакомиться с документами RFC. В этом приложении рассматриваются в об- ших чертах некоторые из направлений, которые могут быть реализованы уже в ближайшем будущем. Подобно всем прогнозам, приведенный перечень не может претендовать на точность, поскольку некоторые из направлений могут не реализоваться на практике. Кроме того, могут быть созданы новые технологии, которые не попали в данный перечень.
В задачи этого приложения не входит обсуждение технологических особенностей. Необходимо обратить внимание читателя на то, что лучшим является сетевой Проект, который может применяться с программным обеспечением следующего поколения и отвечать запросам клиентов. К сожалению, в мире компьютерных технологий этого трудно достичь. Если вы не занимаетесь прогнозированием возможных изменений, вероятнее всего, вы попытаетесь повторно внедрить имеющуюся технологию. А этот путь предполагает большие затраты средств и времени. Следующий список содержит перспективные направления развития технологий VPN.
Возможности по коммуникации Active Directory с использованием сетевых устройств. Это направление коренным образом изменяет методику обработки конфигураций
узлов и служб. До последнего времени администратор Active Directory вынужден в ручном режиме указывать каталог для сетевой инфраструктуры. Если Active Directory сможет взять на себя эту задачу, администратору узлов и служб останется только при необходимости изменить значения настроек.
Всесторонняя и улучшенная поддержка туннельного режима IPSec в будущих версиях Windows. В Windows 2000 поддерживается туннельный режим IPSec, но при его использовании имеется ряд недочетов. Основной недостаток состоит в том, что служба RRAS не просматривает интерфейс после определения политики IPSec. После реализации усовершенствований значительно облегчается маршрутизация и конфигурирование туннеля IPSec.
ДоступностьL2TP/lPSecдлясемейства Windows9x.Еслисотрудникивашейкор
порации пожелают использовать протоколы L2TP/IPSec, все серверы и клиенты должны применять операционную систему Windows 2000 или более позднюю версию. Поэтому пользователи Windows 9x имеют существенное преимущество. Либо компания Microsoft, либо сторонние производители, возможно, уже в ближайшее время выйдут на рынок с решением для клиентов Windows 9x/Millennium.
Улучшенная поддержка опции DHCP, поддерживающей информацию, связанную с маршрутизацией. При передаче маршрутов туннельные клиенты практических приложений не могут пользоваться опцией 33 (указывается список статических маршрутов, инсталлированных клиентом в клиентском кэше; не поддерживается маска подсети). Все больше и больше корпораций обращаются к решениям, связанным с клиентской маршрутизацией. Эта опция применяется очевидным образом для диверсификации клиентской среды. Однако желательно, чтобы для поддержки маршрутизации и информации о маске подсети использовалась новая опция. В этом случае значительно возрастает гибкость, достигаемая при использовании конфигурации туннельного клиента. Если эта опция поддерживается другими операционными системами, они также оказываются в выигрыше.
Улучшенная клиентская поддержка для протокола "точка-точка" поверх Ethernet (РРРоЕ). Поскольку все большее число клиентов применяют технологии типа DSL, чрезвычайно важно располагать стандартным подходом для поддержки некоторых требований, проявляющихся в данном случае. Многие реализации DSL являются зависимыми от стандарта РРРоЕ. В этом случае требуется программные подключаемые модули, но в настоящее время отсутствуют реальные стандарты, описывающие детали реализации клиента.
Более эффективная поддержка инструментария управления Windows (WMI) для клиентов. В современных средах VPN требуется поддержка и управление для подключенных клиентов. По мере развития этой технологии продолжает улучшаться степень управляемости. Обычно сетевой администратор должен располагать инструментарием, основанным на WMI, для осуществления нентрализо- ванного конфигурирования и мониторинга серверов и клиентов.
Улучшение решений, обеспечивающих регистрацию клиентов. Будут усовершенствованы клиентские подключения и управление соответствующими журналами с целью улучшения поддержки распределенной среды.
Дополнительные свойства диспетчера подключений. Текущая реализация диспетчера подключений имеет свои недостатки, проявляющиеся для удаленных подключений. В этом случае должны обеспечиваться такие возможности, как полная поддержка модемов ISDN, обратный вызов, а также некоторые другие возможности. Кроме того, вполне возможно, что в будущих версиях диспетчера подключений будут реализованы некоторые моменты технологии нулевого администрирования Windows (ZAW — Zero Administration for Windows). Гибкость диспетчера подключений позволяет реализовать любое количество новых свойств, которые приведут к увеличению степени гибкости и появлению новых возможностей для клиентов.
Дальнейшая разработка среды IPSec. Среда IPSec будет продолжать развиваться с целью оптимизации производительности, включая полную поддержку среды QoS,
поддержку балансировки сетевой нагрузки, а также внедрение решений, обеспечивающих использование IPSec для передачи данных через устройства, совместно использующие подключения к Internet. В этом случае также будет разрешена проблема создания заказных политик IPSec, обеспечивающих коммуникации служб операционной системы. Кроме того, среда IPSec будет поддерживать улучшенный пользовательский интерфейс, включая мониторинг в режиме реального времени, улучшенное отслеживание событий, счетчики Performance Monitor, а также некоторые наиболее часто применяемые решения регистрации.
Решение, обеспечивающее передачу трафика L2TP/IPSec через сервер NAT. Эта проблема может решаться с помощью различных методов, но при этом нужно учитывать необходимость обработки этого вида трафика без нарушения безопасности. Данный вопрос рассматривается во многих документах RFC. Однако до разрешения этой проблемы весь трафик, передаваемый через стандартное общее устройство, основанное на NAT, будет блокироваться протоколом РРТР.
Дальнейшее развитие среды L2TP/IPSec. В ходе дальнейшего развития среды обеспечивается оптимизация производительности путем реализации полной поддержки решения QoS для клиентских туннелей, что со временем приведет к включению поддержки сжатия заголовков L2TP с целью уменьшения накладных расходов, направленных на поддержку туннелей.
Диагностика модема, основанная на протоколе RADIUS. Это свойство включено в состав многих современных решении. и фирма Microsoft будет включать его во многие будущие версии. В результате администраторы могут лучше управлять серверами удаленного доступа путем регистрации причин сбоев вызовов, а также показателей производительности сетей VPN (с помощью протокола RADIUS).
Поддержка сжатия заголовков транспортного протокола в режиме реального времени (документы RFC 2508 и 2509). В этом случае обеспечивается улучшенное использование полосы пропускания для низкоскоростных каналов связи.
Полная реализация групповых протоколов маршрутизации. Хотя Windows 2000 включает ограниченную поддержку групповой рассылки с помощью прокси-службы Multicast, важно обеспечить полную поддержку этого алгоритма. В этом случае операционная система может выступать в роли маршрутизатора в инфраструктуре, обеспечивающей групповую рассылку. В результате обеспечивается полная поддержка развертывания групповых приложений, что становится уж традиционным.
Большая степень гибкости сертификатов. Операционная система Windows 2000 использует стандартные сертификаты. При использовании некоторых серверов сертификатов сторонних производителей проявляется ряд недостатков. Возможно, индустрии следует оказать "давление" на Microsoft с целью облегчения использования иных типов сертификатных серверов, а также улучшения их интеграции с другими операционными системами.
Улучшение взаимодействия с другими маршрутизаторами. Под этим подразумевается использование некоторых Web-инструментов; маршрутизаторы могут управляться таким образом, что маршрутизатор в следующей версии Windows будет выглядеть как "просто другой маршрутизатор."
Продолжение процесса интеграции технологий телефонии. В настоящее время становится нормой включение функциональных свойств телефонии в состав компьютерных технологий. Вполне вероятно, что скоро появятся телефоны USB, которые будут использоваться в качестве "надстройки" над другими типами подключений —VPN или Internet.
И снова следует отметить, что настоящий список не претендует на полное описание свойств, которые могут проявиться в будущем. По моему мнению, изменения, относящиеся к сети, являются интересными, и о них стоит поговорить отдельно. Будем надеяться, что, используя эту информацию, вы сможете разрабатывать сети и решения VPN, которые смогут без проблем изменяться в случае появления новых технологий.
Предметный указатель
А
Active Directory, 50; 245; 259
С
Cisco IOS, 303
D
DMZ, 172
I
IP Protocol 50, 153
IP-протокол 50, 151
M
Microsoft Proxy, 172
P
Perfect Forward Secrecy, 41
w
Windows 2000 Resource Kit, 146
A
Автоматическое развертывание, 99
Агент ретрансляции SMTP, 273
Агентство
ARPA, 279
Алгоритм
DH группы 2, 160
DSA, 80
MD5, 303
RSA, 80
SHA, 80
SHA1, 158; 303
SPF, 227
Диффи-Хеллмана, 80
Диффи-Хелмана группы 1, 308
Ассоциация безопасности, 54
Атака
"человек посередине", 38
изменениеданных, 38
имитация адреса, 38
метод "грубого взлома", 38
ответная, 38; 42
отказ в обслуживании, 38
подбор паролей и атаки со словарем, 38
приводящая к раскрытию ключей, 38
проникновение хакеров во время сеанса
связи, 38
сетевой анализатор пакета, 38
социальная, 38
Аутентификация Kerberos, 272
Б
Безопасность, реализуемая по схеме "точка- точка", 34
Билет TGT, 122
Брандмауэр, 175
ISA, 175
В
Взаимосвязанные частные сети, 281
Виртуальная частная сеть, 21
Второй этап применения политики
удаленного доступа
права доступа, 211
Вызов удаленных процедур, 174
Г
Генератор
ISTG, 261
Главный контроллер домена, 259
Глоба1ьная сеть, 21
Гостевая аутентификация, 218
Граничный сервер, 34; 176
Групповая система, 255
д
Двунаправленный инициированный туннель, 238
Демультиплексор Kerberos, 272
Дескриптор
RID, 263
Динамический DNS, 56
Динамическое возобновление ключа, 159
Диспетчер
Replication Monitor, 262
подключений, 55; 149; 203; 233
Доставка пакетов, 152
Дочерний домен, 276
Е
Единственный мастер-домен гибких операций, 264
3
Заголовок
GRE, 174
Значение хеш-функции, 80
Зона безопасности, 37
И
Иерархия сертификатов, 83
Имя
FQDN, 237
Инициатор, 116
Институт инженеров по электротехнике и электронике, 283
Инструментальное средство
Knowledge Consistency Checker, 260
Интегрированное хеш-покрытие, 115
Интерфейс
Ethernet, 297
TAPI, 206
удаленного доступа по требованию, 149
Инфраструктура открытого ключа, 79
К
Код аутентификации сообщения, 80
Команда
Crypto Isakmp, 310
crypto map, 312
FTP
PORT, 174
IPConfig, 233
NETSH, 231
Pre-Share, 310
ROUTE, 231; 298
ROUTE ADD, 232
route print, 229
Компонент топологии узла
глобально уникальный идентификатор
сервера, 268
график использования связей узла.сети^ 270
затраты на связи узлов сети, 269
объект NTDS Settings, 269
подключение, 269
подсеть, 269
связи узлов сети, 269
серверный объект, 268
узел, 268
Консоль
ММС, 55
управления Microsoft, 299
Контроллер домена, 259
Контрольное сообщение L2TP, 152
Корневая иерархия, 83
Л
Линия цифровой подписки, 153
Локальный
компонентный сервер, 70
контроллер домена, 276
м
Маршрутизатор
Cisco, 297
Маршрутизация в Windows 2000, 225
IGMP, 228
Автостатическая маршрутизация, 227
по протоколу IGMP, 228
протокол RIP (для IP-сетей), 227
с определением кратчайшего маршрута, 227
статическая маршрутизация, 226
Мастер
RRAS Setup, 239
набора администрирования диспетчера подключений, 205
Межузловой туннель, 156
Межшлюзовый туннель, 156
Метод
IKE, 54
контроля
код CRC, 283
шифрования
CHECKSUM, 113
Модель
СОМ, 175
OSI, 22
уровень
LLC, 283
MAC, 283
канальный, 282
представления, 285
приложения, 285
сеанса, 284
сетевой, 283
транспортный, 284
физический, 282
репликации с несколькими мастер-доменами, 259
сети HappyVPN, 275
н
Набор
IEAK, 204
телефонных книг администрирования
диспетчера подключений, 149
О
Объект групповой политики, 87
Одноранговый контроллер домена, 276
Операция
Pull, 262
Push, 262
Определение имен
NetBIOS, 246
в среде Active Directory, 253
для домашней сети/филиала офиса, 248
для туннельных клиентов, 246
хоста, 246
Оптовое удаленное подключение, 218
Основной ключ PFS, 160
Ответчик, 116
Отзыв сертификатов, 86
п
Пакет
АН IPSec
поле
Next Header, 114
Payload Length, 114
Reserved, 114
Security Parameter Index, 114
Sequence Number, 114
DHCPREQUEST, 247
управления L2TP, 156
Первый этап применения политики удаленного доступа
Условия, 209
Перекрестная иерархия сертификатов, 84
Персональное хранилище, 87
Плата разгрузки, 1 [2
Подключаемый модуль
Local Users and Groups, 207
Sites and Services, 263
Подключение
ICS, 192
кабельного типа, 153
Подчиненный режим распространения в
Kerberos, 272
Политика удаленного доступа, 207
в Windows 2000, 209
Полномочия
LSA, 263
Полностью определенное доменное имя, 119
Потоковый шифр RC4, 62
Преобразование IP-адресов, 270
Приложение
Event Viewer, 93; 126
IPSecmon, 125; 164
1PSECPOL, 146
Network Monitor, 143; 163
Принудительный туннель, 34
Провайдер службы шифрования, 98
Проверка
отклика, 114
подлинности сертификата, 85
Проект Happy VPN, 50
Произвольный туннель, 34
Прокси-сервер, 169
SOCKS, 171
приложения, 170
Протокол
2ТР, 22
Apple Talk, 22
ВАР, 214
ССР, 62
СЕР, 310
CHAP, 60; 151; 218
DHCP, 229
ЕАР, 23; 61; 88; 151; 218
ESP, 52
FTP, 172
GRE, 51; 61
ICMP, 172
ICS, 55
[KE, 158; 308
IP, 22
[PSec, 22; 53; 59; 110; 149; 175; 242
AH, 110
ESP, 110
IKE, 110
IPX, 22
Kerberos, 80
L2F, 22; 149
L2F, 52
L2TP, 52; 59; 149; 242
LCP. 60
LDAP, 95; 175; 256; 264; 272
MPPE, 62; 151
MS-CHAP, 60; 151; 218
NAT, 54
NCP, 60; 150; 280
OSPF, 57; 226
PAP, 60; 218
PPTP, 22; 51; 59; 149
RADIUS, 23; 156; 217
RIP, 57; 226
RRAS, 119
RSVP, 112; 124
SMTP, 273
SNMP, 175
SPAP, 62
SRA, 26
SSL, 117
TCP, 151
TCP/IP, 280
UDP, 151
P
Развертывание сертификатов вручную, 100
Рассылка
многоабонентская, 112
широковещательная, 112
Регенерация ключа, 159
Регистрация сертификатов, 84
Редактор NAT, 173
Режим без поддержки
истории, 66
состояния, 66
Репликация, 260
на уровне атрибутов, 260
С
Сеансовая служба NetBIOS, 272
Сервер
BHS, 261
DDNS, 245
IAS, 207
Internet Security and Acceleration, 187
Microsoft Internet Authentication Server, 156
Microsoft Proxy Server, 169
NAT, 150; 169; 373; 229; 270
RADIUS, 217
лавинной адресации, 39
паролей Kerberos, 272
регистрации пользователей Kerberos, 272
сертификатов, 55; 79
НС, S3
Сервер телефонных книг, 204
Сертификат
Х.509, 81
Для конечных компонентов, 82
Подчиненный ЦС, 82
Регистрации авторизации, 82
С автоподписью, 82
Сетевой анализатор пакетов, 40
Сеть
ARPANET, 280
CSNET, 280
MILNET, 280
NSFNET, 280
VPN
документы RFC, 285
Система
DDNS, 245
DNS, 245
NetBIOS, 245
Сканер порта, 294
Служба
ANI, 218
DHCP Allocator, 177
DNIS, 218
IAS, 217
ICS, 176
NAT, 116; 187
RADIUS, 203
RIP Listener, 227
RRAS, 47; 55; 149; 209; 236
TLS, 26
WINS, 245
дейтаграмм NetBIOS, 272
каталогов пользователей, 87
преобразования имен NetBIOS, 272
Соглашение по обмену ключей, 155
Сообщение
PKCS #10, 85
Список отозванных сертификатов, 86
Среда
CIDR, 227
Срочная репликация, 260
Active Directory, 263
Стандарт
DES,26
IPv4, ПО
IPv6, ПО
Open Database Connectivity, 218
QoS, 57
Стандартный порядок определения имен, 246
Статический маршрутизатор, 226
T
Технология
APIPA, 237
МРРЕ, 51
SSL, 27
Транзитный участок, 289
Третий этап применения политики удаленного доступа профиль, 212
Туннель, 33
Туннельный
клиент, 33
сервер, 33
У
Удаленная сетевая обработка, 149
Утилита
Ipsecmon, 313-
Network Monitor, 294
PPTPCLNT.exe, 291
PPTPSRV.exe, 291
repadmin, 262
Tracert, 290
Ф
Файл
Oakley.log, 313
конфигурации Cisco, 313
Файловая система EPS, 80
Фильтр
блокирующий, 112
обычный, 112
пропускающий, 112
Фильтрация пакетов, 239
Фрейм РРР, 60
X
Хеширование, 80
Хранилище
доверия, 87
сертификатов, 87
ЦС, 87
Ц
Центр
распределения ключей, 123
сертификации, 80; 82
Цифровая подпись, 81
ЦС
изолированный корневой, 90
изолированный подчиненный, 90
корневой предприятия, 90
подчиненный предприятия, 90
ш
Шифрование
DES,157
L2TP, 157
методом открытого ключа, 80
методом симметричного ключа, 80
тройной DES, 157
э
Экранируемая подсеть, 172
Научно-популярное издание
Тадеуш Фортенбери
Проектирование виртуальных частных сетейв среде Windows 2000
Литературный редактор Т. Т. Шматко
Верстка К. В. Самоцветов
Художественный редактор Е, П. Дынник
Технический редактор Г.Н. Горобец
Корректоры Л.А. Гордиенко, О. В. Мишутина
Издательский дом “Вильямс”.
101509, Москва, ул. Лесная, д, 43, стр. 1.
Изд. лиц. ЛР № 090230 от 23.06.99
Госкомитета РФ по печати.
Подписано в печать 16.01.2002. Формат 70x100/16.
Гарнитура Times. Печать офсетная.
Усл. печ. л. 25,8. УЧ.-изд. л. 22,54.
Тираж 4000 экз. Заказ № 2690.
Отпечатано с диапозитивов в ФГУП "Печатный двор"Министерства РФ по делам печати,телерадиовещания и средств массовых коммуникаций.
197110, Санкт-Петербург, Чкаловский пр., 15.
частных сетей в средечастных сетей в среде
частных сетей в среде
частных сетей в среде
Проектирование виртуальных
WINDOWS 2000
ISBN 5-8459-0240-1ISBN 5-8459-0240-19 "785845"90240519 "785845"9024051020 1 0020 1 0Издательскийдом*Вильямс'Издательскийдом*Вильямс'
ISBN 5-8459-0240-1
ISBN 5-8459-0240-1
9 "785845"9024051
9 "785845"9024051
020 1 0
020 1 0
Издательскийдом
*Вильямс'
Издательскийдом
*Вильямс'
“Дискуссия о ропи и месте технопо- гий в структуре Windows 2000 является весьма захватывающей. Здесь можно найти технические подробности и примеры, позволяющие читателю лучше понять суть технологий Windows 2000, используемых при развертывании сетей VPN. Если вы применяете виртуальные частные сети на основе Windows 2000, то эта книга для вас".
Мэнди Андресс, исполнительный директор и основатель компании ArcSec Technologies, Inc.
Тадеуш Фортенбери, имеющий степени MCSE и МСТ, является ведущим специалистом в обпасти виртуальных частных сетей, реализованных на платформа Windows. Будучименеджеромпро- грамм в фирме Compaq, он занимается разработкой глобальныхспецификаций процессатуннели- рования и развертывания туннельных серверов. Тадеуш выполнял разработки в среде Windows NT, начиная с момента появпения первой версии этой операционной системы. Он также выполнял функции консультанта в обпасти технической поддержки по сетям и виртуальным частным сетям в рамках программы Windows 2000 Rapid Deployment Program фирмы Microsoft. Тадеуш принимал участие в развертывании и администрировании Qtest Active Directory фирмы Compaq (вторая по масштабности предварительная версия Windows 2000 Active Directory). Помимо этого он играп ключевую роль при разработке испытательной сети HappyVPN (вариант развертывания Active Directory, полностью основанный на связях VPN, использующих технологии туннелирования Windows 2000).
Неш\
Riders 1
Publishing
С появлением технологий сетей VPN в Windows 2000 проектировщики сетей и сетевые администраторы попучипи в свои руки средство проектирования, позволяющее сэкономить деньги, облегчить администрирование и техническую поддержку сетей, а также решить проблемы, связанные с передачей данных по сетевым каналам связи. Книга Проектирование виртуальных частных сетей в среде Windows 2000 является простым пошаговым руководством, позволяющим реапизовать решения сетей VPN в рабочей обпасти.
Здесь вы найдете:
сценарии изреальной жизни, актуальные проекты, а также документацию по различным туннельным решениям, включая сложные удаленные конфигурации локальных сетей для филиалов и домашних офисов;
анализ распространенных конфигураций прокси-серверов, серверов NAT и брандмауэров, имеющих отношение к сетям VPN;
пошаговые процедуры, позволяющие сконфигурировать протоколы L2TP, РРТР и IPSec.
ля проектировщиков сетей, администраторов Windows 2000 и службы технической поддержки книга Проектирование виртуальных частных сетей в среде Windows 2000 является авторитетным изданием, которое может оказать помощь при решении перечисленных ниже проблем:
развертывание и конфигурирование технологий VPN, включая сертификаты, политики удаленного доступа, сложную маршрутизацию, фильтрацию и эффективное определение имен;
развертывание среды Active Directory, использующей исключитепьно сети VPN;
конфигурирование клиентов в средах, не относящихся к Windows (например, устройства Cisco), дпя работы с туннельным сервером Windows 2000.
Категория: Windows 2000/Безопасность/ Виртуальные частные сети
www.newriders.com
www.williamspublishing.com
1. Создайте пользовательскую консоль управления (ММС — Microsoft Management Console) с целью включения сертификатов для локального компьютера, подключаемого модуля Local Computer Policy (Политика локального компьютера) и политик IP-безопасности для локального компьютера (рис. 6.8).
2. Чтобы наблюдать за эффективностью применения политики IPSec, запустите приложение IPSecmon, выбрав команду Start C> Run (Пуск =» Выполнить) и введя IPSecmon в окне Run (Выполнить). Щелкните на кнопке <OK>. Щелкните на кнопке s:Options> (Параметры) и измените заданный по умолчанию интервал обновления с 15 секунд до 1 секунды. Минимизируйте окно монитора.
3. При тестировании политик IPSec желательно включать политику аудита, в результате чего можно будет легко определить успех или неудачу при реализации соглашения IPSec. В левой панели ММС щелкните дважды на имени локальной ком-