Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта


В лаборатории Novell Users Group SPb

BorderManager 3.5 Virtual Prived Network ≈ интересные особенности


Павел Гарбар, Александр Горячев, Дмитрий Смоликов


В предыдущей статье (╚КИ╩/2000, ╧ 1) была описана первая серия экспериментов с BorderManager 3.5, выполненная NetWare User Group SPb.
Целью эксперимента на этот раз была проверка следующих вопросов:
≈ организация VPN между серверами с различными версиями BorderManager от 2.1 до 3.5;
≈ некоторые&127;проблемы с установкой BM;
≈ организация защищенных IPX сетей;
≈ проверка VPN ╚сервер-клиент╩;
≈ как применение VPN на сервере сказывается на его производительности.
Поскольку VPN пока редкий гость в наших локальных сетях, уместно привести краткие сведения о VPN, как таковой.

Виртуальные частные сети (Virtual Private Network ≈ VPN) позволяют устанавливать защищенные шифрованные соединения через дешевые и общедоступные каналы, например, Интернет и телефонную сеть. Чтобы обеспечить возможность организации гибких и надежных сетей VPN, решение для интрасети должно:

BorderManager VPN предлагает экономичный метод создания безопасных соединений с удаленными пользователями, организациями, заказчиками и поставщиками, которым нужно обращаться к конфиденциальной информации через Интернет. Используя Интернет в качестве недорогой альтернативы применению арендуемых частных линий и корпоративных пулов модемов, можно сократить расходы до 80%.
VPN используется для передачи важной информации через незащищенную сеть, такую как Интернет, в шифрованном виде.

BorderManager VPN предусматривает гибкие возможности создания 2-х типов VPN:

Между двумя пунктами. Взаимодействующие друг с другом серверы в 2-х или более удаленных пунктах используют в качестве линии соединения Интернет. Это позволяет связать независимые сегменты локальной сети в единую интрасеть.

Клиент/сервер. Позволяет обращаться к ресурсам VPN через защищенное соединение в Интернет посредством кабельных модемов и по телефонным коммутируемым линиям по протоколу IP или IPX. Кроме того, пользователи получают возможность обращаться ко всем ресурсам интрасети из любого места с помощью однократного предъявления пароля.

Центром VPN является Master сервер. Мастер ≈ сервер поддерживает список подчиненных серверов, являющихся частью VPN. Добавление новых членов VPN возможно только на нем. Он также предоставляет криптографическую информацию, которая используется подчиненными серверами для генерации ключей шифрации. Каждая VPN может иметь только 1 мастер ≈ сервер.

Остальные участники VPN являются подчиненными серверами. Подчиненные серверы генерируют ключи шифрования на основе шифровальной информации, получаемой от мастер ≈ сервера. Каждый VPN сервер может быть членом только одного VPN одновременно.
VPN серверы инкапсулируют шифрованные IP или IPX пакеты в IP пакеты, которые передают информацию через Интернет или локальную интрасеть. Соединение, используемое для обмена этими IP пакетами, называется VPN туннелем или шифрованным туннелем.

VPN клиент ≈ это клиент, использующий телефонные линии для соединения с подчиненным либо мастер ≈ сервером по протоколу PPP (Point-to-Point Protocol). После установки соединения клиент имеет доступ к сети, защищаемой членами VPN. Клиент может звонить как напрямую на сервер VPN, так и использовать провайдеров для выхода в защищаемую сеть через Интернет.
BorderManager VPN выполняет аутентификацию всех пользователей с помощью NDS, допуская в VPN только тех, кто имеет соответствующие полномочия. Это ПО поддерживает различные стандарты туннелирования, шифрования и механизмы обмена ключами, включая IP SEC, SKIP, RC2, RC5, DES и 3DES, что создает сильную, но гибкую инфраструктуру VPN.

BorderManager VPN полностью поддерживает следующие типы соединений между членами VPN: ╚полная сеть╩ (mesh), ╚звезда╩ (star) и ╚кольцо╩ (ring). Выбор используемой топологии определяется типом и числом устанавливаемых соединений, потоками передаваемой информации. Соединение в любой из этих топологий может быть как односторонним (всегда инициализируется одним сервером), так и двусторонним (может инициализироваться любым сервером).

Топология mesh подразумевает непосредственное соединение между собой всех серверов (только 1 ╚hop╩ до каждого члена VPN). Она используется по умолчанию при установке BorderManager и наиболее защищена. Если 1 из членов VPN перестает работать, связь теряется только с одним этим сервером, остальные члены VPN продолжают работать. Также после того, как VPN полностью установлена, т.е. установлены все ключи шифрования, мастер ≈ сервер больше не требуется. Однако эта топология создает повышенный трафик в сети, поскольку каждый член VPN должен посылать обновления каждому другому члену VPN.

