Современные средства защиты данных настолько разнообразны, что способны функционировать на любом уровне стека протоколов и размещаться в любом месте корпоративной сети. Тем не менее наиболее популярным вариантом организации защищенных соединений между удаленными офисами становится применение шлюзов виртуальных частных сетей (VPN), поддерживающих протокол IPSec.

В ходе тестирования 13 продуктов данной категории мы интересовались и традиционными характеристиками (такими, как производительность, простота управления и поддержка функций, совершенно необходимые в корпоративных сетях), и способностью изделий разных фирм взаимодействовать друг с другом. В целом результаты испытаний оказались довольно близкими и ни один из шлюзов не стал победителем во всех категориях. Как можно видеть из табл. 1, оценки примерно половины продуктов отстоят друг от друга не более чем на одну десятую балла, поэтому на сей раз «Голубую ленту» победителя мы решили не присуждать никому.

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

Приступая к испытаниям, мы сгенерировали гипотетический набор правил обеспечения безопасности для крупной многосегментной сети, а затем попытались выяснить, насколько удачно каждый из VPN-продуктов «вписывается» в такую сеть. Мы проверяли способность пар шлюзов к взаимодействию друг с другом как на стадии формирования защищенного соединения, так и в процессе обмена данными в течение нескольких дней. Отдельные продукты оценивались на предмет взаимодействия с другими изделиями, с установленным нами средством выдачи сертификатов (Certificate Authority) и с популярными клиентскими приложениями VPN; кроме того, нас интересовала поддержка различных методов аутентификации в сети VPN.

Нами была предпринята и попытка заставить шлюзы работать в полносвязной топологии. Очевидно, что любой производитель, повозившись с конфигурацией своего продукта, обеспечит его взаимодействие с конкретным изделием другой фирмы. Полносвязная топология позволила «обойти» эти компромиссные парные настройки и выявить, «кто чего стоит» в действительно гетерогенной среде. Лучше других тест на совместимость прошел программный шлюз Sidewinder производства Secure Computing. Впрочем, от него не очень сильно отстали разработки Avaya, Check Point Software, Cisco, Microsoft, Nortel и Nokia.

Хотя по сумме объективных оценок, выставлявшихся в соответствии с заранее определенными критериями, фирма Cisco вышла в «передовики», у ее продуктов обнаружились серьезные недостатки. Для настройки конфигурации компания предлагает исключительно интерфейс командной строки. Возможно, кто-нибудь из администраторов будет в восторге от такого решения, зато проектировщики сетей VPN не испытают особой радости. Стремясь упростить управление сетью VPN при помощи командной строки, разработчики из Cisco Systems не нашли ничего лучшего, как ограничить в каждой системе поддержку инфраструктуры обмена ключами (Internet Key Exchange, IKE) единственным набором правил. Для тестирования этого вполне достаточно, но как быть тем администраторам, которые для любого удаленного офиса устанавливают свою стратегию IKE? Инсталлировав клиентское ПО компании Safenet, мы были вынуждены разрушить конфигурацию устройства Cisco PIX 525: оно способно работать либо с выбранным набором правил, либо с указанным приложением, но никак не с тем и другим одновременно.

Чтобы воспользоваться на стадии аутентификации участников соединения цифровыми сертификатами, мы установили сервер открытых ключей (PKI) фирмы Entrust. Однако в методах взаимодействия с ним отдельных VPN-шлюзов обнаружился значительный разнобой. Скажем, продукты Sidewinder и Contivity 1600 производства Nortel и VPN-1 от Check Point гарантируют полный контроль администратора за тем, кто входит в корпоративную сеть и к каким ресурсам получает доступ. Три перечисленных шлюза позволяли с любой степенью детализации определять, какие типы сертификатов необходимы для входа в сеть. Напротив, устройствам Access Point 1000 компании Lucent Technologies, PIX 525 и 7140 VPN Router корпорации Cisco (на оба шлюза устанавливается операционная система IOS) подобной строгости явно недостает: один раз получив цифровой сертификат от PKI-сервера, вы можете организовывать VPN-соединения с кем угодно. Такой подход губителен для экстрасетей. Их пользователи обычно обращаются к разным серверам PKI, поэтому место получения цифрового сертификата имеет не меньшее значение, чем его содержимое.

