WWW.DISSERS.RU

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

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

Pages:     | 1 |   ...   | 6 | 7 || 9 | 10 |   ...   | 13 |

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

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

Внимание Будьте очень осторожны при добавлении маршрутов, чтобы гарантиро вать передачу трафика, связанного с интрасетью, по 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 Зак Удаленный доступ 370 ЧАСТЬ Временные и постоянные 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 Виртуальные частные сети ^ Чтобы настроить маршрутизатор филиала:

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-соединению между маршрутизато рами. Этот вариант хорошо работает в крупных межсетевых средах с большим количеством маршрутов. Подробнее об автостатических обновлениях см. главу «Маршрутизация с соединением по требованию» в этой книге.

3. В случае постоянных соединений разрешите функционирование нужных прото колов маршрутизации через VPN-соединение между маршрутизаторами. Про токолы будут считать это VPN-соединение каналом связи типа «точка-точка».

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

ГЛАВА 9 Виртуальные частные сети Аутентификация на основе общего ключа при использовании L2TP поверх IPSec для VPN-соединений между маршрутизаторами По умолчанию Ь2ТР-клиент и Е2ТР-сервер Windows 2000 настраиваются на IPSec аутентификацию на основе сертификатов. Ко1'да Вы устанавливаете соединение L2TP поверх IPSec, автоматически создается политика IP-безопасности, заставля ющая IKE (Internet Key Exchange) в процессе согласования параметров защиты для L2TP использовать аутентификацию на основе сертификатов. Это означает, что у Ь2ТР-клиента и сервера должны быть машинные сертификаты. Они могут быть получены от центра сертификации (certificate authority, CA), либо на каждом ком пьютере должна быть установлена копия корневого сертификата СА другой сторо ны, полученная из хранилища доверенного корневого центра сертификации. ] Iод роб нее на эту тему см. книгу «Распределенные системы» из серии «Ресурсы Micro soft 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\CurrentContro1 Set\Services\RasMan\Parameters значение 1. По умолчанию ProhibitlpSec равен 0.

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

ЧАСТЬ 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 Виртуальные частные сети жен быть предназначен для определенного адреса. В нашем примере нужен спи сок из двух фильтров, один из которых определяет Ь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 Удаленный доступ Теперь для каждого адреса назначения создайте фильтр (в рамках списка) со сле дующей конфигурацией.

• На вкладке 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 (Проверять политику на наличие изменений каждые) и Ad vanced (Дополнительно).

• На вкладке Rules (Правила):

• удалите правило Default Response (Отклик по умолчанию).

Добавьте правило со следующими свойствами.

• На вкладке IP Filter List (Список фильтров IP):

• выберите список IP-фильтров, соответствующий всем Ъ2ТР-соединениям со всеми филиалами. В нашем примере это список L2TP connections.

• На вкладке Filter Action (Действие фильтра):

• выберите действие фильтра, запрещающее незащищенную Ь2ТР-свя;

*ь. В на шем примере это Secure L2TP.

ГЛАВА 9 Виртуальные частные сети • На вкладке 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 (Проверять политику на наличие изменений каждые) и Ad vanced (Дополнительно).

• На вкладке Rules (Правила):

• удалите правило Default Response (Отклик по умолчанию).

Для каждого межмаршрутизаторного VPN-соединения на основе L2TP добавьте правило со следующими свойствами (на примере соединения с Бостоном).

• На вкладке IP Filter List (Список фильтров IP):

Виртуальные частные сети ГЛАВА. • выберите список IP-фильтров, соответствующий Ь2ТР-соединетшю с фили алом в Бостоне. В нашем примере это список L2TP pre-shared key connec tion 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 ЧАСТЬ Создание политики 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-ресурсам интрасети.

Туннель Брандмауэр s \ vmicpnci, VPN-сервер V-..ъ. VPN-клиент Рис. 9-17. VPN-сервер, подключенный к Интернету перед брандмауэром Виртуальные частные сети ГЛДВА 9 Если Вы выбрали именно этот вариант, то должны сконфигурировать для Интер нет-интерфейса 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 ЧАСТЬ • 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 Этот фильтр разрешает передачу управляющего РРТР-туннелем трафика от РРТР-клиента РРТР-серверу.

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 ЧАСТЬ Фильтры пакетов для 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 десятичное представление 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 parame ters index, SPI). SPI используется — в сочетании с IP-адресом назначения в неза шифрованных IP-заголовке и заголовке одного из IPSec-протоколов (ESP или АН) — для идентификации IPSec-соноставления безопасности (SA).

ЧАСТЬ 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-соединений удаленного досту па от клиентов через Интернет и создайте политики удаленного доступа, требую Виртуальные частные сети ГЛАВА щие наиболее защищенные типы аутентификации и шифрования. Подробнее см, справочную систему Windows 2000 Server.

Г VPN-соединение Туннель «r^jR,-™**.

т lin&^als "X ^^ Компьютер сотрудника компании А „™™*™ ^ Туннель Инграсеть компании В 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 dial in 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-сервера компании В Условие Настройки Virtual (VPN) [Virtual (VPN)] NAS-Porl-Typc Callcd-Station-ID IP-адрес интерфейса VPN-сервера, принимающего VPN-соединения Windows-Groups Например, VPN_PassThrough Таблица 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.

Виртуальные частные сети ГЛАВА 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 ЧАСТЬ Настройка компьютера VPN-клиента на использование сквозной VPN Здесь рассматривается конфигурация VPN-клиента Windows 2000 для создания сквозной VPN на основе РРТР и L2TP поверх IPSec.

^ Чтобы настроить РРТР-соединение:

1. Создайте объект VPN-соединения, подключающий сотрудника компании А к VPN-серверу компании В:

• на вкладке General (Общие) введите хост-имя или IP-адрес интерфейса ин трасети VPN-сервера компании В;

• на вкладке Security (Безопасность) выберите шифрование только пароля;

• на вкладке Networking (Сечь) выберите в качестве типа сервера Point-to Point 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- Tunneling Protocol (L2TP) [Туннельный протокол уровня 2 (L2TP)].

2. Создайте объект VPN-соединения, подключающий сотрудника компании А к VPN-серверу компании А:

• на вкладке General введите хост-имя или IP-адрес Интернет-интерфейса VPN-сервера компании А;

• на вкладке Security выберите либо шифрование пароля и данных, либо переключатель Custom [Дополнительные (особые параметры)]. Выбрав Custom, Вы должны указать подходящие параметры шифрования и аутен тификации;

• на вкладке Networking выберите в качестве типа сервера Layer-2 Tunneling Protocol (L2TP).

Виртуальные частные сети ГЛАВА Создание сквозного 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 per mission (Предоставить право удаленного доступа) в политике удаленного доступа;

• соответствовать всем параметрам профиля;

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

Подробнее о политиках удаленного доступа см. справочную систему Win dows 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 • у группы безопасности 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, считывающий параметры пользовательских учетных записей из доверяемого домена Win dows 2000, проверьте, включена ли группа Everyone (Все) в группу Pre-Win dows 2000 Compatible Access. Для этого воспользуйтесь командой net localgroup «Pre-Windows 2000 Compatible Access». В случае отрицательного результата введите команду net localgroup «Pre-Windows 2000 Compatible Access» every one /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 (Отказать в праве удаленного доступа).

Подробнее о политиках удаленного доступа см. справочную систему Win dows 2000 Server и главу 7 «Сервер удаленного доступа* в этой книге.

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

• Проверьте настройки распределения IP-адресов VPN-сервером.

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

Если VPN-сервер настроен на выделение IP-адресов через DHCP, a DIICP сервер недоступен, VPN-сервер выделяет адреса из диапазона 169.254.0.1 169.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 ЧАСТЬ товерениях вызывающего маршрутизатора совпадает с именем интерфейса со единения по требованию на 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 Виртуальные частные сети блем с 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 ЧАСТЬ Дополнительные материалы Более подробную информацию о RFC см. по ссылке:

• Internet Engineering Task Force на странице Web Resources (http://win dows.microsoft.com/windows2000/reskit/webresources).

ЧАСТЬ Взаимодействие с другими системами Взаимодействие с операционными системами, отличными от Windows, по прежнему остается важной задачей для администраторов сетей. В главах ча сти 3 рассматриваются возможности Windows 2000 и дополнительных про граммных продуктов в поддержке взаимодействия между Windows 2001) и операционными системами, отличными от Windows.

В этой части Взаимодействие с хост-системами IBM Services for Unix Взаимодействие с NetWare Services for Macintosh ГЛАВА Взаимодействие с хост-системами IBM Microsoft SKA Server — это программное решение Microsoft для интеграции клиен тов и серверов на базе персональных компьютеров с мэйнфреймами и хост-систе мами IBM (хостами). SNA Server обеспечивает клиентам на базе операционных систем и от Microsoft, и не от Microsoft защищенный доступ к данным, приложени ям и сетевым сервисам на хостах IBM. Вы можете интегрировать SNA Server в су ществующую среду, а также разработать решения для доступа к ресурсам хост-сис тем из пользовательского интерфейса операционной системы или Web-браузера.

В этой главе Обзор Microsoft SNA Server Способы интеграции сетей Коммуникационное взаимодействие с иерархическими SNA-сетями Коммуникационное взаимодействие с одноранговыми SNA-сетями Гетерогенные клиенты Host Print Service Защита сетевых сред, включающих хост-системы Доступ к данным на хост-системах Интеграция с приложениями хост-систем через COMTI Интеграция с системой обработки транзакций на хостах Интеграция хост-систем с Web Интеграция управления сетями См. также • Подробнее о хост-системах IBM и SNA-сетях — приложение А «Концепции взаимодействия с IBM SNA» в этой книге.

• Подробнее о настройке и администрировании SNA Server — справочную систе му SNA Server и Microsoft BackOffice Resource Kit.

ГЛАВА 10 Взаимодействие с хост-системами IBM Обзор 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, а также через службу маршрутизации и удаленного доступа Win dows 2000, Сам SNA Server подключается к мэйнфрейму или AS/400 по стандарт ным протоколам IBM SNA.

Установив сетевое соединение на основе SNA или TCP/IP, пользователи могут по лучать с помощью SNA Server защищенный доступ к данным, приложениям и се тевым сервисам на мэйнфреймах и хост-системах ШМ, не выходя из привычного интерфейса своей операционной системы или Web-браузера.

AS/ LAN/WAN-протоколы:

^-.

Мэйнфрейм TCP/IP IPX/SPX Banyan VINES Сервисы Для интеграции:

AppleTalk Сетей NetBEUI Данных SNA Приложений Server Управления сетями Хост-систем с Web U MIX OS/ Macintosh " MS-DOS Windows 3.x Windows 95/ Windows NT Workstation Windows Professional Рис. 10-1. SNA Server интегрирует гетерогенные сети с хост-системами IBM 143ак Взаимодействие с другими системами 402 ЧАСТЬ Основа мощной функциональности 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-1. (продолжение) Характеристики Описание Поддержка гетерогенных клиентов 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 Ser ver. Это обеспечивает эффективное туннелированис 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 ЧАСТЬ Таблица 10-2. Доступ к данным на хостах и интегрированные сервисы доступа к файлам и принтерам Сервисы доступа к базам данных и передачи файлов Описание Обеспечивает доступ к VSAM- и OS/400-файлам па OLE DB Provider для AS/ мэйнфреймах па уровне записей. Позволяет разрабаты и VSAM вать многоуровневые приложения для доступа к нере ляционным базам данных на хостах.