В топологии ╚звезда╩ мастер ≈ сервер выступает в роли центрального хаба. В плане трафика маршрутизации эта топология является наиболее оптимальной, но, поскольку мастер ≈ сервер выступает центральной точкой, он наиболее уязвим. При выходе из строя мастер ≈ сервера шифрованный туннель невозможно установить и VPN разрушается.
В топологии ╚кольцо╩ каждый член VPN соединен с ближайшим соседом. Пакет посылается от мастер ≈ сервера и, пройдя последовательно все подчиненные серверы, возвращается к мастеру.
Эта топология создает меньший трафик маршрутизации, чем полная сеть, и более надежна, чем звезда. Однако, у нее есть существенный минус ≈ сбор и обработка маршрутной информации требует значительного времени, кроме того члены VPN оказываются уже в разных сетях.

Основной конфигурацией при использовании VPN является конфигурация site-to-site, в которой защищенное соединение устанавливается между 2-мя серверами, расположенными в различных сетях. Есть несколько вариантов взаиморасположения VPN серверов и серверов, обеспечивающих безопасность IP сети.
Первый вариант ≈ сервер VPN используется одновременно и как пограничный сервер. Один и тот же сервер предоставляет и сервисы VPN, и защищает сеть в качестве брандмауэра. Также, когда брандмауэр и VPN совмещены на одной машине, значительно упрощается их администрирование. Когда же брандмауэр и VPN реализованы на разных машинах и разных ОС, то управление ими резко усложняется. Минусом является то, что совмещение функций пограничного сервера и VPN на одном сервере создает единую ╚точку падения╩ системы в случае серьезных атак извне.

Второй вариант ≈ VPN серверы располагаются и позади серверов, осуществляющих функции пограничного контроля. Преимущество данной конфигурации в том, что VPN узлы лучше защищены от различных атак извне. Установка VPN на отдельный высокоскоростной сервер увеличивает производительность VPN и не загружает при этом пограничные серверы. Отрицательной стороной является то, что необходимо 2 отдельных сервера и, следовательно, администрирование их усложняется.

VPN может использоваться и внутри интрасети. В этом случае 2 подразделения в корпоративной сети совместно используют важные данные, которые требуют шифрации при передаче даже по внутренней сети. В сравнении с предыдущими примерами преимуществом является то, что важные данные, с которыми работают определенные группы пользователей, защищены от других пользователей корпоративной сети. Важно это именно потому, что 80% всех попыток нарушения сетевой безопасности начинаются внутри интрасети.
VPN client-to-site предоставляет возможность территориально удаленному клиенту осуществлять обмен информацией, защищенной по всем правилам VPN. Есть 2 варианта этой конфигурации: доступ к VPN серверу через сеть коллективного доступа ≈ Интернет, или установление прямого соединения DialUp.
Клиент, используя протокол PPP (Point-to-Point Protocol), устанавливает соединение с провайдером Интернет и затем соединяется с VPN сервером через Интернет. Хотя использование провайдера  не гарантирует постоянную полосу пропускания и медленнее, чем прямое соединение по коммутируемым линиям, оно значительно дешевле. В дополнение к телефонной линии для прямого соединения необходимо поддерживать сервер удаленного доступа, модемы и другое необходимое оборудование.

Если провайдер Интернет поддерживает протокол PPTP (Point-to-Point Tunneling Protocol), то VPN клиент может использовать его для соединения с VPN сервером, как более защищенный.
Клиент может, используя протокол PPP, устанавливать DialUp соединение непосредственно с VPN сервером. Прямое PPP соединение гарантирует заданную полосу пропускания, но при этом оно значительно дороже и не намного быстрее соединения через провайдера Интернет.
VPN сервер, поддерживающий client-to-site VPN, может одновременно являться членом site-to-site VPN. В этом случае клиент может также получить доступ ко всем другим ресурсам site-to-site VPN и сетям, которые они защищают.

В экспериментах особое внимание было уделено конфигурации client-to-site, т. к. конфигурация site-to-site была отработана и проверена в предыдущих версиях BorderManager.
Для первого опыта использовалась  конфигурация на рис.1.

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

Результатом первого эксперимента было подтверждение обнаруженного впоследствии в TID факта взаимной несовместимости VPN BorderManager 2.1 и 3.х ≈ они используют различные методы шифрования.
Организация защищенных IPX сетей вызвала интерес с 2-х точек зрения. Во-первых, транспортным протоколом для передачи информации служит IP (т. е. канал между 2-мя узлами VPN формируется на основе протокола TCP/IP, в этом-то канале и передается трафик IPX). Во-вторых, настройки удаленного DialUp VPN-клиента под IPX имеют ряд особенностей.