Наконец, VPN Server Appliance корпорации Hewlett-Packard, RapidStream 2000 одноименной фирмы, Ravlin 7160 компании RedCreek и FireBox III 4500 производства WatchGuard вообще не прошли тест на работу с сертификатами. Два последних продукта не поддерживают обращение к внешнему «органу» сертификации в процессе аутентификации взаимодействующих сторон.

Система Windows 2000 Server фирмы Microsoft, снабженная встроенными средствами VPN, и уже упоминавшееся устройство Access Point корпорации Lucent сертификаты поддерживают, однако обмен сертификатами с другими продуктами вызвал серьезные проблемы. Скажем, чтобы заставить изделие Lucent «общаться» с продуктами Avaya и Nokia, нам пришлось обратиться к наиболее распространенной (но, очевидно, не вполне надежной) схеме, поддерживающей использование предварительно согласованных секретных ключей. А взаимодействие с Cisco PIX 525 вообще оказалось невозможным.

Протокол IPSec реализован в продукте HP таким образом, что процесс конфигурации показался нам весьма странным. Защищенные виртуальные каналы (Security Association, SA) надо либо инициировать всякий раз, либо не инициировать совсем. В противном случае при обмене ключами возникают коллизии. Но в сети, соединяющей разные офисы, такой вариант, мягко говоря, неудобен. Работая с Server Appliance, мы потратили уйму времени на поддержание защищенных каналов.

В отношении возможностей взаимодействия нечем похвастать и продуктам WatchGuard и RapidStream. В первом случае принимаемая по умолчанию (и неизменяемая!) стратегия безопасности не обеспечивает защиты соединений, поскольку для шифрования используются обычный протокол DES (вместо Triple-DES) и алгоритм Диффи — Хеллмана первой группы. Чтобы совладать со столь негибким шлюзом Firebox III 4500, нам пришлось перестраивать конфигурацию всех остальных изделий. Что же касается разработки фирмы RapidStream, ее поведение оказалось на редкость нестабильным: в одних случаях все шло как по маслу, в других же распознавались только защищенные каналы, а трафик по ним не транспортировался.

Корпоративное администрирование

По мере перехода от пилотных проектов к реальным сетям настройка конфигурации и администрирование десятков, а то и сотен устройств VPN превращается в серьезную проблему. Из протестированных шлюзов лишь разработки Avaya, Check Point и Nokia позволяют управлять сложной (включающей в себя оборудование нескольких компаний) средой VPN при помощи графического интерфейса. В процессе испытаний мы обращали внимание на то, как реализована в средствах управления поддержка устройств того же производителя и в какой мере эти средства способствуют взаимодействию продуктов разных фирм.

Доминирование Avaya и Nokia над конкурентами обнаружилось довольно быстро. Для описания топологии соединений VPN в обоих случаях используются простые «строительные» блоки, так что формирование и модификация гетерогенной среды VPN, а также управление ею не вызывает затруднений. GUI-интерфейс VPN Policy Manager компании Nokia позволяет создавать довольно сложные топологии, в которые входят комбинации концентраторов, соединенных между собой ячеистых сегментов и отдельных туннелей между двумя произвольными системами.

Спектр топологий, реализуемых графическим интерфейсом VPN Manager GUI компании Avaya, не столь широк, зато здесь налицо прекрасная серверная поддержка. Построенный на базе сервера LDAP управляющий инструментарий позволяет сразу нескольким администраторам, находящимся в разных участках сети, просматривать параметры конфигурации сети VPN, редактировать их и активизировать изменения.

Средства администрирования, реализованные корпорацией Nortel в устройстве Contivity 1600, обладают схожими возможностями, но не позволяют размещать в каждом сегменте сети более одного крипто-шлюза.

Мы испытали и недавно появившийся продукт версии VPN-1 от Check Point. Нас приятно удивил тот прогресс в области настройки конфигурации и администрирования сетей VPN, которого удалось добиться фирме за время, прошедшее после выпуска версии 4.1. Теперь интерфейс Policy Editor GUI позволяет оперировать заметно большим числом сценариев взаимодействия, а кроме того, появилась возможность генерировать ячеистые топологии VPN. И даже несмотря на обнаружившиеся ошибки в новом ПО, нельзя не признать: разработчики Check Point стали уделять серьезное внимание поддержке крупных виртуальных частных сетей.