Драйвер ООВСДЖОАдля DB2 Позволяет- приложениям, рассчитанным па использова ние SQL и интерфейса ODBC, динамически взаимодей ствовать с системами управления базами данных на хостах (например, с DB2) по протоколу DRDA. Приме ним и для приложений, использующих OLE DB.

Дает возможность пользователям получать доступ к Shared Folders Gateway файлам в общих папках AS/400 (shared folders-based files) так, будто эти папки являются локальными диска ми компьютера под управлением Windows 2000 Server, Обеспечивает доступ к сервису передачи файлов AFTP (APPC File Transfer Protocol) Service (SNA APPC - эквивалент FTP ш TCP/IP).

FTP-AFTP Gateway Service Позволяет стандартным FTP-клиентам обращаться к файлам на хосте по AFTP.

VSAM F i l e Transfer Service Дает возможность авторизованным пользователям ко пировать VSAM-файлы с мэйнфрейма на компьютер Windows 2000 Server.

Host Data Replicator Support Действует как птлюл при репликации хост-данных в Microsoft SOL Server'".

Host Print Services Позволяет печатать с мэйнфреймов и 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 также поддерживает сторонние программы эмуляции соответствующих терминалов.

Взаимодействие с хост-системами IBM ГЛАВА 10 Таблица 10-3. (продолжение) Характеристики Описание Поддержка эмуляции терминалов 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, предназначенные для интеграции систем управления Win dows 2000 Server и хостов IBM, перечислены в таблице 10-4.

Таблица 10-4. Сервисы интеграции управления сетями Сервисы интеграции управления Описание сетями Предоставляет единую консоль для добавления, SNA Server Manager настройки, мониторинга и контроля всех компонентов SNA Server. Обеспечивает удаленное управление поддо менами, серверами, службами, подключениями, LU.

сеансами, пользователями и группами.

Обеспечивает полную интеграцию с ММС (Microsofl Поддержка интеграции Management Console) и средствами Windows со службами управления для мониторинга событий, безопасности и производи Windows 2000 Server тельности.

Обеспечивает автоматическое уведомление NetVtew n Поддержка интеграции поддерживает Response Time Monitor (если он поддер с системой управления живается эмулятором 3270). Кроме того, поддерживает сетями IBM NciView службы 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), соответствующим об ЧАСТЬ 3 Взаимодействие с другими системами разом организовать компьютеры SNA Server внутри своих доменов Windows и выбрать способы подключения локальных сетей к хосту.

Модели развертывания Решая, как развернуть 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 или через IBM Net View.

Преимущества • Изоляция SNA-трафика. Модель развертывания по филиалам идеальна при ограниченной пропускной способности соединения SNA Server с хостом. Меж ду клиентом и компьютером SNA Server сетевой трафик, как правило, интен сивнее. Если Ваша организация реализовала TCP/IP или один из маршрутизи руемых WAN-протоколов, выделение для SNA-трафика, требующего подключе ния к хосту, специальных соединений — в данном случае для трафика между SNA Server и хостом — исключает распространение лишнего сетевого трафика по WAN-соединениям, не имеющим отношения к SNA.

• Использование существующей инфраструктуры SNA. Эта модель также иде ально подходит организациям, переходящим на единый маршрутизируемый WAN-протокол, так как позволяет использовать существующие каналы переда чи SNA-данных.

Взаимодействие с хост-системами IBM ГЛАВА 10 • Более высокая гибкость в управлении. Поскольку компьютеры, работающие со 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 ЧАСТЬ Модель централизованного развертывания В этой модели компьютеры SNA Server размещаются рядом с хостом, к которому они обеспечивают доступ через эмуляторы терминалов 3270 и 5250;

при этом ло кальные и удаленные клиентские компьютеры подключаются к шлюзам по одному из маршрутизируемых протоколов, например TCP/IP. Другие клиентские и сервер ные приложения, либо приложения Telnet могут подключаться к хосту через эти шлюзы из любого участка WAN. Модель централизованного развертывания пока зана на рис. 10-3.

AS/ Главный мэйнфрейм Компьютеры SNA Server SNA-сеть WAN-мосты или маршрутизаторы в Сакраменто Маршру-,г< тизатор ;

f Северо-западный LAN-домен " -.г* LAN-домен t - филиала в Бостоне LAN-домен филиала в Сан-Диего Рис. 10-3. Модель централизованного развертывания SNA Server с применением маршрутизаторов или мостов Преимущества • Эффективная балансировка нагрузки и отказоустойчивость. В централизо ванной модели LU-пулы и пары АРРС-сеансов (АРРС session pairs) на множе стве компьютеров SNA Server могут быть логически организованы в поддомен, который обеспечивает балансировку нагрузки и отказоустойчивость. За счет ба лансировки нагрузка равномерно распределяется между всеми серверами. От казоустойчивость или «горячее» резервирование гарантирует, что в случае ава рии одного из серверов его функции автоматически возьмут на себя остальные компьютеры SNA Server, входящие в поддомен. Подробнее о поддоменах см. раз дел «Поддомены SNA Server* далее в :ггой главе.

• Централизованное администрирование. Администрирование при использова нии этой модели гораздо проще, чем при реализации модели на основе филиа лов, поскольку все компьютеры SNA Server расположены рядом друг с другом, а не разбросаны по филиалам.