Одной из наиболее интересных частей эксперимента была работа с VPN ╚клиент-сервер╩. Вариант ╚сервер-сервер╩ позволяет организовать защищенную связь между несколькими удаленными сетями, в каждой из которых есть хотя бы 1 сервер. В реальных условиях очень актуальной является задача организации защищенного канала связи между сервером и удаленно расположенным клиентом, располагающим только общественными (открытыми) линиями связи. Конфигурация стенда представлена на рис. 2.

На что обратить внимание при изначальной настройке? При установке VPN автоматически выполняется настройка фильтрации RIP пакетов, что позволяет скрыть внутреннюю структуру VPN. Устанавливаются 3 фильтра:

Фильтры, необходимые для нормального функционирования VPN, не должны удаляться. В крайнем случае, их можно восстановить с помощью Update VPN Filter опции NIASCFG.
Является ли VPN клиент самостоятельным продуктом или это ╚дополнение╩ к стандартному клиентскому ПО? Клиентское ПО VPN обеспечивает транспортный уровень модели OSI передачи данных, т. е. только устанавливает гарантированное соединение, а для аутентификации и дальнейшей работы требуется обычное клиентское ПО.

На клиентской части был установлен клиент NetWare 4.6 и VPN клиент NBMEE 3.5. Windows NT Workstation 4 впервые получила возможность выступать в роли клиента VPN от Novell (Service Pack 3 обязателен!). Для использования IPX потребовалось установить IPX Compatibility Mode ≈ режим совместимости IPX. Это привело к установке режима совместимости на сервере и драйвера режима совместимости на клиентской станции. Поскольку транспортным протоколом является IP, появляется еще 1 требующий указания параметр ≈ IP адрес VPN сервера.

Поскольку наибольшее в эксперименте внимание было уделено организации VPN ╚клиент-сервер╩, то уделим больше внимания настройке именно этого режима.

Клиент требует Windows 95, 98 или NT. Windows 95 дополнительно потребует MS Dial-Up Networking ISDN Accelerator Pack 1.1. Установка Novell Client версий 2.2.0.0 или более поздних должна быть произведена до установки ПО VPN клиента.
Для организации VPN-канала для IPX пакетов необходимо установить IPX адрес, который будет использоваться Dial-Up клиентом для доступа к серверу. Этот адрес не должен совпадать ни с одним из IPX адресов сервера. Впоследствии этот адрес можно будет наблюдать на панели VPN клиента. Можно организовать шифрованный IPX канал посредством инкапсуляции таких пакетов в IP пакеты. Однако можно одновременно организовать шифровку IP пакетов.

Не забывайте, что для использования VPN необходимо с помощью NWAdmin назначить и сконфигурировать доступ для соответствующих пользователей.
При регистрации дополнительно к стандартным 3-м параметрам (имя пользователя NDS, пароль и контекст) необходимо (согласно документации) указать IP адрес VPN сервера, но только в том случае, если IP соединение устанавливается через Интернет. На практике он требуется в любом случае.
При первом соединении с сервером тербуется убедиться в корректности аутентификационной информации: сравнить выведенное на экран значение ключа с ключем, сформированном администратором при формировании VPN клиента.

Особый интерес представляла конфигурация с доступом VPN клиента к серверу через DialUp соединение. Эта возможность появилась в Support Pack 2 для BorderManager 3 и стала базовой для BorderManager 3.5. Для организации Dial-Up соединения требуется установка на клиентской стороне MS Dialup Networking, т. к. именно с его помощью формируется ╚первичный╩ канал к серверу.

Последней задачей было определение затрат производительности на VPN. Исследование производилось на передаче больших объемов информации через VPN ╚клиент-сервер╩ через 10Мбит/с Ethernet локальную сеть. Аппаратная конфигурация клиента (Windows NT Workstation 4 c VPN клиентом) и сервера (NetWare 5 и BorderManager 3.5) одинаковы: Celeron 400MHz, 128 МБ ОЗУ, сетевая карта D-Link. Определение затрат производительности выполнялось по изменению показаний штатных средств ОС по измерению загрузки (Task Manager Windows NT и Monitor NetWare) при выполнении одних и тех же процедур с использованием обыкновенного клиента и клиента VPN. Наблюдения дали следующий результат: VPN потребляет примерно 10-15% процессорной производительности на клиентской станции и примерно 8-10% на сервере.
BorderManager представляет большие возможности по мониторингу VPN соединения как со стороны администратора, так и со стороны клиента.

