Виртуальные частные сети: только между нами

Все, что вы хотели знать о виртуальных частных сетях, в том числе три новейшие стратегии.

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

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

Действительно ли VPN сводится только к блеску в глазах у скаредных администраторов глобальных сетей?

Конечно, замена выделенных линий на Internet (даже с учетом непредсказуемости производительности) ведет зачастую к экономии средств, но это далеко не единственная причина, по которой VPN привлекает все более пристальное внимание: технология виртуальных частных сетей позволяет "отдавать на сторону" коммутируемую часть сервисов удаленного доступа и делает архитектуру глобальных сетей более гибкой, нежели это когда-либо было возможно. И дело тут в том, что новые глобальные сети используют общедоступные сети передачи данных (data cloud).

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

ОТКРОЙ УМ СВОЙ

Основную концепцию виртуальных частных сетей понять легко: Internet следует использовать для передачи пакетов тогда, когда иначе прокладки или аренды кабеля не избежать. Однако из-за путаницы в терминологии разобраться в деталях технологии VPN непросто. Прежде всего, это применение самого термина VPN. Изначально данный термин применялся в телефонных сетях, но здесь он не имеет ничего общего с Internet VPN, за исключением того, что концептуально его смысл тот же. Кроме того, когда операторы дальней связи стали предлагать сервисы frame relay, они использовали имя VPN для описания виртуальных каналов, соединяющих конечные точки. Это значение близко по смыслу к использованию Internet в качестве облака, через которое данные передаются из вашей глобальной сети, что все же не одно и то же.

Два применения VPN в Internet - "вынос" точек удаленного доступа и продолжение глобальной сети - имеют не так уж много общего друг с другом, в результате разговор о VPN становится еще более запутанным, поэтому в данной статье они рассматриваются отдельно.

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

СТАНДАРТ НА ПРОИЗВОДИТЕЛЬНОСТЬ

Несмотря на различие в подходах к VPN и вытекающий отсюда разнобой в стандартах и акронимах, общие моменты, несомненно, существуют. Например, применение виртуальной сети ведет к вынужденному компромиссу в отношении производительности и защищенности сети.

Internet обеспечивает "наилучшую возможную" производительность. Сеть передает пакеты от одного узла к другому по наилучшему доступному маршруту, при этом она не дает никаких гарантий - даже гарантии доставки пакета. Несмотря на то что множество внутренних корпоративных сетей работают по тем же самым правилам (если взять наиболее распространенный протокол в корпоративных сетях, IPX, то он не гарантирует ни определенный уровень производительности, ни даже доставку), однако такие сети поддаются гораздо более жесткому контролю. Например, число активных узлов в сегменте является известной величиной, а это, в общем-то, гарантирует определенную часть полосы пропускания. При подключении внутренних сегментов к глобальной сети и выделенные линии на 56 Кбит/с, и технологии frame relay обеспечивают лишь минимальный уровень производительности.

Для некоторых корпоративных пользователей отсутствие гарантированной производительности не представляет непреодолимой проблемы - например передача электронной почты от одного сервера к другому может и не сопровождаться задержками. Кроме того, два возможных решения уже маячат на горизонте. Во-первых, некоторые компании (в частности операторы дальней телефонной связи) предлагают альтернативные магистрали Internet по передаче пакетов только между коммерческими клиентами. Во-вторых, Группа инженерной поддержки Internet разрабатывает протокол для резервирования IP-соединениями минимального уровня услуг. Кстати говоря, протокол резервирования ресурсов (Resource Reservation Protocol, RSVP) имеет ряд параметров для задания качества услуг, причем он достаточно проработан, так что ограниченного внедрения этого протокола можно ожидать уже в этом году.

Даже если пользователей удовлетворяет предоставляемая Internet производительность, все же остается вопрос защиты информации. Джон Кунс, главный аналитик по технологиям глобальных сетей в Dataquest, считает эту проблему чрезмерно раздутой. "Любопытно, - говорит он, - что компании, никогда не задумывавшиеся о защите трафика при его передаче по выделенным линиям, принадлежащими операторам дальней связи, уверены, что их данные будут менее защищены, когда они передаются в виде IP-пакетов по линиям и через маршрутизаторы, владельцами которых являются те же самые операторы".