Управляющий инструментарий от Check Point допускает также интеграцию правил функционирования брандмауэра с настройками VPN. И хотя число поддерживаемых протоколов и функций здесь меньше, чем, скажем, в продукте Lucent, охвачено не менее 90% конфигураций, которые встречаются на практике. Возможность сформулировать единое правило для фильтров брандмауэра и VPN-туннелей играет ключевую роль в объединении этих двух технологий сетевой безопасности.

Когда дело дошло до проверки управляемости продуктов, выяснилось, что от некоторых средств администрирования проку немного. Например, приложение Optivity корпорации Nortel обеспечивает надежный дистанционный «присмотр» сразу за несколькими устройствами Contivity, однако не позволяет настроить или изменить конфигурацию VPN-соединений между двумя офисами, даже если в них установлено только оборудование Nortel. Это тем более досадно, что реализованные данной фирмой средства управления отдельными компонентами сети (с локального Web-сервера, загруженного на Contivity) показались нам лучшими. Если бы Nortel распространила «сферу компетенции» своего административного инструментария на гетерогенные среды, ее продукт стал бы единоличным лидером в данной категории.

Поставляемое за дополнительную плату ПО QVPN Builder корпорации Lucent, обеспечивающее графический интерфейс, неплохо справилось с управлением сетью VPN-устройств как единой «коробкой». Однако при этом проявился один серьезный недостаток: продукт работоспособен лишь при условии, что в сети установлены исключительно шлюзы Access Point той же фирмы. В результате при настройке конфигурации нам ничего не оставалось, как вернуться к интерфейсу командной строки (его использование одновременно с QVPN Builder невозможно).

Аналогичное ограничение обнаружилось и у инструментария компании HP: при помощи весьма примитивных средств действие одного набора правил можно распространить сразу на несколько систем, но интегрировать в сеть продукты, выпущенные другими фирмами, не удастся. Недалеко ушло и приложение VPN Manager от WatchGuard, поставляемое в качестве опции. Особенно разочаровывает то, что параметры брандмауэра нельзя ввести в конфигурационные настройки VPN, ведь сама настройка брандмауэра WatchGuard на редкость проста и интуитивна.

А вот управление сетями VPN с помощью средств компании Microsoft никак не назовешь ни простым, ни интуитивным. Вы, конечно, можете определить единую стратегию IPSec и распространить ее на несколько систем (правда, все они должны являться серверами под Windows 2000), но сам по себе GUI-интерфейс является неоправданно громоздким. Долго провозившись с 92(!) экранными формами, мы так и не поняли, превосходит ли данный продукт хотя бы одного из своих конкурентов.

Новый инструментарий Cisco Secure Policy Manager порадует любого администратора, который планирует использовать Cisco PIX или устройства, работающие под управлением IOS, в сети VPN или в качестве брандмауэра. Синтаксис нового продукта слегка отличается от такового в IOS и PIX (а потому несовместим с ними). Тем не менее он набрал достаточно баллов благодаря умению создавать и синхронизировать правила работы брандмауэров и систем обнаружения несанкционированных вторжений в сеть, содержащую множество продуктов Cisco. Впрочем, в данном случае уметь еще не означает «делать это оптимальным образом».

В Cisco Secure Policy Manager имеется встроенный инструментарий для формирования VPN-туннелей. Поддерживаются как ячеистая, так и разделяемая топологии. К сожалению, данное ПО не умеет «общаться» с оборудованием других производителей. Чтобы обмануть его, устройства прочих фирм приходится описывать как выпущенные Cisco Systems. Более существенный недостаток — конфигурация VPN недостаточно интегрирована с правилами работы брандмауэров.

Производительность

Значения производительности VPN-устройств изменялись в широких пределах. В одних случаях компании намеренно занижают характеристики быстродействия определенных продуктов, надеясь стимулировать спрос на более дорогое оборудование, в других — сознательно завышают их, стремясь достойно выглядеть на фоне конкурентов. Мы не собирались осуществлять «прогон» полного набора тестов на производительность, однако воспользовались возможностью запустить на каждом продукте несколько коротких эталонных утилит и сравнить показатели.

По сути дела, тестов было три: имитировались наилучшие и наихудшие параметры трафика, а также смешанный вариант, в котором воспроизводились типичные потоки данных Internet (табл. 2). В последнем случае мы формировали поток данных с характеристиками, «заимствованными» у трафика Internet-магистралей: 50% коротких пакетов (длиной до 96 октетов), 10% длинных (1518 октетов — максимальный блок данных в сети Ethernet), 20% пакетов среднего размера (576 октетов — типичный блок данных глобальной сети), наконец, 20% смеси пакетов среднего размера (от 192 до 1024 октетов).

