Кузьменко Н.Г. Коммутаторы и IP телефония

Подождите немного. Документ загружается.

страль провайдера службы типа Internet Protocol, Frame Relay, ATM или Inter-

net. На практике используются три типа VPN сетей:

VPN сети удаленного доступа. Эти сети предоставляют удалённый до-

ступ пользователям корпоративной интранет или экстранет сети с использо-

ванием тех же политик, какие используются в частой сети. VPN сети удалён-

ного доступа, при необходимости, предоставляют пользователям доступ к

корпоративным ресурсам в любое время, в любом месте и любым способом.

Для обеспечения безопасного соединения мобильных пользователей и филиа-

лов предприятия, VPN сети удалённого доступа могу использовать аналого-

вую телефонную линию, сеть интегрированных цифровых служб ISDN. циф-

ровые абонентские каналы DSL. мобильные IP-телефоны и кабельные техно-

логии.

Частные виртуальные интранет сети. Такие сети соединяют между

собой головной офис компании, удалённые офисы и филиалы через совмест-

но используемую инфраструктуру с использованием выделенных линий. В

этом случае пользователи получают все используемые в частной сети полити-

ки, включая обеспечение безопасности, качество обслуживания QoS, управ-

ляемость и надёжность.

VPN экстранет сети. Эти сети соединяют между собой имеющих об-

щие интересы пользователей, партнеров или сообщества в корпоративную

интранет сеть через совместно используемую инфраструктуру с использова-

нием выделенных линий. В этом случае пользователи получают все использу-

142

IP сеть

VPN

Главный офис

Филиал

Домашний офис

Мобильный

пользователь

Рис. 8.3. Логическая топология VPN сети

емые в частной сети политики, включая обеспечение безопасности, качество

обслуживания управляемость и надёжность.

Соглашения об уровне обслуживания SLA представляют собой договор

между провайдером VPN сети и его клиентом; в этом соглашении содержатся

критерии, согласно которым пользователь ожидает предоставления конкрет-

ных служб. Соглашение SLA является единственным имеющим юридическую

силу средством, имеющимся в распоряжении пользователя, которое позволя-

ет ему добиться того, чтобы провайдер VPN сети предоставил ему службы

того уровня и качества, которые определены в соглашении. Однако в этих со-

глашениях имеются некоторые аспекты, представляющие определённые тех-

нические проблемы, как для провайдера, так и для его клиента.

Для клиента определенную проблему составляет выбор и установка тех-

нических средств, позволяющих оценить уровень обслуживания, и, соответ-

ственно, степень соответствия предоставляемых услуг критериям соглашения

SLA. Следует отметить, что в одном соглашении SLA могут содержаться по-

ложения, описывающие совместные контрактные обязательства нескольких

провайдеров, но если VPN сеть пользователя охватывает несколько доменов

различных провайдеров, то в соглашении SLA должен быть оговорён порядок

взаимного соединения провайдеров и характеристики сквозного соединения.

Для провайдера проблемы, связанные с соглашением SLA состоят в

том, что их выполнение может быть связано с использованием услуг несколь-

ких других провайдеров. В случае взаимодействия с Internet-провайдером, в

открытой сети, типичный режим "негарантированной доставки" мало подхо-

дит для выполнения условий соглашения SLA, в силу непредсказуемого ха-

рактера работы механизмов выделения ресурсов. В таких средах либо про-

вайдер должен, либо обеспечить правильно спроектированную сеть (в смысле

нужного соотношения между мощностью доступа пользователя и возможно-

стями внутренней коммута-

ции), либо создать структу-

ры дифференциации служб

для обеспечения того, что-

бы каждому клиенту согла-

шений SLA был предостав-

лен некоторый минималь-

ный уровень выделения ре-

сурсов. Следует отметить,

что первый способ имеет

тенденцию к уменьшению

возможностей агрегирова-

ния потоков данных, что не-

гативно влияет на конечную

стоимость: второй способ оказывает неблагоприятное воздействие на слож-

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

143

ISDN соединение

Рис. 8.4. Виртуальная сеть, состоящая из узлов А

В примере, показанном на рис.8.4, узлы сети A образуют VPN сеть (по-

казанную пунктиром) в магистральной сети провайдера службы, в то время

как сеть B даже не подозревает о её существовании. При этом сети A и B гар-

монично сосуществуют в одной и той же общей магистральной инфраструк-

туре.

Наиболее общим типом частной виртуальной сети является объедине-

ние, географически удалённых друг от друга подсетей, принадлежащих обще-

