Internetworking Guide Microsoft
Windows 2000 Server R Microsoft Press
Межсетевое взаимодействие
Microsof
Windows 2000 Server Москва, 2002
УДК 004 ББК 32.973.26-018,2 М59 Microsoft Corporation М59
Межсетевое взаимодействие. Ресурсы Microsoft Windows 2000 Server/Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция*, 2002. — 736 с.: ил,
ISBN 5-7502-0163-5 Книга представляет собой техническое руководство по серверу маршрутизации и удаленного доступа под управлением Windows 2000 Server и организации взаимодействия между сетями различных типов (TCP/IP, IBM SKA, UNIX, NetWare, AppleTalk. ATM). Кроме того, дается детальная техническая информация о виртуальных частных сетях, службе Internet Authentication Service, об интеграции телефонии и поддержке конференций. Книга состоит из введения, шести частей (17 глав), трех приложений, словаря терминов (содержится на компактдиске) и предметного указателя. Предназначена сетевым инженерам, сетевым и системным администраторам, квалифицированным пользователям и всем, кто хочет досконально изучить взаимодействие операционной системы Windows 2000 с различными сетями и другими операционными системами. Названия всех команд, диалоговых окон и других интерфейсных элементов тфиведены как на английском языке, так и на русском (по коммерческой русской версии Windows 2000 Server).
УДК 004 ББК 32.973.26-018.2 Подготовлено к изданию но лицензионному договору с Microsoft Corporation, Редмонд, Вашингтон, США. Active Accessibility, Active Channel, Active Client. Active Desktop, Active Directory, ActivcMovic, ActiveX, Authenticode, BackOffice, DvrectAnimatkm, DirectPlay, DirectShow, DircctSound, DirectX, DoubleSpace, DriveSpace, FrontPage, Georgia, Hotmail. fntelHMirror, InteUiSense. JScript, Links, Microsoft, Microsoft Press, MSDN, MS-DOS, MSN, Natural, Net Meeting. NetShow, OpenType. Outlook, PowerPoint, Sidewalk, Slate, Starts Here, Truelmage, Verdana, Visual Basic, Visual C4-+, Visual InterDev, Visual J + -*-, Visual Studio, WebBot, Win32, Windows. Windows Media и Windows NT являются либо охраняемыми товарными знаками, либо товарными знаками корпорации Microsoft в США и/или других странах. NT — товарный знак компании Nothern Telecom Limited. Все другие товарные знаки являются собственностью соответствующих фирм. Информация, приведенная в этой книге, в том числе URL и другие ссылки на Web-узлы, может быть изменена без предварительного уведомления. Все названия компаний, организаций и продуктов, а также имена лиц. используемые в примерах, вымышлены и не имеют никакого отношения к реальным компаниям, организациям, продуктам и лицам.
-805-8 (англ) ISBN 5-7502-0163-5
© Оригинальное издание на английском языке, Microsoft Corporation. 2000 © Перевод на русский язык, Microsoft Corporation. 2002
Оглавление Введение
ЧАСТЬ 1
XIV
Маршрутизация
1
ГЛАВА 1 Обзор одноадресной маршрутизации
2
Межсетевая маршрутизация Адресация в межсетевой среде Концепции маршрутизации Маршрутизация хостом Маршрутизация маршрутизатором Таблицы маршрутизации Статические и динамические маршрутизаторы Проблемы маршрутизации Маршрутизаторы и широковещательный трафик Туннелирование Основы протоколов маршрутизации
3 3 4 5 7 8 11 12 14 15 16
Состояние канала Инфраструктура маршрутизации Одно- и многопутевая инфраструктуры маршрутизации Плоская и иерархическая инфраструктуры маршрутизации
17 18 18 19
Вектор расстояний
17
Автономные системы
19
ГЛАВА 2 Служба маршрутизации и удаленного доступа
22
Введение в службу маршрутизации и удаленного доступа Служба маршрутизации и удаленного доступа в Windows 2000 Аутентификация и авторизация Учет Установка и конфигурирование Изменение конфигурации Функциональность службы маршрутизации и удаленного доступа Архитектура службы маршрутизации и удаленного доступа Компоненты и процессы поддержки одноадресной IP-маршрутизации Компоненты и процессы поддержки многоадресной IP-маршрутизации Компоненты и процессы IPX-маршрутизации Настройки в реестре Дополнительные средства, поставляемые со службой маршрутизации и удаленного доступа
23 23 25 26 26 27 27 31 36 37 38 40 40
Оснастка Routing and Remote Access Утилита Netsh Запись аутентификационной и учетной информации Регистрация событий
41 43 45 45
Трассировка
ГЛАВА 3 Одноадресная IP-маршрутизация Windows 2000 и IP-маршрутизация
46
,
Возможности маршрутизатора Windows 2000 в IP-маршрутизации RIP for IP RIP и большие межсетевые среды Конвергенция в межсетевых средах, использующих RIP
48 48
49 SO 50 51
Функционирование RIP for IP
57
RIP for IP версии 2 Windows 2000 как маршрутизатор RIP for IP Выявление и устранение проблем с RIP for IP
60 64 64
RIP for IP версии 1
58
VI
Оглавление
OSPF Функционирование OSPF Типы сетей в терминах OSPF
Синхронизация LSDB через механизм соседства Передача OSPF-пакегов в сетях OSPF Области OSPF Виртуальные каналы Внешние маршруты Изолированные области Выявление и устранение проблем с OSPF Агент ретрансляции DHCP DHCP и IP-маршрутизаторы : Выявление и устранение проблем с агентом ретрансляции DHCP NAT
66 67 72
73 80 80 84 86 87 89 91 91 94 95
Статическое и динамическое сопоставление адресов Корректная трансляция полей заголовков
96 96
Редакторы МАТ Процессы NAT на маршрутизаторе Windows 2000
97 97
Дополнительные компоненты протокола маршрутизации NAT Выявление и устранение проблем с NAT
100
102
Фильтрация IP-пакетов Фильтрация IP-пакетов в Windows 2000 Входные фильтры Выходные фильтры Настройка фильтра Варианты фильтрации Обнаружение маршрутизаторов средствами ICMP
103 104 106 106 106 108 113
ГЛАВА 4
115
Поддержка групповой IP-рассылки
Обзор Взаимосвязь IP-адресов групповой рассылки с эквивалентными МАС-адресами Интрасеть с поддержкой групповой IP-рассылки
Хосты
Маршрутизаторы МВопе
IGMP IGMP v1 IGMP v2
Поддержка групповой IP-рассылки в службе маршрутизации и удаленного доступа
116 117 118
118
119 123
124 124 126
128
Протокол IGMP
128
Пульс групповой рассылки
134
Ограничители групповой рассылки
Туннели IP-B-IP Многоадресные статические маршруты Поддерживаемые конфигурации многоадресной пересылки Интрасеть с единственным маршрутизатором Интрасеть с единственным маршрутизатором и подключением к МВопе Периферийный маршрутизатор в интрасети с поддержкой групповой рассылки Поддержка групповой рассылки для клиентов удаленного доступа Поддержка многоадресной пересылки для сетей филиалов Средства диагностики Таблицы оснастки Routing and Remote Access Команда Mrinio Поддержка Mtrace Команды Netsh Регистрация событий IGMP Трассировка
ГЛАВА 5
IPX-маршрутизация
Windows 2000 и IPX-маршрутизация Функциональность маршрутизатора Windows 2000 для набора протоколов IPX
133
135 136 137 137 138 139 140 142 143 143 145 146 146 147 147
148 148 149
Оглавление
VII
Фильтрация IPX-пакетов Структура IPX-заголовка Демультиплексирование IPX-пакета Фильтрация IPX-пакетов на маршрутизаторе Windows 2000 RIP for IPX Таблицы IPX-маршрутизации Функционирование RIP for IPX Структура пакетов RIP for IPX Фильтры маршрутов RIP for IPX Статические IPX-маршруты SAP for IPX IPX-маршрутизаторы и номер внутренней сети Таблицы SAP Функционирование SAP для IPX-маршрутизатора Структура пакета SAP SAP-фильтры Статические службы Широковещание NetBIOS IPX WAN Broadcast Структура широковещательных пакетов NetBIOS поверх IPX Статические NetBIOS-имена
149 150 152 153 156 157 158 159 160 162 163 163 167 168 169 170 171 172 172 174 175
ГЛАВА 6
177
Маршрутизация с соединением по требованию
Введение в маршрутизацию с соединением по требованию Типы соединений по требованию Компоненты поддержки маршрутизации с соединением по требованию Процесс маршрутизации с соединением по требованию VPN-соединение, устанавливаемое между маршрутизаторами по требованию Тестирование подключений, устанавливаемых по требованию Мониторинг подключений по требованию с помощью Rasmon Защита при маршрутизации с соединением по требованию Создание учетных записей пользователей с помощью Demand-Dial Wizard Блокировка соединений по требованию Маршрутизация с соединением по требованию и протоколы маршрутизации Подключения, устанавливаемые по требованию Постоянные подключения Использование Multilink и ВАР IPX-соединения по требованию Выявление и устранение проблем Средства диагностики
ЧАСТЬ 2
Удаленный доступ
178 179 182 184 186 189 190 190 т94 195 197 197 201 202 204 205 210
213
ГЛАВА 7 Сервер удаленного доступа
214
Обзор Удаленный доступ и удаленное управление Компоненты, участвующие в соединении по коммутируемой линии Элементы защиты удаленного доступа Управление удаленным доступом Архитектура сервера удаленного доступа IP-, IPX- и AppleTalk-маршрутизэтор Выделение адресов из диапазона внутри или вне подсети Шлюз NetBIOS РРР РРР-инкапсуляция Согласование параметров РРР-канала по протоколу LCP Согласование параметров ответного вызова по протоколу СВСР Согласование параметров РРР сетевого уровня по протоколу NCP Процесс РРР-соединения Пример РРР-соединения
?15 215 216 221 224 228 ?29 231 233 234 234 237 241 242 246 247
VIII
Оглавление
Закрытие РРР-соединения РРР-протсжолы аутентификации РАР SPAP CHAP MS-CHAP v1 MS-CHAP v2 EAP Неаутентифицируемые соединения Удаленный доступ и настройка TCP/IP и IPX TCP/IP IPX Политика удаленного доступа Обработка запроса на соединение Проблемы с политиками удаленного доступа Multilink и ВАР РРР-протокол МР ВАР ВАСР Сервер удаленного доступа и поддержка групповой IP-рассылки Выявление и устранение проблем Наиболее распространенные проблемы с удаленным доступом Средства диагностики
253 253 254 255 255 256 257 258 260 260 260 264 265 266 267 268 268 270 271 271 274 274 278
ГЛАВА 8 Служба проверки подлинности в Интернете
281
Обзор Возможности IAS Протокол RADIUS Процесс аутентификации через RADIUS Формат RADIUS-пакетов Аутентификация в IAS Аутентификация и авторизация в IAS: шаг за шагом IAS и туннелирование Методы аутентификации Авторизация в IAS Политики удаленного доступа Учет в IAS Учет в RADIUS Файл журнала IAS Аутентификация в IAS и режимы работы доменов Windows Домены Windows 2000 основного режима Домены Windows 2000 смешанного режима и домены Windows NT 4.0 Автономные серверы под управлением Windows 2000 Различия в поведении IAS под управлением Windows 2000 и Windows NT 4.0 Некоторые вопросы безопасности RADIUS-прокси Брандмауэры Блокировка учетной записи удаленного доступа Настройка и оптимизация Мониторинг производительности и работоспособности сервера IAS Выявление и устранение проблем Проблемы с конфигурацией IAS Применение Network Monitor
ГЛАВА 9 Обзор
Виртуальные частные сети
Элементы VPN-соединения VPN-соединения Свойства VPN-соединений
282 282 286 286 287 294 296 301 305 314 314 327 327 328 328 328 329 330 330 331 331 331 332 332 333 333 333 338
340 341
342 343 .343
Оглавление VPN-соединения через Интернет или интрасети Управление виртуальными частными сетями РРТР Network Load Balancing и РРТР L2TP и IP-безопасность Защита виртуальных частных сетей РРТР-соединения Соединения L2TP поверх IPSec Адресация и маршрутизация при использовании виртуальных частных сетей VPN-соединения удаленного доступа VPN-соединения между маршрутизаторами Аутентификация на основе общего ключа при использовании L2TP поверх IPSec для VPN-соединений между маршрутизаторами Виртуальные частные сети и брандмауэры Виртуальные частные сети и NAT Трансляция адресов и номеров портов для VPN-трафика Сквозные VPN-соединения Конфигурирование VPN-сервера компании А Консригурирование VPN-сервера компании В Настройка компьютера VPN-клиента на использование сквозной VPN Создание сквозного VPN-соединения Выявление и устранение проблем Наиболее распространенные проблемы с VPN Средства диагностики
ЧАСТЬ 3 ГЛАВА 10
345 348 352 356 357 362 362 363 364 365 369 373 380 384 385 386 386 387 390 391 391 391 397
Взаимодействие с другими системами
399
Взаимодействие с хост-системами IBM
Обзор Microsoft SNA Server Сервисы интеграции сетей Доступ к данным Интеграция приложений Интеграция управления сетями Способы интеграции сетей Модели развертывания Интеграция SNA Server с сетями Windows 2000 Способы подключения Коммуникационное взаимодействие с иерархическими SNA-сетями Доступ через терминалы 3270 Использование LU-пулов Выделение LU рабочим станциям Обеспечение отказоустойчивости Балансировка нагрузки Доступ через терминалы TN3270 Соединения с нижестоящими системами Коммуникационное взаимодействие с одноранговыми SNA-сетями АРРС и SNA Server CPI-C АРРС-приложения Стратегии развертывания АРРС Обеспечение отказоустойчивости Параметры IP для TN5250 SNA Remote Access Service Гетерогенные клиенты Интеграция гетерогенных клиентов с мэйнфреймами Интеграция гетерогенных клиентов с системами AS/400 Host Print Service Защита сетевых сред, включающих хост-системы Аутентификация
IX
400
'
401 402 403 404 405 405 406 411 412 420 420 421 422 422 422 422 424 425 425 426 426 429 430 431 431 432 432 434 435 437 438
Оглавление Выделение ресурсов
43Е
Шифрование данных Поддержка брандмауэров Host Security Integration Автоматизация синхронизации паролей
440 440 441 444
Автоматизация регистрации
Доступ к данным на хост-системах
Доступ к данным на хосте через ODBC Доступ к данным на хосте через OLE DB
Выбор метода доступа к хост-данным Интеграция с приложениями хост-систем через COMTI
Интеграция с системой обработки транзакций на хостах Интеграция хост-систем с Web
SNA Server и технология Web
Способы доступа к хосту из Web-браузеров
Интеграция управления сетями Сервисы управления SNA Server Интеграция со службами управления Windows 2000 Интеграция с сервисами управления IBM NetView
ГЛАВА 11
Services for UNIX
Обзор
Доступ к файлам через NFS Поддерживаемые версии NFS Server for NFS
444
444
445 446 447 448
450
451
451
452
455 455 456 457
459 460
460 460 461
Client lor NFS
463
Протоколы NFS NFS-потоки Аутентификация PCNFSD
464 466 467
Команда showmount
Особенности архитектуры NFS
Клиент и сервер Telnet в Services for UNIX Протокол Telnet Network Virtual Terminal Сеанс Telnet Функциональность Telnet Безопасность Telnet
Синхронизация паролей
Использование синхронизации паролей
Защита
Утилиты UNIX и оболочка Когп Оболочки UNIX Поддержка сценариев
ГЛАВА 12 Взаимодействие с NetWare
467
467
471 472 472 472 472 473
473 473
474
476 476 488
490
Обзор NWLink Архитектура NWLink Настройка NWLink
491 492 493 498
Службы шлюза и клиента для NetWare Выбор между службой шлюза и службой клиента
503 504
Типы кадров и номера сетей
498
Как функционирует Gateway Service for NetWare Как функционирует Client Service for NetWare
505 507
Настройка служб шлюза и клиента
509
Файлы, устанавливаемые со службой шлюза, службой клиента и NWLink Администрирование NetWare через Windows 2000 Администрирование серверов NetWare Защита Windows 2000 и NetWare ..
515
516 516 .. 519
Оглавление Разрешения Windows 2000 Доверигельные права доступа NetWare Права доступа к NDS-объектам и свойствам Доступ к томам NetWare Использование команд net view Сценарии регистрации Выявление и устранение проблем Средства диагностики Наиболее распространенные проблемы Проблемы со сценариями регистрации Другие распространенные проблемы
ГЛАВА 13 Services for Macintosh Обзор AppleTalk Сети AppleTalk и маршрутизация Особенности AppleTalk Phase 2 Проектирование сети Инициирующие маршрутизаторы Присвоение сетям номеров и диапазонов номеров Зоны Создание зон в сети Создание плана размещения маршрутизаторов Планирование сетевой среды File Services for Macintosh Доступ к файл-серверу через TCP/IP Доступ к файл-серверу через AppleTalk AFP NTFS-потоки Индексация Дисковое пространство Защита сети Разрешения на доступ к файлам Трансляция имен файлов Macintosh Кросс-платформенные приложения для Macintosh и Windows 2000 Сопоставления расширений с типами Print Server for Macintosh Протокол печати Аутентификация при печати Macintosh Port Monitor Процессор печати в Services for Macintosh Настройка сетевых принтеров Предотвращение LaserPrep Wars Дополнительные варианты печати Удаленный доступ Выявление и устранение проблем
ЧАСТЬ 4
Интеграция сетей и мультимедиа
ГЛАВА 14 ATM Введение в ATM Обзор ATM Базовые компоненты "Традиционная и ATM LAN Архитектура ATM Модель ATM Структура ATM-ячейки Виртуальные пути и виртуальные каналы Quality of Service
XI 519 519 522 522 523 524 525 525 525 529 530
532 532 533 I535 I536 I536 536 538 538 539 539 540 543 543 543 544 544 544 545 545 &47 549 551 551 555 555 556 556 556 557 558 559 560 561
567 568 568 569 569 569 573 574 5I77 579 580
XII
Оглавление
ATM-адреса Типы ATM-соединений LAN Emulation TCP/IP поверх ATM Службы ATM в Windows 2000 Компоненты Рекомендации Использование ELAN по умолчанию Повышение безопасности за счет нескольких ELAN Протоколирование событий Корректные имена ELAN Поддерживаемые ATM-адаптеры Утилиты ATM IP поверх ATM Предотвращение несанкционированного доступа к коммутатору Выявление и устранение проблем Сбой при инициализации РУС не пересылает ячейки
ГЛАВА 15 Интеграция телефонии и поддержка конференций Обзор Интеграция компьютера и телефонии Microsoft-поддержка CTI Архитектура TAPI TAPI 3.0 COM API
TAPI Server TSP MSP Клиент-серверная телефония Интернет-телефония и конференции Интернет-телефония на основе Н.323 Многосторонние конференции на основе групповой IP-рассылки Выявление и устранение проблем Проблемы с PSTN-телесронией Проблемы с Н.323-вызовами и многосторонними конференциями
ЧАСТЬ 5
Другие протоколы
ГЛАВА 16 NetBEUI Обзор Взаимодействие с другими операционными системами через NBF Архитектура NBF Интерфейс TDI Интерфейс NDIS Типы сетевой коммуникационной связи Коммуникационная связь, не ориентированная на логические соединения Коммуникационная связь, ориентированная на логические соединения Поддержка динамического выделения памяти Поддержка клиентов удаленного доступа Ограничения на число сеансов в NBF Установление сеансов Возможности маршрутизации на основе NBF Поддержка Plug and Play Выявление и устранение проблем ГЛАВА 17 DLC Обзор Установка протокола DLC Настройка сетевых привязок
582 583 585 589 594 595 603 603 603 603 604 604 604 612 614 615 615 616
618 618 619 620 622 622
622 622 624 624 625 626 631 636 636 637
643 644 644 645 646 647 647 648 649 650 652 652 652 653 656 656 656 659 659 660 .. 660
Оглавление Параметры драйвера DLC в реестре Коммуникационное взаимодействие со SNA-хостами через DLC Изменение локально управляемого адреса Подключение к устройствам печати через DLC
ЧАСТЬ 6
Приложения
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
XIII 661 662 662 663
665 066
Интеграция с хост-системами IBM Microsoft SNA Server Архитектура IBM SNA Иерархические SNA-сети Аппаратные компоненты в иерархических сетях Типы соединений в иерархических сетях Физические элементы в иерархических сетях Логические элементы в иерархических сетях Функциональные уровни SNA SNA-сеансы Иерархические домены и подобласти APPN Аппаратные компоненты в одноранговых сетях Типы соединений в одноранговых сетях Физические элементы в одноранговых сетях Логические элементы в одноранговых сетях Развитие SNA Интеграция иерархической и одноранговой моделей IBM Networking Blueprint Стандарты приложений хост-систем Доступ с терминалов Стандарты баз данных на хост-системах Доступ к данным на уровне записей Доступ к данным на уровне файлов Обработка транзакций Стандарты безопасных транзакций Компоненты, участвующие в обработке транзакций Синхронизация обработки транзакций Стандарты обработки транзакций на хост-системах IBM Система управления сетью IBM NetView Функции NetView Архитектура NetView
667 667 668 669 669 670 671 673 674 676 676 677 678 679 679 681 882 683 683 683 683 (584 684 685 685 686 В86 686 687 687 088 688
ПРИЛОЖЕНИЕ Б
690
Концепции взаимодействия с UNIX
Иерархическая структура файлов Ядро Корень Реализации UNIX Печать в UNIX UNIX Man
ПРИЛОЖЕНИЕ В Windows 2000 Resource Kit Deployment Lab
690 692 692 692 693 В93
694
Web-узел Windows 2000 Resource Kit Deployment Scenarios Партнеры лаборатории Resource Kit Deployment Lab Маршрутизаторы Коммутаторы Серверы Настольные компьютеры Портативные компьютеры
694 695 695 (:i98 (599 701 702
Предметный указатель
704
Введение
Мы рады представить Вам книгу «Межсетевое взаимодействие» из серии «Ресурсы Microsoft Windows 2000 Server». Эта серия состоит из нескольких книг и одного компакт-диска, на котором содержатся различные утилиты, дополнительные справочные материалы и электронные версии всех книг. Новая информация, относящаяся к «Ресурсам Microsoft Windows 2000 Server*, будет доступна в Интернете по мере се появления. Книга «Межсетевое взаимодействие» предоставляет глубокую техническую информацию о службах и протоколах, которые позволяют сетям Microsoft® Windows® 2000 взаимодействовать с самыми разнообразными локальными (LAN) и региональными сетями (WAN) и поддерживать соединения с удаленными сетями. В этой книге объясняется, как управлять всеми аспектами технологий межсетевого взаимодействия в Windows 2000, а также выявлять и устранять любые проблемы, возникающие в этой связи. Особое внимание уделяется: •
службе маршрутизации и удаленного доступа (Routing and Remote Access Service), в том числе технологиям виртуальных частных сетей (VPN);
•
взаимодействию Windows 2000 с другими операционными системами;
•
новейшим технологиям сетевых сред, в частности ATM (Asynchronous Transfer Mode) и поддержке телефонии.
Данная информация дополняет (но не заменяет) электронную документации), поставляемую с Microsoft Windows 2000 Server, и требует знания материалов, изложенных в книге «Сети TCP/IP. Ресурсы Microsoft Windows 2000 Server» (M.: Русская редакция, 2001).
Соглашения В этой книге приняты следующие соглашения по оформлению текста. Элемент оформления
Описание
Полужирное начертание шрифта Выделяет команды, ключи или символы, которые Вы вводите к диалоговом окне или в командной строке; точно так же выделяются и элементы пользовательского интерфейса Курсивное начертание шрифта Выделяет нгаблон для подстановки конкретных данных; например, вместо Filename,ext можно подставить имя нужного в данном случае файла
Введение Элемент оформления
Описание
Фиксированный
Выделяет примеры кода
%SystemRoot%
шрифт
XV
Папка, в которую установлена Windows 2000
Совет
Выделяет дополнительную информацию, необязатель-
Примечание
Выделяет любую другую дополнительную информацию
Внимание
Выделяет особо важную информацию, необходимую для выполнения данной операции; точно так же помечаются части текста, в которых предупреждается о возможности потери данных, сбоев системы, появлении брешей в лащите и других серьезных проблем в результате тех или иных действий
ную для выполнения данной операции
Компакт-диск «Ресурсы Microsoft Windows 2000 Server» Включает информационные ресурсы и утилиты, позволяющие эффективнее работать с операционной системой Windows 2000. Распространяется отдельно, прилагается к брошюре «Ресурсы Microsoft Windows 2000 Server. Компакт-диск: дополнительная техническая информация и утилиты для развертывания, настройки, оптимизации и поддержки Microsoft Windows 2000 Server» (M.: Русская редакция, 2001). Примечание Утилиты разработаны и протестированы с использованием американской версии Windows 2000. Выполнение этих программ в других версиях W i n dows 2000 или в Microsoft® Windows NT® может привести к непредсказуемым результатам. Компакт-диск содержит следующие материалы и программное обеспечение, Windows 2000 Server Resource Kit Online Books Электронные версии печатных книг в формате HTML Help. Дают возможность быстро находить информацию, необходимую лля выполнения какой-либо операции. Windows 2000 Server Resource Kit Tools and Tools Help Более 200 утилит с документацией на них и другие ресурсы, которые помогут полнее использовать возможности Windows 2000. Применяйте эти утилиты для управления службой каталогов Active Directory™, администрирования служб защиты, работы с реестром, автоматизации рутинных операций и выполнения многих других важных задач. Как пользоваться утилитами, Бы узнаете из документации Tools Help. Windows 2000 Server Resource Kit References формате HTML Help. •
Набор справочных материален в
Error and Event Messages Help Содержит большую часть сообщении об ошибках и событиях, генерируемых Windows 2000. Для каждого сообщения дается подробное описание и перечисляются возможные ответные действия со стороны пользователя.
XVI
Введение Technical Reference to the Registry Детальное описание ветвей, разделов, иодразделов и параметров реестра Windows 2000, в частности тех, которые могут понадобиться опытным пользователям и которые нельзя изменить средствами Windows 2000 или через программные интерфейсы. Performance Counter Reference Сведения обо всех объектах и счетчиках, предоставляемых для использования с инструментами оснастки (snap-in)* Performance (Производительность) в Windows 2000. Из этого справочника Вы узнаете, как применять различные счетчики (показатели) для диагностики проблем и выявления «узких мест» в Вашей системе. Group Policy Reference ки в Windows 2000.
Полное описание всех параметров групповой полити-
Техническая поддержка Техническая поддержка программного обеспечения Ресурсов не предусматривается. Microsoft не гарантирует безошибочную работу инструментальных средств и утилит, содержащихся на прилагаемом компакт-диске, немедленный ответ на какие-либо вопросы или исправление ошибок в программном обеспечении. Однако, если Вы обнаружите какие-либо ошибки в книгах или программном обеспечении Ресурсов, присылайте сообщения о них на адрес
[email protected], и. возможно, Вам будут предоставлены соответствующие исправления и обновления. Обратите внимание, что на этот адрес следует направлять сообщения лишь по вопросам, относящимся к «Ресурсам Microsoft Windows 2000 Server», а не к самой операционной системе Windows 2000. О том, как получить техническую поддержку по Windows 2000, Вы узнаете из документации, поставляемой с этим программным продуктом.
* Здесь используется терминология русской версии Windows 2000 Server. — Прим. перев.
ЧАСТЬ
I
Маршрутизация
Службы маршрутизации обеспечивают доставку IP- и IPX-трафика между сетями. В этой части излагаются базовые сведения о маршрутизации, а также о соответствующих протоколах и механизмах, поддерживаемых службой маршрутизации и удаленного доступа в Windows 2000.
В этой части Обзор одноадресной маршрутизации
2
Служба маршрутизации и удаленного доступа Одноадресная IP-маршрутизация Поддержка групповой IP-рассылки IPX-маршрутизация
22
48 115
148
Маршрутизация с соединением по требованию
177
ГЛАВА
!
Обзор одноадресной маршрутизации
Одноадресная маршрутизация (unicasi routing) — это пересылка одноадресного трафика от отправителя получателю по межсетевой среде (internetwork). Одноадресный трафик посылается на уникальный адрес. Чтобы разобраться в деталях работы протоколов маршрутизации (routing protocols), например RIP (Routing Information Protocol) и OSPF (Open Shortest Path First), и в их реализации в Microsoft'^ Windows* 2000 Server, важно иметь четкое представление о принципах одноадресной маршрутизации. Поскольку Windows 2000 с Routing and Remote Access Service (Служба маршрутизации и удаленного доступа) является открытой платформой, на которую может быть установлен практически любой протокол межсетевого взаимодействия и маршрутизации, в этой глаие дается обзор по одноадресной маршрутизации, независимой от конкретного протокола. В качестве примеров используются протоколы ТР (Internet Protocol) и IPX (Internetwork Packet Exchange). В этой главе Межсетевая маршрутизация 3 Концепции маршрутизации 4 Основы протоколов маршрутизации 18 Инфраструктура маршрутизации 20 См. также • О поддержке одноадресной IP-маршрутизации — главу 3 «Одноадресная IP-маршрутизация» в этой книге. • О поддержке IPX-маршрутизации — главу 5 «IPX-маршрутизапия» в этой книге. • О виртуальных частных сетях — главу 9 «Виртуальные частные сети» в этой книге.
ГЛАВА 1
Обзор одноадресной маршрутизации
Межсетевая маршрутизация Для понимания маршрутизации Вы должны знать следующие термины. Конечные системы (end systems). По определению International Standards Organization (ISO), конечные системы — это сетевые устройства, не способные пересылать пакеты между отдельными частями сети. Конечные системы также называются хостами (hosts). Промежуточные системы (intermediate systems). Сетевые устройства, способные пересылать пакеты между отдельными частями сети. К таким устройствам относятся мосты, коммутаторы и маршрутизаторы. Сеть (network). Часть сетевой инфраструктуры, ограниченная промежуточной системой сетевого уровня и имеющая тот же адрес сетевого уровня. Маршрутизатор (router). Промежуточная система сетевого уровня, соединяющая отдельные сети па основе общего протокола сетевого уровня. Аппаратный маршрутизатор (hardware router). Сетевое устройство, рассчитанное только на выполнение маршрутизации и аппаратно оптимизированное для этой задачи. Программный маршрутизатор (software router). Сетевое устройство, выполняющее маршрутизацию лишь как одну из множества функций. Программным маршрутизатором может быть компьютер под управлением Windows 2000 Server и службы маршрутизации. Межсетевая среда (internetwork). Минимум дне сети, соединенные маршрутизаторами (рис. 1-1). Межсетевая среда Сеть
Конечная система
Маршрутизатор
Промежуточная система
Конечная система
Рис. 1-1. Межсетевая среда
Адресация в межсетевой среде Для понимания маршрутизации важны и термины, относящиеся к адресации в межсетевой среде. Адрес сети, или сетевой адрес (network address). Также называется идентификатором сети. Это число, присваиваемое отдельной сети в межсетевой среде. Сетевые адреса используются хостами и маршрутизаторами при пересылке пакета от источника получателю в межсетевой среде. Адрес хоста (host address). Также называется идентификатором хоста, или идентификатором узла. Представляет собой либо физический адрес хоста (адрес сетевой
4
ЧАСТЬ 1
Маршрутизация
интерфейсной платы), либо назначенный администратором адрес, уникально идентифицирующий хост в своей сети. Межсетевой адрес (internetwork address). Комбинация адресов сети и хоста, которая уникально идентифицирует хост в межсетевой среде. IP-адрес, состоящий из идентификатора сети и идентификатора хоста, как раз и является межсетевым адресом. Подробнее о том, как в IP реализуется адресация па основе идентификаторов сетей и хостов, см. книгу «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server*. Когда пакет посылается от хоста-источника хосту-получателю в межсетевой среде, заголовок сетевого уровня в пакете содержит: •
межсетевой адрес источника (Source Internetwork Address) — определяет адреса сети и хоста отправителя;
•
межсетевой адрес получателя (Destination Internetwork Address) — определяет адреса сети и хоста получателя;
• счетчик переходов (Hop Count) — инициализируется либо нулевым значением и при пересечении каждого маршрутизатора увеличивается на 1 до некоего максимального значения, либо, наоборот, максимальным значением, которое уменьшается на 1 всякий раз, когда пакет проходит через очередной маршрутизатор, и в конечном счете достигает нулевого значения. Этот параметр предотвращает бесконечную циркуляцию пакета в межсетевой среде.
Концепции маршрутизации Маршрутизация — это процесс передачи данных по межсетевой среде от хоста-отправителя хосту-получателю. Опа может проходить как маршрутизация хостом (host routing) и как маршрутизация маршрутизатором (router routing). Маршрутизация хостом происходит, са сети получателя этот хост должен ту-получателю или маршрутизатору. ресованный хосту-получателю пакет
когда хост пересылает пакет. Исходя из адререшить, кому следует переслать пакет — хосПа рис. 1-2 хост-отправитель пересылает адмаршрутизатору 1.
г Маршрутизация хостом
• Хост-
отправитель
за Маршрутизатор 1
Маршрутизатор 2
Г Маршрутизация
Хост-
получатель
маршрутизатором
Рис. 1-2. Процесс маршрутизации Маршрутизация маршрутизатором происходит, когда маршрутизатор принимает пакет, который следует переслать другому адресату. Пакет пересылается между маршрутизаторами (если данный маршрутизатор не подключен напрямую к сети назначения) или между маршрутизатором и хостом-получателем (если данный мар-
ГЛАВА 1 Обзор одноадресной маршрутизации шрутизатор напрямую подключен к сети назначения). На рис. 1-2 маршрутизатор 1 пересылает пакет маршрутизатору 2, а тот — хосту-получателю.
Маршрутизация хостом Когда хосту, использующему маршрутизируемый протокол (rentable protocol), нужно послать данные другому хосту, он должен сначала выяснить межсетевой адрес получателя. Этот адрес определяется в процессе разрешения адреса, если хост-отправитель ссылается на хост-получатель по его логическому имени. Например, ч ля разрешения доменного DNS-имени в IP-адрес ТСР/1Р-хост использует DNS (Domain Name System). А для разрешения имени сервера в межсетевой IPX -адрес рабочие станции Novell NetWare запрашивают регистрационную базу данных (bindery), которая хранится на NetWare-сервере, или дерево каталогов своего основного сервера. После определения межсетевого адреса получателя проводится сравнение адресов сетей отправителя и получателя: Если эти адреса совпадают (отправитель и получатель находятся в одной сети), отправитель посылает пакеты непосредственно получателю без использования маршрутизатора (рис. 1-3). Хост-отправитель посылает пакет, ссылаясь на физический адрес получателя. Такая схема называется прямой доставкой (direct delivery). В этом случае межсетевой и физический адрес получателя относятся к одной и той же конечной системе. Если же отправитель и получатель находятся в разных сетях, источник не может напрямую доставлять пакеты адресату- Тогда отправитель посылает пакеты промежуточному маршрутизатору (рис. 1-3), адресуя их на физический адрес этого маршрутизатора. Данная схема называется непрямой доставкой (indirect delivery). В этом случае межсетевой и физический адрес получателя относятся к разным системам. В ходе непрямой доставки хост-отправитель пересылает пакет маршрутизатор 1 ;' в своей сети; при этом выбирается маршрутизатор, соответствующий первому переходу (hop), либо сначала определяется весь путь от источника до конечного адресата, Локальный хост
Хост-отправитель
Прямая доставка
Маршрутизатор
,00,
Рис. 1-3. Процесс маршрутизации хостом
Определение хостом первого перехода 1Р- и IPX-хосты определяют физический адрес маршрутизатора первою перехода одним из следующих способов.
ЧАСТЬ 1
Маршрутизация
Таблица маршрутизации на хосте. Такая таблица сообщает адрес маршрутизатора, который следует использовать для того, чтобы переслать пакет в нужную сеть. Примером может служить таблица IP-маршрутизации на ТСР/ТР-хосте. Детальное описание таблицы маршрутизации см. в разделе «Таблицы маршрутизации» далее в этой главе. Динамическое обновление таблицы маршрутизации на хосте. TCP/IP поддерживает механизм динамического обновления таблицы маршрутизации на хосте, записывая в нее более эффективные маршруты по мере пересылки пакетов адресатам. Для этого IP-маршрутизатор посылает хосту-отправителю ICMP-сообщение Redirect, которое информирует его о наличии более эффективного маршрута к хосту-получателю. В таблице маршрутизации этот маршрут становится маршрутом к данному хосту (host route). TCP/IP u Windows 2000 обеспечивает динамическое обновление таблицы IP-маршрутизации при получении ICMP-сообщения Redirect. Прослушивание. TCP/IP-хосты способны прослушивать трафик, передаваемый по протоколам маршрутизации, используемым маршрутизаторами. Эта функциональность известна под названием прослушивание (eavesdropping), или перехват (wiretapping). Прослушивающие хосты получают ту же информацию, что и маршрутизаторы. Пример — Silent RIP (Пассивный RIP). Silent RIP позволяет TCP/1Pхосту прослушивать RIP с целью полумения связанного с IP-маршрутизацией трафика, которым обмениваются RIP-маршрутизаторы, и на основе принимаемой информации обновлять свою таблицу маршрутизации. Поддержка Silent RIP реализована в Microsoft® Windows NT® Server 3.51 с Service Pack 2 (и выше), а также в Microsoft® Windows NT® Workstation 4.0 с Service Pack 4 (и выше). Маршрут по умолчанию. Для упрощения настройки хостов и маршрутизаторов, а также для сокращения издержек, связанных с тем, что на каждом хосте имеются маршруты ко всем сетям в межсетевой среде, хост-отправитель конфигурируется с единственным маршрутом по умолчанию. Этот маршрут и адрес основного маршрутизатора используются, когда не удается найти других маршрутов к сети назначения. В случае TCP/IP-хостов основным маршрутизатором является Default Gateway (Основной шлюз). Опрос сети для определения оптимального маршрута. Применительно к хостам, у которых нет таблицы маршрутизации или для которых не сконфигурирован основной маршрутизатор, хост-отправитель определяет физический адрес маршрутизатора первого перехода, опрашивая псе маршрутизаторы в сети. Запрос на определение наилучшего маршрута к сети назначения посылается как широковещательный (broadcast) или групповой (multicast) пакет. Хост-отправитель анализирует ответы от маршрутизаторов и выбирает самый эффективный маршрут. Пример такого процесса — RIP-сообщение GetLocalTarget, посылаемое IPX-хостом. Это сообщение содержит идентификатор нужной IPX-сети. IPX-маршрутизаторы в сети хоста-отправителя, способные достичь этой сети, посылают ответ хосту-отправителю. На основе RIP-ответов от локальных маршрутизаторов хост-отправитель выбирает наиболее подходящий маршрутизатор для пересылки IPX-пакета.
Определение хостом всего пути При использовании некоторых маршрутизируемых протоколов хост-отправитель определяет не только первый переход; он выполняет процесс обнаружения маршрута (route discovery process) и выбирает маршрут к адресату. После этого в заголо-
ГЛАВА 1
Обзор одноадресной маршрутизации
вок сетевого уровня включается список сетей или маршрутизаторов, который используется маршрутизаторами для пересылки пакета по указанному пути. Такой процесс называется маршрутизацией источника (source routing). При маршрутизации источника маршрутизаторы функционируют просто как приемопередающие устройства, поскольку все решения по выбору маршрута уже приняты хостом-отправителем. Маршрутизация источника не является типичным методом маршрутизации, так как путь должен быть либо известен, либо обнаружен. Процессы обнаружения маршрутов генерируют большие объемы трафика и,проходят довольно медленно. IP-маршрутизация обычно реализуется за счет принятия соответствующих решений хостами-отправителями и IP-маршрутизаторами на основе локальных таблиц маршрутизации. Однако при отладке и тестировании сети иногда приходится указывать точный маршрут через межсетевую IP-среду, заменяющий путь, который был бы выбран в нормальных условиях. Этот вариант называется IP-маршрутизацией источника (IP source routing). При IP-маршрутизации источника весь маршрут указывается хостом-отправителем как последовательный набор IP-адресов IP-маршрутизаторов на пути между источником и конечным адресатом. При этом на каждом IP-маршрутизаторе IP-дейтаграмма пересылается на следующий маршрутизатор с использованием поля IP-адреса получателя в IP-заголовке. IP поддерживает два типа мартпрутизации источника. Первый — это нестрогая мдршрутизация источника (loose source routing), при которой в качестве IP-адреса следующего маршрутизатора может быть указан маршрутизатор, отдаленный на несколько переходов. Второй тип — строгая маршрутизация источника (strict source routing), при которой следующим должен быть именно соседний маршрутизатор (отдаленный па один переход). Примечание Маршрутизация источника Token Ring представляет собой схему маршрутизации МАС-подуровня (MAC-sublayer routing scheme) и не применима к маршрутизации источника в межсетевой среде, о которой шла речь в данном разделе.
Маршрутизация маршрутизатором Маршрутизатор, получив пакет, адресованный другому сетевому устройству, должен доставить его либо хосту-получателю, либо другому маршрутизатору, как показано на рис. 1-4. Хост-получатель
Маршрутизатор
Йсшка "
.^..i
Маршрутизатор
Непрямая доставка
Рис. 1-4. Процесс маршрутизации маршрутизатором
8
•
ЧАСТЬ 1
Маршрутизация
Если сеть назначения совпадает с сетью, к которой подключен данный маршрутизатор, он пересылает пакет хосту-получателю, направляя его на физический адрес этого хоста. В этом случае маршрутизатор выполняет прямую доставку.
• Если сеть назначения, напротив, не подключена к данному маршрутизатору, он пересылает пакет промежуточному маршрутизатору, который выбирается на основе оптимального маршрута в таблице маршрутизации. При этом он пересылает пакет па физический адрес промежуточного маршрутизатора, т. е. выполняет непрямую доставку (на следующий маршрутизатор на пути к адресату).
Таблицы маршрутизации В процессе маршрутизации хосты и маршрутизаторы принимают решения, используя базу данных маршрутов — таблицу маршрутизации (routing table). Эта таблица ае является исключительной принадлежностью только маршрутизаторов. В зависимости от маршрутизируемого протокола на хостах тоже могут храниться таблицы маршрутизации, помогающие выбирать оптимальные маршруты для пересылаемых пакетов. Таблицы маршрутизации имеются на IP-хостах, но отсутствуют на IPX-хостах. Ниже перечислены типы записей, которые могут быть в таблице маршрутизации. Маршрут к сети (network route). Маршрут к сети с определенным идентификатором. Маршрут к хосту (host route). Маршрут к определенному межсетевому адресу (комбинации идентификаторов сети и хоста). Решение о маршрутизации принимается на основе не одного идентификатора сети, а в комбинации с идентификатором хоста. Такие маршруты позволяют принимать более «интеллектуальные» решения применительно к каждому межсетевому адресу. Маршруты к хостам обычно используются для создания нестандартных маршрутов, что позволяет контролировать или оптимизировать специфические виды межсетевого трафика. Маршрут по умолчанию (default route). Маршрут, используемый в том случае, если в таблице маршрутизации нет других маршрутов к адресату. Например, если маршрутизатор или конечная система не может найти маршрут к сети или к хосту получателя, выбирается маршрут по умолчанию. Последний упрощает настройку конечных систем или маршрутизаторов, позволяя не записывать в их таблицы маршруты к каждой сети в межсетевой среде. Примечание Во многих реализациях маршрутизаторов, включая службу маршрутизации и удаленного доступа в W i n d o w s 2000, поддерживается как таблица маршрутизации, так и таблица пересылки (forwarding table). Таблица маршрутизации храпит все маршруты от всех возможных источников, а таблица пересылки — это как раз то, что используется маршрутизируемым протоколом при пересылке пакета. Так, в случае маршрутизатора под управлением Windows 2000 служба маршрутизации и удаленного доступа поддерживает таблицу IP-маршрутизации, используя компонент Route Table Manager. Таблица IP-пересылки содержится в самом TCP/ IP. Route Table Manager обновляет эту таблицу на основе информации о маршрутах, поступающей из множества источников. Содержимое таблицы маршрутизации не обязательно соответствует содержимому таблицы пересылки. В этой вводной главе мы не будем делать различий между таблицами маршрутизации и пересылки.
ГЛАВА 1
Обзор одноадресной маршрутизации
9
Структура таблицы маршрутизации Записи таблицы маршрутизации обычно состоят из следующих нолей (рис. 1-5).
Идентификатор сети
Пересылочный адрес
Интерфейс
Метрика Срок действия
Рис. 1-5. Структура таблицы маршрутизации Идентификатор сети (Network ID), Поле, содержащее идентификационный номер (код) для маршрута к сети или межсетевой адрес для маршрута к хосту. Пересылочный адрес (Forwarding Address). Поле, содержащее адрес, на который следует пересылать пакеты. Пересылочный адрес может быть адресом сетевой интерфейсной платы (сетевого адаптера) или межсетевым адресом. В случае сетей, к которым конечная система или маршрутизатор подключены напрямую, поле пересылочного адреса может быть пустым. Интерфейс (Interface). Поле, указывающее сетевой интерфейс, который надо использовать при пересылке пакетов в определенную сеть. Это номер порта или какой-нибудь другой логический идентификатор. Например, интерфейс: для сетевого адаптера 3COM EtherLink III в таблице маршрутизации может быть указан как ELNK3. Метрика (Metric). Поле, указывающее «цену» маршрута; обычно выражается числом переходов (т. е. количеством пересекаемых маршрутизаторов) до конечной сети. Если к адресату ведет несколько маршрутов, выбирается тот, у которого минимальная метрика. Некоторые алгоритмы маршрутизации предусматривают запись в таблицу маршрутизации только по одному маршруту к каждому идентификатору сети — даже если возможно использование нескольких маршрутов. В этом случае маршрутизатор на основе значения в поле метрики решает, какой из маршрутов сохранить в таблице. Метрики могут содержать значения различных типов. Число переходов (hop count). Стандартная метрика. Сообщает число маршрутизаторов (переходов) на пути к сети с определенным идентификатором. Задержка (delay). Время, необходимое дли доставки пакета в определенную есть. Задержка отражает скоростные характеристики маршрута (в локальных сетях малые задержки, а в региональных — большие) или его загруженность.
10
ЧАСТЬ 1
Маршрутизация
Пропускная способность (throughput). Эффективный объем данных, который может быть передан по этому пути за секунду. Пропускная способность не обязательно отражает скорость передачи битов по данному каналу, поскольку очень загруженный канал Ethernet может иметь меньшую пропускную способность, чем незагруженный WAN-канал на 64 Кбит/с. Надежность (reliability). Мера постоянства пути. Некоторые типы каналов в большей степени подвержены сбоям, чем другие. Например, в случае WAN-каналов выделенные линии более надежны, чем обычные телефонные. Срок действия (Lifetime). Поле, указывающее срок действия данного маршрута; по истечении этого срока маршрут считается недействительным. Это поле используется при получении маршрутов в процессе обмена информацией с другими маршрутизаторами. Полученные маршруты имеют конечные сроки действия. Чтобы такие маршруты оставались в таблице маршрутизации, их нужно периодически обновлять. Как только срок действия маршрута, полученного в результате обмена информацией с другими маршрутизаторами, истекает, огн удаляется из таблицы маршрутизации. Этот механизм позволяет маршрутизаторам автоматически перенастраиваться при изменениях в топологии межсетевой среды, связанных с отключением какого-либо канала связи или маршрутизатора. Примечание Поле срока действия в таблицах маршрутизации обычно невидимо. Здесь был приведен список лишь стандартных полей в записях таблицы маршрутизации. Реальный набор полей зависит от конкретного маршрутизируемого протокола. Подробнее о таблице IP-маршрутизации см. книгу «Сети TCP/IP* из серии «Ресурсы Microsoft Windows 2000 Server». Подробнее о таблице IPX-маршрутизации см. главу 5 «IPX-маршрутизация» в этой книге.
Местонахождение таблицы маршрутизации Все решения по маршрутизации, принимаемые конечной системой или маршрутизатором, основываются на информации из локальной таблицы маршрутизации, которая физически находится в оперативной памяти данной системы. Единого, целостного представления межсетевой среды, которое собиралось бы каким-нибудь сервером и загружалось бы им на каждую конечную систему и каждый маршрутизатор, нет. Каждый маршрутизатор на пути между источником и конечным адресатом принимает решение о маршрутизации на основе собственной таблицы маршрутизации. Путь от источника к конечному адресату может не совпадать с маршрутом ответных пакетов от получателя. Если информация в локальных таблицах на конечных системах или маршрутизаторах некорректна из-за иеправттльнои настройки или изза изменения условий в сети, то с маршрутизацией могут возникнуть проблемы. Выявление и устранение таких проблем может потребовать изучения таблиц маршрутизации на конечных системах (отправителе и получателе) и на всех маршрутизаторах, пересылающих пакеты между этими системами. Об IP-маршрутизации см. главу 3 «Одноадресная IP-маршрутизация», а об IPXмаршрутизации — главу 5 «IPX-маршрутизация» в этой книге.
ГЛАВА 1
Обзор одноадресной маршрутизации
11
Статические и динамические маршрутизаторы Для эффективной маршрутизации между маршрутизаторами в межсетевой среде последние должны знать об идентификаторах других сетей или должны быть настроены на маршрут по умолчанию. В больших межсетевых средах таблицы маршрутизации следует настраивать так, чтобы трафик всегда проходил по оптимальным путям. Способ настройки этих таблиц зависит от того, какая маршрутизация используется — статическая или динамическая. Статическая маршрутизация Маршрутизатор с таблицей маршрутизации, сконфигурированной вручную, является статическим (static router). Сетевой администратор, знающий топологию межсетевой среды, вручную создает и обновляет таблицу маршрутизации, программируя в ней все маршруты, Статические маршрутизаторы эффективно работают в малых межсетевых средах, но плохо масштабируются и не могут динамически реагировать на изменения в межсетевой среде из-за необходимости управления ими вручную. Статические маршрутизаторы не являются отказоустойчивыми. Срок действия вручную сконфигурированного статического маршрута бесконечен, и поэтому статические маршрутизаторы не распознают отключения каких-либо маршрутизаторов или каналов связи. Яркий пример статического маршрутизатора — многоадресный компьютер под управлением Windows 2000 (многоадресным называется компьютер с несколькими сетевыми адаптерами). Создать статический IP-маршрутизатор с помощью W i n dows 2000 несложно: установите несколько сетевых адаптеров, настройте TCP/IP и разрешите применение IP-маршрутизации, Динамическая маршрутизация Маршрутизатор с динамически конфигурируемыми таблицами маршрутизации называется динамическим (dynamic router). В этом случае таблицы маршрутизации создаются и поддерживаются автоматически — за счет обмена информацией между маршрутизаторами. Такое взаимодействие обеспечивается протоколом маршрутизации, но которому периодически или по требованию передаются серии сообщений, содержащие информацию о маршрутизации. Если не считать начальной настройки, динамические маршрутизаторы практически не требуют обслуживания и поэтому легко масштабируются при расширении межсетевой среды. Динамическая маршрутизация обеспечивает отказоустойчивость. Динамические маршруты, получаемые от других маршрутизаторов, имеют конечный срок действия. Если какой-либо маршрутизатор или канал связи выходит из строя, динамические маршрутизаторы распознают соответствующее изменение в топологии межсетевой среды, как только в таблице маршрутизации истекает срок действия ранее полученного маршрута. Информация об этом изменении распространяется на другие маршрутизаторы, и в конечном счете все маршрутизаторы в межсетевой среде узнают о ее новой топологии. Благодаря способности к масштабированию и автоматическому восстановлению после сбоев в межсетевой среде динамическая маршрутизация — более эффективный выбор для средних, больших и очень больших межсетевых сред.
12
ЧАСТЬ 1
Маршрутизация
Типичный пример динамического маршрутизатора — компьютер под управлением Windows 2000 Server и службы маршрутизации и удаленного доступа, на котором работают протоколы RIP for IP и OSPF tor IP, а также RIP for IPX.
Проблемы маршрутизации Проблемы с маршрутизацией возможны, когда в таблице маршрутизации либо хоста, либо одного из маршрутизаторов содержится информация, неправильно отражающая топологию межсетевой среды.
Петли маршрутизации В процессе маршрутизации маршрутизатором пакеты пересылаются по оптимальному пути в соответствии с информацией, записанной в локальной таблице маршрутизации. Если записи таблиц маршрутизации на всех маршрутизаторах правильны, пакет следует по оптимальному маршруту от источника к получателю. Но, если какая-то из записей в таблице маршрутизации неверна (из-за неправильной настройки или из-за того, что полученный маршрут не точно отражает топологию межсетевой среды), могут формироваться так называемые петли маршрутизации (routing loops). Петля маршрутизации — это путь к сети с определенным идентификатором, замкнутый на себя. Рис. 1-6 иллюстрирует петлю маршрутизации, возникшей при следующих условиях: • согласно таблице маршрутизации на маршрутизаторе 1, оптимальный маршрут к сети 10 проходит через маршрутизатор 2; • согласно таблице маршрутизации на маршрутизаторе 2, оптимальный маршрут к сети 10 проходит через маршрутизатор 3; • согласно таблице маршрутизации па маршрутизаторе 3, оптимальный маршрут к сети 10 проходит через маршрутизатор 1. Чтобы предотвратить бесконечное циркулирование пакета, в заголовке сетевого уровня присутствует счетчик переходов. Всякий раз, когда маршрутизатор передает пакет из одной сети в другую, он либо увеличивает, либо уменьшает счетчик переходов на 1. Если этот счетчик достигает своего максимума (в случае увеличения) или обнуляется (в случае уменьшения), маршрутизатор отбрасывает пакет. Маршрутизатор 2 Сеть 10 Сеть 10
Маршрутизатор 1
Сеть 10
Маршрутизатор 3
Рис. 1-6. Петля маршрутизации
ГЛАВА 1
Обзор одноадресной маршрутизации
13
Например, IPX-хост посылает IPX-пакеты, присваивая счетчику переходов нулевое значение. Каждый маршрутизатор RIP for IPX увеличивает этот счетчик на 1. Когда он достигает 17, пакет «молча» отбрасывается. IP-хост, посылая IP-пакеты, записывает в поле TTL (Tim e-to-Live) IP-заголовка максимальное число переходов, Каждый IP-маршрутизатор на пути пакета уменьшает TTL на 1. Когда TTL становится равным 0, IP-маршрутизатор отбрасывает пакет и посылает хосту-отправителю ICMP-сообщение Time Exceeded. По умолчанию TCP/IP-хосты под управлением Windows NT версии 4.0 (и выше) присваивают TTL значение 128.
Черные дыры Наиболее распространенные межсетевые протоколы вроде IP и IPX не ориентированы на логические соединения (connectionless) и используют дейтаграммы. Они не гарантируют успешную доставку. IP и IPX осуществляют доставку и точку очередного перехода или конечному адресату по принципу «максимум возможного» (best effort delivery) и не ожидают подтверждения о приеме данных. А это может создавать такие условия в межсетевой среде, при которых данные теряются. Если следующий на пути маршрутизатор (downstream router) выхолит из строя и этот факт не распознается предыдущим на пути маршрутизатором (upstream router), то последний продолжает пересылать пакеты первому. Поскольку вышедший из строя маршрутизатор не принимает пакеты, они «выпадают» из межсетевой среды. Получается, что предыдущий маршрутизатор посылает пакеты в черную дыру, — это ситуация в межсетевой среде, при которой пакеты теряются, а об ошибке ничего не сообщается. Так, па рис. 1-7 маршрутизатор 1, не уведомленный о том, что маршрутизатор 2 отключен, продолжает посылать ему пакеты. И отключенный маршрутизатор 2 создает черную дыру. Хост-отправитель
Непрямая доставка Непрямая доставка
Хост-получатель
Рис. 1-7, Маршрутизация при образовании черной дыры Черные дыры могут образовываться, когда канал связи или маршрутизатор выводит из строя и авария еще не обнаружена. В среде со статической маршрутизацией черные дыры сохраняются до восстановления канала связи или маршрутизатора либо до перенастройки статических маршрутизаторов сетевым администратором В среде с динамической маршрутизацией неработающие каналы связи или маршрутизаторы распознаются по истечении срока действия маршрутов, полученных в результате обмена информацией с другими маршрутизаторами.
14
ЧАСТЬ 1
Маршрутизация 1
Черные дыры могу возникать и в тех случаях, когда активный маршрутизатор отбрасывает пакеты, не сообщая о причине этого. Примером может служить маршрутизатор типа «черная дыра* PMTU (PMTU black hole router), который отбрасывает IP-пакеты, подлежащие фрагментации, и не посылает отправителю сообщение о соответствующей ошибке. Обнаружить такие маршрутизаторы весьма непросто, потому что пакеты меньшего размера пересылаются нормально. Подробнее на эту тему см. книгу «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server*.
Маршрутизаторы и широковещательный трафик Широковещательный трафик межсетевого уровня представляет собой широковещательные кадры МАС-уровня со специальным межсетевым адресом, который информирует маршрутизатор о том, что соответствующие пакеты следует пересылать во все сети, кроме той, из которой они поступают. Маршрутизаторы — и отличие от мостов — но пересылают широковещательный трафик МАС-уровня. Для передачи широковещательного трафика межсетевого уровня маршрутизаторы требуют дополнительной настройки. В сети широковещательные кадры МАС-уровня рассылаются каждому хосту. Для передачи такого трафика каждому хосту в межсетевой среде некоторые маршрутизируемые протоколы поддерживают широковещание межсетевого уровня (internetwork-level broadcasts). Потенциальная опасность пересылки широковещательного трафика межсетевого уровня заключается в том, что существует возможность лавинообразного нарастания широковещательного трафика в межсетевой среде, если какой-то хост работает некорректно и постоянно посылает один и тот же широковещательный пакет межсетевого уровня. Если маршрутизаторы пересылают такой трафик, все хосты в межсетевой среде вынуждены обрабатывать каждый широковещательный кадр, и в конечном счете работа всей межсетевой среды скорее всего просто парализуется. Широковещание «NetBIOS поверх IPX» как раз и является широковещанием межсетевого уровня. NetBIOS-приложения в межсетевой IPX-среде при регистрации, разрешении и освобождении имен используют широковещательные рассылки «NetBIOS поверх IPX*. IPX-маршрутизатор, получив широковещательный пакет «NetBIOS поверх IPX», отмечает сеть, из которой поступил этот пакет, в заголовке «NetBIOS поверх IPX». Таким образом, по мере прохождения пакета но межсетевой среде в этом заголовке регистрируется его маршрут. Перед пересылкой IPX-маршрутизатор проверяет эту информации», чтобы не допустить пересылку широковещательного пакета «NetBIOS поверх IPX» в сеть, которую он уже прошел. Это предотвращает зацикливание широковещательного пакета и лавинообразное нарастание широковещательного трафика. В качестве дополнительной меры предосторожности широковещательные пакеты «NetBIOS поверх IPX» могут распространяться только через восемь сетей с использованием максимум семи маршрутизаторов. На восьмом маршрутизаторе пакет отбрасывается без уведомления хоста-отправителя. Подробнее о широковещании «NetBIOS поверх IPX» см. главу 5 «IPX-маршрутизация» и этой книге. Примечание Путь в межсетевой IPX-среде аналогичным образом регистрируется в информации о маршрутизации на МАС-нодуровне (MAC-sublaycr routing information) внутри кадра Explorer, связанного с маршрутизацией источника в Token Ring (Token Ring source routing Explorer frame). Однако в отличие от случая марш-
ГЛАВА 1
Обзор одноадресной маршрутизации
15
рутизании источника Token Ring путь в межсетевой IPX-среде при последующей коммуникационной связи не используется — он применяется только для того, чтобы не допустить повторной пересылки широковещательного пакета в ту же IPX-сеть.
Туннелирование Туннелирование (tunneling), также известное как инкапсулирование (encapsulation), — это способ использования межсетевой инфраструктуры одного протокола для передачи «полезной нагрузки» (т. е. собственно данных), которая, как правило, представляет собой кадры (или пакеты) другого протокола (рис. 1-8). Вместо отправки кадров по мере их генерации хостом-отправителем они инкапсулирую гея в пакет с дополнительным изголовком. Этот заголовок содержит информацию о маршрутизации, чтобы инкапсулированные данные могли быть переданы через промежуточную среду (также называемую транзитной). Далее пакеты проходят сшж путь между конечными точками тутшеля, сформированного в транзитной межсетевой среде. Как только пакеты е инкапсулированной полезной нагрузкой достигают точки назначения, из них извлекаются исходные кадры, которые и пересылаются конечному адресату. Таким образом, Туннелирование — это процесс, включающий инкапсуляцию кадров в пакеты, их передачу и восстановление исходных кадров. Логический путь пакетов с инкапсулированными кадрами по транзитной межсетевой среде называется туннелем. Конечные точки туннеля Заголовок межсетевого транзита Транзитная межсетевая среда
Полезные данные
Туннелированные полезные данные
Туннель
Полезные данные
Рис. 1-8. Туннелирование Транзитной может быть любая межсетевая ереда, например Интернет. Ниже перечислены некоторые распространенные типы тупнелирования. SNA Tunneling over IP Internetworks. Для передачи SNA-трафика (System Network Architecture) через корпоративную межсетевую IP-среду SNA-кадр инкапсулируется в пакет с заголовками UDP (User Datagram Protocol) и IP. Этот вариант известен под названием Data Link Switching (DLSw) и описан и RFC 1795. IPX Tunneling for Novell NetWare. IPX-пакеты передаются Net Ware-серверу и in IPX-маршрутизатору, который включает в них UDP- и IP-заголовки, а затем посылает полученные пакеты через межсетевую IP-среду. IP-маршрутизатор в сети назначения удаляет UDP- и IP-заголовки и пересылает пакеты конечному 1РХ-хосгу. Point-to-Point Tunneling Protocol
16
ЧАСТЬ 1
Маршрутизация
поративную межсетевую ТР-среду или открытые межсетевые среды типа Интернета. Подробнее на эту тему см. главу 9 «Виртуальные частные сети» в этой книге. Layer 2 Tunneling Protocol (L2TP). L2TP позволяет шифровать IP-, IPX- или NetBEUI-трафик, а затем передавать его по любой среде, которая поддерживает доставку дейтаграмм по типу «точка-точка», например по IP, Х.25, Frame Relay или ATM. Подробнее на эту тему см. главу 9 «Виртуальные частные сети» в этой книге, IP Security (IPSec) Tunnel Mode. IPSec Tunnel Mode позволяет шифровать полезные данные IP, а затем инкапсулировать их в пакеты с IP-заголовком для передачи через корпоративную межсетевую IP-среду или открытые межсетевые среды типа Интернета. Подробнее об IPSec см. книгу «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». Примечание В Windows 2000 Server включена поддержка туннелирования только по РРТР, L2TP и IPSec.
Основы протоколов маршрутизации Динамические маршрутизаторы используют протоколы маршрутизации для взаимодействия друг с другом и динамическою обновления таблиц маршрутизации. Эти протоколы применяются между маршрутизаторами и создают в сети дополнительный трафик, который может стать важным фактором при планировании нагрузки на WAN-канал. RIP for IP, OSPF for [P, а также RIP for IPX и NLSP for IPX - все это протоколы маршрутизации. Некоторые из них, например RIP for IP (версии 1) и RIP for IPX, для обмена информацией о маршрутизации используют широковещание МАС-уровня. Важный элемент реализации протокола маршрутизации — его способность распознавать сбои в межсетевой среде и восстанавливаться после них. Насколько быстро происходит восстановление после сбоя, зависит от типа сбоя, способа его распознавания и метода распространения информации о маршрутизации в межсетевой среде. Когда и таблицах маршрутизации на всех маршрутизаторах в межсетевой среде содержится корректная информация о маршрутах, межсетевая среда пребывает в стабильном состоянии (достигнута конвергенция) и вее потоки данных идут по оптимальным маршрутам. Когда какой-то канал связи или маршрутизатор выходит из строя, межсетевая среда должна перенастроиться под новую топологию. Соответственно должна обновиться информация в таблицах маршрутизации. Пока межсетевая среда не достигнет конвергенции, она будет находиться в нестабильном состоянии, при котором могут возникать петли маршрутизации и появляться черные дыры. Период, необходимый на восстановление стабильного состояния межсетевой среды, называется временем конвергенции (convergence time). Это время зависит от применяемого протокола и вида сбоя (отказ канала связи или отключение маршрутизатора). Протоколы маршрутизации базируются па одной из двух технологий: векторе расстояний (distance vector) или состоянии канала (link state). Протоколы, построенные на этих двух технологиях, отличаются тем, как и когда происходит обмен информацией о маршрутизации, а также тем, насколько быстро может восстановиться межсетевая среда после отключения канала связи или маршрутизатора.
ГЛАВА 1 Обзор одноадресной маршрутизации
17
Вектор расстояний Маршрутизаторы, использующие протоколы маршрутизации на основе векторов расстояний (distance vector-based routing protocols), периодически оповещают друг друга о маршрутах, записанных в их таблицах маршрутизации. Информация, которой обычно обмениваются такие маршрутизаторы, не синхронизируется и не требует подтверждения о приеме. Некоторые протоколы маршрутизации на основе векторов расстояний перечислены в таблице 1-1. Таблица 1-1. Протоколы маршрутизации на основе векторов расстояний Маршрутизируемый протокол
Протокол маршрутизации на основе векторов расстояний
IP
RIP (Routing Information Protocol) IGRP (Interior Gateway Routing Protocol) RIP RTMP (Routing Table Maintenance Protocol)
IPX AppIeTalk
Преимущества протоколов маршрутизации на основе векторов расстояний •
Простота реализации — такие протоколы не требуют сложных процессов оповещения маршрутизаторов.
• Легкость настройки — в простейшем случае вся настройка протокола маршрутизации на основе векторов расстояний заключается лишь в том, что Вы разрешаете его применение на интерфейсах маршрутизатора. Недостатки протоколов маршрутизации на основе векторов расстояний •
Большой размер таблиц маршрутизации — в таблице маршрутизации может присутствовать несколько записей с маршрутами к одной и той же сети. В больших межсетевых средах со множеством путей в таблице маршрутизации могут оказаться сотни или даже тысячи записей.
•
Большой объем дополнительного сетевого трафика — оповещение о маршрутах выполняется через регулярные интервалы времени, даже если топология межсетевой среды остается неизменной.
• Невозможность масштабирования — из-за больших размеров таблиц маршрутизации и высоких издержек, связанных с дополнительным трафиком, протокол ы маршрутизации на основе векторов расстояний плохо работают в крупных и очень крупных межсетевых средах. • Длительное время конвергенции — из-за отсутствия синхронизации и подтверждений о приеме передаваемой информации о маршрутизации конвергенция межсетевой среды занимает до нескольких минут, и в этот промежуток могут возникать петли маршрутизации и черные дыры.
Состояние канала Маршрутизаторы, использующие протоколы маршрутизации на основе состояния каналов (link state-based routing protocols), обмениваются объявлениями о состоянии каналов связи для обновления своих таблиц; маршрутизации. Такое объявление состоит из списка идентификаторов сетей, к которым подключен маршрутизлтор; оно посылается маршрутизатором при запуске и при распознавании любых
18
ЧАСТЬ 1
Маршрутизация
изменений в топологии межсетевой среды. Обновления состояния каналов передаются как адресный или групповой трафик; широковещание не применяется. Маршрутизатор этого вида создает базу данных с объявлениями о состоянии каналов связи и использует ее для формирования таблицы маршрутизации. Информация о маршрутизации, которой обмениваются такие маршрутизаторы, синхронизируется и требует подтверждения о приеме. Некоторые протоколы маршрутизации на основе состояния каналов перечислены в таблице 1-2. Таблица 1-2. Протоколы маршрутизации на основе состояния каналов Маршрутизируемый протокол
Протокол маршрутизации на основе состояния каналов
IP IPX
OSPF (Open Shortest Path First) NLSP (NetWare Link Services Protocol)
Преимущества протоколов маршрутизации на основе состояния каналов •
Компактность таблиц маршрутизации — в них хранится лишь по одному оптимальному маршруту к каждой сети.
• Малый объем дополнительного сетевого трафика — маршрутизаторы не обмениваются информацией, если межсетевая среда достигла конвергенции. • Возможность масштабирования — из-за малых размеров таблиц маршрутизации и низких издержек, связанных с дополнительным трафиком, протоколы маршрутизации на основе состояния каналов хорошо работают в крупных и очень крупных межсетевых средах. • Малое время конвергенции — протоколы маршрутизации на основе состояния каналов обеспечивают меньшее время конвергенции и практически исключают вероятность появления петель маршрутизации. Недостатки протоколов маршрутизации на основе состояния каналов Сложность реализации — эти протоколы гораздо сложнее, чем протоколы маршрутизации на основе векторов расстояний. • Трудность настройки — применение протокола маршрутизации на основе состояния канала требует дополнительного планирования и конфигурирования. ш
•
Интенсивное использование вычислительных ресурсов — в очень больших межсетевых средах база данных объявлений о состоянии каналов связи требует больших объемов памяти, а вычисления, связанные с записями таблицы маршрутизации, сильно нагружают процессор.
Инфраструктура маршрутизации Инфраструктура маршрутизации — это вся структура маршрутизируемой межсетевой среды. При выборе маршрутизируемых протоколов и протоколов маршрутизации следует учитывать ряд важных свойств такой инфраструктуры,
Одно- и многопутевая инфраструктуры маршрутизации Однопутевая инфраструктура маршрутизации (single-path routing infrastructure), в которой каждая из сетей в межсетевой среде связана одним маршрутом, позволяет упростить таблицы маршрутизации и пути передачи данных, но не обеспечивает
ГЛАВА 1
Обзор одноадресной маршрутизации
19
отказоустойчивости. Динамический маршрутизатор может распознать сбой в межсетевой среде, но соответствующие сети останутся недоступными до тех пор, пока этот сбой не будет устранен. Успешная доставка пакетов в эти сети возможна лишь после того, как вышедший из строя канал связи или маршрутизатор будет возиращен в работоспособное состояние. Многопутевая инфраструктура маршрутизации (nniltipath routing infrastructure), в которой каждая из сетей в межсетевой среде связана множеством маршрутов, обладает высокой отказоустойчивостью при использовании динамической маршрутизации, а некоторые протоколы маршрутизации, например OSPF, могут распределять сетевой трафик по нескольким маршрутам с одинаковой метрикой. Однако многопутевые межсетевые среды более сложны в конфигурировании, а вероятность иозникповения в них петель маршрутизации в ходе конвергенции (при использовании протоколов маршрутизации на основе векторов расстояний) выше.
Плоская и иерархическая инфраструктуры маршрутизации В плоской инфраструктуре в таблице маршрутизации представлены все идентификаторы сетей, и они не содержат идентификаторы подсетей. Межсетевые IPX-среды на основе RIP используют линейную адресацию и имеют плоскую инфраструктуру маршрутизации (flat routing infrastructure). В иерархической инфраструктуре маршрутизации (hierarchical routing infrastructure) группы идентификаторов сетей могут быть представлены единствен! шй записью в таблице маршрутизации за счет суммирования маршрутов (route summarization). Идентификаторы сетей в такой инфраструктуре включают идентификаторы подсетей и вложенных подсетей (sub-subnet IDs). Запись в таблице маршрутизации для высшего уровня (сети) также является маршрутом, который используется для подсетей этой сети и вложенных в них подсетей. Иерархические инфраструктуры маршрутизации упрощают таблицы маршрутизации и уменьшают объемы информации, которой обмениваются маршрутизаторы, но требуют более тщательного планирования. IP реализует иерархическую адресацию к сетям, и поэтому межсетевые IP-среды могут иметь иерархическую структуру маршрутизации. При иерархической инфраструктуре маршрутизации межсетевая среда делится на домены маршрутизации (routing domains), также называемые регионами (regions) или областями (areas). Домен маршрутизации — набор смежных сетей, соединенных маршрутизаторами, которые совместно используют одну и ту же информацию о маршрутах внутри этого домена. Домены маршрутизации объединяются общим доменом маршрутизации (common routing domain), также называемым магистралью (backbone). Внутридомснпая маршрутизация осуществляется маршрутизаторами, расположенными в данном домене, а междоменная — маршрутизаторами домена, подключенными к магистрали.
Автономные системы Очень большие межсетевые среды приходится делить на отдельные пространства, называемые автономными системами (autonomous systems, AS) (рис. 1-9). Автономная система — это часть межсетевой среды, находящаяся в ведении одного административного центра. Этим центром может быть некое учреждение или корпорация; однако он может быть определен с помощью одного из протоколов маршрутизации, например OSPF. Непрерывная часть межсетевой IP-среды, в которой для распрос-
20
ЧАСТЬ 1
Маршрутизация
гранения информации о маршрутизации применяется OSPF, считается находящейся в ведении административного центра OSPF (OSPF administrative authority) и, следовательно, является автономной системой OSPF. Автономная система в свою очередь может быть разделена на регионы (домены, области), определяющие иерархическую структуру автономной системы. Протоколы, используемые для распространения информации о маршрутизации внутри автономной системы, известны как протоколы внутренних шлюзов (Interior Gateway Protocols, IGP). а протоколы, применяемые для распространения информации о маршрутизации между автономными системами, — как протоколы внешних шлюзов (Exterior Gateway Protocols, KGP).
IGP
Рис. 1-9. Автономные системы с протоколами IGP и EGP
IGP-протоколы IGP — это протоколы маршрутизации, применяемые внутри автономной системы. По ним распространяется информация о маршрутах внутри автономной системы, имеющей плоскую или иерархическую структуру. IGP-протоколы для межсетевых IP-сред: • RIP for IP — стандартный IGP на основе векторов расстояний; • OSPF — стандартный IGP на основе состояния каналов; • IGRP (Interior Gateway Routing Protocol) — нестандартный IGP на основе векторов расстояний, разработанный компанией Cisco Systems, Inc.
EGP-протоколы EGP — это протоколы маршрутизации, применяемые между автономными системами. EGP определяют, как сети внутри автономной системы объявляют о себе за пределами этой системы. В плоской инфраструктуре маршрутизации может предо-
ГЛАВА 1
Обзор одноадресной маршрутизации
21
ставляться список маршрутов к сетям, а в иерархической — список суммированных маршрутов к сетям. EGP независимы от IGP, применяемых внутри автономной системы. EGP упрощают обмен информацией о маршрутах между автономными системами, использующими различные IGP. EGP-протоколы для межсетевых IP-сред: • EGP (Exterior Gateway Protocol) — стандартный EGP, разработанный для использования между автономными системами в Интернете. В Интернете болыие не применяется из-за отсутствия поддержки сложных многопутевых сред и CTDR (Classless Inter-Domain Routing); • BGP (Border Gateway Protocol) — стандартный EGP, используемый между автономными системами в Интернете в настоящее время. В BGP устранены недостатки, присущие EGP.
Дополнительные материалы Более подробную информацию о маршрутизации см. в следующих книгах: • Christian Huitema «Routing in the Internet», Englewood Cliffs, NJ: 1995, Prentice Ball; •
Radia Perlman «Interconnections: Bridges and Routers», Reading, MA: 19':*2, Ad dison-Wesley.
ГЛАВА
Служба маршрутизации и удаленного доступа
Windows 2000 включает службу маршрутизации и удаленного доступа, которая обеспечивает маршрутизацию по нескольким протоколам и удаленный доступ, а также предоставляет серверную часть поддержки виртуальных частных сетей для компьютеров под управлением Windows 2000 Server. В этой главе Введение в службу маршрутизации и удаленного доступа 23 Функциональность службы маршрутизации и удаленного доступа Архитектура службы маршрутизации и удаленного доступа Дополнительные средства, поставляемые со службой маршрутизации и удаленного доступа 40
27
31
См. также • Об одноадресной IP-маршрутизации — главу 3 «Одноадресная IP-маршрутизация» и этой книге. • О групповой IP-рассылке — главу 4 «Поддержка групповой IP-рассылки» в этой книге. • Об IPX-маршрутизации — главу 5 «IPX-маршрутизация» в этой книге, • О соединении по требовании» — главу 6 «Маршрутизация с соединением по требованию* в этой книге. • •
Об удаленном доступе — главу 7 «Сервер удаленного доступа» в этой книге. О поддержке виртуальных частных сетей — главу 9 «Виртуальные частные сети» в этой книге.
ГЛАВА 2
Служба маршрутизации и удаленного доступа
23
Введение в службу маршрутизации и удаленного доступа Впервые поддержка маршрутизации по нескольким протоколам для операционных систем семейства Windows NT была введена в Microsoft® Windows NT® 3.51 Service Pack 2, который включал компоненты для RIP for IP, RIP for IPX и SAP for IPX. В Windows NT 4.0 эти компоненты тоже присутствовали. В июне 1996 года Microsoft выпустила для Windows NT 4.0 службу маршрутизации и удаленного доступа (Flouting and Remote Access Service, RRAS) — компонент, заменивший службу удаленного доступа (Remote Access Service) Windows NT 4.0, а также сервисы RIP for IP, RIP for IPX и SAP for IPX. RRAS для Windows NT 4.0 поддерживала: • • •
• •
протокол маршрутизации RIP for IP версии 2; протокол маршрутизации OSPF for IP; маршрутизацию с соединением по требованию (demand-dial routing) по постоянным (persistent) либо подключаемым по требованию (on-demand) WAN-каналам (например, по аналоговым телефонным линиям и ISDN) или с применением РРТР (Point-to-point Tunneling Protocol); обнаружение маршрутизатора средствами 1СМР (ICMP Router Discovery); клиент RADIUS (Remote Authentication Dial-In User Service);
• фильтрацию IP- и IPX-пакетов; • РРТР для VPN-соединений между маршрутизаторами; • административную программу с графическим пользовательским интерфейсом (Routing and RAS Admin) и утилиту командной строки (Routemon).
Служба маршрутизации и удаленного доступа в Windows 2000 Служба маршрутизации и удаленного доступа в Windows 2000 Server — это дальнейшее развитие многопротокольных служб маршрутизации и удаленного доступа для платформы Windows. Вот некоторые из новых средств и возможностей этой службы: • • • • •
поддержка 1GMP (Internet Group Management Protocol) и ограничителей rpvnновой рассылки (multicast boundaries); трансляция сетевых адресов, упрощающая соединение сети малого или домашнего офиса с Интернетом; маршрутизация Integrated AppleTalk; поддержка L2TP (Layer Two Tunneling Protocol) поверх IPSec (IP-безопасность) для VPN-соединений между маршрутизаторами; более совершенные средства администрирования и управления — компонент Routing and Remote Access (Маршрутизация и удаленный доступ), который является оснасткой Microsoft Management Console (MMC) (Консоль управления Microsoft), и Netsh, утилита командной строки.
Функциональность службы маршрутизации и удаленного доступа позволяет компьютеру под управлением Windows 2000 Server выступать в нескольких ролях.
24
ЧАСТЬ 1
Маршрутизация
•
Многопротокольный маршрутизатор (multiprotocol router). Компьютер со службой маршрутизации и удаленного доступа может пересылать IP-, IPX- и AppleTalk-пакеты одновременно. Все маршрутизируемые протоколы и протоколы маршрутизации настраиваются с помощью одной оснастки (Routing and Remote Access). • Маршрутизатор с поддержкой соединения по требованию (demand-dial router). Компьютер со службой маршрутизации и удаленного доступа может пересылать IP- и IPX-пакеты по постоянным или подключаемым но требованию WAN-каналам (например, по аналоговым телефонным линиям и ISDN) либо по VPN-соединениям с использованием РРТР или L2TP поверх IPSec. • Сервер удаленного доступа (remote access server). Компьютер со службой маршрутизации и удаленного доступа может функционировать как сервер удаленного доступа к сети для клиентов, соединяющихся по коммутируемым линиям (dial-up clients), или для VPN-клиентов с использованием IP, IPX, AppleTalk или NetBEUI.
Сочетание сервисов маршрутизации и удаленного доступа на одном компьютере позволяет превратить его в маршрутизатор удаленного доступа (remote access router). Преимущество службы маршрутизации и удаленного доступа — ее тесная интеграция с операционной системой Windows 2000 Server. Эта служба работает на широком спектре аппаратных платформ и с сотнями моделей сетевых адаптеров; в результате Вы получаете более экономичное решение, чем при использовании выделенных маршрутизаторов или серверов удаленного доступа среднего ценового уровня. Служба маршрутизации и удаленного доступа предусматривает возможность расширения за счет поддержки нескольких API, с помощью которых сторонние разработчики могут создавать собственные сетевые решения.
Объединение маршрутизации и удаленного доступа Зачем понадобилось объединять маршрутизацию и удаленный доступ в одну службу? В первоначальной версии Windows NT 4.0 обе службы работали отдельно. Причина объединения двух служб связана с РРР (Point-to-Point Protocol) — набором протоколов, часто применяемых при установлении соединений типа «точкаточка» для клиентов удаленного доступа. РРР обеспечивает согласование параметров канала, обмен аутентификационными удостоверениями и согласование протокола сетевого уровня. Например, когда Вы уста![аиливаете связь с провайдером услуг Интернета (Internet Service Provider, ISP) no телефонной линии, используя РРР, Ваш модем договаривается о размере посылаемых им пакетов и о том, как они разбиваются на кадры (этап согласования канала); далее Вы вводите свое имя и пароль (этап аутентификации) и, наконец, получаете IP-адрес (этап согласования сетевого уровня). При маршрутизации с соединением по требованию РРР используется в тех же целях, что и при удаленном доступе (согласование канала, аутентификация и согласование сетевого уровня). Таким образом, интеграция маршрутизации (которая включает маршрутизацию с соединением но требованию) и удаленного доступа позволила задействовать клиент-серверную инфраструктуру РРР, уже существовавшую для компонентов поддержки удаленного доступа.
ГЛАВА 2
Служба маршрутизации и удаленного доступа
25
Инфраструктура РРР в Windows 2000 Server включает поддержку: • удаленного доступа по коммутируемым линиям (например, по аналоговым телефонным линиям и ISDN) в качестве либо клиента, либо сервера; •
удаленного VPN-доступа (удаленного доступа через VPN-соединения с использованием РРТР или L2TP поверх IPSec) в качестве либо клиента, либо сервера;
• маршрутизации с соединением по требованию по коммутируемым линиям (например, по аналоговым телефонным линиям и ISDN) в качестве либо вызывающего, либо отвечающего маршрутизатора; • маршрутизации с соединением по требованию через VPN-соединения (с использованием РРТР или L2TP поверх IPSec) в качестве либо вызывающего, либо отвечающего маршрутизатора,
Аутентификация и авторизация Знание различий между аутентификацией и авторизацией очень важно для понимания того, как принимается или отклоняется запрос на соединение. • Аутентификация (authentication) — проверка удостоверений при запросе на соединение. Этот процесс включает передачу удостоверений (credentials) от клиента удаленного доступа серверу удаленного доступа в незашифрованном или шифрованном виде с применением какого-либо протокола аутентификации. • Авторизация (authorization) — проверка нрав на установление соединения. Авторизация происходит после успешной аутентификации. Запрос на соединение принимается только после успешной аутентификации и авторизации. Возможна ситуация, R которой запрос на соединение успешно аутен гифицируется благодаря наличию правильных удостоверений, по не проходит авторизацию. В таком случае запрос на соединение отклоняется. Если сервер удаленного доступа сконфигурирован на аутентификации» через Windows, удостоверения и параметры удаленного соединения по данной пользовательской учетной записи проверяет система защиты Windows 2000, а авторизация соединения реализуется за счет локально хранящихся правил политики удаленного доступа- Если запрос на соединение проходит и аутентификацию, и авторизацию, он принимается, и соединение устанавливается. Если сервер удаленного доступа сконфигурирован на аутентификацию через RADIUS, удостоверения передаются на сервер RADIUS для аутентификации и авторизации. Если запрос на соединение проходит аутентификацию и авторизацию, сервер RADIUS посылает серверу удаленного доступа сообщение о приеме запроса, и соединение устанавливается. Если запрос на соединение не проходит аутентификацию или авторизацию, сервер RADIUS посылает серверу удаленного доступа сообщение об отказе, и запрос на соединение отклоняется. Если сервер RADIUS представляет собой компьютер под управлением W i n dows 2000 Server и Internet Authentication Service (IAS) (Служба проверки подлинности в Интернете), аутентификация выполняется сервером IAS через систему защиты Windows 2000, а авторизация — за счет проверки параметров удаленного соединения по данной пользовательской учетной записи и правил политики удаленного доступа, хранящихся на сервере IAS.
26
ЧАСТЬ 1
Маршрутизация
Настройка компонента аутентификации службы маршрутизации и удаленного доступа осуществляется через вкладку Security (Безопасность) окна свойств маршрутизатора удаленного доступа, открываемого из оснастки Routing and Remote Access (Маршрутизация и удаленный доступ), либо командами netsh ras aaaa set authentication и netsh ras aaaa set authserver.
Учет Службу маршрутизации и удаленного доступа можно настроить на регистрацию учетной информации в следующих местах. •
В локально хранящихся файлах журнала при настройке на учет средствами Windows. Конкретное место хранения информации указывается в свойствах папки Remote Access Logging (Ведение журнала удаленного доступа) в окне оснастки Routing and Remote Access (Маршрутизация и удаленный доступ),
• На сервере RADIUS при настройке на учет средствами RADIUS. Если сервер RADIUS является сервером IAS, файлы журнала хранятся на сервере IAS. Конкретное место хранения информации указывается в свойствах папки Remote Access Logging (Ведение журнала удаленного доступа) в окне оснастки Internet Authentication Service (Служба проверки подлинности в Интернете), Настройка компонента учета службы маршрутизации и удаленного доступа осуществляется через вкладку Security (Безопасность) окна свойств маршрутизатора удаленного доступа, открываемого из оснастки Routing and Remote Access, либо командами netsh ras aaaa set accounting и netsh ras aaaa set acctserver.
Установка и конфигурирование В отличие от RRAS для Windows NT -1.0 и большинства сетевых служб Windows 2000 службу маршрутизации и удаленного доступа нельзя установить или удалить через апплет Add/Remove Programs (Установка и удаление программ) в Control Panel (Панель управления). Эта служба автоматически устанавливается в отключенном состоянии. ^ Чтобы включить и настроить службу маршрутизации и удаленного доступа: 1. Запустите компонент Routing and Remote Access (Маршрутизация и удаленный доступ) из папки Administrative Tools (Администрирование). 2. В случае локального компьютера щелкните значок сервера правой кнопкой мыши и выберите команду Configure and Enable Routing and Remote Access (Настроить и включить маршрутизацию и удаленный доступ). В случае удаленного компьютера щелкните правой кнопкой мыши значок Server Status (Состояние сервера) и выберите команду Add Server (Добавление сервера). В диалоговых окнах Add Server (Добавление сервера) выберите сервер, который Вы хотите добавить. 3. Для настройки маршрутизатора удаленного доступа воспользуйтесь Routing and Remote Access Server Setup Wizard (Мастер настройки сервера маршрутизации и удаленного доступа) и укажите требуемые параметры. Эта процедура позволяет включить маршрутизатор удаленного доступа и настроить его в соответствии с параметрами, выбранными в мастере. Для дополнитель-
ГЛАВА 2
Служба маршрутизации и удаленного доступа
27
ной настройки используйте оснастку Routing and Remote Access (Маршрутизация и удаленный доступ).
Изменение конфигурации Удалить службу маршрутизации и удаленного доступа через апплет Add/Remove Programs (Установка и удаление программ) в Control Panel (Панель управления) нельзя, но Вы можете обновить конфигурацию, отключив эту службу, а затем изменив ее конфигурацию. Отключение данной службы влечет за собой удаление из реестра всех параметров, относящихся к маршрутизации и удаленному доступу ^ Чтобы изменить конфигурацию службы маршрутизации и удаленного доступа: 1. Запустите компонент Routing and Remote Access (Маршрутизация и удаленный доступ) из папки Administrative Tools (Администрирование). 2. Для нужного компьютера щелкните значок сервера правой кнопкой мыши и выберите команду Disable Routing and Remote Access (Отключить маршрутизацию и удаленный доступ). 3. Когда появится окно с предупреждением, выберите Yes (Да). 4. Для создания новой конфигурации службы маршрутизации и удаленного доступа используйте процедуру включения и настройки этой службы, описанную в предыдущем разделе. Примечание Если Вы отключите службу маршрутизации и удаленного доступа, все параметры ее текущей конфигурации, в том числе конфигурации протоколов маршрутизации и интерфейсов соединения по требованию (demand-dial interfaces), будут удалены из реестра, а все подключенные в данный момент клиенты — отсоединены.
Функциональность службы маршрутизации и удаленного доступа Служба маршрутизации и удаленного доступа в Windows 2000 включает обширную функциональность для одно- и многоадресной IP-маршрутизации, IPX- и AppleTalk-маршрутизации, удаленного доступа и поддержки VPN.
Поддержка Unicast IP Состоит из следующих функций и компонентов. • Статическая IP-маршрутизация. Эта встроенная функция TCP/IP в W i n dows 2000 позволяет управлять статическими маршрутами через оснастку Routing and Remote Access, не используя утилиту Route. • RIP (Routing Information Protocol) версий 1 и 2. Протокол маршрутизации на основе векторов расстояний, часто применяемый в малых и средних межсетевых IP-средах. • OSPF (Open Shortest Path First). Протокол маршрутизации на основе состояния каналов, обычно применяемый в больших межсетевых IP-средах.
28
ЧАСТЬ 1
Маршрутизация
• DHCP Relay Agent (Агент ретрансляции DHCP). Агент, ретранслирующий сообщения DHCP (Dynamic Host Configuration Protocol) между DHCP-клиентами и DHCP-серверами, которые находятся в разных сегментах сети. •
Транслятор сетевых адресов. Этот компонент обеспечивает трансляцию сетевых адресов при подключении к Интернету сетей, в которых используются частные адреса. • Фильтрация IP-пакетов. Функция, позволяющая указывать, какой трафик принимается и передается по каждому интерфейсу Критерии фильтрации включают IP-адреса отправителя и получателя, номера TCP- и UDP-портов, типы и коды ICMP и номера протоколов IP. • Обнаружение маршрутизаторов средствами ICMP. Функция, которая периодически оповещает об имеющихся маршрутизаторах и отвечает на запросы хостов для поддержки обнаружения маршрутизаторов хостами в сегменте сети с использованием средств 1СМР. Подробнее о поддержке одноадресной IP-маршрутизации см. главу 3 «Одноадресная IP-маршрутизация» в этой книге.
Поддержка IP Multicast Состоит из следующих функций и компонентов. •
Пересылка группового трафика (multicast forwarding). Эта встроенная функция TCP/IP в Windows 2000 позволяет просматривать таблицу пересылки группового трафика (inulticasl forwarding table) с помощью оснастки Routing and Remote Access.
• IGMP (Internet Group Management Protocol) версий 1 и 2. Протокол из набора TCP/IP для учета членства в группах рассылки в подключенных сегментах сети. • Поддержка пересылки и маршрутизации ограниченного группового трафика. Когда Вы используете протокол маршрутизации IGMP и настраиваете интерфейсы для режимов IGMP-маршрутизатора (IGMP router mode) и IGMP-прокси (IGMP proxy mode), маршрутизатор под управлением Windows 2000 может пересылать и маршрутизировать групповой трафик только для специфических конфигураций. • Поддержка ограничителей групповой рассылки. Ограничители групповой рассылки (multicast boundaries) (барьеры, ограничивающие пересылку группового IP-трафика) можно определять на основе адреса группы IP-рассылки, значения поля TTL (Time-To-Live) в IP-заголовке или максимального объема группового трафика (в Кб/с). Подробнее о поддержке групповой IP-рассылки см. главу 4 «Поддержка групповой IP-рассылки» в этой книге.
Поддержка IPX Состоит из следующих функций и компонентов, •
Фильтрация IPX-пакетов. Функция, позволяющая указывать, какой трафик принимается и передается по каждому интерфейсу Критерии фильтрации включают IPX-адреса отправителя и получателя, узел, номера сокетов и тип пакетов.
ГЛАВА 2 •
Служба маршрутизации и удаленного доступа
29
RIP for IPX. Протокол маршрутизации на основе векторов расстояний, часто применяемый в межсетевых IPX-средах. Служба маршрутизации и удаленного доступа позволяет настраивать статические IPX-маршруты и фильтры маршрутов RIP (RIP route filters).
SAP for IPX. SAP (Service Advertising Protocol) — протокол маршрутизации на основе векторов расстояний, обычно применяемый в межсетевых IPX-средах для оповещения о сервисах и их местонахождении. Служба маршрутизации и удаленного доступа позволяет настраивать статические SAP-сервисы и фильтры SAP-сервисов (SAP service filters). • NetBIOS поверх IPX. NetBIOS поверх IPX используется сетевыми компонентами Microsoft для поддержки компонентов доступа к файлам и принтерам в IPX-сетях. Служба маршрутизации и удаленного доступа позволяет пересылать широковещательные пакеты «NetBIOS поверх IPX» и настраивать статические NetBIOS-имена.
•
Подробнее о поддержке IPX-маршрутизации см. главу 5 «IPX-маршрутизация» и этой книге.
AppleTalk AppleTalk подержи нает пересылку Apple Talk-пакетов как маршрутизатор AppleTalk и использование протокола RTMP (Routing Table Maintenance Protocol). Подробнее о маршрутизации AppleTalk см. главу 13 «Services for Macintosh» в этой книге.
Маршрутизация с соединением по требованию IP- и IPX-трафик можно пересылать через интерфейсы с соединением по требованию (demand-dial interfaces) по постоянным или подключаемым по требованию WAN-каналам, Для соединений по требованию служба маршрутизации и удаленного доступа автоматически создает РРР-соединение со сконфигурированной конечной точкой при получении трафика, соответствующего статическому маршруту (см. главу 6 «Маршрутизация с соединением по требованию» в этой книге).
Удаленный доступ Служба маршрутизации и удаленного доступа позволяет превратить компьютер в сервер удаленного доступа, принимающий запросы на соединение от клиентов удаленного доступа, использующих традиционные технологии связи по коммутируемым линиям, например по аналоговым телефонным линиям или ISDN. Более подробную информацию см. в главе 7 «Сервер удаленного доступа» в этой книге.
VPN-сервер Служба маршрутизации и удаленного доступа дает возможность превратить компьютер в сервер виртуальной частной сети (virtual private network, VPN), который поддерживает как РРТР, так и L2TP поверх IPSec, и принимает запросы на VPNсоединения от клиентов удаленного доступа и вызывающих маршрутизаторов. Более подробную информацию см. в главе 9 «Виртуальные частные сети» в этой книге.
30
ЧАСТЬ 1
Маршрутизация
Клиент RADIUS Службу маршрутизации и удаленного доступа можно настроить в качестве клиента RADIUS (Remote Authentication Dial-In User Service) для аутентификации, авторизации и веления учета. Параметры всех запросов на РРР-соединения посылаются сконфигурированному серверу RADIUS для аутентификации и авторизации. Информация о соединениях передается на сконфигурированный сервер RADIUS для учета. Windows 2000 также включает Internet Authentication Service (IAS) (Служба проверки подлинности в Интернете), которая представляет собой реализацию сервера RADIUS. Более подробную информацию см. в главе 8 «Служба проверки подлинности в Интернете» в этой книге.
Поддержка SNMP MIB Windows 2000 и служба маршрутизации и удаленного доступа обеспечивают функциональность агента SNMP (Simple Network Management Protocol) версии 1 с поддержкой Internet MIB II в соответствии с RFC 1213. Для управления маршрутизатором удаленного доступа Windows 2000 можно использовать станции SNMP-ynравления (SNMP management stations). Кроме поддержки Internet MIB II. служба маршрутизации и удаленного доступа предоставляет динамически подключаемые библиотеки (DLL) MIB для: • IP Forwarding Table MIB — объекты в IP Forwarding Table MIB документированы в RFC 1354 «IP Forwarding Table MIB»; • Microsoft RIP 2 for Internet Protocol МГВ; • •
Wel1fleet>Series7-MIB for OSPF; Microsoft BOOTP for Internet Protocol MIB;
• • •
Microsoft IPX MIB; Microsoft RIP and SAP for IPX MIB; Internet Group Management Protocol MIB - объекты в Internet Group Management Protocol MIB документированы в Интернет-проекте «Internet Group Management Protocol MIB»; • IP Multicast Routing MIB — объекты в IP Multicast Routing MIB документированы в Интернет-проекте «IP Multicast Routing MIB».
Всесторонняя поддержка LAN и WAN Служба маршрутизации и удаленного доступа может работать с любыми сетевыми адаптерами, которые поддерживаются Windows 2000 Server, в том числе с WANплатами от компаний Eicon, Cisco, SysKonnect, Allied и US Robotics. Подробнее о поддерживаемых сетевых адаптерах см. ссылку Windows 2000 Hardware Compatibility на http://window5.microsoft.com/windows2000/reskit/webresources.
Утилиты командной строки и с графическим интерфейсом Служба маршрутизации и удаленного доступа включает оснастку Routing and Remote Access (Маршрутизация и удаленный доступ) — административную утилиту Windows 2000, которая позволяет легко просматривать и настраивать локальные или удаленные маршрутизаторы удаленного доступа под управлением W i n -
ГЛАВА 2
Служба маршрутизации и удаленного доступа
31
clows 2000, — а также Netsh.exe, утилиту командной строки, способную выполнять сценарии локальной автоматизированной настройки. Более подробную информацию см. в разделе «Дополнительные средства, поставляемые со службой маршрутизации и удаленного доступа» далее в этой главе.
API-поддержка для компонентов сторонних поставщиков Служба маршрутизации и удаленного доступа предоставляет полностью открытые наборы API для поддержки одно- и многоадресных протоколов маршрутизации, а также для создания административных утилит. Разработчики могут создавать дополнительные протоколы маршрутизации и напрямую включать их в архитектуру службы маршрутизации и удаленного доступа. Кроме того, используя API-функции управления службы маршрутизации и удаленного доступа, можно разрабатывать дополнительные утилиты управления.
Архитектура службы маршрутизации и удаленного доступа Архитектура службы маршрутизации и удаленного доступа показана па рис. 2-1. Агент
Управляющие приложения . .
SNMP.
г Диспетчер динамических интерфейсов ДАЛА
API-функции маршрутизации API-функции управления
IP Вшйг
IPX
Диспетчер соединений {протоколы управления РРР)
Router Manager
Протокбяы одноадресной маршрутизации
Протоколы многоадресной
Route Table Manager ,
Mtdlicast Group Manager
Manager
TAPI • " : | Пользовательский режим
IPфишрация
Компонент пересылки одноадресного iP-трафика
Компонент пересылки группового IP-трафика
|
Компонент пересылки IPX-трафика
IPXфильтрация
Оболочка NDIS Оболочка NDIS WAN Miniport
ШР
РРТР
"AsyneJ
€thernet
Х.25
ISDN
[frame Relay
TR ATM
FDDI X.25...
| |
Рис. 2-1. Архитектура службы маршрутизации и удаленного доступа Примечание Компонент Network Address Translation (NAT) службы маршрутизации и удаленного доступа на рис. 2-1 не показан. NAT не является протоколом маршрутизации. Подробнее о том, как компонент NAT взаимодействует с другими ком-
32
ЧАСТЬ 1
Маршрутизация
шшентами службы маршрутизации и удаленного доступа, а также с TCP/IP, см. главу 3 «Одноадресная IP-маршрутизация» в этой книге.
Агент SNMP Служба маршрутизации и удаленного доступа в Windows 2000 поддерживает SNMP (Simple Network Management Protocol) MIB (Management Information Bases), описанные в разделе «Функциональность службы маршрутизации и удаленного доступа» ранее в этой главе.
Управляющие приложения К управляющим приложениям для службы маршрутизации и удаленного доступа относятся оснастка Routing and Remote Access (Маршрутизация и удаленный доступ), доступная из нанки Administrative Tools (Администрирование), и Netsh, утилита командной строки.
АААА Набор компонентов, обеспечивающих аутентификацию, авторизацию, аудит и учет (authentication, authorization, auditing, accounting — АААА) для службы маршрутизации и удаленного доступа, если она настроена на аутентификацию и учет через Windows. Если же эта служба сконфигурирована на аутентификацию и учет через RADIUS, локальные компоненты АААА не используются. Компоненты АААА также применяются службой IAS.
DIM (Mprdlm.dll) Диспетчер динамических интерфейсов (dynamic interface manager, DIM) — это компонент, который: • поддерживает RFC-интерфейс для функций управления на основе SNMP, используемых такими утилитами управления, как оснастка Routing and Remote Access; • загружает конфигурационную информацию из реестра Windows 2000; • взаимодействует с диспетчером соединений (Connection Manager) при использовании соединений, устанавливаемых но требованию (demand-dial connections); • передает конфигурационную информацию диспетчерам маршрутизаторов (router managers) (например, IP Router Manager и IPX Router Manager); • управляет всеми интерфейсами маршрутизации.
Диспетчер соединений Набор компонентов, который: • управляет WAN -устройствами; • устанавливает соединения с использованием TAPI; • обеспечивает согласование управляющих протоколов РРР, в том числе ЕАР (Extensible Authentication Protocol); •
реализует Multilink (поддержку многоканальных соединений) и ВАР (Bandwidth Allocation Protocol).
ГЛАВА 2
Служба маршрутизации и удаленного доступа
33
TAPI TAPI (Telephony Application Programming Interface), также называемый Telephony API, предоставляет аппаратно-незаштсимые сервисы для установления, мониторинга и завершения соединений. Диспетчер соединений использует TAPI для создания или приема соединений, устанавливаемых но требованию. Подробнее о TAPI см. главу 15 «Интеграция телефонии и поддержка конференций» в этой книге.
IP Router Manager (lprtmgr.dll) Компонент, который: • получает конфигурационную информацию от DIM; • сообщает о конфигурации фильтрации IP-пакетов драйверу IP-фильтрации; • сообщает конфигурационную информацию об IP-маршрутизации компоненту пересылки IP-трафика (IP forwarder) в TCP/IP; • поддерживает базу данных по всем интерфейсам ТР-маршрутизации; • загружает конфигурационную информацию и передает ее протоколам 1Р-ма]ипрутизации (например, RIP for IP и OSPF, поставляемым с Windows 2000); • взаимодействуя с DIM, инициирует устанавливаемые по требованию соединения в интересах протоколов маршрутизации.
IPX Router Manager (lpxrtmgr.dll) Компонент, который: • получает конфигурационную информацию от DIM; • сообщает о конфигурации фильтрации IPX-пакетов драйверу IPX-фильтраш-ш; • сообщает конфигурационную информацию об 1РХ-маршрути;(ации драйверу компонента пересылки IPX-трафика (IPX forwarder driver); • поддерживает базу данных по всем интерфейсам ТРХ-мартпрутизации; • загружает конфигурационную информацию и передает ее протоколам IPX-маршрутизации (например, RIP for IPX, SAP for IPX); • взаимодействуя с DIM, инициирует устанавливаемые по требованию соединения в интересах протоколов маршрутизации.
Протоколы одноадресной маршрутизации Служба маршрутизации и удаленного доступа предоставляет следующие протоколы одноадресной маршрутизации. RIP lor IP (Iprip2.dll)
Компонент, который: •
сообщает Route Table Manager полученные маршруты RIP for IP (RIP for IP learned routes); • использует Windows Sockets для передачи и приема трафика RIP for IP; • экспортирует API-функции управления для поддержки М1В и управляющих приложений через IP Router Manager.
34
ЧАСТЬ 1
Маршрутизация
OSPF (Ospf.dll) Компонент, который: • сообщает Route Table Manager полученные маршруты OSPF; • использует Windows Sockets для передачи и приема трафика OSPF; • экспортирует API-функции управления для поддержки MIB и управляющих приложений через IP Router Manager. RIP for IPX (lpxrip.dll} Компонент, который: • сообщает Route Table Manager полученные маршруты RIP for IPX; • использует Windows Sockets для передачи и приема трафика RIP for IPX; • экспортирует API-функции управления для поддержки MIB и управляющих приложений через IPX Router Manager. SAP lor IPX (lpxsap.dll) Компонент, который: •
сообщает Route Table Manager полученные сервисы SAP for IPX (SAP for IPX learned services);
• •
использует Windows Sockets для передачи и приема трафика SAP for IPX; экспортирует API-функции управления для поддержки MIB и управляющих приложений через IPX Router Manager.
Протоколы групповой IP-рассылки Служба маршрутизации и удаленного доступа предоставляет следующий протокол групповой IP-рассылки (IP multicast protocol). IGMP версий 1 и 2 Компонент, который: • сообщает Multicast Group Manager информацию о членстве в группах рассылки (multicast group membership); • использует Windows Sockets для передачи и приема трафика IGMP; • экспортирует API-функции управления для поддержки М1В и управляющих приложений через Multicast Group Manager.
Route Table Manager (Rtm.dll) Компонент, который: •
поддерживает таблицу маршрутов пользовательского режима (user mode route table) для всех маршрутизируемых протоколов (IP и IPX). Эта таблица включает все маршруты из всех возможных источников маршрутов; • предоставляет API-функции для добавления, удаления и перечисления маршрутов, используемых протоколами маршрутизации; • обеспечивает устаревание полученных маршрутов; •
сообщает только самые эффективные маршруты соответствующему драйверу компонента пересылки. Самыми эффективными являются маршруты с наимень-
ГЛАВА 2
Служба маршрутизации и удаленного доступа
35
шим уровнем предпочтения (lowest preference level) (в случае IP-маршрутов) и наименьшими метриками. Такие маршруты записываются в таблицы IP- и IPXпсрссылки.
Multicast Group Manager Компонент, который: • •
поддерживает членство во всех группах рассылки; сообщает записи пересылки группового трафика (multicast forwarding entries, MFE) в компоненте пересылки группового 1Р-трафика; • отражает членство в группах на все протоколы многоадресной IP-маршрути taции.
Драйвер IP-фильтрации (Ipfltdrv.sys) Компонент, который: • получает конфигурационную информацию от ТР Router Manager; •
применяет IP-фильтры после того, как компонент пересылки IP-трафика находит какой-либо маршрут.
Компонент пересылки одноадресного IP-трафика Компонент TCP/IP (Tcpip.sys), который: • •
получает конфигурационную информацию от IP Router Manager; хранит таблицу IP-пересылки — таблицу е наиболее эффективными маршрутами, полученными от Route Table Manager;
• может инициировать соединения, устанавливаемые по требованию; • пересылает одноадресный 1Р-трафик.
Компонент пересылки группового IP-трафика Компонент TCP/IP (Tcpip.sys), который: • хранит записи пересылки группового трафика (MFE), полученные от протоколов многоадресной 1Р-маршрути;1ации через Multicast Group Manager; • на основе принимаемого многоадресного трафика сообщает Multicast. Group Manager новую информацию в виде [источник, группа]; • пересылает пакеты групповой IP-рассылки.
Драйвер IPX-фильтрации (Nwlnkfltsys) Компонент, который: • получает конфигурационную информацию от IPX Router Manager; • применяет IPX-фильтры после того, как драйвер компонента пересылки IPXтрафика находит какой-либо маршрут.
Драйвер компонента пересылки IPX-трафика (Nwlnkfwd.sys) Компонент, который: •
получает конфигурационную информацию от IPX Router Manager;
36
ЧАСТЬ 1
Маршрутизация
•
хранит таблицу IPX-пересылки — таблицу с наиболее эффективными маршрутами, полученными от Route Table Manager; • может инициировать соединения, устанавливаемые по требовании); • пересылает IPX-трафик,
Компоненты и процессы поддержки одноадресной IP-маршрутизации Компоненты одноадресной IP-маршрутизации службы маршрутизации и удаленного доступа представлены на рис. 2-2. В следующих подразделах типичные процессы одноадресной IP-маршрутизации рассматриваются в терминах соответствующих компонентов службы маршрутизации и удаленного доступа, Оснастка Routing
Команда Metsh
and
Remote Access
Диспетчер динамических интерфейсов
нп-функции маршрутизации . . .
API-функции управления
05Й1
Диспетчер соединений (протоколы управления РРР)
Route Tabte Manager
TAPI Попьзоватвльский режим Режим ядра TCFVfP
|Р-фш1ьтрация NDIS
Компонент пересылки одноадресного S 1Р-траф«ка Оболочка NDIS
Оболочка NDIS WAN Miniport j
L2TP
!
PPTP
I]
ftsync
j
X.25
ISDN
Ethernet
т
j Frame Relay 1
ATM
FDOI X.21..
|
Рис. 2-2. Одноадресная IP-маршрутизация и служба маршрутизации и удаленного доступа Входящий-исходящий пакет (транзитный трафик) Входящий пакет сначала передается компоненту пересылки IP-трафика (IP forwarder), который находит маршрут, а затем передает пакет драйверу IP-фильтрации для проверки входными и выходными фильтрами. Если входные фильтры разрешают прием пакета, а выходные — его пересылку, пакет возвращается драйверу компонента пересилки IP-трафика, который пересылает его по подходящему ин-
ГЛАВА 2
Служба маршрутизации и удаленного доступа
37
тсрфейсу, используя NDIS (Network Driver Interlace Specification). Если входные или выходные фильтры не разрешают пересылку пакета, он «молча» отбрасывается. Если маршрут не найден, источнику пакета возвращается ICMP-сообщение Destination Unreachable/Host Unreachable. (Описание ICMP-сообщений см. в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server».) Входящий пакет (локальный трафик хоста) Входящий пакет сначала передается компоненту пересылки ТР-трафика, который отмечает, что данный пакет не подлежит маршрутизации (IP-адрес получателя соответствует адресу широковещательной рассылки, либо получателем является маршрутизатор). Тогда компонент пересылки IP-трафика передает этот пакет драйверу IP-фильтрации для проверки входными фильтрами. Если входные фильтры разрешают прием пакета, он передается драйверу TCP/IP, который обрабатывает этот пакет. Если входные фильтры не разрешают прием пакета, он «молча» отбрасывается. Исходящий пакет (локальный трафик хоста) Исходящий TCP/IP-пакет передается драйвером TCP/IP драйверу IP-фильтрации, который проверяет его выходными фильтрами. Если выходные фильтры разрешают передачу пакета, он направляется компоненту пересылки IP-трафика, который посылает его по наиболее эффективному маршруту через подходящий интерфейс, используя NDIS. Если выходные фильтры не разрешают передачу пакета, он «молча» отбрасывается. Если маршрут не найден, приложению — источнику пакета сообщается об ошибке IP-маршрутизации. Работа протоколов маршрутизации в сети Протоколы маршрутизации RIP for IP и OSPF работают точно так же, как и любые другие приложения Windows Sockets, передающие и принимающие IP-пакеты. Обновления таблицы маршрутизации RIP for IP и OSPF обновляют маршруты в Route Table Manager. Таблица самых эффективных маршрутов в компоненте пересылки IP-трафика обновляется с учетом наилучшего маршрута и ранга источника маршрута (route source ranking).
Компоненты и процессы поддержки многоадресной IP-маршрутизации Компоненты многоадресной IP-маршрутизации службы маршрутизации и удаленного доступа представлены па рис. 2-3. В следующих подразделах типичные процессы многоадресной IP-маршрутизации рассматриваются в терминах соответствующих компонентов службы маршрутизации и удаленного доступа. Входящий групповой пакет (в отсутствие MFE) Адрес источника входящего группового IP-пакета и адрес группы сравниваются с MFE-записями в таблице пересылки группового ТР-трафика. Если записи [источник, группа] нет, в таблицу пересылки добавляется неактивная MFE для [источник, группа] и сообщается компоненту Multicast Group Manager. Пакет помешается в буфер на время ожидания активизации MFE.
38
ЧАСТЬ 1
Маршрутизация
Оснастка Routing . Команда and Netsh Remote Access Диспетчер , динамических интерфейсов
API-функции управления
IGMP
Диспетчер соединений (йратоколы управления РРР)
АААА
Route Table Manager
WticastBraap Manager
|
ТАР!
Пользовательский режим Режим ядра
ТСРЛР IP-фильтрация
NDIS
Компонент перееыяю* . многоадресного IP-трафика Оболочка NDIS
L2TR
РРТР
1
ftsync
ra
Ethernet
Оболочка NDIS WAN Miniport
Х.25
ISDN |
Frame Relay
!
ATM
FODI
X.25.,.
Рис. 2-3. Многоадресная IP-маршрутизация и служба маршрутизации и удаленного доступа Входящий групповой пакет (при наличии активной MFE) Адрес источника входящего группового IP-пакета и адрес группы сравниваются с MFE-записями в таблице пересылки группового IP-трафика. Если активная запись для [источник, группа] найдена, групповой трафик пересылается по нужному интерфейсу или интерфейсам. Работа протоколов многоадресной маршрутизации в сети Протокол многоадресной маршрутизации IGMP v2 работает точно так же, как и другие приложения Windows Sockets, передающие и принимающие IP-пакеты. Обновления таблицы многоадресной маршрутизации Протокол многоадресной маршрутизации IGMP v2 обновляет записи [источник, группа] в Multicast Group Manager на основе IGMP-трафика, поступающего на те интерфейсы, которые работают в режиме маршрутизатора IGMP. После этого Multicast Group Manager вносит изменения в таблицу пересылки группового IPграфика.
Компоненты и процессы IPX-маршрутизации Компоненты IPX службы маршрутизации и удаленного доступа представлены на рис. 2-4.
ГЛАВА 2 Оснастка Routing and Remote Access
Команда Welsh
Диспетчер динамических интерфейсов
;
Служба маршрутизации и удаленного доступа
39
API-функции маршрутизации API-функции управления
SAP for IPX
RIP for IPX
Диспетчер соединений (протоколы управления IW)
Route Table Manager
ТАР!
Пользовательский режим Режим ядра «>ХУ5РХ
IPX-фмйьтрамия 1
NDIS
Компонент тюрееьши 1РХ-трафйка
Оболочка NOIS Оболочка NDIS WAN Miniport • L2TP
• РГТР
1 Async
Х.25
ISDN
Ethernet
TR
Frame Retay
КПП
FODi X.25...
Рис. 2-4. IPX-маршрутизация и служба маршрутизации и удаленного доступа В следующих подразделах типичные процессы IPX-маршрутизации рассматриваются в терминах соответствующих компонентов службы маршрутизации и удаленного доступа. Входящий-исходящий пакет (транзитный трафик) Входящий пакет сначала передастся драйверу компонента пересылки IPX-трафика (IPX forwarder driver), который находит маршрут, а затем передает пакет драйверу IPX-фильтрации для проверки сходными и выходными фильтрами. Если входные фильтры разрешают прием пакета, а выходные — его пересылку, пакет возвращается драйверу компонента пересылки IPX-трафика, который пересылает его по подходящему интерфейсу, используя NDIS. Если входные или выходные фильтры не разрешают пересылку пакета, он «молча» отбрасывается. Входящий пакет (локальный трафик хоста) Входящий пакет сначала передается драйверу компонента пересылки IPX-трафика, который отмечает, что данный пакет не подлежит маршрутизации (IPX-адрес получателя соответствует адресу широковещательной рассылки, либо получателем является маршрутизатор), и передает его драйверу IPX-фильтрации для проверки входными фильтрами. Если входные фильтры разрешают прием пакета, он передается драйверу IPX/SPX, который обрабатывает этот пакет обычным образом. Если входные фильтры не разрешают прием пакета, он «молча» отбрасывается.
40
ЧАСТЬ 1
Маршрутизация
Исходящий пакет (локальный трафик хоста) Исходящий ТРХ-пакст передается драйвером IPX/SPX драйверу IPX-фильтрации, который проверяет его выходными фильтрами. Если выходные фильтры разрешают передачу пакета, он направляется драйверу компонента пересылки IPX-трафика, который посылает его по наиболее эффективному маршруту через подходящий интерфейс, используя NDTS. Если выходные фильтры не разрешают передачу пакета, он «молча» отбрасывается. Если маршрут не найден, посылается RIP-сообщение GetLocalTarget. Подробнее о процессах IPX-маршрутизации см. главу 5 «IPXмаршрутизация» в этой книге. Работа протоколов маршрутизации в сети Протоколы маршрутизации RIP for IPX и SAP работают точно так же, как и любые другие приложения Windows Sockets, передающие и принимающие IPX-пакеты. Обновления таблицы маршрутизации RTP for IPX и SAP обновляют маршруты в Route Table Manager. Таблица самых эффективных маршрутов в драйвере компонента пересылки IPX-трафика обновляется с учетом наилучшего маршрута и принимаемой информации,
Настройки в реестре При включении службы маршрутизации и удаленного доступа в реестре W i n dows 2000 создаются и поддерживаются соответствующие настройки. Для большего быстродействия основная часть конфигурационной информации этой службы хранится в двоичной форме крупными блоками, а не отдельными записями, которые можно было бы легко просмотреть и изменить. Поэтому настройка службы маршрутизации и удаленного доступа осуществляется исключительно через оснастку Routing and Remote Access (Маршрутизация и удаленный доступ) или утилитой Netsh, которая будет детально рассмотрена чуть позже. Конфигурационная информация об интерфейсах маршрутизатора и службе маршрутизации и удаленного доступа хранится в разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess. Конфигурационная информация о компонентах маршрутизатора хранится в разделе реестра HKEY_LOCAL_MACHINE\Sortware\Microsoft\Router. Настройки телефонной книги маршрутизатора хранятся в разделе реестра HKEY_ LOCAL_MACHINE\Software\Microsoft\RouterPhonebook.
Дополнительные средства, поставляемые со службой маршрутизации и удаленного доступа Для упрощения настройки и сбора информации для учета, аудита или диагностики служба маршрутизации и удаленного доступа предоставляет ряд дополнительных средств: • оснастку Routing and Remote Access (Маршрутизация и удаленный доступ); • утилиту Netsh (командной строки); • средства записи аутентификационной и учетной информации; • средства регистрации событий; • средства трассировки.
ГЛАВА 2
Служба маршрутизации и удаленного доступа
41
Оснастка Routing and Remote Access Оснастка Routing and Remote Access (Маршрутизация и удаленный доступ) запускается ин папки Administrative Tools (Администрирование) и является основным инструментом настройки локальных и удаленных серверов доступа и маршрутизаторов в Windows 2000 Server.
Плавающие окна оснастки Routing and Remote Access В этой оснастке можно открыть целый набор плавающих окоп, отображающих статистику или записи в таблицах. Плавающее окно можно переместить в любое место и оставить его поверх окна оснастки, если она является активным приложением. Список плавающих окон оснастки Routing and Remote Access приведен в таблице 2-1. Таблица 2-1. Плавающие окна оснастки Routing and Remote Access Плавающее окно
Местонахождение
Описание
TCP/IP information (Сведения о TCP/IP)
IP Routing/General (IP-маршрутизация/Общие) IP Routing/General/ Interface (IP-маршрутизация/Обшие/Интерфейс) IP Routing/General
Глобальная статистика TCP/IP, например количество маршруток, число принятых и перенаправл е н н ы х пакетов
IP Routing/General
Статистика по каждой группе, например число принятых групповых пакетом Содержимое кэша A R P (Address Resolution Protocol)
Multicast forwarding cable (Таблица многоадресного перенаправления) Multicast statistics (Статистика многоадресной области) Address translations (Преобразование IP-адресов) IP addresses (IP-адреса) IP routing table (Таблица маршрутизации IP)
TCP connections (Подключения TCP) L'DP listener ports (Порты UDP) Areas (Области OSPF) Link state database (OSPF - база данных состояния связи) Neighbors (OSPF) (Соседи OSPF)
IP Routing/General/ Interface
Содержимое таблицы пересылки группового ТСР/1Р-трафика
IP Routing/General/ Interface IP Routing/General/ Interface IP Routing/Static Routes (IP-маршрутизация/ Статические март] футы) IP Routing/General/ Interface
IP-адреса, назначенные интерфейсам маршрутизации Содержимое табл нцы IP-маршрутизации
IP Routing/OSPF
Список соседних OSPF-маршрутизаторов и их состояние
Список TCP-соединений, в том числе локальных и удаленных адресов и TCP-портов Список UDP-портов, прослушинаIP Routing/General/ Interface емых маршрутизатором Список сконфигурированных IP Roiiting/OSPF (1Р-маршрутизация/О8РР) областей OSPF Содержимое базы данных IP Routing/OSPF состояния каналов
(см. след, стр.)
42
ЧАСТЬ 1
Таблица 2-1.
Маршрутизация (продолжение,)
Плавающее окно
Местонахождение
Описание
Список сконфигурированных виртуальных интерфейсов и их состояние IP Routing/RIP Список соседних (I Р-мартрутизация/RIP) RIP-маршрутизаторов IP Routing/Network Статистика но количеству типов Address Translation отправленных и полученных (IP-маршрутизация/КАТ - DHCP-сообщепий преобразование сетевых адресов) DNS Proxy information IP Routing/Network Статистика по количеству типов отправленных и полученных (Сведения о DNS-прокси) Address Translation DNS-сообщений IP Routing/Network Add- Содержимое таблицы Mappings [Таблица сопоставления сеанса ress Translation/Interface сопоставлений NAT преобразования сетевых (IP-маршрутизация/NAT преобразование сетевых адресов (NAT)] адресов/Интерфейс) IP Routing/IGMP Group table Глобальный список групп, обнару(Таблица IGMP-групп) (1Р-мар)1Грутн.г1ация/'1СМР) женных с применением протокола маршрутизации IGMP Interface group table IP Routing/IGMP/Interface Действительный для данного (Таблица интерфейса (IP-маршрутизация/ЮМР/ интерфейса список групп, обнаруИнтерфейс) IGMP-группы) женных с применением протокола маршрутизации IGMP IPX parameters IPX Routing/General Глобальная статистика IPX, напри(Глобальные параметры мер количество маршрутов и служб, (IPX-маршрутизация/ число принятых и перенаправленIPX) Общие) ных пакетов IPX routing table IPX Routing/General Содержимое таблицы (Таблица IPX-маршру(IPX-маршрутизация/ IPX-маршрутизации тизации) Общие) IPX Ron ting/Static Routes (IPX-маршрутизация/ Статические маршруты) IPX service table IPX Routing/General Содержимое таблицы служб SAP (Таблица служб IPX) IPX Routing/Static Services (IPX-маршрутизация/ Статические службы) RIP parameters IPX Routing/RIP for IPX Глобальная статистика (Глобальные параметры (IPX-маршрутизация/RIP по протоколу RIP for IPX IPX для RIP)* для IPX) SAP parameters IPX Routing/SAP for IPX Глобальная статистика (Глобальные параметры (IPX-маршрутизация/SAP по протоколу SAP for IPX IPX для SAP) для IPX) Virtual interfaces (Виртуальные интерфейсы OSPF) Neighbors (RIP) (Соседи RIP) DHCP Allocator information (Сведения DHCP-распределителя)
IP Routing/OSPF
Несмотря на такое название этого окна л русской версии Windows 2000 Server, речь идет, конечно же, о параметрах RIP for IPX. To же относится и к параметрам SAP for IPX (см, следующую строку в таблице). — Прим. персе.
ГЛАВА 2 Служба маршрутизации и удаленного доступа
43
Утилита Netsh Netsh — это утилита командной строки и средство выполнения сценариев для сетевых компонентов Windows 2000 как на локальных, так и на удаленных компьютерах. Она также позволяет сохранять сценарий конфигурирования в виде текстового файла для архивных целей или для настройки других серверов. Netsh представляет собой оболочку, способную поддерживать множество сетевых компонентов Windows 2000 за счет добавления вспомогательных DLL. Такие DLL расширяют функциональность Netsh, предоставляя дополнительные команды для мониторинга или настройки конкретных сетевых компонентов Windows 2000. Каждая вспомогательная DLL предоставляет контекст — группу команд для определенного сетевого компонента. Внутри каждого контекста могут существовать подконтексты. Например, в контексте routing существуют подконтексты ip и ipx, группирующие команды для IP- и IPX-маршрутизации соответственно. Ниже кратко описываются параметры командной строки Netsh. а файл_псевдонимов
Заставляет использовать указанный файл псевдонимов (alias file). Файл псевдонимов содержит список команд Netsh и их псевдонимов, что позволяет переименовать команды Netsh так, как Вам удобнее. Файлы псевдонимов полезны для сопоставления команд Netsh и эквивалентных команд, более привычных на других платформах. -с контекст Определяет контекст команды, который соответствует установленной вспомогательной DLL. команда Задает команду Netsh, которую нужно выполнить. -/ файл.сценария Заставляет выполнять все команды Netsh в указанном файле сценария. -/•имя_или_1Р-адрес_удаленного_компьютера Заставляет выполнять команды Netsh на удаленном компьютере, указанном по имени или IP-адресу. Названия команд можно сокращать до таких аббревиатур, которые не вызывают неоднозначности. Например, команда го ip sh int эквивалентна команде routing ip show interface. Команды Netsh могут быть либо глобальными, либо контекстными. Глобальные команды действуют в любом контексте и используются для выполнения универсальных функций Netsh. Контекстные команды зависят от конкретного контекста. Список глобальных команд Netsh приведен в таблице 2-2. Netsh поддерживает два режима работы. •
Интерактивный (online). В этом режиме команды, вводимые в командной строке Netsh, выполняются немедленно. • Автономный (offline). В этом режиме команды, вводимые в командной строке Netsh, аккумулируются и выполняются пакетом после ввода глобальной коман-
44
ЧАСТЬ 1
Маршрутизация
ды commit. Аккумулированные команды можно отбросить, введя глобальную команду flush. Таблица 2-2. Глобальные команды Netsh Команда ? или help add helper delete helper show helper online offline set mode show mode flush commit show machine exec quit, или bye, или exit add alias delete alias show alias dump popd pushd
Описание Перемещает на один уровень контекста вверх Выводит краткую справочную информацию Добавляет вспомогательную DLL Удаляет вспомогательную DLL Перечисляет установленные вспомогательные DLL Устанавливает интерактивный режим как текущий Устанавливает автономный режим как текущий Устанавливает интерактивный или автономный режим как текущий Показывает текущий режим Отбрасывает любые изменения, внесенные в автономном режиме Фиксирует изменения, внесенные в автономном режиме Показывает, на каком компьютере выполняются команды Netsh Выполняет файл сценария с командами Netsh Завершает работу Netsh Добавляет псевдоним существующей команды Удаляет псевдоним существующей команды Показывает все псевдонимы Записывает настройки Команда, применяемая в сценариях для выталкивания контекста из стека Команда, применяемая в сценариях для заталкивания текущего контекста
Вы также можете запускать сценарии (сценарий — это текстовый файл со списком команд Netsh), используя либо параметр -f, либо глобальную команду exec в командной оболочке Netsh. Чтобы создать сценарий, устанавливающий текущую конфигурацию, используйте глобальную команду dump. Она генерирует описание текущей конфигурации в виде команд Netsh. Впоследствии Вы сможете использовать этот сценарий для конфигурирования нового сервера или для перенастройки существующего. При внесении множества изменений в конфигурацию какого-либо компонента рекомендуется начать сеанс настройки с выполнения команды dump на тот случай, если понадобится восстановить исходную конфигурацию этого компонента. Для службы маршрутизации и удаленного доступа Netsh поддерживает следующие контексты.
газ Позволяет использовать команды и контексте ras для настройки конфигурации удаленного доступа.
ГЛАВА 2
Служба маршрутизации и удаленного доступа
45
аааа Позволяет использовать команды в контексте аааа для настройки компонента А А А А , применяемого как службой маршрутизации и удаленного доступа, так и Internet Authentication Service (Служба проверки подлинности в Интернете).
routing Позволяет использовать команды в контексте routing для настройки ТР- и 1РХ-маршрутизации.
interface Позволяет использовать команды в контексте interface для настройки интерфейсов соединений по требованию. Подробнее о контекстных командах см. справочную систему Windows 2000 Server и справочную информацию, встроенную в утилиту \etsh,
Запись аутентификационной и учетной информации Если Вы выбрали аутентификацию или учет черен Windows, служба маршрутизации и удаленного доступа может регистрировать аутентификационную и учетную информацию для запросов на соединения на основе РРР. Соответствующие журналы ведутся отдельно от системных журналов. Эта информация позволяет отслеживать попытки аутентификации и использование сетевых ресурсов клиентами удаленного доступа. Она особенно полезна при устранении каких-либо проблем с удаленным доступом. Аутентификационная и учетная информация хранится в файле или файлах журнала в папке %5z/stemfioot%\System32\LogFiles. Эти файлы записываются в формате Internet Authentication Service (IAS) 1.0 или баз данных ODBC (в последнем случае любая программа, работающая с базами данных, может напрямую считывать файл журанала для последующего анализа). Вы можете указывать типы регистрируемой активности (использование удаленного доступа или операции, связанные с аутентификацией) и настраивать параметры файлов журнала через свойства папки Remote Access Logging (Ведение журнала удаленного доступа) в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ). Если маршрутизатор удаленного доступа настроен па аутентификацию или у ют через RADIUS и сервером R A D I U S является компьютер под управлением W i n dows 2000 и Internet Authentication Service (Служба проверки подлинности в Интернете), та же информация регистрируется и на компьютере — сервере IAS.
Регистрация событий Маршрутизатор Windows 2000 регистрирует все ошибки в системном журнале событий. Вы можете использовать эту информацию при устранении проблем с маршрутизацией или удаленным доступом. Поддерживается четыре уровня регистрации. 1. Запись только ошибок (по умолчанию). 2. Запись ошибок и предупреждений.
46
ЧАСТЬ 1
Маршрутизация
3. Запись максимального объема информации. 4. Запись событий отключена. Например, если OSPF-маршрутизатор не может установить соседство на интерфейсе, можно выполнить следующие действия. 1. Отключить протокол OSPF на интерфейсе. 2. Изменить уровень регистрации для OSPF на запись максимального объема информации. 3. Включить протокол OSPF на интерфейсе, \. Проанализировать в системном журнале событий информацию о процессе установления соседства OSPF (OSPF adjacency process). 5. Изменить уровень регистрации для OSPF на запись только ошибок. Затем, чтобы выявить источник проблемы с установлением соседства, просмотрите записи журнала событий, относящиеся к протоколу OSPF. Установить уровень регистрации можно с вкладок General (Общие) в следующих окнах свойств: • IP Routing (Маршрутизация IP)\GeneraI (Общие); • IP Routing\Network Address Translation Properties (NAT - преобразование сетевых адресов); • IP Routing\RIP (RIP);
• IP RoutingXOSPF (OSPF); • IP Routing\IGMP (IGMP); • IPX Routing (Маршрутизация IPX)\General (Общие); • IPX Routing\RIP for IPX (RIP для IPX); • IPX Routing\SAP for IPX (SAP для IPX). Регистрация требует значительных системных ресурсов, и ее следует применять лишь при выявлении и устранении проблем с сетями. После записи события или обнаружения причины проблем следует немедленно восстановить изначальный уровень регистрации (запись только ошибок). В случае записи максимального объема информации получаемые данные могут оказаться сложными и очень детальными. Часть их полезна только инженерам службы технической поддержки Microsoft или сетевым администраторам, имеющим большой опыт работы со службой маршрутизации и удаленного доступа.
Трассировка Служба маршрутизации и удаленного доступа Windows 2000 обладает богатыми возможностями трассировки, весьма полезными при устранении сложных проблем в сетях. Средства трассировки записывают значения переменных внутренних компонентов, а также регистрируют вызовы функций и любое взаимодействие между компонентами. Трассировочную информацию можно записывать в файлы, причем отдельно для компонентов маршрутизации и отдельно для компонентов удаленного доступа. Чтобы включить трассировку, нужно изменить настройки в реестре Windows 2000.
ГЛАВА 2
Служба маршрутизации и удаленного доступа
47
Внимание Не модифицируйте реестр самостоятельно (с помощью редактора реестра) — делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также тех, которые могут снизить быстродействие системы или привести к ее краху. Пряное редактирование реестра может повлечь за собой непредсказуемые последствия, и Вам придется переустанавливать Windows 2000. Для настройки и конфигурирования Windows 2000 по возможности используйте Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft). Трассировку можно включить для каждого протокола маршрутизации по отдельности, изменяя параметры реестра, показанные ниже. Трассировку для протоколов маршрутизации можно включать и выключать в процессе работы маршрутизатора. Каждый установленный протокол или компонент маршрутизации поддерживает трассировку, и для него создается одноименный подраздел в разделе, ОТНОСЯЩЕМСЯ к трассировке, например OSPF или RIPV2. Трассировка требует значительных системных ресурсов, и ее следует применять лишь при выявлении и устранении проблем с сетями. После записи трассировочной информации или обнаружения причины проблем трассировку следует немедленно отключить. Трассировочная информация может оказаться сложной и очень детальной. Часть ее полезна только инженерам службы технической поддержки Microsoft или сетевым администраторам, имеющим большой опыт работы со службой маршрутизации и удаленного доступа.
Запись трассировочной информации в файлы Чтобы разрешить запись трассировочной информации в файл (file tracing) для конкретного компонента (обозначаемого ниже как Компонент), Вы должны присвоить значение 1 параметру EnableFileTracing в разделе реестра HKEYJJ3CAL МАCmNE\SYSTEM\SOFTWARE\Microsoft\Tracing\Ao^moHewm. По умолчанию его значение равно 0. Местонахождение файла трассировки для конкретного компонента указывается как путь в параметре FileDirectory в разделе реестра HKEY_LOCALJV1ACH1NE\SYSTEM\SOFTWARE\Microsoft\Tracmg\/fojwnoHeHm. Имя файла формируется из имени компонента, для которого включена трассировка. По умолчанию все файлы трассировки помещаются в каталог %SystemRoot.%\Trac\ng. Для задания уровня трассировки (индивидуально для каждого компонента) нужно присвоить требуемое значение параметру FileTracingMask в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\SOFTWARE\Microsoft\Tracing\/Co^noKeHm. Уровень трассировки можно изменять от 0 до OxFFFFOOOO. По умолчанию он равен OxFFFFOOOO. что соответствует максимальному объему трассировочной информации. Чтобы указать максимальный размер файла трассировки, присвоите нужное значение параметру MaxFileSize в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\SOFTWARE\Microsoft\TracmgVCo^«OHeHm. По умолчанию параметр МахFileSlze содержит значение 10000, что соответствует 64 Кб.
50
ЧАСТЬ 1
Маршрутизация
тором Windows 2000 — он может быть реализован сторонними поставщиками программного обеспечения. Подробнее об API для поддержки сторонних протоколов маршрутизации см. Windows 2000 Software Development Kit (SDK).
Уровни предпочтений При наличии нескольких источников информации о маршрутах возникает необходимость в определении того, маршруты каких источников аффективнее но сравнению с маршрутами других источников. Например, если происходит обмен информацией о маршрутах между RIP- и OSPF-частями интрасети, нужно учитывать, что определения метрик в RIP и OSPF различаются. Вместо того чтобы синхронизировать метрики для двух маршрутов к одной и той же сети из двух источников, используется маршрут, полученный из более предпочтительного источника, а маршрут из менее предпочтительного — игнорируется (независимо от его метрики). Так, если маршрутизатор сконфигурирован на использование и RIP, и OSPF, в таблицу IP-маршрутизации Route Table Manager (RTM) добавляются маршруты, полученные как от RIP, так и от OSPF. Если метрика OSPF-маршрута равна 5, а метрика эквивалентного RlP-маршрута — 3 и если OSPF является предпочтительным протоколом маршрутизации, то RTM добавляет в таблицу IP-пересылки именно OSPF-маршрут. Уровни предпочтений для источников маршрутов настраиваются на вкладке Preference Levels (Уровни предпочтений) в окне свойств, которое открывается из контейнера IP Routing\General (1Р-маршрутизация\Общие) в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ). Вкладка Preference Levels позволяет указывать уровни предпочтений для всех маршрутов из определенного источника. А чтобы задать уровень предпочтения для статического маршрута, используйте команду netsh routing ip add rtmroute.
RIP for IP RIP for IP — это протокол маршрутизации на основе векторов расстояний (distance vector routing protocol), который упрощает обмен информацией об IP-маршрутизации. Как и RIP for IPX, RIP for IP разработан на базе XNS-версии (Xerox Network Services) RIP. Благодаря включению в Berkeley UNIX (BSD версий 4.2 и выше) в качестве демона маршрутизируемого сервера (routed server daemon) RIP стал очень популярным протоколом маршрутизации. (Демон в UNIX аналогичен службе в Windows 2000.) Существует две версии RIP: первая (vl) определена в RFC 1058, вторая (v2) — в RFC 1723. Информация, представленная в этой главе, относится к RIP for IP обоих версий. Также поясняются различия между RIP vl и RIP v2.
RIP и большие межсетевые среды Хотя RIP for IP прост в реализации и широко поддерживается в компьютерной индустрии, ему присущ ряд недостатков, связанных с тем, что изначально он был разработан для локальных сетей. Из-за этих недостатков RIP приемлем только в малых или средних по размеру межсетевых IP-средах. RIP и число переходов RIP использует число переходов как метрику для маршрута, хранящегося в таблице IP-маршрутизации. Число переходов — это количество маршрутизаторов на пути
ГЛАВА 3
Одноадресная IP-маршрутизация
51
к нужной сети. RIP допускает максимум 15 переходов, так что при его использовании между любыми двумя хостами не может быть более 15 маршрутизаторов. Сети, отдаленные на 16 и более переходов, считаются недостижимыми. Число переходов RIP не зависит от поля TTL (Time-to-Live) в IP-заголовке. Сеть, отдаленная на 16 переходов, вполне доступна для IP-пакета с соответствующим значением TTL, по для RIP-маршрутизатора такая сеть недостижима, и любая попытка переслать пакет хосту в этой сети заставит RIP-маршрутизатор вернуть ICMP-сообщепие Destination Unreachable/Network Unreachable. RIP и записи в таблице маршрутизации R1P допускает наличие в таблице маршрутизации нескольких записей для одной сети, если к пей ведет несколько маршрутов. Процесс IP-маршрутизации считает наиболее эффективным маршрут с наименьшей метрикой (минимальным числом переходов). Однако в типичных реализациях маршрутизатора RIP for IP, включая Windows 2000, для каждой сети хранится лишь по одному маршруту с наименьшей метрикой. Если RIP получает несколько маршрутов с наименьшей метрикой, (in выбирает первый из них, а остальные отбрасывает. Если же RIP-маршрутизатор хранит полный список всех сетей и все возможные пути к каждой из них, в большой межсетевой IP-среде со множеством маршрутов в таблице маршрутизации могут присутствовать сотни или даже тысячи записей. Поскольку в одном RIP-пакете можно переслать лишь 25 маршрутов, большие таблицы маршрутизации передаются несколькими RIP-пакетами. Оповещения о маршрутах RIP-маршрутизаторы сообщают о содержимом своих таблиц маршрутизации каждые 30 секунд и посылают соответствующие оповещения во все подключенные сети через широковещательный IP-адрес IP-подсети и широковещание МАС-уровнл. (Маршрутизаторы RIP v2 можно настроить на групповые RIP-оповещения.) Из-за этого в крупных межсетевых IP-средах с большими таблицами маршрутизации генерируется большой объем широковещательного RIP-трафика, что может быть особенно проблематично в WAN-каналах, чья основная часть полосы пропускания была бы занята RIP-трафиком. Поэтому маршрутизация на основе RIP не годится для крупных межсетевых сред или сред, включающих WAN-каналы. Конвергенция в SIP По умолчанию срок действия каждой записи таблицы маршрутизации, полученной через RIP, истекает через 3 минуты после того времени, когда было принято последнее оповещение от соседнего RIP-маршрутизатора. Если какой-нибудь маршрутизатор отключается из-за сбоя, на распространение информации об изменении топологии межсетевой среды может уйти несколько минут. Таким образом, конвергенция в RIP проходит довольно медленно.
Конвергенция в межсетевых средах, использующих RIP RIP for TP, как и большинство протоколов маршрутизации на основе векторов расстояний, оповещает о маршрутах без синхронизации и приема подтверждений. Эти может вызывать проблемы с конвергенцией. Однако Вы можете изменять алгорш мы оповещения, что, как правило, позволяет ускорить конвергенцию.
52
Маршрутизация
ЧАСТЬ 1
Проблема счета до бесконечности Проблема счета до бесконечности (count-to-infinity problem) — классическая проблема конвергенции при использовании векторов расстояний и прямой результат схемы асинхронных оповещений. Когда маршрутизаторы RIP for IP добавляют маршруты в свои таблицы маршрутизации на основе маршрутов, объявленных другими маршрутизаторами, они сохраняют в таблицах лишь самый эффективный маршрут. При этом они заменяют маршрут с меньшей ценой использования на маршрут с большей ценой, только если последний объявляется тем же источником как маршрут, который в данный момент имеет меньшую цену использования. В определенных ситуациях (см. иллюстрации на рис. 3-1, 3-2, 3-3, 3-4 и 3-5) это приводит к так называемому счету до бесконечности. Допустим, что межсетевая среда, изображенная на рис. 3-1, находится в состоянии конвергенции. Для упрощения исключим из рассмотрения оповещения, рассылаемые маршрутизатором 1 в сети 1 и маршрутизатором 2 в сети 3. Сеть1
""Щ Маршрутизатор 1
Сеть I 2
: з
^^J*
Оповещение
Ceib 1 ; 1 переход Сеть 3 ; 2 перехода
Сеть 2 Оповещение Сеть 3 : 1 переход ^'^Г^Чб Сеть 1 : 2 перехода
Число переходов
1 Г ; 2
Xх" I ,
Сеть 3
Маршрутизатор 2 Сеть Число переходов 1 2
:' 3
2 1 1
Рис. 3-1. Межсетевая среда в состоянии конвергенции Теперь предположим, что канал связи маршрутизатора 2 с сетью 3 вышел из строя, и этот сбой распознан маршрутизатором 2. Как видно на рис. 3-2, маршрутизатор 2 изменяет число переходов в маршруте к сети 3 так, чтобы показать, что она недоступна, т. е. находится бесконечно далеко. Для RIP for IP бесконечность равна 16. Но прежде чем маршрутизатор 2 в соответствии с расписанием успевает оповестить о новом числе переходов к сети 3, он получает от маршрутизатора 1 оповещение, в котором содержится маршрут к сети 3 и указывается, что она отдалена па 2 перехода. Поскольку маршрут с двумя переходами лучше маршрута с шестнадцатью, маршрутизатор 2 обновляет к своей таблице маршрутизации запись для сети 3, изменяя в этой записи число переходов с 16 на 3, как показано на рис. 3-3.
ГЛАВА 3
Одноадресная IP-маршрутизация
53
СетН
Сеть 2 Маршрутизатор 1
Сеть Число переходов 1 2 3
1 t 2
Г]
СетьЗ
X
Маршрутизатор 2 С&ть Число переходов 1
2 1 V16
2 3
Рис. 3-2. Сбой канала связи с сетью 3 СетП Оповещение
Сеть 2 Маршрутизатор 1
Сеть Число переходоз
1 2
- 3
t 1 2
СетьЗ
Маршрутизатор 2 Сеть Число переходов 1 2 3
2 1
>е з
Рис. 3-3. Маршрутизатор 2 после приема оповещения от маршрутизатора 1 Когда маршрутизатор 2 объявляет о своих новых маршрутах, маршрутизатор 1 отмечает, что сеть 3 отдалена на 3 перехода и доступна через маршрутизатор 2. 1 Г ) скольку маршрут к сети 3 на маршрутизаторе 1 изначально был получен от маршрутизатора 2, то маршрутизатор 1 обновляет свой маршрут к сети 3, изменяя в нем число переходов на 4 (рис. 3-4). Когда маршрутизатор 1 объявляет о своих новых маршрутах, маршрутизатор 2 отмечает, что сеть 3 отдалена на 4 перехода и доступна через маршрутизатор 1. Поскольку маршрут к сети 3 на маршрутизаторе 2 изначально был получен от маршрутизатора 1, то маршрутизатор 2 обновляет свой маршрут к сети 3, изменяя в нем число переходов на 5 (рис. 3-5). Эти дна маршрутизатора продолжают оповещать о маршрутах к сети 3, указывая все большие значения числа переходов, — и так до бесконечности (до 16). После
54
ЧАСТЬ 1
Маршрутизация
этого сеть 3 считается недостижимой, и срок действия маршрута к ней в конечном счете истекает. В этом вся суть проблемы счета до бесконечности. Сеть1
Маршрутизатор 1
С$ть Чисяо перехода!! 1 2 3
1 1
СетьЗ
$£
Маршрутизатор 2 Сеть Ч«сло переходов t 2 3
2 1
. з
Рис. 3-4. Маршрутизатор 1 после приема оповещения от маршрутизатора 2 Сеть 1 Оповещение Сеть 2
СетьЗ Маршрутизатор 2
Сеть Число переходов 1 2
з
2 .../-'. t >.5
Рис. 3-5. Маршрутизатор 2 после приема другого оповещения от маршрутизатора 1 Эта проблема — одна из причин, по которым максимальное число переходов в RIP for IP ограничено до 15, Если бы этот максимум имел более высокие значения, конвергенция занимала бы слишком много времени. Кроме того, обратите внимание, что в процессе счета до бесконечности в предыдущем примере маршрут от маршрутизатора 1 к сети 3 проходит через маршрутизатор 2, а маршрут от маршрутизатора 2 к сети 3 — через маршрутизатор 1. Таким образом, на время счета до бесконечности между маршрутизаторами 1 и 2 на пути к сети 3 возникает петля маршрутизации.
ГЛАВА 3
Одноадресная IP-маршрутизация
55
Ускорение конвергенции Чтобы сократить время конвергенции при использовании RIP for IP и избежать счета до бесконечности и петель маршрутизации (по крайней мере в большинстве ситуаций), Вы можете разрешить следующие изменения в механизме RlP-ononeщсний: • разделение направлений (split horizon); • разделение направлений с запретом возвратов (split horizon with poison reverse); •
инициируемые обновления (triggered updates).
Разделение направлений Разделение направлений помогает сократить время конвергенции. При этом маршрутизатору запрещается объявлять о сетях в том направлении, откуда он получил информацию об этих сетях. В однопутевьтх межсетевых средах разделение направлений исключает проблему счета до бесконечности и появление петель маршрутизации в процессе конвергенции, а во многопутевых межсетевых средах — существенно уменьшает вероятность возникновения этой проблемы. Рис. 3-6 иллюстрирует, как алгоритм разделения направлений не дает возможности ШР-маршрутизатору посылать оповещения о маршрутах в том направлении, откуда они FM были получены. Оповещение
СетИ
Маршрутизатор 1 Сеть Число лереходов '' 1 2 ! 3
1 1
Сеть 2
2--
Маршрутизатор 2 Сеть
т 2 3
Чисяо переходов
.2 1 1
СетьЗ
Рис. 3-6. Разделение направлений Разделение направлений с запретом возвратов Разделение направлений с запретом возвратов отличается от простого разделении направлений тем. что маршрутизатор оповещает обо всех известных ему сетях, но для маршрутов в том направлении, откуда он получил о них информацию, он указывает число переходов, равное 16, т. е. соответствующие сети объявляются недостижимыми. В однопутевой межсетевой среде разделение направлений с запретом возвратов не дает никаких преимуществ по сравнению с простым разделением на-
56
Маршрутизация
ЧАСТЬ 1
правлений, но во многопутевой межсетевой среде оно значительно уменьшает вероятность проблемы счета до бесконечности и появления петель маршрутизации. Полностью исключить счет до бесконечности во многопутевой межсетевой среде нельзя, так как информация о маршрутах к сетям поступает из множества источников. В примере на рис. 3-7 разделение направлений с запретом возвратов приводит к объявлению сетей недостижимыми в том направлении, откуда была получена информация о маршрутах к ним. Кроме того, разделение направлений с запретом возвратов не создает дополнительного трафика RIP-сообщениЙ, поскольку объявляются сразу все сети. Оповещение
*Сеть 2 : 1 переход 7*%i €&TI> 3 : 2 перехода Сеть11
-^^\
Р Маршр утизатор
1
Чиело переходов
гть
1
1 t 2
Оповещение Ц1
Сеть 1 : 1 переход СетьЗ ; 16 переходов "**$., ,-•' 0' овещение
: ^ переход ,-'!'"°">'*--ч*чЦ§ Сеть! : 16 переходов Сеть 2 7%i^gj Оповещение qi ц Сеть г : 1 переход '. ^ Сеть 1 : 2 перехода ^4 Сатъ Число переходов 1 2 3
2 1 1
СетьЗ
Рис. 3-7. Разделение направлений с запретом возвратов Инициируемые обновления Инициируемые обновления позволяют RIP-маршрутизатору объявлять об изменениях значений метрик почти сразу после таких изменений, не дожидаясь следующего периода рассылки оповещений. Триггером служит изменение метрики в записи таблицы маршрутизации. Например, благодаря алгоритму инициируемых обновлений маршруты к сетям, ставшим недоступными, могут быть объявлены с числом переходов, равным 16. Заметьте, что обновление посылается почти немедленно; время задержки обычно указывается па самом маршрутизаторе. Если бы все маршрутизаторы немедленно посылали ипциируемые обновления, любое инициированное обновление могло бы вызвать лавинообразное нарастание широковещательного трафика в межсетевой IP-среде. Инициируемые обновления ускоряют конвергенцию RIP-сред, но за это приходится расплачиваться дополнительным широковещательным трафиком, генерируемым по мере распространения обновлений.
ГЛАВА 3
Одноадресная IP-маршрутизация
57
Функционирование RIP for IP Нормальная работа маршрутизатора RIP for IP заключается в выполнении трех процессов: инициализации, в ходе которой ои получает маршруты в межсетевой среде от соседних маршрутизаторов, регулярного оповещения о маршрутах и объявления о недоступных маршрутах в случае его отключения административными средствами.
Инициализация При запуске маршрутизатор RIP for IP оповещает о локально подключенных сетях по всем своим интерфейсам. Соседние RIP-маршрутизаторы обрабатывают это RIP-оповещение и при необходимости добавляют в свои таблицы маршруты к новым сетям. Инициализирующийся RIP-маршрутизатор также посылает универсальный RIPзапрос (General RIP Request) во все локально подключенные сети. Этот запрос является особым RiP-с.ообшением, в котором запрашиваются осе маршруты. Получив универсальный RIP-запрос, соседние RIP-маршрутизаторы посылают ответ, адресованный непосредственно запросившему маршрутизатору. На основе этих ответов формируется таблица маршрутизации инициализирующегося RIP-MapinpyTnзатора. Регулярное оповещение По умолчанию RIP-маршрутизатор каждые 30 секунд посылает но всем интерфейсам оповещения о своих маршрутах. Содержимое оповещения о маршрутах зависит от того, на использование какого алгоритма настроен RIP-маршрутизатор разделение направлений или разделение направлений с запретом возвратов. Кроме того, RIP-маршрутизатор всегда прослушивает RIP-оповещения от соседних маршрутизаторов, чтобы своевременно добавлять или обновлять маршруты в собственной таблице маршрутизации. Отключение маршрутизатора административными средствами Если маршрутизатор RIP for IP корректно выключается административными средствами, он посылает инициируемое обновление во все локально подключенные сети. В нем объявляется, что в маршрутах к сетям, доступным через данный маршрутизатор, число переходов равно 16 (сети недостижимы). Изменение в топологии межсетевой IP-среды распространяется соседними RIP-маршрутизаторами с использованием инициируемых обновлений. Как и динамические маршрутизаторы, маршрутизаторы RIP for IP тоже реагируют на такие изменения в топологии межсетевой среды, которые вызваны выходом из строя каких-либо каналов связи или маршрутизаторов. Выход канала связи из строя Если вышедший из строя канал связи соединен с одним из интерфейсов маршрутизатора, если этот сбой апларатно распознается интерфейсом и если интерфейс уведомляет маршрутизатор о таком сбое, то посылается соответствующее инициируемое обновление.
58
ЧАСТЬ 1
Маршрутизация
Выход маршрутизатора из строя Если маршрутизатор отключается из-за аварии с электроснабжением или какогонибудь сбоя в оборудовании или программном обеспечении, у него нет возможности уведомить соседние маршрутизаторы о том, что сети, к которым он был подключен, теперь недоступны. Чтобы не допустить чрезмерно длительного присутствия недоступных маршрутов в таблицах маршрутизации, каждый маршрут, полученный RIP for IP, имеет максимальный срок действия в 3 минуты (по умолчанию). Если соответствующая запись не обновляется в течение трех минут, число переходов в ней изменяется на 16, и в конечном счете она удаляется из таблицы маршрутизации. Поэтому, если маршрутизатор RIP for IP выходит из строя, соседние маршрутизаторы помечают полученные от него маршруты недоступными не раньше, чем через 3 минуты. И только после этого они распространяют информацию об изменении топологии, используя алгоритм инициируемых обновлений.
RIP for IP версии 1 RIP версии 1 (vl) определен в RFC 1058 и широко применяется в малых и средних межсетевых средах.
Формат сообщений RIP v1 RIP-сообщения инкапсулируются в UDP-дейтаграмму, которая посылается с IPадреса интерфейса маршрутизатора и его UDP-порта 520 на широковещательный IP-адрес подсети. Сообщение RIP vl содержит 4-байтовый RIP-заголовок и максимум 25 RIP-маршрутов. Максимальный размер RIP-сообщения — 504 байта. С учетом 8-байтового U DP -заголовка, максимальный размер RIP-сообщения достигает 512 байтов. Формат сообщений RIP vl показан на рис. 3-8. 1 = запрос,
Команда
Версия 01 Должно быть нулем DO И] Идентификатор семейства
До 25 маршрутов в одном RIP-сообщении
Должно быть нулем
00 02 2 Обозн 00 ЕЮ
IP-адрес Должно быть нулем 00 00 00 00 Должно быть нулем 00 00 00 00 Метрика = 1 байт
Рис. 3-8. Формат сообщений RIP версии 1 Команда. Однобайтовое поле, содержащее либо 0x01, либо 0x02. Первое значение указывает, что RIP-запрос адресован всем (General RIP Request) или только части таблиц маршрутизации соседних маршрутизаторов. Второе значение указывает, что RIP-ответ включает все содержимое или часть таблицы маршрутизации соседнего маршрутизатора. RIP-ответ посылается в ответ на RIP-запрос или при периодическом либо инициируемом обновлении.
ГЛАВА 3 Одноадресная IP-маршрутизация
59
Версия. Однобайтовое поле. Для RIP vl содержит значение 0x01. Идентификатор семейства. Двухбайтовое поле, идентифицирующее семейство протоколов. Содержит значение 0x00-02, которое указывает на семейство протоколов IP. IP-адрес. Четырехбайтовое поле, содержащее идентификатор IP-сети, который может быть идентификатором сети, основанным на классе (class-based network .'D), идентификатором сети, включающим идентификаторы подсетей (subletted network ID) (для сети, разбитой на подсети), IP-адресом (для маршрута к хосту) или :шачением, равным 0.0.0.0 (для маршрута по умолчанию). В General RIP Request поле IP-адреса устанавливается равным 0.0.0.0. Метрика. Четырсхбайтовое поле, указывающее число переходов к IP-сети; может принимать значения от 1 до 16. Метрика приравнивается 16 для General RIP Request или для того, чтобы сообщить в RIP-ответе, что данная сеть недостижима.
Проблемы с RIP v1 RIP vl разработан в 1988 году для динамической маршрутизации в межсетевых IPсредах на основе LAN-технологий. Сетевые технологии разделяемого доступа (shared access LAN technologies) вроде Ethernet и Token Ring поддерживают широковещание на МАС-уровне, при котором один пакет может быть принят и обработан множеством узлов в сети. Однако в современных межсетевых средах применение широковещания на МАС-уровне нежелательно, так как в этом случае всем узлам приходится обрабатывать все широковещательные пакеты. Кроме того, RIP vl разрабатывался в то время, когда в Интернете еще использовали идентификаторы сетей на основе классов Интернет-адресов. Б наше время для экономии IP-адресов почти повсеместно используются CIDR (Classless Inter-Domain Routing) и разбиение на подсети переменного размера (variable length subnetting).
Широковещательные fllP-оповещения Все оповещения о маршрутах RIP vl адресуются на широковещательный адрес IPподсети (все биты идентификатора хоста установлены в 1) и адрес Широкове! iaтельной рассылки МАС-уровня. Хосты, не поддерживающие RIP, также принимают RIP-оповещения. В больших и очень больших RIP-средах объем широковещательного трафика в каждой подсети может быть весьма значительным. RIP vl также дает возможность применять Silent RIP. Компьютер со службой Silent RIP (Пассивный RIP) обрабатывает RIP-оповещения, но не объявляет о своих маршрутах. Silent RIP можно включить на обычных хостах, что позволит формировать на них такие же детальные таблицы маршрутизации, что и на RIP-маршрутизаторах. Располагая более детальной информацией о маршрутах, хост Silent RIP сможет принимать более эффективные решения по маршрутизации. Маска подсети не объявляется вместе с маршрутом RIP vl предназначен для межсетевых IP-сред с адресацией на основе классов, в которых идентификатор сети может быть определен по значениям первых трех битов IP-адреса в RIP-маршруте. Поскольку маска полсети не включается в маршрут, RIP-маршрутизатору приходится определять идентификатор сети, исходя из ограниченного набора данных. Для каждого маршрута в сообщении RIP vl маршрутизатор RIP vl выполняет следующие операции.
60
ЧАСТЬ 1
Маршрутизация
• Если идентификатор сети укладывается в какой-либо класс адресов (А, В или С), используется маска подсети по умолчанию для данного класса. • Если же идентификатор сети не укладывается в какой-либо класс адресов, то: • если идентификатор сети подходит к маске подсети па интерфейсе, с которото он был получен, используется маска подсети этого интерфейса; • если идентификатор сети не подходит к маске подсети на интерфейсе, с которого он был получен, считается, что идентификатор сети — это маршрут к хосту с маской подсети 255.255.255.255. В результате этих допущений маршрут, нключающие надсети (supernettcd routes), могут интерпретироваться как один идентификатор сети, а не как группа идентификаторов; кроме того, маршруты к подсети (subnet routes), объявляемые вне сети с данной подсетью, могут восприниматься как маршруты к хосту. Поэтому для поддержки сред с подсетями маршрутизаторы RIP vl не объявляют о подсетях идентификатора сети па основе классов за границами региона межсетевой IP-среды, разбитого на подсети. Однако, поскольку за пределами среды с подсетями объявляется только идентификатор сети на основе класса (без входящих в него идентификаторов подсетей), подсети для данного идентификатора сети в среде RIP vl должны быть расположены непрерывно, одна за другой. Если же подсети не являются смежными, идентификатор сети па основе класса в разных частях межсетевой среды объявляется разными маршрутизаторами RIP vl. В итоге IP-трафик может быть направлен не той сети. Отсутствие защиты от неавторизованных RIP маршрутизаторов RIP vl не предусматривает никакой .шииты от неавторизовашюго RIP-маршрутизатора (rogue RIP router), который запускается в сети и сообщает ложные или неточные маршруты. Оповещения RIP vl обрабатываются независимо от их источника. Поэтому злоумышленник может легко воспользоваться этой брешью в защите и заполонить RIP-маршрутизаторы сотнями или тысячами ложных или неточных маршрутов.
RIP for IP версии 2 RIP версии 2 (v2), определенный в RFC 1723, устраняет некоторые недостатки R[P vl. Учитывая появление более современных и эффективных протоколов маршрутизации вроде OSPF, принятие решения о доработке RIP было довольно спорным. Однако RIP имеет ряд преимуществ над OSPF: • RIP for IP прост в реализации. В элементарной конфигурации по умолчанию вся настройка RIP for IP заключается в том, что Вы присваиваете нужные IPадреса и маски подсетей каждому интерфейсу маршрутизатора, а затем просто включаете его. •
RTP for IP широко используется в малых и средних по размеру межсетевых IPсредах, администраторы которых не имеют ни малейшего желания взваливать на себя бремя планирования и конфигурирования OSPF.
Функциональность RIP v2 Чтобы свести к минимуму широковещательный трафик в современных межсетевых IP-средах, разрешить разбиение на подсети переменной длины (для экономии IP-
ГЛАВД 3
Одноадресная IP-маршрутизация
61
адресов) и обезопасить среду маршрутизации от неправильно настроенных (случайно или умышленно) маршрутизаторов, в RIP v2 было добавлено несколько ключевых функций. Групповые RIP-оповещения RIP v2 может посылать RIP-оповещения на IP-адрес групповой рассылки (224.0.0,9), не используя широковещания. Благодаря этому трафик, связанный с RIP-оповещепиями, не затрагивает хосты, не поддерживающие RIP, Недостаток этой новой функции в том, что хосты Silent RIP тоже должны прослушивать групповой трафик, посылаемый на 224.0.0.9. Если Вы используете службу Silent RIP (Пассивный RIP), то, прежде чем применять эту функцию RIP v2, убедитесь, что Ваши хосты Silent RIP могут прослушивать групповые оповещения RIP v2, Поддержка групповых RIP-оповещений не является обязательной функцией. RIP v2 поддерживает и широковещательные оповещения,
Маски подсетей В оповещениях RIP v2 вместе с идентификатором сети передается и маска полсети (также называемая сетевой маской). RIP v2 можно использовать в средах с подгетями. надсетями и масками подсетей переменной длины. Подсети, определяемые идентификатором сети, могут быть несмежными.
Аутентификация RTP v2 поддерживает механизмы аутентификации для проверки источника входящих RIP-оповещений. В RFC 1723 определена аутентификация по простому паролю, но RIP v2 позволяет использовать более новые механизмы аутентификации, например Message Digest 5 (MD5). Примечание Windows 2000 поддерживает только аутентификацию по простому пароли). Совместимость с маршрутизаторами ШР v1 RIP vl разрабатывался в расчете па совместимость с будущими версиями RIP. EC^IH маршрутизатор RIP vl получает сообщение и поле версии в RIP-заголовке этого сообщения содержит значение, отличное от 0x01, то он не отбрасывает данное К. Г 1 } оповещение, а обрабатывает лишь поля, определенные для RIP v l . Кроме того, маршрутизаторы RIP v2 посылают на запрос RIP vl ответ в формате RIP vl, если только они не настроены на посылку оповещений исключительно в формате RIP v2.
Формат сообщений RIP v2 Чтобы маршрутизаторы RIP vl могли обрабатывать оповещения RIP v2, в RIP v2 не модифицировали структуру RIP-сообщений. RIP v2 использует поля, определенные в RIP vl как нулевые. Назначение нолей «команда?, «идентификатор семейства», «IP-адрес» и «метрика» — то же, что и в RIP vl. Поле версии устанавливается равным 0x02, указывая, что это сообщение RIP v2. Формат сообщений RIP v2 показан на рис. 3-9.
62
ЧАСТЬ 1
Маршрутизация Команда
1 = запрос, 2 = ответ
Версия
, Должно быть нулем 00100 Идентификатор семейства До 25 маршрутов в одном RIP-сообщении
00 02 2 обозн
Метка маршрута IP-адрес Маска подсети Следующий переход Метрика
Г] = байт
Рис. 3-9, Формат сообщений RIP версии 2 Метка маршрута. Это поле используется для маркировки особых маршрутов, применяемых в административных целях. Изначально в RFC 1723 было определено, что это поле должно давать возможность отличать маршруты на основе RIP (внутренние для RIP-ереды) от маршрутов на другой основе (внешних для RIPсреды). Поле метки маршрута настраивается на маршрутизаторах, поддерживающих несколько протоколов маршрутизации. Примечание Windows 2000 поддерживает настройку поля метки маршрута для интерфейсов RIP v2. Маска подсети. Четырехбайтовое поле, содержащее маску подсети (также называемую сетевой маской) для идентификатора сети в поле IP-адреса. Следующий переход. Четырехбайтовое поле, содержащее пересылочный IP-адрес (также называемый адресом шлюза) для идентификатора сети в поле IP-адреса. Если следующий переход настроен на 0.0.0.0, то предполагается, что пересылочный IP-адрес (следующий переход) для маршрута является IP-адресом источника данного оповещения. Поле следующего перехода используется для того, чтобы предотвратить выбор неоптимального маршрута, Вот простейший пример неоптимальной маршрутизации. Если какой-либо маршрутизатор объявляет маршрут к хосту, расположенному в той же сети, что и интерфейс маршрутизатора, по которому было объявлено о данном маршруте, и поле следующего перехода не используется, то пересылочным IP-адресом для маршрута к хосту станет IP-адрес интерфейса маршрутизатора, а вовсе не IP-адрес хоста. Другие маршрутизаторы в той же сети, получившие ото оповещение, будут пересылать адресованные хосту пакеты на IP-адрес первого маршрутизатора вместо того, чтобы направлять их этому хосту. При использовании поля следующего перехода маршрутизатор объявляет маршрут к хосту, указывая IP-адрес хоста в поле следующего перехода. Другие маршрутизаторы в той же сети, получившие это оповещение, будут пересылать адресованные хосту пакеты на IP-адрес хоста, а не объявившему маршрутизатору. Поскольку в таблице IP-маршрутизации поле следующего перехода становится полем адреса шлюза, IP-адрес, указанный в поле следующего перехода, должен находиться в сети, напрямую подключенной к интерфейсу данного маршрутизатора.
ГЛАВА 3
Одноадресная IP-маршрутизация
63
Аутентификация в RIP v2 При использовании аутентификации для оповещений RIP v2 аутентификационная информация хранится в записи первого маршрута в RIP-сообщении. Таким образом, в оповещении RIP v2 с аутентификацией может быть объявлено максимум 24 маршрута. Чтобы указать на необходимость аутентификации, поле идентификатора семейства устанавливается равным OxFF-FF. Поле типа аутентификации, в нормальных условиях используемое как поле метки маршрута, определяет тип применяемой аутентификации. В случае аутентификации по простому паролю в это поле записывается значение 0x00-01. Следующие за полем типа аутентификации 16 байтов применяются для хранения аутентификационных данных. В случае аутентификации по простому паролю сюда записывается незашифрованный, чувствительный к регистру букв пароль с выравниванием по левому краю и дополнением недостающих символов нулями. Формат сообщений RIP v2 с аутентификацией показан на рис. 3-10. Команда 02 Версия 02 Должно быть нулем 00
по]
Идентификатор семейства FF FF Указывает аутентификацию Тип аутентификации 00 01 Указывает простой пароль Простой пароль
L ... ГГ
1
L 16 байтов
1 = 1 байт
Рис. 3-10. Формат сообщений RIP v2 с аутентификацией Маршрутизаторы RIP vl игнорируют первую запись маршрута в сообщении RIP v2 с аутентификацией, поскольку им не известен идентификатор семейства в этой записи. Примечание Аутентификация по простому паролю для RIP v2 не позволяет размещать в сети неавторизованные или неправильно настроенные RIP-маршрутиза горы. Однако простой пароль ненадежен, так как перелается по сети открытым текстом. Любой, у кого есть анализатор протоколов типа Microsoft Network Monitor (Сетевой монитор), может захватить пакеты RIP v2 и выяснить пароль аутентификации.
Смешанные среды RIP v1 и RIP v2 Пользоваться маршрутизаторами RIP v2 в комбинации с маршрутизаторами RIP vl следует с осторожностью. Поскольку маршрутизаторы RIP vl не интерпретируют ноле маски подсети в маршруте, маршрутизаторы RIP v2 не должны оповещать о маршрутах, которые могут быть неверно интерпретированы маршрутизаторачи RIP vl. Кроме того, в таких смешанных средах нельзя использовать маски подсетей переменной длины (variable length subnet masks, VLSM) и указывать несмежные подсети.
64
ЧАСТЬ 1
Маршрутизация
Выдавая оповещения RIP v2, полностью распознаваемые маршрутизаторами RIP vl, маршрутизаторы RIP v2 должны суммировать маршруты подсети, если оповещения выходят за пределы среды, разбитой на подсети. Маршрут к подсети, объявленный маршрутизатору RIP vl, может быть ошибочно истолкован как маршрут к хосту. Кроме того, маршрутизаторы RIP v2 не должны объявлять маршруты к надсетям — маршрутизатор RIP vl может носприпять диапазон сетей как единую сеть. Если маршрутизаторы RIP v2 находятся в той же сети, что и маршрутизаторы RIP vl, соответствующие интерфейсы маршрутизаторов RIP v2 должны быть настроены на широковещательную рассылку оповещений. Групповые оповещения RIP v2 не обрабатываются маршрутизаторами RIP v l .
Windows 2000 как маршрутизатор RIP for IP RIP tor IP в Windows 2000 соответствует RFC 1058 и 1723 и поддерживает: •
алгоритмы конвергенции «разделение направлений» (split horizon), «запрет возвратов» (poison reverse) и «инициируемые обновления» (triggered updates); • возможность изменения периодичности оповещений (по умолчанию — 30 секунд); • возможность изменения срока действия записей в таблице маршрутизации (но умолчанию — 3 минуты); • Silent RIP (Пассивный RIP) для хостов; • функцию Peer Filtering (фильтрация равноправных маршрутизаторов) — позволяет принимать или отбрасывать обновления, содержащиеся в оповещениях, которые поступают от определенных маршрутизаторов (идентифицируются по IP-адресам); • функцию Route Filtering (фильтрация маршрутов) — позволяет принимать или отбрасывать обновления, поступающие из определенных сетей или от определенных маршрутизаторов; • функцию RIP Neighbors (соседи RIP) — позволяет направлять адресные RIPоновещения определенным маршрутизаторам для поддержки сетевых технологий, не использующих широковещания, например Frame Relay. Сосед RIP — это RIP-маршрутизатор, который принимает адресные RIP-оповещения; • возможность объявления или приема маршрута по умолчанию или маршрута к хосту. Примечание Когда маршрутизатор Windows 2000 оповещает о маршруте, полученном не от RIP (non-RIP learned route), он объявляет его с числом переходов, равным двум. К маршрутам, получаемым не от RIP, относятся статические маршруты (даже для напрямую подключенных сетей), а также маршруты OSPF и SNMP. Вы можете просмотреть текущих соседей RIP в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ), щелкнув правой кнопкой мыши протокол маршрутизации RIP (RIP) и выбрав команду Show Neighbors (Отобразить соседей).
Выявление и устранение проблем с RIP for IP Если RIP-среда сконфигурирована корректно, после конвергенции RIP-маршрутизаторы получают от соседних маршрутизаторов наиболее оптимальные маршруты.
ГЛАВА 3
Одноадресная IP-маршрутизация
65
Точный список маршрутов, добавляемых R1P и таблицу IP-маршрутизации, зависит от того, находятся ли интерфейсы маршрутизатора в регионе, разбитом на пол* сети, применяется ли RIP v2, объявляются ли маршруты к хостам или маршруты по умолчанию, а также от ряда других факторов. Проблемы с RIP могут возникать в смешанных средах RIP vl и v2 при использовании хостов Silent RIP или в тех случаях, когда не все RIP-маршруты принимаются и добавляются в таблицу IP-маршрутизации. Проблема с маршрутами в смешанной среде RIP v1 и RIP v2 В сетях, содержащих маршрутизаторы RIP vl, убедитесь, что RIP v2 настроен па широковещательную рассылку своих оповещений в сети с маршрутизаторами RIP vl. В сетях, содержащих маршрутизаторы RIP v l , убедитесь, что интерфейсы маршрутизаторов RIP v2 сконфигурированы на прием оповещений как RIP v l , так и RIP v2. Хосты Silent RIP не получают информацию о маршрутах Если в сети имеются хосты Silent RIP, не получающие маршруты от локального RIP-маршрутизатора, проверьте версию RIP, поддерживаемую этими хостами. Например, если они прослушивают только широковещательные оповещения RIP vl, не настраивайте RIP v2 на групповую рассылку оповещений, Если Вы используете компонент RIP Listener (Слушатель RIP), доступный в Microsoft Windows NT Workstation версии 4.0 с Service Pack 4 (или выше), настройте свои RIP-маршрутизаторы на широковещание по RIP vl или RIP v2. RIP-маршрутизаторы не получают ожидаемые маршруты Убедитесь, что Вы не используете разбиение на подсети переменного размера и несмежные подсети, а также не применяете надсети в RIP vl или в смешанной среде RIP vl и RIP v2. • Если включена аутентификация, убедитесь, что все интерфейсы в одной и ' ой же сети используют один и тот же пароль (он чувствителен к регистру букв}. ш
• Если включена RIP-фильтрация равноправных маршрутизаторов, убедитесь, что для соседних равноправных RIP-маршрутизаторов заданы корректные IP-адреса. • • •
• •
Если разрешена RIP-фильтрация маршрутов, убедитесь, что нужные диапазоны идентификаторов сетей не исключены из Вашей межсетевой среды. Если Вы активизировали функцию RIP Neighbors, проверьте правильность I Pадрееов для адресных RIP-оповещений. Убедитесь, что фильтрация IP-пакетов не препятствует приему (через входные фильтры) или передаче (через выходные фильтры) RIP-оповещений по интерфейсам маршрутизатора, настроенным на RIP. RIP-трафик использует UDPпорт 520. Убедитесь, что фильтрация TCP/IP на интерфейсах маршрутизатора не запрещает прием RlP-трафика. В случае интерфейсов соединения по требованию*, использующих автостатические обновления (aulo-static updates), настройте эти интерфейсы на использоиа-
* В русской версии Windows 2000 Server такие интерфейсы называются интерфейсами вызова по требованию. — Прим, перев.
66
ЧАСТЬ 1
Маршрутизация
ние групповых оповещений RIP v2. Когда один маршрутизатор вызывает другой, каждый из них получаст IP-адрес из пула IP-адресов другого маршрутизатора, а эти адреса находятся в разных подсетях. Поскольку широковещательные RIP-оновстцения направляются на адрес широковещательной рассылки в подсети, эти маршрутизаторы не обрабатывают широковещательные запросы о маршрутах друг от друга. При использовании групповой рассылки RIP-запросы и оповещения обрабатываются независимо от подсети для интерфейсов маршрутизаторов. Подробнее об интерфейсах соединения по требованию и автостатических обновлениях см. главу 6 «Маршрутизация с соединением по требованию» в этой книге. • В случае «RIP поверх интерфейсов соединения по требованию» (RIP over demand-dial interfaces) проверьте, не мешают ли приему или передаче RIP-трафика фильтры пакетов, определенные в профиле политики удаленного доступа отвечающего маршрутизатора. Фильтры TCP/IP-пакетов можно настроить в свойствах профиля политики удаленного доступа на отвечающем маршрутизаторе (или IAS-сервере, если используется RADIUS). Эти фильтры определяют, какой трафик допустим по соединению удаленного доступа. Маршруты к хосту или маршруты по умолчанию не распространяются маршрутизаторами По умолчанию маршруты к хосту и маршруты по умолчанию не объявляются через RIP. Вы можете изменить это поведение на вкладке Advanced (Дополнительно) окна свойств RIP-интерфейса, которое открывается в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ).
OSPF OSPF (Open Shortest Path First) — протокол маршрутизации на основе состояния каналов, определенный в RFC 2328. Он предназначен для работы в качестве IGP (Interior Gateway Protocol) в одной автономной системе (autonomous system, AS). В любом протоколе маршрутизании на основе состояния каналов каждый маршрутизатор поддерживает базу данных оповещений, называемую Link State Advertisements (LSA). LSA на маршрутизаторе внутри автономной системы включает информацию о маршрутизаторах и подключенных к ним сетям, а также сведения о цепе их использования. Цена использования в OSPF (OSPF cost) — это безразмерная метрика, которая определяет предпочтение использования того или иного канала связи. Существуют также LSA для суммированных маршрутов и маршрутов за пределами автономной системы. Маршрутизатор распространяет свои LSA на соседние маршрутизаторы Эти LSA собираются в базу данных состояний каналов связи (link state database, LSDB). За счет синхронизации LSDB между всеми соседними маршрутизаторами в базе данных каждого маршрутизатора имеются LSA остальных маршрутизаторов. Благодаря этому на всех маршрутизаторах хранится одна и та же LSDB. Записи таблицы маршрутизации на каждом маршрутизаторе формируются на основе данных LSDB с применением алгоритма Дейкстры (Dijkstra algorithm), который позволяет определить путь с наименьшей ценой использования (least cost path) к каждой сети в межсетевой среде, т, е. кратчайший путь. Для OSPF характерны следующие возможности.
ГЛАВА 3
Одноадресная IP-маршрутизация
67
Быстрая конвергенция. OSPK распознает и распространяет изменения в топологии гораздо быстрее, чем RIP. В OSPF нет проблемы счета до бесконечности. Маршруты, свободные от зацикливания. Маршруты, вычисляемые OSPF, всегда свободны от зацикливания (петель маршрутизации). Масштабируемость. OSPF позволяет подразделить автономную систему на непрерывные группы сетей, называемые областями (areas). Маршруты внутри областей можно суммировать, тем самым уменьшая число записей в таблице маршрутизации. Области могут быть сконфигурированы с маршрутом по умолчанию, гуммирующим все маршруты за пределами автономной системы или области. Так что OSPF способен масштабироваться под большие и очень большие межсетевые среды. В противоположность этому межсетевые среды RIP for IP нельзя подразделять на области меньшего размера, а суммирование маршрутов невозможно (кроме суммирования всех подсетей по данному идентификатору сети). Маска подсети объявляется вместе с сетью. OSPF рассчитан на оповещение о маске подсети при объявлении сети. OSPF поддерживает маски подсетей переменной длины (VLSM), надсети и несмежные подсети. Поддержка аутентификации. Обмен информацией между OSPF-маршрутизаторами можно аутентифицировать. OSPF в Windows 2000 поддерживает аутентификацию по простому паролю. Поддержка внешних маршрутов. Маршруты, выходящие за пределы автономной системы OSPF, объявляются и внутри автономной системы, чтобы OSPF-маршрутизаторы могли вычислять маршрут к внешним сетям с наименьшей ценой использования, Примечание Аутентификация по простому паролю для OSPF рассчитана на то, чтобы не допустить размещения в сети неавторизованных OSPF-маршрутизаторов. Однако простой пароль ненадежен, так как передается по сети открытым текстом. Любой, у кого есть анализатор протоколов типа Microsoft Network Monitor, может захватить сообщения OSPF и выяснить пароль аутентификации.
Функционирование OSPF Основную часть работы протокол OSPF выполняет в процессе конвергенции межсетевой среды. \. Компиляция LSDB. 2. Вычисление дерева SPF (Shortest Path First Tree, SPF Tree). 3. Создание записей в таблицах маршрутизации.
Формирование LSDB с использованием LSA LSDB — это база данных, сформированная из всех LSA маршрутизаторов OSI'F, сводных LSA и LSA внешних маршрутов. LSDB компилируется за счет обмена LSA между соседними маршрутизаторами, чтобы каждый маршрутизатор был синхронизирован со своим соседом. В процессе конвергенции автономной системы в LSDB на каждом маршрутизаторе помещаются соответствующие записи. Чтобы создать LSDB, каждый OSPF-маршрутизатор должен получить действительный LSA от своего соседа в автономной системе. Это достигается через процсду.>у,
68
ЧАСТЬ 1 Маршрутизация
называемую растеканием (flooding). Каждый маршрутизатор изначально посылает LSA, которая содержит его конфигурацию. По мере получения LSA от других маршрутизаторов он передает эти LSA своим соседям. Таким образом, LSA от данного маршрутизатора растекается по автономной системе, и все остальные маршрутизаторы в ней включают LSA от первого маршрутизатора. Хотя на первый взгляд может показаться, что растекание многочисленных LSA по автономно!] системе должно создавать интенсивный сетевой трафик, OSPF распространяет LSA-информацию очень эффективно. Рис. 3-11 иллюстрирует простую автономную систему OSPF и потоки LSA между соседними маршрутизаторами. Подробнее о синхронизации LSDB между соседними маршрутизаторами см. раздел «Синхронизация LSOB через механизм соседства*- далее в этой главе. Вы можете просмотреть текущее содержимое базы данных состояний каналов связи в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ): щелкните правой кнопкой мыши протокол маршрутизации OSPF (OSPF) и выберите команду Show Link State Database (Отобразить базу данных состояния связей). Автономная система
- LSA-потоки
Рис. 3-11. База данных состояний каналов связи (LSDB) Код маршрутизатора Для отслеживания LSA в LSDB каждому маршрутизатору назначается свой код (Router ID) — 32-разрядное число в точечно-десятичной нотации, уникальное в данной автономной системе. Этот код идентифицирует маршрутизатор в автономной системе, а не IP-адрес одного из интерфейсов маршрутизатора. Код маршрутизатора не используется как IP-адрес назначения при передаче информации маршрутизатору. В компьютерной индустрии принято соглашение, что в качестве кода маршрутизатора принимается его наибольший или наименьший IP-адрес. Поскольку IP-адреса уникальны, данное соглашение гарантирует уникальность и кодов OSPF-маршрутизаторов.
ГЛАВА 3
Одноадресная IP-маршрутизация
69
Вычисление дерева SPF по алгоритму Дейкстры Как только компиляция LSDB завершается, каждый OSPF-маршрутизатор на основе информации в LSDB вычисляет путь с наименьшей ценой использования (по алгоритму Дейкстры) и создает дерево кратчайших путей к каждому маршрутизатору и к каждой сети, причем корнем этого дерева является тот маршрутизатор, который формирует это дерево. Оно называется деревом SPF (SPF Tree) и содержит по одному пути с наименьшей ценой использования к каждому маршрутизатору и к каждой сети в автономной системе. Поскольку вычисление пути с наименьшей ценой использования осуществляется вселит маршрутизаторами, у каждого из них свое дерево SPF в автономной системе. Алгоритм Дейкстры взят из той области математики, которая называется теорией графов; это очень эффективный метод вычисления набора кратчайших путей относительно узла-источника. Алгоритм Дейкстры для вычисления дерева SPF Этот алгоритм па выходе дает множество SPF{} — список кратчайших путей, отсортированных но цене использования. Он включает путь (набор узлов и связей) и его аккумулированную цепу использования от узла-источника S. 1. Определить множество Е{} как набор узлов (маршрутизаторов), подлежащих оценке. 2. Определить множество R{} как набор остальных узлов (маршрутизаторов), не подлежащих оценке. 3. Определить множество О{} как список отсортированных по пене использова! ия упорядоченных путей между узлами. Упорядоченный путь (ordered path) может состоять из нескольких узлов, соединенных друг с другом в конфигурацию с несколькими переходами (они не обязательно должны быть соседними). 4. Определить множество SPF{} как список отсортированных по цене использования кратчайших путей. 5. Инициализировать множество Е{| так, чтобы оно содержало узел-источник S, a множество R{} — все остальные узлы. Инициализировать множество О{} как список отсортированных по цене использования путей, напрямую соединяющих с S. Инициализировать множество SPF{} как пустое. 6. Если О{} пусто или первый путь в О{} имеет бесконечную метрику, пометить все узлы в R как недостижимые и завершить работу алгоритма. 7. Во множестве О{} проанализировать Р. кратчайший упорядоченный путь в О{}. Удалить Р из О{}. Пусть V будет последним узлом в упорядоченном пути Р. Если V уже является членом множества Е{}, вернуться на этап 6. - Или Если Р — кратчайших! путь к V. переместить V из R{} в Е{}. Добавить новый чл!.'н во множество SPF{}, состоящий из Р и его аккумулированной цепы использования от S. 8. Создать новый набор путей за счет конкатенации Р и каждого из каналов, смежных с V. Цена использования этих путей является суммой целы Р и метрики канала, добавленного к Р. Вставить новые связи во множество О{} и отсортировать по цене использования. Вернуться на этап 6,
70
ЧАСТЬ 1
Маршрутизация
Вычисление записей таблицы маршрутизации по дереву SPF Записи в таблице маршрутизации создаются на основе дерева SPF, и для каждой сети в автономной системе формируется одна запись, Метрикой в записи служит цена использования, вычисленная OSPF, а не число переходов. Для расчета записей в таблице IP-маршрутизации на основе дерева SPF анализируется полученное множество SPF{}. Результатом этого анализа становится набор OSPF-маршрутов, содержащих IP-адрес назначения (идентификатор сети) и его сетевая маска (маска подсети), пересылочный IP-адрес подходящего соседнего маршрутизатора, интерфейс, через который доступен соседний маршрутизатор, и цена использования маршрута к сети, вычисленная OSPF. После этого OSPF-маршруты добавляются в таблицу IP-маршрутизации.
Пример работы OSPF Здесь будет показано, как OSPF компилирует LSDB, как вычисляет путь с наименьшей пеной использования и как создает записи в таблице маршрутизации. Данный пример специально упрощен, чтобы Вам было легче разобраться в базовых принципах OSPF-конвергенции. Компиляция LSDB Возьмем простую автономную систему, представленную па рис. 3-12. Каждому интерфейсу маршрутизатора присваивается безразмерная метрика (цена), отражающая уровень предпочтения использования этого интерфейса. Эти «ценовые» значения могут быть результатом учета таких факторов, как полоса пропускания, задержки и надежность, — решение принимается сетевым администратором. Автономная система Цена=2 . . Цена»? Сеть 6 Сеть 2
Сеть 3
R1 -• ч, Цена=2'"' ••-1 Сеть 4 ''"'•-. Цена=3
Сеть 5 Цвна=2
R4
Рис. 3-12. Автономная система с информацией LSDB После конвергенции, когда на каждом маршрутизаторе имеются LSA от остальных маршрутизаторов в автономной системе, содержимое LSDB соответствует тому, что показано в таблице 3-1.
ГЛАВА 3
Одноадресная IP-маршрутизация
71
Таблица 3-1. Содержимое базы данных состояний каналов Маршрутизатор
Подключенные сети и цены использования
R1
Сеть 1-цена 2, сеть 3-цена 5, сеть 4-цсна 2 Сеть 1-цена 1, сеть 2-цена 4, сеть 6-цсна 2 Сеть 2-цена 4, сеть 3-цена 2, сеть 5-цена 3, сеть 7-цена 2 Сеть 4-цена 3, сеть 5-цена 2 Сеть 6-цена 2, сеть 7-цена 3
R2 R3 К i R5
Вычисление дерева SPF Следующий таг — применение алгоритма Дейкстры к нашей автономной системе. Рис. 3-13 иллюстрирует дерево SPF, вычисляемое маршрутизатором R4. В результате R4 размещается в корне и определяется набор подключенных маршрутизаторов и сетей. Это дерево отражает кратчайший путь к каждому маршрутизатору и к каждой сети.
Цена=з|Н Сеть ^ Цена=2 Сеть 1, .„ R3
R1
Цена=2 Сеть 7
Сеть 2 R2
Цена=2 Сеть 6 R5
Рис. 3-13. Дерево SPF Создание записей в таблице маршрутизации Таблица маршрутизации создается по результатам расчета дерева SPF, как показано на рис. 3-14, Примечание В большой сети с OSPF в момент обмена LSA между маршрутизаторами может кратковременно понадобиться значительная часть ее полосы пропускания. После обмена LSA между маршрутизаторами требуется большой объем памяти для хранения LSDB до конвергенции. Алгоритм SPF очень интенсивно использует вычислительные мощности центральных процессоров. Сети с часто появляющимися и исчезающими каналами связи могут вызывать проблемы с производительностью маршрутизаторов. Издержки от использования OSPF можно свести к минимуму, разбив автономную систему на области. Подробнее см. раздел «Области OSPF» далее в этой главе.
72
ЧАСТЬ 1
Маршрутизация
Цена=3 Сеть Цена=2 аСеть 1
Цена=2 Сеть 7 .
'
41
'
Цена=4 Сеть 2
m
R2
8
Цена=2
Сеть 6
R5
Сеть 4 5 1 3 2 7 6
Пересылочный IP-адрес — _.
Порт
Метрика
1 2 1 2 2 2 2
3 2 5 4 6 4 6
R1 R3 R3 R3
т
Рис. 3-14. Записи it таблице маршрутизации
Типы сетей в терминах OSPF Адреса OSPF-сообщений определяются типом сети, к которой подключен OSPFинтерфейс. При настройке интерфейса OSPF-маршрутшатора нужно выбрать один ил следующих типов сетей OSPF. Broadcast (Широковещательная). Сеть, которая может соединять более двух маршрутизаторов, в которой предусмотрена аппаратная поддержка широковещания и в которой один пакет, переданный каким-либо маршрутизатором принимается всеми маршрутизаторами, подключенными к этой сети. К сетям с поддержкой широковещания относятся Ethernet, Token Ring и FDDT. OSPF-сообщения, передаваемые в таких сетях используют IP-адроса групповой рассылки. Point-to-Point (Точка-точка). Сеть, которая может соединять только два маршрутизатора. Выделенные WAN-каналы вроде DDS (Dataphone Digital Service) и ТCarrier являются сетями типа «точка-точка». OSPF-сообщения, передаваемые в таких сетях, используют IP-адреса групповой рассылки. Non-Broadcast Multiple Access (NBMA). Сеть, которая может соединять более двух маршрутизаторов, но без аппаратной поддержки широковещания. Сети с множественным доступом без широковещания (Non-Broadcast Multiple Access, NBMA) это Х.25, Frame Relay и ATM. Поскольку в такой сети групповые OSPF-сообщения не достигают всех OSPF-маршрутизаторов, OSPF следует настроить па передачу сообщений непосредственно на IP-адреса маршрутизаторов. О передаче OSPF-пакетов в этих сетях см. раздел «Передача OSPF-пакетов в сетях OSPF» далее в этой главе.
ГЛАВА 3
Одноадресная IP-маршрутизация
73
Примечание Применение OSPF по непостоянным WAN-каналам (например, по аналоговым телефонным линиям или ISDN) не рекомендуется.
Синхронизация LSDB через механизм соседства Алгоритмы маршрутизации на основе состояния каналов связи опираются на синхронизацию информации LSDB между маршрутизаторами в автономной системе. Маршрутизатор должен проверять свою синхронизацию не со всеми маршрутизаторами в автономной системе, а только со своими соседями. Отношения между соседними маршрутизаторами, устанавливаемые в целях синхронизации LSDB, называются соседством (adjacency). Отношения соседства необходимы для компиляции корректных записей в LSDB перед вычислением дерева SPF и созданием записей в таблице маршрутизации. Ошибки при установлении соседства являются одной из основных проблем при конвергенции межсетевых сред с OSPF. Подробнее об устранении проблем с установлением соседства OSPF см. раздел «Выявление и устранение проблем с OSPF» далее в этой главе.
Установление отношений соседства При инициализации OSPF-маршрутизатор периодически посылает OSPF-т акет Hello. Этот пакет содержит такую конфигурационную информацию, как код маршрутизатора и список соседних маршрутизаторов, от которых данный маршрутизатор уже получил пакет Hello. Изначально в списке соседей в OSPF-пакете H e l l o никаких записей нет. Инициализирующийся OSPF-маршрутизатор также прослушивает пакеты Hello от соседних маршрутизаторов. Из поступающих пакетов Hello on определяет конкретный маршрутизатор (или маршрутизаторы), с которым надо установить отношения соседства. Отношения соседства устанавливаются с главным (designated router, DR) и дублирующим главным маршрутизатором (backup designated router, BDR), которые указываются во входящих пакетах Hello. О главных и дублирующих глазных маршрутизаторах будет рассказано чуть позже. Чтобы установить отношения соседства, маршрутизаторы описывают содержимое своих LSDB, посылая последовательность пакетов описания базы данных (Database Description packets). Это процесс обмена информацией баз данных (Database Exchange Process), в ходе которого два соседних маршрутизатора устанавливают отношения «ведущий-ведомый» (master/slave). Содержимое LSDB одного из маршрутизаторов подтверждается при приеме соседним маршрутизатором. Каждый маршрутизатор сравнивает свои LSA с LSA соседа и отмечает, какие LSA нужно запросить от соседа, чтобы синхронизировать LSDB. Отсутствующие или более актуальные LSA запрашиваются в пакетах Link Stale Request. В ответ посылаются пакеты Link State Update, и их прием подтверждается. Когда приходя т все ответы на все запросы о состоянии каналов связи ( L i n k Stale Requests) обоих маршрутизаторов, считается, что LSDB соседних маршрутизаторов полностью синхронизированы и отношения соседства между ними установлены. Установив отношения соседства, каждый маршрутизатор периодически посылает пакет Hello, информируя соседа о своем присутствии в сети. Отсутствие пакетов Hello от соседа рассматривается как его отключение,
74
ЧАСТЬ 1
Маршрутизация
Если происходит такое событие, как отключение канала связи или маршрутизатора, либо добавление новой сети, которое изменяет LSDB на одном из маршрутизаторов, LSDB смежных маршрутизаторов больше не являются синхронизированными. Тогда маршрутизатор, чья LSDB изменилась, посылает своему соседу пакеты Link State Update. Прием этих пакетов должен быть подтвержден. После обмена информацией LSDB соседних маршрутизаторов вновь становятся синхронизированными. Состояния отношений соседства В процессе установления отношений соседства смежные маршрутизаторы последовательно меняют свое состояние (таблица 3-2). Таблица 3-2. Состояния отношений соседства для смежных маршрутизаторов Состояние соседства Описание Down Attempt Init 2-Way ExStart Exchange Loading Full
Начальное состояние. От соседнего маршрутизатора еще не получено никакой информации. Несмотря на попытки связаться с соседом, никакой информации пока не получено (только в сетях NBMA). От соседа получен пакет Hello, но в списке соседей в этом пакете данный маршрутизатор отсутствует. От соседа получен пакет Hello, и в списке соседей в этом пакете данный маршрутизатор присутствует. Идет согласование ролей ведущего и ведомого для процесса Database Exchange Process. Это первая фаза установления отношений соседства. Маршрутизатор посылает своему соседу пакеты Database Description, Маршрутизатор посылает пакеты Link State Request своему соседу, запрашивая недостающие или более актуальные LSA. LSDB соседних маршрутизаторов синхронизируются, и это вторая фаза установления отношений соседства. Теперь между ними существуют полнопенные отношения соседства.
^ Чтобы просмотреть состояние отношений соседства маршрутизаторов: •
В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IP Routing (IP-маршрутизация), щелкните правой кнопкой мыши OSPF (OSPF) и выберите команду Show Neighbors (Отобразить соседей). Вы увидите список соседних маршрутизаторов в окне OSPF Neighbors (Соседи OSPF).
Из-за выборов главных и дублирующих главных маршрутизаторов устанавливать отношения соседства с каждым OSPF-маршрутизатором не требуется. Для соседних маршрутизаторов, установивших полноценные отношения соседства, в колонке State (Состояние) должно появиться слово Full.
Конфигурационные параметры соседства Распространенная проблема OSPF заключается в том, что отношения соседства, которые должны быть установлены между двумя соседними маршрутизаторами, установить не удается. Формирование отношений соседства требует совпадения следующих параметров двух маршрутизаторов.
ГЛАВА 3
Одноадресная IP-маршрутизация
75
• Если применяется аутентификация, соседние маршрутизаторы должны использовать один и тот же тип аутентификации. •
Если включена аутентификация по простому паролю, соседние маршрутизаторы должны использовать одинаковые пароли.
•
Должен быть одинаковым параметр Hello Interval (Интервал приветствия), определяющий периодичность посылки пакетов Hello. По умолчанию он равен 10 секундам*,
• Должен быть одинаковым параметр Dead Interval (Интервал исчезновения) — срок ожидания пакетов Hello. Если по истечении этого времени не получено ни одного пакета Hello, смежный маршрутизатор считается отключенным. По умолчанию этот параметр равен 40 секундам**. В RFC рекомендуется, чтобы он был о 4 раза больше интервала приветствия. • Должен быть одинаковым параметр Area ID (Код области), идентифицирующий область (автономной системы), к которой подключен маршрутизатор. Этот параметр настраивается на каждом интерфейсе маршрутизатора отдельно. • Два соседних маршрутизатора должны прийти к соглашению о том, находятся они в изолированной области (stub area) или нет. Об изолированных областях см. раздел «Изолированные области» далее в этой главе. Коды двух соседних маршрутизаторов не должны совпадать, иначе установить отношения соседства не удастся. Коды маршрутизаторов должны быть уникальны в пределах автономной системы. Дублирующиеся коды не позволят установить отношения соседства.
Добавление маршрутизатора в межсетевую среду OSPF, находящуюся в состоянии конвергенции Когда в существующей межсетевой среде OSPF, достигшей состояния конвертации, инициализируется новый OSPF-маршрутизатор, LSA для этого маршрутизатора нужно распространить на все OSPF-маршрутизаторы в межсетевой среде через механизм растекания. Получив новую LSA, каждый маршрутизатор должен выполнить вычисления по алгоритму Дейкстры, пересчитать дерево SPF и создать новые записи в таблице маршрутизации. После того как будут обновлены таблицы маршрутизации па всех маршрутизаторах, межсетевая среда вернется в состояние конвергенции. Рис. 3-15 иллюстрирует процесс конвергенции после появления в межсетевой с^еде OSPF нового маршрутизатора и распространение информации о новом соседстве. 1. Маршрутизатор R1 инициализируется и начинает периодически посылать пакеты Hello через WAN-канал типа «точка-точка». Маршрутизатор R2 тоже посылает пакеты Hello по этому каналу. R1 и R2 решают установить отношения соседства.
* По крайней мере в русской версии Windows 2000 Server интервал приветствия по у молча шю равен 15 секундам. — Прим. перев. ** По крайней мере в русской версии Windows 2000 Server интервал исчезновения по умолчанию равен 60 секундам. — Прим. перев.
76
ЧАСТЬ 1
Маршрутизация
2. R1 и R2 обмениваются пакетами Database Description. Пакет Database Description от R1 содержит информацию только о самом маршрутизаторе R1, а аналогичный пакет от R2 — самые последние LSA всех маршрутизаторов в межсетевой среде (кроме R1), 3. R1 посылает R2 пакет Link State Request, запрашивая LSA всех маршрутизаторов т; межсетевой среде. В ответ R2 посылает R1 запрошенные LSA в виде пакетов Link Stale Update. 4. R2 посылает R1 пакет Link State Request, запрашивая его LSA. В ответ R1 посылает R2 свой LSA в виде пакета Link State Update. Теперь R1 и R2 располагают синхронизированными LSDB. Принимая LSA, маршрутизаторы R1 и R2 вычисляют свои деревья SPF и формируют записи в таблицах маршрутизации. 5. После синхронизации с R1 маршрутизатор R2 посылает пакет Link State Update всем остальным смежным OSPF-маршрутизаторам (R3 и R4). Пакет Link State Update содержит LSA, полученную от R1. Принимая LSA от R2, маршрутизаторы R3 и R4 вычисляют свои деревья SPF и формируют записи в таблицах маршрутизации. 6. R3 и R4 распространяют эту информацию своим смежным маршрутизаторам (R5 и R6) отдельным пакетом Link State Update. Принимая се, маршрутизаторы R5 и R6 вычисляют свои деревья SPF и формируют записи в таблицах маршрутизации. - Отношения соседства устанавливаются между маршрутизаторами R1 и П2
- Маршрутизатор R2 распространяет новую LSA на маршрутизаторы Р З и R4
i *
Маршрутизатор R3 распространяет новую LSA на маршрутизатор R5, а маршрутизатор R4 — на маршрутизатор R6 R5
Рис. 3-15. Распространение информации о новом соседстве Так межсетевая среда OSPF возвращается п состояние конвергенции после добавления R1 и связанной с ним сети.
ГЛАВА 3
Одноадресная IP-маршрутизация
77
Главный маршрутизатор При использовании канала связи типа «точка-точка» (например, выделенного WAN-капала) отношения соседства должны быть установлены между двумя маршрутизаторами — на каждой стороне канала сняли. Однако в сетях с множественным доступом (в широковещательных или NBMA-сетях) установление отношении соседства следует контролировать. Возьмем для примера широковещательную есть с шестью OSPF-маршрутизаторами. Без контроля каждый маршрутизатор мог бы установить отношения соседства со всеми остальными маршрутизаторами, что дало бы в итоге 15 соседств. В широковещательной сети с п маршрутизаторами, возможно установление максимум п*(п-1)/2 соседств. Число соседств масштабируется как О(и-). Кроме того, в такой сети генерировалось бы слишком много лишнего трафика но мере тою, как каждый маршрутизатор пытался бы синхронизироваться со всеми смежными маршрутизаторами. Чтобы решить эту проблему масштабирования, в сетях с множественным доступом обязательно проводятся выборы главного маршрутизатора (Designated Router, DR). DR устанавливает отношения соседства со всеми остальными маршрутизаторами в этой сети. В широковещательной сети с п маршрутизаторами нужно устаноьить всего (я—1) соседств. Поскольку OR является соседом всех маршрутизаторов, он выступает в роли концентратора для распространения информации о состоянии каналов связи и для синхронизации LSDB. DR выбирается путем обмена OSPF-пакетами Hello. Каждый такой пакет указывает текущий DR (если он выбран), код и приоритет маршрутизатора, отправившего данный пакет. Приоритет маршрутизатора (Router Priority) — это зависимы!! от конкретного интерфейса конфигурационный параметр OSPF, используемый при выборах DR. На эту роль избирается маршрутизатор с наивысшим приоритетом. По умолчанию приоритет маршрутизатора равен 1. Если маршрутизатору присвоен нулевой приоритет, он никогда не станет DR. В случае нескольких маршрутизаторов с одинаковым наивысшим приоритетом на роль DR избирается тот из лих, чей код (идентификатор) больше. Внимание Приоритеты следует назначать так, чтобы по крайней мере у одного маршрутизатора в сети с множественным доступом (широковещательной или NBMA) был приоритет, равный или больший 1. Если все маршрутизаторы в сети с множественным доступом сконфигурированы с нулевым приоритетом, ни один из ним не станет DR, и не будет установлено ни одного соседства. Л без отношений соседства синхронизировать LSDB и пропускать через эту сеть транзитный трафик нельзя. Примечание Если DR уже избран в сети, инициализация в той же сети маршрутизатора с более высоким приоритетом не приводит к новым выборам DR.
Главные маршрутизаторы в широковещательных сетях Рис. 3-16 иллюстрирует работу DR в широковещательной сети. Без DR в этой сети с четырьмя маршрутизаторами могло бы образоваться шесть соседств, а лишние соседства приводят к пустой трате локальных и сетевых ресурсов. Благодаря DR для синхронизации LSDB достаточно всего три соседства.
78
ЧАСТЬ 1
Маршрутизация
Главный маршрутизатор (DR)
Соседства
• i
Рис. 3-16. Главный маршрутизатор в широковещательной сети
Главные маршрутизаторы в NBMA-сетях В NBMA-сетях вроде Frame Relay с центрально-лучевой топологией главным должен быть маршрутизатор-концентратор, так как только он может взаимодействовать со всеми остальными маршрутизаторами. Чтобы гарантировать назначение маршрутизатора-концентратора на роль главного маршрутизатора (DR), установите его приоритет не менее 1. А чтобы ни один лучевой маршрутизатор не стал DR, присвойте им нулевые приоритеты. Главный маршрутизатор в сети Frame Relay показан на рис. 3-17.
Дублирующий главный маршрутизатор DR действует в качестве точки централизованного распространения изменений в топологии сети с множественным доступом. Если DR становится недоступным, должны быть установлены новые отношения соседства с новым DR. Пока идет установление отношений соседства и конвергенция межсетевой среды, возможна временная потеря соединений для транзитного трафика.
ГЛАВА 3
Одноадресная IP-маршрутизация
79
Главный маршрутизатор (DR) R2 Приоритет=0
R1 Приоритет=1
R3
Приоритет^
Виртуальные цепи Frame Relay R4 Приоритет=0
Соседства
Рис. 3-17. Главный маршрутизатор в сети Frame Relay Чтобы предотвратить эту проблему, связанную с временным отсутствием DR, в каждой сети с множественным доступом выбирается дублирующий главный маршрутизатор (Backup Designated Router, BDR). Как и DR, BDR имеет отношения соседства со всеми маршрутизаторами в сети. Когда DR выходит из строя, BDR немедленно становится DR, посылая всем смежным с ним маршрутизаторам LSA, в которых объявляет о своей новой роли. Так что остается лишь очень короткий промежуток времени, в течение которого может быть прервана передача транзитного трафика: те несколько мгновений, когда BDR берет на себя роль DR. Как и DR, BDR избирается путем обмена пакетами Hello. Каждый такой пакет содержит поле, определяющее BDR в сети. Если BDR в нем не указан, дублирующим главным маршрутизатором становится маршрутизатор с наивысшим приоритетом, не выбранный на роль DR. Если таких маршрутизаторов несколько, на роль BDR избирается тот из них, чей код (идентификатор) больше.
Состояния интерфейса После установления отношений соседства каждый OSPF-интсрфейс может находиться в одном из нескольких состояний (таблица 3-3), Таблица 3-3. Состояния интерфейсов маршрутизаторов, установивших отношения соседства Состояние интерфейса
Описание
Down
Начальное состояние интерфейса; обмена пакетами Hello еще не было Интерфейс с сетью аппаратно или программно замкнут на себя (looped back) (внутренне сконфигурирован так, что никакие пакеты не посылаются) Интерфейс посылает и принимает пакеты Hello, чтобы определить DR и BDR для сети Интерфейс образовал соседство со смежным интерфейсом в сети типа «точка-точка» или через виртуальный канал (см. след, стр.)
Loopback Waiti ng Point-to-Point
80
ЧАСТЬ 1
Таблица 3-3.
Маршрутизация
(продолжение)
Состояние интерфейса
Описание
Other
Интерфейс подключен к сети с множественным доступом и не является ни DR. ни BDR Designated Router Интерфейс якляется DR для подключенной сети Backup Designated Router Интерфейс является BDR для подключенной сети
Чтобы просмотреть состояние какого-либо OSPF-интерфейса на OSPF-маршрути:тторе Windows 2000, запустите оснастку Routing and Remote Access (Маршрутизация и удаленный доступ), раскройте узел IP Routing (IP-маршрутизация) и щелкните OSPF (OSPF). В правой секции окна оснастки появится список OSPF-интерфейсов. В колонке State (Состояние) будут перечислены текущие состояния всех интерфейсов. На основе этих данных Вы определите главный и дублирующий главный маршрутизаторы в сети.
Передача OSPF-пакетов в сетях OSPF Адресация пакетов OSPF-маршрутнзаторами зависит от типа сети OSPF. Широковещательные сети, OSPF-маршрутизаторы используют следующие два IP-адреса, зарезервированные для групповой рассылки. •
224.0.0.5 (AHSPFRouters). Предназначен для рассылки OSPF-сообщений всем OSPF-маршрутизаторам в одной сети. Адрес AHSPFRouters используется для пакетов Hello. DR и BDR используют этот адрес для передачи пакетов Link State Update и Link State Acknowledgment.
•
22^1.0.0.6 (AllDRouters). Предназначен для рассылки OSPF-сообщений DR и BDR в одной сети. Все OSPF-маршрутизаторы, кроме DR. используют этот адрес при передаче DR пакетов Link State Update и Link State Acknowledgment.
Сети типа «точка-точка». Routers (224.0.0.5).
Для всех OSPF-сообщений используется адрес A11SPF-
NBMA-сети. Такие сети не поддерживают групповую рассылку. Поэтому IP-адресом назначения любого пакета Hello или Link State является конкретный IP-адрес конкретного соседа. IP-адрес соседа представляет собой обязательную часть конфигурации OSPF в NBMA-сетях.
Области OSPF В очень крупной автономной системе с большим числом сетей каждый OSPF-маршрутизатор должен хранить LSA всех остальных маршрутизаторов в своей LSDB. Поэтому размер LSDB па каждом маршрутизаторе в большой автономной системе весьма велик. SPF-вычисления большой LSDB могут потребовать значительных ресурсов. Кроме того, полученная в результате таблица маршрутизации может оказаться крайне объемной, так как в ней должен быть записан маршрут к каждой сети в автономной системе. Чтобы уменьшить размер LSDB и сократить нагрузку на вычислительные мощности при формировании дерева SPF и таблицы маршрутизации, OSPF позволяет разбивать автономную систему на области (areas) — непрерывные группы сетей. Области идентифицируются 32-разрядным параметром Area ID (Код области), который выражается и точечно-десятичной нотации.
ГЛАВА 3 Одноадресная IP-маршрутизация
81
Код области — уто административный идентификатор; он не имеет никакого отношения к IP-адресу или идентификатору сети. Если все сети внутри области соответствуют одному идентификатору сети, включающему идентификаторы подсетей, то для удобства управления код области можно приравнять этому идентификатору сети. Например, если область содержит все подсети IP-сети 10.1.0.0, код этой области может быть установлен равным 10.1.0.0.
Уменьшение размера LSDB Чтобы свести к минимуму размер LSDB на каждом маршрутизаторе, LSA для сетей и маршрутизаторов области распространяются только в пределах этой области и не попадают к маршрутизаторам за ее пределами. Каждая область становится с\юим доменом состояний каналов связи (link state domain) с собственной LSDB. Если маршрутизатор соединен с несколькими областями, на нем хранится несколько LSDB и деревьев SPE А его таблица маршрутизации объединяет в себе записи таблиц маршрутизации для всех деревьев SPF, а также статические маршруты, маршруты, сконфигурированные SNMP, и маршруты, полученные по другим протоколам маршрутизации.
Уменьшение размера таблицы маршрутизации Для сокращения числа записей в таблицах маршрутизации OSPF-маршрутизаторов сети, находящиеся внутри области, могут объявляться за ее пределами с суммированием маршрутов. Так, на рис. 3-18 маршрутизатор па границе области O.O.Ci.l, также называемый граничным маршрутизатором области (area border router, AB]i), объявляет сводную информацию о всех сетях внутри области 0.0.0.1 в виде пар [адрес назначения, маска сети] граничным маршрутизаторам областей 0.0.0.2 и 0.0.0.3. Благодаря суммированию маршрутов (route summarization) топология области (сети и цена использования путей к ним) скрывается от остальной части автономной системы. Автономная система
Область 0.0.0.2 Область 0.0.0.1
R1 Область 0.0.0.0,
нг
ОбластьО.0.0.3 R3
Рис, 3-18. Автономная система и ее области 4 Зак. 3343
82
ЧАСТЬ 1
Маршрутизация
Когда топология области скрыта, остальная часть автономной системы защищается от варьирования маршрутов (route flapping) — событий, связанных с появлением или исчезновением отдельных сетей. Если появляется какая-то сеть, это событие распространяется как пакет Link State Update и по соседским связям попадает на все маршрутизаторы внутри области. Но, поскольку сети внутри области объявляются за ее пределами с суммированием маршрутов, пакет Link State Update не пересекает границы этой области. Бы можете просмотреть текущие области OSPF в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ), щелкнув правой кнопкой мыши OSPF (OSPF) и выбрав команду Show Areas (Отобразить области).
Магистральная область Межсетевая среда OSPF — разбита она на области или нет — всегда имеет по крайней мере одну область, называемую магистральной (backbone area). Для нее зарезервирован код области 0.0.0.0. Из-за этого ее иногда называют областью 0. Магистральная область действует как концентратор для межобластного транзитного трафика и для распространения информации о маршрутах между областями. Межобластной трафик (inter-area traffic) направляется сначала в магистральную область, затем — в область назначения и в конечном счете доставляется хосту-получателю, который находится в области назначения (см. также раздел «Маршрутизация между областями» далее в этой главе). Каждый маршрутизатор в магистральной области также объявляет остальным маршрутизаторам в этой области суммированные в пределах своих областей маршруты. Эти оповещения распространяются на маршрутизаторы областей. Таким образом, таблица маршрутизации на каждом маршрутизаторе в любой из областей отражает маршруты, доступные в пределах данной области, и маршруты, соответствующие суммированным оповещениям от ABR остальных областей автономной системы. Например, на рис. 3-18 маршрутизатор R1 объявляет обо всех маршрутах в области 0.0.0.1 всем магистральным маршрутизаторам (R2 и R3) с использованием сводного оповещения (summary advertisement). R1 принимает сводные оповещения от R2 и R3. R1 сконфигурирован на передачу суммированных маршрутов для области 0.0.0.0. Несмотря на механизм растекания, R1 распространяет информацию о суммированных маршрутах всем маршрутизаторам в области 0.0.0.1. При расчете таблиц маршрутизации каждый маршрутизатор в области 0.0.0.1 учитывает суммированные маршруты из областей 0.0.0.0, 0.0.0.2 и 0.0.0.3.
Типы OSPF-маршрутизаторов Когда автономная система OSPF подразделяется на области, маршрутизаторы относятся к одной или более категориям, определенным в таблице 3-4. Таблица 3-4. Типы OSPF-маршрутизаторов Тип маршрутизатора Внутренний маршрутизатор (internal router)
Описание Маршрутизатор, все интерфейсы которого подключены к одной области. На каждом внутреннем маршрутизаторе хранится одна LSDB.
ГЛАВА 3 Таблица 3-4.
Одноадресная IP-маршрутизация
83
(продолжение)
Тип маршрутизатора
Описание
Граничный маршрутизатор области (area border router, ABR)
Маршрутизатор, интерфейсы которого подключены к разным областям. На ABR хранится несколько LSDB — по одной на каждую подключенную область. Маршрутизатор, один из интерфейсов которого подключен к магистральной области. К маршрутизаторам этого типа относятся все ABR и внутренние маршрутизаторы магистральной области. Маршрутизатор, который обменивается информацией о маршрутах с источниками за пределами данной автономной системы OSPF. ASBR оповещают о внешних маршрутах через автономную систему OSPF
Магистральный маршрутизатор (backbone router), или маршрутызатор магистральной области (router of backbone area) Граничный маршрутизатор автономной системы (AS boundary router, ASBR)
Маршрутизация между областями Маршрутизация внутри области осуществляется OSPF-маршрутизаторами с использованием кратчайшего пути к сети назначения. Поскольку маршруты внутри области тте суммируются, у каждого маршрутизатора имеется маршрут к каждой сети внутри сто области (или областей). Маршрутизация между областями происходит так. 1. Маршрутизаторы внутри области-источника пересылают пакет ближайшему ABR но кратчайшему пути. 2. Магистральные маршрутизаторы пересылают пакет по кратчайшему пути ближайшему ABR, подключенному к области, которая включает IP-адрес хоста получателя. 3. Маршрутизаторы внутри области, которая включает IP-адрес хоста-получателя, пересылают пакет этому хосту-получателю по кратчайшему пути, На рис. 3-19 пакет проходит через маршрутизаторы области 0.0.0.1 и попадает на R1, один из маршрутизаторов магистральной области. Далее пакет последовательно пересылается маршрутизаторами магистральной области (область 0.0.0.0) па маршрутизатор R2, И, наконец, пакет попадает хосту-получателю через маршрутизаторы области 0.0.0.2. Примечание OSPF-маршрутизаторы принимают решения о маршрутизации на основе не кодов областей, а записей в таблице IP-маршрутизации. В примере маршрутизации между областями, показанном на рис. 3-19, магистральные маршрутизаторы не пересылают пакет в область 0.0.0.2 явным образом. Они посылают его по кратчайшему пути на маршрут, который лучше всего подходит для указанного в пакете IP-адреса назначения.
84
ЧАСТЬ 1
Маршрутизация
Автономная система
Область 0.0.0.2
Хостполучатель
Хостотправитель
R1 (ABR) ^ Область 0.0.0.0
R2 (ABR)
Область 0.0.0.3
Рис. 3-19. Маршрутизация между областями в OSPF
Виртуальные каналы Области можно определить так, чтобы в них не было ABR, физически подключенного к магистральной области. Соединение с магистральной областью остается возможным за счет создания виртуального капала (virtual link) между магистральной областью и любой другой областью. Виртуальные каналы создаются между любыми двумя маршрутизаторами, имеющими интерфейс с общей областью, отличной от магистральной. Такая область называется транзитной (transit area). В транзитной области должен быть ABR, подключенный к магистральной области. Виртуальные каналы нельзя создавать через несколько транзитных областей. Виртуальный канал — это логический канал с кратчайшим путем между ABR области, отличной от магистральной, и магистральным ABR транзитной области, По виртуальному каналу устанавливаются отношения виртуального соседства и происходит обмен информацией о маршрутах. Так же, как и в случае физических соседств, установление виртуального соседства требует совпадения параметров двух маршрутизаторов виртуального канала (паролей, интервалов приветствия и исчезновения, и т. д.). На рис. 3-20 в области 0.0.0.3 нет маршрутизатора, физически подключенного к магистральной области 0.0.0.0. Поэтому виртуальный канал создается через транзитную область 0.0.0.2 между маршрутизаторами R2 и R3. Эти маршрутизаторы называются соседями по виртуальному каналу (virtual l i n k neighbors),
ГЛАВА 3
Одноадресная IP-маршрутизация
85
Автономная система
Область 0.0.0.0 Область 0.0.0.1
Виртуальный канал .t.,<'<
Область 0.0.0.3
Область 0.0.0.2 Транзитная область
\\:
Рис. 3-20. Виртуальный канал OSPF
Конфигурирование виртуальных каналов Чтобы настроить виртуальный канал, воспользуйтесь оснасткой Routing and Remote Access и сконфигурируйте виртуальный интерфейс в свойствах протокола маршрутизации OSPF на каждом маршрутизаторе — соседе по виртуальному каналу. Для этого задайте: • параметр Area ID (Код области) транзитной области для виртуального канала; • параметр Router ID (Код маршрутизатора) для соседа по виртуальному каналу; • такие параметры соседства, как Retransmit Interval (Интервал повторной передачи), Hello Interval (Интервал приветствия), Dead Interval (Интервал исчезновения) и Password (Пароль). Параметры Hello Interval, Dead Interval и Passw ird двух маршрутизаторов на каждой стороне виртуального канала должны совпадать, чтобы можно было установить отношения соседства. Параметр Retrans n i t Interval определяет, сколько времени OSPF-маршрутизатор будет ждать перед повторной передачей пакетов Link State. ^ Чтобы просмотреть виртуальные каналы: • В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IP Routing (IP-маршрутизация), щелкните правой кнопкой мыши OSPF (OSPF) и выберите команду Show Virtual Interfaces (Отобразить виртуальные интерфейсы). В появившемся окне Virtual Interfaces (Виртуальные интерфейсы OSPF) будут показаны все сконфигурированные виртуальные интерфейсы и их состояние.
86
ЧАСТЬ 1
Маршрутизация
Внешние маршруты Таковым считается любой маршрут, не находящийся внутри автономной системы OSPF. Внешними могут быть маршруты: •
других протоколов маршрутизации, например RIP for IP (vl и v2), EGP или BGP; • статические; • заданные на маршрутизаторе через SNMP. Информация о внешних маршрутах распространяется по всей автономной системе OSPF через один или несколько ASBR. ASBR оповещает о доступности внешних маршрутов серией LSA, содержащих эти маршруты. Такие LSA растекаются по всей автономной системе (кроме изолированной области) и становятся частью дерева SPF и таблиц маршрутизации. Трафик во внешние сети перенаправляется внутри автономной системы с использованием кратчайшего пути к ASBR. Автономная система с ASBR и внешними маршрутами показана на рис. 3-21.
Автономная система
Внешние маршруты Область 0.0.0.1
. Область 0.0.0.2
Область 0.0.0.0 Область 0.0.0.3
Рис. 3-21. Внешние маршруты OSPF
Фильтры внешних маршрутов По умолчанию OSPF-маршрутизаторы, выступающие в роли ASBR, импортируют и объявляют все внешние маршруты. Возможно, Вы захотите фильтровать внешние маршруты, чтобы защитить автономную систему от получения некорректной информации или попыток умышленного нанесения ущерба. В случае маршрутизатора Windows 2000 внешние маршруты фильтруются на ASBR по источникам или индивидуальным маршрутам. Вы можете настроить ASBR на прием или игнорирование маршрутов и.ч определенных внешних источников, например протоколов маршрутизации (RIP v2), или из других источников (статические маршруты или SNMP). Вы можете также настроить ASBR на прием или отклонение определенных маршрутов, сконфигурировав одну или несколько нар [адрес назначения, маска сети].
ГЛАВА 3 Одноадресная IP-маршрутизация
87
Комбинация таких фильтров, настроенных на ASBR, гарантирует, что автономная система OSPF будет принимать только корректные внешние маршруты из лоьеряемых источников.
ASBR и маршруты по умолчанию В отсутствие фильтров маршрутизатор, сконфигурированный как ASBR, оповещает обо всех внешних маршрутах, в том числе о собственном статическом маршруте по умолчанию. Этот маршрут по умолчанию должен быть корректен для всех OSPF-маршрутизаторов в Вашей автономной системе. Маршрут по умолчанию, указывающий па другой маршрутизатор в автономной системе, недопустим. Ксли на маршрутизаторе, используемом как основной шлюз, окажется маршрут по умолчанию, в котором в качестве следующего перехода указан IP-адрес этого шлюза, то пакеты, пересылаемые с использованием маршрута по умолчанию, будут отбрасываться на этом маршрутизаторе. Если маршрут по умолчанию правилен не для всех OSPF-маршрутизаторов, его не следует объявлять. В корректном маршруте по умолчанию в качестве следующего перехода должен быть указан адрес шлюза, внешнего для автономной системы, Избежать этой проблемы с маршрутом по умолчанию можно двумя способами, 1. Не настраивать основной шлюз на ASBR. 2. Если же на ASBR обязательно должен быть основной шлюз, создайте филяр внешних маршрутов OSPF для отфильтровывания собственного маршрута по умолчанию (адрес назначения 0.0.0.0 с маской сети 0.0.0.0).
Изолированные области Чтобы еще больше сократить объем информации о маршрутах, передаваемой в области, OSPF позволяет использовать изолированные области (stub areas). Изолированная область может содержать единственную точку входа и выхода (один AHR) или несколько ABR, когда адреса назначения по внешним маршрутам достижимы с использованием любого из ABR. В случае изолированной области с несколькими ABR внешние маршруты объявляются ASBR, который расположен за пределами этой области. Внешние маршруты автономной системы не передаются в изолированную область и не распространяются по ней. Маршрутизация во все внешние сети осуществляется в изолированной области через маршрут по умолчанию (адрес назначения 0.0.0.0 с маской сети 0.0.0.0). Таким образом, для перенаправления на любые внешние по отношению к автономной системе адреса в таблицах маршрутизации на маршрутизаторах изолированной области используется единственная запись. Для создания маршрута по умолчанию ABR изолированной области объявляет такой маршрут в этой области. Информация о маршруте по умолчанию распространяется на все маршрутизаторы внутри изолированной области, но не пересекае' ее границ. Этот маршрут используется маршрутизаторами в изолированной области для любых IP-адресов назначения, находящихся за пределами автономной области. Например, область 0.0.0.3 на рис. 3-22 сконфигурирована как изолированная, петому что весь внешний трафик проходит через единственный ABR этой области маршрутизатор R3. Последний распространяет внутри области 0.0.0.3 маршрут по умолчанию, а не информацию о внешних сетях.
88
ЧАСТЬ 1
Маршрутизация
Внешние маршруты Автономная система
ASBR
Область 0.0.0.2 Область 0.0.0.1
Область 0.0.0.0 Область 0.0.0.3
i '
Рис. 3-22. Изолированные области OSPF Все маршруты в изолированной области должны быть настроены так, чтобы они не вызывали импорта или растекания маршрутов, внешних по отношению к автономной системе, внутри этой области. Поэтому все параметры, относящиеся к областям, для всех интерфейсов маршрутизатора внутри изолированной области, должны быть сконфигурированы применительно к данной области. Находится интерфейс маршрутизатора в изолированной области или нет, косвенно указывается в специальном битовом флаге — Е-бите* (E-bit) OSPF-пакета Hello. Если Е-бит равен 1, маршрутизатору разрешено принимать и распространять внешние маршруты, а если он равен 0 — запрещено. Перед установлением отношений соседства маршрутизаторы, принимая пакеты Hello, проверяют, подходит ли в них состояние Ебита к их конфигурации. Изолированные области накладывают следующие ограничения: • •
при настройке виртуальных каналов нельзя использовать изолированную область в качестве транзитной; в изолированной области нельзя размещать ASBR.
Изолированные области, как и определено в RFC, относящихся к OSPF, сворачивают все внешние маршруты в единый маршрут по умолчанию. Таким образом, таблица маршрутизации любого маршрутизатора внутри изолированной области содержит внутренние (intra-агеа routes) и межобластные маршруты (inter-area routes), а также маршрут по умолчанию. Кроме того, маршрутизатор Windows 2000 поддерживает сворачивание всех маршрутов, отличных от внутренних, в единый маршрут
Название этого бита образовано от «external mules». — Прим, пврек.
ГЛАВА 3
Одноадресная IP-маршрутизация
89
по умолчанию. Такая область называется полностью изолированной (totally stubby area). Таблица маршрутизации любого маршрутизатора внутри полностью изолированной области содержит только внутренние маршруты и маршрут по умолчанию. В этом случае маршрут по умолчанию суммирует все межобластные и внешние маршруты. Чтобы определить изолированную область на маршрутизаторе Windows 2000, установите в общих свойствах какой-либо области флажки Stub area (Изолированная область) и Import summary advertisements (Импорт итоговых объявлений). А для определения полностью изолированной области на маршрутизаторе Windows 2000 сделайте то же самое, по не устанавливайте флажок Import summary advertisements.
Выявление и устранение проблем с OSPF Если среда OSPF настроена корректно, OSPF-маршрутизаторы получают крат шйшие маршруты от соседних OSPF-маршрутизаторов после конвергенции. Точный список маршрутов, добавляемых OSPF в таблицу IP-маршрутизации, зависит от того, настроены ли области па суммирование своих маршрутов, применяются ли изолированные или полностью изолированные области, используются ли ASBR, включена ли фильтрация маршрутов, а также от ряда других факторов. Большинство проблем с OSPF связано с установлением отношений соседства по физическим или логическим (виртуальным) каналам, Не установив отношение соседства, OSPF-маршрутизаторы не смогут синхронизировать свои LSDB, а это приведет к неправильному отражению ими топологии межсетевой среды. Прочие проблемы с OSPF связаны с отсутствием или некорректностью каких-либо маршрутов в таблицах IP-маршрутизации. Не удается установить отношения соседства •
Сначала убедитесь в том, что два соседних маршрутизатора действительно должны устанавливать отношения соседства. Если других маршрутизаторов, кроме них, в сети нет, отношения соседства должны быть установлены. Если же в сети более двух маршрутизаторов, отношения соседства устанавливаются только с DR и BDR. Если два маршрутизатора уже образовали соседство с DR и BIDR, они никогда не установят отношения соседства друг с другом. В этом случае их состояния соседства должны показываться как 2-way (Двусторонние).
Проверьте доступность соседнего маршрутизатора командой ping и убедитесь, все ли в порядке с базовой поддержкой соединений по IP-адресам и именам. Используйте команду tracert и проследите маршрут к соседнему маршрутизатору. Между соседними маршрутизаторами не должно быть промежуточных маршрутизаторов. • Используйте средства протоколирования OSPF для регистрации ошибок и предупреждений, если установить отношения соседства между маршрутизаторами не удается. Чтобы получить дополнительную информации) о процессах OSPF, включите трассировку для компонента OSPF. Подробнее о трассировке см. i лаву 2 «Служба маршрутизации и удаленного доступа» в этой книге.
•
90
ЧАСТЬ 1
Маршрутизация
• Убедитесь, что в областях разрешена аутентификация и что OSPF-интерфейсы используют одинаковые пароли. Па OSPF-маршрутизаторах под управлением Windows 2000 аутентификация разрешена по умолчанию (при этом предлагается пароль по умолчанию «12345678»). Настройте аутентификацию одинаковым образом на всех соседних OSPF-маршрутизаторах в одной сети. Для другой сети пароль может быть другим. •
Убедитесь, что у маршрутизаторов одинаковые параметры Hello Interval (Интервал приветствия) и Dead Interval (Интервал исчезновения). По умолчанию Hello Interval равен 10 секундам, a Dead Interval — 40 секундам.
• Убедитесь, что маршрутизаторы пришли к соглашению по поводу того, принадлежит ли общая сеть к изолированной области. • Убедитесь, что параметр Area ID (Код области) в свойствах интерфейсов соседних маршрутизаторов одинаков. •
Если маршрутизаторы находятся в NBMA-сети типа Х.25 или Frame Relay и соединение с этой сетью представлено единственным адаптером (а не отдельными адаптерами для каждой виртуальной цепи), их соседи должны быть настроены вручную с использованием одновещательного IP-адреса того соседа (или соседей), которому нужно передавать информацию о состоянии каналов. Кроме того, проверьте значения параметров Router Priority (Приоритет маршрутизатора) — они должны быть таковы, чтобы один из маршрутизаторов мог стать главным в данной сети. • В широковещательных сетях (Ethernet, Token Ring, FDDI) или NBMA-сетях (X.25, Frame Relay) убедитесь, что не у всех маршрутизаторов значение параметра Router Priority равно 0. Минимум у одного маршрутизатора это значение должно быть 1 (или больше) — тогда этот маршрутизатор сможет стать главным в данной сети. • Убедитесь, что фильтрация IP-пакетов не препятствует приему (через входные фильтры) или передаче (через выходные фильтры) OSPF-сообщсний на интерфейсах маршрутизатора, на которых задействован OSPF (он использует IP-протокол 89). •
Убедитесь также, что фильтрация TCP/IP-пакетов не мешает приему OSPF-coобщений на интерфейсах, настроенных на использование OSPF.
Не удается создать виртуальный канал • Проверьте, заданы ли на маршрутизаторах — соседях по виртуальному каналу одинаковые пароли, а также параметры Hello Interval (Интервал приветствия) и Dead Interval (Интервал исчезновения). • Проверьте на каждом маршрутизаторе правильность настройки параметра Router ID (Код маршрутизатора). •
Убедитесь, что оба соседа по виртуальному каналу настроены на одну и ту же транзитную область.
• Б больших межсетевых средах со значительными задержками передачи пакетов по всей транзитной области (round-trip delays across the transit area) убедитесь, что интервал повторной передачи достаточно велик.
ГЛАВА 3
Одноадресная IP-маршрутизация
91
Отсутствие или некорректность QSPF-маршрутов в таблицах маршрутизации •
Если Вам не удается получать суммированные OSPF-маршруты для какой-либо области, убедитесь, что все ABR этой области сконфигурированы с правильными парами [адрес назначения, маска сети], обеспечивающими суммирование маршрутов нужной области.
•
Если Вы получаете как индивидуальные, так и суммированные OSPF-маршруты для какой-либо области, убедитесь, что вес ABR этой области сконфигурированы с правильными парами [адрес назначения, маска сети], обеспечивающими суммирование маршрутов нужной области.
• Если Вы не получаете внешние маршруты от ASBR, проверьте, не слишком ли строги критерии фильтрации источников и маршрутов на ASBR, из-за чего нужные маршруты не распространяются в автономную систему OSPF. Фильтрация внешних источников и маршрутов настраивается па вкладке External Routing (Внешняя маршрутизация) окна свойств протокола маршрутизации OSPF и, оснастке Routing and Remote Access (Маршрутизация и удаленный доступ). • Убедитесь, что все ABR подключены к магистральной области — либо физически, либо логически (с использованием виртуального канала). Следите, чтобы не было маршрутизаторов, действующих «с черного хода» (backdoor routers), т. е. маршутизаторов, которые соединяют две области в обход магистральной,
Агент ретрансляции DHCP Маршрутизатор Windows 2000 является агентом ретрансляции ВООТР, соответствующим RFC 1542. Он ретранслирует DHCP-сообщения между DHCP-клиентами и DHCP-серверами в ранных IP-сетях. В этой роли маршрутизатор Windows 2000 функционирует как DHCP Relay Agent (Агент ретрансляции DHCP). Без агента ретрансляции DHCP в каждой подсети, где есть DHCP-клиенты, пришлось бы установить DHCP-сервер. Агент ретрансляции DHCP принимает ш гроковещательпые DHCP-сообщения от DHCP-клиентов и пересылает их на IP-адреса DHCP-серверов. Ответы от DHCP-сервера посылаются на IP-адрес агента ретрансляции DHCP, который затем пересылает их DHCP-клиенту. Подробнее о DHCP и его реализации в Windows 2000 см. книгу «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server».
DHCP и IP-маршрутизаторы В больших межсетевых IP-средах DHCP-серверы следует разметать в стратегических точках обслуживания DHCP-клиентов нескольких сетей. Для эффективной работы такой конфигурации DHCP-сообщения должны пересекать IP-маршрутизаторы с помощью агента ретрансляции DHCP. Помимо распространения DHCP-сообщений, агент ретрансляции DHCP играет активную роль в регистрации информации, необходимой для настройки DHCP, и помогает адресовать DHCP-сообщения между серверами и клиентами DHCP.
Инициализация DHCP Инициализация DHCP осуществляется DHCP-клиентом, который еще ни разу не арендовал IP-адрес, освободил ранее выделенный ему IP-адрес или получил сооб-
92
ЧАСТЬ 1
Маршрутизация
щение DHCPNack в ответ на попытку возобновить аренду IP-адреса. В процессе инициализации DHCP используется четыре DHCP-сообщения: DHCPDiscover, DHCPOffcr, DHCPRequest и DHCPAck. DHCPDiscover DHCP-клиент посылает сообщение DlICPDiscover, содержащее МАС-адрес этого DHCP-клиента, на IP-адрес ограниченной широковещательной рассылки (255.255.255.255) и адрес широковещания на МАС-уровне. Это сообщение принимает и обрабатывает агент ретрансляции DHCP. Как определено в RFC 1542, агент ретрансляции DHCP может пересылать пакет на ТР-адрес широковещательной, групповой или адресной (одновещательной) рассылки. На практике агенты ретрансляции DHCP пересылают сообщения DHCPDiscover непосредственно на IP-адреса DHCP-серверов (т. е. используют адресную рассылку). Перед пересылкой исходного сообщения DHCPDiscover агент ретрансляции DHCP вносит в него следующие изменения. •
Увеличивает значение поля числа переходов в DHCP-заголовке. Это поле независимо от поля TTL в IP-заголовке и определяет, через сколько сетей данное сообщение DHCPDiscover прошло как широковещательный пакет. При превышении максимального числа переходов сообщение DHCPDiscover «молча» отбрасывается. Максимальное число переходов, используемое агентом ретрансляции в Windows 2000 по умолчанию, равно 4.
•
При необходимости обновляет поле IP-адреса ретрансляции (также известное как поле IP-адреса шлюза) в DHCP-заголовке. Когда DHCP-клиент посылает сообщение DHCPDiscover, в поле IP-адреса ретрансляции содержится значение 0.0.0.0. Если IP-адрес ретрансляции равен 0.0.0.0, агент ретрансляции DHCP записывает IP-адрес интерфейса, по которому было принято данное сообщение DHCPDiscover. Если же IP-адрес ретрансляции имеет другое значение (не 0.0.0.0), агент ретрансляции DHCP не модифицирует его. В поле IP-адреса ретрансляции регистрируется первый интерфейс маршрутизатора на пути передачи сообщения DHCPDiscover.
•
Изменяет IP-адрес источника сообщения DHCPDiscover на IP-адрес интерфейса, через который было принято это широковещательное сообщение.
•
Изменяет IP-адрес получателя сообщения DHCPDiscover на IP-адрес DHCPсервера.
Агент ретрансляции DHCP посылает сообщение DHCPDiscover как адресный IPпакет, а не как широковещательный. Если агент ретрансляции настроен на взаимодействие с несколькими DHCP-серверами, он посылает каждому DHCP-серверу копию сообщения DHCPDiscover. DHCPOfler Отвечая на запрос DHCP-клиента о выделении IP-адреса, DIICP-сервер использует поле IP-адреса ретрансляции следующим образом. • IP-адрес ретрансляции сравнивается (логической операцией AND) с масками подсетей сконфигурированных областей DHCP-сервера, чтобы найти область,
ГЛАВА 3
Одноадресная IP-маршрутизация
93
чей идентификатор сети совпадает с идентификатором сети в IP-адресе ретрансляции. Если совпадение найдено, DHCP-сервср выделяет какой-нибудь IP-адрес из этой области. •
Возвращая предложение клиенту, DHCP-сервер посылает сообщение DHCPOffer на IP-адрес ретрансляции как на IP-адрес получателя.
Однажды полученный агентом ретрансляции DHCP, IP-адрес ретрансляции используется для определения интерфейса, на который следует переслать сообщение DHCPOffer. Далее оно пересылается клиенту с использованием предложенного IPадреса как IP-адреса получателя, а МАС-адреса клиента — как МАС-адреса получателя. DHCPRequesI DHCP-клиент посылает сообщение DIICPRequest, которое, как и DHCPDiscover, содержит МАС-адрес клиента, на IP-адрес ограниченной широковещательной рассылки 255.255.255.255 и адрес широковещания на МАС-уровне. Агент ретрансляции DHCP принимает это сообщение и пересылает его как адресный IP-пакет сконфигурированным DHCP-серверам. DHCPAck Изначально DHCP-сервер посылает сообщение DHCPAck на IP-адрес ретрансляции — так же, как и сообщение DHCPOffer. Когда агент ретрансляции DHCP принимает DHCPAck, он переадресовывает его на предложенный клиенту IP-адрес и его МАС-адрес.
Возобновление аренды после перезагрузки При завершении работы клиент Microsoft DHCP не посылает DHCP-серверу сообщение DHCPRelease. Вместо этого при перезагрузке DHCP-клиент пытается получить тот IP-адрес, который был у него в прошлый раз, и с этой целью он использует сообщения DHCPRequest. и DHCPAck. DHCPRequest Когда клиент Microsoft DHCP перезагружается, он пытается арендовать свои прежний IP-адрес, посылая широковещательное сообщение DHCPRequest. Это сообщение, отправляемое на IP-адрес ограниченной широковещательной рассылки 255.255.255.255 и адрес широковещания на МАС-уровне, содержит МАС-адрес и ранее выделенный клиенту IP-адрес. Агент ретрансляции DHCP принимает ,>то сообщение и обрабатывает его почти так же, как и сообщение DHCPDiscover. Перед пересылкой агент ретрансляции DHCP: • увеличивает счетчик числа переходов в DHCP-заголовке; •
регистрирует IP-адрес интерфейса, по которому было получено данное сообщение DHCPRequest, в поле IP-адреса ретрансляции;
•
заменяет IP-адрес источника IP-адресом интерфейса, по которому было при-тято данное широковещательное сообщение DHCPDiscover;
•
заменяет IP-адрес получателя на адрес DHCP-сервера, записанный в DHOPRequest, и пересылает это сообщение как адресный IP-пакет.
94
ЧАСТЬ 1
Маршрутизация
DHCPAck и DHCPNack DHCP-сервср, получив DHCPRequest, сравнивает идентификатор сети ранее выделенного клиенту IP-адреса с идентификатором сети IP-адреса ретрансляции. •
Если два идентификатора одинаковы и прежний IP-адрес можно вновь выделить DHCP-клиенту, DHCP-сервер изначально посылает DHCPAck на IP-адрес, указанный в поле IP-адреса ретрансляции. Когда агент ретрансляции DHCP получает сообщение DHCPAck, он переадресует его на предложенный IP-адрес и MAC-адрес клиента.
•
Если два идентификатора одинаковы и прежний IP-адрес нельзя вновь выделить DHCP-клиенту, DHCP-ссрвер изначально посылает DHCPNack на IP-адрес, указанный в поле IP-адреса ретрансляции. Когда агент ретрансляции DHCP получает сообщение DHCPNack, он переадресует его на предложенный IP-адрес и МАС-адрес клиента. В этот момент DHCP-клиент должен заново начать процесс получения IP-адреса, послав сообщение DHCPDiscovcr.
• Если два идентификатора не совпадают, значит, DHCP-клиент перемещен в другую подсеть, и DHCP-сервер посылает DHCPNack на IP-адрес, указанный в иоле IP-адреса ретрансляции. Когда агент ретрансляции DHCP получает сообщение DHCPNack, он переадресует его на предложенный IP-адрес и МАС-адрес клиента. В этот момент DHCP-клиент должен заново начать процесс получения IP-адреса, послав сообщение DHCPDiscover.
Выявление и устранение проблем с агентом ретрансляции DHCP Если агент ретрансляции DHCP в Windows 2000 не предоставляет сервисов ретрансляции DHCP-клиентам в сети, проверьте следующее. •
Убедитесь, что интерфейс маршрутизатора Windows 2000, подключенный к той сети, где находятся DHCP-клиенты, добавлен к протоколу маршрутизации DHCP Relay Agent.
•
Убедитесь, что флажок Relay DHCP packets (Ретрансляция DHCP-пакетов) установлен для того интерфс-йеа агента ретрансляции DHCP, который подключен к сети с DHCP-клиентами.
• Убедитесь, что IP-адреса DHCP-серверов, сконфигурированные в глобальных свойствах агента ретрансляции DHCP, корректны для DHCP-серверов в Вашей межсетевой среде. •
С маршрутизатора, на котором работает агент ретрансляции DHCP, запустите утилиту Ping, чтобы проверить возможность соединения с каждым DHCP-cepвсром, сконфигурированным в глобальных свойствах агента ретрансляции. Если Вам не удается связаться с DHCP-серверами, устраните проблемы с поддержкой соединений на участке между маршрутизатором с агентом ретрансляции и DHCP-серверами.
•
Убедитесь, что фильтрация IP-пакетои не препятствует приему (через входные фильтры) или передаче (через выходные фильтры) DHCP-трафика. DHCP-трафик использует UDP-порты 67 и 6Н.
• Убедитесь, что TCP/IP-фильтрация на интерфейсах маршрутизатора не препятствует приему DHCP-трафика.
ГЛАВА 3
Одноадресная IP-маршрутизация
95
NAT Network Address Translator (NAT) (Средство преобразования сетевых адресов)" это IP-маршрутизатор, определенный в RFC 1631 и способный транслировать IPадреса и номера TCP/UDP-портов пакетов в процессе их пересылки. Возьмем для примера сеть малого предприятия со множеством компьютеров, подключенных к Интернету. В нормальной ситуации на малом предприятии каждый компьютер в сети обычно получает общий IP-адрес от провайдера услуг Интернета (Internet Service Provider, ISP). Однако при наличии NAT малое предприятие может использовать частные адреса (как описывается в RFC 1597) и NAT-карту, увязывающую его частные адреса с единственным или несколькими общими IP-адресами, выделяемыми 1SP. Например, если малое предприятие использует частную сеть 10,0.0.0 для своей инграсети, a ISP выделил ему один общий IP-адрес 198.200.200.1, то NAT транслирует (с помощью статических или динамических сопоставлений) все частные IP адреса, принадлежащие сети 10.0.0.0, в общий IP-адрес 198.200.200.1, Когда какой-либо пользователь в интрассти этого предприятия подключается к Интернет-ресурсу, стек IP на компьютере пользователя создает IP-пакет со следующими параметрами в IP- и либо в TCP-, либо н U DP-заголовках (полужирным шрифтом выделены значения, изменяемые NAT): • Destination IP Address (IP-адрес приемника): IP-адрес Интернет-ресурса; • Source IP Address (IP-адрес источника): частный IP-адрес; • Destination Port (Порт приемника): TCP- или LTDP-порт Интернет-ресурса; •
Source Port (Порт источника): TCP- или UDP-порт приложения-источника.
Хост-отправитель или другой маршрутизатор пересылает этот IP-пакет в NAT, который транслирует адреса исходящего пакета следующим образом (полужирным шрифтом выделены значения, изменяемые NAT): •
Destination IP Address: IP-адрес Интернет-ресурса;
• Source IP Address: общий адрес, выделенный ISP; • Destination Port: TCP- или UDP-порт Интернет-ресурса; •
Source Port: перенумерованный TCP- или UDP-порт приложения-источника.
NAT посылает преобразованный IP-пакет через Интернет и получает ответ от вызываемого компьютера. Пакет, полученный NAT, содержит следующую информацию об адресах (полужирным шрифтом выделены значения, изменяемые NAT): • Destination IP Address: общий адрес, выделенный ISP; • Source IP Address: IP-адрес Интернет-ресурса; • Destination Port: перенумерованный TCP- или UDP-порт приложения-источника; • Source Port: TCP- или UDP-порт Интернет-ресурса.
В нашем тексте этот компонент называется транслятором сетевых адресов. — Прим. перен.
96
ЧАСТЬ 1
Маршрутизация
Когда NAT сопоставляет и транслирует адреса, а затем пересылает пакет клиенту интрасети, этот пакет содержит следующую информацию об адресах (полужирным шрифтом выделены значения, изменяемые NAT): •
Destination IP Address: частный IP-адрес;
•
Source IP Address: IP-адрес Интернет-ресурса;
• Destination Port: TCP- или UDP-порт приложения-источника; •
Source Port: TCP- или UDP-порт Интернет-ресурса.
В исходящих пакетах частный IP-адрес источника и номер TCP/UDP-порта преобразуются в общий IP-адрес источника и возможно измененный номер TCP/UDPаорта. Во входящих пакетах общий IP-адрес приемника и номер TCP/UDP-порта преобразуются в частный IP-адрес приемника и исходный номер TCP/UDP-иорта.
Статическое и динамическое сопоставление адресов NAT использует либо статическое, либо динамическое сопоставление. Статическое сопоставление настраивается так, чтобы трафик всегда сопоставлялся одним способом. Вы можете сопоставить с определенным Интернет-адресом весь трафик, направляемый на определенный адрес частной сети и исходящий с него. Так, чтобы настроить Web-сервер на компьютере в Вашей частной сети, Вы создаете статическое сопоставление (общий IP-адрес, TCP-порт 80] с [частный IP-адрес, TCP-порт 80]. Динамические сопоставления создаются, когда пользователи в частной сети инициируют трафик на Интернет-адреса. NAT автоматически добавляет эти сопоставления в свою таблицу сопоставлений и обновляет их при каждом использовании. Если динамическое сопоставление не обновлено в течение заданного времени, оно удаляется из таблицы. Для TCP-соединений таймаут по умолчанию составляет 24 часа. Для UDP-трафика аналогичный таймаут равен одной минуте.
Корректная трансляция полей заголовков По умолчанию NAT транслирует IP-адреса и TCP/UDP-порты. Эти изменения в IP-дейтаграмме требуют модификации и пересчета следующих полей в IP-, TCP- и UDP-заголовках: •
Source IP Address (IP-адрес источника) (в пакете, исходящем из частной сети), Destination IP Address (IP-адрес приемника) (в пакете, входящем в частную сеть);
•
IP Checksum (Контрольная сумма IP);
• • •
Source Port (Порт источника) (R пакете, исходящем из частной сети). Destination Port (Порт приемника) (в пакете, входящем в частную сеть); TCP Checksum (Контрольная сумма TCP); UDP Checksum (Контрольная сумма UDP).
Если информация об IP-адресах и портах находится только в IP- и TCP/UDP-заголовках (как в случае HTTP-трафика), ее трансляция не представляет никакой сложности. Однако существуют приложения и протоколы, которые передают информацию об IP-адресах или портах в собственных заголовках. FTP, например, храпит точечно-десятичное представление IP-адресов в FTP-заголовкс для FTP-коман-
ГЛАВА 3 Одноадресная IP-маршрутизация
97
ды port. Если NAT некорректно транслирует IP-адрес, у Вас могут появиться проблемы с сетевыми соединениями. Кроме того, в случае FTP — из-за хранения им IP-адресов в точечно-десятичном формате — транслированный IP-адрес в FTP-заголовке может получиться другого размера. Поэтому NAT приходится модифицировать и номера TCP-последовательностей, чтобы исключить потерю каких-либо данных.
Редакторы NAT В том сдучае, когда компоненту NAT приходится дополнительно транслировать и выравнивать полезные данные за IP-, TCP- и UDP-заголовками, нужен редактор NAT. Редактор NAT — это устанавливаемый компонент, способный корректно изменять полезные данные, которые иным способом правильно модифицироиать нельзя. В Windows 2000 встроены редакторы NAT для протоколов: • FTP;
•
ICMP;
• •
РРТР; NetBIOS поверх TCP/IP
Кроме того, протокол маршрутизации NAT включает прокси для протоколов: • Н.323; • Direct Play; • ILS-регистрации на основе LDAP; • RPC,
Примечание IPSec-трафик транслировать нельзя.
Процессы NAT на маршрутизаторе Windows 2000 Для службы маршрутизации и удаленного доступа в Windows 2000 компонент NAT представляет собой протокол маршрутизации, известный как Network Address Translation (NAT). Разрешить использование компонента NAT можно в оснастке Routing and Remote Access, добавив Network Address Translation как протокол маршрутизации. Примечание Сервисы NAT доступны и при использовании функции разделения Интернет-соединений; эта функция активизируется через апплет Network and Dialup Connections (Сеть и удаленный доступ к сети). Функция разделения (совместного использования) Интернет-соединений делает то же, что и протокол маршрутизации NAT в службе маршрутизации и удаленного доступа, но гораздо менее гибка. О настройке совместного использования Интернет-соединений и о том, в каких случаях эта функция предпочтительнее протокола маршрутизации NAT, см. справочную систему Windows 2000 Server. С протоколом маршрутизации NAT автоматически устанавливается целый напор редакторов NAT. При необходимости коррекции полезных данных пакета, трансли-
98
ЧАСТЬ 1
Маршрутизация
руемых в данный момент, NAT обращается к одному ш установленных редакторов. Редактор модифицирует полезные данные и возвращает результат компоненту NAT. NAT взаимодействует с TCP/IP для: • поддержки динамических сопоставлении портов — при необходимости NAT запрашивает уникальные номера TCP- и UDP-портов от стека протоколов TCP/IP; •
получения от TCP/IP и последующей трансляции пакетов, пересылаемых между частной сетьн) и Интернетом.
Компонент NAT и его взаимосвязь е TCP/IP и другими компонентами маршрутизатора показаны на рис. 3-23. tP Router Manager
Конфигурирование Назначение порта mrniHimmuLtre**-***-*-*"
Процесс редактирования
Трансляция
Рис. 3-23. Компоненты NAT
Исходящий Интернет-трафик В случае трафика частной сети, который передается по Интернет-интерфейсу. NAT сначала оценивает, имеется ли для данного пакета сопоставление адресов/портов — статическое или динамическое. Если нет, создается динамическое сопоставление. Создавая сопоставление, NAT учитывает, доступен один общий IP-адрес или несколько. • Если доступен единственный общий IP-адрес, NAT запрашивает новый уникальный TCP- или UDP-порт для этого адреса и использует полученный порт. •
Если доступно несколько общих IP-адресов, NAT сопоставляет частный IP-адрес с общим. Для таких сопоставлении трансляция портов не осуществляется. Когда возникает необходимость в использовании последнего общего IP-адреса, NAT переключается на тот алгоритм, который применяется при наличии единственного общего IP-адреса.
После сопоставления NAT проверяет установленные редакторы и при необходимости вызывает один из них. Когда редактирование заканчивается, NAT модифицирует TCP-, LIDP- и IP-заголовки и пересылает полученный кадр по Интернет-интерфейсу. Обработку исходящего Интернет-трафика компонентом NAT иллюстрирует рис. 3-24.
ГЛАВА 3
Одноадресная IP-маршрутизация
Начало
Создать сопоставление Т
Да
Имеется ли сопоставление?
Нет
да
Зарегистрирован ли подходящий редактор?
Вызвать редактор
UDP
TCP TCP или UDP?
Транслировать UDP-nopi источника; обновить контрольную сумму
Транслировать TCP-порт источника; обновить контрольную сумму
Транслировать IP-адрес источника: обновить контрольную сумму
Обновить сопоставление
Переслать через интерфейс, подключенный к Интернету
Рис. 3-24. Обработка исходящего Интернет-трафика компонентом NAT
99
100
ЧАСТЬ 1
Маршрутизация
Входящий Интернет-трафик В случае трафика частной сети, который принимается по Интернет-интерфейсу, NAT сначала оценивает, имеется ли для данного пакета сопоставление адресов/портов — статическое или динамическое. Если нет, КАТ «молча» отбрасывает этот пакет. Такое поведение NAT защищает частную сеть от злоумышленников из Интернета. Трафик из Интернета пересылается в частную сеть только в ответ на трафик, который инициирован пользователем частной сети и заставил NAT создать динамическое сопоставление, или при наличии статического сопоставления, разрешающего доступ пользователей Интерлета к определенным ресурсам в частной сети. После сопоставления NAT проверяет установленные редакторы и при необходимости вызывает один из них. Когда редактирование заканчивается, КАТ модифицирует TCP-, UDP- и [Р-заголовки и пересылает полученный кадр по интерфейсу частной сети. Обработку входящего Интернет-трафика компонентом NAT иллюстрирует рис. 3-25.
Дополнительные компоненты протокола маршрутизации NAT Для упрощения конфигурации сетей малых/домашних офисов (SOHO) с подключением к Интернету протокол маршрутизации NAT в Windows 2000 также включает DHCP-распределитель (DHCP allocator) и DNS-прокси (DNS proxy).
DHCP-pacnpe делитель Этот компонент предоставляет конфигурационную информацию об IP-адресах другим компьютерам и SOHO-сети. DHCP-распределитель — это упрощенный DHCPсервер, который выделяет IP-адрес, маску подсети, основной шлюз и IP-адрес DNSсервера. Вы должны настроить компьютеры в сети с DHCP как DHCP-клиенты, чтобы они автоматически принимали параметры конфигурации IP. TCP/IP в Windows 2000, Windows NT и Windows 95/98 по умолчанию конфигурирует компьютеры как DHCP-клиенты. В таблице 3-5 перечислены параметры DHCP в сообщениях DHCPOffer и DHCPAck, посылаемых DHCP-распредслителем в процессе выделения IP-адресов. Модифицировать :-)гги параметры или внести дополнительные нельзя. Таблица 3-5. DHCP-параметры DHCP-распределителя Код параметра
Значение параметра
Описание
1 3
255.255,0.0 IP-адрес частного интерфейса IP-адрес частного и ргтерфей еа 5 минут 5 суток 7 суток Доменное имя компьютера с NAT
Маска подсети Маршрутизатор (основной шлюз)
6 58 (ОхЗА) 59 (ОхЗВ) 51 15 (OxOF)
DNS-ссрвер (только если включен DNS-прокси) Время возобновления аренды Время повторной привязки (псрепривязки) Срок аренды IP-адреса DNS-домен
ГЛАВА 3
Одноадресная IP-маршрутизация
Начало
Отбросить пакет | Имеется ли сопоставление? Да
С /—"~ Нет
Да
Зарегистрирован UIA подходящий редактор?
Вызвать рвдактор
TCP
UDP TCP ял и U DP?
Транслировать UDP-порт источника; обновить контрольную сумму
Транслировать TCP-порт источника; обновить контрольную сумму
Транслировать IP-адрес источника: обновить контрольную сумму
Обновить сопоставление
Переслать через интерфейс, подключенный к частной сети
Рис. 3-25. Обработка входящего Интернет-трафика компонентом NAT
101
102
ЧАСТЬ 1
Маршрутизация
DHCP-распределитель поддерживает лишь одну область IP-адресов, настроенную на вкладке Address Assignment (Назначение адресов) окна свойств протокола маршрутизации Network Address Translation (NAT) (NAT - преобразование сетевых адресов), открываемого из оснастки Routing and Remote Access (Маршрутизация и удаленный доступ), DHCP-распределитель не поддерживает более одной области, а также суперобласти (superscopes) и многоадресные области (multicast scopes). Если Вам нужна такая функциональность, установите DHCP-сервер и отключите DHCP-распределитель в свойствах протокола маршрутизации NAT.
DNS-прокси Компонент DNS-прокси выступает в роли DNS-сервера для компьютеров и SOIIOсети. DNS-запросы от клиентских компьютеров посылаются на NAT-компьютер, который пересылает их как DNS-запросы от своего имени к сконфигурированному DNS-серверу. Ответы на DNS-запросы, соответствующие незавершенным запросам клиентских компьютеров, принимаются NAT-компьютером и пересылаются клиентам.
Выявление и устранение проблем с NAT Большинство проблем с NAT связано с некорректным преобразованием пакетов. Прочие проблемы относятся к распределению адресов и разрешению имен. NAT-компьютер неправильна преобразует пакеты я
Убедитесь, что интерфейс маршрутизатора Windows 2000, по которому он подключен к Интернету, добавлен к протоколу маршрутизации Network Address Translation (NAT) (NAT - преобразование сетевых адресов).
•
Убедитесь, что на вкладке General (Общие) окна свойств Интернет-интерфейса установлен переключатель Public interface connected to the Internet (Общий интерфейс подключен к Интернету).
•
Убедитесь, что на вкладке General окна свойств интерфейса частной сети установлен переключатель Private interface connected to private network (Частный интерфейс подключен к частной сети).
• Если у Вас имеется лишь один общий IP-адрес, установите флажок Translate TCP/UDP headers (Преобразовать TCP/UDP-заголовки) на вкладке General окна свойств Интернет-интерфейса, •
Если у Вас несколько общих IP-адресов, проверьте, правильно ли они набраны в полях на вкладке Address Pool (Пул адресов) окна свойств Интернет-интерфейса. Если в Ваш пул включен IP-адрес, не выделенный Вам провайдером услуг Интернета (ISP), то входящий Интернет-трафик, связанный с этим IP-адресом, будет направляться ISP в какое-то другое место.
• Если некое приложение не работает через NAT, попробуйте запустить его с NATкомпьютера. Если оно работает на NAT-компьютере и не функционирует на любом другом компьютере в частной сети, то, вероятно, его полезные данные не удается транслировать. Проверьте протокол, используемый этим приложением, и сравните его со списком редакторов, поддерживаемых NAT. При необходимости свяжитесь с поставщиком данного приложения и выясните, как оно работает в NAT-среде,
ГЛАВА 3
Одноадресная IP-маршрутизация
i 03
• Убедитесь, что фильтрация IP-пакетов на интерфейсах, подключенных к Интернету и частной сети, не препятствует приему (через входные фильтры) или передаче (через выходные фильтры) Интернет-трафика. • Убедитесь, что TCP/IP-фильтрация на интерфейсах, подключенных к Интернету и частной сети, не препятствует приему трафика. • При использовании особых портов проверьте конфигурации) общего адреса/порта и частного адреса/порта. Хосты в частной сети не получают конфигурацию IP-адресов Убедитесь, что на вкладке Address Assignment (Назначение адресов) в окне свойств протокола маршрутизации Network Address Translation (NAT) (NAT - преобразование сетевых адресов) включено автоматическое назначение IP-адресов с использованием DHCP. Разрешение имен для хостов в частной сети не функционирует •
Убедитесь, что на вкладке Address Assignment в окне свойств протокола маршрутизации Network Address Translation (NAT) использование DNS-прокси разрешено.
• Проверьте настройки разрешения имен на NAT-компьютере с помощью команды ipconfig. Существует два варианта настройки разрешения имен при подкл ючении к ISP. • Статически назначенные серверы имен. Вы должны вручную настроить TCP/IP на IP-адрес или адреса серверов имен, предоставляемых ISP. В этом случае Вы можете в любой момент воспользоваться командой ipconfig и получить IP-адреса своих серверов имен. • Динамически назначаемые серверы имен. Настройка вручную не требуется. IP-адреса серверов имен, предоставляемые ISP, динамически назначаются при каждом соединении с ISP. В этом случае Вы должны воспользоваться командой ipconfig после соединения с ISP.
Фильтрация IP-пакетов Для обеспечения защиты IP-маршрутизатор может фильтровать IP-трафик. Эта функциональность, называемая фильтрацией IP-пакетов, позволяет администратору сети очень точно определять, какой именно IP-трафик разрешается принимать и пересылать маршрутизатору. Фильтрация IP-пакетов — важное звено в соединении корпоративных интрасетей с общедоступными сетями типа Интернета. Фильтрация IP-пакетов требует создания серии определений, называемых фильтрами; они определяют, какие виды трафика разрешены па каждом интерфейсе маршрутизатора. Фильтры могут устанавливаться как для входящего, так и для исходящего трафика. •
Входные фильтры определяют, какой входящий трафик на данном интерфейсе может быть перенаправлен или обработан маршрутизатором • Выходные фильтры определяют, какой трафик разрешено передавать маршрутизатору по данному интерфейсу.
104
ЧАСТЬ 1
Маршрутизация
Поскольку для каждого интерфейса можно определить как входные, так и выходные фильтры, есть риск создать конфликтующие фильтры. Например, входной фильтр на одном интерфейсе разрешает прием какого-то входящего трафика, но выходной фильтр на другом интерфейсе запрещает передачу этого трафика. Дело кончится тем, что этот трафик не сможет пересечь данный маршрутизатор Windows 2000. Фильтрация пакетов может быть реализована не только на маршрутизаторе, но и на любом другом компьютере под управлением Windows 2000. Это позволит фильтровать специфические подмножества входящего и исходящего трафика. Фильтры пакетов следует создавать с осторожностью, чтобы они не оказались чрезмерно ограничивающими и fie нарушили функционирование других протоколов, которые могут работать на данном компьютере. Например, если на компьютере с Windows 2000 выполняются Internet Information Services (IIS) — службы, которые превращают этот компьютер в Web-сервер, — а фильтры пакетов определены так, что пропускают лишь трафик, относящийся к Web, то Вы не сможете использовать утилиту Ping (выдающую ICMP-сообщения Echo Request и Echo Reply) для проверки базовой функциональности IP. Л если этот Web-сервер является еще и хостом Silent RIP, те же фильтры не позволят службе Silent RIP (Пассивный RIP) принимать RIP-оповещения. Примечание При устранении проблем с сетевыми соединениями и базовой функциональностью IP на компьютере под управлением Windows 2000, использующем фильтрацию пакетов, сначала убедитесь, что эти фильтры не препятствуют передаче или приему пакетов того протокола, с которым возникли проблемы.
Фильтрация IP-пакетов в Windows 2000 Фильтрация IP-пакетов в Windows 2000 основана на принципе исключения. Вы настраиваете Windows 2000 либо на пропуск всего трафика, кроме запрещенного фильтрами, либо на игнорирование всего трафика, кроме разрешенного фильтрами, Например, Вам может понадобиться сконфигурировать фильтр, пропускающий весь трафик, кроме трафика Telnet (TCP-порт 23). Или создать фильтры на выделенном Web-сервере для обработки только TCP-трафика, связанного с Web (TCPпорт 80). Примечание Маршрутизатор Windows 2000 не позволяет применять пользовательские фильтры там, где администратор сети может создать фильтр на основе какихлибо полей IP-, TCP-, UDP- или ICMP-заголовка; кроме того, он поддерживает фильтрацию лить но протоколам IP, TCP, UDP и ICMP. Windows 2000 поддерживает фильтрацию на основе содержимого различных полей в IP-, TCP-, UDP- и ICMP-заголовках входящих и исходящих пакетов.
IP-заголовок В IP-заголовке фильтры могут быть определены для следующих полей. IP Protocol (IP-протокол). Идентификатор, применяемый при демультиплексировании полезных данных IP-пакета для протокола более высокого уровня. Например, по умолчанию TCP использует протокол 6, UDP — 17, a ICMP — 1.
ГЛАВД 3
Одноадресная IP-маршрутизация
105
Source IP Address (IP-адрес источника). IP-адрес источника, в котором может быть указана маска подсети, что позволяет задавать целый диапазон IP-адресов (соответствующих IP-сети) в одном элементе фильтра. Destination IP Address (IP-адрес приемника). IP-адрес назначения, в котором может быть указана маска подсети, что позволяет задавать целый диапазон IP-адресов (соответствующих IP-сети) в одном элементе фильтра.
TCP-заголовок В TCP-заголовке фильтры могут быть определены для двух полей: 1) TCP Source Port (TCP-порт источника), используемого для идентификации процесса-источника, который отправляет данный TCP-сегмент, и 2) TCP Destination Port (ТСР-пирт приемника), применяемого для идентификации процесса-приемника данного ТС'Рсегмента. Примечание Маршрутизатор Windows 2000 не позволяет указывать в одном фильтре диапазон TCP-портов. Чтобы задать диапазон TCP-портов, придется определять отдельные фильтры для каждого порта из диапазона.
UDP-заголовок В UDP-заголовке фильтры могут быть определены для двух полей: 1) UDP Souice Port (t'DP-порт источника), используемого для идентификации процесса-источника, который отправляет данное UDP-сообшение, и 2) UDP Destination Port (UDPпорт приемника), применяемого для идентификации процесса-приемника данного UDP-сообщения. Примечание Маршрутизатор Windows 2000 не позволяет указывать в одном фильтре диапазон UDP-портов. Чтобы задать диапазон UDP-нортов, придется определять отдельные фильтры для каждого порта из диапазона.
ЮМР-заголовок J3 ICMP-заголовке фильтры могут быть определены для двух полей: 1) ICMP Ту >е (Тип 1СМР), задающего тип ICMP-пакста (например, эхо-запрос или эхо-ответ), и 2) ICMP Code (Код ICMP), указывающего одну из нескольких функций, допустимых для данного тина. Если для данного типа имеется лишь одна функция, ноле ICMP Code содержит 0. Часто используемые типы и коды 1СМР перечислены в таблице 3-6. Таблица 3-6. Часто используемые типы и коды ICMP Тип ICMP О В 3 3
Код ICMP Описание ,^____________ 0 Echo Reply (Эхо-ответ) 0 Echo Request (Эхо-запрос1) 0 Destination Unreachable/Network Unreachable (Адресат недоступен/ Сеть недоступна) 1 Destination Unreachable/Host Unreachable (Адресат недоступен/Узел недоступен) (см. след, стр.)
106
Маршрутизация
ЧАСТЬ 1
Таблица 3-6.
(продолжение)
Тип ICMP
Код ICMP
Описание
3
2
3
3
3
4
4 ."i
0 I
9 10 11 11
0 0 0 1
12
0
Destination Unreacbable/Protocol Unreachable (Адресат недоступен/ Протокол недоступен) Destination Unreachable/Port Unreachable (Адресат недоступен/Порт недоступен) Destination Unreachable/Fragmentation Needed and Don't Fragment Flag Set (Адресат недоступен/Требуется фрагментация, но установлен флаг DF) Source Quench (Замедление источника) Redirect/Redirected datagrams for the host (Перенаправление/Дейтаграммы перенаправлены на узел) Router Advertisement (Оповещение маршрутизатора) Router Solicitation (Сбор сведений о маршрутизаторах) Time Exceeded/TTL Expired (Время превышено/TTL истек) Time Exceeded/Fragmentation Reassembly Expiration (Время превышено/Срок восстановления фрагментации истек) Parameter Problem (Проблема с параметром)
Примечание Полный список типов и кодов ICMP см. по ссылке на странице http:// windows.microsoft.com/windows2000/reskit/vvebresources.
Входные фильтры Входные фильтры настраиваются по принципу исключения. Вы можете сделать так, чтобы фильтр либо принимал весь трафик, кроме заданного, либо игнорировал весь трафик, кроме указанного. Если задано несколько фильтров, то отдельные фильтры, применяемые к входящему пакету, сравниваются логической операцией OR. Если пакет подходит хотя бы под один фильтр, он принимается или игнорируется в зависимости от действия данного фильтра.
Выходные фильтры Выходные фильтры тоже настраиваются по принципу исключения. Вы можете сделать так, чтобы фильтр либо пропускал весь трафик, кроме заданного, либо игнорировал весь трафик, кроме указанного. Если задано несколько фильтров, то отдельные фильтры, применяемые к исходящему пакету, сравниваются логической операцией OR. Если пакет подходит хотя бы под один фильтр, он передается или игнорируется в зависимости от действия данного фильтра.
Настройка фильтра При добавлении или изменении фильтра Вы настраиваете его параметры в диалоговом окне Add IP Filter (Добавление IP-фильтра) или Edit IP Filter (Изменение IP-фильтра) соответственно. Если Вы задаете несколько параметров для какого-
ГЛАВА 3 Одноадресная IP-маршрутизация
107
либо фильтра, то при его применении к входящему пакету эти параметры сравниваются логической операцией AND. Чтобы пакет удовлетворял критериям фильтра, его поля должны соответствовать всем параметрам этого фильтра. Примечание Сконфигурировать раздельные активные фильтры для Receive all packets except those that meet the criteria below (Принимать все пакеты, кроме тех, что отвечают указанным ниже критериям) и Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям) нельзя. В диалоговом окне Add IP Filter или Edit IP Filter можно настроить следующие поля. Source Network (Исходная сеть) •
JP Address (IP-адрес). Введите идентификатор сети источника или IP-адрес источника.
•
Subnet Mask (Маска подсети). Для идентификатора сети источника введите соответствующую маску подсети, а для IP-адреса источника — 255.255.255.255.
Destination Network (Сеть назначения) m IP Address (IP-адрес). Введите идентификатор сети назначения или IP-адрес назначения. • Subnet Mask (Маска подсети). Для идентификатора сети назначения введите соответствующую маску подсети, а для IP-адреса источника — 255.255.255.2л5. Protocol (Протокол) m TCP (TCP). Протокол = 6. Выберите этот вариант, чтобы появились поля, в которых Вы сможете указать TCP-порты источника и назначения (адресата). Можно заполнить только одно или оба поля. Если Вы оставите эти поля пустыми, они получат значение по умолчанию (0), что соответствует любому порту. • TCP [established] (TCP [установлено]). Протокол = 6. Выберите этот вариант, если Вы хотите определить TCP-трафик для TCP-соединений, установленных с помощью маршрутизатора. • UDP (UDP). Протокол = 17. Выберите этот вариант, чтобы появились поля, в которых Вы сможете указать UDP-иорты источника и назначения (адресата). Можно заполнить только одно или оба поля. Если Вы оставите эти поля пустыми, они получат значение по умолчанию (0), что соответствует любому порту. • JCMP (ICMP). Протокол = 1. Выберите этот вариант, чтобы появились поля, в которых Вы сможете указать код и тип ICMP. Можно заполнить только одно или оба поля. Если Вы оставите эти поля пустыми, они получат значение то умолчанию (255), что соответствует любому коду или типу. • Any (Любой). Выберите этот вариант, чтобы был принят любой номер протокола IP. • Other (Другой). Выберите этот вариант, чтобы появилось поле, в котором 1>ы сможете указать любой протокол IP.
108
ЧАСТЬ 1
Маршрутизация
Варианты фильтрации В этом раз дел с приведены примеры конфигураций фильтров для наиболее часто реализуемых вариантой фильтрации. Внимание Если Вы решили скомбинировать любые из предлагаемых наборов фильтров, убедитесь, что они разрешают пропуск нужного подмножества трафика и в то же время обеспечивают требуемый уровень защиты. Например, если Вы комбинируете наборы фильтров для локального хоста и Web-трафика, то из-за особенностей применения фильтров (AND — внутри фильтра, OR — между фильтрами), будет разрешен весь трафик, адресованный хосту. Входной фильтр для Web-трафика будет фактически игнорироваться.
Фильтрация локального хоста Используйте такую фильтрацию, чтобы разрешить обработку только трафика, адресованного хосту. Фильтрация локального хоста (local host filtering) блокирует пересылку пакетов по интерфейсу, на котором она включена. Эта фильтрация применяется в том случае, когда интрасеть подключена к Интернету и прямая маршрутизация пакетов между интрасетью и Интернетом нежелательна. В этом варианте фильтрация локального хоста осуществляется на Интернет-интерфейсе. Сконфигурируйте следующие фильтры на интерфейсе, соединенном с Интернетом. Они разрешают пропуск по интерфейсу только трафика, адресованного данному хосту или всем хостам в его сети, либо группового трафика. Выбор действия фильтра Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям) приведет к созданию серии входных фильтров со следующими атрибутами. IP-адрес назначения для хоста В диалоговом окне Add IP Filter (Добавление IP-фильтра) установите флажок Destination network (Сеть назначения), а затем введите в соответствующих полях IP-адрес хоста и маску подсети 255.255.255.255. IP-адрес назначения для широковещательной рассылки в подсети 1. В диалоговом окне Add IP Filter установите флажок Destination network, а затем введите в соответствующих полях IP-адрес широковещательной рассылки в подсети хоста и маску подсети 255.255.255.255. 2. Чтобы определить широковещание в подсети, установите все биты идентификатора в 1. Например, если IP-адрес хоста определен как 172.16.5.98, а маска подсети — как 255.255.255.0 (подсеть частной IP-сети 172.16.0.0), то этот фильтр будет действовать применительно к IP-адресу назначения 172.16.5.255. IP-адрес назначения для широковещательной рассылки по всем подсетям В диалоговом окне Add IP Filter установите флажок Destination network, а затем введите в соответствующих полях IP-адрес широковещательной рассылки во все подсети и маску подсети 255.255.255,255. IP-адрес широковещательной рассылки во все подсети (all subnets-directed broadcast) является широковещательным адресом на основе класса, где биты идентифи-
ГЛАВА 3
Одноадресная IP-маршрутизация
109
катора хоста установлены в 1 до разбиения на подсети. Для хоста, используемого в данном примере, этот фильтр будет действовать применительно к IP-адресу назначения 172.16.255.255. Фильтр для широковещания во псе подсети нужен только при разбиении па подсети. IP-адрес назначения для ограниченной широковещательной рассылки В диалоговом окне Add IP Filter установите флажок Destination network, а затем введите в соответствующих полях IP-адрес 255.255.255.255 и маску подсети 255.255.255.255. IP-адрес ограниченной широковещательной рассылки определен как 255,255.255.255. IP-адрес назначения для всех возможных видов группового трафика В диалоговом окне Add IP Filter установите флажок Destination network, а затем введите в соответствующих полях IP-адрес 224.0.0.0 и маску подсети 240.0.0.0. Па данном интерфейсе будет разрешен любой входящий групповой трафик. Примечание Фильтрация локального хоста на каком-либо интерфейсе фактически отключает одноадресную маршрутизацию па этом интерфейсе, потому что через него разрешается пропуск лишь того одноадресного трафика, который предназначен непосредственно хосту. Транзитный трафик отбрасывается.
Фильтрация Web-трафика Фильтрация Web-трафика осуществляется на хостах, работающих в качестве Webсерверов; при этом разрешается обработка только принимаемого или передаваемого хостом Web-трафика. Это позволяет защитить от атак злоумышленников другие службы, функционирующие на Web-сервере. В случае Web-сервера, подключенного к Интернету, Web-трафик фильтруется на Интернет-интерфейсе. Выбрав переключатель Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям), настройте следующие фильтры, чтобы разрешить пропуск только тех пакетов, которые принимаются или передаются службой Web-сервера. •
Входной фильтр: в поле IP-адреса назначения введите IP-адрес Web-сервера, а в поле TCP-порта назначения — 80.
•
Выходной фильтр: в ноле IP-адреса источника введите IP-адрес Web-сервера, а в поле TCP-порта источника - 80.
Если Вы определили только эти фильтры, то по данному интерфейсу будет разрешен пропуск лишь TCP-трафика, принимаемого и передаваемого службой Web-сервера на компьютере под управлением Windows 2000 Server. Примечание В предыдущем примере мы исходили из того, что по умолчанию номер порта Web-сервера равен 80. Если Вы используете какой-то другой тторт, подставьте вместо 80 соответствующее значение.
Фильтрация РТР-трафика Фильтрация FTP-трафика осуществляется на хостах, работающих в качестве РТРсерверов; при этом разрешается обработка только принимаемого или передаваемо-
110
ЧАСТЬ 1
Маршрутизация
го хостом FTP-трафика. Это позволяет защитить от атак злоумышленников другие службы, функционирующие на FTP-сервере. В случае FTP-ссрвера, подключенного к Интернету, FTP-трафик фильтруется на Интернет-интерфейсе. Выбрав переключатель Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям), настройте следующие фильтры, чтобы разрешить пропуск только тех пакетов, которые принимаются или передаются службой FTP-сервсра. •
Входные фильтры: в поля IP-адреса назначения введите IP-адрес РТР-сервера, а в поля TCP-порта назначения — 21 (порт управления FTP) и 20 (порт данных FTP). • Выходные фильтры: в поля IP-адреса источника введите IP-адрес РТР-сервера, а в поля TCP-порта источника — 21 и 20. Если Вы определили только эти фильтры, то по данному интерфейсу будет разрешен пропуск лишь TCP-трафика, принимаемого и передаваемого службой FTP-cepвера на компьютере под управлением Windows 2000 Server. Примечание В предыдущем примере мы исходили из того, что по умолчанию номера портов FTP-сервера равны 20 и 21. Если Вы используете какие-то другие порты, подставьте вместо 20 и 21 соответствующие значения.
Фильтрация РРТР-трафика Фильтрация РРТР-трафика осуществляется на хостах, работающих в качестве РРТР-серверов; при этом разрешается обработка только принимаемого или передаваемого хостом РРТР-трафика. Это позволяет защитить от атак злоумышленников другие службы, функционирующие на РРТР-сервере. В случае РРТР-сервера, подключенного к Интернету, РРТР-трафик фильтруется на Интернет-интерфейсе. Выбрав переключатель Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям), настройте следующие фильтры, чтобы разрешить пропуск только тех пакетов, которые принимаются или передаются службой РРТР, выполняемой на сервере. •
Входные фильтры: для первого фильтра в поле IP-адреса назначения введите IPадрес РРТР-сервера, а в поле TCP-порта назначения — 1723; для второго фильтра в качестве IP-адреса назначения укажите IP-адрес РРТР-сервера и выберите IP-протокол 47 (Generic Routing Encapsulation [GRE|). • Выходные фильтры: для первого фильтра в поле IP-адреса источника введите IP-адрес РРТР-сервера, а в поле TCP-порта источника — 1723; для второго фильтра в качестве IP-адреса источника укажите IP-адрес РРТР-сервера и выберите IP-протокол 47 (Generic Routing Encapsulation [GRE]).
Если РРТР-сервер используется и как РРТР-клиент для инициации туннелированных соединений с использованием виртуальной частной сети, настройте дополнительные фильтры. •
Входной фильтр: в поле IP-адреса назначения укажите IP-адрес РРТР-сервера, а затем, выбрав в списке TCP (established) (TCP [установлено]), введите 1723 в поле TCP-порта источника.
ГЛАВА 3 •
Одноадресная IP-маршрутизация
111
Выходной фильтр: в поле IP-адреса источника укажите IP-адрес РРТР-сервера, а затем, выбрав в списке TCP (established) (TCP [установлено]), введите 1723 в поле TCP-порта назначения.
Фильтр TCP (established) используется для того, чтобы разрешить пропуск трафика только но TCP-соединению, установленному РРТР-клиентом. Без этого фильтра злоумышленник мог бы проникнуть на РРТР-сервср из Интернета, посылая пакеты из приложений, использующих TCP-порт 1723. Если Вы определили только эти фильтры, то по данному интерфейсу будет разрешен пропуск лишь TCP-трафика и тупнелированных данных (GRE-трафика), принимаемых и передаваемых РРТР-сервером и РРТР-клиентом на компьютере под управлением Windows 2000 Server, Подробнее о РРТР см. главу 9 «Виртуальные частные сети» в этой книге.
Фильтрация 1_2ТР-трафика Фильтрация трафика L2TP (Layer Two Tunneling Protocol) поверх IPSec осуществляется на хостах, работающих в качестве L2TP-серверов; при этом разрешается обработка только Ь2ТР-трафика. принимаемого или передаваемого службой L1ITPссрвера. Это позволяет защитить от атак злоумышленников другие службы, функционирующие на Ь2ТР-сервере. В случае ЬЗТР-сервера, подключенного к Интернету, Ь2ТР-трафик фильтруется на Интернет-интерфейсе. Выбрав переключатель Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям), настройте следующие фильтры, чтобы разрешить пропуск только тех пакетов, которые принимаются или передаются службой L2TP, выполняемой на сервере. •
Входной фильтр: в поле IP-адреса назначения укажите а в поле UDP-порта назначения — 1701. • Входной фильтр: в поле IP-адреса назначения укажите а в поле UDP-порта назначения — 500. • Выходной фильтр: в поле IP-адреса источника укажите а в поле UDP-порта источника — 1701. • Выходной фильтр: в поле IP-адреса источника укажите а в тюле UDP-порта источника — 500.
IP-адрес L2TP-eepuepa, IP-адрес Ь2ТР-сервера, IP-адрес L2TP-cepnepa, IP-адрес Ь2ТР-сервера,
Фильтры для UDP-порта 1701 предназначены для протокола L2TP, а фильтры для UDP-порта 500 — для Internet Key Exchange (IKE), используемой при создании сопоставления безопасности IPSec (IPSec security association). Фильтры пакетов для ESP-заголовка (Encapsulating Security Payload), использующего IP-протокил 50, не требуются, так как входящие и исходящие пакеты сначала обрабатываются службой IPSec (IP-безопасность), которая добавляет или удаляет ESP-заголовок до применения фильтров IP-пакетов службой маршрутизации и удаленного доступа. Если Вы определили только эти фильтры, то по данному интерфейсу будет разрешен пропуск лишь UDP-трафика, принимаемого и передаваемого Ь2ТР-сериером и Ь2ТР-клиентом на компьютере под управлением Windows 2000 Server. Подробнее о L2TP поверх IPSec см. главу 9 «Виртуальные частные сети» в этой книге.
112
ЧАСТЬ 1
Маршрутизация
Отклонение фальсифицированных пакетов с частных IP-адресов Один из способов реализации атак типа «отказ в обслуживании*- (denial of service attacks) заключается в том, чтобы наводнить серверы пакетами (например, запросами на установление TCP-соединения) с адресов, на которые нельзя ответить. В таких случаях злоумышленник фальсифицирует, или подменяет, IP-адрес источника пакетов другим адресом, отличным от IP-адреса интерфейса, с которого они реально посылаются. Проще всего воспользоваться каким-нибудь частным адресом, так как ответ, отправленный на частный адрес в Интернете, приведет к генерации IСМР-сообщения Destination Unreachable. Чтобы отклонять Интернет-трафик с фальсифицированных частных IP-адресов, создайте входные фильтры на Интернет-интерфейсе для приема всех пакетов, кроме отвечающих следующим критериям; •
IP-адрес источника 10.0.0.0 с маской подсети 255.0.0.0;
• IP-адрес источника 172.16.0.0 с маской подсети 255.240.0.0; • IP-адрес источника 192.168.0.0 с маской подсети 255.255.0.0.
Фильтрация фрагментов Служба маршрутизации и удаленного доступа также поддерживает фильтрацию фрагментированных IP-дейтаграмм. Фрагментированная IP-дейтаграмма — это IPдейтаграмма, содержащая фрагмент полезных данных IP. Хосты-отправители или маршрутизаторы фрагментируют полезные данные IP для того, чтобы получаемые в результате IP-дейтаграммы были достаточно малыми для передачи по сетевому сегменту за следующим переходом. Фильтрация фрагментов применима только к входящему трафику. ^- Чтобы включить фильтрацию фрагментов: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IP Routing (IP-маршрутизация) для нужного сервера. 2. Укажите General (Общие), щелкните правой кнопкой мыши нужный интерфейс и выберите команду Properties (Свойства). 3.
На вкладке General (Общие) установите флажок Enable fragmentation checking (Включить проверку фрагментации).
Чтобы маршрутизатор не пересылал фрагментированные IP-пакеты транзитного трафика по любому из своих интерфейсов, установите этот флажок в свойствах каждого интерфейса маршрутизатора. Такая настройка не запрещает пересылки фрагментированных пакетов, передаваемых с самого маршрутизатора. Фильтрация фрагментов также предотвращает «Ping of Death», одну из атак типа «отказ в обслуживании», при которой злоумышленники посылают одно или несколько 64-килобайтных ICMP-сообщений Echo Request. 64-килобайтные сообщения фрагментируются, а на хосте-получателе восстанавливаются. Для каждого 64килобайтного сообщения TCP/IP должен выделять память, таблицы, таймеры и другие ресурсы. При достаточно большом количестве фрагментировапных сообщений компьютер с Windows 2000 Server может просто «захлебнуться» в них, и обслуживание нормальных запросов резко ухудшится. Фильтрация фрагментов
ГЛАВА 3
Одноадресная IP-маршрутизация
113
приводит к тому, что входящие фрагментированные IP-дейтаграммы тут же отбрасываются.
Обнаружение маршрутизаторов средствами ICIWP Маршрутизатор Windows 2000 включает поддержку оповещений маршрутизаторов (router advertisements) и схему обнаружения маршрутизаторов, дсжументиронанную в RFC 1256. Чтобы упростить настройку IP-хостов на IP-адреса локальных маршрутизаторов и обеспечить распознавание хостами отключенных маршрутизаторов, RFC 1256 предлагает использовать ICMP-сообщения Router Advertisement и Router Solicitation.
ICMP-сообщение Router Advertisement Маршрутизатор периодически посылает ICMP-сообщение Router Advertisement (Оповещение маршрутизатора) (тип 9, код 0). Это сообщение может быть отправлено на адрес групповой IP-рассылки всем хостам (all-hosts IP multicast addr >ss) 224.0.0.1 и адрес локальной широковещательной IP-рассылки, также называемый адресом ограниченной широковещательной рассылки (255.255.255.255). На практике сообщение Router Advertisement посылается на адрес групповой рассылки. Эти сообщения явно уведомляют все хосты в сети о том, что данный маршрутизатор все еще доступен. Сообщение Router Advertisement содержит параметр Advertisement Lifetime (Бремя жизни объявления) — время, по истечении которого маршрутизатор можно считать отключенным, если не поступило очередное сообщение Router Advertisement (по умолчанию — 30 минут), — и параметр Preference Level (Уровень предпочтения), учитываемый при выборе маршрутизатора на роль основного шлюза для сети. Основным шлюзом становится маршрутизатор с наивысшим уровнем предпочтения.
ICMP-сообщение Router Solicitation Когда хосту, который поддерживает RFC 1256, нужно настроиться на основной шлюз (либо при инициализации, либо при выходе из строя предыдущего основного шлюза), он посылает ICMP-сообщение Router Solicitation (Сбор сведений о маршрутизаторах) (тип 10, код 0). Это сообщение может быть отправлено па адрес групповой IP-рассылки всем маршрутизаторам (all-routers IP multicast address) 224.0.0.2 и адрес локальной широковещательной IP-рассылки, также называемый адресом ограниченной широковещательной рассылки (255.255.255.255). На практике хосты посылают сообщения Router Solicitation на адрес групповой рассылки. Маршрутизаторы в сети хоста, поддерживающие RFC 1256, немедленно отвечают lCMP-сообщением Router Advertisement, и хост выбирает в качестве своего основного шлюза маршрутизатор с наивысшим уровнем предпочтения. Примечание Поддержка обнаружения маршрутизаторов средствами ICMP не имеет ничего общего с протоколами маршрутизации. Маршрутизаторы лишь оповещают о своем присутствии, но не объявляют об оптимальном маршруте к какой-либо сети назначения. Если хост использует неоптимальный маршрут, ICMP-сообще* ия Redirect перенацелят хост на более эффективный маршрут.
5 Зак 3343
114
ЧАСТЬ 1
Маршрутизация
Настройки обнаружения маршрутизаторов средствами ICMP описываются в таблице 3-7. Таблица 3-7. Настройки обнаружения маршрутизаторов средствами ICMP Параметр
Описание
Level of Preference Уровень предпочтения данного маршрутизатора (Уровень предпочтения) как основного шлюза. По умолчанию — 0. Advertisement Lifetime (minutes) Время (в .минутах), по истечении которого хост [Время жизни объявления (мин)] считает маршрутизатор отключенным (если не поступило очередное сообщение Router Advertisement). По умолчанию — 30 мин. Advertisement interval: minimum Минимальный интервал между сообщениями Router time (minutes) [Отправлять Advertisement, посылаемыми данным маршрутизатором, объявления в этом интервале: По умолчанию — 7 мин. минимальное время (мин)] Advertisement interval: maximum Максимальный интервал между сообщениями Router (minutes) [Отправлять Advertisement, посылаемыми данным маршрутизатором, объявления в этом интервале: По умолчанию — 10 мин. На практике периодичность максимальное время (мин)] посылки сообщений Router Advertisement случайным образом варьируется в пределах между минимальным и максимальным интервалами. > Чтобы включить оповещения маршрутизатора для его распознавания хостами: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IP Routing (IP-маршрутизация) для нужного сервера. 2. Укажите General (Общие), щелкните правой кнопкой мыши нужный интерфейс и выберите команду Properties (Свойства). 3. На вкладке General (Общие) установите флажок Enable router discovery advertisements (Включить объявления обнаружения маршрутизатора). При активизации флажка Enable router discovery advertisements Windows 2000 посылает сообщения Router Advertisement (как периодически, так и в ответ на сообщения Router Solicitation) с использованием адреса групповой IP-рассылки 224.0.0.1, TCP/IP в Windows 2000 и Windows 98 поддерживает применение сообщений Router Solicitation для выбора основного шлюза. О том, как отключить распознавание маршрутизатора для TCP/IP в Windows 2000, см. книгу «Сети TCP/ IP» из серии «Ресурсы Microsoft Windows 2000 Server».
Дополнительные материалы Более подробную информацию об IP-маршрутизации см. в следующих книгах: •
Christian Huitema «Routing in the Internet»,1995, Englewood Cliff's, NJ: Prentice Hall;
• John T. Moy «OSPF: Anatomy of an Internet Routing Protocol», 1998, Reading, MA: Addison-Weslev.
ГЛАВА
Поддержка групповой IP-рассылки
Windows 2000 предоставляет поддержку для передачи, приема и пересылки группового IP-трафика. Соответствующие компоненты службы маршрутизации и удаленного доступа позволяют передавать и принимать групповой IP-трафик от клиентов удаленного доступа и из тех частей Интернета или частной интрасети, которые поддерживают групповые рассылки. В этой главе Обзор 116 Интрасеть с поддержкой групповой IP-рассылки 118 IGMP 124 Поддержка групповой IP-рассылки в службе маршрутизации и удаленного доступа 128 Поддерживаемые конфигурации многоадресной пересылки Средства диагностики 143
137
См. также • О базовых концепциях групповой IP-рассылки — главу 1 «Введение в TCP/IP» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». • Подробнее о поддержке групповой IP-рассылки в TCP/IP для Windows 2000 — главу 2 «Реализация TCP/IP в Windows 2000» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». • Подробнее об удаленном доступе — главу 7 «Сервер удаленного доступа» в этой книге. •
Подробнее о маршрутизаторах под управлением Windows 2000 Server — главу 2 «Служба маршрутизации и удаленного доступа» в этой книге.
116
ЧАСТЬ 1
Маршрутизация
Обзор Кроме поддержки адресной (unicasl) передачи и широковещательной рассылки, IP также предоставляет механизм для приема и передачи группового IP-трафика, Такой трафик посылается на единственный IP-адрес назначения, БО принимается и обрабатывается несколькими IP-хостами независимо от их местонахождения в межсетевой IP-среде. Хост прослушивает определенный IP-адрес групповой рассылки и принимает все пакеты, поступающие на этот адрес. При доставке данных по типу «один-ко-многим» групповая IP-рассылка эффективнее, чем адресная IP-передача или широковещание. В отличие от адресной передачи в этом случае посылается только одна копия данных, а трафик — в отличие от широковещания — принимается и обрабатывается лишь теми компьютерами, которые прослушивают специальный IP-адрес. Дополнительные особенности групповой IP-рассылки: • набор хостов, прослушивающих определенный IP-адрес групповой рассылки, называется группой хостов (host group); • членство в группах хостов является динамическим: хосты могут в любое время присоединяться к группе и покидать ее; • никаких ограничений на размер группы хостов не накладывается; •
группа хостов может охватывать IP-маршрутизаторы во множестве сетевых сегментов. Такая конфигурация требует от IP-маршрутизаторов поддержки многоадресной IP-пересылки, а от хостов — способности самостоятельно регистрироваться на маршрутизаторе. Регистрация хоста осуществляется по протоколу IGMP (Internet Group Managcjnent Protocol); • хост может посылать трафик на IP-адрес групповой рассылки, даже если он не входит в соответствующую группу хостов.
IP-адреса групповой рассылки, также называемые групповыми адресами (group addresses), относятся к классу О и находятся в диапазоне от 224.0.0.0 до 239.255.255.255 (четыре старших бита устанавливаются как 1110). При использовании префикса сети или нотации C1DR (Classless Inter-Domain Routing) IP-адреса групповой рассылки суммируются как 224.0.0.0/4. Адреса групповой рассылки в диапазоне от 224.0.0.0 до 224.0.0.255 (224.0.0.0/24) резервируются для локальной подсети, и IP-маршрутизаторы не пересылают на них пакеты независимо от значения TTL в IP-заголовках этих пакетов. IP-адреса групповой рассылки в диапазоне от 224.0.1.0 до 238.255.255.255 либо резервируются, либо выделяются какому-либо приложению групповой рассылки. Адреса от 239.0.0.0 до 239.255.255.255 (239.0.0.0/8) резервируются как адресное пространство групповой рассылки, которое можно разбивать на области. Подробнее об этих адресах см. раздел «Ограничители групповой рассылки» далее в этой главе. Вот несколько примеров зарезервированных IP-адресов групповой рассылки: • 224.0.0.1 — групповая рассылка всем хостам в данной подсети; •
224.0.0.2 -- групповая рассылка всем маршрутизаторам в данной подсети;
Поддержка групповой IP-рассылки
ГЛАВА 4
117
• 224.0.0.5 — групповая рассылка всем OSPF-маршрутизаторам в какой-либо сети (соответствующая поддержка введена в OSPF версии 2); •
224.0.0.6 -•- групповая рассылка всем главным OSPF-маршрутизаторам в какойлибо сети (соответствующая поддержка введена в OSPF версии 2); • 224.0.0.9 — используется протоколом RIP версии 2; • 224.0.1.1 — используется протоколом NTP (Network Time Protocol). Полный список зарезервированных групповых адресов см. по ссылке Information Sciences Institute на http://windows.microsoft.com/windows2000/reskit/vvebresources. Подробнее о поддержке групповой IP-рассылки см. RFC 1112.
Взаимосвязь IP-адресов групповой рассылки с эквивалентными МАС-адресами Для поддержки групповой IP-рассылки организации, отвечающие за развитие Интернета, зарезервировали диапазон МАС-адресов для Ethernet и FDDI от 01-00- 5Е00-00-00 до 01-00-5E-7F-FF-FF. Старшие 25 битов 48-битного МАС-адреса зафиксированы, а младшие 23 бита варьируются, как показано па рис. 4-1. Младшие 23 бита
и 5итов
16 битов
шЕИ
IP-адрес гру 1повой рассылки
Ethernet-адрес гр упповой рассылк А 8i : OJOJG|Q|G 0 1 0 0 оТоГоТоТоШо
1
1|о \\ 1 •1
24 бита
I
10
32 бита
1
1
1
BJ
iI
1
40 битов
: I
Т
,,.ТГ[, ™.
Младшие 23
Рис. 4-1. Взаимосвязь между IP-адресами и МАС-адресами Ethernet и FDD.1 (выделенными для групповой рассылки) IP-адрес групповой рассылки преобразуется в эквивалентный МАС-адрес следующим образом: младшие 23 бита IP-адреса прямо переписываются в младшие 23 бита МАС-адреса. Первые 4 бита IP-адреса групповой рассылки зафиксированы в соответствии с требованиями к адресам класса D, а остальные 5 битов в МАС-адрес групповой рассылки не переносятся. Поэтому хост мог бы обрабатывать пакеты групповой рассылки на МАС-уровне, адресованные группам, к которым этот ^ост не принадлежит. Однако такие пакеты просто отбрасываются IP, если определен IPадрес назначения. Например, адрес групповой рассылки 22-1.192.16.1 становится МАС-адресом 01-005Е-40-10-01. IP-адрес преобразуется в эквивалентный МАС-адрес следующим образом. Первый октет отбрасывается, а из второго октета используются лишь последние 7 битов. Третий и четвертый октеты преобразуются непосредственно в ыестнадцатеричныс числа. Второй октет (192) в двоичном виде выглядит как 11000000. Если Вы отбросите старший бит, то получите 1000000 в двоичном виде, 64 в десятичном или 0x40 в шестнадцатиричном. Следующий октет (16) в шест над цате чич-
118
ЧАСТЬ 1
Маршрутизация
ной форме рапен 0x10, а последний октет (1) — 0x01. Таким образом, из IP-адреса 224.192.16.1 получается соответствующий МАС-адрес 01-00-5Е-40-10-01. В Token Ring для получения эквивалентных МАС-адресов групповой рассылки применяется тот же метод. Однако многие сетевые адаптеры Token Ring этот метод не поддерживают. Так что для любого трафика групповой IP-рассылки в сетях Token Ring но умолчанию используется функциональный адрес ОхСО-00-00-04-00-00, Подробнее о поддержке групповой IP-рассылки в Token Ring см. RFC 1469. Примечание Windows NT версий 4.0 (или ниже) не поддерживает групповую IP-рассылку при использовании сетевых адаптеров Token Ring.
Интрасеть с поддержкой групповой IP-рассылки В интрассти с поддержкой групповой IP-рассылки любой хост может отправить групповой трафик на любой групповой адрес и принять его с любого группового адреса независимо от своего местонахождения. Для реализации такой возможности групповая IP-рассылка должна поддерживаться всеми хостами и маршрутизаторами в интрасети.
Хосты Хост поддерживает групповую IP-рассылку на одном из следующих уровней: • уровень 0 — прием и передача группового IP-трафика не поддерживается; • уровень 1 — поддерживается только передача группового IP-трафика; • уровень 2 — поддерживается и прием, и передача группового 1Р-трафика. TCP/IP в Windows 2000 поддерживает все эти уровни и по умолчанию настроен на уровень 2. О том, как изменить уровень поддержки групповой рассылки, см. главу 2 «Реализация TCP/IP в Windows 200()>> в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». Чтобы послать групповой IP-пакет, хост должен выполнить следующие операции. •
Определить нужный IP-адрес групповой рассылки. Выбирая этот адрес, приложение должно сначала определить: создать новую группу хостов или использовать одну из существующих. Чтобы присоединиться к существующей группе хостов, приложение с помощью какого-либо протокола поиска службы выясняет групповой адрес для конкретной службы. Адрес групповой рассылки для новой группы хостов может быть либо определен приложением, либо получен через какой-либо механизм, который выделяет уникальный адрес групповой рассылки, например через протокол MADCAP (Multicast Address Dynamic Client Allocation Protocol). MADCAP — это расширение протокола DHCP (Dynamic Hosl Configuration Protocol), которое можно использовать для поддержки динамического назначения и конфигурирования IP-адресов групповой рассылки в ТСР/1Р-сетях. DHCP-области обеспечивают выделение клиентам диапазонов одновещательных IP-адресов,, а MADCAP-области — диапазонов IP-адресов групповой рассылки. Подробнее о MADCAP и его поддержке в Windows 2000 см. главу 4
ГЛАВА 4
Поддержка групповой IP-рассылки
119
«DHCP» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». • Поместить групповой IP-пакет в несущую среду. Хост-отправитель должен сформировать IP-пакет, содержащий нужный группе* вой IP-адрес назначения, и поместить его в несущую среду. Если используются сетевые технологии разделяемого доступа, например Ethernet, FDDI или Token Ring, то групповой IP-адрес сначала преобразуется в МАС-адрес назначения, Чтобы принять групповой IP-пакет, хост должен выполнить следующие операции. • Сообщить IP о приеме группового трафика. Определяя IP-адрес групповой рассылки, приложение должно сначала решить: создать новую группу хостов или использовать одну из существующих. Чтобы присоединиться к существующей группе хостов, приложение с помощью клкого-либо протокола поиска службы выясняет групповой адрес для конкретной службы. Определив групповой адрес, приложение должно уведомить IP о приеме группового трафика на указанный групповой IP-адрес назначения. Если этим адресом пользуется несколько приложений, IP должен передать копию группового трафика каждому приложению. По мере того как приложения присоединяются к какой-либо группе хостов или покидают ее, IP должен вести учет, какие приложения используют групповые адреса и что это за адреса. А в случае многоадресных хостов IP должен отслеживать членство приложений в группах хо«тои применительно к каждой подсети, • Сообщить МАС-адрес групповой рассылки сетевому адаптеру. Если сетевая технология поддерживает аппаратные средства групповой рассылки, тогда сетевому адаптеру указывается передать пакеты па конкретный адрес групповой рассылки. В случае технологий разделяемого доступа типа Ethernet, FDDI или Token Ring запрограммировать сетевой адаптер так, чтобы он реагировал на групповой МАС-адрес, соответствующий нужному IP-адресу групповой рассылки, можно с помощью функции NdisRequest. • Уведомить локальные маршрутизаторы. Хост должен уведомить маршрутизаторы и локальной подсети о том, что он прослушивает групповой трафик по определенному групповому адресу. Для регистрации информации о группе хостов используется протокол IGMP (Internet Group Management Protocol). IGMP необходим на всех хостах, поддерживающих групповую IP-рассылку на уровне 2. Для регистрации своего членства в определенной группе хост посылает IGMP-сообщение Host Membership Report. TCP/IP в Windows 2000 поддерживает IGMP версии 2. Подробнее об IGMP см. разделы «IGMP v l » и «IGMP v2» далее в этой главе.
Маршрутизаторы Для пересылки групповых IP-пакетов только в те подсети, в которых есть члены каких-либо групп хостов, маршрутизатор группового IP-трафика должен: •
принимать весь групповой 1Р-трафик;
120
ЧАСТЬ 1
Маршрутизация
• пересылать групповой IP-трафик; • принимать и обрабатывать IGMP-сообщения Host Membership Report; • получать от подключенных к нему подсетей информацию о членстве хостов в группах; • передавать эту информацию другим маршрутизаторам группового 1Р-трафика.
Прием всего группового IP-трафика В случае таких технологий разделяемого доступа, как Ethernet и FDDI, нормальный режим работы сетевых адаптеров — режим адресного прослушивания (unicast listening mode). Режим прослушивания — это метод, по которому сетевой адаптер анализирует MAC-адреса назначения входящих кадров, решая, как обрабатывать их дальше. В режиме адресного прослушивания для дальнейшей обработки отбираются только те кадры, чьи МАС-адреса назначения присутствуют в таблице МАС-адресов назначения сетевого адаптера. Как правило, это широковещательный адрес (OxFF-FF-FF-FF-FF-FF) и одновешательный, также называемый МАС-адресом сетевого адаптера. Однако, чтобы маршрутизатор группового ТР-трафика мог принимать весь такой трафик, он должен перевести сетевой адаптер в особый режим прослушивания, называемый режимом прослушивания смешанного группового трафика (multicast promiscuous mode). В этом режиме сетевой адаптер анализирует состояние бита — признака группового адреса (multicast, hit), определенного IEEE (Institute of Electrical and Electronics Engineers), чтобы выяснить, требует ли данный кадр дальнейшей обработки. В Ethernet и FDDI это последний бит первого байта МАС-адрсса назначения. Признак группового адреса может принимать следующие значения: • 0 — данный адрес является одновещательным, или индивидуальным; • 1 — данный адрес является групповым, или адресом групповой рассылки. То же значение устанавливается и для широковещательного адреса. Сетевой адаптер, переведенный в режим прослушивания смешанного группового трафика, отбирает для дальнейшей обработки любые кадры с установленным битом — признаком группового адреса. Режим прослушивания смешанного группового трафика отличается от режима прослушивания смешанного трафика (promiscuous mode). В последнем случае на дальнейшую обработку передаются все кадры независимо от МАС-адреса назначения. Режим прослушивания смешанного трафика используется анализаторами протоколов, например полной версией Microsoft Network Monitor (Сетевой монитор), которая поставляется с Microsoft Systems Management Server. Режим прослушивания смешанного группового трафика поддерживается большинством сетевых адаптеров. Однако сетевой адаптер, который поддерживает режим прослушивания смешанного трафика, может не поддерживать режим прослушивания смешанного группового графика. Проверьте документации) на Ваш сетевой адаптер или выясните у его изготовителя, поддерживает ли этот сетевой адаптер режим прослушивания смешанного группового трафика.
ГЛАВА 4
Поддержка групповой IP-рассылки
121
Пересылка группового IP-трафика Поддержка пересылки групповых IP-пакетов предусмотрена в TCP/IP, и его реализация в Windows 2000 включает соответствующую функциональность. Если многоадресная пересылка разрешена, маршрутизатор анализирует групповые IP-пакеты из нелокальных подсетей, чтобы определить, по каким интерфейсам следует переслать тот или иной пакет. Анализ осуществляется сравнением групповогс адреса назначения с записями в таблице многоадресной IP-пересылки (IP multicast forwarding table). При приеме нелокального группового IP-пакета значение T"L о его IP-заголовке уменьшается на 1. Если после этой операции значение TTL остается ненулевым, проверяется содержимое таблицы многоадресной 1Р-псрссы'[Ки. Если в ней есть запись, подходящая для данного группового IP-адреса назначения, групповой IP-пакет с новым значением TTL пересылается по соответствующим интерфейсам. Процесс многоадресной пересылки (multicast forwarding process) не делает никаких различий между хостами в локально подключенных подсетях, принимающими групповой трафик, и хостами, доступными через другой маршрутизатор, который расположен далее по пути передачи этого трафика. Иначе говоря, маршрутизатор группового трафика может переслать групповой пакет в подсеть, где нет хостов, ожидающих групповой трафик. Так происходит потому, что другой маршрутизатор в той подсети сообщает, что па одном из его маршрутов имеется хост, принимающий групповой трафик. В таблице многоадресной IP-пересылки регистрируется лишь тот факт, что для такого-то группового адреса имеется по крайней мере один член группы хостои, список и количество членов групп хостов не фиксируются. О том, как просмотреть таблицу многоадресной IP-пересылки на компьютере под управлением Windows 2000 Server и службы маршрутизации и удаленного доступа, см. раздел «Средства диагностики» далее в этой главе. Многоадресная пересылка разрешена, если параметру EnableMuIticastForwarding в разделе HKEY_LOCAL_MACHINE\Systein\CurrentControlSet\Scrvices\Tcpip\ Parameters присвоено значение 1. Этот параметр создается и получает значение, равное 1, при установке службы маршрутизации и удаленного доступа. Внимание Не модифицируйте реестр самостоятельно (с помощью редактора реестра) — делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства зашиты, призванные не допускать ввода конфликтующих значений параметров, а также тех, которые могут снизить быстродействие системы или привести к ее краху. Прямое редактирование реестра может повлечь за собой непредсказуемые последствия, и Вам придется переустанавливать Windows 2000. Для настройки и конфигурирования Windows 2000 по возможности используйте Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft).
Прием и обработка IGMP-сообщений Host Membership Report Маршрутизаторы группового трафика принимают IGMP-сообщения Host Membership Report от всех хостов во всех локально подключенных подсетях. Эти информация используется для отслеживания членства хостов в группах и записыва-
122
ЧАСТЬ 1
Маршрутизация
ется в таблицу многоадресной пересылки. Поскольку такие маршрутизаторы работают в режиме прослушивания смешанного группового трафика, они принимают все IGMP-сообщения Host Membership Report, посылаемые по любому групповому адресу. В службе маршрутизации и удаленного доступа Windows 2000 эта функциональность становится доступной после добавления протокола маршрутизации IGMP и включения на интерфейсе режима работы в качестве IGMP-маршрутизатора. Подробнее см. раздел «Протокол IGMP» далее в этой главе.
Получение от подключенных подсетей информации о членстве хостов в группах Б подсети могут находиться хосты как с TGMP vl, так и с IGMP v2. Хост IGMP vl, прекращая прием группового IP-трафика по какому-либо групповому адресу (т. е. покидая соответствующую группу хостов), не уведомляет об этом локальные маршрутизаторы. Если он был последним членом группы в данной подсети, локальные маршрутизаторы какое-то время продолжают пересылать групповой трафик этой группе в этой подсети до тех пор, пока самостоятельно не выяснят, что группы больше нет. Чтобы уменьшить интервал между тем, когда последний хост покидает группу, и тем, когда прекращается пересылка группового трафика для этой группы в данной подсети, маршрутизаторы группового трафика периодически посылают в локальную подсеть IGMP-сообщения Host Membership Query, запрашивая информацию о членстве хостов в группах. Какой-либо хост, все еще являющийся членом группы, отвечает на этот запрос IGMP-сообщением Host Membership Report. Чтобы предотвратить посылку таких сообщений несколькими хостами одной и той же группы, хосты настраиваются на передачу IGMP-сообщения Host Membership Report с некоторой задержкой, варьируемой случайным образом. Если такое сообщение уже послано одним из хостов в подсети, остальные хосты его не посылают. Чтобы еще больше сократить упомянутый выше интервал, хост IGMP v2, покидая какую-либо группу в подсети, посылает IGMP-сообщение Leave Group. Тогда маршрутизатор IGMP v2 направляет этой группе запросы и, если в ней больше нет хостов в данной подсети, не получает никаких ответов. Благодаря этому маршрутизатор IGMP v2 быстро узнает, что членов данной группы в данной подсети больше нет, и прекращает пересылку соответствующего группового трафика.
Передача информации о членстве хостов в группах другим маршрутизаторам группового IP-трафика Чтобы создать межсетевую IP-среду, которая поддерживает групповую рассылку и содержит более одного маршрутизатора, маршрутизаторы групповой рассылки должны обмениваться друг с другом информацией о членстве хостов в группах — тогда члены групп смогут получать групповой IP-трафик независимо от своего местонахождения в межсетевой IP-среде. Маршрутизаторы групповой рассылки обмениваются информацией о членстве хостов в группах с использованием одного из протоколов многоадресной маршрутизации, например DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast Open Shortest Path First) или PIM (Protocol Independent Multicast). Информация о членстве в группах передается либо в явном виде (путем обмена
ГЛАВА 4
Поддержка групповой IP-рассылки
123
сведениями о групповых адресах и подсетях), либо в неявном (уведомлением маршрутизаторов, расположенных ближе к источнику группового трафика, о том, существуют ли члены групп далее па пути от этого источника). Протокол многоадресной маршрутизации (multicast routing protocol) предназначен для: •
пересылки трафика от источника с запретом возвратов во избежание петель маршрутизации; • минимизации или полного исключения пересылки группового трафика в те подсети, которым этот трафик не нужен; • минимизации нагрузки на центральный процессор и память маршрутизатора для большей масштабируемости; • минимизации издержек, связанных с применением протокола маршрутизации; • уменьшения времени, уходящего на то, чтобы первый хост, присоединившийся к группе в какой-либо подсети, начал получать групповой трафик. Многоадресная маршрутизация сложнее, чем одноадресная. При одноадресной маршрутизации трафик пересылается на глобально уникальный адрес назначения. Маршруты суммируют диапазоны глобально уникальных адресов назначения. К роме того, такие маршруты относительно постоянны и обновляются лишь при изменении топологии межсетевой IP-среды. При многоадресной маршрутизации групповой трафик пересылается группам хостов, изменчивым но своему составу. Групповые адреса представляют индивидуальные группы и, как правило, их нельзя суммировать в таблице многоадресной пересылки. Местонахождение членов групп непостоянно, и маршрутизаторам группового трафика приходится обновлять таблицы многоадресной пересылки всякий раз, когда какой-либо хост присоединяется к группе или покидает ее. Если протоколы одноадресной маршрутизации обновляют таблицу (адресной) IPпересылки, то протоколы многоадресной маршрутизации — таблицу многоадресной IP-пересылки. Служба маршрутизации и удаленного доступа в Windows 2000 не содержит никаких протоколов многоадресной маршрутизации, но предоставляет платформу, на которой они могут работать. Единственный компонент Windows 2000, способный обновлять записи в таблице многоадресной маршрутизации, - 1GMP.
МВопе MBone (Internet Multicast Backbone) — это часть Интернета, которая ноддержлваст многоадресную маршрутизацию и пересылку группового IP-трафика, генерируемого в Интернете. Структура МВопе представляет собой серию островков, поддерживающих многоадресную пересылку (multicast-enabled islands), — наборы смежных сетей, соединенные друг е другом туннелями. Групповой трафик передается от одного островка другому методом туннелирования, т. с. инкапсулирования группового IP-пакета в пакет с дополнительным IP-заголовком; этот пакет передается между маршрутизаторами островков, поддерживающих многоадресную пересылку. Туннелирование обеспечивает передачу группового трафика по тем участкам Интернета, где нет поддержки многоадресной пересылки.
124
ЧАСТЬ 1
Маршрутизация
МВопе используется для групповой трансляции аудио- и видеоинформации с совещаний IETF, из NASA (National Aeronautics and Space Administration), Палаты представителей и Сената США, а также некоторых других учреждений. Разные провайдеры услуг Интернета по-разному реализуют поддержку МВопе.
IGMP IGMP (Internet Group Management Protocol) применяется между хостами и их локальным маршрутизатором группового трафика. IGMP-сообщения инкапсулируются IP и используют номер IP-протокола 0x02. Существует две версии TGMP. •
Версия 1 (IGMP vl) поддерживается TCP/IP в Windows NT версии 4.0 с Service Pack 3 (или ниже) и в Windows 95.
•
Версия 2 (IGMP v2) поддерживается TCP/IP в Windows NT 4.0 Service Pack 4 (и выше), в Windows 98 и Windows 2000.
IGMP v2 обратно совместим с IGMP v l . Различия между этими двумя версиями рассматриваются в следующих разделах. Примечание IGMP применяется только для поддержки членства хостов в группах в локальной подсети. Групповой IP-трафик посылается без IGMP-заголовка. В типичном случае для группового IP-трафика используются UDP-заголовки.
IGMP v1 IGMP версии 1 — простой протокол, предусматривающий всего два сообщения. Структура этих сообщений показана на рис. 4-2. Версия llil
Не используется Контрольная сумма Групповой адрес
Рис, 4-2. Структура сообщений IGMP vl Версия.
Поле длиной в 4 бита, в которое записывается значение 0x1 для IGMP vl.
Тип. Поле длиной в 4 бита, содержащее либо 0x1, либо 0x2. Первое значение указывает на то. что данное сообщение — Host Membership Query, посланное маршрутизатором группового IP-трафика в подсеть для получения текущей информации о членстве хостов в группах. Второе значение указывает на то, что данное сообщение — HOSL Membership Report, посланное хостом при присоединении к какой-либо группе или в ответ на сообщение Host Membership Query. Не используемое поле. Однобайтовое поле, устанавливаемое отправителем в 0x00 и игнорируемое получателем. Не используется. Контрольная сумма. Двухбайтовое поле, в которое записывается 16-битная контрольная сумма для данного IGMP-сообщения. Контрольная сумма IGMP не включает IP-заголовок.
ГЛАВА 4
Поддержка групповой IP-рассылки
125
Групповой адрес. Четырехбайтовое поле, которое в сообщении Host Membership Query содержит 0.0.0.0, а в сообщении Host Membership Report — конкретный групповой адрес.
Сообщение Host Membership Report Когда хост присоединяется к группе многоадресной рассылки, он посылает IGMPсообщение Host Membership Report на определенный групповой адрес независимо от того, имеются ли в его подсети другие хосты, уже являющиеся членами этой группы. В отличие от маршрутизатора группового трафика хост не отслеживает членство других хостов в группах. Поскольку в данном случае маршрутизатор работает в режиме прослушивания смешанного группового трафика, он полу част и обрабатывает IGMP-сообщения Host Membership Report, посылаемые на любой групповой адрес. Если служба маршрутизации и удаленного доступа в Windows 2000 сконфигурирована на использование протокола маршрутизации IGMP, если какой-либо интерфейс работает в режиме IGMP-маршрутизатора и если к группе хостов в контс >етпой подсети присоединяется первый хост, то протокол IGMP создает запись в таблице групп этого интерфейса (interface group table). При необходимости создастся и запись в таблице многоадресной IP-маршрутизации; в ней отмечается регистрируемый групповой адрес и интерфейс, по которому было принято IGMP-сообщение Host Membership Reporl.
Сообщение Host Membership Query Маршрутизатор TGMP vl периодически посылает IGMP-сообщение Host Membership Query на адрес 224.0.0.1 (адрес рассылки всем группам хостов), чтобы обновить свою информацию о членстве хостов в группах в данной подсети. В каждой группе хостов, члены которой имеются в дайной подсети, один из хостов отвечает IGMP-сообщением Host Membership Report. Механизм ответа на запрос маршрутизатора о членстве хостов в группах был рассмотрен в одном из предыдущих разделов. Получив ответ от группы хостов, служба маршрутизации и удаленного доступа в Windows 2000 продлевает срок действия соответствующей записи в таблице групп IGMP-интерфейса и оставляет в таблице многоадресной IP-пересылки запись для данной группы хостов. Если ответ на запрос по какой-либо группе хостов не поступает и срок действия соответствующей записи в таблице групп IGMP-интерфейса истекает, то IGMP удаляет запись о группе хостов из таблицы многоадресной пересылки. Значения IP-адресов источника и приемника, TTL в IP-заголовке и групповые адреса в IGMP-заголовке для двух типов сообщений IGMP vl показаны в таблице 4-1. Таблица 4-1. Адреса и значения TTL, используемые для сообщений IGMP vl Адрес
Host Membership Query
Host Membership Report
IP-адрес источника
[IP-адрес интерфейса маршрутизатора]
[IP-адрес интерфейса хоста]
IP-адрес приемника TTL Групповой адрес
224.0.0.1 1 0.0.0.0
[Групповой адрес] 1 [Групповой адрес]
126
ЧАСТЬ 1
Маршрутизация
Более подробную информацию см. в RFC 1112 (Appendix I).
IGMP v2 IGMP версии 2 расширяет функциональность IGMP, в то же время сохраняя обратную совместимость с IGMP версии 1, При использовании IGMP vl выбор маршрутизатора, посылающего периодические запросы, осуществляется протоколами многоадресной маршрутизации. В IGMP v2 процесс выборов такого маршрутизатора упрощен: в каждой подсети назначается один маршрутизатор, периодически посылающий IGMP-сообщения Host Membership Query. На его роль избирается маршрутизатор с наименьшим числовым значением IP-адреса. Процесс выборов заключается в том, что маршрутизатор прослушивает IGMP-запросы от других маршрутизаторов. Если принимается запрос с меньшим значением IP-адреса источника, слушающий остается рядовым маршрутизатором. Если запросы от других маршрутизаторов не поступают, слушающий становится опрашивающим — маршрутизатором, который периодически рассылает запросы. В IGMP v2 введено два новых типа сообщений: Host Membership Report v2 и Leave Group. Кроме того, добавлена разновидность сообщения Host Membership Query — Group-Specific Host Membership Query. Детальное описание этих сообщений см. в следующих разделах. Структура сообщений IGMP v2 показана на рис. 4-3. Inn Максимальное время ответа Контрольная сумма
Групповой адрес Рис. 4-3. Структура сообщений IGMP v2 Тип. Указывает тип IGMP-пакета. В IGMP v2 два четырехбитовых поля версии и типа, используемые IGMP vl, объединены в одно восьмибитовое поле типа. Типы сообщений IGMP v2 представлены в таблице 4-2. Таблица 4-2. Типы сообщений IGMP v2 Шестнздцатеричное значение
Десятичное значение Тип сообщения и описание
0x11 (поле версии IGMP v l , 17 равное 0x1, и поле типа IGMP vl, равное 0x1, становится полем типа IGMP v2, равным 0x11) 0x12 (поле версии TGMP vl. 18 равное 0x1, и поле типа IGMP vl. равное 0x2, становится полем типа IGMP v2, равным 0x12) 0x16
22
Сообщение Host Membership Query. Для общего запроса в поле группового адреса записывается 0.0.0.0, а для запроса, адресованного конкретной группе. •- адрес группы хостов. Сообщение Host Membership Report. Поле группового адреса указывает на группу хостов. Сообщение Host Membership Report версии 2. Поло группового адреса указывает па группу хостов.
ГЛАВА 4
Таблица 4-2.
Поддержка групповой IP-рассылки
127
(продолжение)
Шестнадцатеричное значение 0x17
Десятичное значение Тип сообщения и описание 23 Сообщение Leave Group. Поле группового адреса укалывает на группу хостов.
Максимальное время ответа. Однобайтовое поле, которое указывает максимальное время задержки (в десятых долях секунды), допустимой перед отправкой сообщения Host Membership Report в ответ на сообщение Host Membership Query. Это поле используется только в общих или адресованных конкретной группе запросах, Его значение соответствует значению параметра Query Response Interval (Интервал между ответами на запросы), который можно настроить одним из двух способов: •
на вкладке Router (Маршрутизатор) окна свойств IGMP-интерфейса в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ); • командой netsh routing ip igmp set interface.
Контрольная сумма. Двухбайтовое поле, в которое записывается 16-битная контрольная сумма для данного IGMP-сообщения. Контрольная сумма IGMP не включает IP-заголовок. Групповой адрес. Четырехбайтовое поле, которое в общем сообщении Host Membership Query содержит 0.0.0.0, а в сообщениях Host Membership Report, Leave Group и в адресованном конкретной группе Host Membership Query — конкретный групповой адрес.
IGMP-сообщение Host Membership Report версии 2 Это сообщение выполняет ту же функцию, что и IGMP-сообщение Host Membership Report версии 1, но принимается только маршрутизаторами IGMP v2.
Сообщение Leave Group Сообщение Leave Group позволяет сократить время, затрачиваемое на то, чтобы маршрутизатор прекратил пересылку группового трафика группе, в которой больше нет хостов. Если какой-нибудь хост отвечает на последний IGMP-запрос, он может быть последним или единственным членом данной группы хостов. Когда этот хост покидает группу, он посылает IGMP-сообщение Leave Group на адрес 224.0.0.2 (адрес рассылки всем маршрутизаторам в данной подсети). Получив сообщение Leave Group, маршрутизатор посылает серию запросов, адресованных дан.ной группе хостов. Если ни один хост не отвечает, маршрутизатор считает, что в данной группе больше нет хостов из данной подсети, и удаляет соответствующую запись из таблицы групп IGMP-интсрфейса.
IGMP-запрос, адресованный конкретной группе IGMP-сообщение Host Membership Query посылается на адрес 224.0.0.1 (адрес рассылки всем группам хостов), чтобы получить информацию о членстве хосте в в группах применительно к данной подсети. Маршрутизаторы IGMP v2 также могут посылать запрос, адресованный конкретной группе (направляемый непосредственно на адрес этой группы).
128
ЧАСТЬ 1
Маршрутизация
Значении IP-адресов источника и приемника, TTL в IP-заголовке и групповые адреса в ЮМР-заголовке для двух дополнительных типов сообщений IGMP v2 показаны в таблице 4-3. Таблица 4-3. Адреса и значения TTL, используемые для сообщений IGMP v2 Адрес IP-адрес источника
IGMP-залрос, адресованный конкретной группе
IGMP-сообщение Leave Group
IP-адрес приемника
[IP-адрес интерфейса маршрутизатора] [Запрашиваемая группа хостов]
[IP-адрес интерфейса хоста]
TTL
I
I
Групповой адрес
[Запрашиваемая группа хостов]
[Покидаемая группа хостов]
224.0.0.2
Более подробную информацию см. в RFC 2236,
Поддержка групповой IP-рассылки в службе маршрутизации и удаленного доступа Поддержка групповой IP-рассылки, предоставляемая службой маршрутизации и удаленного доступа в Windows 2000, состоит из следующих элементов: •
протокола IGMP;
•
ограничителей групповой рассылки (multicast boundaries);
• пульса групповой рассылки (multicast heartbeat);* •
туннелей IP-B-IP (IP-in-IP tunnels):
•
многоадресных статических маршрутов (multicast static routes).
Протокол IGMP Поскольку с Windows 2000 никаких протоколов многоадресной маршрутизации не поставляется, поддержка записей в таблице многоадресной IP-пересылки возлагается на IGMP -- компонент, добавляемый как один из протоколов маршрутизации IP. После установки IGMP к нему добавляются интерфейсы маршрутизатора. Каждый интерфейс, добавленный к протоколу маршрутизации IGMP, можно настроить на работу в одном из двух режимов: IGMP-маршрутизатора и IGMP-прокси. Эти режимы подробно рассматриваются в следующих разделах. Хотя IGMP предоставляет некоторые, довольно ограниченные возможности для создания или расширения межсетевой IP-среды с поддержкой многоадресной маршрутизации, он не является протоколом многоадресной маршрутизации, как, например, DVMRP или PIM. Не используйте IGMP в Windows 2000 для создания межсетевой IP-среды с поддержкой многоадресной маршрутизации произвольного размера или топологии. Подробнее о том, как можно применить маршрутизаторы Windows 2000 с установленным протоколом маршрутизации IGMP, см. раздел «Поддерживаемые конфигурации многоадресной пересылки» далее в этой главе.
В русской версии Windows 2000 Server этот термин называется пульсом многоадресной рассылки. -- Прим, перев.
ГЛАВА 4
Поддержка групповой IP-рассылки
129
Режим IGMP-маршрутизатора Если IGMP-интерфейс настроен на режим IGMP-маршрутизатора, он выполняет следующие функции. •
Работает в режиме прослушивания смешанного группового трафика. Если такой режим не поддерживается сетевым адаптером, в системном журнале регистрируется событие 20157 диспетчера IP-маршрутизатора (IP Router Managei).
• Прослушивает IGMP-сообщения Host Membership Report и Leave Group. Интерфейс и режиме IGMP-маршрутизатора прослушивает IGMP-сообщения Host Membership Report и Leave Group, посылаемые хостами в подсети. • Посылает IGMP-сообщения Host Membership Query, Интерфейс в режиме IGMP-маршрутизатора периодически посылает общие и адресованные конкретной группе хостов запросы после приема сообщения Leave Group. • Участвует в выборах опрашивающего IGMP-маршрутизатора (IGMP querier). Интерфейс в режиме IGMP-маршрутизатора участвует в выборах опрашимающего IGMP-маршрутизатора в своей подсети. •
Обрабатывает записи в таблице многоадресной IP-пересылки. На основе текущей информации о членстве хостов в группах в подсети IGMP ведет соответствующие записи в таблице многоадресной IP-пересылки.
Режим IGMP-маршрутизатора может быть разрешен на нескольких интерфейсах, причем на каждом интерфейсе можно включить любую из версий IGMP. По умолчанию предлагается IGMP v2.
Параметры режима IGMP-маршрутизатора IGMP v2, работающий в режиме IGMP-маршрутизатора, настраивается на каждом интерфейсе отдельно. Бы можете модифицировать соответствующие параметры, используя: •
вкладку Router (Маршрутизатор) окна свойств IGMP-иптерфсйса в оснастке Rouiing and Remote Access (Маршрутизация и удаленный доступ):
• команду netsh routing ip igmp set interface. Па рис. 4-4 показаны параметры режима IGMP-маршрутизатора для интерфейса Local Area Connection (Подключение по локальной сети) в оснастке Routing and Remote Access. Robustness Variable (Переменная надежности). Переменная, которая служит индикатором того, насколько чувствительна подсеть к потере пакетов. IGMP обеспечивает восстановление, если потери IGMP-пакетов не превышают значение переменной надежности за вычетом единицы. Вы можете указать другое значение этого параметра, отличное от предлагаемого но умолчанию (2). Переменная надежности должна быть не менее чем 2. Query Interval (Интервал между запросами). Промежуток времени (в секундах) между общими IGMP-запросами, посылаемыми маршрутизатором (если данный маршрутизатор является опрашивающим в этой подсети). Интервал по умолчанию — 125 секунд.
130
ЧАСТЬ 1
Маршрутизация
£eca( Area LenmH-Hun praps* ties
S^lupqugyi-ourttUuffiemba query countI
Enable шотайс. recalculate»! >
rsnp f) q икнет plesen! t
Рис. 4-4. Параметры маршрутизатора IGMP v2 Query Response Interval (Интервал между ответами на запросы). Максимальное время ожидания (в секундах) IGMP-маршрутизатора ответа на общий запрос. Интервал между ответами на запросы представляет содержимое поля максимального времени ответа в IGMP-сообщении Host Membership Query v2. Интервал по умолчанию — 10 секунд (должен быть меньше интервала между запросами). Last Member Query Interval (Интервал между запросами последнего участника). Время ожидания (в секундах) IGMP-маршрутизатора ответа на запрос, адресованный конкретной группе. Этот параметр также представляет собой интервал (в секундах) между успешными запросами, адресованными конкретной группе. Интервал по умолчанию — 1 секунда. Calculated Defaults (Вычисляемые значения по умолчанию). IGMP-переменные настраиваются вручную или автоматически — на основе значений переменной надежности и интервала между запросами. Для автоматической настройки установите флажок Enable automatic recalculation of defaults (Разрешить автоматический пересчет умолчаний). Startup Query Interval (Интервал между запросами при запуске). Интервал (в секундах) между успешными общими запросами, которые посылаются опрашивающим маршрутизатором в процессе запуска. Этот интервал по умолчанию составляет четверть интервала между запросами. Startup Query Count (Счетчик запросов при запуске). Число общих запросов, посылаемых при запуске. Значение этого счетчика по умолчанию — 2. Last Member Query Count (Счетчик запросов последнего участника). Число адресованных конкретной группе запросов, посылаемых перед тем, как данный маршрутизатор будет считать, что в группе, запрашиваемой по данному интерфейсу, больше нет хостов. Значение этого счетчика по умолчанию — 2.
ГЛАВА 4
Поддержка групповой IP-рассылки
131
Enable Automatic Recalculation of Defaults (Разрешить автоматический пересчет умолчаний). Указывает, надо ли автоматически вычислять значения интервала между запросами и счетчика запросов при запуске, а также счетчика запросов последнего участника. Вычисления осуществляются так: •
интервал между запросами при запуске приравнивается четверти интервала между запросами; • счетчики запросов при запуске и запросов последнего участника получают то же значение, что и переменная надежности.
Group Membership Interval (Интервал принадлежности к группе). Время (в секундах), по истечении которого маршрутизатор группового трафика считает, что в группе хостов больше нет членов, находящихся в данной подсети. Этот интервал вычисляется как (неременная надежности) * (интервал между запросами) + (интервал между ответами на запросы). Данный параметр определяется на основе вычислений, и его нельзя модифицировать вручную, Other Querier Present Interval (Интервал проверки присутствия других опросчиков). Время (в секундах), по истечении которого данный маршрутизатор группового трафика считает, что другие маршрутизаторы группового трафика не могут быть опрашивающими. Этот интервал вычисляется как [(переменная надежности) • (интервал между запросами) + (интервал между ответами на запросы)] / 2. Данный параметр определяется па основе вычислений, и его нельзя модифицировать вручную. Примечание
Подробнее об этих параметрах и их взаимосвязи см. RFC 2236.
Режим IGMP-прокси Если режим IGMP-маршрутизатора позволяет использовать интерфейс маршрутизатора для многоадресной пересылки, то режим IGMP-прокси — в качестве прокси-узла многоадресной пересылки (multicast proxy) для хостов, подключенных к интерфейсам, работающим в режиме IGMP-маршрутизатора. Когда IGMP-итерфейс настроен на режим IGMP-прокси, он выполняет следующие функции. •
Пересылает IGMP-сообщения Host Membership Report. Все IGMP-сообщения Host Membership Report, принятые на интерфейсах, работающих в режиме IGMP-маршрутизатора, ретранслируются по интерфейсу, работающему в режиме IGMP-прокси. • Регистрирует МАС-адреса групповой (многоадресной) рассылки. При использовании сетевых технологий разделяемого доступа типа Ethernet сетевой адаптер поначалу остается в режиме прослушивания адресного трафика. Для каждой уникальной группы хостов, зарегистрированной IGMP-сообщением Host Membership Report, которое пересылается на интерфейс IGMP-i poкси, сетевой адаптер программируется на сквозную передачу кадров с соответствующим МАС-адресом групповой рассылки. Каждый дополнительный групповой МАС-адрес требует отдельной записи в таблице MAC-адресов назначения на сетевом адаптере. Максимальное число записей в этой таблице ограничено и зависит от конкретного сетевого адаптера. Как только эта таблица пол-
132
ЧАСТЬ 1
Маршрутизация
ностыо заполняется, протокол маршрутизации IGMP переводит сетевой адаптер в режим прослушивания смешанного группового трафика. • Добавляет записи в таблицу многоадресной пересылки. Когда интерфейс, работающий в режиме IGMP-маршрутизатора, принимает нелокальный групповой трафик, протокол маршрутизации IGMP добавляет или обновляет запись в таблице многоадресной пересылки для дальнейшей передачи этого группового трафика с интерфейса lGMP-нрокси. Конечный результат этого процесса заключается в том, что любой нелокальный групповой трафик, принятый по интерфейсу режима IGMP-маршрутизатора, копируется па интерфейс IGMP-прокеи. • Принимает групповой трафик, полученный интерфейсами IGMP-прокси. Групповой трафик, принимаемый по интерфейсу IGMP-прокеи и адресованный группам, которые зарегистрированы хостами, подключенными к интерфейсам режима IGMP-маршрутизатора, перенаправляется на соответствующие интерфейсы с использованием IP-протокола и таблицы многоадресной пересылки. Предназначение режима IGMP-прокси подключить маршрутизатор Windows 2000 к межсетевой IP-среде с поддержкой многоадресной пересылки, например к МВопе, или к частной интрасети, в которой используются протоколы многоадресной маршрутизации иролс DVMRP и PIM. Интерфейс, работающий в режиме IGMP-прокси, действует как хост и присоединяется к группам в интересах хостов, подключенных к интерфейсам режима IGMP-маршрутизатора. Групповой трафик, посылаемый членам групп хостов, подключенных к интерфейсам режима IGMP-маршрутизатора, принимается интерфейсом IGMP-прокси и перенаправляется с использованием процесса многоадресной IP-пересылки. Групповой трафик, посылаемый хостами, подключенными к интерфейсам режима IGMP-маршрутизатора, передается на интерфейс IGMP-прокси, откуда следующий от источника группового трафика маршрутизатор может либо переслать этот трафик дальше, либо проигнорировать его. Режим IGMP-прокси можно включить только на одном IGMP-интерфейсе. Этот интерфейс должен быть подключен к какой-нибудь полсети, в которой присутствует маршрутизатор группового трафика с установленными протоколами многоадресной маршрутизации. Иначе говоря, интерфейс IGMP-прокси «указывает* на интрасеть с поддержкой многоадресной пересылки,
Сравнение режимов IGMP-маршрутизатора и IGMP-прокси Особенности и функциональность режимов IGMP-маршрутизатора и IGMP-прокси суммированы в таблице 4-4. Таблица 4-4. Сравнение режимов IGMP-маршрутизатора и IGMP-ирокси Функциональность Режим IGMP-маршрутизатора IGMP-маршрутизатор Действует как маршрутизатор или хост группового трафика на основе IGMP и прослушивает IGMP-сообщения Host Membership Report
Режим IGMP-прокси Действует как IGMP-хост, пересылая IGMP-сообщения Host Membership Report и отвечая на IGMP-запросы; прослушивает IGMP-сообщения Hosi Membership Report как хост, а не как маршрутизатор
ГЛАВА 4 Таблица 4-4. Функциональность
Поддержка групповой IP-рассылки
(продолжение) Режим IGMP маршрутизатора
Режим прослушивания Прослушивание смешанного группового трафика Обновление таблицы Обновляет таблицу многомногоадресной адресной IP-пересылки IP-пересылки на основе IGMP-трафика Отправка IGMP-запросов
133
Посылает IGMP-запросы для поддержания таблицы нересылки в актуальном состоянии
Режим IGMP-прокси Прослушивание адресного трапика Обновляет таблицу многоадресной IP-пересылки для распространения нелокального группового трафика, принимаемого но интерфейсам режима IGMP-маршрутизатор;! Никаких IGMP-запрогон не посылает
Ограничители групповой рассылки Ограничители групповой рассылки это настраиваемые административные барьеры, ограничивающие пересылку группового трафика рамками определенной области межсетевой IP-среды. Без таких ограничителей пересылается весь групповой IP-трафик. На маршрутизаторе Windows 2000 ограничители групповой рассылки можно определять на основе диапазона IP-адресов, называемого многоадресной областью (multicast scope), значения поля TTL (Time-To-Live) в IP-заголовке или максимального объема группового трафика. Ограничители групповой рассылки настраиваются па каждом интерфейсе отдельно. Для этого используется вкладка Multicast Boundaries (Границы многоадресной области) в окне свойств нужного интерфейса, которое открывается из папки General (Общие) узла IP Routing (IP-маршрутизация) в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ).
Ограничители на основе областей Диапазон IP-адресов групповой рассылки 239.0.0.0/8 определяется как административно выделенное адресное пространство IP-рассылки. Передачу или прием по групповым адресам из этого диапазона можно запретить за счет применения ограничителей на основе областей (.scope-based boundaries). Ограничитель па основе области определяет границу, за пределы которой групповой пакет, направляемый на определенный диапазон адресов, не пересылается. Чтобы сконфигурировать многоадресную область (диапазон IP-адресов групповой рассылки) для использования ограничителей, Вы должны сначала добавить эту область одним из двух способов: •
с помощью вкладки Multicast Scopes (Многоадресные области) окна общих свойств IP-маршрутизации. Для этого в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IP Routing (IP-маршрутизация), щелкните правой кнопкой мыши папку General (Общие) и выберите команду Properties (Свойства); • командой netsh routing ip set scope. Вы должны указать соответствующий области диапазон адресов в виде IP-адреса и маски. Однако локальная область 239.25.5.0.0/16 всегда исключается. Так
134
ЧАСТЬ 1
Маршрутизация
что определяемые Вами области должны укладываться в диапазон от 239.0.0.0 до 239.254.255.255. Чтобы охватить диапазон IP-адресов групповой рассылки, введите соответствующий IP-адрес и маску, охватывающую этот диапазон. А в случае единственного группового адреса введите требуемый IP-адрес и маску, равную 255,255.255.255. Создав области, Вы можете создать соответствующие ограничители для отдельных интерфейсов, используя вкладку Multicast Boundaries (Границы многоадресной области) в окне свойств нужного интерфейса. Подробнее об административном управлении групповым IP-трафиком см. RFC 2356.
Ограничители на основе TTL Ограничители на основе TTL (TTL-based boundaries) препятствуют пересылке групповых IP-пакетов с TTL, меньшими определенного значения. Ограничители на основе TTL применяются ко всем групповым пакетам независимо от того, какой группе хостов они адресованы. Типичные пороговые значения TTL, используемые в таких случаях, показаны в таблице 4-5. Таблица 4-5. Пороговые значения TTL Пороговое значение TTL 1
1 ! 15 63 127 191 255
Запрещаемая область Тот же хост Та же подсеть Тот же сайт Тот же регион Глобальная Глобальная; ограниченная полоса пропускания Без ограничений
Таким образом, установив на каком-либо интерфейсе пороговое TTL в 15, Вы запретите пересылку группового IP-трафика, не рассчитанного на передачу за пределы сайта*. Будет пересылаться только региональный и прочий трафик. Ограничители на основе TTL менее эффективны, чем ограничители на основе областей. Более подробную информацию см. в RFC 2365.
Ограничение максимального объема группового трафика Для введения такого ограничения Вы устанавливаете предел скорости передачи группового трафика в Кб/с.
Пульс групповой рассылки Пульс групповой рассылки (multicast heartbeat) — это групповые уведомления, регулярно посылаемые на определенный групповой адрес. Пульс групповой рассылки используется для проверки возможности соединений в сети для передачи группового IP-трафика. Если по какому-либо интерфейсу пульс групповой рассылки в течение определенного времени не прослушивается, состояние этого интерфейса
* Следует иметь в виду, что под сайтом подразумевается совокупность подсетей с серверами Active Directory. — Прим. nepe.fi.
ГЛАВА 4
Поддержка групповой IP-рассылки
135
считается неактивным. Чтобы маршрутизатор Windows 2000 распознавал отсутствие пульса групповой рассылки, Вы должны создать механизм опроса, пери* мипески проверяющий состояние пульса групповой рассылки. Как только его состояние становится неактивным, возникает уведомляющее событие, определенное Влми. Подробнее на эту тему см. по ссылке Microsoft Platform SDK на http://windows.niicrosoft.coin/windows2000/reskit/vvebresources. Допустим, Вы решили создать механизм, который посылает SNMP-перехват сконфигурированной станции управления SNMP в тот момент, когда состояние пульса групповой рассылки становится неактивным. Для этого Вам потребуется создать субагент SNMP, а агент SNMP па маршрутизаторе Windows 2000 настроить на гмя SNMP-сообщества, указав при этом, кому будут посылаться перехваты. Подробнее на эту тему см. главу 10 «SNMP» в книге «Сети TCP/IP* и.ч серии «Ресурсы Microsoft Windows 2000 Server». Стандартный протокол, применяемый для передачи пульса групповой рассылки, — SMTP (Simple Network Time Protocol). SNTP использует зарезервированный групповой IP-адрес 224.0.1.1 и предназначен для синхронизации по времени. Если источник трафика, связанного с пульсом групповой рассылки (SNTP-сервер), размещен на стратегическом участке межсетевой среды, то потеря пульса будет указывать на наличие какой-либо проблемы в инфраструктуре многоадресной IP-маршрутизации. Windows 2000 Server включает SNTP-сервер — Windows Time Synchronization Service (W32Time) (Служба времени Windows) — и SNTP-клиент. Подробнее о SNTP см. RFC 1769. Вы можете настроить пульс групповой рассылки на вкладке Multicast Heartbeat (Пульс многоадресной рассылки) окна свойств интерфейса, открываемого из папки General (Общие) узла IP Routing (IP-маршрутизация) в оснастке Routing iind Remote Access (Маршрутизация и удаленный доступ).
Туннели IP-B-IP Туннели IP-B-IP (IP-in-IP tunnels) используются для пересылки информации между конечными точками, образующими мост между разными частями межсетевой IPсреды с разными возможностями. Типичное применение туннелей IP-B-IP — пересылка группового IP-трафика из одной области интрасети в другую через участок, на котором пересылка или маршрутизация группового трафика не поддерживается. При таком туннелировании IP-дейтаграмма инкапсулируется другим 1Р-заголовком для передачи между конечными точками туннеля ГР-в-IP, как показано на рис. 4-5. Признаком туннеля IP-в-ТР служит значение 4 в поле IP-протокола внешнего IP-заголовка. Подробнее о туннелировании IP-B-IP см. RFC 1853.
Рис. 4-5. Структура пакета при туннелировании IP-B-IP
Интерфейсы IP-B-IP Интерфейс IP-B-1P — это логический интерфейс, который посылает IP-пакеть в режиме туннелирования. Чтобы создать такой интерфейс, запустите оснастку Routing and Remote Access (Маршрутизация и удаленный доступ), щелкните пра-
136
ЧАСТЬ 1
Маршрутизация
вой кнопкой мыши папку Routing Interfaces (Интерфейсы маршрутизации) и выберите команду New Tunnel (IP only) (Создать IP-туннель). Создав туннель, добавьте его как интерфейс IP-маршрутизации, для чего раскройте узел IP Routing (IP-маршрутизация), щелкните правой кнопкой мыши папку General (Общие) и выберите команду New Interface (Новый интерфейс). После создания всех интерфейсов lP-в-ТР и добавления их в качестве интерфейсов IP-маршрутизации Вы должны определить конечные точки туннеля. Затем Вы можете настроить эти интерфейсы точно так же, как и любой другой IP-интерфейс.
Многоадресные статические маршруты Когда по интерфейсу маршрутизатора Windows 2000 с поддержкой многоадресной пересылки принимается групповой IP-пакет, IP-адреса источника и назначения этого пакета проверяются в записях таблицы многоадресной IP-пересылки. Если подходящая запись найдена, групповой IP-пакет пересылается по маршруту, указанному в УТОЙ записи. Если па пути за д а н н ы м маршрутизатором членов нужной группы хостов нет, пакет просто отбрасывается. Если запись не найдена, она должна быть создана. Запись в таблице многоадресной IP-пересылки состоит из группового адреса, IP-адреса источника, списка интерфейсов, по которым пересылается трафик (интерфейсы следующего перехода), и одного интерфейса, по которому должен поступать трафик для дальнейшей пересылки (интерфейс предыдущего перехода). Групповой адрес и IP-адрес источника извлекаются из группового пакета. Интерфейсы следующего перехода определяются при регистрации членства хостов в группах с использованием IGMP (и любых протоколов многоадресной маршрутизации, если они есть). Интерфейс предыдущего перехода — это интерфейс, ближайший (в терминах метрик маршрутов) к источнику ГР-трафнка. Для определения такого интерфейса просматриваются записи в таблице многоадресной маршрутизации. В качестве интерфейса предыдущего перехода выбирается один интерфейс с наилучшим маршрутом обратно к источнику группового IP-пакета. Наилучшим считается маршрут, наиболее точно соответствующий многоадресному маршруту с минимальной метрикой. Таблица многоадресной маршрутизации (multicast routing table) логически отделена от таблицы одноадресной маршрутизации (imicast routing table), также называемой просто таблицей маршрутизации. Диспетчер таблиц маршрутизации (Route Table Manager, RTM) службы маршрутизации и удаленного доступа хранит мастерсписок маршрутов, или таблицу маршрутизации RTM (RTM routing table). Каждый маршрут помечается как одноадресный или как многоадресный, или как то и другое. Следовательно, список получаемых маршрутов зависит от выбранного Вами представления. Набор одноадресных маршрутов в таблице маршрутизации RTM называется одноадресным представлением (unicast view), а набор многоадресных маршрутов в той же таблице — многоадресным (multicast view). Одноадресное представление таблицы маршрутизации RTM используется для определения интерфейса предыдущего перехода и соседа на предыдущем переходе, что необходимо для диагностических утилит тина Ml race. По умолчанию все одноадресные маршруты, получаемые протоколами маршрутизации RIP и OSPF, а также статические маршруты, вручную сконфигурированные с помощью оснастки Routing and Remote Access, помечаются как появляющиеся в
ГЛАВА 4
Поддержка групповой IP-рассылки
137
обоих представлениях. Если Ваши маршрутизаторы адресного трафика являются и маршрутизаторами группового трафика, никаких изменений не требуется. Однако Б некоторых конфигурациях инфраструктуры одноадресной и многоадресной маршрутизации различны. Например, чтобы сбалансировать нагрузку. Вы используете для адресного и группового трафика разные наборы маршрутизаторов. Тогда Вам скорее всего придется отказаться от предлагаемого по умолчанию добавления всех маршрутов в одноадресное и многоадресное представления и создать многоадресный статический маршрут командой netsh routing ip add rtmroute. Пример одной из таких конфигураций — маршрутизатор Windows 2000 с двумя интерфейсами: первый подключен к одноадресному маршрутизатору, а второй — к многоадресному. Для упрощения примера будем считать, что для пересылки всего нелокального одноадресного IP-трафика па следующий маршрутизатор через интерфейс 1 используется единственный статический маршрут по умолчанию. Поскольку этот статический маршрут был сконфигурирован в оснастке Routing and Remote Access, on помечается и как одноадресный, и как многоадресный. А теперь представьте, что получится, когда по интерфейсу 2 будет принят групповой IP-пакет. Чтобы создать запись в таблице многоадресной IP-пересылки, ну.'Кно определить интерфейс предыдущего перехода. На основе многоадресного представления таблицы маршрутизации RTM и качестве такового будет выбран интерфейс 1, а не интерфейс 2, так как первый находится ближе к источнику группового трафика (в терминах метрик маршрутов). Поскольку групповые IP-пакеты, направляемые группе и на IP-адрес источника, могут быть приняты только по интерфейсу предыдущего перехода, групповые IP-пакеты, поступающие на интерфейс 2, будут «молча» отбрасываться. Чтобы избежать этой проблемы, используйте команду netsh routing ip add rtmroute и создайте многоадресный статический маршрут по умолчанию, который использует интерфейс 2 и имеет меньшую метрику. Этот новый маршрут заменит статический маршрут по умолчанию.
Поддерживаемые конфигурации многоадресной пересылки Поскольку IGMP-маршрутизатор и TGMP-прокси, включенные в службу маршрутизации и удаленного доступа Windows 2000, не могут заменить какой-либо протокол многоадресной маршрутизации (например, DVMRP или Р1М), в следующих разделах описываются рекомсн.-чуемые и поддерживаемые конфигурации маршрутизатора Windows 2000 с применением протокола маршрутизации IGA1P, а также режимов IGMP-маршрутизатора и IGMP-прокси.
Интрасеть с единственным маршрутизатором Маршрутизатор Windows 2000 обеспечивает полнопенную поддержку многоадресной пересылки в интрасети с единственным маршрутизатором. В этой конфигурации все интерфейсы добавляются к протоколу маршрутизации 1GMP, и каждый интерфейс настраивается па режим IGMP-маршрутизатора. Тогда любой хосг в любой подсети может передавать и принимать групповой трафик от любого другого хоста. Весь групповой трафик пересылается в те подсети, где находятся члены групп хостов.
138
ЧАСТЬ 1
Маршрутизация
Конфигурация интрасети с единственным маршрутизатором показана на рис, 4-6.
Режим IGMPмаршрутизатора
г Режим IGMPмаршрутизатора
Режим IGMPмаршрутизатора Марирутизатор Windows 2000 I- Режим IGMPмаршрутизатора
Рис. 4-6. Интрасеть с единственным маршрутизатором
Интрасеть с единственным маршрутизатором и подключением к МВопе Маршрутизатор Windows 2000 обеспечивает поддержку многоадресной пересылки в интрасети с единственным маршрутизатором и подключением к МВопе. Б этой конфигурации все интерфейсы добавляются к протоколу маршрутизации IGMP. Интерфейсы частных подсетей настраиваются на режим IGMP-маршрутизатора, а Интернет-интерфейс — на режим lGMP-нрокси. Хосты, присоединяющиеся к группам, посылают IGMP-сообщения Host Membership Report, которые затем копируются на Интернет-интерфейс. На тот же интерфейс передается групповой трафик из Интернета. После приема этот трафик пересылается хосту в соответствующей подсети. Групповой трафик, посылаемый хостом, который находится в одной из подсетей интрасети, копируется на Интернетинтерфейс. А маршрутизатор группового трафика, размещенный у провайдера услуг Интернета (ISP), либо игнорирует, либо пересылает этот трафик. В такой конфигурации групповой трафик, передаваемый между двумя хостами в частной интрасети, копируется и на Интернет-интерфейс, что приводит к пеэффек- Режим IGMPмаршрушзатора Режим IGMPмаршрутизатора Режим IGMP-прокси Маршрутизатор Windows 2000 Internet МВопе
Рис. 4-7. Интрасеть с единственным маршрутизатором и подключением к МВопе
ГЛАВА 4
Поддержка групповой IP-рассылки
139
тившшу использованию пропускной способности канала связи с 1SP. Чтобы избежать копирования внутреннего группового трафика на Интернет-интерфейс, настройте приложения или диапазоны групповых адресов на MADCAP-серверах интрасоти на использование групповых IP-адресов из административно выделенного диапазона 239.0.0.0-239.254.255.255 и создайте подходящий ограничитель на основе области, действующий применительно к Интернет-интерфейсу. Конфигурация интрасети с единственным маршрутизатором и подключением к МВопе показана на рис. 4-7.
Периферийный маршрутизатор в интрасети с поддержкой групповой рассылки В этой конфигурации, очень похожей на предыдущую, маршрутизатор Windows 2000, обеспечивая поддержку многоадресной пересылки, выступает в роли периферийного маршрутизатора, который подключен к частной интрасети с поддержкой групповой рассылки. Периферийным называется маршрутизатор, подключенный к нескольким подсетям, из которых лишь одна содержит другой маршрутизатор. В такой ситуации последний является основным маршрутизатором группового трафика в интрасети с поддержкой групповой рассылки, и на нем работают все необходимые протоколы маршрутизации. В данном случае все интерфейсы добавляются к протоколу маршрутизации IGIV1P. Интерфейсы, не связанные с маршрутизатором группового трафика, настраиваются на режим IGMP-маршрутизатора, а интерфейс, подключенный к подсети с основным маршрутизатором группового трафика, — на режим ЮМР-прокси. Хосты, присоединяющиеся к группам, посылают IGMP-сообщения Host Membership Report, которые копируются на интерфейс, подключенный к подсети с основным маршрутизатором группового трафика. Групповой трафик из интрасети пересылается на интерфейс, работающий в режиме ЮМР-прокси. После приема этот трафик пересылается хосту в соответствующей подсети. Групповой трафик, посылаемый хостом, который находится в одной из подсетей, подключенных к интер- Режим IGMPмаршрушзатора Режим IGMPмаршрутизатора Режим ЮМР-прокси Маршрутизатор Windows 2000
Основной маршрутизатор f illf- группового трасрика
Инграсеть с поддержкой групповой рассылки
Рис. 4-8. Периферийный маршрутизатор в интрасети с поддержкой групповой рассылки
140
ЧАСТЬ 1
Маршрутизация
фейсу IGMP-маршрутизатора, копируется на интерфейс IGMP-прокси. А основной маршрутизатор группового трафика либо игнорирует, либо пересылает этот трафик находящимся за ним членам групп хостов. Периферийный маршрутизатор в интрассти с поддержкой групповой рассылки показан на рис. 4-8.
Поддержка групповой рассылки для клиентов удаленного доступа Протокол маршрутизации IGMP в Windows 2000 часто используется для предоставления сервисов групповой рассылки клиентам удаленного доступа, которые соединяются по коммутируемым линиям или через виртуальные частные сети (VPK). По аналогии с предыдущими конфигурациями сервер удаленного доступа или VPN-cepRcp Windows 2000 выступает и роли периферийного маршрутизатора для межсетевой IP-среды с поддержкой многоадресной пересылки. В данном случае возможны две конфигурации: •
MBone-доступ, предоставляемый провайдером услуг Интернета (ISP) клиентам удаленного доступа, которые подключаются по коммутируемым линиям (dialup clients);
• доступ к частной сети с поддержкой групповой рассылки для клиентов удаленного доступа, которые подключаются по коммутируемым линиям или через VPN.
MBone-доступ для клиентов, подключающихся к ISP по коммутируемым линиям Если Вы — в качестве ISP — используете службу маршрутизации и удаленного доступа Windows 2000 для того, чтобы предоставлять доступ к Интернету клиентам удаленного доступа, подключающимся по коммутируемым линиям, то должны выполнить следующие операции. 1. Добавьте к протоколу маршрутизации IGMP интерфейс Internal (Внутренний) и интерфейс, соединенный с Интернетом. Внутренний интерфейс представляет все клиенты удаленного доступа. 2. Настройте интерфейс Internal па режим IGMP-маршрутизатора. 3. Настройте Интернет-интерфейс на режим IGMP-прокси. Подключенные клиенты удаленного доступа, присоединяясь к группам хостов, посылают IGMP-сообщсния HOSL Membership Report, которые копируются на Интернет-интерфейс. На этот же интерфейс поступает и групповой трафик из Интернета. После приема групповой трафик пересылается подключенному хосту (клиенту удаленного доступа). Групповой трафик, посылаемый подключенным хостом, пересылается другим подключенным членам групп хостов и копируется на Интернетинтерфейс. Следующий маршрутизатор группового трафика в Интернете либо игнорирует групповой трафик, либо пересылает его членам групп хостов, расположенным за ним. Конфигурация МБопе-доступа, предоставляемого клиентам, которые подключаются к ISP по коммутируемым линиям, показана на рис. 4-9.
ГЛАВА 4
Поддержка групповой !Р-рассылки
141
- Режим IGMP-маршрутизатора Режим IGMP-прокси Клиенты ISP
Сервер удаленного доступа -I под управлением Windows 2000
МВопе
Рис. 4-9. MBone-доступ, предоставляемый клиентам, подключающимся к ISP по коммутируемым линиям
Доступ к частной сети для клиентов, подключающихся по коммутируемым линиям или через VPN Если Вы используете службу маршрутизации и удаленного доступа Windows 2000 для того, чтобы предоставлять доступ к интрасети клиентам удаленного доступа, подключающимся по коммутируемым линиям или через VPN, то должны выполнить следующие операции. 1. Добавьте к протоколу маршрутизации IGMP интерфейс Internal (Внутренний) и интерфейс, соединенный с частной интрасетью. Внутренний интерфейс представляет все клиенты удаленного доступа. Интерфейс частной интрасети должен быть подключен к подсети, содержащей основной маршрутизатор группового трафика. 2. Настройте интерфейс Internal на режим IGMP-маршрутизатора. 3. Настройте интерфейс частной интрасети па режим IGMP-прокси. Подключенные клиенты удаленного доступа, присоединяясь к группам хостов, посылают IGMP-сообщения Host Membership Report, которые копируются па интерфейс частной интрасети. На этот же интерфейс поступает и групповой трафик из интрасети. После приема групповой трафик пересылается полключенным членам групп хостов (клиентам удаленного доступа). Групповой трафик, посылаемый под- Режим IGMP-маршрутизатора Режим IGMP-прокси Клиенты удаленного доступа
Основной маршрутизатор группового трафика
-Сервер удаленного доступа или VPN-cepsep под управлением Windows 2000 Интрасеть с поддержкой групповой рассылки
Рис. 4-10, Доступ к частной интрасети для клиентов, подключающихся по коммутируемым линиям или через VPN
142
ЧАСТЬ 1
Маршрутизация
ключенным хостом, пересылается другим подключенным членам групп хостов и копируется на интерфейс частной иптрасети. Основной маршрутизатор группового трафика либо игнорирует групповой трафик, либо пересылает его членам групп хостов, расположенным за ним. Конфигурация доступа к частной интрасети, предоставляемого клиентам, которые подключаются по коммутируемым линиям или через VPN, показана на рис. 4-10. Подробнее о поддержке групповой рассылки сервером удаленного доступа см. главу 7 «Сервер удаленного доступа* в этой книге.
Поддержка многоадресной пересылки для сетей филиалов Маршрутизатор 2000 обеспечивает полноценную поддержку многоадресной пересылки для филиала с единственным маршрутизатором, подключенным к интрасети центрального офиса с поддержкой групповой рассылки. Эта конфигурация требует должной настройки как маршрутизатора филиала, так и маршрутизатора центрального офиса. В случае маршрутизатора филиала все его интерфейсы добавляются к протоколу маршрутизации IGMP, причем интерфейсы, подключенные к подсетям филиала, настраиваются на режим IGMP-маршрутизатора. Интерфейс, соединенный с маршрутизатором центрального офиса, настраивается на режим IGMP-прокси. Этот интерфейс может быть LAN-интерфейсом (при использовании соединения на основе, например, Т-Сагпег или Frame Relay) или интерфейсом соединения по требованию (при использовании, например, коммутируемой линии вроде аналоговой телефонной и ISDN или VPN-соединения между маршрутизаторами). Подробнее об интерфейсах соединения по требованию и их конфигурациях см. главу 6 «Маршрутизация с соединением по требованию» в этой книге. Б случае маршрутизатора центрального офиса все его интерфейсы добавляются к протоколу маршрутизации IGMP, причем интерфейс, подключенный к филиалу, настраивается на режим IGMP-маршрутизатора. Этот интерфейс может быть LANинтерфейсом (при использовании соединения на основе, например, Т-Carrier или Frame Relay) или интерфейсом соединения по требованию (при использовании, например, коммутируемой линии вроде аналоговой телефонной и ISDN или VPNсоединения между маршрутизаторами). Наконец, интерфейс, соединенный с подсетью, в которой находится основной маршрутизатор группового трафика, настраивается на режим IGMP-прокси. IGMP-сообщения Group Membership Report для членов групп хостов копируются по каналу связи с центральным офисом в подсеть с основным маршрутизатором группового трафика. Через канал связи с центральным офисом в эту подсеть передается и групповой трафик от хостов филиала. В такой конфигурации групповой трафик, передаваемый между двумя хостами в интрасети филиала, поступает и в канал связи с центральным офисом, что приводит к неэффективному использованию пропускной способности этого канала. Чтобы избежать этого, настройте приложения или диапазоны групповых адресов на MADCAP-серверах интрасети на использование групповых IP-адресоь из административно выделенного диапазона 239.0.0.0-239,254.255.255 и создайте подходящие ограничители на основе областей, действующие применительно к интерфейсу, связанному с центральным офисом.
ГЛАВА 4 Поддержка групповой IP-рассылки
143
Конфигурация поддержки многоадресной пересылки для сетей филиалов представлена на рис. 4-11. Филиал
<"KJi • v
^-J^ 'li "*fN _
_. цкм фйиьмы11 ифии
Канал связи с центральным г офисом
Маршрутизатор Windows 2000 Режим IGMPмаршрут/затара
\ ir
:
Of l^ Маршрутизатор Windows 2000
Режим J IGMP-прокси
\
Режим IGMP- маршрутизатора Режим J IGMP-прок ;и
,Х'"'
Основной маршрутизатор : группового трафика Интрасеть с поддержкой групповой рассылки
Рис. 4-11. Поддержка многоадресной пересылки для сетей филиалов
Средства диагностики Для устранения проблем с групповой IP-рассылкой служба маршрутизации и удаленного доступа Windows 2000 предоставляет: • таблицы оснастки Routing and Remote Access; •
команду Mrinfo;
•
поддержку Мtrace;
•
команды Netsh;
•
поддержку регистрации событий IGMP;
•
поддержку трассировки.
Подробнее об общих принципах выявления и устранения проблем с групповой рассылкой см. проект Интернет-документа «Multicast Debugging Handbook».
Таблицы оснастки Routing and Remote Access С помощью этой оснастки можно просмотреть три таблицы, содержащих информацию о групповой IP-рассылке: •
Multicast Forwarding Table (Таблица многоадресного перенаправления);
144 • •
ЧАСТЬ 1
Маршрутизация
Multicast Statistics (Статистика многоадресной рассылки); IGMP Interface Group Table (Таблица интерфейса IGMP-группы)*.
Таблица многоадресной пересылки Таблица многоадресной пересылки** - это таблица, используемая ТР для пересылки группового IP-трафика. В каждой ее записи регистрируется определенная группа хостов и источник трафика. В колонке Туре (Тип) сообщается Active, если идет пересылка пакетов для данной группы хостов, или Negative, если соответствующий трафик в сети имеется, но маршрутизатор не пересылает его, так как для данной группы никаких хостов не зарегистрировано. Чтобы просмотреть таблицу многоадресной пересылки, раскройте узел IP Routing (IP-маршрутизация), щелкните правой кнопкой мыши папку General (Общие) и выберите команду Show Multicast forwarding table (Отобразить таблицу многоадресного перенаправления).
Статистика групповой рассылки Статистика групповой рассылки предстанлена счетчиками и другой информацией, поддерживаемой IP для каждой группы хостов, которой пересылается групповой трафик. В каждой записи таблицы статистики групповой расылки регистрируется групповой адрес, IP-адрес источника группового трафика, интерфейс, по которому был принят этот трафик, число принятых пакетов и прочие сведения. Чтобы просмотреть статистику групповой рассылки, раскройте узел IP Routing (IP-маршрутизация), щелкните правой кнопкой мыпти папку General (Общие) и выберите команду Show Multicast statistics (Отобразить статистику многоадресной рассылки).
Таблица IGMP-rpynn Эта таблица сообщает информацию о членстве хостов в группах, зарегистрированных на всех интерфейсах, работающих в режиме IGMP-маршрутизатора. В каждой записи этой таблицы регистрируется время работы (сколько секунд прошло с момента регистрации группы), истечение срока (сколько секунд осталось до окончания срока существования группы, если ни один хост не отправит на этот адрес IGMP-сообщение Host Membership Report) и прочие сведения. Чтобы просмотреть IGMP Group Table (Таблицу IGMP-групп), раскройте узел IP Routing (IP-маршрутизация), щелкните правой кнопкой мыши папку IGMP (IGMP) и выберите команду Show group table (Отобразить таблицу групп).
* В разных частях пользовательского интерфейса оснастки Routing and Remote Access в русской ворсин Windows 2000 Server эта таблица называется либо «Таблица интерфейса IGMPфуппы». либо «Таблица IGMP-групп». Первое название используется при просмотре таблицы применительно к конкретному интерфейсу, а второе — при просмотре сводной таблицы по всем интерфейсам. Здесь рассматриваются обе таблицы. Следует также отметить, что название «Таблица интерфейса IGMP-группы» неправильно, так как речь идет о группах, зарегистрированных на данном интерфейсе, а не об интерфейсе какой-то одной группы. — Прим. переа, * В русской версии Windows 2000 Server используется термин «таблица многоадресного перенаправления». По мере возможности мы стараемся употреблять вместо термина «многоадресный» термин «групповой*, который гораздо точнее отражает смысл оригинального термина «multicast». - Прим. перев.
ГЛАВА 4
Поддержка групповой IP-рассылки
145
Таблица групп IGMP-интерфейса Эта таблица сообщает информацию о членстве хостов в труппах, зарегистрированных па конкретном интерфейсе, работающем в режиме IGMP-маршрутизатора. В каждой записи этой таблицы регистрируется время работы (сколько секунд прошло с момента регистрации группы), истечение срока (сколько секунд осталось до окончания срока существования группы, если пи один хост не отправит на ;-JTOT адрес IGMP-сообщение Host Membership Report) и прочие сведения. Чтобы просмотреть IGMP Interface Group Table (Таблица интерфейса IGMP-rpynпы), раскройте узел IP Routing (IP-маршрутизация), щелкните правой кнопкой мыши нужный интерфейс в лапке IGMP (IGMP) и выберите команду Show interface group table (Отобразить таблицу групп интерфейса).
Команда Mrinfo Windows 2000 поддерживает команду mrinfo, которая позволяет просматривать конфигурацию маршрутизатора группового трафика. Эта информация может пригодиться при выявлении и устранении проблем с многоадресной пересылкой и маршрутизацией. Команда mrinfo посылает указанному маршрутизатору группового трафика специальный запрос. В ответе на этот запрос сообщается номер версии, список интерфейсов и соседей на каждом интерфейсе, метрики, пороговые значения TTL и флаги. Синтаксис команды mrinfo выглядит так:* mrinfo [ -d уровень_отладки ] [ -г число_повторов ] [ -t таймаут ] маршрутизатор Таблица 4-6. Параметры команды Mrinfo Параметр
Описание
-d
Уровень отладки. По умолчанию — 0. Если уровень отладки равен 1, отображ,.ются вес предупреждения, связанные с пакетами. Если уровень отладки равен 2, покалываются уведомления об отключенных сетях и все сообщения уровня 1. А если уровень отладки равен 3, выводятся уведомления о таймаутах пакетов и все сообщения уровня 2. Число повторных попыток получения информации о соседях. По умолчанию - 3. Время ожидания (в секундах) ответа на запрос о соседях. По умолчанию — 4.
-г -t
Вот пример использования команды mrinfo: C:\>rcrinfo 10.1.0.1 10.1.0.1 (testl.ntdev.microsoft.com) [version 20.50,mtrace,snmp]: 10.1.0.1 -> 0.0.0,0 (local) [1/0/querier/leaf] 10.2.0.1 -> 10.2.0,2 (test2.ntdev.microsoft.com) [1/0] 10.2.0.1 -> 10.2.0.3 (test3.ntdev.microsoft.com) [1/0] 10.3.0.1 -> 0 . 0 . 0 . 0 (local) [1/0/querier/leaf]
В этом примере mrinfo выполняется применительно к маршрутизатору (группового трафика) с адресом 10.1.0.1. В первой строке показывается конфигурация этого маршрутизатора: номер версии (в случае маршрутизаторов Windows 2000 тлжер * По крайней мери в русской версии команды mrinfo параметр -d не поддерживается, - Прим. персе.
146
ЧАСТЬ 1
Маршрутизация
версии отражает номер сборки Windows 2000) и флаги (в данном случае сообщается, что поддерживаются mtrace и SNMP). В каждой последующей строке отображается информация об интерфейсах маршрутизатора группового трафика и о соседях на каждом интерфейсе. На интерфейсах 10.1.0.1 и 10.3.0.1 соседей нет, а на интерфейсе 10.2.0.1 есть два соседа: 10.2.0.2 и 10.2.0.3. Б каждой из этих строк mrinfo сообщает об интерфейсе, соседях и их доменных именах, метрику многоадресного маршрута, пороговое значение TTL и флаги, указывающие, является ли данный интерфейс маршрутизатора опрашивающим (querier) и есть ли у него соседи (если нет, то выводится слово «leaf»).
Поддержка Mtrace Хотя в Windows 2000 нет какой-либо версии утилиты Mtrace, предназначенной для трассировки групповых пакетов, маршрутизатор Windows 2000 реагирует на запросы от таких утилит, поставляемых сторонними разработчиками.
Команды Netsh Чтобы просмотреть таблицы многоадресной пересылки и собрать информацию, полезную при выявлении источника проблем с многоадресной маршрутизацией и пересылкой, используйте следующие команды netsh. • netsh routing ip show mfe Выводит содержимое таблицы многоадресной пересылки. Эта команда показывает ту же таблицу, что и оснастка Routing and Remote Access (Маршрутизация и удаленный доступ). • netsh routing ip show mfestats Сообщает статистику о переданных и принятых пакетах, а также информацию о входных и выходных интерфейсах но каждой записи в таблице многоадресной пересылки. Эта команда показывает ту же статистику, что и оснастка Routing and Remote Access. • netsh routing ip igmp show grouptabte Выводит информацию о членстве хостов в группах, зарегистрированных на всех интерфейсах, которые работают в режиме IGMP-маршрутизатора. Эта команда показывает ту же таблицу IGMP-rpynn, что и оснастка Routing and Remote Access. • netsh routing ip igmp show ifstals Отображает статистику IGMP по каждому интерфейсу. • netsh routing ip igmp show iftable Выводит информацию о членстве хостов в группах, зарегистрированных па конкретном интерфейсе, который работает в режиме IGMP-маршрутизатора. Эта команда показывает ту же таблицу групп IGMP-интерфейса, что и оснастка Routing and Remote Access. • netsh routing ip igmp show rasgrouptable Выводит таблицу групп для интерфейса Internal (Внутренний), используемого сервером удаленного доступа,
ГЛАВА 4
•
Поддержка групповой IP-рассылки
147
netsh routing ip igmp show proxygrouptable Выводит таблицу групп для интерфейса, работающего в режиме IGMP-прокси.
Регистрация событий IGMP Уровень регистрации событий для протокола маршрутизации IGMP, записываемых в системном журнале событий Windows 2000 устанавливается: •
в окне свойств протокола маршрутизации IGMP, открываемого в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ); • командой netsh routing ip igmp set global. Уровни регистрации событий могут быть следующими: • Log errors only (Вести только журнал ошибок); • Log errors and warnings (Вести журнал ошибок и предупреждений); • Log the maximum amount of information (Вести журнал всех событий); • Disable event logging (Отключить журнал событий). Уровень по умолчанию — Log errors only. При выявлении причины проблем с протоколом маршрутизации IGMP установите уровень Log the maximum amount of information. Получив нужную информацию, верните уровень регистрации событий на Log errors only.
Трассировка Средства трассировки записывают последовательность вызываемых функций в файл. Для .-записи детальной информации о процессах, выполняемых протоколом маршрутизации 1GMP, в файл журнала %SystemRoot%\Trfd(:mg\lGMPv2.\og присвойте параметру EnableFileTracing в разделе реестра HKEY_LOCAL_MACHIXE\ Software\Microsoft\Tracing\IGMPv2 значение 1. Закончив трассировку, верните этому параметру исходное значение (0). Трассировочная информация может оказаться сложной и очень детальной. Часть ее полезна только инженерам службы технической поддержки Microsoft или сетевым администраторам, имеющим большой опыт работы со службой маршрутизации и удаленного доступа. Трассировочную информацию можно сохранить в виде файлов и послать в службу технической поддержки Microsoft для анализа. Подробнее о возможностях трассировки см. главу 2 «Служба маршрутизации и удаленного доступа* в этой книге.
Дополнительные материалы Более подробную информацию о групповой IP-рассылке см. в книге: •
Thomas A. Maufcr «Deploying IP Multicast in the Enterprise», 1998, Upper Sad.lie River, NJ: Prentice Hall PTR.
ГЛАВА
5
IPX-маршрутизация
Служба маршрутизации и удаленного доступа Windows 2000 является полнофункциональным IPX-маршрутизатором, который поддерживает RIP for IPX (основной протокол маршрутизации, используемый в межсетевых IPX-средах), Novell NetWare SAP for IPX (протокол для сбора и распространения имен и адресов служб) и пересылку широковещательных пакетов NetBIOS поверх IPX. В этой главе Windows 2000 и IP Х-маршрутизация Фильтрация IPX-пакетов 149 RIP for IPX
148
156
SAP for IPX 163 Широковещание NetBIOS
172
См.также • Об одноадресной маршрутизации — главу 1 «Обзор одноадресной маршрутизации» в этой книге. •
Подробнее о маршрутизаторе Windows 2000 — главу 2 «Служба маршрутизации и удаленного доступа» в этой книге. • О маршрутизации с соединением по требованию — главу 6 «Маршрутизация с соединением по требованию» в этой книге. •
Подробнее о взаимодействии с NetWare — главу 12 «Взаимодействие с NetWare» в этой книге.
Windows 2000 и IPX-маршрутизация Маршрутизатор IPX (Internetwork Packet Exchange) — это комбинация агента IPXмаршрутизации (IPX routing agent) и агента SAP (Service Advertising Protocol). Первый агент перенаправляет IPX-пакеты между IPX-сетями и ведет свою таблицу маршрутизации, используя протокол RIP (Routing Information Protocol) for IPX. Агент SAP собирает и распространяет SAP-информацию (список служб, доступных в сети, и их межсетевые IPX-адреса), а также отвечает па запросы клиентов SAP. Подробнее о компонентах IPX-маршрутизатора в Windows 2000 см. главу 2 «Служба маршрутизации и удаленного даступн» в этой книге.
ГЛДВА 5
IPX-маршрутизация
149
Windows NT Server версии 4.0 (и ниже) предоставляла службу агента SAP, которая позволяла приложениям и службам Windows NT (в частности, File and Print Services for NetWare и Microsoft Exchange Server) оповещать клиенты NetWare о своих именах и адресах, a Windows NT версии 3.51 (с Service Pack 2 и выше) и Windows NT Server 4.0 — агент IPX-маршрутизации, использующий протокол RIP for IPX. Windows 2000 Server предоставляет интегрированный 1РХ-маршрутизат(.|р с агентом SAP и агентом IPX-маршрутизации, который работает с протоколом RIP for IPX.
Функциональность маршрутизатора Windows 2000 для набора протоколов IPX Маршрутизатор Windows 2000 (Windows 2000 Router) — компьютер под управлением Windows 2000 Server и службы маршрутизации и удаленного доступа — предусматривает богатую функциональность для поддержки межсетевых IPX-сред. Фильтрация IPX-пакетов. Для каждого интерфейса можно определить входные и выходные фильтры с использованием ключевых полей в IPX-заголовке. RIP for IPX, Полная поддержка RIP for IPX, основного протокола маршрутизации, применяемого в межсетевых IPX-средах. Фильтрация IPX-маршрутов. оповещений о маршрутах,
Фильтрация входящих и исходящих маршруток и
Статические IPX-маршруты. Статические IPX-маршруты, объявляемые по протоколу RIP for IPX. SAP for IPX. Полная поддержка SAP — механизма, с помощью которого клиенты NetWare получают информацию об именах и адресах служб, работающих на IPX-узлах. Фильтрация SAP, Фильтрация входящих и исходящих имен служб и оповещений об именах служб. Статические службы SAP. ся по протоколу SAP.
Статические службы SAP имена которых объявляют-
Распространение широковещательных пакетов NetBIOS. Пересылка широковещательных пакетов NetBIOS поверх IPX, гибко настраиваемая на LAN-интерфейсах и интерфейсах соединений по требованию. Статические NetBIOS-имена. Статические NetBIOS-имена можно настроить так, чтобы широковещательные запросы определенных имен NetBIOS поверх IPX пересылались по определенным интерфейсам, Платформа для поддержки других протоколов IPX-маршрутизации. Предусмотрена поддержка для дополнительных протоколов IPX-маршрутизации, например NLSP (NetWare Link Services Protocol). (Маршрутизатор Windows 2000 не включает NLSP, но этот протокол может быть предоставлен сторонними разработчиках и программного обеспечения.)
Фильтрация IPX-пакетов Кроме маршрутизации IPX-трафика, IPX-маршрутизатор может пропускать или отклонять определенные виды IPX-трафика. Эта фунциональность, называемая
150
ЧАСТЬ 1
Маршрутизация
фильтрацией IPX-пакетов, позволяет точно указывать тип IPX-трафика, которому разрешено пересекать данный маршрутизатор. Вы можете создать серии определений, называемых фильтрами, которые задают маршрутизатору, какой тип трафика разрешен или запрещен на каждом интерфейсе. Такие фильтры могут быть установлены как для входящего, так и для исходящего трафика. Входные фильтры определяют, какой входящий трафик, принимаемый по данному интерфейсу, может быть перенаправлен или как-то иначе обработан маршрутизатором. Выходные фильтры указывают, какой трафик может посылаться по данному интерфейсу. Фильтрацию IPX-пакетов иллюстрирует рис. 5-1. IPX-трафик -I
Выходные фильтры
Входные фильтры — - г Сетевой адаптер
IPX-трафик Рис. 5-1. Фильтрация IPX-пакетов
Поскольку для каждого интерфейса можно определить как входные, так и выходные фильтры, есть риск создать конфликтующие фильтры. Например, входной фильтр на одном интерфейсе разрешает прием какого-то входящего трафика, но выходной фильтр на другом интерфейсе запрещает передачу этого трафика. Дело кончится тем, что этот трафик не сможет пересечь данный маршрутизатор. Маршрутизатор Windows 2000 поддерживает фильтрацию на основе содержимого основных полей в IPX-заголовках входящих и исходящих пакетов. Структура IPXзаголовка поясняется в следующем разделе — это даст Вам представление о типах IPX-фильтрации, поддерживаемых маршрутизатором Windows 2000.
Структура IPX-заголовка IPX-заголовок, следующий за заголовками, относящимися к физическому и канальному уровням (например, Ethernet, Token Ring или РРР), показан на рис. 5-2. Контрольная сумма. 16-битная контрольная сумма IPX-заголовка и полезных данных обычно не применяется. Если она не используется, в это поле записывается значение OxFF-FF, а если все же используется, то настроить IPX-узел па применение кадров Ethernet__802.3 нельзя. Длина. Указывает длину IPX-пакета (IPX-заголовка и полезных данных в IPXпакете) в байтах. Для адаптации под устаревшие маршрутизаторы и сетевые адаптеры IPX-узлы иногда приходится настраивать так, чтобы генерируемые ими IPX-
ГЛАВА 5
IPX-маршрутизация
151
пакеты содержали четное число байтов. Если в пакете содержится нечетное число байтов, к нему добавляется еще один байт, но в поле длины он не учитывается. Контрольная сумма Длина Контроль транспорта Тип пакета Сеть назначения Узел назначения Сокет назначения Сеть источника Узел источника
Сокет источника = 1 байт
Рис. 5-2. IPX-заголовок Контроль транспорта. Указывает число IPX-маршрутизаторов, через которые уже прошел данный IPX-пакет; также называется числом переходов (hop count). Передающие узлы записывают в это поле нулевое значение, а каждый IPX-маршрутизатор на пути от источника к адресату увеличивает это значение на 1. Маршрутизаторы RIP for IPX ограничивают максимальное число переходов до 15. На 16-м маршрутизаторе RIP for IPX пакет «молча* отбрасывается (без уведомления узлаотправителя). Маршрутизаторы NLSP (NetWare Link Services Protocol) for IPX поддерживают число переходов до 127. Тип пакета. Указывает тип полезных данных в IPX-пакете. Благодаря этому клиентские протоколы могут использовать IPX и распознаются IPX-маршрутизатор ом. Некоторые из возможных значений этого поля перечислены в таблице 5-1. Таблица 5-1. Типы IPX-пакетов Клиентский протокол Не заданный
Тип пакета {значение в шестнадцатеричной форме)
RIP
00 01
SAP/Normal IPX
ui
SPX
05 14 (в десятичной форме — 20)
IPX WAN Broadcast (используется для передачи широковещательных пакетов NetBIOS поверх IPX)
Маршрутизаторы могут отфильтровывать IPX-трафик на основе содержимого поля типа пакета. Например, некоторые маршрутизаторы по умолчанию не распространяют широковещательный трафик NetBIOS поверх IPX и должны быть вручную настроены на пересылку таких пакетов (со значением поля типа, равным 20). Сеть (назначения и источника). Поля сети назначения и сети источника идентифицируют сети (сеть — это сегмент межсетевой IPX-среды, ограниченной 1РХ-мар-
152
ЧАСТЬ 1
Маршрутизация
шрутизаторами), к которым подключены IPX-узлы назначения и источника. Номера IPX-сетей образуют линейное пространство адресации. При использовании протокола маршрутизации RIP for IPX ни разбиение на подсети, ни суммирование групп IPX-сетей не поддерживается. В таблицах маршрутизации на маршрутизаторах RIP for IPX должен быть маршрут к каждой сети. Всем IPX-сетям присваивается уникальный номер. Узел (назначения и источника). Ноля узла назначения и узла источника идентифицируют соответствующие узлы в IPX-сети. В этих шестибайтовых полях можно хранить физические адреса, также называемые МЛС-адресами. Сокет (назначения и источника). Поля сокета назначения и сокета источника идентифицируют адреса программных процессов приложения-адресата и приложения-отправителя. При взаимодействии нескольких процессов между двумя компьютерами номера IPX-сети и узла совпадают. Номер IPX-сокета — это идентификатор программного процесса, используемый при пересылке полезных данных IPX нужному процессу. Многие номера сокетов являются общеизвестными. Например, процесс файл-сервера, выполняемый на файл-сервере Novell NetWare или совместимых файл-серверах, использует общеизвестный сокет 0x451. Любые запросы к сокету 0x451 на файл-сервере NetWare пересылаются процессу файл-сервера NetWare. Клиенты файл-сервера NetWare и IPX-приложения, не использующие какой-либо из общеизвестных номеров сокетов, оперируют динамически назначаемыми номерами сокетов. Некоторые из общеизвестных номеров IPX-сокетов перечислены в таблице 5-2. Таблица 5-2. Номера 1РХ-сокетов
Процесс
Номер сокета (в шестнадцатеричной форме)
NCP Server RIP SAP NetBIOS
451 153 152 451)
Примечание 1РХ-сокеты отличаются от сокетов Windows Sockets 2.x API (Winsock). Сокет Winsock на основе TCP/IP представляет собой комбинацию IP-адреса и номера порта, идентифицирующую конечную точку какого-либо процесса в межсетевой IP-среде, а сокет Winsock на основе IPX — комбинацию номеров IPX-сети, IPXузла и IPX-сокета, определяющую конечную точку того или иного процесса в межсетевой IPX-среде.
Демультиплексирование IPX-пакета Когда IPX-пакет прибывает по назначении) и передается протоколу IPX, данные приложения должны быть демультиплексированы, т. е. перенаправлены нужному процессу. Демультиплексирование IPX-пакета на хосте-получателе осуществляется в два этапа. На первом этапе модуль IPX проверяет номера сети назначения и узла, чтобы убедиться в их соответствии локальному IPX-интерфейсу. А на втором этапе мо-
ГЛАВА 5
IPX-маршрутизация
153
дуль IPX проверяет номер сокета назначения и, исходя из его значения, передает полезные данные IPX (полученный пакет без IPX-заголовка) соответствующему про пес суПроцесс демультиплексирования IPX-пакета показан на рис. 5-3. Файл-сервер NetWare
Процесс RIP
Процесс SAP А
Т Соквт 1 -назначений I 0X451
Т Сокет f назначения | 6x453
Процесс NetBIOS I
Т Сокет \ назначения I 0x452
А
Сокет I назначения | 0x455
IPX
Сеть назначения и адрес узла
Рис. 5-3. Демультиплексирование IPX-пакета Например, какой-то клиент NetWare посылает серверу NetWare запрос на доступ к файлу. Когда модуль IPX на сервере NetWare получает этот запрос, он проверяет номера сети назначения и узла, чтобы убедиться в их соответствии локальному ГРХ-интерфейсу. Далее модуль IPX обнаруживает, что значение в иоле сокета назначения равно 0x451, и поэтому передает полезные данные IPX процессу файлсервера NetWare.
Фильтрация IPX-пакетов на маршрутизаторе Windows 2000 Фильтрация IPX-пакетов на маршрутизаторе Windows 2000 основана па принципе исключения. Вы настраиваете Windows 2000 либо на пропуск всего IPX-трафика, кроме запрещенного фильтрами, либо на игнорирование всего IPX-трафика, кроме разрешенного фильтрами. Например, Вам может понадобиться сконфигурировать выходные фильтры, пропускающие весь трафик, кроме объявлений SAP. Или гоздать входной фильтр на выделенном сервере SQL для обработки только трафика SPX (Sequencer! Packet Exchange), связанного с SQL. Маршрутизатор Windows 2000 позволяет определять IPX-фильтры на основе следующих полей; • типа пакета; • сети источника; • узла источника;
154
ЧАСТЬ 1
Маршрутизация
сокета источника; сети назначения; узла назначения; сокета назначения. Примечание Номера сетей источника и назначения можно указывать с использованием маски сети, что позволяет задавать в одном элементе фильтра целый диапазон номеров IPX-сетей. Определяя, соответствует ли номер сети IPX-пакета критериям фильтра, маршрутизатор Windows 2000 использует логическую операцию AND для комбинирования маски сети и номера сети в IPX-пакете, а затем сравнивает полученный результат с номером сети в фильтре. При этом 0 можно использовать как символ подстановки для любого шестнадцатеричного разряда, a F — для определенного шестнадцатеричного разряда.
Настройка IPX-фильтра Вы можете сконфигурировать входную и выходную фильтрацию IPX, выбрав действие фильтра и добавив набор фильтров через диалоговое окно IPX Packet Filters Configuration (Конфигурация фильтров IPX-пакетов), показанное на рис. 5-4.
ас liar
. йгаО'э! васЬей e*eept Ihes*; that mee* (he сгёеге
«L
Рис. 5-4. Диалоговое окно IPX Packet Filters Configuration Примечание Сконфигурировать раздельные активные фильтры для Receive all packets except those that meet the criteria below (Принимать все пакеты, кроме тех, что отвечают указанным ниже критериям) и Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям) нельзя. Вы можете задать параметры входного или выходного фильтра в диалоговом окне Add IPX Filter (Добавление IPX-фильтра) или Edit IPX Filter (Изменение IPX-
ГЛАВА 5
IPX-маршрутизация
155
фильтра), как показано па рис. 5-5. Если Вы настраиваете несколько параметров фильтра, то в процессе фильтрации они комбинируются логической операцией AMD. Так, если в фильтре указаны Packet Type (Тип пакетов) и Destination Socket (Сокет назначения), он пропускает IPX-пакет только в том случае, когда содержимое обоих полей IPX-пакета — и типа пакета, и сокета назначения — удовлетворяет значениям соответствующих параметров этого фильтра. Примечание Все числа, вводимые в диалоговых окнах Add IPX Filter и Edit IPX Filter, должны быть шестнадцатеричными.
Рис, 5-5, Диалоговое окно Add IPX Filter Следующие два примера демонстрируют варианты IPX-фильтрации и реализации IPX-фильтров с использованием нолей в диалоговом окне Add IPX Filter или Edit IPX Filter. Эти примеры представлены лишь для иллюстрации того, как настраиваются IPX-фильтры, а не в качестве рекомендаций по IPX-фильтрации в конкретных условиях. ^ Чтобы сконфигурировать входной IPX-фильтр с использованием маски сети (пример); Для выборки IPX-пакетов с номерами сетей назначения, начиная с АВ, настройте входной фильтр следующим образом. 1. В диалоговом окне IPX Packet Filters Configuration (Конфигурация фильтров IPX-пакетов) щелкните кнопку Add (Добавить). 2. В диалоговом окне Add IPX Filter (Добавление IPX-фильтра) в разделе Destination (Назначение) введите в ноле Network number (Номер сети) значение АВОООООО. 3. В том же разделе введите в поле Network mask (Маска подсети) значение FFOOOOOO. 4. Щелкните КНОПКУ ОК.
156
ЧАСТЬ 1
Маршрутизация
5. В диалоговом окне IPX Packet Filters Configuration установите флажок Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям). 6. Щелкните кнопку ОК. Б этом фильтре используется маска сети, которая задает диапазон номеров IPX-сетей от ABOOOOQO до ABFFFFFF. ^ Чтобы сконфигурировать выходной IPX-фильтр с использованием маски сети (пример): Во избежание передачи или пересылки всего IPX-трафика из сети источника с номером СС000001 настройте выходной фильтр следующим образом. 1. В диалоговом окне IPX Packet Filters Configuration (Конфигурация фильтров IPX-пакетов) щелкните кнопку Add (Добавить). 2. В диалоговом окне Add IPX Filter (Добавление IPX-фильтра) в разделе Source (Источник) введите в поле Network number (Номер сети) значение СС000001. 3. В том же разделе введите в поле Network mask (Маска подсети) значение FFFFFFFF. 4. Щелкните кнопку ОК. 5. В диалоговом окне IPX Packet Filters Configuration установите флажок Receive all packets except those that meet the criteria below (Принимать все пакеты, кроме тех, что отвечают указанным ниже критериям). 6. Щелкните кнопку ОК. В этом фильтре используется маска сети, которая задает единственный номер IPXсети - СС000001. Примечание Маска сети в диалоговых окнах Add IPX Filter и Edit IPX Filter применяется только для упрощения задания диапазона номеров IPX-сетей. Это не означает, что маршрутизатор Windows 2000 поддерживает разбиение IPX-сетей на подсети. Дело в том, что сам RIP for IPX не поддерживает ни разбиение на подсети, ни суммирование маршрутов.
RIP for IPX RIP for IPX — это протокол маршрутизации на основе векторов расстояний (distance vector routing protocol), предназначенный для распространения информации о маршрутах в межсетевой IPX-среде. RIP for IPX разработан на базе XNS-версии (Xerox Network Services) RIP, no содержит дополнительное поле счетчика тактов (tick count). Этот счетчик позволяет приблизительно оценить время, которое уходит на доставку IPX-пакета в сеть назначения, и дает возможность маршрутизатору RIP for IPX выбрать маршрут, обеспечивающий наименьшую задержку в доставке пакетов. Для ускорения конвергенции Rip for IPX использует алгоритмы разделения направлений и инициируемых обновлений (см. главу 3 «Одноадресная IP-маршрутизация» в этой книге).
ГЛАВА 5
IPX-маршрутизация
157
RTF for IPX поддерживает следующие типы сообщений. •
RIP-клиенты, например рабочие станции, находят оптимальный маршрут к какой-либо IPX-сети, посылая широковещательный RIP-запрос Get Local Target.
•
Маршрутизаторы запрашивают информацию о маршрутах от других маршрутизаторов, посылая обший широковещательный RTP-занрос о маршрутах. • Маршрутизаторы отвечают на RlP-запросы Get Local Target и общие RIP-заиросьт о маршрутах. • Маршрутизаторы периодически (по умолчанию — каждые 60 секунд) выполняют широковещание содержимого своих таблиц маршрутизации с применением алгоритма разделения направлений (split horizon). • Маршрутизаторы выполняют широковещание инициируемых обновлений для уведомления соседних маршрутизаторов о каком-либо изменении в конфигурации межсетевой IPX-среды.
Таблицы IPX-маршрутизации Таблица IPX-маршрутизации поддерживается протоколом маршрутизации RIP for IPX. Запись в таблице IPX-маршрутизации содержит следующие поля*. Network Number (Номер сети). Номер IPX-сети, совпадающий с номером сети назначения в IPX-заголовке пакета. Forwarding MAC Address (MAC-адрес следующего прыжка). МАС-адрес назначения IPX-пакета при его пересылке на следующий маршрутизатор. В случае сетей, подключенных напрямую, это поле остается пустым. Tick Count (Счетчик тиков). Число тактов (один такт равен примерно 1/18 секунды), необходимое для достижения сети назначения. Это значение оценивается на основе входящих RIP-запросов и ответов и зависит от скорости передачи данных в сетевых сегментах. LAN-каналы обычно требуют одного такта, а WAN-каналы вроде линии Т1 — шести или семи тактов. Этот счетчик дает приблизительное представление о задержке. Hop Count (Счетчик прыжков). Число маршрутизаторов, которые нужно пересечь, чтобы достичь IPX-сети с нужным номером. Interface (Интерфейс) или Port (Порт). Интерфейс (плата сетевого интерфейса), применяемый при пересылке IPX-трафика по данному маршруту. Маршрутизатор имеет по одному интерфейсу для каждого подключенного сегмента сети. Структуру таблицы IPX-маршрутизации иллюстрирует рис. 5-6. Если к какой-либо IPX-сети ведет несколько маршрутов, IPX-маршрутизаторы выбирают оптимальный маршрут следующим образом. 1. Находят маршрут с наименьшим числом тактов.
* Русские названия нолей, приведенные в скобках, даются но интерфейсу русской версии Windows 2000 Server. Но в остальном тексте вместо счетчика тиков мы используем счетчик тактов, вместо МАС-адреса следующего прыжка — МАС-адрес следующего перехода (или пересылочный МАС-адрес), а вместо счетчика прыжков — счетчик переходов. Кроме того, имеете в виду, что в оригинальном тексте книги отсутствует упоминание о еще одном поле в таблице IPX-маршрутизации — о поле протокола. — Прим. переч.
158
ЧАСТЬ 1
Маршрутизация
2. Если таких маршрутов несколько, определяют маршрут с наименьшим числом переходов. 3. Если и таких маршрутов несколько, выбирают один из них случайным образом. IPX-маршрутизатор
Таблица IPX-маршрутизации Номер сети
МАС-адрес следующего перехода
Счетчик тактов
Счетчик Интерфейс переходов
Рис. 5-6. Таблица IPX-маршрутизации
Функционирование RIP for IPX Нормальная работа маршрутизатора RIP for IPX заключается в выполнении следующих процессов, Инициализация. При запуске IPX-маршрутизатор посылает широковещательный RIP-пакет во все локально подключенные сети, оповещая соседние маршрутизаторы о номерах своих сетей. Соседние RTP-маршрутизаторы обрабатывают этот пакет и при необходимости добавляют в свои таблицы маршрутизации соответствующие записи. Инициализирующийся IPX-маршрутизатор также посылает широковещательный общий RIP-запрос во все локально подключенные сети. Получив этот запрос, соседние IPX-маршрутизаторы посылают ему информацию о содержимом своих таблиц маршрутизации. На основе этих ответов формируется таблица маршрутизации инициализирующегося IPX-маршрутизатора. Регулярное оповещение. IPX-маршрутизатор каждые 60 секунд посылает по всем интерфейсам широковещательные оповещения о своих маршрутах, используя при этом алгоритм разделения направлений. Соседние IPX-маршрутизаторы принимают объявленные маршруты и соответственно обновляют содержимое своих таблиц маршрутизации. Отключение маршрутизатора административными средствами. Если IPX-маршрутизатор корректно выключается административными средствами, он посылает широковещательное RIP-сообщение во все локально подключенные сети. В нем объявляется, что в маршрутах к сетям, доступным через данный маршрутизатор, число переходов равно 16 (сети недостижимы). Изменение в топологии межсетевой IPX-среды распространяется соседними IPX-маршрутизаторами с использованием инициируемых обновлений.
ГЛАВА 5
IPX-маршрутизация
159
Выход канала связи из строя. Если вышедший из строя канал связи соединен с одним из интерфейсов маршрутизатора, если этот сбой аппаратно распознается интерфейсом и если интерфейс уведомляет маршрутизатор о таком сбое, то посылается соответствующее инициируемое обновление. Маршруты, полученные через данный интерфейс, с этого момента считаются недействительными. Заметьте, что большинство LAN-интерфейсов не обеспечивает аппаратной поддержки распознавания сбоев в несущей среде, и поэтому выход канала связи из строя обнаруживается не сразу. Однако многие WAN-адаптеры умеют распознавать отключение канала связи с провайдером WAN-сервисов. Выход маршрутизатора из строя. Если IPX-маршрутизатор отключается и s-за аварии с электроснабжением или какого-нибудь сбоя в оборудовании или программном обеспечении, у него нет возможности уведомить соседние маршрутизаторы о том, что сети, к которым он был подключен, теперь недоступны. Чтобы не допустить чрезмерно длительного присутствия маршрутов к недоступным сетям в таблицах маршрутизации, каждый маршрут, полученный RIP for IPX, имеет максимальный срок действия в 3 минуты (по умолчанию). Если соответствующая запись не обновляется в течение трех минут, число переходов в ней изменяется на 16, и в конечном счете она удаляется из таблицы маршрутизации. Поэтому, если IPX-маршрутизатор выходит из строя, соседние маршрутизаторы помечают полученные от него маршруты недействительными не ранее, чем через 3 минуты. И только после этого они распространяют информацию об изменении топологии, используя алгоритм инициируемых обновлений,
Структура пакетов RIP for IPX Заголовок RIP for IPX (рис. 5-7) располагается сразу же после IPX-заголовка. Пакеты RIP for IPX относятся к типу 0x1 и имеют номера сокетов источника и назначения, равные 0x453. Режим работы [ До 50 R IP-маршрутов в одном RIP-пакете
Номер сети Число переходов Число тактов
О-' dan1 Рис. 5-7. Структура пакетов RIP for IPX Режим работы. Двухбайтовое поле, которое указывает тип сообщения RIP for IPX. Для него определено два значения. •
0x00-01 — RIP Request (RIP-запрос). Это значение устанавливается клиентом, пытающимся найти оптимальный маршрут к сети назначения (RIP-запрос GetLocalTargct), или маршрутизатором, запрашивающим все доступные маршруты от соседних маршрутизаторов в момент своего запуска (общий RIP-запрос).
•
0x00-02 — RIP Response (RIP-ответ). Это значение устанавливается маршрутизатором, отвечающим либо на RIP-запрос GetLocalTarget, либо на общ,[и
160
ЧАСТЬ 1
Маршрутизация
запрос. Периодические оповещения также посылаются как сообщения RIP Response. За полем режима работы следует одна или несколько записей о RIP-маршрутах (до 50). В RIP-запросы включается единственный RlP-маршрут. В случае RIP-запроса GetLocalTargct указывается номер IPX-сети назначения, а в случае общего RIP-запроса номер IPX-сети устанавливается равным OxFF-FF-FF-FF. В RIP-ответы включается один или несколько RIP-маршрутов. В ответе на запрос: GetLoealTarget указывается один маршрут, а в ответе на общий RIP-запрос или периодическое оповещение — до 50 (в одном пакете RIP for IPX). Максимальный размер пакета RIP for IPX — 432 байта. Если нужно сообщить более чем о 50 маршрутах, используются дополнительные пакеты RIP for IPX. Номер сети. Четырехбайтовое поле, в котором указывается номер IPX-сети. Число переходов. Двухбайтовое поле, сообщающее число маршрутизаторов, которые должен пересечь пакет при использовании данного маршрута. Число тактов. Двухбайтовое поле, указывающее число тактов, требуемых для передачи IPX-пакета но данному маршруту.
Фильтры маршрутов RIP for IPX Чтобы получить доступ к фильтрам RIP for IPX, откройте окно свойств интерфейса в папке RIP for IPX (RIP для IPX) u щелкните кнопку Input Filters (Фильтры входа) или Output Filters (Фильтры выхода). Функция фильтрации RIP-маршрутов предусматривает как входную, так и выходную фильтрацию на каждом интерфейсе, и основана на принципе исключения. Вы можете сконфигурировать маршрутизатор Windows 2000 либо для приема или объявления всех маршрутов RIP for IPX, кроме запрещенных фильтрами, либо для отклонения или «умолчания» обо всех маршрутах RIP for IPX, кроме разрешенных фильтрами. Диалоговые окна Input Route Filter (Фильтры входящих маршрутов) и Route Filter (Фильтр маршрутов) показаны на рис, 5-8. Следующие два примера демонстрируют варианты фильтрации маршрутов и реализации фильтров с использованием полей в диалоговом окне Route Filter. Эти примеры представлены лишь для иллюстрации того, как настраиваются фильтры маршрутов, а не в качестве рекомендаций по фильтрации маршрутов в конкретных условиях. ^ Чтобы настроить фильтр входящих маршрутов RIP for IPX (пример): Этот фильтр входа будет запрещать все маршруты RIP for IPX, кроме ведущих к сетям с номерами, начиная с шестнадпатеричного разряда А. 1. В диалоговом окне Input Route Filters (Фильтры входящих маршрутов) щелкните кнопку Add (Добавить). 2. В появившемся диалоговом окне Route Filter (Фильтр маршрутов) введите в поле Network number (Номер сети) значение АООООООО. 3. В поле Network mask (Маска подсети) введите FOOOOOOO. 4. Щелкните кнопку ОК.
ГЛАВА 5
IPX-маршрутизация
161
5. В диалоговом окне Input Route Filters выберите переключатель Deny routes except listed below (Запретить все маршруты, кроме перечисленных), 6. Щелкните кнопку ОК. В этом фильтре используется маска сети, которая задает диапазон номеров IPX-сетей от АООООООО до AFFFFFFF.
VAAOQQQ
FFFFOOQG
Add.
e 1 Ане a- Connect! о п
Рис. 5-8. Диалоговые окна Input Route Filter и Route Filter ^ Чтобы настроить фильтр исходящих маршрутов RIP for IPX (пример): Этот фильтр выхода будет разрешать объявление всех маршрутов RIP for IPX, кроме ведущих к IPX-сети с номером ВВОООП99. 1. В диалоговом окне Output Route Filters (Фильтры исходящих маршрутов) щелкните кнопку Add (Добавить). 2. В появившемся диалоговом окне Route Filter (Фильтр маршрутов) введите в поле Network number (Номер сети) значение ВВ000099. 3. В поле Network mask (Маска подсети) введите FFFFFFFF. 4. Щелкните кнопку ОК. 5. В диалоговом окне Output Route Filters выберите переключатель Permit routes except listed below (Разрешить все маршруты, кроме перечисленных).
162
ЧАСТЬ 1
Маршрутизация
6. Щелкните кнопку ОК. В этом фильтре используется маска сети, которая задает единственный номер IPXсети - ВВ000009. Примечание Приведенная выше маска сети применяется только для упрощения задания диапазона номеров сетей IPX. Это не означает, что маршрутизатор Windows 2000 поддерживает разбиение IPX-сетей на подсети. Дело в том, что сам RIP for IPX не поддерживает ни разбиение на подсети, ни суммирование маршрутов. Примечание Сконфигурировать раздельные активные фильтры для Permit routes except listed below и Deny routes except listed below нельзя.
Статические IPX-маршруты Маршрутизатор Windows 2000 позволяет создавать статические IPX-маршруты в таблице IPX-маршрутизации. Такие маршруты обычно используются для определения номеров IPX-сетей, доступных через соединение удаленного доступа по коммутируемой линии. Подробнее о применении статических IPX-маршрутов см. главу 6 «Маршрутизация с соединением по требованию* в этой книге. Статические IPX-маршруты объявляются через LAN-интерфейсы так же, как и любые другие IPX-маршруты. ^ Чтобы добавить статический маршрут: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IPX Routing (IPX-маршрутизация), щелкните правой кнопкой мыши папку Static Routes (Статические маршруты) и выберите команду New Route (Новый маршрут). 2. Для определения статического IPX-маршрута в диалоговом окне Static Route (Статический маршрут), показанном на рис. 5-9, заполните следующие поля: • Network number (Номер сети) — четырехбайтовое значение в итсстнадцатеричной форме (8 шестнадцатеричных разрядов); •
Next hop MAC address (MAC-адрес следующего прыжка) — шестибайтовое значение в шестнадцатеричной форме (12 шестнадцатеричных разрядов);
Net'.../.ч i-i.ir. Nt-;:tlk.t, M.-i, ;v:)ae,; fhe-] Tick count.
•;
Щ
f:.
Cancel
Рис. 5-9. Диалоговое окно Static Route
ГЛАВА 5
•
IPX-маршрутизация
163
Tick count (Счетчик тиков) — число тактов, требуемых для достижения сети с заданным номером;
• Hop count (Счетчик прыжков) — количество маршрутизаторов, которые надо пересечь для достижения сети с заданным номером; •
Interface (Интерфейс) — интерфейс маршрутизатора Windows 2000, через который можно достичь сети с заданным номером. В случае соединений удаленного доступа выберите подходящий интерфейс соединения по требованию.
SAP for IPX Novell NetWare SAP (Service Advertising Protocol) for IPX предоставляет клиентам механизм разрешения имен для получения адресов служб в межсетевых 1РХ-гредах. Хосты, поддерживающие какие-либо службы, например файл-серверы, серверы печати и приложений, широковещательно объявляют через SAP об именах и типах служб, а также о своих межсетевых IPX-адресах. Информация о службах и межсетевых IPX-адресах собирается IPX-маршрутизаторами и серверами No '/ell NetWare в базе данных, называемой таблицей SAP. Содержимое таблиц SAP периодически объявляется и распространяется в межсетевой среде так же, как и IPX-маршруты. Информация о службах добавляется в таблицу SAP и удаляется из нее динамически: добавление осуществляется на основе периодических оповещений, а удаление — по истечении срока действия в отсутствие новых оповещений. Чтобы сократить время конвергенции, SAP использует алгоритмы разделения направлений и инициируемых обновлений. (О разделении направлений и инициируемых обновлениях см. главу 3 «Одноадресная IP-маршрутизация» в этой книге.) SAP for IPX поддерживает следующие типы сообщений. • Клиенты SAP, например рабочие станции, запрашивают имя и адрес ближайшего сервера определенного типа, посылая широковещательный SAP-запрос GetNearestServer. • •
Маршрутизаторы или клиенты SAP запрашивают имена и адреса всех служб определенного типа, посылая широковещательный общий SAP-запрос о службах. Маршрутизаторы отвечают на общие SAP-запросы и GetNearestServer.
• Маршрутизаторы периодически (по умолчанию — каждые 60 секунд) широковещательно уведомляют о содержимом своих таблиц SAP с применением алгоритма разделения направлений. • Хосты — провайдеры каких-либо служб, не являющиеся маршрутизаторами, периодически (по умолчанию — каждые 60 секунд) широковещательно объявляют о предоставляемых ими службах. • Маршрутизаторы выполняют широковещание инициируемых обновлений для уведомления соседних маршрутизаторов об изменении в какой-либо таблице SAP.
IPX-маршрутизаторы и номер внутренней сети Чтобы оптимизировать взаимодействие со службами, которые работают на IPXмаршрутизаторах и объявляют о себе с использованием Novell NetWare SAP, IPX-
164
ЧАСТЬ 1
Маршрутизация
маршрутизаторы (например, серверы под управлением Novell NetWare или Windows 2000 Server) требуют определения номера внутренней IPX-сети. Внутренняя IPX-сеть (IPX internal network) — это виртуальная сеть внутри маршрутизатора. К ней подключается виртуальный сетевой адаптер с МАС-адресом 0x00-00-00-00-00-01. Внутренняя IPX-сеть объявляется по протоколу RIP for IPX точно так же, как и физические IPX-сети. Когда служба, работающая на маршрутизаторе, объявляется через SAP, для нес сообщается межсетевой IPX-адрес внутренней сети и виртуальный МАС-адрес. Внутренняя IPX-сеть позволяет оптимизировать пересылку пакетов службам, выполняемым на IPX-маршрутизаторе. В чем заключается эта оптимизация и что она дает, поясняется в следующих разделах.
IPX-трафик без использования внутренней IPX-сети Рис. 5-10 иллюстрирует простую межсетевую IPX-среду и процесс файл-сервера, работающий па маршрутизаторе, на котором не используется внутренняя IPX-сеть. Г Адрес процесса файл-сервера: ААААААМ:001111111111:0451
IPX-маршрутизатор 1
IPX-сеть: АААААААА
IPX-маршрутизатор 2
Хост
Рис. 5-10. Трафик до определения номера внутренней IPX-сети 1. Процесс файл-сервера NetWare, в ы п о л н я е м ы й па IPX-маршрутизаторе 1, объявляет через SAP о споем местонахождении по адресу сервера АААААААА-.001111111111:0451 (1РХ-сетъ:1РХ-узел:1РХ-сокет). 2. Хост разрешает адрес файл-сервера, запрашивая свой основной сервер NetWare (он не показан на рис. 5-10). 3. Хост рассылает широковещательный RIP-запрос GetLocalTarget в сети ВВБВВВВВ, чтобы выяснить наилучший маршрут к IPX-сети АААААААА, 4. IPX-маршрутизатор 1 в своем ответе сообщает о маршруте с одним переходом и двумя тактами. 5. IPX-маршрутизатор 2 в своем ответе тоже сообщает о маршруте с одним переходом и двумя тактами.
ГЛАВА 5
IPX-маршрутизация
165
6. Хост выбирает ответ IPX-маршрутизатора 2 (либо из-за того, что он пришел первым, либо потому, что таков был результат случайного выбора из двух vrapшрутов с одинаковыми характеристиками). 7. Хост отправляет пакет запроса на соединение с процессом файл-сервера на АААААААА;001111111111:0451..пересылая этот пакет IPX-маршрутизатору "2 на его МАС-адрес 00-44-44-44-44-44 в сети BBBBBBIiB. 8. IPX-маршрутизатор 2 пересылает пакет запроса на соединение маршрутизатору 1 на его МАС-адрес 00-11-11-11-11-11 в сети А А А А А А А А . 9. Процесс файл-сервера на маршрутизаторе 1 отвечает на пакет запроса о соединении, пересылая ответ па МАС-адрес хоста (этот адрес на иллюстрации не показан) в сети ВВВВВВВВ. Результат таков; пакеты, посылаемые хостом процессу файл-сервера, направляются по неоптимальному маршруту. Они передаются IPX-маршрутизатору 2, тогда как их следовало бы передавать IPX-маршрутизатору 1.
IPX-трафик при использовании внутренней IPX-сети Рис. 5-11 иллюстрирует простую межсетевую IPX-среду и процесс файл-сервера, работающий на маршрутизаторе, на котором используется внутренняя IPX-сеть. IPX-сеть: СССССССС
Адрес процесса фа йл-седве paj СССССССС:000000000001:0451
MAC: 00-00-00-00-00-01
IPX-маршрутизатор 1
IPX-сеть: АААААААА
MAC: 00-11-11-11-11-11
MAC: I 00-22-22-22-22-22
MAC: 00-33-33-33-33-33
MAC:
00-44-44-44-44-44
i IPX-маршрутизатор 2 I
Рис. 5-11. Трафик после определения номера внутренней IPX-сети 1. Процесс файл-сервера NetWare, выполняемый па IPX-маршрутизаторе 1, объявляет через SAP о своем местонахождении во внутренней сети по адресу сервера СССССССС:000000000001:0451 (1РХ-ссть:1РХ-узел:1РХ-сокет). 2. Хост разрешает адрес файл-сервера, запрашивая свой основной сервер NetW;ire (он не показан на рис. 5-11). 3. Хост рассылает широковещательный ШР-запрос GetLocalTarget в сети ВВВВВВВВ, чтобы выяснить наилучший маршрут к IPX-сети СССССССС.
166
ЧАСТЬ 1
Маршрутизация
4. IP Х-маршрутизатор 1 в своем ответе сообщает о маршруте с одним переходом и двумя тактами. 5. IPX-маршрутизатор 2 в своем ответе сообщает о маршруте с двумя переходами и тремя тактами. 6. Хост всегда выбирает ответ IPX-маршрутизатора 1 из-за меньшего значения счетчика тактов в его маршруте к сети СССССССС. 7. Хост отправляет пакет запроса на соединение с процессом файл-сервера на СССССССС:00000000001:0451, пересылая этот пакет IPX-маршрутизатору 1 на его МАС-адрсс 00-22-22-22-22-22 в сети ВВВВВВВВ. 8. Процесс файл-сервера на маршрутизаторе 1 отвечает на пакет запроса о соединении, пересылая ответ па MAC-адрес хоста (этот адрес на иллюстрации не показан) в сети ВВВВВВВВ. Результат таков: пакеты, посылаемые хостом процессу файл-сервера, всегда направляются по оптимальному маршруту.
Маршрутизатор Windows 2000, номер внутренней IPX-сети и внутренний интерфейс На маршрутизаторе Windows 2000, поддерживающем IPX-маршрутизацию, можно задать уникальный номер внутренней IPX-сети, который вводится в окне свойств lPX/SPX/NetBIOS-совместимого транспорта. Если такой номер не определен, он автоматически назначается при запуске маршрутизатора Windows 2000. Процесс автоматической настройки на маршрутизаторе Windows 2000 выбирает случайный номер внутренней IPX-сети и посылает ШР-пакет GetLocalTarget, запрашивающий маршрут к IPX-сети с этим номером. Если поступает какой-нибудь RIP-ответ, текущий номер внутренней IPX-сети отбрасывается и выбирается другой случайный номер. Эти операции повторяются до тех пор, пока не удается найти уникальный номер (RIP-ответ больше не приходит). Подобранный помер автоматически записывается в свойства IPX/SPX/NetBIOS-совместимого транспорта. п RotAmg pse «Р[Ч»!Р attest. _ Routing and Remote Access
t
Server Status RRftS-ROLITERl (local)
' Л RoutriQ Interface? ]jjj[ Dial-In Clients (0)
г Remote Router
Demand Dial
Enabled
Local Area Connection
Dedicated
Enabled
Sleeping Up
00000000 9d3b080o
Local Area Connection
Dedicated
Enabled
Up
172L6720
Not availa...
Not available
-JD Ports •Ji AppleTalk Routing •! Ж Ip Rout»4 В ]&. IPX Routing
f
NetBIOS Broaden Static Routes
Л state Services J[ Static NetBIOS Na Jj[R[PforIPX
Ji SAP For IPX 1
Remote Access Policie j Logging
Рис. 5-12. Внутренний IPX-интерфейс
•
ГЛАВА 5
IPX-маршрутизация
167
Чтобы увидеть виртуальный интерфейс, соответствующий внутренней IPX-сети, выберите свой сервер в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ), а затем раскройте узел IPX Routing (IPX-маршрутизация) и щелкните папку General (Общие). В правой секции окна оснастки появится интерфейс Internal (Внутренний); он является интерфейсом IPX-маршрутизатора и виртуальным сетевым адаптером для внутренней IPX-сети сервера (рис. 5-12).
Таблицы SAP Запись в таблице SAP состоит из следующих полей. Имя сервера. Тип службы. ложений).
Имя сервера, на котором работает данная служба, Тип службы (например, файл-сервер, сервер печати или сервер при-
Адрес сервера. Полный IPX-адрес службы (сетыузелхокет). Например, у процесса доступа к файлал! и принтерам на сервере NetWare мог бы быть адрес сервера, равный 000000АА:0000000000001:0451. Счетчик переходов. Число маршрутизаторов, которые нужно пересечь для достижения сервера, на котором работает данная служба. Предельное число переходов для служб — 15. Службы, находящиеся в 16 переходах (или дальше) от клиента, считаются недостижимыми. Интерфейс (или порт). Интерфейс (плата сетевого интерфейса), по которому была получена данная запись SAP. Структура таблицы SAP представлена на рис. 5-13. IPX-маршрутизатор
Таблица SAP
Имя сервера
Тип службы
Адрес сервера
Счетчик Интерфейс переходов
Рис. 5-13. Таблица SAP При наличии нескольких записей для одних и тех же имени сервера и типа службы IPX-маршрутизаторы выбирают запись с наименьшим числом переходов. Если же и таких записей несколько, маршрутизатор выбирает одну из них случайным образом.
168
ЧАСТЬ 1
Маршрутизация
Функционирование SAP для IPX-маршрутизатора Работа SAP на IPX-маршрутизаторе заключается в выполнении следующих процессов. Инициализация. Если на IPX-маршрутизаторе размещены какие-нибудь дополнительные службы, он посылает широковещательный SAP-пакет во все локально подключенные сети, оповещая соседние маршрутизаторы о своих службах. Затем IPX-маршрутизатор посылает широковещательный общий SAP-запрос во все локально подключенные сети. На основе ответов на этот запрос формируется таблица SAP. Регулярное оповещение. IPX-маршрутизатор каждые 60 секунд посылает по всем интерфейсам широковещательные оповещения о своей таблице SAP, используя при этом алгоритм разделения направлений. Соседние IPX-маршрутизаторы принимают информацию об объявленных службах и соответственно обновляют содержимое своих таблиц SAP. Отключение маршрутизатора административными средствами. Если IPX-маршрутизатор корректно выключается административными средствами, он посылает широковещательное SAP-сообщение ко все локально подключенные сети. В нем объявляется, что службы, ранее доступные на данном маршрутизаторе, более не доступны. Агент SAP устанавливает счетчик переходов в записях для этих служб равным 16, указывая па то, что службы недоступны. Это изменение распространяется соседними IPX-маршрутизаторами по межсетевой IPX-среде с использованием инициируемых обновлений. Выход канала связи из строя. Если вышедший ш строя канал связи соединен с одним из интерфейсов маршрутизатора, если этот сбой аппаратно распознается интерфейсом и если интерфейс уведомляет маршрутизатор о таком сбое, то посылается соответствующее инициируемое обновление. Службы SAP, информация о которых была получена через данный интерфейс, с этого момента считаются недоступными. Заметьте, что большинство LAN-интерфейсов не обеспечивает аппаратной поддержки распознавания сбоев в несущей среде, и поэтому выход канала связи из строя обнаруживается не сразу. Однако многие WAN-адаптеры умеют распознавать отключение капала связи с провайдером WAN-сервисов, Выход маршрутизатора из строя. Если IPX-маршрутизатор отключается из-за аварии с электроснабжением или какого-нибудь сбоя в оборудовании или программном обеспечении, у пего нет возможности уведомить соседние маршрутизаторы о том, что службы, которые работали на нем, теперь недоступны. Чтобы не допустить чрезмерно длительного присутствия записей о недоступных службах в таблицах SAP, каждая запись о службе SAP, полученная IPX-маршрутизатором, имеет максимальный срок действия и 3 минуты (по умолчанию). Если соответствующая запись не обновляется в течение трех минут, число переходов в ней изменяется на 16, и в конечном счете она удаляется из таблицы маршрутизации. Поэтому, если IPX-маршрутизатор выходит из строя, соседние маршрутизаторы помечают полученные от него записи недействительными не ранее, чем через 3 минуты. И только после этого они распространяют информацию об изменении, используя алгоритм инициируемых обновлений.
ГЛАВА 5
IPX-маршрутизация
169
Структура пакета SAP SAP-заголовок (рис. 5-14) располагается сразу же после IPX-заголовка. SAP-пакеты относятся к типу IPX-пакетов 0x04 или 0x00 и имеют номера сокетов источника и назначения, равные 0x0452. Режим работы [
До 7 служб SAP в одном SAP-пакете
Тип службы Имя сервера Номер сети Номер узла Номер со кета Промежуточные сети
...48 байтов
= 1 байт Рис. 5-14. Структура пакета SAP for IPX Примечание Рис. 5-14 отражает структуру пакетов SAP Response и SAP GetNearestServer Response. Пакеты SAP Request и SAP GetNearestServer Request содсржат только поля режима работы и типа службы и имеют длину в 34 байта (30 байтов на IPX-заголовок и 4 байта на SAP-заголовок). Режим работы. Двухбайтовое поле, указывающее тип SAP-счгобщения. Значения этого поля описываются в таблице 5-3. Таблица 5-3. Режимы работы SAP Режим работы
Тип сообщения
Описание
I
Request(запрос)
Посылается маршрутизатором пли клиентом SAP для запроса информации обо всех службах или о службах определенного типа Ответ на SAP Request; периодические оповещения SAP тоже посылаются как SAP
Response (ответ)
Response
GctNearestScrver Request (запрос GetNearestServer) GetNearestServer Response (ответ GetNearestServer)
Посылается рабочей станцией для запроса межсетевою IPX-адреса ближайшего сервера (отвечающего раньше остальных) службы определенного типа Посылается в ответ на SAP-:ianpoc GetNearestServer и содержит имя и межсетевой IPX-адрес ближайшего сервера службы запрошенного типа
За полем режима работы следует серия записей о службах SAP (до 7 и одшш сообщении). Максимальный размер пакета SAP — 480 байтов. Если нужно сообщить информацию более чем о семи службах, она посылается в нескольких пакетах SAP,
170
ЧАСТЬ 1
Маршрутизация
Тип службы. Двухбайтовое поле, указывающее тип службы. Каждому типу службы соответствует уникальное числовое значение, определенное компанией Novell. Некоторые из наиболее распространенных типов служб SAP перечислены в таблице 5-4. Полный список типов служб SAP см. по ссылке SAP на http://wmdows.microsoft.com/windows2000/reskit/webresources. Таблица 5-4. Типы служб SAP Сервер
Тип службы (значение в шестнадцатеричной форме)
Неизвестный Файл-сервер NetWare Сервер печати NetWare Сервер Microsoft RFC Общий SAP-запрос
00-00 00-04 00-07 06-40 FF-FF
Имя сервера. 48-байтовое поле, в котором хранится имя сервера, объявляющего о данной службе, Комбинация полей имени сервера и типа службы уникально идентифицирует службу в межсетевой IPX-среде. Имена серверов длиной менее 48 байтов завершаются ASCII-символом NULL. Номер сети. Четырехбайтовое поле, указывающее номер IPX-сети, в которой находится сервер с данной службой. Номер узла. Шестибайтовое поле, указывающее номер IPX-узла, на котором работает сервер, предоставляющий данную службу. Номер сокета. Двухбайтовое поле, указывающее номер сокета, прослушиваемый процессом данной службы. Промежуточные сети. Двухбайтовое поле, указывающее число маршрутизаторов, которые надо пересечь, чтобы достичь сервер с данной службой.
SAP-фильтры Чтобы получить доступ к SAP-фильтрам, откройте окно свойств интерфейса в папке SAP for IPX (SAP для IPX) и щелкните кнопку Input Filters (Фильтры входа) или Output Filters (Фильтры выхода). Функция SAP-фильтрации предусматривает как входную, так и выходную фильтрацию на каждом интерфейсе, основанную на принципе исключения. Вы можете сконфигурировать маршрутизатор Windows 2000 либо для разрешения всех служб SAP, кроме запрещенных фильтрами, либо запрета всех служб SAP, кроме разрешенных фильтрами (рис. 5-15). Примечание Сконфигурировать раздельные активные фильтры для Permit services except listed below (Разрешить все службы, кроме перечисленных) и Deny services except listed below (Запретить все службы, кроме перечисленных) нельзя. Примечание Параметры, определенные R одном фильтре, комбинируются логической операцией AND, а параметры, определенные в нескольких фильтрах, — логической операцией OR.
ГЛАВА 5
III!-!
IPX-маршрутизация
171
NCPSERVER
aocaf Area Cennectron
•Cancel
Рис. 5-15. Диалоговые окна Input Service Filters (Фильтры входящих служб) и Service Filter (Фильтр служб)
Статические службы Маршрутизатор Windows 2000 позволяет создавать статические службы в таблице SAP. Статические службы объявляются так же, как и обычные службы SAP. Они обычно используются для определения служб, доступных через соединение удаленного доступа по коммутируемой линии, Подробнее о применении статических служб SAP см. главу 6 «Маршрутизация с соединением по требованию* в этой книге. Чтобы добавить статические службы, в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IPX Routing (IPX-маршрутизация), щелкните правой кнопкой мыши папку Static Services (Статические службы) и выберите команду New Service (Новая служба). После этого появится д iaлоговое окно Static Services (Статические службы), показанное на рис. 5-16.
172
ЧАСТЬ 1
Маршрутизация
interface:
Рис. 5-16. Диалоговое окно Static Services
Широковещание NetBIOS Чтобы приложения NetBIOS корректно работали в межсетевой IPX-среде, «NetBIOS поверх IPX* предоставляет стандартные службы NetBIOS, в частности службу дейтаграмм (отдельные пакеты посылаются как широковещательные без подтверждений о приеме), службу сеансов (группы пакетов передаются между двумя конечными точками с подтверждениями о приеме) и службу имен (регистрация, запросы и освобождение NetBIOS-имен). Подробнее о NetBIOS см. главу 1 «Введение в TCP/IP» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server*. NetBIOS поверх IPX реализуется с использованием пакетов двух разных структур. Широковещательные пакеты NetBIOS поверх IPX. Используются для передачи NetBIOS-дейтаграмм и управления именами, например для запросов и регистрации имен. IPX-маршрутизаторы могут поддерживать (а могут и не поддерживать) пересылку широковещательных пакетов NetBIOS поверх IPX. Сеансы NetBIOS поверх IPX. Используются для надежного, ориентированного на соединение взаимодействия между двумя приложениями NetBIOS в межсетевой IPX-среде. Трафик сеанса NetBIOS поверх IPX является адресным (направленным на конкретный межсетевой IPX-адрес), а не широковещательным. В сеансах NetBIOS поверх IPX применяются IPX-пакеты типа 0x04 (Normal IPX), а также номера сокетов источника и назначения, равные 0x455. Поскольку трафик сеансов NetBIOS поверх IPX пересылается любыми IPX-маршрутизаторами, в следующих разделах рассматривается только широковещание NetBIOS поверх IPX и его поддержка маршрутизатором Windows 2000.
IPX WAN Broadcast Чтобы пемаршрутизируемые протоколы типа NetBIOS, полагающиеся на широковещание, корректно работали в межсетевой IPX-среде, IPX-маршрутизатор должен поддерживать пересылку широковещательного трафика. (NetBIOS использует широковещание при регистрации и разрешении NetBIOS-имен.) Поддержка пересыл-
ГЛАВА 5
IPX-маршрутизация
173
ки широковещательного трафика через IPX-маршрутизаторы реализуется с применением специального IPX-пакета типа 0x14; этот пакет также называется IPX WAN Broadcast. Заголовок IPX WAN Broadcast содержит в поле типа IPX-пакета значение 0x14 (в десятичной форме — 20) и адрес IPX-узла назначения OxFF-FF-FF-FF-FF-FF. IPXмаршрутизаторы можно настроить либо на пересылку, либо на «молчаливое» отклонение пакетов IPX WAN Broadcast. Широковещательные пакеты NetBIOS поверх IPX включают заголовок IPX WAN Broadcast.
IPX WAN Broadcast и сети Microsoft В сетях под управлением Windows 2000, Windows NT 4.0 (и нттже). Windows for Workgroups, Windows 95 или Windows 98 службы сервера и рабочей станции, применяющие для доступа к сетевым файлам и принтерам протокол SMB (Server Message Block), могут использовать NetBIOS поверх IPX или просто IPX. Процесс передачи SMB-блоков поверх IPX без NetBIOS называется прямым хостингом (direct hosting). Пакеты IPX WAN Broadcast используются в сетевых SMB-процессах на oci ове NetBIOS поверх IPX: • регистрации NetBIOS-имен; • запросах NetBIOS-имен; • объявлении обозревателя сети; • сетевом входе в систему. Пакеты IPX WAN Broadcast также используются в сетевых SMB-процессах на основе прямого хостинга: • •
запросах поиска имени сервера; объявлении обозревателя сети.
При прямом хостинге заголовок NetBIOS поверх IPX не применяется. Вместо ;>того SMB-блоки перелаются непосредственно по IPX. Сообщения прямого хостинга передаются в пакете IPX WAN Broadcast без соответствующих полей NetBIOS Отключение пересылки пакетов IPX WAN Broadcast может лишить компьютеры с Microsoft SMB способности распространять информацию, связанную с просмотром сети, разрешать имена и устанавливать соединения в межсетевой IPX-среде. Примечание По умолчанию Routing and Remote Access Server Setup Wizard (Мастер настройки сервера маршрутизации и удаленного доступа) настраивает широковещание NetBIOS поверх IPX для интерфейса Internal (Внутренний) на npnevi и пересылку широковещательных пакетов, а для любых LAN-интерфейсов — только на прием (без пересылки). В этой конфигурации по умолчании) пересылка широковещательных IPX-пакетов на маршрутизаторе Windows 2000 запрещена. Чтобы разрешить пересылку таких пакетов, настройте соответствующие LAN-интерфейсы на доставку широковещательных пакетов «NetBIOS поверх IPX» при любых условиях. Для этого в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IPX Routing (IPX-маршрутизация) и в п а н к е
174
ЧАСТЬ 1
Маршрутизация
NetBIOS Broadcasts (Широковещание NetBIOS) откройте окно свойств нужного LAN-интерфейса. В этом окне в разделе NetBIOS Broadcast Delivery (Доетавка широковещательных пакетов) активизируйте переключатель Always (Всегда).
Структура широковещательных пакетов NetBIOS поверх IPX Заголовок широковещательного пакета NetBIOS поверх IPX (рис. 5-17) является комбинацией заголовков IPX WAN Broadcast и NetBIOS, которые размещаются непосредственно за IPX-заголовком. Широковещательные пакеты NetBIOS поверх IPX относятся к типу пакетов 0x14; при этом они используют номер узла назначения, равный OxFF-FF-FF-FF-FF-FF, и номера сонетов источника и назначения, равные Ох-455. Сеть 1 Сеть 2 СетьЗ
IPX WAN Broadcast
Сеть 4 Сеть 5 Сеть 6 Сеть/ Сеть 8 Флаги типа имени Поток данных типа 2 NetBIOS-имя
._ _| ...16 байтов.
NetBIOS
= 1 байт
Рис. 5-17. Структура широковещательных пакетов NetBIOS поверх IPX Сети 1-8 (Заголовок IPX WAN Broadcast) Первые восемь полей (сети 1-8) представляют собой заголовок IPX WAN Broadcast. В этих полях регистрируются IPX-сети, через которые прошел пакет IPX WAN Broadcast. Запись ведется IPX-маршрутизаторами, пересылающими данный пакет по межсетевой IPX-среде. Для предотвращения петель маршрутизации эта информация о сетевом пути анализируется при приеме на маршрутизаторе, и пакет пересылается во все сети, кроме тех, в которых он уже был. Если пакет IPX WAN Broadcast уже прошел восемь сетей, он «молча» отбрасывается следующим на пути маршрутизатором. Однако вспомним, что максимальное число переходов для любого IPX-пакета в межсетевой среде, использующей RIP for IPX, равно 15. Разница в максимальном числе переходов для пакетов IPX WAN Broadcast и обычных IPX-пакетов может вызвать проблемы в больших межсетевых IPX-средах. Например, клиент NetWare может взаимодействовать с сервером NetWare, находящимся в 10 переходах от него, потому что межсетевой IPX-адрес этого сервера определяется запросом таблицы SAP или дерева каталогов на основном для данного
ГЛАВА 5
IPX-маршрутизация
175
клиента сервере NetWare. Запросы на соединение, посылаемые серверу NetWare, это адресный трафик, который попадает на данный сервер NetWare, поскольку число переходов не превышает 15. С другой стороны, для клиента Microsoft SMB компьютер с Windows 2000 Server в 10 переходах от него недостижим, потому что его межсетевой IPX-адрес определяется запросом NetBIOS-имени, посылаемым в широковещательном пакете NetBIOS поверх IPX, а этот пакет отбрасывается после прохождения восьми сетей. Поскольку ответ на запрос не приходит, определить межсетевой IPX-адрес компьютера с Windows 2000 Server и установить соединение ие удается. Во избежание этой проблемы проектируйте свою межсетевую IPX-среду так, чтобы в ней не было более семи IPX-маршрутизаторов между любыми двумя компьютерами с Windows 2000. Флаги типа имени (заголовок NetBIOS) Это однобайтовое поле в заголовке NetBIOS содержит набор флагов, определяющих статус NetBIOS-имени. Соответствующие битовые флаги перечислены в таблице 5-5. Таблица 5-5. Битовые флаги типа имени Бит типа имени
Описание
1 2 3, 4. 5 6 7 8
Групповое (1) или уникальное имя (0) Имя занято (1) или свободно (0) Не используются Имя зарегистрировано (1) или не зарегистрировано (0) Имя дублируется (1) или не дублируется (0) Регистрация имени отменена (1) или имя еще не снято с регистрации (0)
Биты нумеруются от старшего (бит 1) к младшему (бит 8), Поток данных типа 2 (заголовок NetBIOS) Это однобайтовое поле в заголовке NetBIOS указывает тип NetBIOS-пакета, Его возможные значения перечислены в таблице 5-6. Таблица 5-6. Значения поля -«поток данных типа 2» Значение
Описание
1 .' 3
Идет поиск имени (для пакетов запросов NetBIOS-имен) Имя распознано Добавить имя (для пакетов регистрации NetBIOS-имен)
NetBIOS-имя (заголовок NetBIOS) В этом 16-байтовом поле заголовка NetBIOS хранится NetBIOS-имя,
Статические NetBIOS-имена Если в окне свойств интерфейса, открытого из папки NetBIOS Broadcast (Широковещание NetBIOS) в оснастке Routing and Remote Access (Маршрутизация ц удаленный доступ), в разделе NetBIOS Broadcast Delivery (Доставка широкопещательпых пакетов) выбран переключатель Only for statically seeded names (Тплько
176
ЧАСТЬ 1
Маршрутизация
для статически заданных имен), то широковещательные пакеты NetBIOS поверх IPX пересылаются лишь для определенной группы NetBIOS-имен и только в выбранном направлении. Статические NetBIOS-имена можно использовать для ограничения широковещательного трафика NetBIOS поверх IPX в тех средах, где приложениям NetBIOS на клиентской стороне нужен доступ лишь к малой группе приложений NetBIOS на серверной стороне. Например, в среде Lotus Notes с применением NetBIOS поверх IPX множеству клиентов Lotus Notes требуется доступ к сравнительно небольшому числу серверов Lotus Notes. В такой ситуации сетевой администратор настраивает маршрутизаторы на пересылку только тех широковещательных пакетов NetBIOS поверх IPX, которые адресованы на NetBIOS-имена, соответствующие именам серверов Lotus Notes, Чтобы добавить статические NetBIOS-имена, в оснастке Routing and Remote Access раскройте узел IPX Routing (IPX-маршрутизация), щелкните правой кнопкой мыши папку Static NetBIOS Names (Статические NetBIOS-имена) и выберите команду New NetBIOS Name (Новое NetBIOS-имя). После этого появится диалоговое окно Static NetBIOS Name (Статическое имя NetBIOS), показанное на рис. 5-18.
interface
Рис. 5-18. Диалоговое окно Static NetBIOS Name
Дополнительные материалы Более подробную информацию об IPX см. тз книге: • Laura A. Chappcl «Novell's Guide to LAN/WAN Analysis: IPX/SPX», 1998, San Jose, CA: Novell Press.
ГЛАВА
6
Маршрутизация с соединением по требованию
Windows 2000 обеспечивает полную поддержку маршрутизации с соединением по требованию — перенаправления пакетов по каналам связи типа «точка-точка», например по аналоговым телефонным линиям и ISDN. Маршрутизация с соединением но требованию позволяет подключаться к Интернету и интрасетям филиалов или реализовать VPN-соединения между маршрутизаторами. В этой главе Введение в маршрутизацию с соединением по требованию 178 Процесс маршрутизации с соединением по требованию 184 Защита при маршрутизации с соединением по требованию 190 Создание учетных записей пользователей с помощью Demand-Dial Wizard Блокировка соединений по требованию 195 Маршрутизация с соединением по требованию и протоколы маршрутизации
1^4 197
IPX-соединения по требованию 204 Выявление и устранение проблем
205
См. также • Об одноадресной маршрутизации — главу 1 «Обзор одноадресной маршрутизации» в этой книге. • Об IP-маршрутизации в Windows 2000 — главу 3 «Одноадресная IP-маршрутизация» в этой книге, • Об IPX-маршрутизации в Windows 2000 — главу 5 «IPX-маршрутизация» в .этой книге. • Подробнее об установлении РРР-соединений и о наборе протоколов РРР — главу 7 «Сервер удаленного доступа» в этой книге.
1 Зак 3343
178
ЧАСТЬ 1
Маршрутизация
•
Подробнее о виртуальных частных сетях — главу 9 «Виртуальные частные сети» в этой книге. • Подробнее о маршрутизаторе Windows 2000 — главу 2 «Служба маршрутизации и удаленного доступа» в этой книге.
Введение в маршрутизацию с соединением по требованию Маршрутизация с соединением по требованию (demand-dial routing) — это пересылка пакетов по каналу связи, для которого используется протокол РРР (Pointto-Point Protocol). PPP-канал представляется в маршрутизаторе Windows 2000 как интерфейс соединения но требованию (demand-dial interface)*. Такие интерфейсы позволяют при необходимости создавать соединения в коммутируемой несущей среде — по постоянным подключениям или устанавливаемым по требованию. В случае LAN- и постоянных WAN-каналов соответствующий интерфейс всегда находится в активном или подключенном состоянии. Пакет можно переслать, не создавая физическое или логическое соединение. Однако интерфейс соединения по требованию может находиться либо в подключенном, либо в отключенном состоянии. Если в момент пересылки пакета такой интерфейс находится в отключенном состоянии, его нужно сначала перевести в подключенное состояние. Процесс установления соединения, состоящий из этапов создания физического или логического соединения и установления РРР-соединения, вносит в процесс пересылки пакета некую задержку, которая называется задержкой установления соединения (connection establishment delay). Ее длительность зависит от типа создаваемого соединения (физического или логического). Например, задержка установления соединения для аналоговых телефонных линий или Х.25 варьируется в диапазоне от 10 до 20 секунд и более, а для линий ISDN (Integrated Services Digital Network) не превышает 3-5 секунд. При использовании приложений, доступных через соединения по требованию, следует учитывать задержку установления соединения и принять во внимание два фактора, •
Сколько времени приложение ждет создания сетевого соединения (этот параметр также называется таймаутом приложения). Если таймаут приложения длительнее задержки установления соединения, тогда это приложение при неудачной попытке соединения будет сообщать пользователю об ошибке.
•
Сколько раз приложение пытается установить сетевое соединение. При первой попытке сетевой трафик пересылается маршрутизатору с поддержкой соединений по требованию (demand-dial router), который инициирует процесс установления соединения. Поскольку размер буфера на маршрутизаторе не бесконечен, а процесс установления соединения занимает определенное время, продолжающие поступать пакеты, которые надо переслать по затребованному соединению, могут перезаписать первоначальный пакет запроса приложения на подключение
В русской версии Windows 2000 Server .ITOT интерфейс называется интерфейсом вызова по требованию, а соответствующий вид маршрутизации — маршрутизацией вызова по требованию. — Прим. перев.
ГЛАВА 6
Маршрутизация с соединением по требованию
179
к какому-либо ресурсу. Поэтому у приложения, предпринимающего несколько попыток установить соединение, больше шансов переслать пакет запроса на подключение, как только соединение будет установлено. Приложения, в которых предусмотрены длительные таймауты или несколько попыток соединения, скорее всего успешно дождутся установления связи. Интерактивные приложения вроде Web-браузеров и Telnet могут сообщить о неудаче при первом соединении. Но, когда пользователь повторит попытку, такое приложение успешно соединится с нужным ресурсом, так как соединение по требованию было создано еще при первой попытке подключения. После установления связи пакеты пересылаются по соединению, созданному по требованию. Поскольку стоимость таких соединений, как правило, определяется временем их использования, после простоя в течение заданного времени связь разрывается. Соединения но требованию позволяют задействовать более дешеиые WAN-каналы удаленного доступа и платить за них, только когда они реально используются.
Маршрутизация с соединением по требованию и удаленный доступ Маршрутизация с соединением по требованию — не то же самое, что удаленный доступ; в первом случае происходит соединение между сетями, во втором — подключение к сети одного пользователя. Однако и обоих случаях для согласования параметров соединения, аутентификации и инкапсуляции данных, передаваемых по соединению, применяется РРР. Служба маршрутизации и удаленного доступа Windows 2000 позволяет раздельно разрешать соединения по требованию и удаленного доступа, но при этом они используют одни и те же: • параметры в пользовательских учетных записях; •
настройки безопасности, в том числе шифрование и протоколы аутентификации;
•
политики удаленного доступа;
• службы аутентификации — Windows или RADIUS (Remote Authentication D i a l In User Service); •
параметры выделения IP- и IPX-адресов;
•
средства РРР, например МРРС (Microsoft Point-to-Point Compression), Multilink и ВАР (Bandwidth Allocation Protocol);
• средства диагностики и устранения неполадок, включая протоколирование событий, трассировку и средства учета службы аутентификации Windows или RADIUS.
Типы соединений по требованию Соединения но требованию различаются по следующим характеристикам: • по подключению — постоянному или устанавливаемому по требованию; •
по инициации — только одной или любой из сторон.
Соответствующий выбор влияет на конфигурацию интерфейса соединения (вы:юва) по требованию.
180
ЧАСТЬ 1
Маршрутизация
Постоянные и устанавливаемые по требованию подключения Устанавливаемые по требованию подключения применяются в тех случаях, когда решающим является фактор стоимости использования коммуникационного канала. Например, междугородные вызовы по аналоговым телефонным линиям оплачиваются поминутно. При вызове по требованию соединение создается только при пересылке трафика и закрывается по истечении определенного времени простоя. Функцию отключения при простое можно настроить как на вызывающем (calling router), так и на отвечающем маршрутизаторе (answering router). • Для настройки отключения при простое на вызывающем маршрутизаторе (инициирующем соединение) установите время простоя до разъединения па вкладке Options (Параметры) окна свойств интерфейса подключения по требованию. • Для настройки отключения при простое на отвечающем маршрутизаторе (принимающем запрос на соединение) установите время простоя до разъединения на вкладке Dial-In Constraints (Ограничения по входящим звонкам) окна свойств профиля коммутируемых соединений для политики удаленного доступа, используемой нужным интерфейсом соединения по требованию. Постоянные подключения базируются на WAN-технологиях, за пользование которыми взимается фиксированная плата, и соединение может быть активным круглосуточно. Примеры постоянных подключений на основе таких WAN-технологий — местная телефонная связь, выделенные аналоговые линии и ISDN. При разрыве постоянного подключения вызывающий маршрутизатор пытается немедленно восстановить его. Параметры постоянных подключений следует настроить как на вызывающем, так и на отвечающем маршрутизаторе. ^ Чтобы настроить параметры постоянного подключения на вызывающем маршрутизаторе: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) укажите папку Routing Interfaces (Интерфейсы маршрутизации), щелкните правой кнопкой мыши нужный интерфейс соединения по требованию и выберите команду Properties (Свойства). 2. На вкладке Options (Параметры) выберите переключатель Persistent connection (Постоянное подключение). ^ Чтобы настроить параметры постоянного подключения на отвечающем маршрутизаторе: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) укажите папку Remote Access Policies (Политика удаленного доступа), щелкните правой кнопкой мыши имя политики удаленного доступа, используемой соответствующим интерфейсом соединения по требованию, и выберите команду Properties (Свойства). 2. Щелкните кнопку Edit profile (Изменить профиль). 3. На вкладке Dial-in Constraints (Ограничения по входящим звонкам) сбросьте флажок Disconnect if idle for (Разъединение при простое более). Параметры подключения должны быть настроены и на вызывающем, и на отвечающем маршрутизаторе. Если вызывающий маршрутизатор настроен на постоянное
ГЛАВА 6 Маршрутизация с соединением по требованию
181
подключение, а отвечающий — па разъединение при простое, последний будет разрывать связь по истечении определенного времени в простое. Тогда вызывающему маршрутизатору придется восстанавливать подключение, что будет создавать наузу в пересылке пакетов, равную задержке установления соединения.
Соединения, инициируемые только одной или любой из сторон При использовании соединений, инициируемых любой из сторон (two-way initiated connections), любой маршрутизатор может выступать в роли отвечающего или иызывающего — в зависимости от того, какой из них инициирует соединение. Оба маршрутизатора нужно сконфигурировать как на инициацию, так и на прием запроса на соединение. Такие соединения применяются, когда их создания может потребовать трафик, поступающий на любой и:? маршрутизаторов. Для поддержки соединений по требованию, инициируемых любой из сторон, необходимы следующие условия: •
оба маршрутизатора настроены и как LAN-, и как WAN-маршрутизаторы;
• на оба маршрутизатора добавлены пользовательские учетные записи, чтобы отвечающий маршрутизатор мог проверять удостоверения (учетные данные) вызывающего маршрутизатора; •
на обоих маршрутизаторах настроены интерфейсы соединения по требованию, имена которых совпадают с тем, что указано в учетной записи, используемой текущим вызывающим маршрутизатором. При этом сконфигурированы и такие параметры, как телефонный номер отвечающего маршрутизатора и удостоверения для аутентификации вызывающего маршрутизатора;
• на обоих маршрутизаторах определены статические маршруты. Чтобы маршрутизация с соединением по требованию любой из сторон работала корректно, имя пользователя вызывающего маршрутизатора должно совпадать с именем интерфейса соединения по требованию на другой стороне соединения. Пример такой конфигурации показан в таблице 6-1. Таблица 6-1. Пример конфигурации соединения, инициируемого любой из сторон Маршрутизатор
Имя интерфейса соединения гнмребованин)
Маршрутизатор центрального офиса
New York Router
Маршрутизатор филиала
CorpHub
Имя пользовательской учетной записи CorpHub NewYorkRouter
При использовании соединений, инициируемых только одной стороной, один из маршрутизаторов всегда отвечающий, а другой — всегда вызывающий. В этом случае настройка маршрутизаторов упрощается, так как пользовательские учетные записи, интерфейсы соединений по требованию и статические IP-маршруты не обязательно полностью конфигурировать на обеих сторонах соединения. Вместо нлстроики интерфейса соединения по требованию и статических маршрутов на отвечающем маршрутизаторе достаточно указать статические маршруты в параметрах входящих вызовов в пользовательской учетной записи вызывающего маршрутизатора. При создании соединения статические маршруты, определенные в пользовательской учетной записи вызывающего маршрутизатора, добавляются в таблицу 1Р-мар-
182
ЧАСТЬ 1
Маршрутизация
шрутшации на отвечающем маршрутизаторе. Если новые статические маршруты распространяются с помощью протоколов маршрутизации, тогда возникает задержка между моментом создания соединения и тем моментом, когда всем маршрутизаторам в интрасети отвечающего маршрутизатора становится известно о новом маршруте. Следовательно, хосты в интрасети вызывающего маршрутизатора начинают принимать трафик от хостов в интрасети отвечающего маршрутизатора не сразу, а тоже с некоторой задержкой. Если отвечающий маршрутизатор находится в домене Windows 2000 смешанного режима или в домене Windows NT 4.0, статические маршруты, определенные в пользовательской учетной записи, недоступны. Тогда для поддержки соединений по требованию, инициируемых только одной из сторон, необходимы следующие условия: •
оба маршрутизатора настроены и как LAN-, и как WAN-маршрутизаторы;
• создана пользовательская учетная запись вызывающего маршрутизатора, позволяющая проверять его удостоверения защиты отвечающим маршрутизатором; •
интерфейс соединения по требованию па вызывающем маршрутизаторе сконфигурирован с удостоверениями пользователя соответствующей учетной записи, а аналогичный интерфейс на отвечающем маршрутизаторе имеет то же имя, что и пользовательская учетная запись, применяемая вызывающим маршрутизатором. Интерфейс соединения по требованию на отвечающем маршрутизаторе для исходящих вызовов не используется, поэтому в его свойствах не требуется указывать ни телефонный номер вызывающего маршрутизатора, ни удостоверения соответствующего пользователя.
Компоненты поддержки маршрутизации с соединением по требованию Основными компонентами являются вызывающий и отвечающий маршрутизаторы, а также несущая среда, по которой устанавливается соединение между этими маршрутизаторами (рис. 6-1).
Интрасеть
Несущая среда соединения
маршрутизатор
Вызывающий маршрутизатор Интрасеть
Рис. 6-1. Компоненты поддержки маршрутизации с соединением по требованию
Вызывающий маршрутизатор Вызывающий маршрутизатор инициирует соединение. Он состоит из следующих элементов.
ГЛАВА 6
Маршрутизация с соединением по требованию
183
•
Служба маршрутизации и удаленного доступа. Эта служба должна быть настроена как LAN- и WAN-маршрутизатор, а также сконфигурирована на использование пула IP-адресов (DHCP- или статического пула) и методов аутентификации.
•
Порт. Логический или физический коммуникационный канал, поддержипающий одно РРР-соединение. Физические порты соответствуют аппаратным средствам, установленным на вызывающем маршрутизаторе. VPN-порты являются логическими.
•
Интерфейс соединения по требованию. В данном случае этот интерфейс представляет РРР-соединение и содержит такую конфигурационную информацию, как используемый порт, адрес, применяемый при создании соединения (например, телефонный номер), удостоверения, методы аутентификации и шифрования.
• Маршрут. IP- или IPX-маршрут и таблице маршрутизации на вызывающем маршрутизаторе, настроенный на пересылку трафика через интерфейс соединения по требованию.
Отвечающий маршрутизатор Отвечающий маршрутизатор принимает запрос на соединение от вызывающего маршрутизатора и состоит из следующих элементов. • Служба маршрутизации и удаленного доступа. Эта служба должна быть настроена как LAN- и WAN-маршрутизатор, а также сконфигурирована на использование пула IP-адресов (DHCP- или статического пула) и на аутентификацию пользователя. • Порт. Логический или физический коммуникационный канал, поддерживающий одно РРР-соединение. Физические порты соответствуют аппаратным средствам, установленным на вызывающем маршрутизаторе. VPN-порты являются логическими. • Пользовательская учетная запись. Для аутентификации вызывающего маршрутизатора его учетные данные должны соответствовать параметрам, определенным в пользовательской учетной записи. Эта учетная запись должна быть либо локальной на вызывающем маршрутизаторе, либо доступной через службу ,ia[циты Windows 2000. Если отвечающий маршрутизатор настроен на аутентификацию через RADIUS, тогда серверу RADIUS нужно обеспечить доступ к пользовательской учетной записи вызывающего маршрутизатора. Пользовательская учетная запись требует следующей настройки. • На вкладке Dial-in (Входящие звонки) выберите вариант разрешения на удаленный доступ либо как Allow access (Разрешить доступ), либо как Control access through Remote Access Policy (Управление на основе политики удаленного доступа). • На вкладке General (Общие) сбросьте флажок User must change password at next logon (Потребовать смену пароля при следующем входе в систему) и установите флажок Password never expires (Срок действия пароля не ограничен). В случае соединения, инициируемого только одной из сторон, сконфигурируйте статические IP-маршруты, которые добавляются в таблицу маршрутизации на отвечающем маршрутизаторе при создании соединения.
184
ЧАСТЬ 1
Маршрутизация
•
Интерфейс соединения по требованию. В случае соединений, инициируемых любой из сторон, этот интерфейс представляет РРР-соединение. В случае соединений, инициируемых только одной из сторон и использующих статические маршруты в учетной записи вызывающего маршрутизатора, настройка интерфейса соединения но требованию на отвечающем маршрутизаторе не требуется. • Маршрут. В случае соединений, инициируемых любой из сторон, это IP- или IPX-маршрут в таблицах маршрутизации на вызывающем маршрутизаторе, настроенный на пересылку трафика через интерфейс соединения по требованию. В случае соединений, инициируемых только одной из сторон, Вы можете указать статические IP-маршруты и пользовательской учетной записи вызывающего маршрутизатора. • Политика удаленного доступа. Чтобы указать параметры соединения, специфичные для подключений по требованию, создайте отдельную политику удаленного доступа с установленным атрибутом Windows-Groups (Windows-Groups) для группы, которая объединяет псе пользовательские учетные записи вызывающих маршрутизаторов, входящих в мту группу. Для подключений по требованию отдельная политика удаленного доступа не нужна.
Несущая среда соединения РРР-каналы связи устанавливаются либо по физическим несущим средам, либо через логические туннели. К первым относятся аналоговые телефонные линии и ISDN, а ко вторым — протоколы РРТР (Point-to-Point Tunneling Protocol) и L2TP (Layer Two Tunneling Protocol).
Процесс маршрутизации
с соединением по требованию
В общих чертах этот процесс проходит следующим образом (при условии, что и вызывающий, и отвечающий марш руги заторы работают под управлением Windows 2000). 1. Получив пакет, вызывающий маршрутизатор отыскивает оптимальный маршрут для пересылки этого пакета. 2. Если в оптимальном маршруте указан интерфейс соединения по требованию, проверяется состояние этого интерфейса. Если его состояние — «подключен», пакет пересылается но данному интерфейсу с применением фильтров, определенных для интерфейса. Если же его состояние — «отключен», тогда компонент, отвечающий за пересылку данных по IP или IPX, вызывает Dynamic Interface Manager (диспетчер динамических интерфейсов) и указывает ему активизировать заданный в маршруте интерфейс соединения по требованию. 3. Диспетчер динамических интерфейсов проверяет расписание исходящих вызовов (dial-out hours) и фильтры, определенные для этого интерфейса. Если расписание или фильтры запрещают инициацию соединения по требованию, попытка соединения заканчивается неудачей, причина которой сообщается через параметр Unreachability reason (Причина недостижимости) этого интерфейса.
ГЛАВА 6
Маршрутизация с соединением по требованию
185
Подробнее о причинах недостижимости см. раздел «Средства диагностики» далее в этой главе. 4, Если соединение разрешается, диспетчер динамических интерфейсов считывает конфигурационную информацию данного интерфейса соединения по требованию из файла %5i/.s£emfioot% \Systein32\Ras\Router.pbk. 5. Иеходя из порта, указанного в конфигурации интерфейса, устанавливается физическое или логическое соединение со второй стороной. В конфигурациях с прямым подключением но последовательному или параллельному интерфейсу телефонный номер, естественно, не указывается. В :ггом случае между двумя компьютерами устанавливается физическое соединение с использованием их последовательных или параллельных портов. Для модемов или ISDN набирается указанный телефонный помер с применением заданного порта. Если этот порт недоступен, используется другой порт того же типа. Если таких портов нет, попытка соединения заканчивается неудачей и сообщается о ее причине. В случае VPN-соединений используется заданный IP-адрес или хост-имя и создается либо РРТР-туннель (для РРТР-соединений), либо сопоставление Оезонаепости IPSee и Е2ТР-тунпель (для соединений L2TP поверх IPSec). G. Как только физическое или логическое соединение установлено, с конечной точкой согласуются параметры РРР-соединения. Ниже кратко описывается специфика РРР-соединениЙ при использовании интерфейсов соединении по требованию. • Отвечающий маршрутизатор назначает IP-адрес вызывающему, а тот - отвечающему. Эти IP-адреса должны принадлежать разным подсетям, чтобы маршрутизаторы случайно не назначили друг другу одинаковые IP-адреса. • Если вызывающий маршрутизатор сконфигурирован на IP-адреса DNS- или WINS-серверов, тогда их IP-адреса не запрашиваются (в ином случае — запрашиваются). Отвечающий маршрутизатор никогда не запрашивает IP-адреса DNS- или WINS-серве-ров от вызывающего маршрутизатора, • В отличие от клиентов удаленного доступа Windows 2000 вызывающий маршрутизатор не создает маршрут но умолчанию и не посылает отвечающему сообщение DHCPInform. По умолчанию вызывающий маршрутизатор не регистрируется на DNS- или WINS-серверах отвечающего маршрутизатора, если только параметру ReglsterRoutersWithNameServers в разделе реестра HKEY_LOCAL_MACHTNE\System\CurrentControlSet\Services\Rasraan\ PPP\ControlProtocols\BuiltIn не присвоено значение 1. 7. Удостоверения вызывающего маршрутизатора посылаются на этапе аутентификации после согласования РРР-протокола аутентификации. На основе этих удостоверений отвечающий маршрутизатор делает одно из двух: •
проверяет соответствующую базу данных учетных записей и локальную политику удаленного доступа. Если все в порядке, соединение принимается; • посылает атрибуты соединения сконфигурированному серверу RADIUS. Если этот сервер представляет собой компьютер под управлением Windows 2000 Server и Internet Authentication Service (IAS) (Служба проверки
186
ЧАСТЬ 1
Маршрутизация
подлинности в Интернете), отвечающий маршрутизатор проверяет соответствующую базу данных учетных записей и политику удаленного доступа. Если все в порядке, соединение принимается. 8. Если в пользовательской учетной записи вызывающего маршрутизатора определены статические маршруты, они заносятся в таблицу IP-маршрутизации отвечающего маршрутизатора. 9. Отвечающий маршрутизатор ищет в файле %5z/s£em-/?ottf%\System32\Ras\Router.pbk имя интерфейса соединения по требованию, совпадающее с именем пользователя в удостоверениях вызывающего маршрутизатора. Если такое совпадение обнаруживается, данный интерфейс переводится в подключенное состояние. 10. Как только создание РРР-соединения завершается, вызывающий маршрутизатор начинает пересылать пакеты, применяя к ним фильтры, определенные для данного интерфейса. Если имя пользователя в удостоверениях вызывающего маршрутизатора не совпадает с именем интерфейса соединения по требованию, этот маршрутизатор считается клиентом удаленного доступа. А если в пользовательской учетной записи не определены статические маршруты, возможны проблемы с маршрутизацией. Так, если имя пользователя в удостоверениях вызывающего маршрутизатора lie соответствует имени интерфейса соединения по требованию на отвечающем маршрутизаторе, вызывающий рассматривается не как маршрутизатор, а как клиент удаленного доступа. Пакеты, поступающие из интрасети вызывающего маршрутизатора, пересылаются по соединению, а затем перенаправляются отвечающим маршрутизатором. Однако, когда отвечающий маршрутизатор принимает ответные пакеты, адресованные интрасети вызывающего маршрутизатора, маршруты к этой интрасети настраиваются на использование интерфейса соединения по требованию. А поскольку этот интерфейс находится в отключенном состоянии, отвечающий маршрутизатор пытается установить соответствующее соединение с вызывающим маршрутизатором. Если имеется еще один порт того же типа, создается второе соединение по требованию. В ином случае пакеты просто отбрасываются и сообщается о причине недо<тижимости. Так что дело кончится тем, что либо будет создано два соединения по требованию, либо ответные пакеты будут отбрасываться.
VPN-соединение, устанавливаемое между маршрутизаторами по требованию VPN-соединение между маршрутизаторами обычно используется для взаимного соединения удаленных офисов, если их маршрутизаторы подключены к Интернету по постоянным WAN-каналам типа Т1 или Frame Relay. В такой конфигурации VPN-соединение является постоянным и доступным круглосуточно. Однако, если нужного WAN-канала у Вас нет или если его использование нецелесообразно, Вы можете сконфигурировать VPN-соединение, устанавливаемое между маршрутизаторами по требованию (рис. 6-2).
ГЛАВА 6
Туннель -
Соединение удаленного доступа
Маршрутизация с соединением по требованию
187
Нктрасеть
J
Рис. 6-2. VPN-соединение, устанавливаемое между маршрутизаторами по требованию Такое VPN-соединение требует двух интерфейсов соединения по требованию, которые настраиваются па VPN-клиенте (вызывающем маршрутизаторе). 1. Интерфейс для установления связи с местным провайдером услуг Интернета (1SP). 2. Интерфейс для VPN-соединения между маршрутизаторами. VPN-соединение между маршрутизаторами устанавливается автоматически, когда Вы направляете трафик в определенный участок межсетевой среды. Например, если появляется пакет, который нужно перенаправить в филиал, маршрутизатор филиала дозванивается до локального TSP, а затем создает VPN-соединение с маршрутизатором центрального офиса, подключенного к Интернету. Примечание Здесь предполагается, что маршрутизатор центрального офиса (отвечающий маршрутизатор) подключен к Интернету по постоянному WAN-кашиту, хотя оба маршрутизатора могут подключаться к Интернету через своих ISP по коммутируемым WAN-каналам удаленного доступа. Однако это возможно, только если ISP предоставляет заказчикам услуги маршрутизации с соединением по требованию; в этом случае ISP, получив IP-пакет, который нужно доставить заказчику, вызывает его маршрутизатор. Но лишь очень немногие 1SP предоставляют такие услуги. Чтобы настроить на маршрутизаторе интрасети филиала VPN-соединение, устанавливаемое между маршрутизаторами по требованию, проделайте следующие операции. •
Создайте интерфейс соединения по требованию для подключения к Интернету через подходящее устройство (модем или ISDN-устройство) и укажите в '.то свойствах телефонный номер местного ISP, имя и пароль пользователя для доступа к Интернету. • Создайте интерфейс соединения по требованию для VPN-соединения с маршрутизатором центрального офиса и укажите в его свойствах VPN-порт (РРТРили L2TP-nopT), IP-адрес Интернет-интерфейса маршрутизатора центрального
188
ЧАСТЬ 1
Маршрутизация
офиса, а также имя и пароль пользователя, которые будут проверяться VPN-сервером. Имя пользователя должно совпадать с именем интерфейса соединения по требованию на маршрутизаторе центрального офиса. • Создайте статический маршрут к хосту с IP-адресом Интернет-интерфейса маршрутизатора центрального офиса. Этот маршрут должен использовать интерфейс соединения с ISP по требованию. • Создайте статический маршрут (или маршруты) к IP-сети корпоративной интрасети. Этот маршрут должен использовать интерфейс VPN-соединения по требованию. Чтобы настроить на маршрутизаторе центрального офиса VPN-соединение, устанавливаемое между маршрутизаторами по требованию, проделайте следующие операции. • Создайте интерфейс соединения по требованию для VPN-соединения с маршрутизатором филиала и укажите в его свойствах VPN-порт (РРТР- или L2TPпорт). Имя этого интерфейса должно совпадать с именем пользователя в удостоверениях зашиты, применяемых маршрутизатором филиала при создании VPN-соединения. • Создайте статический маршрут (или маршруты) к IP-сетям интрасетей филиалов, Этот маршрут должен использовать интерфейс VPN-соединения по требованию. VPN-соединение между маршрутизаторами инициируется маршрутизатором филиала автоматически по следующей процедуре. 1. Пакеты, передаваемые в корпоративную сеть с компьютера, который расположен в интрасети филиала, пересылаются маршрутизатору центрального офиса. 2. Маршрутизатор филиала проверяет свою таблицу маршрутизации и отыскивает маршрут к корпоративной сети, в котором используется интерфейс VPN-соединения по требованию. 3. Маршрутизатор филиала проверяет состояние интерфейса VPN-соединения по требованию и обнаруживает, что он находится в отключенном состоянии. 4. Маршрутизатор филиала считывает информацию о конфигурации интерфейса VPN-соединения но требованию. 5. На основе этой информации маршрутизатор филиала пытается инициализировать VPN-соединение «маршрутизатор-маршрутизатор», используя IP-адрес Интернет-интерфейса маршрутизатора центрального офиса. 6. Чтобы установить VPN-соединение, маршрутизатор центрального офиса, выступающий в роли VPN-сервера, должен получить либо TCP-пакет запроса на установление VPN-соединения (через РРТР), либо эквивалентный UDP-пакет (через L2TP поверх IPSec). Поэтому следующий шаг — создание такого пакета. 7. Для пересылки пакета запроса на установление VPN-соединения маршрутизатору центрального офиса маршрутизатор филиала проверяет свою таблицу маршрутизации и отыскивает маршрут к хосту, использующий интерфейс соединения с ISP по требованию. 8. Маршрутизатор филиала проверяет состояние этого интерфейса и обнаруживает, что он находится в отключенном состоянии.
ГЛАВА 6
Маршрутизация с соединением по требованию
189
9. Маршрутизатор филиала считывает информацию о конфигурации интерфейса соединения с ISP по требованию. 10. На основе этой информации маршрутизатор филиала использует свой мсдем или ISDN-устройство, чтобы подключиться к местному ISP. 11. Как только связь с Г5Р установлена, пакет запроса на установление VPN-сосдинсния посылается маршрутизатору центрального офиса. 12. Маршрутизаторы центрального офиса и филиала согласовывают параметры VPN-соединения. В ходе этого согласования маршрутизатор филиала передает свои аутентификационные удостоверения, которые проверяются маршрутизатором центрального офиса. 13. Маршрутизатор центрального офиса проверяет свои интерфейсы соединений по требованию и находит один из них, чье имя совпадает с именем пользователя, переданным в процессе аутентификации; после этого он переводит интерфейс в подключенное состояние. 14. Маршрутизатор филиала пересылает пакет по VPN-туннелю, и маршрутизатор центрального офиса перенаправляет его на соответствующий адрес в своей интрасети. 15. Когда адресат в этой интрасети отвечает на пакет, переданный ему пользователем из интрассти филиала, ответный пакет пересылается маршрутизатору центрального офиса. 16. Маршрутизатор центрального офиса проверяет свою таблицу маршрутизации и отыскивает маршрут к сети филиала, использующий интерфейс VPN-соединения по требованию. 17. Маршрутизатор центрального офиса проверяет состояние этого интерфейса и обнаруживает, что он находится в подключенном состоянии. 18. Ответный пакет пересылается через Интернет по VPN-соединению. 19. Этот пакет принимается маршрутизатором филиала и пересылается хосту-отправителю.
Тестирование подключений, устанавливаемых по требованию Вы можете проверить правильность работы устанавливаемых по требованию подключений либо вручную, либо автоматически.
Проверка вручную В этом случае Вы тестируете, возможно ли установление РРР-соединения. Это позволяет проверить, правильно ли настроены методы аутентификации и шифрования, верны ли пользовательские удостоверения и корректен ли адрес, указали ли для интерфейса соединения но требованию. ^ Чтобы вручную подключиться через интерфейс соединения по требованию: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) щелкните папку Routing Interfaces (Интерфейсы маршрутизации), 2. Щелкните правой кнопкой мыши нужный интерфейс соединения по требованию. 3. Выберите команду Connect (Подключить).
190
ЧАСТЬ 1
Маршрутизация
Как только соединение будет установлено, значение в колонке Connection Status (Состояние подключения) сменится с Disconnected (Отключено) на Connected (Подключено). Если Вам не удается вручную подключиться через интерфейс соединения по требованию, см. раздел «Выявление и устранение проблем? далее в этой главе,
Автоматическая проверка В этом случае Вы тестируете, возможно ли автоматическое установление соединения при передаче трафика по данному маршруту. Прежде чем проводить автоматическую проверку, убедитесь, что на вызывающем и отвечающем маршрутизаторах имеются необходимые статические маршруты. Перед проверкой также убедитесь, что тестируемый интерфейс соединения по требованию находится в отключенном состоянии. Далее сгенерируйте трафик, направив его по какому-нибудь адресу, который находится на другой стороне соединения, устанавливаемого по требованию. Один из самых простых способов сгенерировать IP-трафик — воспользоваться командой ping или tracert. В случае ping или tracert первая попытка создать соединение может закончиться неудачей из-за задержки установления соединения. Но первый пакет, отправленный через интерфейс соединения по требованию, после некоторой задержки вызовет его перевод в подключенное состояние, и повторный ввод команды пройдет успешно. Если Вы хотите понаблюдать за процессом установления соединения, введите команду ping с ключом -t; тогда она будет посылать ICMP-сообщения Echo Request (эхо-запросы) вплоть до закрытия соединения. Если Вам не удается автоматически подключиться через интерфейс соединения по требованию, см. раздел «Выявление и устранение проблем» далее в этой главе.
Мониторинг подключений по требованию с помощью Rasmon Состояние подключения интерфейса соединения по требованию можно упидеть, щелкнув папку Routing Interfaces (Интерфейсы маршрутизации) в оснастке Routing and Remote Access. Однако :-rra оснастка не позволяет получить более детальные сведения о работе интерфейса (скорость последовательной передачи, статистика устройства, статистика соединения, ошибки устройства). Для просмотра информации о соединениях по требованию, инициированных маршрутизатором, запустите на этом маршрутизаторе утилиту Rasmon с компакт-диска «Ресурсы Microsoft Windows 2000 Server». Эта утилита сообщает только о соединениях по требованию, инициируемых маршрутизатором, который выступает в роли вызывающего. Интерфейсы соединений по требованию в подключенном состоянии не показываются. Данная утилита Rasmon эквивалентна программе Rasmon из состава Windows NT 4.0.
Защита при маршрутизации с соединением по требованию Для защиты соединений, устанавливаемых по требованию, используются те же средства, что и для защиты соединений удаленного доступа, в том числе: • разрешение на удаленный доступ;
ГЛАВА 6 Маршрутизация с соединением по требованию
191
• аутентификация; • шифрование; • ответный вызов (callback); • идентификатор звонящего (caller ID); •
блокировка учетной записи удаленного доступа.
Подробнее об ответных вызовах, идентификаторе звонящего и блокировке учетной записи удаленного доступа см. главу 7 «Сервер удаленного доступа» в этой книге и справочную систему Windows 2000 Server.
Разрешение на удаленный доступ Пользовательская учетная запись вызывающего маршрутизатора должна присутствовать в соответствующей базе данных отвечающего маршрутизатора или сервера RADIUS (если аутентификация осуществляется через службу RADIUS) и разрешать удаленный доступ к этому маршрутизатору. Такое разрешение может быть предоставлено либо явным образом, в самой учетной записи — в параметрах иходящих звонков выбран вариант Allow access (Разрешить доступ), — либо пеяшю, через политику удаленного доступа — в параметрах входящих звонков выбран вариант Control access through Remote Access Policy (Управление на основе полигики удаленного доступа), а в политике удаленного доступа активизировано правило Grant remote access (Предоставить право удаленного доступа).
Аутентификация Вызывающий маршрутизатор может быть аутентифицирован как на уровне пользователя, так и на уровне компьютера, Аутентификачия на уровне пользователя Удостоверения вызывающего маршрутизатора проверяются в процессе установления РРР-соедипения. Аутентификация на уровне пользователя осуществляется одним из следующих методов РРР-аутентификациш •
PAP (Password Authentication Protocol);
• SPAP (Shiva Password Authentication Protocol); • CHAP (Challenge Handshake Authentication Protocol); • MS-CHAP vl (Microsoft Challenge Handshake Authentication Protocol версии 1); • MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol версии .2); • EAP-MD5 (Extensible Authentication Protocol-Message Digest 5) CHAP; • EAP-TLS (Extensible Authentication Protocol-Transport Layer Security). Все только что перечисленные методы аутентификации, кроме EAP-TLS, требуют, чтобы удостоверения вызывающего маршрутизатора состояли из имени пользователя, домена и пароля. При всех методах аутентификации, кроме РАР, пароль передается по соединению в шифрованном или хэшировашюм виде. В случае EAP-TLS удостоверения вызывающего маршрутизатора представляют собой сертификат пользователя, проверяемый отвечающим маршрутизатором. Для выдачи и проверки сертификатов EAP-TLS требует создания инфраструктуры открытого ключа (Public Key Infrastructure, PKI).
192
ЧАСТЬ 1
Маршрутизация
Аутентификация на уровне компьютера Такая аутентификация выполняется в двух случаях (при маршрутизации с соединением по требованию). 1. В процессе сопоставления безопасности IPSec для соединений L2TP поверх IPSec — аутентификация на уровне компьютера выполняется путем обмена сертификатами компьютеров (также называемыми машинными сертификатами), 2. При аутентификации на уровне пользователя методом EAP-TLS — отвечающий маршрутизатор аутентифицируется на вызывающем маршрутизаторе, посылая ему свой машинный сертификат. Для выдачи и проверки сертификатов компьютеров нужна инфраструктура PKI.
Односторонняя и взаимная аутентификация Аутентификация при соединении по требованию может быть односторонней или взаимной. Односторонняя аутентификация При односторонней аутентификации (one-way authentication) вызывающий маршрутизатор аутентифипируется на отвечающем. Протоколы PAP, SPAP, CHAP, MSCHAP vl и EAP-MD5 лишь передают удостоверения вызывающего маршрутизатора отвечающему. В процессе односторонней аутентификации вызывающий маршрутизатор не получает никаких доказательств подлинности отвечающего маршрутизатора. Так что односторонняя аутентификация не обеспечивает защиту от неавторизованных отвечающих маршрутизаторов или компьютеров, маскирующихся под отвечающие маршрутизаторы. Взаимная аутентификация При взаимной аутентификации (mutual authentication) вызывающий маршрутизатор аутентифицируется на отвечающем, а тот — на вызывающем. Обе стороны соединения взаимно подтверждают свою идентификацию. Взаимная аутентификация поддерживается MS-CHAP v2 и EAP-TLS. Если используется MS-CHAP v2, обе стороны соединения передают хэш строки вызова (challenge .string) и пароль. В случае успеха каждая из сторон получает уверенность в том. что противоположная сторона имеет доступ к паролю учетной записи. Если же применяется EAP-TLS, то вызывающий маршрутизатор посылает сертификат пользователя, проверяемый отвечающим маршрутизатором, а последний посылает сертификат компьютера, проверяемый вызывающим маршрутизатором. EAP-TLS — самая защищенная форма взаимной аутентификации, но требующая создания инфраструктуры PKI. Примечание Windows NT 4.0 с Routing and Remote Access Service (RRAS) поддерживает двухстороннюю аутентификацию (two-way authentication). Эта функция на основе методов односторонней аутентификации обеспечивает взаимную аутентификацию. Если на интерфейсе соединения по требованию включена двухсторонняя аутентификация, вызывающий маршрутизатор заставляет отвечающий аутентифицироваться после того, как сам пройдет аутентификацию на отвечающем маршрутизаторе. Вызывающий маршрутизатор под управлением Windows 2000 никогда не
ГЛАВА 6
Маршрутизация с соединением по требованию
193
требует аутентификации отвечающего маршрутизатора под упраилением Windows NT 4.0 и службы RRAS. Но отвечающий маршрутизатор Windows 2000 может аутентифицироваться на вызывающем маршрутизаторе Windows NT 4.0 RRAS, если он того потребует.
Шифрование Для соединений, устанавливаемых по требованию, доступно два вида шифрования: МРРЕ (Microsoft Point-to-Point Encryption) и IPSec (Internet Protocol Security) (IP-безопасность). MPPE
Все РРР-соединения, в том числе РРТР (но не L2TP), могут использовать МРРЕ (Microsoft Point-to-Point Encryption). МРРЕ основан на алгоритме RSA (Riv,:stShamir-Adlcman) RC4 и применяется только при аутентификации по EAP-TLS или MS-CHAP (версий 1 и 2). МРРЕ может оперировать 40-, 56- или 128-битными шифровальными ключами. 40битный ключ предназначен для обратной совместимости. По умолчанию вызывающий и отвечающий маршрутизаторы используют самый стойкий ключ. Если отвечающий маршрутизатор требует более стойкий ключ, чем поддерживаемый вызывающим маршрутизатором, запрос на соединение отклоняется. IPSec В случае соединений по требованию с применением L2TP поверх IPSec алгоритм шифрования определяется в процессе сопоставления безопасности (security association, SA). В числе поддерживаемых алгоритмов шифрования: • •
DES с 56-битным ключом; 3DES (Triple DES), который использует три 56-битных ключа и рассчитан на среды, требующие высокой степени защиты.
Исходные шифровальные ключи генерируются в процессе аутентификации по IPSec. Подробнее об IPSec см. главу 8 «IP-безопасность» в книге «Сети TCP/IP* из серии «Ресурсы Microsoft Windows 2000 Server»; подробнее о настройке IPSec для соединений L2TP поверх IPSec см. главу 9 «Виртуальные частные сети» в этой книге.
Настройка фильтрации пакетов в свойствах интерфейса соединения по требованию Фильтры IP- и IPX-пакетов на интерфейсе соединения по требованию можно использовать для ограничения видов трафика, принимаемого и передаваемого интерфейсом. Фильтрация IP- и IPX-пакетов осуществляется, только когда интерфейс соединения по требованию находится в подключенном состоянии. Фильтрация пакетов особенно полезна в экстрасети — части Вашей интрасети, доступной Вашим бизнес-партнерам через соединения, устанавливаемые по требованию. Например, когда бизнес-партнер устанавливает соединение по требованию, фильтры пакетов на соответствующем интерфейсе пропускают лишь ТСР/1Р-трафик, адресованный в определенные сетевые сегменты или направляемый конкретным сетевым ресурсам.
194
ЧАСТЬ 1
Маршрутизация
Настройка фильтрации пакетов в профиле политики удаленного доступа В дополнение к фильтрам пакетов на интерфейсах соединений по требованию Вы можете настроить фильтры TCP/IP-пакетов в профиле политики удаленного доступа на вызывающих маршрутизаторах. Хотя основное предназначение фильтров TCP/IP-пакетов — ограничивать трафик, передаваемый по соединениям удаленного доступа, эти фильтры можно использовать и при маршрутизации с соединением по требованию. Если на множестве интерфейсов соединений по требованию применяются одинаковые фильтры и политики удаленного доступа, то - вместо того чтобы настраивать одни и те же фильтры IP-пакетов для каждого интерфейса по отдельности — Вы создаете нужный набор фильтров а профиле политики удаленного доступа, и он действует на все соединения, устанавливаемые по требованию.
Создание учетных записей пользователей с помощью Demand-Dial Wizard Когда Вы создаете в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) интерфейс соединения по требованию с помощью Demand-Dial Wizard (Мастер интерфейса вызова по требованию), активизация флажка Add a user account so a remote router can dial in (Добавить учетную запись для входящих звонков удаленного маршрутизатора) на странице Protocols and Security (Протоколы и безопасность) окна этого мастера позволяет создать новую учетную запись, которая будет использоваться вызывающим маршрутизатором. При этом пользовательская учетная запись создается с тем же именем, что и новый интерфейс соединения по требованию; она помещается в-базу данных учетных записей, используемую Вашим маршрутизатором. В таблице 6-2 перечислены места, в которых создается эта учетная запись. Таблица 6-2. Места создания учетных записей мастером интерфейса вызова по требованию Маршрутизатор
Место создания учетной записи
Автономный (stand-alone)
Локальная учетная запись, создаваемая как будто через оснастку Local Users and Groups (Локальные пользователи н группы) Доменная учетная запись, создаваемая как будто через оснастку Active Directory Users and Groups (Active Directory - пользователи и группы) Локальная учетная запись, создаваемая как будто через оснастку Local Users and Groups
Контроллер домена Участник домена
В любом случае разрешение на удаленный доступ устанавливается как Allow access (Разрешить доступ) — даже несмотря на то что по умолчанию для новой учетной записи, которая создается в домене Windows 2000 основного режима или на автономном маршрутизаторе, выбирается вариант Control access through Remote Access Policy (Управление на основе политики удаленного доступа). Такое поведение мастера может привести к некоторой путанице, если Вы управляете доступом па основе модели административной политики. В этой модели разрешение на удаленный доступ во всех учетных записях по умолчанию устанавливается как Control access through Remote Access Policy, а в политиках удаленного доступа,
ГЛАВА 6
Маршрутизация с соединением по требованию
195
применяемых к индивидуальным пользователям, Вы указываете либо Grant remote access (Предоставить право удаленной» доступа), либо Deny remote access (Отказать в праве удаленного доступа). Учетная запись создается с текущими параметрами паролей по умолчанию и политиками, действующими в Вашем домене. Убедитесь, что в каждой учетной записи, используемой вызывающими маршрутизаторами: • флажок User must change password at next logon (Потребовать смену пароля при следующем входе в систему) сброшен. В ином случае вручную сбросьте :»тот флажок в учетных записях, созданных мастером интерфейса вызова по требованию. Если Вы этого не сделаете, маршрутизатор с соединением по требованию не сможет подключаться под этой учетной записью. Когда вызывающий маршрутизатор приступит к передаче своих удостоверений, появится приглашение сменить пароль. А поскольку инициация соединения по требованию — неинтерактивный процесс, в котором пользователь не участвует, вызывающий маршрутизатор не сможет сменить пароль, и попытка соединения завершится неудачей; • флажок Password never expires (Срок действия пароля не ограничен) установлен. Процесс установления соединения по требованию проходит без участия пользователя. Если срок действия пароля истечет, на вызывающем маршрутизаторе появится приглашение сменить пароль, и попытка соединения заверн. ится неудачей.
Блокировка соединений по требованию Хотя маршрутизация с соединением по требованию — более экономичное решение, чем выделенный WAN-канал, каждое подключение, устанавливаемое маршрутизатором с соединением по требованию, отнюдь не бесплатно. Так, стоимость соединений по коммутируемым аналоговым линиям зависит от времени их использования и дальности вызова. А в случае ISDN-линий с Вас могут взимать еще и плату за каждый вызов. Чтобы свести к минимуму затраты на соединения, устанавливаемые по требованию, маршрутизатор Windows 2000 позволяет создавать фильтры вызовов но требованию (demand-dial filters) и расписание исходящих вызовов (dial-out hours).
Фильтры вызовов по требованию Такие фильтры позволяют указать, для каких типов TCP/IP-трафика можно инициировать соединения. Например, если Бы хотите, чтобы инициация соединений по требованию была возможна только при появлении трафика, связанного с Web, настройте фильтры вызовов но требованию, разрешающие инициировать соединение лишь для трафика, адресованного TCP-порту 80. Фильтры вызовов по требованию годятся только для тех интерфейсов соединений по требованию, которые находятся в отключенном состоянии. ^ Чтобы установить фильтры вызовов для интерфейса соединения по требованию: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) выберите панку Routing Interfaces (Интерфейсы маршрутизации) и щелкните правой кнопкой мыши нужный интерфейс соединения по требованию.
196
ЧАСТЬ 1
Маршрутизация
2.
Выберите команду Set IP Demand-Dial Filters (Установить IP-фильтры вызова но требованию). 3. Щелкните кнопку Add (Добавить), настройте параметры фильтра и щелкните кнопку ОК. Л. Выберите нужное действие фильтра, щелкнув либо Only for the following traffic (Только для перечисленных потоков данных), чтобы разрешить инициацию соединения при наличии трафика, удовлетворяющего критериям фильтров, либо For all traffic except (Для всех потоков данных, кроме перечисленных), чтобы запретить инициацию соединения при наличии трафика, удовлетворяющего критериям фильтров. Примечание Фильтры вызовов по требованию отличаются от фильтров IP-пакетов. Первые определяют, какой трафик может инициировать соединение по требованию, а вторые — какой трафик может приниматься и передаваться через интерфейс соединения по требованию (после его подключения). Таким образом, фильтры IP-пакетов применяются уже после установления соединения. Поэтому при наличии выходных фильтров IP-пакетов, запрещающих передачу какого-либо ТСР/ТР-трафика через интерфейс соединения по требованию, рекомендуется сконфигурировать эти же фильтры и как фильтры вызовов. Тогда для трафика, который отбрасывается выходными фильтрами IP-пакетов, соединение по требованию просто не устанавливается.
Расписание исходящих вызовов Такое расписание позволяет указывать, в какое время суток и в какие дни недели соединение по требованию разрешается или запрещается. Например, если данный интерфейс соединения по требованию предназначен для резервного копирования данных в будние дни с 00:00 до 4:00, тогда Вы настраиваете расписание так, чтобы оно разрешало соединения по этому интерфейсу только в будни и только в эти часы. ^
Чтобы настроить расписание исходящих вызовов для интерфейса соединения по требованию:
1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) выберите папку Routing Interfaces (Интерфейсы маршрутизации) и щелкните правой кнопкой мыши нужный интерфейс соединения по требованию. 2. Выберите команду Dial-out Hours (Расписание исходящих вызовов). 3. В диалоговом окне Dial-out Hours (Расписание исходящих вызовов) выберите дни недели и часы работы, в которые соединение либо разрешается, либо запрещается, и щелкните кнопку ОК. По умолчанию соединения разрешены в любое время и любые дни. Когда наступает время, в течение которого соединения по требованию запрещены, интерфейс соединения по требованию, находящийся в подключенном состоянии, автоматически не отключается. Расписание исходящих вызовов действует только на интерфейсы соединений по требованию, находящиеся в отключенном состоянии.
ГЛАВА б
Маршрутизация с соединением по требованию
197
Маршрутизация с соединением по требованию и протоколы маршрутизации Метол обновления таблиц маршрутизации на маршрутизаторах с поддержкою соединений но требованию зависит от типа подключения: для подключений, устанавливаемых по требованию, используйте статическую маршрутизацию, а для постоянных подключений — динамическую (на основе протоколов маршрутизации),
Подключения, устанавливаемые по требованию Применение статической маршрутизации для соединений на основе подключений, устанавливаемых по требованию, рекомендуется потому, что протоколы маршрутизации, поставляемые со службой маршрутизации и удаленного доступа в Windows 2000 (RIP for IP, OSPF, RIP for IPX, SAP for IPX), периодически генерирую! оповещения, которые заставят либо устанавливать соединение при каждом оповещении, либо постоянно поддерживать его, если интервал оповещения меньше времени простоя до разъединения. Поскольку плата за пользование коммутируемыми WAN-каналами, как правило, зависит от времени и дальности вызовов, работать с протоколами маршрутизации на подключениях, устанавливаемых по требованию, нежелательно. Статические маршруты, применяемые при маршрутизации с с'оединением по требованию, конфигурируются либо вручную, либо автоматически — с использованием автостатических обновлений (см. раздел «Автостатические обновления» далее в этой главе).
Создание статических маршрутов вручную Эта операция заключается в том. что Вы создаете с помощью оснастки Routing ,md Remote Access статические маршруты, доступные через интерфейс соединения по требованию. Для TCP/IP-трафика нужно создать статические IP-маршруты. ^ Чтобы добавить статический IP-маршрут, использующий интерфейс соединения по требованию: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IP Routing (IP-маршрутизация) и щелкните правой кнопкой мыши папку Static routes (Статические маршруты). 2. Выберите команду New Static Route (Новый статический маршрут). 3. В списке Interface (Интерфейс) выберите нужный интерфейс соединения по требованию, 4. Введите подходящие значения в поля Destination (Назначение), Network mask (Маска подсети) и Metric (Метрика). 5. Если Вы не хотите, чтобы трафик, передаваемый по этому статическому маршруту, заставлял интерфейс инициировать подключение по требованию, сбросьте флажок Use this route to initiate demand-dial connections (Использовать этот маршрут для подключений по требованию).
198
ЧАСТЬ 1
Маршрутизация
Примечание При выборе интерфейса соединения по требованию поле Gateway (Шлюз) становится недоступным. Через такой интерфейс создается соединение типа «точка-точка», и пересылочный IP-адрес, указываемый в поле Gateway, для пересылки IP-трафика не требуется. Для IPX-трафика следует добавить статические IPX-маршруты и статические службы SAP. Использование IP-маршрута по умолчанию для подключения, устанавливаемого по требованию Будьте осторожны при использовании IP-маршрута по умолчанию (0.0.0.0/0). Хотя он упрощает настройку статической маршрутизации через подключения, устанавливаемые по требованию, Вы должны тщательно взвесить все последствия его применения. IP-маршрут по умолчанию обеспечивает эффективное суммирование всех IP-адресов назначения и используется для пересылки IP-пакетов в отсутствие других, более специфических маршрутов. Использование маршрута по умолчанию подразумевает, что все адреса назначения находятся в направлении этою маршрута. При подключении к Интернету через интерфейс соединения по требованию это допущение справедливо. Но, если Вы используете этот интерфейс для подключения филиала к центральному офису в рамках частной интрасети, применение маршрута по умолчанию может создать проблему. Если IP-маршрут но умолчанию настроен па интерфейс соединения по требованию, то подключение по требованию может быть инициировано для такого 1Р-трафика, адресат которого на самом деле недостижим. Например, если какая-либо организация использует частную IP-сеть 10.0.0.0/8, а филиал — 10.1.1.0/24, статическая маршрутизация может быть сконфигурирована на маршрутизаторе филиала следующими способамтт. •
Определен статический маршрут к сети 10.0.0.0/8 с использованием интерфейса соединения по требованию. Если кто-нибудь в филиале попытается передать данные на IP-адрес назначения 192.168.0.1, маршрутизатор филиала не найдет подходящего маршрута в своей таблице маршрутизации. В результате пакет будет отброшен и хост-отправитель получит ICMP-сообщение Destination Unreachable/Host Unrcachable. • Определен статический маршрут 0.0.0.0/0 с использованием интерфейса соединения по требованию. Если кто-нибудь в филиале попытается передать данные на IP-адрес назначения 192.168.0.1. маршрутизатор филиала инициирует соединение и перешлет через него пакет маршрутизатору центрального офиса. Однако ни на маршрутизаторе центрального офиса, пи на каком-либо другом маршрутизаторе в корпоративной интрасети нет подходящего маршрута для данного пакета. В результате пакет будет отброшен и хост-отправитель получит ICMP-сообщение Destination Unreachable/Host Unreachable. Таким образом, использование маршрута по умолчанию в интрасети филиала может принести к нежелательным результатам при генерации трафика к недостижимому адресату.
ГЛАВА б Маршрутизация с соединением по требованию
199
Автостатические обновления Хотя создание небольшого числа статических маршрутов вручную в некоторых случаях вполне оправданно, при наличии множества маршрутов или при их частом изменении настройка вручную неприемлема. Для автоматического добавления маршрутов и служб в таблицы маршрутизации служба маршрутизации и удаленного доступа поддерживает автостатические обновления через интерфейсы соединений по требованию. При автоматическом обновлении (autostatic update) от маршрутизатора на другой стороне соединения запрашиваются вес известные маршруты или службы, которые затем вносятся в таблицы маршрутизации запрашивающего маршрутизатора. Автостатическое обновление — это разовая односторонняя передача информации о маршрутах. После того как информация о маршрутах передана, маршрутизаторы на обеих сторонах соединения больше не объявляют ее, даже если соединение1 не разрывается, Примечание Термин «автостатический» подразумевает автоматическое добавление маршрутов в таблицу маршрутизации как статических. Но само автостатическое обновление не осуществляется автоматически при создании соединения по требованию. Чтобы задействовать автостатические обновления для IP-маршрутов, добавьте интерфейс соединения по требованию к протоколу маршрутизации RIP. По умолчанию интерфейсы соединений по требованию функционируют для RIP в режиме Autostatic update mode (Режим автостатического обновления), а в качестве протокола исходящих пакетов выбирается RIP version 2 multicast (Для RIP версии 2, многоадресная). Эти настройки по умолчанию рассчитаны на установление соединения с другим маршрутизатором Windows 2000. Если же Вы хотите использовать автостатические обновления для IPX-маршрутов и SAP-служб, добавьте интерфейс соединения по требованию к протоколам маршрутизации RIP for IPX и SAP for IPX. По умолчанию интерфейсы соединений по требованию функционируют для RIP for IPX и SAP for IPX в режиме No update (Без обновлений). В обоих случаях Вы должны сменить его на Autostatic (Автостатический), ^ Чтобы изменить режим обновления: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IPX Routing (IPX-маршрутизация). 2. В случае RIP for IPX укажите RIP for IPX (RIP для IPX), щелкните правой кнопкой мыши нужный интерфейс соединения по требованию и выберите команду Properties (Свойства). В разделе Update mode (Режим обновления) в ,iберите переключатель Autostatic (Автостатический) и щелкните кнопку ОК. 3. В случае SAP for IPX укажите SAP for IPX (SAP для IPX) и проделайте те же операции, что и в п. 2.
200
ЧАСТЬ 1
Маршрутизация
Примечание Перед передачей запроса автостатического обновления существующие маршруты, полученные в результате предыдущего антистатического обновления, удаляются. Если ответ на запрос не приходит, маршрутизатор не восстанавливает удаленные маршруты. Это может вызвать проблемы с подключением к удаленным сетям. Автостатические обновления вручную Статические IP-маршруты обновляются вручную по следующей процедуре. I* Чтобы вручную выполнить автостатическое обновление для IP: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IP Routing (IP-маршрутизация) и выберите папку General (Общие). 2. Щелкните правой кнопкой мыши нужный интерфейс соединения по требованию и выберите команду Update Routes (Обновить маршруты). Если интерфейс соединения по требованию находится в отключенном состоянии, производится автоматическое подключение. После этого начинается автостатическое обновление. При автостатическом обновлении информация о маршрутах передается только от отвечающего маршрутизатора вызывающему. Чтобы передать аналогичную информацию от вызывающего маршрутизатора отвечающему, Вы должны выполнить ту же процедуру на отвечающем маршрутизаторе. Информация об IP-маршрутах передается но протоколу RIP for IP. Маршрутизатор, на котором инициируется обновление, посылает общий RIP-запрос (General RIP Request), а маршрутизатор на другой стороне соединения отвечает сообщением RIP Response, в которое включает все подходящие маршруты из своей таблицы IP-маршрутизации. RIP-маршруты, принятые запрашивающим маршрутизатором, автоматически добавляются в его таблицу IP-маршрутизации как статические. Подробнее о RIP-сообщениях см. главу 3 «Одноадресная IP-маршрутизация» в этой книге. Для обновления статических IPX-маршрутов и SAP-служб вручную действуйте по следующей процедуре. ^ Чтобы вручную выполнить автостатическое обновление для IPX и SAP: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IPX Routing (IPX-маршрутизация) и выберите папку General (Общие). 2. Щелкните правой кнопкой мыши нужный интерфейс соединения по требованию и выберите команду Update Routes (Обновить маршруты). Как и в случае автостатического обновления для IP, если интерфейс соединения но требованию находится в отключенном состоянии, производится автоматическое подключение. После этого начинается автостатическое обновление. При автостатическом обновлении информация о маршрутах и службах перелается только от отвечающего маршрутизатора вызывающему. Чтобы передать аналогичную информацию от вызывающего маршрутизатора отвечающему. Вы должны выполнить ту же процедуру на отвечающем маршрутизаторе. Информация об IPX-маршрутах передается по протоколу RIP for IPX. Маршрутизатор, на котором инициируется обновление, посылает общий RIP-запрос, а марш-
ГЛАВА 6
Маршрутизация с соединением по требованию
201
рутизатор на другой стороне соединения отвечает сообщением RIP Response, n которое включает все подходящие маршруты из своей таблицы IPX-маршрутизации. Маршруты RIP tor IPX, принятые запрашивающим маршрутизатором, автоматически добавляются в сто таблицу 1РХ'Мар1нрутшаиии как статические. IIo/ipo6?iec о сообщениях RIP tor IPX см. главу 5 «IPX-маршрутизация» в этой книге. Информация о SAP-службах передается но протоколу SAP for IPX. Маршрутизатор, на котором инициируется обновление, посылает общий SAP-запрос (SAP General Request), а маршрутизатор на другой стороне соединения отвечает сообщением SAP Response, в которое включает вес подходящие службы из своей таблицы SAP-служб. SAP-службы, информация о которых принята запрашивающим маршрутизатором, автоматически добавляются в его таблицу SAP-служб как статические. Подробнее о сообщениях SAP см. главу 5 «IPX-маршрутизация» в этой книге. Автостатические обновления по расписанию Автостатические обновления можно проводить периодически — по расписанию. Для этого нужно использовать командный файл иди файл сценария netsh в комбинации с программой Scheduled Tasks (Назначенные задания). Для автостатического обновления с применением RIP for IP и сценария выполняются следующие команды netsh: netsh interface set interface пате=<имя интерфейса соединения по требований
connect=CQNNECTED netsh routing ip rip update <имя интерфейса соединения по требованию? netsh interface set interface пате=<имй интерфейса соединения по требования»
Connect=DISCONNECTED Например, чтобы обновить IP-маршруты, использующие интерфейс соединения но требованию СогрНиЬ; netsfi interface set interface name=CorpHub connect=CONNECTED rietsfi routing ip rip update CorpHub netsh interface set interface name=CorpHub connect=DISCONNECTED
Команды netsh можно выполнять в командном файле Windows 2000 или поместить в файл сценария netsh. Так, ниже показан текст файла сценария Corphub.scp для ранс-е приведенных команд. interface set interface name=CorpHub connect=CONNECTED routing ip rip update CorpHub interface set interface name=CorpHuti connect=DISCONNECTED
Для выполнения этого файла сценария введите в командной строке: netsh -f corphub.scp Создав командный файл Windows 2000 или файл сценария netsh. Вы можете указать его периодический запуск в Scheduled Tasks.
Постоянные подключения В случае соединений по требованию на основе постоянных подключений (persistent demand-dial connections) протоколы маршрутизации могут функционировать точно так же, как и при использовании LAN-интерфейсов, обеспечивая динамические обновление таблиц маршрутизации. Специальную настройку протоколов маршрутизации для интерфейсов соединений по требованию с постоянным подключением иллюстрирует таблица 6-3.
202
ЧАСТЬ 1
Маршрутизация
Таблица 6-3. Изменения в исходной конфигурации протоколов маршрутизации для интерфейсов соединений по требованию Протокол маршрутизации Изменение в исходной конфигурации RIP for IP
OSPF
RIP for IPX SAP for IPX
Измените режим работы с предлагаемого по умолчанию на Periodic update mode (Режим периодического обновления) и разрешите использование инициируемых обновлений (triggered updates). На вкладке General (Общие) окна свойств OSPF-интсрфейса выберите тип сети Point-to-point (Точка-точка). Этот тип сети для интерфейсов соединений по требованию предлагается по умолчанию. Для постоянного VPN-соединения между маршрутизаторами Вам, возможно, понадобится увеличить значения параметров Transit Delay (Задержка транзита), Retransmit Interval (Интервал повтора передачи), Hello Interval (Интервал приветствия) и Dead Interval (Интервал исчезновения) на вкладке Advanced (Дополнительно) окна свойств OSPF-интерфейса, чтобы учесть задержку в пересылке OSPF-пакстов через Интернет. Измените режим обновления на Standard (Обычный). Измените режим обновления на Standard.
Во всех случаях протоколы маршрутизации, предоставляемые службой маршрутизации и удаленного доступа Windows 2000, должны работать через нумерованное соединение (numbered connection). В процессе установления РРР-соединения нумерованному соединению присваивается IP- или IPX-адрес. Служба маршрутизации и удаленного доступа поддерживает и ненумерованные соединения, но протоколы маршрутизации с ними не работают. Ненумерованные соединения обычно используются при установлении связи с Интернет-провайдером, предпочитающим не расходовать IP-адреса на соединения типа «точка-точка». Интернет-соединение может быть ненумерованным, потому что Вы, как правило, настраиваете статический IP-маршрут по умолчанию, не используя какой-либо протокол маршрутизации.
Использование Multilink и ВАР При маршрутизации с соединением по требованию Multilink и ВАР (Bandwidth Allocation Protocol) позволяют автоматически добавлять физические соединения к многоканальному РРР-соединению, когда интенсивность сетевого трафика увеличивается, и удалять их, когда интенсивность сетевого трафика уменьшается. ^ Чтобы создать многоканальное или ВАР-соединение по требованию: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел Routing Interfaces (Интерфейсы маршрутизации). 2.
Щелкните правой кнопкой мыши Routing Interfaces и выберите команду New Demand-dial interface (Создать новый интерфейс вызова по требованию).
3. Когда запустится Demand-Dial Wizard (Мастер интерфейса вызова по требованию), выберите модем, который Вы хотите использовать для первого физического соединения. 4. Щелкните правой кнопкой мыши созданный интерфейс соединения по требованию и выберите команду Properties (Свойства).
ГЛАВА 6 5.
Маршрутизация с соединением по требованию
203
На вкладке General (Общие) в списке Connect using (Подключить через) выберите модемы или порты, которые Вы хотите задействовать для соединения, причем в том порядке, в каком Вы будете ими пользоваться. Если для каждого физического соединения набирается свой телефонный номер, сбросьте флажок АН devices call the same numbers,
6. На вкладке Options (Параметры) в разделе Multiple devices (Использование нескольких устройств) щелкните Dial devices only as needed (Лишь необходимые устройства). 7. Щелкните кнопку Configure (Настроить), и на экране появится диалоговое окно Automatic Dialing and Automatic Hanging Up (рис. 6-3). В разделе Automatic dialing (Автоматическое подключение) укажите условия, при которых должно устанавливаться новое подключение через дополнительное устройство (канал). По умолчанию — через 2 минуты после того, как нагрузка на существующее многоканальное соединение достигнет верхнего порогового значения в 75% его пропускной способности. В разделе Automatic hangup (Автоматический разрыв соединения) укажите условия, при которых следует отключать дополнительное устройство (канал), По умолчанию — через 2 минуты после того, как нагрузка на существующее многоканальное соединение достигнет нижнего порогового значения л 10% его пропускной способности.
Automatic hangup--- Hang up any device used for Фк cortwdaon i"Aer> it rrteste bolh if ihe
Рис. 6-3. Диалоговое окно Automatic Dialing and Automatic Hanging Up Примечание Если связь по одному из каналов многоканального подключения разрывается, а протокол ВАР не используется, то связь автоматически не восстанавливается. Для автоматического восстановления каналов связи многоканального подключения используйте ВАР и настраивайте свои каналы на инициализацию при создании соединения по требованию и повторную инициализацию при разрыве свя-
204
ЧАСТЬ 1
Маршрутизация
зи. Например, задайте следующие условия автоматического подключения, присвоив параметру Activity at least (Активно tie менее) значение 1%, а параметру Duration at least (Продолжительность не менее) — значение 3 секунды.
IPX-соединения по требованию При установлении IPX-соединений по требованию параметры IPX согласуются одним из двух способов — в зависимости от того, какой управляющий протокол IPX Бы используете. •
IPX CP (IPX Control Protocol). Это протокол LCP (Link Control Protocol) для согласования.параметров IPX-соединений на основе РРР, документированный в RFC 1552. IPXCP применяется по умолчанию. Подробнее об IPXCP см. главу 7 «Сервер удаленного доступа» в этой книге.
•
IPX WAN. Это управляющий протокол, используемый Novell NetWare, а также совместимыми серверами удаленного доступа и маршрутизаторами. Вы должны переключаться на IPX WAN при вызове сервера или маршрутизатора, работающего под управлением Novell NetWare, и других маршрутизаторов, поддерживающих управляющий протокол IPX WAN.
^ Чтобы сменить управляющий протокол IPX на каком-либо интерфейсе соединения по требованию: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) раскройте узел IPX Routing (IPX-маршрутизация) и щелкните папку General (Общие). 2. Щелкните правой кнопкой мыши нужный интерфейс соединения по требованию. ?>. Выберите переключатель либо IPX CP (IPX CP), либо IPX WAN (IPX WAN), a затем щелкните кнопку ОК. Протокол NCP Watchdog Клиенты Novell NetWare получают доступ к файлам на серверах Novell NetWare no протоколу NCP (NetWare Core Protocol). NCP — это падежный, ориентированный па логические соединения протокол, который обеспечивает доступ к файлам и принтерам в сетях NetWare. Как только NCP-соединение установлено, оно поддерживается с помощью NCP Watchdog - простого протокола, по которому сервер NetWare проверяет, присутствует ли еще клиент NetWare и делает ли он что-нибудь через данное NCP-соединение. Пакет NCP Watchdog представляет собой сообщение, посылаемое клиенту NetWare внутренним адаптером сервера NetWare и состоящее из номера NCP-соединения и сигнатуры (ОхЗР). Если клиент еще проявляет какую-то активность на соединении, оп возвращает номер соединения и сигнатуру серверу NetWare. По умолчанию, сели клиент не посылает данные по NCP-соединению в течение 4 минут и 56,6 секунд, сервер NetWare передает пакет NCP Watchdog. Если ответ на пего не приходит, сервер NetWare посылает еще 10 таких пакетов с интервалом в 59,3 секунды. (Все эти параметры настраиваются на сервере NetWare. Более подробную информацию см. в документации на сервер NetWare.)
ГЛАВА б
Маршрутизация с соединением по требованию
205
Протокол NCP Watchdog оставляет открытым подключение по требованию, лаже если клиент или сервер не посылают никаких данных по NCP-соединению. Чтобы блокировать такое поведение NCP Watchdog, служба маршрутизации и удаленного доступа Windows 2000 имитирует ответы на пакеты NCP Waichdog за удаленных клиентов NetWare, находящихся на другой стороне подключения по требопап по. Если маршрутизатор с соединением по требованию принимает пакет NCP Watchdog, который передан сервером NetWare клиенту NetWare, достижимому по маршруту через интерфейс соединения по требованию, он отвечает на этот пакет за клиента NetWare. За счет этого пакеты NCP Watchdog не мешают закрытию простаивающего подключения по требованию. Однако NCP-соединение не закрывается после разрыва подключения, установленного по требованию, — оно имитируется маршрутизатором Windows 2000. По истечении заданного времени простоя подключение, установленное по требованию, закрывается, ко служба маршрутизации и удаленного доступа Windows 2000 продолжает имитировать ответы на пакеты NCP Watchdog. Когда какой-нибудь сервер или клиент NetWare передаст данные по JTOму NCP-соединению, маршрутизатор восстановит подключение и перешлет данные адресату.
Выявление и устранение проблем Наиболее распространенные проблемы маршрутизации с соединением по требованию: • соединение по требованию автоматически не устанавливается; • соединение по требованию вообще не удается установить; • адреса за вызывающим или отвечающим маршрутизатором недостижимы; • автостатическое обновление не работает. В следующих разделах даются рекомендации, которые помогут Вам выявить он ибки в конфигурации или инфраструктуре, которые вызывают проблемы с мари рутизацией, использующей соединения по требованию. Соединение по требованию автоматически не устанавливается •
Проверьте наличие требуемых статических маршрутов и убедитесь, что они настроены на нужный интерфейс соединения по требованию, • Б параметрах статических маршрутов, использующих интерфейс соединения по требованию, убедитесь, что флажок Use this route to initiate demand-dial connections (Использовать этот маршрут для подключений по требованию) установлен. • Проверьте, не запрещен ли интерфейс соединения по требованию. Если да, толкните этот интерфейс правой кнопкой мыши и выберите команду Enable (Разрешить). •
Убедитесь, что расписание исходящих вызовов для данного интерфейса соединения по требованию на вызывающем маршрутизаторе не блокирует попытки подключения. • Убедитесь, что фильтры вызовов по требованию для данного интерфейса соединения по требованию не блокируют попытки подключения,
206
ЧАСТЬ 1
Маршрутизация
Соединение по требованию вообще не удается установить •
Убедитесь, что служба маршрутизации и удаленного доступа работает как на вызывающем, так и на отвечающем маршрутизаторе.
•
Убедитесь, что на вызывающем и отвечающем маршрутизаторах разрешена как локальная, так и удаленная пересылка (LAN и WAN).
•
Проверьте, настроены ли порты удаленного доступа по коммутируемым линиям, используемые вызывающим и отвечающим маршрутизаторами, на поддержку маршрутизации с соединением по требованию. • Проверьте, не задействованы ли уже все порты удаленного доступа по коммутируемым линиям на вызывающем и отвечающем маршрутизаторах. • При использовании политики удаленного доступа убедитесь, что вызывающий и отвечающий маршрутизаторы могут применять хотя бы один общий метод аутентификации и/или шифрования. •
Проверьте в удостоверениях вызывающего маршрутизатора правильность имени и пароля пользователя, а также имени домена и убедитесь, что они могут быть проверены отвечающим маршрутизатором.
•
В случае соединений по требованию, для которых используется MS-CHAP vl и осуществляется попытка договориться о шифровании по методу МРРЕ с 40битным ключом, убедитесь, что длина пароля не превышает 14 символов.
•
Убедитесь, что пользовательская учетная запись вызывающего маршрутизатора не отключена или не заблокирована (в свойствах этой записи). Если срок действия пароля для данной учетной записи истек, убедитесь, что клиент удаленного доступа использует MS-CHAP vl или MS-CHAP v2. (MS-CHAP vl/v2 единственный протокол аутентификации в Windows 2000, который позволяет сменить просроченный пароль в процессе установления соединения.)
Если истек срок действия пароля в учетной записи уровня администратора, переустановите пароль, используя учетную запись другого администратора. • Убедитесь, что пользовательская учетная запись вызывающего маршрутизатора не была заблокирована из-за блокировки учетной записи, предназначенной для удаленного доступа (см. главу 7 «Сервер удаленного доступа* в этой книге). • Убедитесь, что параметры на вкладке General (Общие) окна свойств пользовательской учетной записи вызывающего маршрутизатора настроены так, чтобы при следующей попытке входа в систему смена пароля не требовалась и срок действия пароля не был ограничен. • Убедитесь, что параметры запроса на соединение согласуются с параметрами входящих звонков в пользовательской учетной записи вызывающего маршрутизатора и в политике удаленного доступа. Если отвечающий маршрутизатор настроен на аутентификацию через Windows, значит, используется политика удаленного доступа, хранящаяся на атом маршрутизаторе. Если же он настроен на аутентификацию через RADIUS и если сервер RADIUS представляет собой компьютер с Windows 2000 и службой проверки подлинности в Интернете (IAS), значит, используется политика удаленного доступа, хранящаяся на IAS-сервере. Для успешного установления соединения параметры в запросе на соединение должны;
ГЛАВА 6
Маршрутизация с соединением по требованию
207
• соответствовать всем условиям по крайней мере одной политики удаленного доступа; • предоставлять право на удаленный доступ либо через Allow access (Разрешить доступ) в пользовательской учетной записи, либо через Control access through Remote Access Policy (Управление на основе политики удаленного доступа) в пользовательской учетной записи и Grant remote access permission (Предоставить право удаленного доступа) в политике удаленного доступа; • соответствовать всем параметрам профиля; • соответствовать всем параметрам входящих звонков в свойствах пользивательской учетной записи. Убедитесь, что настройки в профиле политики удаленного доступа не конфликтуют со свойствами отвечающего маршрутизатора. Профиль политики удаленного доступа и свойства отвечающего маршрутизатора предусматривают настройки для: • многоканальных подключений; • протокола ВАР (Bandwidth Allocation Protocol); • протоколов аутентификации. Если настройки в профиле соответствующей политики удаленного доступа конфликтуют со свойствами отвечающего маршрутизатора, запрос на соединение будет отклонен. Например, если в профиле указан протокол аутентифика щи EAP-TLS, но этот протокол в свойствах отвечающего маршрутизатора не включен, последний будет отклонять запросы на соединение. Если отвечающий маршрутизатор настроен на использование статического пула IP-адресов, проверьте, достаточно ли адресов в пуле. Если все адреса из статического пула уже выделены клиентам удаленного доступа или маршрутизаторам, подключаемым по требованию, то отвечающий маршрутизатор не сможет назначить очередной IP-адрес. Если вызывающий маршрутизатор сконфигурирован только на пересылку IP-пакетов, запрос на соединение будет отклонен. Проверьте конфигурацию службы аутентификации на отвечающем маршрутизаторе. Отвечающий маршрутизатор может быть настроен на аутентификацию удостоверений вызывающего маршрутизатора либо через Windows, либо через RADIUS. В последнем случае проверьте конфигурацию службы RADIUS на отвечающем маршрутизаторе. Если отвечающий маршрутизатор является рядовым сервером в домене Windows 2000, который работает в смешанном или основном режиме и сконфигурирован на аутентификацию через Windows 2000, убедитесь, что: •
в службе каталогов Active Directory имеется группа безопасности RAS iind IAS Servers (Серверы RAS и IAS). Если этой группы нет, создайте ее, указав тип Security (Безопасность) и область действия Domain local (Локальная доменная);
208
ЧАСТЬ 1
Маршрутизация
• у группы безопасности RAS and IAS Servers имеется разрешение па чтение объекта RAS and IAS Servers Access Check; • учетная запись компьютера отвечающего маршрутизатора включена в группу безопасности RAS and IAS Servers. Для просмотра текущих регистрации используйте команду netsh ras show registeredserver, а для регистрации сервера в определенном домене — команду netsh ras add registeredserver. Если Вы добавляете компьютер отвечающего маршрутизатора в группу безопасности RAS and IAS Servers, то скорее всего он не сможет немедленно начать аутентифицировать удостоверения в запросах па входящие соединения (из-за особенностей кэширования аутентификационной информации в Windows 2000). Чтобы отвечающий маршрутизатор немедленно приступил к аутентификации входящих соединений, перезагрузите этот маршрутизатор. Если отвечающий маршрутизатор является членом домена Windows 2000 основного режима, убедитесь, что этот маршрутизатор присоединился к домену. Если отвечающий маршрутизатор под управлением 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 «PreWindows 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 •
Маршрутизация с соединением по требованию
209
При маршрутизации с соединением по требованию на основе сертификатов убедитесь, что на вызывающем маршрутизаторе: • разрешено использование ЕАР в качестве протокола аутентификации; •
правильно выбран сертификат для корневого центра сертификации отвечающего маршрутизатора; • при настройке удостоверений (учетных данных) интерфейса соединения по требованию правильно выбран сертификат маршрутизатора (автономный запрос). • При маршрутизации с соединением по требованию на основе сертификатов убедитесь, что на отвечающем маршрутизаторе: • разрешено использование ЕАР в качестве протокола аутентификации; • правильно выбран машинный сертификат для корневого центра сертификации отвечающего маршрутизатора. Адреса за вызывающим или отвечающим маршрутизатором недостижимы • Б случае соединения по требованию, инициируемого любой из сторон, проверьте, не интерпретируется ли оно как соединение удаленного доступа. Чтобы отвечающий маршрутизатор мог определить, что его вызывает маршрутизатор, а не клиент удаленного доступа, имя пользователя в удостоверениях вызывающего маршрутизатора должно совпадать с именем интерфейса соединения по требованию, сконфигурированного на отвечающем маршрутизаторе. Если вызов поступил от маршрутизатора, порт, через который был принят пьтзов, должен находиться в состоянии Active (Активно), а соответствующий интерфейс соединения по требованию — в состоянии Connected (Подключено). Если имя вызывающего маршрутизатора появилось в папке Remote Access Clients (Клиенты удаленного доступа), значит, отвечающий маршрутизатор воспринимает его в качестве клиента удаленного доступа. В случае соединений, инициируемых любой из сторон, любой маршрутизатор может быть вызывающим или отвечающим. При этом имя пользователя в удостоверениях одного маршрутизатора должно совпадать с именем интерфейса соединения по требованию на другом маршрутизаторе. Например, соединения, инициируемые любой из сторон, могли бы работать в следующей конфигурации. У маршрутизатора 1 имеется интерфейс соединения по требовании» с именем NEW-YORK, который передает в своих удостоверениях имя пользователя SEATTLE, а у маршрутизатора 2 — интерфейс соединения по требованию с именем SEATTLE, который передает в своих удостоверениях имя пользователя NEW-YORK. В этом примере имя пользователя SEATTLE может быть аутентифицировано маршрутизатором 2, а имя пользователя NEW-YORK — маршрутизатором 1. • В случае соединения по требованию, инициируемого только одной из сторон, убедитесь, что в пользовательской учетной записи вызывающего маршрутизатора разрешены соответствующие статические маршруты и что на отвечающем маршрутизаторе работает какой-либо протокол маршрутизации, который после установления соединения объявляет соседним маршрутизаторам статические маршруты из пользовательской учетной записи вызывающего маршрутизат( ipa. 8 Зак. 3343
210
ЧАСТЬ 1
Маршрутизация
• Убедитесь, что на обеих сторонах соединения по требованию имеются маршруты, обеспечивающие двусторонний обмен трафиком. В отличие от соединения удаленного доступа соединение но требованию не приводит к автоматическому созданию 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 2000 регистрирует причину, по которой не удалось установить соединение, в параметре Unreachability reason (Причина недостижимости). Информация, указанная в этом параметре, поможет Вам локализовать источник проблемы. ^ Чтобы просмотреть причину недостижимости: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) щелкните правой кнопкой мыши нужный интерфейс соединения по требованию. 2. Выберите команду Unreachability reason (Причина недостижимости).
ГЛАВА б
Маршрутизация с соединением по требованию
211
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
ЧАСТЬ 1
Маршрутизация
информацию для соединений по требованию и удаленного доступа. Соответствующие журналы ведутся отдельно от системных журналов. Эта информация позволяет отслеживать попытки аутентификации, а также использование соединений по требованию и удаленного доступа. Она особенно полезна при устранении какихлибо проблем с политикой удаленного доступа. Для каждой попытки аутентификации в журнал записывается имя политики удаленного доступа, благодаря которой запрос на соединение был принят или отклонен. Аутентификационная и учетная информация хранится в файле или файлах журнала в папке %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 «Сервер удаленного доступа» в этой книге.
ЧАСТЬ
2
Удаленный доступ
Поддержка удаленного доступа по коммутируемым линиям, виртуальных частных сетей, централизованной аутентификации, авторизации и учета с применением RADIUS позволяет создавать защищенные и масштабируемые решения но удаленному доступу. В этой части подробно рассматриваются технологии удаленного доступа, поддерживаемые службой маршрутизации и удаленного доступа Windows 2000, а также службой проверки подлинности в Интернете (IAS).
В этой части Сервер удаленного доступа
214
Служба проверки подлинности в Интернете Виртуальные частные сети
340
281
ГЛАВА
7
Сервер удаленного доступа
Windows 2000 поддерживает технологии удаленного доступа для подключения удаленных клиентов к корпоративным сетям или Интернету. Здесь поясняется, как работает сервер удаленного доступа и как локализовать причины пройдем, возникающих при удаленном доступе. Эта глава предназначена для сетевых инженеров и специалистов по технической поддержке, уже знакомых с TCP/IP, IP- и IPX-маршрутизацией, а также с технологиями WAN. Кроме того, предполагается, что Вы прочитали раздел по удаленному доступу в справочной системе Windows 2000 Server. В этой главе Обзор 215
Архитектура сервера удаленного доступа РРР 234 РРР-протоколы аутентификации
228
253
Удаленный доступ и настройка TCP/IP и IPX
260
Политика удаленного доступа 265 Multilink и ВАР 268 Сервер удаленного доступа и поддержка групповой IP-рассылки Выявление и устранение проблем 274
271
См. также • О протоколах TCP/IP — главу 1 «Введение в TCP/IP» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». • Об одноадресной IP-маршрутизации — главу 3 «Одноадресная IP-маршрутизация» в этой книге. • •
Об IPX-маршрутизации — главу 5 «IPX-маршрутизация» в этой книге. О маршрутизации с соединением но требованию — главу 6 «Маршрутизация с соединением по требованию» в этой книге.
ГЛАВА 7 Сервер удаленного доступа •
215
О виртуальных частных сетях — главу 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
ЧАСТЬ 2
Удаленный доступ
ра удаленного доступа используется исключительно для поддержки взаимодействия между клиентами удаленного доступа и сетевыми ресурсами.
Компоненты, участвующие в соединении по коммутируемой линии В соединении удаленного доступа по коммутируемой линии участвуют клиент удаленного доступа, сервер удаленного доступа и инфраструктура 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
Сервер удаленного доступа
217
говая телефонная система, рассчитанная на передачу минимальной полосы частот, достаточной для восприятия человеческой речи. Так как PSTN изначально не предназначалась для передачи данных, соединение через PSTN существенно ограничивает скорость передачи битов. Телефонное оборудование состоит из аналоговых модемов, установленных на клиенте и сервере удаленного доступа. В крупных организациях сервер удаленного доступа подключен к модемному пулу, содержащему сотни модемов. При использовании аналоговых модемов на клиенте и сервере удаленного доступа максимально возможная скорость на соединениях через PSTN 33600 бит/с (33,6 Кбит/с). Соединение через PSTN показано на рис. 7-2. Сервер удаленного доступа
Модем Клиент удаленного доступа
PSTN
Интрасеть
Рис. 7-2. Телефонное оборудование и инфраструктура WAN для связи через PSTN Цифровые линии и V.90 Максимальная скорость передачи через PSTN ограничивается полосой пропускания коммутаторов PSTN и отношением «сигнал/шум». Современные телефонные системы являются аналоговыми только на последнем отрезке, соединяющем абонента с АТС. Как только аналоговый сигнал попадает на коммутатор PSTN, он преобразуется в цифровой сигнал. При аналогово-цифровом преобразовании появляется шум, известный как шум квантизации (quantization noise). Если сервер удаленного доступа подключен к АТС через цифровой коммутатор T-Carricr или ISDN, а не через аналоговый PSTN-коммутатор, то при отправке информации от сервера клиенту удаленного доступа аналогово-цифрового преобразования не происходит. Таким образом, на пути к клиенту удаленного доступа шум квантизации отсутствует, что обеспечивает более высокое отношение «сигнал/шум» и более высокую скорость передачи данных. Благодаря этой повой технологии, названной V.90, клиент удаленного доступа передает данные па скорости 33,6 Кбит/с, а принимает — на скорости 56 Кбит/с. Однако па практике максимальная скорость приема данных несколько ниже, например в Северной Америке она не превышает 53 Кбит/с. Чтобы достичь скоростей протокола V.90: •
клиент удаленного доступа должен использовать модем с поддержкой протокола V.90; • сервер удаленного доступа должен использовать цифровой коммутатор V.9D и подключаться к PSTN по цифровой линии типа Т-Саглег или ISDN; • на пути от сервера удаленного доступа к клиенту не должно бытъ никаких аналогово-цифровых преобразований сигнала.
218
ЧАСТЬ 2
Удаленный доступ
Соединение через PSTN но технологии V.90 показано на рис. 7-3. - Линия T-Carrier или ISDN Сервер удаленного доступа
Клиент удаленного доступа
Модем V.90
Интрасеть
Рис. 7-3. Телефонное оборудование и инфраструктура WAN для связи по технологии V.90 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 Х.25 — международный стандарт передачи данных по общедоступным сетям с коммутацией пакетов. В Windows 2000 предусмотрено два варианта поддержки Х.25.
1. Клиент удаленного доступа поддерживает так называемые интеллектуальные платы Х.25 (Х.25 smart cards), напрямую подключаемые к сети Х.25 и исноль-
ГЛАВА 7
Сервер удаленного доступа
219
зующие протокол Х.25 для установления соединений и обмена данными. Кроме того, клиенты удаленного доступа поддерживают непрямое подключение к сети Х.25 через устройство сборки/разборки пакетов (packet assembler/disassembler, PAD) несущей среды Х.25 с применением аналогового модема. 2. Сервер удаленного доступа поддерживает только интеллектуальные платы Х.25. Подробнее о настройке Х.25 и PAD см. справочную систему Windows 2000 Server. Примечание Интеллектуальные платы Х.25 — это адаптеры, которые используют протокол Х.25 и напрямую подключаются к общедоступной сети данных Х.25. Эти платы не имеют ничего общего со смарт-картами, применяемыми для аутентификации (проверки подлинности) и организации защищенного канала связи. Соединение через Х.25 показано на рис. 7-5.
Клиент удаленного доступа
Интеллектуальная плата Х.25
\/ PAD
Х.25
Сервер ^^ удаленного ^т доступа
Интеллектуальная плата Х.25
Интрасеть Рис. 7-5. Телефонное оборудование и инфраструктура WAN для связи через Х.25 ATM поверх ADSL ADSL (Asymmetric Digital Subscriber Line) — новая технология «последней ми; и», предназначенная для малого бизнеса и домашних пользователей. Хотя ADSL обеспечивает более высокую скорость передачи данных по сравнению с PSTN и ISDN, входящие и исходящие соединения неравноценны. Обычно ADSL-соединения от абонента работают на скорости 64 Кбит/с, а к абоненту — на скорости 1,544 Мбит/с. Такая асимметричность оптимальна для обычного использования Интернета, поскольку основная часть пользователей принимает информации гораздо больше, чем передаст. Windows 2000 воспринимает аппаратные средства ADSL либо как Ethernet-интерфейс, либо как интерфейс удаленного доступа по коммутируемой линии. Если ADSL-адаптер распознается как Ethernet-интерфейс, ADSL-соединение работает так же, как Ether net-подключение к Интернету.
220
ЧАСТЬ 2
Удаленный доступ
Если ADSL-адаптер распознается как интерфейс удаленного доступа по коммутируемой линии, то ADSL обеспечивает физическое соединение, а пакеты LAN-протоколов посылаются с использованием ATM (Asynchronous Transfer Mode). Адаптер ATM с портом ADSL устанавливается как па клиенте удаленного доступа, так и на сервере удаленного доступа. Соединение через ATM поверх ADSL показано на рис. 7-6. Клиент удаленного доступа
Адаптер ATM
Сервер ^ удаленного
ADSL
Интрасеть
Рис. 7-6. Телефонное оборудование и инфраструктура WAN для связи через ATM поверх ADSL
Протоколы удаленного доступа Протоколы удаленного доступа управляют установлением соединения и передачей данных по WAN-каналам. Выбор протокола удаленного доступа на клиентском компьютере диктуется тем, какая операционная система и какие LAN-протоколы установлены на клиенте и сервере удаленного доступа. Существует три типа протоколов удаленного доступа, поддерживаемых Windows 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 2000 Протокол удаленного доступа
Клиент удаленного доступа
Сервер удаленного доступа
РРР
X
X
SLIP AsvBEUI
X X
X
ГЛАВА 7
Сервер удаленного доступа
221
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
ЧДСТЬ 2
Удаленный доступ
Шифрование данных при соединениях удаленного доступа основано на применении секретного ключа, известного серверу и клиенту удаленного доступа. Этот общий ключ генерируется в процессе аутентификации пользователя. Шифрование данных возможно при удаленном доступе по коммутируемым линиям с использованием РРР и протоколов аутентификации EAP-TLS или MS-CHAP. Сервер удаленного доступа может требовать обязательного шифрования данных. Если клиент не способен обеспечить шифрование, его запрос на соединение отклоняется. Клиенты и серверы удаленного доступа под управлением Windows 2000, Windows NT 4.0, Windows 98 и Windows 95 поддерживают шифрование по МРРЕ (Microsoft Point-to-Point Encryption Protocol). MPPE использует алгоритм RSA (RivestSharair-Adleman) RC4 и шифровальные ключи длиной 40, 56 или 128 битов. Ключи МРРЕ генерируются в процессе аутентификации пользователя по протоколам MS-CHAP или EAP-TLS.
Ответный вызов Если функция ответного вызова включена, то после проверки пользовательских удостоверений сервер удаленного доступа перезванивает клиенту. Ответный вызов можно настроить так, чтобы сервер звонил клиенту по номеру, указываемому при первом вызове (это удобно мобильным пользователям). Однако эту функцию можно настроить на ответный вызов только по одному номеру, что обеспечивает дополнительную защиту.
Идентификация звонящего Эта функция гарантирует, что входящий вызов поступил с определенного номера. Она настраивается в параметрах входящих звонков в свойствах пользовательской учетной записи. Если номер звонящего не совпадает с заданным, запрос на соединение отклоняется. Применение этой функции возможно лишь при условии, что идентификацию звонящего поддерживают все необходимые компоненты — телефонная линия звонящего, телефонная система, телефонная линия сервера удаленного доступа и драйверы телефонного оборудования. Если учетная запись сконфигурирована на использование идентификации звонящего, но его идентификатор не передается от звонящего в службу маршрутизации и удаленного доступа, запрос на соединение отклоняется. Идентификация звонящего позволяет достичь более высокого уровня защиты сетей, поддерживающих удаленный доступ. Ее недостаток в том, что пользователь может звонить только по одной телефонной линии.
Блокировка учетной записи удаленного доступа Эта функция позволяет указать число неудачных попыток аутентификации по действующей учетной записи перед тем, как пользователю будет отказано в удаленном доступе. Блокировка учетных записей удаленного доступа особенно важна при VPN-соединениях через Интернет. Злоумышленники из Интернета могут попытаться получить доступ в интрасеть организации через VPN-соединение, последовательно присылая удостоверения с правильным именем пользователя и подбирае-
ГЛАВА 7 Сервер удаленного доступа
223
мым паролем. При этом посылаются сотни или тысячи удостоверений, в которые подставляются пароли из списка, основанного на наборе наиболее часто употребляемых слов и выражений. Такая атака называется словарной (dictionary attack). Функция блокировки учетных записей удаленного доступа надежно пресекает попытки словарных атак. Однако она не различает злоумышленника и настоящего пользователя, который пытается войти в сеть, но забыл свой пароль. Такие пользователи обычно пробуют несколько вариантов, пытаясь вспомнить правильный пароль, и — в зависимости от числа попыток и значения параметра MaxDenials — могут нечаянно заблокировать свою учетную запись. При включенной функции блокировки учетных записей удаленного доступа злоумышленник может намеренно блокировать учетные записи, вводя неправильные пароли до тех пор, пока эти записи не заблокируются, и тем самым не давая настоящим пользователям войти в свою сеть. Как администратор сети, Вы должны принять решение о том, как настроить два параметра, регулирующих работу функции блокировки учетных записей удаленного доступа. 1. Число неудачных попыток до блокировки. После каждой неудачной попытки счетчик таких попыток для учетной записи увеличивается на 1. Как только он достигает заданного максимума, дальнейшие попытки соединения игнорируются, Если аутентификация проходит успешно, пока счетчик неудачных попыток не достиг максимального значения, этот счетчик сбрасывается. Иначе говоря, число неудачных попыток не аккумулируется после успешной аутентификации. 2. Частота сброса счетчика неудачных попыток. Во избежание ложного срабатывания функции блокировки из-за ошибок пользователей при вводе паролей Вам следует периодически сбрасывать счетчик неудачных попыток. Функция блокировки учетных записей удаленного доступа настраивается через реестр на том компьютере, который аутентифицирует пользователей. Если сервер удаленного доступа сконфигурирован на аутентификацию через Windows, модификации требует реестр на этом сервере. А если он настроен на аутентификацию через RADIUS и использует Internet Authentication Service (IAS) (Служба проверки подлинности в Интернете), Вы должны внести нужные изменения в реестр на сервере IAS. Для включения функции блокировки учетных записей присвойте параметру MaxDenials в разделе реестра HKEY_LOCAL_MACHINE\System\CurrcntControlSet\ Services\ Remote Access\ Pa rameters\ Account Lockout значение, равное или большее 1. Значение MaxDenials по умолчанию — 0 (функция блокировки учетных записей отключена). Для изменения периодичности сброса счетчика неудачных попыток присвойте параметру ResetTime в разделе реестра HKEY_LOCAL_MACHINE\System\CunentControlSet\Services\RemoteAccess\Parameters\AccountLockout нужное значение в минутах. Значение ResetTime по умолчанию — ОхЬ40 (2880 минут, или 48 часпв).
224
ЧАСТЬ 2
Удаленный доступ
Чтобы вручную разблокировать учетную запись, не дожидаясь автоматического сброса счетчика неудачных попыток, удалите из реестра следующий подраздел, соответствующий имени пользователя по этой учетной записи: 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
Сервер удаленного доступа
225
В 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 2 (Проверка (MS-CHAP v2) [Шифрованная проверка (Microsoft, версия 2, подлинности) MS-CHAP v2>] и Microsoft encrypted authentication (MS-CHAP) [Шифрованная проверка подлинности Microsoft (MS-CHAP)J Доступ на основе политики Административная модель доступа на основе политики разработана для серверов удаленного доступа Windows 2000 — как автономных, так и входящих в домен Windows 2000 основного режима. Для управления удаленным доступом на основе
226
ЧАСТЬ 2
Удаленный доступ
политик укажите разрешение удаленного доступа во всех учетных записях пользователей как 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. Условия политики удаленного доступа для подключения по коммутируемой линии на основе политики Условия
Настройки
NAS-Port-Type Windows-Groups
Выберите все типы, кроме Virtual (VPN) [Virtual (VPN)j DialUpUsers (пример имени группы)
Таблица 7-5. Параметры профиля политики удаленного доступа для подключения по коммутируемой линии на основе политики Вкладка в окне профиля Настройки Authentication Установите флажки Microsoft encrypted authentication version 2 (Проверка (MS-CHAP v2) [Шифрованная проверка (Microsoft, версия 2, подлинности) MS-CHAP v2)j и Microsoft encrypted authentication (MS-CHAP) [Шифрованная проверка подлинности Microsoft (MS-CHAP)]
Управление аутентификацией Сервер удаленного доступа можно настроить на поддержку аутентификации через Windows или RADIUS.
ГЛАВА 7
Сервер удаленного доступа
227
Аутентификация через 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
ЧАСТЬ 2
Удаленный доступ
Управление учетом В качестве службы учета сервер удаленного доступа может использовать 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
Сервер удаленного доступа
229
NDISWAN напрямую. Подробнее о TAPI в \Vindovvs2000 см. главу 15 «Интеграция телефонии и поддержка конференций» в этой книге. ЙД8
TCP/IP
IPX
NetBEUI
AppieTalk
Компоненты удаленного доступа
NDIS
Ndis.sys
Ndiswan.sys Минипорт-драйвер WAN
Рис. 7-7. Архитектура удаленного доступа в Windows 2000 Клиенты удаленного доступа устанавливают соединение вызовом интерфейса HAS, который в свою очередь обращается к ТЛР1 для передачи информации о вызове телефонному оборудованию. После установления физического соединения интерфейс TAPI далее не используется. Компоненты удаленного доступа согласую" параметры соединения (протоколы канального уровня, аутентификации и управления сетью), напрямую взаимодействуя с NDISWAN. Как только соединение удаленного доступа установлено, драйверы протоколов могут взаимодействовать по этому соединению, вызывая стандартные NDIS-функкии, например NdisSend(). При соединениях по коммутируемой линии вызовы NdisSendQ пересылаются NDISWAN, который определяет нужное устройство и тюрт, выполняет сжатие, шифрование и разбиение на кадры для РРР, а затем пересылает готовый кадр миншюрт-драйвсру WAN. Последний пересылает кадр адаптеру удаленного доступа. Все входящие соединения, инициированные клиентами для обращения к сериеру удаленного доступа, представляются одним адаптером — интерфейсом сервера HAS. Для каждого исходящего соединения с клиентом удаленного доступа, инициированного сервером, создается отдельный интерфейс. Для приема вызовов сервер удаленного доступа командует всем минипорт-драйверам WAN уведомлять его об их переходе в состояние подключения (line-up state). При поступлении вызова минипорт-драйвер WAN передает признак перехода в состояние подключения компонентам TAPI через NDISWAN. Компоненты TAPI возвращают описатель вызова драйверу NDISWAN для последующей ссылки на физическое соединение. Затем NDISWAN и компоненты удаленного доступа согласуют остальные параметры соединения удаленного доступа.
IP-, IPX- и AppleTalk-маршрутизатор Установив соединение удаленного доступа, клиент начинает посылать трафик по LAN-протоколам на сервер удаленного доступа или в сети, находящиеся за ;ггим сервером. Если данные адресованы не серверу удаленного доступа, последний дол-
230
ЧАСТЬ 2
Удаленный доступ
жен переслать LAN-трафик в место назначения. Для этого на сервере должны быть включены средства пересылки по используемым маршрутизируемым протоколам, и он должен работать в качестве IP-, IPX- и AppleTalk-маршрутизатора. Пересылка пакетов между LAN-адаптерам и и интерфейсом минипорта WAN требует включения службы маршрутизации и удаленного доступа и ее настройки на поддержку соединений удаленного доступа типа «точка-LAN». Элементы архитектуры сервера удаленного доступа, необходимые для маршрутизации пакетов, иллюстрирует рис. 7-8. (Для упрощения схемы показана только IPмаршрутизация. IPX- и AppIcTalk-маршрутизация осуществляется аналогичным образом.) :
IPX
AppleTalk
TCP/IP
NOIS
1
NQIS-SyS
jNdiswan.sys Ми ни порт -драйвер LAN
1
I
Минипорт-драйвер WAN
1
Рис. 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
Сервер удаленного доступа
231
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
•
ЧДСТЬ 2
Удаленный доступ
Выделение адресов из диапазона вне подсети (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
Сервер удаленного доступа
233
При подключении первого клиента удаленного доступа в таблицу 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
ЧАСТЬ 2
Удаленный доступ
Клиент удаленного доступ»
Сервер удаленного доступа Шлюз NetBIOS
NetBIOS
NetBIOS
1 NetBEUI
|
NetBT
NBIPX
TCP/IP
IPX
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
Сервер удаленного доступа
235
•
Флаг. Устанавливается как Ох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
ЧАСТЬ 2
Удаленный доступ
Таблица 7-fi. РРР-идентификаторы протоколов Протокол
IP AppleTalk IPX Van Jacobsen Compressed TCP/IP Multilink NetBEUI MPPC (Microsoft Point-to-Point Compression Protocol) MPPE (Microsoft Point-to-Point Encryption Protocol)
Идентификатор протокола/сжатое значение
0x0021 / 0 x 2 1 0x0029 / 0x29 Ox()02B / Ох2В Ox002D / Ox2D Ox003D / Ox3D Ox003F/Ox3F OxOOFD / OxFD OxOOFD / OxFD
Если в процессе согласования принят протокол МРРЕ или МРРС, идентификатор протокола устанавливается в OxOOFD. Так как для протоколов МРРЕ и МРРС используется один и тот же идентификатор, обе стороны сеанса должны знать, что содержимое РРР-кадра зашифровано и/или сжато. •
Если принимается только МРРС, идентификатор протокола устанавливается в OxOOFD, а содержимое кадра сжимается.
•
Если принимается только МРРЕ, идентификатор протокола устанавливается в OxOOFD, а содержимое кадра шифруется.
•
Если принимается и МРРС, и МРРЕ, то сжатие всегда предшествует шифрованию. Сжатый РРР-калр, состоящий из поля идентификатора протокола, установленного в OxFD, и сжатых полезных данных, шифруется и инкапсулируется еще одним РРР-заголовком, который включает поле идентификатора протокола, установленное в OxFD, и двухбайтовый МРРЕ-заголовок.
Предотвращение появления символа флага Символ флага создает одну проблему. Что если этот символ (Ох7Е) появится не только в начале и конце РРР-кадра, но и где-то еще? В РРР предусмотрено два способа предотвращения появления символа флага в зависимости от того, где используется РРР -- на асинхронном или синхронном канале. РРР на асинхронных каналах На асинхронных каналах вроде аналоговых телефонных линий появление символа флага в РРР-калре предотвращается заменой символа. Если символ флага (Ох7Е) появляется не только в заголовке, но и в каком-либо другом месте РРР-кадра, отправитель заменяет его последовательностью Ox7D5E. Символ Ox7D известен как Escape-кол РРР. Если в РРР-кадре встречается Escape-код РРР, отправитель заменяет его последовательностью Ox7D5D. Получатель транслирует последовательности Ох7П5Г. обратно в Ох7Е, a Ox7D5D - в 6x7D. Кроме того, коды символов со значениями менее 0x20 могут быть модифицированы, чтобы драйверы последовательных портов не интерпретировали их как управляющие символы. Если в процессе согласования по LCP принята такая модификация, то вместо символов, коды которых меньше 0x20, посылается последователь-
ГЛАВА 7
Сервер удаленного доступа
237
ность Ох7В-[исходный символ с добавлением 6-го бита]. Например, байт 0x01 транслируется в 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
3
5 6 V 8
9 10
Посылается для открытия или сброса РРР-сосдинсния. Configure-Request содержит список параметров LCP, чьи значения изменены по сравнению с предлагаемыми по умолчанию. Configure-Ack Посылается, когда все значения всех параметров LCP последнего полученного пакета Configure-Request распознаны и приняты. Согласование по протоколу LCP считается завершенным, когда обе стороны РРР-соединения отсылают и принимают пакет Configure-Ack. Configure-Nack Посылается, когда все параметры LCP распознаны, но некоторые из их значений не приняты. Пакет Configure-Nack содержит конфликтные параметры и их приемлемые значения. Configure-Reject Посылается, когда параметры LCP не распознаны или не приняты. Пакет Configure-Reject содержит нераспознанные или несогласованные параметры. Terminate- Request Посылается для закрытия РРР-соединения (не обязателен). Terminate-Ac k Посылается в ответ па запрос Terminate-Request. Посылается, если код LCP неизвестен. Сообщение Code-Reject Code-Reject содержит конфликтный LCP-пакет. Protocol-Reject Посылается, когда РРР-калр содержит неизвестный идентификатор протокола. Сообщение Protocol-Reject включает конфликтный LCP-пакет. Пакет Protocol-Reject обычно посылается одной из сторон РРР-соединсния в ответ на РРР NCP для LAN-протокола, не поддерживаемого этой стороной. Echo-Request Посылается для проверки РРР-соединения (не обязателен). Посылается в ответ на запрос Echo-Request. Echo-Reply РРР-сообщения Echo-Request и Echo-Reply не имеют никакого отношения к ICMP-сообщсниям Echo Request и Echo Reply. Discard-Request Посылается для проверки канала в исходящем направлении (не обязателен).
Параметры LCP При использовании LCP-пакетов типа Configure-Request, Configure-Ack, ConfigureNack и 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.
239
(продолжение)
Имя параметра
Тип
Длина Описание
Asynchronous Control Character Map (ACCM) (таблица управляющих символов для асинхронных соединений)
'•'
6
Битовая карта, которая включает (бит установлен) или отключает (бит сброшен) использонание 32 управляющих ASCII-символов (от 0x00 до 0x20) в качестве Escape-кодов при асинхр!>нных соединениях. Escape-коды используются по умолчанию. Для каналов с программным управлением потоком XON/XOFF битовая карта АССМ устанавливается как 0x00000000. 5 Протокол, используемый на этапе аутентификаAuthentication Protocol '.'> (протокол аутентификации) или 6 ции в процессе установления соединения. Стороны соединения Microsoft PPP указывают в этом параметре одно из следующих значенлй: ОхС227 (ЕАР). ОхС22380 (MS-CHAP версии 1), ОхС22381 (MS-CHAP версии 2), ОхС22305 (MD5-CHAP), ОхС027 (SPAP) или ОхС023 (РАР). II Случайное число, выбираемое для того, чтобы Magic Number различать стороны соединения и обнаруживать (волшебный номер) замкнутые на себя линии (looped back lines). '1 Флаг, указывающий, что двухбайтовый Protocol Compression РРР-идентификатор протокола сокращается (сжатие протокола) до одного октета, если он находится в диапазоне OxOOOO-OxOOFF. 2 Флаг, указывающий, что поля адреса (всегда Address and Control Field 8 OxFF) и управления (всегда 0x03) удаляются Compression (сжатие полей из РРР-заголовка. адреса и управления) Callback (ответный вызов) 13, 3 Параметр (размером в один октет), указывав >или щий, как настраивается функция ответного иызоOxOD ва. Для клиентов и серверов удаленного доступа под управлением 32-битных операционных систем Microsoft Windows этот параметр равен 11x06. Это означает, что функция ответного вызова настраивается в процессе согласования по протоколу СВСР (Callback Control Protocol). Флаг Адрес
Управление Идентификатор протокола
Код Идентификатор Длина
Тип Длина Г Данные параметра
FCS Флаг I.7E
Рис. 7-12. Параметры LCP
" Параметры LCP
240
ЧАСТЬ 2
Удаленный доступ
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. Когда одна из сторон РРР-соединения посылает первоначальный запрос ConfigureRequest, в ответ может быть получено одно из следующих сообщений: • С 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. Сторона 1
W
;onfigure-Request: W, X=100. Y = 0 , Z аЛЫЯаГЖНаНЯаЯПяя >1Па11№>№>НМЛЛ&аЯЖЯьЯаЛЯ#ЯЖ&. ; , ;,„;^
Configure-Reject; Z
Configure-Request: W, X=100. Y = 0
Configure-Request: W, X=200, Y = 0 Configure-Ack: W, X=200. Y=0
Рис. 7-13. Пример LCP-согласования
ГЛАВА 7
Сервер удаленного доступа
241
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 на http://windows.microsoft.com/windows2000/rcskit/webresources.
Структура пакетов РРР-идентификатор протокола СВСР — ОхС029. Структура СВСР-пакетов точно повторяет структуру LCP-пакетов, однако используются только Callback-Request (тип 1), Callback-Response (тип 2) и Callback-Ack (тип 3). Во всех СВСР-пакетах раздел данных состоит из одного или более параметров СВСР, а каждый параметр СВСР — из поля типа параметра, поля длины (указывающего общий размер параметра в байтах) и данных, связанных с этим параметром.
Согласуемые параметры Параметры СВСР, согласуемые сторонами соединения Microsoft РРР, перечислены в таблице 7-9. Таблица 7-9. Параметры СВСР Имя параметра
Тип
Длина
Описание
No callback (ответный вызов отключен)
1
2
Указывает, что для данного соединения ответный вызов не используется
9 Зак. 334.1
(см. след, стр.)
242
ЧАСТЬ 2
Таблица 7-9.
Удаленный доступ (продолжение)
Имя параметра
Тип Длина
Callback to a user-specified 2 number (ответный вызов но номеру, заданному пользователем) Callback Lo an administrator3 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 в том виде, в каком он используется сторонами соединения Microsoft РРР, документирован в 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
Сервер удаленного доступа
243
Таблица 7-Ю. Параметры IPCP
Имя параметра
Тип
Длина Описание
IP compression protocol (протокол сжатия для IP) IP address (IP-адрес)
2
4
Протокол сжатия Van Jacobsen TCP
3
6
Primary DNS server address (адрес основного DNS-сервера) Primary NBNS server address (адрес основного NBNS-сервера) Secondary DNS server address (адрес дополнительного DNS -сервера) Secondary NBNS server address (адрес дополнительного NBNS-сервера)
129, 6 или 0x81 130, 1.
IP-адрес, который должен быть назначен клиенту удаленного доступа Адрес основного DNS-сервера для клиента удаленного доступа Адрес основного сервера NBNS (WINS) для клиента удаленного доступа Адрес дополнительного DNS-сервера для клиента удаленного доступа
или 0x82 131.
6
132,
1)
или 0x83 или 0x84
Адрес дополнительного сервера NBNS (WINS) для клиента удаленного доступа
Заметьте, что в протоколе 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 (номер IPX-сети) IPX Node Number (номер IPX-узла)
1
6
;
6
•
Номер IPX-сети для клиента удаленного доступа Номер IPX-узла для клиента удаленного доступа
АТСР Протокол АТСР в том виде, в каком он используется сторонами соединения Microsoft РРР, документирован в RFC 1378. По этому протоколу согласуются параметры AppleTalk для динамической настройки AppleTalk на сторонах соединения типа «точка-точка*. Стандартные параметры АТСР включают AppleTalk-адрес и информацию о сервере. Структура пакетов РРР-идентификатор протокола АТСР — 0x8029. Структура АТСР-пакетов точно повторяет структуру LCP-пакетов (с тем исключением, что определены лишь типы 1-7). В случае АТСР-пакетов Configure-Request, Configure-Ack, Configure-Nack и Configure-Reject раздел данных АТСР состоит из одного или более параметров АТСР, а каждый параметр АТСР — из поля типа параметра, поля длины (указывающего общий размер параметра в байтах) и данных, связанных с этим параметром. Согласуемые параметры Параметры АТСР, согласуемые сторонами соединения Microsoft РРР, перечислены в таблице 7-12. Таблица 7-12. Параметры АТСР Имя параметра
Тип
Длина Описание
AppleTalk Address (AppleTalk-адрес) Server Information (информация о сервере)
I
6
3
16
Позволяет согласовать номера AppleTaIk-сети и узла Используется для передачи информации о сервере удаленного доступа
ГЛАВА 7
Сервер удаленного доступа
245
NBFCP Протокол NBFCP в том виде, в каком он используется сторонами соединения Microsoft PPP, документирован в RFC 2097. По-этому протоколу согласуются параметры NetBEUI для динамической настройки NetBEUI на сторонах соединения типа «точка-точка». Стандартные параметры NBFCP включают параметры фильтрации групповой рассылки и информацию о сторонах соединения. Структура пакетов РРР-идентификатор протокола NBFCP — Ox803F. Структура NBFCP-пакетов точно повторяет структуру LCP-пакетов (с тем исключением, что определены лишь типы 1-7). В случае NBFCP-пакетов Configure-Request, Configure-Ack, ConfigiireNack и Configure-Rejecc раздел данных NBFCP состоит из одного или более параметров NBFCP. а каждый параметр NBFCP — из поля типа параметра, поля длины (указывающего общий размер параметра в байтах) и данных, связанных с этим параметром. Согласуемые параметры Параметры NBFCP, согласуемые сторонами соединения Microsoft PPP, перечислены в таблице 7-13. Таблица 7-13. Параметры NBFCP Имя параметра
Тип
Длина Описание
Multicast filtering (фильтрация групповой рассылки) Peer information (информация о сторонах соединения)
3
5
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
ЧАСТЬ 2
Удаленный доступ
Таблица 7-14. Параметры ССР
Имя параметра
Тип
Длина
Описание
Organization Unique Identifier (уникальный идентификатор организации) МРРС
0
6
Используется для согласования особого протокола сжатия данных, применяемого в организации Служит признаком использования МРРС и МРРЕ, а также указывает стойкость шифрования
и более
18, 6 или 0x12
МРРЕ и МРРС ССР-параметр 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-битных ключей (0x0000-00-40) 32-битное поле данных будет выглядеть как 0x00-00-00-41. Подробнее о МРРЕ см. Интернет-проект «Microsoft Point-To-Point Encryption (МРРЕ) Protocol*,
ЕСР Протокол ЕСР (Encryption Control Protocol) используется для согласования конкретного метода шифрования и документирован в RFC 1968. Однако в случае соединения Microsoft PPP для шифрования данных поддерживается только МРРЕ, применение которого указывается в ССР-параметре МРРС.
Процесс РРР-соединения Согласование РРР-соединения проходит в четыре этапа: •
настройка РРР;
• аутентификация; •
ответный вызов;
•
конфигурирование протоколов.
ГЛАВА 7
Сервер удаленного доступа
247
Этап 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 •
Удаленный доступ
ЧАСТЬ 2
средства трассировки РРР — используются для протоколирования обмена РРРпакетами в процессе установления РРР-соединения.
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 = 36 2
8.796
RECV
RECV
LCP
Corifig Req Packet. Ident = 0x00, Length = 25
ГЛАВА 7 3
8,796
SEND
SEND
Сервер удаленного доступа
LCP
Config Ack Packet, Ident = 0x00, Length = 25
•1
8.816
5
8.816
RECV
RECV
LCP
SEND
SEND
LCP
RECV
RECV
LCP
Config Reject Packet, Ident = 0x00, Length = 17
Config Req Packet, Ident = 0x01, Length = 23
G
В. 886
Config Ack Packet, Ident = 0x01, Length = 23 ,
6.886
SEND
SEND
LCP
Ident Packet, Ident = 0x02, Length = 18 8
8.886
SEND
SEND
LCP
RECV
RECV
PPPCHAP
SEND
SEND
PPPCHAP
RECV
RECV
PPPCHAP
RECV
RECV
CBCP
Ident Packet, Ident = 0x03, Length = 23
•
8.886
Challenge, ID = Ox 1 : Challenge
1C
8.886
Ii
8.976
Challenge, ID = Ox 1: Response, administrator
Challenge, 10 = Ox 1 : Success
i:.;
В. 976
13
8.976
Callback Request, Ident = 0x01 SEND
SEND
CBCP
Callback Response, Ident = 0x01 14
8.996
RECV
RECV
CBCP
Callback Acknowledgement, Ident = 0x01
15
8.996
SEND
SEND
CCP
К
8.997
SEND
SEND
IPCP
17
8.997
Configuration Request, Ident = 0x04 Configuration Request, Ident = 0x05
RECV
RECV
CCP
RECV
RECV
IPCP
RECV
RECV
IPXCP
RECV
RECV
NBFCP
Configuration Request, Ident = 0x01
И
9.017
1U
9.037
11
9.037
Configuration Request, Ident = 0x02 Configuration Request, Ident = 0x03 Configuration Request, Ident = 0x04
21
9.117
:v
9.147
23
9.147
24
9.167
25
9.167
26
9.237
27
9.237
28
9.237
SEND
SEND
IPCP
29
9.257
RECV
RECV
IPXCP
SEND
SbND
IPXCP
SEND
SEND
CCP
Configuration Request, Ident = 0x06 Configuration Acknowledgement, Ident = 0x01
SEND
SEND
IPCP
Configuration Acknowledgement, Ident = 0x02 SEND
SEND
IPXCP
Configuration Acknowledgement, Ident = 0x03 SEND
SEND
LCP
RECV
RECV
CCP
RECV
RECV
IPCP
Protocol Reject Packet, Ident = 0x07, Length = 32
Configuration Reject, Ident = 0x04 Configuration Reject, Ident = 0x05 Configuration Request, Ident = 0x08 Configuration No Acknowledgement, Ident = 0x06
249
Удаленный доступ
250
ЧАСТЬ 2
30
9.257
SEND SEND IPXCP Configuration Request, Ident = 0x09
31
9.287
RECV
32 33 34 35 36 37 38
RECV
IPCP
Configuration No Acknowledgement, Ident = 0x08 9.287 SEND SEND IPCP Configuration Request, Ident = OxOA 9.287 RECV RECV IPXCP Configuration Acknowledgement, Ident = 0x09 9.327 RECV RECV IPCP Configuration Acknowledgement, Ident = OxOA 10.729 SEND SEND CCP Configuration Request, Ident = 0x04 10.960 RECV RECV CCP Configuration Reject, Ident = 0x04 10.960 SEND SEND CCP Configuration Request, Ident = OxOB 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.967 FRAKE: Time delta from previous physical frame: 0 milliseconds FRAME: Frame number: 1 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 = 36 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.COMPCALL.BACK;Unkn--LCP: ASYNC.MAP:00 00 00 00 LCP: Option Type = Async Control Character Map
ГЛАВА 7
Сервер удаленного доступа
251
LCP: Option Length = 6 (0x6) LCP: Async Control Character Map = 00 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 = 0x06 LCP: Multilink Maximum Receive Reconstructed Unit LCP: Option Type = 0x11 LCP: Option Length = 4 (0x4) LCP: Multilink Endpoint Discriminator LCP: Option Type = 0x13 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 5 [1472] 15:57:50:104: Starting PPP on link with IfType=OxO,IPIf=OxO, IPXIf=OxO
[1472] [1472] [1472] [1472] [1472] [1472]
15:57:50:104: RasGetBuffer returned ae70054 for SendBuf 15:57:50:104: Fsmlnit called for protocol = c021, port = 5 15:57:50:104: Configlnfo = 273e 15:57:50:104: APs available = 1 15:57:50:104: FsmReset called for protocol = c021, port = 5 15:57:50:104: Inserting port in bucket ft 5
252
ЧДСТЬ 2
Удаленный доступ
[1472] 15:57:50:104: Inserting bundle in bucket tt 6 [1472] 15:57:50:104: FsmOpen event received for protocol c021 on port 5 [1472] 15:57:50:104: FsfflThisLayerStarted called for protocol = c021, port = 5 [1472] 15:57:50:104: FsmUp event received for protocol c021 on port 5 [1472] 15:57:50:104:
F ...... | [1472] 15:57:50:104: InsertlnTimerQ called portid=6.Id=0, Protocol=c021, EventType=0,fAuth=0 [1472] 15:57:50:104: InsertlnTimerQ called portid=6,Id=0, Protocol=0, EventType=3,fAuth=0 [1472] 15:57:50:104: >PPP packet received at 11/04/1998 23:57:50:104 [1472] 15:57:50:104: >Protocol = LCP. Type = Configure-Req, Length = 0x26, Id = 0x0, Port = 5 [1472] 15:57:50:104: >CO 21 01 00 00 24 02 06 00 00 00 00 05 06 00 00 [1472] 15:57:50:104: >CO 05 07 02 08 02 OD 03 06 11 04 06 4E 13 09 03 [1472] 15:57:50:104: >00 60 08 52 F9 D8 00 00 00 00 00 00 00 00 00 00 I - ' . R ............ I
Последние три строки из этого фрагмента файла трассировки отражают содержимое того же LCP-пакета (в итестнадцатеричном виде), что и листинг кадра 1 из предыдущего примера с использованием Network Monitor. Чтобы понять структуру этого РРР-кадра, Вы должны вспомнить структуру РРР- и LCP-пакетов. Пример его анализа приведен в таблице 7-15. Таблица 7-15. Анализ LCP-пакета Configuration-Request Байты
Описание
СО 21
РРР-идентификатор протокола для LCP LCP-код сообщения Configure-Request LCP-идентификатор данного сообщения Configure-Request Длина LCP-пакета в байтах (в данном случае — 36 байтов) LCP-парамстр Asynchronous Control Character Map (ACCM) Длина параметра АССМ в байтах Данные параметра ЛССМ LCP-параметр для волшебного номера Длина параметра для волшебного номера в байтах Данные параметра для волшебного номера LCP-параметр для сжатия протокола Длина параметра для сжатия протокола в байтах LCP-параметр для сжатия полей адреса и управления Длина параметра для сжатия полей адреса и управления в байтах
01 00 0024
02 06 00 00 00 00 05 06 00 00 СО 05 07 и• 08 и •
ГЛАВА 7 Таблица 7-15.
Сервер удаленного доступа
253
(продолжение)
Байты
Описание
OD
LCP-параметр для ответного вызова
03
Длина параметра для ответного вылова в байтах
06
Данные параметра для ответного вызова
11
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 идентична трассировке РРР в Windows NT версий 4,0 и ниже.
Закрытие РРР-соединения При использовании РРР соединение может быть закрыто в любой момент. Обычно это происходит при потере несущей, неудачной аутентификации, падении пропускной способности подключения, таймауте или закрытии соединения клиентом удаленного доступа либо системным администратором. В момент закрытия соединения РРР информирует об этом протоколы сетевого уровня, чтобы они могли выполнить нужные операции.
РРР-протоколы аутентификации Па втором этапе установления РРР-соединения клиент удаленного доступа аутснтифицируется по одному из РРР-нротоколов аутентификации. О конкретном РРРпротоколе аутентификации стороны договариваются на первом этапе установления РРР-соединения. Средства удаленного доступа в Windows 2000 поддерживают следующие РРР-протоколы аутентификации: ЕАР (Extensible Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) версий 1 и 2, SPAP (Shiva Password Authentication Protocol) и PAP (Password Authentication Protocol). Надежная схема аутентификации должна обеспечивать защиту от атак с иов-.орением пакетов (replay attacks), а также от подмены клиента или сервера удаленного доступа.
254
ЧАСТЬ 2
Удаленный доступ
• Атака с повторением пакетов заключается в том, что злоумышленник захватывает пакеты, передаваемые по сети в процессе успешного установления соединения, а впоследствии повторяет (воспроизводит) эти пакеты, чтобы установить несанкционированное соединение. • Подмена клиента удаленного доступа — атака, при которой злоумышленник подменяет клиент на уже установленном соединении. При этом злоумышленник дожидается успешной аутентификации подлинного пользователя, определяет параметры соединения, а затем отключает этого пользователя и берет управление соединением на себя. • Подмена сервера удаленного доступа — атака, при которой злоумышленник подменяет подлинный сервер удаленного доступа своим компьютером. При этом подставной сервер имитирует проверку удостоверений клиента удаленного доступа, а потом захватывает весь трафик, исходящий от клиента.
РАР PAP (Password Authentication Protocol) — простейший протокол аутентификации, использующий пароли в незашифрованном виде. Имя и пароль пользователя запрашиваются сервером удаленного доступа и сообщаются клиентом открытым текстом. Поэтому РАР не является безопасным протоколом аутентификации. Злоумышленник, перехватывающий РАР-пакеты, которые передаются между клиентом и сервером удаленного доступа, может легко определить пароль клиента. РАР не обеспечивает защиту от атак с повторением пакетов, а также от подмены клиента или сервера удаленного доступа. О применении РАР стороны договариваются в LCP-процессе согласования, указывая в LCP-параметре Authentication Protocol (тип 3) значение ОхС023. По окончании LCP-согласования в РАР-сообщениях используется РРР-идентификатор протокола ОхС023. РАР реализует простой обмен сообщениями. 1. Клиент удаленного доступа посылает серверу РАР-сообщение AuthenticateRequest с именем пользователя и паролем в виде незашифрованного текста. 2. Сервер удаленного доступа проверяет имя и пароль пользователя, а затем посылает РАР-сообщение Authenticate-Ack, если удостоверения правильны, или Authenticate-Nak, если удостоверения неправильны. РАР включен в Windows 2000 только для того, чтобы клиенты удаленного доступа под управлением 32-разрядных операционных систем Windows могли подключаться к серверам удаленного доступа, не поддерживающим безопасные протоколы аутентификации, а также для того, чтобы клиенты удаленного доступа под управлением операционных систем, отличных от Microsoft и не поддерживающих безопасные протоколы аутентификации, могли подключаться к серверу удаленного доступа под управлением 32-разрядной операционной системы Windows. Примечание Для большей безопасности сервера удаленного доступа рекомендуется отключить РАР. Но тогда устаревшие клиенты под управлением операционных систем, отличных от Microsoft, не смогут подключаться к этому серверу.
ГЛАВА 7
Сервер удаленного доступа
255
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-сообщение AuthenticateRequest с именем пользователя и паролем в зашифрованном виде. 2. Сервер удаленного доступа расшифровывает пароль, проверяет имя п пароль пользователя, а затем посылает SPAP-сообщение Authenticate-Ack, если удостоверения правильны, или Authenticate-Nak, если удостоверения неправильны.
CHAP CHAP (Challenge Handshake Authentication Protocol) — протокол аутентификации, основанный на технологии «вызов-ответ* (challenge-response) и описанный в RFC 1994. Он использует стандартный алгоритм необратимого шифрования MD5 (Message Digest 5) для хэширования ответа на вызов, посланный сервером удаленного доступа, CHAP применяется многими разработчиками серверов и клиентов удаленного доступа. Этот протокол поддерживается как клиентами, так и серверами удаленного доступа Windows 2000. CHAP более совершенен, чем РАР и SPAP: пароль не пересылается по каналу связи, а используется для создания необратимого хэша из строки вызова. Сервер, которому известен пароль пользователя, проводит ту же операцию и сравнивает полученный результат с ответом клиента. О применении CHAP стороны договариваются в LCP-процессе согласования, указывая в LCP-параметре Authentication Protocol (тип 3) значение ОхС223 и алгоритм 0x05. По окончании LCP-согласования в СНАР-сообщениях используется РРРидентификатор протокола ОхС223. Аутентификация по протоколу CHAP представляет собой обмен тремя сообщениями. 1. Сервер удаленного доступа посылает СНАР-сообщсние Challenge (вызов) с идентификатором сеанса и произвольной строкой вызова. 2. Клиент удаленного доступа возвращает С НАР-сообщение Response (ответ) с именем пользователя в незашифрованном виде и хэшем, полученным из строки вызова, идентификатора сеанса и пароля с применением алгоритма MD5. 3. Сервер удаленного доступа выполняет ту же операцию над теми же данными и сравнивает свой результат с ответом. Если они совпадают, сервер удаленного
256
ЧЛСТЬ 2 Удаленный доступ
доступа возвращает СНАР-сообщение Success (успех); нет — СНАР-сообщение Failure (неудача). CHAP обеспечивает защиту от атак с повторением пакетов, так как при каждой попытке аутентификации использует новую строку вызова, генерируемую случайным образом. Однако CHAP не защищает от подмены сервера удаленного доступа.
MS-CHAP v1 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 (успех); нет — сообщение MSCHAP 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 Сервер удаленного доступа
257
MS-CHAP v2 Windows 2000 поддерживает протокол MS-СНЛР v2 (Microsoft Challenge Handshake 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 Challenge (вызов) с идентификатором сеанса и произвольной строкой вызова. 2. Клиент удаленного доступа посылает сообщение MS-CHAP v2 Response (ответ), содержащий: • имя пользователя; • произвольную строку вызова; • кэш, сгенерированный по методу SHA (Secure Hash Algorithm) из строки вызова, полученной от сервера, собственной строки вызова, идентификатора сеанса и MD4-X3iita пароля пользователя. 3. Сервер удаленного доступа проверяет сообщение MS-CHAP v2 Response, принятое от клиента, и посылает свой ответ, содержащий: • признак успеха или неудачи попытки соединения; • аутентификационный ответ на основе переданной строки вызова, собс твенной строки вызова, шифрованной строки вызова клиента и пароля пользователя. 4. Клиент удаленного доступа проверяет аутентификационный ответ и, ееш он правилен, использует соединение. Если же ответ неправилен, клиент разрывает соединение.
258
ЧАСТЬ 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-MD5 EAP-MD5 — это механизм аутентификации CHAP, используемый в рамках ЕАР. На этапе установления соединения стороны договариваются, что на этапе аутентификации будут применять ЕАР. На этапе аутентификации происходит процесс проверки клиента. 1. Проверяющий посылает сообщение EAP-Request, запрашивающее идентификацию клиента. 2. Клиент посылает идентификатор пользователя в сообщении EAP-Response. 3. Проверяющий посылает сообщение EAP-Request со строкой вызова MD5. 4. Клиент посылает МО5-хэш идентификатора и пароля пользователя в сообщении EAP-Response. 5. Если ответ правильный, проверяющий посылает клиенту сообщение Success об успешной аутентификации.
ГЛАВА 7
Сервер удаленного доступа
259
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
ЧАСТЬ 2
Удаленный доступ
сервер RADHJS, Сервер RADIUS обрабатывает сообщение и посылает серверу удаленного доступа ответное сообщение КАР, инкапсулированное в сообщение RADIUS. Наконец, сервер удаленного доступа пересылает сообщение ЕАР клиенту.
Неаутентифицируемые соединения 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 2000 настраивает параметры сетевой конфигурации для клиентов удаленного доступа, использующих 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
Сервер удаленного доступа
261
сов. Сервер удаленного доступа использует для интерфейса сервера 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-адреса, освобожденные в результате отключения клиентов удаленного доступа, используются повторно. Если диапазон адресов статического пула относится к другой подсети, нужно либо включить соответствующий протокол маршрутизации па сервере удаленного доступа, либо добавить маршруты, соответствующие диапазонам IP-адресов, на маршрутизаторы Вашей интрасети. Подробнее см. раздел «Выделение адресов из диапазона внутри или вне подсети» ранее в этой главе.
262
ЧАСТЬ 2
Удаленный доступ
Назначение адресов DNS- и WINS-серверов В IPCP-процессе согласования сервер удаленного доступа назначает IP-адреса DNS- и WINS-серверов. Какой именно набор IP-адресов этих серверов будет назначен клиенту удаленного доступа, зависит от следующих факторов: • запрещено ли присвоение IP-адресов DNS- и WINS-серверов; • настраиваются ли IP-адреса этих серверов для клиентов удаленного доступа глобально — с использованием данных, хранящихся в реестре; • имеется ли на сервере удаленного доступа более одного LAN-интерфейса; • настраиваются ли IP-адреса DNS- и WINS-серверов для сервера удаленного доступа статически или назначаются динамически через DHCP,
Запрещение присвоения IP-адресов DNS- и WINS-серверов Если Вы не хотите, чтобы сервер удаленного доступа назначал IP-адреса DNS- и WINS-серверов, присвойте значение 1 параметрам SuppressDNSNameServers и SuppressWINSNameServers в разделе реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services \RemoteAccess\Parameters\Ip Настройка глобального присвоения IP-адресов DNS- н WINS-серверов Чтобы глобально настроить IP-адреса DNS- и WINS-серверов для клиентов удаленного доступа, укажите нужные IP-адреса в параметрах DNSNameServers и WINSNameServers в разделе реестра: HKEY_LOCAL_MACHINE\Systeni\CurrentControlSet\Sen4ces \RemoteAccess\Parameters\Ip Несколько LAN-интерфейсов Если назначение IP-адресов DNS- и WINS-серверов не запрещено и они не настраиваются глобально, сервер удаленного доступа присваивает клиентам удаленного доступа IP-адреса DNS- и WINS-серверов, достижимые через LAN-интерфейс сервера RAS. Если на сервере удаленного доступа только один LAN-интерфейс (типичная конфигурация), сервер назначает клиентам IP-адреса DNS- и WINS-серверов, доступные через этот LAN-интерфейс. Если же таких интерфейсов несколько, нужно указать какой-то один из них. При наличии нескольких LAN-интерфейсов (типичная конфигурация для VPN-серверов удаленного доступа) служба маршрутизации и удаленного доступа случайным образом выбирает один из них при запуске, и тогда сервер удаленного доступа назначает клиентам IP-адреса DNS- и WINS-серверов, достижимых через выбранный LAN-интерфейс. Если Вы хотите самостоятельно выбрать нужный LAN-интерфейс, запустите оснастку Routing and Remote Access (Маршрутизация и удаленный доступ), откройте окно свойств сервера удаленного доступа, перейдите на вкладку IP и укажите требуемый интерфейс. По умолчанию выбирается Allow RAS to select adapter. Статическая настройка и конфигурирование через DHCP После того как LAN-адаптер для назначения IP-адресов DNS- и WINS-серверов определен, происходит следующее.
ГЛАВА 7
Сервер удаленного доступа
263
•
Если LAN-адаптер имеет статическую конфигурацию IP, клиентам удаленного доступа выделяются IP-адреса статически настроенных DNS- и WINS-серверов.
•
Если LAN-адаптер получает параметры конфигурации IP через DHCP, клиентам удаленного доступа выделяются IP-адреса DNS- и WINS-сериеров, полученные от DHCP-сервера.
Как сервер удаленного доступа определяет набор IP-адресов DNS- и WINS-серверов для выделения клиентам удаленного доступа в IPCP-пропессе согласования, показано на рис. 7-14.
Начало
Hei
Нет Существует ли более одного LAN-интерфейса?
HIM
Запрещено ли назначение IP-адресов DNSи WINS-серверов?
Указаны ли в реестре IP-адреса DNS- и WINSсерверов?
Не назначать IP-адреса DNSи WINS-серверов
Назначить IP-адреса DNSи WINS-сераеров, указанные в реестре
Да Выбран ли какой-нибудь LAN-интерфейс? Иг:
Выбрать один из LAN-интерфейсов
случайным образом
Назначить статически заданные IP-адреса DNS-и WINS-серверов
Нет-—-<Г У Имеется ли | интерфейс, использующий I DHCP?
Да
Назначить IP-адреса DNS-и WINS-серверов, полученные через DHCP
Рис. 7-14. Определение IP-адресов DNS- и WINS-серверов
264
ЧДСТЬ 2 Удаленный доступ
Изменение IP-адресов DNS- и lA/INS-серверов, назначенных в IPCP-процессе согласования, с помощью DHCPInform По окончании ТРСР-процесса согласования клиенты удаленного доступа под управлением Windows 98 и Windows 2000 посылают серверу удаленного доступа сообщение DHCPInform, Это DHCP-сообщение используется DHCP-клиентами для получения параметров DHCP. РРР-клиенты удаленного доступа не используют DHCP для получения адресов, но, если они работают под управлением Windows 98 или Windows 2000, то получают IP-адреса DNS- и WINS-серверов, а также доменное DNS-имя, посылая сообщение DHCPInform после IPCP-согласования. Сообщение DHCPInform, полученное сервером удаленного доступа, пересылается на DHCP-сервер. Однако для этого на сервере удаленного доступа должен быть установлен агент ретрансляции DHCP, о котором будет рассказано в следующем разделе. Ответ на сообщение DHCPlnfonii пересылается обратно запрашивающему клиенту. Если в ответе DHCPInform содержатся параметры, указывающие IP-адреса DNSи WINS-серверов. новые адреса заменяют полученные в ТРСР-продессе согласования. Если клиент удаленного доступа работает под управлением Windows 2000 и в ответе DHCPInform указывается доменное DNS-имя, это имя используется в качестве DNS-суффикса для конкретного адаптера при подключении клиента удаленного доступа. Подробнее о DNS-суффиксах ем. главу 6 «DNS в Windows 2000» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server».
Сервер удаленного доступа и агент ретрансляции DHCP Для подержки пересылки сообщений DUCPInform между клиентами удаленного доступа и DHCP-серверами на сервере удаленного доступа должен быть установлен DHCP Relay Agent (Агент ретрансляции DHCP) — один из компонентов службы маршрутизации и удаленного доступа в Windows 2000. Чтобы настроить сервер удаленного доступа на использование: агента ретрансляции DHCP, в оснастке Routing and Remote Access раскройте узел IP Routing (IP-маршрутизация), укажите DHCP Relay Agent (Агент DHCP-ретрансляции) и добавьте интерфейс Internal (Внутренний). Если сервер удаленного доступа для получения IP-адресов, выделяемых удаленного доступа, использует DHCP, значит, для пересылки сообщений form между клиентами и DHCP-еервером, доступным через выбранный терфейс, используется агент ретрансляции DHCP. Это можно проверить ке IP в свойствах сервера удаленного доступа.
клиентам DHCPInLAN-инна вклад-
Если же сервер удаленного доступа для выделения IP-адресов клиентам использует статический пул IP-адресов, то для агента ретрансляции DHCP нужно указать IP-адрес хотя бы одного DHCP-сервера. Иначе сообщения DHCPInform, посылаемые клиентами удаленного доступа, будут «молча» отбрасываться.
IPX Для настройки IPX-клиента удаленного доступа в IPXCP-процсссе согласования сервер удаленного доступа присваивает ему номера IPX-сети и IPX-узла, Правила присвоения номера IPX-сети определяются параметрами на вкладке IPX (IPX)
ГЛАВА 7
Сервер удаленного доступа
265
окна свойств сервера удаленного доступа в оснастке Routing and Remote Access. Ниже перечислены основные возможности настройки IPX. •
Номера IPX-сетей для клиентов удаленного доступа присваиваются автоматически или задаются администратором как диапазон. При автоматическом присвоении номеров IPX-сетей сервер удаленного доступа должен убедиться, что данный номер не используется в межсетевой ТРХ-среде, и для этого посылает через все свои LAN-интерфейсы RIP-пакст GelLocalTarget. Если на RIP-заирос Get Local Target приходит ответ, значит, данный помер IPX-сети уже занят, и сервер выбирает другой номер.
•
Всем клиентам удаленного доступа может быть присвоен один и тот же номер IPX-сет и,
•
Клиенты удаленного доступа могут запрашивать определенные номера 1РХ-у. тов.
Если Вы хотите задать первый из номеров IPX-узлов, выделяемых клиентам удаленного доступа, укажите его в виде 12-разрядного шестнадцатиричного числа в параметре FirstWanNode (тип REG_SZ), добавив его в раздел реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services \RemoteAccess\Parameters\Ipx Следующий IPX-клиент получит помер узла, увеличенный на 1, и т. д. Если в реестре нет параметра FirstWanNode, клиент удаленного доступа, не требующий определенного номера IPX-узла, получаст случайный номер в форме Qx2E-xx-xx-xx-xx-xx.
Политика удаленного доступа В Windows 2000 соединения удаленного доступа принимаются на основе параметров входящих звонков в свойствах пользовательской учетной записи и политиках удаленного доступа. Политика удаленного доступа — это набор условий и параметров соединения, определяющих характеристики входящих подключений и налагаемый на них набор ограничений. Политики удаленного доступа позволяют давать разрешения на подключения, исходя из времени суток, дня недели, принадлежности звонящего к той или иной группе Windows 2000, типа клиента удаленной.' доступа (соединение по коммутируемой линии или через VPN) и т.д. Политики удаленного доступа используются и для ограничения значений таких параметров соединения, как максимальная длительность сеанса, время простоя до разрыва соединения, допустимые методы аутентификации, способы шифрования тт др. Если определено сразу несколько политик удаленного доступа, к разным клиентам удаленного доступа применяются разные наборы условий, либо требования к одному клиенту зависят от параметров соединения. Несколько политик удаленного доступа используется, например, чтобы: •
разрешить или запретить соединения, если учетная запись пользователя относится к определенной группе;
•
определить расписание доступа для разных учетных записей в зависимости от принадлежности к той или иной группе:
• применять разные методы аутентификации для клиентов удаленного доступа, подключающихся по коммутируемой линии и через VPN;
26В
ЧАСТЬ 2
Удаленный доступ
•
настроить разные параметры аутентификации и шифрования для РРТР- и Ь2ТР-соединений; • задать длительность сеансов для разных учетных записей на основе принадлежности к той или иной группе; • посылать клиенту RADIUS атрибуты RADIUS, специфичные для конкретного сервера доступа к сети (network access server, NAS). Если у Вас несколько серверов удаленного доступа Windows 2000 или VPN-серверов и Вы хотите, чтобы все они авторизовали входящие соединения по централизованному набору политик удаленного доступа, нужно установить на каком-нибудь компьютере Windows 2000 и Internet Authentication Service (IAS) (Служба проверки подлинности в Интернете). Затем следует настроить все серверы удаленного доступа или VPN-серверы на использование сервера IAS в качестве клиентов RADIUS. Подробнее о политиках удаленного доступа, в том числе о типичных примерах таких политик, см. справочную систему Windows 2000 Server.
Обработка запроса на соединение При обработке запроса на соединение его параметры сравниваются с именем пользователя, паролем, параметрами входящих звонков в свойствах пользовательской учетной записи и в действующих политиках удаленного доступа. Общая схема обработки запроса на соединение представлена ниже. • Если в запросе указано неправильное имя или пароль пользователя, запрос отклоняется. • Если не определена ни одна политика удаленного доступа, все запросы на соединение отклоняются. • Если параметры запроса не соответствуют хотя бы одной политике удаленного доступа, запрос отклоняется. • Если в параметрах входящих звонков в свойствах учетной записи пользователя выбран переключатель Deny Access (Запретить доступ), запросы данного пользователя на удаленное соединение всегда отклоняются. •
Запрос на соединение принимается, если его параметры отвечают всем условиям политики удаленного доступа, если данному пользователю разрешен удаленный доступ (либо в свойствах учетной записи, либо в политике удаленного доступа) и если параметры запроса соответствуют параметрам входящих звонков (либо в свойствах учетной записи, либо в политике удаленного доступа).
Пример обработки запроса на соединение с использованием параметров входящих звонков в свойствах учетной записи и политик удаленного доступа показан на рис. 7-15. Здесь предполагается, что имя и пароль пользователя, переданные в процессе аутентификации, соответствуют действительной учетной записи,
ГЛАВА 7
Сервер удаленного доступа
267
Начала
Да
Ц Отклонить запрос на соединение
Определены ли какие-нибудь политика удаленного доступа?
S\
Т Да
Т да is
Перейти к следующей политике
Соответствуют ли параметры запроса условиям данной политики?
Запрещен ли удаленный доступ свойствах учетной записи?
Разрешен ли удаленный доступ в свойствах учетной записи?
jа
Щ Отклонить запрос на соединение
Y да
Запрещен ли удаленный доступ в данной политике? 1 Отклонить запрос на соединение
'W ^
%
Т 1
"•»,•
НбТ
Соответствуют ли параметры запроса параметрам объекта пользователя и профиля?
Отклонить запрос на соединение
Принять запрос на соединение
Рис. 7-15. Обработка запроса на соединение
Проблемы с политиками удаленного доступа Распространенная проблема, возникающая при использовании политик удаленного доступа, — отказ в соединении, когда оно должно было бы быть принято. Если у Вас появились какие-нибудь сомнения, проверьте параметры запроса на соединение, параметры входящих звонков в свойствах учетной записи пользователя и политиках удаленного доступа, придерживаясь схемы на рис. 7-15. При наличии не-
268
ЧАСТЬ 2
Удаленный доступ
скольких политик удаленного доступа поиск причины отказа в соединении может занять очень много времени. Если у Вас несколько политик удаленного доступа и Бы хотите определить, какая из них приводит к отказу в соединении, включите запись запросов на проверку подлинности (аутентификацию) в свойствах локального файла журнала удаленного доступа; для этого в оснастке Routing and Remote Access укажите папку Remote Access Logging (Ведение журнала удаленного доступа), щелкните правой кнопкой мыши нужный локальный файл и выберите команду Properties (Свойства). Записанные в журнале запросы на аутентификацию содержат имя политики удаленного доступа, приводящей к приему или отклонению соединения.
Multilink и ВАР Средства удаленного доступа в Windows 2000 поддерживают РРР-протоколы МР (Multilink Protocol). BAP (Bandwidth A l l o c a t i o n Protocol) и ВАСР (Bandwidth Allocation Control Protocol). •
МР позволяет объединять несколько физических каналов в один логический канал, но которому передаются и принимаются данные. • ВАР — это управляющий протокол РРР, используемый для динамического добавления или удаления дополнительных каналов к МР-соединению. • ВАСР — это РРР-протокол NCP, выбирающий предпочтительную сторону РРРсоединепия в том случае, если обе стороны пытаются одновременно добавить или удалить канал. Каждый из этих протоколов подробно рассматривается в следующих разделах.
РРР-протокол МР РРР-протокол МР ( M u l t i l i n k Protocol) определен в RFC 1990 и используется для объединения нескольких физических каналов в один логический. Один из примеров его применения — объединение двух В-каналов соединения ISDN BRI (Basle Rate Interface). MP фрагментирует, формирует последовательности и переупорядочивает пакеты, посылаемые по нескольким физическим каналам, так чтобы создать R результате один логический канал с полосой пропускания, равной сумме полос пропускания всех физических каналов. МР рекомендуется для объединения нескольких В-каналов BRI-соединения, поскольку аппаратная поддержка такого объединения может быть специфична для конкретного адаптера ISDN. МР должен поддерживаться обеими сторонами соединения. Структура МР-кадра показана на рис. 7-16. Полезной нагрузкой такого пакета является РРР-кадр или его фрагмент. Фрагментация средствами Multilink не нужна, если размер МР-пакета меньше значения MRU данного канала. Чтобы не допустить неправильного порядка следования дейтаграмм или фрагментов по нескольким физическим каналам, между полем РРР-протокола и IP-дейтаграммой используются дополнительные поля. РРР-идентификатор протокола МР — Ox003D. В RFC 1717 определено два формата пакета — с короткими и длинными номерами последовательностей. Эти номера используются для предотвращения неправильного порядка кадров, посылаемых по нескольким каналам, а не для формирования последовательности фрагментов.
ГЛАВА 7 Пакет с коротким номером последовательности
Сервер удаленного доступа Пакет с длинным номером последовательности
Флаг
VT
Флаг
Адрес
FF
Адрес
Управление
03
Управление
Протокол
269
Протокол
00 3D
Разделитель/номер последовательности
Разделитель Номер последовательности
Данные фрагмента
Данные фрагмента
FCS
Флаг
FI
Флаг = 1 байт
Рис. 7-16. РРР-протокол Multilink В случае формата с короткими номерами последовательностей двухбайтовое поле разделителя/номера последовательности состоит из четырех битов отграничения и 1 2 битов номера последовательности. Внутри поля разделителя содержится два битовых флага. Первый (бит начала) укалывает, что данный фрагмент является первым в последовательности фрагментов, относящихся к пакету, а второй (бит конца) -- что этот фрагмент является последним в последовательности фра] ментов, относящихся к пакету. Остальные два бита приравниваются нулю, Для РРР-кадров, посылаемых без фрагментации, оба флага (биты начала и конца) устанавливаются в 1. Если длина РРР-кадра больше MRU, он фрагментируется, и каждый фрагмент передается как отдельный РРР-иакст. Протокол МР выполняет фрагментацию па канальном уровне, которая не имеет никакого отношения к IPфрагментации. В случае формата с длинными номерами последовательностей четырехбайтовое поле разделителя/номера последовательности состоит из восьми битов (одного байта) отграничения и 24 битов (трех байтов) номера последовательности. Внутри поля разделителя присутствуют те же биты начала и конца, а остальные биты в первом байте равны 0, По умолчанию выбирается формат с длинными номерами последовательностей, если в LCP-процессе согласования не согласован формат с короткими номерами. LCP-параметры Multilink, которые согласуются сторонами соединения, использующими Microsoft PPP, перечислены в таблице 7-16. С) других параметрах Multilink см. RFC 1990. Таблица 7-16. LCP-параметры Multilink Имя параметра
Тим
Multilink Maximum Receive Reconstructed Unit
17, или 0x11
Длина Описание Указывает число октетов, которые сторона • оединспия может восстановить из фрагментированных МР-кадров
(см. след, стр.)
270
ЧАСТЬ 2
Таблица 7-16.
Удаленный доступ (продолжение)
Имя параметра
Тип
Длина Описание
2 Short Sequence 18, Number Header Format или 0x12 9 Multilink Endpoint 19, Discriminator или 0x13
Указывает, что в МР-заголовке используется короткий номер последовательности Уникальный системный идентификатор, позволяющий различать каналы от двух сторон РРР-соединения с одним аутентификашюнным именем
ВАР Хотя протокол МР позволяет объединять несколько физических каналов, в нем нет механизма адаптации к изменению условий, который был бы способен при необходимости добавлять новые каналы или удалять существующие. Такая функциональность поддерживается протоколами ВАР (Bandwidth Allocation Protocol) и ВАСР (Bandwidth Allocation Control Protocol), определенными в RFC 2125. BAP — это управляющий протокол РРР, используемый при МР-соединениях для динамического управления каналами. РРР-идентификатор протокола ВАР — ОхСОЗО. Например, клиент и сервер удаленного доступа, поддерживающие протоколы МР и ВАР, устанавливают МР-подключение, которое состоит из одного физического канала. Как только нагрузка на капа,'! вырастает до заданного порогового значения, клиент удаленного доступа с помощью БАР-сообщения Call-Request запрашивает дополнительный канал. ВАР-сообщение Call-Request указывает нужный тип канала (например, аналоговая телефонная линия, ISDN или Х.25). В ответ сервер удаленного доступа посылает ВАР-сообщепие Call-Response, содержащее телефонный номер свободного порта сервера удаленного доступа, тип которого соответствует типу, запрошенному клиентом. Когда нагрузка на втором канале снижается до заданного порогового уровня, сервер или клиент удаленного доступа посылает ВАР-сообщение Link-Drop-QueryRequest для отключения дополнительного канала. ВАР также поддерживает сообщение Callback-Request, в котором запрашивающая сторона указывает тип канала и телефонный номер для приема ответного вызова. Подробнее о сообщениях ВАР см. RFC 2125. LCP-параметры ВАР, которые согласуются сторонами соединения, использующими Microsoft РРР, перечислены в таблице 7-17. Таблица 7-17. LCP-параметры ВАР Имя параметра
Тин
Длина Описание
ВАР Link Discriminator
23, или 0x17
4
Уникальный номер, идентифицирующий отдельные каналы МР-соединения
Протоколы МР и ВАР включаются на сервере удаленного доступа через вкладку РРР (РРР) окна свойств сервера удаленного доступа (в оснастке Routing and Remote Access). Параметры многоканального подключения и ВАР настраиваются на вкладке Multilink (Многоканальное подключение) в свойствах профиля политики удаленного доступа.
ГЛАВА 7
Сервер удаленного доступа
271
^- Чтобы задать телефонный номер порта, посылаемый в ВАР-сообщенин Call-Response: 1. Запустите оснастку Routing and Remote Access (Маршрутизация и удаленный доступ) и откройте окно свойств объекта Ports (Порты). 2. Выберите требуемый порт и щелкните кнопку Configure (Настроить). 3.
Введите номер телефона в поле Phone number of this device (Номер телес юна этого устройства).
ВАСР ВАСР (Bandwidth Allocation Control Protocol) — это РРР-протокол NCP, согласующий единственный параметр, который определяет предпочтительную сторону соединения. Если обе стороны, поддерживающие МР и ВАР, одновременно посылают ВАР-сообщения Call-Request или Link-Drop-Query-Request, то выполняется запрос от предпочтительной стороны. РРР-идентификатор протокола ВАСР — ОхС02В. Структура ВАСР-пакетов точно повторяет структуру LCP-пакетов (с тем исключением, что определены лишь типы 1-7). В случае ВАСР-пакетов Configure-Request, Configure-Ack, Configure-Nack и Configure-Reject раздел данных ВАСР состоит из единственного параметра ВАСР, показанного в таблице 7-18. Таблица 7-18. ВАСР-параметр Favored-Peer Имя параметра
Тип
Длина
Описание
Favored-Peer
1
6
Случайным образом присваиваемый 4-байтовый волшебный номер, который используется для выбора предпочтительной стороны (предпочтительной считается сторона с наименьшим волшебным номером)
Сервер удаленного доступа и поддержка групповой IP-рассылки Сервер удаленного доступа Windows 2000 также поддерживает пересылку группового IP-трафика между клиентами удаленного доступа и сетями, к которым подключен данный сервер удаленного доступа. Поддержка групповой IP-рассылки для клиентов удаленного доступа требует трех элементов, показанных па рис 7-17. 1. На интерфейсе, к которому подключаются все клиенты удаленного доступа, должен быть включен режим IGMP-маршрутизатора. В оснастке Routing and Remote Access это интерфейс Internal (Внутренний). 2. На отдельном интерфейсе должен быть включен режим IGMP-прокси. 3. Сеть, соответствующая интерфейсу, на котором включен режим IGMP-прокси, должна быть частью сети, поддерживающей пересылку группового 1Р-трафика. В такой сети для передачи группового IP-трафика от источников, расположенных в любой сети, узлам, расположенным и любой сети, используются протоко-
272
ЧАСТЬ 2
Удаленный доступ
льт многоадресной маршрутизации. Например, та часть Интернета, где поддерживается пересылка группового IP-трафика, называется Multicast Backbone, или MB one. Работает в режиме IGMP-маршрутизатора Сервер удаленного доступа
Клиент удаленного доступа
Г Работает в режиме IGMP-прокси
Внутренний адаптер Сеть с поддержкой пересылки группового IP-трафика
Рис. 7-17. Поддержка групповой IP-рассылки при удаленном доступе Подробнее о групповой IP-рассылке и ее поддержке в Windows 2000 Server см. главу \ «Поддержка групповой IP-рассылки» в ;-зтой книге. Примечание В зависимости от вариантов, выбранных Вами в Routing and Remote Access Server Setup Wizard (Мастер настройки сервера маршрутизации и удаленного доступа), режимы IGMP-марптрутизатора и IGMP-прокеи могут быть уже включены на соответствующих интерфейсах.
Групповой трафик, направляемый клиентам удаленного доступа Для пересылки группового IP-трафика от источников в сети с соответствующей поддержкой к клиентам удаленного доступа нужно, чтобы: • группы, прослушиваемые клиентами удаленного доступа, были зарегистрированы на маршрутизаторах группового IP-трафика, находящихся в сети с поддержкой пересылки группового IP-трафика; • групповой IP-трафик от источников пересылался клиентам удаленного доступа. Регистрация клиента удаленного доступа в группе Клиенты удаленного доступа регистрируют адреса групповой IP-рассылки, с которых они хотят получать трафик, путем посылки IGMP-сообщения Membership Report черен соединение удаленного доступа. Сервер удаленного доступа записывает группы рассылки, регистрируемые каждым клиентом удаленного доступа, и пересылает IGMP-сообщение Membership Report через интерфейс, работающий в режиме IGMP-прокси. Это сообщение принимают маршрутизаторы группового IP-трафика, подключенные к тому сегменту сети, с которым соединен сервер удаленного доступа. Маршрутизаторы с помощью протоколов многоадресной маршрутизации создают записи в
ГЛАВА 7
Сервер удаленного доступа
273
своих таблицах многоадресной пересылки для перенаправления группового трафика, адресованного группам (зарегистрированным клиентами удаленного доступа), в сегмент сети с сервером удаленного доступа.
Пересылка группового трафика Когда источник посылает групповой трафик в группы, зарегистрированные клиентами удаленного доступа, маршрутизаторы группового IP-трафика пересылают ,»тот трафик в сегмент сети сервера удаленного доступа на интерфейс, работающий в режиме IGMP-прокси. Когда на этот интерфейс поступает групповой трафик, сервер проверяет, зарегистрирован ли какой-нибудь из подключенных клиентов удаленного доступа в да! пой группе многоадресной рассылки. Если полученный трафик относится к группе, зарегистрированной клиентом удаленного доступа, он пересылается клиенту,
Групповой трафик, передаваемый от клиентов удаленного доступа Для пересылки группового IP-трафика от клиентов удаленного доступа нужно, чт.>бы: •
группы, прослушиваемые хостами, были зарегистрированы на маршрутизаторах группового IP-трафика, находящихся в сети с поддержкой пересылки гру : [нового IP-трафика; • групповой IP-трафик от клиентов удаленного доступа пересылался членам групп. Регистрация хоста в группе Хосты в сети с поддержкой пересылки группового IP-трафика регистрируют IPадреса групповой рассылки, с которых они хотят получать трафик, путем посылки IGMP-сообщений Membership Report в своих локальных сегментах сети. Маршрутизаторы группового ТР-трафика с помощью протоколов многоадресной маршрутизации создают записи в своих таблицах многоадресной пересылки для перенаправления группового трафика, адресованного группам (зарегистрированным хостами), в сегменты сети соответствующих хостов. Пересылка группового трафика Когда клиент удаленного доступа посылает групповой'трафик через соединение удаленного доступа, этот трафик пересылается в сегмент сети сервера удален шго доступа на интерфейс, работающий в режиме IGMP-прокси. Маршрутизаторы группового IP-трафика в этом сегменте сети принимают пересылаемый групповой трафик и перенаправляют его в сетевые сегменты членов групп. Кроме того, сервер удаленного доступа пересылает групповой IP-трафик от одних клиентов удаленного доступа другим (если они прослушивают такой трафик).
Передача группового IP-трафика через Интернет Если сервер удаленного доступа используется для предоставления доступа в Интернет клиентам, которые подключаются но коммутируемой линии, то пересылать групповой IP-трафик от клиентов и обратно позволит следующая конфигурация. 1. Сервер удаленного доступа имеет прямое (или непрямое по логическому туннелю) к МВопе. ЮЗак. Л43
274
ЧАСТЬ 2
Удаленный доступ
2. Интерфейс, соответствующий прямому или непрямому подключению к МВопе, добавляется к протоколу маршрутизации IGMP и переключается в режим IGMP-прокси. 3. К протоколу маршрутизации IGMP добавляется интерфейс Internal (Внутренний), и на нем включается режим IGMP-маршрутизатора.
Передача группового IP-трафика через интрасеть организации Если сервер удаленного доступа используется для предоставления доступа в интрасеть клиентам, которые подключаются по коммутируемой линии, то пересылать групповой IP-трафик от клиентов и обратно позволит следующая конфигурация. 1. У сервера удаленного доступа имеется LAN-интерфейс, подключенный к интрасети организации с поддержкой групповой IP-пересылки. 2. LAN-интерфейс, подключенный к иптрасети организации, добавляется к протоколу маршрутизации IGMP и переводится в режим IGMP-прокси. 3. К протоколу маршрутизации IGMP добавляется интерфейс Internal (Внутренний), на котором включается режим IGMP-маршрутизатора.
Выявление и устранение проблем Выявление и устранение проблем с удаленным доступом заключается в проверке возможности IP-соединений, адресации, маршрутизации и телефонного оборудования. Вы должны хорошо разбираться в каждой из перечисленных областей. В следующих разделах поясняются наиболее частые проблемы, возникающие при организации удаленного доступа, и рассматриваются средства Windows 2000, предназначенные для устранения таких проблем. О выявлении и устранении проблем с VPN-соединениями см. главу 9 «Виртуальные частные сети» в этой книге; о выявлении и устранении проблем, относящихся к маршрутизации с соединением по требованию, см. главу 6 «Маршрутизация с соединением по требованию» в этой книге.
Наиболее распространенные проблемы с удаленным доступом При удаленном доступе нередко возникают следующие проблемы: • запрос на соединение отклоняется, хотя должен быть принят; • запрос на соединение принимается, хотя должен быть отклонен; • адреса за сервером удаленного доступа недостижимы; • прочие проблемы с удаленным доступом. Далее будут даны рекомендации по устранению ошибок в конфигурации или инфраструктуре, вызывающих проблемы при организации удаленного доступа. Запрос на соединение отклоняется, хотя должен быть принят •
Убедитесь, что на сервере удаленного доступа работает служба маршрутизации и удаленного доступа.
• •
Убедитесь, что удаленный доступ разрешен на сервере удаленного доступа. Убедитесь, что порты сервера удаленного доступа сконфигурированы па прием входящих подключений удаленного доступа.
ГЛАВА 7
Сервер удаленного доступа
275
Убедитесь, что клиент и сервер удаленного доступа, на котором действует политика удаленного доступа, используют хотя бы один общий метод аутентификации и/или шифрования. Убедитесь, что параметры запроса на соединение согласуются с текущими параметрами входящих звонков в пользовательской учетной записи и в политиках удаленного доступа. Для успешного установления соединения параметры в запросе на соединение должны; • соответствовать всем условиям по крайней мере одной политики удаленного доступа; • предоставлять право на удаленный доступ либо через Allow access (Разрешить доступ) в пользовательской учетной записи, либо через Control access through Remote Access Policy (Управление на основе политики удаленного доступа) в пользовательской учетной записи и Grant remote access permission (Предоставить право удаленного доступа) в политике удаленного доступа; • соответствовать всем параметрам профиля; • соответствовать всем параметрам входящих звонков в свойствах пользовательской учетной записи. Убедитесь, что настройки в профиле политики удаленного доступа не конфликтуют со свойствами сервера удаленного доступа. Профиль политики удаленного доступа и свойства сервера удаленного доступа предусматривают настройки для: • многоканальных подключений; • протокола ВАР; • протоколов аутентификации. Если настройки в профиле соответствующей политики удаленного доступа конфликтуют со свойствами сервера удаленного доступа, запрос на соединение будет отклонен. Например, если в профиле указан протокол аутентификации 1IAPTLS, но этот протокол в свойствах сервера удаленного доступа не включен, последний будет отклонять запросы на соединение. Если сервер удаленного доступа является рядовым сервером в домене Windows 2000, который работает в смешанном или основном режиме и сконфигурирован на аутентификацию через Windows 2000, убедитесь, что: •
в службе каталогов Active Directory имеется группа безопасности RAS and IAS Servers (Серверы RAS и IAS). Если этой группы нет, создайте ее, указав тип Security (Безопасность) и область действия Domain local (Локальная доменная); • у группы безопасности RAS and IAS Servers имеется разрешение на чтение объекта RAS and IAS Servers Access Check; • учетная запись компьютера сервера удаленного доступа включена в группу безопасности RAS and IAS Servers. Для просмотра текущих регистрации используйте команду netsh ras show registeredserver, а для регистрации сервера в определенном домене — команду netsh ras add registeredserver.
276
ЧАСТЬ 2
Удаленный доступ
Если Вы добавляете компьютер сервера удаленного доступа в группу безопасности RAS and IAS Servers или удаляете из нее, изменения не вступают в силу немедленно (из-за особенностей кэширования информации службы каталогов Active Directory в Windows 2000). Чтобы изменения немедленно вступили в силу, перезагрузите этот компьютер. Убедитесь, что телефонное оборудование работает нормально. Убедитесь, что на сервере удаленного доступа есть свободные порты. Убедитесь, что LAN-протоколы, используемые клиентами удаленного доступа, настроены либо на маршрутизацию, либо на удаленный доступ. Проверьте в удостоверениях клиеша удаленного доступа правильность имени и пароля пользователя, а также имени домена и убедитесь, что они могут быть проверены сервером удаленного доступа. В случае соединений, для которых используется MS-CHAP vl и осуществляется попытка договориться о шифровании по методу МРРЕ с 40-битным ключом, убедитесь, что длина пароля не превышает 14 символов. Убедитесь, что пользовательская учетная запись не отключена или не заблокирована (в свойствах этой записи). Если срок действия пароля для данной учетной записи истек, убедитесь, что клиент удаленного доступа использует MSCHAP vl или MS-CHAP v2. (MS-CHAP vl/v2 — единственный протокол аутентификации в Windows 2000, который дозволяет сменить просроченный пароль в процессе установления соединения.) Если истек срок действия пароля в учетной записи уровня администратора, переустановите пароль, используя учетную запись другого администратора. Убедитесь, что пользовательская учетная запись не заблокирована из-за блокировки учетной записи, предназначенной для удаленного доступа. Если сервер удаленного доступа настроен на использование статического пула IP-адресов, проверьте, достаточно ли адресов в пуле. Если все адреса из статического пула уже выделены клиентам удаленного доступа, сервер удаленного доступа не сможет назначить очередной IP-адрес. Если клиент удаленного доступа сконфигурирован на использование только TCP/IP в качестве LAN-протокола, запрос на соединение будет отклонен. Если клиент удаленного доступа требует выделить ему определенный номер IPX-узла, убедитесь, что сервер удаленного доступа разрешает это делать. Если сервер удаленного доступа настроен на диапазон номеров IPX-сетей, убедитесь, что эти номера не используются где-нибудь в другой части межсетевой IPX-среды. Проверьте конфигурацию службы аутентификации. Сервер удаленного доступа может быть настроен на аутентификацию удостоверений клиентов удаленного доступа либо через Windows, либо через RADIUS. Если сервер удаленного доступа является рядовым сервером в домене Windows 2000 смешанного или основного режима, убедитесь, что он присоединился к домену. Если сервер удаленного доступа под управлением Windows NT 4.0 с Service Pack 4 и выше является членом домена Windows 2000 смешанного режима или если
ГЛАВА 7
Сервер удаленного доступа
279
Регистрация учетной и аутентификационной информации Сервер удаленного доступа под управлением Windows 2000 поддерживает регистрацию учетной и аутентификационной информации для подключений удаленного доступа в локальных файлах журналов, если Вы выбрали аутентификацию или учет через Windows. Соответствующие журналы ведутся отдельно от системных журналов. Эта информация позволяет отслеживать попытки аутентификации и использование сетевых ресурсов клиентами удаленного доступа. Она особенно полезна при устранении каких-либо проблем с политиками удаленного доступа. Для каждой попытки аутентификации в журнал записывается имя политики удаленного доступа, благодаря которой запрос на соединение был принят или отклонен, Аутентификационная и учетная информация хранится в файле или файлах журнала в папке %5у$£етЙоо£% \System32\LogFiles. Эти файлы записываются в формате IAS 1.0 или 2.0. Формат IAS 2.0 совместим с ODBC-форматом баз данных, и в этом случае любая программа, работающая с базами данных, может напрямую считывать файл журнала для последующего анализа. Если сервер удаленного доступа настроен на аутентификацию или учет через RADIUS и сервером RADIUS является компьютер под управлением Windows 2000 и Internet Authentication Service (Служба проверки подлинности в Интернете), учетная и аутентификационная информация записывается в файлы в папке %Sysstem32\LogFiles па компьютере — сервере IAS*.
Протоколирование событий На вкладке Event logging (Журнал событий) окна свойств сервера удаленного доступа предлагается четыре уровня протоколирования. Выберите переключатель Log the maximum amount of information (Вести журнал всех событий) и повторите попытку соединения. Как только попытка закончится неудачей, проверьте, какие события были зарегистрированы в системном журнале при попытке соединения. Просмотрев события, выберите на вкладке Event logging переключатель Log errors and warnings (Вести журнал ошибок и предупреждений).
Трассировка Средства трассировки записывают последовательность вызываемых функиий в файл. Разрешите применение трассировки для записи детальной информации о процессах, выполняемых при установлении соединения компонентами удаленного доступа, и повторите попытку соединения. Закончив трассировку и просмотрев нужную информацию, верните параметрам трассировки исходные значения. Вы можете включить трассировку РРР на вкладке Event logging (Журнал событий) окна свойств сервера удаленного доступа. Трассировочная информация может оказаться сложной и очень детальной. Часть ее полезна только инженерам службы технической поддержки Microsoft или сетевым администраторам, имеющим большой опыт работы со службой маршрутизации и удаленного доступа. Трассировочную информацию можно сохранить в виде файлов и послать в службу технической поддержки Microsoft для анализа.
* Это требует проверки, так как в аналогичном разделе главы 2 утверждается, что данная информация дублируется на сервере IAS. — Прим. перев.
280
ЧАСТЬ 2
Удаленный доступ
Network Monitor Network Monitor (Сетевой монитор) — это программа для захвата пакетов и их анализа, которая позволяет наблюдать за трафиком, передаваемым между сервером и клиентом удаленного доступа в процессе установления соединения. Network Monitor не анализирует сжатый или шифрованный трафик, передаваемый через соединения удаленного доступа. Правильная интерпретация трафика в процессе установления удаленного соединения с помощью Network Monitor требует понимания протоколов РРР, рассмотренных в этой главе. Информацию, захваченную Network Monitor, можно сохранить в виде файлов и послать в службу технической поддержки Microsoft для анализа.
ГЛАВА
8
Служба проверки подлинности в Интернете
Служба проверки подлинности в Интернете (Internet Authentication Service, IAS) это Microsoft-реализация сервера RADIUS (Remote Authentication Dial-In User Service). Служба IAS выполняет централизованную аутентификацию, авторизацию, аудит и учет (authentication, authorization, auditing and accounting, AAAA) для соединений по коммутируемым линиям и через виртуальные частные сети (virtual private networks, VPN). Эту службу можно использовать в сочетании со службой маршрутизации и удаленного доступа Windows 2000. Служба IAS позволяет работать с оборудованием удаленного доступа или VPN как от одного, так и от нескольких поставщиков. В этой главе
Обзор 282 Протокол RADIUS 286 Аутентификация в IAS 294 Авторизация в IAS 314 Учет в IAS 327 Аутентификация в IAS и режимы работы доменок Windows Некоторые вопросы безопасности 331 Настройка и оптимизация 332 Выявление и устранение проблем 333
328
См, также • Об удаленном доступе — главу 7 «Сервер удаленного доступа» в этой книге. • О виртуальных частных сетях — главу 9 «Виртуальные частные сети» в этой книге, • О политиках безопасности — книгу «Распределенные системы? из серии «Ргсурсы Microsoft Windows 2000 Server».
282
ЧАСТЬ 2 Удаленный доступ
Обзор Провайдеры услуг Интернета (Internet service providers, ISP) и корпорации, поддерживающие удаленный доступ для своих сотрудников, все острее нуждаются в централизованном управлении различными видами удаленного доступа независимо от типа применяемого оборудования. Стандарт RADIUS поддерживает такую функциональность как в однородных, так и в гетерогенных сетевых средах. RADIUS — это клиент-серверный протокол, превращающий аппаратные средства удаленного доступа в клиенты RADIUS, передающие серверам RADIUS запросы на аутентификацию и регистрацию учетной информации. Сервер RADIUS имеет доступ к информации об учетных записях пользователей и поэтому может проверять удостоверения удаленных клиентов. Если удостоверения пользователя являются подлинными (аутентичными) и запрос на соединение успешно авторизован, сервер предоставляет пользователю доступ в рамках заданных для него ограничений и регистрирует подключение удаленного доступа как событие учета. Применение RADIUS позволяет хранить информацию, необходимую для аутентификации, авторизации и учета удаленных клиентов, централизованно, а не на каждом сервере доступа в сеть (network access server, NAS). Пользователи подключаются к RADIUS-совместимым серверам NAS (в их роли выступают компьютеры под управлением Windows 2000 Server и службы маршрутизации и удаленного доступа), которые в свою очередь пересылают запросы на аутентификацию централизованному серверу IAS. Подробнее о протоколе RADIUS см. RFC 2138 и 2139. Служба IAS также позволяет компаниям использовать имеющуюся у провайдеров услуг Интернета инфраструктуру удаленного доступа, оставляя за собой контроль над аутентификацией, авторизацией и учетом клиентов удаленного доступа. Служба IAS поддерживает разнообразные конфигурации с использованием Интернет-технологий: • • • •
удаленный доступ к сети по коммутируемой линии; доступ к экстрасети для партнеров по бизнесу; доступ в Интернет; аутсорсинговое управление корпоративным доступом через ISP.
Примечание Компании может предоставлять доступ к определенной части ресурсов своей сети другим компаниям, с которыми заключены партнерские соглашения. Служба IAS позволяет ограничивать доступ к сетевым ресурсам корпорации на основе ограничений, определенных для каждого партнера.
Возможности 1AS Ниже перечислены основные возможности службы IAS. Централизованная аутентификация пользователей Аутентификация пользователей, пытающихся установить соединение, — важный элемент в обеспечении безопасности. IAS поддерживает множество протоколов
ГЛАВА 8 Служба проверки подлинности в Интернете
283
аутентификации, что позволяет использовать любой метод аутентификации, соответствующий Вашим требованиям. В Windows 2000 служба IAS поддерживает следующие методы аутентификации, • РРР (Point-to-Point Protocol) — набор стандартных протоколов разбиения на кадры и аутентификации, обеспечивающий взаимодействие программных решений удаленного доступа в гетерогенной сетевой среде. TAS поддерживает такие РРР-протоколы аутентификации, как PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) версий 1 и 2, а также ЕАР (Extensible Authentication Protocol). •
EAP (Extensible Authentication Protocol) — инфраструктура поддержки ноиых (произвольных) методов аутентификации, например через смарт-карты, сертификаты, одноразовые пароли или Token Cards.
• DNIS (Dialed Number Identification Service) — метол аутентификации на основе телефонного номера, набранного пользователем. •
ANI/CLI (Automatic Number Identification/Calling Line Identification) — метод аутентификации на основе телефонного номера, с которого зионит пользователь. Метод ANI также называется идентификацией звонящего (Caller ID).
• Аутентификация гостя — метод, при котором звонящий в процессе аутентификации не сообщает имя и пароль пользователя. Если разрешен неаутентйфицируемый доступ, то но умолчанию в качестве идентификации звонящего используется учетная запись Guest (Гость), Дутсорсинговый удаленный доступ Аутеорсинговый удаленный доступ (outsourced dialing) подразумевает заключение договора между организацией или частной компанией (заказчиком) и ISP, по условиям которого сотрудники компании могут подключаться к сети ISP до установления VPN-туннеля с частной сетью своей компании. Когда сотрудник подключается к серверу удаленного доступа ISP, аутентификационная информация и данные1 об использовании сети пересылаются па сервер IAS компании. Последний дает возможность управлять аутентификацией пользователей, отслеживать использование сетевых ресурсов и контролировать доступ сотрудников к сети ISP. Преимущество аутсорсинга в потенциальной экономии средств. Так. используя маршрутизаторы, серверы доступа к сети и линии Т1 Интернет-провайдера вместо покупки собственных, можно сэкономить значительные средства на оборудовании (инфраструктуре). Устанавливая связь с ISP, поддерживающим роуминг или подключения к так называемым точкам присутствия (points of presence) других ISI* можно существенно снизить расходы на междугородные звонки. Таким образом, возложив поддержку системы на провайдера, Вы исключите большую статью расходов из своего бюджета. Централизованная авторизация пользователей Чтобы предоставить пользователю соответствующий доступ к сети, служба IAS аутентифицирует пользователей в доменах Windows NT 4.0 и в локальной базе данных Security Accounts Manager (SAM) (Диспетчер учетных записей безопасности) Windows 2000. Кроме того, IAS поддерживает новые возможности Active Directory
284
ЧАСТЬ 2 Удаленный доступ
например основные имена пользователей (user principal names) и универсальные группы. Политики удаленного доступа позволяют сетевым администраторам более гибко управлять предоставлением прав на удаленный доступ к Вашей сети. С ростом численности персонала в организации метод управления доступом на основе разрешений в учетных записях каждого пользователя становится неудобен, хотя технически возможен. В таких случаях гораздо аффективнее использовать политики удаленного доступа. Эти политики дают возможность контролировать удаленный доступ на основе самых разнообразных условий, например; • принадлежности пользователя к той или иной группе безопасности Windows 2000; • времени суток или дня недели; • типа несущей среды, через которую осуществляется подключение пользователя (например, ISDN, коммутируемая линия или VPN-туннель); • типа протокола VPN-туннелирования (РРТР или L2TP); • телефонного номера, на который поступает вызов пользователя; • телефонного номера, с которого поступает вызов пользователя. В каждой политике удаленного доступа имеется профиль (набор настроек), с помощью которых Вы управляете параметрами соединения. Например, Вы можете: •
разрешать или запрещать использование определенных методов аутентификации; • задавать время простоя до разрыва соединения; • указывать максимальную продолжительность одного сеанса; • управлять количеством каналов, используемых в сеансе многоканального подключения; • определять параметры шифрования данных; • добавлять фильтры пакетов для управления доступом пользователей к сети (фильтры пакетов позволяют контролировать, с каких IP-адресов, хостов и портов пользователю разрешается передавать или принимать пакеты); • создавать обязательный туннель, который заставляет туннелировать все пакеты, передаваемые по данному соединению через Интернет в частную сеть; • выбирать, как назначаются IP-адреса клиентским компьютерам пользователей - по их запросу или Вашим сервером удаленного доступа. Централизованное администрирование серверов удаленного доступа Поддержка стандарта RADIUS позволяет IAS контролировать параметры соединений для любого сервера доступа в сеть, использующего тот же стандарт. Кроме того. RADIUS дает возможность поставщикам средств удаленного доступа создавать собственные расширения, называемые особыми атрибутами вендоров (vendor-specific attributes, VSA). В словаре вендоров службы IAS уже реализован ряд таких расширений.
ГЛАВА 8
Служба проверки подлинности в Интернете
285
Централизованный аудит и учет Поддержка стандарта RADIUS позволяет JAS собирать в одном месте записи об использовании сетевых ресурсов (учетную информацию), посылаемые сервером NAS. IAS регистрирует в файлах журналов данные аудита (например, успешные и неудачные попытки аутентификации) и учета (например, записи о входе в систему и выходе из нее). IAS поддерживает такой формат журналов, благодаря которому соответствующую информацию можно напрямую импортировать R какую-либо базу данных. Анализ этих данных возможен и с помощью программного обеспечения от сторонних разработчиков. Интеграция со службой маршрутизации и удаленного доступа Служба маршрутизации и удаленного доступа в Windows 2000 конфигурируется на аутентификацию и учет через Windows или RADIUS. При выборе аутентификации и учета через RADIUS можно использовать любой сервер RADIUS, совместимый со стандартами RFC. Однако для достижения оптимального уровня интеграции с Windows 2000 и использования преимуществ централизованных политик удаленного доступа рекомендуется установить сервер IAS. Так, в небольшой сети или в филиалах с малым числом серверов удаленного доступа, где не требуется централизованного управления удаленным доступом, службу маршрутизации и удаленного доступа можно настроить па аутентификацию и учет через Windows. В транснациональных корпорациях с большим числом серверов удаленного доступа, развернутых по всему миру, централизованная аутентификация и учет с помощью IAS дают очевидные выгоды. Однако, если малый филиал подключается к централизованному серверу IAS транснациональной корпорации по узкополосному каналу, конфигурацию аутентификации и учета через Windows можно скопировать из центрального участка на серверы удаленного доступа этого филиала. IAS и служба маршрутизации и удаленного доступа используют одни и те же политики удаленного доступа и средства регистрации аутентификационной и учетной информации. Если служба маршрутизации и удаленного доступа настроена на аутентификацию через Windows, используются локальные политики и журнал. А если она работает как RADTUS-клиент сервера IAS. используются политики и журнал па сервере IAS. Такая интеграция обеспечивает согласованную работу IAS и службы маршрутизации и удаленного доступа. В небольших сетях можно обойтись одной службой маршрутизации и удаленного доступа, не развертывая отдельный, централизованный сервер IAS. по возможность перехода на модель централизованного управления удаленным доступом в случае укрупнения сети все равно сохраняется. Тогда IAS вместе с серверами удаленного доступа позволит реализовать единую точку администрирования различных видов удаленного доступа к Вашей сети — аутсорсинп »вого, с соединением по требованию, через VPN. Политики, действующие в рамкг.х IAS, можно экспортировать с центрального сайта на независимый сервер удаленного доступа, находящийся на небольшом сайте. Графический пользовательский интерфейс IAS предоставляет графический интерфейс (в виде оснастки), позволяющий настраивать локальные или удаленные серверы IAS.
286
ЧАСТЬ 2
Удаленный доступ
Удаленный мониторинг Мониторинг 1AS можно вести либо средствами Windows 2000, например с помощью Event Viewer (Просмотр событий) и System Monitor (Системный монитор), либо средствами SNMP (Simple Network Management Protocol). Масштабируемость IAS применима в разных по своим масштабам сетевых конфигурациях — от малых сетей до больших корпоративных сетей или сетей ISP. IAS SDK IAS Software Development Kit (SDK) можно использовать для:
• управления числом сетевых сеансов пользователей; • расширения возможностей IAS в авторизации; • экспорта данных аудита и учетной информации в какую-либо базу данных; • создания собственных методов аутентификации для IAS (отличных от ЕАР). ЕАР SDK Этот SDK позволяет использовать произвольные методы аутентификации на основе ЕАР.
Импорт/экспорт конфигурации для управления несколькими серверами IAS Конфигурация IAS импортируется или экспортируется командой netsh.
Протокол RADIUS RADIUS (Remote Authentication Dial-In User Service) — промышленный стандарт служб авторизации, идентификации, аутентификации и учета для сетей с поддержкой удаленного доступа. Клиент RADIUS (обычно сервер удаленного доступа по коммутируемой линии, установленный у провайдера услуг Интернета) пересылает информацию о пользователе серверу RADIUS, который проверяет достоверность учетных данных, предоставленных клиентом. Подробнее о протоколе RADIUS см. RFC 2138 и 2139.
Процесс аутентификации через RADIUS Процесс аутентификации через RADIUS начинается с предоставления удаленным пользователем аутентификационной информации клиенту RADIUS. Получив такую информацию, клиент RADIUS может проверить ее подлинность средствами RADIUS. Например, когда удаленный пользователь посылает свои удостоверения по протоколу CHAP, клиент RADIUS генерирует пакет Access-Request, содержащий такие атрибуты, как имя и пароль пользователя, идентификатор клиента и идентификатор порта, к которому обращается клиент. При наличии пароля CHAP шифрует его методом RSA MD5. RADIUS-пакет Access-Request посылается на сервер RADIUS. Если в течение определенного времени ответ fie приходит, запрос повторяется заданное число раз. Если основной сервер RADII'S не работает или недоступен, клиент RADIUS мо-
ГЛАВА 8
Служба проверки подлинности в Интернете
287
жет перенаправить запрос дополнительному серверу RADIUS. Обращение к дополнительному серверу возможно после определенного числа неудачных попыток связаться с основным сервером или поочередно то к основному, то к дополнительному серверу. При использовании службы маршрутизации и удаленного доступа можно добаиитъ несколько серверов RADIUS с разным приоритетом. Если основной сервер RADIUS (с наивысшим приоритетом) не отвечает в течение 3 секунд, служба маршрутизации и удаленного доступа автоматически переключается на следующий сервер RADIUS (с меньшим приоритетом). Получив запрос, сервер RADIUS аутонтифицирует клиент RADIUS, проверяя, передан ли RADIUS-пакет Access-Request подлинным клиентом RADIUS. Если это так и клиент RADIUS поддерживает цифровые подписи, сервер проверяет цифровую подпись в пакете, используя общий секрет. (Что такое общий секрет, см. в разделе «Аутентификация в IAS» далее в этой главе.) Запрос от клиента RADIUS, с которым у сервера RADIUS нет общего секрета, просто игнорируется. Если клиент RADIUS подлинный, сервер RADIUS обращается к базе данных учетных записей пользователей и ищет запись, имя пользователя в которой совпадает с именем, указанным в запросе. Учетная запись пользователя содержит список условий, которые нужно соблюсти, чтобы данный пользователь получил разрешение на подключение. Если хотя бы одно условие в процессе аутентификации или авторизации не выполнено, сервер RADIUS отвечает клиенту RADIUS пакетом Access-Reject, сообшая, что запрос от данного пользователя следует отклонить. Если все условия выполнены, клиент RADIUS получает пакет Access-Accept со списком значений конфигурационных параметров — атрибутов RADIUS и всех настроек, необходимых для получения пользователем запрещенного сервиса. В случае SLIP и РРР к таким параметрам относятся IP-адрес, маска подсети, MTU, пастройки сжатия данных, идентификаторы требуемых фильтров пакетов.
Формат RADIUS-пакетов Здесь представлена информация, которая может пригодиться при: • диагностике на основе трассировочной информации, полученной с помощыо Network Monitor; • ознакомлении с различными форматами пакетов для анализа журнала учета; • вводе номеров особых атрибутов вендоров. RADIUS-пакеты посылаются на сервер RADIUS как UDP-сообщения через UDPпорты 1812 (для аутентификации) и 1813 (для учета). Некоторые старые серверы доступа в сеть используют с теми же целями соответственно UDP-порты 1645 и 1646. IAS поддерживает прием RADIUS-сообщений на оба набора UDP-портов. В качестве полезной нагрузки в UDP-сообщение инкапсулируется только один RADIUS-пакет.
Общая структура пакетов Общая структура RADIUS-пакетов показана на рис. 8-1.
288
ЧАСТЬ 2
Удаленный доступ Код
Идентификатор Длина Аутентификационная информация Ш
J •- L
1
, 1^
баи
™
Атрибуты
ПРис. 8-1. Общая структура RADIUS-пакета
Код Однобайтовое поле, указывающее тип RADIUS-пакета. Пакет с недопустимым значением в этом поле игнорируется. Значения, определенные для поля кода, перечислены в таблице 8-1. Таблица 8-1. Значения поля кода в RADlUS-пакете Код (десятичный)
Пакет
i
Access-Request
'.'
Access-Accept
3 4 5 11 12 13 255
Access-Reject Accounting-Request Accounting-Response Access-Challenge Status-Server (экспериментальный) Status-Client (экспериментальный) Зарезервировано
Идентификатор Однобайтовое поле, используемое для сопоставления запроса с соответствующим ответом. Длина Поле длиной в два октета, указывающее полный размер пакета и RADIUS-сообщения, в том числе полей кода, идентификатора, длины и аутентификационной информации, а также раздела атрибутов. Значение этого ноля может варьироваться от 20 до 4096 байтов. Аутентификационная информация Поле длиной в шесть октетов, содержащее информацию, на основе которой клиент и сервер RADIUS аутентифицируют друг друга. Атрибуты Раздел атрибутов RADIUS-пакета содержит один или более атрибутов RADIUS, которые указывают параметры аутентификации и авторизации, а также конфигурационную информацию. Если у атрибута имеется более одного экземпляра, необходимо соблюдать порядок следования экземпляров. А если у атрибута только один экземпляр, порядок следования не имеет значения.
ГЛАВА 8
Служба проверки подлинности в Интернете
289
Атрибуты RADIUS Структура атрибута RADIUS показана на рис. 8-2. Атрибуты RADIUS имеют формат «тип-длина-значение», часто применяемый и в других протоколах. Тим Длина
Значение
Ц = 1 байт Рис. 8-2. Структура атрибута RADIUS
Тип Однобайтовое поле, указывающее тип атрибута RADIUS. Некоторые атрибуты геречислены в таблице 8-2. О других атрибутах RADIUS и их предназначении см. RFC 2138 и 2139; о новых атрибутах RADIUS см. ссылку Radius Types на странице Web Resources по адресу http://wmdows.microsoft.com/windows2000/reskit/webresources. Таблица 8-2. Типы атрибутов RADIUS
Тип
Описание
I
User-Name User- Pass word С HAP- Password NAS- IP- Address NAS-Port. Service-Type Framed- Protocol Framed -IP- Address Framed- IP-Netmask Framed -Routing Filter-ID Framed -MTU Framed- Compression Reply -Message State Class Vendor- Specific Session-Timeout Idle-Timeout Termination-Action NAS-Identifier NAS-Port-Typc Port- Urn it
2
3 4 5 1 7 8 9 LO I1 !!
13 19 24 25
26 •'•,
28 29 32 61 1
li .'
290
ЧАСТЬ 2 Удаленный доступ
Типы 192-223 зарезервированы для экспериментальных целей, типы 224-240 специфичны для конкретной реализации, а типы 241-255 зарезервированы и вообще не используются. Тип 26 зарезервирован для особых атрибутов вендоров. Длина Поле, указывающее длину атрибута (вместе с его полями типа, длины и значения). Значение Поле длиной в ноль или несколько октетов, содержащее информацию, специфичную для конкретного атрибута. Формат и длина этого ноля зависят от типа атрибута.
Особые атрибуты вендоров Особые атрибуты вендоров (vendor specific attributes, VSA) позволяют поставщикам использовать собственные атрибуты, не определенные в RFC 2138. В словаре вендоров службы IAS содержатся VSA от различных поставщиков. Этот список постоянно пополняется новыми атрибутами и вендорами. Чтобы использовать атрибуты, не включенные в словарь вендоров, IAS предусматривает возможность их добавления как атрибутов Vendor-Specific (тип 26) на вкладке Advanced (Дополнительно) профиля политики удаленного доступа. Для использования атрибута типа 26 администратору нужно знать его формат и точное значение. Форматы VSA описываются ниже, а информацию о том, какие данные следует вводить для конкретного VSA, см. в документации на Bain сервер NAS. Структура особого атрибута вендора показана на рис. 8-3. Тип И =26 Длина Идентификатор вендора [00_ Строка
=1 байт
Рис. 8-3. Структура особого атрибута вендора Тип
Значение этого поля устанавливается в 26 (OxlA), что указывает на атрибут VSA. Длина Значение этого поля зависит от числа байтов в атрибуте VSA. Идентификатор вендора Поле длиной в 4 октета, где старший октет всегда равен 0 (0x00), а младшие 3 октета представляют код SMI (Structure and Identification of Management Information) Network Management Private Enterprise Code вендора. Строка Это поле состоит из одного или более октетов. В соответствии с рекомендациями RFC 2138 поле строки должно состоять из полей, показанных на рис. 8-4.
ГЛАВА 8
Служба проверки подлинности в Интернете
291
Тип вендора Длина строки Данные, специфичные для конкретного атрибута
Рис. 8-4. Структура поля строки Тип вендора Идентифицирует конкретный VSA. Длина строки Сообщает размер строки в байтах. Данные, специфичные для конкретного атрибута Содержит данные особого атрибута вендора. Вендоры, атрибуты которых не соответствуют RFC 2138, идентифицируют свой VSA как тип 26, но не используют поля, показанные на рис. 8-4. В этом случае формат особого атрибута вендора соответствует формату, приведенному на рис. 8-3. Добавляя VSA для конкретного сервера NAS как тип 26, Вы должны знать, соответствует ли этот атрибут RFC 2138. Информацию о том. использует ли Ваш сервер NAS формат VSA, приведенный на рис. 8-4, см. в документации на этот сервер Атрибуты VSA настраиваются в диалоговом окне Vendor-Specific Attribute Information (Сведения об атрибуте вендора); о том, как открыть данное диалоговое окш >, см. раздел «Профили вендоров» далее в этой главе. Если формат VSA соответствует RFC 2138, выберите переключатель Yes, it conforms (Да, соответствует) и настройте поля атрибута, как указано в документации на Ваш сервер NAS. Если формат VSA не соответствует RFC 2138, выберите переключатель No, it does not conform (Нет, не соответствует) и введите шестнадцатеричное значение атрибута, которое включает строку в формате VSA (все, что находится за полем идентификатора вендора); подробнее о настройке особых атрибутов вендоров см. раздел «Профили вендоров* далее в этой главе.
Пример RADfUS-пакета Допустим, клиент РРТР под управлением Windows 2000 пытается создать соеди нение удаленного доступа с VPN-сервером под управлением Windows 2000. IP-адрес VPN-сервера - 10.10.210.13, а сервера IAS - 10.10.210.12. Пакет Access-Request В трассировочной информации, полученной с помощью Network Monitor и показанной ниже, можно увидеть содержимое пакета Access-Request, посланного VPNсервером серверу IAS. + IP: ID = 0x850; Proto = UDP; Len: 248 + UDP: Src Port: Unknown, (1327); Dst Port: Unknown (1812); Length = 228 COxE4) RADIUS: Message Type: Access Requestd) RADIUS: Message Type = Access Request RADIUS: Identifier = 2 (0x2)
292
ЧАСТЬ 2
Удаленный доступ
RADIUS: Length = 220 (OxDC) RADIUS: Authenticates = 8A 6F DC 03 23 5F 4B 62 CA 40 92 38 DC 75 CB 74 RADIUS: Attribute Type: NAS IP Address(4) RADIUS: Attribute type = NAS IP Address RADIUS: Attribute length = 6 (0x6) RADIUS: HAS IP address = 10,10.210.13 RADIUS: Attribute Type: Service Type(6) RADIUS: Attribute type = Service Type RADIUS: Attribute length = 6 (0x6) RADIUS: Service type = Framed RADIUS: Attribute Type: Framed Protocol(7) RADIUS: Attribute type = Framed Protocol RADIUS: Attribute length = 6 (0x6) RADIUS: Framed protocol = PPP RADIUS: Attribute Type: NAS Port(5) RADIUS: Attribute type = NAS Port RADIUS: Attribute length = 6 (0x6) RADIUS; NAS port = 32 (0x20) RADIUS: Attribute Type: Vendor Specific(2B) RADIUS: Attribute type = Vendor Specific RADIUS'. Attribute length = 12 (OxC) RADIUS; Vendor ID = 311 (0x137) RADIUS: Vendor string = n RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 18 (0x12) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = MSRASV5.00 RADIUS: Attribute Type: NAS Port Type(61) RADIUS; Attribute type = NAS Port Type RADIUS: Attribute length = 6 (0x6) RADIUS: NAS port type * Virtual RADIUS: Attribute Type; Tunnel Type(64) RADIUS: Attribute type = Tunnel Type RADIUS: Attribute length = 6 (0x6) RADIUS: Tag = 0 (0x0) RADIUS: Tunnel type = Point-to-Point Tunneling Protocol(PPTP) RADIUS; Attribute Type: Tunnel Media Type(65) RADIUS: Attribute type - Tunnel Media Type RADIUS: Attribute length = 6 (0x6) RADIUS: Tag = 0 (0x0) RADIUS: Tunnel media type = IP (IP version 4) RADIUS: Attribute Type: Calling Station ID(31) RADIUS: Attribute type = Calling Station ID RADIUS: Attribute length = 14 (OxE) RADIUS: Calling station ID = 10.10.14.226 RADIUS: Attribute Type: Tunnel Client Endpoint(66) RADIUS: Attribute type = Tunnel Client Endpoint RADIUS: Attribute length = 14 (OxE) RADIUS: Tunnel client endpoint = 10.10.14.226 RADIUS: Attribute Type: User Named) RADIUS: Attribute type = User Name RADIUS: Attribute length = 18 (0x12) RADIUS: User name = NTRESKIT\Johndoe
ГЛАВА 8
Служба проверки подлинности в Интернете
293
RADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 24 (0x18) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = QM1/2+-_;en$+fN
294
ЧАСТЬ 2
Удаленный доступ
RADIUS: Attribute length = 51 (0x33) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = ПRADIUS: Attribute Type: Vendor Specific(26) RADIUS: Attribute type = Vendor Specific RADIUS: Attribute length = 21 (0x15) RADIUS: Vendor ID = 311 (0x137) RADIUS: Vendor string = Атрибуты RADIUS, переданные сервером IAS, содержат имя пользователя, тип сервиса, протокол разбиения на кадры, класс сервиса, а также набор особых атрибутов вендора для аутентификации по MS-CHAP.
Аутентификация в IAS В процессе идентификации удаленных пользователей и их допуска в защищенную сеть или на сайт разные аспекты этой задачи выполняются разными серверами. Сервер доступа в сеть (Network Access Server, NAS) выступает в роли клиента сервера IAS. Этот клиент отвечает за передачу информации о пользователе на заданные серверы IAS и реагирование на получаемые ответы, Сервер TAS отвечает за прием запросов на соединение, аутентификацию пользователей, авторизацию попыток соединения и определение всех конфигурационных параметров, необходимых клиенту RADIUS для предоставления пользователю запрошенного сервиса. Общая схема процесса аутентификации средствами IAS показана на рис. 8-5, Каталог, содержащий учетные данные пользователя
ААА-зэпросы
Конечный пользователь
Сервер каталога
доступа в сеть Сервер IAS
Рис. 8-5. Процесс аутентификации в IAS Когда пользователь пытается подключиться к сети через соединение удаленного доступа по коммутируемой линии или через виртуальную частную сеть (VPN), аутентификация осуществляется следующим образом. 1. Сервер NAS согласует параметры соединения с клиентом удаленного доступа, сначала пытаясь использовать самый защищенный протокол, затем менее защищенный и так до наименее безопасного протокола (например, в такой последовательности: ЕАР, MS-CHAP, CHAP, PAP). 2. Сервер NAS пересылает запрос па аутентификацию серверу IAS в виде RADIUS-пакета Access-Request,
ГЛАВА 8 Служба проверки подлинности в Интернете
295
3. Сервер IAS сначала проверяет, отправлен ли данный RADIUS-пакет AccessRequest тем клиентом RADIUS, на который он настроен, и для этого определяет IP-адрес источника пакета. Если пакет Access-Request отправлен подлинным клиентом RADIUS и этот клиент поддерживает цифровые подписи, то сервер IAS проверяет в пакете цифровую подпись, используя общий секрет. (Общий секрет — это текстовая строка, служащая особым паролем между сервером RADIUS и подключенным к нему клиентом. Общий секрет должен существовать между каждым сервером IAS и сервером NAS или другим сервером IAS, пересылающим RADIUS-пакеты.) Существует ряд правил, соблюдение которых необходимо для успешной настройки общего секрета; • общий секрет должен быть абсолютно одинаковым на обоих серверах; • секреты чувствительны к регистру букв; • 4.
в секретах могут присутствовать стандартные алфавитно-цифровые знаки и любые специальные символы.
Если применение цифровых подписей разрешено, но проверка подписи закончилась неудачей, сервер IAS «молча» отбрасывает соответствующий пакет. Если по истечении заданною периода ожидания сервер NAS не получает ответ, он повторяет попытку, а затем отключает пользователя. Если сервер IAS не можгт подключиться к контроллеру домена или найти домен, к которому относится пользователь, он «молча» отбрасывает пакет. Это позволяет RADIUS-проксп передавать запрос резервному серверу IAS, который таким образом получает возможность попытаться аутентифицировать пользователя на основе доменной базы данных.
5. Если применение цифровых подписей разрешено и проверка подписи прошла успешно, сервер IAS обращается к контроллеру домена Windows 2000, которьш проверяет удостоверения пользователя. 6. Если эти удостоверения действительны, сервер IAS — чтобы определить, можно ли авторизовать запрос на соединение, — сравнивает его параметры с условиями действующих политик удаленного доступа и параметрами входящих звонков в учетной записи пользователя. Если параметры .запроса на соединение отвечают условиям хотя бы одной политики и параметрам входящих звонков, соединение авторизуется, и сервер IAS посылает RADIUS-coo6uj;emie AccessAccept серверу NAS, от которого было получено сообщение Access-Request. Сообщение Access-Accept не только авторизует запрос на соединение, но и указывает параметры соединения, заданные в профиле политики удаленного доступа и в свойствах входящих звонков учетной записи данного пользователя. Сервер NAS интерпретирует эти данные и определяет, какие параметры соединения разрешил использовать сервер IAS. Если же удостоверения недействительны либо запрос на соединение не соответствует условиям хотя бы одной политики или, напротив, соответствует условиям какой-либо политики, запрещающей данному пользователю удаленный доступ, IAS посылает RADIUS-сообщение Access-Reject, и сервер NAS разрывает соединение с пользователем.
296
ЧАСТЬ 2
Удаленный доступ
Аутентификация и авторизация в IAS: шаг за шагом Схема, показанная на рис. 8-6а и рис. 8-66, иллюстрирует, как проходит процесс аутентификации и авторизации средствами IAS. Примечание При настройке службы маршрутизации и удаленного доступа на аутентификацию и авторизацию через Windows упомянутый выше процесс ограничивается этапами 4-14. На этих этапах RADIUS-пакеты не пересылаются. Признак успешного или неудачного проведения аутентификации и авторизации возвращается в качестве значения функции, вызываемой службой маршрутизации и удаленного доступа. Содержимое журнала локальных событий или аутентификации зависит от параметров протоколирования, установленных в свойствах этой службы (см. главу 2 «Служба маршрутизации и удаленного доступа» в этой книге). 1. Проверить RADIUS-пакет. Во входящем пакете Ac cess-Request проверяется IP-адрес источника, цифровая подпись, атрибуты и т. д. 2. Проверить на Auto Reject. Auto Reject используется для немедленной посылки пакета Access-Reject, если атрибут User-Name в пакете Access-Request совпадает с определенным значением. Периодически посылая такие пакеты Access-Request и принимая пакеты Access-Reject (отправляемые в режиме Auto Reject), клиент RADIUS определяет, присутствует ли еще сервер RADIUS в сети. Эти сообщения Access-Reject требуют особой обработки, поскольку их не нужно ни аутентифицировать, ни авторизовать. Кроме того, для них не создается никаких записей в журнале аутентификации, чтобы они попусту не заполняли этот журнал. Для настройки IAS на Auto Reject присвойте параметру Ping User-Name в разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ IAS\Pararaeters имя пользователя — получателя пакетов Access-Reject от Auto Reject. Сообщение Access-Reject посылается, когда атрибут User-Name в пакете Access-Request совпадает со значением параметра Ping User-Name. 3. Идентифици ровать гюлыювател я. Если атрибут User-Name в пакете Access-Request не является именем для Auto Reject, 1AS определяет идентификацию пользователя для последующей аутентификации и авторизации. Обычно идентификацию пользователя описывает строковое значение RADIUS-атрибута User-Name. Если атрибута User-Name нет, пользователь идентифицируется как соответствующий учетной записи Guest (Гость) или учетной записи, которая указывается параметром Default User Identity в разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ Remote Access\Policy. Однако для идентификации IAS может использовать любой атрибут RADIUS. Номер атрибута RADIUS, который служба IAS задействует для идентификации пользователя, указывается в параметре User Identity Attribute в разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy. По умолчанию параметру User Identity Attribute присваивается значение 1, что соответствует RADIUS-атрибуту User-Name. Подробнее о параметре User Identity Attribute см. раздел «Неаутентифицируемый доступ» далее в этой главе.
ГЛАВА 8
Служба проверки подлинности в Интернете
Начало
Записать событие а журнал
I Нет \
Послать пакет Access-Reject
Совпадает ли атрибут User-Name со значением параметра реестра Ping User-Name? 3. Идентифицировать пользователя 4. Разобрать имя 5. Проверить наличие дополнительных средств аутентификации
Послать пакет Access-Reject
Записать в журнал факт неудачной попытки аутентификации
Отказать Принять
Есть ли дополнительные средства?
Применить дополнительные средства Продолжить
6. Проверить наличие блокировки учетной записи удаленного доступа
} Нет
Учетная запись блокирована? 7. Проверить возможность использования MS-CHAP. CHAP и PAP
Рис. 8-fia. Процесс аутентификации и авторизации средствами IAS
297
298
ЧАСТЬ 2
Т Нет
Удаленный доступ
Провести аутентификацию пользователя
Используется ли MS-CHAP. CHAP или PAP? /
>_—Нет-
I
• Да-**
8. Проверить учетную запись пользователя
Аутентификация пппшпя удачно? \/лячнп? прошла
НетДействительна ли учетная запись пользователя? 9. Проанализировать действующие политики
/ ч—„„т.. Т
Подходит ли какая-либо политика?
10. Полунить параметры входящих звонков и объединить их с параметрами профиля 11. Проверить наличие ЕАР
Т Нет
Провести аутентификацию по ЕАР
Возможна ли v
по ЕАР?
Т
">—-—-Нет Аутентификация прошла удачно?
12. Проверить параметры учетной записи пользователя и свойства профиля с : ^~-»—«-мям« Нет • Т да
Позволяют ли эти параметры осуществить подключение? 13. Проверить наличие дополнительных средств авторизации Отказать
| Есть ли Нет дополнительные средства?
<
Применить дополнительные средства
Продолжить 14. Поспать пакет Access-Accept и зарегистрировать успешную попытку аутентификации
Рис. 8-66. Процесс аутентификации и авторизации средствами IAS
ГЛАВА 8
Служба проверки подлинности в Интернете
299
4. Разобрать имя. Разбор имени (name cracking) — это разрешение идентификации пользователя в его учетную запись с применением основных имен пользователя (user principal names), LDAP (Lightweight Directory Access Protocol), составных имен (disiinguished names, DNA), канонических имен и т. д. Получив основное имя, IAS запрашивает Global Catalog (Глобальный каталог) службы каталогов Active Directory. Для ускорения этого процесса копия глобального каталога должна находиться на контроллере домена в пределах того сайта Active Directory, где расположен сервер IAS. Если в идентификации пользователя нет имени домена, IAS добавляет такое имя. По умолчанию это имя домена, в который входит сервер IAS. Имя домеаа, предоставляемое IAS, можно указать в параметре DefaultDomain в разделе реестра HKEy_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\ PPP\ControlProtocols\BuiltIn. 5. Проверить наличие дополнительных средств аутентификации. Проверяется существование дополнительных средств аутентификации, которое представляют собой необязательные компоненты, создаваемые с помощью IAS SDK. Каждый такой компонент возвращает Accept (принять), Reject (отклонить) или Continue (продолжить). Если дополнительный компонент аутентификации возвращает Accept, считается, что пользователь аутентифицирован, и начинается проверка его учетной записи. Если компонент аутентификации возвращает Reject, IAS посылает пакет Access-Reject, и в зависимости от параметров протоколирования неудачная попытка аутентификации фиксируется либо в системном журнале событий, либо в журнале аутентификации IAS. Если компонент возвращает Continue, происходит переключение на следующий компонент. Если других компонентов больше нет, пользователь считается аутентифицирован ным. Дополнительный компонент аутентификации может также возвращать атрибуты RADIUS, которые включаются в пакет Access-Accept. 6. Проверить наличие блокировки учетной записи удаленного доступа. После того как заканчивается работа дополнительных компонентов аутентификации, считывается содержимое реестра на сервере IAS, чтобы выяснить, не блокирована ли учетная запись пользователя. Если да, IAS посылает серверу NAS сообщение Access-Reject и регистрирует в журнале попытку аутентификации. Примечание Блокировка учетной записи пользователя — одна из функций защиты, включаемая через реестр Windows 2000. Она предотвращает словарные атаки против учетных записей пользователей. Подробнее о блокировке учетньи. записей см. главу 7 «Сервер удаленного доступа» в этой книге. Функция блокировки учетных записей удаленного доступа не связана с флажком Account locked out (Отключить учетную запись) на вкладке General (Общие) окна свойств пользовательской учетной записи и не имеет никакого отношения к управлению политиками блокировки учетных записей через политики групп Windows 2000.
300
ЧАСТЬ 2
Удаленный доступ
7. Проверить возможность использования MS-CHAP, CHAP и PAP. Если для аутентификации удаленного клиента используется протокол MSCHAP (версии 1 или 2), CHAP или PAP, IAS обращается к соответствующему подмодулю аутентификации. На основе локальной или доменной базы данных учетных записей проверяются удостоверения пользователя (имя и пароль), а также определяется его принадлежность к группам. Конкретный метод аутентификации зависит от применяемого протокола. Если аутентификация закончилась неудачно, посылается сообщение AccessReject, и в зависимости от параметров протоколирования неудачная попытка аутентификации фиксируется либо в системном журнале событий, либо в журнале аутентификации IAS. Если применяется ЕАР или неаутентифицируемый доступ, процесс аутентификации пользователя пропускается. В случае ЕАР аутентификация осуществляется позже, а в случае неаутентифицируемого доступа — вообще не выполняется. 8. Проверить учетную запись пользователя, Учетная запись, определенная при разборе имени, проверяется на предмет того, не отключена ли она (это не имеет отношения к блокировке) и не истек ли срок действия пароля пользователя. Если учетная запись недействительна, посылается сообщение Access-Reject, и в зависимости от параметров протоколирования неудачная попытка аутентификации фиксируется либо в системном журнале событий, либо в журнале аутентификации 1AS. 9. Проанализировать действующие политики. Для поиска политики удаленного доступа, соответствующей параметрам соединения, анализируются политики удаленного доступа, действующие на сервере IAS. Если подходящая политика не найдена, посылается сообщение AccessReject, и данное событие фиксируется в журнале. Подробнее о политиках удаленного доступа и алгоритме их анализа см. раздел «Политики удаленного доступа* далее н этой главе. 10. Получить параметры входящих звонков и объединить их с параметрами профиля. Параметры входящих звонков в свойствах учетной записи пользователя и своиства профиля подходящей политики удаленного доступа объединяются в набор свойств соединения. И. Проверить наличие ЕАР. Если при попытке соединения используется ЕАР, происходит аутентификация по этому протоколу. Начальное согласование о применении ЕАР требует выбора ЕАР в качестве РРР-протокола аутентификации и указания типа ЕАР. Чтобы убедиться, что использование данного типа ЕАР разрешено, проверяются параметры в профиле соответствующей политики. Если использование выбранного типа ЕАР не разрешено в этом профиле, посылается сообщение AccessReject, и в зависимости от параметров протоколирования неудачная попытка аутентификации фиксируется либо в системном журнале событий, либо в журнале аутентификации 1AS. Если применение выбранного типа ЕАР разрешено, то для него проводится ЕАР-аутентификация. IAS посылает серверу NAS вызов, чтобы начать согла-
ГЛАВА 8
Служба проверки подлинности в Интернете
301
сование ЕАР. При этом взаимодействие между DLL-модулями ЕАР на клиентской и серверной стороне осуществляется путем туннелировапия с использованием протокола RADIUS. По окончании согласования провайдер ЕАР может вернуть атрибуты, отсылаемые серверу NAS в пакете Access-Accept. Если ЕАРаутентификация закончилась неудачей, посылается сообщение Access-Reject, и в зависимости от параметров протоколирования неудачная попытка аутентш шкапии фиксируется либо в системном журнале событий, либо в журнале аутентификации JAS. 12. Проверить параметры учетной записи пользователя и свойства профиля. Чтобы убедиться, что соединение разрешено, параметры входящих звонков в свойствах учетной записи пользователя и свойства профиля соответствующей политики удаленного доступа сравниваются с параметрами запроса на соединение. Если соединение не разрешено, посылается сообщение Access-Reject, j-i в зависимости от параметров протоколирования неудачная попытка аутентификации фиксируется либо в системном журнале событий, либо в журнале аутентификации IAS. 13. Проверить наличие дополнительных средств авторизации. Проверяется наличие дополнительных средств авторизации — необязательных компонентов, создаваемых с помощью IAS SDK. Каждый такой компонент возвращает либо Reject (отклонить), либо Continue (продолжить). Если дополнительный компонент авторизации возвращает Reject, JAS посылает пакет AccessReject, и в зависимости от параметров протоколирования неудачная попытка авторизации фиксируется либо в системном журнале событий, либо в журнале аутентификации JAS. Если компонент возвращает Continue, происходит переключение на следующий компонент. Если других компонентов больше пег, пользователь считается авторизованным. Дополнительный компонент авторизации может также возвращать атрибут],! RADIUS, которые включаются в пакет Access-Accept. 14. Послать пакет Access-Accept и зарегистрировать успешную попытку аутентификации. Если параметры входящих звонков в свойствах учетной записи пользователя, свойства профиля соответствующей политики удаленного доступа и условия, заданные дополнительными компонентами авторизации, разрешают соединение., серверу NAS посылается пакет Access-Accept с набором атрибутов RADIUS, содержащих информацию об ограничениях для данного соединения. Б зависимости от параметров протоколирования удачная попытка аутентификации фиксирует ся либо в системном журнале событий, либо в журнале аутентификации IAS.
IAS и туннелирование Преимущество использования IAS e туннелями в том, что эту службу можно настроить так, чтобы она направляла трафик от клиента через туннель к определенной части корпоративной сети (в зависимости от категории пользователя). Примечание О туннелировании и его применении в Windows 2000 см. главу 9 «Виртуальные частные сети» в этой книге.
302
ЧАСТЬ 2
Удаленный доступ
Туннели создаются различными способами. В следующих разделах поясняются два основных тина туннелирования — произвольное (voluntary tunneling) и принудительное (compulsory tunneling).
Произвольное туннелирование Пользователь или клиентский компьютер может послать VPN-запрос для создания и настройки произвольного туннеля. В этом случае компьютер пользователя является конечной точкой туннеля и работает как клиент туннелирования, Произвольное туннелирование происходит, когда рабочая станция или маршрутизатор использует клиентское программное обеспечение туннелирования для создания VPN-соединения с целевым сервером туннелирования. Для этого на клиентском компьютере должен быть установлен подходящий протокол туннелирования. В ситуации с удаленным доступом по коммутируемой линии клиент должен установить удаленное соединение, прежде чем создавать туннель. Это наиболее распространенный случай. Пример — пользователь услуг доступа в Интернет по коммутируемой линии, который перед тем, как создать туннель через Интернет, должен сначала связаться с провайдером (ISP) и установить соединение с Интернетом. Рис. 8-7 иллюстрирует произвольный туннель, созданный между клиентом удаленного доступа по коммутируемой линии и сервером туннелирования.
Клиент
удаленного доступа
I' i 1 Active Directory
РРР-соединение
RADIUSпрокси
Брандмауэр
Рис. 8-7. Произвольный туннель, созданный удаленным пользователем На рис. 8-7 показано использование IAS в сценарии с аутсорсинговым управлением удаленным доступом для произвольного туннелирования. Клиент удаленного доступа устанавливает по коммутируемой линии соединение с ISP. который обеспечивает всем сотрудникам некоей организации удаленный доступ к ее интрасети. На основе параметров соединения сервер NAS, с которым соединился удаленный клиент, формирует пакет Access-Request и посылает его на заданный компьютер RADIUS-прокси. RADIUS-прокси, исходя из содержимого атрибута User-Name, пересылает этот пакет серверу 1AS организации, доступной в Интернете через брандмауэр. Ее сервер IAS аутентифицирует и авторизует запрос удаленного клиента на соединение и возвращает RADIUS-прокси пакет Access-Accept. RADIUS-прокси
ГЛАВА 8
Служба проверки подлинности в Интернете
303
пересылает этот пакет серверу NAS провайдера, и тот подключает клиента к Интернету. После подключения к Интернету клиент удаленного доступа инициирует создание туннеля с сервером туннелирования организации. На основе параметров соединения сервер туннелирования генерирует пакет Access-Request н посылает его на сервер IAS. Последний аутентифицирует и авторизует запрос клиента туннелирования на соединение и возвращает серверу туннелирования пакет Access-Accept. Сервер туннелирования создает туннель, и с этого момента клиент может передавать пакеты в интрасеть организации по туннелю. Примечание Метод аутентификации и стойкость шифрования для соединения удаленного доступа и туннеля могут различаться. Так, для удаленного соединения с ISP может использоваться CHAP, а для туннеля — более безопасный метод аутентификации вроде MS-CHAP v2 или EAP-TLS.
Принудительное туннелирование Принудительное туннелирование — создание защищенного туннеля другим компьютером или сетевым устройством в интересах клиентского компьютера. Принудительные туннели создаются и настраиваются автоматически — без участия пользователя. При принудительном туннелировании конечной точкой туннеля является не клиентский компьютер, а другое устройство, находящееся между клиентским компьютером и сервером туннелирования. Это устройств*} работает как клиент туннелирования. Таким устройством служит сервер удаленного доступа по коммутируемой линии, вызываемый удаленным клиентом. Многие поставщики серверов удаленного доступа предусматривают возможность создания туннелей в интересах клиентов удаленного доступа. Компьютер или сетевое устройство, предоставляющее туннель для клиентского компьютера, в РРТР называется FEP (Frant End Processor), в L2TP - LAC (L2TP Access Concentrator). а в IPSec — IP Security Gateway. В этой главе независимо от протокола туннелирования используется термин FEP. На FKP должен быть установлен подходящий протокол туннелирования; кроме того, он должен быть способен создавать туннель, когда клиентский компьютер пытается установить соединение, Организация может заключить договор с JSP о развертывании набора FEP по всей стране. Эти FEP будут создавать туннели через Интернет с сервером туннелирования, подключенным к частной сети организации, и тем самым консолидировать вызовы с территориально распределенных участков в единую точку Интернет-входа в корпоративную сеть. На рис. 8-8 показан клиентский компьютер, вызывающий сервер NAS провайдера с поддержкой туннелирования с целью аутентификации на сервере IAS, который находится на другом конце туннеля. Рис. 8-8 иллюстрирует применение IAS в сценарии с аутсорсипговым управлением удаленным доступом для принудительного туннелирования. Клиент удаленного доступа устанавливает по коммутируемой линии соединение с ISP, который обеспечивает всем сотрудникам некоей организации удаленный доступ к ее интрасети. На основе параметров соединения сервер NAS. с которым соединился удаленный клиент, формирует пакет Access-Request и посылает его на заданный сервер IAS.
304
ЧАСТЬ 2
Удаленный доступ
Сервер IAS провайдера авторизует запрос удаленного клиента на соединение и возвращает пакет Access-Accept с набором атрибутов туннелирования. При необходимости сервер NAS провайдера создает через Интернет туннель с сервером туннелирования организации.
Active Directory
Клиент удаленного доступа
Клиент туннелирования Туннель Сервер IAS
Рис. 8-8. Принудительный туннель, созданный сервером NAS, который поддерживает туннелирование Примечание Обычно IAS обеспечивает как аутентификацию, так и авторизацию. Однако в данном случае сервер IAS Интернет-провайдера, как правило, отвечает только за авторизацию. Поскольку клиент удаленного доступа проходит аутентификацию на сервере тунпслирования организации, в аутентификации на сервере IAS провайдера нет необходимости. Далее сервер NAS провайдера передает клиенту удаленного доступа РРР-сообщение о перезапуске процесса аутентификации, чтобы этот клиент мог пройти аутентификацию на сервере туннелирования своей организации. Клиент удаленного доступа посылает аутентификационную информацию на сервер NAS провайдера, который инкапсулирует эти данные и посылает их по туннелю на сервер туннелирования. Получив аутентификационную информацию, сервер туннелирования посылает серверу IAS организации пакет Access-Request. Сервер IAS организации аутентифицирует и авторизует соединение удаленного доступа с сервером туннелирования и посылает пакет Access-Accept на сервер туннелирования, который после этого принимает запрос на соединение от клиента удаленного доступа. Теперь все данные, посылаемые клиентом удаленного доступа, автоматически передаются через туннель на сервер туннелирования с использованием сервера NAS провайдера. Такое туннелирование называется принудительным потому, что клиент вынужден использовать туннель, созданный FEP. Как только соединение установлено, весь сетевой трафик от клиента автоматически передается по туннелю. Сервер IAS можно настроить так, чтобы он заставлял FEP для разных клиентов удаленного доступа создавать туннели с разными серверами туннелирования. В отличие от произвольных туннелей принудительные туннели между FEP и сервером туннелирования могут совместно использоваться несколькими клиентами
ГЛАВА 8
Служба проверки подлинности а Интернете
305
удаленного доступа. Когда второй клиент подключается к сервер}' доступа (FEP) и обращается к адресату, туннель к которому уже с о;* дан, его трафик перелается по существующему туннелю. Примечание Применять RADIUS-прокси при принудительном туннелировании не рекомендуется. Прокси может расшифровать пароль туннеля, так как для шифрования паролей между прокси и сервером IAS используется общий секрет. Для передачи информации о туннелировании от сервера IAS серверу NAS используются следующие атрибуты RADIUS. Только при авторизации: • Tunnel -Private-Group-ID; • Tunnel-Assignment-ID; • Тн nnel - P reteren ce; • Tunnel-Password (с прокси не используется). При авторизации и учете: • Tunnel-Type (PPTP, L2TP и т. д.); • Tunnel-Medium-Type (X.25, ATM, Frame Relay, IP и т. д.); • Tunnel-Client-End point; •
Tunnel-Server-Endpoint.
Только при учете: • Acct-Timnel-Connection. Служба маршрутизации и удаленного доступа Windows 2000 не может выступать в роли FEP при принудительном тупнелировании.
Методы аутентификации Протокол RADIUS поддерживает ряд РРР-протоколов аутентификации. У каждого из них свои плюсы и минусы. Конкретный протокол определяется устройством NAS. Если Вы настраиваете сеть на поддержку удаленного доступа по коммутируе мым линиям, прочтите документацию на свой сервер NAS, а если удаленный доступ к Вашей сети поддерживается через ISP, обратитесь к нему. В следующих разделах рассматриваются преимущества и недостатки протоколои аутентификации, поддерживаемых IAS в настоящее время. Эта информация будет полезна при настройке конкретного протокола аутентификации,
РАР PAP (Password Authentication Protocol) передает пароль от компьютера пользователя устройству NAS в виде строки. NAS, пересылая пароль, шифрует его, используя п качестве криптографического ключа общий секрет RADIUS. PAP — самый гибкий протокол, так как передача нешифрованного пароля на сервер аутентификации позволяет этому серверу оперировать практически с любым форматом данных. Например, пароли UNIX хранятся в виде необратимо зашифрованных строк, и для сравнения паролей РАР с этими строками нужно всего лишь воспользоваться тем же методом шифрования. I! Зак 3345
306
ЧАСТЬ 2
Удаленный доступ
Однако из-за того, что РАР имеет дело с нешифрованными паролями, этот протокол весьма уязвим с точки зрения безопасности. Хотя пароль все же шифруется протоколом RADIUS, по телефонной линии он передается открытым текстом. Включение РАР Чтобы выбрать аутентификацию по протоколу РАР, выполните следующую процедуру. 1. Разрешите применение РАР в качестве протокола аутентификации на сервере удаленного доступа. Об исходных настройках конкретного сервера NAS см. документацию на этот сервер. В службе маршрутизации и удаленного доступа протокол РАР по умолчанию отключен. 2. Разрешите применение РАР в нужной политике удаленного доступа. По умолчанию протокол РАР отключен. 3. Разрешите применение РАР на клиенте удаленного доступа. Примечание Включение РАР в качестве протокола аутентификации означает, что пароль пересылается от клиента серверу NAS открытым текстом. Сервер NAS шифрует пароль, используя общий секрет, и передает его в пакете Access-Request. RADIUS-прокси должен шифровать РАР-пароль на основе секрета, общего с пересылающим сервером RADIUS, и расшифровывать его на основе секрета, общего с сервером NAS. Злоумышленник, получив доступ к RADIUS-прокси, может определить имена и пароли пользователей для РАР-соединений. Таким образом, использовать протокол РАР настоятельно не рекомендуется — особенно при VPN-подключениях.
CHAP CHAP (Challenge Handshake Authentication Protocol) разработан для безопасной передачи паролей. При использовании CHAP сервер NAS посылает клиентскому компьютеру вызов со случайным образом генерируемой строкой. Строка вызова и пароль пользователя хэшируются по MD5. Далее клиентский компьютер посылает хэш на сервер NAS, а тот пересылает серверу аутентификации и строку вызова, и ответ на него в виде RADIUS-пакета Access-Request. Получив этот пакет, сервер аутентификации создаст собственную версию ответа. Если версия сервера совпадает с ответом от клиентского компьютера, запрос на соединение принимается. СНАР-ответы нельзя использовать повторно, так как устройства NAS каждый раз посылают клиенту уникальную строку вызова. Поскольку алгоритм вычислений при генерации СНАР-ответов хорошо известен, очень важно тщательно выбирать пароли и заботиться о том, чтобы их длина была достаточной. Пароли CHAP на основе распространенных слов или имен уязвимы перед словарными атаками. А пароли недостаточной длины могут быть раскрыты простым перебором возможных комбинаций. Исторически сложилось так, что CHAP стал самым распространенным протоколом аутентификации при удаленном доступе. Однако, если на сервере не хранится тот же пароль, что и использованный для генерации СНАР-ответа, создать свою версию ответа этот сервер не сможет. Поскольку для создания ответа на вызов стан-
ГЛАВА 8
Служба проверки подлинности в Интернете
307
дартные СНАР-клиенты используют нешифрованную версию пароля, то и на сервере пароли должны храниться в незашифрованном виде. Хотя сервер IAS поддерживает CHAP, контроллер домена Windows NT 4.0 не может проверять СНАР-запросы без поддержки хранения обратимо шифруемых паролей. Такая поддержки имеется в Windows 2000, а на контроллерах домена Windows NT 4.0 нужно устанавливать специальное обновление. Включение CHAP Чтобы выбрать аутентификацию по протоколу CHAP, выполните следующую процедуру. 1. Разрешите применение CHAP и качестве протокола аутентификации на сервере удаленного доступа. Об исходных настройках конкретного сервера NAS см. документацию на этот сервер. В службе маршрутизации и удаленного доступа протокол CHAP включен по умолчанию. 2. Разрешите применение CHAP в нужной политике удаленного доступа. По умолчанию протокол CHAP включен. 3. Разрешите хранение паролей пользователей в обратимо шифруемом виде. В случае автономного сервера под управлением Windows 2000 Server храпение обратимо шифруемых паролей для всех пользователей данного компьютера следует разрешить через политики групп. В доменах Windows 2000 можно использовать политики групп на уровне доменов или организационных единиц. Об активизации обратимого шифрования паролей см. справочную систему Windows 2000 Server. 4. Принудительно сбросьте пароли для их преобразования в обратимо зашифрованную форму. Когда Вы разрешаете хранение паролей в обратимо зашифрованном виде, пароли, уже хранящиеся в необратимо зашифрованной форме, автоматически не изменяются. Вы должны либо сбросить пароли, либо потребовать смены паролей при следующем входе в систему. Если Вы выбрали второй вариант, пользователи должны войти в сеть через LAN-соединение и сменить свои пароли — только после этого они смогут подключаться к серверу удаленного доступа и аутсптифицироваться по протоколу CHAP CHAP не поддерживает смену паролей в процессе аутентификации, и такие попытки заканчиваются неудачей. Это ограничение можно обойти, временно подключившись к серверу удаленного доступа с использованием MSCHAP, который допускает смену пароля в процессе соединения. 5. Разрешите применение CHAP на клиенте удаленного доступа.
MS-CHAP MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) — разновидность протокола CHAP, tie требующая хранения пароля пользователя на сервере аутентификации в незашифрованном виде. В MS-CHAP ответ на вызов генерируется на основе МО4-хэша пароля и строки вызова сервера NAS. Это обеспечивает аутентификацию через Интернет на контроллере домена Windows 2000 (или Windows NT 4.0 без установки специального обновления). Пароли в MS-CHAP хранятся на сервере более безопасным образом, но, как и пароли в CHAP они уязвимы перед словарными атаками и атаками с подбором паро-
308
ЧАСТЬ 2 Удаленный доступ
лей. Используя MS-CHAP, важно тщательно выбирать пароли (чтобы их не было в стандартном словаре) и заботиться о том, чтобы их длина была достаточной. Многие крупные компании требуют, чтобы длина пароля была не менее шести символов и чтобы в пароле присутствовали буквы верхнего и нижнего регистра, а также минимум одна цифра, О поддержке MS-CHAP можно узнать из документации на сервер NAS или у Интернет-провайдера. Примечание По умолчанию MS-CHAP vl в Windows 2000 поддерживает аутентификацию LAN Manager. Бели Вы хотите отключить такую поддержку в MS-CHAP vl для старых операционных систем вроде Windows NT 3.5 и Windows 95, присвойте нулевое значение параметру Allow LM Authentication в разделе реестра HKEY_LOCAL__MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy иа сервере аутентификации. Если пользователь пытается пройти аутентификацию по MS-CHAP с просроченным паролем, ему предлагается сменить пароль в процессе соединения с сервером. Другие протоколы аутентификации не поддерживают такую возможность, просто блокируя доступ. Включение MS-CHAP Чтобы выбрать аутентификацию по протоколу MS-CHAP, выполните следующую процедуру. 1. Разрешите применение MS-CHAP в качестве протокола аутентификации на сервере удаленного доступа. Об исходных настройках конкретного сервера NAS см. документацию на этот сервер. В службе маршрутизации и удаленного доступа протокол MS-CHAP включен но умолчанию. 2. Разрешите применение MS-CHAP в нужной политике удаленного доступа. По умолчанию протокол MS-CHAP включен. 3. Разрешите применение MS-CHAP na клиенте удаленного доступа. MS-CHAP v2 MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol версии 2) поддерживает взаимную аутентификацию, более стойкие шифровальные ключи и применение раздельных ключей для передачи и приема данных. Для VPN-соединении серверы Windows 2000 предлагают сначала MS-CHAP v2 и только потом более старый протокол MS-CHAP. Клиенты под управлением новых версий Windows всегда соглашаются на использование MS-CHAP v2. если это предлагается сервером. В MS-CHAP v2 используются необратимо шифруемые пароли. Процесс взаимной аутентификации проходит в последовательности, описанной в разделе «MS-CHAP v2*> главы 7 «Сервер удаленного доступа» в этой книге. Если пользователь пытается пройти аутентификацию по MS-CHAP v2 с просроченным паролем, ему предлагается сменить пароль в процессе соединения с сервером. Другие протоколы аутентификации пе поддерживают такую возможность, просто блокируя доступ.
ГЛАВА 8
Служба проверки подлинности в Интернете
309
Включение MS-CHAP v2 Чтобы выбрать аутентификацию по протоколу MS-CHAP v2, выполните следующую процедуру. 1. Разрешите применение MS-CHAP v2 в качестве протокола аутентификация на сервере удаленного доступа. Об исходных настройках конкретного сервера XAS см. документацию на этот сервер. В службе маршрутизации и удаленного доступа протокол MS-CHAP v2 включен по умолчанию. 2. Разрешите применение MS-CHAP v2 в нужной политике удаленного доступа. По умолчанию протокол MS-CHAP v2 включен. 3. Разрешите применение MS-CHAP v2 на клиенте удаленного доступа. Примечание Windows 95 и Windows 98 поддерживают MS-CHAP v2 только для VPN- соединении,
ЕАР ЕАР (Extensible Authentication Protocol) — это расширение РРР (Point-to-point Protocol), поддерживающее клиенты доступа по коммутируемым линиям, а также РРТР- и Е2ТР-клиенты, ЕАР позволяет добавлять новые методы аутентификации, называемые типами КАР. Для успешной аутентификации данный тип ЕАР должен поддерживаться как сервером удаленного доступа, так и клиентом. В Windows 2000 имеется инфраструктура ЕАР и встроено два типа ЕАР: EAP-MD5 CHAP и EAP-TLS. Реализация IAS в Windows 2000 позволяет передавать ЕАР-сообщения на сервер RADIUS (EAP-RADIUS). EAP-MD5 CHAP EAP-MD5 CHAP (Message Digest 5 Challenge Handshake Authentication Protocol) является обязательным типом ЕАР, который использует тот же протокол вызоваответа, что и РРР CHAP, но вызовы и ответы посылаются в виде ЕАР-сообщениЙ, Обычно EAP-MD5 CHAP применяется для проверки удостоверений клиентов уда ленного доступа в системах защиты на основе имен и паролей пользователей. Кроме того, этот тип ЕАР позволяет проверять возможность взаимодействия по ЕАР. ЕДР-TLS EAP-TLS (EAP-Tran.sport Level Security) — тип ЕАР, применяемый в системах защиты на основе сертификатов. Вы должны использовать EAP-TLS, если аутентифицируете клиенты удаленного доступа с помощью смарт-карт. Обмен сообщениями EAP-TLS обеспечивает взаимную аутентификацию, согласование метода шифрования и безопасный обмен закрытыми ключами между клиентом удаленного доступа и сервером аутентификации. EAP-TLS — самый защищенный метод аутентификации и обмена ключами. Он поддерживается только серверами удаленного доступа под управлением Windows 2000, которые входят в домен Windows 2000 основного или смешанного режима. EAP-RADIUS
EAP-RADIUS — это не тип ЕАР, а способ передачи сообщений любого типа ЕАР сервером удаленного доступа на сервер RADIUS для аутентификации. Сообщения ЕАР, пересылаемые между клиентом и сервером удаленного доступа, инкапсулиру-
310
ЧАСТЬ 2
Удаленный доступ
ются и форматируются как сообщения RADIUS, которыми обмениваются сервер удаленного доступа и сервер RADIUS. Подробнее об EAP-RADIUS см. раздел «EAP-RADIUS» главы 7 «Сервер удаленного доступа» в этой книге, Включение ЕАР Чтобы выбрать аутентификацию но ЕАР, выполните следующую процедуру. 1. Разрешите применение ЕАР в качестве протокола аутентификации на сервере удаленного доступа. 2. Разрешите применение ЕАР в нужной политике удаленного доступа. 3. Разрешите применение ЕАР на клиенте удаленного доступа. В дополнение к типам ЕАР, определенным и поддерживаемым в Windows 2000, ЕАР Software Development Kit (SDK) позволяет добавлять новые ЕАР-методы аутентификации,
Неаутентифицируемый доступ Неаутентифицируемый доступ позволяет удаленным клиентам входить в сеть без проверки удостоверений. Например, сервер IAS не будет проверять имя и пароль пользователя. Единственная проверка, выполняемая при таком тине доступа, — авторизация. К использованию неаутентифицируемых соединений следует относиться очень внимательно, так как они предоставляются без проверки идентификации удаленных клиентов. В этом разделе рассматриваются три варианта неаутентифшшруемого доступа: •
гостевой доступ;
• авторизация на основе DNIS (Dialed Number Identification Service); • авторизация на основе AN1/CLI (Automatic Number Identification/Calling Line Identification). Гостевой доступ для РРР-клиентов Гостевой доступ — это возможность входа в домен, не указывая имя пользователя и/или пароль. При этом IAS и служба маршрутизации и удаленного доступа должны быть настроены на поддержку неаутентифицируемого доступа. Когда сервер удаленного доступа получает запрос на соединение, начинается процесс согласования с клиентом метода аутентификации из числа поддерживаемых сервером. Если клиент принимает один из них, он посылает удостоверения, требуемые согласованным методом аутентификации. Если же пользователь отказывается проходить аутентификацию, служба маршрутизации и удаленного доступа проверяет возможность доступа без аутентификации. Если такой доступ разрешен, она пересылает IAS пакет Access-Request. В этом пакете не содержится ни атрибут UserName, ни какие-либо другие удостоверения. IAS, получив пакет Access-Request без атрибута User-Name, считает, что пользователь хочет войти в сеть через гостевой доступ. В этом случае в качестве идентификации пользователя IAS принимает имя гостевой учетной записи в домене. Далее IAS анализирует действующие политики, чтобы найти нужный профиль, Если таковой найден и гостевой доступ & нем разрешен, IAS выполняет остальные операции, связанные с авторизацией, и возвращает пакет Access-Accept. В файле журнала учета регистрируется идентификация пользователя и тип аутентификации,
ГЛАВА 8
Служба проверки подлинности в Интернете
311
Впоследствии на основе этой информации можно будет определить, входил ли пользователь по гостевой учетной записи. Включение гостевого доступа Чтобы разрешить гостевой доступ, выполните следующие операции. 1. Разрешите неаутентифицируемый доступ на сервере удаленного доступа. 2. Разрешите неаутентифицируемый доступ с подходящей политике удаленного доступа. 3. Разрешите использование учетной записи Guest (Гость). 4. В зависимости от административной модели удаленного доступа укажите в остевой учетной записи Allow Access (Разрешить доступ) или Control access through Remote Access Policy (Управление на основе политики удаленного доступа). Если Вы не хотите разрешать использование учетной записи Guest, создайте пользовательскую учетную запись и укажите в пой Allow Access или Control access through Remote Access Policy. Затем на сервере аутентификации (сервере удаленного доступа или сервере IAS) присвоите параметру Default User Identity в разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy имя только что созданной учетной записи. Подробнее о включении и настройке протоколов аутентификации, а также об активизации отключенных пользовательских учетных записей см. справочную систему Windows 2000 Server. Пример гостевого доступа 1. При РРР-согласовании клиент отвергает все протоколы РРР-аутентификации, поддерживаемые NAS. 2. Если NAS настроен на возможность неаутентифицируемого доступа, он посылает пакет Access-Request без атрибута User-Name и без пароля. В службе маршрутизации и удаленного доступа Windows 2000 неаутентифицируемый доступ разрешается на вкладке Authentication* окна свойств сервера в оснастке Ronting and Remote Access (Маршрутизация и удаленный доступ). 3. Так как в пакете Access-Request нет атрибута User-Name, идентификацией пользователя для IAS служит учетная запись Guest (Гость) или значение параметра реестра Default User Identity. 4. С идентификацией пользователя в качестве гостя и попыткой подключения без проверки аутентификация и авторизация проходят так, как это было показано ранее в этой главе. Если параметры запроса па соединение соответствуют какойлибо политике, в профиле которой разрешен доступ без аутентификации, если учетная запись Guest не отключена и если она разрешает удаленный доступ, то JAS посылает серверу KAS пакет Access-Accept. * Такой вкладки в окне свойств сервера удаленного доступа нет. По крайней мере н русской вер сии Windows 2000 Server Вы должны открыть в окне свойств сервера удаленного доступа вкладку Безопасность, щелкнуть кнопку Методы проверки подлинности и в появившемся одноименном диалоговом окне в разделе Доступ без проверки установить флажок Разрешить подключение удаленных систем без проверки. — Прим. персе.
312
ЧАСТЬ 2
Удаленный доступ
Авторизация на основе DNIS Авторизация на основе DNIS (Dialed Number Identification Service) — это метод, при котором авторизация попытки соединения осуществляется на основе; набранного клиентом номера. Соответствующий атрибут называется идентификатором вызываемой станции (Called-Station-TD). DNIS используется большинством телекоммуникационных компаний. Эта служба возвращает набранный телефонный номер получателю вызова. На основе атрибута Called-Station-ID сервер IAS определяет, какие услуги могут быть предоставлены данному клиенту удаленного доступа. Включение авторизации на основе DNIS Для этого выполните следующие операции. 1. Разрешите неаутентифицируемый доступ на сервере удаленного доступа, 2. Создайте на сервере аутентификации (т. е. на сервере удаленного доступа или на сервере IAS) политику удаленного доступа, которая предназначена для DNISавторизации и в которой атрибут Called-Station-ID хранит нужный телефонный номер. 3. Разрешите неаутентифицируемый доступ в свойствах созданной политики удаленного доступа. Авторизация на основе ANI Этот метод авторизации базируется на определении телефонного номера, с которого звонит пользователь. Соответствующий атрибут называется идентификатором вызывающей станции (Calling-Station-ID), или идентификатором звонящего (Caller ID). На основе атрибута Calling-Station-ID сервер IAS определяет, какие услуги могут быть предоставлены данному клиенту удаленного доступа. Авторизация на основе ANI отличается от функции Caller ID (Идентификация звонящего) параметрами входящих звонков в свойствах учетной записи пользователя. ANI-авторизация выполняется в том случае, если пользователь не вводит свое имя или пароль и отказывается от любых поддерживаемых методов аутентификации. Тогда IAS получает атрибут Calling-Station-ID без имени и пароля пользователя. Поддержка авторизации на основе ANI требует, чтобы в Active Directory хранились учетные записи, где вместо имен пользователей указываются их Caller ID (проще говоря, телефонные номера). Эта разновидность аутентификации применяется при удаленном доступе из сетей сотовой связи, а также Интернет-провайдерами в Германии и Японии. Если в учетной записи задано значение свойства Caller ID, то для нхода в сеть пользователь вводит свои учетные данные (имя и пароль) и аутентифицируется по одному из поддерживаемых методов. После аутентификации пользователя на основе его имени и пароля IAS сравнивает атрибут Calling-Station-ID в пакете AccessRequest со свойством Caller ID учетной записи этого пользователя для авторизации запроса на соединение. Включение авторизации на основе ANI \. Разрешите неаутентифицируемый доступ на сервере удаленного доступа. 2. Разрешите неаутентифицируемый доступ в свойствах политики удаленного доступа, созданной для проверки подлинности на основе ANI/CLI.
ГЛАВА 8
Служба проверки подлинности в Интернете
313
3. Создайте пользовательскую учетную запись для каждого номера, с которого звонят удаленные клиенты и для которого Вы хотите настроить авторизацию на основе ANT/CLI. Имя учетной записи должно совпадать с телефонным номером, с которого звонит пользователь. Например, если пользователь звонит с номера 555-0100, создайте учетную запись «5550100». 4. На сервере аутентификации присвойте параметру User Identity Attribute в раздоле реестра HKEY_LOCAL_MACHINE\System\CurrentControISet\Services\ RemoteAccess\Policy значение, равное 31. Этот параметр сообщает серверу аутентификации, что для идентификации звонящего следует использовать его телефонный номер (RADIUS-атрибут 31, Calling-Station-ID). Телефонный номер служит идентификацией пользователя, только если в запросе на соединение отсутствует имя пользователя. Чтобы телефонный номер звонящего всегда применялся в качестве идентж шкации пользователя, на сервере аутентификации присвойте параметру Override User-Name в разделе реестра HKEY__LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\PoIicy значение, равное 1. Учтите: если Вы записываете в параметр Override User-Name значение 1, а в User Identity Attribute — 31, сервер аутентификации выполняет лишь авторизацию на основе AN1/CL1. Обычные протоколы аутентификации типа MSCHAP, CHAP и PAP отключаются. Пример ANI-авторизации В этом пример показано, как осуществляется авторизация на основе ANI/CLI для клиента удаленного доступа, звонящего с номера 55.5-0100 (при этом на сервере аутентификации имеется учетная запись 5550100). 1. При РРР-согласовании клиент отвергает все протоколы РРР-аутентификации, поддерживаемые NAS. 2. Если NAS настроен па возможность неаутентифицируемого доступа, он посылает пакет Access-Request без атрибута User-Name и без пароля. В службе маршрутизации и удаленного доступа Windows 2000 пеаутентифицируемый доступ разрешается на вкладке Authentication* окна свойств сервера в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ). 3. Так как в пакете Access-Request пет атрибута User-Name, a IAS настроена на идентификацию пользователя по атрибуту CalHng-Station-ID, пользователь идентифицируется по учетной записи 5550100. 4. Далее аутентификация и авторизация проходят так, как это было показано рапсе и этой главе. Если параметры запроса на соединение соответствуют какойлибо политике, в профиле которой разрешен доступ без аутентификации, если учетная запись 5550100 не отключена и если она разрешает удаленный доступ, то IAS посылает серверу NAS пакет Access-Accept.
См. предыдущее iтримеча!ше переводчика. — Прим. перев.
314
ЧАСТЬ 2
Удаленный доступ
Авторизация в IAS Администратор может использовать средства авторизации в IAS, чтобы разрешать или запрещать подключения на основе параметров соединения. В следующих разделах подробно рассказывается о настройке политик удаленного доступа и особых атрибутов вендоров.
Политики удаленного доступа В Windows NT 4.0 привилегии на удаленный доступ выдавались исключительно на основе разрешений, связанных с входящими звонками и закрепляемых за пользователем. В Windows 2000 соединения удаленного доступа принимаются на основе свойств входящих звонков в объекте пользователя и политиках удаленного доступа. Политика удаленного доступа — это набор условий и параметров соединения, позволяющих администраторам более гибко выдавать разрешения на удаленный доступ и использование сетевых ресурсов. Политики удаленного доступа хранятся на локальном компьютере и разделяются IAS и службой маршрутизации и удаленного доступа. Используя политики удаленного доступа, администратор может указывать разрешения на основе времени суток, дня недели, принадлежности к группе Windows 2000, типа запрашиваемого соединения (по коммутируемой линии или через VPN) и т.д. Кроме того, можно ограничивать максимальную длительность сеанса, задавать конкретные методы аутентификации и шифрования, настраивать политики ВАР и др. Важно помнить, что запрос на соединение удаленного доступа принимается, только если его параметры совпадают с параметрами хотя бы одной политики удаленного доступа. В ином случае запрос на соединение отклоняется независимо от параметров входящих звонков в свойствах учетной записи данного пользователя. При наличии серверов IAS под управлением Windows 2000 управление политиками удаленного доступа осуществляется через оснастку Routing and Remote Access (Маршрутизация и удаленный доступ), если Вы выбрали аутентификацию черем Windows, или средствами Internet Authentication Service (IAS) (Служба проверки подлинности в Интернете). Примечание Windows 2000 поддерживает нестандартные процессы авторизации, разрабатываемые с помощью IAS SDK.
Локальное и централизованное управление политиками Политики удаленного доступа хранятся локально на сервере удаленного доступа или сервере IAS. Чтобы организовать централизованное управление единым набором политик удаленного доступа для нескольких серверов удаленного доступа или VPN-серверов, Вы должны выполнить следующие операции. 1. Установить на компьютере с Windows 2000 службу IAS в качестве сервера RADIUS. 2. Настроить IAS на клиенты RADIUS, соответствующие серверам удаленного доступа или VPN-серверам под управлением Windows 2000.
ГЛАВА 8 Служба проверки подлинности в Интернете
315
3. Создать на сервере IAS централизованный набор политик, используемый всеми серверами удаленного доступа Windows 2000. 4. Сконфигурировать все серверы удаленного доступа Windows 2000 в качестве клиентов RADIUS сервера IAS. После настройки сервера удаленного доступа в качестве RADIUS-клиента сервера IAS локальные политики удаленного доступа, хранящиеся на этом сервере удаленного доступа, больше не действуют. Централизованное управление политиками удаленного доступа применяется и при наличии серверов удаленного доступа под управлением Windows NT 4.0 и службы Routing and Remote Access Service (RRAS). Сервер Windows NT 4.0 с работающей службой RRAS можно настроить в качестве RADIUS-клиента сервера IAS. (Без службы RRAS на сервере Windows NT 4.0 централизованное управление политиками удаленного доступа не поддерживается.)
Свойства входящих звонков объекта пользователя В Windows 2000 объект пользователя на автономном сервере или сервере, управляемом Active Directory, содержит набор свойств входящих звонков, на основе значений которых определяется, принять или отклонить запрос на соединение от данного пользователя. В случае автономных серверов параметры входящих звонков доступны на вкладке Dial-in (Входящие звонки) окна свойств учетной записи пользователя в оснастке Computer Management (Управление компьютером) или в локальном User Manager (если сервер работает под управлением Windows NT 4.0), В случае серверов на основе Active Directory параметры входящих звонков настраиваются на той же вкладке окна свойств объекта пользователя в оснастке Active Directory Users and Computers (Active Directory - пользователи и компьютеры]. Средство администрирования User Manager из Windows NT 4.0 неприменимо к серверам на основе Active Directory. Ниже перечислены свойства входящих звонков объекта пользователя. •
Remote Access Permission (Dial-in or VPN) [Разрешение на удаленный доступ (VPN или модем)]. Это свойство позволяет либо явно разрешить/запретить удаленный доступ, либо управлять удаленным доступом на основе политик. Даже если доступ явно разрешен, условия политики удаленного доступа, свойства объекта пользователя или параметры профиля могут переопределить данную настройку. Переключатель Control access through Remote Access Policy (Управление на основе политики удаленного доступа) доступен только для объектов пользователей на автономных серверах под управлением Windows 2000 и службы маршрутизации и удаленного доступа или на серверах, входящих в домен Windows 2000 основного режима. По умолчанию в учетных записях Administrator (Администратор) и Guest (Гость) на автономных серверах удаленного доступа или входящих в домен Windows 2000 основного режима это свойство устанавливается как Control access through Remote Access Policy, а в домене Windows 2000 смешанного режима — как Deny access (Запретить доступ), В новых учетных записях, создаваемых на автономных серверах или входящих в домен Windows 2000 основного режима, свойство Remote Access Permission (Dial-in or VPN) устанавдива-
31В
ЧАСТЬ 2
Удаленный доступ
стоя как Control access through Remote Access Policy, а в новых учетных записях, создаваемых в домене Windows 2000 смешанного режима, — как Deny access. • Verify Caller ID (Проверять идентификатор). Если это свойство (представленное в пользовательском интерфейсе флажком) включено, сервер проверяет телефонный номер звонящего. Если он не совпадает с заданным, запрос на соединение отклоняется. Функция идентификации звонящего должна поддерживаться клиентом, телефонной сетью между клиентом и сервером удаленного доступа, а также самим сервером удаленного доступа. Для поддержки этой функции на сервере удаленного доступа необходимо оборудование, отвечающее на вызовы и способное передавать информацию об идентификации звонящего, и соответствующий драйвер в Windows 2000. Если Вы включаете для пользователя функцию идентификации звонящего, но на одном из перечисленных выше участков поддержка передачи информации об идентификации звонящего не реализована, запрос на соединение будет отклоняться. • Callback Options (Ответный вызов сервера). Если это свойство включено, то в процессе установления соединения сервер перезванивает клиенту по указанному номеру. • Assign a Static IP Address (Статический IP-адрес пользователя). Если это свойство включено, то при установлении соединения клиентскому компьютеру присваивается конкретный IP-адрес, назначенный администратором. • Apply Static Routes (Использовать статическую маршрутизацию). Если это свойство включено, серия статических IP-маршрутов, определенных администратором, добавляется и таблицу маршрутизации на сервере удаленного доступа после установления соединения с клиентом. Эта настройка предназначена для учетных записей, используемых маршрутизаторами Windows 2000 для маршрутизации с соединением по требованию. Если сервер Windows 2000 со службой маршрутизации и удаленного доступа входит в домен Windows NT 4.0 или Windows 2000 смешанного режима, то: • из всех свойств входящих звонков доступны лишь Remote Access Permission (Dial-in or VPN) и Callback Options; • для разрешения или запрета удаленного доступа и настройки параметров ответного вызова можно использовать User Manager for Domains (Диспетчер пользователей для доменов). Если сервер является автономным или состоит в домене Windows 2000 основного режима, длина номера ответного вызова не ограничена. Если сервер входит в домен Windows NT 4.0 или Windows 2000 смешанного режима, длина номера ограничена 128 символами. Телефонные номера ответного вызова, длина которых превышает 128 символов, набираются не полностью, и установить соединение ие удается. Когда сервер RAS под управлением Windows NT 4.0 получает параметры входящих звонков учетной записи пользователя из домена Windows 2000 основного режима.
ГЛАВА 8
Служба проверки подлинности в Интернете
317
параметр Control access through Remote Access Policy интерпретируется как Deny access. Параметры ответного вызова распознаются правильно. Сервер RAS под управлением Windows NT 4.0 не поддерживает политики удаленного доступа. Рекомендуется обновить такие серверы до Windows 2000 Server, что позволит использовать преимущества политик удаленного доступа.
Элементы политики удаленного доступа Политика удаленного доступа — ,:>го именованное правило, включающее элементы, которые перечислены ниже. Условия Условия политики удаленного доступа — один или несколько атрибутов, сравниваемых с параметрами запроса на соединение. При наличии нескольких условий все они должны совпадать с параметрами запроса на соединение, а иначе запрос отклоняется. Атрибуты, используемые как условия в политике удаленного доступа, перечислены в таблице 8-3. Таблица 8-3. Атрибуты, используемые как условия в политике удаленного доступа Атрибут
Описание
NAS-IP-Address
JP-адрсс серн ера доступа в есть (KAS). Этот атрибут представляет собой строку символов, передаваемую серверу IAS. Для задания набора IP-сетей используется синтаксис с подстановкой по шаблону. Тип запрашиваемого сервиса. Примеры типов — Framed (для РРР-соедипений) и Login (для Telnet-соединении). Подробнее о типах сервисов RADIUS см. RFC 2138. Этот атрибут предназначен для сервера IAS. Тип разбиения на кадры входящих пакетов. Примеры — РРР, SLIP. Frame Relay и Х.25. Этот атрибут предназначен для сер вера IAS. Телефонный номер NAS. Этот атрибут представляет собой строку символов. Для задания кодов областей можно использовать синтаксис с. подстановкой по шаблону. Чтобы получать информацию об идентификаторе вызываемой станции в процессе вызова, телефонная линия, оборудование и его драйвер должны поддерживать передачу такого идентификатора. В ином случае идентификатор вызываемой станции настраивает ся вручную для каждого порта. Телефонный номер звонящего. Этот атрибут представляет собой строку символов. Для задания кодов областей можно использовать синтаксис с подстановкой по шаблону. Тип несущей среды, используемой звонящим. Примеры — аналоговые телефонные линии (также называемые «asyno), ISDN и туннели (или VPN'). День недели и время суток, когда принимается запрос на соединение. IP-адрес NAS (RADlUS-клиепта). Этот атрибут представляет собой строку символов, передаваемую серверу IAS. Для задания набора IP-сетей используется синтаксис с подстановкой пи шаблону. (см. след, стр.}
Service-Type'
Framed-Pro tocol
Called-Station-ID
Cal!ing-Station-ID
NAS-Port-Type Day-and-Time-Restrictions Ciient-IP-Address
318
ЧАСТЬ 2
Таблица 8-3.
Удаленный доступ
(продолжение)
Атрибут
Описание
N AS-Manufacturer
Изготовитель (вендор) сервера доступа в сеть (NAS), запрашивающего аутентификацию. Сервер удаленного доступа Windows 2000 обозначается как Microsoft RAS NAS, Этот атрибут позволяет настраивать разные политики для разных изготовителей серверов NAS, являющихся RADIUS-клиентами сервера IAS. Атрибут NAS-Manufacturer предназначен для сервера IAS. Имя компьютера RADIUS-клиента, запрашивающего аутентификацию. Этот атрибут представляет собой строку символов, передаваемую серверу IAS. Для задания нескольких имен клиентов можно использовать синтаксис с подстановкой по шаблону. Имена Windows-групп, в которые входит пользователь, выдавший запрос на удаленное соединение. Атрибута, который позволял бы указывать имя конкретного пользователя, нет. Создавать отдельную политику удаленного доступа для каждой группы не обязательно. Вместо этого можно использовать вложенные группы. Для сервера удаленного доступа или сервера IAS, входящего в домен Windows 2000 основного режима, рекомендуется применять универсальные группы. Тип туннеля, создаваемого клиентом. Примеры типов туннелей — РРТР и L2TP, используемые клиентами удаленного доступа и маршрутизаторами с соединением по требованию. Этот атрибут позволяет указывать такие параметры профиля, как методы аутентификации и шифрования для определенного типа технологии туннелирования.
Client-Friendly-Name
Windows-Groups
Tunnel-Type
Примечание Если условия, которые используют атрибут, предназначенный для сервера TAS, сравниваются с параметрами запроса на соединение и совпадение не обнаруживается, соответствующая политика не применяется. Учтите также, что не каждый сервер NAS поддерживает все атрибуты, предназначенные для серверов IAS. Для атрибута Windows-Groups нельзя использовать встроенные локальные группы на автономном сервере удаленного доступа под управлением Windows 2000. Remote Access Permission (Разрешение на удаленный доступ) Если все условия политики удаленного доступа выполняются, клиенту либо предоставляется, либо не предоставляется разрешение на удаленный доступ. Это зависит от того, какой переключатель в свойствах политики выбран — Grant remote access permission (Предоставить право удаленного доступа) иди Deny remote access permission (Отказать в праве удаленного доступа). Разрешение на удаленный доступ, заданное в учетной записи пользователя, имеет преимущество перед разрешением на удаленный доступ, указанным в политике удаленного доступа. Если же в учетной записи разрешение на удаленный доступ указано как Control access through Remote Access Policy (Управление па основе политики удаленного доступа), результат определяется политикой удаленного доступа.
ГЛАВА 8
Служба проверки подлинности в Интернете
319
Проверка разрешения в учетной записи пользователя или политике удаленного доступа — лишь первый шаг в процессе принятия запроса на соединение. Д.ичее проверяются параметры в свойствах учетной записи пользователя и профиля политики. Если параметры запроса на соединение не соответствуют параметрам в свойствах учетной записи пользователя или профиля, запрос на соединение отклоняется. По умолчанию разрешение на удаленный доступ в политике устанавливается как Deny remote access permission. Профиль Профиль политики удаленного доступа— это набор параметров, применяемых к соединению после успешной попытки подключения. Профиль состоит из следующих i-pyrm параметров (эти группы представлены одноименными вкладками в окне свойств профиля); • Dial-in constraints (Ограничения по входящим звонкам); • IP (IP); • Multilink (Многоканальное подключение); • Authentication (Проверка подлинности); • Encryption (Шифрование); • Advanced (Дополнительно). Dial-in constraints
Вы можете задать следующие ограничения на входящие звонки. • Разъединение при простое. Время простоя, по истечении которого связь разрывается. По умолчанию это свойство не установлено, и сервер удаленного доступа не разрывает простаивающее соединение. • Максимальная продолжительность сеанса. Если длительность сеанса превышает это время, сервер удаленного доступа разрывает связь. По умолчанию эти свойство не установлено, и сервер удаленного доступа не ограничивает продолжительность сеанса. • Прием входящих подключений только в определенные дни и время. Дни недели и часы каждого дня, в которые разрешается соединение. Если момент попытки подключения не соответствует заданным ограничениям, запрос на соединение отклоняется. По умолчанию это свойство не установлено, и сервер удаленного доступа не ограничивает дни недели и часы каждого дня, в которые разрешается соединение. Сервер удаленного доступа не разрывает активные соединения, если наступает момент, начиная с которого не разрешается устанавливать подключения. • Вход только по определенному номеру. Телефонный номер, по которому должен звонить клиент удаленного доступа. Если клиент пытается установить соединение с использованием другого номера, запрос на подключение отклоняется. По умолчанию это свойство не установлено, и сервер удаленного доступа разрешает подключения по всем телефонным номерам, доступным для входящих вызовов.
320 •
ЧАСТЬ 2
Удаленный доступ
Входящие звонки только определенных типов. Конкретный тип несущей среды, например аналоговая телефонная линия, ISDN или VPN, который должен использовать вызывающий клиент, чтобы его запрос на соединение был принят. Если клиент пытается установить соединение с использованием другой несущей среды, запрос на подключение отклоняется. По умолчанию это свойство не установлено, и сервер удаленного доступа разрешает входящие вызовы по любой несущей среде.
1
J/ Параметры на вкладке IP позволяют указывать, может ли клиент запрашивать конкретный IP-адрес, По умолчанию сервер удаленного доступа сам назначает IP-адрес, и клиенту не разрешается запрашивать конкретный IP-адрес. Эту вкладку можно использовать и для настройки фильтров в профиле политики удаленного доступа. Фильтры IP-пакетов в профиле ограничивают IP-трафик, передаваемый клиенту и/или принимаемый от клиента, методом исключения: либо разрешается, либо запрещается любой трафик, кроме указанного. Фильтры в профиле политики удаленного доступа применяются ко всем соединениям, соответствующим данной политике.
МиШЫ Вкладка Multilink (Многоканальное подключение) позволяет использовать многоканальные подключения и указывать максимальное число портов, которые может задействовать какое-либо многоканальное подключение. Кроме того, Вы можете настроить политики ВАР, определяющие использование этого протокола и условия, при которых отключаются дополнительные каналы связи. Параметры многоканальных подключений и ВАР специфичны для средств удаленного доступа в Windows 2000. По умолчанию многоканальные подключения не разрешены, а протокол ВАР отключен. Чтобы заданные в профиле параметры многоканальных подключений вступили в силу, на сервере удаленного доступа нужно разреышть многоканальные подключения и включить протокол ВАР. Authentication Вкладка Authentication (Проверка подлинности) позволяет задать типы аутентификации, которые разрешается использовать для соединений, а также выбрать и настроить определенный тип ЕАР. По умолчанию установлены флажки Microsoft Encrypted Authentication (MS-CHAP) [Шифрованная проверка подлинности Microsoft (MS-CHAP)] и Microsoft Encrypted Authentication version 2 (MS-CHAP v2) [Шифрованная проверка (Microsoft, версия 2, MS-CHAP v2)[, Чтобы заданные в профиле параметры аутентификации вступили в силу, на сервере удаленного доступа должны быть разрешены соответствующие методы проверки подлинности.
Encryption Параметры на этой вкладке позволяют включать следующие уровни шифрования. •
No Encryption (Без шифрования). Шифрование не используется. Чтобы потребовать шифрования, выберите любой другой уровень шифрования.
ГЛАВА 8
Служба проверки подлинности в Интернете
321
• Basic (Основное). Для соединений по коммутируемым линиям и чере.ч VPN (па основе РРТР) применяется шифрование по методу МРРЕ (Microsoft Poini-toPntnt Encryption) с 40-битным ключом, а для VPN-соединений на основе L2TP поверх IPSec -- шифрование по алгоритму DES с 40-битным ключом. • Strong (Стойкое). Для соединений по коммутируемым линиям и через VPN (на основе РРТР) применяется шифрование по методу МРРЕ с 56-битным ключом, а для VPN-соединении на основе L2TP поверх IPSec — шифрование по алгоритму DES с 56-битным ключом. • Strongest*. Для соединений по коммутируемым линиям и чере:; VPN (на основе РРТР) применяется шифрование по методу МРРЕ со 128-битным ключом, а для VPN-соединений на основе L2TP поверх IPSec — шифрование по алгоритму 3DES со 128-битным ключом. Advanced Дополнительные параметры предназначены для задания атрибутов RADIUS, передаваемых сервером IAS клиенту RADIUS. Атрибуты RADIUS специфичны для процесса аутентификации черен RADIUS и игнорируются сервером удаленного доступа. По умолчанию атрибут Framed-Protocol установлен как РРР, а атрибут Service-Type— как Framed. Сервер удаленного доступа использует лишь атрибуты Acct-Interim-Interval, Framed-Protocol, Framed-MTU, Reply-Message и Service-Type. Политика удаленного доступа по умолчанию Политика удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения) создается при включении службы маршрутизации и удаленного доступа. Она имеет следующую конфигурацию: • условие Day-and-Time-Restrictions не ограничивает дни недели и время cyroic; •
выбран переключатель Deny remote access permission (Отказать в праве удаленного доступа); • всем параметрам профиля присвоены значения по умолчанию. Примечание Элементы политики удаленного доступа соответствуют атрибутам RADIUS, используемым при аутентификации через RADIUS. В случае сервера IAS убедитесь, что Ваши серверы доступа в сеть передают такие атрибуты RADIUS, которые соответствуют условиям, заданным в политике удаленного доступа и параметрах профиля. Иначе аутентификация через RADIUS .•накапчивается неудачей.
Профили вендоров Чтобы предоставить функциональность, не поддерживаемую стандартными атрибутами, некоторые поставщики используют особые атрибуты вендоров (vendorspecific attributes, VSA). IAS позволяет создавать и изменять VSA. благодаря чему Вам доступны дополнительные возможности тех или иных серверов NAS. * Этот уровень шифрования поддерживается только после установки Microsoft Encryption Pack, подпадающего под действие экспортных ограничений США. — Прим. трев.
322
ЧАСТЬ 2 Удаленный доступ
Если для какого-то профиля требуется настроить более одного VSA, эти атрибуты нужно определенным образом упорядочить. Для упорядочения атрибутов используются кнопки со стрелками. Пример 1 Следующий пример демонстрирует процедуру добавления Cisco VSA в профиль. Здесь просто показывается механизм добавления VSA, отвечающего стандарту (RFC). Особые атрибуты вендора Cisco уже доступны в IAS-словаре вендоров. Особые атрибуты вендора Cisco соответствуют требованиям RADIUS RFC, предъявляемым к особым атрибутам вендоров (тип 26). Далее поясняется, как настроить атрибут Cisco для задания основного DNS-сервера. • Vendor ID (Идентификатор вендора): 9. Это уникальный идентификатор для Cisco. Данное значение устанавливается автоматически, когда Вы выбираете Cisco в качестве вендора. • Vendor Type (Тип вендора): 1. Это номер типа вендора для особых атрибутов вендора, которые имеют формат «атрибут-значение» (обозначаемый в документации Cisco как «cisco-avpair»), •
Data Type (Тип данных): String (Строковый).
•
Format (Формат): если атрибут является обязательным, то формат выглядит как <протокол>: атрибут^значение.
Если атрибут необязательный, он отделяется от значения не знаком равенства, а звездочкой. В этом примере <протокол> - значение Cisco-атрибута «protocol» для конкретного типа авторизации. «Атрибут» и «значение*, представляют соответствующую пару «атрибут-значение» (AV), определенную в спецификации Cisco TACACS+. Это позволяет использовать и для RADIUS полный набор возможностей, доступных при авторизации через TACACS4-. Атрибут Cisco для задания основного DNS-сервера выглядит так: ip:dns-servers=10.10.10.10 ^ Чтобы добавить особый атрибут вендора в профиль входящих звонков: 1. В окне IAS выберите Remote Access Policies (Политика удаленного доступа), 2. Щелкните правой кнопкой мыши имя политики, в которой Вы хотите настроить особый атрибут вендора, и выберите команду Properties (Свойства). 3. Щелкните кнопку Edit profile (Изменить профиль), откройте вкладку Advanced (Дополнительно) и щелкните кнопку Add (Добавить). 4. В списке атрибутов RADIUS дважды щелкните Vendor-Specific (Vendor-Specific). 5. Щелкните кнопку Add (Добавить). 6. В списке раздела Network access server vendor (Вендор сервера удаленного доступа) выберите Cisco. Щелкните переключатель Yes, it conforms (Да, соответствует) и нажмите кнопку Configure Attribute (Настройка атрибута). В поле Vendor-assigned attribute number (Назначенный вендором номер атрибута) введите 1. 8. В поле Attribute format (Формат атрибута) выберите String (Строковый). 7.
9. Б поле Attribute value (Значение атрибута) введите: ip:dns-serversi=10.10.10.10
ГЛАВА 8
Служба проверки подлинности в Интернете
323
Пример 2 Следующий пример иллюстрирует, как добавить в профиль особый атрибут вендора 3Com/U.S. Robotics. Примечание Пример 2 просто демонстрирует, как добавить в профиль VSA, несоответствующий стандарту (RFC). Особые атрибуты вендора ЗСот/'U.S. Robotics уже доступны в IAS-словаре вендоров. Особые атрибуты вендора U.S. Robotics не соответствуют рекомендованному формату VSA (тип 26), описанному в RFC 2138, Таким образом, все особые атрибуты вендора U.S. Robotics следует вводить в шестнадцатеричной форме. Далее поясняется, как настроить атрибут U.S. Robotics для задания основного D\TSсервера. • Vendor ID: 429. Это уникальный идентификатор для U.S. Robotics. Данное значение устанавливается автоматически, когда Вы выбираете U.S. Robotics в качестве вендора. • Indicator: Ox900F. •
Data Type: String.
•
Format: шестнадцатеричный.
^ Чтобы указать IP-адрес 10,10.10.10 для основного DNS/NBNS-сервера: 1.
В окне IAS выберите Remote Access Policies (Политика удаленного доступа).
2. Щелкните правой кнопкой мыши имя политики, в которой Вы хотите настроить особый атрибут вендора, и выберите команду Properties (Свойства). 3. Щелкните кнопку Edit profile (Изменить профиль), откройте вкладку Advanced (Дополнительно) и щелкните кнопку Add (Добавить). 4. В списке атрибутов RADIUS дважды щелкните Vendor-Specific (VendorSpecific) и щелкните кнопку Add (Добавить). 5. В разделе Network access server vendor (Вендор сервера удаленного доступа) щелкните переключатель Select from the list (Выбор из списка) и выберите из списка US Robotics, Inc. 6. Щелкните переключатель No, it doest not conform (Нет, не соответствует) и нажмите кнопку Configure Attribute (Настройка атрибута). 7. В поле Hexadecimal attribute value (Шестнадцатеричное значение атрибута) введите:
0х900т302еЗШ2е31302е31302е Подробнее о нестандартных атрибутах U.S. Robotics см. документацию на Ваше оборудование U.S. Robotics.
Принятие запроса на соединение Когда пользователь пытается установить соединение, его запрос принимается или отклоняется по следующему алгоритму. 1, Проверяется первая политика в списке политик удаленного доступа. Если политик удаленного доступа нет, запрос на соединение отклоняется.
324
ЧАСТЬ 2
Удаленный доступ
2. Если не все параметры запроса на соединение соответствуют данной политике удаленного доступа, проверяется следующая политика. Если политик удаленного доступа больше нет, запрос на соединение отклоняется. 3. Если все параметры запроса на соединение соответствуют политике удаленного доступа, проверяется разрешение на удаленный доступ для данного пользователя. • Если разрешение установлено как Deny access (Запретить доступ), запрос на соединение отклоняется. • Если разрешение установлено как Allow access (Разрешить доступ), применяются параметры, ладанные в учетной записи пользователя и в профиле. •
Если параметры запроса на соединение не соответствуют параметрам учетной записи пользователя и профиля, запрос на соединение отклоняется.
• Если параметры запроса на соединение соответствуют параметрам учетной записи пользователя и профиля, запрос на соединение принимается, •
Если Allow access или Deny access не задано, разрешение должно быть указано как Control access through Remote Access Policy (Управление на основе политики удаленного доступа). Тогда проверяется разрешение на удаленный доступ о политике удаленного доступа.
• Если в политике разрешение установлено как Deny remote access permission (Отказать в праве удаленного доступа), запрос на соединение отклоняется. •
Если в политике разрешение установлено как Grant remote access permission (Предоставить право удаленного доступа), применяются параметры учетной записи пользователя и профиля.
• Если параметры запроса на соединение не соответствуют параметрам учетной записи пользователя и параметрам профиля, запрос на соединение отклоняется. • Если параметры запроса на соединение соответствуют параметрам учетной записи пользователя и профиля, запрос на соединение принимается.
Административные модели политик удаленного доступа Windows 2000 предусматривает три основных модели управления разрешениями на удаленный доступ и параметрами соединений: • доступ на уровне пользователей; • доступ на основе политик в домене Windows 2000 основного режима; • доступ на основе политик в домене Windows 2000 смешанного режима. Доступ на уровне пользователей В этой модели разрешения на удаленный доступ определяются разрешением, заданным на вкладке Dial-in (Входящие зконки) окна свойств учетной записи пользователя. Удаленный доступ разрешается или запрещается для каждого пользователя индивидуально выбором переключателя Allow access (Разрешить доступ) или Deny access (Запретить доступ). Если в свойствах учетной записи пользователя разрешение на удаленный доступ установлено как Allow access или Deny access, оно переопределяет эквивалентное
ГЛАВА 8
Служба проверки подлинности в Интернете
325
разрешение, указанное н политике удаленного доступа. Но параметры соединения определяются условиями политики удаленного доступа и настройками профиля. Удаленным доступом на уровне пользователей можно управлять с1 помощью нескольких политик удаленного доступа. Каждая политика имеет свои параметры профиля. Вы должны крайне осторожно настраивать эти параметры, так как запрос на соединение может отклоняться, даже еслтт в свойствах учетной записи пользователя разрешение на удаленный доступ задано как Allow access. Если запрос на соединение соответствует условиям политики, но не отвечает параметрам профиля (или вообще не соответствует ни одной из политик удаленного доступа), он отклоняется. При применении административной модели доступа на уровне пользователей возможны три ситуации. •
Явное разрешение. Разрешение на удаленный доступ в свойствах учетной записи пользователя установлено как Allow access, и параметры запроса на соединение соответствуют условиям политики, параметрам профиля и параметрам входящих звонков в свойствах учетной записи данного пользователя. • Явный запрет. Разрешение на удаленный доступ в свойствах учетной записи пользователя установлено как Deny access. • Неявный запрет. Параметры запроса на соединение не соответствуют условиям ни одной политики удаленного доступа.
В Windows 2000 административная модель доступа на уровне пользователей эквивалентна управлению удаленным доступом на RAS-сервере Windows NT 4.0. Вы можете применять административную модель доступа па уровне пользователей на автономных серверах, серверах в домене Windows 2000 основного либо смешанного режима или на серверах с домене Windows NT 4.0. Кроме того, эта модель применима на серверах RAS или IAS под управлением Windows NT 4.0, Доступ на основе политик в домене Windows 2000 основного режима В этой модели разрешение на удаленный доступ в свойствах каждой пользовательской учетной записи указывается как Control access through Remote Access Policy (Управление на основе политики удаленного доступа), поэтому реальные разрешения на удаленный доступ определяются параметрами политики удаленного доступа. При применении административной модели доступа на основе пол тик в доме i го Windows 2000 основного режима возможны три ситуации. • Явное разрешение. Разрешение на удаленный доступ и политике удаленного доступа установлено как Grant remote access permission (Предоставить ripaj>o удаленного доступа), и параметры запроса на соединение соответствуют условиям политики, параметрам профиля и параметрам входящих звонков в свойствах учетной записи данного пользователя. • Явный запрет. Разрешение на удаленный доступ в политике удаленного доступа установлено как Deny remote access permission (Отказать в праве удалепниго доступа). • Неявный запрет. Параметры запроса на соединение не соответствуют условия^ ни одной политики удаленного доступа.
326
ЧАСТЬ 2 Удаленный доступ
Если при использовании данной административной модели Вы не добавляете свои политики удаленного доступа и не изменяете политику удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения), удаленный доступ запрещается всем пользователям. Изначально разрешение на удаленный доступ в политике по умолчанию указано как Deny remote access permission (Отказать в праве удаленного доступа). Если Вы смените этот вариант на Grant remote access permission (Предоставить право удаленного доступа), удаленный доступ будет разрешен всем пользователям, Административная модель доступа на основе политик в домене Windows 2000 основного режима применима и на автономном сервере удаленного доступа, не входящем в домен. Однако эта модель не годится при наличии сервера IAS или RAS под управлением Windows NT 4.O. Если Вы применяете административную модель доступа на основе политик в домене Windows 2000 основного режима и не используете группы для определения круга лиц, имеющих право удаленного доступа, убедитесь, что учетная запись Guest (Гость) отключена и что в ее свойствах выбран переключатель Deny access (Запретить доступ). Доступ на основе политик в домене Windows 2000 смешанного режима В этой модели во всех учетных записях пользователей разрешение на удаленный доступ указывается как Allow access (Разрешить доступ), политика удаленного доступа по умолчанию удаляется и создаются новые политики, определяющие разрешенные типы подключений. На сервере удаленного доступа Windows 2000, входящем в домен Windows 2000 смешанного режима, флажок Control access through Remote Access Policy (Управление на основе политики удаленного доступа) в окне свойств пользовательской учетной записи отсутствует. Если параметры запроса на соединение соответствуют условиям политики, параметрам профиля и параметрам входящих звонков в свойствах пользовательской учетной записи, то он принимается. Эта модель применима и для сервера удаленного доступа Windows 2000, входящего в домен Windows NT 4.0. При использовании административной модели доступа на основе политик в домене Windows 2000 смешанного режима возможны три ситуации. •
Явное разрешение. Параметры запроса на соединение соответствуют условиям политики, параметрам профиля и параметрам входящих звонков в свойствах учетной записи данного пользователя.
•
Явный запрет. Параметры запроса на соединение соответствуют условиям политики, но не свойствам профиля. Явный запрет в этой административной модели реализуется установкой флажка Restrict Dial-in to this number only (Разрешить вход только по номеру) на вкладке ограничений на входящие звонки и вводом телефонного номера, заведомо не используемому сервером удаленного доступа.
•
Неявный запрет. Параметры запроса на соединение не соответствуют условиям ни одной политики удаленного доступа.
ГЛАВА 8
Служба проверки подлинности в Интернете
327
Если Вы не удалите политику удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения), псе пользователи получат право удаленного доступа. При наличии серверов Windows NT 4.0 со службой маршрутизации и удаленного доступа административную модель доступа па основе политик в домене Windows 2000 смешанного режима можно использовать, только если эти серверы сконфигурированы как RADI US-клиенты сервера IAS под управлением Windows 2000. Для серверов RAS под управлением Windows NT Л.О эта модель неприменима. Примечание Описанные здесь административные модели являются рекомендуемыми методами управления удаленным доступом. Вы можете использовать их комбинации, но делайте это осторожно. Неправильная настройка может привести к отклонению запросов на соединение, которые должны приниматься, и принятию запросов, которые должны отклоняться. Для устранения проблем в таких сложных конфигурациях Вы дол лены знать логику, по которой сервер удаленного доступа обрабатывает запросы на соединения, или включить протоколирование запросов на аутентификацию, а затем просмотреть журнал. Дополнительную информацию о политиках удаленного доступа и примерах их использования см. в справочной системе Windows 2000 Server.
Учет в IAS В следующем разделе описываются средства учета, поддерживаемые IAS, и форматы файла журнала IAS.
Учет в RADIUS IAS поддерживает протоколирование учетной информации RADIUS, na основе которой администратор может отслеживать использование сетевых ресурсов в целях аудита и биллинга. Средства учета RADIUS позволяют: • собирать учетную информацию в режиме реального времени; • хранить собранную учетную информацию в централизованном хранилище; • использовать для анализа учетной информации RADIUS программные продукты сторонних поставщиков. Если клиент настроен на учет через RADIUS, то в момент предоставления ему какого-либо сервиса он генерирует пакет Accounting Start, описывающий тип предоставляемого сервиса и пользователя, которому этот сервис предоставляется, Пакот посылается на сервер учета RADIUS, который возвращает подтверждение о приеме данного пакета. По окончании использования сервиса клиент генерирует паю т Accounting Stop, описывающий тип предоставленного сервиса и такую статистику (необязательная часть), как длительность использования сервиса, число пходятш х и исходящих октетов или число входящих и исходящих пакетов. Этот пакет передается серверу учета RADIUS, который возвращает подтверждение о его приеме. Пакет Accounting-Request (Start или Stop) направляется серверу учета RADIUS по сети. Если в течение заданного времени ответ не приходит, передача пакета повторяется определенное число раз. Кроме того, в отсутствие ответа от основного сер-
328
ЧАСТЬ 2
Удаленный доступ
вера (если он выключен или недостижим) клиент может пересылать пакеты на дополнительный сервер или серверы. Передама пакетов на дополнительны)! сервер осуществляется либо после заданного числа неудачных попыток связаться с основным сервером, либо поочередно — то основному, то дополнительному серверу. Если серверу учета RADIUS не удается успешно записать учетный пакет, он не посылает клиенту подтверждение о его приеме. Так, если файл журнала переполнен, IAS начинает игнорировать поступающие пакеты с учетными данными. Это заставляет сервер NAS переключиться на резервный сервер IAS.
Файл журнала IAS IAS способна создавать файл журнала на основе данных, возвращаемых серверами доступа в сеть. Эта информация полезна для учета использования сетевых ресурсов и сравнения аутентификационной информации с записями учета (например, для выявления отсутствующих записей или случаев выставления завышенных счетов), IAS поддерживает два формата файла журнала: IAS и базы данных. Формат базы данных позволяет следить за предопределенным набором атрибутов, а формат IAS обеспечивает более высокую степень детализации и содержит информацию обо всех атрибутах. Формат базы данных следует использовать, если Вы хотите импортировать информацию непосредственно в базу данных, а формат IAS — если Вам нужна более детальная информация, не поддерживаемая форматом базы данных. Примечание Файл журнала 1AS содержит все события IAS, связанные с пользователями. События 1AS, относящиеся к системе или самой службе 1AS, записываются в системный журнал событий.
Аутентификация в IAS и режимы работы nniu uno lA/inrimiie доменов Windows В этом разделе основное внимание уделяется средствам аутентификации IAS и их поседению в различных режимах работы доменов Windows. Эта информация полезна при принятии решений о выборе конкретного режима домена, в котором развертывается 1AS. IAS способна аутентифицироиать запросы, принимаемые по протоколу RADIUS в доменах Windows 2000 основного или смешанного режима, доменах Windows NT 4.0 или в локальной базе учетных данных Windows 2000 на автономном сервере IAS. Набор средств аутентификации 1AS, доступный администраторам, зависит от режима домена, в котором проходит аутентификация пользователя.
Домены Windows 2000 основного режима Домен Windows 2000 основного режима обеспечивает наибольшую гибкость в управлении удаленным доступом на основе членства пользователей в группах. • Полное управление разрешениями на удаленный доступ через группы. Администратор может использовать универсальные группы для создания единой политики в отношении пользователей, регистрируемых в разных доменах.
ГЛАВА 8
Служба проверки подлинности в Интернете
329
•
Возможность подключения удаленной сети к корпоративной. Маршруты для удаленной сети определяются как статические. • Поддержка основных имен пользователей (user principal names, UPN). • У конечных пользователей может быть одно и то же UPN независимо от их принадлежности к доменам. Это обеспечивает масштабируемость, необходимую в организациях с большим числом доменов. Ниже приведен список средств аутентификации и управления удаленным доступом, поддерживаемых сервером IAS, который входит в домен Windows 2000 основного режима. •
Параметры входящих звонков в свойствах учетной записи пользователя; • все разрешения на удаленный доступ, в том числе Allow access (Разрешить доступ), Deny access (Запретить доступ) и Control access through Remote Access Policy (Управление на основе политики удаленного доступа); • идентификация звонящего; • параметры ответного вызова; • статический IP-адрес; • статические маршруты. • Поддержка UPN и универсальных групп. • Поддержка EAP-TLS. Чтобы сервер IAS мог обращаться к параметрам «ходящих звонков пользовательских учетных записей, хранящихся в Active Directory, on должен быть включен в группу безопасности RAS and IAS Servers (Серверы RAS и IAS). Для этого Вы можете воспользоваться оснасткой Active Directory Users and Computers (Active Directory - пользователи и компьютеры), зарегистрировать сервер IAS в оснастке Internet Authentication Service (Служба проверки подлинности в Интернете) или ввести команду netsh ras add registereclserver.
Домены Windows 2000 смешанного режима и домены Windows NT 4.0 Домены Windows 2000 смешанного режима используются в основном при переходе с Windows NT 4.0 на Windows 2000. С точки зрения IAS, домен Windows 2000 смешанного режима — то же самое, что и доме!г Windows NT 4.0. Сервер IAS. состоящий в домене Windows 2000 смешанного режима, поддерживает следующие средства аутентификации и управления удаленным доступом. •
Параметры входящих звонков в свойствах учетной записи пользователя: • разрешения удаленного доступа — только Allow access (Разрешить доступ) и Deny access (Запретить доступ). Отсутствие Control access through Remote Access Policy (Управление па основе политики удаленного доступа) усложняет применение групп при управлении па основе политик, так как разрешение на удаленный доступ в учетной записи пользователя имеет боле'; высокий приоритет, чем разрешения в политиках удаленного доступа. Подробнее об управлении па основе политик в доменах смешанного режима см. раздел «Политики удаленного доступа* ранее в этой главе. • Параметры ответного вызова.
330
ЧАСТЬ 2 Удаленный доступ
Как и в доменах Windows 2000 основного режима, сервер IAS получает доступ к параметрам входящих звонков в свойствах пользовательских учетных записей, хранящихся в Active Directory, если компьютер, на котором работает служба IAS, включен в группу безопасности RAS and IAS Servers (Серверы RAS и IAS). Для этого Вы можете воспользоваться оснасткой Active Directory Users and Computers (Active Directory - пользователи и компьютеры), зарегистрировать сервер IAS в оснастке Internet Authentication Service (Служба проверки подлинности в Интернете) или ввести команду netsh ras add registeredserver. Если сервер IAS входит в домен Windows NT 4.0 и пытается аутентифипировать пользователей в доверяемом домене Active Directory, он не получает доступа к Active Directory, так как учетную запись его компьютера нельзя включить в группу безопасности RAS and IAS Servers. Но Бы можете включить группу Everyone (Все) в группу Pre-Windows 2000 Compatible Access. Для этого воспользуйтесь командой net localgroup «Pre-Windows 2000 Compatible Access». В случае отрицательного результата введите команду net localgroup «Pre-Windows 2000 Compatible Access» everyone /add на контроллере домена и перезагрузите его.
Автономные серверы под управлением Windows 2000 Такие серверы можно использовать в очень малых сетях без доменов. Все пользователи определяются в локальной базе учетных данных на автономном сервере. Ниже перечислены средства аутентификации, поддерживаемые автономным сервером IAS под управлением Windows 2000. •
Параметры входящих звонков в свойствах учетной записи пользователя: • вес разрешения на удаленный доступ, в том числе Allow access (Разрешить доступ), Deny access (Запретить доступ) и Control access through Remote Access Policy (Управление на основе политики удаленного доступа); • идентификация звонящего; • параметры ответного вызова; • статический IP-адрес;
• статические маршруты. Автономные серверы Windows 2000 не поддерживают UPN, универсальные группы и KAP-TLS. Параметры входящих звонков в свойствах учетных записей пользователей можно администрировать через Network and Dial-Up Connections (Сеть и удаленный доступ к сети) или Local Users and Groups (Локальные пользователи и группы).
Различия в поведении 1AS под управлением Windows 2000 и Windows NT 4.0 Предыдущая версия IAS поставлялась в составе Windows NT 4.0 Option Pack. Здесь поясняются различия в поведении двух версий IAS.
Поведение IAS в Windows NT 4.0 •
Если в процессе аутентификации не указывается имя домена, сервер IAS проверяет пользователя только по локальной 6aje данных SAM.
ГЛАВА 8 •
Служба проверки подлинности в Интернете
331
Не поддерживаются разрешения ответного вызова для любых объектов пользователей.
• Файлы журнала IAS записываются в кодировке ASCII.
Поведение IAS в Windows 2000 • В процессе аутентификации IAS разрешает имя пользователя без имени домена в следующей последовательности. 1. IAS находит в реестре домен но умолчанию, если таковой указан. 2. Если сервер IAS входит в какой-нибудь домен, аутентификация пользователя осуществляется в домене. 3. Если сервер IAS не входит ни в один домен, аутентификация пользователя осуществляется на основе локальной базы данных SAM. •
Поддерживаются разрешения ответного вызова для любых объектов пользователей,
• Файлы журнала IAS записываются в колировке UTF-8.
Некоторые вопросы безопасности В этом разделе рассматриваются вопросы безопасности IAS и даются рекомендации по устранению возникающих проблем.
RADIUS-прокси Пользователь не должен аутентифицироваться несколькими методами. Иначе возникает риск выбора наименее безопасного метода из числа возможных. Во избежание этого Вы должны определить для каждого пользователя единственный метод аутентификации. Если пользователю нужно применять разные методы аутентификации в разных обстоятельствах, следует назначить ему несколько имен, и с каждым из них сопоставить свой метод аутентификации. Пароли и другие секретные данные должны храниться на обеих сторонах соединения; при этом доступ к такой информации должен быть максимально ограничен. В идеале секреты должны быть доступны только запрашивающему доступ процессу, чтобы можно было выполнить аутентификацию. Круг лиц, имеющих доступ к секретам, следует свести к минимуму. У посторонних лиц не должно быть возможности получить эти секреты.
Брандмауэры Брандмауэр обеспечивает дополнительную защиту любых служб, работающих в какой-либо операционной системе. В качестве брандмауэра может выступать компьютер Windows NT или Windows 2000 с Microsoft Proxy Server или аналогичным программным пакетом от стороннего поставщика. Брандмауэр может работать на том же компьютере, что и сервер IAS. Один из вариантов применения Proxy Server — скрытие IP-адреса сервера. В этом случае IP-адрес сервера IAS представляется IP-адресом прокси-сервера. Кроме того, Вы можете установить брандмауэры от сторонних поставщиков и пропускать только UDP-трафик, который связан с сервером IAS и адресуется на порты, использус-
332
ЧАСТЬ 2
Удаленный доступ
мые сервером RADIUS. Для большей защиты разрешите пропуск трафика к серверу RADIUS лишь с определенных IP-адресов (NAS- иди RADIUS-нрокси).
Блокировка учетной записи удаленного доступа Функция блокировки учетных записей позволяет задавать число неудачных попыток аутентификации, по достижении которого любые попытки подключения по данной учетной записи будут отклоняться. Подробнее о блокировке учетных записей удаленного доступа см. главу 7 «Сервер удаленного доступа» в этой книге.
Настройка и оптимизация 1} этом разделе Вы найдете рекомендации по тонкой настройке службы IAS и ее мониторингу. Здесь же дается информация, которая будет полезна при проверке производительности и работоспособности сервера IAS. При тонкой настройке сервера IAS примите во внимание следующие соображения. •
Если IAS выполняет аутентификацию пользователя на контроллере домена Windows 2000 основного режима, па этом контроллере должен храниться глобальный каталог. • Соединения между серверами MAS и TAS или сервером IAS и контроллером домена с большими задержками могут отрицательно сказаться на длительности процесса аутентификации, а также вызывать повторы передачи данных и таимауты. При использовании IAS в очень крупных средах Интернет-провайдеров (с миллионами удаленных пользователей) в условиях экстремальной нагрузки, когда за одну секунду приходится обрабатывать огромное число запросов на аутентификацию и пакетов учетной информации, следует принять во внимание следующие соображения. •
Число запросов на аутентификацию в секунду, которое сможет обрабатывать IAS, зависит от оборудования, установленного на контроллере домена. Более быстрый контроллер домена обеспечит более высокую пропускную способность, • Подумайте об использовании раздельных серверов IAS для аутентификации и учета. • Рассмотрите возможность работы сервера IAS на контроллере домена с глобальным каталогом. Это снизит задержки в передане данных и увеличит пропускную способность. • Для достижения максимально возможной пропускной способности укажите в соответствующем параметре реестра число запросов на аутентификацию, одновременно обрабатываемых сервером 1AS и контроллером домена. Информацию о нужном параметре реестра см. л справочной системе Windows 2000 Server, • Администратор может развернуть несколько серверов 1AS и использовать Windows Load Balance Service (эта служба имеется только в Windows 2000 Advanced Server) для перенаправления всех серверов NAS на один IP-адрес, представляющий пул серверов IAS.
ГЛАВА 8
Служба проверки подлинности в Интернете
333
Мониторинг производительности и работоспособности сервера IAS Протокол аутентификации RADIUS различает функции клиента и сервера. При аутентификации через RADIUS клиенты посылают пакеты Access-Request, а серверы отвечают пакетами Access-Accept, Access-Reject и Access-Challenge. Устройства NAS обычно выполняют функции клиента и реализуют МПЗ-клиент аутентификации RADIUS; серверы IAS выполняют функции сервера и реализуют МПЗ-сервср аутентификации RADIUS. При мониторинге производительности сервера 1AS чаще всего используются два счетчика оснастки Performance (Производительность): • Access Request/sec (Запросов доступа/сек); • Accounting Request/sec (Запросов учетных данных/сек), Наиболее часто используемые для IAS счетчики описываются в следующем разделе. Подробнее о SNMP МТБ, поддерживаемых IAS, см. главу 10 «SNMP» в книге «Сети TCP/IP* из серии «Ресурсы Microsoft Windows 2000 Server».
Выявление и устранение проблем Здесь представлена информация об устранении проблем в работе IAS и о диагностике с помощью Network Monitor (Сетевой монитор),
Проблемы с конфигурацией IAS В этом разделе кратко рассматриваются типичные проблемы в конфигурациях IAS и методы их устранения. Во всех случаях подлинный пользователь ие может вой ги в сеть, а в Event Viewer (Просмотр событий) показывается одно из следующих сообщений об ошибке. «Unknown user name or bad password» («Неизвестное имя пользователя млн неправильный пароль >) «The specified user does not exist» («Пользователь с указанным именем не существует») «Тпе specified domain does not exist» («Указанный домен не существует») Не исключено, что пользователь ввел неправильное имя или пароль. Проверьте имя и пароль в его учетной записи и убедитесь, что они введены правильно и что эта учетная запись допустима для домена, в котором IAS аутентифицирует данного пользователя. Также возможно, что правила замены сфер (realm replacement rules) заданы неверно или не в том порядке, и из-за этого контроллер домена не распознает имя пользователя. Исправьте правила замены сфер (см. справочную систему Windows 2000 Server). Если сервер удаленного доступа является членом домена, а в ответе от пользователя нет имени домена, IAS подставляет имя домена, в который входит этот серпе) удаленного доступа. Чтобы IAS в таких случаях использовала имя другого доменг, присвойте нужное значение параметру DefaultDomain в разделе реестра (на компьютере с сервером IAS):
334
ЧАСТЬ 2 Удаленный доступ
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan \PPP\ControlPromcols\BuiltIn Внимание Не модифицируйте реестр самостоятельно (с помощью редактора реестра) — делайте это лить в крайнем случае, когда другого выхода нет, В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также тех, которые могут снизить быстродействие системы или привести к ее краху. Прямое редактирование реестра может повлечь за собой непредсказуемые последствия, и Вам придется переустанавливать Windows 2000. Для настройки и конфигурирования Windows 2000 по возможности используйте Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft). Некоторые серверы NAS автоматически удаляют имя домена из имени пользователя перед его пересылкой серверу RADIUS. Отключите удаление имени домена из имени пользователя. Подробнее см. документацию на Ваш сервер NAS. «The authentication type is not supported on this system» («Этот тип проверки подлинности не поддерживается на этом компьютере») Пользователь пытается задействовать метод аутентификации, не поддерживаемый на этом компьютере. Например, пользователю нужен тип ЕАР, не установленный на сервере. Для включения требуемого протокола измените профиль удаленного доступа. Если политика удаленного доступа отклоняет запрос пользователя на соединение, могут появляться следующие сообщения. "The user's information did not match a remote access policy» («Информация о пользователе не соответствует политике удаленного доступа») «The user is not allowed dial-in access to the network» («Этому пользователю не разрешен удаленный доступ к сети») «User attempted an unauthorized authentication method» («Пользователь пытался применить неразрешенный метод проверки подлинности») «User tried to connect from an unauthorized calling station» («Пользователь пытался подключиться через неразрешенную станцию вызова») «User tried to dial-In outside of permitted hours» («Пользователь пытался подключиться за пределами разрешенного времени») «User tried to connect by calling an unauthorized NAS phone number» («Пользователь пытался подключиться через неразрешенный телефонный номер NAS») «User tried to connect using an invalid port type» («Пользователь пытался подключиться через неправильный тип порта») «A constraint defined in the remote access policy tailed» («He выполнено ограничение, определенное в политике удаленного доступа») Доступ может быть запрещен пользователю одной из политик удаленного доступа. Просмотрите список политик и проверьте, не исключили ли Вы пользователей, которым должен предоставляться доступ. Проверьте в журнале событий, не пытается ли пользователь подключиться с параметрами, не разрешенными политикой удаленного доступа (например, в запрещенное время, через неправильный тип порта.
ГЛАВА 8
Служба проверки подлинности в Интернете
335
с неавторизованного телефонного номера или по недоступному для данного пользователя телефонному номеру NAS). Внесите соответствующие изменения в политики удаленного доступа. Также возможен неверный порядок политик удаленного доступа. Запрос на соединение принимается или отклоняется первой политикой, условия которой соответствуют параметрам данного запроса. Переместите нужную политику с помощью кнопки Move Up (Вверх) выше по списку. «The user has exceeded the dial-in lockout count» («Этот пользователь превысил счетчик блокировки входящих подключений») Если включена функция блокировки учетных записей, предыдущая неудачная попытка соединения могла привести к блокировке учетной записи данного пользователя. Если это так, увеличьте пороговое значение счетчика, используемого функцией блокировки. «The user's account is currently locked out and might not be legged on to» («Учетная запись этого пользователя в данный момент заблокирована и не может использоваться для входа в систему») 1 Учетная запись пользователя блокирована, и аутентификация по ней невозможна. «The user is not allowed dial-in access to the network» («Этому пользователю не разрешен удаленный доступ к сети») Пользователю может быть запрещен удаленный доступ. Проверьте, предоставлен ли пользователю удаленный доступ в учетных данных на контроллере домена или в оснастке Local Users and Groups (Локальные пользователи и группы). Эта информация переопределяет любую политику, разрешающую доступ. «The current configuration supports only local user accounts» («Текущая конфигурация поддерживав г только локальные учетные записи пользователей») IAS настроен на аутентификацию в локальной базе данных SAM, а пользователь не зарегистрирован в этой базе. В таком случае включите сервер IAS в Active Directory. «The user's account domain is unreachaole» («Домен учетной записи пользователя недоступен») «The server is unavailable» («Сервер недоступен») «The specified domain did not exist» («Указанный домен не существует») «IAS could not access the Global Catalog» («IAS не имеет доступа к глобальному каталогу») Возможна проблема со связью между серверами NAS и IAS или между сервером IAS и контроллером домена или сервером глобального каталога. Для проверки свя зи с контроллером домена или сервером глобального каталога используйте г<оман ду ping. Если команда ping сработала, попробуйте подключиться к серверу командой net use \\имя_сервера\общии_ресурс. Если после этого в журнале IAS не появилось никакой информации, проверьте по журналу событий Windows 2000, не было ли таймаута при попытке подключения. Клиентский компьютер может быть настроен на CHAP, a Active Directory не сконфигурирована на использование нешифрованных паролей. Чтобы использовать протокол аутентификации CHAP, настройте профиль входящих подключений пользователя или группы на протокол CHAP. NAS и пользовательская программа лозвона до сервера (например, диспетчер подключений) должны быть настроены
336
ЧАСТЬ 2
Удаленный доступ
на аутентификацию по CHAP. Вы также должны включить CHAP на контроллере домена. Некоторые серверы NAS распознают не все символы, которые IAS принимает для общих секретов. Попробуйте изменить общий секрет так, чтобы он состоял только из алфавитно-цифровых знаков. Не исключено, что сервер NAS посылает пакеты, не соответствующие формату, ожидаемому IAS. Щелкните правой кнопкой мыши Internet Authentication Service (Служба проверки подлинности в Интернете) и выберите команду Properties (Свойства). Убедитесь, что флажок Log rejected or discarded authentication requests (Протоколирование отказов на запросы проверки подлинности) установлен, а жгем просмотрите журнал на предмет того, не посылаются ли какие-нибудь неподходящие пакеты. Если дело обстоит именно так, то, возможно, придется определить в IAS какие-то особые атрибуты вендора. Возможно, что серверу IAS не удается подключиться к домену. Убедитесь, что 1AS использует правильное имя домена. Если имя домена корректно, убедитесь, что сервер 1AS входит в этот домен или что между этим доменом и доменом, к которому относится сервер IAS, существуют доверительные отношения. У сервера 1AS нет разрешения на просмотр объектов пользователей в Active Directory. Включите сервер IAS в Active Directory. Учетная запись пользователя находится в лесу Active Directory, отличном от леса, в который включен сервер IAS. Для перенаправления запроса на аутентификацию серверу IAS, который включен в другой лес Active Directory, используйте RADIUSпрокси. Пользователь пытается применить разрешенное 128-битное шифрование. В IAS такое шифрование тоже разрешено, но в службе маршрутизации и удаленного доступа — нет. Выберите в службе маршрутизации и удаленного доступа уровень шифрования Strongest. (Если соответствующий переключатель отсутствует, установите Microsoft Encryption Pack.) Возможно, Вашему серверу NAS нужен метод маршрутизации Framed-Routing (с разбиением на кадры), а па сервере IAS он не разрешен. Включите этот метод маршрут иза дин. ^ Чтобы включить метод маршрутизации Framed-Routing: 1.
В оснастке IAS раскройте узел Remote Access Policies (Политика удаленного доступа), а затем дважды щелкните имя политики, применяемой к пользователям, которым не удается войти в систему.
2. Щелкните кнопку Edit Profile (Изменить профиль), перейдите на вкладку Advanced (Дополнительно) и щелкните кнопку Add (Добавить). 3. В списке доступных атрибутов RADIUS дважды щелкните атрибут FramedRouting (Framed-Routing). 4. В ноле со списком Attribute value (Значение атрибута) выберите None (None). Вашему NAS может понадобиться сжатие для TCP/IP но методу Ван Якобсена (Van Jacobsen TCP/IP compression), не предлагаемое в IAS по умолчанию. Настройте IAS на использование сжатия для TCP/IP по методу Van Jacobsen
ГЛАВА 8
Служба проверки подлинности в Интернете
337
>• Чтобы настроить IAS на сжатие для TCP/IP по методу Van Jacobsen: 1. В оснастке IAS раскройте узел Remote Access Policies, а затем дважды шелкните имя политики, применяемой к пользователям, которым не удается пойти в систему. 2. Щелкните кнопку Edit Profile, перейдите на вкладку Advanced и щелкните кнопку Add. 3. В списке доступных атрибутов RADIUS дважды щелкните атрибут FramedCompression (Framed-Compression). 4. В иоле со списком Attribute value выберите Van Jacobsen TCP/IP header compression (Van Jacobsen TCP/IP header compression). Если на сервере NAS установлен параметр Framed-MTU, а на сервере IAS — пет, пользователи не смогут входить в систему. Проверьте параметр Framed-MTU в JAS и убедитесь, что он соответствует тому же параметру на сервере NTAS. >• Чтобы изменить значение параметра Framed-MTU: 1. В оснастке IAS раскройте узел Remote Access Policies, а затем дважды щелкните имя политики, применяемой к пользователям, которым не удается войти в систему. 2. Щелкните кнопку Edit Profile, перейдите на вкладку Advanced и щелкните кнопку Add. 3. В списке доступных атрибутов RADIUS дважды щелкните атрибут FramedMTU (Framed-*MTU). 4. В поле Attribute value введите значение, соответствующее настройкам NAS. Если IAS возвращает пакет Access-Accept, используя сетевой адаптер, от личный от того, по которому был принят пакет Access-Request, сервер NAS не распознает такой пакет, В этом случае проверьте настройки сервера IAS. Если запрос возвращается через RADIUS-прокси, то не исключено, что он не поддерживает некоторые необходимые расширения, например: •
если Вы хотите, чтобы Ваши пользователи аутентифицировались по ЕАГ. RADIUS-прокси должен поддерживать цифровые подписи (в соответствии с расширениями RADIUS); • если Вы хотите, чтобы Ваши пользователи подключались через принудительные туннели, RADIUS-прокси должен поддерживать шифрование пароля для туннеля; • если для подключений требуется Microsoft Encryption, RADIUS-прокси должен поддерживать шифрование МРРЕ-ключей, Просмотрите документацию на свой RADIUS-прокси и проверьте, поддерживает ли он нужные Вам расширения. Какая-то политика удаленного доступа может принимать запросы на соединение от пользователей, доступ которым должен быть запрещен. Проверьте список политик и убедитесь, что Вы не включили в одной из политик пользователей, доступ которым должен быть запрещен. Проверьте, не заданы ли свойства входящих звонков объекта пользователя, переопределяющие параметры в политике удаленного 123ак. 3343
338
ЧАСТЬ 2
Удаленный доступ
доступа. Также не исключено, что порядок перечисления политик неверен. Доступ предоставляется или запрещается первой же политикой, условия которой применимы к пытающемуся подключиться пользователю. Кнопка Move Up (Вверх) позволяет переместить политику, запрещающую доступ пользователям, выше по списку. IAS не настроена на ведение журнала отказов на запросы аутентификации. Включите эту функциональность IAS и проверьте, не зарегистрированы ли какие-нибудь недопустимые пакеты. NAS может требовать для учета в RADIUS другой общий секрет. Убедитесь, что общий секрет для учета идентичен используемому для аутентификации. В профиле входящих подключений политики удаленного доступа не выбрано СНАР-шифрование. Проверьте параметры профиля и убедитесь, что IAS настроена на аутентификацию по CHAP. Также убедитесь, что сервер NAS настроен на этот метод (см. документацию на сервер NAS). Кроме тото, контроллер домена должен быть настроен на хранение обратимо шифруемых паролей. • После включения режима хранения паролей в обратимо шифруемом виде, текущие пароли не преобразуются в эту форму автоматически. Вы должны либо сбросить их, либо потребовать смены пароля для каждого пользователя при следующем входе в систему. • После переключения контроллера домена из смешанного режима в основной, перезагрузите все контроллеры этого домена, чтобы произошла репликация изменений. • Перезагрузите контроллеры домена, чтобы серверы вновь могли получать к ним доступ. Если служба маршрутизации и удаленного доступа сконфигурирована на аутентификацию через RADIUS, доступ к политикам возможен только через оснастку IAS. Это сделано преднамеренно, Подробнее об устранении проблем с TAS см. справочную систему Windows 2000 Server.
Применение Network Monitor Если после проверки базовой конфигурации IAS решить проблему не удалось, используйте Network Monitor (NetMon) (Сетевой монитор) для трассировки и последующего анализа данных. Применяя NetMon для устранения проблем с IAS, учтите следующие соображения. • NetMon должен быть установлен на компьютере, на котором работает сервер IAS. • Если Вы используете NetMon в коммутируемой сетевой среде, то увидите лишь трафик, адресованный компьютеру, где запущен NetMon. Об установке и использовании NetMon см. книгу «Сопровождение сервера* из серии «Ресурсы Microsoft Windows 2000 Server». Для локализации источника проблем в работе RADIUS средствами NetMon нужно настроить его на фильтрацию пакетов RADIUS.
ГЛАВА 8
Служба проверки подлинности в Интернете
339
^ Чтобы фильтровать RADIUS-пакеты в трассировочной информации NetMon: 1. Выполните трассировку в дробленной ситуации. 2. Выберите из меню Display (Отображение) команду Filter (Фильтр). 3. Выберите Protocol = = Any (Протокол = = Любой), а затем щелкните кнопку Edit Expression (Выражение). Выберите Disable All (Отключить все), чтобы отключить все протоколы. В лрааой секции укажите RADIUS protocol (Протокол RADIUS) и щелкните Enable (Включить). 4. Щелкните кнопку ОК.
ГЛАВА
9
Виртуальные частные сети
Windows 2000 поддерживает виртуальные частные сети (virtual private networks. VPN), позволяющие подключать удаленные клиенты и офисы к корпоративным сетям черед Интернет. Как специалист по сетям, Вы должны понимать области применения виртуальных частных сетей, а также технологии и концепции, на которых они построены: РРТР (Point-to-Point Tunneling Protocol), L2TP (Layer Two Tunneling Protocol), средства защиты, адресацию и маршрутизацию в VPN и т. д. Кроме того, здесь предполагается, что Вы хорошо знаете TCP/IP, IP-маршрутизацию, IPбезопасность (IPSec) и сервер удаленного доступа Windows 2000. В этой главе Обзор 341 РРТР 352 L2TP и IP-безонасностъ 357 Защита виртуальных частных сетей 362 Адресация и маршрутизация при использовании виртуальных частных сетей Виртуальные частные сети и брандмауэры 380
364
Виртуальные частные сети и NAT 384 Сквозные VPN-соединения 386 Выявление и устранение проблем 391 См. также • Подробнее о TCP/IP — главу 1 «Введение в TCP/IP» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server», • Об IPScc — главу 8 «IP-безопасность» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». • Об одноадресной IP-маршрутизации — главу 3 «Одноадресная IP-маршрутизация» в этой книге. • О маршрутизации с соединением по требованию — главу 6 «Маршрутизация с соединением по требованию» в этой книге.
ГЛАВА 9
Виртуальные частные сети
341
О сервере удаленного доступа Windows 2000 — главу 7 «Сервер удаленного доступа» в этой книге.
Обзор Виртуальная частная сеть (virtual private network, VPN) — это расширение частной сети, включающей соединения через общедоступные сети вроде Интернета. VPK позволяет передавать данные между двумя компьютерами по общедоступным сетям, эмулируя свойства частного канала связи типа «точка-точка». Для эмуляции канала связи «точка-точка* данные инкапсулируются в пакет с заголовком, который содержит информацию о маршрутах, необходимую для пересилки этого пакета в конечную точку по общедоступным сетям. Кроме того, передаваемые данные зашифровываются. Злоумышленник, перехватив такие пакеты в общедоступной сети, не сможет расшифровать их без соответствующих шифровальных ключей. Канал связи, при использовании которого частные данные инкапсулируются и зашифровываются, называется VPN-соединением. Логическую концепцию VPN иллюстрирует рис. 9-1.
VPN-соединение
Рис. 9-1, Виртуальная частная сеть (VPN) VPN-соединение дает возможность пользователю, работающему дома или в дороге, получать удаленный доступ к серверу своей организации через инфраструктуру общедоступных сетей, например через Интернет. С точки зрения пользователя, VPN — это соединение типа «точка-точка» между его компьютером (VPN-клиентом) и сервером организации (VPN-сервером). Конкретная инфраструктура общедоступной сети не имеет для него никакого значения, поскольку VPN-соедине-
342
ЧАСТЬ 2
Удаленный доступ
ние создает такое впечатление, будто данные передаются по выделенному частному каналу, VPN-соединения также позволяют организациям создавать маршрутизируемые подключения к территориально удаленным офисам и другим организациям по общедоступным сетям тина Интернета, в то же время обеспечивая защиту коммуникационных связей. Маршрутизируемое VPN-соединение (routed VPN connection) через Интернет на логическом уровне обрабатывается как выделенный WAN-канал. Обладая свойствами как удаленных, так и маршрутизируемых соединений, VPNсоединения позволяют организации заменить междугородные выделенные или коммутируемые линии удаленного доступа на локальные выделенные линии или удаленный доступ по коммутируемой линии к местному провайдеру Интернет-услуг (Internet service provider, ISP).
Элементы VPN-соединения VPN-соединение в Windows 2000 включает следующие элементы (рис. 9-2). VPN-сервер. Компьютер, принимающий запросы на VPN-соединения от VPN-клиентов. VPN-сервер поддерживает VPN-соединения удаленного доступа и VPN-соединения между маршрутизаторами. Подробнее см. раздел «VPN-соединения» далее в этой главе. VPN-клиент. Компьютер, инициирующий VPN-соединение с VPN-сервером. VPNклиент может быть автономным компьютером, используемым для удаленного доступа, или маршрутизатором, принимающим межмаршрутизаторные VPN-соединения. Компьютеры под управлением Windows NT версии 4.0, Windows 2000, Windows 95 или Windows 98 могут создавать VPN-соединения удаленного доступа с VPN-сервером Windows 2000, а компьютеры под управлением Windows 2000 Server и Windows NT Server 4.0 и службы маршрутизации и удаленного доступа (Routing and Remote Access service, RRAS) — межмаршрутизаторные VPN-соединения с VPN-сервером Windows 2000. VPN-клиент может быть клиентом любой реализации РРТР (Point-to-Point Tunneling Protocol) или L2TP (Layer Two Tunneling Protocol) поверх IPSec (не только от Microsoft). Туннель. Часть соединения, по которой данные передаются в инкапсулированном виде. VPN-соединение. Часть соединения, по которой данные передаются в шифрованном виде. В случае безопасных VPN-соединений данные зашифровываются и инкапсулируются на одной и той же части соединения. Примечание Существует возможность создания туннеля и передачи данных по нему без шифрования. Но это не VPN-соединение, так как конфиденциальные данные будут передаваться по общедоступной сети в незашифрованном, легко читаемом виде. Протоколы тунпелирования (тупнелирующие протоколы). Коммуникационные стандарты, применяемые для управления туннелями и инкапсуляции конфиденциальных данных. (Туннелируемые данные также зашифровываются.) Windows 2000 включает протоколы тунпелирования РРТР и L2TP (см. разделы «РРТР» и «L2TP и IP-безопасность» далее в этой главе).
ГЛАВА 9
Виртуальные частные сети
343
Тупнелированные данные. Данные, которые обычно передаются по частному каналу связи типа «точка-точка». Транзитная межсетевая среда. Открытая или общедоступная межсетевая среда, через которую передаются инкапсулированные данные. В случае Windows 2000 транзитной всегда является межсетевая IP-среда. Транзитной межсетевой средой может быть Интернет или частная JP-интрасеть.
Туннель "'{" ^><" NT VPN-соединение VPN-сервер ч,, vS, т~ч
•Транзитная межсетевая среда
VPN-клиент
Рис. 9-2. Элементы VPN-соединения
VPN-соединения Создание VPN-соединения во многом аналогично установлению соединения типа «точка-точка» по коммутируемой линии или при маршрутизации с соединением по требованию. Существует два типа VPN-соединений: VPN-соединение удаленного доступа (remote access VPN connection) и VPN-соединение между маршрутизаторами (router-to-router VPN connection).
VPN-соединение удаленного доступа Такое соединение инициируется клиентом удаленного доступа (компьютером индивидуального пользователя), который подключается к частной сети. VPN-сервер предоставляет доступ к своим ресурсам или ко всей сети, с которой он связан. Пакеты, передаваемые по VPN-соединению, генерируются клиентом удаленного доступ,!, Клиент удаленного доступа (VPN-клиент) аутентифицируется на сервере удаленного доступа (VPN-сервере), а тот — на клиенте (в случае взаимной аутентификации).
VPN-соединение между маршрутизаторами Данное VPN-соединение инициируется маршрутизатором и связынает два фрагмента частной сети. VPN-сервер предоставляет маршрутизируемое соединение с сетью, к которой он подключен. При VPN-соединении между маршрутизаторами пакеты передаются одним из пик и обычно генерируются другими компьютерами. Вызывающий маршрутизатор (VPN-клиент) аутентифицируется на отвечающем (VPN-сервере), а отвечающий — на вызывающем (в случае взаимной аутентификации).
Свойства VPN-соединений VPN-соединения, использующие РРТР и «L2TP поверх IPSec», обеспечивают: • инкапсуляцию; • аутентификацию (проверку подлинности);
344
ЧАСТЬ 2
Удаленный доступ
• шифрование данных; • назначение адресов и серверов имен. Инкапсуляция Технология VPN предусматривает инкапсуляцию частных (конфиденциальных) данных з пакет с заголовком, необходимым для передачи этих данных через транзитную межсетевую среду. Аутентификация Для VPN-соединений поддерживается аутентификация двух видов. •
Аутентификация пользователя. Для установления VPN-соединения нужно, чтобы VPN-сервер аутентифицировад VPN-клиент, запрашивающий соединение, и проверял наличие у него соответствующих разрешений. При взаимной аутентификации VPN-клиент тоже аутентифицирует VPN-сервер, что обеспечивает защиту от фальшивых VPN-серверов. • Аутентификация и проверка целостности данных. Если Вы хотите гарантировать подлинность источника данных, передаваемых по VPN-соединению, и исключить вероятность их модификации в процессе передачи, то можете; включать в них криптографическую контрольную сумму, которая вычисляется на основе шифровального ключа, известного лишь отправителю и получателю данных.
Шифрование данных Чтобы гарантировать конфиденциальность данных при передаче по открытой межсетевой среде, отправитель шифрует их, а получатель расшифровывает. Процессы шифрования и расшифровки невозможны без знания обеими сторонами общего шифровального ключа. Пакеты, перехваченные на своем пути по VPN-соединению через транзитную межсетевую среду, бесполезны для злоумышленника, не знающего шифровального ключа. Существуют вычислительные методы, позволяющие определить шифровальный ключ, но чем он длиннее, тем больше нужно вычислительных мощностей и времени. Поэтому длина шифровального ключа — важнейший параметр защиты. Кроме того, чем больше информации зашифровывается одним и тем же ключом, тем легче ее расшифровать. В связи с этим некоторые технологии шифрования позволяют указывать частоту смены шифровального ключа в процессе сеанса связи. Подробнее об управлении шифровальными ключами применительно к технологиям VPN в Windows 2000 см. раздел «Защита виртуальных частных сетей» далее в этой главе. Назначение адресов и серверов имен При настройке VPN-сервера создается виртуальный интерфейс, чере;^ который устанавливаются все VPN-соединения. Когда VPN-клиент запрашивает VPN-соединение, на нем тоже создается виртуальный интерфейс. Далее виртуальный интерфейс VPN-клиента подключается к виртуальному интерфейсу VPN-сервера, и создается VPN-соединение типа «точка-точка». Виртуальным интерфейсам VPN-клиента и сервера должны быть назначены IP-адреса. Их назначение осуществляется VPN-сервером. По умолчанию VPN-cepuep получает IP-адреса для себя и VPN-клиента через DHCP (Dynamic Host Configu-
ГЛАВА 9
Виртуальные частные сети
345
ration Protocol), Вы можете задать статический пул IP-адресов, определяемый по идентификатору сети и маске подсети. Серверы имея (DNS- и WINS-серверы) также назначаются в процессе установления VPN-соединения. VPN-клиент получает от VPN-сервера IP-адреса DNS- и WINS-серверов, относящихся к иптрасети, к которой подключен VPN-сервер.
VPN-соединения через Интернет или интрасети VPN-соединения удобны для подключения пользователей или сетей по безопасному каналу связи типа «точка-точка». Типичные VPN-соединения осуществляются либо через Интернет, либо через интрасети.
VPN-соединения через Интернет Используя такие соединения, Вы избегаете расходов па междугородную и/или международную телефонную связь и в то же время получаете все преимущества г,юбальпых Интернет-коммуникаций. Удаленный доступ через Интернет Клиент удаленного доступа — вместо того чтобы связываться с корпоративным или аутсорсинговым сервером доступа is сеть по междугородной связи — звонит местному ISP. Установив физическое соединение с местным 1SP, клиент удаленного доступа инициирует VPN-соединение через Интернет с VPN-сервером своей организации. После создания VPN-соединения клиент удаленного доступа может обращаться к ресурсам частной интрасети. Схема удаленного доступа через Интернет показана на рис. 9-3. г VPN-соединение
Интрасеть
Рис. 9-3. VPN-соединение, связывающее удаленный клиент с частной интрасетью Соединение сетей через Интернет Когда сети соединяются через Интернет (рис. 9-4). один маршрутизатор пересылает пакеты другому но VPN-соединению. С точки зрения маршрутизаторов, VPN действует как канальный уровень сети.
346
ЧАСТЬ 2 Удаленный доступ • VPN-соединение
'Туннель
• Выделенный или коммутируемый канал связи с ISP
Выделенный канал связи с ISP
Центральный офис
Рис. 9-4. VPN-соединение, связывающее две удаленные сети через Интернет Соединение сетей с использованием выделенных WAN-каналов. Маршрутизаторы офисов подключаются не через дорогостоящий междугородный выделенный WAN-канал, а через Интернет с использованием локальных выделенных WAN-каналов связи с местными ISP. VPN-соединение инициируется одним из маршрутизаторов. После соединения маршрутизаторы могут пересылать друг другу любой трафик. Соединение сетей с использованием коммутируемых WAN-каналов. Маршрутизатор филиала — вместо того чтобы связываться с корпоративным или аутсорсинговым сервером доступа в сеть (NAS) по междугородной или международной телефонной линии — звонит местному ISP. Используя соединение с местным ISP, маршрутизатор филиала инициирует межмаршрутизаторпое VPN-соединение с корпоративным маршрутизатором-концентратором черен Интернет. Корпоративный маршрутизатор-концентратор, выступающий в роли VPN-сервера, должен быть подключен к местному ISP по выделенному WAN-каналу. Подробнее о настройке VPN-соединений, создаваемых на коммутируемом подключении с местным ISP, см. раздел «Адресация и маршрутизация при использовании виртуальных частных сетей» далее в этой главе. Оба офиса можно подключить к Интернету по коммутируемым WAN-каналам, Но это реально, только если ISP поддерживает для своих заказчиков маршрутизацию с соединением по требованию; в этом случае ISP, получив IP-дейтаграмму, которую нужно доставить заказчику, вызывает его маршрутизатор. Такой сервис предоставляют лишь отдельные ISP.
VPN-соединения через интрасети Такое VPN-соединение использует преимущества поддержки IP-соединений в интрасети организации. Удаленный доступ через интрасеть В некоторых интрасетях информация, принадлежащая какому-либо отделу, например отделу кадров, настолько конфиденциальна, что соответствующий сегмент сети физически отключается от остальной части интрасети организации. Хотя этот способ надежно защищает конфиденциальную информацию, он создает проблемы с доступом к ней для пользователей, не подключенных к отделенному сегменту сети. Применение VPN-соединений позволяет физически подключить сегмент сети отдела, имеющего дело с конфиденциальной информацией, к интрасети организации, но отделить его VPN-сервером, который не обеспечивает прямое мартрутизируе-
ГЛАВА 9
Виртуальные частные сети
347
мое соединение между корпоративной интрасетью и отделенным сегментом сети. Пользователи корпоративной интрасети с соответствующими разрешениями могут устанавливать с VPN-сервером VPN-соединения удаленного доступа и обращаться к защищенным ресурсам. Кроме того, все данные, передаваемые по VPN-соединению, зашифровываются для обеспечения их конфиденциальности. Пользователям, не имеющим прав на установление такого VPN-соединения, отделенный сегмент сети просто не виден. Схема удаленного доступа через интрасеть показана на рис. 9-5. • VPN-соединение VPN-сервер
Защищенная (скрытая) сеть Рис. 9-5. VPN-соединение, обеспечивающее удаленный доступ к защищенной сети через интрасеть Соединение сетей через интрасеть Используя VPN-соединение между маршрутизаторами, Вы можете связать две сети через иитрассть. VPN-соединение этого типа очень удобно для организации коммуникационного взаимодействия между двумя отделами, которые находятся в разных географических точках и имеют дело с конфиденциальной информацией, например, чтобы бухгалтерия могла обмениваться с отделом кадров сведениями о заработной плате сотрудников организации. Бухгалтерия и отдел кадров подключаются к общей интрасети через компьютеры, работающие в качестве VPN-клиентов или серверов. Как только VPN-соединение установлено, пользователи любой из двух сетей могут обмениваться конфиденциальной информацией через корпоративную интрасеть, Рис. 9-6 иллюстрирует сети, соединенные интрасетью. • VPN-соединение
Защищенная (скрытая) сеть
Защищенная (скрытая) сеть
Рис. 9-6. VPN-соединение, связывающее две сети через интрасеть
348
ЧАСТЬ 2 Удаленный доступ
Комбинированные VPN-соединения через Интернет и интрасети VPN-соединения — гибкое средство для создания защищенных подключений типа «точка-точка». Менее распространены комбинированные VPN-соединения, также называемые сквозными (pass-through VPN connection) (рис. 9-7). Такое соединение позволяет удаленному клиенту, подключенному к интрасети одной компании, получить доступ через Интернет к ресурсам интрасети другой компании. В этом варианте VPN-соединение удаленного доступа достигает интрасети назначения через другую интрасеть и Интернет. • VPN-соединение Туннель
Интрасеть
Интрасеть
Рис. 9-7. Сквозное VPN-соединение Подробнее о сквозных VPN-соединениях см. раздел «Сквозные VPN-соединения» далее в этой главе.
Управление виртуальными частными сетями Управление виртуальными частными сетями ничем не отличается от управления любыми другими сетевыми ресурсами, и при использовании VPN-соединений (особенно через Интернет) следует тщательно продумать систему безопасности. Ответьте себе на следующие вопросы. •
Где должны храниться учетные данные пользователей?
• Как будут назначаться адреса VPN-клиентам? • Кому разрешено создавать VPN-соединения? • Как VPN-сервер будет аутентифицировать пользователя, пытающегося установить VPN-соединение? • Как VPN-сервер будет регистрировать активность, связанную с VPN? • Как добиться того, чтобы VPN-сервером можно было управлять на основе стандартных протоколов и инфраструктуры сетевого администрирования?
Управление пользователями Поскольку хранить разные учетные записи на разных серверах для одного и того же пользователя и одновременно поддерживать их в актуальном состоянии слишком непрактично с административной точки зрения, большинство администраторов создают главную базу учетных данных (master account database) на первичном контроллере домена или на сервере RADIUS (Remote Authentication Dial-In User Service). Это позволяет VPN-серверу передавать аутентификационные удостоверения устройству, отвечающему за централизованную аутентификацию. При этом для удаленного доступа как по коммутируемой линии, так и через VPN применяется одна и та же пользовательская учетная запись.
ГЛАВА 9
Виртуальные частные сети
349
Управление адресами и серверами имен VPN-сервер должен располагать запасом свободных IP-адресов, чтобы иметь возможность назначать их своему виртуальному интерфейсу и VPN-клиентам при согласовании параметров по JPCP (IP Control Protocol) в процессе установлении соединений. IP-адрес, назначенный VPN-клиенту, на самом деле присваивается его виртуальному интерфейсу. VPN-серверы под управлением Windows 2000 по умолчанию получают IP-адреса для VPN-клиентов через DHCP, но Вы можете сконфигурировать статический пул IP-адресов. Кроме того, VPN-серверу должны быть известны адреса DNS- и WINS-серверов, которые он назначает VPN-клиентам при согласовании параметров но IPCP (см. главу 7 «Сервер удаленного доступа» в этой книге).
Управление доступом В Windows 2000 для управления удаленным доступом следует настроить параметры входящих звонков в свойствах пользовательских учетных записей и в соответствующих политиках удаленного доступа. Доступ по пользовательской учетной записи Если Вы управляете доступом па уровне пользователей (индивидуально для каждого пользователя), установите в параметрах их учетных записей разрешение на создание VPN-соединений как Allow access (Разрешить доступ). Если VPN-сервер обслуживает только VPN-соединения, удалите политику удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения) и создайте новую политику с подходящим именем, например VPN access it' allowed by user account. Если VPN-сервер обслуживает как VPN-соединения, так и удаленный доступ по коммутируемым линиям, оставьте политику удаленного доступа по умолчанию но переместите се в самый конец списка политик. В качестве примера типичных настроек удаленного доступа через VPN выберите в свойствах политики удаленного доступа переключатель Deny remote access permission (Отказать в праве удаленного доступа), а условия и параметры профиля установите, как показано в таблицах 9-1 и 9-2. Подробнее о настройке этих параметров см. справочную систему Windows 2000 Server. Таблица 9-1. Условия политики удаленного доступа для подключения через VPN на основе параметров учетной записи Условие NAS-Port-Type
Настройки Virtual (VPN) [Virtual (VPN)J
Если Вы хотите определить для РРТР- и Ь2ТР-соединений разные параметры аутентификации и шифрования, создайте отдельные политики удаленного дос упа, д которых установите условие Tunnel-Type (Tunnel-Type) либо как Point-topoint Tunneling Protocol (Point-to-Point Tunneling Protocol), либо как Layer Two Tunneling Protocol (Layer Two Tunneling Protocol).
350
ЧАСТЬ 2
Удаленный доступ
Таблица 9-2. Параметры профиля политики удаленного доступа для подключения через VPN на основе параметров учетной записи Вкладка в окне профиля
Настройки
Authentication Установите флажки Microsoft encrypted authentication version 2 (Проверка подлинности) (MS-CHAP v2) [Шифрованная проверка (Microsoft, версия 2, MS-CHAP v2)J и Microsoft encrypted authentication (MS-CHAP) [Шифрованная проверка подлинности Microsoft (MS-CHAP)l Encryption (Шифрование) Выберите переключатель Basic (Основное), Strong (Стойкое) или Strongest* и сбросьте флажок No Encryption (Без шифрования) Доступ по принадлежности к группам Если Вы управляете удаленным доступом на уровне групп, укажите разрешение удаленного доступа во всех учетных записях пользователей как Control access through Remote Access Policy (Управление на основе политики удаленного доступа). Создайте какую-нибудь группу Windows 2000, членам которой будет разрешено устанавливать VPN-соединения удаленного доступа. Если VPN-сервер обслуживает только VPN-соединения, удалите политику удаленного доступа по умолчанию Allow access if dial-in permission is enabled (Разрешить доступ, если разрешены входящие подключения) и создайте новую политику с подходящим именем, например VPN access if member of VPN-allowed group. Если VPN-сервер обслуживает как VPN-соединения, так и удаленный доступ по коммутируемым линиям, оставьте политику удаленного доступа по умолчанию, но переместите ее в самый конец списка политик. Таблица 9-3. Условия политики удаленного доступа для подключения через VPN на основе принадлежности к группам Windows 2000 Условие
Настройки
NAS-Port-Type Windows-Groups
Virtual (VPN) [Virtual (VPN)] Группа Windows 2000. члены которой имеют право создавать VPN-соединения
Таблица 9-4. Параметры профиля политики удаленного доступа для подключения через VPN на основе принадлежности к группам Windows 2000 Вкладка в окне профиля
Настройки
Authentication (Проверка подлинности)
Установите флажки Microsoft encrypted authentication version 2 (MS-CHAP v2) [Шифрованная проверка (Microsoft, версия 2, MS-CHAP v2)"| и Microsoft encrypted authentication (MSCHAP) [Шифрованная проверка подлинности Microsoft (MSCHAP)] Encryption (Шифрование) Выберите переключатель Basic (Основное), Strong (Стойкое) или Strongest и сбросьте флажок No Encryption (Без шифрования)
Этот уровень шифрования поддерживается только после установки Microsoft Encryption Pack, подпадающего под действие экспортных ограничений США. — Прим, перев.
ГЛАВА 9
Виртуальные частные сети
351
В качестве примера типичных настроек удаленного доступа через VPN только для членов определенной группы выберите в свойствах политики переключатель Grant remote access permission (Предоставить право удаленного доступа), а условия и параметры профиля установите, как показано в таблицах 9-3 и 9-4. Подробнее о настройке этих параметров см. справочную систему Windows 2000 Server.
Управление аутентификацией VPN-сервер можно настроить на поддержку аутентификации через Windows или RADIUS. Если в качестве провайдера аутентификации выбрана Windows, удостоверения пользователей, пытающихся установить VPN-соединения, проверяются обычными средствами аутентификации Windows. Если в качестве провайдера аутентификации выбрана служба RADIUS, удостоверения пользователей и параметры запросов па соединения посылаются на сервер RADIUS как серия RADIUS-запросов. Сервер RADIUS получает запрос пользователя на соединение от VPN-сервера и аутентифицирует его на основе собственной базы данных учетных записей. На сервере RADIUS могут централизованно храниться и другие сведения о пользователях. Сервер RADIUS может не просто ответить «да» или «нет» на запрос о согдинении, но и предоставить VPN-серверу информацию о параметрах соединения для данного пользователя, например о максимальной продолжительности сеанса, статическом IP-адресе и т. д. Сервер RADIUS может не только отвечать на запросы на основе собственной базы данных, но и выступать в роли клиентского интерфейса другого сервера базы данных, например универсального сервера ODBC (Open Database Connectivity) или первичного контроллера домена под управлением Windows 2000. Последний может находиться как на машине, где установлен сервер RADIUS, так и на другом компьютере. Кроме того, сервер RADIUS способен работать как прокси-клиент для удаленного сервера RADIUS. Протокол RADIUS описан в RFC 2138 и 2139. Подробнее о протоколе RADIUS и сервере RADIUS, также называемом службой IAS (Internet Authentication Service) см. главу 8 «Служба проверки подлинности в Интернете» в этой книге.
Управление учетом В качестве службы учета VPN-сервер может использовать Windows или RADIUS. В первом случае учетная информация записывается в файл журнала на VPN-сервере, во «тором — сообщения с учетной информацией поступают на сервер RADII'S. где накапливаются и хранятся для последующего анализа. Большинство серверов RADIUS можно настроить так, чтобы они записывали в файл учетной информации сведения о запросах на аутентификацию. Сторонними разработчиками создано программное обеспечение для биллинга и аудита, которое считывает записи с учетной информацией RADIUS и генерирует отчеты. Подробнее об учете в RADIUS см. RFC 2139.
Управление сетью Если на компьютер с Windows 2000, работающий в качестве VPN-сервера, установить службу SNMP, он сможет действовать в среде SNMP (Simple Network Management Protocol) как агент SNMP. VPN-сервер регистрирует управляющую инфор-
352
ЧАСТЬ 2
Удаленный доступ
манию в различных идентификаторах объектов МШ II (Management Information Base), которые устанавливаются со службой SNMP. Объекты МШ II документированы в RFC 1213.
РРТР РРТР (Point-to-Point. Tunneling Protocol) инкапсулирует кадры РРР (Point-to-Point Protocol) в IP-дейтаграммы для передачи через межсетевую IP-среду, например Интернет или частную интрасеть. РРТР документирован в RFC 2637. Для создания, поддержания и закрытия туннеля протокол РРТР использует TCPсоединение, известное под названием «управляющее РРТР-соединенис» (РРТР control connection), а для инкапсуляции РРР-кадров как туннелированных данных — модифицированную версию GRE (Generic Routing Encapsulation). Собственно данные инкапсулированных РРР-кадров можно шифровать и/или сжимать. РРТР требует наличия межсетевой IP-среды между РРТР-клиентом (VPN-клиентом, использующим протокол туннелирования РРТР) и РРТР-сервером (VPN-сервером, использующим тот же протокол). РРТР-клиент может быть уже подключен к межсетевой IP-среде, через которую достижим РРТР-сервер, либо он может дозваниваться до сервера доступа в сеть (NAS) и устанавливать IP-соединение — так же, как и пользователь, получающий доступ в Интернет по коммутируемой линии. Аутентификация, выполняемая при создании VPN-соединения на основе РРТР, осуществляется с применением тех же механизмов, что и при установлении РРРсоединепий, — например, ЕАР (Extensible Authentication Protocol), MS-CHAP (Microsoft Challenge-Handshake Authentication Protocol), CHAP, SPAP (Shiva Password Authentication Protocol) и PAP (Password Authentication Protocol). РРТР наследует методы шифрования и/или сжатия полезных данных РРР от протокола РРР. В случае Windows 2000 для шифрования этих данных по методу МРРЕ (Microsoft Point-to-Point Encryption) следует использовать либо EAP-TLS (SAP-Transport Level Security), либо MS-CHAP. МРРЕ обеспечивает шифрование не на всем пути передачи данных (между клиентским приложением и сервером, на котором размещен ресурс или сервис;, используемый этим приложением), а лишь при их прохождении по каналу. Для шифрования на всем пути передачи данных нужно использовать IPSec, который будет шифровать IP-трафик после создания РРТР-тупнеля. РРТР-сервер на основе Интернет-стандартов представляет собой VPN-сервер с поддержкой РРТР; при этом один из его интерфейсов подключен к Интернету, а другой — к интрасети.
Поддержание туннеля с помощью управляющего РРТР-соединения Управляющее Р РТР-соединение устанавливается между динамически назначаемым TCP-портом РРТР-клиента и зарезервированным ТСР-нортом 1723 РРТР-сервера. По этому соединению РРТР управляет вызовами и передает управляющие сообщения, используемые для поддержания РРТР-туннеля. К ним относятся Р РТРсообщения Echo-Request и Echo-Reply, позволяющие распознавать обрыв связи между РРТР-клиентом и сервером. Пакет, передаваемый по управляющему РРТРсоединению состоит из IP- и TCP-заголовков, управляющего РРТР-сообщения, а также заголовка и концевой части канальною уровня (рис, 9-8).
ГЛАВА 9 Виртуальные частные сети
Заголовок канального уровня
IP
TCP
Управляющее РРТР-сообщ&ние
353
Концевая часть канального уровня
Рис. 9-8. Пакет, передаваемый по управляющему РРТР-соединению В таблице 9-5 перечислены основные управляющие РРТР-сообщсння, передаваемые по управляющему РРТР-соединению. Конкретный РРТР-туннель для всех управляющих РРТР-сообщений идентифицируется но ТСР-соедииению. Таблица 9-5. Основные управляющие РРТР-сообщения Сообщение
Описание
Start-Control-Connection-Request
Посылается РРТР-клиентом для установления управ,гяющего соединения. До передачи любых других РРТР сообщений для каждого РРТР-туннеля нужно создат. свое управляющее соединение. Посылается РРТР-сервером в ответ па сообщение SUirtControl-Connection-Request. Посылается РРТР-клиентом для создания РРТР-туш.сля. В это сообщение включается идентификатор вызова (Call ID), используемый в GRE-заголовке для определения туннелируемого трафика, передаваемого по конкретному туннелю. Посылается РРТР-сервером в ответ на сообщение Outgoing-Call-Request. Посылается РРТР-клиентом или сервером для проверки активности соединения. Если ответ на .это сообщение не поступает, РРТР-туннель через определенное врем и закрывается. Ответ на сообщение Echo-Request. Примечание: РРТР-сообщения Echo-Request и EchoReply не имеют никакого отношения к ЮМР-сообщениям Echo Request (Эхо-запрос) и Echo Reply (Эхо-ответ), Посылается РРТР-сервером всем VPN-клиентам, чтоиы сообщить о какой-либо ошибке, возникшей на РРРинтерфейсе РРТР-сервера. Посылается РРТР-клиентом или сервером для установки согласованных РРР-параметров. Посылается РРТР-клиентом для закрытия туннеля. Посылается РРТР-сервером в ответ на сообщение CallClear-Request или по другим причинам. Указывает, чти туннель должен быть закрыт. Посылается РРТР-клиентом или сервером для уведомления другой стороны о закрытии управляющего соединения. Ответ на сообщение Stop-Control-Conncction-Request.
Start-Control-Connection-Reply Outgoing-Call-Request
Outgoi ng-Call - Reply Echo-Request
Echo-Reply
WAN-Error-Notify Set-Link-Info Call-Clear-Request Call-Disconnect-Notify Stop-Control-Connection-Request Stop-Control-Connection-Reply
Детальные сведения о точной структуре управляющих РРТР-сообщений см. в RFC 2637.
354
ЧАСТЬ 2
Удаленный доступ
Туннелирование данных средствами РРТР Такое туннелирование осуществляется путем многоуровневого инкапсулирования. Структура данных, тунпелирошнньтх средствами РРТР, показана на рис. 9-9. Заголоаок канального IP-загоповсж
SRE-заголовок
Шифрованные полезные Концевая да иные РРР РРР-заголовок (IP- или 1РХ-йе£Иаграмш канального либо NetBEUI-кади уровня
Рис. 9-9. Данные, туннелированные средствами РРТР Инкапсуляция РРР-кадра Исходные полезные данные РРР зашифровываются и инкапсулируются в кадр с РРР-заголовком (РРР-кадр). Затем этот кадр инкапсулируется в пакет с модифицированным GRE-заголовком. GRE документирован в RFC 1701 и 1.702 и изначально был разработан в качестве простого универсального механизма инкапсуляции данных, передаваемых через межсетевые IP-среды. GRE является клиентским протоколом IP и использует идентификатор IP-протокола 47. GRE-заголовок модифицируется для РРТР следующим образом. •
Бит подтверждения указывает на наличие 32-битного поля подтверждения.
•
Поле ключа заменяется 16-битными полями длины полезных данных и идентификатора вызова. Последнее устанавливается РРТР-клиеитом при создании РРТР-туннеля.
•
Добавляется 32-битное поле подтверждения.
Внутри GRE-заголовка в поле типа протокола записывается значение Ох880В, используемое как значение EtherType для РРР-кадра. Примечание GRE иногда используется ISP для пересылки информации о маршрутизации внутри своих сетей. Чтобы эта информация не пересылалась на маршрутизаторы Интернет-магистралей (Internee backbone routers), ISP отфильтровывают GRE-трафик на интерфейсах, подключенных к Интернет-магистралям. В результате такой фильтрации создавать РРТР-туннели с использованием управляющих РРТР-сообтцений можно, но пересылать данные, туннелированные средствами РРТР, нельзя. Если Вы подозреваете наличие именно этой проблемы, свяжитесь со своим IS Р. Инкапсуляции GRE-пакета GRE-пакет далее инкапсулируется в пакет с IP-заголовком, в котором указываются IP-адреса отправителя и получателя (в роли которых выступают РРТР-клиент и сервер). Инкапсуляция канального уровня Для передачи по локальной сети (LAN) или WAN-каналу созданная на предыдущем этапе IP-дейтаграмма инкапсулируется в пакет с заголовком и концевой частью канального уровня, применяемого на данном физическом интерфейсе. Например, при передаче через Ethernet-интерфейс IP-дейтаграмма инкапсулируется в пакет с Ethernet-заголовком и концевой частью, а при передаче по WAN-каналу
ГЛАВА 9
Виртуальные частные сети
355
типа «точка-точка» (аналоговой телефонной линии или ISDN) — в пакет с РРРзаголовком и концевой частью. Обработка туннелированных данных Получив туннелированные средствами РРТР данные, РРТР-клиент или сервер выполняет следующие операции. 1. Обрабатывает и удаляет заголовок и концевую часть канального уровня. 2. Обрабатывает и удаляет IP-заголовок. 3. Обрабатывает и удаляет GRE- и РРР-заголовки. 4. Расшифровывает и/или декомпрессирует полезные данные РРР (если это нужно), 5. Обрабатывает полезные данные или пересылает их.
РРТР-пакеты и сетевая архитектура Windows 2000 Рис. 9-10 иллюстрирует путь, который проходят туннелированные данные (от VPNклиента по VPN-соединению удаленного доступа, установленному с помощью аналогового модема) через компоненты сетевой архитектуры Windows 2000. Вот что происходит на этом пути. 1. IP- или IPX-дейтаграмма либо NetBEUI-кадр передается соответствующим протоколом через NDIS (Network Driver Interface Specification) на виртуальный интерфейс, представляющий VPN-соединение. 2. NDIS передает пакет NDISWAN, который расшифровывает и/или декомпрессирует данные и предоставляет РРР-заголовок, включающий только поле идентификатора РРР-протокола. Поля флагов и PCS (Frame Check Sequence) не добавляются. Это предполагает, что на LCP-этапе процесса установления РРР-соединения было согласовано сжатие полей адреса и управления. Подробнее о РРР и LCP см. главу 7 «Сервер удаленного доступа» в этой книге. 3. NDISWAN передает данные драйверу протокола РРТР, который инкапсулирует РРР-кадр в пакет с GRE-заголовком. В поле идентификатора вызова в GRE-;;aголовке записывается значение, идентифицирующее туннель. 4. Полученный пакет драйвер протокола РРТР передает драйверу протоколов TCP/IP. 5. Этот драйвер инкапсулирует туннелированные средствами РРТР данные в пакет с IP-заголовком и передает его через NDIS интерфейсу, представляющему соединение удаленного доступа с местным ISP. 6. NDIS передает пакет NDISWAN, который добавляет РРР-заголовок и концевую часть. 7. NDISWAN передает полученный РРР-кадр минипорт-драйверу WAN, представляющему аппаратные средства удаленного доступа, например асинхронный порт (в случае модемного соединения). Примечание Бы можете согласовать использование шифруемого РРР-соединения по коммутируемому соединению с ISP. Однако делать это не рекомендуется, так как данные, передаваемые по туннелю, уже зашифрованы. Дополнительный уровень шифрования может отрицательно повлиять на производительность.
356
ЧАСТЬ 2
Удаленный доступ
— Пакет начинает свой путь отсюда NDIS NDISWAN Х.25
' РРР-заголовок
IP-заголовок GRE-заголовок РРР-заголовок
i
ISDN
Шифрованные полезные данные РРР Концевая (IP- или IPX-дейтаграмма часть РРР пайс NetBElfl-кадр) , .. :
Структура конечного пакета Рис. 9-10. Обработка РРТР-пакета в сетевой архитектуре Windows 2000
Network Load Balancing и РРТР Компонент Network Load Balancing к Windows 2000 Advanced Server позволяет создать кластер РРТР-сервсров для более надежной поддержки VPN-соединений. Формируя такой кластер с балансировкой нагрузки, придерживайтесь следующей схемы. t. Сконфигурируйте каждого участника кластера как РРТР-сервер Windows 2000. Подробнее на эту тему см. справочную систему Windows 2000 Server. 2. Настройте набор РРТР-ссрверов как кластер Network Load Balancing. Подробнее о настройке Network Load Balancing см. справочную систему Windows 2000 Advanced Server. Настраивая Network Load Balancing на каждом РРТР-сервере, разрешите балансировку сетевой нагрузки на интерфейсе, принимающем запросы на РРТР-соединения. Учтите, что этому интерфейсу назначаются IP-адрес кластера и выделенный IP-адрес. Чтобы избежать проблем при создании РРТРшединений с РРТР-клиентами Windows 95. Windows NT 4.0 и Windows 98, удалите выделенный IP-адрес на интерфейсе, принимающем запросы на РРТР-соединения. Для этого на каждом РРТР-сервере кластера используйте окно свойств TCP/IP, открываемое через апплет Network and Dial-up Connections (Сеть и удаленный доступ к сети). 3. Удаление выделенного IP-адреса не позволит удаленно управлять индивидуальными серверами с использованием ;->того IP-адреса. Поэтому для удаленного управления отдельными РРТР-серверами в кластере нужно установить на каждом сервере дополнительный LAN-интерфейс и подключить его к сегменту сети, отличному от того, к которому подключен интерфейс, принимающий запросы на РРТР-соединения, У РРТР-сервера Интернета обычно имеется дополнительный интерфейс интрасети. После удаления выделенного IP-адреса на Интернет-
ГЛАВА 9
Виртуальные частные сети
357
интерфейсе Вы сможете удаленно управлять этим Р РТР-серне ром ш интрасети (но не из Интернета). Примечание Пока Вы не удалите выделенный IP-адрес РРТР-сервсра, входящего is кластер, РРТР-клиенты Windows 95, Windows NT 4.0 и Windows 98, вероятно, не смогут подключаться к нему. Это связано с тем, что такие клиенты посылают сши запросы на IP-адрес кластера, а индивидуальный РРТР-сервер может ответить на запрос не с кластерного, а с выделенного IP-адреса. В последнем случае РРТР-клиеит обнаружит, что ответ поступил с IP-адреса, отличного от того, на который он посылал запрос, сочтет это нарушением безопасности РРТР-соединения и разорвет связь.
L2TP и IP-безопасность L2TP (Layer Two Tunneling Protocol) — это комбинация РРТР и L2F (Layer 2 Forwarding), технологии, предложенной компанией Cisco® Systems. Inc. Чтобы два несовместимых протокола туннелирования не конкурировали на рынке и не запутывали заказчиков, IETF распорядился скомбинировать эти две технологии в один протокол туннелирования, который сочетал бы в себе лучшие качества РРТР и L2F. L2TP документирован в RFC 2661, L2TP инкапсулирует РРР-кадры, передаваемые по сетям IP, X.25. Frame Relay тии ATM. В настоящее время определен стандарт только на L2TP поверх IP. При передаче по межсетевой IP-среде 1-2ТР-кадры инкапсулируются как UDP-сообщения. L2TP — протокол туннелирования, пригодный для применения как в Интернете, так и в частных интрасетях. L2TP использует UDP-сообщения в межсетевых IP-средах для управления туннелями и передачи туннелированных данных. Полезные данные инкапсулированных РРР-кадров могут быть зашифрованы и/или сжаты; однако Ь2ТР-клиенты под управлением Windows 2000 не могут использовать МРРЕ для L2TP-coe;7iineHHfl. Поэтому шифрование для таких соединений реализуется за счет IPSec-прогокола ESP. Windows 2000 позволяет создавать L2TP-coe/TmneHH#, не шифруемые с помощью IPSec (IP-безопасность). Но в таком случае Вы не получите VPN-соединение, нескольку конфиденциальные данные, инкапсулируемые L2TP, окажутся незашифрованными. Нешифруемые Е2ТР-соединения можно использовать в качестве временной меры при устранении каких-либо проблем с поддержкой соединении L2TP поверх IPSec; при этом Вы исключаете IPSec-процессы аутентификации п согласования. L2TP требует наличия межсетевой IP-среды между Ь2ТР-клиентом (VPN-клиен том, использующим протокол тупнелирования L2TP и IPSec) и L2TP-cepnepoM (VPN-сервером, использующим тот же протокол и IPSec). Е2ТР-клиент может быть уже подключен к межсетевой IP-среде, через которую достижим Е2ТР-сервер, либо он может дозваниваться до сервера NAS и устанавливать IP-соединение — так же как и пользователь, получающий доступ в Интернет по коммутируемой линии. Аутентификация, выполняемая при создании L2TP-туннелей, осуществляется с применением тех же механизмов, что и при установлении РРР-соединений, — например, ЕАР, MS-CHAP, CHAP, SPAP и PAP.
358
ЧАСТЬ 2 Удаленный доступ
L2TP-сервер на основе Интернет-стандартов представляет собой сервер удаленного доступа с поддержкой L2TP; при этом один из его интерфейсов подключен к Интернету, а другой — к интрасети. Пакеты с информацией, управляющей Ь2ТР-туннелем, и туннелированными данными имеют одинаковую структуру.
Поддержание туннеля с помощью управляющих 1_2ТР-сообщений L2TP — в отличие от РРТР — не требует для поддержания туннеля отдельного TCP-соединения. Ь2ТР-трафик передается между Ь2ТР-клиентом и сервером в виде UDP-сообщений. В Windows 2000 для этого используется UDP-порт 1701. Примечание 1.2ТР-клиент и сервер в Windows 2000 всегда используют UDP-порт 1701. Однако Ь2ТР-сервер под управлением Windows 2000 поддерживает L2TPклиенты, работающие с другим UDP-портом. Управляющие сообщения L2TP поверх IP посылаются как UDP-дейтаграммы. В варианте, реализованном в Windows 2000, эти I'DP-дейтаграммы передаются в виде зашифрованных полезных данных IPSec-протокола ESP (рис. 9-11),
•'-.• Концевая Заголовок ШР~ L2TP-. Кошевая часть ISP ESPканального IPчасть ESP Authentication сообщение заголовок заголовок заголовок уровня : • ' L
Концевая часть канального уровня
Шифруется IPSec
Рис. 9-11. Управляющее Ь2ТР-сообщение
Поскольку TCP-соединение не используется, L2TP — чтобы гарантировать доставку Ъ2ТР-сообщений — применяет их упорядочение (message sequencing). Поля Next-Received (по аналогии с TCP-полем подтверждения) и Next-Sent (по аналогии с TCP-полем номера последовательности) внутри управляющего 1.2ТР-сообщения предназначены для слежения за последовательностью сообщений. Пакеты, выпадающие из должной последовательности, отбрасываются. Поля Next-Sent и Next-Received могут также использоваться для упорядоченной доставки и управления потоком туннелировапных данных. L2TP поддерживает по несколько вызовов на каждом туннеле. С этой целью в управляющем Ь2ТР-сообщении в L2TP-заголовке туннелированных данных присутствуют поля идентификатора туннеля и идентификатора вызова (для данного туннеля). Основные управляющие Ь2ТР-сообщения перечислены в таблице 9-6. Таблица 9-6. Основные управляющие Ь2ТР-сообщения Сообщение
Описание
Start-Control-Conitection-Request
Посылается Ь2ТР-клиситом для установления управляющего соединения. До передачи любых других L2TP-сообщений для каждого Ь2ТР-туннеля нужно создать свое управляющее соединение.
ГЛАВА 9 Таблица 9-6.
Виртуальные частные сети
359
(продолжение)
Сообщение
Описание
Siart- Control- Connection-Reply
Посылается L2TP-cepBepOM в ответ на сообщение Start-Control-Cormection-Request (см. также ниже).
Start-Control-Connection-Connected
Посылается L2TP-клиентом в ответ на сообщение Starc-Control-Connection-Reply.
Outgoing-Call-Request
Посылается Ь2ТР-клиентом для создания L2TPтуннеля. В это сообщение включается назначенный идентификатор вызова (Assigned Call ID), определяющий конкретный вызов по данному туннелю. Посылается Ь2ТР-сервером в ответ на сообщение Outgoing-Cail-Rcquest. Посылается Ь2ТР-клиентом в ответ на сообщение Outgoing-Call-Reply.
Outgoing-Call-Reply Start-Control-Connection-Connected Helio
Посылается 1,2ТР-клиентом или сервером для проверки активности соединения. Если прием этого сообщения не подтверждается, Ь2ТР-тукнель через определенное время закрывается. Посылается Ь2ТР-ссрвером всем VPN-клиентам, чтобы сообщить о какой-либо ошибке, возникшей на РРР-интерфейсе L2TP-cepsepa. Посылается LSTP-клиентом или сервером для установки согласованных РРР-параметров.
WAN-Error-Notify
Set-Link-Info Call-Disconnect-Notify
Stop-Control-Conncction-Notification
Посылается Ь2ТР-сервером или клиентом для уведомления другой стороны о том, что данный вызов в данном туннеле должен быть завершен. Посылается L2TP-сервером или клиентом для уведомления другой стороны о том, что туннель должен быть закрыт.
Детальные сведения о точной структуре управляющих Ь2ТР-сообщений см. в проекте Интернет-документа по L2TP.
Туннелирование данных средствами L2TP Такое туннелирование осуществляется путем многоуровневого инкапсулирования. Структура данных, туннелированпых средствами L2TP, показана на рис. 9-12. •"
• Полезные данные Концевая Заголовок (Р-заго- ESP-зшъ УОР-за- 12ГР-за- РРР-заРРР рр-ляи Квицевая часть ESP канального ловок ловок гшовок головои голавок IPX-дейтаграмма часть KSP Authentication уровня либо NetBEUI-кадр)
Коневая часть канал ьяого уровня
Шифруется Подписывается для аутентификации по IPSec-поотоколу ESP Рис. 9-12. Инкапсуляция Ь2ТР-пакета
360
ЧАСТЬ 2
Удаленный доступ
Инкапсуляция L2TP Изначальные полезные данные РРР инкапсулируются с использованием РРР- и Ь2ТР-заголовков. Инкапсуляция UDP Пакет, инкапсулированный L2TP, инкапсулируется в сообщение с UDP-заголОБКОМ, а порты отправителя и получателя устанавливаются как 1701. Инкапсуляция IPSec UDP-сообщение зашифровывается па основе политики IP-безопасности и инкапсулируется в пакет с заголовком и концевой частью ESP (Encapsulating Security Payload); кроме того, добавляется концевая часть ESP Authentication, необходимая для аутентификации по IPSec-протоколу ESP.
Инкапсуляция IP IPSec-пакет инкапсулируется в IP-дейтаграмму с IP-заголовком, который содержит IP-адреса отправителя и получателя, соответствующие VPN-клиенту и серверу.
инкапсуляция канального уровня Для передачи по локальной сети или WAN-каналу созданная на предыдущем этапе IP-дейтаграмма инкапсулируется в пакет с заголовком и концевой частью канального уровня, применяемого на данном физическом интерфейсе. Например, при передаче через Ethernet-интерфейс IP-дейтаграмма инкапсулируется в пакет с Ethernet-заголовком и концевой частью, а при передаче по WAN-каналу типа «точка-точка» (аналоговой телефонной линии или ISDN) — в пакет с РРР-заголовком и концевой частью. Обработка данных, туннелированных L2TP поверх IPSec Получив данные, туннелированные средствами L2TP поверх IPSec, 1_2ТР-клиент или сервер выполняет следующие операции. 1. Обрабатывает и удаляет заголовок и концевую часть канального уровня, 2. Обрабатывает и удаляет IP-заголовок. 3. Используя концевую часть "ESP Authentication, проверяет подлинность полезных данных IP и ESP-заголовка. 4. Используя ESP-заголовок, расшифровывает зашифрованную часть пакета. 5. Обрабатывает UDP-заголовок и передает Ь2ТР-пакет протоколу L2TP. 6. L2TP считывает содержимое полей идентификатора туннеля и идентификатора вызова в L2TP-заголовке, чтобы определить конкретный 1.2ТР-туинель. 7. Идентифицирует по РРР-заголовку полезные данные РРР и передает их драйверу соответствующего протокола для обработки.
Пакеты L2TP поверх IPSec и сетевая архитектура Windows 2QOQ Рис. 9-13 иллюстрирует путь, который проходят туннелированные данные (от VPNклиента по VPN-соединению удаленного доступа, установленному с помощью аналогового модема) через компоненты сетевой архитектуры Windows 2000. Вот что происходит на этом пути.
ГЛАВА 9
1.
Виртуальные частные сети
361
IP- или IPX-дейтаграмма либо NetBEUI-кадр передается соответствующим протоколом через NDIS на виртуальный интерфейс, представляющий VP\"-coед и пение.
2. NDIS передает пакет NDISWAN, который декомпрессирует данные (при необходимости) и предоставляет РРР-заголовок, включающий только поле идентификатора РРР-протокола. Поля флагов и FCS не добавляются, 3. ND1SWAN передает РРР-кадр драйверу протокола L2TP, который инкапсулирует этот кадр в пакет с Ь2ТР-заголовком. В поля идентификаторов туннеля и вызова в Ь2ТР-заголовке записываются значения, идентифицирующие туннель и вызов. 4.
Полученный пакет драйвер протокола L2TP передает драйверу протоколов TCP/IP и уведомляет его о том, что данный Ь2ТР-пакет следует отправить как UDP-сообщение с UDP-порта 1701 клиента в UDP-порт 1701 сервера (при этом указываются IP-адреса клиента и сервера).
5. Драйвер протоколов TCP/IP формирует IP-пакет, добавляя необходимые II*- и UDP-гшголовки. Далее этот IP-пакет анализируется IPSec и приводится в соответствие с текущей политикой IP-безопасности. В зависимости от параметров политики IPSec шифрует UDP-часть IP-пакета и добавляет требуемые заголовок и концевые части ESP. Перед началом ESP-пакета добавляется исходный [Р.чаголовок со значением в поле протокола, равным 50. Затем драйвер протоколов TCP/IP передает полученный пакет через NDIS интерфейсу, представляющему соединение удаленного доступа с местным ISP. 6. NDIS передает пакет NDISXVAN, который добавляет РРР-заголовок и концег:ую часть. 7. NDIS WAN передает полученный РРР-кадр минипорт-драйверу WAN, представляющему аппаратные средства удаленного доступа.
|— Пакет начинает свай путь отсюда '
NDIS
РРР-за- fP-заго- ESP-заго- УОР-за- ШР-аа- РРР-заголовок повок ловок гояоаок fonmoK голшзок
Концевая
Концева;;*
часть ESP часть ESP Authentication часть PF'P
Структура конечного пакета
Рис. 9-13. Обработка Ь2ТР-пакета в сетевой архитектуре Windows 2000
362
ЧАСТЬ 2 Удаленный доступ
Примечание Вы можете согласовать использование шифруемого РРР-соединения по коммутируемому соединению с ISP. Однако делать это не рекомендуется, так как данные, передаваемые по туннелю, уже зашифрованы. Дополнительный уровень шифрования может отрицательно повлиять на производительность.
Защита виртуальных частных сетей Защита — важный элемент VPN. В следующих разделах описываются средства защиты, поддерживаемые РРТР и L2TP поверх IPSec для VPN-соединений.
РРТР-соединения РРТР обеспечивает аутентификацию пользователей и шифрование данных.
Аутентификация пользователей с помощью РРР Пользователь, запрашивающий РРТР-соединение, аутентифицируется по одному из РРР-протоколов аутентификации: ЕАР, MS-CHAP, CHAP, SPAP или PAP. Для РРТР-соединений настоятельно рекомендуется использовать EAP-TLS в сочетании со смарт-картами либо MS-CHAP версии 2, поскольку именно эти протоколы поддерживают взаимную аутентификацию и являются самыми безопасными методами обмена удостоверениями.
Шифрование методом МРРЕ РРТР поддерживает шифрование методом МРРЕ, который основан на алгоритме RSA (Rivest-Shamir-Adleman) RC4. МРРЕ доступен только при использовании EAP-TLS или MS-CHAP (версии 1 или 2). МРРЕ оперирует с 40-, 56- или 128-битными шифровальными ключами. 40-битный ключ предназначен для обратной совместимости с клиентами под управлением операционной системы, отличной от Windows 2000. По умолчанию VPN-клиент и сервер договариваются о применении самого стойкого ключа из числа поддерживаемых. Если VPN-сервер требует более стойкого ключа, не поддерживаемого VPNклиентом, запрос на соединение отклоняется. Изначально МРРЕ был разработан для шифрования данных на пути их передачи по каналу связи тина «точка-точка», где пакеты принимаются в том порядке, в каком они были отправлены, и потери пакетов невелики. В такой среде расшифровка очередного пакета зависит от результатов расшифровки предыдущего. Однако в случае VPN-соединений IP-дейтаграммы, передаваемые по Интернету, могут поступать вовсе не в том порядке, в котором они отправлялись, а пакеты теряются чаще. В связи с этим МРРЕ для VPN-соединении использует отдельный шифровальный ключ для каждого пакета, и расшифровка очередного пакета не зависит от результатов расшифровки предыдущего. В МРРЕ-заголовок включается номер последовательности. Если пакеты теряются или поступают в другом порядке, шифровальные ключи меняются в соответствии с этим номером последовательности.
Фильтрация пакетов средствами РРТР VPN-сервер на основе РРТР обычно снабжен двумя физическими интерфейсами: один подключен к общедоступной сети (например, к Интернету), другой — к частной интрасети. Кроме того, у него имеется виртуальный интерфейс, соединяющий
ГЛАВА 9
Виртуальные частные сети
363
его со всеми VPN-клиентами. Чтобы VPN-сервер мог пересылать трафик между VPN-клиентами, ПА всех его интерфейсах нужно включить поддержку ТР-пересылки. Однако включение поддержки пересылки между двумя физическими интерфейсами приводит к тому, что VPN-сервер перенаправляет весь IP-трафик из общедоступной сети в интрассть. Для защиты интрасети от постороннего трафика Вы должны настроить фильтрацию пакетов в РРТР так, чтобы VPN-сервер передавал данные только между VPN-клиентами и интрасетью и блокировал обмен пакетами между интрасетью и потенциально опасными пользователями общедоступной сети. Фильтрацию пакетов средствами РРТР можно настроить либо на VPN-сервере, либо на промежуточном брандмауэре (см. раздел «Виртуальные частные сети и брандмауэры» далее в этой главе).
Соединения L2TP поверх IPSec «L2TP поверх IPSec» обеспечивает аутентификацию пользователей, взаимную аутентификацию компьютеров, шифрование, аутентификацию данных и проверку их целостности.
Аутентификация пользователей с помощью L2TP поверх IPSec Аутентификация VPN-клиента осуществляется на двух уровнях: сначала проверяется подлинность компьютера, затем — пользователя, IPSec аутентификация компьютеров Взаимная аутентификация компьютеров VPN-клиента и сервера выполняется путем обмена машинными сертификатами при создании IPSec-протоколом ESP сопоставления безопасности (security association, SA). IPSec SA устанавливается на в гором этапе процесса IPSec-согласования; к этому времени стороны также выбирают алгоритмы шифрования и хэширования и договариваются о шифровальных ключах. Для использования L2TP поверх JPSec у VPN-клиента и сервера должны быть машинные сертификаты. Вы можете получать их автоматически, выбрав в Group Policy (Групповая политика) автоматический запрос сертификатов, или вручную — через оснастку Certificates (Сертификаты). Подробнее на эту тему см. справочную систему Windows 2000 Server. LZTP-эутентификация на уровне пользователей Пользователь, запрашивающий Ь2ТР-соединение, аутентифицируется по одному из РРР-протоколов аутентификации: ЕАР, MS-CHAP, CHAP, SPAP или PAP. Поскольку процесс установления РРР-соединения защищается средствами шифрования IPSec, можно использовать любой метод РРР-аутентификации. Взаимная аутентификация на уровне пользователей выполняется только при выборе MS-CHAP v2 или EAP-TLS. Аутентификация 12ТР-туннеля В процессе установления Ь2ТР-туннеля протокол L2TP позволяет аутентифицировать конечные точки этого туннеля. Эта операция называется аутентификацией Ь2ТР-туннеля. По умолчанию Windows 2000 ее не выполняет. Подробнее о и iстройке Windows 2000 на аутентификацию Ь2ТР-туннеля см. по ссылке Microsoft Knowledge Base на Web-странице http://windows.microsoft.com/windows2000/reskit/web resources.
364
ЧАСТЬ 2
Удаленный доступ
Шифрование с помощью L2TP поверх IPSec Метод шифрования выбирается при установлении IPSec SA. Доступные методы шифрования включают: • DES с 56-битным ключом; • 3DES (Triple DES), использующий три 56-битных ключа и предназначенный для сред с жесткими требованиями к безопасности. Так как IPSec рассчитан на межсетевые IP-среды, в которых возможна потеря пакетов и их доставка в неверпом порядке, каждый IPSec-пакет зашифровывается независимо от других IP Sec-пакетов. Исходные шифровальные ключи генерируются в процессе IP See-аутентификации. При соединениях с шифрованием по методу DES новые шифровальные ключи генерируются через каждые 5 минут или 250 Мб переданной информации, а при соединениях с шифрованием по методу 3DES — каждый час или через каждые 2 Гб переданной информации. Для соединений, защищаемых АН, новые хэш-ключи тоже генерируются каждый час или через каждые 2 Гб переданной информации, Подробнее об IPSec см. главу 8 «IP-безопасность» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server».
Аутентификация данных и проверка их целостности средствами L2TP поверх IPSec Аутентификация и проверка целостности данных реализуется одним из следующих алгоритмов: • НМАС (Hash Message Authentication Code) MD5 (Message Digest 5) — генерирует 128-битный хэш аутентифипированных полезных данных; • НМАС SHA (Secure Hash Algorithm) — генерирует 160-битный хэш аутентифицированных полезных данных.
Фильтрация пакетов средствами L2TP поверх IPSec Как и в случае VPN-соединений на основе РРТР, включение поддержки пересылки между интерфейсами общедоступной сети и интрасети приводит к тому, что VPNсервер перенаправляет весь IP-трафик из общедоступной сети в интрасеть. Для защиты интрасети от постороннего трафика Вы должны настроить фильтрацию пакетов средствами L2TP поверх IPSec так, чтобы VPN-сервер передавал данные только между VPN-клиентами и интрасетью и блокировал обмен пакетами между иптрасетыо и потенциально опасными пользователями общедоступной сети. Фильтрацию пакетов средствами L2TP поверх IPSec можно настроить либо на VPN-сервере, либо на промежуточном брандмауэре (см. раздел «Виртуальные частные сети и брандмауэры* далее в этой главе).
Адресация и маршрутизация при использовании виртуальных частных сетей Чтобы понять, как работают виртуальные частные сети (VPN), Вы должны разобраться в том, как создание VPN-соединений удаленного доступа и VPN-соединении между маршрутизаторами влияет на адресацию и маршрутизацию. VPN-соединение образует виртуальный интерфейс, которому нужно назначить соответствую-
ГЛАВА 9
Виртуальные частные сети
365
щий IP-адрес; кроме того, следует изменить или добавить маршруты, чтобы требуемый трафик передавался но защищенному VPN-соединению, а не пи транзитной межсетевой среде.
VPN-соединения удаленного доступа При VPN-соединении удаленного доступа компьютер подключается к VPN-серверу. В процессе установления соединения VPN-сервер назначает VPN-клиенту IPадрес и изменяет маршрут по умолчанию на удаленном клиенте, чтобы соответствующий трафик передавался по виртуальному интерфейсу.
IP-адреса и VPN-клиент удаленного доступа VPN-клиент удаленного доступа перед созданием VPN-соединения с VPN-сервером сначала подключается к Интернету и из-за этого получает два IP-адреса: • при установлении РРР-соедииения NAS-сервер ISP присваивает клиенту обгний IP-адрес (в IPCP-пропессе согласования); •
при создании VPN-соединения VPN-сервер (в ГРСР-пропессе согласования) назначает клиенту IP-адрес из диапазона адресов своей интрасети. Этот ТР-адрес может быть общим (видимым в Интернете) или частным (невидимым в Интернете) в зависимости от того, какие адреса используются в данной интрасети — общие или частные.
В любом случае IP-адрес, выделенный VPN-клиенту, должен быть достижим для хостов в интрасети и наоборот, В таблице маршрутизации на VPN-сервере должны быть записи, позволяющие связаться с любыми хостами в интрасети, а в аналогичных таблицах на маршрутизаторах — записи, необходимые для взаимодействия с VPN-клиентами. В IP-заголовке туннслиропанньгх данных, посылаемых через VPN, указываются адрес, выделенный клиенту VPN-сервером, и адрес интрасети, а во внешнем IP-заголовке — IP-адрес, выделенный клиенту провайдером, и общий адрес VPN-сервера. Поскольку маршрутизаторы в Интернете обрабатывают только внешние IP-заголовки, они пересылают туннелировапные данные на общий IP-адрес VPN-сервера. Пример адресации при удаленном доступе показан на рис. 9-14. В данной интрасети используются частные адреса, и, кроме того, тупнелированпые данные передаются в виде IP-дейтаграмм.
Маршруты по умолчанию и клиенты удаленного доступа Когда клиент удаленного доступа дозванивается до ISP, он обычно получает общий IP-адрес от NAS-сервера ISP. При этом адрес основного шлюза в IPCP-пропессе согласования не назначается. Поэтому, чтобы иметь возможность обращаться по любым адресам в Интернете, клиент удаленного доступа добавляет в свою таблицу маршрутизации маршрут по умолчанию, использующий интерфейс удаленного доступа, подключенный к ISP В результате клиент может посылать IP-дейтаграммы NAbсерверу 1SP, через который они перенаправляются на нужные адреса R Интернете. Если у клиента удаленного доступа нет других TCP/IP-интерфейсов, именно этч схема ему и нужна. Но она может вызвать проблемы в случае клиентов удаленного доступа, имеющих LAN-подключение к какой-либо интрасети. В этом вариант'.' маршрут по умолчанию уже существует и указывает па локальный маршрутизатор
366
ЧАСТЬ 2
Удаленный доступ
интрасети. Когда клиент удаленного доступа устанавливает соединение со своим ISP, исходный маршрут по умолчанию остается в таблице маршрутизации, но получает метрику с более высоким значением. Кроме того, добавляется новый маршрут по умолчанию с меньшей метрикой, соответствующий подключению к ISP. В итоге адреса в интрасети, находящиеся вне сети, к которой клиент удаленного доступа подключен напрямую, оказываются недостижимыми в течение всего сеанса связи с ISP. Если бы в таблице маршрутизации не появлялся новый маршрут по умолчанию, клиенту были бы доступны любые адреса в интрасети, но не в Интернете. Клиент удаленного доступа под управлением Windows 2000 создает такой маршрут автоматически (по умолчанию). • Общие адреса IP-адрес назначения: VPN-сервер IP-адрес источника: выделяется ISP IP
6RE
РРР
~ Частные адреса IP-адрес назначения: целевая интрасеть IP-адрес источника: выделяется VPN-сервер IP
г
1CP
ШР
Данные приложения
ISP
VPN-соединение
Клиент удаленного доступа Рис. 9-14, Общие и частные адреса в данных, туннелированных РРТР ^ Чтобы запретить создание маршрута по умолчанию: 1 В свойствах TCP/IP объекта соединения удаленного доступа откройте диалоговое окно Advanced TCP/IP Settings (Дополнительные параметры TCP/IP), перейдите на вкладку General (Обшие) и сбросьте флажок Use default gateway on remote network (Использовать основной шлюз в удаленной сети), Чтобы обеспечить связь как с адресами в интрасети, так и с адресами и Интернете, пока активно соединение с ISP, не сбрасывайте флажок Use default gateway on remote network, а в таблицу маршрутизации на клиенте удаленного доступа добавьте маршруты к интрасети. Эти маршруты можно добавить как статические (коман-
ГЛАВА 9
Виртуальные частные сети
367
дои route) или, если в интрасети используется протокол марифутизации RIP Персии 1, воспользоваться службой Route Listening Service для прослушивания трафика RiP vl и динамического добавления нужных маршрутов. Тогда после соединения с ISP все адреса в интрасети будут достижимы через маршруты к интрасети, а все адреса в Интернете — через маршрут по умолчанию.
Маршруты по умолчанию и VPN-соединения через Интернет Когда клиент удаленного доступа дозванивается до ISP, он добавляет в свою таблицу марифутизации маршрут по умолчанию, использующий соединение с JSP (рис. 9-15). С этого момента ему доступны все адреса в Интернете через маршрутизатор ш NAS-сервере ISP. г Маршрут по умолчанию
Интрасеть Рис. 9-15. Маршрут по умолчанию, созданный после установления соединения с ISP Когда VPN-клиент создает VPN-соединение, в его таблицу маршрутизации добавляются еще один маршрут по умолчанию и маршрут к хосту, которые указывают IP-адрес сервера туннелирования (рис. 9-16). Прежний маршрут по умолчанию сохраняется, но его метрика увеличивается. Добавление нового маршрута по умолчанию означает, что все адреса в Интернете, кроме IP-адреса сервера туннелирования, недостижимы до закрытия VPN-соединения. г VPN-соединение
Туннель
- Маршрут по умолчанию
ISI
Интрасеть
Рис. 9-16. Маршрут по умолчанию, созданный после инициации VPN-соединения
368
ЧАСТЬ 2
Удаленный доступ
Как и в случае клиента удаленного доступа, подключающегося к Интернегу, создание VPN-клиентом удаленного доступа VPN-соединения с частной интрасетью через Интернет влечет за собой одно из следующих последствий: • пока VPN-соединение неактивно, адреса в Интернете достижимы, а в интрасети — пет; • пока VPN-соединение активно, адреса в интрасети достижимы, а в Интернете — нет. Для большинства VPN-клиентов, подключенных к Интернету, такая схема не создает никаких проблем, потому что они, как правило, поддерживают коммуникационную связь либо с интрасетью. либо с Интернетом, но не то и другое одновременно. Л что касается VPN-клиентов, которым после установления VPN-соединения нужен одновременный доступ и к интрасети, и к Интернету, то конкретное решение зависит от типа адресации в интрасети. Но в любом случае объект VPN-соединения следует настроить так, чтобы новый основной шлюз не добавлялся. Тогда после создания VPN-соединения маршрут по умолчанию будет по-прежнему указывать адрес NAS-сервера ISP, что позволит обращаться по любым адресам в Интернете. Исходя из тина адресации в интрасети одновременный доступ к ресурсам интрасети и Интернета реализуется следующим образом. Общие адреса. Добавьте статические постоянные маршруты к общим адресам интрасети с использованием IP-адреса виртуального интерфейса VPN-сервера в качестве IP-адреса шлюза. Частные адреса. Добавьте статические постоянные маршруты к частным адресам интрасети с использованием IP-адреса виртуального интерфейса VPN-сервера в качестве IP-адреса шлюза. Перекрывающиеся или недопустимые адреса. Если в интрасети используются перекрывающиеся (overlapping) или недопустимые (illegal) адреса (идентификаторы IP-сетей, которые не являются частными и либо не зарегистрированы в InterNIC, либо получены от ISP), эти IP-адреса могут дублировать общие адреса в Интернете. Если в таблицу маршрутизации на VPN-клиенте добавляются статические постоянные маршруты с перекрывающимися адресами, то совпадающие: с ними адреса в Интернете недостижимы. В каждом из этих случаев в таблицу маршрутизации на VPN-клиенте нужно добавлять статические постоянные маршруты к идентификаторам сетей, используемым в интрасети. Постоянные маршруты записываются в реестр, В Windows NT 4.0 с Service Pack 3 (или выше) и в Windows 2000 постоянные маршруты на самом деле не добавляются в таблицу IP-маршрутизации (и невидимы команде route print в Windows 2000) до тех пор, пока IP-адрес шлюза не станет достижимым. А это происходит после установления VPN-соединения. Каждый маршрут добавляется следующей командой: ROUTE ADD <идентификатор_сети_для_интрасети> HASK <маска_сети> <1Р-адрес_виртуального_интерфейса__УРН-сервера> -р
IP-адрес шлюза в командах route для каждого маршрута интрасети — это IP-адрес виртуального интерфейса VPN-сервера, а не его Интернет-интерфейса.
ГЛАВА Э
Виртуальные частные сети
369
Вы можете определить IP-адрес виртуального интерфейса VPN-сервера но IP-адресу интерфейса Internal (Внутренний), раскрыв в оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) узлы IP Routing (IP-маршрутизация) и General (Общие). Если IP-адреса для VPN-клиентов и удаленного доступа к сетям выделяются через DHCP, то IP-адрес виртуального интерфейса VPN-сервера является первым ТР-адресом, полученным от DHCP. Если Вы сконфигурировали статический пул IP-адресов, то IP-адрес виртуального интерфейса VPN-сервера — первый IP-адрес из этого пула. Вы можете выяснить IP-адрес виртуального интерфейса VPN-сервера и таким способом: дважды щелкните объект активного VPNсоединения и в диалоговом окне Status (Состояние) перейдите на вкладку Details (Сведения). Внимание Будьте очень осторожны при добавлении маршрутов, чтобы гарантировать передачу трафика, связанного с интрасетью, по VPN-, а не по РРР-соединению с ISP. Если Вы добавите неправильные маршруты, то трафик, который должен был бы пересылаться через VPN в зашифрованном виде, будет передаваться через Интернет открытым текстом. Например, если идентификатор сети для Вашей интрасети равен 207.46.130.0/24 (маска подсети — 255.255.255.0) и Вы по ошибке добавили постоянный статический маршрут к 207.46.131.0/24, то весь трафик в интрассть 207.46.130.0/24 будет пересылаться через Интернет открытым текстом, а не через VPN-соединение в зашифрованном виде.
VPN-соединения между маршрутизаторами В случае VPX-соедипений между маршрутизаторами пересылка пакетов осуществляется через интерфейс соединения по требованию (demand-dial interface), настраиваемый следующим образом. •
На вкладке General (Общие) введите хост-имя или IP-адрес VPN-сервера,
•
На вкладке Security (Безопасность) выберите либо шифрование пароля и данных, либо переключатель Custom (Дополнительные (особые параметры)]. Выбрав Custom. Вы должны указать подходящие параметры шифрования и аутентификации.
•
На вкладке Networking (Сеть) укажите нужный тип сервера и протоколы, подлежащие маршрутизации. Если в качестве типа сервера Вы выбрали вариант Automatic (Автоматически), то сначала предпринимается попытка установить соединение L2TP поверх IPSec, затем РРТР-соединенис.
•
В окне Interface Credentials (Учетные данные для интерфейса) введите имя пользователя, пароль и имя домена, применяемые для проверки вызывающей» маршрутизатора.
В создании интерфейсов соединения по требованию помогает Demand-Dial Interface Wizard (Мастер интерфейса вызова по требованию). Имя такого интерфейса на отвечающем маршрутизаторе должно совпадать с именем пользователя в удостоверениях (учетных данных) вызывающего маршрутизатора и наоборот — иначе Вам не удастся установить VPN-соединение между маршрутизаторами (см. главу 6 «Маршрутизация с соединением по требованию» в этой книге). 15 Зак 3343
370
ЧАСТЬ 2
Удаленный доступ
Временные и постоянные VPN-соединения между маршрутизаторами VPN-соединения между маршрутизаторами могут быть временными или постоянными. •
Временные соединения создаются для пересылки пакетов через VPN-интерфейс соединения по требованию и закрываются по истечении определенного времени простоя. Этот интервал задается как на VPN-клиенте (вызывающем маршрутизаторе), так и на VPN-сервере (вызываемом маршрутизаторе). По умолчанию время простоя для интерфейсов соединения по требованию на VPN-клиенте не ограничено, а на VPN-сервере — составляет 20 минут. Эти интервалы можно изменить по своему усмотрению. Временные VPN-соединения между маршрутизаторами рекомендуется использовать в филиалах, сначала подключающихся к Интернету через местных провайдеров.
• Постоянные соединения создаются при запуске маршрутизатора и существуют независимо от того, пересылается по ним трафик или нет. Если VPN-соединение закрывается, оно автоматически восстанавливается. Используйте постоянные VPN-соединения между маршрутизаторами в офисах, располагающих постоянными подключениями к Интернету. ^ Чтобы сделать соединение временным или постоянным: 1. В оснастке Routing and Remote Access (Маршрутизация и удаленный доступ) выберите Routing Interfaces (Интерфейсы маршрутизации). 2. Щелкните правой кнопкой мыши нужный интерфейс соединения по требованию и выберите команду Properties (Свойства). 3. На вкладке Options (Параметры) в разделе Connection Type (Тип подключения) выберите один из переключателей: либо Demand dial (Вызов по требованию), либо Persistent (Постоянное подключение).
VPN-соединения через подключение удаленного доступа с ISP Если и VPN-сервер, и VPN-клиент напрямую подключены к Интернету по постоянному WAN-каналу типа Т1 или Frame Relay, VPN-соединение может быть постоянным и действовать круглосуточно. Однако, если у Вас нет постоянного WAN-капала или если его применение нерентабельно, Вы можете сконфигурировать VPNсоединение между маршрутизаторами, устанавливаемое по требованию и использующее подключение удаленного доступа к ISP. Для этого VPN-соединения нужно два интерфейса соединения по требованию: один обеспечивает подключение к местному TSP, другой — создание VPN-соединения между маршрутизаторами. Временное VPN-соединение между маршрутизаторами устанавливается автоматически, когда маршрутизатор филиала принимает трафик, подлежащий пересылке по VPN-соединению. Например, получив пакет, который нужно переслать в центральный офис, маршрутизатор филиала сначала связывается с местным ISP по коммутируемой линии. Подключившись к Интернету, маршрутизатор филиала (VPNклиеит) создает межмаршрутизаторное VPN-соединение с маршрутизатором центрального офиса (VPN-сервером).
ГЛАВА 9
Виртуальные частные сети
371
^ Чтобы настроить маршрутизатор филиала: 1. Добавьте интерфейс соединения по требованию для подключения к Интернету и настройте его на использование нужного оборудования (модема или ISDNустройства). Затем укажите телефонный номер местного ISP, имя и пароль пользователя, необходимые для получения доступа в Интернет. 2. Добавьте интерфейс соединения по требованию для межмаршрутизаторного VPN-соединения с маршрутизатором центрального офиса и настройте его на использование РРТР или L2TP Затем укажите IP-адрес или хост-имя Интернет-интерфейса VPN-сервера центрального офиса, а также имя и пароль пользователя, которые сможет проверить VPN-сервер. Имя пользователя должно совпадать с именем интерфейса соединения по требованию на VPN-сервере центрального офиса. 3. Создайте статический маршрут к хосту для IP-адреса Интернет-интерфейса VPN-сервера; этот маршрут должен использовать интерфейс соединения по требованию, через который маршрутизатор (рилнала связывается с местным ISP. 4. Создайте статический маршрут или маршруты для идентификаторов сетей в корпоративной интрасети; эти маршруты должны использовать VPN-интерфейс соединения по требованию. ^ Чтобы настроить маршрутизатор центрального офиса: 1. Добавьте интерфейс соединения по требованию для VPN-соединения с маршрутизатором филиала и настройте его на использование VPN-устройства (РРТР- или L2TP-порта). Имя интерфейса соединения по требованию должно совпадать с именем пользователя в аутентификационных удостоверениях маршрутизатора филиала. 2. Создайте статический маршрут или маршруты для идентификаторов сетей в интрасети филиала; эти маршруты должны использовать VPN-интерфейс соединения но требованию. VPN-соединение между маршрутизаторами автоматически инициируется маршрутизатором филиала, и вот что при этом происходит. 1. Пакеты, передаваемые в корпоративную сеть от пользователя в сети филиала, пересылаются клиентским компьютером этого пользователя на маршрутизатор филиала. 2. Маршрутизатор филиала просматривает свою таблицу маршрутизации и находит нужный маршрут, использующий VPN-интерфейс соединения по требованию. 3. Маршрутизатор филиала проверяет VPN-интерфейс соединения по требованию и обнаруживает, что он находится в отключенном состоянии. 4. Маршрутизатор филиала считывает конфигурационные параметры этого интерфейса. 5. На основе полученных параметров маршрутизатор филиала пытается инициализировать VPN-соединение между маршрутизаторами, используя IP-адрес VPN-сервера в Интернете. 6. Для создания VPN-соединения нужно либо установить TCP-соединение (при использовании РРТР), либо выполнить процесс согласования IPSec с VPN-сервером. С этой целью генерируется пакет запроса на VPN-соединение.
372
ЧАСТЬ 2
Удаленный доступ
7. Чтобы переслать этот пакет маршрутизатору центрального офиса, маршрутизатор филиала отыскивает в своей таблице маршрутизации маршрут к хосту, указывающий на ISP-интерфейс соединения по требованию. 8. Маршрутизатор филиала проверяет ISP-интерфейс соединения по требованию и обнаруживает, что он находится в отключенном состоянии. 9. Маршрутизатор филиала считывает конфигурационные параметры этого интерфейса. 10. На основе полученных параметров маршрутизатор филиала устанавливает соединение с местным ISP по модему или через ISDN-адаптер. 11. Установив соединение с 1SP, маршрутизатор филиала посылает маршрутизатору центрального офиса пакет запроса на VPN-соединение. 12. После этого оба маршрутизатора согласуют параметры VPN-соединения. В процессе согласования маршрутизатор филиала посылает аутентификапионные удостоверения, проверяемые маршрутизатором центрального офиса. 13. Маршрутизатор центрального офиса проверяет свои интерфейсы соединения по требованию и выбирает тот, чье имя совпадает с именем пользователя, указанным при аутентификации. Затем ;>тот интерфейс переводится в подключенное состояние. 14. Маршрутизатор филиала отправляет пакеты по VPN-соединению, а VPN-сервер пересылает их па соответствующий адрес в корпоративной сети,
Статическая и динамическая маршрутизация Создав интерфейсы соединения по требованию и сделав выбор между временными и постоянными соединениями, Вы должны решить, каким способом следует добавлять информацию о маршрутах в таблицу маршрутизации. 1. В случае временных соединений Вы можете вручную добавить нужные статические маршруты, позволяющие достичь адресов в сетях других офисов. Этот вариант подходит для малых межсетевых сред с небольшим числом маршрутов. 2. В случае временных соединений Вы можете использовать механизм автостатических обновлений для периодического обновления статических маршрутов, обеспечивающих передачу пакетов но VPN-соединению между маршрутизаторами. Этот вариант хорошо работает в крупных межсетевых средах с большим количеством маршрутов. Подробнее об автостатических обновлениях см. главу 6 «Маршрутизация с соединением по требованию» в этой книге. 3. В случае постоянных соединений разрешите функционирование нужных протоколов маршрутизации через VPN-соединение между маршрутизаторами. Протоколы будут считать это VPN-соединение каналом связи типа «точка-точка». Примечание В отличие от маршрутизации с соединением по требованию на основе прямых физических подключений в данном случае IP-маршрут по умолчанию, созданный для VPN-интерфейса соединения по требованию, не годится для суммирования всех маршрутов интрассти, доступных через VPN. Поскольку маршрутизатор подключен к Интернету, маршрут по умолчанию должен суммировать все маршруты Интернета, и Вы должны настроить его на использование Интернет-интерфейса.
ГЛАВА 9
Виртуальные частные сети
373
Аутентификация на основе общего ключа при использовании L2TP поверх IPSec для VPN-соединений между маршрутизаторами По умолчанию Ь2ТР-клиент и Е2ТР-сервер Windows 2000 настраиваются на IPSecаутентификацию на основе сертификатов. Ко1'да Вы устанавливаете соединение L2TP поверх IPSec, автоматически создается политика IP-безопасности, заставляющая IKE (Internet Key Exchange) в процессе согласования параметров защиты для L2TP использовать аутентификацию на основе сертификатов. Это означает, что у Ь2ТР-клиента и сервера должны быть машинные сертификаты. Они могут быть получены от центра сертификации (certificate authority, CA), либо на каждом компьютере должна быть установлена копия корневого сертификата СА другой стороны, полученная из хранилища доверенного корневого центра сертификации. ] Iодроб нее на эту тему см. книгу «Распределенные системы» из серии «Ресурсы Microsoft Windows 20QO Server*. Иногда IPSec-аутентификация на основе сертификатов для VPN-соединений между маршрутизаторами с использованием L2TP нежелательна — например, когда у Вас небольшая организация и Вы пе хотите развертывать инфраструктуру сертификации или когда Вы подключаетесь к маршрутизаторам, не поддерживающим такой вид IPSec-аутентификации. В таких случаях Вы можете вручную создать политику IP-безопасности, заставляющую при установлении VPN-соединений между маршрутизаторами использовать общие ключи (pre-sharcd keys). Подобный ключ действует как простой пароль в IKE-процессе согласования: если обе стороны подтверждают, что им известен этот пароль, значит, они доверяют друг другу и могут продолжить согласование закрытых ключей симметричного шифрования и специфических параметров защиты Ь2ТР-трафика. Общий ключ IKE считается менее надежным, чем сертификаты, поскольку IKEаутентификация (и неявное доверие) зависит лить от одного ключа, значение которого хранится в политике IP-безопасности открытым текстом. Любой человек, просмотрев параметры этой политики, узнает значение общего ключа. Получив лтот ключ, злоумышленник мог бы сконфигурировать свою систему в соответствии с параметрами IPSec Вашей системы. Однако Ь2ТР-соединение требует проверки подлинности на уровне пользователя с применением одного из РРР-протоколов аутентификации. Поэтому для успешного установления соединения L2TP ттоиерх IPSec одного общего ключа мало — нужно знать еще и учетные данные. Для перехода на аутентификацию на основе общего ключа применительно к межмаршрутизаторным VPN-соединениям L2TP поверх IPSec нужно модифицировать реестр и соответственно настроить параметры политики IP-безопасности. Чтобы запретить службе маршрутизации и удаленного доступа автоматически создавать политику IP-безопасности для Ь2ТР-трафика, присвойте параметру РгоhibitlpSec в разделе реестра HKEY_LOCAL_MACHINE\Syslem\CurrentContro1Set\Services\RasMan\Parameters значение 1. По умолчанию ProhibitlpSec равен 0. Когда Вы меняете значение ProhibitlpSec на 1, параметры шифрования для интерфейса соединения по требованию на вызывающем маршрутизаторе замещаются параметрами шифрования из созданной Вами политики IP-безопасности. Перезагрузите компьютер, чтобы эти изменения вступили в силу.
374
ЧАСТЬ 2 Удаленный доступ
Настройка IPSec зависит от следующего. •
Если VPN-сервер является автономным или входит в домен Windows NT 4.0, Вы должны настроить локальную политику IP-безопасности. • Если VPN-сервер входит в домен Windows 2000, локальные политики [Р-безопасности замещаются политиками IP-безопасности данного домена. Чтобы сформировать политику IP-безопасности, применяемую только к Вашему VPNсерверу, создайте в службе каталогов Active Directory организационную единицу (OU), включите в нее учетную запись компьютера VPN-сервера и используйте групповую политику для создания и назначения политик IP-безопасности для OU, в которую входит VPN-сервер. Тогда эти политики будут распространены на Ваш VPN-сервер, Прежде чем создавать политику IP-безопасности, Вы должны решить, будут ли все подключаемые сайты использовать одинаковый общий ключ или для каждого соединения потребуется свой общий ключ. От этого решения зависит характер настройки списка фильтров IPSec и политики. Одинаковый общий ключ приемлем, если обе конечные точки Е2ТР-туннеля контролируются одним администратором. Если же Е2ТР-туннели создаются между системами, управляемыми разными администраторами, желательно использовать отдельный общий ключ на каждое VPN-соединение. Так, единственный VPN-сервер Windows 2000 может быть настроен на коммуникационную связь с шестью бизнеспартнерами, каждому из которых для Ь2ТР-соединений понадобится свой общий ключ. В следующих разделах рассматривается два примера конфигурации IPSec для маршрутизатора, использующего аутентификацию на основе общего ключа при межмаршрутизаторных VPN-соединениях L2TP поверх IPSec с центральным офисом в Нью-Йорке и двумя филиалами — в Бостоне и Лондоне. Примечание Если Ваш VPN-сервер W i n d o w s 2000 взаимодействует с другими L2TP-клиентами или серверами, используя IPSec-аутентификацию на основе сертификатов (она предлагается но умолчанию), но для одного из Е2ТР/1Р5ес-туннелей Вам нужна IP See-аутентификация на основе общего ключа, тогда Вы должны включить в политику IP-безопасности и правило для аутентификации на основе общего ключа, и правила для аутентификации на основе сертификатов (предназначенные для остальных систем).
Одинаковый общий ключ для всех соединений Чтобы использовать одинаковый общий ключ для всех межмаршрутизаторных VPN-соединений L2TP поверх IPSec, выполните следующие операции. 1. Откройте оснастку Routing and Remote Access (Маршрутизация и удаленный доступ) и создайте нужные интерфейсы соединения по требованию. В данном случае создайте два интерфейса соединения по требованию: один — для подключения к филиалу в Бостоне, другой — для подключения к филиалу в Лондоне. 2. Откройте оснастку IP Security Policies (Политики безопасности IP) и определите действие IPSec-фильтра, которое запрещает незащищенную Ь2ТР-связь. 3. Создайте список IPSec-фильтров для всех соединений L2TP поверх IPSec, использующих одинаковый общий ключ ЖЕ. Каждый фильтр внутри списка дол-
ГЛАВА 9
Виртуальные частные сети
375
жен быть предназначен для определенного адреса. В нашем примере нужен список из двух фильтров, один из которых определяет Ь2ТР-трафик для маршрутизатора в Бостоне, а другой - Ь2ТР-трафик для маршрутизатора п Лондоне. 4. Создайте новую политику IP-безопасности с единственным правилом -- оно должно использовать действие фильтра, запрещающее незащищенную I..2TPсвязь, список фильтров для всех соединений L2TP поверх IPSec и аутентификацию на основе общего ключа. Определение действия фильтра Чтобы определить действие фильтра, запрещающее незащищенную коммуникационную связь по L2TP, настройте следующие свойства. •
На вкладке General (Общие): • •
в поле Name (Имя) введите Secure L2TP (образец); в поле Description (Описание) введите, например: Требует согласования параметров входящего соединения. Игнорирует запросы открытым текстом. Заставляет согласовывать параметры исходящего соединения, • На вкладке Security Methods (Методы безопасности): • выберите переключатель Negotiate security (Согласовать безопасность) и добавьте в список тип High (Высокая) (как минимум). При необходимости включите в список дополнительные типы; • сбросьте флажки Accept unsecured communication, but always respond using IPSec (Принимать небезопасную связь, но отвечать с помощью IPSec) и Allow unsecured with non IPSec-aware computer (Разрешать связь с компьютерами, не поддерживающими IPSec). При необходимости установите флажок Session key Perfect Forward Secrecy [Сеансовые циклы безопасной пересылки (PFS)J*. В рассматриваемом здесь примере для всех адресов назначения используется шифрование одинаковой стойкости. Однако Вам могут понадобиться действия фильтра, специфичные для конкретного адреса назначения (зависящие от возможностей данной удаленной системы в поддержке IP-безопасности). Допустим, действие фильтра для Бостона требует шифрования по методу 3DES, а для Лондона - по методу DES (из-за ограничений па экспорт технологий шифрования). Тогда создайте список методов безопасности для одного и того же действия фильтра, поместив метод 3DES первым, чтобы он использовался в тех случаях, когда это возможно. Создание списка фильтров при использовании одинакового общего ключа для всех соединений Чтобы получить список фильтров, охватывающий все межмаршрутизаторные VPNсоединения на основе L2TP, создайте список фильтров и настройте следующие его свойства. • •
Имя: L2TP connections (образец). Описание: Адреса назначения для L2TP-соединений с аутентификацией по общему ключу (образец).
* Название этого флажка в русской версии Windows 2000 Server требует пояснения: ec.'iv этот флажок установлен, сеансовые ключи и материалы для ключей повторно не используется. — Прим. перев.
ЧАСТЬ 2 Удаленный доступ
376
Теперь для каждого адреса назначения создайте фильтр (в рамках списка) со следующей конфигурацией. •
На вкладке Addressing (Адресация): • в Source Address (Адрес источника пакетов) выберите A specific IP Address (Определенный IP-адрес) и введите IP-адрес Интернет-интерфейса локального маршрутизатора. В данном случае укажите IP-адрес Интернет-интерфейса маршрутизатора в Нью-Йорке: • в Destination Address (Адрес назначения пакетов) выберите A specific IP Address и введите IP-адрес Интернет-интерфейса маршрутизатора на другой стороне данного межмаршрутизаторного VPN-соединения. В данном случае укажите IP-адрес Интернет-интерфейса маршрутизатора в Бостоне; • установите флажок Mirrored (Отраженный).
•
На вкладке Protocol (Протокол): • в Select a protocol type (Выберите тип протокола) выберите UDP (UDP); •
•
в Set the IP protocol port (Установка порта для протокола IP) выберите переключатель From this port (Пакеты из этого порта) и тип 1701, а затем выберите переключатель То any port (Пакеты на любой порт).
На вкладке Description (Описание): •
в поле Description (Описание) введите соответствующий пояснительный текст. Например, для соединения с Бостоном введите L2TP-coedunenue с Бостоном. Этот текст появится в утилите для мониторинга IPSec (ipsecmon).
Настройка политики IP-безопасности на использование одинакового общего ключа Чтобы сформировать политику IP-безопасности, использующую одинаковый обгний ключ для всех межмаршрутизаторных VPN-соединений на основе L2TP, создайте политику IP-безопасности со следующими свойствами. • На вкладке General (Общие): • в поле Name (Имя) введите Pre-sharc.d key L2TP Connections (образец); • в поле Description (Описание) введите, например: IPSec-аутентификация на основе общего ключа для межмаршрутизаторных VPN-соединений L2TP поверх IPSec; • при необходимости модифицируйте значения параметров Check for policy changes every (Проверять политику на наличие изменений каждые) и Advanced (Дополнительно). • На вкладке Rules (Правила): • удалите правило Default Response (Отклик по умолчанию). Добавьте правило со следующими свойствами. •
На вкладке IP Filter List (Список фильтров IP): • выберите список IP-фильтров, соответствующий всем Ъ2ТР-соединениям со всеми филиалами. В нашем примере это список L2TP connections. • На вкладке Filter Action (Действие фильтра): •
выберите действие фильтра, запрещающее незащищенную Ь2ТР-свя;*ь. В нашем примере это Secure L2TP.
ГЛАВА 9
Виртуальные частные сети
377
•
На вкладке Authentication Methods (Мотели проверки подлинности): • в разделе Authentication Method preference order (Порядок предпочтений методов проверки подлинности) определите единственный метод на основе общего ключа. Укажите содержимое этого ключа, одинакового для всех маршрутизаторов, с которыми данный маршрутизатор устанавливает соединение L2TP поверх IPSec с применением аутентификации па основе общего ключа. Учтите, что ключ должен быть длиной не менее 20 символов и что он должен состоять из переметанного набора букв верхнего и нижнего регистра, чисел и знаков препинания. • На вкладке Tunnel Setting (Параметры туннеля): •
выберите This rule does not specify an IPSec tunnel (Это правило не указывает туннель IPSec). • На вкладке Connection Type (Тип подключения): • выберите All network connections (Все сетевые подключения). Поскольку список фильтров охватывает все адреса назначения для VPN-соединений между маршрутизаторами на основе L2TP, в политике IP-безопасности требуется лишь одно правило.
Раздельные общие ключи для разных соединений Чтобы использовать раздельные общие ключи для всех VPN-соединений между маршрутизаторами на основе L2TP поверх IPSec, выполните следующие операции. 1. Создайте нужные интерфейсы соединения по требованию. В данном случае добавьте два таких интерфейса: один — для соединения с филиалом в Бостоне, другой — для соединения с филиалом в Лондоне. 2. Определите действие фильтра, запрещающее незащищенную Ь2ТР-связь. 3. Создайте список IPSec-фильтров с единственным фильтром для соединения L2TP поверх IPSec с определенным адресом. В нашем примере нужно создать два списка фильтров, каждый с единственным фильтром; при этом один фильтр определяет 1_2ТР-трафик, адресуемый маршрутизатору в Бостоне, а другой Ь2ТР-трафик, направляемый маршрутизатору в Лондоне. /
1. Создайте новую политику IP-безопасности с набором правил; каждое правило должно использовать действие фильтра, запрещающее незащищенную L2TPсвязь, список фильтров для определенного соединения L2TP поверх IPScc и аутентификацию на основе общего ключа для этого соединения.
Определение действия фильтра Здесь Ваши действия идентичны уже рассмотренным ранее при использовании одинакового общего ключа для всех соединений. Создание списка фильтров при использовании разных общих ключей для каждого соединения Чтобы получить список фильтров, охватывающий определенное межмаршрутизаторное VPN-соединение па основе L2TP. создайте список фильтров и настроите следующие сто свойства (на примере соединения с Бостоном). • Имя: L2TPpre-shared key connection to Boston (образец). • Описание: L2TP-соединение с Бостоном, использующее отдельный общий ключ (образен).
378
ЧАСТЬ 2
Удаленный доступ
Теперь создайте единственный фильтр со следующей конфигурацией. На вкладке Addressing (Адресация): • в Source Address (Адрес источника пакетов) выберите A specific IP Address (Определенный IP-адрес) и введите IP-адрес Интернет-интерфейса локального маршрутизатора. В данном случае укажите IP-адрес Интернет-интерфейса маршрутизатора в Нью-Йорке; • в Destination Address (Адрес назначения пакетов) выберите A specific IP Address и введите IP-адрес Интернет-интерфейса маршрутизатора на другой стороне данного межмаршрутизаторного VPN-соединения. В данном случае укажите IP-адрес Интернет-интерфейса маршрутизатора в Бостоне; • установите флажок Mirrored (Отраженный). • На вкладке Protocol (Протокол): •
• в Select a protocol type (Выберите тип протокола) выберите UDP (IJDP); • в Set the IP protocol port (Установка порта для протокола IP) выберите переключатель From this port (Пакеты из этого порта) и тип 1701, а затем выберите переключатель То this port (Пакеты на этот порт). На вкладке Description (Описание): • в поле Description (Описание) введите соответствующий пояснительный текст. Например, для соединения с Бостоном введите L2TP-соединение с Бостоном. Этот текст появится в утилите для мониторинга IPSec (ipsecmon). Повторите эту процедуру для каждого межмаршрутизаторного VPN-соединения на основе L2TP поверх IPSec. В данном случае проделайте то же самое применительно к соединению с маршрутизатором в Лондоне. •
Настройка политики IP-безопасности на использование разных общих ключей для каждого соединения Чтобы сформировать политику IP-безопасности, использующую отдельный общий ключ для каждого межмаршрутизаторного VPN-соединения на основе L2TP, создайте политику IP-безопасности со следующими свойствами. • На вкладке General (Общие): • в поле Name (Имя) введите: Pre-shared key L2TP Connections (образец); в поле Description (Описание) введите, например: IPSec-аутентификация па основе общего ключа для межмаршрутизаторных VPN-соединений L2TP поверх IPSec', • при необходимости модифицируйте значения параметров Check i'or policy changes every (Проверять политику на наличие изменений каждые) и Advanced (Дополнительно). • На вкладке Rules (Правила): •
• удалите правило Default Response (Отклик по умолчанию). Для каждого межмаршрутизаторного VPN-соединения на основе L2TP добавьте правило со следующими свойствами (на примере соединения с Бостоном). • На вкладке IP Filter List (Список фильтров IP):
ГЛАВА. 9
Виртуальные частные сети
379
•
•
выберите список IP-фильтров, соответствующий Ь2ТР-соединетшю с филиалом в Бостоне. В нашем примере это список L2TP pre-shared key connection to Boston. На вкладке Filter Action (Действие фильтра):
• выберите действие фильтра, запрещающее- незащищенную Ь2ТР-связь, ]•> нашем примере это Secure L2TP. •
•
На вкладке Authentication Methods (Методы проверки подлинности); • в разделе Authentication Method preference order (Порядок предпочтений методов проверки подлинности) определите единственный метод на основе общего ключа. Укажите содержимое этого ключа, одинакового для двух маршрутизаторов, между которыми устанавливается данное VPN-соединение L2TP поверх IPSec. В нашем примере это VPN-соединение между маршрутизаторами в Нью-Йорке и Бостоне. Учтите, что ключ должен быть длиной не менее 20 символов и что он должен состоять из перемешанного набора букв верхнего и нижнего регистра, чисел и знаков препинания. На вкладке Tunnel Setting (Параметры туннеля); •
•
выберите This rule does not specify an IPSec tunnel (Это правило не указывает туннель IPSec),
На вкладке Connection Type (Тип подключения): • выберите АН network connections (Все сетевые подключения).
Действуя таким образом, добавьте отдельное правило для каждого межмаршругизаторного VPN-соединения на основе L2TP поверх IPSec. В нашем примере добавьте правило для соединения с маршрутизатором в Лондоне. Примечание В случае входящих соединений L2TP поверх IPSec служба маршрутизации и удаленного доступа обращается к IPSec, чтобы определить согласованный тип шифрования, используемого IPSec SA для IP-трафика, который направляемся в UDP-порт 1701. Если SA для этого трафика установлено, в ответ на запрос возвращается тип шифрования для SA. При нулевом значении параметра реестра ProhibitlpSec, SA всегда устанавливается для этого вида трафика, потому что служба маршрутизации и удаленного доступа автоматически создает фильтры Ь2ТР-трафика. Далее тип шифрования сравнивается с типами шифрования, разрешенными в профиле политики удаленного доступа, которая действует для данного L2TP-coединения. Если тип шифрования, полученный в результате запроса к IPSec, не относится к числу разрешенных в профиле политики, запрос на соединение отклоняется. Когда параметр ProhibitlpSec равен 1 и специфический фильтр для UDP-nopта 1701 отсутствует, сопоставление безопасности (SA) для IP-трафика, направляемого в UDP-порт 1701, не устанавливается и шифрование не применяется. Это может привести к отклонению запроса на соединение, если в профиле соответствующей политики удаленного доступа сброшен флажок No encryption (Без шифрования). Следовательно, возможен разрыв шифруемого соединения L2TP поверх IPSec в тех случаях, когда IPSec-фильтр, использующий общий ключ для все/'О IP-трафика, есть, а специфического фильтра для трафика, направляемою в UDPпорт 1701, нет.
380
ЧАСТЬ 2
Удаленный доступ
Создание политики IP-безопасности с помощью IPSecPol Политику IP-безопасности для соединений L2TP поверх IPSec, использующих общий ключ, можно сформировать и с помощью утилиты IPSecPol из набора инструментальных средств, предлагаемого на компакт-диске «Ресурсы Microsoft Windows 2000 Server». Подробнее на эту тему см. Windows 2000 Resource Kit Tools Help.
Виртуальные частные сети и брандмауэры Брандмауэр (firewall) применяет фильтры пакетов, разрешая или запрещая передачу определенных видов сетевого трафика. Механизм фильтрации IP-пакетов позволяет точно определять, какой IP-трафик может проходить через брандмауэр. Фильтрация IP-пакетов очень важна при подключении частных интрасетей к общедоступным сетям вроде Интернета.
Конфигурации VPN-сервера и брандмауэра Существует два подхода к использованию брандмауэра в сочетании с VPN-сервером: • VPN-сервер подключается к Интернету, а брандмауэр размещается между VPNсервером и интрасстью; • брандмауэр подключается к Интернету, а VPN-сервер размещается между брандмауэром и интрасетью.
VPN-сервер перед брандмауэром При размещении VPN-сервера перед брандмауэром, подключенным к Интернету (рис. 9-17). Вы должны создать фильтры пакетов на Интернет-интерфейсе VPNсервера, разрешающие передачу и прием только VPN-трафика. Туннелированные данные входящего трафика расшифровываются VPN-сервером и пересылаются брандмауэру, и тот применяет к ним свои фильтры, пропуская в интрасеть лишь разрешенный трафик. Поскольку через VPN-сервер проходит только трафик, создаваемый аутентифипированными VPN-клиентами, брандмауэр в данном варианте используется исключительно для того, чтобы VPN-клиенты не могли обращаться к определенным ресурсам в интрасети. Так как единственный Интернет-трафик, разрешенный в интрасети, сначала проходит через VPN-сервер, в этом варианте блокируется и возможность доступа посторонних пользователей к FTP- или Web-ресурсам интрасети.
Туннель
Брандмауэр
\
VPN-сервер V-.
vmicpnci ,
.ъ.
s
VPN-клиент
Рис. 9-17. VPN-сервер, подключенный к Интернету перед брандмауэром
ГЛДВА 9
Виртуальные частные сети
381
Если Вы выбрали именно этот вариант, то должны сконфигурировать для Интернет-интерфейса VPN-сервера следующие входные и выходные фильтры. С этой целью используйте оснастку Routing and Remote Access. Фильтрация пакетов для РРТР Настройте входные фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям). •
IP-адрес сети назначения для Интернет-интерфейса VPN-сервера, маска годссти - 255.255.255.255 и TCP-порт назначения - 1723 (ОхОбВВ). Этот фильтр разрешает передачу управляющего РРТР-туннелями трафика от РРТР-клиента РРТР-серверу. • IP-адрес сети назначения для Интернет-интерфейса VPN-сервера, маска подсети — 255.255.255.255 и идентификатор IP-протокола — 47 (Ox2F). Этот фильтр разрешает передачу данных, туннелированпых средствами РРТР, от РРТР-клиента РРТР-серверу. •
IP-адрес сети назначения для Интернет-интерфейса VPN-сервера, маска полсети — 255.255.255.255 и TCP-порт источника — 1723 (ОхОбВВ); Вы должны выбрать вариант TCP [established] (TCP (установлено]). Этот фильтр нужен, только если VPN-сервер выступает в роли VPN-клиента (вызывающего маршрутизатора) при VPN-соединении между маршрутизаторами. Когда Бы выбираете TCP [established], трафик принимается лишь в том случае, если VPN-сервер инициирует TCP-соединение,
Настройте выходные фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below. • IP-адрес исходной сети для Интернет-интерфейса VPN-сервера, маска подсети - 255.255.255.255 и TCP-порт источника - 1723 (ОхОбВВ). Этот фильтр разрешает передачу управляющего РРТР-туннелями трафика от РРТР-сервера РРТР-клиенту. • IP-адрес исходной сети для Интернет-интерфейса VPN-сервера, маска подсети — 255.255.255.255 и идентификатор IP-протокола — 47 (Ox2F). Этот фильтр разрешает передачу данных, тупнелироваппых средствами РРТР, от РРТР-сервера РРТР-клиенту. • IP-адрес исходной сети для Интернет-интерфейса VPN-сервера, маска подсети — 255.255.255.255 и TCP-порт назначения — 1723 (ОхОбВВ); Вы должны выбрать вариант TCP [established]. Этот фильтр нужен, только если VPN-сервер выступает в роли VPN-клиента (вызывающего маршрутизатора) при VPN-соединении между маршрутизаторами. Когда Вы выбираете TCP [established], трафик передается лишь в том случае, если VPN-сервер инициирует TCP-соединение. Фильтры пакетов для L2TP поверх iPSec Настройте входные фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям).
382
ЧАСТЬ 2
Удаленный доступ
•
IP-адрес сети назначения для Интернет-интерфейса VPN-сервера, маска подсети - 255.255.255.255 и UDP-порт назначения - 500 (Ox01F4). Этот фильтр разрешает передачу трафика IKE (Internet Key Exchange) на VPNсервер. • IP-адрес сети назначения для Интернет-интерфейса VPN-сервера, маска подсети - 255.255.255.255 и UDP-порт назначения - 1701 (Ох6А5). Этот фильтр разрешает передачу Е2ТР-трафика от VPN-клиента VPN-серверу. Настройте выходные фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below. •
IP-адрес исходной сети для Интернет-интерфейса VPN-сервера, маска подсети - 255.255.255.255 и UDP-порт источника - 500 (Ox01F4). Этот фильтр разрешает передачу трафика IKE от VPN-сервера.
•
IP-адрес исходной сети для Интернет-интерфейса VPN-сервера, маска подсети - 255.255.255.255 и UDP-порт источника - 1701 (Ох6А5).
Этот фильтр разрешает передачу L2 ТР-трафика от VPN-сервера VPN-клиенту. Для ESP-трафика применительно к IP-протоколу 50 никаких фильтров не требуется. После того как из пакета удаляется ESP-заголовок (модулем IPSec в TCP/ IP), применяются фильтры службы маршрутизации и удаленного доступа.
VPN-сервер за брандмауэром В более распространенной конфигурации (рис. 9-18) брандмауэр подключается непосредственно к Интернету, а VPN-сервер является одним из ресурсов интрасети в демилитаризованной зоне (demilitarized zone, DMZ). DMZ — это сегмент IP-сети, в котором обычно находятся ресурсы, доступные пользователям Интернета, например Web- и FTP-сервсры. Один из интерфейсов VPN-сервера подключается к DMZ, а другой — к интрасети. При таком подходе для Интернет-интерфейса брандмауэра нужно создать входные и выходные фильтры, которые пропускают к VPN-серверу трафик, управляющий туннелями, и туннелировапные данные. Дополнительные фильтры могут разрешать пропуск трафика к Web- и FTP-серверам, а также другим типам серверов и DMZ. Поскольку у брандмауэра нет шифровальных ключей для VPN-соединений, он может осуществлять фильтрацию только па основе незашифрованных заголовков туннелированных данных, а значит, все тунпелированные данные свободно проходят через брандмауэр. Однако это не создает проблем с безопасностью, так как VPNсоединения требуют аутентификации, которая блокирует попытки несанкционированного доступа. Для Интернет-интерфейса брандмауэра нужно создать следующие входные и выходные фильтры (при этом используется программное обеспечение брандмауэра). Фильтры пакетов для РРТР Настройте входные фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям). •
IP-адрес сети назначения для DMZ-интерфейса VPN-сервера и TCP-порт назначения - 1723 (ОхОбВВ).
ГЛАВА 9
Виртуальные частные сети
383
Этот фильтр разрешает передачу управляющего РРТР-туннелем трафика от РРТР-клиента РРТР-серверу. IP-адрес сети назначения для DMZ-интерфейса VPN-сервера и идентификатор IP-протокола — 47 (Ox2F). Этот фильтр разрешает передачу данных, туннелированных средствами РРТР. от РРТР-клиента РРТР-ссрверу. IP-адрес сети назначения для DMZ-интерфейса VPN-сервера и TCP-порт источника — 1723 (ОхОбВВ); Вы должны выбрать вариант TCP [established] (TCP [установлено]). Этот фильтр нужен, только если VPN-сервер выступает в роли VPN-клиента (вызывающего маршрутизатора) при VPN-соединении между мартпрутизьторами. Когда Вы выбираете TCP [established], трафик принимается лишь it том случае, если VPN-сервер инициирует TCP-соединение.
VPN-соединение Г Туннель
VP8-"
еервер
Webсвраер DMZ Брандмауэр
VPN-клиент
Рис. 9-18. VPN-сервер за брандмауэром, подключенным к Интернету Настройте выходные фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below. •
IP-адрес исходной сети для DMZ-интерфейса VPN-сервера и TCP-порт источника - 1723 (ОхОбВВ). Этот фильтр разрешает передачу управляющего РРТР-тунпелями трафика от РРТР-сервера РРТР-клиенту.
•
IP-адрес исходной сети для DMZ-интерфейса VPN-сервера и идентификатор IPпротокола — 47 (Ox2F). Этот фильтр разрешает передачу данных, туннелированных средствами РРТР, от РРТР-сервсра РРТР-клиенту. • IP-адрес исходной сети для DMZ-интерфейса VPN-сервера и TCP-порт назначения - 1723 (ОхОбВВ); Вы должны выбрать вариант TCP [established]. Этот фильтр нужен, только если VPN-сервер выступает в роли VPN-клиента (вызывающего маршрутизатора) при VPN-соединении между маршрутизаторами. Когда Вы выбираете TCP [established], трафик передается лишь в том случае, если VPN-сервер инициирует TCP-соединение.
384
ЧАСТЬ 2
Удаленный доступ
Фильтры пакетов для L2TP поверх IPSec Настройте входные фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below, •
IP-адрес сети назначения для DMZ-интерфейса VPN-сервера и UDP-порт назначения - 500 (Ox01F4). Этот фильтр разрешает передачу трафика IKE на VPN-сервер.
•
IP-адрес сети назначения для DMZ-интерфейса VPN-сервера и идентификатор IP-протокола — 50 (0x32). Этот фильтр разрешает передачу ESP-трафика от РРТР-клиента Р РТР -сервер у,
Настройте выходные фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below. •
IP-адрес исходной сети для DMZ-интерфейса VPN-сервера и UDP-порт источника - 500 (0x01 И). Этот фильтр разрешает передачу трафика IKE от VPN-сервера.
•
IP-адрес исходной сети для DMZ-интерфейса VPN-сервера и идентификатор IPпротокола — 50 (0x32). Этот фильтр разрешает передачу ESP-трафика от VPN-сервера VPN-клиенту.
Для Е2ТР-трафика, направляемого в UDP-порт 1701, никаких фильтров не требуется. На брандмауэре весь Ь2ТР-трафик, в том числе управляющий туннелями и туннелировапные данные, зашифровывается как полезная нагрузка IPSec-протокола ESP
Виртуальные частные сети и NAT Транслятор сетевых адресов (network address translator. NAT) — это IP-маршрутизатор, способный транслировать IP-адреса и номера TCP/UDP-портов в пересылаемых пакетах. Представьте, что малое предприятие подключает свои компьютеры к Интернету. По правилам оно должно было бы подучить общий адрес для каждого компьютера в собственной сети. Но при наличии NAT малому предприятию не требуется столько общих адресов. Оно может использовать в своем сегменте частные адреса (как документировано в RFC 1597) и с помощью NAT увязать частные адреса с одним или несколькими общими IP-адресами, выделенными ISP. Функциональность NAT документирована в RFC 1631. Например, если адрес частной сети малого предприятия — 10.0.0.0/8 и ISP выдал ему общий IP-адрес w.x.y.z, то NAT статически или динамически увязывает все частные IP-адреса в сети 10.0.0.0/8 с общим IP-адресом w.x.y.z, В исходящих пакетах IP-адрес источника транслируется в w.x.y.z, кроме того, номера TCP/UDP-портов могут быть изменены. Во входящих пакетах IP-адрес назначения и номера TCP/UDP-портов преобразуются в частный IP-адрес и исходный номер TCP/UDP-порта. По умолчанию NAT транслирует IP-адреса и TCP/UDP-порты. Если информация об IP-адресе и портах содержится только в IP- и TCP/UDP-заголовках, никаких проблем трансляция не вызывает. Пример - HTTP-трафик в Web. Однако некоторые приложения и протоколы храпят информацию об IP-адресах и TCP/lJDP-портах в собственных заголовках. FTP, например, записывает точечно-
ГЛАВЛ 9
Виртуальные частные сети
385
десятичное представление IP-адресов в РТР-заголовок для использования ком;шдой FTP port. Если NAT неправильно преобразует IP-адрес в FTP-заголовке. может возникнуть проблема с поддержкой соединений. Более того, некоторые протоколы для идентификации потоков данных используют не TCP- или V DP -за головки, а поля в других заголовках. Когда компоненту NAT приходится выполнять дополнительные преобразования и учитывать полезные данные не только в IP-, TCP- и UDP-заголовках, нужен NATредактор. Этот редактор так модифицирует иначе пе транслируемые данные, чтобы NAT мог пересылать их на правильные адреса.
Трансляция адресов и номеров портов для VPN-трафика Чтобы туннели РРТР и L2TP поверх IPSec могли работать через NAT, послсднш-i должен корректно обрабатывать множество потоков данных, поступающих на единственный IP-адрес или передаваемых с него.
РРТР-трафик РРТР-трафик связан с TCP-соединением, используемым для управления туннелем, и с инкапсуляцией тунлелированных данных в GRE-пакеты. Первая часть РРТРграфика корректно транслируется самим NAT, а вторая часть — только в комбинации со специфическим NAT-редактором. В туннелированных данных конкретный туннель определяется по IP-адресу источника и нолю идентификатора вызова в GRE-заголовке. Когда к одному РРТР-ссрверу обращается несколько РРТР-клиентов, расположенных в частной сети за NAT, весь туннелированный трафик имеет один и тот же IP-адрес источника. Кроме того, поскольку РРТР-клиенты ничего не знают о трансляции адресов, они могут выбрать одинаковые идентификаторы вызова при создании РРТР-туннеля. Во избежание этой проблемы NAT-редактор для РРТР должен отслеживать формирование РРТР-туннелеЙ и создавать раздельные сопоставления частных IP-адресов и идентификаторов вызова, используемых РРТР-клиента ми, с общим IP-адресом и уникальными идентификаторами вызова, принимаемыми РРТР-сервером в Интернете. Протокол маршрутизации NAT, поддерживаемый службой маршрутизации и удаленного доступа, предоставляет NAT-редактор для РРТР, который преобразует GRE-лоля идентификаторов вызова, и это позволяет различать РРТР-тунпели, создаваемые клиентами частной сети за NAT.
Трафик L2TP поверх IPSec Этот трафик не обрабатывается NAT, потому что номер UDP-лорта в нем зашифрован и его значение защищено криптографической контрольной суммой. Трафик L2TP поверх IPSec не транслируется даже с помощью NAT-релактора по причинам, изложенным ниже. Нельзя различить потоки данных IPSec-протокола ESP ESP-заголовок содержит поле индекса параметров безопасности (security parameters index, SPI). SPI используется — в сочетании с IP-адресом назначения в незашифрованных IP-заголовке и заголовке одного из IPSec-протоколов (ESP или АН) — для идентификации IPSec-соноставления безопасности (SA).
386
ЧАСТЬ 2 Удаленный доступ
В исходящем от NAT трафике IP-адрес назначения не изменяется, а во входящем в NAT трафике этот адрес должен быть преобразован в частный. Как и в случае нескольких РРТР-клиентов в частной сети за NAT, IP-адрес назначения в нескольких входящих потоках данных IPSec-протокола ESP тоже одинаков. Чтобы отличить один поток от другого, исходные IP-адрес назначения и SPI следовало бы транслировать в частные IP-адрес назначения и SPI. Однако из-за того, что в концевой части ESP Authentication содержится криптографическая контрольная сумма, удостоверяющая подлинность ESP-заголовка и полезных данных, изменять SPI нельзя - иначе эта контрольная сумма будет модифицирована. Нельзя модифицировать контрольные суммы TCP и UDP В пакетах «L2TP поверх IPSec» каждый UDP- и TCP-заголовок содержит контрольную сумму, включающую IP-адреса источника и назначения, взятые из незашифрованного IP-заголовка. Это означает, что Вы не можете изменить адреса в незашифрованном IP-заголовке, не изменив контрольные суммы в TCP- и UDPзаголовках. А обновлять эти контрольные суммы нельзя, потому что они входят в зашифрованную часть полезных данных ESP.
Сквозные VPN-соединения Как уже говорилось в разделе «VPN-соединения через Интернет или интрасети», сквозная VPN (pass-through VPN) позволяет клиенту удаленного доступа, подключенному к интрасети одной компании, обращаться через Интернет к ресурсам в интрасети другой компании. VPN-соединение удаленного доступа к одной интрасети проходит через другую интрасеть и Интернет. В типичном случае компании А и В являются бизнес-партнерами, и сотрудники компании А посещают сетевые ресурсы компании В. Когда сотрудник компании А, участвующий в совместном совещании, подключает свой портативный компьютер к интрасети компании В, его система получает информацию о конфигурации IPадресов в этой интрасети. Если этому сотруднику нужно подключиться к интрасети своей компании, это делается одним из двух способов. • По телефонной линии в комнате совещаний сотрудник компании А может либо напрямую подключиться к серверу удаленного доступа этой компании и установить соединение удаленного доступа с ее интрасетью, либо связаться с местным ISP и создать VPN-соединение с интрасетью компании А. • Как показано на рис. 9-19, технология VPN и соответствующая инфраструктура позволяют сотруднику компании А создать туннель через интрасетъ компании В в Интернет, а затем создать другой туннель — через интрасегь компании В и Интернет в интрасетъ компании А. При втором способе VPN-соединение с интрасетью компании А создается за счет активизации двух объектов подключения и использования существующего локального физического сетевого соединения. Заметьте, что второй туннель формируется внутри первого,
Конфигурирование VPN-сервера компании А Настроите VPN-сервер компании А на прием VPN-соединений удаленного досту па от клиентов через Интернет и создайте политики удаленного доступа, требую-
ГЛАВА 9
Виртуальные частные сети
387
щие наиболее защищенные типы аутентификации и шифрования. Подробнее см, справочную систему Windows 2000 Server. Г VPN-соединение
«r^jR,-™**.
Туннель 1
т"X ^^ lin&^als Компьютер сотрудника компании А „™™*™__
Инграсеть компании В
^
Туннель 2
VPN-сервер компании В Интернет VPN-сервер компании А
Интрасеть компании А Рис. 9-19. Сквозная VPN
Конфигурирование VPN-сервера компании В Настройте VPN-сервер компании В следующим образом. 1. Сконфигурируйте этот VPN-сервер на прием VPN-соединений удаленного дос тупа. Подробнее см. справочную систему Windows 2000 Server. 2. Создайте вручную пул общих IP-адресов. 3. Создайте группу Windows 2000 для пользовательских учетных записей сотрудников другой компании, устанавливающих сквозные VPN-соединения, — например, группу VPN_Pa.ssThrough. 4. Создайте пользовательские учетные записи для сотрудников компании А. Если сквозные VPN-соединения сотрудников из других компаний обслуживаются только этим VPN-сервером, удалите политику по умолчанию Allow access if dialin permission is enabled (Разрешить доступ, если разрешены входящие подключения) и создайте свою, назвав ее, например, VPN Pass-Through for Business Partners. В этой политике нужно установить разрешение на удаленный доступ как Grant remote access permission (Предоставить право удаленного доступа). Потом задайте условия и параметры профиля, как показано в таблицах 9-7 и 9-8. Подробнее о настройке этих параметров см, справочную систему Windows 2000 Server, Параметры политики удаленного доступа, перечисленные в таблицах 9-7 и 9-8, предполагают управление удаленным доступом на основе групп. С этой целью во всех пользовательских учетных записях нужно установить разрешение на удаленный доступ как Control access through Remote Access Policy (Управление на основе политики удаленного доступа).
388
ЧАСТЬ 2
Удаленный доступ
Таблица 9-7, Условия политики удаленного доступа для VPN-сервера компании В Условие
Настройки
NAS-Porl-Typc Callcd-Station-ID
Virtual (VPN) [Virtual (VPN)] IP-адрес интерфейса VPN-сервера, принимающего VPN-соединения Например, VPN_PassThrough
Windows-Groups
Таблица 9-8. Параметры профиля политики удаленного доступа для VPN-сервера компании В Вкладка в окне профиля
Настройки
Authentication Установите флажок Microsoft Encrypted Authentication (Проверка подлинности) (MS-CHAP) [Шифрованная проверка подлинности Microsoft (MS-CHAP)l Encryption (Шифрование) Выберите Basic (Основное), Strong (Стойкое) или No encryption (Без шифрования) Примечание Параметры профиля политики удаленного доступа не требуют шифрования. Туннель от компьютера сотрудника компании А до VPN-сервера компании В не нуждается в шифровании, поскольку шифрование применяется к туннелю от компьютера сотрудника компании А до VPN-сервера компании А. Шифрование первого туннеля излишне и может отрицательно повлиять на производительность.
Настройка фильтрации Чтобы VPN-сервер компании В, подключенный к Интернету, ограничивался только приемом и пересылкой сквозного VPN-трафика, сконфигурируйте с помощью оснастки Routing and Remote Access набор фильтров, описываемых ниже. ^ Чтобы настроить РРТР-фильтрацию: 1. Настройте для интерфейса интрасети входные IP-фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below (Игнорировать псе пакеты, кроме тех, что отвечают указанным ниже критериям). •
IP-адрес сети назначения для интерфейса интрасети VPN-сервера, маска подсети — 255.255.255.255 и TCP-порт назначения — 1723.
•
IP-адрес сети назначения для интерфейса интрасети VPN-сервера, маска подсети — 255.255.255.255 и идентификатор IP-протокола — 47.
2. Настройте для интерфейса интрасети выходные фильтры, в которых действие IP-фильтра определено как Drop all packets except those that meet the criteria below. •
IP-адрес исходной сети для интерфейса интрасети VPN-сервера, маска подсети — 255.255.255.255 и TCP-порт источника — 1723.
•
IP-адрес исходной сети для интерфейса интрасети VPN-сервера, маска подсети — 255.255.255.255 и идентификатор IP-протокола — 47.
ГЛАВА 9
Виртуальные частные сети
389
3. Настройте для Интернет-интерфейса входные IP-фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below. • IP-адрес сети назначения и маску подсети для пула общих IP-адресов, а также TCP-порт источника — 1723. •
IP-адрес сети назначения и маску подсети для пула общих IP-адресов, а также идентификатор IP-протокола — 47.
4. Настройте для Интернет-интерфейса выходные IP-фильтры, в которых дейстиие фильтра определено как Drop all packets except those that meet the criteria below. •
IP-адрес исходной сети и маску подсети для пула общих IP-адресов, а также TCP-порт назначения — 1723.
• IP-адрес исходной сети и маску подсети для пула общих IP-адресов, а также идентификатор IP-протокола — 47. ^ Чтобы настроить фильтрацию L2TP поверх IPSec: 1. Настройте для интерфейса интрассти входные IP-фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below (Игнорировать все пакеты, кроме тех, что отвечают указанным ниже критериям). •
IP-адрес сети назначения для интерфейса интрасети VPN-сервера, маска подсети — 255.255.255.255 и UDP-порт назначения — 1701. • IP-адрес сети назначения для интерфейса интрассти VPN-сервера, маска подсети — 255.255.255.255 и UDP-порт назначения — 500. 2. Настройте для интерфейса интрассти выходные фильтры, в которых действ ire IP-фильтра определено как Drop all packets except those that meet the criteria below. • IP-адрес исходной сети для интерфейса иптрассти VPN-сервера, маска подсети - 255.255.255.255 и UDP-порт источника - 1701. • IP-адрес исходной сети для интерфейса иптрассти VPN-сервера, маска подсети - 255.255.255.255 и UDP-порт источника — 500. 3. Настройте для Интернет-интерфейса входные IP-фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criteria below. • IP-адрес сети назначения и маску подсети для пула общих IP-адресов, а также идентификатор IP-протокола — 50. • IP-адрес сети назначения и маску подсети для пула общих IP-адресов, а также UDP-порт источника — 500. 4. Настройте для Интернет-интерфейса выходные IP-фильтры, в которых действие фильтра определено как Drop all packets except those that meet the criterisi below. • IP-адрес исходной сети и маску подсети для пула общих IP-адресов, а также идентификатор IP-протокола — 50. • IP-адрес исходной сети и маску подсети для пула общих IP-адресов, а также UDP-порт назначения — 500.
390
ЧАСТЬ 2
Удаленный доступ
Настройка компьютера VPN-клиента на использование сквозной VPN Здесь рассматривается конфигурация VPN-клиента Windows 2000 для создания сквозной VPN на основе РРТР и L2TP поверх IPSec. ^ Чтобы настроить РРТР-соединение: 1. Создайте объект VPN-соединения, подключающий сотрудника компании А к VPN-серверу компании В: • на вкладке General (Общие) введите хост-имя или IP-адрес интерфейса интрасети VPN-сервера компании В; • на вкладке Security (Безопасность) выберите шифрование только пароля; • на вкладке Networking (Сечь) выберите в качестве типа сервера Point-toPoint Tunneling Protocol (PPTP) [Туннельный протокол точка-точка (PPTP)J. 2. Создайте объект VPN-соедипения, подключающий сотрудника компании А к VPN-серверу компании А: • на вкладке General введите хост-имя или IP-адрес Интернет-интерфейса VPN-сервера компании А; • на вкладке Security выберите либо шифрование пароля и данных, либо переключатель Custom [Дополнительные (особые параметры)]. Выбрав Custom, Вы должны указать подходящие параметры шифрования и аутентификации; • на вкладке Networking выберите в качестве типа сервера Point-to-Point Tunneling Protocol (PPTP). > Чтобы настроить соединение L2TP поверх IPSec: 1. Создайте объект VPN-соединения, подключающий сотрудника компании А к VPN-серверу компании В: • на вкладке General (Общие) введите хост-имя или IP-адрес интерфейса интрассти VPN-сервера компании В; • на вкладке Security (Безопасность) выберите шифрование только пароля; • на вкладке Networking (Сеть) выберите в качестве типа сервера Layer-2 Tunneling Protocol (L2TP) [Туннельный протокол уровня 2 (L2TP)]. 2. Создайте объект VPN-соединения, подключающий сотрудника компании А к VPN-серверу компании А: • на вкладке General введите хост-имя или IP-адрес Интернет-интерфейса VPN-сервера компании А; • на вкладке Security выберите либо шифрование пароля и данных, либо переключатель Custom [Дополнительные (особые параметры)]. Выбрав Custom, Вы должны указать подходящие параметры шифрования и аутентификации; • на вкладке Networking выберите в качестве типа сервера Layer-2 Tunneling Protocol (L2TP).
ГЛАВА 9
Виртуальные частные сети
391
Создание сквозного VPN-соединения Как только будет установлено сквозное VPN-соединение (см. следующую процедуру), сотрудник компании А сможет обращаться к любому сетевому ресурсу сиоей компании. ^ Чтобы создать сквозное соединение: Данная процедура предназначена для сотрудника компании А, который создает сквозное VPN-соединение с VPN-сервером компании А, подключенным к Интернету. 1. Дважды щелкните объект соединения, создающий туннель с VPN-сервером компании В в ее интрасети. 2. Когда появится приглашение, введите учетные данные, которые соответствуют специальной пользовательской учетной записи, созданной в компании В. 3. Дважды щелкните объект соединения, создающий VPN с VPN-сервером компании А в Интернете. 4. Когда появится приглашение, введите учетные данные, которые соответствуют Вашей пользовательской учетной записи, имеющейся в компании А.
Выявление и устранение проблем Устанавливая причины проблем с виртуальными частными сетями, Вы должны проверить поддержку IP-соединений, процессы установления соединений по требованию и удаленного доступа, маршрутизацию и IPSec.
Наиболее распространенные проблемы с VPN Проблемы с VPN, как правило, делятся на несколько категорий: • запрос на соединение отклоняется, хотя должен быть принят; •
запрос на соединение принимается, хотя должен быть отклонен;
•
адреса за VPN-сервером недостижимы;
•
не удается создать туннель.
Ниже даются рекомендации но устранению ошибок в конфигурации или инфраструктуре, вызывающих эти проблемы с VPN. Запрос на соединение отклоняется, хотя должен быть принят •
•
Используя команду ping, проверьте, возможно ли соединение с VPN-сервером по его хост-имени или IP-адресу. Если Вы имеете дело с хост-именем, проверьте, правильно ли оно разрешается в IP-адрес. Если выполнение команды ping заканчивается неудачей, то, возможно, фильтрация пакетов препятствует передаче ICMP-сообщений на VPN-сервер или от него.
Убедитесь, что на VPN-сервере работает служба маршрутизации и удаленного доступа. • В случае VPN-соединений удаленного доступа убедитесь, что на VPN-сервере разрешен удаленный доступ. В случае VPN-соединений между маршрутиззторами проверьте, настроен ли VPN-сервер на маршрутизацию с соединением по требованию.
392
ЧАСТЬ 2
Удаленный доступ
В случае VPN-соединений удаленного доступа убедитесь, что РРТР- и L2TPпорты настроены на прием входящих соединений удаленного доступа. В случае VPN-соединений между маршрутизаторами проверьте, настроены ли РРТР- и Ь2ТР-порты на входящие и исходящие соединения по требованию. Убедитесь, что VPN-клиент и сервер, на котором действует политика удаленного доступа, используют хотя бы один общий метод аутентификации и/или шифрования. Убедитесь, что параметры запроса на соединение согласуются с параметрами политик удаленного доступа. Для успешного установления соединения параметры в запросе на соединение должны: • соответствовать всем условиям но крайней мере одной политики удаленного доступа; предоставлять право на удаленный доступ либо через Allow access (Разрешить доступ) в пользовательской учетной записи, либо через Control access through Remote Access Policy (Управление на основе политики удаленного доступа) в пользовательской учетной записи и Grant remote access permission (Предоставить право удаленного доступа) в политике удаленного доступа; • соответствовать всем параметрам профиля; •
• соответствовать всем параметрам входящих звонков в свойствах пользовательской учетной записи. Подробнее о политиках удаленного доступа см. справочную систему Windows 2000 Server и главу 7 «Сервер удаленного доступа» в этой книге. Убедитесь, что настройки в профиле политики удаленного доступа не конфликтуют со свойствами VPN-сервера. Профиль политики удаленного доступа и свойства VPN-сервера предусматривают настройки для: • многоканальных подключений; • протокола ВАР; • протоколов аутентификации. Если настройки в профиле соответствующей политики удаленного доступа конфликтуют со свойствами VPN-сервера, запрос на соединение будет отклонен. Например, если в профиле указан протокол аутентификации EAP-TLS, по этот протокол в свойствах VPN-сервера не включен, последний будет отклонять запросы на соединение. Если VPN-сервер является рядовым сервером в домене Windows 2000, который работает в смешанном или основном режиме и сконфигурирован на аутентификацию через Windows 2000, убедитесь, что: •
в службе каталогов Active Directory имеется группа безопасности RAS and IAS Servers (Серверы RAS и IAS). Если этой группы нет, создайте ее, указав тип Security (Безопасность) и область действия Domain local (Локальная доменная);
ГЛАВА 9
Виртуальные частные сети
393
•
у группы безопасности RAS and IAS Servers имеется разрешение на чтение объекта RAS and IAS Servers Access Check;
•
учетная запись компьютера VPN-сервера включена в группу безопасности RAS and IAS Servers. Для просмотра текущих регистрации используйте команду netsh ras show registeredserver, а для регистрации сервера в определенном домене — команду netsh ras add registeredserver;
•
Если Вы добавляете компьютер VPN-сервера в группу безопасности RAS and IAS Servers или удаляете из нее, изменения не вступают в силу немедленно (из-за особенностей кэширования информации службы каталогов A c t i v e Directory в Windows 2000). Чтобы изменения немедленно вступили в силу, перезагрузите этот компьютер.
В случае VPN-соедипепий удаленного доступа убедитесь, что LAN-iipoTOKO.:bi, используемые VPN-юшентами, настроены на удаленный доступ. Убедитесь, что на VPN-сервере есть свободные РРТР- или Ь2ТР-порты. П р и необходимости увеличьте количество этих портов. Проверьте, поддерживается ли VPN-сервером протокол туннелирования, используемый VPN-клиентом, По умолчанию VPN-клиенты удаленного доступа Windows 2000 настроены на автоматический выбор тина сервера, т. е. сначала они пытаются установить VPN-соединение на основе L2TP поверх I PScc, а затем, если первое не удается. VPN-соединение на основе РРТР. Если на VPN-клиенте тип сервера выбран как Point-to-Point Tunneling Protocol (РРТР) (Туннельный протокол точка-точка (РРТР)] или Layer-2 Tunneling Protocol (L2TP) [Туннельный протокол урони я 2 (L2TP)], проверьте, поддерживается ли VPN-сервером выбранный протокол туннелирования. По умолчанию компьютер под управлением Windows 2000 Server и службы маршрутизации и удаленного доступа является РРТР- и Ь2ТР-сервером с пятью Ь2ТР-портами и пятью РРТР-портами. Чтобы создать только РРТР-сервер. укажите, что число Е2ТР-портов равно 0. А чтобы создать только Ь2ТР-сервер, укажите, что число РРТР-портов равно 0. В случае VPN-соединений удаленного доступа на основе L2TP поверх IPSec убедитесь, что на VPN-клиенте и сервере установлены сертификаты компьютеров, также называемые машинными сертификатами. Подробнее об устранении проблем с IPSec-соединениями см. главу 8 «IP-безопасность» в книге «Сети TCP/IP* из серии «Ресурсы Microsoft Windows 2000 Server». Проверьте в удостоверениях (учетных данных) VPN-клиента правильность имени и пароля пользователя, а также имени домена и убедитесь, что они моут быть проверены VPN-сервером. Если VPN-сервер настроен на использование статического пула IP-адресов, проверьте, достаточно ли адресов в пуле. Если все адреса из статического пула уже выделены VPN-клиентам, VPN-c:.'pвер не сможет назначить очередной IP-адрес. Если VPN-клиент сконфигурирован на использование только TCP/IP, запрос на соединение будет отклонен. Если VPN-клиент требует выделить ему определенный номер IPX-узла, убедитесь, что VPN-сервер разрешает- это делать.
394
ЧАСТЬ 2
Удаленный доступ
• Если VPN-сервер удаленного доступа настроен на диапазон номеров IPX-сетей, убедитесь, что эти номера не используются где-нибудь в другой части межсетевой IPX-среды. •
Проверьте конфигурацию службы аутентификации.
VPN-сервер может быть настроен на аутентификацию удостоверений VPN-клиентов либо через Windows, либо через RADIUS. • Если VPN-сервер является рядовым сервером в домене Windows 2000 основного режима, убедитесь, что он присоединился к домену. • Если VPN-сервер под управлением Windows NT 4.0 с Service Pack 4 и выше является членом домена Windows 2000 смешанного режима или если VPN-сервер под управлением Windows 2000 включен в домен Windows NT 4.0, считывающий параметры пользовательских учетных записей из доверяемого домена Windows 2000, проверьте, включена ли группа Everyone (Все) в группу Pre-Windows 2000 Compatible Access. Для этого воспользуйтесь командой net localgroup «Pre-Windows 2000 Compatible Access». В случае отрицательного результата введите команду net localgroup «Pre-Windows 2000 Compatible Access» everyone /add на контроллере домена и перезагрузите его. • Если VPN-сервер под управлением Windows NT 4.0 с Service Pack 3 и ниже является членом домена Windows 2000 смешанного режима, убедитесь, что группе Everyone предоставлены права на перечисление содержимого (list contents), чтение всех свойств (read all properties) и чтение (read) до корневого узла Вашего домена и всех гюдобъектов (sub-objects) корневого домена. •
В случае аутентификации через RADIUS проверьте, взаимодействует ли компьютер VPN-сервера с сервером RADIUS.
• В случае РРТР-соединения с использованием MS-CHAP vl и МРРЕ с 40-битным ключом убедитесь, что длина пароля не превышает 14 символов, Запрос на соединение принимается, хотя должен быть отклонен • Убедитесь, что данные параметры соединения запрещены в политиках удаленного доступа. Чтобы запрос на соединение отклонялся, его параметры должны быть запрещены одним из двух способов: в свойствах учетной записи выберите переключатель либо Deny access (Запретить доступ), либо Control access through Remote Access Policy (Управление на основе политики удаленного доступа). Но в последнем случае разрешение на удаленный доступ в первой политике удаленного доступа, соответствующей параметрам запроса на соединение, укажите как Deny remote access permission (Отказать в праве удаленного доступа). Подробнее о политиках удаленного доступа см. справочную систему Windows 2000 Server и главу 7 «Сервер удаленного доступа* в этой книге. Адреса за VPN-сервером недостижимы • Убедитесь, что LAN-протоколы, используемые VPN-клиентами, либо поддерживают маршрутизацию, либо позволяют обращаться к сети, к которой подключен VPN-сервер. •
Проверьте настройки распределения IP-адресов VPN-сервером.
ГЛАВА 9
Виртуальные частные сети
395
Если VPN-сервер настроен на использование статического пула IP-адресов, проверьте, достижимы ли адреса из этого пула хостами и маршрутизаторами ннтрасети. Если нет, добавьте на маршрутизаторы интрасети IP-маршрут, соответствующий статическому пулу IP-адресов VPN-сервера (пул определяется по IPадресу и маске диапазона), или включите на VPN-сервере подходящий протокол маршрутизации. Если маршруты к подсетям VPN-клиентов удаленного доступа отсутствуют, эти клиенты не смогут получать трафик из интрасети. Маршруты к подсетям указываются либо статически, либо определяются протоколом маршрутизации (OSPF или ШР). Если VPN-сервер настроен на выделение IP-адресов через DHCP, a DIICPсервер недоступен, VPN-сервер выделяет адреса из диапазона 169.254.0.1169.254.255.254, зарезервированного для автоматического назначения частстых IP-адресов (APIPA). Функция APIPA применима к VPN-клиентам удаленного доступа только в том случае, если в сети, к которой подключен VPN-cepuep, тоже используются адреса, назначаемые APIPA. Если VPN-сервер использует APIPA при доступном DHCP-сервере, проверьте, правильно ли выбран адаптер для получения IP-адресов от DHCP-сервера По умолчанию VPN-сервер выбирает такой адаптер случайным образом. Если на компьютере имеется несколько сетевых адаптеров, служба маршрутизации и удаленного доступа может выбрать сетевой адаптер, через который DHCP-;:epвер недоступен, Вы можете сами выбрать подходящий сетевой адаптер на вкладке IP в окне свойств сервера удаленного доступа (через оснастку Routing and Remote Access). Если диапазон IP-адресов статического пула является подмножеством диапазона IP-адресов сети, к которой подключен VPN-сервер, убедитесь, что диапазоны IP-адресов из статического пула не назначаются другим ТСР/1Р-хостач ни статически, ни через DHCP. В случае VPN-соединений между маршрутизаторами убедитесь, что на обеих сторонах такого VPN-соедипения имеются маршруты, обеспечивающие двухсторонний обмен трафиком. В отличие от VPN-соединения удаленного доступа VPN-соединение между маршрутизаторами не приводит к автоматическому созданию маршрута по умолчанию. Вы должны сами создать соответствующие маршруты на обеих сторонах VPN-соединения между маршрутизаторами, чтобы можно было перенаправлять трафик, передаваемый другой стороне соединения или принимаемый от нес. Вы можете добавлять статические маршруты в таблицу маршрутизации либо вручную, либо через протоколы маршрутизации. В последнем случае для постоянных VPN-соединений можно использовать OSPF или RIP, а для VPN-coi^nнений по требованию — механизм автостатических обновлений. В случае VPN-соединения между маршрутизаторами, инициируемого любо'! из сторон (two-way initiated router-to-router VPN connection), убедитесь, что оно не воспринимается VPN-сервером как соединение удаленного доступа. Если имя пользователя из удостоверений вызывающего маршрутизатора появляется в папке Remote Access Clients (Клиенты удаленного доступа) оснастки Routing and Remote Access, значит, VPN-сервер считает вызывающий маршрутизатор клиентом удаленного доступа. Убедитесь, что имя пользователя в y:ioc-
396
ЧАСТЬ 2
Удаленный доступ
товерениях вызывающего маршрутизатора совпадает с именем интерфейса соединения по требованию на VPN-сервере. •
R случае межмартпрутизаторного VPN-соединения по требованию, инициируемого только одной из сторон (one-way initiated router-to-router VPN connection), убедитесь, что маршруты интрасети вызывающего маршрутизатора сконфигурированы как статические (в параметрах входящих звонков в свойствах пользовательской учетной записи, применяемой этим маршрутизатором).
•
Убедитесь, что фильтры TCP/IP-пакетов в профиле политики удаленного доступа на VPN-сервере не препятствуют передаче или приему необходимого TCP/ IP-трафика. Учтите, что эти фильтры могут быть сконфигурированы на сервере RADIUS, если используется служба проверки подлинности в Интернете (IAS).
•
В случае VPN-соединений по требованию проверьте, не установлены ли на интерфейсах соединений по требованию вызывающего и отвечающего маршрутизаторов фильтры пакетов, препятствующие передаче или приему нужного трафика.
Не удается создать туннель •
Убедитесь, что фильтрация пакетов на интерфейсе маршрутизатора между VPNклиентом и сервером не препятствует пересылке трафика протокола туннелирования. На VPN-сервере Windows 2000 фильтрация IP-пакетов настраивается в окне дополнительных параметров TCP/IP и в оснастке Routing and Remote Access. Проверьте оба этих места — возможно, какие-то фильтры блокируют трафик VPNсоединения. Подробнее о трафике на VPN-соединении и фильтрации пакетов см. раздел «Виртуальные частные сети и брандмауэры» ранее в этой главе. • Убедитесь, что на VPN-клиенте пе работает клиент Winsock Proxy. Если он активен, вызовы API-функций Winsock, используемые, в частности, для создания туннелей и передачи туннелированных данных, перехватываются и перенаправляются сконфигурированному прокси-серверу. Компьютер с прокси-сервером позволяет организации получать доступ к специфическим т и н а м Интернет-ресурсов (обычно Web и FTP) без прямого подключения к Интернету. При этом организация использует выделяемые InterNIC идентификаторы частных сетей (например, 10.0.0.0/8). Прокси-серверы обычно применяются для того, чтобы пользователи внутри организации могли обращаться к общедоступным Интернет-ресурсам так, будто они напрямую подсоединены к Интернету. В то же время VPN-соединения, как правило, предназначены для того, чтобы авторизованные пользователи из Интернета могли обращаться к ресурсам частной сети организации так, будто они напрямую подключены к этой сети. Единственный компьютер может выступать и в роли прокси-сервера (для пользователей частной сети), и в роли VPN-сервера (для авторизованных пользователей из Интернета). Подробнее об устранении проблем с VPN-соединениями удаленного доступа см. главу 7 «Сервер удаленного доступа» в этой книге; подробнее об устранении про-
ГЛАВА 9
Виртуальные частные сети
397
блем с VPN-соединениями между маршрутизаторами см. главу 6 «Маршрутизация с соединением но требованию* в этой книге.
Средства диагностики С Windows 2000 поставляются средства диагностики, позволяющие собирать дополнительную информацию об источниках проблем с VPN. Причина недостижимости Если установить соединение по требованию не удается, интерфейс соединения по требованию остается в недостижимом состоянии. Служба маршрутизации и удаленного доступа Windows 2000 регистрирует причину, по которой не удалось установить соединение, в параметре Unreachability reason (Причина недостижимости). Информация, указанная в этом параметре, поможет Вам локализовать источник проблем])!. Протоколирование событий Па вкладке Event logging (Журнал событий) окна свойств VPN-сервера предлагается четыре уровня протоколировании. Выберите переключатель Log the maximum amount of information (Вести журнал всех событий) и повторите попытку соединения. Как только попытка закончится неудачей, проверьте, какие события были зарегистрированы в системном журнале при попытке соединения. Просмотрев события, выберите на вкладке Event logging переключатель Log errors and warnings (Вести журнал ошибок и предупреждений). Трассировка Средства трассировки записывают последовательность вызываемых функций в файл. Разрешите применение трассировки для записи детальной информации о процессах, выполняемых при установлении соединений удаленного доступа и компонентами VPN, как описано в главе 7 «Сервер удаленного доступа» в этой книге. Закончив трассировку и просмотрев нужную информацию, верните параметрам трассировки исходные значения. Трассировочная информация может оказаться сложной и очень летальной. Часть ее полезна только инженерам службы технической поддержки Microsoft или сетевым администраторам, имеющим большой опыт работы со службой маршрут щции и удаленного доступа. Трассировочную информацию можно сохранить в виде файлов и послать в службу технической поддержки Microsoft для анализа. Network Monitor Network Monitor (Сетевой монитор) — это программа для захвата пакетов и их анализа, которая позволяет наблюдать за трафиком, передаваемым между VPN-сер teром и VPN-клиентом в процессе установления VPN-соединения и при передаче данных. Network Monitor не анализирует шифрованную часть VPN-трафика. Правильная интерпретация связанного с VPN и удаленным доступом трафика требует глубокого понимания РРР, РРТР IPSec и других протоколов, (С) протоколах РРР см. главу 7 «Сервер удаленного доступа» в этой книге.) Информацию, захваченную Network Monitor, можно сохранить в виде файлов и послать в службу технической поддержки Microsoft для анализа.
398
ЧАСТЬ 2
Удаленный доступ
Дополнительные материалы Более подробную информацию о RFC см. по ссылке: •
Internet Engineering Task Force на странице Web Resources (http://windows.microsoft.com/windows2000/reskit/webresources).
ЧАСТЬ
3
Взаимодействие с другими системами
Взаимодействие с операционными системами, отличными от Windows, попрежнему остается важной задачей для администраторов сетей. В главах части 3 рассматриваются возможности Windows 2000 и дополнительных программных продуктов в поддержке взаимодействия между Windows 2001) и операционными системами, отличными от Windows.
В этой части Взаимодействие с хост-системами IBM Services for Unix
459
Взаимодействие с NetWare Services for Macintosh
532
490
400
ГЛАВА
10
Взаимодействие с хост-системами IBM
Microsoft SKA Server — это программное решение Microsoft для интеграции клиентов и серверов на базе персональных компьютеров с мэйнфреймами и хост-системами IBM (хостами). SNA Server обеспечивает клиентам на базе операционных систем и от Microsoft, и не от Microsoft защищенный доступ к данным, приложениям и сетевым сервисам на хостах IBM. Вы можете интегрировать SNA Server в существующую среду, а также разработать решения для доступа к ресурсам хост-систем из пользовательского интерфейса операционной системы или Web-браузера. В этой главе Обзор Microsoft SNA Server
401
Способы интеграции сетей 405 Коммуникационное взаимодействие с иерархическими SNA-сетями Коммуникационное взаимодействие с одноранговыми SNA-сетями Гетерогенные клиенты 432 Host Print Service 435 Защита сетевых сред, включающих хост-системы Доступ к данным на хост-системах 444
425
437
Интеграция с приложениями хост-систем через COMTI Интеграция с системой обработки транзакций на хостах Интеграция хост-систем с Web 451 Интеграция управления сетями
420
448 450
455
См. также
•
Подробнее о хост-системах IBM и SNA-сетях — приложение А «Концепции взаимодействия с IBM SNA» в этой книге.
•
Подробнее о настройке и администрировании SNA Server — справочную систему SNA Server и Microsoft BackOffice Resource Kit.
ГЛАВА 10
Взаимодействие с хост-системами IBM
401
Обзор Microsoft SNA Server SNA Server — это исчерпывающее решение для интеграции гетерогенных сетей и интрасетей с мэйнфреймами IBM и хост-системами IBM AS/400 (рис. 10-1). SNA Server представляет собой приложение Microsoft BackOffice®, которое выполняется в операционной системе Windows 2000 Server и предоставляет расширенные сервисы для интеграции сетей, данных и приложений. SNA Server обеспечивает взаимодействие с хостами, использующими протоколы SNA или TCP/IP. Если Ваша хост-система IBM работает с протоколами SNA, то SNA Server действует как защищенный, высокопроизводительный шлюз между гетерогенными клиентами и хост-системами IBM. Поскольку SNA Server выполняется в Windows 2000, гетерогенные клиенты могут подключаться к SNA Server no стандартным сетевым протоколам типа TCP/IP, IPX/SPX, NetBEUI, Banyan V I V E S IP и ApplcTalk, а также через службу маршрутизации и удаленного доступа Windows 2000, Сам SNA Server подключается к мэйнфрейму или AS/400 по стандартным протоколам IBM SNA. Установив сетевое соединение на основе SNA или TCP/IP, пользователи могут получать с помощью SNA Server защищенный доступ к данным, приложениям и сетевым сервисам на мэйнфреймах и хост-системах ШМ, не выходя из привычного интерфейса своей операционной системы или Web-браузера.
AS/400 Мэйнфрейм
LAN/WAN-протоколы:
^-.
TCP/IP IPX/SPX Banyan VINES AppleTalk NetBEUI
Сервисы Для интеграции: Сетей Данных Приложений Управления сетями Хост-систем с Web
SNA Server U MIX OS/2
Macintosh "
MS-DOS
Windows 3.x Windows 95/98 Windows NT Workstation Windows 2000 Professional
Рис. 10-1. SNA Server интегрирует гетерогенные сети с хост-системами IBM 143ак 3343
402
ЧАСТЬ 3
Взаимодействие с другими системами
Основа мощной функциональности SNA Server — широкий набор сервисов интеграции с IBM-совместимыми хостами, SNA Server поддерживает все уровни модели взаимодействия, используемой Windows 2000. Взаимодействие с сетями. Кросс-платформенная поддержка сетей и протоколов, интеграция подсистем безопасности и единый вход в различные системы. (Поддержка единого входа дает возможность получать доступ ко множеству серверов, систем или приложений по одному паролю.) Доступ к данным. Сервисы передачи файлов, технологии Universal Data Access типа OLE DB и ODBC (Open Database Connectivity), а также репликация хост-данных. Доступ к приложениям. Поддержка доступа через терминалы, интегрированные сервисы транзакций, интеграция хост-систем с Web и коммуникационная связь. Интеграция управления сетями. Интеграция между службами управления сетями Windows 2000 и сервисами управления на базе IBM NetView.
Сервисы интеграции сетей Первый таг в реализации решений по кросс-платформенному взаимодействию — установление надежной и защищенной связи между сетевыми платформами. SNA Server интегрирует гетерогенные сети с хостами IBM (мэйнфреймами, мини-ЭВМ и хост-системами AS/400) е использованием соединений двух типов; сервер-хост (server-to-host) и клиент-сервер (client-to-server). Соединения «сервер-хост» — это физические (physical units, PU) и логические элементы (logical units, LU), связывающие SNA Server с хост-системой. Соединения «клиент-сервер» позволяют сетевым клиентам и приложениям подключаться к SNA Server по локальной (LAN) или региональной сети (WAN). Поскольку SNA Server работает в операционной системе Windows 2000 Server, он поддерживает широкий епектр клиентов и протоколов, а также масштабируется в соответствии с требованиями больших корпоративных сетей. Характеристики сервисов, предоставляемых SNA Server па уровне интеграции сетей, перечислены в таблице 10-1. Таблица 10-1. Характеристики сервисов интеграции сетей Характеристики Поддерживаемые хосты
Описание
Мэйнфреймы IBM, системы AS/400. Advanced System 36, System/36, System/38 и IBM-совместимые мэйнфреймы производства Amdahl, Fujitsu, Hitachi. Tandem и Unisys. Пропускная способность сервера До 3000 пользователей и до 30 000 одновременных сеансов на каждом сервере. «Горячее» резервирование До 15 компьютеров под управлением SNA Server, страи балансировка нагрузки хующнх друг друга на случай аварии. LU-пулы можно распределить между 15 серверами (максимум) для балаксировкп нагрузки. Способы подключения к хостам Стандартные способы подключения, в том числе канальные (ESCON и Bus & Tag), Twinax, Open Systems Adapter (Token Ring, Ethernet, FDDI), SDLC, X.25 и DFT. SNA Remote Access Service Интегрирует транспорт LU 6.2 с сервером удаленного доступа Windows 2000.
ГЛАВА 10 Таблица 10-1.
Взаимодействие с хост-системами
403
(продолжение)
Характеристики
Описание
Поддержка гетерогенных клиентов Windows 2000 Professional, Windows 95, Windows 98, Windows За-. MS-DOS, Macintosh, OS/2 и UNIX. Поддержка протоколов SNA, TCP/IP, IPX/SPX, именованные каналы, Banyan VINES IP и AppleTalk. Distributed Link Service Компьютеры SNA Server могут использовать хост-соединения совместно с другими компьютерами SNA Server. Это обеспечивает эффективное туннелированис SNA-данных между компьютерами SNA Server черен стандартные инфраструктуры WAN, например TCP/IP-сети. Поддерживается коммуникационная связь с устрой Соединения с нижестоящими устройствами ствами PU типа 2.0 при использовании только протоколов SNA. Нижестоящим устройствам (downstream devices) SNA представляется реальной хост-системпй. что упрощает конфигурацию PU на хосте. Программные продукты с полной поддержкой SNA моPU Pass-through Service гут взаимодействовать с хостом путем передачи данных PU 2.1 или PU 2.0 через SNA Server. Последний велет себя как кластерный контроллер IBM 3174. Администраторы могут настроить SNA Server на переИнтегрированная поддержка дачу хосту идентификаторов пользователей и паро/ей унифицированной регистрации на основе аутентификадионных удостоверений, исполь(единого входа) зуемых в домене Windows 2000, что устраняет необходимость управления несколькими схемами регистрации пользователей. Поддерживаются средства (от третьих фирм) двухстоСинхронизация паролей ронней синхронизации паролей для функций безопасности ACF2, RACF (Resource Access Control Facility) и Top Secret. Шифрует потоки данных между клиентами и компьютеШифрование данных рами SNA Server, исключая передачу данных открытым текстом (этого требуют многие приложения хостов) Создает защищенную сетевую среду в центре обработки данных. Позволяет администраторам открывать пользователям Защита на уровне LU доступ к LU-пулам или разрешать доступ только к определенным LU. Создает учетные записи в домене Windows 2000, регистBulk Migration Tool for Host рирует пользователей в Host Security Domain и синхроSecurity низирует критически важную информацию об учет? ых записях.
Доступ к данным Цель интеграции гетерогенных сетей — предоставить пользователям кросс-платформенный доступ к данным и приложениям. В таблице 10-2 перечислены дополнительные сервисы SNA Server, обеспечивающие доступ к средствам печати, данным и связанным с ними файлам на хостах.
404
ЧАСТЬ 3
Взаимодействие с другими системами
Таблица 10-2. Доступ к данным на хостах и интегрированные сервисы доступа к файлам и принтерам Сервисы доступа к базам данных и передачи файлов OLE DB Provider для AS/400 и VSAM Драйвер ООВСДЖОАдля DB2
Shared Folders Gateway
AFTP (APPC File Transfer Protocol) Service FTP-AFTP Gateway Service VSAM F i l e Transfer Service
Host Data Replicator Support Host Print Services
Описание Обеспечивает доступ к VSAM- и OS/400-файлам па мэйнфреймах па уровне записей. Позволяет разрабатывать многоуровневые приложения для доступа к нереляционным базам данных на хостах. Позволяет- приложениям, рассчитанным па использование SQL и интерфейса ODBC, динамически взаимодействовать с системами управления базами данных на хостах (например, с DB2) по протоколу DRDA. Применим и для приложений, использующих OLE DB. Дает возможность пользователям получать доступ к файлам в общих папках AS/400 (shared folders-based files) так, будто эти папки являются локальными дисками компьютера под управлением Windows 2000 Server, Обеспечивает доступ к сервису передачи файлов (SNA APPC - эквивалент FTP ш TCP/IP). Позволяет стандартным FTP-клиентам обращаться к файлам на хосте по AFTP. Дает возможность авторизованным пользователям копировать VSAM-файлы с мэйнфрейма на компьютер Windows 2000 Server. Действует как птлюл при репликации хост-данных в Microsoft SOL Server'". Позволяет печатать с мэйнфреймов и AS/400 па принтерах, подключенных через LAN.
Интеграция приложений Организации часто используют хост-системы IBM для онлайновой обработки транзакций ( o n l i n e transaction processing, OLTP), которая необходима бизнес-приложениям, работающим в режиме реального времени. Для получения доступа к этим приложениям хостов пользователи традиционно полагались на программы эмуляции терминалов. Но сейчас отделы информационных технологий все чаше развертывают программные решения, обеспечивающие более высокий уровень интеграции современных сервисов интрасетей с данными и приложениями на хостах
IBM. Характеристики сервисов SNA Server, предназначенных для интеграции клиентских компьютеров с приложениями и сервисами транзакций на хостах, перечислены в таблице 10-3. Таблица 10-3. Характеристики сервисов SNA Server, обеспечивающих интеграцию с приложениями и сервисами транзакций на хостах Характеристики
Описание
Поддержка эмуляции терминалов SNA Server предусматривает эмулятор 3270 для доступа 3270, TN3270, TN3270E и TN3287 к приложениям мэйнфреймов. SNA Server также поддерживает сторонние программы эмуляции соответствующих терминалов.
ГЛАВА 10 Таблица 10-3.
Взаимодействие с хост-системами IBM
405
(продолжение)
Характеристики
Описание
Поддержка эмуляции терминалов SNA Server предусматривает эмулятор 5250 для доступа 5250 и TN5250 к приложениям AS/400. SNA Server также поддерживает сторонние программы эмуляции соответствующих терминалов. COMTI (COM Transaction Обеспечивает интеграцию Component Services с транIntegrator) для CICS и IMS закциями CICS и IMS, поддерживая, в том числе, распределенную двухфазную фиксацию (distributed two-phase commit) между Component Services и CICS. CPI-C (Common Programming Позволяет взаимодействовать с приложениями Interface for Communications) на любой платформе, поддерживающей АРРС и СР1-С, в том числе иа мэйнфреймах. AS/400, Windows 2000 и UNIX. Технологии интеграции Обеспечивает интеграцию данных и приложений хостов хост-систем с Web с приложениями Windows 2000, например с Microsoli Internet Information Services (IIS), SQL Server и др,
Интеграция управления сетями Интеграция управления сетями дает возможность без проблем поддерживать коммуникационную связь между разными платформами и позволяет организациям разрабатывать более эффективные бизнес-процессы. Сервисы SNA Server, предназначенные для интеграции систем управления Windows 2000 Server и хостов IBM, перечислены в таблице 10-4. Таблица 10-4. Сервисы интеграции управления сетями Сервисы интеграции управления сетями SNA Server Manager
Поддержка интеграции со службами управления Windows 2000 Server Поддержка интеграции с системой управления сетями IBM NciView
Описание Предоставляет единую консоль для добавления, настройки, мониторинга и контроля всех компонентов SNA Server. Обеспечивает удаленное управление поддоменами, серверами, службами, подключениями, LU. сеансами, пользователями и группами. Обеспечивает полную интеграцию с ММС (Microsofl Management Console) и средствами Windows 2000 для мониторинга событий, безопасности и производительности. Обеспечивает автоматическое уведомление NetVtew n поддерживает Response Time Monitor (если он поддерживается эмулятором 3270). Кроме того, поддерживает службы NVAlert и NVRunCmd в Windows 2000 для удаленного управления SNA Server с консоли NetVitvv на хосте.
Способы интеграции сетей Используя средства SNA Server, перечисленные в таблицах 10-1, 10-2, 10-3 и 10-4, Вы можете соединять сети Windows 2000 с иерархическими SNA-сетями и сетями АРРК (Advanced Peer-to-Peer Networking). С этой целью Вы должны сначала выбрать конкретную модель развертывания (deployment model), соответствующим об-
406
ЧАСТЬ 3 Взаимодействие с другими системами
разом организовать компьютеры SNA Server внутри своих доменов Windows 2000 и выбрать способы подключения локальных сетей к хосту.
Модели развертывания Решая, как развернуть SNA Server на своем предприятии, примите во внимание следующее: • тип хост-систем, с которыми должны соединяться Ваши пользователи; •
местонахождение этих пользователей;
• существующую у Вас сетевую инфраструктуру; • уровень производительности и доступности хостов, требуемый в Вашей организации; • затраты на развертывание систем и управление ими. SNA Server поддерживает три модели развертывания. Модель развертывания по филиалам. Компьютеры SNA Server размещаются вдали от хост-системы — рядом с группами пользователей. Модель централизованного развертывания. SNA-шлюзы размещаются рядом с хост-системой. Модель распределенного развертывания. SNA-шлюзы размещаются рядом с хост-системой и рядом с пользователями. Эти три модели развертывания SNA Server можно комбинировать. Их преимущества и недостатки поясняются в следующих разделах.
Модель развертывания по филиалам Именно по этой модели предприятия традиционно развертывают SNA-шлюзы. При этом для взаимодействия с компьютером SNA Server, расположенным в локальной сети филиала, клиенты используют LAN-протоколы типа TCP/IP. В свою очередь компьютер SNA Server взаимодействует с хостом по SNA-протоколам, используя соединения 802.2 (с применением маршрутизатора), SDLC или Х.25, как показано на рис. 10-2. Компьютерами SNA Server можно управлять локально или удаленно через службу маршрутизации и удаленного доступа Windows 2000 или через IBM Net View. Преимущества •
Изоляция SNA-трафика. Модель развертывания по филиалам идеальна при ограниченной пропускной способности соединения SNA Server с хостом. Между клиентом и компьютером SNA Server сетевой трафик, как правило, интенсивнее. Если Ваша организация реализовала TCP/IP или один из маршрутизируемых WAN-протоколов, выделение для SNA-трафика, требующего подключения к хосту, специальных соединений — в данном случае для трафика между SNA Server и хостом — исключает распространение лишнего сетевого трафика по WAN-соединениям, не имеющим отношения к SNA. • Использование существующей инфраструктуры SNA. Эта модель также идеально подходит организациям, переходящим на единый маршрутизируемый WAN-протокол, так как позволяет использовать существующие каналы передачи SNA-данных.
ГЛАВА 10
Взаимодействие с хост-системами IBM
407
•
Более высокая гибкость в управлении. Поскольку компьютеры, работающие со SNA Server, размещены рядом с клиентами, администраторы SNA Server могут управлять пользователями в своих филиалах, быстрее реагируя на изменения в их требованиях. Но при необходимости компьютеры SNA Server w >жнс настраивать и контролировать удаленно по имеющимся у Вас WAN-каналам. • Возможность использования локальных многоцелевых серверов. Развернув SNA Server в филиалах, Вы можете использовать преимущества других приложений, рассчитанных на выполнение в Windows 2000 Server. Сервер, размещенный в филиале, может выполнять не только функции SNA Server, но и функции почтового сервера, сервера балы данных или Web-сервера. Недостатки •
Невозможность использования высокоскоростных каналов сняли с мэйнфреймом. В сети филиала нельзя реализовать поддержку высокоскоростных ьаналов связи с мэйнфреймом, например канальных подключений, Token Ring или Ethernet. Это вызвано либо физическими ограничениями, либо трудностью реализации SNA-протоколов для WAN-соединений. Как правило, SNA-шлюзы, размещенные в филиалах, используют соединения типа SDLC, которые поддерживают только один PU для каждого хост-адаптера и 254 LU на одно подключение.
•
Сложность маршрутизации. Если для передачи WAN-трафика между филиалом и хост-системами SNA Вы решили использовать маршрутизаторы, а не выделенные SNA-каналы, то конфигурация этих маршрутизаторов должна быть достаточно сложной, чтобы они могли назначать приоритеты передаваемым через WAN потокам данных различных протоколов (в дополнение к протоколам SNA). Главный мэйнфрейм Процессор FEP {Front-End Processor) (37xx]
Центр обработки данных
в Сакраменто Филиал в Сан-Диего SNA Server Филиал в Бостоне
Филиал в Портленде
Рис. 10-2. Модель развертывания SNA Server по филиалам с использованием соединений SDLC
408
ЧАСТЬ 3
Взаимодействие с другими системами
Модель централизованного развертывания В этой модели компьютеры SNA Server размещаются рядом с хостом, к которому они обеспечивают доступ через эмуляторы терминалов 3270 и 5250; при этом локальные и удаленные клиентские компьютеры подключаются к шлюзам по одному из маршрутизируемых протоколов, например TCP/IP. Другие клиентские и серверные приложения, либо приложения Telnet могут подключаться к хосту через эти шлюзы из любого участка WAN. Модель централизованного развертывания показана на рис. 10-3. Главный мэйнфрейм
AS/400 Компьютеры SNA Server
SNA-сеть
WAN-мосты или маршрутизаторы
в Сакраменто
Маршру- ,г<тизатор ; f3 Северо-западный LAN-домен " - .г*
t
-
LAN-домен филиала в Бостоне
LAN-домен филиала в Сан-Диего -
Рис. 10-3. Модель централизованного развертывания SNA Server с применением маршрутизаторов или мостов Преимущества •
Эффективная балансировка нагрузки и отказоустойчивость. В централизованной модели LU-пулы и пары АРРС-сеансов (АРРС session pairs) на множестве компьютеров SNA Server могут быть логически организованы в поддомен, который обеспечивает балансировку нагрузки и отказоустойчивость. За счет балансировки нагрузка равномерно распределяется между всеми серверами. Отказоустойчивость или «горячее» резервирование гарантирует, что в случае аварии одного из серверов его функции автоматически возьмут на себя остальные компьютеры SNA Server, входящие в поддомен. Подробнее о поддоменах см. раздел «Поддомены SNA Server* далее в :ггой главе. • Централизованное администрирование. Администрирование при использовании этой модели гораздо проще, чем при реализации модели на основе филиалов, поскольку все компьютеры SNA Server расположены рядом друг с другом, а не разбросаны по филиалам.
Взаимодействие с хост-системами IBM
ГЛАВА 10
409
• Использование высокоскоростных каналов связи с мэйнфреймом. Так как компьютеры SNA Server находятся рядом со SNA-хостом, их можно подключить к нему по высокоскоростным каналам связи. Самую высокую пропускную способность обеспечивает канальное подключение (типа ESCON). Во многих случаях компьютеры SNA Server, подключаемые по таким каналам, могут обходить FEP, еще- больше ускоряя транзакции. А в случае хостов AS/400 можно реализовать высокоскоростные соединения Token Ring или Ethernet. Недостатки •
Жесткие требования к инфраструктуре WAN. Модель централизованного развертывания предполагает наличие эффективной WAN-среды. Если у Ва:- нет подходящей инфраструктуры WAN, Вы должны сначала подсчитать стоимость необходимого для нее оборудования, расходы на его установку и возмохные потери из-за простоев, связанных с настройкой этого оборудования.
•
Невозможность использования локальных многоцелевых серверов. В данной модели компьютеры с Windows 2000 Server, на которых работает SNA Server, нельзя использовать в качестве многоцелевых серверов. Если в филиалах Д!>лжны работать и другие серверные приложения, Вам придется устанавливат . дополнительные компьютеры и аппаратные средства.
Модель распределенного развертывания Эта модель сочетает в себе лучшие качества первых двух моделей. Как показано на рис. 10-4, компьютеры SNA Server размещаются и в центральном участке (рядом со SNA-хостом), и в филиалах (рядом с клиентами). AS/400 Главный мэйнфрейм Компьютеры SNA Server
SNA-сеть в Сакраменто
WAN-мост или маршрутизатор SNA Server
LAN-домен в Сакраменто
Северо-восточный LAN-домен Северо-западный LAN-домен
Рис. 10-4. Модель распределенного развертывания SNA Server
410
ЧАСТЬ 3
Взаимодействие с другими системами
Компьютеры SNA Server, расположенные рядом с хостом, обычно связываются с ним высокоскоростным соединением, например по канальному подключению. Затем канальные сервисы делают доступными компьютерам SNA Server в филиалах, используя с этой целью Distributed Link Services — функцию, которая позволяет компьютеру SNA Server разделять сконфигурированные сервисы каналов с другими компьютерами SNA Server. В этом случае серверы в филиалах взаимодействуют со SNA-хостом через сервис виртуального канала (virtual link service) с использованием одного из маршрутизируемых WAN-протоколов, например TCP/IP. Преимущества •
Сочетание преимуществ централизованной модели и модели на основе филиалов. Распределенная модель сочетает в себе высокую пропускную способность коммуникационной связи централизованной модели со способностью модели на основе филиалов изолировать очень интенсивный трафик между клиентами и серверами в отдельном сегменте WAN. • Оптимальная поддержка отказоустойчивости и балансировки нагрузки. Распределенная модель обладает еще большей гибкостью в реализации балансировки нагрузки и отказоустойчивости, чем централизованная или на основе филиалов. Например, несколько компьютеров SNA Server в филиале можно настроить на взаимное «горячее» резервирование и балансировку нагрузки между собой. В свою очередь эти серверы можно подключить к SNA-хосту через Distributed Link Services, используемой совместно с централизованными компьютерами SNA Server. При аварии любого из серверов остальные серверы на данном участке могут взять на себя его функции. • Применение стандартных WAN-протоколов. Distributed Link Services также облегчает выбор протоколов маршрутизации и сетевых протоколов. В филиалах можно использовать любой LAN-протокол, поддерживаемый SNA Server, в том числе IPX/SPX. А между филиалом и центральным участком с компьютерами SNA Server можно реализовать более эффективный, маршрутизируемый протокол типа TCP/IP. SNA-трафик передается только но соединению между компьютерами SNA Server и хост-системой. Соответственно маршрутизация SNA-протоколов через WAN становится ненужной, что упрощает сетевое управление. Недостатки Один из потенциальных недостатков распределенной модели в том, что при ее применении может понадобиться — в зависимости от Ваших требований — установка большего числа серверов. Однако более высокие надежность и производительность, обеспечиваемые этой моделью, в сочетании с возможностью отказа от многопротокольных инфраструктур WAN скорее всего перевесят затраты на дополнительные серверы. В целом, модель распределенного развертывания является самым гибким и надежным решением на основе SNA Server. Она рекомендуется для средних и больших сетевых сред, требующих максимальной производительности и отказоустойчивости. Кроме того, распределенная модель легко масштабируется с ростом Ваших потребностей.
ГЛАВА 10
Взаимодействие с хост-системами IBM
411
Интеграция SNA Server с сетями Windows 2000 Выбрав подходящую модель развертывания, Вы должны логически сгруппировать компьютеры SNA Server для обеспечения максимальной отказоустойчивости, «горячего» резервирования и балансировки нагрузки.
Домены Windows 2000 Служба каталогов Active Directory в Windows 2000 Server хранит информацию обо всех объектах в локальной или глобальной сети и упрощает доступ к этой информации пользователям и администраторам. Для адаптации под требования разных предприятий содержимое Active Directory можно разделить на домены, а в более крупных сетях — па деревья доменов. Домен Windows 2000 — это группа компьютеров и ресурсов с общей базой данных учетных записей пользователей и единой политикой безопасности. Домен Windows .:ЮОО включает контроллеры домена, управляющие учетными записями пользователей и доступом к сетевым ресурсам. Остальные компьютеры в домене являются либо рабочими станциями, либо рядовыми серверами, предоставляющими свои ресурсы пользователям домена. Подробнее об Active Directory и доменах см. книгу «Распределенные системы» из серии «Ресурсы Microsoft Windows 2000 Server».
Поддомены SNA Server Каждый компьютер SNA Server является членом домена Windows 2000 и одновременно членом поддомена SNA Server. Поддомен SNA Server — это логическая группа компьютеров SNA Server, использующих общую конфигурационную информацию. Для клиентов с программным обеспечением SNA Server Client компыо' еры поддомена SNA Server кажутся единым набором SNA-ресурсов. Хотя SNA Server работает в операционной системе Windows 2000 Server, поддимены SNA Server не участвуют в аутентификации пользователей, выполняемой W i n dows 2000. Напротив, в аутентификации. SNA Server полагается на средства Windows 2000 Server. Примечание SNA Server можно настроить на аутентификацию через домен Windows 2000, чтобы реализовать унифицированную регистрацию для доступа к ресурсам хост-системы. Подробнее см. раздел «Защита сетевых сред, включающих .хостсистемы» далее в этой главе.
Организация поддоменов SNA Server В каждый поддомен SNA Server может входить до 15 компьютеров SNA Server, а в домен Windows 2000 — неограниченное количество поддоменов SNA Server. Поскольку в контроле за доступом к сети эти ноддомены полагаются на систему защиты домена Windows 2000, все компьютеры SNA Server конкретного полдомена должны относиться к одному домену Windows 2000, Планируя поддомен SNA Server и размещение его членов, Вы должны учесть пропускную способность сетевого канала, соединяющего членов поддомена. При каждом изменении конфигурации поддомена (например, из-за добавления нового пользователя или LU) модифицированный конфигурационный файл раснрос тра-
412
ЧАСТЬ 3
Взаимодействие с другими системами
няется на все компьютеры SNA Server в поддомене, выполняющие роль резервных. (Роли компьютеров в SKA Server поясняются в следующем разделе.) Чтобы свести к минимуму излишний трафик репликации, передаваемый по медленным WAN-соединениям, ноддомеп обычно содержится внутри сайта Active Directory. Сайт Active Directory — это одна или несколько TCP/IP-подсетей, соединенных высокоскоростными каналами. Windows 2000 позволяет администраторам контролировать и оптимизировать репликацию внутри сайта. В модели распределенного развертывания Вы могли бы сгруппировать все компьютеры SNA Server, входящие в сайт филиалов, в один поддомен, а компьютеры SNA Server на центральном сайте (рядом с хостом) — в другой поддомен.
Определение ролей в SNA Server Сформировав домены Windows 2000 и полдомены, Вы должны назначить каждый компьютер SKA Server в каждом поддомене на одну из трех ролей. Основной (primary). Предоставляет сервисы подключения к хост-системе пользователям и хранит мастер-копию конфигурационного файла. Внутри иоддомена основным может быть только один компьютер SKA Server. Резервный (backup). Хранит копию (только для чтения) конфигурационного файла, поддерживаемого основным сервером. Резервный сервер может быть выдвинут на роль основного, если тот выйдет из строя. В поддомене SNA Server может быть до 14 резервных серверов. Рядовой (member). He имеет копии конфигурационного файла. Рядовые серверы целиком полагаются па основной и резервные серверы. В ноддомене SKA Server может быть до 14 рядовых серверов. Примечание Концепция резервного сервера SNA Server отличается от концепции «горячего* резервирования. «Горячее» резервирование — это возможность совместной поддержки сеансов компьютерами SNA Server даже в том случае, если один из серверов или какое-то соединение не работает. Основным компьютером SNA Server должен быть первый сервер, установленный Вами в поддомене SNA Server. По возможности в поддомене должен присутствовать хотя бы один резервный сервер на случай выхода из строя основного сервера. Если главным требованием является безопасность, резервные серверы должны быть физически защищены, поскольку каждый из них хранит копию конфигурационного файла SNA Server. Выделив основной и несколько резервных серверов, Вы можете назначить остальные серверы на роль рядовых (не имеющих копии конфигурационного файла), Пока работает основной сервер, Вы можете администрировать SNA Server с рядового сервера — точно так же, как и с любого другого. SNA Server можно управлять и с компьютера Windows 2000 Professional, на котором установлен SKA Server Manager.
Способы подключения Выбрав подходящую модель развертывания и конфигурацию поддоменов, Вы должны решить: • как подключить компьютеры SKA Server к хост-системам IBM;
ГЛАВА 10
Взаимодействие с хост-системами IBM
413
•
какие сетевые протоколы будут использоваться для коммуникационной связи между клиентами и компьютерами SNA Server;
•
какие сетевые протоколы будут использоваться для коммуникационной связи между самими компьютерами SNA Server.
Подключение компьютеров SNA Server к хост-системам IBM Здесь поясняется, как подключать компьютеры SNA Server к мэйнфреймам ШМ и хост-системам AS/400. Что представляет собой соединение между SNA Server и хостом В терминологии SNA Server хост-соединение (host connection) — это коммуникационный путь передачи данных между SNA Server и хост-системой, В случае мэйнфрейма это соединение соответствует определению физического элемента (P1J) во VTAM (Virtual Telecommunications Access Method). PIJ — комбинация аппаратнопрограммных средств, которая обеспечивает сервисы, необходимые для использования определенного устройства н управления им. Применительно к AS/400 эпо же соединение соответствует определению контроллера АРРС (Advanced Program-toProgram Communications). Подробнее о способах подключения к хостам IBM и о SNA-сетях см. приложение А «Концепции взаимодействия с IBM SNA* в этой книге. Для каждого физического адаптера или подключения в SNA Server устанавливает ся и настраивается соответствующий сервис канала (link service). Сервис канала — это служба Windows 2000 или драйвер устройства, используемый для управления коммуникационными адаптерами «сервер-хост», которые поддерживаются SNA Server. После настройки сервис канала доступен не только на сконфигурированном SNA Server, но и на любом SNA Server в поддомсне (через Distributed Link Services). Сконфигурировав свои сервисы каналов, Вы создаете соединение через определенный сервис канала. Используя хост-соединение, клиентский компьютер в LAN может взаимодействовать с мэйнфреймовой системой. Для некоторых сервисов каналов возможно определение нескольких соединений на одном канале связи с хостом. В терминологии SNA комбинация соединения и используемого им сервиса канала эквивалентна PU. В SNA-сетях SNA Server предоставляет функциональность PU 2 или PU 2.1, аналогичную функциям контроллера кластера. О функциях контроллера кластера см. приложение А «Концепции взаимодействия с IBM SNA» в этой книге. Что представляют собой способы подключения SNA Server к хосту Для понимания различных вариантов подключения следует сначала изучить типы физических подключений и сетевые протоколы, поддерживаемые SNA Server. Наиболее распространенные способы подключения перечислены в таблице 10-5. Выбирая способ подключения, следует учитывать несколько факторов: • тип хост-систем, к которым Вы намерены подключиться; • реализуемую модель развертывания; • сетевую инфраструктуру хоста; • предполагаемый уровень использования ресурсов хоста; • уровень производительности и скорость отклика, ожидаемые Вашими пользователями; •
стоимость.
414
ЧАСТЬ 3
Взаимодействие с другими системами
Таблица 10-5. Способы подключения SNA Server к хосту Способ Token Ring 802.2 DLC (Data Link Control)
Пропускная способность 4, или 16 Мбит/с
Стандартный Ethernet 802.2 DLC
10 Мбит/с
Fast Ethernet 802.2 DLC
100 Мбит/с
FDDI (Fiber Distributed Data Interface) 802.2 DLC
100 Мбит/с
SDLC (Synchronous Data Link Control)
9600-19200 бит/с
X.25
9600-19200 бит/с
Характеристики • Для мэйнфреймов или AS/400 • Средняя производительность с использованием протокола DLC • Поддержка нескольких хост-соединений с использованием одного адаптера • Простой и недорогостоящий в реализации • Подходит для широкого спектра задач • Для мэйнфреймов или AS/400 • Средняя производительность с использованием протокола DLC • Поддержка нескольких хост-соединений с использованием одного адаптера • Простой и недорогостоящий в реализации • Подходит для малой и средней нагрузки по сетевому трафику • Конкуренция в Ethernet может ухудшить производительность в условиях высоких нагрузок • Для мэйнфреймов или AS/400 • Высокая производительность с использованием протокола DLC • Поддержка нескольких хост-соединений с использованием одного адаптера • Простой и не дорогостоящи и в реализации • Подходит для более производительных соединений • Конкуренция в Ethernet может ухудшить производительность в условиях высоких нагрузок • Для мэйнфреймов или AS/400 • Высокая производительность с использованием протокола DLC • Поддержка нескольких хост-соединений с использованием одного адаптера • Относительно дорогостоящий в реализации • Подходит для более производительных соединений • Для мэйнфреймов или AS/400 • Низкая производительность с использованием протокола SDLC • Поддержка 256 сеансов по одному хост-соединению • Простой и недорогостоящий в реализации • Подходит для WAN-соединений с малым трафиком • Для мэйнфреймов или AS/400 • Низкая производительность с использованием протокола QLLC (Qualified Logical Link Control) • Поддержка 256 сеансов по одному хост-соединению • Простой и недорогостоящий в реализации • Подходит для WAN-соединений с малым трафиком
ГЛАВА 10 Таблица 10-5.
(продолжение)
Способ
Пропускная способность
DFT
2.35 Мбит/с
Twin ax
1 Мбит/с
Канальный —
4,5 Мб/с
(Distributed Function Terminal)
Bus & Tag
Канальный — ESC ON
17 Мб/с
Взаимодействие с хост-системами IBM
415
Характеристики • Только для мэйнфреймов • Производительность: от малой до средней • Поддерживает только 5 сеансов но одному хост-сосди нению • Недорогостоящий • Подходит для тестовых сред или малых сетей с уже имеющейся инфраструктурой па основе DFT • Только для AS/400 • Низкая производительность • Поддерживает только 5 сеансов но одному хост-соединению л Недорогостоящий • Подходит для сред AS/400 с уже имеющейся инфраструктурой на основе Twinax • Только для мэйнфреймов • Высокая производительность • Поддерживает большое количество хост-соединений • Дорогостоящий • Подходит для высокопроизводительных соединений • Только для мэйнфреймов • Высочайшая производительности • Поддерживает большое количество хост-соединений • Дорогостоящий • Подходит для сред, требующих максимальной пропускной способности
Как правило, хороший выбор — высокоскоростное соединение Token Ring, если такое же соединение используется для подключения LAN к SNA-сети, включающей как мэйнфрейм, так и AS/400. Для большей производительности в среде, содержащей только мэйнфрейм, обычно рекомендуется соединение канального типа. Некоторые сервисы каналов дают возможность создавать несколько хост-соединений с помощью одного адаптера. Каждый экземпляр SNA Server поддерживает до 250 хостсоединений, а на одном компьютере может работать до 4 экземпляров SNA Server. Подключение SNA Server к мэйнфреймовой системе Модель иерархической SNA-сети обеспечивает доступ к централизованной обработке данных из различных точек сети. Чаще всего эта модель ассоциируется с мэйнфреймовыми средами, где к централизованно выполняемым приложениям обращаются с удаленных терминалов по сети. Устройства в иерархической SNA-сети, например терминалы и контроллеры кластеров, называются физическими элементами (PU). Каждому классу устройств присваивается свои номер. Так, сам мэйнфрейм считается устройством PU 5. Подробнее об иерархических SNA-сетях см. приложение А «Концепции взаимодействия с IBM SNA» в этой книге
418
ЧАСТЬ 3 Взаимодействие с другими системами
• Twinas; • Frame Relay.
ftS/400 LI) 6.2 SNA Server
Рис. 10-7. Соединения SNA Server в одноранговой сети
Выбор сетевых протоколов Определив способ подключения компьютеров SNA Server к хосту, Вы должны выбрать протокол или протоколы для двух дополнительных коммуникационных путей SNA Server: между клиентами и компьютерами SNA Server и между самими компьютерами SNA Server. С этой, целью можно применить один протокол или комбинацию нескольких протоколов — при условии, что все серверы будут использовать хотя бы один общий клиент-серверный протокол. С точки зрения управления сетью, проще всего развернуть единственный протокол в инфраструктуре WAN. Однако, если Вы предпочитаете постепенное внедрение SNA Server па своем предприятии, то для определенных соединений Вам придется использовать существующие протоколы. Например, для коммуникационного взаимодействия между серверами Вы можете пользоваться TCP/IP, а для коммуникационного взаимодействия между клиентами и серверами — IPX/SPX. Аналогичным образом возможно применение и других комбинаций поддерживаемых протоколов, если все компьютеры SNA Server работают хотя бы с одним общим протоколом и используют его для коммуникационного взаимодействия как между собой, так и с клиентами. Выбор клиент-серверных сетевых протоколов Компьютеры с программным обеспечением SNA Server Client могут взаимодействовать по нескольким LAN-протоколам: • TCP/IP;
• IPX/SPX;
ГЛАВА 10
Взаимодействие с хост-системами IBM
419
• Named Pipes; • Banyan VINES IP; •
AppleTalk.
TCP/IP быстро становится стандартным сетевым протоколом для клиент-серверных приложений. Благодаря высокой производительности и поддержке самых изощренных средств маршрутизации он подходит для многих WAN-сред. Обычно TCP/IP является лучшим выбором для сети — особенно если он уже в какой-то мере применяется в сегменте LAN, объединяющем клиенты и серверы SNA Server. Если Вы решили реализовать TCP/IP, рекомендуется назначить компьютерам SNA Server статические IP-адреса, поскольку управлять рабочими станциями, имеющими дело с фиксированным адресом SNA Server, гораздо легче. Клиентским компьютерам можно без проблем назначать динамические IP-адреса, используя с итой целью DHCP. SNA Server Client Благодаря SNA Server Client рабочие станции поддерживают расширенные функции SNA Server интеграции с хостами. SNA Server Client также предоставляет API, используемые сторонними разработчиками в своих приложениях для доступа к хост-системам и приложениям IBM. SNA Server Client обеспечивает независимость от конкретного сетевого транспорта, позволяя клиентам и приложениям взаимодействовать друг с другом через любые программные интерфейсы SNA Server. В настоящее время клиентское программное обеспечение доступно для следующих платформ: •
Windows NT;
•
Windows 95;
• т
Windows 3.x; MS-DOS;
• IBM OS/2: • Macintosh (от сторонних поставщиков); • UNIX (от сторонних поставщиков).
Примечание SNA Server Client не нужен клиентам, использующим TCP/IP для таких сервисов, как TN3270, TN5250 и AFTP. Приложения вроде эмуляторов ТШ270 взаимодействуют с этими сервисами напрямую, не обращаясь к клиент-серверному интерфейсу SNA Server. Выбор сетевых протоколов для коммуникационной связи между серверами Компьютеры SNA Server могут взаимодействовать друг с другом по любому из следующих протоколов: • •
TCP/IP; IPX/SPX;
• Named Pipes (именованные каналы); • Banyan VINES IP.
420
ЧАСТЬ 3
Взаимодействие с другими системами
Подробнее о настройке протоколов и оптимизации межсерверного сетевого трафика см. документацию на SNA Server версии '10.
Коммуникационное взаимодействие с иерархическими SNA-сетями В традиционных иерархических SNA-сетях удаленные терминалы обращаются к централизованным приложениям на мэйнфрейме через сеть. Эта модель использует протокол отображения информации (information display protocol) для мэйнфреймов IBM, известный как 3270. Этот протокол упрощает взаимодействие между мэйнфреймом и такими устройствами, как терминалы, принтеры и контроллеры. SNA Server предоставляет доступ к ресурсам мэйнфрейма за счет определения и назначения логических элементов (LU) 3270. Установив физическое подключение между SNA Server и мэйнфреймом, Вы должны определить, какие типы соединений 3270 понадобятся Вашим пользователям.
Доступ через терминалы 3270 SNA Server поддерживает соединения 3270 через зависимые логические элементы 3270 (зависимые потому, что требуют для своей работы мэйнфрейма). Каждый 3270 LU, определенный в SNA Server, конфигурируется на использование существующего подключения к мэйнфреймовой системе и соответствует парному LU-pecypсу, выделенному на хост-компьютере (обычно с помощью VTAM). Определение 3270 LU в SNA Server идентифицируется по номеру и имени, специфичному для конкретного пользователя. Этот номер совпадает с номером соответствующего LUресурса па мэйнфрейме. 3270 LU дополнительно классифицируется по типу сервиса, предоставляемого для данного соединения. Как и в случае PU, типы LU обозначаются номерами Например, потоки данных 3270 для отображения на дисплее известны как LU 2. На рис. 10-8 показано, что 3270 LU можно сконфигурировать как: • дисплей (LU 2); • принтер (LU 1 или 3): • приложение (LUA); • нижестоящий LU (downstream LU), SNA Server Client должен быть установлен на каждом клиенте, использующем LUсервисы SNA Server. Клиентское программное обеспечение управляет взаимодействием между приложением 3270 и сервером, выполняющим SNA Server. Приложения, рассчитанные на SNA Server Client API, устанавливают с помощью LU, определенных в SNA Server, коммуникационную связь от клиента к мэйнфрейму через SNA Server. Связь между определением LU в SNA Server и LU-ресурсом на хосте называется сеансом. Сеансы могут быть постоянными, автоматически создаваемыми при инициализации или устанавливаемыми по мере необходимости. Параллельные сеансы могут совместно использовать одни и те же физические устройства и коммуникационные каналы.
ГЛАВА 10
Взаимодействие с хост-системами IBM
421
SNA-сеть Мэйнфрейм SSCP (PU 5} Сеть Windows 2000
Нижестоящий LU Эмуляция принтера 3287 (LU 1 и 3) Эмуляция
тер ми нала 3270 Пользовательское ' приложение (LLJA)
Рис. 10-8. Соединения 3270 с использованием SNA Server
Использование LU-пулов Хотя Вы можете создавать отдельные LU и назначать их пользователям и грунтам, LU-пулы (при наличии большого количества LU) гораздо удобнее в управлении и применении. Пулы группируют LU, обеспечивая максимально эффективное их использование (рис. 10-9). Пользователь, приложение или клиентская система может обращаться к LU, когда свободен любой из включенных в пул LU. Если како!'-нибудь LU, входящий в пул, перестает функционировать, происходит переключение на другой свободный LU из пула. Соединения LU LU
/Ш : Г— 1* I LU
LU
SNA
V_v
LU
Рис. 10-9. Создание LU-пулов и выделение из них ресурсов LU-пулы также позволяют более эффективно распределять ограниченный объем ресурсов хоста среди групп непостоянных пользователей. Закрепление LU за пользователями, которые обращаются к хосту лишь эпизодически, привело бы к
422
ЧАСТЬ 3
Взаимодействие с другими системами
пустой трате его ресурсов. С помощью пула Вы можете закрепить за группой таких пользователей гораздо меньшее число LU,
Выделение LU рабочим станциям LU (и LU-пулы) можно назначать не пользователям, а рабочим станциям. Допустим, у Вас имеется 150 сотрудников, использующих 50 рабочих станций, к каждой из которых подключен принтер. Вместо выделения 150 принтерных LU в пул для всех пользователей Вы можете включить все рабочие станции в SNA Server и назначить им всего 50 таких LU.
Обеспечение отказоустойчивости LU-пулы также обеспечивают отказоустойчивость соединений. Если какой-то ресурс, например одно из хост-соединений, выходит из строя, «горячее» резервирование позволяет переключиться на аналогичный (заранее сконфигурированный) ресурс, как показано на рис. 10-10. «Горячее» резервирование реализуется в рамках одного сервера или нескольких серверов одного домена. Такая стратегия рекомендуется для предприятий любых размеров, так как она обеспечивает надежный доступ к хосту. Соединения
SNA Server
ты ашм*,,.^,,,,[ SNA Server Рис. 10-10. «Горячее» резервирование соединений и серверов
Балансировка нагрузки Балансировка нагрузки тесно связана с «горячим» резервированием и позволяет равномерно распределять сеансы между имеющимися хост-соединениями и серверами с использованием поддержки LU-пулов в 3270. Например, если у Вас есть два соединения, каждое из которых поддерживает по десять дисплейных LU, то функция балансировки нагрузки гарантирует равномерное использование LLJ, свободных на этих соединениях. Балансировка нагрузки реализуется созданием пула с LU от нескольких серверов или соединений.
Доступ через терминалы TN3270 TN3270 — это тип Telnet-сервиса, который обеспечивает доступ к мэйнфреймам по TCP/IP-сети. Пользователи могут подключаться к мэйнфреймам через клиент TN3270 и сервис TN3270, предоставляемый SKA Server (рис. 10-11).
ГЛАВА 10
Взаимодействие с хост-системами IBM
423
Сервис TN3270 поддерживает протоколы: •
TN3270 для сеансов дисплея;
•
TN3287 для сеансов принтера;
•
TN3270E для расширенных сеансов дисплея и принтера.
Сервис TN3270 предоставляет доступ к мэйнфреймам через функции SNA Server и используется в целях безопасности и создания избыточности в тех случаях, когда коммуникационные пути передачи данных между клиентом и сервером проходят через один или несколько незащищенных сегментов.
Мэйнфрейм
Рис. 10-11. Коммуникационное взаимодействие с помощью TN3270 через SNA Server Поскольку сервис TN3270 взаимодействует со SNA Server через LUA API, на сервере должны быть сконфигурированы соединения типа LUA, а также LU. После этого LUA и LU-пулы могут быть выделены сервису TN3270 и сделаны досту тными клиентам TN3270. Как и службы TCP/IP, сервис TN3270 требует наличия свободного TCP-порта, через который клиенты могут обращаться к сервису TN3270. По умолчанию сервис TN3270 использует TCP-порт 23 — тот же, что и стандартные сервисы Telnet. По-
424
ЧАСТЬ 3
Взаимодействие с другими системами
скольку сервисы не могут совместно использовать TCP-порт, рекомендуется перенастроить сервис TN3270 на TCP-порт 24 или какой-нибудь другой из числа свободных.
Соединения с нижестоящими системами В иерархических SNA-средах Вы конфигурируете коммуникационное взаимодействие 3270 между SNA-узлами, работающими с протоколами SNA. Обычно такими узлами являются компьютеры SNA Server и мэйнфреймы. Однако нижестоящая система (downstream system) — это SNA-узел, использующий SNA Server как шлюз PU (рис, 10-12). Нижестоящей системе компьютер SNA Server кажется мэйнфреймом, предоставляющим PU и 3270 LU. Клиенты SNA Server
Мэйнфрейм
Нижестоящие клиенты
Рис. 10-12, Соединения с нижестоящими системами при использовании SNA Server Нижестоящая система в среде этого типа должна быть устройством PL! 2. Нижестоящим устройством может быть, например, контроллер кластера IBM 3745. Таким же устройством может быть и клиент, работающий с эмулятором терминала, который эмулирует PU 2 и запрашивает LU-сеансы от компьютера SNA Server. Для поддержки нижестоящих систем у компьютера SNA Server должно быть два соединения: •
хост-соединение между сервером и мэйнфреймом (любое стандартное физическое подключение, поддерживаемое мэйнфреймом); • соединение между сервером и нижестоящей системой (физическое подключение, использующее 802.2/DLC, SDLC или Х.25). После соответствующей настройки SNA Server может управлять нижестоящими LU аналогично тому, как он управляет другими LU, Этот тип конфигурации удобен в средах, в которых нижестоящая система не способна напрямую взаимодействовать с мэйнфреймом из-за аппаратной или сетевой несовместимости. Применение промежуточного сервера SNA Server решает подобную проблему.
ГЛАВА 10
Взаимодействие с хост-системами IBM
425
Коммуникационное взаимодействие с одноранговыми SNA-сетями В одноранговых SNA-сетях все устройства считаются APPN-устройствами (Advanced Peer-to-Peer Networking). Каждое APPN-устройство (PU 2.1) может напрямую взаимодействовать с другими устройствами PU 2.1, использующими сеансы А Р Р С (Advanced Program-to-Program Communications). Устройство PU 2.1 полагается на свои вычислительные ресурсы и не требует постоянного доступа к центральной хост-системе, Примечание Хотя сети, использующие АРРС, обычно ассоциируются с хост-системами AS/400, мэйнфреймовые системы тоже поддерживают АРРС. В среде AS/400 АРРС применяется для самых разнообразных приложений, в том числе для доступа через 5250 и для передачи файлов. Программы, взаимодействующие через АРРС, называются транзакциопиыми (transaction programs, TP). АРРС ТР используют имена LU 6.2 для доступа к другим системам и транзакпиопиым программам. Подробнее о SNA APPN см. приложение А «Концепции взаимодействия с IBM SNA» в этой книге.
АРРС и SNA Server С помощью SNA Server транзакциопная программа (например, эмулятор терминала 5250) может использовать АРРС-псевдоним LU (АРРС LU alias) для взаимодействия с другой ТР. В атом случае псевдоним LU преобразуется в имя LU, которое на самом деле и применяется при взаимодействии с ТР на другой системе. ГР
Удаленный АРРС LU
Одноранговый узел PU 2.1 (SNA-хост)
Одноранговый узел SNA Server
Клиенты Рис. 10-13. Взаимодействие по механизму АРРС с применением SNA Server Когда ТР в клиент-серверной сети запрашивает сеанс связи с ТР на AS/400 (удалепной системе), SNA Server (локальная система) действует в интересах клиента и договаривается с AS/400 о создании сеанса «LU 6.2 - LU 6.2*. Данные, переда пае-
426
ЧАСТЬ 3
Взаимодействие с другими системами
мые или принимаемые от AS/400 ТР, обрабатываются сервером и пересылаются клиентской ТР но выбранному клиент-серверному протоколу. Взаимодействие но механизму АРРС с применением SNA Server показано на рис. 10-13. Примечание SNA Server считает, что локальный АРРС LU соответствует SNA Server, а удаленный — AS/400. Но с точки зрения AS/400, все наоборот: локальным АРРС LU является AS/400, удаленным — SNA Server.
CPI-C CPI-C (Common Programming Interface for Communications) — это API, использующий коммуникационную архитектуру LU 6.2. Многие организации реализуют CPI-C, потому что этот API доступен на нескольких платформах, поддерживающих АРРС, — в том числе на AS/400, мэйнфреймовых системах, Windows 2000 и некоторых операционных системах UNIX. CPI-C состоит из набора процедур, написанных на языке программирования С и позволяющих приложениям на разных компьютерах взаимодействовать друг с другом при выполнении какой-либо задачи, например при копировании файлов или доступе к удаленной базе данных. CPI-C предоставляет механизм, который дает возможность сопоставлять набор параметров с определенным символьным именем адресата. Программа на основе CPIС использует символьное имя адресата для инициализации сеанса взаимодействия через АРРС LU, которые сопоставлены с этим именем, SNA Server поддерживает CPI-C API и предусматривает средства для настройки параметров CPI-C. О программировании с помощью CPI-C API см. документацию на SNA Server версии 4.0.
АРРС-приложения АРРС поддерживает широкий спектр приложений, обеспечивая: •
доступ через терминалы 5250;
•
доступ через терминалы TN5250;
•
передачу файлов, в том числе доступ к общим папкам (Shared Folders).
Доступ через терминалы 5250 Сеансы дисплея AS/400 предоставляются через АРРС с применением эмуляции терминала 5250. Компьютеры SNA Server обеспечивают АРРС-доступ к AS/400, используя клиенты эмуляции 5250. Для поддержки сервисов 5250 локальный АРРС LU действует как идентификатор локальных клиентов SNA Server; удаленный АРРС LU идентифицирует систему AS/400. Локальный и удаленный LU, применяемые в такой конфигурации, показаны на рис. 10-14.
Доступ через терминалы TN5250 TN5250 — это сервис Telnet, обеспечивающий доступ к AS/400 по TCP/IP-сети с использованием соответствующего эмулятора клиентского терминала TN5250. Сервис TN5250, предоставляемый SNA Server, позволяет любому клиенту TN5250 соединяться с AS/400 средствами SNA Server, не устанавливая и не настраивая TCP/ IP на AS/400 (рис. 10-15).
ГЛАВА 10 SNA Sewer Эмулятор sSHftSeraefeaeitl 5250 —| Клиентская ТР Локальный шрт АРРС LU ~Щ Серверный LU 6.2 . _ . . .
г"-"-'---
:л
"^7~~'„''
Одноранговый —\ Серверный PU 2.1 узел
Взаимодействие с хост-системами IBM
AS/400
Обмен данными
TP на хосте
r^fJfjnWlfrrHmriTATlT.lilLti
Сеанс 5250
тчиыинхл-хшппаям*
^^Соединение
427
fb OS/400
Удаленный LU6.2HaxocTej4-APPC LU Ру 21 на хосте ]г|- Одноранговый .' .;= узе;
Физическая сеть Рис. 10-14. Компоненты, используемые при 5250-доступе через SNA Server
Приложение на хосте
AS/400
Удаленный APPCLU
Локальный АРРС LU Сервис TN5250
Клиенты
TN525Q TN5250
TN5250 Рис. 10-15. TN5250-AOCTyn через SNA Server
Передача файлов через АРРС Хотя обмениваться файлами между клиентом и хост-системой можно чгрез SINDF1LE или другие механизмы, ЛРРС предлагает более падежный и скоростной вариант передачи файлов по сравнению с решениями, построенными па основе эмуляции терминалов. SNA Server поддерживает три механизма передачи файлов па основе АРРС: •
AFTP (АРРС File Transfer Protocol);
•
FTP-AFTP Gateway;
• общие папки. Выбор метода передачи файлов зависит от типа хост-системы на Вашем предприятии (мэйнфрейм или AS/400) и от того, какой спектр возможностей в передаче файлов Вы хотите предоставить своим пользователям.
428
ЧАСТЬ 3
Взаимодействие с другими системами
AFTP AFTP — это клиент-серверное приложение, обеспечивающее передачу файлов с применением АРРС и LU 6.2 (FTP используется в ТСР/1Р-сетях аналогичным образом). AFTP поддерживает функции, похожие на те, которые поддерживает стандартный FTP, в том чиеле передачу, прием и переименование файлов, а также операции с каталогами на удаленных системах. Сервис AFTP устанавливается и настраивается на компьютере SNA Server (или на клиенте SNA Server), чтобы клиентское программное обеспечение AFTP, поставляемое со SNA Server, могло обращаться к специфическим каталогам на сервере. Подробнее о настройке и использовании AFTP см. документацию на SNA Server версии 4.0. Сервис FTP-AFTP Gateway Этот сервис дает возможность пользователям TCP/IP получать доступ к файлам па мэйнфрейме или AS/400 через обычный клиент FTP без установки TCP/IP на хосте (рис. 10-16). FTP-AFTP Gateway автоматически преобразует входящие запросы от клиента FTP в AFTP-команды и управляет коммуникационной связью и передачей данных между сервисами FTP и AFTP. Файлы
AS/400
[Локальней АРРС Ш |
Cepewc AFTP Шлюз FTP-AFTP
SNA Server
FTP-сервер TCP/IP
Клиент AFTP
KnnesrfTP
TCP/IP
TCP/IP
Рис. 10-16. АРРС-сервисы FTP и FTP-AFTP Gateway
ГЛАВА 10
Взаимодействие с хост-системами IBM
429
Чтобы запустить сервис FTP-AFTP Gateway, Вы должны сначала установить 1Слиентское программное обеспечение FTP или AFTP, а также сервис AFTP на компьютере SNA Server. Общие папки Рабочие станции, на которых не установлено программное обеспечение SNA Server Client, могут обмениваться файлами с хостом AS/400 с помощью сервиса Shiired Folders Gateway, предоставляемого SNA Server. Благодаря этому сервису пользователи сети обмениваются файлами с системой AS/-100 так, будто она представ.;яет собой дисковый том на компьютере SNA Server (рис. 10-17). АРРС LU
АРРС LU
Диск А в Windows 200U
-сз
......
Диск Х в Windows 2000
Файш 1,2 и з SNA-хост
Рис. 10-17. Сервис Shared Folders Gateway
Стратегии развертывания АРРС Реализуя АРРС-соединеиия со SNA Server, следует продумать, как Вы будете использовать следующие типы LIJ: • независимые LU; • зависимые LU; • LU-пулы.
Использование независимых АРРС LU Независимый LU (independent LU) может напрямую взаимодействовать с одноранговой системой и не нуждается в поддержке со стороны хост-компьютера. Независимые АРРС LU — в том виде, в каком они применяются в АРРК-сстях AS/400, — позволяют открывать множество параллельных сеансов между локальным и удаленным LU. Конфигурируя независимые АРРС LU, учтите следующее. Когда для взаимодействия с ТР на мэйнфрейме через независимый АРРС LU используется SNA Server,
430
ЧАСТЬ 3
Взаимодействие с другими системами
на хосте должен работать VTAM не ниже V3R2. Версия ACF/NCP (Advanced Communication Function/Network Control Function), необходимая на мэйнфрейме, зависит от типа применяемого FEP. Для систем 3725 требуется ACF/NCP не ниже V4R3, а для систем 3745 - ACF/NCP не ниже V5R2. О настройке независимых АРРС LU см. документацию на SNA Server версии 4,0.
Использование зависимых АРРС LU Зависимый локальный АРРС Ш требует поддержки мэйнфрейма для взаимодействия с удаленной ТР. Зависимые АРРС LU не годятся для коммуникационной связи с AS/400. В отличие от независимых АРРС LU зависимые поддерживают только один сеанс на каждый LU. Зависимые АРРС LU полезны при настройке SNA Server на взаимодействие с мэйнфреймом, использующим VTAM версии ниже V3R2, так как независимые LU не поддерживаются VTAM этих версий. Хотя SNA Server предоставляет поддержку для зависимых АРРС LU, по возможности используйте независимые LU. При настройке зависимых LU нужно обязательно указать имена сети и LU. Эти имена требуются программному обеспечению SNA Server. О настройке зависимых АРРС LU см. документацию на SNA Server версии 4.0.
Использование пулов АРРС LU Хотя Вы можете создавать отдельные LU и назначать их пользователям и группам, LU-пулы более эффективны при управлении большим числом LU. Эти пулы также позволяют экономнее распределять ограниченный объем ресурсов хоста среди групп непостоянных пользователей. Закрепление LU за пользователями, которые обращаются к хосту лишь эпизодически, привело бы к пустой трате его ресурсов. С помощью пула Вы можете закрепить за группой таких пользователей гораздо меньшее число LU. Подробнее о настройке LU см. документацию на SNA Server версии 4.0 и Microsoft BackOffice Resource Kit.
Обеспечение отказоустойчивости SNA Server в среде AS/400 использует комбинацию имен LU и их псевдонимов на одном или нескольких серверах для поддержки отказоустойчивых соединений с хостом AS/400 (рис. 10-18). Единственный компьютер SNA Server может использовать несколько соединений для обеспечения отказоустойчивости. С этой целью два и более АРРС-соединений с одной AS/400 конфигурируются как «горячий» резерв друг для друга. Если одно из соединений выходит из строя, клиенты перенастраиваются на другое соединение. SNA Server также позволяет создавать конфигурацию с несколькими серверами, страхующими друг друга. Если один из серверов выходит из строя, клиенты аварийного сервера переключаются на работающий. Подробнее о «горячем» резервировании АРРС-соединений см. документацию на SNA Server версии 4.0.
ГЛАВА 10
Взаимодействие с хост-системами IBM
431
"Горячее" резервирование соединений
"Горячее" резервирование серверов
AS/408
Рабочая станция
Рис. 10-18. «Горячее» резервирование соединений и серверов
Параметры IP для TN5250 Параметры IP, связываемые с определениями TN5250, позволяют клиентам TN.ri250 подключаться к AS/400. По умолчанию определение TN5250 не сопоставляется с IP-адресом или маской подсети, Это дает возможность соединяться с AS/400 любому клиенту TN5250. Вы можете ограничить доступ к сервису TN5250, указав для клиентской рабочей станции IP-адрес или маску подсети. Если эти параметры заданы, доступ к AS/400 через сервис TN5250 разрешается только тем клиентам, чьи IP-адреса или миска подсети совпадают с заданными в конфигурации TN5250. Вместо IP-адреса можно использовать имя рабочей станции, а для его разрешения в IP-адрес — любую службу разрешения имен, в том числе WINS.
SNA Remote Access Service SNA Remote Access Service (этот сервис также называется SNA-сервером удаленного доступа) интегрирует транспорт LU 6.2 сервера SNA Server со службой маршрутизации и удаленного доступа Windows 2000, позволяя администраторам создавать виртуальные LAN-соединения между системами Windows 2000 через существующую SNA-есть. Рис. 10-19 иллюстрирует, как с помощью SNA-сервера удаленного доступа SNA-сеть превращается в опорную сетевую магистраль. Функциональность SNA-сервера удаленного доступа аналогична функциональности, предоставляемой сервером удаленного доступа по ISDN или Х.25, с тем исключением, что функция обратного вызова не поддерживается. О настройке SNA-сервера удаленного доступа см. документацию на SNA Server isepсии 4.0.
432
ЧАСТЬ 3
Взаимодействие с другими системами Windows 2000 Server
Windows 2000 Server
SNA Server Исходящие соединения Удаленный tu Локальный LU
Клиент
Рис. 10-19. SNA Remote Access Service, также называемый SNA-сервером удаленного доступа
Гетерогенные клиенты SNA Server поддерживает типы LU (и эквивалентные приложения Telnet), а также API-интерфейсы, поддерживающие наиболее распространенные операционные системы, включая: •
Windows NT;
•
Windows 95;
•
Windows З.дг;
•
MS-DOS;
• IBM OS/2; • Macintosh; • операционные системы UNIX.
Интеграция гетерогенных клиентов с мэйнфреймами Сервисы SNA Server, обеспечивающие интеграцию клиентов с мэйнфреймами, перечислены и таблице 10-6 (применительно к каждой клиентской платформе). Таблица 10-6. Интеграция гетерогенных клиентов с мэйнфреймами Клиентская платформа
Типы LU/сервисы Telnet
API-интерфейсы SNA
MS-DOS
LUO. LU1, LU2. LU3 и LU6.2; TN3270, TN3287 и TN3270E LUO, LU1, Ш2, LU3 и LU6.2; TN3270, TN3287 и TN3270E LUO, LU1, LU2, LU3 и LU6.2; TN3270, TN3287 и TN3270E
APPC, CPI-C, Common Service Verb (CSV) и LUA Request User Interface (RUI) APPC, CPI-C, CSV, LUI RUI, LUA Session Level Interface (SLI) и ODBC/DRDA APPC, CPI-C, CSV. LUA RUI и LUA SLI
Windows 3..r. Windows for Workgroups OS/2
ГЛАВА 10 Таблица 10-6.
Взаимодействие с хост-системами IBM
433
(продолжение)
Клиентская платформа
Типы LU/сервисы Telnet
API-интерфейсы SNA
Macintosh
ТШ270, TN3287 и TN3270E LUO и LU6.2; TN3270, TN3287 и TN3270E
Используются Telnet-сервисы
UNIX 1 Windows 95 и Windows 98 Windows NT Workstation 4.0 и Windows 2000 Professional
LUO, I.U1, LL'2, LU3
и LU6.2; TN3270, TN3287 и TN3270E LUO, LU1.LU2. LU3 и LU6.2; TN3270, TN3287 и TN3270E
АРРС CPI-C, CSV и HJA RUI АРРС, CPI-C, CSV. LUA RUI. LUA SLI. ODBC/DRDA и AFTP АРРС. CPI-C, CSV, LUA RUI, LUA SLI, ODBC/DRDA и AFTP
1 При использовании UNIX-клиента для SNA Server, разработанного Parker Software в сотрудничестве с Microsoft, клиентская платформа UNIX позволяет работать не только с сервисами Telnet. Подробнее о UNIX-клиенте для SNA Server см. http://www.microsoft.com/sna.
Типы сеансов связи с мэйнфреймами SNA Server поддерживает стандартные сеансы терминала и принтера с LU тштов 0-3. LU 0 — это аппаратно-независимый LU, используемый главным образом в финансовых учреждениях для поддержки банковских терминалов и автоматических кассовых аппаратов. LU типов 1 и 3 предназначены для поддержки программ эмуляции принтеров на клиентских и серверных компьютерах, в том числе сервиса Host Print Service в SNA Server. LU типа 2 предоставляет поддержку для широкого спектра программ эмуляции терминала 3270. LU 6.2 поддерживает АРРС, СР1-С и CSV (Common Service Verb). Эти API позволяют транзакпионным программам на клиентах и серверах, а также другим процессам взаимодействовать с хост-системами, работающими под управлением ПШ CICS (Customer Information Control System) и IMS (Information Management System).
Дополнительные утилиты для взаимодействия с мэйнфреймами Как показано в таблице 10-6, SKA Server предлагает целый ряд утилит, дополняющих встроенную поддержку сеансов эмуляции стандартных терминалов и принтеров. Одна из таких утилит — AFTP. AFTP является частью набора приложений, поддерживаемого АРРС-приложениями IBM, которые выполняются в OS/390, MVS, VM или OS/400. Как серверное решение AFTP — в сочетании со шлюзом FTP-to-AFTP в SNA Server позволяет клиентам обмениваться файлами с хост-системами. SNA Server преобразует FTP-команды в AFTP-команды и использует АРРС на коммуникационном пути между компьютером SNA Server и хост-системой. Это позволяет клиенту работать с TCP/IP, а хосту — с «родными» протоколами SNA.
API для взаимодействия с мэйнфреймами SNA Server включает SDK (Software Development Kit) с документацией в электронном виде и образцами исходного кода. Этот SDK позволяет создавать законченные решения на основе AFTP, АРРС, CPI-C, CSV и LUA, а также программные продукты, дополняющие базовую функциональность SNA Server. LUA является !53ак. 3343
434
ЧАСТЬ 3
Взаимодействие с другими системами
адаптируемым API. который дает возможность программировать на низком уровне (на уровне стека протоколов SNA с применением Request User Interface), либо на более высоком уровне (с применением Session Level Interface). Все перечисленные API часто используются крупными финансовыми организациями, имеющими дело с унаследованными приложениями для банковского дела или страхования. Кроме того, существуют API, прямо не поддерживаемые SNA Server SDK, — HLLAPI (High Level Language API), EHLLAPI (Extended HLLAPI) и WinHLLAPI (Windows HLLAPI). API-интерфейсы SNA Server соответствуют концепции WOSA (Windows Open Service Architecture). Это означает, что во всех операционных системах Windows API-интерфейсы SNA Server устанавливаются в виде WOSA-версий: WinAPPC, WinCPI-C и WinCSV. Большинство основных поставщиков программного обеспечения для Windows SNA напрямую поддерживают WOSA API в своих продуктах; к таким поставщикам, в частности, относятся Andrew, Attachmate, Eicon, NetManage, NetSoft, Wall Data и WRQ. API-интерфейсы SNA Server отвечают стандартам, опубликованным и для других операционных систем. Например, в MS-DOS и OS/2 API-интерфейсы SNA Server совместимы с IBM Communications Manager/2 на уровне двоичного кода.
Интеграция гетерогенных клиентов с системами AS/400 Сервисы SNA Server, обеспечивающие интеграцию клиентов с системами AS/400, перечислены в таблице 10-7 (применительно к каждой клиентской платформе). Таблица 10-7. Интеграция гетерогенных клиентов с системами AS/400 Клиентская платформа
Типы LU/сервисы Telnet
API-интерфейсы SNA
MS-DOS
LU 6.2 (эмуляция терминалов и принтеров) и TN5250 LU 6.2 и TN5250
АРРС и СР1-С
Windows 3.x, Windows for Workgroups OS/2 Macintosh UNIX1 Windows 95 и Windows 98 Windows NT Workstation 4.0 и Windows 2000 Professional
LU 6.2 и TN5250 TN5250 TN5250 LU 6.2 и TN5250 LU 6.2 и TN5250
АРРС, CPI-C, CSV, EHNAPPC и ODBC/DRDA АРРС, CPI-C и CSV Используются Telnet-сервисы АРРС, CPI-C и CSV ЛРРС, CPI-C, CSV. EHNAPPC, ODBC/DRDA и AFTP АРРС, CPI-C, CSV, EHNAPPC. ODBC/DRDA и AFTP
1 При использовании UNIX-клиента для SNA Server, разработанного Parker Software в сотрудничестве с Microsoft, клиентская платформа UNIX позволяет работать не только с сервисами Telnet. Подробнее о UNIX-клиенте- для SNA Server см. http://\vww.microsoft.L'om/sna.
Типы сеансов связи с системами AS/400 SNA Server поддерживает все тины сеансов AS/400 в наиболее популярных персональных операционных системах через LU типа 6.2. Некоторые более старые эмуляторы используют LU типа 4 (для эмуляции принтера) и LU типа 7 (для эмуляции терминала). Однако SNA Server и большинство современных эмуляторов под-
ГЛАВА 10
Взаимодействие с хост-системами IBM
435
держивают эмуляцию стандартного терминала 5250 и принтера через LU типа 6.2 и АРРС. SNA Server поддерживает клиенты Macintosh и UNIX с помощью сервиса TN5250, который обеспечивает эмуляцию лишь базового терминала. Но в сочетании с Host Print Service, Shared Folders Service и FTP-to-AFTP Gateway SNA Server отвечает всем требованиям клиентов Macintosh и UNIX.
Дополнительные утилиты для взаимодействия с AS/400 Утилиты, выполняемые иа компьютере SNA Server, упрощают администратишшс управление соединениями клиентов с AS/400. Так, SNA Server предлагает дополнительный сервис общих папок (Shared Folders Service), позволяющий любому клиенту на основе Windows 2000 Server обращаться к файлам AS/400 без установки специального программного обеспечения или протоколов SNA. Другой пример Host Print Service, заменяющая средства эмуляции принтера на компьютере SNA Server.
API для взаимодействия с AS/400 Поддержка соединений AS/400 через SNA Server полностью совместима с EHNAI'PC и предоставляет полный спектр функций Client Access/400, включая общие панки, виртуальную печать, передачу файлов. EHNAPPC — стандартный Windows API, поддерживаемый продуктами IBM PC Support и Client Access/400 (CA/4I.IO). EHNAPPC дает возможность писать Windows-приложения, способные интегрироваться с AS/400. SNA Server Client для 32-разрядных операционных систем Windows также поддерживает 16-разрядные Windows-приложения на основе АРРС и CPI-C. Это позволяет запускать многие 16-разрядные Windows-приложения, работающие со SNA Server, в 32-разрядных Windows-средах. О настройке и управлении SNA Server Client см. документацию на SNA Server версии 4,0.
Host Print Service SNA Server поддерживает три метода печати информации с хоста на локальном или сетевом принтере. Распечатка экрана. Любой эмулятор 3270 или 5250 способен печатать содержимое экрана, используя функции печати экрана, предоставляемые клиентской операционной системой. Вывод может быть направлен на локальный или сетевой принтер. Перенаправленная печать на клиенте. Поток данных принтера SNA-хоста (например, 3287) доставляется соответствующей программе эмуляции, выполняемой на клиенте SNA Server. Клиентское программное обеспечение преобразует поток данных в информацию, которую можно вывести на локальный или сетевой принте;). Перенаправленная печать на сервере. Поток данных принтера SNA-хоста преобразуется каким-либо серверным процессом в данные, которые могут быть перенаправлены на локальный или сетевой принтер, определенный с помощью диспетчера принтеров Windows 2000 Server.
436
ЧАСТЬ 3 Взаимодействие с другими системами
Первые два метода реализуются на основе стороннего программного обеспечения, а третий метод поддерживается Host Print Service и сторонними программными продуктами. Host Print Service обеспечивает эмуляцию принтеров 3270 и 5250 на базе SNA Server, позволяя приложениям хоста печатать на LAN-принтере, который поддерживается Windows 2000 Server или Novell NetWare. Бы можете администрировать все функции Host Print Service через SNA Server Manager и контролировать различные параметры печати. Вывод на принтер можно перенаправлять в файлы. Каждое определение принтера на хосте также позволяет сопоставлять сеансы печати с фильтрами печати. Фильтры предоставляются сторонними приложениями.
Печать с мэйнфрейма Для мэйнфреймовых систем (рис. 10-20) Host Print Service поддерживает потоки печатаемых данных LU 1 и 3, в том числе задания на печать, отправленные препроцессорами хоста. Мэйнфрейм
PU
<ф
Принтерный LU |
SNA Server
Принтер Рис. 10-20. Печать с мэйнфрейма Для обработки заданий на печать 3270 выполните в SNA Server Manager следующие операции: • •
определите имя сеанса (оно позволит идентифицировать различные принтеры в сети); создайте LU принтера 3270;
• назначьте этот LU сеансу печати. Подробнее о настройке сеансов печати с мэйнфрейма ем. документацию на SNA Server версии 4.0.
ГЛАВА 10
Взаимодействие с хост-системами IBM
437
Печать с AS/400 Для систем AS/400 (рис. 10-21) Host Print Service поддерживает стандартную последовательную печать SCS и эмуляцию печати графики 3812 с использованием функции IBM Host Print Transform. AS/400
Приложение
SNA Server
Принтер АРРСШ
SNA Server APPCLU |
'"~""'""~~I.. • ~..' Сервис печати
Диспетчер печати
Принтер Рис. 10-21. Печать с AS/400 О настройке сеансов печати с AS/400 см. документацию на SNA Server.
Защита сетевых сред, включающих хост-системы Когда Вы интегрируете свою сеть с Интернетом и другими внешними сетями, резко возрастает угроза несанкционированного доступа к Вашим сетевым ресурсам. Поэтому при планировании сетевой среды Вы должны найти верный баланс мсжду степенью защиты ресурсов и удобством доступа к ним со стороны авторизованных пользователей. Планируя защиту сетевой среды со SNA Server, продумайте, какие методы Вы будете применять для: • аутентификации пользователей, которым нужен доступ к ресурсам хоста; •
управления доступом к ресурсам хоста;
• управления конфиденциальными данными, передаваемыми между рабочими станциями и приложениями хоста; • обеспечения безопасности при подключении своей сети к Интернету; •
упрощения доступа к ресурсам хоста со стороны аутентифицированных пользователей без ослабления защиты своей сетевой среды.
Все эти методы поясняются в следующих разделах; там же описывается, как реализовать средства защиты SNA Server и Windows 2000 для создания безопасной се: евой среды, включающей хост.
438
ЧАСТЬ 3 Взаимодействие с другими системами
Подробнее о защите Windows 2000 см. книгу «Распределенные системы» из серии «Ресурсы Microsoft Windows 2000 Server».
Аутентификация SNA Server, получив запрос, на доступ к ресурсу хоста, например к LU для сеанса термина/т, должен каким-то образом проверить этот запрос. В зависимости от типа запрошенного сервиса проверка пользователя осуществляется путем аутентификации в домене или на рабочей станции.
Аутентификация в домене Домен Active Directory в Windows 2000 - это группа компьютеров с общей базой данных пользовательских учетных записей и с общей политикой безопасности. Домен Active Directory включает контроллеры домена, которые хранят информацию, необходимую для зашиты, и реплицируют ее на другие контроллеры домена. В домене Windows 2000 компьютеры SNA Server логически группируются в поддомены (рис. 10-22). Каждый поддомеи SNA Server может содержать до 15 компьютеров SNA Server, а домен Windows 2000 - неограниченное количество таких поддоменов. Поддоман SNA
Server A
Педдймен
SNA Server В
Североамериканский домен 20QB
домен Wifttfews 2008
Рис. 10-22. Поддомены SNA Server в доменах Windows 2000 В аутентификации пользователей, запрашивающих доступ к ресурсам хоста, SNA Server полагается на службы домена Windows 2000 (рис. 10-23). Аутентификация в домене позволяет проверить подлинность пользователей, которые запрашивают доступ к ресурсам, предоставляемым следующими сервисами: • • •
3270 или 5250 с рабочих станций под управлением SNA Server Client; AS/400 Shared Folders Gateway Service; Host Print Service;
• APPC, CPI-C или LUA, использующими API-интерфейсы SNA Server. У каждого пользователя, которому Е1ужен доступ к ресурсам SNA Server, должна быть учетная запись в домене Windows 2000. Как только такой пользователь регистрируется доменом Windows 2000, его учетная запись добавляется в лоддомен SNA Server. После этого он может получить доступ к определенным SNA-ресурсам.
ГЛАВА 10
Взаимодействие с хост-системами IBM
439
Мэйнфрейм
SNA Server
SNA Server Client
Контроллер домена
Рис. 10-23. Процесс аутентификации в домене для доступа через терминалы 3270 Примечание У каждого компьютера SNA Server в домене Windows 2000 должна быть своя учетная запись, под которой выполняются сервисы SNA Server, Эта учетная запись нужна SNA Server для входа в домен с целью выполнения таких функций, как печать с хоста и шифрование данных с применением Distributed Link Services.
Выделение ресурсов В большинстве случаев нужно контролировать, кто именно обращается к ресурсам SNA Server. Способ защиты этих ресурсов зависит от конкретной среды, включающей хост, и от типа сервисов, предоставляемых пользователям.
Доступ через терминалы 3270 Пользователи или группы, которым требуется доступ к сеансам 3270 с рабочих станций под управлением SNA Server Client, должны быть членами гюддомена SNA Server. При этом они являются и членами домена Windows 2000, в который входит данный поддомен SNA Server. Вы можете закрепить определенные ресурсы 3270 (LU типа 2) за соответствующими учетными записями, и тогда пользователи будут получать доступ только к указанным Вами ресурсам. Рекомендуется аутентифицировать пользователей через домен и разрешать им доступ лишь к определенным ресурсам.
Доступ через терминалы 5250 и АРРС Включать сотрудников, использующих доступ через АРРС, в поддомен SNA Server не требуется, но они должны быть членами домена Windows 2000. При доступе через терминалы 5250 с применением SNA Server Client необходимая защита обеспечивается средствами AS/400.
Сервисы TN3270 и TN5250 Для защиты этих сервисов Вы указываете IP-адреса клиентских рабочих станций и сопоставляете с адресами разрешения на доступ к тем или иным ресурсам. В случае клиентов TN3270E вместо IP-адреса можно задать имя рабочей станции.
440
ЧАСТЬ 3
Взаимодействие с другими системами
Сервисы общих папок Доступ пользователей домена Windows 2000 к общим папкам AS/400 контролируется через Shared Folders Gateway Service. Разрешения устанавливаются средствами Windows 2000. В некоторых случаях Вам может понадобиться открытый доступ к определенным LU, предоставляемым SNA Server. Для этого предназначена пользовательская учетная запись Guest (Гость) или групповая учетная запись Everyone (Все). Чтобы обеспечить доступ с помощью учетной записи Guest, активизируйте эту запись в домене Windows 2000, как описано в справочной системе Windows 2000 Server. Добавьте учетную запись Guest в поддомен SNA Server и назначьте ей нужные UJ. А чтобы предоставить доступ через учетную запись Everyone, просто добавьте ее о поддомен SNA Server и назначьте ей нужные LU. Для неограниченного доступа к сервисам TN3270 или TN5250 можно создать LU, не указывая для иего IP-адреса или имени рабочей станции.
Шифрование данных SNA Server позволяет шифровать данные на пути их передачи между клиентом и сервером и между серверами (рис, 10-24). Хост-система
Distributed Link Services
SNA Server Client SNA Server
Рис. 10-24. Шифрование данных между клиентом и сервером и между серверами Шифрование между клиентом и сервером предотвращает передачу данных открытым текстом от компьютеров с программным обеспечением SNA Server Client компьютерам SNA Server и наоборот. Шифрование данных повышает безопасность клиент-серверной коммуникационной связи всех приложений, использующих средства SNA Server Client, в том числе эмуляторов 3270/5250. Шифрование включается с помощью SNA Server Manager для каждого пользователя индивидуально. Шифрование данных между серверами позволяет создавать безопасные коммуникационные пути через Вашу сеть, Интернет или любую WAN.
Поддержка брандмауэров Брандмауэр (firewall) — это устройство сетевой защиты, которое ограничивает доступ к сетевым ресурсам, пропуская только трафик, направляемый в порты с определенными номерами. Если адрес SNA Server известен, па клиентской рабочей станции настраиваются соответствующие порт и IP-адрес компьютера SNA Server (например, па рис. 10-25 это 1477 и 128.124.1.2 соответственно). В качестве альтернативы номера портов
ГЛАВА 10 Взаимодействие с хост-системами IBM
441
какого-либо сервиса на компьютере SNA Server можно менять на номера, запрашиваемые клиентом. Заголовок
IP-адрес 128,124.1.2
Проверка номера TCP-порта (в данном случае -1477)
-
TCP-порт 1477
Данные
Концевая часть
TCP-порт 1 4 7 7 IP-адрес 128.124.1.2 Хост-система
Брандмауэр Клиент
Рис. 10-25. SNA Server с брандмауэром Если же адрес SNA Server не известен, IP-транспорт SNA Server заменяет реальный IP-адрес назначения адресом брандмауэра. Тогда брандмауэр сам сопоставляет запрос на соединение с адресом компьютера SNA Server. Это происходит, когда транспорт открывает соединение с компьютером SNA Server для сеансов приложений или для спонсорского подключения (sponsor connection). SNA Server поддерживает брандмауэры главным образом в TCP/IP-сетях. Кроме того, возможна реализация брандмауэров в сетях IPX/SPX или Banyan VINES.
Host Security Integration В вычислительной среде масштаба предприятия сотрудники, выполняя свои ежедневные обязанности, часто обращаются к различным сетевым системам. Пользователь может начать свой рабочий лень с включения компьютера Windows 2000 Professional и входа в сеть Windows 2000, а позднее обратиться к базе данных на AS/400 через какую-нибудь программу эмуляции терминала. Каждая система, с которой имеет дело пользователь, устанавливает свои требования к безопасности и процедуры регистрации. Например, учетная запись в домене Windows 2000 может требовать имени пользователя из шести букв и пароле из восьми букв разного регистра, а в мэйнфреймовой системе — имени пользователя из семи букв и пароля из семи алфавитно-цифровых знаков. Нередко пользователям приходится запоминать несколько комбинаций имен и паролей для доступа к различным ресурсам в сети. Несмотря на все требования политики безопасности, многие из таких пользователей просто записывают свои пароли на листке бумаги и хранят его рядом с компьютером, ослабляя защиту сечи. Одна из наиболее важных особенностей SNA Server состоит в том, что он позволяет интегрировать системы защиты домена Windows 2000 и хоста. Host Security
442
ЧАСТЬ 3
Взаимодействие с другими системами
Integration — это комбинация средств и сервисов, автоматизирующих процесс синхронизации паролей и регистрации в различных системах. Применяя эти средства, Вы поможете своим пользователям соблюдать корпоративные стандарты безопасности и упростите управление учетными записями в сети и на хост-системе.
Компоненты Host Security Integration Host Security Integration обеспечивает управление пользовательскими учетными записями в сети и на хост-системе на основе концепции домена защиты хоста (host security domain). Домен защиты хоста определяет различные домены защиты с общей базой данных пользовательских учетных записей. Простейший домен защиты может состоять из домена хоста, домена Windows 2000 и поддомена SNA Server, как показано на рис. 10-26.
Host Account Synchronization Service
AS/400
SNA .Server
Windows 2000 Account Synchronization Service
Поддомен SNA Server
Домен Windows 2000
Host Account Cache
Рис. 10-26. Элементы в типичном домене защиты хоста Host Security Integration включает три компонента (которые можно устанавливать по отдельности): •
Host Account Cache;
•
Host Account Synchronization Service;
• Windows 2000 Account Synchronization Service,
Компонент Host Account Cache Host Account Cache поддерживает шифрованную базу данных, которая увязывает учетные записи на хосте с учетными записями в домене Windows 2000. Этот компонент представляет собой службу Windows 2000, устанавливаемую на одном из контроллеров домена Windows 2000. В сетях меньшего размера па контроллере до-
ГЛАВА 10
Взаимодействие с хост-системами IBM
443
мена Windows 2000 можно установить сам SNA Server, который и будет хранить информацию Host Account Cache. Для большей надежности на любом другом контроллере домена можно установить резервный Host Account Cache. Этот резервный кэш поддерживает локальную копию базы данных пользовательских учетных записей.
Компонент Host Account Synchronization Service Этот сервис можно установить на основном, резервном или рядотюм компьютере SNA Server в поддомене SNA Server. Подробнее о ролях в SNA Server см. раздел «Определение ролей в SNA Server» ранее в этой главе. Вы можете устанавливать данный сервис и на компьютерах без SNA Server. Host Account Synchronization Service поддерживает сторонние интерфейсы к различным базам данных учетных записей на хостах, позволяющие координировать изменения в паролях между системами защиты домена Windows 2000 и хоста. Host Account Synchronization Service не обязательна, если Вы используете функцию унифицированного входа с обновлением паролей вручную; в этом случае администраторы или пользователи сохраняют учетные данные с хоста в Host Account Cache через приложение Host Account Manager (UDConfig). О том, как пользоваться UDConfig, см. документацию на SNA Server версии 4.0 и Microsoft BackOffice Resource Kit,
Компонент Windows 2000 Account Synchronization Service Этот компонент автоматически синхронизирует пароли в учетных записях па хосте и в домене Windows 2000. Он должен быть установлен даже в том случае, если автоматическая синхронизация паролей не применяется, так как координирует внутреннее функционирование других сервисов. Account Synchronization Service устанавливается на контроллере домена Windows 2000. Основным может быть только один экземпляр этой службы; остальные должны быть резервными. В SNA Server встроена поддержка синхронизации паролей между доменом Windows 2000 и доменом защиты AS/400. Сервисы синхронизации с другими хост-системами предоставляют сторонние программные продукты.
Режимы синхронизации паролей При определении домена защиты хоста автоматически создается групповая учетная запись Windows 2000 с тем же именем. Затем в эту группу добавляются пользовательские учетные записи, которые таким образом становятся членами домена защиты хоста. Как только Вы определите домен защиты хоста, Вам станут доступны два режима синхронизации паролей: •
Replicated — в каждом домене защиты, определенном в домене защиты хол:та, используется одно и то же имя или пароль; • Mapped — в каждом домене защиты используются разные имена и пароли. Сопоставления между учетными записями и паролями хранятся в базе данных, контролируемой Host Account Cache Service. Вы можете установить любой из этих режимов для имен пользователей и/или паролей — например, выбрать сопоставление имен пользователей и репликацию па-
444
ЧАСТЬ 3
Взаимодействие с другими системами
ролей между доменами защиты. Это позволит входить в различные системы (в домене защиты хоста) по одному паролю, но под разными именами, Сразу после определения хост-соединения закрепляются за доменом, однако каждому из доменов защиты может быть присвоено только одно хост-соединение единовременно. Как только за доменом зашиты закреплены соединения, Вы можете включать в него пользователей, добавляя их учетные записи в ранее созданную группу Windows 2000. В каждой из таких учетных записей можно активизировать нужный режим синхронизации паролей и разрешить применение средств автоматической регистрации, Тогда пользователи, уже вошедшие в домен Windows 2000, смогут автоматически входить в хост-систему.
Автоматизация синхронизации паролей В рамках сети SNA Server автоматическая односторонняя (LAN-K-AS/400) синхронизация паролей поддерживается без всяких дополнительных средств или программных продуктов. В средах с мэйнфреймами или в том случае, если Вам нужна автоматическая двухсторонняя синхронизация паролей, требуется применение специальных программных продуктов от сторонних поставщиков.
Автоматизация регистрации SNA Server также позволяет автоматизировать процесс регистрации на хост^системе. Эта функция, обычно называемая поддержкой унифицированного входа, обеспечивает автоматическую регистрацию пользователя во всех системах безопасности домена защиты хоста, если этот пользователь уже проверен любой из систем внутри поддомепа. SNA Server изначально поддерживает унифицированный вход в хост-системы AS/400. При использовании сторонних программных продуктов эквивалентная функциональность становится доступной для приложений АРРС и CPI-C как на мэйнфреймах, так и на AS/400. Список поставщиков таких продуктов см. на Webузле SNA Server по адресу http://www.microsoft.com/sna. Подробнее о средствах защиты SNA Server и о поддержке интеграции систем безопасности см. документацию на SNA Server версии 4.0 и Microsoft BackOffice Resource Kit.
Доступ к данным на хост-системах Одна из основных целей интеграции сетей Windows 2000 с хост-системами IBM обеспечить пользователям доступ к данным на хостах. Многие крупные компании уже давно применяют хост-системы для хранения огромных баз данных и обработки больших объемов информации, необходимой пользователям в сети предприятия. Ввиду своей производительности и надежности хост-системы по-прежнему играют заметную роль в хранении и анализе колоссальных массивов данных. Приобретая все больше персональных компьютеров, объединяемых локальными сетями, многие организации ищут способы интеграции систем управления базами данных на хостах с персональными компьютерами. С помощью SNA Server Вы можете обращаться к источникам данных на хостах, используя одно из следующих средств:
ГЛАВА 10
Взаимодействие с хост-системами IBM
445
• Open Database Connectivity (ODBC) Driver for DB2 — для доступа к СУ6Д с архитектурой DRDA (Distributed Relational Database Architecture) через ODBCинтерфейсы; •
OLE DB Provider for AS/400 и VSAM — для доступа к данным на уровне записей через интерфейсы OLE DB.
Доступ к данным на хосте через ODBC SNA Server позволяет приложениям, рассчитанным на использование интерфейса ODBC и команд SQL. обращаться к базам данных на хостах. Применяя ODBC Driver for DB2, ODBC-приложения могут манипулировать базами данных на хостсистеме, которая управляет распределенными данными по протоколу DRDA (Distributed Relational Database Architecture), не требуя шлюза к базе данных. Соо" ветствующис драйверы предусмотрены для Windows NT, Windows 2000, Windows 95, Windows 98 и Windows 3.x. Рис. 10-27 иллюстрирует доступ к данным на хосте с помощью ODBC Driver for DB2. DB2 или
082/400
DRDA
Сисгемы управления базами данных IBM с поддержкой DRDA
База данных
SNA Server, управляющий взаимодействием между клиентами и хостом IBM
Драйвер ODBC/DRDA, транслирующий ODBC-команды в DRDA-команды ODBC Microsoft Word
|
ODBC ;
Microsoft Excel
. |
ODBC Microsoft Access
Персональные приложения с поддержкой ODBC
Рис. 10-27. Доступ к данным на хосте с помощью ODBC Driver for DB2
446
ЧАСТЬ 3
Взаимодействие с другими системами
ODBC-драйвер транслирует команды между SQL- и DRDA-системами, как показано на рис. 10-27. Каждый драйвер принимает SQL-запросы от клиентского приложения через ODBC, транслирует их в DRDA-команды и передает хосту. Последний обрабатывает DRDA-команды и возвращает результаты через SNA Server драйверу на клиентском компьютере. Затем драйвер преобразует DRDA-информацию в SQL-данные и передает их клиентскому приложению, используя ODBC-интерфейс. ODBC-драйвер поддерживает: • фиксацию и откат транзакций; • асинхронную обработку; • отмену запросов: • основные и внешние (foreign) ключи; •
четыре уровня изоляции транзакций.
Этот же драйвер позволяет напрямую передавать SQL-строки базе данных на хосте с трансляцией. К числу поддерживаемых баз данных относятся: • DB2 for MVS; • SQ/DS for VM and VSE; • DB2/400 for OS/400.
Подробнее о специфических функциях и типах данных ODBC, поддерживаемых ODBC-драйвером, см. документацию на SNA Server версии 4.0.
Доступ к данным на хосте через OLE DB SNA Server обеспечивает доступ на уровне записей к базам данных на мэйнфреймах и AS/400 через OLE DB Provider for AS/400 и функцию VSAM. Используя преимущества OLE DB как универсального интерфейса к разнородным источникам данных (рис. 10-28), OLE DB Provider for AS/400 и VSAM позволяют: •
адаптировать программные решения для чтения и записи файловых систем AS/400 и мэйнфреймов без предварительного переноса информации на клиентсерверную платформу; • интегрировать неструктурированные данные с клиентскими и серверными базами данных, работающими на персональных компьютерах; • разрабатывать приложения с использованием высокоуровневых интерфейсов типа Microsoft ADO (ActiveX® Data Objects), которые поддерживаются языками программирования Microsoft Visual Basic® (VB), Microsoft Visual C++® (VC++), Microsoft Visual J++"1 (VJ++). Microsoft Visual Basic® for Applications (VBA) и Microsoft Scripting. OLE DB Provider использует протокол ввода-вывода на уровне записей (recordlevel input/output, RL1O) в архитектуре IBM DDM (Distributed Data Management) уровня 2 или выше. Эта функция реализуется как DDM-средство запросов источника (source DDM requester) и взаимодействует с целевыми серверными DDM-peализациями в большинстве популярных операционных систем хостов, включая MVS/ESA, OS/390 и OS/400.
ГЛАВА 10
Взаимодействие с хост-системами IBM
447
Мэйнфрейм II или AS/400
Рис. 10-28. Доступ к данным на хосте через OLE DB Provider for AS/400 и VSAM Клиентские приложения взаимодействуют с базой данных на хосте но АРРС-соединению (LU 6.2), установленному между SNA Server Client и SNA Server, OLE DB Provider поддерживает: • блокировку файлов и записей; •
сохранение исходных атрибутов файлов и записей;
• индексированный и последовательный доступ к записям; •
логические записи фиксированной и переменной длины.
OLE DB Provider поддерживает самые разнообразные типы файловых данных, используемые мэйнфреймами и AS/400. Для мэйнфрсймовых систем OLE DB Provider поддерживает наборы данных SAM (включая BSAM и QSAM), VSAM (в том числе ESDS, KSDS, RRDS, VRRDS), альтернативный индекс для наборов данных ESDS и KSDS, а также элементы PDS/PDSE. Для AS/400 OLE DB Provide] поддерживает физические и логические файлы (как с ключами, так и без ключей). Полное описание OLE DB Provider for VSAM and AS/400 см. в SNA Server Software Development Kit, поставляемом со SNA Server.
Выбор метода доступа к хост-данным Выбор этого метода зависит от того, как именно Вы хотите предоставлять доступ к системам управления базами данных (СУБД). Предприятия, предпочитающие ODBC-приложения и SQL-команды для доступа к таблицам баз данных на хосте и манипуляций с ними, могут использовать драйвер ODBC/DRDA. Поднофункциопальная поддержка ODBC во многих персональных приложениях вроде Microsoft Excel и Microsoft Access упрощает создание соответствующих решений. Во многих средах OLE DB Provider for AS/400 и VSAM можно настроить H.I поддержку той же функциональности, что и драйвер ODBC/DRDA. Однако на предприятиях, где слишком мало специалистов по SQL (или их вообще нет), лучше
448
450
ЧДРТ1.
ЧАСТЬ 3
Взаимодействие с другими системами
Клиентские компоненты могут вызывать любой Automation-объект, зарегистрированный на компьютере с Windows 2000 Server, в том числе объект COMTI Automation. Полное описание COMTI и примеры соответствующих приложений см. в документации на SNA Server версии 4.0 и в его справочной системе COM Transaction Integrator Help.
Интеграция с системой обработки транзакций на хостах Во многих организациях хост-системы используются для выполнения приложений, обрабатывающих транзакции в режиме реального времени, например приложений IBM CICS. Эти приложения доступны в интерактивных сеансах вроде 3270 или 5250, поддерживаемых каким-либо эмулятором терминала, Мы уже поясняли, как с помощью функциональности COMTI, поддерживаемой SNA Server, обращаться к простым приложениям мэйнфреймов на программном уровне. Эта функциональность становится еще более мощным инструментом, когда она применяется для расширения приложений, использующих Component Services в Windows 2000 Server. Такие Windows-приложения могут координировать транзакции с CICS-приложениями.
LU6.2 (Sync Level 2)
Рис. 10-30. Интеграция с системой обработки транзакций на хосте
ГЛАВА 10
Взаимодействие с хост-системами IBM
451
COMTI в сочетании с Component Services применим для решения самых разнообразных задач. •
Разработчики для Windows могут описывать, запускать и управлять специальными объектами Component Services, которые обращаются к транзакцией ным программам CICS или IMS.
• Разработчики для мэйнфреймов могут делать ТР доступными для Windows- триложений, работающих в Интернете и интрасетях. •
Проектировщики компонентов Component Services могут включать приложения мэйнфреймов в область действия двухфазных транзакций Component Servires с фиксацией.
Рис. 10-30 иллюстрирует, каким образом клиентское Windows-приложение способно неявно использовать DTC (Distributed Transaction Coordinator) для координации распределенной транзакции, в которой участвуют SQL Server и одна из транзакционных программ CICS. DTC является частью Component Services и координирует двухфазные транзакции с фиксацией (two-phase commit transactions). Полное описание COMTI и примеры соответствующих приложений см. в документации на SNA Server версии 4.0 и в его справочной системе COM Transaction Integrator Help.
Интеграция хост-систем с Web Развитие Интернета и сопутствующих технологий открывает перед отделами информационных технологий новые возможности в распространении клиепт-серлерных приложений как на внутренних, так и на внешних пользователей. Информация и ресурсы во внутренних системах стали доступны более широкому кругу пользователей, что позволяет корпорациям эффективнее использовать существующие инфраструктуры. Кроме того, постоянно растут объемы корпоративных баз данных с критически важной информацией. Продолжая использовать мэйнфреймы и хост-системы AS/400 для поддержки баз данных, обработки транзакций и выполнения других приложений, многие организации стремятся к интеграции хостов с Web.
SNA Server и технология Web Microsoft-модель интеграции хостов с Web использует SKA Server для поддержки соединений между хостами IBM и Web-сервером типа IIS. В ней (рис. 10-31) Webбраузеры и серверы взаимодействуют друг с другом по сети с применением HTTP и TCP/IP. В свою очередь Web-сервер обращается к SNA Server через определенный серверный интерфейс, например ISAPI (Internet Server Application Progr.tmming Interface), а компьютеры SNA Server взаимодействуют с хост-системой по протоколу SNA, используя определенное соединение. Компоненты, показанные на рис. 10-31, можно развернуть на одном или нескольких компьютерах, размещенных на Вашем предприятии. Например, на малом предприятии Web-сервер и SNA Server можно установить на одном компьютере с Windows 2000 Server. С ростом числа серверов и увеличением интенсивности запросов на соединение рекомендуется устанавливать Web-сервер и SNA Server на отдельные компьютеры с Windows 2000 Server.
452
ЧАСТЬ 3
Взаимодействие с другими системами
Хостсистема
6 SNA
Рабочая станция
Server
Рис. 10-31. Взаимодействие между Web и хост-системой Для систем е Windows 2000 Server u качестве Web-сервера желательно использовать службы IIS, поскольку они тесно интегрируются с функциями управления и администрирования данной операционной системы. А интеграция с Windows 2000 Server упрощает связывание 1IS с другими приложениями BackOffice вроде SQL Server или Microsoft Exchange Server,
Способы доступа к хосту из Web-браузеров SNA Server дает возможность пользователям Web-браузеров подключаться к хостам несколькими способами. Чаше всего предприятия выбирают один из следующих вариантов: • доступ через терминал с использованием Web-браузера — потоки данных для терминалов 3270 или 5250 отображаются в окне Web-браузера; • доступ к данным на хосте через Web-браузер — пользователи могут обращаться к реляционным и нереляционным базам данных на хосте через Web-браузер; • доступ к приложениям хоста через Web-браузер — пользователи могут обращаться к системам обработки транзакций через Web-браузер. Эти варианты рассматриваются в следующих разделах; там же даются рекомендации по выбору оптимального способа доступа в конкретных условиях.
Доступ через терминал с использованием Web-браузера Доступ к приложениям хоста через традиционный интерфейс терминала 3270 или 5250 с применением Web-браузера прост и эффективен. Это решение идеально, если Ваши пользователи уже знакомы с интерфейсом текстового терминала и привыкли работать с существующими приложениями хоста. SNA Server позволяет реализовать такое решение за счет установки SNA Server Web Client (рис. 10-32). SNA Server Web Client предоставляет средства эмуляции терминалов через ActiveX-элемент, который является частью пакета, загружаемого в браузер с Web-сервера типа IIS. После загрузки и запуска этот ActiveX-элемент устанавливает соединение со спонсорским компьютером SNA Server, обеспечивающим соединение с хост-системой. При использовании этого способа никакой настройки клиентской рабочей станции не требуется, поскольку вся информация о соединении указывается администратором до загрузки SNA Server Web Client в браузер. Все необходимые данные содержатся в загружаемом пакете, что позволяет SNA Server Web Client автоматически устанавливать соединение с хост-системой.
ГЛАВА 10
Взаимодействие с хост-системами IBM
453
ActiveX-элемент SNA Automation
Рис. 10-32. Доступ к хост-системам через терминалы с применением SNA Server Web Client Загрузка SNA Server Web Client осуществляется однократно, если только браузер не обнаруживает на Web-сервере более новой версии этого программного обеспечения; это ускоряет запуск клиента и сводит к минимуму нагрузку на Ваш сервер. Поскольку SNA Server Web Client распространяется централизованно, данные о каких-либо изменениях в конфигурациях хостов автоматически передаются клиентам при следующем запуске SNA Server Web Client. В настоящее время SNA Server Web Client доступен для операционных систем Windows NT, Windows 2000, Windows 95 и Windows 98 с Internet Explorer версий 3.02 и выше. Поддерживается эмуляция терминалов 3270 и 5250. Детальное описание настройки и установки SNA Server Web Client включено в документацию на SNA Server версии 4.0.
Доступ к данным на хосте через Web-браузер Как уже говорилось, хост-система — идеальная платформа для предприятий, имеющих дело с большими базами данных. SNA Server и технология Web позволяет предоставить доступ к этим данным более широкому кругу пользователей. Стандартный способ интеграции технологии Web с базой данных на хосте — создание на основе HTML наглядных и дружелюбных к пользователю интерфейсов для систем управления базами данных на хостах, предоставляющих только текстовые интерфейсы.
454
ЧАСТЬ 3
Взаимодействие с другими системами
Например, Web-браузер собирает информацию для запроса к базе данных на HTML-форме. Далее запрос передается на Web-сервер, а от него (с помощью ISAPI или другого шлюзового интерфейса) — службе, взаимодействующей с системой управления базами данных на хосте. Результат запроса преобразуется в формат HTML и отображается в окне браузера. SNA Server — идеальный инструмент для реализации программных решений в области доступа к хост-данным на основе технологии Web, поскольку он не требует написания дополнительного кода для хоста или модификации СУБД. Кроме того, используя такие средства, как OLE DB Provider, Вы можете расширить спектр услуг, предоставляемых пользователям Web. Рис. 10-33 иллюстрирует, как компоненты доступа к данным интегрируются со SNA Server и другими сервисами для поддержки операций с файлами данных на хосте из Web-браузера. Мэйнфрейм или AS/400
Windows 2000 Server
Файловая система DDM Server APPC/MVS APPG
Рис. 10-33. Web-доступ к файловой системе хоста В браузере пользователь загружает и вводит данные на ASP-страницу (Active Server Page), размещенную на Web-сервере (IIS). После этого ASP передает данные через ADO-интерфейс в OLE DB Provider, поддерживаемый SNA Server. В этом сценарии OLE DB Provider взаимодействует с базой данных на хосте по АРРС-протоколу RLIO (Record-Level Input/Output) в архитектуре IBM DDM (Distributed Data Management) (уровня 2 и выше).
Доступ к приложениям хоста через Web-браузер Web-браузер также позволяет обращаться к ТР, выполняемым на мэйнфрейме, например к CICS- или IMS-приложениям. Используя COMTI в SNA Server, Вы можете разрабатывать клиент-серверные приложения, использующие Web-браузеры для взаимодействия с системами обработки транзакций на мэйнфреймах. Посколь-
ГЛАВА 10 Взаимодействие с хост-системами IBM
455
ку программы CICS могут обращаться к балам данных DB2, COMTI предоставляет программный доступ и к DB2 на мэйнфрейме. Вы можете обращаться к СОМ-объектам из браузера любым способом, так как COMTI создает стандартный серверный компонент COM Automation, действующий как прокси для транзакционных программ CICS или IMS. Рис. 10-34 иллюстрирует компоненты, которые Web-приложение может использовать для динамического создания объектов и вызова методов с помощью кода сценария на сервере. Мэйнфрейм Windows 2000 Server Источник данных y у р™ ™_^_^ SNA ^~-~Щ GIGS/IMS ,;
.] Рабочая станция
SNA Server
NA
COMTI
——-•-•••''!-^^|m -.— "•
"•••'
I
"S
"И 1! :
j
ASP
Рис. 10-34. Web-доступ к системе обработки транзакций на хосте Также возможно создание приложений на основе других технологий, например RDS (Remote Data Services), и клиентских сценариев. В таком случае создание объектов и вызов методов осуществляется из клиентского сценария, выполняемого на сервере, а RDS-элемент возвращает записи клиенту по HTTP.
Интеграция управления сетями Интеграцию локальных сетей и хоста нельзя считать полной, если Вы не можете управлять интегрированной сетевой средой. SNA Server предоставляет соответствующие сервисы, которые позволяют Вам (или администраторам Вашей хост-системы IBM) управлять SNA Server: •
с компьютеров Windows 2000 Professional;
• с удаленных компьютеров, использующих SNA Server Remote Access Service; • из приложений IBM NctView, выполняемых на хост-системе IBM.
Сервисы управления SNA Server Вы можете конфигурировать SNA Server и управлять им через SNA Server Manager (с графическим интерфейсом) или интерфейс командной строки. SNA Server Manager — это оснастка ММС, которая обеспечивает мониторинг, диагностику и управление ресурсами и сервисами SNA Server, в том числе: • иоддоменами SNA Server; • компьютерами;
456 •
ЧДСТЬ 3
Взаимодействие с другими системами
конфигурациями;
• сервисами каналов; • соединениями; .
Ш;
• сеансами; • сервисами; • пользователями. SNA Server Manager интегрирует уиранление всеми сервисами SNA Server, включая сервисы TN3270 и TN5250, HosL P r i n t Service, Shared Folders Gateway Service и Host Security Integration. SNA Server Manager позволяет наблюдать за всеми компьютерами SNA Server в поддомене SNA Server и управлять сразу несколькими поддоменами. Вы можете удаленно настраивать и администрировать компьютеры SNA Server по любым стандартным протоколам, в том числе: • TCP/IP; • IPX/SPX; • Banyan VINES IP; • Named Pipes; • с использованием службы маршрутизации и удаленного доступа Windows 2000. SNA Server Manager запускается па любом компьютере с Windows 2000 Professional, настроенном как клиент SNA Server. Кроме того. SNA Server Manager позволяет просматривать и управлять одним и тем же поддоменом сразу нескольким администраторам. Примечание SNA Server также предоставляет интерфейс командной строки, дающий возможность записывать команды, связанные с настройкой, в командные файлы. Подробнее па эту тему см. документацию на SNA Server версии 4.0 и Microsoft BackOffice Resource Kit.
Интеграция со службами управления Windows 2000 Поскольку SNA Server является приложением BackOffice, SNA Server Manager тесно интегрирован с другими оснастками ММС в Windows 2000, включая: • • •
User Manager (Диспетчер пользователей); System Monitor (Системный монитор); Event Viewer (Просмотр событий).
Интеграция с User Manager предоставляет пользователям Windows 2000, компьютерам со SNA Server Client и пользователям других приложений BackOffice общую базу данных учетных записей и стандартную систему защиты. Интеграция с System Monitor позволяет указывать счетчики производительности для мониторинга интенсивности SNA-трафика компьютеров SNA Server. Наконец, с помощью Event Viewer можно быстро выяснить, какие события вызвали ту или иную проблему в нодломене SNA Server.
ГЛАВА 10
Взаимодействие с хост-системами IBM
457
Подробнее об управлении ресурсами и сервисами SNA Server из ММС см. документацию на SNA Server версии 4.0 и Microsoft BackOffice Resource Kit.
Интеграция с сервисами управления IBM NetView SNA Server также обеспечивает интеграцию с системами управления сетями FBM NetView, выполняемыми на мэйнфреймах ШМ (рис. 10-35). Система генерации отчетов XctVicw передает уведомления и прочую информацию между хост-системой и компьютерами, подключенными к ней. Функциональность NetView можно расширить за счет ее связывания с функциональностью Winclows 2000 и SNA Server через следующие сервисы: •
NVAlert;
• •
NVRunCmd; Response Time Monitor;
•
Link Alerts for SDLC and Token Ring. NetView
'I 'r•
.
Сервис NVAlert
<^l *•
-sjg**™
Подсистема журнала событий
•!&1-»-яв еобыт?
^ NVAIert.irD
IA rver
Сервис NVRunCrnd
4h- •"•••••-
НР=
Интерфейс
командной строки Windows 2000
Рис. 10-35. Взаимодействие SNA Server с IBM NetView
Сервис NVAlert Как показано на рис. 10-35, сервис NVAlert передает информацию о событиях из журнала Windows 2000 системе IBM NetView на хост-компьютере. Эта информация посылается и виде стандартных уведомлений NetView. NVAlert может сообщать о событиях двух категорий: генерируемых операционной системой Windows 2000 и вызываемых приложениями Windows 2000. Информацию о событиях можно пересылать па консоль NetView или в файл журнала на хост-системе. NVAlert определяет, какое событие было передано консоли NetView, считывая файл NVAlert.ini.
Сервис NVRunCmd Этот сервис позволяет передавать команды, выдаваемые с консоли NetView, на компьютер с Windows 2000 и SNA Server. Сервис NVRunCmd также возвращает результаты выполнения команд на консоль NetView в стандартных текстовых и числовых форматах.
458
ЧАСТЬ 3
Взаимодействие с другими системами
Response Time Monitor Response Time Monitor (RTM) — это функция хоста IBM, которая в сочетании с Net View позволяет измерять время ответа хоста в ходе сеанса 3270. Инструмент Response Time Monitoring, предоставляемый SNA Server, дает возможность указывать, когда RTM должен посылать данные, а также определять триггеры, заставляющие RTM регистрировать момент ответа от хоста.
Link Alerts for SDLC and Token Ring Если соединение SDLC (Synchronous Data Link Control) или Token Ring накапчивается неудачей, SNA Server записывает соответствующую диагностическую информацию, называемую уведомлениями каналов (link alerts). Уведомления регистрируются в файле журнала, который можно просматривать с помощью Event Viewer из Windows 2000. Подробнее о сервисах управления SNA Server, в том числе об их интеграции со службами управления Windows 2000 и хостами IBM, см. документацию на SNA Server версии 4.0.
Дополнительные материалы Более подробную информацию об обновленных версиях SNA Server и сопутствующих спецификациях см. по ссылке: •
SNA Server на странице Web Resources (http://windows.microsoft.com/wmdows2000/reskit/webresources).
ГЛАВА
И
Services for UNIX
Взаимодействие с другими операционными системами очень важно R современных вычислительных средах, которые становятся все более гетерогенными. Microsoft Services for UNIX обеспечивает интеграцию Windows-систем в существующую UNIX-среду и позволяет переносить уже написанные UNIX-сценарии в Windowsсреду, упрощая задачи администрирования. Здесь предполагается, что Вы знаете материалы, изложенные в приложении Б «Концепции взаимодействия с UNIX» в этой книге. Внимание На момент подготовки книги к изданию текущей версией Services for UNIX была версия 1.0, рассчитанная на Windows NT 4.0. Информацию о новых нерсиях Services for UNIX и их функциональности см. на Web-узле Microsoft (http:// www.microsoft.com). В этой главе Обзор 460 Доступ к файлам через NFS
460
Клиент и сервер Telnet в Services for UNIX Синхронизация паролей 473 Утилиты UNIX и оболочка Когп
471
476
См. также • Подробнее о правах доступа к файлам в Windows, о NTFS и FAT — книгу «Сопровождение сервера» из серии «Ресурсы Microsoft Windows 2000 Server». • Подробнее о TCP/IP — главу 1 «Введение в TCP/IP» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». • Об аутентификации — книгу «Распределенные системы* из серии «Ресурсы Microsoft Windows 2000 Server». • О планировании защиты — книгу «Deployment Planning Guide» из Microsoft Windows 2000 Server Resource Kit. • О печати файлов в сети — книгу «Сопровождение сервера» из серии «Ресурсы Microsoft Windows 2000 Server».
460
ЧАСТЬ 3
Взаимодействие с другими системами
Обзор Компонент Services for Unix поддерживает UNIX-платформы: • Digital" UNIX; • Hewlett-Packard HP-UX® 10.1+; • Sun Solans® SPARC 2.5.1+. Services for UNIX предоставляет следующие средства. Network File System (NFS). Клиентское и серверное программное обеспечение NFS позволяет обращаться с компьютеров под управлением Windows NT к файлам на компьютерах под управлением UNIX и наоборот. Примечание Services for UNIX не предусматривает сервисы печати. В Windows 2000 встроены собственные сервисы печати UNIX: LPR (Line Printer Remote) и LPD (Line Primer Daemon). Подробнее на эту тему ем. книгу «Сопровождение сервера» из серии «Ресурсы Microsoft Windows 2000 Server». Telnet Client and Server. Это программное обеспечение позволяет входить в системы под управлением Windows NT или UNIX из сети и выполнять на них команды. Синхронизация паролей. Services for UNIX обеспечивает синхронизацию паролей для пользователей компьютеров с Windows NT и UNIX. Изменения в паролях Windows автоматически распространяются на компьютеры с UNIX. Утилиты и средства поддержки сценариев UNIX. Services for Unix поддерживает UNIX-команды и оболочку Korn, с помощью которых можно автоматизировать рутинные процессы и выполнение административных задач на платформах Windows и UXIX.
Доступ к файлам через NFS NFS (RFC 1094 и 1813) является набором протоколов для доступа к сетевым файлам, обеспечивающим взаимодействие между различными файловыми системами в гетерогенных сетях. Клиенты используют NFS, например, при обращении к файлам па удаленных серверах. NFS построена по модели «клиент-сервер* и опирается на протоколы RPC (Remote Procedure Call) (метод обмена сообщениями между клиентом и сервером, определенный в RFC 1831, 1050 и 1057) и XDR (External Data Representation) (метод трансляции данных между гетерогенными системами, определенный в RFC 1832 и 1014). Удаленные файловые системы на сервере монтируются па клиенте, поэтому они кажутся ему локальными, и он может обращаться к ним так же, как и к обычным файловым системам.
Поддерживаемые версии NFS Существует две версии NFS: версия 2 (RFC 1094) и версия 3 (RFC 1813). Особенности и ограничения версии 2: • 32-разрядный индикатор размеров файлов (file size indicator); • используется сетевой транспорт на основе UDP или TCP; • максимальный размер NFS-пакетов — 8 Кб.
ГЛАВА 11 •
Services for UNIX
461
пакет для записи в файл должен быть передан дисковой подсистеме до того, как сервер отправит подтверждение.
Особенности и ограничения версии 3: • 64-разрядныЙ индикатор размеров файлов; • используется сетевой транспорт на основе UDP или TCP; • максимальный размер NFS-пакетов — 64 Кб при использовании TJDP; •
количество и частота обмена пакетами между клиентом и сервером зависит от размера пакетов (то же относится и к подтверждениям о приеме);
• сервер может котировать клиентские запросы на запись, если только клиент не требует непосредственной записи на диск. NFS версии 3 выбирает TCP в качестве сетевого транспорта, если TCP поддерживается и клиентом, и сервером. TCP надежнее UDP. но в определенных ситуациях работает медленнее.
Server for NFS Microsoft Server for NFS (Services for UNIX версии 1.0) — 32-разрядная мнопшоточная Windows-программа режима ядра, интегрированная в Windows NT. Этот компонент позволяет обращаться к файлам в смешанной среде, состоящей из разных аппаратных платформ, операционных систем и сетей. Server for NFS превращает компьютер под управлением Microsoft Windows в сервер NFS. Доступ к файлам и административные задачи выполняются через интерфейс Windows NT. Администрирование NFS осуществляется с помощью специальной утилиты. Server for NFS использует протокол NFS, основанный па ONC-RPC (Open Network Computing Remote Procedure Call). Протокол ONC-XDR (Open Network Compming External Data Representation) обеспечивает передачу данных между клиентами и сервером NFS. NFS и связанные с ним протоколы разработаны компанией Sun Microsystems. Его архитектура показана на рис. 11-1. Прикладная программа NFS
N!S+
Автоматическое монтирование
Локальный дисковый кэш
RPC/XDR Транспортный уровень Сетевые протоколы (например, TCP/IP) Рис. 11-1. Архитектура NFS
Диспетчер блокировки
462
ЧАСТЬ 3 Взаимодействие с другими системами
Server for NFS поддерживает следующие возможности. Удаленный доступ к файлам. После установки Services for UNIX сервер Windows NT может сделать каталоги и файлы Windows доступными клиентах: NFS. Средства управления доступом позволяют назначать клиентам разрешения «только для чтения», «для чтения и записи», «доступ к корню» и «доступ запрещен». Права на доступ к индивидуальным файлам контролируются разрешениями, заданными в файловой системе Windows NT. Глобальные разрешения. Клиенты NFS могут быть сгруппированы. NFS-доступом можно управлять либо по именам клиентов, либо по именам групп. Разрешения безопасности. Server for NFS можно настроить на использование разрешений NTFS. Сопоставление пользовательских и групповых учетных записей. Для защиты файлов в Windows NT, к которым обращаются из UNIX, Server for NFS требует от системного администратора сопоставить учетные записи пользователей или групп в UNIX с эквивалентными учетными записями в Windows NT. Тогда пользователи получают в UNIX те же права доступа, что и в Windows NT. На сайтах с менее жесткими требованиями к безопасности можно пропустить эту процедуру сопоставления и считать всех UNIX-клиентов анонимными пользователями. Размер буфера для считываемых и записываемых данных. Размер этого буфера можно изменять для оптимизации производительности. NFS-потоки. Вы можете указать количество потоков для параллельной обработки запросов на сервисы NFS. Максимальное число потоков — 512. Кэширование inode и информации о каталогах. Кэширование на NFS-сервере inode (данных об атрибутах файлов) и информации о каталогах (списка каталогов, к которым были обращения за самый последний период) позволяет сократить число системных вызовов этого сервера и тем самым повысить его производительность. Размеры соответствующих кэшей устанавливаются с помощью Server for NFS. Символьные ссылки. Server for NFS можно настроить на поддержку символьных ссылок (symbolic links). Блокировка файлов. Такую блокировку можно включить либо только для клиентов NFS (необязательная блокировка) (advisory locking), либо для клиентов NFS и пользователей Windows NT (обязательная блокировка) (mandatory locking). Разрешение конфликтов из-за регистра букв в именах файлов. Server for NFS можно настроить на разрешение конфликтов, которые возникают между именами файлов NFS и NTFS/FAT/CDFS из-за чувствительности к регистру букв. Допускается преобразование имен файлов в буквы только верхнего регистра или только нижнего регистра; кроме того, можно просто игнорировать регистр букв в именах файлов. Символы, допустимые в UNIX, но не поддерживаемые в Windows NT, можно преобразовать в другую последовательность символов с помощью файла трансляции (translation file). Например, Windows 2000 запрещает использование в именах файлов знака двоеточия, и с помощью файла трансляции Вы можете выбрать подходящую последовательность символов для замены всех двоеточий в имени файла, полученного с компьютера под управлением UNIX. NFS версий 2 и 3, версий NFS.
Server for NFS можно настроить на поддержку одной из этих
ГЛАВА 11
Services for UNIX
463
Транспорт данных с помощью TCP или UDP. По умолчанию Services for LI MIX использует для транспорта данных протокол UDP. Вы можете настроить Server for NFS на TCP, который более надежен, но в некоторых ситуациях менее производителен. Диагностические утилиты. Services for UNIX поддерживает команды showmount и rpcinfo, позволяющие находить причины проблем с NFS.
Client for NFS Microsoft Client for NFS (Services for UNIX версии 1.0) позволяет компьютеру под управлением Windows NT действовать в качестве клиента NFS и обращаться к каталогам и файлам, находящимся на сервере NFS. Клиент NFS монтирует каталог на сервере NFS. Client for NFS обеспечивает следующие возможности. Доступ к удаленным файлам. Каталоги и файлы, экспортированные с сервера NFS, могут быть смонтированы клиентом NFS локально. Права пользователя на доступ к этим каталогам или файлам определяются параметрами экспорта файловой системы и применимыми разрешениями. Настройка параметров монтирования. В UNIX пользователь или системный администратор подключается к удаленной файловой системе командой mount. Эта команда поддерживает набор параметров, специфичный для конкретной реализации UNIX. Services for UNIX поддерживает параметры монтирования, определяющие: • размер буфера, от которого зависит, сколько пакетов посылается в одном запросе на чтение или запись; • тип монтирования (жесткий или нежесткий). При жестком монтировании системные вызовы сервера, переставшего отвечать, повторяются бесконечно, а при нежестком монтировании этого не происходит. Файловые системы, экспортируемые с разрешением на доступ для чтения и записи, требуют жесткого монтирования, чтобы гарантировать целостность данных; • время ожидания ответа от сервера при RPC-вызове; • количество повторных RPC-вызовов в отсутствие ответа от сервера NFS (только при нежестком монтировании); • возможность использования блокировки файлов, позволяющей получать монопольный доступ к какому-либо файлу. Блокировка файлов в NFS работает эффективнее, если ее применение разрешено на всех клиентах NFS; • возможность кэширования считываемых данных на клиенте NFS (такое кэширование уменьшает число обращений к серверу NFS); • возможность кэширования записываемых данных па сервере NFS (такое кэширование уменьшает издержки при записи небольших порций данных). Выбор методов аутентификации. Поддерживается три метода аутентификации. •
Анонимный UID. Способ идентификации пользователей без логина (имени) и пароля на сервере NFS. • Стандартная аутентификация в UNIX с использованием сервера NIS. Способ аутентификации пользователей, логины и пароли которых хранятся на сервере N1S.
464
•
ЧАСТЬ 3
Взаимодействие с другими системами
Аутентификация PCNFSD. Способ аутентификации, при котором проверка логина и пароля для клиентских компьютеров NFS осуществляется с помощью демона pcnfsd.
Разрешение символьных ссылок. Services for UNIX разрешает переименование и удаление символьных ссылок. Чтобы Client for NFS мог найти целевой файл, на который указывает символьная ссылка в файловой системе, отличной от смонтированной на данный момент, в специальном конфигурационном файле должна быть соответствующая запись. (Такой файл сопоставляет удаленную файловую систему с именем сервера этой файловой системы или именем общего сетевого ресурса.) В отсутствие подобной записи Client for NFS считает, что целевой файл находится па клиентском компьютере. Подключение каталогов NFS как локальных дисков. Смонтированные каталоги NFS можно подключать как локальные диски в Windows-системе, что позволяет просматривать подключенный катало! с помощью Windows Explorer (Проводник), Изменение нрав на доступ к файлу. разрешения для удаленных файлов.
Client for NFS позволяет изменять UNIX-
Разрешение конфликтов из-за регистра букв в именах файлов. Поскольку UNIX чувствительна к регистру букв в именах файлов, a Windows — нет (она лишь сохраняет исходные регистры букв), то Services for UNIX предусматривает настройки для разрешения конфликтов, связанных с регистром букв в именах файлов, Диагностические утилиты. Services for UNIX поддерживает команды showmount и rpcinfo, позволяющие находить причины проблем с NFS.
Протоколы NFS NFS состоит из протоколов семи уровней, соответствующих уровням модели OSI (Open System Interconnection). Таблица 11-1. Уровни OSI и протоколы NFS Уровни OSI
Уровни NFS
Прикладной Презентационный
NFS и NTS
Сеансовый Транспортный Сетевой Канальный Физический
XDR RFC
TCP, U DP IP
Ethernet Ethernet
Описание уровней модели OSI см. в приложении А «Модель OSI» в книге «Сети TCP/IP* из серии «Ресурсы Microsoft Windows 2000 Server».
Протокол RPC Протокол RPC (Remote Procedure Call) позволяет вызывать процедуры, выполняемые па другом компьютере в сети. RPC базируется на модели «клиент-сервера. Клиент вызывает процедуру, которая кажется ему локальной, но на самом деле находится на удаленном компьютере. При вызове аргументы процедуры упаковываются в специальный формат и передаются по сети на сервер, где они распаковыва-
ГЛАВА 11
Services for UNIX
465
ются. Результат преобразуется в тот же формат и возвращается клиенту; после распаковки клиент получает значение, возвращенное удаленной процедурой. RPC использует IJDP или TCP; поскольку RPC-вызовы компактны, предпочтение отдается UDP. Из-за этого RPC-вызов должен содержать всю необходимую информацию в одном пакете, так как UDP не гарантирует доставки пакетов в правильной последовательности. Кроме того, клиент может задать максимальное время ожидания, но истечении которого вызов повторяется или передается другому серверу. RPC предоставляет набор процедур, называемых программами. Каждая программа (RPC-сервис) идентифицируется по номеру. Например, NFS — это программа под номером 100003. Когда RPC-сервис запускается в UNIX, он регистрируется у демона portmapper. Тот фиксирует номер и версию RPC-сервиса и выделяет TCP- или UDP-порт, по которому этот сервис будет принимать входящие запросы. Демон porlmapper тоже является RPC-сервисом, который прослушивает TCP- и UDP-порты 111. Получить список RPC-программ, зарегистрированных на данном компьютере, можно с помощью команды rpcinfo (таблица 11-2). Таблица 11-2. Параметры командной строки для rpcinfo Параметр
Описание
-р [хост]
Перечисляет все RPC-программы, зарегистрированные па указанном хосте
-ц <хост программа> [версия] <принят>
Посылает команду null целевому хосту и RPC-программе с использованием UDP и сообщает, получен ли ответ
-t <xocm программой\версия] <-принят>
Посылает команду null целевому хосту и RPC-программе с использованием TCP и сообщает, получен ли ответ
-Ь <про?.рамми версия> Выдает широковещательный RFC-запрос на указанную программу заданной версии (по UDP) и перечисляет все ответившие хосты
Rpcinfo полезна при устранении проблем с RPC (позволяя, например, выяснить, активен ли нужный сервер), с демоном portmapper или с широковещанием. RPC-вызовы, доступные клиенту NFS, перечислены в таблицах 11-3 и 11-4. Таблица 11-3. RPC-вызовы NFS версии 2 Имя RPC-вызова
Описание
create getattr link
Создать файл Получить атрибуты файла Создать связь с файлом
lookup
Найти файл с определенным именем
mkdir
Создать каталог
read rcaddir
Читать из файла Читать и,ч каталога
rcadlink
Читать по символьной ссылке
remove
Удалить файл
rename
Переименовать файл
rmdir
Удалить каталог
1вз«.зз43
(см. след, стр )
466
ЧАСТЬ 3 Взаимодействие с другими системами
Таблица 11-3.
(продолжение)
Имя RPC-вызова
Описание
sctattr slatfe symlink write
Установить атрибуты файла Получить атрибуты файловой системы Создать символьную ссылку Записать в файл
Таблица 11-4. RPC-вызовы NFS версии 3 Имя RPC-вызова
Описание
access create commit t'sstat fsinfo getattr link lookup mkdir mknod pathconf read readclir readdirplus read] ink remove rename rmdir setat.tr symlink write
Проверить права пользователя на доступ Создать файл Записать кэшированные данные Получить атрибуты файловой системы Получить информацию о файловой системе Получить атрибуты файла Создать связь с файлом Найти файл с определенным именем Создать каталог Создать специальный узел устройств Извлечь информацию POSIX Читать из файла Читать из каталога Расширенное чтение из каталога Читать по символьной ссылке Удалить файл Переименовать файл Удалить каталог Установить атрибуты файла Создать символьную ссылку Записать в файл
NFS-потоки Когда выдается запрос на какой-либо сервис NFS, сервер NFS под управлением Services for UNIX создает поток для обработки этого запроса. Каждый поток может обрабатывать один запрос. Больший пул потоков позволяет серверу параллельно обрабатывать большее число NFS-запросов. Однако нужно учитывать, что слишком большое количество потоков может отрицательно повлиять на общую производительность сервера. Для определения оптимального числа потоков используйте такую формулу:
16 + (4 X Л*) где N — число дополнительных процессоров на сервере NFS. В соответствии с этой формулой на двухпроцессорном сервере (iV= 1) не должно быть более 20 потоков. Максимально возможное число потоков равно 512.
ГЛДВА 11
Services for UNIX
467
Аутентификация PCNFSD NFS может использовать для проверки подлинности демон аутентификации PC/ NFS (PC/NFS daemon, PCNFSD). После аутентификации через PCNFSD выдается идентификатор пользователя (user ID, UID) и идентификатор группы (group ID, GID). Если UID- и GID-идентификаторы одинаковы на всех UNIX-серверах NFS, то на роль сервера PCNFSD нужно назначить только один из серверов. PCNFSD сравнивает имя и пароль пользователя с содержимым файла /etc/passwd. Обнаружив совпадение, сервер PCNFSD возвращает соответствующие UID и GID. Цели аутентификация не реализована (т.е. Вы не применяете ни PCNFSD, ни MS), Client for NFS назначает пользователю анонимные UID (-2) и GID (-1). Если сервер NFS сконфигурирован на анонимный доступ, пользователь может обращаться к файлам в режиме доступа «только для чтения*.
Команда show/mount Команда showmount запрашивает у демона mountd на указанном удаленном хосте информацию о том, какие клиенты монтируют каталоги с этого хоста. Демон mountd принимает запрос на монтирование от клиента NFS, проверяет список экспортируемых файловых систем в /etc/exports и, если запрос можно удовлетворить, создает описатель запрошенного каталога, а затем добавляет соответствующую запись в /etc/rmtab на компьютере с UNIX. Некоторые параметры команды showmount перечислены в таблице 11-5, Таблица 11-5, Параметры showmount Параметр
Описание
-а [хост]
Перечисляет хост-имена клиентов и смонтированные ими каталоги в виде (хост: каталог)
-d [;rocm] -е [хост]
Перечисляет каталоги, смонтированные клиентом Показывает список экспорта сервера NFS
Поскольку команда showmount получает свою информацию через демон mountd, список смонтированных каталогов может оказаться неполным. Кроме того, showmount сортирует выводимую информацию и удаляет в ней повторяющиеся данные, поэтому каталог, смонтированный несколько раз, перечисляется только единожды. Подробнее о showmount см. справочную систему Services for UNIX.
Особенности архитектуры NFS Понимание некоторых особенностей NFS, рассматриваемых в этом разделе, поможет Вам оптимизировать работу NFS.
Inode Для записи информации о файле UNIX использует inode, которому присваивается уникальный номер. Inode назначается каждому файлу и каждому каталогу. У файла может быть несколько имен (в зависимости от числа связей), но только один inode. В inode содержатся следующие элементы; •
номер inode;
•
имя файла;
468
ЧАСТЬ 3 Взаимодействие с другими системами
• размер и тип файла; • дата и время создания файла, его модификации и последнего обращения к нему; • дата и время изменения mode; •
информация, связанная с защитой файла (владелец, группа, разрешения);
• количество связей (ссылок); • карта с указателями на блоки данных, из которых состоит файл.
Именование файлов Сервер NFS применяет следующие правила именования файлов: • имя файла не должно быть длиннее 255 символов; •
символы < > : " / \ j не должны встречаться в именах файлов;
• сервер воспринимает знак точки как текущий рабочий каталог, а знаки «..» как родительский каталог текущего рабочего каталога.
Разрешения на типы доступа к файлам С каждым файлом сопоставлен набор разрешений, определяющих, кто имеет права на доступ к этому файлу и что он может делать с ним. (Изменять разрешения может суперпользователь или тот, у кого есть права на доступ к корню.) Windows NT и UNIX используют разные механизмы сопоставления разрешений с файлами. В Windows NT для этого применяется список управления избирательным доступом (discretionary access-control list, DACL), а в UNIX — концепция режима доступа. Режим доступа можно изменять командой chmod, поддерживаемой Services for UNIX. В UNIX возможны следующие типы доступа к файлам: чтение, запись или выполнение; предоставляемые типы доступа зависят от того, кто обращается к файлу пользователь (user), группа (group) или прочие (other). Разрешения пользователя выдаются владельцу файла, разрешения группы — членам группы, к которой относится пользователь, создавший файл, разрешения прочих — пользователям, отличным от только что упомянутых категорий. Таблица 11-6. Разрешения на типы доступа к файлам Тип доступа к файлу Чтение Запись Выполнение
Описание Позволяет считывать файл или просматривать каталог Позволяет создавать, изменять или удалять файл либо каталог Позволяет запускать исполняемый файл или просматривать каталог
UNIX идентифицирует пользователей и группы по UID и GID. У пользователя имеется единственный UID и один или несколько GID, которые хранятся в файле /etc/passwd. Windows NT связывает разрешения с файлом, добавляя в DACL запись управления доступом (access control entry, ЛСЕ). АСЕ определяет какое-либо право, выданное конкретному пользователю или группе. Services for UNIX преобразует DACL в режим доступа UNIX, исходя из того, кто является владельцем файла и какие АСЕ сопоставлены с ним. Эта операция возможна только после корректного сопоставления учетных записей пользователей и групп UNIX с соответствующими учетными записями Windows NT с помощью User Manager из Server for NFS.
ГЛАВА 11
Services for UNIX
469
Допустим, на компьютере с Windows NT создана пользовательская учетная запись johndo и добавлена в группу Users. На компьютере с UNIX тоже создана пользовательская учетная запись johndo, но добавлена в группу Staff. В Server for NFS учетная запись johndo из Windows NT сопоставляется с одноименной учетной записью из UNIX, а группа Users — с UNIX-группой Staff. Пользователь johndo становится владельцем файла letter.doc в экспортированной файловой системе NFS на компьютере под управлением Services for UNIX, получает для себя и своей группы Users разрешения Full Control и выдаст разрешения List группе Everyone (т. е. мсем пользователям). Когда пользователь johndo обращается к файловой системе I4FS на компьютере под управлением Services for UNIX с UNIX-клиента NFS и вводит команду Is -1 применительно к файлу letter.doc, он видит следующее: rwxrwxr-x
1 johndo staff
2116 Jul 1 14:54 letter.doc
Первые девять символов (группами по три) указывают разрешения на чтение (read), запись (write) и выполнение (execute) для владельца (rwx), группы (rw;) и прочих пользователей (г-х); дефис обозначает отсутствие данного разрешения. За разрешениями сообщается число жестких связей (1), имя пользователя (johndo), имя группы (staff), размер файла (2116), дата и время последней модификации файла (Jul 1 14:54) и имя файла. Примечание Когда владельцем файла является член Windows NT-группы Administrators, возникает особая ситуация. В этом случае Server for NFS автоматически-лрисваивает ему UID 0 (корень) на компьютере с UNIX. Если бы владелец файла не получил явные разрешения через АСЕ, то в предыдущем примере у владельца не было бы прав на доступ к этому файлу (режим доступа 0). Администратор Server for NFS может смешаться в эту схему, установив флажок Implicit Permissions на вкладке Security Permissions диалогового окна Server for NFS Configuration. Если флажок Implicit Permissions установлен, Server for NFS комбинирует разрешения, выданные любым группам, в которые входит владелец файла и которые предоставляют какие-либо права на доступ к этому файлу, с разрешениями для группы Everyone. На основе этой комбинации разрешений владелец получает соответствующие права на доступ к своему файлу. Файл, создаваемый в Windows NT, наследует разрешения своего родительского каталога. Если клиент NFS выдает команду chgrp или chmod, выполняемую на сервере с Services for UNIX, тогда по умолчанию Server for NFS удаляет любые существующие элементы в DACL и создает свои записи для трех сущностей NFS (владельца, группы и прочих). В итоге файл теряет унаследованные разрешения. Администратор Server for NFS может вмешаться в эту схему, выбрав Augment DACL на вкладке Security Permissions. Тогда Server for NFS записывает и разрешения, унаследованные от родительского каталога.
Символьные ссылки Символьная ссылка (symbolic link) — это файл, указывающий на другой файл и.ти каталог (т. е. он содержит путь к другому файлу или каталогу). Символьная ссылка может указывать на файл или каталог в любой файловой системе UNIX, доступной по сети. Система находит целевой файл, считывая содержимое символьной ссылки. Такие ссылки очень удобны, если, например, файл должен быть доступен из нескольких каталогов.
470
ЧАСТЬ 3
Взаимодействие с другими системами
Символьные ссылки могут содержать абсолютный или относительный путь. Поскольку ссылка разрешается в файловой системе на клиенте, может получиться так, что она указывает на файл или каталог, которого нет на клиентской системе, либо па файлы, находящиеся в неподключенном каталоге. Такие файлы недоступны. RFC-вызов сервера для определения адресата символьной ссылки возвращает путь, который интерпретируется на клиенте, но который может указывать на файловую систему, не смонтированную клиентом. Если клиент монтирует каталог с символьной ссылкой, он должен смонтировать и каталог с целевым файлом, иначе этот файл останется недоступным. Кроме того, Client for NFS может проверять содержимое локального конфигурационного файла (заполняемого вручную) и находить корректные адреса (если они там есть) целевых файлов, на которые указывают символьные ссылки. Например, системный администратор UNIX-сервера NFS, server 1, создает символьную ссылку с именем «public», указывающую на фиктивный каталог /server2. В этом случае команда Is -1 сообщает: Irwxrwxrwx 2
root
other
8
Jul 1 16:25 public->/server2
Далее на компьютере Client for NFS или в сетевой файловой системе, доступной с этого компьютера, системный администратор создает текстовый файл со списком предполагаемых символьных ссылок. Его записи выглядят примерно так: server2
\serveг2\ння_общвго_ресурса
Когда компьютер Client for NFS подключается к экспортируемой файловой системе на server 1, он разрешает символьную ссылку public и инициирует NFS-соединение с \server2:\шия_о(5н$его_ресг/рсй. Это позволяет клиенту просматривать файлы, хранящиеся на удаленном сервере server2.
Блокировка файлов Эта функция позволяет процессу получить монопольный доступ к файлу или его части. Блокировка файлов реализуется на сервере и клиенте. Сервер, перезагруженный после краха, пытается восстановить предыдущее состояние всех блокировок, Если крах происходит на клиенте, сервер освобождает блокировку, установленную этим клиентом. Однако после перезапуска клиент может быстро возобновить блокировку (если успеет сделать это в течение очень короткого времени). Когда файл блокирован, буферный кэш для него не используется. Каждый запрос на запись немедленно посылается серверу. Блокировка файлов в BSD UNIX реализуется иначе, чем в System V UNIX (это две версии UNIX, от которых произошло большинство современных операционных систем UNIX). BSD поддерживает блокировку только локальных файлов; блокировки в System V обрабатываются отдельно от NFS с помощью демонов lockd и statd. Первый выполняется как на клиенте, так и на сервере для обработки запросов на блокировку и для освобождения блокировок. Удаленные демоны lockd взаимодействуют друг с другом по протоколу NLM (Network Lock Manager).
Кэширование файлов Кэширование файлов заключается в сохранении часто используемых данных в оперативной памяти. Буферный кэш UNIX — это часть системной памяти, выделяемая под блоки файлов, на которые недавно были ссылки. В NFS кэширование фай-
ГЛАВА 11
Services for UNIX
471
лов применяется па клиенте (чтобы не передавать лишние RPC-запросы по сети) и на сервере (для повышения его пропускной способности). NFS обеспечивает целостность данных, несмотря на существование клиентского и серверного кэшей. Редиректор NFS, открывая какой-либо файл только для чтения или для чтения/ записи, использует системный кэш Windows NT. Когда данные записываются в файл, они на самом леле записываются в КУШ и перелаются редиректору позднее. Если в сети произойдет какой-нибудь серьезный сбой в момент пересылки данных удаленному серверу, запрос на запись может закончиться неудачей. Диспетчер кэша Windows NT также выполняет опережающее чтение, заранее загружая в кэш следующий блок данных из файла. В результате однозначно сопоставить запрос приложения на чтение/запись и NFS-вызов нельзя. Редиректор NFS поддерживает блокировку файлов с использованием протокола NLM. Кэширование данных разрешается, если блокировка файлов запрещена. Server for NFS не предусматривает кэширования файлов.
Клиент и сервер Telnet в Services for UNIX Примечание Windows 2000 Server предоставляет сервер Telnet (поддерживающий не более двух клиентских соединений одновременно) и клиент Telnet, Telnetc.exe. Подробнее на эту тему см. справочную систему Windows 2000 Server. Клиентское программное обеспечение Telnet позволяет соединяться с удалеплым компьютером, а серверное программное обеспечение Telnet дает возможность клиентам Telnet подключаться к серверу, регистрироваться на нем и запускать его приложения. Клиентское и серверное программное обеспечение Telnet, поставляемое с Services for UNIX версии 1.0, принимает соединения от UNIX- и Windows-клиентов Telnet и позволяет им подключаться друг к другу и к любым серверам Telnet. Пользователи UNIX могут обращаться к Windows-серверам и запускать па них программы с текстовым интерфейсом; кроме того, па сервере Telnet под управлением Services for UNIX можно запустить какую-нибудь оболочку UNIX, например Кот. Программное обеспечение Telnet в Services for UNIX также позволяет системному администратору удаленно управлять Windows- и UNIX-серверами. Программное обеспечение Telnet в Services for UNIX поддерживает: • удаленное администрирование UNIX из Windows, Windows из UNIX и Windows из Windows; • средство управления сервером Telnet с текстовым интерфейсом; • интерфейс эмуляции командной строки Telnet; • терминал типа VTNT для соединений между Telnet-клиентом Services for UNIX и Telnet-сервером Services for UNIX; • эмуляцию терминалов VT100, VT52, VTNT и ANSI; • NTLM-аутентификацию для сеансов Telnet между Windows-компьютерами с использованием Microsoft-клиента и сервера Telnet; • общеизвестные параметры и команды Telnet.
472
ЧАСТЬ 3
Взаимодействие с другими системами
Протокол Telnet Для подключения клиента к удаленному компьютеру, выполняющему серверное программное обеспечение Telnet, используется протокол Telnet, определенный в RFC 854. Он предоставляет механизм двухстороннего коммуникационного взаимодействия, позволяющий терминальным устройствам и процессам, ориентированным на терминалы, обращаться друг к другу. Telnet передает данные и управляющую информацию по TCP. По умолчанию Telnet использует TCP-порт 23.
Network Virtual Terminal Network Virtual Terminal (NVT) — это определение базового терминала и стандарт, которого должны придерживаться обе стороны Telnet-соединения. Он определяет, как данные и команды передаются по сети, и обеспечивает взаимодействие между Telnet и самыми разнообразными аппаратными платформами и операционными системами. NVT состоит из виртуальной клавиатуры, генерирующей указанные пользователем символы, и принтера, выводящего определенные символы. Клиенты и серверы Telnet могут сопоставлять свои локальные устройства с NVT и исходить ш того, что остальные клиенты и серверы делают то же самое.
Сеанс Telnet Если в команде telnet не указывается имя какого-либо компьютера. Telnet переходит в интерактивный режим командной строки и выводит соответствующее приглашение пользователю. Активизация Telnet приводит к тому, что он создает TCPсоединение с сервером и демоном Telnet, tlntsvr. Установив соединение, Telnet переходит в режим ввода. В зависимости от настроек удаленного компьютера введенный текст передается посимвольно или построчно. Пользователи могут в любой момент активизировать командный режим Telnet с помощью escape-последовательности. В Services for UNIX такая последовательность представляет собой комбинацию клавиш Clrl-t-Л.
Функциональность Telnet Кроме стандартной функциональности (определяемой NVT), клиенты и серверы могут согласовывать дополнительную. Механизм определения функций Telnet описан в RFC 855. Каждой функции Telnet назначается свои номер. Функциональность обычно согласуется в начале сеанса Telnet, но может быть запрошена и позже. При согласовании стороны обмениваются последовательностями номеров функций. Любая из сторон может запросить какую-либо функцию, а другая — согласиться с запросом или отклонить его. Синтаксис протокола согласования включает четыре команды: WILL/DO (запрос или предложение) и WON'T/ DON'T (прямо противоположное). Потенциально согласование функциональности может привести к бесконечному обмену подтверждениями. Services for UNIX поддерживает следующую функциональность Telnet: • NTLM-аутентификацию, использующую алгоритм рандомизации и шифрованные пароли; •
эмуляцию терминалов, при которой компьютер действует как терминал выбранного типа (VTNT, VT100, VT52 или ANSI).
ГЛАВА 11
Services for UNIX
473
Безопасность Telnet Services for UNIX предоставляет два варианта защиты: •
UNIX-аутентификацию, при которой используется логин и пароль UNIX Пароль передается открытым текстом;
• NTLM-аутентификацию между клиентом и сервером Telnet из Services for UNIX. Это сквозная аутентификация, при которой удостоверения защиты (имя домена, имя пользователя и хэшированный пароль) передаются через контроллеры доменов по соединениям между доверяемыми доменами. При этом пользователю не предлагается ввести логин и пароль. Этот вариант обеспечивает интеграцию с системой защиты Windows. При использовании NTLM можно обращаться к ресурсам только данного удаленного компьютера — доступ к другим сетевым ресурсам требует новой аутентификации.
Синхронизация паролей Services for UNIX версии 1.0 содержит компонент Password Synchronization, который обеспечивает синхронизацию паролей между компьютерами с Windows и UNIX, повышая степень взаимодействия двух систем. Этот компонент поддерживает общий пароль как на компьютере с Windows, так и на компьютере с UNIX. Password Synchronization в Services for UNIX позволяет системному администратору так конфигурировать сеть с Windows- и UNIX-системами, что изменение iiiipoля в Windows автоматически распространяется и на эквивалентное имя пользователя в файлах паролей группы компьютеров с UNIX. Services for UNIX можно настроить на передачу измененных паролей из Windows NT в UNIX либо открытым текстом, либо в зашифрованной форме. Все пароли пользователей должны соответствовать правилам как Windows, так и UNIX. Компонент Password Synchronization поддерживает: • одностороннюю синхронизацию паролей (от Windows к UNIX); • небезопасную синхронизацию паролей, передаваемых открытым текстом (для этого используется команда rlogin); • безопасную синхронизацию паролей с применением метода шифрования Triple DES, специального демона из состава Services for UNIX, шифровального ключа для изменения пароля в файле /etc/passwd и NIS (Network Information Service) или NIS+; • административные утилиты для управления всеми процессами синхронизации паролей.
Использование синхронизации паролей Реализуя синхронизацию паролей с помощью Services for UNIX, примите во внимание следующие соображения. Имя и пароль пользователя. Имя и пароль пользователя должны быть одинаковы па Windows- и UNIX-компьютерах, настроенных на синхронизацию паролей. Имена и пароли чувствительны к регистру букв,
474
ЧАСТЬ 3
Взаимодействие с другими системами
Контроллеры домена. Если Вы установили Services for UNIX версии 1.0 для Windows NT 4.0, на всех контроллерах домена Windows NT нужно установить Services for UNIX с компонентом Password Synchronization. Если Services for UNIX установлена только на первичном контроллере домена (РОС) и он выходит из строя, на роль РОС выбирается резервный контроллер домена (BDC). Если на нем не установлен Services for UNIX с компонентом Password Synchronization, база данных паролей окажется в рассинхронизированном состоянии. Изменение паролей. Реализовав синхронизацию паролей, не меняйте пароли в UNIX — они будут перезаписаны при очередной смене паролей в Windows. Способ синхронизации. Все компьютеры в UNIX-секции должны использовать одинаковый способ синхронизации паролей — безопасный или небезопасный. UNIX-секция (UNIX pod) — это группа UNIX-систем, в которой один из компьютеров успешно принимает пароль, обновленный в Windows NT. NIS/NIS+ и синхронизация паролей. Services for UNIX не поддерживает обновление паролей для NIS или NIS+ с помощью команды rlogin, поэтому, если UNIXкомпьютеры управляют системно-независимой информацией (например, логинами и паролями) через NIS или NIS+. Вы должны использовать безопасный способ синхронизации паролей. NIS и распространение изменений в паролях. Если в синхронизации паролей участвует домен NIS, Services for UNIX обновляет главный домен NIS/NIS+, а тот распространяет изменения на подчиненные серверы NIS/NIS+. Установка демона ssod. При использовании безопасной синхронизации паролей на каждом компьютере UNIX-секции должен быть установлен демон ssod. поставляемый с Services for UNIX. Небезопасная синхронизация паролей. При использовании небезопасной синхронизации паролей нужно корректно настроить файлы /etc/hosts и .rhosts на всех компьютерах в UNIX-секции, чтобы rlogin могла использовать команду passwd для входа в корень. Кроме того, нужно модифицировать файл /etc/default/login на рабочих станциях Sun Sparcstatkm и отключить вход в корень только через консоль.
Защита Компонент Password Synchronization в Services for UNIX посылает обновления паролей по сети открытым текстом или в зашифрованном виде. Первый способ (небезопасный) допустим, только если Вас не волнуют проблемы защиты. При втором способе используется алгоритм шифрования Triple OES (3DES), кратко описываемый в разделе «Triple DES» далее в этой главе. Если выбран небезопасный способ, смена пароля на UNIX-компьютере осуществляется командой rlogin. Компонент Password Synchronization использует логин с привилегиями корня для доступа к passwd и обновления пароля пользователя в UNIX. Файл .rhosts должен содержать имена нужных компьютеров, полные хостимена (не псевдонимы) компьютеров Windows NT и имя корня. В файле /etc/hosts должны быть требуемые сопоставления имен хостов с IP-адресами. Если Вы используете Sun Sparcstation, модифицируйте файл /etc/default/login и отключите вход в корень только через консольПримечание NIS и NIS+ не поддерживаются rlogin. Если в Вашей сети используется NTS или NIS+, выбирайте безопасный способ синхронизации паролей.
ГЛАВА 11
Services for UNIX
475
Если выбран безопасный способ синхронизации паролей, системный администратор UNIX должен скопировать на UNIX-компьютер программу ssod, поставляемую на компакт-диске Services for UNIX. Ее нужно установить как демон и настроить на запуск при загрузке компьютера. Этот демон открывает соответствующий порт и ждет уведомления о пароле от компьютера с Windows NT. Системный администратор должен выбрать шифровальный ключ и добавить его в файл ssod.config на UNIX-компьютере, а также на компьютер с Windows NT, используя Windows NTto-UNIX Password Synchronization Service Administrator. Services for UNIX включает версии двоичных файлов ssod для Solaris, Digital UNIX и HP-UX. Каждый хост в UNIX-секции должен использовать один и тот же шифровальный ключ. К этому ключу предъявляются следующие требования. • Его длина должна быть минимум 12 символов. •
Он должен содержать символы хотя бы из следующих трех групп: • прописные английские буквы; • строчные английские буквы; •
арабские цифры;
• специальные символы ( ' ' ! @ # $ % л & * _ - + = \ { } [ ] : ;
Примеры файлов В этом разделе приведено несколько примеров UNIX-файлов, используемых компонентом Password Synchronization. Файл /etc/passwd содержит информацию о пользователях. Каждая запись состоит из семи полей, разделяемых двоеточиями: login-id: password: DID :GID: use [".information: home-directory: shell Б поле login-id хранится имя, которое данный пользователь вводит при регистрации. Поле password содержит либо зашифрованный пароль, либо специальный маркер, если пароль находится в файле /etc/shadow (доступном только корневым пользователям). Поле UID — это числовой идентификатор пользователя, а поле GID — числовой идентификатор группы, к которой относится данный пользователь. В поле user_information записывается дополнительная информация о пользователе (если она нужна). Поле home-directory сообщает абсолютный путь к основному каталогу пользователя, а поле shell указывает программу, запускаемую при входе пользователя в систему. При необходимости в этом поле можно определить специфическую оболочку (например, /usr/bin/ksh запускает оболочку Korn, /usr/bin/sh — оболочку Bourne). Файл /etc/shadow хранит информацию о пароле пользователя и доступен только суперпользователю. Его записи состоят из девяти полей, разделяемых двоеточиями: login-id:password:lastchg:min:max:warn;inactive:expire:flag Поле login-id содержит имя, которое данный пользователь вводит при регистрации, поле password — зашифрованный пароль- иоле lastchg — число дней, прошедших с 1 января 1970 года до даты последней смены пароля, поле min — минимальный интервал (в сутках), через который нужно менять пароль, поле max — максимальный срок действия пароля (в сутках), поле warn — интервал (в сутках), в течение которого пользователь получает предупреждения об истечении срока действия пароля,
476
ЧАСТЬ 3
Взаимодействие с другими системами
поле inactive — срок (в сутках), в течение которого пользователь может не входить в систему. Наконец, поле expire указывает последний день, в который можно воспользоваться данным логином, а поле flag в настоящее время не применяется. Файл /etc/group хранит информацию о группах. Каждая запись состоит из четырех полей, разделяемых двоеточиями: group-name;password:group-ID:list-of-names
Поле group-name сообщает имя группы. Поле password может содержать необязательный зашифрованный пароль. Поле group-ID содержит числовой идентификатор группы, а поле list-of-nam.es — имена всех членов группы (через запятую). Файл /etc/hosts перечисляет все хосты в сети, включая локальный. Он увязывает имена хостов с IP-адресами. Каждая строка файла, описывающая один хост, состоит из трех полей, разделяемых пробелами: IP-адрес имя_хоста псевдоним
Файл /etc/hosts.equiv перечисляет хосты и пользователей, которые могут удаленно выполнять команды на данном хосте без пароля (доверительные отношения). Файл .rhosts определяет удаленных пользователей, имеющих право использовать локальную учетную запись без пароля. Этот файл является скрытым; он находится в основном каталоге пользователя и должен принадлежать этому пользователю, Файлы /etc/hosts.equiv и .rhosts имеют одинаковый формат: имя^хоста имя_пользователя
Оба файла позволяют указывать знак «плюс» (+•) в качестве символа подстановки. Знак «плюс» после имени хоста или пользователя означает установление доверительных отношений со всеми пользователями конкретного хоста или всех хостов, на которых имеется учетная запись данного пользователя. Если знак «плюс» помещается в самое начало файла, доверительные отношения устанавливаются со всеми пользователями на всех хостах в сети. С этой возможностью следует быть крайне осторожным. Хосты или пользователи, чьи имена не указаны в файле, не входят в число доверяемых.
Triple DES Triple DES, используемый компонентом Password Synchronization, представляет собой разновидность DES (Data Encryption Standard). DES — метод шифрования, при котором отправитель и получатель шифруют и расшифровывают данные, применяя общий секретный ключ. DES работает с 56-битными ключами. Triple DES шифрует данные по алгоритму DES три раза подряд.
Утилиты UNIX и оболочка Когп С помощью утилит UNIX и оболочки Когп можно автоматизировать процессы на платформах Windows NT и UNIX.
Оболочки UNIX Services for UNIX версии 1.0 включает оболочку Когп. Она представляет собой интерпретатор команд, действующий как интерфейс операционной системы UNIX. Оболочка принимает команды, вызывает соответствующие программы и возвращает результаты на стандартное устройство вывода. Многие оболочки также предос-
ГЛАВА 11
Services for UNIX
477
гавляют высокоуровневый язык программирования, позволяющий решать сложные задачи за счет использования базовых утилит и функций операционной системы. Оболочка Когп, разработанная Дэвидом Корном (David Korn) из компании AT&T, сочетает в себе лучшие качества оболочек С и Bourne. Оболочка Bourne, разработанная Стивеном Борном (Steven Bourne) из компании AT&T, была первой оболочкой UNIX. Эта оболочка предоставляет мощный язык программирования, а оболочка С — целый ряд возможностей, недоступных через оболочку Bourne, например присвоение командам псевдонимов, механизм хронологии введенных команд и управление заданиями. Функциональность различных оболочек перечислена в таблице 11-7. Таблица 11-7. Функциональность различных оболочек Bourne Псевдонимы команд Хронология команд Редактирование командной строки Управление заданиями Поддержка ныполнения сценариев
С
Когп
X \
X
\
ч \ X
X
X
\
Для операционной системы UNIX созданы и другие оболочки. Б частности, Bash (оболочка Bourne Again) является расширением оболочки Bourne, которое сочетает в себе функциональность оболочек Когп и С и обычно используется для Linux. Или, например, Tcsh — расширенная версия оболочки С, которая поддерживаем автоматическую подстановку команд по первым буквам их имен, редактор командной строки и более совершенные средства работы с хронологией команд.
Использование оболочки Когп Реализация оболочки Когп, поставляемая с Services for UNIX, отличается от стандартной UNIX-оболочки Когп: • записи в переменной PATH отделяются не двоеточиями, а точками с запятой; • текущий каталог в PATH обозначается как ;; или ;.; вместо точки (.); •
стартовый файл называется profile.ksh, а не .profile;
•
стартовым файлом для общесистемных переменных окружения является /etc/ profile.ksh, а не /etc/profile;
• файл хронологии команд, вводившихся пользователем, называется sh_histo, л не sh_hi story; • задания можно выполнять в фоновом режиме, для чего в командной строке указывается знак &. Если системный администратор указывает оболочку Когп как стандартную для Нас на сервере Telnet, то при обращении к серверу Services for UNIX через Telnet Вы будете регистрироваться именно в этой оболочке. Если Вы хотите работать с оболочкой Когп без регистрации в пей, используйте команду sh (в стандартной оболочке Korn — ksh). Переменные окружения Переменная состоит из имени и присвоенного ей значения. Вы можете определять переменные и использовать их в сценариях оболочки. Прочие переменные, назына-
478
ЧАСТЬ 3
Взаимодействие с другими системами
емые переменными оболочки, устанавливаются самой оболочкой. Имя переменной может состоять из букв, цифр (цифра не должна быть первым символом) и знака подчеркивания, Значение присваивается знаком равенства без пробелов. Определив переменную, Вы должны исполкюватъ команду export, чтобы значение этой переменной стало доступным другим процессам. После входа в оболочку Когп запускается файл profile.ksb. Он устанавливает пользовательские переменные окружения и режимы терминала. (Системный администратор может с помощью файла /etc/profile.ksh устанавливать общесистемные переменные для всех учетных записей пользователей в системе.) В таблице 11-8 перечислены многие переменные оболочки Когп из Services for UNIX. Полный список переменных этой оболочки см. в справочной системе Services for UNIX в разделе, описывающем команду sh. Таблица 11-8. Переменные окружения, используемые оболочкой Когп Имя переменной
Описание
Разворачивается в аргумент предыдущей выполненной команды Путь поиска, используемый командой cd Определяет ширину области нывода для программ, считывающих значение этой переменной, например для vi EDITOR Определяет редактор, вызываемый системой по умолчанию, в отсутствие других указаний ENV Если ENV установлена, то при загрузке оболочки сначала запускается указанный файл ERRNO Значение, которое устанавливается последней подпрограммой, закончившейся неудачей FIGNORE Содержит шаблон, определяющий, какие файлы следует игнорировать при подстановке файлов (file expansion) FCEDIT Редактор для команды fc HISTFILE Абсолютный путь к файлу (по умолчанию — к sh_histo), содержащему хронологию команд HISTSIZE Количество команд в файле хронологии НОМЕ Абсолютный путь к Вашему основному каталогу, который становится текущим после Вашей регистрации (входа в систему) IFS Символы, используемые как разделители внутренних полей LTNENO Номер строки из стандартного ввода, обрабатываемой в данный момент сценарием оболочки (shell script) LINES Количество строк вывода, используемых оператором select при распечатке своего меню MAIL Абсолютный путь к файлу, в котором хранится Ваша почта MAILCHECK Интервал (в секундах), через который оболочка проверяет поступление новой почты MAILPATH Файлы почтового ящика, в который посылается уведомление о появлении новой почты OLDPWD Путь к предыдущему рабочему каталогу PATH Абсолютные пути к каталогам, в которых оболочка ищет исполняемые файлы РРШ Идентификатор процесса, создавшего процесс оболочки PS1 Приглашение, выводимое оболочкой; в оболочке Когп приглашение но умолчанию обозначается знаком $ CDPATH COLUMNS
ГЛАВА 11 Таблица 11-8.
Services for UNIX
479
(продолжение)
Имя переменной
Описание
PS2 PWD RANDOM REPLY SHELL
Приглашение вторичной оболочки Путь к текущему рабочему каталогу Генерирует случайное число Содержит пользовательский ввод, полученный от оператора select Абсолютный путь к текущей оболочке; используется командами для обращения к оболочке Период простоя (в секундах), по истечении которого оболочка завершается Указывает редактор по умолчанию, переопределяя переменную EDITOR
TMOUT VISUAL Метасимволы
Оболочка Когп интерпретирует некоторые символы особым образом. Когда в выражении присутствует метасимвол, он воспринимается так, как показано в таблице 11-9. Таблица 11-9. Метасимволы оболочки Когп Символ
Описание
\
Escape-символ. Превращает следующий за ним символ в обычный (если он имеет особый смысл) Символ подстановки произвольного числа символов Символ подстановки одного символа Шаблон подстановки (знаки указываются в квадратных скобках) Перенаправляет стандартный ввод па заданный файл Перенаправляет стандартный вывод в заданный файл Записывает стандартный вывод в конец указанного файла Символ конвейеризации; переключает стандартный вывод одной ком шды на стандартный ввод другой Этот знак, добавленный в командную строку, заставляет соответствую>щий процесс работать в фоновом режиме Представляет путь к основному каталогу пользователя Текущий каталог Родительский каталог текущего каталога Представляет первые девять аргументов какой-либо команды Корневой каталог Задает строку; допускается указание переменной Задает строку; допускается указание переменной Если командная строка заключена в эти символы, оболочка выполняет команду и вместо строки использует вывод Позволяет группировать команды Разделяет команды в командной строке Начинает выполнение команды
V [ ] < > » | &
S1-S9 /
( ) ; newline (Enter)
Команды оболочки Когда Вы вводите команду в строке приглашения, оболочка анализирует эту команду, подставляет нужные значения переменных и псевдонимов, а затем выполняет ее.
echo environ evaJ exec exit
J~ff\
"•^'«paaiZ; ^Згалог "-"""«и
"''' ^шолненм
^H£=H=^:=:::,= -
480
ЧАСТЬ 3
Взаимодействие с другими системами
Базовый синтаксис команд выглядит так: имя_команды аргумент! аргумент?. >имя_файла Команда может принимать параметры, модифицирующие ее действие. Например, Is перечисляет содержимое каталога, но не включает скрытые файлы (имена которых начинаются с точки). Увидеть и скрытые файлы позволяет команда Is -a. Оболочка обрабатывает команду после нажатия клавиши Enter. Команды можно вводить в одну строку, разделяя их точками с занятой; они тоже обрабатываются только после нажатия клавиши Enter. Выполняя команду, оболочка запускает процесс. Каждому процессу присваивается свой идентификатор (process ID, PID), используемый для доступа к процессу. Процессы можно выполнять как фоновые или активные, а также приостанавливать или отменять. Родительские процессы порождают дочерние, которым также присваиваются собственные PID. Команда принимает стандартный ввод с терминала и посылает стандартный вывод и стандартную ошибку на терминал. Стандартный ввод можно перенаправить на файл: имя_комаиды < имя _файла Стандартный вывод также можно перенаправить на файл: имя_команды > имя_файла Для записи вывода в конец существующего файла:
имя_команды » имя_файла Кроме того, в файл можно перенаправить и вывод стандартной ошибки: гшя_команды 1> имя_файла1 2>имя_файла2 Стандартный вывод направляется в первый файл, а стандартная ошибка — во второй. Стандартный вывод одной команды можно подключить к стандартному вводу другой с помощью символа конвейеризации: имя_коман()ы \ имя_команды >имя_файла Оболочка Когп из Services for UNIX является программируемой и поддерживает команды, обеспечивающие структуризацию (таблица 11-10). Полный список таких команд см. в справочной системе Services for UNIX (раздел, описывающий команду sh). Таблица 11-10. Команды оболочки Когп для программирования Команда case for if select until while
Описание Выполняет команды в зависимости от значения переменной Выполняет список команд Задает условие в сценарии Записывает указанные слова в стандартную ошибку Выполняет список команд до тс.ч пор, пока не будет возвращено нулевое значение Выполняет список команд, пока определенное условие истинно
В оболочке Когп из Services for UNIX также имеются встроенные команды (таблица 11-11). выполняемые собственным процессом оболочки. Более подробное описание этих команд см. в справочной системе Services for UNIX.
• o9
,,,\ нгевд"*-*"
4ftG'
—
„есте с параме^^созда-
ма Что6ы
псе»*»
дони-
псев
предопределен^
ГЛАВА 11
Services for UNIX
483
Таблица 11-12. Знаки арифметических и логических операций Знак операции
Описание
+
Плюс Минус Умножение Целочисленное деление
/
%
Остаток
« » & &&
Побитовый сдвиг влево Побитовый сдвиг вправо Побитовая операция and Логическая операция and Побитовая операция or
!,
Логическая операция ог Побитовая операция хог Логическая операция not Побитовая операция not
'. < > <s
Меньше Больше Меньше или равно
>=
Больше или равно
1=
Не равно Равно
Сценарии оболочки Сценарий оболочки (shell script) — это файл, который содержит серию команд для выполнения определенной задачи. Вы можете запускать сценарий из командной строки, если оболочка Когп загружена и если у Вас есть право на запуск этого сценария. Если оболочка Когп не загружена, сценарий можно запустить командой: sh имя_файла Windows NT не поддерживает запуск сценария из командной строки только по имени его файла, но в UNIX это возможно — при условии, что путь к исполняемому файлу оболочки и имя этого файла указаны в первой строке самого сценария, например: #[/bin/sh Расширения имен файлов должны быть сопоставлены с какими-либо программами, В частности, .sh или .ksh можно связать с оболочкой Когп. Управление заданиями Поддержка управления заданиями позволяет выполнять какую-либо команду в фоновом или активном режиме, а также временно приостанавливать ее работу. Кроме того, Вы можете просматривать список команд, выполняемых в данный момент. Когда Вы вводите команду (не встроенную в оболочку), оболочка порождает новый процесс, в котором эта команда и выполняется. Ядро включает этот процесс в число планируемых и присваивает ему идентификатор PID. Оболочка отслеживает данный процесс и назначает ему номер задания.
484
ЧАСТЬ 3 Взаи v од(!й(л • не с другими системам 1
Интерактивные или Smpo выполняемые i ронеа-\-л могут работать как активные (foreground). Остадьнь'..;' пргдсссы обычно sn.iчсишлются как фоновые — особенно те команды, обработка к:по|>ьтх занимает л/ и т г п j j i o e время, например сортировка большого числа элешчп".>:. Т>ы можете перс :одгл. процесс в активный или фоновый режим, а также г-ремнп-.о приостанавлн L;;iTfc или принудительно завершать его. Команды, предназначен к ы е ;;ля управлении гаданиями и поддерживаемые Services for UNIX, перечислен].! в таблице 11-13. Таблица 11-13. Компг;,[;ы для управления .;ацалш[«н Команда jobs -1
П е р с - I I ел лет текущие :1ада • i-is. К;«Е дому заданию присваивается свой I I D V K . Параметр -1 заставляет ; а ч п у ю команду показывать PID.
команда &
В лп.пши:" команду в фоно:он режиме, Например, scirt гмп'_ фаша новый_(pai>.r, &-.
kill номер_задания
[ I p K - i v . n i i c j i h i u ) завершает . : лл,;1 H I L , указанное но номеру. Номер задан ш по (а:п.шастся, когда оно 1\л гусиаотся с указанием метасимвола & i n n |;с>мы1доп jobs.
Утилиты UNIX В таблице 11-14 пр.'дс.мч.пеньт утилиты 1 . M I X , доступные как часть Services for UNIX. Более подроо-\ 1: информацию об .г^их утилитах см. в справочной системе Services for UNIX. Таблица 11-14. Утилиг ; 1 UNIX UNIX-команда sh basename
cat chmod
Описание ii"i' о()олочку Korn Удал я:" г и т .: оставляя тольк.: .[\\'л ф.:йла; удаляет любые префиксы, зак а н ч н з ш г . п и ;ся символом «/», м OT(KI >ажает результат на стандартном устр nic i i ! . ; ш.шода Вып ;JH;I "• ьонкатенацкю и nr:«n iin;. ;т файл
chown
Иам?1гг:' и.ш назначает pa;ipci ICHIIH на доступ к файлу Поавол;н г с!.'енить владельцу файла
ср
Коп \\>\".1 :р;. тлы
dirname
Возт^аидет ьссь путь, кроме ш.ч •! :,'.:з1'го уровня (имени файла) Реку - ж п п ш просматривает И!фа;>ш-: катало]-ов в поисках файлов, подходящ. л :и.цампому булеву в ы р а ж е н и и ) Ип ],(••: ii ^iiiii.ie пли в файлах .ш'р^ньш шаблон и выводит всю строку, содеркЕшун: .мот шаблон
find
grep head
Коп ipycr первые п строк ука;шш )го текстового файла на стандартное y C T f o k i T i - . i D пывода
In
Создг.е- лгсггкую связь с ф а Я / о м ; ш н ы й файл сопоставляется с целевым
Is mkdir
Перечне. iii
тоге mv rm
Соз Uu?" 1 уимюванный катало: с f)a: : .]iiH спиямн на чтение, запись и выпо;[ ic: . с д.1л пользователей п г е ч т ^ л о в Фильтг! позволяющий носледо1,а"е;и:НО (по одной экранной странице) выв:ди" , содержимое текстовою фаЕ.ла на термина.'! г Перел(:Ч|.:е [ файл в укаланн .• - -.вта/, >i Удапл(!1 фаИл из каталога
ГЛАВА 11 Таблица 11-14. UNIX-команда rmdir sed sort tail tee touch uniq we vi perl
Services for UNIX
485
('продолжение) Описание
Удаляет каталог Потоковый редактор (колирует указанный файл на стандартное устройство вывода и редактирует его и соответствии с командами сценария) Сортирует файлы и отображает результат на стандартном устройстве вывода Копирует файл на стандартное устройство вывода, начиная с указанного места Переписывает стандартный ввод в стандартный вывод и делает копии в указанном файле Обновляет время последнего обращения к файлу или время его последней модификации Сообщает о повторяющихся строках в файле Сообщает количество строк, слов или символов в файле Редактор, основанный на ех Интерпретируемый язык, используемый для сканирования текстовых файлов, выборки информации из них и се вывода на экран
Использование vi Программа vi — это интерактивный текстовый редактор для создания и изменения файлов в кодировке ASCII. Этот редактор может работать в командном режиме или в режиме ввода. В первом режиме Вы вводите команды для выполнения таких действий, как удаление текста или перемещение курсора в другую позицию. В режиме ввода Вы можете набирать текст и редактировать его. Для перехода в этот режим нужно ввести соответствующую команду редактора vi, а для выхода — нажать клавишу Esc. В данном разделе даются базовые сведения по использованию редактора vi. Как только Вы поймете принципы его работы, Вы сможете самостоятельно изучить всю его функциональность. Более подробную информацию см. в различных онлайновых источниках, а также в справочной системе Services for UNIX (в разделе, списывающем команду vi). Чтобы отредактировать файл с помощью vi, введите в системной командной строке: vi имя_файла и нажмите клавишу Enter. Если файл уже существует, его содержимое появится на экране. Если такого файла нет, vi создаст его. Примечание Редактор vi поддерживает восстановление файлов. Если система записывает в буфер копию последней сохраненной версии Вашего файла, Вы можете воспользоваться этой копией, набрав команду vi -r имя_файла и нажав клавишу Enter. После загрузки файла в редактор Вы видите на экране текст из этого файла (если он есть) и мигающий курсор в левом верхнем углу. Напротив пустых строк (е--ли таковые есть) в столбце рядом с левым полем текста показываются тильды. В гюс-
486
ЧАСТЬ 3
Взаимодействие с другими системами
ледней строке экрана сообщается имя данного файла. (В нижней части экрана также отображаются все вводимые Вами команды, начинающиеся с символов «/V, «?», «!» и «:».) Чтобы начать ввод текста, нажмите клавишу i (режим вставки текста). Набираемый текст появляется, начиная с позиции курсора. Закончив ввод текста, нажмите клавишу Esc. Для сохранения файла и выхода из vi введите:
:wq и нажмите Enter. Для выхода в командную оболочку редактора используйте двоеточие — это позволит вводить команды в нижней части экрана. Для записи файла на диск нажмите клавишу w. Чтобы выйти из редактора vi, нажмите клавишу q. Команды для запуска редактора и выхода из него перечислены в таблице 11-15. Таблица 11-15. Запуск и закрытие vi Команда
Описание
vi имя_файла
Позволяет редактировать указанный файл (или создать его. если такого файла еще нет) vi -г имя_файла Позволяет восстановить файл после краха системы и отредактировать его :q Позволяет выйти из vi, если в файл не внесено никаких изменений :ql Позволяет выйти из vi без сохранения изменений :wq Позволяет записать (сохранить изменения) и выйти из vi Создав файл с помощью vi, Вы можете перемещаться по нему в пределах его длины. Команды для позиционирования курсора в файле показаны в таблице 11-16. Таблица 11-16. Перемещение курсора в командном режиме Команда
Описание
Пробел Backspace
Вперед на один символ Назад на один символ На один символ вправо На один символ влево На одну строку вниз На одну строку вверх Прокрутка половины экрана вниз Прокрутка половины экрана вверх Прокрутка экрана вниз Прокрутка экрана вверх Перемещение курсора на строку п Перемещение курсора в конец файла
h j k Ctrl+d Ctrl-ьи Ctrl+f Ctrl+b nG G
Для вставки и редактирования текста предусмотрено множество команд (таблицы 11-17 и 11-18).
ГЛАВА 11
Services for UNIX
487
Таблица li-17. Режим ввода Команда
Описание
а А i
Вставка текста за курсором Вставка текста в конец текущей строки Вставка текста перед курсором Вставка текста перед текущей строкой Создание строки в тексте под строкой, в которой находится курсор Создание строки в тексте над строкой, в которой находится курсор
о О
Table 11-18. Редактирование текста Команда г R ее cw > S
Описание Замена текущего символа новым и возврат в командный режим Замена текста, начиная с текущего символа Редактирование всей строки Редактирование текущего слова, начиная с позиции курсора Замена символа в позиции курсора новым текстом (который Вы должны набрать) Замена всей текущей строки новым текстом (который Вы должны набрать)
Способы удаления текста в vi показаны в таблице 11-19, Таблица 11-19. Удаление текста Команда
Описание
D х dd
Удаление текста от текущей позиции курсора до конца строки Удаление текущего символа Удаление текущей строки
Вы можете копировать (в терминологии UNIX — yank) и вставлять (в терминологии UNIX — put) текст внутри файла и между файлами. Команды первого иида позволяют копировать указанный текст и помещать его в буфер, а команды второго вида — копировать текст из буфера в указанное место файла (таблица 11-20). При этом можно пользоваться буферами с именами и с номерами, но их рассмотрение выходит за рамки данной книги. Таблица 11-20. Команды копирования и вставки Команда
Описание
уу или Y 5уу р Р
Копирует текущую строку Копирует 5 строк Вставляет текст из буфера в строку, которая находится за текущей Вставляет текст из буфера в строку, которая находится перед текущей
Пытаясь найти какую-либо строку символов в файле, помните, что средства поиска чувствительны к регистру букв. Если искомая строка не найдена, vi выводит в нижней части экрана соответствующее сообщение. Команды поиска перечислены в таблице 11-21.
488
ЧАСТЬ 3
Взаимодействие с другими системами
Таблица 11-21. Команды поиска Команда
Описание
Перемещает курсор к первому символу в следующем вхождении искомой строки / Повторяет предыдущую операцию поиска в направлении вперед Ч искомая _строка Перемещает курсор к первому символу в предыдущем вхождении искомой строки '.-' Повторяет предыдущую операцию поиска в направлении назад /искомая^строка
Из командной строки можно ьызвать мопшый инструмент глобальной замены по шаблону. Эта команда имеет следующий синтаксис: : s/искомая ^строка/заменяющая _cmpoKa/g Здесь g указывает на необходимость глобальной замены всех вхождений искомой строки. Без метасимвола g заменяется только первое вхождение в каждой строке текста. Если Вы хотите контролировать каждую замену, команду нужно немного модифицировать: :s/'искомая _строка/'заменяющая _строка/£с В таблице 11-22 перечислены некоторые другие инструменты, доступные в vi. Таблица 11-22. Другие полезные команды Команда :sh :1команда и U хр
Описание Выход в оболочку для запуска команды Запуск одной команды Отмена последнего изменения Восстановление последней удаленной строки Переключение регистра чекушей буквы Перестановка текущего и следующего символов Повторение последнего изменения
Поддержка сценариев Services for UNIX включает два инструмента, позволяющие использовать сценарии: Perl и sh. Perl — это язык сценариев («скриптов»), полезный для автоматизации таких задач, как обработка текстовых файлов по шаблонам. Perl является программным обеспечением с открытым исходным кодом. (В Services for UNIX реализованы не все функции Per].) Оболочка Когп в Services for UNIX способна действовать как процессор сценариев оболочки. Подробнее о Perl и поддержке сценариев в оболочке Когп см. справочную систему Services for UNIX (разделы с описанием Perl и sh).
ГЛАВА 11
Services for UNIX
489
Дополнительные материалы Более подробную информацию о NFS, Windows NT и UNIX, а также о TCP/IP и OXC/NFS см. в следующих книгах: • Hal Stern «Managing NFS and NIS», 1991, Sebastopol: O'Reilly & Associates, Inc.; • G. Robert Williams and Ellen Beck Gardner «Windows NT & UNIX Administration, Coexistence, Integration, & Migration», 1998, Reading, Massachusetts: AddisonWesley Longman, Inc.; • Mark G. Sobell «UNIX System V: A Practical Guide Third Edition», 1995, Menlo Park, California: Addison-Wesley Publishing Company; • Michael Santifaller «TCP/IP and ONC/NFS Internetworking in a UNIX E n v i r o n ment Second Edition», 1994, Wokingham, England: Addison-Wesley Publishing Company.
ГЛАВА
12
Взаимодействие с NetWare
Windows 2000 предоставляет протоколы и службы, обеспечивающие интеграцию с сетями Novell NetWare. В этой главе рассматриваются IPX/SPX/NetBIOS-совместимый транспортный протокол NWLink и службы Windows 2000 — Gateway Service for NetWare (Служба шлюза для NetWare) и Client Service for NetWare (Служба клиента для сетей NetWare). Эти средства и другие программные продукты Microsoft позволяют поддерживать гетерогенную среду, состоящую из серверов Windows 2000 и NetWare. Кроме того, используя Directory Services Migration Tool for NetWare (DSMigrate), можно перейти с NetWare на Windows 2000. В этой главе Обзор 491 NWLink 492 Службы шлюза и клиента для NetWare 503 Администрирование NetWare через Windows 2000 Защита Windows 2000 и NetWare 519 Доступ к томам NetWare 522 Сценарии регистрации 524 Выявление и устранение проблем 525
516
См. также • О сервисах IPX-маршрутизации в Windows 2000 — главу 5 «IPX-маршрутизация» в этой книге. • О мониторинге сети — книгу «Сопровождение сервера» из серии «Ресурсы Microsoft Windows 2000 Servers-.
ГЛАВА 12
Взаимодействие с NetWare
491
Обзор Microsoft предоставляет несколько сервисов для интеграции компьютеров под управлением Windows 2000 с компьютерами под управлением Novell Directory Services (NDS) версий 4.x, 5jc и 8л% а также с серверами NetWare 2.x и 3.x. Некоторые из этих сервисов включены в Windows 2000 Server или Windows 2000 Professional, остальные поставляются как отдельные программные продукты Microsoft. IPX/SPX/NetBIOS-совместимый транспортный протокол NWLink. NWLink это реализация протокола IPX/SPX (Internetwork Packet Exchange/Sequenced Packet Exchange) в Windows 2000, позволяющая соединять компьютеры Windows 2000 с компьютерами NetWare. NWLink также поддерживает функциональность NetBIOS и протокола RIP (Routing Information Protocol). NWLink может функционировать либо как протокол, соединяющий компьютеры Windows 2000, Windows NT, Windows for Workgroups 3.11, Windows 95 и Windows 98, либо как протокол, объединяющий компьютеры под управлением MS-E)OS (при использовании в комбинации с редиректором). Кроме того, NWLink выступает в роли альтернативного транспортного протокола для серверов с Microsoft Exchange Server, Microsoft SQL Server™ и Microsoft SNA Server. NWLink имеется как в Windows 2000 Server, так и в Windows 2000 Professional, и устанавливается автоматически при установке Client Service for NetWare (Служба клиента для сетей NetWare) или Gateway Service for NetWare (Служба шлюза для NetWare). Обе эти службы полагаются на протокол NWLink. Gateway Service for NetWare (Служба шлюза для NetWare). Эта служба совместно с NWLink обеспечивает доступ к службам NetWare и действует как шлюз, через который множество CIFS-клиентов обращаются к ресурсам NetWare. С помощью Gateway Service for NetWare Вы можете подключать компьютер Windows 2000 Server к серверам NetWare и NDS через IPX. (Если Вы хотите использовать «родной» IP для подключения к серверу NetWare, то должны перейти на какой-нибудь клиент NetWare.) После этого Windows-клиенты смогут обращаться через Gateway Service for NetWare к службам NetWare без NCP. Gateway Service for NetWare поддерживает прямой доступ к серверам NetWare с компьютера Windows 2000 Server (Client Service for NetWare позволяет делать то же самое с клиентского компьютера под управлением Windows 2000 Professional) и сценарии регистрации NetWare. Gateway Service for NetWare поставляется только с Windows 2000 Server и Windows 2000 Advanced Server. Client Service for NetWare (Служба клиента для сетей NetWare). Как и Gateway Service for NetWare, Client Service for NetWare обеспечивает доступ к службам NetWare с помощью NWLink. Однако Client Service for NetWare не выступает в роли шлюза, а напрямую соединяет клиентз со службами доступа к файлам и принтерам на серверах NetWare, работающими с регистрационной базой данных (bindery), и на серверах NetWare, работающих с NDS через IPX. Client Service for NetWare также поддерживает сценарии регистрации NetWare. Client Service for NetWare поставляется только с Windows 2000 Professional. Примечание Вместо Client Service for NetWare можно использовать Novell Client for Windows 2000.
492
ЧЛСТЬ 3 Взаимодействие с другими системами
Directory Services Migration Tool (DSMigrate). Этот инструмент позволяет переносить пользовательские учетные записи, группы, файлы и определения разрешений с серверов NetWare в службу каталогов Active Directory, а также ласт возможность смоделировать и протестировать весь процесс перехода на новую систему. Windows NT версии 4.0 поддерживает два дополнительных сервиса подключения к NetWare. На момент издания книги эти сервисы работали только на серверах Windows NT 4.0. Более свежую информацию см. но ссылке ResourceLink на http:// windows.microsott.com/windows2000/reskit/webresources. File and Print Services for NetWare (Служба доступа к файлам и принтерам NetWare). Эта служба позволяет компьютеру под управлением Windows 2000 эмулировать сервер NetWare, напрямую предоставляя доступ к своим файлам и принтерам IPX-клиентам, например компьютерам под управлением NetWare. Сервер Windows 2000 кажется таким клиентам обычным сервером NetWare. Никаких изменений в программном обеспечении клиентов NetWare не требуется. Directory Service Manager for NetWare. Этот компонент позволяет добавлять серверы NetWare в домены Windows NT и управлять единым набором пользовательских и групповых учетных записей, действительных на серверах Windows NT Server или NetWare. Для доступа к этим серверам пользователю нужна единственная учетная запись с одним паролем. (Эквивалентного программного обеспечения для Windows 2000 на момент издания л-той книги не было.)
NWLink IPX/SPX/NetBIOS-совместимый транспортный протокол NWLink — это 32-разрядная Microsoft-реализация IPX/SPX (Internetwork Packet Exchange/Sequenced Packet Exchange). Вы должны использовать этот протокол, если хотите подключаться к серверам NetWare с помощью Gateway Service for NetWare или Client Service for NetWare. NWLink предоставляет только транспортный протокол для поддержки взаимодействия с файл-серверами NetWare. Чтобы войти в сеть NetWare с компьютера под управлением Windows 2000 Professional. Вы должны использовать Client Service for NetWare или один из клиентов NetWare, например Novell Client for Windows 2000. В качестве альтернативы можно установить Gateway Service for NetWare па компьютере с Windows 2000 Server. Детальное описание Client Service for NetWare и Gateway Service for NetWare будет дано несколько позже. Поскольку NWLink соответствует спецификации NDIS, компьютер с Windows 2000 может одновременно работать с прочими стеками протоколов, например TCP/IP, который обеспечивает взаимодействие с другими TCP/IP-компьютерами под управлением Windows. NWLink способен привязываться к нескольким сетевым адаптерам и позволяет использовать несколько типов кадров. Примечание В качестве «родного» протокола NetWare 5.0, как и Windows 2000, использует TCP/IP, и по умолчанию IPX не устанавливается. Однако ни Client Service for NetWare, ни Gateway Service for NetWare не поддерживает подключение к ресурсам NetWare no IP. Поэтому, если Вы используете NWLink для подключения к серверам NetWare 5.0, включите поддержку IPX на серверах NetWare 5.O.
ГЛАВА 12
Взаимодействие с NetWare
493
NWLink поддерживает два API: NetBIOS и Windows Sockets. Эти API обеспечивают коммуникационное взаимодействие компьютеров с Windows 2QOO как между собой, так и с серверами NetWare. NWLink с успехом заменяет IPX/SPX. Например, в тех случаях, когда для подключения к прокси-серверам или серверам под управлением Microsoft Systems Management Server (SMS), SNA Server, SQL Server или Exchange Server нужен IPX/SPXсовместимый протокол, Вы можете использовать NWLink. В небольших сетях без маршрутизации NWLink практически не требует начальной настройки клиентских конфигураций.
Архитектура NWLink NWLink предоставляет большой набор протоколов транспортного и сетевого у|хшня, обеспечивающих интеграцию со средой NetWare. Эти протоколы икомпоненты перечислены в таблице 12-1. Таблица 12-1. Протоколы NWLink Протокол
Описание
Драйвер
IPX
Сервисы передачи дейтаграмм, не требующие логических соединений Сервисы передачи данных, ориентированные на логические соединения Сервисы обнаружения маршрутов и маршрутизаторов Собирает и распространяет данные об именах и адресах служб Обеспечивает совместимость с NetBIOS for IPX/SPX, выполняемой на серверах NetWare Обеспечивает поддержку IPX -маршрутизаторов
Nwlnkipx.sys
SPXnSPXII RIP SAP
NetBIOS Компонент пересылки •графика (forwarder)
Nwlnkspx sys Nwlnkipx.sys Nwlnkipx.sys Nwlnknb.sys Nwlnkfwd.sys
NWLink в архитектуре Windows 2000 показан на рис. 12-1.
NWLink -
SAP
RIP
SPX/SPXII Nwlinkspx.sys
Ipxsap.cfll
Nwlinkipx.sys
1 IPX Nw[Enkipx.sys
NDIS-интерфвйс
Драйвер NEHS-адаптера
а-вшода Рис. 12-1. NWLink в архитектуре Windows 2000
NetBIOS Nwlinknb.sys
Компонент пересыпки трафяка KwlrnkteUys
494
ЧАСТЬ 3 Взаимодействие с другими системами
IPX
IPX — сетевой протокол, который не требует логических соединений и предоставляет сервисы передачи дейтаграмм. Кроме того, он управляет адресацией и маршрутизацией пакетов данных внутри сетевых сегментов и между ними. Устанавливать сеанс всякий раз, когда передаются пакеты, не нужно — они просто посылаются по несущей среде. Поскольку IPX не ориентирован на логические соединения, он не предусматривает управления потоком данных и подтверждений о приеме пакетов. В связи с этим нет никаких гарантий, что пакеты попадут к адресату и что они будут поступать в корректной последовательности. Однако в локальных сетях такие ошибки возникают сравнительно редко, и IPX весьма эффективен в доставке небольших групп пакетов в этих сетях. NWLink позволяет работать с Windows Sockets и вызывать удаленные процедуры через Windows Sockets. IPX поддерживает идентификаторы сокетов для приложений Windows Sockets и использование NetBIOS, именованных каналов (Named Pipes), почтового ящика (Mailslot), NetDDE (Network Dynamic Data Exchange), RFC поверх NetBIOS и «RPC поверх именованных каналов» поверх NBIPX. NWLink поддерживает и другие приложения, использующие IPX, по механизму прямого хостинга (direct hosting). Прямой хостинг — это функциональность, позволяющая компьютерам взаимодействовать по IPX, минуя уровень NetBIOS. Прямой хостинг обычно уменьшает издержки и увеличивает пропускную способность, Структура IPX-пакетов IPX-пакет инкапсулируется в поле данных IEEE-кадра и размешается непосредственно за заголовками несущего и канального уровней (например, Ethernet, Token Ring или FDDI). Первые 30 байтов IPX-пакета содержат заголовочную информацию (рис. 12-2). Остальные байты представляют собственно данные. Эти данные могут быть запросом на какой-либо сервис, ответом от сервера, текстовой информацией и т. д. Базовая структура IPX-заголовка показана на рис. 12-2. Контрольная сумма Длина
Контроль транспорта Тип пакета
Сеть назначения Узел назначения Сокет назначения
Сеть источника Узел источника Сокет источника г-—1
= 1 байт
Рис. 12-2. IPX-заголовок
ГЛАВА 12
Взаимодействие с NetWare
495
Подробнее об IPX и структуре IPX-заголовка см. главу 5 «IPX-маршрутизация» в этой книге; подробнее о типах IEEE-кадров см. раздел «NWLink и поддерживаемые типы кадров» далее в этой главе. SPX
SPX — транспортный протокол, предоставляющий сервисы по IPX и требующий логических соединений. Хотя ориентация на логические соединения приводит к издержкам из-за необходимости установления сеанса, после его создания передача данных осуществляется эффективнее, чем в отсутствие логического соединения. Поэтому такой протокол лучше всего подходит для тех приложений, которые требуют наличия постоянного соединения. SPX обеспечивает надежную доставку любому адресату и проверяет ее успешность, запрашивая подтверждения от получателя по мере того, как он принимает данные. Если в течение определенного интервала ответ на запрос о подтверждении не поступает, SPX повторяет запрос (максимум 8 раз). Если и после этого ответа нет, SPX считает соединение разорванным.
SPXII SPXII совершеннее SPX в следующих отношениях. • SPXII допускает большее количество неподтвержденных пакетов. В SPX не может быть более одного неподтвержденного пакета единовременно, тогда как в SPXII все зависит от того, о чем договорились равноправные сетевые узлы в процессе установления соединения. • SPXII поддерживает пакеты большего размера. Максимальный размер пакетов в SPX — 576 байтов, а в SPXII он может достигать значений, предельных для используемой LAN-технологии. Например, в Ethernet-сети SPXII поддерживает пакеты размером 1518 байтов (предельное значение для этой LAN-технологии). • SPXII предоставляет механизм пакетной передачи (packet burst). Поддержка пакетного режима позволяет передавать данные сразу несколькими пакетами без подтверждения о приеме индивидуальных пакетов. За счет этого сетевой график в большинстве IPX-сетей уменьшается. Кроме того, механизм пакетной передачи обеспечивает учет потерянных пакетов и повторно посылает только эти пакеты. В Windows 2000 режим пакетной передачи включен по умолчанию. RIP
Сервисы обнаружения маршрутов и маршрутизаторов, используемые SPX uNBJPX, NWLink реализует на основе RIP поверх IPX (RIPX). Клиенты применяют RIP для определения пересылочного МАС-адреса для исходящего трафика. RIP выполняется на уровне, эквивалентном прикладному уровню модели OSL Код RIP содержится в файле Nwlnkipx.sys. NWLink включает протокол RIP для Windows-клиентов и для компьютеров под управлением Windows 2000 Server без службы маршрутизации и удаленного доступа. Эти компьютеры не пересылают пакеты (т. е. не являются маршрутизатораVIH), но определяют, куда передавать пакеты, на основе таблицы RIP. Клиенты RIP ироде рабочих станций могут находить оптимальный маршрут к IPX-сети, широковещательно рассылая RIP-запрос GetLocalTarget. Каждый маршрутизатор, через который достижима требуемая сеть, сообщает в ответ на этот запрос сведения ос" од-
496
ЧАСТЬ 3
Взаимодействие с другими системами
ном маршруте. Получив RIP-ответы от локальных маршрутизаторов, рабочая станция выбирает наилучший маршрутизатор для пересылки IPX-пакета. RIPX-заголовок (рис. 12-3) помещается непосредственно за IPX-заголовком. Режим работы
До 50 маршрутов в одном
RIP-пакете
Номер сети Число переходов Число тактов
П=1 байт Рис. 12-3. RIPX-заголовок SAP
SAP (Service Advertising Protocol) — протокол, применяемый маршрутизаторами для распространения имен и адресов служб, работающих на IPX-узлах. SAP-клиенты используют широковещательные SAP-рассылки, только если запросы к регистрационной базе (bindery) и NDS заканчиваются неудачно. SAP-клиенты посылают сообщения следующих типов: •
GetNearestServer — широковещательный SAP-запрос имени и адреса ближайшего сервера указанного типа;
• общий SAP-запрос о службах — широковещательный запрос имен и адресов всех служб или служб только определенного типа. NWLink включает подмножество протокола SAP для Windows-клиентов и компьютеров под управлением Windows 2000 Server, на которых не установлен 1РХ-марщрутизатор. (Об IPX-маршрутизации см. главу 5 <<1РХ-мартпрутизация» в этой книге.) SAP-заголовок (рис. 12-4) следует за IPX-заголовком. Режим работы |_
До 7 служб В ОДНОМ
SAP-пакете
Тип службы Имя сервера Номер сети Номер узла Номер сокета Промежуточные сети
...48 байтов
= 1 байт Рис. 12-4. SAP-заголовок
ГЛАВА 12
Взаимодействие с NetWare
497
NetBIOS поверх IPX Чтобы приложения NetBIOS могли работать в межсетевой IPX-среде, компонент NWLink, NetBIOS поверх IPX (NWLnkNB.sys), предоставляет стандартные NetBIOS-сервисы: •
службу дейтаграмм (дейтаграмма — отдельный пакет, передаваемый без подтверждения о приеме). Один из примеров дейтаграмм — широковещательный пакет: • службу сеансов (сеансы — группы пакетов, передаваемые между двумя сторонами с подтверждениями о приеме); •
службу имен (поддерживает регистрацию, запрос и освобождение NetBIOSимен).
Структура пакетов NetBIOS поверх IPX показана на рис. 12-5. Сеть1 Сеть 2 СетьЗ
IPX WAN Broadcast
Сеть 4 Свтьб Сеть 6 Сеть? Сеть 8 Флаги типа имени Поток данных типа 2
NetBIOS
NetBIOS-имя
_| ...16 байтов
Т
= 1 байт
Рис. 12-5. Структура пакетов NetBIOS поверх IPX NWLnkNB отвечает за форматирование запросов уровня NetBIOS и их передачу NWLink для последующей отправки по сети. Для большего быстродействия в NWLnkNB введены: •
поддержка PiggyBackAck — подтверждение о приеме предыдущих кадров помещается в ответные кадры; • механизм «скользящего окна» (sliding window) — алгоритм динамического изменения окна (буфера), позволяющий в пакетном режиме регулировать число одновременно отправляемых кадров,
Компонент пересылки трафика Компонент пересылки трафика (forwarder) устанавливается вместе с NWLink, но используется, только если сервер Windows 2000 со службой маршрутизации и удаленного доступа выступает в роли IPX-маршрутизатора. Этот компонент работает в режиме ядра. При активизации программного обеспечения IPX-маршрутизатора данный компонент пересылает пакеты во взаимодействии с IPX Router Manager и компонентом 173ак 3343
498
ЧАСТЬ 3 Взаимодействие с другими системами
фильтрации. Подробнее о компоненте пересылки трафика см. главу 2 «Служба маршрутизации и удаленного доступа» в этой книге.
Настройка NWLink Если на компьютере установлено несколько протоколов, Windows 2000 пытается использовать протоколы в порядке их привязки. Например, если в первой позиции списка привязок находится TCP/IP, то в качестве транспорта для сетевых соединений сначала предпринимается попытка согласовать TCP/IP. Если пользователи обращаются к серверам в основном по TCP/IP, такой приоритет протоколов обеспечит максимальную общую производительность. Однако, когда пользователи создают соединения главным образом с серверами NetWare no IPX/SPX, рекомендуется так изменить приоритет протоколов в списке привязок, чтобы Windows 2000 начинала согласование не с TCP/IP, а с IPX/SPX. Об изменении приоритета протоколов см. в справочной системе Windows 2000.
Типы кадров и номера сетей Для взаимодействия с другими компьютерами в том же сегменте сети и для поддержки корректной маршрутизации пакетов в NWLink используются такие параметры, как номера сетей и типы кадров.
NWlink-функция Auto Detect Чтобы подключить компьютер под управлением Windows 2000 к компьютерам, работающим с IPX/SPX, на каждой машине нужно задать тип кадров и номер сети (подразумевается — внешней). Они должны быть идентичны используемым в сегменте локальной сети. Тип кадров и номер сети автоматически распознаются NWLink-функцией Auto Detect, и для настройки рекомендуется применять именно эту функцию. Функция Auto Detect работает следующим образом. 1. При инициализации протокол NWLink посылает RIPX-запрос, использующий определенный тип кадра. Этот запрос рассылается в локальной сети как широковещательный. Если ответ на него не приходит, NWLink посылает другие запросы (с другими типами кадров). 2. Получив ответ, NWLink подстраивается под тип кадра ответа, а номер IPX-сети устанавливает равным номеру сети источника в IPX-заголовке ШРХ-ответа. 3. Если у компьютера имеется несколько сетевых адаптеров, подключенных к разным сетям, например Token Ring, FDDI и Ethernet, функцию Auto Detect можно активизировать для каждого адаптера. 4. Если поступает несколько RIPX-отвстов с несколькими номерами сетей, Auto Detect выбирает наиболее вероятный номер сети по эвристическому алгоритму. 5. Если ни на один запрос ответа нет, NWLink выбирает тип кадров Ethernet 802.2 (для сетевых адаптеров Ethernet) и номер сети, равный 0. Иногда на неправильно сконфигурированном хосте Auto Detect выбирает неподходящую комбинацию типа кадров и номера сети для адаптера. Как правило, такая ситуация возникает при неверной ручной настройке сетевых параметров на компьютере. Так как Auto Detect использует ответ, присылаемый на RIPX-запрос, а неправильно настроенный компьютер сообщает некорректные тип кадров и номер
ГЛАВА 12
Взаимодействие с NetWare
499
сети, Auto Detect принимает неверную конфигурацию и пытается работать с ней. Кроме того, Auto Detect может выбрать неправильный номер сети, когда на запрос отвечает несколько компьютеров. В этом случае функция использует эвристический алгоритм для определения наиболее вероятного номера сети, но ошибка вполне возможна. Если Auto Detect выбирает неподходящий тип кадров для конкретного адаптера, Вы можете сами задать нужные тип кадров и номер сети, которые будут использоваться NWLink для этого адаптера. Чтобы выяснить тип кадров и номер сети, указанные на компьютере Windows 2000, введите в окне командной строки команду Spxroute config. Это единственный способ просмотра информации IPX на серверах Windows 2000. Получаемые при ;-этом данные показаны на рис. 12-6.
9B r > ---199? Hici-otioFt Corp. R o u t i n g and Source }\u Netwuj'k
ipbacfcfld&pt*!»
Urea C o n n e c t i o n
NucUf
i72if.72B
l?2tfi72B
Йс212в524153
Рис. 12-6. Информация, отображаемая командой ipxroute config Чтобы выяснить тип кадров и номера внутренней и внешней сетей, указанные на компьютере NetWare, введите команду config в консоли сервера NetWare или проверьте содержимое файла Autoexec.ncf (рис. 12-7),
File server name R E S K I T 7 ipx internal net 17116168 load c:\EPRO port=3Bfl int-5 frane= ETHERNET_8B2.2 Hind IPX to EPRO net =17216240 I
Рис. 12-7. Тип кадров, сообщаемый в NetWare-файле Autoexec.ncf Изменять тин кадров и номер сети на компьютере Windows 2000 имеют право лишь члены группы Administrators (Администраторы). Внимание ГЗ большинстве случаев необходимость изменять тип кадров и номер сети не возникает, поскольку они корректно распознаются функцией Auto Detect. Если Вы выберете неправильное значение одного из этих параметров, клиентская м&пина не сможет подключаться к ресурсам по IPX, ^ Чтобы изменить номер внутренней сети: 1, В окне Control Panel (Панель управления) дважды щелкните значок Network and Dial-up Connections (Сеть и удаленный доступ к сети).
500
ЧАСТЬ 3
Взаимодействие с другими системами
2. Щелкните значок нужного соединения правой кнопкой мыши и выберите команду Properties (Свойства). 3. На вкладке General (Общие) укажите NWLink IPX/SPX/NetBIOS Compatible Transport Protocol (NWLink IPX/SPX/NetBIOS-совместимый транспортный протокол) и щелкните кнопку Properties (Свойстаа). 4.
В поле Internal network number (Номер внутренней сети) введите какое-либо уникальное значение и щелкните кнопку ОК.
^ Чтобы изменить тип кадров и номер внешней сети: 1. В окне Control Panel дважды щелкните значок Network and Dial-up Connections. 2. Щелкните значок нужного соединения правой кнопкой мыши и выберите команду Properties. 3. На вкладке General укажите NWLink IPX/SPX/NetBIOS Compatible Transport Protocol и щелкните кнопку Properties. 4.
Выберите переключатель Manual frame type detection (Ручное определение типа кадра) и щелкните кнопку Add (Добавить).
5.
В диалоговом окне Manual Frame Detection (Ручное определение типа кадра) в списке Frame type (Тип кадра) выберите требуемый тип кадров.
6. В поле Network number (Номер сети) введите подходящий номер сети и щелкните кнопку ОК.
NWLink и поддерживаемые типы кадров Windows 2000 и NetWare поддерживают для сетей Ethernet, Token Ring и FDD1 типы кадров, перечисленные в таблице 12-2. Таблица 12-2. Поддерживаемые типы кадров Тип сети
Поддерживаемые типы кадров
Ethernet Token Ring FDDI
Ethernet II, 802.2. 802.3. К02.2 SNAP (Subnet Access Protocol) 802.5 и 802.5 SNAP 802.2, 802.3 и SNAP
Типы кадров определяются на основе стандартов IEEE (Institute of Electrical and Electronics Engineers. Inc.) и описывают форматы пакетов, используемые в различных сетевых технологиях. На рис. 12-8 показана структура пакета типа кадра, определенного IEEE. Ethernet II PA
SFD
Адрес назначения Адрес источника
Тип
MAC -данные
IPX-заголовок
FCS
1РХ-данньй
Рис. 12-8. NWLink и поддерживаемые типы кадров
ГЛАВА 12
Взаимодействие с NetWare
501
Ethernet II Кадр Ethernet II включает двухбайтовое поле типа, которое следует непосредственно за адресом источника. Поле типа содержит уникальное значение, называемое EtherType; это значение идентифицирует компьютер-получатель (протокол более высокого уровня должен обрабатывать для этого компьютера содержимое ноля данных). Ethernet 802.2 Несколько типов кадров базируется на стандартах IEEE 802.3, которые определяют рабочие характеристики физического уровня и подуровня MAC. В NetWare стандарт IEEE 802.3 для физического уровня комбинируется со стандартом IliEE 802.2 для поддержки подуровня LLC (Logical Link Control). Комбинация этих стандартов называется типом кадров Ethernet 802.2. Кадры Ethernet II и Ethernet 802.2 можно использовать в одной сети. Поскольку ноле типа в Ethernet всегда содержит значение, большее 1500, а значение поля длины в Ethernet 802.2 никогда не превышает 1500, аппаратно-программное обеспечение любой сети различает эти типы кадров, и, следовательно, они могут сосуществовать в одной сети. SNAP
Тип кадров SNAP (Subnet Access Protocol) является производным от типа кадров Ethernet 802.2. SNAP-часть кадра помещается в поле данных. Этот тип кадров предназначен для того, чтобы отдельные вендоры могли назначать собственные уникальные идентификаторы протоколам, работающим на их оборудовании. Ethernet 802.3 Как и кадры 802.2, кадры 802.3 отличаются от кадров Ethernet II тем, что вместо поля типа используется поле длины. Этот тип кадров часто называют «802.3 r;i.w», потому что он не предусматривает LLC-заголовка в ноле данных, Token Ring 802.5 Протокол Token Ring поддерживает два подтипа: МАС-кадры и кадры, отличные от MAC. Кадры первого подтипа несут в сетях Token Ring управляющую информацию и не пересылаются мостами и маршрутизаторами. Поэтому они циркулируют в рамках того LAN-кольца, где они были сгенерированы. Кадры второго подтипа в сетях Token Ring используются для передачи данных между компьютерами в кольце и пересылаются мостами и маршрутизаторами. Содержимое первых полей в кадре Token Ring может переопределять смысл значений в последующих полях этого кадра.
Номера сетей Для поддержки маршрутизации NWLink можно настроить с двумя принципиально разными типами номеров сетей: номером внешней сети (external network number) и номером внутренней сети (internal network number). NWLink использует номер внешней IPX-сети для идентификации локального сетевого сегмента компьютера в маршрутизируемой среде. N W L i n k поддерживает и номер виртуальной сети (virtual network number), также называемый номером внутренней сети; этот номер
502
ЧАСТЬ 3
Взаимодействие с другими системами
идентифицирует логическую сеть внутри компьютера. Эта логическая сеть позволяет оптимизировать маршрутизацию запросов, адресованных службам, которые работают на данном компьютере. В Windows 2000 оба номера можно модифицировать через Control Panel. Соответствующие процедуры см. в разделе «NWLink-функция Auto Detect» ранее в этой главе. Подробнее о номерах сетей см. главу 5 «IPX-маршрутизация» в этой книге. Номер внешней сети Этот номер сопоставляется с физическим сетевым адаптером и LAN-сегментом (такой сегмент аналогичен TCP/IP-подсети). Номер внешней сети идентифицирует локальный сегмент компьютера и применяется при взаимодействии с другими сетевыми устройствами в маршрутизируемой среде. Пакеты, передаваемые по сети, содержат номер внешней сети компьютера или его номер внутренней сети, если ему присвоен таковой номер, а также MAC-адрес, идентифицирующий конкретный компьютер. Все компьютеры в одном и том же сетевом сегменте, использующие одинаковый тип кадров, должны иметь одинаковый номер внешней сети, и этот номер должен быть уникальным для каждого сетевого сегмента. Если Вы модифицировали такой номер своего сегмента, заменили сетевой адаптер или подключили компьютер к другому сегменту, то не исключено, что Ваш компьютер не сможет поддерживать коммуникационную связь по IPX. Если Вы потеряли возможность соединений по IPX, восстановите номер внешней сети и перезагрузите компьютер. Чтобы определить номер внешней сети и тип кадров, на которые настроен компьютер с Windows 2000, используйте команду ipxroute config. А чтобы выяснить те же параметры на сервере NetWare, введите команду config или просмотрите файл Autoexec, ncf. Примечание В одном физическом сетевом сегменте может работать несколько IPXсетей, если все они используют разные типы кадров. Номер внутренней сети Такие номера помогают SAP-клиентам определять оптимальный маршрут передачи пакетов службам, работающим на серверах. При использовании номеров только внешних сетей несколько маршрутизаторов может предоставить клиентскому хосту целый набор маршрутов с одинаковыми метриками, тогда как оптимальным маршрутом на самом деле является лишь один из них. Указывая номер внутренней сети, Вы создаете на сервере виртуальную сеть, благодаря которой пакеты пересылаются службам, работающим на этом сервере, по оптимальному пути (см. главу 5 «IPX-маршрутизация» в этой книге). По умолчанию номер внутренней сети не задается. При установке NWLink функция Auto Detect не распознает этот номер автоматически. Вместо этого NWLink no умолчанию присваивает сетевому адаптеру компьютера номер внутренней сети 00000000. А когда номер внутренней сети равен 00000000, он не используется. NWLink ведет себя так при привязке как к одному адаптеру, так и к нескольким. Однако номер внутренней сети необходим, если Ваш компьютер с Windows 2000 выполняет какое-нибудь серверное приложение, использующее NetWare SAP, например SQL Server, Microsoft Exchange или SNA Server.
ГЛАВА 12 Взаимодействие с NetWare
503
В зависимости от конфигурации Вашему компьютеру, возможно, уже присвоен номер внутренней сети. Такой номер автоматически задается при установке File and Print Services for NetWare (Служба доступа к файлам и принтерам сетей NetWare), Routing and Remote Access Service (Служба маршрутизации и удаленного доступа) и агента SAP. Номер внутренней сети по умолчанию (00000000) командой ipxroute config HI.' показывается.
Службы шлюза и клиента для NetWare Windows 2000 включает два средства, позволяющие Windows-клиентам обращаться к файлам, каталогам и принтерам NetWare на серверах NetWare как с регистрационной базой данных (bindery), так и с Novell Directory Services (NDS). Gateway Service for NetWare (Служба шлюза для NetWare) действует как шлюз, через который множество клиентов может обращаться к ресурсам NetWare, a Client Service for NetWare (Служба клиента для сетей NetWare) обеспечивает клиентскую поддержку соединений п NetWare. Обе службы работают с протоколом NWLink, автоматически устанавливаемым при установке C l i e n t Service for NetWare или Gateway Service for NetWare. Подробнее о NWLink см. раздел «NWLink» ранее в этой главе, Gateway Service tor NetWare устанавливается на компьютер с Windows 2000 Server. Через этот шлюз клиенты под управлением Windows 2000 Professional, Window;; NT Workstation, Windows 95 и Windows 98 могут работать с файлами, каталогами и принтерами NetWare. Поскольку шлюз образует единую точку доступа к службам NetWare, Вам не потребуется устанавливать клиентское программное обеспечение NetWare (например, Client Service for NetWare) ua каждой рабочей станции. Crateway Service for NetWare поддерживает прямой доступ к службам NetWare с компьютера под управлением Windows 2000 Server — так же, как Client Service for NetWare поддерживает прямой доступ с клиентского компьютера. Client Service for NetWare устанавливается на индилидуалъных клиентах Windows 2000 Professional и предоставляет им прямой, высокопроизводительный доступ к файлам, каталогам и принтерам NetWare. Так как клиенты Windows 2000 с установленной Client Service for NetWare напрямую подключаются к серверам NetWare, им не нужен шлюз, предоставляемый Gateway Service for NetWare. Обе службы — Gateway Service for NetWare и Client Service for NetWare — также поддерживают сценарии регистрации в NetWare (см. раздел «Сценарии регистрации» далее в этой главе). Примечание Windows 2000 обновляет клиентское программное обеспечение \etWare, ранее установленное с Windows NT, Windows 95 и Windows 98. Такое обновление применяется только на компьютерах с клиентским программным обеспечением NetWare версий ниже 4.7 и только при установке Windows 2000 «поверх» одной из прежних версий Windows. Более подробную информацию см. в файле Readme на дистрибутивном компакт-диске Windows 2000. Компьютеры под управлением Windows 2000 Server со службой шлюза для NetWare и компьютеры иод управлением Windows 2000 Professional со службой клиента для сетей NetWare могут использовать сквозную аутентификацию. Если у пользователя одинаковые удостоверения для сетей Windows 2000 и NetWare и пароли для входа в эти сети синхронизированы, он может регистрироваться сразу в двух сетях.
504
ЧАСТЬ 3
Взаимодействие с другими системами
При загрузке компьютера с упомянутым выше программным обеспечением на экране появляется диалоговое окно Log on to Windows (Вход в Windows). С его помощью пользователь может войти в сеть Windows 2000, а также аутентифицироваться в сети NetWare — при условии, что пароли синхронизированы. Синхронизировать пароли можно как на Windows-серверах, так и на серверах NetWare 4.x через Gateway Service for NetWare или Client Service for NetWare. Для этого нужно нажать комбинацию клавиш Clrl+Alt-rDcl и в диалоговом окне ввести новый пароль. Информацию о синхронизации паролей см. в разделе «Дополнительные материалы» в конце этой главы.
Выбор между службой шлюза и службой клиента Выбирая между Gateway Service for NetWare и Client Service for NetWare для доступа к сервисам NetWare, примите во внимание изложенные ниже материалы. Как правило, если Вы собираетесь создать гетерогенную среду, состоящую из серверов Windows 2000 и NetWare, то лучше использовать Client Service for NetWare. Если же Вы планируете постепенный переход с NetWare на Windows 2000 или хотите упростить администрирование, подумайте о применении Gateway Service for NetWare.
Преимущества и недостатки Client Service for NetWare Client Service for NetWare обеспечивает следующие преимущества. •
Защита на уровне пользователей. Служба клиента для сетей NetWare поддерживает защиту на уровне пользователей, а не ресурсов. Благодаря этому пользователи могут обращаться к индивидуальным основным каталогам (с персональными данными), которые хранятся на NetWare-томе. Этот каталог пользователь подключает как сетевой диск; то же самое можно делать с любыми дополнительными томами, к которым он имеет право обращаться. А для доступа к индивидуальным основным каталогам через Gateway Service for NetWare нужно выделять каждому пользователю отдельную букву диска.
•
Большее быстродействие по сравнению со службой шлюза. Client Service for NetWare взаимодействует с серверами NetWare напрямую, исключая потенциальное «узкое место», которое возникает из-за интенсивного трафика через единственное сетевое соединение.
Однако Client Service for NetWare присущ ряд недостатков. •
Несколько учетных записей на каждого пользователя. Для каждого пользователя нужны разные учетные записи в Windows 2000 и NetWare. Однако этого не потребуется при использовании какого-либо дополнительного продукта. Например, Directory Service Manager для Windows NT 4.0 исключает необходимость создания отдельных учетных записей па серверах NetWare с регистрационной базой данных (bindery). • Более высокие затраты на установку программного обеспечения и управление им. Вы должны установить Client Service for NetWare на каждую рабочую станцию с Windows 2000 Professional. • Необходимость добавления IPX ко всей сети. Серверы Windows 2000 и NetWare 5.0 используют TCP/IP как «родной» набор протоколов. Однако Client Service for NetWare требует применения IPX (через NWLink) и не позволяет ограничить его использование рамками некоей части сети. Даже если 1РХ-кли-
ГЛАВА 12
Взаимодействие с NetWare
505
енты присутствуют только в одной подсети, Вам придется обеспечить IPX-маршрутизацию во всей сети.
Преимущества и недостатки Gateway Service for NetWare Gateway Service for NetWare обеспечивает следующие преимущества. •
Одна учетная запись для каждого пользователя. Служба шлюза является централизованным интерфейсом для доступа пользователей к NetWare Service for NetWare и позволяет управлять всеми пользовательскими учетными записями Windows 2000. Вы можете приписать пользователей или группы к ACL каждого общего ресурса.
•
Установка только на сервере. Служба шлюза не требует установки клиентского программного обеспечения NetWare.
•
Возможность изоляции IPX. Служба шлюза позволяет изолировать IPX к каком-либо сегменте локальной сети — Вам не придется обеспечивать IPX-маршрутизацию во всей сети.
Однако Gateway Service for NetWare присущ ряд недостатков. •
Ограниченная поддержка защиты на уровне пользователей. Все пользователи Windows 2000 обращаются к ресурсам NetWare так, будто они являются эквивалентными пользователями NetWare. Служба шлюза назначает буквы дисков отдельным файлам или каталогам NetWare, а затем ко всему ресурсу применяются ограничения доступа на уровне ресурсов. Поэтому единственный способ создания защиты на уровней пользователей — закрепление отдельных букв дисков за каждым пользователем. Поскольку часть букв дисков резервируется для локальных и сетевых дисков, а также для некоторых других целей, защита на уровне пользователей просто неприменима при наличии более двадцати пользователей. • Меньшее быстродействие по сравнению с Client Service for NetWare. При использовании службы шлюза компьютер с Windows 2000 Server должен работать как шлюз между клиентскими компьютерами и серверами NetWare. Все запросы к NetWare проходят через одно шлюзовое соединение, создавая «y;iKoe место». Но в некоторых случаях Gateway Service for NetWare все же работает быстрее, чем Client Service for NetWare, — например, если SMB-трафик интенсивнее NCP-трафика.
Как функционирует Gateway Service for NetWare Gateway Service for NetWare (Служба шлюза для NetWare) выступает в роли шлюза между протоколом CIFS (Common Internet File System), применяемым в сетях Windows, и протоколом NCP (NetWare Core Protocol), используемым в сетях NetWare. CIFS (ранее известный как SMB) — это встроенный в Windows 2000 протокол совместного использования файлов. После активизации службы шлюза Windows-клиенты могут обращаться к сервисам NetWare через этот шлюз, находящийся на компьютере с Windows 2000 Server. Рис. 12-9 иллюстрирует, как несколько Windows-клиентов обращаются к сервисам NetWare через шлюзовой сервер Windows 2000. CIFS-трафик транслируется в NCPтрафик и передается серверу NetWare.
506
ЧАСТЬ 3 Взаимодействие с другими системами Gateway Service for NetWare находится на компьютере с Windows 2000 Server
Клиентские компьютеры
(с Windows 2000
Professional, Windows NT, Windows 95. Windows 98)
^4ta. л&^£
Принтер
Рис. 12-9. Доступ к NetWare через службу шлюза Чтобы Windows-клиенты могли обращаться к дисковому тому NetWare, компьютер Windows 2000 Server с Gateway Service for NetWare подключает этот том NetWare как свой сетевой диск и делает его доступным Windows-клиентам. Для создания аутентифицированного соединения с сервером NetWare шлюз Windows 2000 Server использует свою учетную запись в NetWare. Это соединение на компьютере с Windows 2000 Server появляется как перенаправленный диск (redirected drive). Когда перенаправленный диск становится общим, он функционирует так же, как и любой другой общий ресурс; при этом он кажется пользователям ресурсом Windows 2000 Server, хотя на самом деле это ресурс сервера NetWare. Допустим, Вы хотите создать шлюз на компьютере А (где работает Gateway Service for NetWare) к тому Data на компьютере В — сервере NetWare с регистрационной базой данных, При активизации шлюза в диалоговом окне Configure Gateway (Пастройка шлюза) Вы указываете \\B\Data как ресурс NetWare, а затем задаете имя этого ресурса для клиентов Windows 2000, например Nw_Data. Тогда Windows-клиенты ссылаются на этот ресурс под именем \\A\Nw_Data. После того как шлюзовое соединение установлено, оно разрывается только в тех случаях, если компьютер с Windows 2000 Server выключается, если администратор отключает данный общий ресурс либо останавливает работу шлюза или если в сети возникает какая-либо проблема, препятствующая доступу к серверу NetWare. Смена зарегистрированного пользователя в Windows 2000 Server сама но себе не приводит к разрыву шлюзового соединения. Примечание Поскольку запросы от сетевых Windows-клиентов принимаются по единственному соединению между шлюзом и сервером NetWare, доступ через шлюз медленнее, чем прямой доступ с использованием Client Service for NetWare. Windows-клиенты, часто обращающиеся к ресурсам NetWare, для большего быстродействия должны работать с локальным клиентским программным обеспечением (например, Client Service for NetWare или Novell Client for Windows 2000).
Трансляция пакетов службой шлюза для NetWare При передаче данных между протоколом CIFS в Windows 2000 и протоколом Novell NCP с помощью Gaieway Service for NetWare на шлюзе осуществляются необходимые преобразования с использованием редиректора Nwrdr.sys.
ГЛАВА 12
Взаимодействие с NetWare
507
Рис. 12-10 иллюстрирует, как CIFS-пакет транслируется в NCP-пакет и передается серверу NetWare. Сначала Windows-клиент посылает CIFS-запрос. Такой запрос может поступать на шлюз от самых разнообразных сетевых Windows-клиентов с применением различных транспортных протоколов. Например, CIFS-запрос может быть принят от Windows-клиента удаленного доступа, соединяющегося с сетью через службу маршрутизации и удаленного доступа, или от Windows-клиента, напрямую подключенного к сети по TCP/IP, IPX/SPX или NetBEUI. CIFS-запрос, поступивший от сетевого клиента на компьютер с Windows :.:!000 Server и Gateway Service for NetWare, сначала обрабатывается службой cepuepa (Srv.sys). Если клиент запрашивает какую-либо файловую операцию (в ответ на этот запрос должен быть возвращен описатель нужного файла), служба сервера передает имя общего ресурса, путь к файлу и его имя диспетчеру ввода-вывода Windows 2000.
Сервер NetWare
Рис. 12-10. Трансляция пакетов службой шлюза для NetWare После этого диспетчер ввода-вывода Windows 2000 (To.sys), используя имя объекта файла, вызывает редиректор Nwrdr.sys и передает ему информацию из маркера защиты объекта, отправившего CIFS-запрос. Исходя из маркера защиты, Nwrdr.sys определяет, был ли запрос выдан по локальной учетной записи. Если запрос был удаленным, Nwrdr.sys использует удостоверения шлюза. Далее Nwrdr.sys возвращает описатель файла диспетчеру ввода-вывода W i n dows 2000, а тот передает описатель службе сервера. С этого момента ClFS-трафик, связанный с операциями над данным файлом, посылается службой сервера непосредственно Nwrdr.sys. Наконец, Nwrdr.sys передает запрос серверу NetWare.
Как функционирует Client Service for NetWare Код Client Service for NetWare (Служба клиента для сетей NetWare) представляет собой подмножество кода Gateway Service for NetWare. Вы устанавливаете эту службу на клиентских компьютерах под управлением Windows 2000, чтобы они могли напрямую обращаться к сервисам NetWare. При этом клиенты, работающие с Client Service for NetWare, не используют для трансляции пакетов шлюз Windows 2000.
508
ЧДСТЬ 3
Взаимодействие с другими системами
Вместо этого клиент под управлением Windows 2000 Professional и Client Service for NetWare сам генерирует NCP-пакеты и передает их прямо в сеть (рис. 12-1.1). Эти пакеты принимаются непосредственно сервером NetWare. Client Sen/ice for NetWare находится на клиенте Windows 2000
Windows 2000 Professional Принтер
Рис. 12-11. Доступ через службу клиента для сетей NetWare Когда том NetWare подключается как сетевой диск, компьютер под управлением Windows 2000 Professional устанавливает соединение с сервером NetWare по своей учетной записи в NetWare. Допустим, Вы хотите создать соединение между компьютером А (под управлением Client Service for NetWare) с NetWare-томом \\B\Serverl\Org_Unit.Org\Data на NetWare-сервере В со службой NDS. Тогда Вы просто используете команду Map Network drive (Подключить сетевой диск) или утилиту командной строки net use и указываете путь \\B\Serverl\Org_Unit.Org\Data для ресурса NetWare. Информацию о подключении сетевых дисков см. в справочной системе Windows 2000 Professional. После подключения сетевого лиска соответствующее соединение разрывается, только если в сети возникает какая-либо проблема, препятствующая доступу к серверу NetWare, если сетевой диск отключается вручную или если компьютер с Windows 2000 Professional выключается. При следующем входе пользователя в сеть это соединение восстанавливается. Примечание Поскольку запросы от клиента Windows 2000 Professional с Client Service for NetWare передаются серверу NetWare по выделенному соединению, доступ осуществляется быстрее, чем при использовании Gateway Service for NetWare.
Трансляция пакетов службой клиента для сетей NetWare Пакеты перенаправляются серверам файлов и принтеров NetWare через Client Service for NetWare no аналогии с тем, как ото делается при использовании Gateway Service for NetWare, но генерируются па самом клиенте Windows 2000. Как видно на рис. 12-12, пакеты проходят через lo.sys и редиректор Nwrdr.sys, а затем передаются в сеть по протоколу NCP.
ГЛАВА 12
Взаимодействие с NetWare
509
Сервер NetWare
Рис. 12-12. Трансляция пакетов службой клиента для сетей NetWare
Настройка служб шлюза и клиента Поскольку при использовании Gateway Service for NetWare (Служба шлюза для NetWare) или Client Service for NetWare (Служба клиента для сетей NetWare] соединения являются кросс-платформенными (между Windows 2000 и NetWare), Вы должны сконфигурировать и сеть Windows 2000, и сеть NetWare.
Подготовка сервера NetWare к взаимодействию со службами шлюза и клиента Обе эти службы требуют создания учетных записей и задания прав доступа в сеть NetWare. Эти задачи могут быть решены с помощью NetWare Syscon или NDS NWAdmin. Внимание Ни Gateway Service for NetWare, ни Client Service for NetWare не поддерживают доступ к утилите NWAdmin. Для использования NWAdmin Бы должны войти на NDS-сервер NetWare с клиентского компьютера, на котором установлено клиентское программное обеспечение NetWare, например Novell Client for Windows 2000. В следующих разделах поясняется, какие учетные записи Вам понадобятся. Подготовка сервера NetWare к взаимодействию со службой шлюза для NetWare Чтобы компьютер с Windows 2000 Server и Gateway Service for NetWare мог подключаться к ресурсам NetWare, нужно создать пользовательскую и групповую учетные записи. Сначала Вы должны создать уникальную пользовательскую учетную запись NetWare, которая будет служить своего рода NetWare-интерфейсом для компьютера под управлением Windows 2000 Server и Gateway Service for NetWare. Пароль для этой записи должен быть идентичен паролю, применяемому при активизации шлюза Windows 2000 Server (см. раздел «Настройка га л юза на сервере с Windows !:'000 Server» далее в этой главе). Затем нужно создать в NetWare уникальную групповую учетную запись с именем NTGATEWAY. Эта запись служит общей точкой доступа к ресурсам NetWare для всех пользователей шлюза Windows 2000 Server, поэтому Вы должны указать в ней соответствующие права доступа ко всем необходимым ресурсам NetWare. Наконец, включите созданную ранее пользовательскую учетную запись NetWare в групповую учетную запись NTGATEWAY.
510
ЧАСТЬ 3
Взаимодействие с другими системами
Подготовка сервера NetWare к взаимодействию со службой клиента для сетей NetWare Чтобы компьютер с Windows 2000 Professional и Client Service for NetWare мог подключаться к ресурсам NetWare, нужно создать уникальную пользовательскую учетную запись в сети NetWare и указать в ней соответствующие права доступа к необходимым ресурсам. Вы (или сам пользователь) должны также синхронизировать пароли между Windows 2000 и NetWare.
Настройка шлюза на сервере с Windows 2000 Server Включив пользовательскую учетную запись NetWare в группу NTGATEWAY, Вы можете создать шлюз Windows 2000 Server. Для этой операции у Вас должно быть разрешение на создание общих ресурсов на локальном компьютере с Windows 2000 Server. Внимание Прежде чем устанавливать Gateway Service for NetWare (Служба шлюза для NetWare), удалите любые редиректоры NetWare, если они были установлены ранее (например, Novell Client for Windows 2000), и перезагрузите компьютер. Установка Gateway Service for NetWare Gateway Service for NetWare устанавливается на компьютере с Windows 2000 Server для его использования в качестве шлюза. ^ Чтобы установить Gateway Service for NetWare: 1. В окне свойств соединения откройте икладку General (Общие) и щелкните кнопку Install (Установить). 2.
В диалоговом окне Select Network Component Type (Выбор типа сетевого компонента) укажите Client (Клиент) и щелкните кнопку Add (Добавить). Если Вы устанавливаете серверный шлюз, выберите Gateway (and Client) Services for NetWare [Службы шлюза (и клиента) лля NetWare] и щелкните кнопку ОК. 3. В случае сервера NetWare с регистрационной базой данных (bindery) в диалоговом окне Select NetWare Logon (Выбор входа в сеть NetWare) введите имя основного сервера, с которым должен соединяться данный компьютер под управлением Windows 2000 Server. - Или В случае сервера NetWare с NDS щелкните переключатель Default Tree and Context (Дерево и контекст по умолчанию) и введите имена дерева и контекста. Если Вам нужно запускать сценарий регистрации, установите флажок Run Login Script (Выполнять сценарий входа) и щелкните кнопку ОК.
Примечание Кроме установки Gateway Service for NetWare или Client Service for NetWare, которые позволяют обращаться к файлам, каталогам и принтерам NetWare из Windows 2000, Вам нужно настроить на серверах NetWare соответствующие пользовательские учетные записи, права /юстугта к ресурсам, групповые нрава и сценарии регистрации. Более подробную информацию па эту тему см. в документации NetWare. Подробнее об основном сервере, дереве и контексте по умолчанию см. раздел «Выбор дерева и контекста по умолчанию или основного сервера» далее в этой главе.
ГЛАВА 12
Взаимодействие с NetWare
511
После установки Gateway Service for NetWare Вы можете изменить ее конфигурацию через диалоговое окно Gateway Service for NetWare (Служба шлюза для NetWare), показанное на рис. 12-13. Это окно открывается запуском апплета Gateway Service for NetWare (GSKW) в Control Panel (Панель управления).
•C Defai* Tree a^ Cantol Tree:
[
Cortes* Overview
Рис. 12-13. Диалоговое окно Gateway Service for NetWare (Служба шлюза для NetWare) Настройка шлюза Windows 2000 Server Чтобы активизировать шлюз Windows 2000 Server, в диалоговом окне Gateway Service for NetWare (Служба шлюза для NetWare) щелкните кнопку Gateway (Шлюз). На экране появится диалоговое окно Configure Gateway (Настройка шлюза), показанное на рис. 12-14. Установите в нем флажок Enable Gateway (Включить шлюз), введите имя учетной записи шлюза и пароль. Этот пароль должен быть идентичен паролю в пользовательской учетной записи, созданной ранее на сервере NetWare. Такие операции выполняются только один раз для каждого сервера, работающего в качестве шлюза. Примечание Если Ваша учетная запись находится в NDS, Вы должны ввести полное составное имя (full distinguished name) для этой учетной записи — например, не Jdoe, a Jdoe.Sales.Milan.Eu.Reskit. Указание ресурсов и разрешений После установки Gateway Service for NetWare и настройки шлюза можно указать общие ресурсы и разрешения. Для создания общего ресурса щелкните кнопку Add (Добавить) в диалоговом окне Configure Gateway (Настройка шлюза). В соответствующих полях введите имя ресурса, сетевой путь, букву сетевого диска и предельное число пользователей данного ресурса. Далее можно указать разрешения для пользователей этого ресурса.
512
ЧАСТЬ 3 Взаимодействие с другими системами
Рис. 12-14. Диалоговое окно Configure Gateway (Настройка шлюза) Настройка принтера шлюза Создав необходимые пользовательскую и 1рушювую учетные записи, задав права доступа на серверах NetWare и корректно установив Gateway Service for NetWare на сервере Windows 2000, можно настроить и установить соединение с принтером NetWare через шлюз Windows 2000 Server. Подробную информацию о настройке принтерного ресурса Вы получите, щелкнув кнопку Overview (Обзор) в диалоговом окне Gateway Service for NetWare (Служба шлюяа для NetWare).
Настройка службы клиента в Windows 2000 Professional Создав и настроив пользовательскую учетную запись NetWare, Вы можете установить и настроить Client Service for NetWare (Служба клиента для сетей NetWare) на компьютере с Windows 2000 Professional. Внимание Прежде чем устанавливать Client Service for NetWare, удалите любые редиректоры NetWare, если они были установлены ранее (например, Novell Client for Windows 2000), и перезагрузите компьютер. Установка Client Service for NetWare Client Service for NetWare устанавливается на компьютере с Windows 2000 Professional. ^ Чтобы установить Client Service for NetWare: 1. В окне свойств соединения откройте вкладку General (Общие) и щелкните кнопку Install (Установить). В диалоговом окне Select Network Component Type (Выбор типа сетевого компонента) укажите Client (Клиент) и щелкните кнопку Add (Добавить). 3. В диалоговом окне Select Network Client (Выбор сетевого клиента) укажите Client Service for NetWare (Служба клиента для сетей NetWare). 2.
4. В случае сервера NetWare с регистрационной базой данных (bindery) в диалоговом окне Select NetWare Logon (Выбор входа в сеть NetWare) введите имя ос-
ГЛАВА 12
Взаимодействие с NetWare
513
ионного сервера, с которым должен соединяться данный компьютер под управлением Windows 2000 Professional. - Или -
В случае сервера NetWare с NDS щелкните переключатель Default Tree and Context (Дерево и контекст по умолчанию) и введите имена дерева и контекста. Если Вам нужно запускать сценарий регистрации, установите флажок Кип Login Script (Выполнять сценарий схода) и щелкните кнопку ОК. Примечание Кроме установки Gateway Service for NetWare или CJient Service for NetWare, которые позволяют обращаться к файлам, каталогам и принтерам NetWare из Windows 2000, Вам нужно настроить на серверах NetWare соответствуюшие пользовательские учетные записи, права доступа к ресурсам, групповые прав;! и сценарии регистрации. Более подробную информацию на эту тему см. в документации NetWare. После установки Client Service for NetWare Вы можете изменить ее конфигурацию через диалоговое окно Client Service for NetWare (Служба клиента для сет^й NetWare). Это окно открывается запуском апнлета Client Service for NetWare (CSNW) в Control Panel (Панель управления).
Выбор дерева и контекста по умолчанию или основного сервера Чтобы получить доступ к сервисам NetWare через Gateway Service for NetWare шш Client Service for NetWare, Вы должны указать либо дерево и контекст по умолчанию для пользователя или группы, либо основной сервер. Если пользователям нужно подключаться к ресурсам NDS, задайте дерево и контекст, а если пользователям нужно подключаться к ресурсам на основе регистрационной базы данных — основной сервер. Указание дерева и контекста по умолчанию в среде NDS В NDS (Novell Directory Services) термин «дерево» относится к иерархической структуре каталогов NDS, а «контекст» — к местонахождению какого-либо объекта в этом дереве каталогов. Если в организации имеется только одно дерево, его очеш. легко выбрать и указать. Однако выбор контекста не столь очевиден. Примечание При обращении к среде NDS часто возникает проблема с доступом к файлам или сервисам из-за неправильно заданного контекста. Установив неверный контекст, Вы не сможете аутентифидироваться. Вы задаете контекст в диалоговом окне Client Service for NetWare (Служба клиента для сетей NetWare) или Gateway Service for NetWare (Служба шлюза для NetWare). При этом Вы можете ввести его имя либо в полностью типизированном, либо в нетипизированном формате, В дереве каталогов NDS на рис. 12-15 контекстом в полностью типизированном формате для пользователя JDOE является ou=sales.ou=milan.ou=eu.o=reskit; тот же контекст в нетипизированном формате выглядит как sales.milan.eu,reskit. В этом примере корневым объектом является Reskit.
514
ЧАСТЬ 3 Взаимодействие с другими системами
(OU)=Noam
(CNHDOE
Корень Организация Организационная единица (OU) Общее имя
Рис. 12-15. Дерево каталогов NDS
Указание основного сервера в среде на основе регистрационной базы данных В этой среде Вы должны сообщить системе с Windows 2000 и Gateway Service for NetWare или Client Service for NetWare, на каком сервере NetWare находятся пользовательская и групповая учетные записи с соответствующими правами. Такой сервер NetWare указывается как основной. После регистрации на этом сервере Вы сможете подключаться к другим серверам NetWare. Если Вы не хотите указывать основной сервер, выберите None (Нет) в диалоговом окне Client Service for NetWare. Тогда Ваш компьютер будет посылать запрос Get Nearest Server, и первый ответивший сервер станет SAP-агентом. Вы сможете использовать этот сервер для поиска других серверов в сети точно так же, как и при работе с NetWare-командой slist.
Установка нескольких шлюзов При использовании Gateway Service for NetWare и наличии очень интенсивного трафика можно установить несколько шлюзов (рис. 12-16), чтобы распределить между ними нагрузку. Но и в этом случае единственной точкой доступа к сети NetWare является групповая учетная запись NTGATEWAY. Чтобы раздельно управлять учетными записями шлюзов, создайте для каждого из них индивидуальную пользовательскую учетную запись NetWare и включите их в группу NTGATEWAY.
Управление защитой Устанавливая Gateway Service for NetWare на компьютер с Windows 2000 Server и включая шлюз в групповую учетную запись NTGATEWAY в NetWare, Вы можете управлять защитой шлюзового соединения двумя способами: • добавив доверительные права доступа (trustee rights) в групповую учетную запись NTGATEWAY на сервере NetWare; • указав ограничения на доступ на шлюзе Windows 2000 Server. Проще всего добавить доверительные права доступа в групповую учетную запись NTGATEWAY. Поскольку эта запись выступает в роли единственного интерфейса
ГЛАВА 12
Взаимодействие с NetWare
515
с сетью NetWare, доверительные права доступа, заданные в NTGATEWAY, применяются ко всем пользователям этой группы. Поэтому Вы должны установить в данной учетной записи такие права, которые отвечают потребностям всех пользователей. В качестве дополнительной защиты можно задать ограничения в разрешениях на шлюзе Windows 2000 Server. О добавлении доверительных прав доступа на сервере NetWare см. документацию NetWare. Грушевая 1 четная запись NTGATEWAY
Шлюзы Windows 2000 Server
Пользовательские учетные записи NetWare Шлюз 1
Сервер NetWare
Шлюз 2
ШлюзЗ
Рис. 12-16. Несколько шлюзов Windows 2000 Server
Файлы, устанавливаемые со службой шлюза, службой клиента и NWLink В таблице 12-3 перечислены файлы, записываемые на компьютер с Windows 2000 Server при установке Gateway Service for NetWare или на компьютер с W i n dows 2000 Professional при установке Client Service for NetWare. При установке любой из этих служб автоматически устанавливается и NWLink. Таблица 12-3. Файлы служб шлюза и клиента Файлы
Описание
Местонахождение
Nwlnkipx.sys, Nwluknb.sys, Nwinkspxsys Ipxroute.exe Nwlnkflt.sys, Nwfnkfwd.sys
Базовые драйверы поддержки NetWare Link Protocol
%windir%\system32\drivers
Диагностическая утилита Драйвер фильтра и диспетчер таблицы пересылки (устанавливаются, если включена служба маршрутизации и удаленного доступа) Клиент для доступа к серверам NetWare
%windir%\system32 %windir%\system32\drivers
Nwrdr.sys
%windir%\system32\drivers (см. след, стр.)
516
ЧАСТЬ 3 Взаимодействие с другими системами
Таблица 12-3.
(продолжение)
Файлы
Описание
Местонахождение
Nwnks.dll, Nwapi32.dll, Nwapil6.dll NetWare.drv, Nwl6.exe, Vwipxspx Nwscript.exe Nwc.cpl Nwdoc.hlp, Nwdocgw.hlp Nwcfg.dll
Клиент, служба и редиректор
% wi ndir % \sysLc m32
Файлы поддержки устаревших 16-разрядных приложений Обработчик сценариев регистрации Па[1ель управления Справочные файлы Файл, используемый для установки и удаления клиента DLL с дополнительными счетчиками производительности Строки для журнала событий
%windir%\systeni32
Perfnw.dll Nwevent.dll
%windir%\system32 ?£windir%\sysieiTi32 %wmdir%\system32\help %windir%\systern32 %windir%\system32 %windir%\system32
Администрирование NetWare через Windows 2000 После настройки доступа к NetWare на компьютере с Windows 2000 через Gateway Service for NetWare (Служба шлюза для NetWare) или Client Service for NetWare (Служба клиента для сетей NetWare) Вы можете управлять большинством серверных функций NetWare и манипулировать ресурсами NetWare.
Администрирование серверов NetWare Администрировать серверы NetWare напрямую через серверы, работающие под управлением NetWare 3~г или 4.x, нельзя. Хотя они позволяют выполнять некоторые административные задачи, Вы не сможете настраивать учетные записи пользователей, указывать их права и т. д. Однако компьютер Windows 2000, подключенный к сети, способен работать как системная консоль и управлять сервером NetWare. Установив на сервере Windows 2000 службу Client Service for NetWare или Gateway Service for NetWare, Вы можете с помощью любой из этих служб запускать утилиты NetWare, рассчитанные на использование регистрационной базы данных (bindery), например System Console (syscun), Remote Console (rcomole) и Printer Console (pconsole). В серверной среде NetWare на основе регистрационной базы данных syscon является главным административным инструментом, который применяется для создания пользовательских учетных записей, определения политик и выдачи разрешений пользователям в сети NetWare. П р и м е ч а н и е Хотя Gateway Service for NetWare и Client Service for NetWare в Windows 2000 поддерживают соединения с NDS-серверами, Вы не сможете использовать VLM (Virtual Loadable Modules) или другие утилиты, специфичные для NDS. Для доступа к этим утилитам нужно установить Novell Client for Windows 2000. В таблице 12-4 перечислены наиболее часто используемые 16-разрядные административные утилиты NetWare, которые можно запускать с компьютера под управлением Windows 2000. Не все версии NetWare поддерживают эти утилиты. Одни утилиты компания Novell заменила, другие — обновила.
ГЛАВА 12
Взаимодействие с NetWare
517
Таблица 12-4. 16-разрядные утилиты NetWare Утилита
Описание
Примечание
Chkvol
Сообщает информацию о любом томе на сервере NetWare
NetWare версий 4.д~ и выше не полдсрживаст эту утилиту; используйте команду ndir [path] /vol
Colorpa]
Позволяет модифицировать стандартную цветовую гамму в NetWare NetWare версий 4.x и выше не поддерDspace Ограничивает дисковое пространство, живает эту утилиту; используйте доступное пользователю на томе команду filer Fconsole Обеспечивает широковещательную Windows 2000 поддерживает не во 1 се передачу сообщений, просмотр текущих меню; Down File Server функционирусоединений пользователей и изменение ет некорректно статуса файл-сервера Filer Позволяет сменить владельца каталога и модифицировать дату создания и временные метки Возможны проблемы в NetWare 5.0 Flag Позволяет просмотреть и изменить атрибуты файлов в указанном каталоге NetWare версий 4.x и выше не поддерFlagdir Позволяет просмотреть и изменить живает эту утилиту; используйте атрибуты подкаталогов в указанном команду flag path attributes /do каталоге NetWare версий 4„т и выше не поддерGrant Выдает доверительные права доступа живает эту утилиту; используйте пользователям или группам применительно к указанному файлу или каталогу команду rights path attributes /nanie=|/group=usernames Обычный синтаксис: Help Выводит справочную информацию <имя_утилиты> /help об утилитах, системных сообщениях и концепциях NetWare NetWare версий 4„т и выше не поддерListdir Позволяет просматривать каталоги, подкаталоги, а также маску наследуемых живает эту утилиту; используйте команду ndir [path] /do ими прав, действующие права и даты создания Возможны проблемы в NetWare 4..Т Ncopy Позволяет копировать один или более и NetWare 5.0 файлов из одного сетевого каталога в другой Возможны проблемы при использоваNdir Позволяет просматривать информацию нии Windows 2000 в сочетании с об именах и размерах файлов, а также NetWare 5.0 о датах их модификации, последнего доступа, создания и архивирования Pconsole Предоставляет администратору средства, Change Current Server не работает необходимые для управления серверами печати NetWare 5.0 не поддерживает Psc Позволяет управлять принт-серверами эту утилиту и сетевыми принтерами Rcoiisole Удаленное управление через системную консоль NetWare NetWare версий 4.x и выше не поддерRemove Позволяет удалять пользователя или живает эту утилиту; используйте группу из списка доверяемых для команду rights указанного файла или каталога NetWare версий i.x и выше не подлерRevoke Аннулирует у пользователя или живает эту утилиту; используйте группы доверительные права доступа команду rights к указанному файлу или каталогу
(см. след, стр.)
518
Взаимодействие с другими системами
ЧАСТЬ 3
Таблица 12-4.
(продолжение)
Утилита
Описание
Примечание
Rights
Позволяет просматривать действующие права доступа к файлу или каталогу Посылает короткое сообщение от одной рабочей станции другой (или нескольким рабочим станциям)
Возможны проблемы в NetWare 5.0
Send
Session
Setpass
Settts
Slist
Syscon
Tlist
Userlist
Volinfo
Whoami
Позволяет временно подключать сетевые диски, создавать, изменять и удалять диски поиска, просматривать группы в сети и посылать сообщения Устанавливает или изменяет пароли на одном или нескольких файл-серверах
Позволяет проверить, отслеживает ли транзакции система TTS (Transaction Tracking System) Сообщает список файл-серверон в межсетевой среде Позволяет создавать учетные записи пользователей, определять политики и выдавать разрешения на доступ к ресурсам NetWare Позволяет просматривать список доверяемых для указанного файла или каталога Позволяет просматривать список текущих пользователей указанного файлсервера, номер соединения каждого пользователя, время его входа в сеть и сетевой адрес Позволяет просматривать информацию о каждом томе на файл-серверах NetWare
Позволяет просматривать информацию о зарегистрированных пользователях, о файл-серверах, к которым подключены пользователи, о группах, к которым относятся пользователи, и о нравах доступа
Команда Send не поддерживается при подключении к NDS-серверу; возможны проблемы при использовании Windows 2000 в сочетании с NetWare 4л: или NetWare 5.0 Функция подключения дисков поиска не поддерживается; в NetWare 4л: эта утилита заменена командой netuser Используйте эту команду только для серверов на основе регистрационной базы данных; для смены паролей в NDS нажимайте комбинацию клавиш Ctrl+Alt+Del NetWare 5.0 не поддерживает эту утилиту NetWare версий 4_г и выше не- поддерживает эту утилиту; используйте команду nlist server NetWare версий 4.x и выше не поддерживает эту утилиту
NetWare версий 4 „г и выше не поддерживает эту утилиту; используйте команду rights NetWare версий 4.x и выше не поддерживает эту утилиту; используйте команду nlist /А /В
Если интервал обновления равен 5, эта команда выполняется очень медленно; NetWare версий 4.x и выше не поддерживает эт}' утилиту; используйте команду filer При подключении к NDS-серверу сообщает лишь ограниченную информацию
Примечание Информацию об административных утилитах NetWare см. в документации на Вашу «ереиго NetWare.
ГЛАВА 12
Взаимодействие с NetWare
519
Многие команды Windows 2000 эквивалентны командам NetWare и могут выполнять те же функции на сервере NetWare. Утилиты NetWare и их эквивален гы в Windows 2000 перечислены в таблице 12-5. Таблица 12-5. Утилиты NetWare и их эквиваленты в Windows 2000 Утилита NetWare
Эквивалент в Windows 2000
Slist Attach, capture, login и logout Map Map root Capture (заставляет приложения MS-DOS и Windows печатать Б определенный порт)
net view /network:nw net use net use net use \сервер\общий_ресурс\ net use
Кроме того, Вы можете использовать папку Printers (Принтеры) для подключения к какому-либо принтеру и работы с ним. Внимание NetWare-команды attach, capture, login и logout не поддерживаются в Windows 2000 и могут вызывать ошибки при выполнении с компьютера под уг равлением Windows 2000. Для упрощения управления сетью на компьютере с Windows 2000 можно открыть отдельные окна для параллельного мониторинга сразу нескольких серверов NetWare. ^ Чтобы подключиться к дополнительным серверам NetWare: 1. Щелкните кнопку Start (Пуск) и последовательно выберите команды Programs (Программы), Accessories (Стандартные) и Windows Explorer (Проводник). 2. Выберите из меню Tools (Сервис) команду Map Network Drive (Подключить сетевой диск). 3. В поле Drive (Диск) введите букву диска (если это нужно). 4.
В иоле Folder (Панка) наберите путь к серверу NetWare.
5. Щелкните кнопку Finish (Готово).
Защита Windows 2000 и NetWare Хотя системы защиты Windows 2000 и NetWare не идентичны, при передаче данных можно управлять одной системой защиты из другой. В следующих разделах описывается, как разрешения Windows 2000 транслируются в права доступа NetWare в гетерогенной среде, состоящей как из серверов и рабочих станций Windows 2000, так и из серверов NetWare.
Разрешения Windows 2000 При доступе из сети разделы FAT и NTFS в Windows 2000 можно защищать на уровне ресурсов. Но защита разделов NTFS в Windows NT поддерживается только на уровне пользователей.
Доверительные права доступа NetWare Защита файлов NetWare аналогична защите файловой системы NTFS, так кап: позволяет управлять в NetWare правами — возможностями групп и пользовать ей в
520
ЧАСТЬ 3
Взаимодействие с другими системами
доступе к файлам. Доверительное право доступа (trustee right) в NetWare, эквивалентное разрешению (permission) в Windows 2000, — это правило, сопоставленное с каким-либо объектом (папкой, файлом или принтером) и определяющее, какие пользователи могут получать доступ к этому объекту и что они могут делать с ним. Разрешения на доступ к объекту обычно устанавливаются его создателем или владельцем. Основное отличие разрешений в Windows 2000 от доверительных прав доступа в NetWare заключается R том, что первые являются ограничительными (subtractive), а вторые — разрешительными (additive). При создании папки или файла Windows 2000 изначально предоставляет полный доступ к этому объекту и лишь потом позволяет ограничивать права на доступ к нему. NetWare делает наоборот: сразу после создания доступ к каталогу или файлу запрещается, и для обращения к нему нужно добавлять требуемые права доступа. Параметры защиты в NetWare задаются комбинацией назначаемых прав и масок наследуемых прав (фильтров). На их основе определяются реальные права доступа к объекту, называемые в NetWare действующими (effective rights). В NetWare возможно восемь типов доступа к каталогам: Read, Write, Create, Erase, Modify, File Scan. Access Control и Supervisor. Эти права описываются в таблице 12-6. Таблица 12-6. Права доступа к каталогам NetWare Право доступа
Описание
Read (R) Чтение данных из существующего файла Write (W) Запись данных в существующий файл Create (С) Создание нового файла или подкаталога Erase (E) Удаление существующих файлов или каталога Modify (M) Переименование или изменение атрибутов файла File Scan (F) Перечисление содержимого каталога Access Control (А) Управление правами других пользователей в доступе к файлам или каталогам Supervisor (S) Автоматически предоставляет все права
Разрешения на доступ к папкам в Windows 2000 и права доступа к каталогам в NetWare В таблице 12-7 сравниваются разрешения па доступ к папкам в Windows 2000 с правами доступа к каталогам в NetWare. Таблица 12-7. Соответствие разрешений на доступ к папке в Windows 2000 и прав доступа к каталогу в NetWare Разрешения на доступ к папке в Windows 2000
Соответствующие права доступа к каталогу в NetWare
List Folder Contents Read Write Modify Full Control
File Scan (F) Read, F i l e Scan (RF) Write, Create, Modify (WCM) Read. Write, Create, Erase, Modify, File Scan (RWCEMF) Supervisor (S)
ГЛАВА 12
Взаимодействие с NetWare
521
Разрешения на доступ к файлам в Windows 2000 и права доступа к файлам в NetWare В таблице 12-8 сравниваются разрешения на доступ к файлам в Windows 2000 с правами доступа к файлам в NetWare. Таблица 12-8. Соответствие разрешений на доступ к файлу в Windows 2000 и прав доступа к файлу в NetWare Разрешения на доступ к файлу в Windows 2000 Соответствующие права доступа к файлу в NetWare Read Modify Full Control
Read (R) Read. Write, Erase, Modify (RWEM) Supervisor (S)
Атрибуты файлов в Windows 2000 и NetWare Атрибуты файлов в NetWare, также называемые флагами, не полностью эквивалентны атрибутам файлов в Windows 2000. Соответствие между ними показано в таблице 12-9 (при открытии какого-либо файла NetWare через Gateway Service for NetWare или Client Service for NetWare). Атрибуты файлов в Windows 2000 представляют собой подмножество атрибутов в NetWare. Windows 2000 не поддерживает дополнительные атрибуты файлов и каталогов NetWare. Таблица 12-9. Атрибуты файлов в Windows 2000 и NetWare Атрибуты файлов в Windows 2000
Атрибуты файлов в NetWare
A (Archive) (архивируемый) S (System) (системный) Н (Hidden) (скрытый) R (Read-only) (только для чтения)
A (Archive needed) (необходимо архивирование) Sy (System file) (системный файл) Н (Hidden) (скрытый) Ro (Read-only) (то.чько для чтения), Di (Delete inhibit) (удаление запрещено), Rj (Rename inhibit) (переименование запрещено)
Gateway Service for NetWare не поддерживает следующие атрибуты файлов в NetWare: DC (Don'l Compress) (не сжимать), Ci (Copy Inhibit) (копирование запрещено), Dm (Don't Migrate) (не переносить), Ic (Immediate Compress) (немедленное сжатие), Р (Purge) (очистка), Ri (Rename Inhibit) (переименование запрещено), Ra (Read A u d i t ) (чтение/аудит), Rw (Read Write) (чтение/запись), S (Sharable) (разделяемый), Т (Transactional) (транзакционный), I (Index) (индекс) и X (Execute Only) (только выполнение). Эти атрибуты могут варьироваться в разных версиях NetWare. Когда Вы копируете файл с клиента Windows на файл-сервер NetWare средствами Client Service for NetWare или Gateway Service for NetWare, его атрибуты A, S, I I и R заменяются соответствующими NetWare-атрибутами — A, Sy, Н и Ro. Если Вам нужно изменить какие-то атрибуты, не поддерживаемые Client Service for NetWare или Gateway Service for NetWare, используйте такие команды NetWare, как filer, rights или flag.
522
ЧАСТЬ 3 Взаимодействие с другими системами
Права доступа к NDS-объектам и свойствам NDS добавляет в систему защиты NetWare права доступа к NDS-объектам и свойствам. В NDS сеть структурируется на основе NDS-объектов, которые представляют собой элементы иерархического дерева NDS. В структуру дерева входят: • корневые объекты в верхушке дерева; • контейнерные объекты, включающие различные организационные единицы; • объекты-листья, например пользователи, группы, серверы и тома. Типы доступа к NDS-объектам могут быть следующими; Supervisor, Browse, Create, Delete и Rename. Свойства содержатся внутри какого-либо объекта и являются атрибутами, представляющими этот объект. Например, объект пользователя может содержать такие свойства, как телефонный номер пользователя, адрес офиса и др. Права доступа к свойствам в NDS реализуются отдельно от прав доступа к объектам. Поэтому Вы можете раздельно настраивать защиту объектов и их свойств. Существует пять типов доступа к свойствам объектов: Supervisor, Compare, Read, Write и Add/Delete Self. Примечание Права доступа к NDS-объектам и свойствам применимы только к томам NetWare в NDS, и Вы можете манипулировать ими лишь при использовании программного обеспечения NetWare.
Доступ к томам NetWare Обращаться к томам NetWare можно либо через графический пользовательский интерфейс Windows 2000, либо через ее интерфейс командной строки. ^ Чтобы подключиться к тому NetWare через графический пользовательский интерфейс: 1. Откройте My Network Places (Мое сетевое окружение). 2. Если в этом окне показываются сетевые ресурсы только компьютеров с Windows 2000 или Windows NT, дважды щелкните сначала Entire Network (Вся сеть), затем NetWare or Compatible Network (Сеть NetWare или совместимая). После этого появятся значки деревьев NDS и компьютеров NetWare. 3. Для просмотра дерева, компьютера или объектов дважды щелкните соответствующий значок. 4. Найдя нужный том или папку, раскройте этот объект двойным щелчком. - Или Для подключения тома или папки как сетевого диска укажите нужный объект и выберите из меню Tools (Сервис) команду Map Network Drive (Подключить сетевой диск). Примечание По умолчанию сетевой диск подключается под именем пользователя и паролем, введенным Вами при регистрации. Чтобы подключиться под другим именем, укажите его в окне Connect As (Подключиться как). Процедуры, представленные ниже, иллюстрируют, как подключиться к тому NetWare через интерфейс командной строки.
ГЛАВА 12
Взаимодействие с NetWare
523
^ Чтобы подключиться к тому, для которого Вы не аутентифицированы: • Введите в командной строке: net use <диск>: /user:.en.ou.ou.о пароль
где сп — общее имя (common name) в NDS, ou — организационная единица и о — организация. ^ Чтобы подключиться к тому, для которого Вы аутентифицированы; • Введите в командной строке: net use <диск>:
Например, чтобы подключить панку \Data\Mydata на томе А сервера В в качестве сетевого диска G с использованием синтаксиса UNC, наберите: net use G: \\B\A\data\mydata
Если на экране появилось сообщение об ошибке «The password is invalid for \\<имя_сервера>\<имя_тома>\\<имя_каталога>...\», значит, Вы ввели неправильное имя пользователя и/или пароль, и Вас нельзя аутентифицировать. Примечание При подключении к файловым ресурсам NetWare через интерфейс командной строки можно использовать первую свободную букву диска, введя в команде вместо конкретной буквы звездочку. Например: net use -
Если Вы хотите, чтобы на экране появлялось приглашение для ввода пароля, замените пароль в команде звездочкой. Когда Вы вводите пароль в строке приглашения, он не отображается на экране.
Использование команд net view Команды net view позволяют просматривать файловые ресурсы NetWare или список серверов в сети. Эти команды аналогичны NetWare-команде slist. ^ Чтобы получить список файл-серверов NetWare: •
Введите в командной строке: net view /network:nw
^ Чтобы просмотреть тома на конкретном файл-сервере NetWare: • Введите в командной строке: net view \\<имя_пн-сервера> /network:nw
Например, для вывода списка томов на NetWare-сервере В наберите: net view \\B /network:nw
^ Чтобы просмотреть содержимое каталога на файл-сервере NetWare под управлением NDS: • Введите в командной строке: dir \\<путь_к_каталогу>
524
ЧАСТЬ 3
Взаимодействие с другими системами
Сценарии регистрации Сценарий регистрации (login script) в NetWare — это список команд, выполняемых всякий раз, когда пользователь входит в сеть NetWare. Сценарии регистрации могут определять настройки по умолчанию для сопоставления дисков, параметров печати и других переменных, определяющих конфигурацию пользовательской среды в сети NetWare. Таким образом, они позволяют Вам создавать согласованную и продуманную среду для конкретного пользователя. Сценарии регистрации размешаются па серверах NetWare и выполняются, когда Вы обращаетесь к ресурсам NetWare через Client Service for NetWare (Службу клиента для сетей NetWare) или Gateway Service for NetWare (Службу шлюза для NetWare). Если Вы хотите использовать сценарий регистрации для настройки неременных в сети NetWare при каждом подключении к ней пользователя, установите флажок Run Login Script (Выполнять сценарий входа) в диалоговом окне Client Service for NetWare (Служба клиента для сетей NetWare) или Gateway Service for NetWare (Служба шлюза для NetWare). Когда Вы активизируете этот флажок в диалоговом окне Gateway Service for NetWare, сценарий регистрации запускается при входе на компьютер со службой шлюза. Значения переменных в таком сценарии применяются ко всем пользователям, которые обращаются к сети NetWare через Gateway Service for NetWare. А когда Вы устанавливаете аналогичный флажок в диалоговом окне Client Service for NetWare, сценарий регистрации запускается при аутентификации пользователя в сети NetWare, и значения его переменных применяются лишь к данному пользователю. Серверы NetWare na основе регистрационной базы данных и NDS работают с разными сценариями. Первые поддерживают системные и пользовательские сценарии регистрации, которые выполняются соответственно на общесистемном и пользовательском уровне. Системные сценарии устанавливают значения переменных для всех пользователей сервера. NDS поддерживает сценарии регистрации четырех типов, выполняемые последовательно для задания прав доступа к сервисам на уровне контейнера, профиля и пользователя. Вот что представляют собой эти сценарии. •
Сценарий контейнера NDS аналогичен системному сценарию в версиях NetWare па основе регистрационной базы данных, но устанавливает глобальные переменные на уровне контейнера. • Сценарий профиля NDS позволяет устанавливать переменные для пользователей, которым нужен одинаковый доступ к конкретным приложениям. •
Пользовательский сценарий позволяет настраивать значения переменных для индивидуальных пользователей. • Стандартный сценарий выполняется в отсутствие пользовательского сценария. Подробную информацию о сценариях регистрации см. в документации NetWare; об устранении проблем со сценариями регистрации при доступе через Gateway Service for NetWare или Client Service for NetWare см. раздел «Проблемы со сценариями регистрации» далее и этой главе.
ГЛАВА 12
Взаимодействие с NetWare
525
Выявление и устранение проблем В следующих разделах поясняется, как устранять наиболее распространенные проблемы, связанные с неправильной конфигурацией служб и ошибками в сценариях регистрации, а также описываются средства диагностики.
Средства диагностики С Windows 2000 поставляются средства диагностики, позволяющие определят];, настройки компьютеров и находить причины проблем с коммуникационной связью. Ipxroute config. Эта команда помогает выявлять и устранять проблемы с поддержкой IPX-соединений, а также предоставляет информацию о текущем состоянии стека IPX. Для использования этой команды введите ipxroute config. Ipxroute ripout. Эта команда с помощью R1P определяет, возможно ли соединение с указанной сетью. Для использования этой команды введите ipxroute ripout <помер_сети>. Network Monitor (Сетевой монитор). Эта утилита позволяет выявлять и устранять проблемы в LAN- и WAN-сетях, в том числе при соединениях удаленного доступа. С помощью Network Monitor можно идентифицировать сетевой трафик различных типов и проблемы в сети. Например, Вы можете локализовать причины проблем с соединениями между клиентами и серверами, находить компьютер, генерирующий слишком большое количество запросов, захватывать кадры (пакеты) непосредственно из сети, просматривать их содержимое (в том числе с применением фильтров) и обнаруживать неавторизованных пользователей. В Windows 2000 Server включена версия Network Monitor, которая дает возможность захватывать трафик, передаваемый или принимаемый локальным компьютером. Эта версия не поставляется с Windows 2000 Professional. Подробнее о мониторинге сети см. книгу «Сопровождение сервера» из серии «Ресурсы Microsoft Windows 2000 Server».
Наиболее распространенные проблемы Большинство проблем с соединениями между Windows 2000 и NetWare вызвано неправильной настройкой. Если при соединении с сетью NetWare проявляется любой из перечисленных ниже симптомов, причина Ваших проблем связана скорее всего с ошибками в настройке. •
Доступ к приложениям на серверах NetWare не разрешается.
• Программы не работают и выдают сообщения об ошибках. • •
Скорость передачи данных слишком мала. Пользователям сообщается об ошибке «Server not found» («Сервер не найден»).
•
Пользователям не предоставляется доступ к сетевым ресурсам на серверах NetWare.
• •
Доступ к ресурсам NetWare ограничен. Некоторые клиенты могут обращаться к сервисам NetWare, другие — нет.
•
К серверам Windows 2000 и Windows NT подключиться удается, а к серверам NetWare — нет.
526
ЧАСТЬ 3 Взаимодействие с другими системами
• К одним серверам NetWare подключиться можно, к другим — нет. Поскольку для поддержки соединений нужны ресурсы как Windows 2000, так и NetWare. Вы должны корректно настроить обе системы. Прежде всего убедитесь в правильности настройки доступа к ресурсам NetWare на самих файл-еерверах NetWare. Вам придется проверить массу различных параметров, набор которых зависит от конкретной проблемы и степени ее тяжести. Проверьте: •
правильно ли настроены пользовательские учетные записи на файл-сервере NetWare; • созданы ли необходимые группы; • верно ли указано членство в группах; • корректны ли права доступа к требуемым ресурсам. Примечание О настройке параметров NetWare см. в документации NetWare. Если Вы убедились в правильности конфигураций файл-серверов NetWare и прав доступа к их ресурсам, а проблема все еще не решена, проверьте конфигурацию компьютера с Windows 2000. При этом придерживайтесь схемы, представленной на рис. 12-17. Детальное описание каждой процедуры Вы найдете в следующих разделах. Установлены ли NWLink и служба шлюза или клиента для NetWare? Чтобы клиент или сервер под управлением Windows 2000 мог обращаться к серверам NetWare, на компьютере с Windows 2000 нужно установить Gateway Service for NetWare (Служба шлюза для NetWare) или Client Service for NetWare (Служба клиента для сетей NetWare). NWLink устанавливается автоматически при установке службы шлюза или клиента. ^ Чтобы проверить, установлены ли NWLink и служба шлюза или клиента: 1. Последовательно раскройте значки My Computer (Мой компьютер), Control Panel (Панель управления) и Network and Dial-up Connections (Сеть и удаленный доступ к сети). 2. В появившемся окне щелкните правой кнопкой мыши значок нужного соединения и выберите команду Properties (Свойства), 3. В окне свойств соединения проверьте, присутствуют ли в списке NWLink и либо Gateway Service for NetWare (Служба шлюза для NetWare), либо Client Service for NetWare (Служба клиента для сетей NetWare). Подробнее об установке Client Service for NetWare или Gateway Service for NetWare см. раздел «Настройка служб шлюза и клиента» ранее в этой главе. Правильно ли заданы тип кадров и номера сетей? Когда Вы устанавливаете службу шлюза или клиента для NetWare и NWLink, функция Auto Detect активизируется автоматически. Подробнее об Auto Detect см. раздел «NWLink-функция Auto Detect» ранее в этой главе. В большинстве случаев Auto Detect правильно определяет тип кадров и номер сети. Однако эта функция может давать ошибочную информацию, если в сети используется несколько типов кадров или если Вы сами установили неправильный тип кадров. Если NWLink не распознает сетевой трафик, он выбирает тип кадров 802.2.
-' CffJJ-
ГЛАВА 12
Взаимодействие с NetWare
529
^ Чтобы определить, синхронизированы ли имя и пароль пользователя: 1. Используя имя и пароль, не вызывающие проблемы с доступом, войдите в сеть с компьютера под управлением Windows 2000 Professional, на котором такая проблема есть. 2. Если альтернативная учетная запись позволяет получить доступ к нужным сетевым ресурсам, значит, исходная учетная запись требует синхронизации в сети. Совет Для автоматической модификации клиентского пароля на серверах Windows 2000 и NetWare используйте вкладку Change Password (Смена пароля) в окне свойств паролей на клиенте под управлением Windows 2000 Professional. Не повреждены ди файлы NWLink и службы шлюза или клиента для NetWare? Иногда файлы копируются с ошибками или повреждаются по какой-то другой тричине. !*• Чтобы проверить, не повреждены ли файлы: 1.
Проверьте временные метки и размеры файлов, созданных при установке NWLink и службы шлюза или клиента на клиенте или сервере Windows 2000, на котором Вы подозреваете наличие поврежденных файлов.
Список файлов, устанавливаемых при установке Gateway Service for NetWare или Client Service for NetWare на компьютере под управлением Windows 2000, см. в разделах «NWLink» и «Службы шлюза и клиента для NetWare» ранее в этой главе. 2. Проверьте, идентичны ли они временным меткам и размерам файлов на клиенте или сервере Windows 2000, работающем без проблем. Если временные метки или размеры этих файлов не идентичны, то скорее всего Ваши файлы повреждены. I* Чтобы устранить проблему, вызванную повреждением файлов: В окне свойств сетевого соединения выберите Client Service for NetWare (Служба клиента для сетей NetWare) па компьютере с Windows 2000 Professional или Gateway (and Client) Services for NetWare [Службы шлюза (и клиента) для NetWare] на компьютере с Windows 2000 Server, а затем щелкните кнопку Uninstall (Удалить) и кнопку ОК. 2. Убедитесь, что все файлы NWLink и Gateway Service for NetWare или Client Service for NetWare удалены. Если какие-то файлы остались, не удаляйте их, а переименуйте, заменяя расширение па ,bak. 3. Переустановите Gateway Service for NetWare или Client Service for NetWare. 1.
Проблемы со сценариями регистрации Сценарии регистрации (login scripts) создают пользовательскую среду на серверах NetWare и применяются при доступе к этим серверам. Задаваемые в них пастрийки должны быть корректны, чтобы обеспечить оптимальную производительность. Ниже перечислены некоторые проблемы, с которыми Вы можете столкнуться при активизации таких сценариев через Client Service for NetWare или Gateway Ser\ice for NetWare. I 8 3 a t c 3343
530
ЧАСТЬ 3
Взаимодействие с другими системами
Команда СХ Когда сценарий регистрации пытается изменить контекст, используя относительный путь, появляется сообщение об ошибке «The context you want to change to does not exist» («контекст, на который Вы хотите сменить текущий, отсутствует»). Сценарии регистрации NetWare обрабатываются Nwscript.exe. Смена контекста осуществляется командой СХ, и в данном случае она используется в виде «ex ..». Такая команда должны была бы установить контекст, находящийся в иерархии NDS на один уровень выше текущего. Но вместо этого пользователь получает уже упомянутое сообщение об ошибке. Чтобы устранить эту проблему, используйте в сценариях регистрации только абсолютные пути, например: ex .somecontainer
Команда Capture Когда сценарий регистрации выполняет показанную ниже строку, сообщается об ошибке 255 в строке 668 файла Spool.с. «COMMAND /с CAPTURE /$=имя_сервера /й=имя_очередн
Замените эту строку на: ((CAPTURE /$=<иня_сервера> /й=<имя_очереди>
Примечание CaptuTe.exe не относится к числу поддерживаемых утилит и часто не срабатывает при запуске через интерфейс командной строки. Обработчик сценариев регистрации на самом деле не выполняет команду Capture. Он лишь разбирает ее синтаксис и запускает реальный файл Capture.exe.
Другие распространенные проблемы Кроме проблем с соединениями между NetWare и Windows 2000, связанных с корректностью параметров и сценариев регистрации, Вы можете столкнуться и с другими проблемами, кратко описанными ниже. Служба шлюза или клиента создает несколько лицензированных соединений с NDS-серверами Если у Вас имеется дерево NDS, в которое входит более одного сервера NetWare, то Вы могли бы использовать несколько лицензированных соединений (multiple licensed connections), подключаясь к одному из серверов для аутентификации (и входа) и в дальнейшем отображая соединения с помощью сценария регистрации на другой сервер. Если Вы так и делаете, то превышаете число лицензированных Novell соединений в два раза по сравнению с необходимым. О том, как решить эту проблему, см. ссылку Microsoft Knowledge Base на странице Web Resources (http://windows.microsoft.com/windows2000/reskit/webresources). Проведите поиск в Knowledge Base no ключевым словам «connect to multiple servers» и «NDS». Компьютеры с Windows 2000 не могут соединяться с другими Windows-клиентами По умолчанию компьютеры под упраилснием Windows 95 и Windows 98 используют прямой хостинг для IPX/SPX на клиентской и серверной сторонах. Прямой
ГЛАВА 12
Взаимодействие с NetWare
531
хостинг (direct hosting) — это функциональность, позволяющая компьютерам взаимодействовать по IPX в обход уровня NetBIOS. Windows 2000 поддерживает прямой хостинг только на серверной стороне. Поэтому клиенты Windows for Workgroups, Windows 95 или Windows 98, работающие лишь с протоколами IPX/SPX, могут подключаться к серверу Windows 2000, а аналогичный клиент Windows 2000 — нет. Для решения этой проблемы нужно включить поддержку NetBIOS на клиенте Windows 2000 и компьютере с Windows 2000 Server.
Дополнительные материалы Более подробную информацию о синхронизации паролей с серверами NetWare 4.x см. по ссылке: •
Novell на странице Web Resources (http://windows.microsoft.com/windows2000/ reskit/webrcsources).
ГЛАВА
13
Services for Macintosh
Services for Macintosh (Службы интеграции с сетью AppleTalk) — это компонент Windows 2000, который обеспечивает интеграцию сетей на основе Windows 2000 и Macintosh, а также позволяет клиентам этих платформ обмениваться файлами и совместно использовать принтеры. Кроме того, с помощью Services for Macintosh клиенты Windows 2000 и Macintosh могут получать доступ к удаленным сетям через службу маршрутизации и удаленного доступа Windows 2000 Server. В этой главе Обзор 532 AppleTalk 533 Сети AppleTalk и маршрутизация File Services for Macintosh 543 Print Server for Macintosh 555 Удаленный доступ
535
560
Выявление и устранение проблем
561
См. также • Подробнее об удаленном доступе — главу 7 «Сервер удаленного доступа» в этой книге. • Подробнее о маршрутизации — главу 2 «Служба маршрутизации и удаленного доступа» в этой книге. • Подробнее о TCP/IP — главу 1 «Введение в TCP/IP» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server»,
Обзор Services for Macintosh в Windows 2000 — мощная платформа межсетевого взаимодействия Macintosh и Windows 2000. Он позволяет клиентам Windows 2000 и Apple Macintosh обмениваться файлами по TCP/IP-сетям и обеспечивает им доступ к серверу печати по сети AppleTalk. Кроме того, он предоставляет клиентам Macin-
ГЛАВА 13
Services for Macintosh
533
tosh сервисы AppleTalk, например AppleTalk Routing. Пользователи Macintosh могут соединяться с сервером Windows 2000 и получать удаленный доступ к сети AppleTalk через РРР-клиент (Point-to-Point Protocol), поддерживающий АТСР (AppleTalk Control Protocol). Services for Macintosh также поддерживает шифрование и другие вилы защиты. Если па клиенте Macintosh установлен MS-UAM (Microsoft User Authentication Method), он может входить на сервер Windows 2000 практически так же, как и клиенты Windows 2000. Services for Macintosh полностью поддерживает протокол и маршрутизатор AppleTalk Phase 2. Стек протоколов AppleTalk представляет собой нижележащий механизм, который обеспечивает коммуникационное взаимодействие между File Services for Macintosh (Файловый сервер для Macintosh), Print Server for Macintosh (Сервер печати для Macintosh) и сетью, объединяющей компьютеры Macintosh. Функциональность Services for Macintosh в Windows 2000 показана л таблице 13-1. Таблица 13-1. Функциональность Services for Macintosh в Windows 2000 Функциональность
Описание
File Services for Macintosh
Поддерживает AppleTalk Filing Protocol поверх TCP/IP и AppleTalk Print Server for Macintosh Предоставляет доступ к PostScript-принтерам, подключенным к сети AppleTalk, или любым другим принтерам, подключенным к серверу Windows 2000 Безопасный вход на основе MS-UAM Реализует для пользователей Macintosh такую жг сетевую защиту, как и для пользователей Windows 2000 Apple Standard UAM Поддерживает шифрованные и нешифрованные (User Authentication Method) пароли Поддержка AppleTalk Phase 2 Поддерживает новейшую версию AppleTalk Удаленный доступ па счет поддержки Клиенты Macintosh могут использовать РРР для АТСР (AppleTalk Control Protocol) удаленного доступа к серверам и одновременного входа в сети AppleTalk и TCP/IP Поддержка Plug and Play Изменения, вносимые в Services for Macintosh через пользовательский интерфейс (например, включение гостевой учетной записи или перенастройка сетевой конфигурации), реализуются автоматически, без перезагрузки компьютера Полностью интегрируемые в консоль Обеспечивают централизованное управление ММС административные средства Disk Quotas (дисковые квоты) Позволяют управлять дисковым пространством, выделяемым под тома NTFS (файловой системы Windows 2000); если эта функция активна, систем • ный администратор может вводить ограничения H.;I объемы дискового пространства на сервере, выделяемые индивидуальным пользователям для хранении их данных
AppleTalk AppleTalk — сетевая система, разработанная Apple Computer. Она базируется па архитектуре протоколов AppleTalk, которая определяет, как именно реализуется возможность соединений в сетевой системе. AppleTalk Pha.sc 2 поддерживает сети
534
ЧАСТЬ 3 Взаимодействие с другими системами
AppleTalk более чем с 254 узлами, несколькими зонами на каждую сеть и межсетевой маршрутизатор AppleTalk, а также обеспечивает расширенную поддержку Ethernet и Token Ring. Более детально функциональность AppleTalk Phase 2 рассматривается в следующем разделе. Архитектура протоколов AppleTalk представлена на рис. 13-1.
AppleTalk Data Stream Protocol (ADSP) Routing Table Maintenance Protocol (RTMP)
Zone Information Protocol (ZIP) AppleTalk Echo Protocoi (AEP)
AppleTalk Filing Protocoi (AFP)
PostScript
AppleTalk Sesslcm Protocol (ASP)
Printer Access Protocoi (PftP)
AppleTalk Transaction Рго(оеоЦАТР)
Name Binding Protocol (HBP)
Datagram Delivery Protocol (DDP)
Token Taik Link Access Protocol (TLAP)
EtherTalk Link Access Protocol (ELAP)
LocaiTalk Link Access Protocol (LLAP)
Оборудование Token Ring
Оборудование Ethernet
Оборудование UcafTalk
Рис. 13-1. Архитектура протоколов AppleTalk Протоколы, показанные на каждом уровне этой схемы (рис. 13-1), опираются на сервисы протоколов более низкого уровня и предоставляют сервисы протоколам более высокого уровня. Они обеспечивают возможность соединений, маршрутизацию, межсетевое взаимодействие, надежную доставку данных, обмен сообщениями между двумя процессами или приложениями и форматирование данных (таблица 13-2). Таблица 13-2. Протоколы AppleTalk Протокол
Описание
DDP (Datagram Delivery Protocol)
Обеспечивает ненадежную доставку пакетов данных, не гарантируя правильную их последовательность Используется маршрутизаторами для обмена информацией о маршрутах Применяется для проверки возможности соединения с какой-либо системой и для определения времени полной передачи пакетов
RTMP (Routing Table Maintenance Protocol) AEP (AppleTalk Echo Protocol)
ГЛАВА 13 Таблица 13-2. Протокол
Services for Macintosh
535
(продолжение) Описание
ATP (AppleTalk Transaction Protocol) Обеспечивает надежную доставку пакетов данных NBP (Name Binding Protocol) Предоставляет сервис трансляции имен, который преобразует имя устройства в AppleTalk-адрес ADSP (AppieTalk Data Stream Обеспечивает надежную, полнодуплексную передачу Protocol) данных между двумя сокетами в сети AppleTalk ZIP (Zone Information Protocol) Поддерживает сопоставление диапазонов номеров сетей с именами зон в межсетевой среде ASP (AppleTalk Session Protocol) Обеспечивает надежную передачу данных без дублирования; отвечает за установление сеанса свяли между двумя программами и его последующее завершение PAP (Printer Access Protocol) Обеспечивает надежную передачу сообщений; отвечает за согласование параметров соединения, егп поддержание и завершение AFP (AppleTalk Filing Protocol) Предоставляет интерфейс между приложением и файл-сервером; позволяет рабочей станции в сеш AppleTalk получать доступ к файлам на файл-сервере AFP
Сети AppleTalk и маршрутизация Перед настройкой Services for Macintosh на компьютере с Windows 2000 Server примите во внимание соображения, изложенные в этом разделе. Внимание File Services for Macintosh может работать через TCP/IP-сеть, поэтому Вам не обязательно использовать AppleTalk. Информацию о TCP/IP см. в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». Windows 2000 поддерживает стек протоколов AppleTalk и соответствующее программное обеспечение для маршрутизации, поэтому сервер Windows 2000 может подключаться к AppleTalk-сетям Macintosh и реализовать для них маршрутизацию. Крупные сети AppleTalk, как правило, представляют собой межсетевые AppleTalkсреды, которые содержат физические сети меньшего размера, связанные между собой маршрутизаторами. Сервер Windows 2000 поддерживает как маршрутизацию, так и подготовку сетей к маршрутизации — инициализацию (seed routing). На компьютере с Windows 2000 Server можно установить неограниченное количество сетевых адаптеров и подключить его к сети AppleTalk, которая состоит из множества физических сетей меньшего размера, соединенных маршрутизаторами. Компьютеры, находящиеся в разных физических сетях, взаимодействовать без маршрутизаторов не могут. Некоторые из маршуртизаторов являются инициирующими (seed routers). Т? кие маршрутизаторы инициализируют и широковещательно рассылают информаци ю о маршрутах в одной иди нескольких напрямую подключенных к ним физических сетях. Эта информация сообщает маршрутизаторам, куда направлять каждый пакет данных. В каждой физической сети должен быть минимум один инициирующий маршрутизатор, который широковещательно распространяет информацию о маршрутах в этой сети.
536
ЧАСТЬ 3
Взаимодействие с другими системами
Не все маршрутизаторы должны быть инициирующими. Маршрутизаторы, которые не являются инициирующими, поддерживают карту физических сетей, пересылают информацию о маршрутах, отслеживают и перенаправляют пакеты данных в сетях AppleTalk. Инициирующие маршрутизаторы выполняют тс же функции плюс иницииализируют информацию о маршрутах (в том числе номера сетей и списки зон) для одной или нескольких физических сетей. Номер сети (network number) или диапазон номеров сети (network range) — это адрес или диапазон адресов, назначенных этой сети. Номер сети уникален и идентифицирует конкретную физическую сеть AppleTalk. Располагая информацией о номерах и диапазонах сетей, маршрутизаторы передают входящие данные в нужную физическую сеть. Номер сети может быть любым числом от 1 до 65279. Сетям LocalTalk можно присваивать только по одному номеру, а сетям Ether Talk, TokenTalk и FDD1 — диапазоны. Подробнее о маршрутизации см. главу 2 «Служба маршрутизации и удаленного доступа» в этой книге.
Особенности AppleTalk Phase 2 AppleTalk поддерживает следующую функциональность Phase 2. •
Сети LocalTalk с единственным номером могут содержать максимум 254 узла. (На практике они ограничены 32 узлами и менее из-за низкой пропускной способности несущей среды.)
•
Сети EtherTalk и TokenTalk, которым можно присваивать диапазоны номеров, способны объединять гораздо большее количество узлов. В этих сетях на каждый номер из диапазона приходится до 253 узлов, а общее количество узлов не должно превышать 16,5 миллионов. • В каждой сети LocalTalk может быть только одна зона, а в каждой сети KtherTalk или TokenTalk — множество зон (конкретный узел может входить в любую из зон сети).
Проектирование сети Прежде чем настраивать AppleTalk на компьютере с Windows 2000 Server, следует продумать плац своей сети. При этом придерживайтесь такой схемы: •
определите, какой маршрутизатор должен быть инициирующим в каждой сети;
• • •
выберите номера и диапазоны номеров сетей; определитесь с группированием узлов по зонам; создайте схему размещения маршрутизаторов.
Инициирующие маршрутизаторы Устанавливая сервер Windows 2000 и настраивая на нем AppleTalk, нужно решить, будет ли данный компьютер инициализировать физические сети, к которым он подключен. Например, компьютер под управлением Windows 2000 Server, подключенный к трем физическим сетям AppleTalk, может выступать в роли инициирующего маршрутизатора только в двух сетях. Для сетей, инициализируемых сервером, следует указать информацию, необходимую для маршрутизации. Тогда сервер будет работать как инициирующий маршрутизатор, распространяя в этих сетях заданную Вами информацию. Если же Вы
ГЛАВД 13
Services for Macintosh
537
предпочитаете, чтобы данный сервер функционировал как обычный маршрутизатор, позаботьтесь о подключении к этим сетям других маршрутизаторов ApplcTalk, которые будут использоваться в качестве инициирующих.
Несколько инициирующих маршрутизаторов в одной сети Для большей надежности в одной физической сети можно установить несколько инициирующих маршрутизаторов. В этом случае все инициирующие маршрутизаторы в конкретной сети должны распространять в ней одну и ту же информацию. При запуске сети реальным инициирующим маршрутизатором становится тот, который начал работать первым. Кроме того, всегда используется информация, заданная на первом инициирующем маршрутизаторе, — даже если она отличается от сведений на других маршрутизаторах этого типа. Windows 2000 Server действует по такому алгоритму: если через некое время включается инициирутощий маршрутизатор с другой информацией, конфликтующие данные игнорируются, в системном журнале отмечается соответствующее событие, и этот маршрутизатор больше не считается инициирующим. Маршрутизаторы под управлением операционных систем, отличных от Microsoft, могут вести себя иначе,
Размещение инициирующего маршрутизатора в сети Планируя большую смешанную сеть, полезно составить схему сети Apple-Talk, продумать структуру физических сетей и точки их соединения. Пример сети Apple Talk показан на рис. 13-2.
Ethernet2
Ethernetсеть 1
LocalTalkсеть 2 LocalTalkсеть 1 Рис. 13-2. Пример сети AppleTalk
538
ЧАСТЬ 3
Взаимодействие с другими системами
Допустим, у Вас имеется сеть с шестью компьютерами, работающими под управлением Windows 2000 Server. Вы должны решить, какие серверы будут инициализировать каждую сеть. • Инициирующим маршрутизатором для Ethernet-сети 1 может быть сервер 1, 2, 3 или 4. • Инициирующим маршрутизатором для Ethernet-сети 2 может быть сервер 4 или 5. • •
Инициирующим маршрутизатором для Ethernet-сети З может быть сервер 5 или 6. Инициирующим маршрутизатором для LocalTalk-сети 2 может быть только сервер 5, поскольку это единственный маршрутизатор, доступный для данной сети. По аналогичной причине сервер 3 должен инициализировать LocalTalk-ееть 1.
Присвоение сетям номеров и диапазонов номеров Присвоение диапазона номеров является частью инициализации сети. Каждой сети AppIeTalk внутри смешанной сети назначается диапазон номеров. Каждый AppleTalk-узел определяется по одному из этих номеров в сочетании с динамически назначаемым идентификационным номером (далее — номер узла), Выбирая номера и диапазоны номеров сетей, придерживайтесь следующих правил. • •
Используйте номера сетей так, чтобы у Вас оставался запас на будущее. Указывая диапазоны номеров сетей, исходите из ожидаемого в будущем числа узлов в каждой сети. Общее число Apple Talk-узлов может быть в 253 раза больше количества номеров сетей в диапазоне. • Сети LocalTalk можно назначить единственный номер, а сети Ethernet или Token Ring — диапазон номеров. Диапазон не должен быть равен нулю. •
Номер или диапазон номеров должен быть уникален для данной физической сети.
•
Номера в одном из диапазонов не должны перекрываться с номерами в других диапазонах.
Зоны Зона — это логическая группа узлов, которая упрощает просмотр ресурсов в сети (серверов, принтеров и т. д.). В сетях LocalTalk каждая физическая сеть может быть сопоставлена только с одной зоной, а в сетях EtherTalk, TbkenTalk и FDDI — со множеством зон. Каждая зона в сетях EtherTalk, TokenTalk или FDDI может включать серверы и принтеры одной или нескольких физических сетей. Каждый компьютер Macintosh получает доступ к серверам и принтерам в любой зоне сети, даже если сам клиент включен только в одну зону. Вообще говоря, зоны значительно упрощают пользователям доступ к сетевым ресурсам. Если пользователи просматриваю! сеть с помощью Chooser, они видят ресурсы лишь в одной зоне единовременно, что лишает их полноценной навигации в больших сетях и затрудняет поиск нужных ресурсов. Клиенты, серверы и принтеры, с которыми работает единственная группа, можно включить в одну зону — тогда пользователи будут видеть, какие ресурсы задействованы наиболее интенсивно, и в то же время при необходимости они смогут обращаться к ресурсам в других зонах. Список зон включает все зоны, сопоставленные с данной сетью. Одна из них считается зоной по умолчанию (default zone), к которой изначально приписываются
ГЛАВА 13 Services for Macintosh
539
все клиенты Macintosh. Однако пользователи мснут так настроить клиент, чтобы он находился в какой-нибудь другой зоне.
Создание зон в сети Задание зонной информации тоже является частью инициализации сети. Зоны AppleTalk идентифицируются по именам. Вы можете просматривать текущий список зон, добавлять и удалять зоны, а также указывать зону по умолчанию. В последнюю включаются все устройства AppleTalk, еще не отнесенные к какой-либо другой зоне. Присваивая имена зонам, соблюдайте следующие правила. • В каждой физической сети LocalTalk присвойте имя одной зоне, а в каждой сети Ethernet или Token Ring — одной или нескольким зонам. Имя зоны может быть длиной до 31 символа. Символы звездочки в имени зоны недопустимы. • В каждой сети Ethernet и Token Ring выберите зону, которая будет зоной по умолчанию. • Выбор числа зон в межсетевой среде зависит от ее размера. Если эта среда невелика, достаточно одной зоны. При наличии единственной сети Ethernet или Token Ring типа Phase 2, которая охватывает большую территорию или содержит большое количество устройств AppleTalk, определите несколько зон, чтобы упростить пользователям поиск нужных устройств.
Создание плана размещения маршрутизаторов Спроектировав свою сеть, составьте план размещения маршрутизаторов, который отражает местонахождение и тип каждого инициирующего маршрутизатора. Чтобы составить план размещения маршрутизаторов, определите: • количество устройств AppleTalk в сетях Ethernet и Token Ring — сейчас и в будущем; • число номеров сетей, соответствующее Вашим потребностям и пропускной способности сети. (Возможна поддержка максимум п X 253 устройств, где п — число номеров сетей в диалазортс.) Пример плана размещения маршрутизаторов (для схемы на рис. 13-2) показан в таблице 13-3. Сохраните следующую информацию о своей сети — она пригодится для обслуживания. • Местонахождение маршрутизатора: • физическое размещение; • имя серверного компьютера, если машрутизатором является компьютер с Windows 2000 Server и AppleTalk. • Тип и версия маршрутизатора. • Физические сети, к которым подключен маршрутизатор. При этом внесите следующие сведения для каждой сети: • •
маркировку кабелей; тип несущей среды;
ЧАСТЬ 3 Взаимодействие с другими системами
540 •
номера сетей;
•
имена зон;
• зона по умолчанию; •
является ли данный маршрутизатор инициирующим для сетей, к которым он подключен.
Таблица 13-3. Пример плана размещения инициирующих маршрутизаторов Маркировка кабеля Ethernet #1
Диапазон номеров сети 16-25
Ethernet #2
32-37
Ethernet #3 LocalTalk #1 LocalTalk #2
768 1024 1280
Список зон
Инициирующие устройства'
2
Finance Accounts Payable Accounts Receivable Marketing 2 Marketing Exec Engineering2 Finance Marketing
Сервер 1 Сервер З Сервер 5 Сервер 6 Сервер 3 Сервера
В информацию об инициирующем устройстве может входить имя сервера, тип специализированного аппаратного маршрутизатора и его физическое местонахождение. Указывает зону по умолчанию в данной сети,
Планирование сетевой среды При планировании физических подключений между компьютерами Windows 2000 и Macintosh следует прежде всего выбрать подходящую несущую среду. Каждый тин несущей среды требует применения специфических кабелей, своей топологии и определенного сетевого оборудования. Сервер Windows 2000 поддерживает несущие среды шести типов; • Ethernet; •
Token Ring;
•
FDDI (Fiber Distributed Data Interface);
•
LocalTalk;
•
CDDI (Copper Distributed Data Interface);
• ATM.
.
Ethernet, Token Ring и FDDI — наиболее распространенные несущие среды. LocalTalk используется только в сетях ApplcTalk. На каждом компьютере Macintosh имеется аппаратно-программное обеспечение, позволяющее ему работать в сети LocalTalk в качестве клиента. Если в сети применяется Ethernet, никаких изменений в аппаратно-программной конфигурации таких компьютеров не требуется. Если в сети применяется LocalTalk, нужно установить сетевую плату LocalTalk. Если клиент Macintosh использует и LocalTalk, и Ethernet, активизируйте поддержку маршрутизации. Допустим, сервер и клиенты Windows 2000 используют Ethernet, а клиенты Macintosh еще не подключены к сети (т. е. они имеют встроенное аппаратно-программное обеспечение LocalTalk). Чтобы компьютеры под управлением Windows 2000
ГЛАВА 13
Services for Macintosh
541
Server могли взаимодействовать с компьютерами Macintosh, выберите один из вариантов, рассматриваемых в следующих разделах.
Установка Ethernet-плат Установите Ethernet-платы на каждом компьютере Macintosh, а затем подключите эти платы к существующей сети Ethernet. Сервер использует имеющуюся у него Ethernet-плату для взаимодействия со всеми клиентами (Windows 2000 и Macintosh), которые подключены к единственной сети Ethernet. Пример такой сети показан на рис. 13-3.
Windows 2000 Server с клиентами Macintosh в сети Ethernet
Рис. 13-3. Сеть Ethernet с сервером Windows 2000 и клиентами Macintosh
Установка LocalTalk-плат Установите на сервере плату сетевого адаптера LocalTalk (в дополнение к уже установленной па нем Ethernet-плате). Тогда Вы сможете объединить компьютеры Macintosh в сеть LocalTalk и подключить ее к новой LocalTalk-плате сервера. Сервер взаимодействует с компьютерами Macintosh через LocalTalk. Пример такой сети показан на рис. 13-4.
LocalTalk
Windows 2000 Server с Ethernet и LocalTalkплатами
Ethernet
Рис. 13-4. Сервер Windows 2000 с Ethernet- и LocalTalk-платами Этот вариант требует единственной дополнительной сетевой платы. Однако LocalTalk работает медленнее Ethernet, что отрицательно повлияет на производительность сети. Поскольку возможности сети LocalTalk очень ограниченны, этот вариант непрактичен, если у Вас имеется достаточно много компьютеров Macintosh,
Установка Ethernet/LocalTalk-маршрутизатора Ethernet/LocalTalk-маршрутизатор транслирует данные между двумя несущими средами. Сервер Windows 2000, работающий с Services for Macintosh, также может
542
ЧАСТЬ 3 Взаимодействие с другими системами
выступать в роли маршрутизатора между Ethernet и LocalTalk. Но в этом случае на нем должны быть установлены сетевые платы Ethernet и LocalTalk. Даже используя Ethernet/LocalTalk-маршрутизатор, сервер может по-прежнему работать со своей Ethernet-платой. Вы размещаете клиенты Macintosh в сети LocalTalk и подключаете маршрутизатор к обеим сетям — Ethernet и LocalTalk. Через этот маршрутизатор проходят все данные, передаваемые между сервером и клиентами Macintosh. С точки зрения сервера, все компьютеры Macintosh подключены к сети Ethernet. Этот тип сети иллюстрирует рис. 13-5.
Сервер Windows 2000
Ethernel/LocalTalkмаршрутизатор
LocalTalk
Рис. 13-5. Ethernet/LocaiTalk-маршрутизатор Чтобы задействовать Ethernet/LocalTalk-маршрутизатор, Вы должны выполнить привязку протокола AppleTalk на сервере к его Ethernet-плате. Этот вариант удобен, если Вы хотите сделать принтеры в сети Ethernet доступными клиентам Macintosh; однако LocalTaIk-часть маршрутизатора приведет к падению общей производительности. Примечание Поскольку компьютер под управлением Windows 2000 Server может функционировать в качестве маршрутизатора, он способен работать и как Ethernet/ LocalTalk-маршрутизатор — если только у него есть сетевой адаптер Ethernet и LocalTalk-плата. Чтобы подключить одну физическую сеть из компьютеров Macintosh к нескольким серверам» Вы можете установить LocalTalk-плату только на одном из серверов, и он будет действовать в качестве маршрутизатора. После этого клиенты Macintosh смогут обращаться к другим серверам по Ethernet.
Примеры более сложных физических сетей Б зависимости от состава клиентов в сети Вы можете столкнуться с более сложными проблемами их подключения, чем те, о которых шла речь до сих пор. Следующие два примера предлагают решения именно таких проблем. •
Сервер Windows 2000 использует Ethernet, но одни компьютеры Macintosh работают с Ethernet, а другие — с LocalTalk.
ГЛАВА 13
Services for Macintosh
543
Вы можете установить LocalTalk-плату на компьютере с Windows 2000 Server, чтобы он взаимодействовал с клиентами Macintosh, использующими LocalTalk, установить Ether net- платы на все клиенты Macintosh или задействовать Ethernet/LocalTalk-маршрутизатор. • Сервер Windows 2000 использует Ethernet, но некоторые компьютеры Macintosh работают либо только с Ethernet, либо только с LocalTalk. Кроме того, на некоторых, компьютерах Macintosh установлены сетевые платы Token Ring. В дополнение к первому решению установите на компьютере с Windows 2000 Server сетевую плату Token Ring — тогда on сможет взаимодействовать и с этими компьютерами Macintosh. Предложенные здесь решения работоспособны и при использовании FUDI
File Services for Macintosh File Services for Macintosh (Файловый сервер для Macintosh) предоставляет пользователям Macintosh доступ к файлам, хранящимся на сервере Windows 200(!>. Файлсервер доступен но TCP/IP- и AppleTalk-сетям.
Доступ к файл-серверу через TCP/IP Файл-сервер для Macintosh доступен в TCP/IP-сетях и поэтому использовать AppleTalk не обязательно. Чтобы задействовать AFP поверх TCP/IP, на клиенте Macintosh нужно установить клиентское программное обеспечение AppleShare версии 3.7 или выше. Файл-сервер работает либо с AppleTalk, либо с TCP/IP. Если эти протоколы установлены и на клиенте, и на сервере, клиент Macintosh пытается создать соединение с помощью TCP/IP. Если сервер располагает несколькими IP-адресами, он посылает клиенту список своих IP-адресов. Если для подключения к серверу пользователю приходится просматривать сеть AppleTalk, следует установить AppleTalk. Но если пользователь знает IP-адрес или DNS-имя сервера, эту информацию можно просто вводить в диалоговом окне программы Chooser, vi запускать AppleTalk на сервере не требуется.
Доступ к файл-серверу через AppleTalk Хотя файловая система Windows 2000 отличается от файловой системы Macintosh, клиенты Windows 2000 и Macintosh могут использовать файлы, хранящиеся на сервере Windows 2000. Такая возможность реализуется благодаря Services for Macintosh. Пользователям Macintosh и Windows 2000 файлы предоставляются в привычном им виде. Пользователь Windows 2000 видит файлы в структуре дерева каталогов, а пользователь Macintosh — в структуре папок Macintosh. Файлы на сервере Windows 2000, работающем с Services for Macintosh, хранятся в общих каталогах или на томах Macintosh. На каждом сервере может быть один или несколько общих каталогов. Каждому общему каталогу на сервере присваивается уникальное имя, и он считается общим ресурсом (share). Services for Macintosh не предоставляет пользователям Macintosh доступ ко всем общим папкам автоматически. Доступны лишь папки, помеченные администратором как «Macintosh-accessible volumes» (тома, доступные Macintosh).
544
ЧЛСГЬ 3
Взаимодействие с другими системами
Б папке, которая является общим и доступным Macintosh томом, сетевые пользователи Windows 2000 видят пайки и файлы, хранящиеся на жестком диске сервера. А пользователям Macintosh кажется, что этот том содержит файлы и папки Macintosh. Имена файлов и папок могут соответствовать правилам, принятым в Macintosh. Файл-сервер и NTFS транслируют имена файлов и лапок так, чтобы пользователи Macintosh могли их видеть.
ДРР AFP (AppIeTalk Filing Protocol) обеспечивает доступ к файлам по сети. Клиенты могут обращаться к файлам на удаленных серверах, используя команды своих файловых систем. AFP также поддерживает аутентификацию пользователей и управление доступом к файлам. На компьютерах Macintosh сервер AFP реализуется как AppleShare. Если применяется AppIeTalk, AFP опирается на протокол ASP (AppJeTalk Session Protocol), а если задействован TCP/IP, то — на DSI (Data Stream Interface). AFP имеет дело с компонентами файловой системы, например с файлами, папками Macintosh и томами; он вызывается клиентом для доступа к информации о файлсервере и его сервисах, а также для изменения файлов и каталогов.
NTFS-потоки Сервер Windows 2000 хранит специфичные для Macintosh сведения о файлах и каталогах, данные Macintosh Finder, атрибуты AFP и индексную информацию в NTTFS-потоках (NTFS streams). Данные и ресурсы для соответствующего файла содержатся в двух потоках на NTFS-томе. В поток данных включается основная часть информации файла, и этот поток разделяется между клиентами Macintosh и Windows 2000. В ноток ресурсов помещаются такие ресурсы операционной системы Macintosh, как код, меню, шрифт и определения значков. Однако аналога потока ресурсов на персональных компьютерах нет, поэтому клиенты Windows 2000 никогда не допускаются к потокам ресурсов файлов па сервере. Finderlnfo, Indexing и Desktoplnfo тоже хранятся в отдельных NTFS-потоках, которые записываются у корень дискового тома. Потоки Desktoplnfo и Indexing открываются при первой инициализации тома и удаляются при его удалении. Поток Finderlnfo, поддерживаемый для каждого файла и каталога, не удаляется. Потоки, сопоставленные с корнем тома, создаются при создании тома. Macintosh Finder использует информацию из потока ресурсов файла, чтобы определять, какое приложение создало данный файл и к какому типу он относится. На основе этой информации Macintosh Finder выбирает для файла значок подходящего типа и при его открытии запускает нужное приложение. Собственно файлы Macintosh хранятся в потоках данных, сопоставляемых с этими файлами. Windows 2000 поддерживает создание потоков данных и ресурсов при хранении файлов Macintosh на сервере Windows 2000, поэтому клиент Macintosh может просматривать эти файлы и запускать их непосредственно с сервера.
Индексация Новые тома, добавляемые к файловой системе, инициализируются по одному и в том порядке, в каком они были созданы. Б процессе инициализации выполняется
ГЛАВА 13
Services for Macintosh
545
индексация, при которой File Server for Macintosh анализирует всю структуру каталогов тома и создает его образ, сохраняемый в виртуальной памяти. Поток индексации обновляется при каждом включении и выключении сервера. При индексации тома возрастает нагрузка на неподкачиваемую память, но это временное явление. Занимаемый объем неподкачиваемой памяти зависит от количества каталогов на томе (число файлов не имеет значения). По окончании индексации эта память освобождается. Инициализация проходит последовательно. До ее окончания том недоступен (т. е. он невидим в сети, и его нельзя смонтировать). Индексация влияет и на объем используемой виртуальной памяти. По приблизительной оценке для 10 000 файлов и каталогов может понадобиться до 2 Мб виртуальной памяти. Чтобы избежать падения производительности при наличии томов, содержащих более 10 000 файлов и каталогов, имеет смысл увеличить через Control Panel доступный объем виртуальной памяти. Если индексную информацию не удается записать при завершении работы системы, эта информация создается заново при следующем запуске системы.
Дисковое пространство Клиенты Macintosh под управлением OS 7.5 или более ранних версий получают доступ максимум к 2 Гб дискового пространства, а клиенты под управлением более новых версий системного программного обеспечения — максимум к 4 Гб. Для клиентов, использующих AFP 2.2, никаких ограничений на объем дискового прост] эанства нет.
Защита сети Windows 2000 Server в сочетании с Services for Macintosh обеспечивает для пользователей Macintosh ту же сетевую защиту, что и для пользователей Windows 2000. При этом Windows 2000 и Macintosh имеют дело с одними и теми же пользовательскими учетными записями и паролями.
Аутентификация Пользователь Macintosh регистрируется на компьютере с Windows 2000 Server no одной из трех схем аутентификации: • • •
как гость, если сервер настроен па гостевой доступ; как пользователь с незашифрованным паролем; по учетной записи Windows 2000 с применением Apple Standard UAM или MSUAM.
Гости Services for Macintosh позволяет настроить гостевой доступ и разрешить пользователям, не имеющим доменной или групповой учетной записи, регистрироваться на сервере. В гостевой учетной записи Windows 2000 Вы можете указать, какие виды доступа к ресурсам предоставляются гостям (обычно гостям выдается меньше разрешений, чем пользователям, чьи учетные записи хранятся на сервере). Если вход по гостевой учетной записи разрешен, сервер принимает запросы на вход, не требуя пароля.
546
ЧАСТЬ 3
Взаимодействие с другими системами
Нешифрованные пароли Защита на основе нешифрованных паролей поддерживается клиентским программным обеспечением AppleShare на компьютерах Macintosh. Она не слишком надежна, так как пароли передаются но сети открытым текстом. Такой вид защиты предлагается пользователям Macintosh, на компьютерах которых установлен стандартный клиент AppleShare или System 7 Filing. Шифрованные пароли Примечание Если сервер Windows 2000 принимает и шифрованные, и нешифрованные пароли, Macintosh автоматически переключается на аутентификацию с шифрованием. Services for Macintosh предлагает клиентам Macintosh два метода шифрования: • Apple Standard Encryption — пароли могут быть длиной до 8 символов; • MS-User Authentication Method (UAM) — пароли могут быть длиной до 14 символов. Этот метод требует установки клиента AppleShare версии 3.8. В обеих схемах аутентификации с шифрованием сам пароль никогда не передается по сети. Вместо этого сервер генерирует случайное число, которое зашифровывается с использованием пароля как шифровального ключа. Зашифрованное случайное число передается клиенту по сети. Сервер, сконфигурированный на хранение паролей (или их производных) в обратимо зашифрованном виде, использует пароль для шифрования того же числа. После этого он сравнивает свой результат с тем, который передан клиентом, и, если они совпадают, аутентификация считается успешной. Services for Macintosh не поддерживает Kcrberos.
Обычные и доверяемые домены Пользователь может войти в сеть одним из двух способов: • •
ввести имя_пользователя; ввести домен \имя_полъзователя.
Во втором случае аутентификация осуществляется указанным доменом. Когда вводится только имя, сервер сначала ищет локальную учетную запись. Если учетная запись с таким именем есть, сервер регистрирует пользователя; в ином случае сервер ищет соответствующую учетную запись в основном домене (для данного сервера). Если поиск заканчивается безрезультатно, сервер проверяет все доверяемые домены. Если подходящая учетная запись обнаруживается более чем в одном доверяемом домене, сервер регистрирует пользователя в первом из них.
Учетные записи Windows 2000 Server для клиентов Macintosh Services for Macintosh работает с той же базой данных пользовательских учетных записей, что и сервер Windows 2000 или его домен. Поэтому, если у Вас уже есть учетные записи в Windows 2000 Server для пользователей Macintosh, Вам не понадобится создавать дополнительные учетные записи. Вы должны создать учетные записи только для тех, у кого еще нет учетных записей на компьютере или в домене под управлением Windows 2000 Server и Services for Macintosh.
ГЛАВА 13
Services for Macintosh
547
Однако концепция основной группы пользователя применима только к Services for Macintosh. Основной для пользователя считается группа, которая обращается к большинству тех же ресурсов, что и данный пользователь. Создавая папку на сервере, пользователь становится ее владельцем, а основная группа владельца сопоставляется с этой папкой но умолчанию. Но администратор или владелец может сопоставить с папкой другую группу.
Разрешения на доступ к файлам Доступ к сетевым файлам и каталогам контролируется па основе разрешений. Система зашиты Windows 2000 позволяет указывать, какие пользователи могут обращаться к конкретным ресурсам и как именно. Разрешения в Macintosh отличаются от разрешений в Windows 2000 тем, что их можно определять только для томов и каталогов (но не для файлов). Не совпадает и набор разрешений, доступных в Windows 2000 и в Macintosh. Services for Macintosh автоматически транслирует разрешения Windows 2000 в разрешения Macintosh и наоборот. Учетная запись администратора в Windows 2000 Server предоставляет все разрешения на доступ к томам Services for Macintosh.
Типы разрешений Пользователи и администраторы Windows 2000 имеют дело с разрешениями Windows 2000, а пользователи Macintosh, создавая папки, устанавливают разрешения в стиле Macintosh. В Windows 2000 новые файлы и подкаталоги наследуют разрешения от каталога, в котором они создаются; в Macintosh файлы наследуют разрешения, заданные для папок. File Server for Macintosh распознает любые разрешения Windows 2000, указанные для файла, даже если пользователь Macintosh не видит в своем Finder никаких признаков того, что эти разрешения существуют, Операционные системы Macintosh до OS 8.5 поддерживали 4 типа разрешений для папки. See Files. Пользователь видит, какие файлы находятся в данной папке, и имеет право на их чтение. See Folders. Пользователь видит, какие папки содержатся в данной папке. Make Changes. Пользователь может изменять содержимое файлов в данной папке, переименовывать и перемещать их, создавать новые файлы и удалять существующие, Cannot Move, Rename, Or Delete. Пользователю запрещается перемешать, переименовывать и удалять файлы в данной папке. Macintosh OS 8.5 поддерживает следующие привилегии доступа Windows 2000. Read-Only. Пользователь видит файлы и подкаталоги в каталоге, но не может удалять, изменять или заменять их. Write-Only. Пользователь может только добавлять файлы и подкаталоги в каталог. Read and Write. Пользователь может добавлять и удалять файлы и подкаталоги, а также сохранять измененные файлы. None. Доступ к файлам и подкаталогам запрещается.
548
ЧАСТЬ 3
Взаимодействие с другими системами
Пользователь Macintosh не может предоставить эти разрешения другим пользователям или группам — они назначаются только следующим трем категориям пользователей Macintosh. Owner. Пользователь, создавший данную папку. User/Group. Эквивалент группы Windows 2000 Server, сопоставленной с нанкой. Единовременно с каждой папкой на сервере может быть сопоставлена лишь одна группа. Everyone.
Любые пользователи сервера, в том числе гости.
Система защиты в Macintosh базируется па том, что каждая папка на сервере может быть личной (доступной только владельцу папки), групповой (доступной единственной группе) или общей (доступной кому угодно). Например, папка содержит информацию, которая нужна всем членам определенной группы, но изменять ее может только один сотрудник, который должен быть владельцем этой папки (Owner) с разрешениями See Files, See Folders и Make Changes. Вы должны сопоставить с папкой соответствующую группу и выдать этой группе разрешения See Files и See Folders. Поскольку остальным видеть содержимое папки не требуется, выбирать категорию Everyone не следует. Но, вообще говоря, владельцем папки не обязательно должен быть член сопоставленной с ней группы.
Обработка разрешений файлового уровня С помощью Windows 2000 Server пользователи Windows 2000 могут назначать разрешения индивидуально для каждого файла в каталоге. Однако Macintosh не поддерживает разрешения на уровне файлов. Такие разрешения применяются к пользователям Macintosh только в том случае, если накладывают более жесткие ограничения, чем разрешения, назначенные для каталога с этим файлом. Например, если пользователю Macintosh выданы для каталога (который виден ему как папка) разрешения See Files, See Folders и Make Changes, он может читать и изменять файлы в этом каталоге. Однако, если для конкретного файла в том же каталоге ему выдано лишь разрешение Read, он сможет только читать данный файл,
Преобразование разрешений Services for Macintosh преобразует разрешения, установленные пользователем Windows 2000 в эквивалентные разрешения Macintosh, и наоборот. Когда пользователь Windows 2000 указывает разрешения для каталога или когда пользователь Macintosh делает то же самое для папки, эти разрешения преобразуются так, как показано в таблице 13-4. Таблица 13-4. Преобразование разрешений для каталогов и файлов Разрешения в Windows 2QQO Read Write, Delete
Разрешения в Macintosh See Files, See Folders (или и то, и другое) Make Changes
Разрешения преобразуются по следующим правилам: •
Read для каталога или файла в Windows 2000 — в See Files и See Folders на компьютере Macintosh;
ГЛАВА 13
Services for Macintosh
549
• Write и Delete для каталога или файла в Windows 2000 — в Make Changes на компьютере Macintosh; •
See Files и/или See Folders на компьютере Macintosh — в Read в Windows 2000;
• Make Changes на компьютере Macintosh — в Write и Delete в Windows 2000.
Пароли томов Services for Macintosh предоставляет дополнительный уровень защиты за счет использования паролей томов, доступных через Macintosh. Пароль тома (volume password) — это пароль, который можно назначить тому при его конфигурировании из Macintosh. Любой пользователь Macintosh, обращающийся к такому тому, должен ввести не только регистрационный пароль, но и пароль для доступа к тбму. Пользователи Windows 2000 получают доступ к каталогу, соответствующему защищенному тому, без пароля. Пароли томов чувствительны к регистру букв. При создании нового тома из Macintosh ввод пароля по умолчанию не предлагается. Из-за ограничений Finder в Macintosh System 6 и 7 автоматическое монтирование тома с паролем при запуске системы или при двойном щелчке его псевдонима не поддерживается. Также не поддерживается автоматическое монтирование тома, если пользователь, подключаемый к нему, работает с Microsoft UAM,
Трансляция имен файлов Macintosh Services for Macintosh позволяет обмениваться файлами между системами Windows 2000 и Macintosh; однако нельзя исключить конфликты из-за разных правил именования файлов в этих системах (таблица 13-5). Таблица 13-5. Правила именования файлов Операционная система
Файловая система
Ограничение на длину имен файлов
MS-DOS/Windows 2000
FAT
Macintosh
Системное программное обеспечение NTFS 256 символов
Windows 2000
«8.3$> (8 символов на само.имя плюс необязательные точка и расширение имени из трех символов максимум) 31 символ
Когда в NTFS-раздел записывается файл с длинным именем (выходящим за рамки стандарта «8.3», принятого в MS-DOS), система не только сохраняет длинное имя, но и генерирует его краткий вариант, чтобы к файлу могли обращаться пользователи MS-DOS (если у них есть соответствующее разрешение). Macintosh при создании папок или файлов на томе Services for Macintosh накладывает ограничение на длину имен в 31 символ, но пользователи этой системы тем не менее видят оригинальные длинные имена файлов, хранящихся па сервере. Пользователи MS-DOS видят лишь краткие варианты имен файлов. Windows 2000 ограничивает длину имен файлов на NTFS-томах 256 символами. Хотя NTFS транслирует длинные имена в краткие, пользователям систем, не распознающих достаточно длинные имена файлов, лучше именовать общие файлы по стандарту «8.3», принятому в MS-DOS (файловой системе FAT). Это упрощает идентификацию файлов для пользователей, работающих на разных платформах.
550
ЧАСТЬ 3
Взаимодействие с другими системами
Ниже поясняется, как транслируются имена файлов на серверах Windows 2000, на которых установлен компонент Services for Macintosh. Подробнее о трансляции имен файлов см. справочную систему Windows 2000 Server.
Различия в схемах именования файлов В целом, схема именования в FAT (файловой системе MS-DOS) накладывает больше ограничений, чем схема именования в Macintosh. Различия между этими схемами заключаются в следующем. • Имена файлов и папок в Macintosh могут быть длиной до 31 символа; пробелы допустимы. Имена файлов и каталогов в FAT могут быть длиной до 8 символов, за которыми следует необязательное расширение (точка и максимум 3 дополнительных символа); пробелы недопустимы. •
Имена файлов и папок в Macintosh могут включать любые символы, кроме двоеточия, однако в именах файлов и каталогов FAT исключений больше, и следующие символы недопустимы:
/ [ ] ; = " \: i,*. •
Имена файлов и папок/каталогов в Macintosh и MS-DOS могут включать символы из расширенного набора, однако такие наборы в Macintosh и MS-DOS различны.
Macintosh принимает любые имена файлов и каталогов FAT за исключением тех, в которых содержатся символы из расширенного набора, отсутствующие в аналогичном наборе Macintosh. В последнем случае Macintosh заменяет недопустимые символы на допустимые.
Трансляция формата имен Macintosh в формат «8.3» Когда файл создается в Macintosh и сохраняется на компьютере с Windows 2000 Server, File Server for Macintosh сначала проверяет, нет ли в его имени символов, недопустимых в NTFS. Затем NTFS выполняет необходимое преобразование. Функциональность Services for Macintosh Вот что делает в этом случае компонент File Server for Macintosh из Services for Macintosh. •
При необходимости File Server for Macintosh заменяет недопустимые в NTFS символы на Unicode-символы из доступного диапазона, которые затем преобразуются в ANSI-символ по умолчанию (знак вопроса). После этого файл виден, но ни клиент, ни сам пользователь пока не могут обращаться к нему. • Для NTFS в именах файлов недопустимы символы:
"/\ * ? < >|: Функциональность NTFS Получив имя файла от File Server for Macintosh, NTFS преобразует его следующим образом. •
Имена Macintosh, соответствующие правилам MS-DOS, не изменяются, например «Sample.art» остается «Sample.art».
•
Длинные имена урезаются до шести символов, к которым добавляется тильда и уникальный номер, чтобы в сумме получилось восемь символов.
ГЛАВА 13
Services for Macintosh
551
•
Последняя точка в длинном имени (если таковая есть), считается признаком расширения (оно сохраняется).
•
Если краткое имя дублирует другое (длинное или краткое), NTFS автоматически усекает его до шести символов, добавляет тильду и подбирает номер до тех пор, пока не будет получено уникальное имя.
Преобразование символов расширенного набора Если пользователь Macintosh сохраняет на компьютере с Windows 2000 Server имя файла или папки, содержащее символы из расширенного набора, File Server for Macintosh преобразует их в эквивалентные Unicode-символы, чтобы они были видны в Windows 2000. Если пользователь Windows 2000 сохраняет на компьютере с Windows 2000 Server имя файла или папки, содержащее символы из расширенного набора MS-DOS, File Server for Macintosh преобразует их в эквивалентные ANSI-символы Macintosh, чтобы они были видны пользователям Macintosh.
Кросс-платформенные приложения для Macintosh и Windows 2000 Так как многие приложения имеют версии для Windows 2000 и Macintosh, пользователи обеих версий могут работать с одним и тем же файлом данных через Services for Macintosh. Например, сотрудник, использующий Microsoft Excel для Windows 2000, создаст файл с таблицей и сохраняет его на сервере в общем каталоге, который сконфигурирован и как том, доступный Macintosh. Пользователь Macintosh, открыв соответствующую папку, видит этот файл, представленный значком Macintosh для таблиц Microsoft Excel. Если он дважды щелкнет этот значок, его система запустит Microsoft Excel for Macintosh, который откроет выбранный файл. После этого пользователь Macintosh может модифицировать файл и сохранить его. Теперь, когда пользователь Windows 2000 откроет этот файл, он увидит его модифицированную версию,
Сопоставления расширений с типами Благодаря таким сопоставлениям пользователи версий приложения для Windows 2000 и Macintosh могут работать с одними и теми же файлами данных. Сопоставления «расширение-тип», предоставляемые Services for Macintosh, сообщают программе Finder, какие расширения имен файлов MS-DOS соответствуют тинам файлов и создателям файлов в Macintosh. Когда расширение имени файла, хранящегося на сервере, сопоставлено с типом файла и создателем файла в Macintosh, Finder отображает для такого файла подходящий значок. При его выборе автоматически запускается нужное приложение, которое и открывает соответствующий файл. Предопределенные сопоставления расширений с типами показаны в таблице liJ-6, Вы можете добавить свои сопоставления в Services for Macintosh. Чтобы просмотреть полный список сопоставлений, запустите оснастку Computer Management (Управление компьютером), щелкните правой кнопкой мыши узел Shared Folders (Общие папки) и выберите команду Configure File Server for Macintosh (Настроить файловый сервер для Macintosh); в появившемся диалоговом окне откройте вкладку File Association (Сопоставление файлов).
552
ЧАСТЬ 3
Взаимодействие с другими системами
Таблица 13-6. Сопоставления расширений с типами Приложение Windows 2000 или формат файлов Adobe Encapsulated PostScript II AldusPageMaker for Microsoft Windows версии 2.0, Aldus PageMaker for OS/2 версии 2.0 Aldus PageMaker for Microsoft Windows версии 3.0 Publication Template Template Template TIFF graphics file Aldus PageMaker for Microsoft Windows версии 4.0 Publication Template Template Template TIFF graphics file Borland dBASE Lotus 1-2-3 for Microsoft Windows версии 2.0 Microsoft Excel for Microsoft Windows version 3.0, Microsoft Excel for OS/2 версии 3.0 Chart Spreadsheet Macro sheet Workspace Add-in macro file Template file Microsoft Excel for Microsoft Windows версии 4.0, Microsoft Excel for OS/2 версии 4.0 Chart Spreadsheet Macro sheec Workspace Add-in macro file Template file Microsoft Multiplan/SYLK
Приложение Macintosh
Расширение Тип в Создатель в MS-DOS Macintosh Macintosh
Adobe Illustrator'88
EPS
EPSF
ARTZ
Aldus PageMaker for Macintosh версии 2.0
PUB
PUBF
ALD2
PM3 PT3 ТЕМ TPL TIE
ALB3 ALTS ALT3 ALTS TIFF
ALD3 ALD3 ALD3 ALD3 ALD3
PM4 PT4 ТЕМ TPL TIP DBF
ALB4 ALT4 ALT4 ALT4 TIFF F+DB
ALD4 ALD4 ALD4 ALD4 ALD4 FOX+
WK3
LWK3
L123
Chart Spreadsheet Macro sheet Workspace Add-in macro file Template file Microsoft Excel for Macintosh нерсии 4.0
XLC XLS XLM XLW LA XLT
XLC3 XLS3 XLM3 XLW3 XLA SLM3
XCEL XCEL XCEL XCEL XCEL XCEL
Chart Spreadsheet Macro sheet Workspace Add-in macro file Template file Microsoft Excel lor Macintosh версии 3.0
XLC XLS XLM XLW XLA XLT SLK
XLC4 XLS4 XLM4 XLW4 XLA SLM3 TEXT
XCEL XCEL XCEL XCEL XCEL XCEL XCEL
Aldus PageMaker for Macintosh версии 3.0 Publication Template Template Template TIFF graphics file Aldus PageMaker for Macintosh нсрсии 4.0 Publication Template Template Template TIFF graphics file Microsoft FoxBASE / FoxBASE+ for Macintosh Lotus 1-2-3 for Macintosh версии 2.0 Microsoft Excel for Macintosh версии 3.0
ГЛАВА 13 Таблица 13-6.
Services for Macintosh
553
(продолжение)
Приложение Windows 2000 или формат файлов Microsoft PowerPoint версии 2.0 Microsoft PowerPoint версии 3.0 Slides Microsoft Project for Windows версии 1-r Projects Exchange format Calendars Views Workspaces Microsoft Word for Windows версии 2.0 Document Text Document Rich Text Style Sheet Glossary N. A./ Comma- Separated Values N.A./SIT files N.A./Text (TXT files) Windows Program
Приложение Macintosh Microsoft PowerPoint for Macintosh версии 2.0 Microsoft PowerPoint for Macintosh версии 3.0 Slides Microsoft Project for Macintosh версии laProjects Exchange format Calendars Views Workspaces Microsoft Word for Macintosh версии 5.1 Document Document Rich Text
Расширение Тип в Создатель в MS-DOS Macintosh Macintosh PPT
SLD2
PPT2
PPT
SLD3
PPT3
MPP MPX MPC MPV MPW
MSPF MSPF MSPJ MSPJ MSPF
MSPJ MSPJ MSPJ MSPJ MSPJ
DOC WRD
WDBK TEXT TEXT TEXT TEXT TEXT
MSWD MSWD MSWD MSWD MSWD XCEL
Bci
SIT! TEXT DEXE DEXE DEXE DEXE TEXT TEXT
SIT! TTXT LMAN LMAN LMAN LMAN MORE LMAN
DIF
TEXT
XCEL
RTF STY
N/A N/A
GLY
Microsoft Excel for Macintosh версии 4.0 Alladin Stuffit Teach text
CSV SIT
TXT EXE
N/A
COM CMD BAT
Symantec Ready! Unknown File
Symantec MORE
VisiCalc (DIF)
Microsoft Excel for Macintosh версии 4.0
N/A
RDY
остальные
Вы можете добавить новые сопоставления «расширение-тип» для любого приложения независимо от того, перечислено ли оно в таблице 13-6. Например, если в Вашей компании сохраняют документы Microsoft Word в файлах с расширением .wrd, Вы можете добавить одно из расширений, перечисленных о таблице 13-7. Таблица 13-7. Дополнительные сопоставления расширений с типами Приложение
Расширение
Расширение в MS-DOS Тип файлов в Macintosh Создатель файлов в Macintosh
.wrd WDBN MSWD
554
ЧАСТЬ 3
Взаимодействие с другими системами
Добавление нового сопоставления не влияет на файлы, уже существующие на сервере. Кроме того, учтите, что можно сопоставить несколько расширений с типом файлов и создателем в Macintosh, но обратное не допускается. Примечание По умолчанию файлы данных в форматах WKS и WK1 разрешается открывать в Microsoft Excel, Lotus 1-2-3 и Informix Wingz. Однако Вы можете сделать так, чтобы с файлами этих форматов работало только одно из приложений Macintosh. Например, если Вы сопоставите расширения WKS и WK1 лишь с теми типом файлов и создателем, которые соответствуют Microsoft Excel for Macintosh, то при двойном щелчке значка файла с одним из этих расширений будет загружаться именно Microsoft Excel for Macintosh. ^ Чтобы создать новые сопоставления расширений с типами: 1. Откройте оснастку Computer Management (Управление компьютером). 2. Щелкните правой кнопкой мыши узел Shared Folders (Общие папки) и выберите команду Configure File Server for Macintosh (Настроить файловый сервер для Macintosh). 3.
На вкладке File Association (Сопоставления файлов) в поле Files with MS-DOS Extension (Файлы с расширением MS-DOS) введите расширение или выберите его из списка. Если расширение уже сопоставлено с типом и создателем файла, оно будет выделено в списке With Macintosh Creator and Type (Файлы, созданные Macintosh).
4. В списке With Macintosh Creator and Type выберите создателя и тип, которые нужно связать с этим расширением. 5. Щелкните кнопку Associate (Сопоставить). ^ Чтобы добавить создателей и типы файлов: 1. Откройте оснастку Computer Management. 2. Щелкните правой кнопкой мыши узел Shared Folders и выберите команду Configure File Server for Macintosh. 3. На вкладке File Association щелкните кнопку Add (Добавить). 4. Введите значения в поля Creator (Создан) и File Type (Тип файла), а затем (необязательно) добавьте описание. ^ Чтобы изменить описание типа файлов: 1. Откройте оснастку Computer Management. 2. Щелкните правой кнопкой мыши узел Shared Folders и выберите команду Configure File Server for Macintosh. 3. На вкладке File Association введите расширение или выберите его из списка. 4. Щелкните кнопку Edit (Изменить) и введите новое описание. ^ Чтобы удалить тип файлов и его сопоставления: 1. Откройте оснастку Computer Management. 2. Щелкните правой кнопкой мыши узел Shared Folders и выберите команду Configure File Server for Macintosh.
ГЛАВА 13 Services for Macintosh 3.
555
На вкладке File Association выберите удаляемого создателя.
4. Щелкните кнопку Delete (Удалить). 5. Щелкните кнопку Yes (Да), чтобы подтвердить свои действия.
Print Server for Macintosh Services for Macintosh позволяет настроить сервер Windows 2000 на поддержку службы печати одного из двух типов (рис. 13-6). Клиенты Windows 2000 могут использовать этот сервер для доступа к сервисам подключенных к сети AppleTalk принтеров PostScript с драйверами LaserWriter. Клиенту Macintosh доступен любой принтер, подключенный к коммуникационному порту сервера Windows 2000 или находящийся в сети.
Принтер.
отличный от PostScript Клиент Macintosh Клиент MS-DOS или Windows Windows 2000 Server
Принтер AppleTalk PostScript
Рис. 13-6. Сервер печати для Macintosh Services for Macintosh предоставляет дополнительные преимущества пользователям Macintosh, работающим с AppIeTalk-принтерами, например спулинг. Благодаря спулингу пользователи Macintosh могут переключаться на другие задачи сразу после отправки задания на печать компьютеру с Windows 2000 Server, на котором эти задания хранятся до тех пор, пока какой-нибудь принтер не станет доступным. Без спулинга пользователям пришлось бы ждать выполнения задания на печать, и до этого момента они не могли бы заниматься другой работой. Компонент Print Services требует наличия AppleTalk, который устанавливается автоматически при установке сервера печати для Macintosh.
Протокол печати Print Server for Macintosh (Сервер печати для Macintosh) использует Printer Access Protocol — протокол сеансового уровня, который обеспечивает надежную передачу данных между клиентом и сервером. Этот протокол отвечает за создание, поддержку и завершение соединения (или соединений) между рабочей станцией и сервером печати. Клиентское приложение посылает запрос на печать диспетчеру печати. Спулер позволяет клиенту продолжать работу, не дожидаясь окончания обработки задания на печать. Но учтите, что для Printer Access Protocol принтер и сервер (или спулер) одно и то же.
556
ЧАСТЬ 3
Взаимодействие с другими системами
Аутентификация при печати Встроенные в Macintosh средства для работы с сетями не поддерживают аутентификацию при печати. Поэтому ограничить клиентам Macintosh доступ к сетевым принтерам нельзя. Однако, если сервер печати запущен под какой-нибудь пользовательской учетной записью, за конкретным принтером можно закрепить ACL (Access Control List). Тогда пользователь получает доступ к спулеру, но не к самому принтеру, а пользователь Macintosh не сможет печатать на этом принтере. Кроме того, системный администратор может ввести один набор разрешений на печать уровня пользователей для всех клиентов печати Macintosh как для некоей группы. Для этого на клиенте Macintosh надо запустить сервис Mac-Print, войдя по учетной записи System, которая предоставляет разрешение Print для всех локальных устройств печати. Затем, чтобы ограничить разрешения для клиентов Macintosh, вы должны создать новую пользовательскую учетную запись и назначить ей те разрешения на печать, которые Вы хотите предоставить группе. И, наконец, настройте сервис MacPrint на клиенте Macintosh так, чтобы он регистрировался под этой учетной записью. Примечание Учетная запись System не дает разрешения на доступ к ресурсам другого компьютера. Клиенты Macintosh, на которых сервис MacPrint запускается под учетной записью System, не могут передавать задания принтерам, пересылающим эти задания на другие серверы печати. Выход таков: настройте сервис MacPrint на клиенте Macintosh так, чтобы он регистрировался под другой пользовательской учетной записью, разрешающей печать па всех серверах печати, которым пересылаются задания.
Macintosh Port Monitor Macintosh Port Monitor передает задания подключенным к сети устройствам печати, используя протокол ApplcTalk. Он также позволяет посылать задания ApplcTalkспулерам независимо от устройства печати, к которому подключен этот спулер. Монитор портов доступен в Windows 2000 и дает возможность любому компьютеру с Windows 2000 посылать локальные задания на печать ApplcTalk-приитерам (независимо от того, как именно перелаются серверу эти задания). Некоторые устройства печати неправильно обрабатывают задания на печать, отличные от PostScript, если получают их через AppleTalk. Кроме того, некоторые устройства печати неправильно обрабатывают PostScript-задания, если они содержат двоичные данные и поступают по любому протоколу, отличному от AppleTalk. Эти проблемы обычно связаны с внутренними ограничениями таких устройств печати.
Процессор печати в Services for Macintosh Этот процессор печати, устанавливаемый с Print Server for Macintosh, назначает документу один из двух типов данных: RAW или PSCRIPT1 (таблица 13-8). Тип данных PSCRIPT1 указывает, что задание содержит PostScript-код Level 1, поступивший от клиента Macintosh, по адресовано принтеру, отличному от PostScript. Спулер передает PostScript-код через Microsoft Truelmage® (процессор растровых изображений), поставляемый с Services for Macintosh. Процессор растровых изображений создает последовательность одностраничных монохромных битовых
ГЛАВА 13
Services for Macintosh
557
карт с максимальным разрешением 300 dpi. Спулер печати Windows 2000 посылает растровые изображения, или битовые карты, драйверу целевого принтера. Таблица 13-8. Типы данных процессора печати Тип данных
Инструкции спулеру
Предназначение
RAW
Печатать документ без изменений
Все документы, адресованные PostScript-принтерам Все документы, адресованные принтерам, отличным от PostScript
PSCRIPT1
Преобразовать документ в растровые изображения, или битовые карты
Поскольку битовые карты монохромные и имеют разрешение не более 300dpi, драйвер принтера формирует конечный вывод, который тоже является монохромным и с разрешением не более 300 dpi, даже если этот драйвер поддерживает циетную печать и более высокие разрешения. Причина таких ограничений в самом программном обеспечении процессора растровых изображений, а не в драйверах принтеров Windows 2000. Если Вам нужен более качественный процессор растровых изображений, Вы можете приобрести соответствующие пакеты от сторонних поставщиков. Примечание Если серверу Windows 2000 посылаются двоичные PostScript-задания на печать, вывод может быть искажен из-за использования разных протоколов.
Настройка сетевых принтеров Ниже перечислены три варианта печати по сети. •
Клиенты Windows посылают запросы на печать принтерам, подключенным к компьютеру под управлением Windows 2000 Server.
•
Клиенты Macintosh посылают запросы на печать принтерам в сети AppleTalk,
•
Клиенты Macintosh и Windows 2000 посылают запросы на печать принтерам. подключенным к компьютеру под управлением Windows 2000 Server (например, принтеру, отличному от PostScript, вроде HP DeskJet 500), и принтерам в сети AppleTalk (например, PostScript-принтеру типа Apple LaserWriter).
Печать происходит следующим образом. Пользователи Windows 2000 указывают принтеры на сервере Windows 2000 и отправляют им задания на печать обычным образом — независимо от того, подключены ли эти принтеры непосредственно к серверу или они находятся где-то в другом месте сети. Аналогично пользователи Macintosh могут подключаться через интерфейс Chooser к принтерам, настроенным в качестве сетевых AppleTalk-устройств, и к принтерам, доступным серверу W i n dows 2000. При использовании Services for Macintosh установка и настройка принтеров ничем не отличается от тех же действий в Windows 2000 Server с единственным исключением: сервер печати и файл-сервер должны находиться в одной зоне. Все очереди печати Windows 2000 автоматически становятся доступными компьютерам Macintosh. Однако, планируя печать в смешанной сетевой среде, примите во внимание следующие соображения. В сетях Windows 2000 устройства печати традиционно подключаются к серверу через последовательные или параллельные порты, тогда как в сетях Macintosh они
558
ЧАСТЬ 3
Взаимодействие с другими системами
подключаются через LocalTalk. Установив Services for Macintosh, Вы можете либо подключить принтер к компьютеру с Windows 2000 Server, либо разместить его в сети AppIeTalk. В любом случае клиенты обоих типов смогут посылать этому принтеру задания на печать, (В AppIeTalk устройство печати должно быть PostScriptпринтером, использующим драйвер LaserWriter.) Чтобы получить максимальную производительность, подключайте принтеры к сети, а не к портам. Ниже перечислены варианты подключения в порядке увеличения эффективности. 1. Принтер подключен к последовательному порту сервера Windows 2000. (Некоторые устаревшие модели Apple LaserWriter можно подключать только к последовательным портам.) 2. Принтер подключен к параллельному порту сервера Windows 2000. 3. Принтер подключен к сети AppIeTalk через LocalTalk (типичный вариант подключения для Macintosh). 4. Принтер подключен к AppIeTalk через Token Ring или Ethernet. Принтеры со встроенными Ethernet-интерфейсами обеспечивают наивысшую производительность. Они подключаются к сети напрямую,
Предотвращение LaserPrep Wars В некоторых сетях AppIeTalk возможна ситуация, известная под названием LaserPrep Wars; она может привести к замедлению печати. Services for Macintosh решает эту проблему. LaserPrep Wars возникает, если в сети есть клиенты Macintosh, использующие не менее двух версий Chooser Packs (набора файлов, часть которых содержит информацию PostScript). Когда компьютер Macintosh посылает задание на PostScriptпринтер, последний интерпретирует PostScript-команды с помощью Chooser Pack, который включает файл подготовки PostScript (также называемый файлом LaserPrep) и драйвер PostScript. Единовременно принтер может работать только с одной версией файла LaserPrep. При отправке задания на печать Macintosh проверяет версию этого файла на принтере. Если принтер использует версию, отличную от имеющейся на клиенте, Macintosh посылает вместе с заданием на печать свою версию файла LaserPrep и командует принтеру загрузить этот файл как резидентный. Поскольку на разных компьютерах Macintosh хранятся разные версии файла LaserPrep, принтеру приходится все время загружать и выгружать то одну, то другую версию LaserPrep. После загрузки повой версии файла LaserPrep принтер должен печатать специальную тестовую страницу. Все это уменьшает производительность принтера и может сократить срок его службы. Services for Macintosh устраняет эту проблему за счет передачи файла LaserPrep с каждым заданием; при этом принтер не тратит время па то, чтобы сделать LaserPrep резидентным и печатать тестовую страницу, Ситуация LaserPrep Wars гарантированно устраняется только в том случае, если пользователи посылают задания через сервер печати. Если же они передают задания принтеру напрямую, в обход сервера печати, это может привести к LaserPrep Wars. LaserPrep Wars никогда не возникает, если принтеры напрямую подключены к серверу Windows 2000 с Services for Macintosh.
1 \ с \ п
В
а
-..
560
-?tf* 05Й
0° ''Po
'-
o;v«°w ";«е t««V
Ч ^t'lo*»^^ ^'*!Г£Ф»* 1 се
**£&%** ^^f>-^- 6na^.
В1
е««-^^Ги «ел- nv vcn* 1 ' • Воз^*П°'
ГО '
Hfi
1
::"ф«^°^^"«а^' "'-^-
найти
uaet -^ai v
файл или vr ^°
ГЛДВД 13
Services for Macintosh
563
He удается сохранить с компьютера Macintosh файл с именем в формате «8.3» Не исключено, что такое краткое имя уже есть, но пользователи Macintosh его не видят. Присвойте файлу другое имя. Не удается найти сервер Придерживайтесь следующей схемы. 1. Убедитесь, что AppleTalk установлен. 2. Убедитесь, что сетевое соединение, схема подключения и заглушки на кабелях соответствуют используемой Вами несущей среде. 3. Начните с клиента, который не может найти сервер. Если иссушая среда LocalTalk, убедитесь, что разъем LocalTalk подключен к принтерному, а не к модемному порту. Если Вы используете другую несущую среду, проверьте, надежно ли подключен сетевой кабель к порту. Щелкните Network для проверки сетевых параметров. 4. Проверьте, нет ли той же проблемы на других клиентах. Если есть, проверьте кабели и подключения на сервере. Убедитесь, что сериср работает правильно. Если с сервером все в порядке, перейдите к л. 5. 5. Проверьте, не повреждена ли кабельная система (несущая среда). Если сервер, который не виден с клиента, находится в локальной сети, последовательно проверьте все клиентские компьютеры между проблемным клиентом и сервером. Место разрыва в кабельной системе находится между клиентом, который показывает сервер в своем Chooser, и тем клиентом, на котором этот сервер не виден. Если сервер находится в другой физической сети, выясните, какой из клиентов является первым за маршрутизатором, связывающим две сети. Проверьте сначала этот клиент, а потом все клиенты за ним (в направлении к серверу), пока не найдете компьютер, на котором искомый сервер виден. Если сервер виден на первом клиенте, двигайтесь в обратном направлении и проверяйте клиенты, расположенные рядом с каждым маршрутизатором, до тех пор, пока на очередном клиенте Вы не обнаружите исчезновения сервера. 6. Найдя предполагаемое место разрыва в кабеле, сначала проверьте надежность всех подключений на клиенте и посмотрите, не появился ли сервер в его Chooser. Если нет, замените кабели или разъемы. В Chooser на компьютере Macintosh не видно никаких зон Убедитесь, что AppleTalk активен в Chooser. Щелкните Network. Проверьте, правильно ли выбран сетевой порт. Возможны проблемы с сетью, поэтому проверьте следующее. • Компьютер Macintosh может использовать AppIeTalk Phase 2 без подходящего драйвера Ethernet. • Маршрутизатор может использовать Phase 1. хотя в остальной сетевой среде применяется Phase 2. • Компьютер Macintosh настроен на неправильный тип несущей среды. Если устранить проблему не удалось, проверьте, корректно ли настроены маршрутизаторы.
564
ЧАСТЬ 3 Взаимодействие с другими системами
Не удается найти том Microsoft UAM На компьютере с Windows 2000 Server недостаточно дискового пространства для тома Microsoft UAM или на нем нет NTFS-раздела. Вы можете создать том командой: setup /i oemnxpsm.inf /с uaminstall Эта команда копирует файлы UAM в папку ApplcShare на первом NTFS-разделе и настраивает соответствующие параметры в реестре. Вид папки искажен или не соответствует виду, выбранному в меню View Владелец папки должен войти на сервер, подключиться к тому Macintosh и выбрать нужный вид (например. View By, View By Name) ш меню View. Выбранный вид останется в силе. Иногда Finder не в состоянии правильно показать содержимое панки. Только что описанный прием решает эту проблему. Файл отображается со значком Windows 2000, предлагаемым по умолчанию Во-первых, на компьютере Macintosh, вероятно, удалено приложение, которое работало с файлами данного типа, Инструмент Apple ResEdit позволяет восстановить информацию о данном типе файлов и о создателе этого файла. Во-вторых, у пользователя, возможно, нет прав на просмотр содержимого лапки, где находится этот файл. Для пользователя Windows 2000 нужно предоставить на сервере разрешение Read. А для пользователя Macintosh владелец папки должен предоставить разрешения See Files и See Folders. Пользователь Macintosh не получает сообщения от сервера Видеть сообщения от сервера могут только клиенты Macintosh с протоколом AFP версии не ниже 2.1. Убедитесь, что на клиенте установлено программное обеспечение AppleShare версии 3,0. Пользователю не удается автоматически подключаться к тому Macintosh по псевдониму Клиенты Macintosh могут быть настроены на автоматическое подключение к томам при запуске или при двойном щелчке псевдонима какого-либо объекта на томе. Однако автоматическое подключение к томам не поддерживается системным программным обеспечением Macintosh, если дисковому тому назначен пароль или если пользователь первоначально подключился к нему с помощью MS-UAM. Если том защищен паролем, смонтируйте его в Chooser — тогда Вы сможете воспользоваться псевдонимом. Или укажите, что он должен открываться при загрузке системы. Но, если Вы входите на сервер с применением MS-UAM, Вам годится только первый вариант. Принтеры AppieTalk не появляются в папке принтеров, открываемой из диалогового окна AppieTalk Printers Если выбор какой-либо зоны AppieTalk не приводит к отображению принтеров в этой зоне, Вы должны дважды щелкнуть ее имя в диалоговом окне Available AppleTalk Printers. При печати документов постоянно появляются сообщения об ошибках Сбросьте состояние устройства печати, выключив его и снова включив.
ГЛАВА 13
Services for Macintosh
565
При печати документа (чаще в его конце) появляется сообщение об ошибке PostScript «Offending command» Во-первых, пользователь или администратор мог отменить задание на печать в момент его обработки спулером. Никаких особых действий не требуется; при необходимости можно распечатать файл повторно. Во-вторых, пользователь отправил задание печатающему устройству PSTODIB, а в документе присутствуют элементы, соответствующие PostScript уровня 2. Не удается печатать задания Проверьте все устройства, печатающие эти задания. Если одно из них выключено, все остальные устройства, входящие в тот же пул, прекращают печать. Символы из расширенного набора Macintosh (например, маркеры, значки авторских прав и торговой марки) заменяются другими символами на LaserWriter II Проверьте настройки коммуникационных портов LaserWriter (соответствующая информация имеется в документации на этот принтер). Если LaserWriter настроен некорректно, возможны проблемы при печати независимо от того, как настроен СО М-порт на сервере Windows 2000. Эта проблема в большей мере влияет на компьютеры Macintosh, чем на компьютеры с Windows 2000, так как на первых чаще используются символы из расширенного набора, Подробнее о выявлении и устранении проблем см. по ссылке на Web-узел Microsoft TechNct на странице http://windows.microsoft.coin/4vindows2000/reskit/vvebresources.
Дополнительные материалы Более подробную информацию об Apple-Talk см. в книге; • G.S. Sidhu, R. F. Andrews and А. В. Oppenheimer «Inside AppleTalk», Second Edition, 1990, Massachusetts; Add i son-Wesley.
ЧАСТЬ
4
Интеграция сетей и мультимедиа
Успешное развертывание и эффективное использование мультимедийных приложений в сетях по-прежнему являются важными задачами сетевых администраторов. Часть 4 посвящена средствам Windows 2000, обеспечивающим поддержку мультимедийных приложений в сетях.
В этой части ATM 568
Интеграция телефонии и поддержка конференций
618
ГЛАВА
14
ATM
Windows 2000 предоставляет службы ATM (Asynchronous Transfer Mode) и поддерживает сервисы ATM LANE, IP поверх ATM и др. Вес эти сервисы и службы подробно обсуждаются в данной главе. В этой главе Введение в ATM 568 Обзор ATM 569 Архитектура ATM 573 Службы ATM в Windows 2000
594
Рекомендации 603 Выявление и устранение проблем 615 См. также • Об интеграции телефонии — главу 15 «Интеграция телефонии и поддержка конференций» в этой книге. • Подробнее о других типах QoS - главу 9 «Quality of Service» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server».
Введение в ATM Спецификация ATM описывает несколько взаимосвязанных технологий, основанных на стандартах и обеспечивающих высокоскоростную коммуникационную связь в различных несущих средах. International Telecommunication Union (ITU-T) определяет ATM как «высокоскоростной, ориентированный на логические соединения метод мультиплексирования и коммутации, описанный в международных стандартах и использующий ячейки фиксированной длины для поддержки различных видов трафика». Прежде чем принимать решение о развертывании ATM в сети, нужно понять, как ATM интегрируется в существующие сетевые среды и как она работает в новых сетевых средах. ATM представляет собой множество сервисов и концепций. В настоящее время технологии ATM обычно применяются в отдельных частях локальных и региональных сетей. Некоторые сети полностью трансформированы в ATM, где программно-аппаратное обеспечение и сетевая инфраструктура состоит только из устройств и
ГЛАВА 14
ATM
569
драйверов ATM. В ряде случаев ATM используется лишь в сетевых магистралях, соединяющих одну локальную сеть с другой. Иногда ATM-компоненты соседствуют с компонентами стандартной LAN и другими сетевыми технологиями. Наиболее важные ATM-сервисы в Windows 2000 — поддержка .эмуляции LAN (LANE), IP поверх ATM, TAPI, Direct Streaming и другие службы. Вес они подробно рассматриваются в разделе «Службы ATM в Windows 2000» далее в этой главе.
Обзор ATM ATM (Asynchronous Transfer Mode) — это ориентированная на логические соединения технология коммутации пакетов с ненадежной доставкой. Особенности ATM перечислены ниже. •
Масштабируемость. ATM позволяет быстро передавать данные по сети независимо от ее размера. Она одинаково хорошо работает как в высокоскоростных, так и в низкоскоростных несущих средах.
• Гибкость настройки гарантированного качества обслуживания (QoS). При использовании ATM клиент указывает желаемую точность и скорость передачи данных. Этим ATM отличается от других высокоскоростных LAN-технологий, например от гигабитной Ethernet. QoS в ATM также поддерживает зависимый от времени (изохронный) трафик. Управление трафиком на аппаратном уровне гарантирует согласованное качество обслуживания на всем маршруте. Трафик в одной виртуальной цепи ATM не влияет на трафик в другой. Благодаря малому размеру пакетов и простой структуре заголовков обеспечивается быстрота переключения и сводится к минимуму число «узких мест». • Скорость. Архитектура ATM не налагает ограничений по скорости. Такие особенности ATM, как создание виртуальных цепей до установления соединения, ячейки фиксированного размера, сегментация и восстановление сообщений на аппаратном уровне, а также аппаратная коммутация, способствуют высокой скорости передачи данных. •
Интеграция различных видов трафика. ATM поддерживает интеграцию служб передачи голосовой и видеоинформации, а также данных. Доступ к этим службам реализуется ATM поверх ADSL.
В отличие от большинства сетевых протоколов, не ориентированных на логические соединения, ATM является строго детерминированной сетевой системой: она обеспечивает предсказуемое, гарантированное качество обслуживания.
Базовые компоненты В ATM два базовых элемента: конечное устройство (компьютер, подключенный к ATM-сети) и ATM-коммутатор (устройство, отвечающее за соединение конечных устройств и успешную передачу данных). Благодаря масштабируемости ATM любой компьютер, подключенный к ATM-сети, может соединяться с любым другим подключенным к той же сети компьютером без дополнительных уровней протоколов.
Традиционная и ATM LAN В следующих разделах дается краткое сравнение этих двух технологий и поясняются сильные стороны ATM.
570
ЧАСТЬ 4
Интеграция сетей и мультимедиа
Сетевые технологии и логические соединения В традиционных LAN-сетях типа Ethernet и Token Ring при передаче данных соединения не устанавливаются и доставка данных не гарантируется. В ATM используется другой подход, при котором устанавливаются логические соединения и создаются виртуальные цепи (virtual circuits, VC). Далее показываются различия между этими двумя подходами. Традиционные LAN В традиционных LAN каждый клиент подключается к сети через сетевой адаптер, у которого имеется свой драйвер. Над этим драйвером располагается драйвер протокола, например TCP/IP. Драйвер протокола разбивает данные на кадры различного размера и вставляет в каждый кадр соответствующий заголовок. Когда адаптер получает доступ к несущей среде, пакеты посылаются на аппаратный адрес получателя. Традиционные LAN-технологии не гарантируют своевременную доставку данных и правильную их последовательность. Хотя Ethernet и Token Ring могут обнаруживать ошибки, они не восстанавливают потерянные или поврежденные пакеты самостоятельно и не гарантируют качество обслуживания. Поскольку все компьютеры подключены к общей несущей среде, каждый из них видит все кадры, отправленные в несущую среду другими компьютерами, независимо от того, пересылаются кадры последовательно от одной станции к другой (топология «кольцо») или передаются сразу на все станции (Ethernet). Сетевой адаптер на каждом компьютере обрабатывает кадр и анализирует адрес получателя, Если кадр адресован этому компьютеру, кадр проверяется на наличие ошибок; при отсутствии ошибок сетевой адаптер инициирует аппаратное прерывание и передает кадр своему драйверу. Пример традиционной LAN приведен на рис. 14-1.
Послать пакет сетевому адаптеру 2 (пакет содержит адрес получателя)
LAN-адаптер 3 Проверить адрес пакета LAN-адаптер 2
Игнорировать
Проверить адрес пакета Выполнить аппаратное прерывание Принять пакет
Рис. 14-1. Традиционная LAN: передача пакетов без установления логических соединений Поскольку традиционные LAN не ориентированы на логические соединения, доставка данных в них не гарантируется. В частности, нельзя определить состояние адресата и выяснить, может ли он принимать кадры. Кроме того, невозможно га-
ГЛАВА 14
ATM
571
рантировать нужную полосу пропускания при передаче данных. «Узкие места», возникающие из-за неожиданно большого числа одновременных обращений, препятствуют применению традиционных LAN-технологий в областях, где важнейшим требованием является постоянство скорости передачи данных, например видео- и аудиоинформации. В традиционных LAN могут использоваться драйверы протоколов верхнего уровня, которые контролируют передачу данных (при необходимости повторно посылая данные), разбивают большие сообщения па несколько сообщений меньшего размера, проставляют временные метки для синхронизации и т. д. Однако эти сервисы замедляют передачу данных и не гарантируют качество обслуживания на всем пути доставки. Традиционные технологии межсетевых сред Разница между ATM и традиционными сетями еще заметнее, если получатель находится не в локальной сети отправителя. Когда маршрутизатор в Ethernet.-сети обнаруживает широковещательный пакет, адресованный в другую сеть, он принимает пакет и пересылает его с использованием TCP/IP. Пакеты, отравленные но одному и тому же адресу, могут передаваться по разным маршрутам. Установление логического соединения не требуется, но доставка не гарантируется. На рис. 14-2 показан пример, в котором два пакета передаются по разным маршрутам. г Пакет 1
Маршрутизатор
Маршрутизатор
Сетевой адаптер Маршрутизатор
Маршрутизатор
L- Пакет 2
Рис. 14-2. Два пакета, передаваемых в традиционной LAN по разным маршрутам ATM-сети ATM ориентирована на логические соединения. Перед передачей данных одно из конечных устройств ATM указывает конкретный путь к другому конечному устройству (получателю), называемый виртуальной цепью (VC). После этого по виртуальной цепи пересылается серия кадров одного размера, называемых ячейками. Устанавливая соединение, конечные устройства ATM согласуют и параметры QoS. В этих параметрах (применяемых, в том числе, к промежуточным коммутаторам) указываются полоса пропускания, максимальная задержка при передаче, приемлемые вариации величины задержки и т. д. Путь трафика согласуется с самого начала, поэтому коммутирующим устройствам достаточно проанализировать простой заголовок, чтобы определить нужный путь. При задании пути ATM позволяет устанавливать полнодуплексное соединение с несколькими адресатами одновременно. Но учтите, что протокол ATM сам по себе
572
ЧАСТЬ 4
Интеграция сетей и мультимедиа
не гарантирует доставку. Доставка ячеек в ATM не подтверждается, как и в традиционных LAN, поэтому ошибки, связанные с потерей или повреждением данных, распознаются и устраняются протоколами более высокого уровня. Виртуальную цепь ATM и процесс передачи пакетов иллюстрирует рис. 14-3. Процесс А {драйаер протокола, приложение) Послать эту ячейку по VC с определенным номером
Драйаер адаптера
ATM-адаптер 1 Создать VC с процессом С на адаптере 2 с указанными параметрами QoS {полосой пропускания, максимальной задержкой и т. д.) Вернуть номер VC
Процесс А Процесса Процессе аивер адаптера
АТМкоммутатор
ATMадаптер 3
ATM-адаптер 2 Выполнить аппаратное прерывание Принять ячейку
Рис. 14-3. Виртуальная цепь ATM и передача пакетов
Скорость передачи В отличие от Ethernet в ATM пет ограничений по скорости, а эффективность ЛТМ не зависит от расстояния, которое проходят данные. Кроме того, путь определенной серии пакетов согласуется с самого начала, благодаря чему АТМ-коммутаторам практически не приходится принимать решений при коммутации пакетов. Для передачи по ATM-сети данные разбиваются на ячейки одинакового размера и дополняются заголовком с нужной информацией. Ячейки передаются по порядку, при этом для большей эффективности их пересылки в ATM-сетях используются номера VPI (Virtual Path Identifier) и VCI (Virtual Channel Identifier). Коммутатор считывает заголовок ячейки, проверяет VPI/VCI по своей таблице и определяет требуемый выходной порт и новые VPI/VCI, после чего пересылает ячейку. Вся необходимая коммутатору информация об адресах всегда содержится в одном и том же месте заголовка. Это позволяет легко реализовать логику пересылки на аппаратном уровне, уменьшая время задержки. Более того, если технология ATM используется на всем пути, трансляция данных при передаче пакетов через WAN не нужна.
ГЛАВА 14
ATM
573
Виртуальные пути и цепи ATM, а также формат ячеек подробно рассматриваются далее в этой главе. Па рис. 14-4 показаны два конечных устройства ATM, пересылающих ячейки фиксированного размера от А к В (хотя ATM-график может пересылаться в обоих направлениях). 5 байтов
48 байтов
Заголовок (идентификатор VC)
АТМкоммутатор ATM-адаптер 2
Рис. 14-4. Ячейки фиксированной длины Небольшие ячейки фиксированного размера (53 байта) упрощают обработку и не требуют определения начала и конца конкретной ячейки. Малый размер ячейки минимизирует задержки при ее пересылке. А то, что он фиксирован, позволяет оптимизировать как алгоритмы обработки, так и использование буферов. Традиционным технологиям LAN вроде Ethernet присущи ограничения по скорости передачи; для поддержки быстрого трафика приходится менять либо инфраструктуру несущей среды (кабели), либо размер сетевого сегмента. ATM — в отличие от Ethernet и Token Ring — такие ограничения пе свойственны. Если скорость передачи данных увеличивается (т. е. данные из одного места в другое должны пересылаться по одному или нескольким проводам быстрее), ATM будет работать с новой средой па новых скоростях. Даже если к скоростям передачи разных данных предъявляются разные требования и они поступают от разных узлов, ATM пересылает их практически одновременно и без конфликтов. ATM посылает в несущую среду ячейки фиксированного размера в соответствии с параметрами, согласованными при соединении. ATM может обрабатывать изохронный трафик, например голосовую и видеоинформацию, одновременно с трафиком, не зависящим от времени (вроде LAN-данных). В следующем разделе описываются аппаратные компоненты, соединяющие конечные устройства ATM с ATM-сетью, и программное обеспечение, которое устанавливает, контролирует и поддерживает сетевые соединения.
Архитектура ATM ATM — это аппаратно-программные средства, на основе которых можно построить либо всю сеть, либо только высокоскоростные сетевые магистрали. Архитектура ATM определяется конкретной структурой ATM и ее программными компонентами.
574
ЧАСТЬ 4
Интеграция сетей и мультимедиа
Модель ATM Основными в модели ATM являются физический уровень, уровень ATM и уровни ATM Adaptation.
Физический уровень Физический уровень обеспечивает прием и передачу ATM-ячеек по несущей среде между любыми двумя ATM-устройствами. Этот уровень разделяется на два подуровня: PMD (Physical Medium Dependent) и ТС (Transmission Convergence), Подуровень PMD Этот подуровень отвечает за прием и передачу индивидуальных битов по физической среде. Ои реализует синхронизации) битов, кодирование сигнала, взаимодействие с физической средой и саму среду (кабели). ATM не предъявляет конкретных требований к скорости передачи битов, способу кодирования и несущей среде. ATM позволяет использовать коаксиальный кабель, экранированную и неэкранированную витую пару, а также оптоволокно на скоростях от 64 Кбит/с до 9,6 Гбит/с. Кроме того. ATM поддерживает передачу данных на расстояния свыше 60 км при применении одномодового оптоволокна и лазеров дальнего действия, что дает возможность без проблем объединить сетью, например, студенческий кампус или даже построить городскую сеть (metropolitan area network, MAN). Независимость от конкретного аппаратного обеспечения позволяет реализовать ATM на радио- и спутниковых каналах связи. Подуровень ТС Этот подуровень работает как конвертер между потоком битов ATM-ячеек и подуровнем PMD. В процессе передачи ТС преобразует ATM-ячейки в формат подуровня PMD (например, в кадры DS-3 или SONET). Поскольку поток битов должен быть непрерывным, неиспользуемые части потока «заполняются* пустыми ячейками, которые определяются по заголовку и отбрасываются принимающей стороной; они никогда не передаются на уровень ATM. Подуровень ТС также создает и проверяет поле НЕС (Header Error Control) в каждой ячейке. На передающей стороне НЕС вычисляется и помещается в заголовок, а па принимающей стороне НЕС только проверяется, Ошибка в единственном бите исправляется, а результат передается на уровень ATM. Ошибки в неекольких битах исправлению не поддаются, и ячейка просто отбрасывается. Наконец, подуровень ТС отвечает за разграничение ATM-ячеек, т. е. указывает, где они начинаются и заканчиваются. Границы ячеек во входящем потоке байтов определяются с использованием поля НЕС.
Уровень ATM Этот уровень предоставляет функции для мультиплексирования и демультиплексирования ячеек, а также для манипуляций с VPI/VCL Кроме того, уровень ATM контролирует поток ячеек для соблюдения согласованных параметров соединения. Если параметры какого-либо соединения отклоняются от согласованных, уровень ATM делает так, чтобы некорректно работающее соединение не влияло на остальные соединения. Уровень ATM отвечает и за правильную последовательность передачи ячеек из любого источника.
ГЛАВА 14
ATM
575
Если ячейка отбрасывается коммутатором из-за перегрузки или повреждения, исправление этой ошибки не входит в обязанности уровня ATM. За это отвечают более высокие уровни: они должны самостоятельно распознавать потерю ячеек и либо передавать их повторно, либо игнорировать факт такой потери. При передаче видеоинформации или интерактивных голосовых данных потерянная ячейка обычно игнорируется, так как повторная передача и построение правильной последовательности для реконструкции звукового или видеосигнала займет слишком много времени. В таких случаях большое число пропущенных ячеек приводит к тому, что воспроизведение аудио или видео становится прерывистым, но устранить эту проблему в ATM можно только одним способом: потребовать для соединения более высокое качество обслуживания. При передаче данных (например, файлов) протоколы более высокого уровня должны реагировать на потерю ячейки и посылать ее еще раз. Так как подобные операции не критичны по времени, задержка, связанная с восстановление ячейки, допустима. Здесь важнее точность передачи. Мультиплексирование и демультиплексирование При мультиплексировании на уровне ATM входные сигналы различных типов смешиваются, но их параметры соединения сохраняются. Этот процесс называется формированием трафика (traffic shaping), Демультиплексирование на уровне ATM заключается в разборе потока ATM-ячеек; при этом в зависимости от VPI/VCI каждая ячейка либо перенаправляется по другому адресу (в случае ATM-коммутатора), либо передается тому процессу уровня ATM Adaptation (AAL), который соответствует этой ячейке (в случае конечного устройства ATM).
Уровни ATM Adaptation Уровни ATM Adaptation (AAL) отвечают за создание и прием 48-байтовых порций данных от более низких уровней в интересах приложений различных типов. Существует 5 типов AAL, no Windows 2000 поддерживает только AAL5. ATM Adaptation необходим для сопряжения основанной на ячейках технологии ATM с потоками битов, которыми оперируют цифровые устройства (например, телефоны и видеокамеры), и с технологиями современных сетей передачи данных (Frame Relay, X.25, TCP/IP и др.). Каждый из пяти AAL предоставляет свой класс сервисов, AALO. Эквивалентен «No AAL», т. е. никакой уровень AAL не применяется. Например, при использовании AAL5 данные не передаются уровню ATM до тех пор, пока не будет получен полный сегмент. В случае AALO данные не размечаются и не синхронизируются, так что ячейки передаются уровню ATM либо по мере их приема, либо, если адаптер это поддерживает, определенными порциями. AAL1. Обеспечивает эмуляцию цепи поверх ATM-сети. Для этого нужны постоянная скорость передачи битов и изохронный трафик. Поэтому AAL1 добавляет временные метки, выполняет проверку на ошибки и формирует правильную последовательность данных. Кроме того, AAL1 позволяет дополнять 48-байтовые полезные данные ячеек несколькими фрагментами длиной менее 48 байтов, что обычно требуется при потоковой передаче голосовых данных. Из-за высоких издержек AAL1 применяется, только если его функциональность действительно необходима.
576
ЧАСТЬ 4
Интеграция сетей и мультимедиа
Обычно он используется приложениями, которые передают и принимают голосовые и видеоданные. AAL2. Это механизм, позволяющий вести высокоскоростную передачу данных с переменной скоростью. В отличие от AAL1 в AAL2 полоса пропускания используется только при передаче данных. AAL2 не получил широкого распространения и практически вытеснен AAL5. AAL3/4. AAL3/4 объединяет две спецификации AAL, которые раньше были раздельными. AAL3 был введен для формирования кадров по протоколам, ориентированным на логические соединения, a AAL4 — для формирования кадров по протоколам, не требующим таких соединений. Впоследствии комитет по стандартам выяснил, что в формировании кадров но протоколам этих двух типов нет никакой разницы, и поэтому два метода были объединены в AAL3/4. Этот A A L добавляет к полезной нагрузке информацию о размере сегмента и последовательности данных. Однако AAL3/4 используется редко из-за высоких издержек. Те же сервисы при минимальном уровне издержек предоставляет AAL5. AAL5. Позволяет приложениям, не ориентированным на логические соединения и не требующим изохронного трафика, передавать и принимать данные с переменной скоростью. AAL5 разработан для более эффективной передачи данных, чем при использовании AAL3/4. AAL5 просто добавляет к полезным данным концевую часть (трейлер), в которой указывается их размер и информация, необходимая для обнаружения ошибок. AAL5 следует использовать при передаче LAN-трафика с установлением или без установления логических соединений поверх ATM-сети. Windows 2000 поддерживает именно AAL5. AAL5 в деталях AAL5 формирует кадры на подуровне CPCS (Common Part Convergence Sublayer), который работает сходным образом с существующими LAN-технологиями вроде Ethernet, Схема полезных данных и заголовка ячейки AAL5 представлена на рис. 14-5. Подуровень CPCS Полезные данные CPCS PDU
1-65535 байтов 0-47 байтов
PAD Концевая часть CPCS PDU — 8 байтов
Информация о пользователях AAL
1 байт
Информация об общей части
1 байт
Размер полезных данных CPCS PDU
2 байта
CRC
4 байта
Подуровень SAR Заголовок ATM-ячейки
РТшШИЩб байтов
Полезные данные SAR PDU
48 байтов
П
= 1 байт
Рис. 14-5. Полезные данные и AAL5-зaгoлoвoк ячейки
ГЛАВА 14
ATM
577
AAL5 исключает двойную инкапсуляцию. Кадры формируются па полуровне CPCS, а не на подуровне SAR (Segmentation and Reassembly), что уменьшает издержки. AAL5 наиболее эффективен при передаче поверх ATM-сети трафика любых LAN-протоколов независимо от того, ориентированы они на логические соединения (Х.25, Frame Relay) или нет (IP, IPX). ААЬ5-подуровень CPCS. Этот подуровень формирует кадры, как показано на рис. 14-5 (заметьте, что добавляется только концевая часть). Полезные данные CPCS PDU. Блок данных, посылаемых приложением. Его размер может варьироваться от 1 до 65535 байтов. Поле PAD дополняет полезные данные пустыми байтами (от 0 до 47), выравнивая размер данных до значения, кратного -18 байтам. Информация о пользователях AAL. пользователями AAL.
Информация, которая передается между
Информация об общей части. В настоящее время используется только для выравнивания (чтобы концевая часть AAL5 была равна 64 битам). Поле размера полезных данных CPCS PDU. Содержит длину полезных данных CPCS PDU в байтах. PAD в это значение не включается. CRC (циклический избыточный код). Поле длиной 4 байта для контроля ошибок в CPCS PDU. Для подсчета CRC используется тот же алгоритм, что и в сетях на основе 802..г, например Ethernet или Token Ring. AALS-подуровень SAR, Что происходит на этом подуровне при формировании кадров, показано на рис. 14-5. Концевая часть и заголовок SAR не добавляются. На передающей стороне этот подуровень просто разбивает CPCS PDU на блоки по 48 байтов и передает их на уровень ATM, где формируется окончательный ATM-заголовок. На принимающей стороне AAL5-подуровень SAR восстанавливает данные из 48-байтовых блоков и передает результат CPCS. В третьем бите поля РТ (Payload Type) AAL5 SAR указывает, что данный 48-байтовый блок последний. Получив ATM-ячейку с установленным третим битом в поле РТ, уровень ATM сообщает об этом уровню AAL, и тот проверяет CRC и длину полной последовательности данных CPCS PDU.
Структура ATM-ячейки ATM-ячейка всегда состоит из заголовка длиной 5 байтов, за которым следуют полезные данные размером 48 байтов. Заголовок состоит из 6 полей (рис. 14-6). GFC. Поле GFC (Generic Flow Control) длиной 4 бита изначально было добавлено для поддержки соединения ATM-сетей с сетями разделяемого доступа, например кольца DQDB (Distributed Queue Dual Bus). GFC предназначалось для согласования параметров мультиплексирования и управления потоками ячеек разных ATM-соединений. Однако значения GFC так и не были стандартизированы, поэтому биты этого поля всегда устанавливаются в 0000. VPI. Поле VP1 (Virtual Path Identifier) определяет виртуальный путь ячейки VPI либо автоматически задается на этапе установления соединения, если используется коммутируемая виртуальная цепь (switched virtual circuit, SVC), либо настраивается вручную в случае постоянной виртуальной цепи (permanent virtual circuit, PVC). Поле VPI длиной 8 битов допускает до 256 виртуальных путей. VPI 0 существует по умолчанию на любом оборудовании ATM и применяется в адмипистра-
578
ЧАСТЬ 4
Интеграция сетей и мультимедиа
тивных целях, например для уведомления о создании и удалении динамических AT М-соединений. VCI. Поле VCI (Virtual Channel Identifier) определяет виртуальный канал в рамках данного виртуального пути конкретной ячейки. Как и VPI, VCI задается либо автоматически на этапе установления соединения (для коммутируемых виртуальных цепей), либо вручную (для постоянных виртуальных цепей). VCT длиной 16 битов поддерживает до 65536 виртуальных каналов для каждого виртуального пути. VCT от 0 до 15 зарезервированы ITU, a VCI от 16 до 32 — ATM Forum. Зарезервированные VCI используются для уведомления о различных событиях, для обслуживания и управления ресурсами. Комбинация значений VPI и VCI идентифицирует виртуальную цепь для конкретной ATM-ячейки. Такая комбинация предоставляет ATM-коммутатору информацию, необходимую ему для пересылки данной ячейки адресату. Однако комбинация VPI/VC1 не является адресом сетевого уровня, как, например, IP- или IPX-адрес. VPI/VCI используется как локальный идентификатор виртуальной цени по аналогии с LCN (Logical Channel Number) ц сетях Х.25 и с DLCI (Data Link Connection Identifier) в сетях Frame Relay, На любом конечном устройстве ATM или АТМкоммутаторе пара VPI/VCI однозначно определяет виртуальную цепь до следующего конечного устройства ATM или АТМ-коммутатора. Комбинация VPI/VCI уникальна для каждого пути передачи (т. е. для каждого кабеля или соединения с ATM-коммутатором). Однако две виртуальных цепи на разных портах ATM-коммутатора вполне могут иметь одну и ту же пару VPI/VCI, и конфликт при этом не возникает.
CLP
Подуровень CPCS 4 бита 16 битов
Рис. 14-6. Структура заголовка ATM-ячейки РТ. Поле РТ (Payload Type) длиной 3 бита. Первый бит определяет тип следующей ATM-ячейки: О указывает, что это пользовательские данные, 1 — что это данные, связанные с функционированием, администрированием и управлением (opera-
ГЛАВА 14
ATM
579
tions, administration and management, OA&M). Второй бит сообщает, попадала ли данная ячейка в затор на своем пути от источника к получателю. Этот бит также называется битом EFCI (Explicit Forward Congestion Indication). Источник задает второй бит равным 0; если при перенаправлении ячейки на промежуточном коммутаторе был затор, этот бит устанавливается в 1. После того как бит установлен в 1, остальные коммутаторы на пути передачи ячейки сохраняют его значение. Принимающие устройства могут использовать бит EFCI для реализации механизмов регулирования потока данных, уменьшая скорость передачи до тех пор, пока не будет получена ячейка с нулевым битом EFCI. Третий бит идентифицирует последнюю ячейку в блоке для AAL5 в ATM-ячейках с пользовательскими данными. В ином случае третий бит предназначен для функций ОА&М. CLP. Поле CLP (Cell Loss Priority) длиной 1 бит используется как индикатор приоритета. Если этот бит равен 0, ячейка обладает высоким приоритетом, и промежуточные коммутаторы должны сделать максимум возможного для ее успешной доставки. Если бит CLP установлен в 1, промежуточные коммутаторы могут отбрасывать ячейку при заторах. Бит CLP аналогичен биту DF (Discard Eligibility) в сетях Frame Relay. Конечное устройство ATM устанавливает бит CLP в 1 при создании ячейки с низким приоритетом. ATM-коммутатор тоже может установить этот бит в 1, если данная ячейка нарушает согласованные параметры. Примерно то же самое происходит при передаче данных на скорости выше CIR (Committed Information Rate) в сетях Frame Relay. НЕС. Поле НЕС (Header Error Control) длиной 8 битов позволяет АТМ-коммутатору или конечному устройству исправлять ошибку в единственном бите и обнаруживать ошибки в нескольких битах первых четырех байтов ATM-заголовка. Ячейки с ошибками в нескольких битах «молча» отбрасываются. НЕС контролирует только ATM-заголовок. Проверка ошибок в полезных данных возлагается на протоколы более высокого уровня.
Виртуальные пути и виртуальные каналы Чтобы понять, как ATM передает данные по сети, Вы должны понять, что такое путь передачи, виртуальный путь и виртуальный канал (рис. 14-7).
\
Путь передачи
Виртуальные каналы L
Виртуальный путь
Рис. 14-7. Среда передачи «в разрезе» Путь передачи. Физический кабель, соединенный с определенным портом АТМкоммутатора. Кабель имеет свою полосу пропускания, например 155 Мбит/с для оптоволокна ОС-3 (Optical Carricr-3).
580
ЧАСТЬ 4
Интеграция сетей и мультимедиа
Виртуальный путь. Полоса пропускания пути передачи логически делится на виртуальные пути, которые идентифицируются по VPI о ATM-заголовке. Каждому виртуальному пути выделяется некая фиксированная часть полосы пропускания. После создания виртуальных путей их полоса пропускания не изменяется. Виртуальный канал. Полоса пропускания виртуального пути логически делится на виртуальные каналы, которые идентифицируются по VCI в ATM-заголовке. Полосу пропускания виртуального канала можно динамически изменять в пределах того, что выделено соответствующему виртуальному пути.
Коммутация на различных уровнях В основе ATM-коммутации лежит иерархия «путь передачи, виртуальный путь, виртуальный капал». Коммутация ячеек возможна на каждом из этих трех уровней. Коммутация на уровне пути передачи Коммутация на этом уровне позволяет ATM-коммутатору определять, через какой выходной порт следует пересылать ячейку. Коммутация на уровне виртуального пути Коммутация па этом уровне позволяет коммутировать целые группы виртуальных каналов. Она аналогична перекрестной коммутации групп вызовов в телефонной сети на основе кода города; коммутация осуществляется на основе именно кода города, а не семизначного телефонного номера. При коммутации на уровне виртуального пути во внимание принимается только VPI из заголовка ATM-ячейки. Благодаря тому, что остальные данные заголовка игнорируются, коммутация на уровне виртуального пути работает быстрее, чем коммутация на уровне виртуального канала. Коммутация на уровне виртуального канала Коммутации на этом уровне обеспечивает гибкость в выделении полос пропускания. Она аналогична коммутации телефонных вызовов на основе последних семи цифр номера. Такая коммутация осуществляется и в частных, и в общедоступных ATM-сетях. При этом коммутатору нужно анализировать как VPI, так и VCI.
Quality of Service При согласовании параметров соединения конечные устройства ATM заключают контракт, гарантирующий определенное качество обслуживания. Такие гарантии Quality of Service (QoS) не предоставляются традиционными LAN-технологиями. В традиционных LAN любые методы реализации гарантированного качества обслуживания базируются на приоритетах; при этом один из источников получает преимущество в доставке его данных. Однако до передачи данных источнику не известно состояние сети или получателя (традиционные LAN не ориентированы на логические соединения), поэтому задержки трафика возможны как на маршрутизаторах, так и на любом участке маршрута. Из-за непредсказуемых задержек прогнозировать время доставки и доступную полосу пропускания крайне трудно. Хотя обычно трафик с высоким приоритетом доходит до получателя быстрее, чем трафик с низким приоритетом, изохронный трафик даже с очень высоким приоритетом может быть доставлен слишком поздно.
ГЛАВА 14
ATM
581
Примечание Термином «QoS*> обозначают разные виды гарантированного качества обслуживания, в том числе ATM QoS, RSVP и Generic QoS. Из этих трех на аипауровне реализуется только ATM QoS. Подробнее о других типах QoS см. главу 9 «Quality of Service» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». ATM предоставляет несколько четких градаций качества обслуживания. Отправитель может указать требования к полосе пропускания, максимальному времени задержки и т. д. После этого каждый ATM-коммутатор с учетом текущей нагрузки решает, сможет ли он обеспечить нужные условия. Если да, он гарантирует затребованный уровень качества обслуживания и выделяет соответствующие ресурсы. В ATM контракт на качество обслуживания обязателен для выполнения, а полоса пропускания выделяется па аппаратном уровне; прежде чем контракт будет принят, с ним должны согласиться все коммутаторы, находящиеся между получателем и отправителем, Аппаратное обеспечение отправителя (также принявшее контракт) отвечает за формирование трафика в соответствии с условиями контракта. ATM предлагает 5 категорий обслуживания. •
•
•
•
•
CBR (Constant Bit Rate). Постоянная скорость передачи битов. Данные посылаются равномерно, число теряемых ячеек очень мало. Обслуживание этой категории весьма дорогостоящее, так как требует выделения заданной полосы пропускания независимо от того, полностью ли она используется. CBR обычно применяется для эмуляции пеней. Windows 2000 поддерживает CBR. VBR (Variable Bit Rate). Указывается общая пропускная способность, но данные посылаются не с постоянной скоростью. Число теряемых ячеек также невелико. Существует два варианта VBR: в реальном времени (для приложений с изохронным трафиком) и не в реальном времени (для всех остальных). ABR (Available Bit Rate). Гарантирует минимальную полосу пропускания, но, если сеть не загружена, данные могут посылаться с большей скоростью. Число потерянных ячеек невелико. ABR обеспечивает более высокую производительность по сравнению с VBR, при этом издержки ниже, чем при использовании CBR. Важно отметить, что ABR окончательно определен литпь недавно, и не все аппаратно-программные средства поддерживают его. ABR — часть спецификации UNI 4.O. UBR (Unspecified Bit Rate). He гарантирует полосу пропускания или пропускную способность; ячейки могут теряться. При UBR-соединении контракт с ATM-сетью не заключается. Windows 2000 поддерживает (JBR. WUBR (Weighted Unspecified Bit Rate). Новейшая категория, разработанная ATM Forum. При WIJBR разным видам трафика присваиваются разные приоритеты обработки (как в традиционных LAN-технологиях, не требующих логических соединений). Каждый вид трафика передается по отдельному соединению. Ячейки, посылаемые по низкоприоритетным соединениям, отбрасываются в первую очередь.
Гарантированное QoS позволяет использовать приложения с изохронным трафиком. Хотя 100-мегабитный Ethernet и другие высокоскоростные сети обеспечивают сравнимую с ATM полосу пропускания, только ATM предоставляет гарантии
582
ЧАСТЬ 4 Интеграция сетей и мультимедиа
QoS, необходимые для телефонии реального времени, потоковой передачи видео с качеством VHS и звука с CD-качеством, видеоконференций и др.
ATM-адреса ATM-адреса нужны для использования виртуальных соединений в ATM-сети. Они имеют длину 20 байтов и состоят из трех частей. Упрощенная схема ATM-адресации показана на рис. Н-8. г 13 байтов
Информация об ATM-коммутаторе
г 6 байтов
г 1 байт
ПТГП1а НИ МАС-адрес ада пте Р 1Я |> H i
т
Идентификатор конечной точки
Конечная точка 1 Конечная точка 2 ! Конечная точка 3 АТМ-коммутатор Рис. 14-8. Упрощенная схема ATM-адресации
ATM-адрес разбивается на три основные части. Идентификатор ATM-коммутатора. Первые 13 байтов идентифицируют конкретный коммутатор в ATM-сети. В ATM применяются три основные схемы адресации, и в каждой из них информация об ATM-коммутаторе представляется по-разному. Соответственно формат этой части адреса может быть одним из трех; DCC (data country/region code), 1CD (international code designator) и Е.164, предложенный ITU-T для международных телефонных номеров в широкополосных TSDN-сетях. МАС-адрес адаптера. Следующие 6 байтов определяют конечное устройство, например ATM-адаптер; в них записывается МАС-адрес, «зашитый?- в адаптер. МАСадреса используются в ATM точно так же. как и в других технологиях IEEE 802.д: (Ethernet, Token Ring и т. д.). Селектор (SEL). Последний байт предназначен для выбора логического соединения на конечном устройстве. Хотя все ATM-адреса соответствуют этой базовой структуре, формат первых 13 байтов зависит от схемы адресации и вида ATM-сети (частная или общедоступная). Все три применяемых в настоящее время формата ATM-адресов (DCC, ICD и Е.164) обладают двумя характеристиками: • совместимостью с планом адресации NSAP (Network Service Access Point), как предложено ISO в модели OSI; • любой из них можно использовать для соединения частных ATM-сетей, поддерживающих коммутируемые виртуальные цени.
Адресация в деталях ATM-адреса используются в виртуальных цепях для установления соединений между конечными устройствами ATM. Тип ATM-адреса зависит от того, является ли сеть частной или общедоступной. Три основных формата показаны на рис. 14-9,
ГЛАВА 14 ATM • API
г DPI
осе
[-Зарезервировано 1
1
I
г—
АА
RO
583
г SEL I
Область Идентификатор конечной системы 1
Формат адреса DCC г AI-I
k
г им
icb |
[- зарезервировано
'АА '
RD
Область] Идентификатор конечной системы |
SE!
Г 1
Формат адреса ICD SEL
AFI
Телефонный номер Е.164 ISDN
RD
Область Идентификатор конечно*сиетвмы
Формат адреса Е.164 Рис. 14-9. Основные форматы ATM-адреса Формат Е.164 разработан специально для общедоступных ATM-сетей. Хотя детальное описание каждого поля выходит за рамки этой главы, наиболее важные поля этих форматов перечислены в таблице 14-1. Таблица 14-1. Основные поля ATM-адресов различных форматов Поля адреса
Описание
AF1
Однобайтовое поле AFI (authority and format identifier) указывает тип адреса Содержимое этого поля равно 45 для Е.164. 47 для ICD и 39 для DCC Однобайтовое иоле АА определяет часть адреса, специфичную для домена Зарезервировано на будущее Информации о маршрутизации в домене (2 байта) Идентификатор области (2 байта) Идентификатор конечного устройства, или МАС-адрес (6 байтов) Однобайтовый селектор NSAP Двухбайтовый международный код страны Телефонный номер ISDN (8 байтов для 16 цифр)
DCC АЛ
Зарезервировано RD
Область IМ
SEL
ICD Е.164
Включение МАС-адреса в ATM-адрес через поле ESI упрощает использование ATM-адресов в существующих LAN-технологиях, где применяются типы адресов IEEE 802jc.
Типы ATM-соединений AT М-соединения между конечными точками различаются не только по параметрам QoS и форматам адресов. Они также разделяются на две более крупные категории: соединения «один-к-одшшу» («точка-точка») и «один-ко-многим». Конкретный тип соединения зависит от того, как устанавливается ATM-соединение и какой сигнальный интерфейс это делает.
584
ЧАСТЬ 4
Интеграция сетей и мультимедиа
Сигнальные интерфейсы Сигнальные интерфейсы сущеетвуют на конечных устройствах и на АТМ-коммутаторах. Сигнальный уровень ATM (ATM signaling layer) отвечает за создание, управление и закрытие коммутируемых виртуальных цепей (SVC). Стандартный протокол передачи данных но несущей среде, реализуемый сигнальным программным обеспечением ATM, называется UNI (User Network Interface). В свою очередь АТМкоммутаторы используют между собой другой сигнальный интерфейс, называемый NNI (Network Network Interface). АТМ-сОвмвстимыЙ процесс
ATM-совместимый процесс
Послать пакет по этой VC
Создать VC с процессом В на адаптере 2
Принять запрос на создание VC
Сигнальный интерфейс UfJI Аппаратный интерфейс
Сигнальный интерфейс
Аппаратный -интерфейс ATMадаптер 1
Пакет, принятый по этой VC
ATMкоммутатор Сигнальные интерфейсы UNI и NNI
ATMATMадаптер 2 коммутатор Сигнальные интерфейсы UNI и NNI
Рис. 14-10. Сигнальные интерфейсы в ATM
Соединения «один-к-одному» Когда ATM-совместимый процесс пытается установить соединение с другим процессом в сети, он указывает сигнальному программному обеспечению установить SVC. С этой целью сигнальное программное обеспечение посылает запрос на создание SVC на ATM-коммутатор, используя ATM-адаптер и VC, зарезервированную для обмена уведомлениями. Этот запрос пересылается от одного АТМ-коммутатора другому, пока не попадет к адресату. Адрес следующего ATM-коммутатора определяется по ATM-адресу в запросе и внутренней базе данных (таблицам маршрутизации). Каждый коммутатор также определяет, может ли он обеспечить затребованные параметры QoS и категорию сервиса. На любом этапе процесса установления соединения между конечными точками любой коммутатор может отклонить запрос. Если все коммутаторы на пути передачи данных способны установить VC с требуемыми параметрами, адресат получает пакет с выданным номером VC. С этого момента ATM-совместимый процесс может обмениваться данными с другим процессом, напрямую посылая пакеты с VPI/VCI, идентифицирующими данную VC. ATM-адаптер формирует трафик для каждой VC так, чтобы он отвечал согласованным параметрам. Если по какой-то причине посылается слишком много данных,
ГЛАВА 14
ATM
585
ATM-коммутатор может проигнорировать (и потерять) часть данных, обеспечивая полосы пропускания для других соединений. Это справедливо для всей сети: если полоса пропускания или скорость превышает согласованные лимиты, любое устройство, включая ATM-адаптер, может просто отбросить данные. В таких случаях конечные устройства не уведомляются о потере ячеек.
Соединения «один-ко-многим» В отличие от стандартных LAN-сред ATM ориентирована на логические соединения и не предусматривает механизмов широковещательной или групповой рассылки пакетов. При необходимости широковещательной рассылки узел-отправитель может создать виртуальные пени со всеми получателями и посылать копию данных по каждой VC. Однако это крайне неэффективно. Лучше использовать соединения «один-ко-многим» (point-to-multipoint connections). Такое соединение связывает источник (корневой узел) с несколькими получателями (листьями). Если соединение разветвляется, ATM-коммутаторы копируют ячейки по каждой его ветви. Соединение «один-ко-многим» является однонаправленным, т. е. корень может передавать данные листьям, а листья не могут передавать данные корню или друг другу но этому соединению. Для передачи пакетов между листьями или от листа корню нужно создавать отдельное соединение. Одна из причин такого ограничения заключается в невозможности чередования ячеек из нескольких источников по одному соединению.
LAN Emulation LAN Emulation (LANE) — это набор программных компонентов, позволяющих ATM работать с унаследованными сетями и приложениями. LANE даст возможность использовать обычные LAN-приложения и протоколы в ATM-сети бел модификации. Благодаря LANE протоколы ATM-уровней кажутся таким приложениям и протоколам средой Ethernet или Token Ring. LANE — ото нечто среднее между «полной» ATM и ее отсутствием. LANE может повысить скорость передачи данных для существующих приложений и протоколов, если ATM используется в высокоскоростной среде, по, к сожалению, LANE не позволяет задействовать такие возможности ATM. как QoS.
Архитектура LANE Базовыми компонентами LANE являются клиент и службы LANE. Клиент L A N E позволяет LAN-протоколам и приложениям работать так же, как и при коммуникационной связи по обычной LAN. Па верхнем (пользовательском) уровне клиент LANE предоставляет функциональность LAN, а на нижнем (на уровне протоколов ATM) — функциональность ATM. Службы LANE — это набор «родных» ATM-приложений, скрывающих свою ориентацию на логические соединения от унаследованных протоколов, которые не используют такие соединения. Эти службы поддерживают базы данных, необходимые для сопоставления LAN- и ATM-адресов, что дает возможность клиентам LANE создавать соединения и посылать данные. Компоненты служб LANE могут находиться в любом участке ATM-сети, хотя обычно они устанавливаются на ATM-коммутаторах. Так что с практической точки зрения, службы LANE работают на ATM-коммутаторе или группе коммутатором.
586
ЧАСТЬ 4 Интеграция сетей и мультимедиа
Три основные службы LANE — сервер конфигурации LANE (LAN Emulation configuration server, LEGS), сервер эмуляции LAN (LAN emulation server, LES) и сервер BUS (Broadcast and Unknown server). LEGS распространяет клиентам конфигурационную информацию, необходимую им для регистрации в сети. LES управляет одной или несколькими эмулированными LAN (Emulated LAN, ELAN); он отвечает за добавление новых членов в ELAN, поддержку списка всех членов ELAN и обработку запросов на разрешение адресов от клиентов LANE. BUS предоставляет сервисы широковещания и групповой рассылки, как показано на рис. 14-11.
Клиент LAN Emulation AT М- протокой
UNI
Аппаратный интерфейс | LEGS
AT WI-
BUS
ATM-
коммутатор
адаптер Рис. 14-11. LECS, LES, BUS и клиент LANE Присоединяясь к сети, клиент LANE сначала ищет LEGS, поскольку тот должен предоставить ему адрес LES, управляющего нужной клиенту ELAN. Без адреса LES клиент не может связаться с другими членами ELAN. К сожалению, на этапе инициализации еще нет соединения между клиентом и ATM-коммутатором или любым другим устройством, на котором выполняется LEGS. Клиенту нужно установить ATM-соединение, желательно напрямую с сервером конфигурации. Если в ATM-сети присутствует только один ATM-коммутатор, на котором выполняются все службы LANE, задача поиска LEGS решается просто. Если же в сети установлено несколько коммутаторов, то не исключено, что на локальном коммутаторе, с которым клиент LANE соединяется напрямую, нет всех необходимых служб LANE. Однако LANE предоставляет механизмы для обнаружения LEGS клиентом LANE. Механизмы обнаружения LEGS Для соединения с LEGS клиент LANE может: • использовать общеизвестный ATM-адрес, определенный в протоколе ATM; •
задействовать общеизвестную VC;
•
послать запрос, используя интерфейс 1LMI (Integrated Local Management Interface).
Общеизвестные ATM-адрес и номер VC стандартизированы. Большинство коммутаторов и клиентов предварительно настраиваются на использование именно этой информации. Чаще всего клиент LANE может обнаружить LECS одним из двух первых методов, перечисленных выше. Но если общеизвестные значения на конечном устройстве или коммутаторе изменены, первые два метода не сработают.
ГЛАВА 14
ATM
587
В таких случаях клиент LANE может перейти на 1LMI — стандарт, разработанный для администрирования и конфигурирования ATM-сетей и аналогичный SN.V1P. В ILMI определена функция запроса, через которую клиент LANE может обнаружить адрес LECS, а затем создать с ним VC. Обнаружив LEGS и соединившись с ним, клиент запрашивает у LEGS конфигурационную информацию, необходимую для соединения с указанной ELAN. Для этого он посылает сведения о требуемой ELAN, например тип LAN (Ethernet или Token Ring), максимальный размер пакетов и имя LAN. LECS получаст данные от клиента LANE и ищет совпадение в своей таблице, в которой хранятся данные о различных ELAN. После обнаружения требуемой ELAN он возвращает ее адрес клиенту LANE. Сопоставление адресов на LES Подучив данные от LEGS, клиент может присоединиться к ELAN, для чего посылает LES адрес ELAN и собственный ATM-адрес, Эта информация регистрируется LES, и с этого момента клиент LANE может посылать данные по ATM-сети как в обычной LAN. Когда клиент LANE получает по какому-либо протоколу (например, TCP/IP, IPX или NetBEUI) запрос на передачу информации другому узлу в ELAN, он посылает LES LAN-адрес получателя. LES ищет в своей базе данных совпадение и возвращает ATM-адрес клиенту LANE. Затем клиент устанавливает обычную VC, больше не используя ни LES, ни другие службы LANE. В процессе обработки запроса на разрешение адреса трафик посылается BUS, откуда рассылается на все станции ELAN. Если LES не находит совпадение для указанного адреса получателя, данные передаются BUS, а тот пытается доставить их неизвестному клиенту (подробнее об этом см. следующий раздел). Распространение данных BUS BUS выполняет две функции: пересылает данные неизвестным клиентам и эмулирует службы широковещания LAN. Если LES не обнаружил запись об определенном клиенте, данные посылаются BUS для распространения, и BUS направляет эти данные всем клиентам ELAN. Кроме того, BUS реализует широковещательную рассылку; для этого он регистрирует свой адрес на LES так же, как и клиенты. Он регистрируется под адресом ОхЕ (15), обычным для LAN адресом широковещательных рассылок. Посылая широковещательное сообщение, клиент LANE направляет его на этот адрес. LEGS посылает соответствующий запрос. LES, который разрешает этот адрес и возвращает ATMадрес BUS. Затем клиент отправляет это сообщение BUS. Последний хранит список всех клиентов в ATM-сети и рассылает полученное сообщение всем клиентам, Обычно BUS работает на том же устройстве, что и LES. ILMI
ILMI размещается на ATM-коммутаторе и предоставляет UNI-интсрфейсу сервисы диагностики, мониторинга и конфигурирования. Стандарт ILMI определен ATM Forum и использует SNMP и М1В (Management Information Base). On работает поверх AAL3/4 или AAL5 (его VPI/VCI по умолчанию — 0/16). ILMI MIB хранит данные о физическом уровне, локальные VPC и VCC, префиксы сетей, административные и конфигурационные адреса, статистику уровня ATM и
588
ЧАСТЬ 4 Интеграция сетей и мультимедиа
информацию о самом уровне ATM. Наиболее часто используемая функция ILMI помощь клиенту в обнаружении LECS. Подробнее о специфике ILMI MIB см. RFC 1695.
Функционирование LANE ATM часто используется в качестве высокоскоростной сетевой магистрали для эмулированной LAN. Ниже дано несколько рекомендаций по настройке и поддержке клиентов LANE. Настройка клиента LANE Вся информация о конфигурировании платы ATM-адаптера и клиента LANE содержится в справочной системе Windows 2000 Server. Там подробно описываются все действия, которые нужно выполнить для добавления нового клиента к существующей ELAN. Как избежать потери клиентской информации при обновлении операционной системы с Windows NT 4.0 до Windows 2000
Перед обновлением операционной системы с Windows NT 4.0 до Windows 2000 запишите следующую информацию о конфигурации каждого обновляег^ого клиента ELAN. •
Имя ELAN. В Control Panel операционной системы Windows NT 4.0 дважды щелкните значок Network. В диалоговом окне Network and Dial-Up Network Connections выберите вкладку Identification. Запомните или запишите имя ELAN, указанное в поле Domain Name.
• Тип LAN. Тип несущей среды, которую Вы собираетесь эмулировать, — Ethernet или Token Ring. •
ATM-адреса LES и BUS, связанных с этой ELAN. Чтобы выяснить эти адреса, откройте Control Panel и дважды щелкните значок Network, В диалоговом окне Network and Dial-Up Network Connections выберите вкладку Adapters и откройте диалоговое окно Hardware Properties.
•
Максимальный размер пакетов ELAN. В Control Panel дважды щелкните значок Network, перейдите на вкладку Adapters и откройте диалоговое окно Windows NT 4.0 Properties.
Записав параметры конфигурации, используйте интерфейс LECS на своем АТМкоммутаторс для настройки всех ELAN и их параметров, включая имя ELAN, тин несущей среды, адреса LES и BUS, а также максимальный размер пакетов. Затем установите Windows 2000 и для каждого LEC укажите имя ELAN (см. справочную систему Windows 2000 Server). В Windows 2000 клиенты LANE автоматически настраиваются на ELAN по умолчанию — так же, как и современные АТМкоммутаторы. Это упрощает настройку в малых сетях.
Отказоустойчивость клиента LANE В случае сбоя LECS или LES клиент LANE is Windows 2000 повторяет процесс инициализации с этапа обнаружения LECS. Поэтому, если произойдет сбой сервера LANE, а затем его работа возобновится, клиент LANE автоматически повторит регистрации) (без имешатслъства со стороны пользователя). За отказоустойчивость в основном отвечают LECS и LES. Клиент LANE способен лишь обнаружить сбой и перезанустшъся.
ГЛАВА 14
ATM
589
Некоторые коммутаторы поддерживают резервный LEGS или LKS, который включается в работу при сбое текущего сервера. В таком случае резервный LECS регистрируется по тому же общеизвестному адресу, что и отказавший LEGS.
TCP/IP поверх ATM Протокол классического IP поверх ATM (classical IP over ATM, CLIP/ATM) определен в RFC 1577 и в более поздних документах. Windows 2000 полностью поддерживает этот стандарт, IP поверх ATM дает несколько преимуществ по сравнению с ELAN. Самые очеиидные из них: поддержка интерфейсов QoS, меньшие издержки (не требуется МАСзаголовок) и отсутствие ограничений на размер кадра. Все :-mi преимущества рассматриваются в следующих разделах.
Архитектура IP поверх ATM IP поверх ATM представляет собой группу компонентов, не обязательно сосредоточенную в одном месте, в силу чего соответствующие службы обычно не устанавливаются на ATM-коммутаторе. Иногда изготовители коммутаторов предусматривают частичную аппаратную поддержку IP поверх ATM. (Далее предполагается, что службы IP поверх ATM установлены на сервере Windows 2000.) Основные компоненты, необходимые для работы IP поверх ATM, - примерно те же, что и требуемые для работы LANE. Взаимодействие между средой, ориентированной на логические соединения, и средой, не ориентированной на такие соединения, в IP поверх ATM реализуется сервером IP ATMARP для каждой IP-подсети. Этот сервер поддерживает базу данных IP и ATM, а также обеспечивает сервисы широковещания и конфигурирования.
Компоненты IP поверх ATM IP поверх ATM — очень тонкий промежуточный уровень между протоколами ATM и TCP/IP Как и в случае LANE, па верхнем уровне клиент эмулирует стандартный IP для TCP/IP, а на нижнем уровне посылает ATM-команды ATM-протоколам. IP поверх ATM часто предпочтительнее LANE ввиду того, что работает быстрее. Основная причина такого преимущества в скорости заключается в том, что IP поверх ATM почти не добавляет дополнительные заголовки в пакеты при их передаче по стеку протоколов. Как только соединение установлено, клиент IP поверх ATM пересылает данные практически без изменений. IP поверх ATM реализуется двумя основными компонентами; сервером и клиентом IP поверх ATM. Сервер состоит из служб ATMARP и MARS (Multicast Address Resolution Service). Первая отвечает за сопоставление одновещательных IP-адресов с ATM-адресами, вторая — за-сопоставление аналогичных широковещательных и групповых адресов. Обе службы поддерживают базу данных IP-адресов — так же, как и службы LANE. Сервер IP поверх ATM может быть размещен более чем на одном компьютере, но базы данных ATMARP и MARS нельзя распределять. Например, один сервер IP поверх ATM может обрабатывать трафик ATMARP. другой - трафик MARS. Однако, если Вы распределяете сервер ATMARP между несколькими компьютерами, это в конечном счете приводит к создании) двух разных IP-сетей. Все клиенты IP поверх ATM в одной логической IP-подсети должны быть настроены на использо-
590
ЧАСТЬ 4 Интеграция сетей и мультимедиа
вание одного и того же сервера ATMARP. Для пересылки пакетов между логическими IP-подсетями (даже если они принадлежат одной и той же физической сети) применяются традиционные способы маршрутизации. В Windows 2000 реализованы полностью интегрированные серверы ATMARP и MARS. Подробнее об этих серверах см. в следующих разделах.
Сервер ATMARP Клиент IP поверх ATM и сервер ATMARP взаимодействуют так же, как и клиент LANE с LECS, когда первый из них присоединяется к сети и пытается идентифицировать других членов этой сети. Как и в LANE, после определения нужного адреса ATM берет передачу данных на себя, и TCP/IP-пакеты посылаются по виртуальной цепи (VC) от одного конечного устройства другому. Однако клиент IP поверх ATM обнаруживает сервер ATMARP совершенно иначе. Обнаружение сервера ATMARP Поскольку сервер ATMARP обычно размещается на серверном компьютере, а не на AT М-коммутаторе, ILMI или VC с общеизвестным номером для определения адреса ATMARP не годится. Фактически механизма обнаружения сервера, применяемого по умолчанию, нет. Чтобы начать использовать IP поверх ATM, администратор должен вручную указать ATM-адрес подходящего сервера ATMARP на каждом клиенте IP поверх ATM. В сети с одним ATM-коммутатором это нетрудно, но в больших сетях выливается в серьезную проблему. Для упрощения настройки в малых сетях службы и клиенты ARP/MARS в Windows 2000 используют адрес по умолчанию. Подробнее об этом см. в справочной системе Windows 2000 Server.
MARS Как и BUS в LANE, MARS отвечает за доставку широковещательных и групповых сообщений всем членам группы многоадресной рассылки. Из-за наличия потенциально «узких мест» MARS позволяет работать в двух режимах, Когда клиент ATMARP получает запрос на передачу пакета на широковещательный или групповой IP-адрес, он посылает запрос MARS, чтобы получить по этому адресу список членов группы IP-рассылки. В первом режиме MARS возвращает список всех ATM-адресов, относящихся к этой группе. После этого клиент создает ATM-соединение «один-ко-многим» (РМР) с каждым адресатом из списка и пересылает пакет по этому соединению. Во втором режиме используется сервер групповой рассылки (multicast server, MCS). Он регистрируется на сервере MARS как MCS для одной или нескольких групп IP-рассылки. MCS получает информацию о членстве в группах, в том числе о клиентах, присоединяющихся к этим группам и покидающих их. Когда клиент посылает MARS запрос на разрешение группового адреса, MARS просто возвращает адрес MCS. В итоге пакет передается MCS, который сам создает РМР-соединение и рассылает пакет всем членам группы (или групп). На рис. 14-12 и 14-13 показаны примеры VC, создаваемых в каждом из этих режимов. Недостаток первого режима, при котором каждый клиент, посылающий пакеты группе, устанавливает собственное РМР-соединение со всеми членами группы, заключается в том, что приходится создавать большое количество VC. А недостаток второго режима (с использованием MCS) в том, что MCS является, во-первых, по-
ГЛАВА 14
ATM
591
тенциалыю уязвимым звеном, а во-вторых, потенциально узким местом, так как рассылает все групповые пакеты во все обслуживаемые группы.
MARS
Кяает«рн<ш Управляющие \ управляющая VC(PMP) '
Виртуальные соединения соединения, \ между- установленные 1 клиентом безМСЗ .. мп DC
MARS GO
: всеми
• ' :!!
$ клиентами
тс да .. 1. грудаавой рассылки от отправителя 1
всем
групповое рассылки : о! отправителя 2
получателям
Отправитель 1 Отправитель 2 Получатель 1 Получатель 2 Получатель 3 \
Рис. 14-12. Групповая IP-рассылка поверх ATM без MCS
MARS Виртуальные соединения, установленные с помощью MCS
\ .-,,... Л Кластерная Управляющие? управляющая соединения : VC (РМРЦ между : ; MARS со клиентом • | всеми 1 клиентами
MCS УСдля УСдяя УСдля групповой! грулповой|; группой и рассылки ;i рассылки от отпра- ; QI отпраt ;; вителя 2 i всем
| «MCS
\ получателям
Отправитель 1 Отправитепь 2 Получатель 1 Получатель 2 Получатель 3
Рис. 14-13. Групповая IP-рассылка поверх ATM с MCS
Функционирование IP поверх ATM С применением IP поверх ATM связаны примерно те же проблемы, что и с LANE. В частности, возникают сложности с разрешением адресов и широковещанием.
592
ЧАСТЬ 4
Интеграция сетей и мультимедиа
В обычной ATM-сети SVC-соединения создаются посылкой специального запроса на ATM-коммутатор с указанием ATM-адреса получателя. Поэтому, прежде чем IPузел сможет создать SVC, ему нужно разрешить IP-адрес получателя в ATM-адрес, Обычно, когда Ethernet-узлу требуется разрешить IP-адрес в МАС-адрес Ethernet, он передаст широковещательный кадр ARP-запроса. Но, как уже говорилось, в ATM нет аппаратной поддержки широковещания. Поэтому за разрешение IP-адресов в ATM-адреса отвечает протокол ARP (Address Resolution Protocol) на сервере ATMARP. Если узлу нужно разрешить IP-адрес, он посылает запрос серверу ATMARP локальной IP-подсети. Этот запрос содержит ATM- и IP-адреса отправителя, а также запрошенный IP-адрес. Если серверу ATMARP этот IP-адрес известен, он возвращает ответ с соответствующим ATM-адресом. А если запрошенный IP-адрес не найден, ATMARP возвращает отрицательный ответ (в отличие от ELAN, где в таких случаях сообщается адрес LANE BUS). Таким образом, устройство, пославшее ARP-запрос, может отличить ошибку из-за неизвестного адреса от ошибки из-за неработающего сервера ATMARP. В итоге получается тройственное сопоставление: IP-адрес, ATM-адрес и VPI/VCI. ТР- и ATM-адреса нужны для создания VC, а для передачи последовательности ячеек данных по VC используются IP-адрес и VPI/VCI. Конечное устройство ATM создает SVC-соединения с другими конечными устройствами внутри своей локальной подсети. Чтобы оно могло разрешить произвольный IP-адрес, ему должен быть известен ATM-адрес сервера ATMARP в локальной подсети. При запуске конечное устройство ATM создает VC с сервером ATMARP. После того как VC создана, сервер посылает конечному устройству запрос In ATM ARP. Когда конечное устройство ATM возвращает ответ, ATMARP получает IP- и ATM-адреса нового устройства. Именно так ATMARP формирует свою таблицу сопоставлений IP- и ATM-адресов. Инициализация клиента IP поверх ATM IP поверх ATM в Windows 2000 не требует применения Inverse ARP. Вместо этого клиент напрямую регистрируется на сервере. Этот процесс проходит без вмешательства пользователя. Процедура инициализации зависит от того, как назначается адрес клиенту — статически или динамически. При использовании статического IP-адреса Сначала клиент инициализируется и получает ATM-адрес от ATM-коммутатора. Далее он соединяется с сервером ARP/MARS и присоединяется к широковещательной группе. Сопоставление ATM-адреса клиента с его IP-адресом добавляется в базу данных сервера ATMARP Теперь клиент готов к передаче данных другим узлам (хостам). При использовании DHCP Соединение IP поверх ATM для единственного клиента IP поверх ATM с использованием DHCP устанавливается аналогичным образом, хотя некоторые отличия есть. Сначала клиент инициализируется и получает ATM-адрес от АТМ-коммутатора. Затем он соединяется с сервером ARP/MARS и присоединяется к широковещательной группе. Далее клиент соединяется с MCS и посылает DHCP-запрос.
ГЛАВА 14
ATM
593
MCS посылает широковещательный DHCP-запрос всем членам широковещательной группы. Получив запрос, DHCP-сервер возвращает DHCP-ответ. MCS рассылает этот ответ всем членам группы. Клиент получает DHCP-ответ и регистрирует свои IP- и ATM-адреса на сервере ARP/MARS. Теперь клиент готов к передаче данных другим хостам. Подробнее о DHCP см. главу 4 «DHCP» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». Логические IP-подсети Межсетевая IP-среда на основе LAN-технологи и состоит из участков, отделенных маршрутизаторами (подсетей). Маршрутизаторы соединяют сети и подсети друг с другом. IP-хост в любой сети может посылать IP-пакеты хосту в той же сети на его MAC-адрес, а в другие сети — через МАС-адрес маршрутизатора. Таким образом, сотни и тысячи хостов одной сети могут соединяться с сотнями и тысячами хостов в другой сети. Хотя этот подход отлично работает в средах, не требующих логических соединений (Ethernet или Token Ring), в ATM его следует применять с осторожностью. На рис. 14-14 показаны две логические IP-подсети (LIS) на одном коммутаторе. IP-сеть 137.107.56.0
г IP-сеть 137.107.68-0
Р-хост
IP-ХОСТ
IP-ХОСТ
US 2
LIS1
ATMкоммутатор
Рис. 14-14. Две логические IP-подсети на одном коммутаторе Прежде чем посылать пакеты, нужно создать соединение между отправителем и получателем на уровне ATM. В ATM-сети, использующей SVC, путь должен быть согласован коммутаторами, чтобы отправитель знал точный VPI/VCI-адрес для передачи ATM-ячеек. Хотя в одной IP-сети можно разместить сотни (и тысячи) конечных устройств ATM, это крайне непрактично. Хост, например сервер сети, не сможет создать необходимое количество VC со всеми хостами в такой сети- Чем больше виртуальных цепей, тем больше нужно ресурсов и тем выше издержки как для операционных систем, так и для аппаратного обеспечения IP-сети (АТМ--адаптерос и коммутаторов). А если соединение осуществляется через провайдера услуг ATM, это приведет и к значительному увеличению оплаты. Логические IP-подсети позволяют ограничить число конечных устройств ATM в IP-сети или подсети. IP-подсеть — это группа IP-хостов с одним идентификатором сети, напрямую связанных друг с другом виртуальными цепями (VC). На одном 20 Зак. 334-
594
ЧАСТЬ 4 Интеграция сетей и мультимедиа
ATM-коммутаторе можно создать несколько логических IP-подсетей и организовать виртуальную межсетевую среду. Обратите внимание на пример, представленный на рис. 14-14, где хосты в подсети 131,107.56.0/24 для обмена данными создают виртуальные цепи друг с другом (прямая доставка). Когда хосты подсети 131.107.56.0/24 обмениваются данными с хостами подсети 131.107.68.0/24, они создают VC с маршрутизатором и посылают IPпакеты именно ему (непрямая доставка). Тот в свою очередь создает VC с хостомполучателем и пересылает ему IP-пакет. IP-маршрутизатор подключен к нескольким подсетям. Если у него один ATM-интерфейс, он может использовать либо один ATM-адрес (с уникальным ESI), либо несколько ATM-адресов, изменяя последний байт в 20-байтовом ATM-адресе (поле SEL). Последний вариант рассчитан в основном на случай сбоя сервера, предоставляя клиентам резервную точку доступа. О создании логических IP-подсетей см. раздел «Утилита ATMARP» далее в этой главе.
Службы АТМ-коммутатора Общая схема ATM-протоколов, оборудования и взаимосоединений показана на рис. 14-15. К оборудованию относятся ATM-клиенты, ATM-коммутаторы и промежуточные устройства между ATM-совместимыми устройствами или приложениями и другими протоколами а средами. Под взаимососдинениями подразумеваются SVC и PVC, обслуживаемые локальным коммутатором (в центре схемы). Кроме того, на рис. 14-15 показаны клиенты LANE, которые присоединяются к локальному коммутатору, а также клиент, перенаправляемый LECS с локального коммутатора 2 на BUS, и службы LES на локальном коммутаторе 1. На нижнем уровне показаны клиенты ARP, ATM и др. (за исключением клиента удаленного доступа, изображенного в верхней части схемы). Различные виды промежуточных устройств показаны в центральной части схемы.
Службы ATM в Windows 2000 Здесь описываются средства поддержки ATM в Windows 2000 и демонстрируются некоторые из преимуществ интеграции этих средств с операционной системой. Windows 2000 обеспечивает поддержку ATM в трех основных областях: • API-интерфейсы и интегрированные сетевые службы для прямого доступа к ATM; • поддержка существующих сетевых протоколов; • поддержка широкого спектра ATM-адаптеров. Приложения могут обращаться к службам ATM напрямую, используя новый набор API-интерфейсов ATM, доступных через компоненты операционной системы, в том числе NDIS (Network Driver Interface Specification), Windows Sockets и TAPI/ DirectShow. Эти интерфейсы поддерживают доступ к службам ATM как в пользовательском режиме, так и в режиме ядра. Кроме того, Windows 2000 предусматривает поддержку более высокого уровня для работы с существующими сетевыми протоколами поверх ATM. Microsoft реализовала универсальный клиент LANE, компоненты IP поверх ATM, PPP поверх ATM,
ГЛАВА 14
WAN
ATM
595
WIndOWS 201)0
Удаленный ATM-коммутатор ATM-совмести мыв промежуточные устройства Локальный коммутатор 1 ATM-совместимое промежуточное «тройство (blade)
Службы эмуляции LAN (LES/BUS/IECS)
Маршрутизатор уровня 3
удаленного доступа
Локальный коммутатор 2
РРР- ррр-
кяивнт сервер
ftRP- ARP-
ARP-
А№
КЛИ9Н'
Существующий 1А1Ч-клиент с МАС-платой
Новый клиент клмвш
Широковещательные DHCP-пакеты
Рис. 14-15. Обобщенная архитектура ATM Windows Socket Service Provider и модули сигнального UNI-интерфейса для конечных устройств.
Компоненты Стоимость поддержки специализированных сетей (когда одна сеть предназначена для передачи данных, другая — для передачи видеоинформации, а третья — аудио-
596
ЧДСТЬ 4
Интеграция сетей и мультимедиа
информации) слишком высока. Однако современные технологии позволяют передавать данные любого тина по одной сети и объединять существующие сети в единую инфраструктуру. В частности, операционные системы семейства Windows предлагают богатые возможности соединений с использованием ATM, при этом поддерживая унаследованные системы. Microsoft обновила NDIS для поддержки «родных* ATM-команд. Так как многие приложения еще не умеют пользоваться службами ATM, .Microsoft добавила поддержку LAKE для LAN-приложений (Ethernet и др.)- По той же причине введена поддержка IP поверх ATM, которая исключает издержки, связанные со вставкой дополнительных заголовков в LAN-пакеты. Кроме того, Winsock 2.0 теперь поддерживает «родную» ATM, благодаря чему она доступна любым приложениям Windows Sockets (Winsock). TAPI теперь может перенаправлять вызовы в ATM-цепи (или из ATM-цепей на устройства и в сети других типов). Одним и,ч примеров является Microsoft DirectShow, а также РРР поверх ATM, применяемый в качестве протокола удаленного доступа в ATM. Потоковый фильтр RCA (Raw Channel Access) режима ядра позволяет использовать TAPI для подключения потока данных к фильтру RCA и передавать его по ATM-цепи (рис. 14-16). TAPI
Winsock 2.0
Унаследованные LAN-протоколы
(~
API для п ередачи данных без уста« овленин соединений
N01S5
Г
Режим ядра
TCP/IP
IAN ARP
Пользовательский режим
Winsock 2.0 поверх ATM
IF/ATM
TAPI NDIS 5 SP
GQoS
Клиент LANE API для управления соединениями
Г~
Диспетчер вызовов ATM UfJl 3.1 API для передачи данных с установлением соединений i Минилорт(ы) №154
Минипорт(ь) NDIS 5
; ; :
~^
Сетевые адаптеры для традиционных сетей
Сетевые адаптеры для ATM-сетей
Рис. 14-16. Службы ATM в Windows 2000 Эти службы дают возможность приложениям использовать сервисы ATM (например, QoS), а с помощью TAPI — достигать высчжого уровня интеграции существующих средств мультимедиа и сетевых протоколов.
ГЛАВА 14
ATM
597
Диспетчер вызовов в ATM Сигнальный компонент ATM, так же называемый диспетчером вызовов UNI, поддерживает создание и управление виртуальными цепями (VC). Далее поясняется, как работает диспетчер вызовов в ATM и как он обслуживает постоянные (PVC) и коммутируемые виртуальные цени (SVC). Различия в управлении PVC и SVC PVC практически ничем не отличаются от SVC, однако каждая PVC должна быть вручную настроена администратором на каждом устройстве, a SVC, напротив, настраивается динамически при создании. Каждое устройство на пути от одной конечной точки до другой (включая коммутаторы) само определяет свою роль в поддержке виртуальной цепи, на какое устройство пересылать запросы и может ли оно гарантировать запрошенное QoS. Ресурсы для PVC выделяются при первой настройке независимо от того, будут ли они нужны прямо сейчас, а ресурсы для SVC выдаются динамически. Параметры SVC и PVC хранятся в одинаковом формате во внутренних таблицах диспетчера вызовов, ATM-адаптера и ATM-коммутатора. Различие между этими двумя видами цепей заключается в том, как их параметры обрабатываются при инициализации. На этом этапе диспетчер вызовов проверяет в реестре наличие записи, относящейся к PVC. Если она есть, диспетчер сохраняет в своей таблице номер VC и другую информацию, в том числе параметры QoS, идентификатор процесса (точку доступа к сервису), а также адреса отправителя и получателя. При инициализации ATM-адаптеру ничего не известно о PVC. Пока кто-то (обычно администратор) не настроит приложение на использование PVC, оно тоже ничего не знает о PVC. Когда приложению требуется PVC, оно выдает ATM-запрос, указывая адрес получателя, QoS, номер VC и другие сведения. Вплоть до этого момента запрос на PVC обрабатывается так же, как и запрос на создание SVC. Диспетчер вызовов получает запрос и сравнивает полученные данные с записями во внутренней таблице виртуальных цепей. Если диспетчер обнаруживает совпадение и запись относится к PVC, он обрабатывает этот запрос иначе, чем запрос на создание SVC. Обычный запрос на создание SVC приводит к выполнению двух команд: первая определяет, может ли адаптер обработать другую VC, а вторая активизирует VC на всем ее пути через сетевые компоненты. Но когда приходит запрос на создание PVC, диспетчер исходит из того, что PVC уже установлена между конечными точками. Поэтому диспетчер посылает ATM-адаптеру два инициирующих вызова подряд. ATM-адаптеру не известно о том, что он работает с PVC. Он получает информацию о QoS и другие данные из передаваемых ему команд и определяет, как формировать трафик. С этого момента PVC работает идентично SVC,
Модуль эмуляции LAN Windows 2000 предоставляет службы клиента эмуляции LAN (LANE). Когда механизм Plug and Play обнаруживает ATM-адаптер и устанавливает требуемый драйвер, по умолчанию устанавливается и клиент LAKE. Это обеспечивает возможность соединений через LANE без дополнительных настроек — при условии, что службы LAXE: • установлены на коммутаторе и работают; • сконфигурированы на использован vie ELAN по умолчанию,
598
ЧАСТЬ 4
Интеграция сетей и мультимедиа
Для централизованного администрирования и упрощения настройки данная реализация клиента LANE позволяет указывать только имя ELAN. Прочие параметры (вроде MTU, типа ELAN и LES) клиент принимает от LECS. Если в LECS включена ELAN no умолчанию, настройка вообще не нужна. Подробнее о настройке клиента LANE см. справочную систему Windows 2000 Server. ATMARP и ARP MARS Поддержка IP поверх ATM интегрирована в Windows 2000. Фактически IP поверх ATM предлагает более удобные сетевые службы, чем LANE. Кроме того, по целому ряду причин IP поверх ATM работает быстрее LANE, и главная из них в том, что IP поверх ATM не включает в пакеты дополнительные заголовки при их передаче по стеку протоколов в несущую среду. Как только соединение установлено, клиент IP поверх ATM может передавать данные без какой-либо модификации. Таким образом, IP поверх ATM является компактным и быстродействующим уровнем между протоколами ATM и TCP/IP. IP поверх ATM напрямую предоставляет TCP/IP многие преимущества ATM. Благодаря этому приложения, работающие с TCP/IP (через Windows Sockets или другой интерфейс), могут работать и с ATM. В Windows 2000 клиент ATMARP (IP поверх ATM) поддерживает разрешение групповых адресов через MARS. Клиент включает службу ARP/MARS, позволяющую Windows выполнять функции сервера как ATMARP, так и MARS с интегрированным сервером групповой рассылки (MCS). О развертывании и настройке IP поверх ATM см. справочную систему Windows 2000 Server.
Поддержка API-интерфейсов: Winsock 2.0, TAPI и NDIS 5.0 Использование всех этих преимуществ стало возможным благодаря расширениям операционной системы. Самым важным из них является ориентированный на соединения сервис, добавленный в NDIS 5.O. Последний включает NDIS, ориентированный на соединения (connection-oriented NDIS, CoNDIS), новое расширение NDIS API для поддержки сред, требующих логических соединений. С помощью новых API приложения могут создавал, виртуальные цепи и указывать качество их обслуживания. CoNDIS поддерживает несколько диспетчеров вызовов, реализуя сигнальные интерфейсы, специфичные для различных несущих сред, в том числе диспетчер вызовов ATM. Кроме того, CoNDIS поддерживает соединения «одинко-многим», что обеспечивает эффективность сервисов групповой рассылки, как показано на рис. 14-17. На верхнем уровне NDIS находятся два компонента, которые интегрируют службы ATM с операционной системой и предоставляют доступ к ним через общеизвестные API. Теперь в Windows Sockets 2.0 встроена прямая поддержка ATM, реализуемая Windows Sockets ATM Service Provider. Эта поддержка обеспечивает прямой доступ к службам ATM из приложений, выполняемых в пользовательском режиме. Благодаря поддержке IP поверх ATM приложения Windows Sockets, использующие TCP/IP в качестве транспортного протокола, могут работать в ATM-сетях и обмениваться данными со стандартными IP-клиентами. Минипорт-драйверы ATM NDIS 5.0
Хотя NDIS 5.0 поддерживает как ориентированные на соединения, так и не ориентированные на соединения драйверы сетевых адаптеров, в ATM-сетях используются только первые.
ГЛАВА 14
ATM
599
Протоколы, совместимые с CoNDIS NDISCIMakeCall (addr, processID, QoS.. NDISCoSendPacketsfpacket, VC.
Aft ддя передачи данных без установления соединений
API для управления соединениями
Диспетчеры) вызовов ATM UNI 3.1 API для передачи данных с установлением соеяений Минилорт(ы)
Hi^Bt. Token Ring, FDDI. ... № Рис
ATM, IS
14-17. Сервисы групповой рассылки, поддержив^е CoNDIS
ше на соединени5сегда упорядочивают раМинипорт-драйверы, ории и о с т у п а ю ш ие паю в свою внутреннюю «чеботу собственных функции и сгавят ^ ND1S _ В(ультате повышается про""иом режиме (при уели, что драйвер не входит большие критические секции). у поддерживает старые шпорт-драйверы N DIS ЗД альность доступна ди^инипорт-драйверам ND 4.0 и 5.0. ческими соедииями, KDIS предоставляет Кроме механизмов, связанных с лс енное явление электропитанием с другие возыож..^ наймет^^^^.^„„с^воляет сетевому адаптеру поддержкой WaKevj ^ ВЫВОдить йыотер из режима понижента контрольных сумм в заголовках пакетов. ^^^^^^^ ™жим) илидержка ailffilpaiH°r° п"дсче" ТАР1 .м„ с^ений и другие функции опест ТАР1 (Telephony API) отвечает за У ™™£ ^ windows 2000 расширен для рационной системы, связанные -леер ^ ^ Л О Г ические соединения (такГкГлТмГхотГсам'тАрТне обрабатываемые, он может создать цепь и соединить ее с дру -гдр|;печивает не просто широкую в Поддерживая перенаправление ° ' обность. Компоненты TAPI в полосу пропускания и хорошую ^ -, н к ц ^авления вызовами ТАР1 в выCoNDIS (прокси) отображают вызов ^ са^,:ш()ЛЯЯ перенаправлять соедиэовьт аналогичных функции ЛТ М оборот). В частности, ТАР1 монения из других сред непосредствен»
600
ЧАСТЬ 4 Интеграция сетей и мультимедиа
жет переадресовывать вызовы какому-нибудь обработки фильтру или компонентам DirectShow Erne о "ШХ' напРимеР RCAW тать в качестве редиректора см. „ разделе «РРР пов^м'м^^м ^'^ f этой главе. NDtbWAN» далее в
РРР поверх ATM С появлением технологи Digital Subscriber Line (xDST оск к сетям для домашних юльзователей и пользова ' °ростной доступ ? И3 С еры постепенно становится жальностыо В этой об т "Т * малого бизнеса стандартов, в том числ^ОЗ! (Asymmetric DSU и m JS? Р^Раб°тано несколько ADSL Lite. Эти технол-ии применяют,, на <пос е^ей^и '^ A°SL)' Шн каоеля, соединяющего злефонную сеть и vm в ' "~ отРезке медного ключается телефонной вдпанией непосреаствс "Ф1** этот отрезок подг:„ «А. д-гдл Родственно к своей центральной ATM.. Служба ATM поверх «L обеспечивает в ^-Ральной ATM-сети. Р СТЬ Д0ступа и QoS, предоставляемыеёнтральной сетью без сш ° гарантии появляется возможносчпротянуть» ATM сеть гоколов. Таким образом тевая модель дает такигреимущества, как: ' ИЛИмалого °Фиса. Эта се• транспарентность проколов; • поддержка всех кла)в QoS; • масштабируемость тосы пропускания; • возможность эволюхнного пепехпггя -> й„ ода на более новые технологии DSL Добавление протоколоРр в ЭТу архитек В ЛЯеТ расширить ее налыюсть и возможпос-ррр поддерживает^ ° Функцио• аутентификацию; .
назначение адресов тьего уровня модели OSI«ество параллели сеансов связи с ^^
. транспарентность прилов третьего уровня модели QSI• шифрование и сжатие Все эти расширения в ссщии с дт-ivj .-. ванной поддержки ATM сбивают BI ^ " ПОВЫМ уровнем интегрирофонной линии. Кроме тоьреход на РРР пс°В ^°АС^ОПУска/ ия Даже по теленений на уровне провайд4,ступа к Интернету т ' Греоует особых измеу 1 теле и провайдеры обычно испуют именно ррр фонные компании, РРР поверх ATM и NDISWA
Windows 2000 поддержива;аленные сое Р поверх А щих версиях Windows KOMIIT NDISWAN ™- В лредыдуивал абот ков протоколов в WAN- Cp € npeaocTaBW Р У стандартных сте- • 2000 компонент NDlSWARp^eHC™H ^НКЦИ °На ?ьность РРР. В Windows го об доставляющий ту же фунта-,,,, ' ^ авлен прокси TAPI, поев ATM. ' Срсде с "ОДДержкой NDIS 5.0, например TAPI, регистрируется как п
ГЛАВА 14
ATM
601
1. Выдает телефонный вызов с ATM-адаптера, обращаясь к диспетчеру вызовов через прокси TAPI и NDIS 5.0. 2. При прохождении вызова перенаправляет соединение с адаптера через NDLS 5.0 компоненту NDISWAN. После этого NDISWAN берет па себя согласование РРР-параметров, а затем, используя стеки LAN и TCP/IP, соединяет компьютер с удаленной сетью. Важно отметить, что TAPI лишь выполняет вызов, а обработку соединения возлагает па другой процесс (в данном случае — на NDISWAN). Такой механизм позволяет, в частности, передавать потоковое видео с качеством DVD, управлять процессами в режиме реального времени и др. Многие приложения этого типа используют RCA-фильтры и технологии» DirectShow, описываемые в следующем разделе.
Поддержка RCA-фильтрации: DirectShow Microsoft разработала технологию DirectShow для более тесной интеграции мультимедийных сервисов и для того, чтобы разработчики мультимедийных продуктов могли легко адаптировать операционную систему под свои потребности. DireciShow позволяет поставщикам аппаратно-программных средств создавать собственные мультимедийные модули, называемые фильтрами. Несколько фильтров можно объединить в цепочку (graph). Если TAPI соединяет компоненты, то DirecLShow использует тот же подход для подключения фильтров и устройств друг к другу. Рис. 14-18 иллюстрирует Direct Scream ing, основанный на СОМ. Благодаря ему приложение Windows 2000 может в реальном времени обрабатывать самые разнообразные типы входных данных. ^ использующее DirectStreaming Данные телефонии
Диспетчер цепочек Directstreammo,
Ц Данные телефонии
Сетевые данные
Сетевые данные
Аудиоданные, передаваемые в реальном времени
Аудиоданные., передаваемые в реальном времени I Другие типы данных реального времени Пользовательский режим Режим ядра Сетевой адаптер
Сетевой адаптер
Сетевой адаптер
Рис. 14-18. DirectStreaming, основанный на СОМ DirectShow содержит КСАчрильтр — простой модуль, предоставляющий необработанные данные (аудио, видео или др.) любому устройству, которому нужно их обрабатывать. При использовании NDIS 5.0 этот фильтр можно подключить к TAPI. NDIS 5.0 позволяет экспортировать виртуальные пени ATM в виде цепочек DirectShow.
602
ЧЛСТЬ 4
Интеграция сетей и мультимедиа
RCA- фильтрация Windows 2000 поддерживает RCA-филътрацию через драйвер CoNDIS 5.O. NDISпрокси инициирует вызов на уровне ATM. который передается через диспетчер вызовов клиенту. Соединение осуществляется с применением AAL5, а не AAL1. При прохождении через фильтр аналоговые данные преобразуются в цифровые, которые обрабатываются так же, как и любые другие данные, передаваемые по AAL5соединеииям. Приложение Weather Report Примером использования DirectShow и поддержки RCA в службах ATM является приложение, передающее потоковые аудиоданные — сводку погоды по телефону. Пользователи просто набирают нужный номер и прослушивают записанное сообщение. Вот что при этом происходит. 1. При инициализации RCA-фильтр регистрирует потоковый обработчик голосовых данных. 2. Пользователь звонит по определенному номеру. 3. TAPI принимает вызов и перенаправляет его RCA-фильтру, так как это голосовой вызов. 4. NDIS 5.0 сопоставляет цепочку DirectShow с номером виртуальной цепи (VC). 5. DirectShow находит нужную непочку фильтров, и начинается потоковое воспроизведение аудиоданных. Приложение Weather Report Диспетчер цепочек OirectStreaming Tapi32.dll Taplsrv.exe TAPI SP Пользовательский режим
RCA-фильтр
WAV-фильтр
Режим ядра
Проке и TAPI
Диспетчер вызовов Минишрт, ориентире-1 ванный на соединения]
WAV (аудиоданные)
RCA
Тип потока: голосовые данные/видео NOfSS
Жесткий диск
Данные телефонии |ISDN, ATM, ..
Рис. 14-19. Приложение Weather Report, использующее RCA-фильтр DirectShow
ГЛАВА 14
ATM
603
Пример такого приложения, использующего RCA-фильтр DirectShow, показан на рис, 14-19; обратите внимание на путь, по которому проходят данные.
1Р-телефоння Аналогичным образом можно осуществлять телефонные вызовы, пе!)енаправляемые в традиционную LAN. Благодаря этому становится возможным использование IPтелефонии. Как и в предыдущем примере, ТАР1 обрабатывает поступающий пызов и, используя NDIS 5.0, подключает его к нужной пеночке. Затем DirectShow переформатирует данные с помощью подходящего фильтра, и в конечном счете они поступают Ethernet-плате. Полученное в итоге соединение дает возможность звонить с телефона пользователю компьютера. Такая интеграция на основе ATM-сети фактически стирает различия между телефонными и компьютерными сетями.
Рекомендации Для эффективной работы ATM- или LANE-сети (как и любой другой сети) нужно позаботиться о ее правильном развертывании. Хотя многие критически важные функции управления сетью выполняются только с коммутатора, немалая часть базовых задач решается на клиентской стороне в эмулированной LAN-сети или сети IP поверх ATM. В этом разделе подробно поясняется, как средствами Windows 2000 добиться эффективной работы ATM-сети. Также описывается ряд утилит с компакт-диска «Ресурсы Microsoft Windows 2000 Server», предназначенных для мониторинга ATM-сети.
Использование ELAN по умолчанию ATM-службы Windows 2000 конфигурируются при установке LANE на использование ELAN по умолчанию. В итоге клиент LANE автоматически пытается присоединиться к этой ELAN, если только Вы не сконфигурировали его на другую ELAN. ELAN по умолчанию обозначается как , и именно это имя должно всегда появляться в окне свойств клиента LANE при его настройке. Приобретая ATM-коммутатор, убедитесь, что на нем предустановлены службы LANE, настроенные на ELAN по умолчанию. (Это ELAN, к которой клиент подключается, если при обращении к службам LANE не указывается имя какой-либо ELAN.)
Повышение безопасности за счет нескольких ELAN Если Вы реализуете LANE для нескольких групп клиентов с разными требованиями к безопасности, применения ELAN по умолчанию может оказаться недостаточно. В таком случае подумайте об использовании нескольких ELAN. Вы можете разделить корпоративную сеть, например, на три ELAN: бухгалтерия и отдел кадров должны находиться в ELAN с максимальной защитой, отделы продаж, маркетинга, материально-технического снабжения — в ELAN со среднем уровнем защиты, а остальные отделы — в менее защищенных ELAN. Настройка нескольких ELAN требует дополнительных усилий, зато повышает уровень защиты.
Протоколирование событий Протоколирование определенных событий, например установление и завершение вызова, можно активизировать в ATMUNT. Нелокализованные английские строки
604
ЧАСТЬ 4
Интеграция сетей и мультимедиа
записываются в указанный Вами файл. Эти настройки глобальны и действуют на все ATM-адаптеры. В подраздел реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services \AtmUm\Parameters добавьте параметры: •
LogFlags типа REG_DWORD — битовая маска, которая определяет, какие события следует записывать в журнал;
• LogFileName типа REG_SZ — имя файла, в который ATMUNI записывает события. Если параметра LogFlags нет (по умолчанию), ATMUNI не регистрирует никаких событий. Значение LogFlags формируется побитовой операцией OR из следующих значений: • 1 — регистрировать неудачные вызовы; • 2 — регистрировать успешные вызовы; • 4 — регистрировать ненормальное завершение вызовов; • 8 — регистрировать нормальное завершение вызовов. Чтобы включить регистрацию всех событий, присвойте параметру LogFlags значение OxF (8+4+2+1). Параметр LogFileName содержит полное (с путем) имя файла, например «c:\atm\logs\log2.txt». Этот файл создается (или обнуляется, если он уже существует) при запуске ATMUNI.
Корректные имена ELAN Следует учитывать, что имя ELAN не должно быть длиннее 32 алфавитно-цифровых символов. Включать в имя ELAN специальные символы и пробелы нельзя. Имена ELAN чувствительны к регистру букв.
Поддерживаемые ATM-адаптеры Перед покупкой ATM-адаптера проверьте, включен ли он в список HCL (Hardware Compatibility List). Информацию на эту тему см. по ссылке Hardware Compatibility List на странице http://windows.nHcro.soft.com/windows2000/reskit/webresources.
Утилиты ATM Чтобы получить доступ к инструментам, поставляемым на компакт-диске «Ресурсы Microsoft Windows 2000 Server», откройте окно командной строки. В этом режиме Вы сможете использовать утилиты ATMADM, ATMLANE и ATMARP для мониторинга, диагностики и устранения неполадок в сети. Все эти утилиты подробно описываются в следующих разделах.
Утилита ATMADM ATMADM помогает в устранении неполадок. Она отслеживает соединения и адреса, зарегистрированные диспетчером вызовов в ATM-сети. Вы можете использовать эту утилиту для вывода статистики по входящим и исходящим соединениям на ATM-адаптерах.
ГЛАВА 14
ATM
605
Параметры ATMADM выводит информацию об ATM-адресе, статистику ATM и текущее состояние всех ATM-соединений. Примечание Чтобы узнать, какие параметры принимаются какой-либо утилитой командной строки, введите ее имя с ключом /? (например: atmadm /?). Три основных ключа утилиты ATMADM — A, S и С. ATMADM -С сообщает информацию о вызовах для всех текущих ATM-соединений. ATMADM -S показывает статистику для мониторинга состояния активных ATM-соединений. ATMADM -А выводит зарегистрированный адрес точки доступа сетевой службы ATM для каждого установленного на компьютере адаптера. Эти ATM-адреса не связаны с адресами других конечных устройств ATM, с которыми соединен данный адаптер. Первые 26 шестнадцатиричных символов (13 байтов) 40-символьной строки представляют адрес коммутатора, следующие 12 (6 байтов) — МАС-адрес устройства, а последние 2 (1 байт) — значение селектора (оно позволяет диспетчеру вызовов различать логические адреса, назначенные одному устройству),
Адреса для нескольких адаптеров Если на компьютере установлено два ATM-адаптера, ATMADM -А сообщает оба адреса, но учтите, что названия идентичных устройств одинаковы. Например, если оба МАС-адаптера выпущены одним и тем же производителем, отображается одно название, но разные адреса (рис. 14-20). C:\users>atmadm -a Windows ATM Call Manager Statistics ATM Addresses for Interface : [003] ForeRunner PCA-200EPC ATM AdapterNNf 4700918100000000613E5BFE0100204808119BOO ATM Addresses for Interface : [002] ForeRunner PCA-200EPC ATM Adapter 47009181000000006-13E5BFE010020480811F300
Рис. 14-20. ATM-адреса для компьютера с двумя ATM-адаптерами Параметр -S предоставляет полезную статистику, относящуюся к ATM-клиенту: количество соединений (созданных, принятых и отклоненных им с момента подключения к ATM-сети), а также текущее число виртуальных цепей. Кроме того, ATMADM -S отслеживает количество служебных ячеек, переданных сигнальными интерфейсами и ILMI. Образен типичного отчета с 10 активными вызовами и краткой хронологией успешных входящих и исходящих вызовов показан на рис. 14-21, Эта статистика очень ценна при диагностике. Допустим, ATMADM -S сообщает, что входящие вызовы успешны, а исходящие — нет. Зная, какие вызовы проходят, Вы сможете локализовать источник проблем. Если не проходят исходящие вызовы, то, вероятно, клиент пытается связаться с уже несуществующим клиентом, запись о котором пока хранится в кэше ARP-сервера, С другой стороны, нужное конечное
606
ЧАСТЬ 4
Интеграция сетей и мультимедиа
устройство, возможно, не в состоянии обработать вызов из-за нехватки ресурсов. Наконец, сбои исходящих вызовов могут быть результатом несовместимости (например, запрашиваемая категория сервиса не поддерживается данным клиентом). C:\users>atmadm -s Windows ATM Call Manager Statistics ATM Call Manager statistics for Interface : [002] ForeRunner PCA-200EPC ATM Adapter Current Active Calls = 10 Total successful Incoming calls = 19 Total successful Outgoing calls = 19 Unsuccessful Incoming calls = 0 Unsuccessful Outgoing calls = 0 Calls Closed by Remote = 20 Calls Closed Locally = 8 Signaling and ILMI Packets Sent = 1488 Signaling and ILMI Packets Received = 1506 Рис. 14-21. Статистика для клиента с одним ATM-адаптером Если же не проходят входящие вызовы, проблема скорее всего в том, что клиент не может удовлетворить требования, предъявляемые к QoS. Это особенно вероятно, если клиент выделил много ресурсов другим соединениям. Когда не проходят ни входящие, ни исходящие вызовы, применяется эмуляция LAN и число сигнальных и ILMI-пакетов продолжает увеличиваться, проблема, видимо, вызвана несовместимостью с коммутатором. В этом случае клиент не может зарегистрироваться на сервере LEGS. А если клиенту все же удалось зарегистрироваться, значит, недоступно или перегружено нужное конечное устройство. Если во всех строках проставляются нули, кроме предпоследней (в которой сообщается значение 1), то не исключено, что клиент физически не подключен к коммутатор}'. Проверьте кабели и другие физические соединения. Запуск ATMADM с ключом -С позволяет увидеть набор параметров, описывающих вес ATM-соединения компьютера (с BUS, LES и другими ATM-устройствами). Образец вывода этой команды показан на рнс. 14-22. Несколько соединений, перечисленных на рис. 14-22, могут быть отслежены до стандартных компонентов. Например, запись для пары VPI/VCI, равной 0/45, адрес сервера ATMARP по умолчанию, запись 0/48 — истинный адрес адаптера (сравните этот отчет с выводом ATMADM -А), а запись 0/37 представляет многоадресное соединение с 12 конечными устройствами. Как правило, все значения VPI/VCI от О/О до 0/32 резервируются для сигнальных и управляющих функций. В частности, О/О и 0/5 резервируются для UNI, 0/16 назначаются каналу ILMI, а 0/17 указывает на ILMI для LANE. В конце каждой записи укалывается параметр MaxSdu (maximum service data unit), эквивалентный MTU (maximum transmission unit). Это позволяет определить тин сети, как показано в таблице 14-2.
ГЛАВА 14
ATM
607
C:\users>atmadm -с Windows ATM Call Manager Statistics ATM Connections on Interface ; [003] ForeRunner PCA-2QOEPC ATM AdapterNNf Connection
VPI/VCI Remote Address/ Media Parameters (rates in bytes/sec)
In
0/285
P-P SVC
In P-P SVC
0/47
Out PMP SVC
0/37
In P-P SVC
0/58
Out P-P SVC
0/51
Out P-P SVC
0/45
Out P-P SVC
0/44
In PMP SVC
0/4B
Out P-P SVC
0/46
4700918100000000613E5BFE01002048082C3C01 Tx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9188 Rx: UBR, Peak 169539B4, Avg 16953984, MaxSdu 9188 47009181QOOOQ000613E5BFE0100204808119B01 Tx: UBR, Peak 16953984, Avg 16953984, HaxSdu 9188 Rx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9188 4700000000003C0001AOOOOOOGOOOOC11082B601 (11) 4700918100000000613E5BFE01002048082C3C01 (10) 39840F8001BC3C0000010016640060A000088B01 (8) 470Q918100000000613E5BFE0100204B08119B01 (7) 39840F8001BC3C0000010016640060A00008DC01 (6) 39840F8001BC61DFQ0072045000020480EB4EB01 (5) 39840F8001BC61DF00072045000000778FE73E01 (4) 39640F8001BC61DF00072045000000D10F4FAD01 (1) 39840F8001BC61DF00072045000020480E06E301 (0) Tx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9180 Rx: UBR, Peak 0, Avg 0, MaxSdu 0 39B40F8001BC61DF00072045000000D10F4FAD01 Tx: UBR, Peak 16953984, Avg 16953964, HaxSdu 9188 Rx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9188 39840FB001BC3C0000010016640060A000088B01 Tx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9168 fix: UBR, Peak 16953984, Avg 16953984, MaxSdu 9188 4700790001020000000000000000A03E00000200 Tx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9188 Rx: UBR, Peak 16953984, Avg 169539B4, HaxSdu 9188 39840F8001BC3C0000010016640060A00008DC01 Tx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9188 Rx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9188 4700918100000000613E5BFE0100204808119BOO Tx: UBR, Peak 0, Avg 0, MaxSdu 0 Их: UBR, Peak 16953936, Avg 16953936, MaxSdu 9180 4700918100000000613E5BFE01Q0204808119BOO Tx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9188 Rx: UBR, Peak 16953984, Avg 16953984, MaxSdu 9188
Рис. 14-22. Образец вывода команды ATMADM -С Таблица 14-2. Стандартные MTU для сетей наиболее распространенных типов MTU
Описание
9234 18190 4544 1516 9188
Одно из значений, допустимых для Ethernet Типичное значение для Token Ring Одно из значений, допустимых для Token Ring Значение для Ethernet по умолчанию IP поверх ATM
608
ЧАСТЬ 4
Интеграция сетей и мультимедиа
Утилита ATMLANE Эта утилита позволяет анализировать различные аспекты работы клиента Microsoft LANE. При запуске из командной строки она сообщает имя ATM-адаптера, ELANсети, сконфигурированные для этого адаптера, номер текущей ELAN (так как адаптер может быть настроен на несколько ELAN) и ее состояние. Возможные состояния ELAN перечислены в таблице 14-3. Таблица 14-3. Возможные состояния ELAN Состояние ELAN
Описание
INITIAL LEGS CONNECT ILMI
ELAN только что начала работать ELAN пытается соединиться с LECS по ATM-адресу, полученному от ILMI ELAN пытается соединиться с LEGS по стандартному ATMадресу LECS ELAN пытается соединиться с LECS7 используя PVC LECS ELAN пытается соединиться с LECS по специально указанному адресу LECS ELAN соединилась с LECS и обменивается с ним конфигурационной информацией ELAN соединяется с LES по адресу, полученному от LECS ELAN обменивается с LES информацией, необходдагой для присоединения ELAN ищет BUS и соединяется с ним ELAN полностью работоспособна ELAN заканчивает работу
LECS CONNECT WKA LECS CONNECT PVC LECS CONNECT CFG CONFIGURE LES CONNECT JOIN BUS CONNECT OPERATIONAL SHUTDOWN
Как показано на рис. 14-23, за информацией о состоянии ELAN выводится три группы параметров. В первую группу входят некоторые рабочие параметры клиента LANE. Параметры С1-С28 (исключая С16) содержат либо значения по умолчанию (определенные ATM Forum с спецификации LANE), либо значения, полученные от LECS и LES. Вторая группа (С16) отражает сопоставления Ethernet-адресов с ATM-адресами. Windows ATM LAN Emulation Client Information Adapter:
\DEVICEM11DC1752-1B17-11D2-A8E5-853DAA694C23J
ELAN: \Device\{FDEBFE5E-1B55-11D2-A8E6-000000000000}
C1 C2 C3 C4 C5 C6 C7 C8
ELAN Number: ELAN State: ATM Address: LAN Type; MaxFrameSize: Proxy: ELAN Name: MAC Address: ControlTimeout: RouteDescriptors: LECS Address;
0 OPERATIONAL 47.0091.81.000000.0061.3e5b.fe01.0020480811f3.00 Ethernet/802.3 1516 Off Collage740ElanEth 00.20.48.08.11. f3 300 sec None 47.0079,00.000000.0000.0000.0000.00a03e000001.00
ГЛАВА 14 С9 LES Address: BUS Address; C10 MaxUnkFratneCount: C11 MaxUnkFrameTime: C12 VccTiirieout: C13 MaxRetryCount:
ATM
609
39.840f.80.01bc61.dfOO.0720.4500.00006f072045.03 39.B40f.60.01bc61.df00.0720.4500.00006f072045.04 5
1 sec 1200 sec 1
C14 LEG ID:
27
C15 multicastMacAddrs; C16 LE_ARP Cache: C17 AgingTime: C18 ForwardDelayTime: C19 TopologyChange: C20 ArpResponseTime: C21 FlushTimeout: C22 PathSwitchingDelay: C23 LocalSegmentld: C24 McastSendVcType: C25 McastSendVcRate: C26 McastSendPeakRate: C27 RemoteMacAddrs: C28 ConnComplTimer:
Broadcast,All_muItleast See below
300 sec 15 sec Off 16 sec 4 sec 6 sec 4080 Best Effort
0 cps 0 cps None
4 sec
C16 LE.ARP Cache 00.00.c1.00.02.8b 00.20.48.0e.06.e3 OD.a0.24.b3.3c,20 00.00,d1.0f.4f.ad 00.00.d1.Of.Sf.aa 00.00.d1.0f.9f.66 ff.ff.ff.ff.ff.ff Connection Cache PEER PEER PEEF PEER PEER PEER PEER PEER BUS LES
-> -> -> -> -> -> ->
39.840f.80.01bcei.dfOO.0720 4500.0000c100Q28b.OO 39.840f-80.01bc61.dfOO.0720, 4500.0020480eQ6e3.00 47.0005.80.ffe100.0000.f219 19a5.00a024b33c20,00 39.B40f.80.01bcei.dfOO.0720 4500.0000d10f4fad.00 47.0000.00.00003с.0000.aOOO. 0000.0000d10f5faa.00 47.0000.00.00003c.OOOO.aOOO 0000.0000d10f9f66.00 39.840f.80.01bc61.dfOO.0720 4500.00006f072045.04
47 0000 00. 00003с, 0000, aOOO. OOQO.OOOOd10f9f66.00 47 0000 00. 00003с 0001 aOOO, 0000.0000d100083c.00 47 0000. 00. 00003с, 0001, aOOO. 0000.0000d10f9f5e.00 39 840f 80. 01bc61, dfOO. 0720. 4500.0000c100028b.00 47, 0000 00. ООООЗС. 0000, aOOO. 0000.0000d10f5faa.00 47 0005 80, ffelOO, 0000, f219. 19a5.00a024b33c20.00 39. 840f .80. 01bc61, dfOO, 0720.4500,0020480e06e3.00 39 840f HO 01bc61, dfOO, 0720. 4500.0000d10f4fad.00 ;((t 840f '30 01bc61. dfOO. 0720. 4500.00006f072045.04 39. 840f. 30 01bc61. dfOO, 0720.4500.00006f072045.03
DataDirect DataDirect DataDirect DataDirect DataDirect DataDirect DataDirect DataDirect HcastSend + McastFwd CtrlDirect + CtrlDistr
Рис. 14-23. Результаты запроса ATMLANE Третья группа параметров отражает информацию о текущих ATM-соединениях, используемых ELAN. В первом столбце указывается класс соединения (Peer, BUS или LES). Во втором — ATM-адрес получателя, в третьем — тип виртуальной цепи (DataDirect для класса Peer, Mcast для класса BUS и Ctrl для класса LES). Ниже приведено краткое описание шести типов виртуальных цепей. Configuration Direct. Двухсторонняя VC между клиентом эмуляции LAN и LEGS; создается на этапе LEGS Connect (таблица 14-3) и используется клиентом для получения конфигурационной информации, например ATM-адреса LES.
610
ЧАСТЬ 4
Интеграция сетей и мультимедиа
Control Direct. Двухсторонняя VC «один-к-одному», по которой перелается управляющая информация между клиентом LANE и LES. Используется, например, для разрешения адресов. Control Distribute. VC «один-ко-многим» от LES до одного или нескольких клиентов эмуляции LAN. Data Direct, Наиболее часто используемая VC — двухстороннее соединение типа «точка-точка» («один-к-одному») между двумя клиентами эмуляции LAN. Multicast Send. Двухсторонняя VC <шдин-к-одному» между клиентом эмуляции LAN и BUS. Используется для передачи групповых кадров в BUS. Multicast Forward. Односторонняя VC «один-к-одному» или «один-ко-многим» между BUS и одним или несколькими клиентами эмуляции LAN. Используется для передачи групповых кадров членам ELAN.
Утилита ATMARP Эта утилита сообщает сведения о сервере ARP или файле Atmarmps.sys, используемом в сети IP поверх ATM. Так как служба IP поверх ATM в Windows 2000 сочетает в себе функции серверов ARP, MARS и MCS, утилита ATMARP предоставляет больше информации, чем это можно было бы предположить исходя из ее имени. Она также выдает статистику MARS и MCS, т. е. количество принятых и переадресованных пакетов, число клиентов — членов группы IP-рассылки, данные о попытках добавления новых клиентов, сведения о регистрациях, присоединении и т. д. Данная утилита предусматривает три ключа: -С, -S и /reset. Последний работает именно так, как Вы и подумали: сбрасывает значения всех параметров статистики по ARP и MARS. По умолчанию действует ключ -S. В этом случае ATMARP генерирует вывод, образец которого приведен на рис. 14-24. В нем описывается текущее состояние и хронология для сервера ATMARP. В строке Elapsed Time сообщается число секунд с момента запуска службы ARP/ MARS/MCS или ввода команды atmarp /reset. Последняя обнуляет все статические данные, значения которых увеличиваются с течением времени. Строка Received Packets отражает общее количество управляющих ARP- или MARS-пакстов, принятых компьютером, на котором установлен данный адаптер, а также число отброшенных пакетов. Большое число отброшенных пакетов свидетельствует о нехватке ресурсов или о проблеме с коммуникационной связью. Строка Entries содержит сведения обо всех текущих записях во внутренней таблице ARP и их максимальное количество, которое отмечалось в этой таблице за время сбора статистики. В строке Responses показывается число переданных ARP-ответов АСК и NAK. Поле Client VCs информирует о количестве входящих клиентских VC, а поле Incoming Calls — об общем числе клиентских VC. Далее отображается статистика сервера MARS, Она начинается с общего числа принятых и отброшенных пакетов. Большое число отброшенных пакетов свидетельствует о нехватке ресурсов или о проблеме с коммуникационной связью. Строка MCData Packets показывает общее количество групповых пакетов, полученных от клиентов, а также общее число отброшенных пакетов и пакетов, отраженных на кластерную управляющую VC. В строке Members сообщается текущее количество клиентов — членов группы IP-рассылки, а также максимальное число клиентов, которое наблюдалось за время сбора статистики. В строке Promiscuous содержится текущее и максимальное количество клиентов, посылавших запрос на присоедине-
ГЛАВА 14
ATM
611
ние в смешанном режиме (promiscuous joins). В строке Add Party выводятся сведения о количестве попыток (в том числе неудачных) ARP-сервера добавить клиент к кластерной управляющей VC. Строка Registration отражает число клиентов, пытавшихся зарегистрироваться на MCS, и количество неудачных попыток. Строки Joins и Leaves информируют о числе клиентских запросов на присоединение и выход из группы IP-рассылки, а также о количестве неудачных запросов и запросов, дублирующих ранее обработанные. Туда же включаются запросы на присоединения в смешанном режиме и выходы. C:\>atmarp
Windows ATM ARP Server Information Adapter: {BA021C4A-8475-11D2-9FC7-95AE3A1F5FF7} Arp Server Statistics Elapsed Time: 71763 Recvd. Pkts.: 14869 Entries: 13 Responses: 11 Client VCs: 6 Incoming Calls: 4582
seconds total current acks current total
Mars Server Statistics Recvd. Pkts.: 13949 MCData Pkts.: 49069 Members: 6 Promis.: 0 Add Party: 24 Registration: 4142 Joins: 9323 Leaves: 31 Requests: 453 Responses: 440 VC Mesh: 1 Groups: 0 Group Size: 1
total total current current total requests total total total acks joins current max
(0 discarded) (13 max) (909 naks) (11 max)
(13 discarded) (0 discarded, 49069 reflected) (8 max) (1 max) (0 failed) (0 failed) (36 failed, 9286 dup's) (0 failed) (0 naks) (0 acks) (1 max)
Рис. 14-24. Образец вывода команды ATMARP -S В строке Requests показывается общее количество MARS-запросов, т. е. запросов ATM-адресов, сопоставленных с IP-адресом конкретной группы IP-рассылки. Строка Responses дает информацию о числе АСК (указывающих на число успешных ответов, в которых содержится минимум один адрес) и NAK (указывающих на число отрицательных ответов), В строке VC Mesh сообщается об общем числе успешных присоединений к группе IP-рассылки VC Mesh; при этом АСК указывает количество MARS-запросов на получение обслуживаемого УС Mesh адреса группы. В строке Groups выводится текущее и максимальное число обслуживаемых VC Mesh адресов группы IP-рассылки. Последняя строка, Group Size, отражает максимальное число клиентов, одновременно запрашивавших обслуживаемый VC Mesh адрес одной и той же группы IP-рассылки.
612
ЧАСТЬ 4
Интеграция сетей и мультимедиа
Сервер MARS (на основе параметров, издаваемых пользователем) определяет адреса, обслуживаемые MCS. (VC Mesh-адреса группы — все адреса, не обслуживаемые MCS.) Если адрес обслуживается MCS, MARS возвращает собственный ATMадрес в ответ па запрос клиента о гаком наборе групповых адресов. В остальных случаях (т. с. для обслуживаемых VC Mesh групповых адресов) сервер MARS возвращает список ATM-адресов клиентов, прослушивающих указанный адрес. Термин «VC Mesh» («сетка виртуальных пеней*) отражает тот факт, что обмен данными между клиентами приводит к созданию «сетки» виртуальных цепей «одинко-многим». Каждый клиент, которому нужно передать данные на определенный групповой адрес VC Mesh, должен создать виртуальную цепь «один-ко-многим». При этом все клиенты, получающие данные по этому адресу, являются листьями виртуальной цепи. Вывод ATMARP -С позволяет заглянуть в кэш адресов. Образец такого вывода показан на рис. Н-25. Windows ATM ARP Server Information Adapter: {EB535D2A-8044-11D2-AFE3-A9CC1F429604}
Arp Cache
192.168.74.20 -> 47.0000. 00.00003с, 0000.aOOO. 0000. ООООСП00879. 01 192.168.74,23 -> 47.0000.00.00003с.0000,aOOO.0000.002048081 Ida.01 Mars Cache promiscuous -> 47.0000.00.00003o.0000.aOOO.0000.0020480811da.01 236.1.2.3 -> 47.0000.00.00003C.0000.aOOO.0000.OOOOc1100879.01:q Рис. 14-25. Образец вывода команды ATMARP -С Каждый элемент ARP-кэша соответствует сопоставлению одного IP-адреса с одним ATM-адресом. Максимальное число элементов в кэше не ограничено, и они не сортируются. Специальный адрес группы IP-рассылки, называемый «смешанным* («promiscuous*), сопоставляется со списком ATM-адресов клиентов, присоединившихся в смешанном режиме. В то же время каждый элемент кэша MARS соответствует сопоставлению одного IP-адреса с одним или несколькими ATM-адресами. Б кэше содержатся только адреса групп IP-рассылки, обслуживаемые VC Mesh. Это важно, так как в сети может быть несколько активных сеансов групповой связи между несколькими клиентами, использующими набор групповых адресов (каждый из которых обслуживается MCS). В таком случае кэш MARS остается пустым.
IP поверх ATM Сеть IP поверх ATM обладает реальными преимуществами, но ее настройка и поддержка требует дополнительных усилий. Здесь поясняется, как эффективно использовать и настраивать логические IP-подсети и РУС, позволяющие администратору поддерживать высокую производительность сети.
Повышение уровня защиты за счет организации логических IP-подсетей Коммуникационная связь между логическими IP-подсетями (logical IP subnets, LIS) возможна только через маршрутизатор (RFC 1577).
ГЛАВА 14
ATM
613
Добавление клиентов в LIS выполняется на уровне клиента, который устанавливает коммутируемую виртуальную цепь (SVC) с ARP-сервером и использует статический или динамический (выделенный DHCP) IP-адрес из набора адресов данной IP-подсети с одной маской подсети. LIS также можно создать на основе PVCсоединений между клиентами в одной IP-сети или подсети с одинаковой маской подсети. Так, сеть IP поверх ATM может состоять из двух подсетей: первая предназначена для пользователей одного отдела, вторая — для пользователей другого отдела. Сервер ATMARP анализирует все попытки присоединения к сети CLIP. Все, кто обращаются к одному и тому же серверу IP поверх ATM, находятся в одной IP-сети или подсети и используют одинаковую маску подсети, являются членами одной LIS. Все члены LIS имеют полные права на доступ друг к другу. Зашита реализуется просто за счет того, что члены других LIS не могут подключиться к этой LIS или к ее членам. Сочетание PVC и LIS открывает другую полезную функциональность IP поверх ATM. Клиенты ATMARP можно связать друг с другом через диспетчер вызовов и IP поверх ATM так, чтобы они использовали общую PVC, созданную па АТМ-коммутаторе и работающую без применения ATM-адресов. Тогда Вы сможете задействовать часть IP-адресов одной IP-сети или подсети и сформировать из них компактную и защищенную LIS. Такая подсеть будет недоступна из других подсетей даже через AT М-коммутатор, пока Вы не реализуете маршрутизацию пакетов между нужными подсетями. Другие варианты применения PVC описываются в следующем разделе.
Эффективное использование PVC Как и логические IP-подсети, PVC в определенных ситуациях тоже полезны в частных ATM-сетях. Например, LAN большого студенческого кампуса переводится на более скоростную сетевую магистраль (ATM). Конфигурация такой магистрали требует для соединений лишь нескольких статических путей, которые изменяются очень редко. С этой задачей прекрасно справляется ATM-сеть с постоянными виртуальными цепями (PVC). Другой пример: небольшая WAN с двумя сайтами. Здесь необходимо постоянное выделенное высокоскоростное соединение, гарантирующее строго определенные параметры QoS на пути между сайтами. При использовании постоянных виртуальных цепей ATM-коммутаторы обоих сайтов не создают дополнительные задержки и не передают сигнальную информацию. Также не возникает необходимости настраивать соединение при каждой передаче ячеек данных или разрывать его. При этом данные пересылаются между сайтами по заранее установленной PVC. В Windows 2000 постоянные виртуальные цепи настраиваются через дополнительные свойства диспетчера вызовов ATM.
Настройка IP поверх ATM в среде, использующей только PVC Компьютеры под управлением Windows 2000 Professional или Windows 2000 Server можно настроить на IP поверх ATM с использованием только PVC. Однако это требует определенной подготовительной работы. Во-первых, назначьте каждому компьютеру IP-адрес. Вам также понадобится PVC (т. е. пара VPI/VCI) для каждой пары компьютеров. Введите и запомните щаче-
614
ЧАСТЬ 4
Интеграция сетей и мультимедиа
ния VPI/VCI ыа каждой стороне PVC. Соответственно настройте свои коммутаторы; все PVC можно сконфигурировать как виртуальные цепи типа UBR (с линейной скоростью). Выполните следующие процедуры. ^ Чтобы разрешить использование IP поверх ATM: 1. В окне Control Panel (Панель управления) дважды щелкните значок Network and Dial-Up Connections (Сеть и удаленный доступ к сети). 2. Щелкните правой кнопкой мыши значок подключения, которое соответствует ATM-адаптеру, установленному на данном компьютере, и выберите команду Properties (Свойства). Вы увидите список всех протоколов, привязанных к ATM-адаптеру. 3.
Установите флажок в строке Internet Protocol (TCP/IP) [Протокол Интернета (ТСР/1Р)| и щелкните кнопку ОК.
^ Чтобы назначить компьютеру IP-адрес: 1. В окне свойств ATM-соединения выберите Internet Protocol (TCP/IP) [Протокол Интернета (TCP/IP)] и нажмите кнопку Properties (Свойства). 2. В диалоговом окне TCP/IP Properties [Свойства: Протокол Интернета (TCP/ IP)] в поле Connect Using (Использовать для подключения) выберите имя Вашего ATM-адаптера, 3.
Щелкните Use the following IP Address (Использовать следующий IP-адрес) и введите данные в поля IP Address (IP-адрес), Subnet Mask (Маска подсети) и Default Gateway (Основной шлюз).
^ Чтобы настроить клиент ATMARP на каждом компьютере на использование только PVC: 1. В окне Control Panel дважды щелкните значок Network and Dial-Up Connections и откройте окно свойств ATM-соединения. 2. Дважды щелкните ATM Call Manager (Управление вызовами ATM) и перейдите на вкладку Properties (Свойства). 3. Щелкните кнопку Add (Добавить). 4. В диалоговом окне ATM PVC Configuration укажите имя PVC и номер VCI, а затем измените Application Type (Тип приложения) с Custom (Пользовательский) на Default (По умолчанию).
Предотвращение несанкционированного доступа к коммутатору ATM достаточно безопасна просто по своей природе, так как в нормальных обстоятельствах подключиться к службам ATM извне невозможно. Любой, кто попытается использовать такие службы извне, должен сначала обратиться к мосту (например, к мосту между Ethernet и Token Ring или к маршрутизатору ATM-Ethernet). Таким образом, простейший способ ограничить внешний доступ к LANE — не подключать к ATM-коммутатору унаследованные устройства. Ограничить доступ изнутри можно простой сменой имени ELAN и адреса ARP-cepвера, предлагаемых по умолчанию. Эти изменения можно внести в процессе создания нескольких ELAN, транспарентных друг для друга, но имеющих разные уров-
ГЛАВА 14
ATM
615
ни защиты. Так как для доступа к сети нужен сервер ATMARP, Вы можете защитить всю сеть, изменив адрес ATMARP. Тогда новые имя и адрес будут своего рода паролем для любого клиента, пытающегося войти в сеть и зарегистрироваться на ATM-коммутаторе. Присоединение no VPI/VCI (называемое ILMI-присоединением) — первое, что делают почти все клиенты при присоединении к ELAN. Эту функциональность можно ограничить фильтрами МАС-адресов — обычно на уровне LECS, но иногда и на уровне ELAN/VLAN, — запрещающих присоединение с неизвестных МАС-адресов, Этот тип присоединения на некоторых коммутаторах можно ограничить запрещением ILMI для LEGS. Еще один способ — использование общеизвестного адреса ATMFNSAP (47.00.79.00.00.00.00.00.00.00.00.00.00.00.aO.3e.00.00.01.00).
Выявление и устранение проблем Выявление и устранение проблем с ATM-соединениями обычно проходит по одному и тому же сценарию, так как сильная сторона ATM (ориентированность на логические соединения) становится причиной неполадок, если устанавливать эти соединения не удается. Поскольку соединения — ключевое звено в обеспечении безотказной работы любой ATM-сети, устранение неполадок в ней всегда начинается с запуска утилиты ATMADM. Для диагностики большинства неполадок достаточно выполнить три операции. Сначала введите команду atmadm -с и проверьте, правильно ли установлены соединения. Во-вторых, введите atmadm -а и проверьте, корректно ли работает UNI-соединение. Если эта команда выдает какой-нибудь адрес, значит, ей удалось связаться с коммутатором и он знает о наличии данного клиента эмуляции LAN. Иногда адрес возвращается, но доступ к каким-либо службам коммутатора невозможен — это связано с очень низким качеством соединения между клиентом LAKE и коммутатором и чаще всего свидетельствует о проблемах с кабельной проводкой. Наконец, если Вы не получили UNI-адрес, используйте atmadm -s, чтобы определить, правильно ли работает ILMI. Если с ILMI все в порядке, то в двух нижних строках вывода этой команды (см. пример на рис. 14-21) показываются примерно одинаковые, постепенно возрастающие значения. Значение в строке Received увеличивается немного с другой скоростью, чем значение в строке Sent.
Сбой при инициализации Одна из наиболее частых проблем с ATM-сетями — сбой при инициализации нового клиента ATM. Обычно сбой является результатом того, что клиент LANE не может обнаружить LEGS. Причины такого сбоя могут быть разными: на коммутаторе не разрешено использование служб LANE, клиент пытается присоединиться к несуществующей ELAN или коммутатор не поддерживает параметры QoS, указанные клиентом при присоединении к нужной ELAN. Если на коммутаторе не разрешены службы LANE, команда atmadm -с показывает, что число исходящих ячеек увеличивается медленно и что данный клиент пытался соединиться с коммутатором по VCI/VPI, равной 0/17. Если клиент указывает неверное имя ELAN при присоединении к сети, попытка связаться с коммутатором приводит к регистрации соответствующего события в журнале. Но, если
616
ЧАСТЬ 4 Интеграция сетей и мультимедиа
на коммутаторе не разрешено использование служб LAKE, такое событие не регистрируется. Уровни QoS на коммутаторе не влияют на UBR-трафик, если только этот коммутатор не отвечает за формирование трафика. Вы можете столкнуться с тем, что скорость соединений меняется R зависимости от направления или что полоса пропускания каждой VC существенно меньше общей полосы пропускания, выделенной для соединения. Это может приводить к потере соединений, которые на самом деле должны работать нормально. Чтобы устранить такую неполадку, измените параметры QoS на коммутаторе. Дополнительную информацию см. в документации на коммутатор.
PVC не пересылает ячейки Иногда при установлении одной или нескольких PVC (см. раздел «IP поверх ATM» ранее в этой главе) обнаруживается, что PVC не пересылает ячейки от одного конечного устройства другому. Корни этой проблемы можно найти сравнением результатов, полученных от команд atmadm -с и atmadm -a. ЛТМАПМ -А сообщает UKI-адрес ATM-адаптера, взаимодействующего с коммутатором, и проверяет наличие UNI-соедииения. ATMADM -С показывает адреса входящих и исходящих вызовов, а также выводит атрибуты SVC-вызовов «олин-к-одному» и «один-ко-многим». Однако для PVC она сообщает информацию о входящей PVC, показывая VPI/VCI, но не давая адрес. ATMADM -С не выводит адрес потому, что установление PVC вызова не требует. В этом случае UNI, создавая соединение, просто открывает нужную PVC. UNI-атрибуты соединения, включая VPI/VCI и скорость передачи входящих/исходящих данных, настраиваются на коммутаторе в процессе настройки VP/VC. После создания PVC-соединение остается активным на уровне UNI, даже если по нему не передается никаких данных. Образен вывода ATMADM -С применительно к работающему PVC-соединению показан на рис. М-26. D:\>atmadm -с Windows ATM Call Manager Statistics ATM Connections on Interface : Interphase 5525/5575 PCI ATM Adapter Connection In P-P PVC
VPI/VCI 0/51
Remote Address/ Media Parameters (rates in bytes/sec) Tx; UBH, Peak 16932864, Avg 16932864, MaxSdu 9188 Rx: UBR, Peak 16932864, Avg 16932864, MaxSdu 9188
Рис. 14-26. Образец вывода команды ATMADM -С для обычного PVC-соединения Примечание Пример па рис. 14-26 приведен для клиента ATM ARP поверх PVC без формирования трафика. Формирование трафика на коммутаторе на основе уровней QoS может быть причиной отличия скоростей передачи в разных направлениях или уменьшения полосы пропускания, выделенной всем VC, до уровня, меньшего общей полосы пропускания всего соединения.
ГЛАВА 14
ATM
617
Если ATMADM -С не показывает никаких соединений, но отчеты ATMADM -А и ATMADM -S выглядят правильно, проверьте параметры PVC n ATMIJNI. Сравните значения параметров PVC на клиенте и на коммутаторе. Для успешного соединения по PVC они должны совпадать. Если ATMADM -А не выводит никаких адресов, значит UNI не установил связь. Если результаты ATMADM -S отрицательные, возможна проблема с соединением. ATMADM -А сообщает информацию об ATM-адресе, полученного от коммутатора (ILMI-взаимодействие); размер этих данных — 20 байтов. Первые 13 байтов представляют адрес коммутатора, следующие 6 — МАС-адрсс адаптера и последний байт — значение селектора. Если адрес получен, значит, Вашему компьютеру удается взаимодействовать с коммутатором на уровне UNI. Если ATMADM -А не выводит адрес, по и об ошибке не сообщает, значит, она не может связаться с диспетчером вызовов. В таком случае проанализируйте вывод ATMADM -S. В частности, обратите внимание на два последних показателя, касающихся передачи и приема. Если работает только передача, адаптер функционирует правильно, но соединение либо отсутствует, либо оно лишь полудуплексное. Это означает, что кабели подключены неправильно. Проверьте, тот ли тип кабелей Вы использовали, не поврежден ли какой-то участок и не перепутана ли где-то полярность. Если и прием, и передача работают нормально, но Вы не получаете ATM-адрес, возможны две проблемы: либо ILMI на коммутаторе отключен, либо коммутатор работает в режиме UNI 3.0. В любом случае нужно исправить ошибки в конфигурации коммутатора. Если ATMADM -Л возвращает адрес и ATMADM -S сообщает, что TLMI работает, то обратите внимание в отчете ATMADM -S на число неудачных исходящих вызовов. При использовании LANE неудачные исходящие вызовы обычно означают, что клиент LAKE не может соединиться с LEGS no VPI/VCI или общеизвестному адресу (повторные попытки соединения увеличивают число неудачных исходящих вызовов). Причин неудачи исходящих вызовов может быть несколько: на коммутаторе не работают службы LANE, на коммутаторе не настроена ELAN по умолчанию или ELAN с именем, указанным в свойствах клиента эмуляции LAN, не существует. В последнем случае в системный журнал записывается соответствующее предупреждение.
Проблемы с IP поверх ATM Признаки проблем с IP поверх ATM практически те же. Неудачные вызовы со стороны клиента IP поверх ATM обычно означают, что по указанному ATM-адресу пет сервера IP поверх ATM. В этом случае Вы должны исправить текущий ATM-адрес сервера на всех клиентах (эту информацию можно распространить с сервера на все клиенты). Если неудачные вызовы происходят на стороне сервера IP поверх ATM, это может свидетельствовать о том, что коммутатор использует устаревшую версию UNI и не позволяет регистрировать два адреса для одного и того же соединения.
Дополнительные материалы Более подробную информацию об ATM см. по ссылке: • ATM Forum Signaling Specifications на странице http://windows.microsoft.com/ 1 wmdows2000/reskit/webresources.
ГЛАВА
15
Интеграция телефонии и поддержка конференций
Windows 2000 — современная платформа для приложений телефонии, предоставляющая как традиционные средства интеграции компьютера и телефонии (computer-telephony integration, CTI), так и более совершенную функциональность для Интернет-телефонии на основе IP (Internet Protocol) и конференций. В этой главе Обзор 618 Архитектура TAPI 622 Клиент-серверная телефония 624 Интернет-телефония и конференции Выявление и з'странение проблем
625
636
См. также • Подробнее о Quality of Service (QoS) — главу 9 «Quality of Service» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». • О сервере удаленного доступа — главу 7 «Сервер удаленного доступа» в этой книге.
Обзор Приложения телефонии вызывают функции TAPI (Telephony API), а те обращаются к таким компонентам, как TSP (Telephony Service Providers) и MSP (Media Service Providers), которые взаимодействуют с соответствующим аппаратно-программным обеспечением и предоставляют запрошенные сервисы телефонии. Эти приложения способны использовать и другую функциональность Windows-среды, в частности службы каталогов, базы данных и электронную почту.
ГЛАВА 15 Интеграция телефонии и поддержка конференций
619
Получая информацию от телефонных систем, TAPI позволяет автоматизировать обработку телефонных вызовов. TAPI также предоставляет инфраструктуру для IPтелефонии и видеоконференций, давая возможность развертывать приложения, которые интегрируют в себе традиционную и IP-телефонию, Основное преимущество TAPI — приложения телефонии могут работать о любым оборудованием, поддерживаемым одним из TSP или MSP. Скрывая специфику конкретных аппаратных средств, TAPI упрощает создание приложений телефонии и расширяет выбор для администраторов сетей. Благодаря TAPI можно, например, создавать приложения телефонии, способные работать с самыми разнообразными телефонными системами. Без такой абстракции разработчику пришлось бы писать отдельный код для каждого типа телефонного оборудования, с которым должна взаимодействовать его программа.
Интеграция компьютера и телефонии Windows 2000 предоставляет средства интеграции компьютера и телефонии (computer-telephony integration, CTI) — более совершенные, чем в предыдущих версиях операционных систем Windows. На их основе создан широкий спектр программ: от Phone Dialer (Телефон), которая позволяет набирать телефонный номер с компьютера, до приложений, управляющих вызовами в ходе конференций через Интернет. TAPI предоставляет таким приложениям стандартные программные интерфейсы и механизмы (например, для ускоренного набора номеров, переадресации вызовов и идентификации звонящего), которые упрощают реализацию поддержки телефонных операций. Ниже перечислено еще несколько примеров CTI-приложений. Интегрированные сервисы. Перевод голосовой почты на компьютерную платформу позволяет создавать универсальные почтовые ящики для приема электронной и голосовой почты, а также факс-сообщений. Приложения центров обработки вызовов. В этой области TAPI предлагает два способа интеграции: •
через интерфейс аппаратной системы, например мини-АТС (Private Branch Exchange, PBX) или внешней системы автоматического распределения вызовов (Automatic Call Distribution, ACD); • посредством полностью программной системы вроде сети IP-телефонии. Исторически сложилось так, что приложения центра обработки вызовов, переадресующие вызовы на основе информации из некоей базы данных, представляли собой сравнительно дорогостоящие, закрытые системы, с трудом поддающиеся интеграции в существующие информационные системы. Перенос этих приложение на полностью программную платформу ускоряет и упрощает разработку, уменьшает их себестоимость и обеспечивает более тесную интеграцию с компьютерными информационными системами. «Интеллектуальный» набор телефонных номеров. В сфере телемаркетинга сервер телефонии с соответствующим аппаратным обеспечением может быстро набрать список заданных номеров. Если сервер обнаруживает, что ему отвечает человек, этот вызов немедленно передается агенту, обслуживающему клиентов. Поскольку лишь малая часть вызовов приводит к соединению с людьми (чаще всего нужные номера заняты или по ним никто не отвечает, либо трубку снимает автоот-
620
ЧАСТЬ 4
Интеграция сетей и мультимедиа
нетчик), такое приложение резко повышает эффективность телемаркетинга, не тратя рабочее время агента на непродуктивные звонки. Интерактивный голосовой ответчик. Средства интерактивного голосового ответа (Interactive Voice Response, IVR) позволяют разработчикам создавать голосовые меню, сообщающие, какие кнопки телефона следует нажать, чтобы получить доступ к нужной информации или выполнить какую-либо транзакцию. Компьютерная мини-АТС. TAPI предоставляет интерфейс для создания унифицированного входного ящика — мини-АТС на основе персонального компьютера. Весьма изощренные сервисы обработки вызовов могут быть полностью реализованы средствами Windows 2000. IP-телефония и конференции. TAPI включает в себя провайдеры сервисов IP-телефонии*, которые поддерживают и видеоконференции по IP-сетям.
Microsoft-поддержка CTI Поддержка TAPI также встроена в клиентские операционные системы Windows 95 и Windows 98. Инфраструктура телефонии и поддержки конференций в Windows 2000 состоит из: •
приложения Phone Dialer (Телефон);
•
интерфейса TAPI 3.0;
•
провайдеров сервисов телефонии (Telephony Service Providers, TSP).
Приложение Phone Dialer TAPI-приложение Phone Dialer поставляется с Windows 2000. Phone Dialer поддерживает базовые функции телефонии, а также аудио- и видеоконференции. Вызывая TAPI-функции, Phone Dialer использует различные TSP, в том числе Н.323 и Multicast Conferencing (этот компонент поддерживает многоадресные конференции). Кроме того, Phone Dialer можно использовать с TSP, поставляемыми другими вендорами. ^ Чтобы запустить Phone Dialer: 1. Из меню Start (Пуск) последовательно откройте подменю Programs (Программы), Accessories (Стандартные) и Communications (Связь). 2.
Выберите команду Phone Dialer (Телефон).
TAPI 2.1 и 3.0 Операционные системы Microsoft Windows до Windows 2000 поставлялись с TAPI версии 2.1 или ниже. (Например, в Windows 95 включен TAPI 1.4, который можно обновить ло ТАР1 2.1, a Windows 98 поставляется с TAPI 2.1.) Эти версии TAPI предоставляли интерфейс для процедурного программирования на Microsoft С. В Windows 2000 включен TAPI 3.0, но эта операционная система поддерживает и предыдущие версии TAPI. В TAPI 3.0 введена поддержка Microsoft COM (Com-
В русской версии Windows 2000 провайдеры сервисов назьшаются поставщиками служб или услуг. — Прим. перев.
ГЛАВА 15
Интеграция телефонии и поддержка конференций
621
ponent Object Mode)). Специальный набор СОМ-объектов позволяет создавать приложения телефонии на любом СОМ-совместимом языке программирования, в том числе на Microsoft Visual Basic, Java и Microsoft V i s u a l C++, а также на языках, предназначенных для написания сценариев («скриптовых» языках), таких как Visual Basic Scripting Edition (VBScript) или JavaScript. APT для я;шка С по-прежнему поддерживается, и Вы можете использовать старые приложения телефонии, рассчитанные именно на этот интерфейс. В дополнение к СОМ интерфейс TAPI 3.0 поддерживает функциональность для IPтелефонии на базе Н.323 и для многоадресных (многосторонних) аудио- и видеоконференций по TCP/IP-сетям.
Провайдеры сервисов Провайдер сервисов — это DLL, предоставляющая набор экспортируемых функций для взаимодействия с одним или несколькими специфическими устройствами. Провайдер сервисов отвечает на запросы, посылаемые TAPI, и выполняет соответствующие низкоуровневые операции. Таким образом, провайдер сервисов в сочетании с TAPI скрывает от приложений специфику различных сервисов и технологий, п >именяемых при коммуникационной связи по сетям. Разработчики могут сами писать провайдеры сервисов для нового или существующего оборудования (чтобы расширить спектр предоставляемых сервисов телефонии). Каждый провайдер сервисов поддерживает минимум одно аппаратное устр: >йство, например плату факс-связи, ISDN-адаптер, телефон или модем. Программа установки провайдера должна связывать этот компонент с его устройствами. ТАР1 3.0 поддерживает два класса провайдеров сервисов: TSP (Telephony Service Providers) и MSP (Media Service Providers). TSP реализуют передачу сигналов и управление соединениями, a MSP обеспечивают доступ к конкретному виду информации, сопоставленному с соответствующим соединением. Если TSP — обязательные компоненты, то MSP появились лишь в TAPI 3.0 и не поддерживаются предыдущими версиями этого интерфейса. Windows 2000 включает в себя целый набор провайдеров сервисов, которые будут детально рассмотрены в этой главе: • • • • • •
Н.323 Service Provider (Поставщик службы доступа Н.323); Multicast Conferencing Service Provider (Поставщик услуг многоадресных конференций); NDIS Proxy Service Provider (Поставщик службы NDIS-прокси); Retnote Service Provider (Удаленный поставщик услуг); TAPI Kernel-Mode Service Provider (Поставщик службы привилегированного режима TAPI); Unimodem 5 Service Provider (Поставщик услуг Unimodem).*
* Названия этих провайдеров сервисов в русской версии Windows 2000 переведены некорректно, в частности Remote Service Provider .-m> провайдер удаленных сервисов (сам провайдер размещается на клиенте и лишь предоставляет доступ к соответствующим сервисам на сервере), а TAPI Kernel-Mode Service Provider — это провайдер сервисов ТАРТ. работающий в режиме ядра (операционной системы, а не ТАР1). — Прим. перео.
ЧАСТЬ 4 Интеграция сетей и мультимедиа
622
Примечание Устанавливая TSP и MSP от сторонних поставщиков, соблюдайте их инструкции по установке. Чтобы проверить, правильно ли установлены TSP и MSP, используйте оснастку Telephony (Телефония).
Архитектура TAPI Все компоненты Win32 Telephony (кроме компонентов, предоставляемых для обратной совместимости) являются 32-разрядными. Существующие 16-разрядные приложения связываются с Tapi.dll. В Windows 3.1 и Windows 95 Tapi.dll — основной компонент Windows Telephony, но в TAPI версии 2.0 и выше Tapi.dll стала просто шлюзом, который преобразует 16-разрядные адреса в 32-разрядные и перенаправляет запросы в Tapi32.dll. Существующие 32-разрядные приложения связываются с Tapi32.dll. В Windows 95 Tapi32.dll является шлюзовым уровнем для TAPI. В TAPI версии 2.0 и выше Tapi32.dll стала уровнем маршалинга, который передает вызовы функций в Tapisrv.dll и при необходимости загружает DLL-библиотеки пользовательских интерфейсов различных провайдеров сервисов в адресное пространство процесса (выполняемого приложения). Основной компонент TAPI — Tapisrv.dll. Он работает как отдельный процесс сервисов, в котором выполняются все TSP. Провайдеры сервисов могут создавать потоки в контексте TAPISRV, если это необходимо для их работы. К важнейшим компонентам архитектуры TAPI 3.0 относятся; •
TAPI 3.0 COM API;
• TAPI Server; • TSP; • MSP.
TAPI 3.0 COM API TAPI 3.0 COM API реализуется как набор СОМ-интерфейсов (Component Object Model). Это позволяет разработчикам писать TAPI-нриложения на любом языке программирования, который поддерживает СОМ, например на Java, Visual Basic или Microsoft Visual C/C++.
TAPI Server TAPI Server предоставляет независимый от приложения контекст, в котором могут выполняться провайдеры сервисов телефонии (TSP). API-функции TAPI запрашивают сервисы от TSP через TAPI Server.
TSP В состав TAPI 3.0 включены два новых провайдера сервисов IP-телефонии и связанные с ними провайдеры медийных сервисов (Media Service Providers, MSP).
Провайдер сервисов Н.323 Провайдер сервисов телефонии Microsoft H.323 и связанный с ним провайдер медийных сервисов позволяют TAPI-нриложениям участвовать в мультимедийных
ГЛАВА 15
Интеграция телефонии и поддержка конференций
623
аудио/видеосеансах связи с любым Н.323-совместимым терминалом (например, с Microsoft NetMeeting) по локальной сети или через Интернет. R частности, Н.323 TSP и MSP реализуют сигнальный стек Н.323. При этом Н.323 TSP принимает адреса в различных форматах (например, в виде имени пользователя или компьютера и адреса электронной почты). Н.323 MSP отвечает за формирование цепочки фильтров Microsoft DirectShow для Н.323-соединения, включая RTF (Real-Time Transport Protocol), кодек, приемник (sink) и фильтры рендеринга.
Провайдер сервисов для многоадресных конференций Этот провайдер обеспечивает на основе групповой IP-рассылки эффективную поддержку многосторонних аудио- и видеоконференций по IP-сетям, интрасетям и Интернету. Так как видеопотоки требуют широкой полосы пропускания, реализовать многосторонние видеоконференции было очень трудно. Теперь благодаря использованию групповой IP-рассылки можно резко сократить число иидеопотоков.
Провайдер сервисов NDIS-прокси Провайдер сервисов NDIS-прокси (NDIS Proxy Service Provider) предоставляет TAPI-интсрфейс с WAN-устройствами типа ISDN или ATM. TAPI-приложения могут напрямую использовать эти устройства (если они соответствуют спецификации NDIS 5). NDIS-прокси — это универсальный провайдер сервисов, поддерживающий все WAN-устройства NDIS 5. Важная особенность NDIS Proxy Service Provider заключается в том, что нижележащие компоненты NDTS 3 не обязаны поддерживать TAPI. Благодаря этому провайдеру TAPI-приложения, например служба маршрутизации и удаленного доступа, могут устанавливать соединения через WAN с использованием драйверов NDIS 5.
Провайдер удаленных сервисов ТАР! содержит провайдер удаленных сервисов (Remote Service Provider, Remote SP) для поддержки клиент-серверной телефонии. Этот провайдер предоставляет расширения сервисов телефонии TAPISRV для доступа клиентов к TAPI-устройствам, находящимся на серверных компьютерах. Remote SP размещается на клиенте, и TAPI рассматривает его как дополнительный провайдер сервисов. Когда TAPIзапрос выдастся через Remote SP, тот связывается с удаленным сервером телефонии. Провайдер сервисов на сервере, который в конечном счете и обслуживает этот запрос, не обязательно должен знать, что он работает в клиент-серверной среде.
Провайдер сервисов TAPI в режиме ядра Провайдер сервисов TAPI в режиме ядра (TAPI Kernel-Mode Service Provider), взаимодействуя с компонентами NDIS 4, предоставляет TAPI-интерфейс к драйверам WAN-устройств NDIS 4 для обратной совместимости. Пример драйвера, способного использовать преимущества такого NDIS-прокси, — ISDN-драйвер, поддерживающий логические соединения. Этот драйвер позволяет TAPI-приложениям с помощью TAPI Kernel-Mode Service Provider устанавливать РРР-соединения через WAN-сети.
Провайдер сервисов Unimodem 5 Unimodem 5 — это TSP, создающий уровень абстракции для модемов, благодаря чему приложения могут работать с самыми разнообразными типами и моделями
624
ЧАСТЬ 4
Интеграция сетей и мультимедиа
модемов, ничего не зная о специфике конкретного модема. Unimodem 5 также поддерживает модемы, способные передавать голосовые сообщения.
Другие провайдеры сервисов Независимые поставщики аппаратного и программного обеспечения могут создавать собственные TSP, совместимые с TAPI.
MSP TAPI 3.0 поставляется с двумя MSP (Media Service Providers): H.323 Conferencing MSP и IP Multicast Conferencing MSP. Эти MSP используют DirectShow API для эффективного управления и манипулирования потоковой информацией. Архитектура TAPI показана на рис. 15-1.
Клиент-серверная телефония В клиент-серверной среде TAPI обеспечивает распределенный доступ к общим ресурсам телефонии. Например, у LAN-сервера может быть несколько подключений к локальному телефонному коммутатору или к офисной мини-АТС. TAPI-onepaнии, запускаемые на любом клиенте, переадресуются этому серверу по локальной сети. При этом управление вызовами между сервером и мини-АТС осуществляется самим сервером. Такая модель позволяет не устанавливать на клиентских компьютерах программное обеспечение для управления вызовами и сократить затраты, если у Вас уже есть локальная сеть. Сервер можно подключить к коммутатору по каналу связи «коммутатор-хост». Кроме того, мини-АТС можно напрямую соединить с локальной сетью, в которой находится Ваш сервер и подключенные к нему клиенты. В рамках этой модели допустимо несколько конфигураций. •
Для поддержки персональной телефонии на каждом клиенте провайдер сервисов может представлять соединение компьютера с мини-АТС как одноканальное устройство.
•
Каждая станция может быть смоделирована как отдельное канальное устройство, что позволяет приложениям управлять вызовами на других станциях. (В терминологии мини-АТС станцией называется любое устройство, соединенное с мини-АТС проводами.) Эта конфигурация требует, чтобы приложение открывало все линии, которые ему нужно контролировать. • Все станции в целом могут быть представлены единственным канальным устройством с одним адресом (телефонным номером), который назначается каждой станции. В этом случае для мониторинга и контроля всех станций на линии достаточно открыть только это устройство, Основное преимущество подобных клиент-серверных реализаций — меньшая стоимость сервисов телефонии.
Интеграция телефонии и поддержка конференций
ГЛАВА 15
TAPI 1л, 2.x (С API) Управление вызовами
625
TAPI 3.0 (COM API) Управление | Управление потовызовами КОЕОЙ информацией
Управление каталогами
i О Служба каталогов Active Directory в Windows 2000 TSPI (Telephony Service Provider Interface)
KMDQSP Сторон-
ний TSP
Urnmodem
WDISпрокси
н.згз
; Групповая i IP-рассылка j (IP MC)
Unimodem MSP
цепочка фильтров DirectShow Streaming Modem GSA
«*•>
Кодек
H.323 MSP
IPMC MSP
•MSPI (Media Service Provider Interface)
Цеп очка фильтров ffi eel Show Streaming JRTPj -^H^- Кеде к
или +*. видео
Аудио
Winsock2.0
TCP/IP
адаптер 1
Мини-АТС (РВХ)
Модем
ATM- или ISDN-адаптер
ISDN
^-^^
Рис. 15-1. Общая схема архитектуры TAPI
Интернет-телефония и конференции Традиционная телефония базируется на коммутируемых сетях голосовой связи, и эти сети в той или иной мере можно интегрировать с компьютерными сетями, предназначенными для передачи данных. Так что технологии IP-телефонии и поддержки конференций на самом деле построены на очень простых концепциях. Персональный компьютер (или другое устройство) отправителя принимает аудио- и видеосигналы, например, от микрофона, соединенного со звуковой платой, и от видеокамеры, подключенной к плате видеозахвата. Эта информация сжимается и передается указанным получателям по локальной сети или через Интернет. На при-
626
ЧАСТЬ 4 Интеграция сетей и мультимедиа
нимающеи стороне сигналы восстанавливаются и воспроизводятся для получателя: звук — через динамики, подключенные к звуковой плате, а видео — в окне, созданном на экране монитора. Windows 2000 предоставляет два набора технологий, обеспечивающих интеграцию компьютерных сетей и сетей голосовой связи.
Интернет-телефония на основе Н.323 Н.323 — это протокол, разработанный ITU-T и применяемый для поддержки сервисов передачи голосовой и видеоинформации по компьютерным сетям. Если говорить в самом общем виде, то Н.323 позволяет передавать по интрасети аудио- и видсовызовы типа «точка-точка». Microsoft-реализация этого протокола поддерживает голосовые вызовы, направляемые на обычные телефоны с использованием шлюзов IP-PSTN, а также аудио- и видсовызовы через Интернет. Подробнее о Н.323 см. по ссылке International Telecommunication Union на странице Web Resources (http://windows.microsoft.com/windows2000/reskit/webresources).
Н.323-вызовы через Phone Dialer С помощью TAPI-приложения Phone Dialer (Телефон) можно передавать аудио- и видеовыловы Н.323 по IP-сетям. Адресаты идентифицируются самыми разными способами. Часто вызываемых пользователей можно внести в списки ускоренного вызова (speed dial lists). Кроме того, диалоговое окно Dial (Вызов) позволяет вызывать адресата по имени или IP-адресу компьютера, на котором работает Н.323приложение вызываемого пользователя. Разрешив идентификационные данные вызываемой стороны в IP-адрес соответствующего компьютера, Phone Dialer выдает TAPI-вызовы, направляемые Microsoft Н.323 TSP. Провайдер сервисов заставляет протокол Н.323 выполнить работу, необходимую для настройки вызова. Затем MSP, связанный с Н.323 TSP, использует ресурсы компьютера для соединения с вызываемой стороной и создания аудиои/ил и видеоконференции. Н.323-вызовы IP-телефонии можно выдавать и через Windows Address Book (WAB) (Адресная книга), которая в таком случае сама обращается к Phone Dialer. ^ Чтобы выдать Н.323-вызов через адресную книгу: 1. Запустите WAB. Создайте'новый контакт и заполните нужные поля. 2. Щелкните Properties (Свойства) и откройте вкладку Business (Служебные). Введите имя пользователя, адрес электронной почты, имя или IP-адрес компьютера и щелкните кнопку ОК. 3. Теперь для вызова пользователя щелкните правой кнопкой мыши нужную запись в WAB. 4. Последовательно выберите команды Action (Действие) и Dial (Позвонить). Это приведет к запуску Phone Dialer (Телефон), который и обработает вызов.
Прием Н.323-вызовов Phone Dialer позволяет слушать входящие Н.323-вызовы IP-телефонии, уведомлять пользователя о таких вызовах и принимать или отклонять их на основе критериев, указанных пользователем. Эта функциональность доступна и в том случае, если
ГЛАВА 15
Интеграция телефонии и поддержка конференций
627
Phone Dialer свернут в значок, помещаемый в секцию индикаторов (system tray) на панели задач.
Использование служб каталогов Windows 2000 Windows 2000 предоставляет службы каталогов для вызова адресатов по имени, а не по телефонным номерам или IP-адресам. Трансляция имен пользователей в телефонные номера или IP-адреса осуществляется через TAPI. TAPI-приложения, выполняемые в Windows 2000, могут использовать две службы каталогов: Active Directory™ и Site Server ILS Service (Служба ILS сервера сайта). Active Directory — это новая служба Windows 2000, которая поддерживает масштабируемое, централизованно адмшшстрируемое и автоматически реплицируемое хранилище. Она позволяет хранить различную информацию в виде атрибутов в наборе объектов, представляющих сстеные ресурсы. TAPI записывает сведения об именах или IP-адресах компьютеров пользователей, которым можно направлять Н.323-ВЫЗОВЫ, в атрибуты IPPhone соответствующих объектов User. Приложение Phone Dialer автоматически находит объект User для пользователя, вошедшего в систему, и обновляет его атрибут IPPhone. Когда другой пользователь пытается связаться с данным пользователем, объект Rendezvous в TAPI ищет в каталоге имя и IP-адрес компьютера по имени или почтовому адресу вызываемого пользователя. После этого приложение обращается к 11.323 TSP и указывает IPадрес, по которому следует выдать вызов. Site Server ILS Service — еще одна служба каталогов, с которой могут работать TAPI-приложения в Windows 2000. Она отличается от Active Directory меньшей масштабируемостью и отсутствием возможностей централизованного администрирования. Phone Dialer создаст объект пользователя в службе Site Server ILS [фи запуске и записывает в него IP-адрес компьютера этого пользователя в формате, совместимом с NetMeeting. Преимущество службы Site Server ILS в том, что она позволяет пользователям NetMeeting видеть пользователей TAPI-приложений и вызывать их двойным щелчком соответствующих имен.
Протоколы Н.323 Microsoft Н.323 TSP и MSP реализуют стек протоколов Н.323 версии 1.0. Он состоит из трех уровней сигнальных протоколов: • Registration, Admission, and Status; . •
Q.931; H.245.
Registration, Admission, and Status Registration, Admission, and Status использует UDP-порты 1718 и 1719 для обнаружения, регистрации и передачи запросов на прием вызовов между Н.323 Gatekeepers и приложениями Н.323. Этот уровень необязателен и в настоящее время не реализован в Microsoft Н.323 TSP. 0.931
Q.931 использует TCP-порт 1720 для настройки вызовов, уведомления, разрыва связи и для выполнения других задач, связанных с управлением логическими соединениями. Этот сигнальный уровень получает IP-адрес вызывающего абонента
628
ЧАСТЬ 4
Интеграция сетей и мультимедиа
От управляющего TAPI-объекта Rendezvous, хранящегося в службе каталогов Windows 2000. Q.931 поддерживается Microsoft H.323 TSP. Н.245 Н.245 использует динамические TCP-порты для выполнения таких задач, как согласование видов передаваемой информации и настройка каналов для ее пересылки. Этот уровень поддерживается Microsoft H.323 TSP.
Передача потоков данных с помощью RTP Н.323 передает оцифрованные аудио- и видеоданные между сторонами, участвующими в конференции, по протоколу RTP (Real-Time Transport Protocol). Этот протокол использует динамические UDP-норты, согласованные отправителем и получателем конкретных потоков данных. Каждый RTF-пакет содержит полезные данные одного или нескольких видов и такую сопутствующую информацию, как временные метки и номера последовательностей. В TAPI 3.0 включена реализация стека протоколов RTP.
Аудио- и видеокодеки Аудио- и видеокодеки на передающей стороне применяются для сжатия оцифрованных аудио- и видеосигналов перед посылкой но сети, а на принимающей — для декомпрессии данных перед иоспрожшеделием. Благодаря этому уменьшаются требования к полосе пропускания сети и снижается нагрузка на сеть. Microsoft H.323 MSP использует для аудиосигналов кодеки G.711 и G.723.1, а для видеосигналов — кодеки Н.261 и Н.263. Схема сжатия и декомпрессии видео с помощью кодеков показана на рис. 15-2. На ПК отправителя
Фильтр источника
-*
Сжимает видео
—+
Видеокодек
- Инкапсулирует сжатое видео в IP-пакеты
RTPфильтр
IP-сеть
^_ ; RTP-
1^
8идео- -^ кодек
фильтр
(
Извлекает инкапсулированное видео
L
Декомпрессирует видео
{
L
рендеринга Посылает видео на экран
Рис. 15-2. Кодеки, применяемые для сжатия и декомпрессии видео
ГЛАВА 15 Интеграция телефонии и поддержка конференций
629
Вызовы через шлюзы IP-PSTN Протокол 11.323 поддерживает передачу вызовов из компьютерных сетей в коммутируемые телефонные сети (PSTN) и наоборот. Основное преимущество такой поддержки в том, что междугородную часть пути вызов проходит по частным или общедоступным компьютерным сетям, а затем передается в местную телефонную есть (обычной голосовой связи). Это позволяет избавиться от высоких тарифов, действующих для междугородных звонков. Например, пользователь из филиала в Сиэтле звонит в Бостон; при этом телефонный вызов передается по корпоративной сети и уже в Бостоне попадает в местную телефонную сеть. То есть звонок превращается из междугородного в местный. Такая схема особенно эффективна, если у предприятия есть собственные WAN-каналы связи со своими подразделениями и филиалами. 11.323 TSP поддерживает вызовы через шлюз IP-PSTN (мост между IP- и PSTNсетями), для настройки которого нужно выполнить следующую процедуру, >• Чтобы указать IP-адрес шлюза IP-PSTN: 1.
Из меню Start (Пуск) последовательно выберите команды Settings (Настройка) и Control Panel (Панель управления).
2. Дважды щелкните значок Phone and modem options (Телефон и модем). 3. Откройте вкладку Advanced (Дополнительно) и выберите Microsoft Ю23 Telephony Service Provider (Поставщик службы доступа Microsoft H.323 TAPI). 4. Щелкните кнопку Configure (Настроить). Установите флажок Use H.323 Gateway (Шлюз H.323) и введите в соседнее поле имя компьютера или IP-адрес шлюза IP-PSTN. Пользователи могут указывать IP-адрес или имя компьютера шлюза IP-PSTN, через который H.323 TSP маршрутизирует все вызовы IP-PSTN. Пример работы такого шлюза показан на рис. 15-3.
Терминал Н.323
Рис. 15-3. Шлюз IP-PSTN
Вызовы через брандмауэры Н.323-ВЫЗОВЫ нельзя передавать через брандмауэры на основе простой трансляцли сетевых адресов (NAT). Для передачи и приема таких вызовов между компьютера-
630
ЧАСТЬ 4
Интеграция сетей и мультимедиа
ми, разделенными в сетях брандмауэрами, требуются специальные прокси-серверы прикладного уровня. Брандмауэры устанавливаются многими предприятиями с целью защиты своих интрасетей от бесконтрольного доступа из Интернета. Это, естественно, усложняет передачу Н.323-вызовов IP-телефонии через Интернет. Microsoft H.323 TSP предоставляет поддержку для передачи Н.323-вьтзовов через брандмауэры. С этой целью нужно задать внутренний IP-адрес компьютера, на котором установлен брандмауэр. ^ Чтобы указать IP-адрес прокси-сервера Н.323: 1. Из меню Start (Пуск) последовательно выберите команды Settings (Настройка) и Control Panel (Панель управления). 2. 3.
Дважды щелкните значок Phone and modem options (Телефон и модем). Откройте вкладку Advanced (Дополнительно) и выберите Microsoft H.323 Telephony Service Provider (Поставщик службы доступа Microsoft H.323 TAPI).
4.
Щелкните кнопку Configure (Настроить). Установите флажок Use H.323 Proxy (Прокси-сервер Н.323) и введите в соседнее поле имя или IP-адрес брандмауэра/прокси-сервера Н.323, используемый из интрасети,
Вызовы через Gatekeepers Gatekeepers — полезные средства для управления клиентами IP-телефонии, обеспечивающие разрешение адресов, перенаправление и регистрацию вызовов, а также другие сервисы. Текущая реализация Н.323 Service Provider не поддерживает Н.323-вызовы через Gatekeepers.
Поддержка Quality of Service TAPI поддерживает Quality of Service (QpS), повышая качество коммуникационной связи при конференциях. QoS предоставляется как в ATM-сетях, так и в сетях, где данные передаются пакетами, например в Интернете. В TAPI приложения и провайдеры сервисов обмениваются информацией о QoS через структуры FLOWSPEC, определенные в Windows Sockets 2.0. Поддержка QoS не ограничивается транспортами ATM; соответствующую функциональность может реализовать любой провайдер сервисов. QoS в TAPI 3.0 обрабатывается через RTP-фильтр DirectShow, который согласует с сетью полосу пропускания на основе требований кодеков DirectShow, связанных с конкретными потоками данных. Кодеки сообщают об этих требованиях RTPфильтру через свой QoS-интерфейс. В свою очередь RTP-фильтр через СОМ-интерфейсы Winsock2 GQoS передает требования к QoS провайдеру сервисов QoS (QoS service provider, QoS SP) в Winsock2. Тот активизирует различные механизмы QoS, подходящие для конкретных приложения, несушей среды и сети; используя эти механизмы, QoS SP согласует приемлемое качество обслуживания на всем пути между сторонами соединения. Все эти механизмы перечислены ниже. •
RSVP (Resource Reservation Protocol) предоставляет QoS в сетях, отличных от ATM. RSVP является сигнальным протоколом, который позволяет отправителю и получатели) резервировать в сети нужную полосу пропускания. Запрос на резервирование в виде RSVP-сообщения передается каждому маршрутизатору и коммутатору на всем пути между отправителем и получателем.
ГЛАВА 15
Интеграция телефонии и поддержка конференций
631
•
Local Traffic Control — механизм QoS, который уменьшает задержки при передаче сетевого трафика и обеспечивает управление им в сетях, не поддерживающих RSVP (например, в унаследованных или широковещательных сетях).
•
Packet Scheduling управляет очередями, создаваемыми классификатором пакетов. Он извлекает пакеты из очередей и посылает их по соединению с согласованным качеством обслуживания.
•
802.1р определяет механизм, с помощью которого разным видам LAN-траф'Ика можно назначать разные приоритеты. Как правило, хосты или маршрутизаторы, посылающие трафик в локальную сеть, указывают для передаваемых пакетов подходящие значения приоритетов. Тем самым хосты или маршрутизаторы через 802.1р уведомляют сетевые устройства об уровне приоритета каждого пакета. Сетевые устройства (коммутаторы, мосты, концентраторы и др.) должны соответствующим образом обрабатывать эти пакеты.
Подробнее о QoS см. главу 9 «Quality of Service» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server».
Многосторонние конференции на основе групповой IP-рассылки Multicast Conferencing Service Provider, включенный в TAPI 3.0, поддерживает многосторонние аудио- и видеоконференции на основе групповой IP-рассылки. О'бъект Rendezvous в TAPI 3.0 предоставляет дополнительные СОМ-интерфейсы, которые ТАРI-приложения могут использовать для обращения к службам каталогов (Active Directory или Site Server ILS Service).
Конференции Модель вызовов для многосторонних конференций отличается от традиционной модели вызовов «один-к-одному». Конференцию ведет один из участников, который должен присвоить ей имя, указать время ее начала и окончания, а также составить список участников. После этого ведущий публикует конференцию на сервере через TAPI-приложение (например, Phone Dialer) и уведомляет ее участников об этой конференции. Остальные участники с помощью своих TAPI-приложений подключаются к сериеру и просматривают список конференций, в которых они могут принять участие, В назначенное время участники присоединяются к конференции через ТАРГ-лриложепие. TAPI предоставляет всю инфраструктуру для передачи и приема аудио- и видеопотоков с использованием групповой IP-рассылки.
Групповая IP-рассылка Групповая IP-рассылка (IP multicast) — это расширение IP, позволяющее эффективнее проводить конференции. Без групповой ТР-рассылки пользователь, которому нужно передать свои данные .V пользователям, был бы вынужден посылать эти данные по N соединениям (рис. 15-4). В результате полоса пропускания сети впустую расходовалась бы на передачу одних и тех же данных каждому получателю. Групповая ТР-рассылка исключает передач}* лишних данных по одним и тем же коммуникационным каналам. Чтобы обратиться к группе IP-рассылки, пользователь посылает один экземпляр данных на единственный IP-адрес нужной группы, который прослушивают все получатели. При этом отправителю не обязательно знать,
632
ЧАСТЬ 4
Интеграция сетей и мультимедиа
кто именно входит в группу. Для приема данных получатели регистрируются по IPадресу нужной группы рассылки на маршрутизаторе, который поддерживает пересылку группового трафика. Идентичные данные
Рис. 15-4. Передача одинаковых данных без групповой IP-рассылки
IP-адрес группы рассылки Групповая IP-рассылка, при которой используется единственный IP-адрес группы рассылки, уменьшает сетевой трафик. На рис. 15-5 показан пример, где в конференции участвуют шесть пользователей, связанных друг с другом через маршрутизаторы. Без групповой IP-рассылки каждый и:) шести участников многосторонней конференции передавал бы остальным участникам 5 копий своих аудио- и видеоданных, что могло бы привести к появлению в сети до 30 аудио- и 30 видеопотоков! Групповая IP-рассылка исключает такую нагрузку. Данные передаются на един* ственный IP-адрес группы рассылки, к которой присоединяются все шесть участников. Маршрутизаторы, способные пересылать групповой трафик, эффективно распределяют потоки данных «один-ко-многим» по алгоритму ветвления (spanning tree algorithm); при этом между каждыми двумя маршрутизаторами формируется только один коммуникационный путь. Поток копируется лишь при разветвлении пути, как показано па рис. 15-6.
Выделение групповых адресов Для групповой IP-рассылки используются IP-адреса класса D (от 224.0.0.0 до 239.255.255.255), предназначенные для идентификации групп хостов. Поддерживаются как постоянные, так и временные групповые адреса. Постоянные адреса
ГЛАВА 15
Интеграция телефонии и поддержка конференций
Элис Подсеть
Джим
Маршрутизатор 3
Джон I Маршру-: тизатор 1
Маршру- Маршрутизатор 5 тизатор 6
Подсеть
Маршрутизатор 4
т
О
:
Подсеть
1'
Маршру- ! тизатор 2
щ j
-
Подсеть
"-J.' --.-Т s-"
Билл
Мэри Рис. 15-5. Многосторонняя конференция на основе групповой IP-рассылки
I
Джон
Мэри
Маршрутизатор 2^
Маршрутизатор!
Маршру- Ш тизатор 3 ^Pf
(§|
ЭЛИС ':
Боб
Билл: Маршрутизатор 4
1 :
Ч~^
1
Джим
Маршрутизатор 5 Рис. 15-6. Алгоритм ветвления при групповой IP-рассылке
633
Б34
ЧАСТЬ 4 Интеграция сетей и мультимедиа
выделяются комитетом IANA (Internet Assigned Numbers Authority). В настоящее время 224.0.0.1 зарезервирован для обращения ко всем группам хостов в локальной сети, а 224.0.0.2 — для обращения ко всем маршрутизаторам в локальной сети. Диапазон адресов от 224.0.0.0 до 224.0.0.255 резервируется для протоколов маршрутизации и других низкоуровневых сетевых протоколов. Также резервируются и некоторые другие адреса и диапазоны, например 224.0.13.000-224.0.13.255 выделяется для NetNews. Подробнее на эту тему см. RFC 1700. В Windows 2000 входит сервер MADCAP (Multicast Address Dynamic Client Allocation Protocol), выделяющий уникальный IP-адрес групповой рассылки на время проведения конференции. TAPI предусматривает специальный API, позволяющий приложениям автоматически (без участия пользователя) выдавать этому серверу запросы на аренду таких адресов и получать нужный групповой адрес. Эти запросы выдаются при создании конференции, что гарантирует получение уникального IP-адреса, по которому к ней могут присоединиться остальные участники. Примечание Чтобы TAPI-приложения могли получать IP-адреса групповой рассылки, в каком-то месте сети следует разместить сервер MADCAP. Подробнее о MADCAP и о его поддержке в Windows 2000 см. главу 4 «DHCP* в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server».
Публикация объектов конференции Определив параметры конференции, ведущий может распространить эту информацию потенциальным участникам несколькими способами. TAPI предоставляет средства для публикации конференций в службе Site Server ILS, выполняемой па централизованном сервере; через этот сервер все, кому ведущий выдал право на участие в конференции, получают доступ к информации, относящейся к конференции. Эта информация хранится в объектах конференции, определенных в RFC 2327. TAPI также позволяет обращаться к Site Server ILS, выполняемой па удаленных серверах, чтобы пользователи могли просматривать опубликованные объекты конференций и при необходимости присоединяться к конференциям, описанным в этих объектах. В пользовательском интерфейсе Phone Dialer (Телефон) предусмотрены соответствующие средства, упрощающие создание, просмотр и присоединение к конференциям. Примечание Чтобы TAPI-приложения могли создавать объекты конференций, в каком-то месте сети следует разместить сервер со службой Site Server ILS. Служба Site Server ILS публикует свой адрес в сети через Active Directory. Соответствующие механизмы TAPI позволяют TAPI-приложениям находить серверы Site Server ILS, запрашивая Active Directory. Благодаря этому пользователям не требуется знать специфику серверов 1LS и их местонахождение.
Протокол SDP SDP (Session Description Protocol) — это IETF-стандарт оповещения о мультимедийных конференциях. SDP обеспечивает публикацию необходимых сведений о конференции (время проведения, адрес, типы информации и др.), чтобы потении-
ГЛАВА 15
Интеграция телефонии и поддержка конференций
635
альиые участники могли присоединиться к ней, если их заинтересует эта конференция. SDP, изначально рассчитанный на функционирование поверх Internet MBONE, теперь интегрирован через TAPI 3.0 со службами Active Directory и Site Server ILS и предоставляет свою функциональность LAN-сетям. SDP-дескриптор (SDP descriptor) несет следующую информацию (в виде атрибутов) о конференции: • • •
Conference Name and Purpose (имя и цель конференции); Conference Time (время конференции); Conference Contact Information (контактная информация);
• •
Media Type (video, audio, and so on) [тип информации (видео, аудио и др.)]; Media Format (H.261 Video, MPEG Video, and so on) [формат информации (видео H.261, MPEG-видео и др.)|; • Transport Protocol (RTP/UDP/IP, H.320, and so on) [транспортный протокол (RTP/UDP/IP, H.320 и др.)]; • Media Multicast Address (групповой адрес для приема данного типа информации); •
Media Transport Port (порт транспорта данного типа информации);
•
Conference Bandwidth (полоса пропускания, необходимая для конференции).
Все описание конференции разбивается на три основные части: описание сеанса (только одно), описания времени (произвольное количество) и описания информации (произвольное количество). Описание сеанса содержит глобальные атрибуты, применяемые ко всей конференции или ко всем потокам информации. Описания времени содержат сведения о начале и окончании конференции, а также о времени ее повторной трансляции. Наконец, описания информации сообщают данные, специфичные для конкретного потока информации.
Модель безопасности конференций Модель безопасности конференций в TAPI 3.0 обеспечивает контроль над тем, кто имеет права на создание, удаление и просмотр объявлений о конференциях. Каждый объект в Active Directory можно сопоставить с ACL (списком управления доступом), указав права на доступ к объекту для каждого пользователя или группы. Сопоставляя такие ACL с SDP-дескрипторами конференций, как показано на рис. 15-7, создатели конференций могут контролировать, кто имеет право на перечисление и просмотр объявлений о конференциях. Аутентификация пользователей осуществляется через систему защиты Windows 2000. ADI
Сервер со службой Site Server ILS
Рис. 15-7. SDP-дескрипторы и ACL-списки
636
ЧАСТЬ 4 Интеграция сетей и мультимедиа
Дескрипторы сеансов передаются пользователю с сервера Site Server ILS по протоколу LDAP в порт 1002. Для защиты соответствующих соединений можно использовать средства IPSec, предоставляемые Windows 2000. Внимание Текущие реализации не поддерживают шифрование потоков мультимедийной информации.
Служба маршрутизации и удаленного доступа Маршрутизаторы и серверы удаленного доступа под управлением службы маршрутизации и удаленного доступа следует явно настроить на пересылку групповых пакетов и IGMP-запросов (Internet Group Management Protocol), генерируемых клиентскими компьютерами, пользователи которых хотят присоединиться к многосторонним конференциям. Подробнее о настройке сервера удаленного доступа в Windows 2000 на пересылку группового трафика см. главу 7 «Сервер удаленного доступа» в этой книге.
Выявление и устранение проблем В этом разделе приводятся сведения, которые помогут Вам в устранении проблем с телефонией.
Проблемы с PSTN-телефонией Здесь рассматриваются наиболее распространенные проблемы с традиционной PSTN-телефонией (не на основе IP) и предлагаются способы их решения. Один или несколько клиентских компьютеров не «видит» сервер телефонии Если достичь сервер телефонии по сети не удается (например, команда ping не находит этот сервер), возможны следующие причины: •
неправильно настроен сервер телефонии (о настройке серверов телефонии см. справочную систему Windows 2000 Server); • не установлен протокол Unicast IP (об установке и отладке Unicasl IP см. справочную систему Windows 2000 Server); • неправильно сконфигурирован домен Windows 2000 (об установке контроллера домена см. справочную систему Windows 2000 Server). Один или несколько клиентских компьютеров не «видит» линии на сервере телефонии Если один или несколько клиентских компьютеров не «видит» линии на сервере телефонии, то, возможно, им не удается пройти авторизацию для доступа к линиям на этом сервере. Когда TAPI-приложение обращается к линиям на сервере телефонии, сначала аутентифицируется контекст пользователя, сопоставленный с процессом данного приложения. То есть линии на сервере телефонии должны быть сконфигурированы так, чтобы клиенту был разрешен доступ к ним. Поэтому, если клиент не видит линии на сервере телефонии, возможны следующие причины; •
линии на сервере сконфигурированы некорректно, и клиент не получает к ним доступа (об установке серверов телефонии и управлении ими см. справочную систему Windows 2000 Server);
ГЛАВА 15
Интеграция телефонии и поддержка конференций
637
• контекст пользовательского процесса, в котором выполняется приложение, не сопоставлен с линиями (об управлении ТАРI-клиентами и пользователями на сервере телефонии см. справочную систему Windows 2000 Server), О доменах Active Directory и об авторизации пользователей см. справочную систему Windows 2000 Server. После закрытия диалогового окна Location Information приложение не запускается Если приложение больше не запускается после того, как Вы закрыли диалоговое окно Location Information (Сведения о местоположении), то скорее всего не указана информация, необходимая TAPI-приложениям для трансляции адресов. Тогда проблему можно устранить, вновь открыв это диалоговое окно и указав в нем код Вашей страны или региона, код города, правила набора номера (тональный или импульсный) и код выхода на внешнюю линию. Клиент не «видит» новую линию на сервере, хотя администратор сервера уже прикрепил клиент к этой линии Когда Вы прикрепляете выполняемый в данный момент клиент к линии на сервере телефонии, новые настройки не вступают в силу до перезапуска TAPI-клиента. Остановите все клиентские TAPI-приложения, чтобы прекратить работу TAPI. После перезапуска клиентские приложения обнаружат новые линии, выделенные им. Об управлении ТАPI-клиентами и пользователями см. справочную систему Windows 2000 Server.
Проблемы с Н.323-вызовами и многосторонними конференциями У пользователей 11.323 или многосторонних конференций на основе групповой IPрассылки могут возникать проблемы с подключением к другим пользователям или с приемом аудио/видеоданных. Если возникают проблемы со звуком В таком случае микрофоны и/или звуковые платы на клиентских компьютерах настроены некорректно или работают неправильно. Для диагностики звукового оборудования на клиентских компьютерах запустите программу Sound Recorder (Звукозапись). С этой целью либо последовательно раскройте меню Start (Пуск), Programs (Программы), Accessories (Стандартные), Entertainment (Развлечения) и выберите команду Sound Recorder (Звукозапись), либо введите sndrcc32 в командной строке. Попробуйте что-нибудь записать с микрофона, а затем воспроизвести эту запись. Если звука нет, проверьте, правильно ли подключен микрофон. Если же этот тест прошел нормально, а проблемы со звуком сохраняются, проверьте настройки звука па всех клиентских компьютерах. ^ Чтобы проверить настройки звука с помощью Volume Control: \. Последовательно раскройте меню Start (Пуск), Programs (Программы), Accessories (Стандартные). Entertainment (Развлечения) и выберите команду Volume Control (Громкость).
638
ЧАСТЬ 4
Интеграция сетей и мультимедиа
2. В окне этой программы выберите из меню Options (Параметры) команду Properties (Свойства) и щелкните переключатель Playback (Воспроизведение). Убедитесь, что ([шажки Wave и Microphone установлены*. 3. Щелкните кнопку ОК. 4. Пометьте флажок Mute (Выкл.) в столбце, который относится к микрофону, Это предотвратит воспроизведение динамиками Вашего компьютера сигналов, поступающих на микрофон. 5. Если голоса остальных участников конференции звучат слишком громко или слишком тихо, подстройте общий уровень громкости и уровень Wave. 6. Вновь выберите из меню Options команду Properties, но на этот раз щелкните переключатель Recording (Запись). Установите все флажки в окне, которое находится в нижней части диалогового окна. 7. Щелкните кнопку ОК. 8. Пометьте флажки Mute (Выкл.) во всех столбцах за исключением того, который относится к микрофону. Это позволит участникам конференции слышать Ваш голос, но исключит передачу любых других звуковых сигналов. 9. Если участников конференции не устраивает уровень громкости Вашего голоса, отрегулируйте чувствительность микрофона, перемещая соответствующий ползунок. Примечание Один неправильно настроенный компьютер может вызывать проблемы со звуком на компьютерах остальных участников конференции. Если неполадки со звуком сохраняются даже после регулировки настроек, проверьте, полнодуплексные ли звуковые платы установлены на проблемных компьютерах. Полнодуплексные звуковые платы могут одновременно и записывать, и воспроизводить звук, тогда как полудуплексные не позволяют этого делать, Современные звуковые платы являются полнодуплексными, но многие старые звуковые платы — лишь полудуплексными. Чтобы проверить, полнодуплексная ли звуковая плата установлена на компьютере, запустите Sound Recorder и запишите образец речи длиной около 30 секунд. После этого откройте второй экземпляр Sound Recorder. В первом экземпляре запустите воспроизведение и, пока он воспроизводит Вашу речь, попробуйте ее записать во втором экземпляре Sound Recorder. Если второй экземпляр Sound Recorder не сможет корректно записать звук, пока на первом экземпляре идет воспроизведение, значит, звуковая плата не является полнодуплексной и поэтому не годится для работы с ТАР I-приложениями. Если звук по-прежнему искажается, проблема может быть связана с микрофоном, звуковой платой или ее драйверами. Убедитесь, что для звуковой платы установлены самые последние драйверы, рассчитанные на Windows 2000. Кроме того, попробуйте заменить микрофон или звуковую плату и повторить все тесты.
Точные названия этих элементов управления зависят от программного обеспечения конкретной звуковой платы и даже в русской версии Windows 2000 могут заменяться английскими названиями, если программное обеспечен не звуковой платы не локализовано (что обычно и бывает). — Прим. перев.
ГЛАВА 15 Интеграция телефонии и поддержка конференций
639
Вы слышите зхо каждого звука Это довольно распространенная проблема при аудиоконференциях. Она возникает из-за того, что микрофон пользователя принимает звуки из динамиков и повторно перелает их другим участникам конференции. Разговор становится просто невозможным, если участники конференции используют очень чувствительные микрофоны, делают звучание своих динамиков чересчур громким или размещают микрофон слишком близко к динамикам. Один из самых простых способов полностью избавиться от эха — перейти на наушники с микрофоном. Более дорогостоящее решение — использовать специальные микрофоны со встроенными средствами эхоподавления. Возникают проблемы с видео Если видеоизображение какого-либо участника Н.323-конференции не появляется на экране другого участника или если изображение одного из участников многосторонней конференции не видно остальным участникам, устройство видеозахиата работает некорректно. Участвуя в видеоконференции, пользователи Phone Dialer должны видеть свое видеоизображение. Если это не так, запустите мастер устранения неполадок с видеокамерами из справочной системы Windows 2000 Professional, Неполадки со звуком и видео в многосторонних конференциях на основе групповой IP-рассылки могут быть вызваны и проблемами в самой групповой рассылке. В следующих разделах описывается, как выявить и устранить эти проблемы с использованием утилиты MCAST, находящейся на компакт-диске «Ресурсы Microsoft Windows 2000 Server». Как проверить конфигурацию маршрутизатора Проблемы в многосторонних конференциях на основе групповой IP-рассылки могут быть связаны с неправильной конфигурацией сети. ^ Чтобы настроить маршрутизатор на поддержку группового трафика: 1. Разрешите групповую рассылку из глобального контекста. 2. Определите интерфейсы маршрутизатора, которые должны поддерживать групповой трафик. 3. Разрешите использоваие протоколов маршрутизации группового трафика на выбранных интерфейсах. Например: • протокол PIM (Protocol Independent Multicast.) в режиме Sparse Mode для каналов с ограниченной полосой пропускания; • протокол PIM в режиме Dense Mode для широкополосных каналов; • протокол DVMRP (Distance Vector Multicast Routing Protocol). 4. Если потребуются списки доступа, см. документацию на маршрутизатор. Детальное описание конфигурационных данных для маршрутизатора обычно предоставляется его поставщиком, Как проверить, настроена пи сеть на передачу групповых пакетов Если Вы не знаете, настроена ли Ваша сеть на передачу групповых пакетов, воспользуйтесь диагностической утилитой MCAST. Она посылает и принимает групповые пакеты, помогая определить, какие части Вашей сети поддерживают передачу групповых IP-пакетов.
640
ЧАСТЬ 4 Интеграция сетей и мультимедиа
Чтобы запустить MCAST в режиме передачи групповых пакетов, введите в командной строке, например: HCAST /SEND /INTF:172.31.253.55 /GRPS:230.1.1.1 /INTVL:1000 /NUMPKTS:3600
В данном случае MCAST начнет посылать групповые пакеты с IP-адреса 172.31.255.255 на групповой IP-адрес 230.1.1.1 с периодичностью 1 пакет каждые 1000 мс. Всего в течение часа будет отправлено 3600 пакетов. Чтобы запустить MCAST в режиме приема групповых пакетов, введите в командной строке, например: MCAST /RECV /INTF: 172.31.255.255/GRPS:230.1.1.1
В данном случае MCAST начнет прослушивать по своему IP-адресу 172.31.255.255 пакеты, направляемые на групповой IP-адрес 230.1.1.1. Принимаемые пакеты перечисляются на экране: Started.... Waiting to receive packets... Received [1]: Received [2]: Received [3]: Received [4]: Received [5]:
[GOOD] SRC- 172.31.253.55 [GOOD] SRC- 172.31.253.55 [GOOD] SRC- 172.31.253.55 [GOOD] SRC- 172.31.253.55 [GOOD] SRC- 172.31.253.55
GRPGRPGRPGRPGRP-
230.1.1.1 230.1.1.1 230.1.1.1 230.1.1.1 230.1.1.1
TTLTTLTTLTTLTTL-
5 5 5 5 5
LenLenLenLenLen-
256 256 256 256 256
He удается публиковать приглашения на многоадресные конференции Если Вам не удается публиковать приглашения на многоадресные конференции, установите Site Server ILS Service (Служба ILS сервера сайта). Эта служба — важная часть IP Multicast Conferencing. Ее сервер предоставляет место встречи для создателей конференций и их потенциальных участников, которые находят там информацию, нужную для участия в той или иной конференции. При создании новой конференции приложение Phone Dialer автоматически создает на выбранном ILS-сервере объект конференции. Лица, которым предоставлено право на доступ к конференции, видят информацию об этой конференции в панели просмотра своих приложений Phone Dialer и могут присоединиться к ней, дважды щелкнув ее название. Об установке 1LS см. справочную систему Windows 2000 Server. Если Phone Dialer не «видит» ILS Приложение Phone Dialer (Телефон) в Windows 2000 должно знать местонахождение службы Site Server ILS, иначе оно не будет работать с конференциями. Phone Dialer может найти нужную информацию в Active Directory при соблюдении следующих условий: •
компьютер, на котором выполняется Phone Dialer, входит в домен Windows 2000;
•
пользователь зарегистрировался в системе по доменной учетной записи;
•
местонахождение ILS-сервера опубликовано в Active Directory.
При соблюдении всех этих условий пользователю не нужно знать, где именно находится ILS-сервср, и вручную вводить его адрес в Phone Dialer. Об установке контроллеров домена и Active Directory см. справочную систему Windows 2000 Server.
ГЛАВА 15
Интеграция телефонии и поддержка конференций
641
Если пользователю не удается обратиться к Active Directory Вес компоненты Windows 2000, необходимые для поддержки IP Multicast Conferencing, устанавливаются по умолчанию — при установке Windows 2000 Professional или Windows 2000 Server. Однако для работы с IP Multicast Conferencing клиентский компьютер или пользователь должен быть включен в домен Windows 2000. Если у пользователя или у его компьютера нет учетной записи для входа в домен Windows 2000, этот пользователь не получит доступа к Active Directory. В этом случае ему придется вручную вводить адреса ILS-серверов в Phone Dialer.
Дополнительные материалы Более подробную информацию о групповой IP-рассылке см. в книге: •
Thomas A. Maufer «Deploying IP Multicast in the Enterprise», 1998, Upper Saddle River, NJ: Prentice Hall PTR.
ЧАСТЬ
Другие протоколы
Часть 5 посвящена дополнительным протоколам в Microsoft Windows 2000, которые поддерживают сравнительно небольшие сети и обеспечивают взаимодействие между Windows 2000 и операционными системами, отличными от Windows.
В этой части NetBEUI DLC
659
643
ГЛАВА
16
NetBEUI
Windows 2000 по-прежнему поддерживает NetBEUI (NetBIOS Extended User Interface), обеспечивая обратную совместимость с унаследованными протоколами. NetBEUI в Windows 2000 поддерживает сетевые сеансы (логические соединения между компьютерами в сети) и к о м м у н и к а ц и о н н у ю связь обоих типов (ориентированную на логические соединения и не требующую таких соединений). В этой главе Обзор 644
Взаимодействие с другими операционными системами через NBF Архитектура NBF 646 Типы сетевой коммуникационной связи
645
648
Поддержка динамического выделения памяти 652 Поддержка клиентов удаленного доступа 652 Ограничения на число сеансов в NBF 652 Установление сеансов 653 Возможности маршрутизации на основе NBF Поддержка Plug and Play
656
656
Выявление и устранение проблем
656
См. также
•
О сетевой архитектуре Windows 2000 Server — приложение Б «Сетевая архитектура Windows 2000* в книге «Сети TCP/IP* из серии «Ресурсы Microsoft W i n dows 2000 Server». • О сетевой архитектуре Windows 2000 Professional — документацию в «Microsoft Windows 2000 Professional Resource Kit».
Обзор NetBEUI (NetBIOS Extended User Interface) — один из самых старых протоколов для сетей, состоящих из персоналыгых компьютеров. Он был разработан на основе интерфейса NetBIOS (Nelwork Basic Input/Output System) как компактный, эффективный протокол для применения в небольших локальных сетях, которые объеди-
ГЛАВА 16
NetBEUI
645
няют от 20 до 200 компьютеров и не требуют маршрутизации между подсетями. В настоящее время NetBEUI используется исключительно в малых, немаршрутизируемых сетях с компьютерами иод управлением самых разнообразных операционных систем, в том числе: Microsoft Windows NT Server 3.5 (и выше), Microsoft Windows NT Workstation 3.5 (и выше), Microsoft LAN Manager, Microsoft Windows for Workgroups, Microsoft Windows 3.1, Microsoft Windows 95. Microsoft Windows 98, Microsoft Windows NT 3.1, LAN Manager for UNIX, IBM PC LAN и LAN Server. NetBEUI в Windows 2000, называемый NBF (NetBIOS Frame), реализует спецификацию NetBEUI версии 3.0. NBF представляет собой более низкоуровневую реализацию протокола NetBEUI и может быть установлен на компьютер с Windows 2000. Он обеспечивает совместимость с существующими LAN-сетями, в которых используется NetBEUI, и с драйвером протокола NetBEUI из сетевых продуктов Microsoft предыдущих версий. Кроме того, NBF: •
использует TDI (Transport Driver Interface) из Windows 2000, позволяющий интерпретировать NetBIOS-команды; • использует NDIS (Network Driver Interface Specification) и.ч Windows 2000 с более совершенной поддержкой транспорта и полностью 32-разрядным интерфейсом;
• динамически выделяет память для обработки клиентских запросов; • поддерживает коммуникационное взаимодействие клиентов удаленного доступа с сервером удаленного доступа; • предоставляет коммуникационные сервисы (как ориентированные на логические соединения, так и не требующие логических соединений); • снимает ограничения на число одновременных NetBIOS-сеансов. Ниже поясняется несколько терминов, часто употребляемых в этой главе. • NetBIOS (Network Basic Input/Output System) — программное обеспечение, разработанное IBM. Предоставляет интерфейс между операционной системой, шиной ввода-вывода компьютера и сетью. Является стандартом de-facto. • NetBEUI (NetBIOS Extended User Interface) — один из первых сетевых протоколов для персональных компьютеров и интерфейс, разработанный IBM для своего LAN Manager Server. NetBEUI реализует протокол OSI LLC2 и поддерживает не более 254 сеансовых соединений. • NetBEUI 3.0 в Windows 2000. также известный как NBFP (NetBIOS Frames Protocol), является Microsoft-реализацией протокола IBM NetBEUI. Он снимает ограничение прежних версий NetBEUI на число одновременных сеансовых соединений с сервером и использует уровень Microsoft TDI как интерфейс к NetBIOS.
Взаимодействие с другими операционными системами через NBF NBF (NetBIOS Frame) обеспечивает совместимость с компьютерами под управлением устаревших операционных систем, например Microsoft LAN Manager, MS-Net и IBM LAN Server. NBF позволяет соединять рабочие станции LAN с серверными компьютерами, а также подключать удаленные клиенты (в том числе портативные компьютеры) к компьютерам с Windows 2000 Server.
646
ЧАСТЬ 5 Другие протоколы
NBF можно использовать с программами, которые реализуют самые разнообразные сервисы на основе следующих API-интерфейсов: • NetBIOS; •
именованных каналов;
• почтовых ящиков; • •
сетевого DDE; RFC (Remote Procedure Call) поверх NetBIOS;
•
RPC поверх именованных каналов.
NBF наиболее эффективен для подключения компьютеров к малым и средним сетям без маршрутизации. В отличие от TCP/IP (Transmission Control Protocol/ Internet Protocol) или IPX (Internetwork Packet Exchange) NBF не является маршрутизируемым протоколом, хотя поддерживает маршрутизацию источника Token Ring, доступную только в сетях IBM Token Ring. Кроме того, схема именования в NBF не поддерживает сегментацию, применяемую в большинстве крупных сетей.
Архитектура NBF NBF — транспортный драйвер, включающий следующие уровни. •
Протокол LLC (LLC 802.2). Соответствует канальному уровню сетевой модели OS1 (Open Systems Interconnection). Отвечает за адресацию, управление потоком кадров и обеспечение коммуникационной связи в средах, ориентированных на логические соединения, и в средах, не требующих таких соединений.
• Протокол NBFP (NetBIOS Frames Protocol). Соответствует транспортному уровню модели OSI. Отвечает за установление и завершение сеансов, мультиплексирование, сегментацию и восстановление сообщений, а также за передачу подтверждений. Взаимосвязь модели OSI с архитектурой NBF показана на рис. 16-1. Модель OSI 7. Прикладной уровень 6. Презентационный уровень 5. Сеансовый уровень
FDI 4. Транспортный уровень
NBFP
3. Сетевой уровень
2. Канальный уровень 1. Физический уровень
LLC NDIS
Рис. 16-1. Модель OSI и архитектура NBF
NBFP взаимодействует с TDI, который предоставляет стандартный интерфейс ко множеству драйверов транспортных протоколов, а компонент LLC подключается к компоненту NDIS, в свою очередь предоставляющему интерфейс к сетевому адап-
ГЛАВА 16
NetBEUI
647
теру. Поскольку NBF не является маршрутизируемым протоколом, в нем нет компонента, соответствующего сетевому уровню модели OSL Примечание В сетях Token Ring NetBEUI выполняет функции сетевого уровня, используя маршрутизацию источника IBM Token Ring, которая отвечает стандарту ШЕЕ 802.5 и соответствует физическому (не сетевому) уровню модели OSI.
Интерфейс TDI Программы, поддерживающие коммуникационную связь на основе NBFP, требуют наличия транспортного драйвера, предоставляющего интерфейс NetBIOS. Но драйверы транспортов в Windows 2000 вместо интерфейса NetBIOS предоставляют более гибкий интерфейс TDI (Transport Driver Interface), который не только поддерживает NBF, но и служит стандартным интерфейсом для таких протоколов, как IPX и TCP/IP. Рис. 16-2 иллюстрирует, как TDI предоставляет функциональность NBFP. Приложения NetBIOS I Интерфейс TDI
NBFP LLC
Рис. 16-2. TDI и NBF TDI в Windows 2000 предоставляет эмулятор NetBIOS, преобразующий NetBIOSкоманды в TDI-команды для поддержки приложений, рассчитанных па NBFP. NetBIOS-команды форматируются в NCB (Network Control Blocks). Когда программа, выполняемая в Windows 2000, создает NCB, NetBIOS-команда сначала обрабатывается драйвером NetBIOS (Netbios.sys). Netbios.sys преобразует NCB в соответствующую TDI-команду и посылает ее драйверу NetBEUI (Nbf.sys). Семантика TDI-вызовов эквивалентна семантике NetBIOS NCB, но оптимизирована для 32разрядного ядра. Примечание Унаследованные 16-разрядные Windows-приложения и транспортные клиенты MS-DOS посылают NCB непосредственно драйверу NetBEUI.
Интерфейс NDIS Транспортный драйвер NBF обрабатывает TDI-запросы как кадры, которые должны быть отправлены в сеть уровнем управления логическими каналами (LLC). LLC является уровнем NBF, который обменивается кадрами с удаленным компьютером в сети. LLC в NBF отвечает стандарту IEEE 802.2 и выполняет следующие функции: • установление соединений; • управление соединениями и их закрытие;
648
ЧАСТЬ 5
Другие протоколы
•
формирование последовательностей кадров и передачу подтверждений;
•
управление потоком кадров;
• коммуникационную связь обоих типов (ориентированную и не ориентированную на логические соединения). На уровне LLC NBF принимает и передаст пакеты нижележащим драйверам сетевого адаптера через интерфейс ND1S. Коммуникационное взаимодействие внутри уровня LLC базируется на точках доступа к сервисам, каналах и станциях сиязи. Станция свази (link station) - это логическая точка внутри точки доступа к сервису, позволяющая адаптеру устанавливать логическое соединение с другим адаптером. Каждая клиентская программа LLC идентифицирует себя, регистрируя уникальную точку доступа к сервису. Точка доступа к сервису (service access point) — это механизм, с помощью которого более высокий уровень может программно обращаться к конкретному сервису, реализованному более низким уровнем. Существуют общеизвестные точки доступа к сервисам, аналогичные общеизвестным портам TCP/IP. Поскольку NBF реализован на основе NetBIOS, он использует общеизвестную точку доступа к NetBIOSсервису (OxFO). Точка доступа к Net BIOS-сервису, другие точки доступа и их взаимосвязи с уровнем LLC показаны на рис. 16-3. LLCКЛйбнт А SAP 40
LLCклиент В
NBFP
SAP 28
SAP FO
LLC 802.2
NDIS
Сетевой адаптер Рис. 16-3. LLC-уровень NBF и NDIS-интсрфейс точек доступа к сервисам Когда клиентская программа посылает кадр в сеть через LLC, последний указывает в заголовке LLC-кадра точку доступа к сервису источника (source service access point, SSAP) и точку доступа к сервису адресата (destination service access point. DSAP).
Типы сетевой коммуникационной связи NBF поддерживает сетевую коммуникационную связь двух типов: ненадежную, не требующую логических соединений и надежную, ориентированную на логические соединения.
ГЛАВА 16
NetBEUI
649
Коммуникационная связь, не ориентированная на логические соединения В этом случае NBF передает сообщение заданное число раз (или один раз) и отвечает лишь за правильную передачу кадра в сетевую среду. Сообщение состоит из единственного кадра. SSAP, DSAP, адрес сетевого адаптера получателя — вот и все, что нужно знать при ненадежной коммуникационной связи, не ориентированной на логические соединения; подтверждения о приеме кадров не требуются. Примечание Коммуникационная связь, не ориентированная на логические соединения, не обязательно ненадежна. Однако NBF при использовании такой связи обеспечивает только ненадежную доставку. Если Вам нужна падежная коммуникационная связь, не требующая логических соединений, NBF можно настроить так, чтобы определенные команды повторно посылали некое количество кадров и тем самым давали получателю время па ответ. Число повторно посылаемых кадров зависит от значения параметра реестра NameQueryRetries. Интервал между отправкой каждого кадра определяется параметром реестра Name Query Timeout. Логические соединения не используются NetBIOS-командами, в частности связанными с: • •
объявлением и разрешением имен; передачей дейтаграмм.
Эти команды посылаются на уровень LLC как кадры Unnumbered Information (ненумерованная информация). Чтобы попять, как Windows 200Q использует параметры реестра, относящиеся к числу повторных попыток передачи и времени ожидания, рассмотрим, что происходит при регистрации NeiBIOS-имени компьютером с Windows 2000 и NBF. Windows 2000 посылает в сеть широковещательный кадр ADD_NAMF_QUERY. Остальные компьютеры, работающие с NBF, получают и обрабатывают это сообщение. Этот широковещательный кадр посылается столько раз, сколько задано i параметре AddName Query Retries, с интервалом, указанным в AddNameQueryTimeout. Благодаря этому остальные компьютеры в сети успеют уведомить запрашивающий компьютер, если такое имя уже зарегистрировано. Все параметры реестра, рассматриваемые в этой главе, находятся в разделе реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbf Внимание Не модифицируйте реестр самостоятельно (с помощью редактора реестра) — делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства зашиты, призванные не допускать ввода конфликтующих значений параметров, а также тех, которые могут снизить быстродействие системы или привести к ее краху. Прямое редактирование реестра может повлечь за собой непредсказуемые последствия, и Вам придется переустанавливать Windows 2000. Для настройки и конфигурирования Windows 2000 по возможности используйте Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft).
650
ЧАСТЬ 5
Другие протоколы
Коммуникационная связь, ориентированная на логические соединения В этом случае NBF передает кадр от источника получателю по сформированному между ними каналу. Кадр состоит из SSAP, DSAP и адреса сетевого адаптера получателя. Кадр может быть отправлен: •
на адрес конкретного сетевого адаптера (тогда кадр принимается единственным компьютером, зарегистрировавшим DSAP);
• на широковещательный NetBIOS-адрес, по которому этот кадр принимается всеми компьютерами, зарегистрировавшими широковещательную DSAP. Надежная коммуникационная связь с ориентацией на логические соединения (также называемая сеансом, или операцией Туре 2) приводит к большим издержкам по сравнению с коммуникационной связью, не требующей таких соединений. Например, адресат должен подтверждать получение каждого кадра. Ответственность за доставку всего сообщения от источника адресату в течение приемлемого времени возлагается на драйвер транспортного протокола. Сообщение, длина которого превышает максимально допустимый размер кадров в данной сетевой среде, должно предварительно разбиваться на кадры меньшего размера на передающем компьютере и корректно восстанавливаться на принимающем. Ниже на примере команды net use описывается процесс установления сеанса при коммуникационной связи, ориентированной на логические соединения. 1. Когда Вы вводите команду net use для подключения к какому-либо общему ресурсу. NBF должен сначала найти сервер, передав кадры Unnumbered Information, а затем инициализировать канал связи. Инициализацию выполняет редиректор, подключаясь к драйверам NBF через интерфейс TDI. 2. NBF генерирует NetBIOS-кадр FincfNarne. 3. После того как сервер найден, посылаются кадры Class-II с параметрами, значения которых соответствуют стандарту 802.2 (это необходимо для согласования параметров устанавливаемого сеанса). 4. Клиент посылает кадр Set Asynchronous Balance Mode Extended, а сервер возвращает кадр Unnumbered Acknowledgment. 5. Клиент посылает кадр Receive Ready (RR), уведомляя сервер о своей готовности к приему кадров Informational (1), номера последовательностей которых начинаются с 0. Сервер подтверждает прием этого кадра. 6. После того как сеанс уровня LLC установлен, клиент и сервер обмениваются дополнительной информацией уровня NetBEUI. Клиент посылает кадр Session Initialize, а сервер отвечает кадром Session Confirm. С этого момента сеанс уровня NetBEUI считается созданным, и становится возможной передача SMB-кадров (Server Message Blocks) прикладного уровня. Для надежной доставки I-кадры последовательно нумеруются. Это позволяет принимающей стороне обнаруживать потерянные кадры и восстанавливать правильную последовательность полученных кадров. Кроме того, для большей эффективности NBF использует два метода: алгоритм адаптивной подстройки окон (adaptive sliding windows) и таймеры соединения (link timers).
ГЛАВА 16
NetBEUI
651
Адаптивная подстройка окон Алгоритм адаптивной подстройки окон повышает производительность, в то же время уменьшая нагрузку на сеть и увеличивая гибкость в управлении потоком данных. Этот алгоритм позволяет системе с Windows 2000 и NBF динамически изменять пороговое число LLC-кадров, после передачи которых запрашивается подтверждение об их приеме, Если бы отправитель дожидался подтверждения (АСК) каждого переданного им кадра, он работал бы крайне неэффективно. В этом случае переданный кадр должен дойти до принимающей стороны, а подтверждение о его приеме должно быть доставлено отправителю до того, как тот сможет передать следующий кадр. Число кадров, передаваемое отправителем до перехода в ожидание подтверждения об их приеме, называется окном передачи (send window), а число кадров, принимаемое получателем до посылки подтверждения, — окном приема (receive window). Если NBF обнаруживает, что удаленный компьютер работает с версией IBM NetBEUI, не поддерживающей опрос (он выполняется передачей кадра, позволяющего выяснить состояние другой стороны), то устанавливает размер окна приема в соответствии с параметром реестра MaxIncomingFrames. Его значение по умолчанию равно 2 и не изменяется динамически. Если Вы хотите модифицировать его, то должны сделать это вручную с помощью Registry Editor (Редактор реестра). Если же опрос поддерживается, алгоритм адаптивной подстройки окон старается определить оптимальный размер окна передачи в данной сетевой среде. В идеале это окно должно быть достаточно большим, чтобы обеспечивать максимальную пропускную способность. Однако, если оно становится слишком большим, принимающая сторона может не успевать обрабатывать входящие кадры и часть из них отбрасывать. Тогда отправителю придется повторно передавать отброшенные кадры. А это может привести к заметному увеличению трафика в сети.
Таймеры соединения NBF использует три таймера, помогающие регулировать сетевой трафик: таймер ответа (Т1), таймер подтверждения (Т2) и таймер неактивности (Ti). Эти таймеры контролируются параметрами реестра DefaultTlTimeout, DefaultT2Timeout и DefaultTiTimeout. Таймер ответа определяет интервал, по истечении которого отправитель считает, что I-кадр потерян. Если этот интервал истекает и ответ не приходит, NBF посылает кадр RR и удваивает значение для таймера ответа (Т1). Если прием кадра RR не подтверждается после определенного числа повторных попыток (это число задается параметром LLCRetries), связь разрывается. Для таймера подтверждения (Т2) по умолчанию присваивается значение, равное 150 мс. Во избежание задержек на медленных каналах связи и других проблем NBF оптимизирован так, что в последнем кадре от отправителя устанавливается битовый флаг опроса (Poll). Это заставляет получателя немедленно передать АСК. Таймер неактивности (Ti) используется для проверки соединения. Значение Ti по умолчанию — 30 секунд. Если Ti срабатывает и соединение остается неактивным, NBF посылает I-кадр для опроса. Если в ответ приходит АСК, значит, соединение еще не потеряно. Примечание
Т2 меньше или равен Ti, а тот меньше или равен Ti.
652
ЧАСТЬ 5
Другие протоколы
Т1 настраивается динамически для каждого канала связи в зависимости от его пропускной способности и степени загруженности. Значение Т1, заданное в реестре, используется как начальное и может быть изменено. Например, на медленных каналах связи значение Т1 увеличивается. Но значения Т2 и Ti являются статическими, и NBF не изменяет их самостоятельно.
Поддержка динамического выделения памяти NBF в Windows 2000 выделяет память, нужную для обработки запросов, выданных сеансовыми клиентами. Это означает, что NBF использует память только по мере необходимости. Например, на компьютере с Windows 2000 в отсутствие активных сетевых соединений стек протоколов NBF резервирует лишь очень малый объем памяти. Установка NBF на компьютере с Windows 2000 не требует дополнительной настройки числа сеансов, пакетов или буферов.
Поддержка клиентов удаленного доступа NBF позволяет удаленным компьютерам подключаться к серверу Windows 2000, па котором установлена служба маршрутизации и удаленного доступа. Поскольку NBF динамически выделяет память и настраивается автоматически, вносить какие-либо изменения в конфигурацию сервера не требуется. Если Вы хотите ограничить число повторных запросов, модифицируйте параметр реестра WanNameQueryRetries с помощью Registry Editor. (Этот параметр является WAN-эквивалентом параметра NameQueryRetries.)
Ограничения на число сеансов в NBF В предыдущих версиях NetBIOS сеансы NetBIOS идентифицировались однобайтовым номером (0-255). Номера сеансов присваивались по компьютерам. Поэтому компьютер с NetBEUI прежних версий поддерживал до 254 сетевых соединений (номера 0 и 255 резервировались самой NetBIOS). NBF устраняет этот барьер, используя комбинацию двух матриц: одна из них поддерживается NBF, другая — NetBIOS. NBF работает с 32-битными TDI-описателями, (TDI handles) которые состоят из номера сеанса и адреса сетевого адаптера удаленного компьютера (рис. 16-4). Матрица состоит из LSN (Local Session Numbers) со значениями от 0 до 255 и адресов сетевых адаптеров тех компьютеров, с которыми установлены сеансы. На пересечении строк и колонок такой таблицы Вы получаете значения TDI-описателей. Подробнее о LSN см. раздел «Установление сеансов» далее в этой главе. Примечание Описание матриц приведено в упрощенном виде. Алгоритм записи значений в матрицы и их точное содержимое здесь не рассматриваются. При использовании NBF сервер Windows 2000 с единственным сетевым адаптером может одновременно поддерживать сеансы более чем с 1000 клиентами. Хотя NBF устраняет лимит в 254 сеанса, свойственный предыдущим версиям NetBIOS, это ограничение все же остается в силе при подключении компьютера с NBE к удаленному клиенту с групповым NetBIOS-именем.
ГЛАВА 16
NetBEUI
653
Идентификатор процесса
i .п TDI-описатель Интерфейс TDI
TDI-описатель
Рис. 16-4. Нумерация сеансов на основе двух матриц Рассмотрим три возможных сценария. Клиент подключается к компьютеру с Windows 2000 и NBE NBF анализирует входящий кадр, чтобы определить адрес сетевого адаптера удаленного клиента и назначить этому адаптеру помер сеанса. NBF подключается к удаленному клиенту с уникальным NetBIOS-именем. XBF посылает кадр FindName. Если ответ приходит от удаленного клиента, значит, у него уникальное имя. Тогда NBF может назначить его сетевому адаптеру номер сеанса, потому что такое имя есть только у этого удаленного клиента. NBF подключается к удаленному клиенту с групповым NetBIOS-именем. NBF посылает кадр FindName. Если ответ приходит от группы, NBF не может определить, какой адаптер принадлежит группе, ответившей на запрос. Тогда NBF должен назначить глобальный номер сеанса — так же. как это делает NetBEUI для всех соединений. Таким образом, в NBF пет ограничений па число одновременных сеансов, если только он не подключается к удаленным клиентам с групповыми именами. В последнем случае действуют прежние ограничения NetBEUI.
Установление сеансов Когда два компьютера устанавливают сеанс с применением NBF, инициирующий компьютер посылает кадр с LSN, равным 0. Этот LSN зарезервирован для кадра FindName в кадре Name-Query. Обмен кадрами при создании сеанса показан на рис. 16-5. 2. Адрес источника =0286DO-129C3D Ответ на NameQuery
1. Адрес источника = 028600-11F784 NameQuery (LSN = 5, имя - REMOTE)
Рис. 16-5. Широковещательная передача кадров NameQuery
654
ЧАСТЬ 5 Другие протоколы
Все компьютеры, получив этот кадр, проверяют, есть ли соответствующее имя в их дереве консоли и незавершенная (pending) команда NCB LISTEN, относящаяся к этому имени. Если такая команда присутствует, компьютер назначает себе новый LSN, и завершает команду NCB LISTEN, добавляя этот LSN в кадр ответа, который теперь содержит только LSN, задействованный на данном компьютере. LSNномера на разных компьютерах могут отличаться, но каждый компьютер всегда использует один и тот же LSN для конкретного сеанса. Этот номер назначается, когда какая-нибудь программа выдает NCB CALL. Хотя каждый компьютер знает LSN другого компьютера, эта информация игнорируется. Для двух сторон коммуникационной связи гораздо важнее информация об адресах сетевых адаптеров, содержащаяся в кадрах. В процессе обмена кадрами каждая сторона получает адрес другой стороны. Поэтому последующие кадры направляются непосредственно адресату. Примечание Описанный процесс относится только к установлению NBF-соединений. Соединения NetBIOS поверх TCP/IP (NetBT) устанавливаются по-другому. О NetBIOS поверх TCP/IP см, главу 1 «Введение в TCP/IP» и главу 2 «Реализация TCP/IP в Windows 2000» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server». Допустим, компьютер под управлением Windows 2000 Server и NBF назначает сеансу между собой и компьютером А, а также одновременному сеансу с компьютером В один и тот же номер (1). Компьютер с Windows 2000 Server различает эти сеансы благодаря тому, что они идентифицируются не только по номеру сеанса, но и по адресу сетевого адаптера, который является частью TDI-описателя. Когда компьютер с Windows 2000 Server посылает сеансовый кадр либо компьютеру А, либо компьютеру В, он направляет его прямо на адрес нужного сетевого адаптера. Поэтому компьютер А не получает кадры, адресованные компьютеру В, и наоборот. Однако, если Windows 2000 Server устанавливает еще один сеанс с компьютером A, NBF должен присвоить второму сеансу номер, отличный от 1. Кадр NameQuery от Windows 2000 содержит LSN, сопоставленный с TDI-описателем в ответ на команду NCB CALL или NCB LISTEN. В случае NCB CALL этот кадр не является широковещательным и адресуется непосредственно удаленному компьютеру. Процесс, выдавший команду NCB CALL или NCB LISTEN, получает LSN не из матрицы NBF. Дело в том, что NBF может установить соединения с несколькими удаленными компьютерами под одним и тем же LSN, например 5. Поэтому конкретная система с Windows 2000 должна вернуть процессу LSN, однозначно определяющий его сеанс с данной системой. Как уже говорилось, по TDI-описателю NBF определяет, на какой LSN и сетевой адрес следует передавать кадры, а в распоряжении каждого процесса свой набор LSN. Поэтому для формирования TDI-описателя из идентификатора процесса и LSN между исходным процессом и TDI-интерфейсом NBF размещается еще один компонент — Netbios.sys. Рис. 16-6 иллюстрирует команду NCB CALL, обрабатываемую с применением матриц NetBIOS и NBF. Матрица, поддерживаемая Netbios.sys, предоставляет по 254
ГЛАВА 16
NetBEUI
655
LSN на каждый номер LAN-адаптера для каждого процесса. В Windows 2000 номер LAN-адаптера идентифицирует уникальную привязку драйвера протокола к драйверу сетевого адаптера. У каждого процесса может быть до 254 сеансов на каждый номер LAN-адаптера (а не всего 254 сеанса). Идентификатор процесса = 122
Пользовательский режим Режим ядра
Идентификатор процесса
LSN TDf-описатель
I I
LSN TDI-описатвль NDIS
Рис. 16-6. NCB CALL, обрабатываемая с применением матриц NetBIOS и NBF Netbios.sys формирует матрицу из строк LSN и колонок с: идентификаторами процессов; в ячейках на пересечении строк и колонок содержатся TDI-описатели. Процесс получает LSN именно из этой таблицы. Чтобы лучше понять, как Netbios.sys использует эту матрицу, представьте, что некий процесс устанавливает сеанс с удаленным компьютером. Прежде чем этот процесс сможет выдать команду NCB CALL, он должен передать кадр Reset NCB, который уведомляет Netbios.sys о необходимости выделить место в ее таблице TDIописателей и выполнить ряд других операций. Получив ответ на кадр Reset NCB, процесс выдает NCB CALL для установления соединения с указанным удаленным компьютером. Этот КСВ (Network Control Block) передается нижележащему драйверу Netbios.sys, а тот открывает новый TDI-описатель для NBF и посылает NBF соответствующую команду. NBF выдает первый NameQuery с LSN 0, чтобы найти удаленный компьютер. Как только удаленный компьютер возвращает ответ, из него извлекается адрес сетевого адаптера и в таблице NBF создается новая колонка. Второй NaineQuery с какимлибо LSN посылается удаленному компьютеру напрямую. Когда на этот кадр ЕФИходит ответ, NBF возвращает драйверу Netbios.sys код успешного завершения TD1вызова. Наконец, Netbios.sys записывает LSN из своей таблицы в NCB и возвращает этот КСВ процессу.
656
ЧАСТЬ 5
Другие протоколы
Возможности маршрутизации на основе NBF Территориально распределенные сети вроде WAN требуют поддержки маршрутизации, но в малых и средних локальных сетях такая поддержка в основном не требуется, и поэтому Вы можете обойтись без установки какого-либо протокола маршрутизации. ХВЕ не является маршрутизируемым протоколом. Применяемая им схема именования Tie позволяет различать компьютеры, которые находятся в разных сетях, подключенных друг к другу. NBF поддерживает лишь простейший вид маршрутизации — маршрутизацию источника Token Ring, которую можно реализовать только в сетях Token Ring, использующих мосты. Маршрутизация источника Token Ring активизируется так: когда NBF посылает широковещательный кадр NameQuery u локальную Token Ring и не получает ответ в течение определенного периода, он использует в кадре поля, относящиеся к маршрутизации источника, что заставляет мосты, отвечающие за такую маршрутизацию, принять и обработать этот кадр. Мост вставляет в кадр дополнительную информации* о маршрутах и передает его во все кольца, к которым подключен данный мост. Когда кадр запроса имени попадает на нужный компьютер, последний генерирует ответный кадр со своим пшеном и, используя информацию о маршрутах из запроса, напрямую передает напросившему компьютеру. Тот кэширует информацию о маршрутах и передает последующие кадры с использованием адресов из кэша.
Поддержка Plug and Play NBF отвечает стандарту Plug and Play и поддерживает все сетевые адаптеры, соответствующие текущим спецификациям ШЕЕ. Подробнее о сетевой поддержке Plug and Play см. приложение Б «Сетевая архитектура Windows 2000» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server».
Выявление и устранение проблем Здесь обсуждаются проблемы, с которыми Вы можете столкнуться при использовании NetBEUI (или NetBIOS Frame) на компьютере с Windows 2000. Тонкая настройка NetBEUI через реестр При установке NetBEUI в Windows 2000 никакой настройки не требуется, так как NetBEUI является самонастраивающимся компонентом. Но при желании Вы можете изменить значения его параметров в разделе реестра: HKEY_IjOCAL_MACHINE\SYSTEM\Services\NBF\Parameters Внимание Не модифицируйте реестр самостоятельно (с помощью редактора реестра) — делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства зашиты, призванные не допускать ввода конфликтующих значений параметров, а также тех, которые могут снизить быстродействие системы или привести к ее краху. Прямое редактирование реестра может повлечь за собой непредсказуемые последствия, и
ГЛАВА 16
NetBEUI
657
Вам придется переустанавливать Windows 2000. Для настройки и конфигурирования Windows 2000 по возможности используйте Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft). Внесение изменений в привязки NetBEUI В привязки NetBEUI можно внести следующие модификации: • создать привязку; • удалить привязку; • изменить порядок (приоритет) привязок. ^ Чтобы изменить приоритет привязок NetBEUI: 1. Откройте в меню Start (Пуск) подменю Settings (Настройка) и выберите команду Control Panel (Панель управления). 2. Дважды щелкните значок Network and Dial-up Connections (Сеть и удаленный доступ к сети). 3. Выберите из меню Advanced (Дополнительно) команду Advanced Settings (Дополнительные параметры). 4. В появившемся диалоговом окне выберите Local Area Connection (Подключение по локальной сети). 5. В диалоговом окне Bindings for Local Area Connections (Привязка для Подключение по локальной сети)* выберите нужную привязку. 6. Измените позицию этой привязки в списке, используя подходящую кнопку со стрелкой. Попытка привязки NetBEUI к нескольким сетевым адаптерам Не привязывайте NetBEUI к нескольким адаптерам в одной физической сети или в сегментах Ethernet, соединенных мостами, иначе каждый адаптер попытается зарегистрировать в сети одно и то же NetBIOS-имя и вызовет конфликт имен. Это скорее всего приведет к отключению адаптеров, и Вы потеряете возможность сетевых соединений через NetBEUI. Маршрутизация источника не поддерживается в FDDI-сети Маршрутизация источника поддерживается только в сетях Token Ring. FDDI-сеть (Fiber Data Distributed Interface) не может использовать NBF для маршрутизации источника. Нет кадров Session Alive NBF не проверяет присутствие удаленного клиента в сеансе с помощью NetBIOSкадров Session Alive; вместо этого он посылает LLC-кадры опроса, выполняющие ту же функцию. Однако NBF отвечает на кадры Session Alive, так что ожидать проблем с взаимодействием с другими реализациями NetBEUI не следует.
* В русской версии Windows 2000 Server это диалоговое окно называется именно так. - Прим, переи, 12 Зак. ЗЛ43
658
ЧАСТЬ 5
Другие протоколы
Применение NetBEUI из Windows 2000 в сетях IBM LAN Server Как правило, NBF не использует окно приема, пока не обнаружит, что удаленный компьютер-отправитель работает с одной из версий IBM NetBEUI, не поддерживающих опрос через сеть; к такой версии относится IBM LAN Server. NBF инициирует соединение с удаленным компьютером так же, как и IBM NetBEUI, но NBF проверяет в принимаемых кадрах битовый флаг опроса. Если в принятом кадре этот флаг не установлен. Windows 2000 ждет срабатывания таймера Т2 и только после этого посылает кадр АСК. Подробнее о Т2 см. раздел «Коммуникационная связь, ориентированная на логические соединения» ранее в этой главе. Примечание Если в принятом кадре битовый флаг опроса установлен, NBF игнорирует окно приема и немедленно передает АСК. Например, компьютер с IBM LAN Server мог задать окно передачи равным 1. Тогда параметр реестра MaxIncomingFrames следует вручную уменьшить до 1 (по умолчанию он равен 2). Иначе этому компьютеру придется ждать АСК от компьютера с Windows 2000, который передаст этот кадр, только когда сработает таймер Т2. Примечание Компьютер с Windows 2000, использующий окно приема с размером MaxIncomingFrames, не всегда посылает ЛСК после приема MaxIncomingFrames пакетов. Это связано с тем, что NBF, прежде чем передавать АСК, дожидается приема NDIS-пакета ProtocolReceiveComplete. Однако, когда компьютер с Windows 2000 получает кадры Poll, он передает АСК немедленно. Обозреватель NetBEUI не видит ТСР/1Р-клиенты Просмотр компьютеров в сети с компьютера под управлением Windows 2000 осуществляется отдельно по каждому протоколу. Иначе говоря, для каждого протокола выбирается свой главный обозреватель (master browser). Компьютеры, использующие только NetBEUI, регистрируются на главном обозревателе, на котором работает протокол NetBEUI. Именно от него эти компьютеры получают список просмотра. А поскольку компьютеры, использующие только TCP/IP, регистрируются на главном обозревателе, работающем с TCP/IP, они не попадают в список просмотра, поддерживаемый главным обозревателем, работающим с NetBEUI. Подробнее о просмотре сети см. приложение И «Служба обозревателя в Windows 2000» в книге «Сети TCP/IP» из серии «Ресурсы Microsoft Windows 2000 Server».
ГЛАВА
17
DLC
Протокол DLC (Data Link Control), реализованный в Windows 2000, позволяет подключаться к мэйнфреймам IBM и к устройствам печати, соединенным напрямую с сетью. DLC — немаршрутизируемый протокол, применяемый только на компьютерах, которым нужен доступ к мэйнфреймам IBM и к принтерам с прямым подключением к сети; он не конфигурируется как основной протокол для коммуникационной связи между рабочими станциями. В Windows 2000 также входит драйвер устройства для интерфейса DLC. В этой главе Обзор 659 Установка протокола DLC 660 Параметры драйвера DLC в реестре 661 Коммуникационное взаимодействие со SNA-хостами через DLC Подключение к устройствам печати через DLC 663
662
См.также • Подробнее о DLC и сетевой печати — книгу «Сопровождение сервера» из серии «Ресурсы Microsoft Windows 2000 Server». • Подробнее о взаимодействии с аппаратно-программным обеспечением IBM главу 10 «Взаимодействие с хост-системами IBM* в этой книге.
Обзор Драйвер протокола DLC поставляется с Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows NT 4.0 и Windows 2000. Он позволяет взаимодействовать с компьютерами, на которых работает стек протоколов DLC (например, с мэйнфреймами IBM), или с сетевой периферией вроде устройств печати, напрямую яодключеных к сети через собственные сетевые адаптеры. Драйвер протокола ULC обеспечивает доступ к сервисам IEEE 802.2 классов I и П. Он также предоставляет интерфейс для обмена кадрами 802.3 и другими Ethernet-кадрами, в частности неструктурированными (raw) кадрами 802.5. Этот интерфейс состоит из DLL и драйвера устройства. Его сервисы доступны при наличии сетевых плат с NDIS-драйверами. DLC в Windows 2000 работает с драйве-
660
ЧАСТЬ 5
Другие протоколы
рами либо Token Ring, либо Ethernet MAC (Media Access Control); в случае привязки к Ethernet MAC также может передавать и принимать кадры формата DIX (Digital Intel Xerox). DLC в Windows 2000 содержит ядро конечных состояний (finite state machine) LLC 802.2 (Logical Link Control), используемое при передаче и приеме кадров типа 2 в среде, ориентированной на логические соединения. DLC позволяет обмениваться и кадрами типа 1 в среде, не ориентированной на логические соединения, например кадрами Unnumbered Information. Кадры типов 1 и 2 можно передавать и принимать одновременно. Интерфейс DLC доступен из 32-раярядпых приложений Windows 2000, а также из 16-разрядных программ MS-DOS и Windows. 32-разрядпый интерфейс в основном соответствует интерфейсу ССВ2 (Command Control Block), в котором сегментированные 16-битные указатели заменены линейными 32-битными. А 16-разрядный интерфейс соответствует интерфейсу ССВ1. В отличие от других транспортных протоколов DLC не поддерживает TDI (Transport Driver Interface). Из-за этого DLC не годится для коммуникационной связи с клиентскими приложениями TDI, например с редиректором и службой сервера Windows 2000. Поскольку редиректор не может использовать DLC, этот протокол не применяется при обычных сеансовых соединениях между компьютерами под управлением Windows 2000.
Установка протокола DLC Протокол DLC устанавливается отдельно — по окончании работы программы Windows 2000 Setup (Установка Windows 2000). ^ Чтобы установить DLC: 1. Откройте в меню Start (Пуск) подменю Settings (Настройка) и выберите команду Control Panel (Панель управления). 2. Дважды щелкните значок Network and Dial-up Connections (Сеть и удаленный доступ к сети). 3. Щелкните правой кнопкой мыши Local Area Connection (Подключение по локальной сети) и выберите команду Properties (Свойства). 4. Щелкните кнопку Add (Установить). 5.
Выберите Protocols (Протокол) и щелкните кнопку Add (Добавить).
6. Выберите DLC Protocols (Протокол DLC) и щелкните кнопку ОК.
Настройка сетевых привязок Сетевые привязки (network bindings) — это связи между сетевыми платами, протоколами и службами. Вы можете внести следующие изменения в сетевые привязки для DLC: • •
создать или удалить привязку; изменить порядок (приоритет) привязок.
Порядок привязок очень важен для DLC, так как в его интерфейсе адаптер определяется по номеру (обычно 0 или 1), хотя DLC в Windows 2000 поддерживает до 16
ГЛАВА 17
DLC
661
физических адаптеров одновременно. Номер соответствует индексу адаптера в разделе привязок DLC. Если на компьютере установлен только один сетевой адаптер. DI-C- приложения ссылаются на этот адаптер по номеру 0, и нет никакой необходимости что-либо менять в привязках DLC. Если же на компьютере установлено более одного сетевого адаптера, Вы можете модифицировать привязки. ^ Чтобы изменить приоритет привязок DLC: 1. Откройте в меню Start (Пуск) подменю Settings (Настройка) и выберите команду Control Panel (Панель управления). 2. Дважды щелкните значок Network and Dial-up Connections (Сеть и удаленный доступ к сети). 3. Выберите из меню Advanced (Дополнительно) команду Advanced Settings (Дополнительные параметры). 4. В появившемся диалоговом окне выберите Local Area Connection (Подключение по локальной сети). 5. В диалоговом окне Bindings for Local Area Connections (Привязка для Подключение по локальной сети)* выберите нужную привязку. 6. Измените позицию этой привязки в списке, используя подходящую кнопку со стрелкой,
Параметры драйвера DLC в реестре При первом открытии адаптера драйвер протокола DEC записывает в реестр (в раздел для этого адаптера) несколько параметров со значениями по умолчанию. Эти параметры управляют таймерами DLC, а также тем, следует ли использовать DIXкадры по Ether net- канал у и надо ли переставлять (swap) биты адреса назначения при переходе кадра через мост, переставляющий адреса назначения. При коммуникационной связи по DLC применяется три таймера: • Т1 — таймер ответа; • Т2 — таймер подтверждения; • TJ — таймер неактивиости. У каждого таймера два параметра: T.rTickOne и XrTickTwo, где вместо х следует подставить «1», «2» или «i». Все параметры DLC для конкретного адаптера содержатся в разделе реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Если Вы модифицируете параметр, связанный с таймером, изменения вступают в силу при следующем открытии адаптера.
* В русской версии Windows 2000 Server это диалоговое окно называется именно так. — Прим, перев.
662
ЧАСТЬ 5
Другие протоколы
Коммуникационное взаимодействие со SNA-хостами через DLC Основное предназначение протокола DLC — соединение персональных компьютеров со SNA-хостами (Systems Network Architecture) вроде мэйнфреймов IBM или систем AS/400. SNA предоставляет функциональность, эквивалентную сетевому, транспортному, сеансовому и презентационному уровням эталонной модели OSI. Эта функциональность несколько отличается от той, которая предусматривается на каждом уровне модели OSI, но уровень DLC (управление каналами) и канальный уровень OSI почти идентичны по своей функциональности. Кроме того, поддерживается программный интерфейс для доступа к уровню DLC. Этот интерфейс описан в стандарте IEEE 802.2. Примечание DLC недостаточно надежен для использования в многопоточных программах. Сравнение моделей. SNA и OSI представлено на рис. 17-1. Модель SNA
Модель OSI
Функциональное управление
7. Прикладной уровень
Управление потокам данных
6. Презентационный уровень
Управление передачей Управление коммуникационным, путем Управление каналами
\ \
5. Сеансовый уровень
4. Транспортный уревамъ !
-
3, Сетевой уровень 2, Канальной уровень 1. Физический уровень
Рис. 17-1. Сравнение моделей SNA и OSI Microsoft SNA Server взаимодействует с мэйнфреймами, используя драйвер устройства протокола DLC.
Изменение локально управляемого адреса При использовании DLC может понадобиться изменить адрес сетевого адаптера. Например, некоторые конфигурации программного обеспечения мэйнфреймов требуют, чтобы сетевые адреса устройств соответствовали определенному формату. Адрес сетевого адаптера модифицируется с помощью редактора реестра (Regcdt32.exe). Ниже приведена процедура изменения адреса для адаптеров IBM Token Ring. Но сначала проверьте в документации на свой сетевой адаптер, можно ли переопределить его адрес.
ГЛАВА 17
DLC
663
Внимание Не модифицируйте реестр самостоятельно (с помощью редактора реестра) — делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также тех, которые могут снизить быстродействие системы или привести к ее краху. Прямое редактирование реестра может повлечь за собой непредсказуемые последствия, и Вам придется переустанавливать Windows 2000. Для настройки и конфигурирования Windows 2000 по возможности используйте Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft). ^ Чтобы изменить адрес платы адаптера: 1. Выберите из меню Start (Пуск) команду Run (Выполнить). 2. Введите команду: regedt32 3. Щелкните кнопку ОК. 4. После запуска редактора реестра выберите раздел: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\ibmTOKMC01 5. Выберите из меню Edit (Правка) команду Add Value (Добавить параметр). 6. Введите в поле Value (Параметр) сетевой адрес, выберите тип данных REG_SZ и щелкните кнопку ОК. 7. Введите 12-разрядный локально управляемый адрес (Locally Administered Address, LAA), необходимый для коммуникационного взаимодействия с мэйнфреймом. Если Вы не знаете этот адрес, обратитесь к администратору сети. 8. Закройте редактор реестра и перезагрузите компьютер, чтобы изменения вступили в силу. 9. Теперь в командной строке введите команду net config rdr, которая сообщает активный МАС-адрес. Если он совпадает с LAA, заданным через реестр, значит, изменения вступили в силу. Подробнее о редакторах реестра см. справочную систему Windows 2000.
Подключение к устройствам печати через DLC DLC также позволяет подключаться к сетевым принтерам, напрямую соединенным с сетью. Примечание DLC не применяется для соединения с принтерами, подключенными к рабочим станциям или серверам через параллельные или последовательные порты. Для подключения к принтеру Hewlett-Packard и его конфигурирования нужно сначала установить монитор Hewlett-Packard Network Port на сервер печати под управлением Windows 2000. После этого с помощью Add Printer Wizard (Мастер установки принтеров) можно установить собственно Hewlett-Packard Network Port для настройки устройства печати.
664
ЧАСТЬ 5 Другие протоколы
Перед запуском Add Printer Wizard: •
включите самодиагностику принтера Hewlett-Packard, чтобы получить в распечатке адрес его сетевого адаптера (уникальное 12-байтовое число, заданное изготовителем сетевого адаптера);
• выберите логическое имя принтера (оно используется для идентификации принтера и сопоставляется с адресом его сетевого адаптера). ^- Чтобы настроить принтер Hewlett-Packard с прямым подключением к сети: 1. Откройте в меню Start (Пуск) подменю Settings (Настройка) и выберите команду Printers (Принтеры). 2. Дважды щелкните значок Add Printer (Установка принтера). 3. В окне Add Printer Wizard (Мастер установки принтеров) щелкните кнопку Next (Далее). 4. Выберите переключатель Network Printer (Сетевой принтер) и щелкните кнопку Next (Далее), 5. Выберите сеть, в которую должен быть добавлен данный принтер, и введите его имя. 6. Щелкните кнопку Finish (Готово). Примечание Перед настройкой сетевого принтера производства Hewlett-Packard или другого изготовителя, пожалуйста, внимательно прочитайте прилагаемое к нему руководство по установке. Дополнительную информацию о настройке принтеров см. в справочной системе Windows 2000.
Дополнительные материалы Более подробную информацию о DLC см. в документации: •
IBM «IBM Local Area Network Technical Reference (IBM part number SC303383)*-, Armonk, NY.
ЧАСТЬ
6
Приложения
Здесь приводятся детальные сведения о концепциях взаимодействия с другими платформами. Дополнительная техническая информация, приведенная в этой части, будет полезна администраторам сетей при устранении проолем с взаимодействием с хост-системами IBM и с UNIX. Кроме того, описываются сценарии установки Windows 2000 в корпоративных сетях.
В этой части Концепции взаимодействия с IBM SNA
666
Концепции взаимодействия с UNIX 690 Windows 2000 Resource Kit Deployment Lab
694
П Р И Л О Ж Е Н И Е
А
Концепции взаимодействия с IBM SNA
Решение Microsoft для интеграции с хост-системами IBM — Microsoft SNA Server. Для эффективного использования SNA Server Вы должны понимать, как работают сетевые среды, содержащие мэйнфреймы IBM и системы AS/400. IBM SKA (Systems Network Architecture) и APPN (Advanced Peer-to-Peer Networking) определяют протоколы, применяемые в традиционных сетях IBM. SNA Server поддерживает эти сетевые протоколы IBM, а также дополнительные технологии и стандарты, которые обеспечивают взаимодействие сетей на основе Windows 2000 с приложениями, базами данных и системами управления IBM. В этом приложении Интеграция с хост-системами IBM Microsoft SNA Server 667
667
Архитектура IBM SNA 668 Иерархические SNA-сети 669 APPN 677 Развитие SNA 682 Стандарты приложений хост-систем 683 Стандарты баз данных на хост-системах 684 Обработка транзакций 685 Система управления сетью IBM NetView
687
См. также • Подробнее о SNA Server — главу 10 «Взаимодействие с хост-системами IBM» в этой книге.
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
667
Интеграция с хост-системами IBM Во многих крупных организациях бизнес-приложения работают на специализированных мэйнфреймах IBM, компьютерных системах среднего класса или на системах AS/400. Поэтому сетевая архитектура хост-систем IBM — SNA (Systems Network Architecture) — и в наши дни остается одной из наиболее распространенных. Для использования информации, накопленной на хост-системах IBM, архитекторы информационных систем должны были найти способы бесшовной интеграции сетей и интрасетей на основе Windows 2000 с хост-системами SNA и их данжлми, приложениями и сетевыми сервисами,
Microsoft SNA Server SNA Server — это приложение Microsoft BackOffice®, выполняемое в операционной системе Microsoft Windows 2000 Server. SNA Server представляет собой комплексное решение для интеграции сетей и интрасетей на основе Windows 2000 с мэйнфреймами и системами AS/400, использующими IBM SNA или TCP/IP. Клиенты подключаются к SNA Server по стандартным сетевым протоколам вроде TCP/IP, IPX/SPX, NetBEUI, Banyan VINES IP и AppleTalk, а также с использованием службы маршрутизации и удаленного доступа Windows 2000. Если хост-система IBM работает с сетевыми протоколами SNA, то SNA Server создает сетевое соединение с такой хост-системой с применением стандартных протоколов [ВМ SNA (рис. А-1).
tAN/WAN-протоколы:
AS/400
I Мэйнфрейм Сервисы для интеграции:
Сетей Данных Приложений Систем управления сетями ХоЕп-снстем с Web
UNIX OS/2
Macintosh MS-DOS Windows Зл Windows 95/98 Windows NT Workstation Windows 2000
Professional Рис. А-1. SNA Server обеспечивает бесшовный доступ к хост-системам IBM SNA
668
ЧАСТЬ 6
Приложения
После установления сетевого соединения клиенты, используя SNA Server, могут обращаться к данным, приложениям и сетевым сервисам на IBM-хостах. Благодаря SNA Server отделы информационных технологий могут создавать приложения, открывающие доступ к данным и приложениям на IBM-хостах из пользовательского интерфейса операционных систем или Web-браузеров, работающих на персональных компьютерах. SNA Server предоставляет полный набор сервисов интеграции с хост-системами. Интеграция с сетями. Кросс-платформенная поддержка сетевых соединений, протоколов, служб каталогов и интеграции подсистем безопасности, а также единый вход в различные системы. (Поддержка единого входа дает возможность получать доступ ко множеству серверов, систем или приложений по одному паролю.) Интеграция с хост-данными. Сервисы передачи файлов, технологии Universal Data Access типа OLE DB и ODBC (Open Database Connectivity), а также репликация хост-данных для доступа к IBM DB2, DB2/400, VSAM, «плоским» файлам AS/400 и файлам баз данных ORACLE. Интеграция приложений. Поддержка доступа через терминалы, интегрированные сервисы транзакций, а также интеграция асинхронных коммуникационных сред IBM MQSeries с Microsoft Message Queue Services. Интеграция систем управления сетями. Интеграция между службами управления сетями Windows 2000 и сервисами управления на базе IBM NetView. Чтобы понять, как с помощью SNA Server можно интегрировать сети Windows 2000 с сетями на основе хост-систем IBM, Вы должны изучить базовые компоненты IBM SNA.
Архитектура IBM SNA SNA — это сетевая архитектура, разработанная IBM для мэнфреймов, компьютерных систем среднего класса и персональных компьютеров. SNA определяет набор коммуникационных протоколов и форматов сообщений для коммуникационного обмена данными и управления сетями, объединяющими IBM-хосты. SNA также определяет методы: • терминального доступа к приложениям на мэйнфреймах и хост-системах; • передачи файлов между компьютерными системами; • печати данных с мэйнфреймов и хост-систем на SNA-принтерах; • межпрограммной коммуникационной связи, позволяющей приложениям обмениваться данными по сети. SNA реализует две сетевые модели. Иерархические сети. Модель иерархических SNA-сетей обеспечивает удаленный доступ с терминалов к централизованным системам. В этой модели централизованные системы должны предоставлять сетевые сервисы всем пользователям в сети. Одноранговые сети. Более современная модель APPN (Advanced Peer-to-Peer Networking) позволяет использовать ресурсы локальных (LAN) и региональных сетей (WAN), а также клиент-серверные вычисления. APPN-сеть поддерживает один из видов распределенной обработки, позволяя любому компьютеру получать
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
669
доступ по протоколам SNA к ресурсам любого другого компьютера в сети. Компьютеры в APPN-сети не зависят от коммуникационных сервисов мэйнфрейма. Из-за распространенности унаследованных приложений, работающих на мэйнфреймах и хост-системах IBM, обе сетевые модели SNA по-прежнему широко применяются в корпоративных сетях. Примечание SNA постепенно эволюционирует к одноранговой структуре сетей. В процессе этой эволюции APPN-сети часто комбинируются с иерархическими SNAсетями.
Иерархические SNA-сети В модели иерархических SNA-сетей на вершине иерархии находится мэйнфрейм, а на самом нижнем уровне — конечный пользователь. Примечание В терминологии SNA конечный пользователь — это не только пользователь, но и прикладная программа. В SNA имеется несколько классов компонентов для поддержки коммуникационной связи между мэйнфреймом или хост-системой и конечным пользователем. Аппаратные компоненты, или узлы. Компьютерные платформы и сетевые устройства, реализующие специфические SNA-функции управления и коммуникационной связи. Типы соединений. Аппаратные и коммуникационные стандарты, предназначенные для формирования коммуникационных путей передачи данных между узлами в SNA-сети. Физические элементы (PU). Комбинация аппаратного и программного обеспечения, позволяющего настраивать и управлять устройствами, соединениями и протоколами в SNA-сети, Логические элементы (LU). Протоколы, стандартизирующие формат данных, доставляемых для конкретных приложений, например при доступе с терминалов и печати. Эти компоненты образуют основу IBM SNA. Все они подробно рассматриваются в следующих разделах.
Аппаратные компоненты в иерархических сетях Формирование иерархической SNA-сети начинается с подбора ее аппаратных компонентов. Каждый аппаратный компонент различается по типу узла, определяющему его положение в иерархии SNA и взаимосвязи с другими аппаратными компонентами сети. Такие компоненты SNA перечислены в таблице А-1, а взаимосвязи между ними показаны на рис. А-2. Примечание Некоторые современные хост-системы поддерживают и одноранговые сети. В таких средах на стороне конечного пользователя может присутствовать узел типа 2.1 (ориентированный на одноранговую коммуникационную связь).
670
ЧАСТЬ 6
Приложения
Таблица А-1. Аппаратные компоненты в иерархической SNA-сети Аппаратный компонент
Узел
Описание
Мэйнфрейм
Узел типа 5
FEP (Front-End Processor)
Узел типа 4
Контроллер кластера
Узел типа 2
Компоненты на стороне конечного пользователя
Периферийные узлы
Центральный компонент иерархической сети. Выполняет централизованные приложения, доступные пользователям SNA-сети. Обычно выделяется для управления коммуникационной связью с мэйнфреймом. Берет на себя поддержку многих коммуникационных процессов, которые иначе отнимали бы дорогостоящие ресурсы мэйнфрейма. Также называется контроллером коммуникационной связи (communications controller). Управляет группой (кластером) принтеров и терминалов конечных пользователей. Часто размещается на удаленных участках и соединяется с FEP по WAN-каналам. Терминалы и принтеры, подключенные к контроллеру кластера.
Мэйнфрейм Узел типа 5 FEP
Узел типа 4 Контроллер кластера Узел типа 2 Терминал Периферийный узел
Принтер Периферийный узел Рис. А-2. Иерархия аппаратных компонентов в SNA
Типы соединений в иерархических сетях Соединения образуют путь передачи данных между аппаратными компонентами в SNA-сети. Они включают пути от мэйнфрейма к FEP и от FEP к контроллеру кластера.
Соединения от мэйнфрейма к FEP Модули FEP можно подключать к мэйнфреймам либо по канальному соединению (IBM Channel), либо с помощью Open Systems Adapter. IBM Channel подключает компоненты к мэйнфрейму по специализированному высокоскоростному коммуникационному каналу. Канальное соединение поддерживается одним или несколькими микропроцессорами мэйнфрейма, выделенными специально для этой задачи. Подключение к мэйнфреймам IBM по таким каналам самый быстрый и эффективный метод. Два наиболее распространенных типа соединений IBM Channel описываются в таблице А-2.
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
671
Таблица А-2. Соединения IBM Channel
Тип кабелей
Состав
Скорость передачи
Bus & Tag
Два многожильных медных кабеля с оплеткой
3,0-4,5 .Мб/с
ESCOM (Enterprise System Connectivity)
и большими \шогоштырькопыми разъемами на концах Волоконно-оптический кабель
До 17 Мб/с
Open Systems Adapter, установленный на хосте, позволяет напрямую подключаться к сетям Token Ring, Ethernet и FDDI.
Соединения от FEP к контроллеру кластера FEP подключается к контроллеру кластера или к другим компонентам, стоящим на более низких уровнях иерархии SNA, по соединениям нескольких типов, также называемым каналами. Типы соединений различаются способом доступа к FEP. Три наиболее распространенных типа соединений перечислены ниже. SDLC (Synchronous Data Link Control). Позволяет контроллеру кластера взаимодействовать с FEP по обычным коммутируемым телефонным линиям или по выделенным (арендованным) линиям телекоммуникационной связи. SDLC существует уже многие годы и широко используется в сетевых SNA-средах. 802.2 DLC (Data Link Control). Позволяет контроллеру кластера взаимодействовать с FEP по сетям со стандартными топологиями, например Token Ring, Ethernet или FDDI. Хотя DLC появился позже SDLC, он завоевал широкую популярность в более новых системах благодаря своей эффективности и гибкости. X.25/OJLLC. Позволяет контроллеру кластера взаимодействовать с FEP по стандартным сетям с коммутацией пакетов. X.25/QLLC — это стандарт ITU (International Telecommunications Union) на глобальные сетевые коммуникации с коммутацией пакетов, требующий применения протокола QLLC (Qualified Logical Link Control), также называемого Х.25. Соединение Х.25 медленнее соединений 802.2, но сравнимо с SDLC-соединением. Подробнее о типах соединений см. главу 10 «Взаимодействие с хост-системами IBM» в этой книге.
Физические элементы в иерархических сетях Создание SNA-сети требует установки на аппаратных компонентах SNA определенного сетевого программного обеспечения. Такое программное обеспечение существует для каждого из трех основных аппаратных компонентов: мэйнфреймов, FEP и контроллеров кластеров. Комплекс программных и аппаратных средств, установленных на каком-либо устройстве в SNA-сети, называется физическим элементом (physical unit, PU) (рис. А-3). Обратите внимание: PU — это компонент, представляющий аппаратное устройство (узел) в SNA-сети. Каждый тип PC идентифицируется по номеру (таблица А-3): чем он больше, тем выше положение данного PU в иерархии SNA. Примечание Концепция физических элементов может привести к путанице. Помниre, что PU — это не само аппаратное устройство, а комплекс программного и аппаратного обеспечения, представляющий устройство в SNA-сети.
672
ЧАСТЬ 6
Приложения
PU типа 5
Оборудование: мэйнфрейм Модель: S/390 Программное обеспечение: VTAM/SSCP
PU типа 4 Оборудование: FEP Модель: IBM 3720
Программное обеспечение: AFC/NCP
PU типа 2 AM/SSCP
Оборудование: контроллер кластера Модель: IBM 3274 Программное обеспечение1. Configuration Support Program К терминалам и принтерам
К терминалам и принтерам
Рис. А-3. PU — комбинация программного и аппаратного обеспечения Таблица А-3. Типы PU Тип PU PU 5 PU 4 PU 2
Аппаратный компонент
Модель
Мэйнфрейм (узел типа 5) S/370, S/390 FEP (узел типа 4, или контроллер коммуникационной связи) IBM 3745, 3720 Контроллер кластера (узел типа 2) IBM 3174. 3274
Примечание Тип 3 не реализован, а дополнительный тип PU (2.1) описывается в разделе по одноранговым SNA-сетям.
Программное обеспечение мэйнфрейма VTAM (Virtual Telecommunications Access Method) — это программа для мэйнфреймов IBM, которая управляет коммуникационным взаимодействием между приложениями на мэйнфрейме и терминалами или компьютерами, подключенными к мэйнфрейму. VTAM включает SSCP (system services control point), которая представляет собой фокальную точку в иерархической сети. SSCP активизирует, контролирует и деактивизирует сетевые ресурсы (например, FEP, контроллеры кластеров, терминалы и принтеры). SSCP также ведет мониторинг и регистрирует состояние SNA-компонентов. После активизации VTAM и SSCP мэйнфрейм становится PU 5. Традиционно VTAM и SSCP напрямую взаимодействовали со следующим более низким уровнем в иерархии, с P U 4 (FEP). Однако сейчас PU 5 вес чаще напрямую взаимодействует с PU 2, подключаемым по канальному соединению или через Open Systems Adapter.
ПРИЛОЖЕНИЕ А Концепции взаимодействия с IBM SNA
673
Программное обеспечение FEP FEP (Front-End Processor), также называемый контроллером коммуникационной связи или PU 4, выполняет программу управления коммуникационной связью ACF/NCP (Advanced Communication Function/Network Control Program). FEP использует это программное обеспечение для управления маршрутизацией и коммуникационным взаимодействием в иерархической SNA-сети, разгружая от этих задач мэйнфреймовую систему. ACF/NCP конфигурируется на мэйнфрейме, а затем загружается на FEP. Как PU 4, FEP поддерживает двухстороннюю коммуникационную связь со следующим более низким уровнем в иерархии SNA.
Программное обеспечение контроллера кластера Контроллер кластера (PU 2) работает с административным программным обеспечением — Configuration Support Program, управляющим соединениями, которые контроллер кластера устанавливает с терминалами и принтерами. Примечание Вместо традиционного контроллера кластера можно использовать компьютер под управлением SNA Server.
Логические элементы в иерархических сетях В SNA-сети PU типов 5 и 2, передающие данные и использующие сетевые протоколы SNA, называются логическими элементами (logical units, LU). LU — это точка входа конечного пользователя в SNA-сеть. Как уже говорилось, в терминологии SNA конечным пользователем может быть не только сам пользователь, но и приложение. Например, когда конечный пользователь вводит данные на SNA-терминале, они передаются LU, который перенаправляет их по сети главному узлу. После того как данные попадают на главный узел, другой конечный пользователь передает их LU на главном узле для обработки. Здесь конечный пользователь на терминале — собственно пользователь, а конечный пользователь на главном узле — прикладная программа этого узла. В иерархических сетях все LU устанавливают и контролируют коммуникационные связи с другими LLI, опираясь на SSCP, выполняемую на мэйнфрейме, поэтому они называются зависимыми логическими элементами (dependent logical units). Как и типы PLJ, типы LU идентифицируются по номерам (таблица А-4). Таблица А-4. Типы LU, используемые в иерархических сетях Тип LU
Компонент
LU 0
Нестандартный интерфейс
LU 1
Принтеры типа IBM 3287
LU 2
Терминалы с монохромными дисплеями IBM 3278 (3270), терминалы с цветными дисплеями 3279/3179, графические терминалы
Описание Позволяет разрабатывать специализированные приложения. Является универсальным LU. Обрабатывает передачу принтерных данных системному и сетевым принтерам. LU 1 использует формат SCS (SNA character string). Определяет, как форматируются и передаются потоки данных с терминалов,
(см. след, стр.)
674
ЧАСТЬ б
Таблица А-4.
Приложения (продолжение)
Тип LU
Компонент
Описание
LU 3
Принтеры типа IBM 3270
Использует формат потока данных SNA 3270 для управления передачей данных системному и сетевым принтерам. Это наиболее распространенный тип принтерного LU.
Примечание Типы LU, применяемые в одноранговых сетях (в том числе LU 6.2), описываются R разделе «APPN» далее в этом приложении,
Функциональные уровни SNA Функциональность каждого уровня SNA, работающего в контексте модели иерархических сетей, показана в таблице А-5. Уровень транзакционных сервисов и физический уровень выходят за рамки исходных спецификаций SNA, но включены в эту таблицу, чтобы дать Вам более полное представление о поддержке сетей IBM. Таблица А-5. Функциональные уровни в иерархических SNA-сетях Функциональный уровень SNA
Описание
Транзакционные сервисы (Transaction Services)
Концептуальный уровень, представляющий хост-приложения, которые устанавливают и завершают SNA-сеансы между пользователями. Функциональное управление Уровень, отвечающий ,ча форматирование потоков данных (Functional Management) и преобразование кодов символов (например, в потоках данных 3270). Также управляет активными сеансами. Управление потоками данных Предоставляет протоколы для поддержки целостности (Data Flow Control) данных в сеансах, синхронизации обмена данными и разбиения блоков данных на пакеты. Управление передачей Использует VTAM и NCP для управления активными сеан(Transmission Control) сами между сторонами соединений (end-to-end sessions). Отвечает за формирование последовательностей данных. Может поддерживать шифрование и дешифрование данных. Управление коммуникацион- Определяет пути передачи данных между иерархическими ными путями (Path Control) SNA-узлами с применением VTAM и NCP. Управление каналами Управляет передачей данных между узлами и отвечает передачи данных за обнаружение ошибок и восстановление данных. (Data Link Control) Управляет передачей информации по стандартным WAN (в том числе SDLC), LAN (Token Ring, Ethernet, FDDI, ATM) и канальным интерфейсам. Физическое управление Отвечает за передачу битов по физической несущей среде. (Physical Control) При этом для LAN и WAN используются стандартные спецификации, а для канальных подключений — уникальные, разработанные специально для SNA.
Примечание Сетевые функции в APPN на некоторых уровнях отличаются от перечисленных в этой таблице. Поскольку специалистам в области сетей хорошо известна эталонная модель OSI (Open Systems Interconnection), имеет смысл сравнить функциональные уровни SNA с уровнями в модели OSI.
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
675
Функциональные уровни SNA определяют протоколы и сервисы, эквивалентные протоколам и сервисам на уровнях модели OSI. Фактически сама модель OSI была разработана в ответ на архитектуру SNA, которая оказала на нее заметное влияние. Изначально в SNA не было спецификаций уровней, соответствующих физическому и прикладному уровням модели OSI. Однако в последние стандарты по SNA включены все семь уровней, в том числе физический и транзакционных сервисов (эквивалентный прикладному уровню модели OSI). Уровень транзакционных сервисов играет важную роль в сетях IBM, поскольку транзакционныс программы часто инициируют сетевые SNA-сеансы. Однако, хотя функциональность уровней в SNA и OSI очень близка, методы, которыми она реализуется, существенно различаются (рис. А-4). Функциональные уровни SNA Транзакционные сервисы Элементы
с сетевой
адресацией (NAU)
Функциональное управл ение Управление потоком данных
Модель OSI
7. Прикладной уровень 6. Презентационный уровень 5. Сеансовый уровень 4. Транспортный уровень
Сетевые компоненты
Управление передачей
управления коммуникационными путями
Управление каналами
2, Канальный уровень
Физическое управление
1. Физический уровень
3. Сетевой уровень
Рис. А-4. Взаимосвязь функциональных уровней SNA с моделью OSI
Сетевые компоненты управления коммуникационными путями Три нижних функциональных уровня SNA объединяют сетевые компоненты управления коммуникационными путями (path control network components), также называемые транспортной сетью SNA (SNA transport network). Эти уровни отвечают за управление потоком сообщений в сети и их перенаправление, а также предоставляют интерфейсы для доступа к физической несущей среде.
Элементы с сетевой адресацией Четыре верхних функциональных уровня SNA предоставляют коммуникационные протоколы для взаимодействия между элементами с сетевой адресацией (network addressable units, NAU). NAU включают следующие SNA-компоненты: •
физические элементы;
•
логические элементы;
• точки управления (например, SSCP во VTAM). У каждого SNA-узла может быть по несколько NAU для управления специфическими сетевыми функциями. Каждый NAU имеет уникальный адрес, на который он получает данные в ходе SNA-сеанса.
676
ЧДСТЬ б
Приложения
SNA-сеансы Коммуникационное взаимодействие в SNA основано на установлении логических сеансов между NAU. Логические сеансы — это коммуникационные пути, обеспечивающие работу сетевых устройств и передачу трафика но сети. В SNA-сетях информация о маршрутах определяется динамически при установлении сеанса и действительна до ето завершения. Все SNA-пакеты во время сеансов идут по одному и тому же логическому пути от NAU-источника до NAU-получателя. Если коммуникационное взаимодействие в ходе SNA-сеанса прерывается хотя бы на малое время, SNA завершает этот сеанс. Сети, в которых SNA-протоколы туннелируются по стандартным WAN-соединениям, должны использовать маршрутизаторы с поддержкой DLSw (Data Link Switching), средства FRAD (Frame Relay Assembler/Disassemblers) с поддержкой Frame Relay (RFC 1490) или специализированные ATM-коммутаторы. Типы сеансов в иерархических SNA-сетях перечислены в таблице А-6. Таблица А-6. Типы SNA-сеансов в иерархических сетях Тип сеанса SSCP-K-SSCP SSCP-K-PU SSCP-K-LU LU-K-LU
Описание _______^^___ Обеспечивает к о м м у н и к а ц и о н н у ю связь между SSCP и мультидоменных иерархических сетях Используется системными администраторами для коммуникационного взаимодействия с сетевыми устройствами Используется логическими элементами в иерархических сетях для доступа к сеансовым сервисам, контролируемым SSCP, например к сервисам входа в сеть и выхода ил нее Обеспечивает коммуникационную связь между конечными пользователями и приложениями как в иерархических, так и в одноранговых сетях
Примечание APPN, кроме сеансов LU-K-LU, поддерживает сеансы СР-к-СР (control point to control point). Эти сеансы позволяют управлять всеми функциями одноранговой SNA-сети без SSCP на мэйнфреймах.
Иерархические домены и подобласти Узлы в иерархических SNA-сетях группируются в домены и подобласти (subareas). SNA-домен в такой сети представляет набор сетевых ресурсов, управляемых SSCP, который реализуется VTAM на хост-системе. В кале дом домене только один SSCP. Некоторые крупные SNA-сети содержат сотни доменов. Когда конечным пользователям из разных доменов нужно установить коммуникационную связь через сеанс LU-K-LU, SSCP в этих доменах сначала создают сеанс SSCP-K-SSCP. SNA-домены, как правило, включают несколько подобластей. Подобласть состоит из одного узла подобласти (узла типа 5 или 4) и ресурсов, контролируемых им, например узлов типа 2, как показано на рис. А-5. Узлы подобластей могут взаимодействовать с периферийными узлами в своей подобласти и устанавливать одно или несколько соединений с узлами других подобластей. Соединения между узлами подобластей называются группами передачи (transmission groups). Способность создавать группы передачи позволяет узлам подобластей формировать таблицы маршрутизации.
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
677
Подобласть 1 Узел типа 5 Терминал Узел типа 2 ^^ {контроллер кластера)
Узеятипа4
(контроллер коммуникационной связи)
Подо&пасть 3
(контроллер кластера)
Узеи тила 4 (контроллер коммуникационной связи)
Терминалы
^\ Узел типа 2 (контроллер кластера) Подобласть 2
Терминалы
Рис. А-5. SNA-домен с тремя подобластями Поддержание нескольких соединений в группе передачи обеспечивает максимальную производительность и надежность сети. Если одно из соединений выходит из строя, SNA перенаправляет данные по одному из других соединений в данной i руппе передачи. Примечание В одноранговых SNA-сетях домены и функции маршрутизации определяются по-другому (см. следующий раздел).
APPN В 1981 году IBM начала разрабатывать новые коммуникационные стандарты, которые потом превратились в архитектуру одноранговых сетей APPN (Advanced Peer-to-Peer Networking). APPN заметно отличается от традиционной архитектуры иерархических сетей SNA, поскольку поддерживает одну из форм распределенной обработки. Все компьютеры в APPN-сети могут взаимодействовать друг с другом напрямую, без централизованных узлов типа 5 или контроллеров коммуникационной связи (узлов типа 4). Эта модель позволяет создавать более гибкие среды, чем традиционная иерархическая модель. APPN определяет, как одноранговые (равноправные) компоненты взаимодействуют друг с другом и как каждый компьютер предоставляет свои сетевые сервисы в сети. В APPN предусмотрены собственные стандарты для следующих компонентов Аппаратные компоненты, или узлы. Аппаратное обеспечение компьютерных платформ и сетевых устройств, реализующих специфические для SNA APPN функции управления и коммуникационной связи.
678
ЧАСТЬ 6
Приложения
Типы соединений. Аппаратные и коммуникационные стандарты, предназначенные для формирования коммуникационных путей передачи данных между компонентами в APPN-сети. Физические элементы (PU). Аппаратно-программное обеспечение, позволяющее настраивать и управлять устройствами, соединениями и протоколами в SNA APPN. Логические элементы (LU). Протоколы, стандартизирующие формат данных, доставляемых для конкретных приложений, например при доступе с терминалов и печати. Примечание Хотя в АРРМ-модели SNA-сетей определены те же классы компонентов, что и в иерархической модели SNA-сетей, сами компоненты заметно различаются.
Аппаратные компоненты в одноранговых сетях Типичная APPN-сеть состоит из нескольких разных устройств, например из хостсистем IBM или персональных компьютеров, подключенных к одной шш более LAN (рис. А-6). Одноранговую модель можно применять во многих средах. Чаще всего она используется в средах с AS/400, поскольку эта система популярна и изначально ориентирована на APPN. Современные мэйнфреймовые системы тоже поддерживают APPN, Рабочие станции
Рабочие станции
Рабочие станции
Рабочие станции
Рис. А-6. Сетевые компоненты в APPN Сетевым APPN-устройством может быть любой аппаратный компонент, способный функционировать как узел PU 2.1. (PU 2.1 является расширением PU 2.) В качестве узлов PU 2.1, если на них установлено соответствующее программное обеспечение, могут быть сконфигурированы: • •
компьютеры AS/400; мэйнфреймы;
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
679
• раоочие станции; •
маршрутизаторы.
Типы соединений в одноранговых сетях Наиболее распространенные типы соединений (каналы), используемые для подключения APPN-устройств, перечислены в таблице А-7. Подробнее1 об этих типах соединений см. главу 10 «Взаимодействие с хост-системами IBM* в этой книге. Таблица А-7. Типы соединений Тип соединения
Метод подключения
802.2 DLC
Token Ring
Ethernet FDDI SDLC Twinax
Общедоступные и частные коишутирусмые телефонные линии Протоколы Twinax
Примечание Twinax-канал — «родной» метод подключения к системам AS/400.
Физические элементы в одноранговых сетях Как и в модели иерархических сетей, функционирование аппаратного компонента в APPN-сети определяется типом программного обеспечения, установленного на этом компоненте. Комбинация аппаратного и программного обеспечения сетевого устройства в APPN, как и в иерархических сетях, тоже называется PU. PU представляет устройство (узел) в SNA-сети. В однородной APPN-сети все узлы являются PU типа 2.1. Этот тип — расширение PU стандартного типа 2.0. Как и узлы PU типа 2.0 в иерархических SNA-сетях, одноранговые узлы типа 2.1 могут взаимодействовать с узлами типа Г). Как таковые, узлы типа 2.1 не требуют SSCP на мэйнфреймах или контроллеров коммуникационной связи, применяемых в иерархических SNA-сетях. Это позволяет формировать сети SNA APPN исключительно из узлов типа 2.1, в качестве которых могут работать, в частности, системы IBM AS/400 и обычные персональные компьютеры.
Типы узлов В APPN-сстях существует три типа узлов PU 2.1 (рис. А-7): •
сетевые узлы APPN;
• конечные узлы APPN; •
узлы LEN (Low Entry Network).
Сетевые узлы APPN Из трех типов APPN-узлов сетевые узлы предоставляют наивысший уровень функциональности. Сетевые узлы APPN могут выполнять все базовые функции, поддерживаемые другими узлами APPN PU типа 2.1. Для совместимости с иерархическими сетями узлы PU 2.1 могут устанавливать сеансы и с узлами типа 5 (м.эйн-
680
ЧАСТЬ Б
Приложения Сетевой узел
Сетевой узел
р
Узел LEN
Конечный узел
Конечный узел
Узел LEN Рис. А-7. Типы узлов PU 2,1 в APPN-сети фреймами). Однако при соединении с другими узлами PU 2.1 сетевые узлы APPN (реализованные в IBM AS/400) предоставляют дополнительные сервисы: • управление сеансами LU-K-LU; • маршрутизацию; • полнофункциональные службы каталогов; • поддержку сеансов СР-к-СР (для функций управления APPN). Сетевой узел APPN и подключенные к нему другие узлы PU 2.1 образуют домен APPN. Таким образом, в своем домене сетевой узел APPN выступает в роли сервера для остальных узлов PU 2.1. Он также может функционировать как промежуточный узел (intermediate node), поддерживая функции маршрутизации в APPNсетях со множеством сетевых узлов A P P N . На сетевом узле APPN может быть точка управления (control point, СР), которая предоставляет сервисы обновления и поиска в базе данных каталога. СР устанавливает сеансы с СР на смежных сетевых узлах APPN, поддерживая актуальность каталогов и информации о структуре сети без использования SSCP на мэйнфрейме. Например, когда в APPN-сети появляется новый конечный узел, соответствующий сервер (сетевой узел APPN) автоматически обновляет свой каталог и таблицы маршрутизации и распространяет ;->ту информацию на другие сетевые узлы APPN. Примечание Службы каталогов APPN отличаются от большинства других служб каталогов, не использующих сетевые протоколы SNA. Так как APPN-ресурсам не назначаются фиксированные адреса, каталоги APPN в ответ на запросы сообщают местонахождение LU получателя и маршрут к нему, а не адрес его ресурса. Поэтому сетевые узлы APPN должны динамически создавать идентификаторы маршрутов (route identifiers) при установлении сеансов LU-K-LU. Конечные узлы APPN Как и все узлы PU 2.1, конечные узлы APPN могут устанавливать сеансы с другими узлами PU 2.1 (и с узлами PU 5, находящимися в иерархических SNA-сетях). Но в отличие от сетевых узлов APPN конечные узлы не выполняют функции маршрутизации и не могут выступать в роли промежуточных узлов в APPN-сетях. Тем
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
681
не менее конечные узлы предоставляют подмножество сеансовых сервисов APPN и служб каталогов для собственных LU. Конечные узлы могут быть подключены к сетевому узлу APPN, который действует как сервер, обеспечивающий маршрутизацию, поддержку сеансов и служб каталогов. Конечный узел можно подключать более чем к одному сетевому узлу, но единовременно в роли сервера всегда выступает только один из этих сетевых узлов. Узлы LEN Как и остальные APPN-узлы, узлы LEN могут устанавливать сеансы с другими узлами PU 2.1 (и с узлами PU 5, находящимися в иерархических SNA-сетях). Однако коммуникационная связь узлов LEK с APPN-узлами, которыми управляют другие сетевые узлы APPN, возможна только через сетевой узел APPN, работающий как сервер. Узлы LEN не предоставляют никаких функций маршрутизации и сеансовых сервисов.
Логические элементы в одноранговых сетях LU — это SNA-протоколы, которые предоставляют стандартизированный формат, используемый при доставке данных приложениям. В APPN-сетях обычно применяются LU типа 6.2, также называемые АРРС (Advanced Prograrn-to-Program Communications) LU. LU 6.2 разработан недавно и является наиболее совершенным типом LU. В отличие от зависимых LU, работающих в иерархических SNA-сетях, LU 6.2 не полагается на нейтрализованное программное обеспечение мэйнфрейма. Напротив, LU 6.2 создает основу для поддержки распределенных вычислений, при которых программы на разных компьютерах взаимодействуют друг с другом напрямую через сеть. Однако для принтеров и дисплейных терминалов AS/400 APPN поддерживает и другие типы LU (таблица А-8). Таблица А-8. Типы LU в APPN Тип LU
Описание
LU 6.2
Поддерживает АРРС для широкого спектра SNA-узлов и предусматривает функции для поддержки SNA-приложений любых типов. Недавно разработанный и наиболее совершенный тип LU. Поддерживает принтеры, использующие потоки данных в формате ШМ 5250. Мало распространен и:1-за ограниченной функциональности. Поддерживает дисплейные терминалы, использующие потоки данных в формате IBM 5250, например дисплейные станции AS/400. Мало распространен из-за ограниченной функциональности.
LU 4 LU 7
АРРС LU 6.2 является основой для IBM АРРС (Advanced Program-to-Prog га in Communications) — протокола сетевых коммуникаций, наиболее распространенного в APPNсетях. АРРС представляет собой универсальный метод сетевого доступа, который поддерживает: •
доступ с терминалов 5250 (к системам AS/400);
• доступ с терминалов TN5250:
ЧАСТЬ б Приложения
682 • •
передачу файлов; сетевые сервисы.
Программы, использующие для коммуникационной связи АРРС LU 6.2, называются транзакционными (transaction programs, TP). Транзакционные программы, взаимодействующие через АРРС-сеансы, показаны на рис. А-8. ТРА LU6.2
Клиент
i AS/400
Рис. А-8. Транзакционные программы, взаимодействующие через АРРС-сеансы АРРС LU 6.2 служит транслятором между транзакционньтми программами и сетью. Когда ТР на одном из компьютеров передает данные программному обеспечению АРРС, оно устанавливает сеанс и посылает эти данные узлу-получателю. На принимающей стороне АРРС преобразует информацию в исходный формат и передает ее соответствующей партнерской ТР (partner TP). АРРС работает с соединениями любых стандартных типов, поддерживаемых SNA.
Зависимые и независимые LU АРРС обычно использует локальный АРРС LU и один или несколько удаленных ЛРРС LU. Локальные АРРС LU могут быть зависимыми или независимыми. Зависимые LU поддерживаются для обратной совместимости с иерархическими сетями. Такие LU для установления сеансов LU-K-LU и управления ими требуют наличия VTAM SSCP на мэйнфрейме. Между нарой LU может быть установлен только один сеанс. Зависимые LU применяются, когда АРРС ТР нужно получить доступ к мэйнфрейму, работающему с версией VTAM ниже V3R2, Эти версии VTAM не поддерживают независимые LU. Кроме того, зависимые LU не годятся для коммуникационного взаимодействия с системами AS/400. В одноранговых APPN-сетях, которые обычно реализуются в средах с AS/400, используются независимые АРРС LU. Они могут устанавливать и контролировать сеансы LU-K-LU без VTAM SSCP. Независимые LU позволяют создавать между парой LU множество параллельных сеансов, Поддержка независимых LU — одно из основных преимуществ APPN-сетей.
Развитие SNA SKA - унаследованная сетевая архитектура, разработанная десятки лет назад. Но она никогда не была статичной. Начав свою жизнь с иерархической модели, она постепенно эволюционировала, и в конечном счете па ее основе была создана более гибкая одноранговая модель. В последнее время ШМ стремится скомбинировать лучшие качества этих моделей и интегрировать их с современными LAN- и WAN -11 ротокол ам и.
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
683
Интеграция иерархической и одноранговой моделей Хотя иерархическая и одноранговая сетевые среды во многом различны, IBM предоставляет средства для интеграции этих двух моделей SNA-сетей. Как уже говорилось, узлы APPN PU типа 2.1 могут устанавливать сеансы с мэйнфреймами (узлами PU типа 5), размещенными в иерархических сетях. Более того, АРРК-сети могут функционировать как транзитные, соединяющие домены в иерархических сетях. В последнее время IBM совершенствует компоненты иерархических сетей, дополняя их поддержкой APPN-функций. Например, VTAM теперь поддерживает не только модель иерархических сетей, но и APPN. Теперь с помощью VTAM можно соединять разные APPN-сети.
IBM Networking Blueprint IBM также реализует сетевую спецификацию IBM Networking Blueprint, на основе которой можно будет интегрировать в традиционную сетевую архитектуру SNA современные протоколы и стандарты. IBM Networking Blueprint описывает стандарты на сетевые протоколы, прикладные сервисы и сервисы системного администрирования. В рамках этой модели IBM стремится к более тесной интеграции хостсистем IBM и моделей SNA со стандартными сетевыми протоколами TCP/IP, IPX и NetBIOS. Примечание Поскольку Microsoft SNA Server полностью интегрирован с операционной системой Windows 2000 Server, он поддерживает эти и другие протоколы и сервисы, позволяющие авторизованным Windows-клиентам и клиентам под управлением операционных систем, отличных от Windows, подключаться к хост-системам IBM SNA. Подробнее об интеграции гетерогенных сетей с иерархическими SNA- и одноранговыми APPN-сетями см. главу 10 * Взаимодействие с хост-системами IBM» в этой книге.
Стандарты приложений хост-систем Предназначение любой сетевой модели — обеспечить эффективную и надежную поддержку приложений, автоматизирующих бизнес-процессы в организации. В сетевой среде SNA такие приложения часто опираются на доступ с терминалов, реляционные и нереляционные базы данных, сервисы обработки транзакций и системы управления сетью, работающие на хост-системе IBM.
Доступ с терминалов В зависимости от типа хост-системы IBM, которая управляет сеансами, организации могут использовать один из двух типов доступа с терминалов: 3270 (для мэйнфреймов) или 5250 (для AS/400).
Доступ к мэйнфреймам IBM В этом случае обычно используется поток данных в формате 3270 — протокол, определяющий, как компоненты в иерархических SNA-сетях получают доступ к мэйнфреймам IBM. Поток данных 3270 поддерживается дисплейными устройствами 3270 вроде терминалов и их эмуляторов (LU 2), принтерами 3270 (LU 1 или 3) и
684
ЧАСТЬ 6
Приложения
приложениями (LUA). 3270 LU известен как зависимый LU, так как не может работать без поддержки мэйнфрейма. Клиенты получают доступ к SNA-ресурсам, используя: • терминалы 3270 и их эмуляторы; • терминалы 3278 и их эмуляторы (модели 2, 3, 4 и 5); • эмуляторы терминалов на основе Telnet (TN3270), в том числе TN3270E (расширение TN3270), и на основе Web-браузера. Эмуляторы Telnet-терминалов позволяют компьютерам, работающим с TCP/IP, получать доступ к хост-системам либо напрямую (если они поддерживают TCP/ IP),'либо через шлюзы TCP/IP-SNA. Примечание
SNA Server поддерживает доступ через 3270 и TN3270.
Доступ к системам AS/400 В этом случае используется поток данных в формате 5250. Этот протокол поддерживает только эмуляцию терминалов. Можно работать как со стандартными эмуляторами терминалов 5250, так и с эмуляторами терминалов TN5250, в том числе на основе Web-браузера. Примечание SNA Server поддерживает оба метода терминального доступа к AS/400. Подробнее на эту тему см. главу 10 «Взаимодействие с хост-системами IBM» в этой книге.
Стандарты баз данных на хост-системах Хотя терминалы предоставляют подходящий интерфейс для доступа к широкому спектру хост-приложений, большинству организаций также требуется программное обеспечение, способное бесшовно интегрировать данные и приложения хост-систем с современными информационными системами на основе архитектуры «клиент-сервер* и стандартов Интернета. Чтобы добиться такого уровня интеграции, Вы должны понимать стандарты, реализуемые приложениями, которые управляют базами данных на хост-системах IBM. Хост-приложения IBM часто опираются на нижележащую архитектуру баз данных, поддерживаемую хост-системой. IBM использует архитектуру DDM (Distributed Data Management). Программы, рассчитанные на эту архитектуру, могут обмениваться данными с приложениями на самых разнообразных платформах.
Доступ к данным на уровне записей Доступ на уровне записей с использованием DDM позволяет приложению напрямую обращаться к нужной записи в физическом файле. Для доступа к данным на хост-системах DDM предоставляет два протокола (рис. А-9). DRDA (Distributed Relational Database Architecture). DRDA - это DDM-протокол для доступа к реляционным данным на хост-платформах, включая MVS (Multiple Virtual Storage) IT AS/400, которые используют системы управления реляционными базами данных IBM Г)В2.
ПРИЛОЖЕНИЕ А
Концепции взаимодействия с IBM SNA
685
RLIO (Record Level Input/Output). RLIO — :->то DDM-иротокол для доступа к нереляционным данным в различных операционных системах типа MVS, OS/390 и OS/400.
1
Терминал Рис. А-9. Доступ к реляционным и нереляционным данным на хост-системах IBM
Доступ к данным на уровне файлов DDM также поддерживает протокол Stream I/O (Stream Input/Output) для доступа к данным на уровне файлов. Stream I/O позволяет обращаться единовременно к одному файлу данных на хост-системе IBM (а не к одной записи, как SQL). Именно на его основе создаются программы для быстрой передачи файлов с большим объемом данных. Примечание Microsoft SNA Server предоставляет ODBC Driver for DB2 и Microsoft OLE DB Provider for AS/400, а также VSAM лля поддержки доступа к реляционным и нереляционным данным на хост-системах. SNA Server поддерживает и репликацию баз данных с хост-систем па компьютеры с Windows 2000 Server и такими приложениями, как Microsoft SQL Server'4. Подробнее об использовании драйверов баз данных и методов репликации, поддерживаемых SNA Server, см. главу 10 «Взаимодействие с хост-системами IBM» в этой книге.
Обработка транзакций Организации часто используют хост-системы IBM для приложений онлайновой обработки транзакций (online transaction processing, OLTP), автоматизирующие выполнение бизнес-операций в режиме реального времени. Эти приложения состоят из транзакционньтх программ (ТР). которые должны поддерживать целостность данных и безопасность бизнес-сред в таких сферах, как финансы, страхование, розничная торговля, системы бронирования.
686
ЧАСТЬ 6
Приложения
Стандарты безопасных транзакций ТР должна обрабатывать транзакции с поддержкой их важнейших свойств, называемых ACID: атомарности (atomicity), согласованности (consistency), изоляции (isolation) и устойчивости (durability). ТР, поддерживающая ACID, гарантирует, что каждая транзакция является: •
атомарной — в ходе каждой транзакции выполняются либо все изменения данных, либо ни одно из них; • согласованной - информация обрабатывается так, чтобы сохранить структурную целостность базы данных; • изолированной — транзакции выполняются последовательно, чтобы исключить возможность модификации данных, уже охваченных другой транзакцией; •
устойчивой — завершенные транзакции должны сохраняться так, чтобы их результаты можно было восстановить даже в случае аварии системы.
Компоненты, участвующие в обработке транзакций В распределенной среде OLTP данные могут быть повреждены при неправильном управлении ими. Монитор ТР (ТР monitor) управляет операционной средой приложения OLTP, оптимизируя использование ресурсов операционной системы и сети. Монитор ТР предоставляет системному администратору платформу управления, которая обеспечивает: • балансировку нагрузки; • отказоустойчивость; • мониторинг рабочих параметров; •
безопасность.
Мониторы ТР обычно включают программный компонент, называемый диспетчером ТР (ТР manager). Диспетчеры ТР используют протокол двухфазной фиксации транзакций (two-phase commit, 2PC), который гарантирует надежное выполнение транзакций. Примечание На платформе Windows 2000 монитором ТР является Microsoft Transaction Services. MTS включает диспетчер ТР — Distributed Transaction Coordinator, IBM поставляет диспетчеры ТР для различных мониторов ТР. Чтобы ТР могла напрямую взаимодействовать с другой ТР через SNA APPC, эти две программы должны сначала установить друг с другом сеанс LU 6.2. (LU 6.2 всегда используется при распределенной обработке транзакций в среде с мэйнфреймами.)
Синхронизация обработки транзакций Любая программа может взаимодействовать с другой, используя один из трех уровней синхронизации (рис. А-10): •
Sync Level 0 (целостность сообщений не проверяется);
•
Sync Level 1 (ограниченная поддержка целостности данных);
-
r
YlSW
Гме\0
T^-^^i^ IIB CO
:V»^SSS- '
щи MetM'^
„*
ет дол
,
ПРИЛОЖЕНИЕ А Концепции взаимодействия с IBM SNA
689
эту информацию в фокальную точку. Сервисные точки также могут принимать от фокальной точки команды, относящиеся к управлению ресурсами, отличными от SNA. Как таковые, эти точки выступают в роли шлюзов, которые транслируют информацию, связанную с управлением сетью, между двумя тинами ресурсов (SNA и не-SNA).
Фокальная точка
Входная точка
Сервисная точка
Устройство, не отвечающее архитектуре SNA
Рис. А-11. Точки управления в Net View IBM усовершенствовала модель управления NecView, которая теперь поддерживает вложенные фокальные точки (nested focal points) и распределенные точки сбора информации (distributed collection points). В последние годы IBM изменила свой подход к управлению сетями, стремясь к тому, чтобы они поддерживали современные платформы распределенных вычислений, например Windows 2000. О том, как SNA Server взаимодействует с IBM NetView, см. главу 10 «Взаимодействие с хост-системами IBM» в этой книге.
Дополнительные материалы Более подробную информацию о SNA Server и технологиях интеграции с хост-системами см. но ссылки: •
SNA Server на странице http://windows.microsoft.com/windows2000/reskit/webresources.
23 Зак 334?
П Р И Л О Ж Е Н И Е
Концепции взаимодействия с UNIX
Операционная система UNIX, написанная в основном на языке С, состоит из библиотек функций, используемых для доступа к системным ресурсам. Эти функции вызываются через самые разнообразные интерфейсы: сам язык С, различные оболочки и Perl. Почти все команды и программы UNIX представляют собой исполняемые файлы. В этом приложении Иерархическая структура файлов Ядро
690
692
Корень 692 Реализации UNIX
692
Печать в UNIX 693 UNIX Man 693
Иерархическая структура файлов Файловая система UNIX организована как иерархическое дерево каталогов и подкаталогов, начинающееся с корневого каталога (/), который является родительским по отношению ко всем остальным каталогам. Он обычно содержит все каталоги (или только их часть), перечисленные в таблице Б-1. У каждого файла и каждого каталога есть свое имя. Внутри каталога имена файлов и подкаталогов должны быть уникальны. У файлов в разных каталогах могут быть одинаковые имена. Учтите, что имена чувствительны к регистру букв, поэтому Members, members и MEMBERS считаются уникальными именами. У имен файлов могут быть расширения, например .doc или .с. Файлы, имена которых начинаются с точки, называются невидимыми (invisible), так как команда Is по умолчанию их не перечисляет. Каждый каталог содержит два файла «.» и «..», созданные командой mkdir. Они представляют соответственно текущий рабочий каталог и его pozinтельский каталог. При адресации к файлам применяются пути — как абсолютные,
ПРИЛОЖЕНИЕ Б
Концепции взаимодействия с UNIX
691
так и относительные. Абсолютный путь указывает весь путь к файлу, начиная от корня. Например, если файл members находится в каталоге documentation, а он — в основном каталоге пользователя jane, то абсолютный путь выглядит так: /usr/jane/ documentation/members. Относительный путь задает путь относительно текущего рабочего каталога. Текущим рабочим считается каталог, в котором Вы находитесь в данный момент (чтобы узнать путь к нему, введите команду pwd). Смена текущего рабочего каталога выполняется командой cd. Примеры использования этой команды показаны в таблице Б-2. Таблица Б-1. Подкаталоги в корневом каталоге Каталог
Содержимое
/bin /sbin /usr
Двоичные файлы, используемые программами внутри /usr Утилиты системного администрирования Большая част?, файлов и программ операционной системы; обычно включает подкаталоги /bin, /sbin и /lib Конфигурационные файлы и каталоги; в каталоге /etc содержится ряд важнейших файлов, в том числе /etc/shadow/ и etc/passwd Файлы, содержимое которых часто изменяется, например временные файлы или файлы почтового ящика Файлы устройств Временные файлы Основные каталоги (home directories) пользователей Общие библиотеки Статические загрузочные файлы Различные руководства в электронной форме
/etc /var /dev /tmp /home /lib /boot /man
Таблица Б-2. Варианты применения команды cd Команда cd cd cd cd cd
Описание
Без аргументов; смена каталога на основной каталог данного пользователя . Смена каталога на текущий рабочий .. Смена каталога на родительский для текущего рабочего каталога ./имя_каталога Смена каталога на указанный подкаталог в текущем рабочем каталоге ,./имя_каталога Смена каталога на указанный подкаталог в родительском каталоге текущего рабочего каталога
Каждому пользователю выделяется персональный основной каталог, интерпретируемый оболочкой как рабочий при первом входе данного пользователя в систему. В основном каталоге хранится стартовый файл (.profile — если Вы работаете с оболочкой Когп или Bourne, либо .login — если Вы работаете с оболочкой С). В этом файле содержится информация, определяющая такие параметры окружения, как пути, по которым оболочка ищет исполняемые файлы, вид строки приглашения на терминале, тип Вашего терминала и его параметры (например, клавиша удаления текущей строки, клавиша стирания символов и др.)-
692
ЧАСТЬ 6
Приложения
Ядро Ядро UNIX-системы управляет ресурсами компьютера и распределяет их между пользователями, обеспечивает запуск программ, взаимодействующих с ядром через системные вызовы, а также контролирует периферийные устройства и определяет файловую структуру для хранилища. Оно выделяет память, контролирует процессы и системные ресурсы, выполняет программы оболочки, реализует многозадачность, обрабатывает прерывания и ошибки, предоставляет сервисы ввода-вывода и управляет файловой системой.
Корень В каждой UNIX-системе имеется особый пользователь, называемый корнем (root), или суперпользователем (superuser); ему предоставляются уникальные и широчайшие привилегии в системном администрировании. Суперпользователь получает доступ ко всем файлам независимо от ограничений. Ему разрешается читать, записывать, выполнять, добавлять или удалять любой файл и просматривать любой каталог. Суперпользователь может изменять пароль любого пользователя, даже не зная его исходного пароля, останавливать систему и менять владельцев файлов. Столь широкие полномочия могут сыграть деструктивную роль, поэтому применять их следует очень осторожно. Войти в систему в качестве суперпользователя можно одним из двух способов: указав при регистрации имя root и соответствующий пароль, либо, если Вы уже вошли в систему обычным образом, набрав команду su и введя пароль корня.
Реализации UNIX UNIX, впервые разработанная в AT&T Bell Laboratories, развивается уже несколько десятилетий. Реализация BSD (Berkeley Software Distribution), созданная Computer Systems Research Group в Калифорнийском университете, обладает рядом преимуществ по сравнению с исходной реализацией, в частности предлагая оболочку С и редактор vi. UNIX System V от Bell Labs включает средства BSD. Solaris от Sun предоставляет возможности System V для рабочих станций Spare и компьютеров на базе 486-х процессоров и Pentium. Эта операционная система работает на одно- и многопроцессорных машинах. SunOS — это операционная система на основе BSD, которая работает только на однопроцессорных рабочих станциях Spare. Наконец, Linux — это бесплатная операционная UNIX-система, совместимая с System V и BSD. Кроме того, она отвечает требованиям POSIX. Краткое описание различных реализаций UNIX приведено в таблице Б-3. Таблица Б-3. UNIX-реализации, поддерживаемые компонентом Services for UNIX UNIX-реализация
Описание
HP-UX (Hewlett-Packard) IRIX (Silicon Graphics) Linux Digital UNIX Solaris (Sun Microsystems)
Основана на System V и включает некоторые средства BSD Включает функциональность System V R4.1 и R4.2 GNU; Posix-совместима; весь исходный код открыт Совместима с System V R3.2 и R4 Другое название SunOS 4.1..г (BSD с некоторыми средствами System V R4): Solaris 1.x включает SunOS 5_r, производную от System V R4
ПРИЛОЖЕНИЕ Б
Концепции взаимодействия с UNIX
693
Печать в UNIX UNIX предоставляет команды для отправки файлов на принтер. Если конкретный принтер не задан, используется принтер по умолчанию, Список определений принтеров содержится в файле /etc/printcap. Принтер по умолчанию можно указать и через переменную окружения (LPDEST в System V и PRINTER в BSD). Наиболее распространенные команды печати в UNIX перечислены в таблице Б-4. Таблица Б-4. UNIX-команды печати UNIX-команда
Реализация UNIX
Описание
cancel Ipstat Ip
System V System V Svstem V
Ipq
BSD
Ipl
BSD
Iprm
BSD
Отменяет запрос к сервису печати LP Сообщает информацию о состоянии сервиса печати LP Посылает запрос сервису печати LP Перечисляет задания на печать в очереди Посылает задание принтеру (поддерживается в Windows 2000) Удаляет задание из очереди печати
UNIX Man Любая версия UNIX поставляется с электронной документацией, где поясняются различные команды и процедуры. Документация оформлена как страницы руководства (manual pages). Каждая команда описывается на отдельной странице. Чтобы получить описание конкретной команды, введите в строке приглашения оболочки команду man имя команды.
П Р И Л О Ж Е Н И Е
В
Windows 2000 Resource Kit Deployment Lab
Лаборатория Windows 2000 Resource Kit Deployment Lab создана для того, чтобы протестировать и задокументировать различные сценарии развертывания Windows 2000. Эти сценарии демонстрируют, как планировать развертывание операционной системы Windows 2000 и конфигурировать ее в корпоративной сетевой среде. Кроме того, в данном приложении дается информация о Web-узле Windows 2000 Resource Kit Deployment Scenarios и об оборудовании, которое используется в лаборатории Windows 2000 Deployment Scenarios Resource Kit Lab. В этом приложении Web-узел Windows 2000 Resource Kit Deployment Scenarios Партнеры лаборатории Resource Kit Deployment Lab 695 Маршрутизаторы
694
695
Коммутаторы 698 Серверы 699 Настольные компьютеры 701 Портативные компьютеры 702
Web-узел Windows 2000 Resource Kit Deployment Scenarios Группа Windows 2000 Resource Kit поддерживает Web-узел Windows 2000 Resource Kit Deployment Scenarios, на котором документируются сценарии развертывания Windows 2000, протестированные в лаборатории Resource Kit Deployment Lab. Эти сценарии разработаны в сотрудничестве с группами разработки и тестирования Windows 2000. Оборудование для лаборатории было предоставлено ведущими компаниями в области сетевых продуктов, в том числе Cisco, Compaq и Intel. Web-узел
,0*^' **
>^
-^ov->
Со^е^^
.,^0**-*
v-v^
,<л
fi
ПРИЛОЖЕНИЕ В Таблица В-3.
Windows 2000 Resource Kit Deployment Lab
697
(продолжение)
Гонконг, OSPF-область 4
Сиэтл, OSPF-область О
Сан-Хосе, OSPF-область б
Взаимодействие с Windows 2000
Cisco 7505, 5-слотовыЙ, 1 CyBus, 1RSP1 RSP Flash Credit Card: 20 MB Option RSP 128 MB DRAM Option Cisco 7505 Route Switch Processor 2-Port Ethernet Interface Processor 4-Port Serial Interface Processor Dual Serial Ports ATM Interface, SONET/SDH Multimode, 155 Мбит/с Cisco 7505, 5-слотовый, 1 CyBus, 1RSP1 Шасси 7505 и блок питания RSP Flash Credit Card: 20 MB Option RSP 128 MB DRAM Option Cisco 7505 Route Switch Processor 6-Port Ethernet Interface Processor 2-Port Fast Ethernet Interface Processor (100TX) HSSI Interface Processor Multi-Channel Interface Processor Tl/PRI 2-Port Cisco 7505, 5-слотовый, 1 CyBus. 1RSP1, 1 Шасси 7505 и электропитание от сети переменного тока Cisco 7505 Route Switch and Processor RSP Flash Credit Card: 20 MB Option RSP 128 MB DRAM Option 6-Port Ethernet Interface Processor 2-Port Fast Ethernet Interface Processor (100TX) HSSI Interface Processor -1-Port Serial Interface Processor Dual Serial Ports Многопротокольная маршрутизация, пересылка группового трафика, IPSec, Quality of Service, SNMP, Cisco Network Services for Active Directory
Маршрутизатор Cisco 3600 Маршрутизатор Cisco 3600 — многофункциональная платформа, которая поддерживает маршрутизацию между филиалами и центральным офисом, все виды удаленного доступа, маршрутизацию ATM, LAN-LAN и мультисервисные приложения. Таблица В-4. Маршрутизатор Cisco 3600 Местонахождение лаборатории Resource Kit Количество Операционная система Аппаратная конфигурация Атланта, OSPF-область 5
Атланта, OSPF-область 5 Сан-Хосе, OSPF-область б 2
Cisco Internet Operating System (IOS) V.12.0.4T Enterprise Edition Cisco 3600, 2-слотовый модульный маршрутизатор с программным обеспечением IP (см. след, стр.)
698
ЧАСТЬ б
Таблица В-4.
Приложения (продолжение)
Сан-Хосе, OSPF-область 6
Взаимодействие с Windows 2000
8-to-32MB Flash Factory Upgrade for Cisco 3600 32-to-64 MB DRAM Factory Upgrade for Cisco 3620 2 Ethernet 2 WAN Card Slot Network Module i-Port Serial WAN Interface Card 1-Port Tl/Fractional Tl DSU/CSU WAN Interface Card 1-Port T1/Fractional Tl DSU/CSU WAN Interface Card 1-Port Fast Ethernet Network Module (TX Only) Cisco 3600, 2-слотовый модульный маршрутизатор с программным обеспечением IP 8-to-32MB Flash Factory Upgrade for the Cisco 3<>00 32-Ю-64 MB DRAM Factory Upgrade for the Cisco 3620 1-Port Fast Ethernet Network Module (TX Only) 32 Port Asynchronous Module Многопротокольная маршрутизация, пересылка группового трафика, IPSec, Quality of Service, SNMP, Cisco Network Services for Active Directory
Коммутаторы В следующих разделах содержится информация о предоставленных коммутаторах.
Коммутатор Cisco Catalyst 6000 L3 Коммутатор Cisco 6000 — платформа многоуровневой коммутации (multilayer switching platform) для сетей кампусов (campus networks). Он разработан в ответ па растущие требования к пропускной способности, высокой готовности к работе, многоуровневой коммутации в сетевых магистралях и распределенных сетях (backbone/distribution), а также к агрегации серверов (server aggregation). Таблица В-5. Коммутатор Cisco Catalyst 6000 L3 Местонахождение лаборатории Resource Kit Количество Операционная система Аппаратная конфигурация
Взаимодействие с Windows 2000
В Сиэтле 3 штуки, в Милане 1 штука
Cisco Internet Operating System (IOS) V.12.0.4T Enterprise Edition Шасси Catalyst 6006 Catalyst 6006 with 2 x 8 port Gigabyte Ethernet Catalyst 6000 Supervisor Flash Image, Release 5.2(1) Catalyst 6000 Supervisor Engine 1, 2 Gigabyte Ethernet Catalyst 6000 Supervisor PCMCIA Flash Memory Card, 24MB Option Catalyst 6000 8-port Gigabit Ethernet Module Catalyst 6000 48-port 10/100 MBs RJ-45 Module 1000BASE-SX «Short Wavelength* (Multimodc only) Catalyst 6000 Multilayer Switch Module Catalyst 6000 MSM IP/IP-Multicast Routing Feature Set Поддержка 802.1Р
ПРИЛОЖЕНИЕ В Windows 2000 Resource Kit Deployment Lab
699
Коммутаторы Cisco Catalyst серии 3500 XL Cisco Catalyst серии 3500 XL — масштабируемый 10/100 и гигабайтный коммутатор, который обеспечивает непревзойденную производительность, управляемость и гибкость. Он позволяет управлять всеми коммутируемыми Cisco-портами с единственного IP-адреса и предоставляет взаимосоединенные коммутаторы е независимой высокоскоростной стековой шиной (stacking bus). Таблица В-6. Коммутатор Cisco Catalyst 3508G XL Местонахождение лаборатории Resource Kit Количество Операционная система Аппаратная конфигурация
Взаимодействие с Windows 2000
Токио, Ванкувер, Бостон, Севиль 4 Cisco Internee Operating System (IOS) V.12.0.4T Enterprise Edition 8-портовыс стекируемые (stackable), масштабируемые коммутаторы 10, 100 и Gigabyte Ethernet 4 Мб разделяемой памяти Встроенные 8 Мб DRAM и 4-мегабайтная плата фл:инпамяти Gigabyte Interface Card (GBIC) Поддержка 802.1Р, 802.1 Q
Серверы В следующих разделах содержится информация о предоставленных серверах.
Сервер Compaq Proliant 5500 LAN Этот сервер предназначен для корпоративных приложений повышенной ответственности. Он рассчитан па приложения, работающие в филиалах предприятий или в центрах обработки данных. Его можно монтировать в стойки или использовать как отдельно стоящий системный блок. Сервер ProLiant 5500 обеспечивает повышенную отказоустойчивость и предоставляет средства быстрого восстановления после сбоев. За более подробной информацией о технологиях Compaq обращайтесь на Web-узел Compaq (http://www.compaq.com). Таблица В-7. Сервер Compaq ProLiant 5500 LAN Количество Центральные процессоры Память Дисковая подсистема Адаптер хост-шины Слоты Порты
6 Два Intel Pentium Pro с тактовой частотой 200 МГц 128 Мб ЕСС Protected EDO RAID-массив уровня 5 Wide Ultra SCSI, Wide-Ultra SCSI-3 3 EISA/5 PCI 2 последовательных, 1 параллельный
Сервер Compaq ProLiant 2500 LAN Этот сервер предназначен для сетей отделов и удаленных офисов, требующих высокого уровня доступности (готовности к работе). Сервер ProLiant 2500 можно монтировать в стойки. Он предоставляет обширные возможности в управлении и
700
ЧАСТЬ 6
Приложения
средства автоматического восстановления сервера (ASR-2), которые отслеживают функционирование сервера и в случае критического сбоя возвращают его в полностью работоспособное состояние. Таблица В-8. Сервер Compaq ProLiant 2500 LAN Количество Центральные процессоры Память Дисковая подсистема Хост-адаптер Слоты
6 Один Intel Pentium II с тактовой частотой 200 МГц 128Мб RAID-массив уровня 5 32-битный контроллер Fast-Wide SCSI-2/E. один — с Fiber Array 4 EISA/2 PCI
Сервер Compaq ProLiant 850R LAN Этот сервер предназначен для средних и крупных предприятий, которым нужен монтируемый в стойку сервер для Интернета/интрасети, приложений шлюза и доступа к файлам и принтерам. Он предоставляет средства автоматического восстановления сервера (ASR-2), которые отслеживают функционирование сервера и в случае критического сбоя возвращают его в полностью работоспособное состояние. Таблица В-9. Сервер Compaq ProLiant 850R LAN Количество Центральные процессоры Память Дисковая подсистема Хост-адаптер Слоты
28 Один Intel Pentium с тактовой частотой 200 МГц 128 Мб RAID-массив уровня 1 Embedded Wide-Ultra SCSI-3, Wide Ultra SCSI 2 ISA, 5 PCI
Сервер Intel Quad Pentium LAN Этот сервер содержит 4 процессора Intel Pentium с тактовой частотой 200 МГц. Он предназначен для создания корпоративных решений повышенной ответственности. Такие серверы могут работать с приложениями, используемыми в филиалах или в центрах обработки данных, так как обеспечивают высокий уровень готовности к работе. Наиболее оптимальны для серверов Intel Quad Pentium LAN приложения типа Microsoft SQL Server1" и Microsoft Exchange Server®. За более подробной информацией о технологиях Intel обращайтесь на Web-узел Intel (http://www.intcl.com), Таблица В-10. Сервер Intel Quad Pentium LAN Количество Центральные процессоры Память Дисковая подсистема
2 Четыре Intel Pentium с тактовой частотой 200 МГц 1 Гб RAID-массив уровня 5
Сервер Intel Dual Pentium LAN Этот сервер содержит 2 процессора Intel Pentium с тактовой частотой 200 МГц. Он предназначен для создания корпоративных решений повышенной ответственное-
ПРИЛОЖЕНИЕ В
Windows 2000 Resource Kit Deployment Lab
701
ти. Такие серверы обеспечивают высокие уровни готовности к работе. Наиболее оптимальны для серверов Intel Dual Pentium LAN приложения типа SQL Server и Exchange Server. Таблица В-11. Сервер Intel Dual Pentium LAN Количество Центральные процессоры Память Дисковая подсистема
18 Два Pentium с тактовой частотой 200 МГц 128 Мб RAID-массив уровня 5
Настольные компьютеры В следующих разделах содержится информация о предоставленных настольных компьютерах.
Compaq Deskpro серии 4000 Compaq Deskpro серии 4000 — надежные компьютеры для работы в сетевой среде. У них имеются интегрированные сетевые адаптеры и усовершенствованные средства Intelligent Manageability. Они также поддерживают новую технологию предсказания сбоев и снабжены дополнительными средствами зашиты, которые упрощают управление этими компьютерами в сетевой среде. Таблица В-12. Compaq Deskpro 4000 Количество Центральный процессор Память Дисковая подсистема Хост-адаптер Слоты
10 Intel Pentium с тактовой частотой 233 МГц 128 Мб Жесткий диск емкостью 3,2 Гб с интерфейсом ATA/IDE Встроенный IDE-контроллер 1 ISA, I ISA/PCI, 2 PCI
Compaq Deskpro серии 6000 Compaq Deskpro серии 6000 предназначен пользователям, предъявляющим более высокие требования к компьютерному оборудованию. Компьютеры этой серии оборудованы оперативной памятью ЕСС SDRAM для большей производительности и отказоустойчивости. Они также поддерживают новую технологию предсказания сбоев и снабжены дополнительными средствами защиты, которые упрощают управление этими компьютерами в сетевой среде. Таблица В-13. Compaq Deskpro 6000CDS Количество Центральный процессор Память Дисковая подсистема Хост-адаптер Слоты
5 Intel Pentium с тактовой частотой 300 МГц 128 Мб Жесткий диск емкостью 4,3 Гб с интерфейсом АТА/ШЕ Встроенный ATA/IDE-контроллер и контроллер Fast SCSI-2 3 ISA/PCI
702
ЧАСТЬ 6
Приложения
Таблица В-14. Compaq Deskpro EN 6400 Количество Центральный процессор Память Дисковая подсистема Хост-адаптер Слоты
10 Intel Pentium II с тактовой частотой 400 МГц 64 Мб Жесткий диск емкостью 3,2 Гб Встроенный ATA/IDЕ-контроллер 1 AGP, 2 ISA/PCI, 2 PCI
Таблица В-15. Compaq Deskpro EN 6300 Количество Центральный процессор Память Дисковая подсистема Хост-адаптер Слоты
11 Intel Pentium с тактовой частотой 300 МГц 64 Мб Жесткий диск емкостью 3,2 Гб Встроенный АТА/ГОЕ-контроллер 2 ISA/PCI, 2 PCI
Портативные компьютеры В следующих разделах содержится информация о предоставленных портативных компьютерах.
Compaq Armada серии 4000 Компьютеры Compaq Armada серии 4000 оборудованы процессорами Intel Pentium ММХ с тактовыми частотами до 266 МГц, жесткими дисками емкостью до 4 Гб, 32 Мб оперативной памяти типа SDRAM и CTFT-матрицами размером 12,1 дюйма с разрешением 800 х 600 и поддержкой до 16 миллионов цветов. Эти компьютеры имеют 64-разрядную локальную PCI-шиыу для видео. Таблица В-16. Compaq Armada 4210 Количество Центральный процессор Память Жесткий диск Хост-адаптер
3 Intel Pentium ММХ е тактовой частотой 233 МГц 64 Мб 3,2 Гб Встроенный ATA/IDE-контроллер
Compaq Armada 1700 Series Компьютеры Compaq Armada серии 1700 оборудованы процессорами Intel Mobile Pentium II с тактовыми частотами до 400 МГц, жесткими дисками емкостью до 10 Гб с поддержкой технологии SMART, 24-х скоростными приводами CD-ROM, 64 Мб SDRAM и CTFT-матрицами размером 14,1 дюйма. Эти компьютеры имеют интегрированный адаптер АС, интегрированный модем и привод для гибких дисков.
ПРИЛОЖЕНИЕ В Windows 2000 Resource Kit Deployment Lab
703
Таблица В-17. Compaq Armada 1700 Количество Центральный процессор Память Жесткий диск Хост-адаптер
3 Intel Pentium II с тактовой частотой 233 МГц 64 Мб 4 Гб Встроенный АТА/ШЕ-контроллер
Compaq Armada серии 7700 Компьютеры Compaq Armada серии 7700 оборудованы процессорами Intel Mobile Pentium MMX с тактовыми частотами до 266 МГц, оперативной памятью EDO до 32 Мб, CTFT-матрицами размером до 13,1 дюйма с разрешением 1024 х 768, поддержкой до 16,8 миллионов цветов и локальной графичеекой шиной, стандартной для моделей 7770. Таблица В-18. Compaq Armada 7770 DMT Количество Центральный процессор Память Жесткий диск Хост-адаптер
3 Intel Pentium MMX с тактовой частотой 233 МГц 64 Мб 3,0 Гб Встроенный АТА/ШЕ-контроллер
Compaq Armada серии 7800 Компьютеры Compaq Armada серии 7800 оборудованы процессорами Intel Mobile Pentium II с тактовыми частотами до 400 МГц, 64 Мб SDRAM, стандартным приводом DVD-ROM, AGP-шиной с графическим контроллером S3ViRGE/MX с 4 Мб видеопамяти и CTFT-матрицами размером до 14,1 дюйма с разрешением 1024 х 768 и поддержкой до 16,8 миллионов цветов. Таблица В-19. Compaq Armada Model 7800 Количество Центральный процессор Память Жесткий диск Хост-адаптер
3 Intel Pentium II с тактовой частотой 266 МГц 64 Мб 5,0 Гб Встроенный АТА/ШЕ-контроллер
Предметный указатель 802.1р 631 802.2 DLC 671
А
АААА 32 AAL 575-577 ABR 581 АСЕ 468 ACF/NCP 673 ACID 686 Active Directory 627 ADSL 219-220 A DSP 535 AFP 535, 544 AFTP 428, 433 ANI/CLI 283 APIPA 278, 395 APPC 425,681-682 — передача файлов 427 — приложения 426 — стратегии развертывания 429-430 Apple Standard UAM 533 AppleShare 561 AppleTalk 29, 533-535, 543 — архитектура протоколов 534 — пример сети 537 AppleTalk Phase 2 533, 536 APPN 677-681 — конечные узлы 680-681 — сетевой узел 679-680 ARP 592 ASP 535 АТСР 244, 533, 561 — параметры 244 ATM поверх ADSL 219 — соединение 220 ATM 568-617 -TAPI 599-600 — адресация 582-583 — архитектура 573-576 — диспетчер вызовов 597 — коммутатор 569 — идентификатор 582 — предотвращение несанкционированного доступа 614-615 — коммутация на различных уровнях 580 — мультиплексирование и демультиплексирование 575 - обзор 568-572 — проблемы с соединениями 615-617 — сигнальные интерфейсы 584 - скорость передачи 572-573 - службы 594-596 — создание логических IP-подсетей 612-613
— типы соединений 583-585 — ячейки 572-573 — структура 577-578 ATMARP "589-590, 592, 598 АТР 535
В
ВАСР 268, 271 — параметр Favored-Peer 271 ВАР 202-203, 268, 270-271 — LCP-параметры 270 Bash 477 BGP 21 Bourne 477 BSD 692 BUS 586-587
С
CBCP 241 — параметры 241-242 CBR 581 ССР 245, 660 — параметры 246 CHAP 255-256, 306 — включение 307 Chooser 562-563 CIFS 505-507 Client Service for NetWare 491, 503-504, 507-509 — установка 512-513 Component Builder 448 COMTI 448-449, 451 COMTI Runtime 448 CoNDIS 598-599 Configuration Support Program 673 CPCS 576-577 С PI-С 426 CTI 619
D
DDM 684 DDP 534 DIM 32 Directory Service Manager for NetWare 492 Directory Services Migration Tool 492 DirectShow 601 Direct Stream ing 601 DLC 659-664 — излтенСЕше приоритета привязок 661 - установка 660 DNIS 283 DNS-прокси 102 DRDA 445, 684 DSAP 648 DTC 451 DVMRP 122, 639
Предметный указатель
Е
Е.164 583 ЕАР 258, 300, 309 - SDK 286 — включение 310 EAP-MD5 258-259 EAP-MD5 CHAP 309 EAP-RADIUS 259, 309 EAP-TLS 221, 259,309 ЕСР 246 EGP 20-21 EHLLAPI 434 EHNAPPC 435 Emulated LAN (ELAN) 586 — по умолчанию 603 — состояния 608
F PCS 235 FEP 670, 673 File and Print Services tor NetWare 492 File Services for Macintosh 533, 543, 545 Framed-MTU 337 FTP-AFTP Gateway 428-429
G
Gatekeepers 630 Gateway Service for NetWare — установка 510 GRE 354 — заголовок 354
491,503,505-506
H H.245 628 H.323 623, 626-629 — ВЫЗДН
— прием 626 — через адресную книгу 626 - через брандмауэры 629-630 — проблемы 637-641 НЕС 574, 579 HLLAPI 434 НМАС 364 Host Account Cache- 442 Host Account Synchronization Service
I IBM Channel 670 IBM CICS 450, 687 IBM NetVicw 457, 687-689 IBM Networking Blueprint 683 IBM SNA 662, 666-689 — архитектура 668-669 — сеансы 676 — сети — иерархические 420. 668-672 — одноранговые 425, 668 — функциональные уровни 674-675 ICMP — заголовок 105 — типы и коды 105-106 IGMP 28.34, 124, 128 - v l 124-125 сообщения 124
143
705
- v2 38, 126-128 — сообщения 126 — регистрация событий 147 — режим IGMP-маршрутизатора 129-131 - режим IGMP-прокси 131 - 133 - трассировка 117 IGP 20 IGRP 20 1LM1 587 — присоединение 615 IMS 687 inode 462, 467 Internet Authentication Service 281-339 - SDK 286 — авторизация 314-316 — аутентификации 294--301 - централизованная 282-283 — интеграция со службой маршрутизации и удаленного доступа 285 — мониторинг производительности сервера 333 — настройка и оптимизация 332 — поведение -в Windows 2000 331 -в Windows NT 4.0 330 — проблемы 333-338 — тунполирование 301-305 — учет 327-331 — централизованная апторизация 283-284 — централизованное администрирование серверов удаленного доступа 284 — централизованный аудит и учет 285 IP — групповая рассылка 115-147, 631 — информации о членстве хостов в группах 122 • ограничители 28. 133-134 особенности 116 — поддержка хостом 118-119 — пульс 134-135 — регистрация хоста в группе 273 — средства диагностики 143-147 — статистика 144 — заголовок 104-105 - пересылка группового трафика 28, 121, 273-274 - для клиентов удаленного доступа 140-141 - для сетей филиалов 142-143 — через Интернет 273 — через интрассть 274 — подсеть 593 — телефония 603 -па основе 11.323 626-628 — фильтрация пакетов 28, 49. 103-108 — и фильтрация ЕТР-трафика 109-110 — и фильтрация Е2ТР-трафика 111 — и фильтрация РРТР-ирафика 110-11 I — и фильтрация Web-трафика 109 — локального хоста 108-109 — отклонение фальсифицированных 112 IP Multicast 28 IP Multicast Conferencing 641 IP Router Manager 33
706
Предметный указатель
ТР поверх ATM 612-6H IPCP 242-243 — параметры 243 IPSec 193 — Tunnel Mode 16 — аутентификация — компьютеров 363 — на основе сертификатов 373 IPX 28-29. 493-494 — внутренний интерфейс 166 — внутренняя сеть 165-166 — демультиплексирование пакетов 152-153 — заголовок 150-151, 494 — маршрутизация 39, 148-176 — соединения по требованию 204 — сокеты (отличие от сокетов Winsock 2) 15 — структура пакетов 494 — фильтрация пакетов 28, 149-156 — фильтр — входной 155 — выходной 156 IPX Router Manager 33 IPX Tunneling for Novell NetWare 15 IPX WAN 204 IPX WAN Broadcast 172-173 IPXCP 243-244 — параметры 244 ISDN 218
К
Korri 477 — встроенные команды 481 — команды оболочки для программирования 480 — метасимволы оболочки 479 I
L2F 357 L2TP 16,357-358 — аутентификация па уровне пользователей 363 — соединения 357 — управляющие сообщения 358-359 L2TP поверх IPSec — соединения 363-364 — трафик 385 — фильтрация пакетов 364 — настройка 389 шифрование 364 LAN Emulation (LAME) 585-588 LaserPri'p Wars 558 LCN 578 LCP 237 - пакеты — структура 237 - типы 238 — параметры 238-239 — процесс согласования 240-24 1 LDAP 636 LECS 586 LES 586-587 Linux 692 LLC 802.2 660 LLC 646, 648
Local Traffic Control 631 LocalTalk 536, 540-541 LSA 66 LSDB 67-68 — синхронизация через механизм соседства 73-74 — уменьшение размера 81 LSN 653-654 LU 669, 673-674. 678 - 6.2 682 - АРРС 430 — выделение рабочим станциям 422 — зависимые 682 — независимые 429, 682 - п у л ы 421 — типы 420
м
Macintosh Finder 544 Macintosh Port Monitor 556 MacPrint 556 MADCAP 118,634 MARS 589-590, 612 MBone 123-124, 138 MCS 590-591 Microsoft Client for NFS 463-464 Microsoft RAS 220 Microsoft Server for NFS 461-462, 469 Microsoft SNA Server 400-458, 667-668 -APPC 425 - Host Print Service 435-437 — Host Security Integration 441-443 — автоматизация регистрации 444 - аутентификация 438-439 — выбор сетевых протоколов 418-419 — доступ к данным 403-404 — на хост-системах 444-447 — интс! рация — приложений 404 -405 — с сетями Windows 2000 411 — управления сетями 405, 455-456 — \-ост-снсгем с Web 451-452, 454-455 — модели развертывания 406-110 -обзор 401-402 — определение ролей 412 — поддержка брандмауэров 440-441 — поддомепы 411 - поддомепы в доменах Windows 2000 438 — сервисы интеграции сетей 402-403 — соединения с нижестоящими системами 424 — способы подключения 412-415 — к мэйнфреймовой системе 415-417 - к системе AS/400 417-418 •- типы сеансов связи с мэйнфреймами 433 — шифрование данных 140 MOSPF 122 МР 268-269 МРРС 236, 246 МРРЕ 193, 222. 236, 246, 362 MRU 235 MS-CHAP 307-308 - v1 256
Предметный указатель - v2 257. 308 — включение 309 MSP 621,624 MS-UAM 533 Multicast Group Manager 35 Multilink 202-203, 236, 268-269, 320 - LCP-параметры 269-270
N NAS 294-295 NAU 675-676 NBF (NetBIOS Frame) 645-647 -NDIS 647-648 - TDI 647 — возможности маршрутизации 656 — таймеры соединения 651 — установление сеансов 653-655 NBFCP 245 — параметры 245 NBFP 645-646 NBP 535 NCB 647 NCB CALL 654-655 NCB LISTEN 654 NCP 242 NCP Watchdog 204-205 NDISWAN 229, 600-601 NDS 513 — дерево 513 — каталогов 514 NetBEUI 644-658 — изменение приоритета привязок 657 — проблемы 656-658 NetBIOS 645 — заголовок 175 — распространение широковещательных пакетов 149 — статические имена 149, 176 — широковещание 172-174 NetBIOS поверх IPX 29, 497 — широковещание 14 — широковещательные пакеты 172 — структура 174 Network Address Translator 28, 49, 95-100, 102 -проблемы 102-103 — редакторы 97-98 Network Load Balancing 356 Network Monitor 212, 248, 280 Network Virtual Terminal 472 NFS 460-461. 464-466 — особенности архитектуры 467-468 — потоки 466 -редиректор 471 NNI 584 Novell NetWare 490-531 — 16-разрядные утилиты 517-518 — администрирование через Windows 200C 516-519 — атрибуты файлов в сравнении с Windows 2000 521 — доверительные права доступа 519-521 — контекст 43, 513 — права доступа к каталогам 520
707
— проблемы 525-531 — распознавание типа кадров 528 — сценарии регистрации 524 — утилиты и их эквиваленты в Windows 2000 519 NSAP 582 NVAlert 457 NWLink 491-493 — архитектура 493 — компонент пересылки трафика 497 — настройка 498 — служб шлюза и клиента 509-513 — номера сетей 501-502 — поддерживаемые типы кадров 500-501 — функция Auto Detect 498-499 — проверка включения 527
О
ODBC Driver for DB2 445. 685 OLE DB Provider 446-447 ONC-RPC 461 ONC-XDR 461 OSPF 20, 27, 34, 66-74, 76 — виртуальные каналы 84-85 — внешние маршруты 86-87 — главный маршрутизатор 77-79 — дублирующий 78-79 — маршрутизация между областями 83-84 — маршруты по умолчанию 87 -область 67, 80-81 — изолированная 87-89 — магистральная 82 — транзитная 84 — передача пакетов 80 — проблемы 89-91 — состояния интерфейса 79-80 ~ типы маршрутизаторов 82-83 — типы сетей 72 — уменьшение размера таблицы маршрутизации 81-82 — цена использования 66 Р
Packet Scheduling 631 PAP 254, 305, 535 — включение 306 Password Synchronization 473-475 Perl 488 PiggyBackAck 497 PIM 122, 639 PMD 574 PPP 220, 234-237 — идентификаторы протоколов 236 — инкапсуляция 234-236 — кадра 354 — на асинхронных каналах 236 — на синхронных каналах 237 — протоколы аутентификации 253-254 — процесс соединения 246-247 — согласование параметров - канала (LCP) 237-239 — ответного вызова (СВСР) 241 — сетевого уровня (NCP) 242
708
Предметный указатель
— специфика при использовании интерфейсов соединений по требованию 185 — трассировка 251-253 РРР поверх ATM 600 РРТР 15- 352-355 — обработка туннелированных данных 355 — соединения 362 — управляющие 352-353 — трафик 385 — управляющие сообщения 353 — фильтрация - пакетов 362-363 — настройка 388 Print Server for Macintosh 533, 555-559 — аутентификация при печати 556 — настройка сетевых принтеров 557-558 — предотвращение I.aserPrep Wars 558 — создании' ггулов печатающих устройств 560 Proxy ARP 232 PSTN 216-217 PU 669,671-672, 678-679 PVC 577 — отличия в управлении от SVC 597 - эффективное использование G13
Q
Q.931 627 QLLC гл. Х.25 Quality of Service
R
580-581
RADIUS 227-228, 259-260, 282, 286-287. 333. 351 - атрибуты 289-294 — вендоров, особые 290 — аутентификация 286-287 — поддержка РРР-протоколов аутентификации 305 — прокси 331 - учет 327 — формат пакетов 287-288 RCA-фильтр G01-602 Registration, Admission, and Status 627 Response Time Monitor 458 RIP 27 -vl 58-60 — в смешанной среде с RIP v2 63 — проблемы 59 — формат сообщении 58-59 - v2 60-63 — формат сообщений 61-63 — конвергенция 51 — соседство 64, 73 — конфигурационные параметры 74-75 — распространение информации 76 — универсальный запрос 57 — широковещательные оповещения 59 RIP for IP 20, 33. 50-58 -vl 58-60 - v2 60-63 -в Windows 2000 64-65 — инициализация 57 — инициируемые обновления 56
— проблема счета до бесконечности — разделение направлений 55 — с: запретом возвратов 55-56 — регулярное оповещение 57 — ускорение конвергенции 55 RIP for IPX 29. 34, 149, 156-160 — заголовок 159 инициализация 158 — регулярное оповещение 158 — структура пакетов 159-160 — фильтры маршрутов 160 — входящих 160-161 RIPX 495 — заголовок 496 RLIO 685 Route Table Manager 8, 34 RPC 460, 464-466 RRAS для Windows NT 4.0 23 RSVP 630 RTM 136 RTMP 29, 534 RIP 628
s
52
SAP 496 — заголовок 496 — на IPX-маршрутизаторе 168 — режимы работы 169 — службы 170 — статические 149, 171-172 - фильтрация 149. 170-171 SAP for IPX 29. 31 149. 163-166 — структура пакетов 169 SAR ',577 SDLC 458. 671 SDP G34-635 Services for Macintosh 532-565 — аутентификация 545-547 — зоны 538-539 - обзор 532-533 — планирование размещения маршрутизаторов 539-540 — сетевой среды 540-543 — проблемы 561-565 — процессор печати 556-557 — разрешения 547 — на доступ к файлам 547-549 — создание новых сопоставлений расширений с типами 554 — трансляция имен файлов Macintosh 549-551 Services for UNIX 459-488 — аутентификация PCNFSD 467 — блокировка файлов 470 - клиент и сервер Telnet 471 — кэширование файлов 470-471 — поддержка сценариев 488 — синхронизация паролей 460. 473-475 - утилиты UNIX 484-485 Shared Folders Gateway 429, 440 Site Server ILS Service 627. 634 SLIP 220 SXA Remote Access Service 431--432
Предметный указатель SKA Server Client 419 SNA Server Manager 455-456 SNA Server SDK 434 SNA Server Web Client 452-453 SNA Tunneling over IP Internetworks SNMP MIB 30 SNTP 135 Solaris 692 SPAP 255 SPX 493, 495 SPXIT 495 SSAP 648 SSCP 672 Stream I/O 685 SunOS 692 SVC 577, 584
Г
V 15
TAPI 33, 618-625 — архитектура 622-623 - версии '2.1 и 3.0 620-621 — использование служб каталогов Windows 2000 627 — компоненты 228 — поддержка Quality of Service 630 TAPI Server 622 ТС 574 TCP-заголовок 105 TCP/IP поверх ATM 589-594 Tcsh 477 ТШ-описатель 652, 654 Telnet 472 — безопасность 473 — функциональность 472 Telnet Client and Server 460 TLS 259 TP G82 - диспетчер 686 — монитор 686 — синхронизация в АРРС-сеансе 687 Triple DES 476 TSP 621 Twinax 679
и
UBR 581 UDP-заголовок 105 UX1 584 Unicast IP 27-28 UNIX 690-693 - vi 485-488 — корень 692 — оболочки 476-482 — печать 693 — реализации 692 — секция 474 - файловая система 690-691 - ядро 692 UNIX Man 693 L'NIX System V 692 UPN 329 User Manager 456
709
V.90 218 — и цифровые линии 217 Vanjacobsen Compressed TCP/IP 236 VBR 581 VC см. цепь, виртуальная VC Mesh 612 VCI 572, 578 VP1 572,577 VPN 340 397 -NAT 384-386 - брандмауэры 380- 384 — инкапсуляция данных 344 — клиент 342 - назначение адресов ч серверов имен 344-345 — определение 340 — проблемы 391-396 - сервер 29, 342 — соединения 342 — комбинированные (через Интернет и интрасети) 348 — между маршрутизаторами 186-188, 3i3, 369-370, 373 -сквозное 348,386-391 — удаленного доступа 343, 365-366 -через ISP 370-372 — через Интернет 345-346 — через интрасети 346-347 -- общий ключ 373-377 — раздельные общи*-' ключи 377-379 — cnoiicTBH 343-344 — управление 348 — адресами и серверами имен 349 — аутентификацией 351 — доступом 349-351 — пользователями 348 — сетью 351 — учетом 351 VSA' 291 - U.S. Robotics 323 VTAM 413. 672
w
WinllLLAPI 434 WUBR 581
X
X.25 218-219, 671 — интеллектуальные платы 219 XDR 460
z
7. IP
535
автономная система 19-20 — области 81 авторизация 25 - на основе AN1 312-313 — пример 313 — на основе DXIS 312 агент - SNMP 32
710
Предметный указатель
— ретрансляции DHCP 49, 91 - проблемы 94 адрес — групповой 116-117 — на уровне MAC 117 — локально управляемый 662 — межсетевой 4 — перекрывающийся 368 — пересылочный 9 — сетевого адаптера (изменение) (563 — сети 3 — хоста 3 алгоритм — адаптивной подстройки окон 651 — Дейкстры 66, 69 атака, сетевая — подмена клиента удаленного доступа 254 — подмена сервера удаленного доступа 254 - с повторением пакетов 254 аутентификация 25, 61 - Ь2ТР-туннеля 363 - RIP v2 63 -взаимная 192,22] - гостей 260, 283 — защищенная 221 — на уровне компьютера 192 — на уровне пользователя 191 — односторонняя 192 — отличия от авторизации 25 — средствами L2TP поверх IPSec 364 -средствами РРР 3G2 аутсорсинг 283
Б
бит - CLP 579 -EFCI 579 — признак группового адреса брандмауэр 331-332,380
120
В
вектор расстояний 17 время конвергенции 16 вызов, ответный 222, 247
Г
группа передачи
д
676
демон 50 — iiuuinld 467 - pcnfsd 464 - PCNFSD 467 - portmapper 4G5 — ssod 474-475 - ttnlsvr 472 дерево SPF 69-71 — вычисление .записей таблицы маршрутизации 70 диалоговое окно -Add IPX Filter (Добавление IPX-фильтра) 155 Automatic Dialing and Automatic Hanging Up 203
- Client Service for NetWare (Служба клиента для сетей NetWare) 513 - Configure Gateway (Настройки шлюза) 506, 512 - Gateway Service for NetWare (Служба шлюза для NetWare) 511 - Input Route Filter (Фильтры входящих маршрутов) 161 — Input Service Filters (Фильтры входящих служб) 171 — IPX Packet Filters Configuration (Конфигурация фильтров IPX-пакетов) 154 — Log on to Windows (Вход к Windows) 504 — Route Filter (Фильтр маршрутов) 163 - Service Filter (Фильтр служб) 171 — Static NetBIOS Name (Статическое имя NetBIOS) 176 - Static Route (Статический маршрут) 162 - Static Services (Статические службы) 172 диспетчер - TP 686 — динамических интерфейсов 32, 184 — соединений 32 домен — иерархический 676-677 — маршрутизации 19 - основного режима 328-32У — смешанного режима 329 доставка - непрямая 5 — прямая 5 доступ - к мэйнфреймам IBM 683-684 - к системам AS/400 684 - к томам NetWare 522-523 - неаутентифицируемый 310 — пример 311 - удаленный 29 — аутентификация через RADIUS 227 - аутентификация через Windows 227 — аутсорсинговый 283 — на основе параметров учетной записи 225 — на основе политики 225-226 — но коммутируемым линшш 215 — управление учетом 228 --через VPN "215 — шифрование данных 221-222 драйвер — DLC (параметры в реестре) 661 — IP-фильтрации 35 -• IPX-фильтрации 35 -NDISWAN 228 - ODBC 446 компонента пересылки IPX-трафика 35 задержка 9 — установления соединения
И идентификатор - протокола 235 - сети 9
I. .
Предметный указатель
м
идентификация звонящего 222. 316 имя, полное составное 511 интерфейс 9 - Internal (Внутренний) 140 -IP-B-IP 135-136 — предыдущего перехода 136 — соединения по требованию — подключение вручную 189 — фильтрация пакетов 193
К кадр - Class-II 650 - Ethernet 802.2 501 -Ethernet II 501 — FindName 650 — Informational 650 — NameQuery 653-654 — Receive Ready 650 - Reset NCB 655 — Session Confirm 650 - Session Initialize 650 — Set Asynchronous Balance Mode Extended - SNAP 501 -Token Ring 802.5 501 — Unnumbered Acknowledgment 650 канал — виртуальный 579-580 — состояние 17 каталог, основной 691 клиент - RADIUS 30 — удаленного доступа 216 кодек 628 команда - alias 482 — capture 530 - cd 691 — chmod 468 - ex 530 — ipxroute config 499, 525 - Is 469 — mount 463 — mrinfo 145-146 — net use 650 — net view 523 -netsh 146-147 - pwd 691 — rlogin 474 — rpcinfo 465 - sh 477 — showmount 467 — unalias 482 компонент — авторизации, дополнительный 301 — пересылки IP-трафика — группового 35 — одноадресного 35 конференция 631 — многосторонняя 632-633 — проблемы 637-641 — модель безопасности 635
650
711
маршрут — варьирование 82 — к сети 8 — к хосту 8 — по умолчанию 6, 8 — VPN-соединения через Интернет 367 — причина недостижимости 184, 210-211. 397 — процесс обнаружения 6-7 — срок действия 10 — статический -IPX 149,162 — многоадресный 136-137 — создание вручную 197 — фильтрация 64 - IPX 149 маршрутизатор 3 -DHCP 91-92 — распределитель 100, 102 — Ethernet/LocalTalk 541-542 - IP 48-49 — уровни предпочтений 50 -IPX 148-149 — RIP (неавторизованный) 60 -Windows 2000 149 — аппаратный 3 — внутренЕшй 82 — вызывающий 182-183 — настройка параметров постоянного подключения 180 — граничный — автономной системы 83 — области 83 — группового IP-трафика 119-120 — динамический 16 — инициирующий 535-537 — код 68 — магистральный 83 - многопротокольный 24 — настройка на поддержку группового трафика 639 — обнаружение средствами ICMP 28, 49, 113-114 — отвечающий 183-184 — настройка параметров постоянного подключения 180 — отличия от мостов 14 — приоритет 77 — программный 3 — с поддержкой соединения по требованию 24 — состояния отношений соседства 74 — типа «черная дыра* PMTU 13-14 — фильтрация равноправных 64 маршрутизация 4 — динамическая 11 — инфраструктура 18-19 — иерархическая 19 — многопутевая 19 — однопутевая 18 — плоская 19 - источника 7
712
Предметный указатель
— маршрут по умолчанию для подключения по требовании! 198 — маршрутизатором i, 7-8 — метод Framed-Routing 33(i — многоадресная 38, 123 — одноадресная 2-21, 36 — определение оптимального маршрута G — петля 12-13 — проблемы 12-13 — с соединением по требовании) 29, 177-212 — аутентифи кация 191-192 — определение 178 — проблемы 205-210 — процесс 184-186 — удаленный доступ 179 — шифрование 193 — средства диагностики 210-211 — статическая 11 — хостом 5 мастер — Add Primer Wizard (Мастер установки принтеров) 663-664 — Demand-Dial Wizard (Мастер интерфейса вызова по требованию) 194, 202 метрика 9 мини-АТС, компьютерная 620 м инипорт-драйвер - ATM ND1S 5.0 598 - WAN 228 модуль эмуляции LAN 597
н
надежность 10 номер -сети 152, 164, 170,502-503 — внутренней (изменение) 499-500 - сокета 152, 170 - у;)ла
170
О
обновление, автоматическое объект — Rendezvous
199-201
631
— конференции 634 окно — передачи 65! — приема 651 оснастка Routing and Remote Access (Маршрутизация и удаленный доступ) 30, 41-42 — таблица - lGMP-1-рупп 145 — групп ЮМР-иптерфейса 145 — многоадресной пересылки 144 ответчик, голосовой интерактивный 620
п
пакет -Access-Accept 293, 301 - Access-Request 287, 291 Accounting-Request 327 — Configuration-Request 252 — анализ 253 — Database Description 76 - Hello 77
- IPX WAN Broadcast 173- 174 Link Slate Request 73, 76 - Link State Update 73-74, 76 -NCP Watchdog 204 — к клиентам удаленного доступа 231 - от клиентов удаленного доступа 230-231 параметр реестра - AddNameQueryRetries 649 — AddNameQuery Timeout 649 Allow LM Authentication 308 - Default User Identity 296, 311 - DefauftDomain 299. 333 - DefaultTlTimeout 651 - DefaultT2Timeout 651 - DefaultTiTimeout 651 - DNSNameServers 262 - EnableMuIticastForwarding 121 - FirstWanNode 265 - InitialAddressPoolSize 261 — LogFileName 604 - LogFlags 604 - MaxDenials 223 - MaxIncomingFrames 651, 658 - NameQueryRetries 649 - NameQucryTimeout 649 - Override User-Name 313 Ping User-Name 296 - ProhibitlpSec 37!) - ResetTime 223 SuppressDNSNameServers 262 - Suppress\\TNSNameServers 262 - User Identity Attribute 296, 313 - Wan NameQueryRetries 652 - WINSNameServers 262 пересылка, многоадресная (конфигурации) 137-140 подключение — многоканальное 320 постоянное 180,201-202 - устанавливаемое по требованию 180, 197 подобласть 676-677 политика удаленного доступа 225, 265-266. 314 - административные модели 324-327 — локальное и централизованное управление 314 - - по умолчанию 321 - принятие запроса на соединение 323-324 - - проблемы 267-268 -профиль 319-321 — элементы 317-319 привязка, сетевая 660 приложение - Phone Dialer 620, 626 - Weather Report 602 - управляющее 32 - центра обработки вызовов 619 провайдер сервисов 621 -Н.323 622-623 - NDlS-прокси 623 ТАР1 в режиме ядра 623 - Unimodem 5 623-624
Предметный указатель — для многоадресных конференций 623 — удаленных 623 программа, трапзакциопная см. ТР проелушиваиие 6 — режимы 120 протокол — групповой IP-рассылки 34 — маршрутизации 16 — многоадресной 123 — па основе векторов расстояний 17 — на основе состояния каналов 18 - одноадресной 113-34 — тупнелирования 342 — удаленного доступа 220 профиль вендора 321-323 путь - виртуальный 579-58Й — передачи 579 Р
растекание
С
68
связь, коммуникационная — не ориентированная па логические соединения 649 — ориентированная на логические соединения 650 сеанс - NetBIOS поверх IPX 172 -Tclnei -172 — логический 676 — максимальная продолжительность 319 сервер -RADIUS 227 — автономный 330 - удаленного доступа 24, 214-280 - IP-маршрутизация 230 — агент ретрансляции DHCP 2G4 — адреса DNS- и WTNS-серверов 262-263 — архитектура 228-229 -- включение гостевого доступа 311 — вход только в определенные дни и время 319 — вход только по определенному номеру 319-320 — гостевой доступ для РРР-клиентов 310 — механизм разрешения МАС-адреса LAXиптерфейса 231-232 - обработка запроса па соединение 266-267 — определение 216 — поддержка групповой IP-рассылки 271 273 — при наличии нескольких LAN-интерфейсов 262 — проблемы 274-278 — расписание исходящих вызовов 196 — свойства входящих звонков 315 — статический пуд П-'-адресов 2G1 сервис канала 413 сеть 3 — виртуальная частная aw. VPN — не ориентированная на логическиесоединения 570
713
с истема — конечная 3 — нижестоящая 424 — промежуточная 3 служба -Silent. RIP (Пассивный RIP) 59 — маршрутизации и удаленного доступа 22 -47 — архитектура 31 - 33 — включение и настройка 20 — изменение конфигурации 27 совместное использование Интернетсоединений 97 — трассировка 46-47 — удаление 27 соединение - инициируемое любой из сторон 181 — инициируемое только одной из сторон 181-182 — неаутснтифицируемое 260 - один-к-одному 584 — один-ко-многим 585 — от FEP к контроллеру кластера 671 — от мэйнфрейма к FEP 670-671 — по требованию (типы) 179 — разъединение при простое 319 сообщение — Access-Rejeri 300 -Callback-Request 270 - Call-Request 270 - Call-Response 270 - DHCPAck 93-94 -DHCPDiseover 92 -DHCPInform 2G4 - DHCPNack 94 - DHCPOffer 92-93 - DHCPRcquesL 93 - Host Membership Query 125-126 - Host Membership Report v2 126-127 - Host Membership Report 121-122, 125- 126 - Leave Group 127 - Rouier Advertisement 113 — Router Solicitation 113 способность, пропускная 10 среда - межсетевая 3 — транзитная 343 - OS PI- 82 ссылка, символьная 469-470 станпия связи 648 суперполкюватель 692 счетчик переходов 4, 12
Т табл нца -SAP 167 — маршрутизации 8-11 - IPX' 157 15В — динамическое обновление на хосте G — многоадресной 136 — па хосте G
— многоадресной IP-пересылки — пересылки 8
121
714
Предметный указатель
телемаркетинг 619 телефония - PSTN (проблемы) 636-637 — клиент-серверная 624 — средства интеграции с компьютером 619 терминал - 3270 420, 439, 684 -3278 684 -5250 426,439 - TN3270 422-423 -TN5250 426-427 — параметры IP 431 точка — входная 688 — доступа к сервису 648 — сервисная 688-689 — фокальная 688 транслятор сетевых адресов см. Network Address Translator трафик - изохронный 569 — межобластной 82 — транзитный 36, 39 — хоста, локальный 37, 39-40 — широковешательный межсетевого уровня 14 туннелирование 15 — данных 343 - средствами L2TP 359-360 — средствами РРТР 354 — принудительное 303 — произвольное 302 — типы 15-16 туннель 15, 342 -IP-B-IP 135
У
узел LEN 681 уровень шифрования 320-321 устройство, конечное 569 утилита -ATMADM 604-607 -ATMARP 610-612 -ATMLANE 608-610 - IPSecPol 380 - MCAST 639-640 — М trace 146 - Netsh 43-45 - Rasmon 190 учетная запись -NTGATEWAY 509,514-515 - блокировка 222-224. 299,332 Ф файл — .rhosts 476 — /etc/group 476 -/etc/hosts 474, 476 — /etc/hosts.equiv 476 - /etc/passwd 473. 475 — /etc/shadow 475 — Autoexec.ncf 499 - lo.sys 507 — Ipfltdrv.sys 35
- Iprip2.dll 33 - Iprtmgr.dll 33 - Ipxrip.dll 34 — Ipxroute.exe 515 - Ipxsap.dlJ 34 - Mprdim.dll 32 - Nbf.sys 647 - Ndis.sys 228 - Ndiswan-sys 228, 230, 248 - Netbios.sys 647, 655 -NetWare.drv 516 - NVAlert.ini 457 -Nwl6.exe 516 -Nwapii6.dll 516 -Nwapi32.dll 516 -Nwc.cpl 516 -Nwcfg.dll 516 — Nwdoc.hlp 516 — Nwdocgw.hlp 516 — Nwevent.dll 516 ~Nwln.kflt.sys 35, 515 — Nwlnkfwd.sys 35, 515 — Nwlnkipx.sys 495, 515 — Nwlnknb.sys 515 — Nwlnkspx.sys 515 -N\vnks.dll 516 -Nwrdr.sys 507, 515 — Nwscript.exe 516 - Ospf.dll 34 -Perfimdll 516 -Ppp.log 251 -profile.ksh 477-478 - Rtm.dll 34 — Srv.sys 507 - Tapi.dli 622 - Tapi32.dll 622 - Tapisrv.dll 622 — Tcpip.sys 35 — Vwipxspx 516 - журнала IAS 328 — трансляции 462 фильтр вызовов по требованию хост (присоединение к группам) хост-система IBM 401 хост-соединение 413 хостинг, прямой 173
Ч
цепь, виртуальная
Ч
число переходов
ш
195-196 139
571-572
9
шлюз -IP-PSTN 629 - NetBIOS 233-234
3
элемент - логический 669, 673-674, 678, 681 - физический 669, 671-672, 678-679
Acquisitions Editor: Juliana Aldous Project Editor. Maureen Williams Zimmerman Department Managers: Paul Goode, Ken Western Documentation Managers: Laura Burris, Martin Del Re, Peggy Etchevers Resource Kit Program Managers: Chris Hallum, Martin Holladay, Louis Knhn, Ryan Marshall, Paul Sutton Technical Writing Lead: Martin Del Re Routing and Remote Access Technical Writing Lead: Joseph Davies Writers: Wolfgang Baur, Joseph Davies, Martin DelRe, Grant Fjermeda), Glenn Geignetter, Victor Goltsman, Leo Gruzman, Mario Matiev, Judith Meskill Editing Leads: Deborah Annan, Jennifer Hendrix, Kate O'Leary Book Editing Lead: Susan F. Sarrafan Developmental Editor, Gary W. Moore Copy Editors: Kate McLaughlin, Mary Ruse Sliwoski, Scott Somohano, Debbie Uyeshiro Clossary: Daniel Bell Resource Kit Tools Software Developers: Dan Grube, Mirhael Hawkins, Darryl Wood. Zeyong Xu Documentation Tooh Software Developers: Amy Buck, Tom Carey, Ryan Farber, Mark Pengra, Fred Taub Production Leads: Sanely Dean, Jane Dow, Keri Grassl, Jason Hershey Production Specialists: Michael Faber, Dani Mclntyre, Lori Robinson Indexing Leads: Jane Dow, Veronica Maier Indexers: Kumud Dwivedi, Cheryl Lantles Lead Graphic Designer. Flora Goldthwaite Designers; Chris Blanton, Siamack Sahafi An Production: Blaine Dollard, Jenna Kiter, Amy Shear, Gabriel Varela Test Lead: Jonathan Fricke Testers: Brian Klanber, Jeremy Sullivan Windows 2000 Lab Manager. Edward Laf forty Administrators: Deborah Jay. Grant Mericle, Dave Meyer, Dean Prince. Robert Thingwold, Luke Walker, Joel Wingert, Frank Zamarron Lab Partners: Cisco Systems, Inc.. Compaq, Inc., Hewlett-Packard Corporation. Intel Corporation Technical Contributors: Bernard Aboba, Mohammad (Shabbir) Alam, Anoop Anantha, Zubair Ansari, David Baldridgt', Vijay Baliga, Adam Bargmeyer, Stephen Bensley, Boyd Benson, Hakan Berk, David Brooks, Evan C. Cacka, Ting Cai, Anil Cakir, Ross Carter, Mike Cerceo, Rakesh Chanana, Frank Chidscy, John Clangherty. Larry Cleeton.Ken Crocker, Carl Da Vault. Joseph Davies, Gulse.ii Demiroz, William Dixon, David Eitelbacb, Scott Frnmons, Kyril Faenov, Pat Petty, Peter Ford, Kevin Forsythe, Tom FouL, Nick Gage, Tony Gaston, Alexandra Gavrilesru. Abolade Gbadegesin, Narendra Gidwani, Stephen Hui, Rich Hagemeyer, David Janson, George Jose, Kevin Kean, Jawad Khaki, Chaitanya Kodeboyina, Shirish Koti, Deepak Kumar, Mark Larusso, Brian Lieuallen, David S. London. Don Lundman, Richard Machin, Rhonda Marshall, Jeremy Martin, Paul Maytield, Kelley McGrew, Randy McLaughlin, Paul Miner, Tim Moore, Vivek Nirkhe, Chris Olson, Ashwin Palekar, Curdeep Singh Pall. Paolo Phan, Amriiansh Raghav, Marc Reynolds, Kenny Richards, David Roundtree, Rao Salapaka.Walter Schmidt, Joseph Seifert. Mark Sestak, Alan Shen, Vena Suomalainen, Dave Thaler, Chuck Tiraon, Rob Trace, Blake Underwood, Sean Wheeler. Kevin Willems,David C. Winkler, Jon Wojan, Glen Zorn, Suzanne Zwick
Microsoft Corporation
Межсетевое взаимодействие. Ресурсы Microsoft Windows 2000 Server
Перевод с английского под общей редакцией Ю. Е. Купцевича Корректор
С. В. Рудзиевская
Технический редактор
С. В, Дерганее
Компьютерная верстка В. Б. Хилъченко Дизайнер обложки Е. В. Козлова Оригинал-макет выполнен с использованием издательской системы Adobe PageMaker 6.0
TypeMarkeiFontLibrary
Главный редактор А, И. Козлов Подготовлено к печати Издательско-торговым домом «Русская Редакция»
М.Р1 Подписано в печать 26.06.02. г Тираж 2 500 экз. Формат 70x100/16. Фш. п. л. 46. Зак. 3343. Ch печатало с оригинал-макета в Академической типографии «Наука» РАН [99034, Санкт-Петербург, 9 линия. 12
M A G A Z I N E / R E
Из каждого номера Windows 2000 Magazine/RE Вы будете получать самую последнюю информацию о том, как добиться от Windows 2000 Professional и Windows 2000 Server максимальной производительности. Вы узнаете, какие существуют программные продукты для Windows 2000 и как они работают, как Windows 2000 Professional или Windows 2000 Server ведут себя в сети, куда обращаться за помощью и многое, многое другое. Как подписчик журнала, Вы будете иметь бесплатный доступ к электронным приложениям "Профессионалам Windows NT/2000" и "SQL Server Magazine ONLINE". В них Вы найдете дополнительную информацию по операционным системам семейства Windows 2000 и продуктам, работающим на их основе.
ПЭ
ч
-, -
ОТКРЫТЫЕ СИСТЕМЫ www.wingQOOmag.r-U ^ [email protected] Подписка во всех отделениях связи по каталогу Роспечати - 79741, АПР - 38185
e d u c a t i o n
Ваш курс начинается завтра!
Microsoft
Подготовка сертифицированных инженеров и администраторов Microsoft Авторизованные и авторские курсы по: » Windows 2000/ХР » Sun Solaris 8 * Visual Studio .NET * Электронной коммерции
Учебный центр SoftLine 119991 г. Москва, ул. Губкина, д. тел.: (095) 232 00 23 e-mail: [email protected] http://education.softline.ru
* Безопасности информационных систем и еще более 40 курсов по самым современным компьютерным технологиям.
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
Дневные и вечерние занятия. Опытные преподаватели. ГШЦбНЗИРОВАНИЕ * ОБУЧЕНИЕ • КОНСАЛТИНГ
Индивидуальные консультации.
kMWW.softline.ru • 232 ОО23 • mtotSsofHine.ru
В каждом из номер» нашего журнала - новое» компьютерной индустрии - подробности о современных и перспективных технологиях - тест и обзоры аппаратных и программных продуктов - интернет и мулпимедоднгры я прикладные программы - консультации »кспертов,встрвчн с интересными людьми - CD-приложение с полезными утилитами
КАШИ ИНДЕКСЫ; Hard'nSoff - 73140. Hard'n'Soft + CD - 26067