Книги, научные публикации
Pages: | 1 | ... | 3 | 4 | 5 | 6 | 7 | ... | 13 | Internetworking Guide Microsoft Windows 2000 Server R Microsoft Press Межсетевое взаимодействие Microsof Windows 2000 Server ...
-- [ Страница 5 ] --Если отвечающий маршрутизатор под управлением Windows NT 4.0 с Service Pack 4 и выше является членом домена Windows 2000 смешанного режима или если отвечающий маршрутизатор под управлением Windows 2000 включен в домен Windows NT 4.C, считывающий параметры пользовательских учетных за писей из доверяемого домена Windows 2000, проверьте, включена ли группа Everyone (Все) в группу Pre-Windows 2000 Compatible Access, Для этого вос пользуйтесь командой net localgroup Pre-Windows 2000 Compatible Access.
В случае отрицательного результата введите команду net localgroup Pre Windows 2000 Compatible Access everyone /add на контроллере домена и пе резагрузите его.
Если отвечающий маршрутизатор под управлением Windows NT 4.0 с Service Pack 3 и ниже является членом домена Windows 2000 смешанного режима, убе дитесь, что группе Everyone (Все) предоставлены права на перечисление содер жимого (list contents), чтение псех свойств (read all properties) и чтение (read) до корневого узла Вашего домена и всех подобъектов (sub-objects) корневого домена.
В случае аутентификации через RADIUS проверьте, взаимодействует ли компь ютер отвечающего маршрутизатора с сервером RADIUS.
Если отвечающий маршрутизатор использует аутентификацию через Windows и является членом домена Windows 2000 смешанного режима, который обнов ляется до домена основного режима, Вы должны перезагрузить компьютер от вечающего маршрутизатора Ч только после этого отвечающий маршрутизатор сможет успешно аутентифицировать удостоверения вызывающего маршрутиза тора и клиентов удаленного доступа.
Если служба факсов и служба маршрутизации и удаленного доступа совместно используют один модем, проверьте, поддерживает ли этот модем адаптивный ответ (adaptive answer). Если модем не поддерживает адаптивный ответ, Вам придется отключить факс-связь на этом модеме, чтобы он мог принимать зап росы на соединения удаленного доступа и подключения для маршрутизации с соединением по требованию.
Маршрутизация с соединением по требованию ГЛАВА 6 Х При маршрутизации с соединением по требованию на основе сертификатов убе дитесь, что на вызывающем маршрутизаторе:
Х разрешено использование ЕАР в качестве протокола аутентификации;
Хправильно выбран сертификат для корневого центра сертификации отвеча ющего маршрутизатора;
Х при настройке удостоверений (учетных данных) интерфейса соединения по требованию правильно выбран сертификат маршрутизатора (автономный запрос).
Х При маршрутизации с соединением по требованию на основе сертификатов убе дитесь, что на отвечающем маршрутизаторе:
Х разрешено использование ЕАР в качестве протокола аутентификации;
Х правильно выбран машинный сертификат для корневого центра сертифика ции отвечающего маршрутизатора.
Адреса за вызывающим или отвечающим маршрутизатором недостижимы Х Б случае соединения по требованию, инициируемого любой из сторон, проверь те, не интерпретируется ли оно как соединение удаленного доступа. Чтобы от вечающий маршрутизатор мог определить, что его вызывает маршрутизатор, а не клиент удаленного доступа, имя пользователя в удостоверениях вызывающе го маршрутизатора должно совпадать с именем интерфейса соединения по тре бованию, сконфигурированного на отвечающем маршрутизаторе.
Если вызов поступил от маршрутизатора, порт, через который был принят пьт зов, должен находиться в состоянии Active (Активно), а соответствующий ин терфейс соединения по требованию Ч в состоянии Connected (Подключено).
Если имя вызывающего маршрутизатора появилось в папке Remote Access Clients (Клиенты удаленного доступа), значит, отвечающий маршрутизатор вос принимает его в качестве клиента удаленного доступа.
В случае соединений, инициируемых любой из сторон, любой маршрутизатор может быть вызывающим или отвечающим. При этом имя пользователя в удос товерениях одного маршрутизатора должно совпадать с именем интерфейса со единения по требованию на другом маршрутизаторе. Например, соединения, инициируемые любой из сторон, могли бы работать в следующей конфигурации.
У маршрутизатора 1 имеется интерфейс соединения по требовании с именем NEW-YORK, который передает в своих удостоверениях имя пользователя SEATTLE, а у маршрутизатора 2 Ч интерфейс соединения по требованию с име нем SEATTLE, который передает в своих удостоверениях имя пользователя NEW-YORK.
В этом примере имя пользователя SEATTLE может быть аутентифицировано маршрутизатором 2, а имя пользователя NEW-YORK Ч маршрутизатором 1.
Х В случае соединения по требованию, инициируемого только одной из сторон, убедитесь, что в пользовательской учетной записи вызывающего маршрутиза тора разрешены соответствующие статические маршруты и что на отвечающем маршрутизаторе работает какой-либо протокол маршрутизации, который после установления соединения объявляет соседним маршрутизаторам статические маршруты из пользовательской учетной записи вызывающего маршрутизат( ipa.
8 Зак. Маршрутизация 210 ЧАСТЬ Х Убедитесь, что на обеих сторонах соединения по требованию имеются маршру ты, обеспечивающие двусторонний обмен трафиком. В отличие от соединения удаленного доступа соединение но требованию не приводит к автоматическому созданию IP-маршрута по умолчанию. Так что на обеих сторонах соединения по требованию нужно создать маршруты, которые позволят пересылать трафик в любую сторону.
Х Убедитесь, что на внутренних маршрутизаторах интрасетей вызывающего и от вечающего маршрутизаторов имеются маршруты, обеспечивающие пересылку пакетов между хостами в интрасетях. Эти маршруты можно добавить на внут ренние маршрутизаторы как статические, либо просто разрешить использование какого-нибудь протокола маршрутизации на подключенных к интрасетям интер фейсах вызывающего и отвечающего маршрутизаторов.
Х Проверьте, не установлены ли на интерфейсах соединений по требованию филь тры IP- или IPX-пакетов, препятствующие передаче нужного трафика.
Х Проверьте, не определены ли в профиле политики удаленного доступа на отве чающем маршрутизаторе (или сервере RADIUS, если используется IAS) какие нибудь фильтры TCP/IP-пакетов, препятствующие передаче или приему TCP/ IP-трафика.
Автостатическое обновление не работает Х В случае автостатических обновлений для IP убедитесь, что соответствующие интерфейсы соединений по требованию на обоих маршрутизаторах добавлены к протоколу маршрутизации RIP, что его режим работы задан как Autostatic update mode (Режим автостатического обновления), а протокол исходящих па кетов Ч как RIP version 2 multicast (Для RIP версии 2, многоадресная).
Х В случае автоматических обновлений для IPX убедитесь, что соответствующие интерфейсы соединений по требованию на обоих маршрутизаторах добавлены к протоколам маршрутизации RIP for IPX и SAP for IPX и что режим обновле ния для каждого из этих протоколов задан как Autostatic (Автостатический).
Средства диагностики С Windows 2000 поставляются средства диагностики, позволяющие собирать до полнительную информацию об источниках проблем с маршрутизацией.
Причина недостижимости Если установить соединение по требованию не удается, интерфейс соединения по требованию остается в недостижимом состоянии. Маршрутизатор Windows регистрирует причину, по которой не удалось установить соединение, в параметре Unreachability reason (Причина недостижимости). Информация, указанная в этом параметре, поможет Вам локализовать источник проблемы.
^ Чтобы просмотреть причину недостижимости:
1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) щелкните правой кнопкой мыши нужный интерфейс соединения по требованию.
2. Выберите команду Unreachability reason (Причина недостижимости).
Маршрутизация с соединением по требованию ГЛАВА б 3. В диалоговом окне Routing and Remote Access (Маршрутизация и удаленный доступ) прочтите текст, поясняющий причину недостижимости и щелкните кнопку ОК.
Интерфейс соединения по требованию остается в недостижимом состоянии по сле дующим причинам:
Х исчерпаны все порты, используемые интерфейсами соединений по требованию;
Х служба маршрутизации и удаленного доступа приостановлена;
Х использование данного интерфейса соединения по требованию запрещено;
Х расписание исходящих звонков (вызовов) препятствует установлению соеди нения.
При настройке интерфейса соединения но требованию выбирается какой-либо порт.
Порт Ч это аппаратный или программный капал, представляющий одно соедине ние типа точка-точка. Порты группируются по типам, например: порты аналого вых телефонных линий, ISDN-порты В-канала, VPN-порты (РРТР и L2TP).
Настраивая интерфейс соединения по требованию на определенный порт, Вы на страиваете его и на использование определенного типа портов, Если заданный порт недоступен в момент установления соединения, служба маршрутизации и удален ного доступа пытается задействовать другой порт того же типа. Например, у Вас два модема, и Вы настраиваете интерфейс соединения по требованию на использо вание конкретного модема. Если в момент установления соединения по требованию этот модем занят, вызывающий маршрутизатор автоматически задействует другой модем.
Оснастка Routing and Remote Access позволяет создавать любое число интерфей сов соединений по требованию для портов определенного типа Ч независимо от реального количества таких портов в системе. Так, можно создать несколько ин терфейсов, настроенных на использование одного и того же модемного порта. Если в момент инициации соединения но требованию этот модем занят и других портов того же типа нет, попытка соединения закончится неудачей;
при этом будет зареги стрирована причина недостижимости.
Протоколирование событий Протоколирование событий заключается в том, что они регистрируются в систем ном журнале событий Windows 2000. Этот процесс обычно используется при иы явлении и устранении проблем или для уведомления администраторов сетей о нео бычных событиях.
На вкладке Event logging (Журнал событий) окна свойств отвечающего маршру тизатора предлагается четыре уровня протоколирования. Выберите переключатель Log the maximum amount of information (Вести журнал всех событий) и повторите попытку соединения. Как только попытка закончится неудачей, проверьте, какие события были зарегистрированы в системном журнале при попытке соединения.
Просмотрев события, выберите на вкладке Event logging переключатель Log errors and warnings (Вести журнал ошибок и предупреждений).
Учет и протоколирование через Windows Если Вы выбрали аутентификацию или учет через Windows, служба маршрутиза ции и удаленного доступа может регистрировать аутентификационную и учетную Маршрутизация 212 ЧАСТЬ информацию для соединений по требованию и удаленного доступа. Соответствую щие журналы ведутся отдельно от системных журналов. Эта информация позволя ет отслеживать попытки аутентификации, а также использование соединений по требованию и удаленного доступа. Она особенно полезна при устранении каких либо проблем с политикой удаленного доступа. Для каждой попытки аутентифи кации в журнал записывается имя политики удаленного доступа, благодаря кото рой запрос на соединение был принят или отклонен.
Аутентификационная и учетная информация хранится в файле или файлах журна ла в папке %5#stem#oot%\System32\LogFiles. Эти файлы записываются в формате IAS 1.0 или 2.0. Формат IAS 2.0 совместим с ODBC-форматом баз данных, и в этом случае любая программа, работающая с базами данных, может напрямую считывать файл журнала для последующего анализа.
Вы можете указывать типы регистрируемой активности и настраивать параметры файлов журнала через свойства папки Remote Access Logging (Ведение журнала удаленного доступа) в оснастке Routing and Remote Access.
Network Monitor Network Monitor (Сетевой монитор) Ч это программа для захвата пакетов и их ана лиза, которая позволяет наблюдать за трафиком, передаваемым между маршрути заторами в процессе установления соединения но требованию. Network Monitor не анализирует сжатый или шифрованный трафик, передаваемый через соединения по требованию.
Правильная интерпретация трафика в процессе установления РРР-соединения с помощью Network Monitor требует понимания протоколов РРР, описываемых в главе 7 Сервер удаленного доступа в этой книге. Информацию, захваченную Network Monitor, можно сохранить в виде файлов и послать в службу технической поддержки Microsoft для анализа.
Трассировка Средства трассировки записывают последовательность вызываемых функций в файл. Разрешите применение трассировки для записи детальной информации о процессах, выполняемых при установлении соединения компонентами удаленного доступа или подключения по требованию. Закончив трассировку и просмотрев нуж ную информацию, верните параметрам трассировки исходные значения.
Трассировочная информация может оказаться сложной и очень детальной. Часть ее полезна только инженерам службы технической поддержки Microsoft или сете вым администраторам, имеющим большой опыт работы со службой маршрутиза ции и удаленного доступа. Трассировочную информацию можно сохранить в виде файлов и послать в службу технической поддержки Microsoft для анализа.
Подробнее о трассировке РРР см. главу 7 Сервер удаленного доступа в этой книге.
ЧАСТЬ Удаленный доступ Поддержка удаленного доступа по коммутируемым линиям, виртуальных частных сетей, централизованной аутентификации, авторизации и учета с применением RADIUS позволяет создавать защищенные и масштабируемые решения но удаленному доступу. В этой части подробно рассматриваются технологии удаленного доступа, поддерживаемые службой маршрутизации и удаленного доступа Windows 2000, а также службой проверки подлинности в Интернете (IAS).
В этой части Сервер удаленного доступа Служба проверки подлинности в Интернете Виртуальные частные сети ГЛАВА Сервер удаленного доступа Windows 2000 поддерживает технологии удаленного доступа для подключения уда ленных клиентов к корпоративным сетям или Интернету. Здесь поясняется, как работает сервер удаленного доступа и как локализовать причины пройдем, возни кающих при удаленном доступе.
Эта глава предназначена для сетевых инженеров и специалистов по технической поддержке, уже знакомых с TCP/IP, IP- и IPX-маршрутизацией, а также с техно логиями WAN. Кроме того, предполагается, что Вы прочитали раздел по удаленно му доступу в справочной системе Windows 2000 Server.
В этой главе Обзор Архитектура сервера удаленного доступа РРР РРР-протоколы аутентификации Удаленный доступ и настройка TCP/IP и IPX Политика удаленного доступа Multilink и ВАР Сервер удаленного доступа и поддержка групповой IP-рассылки Выявление и устранение проблем См. также Х О протоколах TCP/IP Ч главу 1 Введение в TCP/IP в книге Сети TCP/IP из серии Ресурсы Microsoft Windows 2000 Server.
Х Об одноадресной IP-маршрутизации Ч главу 3 Одноадресная IP-маршрутиза ция в этой книге.
Х Об IPX-маршрутизации Ч главу 5 IPX-маршрутизация в этой книге.
Х О маршрутизации с соединением но требованию Ч главу 6 Маршрутизация с соединением по требованию в этой книге.
ГЛАВА 7 Сервер удаленного доступа Х О виртуальных частных сетях Ч главу 9 Виртуальные частные сети в этой книге.
Примечание В этой главе упоминаются различные параметры и разделы реестра Windows 2000. Более подробную информацию о них см. в документации Technical Reference to the W i n d o w s 2000 Registry на компакт-диске Ресурсы Microsoft Windows 2000 Server.
Обзор Средства удаленного доступа Windows 2000 позволяют клиенту удаленного досту па подключаться к серверу удаленного доступа, а через него автоматически соеди няться с сервером (соединение удаленного доступа типа точка-точка) или вхо дить в сеть, связанную с сервером удаленного доступа (соединение удаленного до ступа типа точка-LAN). Такая прозрачность соединений дает возможность кли ентам удаленного доступа входить в есть из разных мест и работать с ее ресурсами так, будто они физически подключены к сети.
При организации удаленного доступа средствами Windows 2000 возможны два типа соединений.
Х Удаленный доступ по коммутируемым линиям (dial-up remote access). Кли ент удаленного доступа использует телекоммуникационную инфраструктуру для создания временной физической или виртуальной цепи, связывающей его с портом сервера удаленного доступа. После создания физической или виртуаль ной цепи могут быть согласованы необходимые параметры соединения.
Х Удаленный доступ через VPN (virtual private network remote access). VPN клиент создает в межсетевой IP-среде виртуальное подключение типа точка точка с сервером удаленного доступа, выступающего в роли VPN-сервера. Пос ле установления виртуального подключения типа точка-точка могут быть со гласованы необходимые параметры соединения.
Примечание Эта глава посвящена в основном удаленному доступу по коммутируе мым линиям, но многие из изложенных здесь материалов применимы и к удален ному доступу через VPN. Для более полного понимания виртуальных частных се тей прочтите сначала эту главу, а затем главу 9 Виртуальные частные сети.
Удаленный доступ и удаленное управление Различия между сервером удаленного доступа и средствами удаленного управле ния заключаются в следующем.
Х Сервер удаленного доступа Ч это программный многопротокольный маршрути затор, тогда как средства удаленного управления обеспечивают управление эк раном, клавиатурой и мышью по какому-либо каналу связи.
Х При удаленном доступе приложения запускаются на клиентском компьютере, при удаленном управлении Ч на сервере.
Х Средства удаленного управления приводят к тому, что пользователи делят меж ду собой один или несколько процессоров на сервере. Однако процессор сер:*е Удаленный доступ 216 ЧАСТЬ ра удаленного доступа используется исключительно для поддержки взаимодей ствия между клиентами удаленного доступа и сетевыми ресурсами.
Компоненты, участвующие в соединении по коммутируемой линии В соединении удаленного доступа по коммутируемой линии участвуют клиент уда ленного доступа, сервер удаленного доступа и инфраструктура WAN (рис. 7-1).
Сервер удаленного доступа Инфраструктура WAN Клиент удаленного доступа Рис. 7-1. Компоненты, участвующие в соединении по коммутируемой линии Клиент удаленного доступа К серверу удаленного доступа Windows 2000 могут подключаться клиенты удален ного доступа Windows 2000, Windows NT 3.5 и выше, Windows 95, Windows 98, Windows tor Workgroups, MS-DOS и Microsoft LAN Manager, а также почти все кли енты удаленного доступа от сторонних поставщиков, использующие протоколы РРР, в том числе клиенты UNIX и Apple Macintosh, Сервер удаленного доступа Сервер удаленного доступа Windows 2000 принимает запросы на соединения по коммутируемым линиям и пересылает пакеты между удаленными клиентами и се тью, к которой подключен сервер удаленного доступа.
Примечание В этой главе термином сервер удаленного доступа обозначается ком пьютер, который работает под управлением Windows 2000 Server со службой марш рутизации и удаленного доступа и настроен на предоставление удаленного доступа.
Телефонное оборудование и инфраструктура WAN Физическое или логическое соединение между сервером и клиентом удаленного доступа обеспечивается телефонным оборудованием, установленным па клиентском компьютере, и телекоммуникационной инфраструктурой. Состав оборудования и телекоммуникационная инфраструктура зависят от тина устанавливаемых соеди нений.
PSTN Коммутируемая телефонная сеть общего пользования (Public Switched Telephone Network, PSTN), также называемая POTS (Plain Old Telephone Service);
Ч анало ГЛАВА 7 Сервер удаленного доступа говая телефонная система, рассчитанная на передачу минимальной полосы частот, достаточной для восприятия человеческой речи. Так как PSTN изначально не пред назначалась для передачи данных, соединение через PSTN существенно ограничи вает скорость передачи битов. Телефонное оборудование состоит из аналоговых модемов, установленных на клиенте и сервере удаленного доступа. В крупных орга низациях сервер удаленного доступа подключен к модемному пулу, содержащему сотни модемов. При использовании аналоговых модемов на клиенте и сервере уда ленного доступа максимально возможная скорость на соединениях через PSTN 33600 бит/с (33,6 Кбит/с).
Соединение через PSTN показано на рис. 7-2.
Сервер удаленного доступа Модем Клиент PSTN удаленного доступа Интрасеть Рис. 7-2. Телефонное оборудование и инфраструктура WAN для связи через PSTN Цифровые линии и V. Максимальная скорость передачи через PSTN ограничивается полосой пропуска ния коммутаторов PSTN и отношением сигнал/шум. Современные телефонные системы являются аналоговыми только на последнем отрезке, соединяющем або нента с АТС. Как только аналоговый сигнал попадает на коммутатор PSTN, он пре образуется в цифровой сигнал. При аналогово-цифровом преобразовании появля ется шум, известный как шум квантизации (quantization noise).
Если сервер удаленного доступа подключен к АТС через цифровой коммутатор T-Carricr или ISDN, а не через аналоговый PSTN-коммутатор, то при отправке ин формации от сервера клиенту удаленного доступа аналогово-цифрового преобра зования не происходит. Таким образом, на пути к клиенту удаленного доступа шум квантизации отсутствует, что обеспечивает более высокое отношение сигнал/шум и более высокую скорость передачи данных.
Благодаря этой повой технологии, названной V.90, клиент удаленного доступа пе редает данные па скорости 33,6 Кбит/с, а принимает Ч на скорости 56 Кбит/с. Од нако па практике максимальная скорость приема данных несколько ниже, напри мер в Северной Америке она не превышает 53 Кбит/с.
Чтобы достичь скоростей протокола V.90:
Х клиент удаленного доступа должен использовать модем с поддержкой протоко ла V.90;
Х сервер удаленного доступа должен использовать цифровой коммутатор V.9D и подключаться к PSTN по цифровой линии типа Т-Саглег или ISDN;
Х на пути от сервера удаленного доступа к клиенту не должно бытъ никаких ана логово-цифровых преобразований сигнала.
Удаленный доступ 218 ЧАСТЬ Соединение через PSTN но технологии V.90 показано на рис. 7-3.
- Линия T-Carrier или ISDN Сервер удаленного доступа Клиент Модем удаленного V. доступа Интрасеть Рис. 7-3. Телефонное оборудование и инфраструктура WAN для связи по технологии V. ISDN ISDN (Integrated Services Digital Network) Ч набор международных спецификаций, определяющих цифровой эквивалент PSTN, который обеспечивает передачу рече вых сигналов, данных, факс-сообщений и предоставляет другие сервисы с исполь зованием существующей у заказчика телефонной проводки. ISDN работает, как обычная аналоговая телефонная линия, с тем исключением, что эта сеть построена на цифровой технологии, поддерживающей более высокие скорости передачи дан ных и меньшее время соединения. ISDN предоставляет несколько каналов, каждый из которых функционирует па скорости 64 Кбит/с. а поскольку эта сеть полностью цифровая, аналогово-цифровых преобразований в ней нет.
Телефонное оборудование состоит из ISDN-адаптеров клиента и сервера удаленно го доступа. Клиенты удаленного доступа обычно используют Basic Rate ISDN (BRI) с двумя 64-килобитными каналами;
в крупных организациях часто применяется Primary Rate ISDN (PRI) с 23 каналами по 64 Кбит/с.
ISDN-соединение показано на рис. 7-4.
Сервер удаленного доступа Клиент ISDN- ISDN удаленного адаптер доступа Рис. 7-4. Телефонное оборудование и инфраструктура WAN для связи через ISDN Х. Х.25 Ч международный стандарт передачи данных по общедоступным сетям с ком мутацией пакетов. В Windows 2000 предусмотрено два варианта поддержки Х.25.
1. Клиент удаленного доступа поддерживает так называемые интеллектуальные платы Х.25 (Х.25 smart cards), напрямую подключаемые к сети Х.25 и исноль Сервер удаленного доступа ГЛАВА зующие протокол Х.25 для установления соединений и обмена данными. Кроме того, клиенты удаленного доступа поддерживают непрямое подключение к сети Х.25 через устройство сборки/разборки пакетов (packet assembler/disassembler, PAD) несущей среды Х.25 с применением аналогового модема.
2. Сервер удаленного доступа поддерживает только интеллектуальные платы Х.25.
Подробнее о настройке Х.25 и PAD см. справочную систему Windows 2000 Server.
Примечание Интеллектуальные платы Х.25 Ч это адаптеры, которые используют протокол Х.25 и напрямую подключаются к общедоступной сети данных Х.25. Эти платы не имеют ничего общего со смарт-картами, применяемыми для аутентифи кации (проверки подлинности) и организации защищенного канала связи.
Соединение через Х.25 показано на рис. 7-5.
Клиент \/ PAD Сервер удаленного ^ удаленного ^ ^т доступа доступа Интеллектуаль- Х.25 Интеллектуаль ная плата Х.25 ная плата Х. Интрасеть Рис. 7-5. Телефонное оборудование и инфраструктура WAN для связи через Х. ATM поверх ADSL ADSL (Asymmetric Digital Subscriber Line) Ч новая технология последней ми;
и, предназначенная для малого бизнеса и домашних пользователей. Хотя ADSL обес печивает более высокую скорость передачи данных по сравнению с PSTN и ISDN, входящие и исходящие соединения неравноценны. Обычно ADSL-соединения от абонента работают на скорости 64 Кбит/с, а к абоненту Ч на скорости 1,544 Мбит/с.
Такая асимметричность оптимальна для обычного использования Интернета, по скольку основная часть пользователей принимает информации гораздо больше, чем передаст.
Windows 2000 воспринимает аппаратные средства ADSL либо как Ethernet-интер фейс, либо как интерфейс удаленного доступа по коммутируемой линии. Если ADSL-адаптер распознается как Ethernet-интерфейс, ADSL-соединение работает так же, как Ether net-подключение к Интернету.
Удаленный доступ 220 ЧАСТЬ Если ADSL-адаптер распознается как интерфейс удаленного доступа по коммути руемой линии, то ADSL обеспечивает физическое соединение, а пакеты LAN-про токолов посылаются с использованием ATM (Asynchronous Transfer Mode). Адап тер ATM с портом ADSL устанавливается как па клиенте удаленного доступа, так и на сервере удаленного доступа.
Соединение через ATM поверх ADSL показано на рис. 7-6.
Клиент Сервер удаленного ^ удаленного доступа Адаптер ADSL ATM Интрасеть Рис. 7-6. Телефонное оборудование и инфраструктура WAN для связи через ATM поверх ADSL Протоколы удаленного доступа Протоколы удаленного доступа управляют установлением соединения и передачей данных по WAN-каналам. Выбор протокола удаленного доступа на клиентском ком пьютере диктуется тем, какая операционная система и какие LAN-протоколы уста новлены на клиенте и сервере удаленного доступа.
Существует три типа протоколов удаленного доступа, поддерживаемых Win dows 2000.
1. РРР (Point-to-Point Protocol) Ч стандартный набор протоколов, обеспечиваю щий максимальную защиту, поддержку множества протоколов и взаимодействие с другими операционными системами.
2. SLIP (Serial Line Internet Protocol) используется на устаревших версиях серве ров удаленного доступа.
3. Microsoft RAS (также называемый Asynchronous NetBEUI, или AsyBEUI) протокол удаленного доступа, используемый унаследованными клиентскими системами Microsoft., например Windows NT 3.1, Windows for Workgroups, MS-DOS и LAN Manager.
Протоколы удаленного доступа и их применение в Windows 2000 показаны в таб лице 7-1.
Таблица 7-1. Протоколы удаленного доступа и их применение в Windows Протокол удаленного доступа Клиент удаленного доступа Сервер удаленного доступа РРР X X X SLIP AsvBEUI X X Сервер удаленного доступа ГЛАВА LAN-протоколы Это протоколы, используемые клиентом удаленного доступа для обращения к ре сурсам в сети, к которой подключен сервер удаленного доступа. Средства удален ного доступа в Windows 2000 поддерживают TCP/IP, IPX, ApplcTalk и NetBEUI (см. раздел Удаленный доступ и настройка TCP/IP и IPX далее в этой главе).
Элементы защиты удаленного доступа Поскольку клиент удаленного доступа бесшовно подключается к сети и содержа щимся в ней конфиденциальным данным, при удаленном доступе очень важно обес печить должную защиту. Windows 2000 предусматривает самые разнообразные средства защиты, в том числе защищенную аутентификацию пользователей, взаим ную аутентификацию (клиента и сервера), шифрование данных, ответный вызов и идентификацию звонящего.
Защищенная аутентификация пользователей Защищенная аутентификация пользователей достигается за счет обмена удостове рениями (учетными данными) пользователей в шифрованном виде и поддержива ется РРР в сочетании с одним из протоколов аутентификации: ЕАР (Extensible Authentication Protocol), MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) версий 1 и 2, CHAP (Challenge Handshake Authentication Protocol) или SPAP (Shiva Password Authentication Protocol). Сервер удаленного доступа мо,-кпо настроить так, чтобы он требовал применения защищенной аутентификации. Если клиент удаленного доступа не в состоянии выполнить это требование, его запрос на соединение отклоняется.
Взаимная аутентификация При взаимной аутентификации каждая из сторон соединения аутентифицирует другую, обмениваясь пользовательскими удостоверениями в зашифрованном виде.
Такая аутентификация поддерживается РРР в сочетании с протоколом аутентифи кации EAP-TLS (EAP-Transport Level Security) или MS-CHAP версии 2. В процес се взаимной аутентификации клиент удаленного доступа подтверждает свою под линность серверу удаленного доступа, а тот Ч клиенту.
Сервер удаленного доступа может не требовать аутентификации клиента удален ного доступа. Однако клиент удаленного доступа Windows 2000 настраивается толь ко под протокол MS-CHAP версии 2 или EAP-TLS и требует взаимной аутентифи кации клиента и сервера. Если сервер удаленного доступа Tie ответит на запрос о взаимной аутентификации, клиент закроет соединение.
Шифрование данных Обеспечивает шифрование информации, передаваемой между клиентом и сервером удаленного доступа. При этом данные шифруются только на коммуникационном пути между клиентом и сервером. Если Вам нужно шифровать данные па всем кути их передачи, то после установления физического соединения удаленного доступа создайте логическое соединение на основе IPSec.
Примечание IPSec также используется для шифрования VPN-соединений на осно ве L2TP (см. главу 9 Виртуальные частные сети в этой книге).
Удаленный доступ 222 ЧДСТЬ Шифрование данных при соединениях удаленного доступа основано на примене нии секретного ключа, известного серверу и клиенту удаленного доступа. Этот об щий ключ генерируется в процессе аутентификации пользователя.
Шифрование данных возможно при удаленном доступе по коммутируемым лини ям с использованием РРР и протоколов аутентификации EAP-TLS или MS-CHAP.
Сервер удаленного доступа может требовать обязательного шифрования данных.
Если клиент не способен обеспечить шифрование, его запрос на соединение откло няется.
Клиенты и серверы удаленного доступа под управлением Windows 2000, Win dows NT 4.0, Windows 98 и Windows 95 поддерживают шифрование по МРРЕ (Mic rosoft Point-to-Point Encryption Protocol). MPPE использует алгоритм RSA (Rivest Sharair-Adleman) RC4 и шифровальные ключи длиной 40, 56 или 128 битов. Клю чи МРРЕ генерируются в процессе аутентификации пользователя по протоколам MS-CHAP или EAP-TLS.
Ответный вызов Если функция ответного вызова включена, то после проверки пользовательских удостоверений сервер удаленного доступа перезванивает клиенту. Ответный вызов можно настроить так, чтобы сервер звонил клиенту по номеру, указываемому при первом вызове (это удобно мобильным пользователям). Однако эту функцию мож но настроить на ответный вызов только по одному номеру, что обеспечивает допол нительную защиту.
Идентификация звонящего Эта функция гарантирует, что входящий вызов поступил с определенного номера.
Она настраивается в параметрах входящих звонков в свойствах пользовательской учетной записи. Если номер звонящего не совпадает с заданным, запрос на соеди нение отклоняется.
Применение этой функции возможно лишь при условии, что идентификацию зво нящего поддерживают все необходимые компоненты Ч телефонная линия звоня щего, телефонная система, телефонная линия сервера удаленного доступа и драй веры телефонного оборудования. Если учетная запись сконфигурирована на ис пользование идентификации звонящего, но его идентификатор не передается от звонящего в службу маршрутизации и удаленного доступа, запрос на соединение отклоняется.
Идентификация звонящего позволяет достичь более высокого уровня защиты се тей, поддерживающих удаленный доступ. Ее недостаток в том, что пользователь может звонить только по одной телефонной линии.
Блокировка учетной записи удаленного доступа Эта функция позволяет указать число неудачных попыток аутентификации по дей ствующей учетной записи перед тем, как пользователю будет отказано в удален ном доступе. Блокировка учетных записей удаленного доступа особенно важна при VPN-соединениях через Интернет. Злоумышленники из Интернета могут попы таться получить доступ в интрасеть организации через VPN-соединение, последо вательно присылая удостоверения с правильным именем пользователя и подбирае ГЛАВА 7 Сервер удаленного доступа мым паролем. При этом посылаются сотни или тысячи удостоверений, в которые подставляются пароли из списка, основанного на наборе наиболее часто употреб ляемых слов и выражений. Такая атака называется словарной (dictionary attack).
Функция блокировки учетных записей удаленного доступа надежно пресекает по пытки словарных атак.
Однако она не различает злоумышленника и настоящего пользователя, который пытается войти в сеть, но забыл свой пароль. Такие пользователи обычно пробуют несколько вариантов, пытаясь вспомнить правильный пароль, и Ч в зависимости от числа попыток и значения параметра MaxDenials Ч могут нечаянно заблокиро вать свою учетную запись.
При включенной функции блокировки учетных записей удаленного доступа зло умышленник может намеренно блокировать учетные записи, вводя неправильные пароли до тех пор, пока эти записи не заблокируются, и тем самым не давая насто ящим пользователям войти в свою сеть.
Как администратор сети, Вы должны принять решение о том, как настроить два параметра, регулирующих работу функции блокировки учетных записей удаленно го доступа.
1. Число неудачных попыток до блокировки.
После каждой неудачной попытки счетчик таких попыток для учетной записи увеличивается на 1. Как только он достигает заданного максимума, дальнейшие попытки соединения игнорируются, Если аутентификация проходит успешно, пока счетчик неудачных попыток не достиг максимального значения, этот счетчик сбрасывается. Иначе говоря, чис ло неудачных попыток не аккумулируется после успешной аутентификации.
2. Частота сброса счетчика неудачных попыток.
Во избежание ложного срабатывания функции блокировки из-за ошибок поль зователей при вводе паролей Вам следует периодически сбрасывать счетчик не удачных попыток.
Функция блокировки учетных записей удаленного доступа настраивается через реестр на том компьютере, который аутентифицирует пользователей. Если сервер удаленного доступа сконфигурирован на аутентификацию через Windows, модифи кации требует реестр на этом сервере. А если он настроен на аутентификацию че рез RADIUS и использует Internet Authentication Service (IAS) (Служба проверки подлинности в Интернете), Вы должны внести нужные изменения в реестр на сер вере IAS.
Для включения функции блокировки учетных записей присвойте параметру Max Denials в разделе реестра HKEY_LOCAL_MACHINE\System\CurrcntControlSet\ Services\ Remote Access\ Pa rameters\ Account Lockout значение, равное или большее 1.
Значение MaxDenials по умолчанию Ч 0 (функция блокировки учетных записей отключена).
Для изменения периодичности сброса счетчика неудачных попыток присвойте па раметру ResetTime в разделе реестра HKEY_LOCAL_MACHINE\System\Cunent ControlSet\Services\RemoteAccess\Parameters\AccountLockout нужное значение в минутах. Значение ResetTime по умолчанию Ч ОхЬ40 (2880 минут, или 48 часпв).
Удаленный доступ 224 ЧАСТЬ Чтобы вручную разблокировать учетную запись, не дожидаясь автоматического сброса счетчика неудачных попыток, удалите из реестра следующий подраздел, со ответствующий имени пользователя по этой учетной записи:
HKEY_LOCAL_MACHINE\SysLem\CiiirentControlSet\Services \ Remote Access\Parameters\AccountLockout\ziM^_5o-лewfl:ziлa_wo^b306umeAa Примечание Функция блокировки учетных записей удаленного доступа не связана с флажком Account locked out (Отключить учетную запись) на вкладке General (Общие) окна свойств пользовательской учетной записи и не имеет никакого от ношения к управлению политиками блокировки учетных записей через политики групп Windows 2000.
Управление удаленным доступом Вы должны продумать следующие вопросы, и Где хранить учетные данные пользователей?
Х Как назначать адреса клиентам удаленного доступа?
Х Кому разрешить создавать соединения удаленного доступа?
Х Как сервер удаленного доступа будет аутснтифицировать пользователя, пытаю щегося установить соединение?
Х Как сервер удаленного доступа будет регистрировать активность, связанную с удаленным доступом?
Х Как реализовать управление сервером удаленного доступа на основе стандарт ных протоколов управления сетью и имеющейся инфраструктуры?
Управление пользователями С точки зрения администрирования, создать несколько учетных записей для одно го и того же пользователя на разных серверах и пытаться постоянно поддерживать актуальность всех этих записей совершенно нереально. Поэтому большинство ад министраторов создают главную базу данных учетных записей на первичном кон троллере домена (PDC) или на сервере RADIUS. Это позволяет централизовать аутентификацию удаленных пользователей;
сервер удаленного доступа просто пе ресылает их удостоверения соответствующему серверу для проверки.
Управление адресами Б случае РРР-соединений информация об ТР-, IPX- и AppleTalk-адресах предостав ляется клиентам удаленного доступа в процессе установления соединения. Сервер удаленного доступа Windows 2000 должен быть настроен на назначение IP-адресов, номеров IPX-сетей и узлов, а также AppleTalk-адресов сетей и узлов.
Подробнее о выделении IP- и IPX-адресов см. раздел Удаленный доступ и на стройка TCP/IP и IPX далее в этой главе.
Управление доступом В Windows XT версий 3.5х и 4.0 авторизация основывалась на простом параметре Grant dial-in permission to user в User Manager или утилите Remote Access Admin.
Параметры ответного вызова настраивались отдельно для каждого пользователя.
ГЛАВА 7 Сервер удаленного доступа В Windows 2000 авторизация осуществляется на основе параметров входящих звон ков в свойствах пользовательской учетной записи и политики удаленного доступа.
Политика удаленного доступа Ч это набор условий и параметров, позволяющий администраторам сетей более гибко управлять авторизацией пользователей при попытках соединения. На основе этой политики служба маршрутизации и удален ного доступа и служба IAS в Windows 2000 решают, принять или отклонить запрос на соединение. Подробнее о политике удаленного доступа см. главу 8 Служба про верки подлинности в Интернете* в этой книге.
Таким образом, право на удаленный доступ можно предоставлять как иа индиви дуальной основе (в учетных записях конкретных пользователей), так и через поли тику удаленного доступа.
Доступ на основе параметров учетной записи Доступ на основе учетной записи является административной моделью, применяв шейся в Windows NT версий 3.5Дт и 4.0. В Windows 2000, если Вы хотите управлять удаленным доступом отдельно для каждого пользователя, установите в параметрах их учетных записей разрешение на удаленный доступ как Allow access (Разрешить доступ) и измените свойства профиля политики удаленного доступа по умолчанию.
называемой Allow access if dial-in permission is enabled (Разрешить доступ, гели разрешены входящие подключения).
Если сервер удаленного доступа обслуживает только подключения по коммутируе мым линиям и не поддерживает VPN-соединения, удалите политику удаленного доступа по умолчанию и создайте новую политику с подходящим именем, напри мер Dial-up remote access if dial-in permission is enabled.
В качестве примера типичных настроек удаленного доступа по коммутируемым линиям выберите в свойствах политики удаленного доступа переключатель Deny remote access permission (Отказать в нраве удаленного доступа), а условия и па раметры профиля установите, как показано в таблицах 7-2 и 7-3. Подробнее о на стройке этих параметров ем. справочную систему Windows 2000 Server.
Таблица 7-2. Условия политики удаленного доступа для подключения по коммутируемой линии на основе параметров учетной записи Условие Настройки NAS-Port-Type Выберите все типы, кроме Virtual (VPN) [Virtual (V'PN)J Таблица 7-3. Параметры профиля политики удаленного доступа для подключения по коммутируемой линии на основе параметров учетной записи Вкладка в окне профиля Настройки Authentication Установите флажки Microsoft encrypted authentication version (MS-CHAP v2) [Шифрованная проверка (Microsoft, версия 2, (Проверка MS-CHAP v2>] и Microsoft encrypted authentication (MS-CHAP) подлинности) [Шифрованная проверка подлинности Microsoft (MS-CHAP)J Доступ на основе политики Административная модель доступа на основе политики разработана для серверов удаленного доступа Windows 2000 Ч как автономных, так и входящих в домен Windows 2000 основного режима. Для управления удаленным доступом на основе Удаленный доступ 226 ЧАСТЬ политик укажите разрешение удаленного доступа во всех учетных записях пользо вателей как Control access through Remote Access Policy (Управление на основе политики удаленного доступа). Далее определите новые политики удаленного дос тупа, разрешающие или запрещающие доступ в зависимости от Ваших потребнос тей. Если сервер удаленного доступа входит в домен Windows NT 4.0 или в домен Windows 2000 смешанного режима и Вы хотите управлять удаленным доступом на основе политик, укажите разрешение удаленного доступа во всех учетных записях пользователей как Allow access (Разрешить доступ). Затем удалите политику по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения) и создайте новые политики, разрешающие или запрещающие доступ. Запрос на соединение, не подходящий условиям ни одной из политик, отклоняется, даже если разрешение удаленного доступа в учетной записи пользователя указано как Allow access.
Обычно доступ на основе политики применяется для того, чтобы разрешать доступ в зависимости от принадлежности пользователей к той или иной группе. Напри мер, создайте группу Windows 2000 с именем DialUpUsers, членам которой будет разрешено устанавливать соединения удаленного доступа.
Чтобы сервер поддерживал удаленный доступ только по коммутируемым линиям, удалите политику по умолчанию Allow access if dial-in permission is enabled и со здайте новую политику с подходящим именем, например Dial-up reinote access if member of DialUpUsers group.
В качестве примера типичных настроек удаленного доступа по коммутируемым линиям только для членов определенной группы выберите в свойствах политики удаленного доступа переключатель Grant remote access permission (Предоставить право удаленного доступа), а условия и параметры профиля установите, как пока зано в таблицах 7-4 и 7-5. Подробнее о настройке этих параметров см. справочную систему Windows 2000 Server.
Таблица 7-4. Условия политики удаленного доступа для подключения по коммутируемой линии на основе политики Условия Настройки Выберите все типы, кроме Virtual (VPN) [Virtual (VPN)j NAS-Port-Type DialUpUsers (пример имени группы) Windows-Groups Таблица 7-5. Параметры профиля политики удаленного доступа для подключения по коммутируемой линии на основе политики Вкладка в окне профиля Настройки Authentication Установите флажки Microsoft encrypted authentication version (MS-CHAP v2) [Шифрованная проверка (Microsoft, версия 2, (Проверка подлинности) MS-CHAP v2)j и Microsoft encrypted authentication (MS-CHAP) [Шифрованная проверка подлинности Microsoft (MS-CHAP)] Управление аутентификацией Сервер удаленного доступа можно настроить на поддержку аутентификации через Windows или RADIUS.
Сервер удаленного доступа ГЛАВА 7 Аутентификация через Windows Если в качестве провайдера аутентификации выбрана Windows, удостоверения пользователей, пытающихся установить соединение, проверяются обычными сред ствами аутентификации Windows.
Если сервер удаленного доступа входит в домен Windows 2000 основного или сме шанного режима и настроен на аутентификацию через Windows, учетная запись компьютера этого сервера должна быть включена в группу безопасности RAS and IAS Servers (Серверы RAS и IAS). Эта операция выполняется администратором домена в оснастке Active Directory Users and Groups (Active Directory - пользова тели и группы) или командой netsh ras add registeredserver до активизации служ бы маршрутизации и удаленного доступа. Если пользователь, активизируют i n i i службу маршрутизации и удаленного доступа, является администратором домгна, учетная запись компьютера автоматически добавляется в группу безопасности RAS and IAS Servers.
Аутентификация через RADIUS Если в качестве провайдера аутентификации выбрана служба RADIUS, удостове рения пользователей и параметры запросов на соединения посылаются на сервер RADIUS (компьютер под управлением Windows 2000 Server с установленной служ бой IAS) как серия RADIUS-запросов.
Сервер RADIUS получает запрос пользователя на соединение от сервера удален ного доступа и аутентифицирует его на основе собственной базы данных учетных записей. На сервере RADIUS могут централизованно храниться и другие сведения о пользователях. Сервер RADIUS может не просто ответить да или нет на зап рос о соединении, но и предоставить серверу удаленного доступа информацию о параметрах соединения для данного пользователя, например о максимальной про должительности сеанса, статическом IP-адресе и т. д.
Сервер RADIUS может не только отвечать на запросы на основе собственной базы данных, по и выступать в роли клиентского интерфейса другого сервера базы дан ных, например универсального сервера ODBC (Open Database Connectivity) пли первичного контроллера домена под управлением Windows 2000. Последний может находиться как на машине, где установлен сервер RADIUS, так и на другом компь ютере. Кроме того, сервер RADIUS способен работать как прокси-клиент для уда ленного сервера RADIUS.
Протокол RADIUS описан в RFC 2138 и 2139. Подробнее о вариантах аутентисш кации при удаленном доступе и о функционировании сервера удаленного доступа в качестве клиента RADIUS см. справочную систему Windows 2000 Server;
подроб нее о службе IAS см. главу 8 Служба проверки подлинности в Интернете в этой книге.
Примечание Служба маршрутизации и удаленного доступа (если она настроена па аутентификацию через Windows) и IAS используют один и тот же процесс для аутентификации и авторизации входящих запросов на соединение. Более подроб ную информацию см. в главе 8 Служба проверки подлинности в Интернете в этой книге.
Удаленный доступ 228 ЧАСТЬ Управление учетом В качестве службы учета сервер удаленного доступа может использовать Windows или RADIUS. В первом случае учетная информация записывается в файл журнала на сервере удаленного доступа, а во втором Ч сообщения с учетной информацией поступают на сервер RADIUS, где накапливаются и хранятся для последующего анал иза.
Большинство серверов RADIUS можно настроить так, чтобы они записывали в файл учетной информации сведения о запросах на аутентификацию. Существует набор сообщений (посылаемых сервером удаленного доступа на сервер RADIUS), позволяющих запрашивать учетную информацию в начале или в конце сеанса свя зи, а также через определенные интервалы в течение сеанса. Сторонними разработ чиками создано программное обеспечение для биллинга и аудита, которое считы вает записи с учетной информацией RADIUS и генерирует отчеты в различных формах.
Управление сетью Если на компьютер с Windows 2000, работающий в качестве сервера удаленного доступа, установить службу SNMP, он сможет действовать в среде SNMP (Simple Network Management Protocol) как агент SNMP. Сервер удаленного доступа регис трирует управляющую информацию в различных идентификаторах объектов MIB II (Management Information Base), которые устанавливаются со службой SNMP.
Объекты MIB II документированы в RFC 1213.
Архитектура сервера удаленного доступа Архитектура сервера удаленного доступа включает следующие элементы (рис. 7-7).
Х Оболочку NDTS, Ndis.sys, предоставляющую KDIS-интерфейс уровня пакетов для TCP/IP, IPX, NetBEUI и AppleTalk.
Х Драйвер NDISWAN, Ndiswan.sys, Ч промежуточный NDIS-драйвер, предостав ляющий интерфейс минипорта IEFE 802.3 для драйверов протоколов и интер фейс протоколов для минипорт-драйверов WAN. NDISWAN обеспечивает раз биение данных на кадры, сжатие и шифрование для соединений удаленного до ступа.
Х Минипорт-драйверы WAN Ч минипорт-драйверы NDIS, содержащие программ ный код, необходимый для управления телефонным оборудованием. Чтобы можно было использовать адаптер, поддерживающий WAN-среду, например ISDN или ATM, в сочетании со средствами удаленного доступа Windows 2000, производитель адаптера должен написать соответствующий минипорт-драйвер WAN.
Х Компоненты удаленного доступа Ч набор библиотек, предоставляющих про граммный интерфейс RAS (Remote Access Service) приложениям, протоколам РРР и т. д. Компоненты удаленного доступа могут взаимодействовать с драйве ром NDISWAN напрямую или через ТАР! (Telephony API).
Х Компоненты TAPI Ч набор библиотек, предоставляющих программный интер фейс управления вызовами для всех приложений, которые поддерживают TAPI.
Управляя соединениями, компоненты TAPI взаимодействуют с драйвером Сервер удаленного доступа ГЛАВА 7 NDISWAN напрямую. Подробнее о TAPI в \Vindovvs2000 см. главу 15 Интег рация телефонии и поддержка конференций в этой книге.
ЙД Компоненты AppieTalk TCP/IP IPX NetBEUI удаленного доступа NDIS Ndis.sys Ndiswan.sys Минипорт-драйвер WAN Рис. 7-7. Архитектура удаленного доступа в Windows Клиенты удаленного доступа устанавливают соединение вызовом интерфейса HAS, который в свою очередь обращается к ТЛР1 для передачи информации о вызове телефонному оборудованию. После установления физического соединения интер фейс TAPI далее не используется. Компоненты удаленного доступа согласую" па раметры соединения (протоколы канального уровня, аутентификации и управле ния сетью), напрямую взаимодействуя с NDISWAN.
Как только соединение удаленного доступа установлено, драйверы протоколов мо гут взаимодействовать по этому соединению, вызывая стандартные NDIS-функкии, например NdisSend(). При соединениях по коммутируемой линии вызовы Ndis SendQ пересылаются NDISWAN, который определяет нужное устройство и тюрт, выполняет сжатие, шифрование и разбиение на кадры для РРР, а затем пересылает готовый кадр миншюрт-драйвсру WAN. Последний пересылает кадр адаптеру уда ленного доступа.
Все входящие соединения, инициированные клиентами для обращения к сериеру удаленного доступа, представляются одним адаптером Ч интерфейсом сервера HAS.
Для каждого исходящего соединения с клиентом удаленного доступа, иницииро ванного сервером, создается отдельный интерфейс.
Для приема вызовов сервер удаленного доступа командует всем минипорт-драй верам WAN уведомлять его об их переходе в состояние подключения (line-up state).
При поступлении вызова минипорт-драйвер WAN передает признак перехода в со стояние подключения компонентам TAPI через NDISWAN. Компоненты TAPI воз вращают описатель вызова драйверу NDISWAN для последующей ссылки на физи ческое соединение. Затем NDISWAN и компоненты удаленного доступа согласуют остальные параметры соединения удаленного доступа.
IP-, IPX- и AppleTalk-маршрутизатор Установив соединение удаленного доступа, клиент начинает посылать трафик по LAN-протоколам на сервер удаленного доступа или в сети, находящиеся за ;
ггим сервером. Если данные адресованы не серверу удаленного доступа, последний дол Удаленный доступ 230 ЧАСТЬ жен переслать LAN-трафик в место назначения. Для этого на сервере должны быть включены средства пересылки по используемым маршрутизируемым протоколам, и он должен работать в качестве IP-, IPX- и AppleTalk-маршрутизатора.
Пересылка пакетов между LAN-адаптерам и и интерфейсом минипорта WAN тре бует включения службы маршрутизации и удаленного доступа и ее настройки на поддержку соединений удаленного доступа типа точка-LAN.
Элементы архитектуры сервера удаленного доступа, необходимые для маршрути зации пакетов, иллюстрирует рис. 7-8. (Для упрощения схемы показана только IP маршрутизация. IPX- и AppIcTalk-маршрутизация осуществляется аналогичным образом.) :
AppleTalk IPX TCP/IP NOIS NQIS-SyS jNdiswan.sys Ми ни порт -драйвер Минипорт-драйвер I LAN WAN Рис. 7-8. IP-маршрутизация на сервере удаленного доступа Пакеты от клиентов удаленного доступа IP-пакеты, отправленные клиентом удаленного доступа, пересылаются сервером удаленного доступа следующим образом.
1. В зависимости от технологии удаленного доступа весь РРР-кадр или его отдель ные биты принимаются аппаратными средствами WAN и передаются соответ ствующему минипорт-драйверу WAN.
2. Минипорт-драйвер WAN передаст РРР-кадр драйверу Nd.iswan.sys.
3. Ndiswan.sys проверяет контрольную сумму РРР и по идентификатору РРР-про токола определяет, что это IP-дейтаграмма. Подробнее о РРР см. раздел РРР. далее в этой главе.
4. IP-дейтаграмма передается драйверу ТСРДР-протокола.
5. Драйвер TCP/IP-протокола, который поддерживает пересылку IP-пакетов, оп ределяет интерфейс пересылки и IP-адрес на основе IP-адреса получателя в IP дейтаграмме и своей таблицы маршрутизации.
6. Для пересылки IP-дейтаграммы через LAN-адаптер TCP/IP вызывает NDIS че рез. NdisSendQ, инструктируя эту функцию переслать IP-дейтаграмму через LAN-адаптер, Сервер удаленного доступа ГЛАВА 7. NDIS пересылает IP-дейтаграмму соответствующему минипорт-драйверу LAN.
8. Минипорт LAN пересылает IP-дейтаграмму LAN-адаптеру через NDIS.
В результате пакеты от клиента удаленного доступа пересылаются стандартным для IP-маршрутизации образом. Успешность пересылки IP-пакета зависит от того, най дет ли сервер удаленного доступа подходящую запись в своей таблице IP-маршру тизации. Таким образом, сервер удаленного доступа либо настраивается на исполь зование основного шлюза, либо на нем хранятся специфические маршруты ко всем адресам в интрасети, к которой он подключен. Нужные маршруты добавляются как статические, или же на сервере удаленного доступа разрешается применение одно го из протоколов маршрутизации.
Пакеты к клиентам удаленного доступа IP-пакеты, отправленные хостами интрасети клиенту удаленного доступа, пересы лаются сервером удаленного доступа следующим образом.
1. LAN-адаптер передает кадр соответствующему минипорт-драйверу LAN через NDIS. Подробное описание того, как IP-дейтаграмма пересылается на МАС-ад рес сервера удаленного доступа, см. в следующем разделе.
2. Минипорт-драйвер LAN передает IP-дейтаграмму драйверу ТСР/ТР-протокола через NDIS.
3. Драйвер TCP/ IP-протокол а, который поддерживает пересылку IP-пакетов, оп ределяет интерфейс пересылки и IP-адрес на основе IP-адреса получателя и IP дейтаграмме и своей таблицы маршрутизации. При подключении клиента уда ленного доступа в таблице маршрутизации создается запись о маршруте к хосту для IP-адреса, выделенного клиенту удаленного доступа, и эта запись указыва ет на интерфейс сервера RAS.
4. Для пересылки IP-дейтаграммы через WAN-адаптер TCP/IP вызывает NDIS функцию NdisSendQ, инструктируя ее переслать IP-дейтаграмму с использова нием NDISWAN и описателя конкретного соединения.
5. NDISWAN находит по описателю соединения конкретное устройство и порт, добавляет РРР-заголовок и концевую часть, а затем пересылает IP-дейтаграм му соответствующему минипорт-драйверу WAN' через ND1S, 6. Минипорт-драйвер WAN пересылает IP-дейтаграмму WAN-адаптеру через NDIS.
В результате пакеты от хостов интрасети пересылаются стандартным для 1Р-м;
фш рутизации образом. Успешность пересылки IP-пакетов зависит от того, достижимы ли IP-адреса клиентов удаленного доступа с хостов интрасети.
Выделение адресов из диапазона внутри или вне подсети Конкретный механизм разрешения MAC-адреса LAN-интерфейса сервера удален ного доступа IP-узлом подсети, к которой подключен этот сервер, зависит от спо соба выделения адресов сервером удаленного доступа.
Х Выделение адресов из диапазона внутри подсети (on-subnet addressing). Кли енты удаленного доступа получают IP-адреса из диапазона, определенного для подсети, к которой подключен сервер удаленного доступа. В этом случае исполь зуется подмножество адресов подсети сервера.
Удаленный доступ 232 ЧДСТЬ Х Выделение адресов из диапазона вне подсети (off-subnet addressing). Клиен ты удаленного доступа получают IP-адреса не из диапазона, определенного для подсети, к которой подключен сервер удаленного доступа, а из адресного про странства (отдельной подсети), уникального для данной интрасети.
Выделение адресов из диапазона внутри подсети и Proxy ARP Если адреса выделяются из диапазона внутри подсети, клиенты удаленного досту па логически находятся в той же подсети, что и сервер удаленного доступа. Для приема IP-дейтаграмм и их пересылки клиентам удаленного доступа сервер исполь зует Proxy ARP.
Proxy ARP применяется в двух случаях.
1. Сервер удаленного доступа сконфигурирован на получение IP-адресов, выделя емых клиентам удаленного доступа, от DHCP.
2. Сервер удаленного доступа настроен на использование статического пула IP адресов, являющегося подмножеством адресов подсети, к которой подключен этот сервер.
В обоих случаях клиенты удаленного доступа логически находятся в той же подсе ти, что и сервер удаленного доступа. Следовательно, IP-узлы в этой подсети, пере сылающие IP-дейтаграммы клиенту удаленного доступа, выполняют прямую дос тавку, посылая широковещательный кадр ARP-запроса об IP-адресе клиента уда ленного доступа.
Клиент удаленного доступа не может ответить па ARP-запрос, так как сервер уда ленного доступа не пересылает ему кадры ARP-запросов. Кроме того, у клиента нет МЛС-адреса, соответствующего интерфейсу соединения удаленного доступа.
В связи с этим сервер удаленного доступа сам посылает кадр ARP-отиета. в кото ром указывает собственный MAC-адрес, и IP-узел пересылает IP-дейтаграмму, ад ресованную клиенту удаленного доступа, на МАС-адрес сервера. После этого сер вер удаленного доступа пересылает IP-дейтаграмму клиенту удаленного доступа через соединение по коммутируемой ЛИРШИ, используя стандартный процесс IP маршрутизации.
Выделение адресов из диапазона вне подсети и IP-маршрутизация Если адреса выделяются из диапазона вне подсети, клиенты удаленного доступа логически находятся в отдельной подсети, достижимой через сервер удаленного доступа. В этом случае Proxy ARP не применяется. Сервер удаленного доступа вы ступает в роли маршрутизатора между подсетью клиентов удаленного доступа и подсетями, к которым он подключен. IP-узлы в LAN-подсетях, подключенных к серверу удаленного доступа, пересылают IP-дейтаграммы клиентам методом непря мой доставки, посылая широковещательный кадр ARP-запроса об IP-адресе не кли ента, а сервера удаленного доступа.
Чтобы удаленные клиенты были достижимы с IP-узлов интрасети, на маршрутиза торах интрасети должны быть маршруты, которые представляют диапазоны пула IP-адресов (выделяемых клиентам) и указывают на LAN-интерфейс сервера уда ленного доступа.
Сервер удаленного доступа ГЛАВА 7 При подключении первого клиента удаленного доступа в таблицу IP-маршрутиза ции сервера удаленного доступа добавляются маршруты, соответствующие диапа зонам адресов вне подсети и указывающие на интерфейс этого сервера. Если сер вер удаленного доступа использует какой-нибудь протокол IP-маршрутизации, он объявляет о новых маршрутах соседним маршрутизаторам. Если же сервер удален ного доступа не использует протокол IP-маршрутизации, новые маршруты придет ся добавлять на маршрутизаторы интрасети вручную.
Шлюз NetBIOS Windows 2000 включает шлюз NetBIOS для клиентов удаленного доступа, которые используют N e t B E U I в сочетании с протоколом удаленного доступа РРР или AsyBEUI. Этот шлюз позволяет удаленному клиенту, использующему NetBEUI, обращаться к любым NetBIOS-ресурсам, достижимым через сервер удаленного до ступа.
Благодаря шлюзу NetBIOS удаленный клиент может получить доступ к сетевым ресурсам, достижимым через сервер удаленного доступа, использующий:
Х NetBEUI;
Х NetBIOS поверх TCP/IP;
Х NetBIOS поверх IPX.
Шлюз NetBIOS отвечает за следующие процессы.
Х Управление NetBIOS-именами. При установлении первоначального соедине ния клиент удаленного доступа передает свое NetBIOS-имя, и оно добавляется в таблицу NetBIOS-имен на сервере удаленного доступа.
Х Передачу NetBIOS-пакетов от клиента удаленного доступа в LAN. 1С)гда клиент удаленного доступа посылает NetBIOS-пакеты по телефонной линии, они попадают на шлюз NetBIOS и передаются по протоколам, предоставляю щим сервисы NetBIOS.
Х Передачу NetBIOS-пакетов клиенту удаленного доступа из LAN. NetBIOS пакеты из локальной сети, передаваемые по любым протоколам, которые предо ставляют сервисы NetBIOS, проверяются на предмет наличия NetBIOS-имени компьютера клиента удаленного доступа и пересылаются этому клиенту с ис пользованием NetBEUI.
Примечание Шлюз NetBIOS не годится для доступа к сетевым ресурсам, отличным от NetBIOS, в частности к Web- и ЕТР-серверам, а также к другим типам сетевых ресурсов на основе Windows Sockets.
Архитектура шлюза NetBIOS на сервере удаленного доступа показана на рис. '7-9.
Удаленный доступ 234 ЧАСТЬ Сервер удаленного доступа Клиент удаленного доступ Шлюз NetBIOS NetBIOS NetBIOS | NetBT NBIPX IPX TCP/IP NetBEUI NDIS WAN Рис. 7-9. Шлюз NetBIOS PPP PPP (Point-to-Point Protocol) Ч стандартный метод передачи многопротокольных дейтаграмм по каналам связи типа точка-точка. РРР документирован в RFC 1661.
Служба маршрутизации и удаленного доступа хранит настройки РРР в разделе ре естра HKLM\System\CurrentControlSet\Services\RASMan\PPP.
РРР выполняет следующие функции.
Х Обеспечивает многопротокольную инкапсуляцию на канальном уровне.
РРР создает кадры, содержащие отдельные ГР-дейтаграммы, IPX-дейтаграммы или NetBEUI-кадры.
Х Устанавливает, поддерживает и закрывает логическое соединение, Для установления соединения канального уровня и настройки параметров РРР использует LCP (Link Control Protocol). Часть согласований по протоколу LCP состоит в аутентификации удостоверений клиента удаленного доступа.
Х Обеспечивает настройку протоколов.
После согласования параметров соединения канального уровня осуществляется настройка протоколов сетевого уровня (IP, IPX и AppleTalk). Например, в слу чае TCP/IP сервер удаленного доступа назначает IP-адрес клиенту удаленного доступа. Также согласуются сжатие и шифрование данных.
РРР-инкапсуляция При инкапсуляции многопротокольных дейтаграмм как полезных данных в РРР кадры применяется разновидность протокола ISO HDLC (High Level Data Link Control). РРР-заголовок и концевая часть таких кадров показаны на рис. 7-10 и содержат следующие поля.
Сервер удаленного доступа ГЛАВА Х Флаг. Устанавливается как Ох7Е (битовая последовательность 011И110) и по мечает начало и конец РРР-кадра. В РРР-кадрах под флаг отводится только один байт.
Х Адрес. В среде HDLC поле адреса используется для адресации кадра хосту-по лучателю. При работе с каналами связи типа точка-точка* указывать адрес по лучателя не требуется. Поэтому для РРР в поле адреса записывается OxFF признак широковещательной рассылки. Если обе стороны РРР-сеанса догова риваются о сжатии полей адреса и управления, поле адреса не включается.
Х Управление. В среде HDLC поле управления используется для упорядочения кадров и подтверждения их приема на канальном уровне. РРР не обеспечивает надежную передачу данных между каналами. Поэтому для всех РРР-кадров поле управления устанавливается как 0x03, что служит признаком ненумерованного информационного кадра. Если обе стороны РРР-сеанса договариваются о сжа тии полей адреса и управления, поле управления не включается.
Х Идентификатор протокола. Двухбайтовое поле, идентифицирующее протокол, данные которого передаются РРР в качестве полезной нагрузки. Если обе сто роны РРР-сеанса договариваются о сжатии поля идентификатора протокола, это ноле уменьшается до одного байта со значениями в диапазоне OxOO-OxFF.
Х PCS (Frame Check Sequence). 16-битная контрольная сумма, используемая для обнаружения ошибок в РРР-кадре на уровне отдельных битов. Если FCS, под считанный получателем, не совпадает с указанным в РРР-кадре, этот кадр мол ча отбрасывается.
Максимальный размер РРР-кадра, называемый максимальным получаемым бликом (maximum receive unit, MRU), определяется в процессе согласования параметров логического соединения. По умолчанию MRU равен 1500 байтам. Если принято меньшее значение, то на случай сбоя в синхронизации канала РРР-хост все равно должен иметь возможность принимать кадры длиной 1500 байтов.
Флаг Адрес Управление Идентификатор протокола Полезные данные РРР I OS Флаг =1 байт Рис. 7-10. РРР-инкапсуляция Типичные значения РРР-идентификаторов протоколов перечислены в таблице 7-6.
Удаленный доступ 236 ЧАСТЬ Таблица 7-fi. РРР-идентификаторы протоколов Протокол Идентификатор протокола/сжатое значение IP 0x0021 / 0 x 2 AppleTalk 0x0029 / 0x IPX Ox()02B / Ох2В Van Jacobsen Compressed TCP/IP Ox002D / Ox2D Multilink Ox003D / Ox3D NetBEUI Ox003F/Ox3F MPPC (Microsoft Point-to-Point OxOOFD / OxFD Compression Protocol) MPPE (Microsoft Point-to-Point OxOOFD / OxFD Encryption Protocol) Если в процессе согласования принят протокол МРРЕ или МРРС, идентификатор протокола устанавливается в OxOOFD. Так как для протоколов МРРЕ и МРРС ис пользуется один и тот же идентификатор, обе стороны сеанса должны знать, что содержимое РРР-кадра зашифровано и/или сжато.
Х Если принимается только МРРС, идентификатор протокола устанавливается в OxOOFD, а содержимое кадра сжимается.
Х Если принимается только МРРЕ, идентификатор протокола устанавливается в OxOOFD, а содержимое кадра шифруется.
Х Если принимается и МРРС, и МРРЕ, то сжатие всегда предшествует шифрова нию. Сжатый РРР-калр, состоящий из поля идентификатора протокола, уста новленного в OxFD, и сжатых полезных данных, шифруется и инкапсулируется еще одним РРР-заголовком, который включает поле идентификатора протоко ла, установленное в OxFD, и двухбайтовый МРРЕ-заголовок.
Предотвращение появления символа флага Символ флага создает одну проблему. Что если этот символ (Ох7Е) появится не только в начале и конце РРР-кадра, но и где-то еще? В РРР предусмотрено два способа предотвращения появления символа флага в зависимости от того, где ис пользуется РРР -- на асинхронном или синхронном канале.
РРР на асинхронных каналах На асинхронных каналах вроде аналоговых телефонных линий появление символа флага в РРР-калре предотвращается заменой символа. Если символ флага (Ох7Е) появляется не только в заголовке, но и в каком-либо другом месте РРР-кадра, от правитель заменяет его последовательностью Ox7D5E. Символ Ox7D известен как Escape-кол РРР. Если в РРР-кадре встречается Escape-код РРР, отправитель заме няет его последовательностью Ox7D5D. Получатель транслирует последовательно сти Ох7П5Г. обратно в Ох7Е, a Ox7D5D - в 6x7D.
Кроме того, коды символов со значениями менее 0x20 могут быть модифицирова ны, чтобы драйверы последовательных портов не интерпретировали их как управ ляющие символы. Если в процессе согласования по LCP принята такая модифика ция, то вместо символов, коды которых меньше 0x20, посылается последователь ГЛАВА 7 Сервер удаленного доступа ность Ох7В-[исходный символ с добавлением 6-го бита]. Например, байт 0x транслируется в Ox7D21.
РРР на синхронных каналах На синхронных каналах типа T-Camer, ISDN или других цифровых линиях появ ление символа флага в РРР-кадре предотвращается вставкой бита. Символ ф..ага представляет собой битовую последовательность 01111110. Вставка бита обеспечи вает появление шести единиц подряд только при посылке символа флага. Символ флага, когда он используется по назначению, не изменяется;
в остальных случаях битовая последовательность 111111 кодируется в несущей среде как 1111101, а би товая последовательность 111110 - как 1 1 1 1 1 0 0 (вставленные биты подчеркнуты).
При вставке бита один байт в несущей среде кодируется более чем восемью бита ми, но биты добавляются и удаляются аппаратными средствами поддержки синх ронного канала.
Согласование параметров РРР-канала по протоколу LCP РРР-протокол LCP (Link Control Protocol) документирован в RFC 1661. По этому протоколу согласуются параметры канала и РРР для динамической настройки ка нального уровня РРР-соединения. LCP позволяет договориться о РРР MRU, про токоле аутентификации, сжатии РРР-заголовков, ответном вызове и параметрах многоканального подключения.
Структура LCP-пакета РРР-идентификатор протокола LCP Ч ОхС021. Структура LCP-накета показана на рис. 7-11. Каждый пакет содержит одно сообщение LCP. которое состоит из поля кода, определяющего тип LCP-пакета, поля идентификатора, указывающего зш рос или ответ, поля длины, падающего размер LCP-пакета, и данных, специфичных для конкретного типа LCP-пакета.
Флаг Адрес Управление Идентификатор протокола Код LCP-пакет Идентификатор Длина Данные С!
Флаг = 1 байт Рис. 7-11. Структура LCP-пакета Типы LCP-пакстов, документированные в RFC 1661. перечислены в таблице 7-7.
238 ЧАСТЬ 2 Удаленный доступ Таблица 7-7. Типы LCP-пакетов Описание LCP-код Тип LCP-пакетз Configure-Re quest Посылается для открытия или сброса РРР-сосдинсния.
Configure-Request содержит список параметров LCP, чьи значе ния изменены по сравнению с предлагаемыми по умолчанию.
Configure-Ack Посылается, когда все значения всех параметров LCP после днего полученного пакета Configure-Request распознаны и приняты.
Согласование по протоколу LCP считается завершенным, когда обе стороны РРР-соединения отсылают и принимают пакет Configure-Ack.
3 Configure-Nack Посылается, когда все параметры LCP распознаны, но некото рые из их значений не приняты. Пакет Configure-Nack содер жит конфликтные параметры и их приемлемые значения.
Configure-Reject Посылается, когда параметры LCP не распознаны или не при няты. Пакет Configure-Reject содержит нераспознанные или несогласованные параметры.
Terminate- Request Посылается для закрытия РРР-соединения (не обязателен).
6 Terminate-Ac k Посылается в ответ па запрос Terminate-Request.
Посылается, если код LCP неизвестен. Сообщение Code-Reject V Code-Reject содержит конфликтный LCP-пакет.
8 Protocol-Reject Посылается, когда РРР-калр содержит неизвестный идентифи катор протокола. Сообщение Protocol-Reject включает конф ликтный LCP-пакет.
Пакет Protocol-Reject обычно посылается одной из сторон РРР-соединсния в ответ на РРР NCP для LAN-протокола, не поддерживаемого этой стороной.
9 Echo-Request Посылается для проверки РРР-соединения (не обязателен).
Посылается в ответ на запрос Echo-Request.
10 Echo-Reply РРР-сообщения Echo-Request и Echo-Reply не имеют никакого отношения к ICMP-сообщсниям Echo Request и Echo Reply.
Discard-Request Посылается для проверки канала в исходящем направлении (не обязателен).
Параметры LCP При использовании LCP-пакетов типа Configure-Request, Configure-Ack, Configure Nack и Configure-Reject раздел данных LCP состоит из одного или более парамет ров LCP, как показано на рис. 7-12. Каждый параметр LCP состоит из поля типа, поля длины (указывающего размер параметра в байтах) и данных, связанных с па раметром.
Стандартные параметры, согласуемые сторонами РРР-соединений, перечислены в таблице 7-8. О других параметрах LCP см. RFC 1661.
Таблица 7-8. Параметры LCP Имя параметра Тип Длина Описание M a x i m u m Receive Unit Максимальный размер РРР-кадра !
(MRU) (максимальный (до 65 535 байтов). MRU но умолчанию Ч 1500.
получаемый блок) Если ни одна из сторон не меняет значение по умолчанию, параметр не согласовывается.
ГЛАВА 7 Сервер удаленного доступа Таблица 7-8. (продолжение) Имя параметра Тип Длина Описание 'Х' Asynchronous Control 6 Битовая карта, которая включает (бит установ Character Map (ACCM) лен) или отключает (бит сброшен) использона (таблица управляющих ние 32 управляющих ASCII-символов (от 0x до 0x20) в качестве Escape-кодов при асинхр!>н символов для асинхрон ных соединений) ных соединениях. Escape-коды используются по умолчанию. Для каналов с программным управ лением потоком XON/XOFF битовая карта АССМ устанавливается как 0x00000000.
5 Протокол, используемый на этапе аутентифика Authentication Protocol '.'> (протокол аутентификации) или 6 ции в процессе установления соединения.
Стороны соединения Microsoft PPP указывают в этом параметре одно из следующих значенлй:
ОхС227 (ЕАР). ОхС22380 (MS-CHAP версии 1), ОхС22381 (MS-CHAP версии 2), ОхС (MD5-CHAP), ОхС027 (SPAP) или ОхС023 (РАР).
II Случайное число, выбираемое для того, чтобы Magic Number различать стороны соединения и обнаруживать (волшебный номер) замкнутые на себя линии (looped back lines).
Флаг, указывающий, что двухбайтовый ' Protocol Compression РРР-идентификатор протокола сокращается (сжатие протокола) до одного октета, если он находится в диапазоне OxOOOO-OxOOFF.
2 Флаг, указывающий, что поля адреса (всегда Address and Control Field OxFF) и управления (всегда 0x03) удаляются Compression (сжатие полей из РРР-заголовка.
адреса и управления) Callback (ответный вызов) 13, 3 Параметр (размером в один октет), указывав > или щий, как настраивается функция ответного иызо OxOD ва. Для клиентов и серверов удаленного доступа под управлением 32-битных операционных сис тем Microsoft Windows этот параметр равен 11x06.
Это означает, что функция ответного вызова настраивается в процессе согласования по прото колу СВСР (Callback Control Protocol).
Флаг Адрес Управление Идентификатор протокола Код Идентификатор Длина Тип Длина Г " Параметры LCP Данные параметра FCS Флаг I.7E Рис. 7-12. Параметры LCP Удаленный доступ 240 ЧАСТЬ LCP-процесс согласования LCP-пропссс согласования представляет собой обмен серией LCP-пакетов между сторонами РРР-соединения для определения набора параметров и их значений, LCP-согласование Ч это два отдельных диалога между сторонами РРР-соединения.
1. Сторона 1 запрашивает, согласует, а затем получает подтверждение о парамет рах LCP, которые будут использоваться для передачи данных стороне 2. Этот диалог начинается с того, что сторона 1 посылает сообщение Configure-Request, и заканчивается, когда сторона 2 присылает сообщение Configure-Ack, 2. Сторона 2 запрашивает, согласует, а затем получает подтверждение о парамет рах LCP, которые будут использоваться для передачи данных стороне 1. Этот диалог начинается с того, что сторона 2 посылает сообщение Configure-Request, и заканчивается, когда сторона 1 присылает сообщение Configure-Ack.
Стороны 1 и 2 не обязательно используют одинаковые параметры LCP.
Когда одна из сторон РРР-соединения посылает первоначальный запрос Configure Request, в ответ может быть получено одно из следующих сообщений:
Х С on figure- Kac k - один или несколько параметров имеют неприемлемые значения;
Х Configure-Reject Ч один или несколько параметров не известны, или их нельзя согласовать;
Х Configure-Ack Ч все параметры имеют приемлемые значения.
Сторона РРР-соединения, получив сообщение Cont'igure-Nack или Configure-Reject в ответ на Configure-Request, посылает новое сообщение Configure-Request с изме ненными параметрами или значениями параметров. После приема сообщения Configure-Ack сторона РРР-соединения готова передавать данные.
Гипотетический LCP-процесс согласования для стороны 1, использующей фиктив ные параметры W, X, Y, Z, показан на рис. 7-13.
Сторона W ;
onfigure-Request: W, X=100. Y = 0, Z аЛЫЯаГЖНаНЯаЯПяя >1Па11№>№>НМЛЛ&аЯЖЯьЯаЛЯ#ЯЖ&. ;
, ;
,Д;
^ Configure-Reject;
Z Configure-Request: W, X=100. Y = Configure-Request: W, X=200, Y = Configure-Ack: W, X=200. Y= Рис. 7-13. Пример LCP-согласования Сервер удаленного доступа ГЛАВА 7 1. Сторона 1 посылает сообщение Configure-Request с запросом параметров W и Z, а также параметров X со значением 100 и У со значением 0. Параметры W и Z Ч флаги.
2. Сторона 2 не понимает параметр Z и посылает сообщение Configure-Reject с этим параметром.
3. Сторона 1 посылает повое сообщение Configurc-Requcst с запросом параметра W, а также параметров X со значением 100 и У со значением О, 4. Сторона 2 предпочитает установить для параметра X значение 200 и посылает сообщение Configure-Nack с параметром X и его предлагаемым значением.
5. Сторона 1 посылает новое сообщение Configure-Request с запросом параметра W, а также параметров X со значением 200 и У со значением 0.
6. Сторона 2 посылает сообщение Configure-Ack.
Всякий раз, когда сторона 1 посылает новое сообщение Configure-Request, она из меняет значение в поле идентификатора в LCP-заголовке. Это позволяет связать сообщения Configure-Request с ответами на них.
В процессе, показанном на рис. 7-13, осуществляется настройка лишь того, как с го рона 1 передает данные стороне 2. Чтобы сторона 2 могла передавать данные с го ронс 1, требуется отдельное согласование;
очень часто эти два процесса проходят одновременно.
Согласование параметров ответного вызова по протоколу СВСР Протокол СВСР (Callback Control Protocol) позволяет согласовать использование ответного вызова сервером удаленного доступа: после аутентификации клиента удаленного доступа сервер разрывает физическое соединение, ждет заданный пе риод времени и перезванивает клиенту по статически или динамически указывае мому номеру. Телефонный номер, используемый сервером для обратного вызова клиента, входит в стандартные параметры СВСР. Подробнее о СВСР см. документ Proposal for Callback Control Protocol (СВСР) но ссылке Internet Working Group на Структура пакетов РРР-идентификатор протокола СВСР Ч ОхС029. Структура СВСР-пакетов точно повторяет структуру LCP-пакетов, однако используются только Callback-Request (тип 1), Callback-Response (тип 2) и Callback-Ack (тип 3). Во всех СВСР-пакетах раздел данных состоит из одного или более параметров СВСР, а каждый параметр СВСР Ч из поля типа параметра, поля длины (указывающего общий размер пара метра в байтах) и данных, связанных с этим параметром.
Согласуемые параметры Параметры СВСР, согласуемые сторонами соединения Microsoft РРР, перечислены в таблице 7-9.
Таблица 7-9. Параметры СВСР Имя параметра Тип Длина Описание No callback (ответный 1 2 Указывает, что для данного соединения вызов отключен) ответный вызов не используется 9 Зак. 334.1 (см. след, стр.) Удаленный доступ 242 ЧАСТЬ Таблица 7-9. (продолжение) Тип Длина Описание Имя параметра Callback to a user-specified 2 Переменная Номер ответного вызова определяет number (ответный вызов пользователь компьютера Ч клиента удаленного доступа но номеру, заданному пользователем) Callback Lo an administrator- 3 Переменная Номер ответного вызова определяется defined number (ответный параметрами сервера удаленного доступа вызов по номеру, заданному администратором) Callback to any of a list of 4 Переменная Сервер удаленного доступа выполняет numbers (ответный вызов ответный вызов по одному из номеров, по любому номеру из списка) указанных в списке Согласование параметров РРР сетевого уровня по протоколу NCP Установив связь и согласовав параметры РРР по протоколу LCP, стороны РРР-со единения согласуй.)! параметры индивидуальных LAN-протоколов, используя набор NCP-протоколов (Network Control Protocols). Microsoft РРР поддерживает следу ющие NCP-протоколы:
Х IPCP (Internet Protocol Control Protocol) Ч для согласования применения IP и его параметров;
Х IPXCP (Internetwork Packet Exchange Control Protocol) Ч для согласования при менения IPX и его параметров;
Х АТСР (AppleTalk Control Protocol) Ч для согласования применения AppleTalk и его параметров;
Х NBFCP (NetBIOS Frames Control Protocol) Ч для согласования применения NetBEUI и его параметров.
IPCP Протокол IPCP в том виде, в каком он используется сторонами соединения Micro soft РРР, документирован в RFC 1332 и 1877. По этому протоколу согласуются па раметры IP для динамической настройки TCP/IP на сторонах соединения типа точка-точка. Стандартные параметры IPCP включают IP-адрес, выделяемый кли енту, и IP-адреса серверов DNS- и NetBIOS-имен.
Структура пакетов РРР-идентификатор протокола IPCP Ч 0x8021. Структура IPCP-пакетов точно повторяет структуру LCP-иакетов (с тем исключением, что определены лишь типы 1-7). В случае IPCP-накетов Configure-Request, Configure-Ack, Con figure-Nack и Configure-Reject раздел данных IPCP состоит из одного или более параметров IPCP, а каждый параметр IPCP Ч из поля типа параметра, поля длины (указываю щего общий размер параметра в байтах) и данных, связанных с этим параметром.
Согпасуемые параметры Параметры IPCP, согласуемте сторонами соединения Microsoft РРР, перечислены в таблице 7-10.
Сервер удаленного доступа ГЛАВА 7 Таблица 7-Ю. Параметры IPCP Имя параметра Длина Описание Тип IP compression protocol Протокол сжатия Van Jacobsen TCP (протокол сжатия для IP) IP address (IP-адрес) IP-адрес, который должен быть 3 назначен клиенту удаленного доступа Primary DNS server address Адрес основного DNS-сервера для 129, (адрес основного DNS-сервера) клиента удаленного доступа или 0x Адрес основного сервера NBNS (WINS) Primary NBNS server address 130, 1.
или 0x (адрес основного NBNS-сервера) для клиента удаленного доступа Secondary DNS server address Адрес дополнительного DNS-сервера 131. (адрес дополнительного или 0x83 для клиента удаленного доступа DNS -сервера) Secondary NBNS server address Адрес дополнительного сервера NBNS 132, 1) или 0x (адрес дополнительного (WINS) для клиента удаленного NBNS-сервера) доступа Заметьте, что в протоколе IPCP не предусмотрены параметры для следующих стан дартных настроек TCP/IP.
Х Для маски подсети. Клиент удаленного доступа определяет маску подсети, ис ходя из того предположения, что ему назначен IP-адрес на основе классов сетей.
Х Для основного шлюза. Сервер удаленного доступа не назначает IP-адрес основ ного шлюза. Но на клиенте создается маршрут по умолчанию, указывающий на соединение удаленного доступа. Если в таблице маршрутизации уже имеется какой-нибудь маршрут по умолчанию, тогда метрика существующего маршрута по умолчанию увеличивается на 1 и создается новый маршрут по умолчанию с меньшей метрикой. Это стандартное поведение клиентов удаленного доступа иод управлением 32-разрядных операционных систем Windows. Его можно из менить, сбросив флажок Use Default Gateway on Remote Network (Использо вать основной шлюз в удаленной сети) в дополнительных свойствах TCP/IP для данного подключения удаленного доступа.
Х Для доменного DNS-имени. Доменное DNS-имя настраивается в свойствах TCP/IP на сервере удаленного доступа и поэтому по протоколу IPCP не согла совывается. Клиенты удаленного доступа под управлением Windows 2000 полу чают доменное DNS-имя через сообщения DHCPInform (см. раздел Удаленный доступ и настройка TCP/IP и IPX далее в этой главе).
Х Для типа NetBIOS-узла. Если стороны договариваются об IP-адресах основных и дополнительных серверов NetBIOS-имен, автоматически используется гиб ридный тип NetBIOS-узла (Н-узел).
IPXGP Протокол IPXCP в том виде, в каком он используется сторонами соединения Microsoft PPP, документирован в RFC 1552. По этому протоколу согласуются па раметры IPX для динамической настройки IPX на сторонах соединения типа тач ка-точка. Стандартные параметры IPXCP включают номера IPX-сети и узла.
244 ЧАСТЬ 2 Удаленный доступ Структура пакетов РРР-идентификатор протокола IPXCP Ч Ох802В. Структура ТРХСР-гтаксгов точно повторяет структуру LCP-пакетов (с тем исключением, что определены лишь типы 1-7). В случае IPXCP-пакетов Configure-Request, Configure-Ack, Configure-Nack и Configure-Reject раздел данных IPXCP состоит из одного или более параметров IPXCP, а каждый параметр IPXCP Ч из ноля типа параметра, поля длины (указы вающего общий размер параметра в байтах) и данных, связанных с этим парамет ром.
Согласуемые параметры Параметры IPXCP. согласуемые сторонами соединения Microsoft РРР, перечисле ны в таблице 7-11.
Таблица 7-11. Параметры IPXCP Имя параметра Длина Описание Тип IPX Network Number 6 Номер IPX-сети для клиента удаленного (номер IPX-сети) доступа ;
IPX Node Number 6 Номер IPX-узла для клиента удаленного Х (номер IPX-узла) доступа АТСР Протокол АТСР в том виде, в каком он используется сторонами соединения Micro soft РРР, документирован в RFC 1378. По этому протоколу согласуются параметры AppleTalk для динамической настройки AppleTalk на сторонах соединения типа точка-точка*. Стандартные параметры АТСР включают AppleTalk-адрес и инфор мацию о сервере.
Структура пакетов РРР-идентификатор протокола АТСР Ч 0x8029. Структура АТСР-пакетов точно повторяет структуру LCP-пакетов (с тем исключением, что определены лишь типы 1-7). В случае АТСР-пакетов Configure-Request, Configure-Ack, Configure-Nack и Configure-Reject раздел данных АТСР состоит из одного или более параметров АТСР, а каждый параметр АТСР Ч из поля типа параметра, поля длины (указыва ющего общий размер параметра в байтах) и данных, связанных с этим параметром.
Согласуемые параметры Параметры АТСР, согласуемые сторонами соединения Microsoft РРР, перечислены в таблице 7-12.
Таблица 7-12. Параметры АТСР Имя параметра Тип Длина Описание AppleTalk Address I 6 Позволяет согласовать номера AppleTaIk-сети (AppleTalk-адрес) и узла Server Information 3 16 Используется для передачи информации (информация о сервере) о сервере удаленного доступа ГЛАВА 7 Сервер удаленного доступа NBFCP Протокол NBFCP в том виде, в каком он используется сторонами соединения Microsoft PPP, документирован в RFC 2097. По-этому протоколу согласуются па раметры NetBEUI для динамической настройки NetBEUI на сторонах соединения типа точка-точка. Стандартные параметры NBFCP включают параметры фильт рации групповой рассылки и информацию о сторонах соединения.
Структура пакетов РРР-идентификатор протокола NBFCP Ч Ox803F. Структура NBFCP-пакетов точ но повторяет структуру LCP-пакетов (с тем исключением, что определены лишь типы 1-7). В случае NBFCP-пакетов Configure-Request, Configure-Ack, Configiire Nack и Configure-Rejecc раздел данных NBFCP состоит из одного или более пара метров NBFCP. а каждый параметр NBFCP Ч из поля типа параметра, поля длины (указывающего общий размер параметра в байтах) и данных, связанных с этим параметром.
Согласуемые параметры Параметры NBFCP, согласуемые сторонами соединения Microsoft PPP, перечисле ны в таблице 7-13.
Таблица 7-13. Параметры NBFCP Имя параметра Тип Длина Описание Multicast filtering (фильтрация 3 5 Позволяет согласовать обработку групповой рассылки) групповых пакетов Peer information (информация 2 17 Используется для передачи сведений о сторонах соединения) о конфигурации NetBIOS ССР Протокол ССР (Compression Control Protocol) в том виде, в каком он использует ся сторонами соединения Microsoft PPP, документирован в RFC 1962. По этому протоколу согласуются параметры для динамической настройки, включения и от ключения алгоритмов сжатия данных, передаваемых между сторонами соединения тина точка-точка*-. Стандартные параметры ССР Ч идентификатор организации и признак использования МРРС.
Структура пакетов РРР-идентификатор протокола ССР Ч OxSOFD. Структура ССР-пакетов точно по вторяет структуру LCP-пакетов (с тем исключением, что определены лишь типы 1-7). В случае ССР-пакетов Configure-Request, Configure-Ack, Configure-Nack и Configure-Reject раздел данных ССР состоит из одного или более параметров ССР, а каждый параметр ССР Ч из поля типа параметра, поля длины (указывающего общий размер параметра в байтах) и данных, связанных с этим параметром.
Согласуемые параметры Параметры ССР, согласуемые сторонами соединения Microsoft PPP, перечислены в таблице 7-14.
Удаленный доступ 246 ЧАСТЬ Таблица 7-14. Параметры ССР Имя параметра Длина Тип Описание Organization Unique Identifier Используется для согласования 0 (уникальный идентификатор и более особого протокола сжатия данных, организации) применяемого в организации Служит признаком использования МРРС 18, МРРС и МРРЕ, а также указывает или 0x стойкость шифрования МРРЕ и МРРС ССР-параметр 18 позволяет сторонам соединения Microsoft PPP одновременно со гласовать применение протоколов МРРЕ и МРРС. Длина поля данных ССР-пара метра 18 равна 4 байтам (32 битам). Биты этого поля являются флагами:
Х 0x00-00-00-01 Ч используется сжатие данных;
Х 0x00-00-00-10 Ч 40-битный сеансовый ключ получен из LAN Manager-версии пароля пользователя;
Х 0x00-00-02-00 - 40-битный сеансовый ключ получен из Windows NT-версии пароля пользователя;
Х 0x00-00-00-80 Ч 56-битный сеансовый ключ получен из Windows NT-версии пароля пользователя;
Х 0x00-00-00-40 Ч 128-битный сеансовый ключ получен из Windows NT-версии пароля пользователя;
Х 0x01-00-00-00 Ч шифровальные ключи обновляются для каждого РРР-кадра.
При выборе сразу нескольких конфигураций значения флагов суммируются. Так, при включении сжатия (0x00-00-00-01) и использовании 128-битных ключей (0x00 00-00-40) 32-битное поле данных будет выглядеть как 0x00-00-00-41.
Подробнее о МРРЕ см. Интернет-проект Microsoft Point-To-Point Encryption (МРРЕ) Protocol*, ЕСР Протокол ЕСР (Encryption Control Protocol) используется для согласования конк ретного метода шифрования и документирован в RFC 1968. Однако в случае со единения Microsoft PPP для шифрования данных поддерживается только МРРЕ, применение которого указывается в ССР-параметре МРРС.
Процесс РРР-соединения Согласование РРР-соединения проходит в четыре этапа:
Х настройка РРР;
Х аутентификация;
Х ответный вызов;
Х конфигурирование протоколов.
Сервер удаленного доступа ГЛАВА Этап 1: настройка РРР Параметры РРР согласуются по протоколу LCP. В начальной фазе LCP-прощ сса каждая сторона согласует коммуникационные параметры, необходимые для пере дачи данных:
Х параметры РРР Ч MRU, сжатие полей адреса, управления и идентификатора протокола;
Х протокол, по которому будет аутентифицироваться клиент удаленного досту па (протокол только выбирается, но не применяется до начала этапа аутенти фикации);
Х параметры многоканального подключения (если таковое используется).
Этап 2: аутентификация По окончании LCP-процесса клиент и сервер удаленного доступа выполняют аутен тификацию по ранее согласованному протоколу. На этом этапе весь трафик между клиентом и сервером связан с работой РРР-протокола аутентификации (см. раздел РРР-протоколы аутентификации далее в этой главе).
Этап 3: ответный вызов Microsoft-реализация РРР предусматривает необязательный этап согласования от ветного вызова по протоколу СВСР. Чтобы клиент удаленного доступа полу шл ответный вызов, в параметрах входящих звонков пользовательской учетной запи си нужно разрешить применение функции ответного вызова. Номер для ответного вызова указывается клиентом или сервером удаленного доступа.
Если при подключении используется ответный вызов, то после первого соедине ния обе стороны РРР-соединения кладут трубку, после чего сервер удаленного доступа перезванивает клиенту по заданному номеру.
Этап 4: конфигурирование протоколов Последний этап заключается в согласовании протоколов сетевого уровня. При уда ленном доступе под управлением 32-разрядных операционных систем Windows сер вер удаленного доступа посылает клиенту сообщения Configuration-Request, пере числяя все LAN-протоколы, используемые на этом сервере. Клиент удаленного до ступа либо продолжает согласование LAN-протоколов, либо посылает LCP-сообще пие Protocol-Reject с одним из принятых сообщений Configuration-Request, тем са мым указывая, что данный LAN-протокол им не поддерживается.
После LCP-согласования протоколов сетевого уровня начинается очень похожее согласование остальных протоколов сетевого уровня по IPCP, ТРХСР, АТС? и NBFCP. Для настройки МРРС и МРРЕ стороны обмениваются ССР-пакетами.
Пример РРР-соединения Наглядно увидеть процесс установления РРР-соединения позволяют:
Х Network Monitor (Сетевой монитор) Ч инструмент для захвата и анализа сете вого трафика. С его помощью можно захватывать все РРР-пакеты, посылаемые по последовательной линии, в том числе пакеты, передаваемые при установле нии соединения, и пакеты с инкапсулированными пользовательскими данными;
Удаленный доступ 248 ЧАСТЬ Х средства трассировки РРР Ч используются для протоколирования обмена РРР пакетами в процессе установления РРР-соединения.
Network Monitor Для захвата РРР-пакетов средствами Network Monitor (Сетевой монитор) укажите в качестве наблюдаемой сеть, соответствующую удаленному соединению. Network Monitor используется, чтобы:
Х выявить причину проблем в процессе установления РРР-соединения;
Х убедиться в шифровании полезных данных РРР;
Х убедиться в сжатии полезных данных РРР.
Примечание Полезные данные РРР не интерпретируются Network Monitor, если применяется их сжатие или шифрование, на что указывает РРР-идептификатор протокола, равный Ox3D (что предполагает сжатие поля идентификатора протоко ла). Для просмотра структуры пользовательских данных РРР нужно отключить сжатие и шифрование этих данных.
Используя Network Monitor, учтите следующие соображения.
Х Захваченные РРР-кадры не содержат символа флага, но включают Ethernet-по добные адреса источника и получателя. Это связано с тем, что Network Monitor получает пакеты от драйвера Ndiswan.sys. Вспомните: Ndiswan.sys Ч это промежу точный NDIS-драйвер, который протоколы воспринимают как Ethernet-адаптер.
Для каждого РРР-кадра Ethernet-подобные адреса источника и получателя ус танавливаются как SEND или RECV, указывая, что РРР-кадр был передан или принят данным компьютером. Адреса SEND и RECV не обязательно идентифи цируют трафик сервера или клиента удаленного доступа. Если захват осуществ ляется на сервере удаленного доступа, кадры SEND передаются сервером, а RECV Ч клиентом. Если же захват выполняется на клиенте удаленного досту па, кадры SEND передаются клиентом, а кадры RECV Ч сервером.
Х Захваченные РРР-кадры содержа']' поля адреса и управления независимо от того, было ли согласовано сжатие этих полей.
Х Обычно стороны РРР-соединения договариваются о сжатии поля идентифика тора протокола, уменьшая его длину до одного байта, если это возможно.
Х Для просмотра трафика, относящегося лишь к определенным протоколам, ис пользуйте фильтрацию данных, отображаемых Network Monitor. Например, для просмотра трафика, связанного только с IPCP-процессом согласования, на стройте фильтры отображения пак, чтобы они пропускали данные, относящиеся исключительно к IPCP.
Ниже приведен пример распечатки, полученной с помощью Network Monitor в про цессе установления РРР-соединения. Здесь даны лишь суммарные сведения о кад рах. Для лучшего восприятия записи показываются с отступами.
1 8.726 SEND SEND LCP Conflg Req Packet, Ident = 0x00, Length = 2 8.796 RECV RECV LCP Corifig Req Packet. Ident = 0x00, Length = ГЛАВА 7 Сервер удаленного доступа 3 8,796 SEND SEND LCP Config Ack Packet, Ident = 0x00, Length = Х1 8.816 RECV RECV LCP Config Reject Packet, Ident = 0x00, Length = 5 8.816 SEND SEND LCP Config Req Packet, Ident = 0x01, Length = G В. 886 RECV RECV LCP Config Ack Packet, Ident = 0x01, Length =, 6.886 SEND SEND LCP Ident Packet, Ident = 0x02, Length = 8 8.886 SEND SEND LCP Ident Packet, Ident = 0x03, Length = Х 8.886 RECV RECV PPPCHAP Challenge, ID = Ox 1 : Challenge 8. 1C SEND SEND PPPCHAP Challenge, ID = Ox 1: Response, administrator Ii 8.976 RECV RECV PPPCHAP Challenge, 10 = Ox 1 : Success i:.;
В. 976 RECV RECV CBCP Callback Request, Ident = 0x 13 8.976 SEND SEND CBCP Callback Response, Ident = 0x 14 8.996 RECV RECV CBCP Callback Acknowledgement, Ident = 0x 15 8.996 SEND SEND CCP Configuration Request, Ident = 0x 8.997 SEND SEND IPCP К Configuration Request, Ident = 0x 17 8.997 RECV RECV CCP Configuration Request, Ident = 0x 9. И RECV RECV IPCP Configuration Request, Ident = 0x 9.037 RECV RECV IPXCP 1U Configuration Request, Ident = 0x 9.037 RECV RECV NBFCP Configuration Request, Ident = 0x 9. 21 SEND SbND IPXCP Configuration Request, Ident = 0x :v 9.147 SEND SEND CCP Configuration Acknowledgement, Ident = 0x 9.147 SEND SEND IPCP Configuration Acknowledgement, Ident = 0x 9.167 SEND SEND IPXCP Configuration Acknowledgement, Ident = 0x 9. 25 SEND SEND LCP Protocol Reject Packet, Ident = 0x07, Length = 9. 26 RECV RECV CCP Configuration Reject, Ident = 0x 9.237 RECV RECV IPCP Configuration Reject, Ident = 0x 9.237 SEND SEND IPCP Configuration Request, Ident = 0x 9.257 RECV RECV IPXCP Configuration No Acknowledgement, Ident = 0x Удаленный доступ 250 ЧАСТЬ 30 9.257 SEND SEND IPXCP Configuration Request, Ident = 0x 31 9.287 RECV RECV IPCP Configuration No Acknowledgement, Ident = 0x 32 9.287 SEND SEND IPCP Configuration Request, Ident = OxOA 33 9.287 RECV RECV IPXCP Configuration Acknowledgement, Ident = 0x 34 9.327 RECV RECV IPCP Configuration Acknowledgement, Ident = OxOA 35 10.729 SEND SEND CCP Configuration Request, Ident = 0x 36 10.960 RECV RECV CCP Configuration Reject, Ident = 0x 37 10.960 SEND SEND CCP Configuration Request, Ident = OxOB 38 10.960 RECV RECV CCP Configuration Acknowledgement, Ident = OxOB Трассировка была проведена на клиенте удаленного доступа. То есть кадры SEND передавались клиентом, а кадры RECV Ч сервером удаленного доступа. В данном случае представлены все четыре этапа установления РРР-соединения:
Х этап 1 Ч настройка РРР (кадры 1-8) путем обмена конфигурационными LCP пакетами;
Х этап 2 Ч аутентификация (кадры 9-11), в ходе которой проверялись удостове рения пользователя;
Х этап 3 Ч настройка ответного вызова (кадры 12-14);
Х этап 4 Ч согласование протоколов (кадры 15-38) с настройкой на использова ние сжатия и шифрования данных, а также протоколов IP и IPX.
Кроме просмотра суммарной информации, Network Monitor позволяет разворачи вать* кадры для детального анализа. Например, кадр 1 из предыдущего листинга выглядит так:
FRAKE: Base frame properties FRAME: Time of capture = Nov 18, 1998 15:23:6. FRAKE: Time delta from previous physical frame: 0 milliseconds FRAME: Frame number: FRAME: Total frame length: 50 bytes FRAME;
Capture frame length: 50 bytes FRAME: Frame data: Number of data bytes remaining = 50 (0x0032) PPP: Link Control Protocol Frame (OxC021) PPP: Destination Address = SEND_ PPP: Source Address = SEND.
PPP: Protocol = Link Control Protocol LCP: Config Req Packet, Ident = 0x00, Length = LCP: Code = Configuration Request LCP: Identifier = 0 (0x0) LCP: Length = 36 (0x24) LCP: Options: ASYNC.HAP:00 00 00 00-MAGICfl:OxOC05-PROT.COMP-ADR/CF.COMP CALL.BACK;
Unkn-- LCP: ASYNC.MAP:00 00 00 LCP: Option Type = Async Control Character Map Сервер удаленного доступа ГЛАВА LCP: Option Length = 6 (0x6) LCP: Async Control Character Map = 00 00 00 LCP: MAGIC:OxOCOS LCP: Option Type = Majic Number LCP: Option Length = 6 (0x6) LCP: Magic Number = 3077 (OxCOS) LCP: PROT.COMP LCP: Option Type = Protocol Field Compression LCP: Option Length = 2 (0x2) LCP: AOR/CF.COHP LCP: Option Type = Address and Control Field Compression LCP: Option Length = 2 (0x2) LCP: CALL.BACK:Unkn LCP: Option Type = Callback LCP: Option Length = 3 (0x3) LCP: CallBack = 0x LCP: Multilink Maximum Receive Reconstructed Unit LCP: Option Type = 0x LCP: Option Length = 4 (0x4) LCP: Multilink Endpoint Discriminator LCP: Option Type = 0x LCP: Option Length = 9 (0x9) Данные, захваченные Network Monitor, можно сохранить в виде файлов и отпра вить специалистам Microsoft по технической поддержке для последующего анализа.
Трассировка РРР Средства трассировки, поддерживаемые компонентами удаленного доступа и мар шрутизации, позволяют регистрировать выполняемый программный код или сете вые события с записью в файл.
Трассировка РРР включается через оснастку Routing and Remote Access (Маршру тизация и удаленный доступ) установкой флажка Enable Point-to-Point Protocol (РРР) Logging (Вести журнал протокола РРР) на вкладке Event Logging (Жур нал событий) окна свойств сервера удаленного доступа.
Файл Ppp.log создается в папке %SystemRoot%\Tracing и содержит информацию о процессе установления РРР-соединения. Журнал РРР, генерируемый средствами трассировки, включает вызовы функций и содержимое РРР-пакетов протоколов управления РРР. Трассировка РРР не годится для просмотра пользовательских дан ных, посылаемых по РРР-соединению.
Ниже приведен фрагмент журнала трассировки РРР, полученного в процессе уста новления РРР-соединения. Для лучшего восприятия записи показываются с отсту пами.
[1472] 15:57:50:094: Line up event occurred on port [1472] 15:57:50:104: Starting PPP on link with IfType=OxO,IPIf=OxO, IPXIf=OxO [1472] 15:57:50:104: RasGetBuffer returned ae70054 for SendBuf [1472] 15:57:50:104: Fsmlnit called for protocol = c021, port = [1472] 15:57:50:104: Configlnfo = 273e [1472] 15:57:50:104: APs available = [1472] 15:57:50:104: FsmReset called for protocol = c021, port = [1472] 15:57:50:104: Inserting port in bucket ft Удаленный доступ 252 ЧДСТЬ [1472] 15:57:50:104: Inserting bundle in bucket tt [1472] 15:57:50:104: FsmOpen event received for protocol c021 on port [1472] 15:57:50:104: FsfflThisLayerStarted called for protocol = c021, port = [1472] 15:57:50:104: FsmUp event received for protocol c021 on port [1472] 15:57:50:104:
Таблица 7-15. Анализ LCP-пакета Configuration-Request Байты Описание РРР-идентификатор протокола для LCP СО LCP-код сообщения Configure-Request LCP-идентификатор данного сообщения Configure-Request Длина LCP-пакета в байтах (в данном случае Ч 36 байтов) LCP-парамстр Asynchronous Control Character Map (ACCM) Длина параметра АССМ в байтах Данные параметра ЛССМ 00 00 00 LCP-параметр для волшебного номера Длина параметра для волшебного номера в байтах Данные параметра для волшебного номера 00 00 СО LCP-параметр для сжатия протокола иХ Длина параметра для сжатия протокола в байтах LCP-параметр для сжатия полей адреса и управления иХ Длина параметра для сжатия полей адреса и управления в байтах Сервер удаленного доступа ГЛАВА Таблица 7-15. (продолжение) Байты Описание OD LCP-параметр для ответного вызова 03 Длина параметра для ответного вылова в байтах 06 Данные параметра для ответного вызова IXZP-парамстр Multilink Maximum Receive Reconstructed Unit;
LCP-пара метры для многоканальных подключений рассматрива ются в разделе Multilink и ВАР далее в этой главе 04 Длина параметра Multilbik Maximum Receive Reconstructed Un.t в байтах 06 4E Данные параметра Multilink Maximum Receive Reconstructed Unit 13 LCP-параметр M u l t i l i n k Endpoint Discriminator 09 Длина параметра Multilink Endpoint Discriminator в байтах 03 00 60 08 52 F9 D8 Данные параметра Multilink Endpoint Discriminator Как видите, Network Monitor Ч более простой инструмент для интерпретации РРР трафика. Однако средства трассировки РРР предоставляют цепную информацию о взаимодействии внутренних компонентов, что может оказаться весьма полезным при устранении проблем с соединениями. Если Вы в чем-то сомневаетесь, исполь зуйте данные, захваченные Network Monitor, в сочетании с трассировкой РРР.
Примечание Трассировка РРР в Windows 2000 идентична трассировке РРР в Win dows NT версий 4,0 и ниже.
Закрытие РРР-соединения При использовании РРР соединение может быть закрыто в любой момент. Обыч но это происходит при потере несущей, неудачной аутентификации, падении про пускной способности подключения, таймауте или закрытии соединения клиентом удаленного доступа либо системным администратором. В момент закрытия соеди нения РРР информирует об этом протоколы сетевого уровня, чтобы они могли выполнить нужные операции.
РРР-протоколы аутентификации Па втором этапе установления РРР-соединения клиент удаленного доступа аутсн тифицируется по одному из РРР-нротоколов аутентификации. О конкретном РРР протоколе аутентификации стороны договариваются на первом этапе установления РРР-соединения.
Средства удаленного доступа в Windows 2000 поддерживают следующие РРР-про токолы аутентификации: ЕАР (Extensible Authentication Protocol), CHAP (Chal lenge Handshake Authentication Protocol), MS-CHAP (Microsoft Challenge Hand shake Authentication Protocol) версий 1 и 2, SPAP (Shiva Password Authentication Protocol) и PAP (Password Authentication Protocol).
Надежная схема аутентификации должна обеспечивать защиту от атак с иов-.оре нием пакетов (replay attacks), а также от подмены клиента или сервера удаленного доступа.
Удаленный доступ 254 ЧАСТЬ Х Атака с повторением пакетов заключается в том, что злоумышленник захваты вает пакеты, передаваемые по сети в процессе успешного установления соеди нения, а впоследствии повторяет (воспроизводит) эти пакеты, чтобы установить несанкционированное соединение.
Х Подмена клиента удаленного доступа Ч атака, при которой злоумышленник подменяет клиент на уже установленном соединении. При этом злоумышлен ник дожидается успешной аутентификации подлинного пользователя, опреде ляет параметры соединения, а затем отключает этого пользователя и берет уп равление соединением на себя.
Х Подмена сервера удаленного доступа Ч атака, при которой злоумышленник под меняет подлинный сервер удаленного доступа своим компьютером. При этом подставной сервер имитирует проверку удостоверений клиента удаленного дос тупа, а потом захватывает весь трафик, исходящий от клиента.
РАР PAP (Password Authentication Protocol) Ч простейший протокол аутентификации, использующий пароли в незашифрованном виде. Имя и пароль пользователя зап рашиваются сервером удаленного доступа и сообщаются клиентом открытым тек стом. Поэтому РАР не является безопасным протоколом аутентификации. Зло умышленник, перехватывающий РАР-пакеты, которые передаются между клиентом и сервером удаленного доступа, может легко определить пароль клиента. РАР не обеспечивает защиту от атак с повторением пакетов, а также от подмены клиента или сервера удаленного доступа.
О применении РАР стороны договариваются в LCP-процессе согласования, указы вая в LCP-параметре Authentication Protocol (тип 3) значение ОхС023. По оконча нии LCP-согласования в РАР-сообщениях используется РРР-идентификатор про токола ОхС023.
РАР реализует простой обмен сообщениями.
1. Клиент удаленного доступа посылает серверу РАР-сообщение Authenticate Request с именем пользователя и паролем в виде незашифрованного текста.
2. Сервер удаленного доступа проверяет имя и пароль пользователя, а затем по сылает РАР-сообщение Authenticate-Ack, если удостоверения правильны, или Authenticate-Nak, если удостоверения неправильны.
РАР включен в Windows 2000 только для того, чтобы клиенты удаленного доступа под управлением 32-разрядных операционных систем Windows могли подключать ся к серверам удаленного доступа, не поддерживающим безопасные протоколы аутентификации, а также для того, чтобы клиенты удаленного доступа под управ лением операционных систем, отличных от Microsoft и не поддерживающих безо пасные протоколы аутентификации, могли подключаться к серверу удаленного до ступа под управлением 32-разрядной операционной системы Windows.
Примечание Для большей безопасности сервера удаленного доступа рекомендует ся отключить РАР. Но тогда устаревшие клиенты под управлением операционных систем, отличных от Microsoft, не смогут подключаться к этому серверу.
ГЛАВА 7 Сервер удаленного доступа SPAP SPAP (Shiva Password Authentication Protocol) Ч это протокол, который предостав ляет механизм обратимого шифрования и применяется на серверах удаленного до ступа Shiva. Клиент удаленного доступа Windows 2000 может использовать SPAP для аутентификации на серверах удаленного доступа Shiva или Windows 2000. SI'АР более надежен по сравнению с РАР, но менее безопасен, чем CHAP или MS-CHAP.
SPAP не защищает от подставных серверов удаленного доступа.
О применении SPAP стороны договариваются в LCP-процессе согласования, ука зывая в LCP-параметре Authentication Protocol (тип 3) значение ОхС027. По окон чании LCP-согласования в SPAP-сообщсниях используется РРР-идентификатор протокола ОхС027, Как и PAP, SPAP реализует простой обмен сообщениями, 1. Клиент удаленного доступа посылает серверу SPAP-сообщение Authenticate Request с именем пользователя и паролем в зашифрованном виде.
2. Сервер удаленного доступа расшифровывает пароль, проверяет имя п пароль пользователя, а затем посылает SPAP-сообщение Authenticate-Ack, если удосто верения правильны, или Authenticate-Nak, если удостоверения неправильны.
CHAP CHAP (Challenge Handshake Authentication Protocol) Ч протокол аутентификации, основанный на технологии вызов-ответ* (challenge-response) и описанный в RFC 1994. Он использует стандартный алгоритм необратимого шифрования MD5 (Mes sage Digest 5) для хэширования ответа на вызов, посланный сервером удаленного доступа, CHAP применяется многими разработчиками серверов и клиентов удаленного до ступа. Этот протокол поддерживается как клиентами, так и серверами удаленного доступа Windows 2000.
CHAP более совершенен, чем РАР и SPAP: пароль не пересылается по каналу свя зи, а используется для создания необратимого хэша из строки вызова. Сервер, ко торому известен пароль пользователя, проводит ту же операцию и сравнивает по лученный результат с ответом клиента.
О применении CHAP стороны договариваются в LCP-процессе согласования, ука зывая в LCP-параметре Authentication Protocol (тип 3) значение ОхС223 и алгоритм 0x05. По окончании LCP-согласования в СНАР-сообщениях используется РРР идентификатор протокола ОхС223.
Аутентификация по протоколу CHAP представляет собой обмен тремя сообще ниями.
1. Сервер удаленного доступа посылает СНАР-сообщсние Challenge (вызов) с идентификатором сеанса и произвольной строкой вызова.
2. Клиент удаленного доступа возвращает С НАР-сообщение Response (ответ) с именем пользователя в незашифрованном виде и хэшем, полученным из строки вызова, идентификатора сеанса и пароля с применением алгоритма MD5.
3. Сервер удаленного доступа выполняет ту же операцию над теми же данными и сравнивает свой результат с ответом. Если они совпадают, сервер удаленного ЧЛСТЬ 2 Удаленный доступ доступа возвращает СНАР-сообщение Success (успех);
нет Ч СНАР-сообщение Failure (неудача).
CHAP обеспечивает защиту от атак с повторением пакетов, так как при каждой попытке аутентификации использует новую строку вызова, генерируемую случай ным образом. Однако CHAP не защищает от подмены сервера удаленного доступа.
MS-CHAP v MS-CHAP vl (Microsoft Challenge Handshake Authentication Protocol версии 1) механизм аутентификации с шифрованием, очень похожий на CHAP. Как и в CHAP, сервер удаленного доступа посылает удаленному клиенту вызов с иденти фикатором сеанса и произвольной строкой вызова. Удаленный клиент должен вер нуть имя пользователя и хэш, полученный из строки вызова, идентификатора се анса и пароля с применением алгоритма MD4 (Message Digest 4).
Единственная разница между CHAP и MS-CHAP vl в том, что CHAP для провер ки ответа на вызов требует хранения пароля в незашифрованном виде, a MS-CHAP vl Ч в виде МП4-хэша. В Windows 2000 пароль пользователя хранится как MD4 хэш, а также в обратимо зашифрованном виде. При использовании MS-CHAP vl сервер удаленного доступа дешифрует обратимо зашифрованный пароль для про верки ответа от клиента удаленного доступа.
Аутентификация по протоколу MS-CHAP vl представляет собой обмен тремя со общениями.
1. Сервер удаленного доступа посылает клиенту удаленного доступа сообщение MS-CHAP Challenge (вызов) с идентификатором сеанса и произвольной стро кой вызова.
2. Клиент удаленного доступа отвечает сообщением MS-CHAP Response (ответ) с именем пользователя в незашифрованном виде и хэшем, полученным из строки вызова, идентификатора сеанса и MD4-xama клиентского пароля (этот хэш ге нерируется по алгоритму необратимого хэширования MD4).
3. Сервер удаленного доступа выполняет ту же операцию над теми же данными и сравнивает свой результат с ответом. Если они совпадают, сервер удаленного доступа возвращает сообщение MS-CHAP Success (успех);
нет Ч сообщение MS CHAP Failure (неудача).
О применении MS-CHAP vl стороны договариваются в LCP-пропессе согласова ния, указывая в LCP-параметре Authentication Protocol (тип 3) значение ОхС223.
По окончании LCP-согласования в сообщениях MS-CHAP vl используется РРР идентификатор протокола ОхС223, MS-CHAP vl также поддерживает коды ошибок, включая код password expired* (лсрок действия пароля истек). Используя при каждой попытке аутентификации новую произвольную строку вызова, MS-CHAP vl обеспечивает защиту от атак с повторением пакетов. Однако от атак с подменой удаленного сервера MS-CHAP vl не защищает.
Если в качестве протокола аутентификации применяется MS-CHAP vl и согласо вано использование МРРЕ, каждая сторона РРР-соединения генерирует секретные шифровальные ключи. MS-CHAP vl предусматривает набор сообщений, позволя ющих менять пароль пользователя в процессе аутентификации.
ГЛАВА 7 Сервер удаленного доступа MS-CHAP v Windows 2000 поддерживает протокол MS-СНЛР v2 (Microsoft Challenge Hand shake Authentication Protocol версии 2), который обеспечивает повышенную защи ту соединений удаленного доступа. Ниже перечислены дополнительные средства зашиты, предлагаемые второй версией MS-CHAP v2.
Х Шифрованные ответы и смена паролей LAN Manager более не поддерживаются.
Х Двухсторонняя аутентификация. Клиент удаленного доступа аутентифицирует ся на сервере удаленного доступа, а сервер Ч на клиенте. Двухсторонняя аутен тификация, также называемая взаимной, гарантирует, что клиент удаленного доступа подключается именно к тому серверу удаленного доступа, который име ет доступ к паролю пользователя. Взаимная аутентификация защищает от атак с подменой сервера удаленного доступа.
Х Для передачи и приема данных генерируются раздельные криптографические ключи.
Х Криптографические ключи генерируются на основе пароля пользователя и про извольной строки вызова. Поэтому, несмотря на то что пользователь подключа ется с одним и тем же паролем, применяются разные ключи.
О применении MS-CHAP v2 стороны договариваются в LCP-процессе согласова ния, указывая в LCP-параметре Authentication Protocol (тип 3) значение ОхС223 и алгоритм 0x81. По окончании LCP-согласования в сообщениях MS-CHAP v'2 ис пользуется РРР-идентификатор протокола ОхС223.
Аутентификация по протоколу MS-CHAP v2 представляет собой обмен тремя со общениями.
1. Сервер удаленного доступа посылает клиенту сообщение MS-CHAP v2 Chal lenge (вызов) с идентификатором сеанса и произвольной строкой вызова.
2. Клиент удаленного доступа посылает сообщение MS-CHAP v2 Response (ответ), содержащий:
Х имя пользователя;
Х произвольную строку вызова;
Х кэш, сгенерированный по методу SHA (Secure Hash Algorithm) из строки вызова, полученной от сервера, собственной строки вызова, идентификатора сеанса и MD4-X3iita пароля пользователя.
3. Сервер удаленного доступа проверяет сообщение MS-CHAP v2 Response, при нятое от клиента, и посылает свой ответ, содержащий:
Х признак успеха или неудачи попытки соединения;
Х аутентификационный ответ на основе переданной строки вызова, собс твен ной строки вызова, шифрованной строки вызова клиента и пароля пользова теля.
4. Клиент удаленного доступа проверяет аутентификационный ответ и, ееш он правилен, использует соединение. Если же ответ неправилен, клиент разрывает соединение.
ЧАСТЬ 2 Удаленный доступ ЕАР ЕАР (Extensible Authentication Protocol) Ч это расширение РРР, позволяющее при менять произвольные механизмы аутентификации. При использовании РРР-про токолов аутентификации вроде MS-CHAP и SPAP конкретный механизм аутенти фикации выбирается па этапе установления соединения. После этого согласован ный протокол аутентификации применяется на этапе аутентификации.
В случае ЕАР конкретный механизм аутентификации на этапе установления соеди нения не выбирается. Вместо этого каждая сторона соглашается использовать на этапе аутентификации протокол ЕАР. Как только начинается этап аутентификации, стороны РРР-соединения должны согласовать конкретную схему аутентификации по ЕАР. называемую типом ЕАР. Согласовав определенный тип ЕАР, клиент и сер вер удаленного доступа начинают вести между собой диалог, зависящий от пара метров соединения и состоящий из запросов аутептификационной информации и ответов. Длительность диалога зависит от выбранного типа ЕАР.
Так, при использовании ЕАР с картами маркера защиты (security token cards) сер вер удаленного доступа последовательно запрашивает у клиента имя, PIN-код и значение маркера карты. После того как па запрос получен ответ, клиент проходит следующий уровень аутентификации. Если на все вопросы получены удовлетвори тельные ответы, аутентификация клиента считается успешной, и ему предоставля ется доступ в сеть.
О применении ЕАР стороны договариваются в LCP-процессе согласования, указы вая в LCP-параметре Authentication Protocol (тип 3) значение ОхС227. По оконча нии LCP-согласования в сообщениях ЕАР используется РРР-идентификатор про токола ОхС227. Windows 2000 поддерживает следующие типы ЕАР: EAP-MD5 и EAP-TLS.
С архитектурной точки зрения, ЕАР рассчитан на применение различных устройств защиты, установленных на клиентах и серверах удаленного доступа. Для поддерж ки нового типа ЕАР на сервере и клиенте удаленного доступа достаточно устано вить файл с библиотекой типа ЕАР. Это позволяет разработчикам аппаратно-про граммных средств в любой момент создавать новые схемы аутентификации. ЕАР обеспечивает наивысшую гибкость в процессе аутентификации.
EAP-MD EAP-MD5 Ч это механизм аутентификации CHAP, используемый в рамках ЕАР.
На этапе установления соединения стороны договариваются, что на этапе аутенти фикации будут применять ЕАР.
На этапе аутентификации происходит процесс проверки клиента.
1. Проверяющий посылает сообщение EAP-Request, запрашивающее идентифика цию клиента.
2. Клиент посылает идентификатор пользователя в сообщении EAP-Response.
3. Проверяющий посылает сообщение EAP-Request со строкой вызова MD5.
4. Клиент посылает МО5-хэш идентификатора и пароля пользователя в сообще нии EAP-Response.
5. Если ответ правильный, проверяющий посылает клиенту сообщение Success об успешной аутентификации.
Сервер удаленного доступа ГЛАВА EAP-MD5 является обязательным типом ЕАР и может быть использован для про верки возможности взаимодействия по ЕАР. Как и CHAP, EAP-MD5 требует хра нения локальных или доменных паролей в обратимо зашифрованном виде. Подроб нее на эту тему см. справочную систему Windows 2000 Server, EAP-TLS Протокол TLS (Transport Layer Security), основанный на SSL (Secure Sockets Layer), обеспечивает защищенное взаимодействие между приложениями. TLS пре доставляет сервисы аутентификации (пользователя и данных), поддержания цело стности и конфиденциальности данных. Для реализации этих сервисов TLS опре деляет инфраструктуру, обеспечивающую:
Х одно- и двухстороннюю аутентификацию с применением симметричного или асимметричного шифрования;
Х согласование конкретного алгоритма шифрования;
Х безопасный обмен криптографическими ключами, используемыми для шифро вания сообщений;
Х контроль за целостностью сообщений и аутентификацией пользователя с при менением аутентификационного кода сообщений.
Подробнее о TLS см. RFC 2246;
подробнее о EAP-TLS см. REC 2716.
EAP-TLS использует TLS на этапе установления РРР-соединения. В случае КАР TLS взаимная аутентификация РРР-клиента и сервера осуществляется путем об мена сертификатами и проверки их подлинности. Клиент, пытающийся установить соединение, посылает сертификат пользователя, а сервер Ч машинный сертификат.
EAP-TLS поддерживается только серверами удаленного доступа под управлением Windows 2000 Server, входящими в домен Windows 2000 смешанного или основно го режима. Автономные серверы удаленного доступа не поддерживают EAP-TLS.
EAR-RADIUS EAP-RADIUS Ч это не тип ЕАР, а способ передачи сообщений любого типа ЕАР сервером удаленного доступа на сервер RADIUS для аутентификации. Сообщения ЕАР, пересылаемые между клиентом и сервером удаленного доступа, инкапсулиру ются и форматируются как сообщения RADIUS, которыми обмениваются сервер удаленного доступа и сервер RADIUS. Таким образом, сервер удаленного доступа становится устройством сквозной передачи сообщений ЕАР между клиентом уда ленного доступа и сервером RADIUS. Вся обработка сообщений ЕАР выполняется на клиентах удаленного доступа и серверах RADIUS.
EAP-RADIUS применяется в средах, где в качестве службы аутентификации ис пользуется RADIUS. Преимущество EAP-RADIUS в том, что типы ЕАР нужно устанавливать не на каждом сервере удаленного доступа, а только на сервере RADIUS.
Обычно при использовании EAP-RADIUS сервер удаленного доступа настраива ется на ЕАР и RADIUS (в качестве службы аутентификации). При попытке под ключения клиент удаленного доступа согласует применение ЕАР с сервером уда ленного доступа. Когда клиент посылает сообщение ЕАР на сервер удалснноги до ступа, тот инкапсулирует сообщение ЕАР в сообщение RADIUS и посылает его на Удаленный доступ 260 ЧАСТЬ сервер RADHJS, Сервер RADIUS обрабатывает сообщение и посылает серверу уда ленного доступа ответное сообщение КАР, инкапсулированное в сообщение RA DIUS. Наконец, сервер удаленного доступа пересылает сообщение ЕАР клиенту.
Неаутентифицируемые соединения Windows 2000 также поддерживает иеаутснтифицируемые РРР-соединения. При установлении таких соединений этап аутентификации пропускается. Ни клиент удаленного доступа, ни сервер удаленного доступа не обмениваются своими удос товерениями. К использованию неауте нтифицируемых соединений следует отно ситься очень внимательно, так как они предоставляются без проверки идентифи кации удаленных клиентов.
Неаутентифицируемые соединения желательны в двух случаях.
1. При аутентификации на основе А Х Г / C L I (Automatic Number Identification/ Calling Line Identification). В этом случае аутентификация осуществляется по номеру телефона клиента. ANI/CLT возвращает получателю вызова номер теле фона клиента Ч такая услуга предоставляется большинством телефонных ком паний.
Аутентификация на основе ANl/СТЛ отличается от аутентификации по иденти фикатору звонящего. При аутентификации по идентификатору звонящего кли ент передает имя и пароль пользователя. Идентификатор звонящего, который настраивается в параметрах входящих звонков в окне свойств учетной записи пользователя, должен совпадать с идентификатором, указываемым при попыт ке подключения;
в ином случае попытка подключения игнорируется. А при аутентификации на основе ANT/CLI имя и пароль пользователя не применяются.
2. Аутентификация гостей. В качестве идентификации клиента используется учет ная запись Guest (Гость).
Подробнее о типичных вариантах применения неаутентифицируемых соединений см. в справочной системе Windows 2000 Server.
Удаленный доступ и настройка TCP/IP и IPX В следующих разделах поясняется, как сервер удаленного доступа Windows настраивает параметры сетевой конфигурации для клиентов удаленного доступа, использующих TCP/IP и IPX.
TCP/IP Для настройки ТСР/1Р-клиеита удаленного доступа в IPCP-процессе согласования сервер удаленного доступа назначает клиенту IP-адрес и сообщает IP-адреса DNS и WINS-ссрверов.
Назначение IP-адреса Чтобы выделить IP-адрес клиенту, сервер удаленного доступа использует либо DHCP (Dynamic Host Configuration Protocol), либо статический пул IP-адресов.
DHCP и автоматическое назначение частных IP-адресов Если сервер удаленного доступа настроен на получение IP-адресов через DHCP, то DHCP-сервер выделяет службе маршрутизации и удаленного доступа 10 1Р-адре Сервер удаленного доступа ГЛАВА 7 сов. Сервер удаленного доступа использует для интерфейса сервера RAS первый полученный от DHCP адрес, а остальные адреса назначает по мере подключения новых ТСР/1Р-клиентов удаленного доступа. Освобождающиеся при отключении клиентов IP-адреса используются повторно.
Если все 10 IP-адресов заняты, сервер удаленного доступа получает от UUCP еще 10-адресов. Количество IP-адресов, выдаваемых за одни раз, определяется значе нием параметра InitialAddressPoolSize в разделе реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services \RemoteAccess\Parameters\Ip В случае сервера удаленного доступа под управлением Windows NT 4.0 адрсеа, вы деленные DHCP, запоминаются и повторно используются после перезапуска этого сервера. Сервер удаленного доступа под управлением Windows 2000 освобождает все IP-адреса (выданные DHCP), посылая сообщение DHCPRelease при каждой остановке службы маршрутизации и удаленного доступа.
Если сервер удаленного доступа использует IP-адреса, выданные DHCP, и DHCP сервер становится недоступным, то выделение этих IP-адресов ТСР/1Р-клиеитам удаленного доступа прекращается.
Если при запуске службы маршрутизации и удаленного доступа DHCP-сервер не доступен, используются IP-адреса из диапазона 169.254.0.1-169.254.255.254. Этот диапазон зарезервирован для автоматического назначения частных IP-адресов (Automatic Private IP Addressing, AP1PA). Функция APIPA для подключений уда лепного доступа типа точка-LAN работает, только если в сети, к которой подклю чен сервер удаленного доступа, тоже используется функция APIPA. Если в локаль ной сети АРТРА не применяется, клиенты могут установить удаленное соединение лишь типа точка-точка*.
Если DHCP-сервер становится доступным, то в следующий раз, когда службе мар шрутизации и удаленного доступа понадобятся IP-адреса, они будут получены от DHCP-сервера.
Сервер удаленного доступа, получая IP-адреса от DHCP для клиентов удаленного доступа, использует определенный LAN-интерфейс. Вы можете выбрать этот ин терфейс (если у Вас не менее двух LAN-интерфейсов) через оснастку Routi m* and Remote Access (Маршрутизация и удаленный доступ) на вкладке IP (IP) окна свойств сервера удаленного доступа. По умолчанию предлагается Allow RAS to select adapter;
это означает, что служба маршрутизации и удаленного доступа вы бирает LAN-интерфейс случайным образом.
Статический пул IP-адресов Если сконфигурирован статический пул IP-адресов, сервер удаленного доступа ис пользует первый IP-адрес из первого диапазона адресов для интерфейса RAS-cep вера, а последующие адреса присваиваются по мере подключения новых TCP/IP клиентов удаленного доступа. IP-адреса, освобожденные в результате отключения клиентов удаленного доступа, используются повторно.
Pages: | 1 | ... | 3 | 4 | 5 | 6 | 7 | ... | 13 | Книги, научные публикации