му административному домену, которые соединены между собой через сов-

местно используемую инфраструктуру, находящуюся вне их административ-

ного контроля (например, через глобальную сеть Internet или магистральную

сеть одного провайдера. Соединения между устройствами такой виртуальной

VPN сети могут оказаться легко уязвимыми, поэтому уровень конфиденци-

альности, обеспечиваемый частной виртуальной сетью, в значительной степе-

ни зависит от технологии, которая использовалась при её создании. Напри-

мер, если данные, передаваемые между всеми подсетями (или всеми узлами

VPN сети) надежно шифруются при прохождении по общей сетевой инфра-

структуре, то обеспечивается относительно высокий уровень безопасности

всей частной виртуальной сети.

Виртуальные частные сети позволяют отделить друг от друга различ-

ные типы потоков данных, с тем, чтобы исследовательские и промышленные

данные не знали о существовании друг друга. Виртуальные частные сети на-

столько независимы, что крупные поломки или неустойчивость в одном сооб-

ществе, абсолютно прозрачны для другого.

Виртуальные частные сети могут охватывать более чем одну сеть с тем,

чтобы её состояние поддерживалось в одним или более провайдером, что

обеспечивает повышенный уровень надёжности, поскольку все провайдеры

явным образом поддерживают распределённую среду.

Реализация частных виртуальных сетей

После того, как принято решение о создании VPN сети, необходимо

принять соответствующие меры для обеспечения адекватной защиты инфра-

структуры; для этого перед началом реализации необходимо провести аудит

безопасности предлагаемых решений, строго определить приложение и цели

его применения.

Аудит безопасности. Аудит безопасности системы проводиться для

того, чтобы после реализации VPN сети уязвимость в брандмауэре, приложе-

нии удалённого доступа или методе аутентификации не стала открытой более

широкой аудитории, чем до реализации этой сети. Эти меры обеспечения без-

опасности заслуживают всестороннего изучения по крайней периметра сети,

который может быть атакован как изнутри сети, так и извне. Такая оценка

144

должна включать в себя аудит всех входных соединений в интранет сеть,

включая серверы удалённого доступа, соединения на базе маршрутизаторов и

соединения с экстранет. В случае экстранет виртуальной частной сети такая

оценка также должна включать анализ периметра сетей организаций-парт-

неров.

Сфера действия сети и требования приложений. После того, как вы-

полнен аудит безопасности, необходимо определить сферу действия вирту-

альной частной сети путём идентификации конечных пользователей (таких

как партнеры, подрядчики и мобильные абоненты), которые бы могли полу-

чать доступ к VPN сети и приложениям.

Этот этап включает в себя оценку приложений, которые будут исполь-

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

искажению, которые они будут передавать. Оценка чувствительности прило-

жений позволит выбрать соответствующие службы безопасности и адекват-

ное шифрование.

Далее необходимо определить и протестировать задержку и потребно-

сти в качестве обслуживания QoS всех приложений, которые будут поддер-

живаться частной виртуальной сетью. Даже приложения, которые можно

рассматривать, как допускающие временное хранение в буфере с последую-

щей отправкой могут оказаться чувствительными к задержке. Эти уровни

чувствительности влияют на то, в какой степени приложение является подхо-

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

ветствующей сети.

Документация. В случае организации экстранет частной виртуальной

сети, администрация предприятия должна зафиксировать правила поведения

пользователей в специальном документе. При использовании удалённого до-

ступа, этот документ должен отражать политику администрации, по отноше-

нию к новой форме доступа пользователей.

Политика безопасности. В случае экстранет сети VPN, работа в вирту-

альной частной сети определяется политикой аутентификации и авторизации.

Авторизация должна основываться на общих принципах, которые опре-

деляются работающими в данной сети предприятиями. Эти общая принципы

должны иметь базовые привилегии – включая доступ к сети и доступ к Web-

серверу – к уровням хранения продуктов поставщиков. Эти принципы долж-

ны быть позднее преобразованы в определённый набор данных и распростра-

нены по VPN сети. Политика удалённого доступа в виртуальной частной сети

не должна радикально отличаться от существующей. Наиболее важным от-

личием от традиционной политики удалённого доступа может быть "допусти-

мое (приемлемое) использование" для доступа в Internet, там, где это необхо-

димо.

Проектирование VPN сетей

145

Использование на всём протяжении маршрута прохождения данных ка-

чественного сетевого оборудования и программного обеспечения, предостав-

ляет возможности обеспечения:

− комплексной безопасности при передаче конфиденциальных данных

по открытой инфраструктуре;

− требуемого качества обслуживания QoS, посредством дифференциа-

ции потоков данных;

− надёжности для критически важных приложений;

− масштабируемость для поддержки большой полосы пропускания для

данных;

− всеобъемлющего управления сетью для полного решения задачи до-

ступа к виртуальной частной сети.

Ключевым компонентом службы виртуального удалённого доступа яв-

ляется туннелирование, которое представляет собой способ поглощения (ин-

капсуляции) пакетов протоколом, который понятен только во входной и вы-

ходной точках данной сети. Эти входная и выходная точки определяются как

туннельные интерфейсы. Туннельный интерфейс аналогичен аппаратному ин-

терфейсу, однако конфигурируется программно.

Используя туннелирование оригинального протокола фирмы Cisco

L2TP, Internet провайдер или другая служба доступа могут создать виртуаль-

ный туннель для связи удалённых узлов пользователя с домашней корпора-

тивной сетью. Концентратор доступа протокола L2TP, расположенный в точ-

ке присутствия провайдера, обменивается сообщениями протокола РРР с

удалёнными пользователями. Посредством запросов и ответов протокола

L2TP концентратор доступа LAC осуществляет связь с сетевым сервером

LNS протокола L2TP для организации туннелей.

Протокол L2TP передаёт пакеты протокольного уровня по виртуально-

му туннелю между конечными точками соединения типа "точка-точка". Паке-

ты от удалённых пользователей принимаются точкой присутствия POP Inter-

146

Корпоративная сеть

Клиент

LNS

Рис. 8.5. Структура туннелирования протокола L2TP

Среда

PSTN

LAC

Среда Internet

Провайдер

= Протокол L2TP

= Протокол PPP

= Протокол IP

net провайдера. преобразовываются в пакеты протокола L2TP и пересылаются

по соответствующему туннелю.

Домашний шлюз пользователя принимает эти пакеты протокола L2TP,

извлекает из него данные и пересылает их на соответствующий интерфейс.

На рис.5 подробно показаны отдельные элементы туннеля протокола L2TP и

процесс подсоединения пользователя к серверу LNS для получения доступа к

требуемой корпоративной Intranet сети.

Как показано на рис.8.5, при туннелировании используются три типа

протоколов:

Протокол пассажира, данные которого преобразуются в пакеты друго-

го протокола, в качестве которого могут выступать протоколы PPP, SLIP и

текстовый диалог.

Протокол преобразования (инкапсуляции) создаёт, поддерживает и

ликвидирует туннель.

Протокол носителя осуществляет передачу по сети данных протокола

преобразования (инкапсуляции). Чаще всего в качестве протокола носителя,

используется протокол IP, поскольку он поддерживается в различных средах

и в глобальной сети Internet. Он обладает высокой надёжностью при маршру-

тизации, и поддерживается практически всеми производителями оборудова-

ния.

Удалённые пользователи (используя протоколы РРР или ISDN) получа-

ют доступ к корпоративной сети LAN таким же образом, как если бы они осу-

ществляли доступ непосредственно к корпоративному шлюзу (несмотря на

то, что физически их соединение удалённого доступа осуществляется через

сервер NAS Internet провайдера). На рис.8.6 показана топологическая картина

того, как были бы реализованы эти соглашения службой виртуального

удалённого доступа.

147

Рис. 8.6. При установке РРР соединения удалённого пользователя с корпоративной

сетью создается полная топология виртуального удалённого доступа

Среда

ISDN

Туннель

Общедоступная

сеть

Сервер LNS

Корпоративная

сеть

Клиент

удалённого

доступа

Концентратор

LAC

Сервер AAAСервер AAA

Для безопасного использования этой службы ни на удалённой конечной

системе, ни на её корпоративных узлах не требуется специального программ-

ного обеспечения.

Аутентификация осуществляется с использованием протокола удалён-

ного доступа РРР. Эта аутентификация может осуществляться пользователем

независимо от Internet провайдера.

Управление адресацией осуществляется так же, как и при использова-

нии выделенных линий, т.е. назначение адреса выполняется компанией поль-

зователя, а не Internet провайдером.

Авторизацией управляют удалённые пользователи компании.

Учёт осуществляется как Internet провайдером (для регистрации расхо-

дов), так и пользователем.

Выполнение этих требований обеспечивается в первую очередь набо-

ром функций, которые предоставляются пользователю с помощью туннеля к

корпоративной сети по протоколу L2TP. В случае использования протокола

РРР, все согласования параметров протокола управления каналом LXP и про-

токола управления сетью NSP, происходят в корпоративной сети пользовате-

ля. Протокол РРР можно использовать для передачи потоков данных от

удалённого пользователя до конечной точки, которой является корпоратив-

ный шлюз.

Виртуальные частные сети VPN позволяют пользователям и мобиль-

ным работникам подсоединяться к корпоративным интранет и экстранет се-

тям. Такие сети позволяют пользователям подсоединяться к Internet локально

и осуществлять передачу данных по туннелю в обратном направлении, для

подсоединения к корпоративным ресурсам. Это не только уменьшает расхо-

ды, связанные с передачей служебной информации, но на также повышает

уровень гибкости и масштабируемости сети.

Традиционные сетевые службы удалённого доступа поддерживают

только зарегистрированные IP адреса, что сужает круг приложений, которые

могут быть реализованы по виртуальным частным сетям VPN. Протокол

L2TP поддерживает несколько протоколов, а также незарегистрированные ис-

правляемые частным образом IP адреса при работе в Internet. Эго позволяет

использовать уже существующую инфраструктуру доступа, такую как Inter-

net, модемы, серверы доступа и терминальные адаптеры. Он также позволяет

промышленным пользователям осуществлять внешнюю поддержку удалённо-

го доступа, тем самым, уменьшая служебную нагрузку, расходы на поддерж-

ку аппаратного обеспечения, а также даёт возможность концентрировать ре-

сурсы корпоративного шлюза. На рис. 8.6 показана структура протокола

L2TP в типичной среде удалённого доступа.

8.5. Процесс виртуального удалённого доступа

148

На рис.8.7 представлено соединение частной виртуальной сети удалён-

ного доступа VPDN с удалённым пользователем, концентратором доступа

LAC в точке присутствия (РОР) Internet провайдера и сервером LNS, в до-

машней локальной сети с использованием туннеля протокола L2TP. Далее

описано поэтапное развитие процесса осуществления виртуального удалённо-

го доступа на всём протяжении маршрута следования данных.

1. Удалённый пользователь инициирует соединение протокола РРР с Internet

провайдером, используя аналоговую телефонную сеть или сеть ISDN.

2. Концентратор доступа LAC Internet провайдера принимает соединение в

точке присутствия РОР и устанавливает канал протокола РРР.

3. После того, как конечный пользователь и сервер LNS согласуют парамет-

ры протокола LCP, концентратор LAC частично аутентифицирует конеч-

ного пользователя с помощью протокола СНАР или РАР. Служба иденти-

фикации имени пользователя, названия домена и набранного номера DNIS

определяет, является ли пользователь клиентом сети VPDN. Если пользо-

ватель не является клиентом сети VPDN, то аутентификация продолжается

и клиент получает доступ к Internet или к другой службе. Если имя пользо-

вателя указывает на то, что он является клиентом сети VPDN, то преоб-

разование определяет конечную точку (сервер LNS).

4. Перед тем, как будет осуществлена попытка создать сеанс связи по тунне-

лю, его конечные точки – концентратор LAC и сервер LNS выполняют вза-

имную идентификацию. Возможен и вариант, когда сервер LNS создает

туннель без (туннельной) аутентификации концентратора LAC.

5. После того, как создан туннель, устанавливается сеанс протокола L2TP

для конечного пользователя.

6. Концентратор LAC посылает согласованные опции протокола LCP и ин-

формацию о частичной аутентификации протокола СНАР или РАР серверу

LNS. Сервер LNS передаёт согласованные опции и информацию об аутен-

тификации непосредственно интерфейсу виртуального доступа. Если скон-

фигурированные опции на виртуальном интерфейсе не совпадают с опция-

ми, согласованными с концентратором LAC, то соединение прерывается и

концентратору LAC посылается сообщение о разъединении. Конечным ре-

зультатом этого является то, что процесс обмена информацией между кли-

ентом удалённого доступа и удалённым сервером LNS выглядит как экс-

клюзивный, как если бы в нём не участвовали промежуточные устройства

(концентратор LAC). На рис.8.7 наглядно показана L2TP последователь-

ность входного вызова с его собственными соответственно более подроб-

ными номерами последовательности, не связанными с номерами предыду-

щего списка.

Особые свойства службы виртуального удалённого доступа

149

Аутентификация и безопасность сети. В традиционном сценарии

удалённого доступа Internet провайдер, использующий сервер NAS вместе с

сервером безопасности, выполняет аутентификацию, запрашивая у пользова-

теля удалённого доступа его имя и пароль. Если удаленный пользователь про-

ходит такую проверку, то начинается этап авторизации.

Для службы виртуального удалённого доступа Internet провайдер вы-

полняет аутентификацию с целью выяснить идентификационные параметры

пользователя и, как следствие этого, желательный для пользователя корпора-

тивный шлюз. На этом этапе соответствие паролей не проверяется. Сразу по-

сле того, как опредёлен корпоративный шлюз, инициируется соединение с ис-

пользованием собранной Internet провайдером информации об аутентифика-

ции. Корпоративный шлюз заканчивает процесс аутентификации, принимая

или отвергая это соединение. Например, в запросе протокола РАР соединение

отвергается, если имя пользователя или его пароль оказываются неправиль-

ными. В случае, когда соединение принято, корпоративный шлюз может вы-

полнить следующую фазу аутентификации на уровне протокола РРР.

Для каждого установленного туннеля протокола L2TP служба безопас-

ности этого протокола генерирует случайным образом уникальный ключ,

предназначенный для защиты. Внутри туннеля L2TP каждый мультиплекси-

рованный сеанс поддерживает номер последовательности для предотвраще-

ния дублирования пакетов. Аппаратное и программное обеспечение фирмы

Cisco предоставляет значительную гибкость, позволяя пользователю осуще-

ствлять сжатие данных на стороне клиента. Кроме того, шифрование в тунне-

ле может осуществляться с использованием протокола IPSec.

Авторизация. При предоставлении традиционной службы удалённого

доступа Internet провайдер поддерживает отдельные профили для каждого

пользователя, которые определяют авторизацию. На основе этого сервер без-

опасности взаимодействовуя с сервером сетевого доступа NAS, предостав-

ляет доступ на основе политик использования и подсоединения пользова-

телей. Характер этих политик может меняться от простых фильтров по источ-

нику/получателю для небольшой группы сайтов до сложных алгоритмов, учи-

тывающих конкретный характер используемых приложений, время дня, в ко-

торое происходит удалённый доступ, а также длинные списки разрешённых

или, наоборот, запрещённых пунктов назначения. Этот процесс может потре-

бовать значительных вычислительных ресурсов от Internet провайдера, осо-

бенно если ему требуется обеспечить доступ удалённых пользователей от

имени компаний, которым требуется постоянно изменять свою политику.

При использовании службы виртуального удалённого доступа вся тя-

жесть подробной авторизации, основанной на политиках, возлагается непо-

средственно на компанию удалённого пользователя. В условиях, когда между

удалёнными пользователями и их корпоративным шлюзом устанавливается

сквозное соединение, все операции по авторизации могут быть выполнены

150

так, как если бы удалённые пользователи осуществляли непосредственный

доступ к своей корпоративной сети. Такой подход освобождает Internet про-

вайдера от необходимости поддержания большой базы данных профилей ин-

дивидуальных пользователей многих компаний. При этом служба виртуаль-

ного удалённого доступа становится более безопасной для компанией. Служ-

ба виртуального удалённого доступа также позволяет компаниям быстро реа-

гировать на изменения состава сообществ своих удалённых пользователей.

Выделение адресов. При использовании традиционной службы удалён-

ного доступа к Internet пользователю IP адрес выделяется динамически из на-

бора доступных адресов провайдера. В этом случае удалённые пользователи

имеют ограниченный доступ к ресурсам своей корпоративной сети, или вооб-

151

Рис. 8.7. Этапы установки соединения между удалённым клиентом VPN

сети и корпоративной локальной сетью

Сеть FSTN

LNS

Сервер

LAC

Концентратор

А А

Сервер LAC Сервер LAC

Установка вызова (1)

Установка PPP LCP (2)

CHAP запрос пользователя (3)

Ответ на CHAP запрос (4)

Информация запроса туннеля (5)

Пользователь = домен

Пароль

Информация о туннеле (6)

Локальное имя (LAC)

Пароль туннеля

Тип туннеля

IP адрес сервера LNS

Установка туннеля (7)

CHAP запрос аутентификации (8)

CHAP ответ сервера LNS (9)

Передача (10)

CHAP запрос (11)

CHAP запрос концентратора LAC (12)

Передача (13)

Сеть

CHAP ответ пользователя=идернификатор+параметры протокола PPP (14)

Передача (17)

Необязательный второй CHAP запрос (18)

CHAP ответ на запрос (19)

Передача (20)

(15)

(20)

(16)

(21)

Запрос доступа

(15) (20)

Ответ на запрос

доступа

(16) (21)