Как оказалось, при скоростях дуплексной передачи ниже 10 Мбит/с все шлюзы успешно справляются с предъявляемой нагрузкой; наилучшие показатели продемонстрировали продукты Avaya, Nortel, RapidStream и Microsoft. Подняв полосу пропускания до 45 Мбит/с (DS-3, дуплексная передача), мы обнаружили: только устройства Access Point фирмы Lucent, снабженные двумя криптографическими ускорителями, и пара серверов под Windows 2000 с установленными криптографическими адаптерами Pro/100S от Intel способны передавать трафик со скоростью 90 Мбит/с, достижение которой считалось условием прохождения теста. А модернизировав аппаратную «начинку» каждого из указанных серверов (что обошлось еще в 200 долл.), мы смогли довести скорость передачи трафика с использованием протокола IPSec до 160 Мбит/с, правда, при транспортировке только больших пакетов. Если принять во внимание низкие цены на компьютеры с процессорами Pentium, операционную систему Windows 2000 и сетевые адаптеры фирмы Intel, можно констатировать: по соотношению цена/производительность продукт Microsoft обгоняет конкурирующие разработки в 10 — 20 раз. Впрочем, мы заметили, что приведенные для Windows 2000 значения были достигнуты при наличии только шести защищенных каналов IPSec. Если же увеличить их число до 500, производительность резко упадет — примерно до 8 Мбит/с для смешанного Internet-трафика.

Продукт фирмы Nokia допускает использование режима разделения нагрузки. Мы протестировали его в двух конфигурациях — как единственное автономное устройство CryptoCluster 2500 и кластер из трех таких устройств. Результат превзошел все наши ожидания: производительность росла практически линейно с увеличением размера кластера.

Широта продуктовых линеек

Администраторам корпоративных сетей частенько приходится использовать в единой среде самое разное оборудование — от модемов коммутируемого доступа до устройств, поддерживающих передачу по интерфейсу OC-3 (155 Мбит/с). Соответственно, в сетевом мире не существует решений, пригодных на все случаи жизни. Это обстоятельство придает особую значимость возможности взаимодействия оборудования различных поставщиков. Например, устройства компаний RedCreek и WatchGuard, ориентированные на сектор SOHO, могут появиться и в отдельных частях крупной сети, но лишь при условии, что они сумеют «общаться» с такими гигантами, как Nokia 5205.

В то же время построение всей сети на базе оборудования одной фирмы облегчает администрирование, причем весьма существенно, и в этом смысле наличие в арсенале производителя устройств разного «калибра» должно рассматриваться как несомненный плюс. Приведенные соображения заставили нас учесть при выставлении итоговых оценок спектр устройств, входящих в семейство VPN-продуктов конкретного производителя. Рассматривалось наличие в линейке изделий как систем для крупных центров обработки данных, требующих шифрования огромного количества пакетов, так и недорогих изделий для рынка SOHO. Кроме того, принималась во внимание возможность поддержки сред передачи, отличных от Fast Ethernet, ведь наличие таких интерфейсов глобальных сетей, как E1/E3 или ISDN, позволяет снизить суммарные затраты заказчика, а поддержка Gigabit Ethernet важна для подключения центров обработки данных.

Безусловным победителем по этому показателю стала Cisco Systems и ее система IOS. Более десятка базовых шасси, широкая палитра продуктов (от изделий стоимостью менее 1000 долл. до устройства GSR 12000, цена которого выражается шестизначным числом), множество интерфейсов (от аналогового модема до Gigabit Ethernet) — все это говорит само за себя. Следует заметить, однако, что в данном случае высокие баллы еще не являются гарантией достаточной гибкости продукта, поэтому мы настоятельно рекомендуем потенциальным заказчикам точно определить со свои потребности в возможностях аппаратных средств и поддерживаемых ими скоростях передачи. Так, продукт PIX 525 фирмы Cisco получил высокую оценку благодаря разнообразию одновременно поддерживаемых интерфейсов, а CryptoCluster 2500 компании Nokia — в свзи с поддержкой широкого диапазона скоростей передачи (интерфейса у него всего два).