Как указывает Кунс, трафик с двух сторон VPN проходит обычно через не такое уж большое число маршрутизаторов. Кроме того, трафик передается отнюдь не в виде одного легко идентифицируемого потока, как в случае выделенной линии. "Чтобы отфильтровать и собрать пакеты для подслушивания шифрованного соединения по VPN, - объясняет Кунс, - вы должны быть как минимум оператором сети и обладать довольно сложным оборудованием". Однако он добавляет, что "общественное мнение считает соединения через Internet чрезвычайно уязвимыми".

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

КОПЕЙКА РУБЛЬ БЕРЕЖЕТ

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

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

До сих пор мы говорили только об удаленных вычислениях, теперь настала пора поговорить о виртуальных сетях. Иначе говоря, мы хотим переставить модем из центрального узла на узел оператора Internet ближе к удаленному пользователю.

Для этого мы должны создать новое соединение между модемом и центральным узлом, причем сделать это с помощью Internet. Таким образом, соединение стоит ровно столько же, сколько и доступ к Internet, но что касается цены, расстояние между центральным офисом и удаленным пользователем не имеет в этом случае значения.

Гипотетически, если локальная сеть центрального узла представляет собой сеть IP, то на этом наша работа завершена. Клиентское приложение пользователя "говорит" на IP с серверами сети, и трафик, предназначенный удаленному пользователю, отбирается маршрутизатором для отправки по сети на IP-адрес, который пользователь получил от оператора Internet.

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

Даже если поставщик возьмет на себя часть вышеперечисленных проблем, это еще не все. Мы начали с предположения, основанного на том, что внутренняя сеть - это IP-сеть. Вобщем-то, корпоративная сеть не обязательно использует IP. Таким образом, вы должны обеспечить работу центральной сети с IP.

Несмотря на все эти проблемы стимул по применению VPN для организации удаленного доступа все же довольно силен. Как говорит Кунс из Dataquest: "Удаленный доступ очень тяжело и дорого поддерживать, особенно когда это надо делать круглосуточно по междугородним линиям. Internet - это дешевая и всеохватывающая среда передачи".

ДОСТУП ПО ТЕЛЕФОННОЙ ЛИНИИ

Две отраслевые инициативы должны сделать VPN еще более жизнеспособной стратегией. Одна инициатива, предложенная среди прочих Microsoft и Ascend, - это Point-to-Point Tunneling Protocol (PPTP); другая, предложенная Cisco, - Layer Two Forwarding (L2F).

В конце прошлого года обе фракции достигли соглашения, что объединение желательно и возможно. Когда вы будете читать нашу статью, они должны уже будут создать комбинированный протокол под названием Layer Two Tunneling Protocol (L2TP). В данной статье мы будем рассматривать обе инициативы как одну.

При туннелировании процесс ответа модема на телефонный звонок отделяется от этапа регистрации пользователя. В случае L2TP модемное соединение осуществляется с оператором Internet, а процесс идентификации перепоручается выделенному серверу в сети Internet. В настоящее же время и ответ на звонок, и регистрация пользователя производятся на узле оператора Internet. После установления соединения все будет выглядеть так, как будто модем располагается прямо в центральной сети.