Взаимодействие с хост-системами IBM ГЛАВА • Использование высокоскоростных каналов связи с мэйнфреймом. Так как компьютеры SNA Server находятся рядом со SNA-хостом, их можно подключить к нему по высокоскоростным каналам связи. Самую высокую пропускную спо собность обеспечивает канальное подключение (типа ESCON). Во многих слу чаях компьютеры SNA Server, подключаемые по таким каналам, могут обходить FEP, еще- больше ускоряя транзакции. А в случае хостов AS/400 можно реали зовать высокоскоростные соединения Token Ring или Ethernet.

Недостатки • Жесткие требования к инфраструктуре WAN. Модель централизованного развертывания предполагает наличие эффективной WAN-среды. Если у Ва:- нет подходящей инфраструктуры WAN, Вы должны сначала подсчитать стоимость необходимого для нее оборудования, расходы на его установку и возмохные потери из-за простоев, связанных с настройкой этого оборудования.

• Невозможность использования локальных многоцелевых серверов. В данной модели компьютеры с Windows 2000 Server, на которых работает SNA Server, нельзя использовать в качестве многоцелевых серверов. Если в филиалах Д!>лж ны работать и другие серверные приложения, Вам придется устанавливат. до полнительные компьютеры и аппаратные средства.

Модель распределенного развертывания Эта модель сочетает в себе лучшие качества первых двух моделей. Как показано на рис. 10-4, компьютеры SNA Server размещаются и в центральном участке (рядом со SNA-хостом), и в филиалах (рядом с клиентами).

AS/ Главный мэйнфрейм Компьютеры SNA Server SNA-сеть в Сакраменто WAN-мост или маршрутизатор SNA Server LAN-домен в Сакраменто Северо-восточный LAN-домен Северо-западный LAN-домен Рис. 10-4. Модель распределенного развертывания SNA Server Взаимодействие с другими системами 410 ЧАСТЬ Компьютеры SNA Server, расположенные рядом с хостом, обычно связываются с ним высокоскоростным соединением, например по канальному подключению. За тем канальные сервисы делают доступными компьютерам SNA Server в филиалах, используя с этой целью Distributed Link Services — функцию, которая позволяет компьютеру SNA Server разделять сконфигурированные сервисы каналов с други ми компьютерами SNA Server. В этом случае серверы в филиалах взаимодейству ют со SNA-хостом через сервис виртуального канала (virtual link service) с исполь зованием одного из маршрутизируемых WAN-протоколов, например TCP/IP.

Преимущества • Сочетание преимуществ централизованной модели и модели на основе фили алов. Распределенная модель сочетает в себе высокую пропускную способ ность коммуникационной связи централизованной модели со способностью мо дели на основе филиалов изолировать очень интенсивный трафик между кли ентами и серверами в отдельном сегменте WAN.

• Оптимальная поддержка отказоустойчивости и балансировки нагрузки. Рас пределенная модель обладает еще большей гибкостью в реализации балансиров ки нагрузки и отказоустойчивости, чем централизованная или на основе фили алов. Например, несколько компьютеров SNA Server в филиале можно настро ить на взаимное «горячее» резервирование и балансировку нагрузки между со бой. В свою очередь эти серверы можно подключить к SNA-хосту через Distri buted Link Services, используемой совместно с централизованными компьюте рами SNA Server. При аварии любого из серверов остальные серверы на данном участке могут взять на себя его функции.

• Применение стандартных WAN-протоколов. Distributed Link Services также облегчает выбор протоколов маршрутизации и сетевых протоколов. В филиа лах можно использовать любой LAN-протокол, поддерживаемый SNA Server, в том числе IPX/SPX. А между филиалом и центральным участком с компьюте рами SNA Server можно реализовать более эффективный, маршрутизируемый протокол типа TCP/IP. SNA-трафик передается только но соединению между компьютерами SNA Server и хост-системой. Соответственно маршрутизация SNA-протоколов через WAN становится ненужной, что упрощает сетевое уп равление.

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

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

Взаимодействие с хост-системами IBM ГЛАВА Интеграция SNA Server с сетями Windows Выбрав подходящую модель развертывания, Вы должны логически сгруппировать компьютеры SNA Server для обеспечения максимальной отказоустойчивости, «го рячего» резервирования и балансировки нагрузки.

Домены Windows Служба каталогов Active Directory в Windows 2000 Server хранит информацию обо всех объектах в локальной или глобальной сети и упрощает доступ к этой инфор мации пользователям и администраторам.

Для адаптации под требования разных предприятий содержимое Active Directory можно разделить на домены, а в более крупных сетях — па деревья доменов. Домен Windows 2000 — это группа компьютеров и ресурсов с общей базой данных учет ных записей пользователей и единой политикой безопасности. Домен Windows.:ЮОО включает контроллеры домена, управляющие учетными записями пользователей и доступом к сетевым ресурсам. Остальные компьютеры в домене являются либо ра бочими станциями, либо рядовыми серверами, предоставляющими свои ресурсы пользователям домена.

Подробнее об Active Directory и доменах см. книгу «Распределенные системы» из серии «Ресурсы Microsoft Windows 2000 Server».

Поддомены SNA Server Каждый компьютер SNA Server является членом домена Windows 2000 и одновре менно членом поддомена SNA Server. Поддомен SNA Server — это логическая груп па компьютеров SNA Server, использующих общую конфигурационную информа цию. Для клиентов с программным обеспечением SNA Server Client компыо' еры поддомена SNA Server кажутся единым набором SNA-ресурсов.

Хотя SNA Server работает в операционной системе Windows 2000 Server, поддиме ны SNA Server не участвуют в аутентификации пользователей, выполняемой W i n dows 2000. Напротив, в аутентификации. SNA Server полагается на средства Win dows 2000 Server.

Примечание SNA Server можно настроить на аутентификацию через домен Win dows 2000, чтобы реализовать унифицированную регистрацию для доступа к ресур сам хост-системы. Подробнее см. раздел «Защита сетевых сред, включающих.хост системы» далее в этой главе.