Основной вывод, который позволяют сделать результаты нашего исследования, сводится к следующему: сегодня на рынке VPN-оборудования вполне хватит места дюжине поставщиков. Любой из протестированных нами продуктов имеет свои достоинства и недостатки (табл. 3), а кроме того, создавался с ориентацией на определенные тип сетей, стиль администрирования, параметры VPN-соединений и набор пользовательских требований.

Джоул Снайдер (Joel.Snyder@opus1.com.) — член Network World Global Test Alliance и партнер компании Opus One.


Процедура тестирования

Среда тестирования имитировала несколько центров обработки данных и удаленных офисов с установленными в них коммутаторами, маршрутизаторами и брандмауэрами (типичный вариант корпоративной СПД). Для формирования этой среды использовались продукты компаний Cubix и Spirent Communications. Система Cubix Density со специальным ПО позволила создавать VPN-туннели, контролировать наличие соединений между шлюзами, измерять время установления соединений и выводить на экран полную матрицу соединений.

Профиль IPSec, применявшийся в ходе тестирования, на наш взгляд, соответствует тому, который всякий здравомыслящий администратор составил бы для своей корпоративной сети. В качестве схемы шифрования передаваемых ключей был предусмотрен алгоритм Triple-DES. Аутентификация проводилась с помощью метода хеширования SHA-1 на основе алгоритма Диффи — Хеллмана Group 2 (MODP-1024); время жизни ключей составляло 8 ч. Те же самые методы были выбраны и при использовании протокола IPSec, только на сей раз время жизни ключей равнялось 1 ч.

Для аутентификации сторон, устанавливающих защищенный канал (SA), мы воспользовались сервером открытых ключей (PKI) компании Entrust. Именно он позволял рассылать цифровые сертификаты отдельным шлюзам безопасности. В настоящее время фирме Entrust принадлежит львиная доля данного сегмента рынка, и мы ожидали, что ее разработка будет поддерживаться всеми устройствами — по крайней мере в режиме ручной регистрации. Оказалось однако, что часть продуктов поддерживают простейший протокол регистрации сертификатов сервером Entrust PKI, другие требуют ручной регистрации, а в некоторых случаях цифровые сертификаты шлюзом не поддерживаются вовсе (аутентификацию пришлось проводить при помощи заранее разосланных «секретов»).

Для измерения производительности отдельных продуктов мы сформировали конфигурацию из шести шлюзов CryptoGluster 2500 компании Nokia. Этого оказалось достаточно, чтобы в режиме дуплексной передачи полностью «забить» 100-Мбит/с сеть Ethernet 64-октетными пакетами. Для генерации UDP-пакетов различной длины использовались устройство Smartbits и коммерческое программное обеспечение. Значения производительности приведены в табл. 2 с точностью 2 Мбит/с; они соответствуют тому моменту, когда доля потерянных пакетов впервые превысила 0,1%.


Совместимость клиентов

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

Существует по крайней мере две компании, специализирующиеся на разработке взаимодействующих клиентов, которые обеспечивают безопасный доступ к корпоративным сетям по протоколу IPSec. Фирма Safenet (бывшая IRE) по OEM-контрактам поставляет клиентское ПО под Windows множеству изготовителей оборудования для виртуальных частных сетей. Подразделение PGP компании Network Associates предлагает версии клиентского приложения IPSec под Windows и Macintosh. В небольшом тесте на взаимодействие мы пригласили поучаствовать Safenet.

Результаты оказались неоднозначными. Никаких проблем не возникло со шлюзами производства Nokia и Check Point, которые с самого начала «расценили» продукт Safenet в качестве стопроцентно совместимого клиента. Шлюзы компаний Nortel, Lucent, Cisco и Secure Computing также «пообщались» с клиентами от Safenet, но прежде нам пришлось внести небольшие изменения в профили защиты данных. А вот шлюзы доступа от Avaya, Microsoft и HP «не воспринимают» клиентов, выпущенных другими фирмами. Нам удалось заставить их работать, выдав клиентов за шлюзы со статическими IP-адресами. Понятно, что такой фокус никак не назовешь удачным решением проблемы удаленного доступа. Наконец, конфигурация некоторых продуктов, включая PIX 525 компании Cisco, оказалась настолько негибкой, что взаимодействия с клиентом удалось добиться, только разорвав соединение между сетевыми сегментами.