Разделение работы модема на физическом уровне и процесса установления соединения на канальном уровне (в проекте стандарта IETF это называется "разъединение функций NAS") дает весьма любопытные преимущества над методом PPP. (Проект IETF можно найти на узле Web по адресу: http://ds.internic.net/internet-drafts/draft-ietf-pppext-pptp-00.txt.)

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

Ввиду того, что путешествующие между удаленным узлом и внутренней сетью пакеты помещаются в IP-конверты (т. е. они туннелируются), отличные от IP протоколы (IPX, AppleTalk и SNA) можно передавать по IP-сети Internet.

НЕ ТОЛЬКО L2TP

Если Microsoft представляет и поддерживает какой-либо проект стандарта для Internet, то наверняка есть еще один или два альтернативных метода - добровольных камикадзе. В данном случае такая альтернативная стратегия предложена компанией Aventail, считающей, что последняя версия протокола шифрования IP от 1990 года как нельзя лучше подходит для задачи построения VPN.

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

По словам Каплана, в случае SOCKS пакеты пересылаются между клиентом и сервером, причем последний контролирует доступ в градационной форме. PPTP нацелен на доставку пакетов от точки до точки - одномоментно. SOCKS контролирует трафик. На Рисунке 2 показано, как идентификация клиента организована в SOCKS.

Несмотря на то что и L2TP, и SOCKS облегчают жизнь удаленных пользователей, эти стратегии туннелирования не обязательно лучшее решение проблемы организации соединения между сетями. Дело тут в том, что как в случае L2TP, так и в случае SOCKS соединение между сетями при помощи VPN предполагает организацию множества туннелей через глобальную сеть. По существу все настольные системы в одной сети будут индивидуально организовывать прямые и обратные туннели через виртуальную локальную сеть с машинами на другом конце соединения, а это означает, что придется договариваться о туннеле каждый раз при открытии сеанса.

В филиалах, например, сотрудников, как правило, немного, а соединения предопределены и стабильны, поэтому в данной ситуации L2TP или SOCKS реализовывать и не обязательно. Как минимум, средства шифрования можно встроить в маршрутизаторы в каждой конечной точке. Именно это по сути и делают основные поставщики. Например, Cisco Systems представила линию продуктов PixLink для реализации аппаратного шифрования в маршрутизаторах старшего класса. Bay Networks и другие готовят аналогичные предложения.

Маршрутизаторы фильтруют предназначенный маршрутизатору на другом конце трафик и шифруют эти пакеты на лету. Трафик, предназначенный получателю с внешним для внутренней сети адресом в Internet, посылается как есть, без шифрования.

ВИРТУАЛЬНОЕ БУДУЩЕЕ

Ричард Каган, вице-президент по маркетингу в компании VPNet, говорит, что повышенное внимание к замене линий на 56 Кбит/с для экономии нескольких долларов оставляет за кормой настоящие преимущества виртуальных локальных сетей. "Взгляд на VPN, как средство экономии денег, представляется мне недалеким, и я думаю, что такая непосредственная польза от VPN гораздо менее важна, чем стратегическое значение того, что компании осуществляют связь со своими партнерами и клиентами при помощи VPN".

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

Каган добавляет: "В то же время мы все имеем или собираемся иметь выход в Internet. Почему же не использовать инфраструктуру Internet, как средство обмена такого рода информацией?"

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

Для этого VPNet представила то, что она называет VPLink - архитектуру для организации согласованных защитных и сетевых сервисов в гетерогенной среде (см. Рисунок 3). Ядро VPLink - это асинхронный интерфейс Secure Networking Applications Programming Interface (SNAPI), с помощью которого общий набор защитных и сетевых сервисов может быть реализован в различных точках континуума сети. Сервисы, вызываемые через SNAPI (например шифрование предназначенных другому узлу VPN пакетов), могут быть реализованы в аппаратных устройствах, программных модулях, микропрограммном обеспечении и интегральных схемах ASIC.

Каган утверждает, что архитектура VPLink интересна и без SNAPI, потому что она обеспечивает быстрое сжатие перед тем, как IP-пакеты отправляются в общедоступную сеть. Обычно шифрованный пакет помещается внутри другого IP-пакета. Как следствие, такой пакет получается несколько длиннее, поэтому для передачи по Internet его, как правило, разбивают на два. По словам Кагана, предварительное сжатие позволяет освободить место для заголовка, чтобы число передаваемых пакетов не увеличивалось.

Сжатие реализуется аппаратно или программно в зависимости от применения; на данный момент реализация VPLink в предлагаемом VPNet продукте достаточно быстра для работы по линии T-3. Что касается более медленных каналов, то в VPNet уверены, что даже при программной реализации сжатие производится достаточно быстро, так что дополнительное оборудование не нужно.

Однако пока предложение процесса программного шифрования для применения на линиях ISDN и более медленных не прошло необходимой проверки на практике. Сегодня VPNet предлагает два аппаратных компонента для установки на границе внутренней сети между последним маршрутизатором и внешней сетью. Устройство должно быть установлено по обе стороны соединения, и все выглядит так, как будто шифрующий маршрутизатор установлен на каждом конце. Каган говорит, что программная версия появится в середине 1997 года.

ОКОНЧАТЕЛЬНО И БЕСПОВОРОТНО?

Положение дел таково, что об едином подходе к организации VPN говорить пока рано - кроме того, на горизонте другая потенциальная стратегия: группировка соединений в зависимости от виртуализованных связей между узлами может быть включена непосредственно в транспортный протокол, а это означает, что виртуальные частные сети не будут восприниматься как замена реальной корпоративной глобальной сети. Наоборот, возможность организации связи через VPN станет обыденным делом в Internet.

Интересно - и немного пугающе - как тогда будет выглядеть администрирование сети.