Межсетевое взаимодействие. Ресурсы Microsoft Windows 2000 Server

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 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.,ы сможете указать любой протокол 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. Филиал

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 соответствует имени интерфейса соединения по требованию на отвечающем маршрутизаторе, вызывающий рассматривается не как маршрутизатор, а как клиент удаленного доступа. Пакеты, поступающие из интрасети вызывающего маршрутизатора, пересылаются по соединению, а затем перенаправляются отвечающим маршрутизатором. Однако, когда отвечающий маршрутизатор принимает ответные пакеты, адресованные интрасети вызывающего маршрутизатора, маршруты к этой интрасети настраиваются на использование интерфейса соединения по требованию. А поскольку этот интерфейс находится в отключенном состоянии, отвечающий маршрутизатор пытается установить соответствующее соединение с вызывающим маршрутизатором. Если имеется еще один порт того же типа, создается второе соединение по требованию. В ином случае пакеты просто отбрасываются и сообщается о причине недо] и 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: —-—-Нет Аутентификация прошла удачно?

12. Проверить параметры учетной записи пользователя и свойства профиля с : ^~-»—«-мям« Нет • Т да

Позволяют ли эти параметры осуществить подключение? 13. Проверить наличие дополнительных средств авторизации Отказать

| Есть ли Нет дополнительные средства?


главы 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 и контроллером домена или сервером глобального каталога. Для проверки свя зи с контроллером домена или сервером глобального каталога используйте г• Чтобы настроить 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-интрасеть.

Туннель "'{" ^>того 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 -р

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-мосты или маршрутизаторы

в Сакраменто

Маршру- ,г/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
Удаляет каталог Потоковый редактор (колирует указанный файл на стандартное устройство вывода и редактирует его и соответствии с командами сценария) Сортирует файлы и отображает результат на стандартном устройстве вывода Копирует файл на стандартное устройство вывода, начиная с указанного места Переписывает стандартный ввод в стандартный вывод и делает копии в указанном файле Обновляет время последнего обращения к файлу или время его последней модификации Сообщает о повторяющихся строках в файле Сообщает количество строк, слов или символов в файле Редактор, основанный на ех Интерпретируемый язык, используемый для сканирования текстовых файлов, выборки информации из них и се вывода на экран

Использование 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 . Файлсервер доступен но 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

Кяает«рн
ГЛАВА 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 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->