Организация поддоменов SNA Server В каждый поддомен SNA Server может входить до 15 компьютеров SNA Server, а в домен Windows 2000 — неограниченное количество поддоменов SNA Server. По скольку в контроле за доступом к сети эти ноддомены полагаются на систему за щиты домена Windows 2000, все компьютеры SNA Server конкретного полдомена должны относиться к одному домену Windows 2000, Планируя поддомен SNA Server и размещение его членов, Вы должны учесть про пускную способность сетевого канала, соединяющего членов поддомена. При каж дом изменении конфигурации поддомена (например, из-за добавления нового пользователя или LU) модифицированный конфигурационный файл раснрос тра Взаимодействие с другими системами 412 ЧАСТЬ няется на все компьютеры SNA Server в поддомене, выполняющие роль резервных.

(Роли компьютеров в SKA Server поясняются в следующем разделе.) Чтобы свести к минимуму излишний трафик репликации, передаваемый по мед ленным WAN-соединениям, ноддомеп обычно содержится внутри сайта Active Directory. Сайт Active Directory — это одна или несколько TCP/IP-подсетей, со единенных высокоскоростными каналами. Windows 2000 позволяет администрато рам контролировать и оптимизировать репликацию внутри сайта.

В модели распределенного развертывания Вы могли бы сгруппировать все компь ютеры SNA Server, входящие в сайт филиалов, в один поддомен, а компьютеры SNA Server на центральном сайте (рядом с хостом) — в другой поддомен.

Определение ролей в SNA Server Сформировав домены Windows 2000 и полдомены, Вы должны назначить каждый компьютер SKA Server в каждом поддомене на одну из трех ролей.

Основной (primary). Предоставляет сервисы подключения к хост-системе пользо вателям и хранит мастер-копию конфигурационного файла. Внутри иоддомена ос новным может быть только один компьютер SKA Server.

Резервный (backup). Хранит копию (только для чтения) конфигурационного фай ла, поддерживаемого основным сервером. Резервный сервер может быть выдвинут на роль основного, если тот выйдет из строя. В поддомене SNA Server может быть до 14 резервных серверов.

Рядовой (member). He имеет копии конфигурационного файла. Рядовые серверы целиком полагаются па основной и резервные серверы. В ноддомене SKA Server может быть до 14 рядовых серверов.

Примечание Концепция резервного сервера SNA Server отличается от концепции «горячего* резервирования. «Горячее» резервирование — это возможность совмес тной поддержки сеансов компьютерами SNA Server даже в том случае, если один из серверов или какое-то соединение не работает.

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

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

Выделив основной и несколько резервных серверов, Вы можете назначить осталь ные серверы на роль рядовых (не имеющих копии конфигурационного файла), Пока работает основной сервер, Вы можете администрировать SNA Server с рядо вого сервера — точно так же, как и с любого другого. SNA Server можно управлять и с компьютера Windows 2000 Professional, на котором установлен SKA Server Manager.

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

• как подключить компьютеры SKA Server к хост-системам IBM;

ГЛАВА 10 Взаимодействие с хост-системами IBM • какие сетевые протоколы будут использоваться для коммуникационной связи между клиентами и компьютерами SNA Server;

• какие сетевые протоколы будут использоваться для коммуникационной связи между самими компьютерами SNA Server.

Подключение компьютеров SNA Server к хост-системам IBM Здесь поясняется, как подключать компьютеры SNA Server к мэйнфреймам ШМ и хост-системам AS/400.

Что представляет собой соединение между SNA Server и хостом В терминологии SNA Server хост-соединение (host connection) — это коммуника ционный путь передачи данных между SNA Server и хост-системой, В случае мэйн фрейма это соединение соответствует определению физического элемента (P1J) во VTAM (Virtual Telecommunications Access Method). PIJ — комбинация аппаратно программных средств, которая обеспечивает сервисы, необходимые для использо вания определенного устройства н управления им. Применительно к AS/400 эпо же соединение соответствует определению контроллера АРРС (Advanced Program-to Program Communications). Подробнее о способах подключения к хостам IBM и о SNA-сетях см. приложение А «Концепции взаимодействия с IBM SNA* в этой книге.

Для каждого физического адаптера или подключения в SNA Server устанавливает ся и настраивается соответствующий сервис канала (link service). Сервис канала — это служба Windows 2000 или драйвер устройства, используемый для управления коммуникационными адаптерами «сервер-хост», которые поддерживаются SNA Server. После настройки сервис канала доступен не только на сконфигурированном SNA Server, но и на любом SNA Server в поддомсне (через Distributed Link Services).

Сконфигурировав свои сервисы каналов, Вы создаете соединение через определен ный сервис канала. Используя хост-соединение, клиентский компьютер в LAN мо жет взаимодействовать с мэйнфреймовой системой. Для некоторых сервисов кана лов возможно определение нескольких соединений на одном канале связи с хостом.

В терминологии SNA комбинация соединения и используемого им сервиса канала эквивалентна PU. В SNA-сетях SNA Server предоставляет функциональность PU или PU 2.1, аналогичную функциям контроллера кластера. О функциях контроллера кластера см. приложение А «Концепции взаимодействия с IBM SNA» в этой книге.

Что представляют собой способы подключения SNA Server к хосту Для понимания различных вариантов подключения следует сначала изучить типы физических подключений и сетевые протоколы, поддерживаемые SNA Server. Наи более распространенные способы подключения перечислены в таблице 10-5.

Выбирая способ подключения, следует учитывать несколько факторов:

• тип хост-систем, к которым Вы намерены подключиться;

• реализуемую модель развертывания;

• сетевую инфраструктуру хоста;

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