Основным инструментом администратора по мониторингу VPN соединения является утилита NetWare Administrator. Через группу свойств VPN объекта ╚сервер╩, входящего в состав VPN, можно прежде всего увидеть статус сервера (Up-to-Date ≈ сервер сконфигурирован и участвует в VPN, Being Configured ≈ сервер еще не получил требуемой информации от мастер ≈ сервера VPN, Being Removed ≈ сервер удален из VPN).
Там же можно получить статистику активности выбранных членов VPN через окно VPN Activity, причем, для визуализации текущего состояния соединения используются направленные вверх и вних стрелки 5 различных цветов, что дает возможность уместить в одном экране большой объем информации. Кроме того, имеется возможность получить статистику по времени активности и объему переданной информации. Необходимо отметить, что в Border Manager 3.5 расширены возможности по формированию отчетов о работе VPN. Однако необходимо отметить, что Novell не позиционирует BorderManager 3.5, как провайдерский продукт, поэтому ряд статистических данных, существенных именно для этой категории пользователей, отсутствует.
Отдельное окно Security window позволяет получить информацию о применяемых методах шифрования и управления ключами.

Окно VPN Monitor window отражает статистику реального времени выбранных членов VPN и их туннельных соединений для  IPX или IP.
Контроль состояния клиентской части VPN удобно вести с помощью окна VPN Status and VPN Statistics клиента VPN (после установления VPN соединения иконка этого окна доступна через панель задач). Динамику функционирования VPN клиента можно отслеживать через окно VPN client Statistics.
И еще  совет: в документации к BorderManager 3.5 (которую можно получить на Web сервере Novell) в разделе, посвященном VPN, есть пункт Troubleshooting VPNs. Информация, приведенная в этом разделе, очень конкретна и не только способствует разрешению конкретных проблем, но и помогает понять многие принципиальные для работы с VPN моменты. Рекомендуем заглянуть туда до того, как проблемы возникнут ≈ тогда львиную долю их удастся избежать. Оттуда взят и список средств, которыми располагает администратор для решения проблем с VPN. Кроме утилит VPN client эти средства хорошо знакомы администраторам, и, если разобраться с VPN, их применение позволит быстро ликвидировать любую проблему:

 VPN -  крайне интересный компонент BorderManager, достойный гораздо пристального внимания, чем то, которое было ему уделено в ходе первого эксперимента. Члены NUG СПб приняли решение через некоторое время вернуться к этой теме для ее более глубокого исследования.

Говоря о VPN, нельзя не коснуться вопросов шифрования информации. BorderManagerVPN использует 128- и 40-битное шифрование. 40-битное шифрование используется в странах, где Novell не имеет права по законам США применять 128-битное кодирование. В настоящее время это ограничение пересмотрено, однако действуют ограничения закона России на применение средств шифрования информации. Для аутентификации и шифрования на сетевом уровне используется стандарт IPSEC, для управления ключами ≈ стандарт SKIP. Он определяет, через какое время (точнее, количество переданных пакетов) ключи аутентификации и шифрования будут автоматически заменены.

Кроме того, BorderManager VPN использует несколько методов шифрования (Triple DES, DES, RC2, RC5) и аутентификации  (SHA1 HMAC, SHA1 KEYED, MD5 HMAC, MD5 KEYED), различающиеся как алгоритмом, так и длиной ключа. Каждый сервер настраивается на использование конкретного набора методов, и на разных серверах эти наборы могут различаться ≈ это важно учитывать при объединении серверов в VPN.
В связи с этим, еще раз следует напомнить, что использование шифрования передаваемой информации в нашей стране требует лицензирования в компетентных органах (ФАПСИ). Поэтому использование VPN в любом виде требует осторожности, т. к. могут пострадать не только те, кто организовал себе защищенную сеть через Интернет, но и те, кто предоставил возможность воспользоваться общественным каналом ≈ т. е. Интернет-провайдером.  

В результате эксперимента рабочая группа подвела следующие итоги:

≈ Организация VPN между серверами с различными версиями BorderManager возможна только в рамках одного ╚поколения╩ этого продукта (2.1 ≈ с 2.1, 3.х ≈ с 3.х).
≈ Большинство проблем с установкой BM устраняются тщательным соблюдением документации по инсталляции.
≈ Организация защищенных IPX сетей на основе VPN требует использования инфраструктуры протокола IP.
≈ При использовании VPN в локальных сетях целесообразно формировать выделенные сегменты, передачи информации по которым осуществляется только через VPN.
≈ VPN ╚сервер-клиент╩ через Dial-Up является эффективным средством организации защищенного взаимодействия мобильных пользователей.
≈ Применение VPN как на сервере, так и на клиенте несущественно сказывается на их производительности и эта зависимость может быть игнорирована.


  КОМПЬЮТЕР-ИНФОРМ 
    Главная страница || Статьи ╧ 3'2000 || Новости СПб || Новости России || Новости мира

Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка

Главная страница

Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл ╧ 77-4461 от 2 апреля 2021 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.

Телефон редакции (812) 118-6666, 118-6555.
Адрес: 196084, СПб, ул. Коли Томчака, д. 9
e-mail:
Для пресс-релизов и новостей