• уровень производительности и скорость отклика, ожидаемые Вашими пользо вателями;

• стоимость.

Взаимодействие с другими системами 414 ЧАСТЬ Таблица 10-5. Способы подключения SNA Server к хосту Пропускная Способ способность Характеристики Token Ring 4, или • Для мэйнфреймов или AS/ 802.2 DLC 16 Мбит/с • Средняя производительность с использованием (Data Link протокола DLC Control) • Поддержка нескольких хост-соединений с использованием одного адаптера • Простой и недорогостоящий в реализации • Подходит для широкого спектра задач Стандартный 10 Мбит/с • Для мэйнфреймов или AS/ Ethernet • Средняя производительность с использованием 802.2 DLC протокола DLC • Поддержка нескольких хост-соединений с использованием одного адаптера • Простой и недорогостоящий в реализации • Подходит для малой и средней нагрузки по сетевому трафику • Конкуренция в Ethernet может ухудшить производительность в условиях высоких нагрузок Fast Ethernet 100 Мбит/с • Для мэйнфреймов или AS/ 802.2 DLC • Высокая производительность с использованием протокола DLC • Поддержка нескольких хост-соединений с использо ванием одного адаптера • Простой и не дорогостоящи и в реализации • Подходит для более производительных соединений • Конкуренция в Ethernet может ухудшить производительность в условиях высоких нагрузок FDDI (Fiber 100 Мбит/с • Для мэйнфреймов или AS/ Distributed Data • Высокая производительность с использованием Interface) протокола DLC 802.2 DLC • Поддержка нескольких хост-соединений с использованием одного адаптера • Относительно дорогостоящий в реализации • Подходит для более производительных соединений SDLC 9600-19200 • Для мэйнфреймов или AS/ (Synchronous бит/с • Низкая производительность с использованием Data Link протокола SDLC Control) • Поддержка 256 сеансов по одному хост-соединению • Простой и недорогостоящий в реализации • Подходит для WAN-соединений с малым трафиком X.25 9600-19200 • Для мэйнфреймов или AS/ бит/с • Низкая производительность с использованием протокола QLLC (Qualified Logical Link Control) • Поддержка 256 сеансов по одному хост-соединению • Простой и недорогостоящий в реализации • Подходит для WAN-соединений с малым трафиком Взаимодействие с хост-системами IBM ГЛАВА Таблица 10-5. (продолжение) Пропускная способность Характеристики Способ 2.35 Мбит/с • Только для мэйнфреймов DFT (Distributed • Производительность: от малой до средней Function • Поддерживает только 5 сеансов но одному Terminal) хост-сосди нению • Недорогостоящий • Подходит для тестовых сред или малых сетей с уже имеющейся инфраструктурой па основе DFT Twin ax 1 Мбит/с • Только для AS/ • Низкая производительность • Поддерживает только 5 сеансов но одному хост-соединению л Недорогостоящий • Подходит для сред AS/400 с уже имеющейся инфраструктурой на основе Twinax Канальный — 4,5 Мб/с • Только для мэйнфреймов Bus & Tag • Высокая производительность • Поддерживает большое количество хост-соединений • Дорогостоящий • Подходит для высокопроизводительных соединений 17 Мб/с • Только для мэйнфреймов Канальный — ESC ON • Высочайшая производительности • Поддерживает большое количество хост-соединений • Дорогостоящий • Подходит для сред, требующих максимальной пропускной способности Как правило, хороший выбор — высокоскоростное соединение Token Ring, если та кое же соединение используется для подключения LAN к SNA-сети, включающей как мэйнфрейм, так и AS/400. Для большей производительности в среде, содержа щей только мэйнфрейм, обычно рекомендуется соединение канального типа.

Некоторые сервисы каналов дают возможность создавать несколько хост-соединений с помощью одного адаптера. Каждый экземпляр SNA Server поддерживает до 250 хост соединений, а на одном компьютере может работать до 4 экземпляров SNA Server.

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

Устройства в иерархической SNA-сети, например терминалы и контроллеры клас теров, называются физическими элементами (PU). Каждому классу устройств при сваивается свои номер. Так, сам мэйнфрейм считается устройством PU 5. Подроб нее об иерархических SNA-сетях см. приложение А «Концепции взаимодействия с IBM SNA» в этой книге ЧАСТЬ 3 Взаимодействие с другими системами • Twinas;

• Frame Relay.

ftS/ LI) 6. SNA Server Рис. 10-7. Соединения SNA Server в одноранговой сети Выбор сетевых протоколов Определив способ подключения компьютеров SNA Server к хосту, Вы должны выб рать протокол или протоколы для двух дополнительных коммуникационных путей SNA Server: между клиентами и компьютерами SNA Server и между самими компь ютерами SNA Server. С этой, целью можно применить один протокол или комбина цию нескольких протоколов — при условии, что все серверы будут использовать хотя бы один общий клиент-серверный протокол.

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

Однако, если Вы предпочитаете постепенное внедрение SNA Server па своем пред приятии, то для определенных соединений Вам придется использовать существую щие протоколы. Например, для коммуникационного взаимодействия между серве рами Вы можете пользоваться TCP/IP, а для коммуникационного взаимодействия между клиентами и серверами — IPX/SPX. Аналогичным образом возможно при менение и других комбинаций поддерживаемых протоколов, если все компьютеры SNA Server работают хотя бы с одним общим протоколом и используют его для коммуникационного взаимодействия как между собой, так и с клиентами.

Выбор клиент-серверных сетевых протоколов Компьютеры с программным обеспечением SNA Server Client могут взаимодейство вать по нескольким LAN-протоколам:

• TCP/IP;

• IPX/SPX;

Взаимодействие с хост-системами IBM ГЛАВА 10 • Named Pipes;

• Banyan VINES IP;

• AppleTalk.

TCP/IP быстро становится стандартным сетевым протоколом для клиент-сервер ных приложений. Благодаря высокой производительности и поддержке самых изощренных средств маршрутизации он подходит для многих WAN-сред. Обычно TCP/IP является лучшим выбором для сети — особенно если он уже в какой-то мере применяется в сегменте LAN, объединяющем клиенты и серверы SNA Server.

Если Вы решили реализовать TCP/IP, рекомендуется назначить компьютерам SNA Server статические IP-адреса, поскольку управлять рабочими станциями, имеющи ми дело с фиксированным адресом SNA Server, гораздо легче. Клиентским компь ютерам можно без проблем назначать динамические IP-адреса, используя с итой целью DHCP.

SNA Server Client Благодаря SNA Server Client рабочие станции поддерживают расширенные функ ции SNA Server интеграции с хостами. SNA Server Client также предоставляет API, используемые сторонними разработчиками в своих приложениях для доступа к хост-системам и приложениям IBM.

SNA Server Client обеспечивает независимость от конкретного сетевого транспор та, позволяя клиентам и приложениям взаимодействовать друг с другом через лю бые программные интерфейсы SNA Server. В настоящее время клиентское про граммное обеспечение доступно для следующих платформ:

• Windows NT;

• Windows 95;

• Windows 3.x;

MS-DOS;

т • IBM OS/2:

• Macintosh (от сторонних поставщиков);

• UNIX (от сторонних поставщиков).

Примечание SNA Server Client не нужен клиентам, использующим TCP/IP для та ких сервисов, как TN3270, TN5250 и AFTP. Приложения вроде эмуляторов ТШ взаимодействуют с этими сервисами напрямую, не обращаясь к клиент-серверному интерфейсу SNA Server.

Выбор сетевых протоколов для коммуникационной связи между серверами Компьютеры SNA Server могут взаимодействовать друг с другом по любому из сле дующих протоколов:

• TCP/IP;

• IPX/SPX;

• Named Pipes (именованные каналы);

• Banyan VINES IP.

Взаимодействие с другими системами 420 ЧАСТЬ Подробнее о настройке протоколов и оптимизации межсерверного сетевого трафи ка см. документацию на SNA Server версии '10.

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

Эта модель использует протокол отображения информации (information display protocol) для мэйнфреймов IBM, известный как 3270. Этот протокол упрощает вза имодействие между мэйнфреймом и такими устройствами, как терминалы, принте ры и контроллеры. SNA Server предоставляет доступ к ресурсам мэйнфрейма за счет определения и назначения логических элементов (LU) 3270.

Установив физическое подключение между SNA Server и мэйнфреймом, Вы дол жны определить, какие типы соединений 3270 понадобятся Вашим пользователям.

Доступ через терминалы SNA Server поддерживает соединения 3270 через зависимые логические элементы 3270 (зависимые потому, что требуют для своей работы мэйнфрейма). Каждый LU, определенный в SNA Server, конфигурируется на использование существую щего подключения к мэйнфреймовой системе и соответствует парному LU-pecyp су, выделенному на хост-компьютере (обычно с помощью VTAM). Определение 3270 LU в SNA Server идентифицируется по номеру и имени, специфичному для конкретного пользователя. Этот номер совпадает с номером соответствующего LU ресурса па мэйнфрейме.

3270 LU дополнительно классифицируется по типу сервиса, предоставляемого для данного соединения. Как и в случае PU, типы LU обозначаются номерами Напри мер, потоки данных 3270 для отображения на дисплее известны как LU 2. На рис. 10-8 показано, что 3270 LU можно сконфигурировать как:

• дисплей (LU 2);

• принтер (LU 1 или 3):

• приложение (LUA);

• нижестоящий LU (downstream LU), SNA Server Client должен быть установлен на каждом клиенте, использующем LU сервисы SNA Server. Клиентское программное обеспечение управляет взаимодей ствием между приложением 3270 и сервером, выполняющим SNA Server. Прило жения, рассчитанные на SNA Server Client API, устанавливают с помощью LU, оп ределенных в SNA Server, коммуникационную связь от клиента к мэйнфрейму че рез SNA Server.

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

Взаимодействие с хост-системами IBM ГЛАВА SNA-сеть Мэйнфрейм SSCP (PU 5} Сеть Windows Нижестоящий LU Эмуляция принтера (LU 1 и 3) Эмуляция тер ми нала Пользовательское ' приложение (LLJA) Рис. 10-8. Соединения 3270 с использованием SNA Server Использование LU-пулов Хотя Вы можете создавать отдельные LU и назначать их пользователям и грунтам, LU-пулы (при наличии большого количества LU) гораздо удобнее в управлении и применении. Пулы группируют LU, обеспечивая максимально эффективное их ис пользование (рис. 10-9). Пользователь, приложение или клиентская система может обращаться к LU, когда свободен любой из включенных в пул LU. Если како!'-ни будь LU, входящий в пул, перестает функционировать, происходит переключение на другой свободный LU из пула.

Соединения LU /Ш LU : Г— 1 I LU * V_v LU SNA LU Рис. 10-9. Создание LU-пулов и выделение из них ресурсов LU-пулы также позволяют более эффективно распределять ограниченный объем ресурсов хоста среди групп непостоянных пользователей. Закрепление LU за пользователями, которые обращаются к хосту лишь эпизодически, привело бы к Взаимодействие с другими системами 422 ЧАСТЬ пустой трате его ресурсов. С помощью пула Вы можете закрепить за группой таких пользователей гораздо меньшее число LU, Выделение LU рабочим станциям LU (и LU-пулы) можно назначать не пользователям, а рабочим станциям. Допус тим, у Вас имеется 150 сотрудников, использующих 50 рабочих станций, к каждой из которых подключен принтер. Вместо выделения 150 принтерных LU в пул для всех пользователей Вы можете включить все рабочие станции в SNA Server и на значить им всего 50 таких LU.

Обеспечение отказоустойчивости LU-пулы также обеспечивают отказоустойчивость соединений. Если какой-то ре сурс, например одно из хост-соединений, выходит из строя, «горячее» резервиро вание позволяет переключиться на аналогичный (заранее сконфигурированный) ресурс, как показано на рис. 10-10. «Горячее» резервирование реализуется в рамках одного сервера или нескольких серверов одного домена. Такая стратегия рекомен дуется для предприятий любых размеров, так как она обеспечивает надежный дос туп к хосту.

SNA Соединения Server ты ашм*,,.^,,,,[ SNA Server Рис. 10-10. «Горячее» резервирование соединений и серверов Балансировка нагрузки Балансировка нагрузки тесно связана с «горячим» резервированием и позволяет равномерно распределять сеансы между имеющимися хост-соединениями и серве рами с использованием поддержки LU-пулов в 3270. Например, если у Вас есть два соединения, каждое из которых поддерживает по десять дисплейных LU, то функ ция балансировки нагрузки гарантирует равномерное использование LLJ, свобод ных на этих соединениях. Балансировка нагрузки реализуется созданием пула с LU от нескольких серверов или соединений.

Доступ через терминалы TN TN3270 — это тип Telnet-сервиса, который обеспечивает доступ к мэйнфреймам по TCP/IP-сети. Пользователи могут подключаться к мэйнфреймам через клиент TN3270 и сервис TN3270, предоставляемый SKA Server (рис. 10-11).

Взаимодействие с хост-системами IBM ГЛАВА 10 Сервис TN3270 поддерживает протоколы:

• TN3270 для сеансов дисплея;

• TN3287 для сеансов принтера;

• TN3270E для расширенных сеансов дисплея и принтера.

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

Мэйнфрейм Рис. 10-11. Коммуникационное взаимодействие с помощью TN через SNA Server Поскольку сервис TN3270 взаимодействует со SNA Server через LUA API, на сер вере должны быть сконфигурированы соединения типа LUA, а также LU. После этого LUA и LU-пулы могут быть выделены сервису TN3270 и сделаны досту тны ми клиентам TN3270.

Как и службы TCP/IP, сервис TN3270 требует наличия свободного TCP-порта, че рез который клиенты могут обращаться к сервису TN3270. По умолчанию сервис TN3270 использует TCP-порт 23 — тот же, что и стандартные сервисы Telnet. По ЧАСТЬ 3 Взаимодействие с другими системами скольку сервисы не могут совместно использовать TCP-порт, рекомендуется пе ренастроить сервис TN3270 на TCP-порт 24 или какой-нибудь другой из числа свободных.

Соединения с нижестоящими системами В иерархических SNA-средах Вы конфигурируете коммуникационное взаимодей ствие 3270 между SNA-узлами, работающими с протоколами SNA. Обычно такими узлами являются компьютеры SNA Server и мэйнфреймы. Однако нижестоящая система (downstream system) — это SNA-узел, использующий SNA Server как шлюз PU (рис, 10-12). Нижестоящей системе компьютер SNA Server кажется мэйнфрей мом, предоставляющим PU и 3270 LU.

Клиенты SNA Server Мэйнфрейм Нижестоящие клиенты Рис. 10-12, Соединения с нижестоящими системами при использовании SNA Server Нижестоящая система в среде этого типа должна быть устройством PL! 2. Ниже стоящим устройством может быть, например, контроллер кластера IBM 3745. Та ким же устройством может быть и клиент, работающий с эмулятором терминала, который эмулирует PU 2 и запрашивает LU-сеансы от компьютера SNA Server.

Для поддержки нижестоящих систем у компьютера SNA Server должно быть два соединения:

• хост-соединение между сервером и мэйнфреймом (любое стандартное физичес кое подключение, поддерживаемое мэйнфреймом);

• соединение между сервером и нижестоящей системой (физическое подключе ние, использующее 802.2/DLC, SDLC или Х.25).

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

Взаимодействие с хост-системами IBM ГЛАВА 10 Коммуникационное взаимодействие с одноранговыми SNA-сетями В одноранговых SNA-сетях все устройства считаются APPN-устройствами (Advan ced Peer-to-Peer Networking). Каждое APPN-устройство (PU 2.1) может напрямую взаимодействовать с другими устройствами PU 2.1, использующими сеансы А Р Р С (Advanced Program-to-Program Communications).

Устройство PU 2.1 полагается на свои вычислительные ресурсы и не требует по стоянного доступа к центральной хост-системе, Примечание Хотя сети, использующие АРРС, обычно ассоциируются с хост-систе мами AS/400, мэйнфреймовые системы тоже поддерживают АРРС.

В среде AS/400 АРРС применяется для самых разнообразных приложений, в том числе для доступа через 5250 и для передачи файлов. Программы, взаимодейству ющие через АРРС, называются транзакциопиыми (transaction programs, TP). АРРС ТР используют имена LU 6.2 для доступа к другим системам и транзакпиопиым программам.

Подробнее о SNA APPN см. приложение А «Концепции взаимодействия с IBM SNA» в этой книге.

АРРС и SNA Server С помощью SNA Server транзакциопная программа (например, эмулятор термина ла 5250) может использовать АРРС-псевдоним LU (АРРС LU alias) для взаимо действия с другой ТР. В атом случае псевдоним LU преобразуется в имя LU, кото рое на самом деле и применяется при взаимодействии с ТР на другой системе.

Pages:     | 1 |   ...   | 6 | 7 || 9 | 10 |   ...   | 13 |



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

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