Виртуальные частные сети – обзор технологий

Тема виртуальных частных сетей (Virtual Private Network, VPN),  получает признание в корпоративной среде. Таким образом, создалась некая «критическая масса», позволяющая сделать обзор и сравнение методов построения VPN. Хотя он, безусловно, является весьма конспективным, но все же позволит сформулировать основные принципы, на которых базируются VPN-технологии, и провести некоторые оценки.

Леонид Бараш, КОМПЬЮТЕРНОЕ ОБОЗРЕНИЕ 

Сегодня о виртуализации ресурсов не говорит разве что только ленивый, однако в тяжелые времена эта тема становится особенно актуальной. Действительно, даже если и весьма скептически относиться к обещаниям золотых гор, которые раздают поставщики виртуальных решений, при умелом их использовании можно добиться существенного снижения затрат на ИТ. Это подтверждается и результатами последнего отчета компании Gartner по исследованию тенденций рынка в 2009 г. Опрос более 200 CIO показал, что они ожидают увеличения инвестиций в трех областях: виртуализации, беспроводных LAN/WAN и оптимизации WAN. Как видим, виртуализация занимает первую строчку.

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

Таким образом, актуальность этой темы не поддается сомнению. Мы попытались осветить ее с разных сторон. Читатель найдет в основной рубрике нашего еженедельника краткий обзор и сравнение технологий построения VPN, примеры реализованных в Украине проектов и статью по безопасности VPN, написанную специалистом в этой области – сотрудником Cisco Systems Владимиром Илибманом.

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

Туннели и туннельные протоколы

Напомним, что сущность виртуальных частных сетей заключается в использовании публичной телекоммуникационной и/или сетевой инфраструктуры (например, Интернет) для обеспечения безопасного доступа удаленных филиалов и сотрудников к основной сети организации (Remote Access VPN) или для объединения географически удаленных локальных сетей (LAN-to-LAN VPN). Такие сети в данном контексте мы будем для удобства называть сайтами (от site – местоположение).

Наиболее универсальным способом построения VPN является использование технологии инкапсуляции, или туннелирования. В общем случае туннелирование применяется для того, чтобы передавать пакеты одной сети (первичной) по каналам связи другой (вторичной), протоколы которых не совместимы. Для этого пакет первичной сети (данные и протоколы) инкапсулируется в пакет вторичной сети и становится виден как данные. Таким образом, пакет продвигается маршрутизаторами ядра сети только на основании внешнего заголовка, без инспекции содержимого оригинального пакета. Это иллюстрирует рис. 1, на котором показана передача данных от А к В по туннелю между Х и Z. Промежуточный узел Y не знает адреса получателя В, а передает данные по туннелю только узлу Z. В этом сценарии узел Х называется входом в туннель, а узел Z – выходом.

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

 

Рис. 1. Передача данных сквозь туннель

Функционально туннель можно представить как сквозной виртуальный канал, имеющий начальную точку (вход, инициатор туннеля) и одну или более конечных (выходов, терминаторов туннелей). Этими точками могут быть компьютер удаленного пользователя, работающий как VPN-клиент, маршрутизатор, шлюз или сервер доступа к сети (Network Access Server – NAS). На обоих концах необходимо установить аппаратное и программное обеспечение (включая шифрование/дешифрование, если оно присутствует), работающее в соответствии с теми протоколами, посредством которых был образован туннель. Хотя термин «туннель» ассоциируется с фиксированным путем, на самом деле для сетей с коммутацией пакетов (Интернет, в частности) это не так. Зашифрованные и инкапсулированные пакеты могут использовать различные маршруты между конечными точками. Основное назначение туннеля – обеспечить конфиденциальность сессии. Это значит, что никто, кроме получателя, не расшифрует (в идеале) пакет, и чужие пакеты не могут попасть в туннель, поскольку маршрутная информация для VPN хранится отдельно от общей.

Традиционно VPN (туннелирование и/или шифрование) организуют на нижних уровнях коммуникационного стека протоколов – канальном (Layer 2) и сетевом (Layer 3). В соответствии с этим различают виртуальные частные сети на уровне 2 (L2VPN) и на уровне 3 (L3VPN). Одно из основных отличий между этими типами VPN заключается в сервисах, которые они предлагают пользователям. Например, L2VPN предоставляют заказчикам сервисы, подобные Ethernet, ATM Virtual Circuits (VC), или арендованные каналы, а L3VPN обеспечивают связь между сайтами на базе протоколов IPv4 или IPv6.

И те и другие VPN имеют свои достоинства и недостатки. Так, решения на базе L2VPN гибче в смысле прозрачности для протоколов более высоких уровней. К примеру, они могут передавать оригинальные пакеты IPv4 и IPv6 безотносительно к протоколу уровня 3 IP-сети оператора. Это также значит, что некоторые из данных L2VPN-решений могут передавать и унаследованный трафик SNA, NetBIOS и SPX/IPX. В числе недостатков данного типа VPN то, что соединяемые сайты (или хосты) должны работать с одним и тем же протоколом канального уровня, что не всегда возможно. L3VPN имеют ряд преимуществ с точки зрения управления. Например, в управляемых L2VPN заказчик остается ответственным за всю IP-маршрутизацию между своими сайтами, тогда как в L3VPN эту заботу может взять на себя оператор.

Основными туннельными протоколами для построения VPN являются MPLS (Multi-Protocol Label Switching), IPSec, L2TP (Layer 2 Tunneling Protocol) IP-in-IP и GRE (Generic Routing Encapsulation). Остановимся вкратце на некоторых их особенностях.

MPLS. Технология MPLS позволяет пересылать данные с помощью меток, прикрепляемых к каждому пакету. Внутренние узлы ядра сети, поддерживающие MPLS, не нуждаются в анализе содержимого каждого пакета. Так, не рассматривается IP-адрес получателя, что дает возможность MPLS предоставить эффективный механизм инкапсуляции для частного трафика, передаваемого по магистрали оператора. Имея это в виду, сформированные протоколом распределения меток (Label Distribution Protocol, LDP) маршруты продвижения пакетов от отправителей к получателям (Label Switched Path, LSP) нередко рассматривают как туннели через всю сеть MPLS или через ее магистральную часть.

Одна из особенностей MPLS в том, что можно устанавливать LSP внутри LSP внутри LSP и т. д., что весьма удобно для мультиплексирования. Туннелирование одного LSP внутри другого заключается в простом добавлении еще одной метки к имеющемуся стеку. Продвижение пакетов осуществляется на основе внешней метки, которая удаляется по достижении конца, соответствующего LSP, и т. д. Другим преимуществом MPLS в качестве туннельной технологии является возможность конструирования трафика (traffic engineering) для LSP, что позволяет зарезервировать для заказчика необходимые сетевые ресурсы. Единственное, о чем должен побеспокоиться последний, так это о безопасности. Правда, анализ безопасности VPN на базе MPLS показал, что она обеспечивается в той же мере, как и виртуальными каналами в сетях ATM/Frame Relay. В частности, конфиденциальность данных не нарушается, но проблемы в сети могут приводить к потере пакетов. В то же время маловероятно, что пакет будет доставлен по другому адресу.

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

Поскольку основная цель протокола заключается в обеспечении безопасности, то в нем реализован полный набор соответствующих требований: аутентификация источника данных, защита от повторной передачи перехваченных пакетов (anti-replay) и шифрование. Еще одним преимуществом IPSec является режим обмена данными без предварительного соединения – это экономит ресурсы транзитных маршрутизаторов.

Один из его недостатков – отсутствие механизма естественного демультиплексирования для IPSec-туннелей, однако этого можно достичь «обходным» путем, например запустив MPLS поверх туннеля IPSec.

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

L2TP. Этот протокол разработан для туннелирования данных канального уровня (уровня 2 эталонной модели OSI) с помощью сетевого (уровня 3). Фактически в пакете он располагается на пятом, сессионном, уровне и использует зарегистрированный UDP-порт 1701 – полный L2TP-пакет, включая полезные данные и L2TP-заголовок, посылается внутри UDP-дейтаграммы.

Конечными точками L2TP-туннеля служат два устройства: концентратор доступа L2TP (L2TP Access Concentrator – LAC) и сетевой сервер L2TP (L2TP Network Server – LNS). LAC является инициатором туннеля, тогда как LNS – сервером, который ждет запросов на установку. Если туннель установлен, то сетевой трафик может передаваться в обоих направлениях.

LAC располагается между удаленной системой (пользователем или филиалом) и LNS. Он принимает вызовы от удаленных систем и инкапсулирует (обычно) PPP-фреймы в пакеты L2TP. Затем он направляет их по L2TP-туннелю на один или несколько LNS по сети с коммутацией пакетов (Internet, Frame Relay, ATM). LNS – вторая конечная точка туннеля, на этот раз со стороны корпоративной сети. Он является логической конечной точкой PPP-сессии. LNS деинкапсулирует L2TP-пакеты, обрабатывает PPP-фреймы и направляет их в корпоративную сеть.

Именно L2TP наиболее часто используется при построении L2VPN. Поскольку для создания туннелей требуются только ресурсы на их конечных точках, они хорошо мультиплексируются. Протокол не имеет встроенных средств безопасности, но его можно запустить поверх IPsec в транспортном режиме.

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

GRE. Если говорить в самых общих чертах, то GRE позволяет туннелировать любой протокол внутри любого протокола. В контексте VPN основное использование GRE заключается в переносе первичного IP-пакета во вторичный IP-пакет. Преимущества те же, что и предыдущего протокола: не требуется сигнализации для установления соединения и дополнительных ресурсов для формирования туннеля. До сих пор это очень похоже на IP-in-IP. Однако имеется ключевое отличие – расширение, описанное в RFC2890, допускает мультиплексирование GRE-туннелей.

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

 

Рис. 2. Роль устройств РЕ, Р и СЕ в VPN

Для того чтобы получить доступ к IP-магистрали, необходимо иметь, по крайней мере, одно устройство (такое как коммутатор или маршрутизатор) на границе сайта (сети) каждого заказчика, подсоединенное к сети оператора. Его называют Customer Edge (CE). Хотя логически эти устройства являются частью сети заказчика, они, тем не менее, в ряде случаев управляются, а иногда и принадлежат оператору. Подобно этому устройство в сети оператора (в типичном случае IP-маршрутизатор), к которому подсоединяется СЕ, называется Provider Edge (PE). Транзитные маршрутизаторы в ядре сети оператора, пересылающие данные (включая VPN-пакеты), но никак не связанные с организацией VPN функционально, именуются просто Provider (P). Роль этих устройств в VPN иллюстрируется на рис. 2. После знакомства с технологиями, образующими фундамент VPN, рассмотрение их типов должно пойти без проблем.

VPN, базированные на СЕ

Рассмотрим вначале решения, в которых вся специфическая для VPN обработка выполняется в устройствах СЕ, – обычно их называют СЕ-базированными. В определенном смысле это простейший тип VPN, поскольку сеть оператора не принимает участия в маршрутизации VPN-трафика ни на втором, ни на третьем уровне сетевого протокола, и устройства PE могут быть стандартными IP-маршрутизаторами. Это является одним из основных преимуществ для оператора. В отличие от PE-базированных VPN, описанных ниже, РЕ-устройства в этом типе виртуальных частных сетей не должны хранить ни МАС-адресов, ни IP-адресов внутренних по отношению к VPN и не участвуют во внутренней маршрутизации VPN. Это значит, что такие решения хорошо масштабируются в сети оператора.

СЕ-базированные VPN являются превалирующим типом традиционных VPN, основанных на арендованных линиях в сетях Frame Relay и ATM. VPN образуются посредством соединений «точка-точка» между сайтами с помощью арендованных линий. Аналогично можно создать IP VPN, установив IP-туннель между СЕ-устройствами.

Свойства VPN, созданных таким способом (в частности, QoS, тип передаваемого трафика и безопасность), наследуются от типа используемой туннельной технологии. Например, IPSec-туннели обеспечивают безопасность туннелируемого IP-трафика для уров- ня 3, тогда как L2TP предоставляют средства для транспорта трафика уровня 2 для L2VPN.

 

Рис. 3. Схема СЕ-базированного решения

Одной из проблем в случае СЕ-базированных VPN является необходимость приложения существенных усилий для управления и конфигурации СЕ-устройств. Конфигурация значительно усложняется при увеличении количества сайтов. Вдобавок пользователи таких сетей могут нуждаться в приобретении нового оборудования для формирования туннелей и/или маршрутизации для поддержки VPN. Один из способов снизить сложность управления – передать эти функции (и, возможно, даже поставку СЕ-устройств) оператору. Однако при включении в СЕ-базированные VPN большого количества сайтов управление полносвязной сетью туннелей становится сложным и для оператора. Решение данной проблемы дается предварительной версией стандарта draft-lee-ppvpn-ce-auto-config, который обеспечивает средства для автоматической конфигурации СЕ-устройств в этом типе VPN (рис. 3).

VPN, базированные на РЕ

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

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

Нам придется ввести еще одну концепцию, которая относится к РЕ-базированным VPN, – это обособленные (отдельные) таблицы продвижения пакетов (forwarding tables). Она иллюстрируется на рис. 4, где показаны несколько СЕ и РЕ, принадлежащих двум разным VPN, а также отдельные туннели через сеть оператора для каждой из них.

Во всех РЕ-базированных решениях для VPN уровня 3 необходимо, чтобы каждое РЕ-устройство маршрутизировало IP-пакеты, приходящие от сайтов, которые принадлежат группе заказчиков, являющихся членами нескольких VPN. В типичном случае РЕ должно направлять пакеты от одного сайта к другому или от одного СЕ к удаленному РЕ, а оно, в свою очередь, будет направлять их другому СЕ в той же VPN. Например, РЕ 1 на рис. 4 получает пакеты от VPN 2 сайта 1, предназначенного для VPN 2 сайта 2, и направляет его через туннель к РЕ 2.

Эти операции усложняются тем, что VPN являются частными сетями и могут иметь одинаковые или перекрывающиеся адресные пространства. К примеру, вполне вероятно, что у хоста в VPN 1 сайта 7 тот же IP-адрес, что и у хоста в VPN 2 сайта 1. Тот же самый адрес может быть использован и в Интернете или в операторской сети. Отсюда следует, что каждый РЕ-маршрутизатор требует несколько изолированных таблиц продвижения пакетов, в частности, для каждой VPN нужно иметь так называемую виртуальную таблицу маршрутизации и продвижения (Virtual Routing and Forwarding table (VRF).

Похожая проблема существует и для РЕ-базированных VPN уровня 2. Хотя в них РЕ продвигают пакеты на основе данных второго уровня протокола, а не на IP-адреса получателя, таблицы продвижения уровня 2 для разных VPN в типичном случае все равно хранятся раздельно.

РЕ-базированные VPN уровня 2

Имеются три основных типа L2VPN. Каждый из них предоставляет разные сервисы заказчикам.

Virtual Private Wire Services (VPWS). Этот тип L2VPN обеспечивает соединение типа «точка-точка» между сайтами заказчиков. Ее можно представить как эмуляцию сетью оператора набора проводов, которые проложены между сайтами.

 

Рис. 4. РЕ-базированные VPN

VPWS может быть полезна, когда заказчик использует между сайтами каналы на базе ATM или Frame Relay, поскольку в этом случае для связи между заказчиком и оператором могут быть задействованы существующие соединения. Заказчик может сохранить обмен данными с провайдером на уровне 2, однако взамен нативных пакетов, передаваемых по сетям ATM или Frame Relay, трафик будет инкапсулироваться и маршрутизироваться по IP-сети оператора, в которой эмулируются соединения уровня 2 (рис. 5).

Рассмотрим далее три примера VPWS-решений. Любое из них выглядит для заказчика как традиционные VPN на уровне 2, соединяющие его сайты с помощью арендованных линий ATM или Frame Relay. В каждом случае это выполняется посредством эмуляции набора соединений типа «точка-точка» между СЕ-маршрутизаторами. Основные различия между решениями заключаются в объеме настроек, требуемых оператором, и типах туннелей, «прокладываемых» через операторские сети.

 

Рис. 5. Соединения «точка-точка» между сайтами заказчика с эмуляцией соединений уровня 2 в сети оператора

VPLS, базированные на MPLS. Один из простейших способов создания VPWS – использование виртуальных каналов (Virtual Circuit, VC) ATM или Frame Relay между РЕ и СЕ и подсоединение каждого из них к отдельным MPLS-каналам сети оператора (рис. 6), которые, напомним, называются Label Switched Path (LSP).

Это относительно прямолинейный подход, и если заказчику понадобится QoS, то может быть использовано конструирование трафика. Однако такое решение недостаточно хорошо масштабируется в сети оператора. Во-первых, каждый LSP через сеть оператора требует индивидуальной конфигурации и последующего подсоединения к определенному VC на каждом конце, и, во-вторых, может возникнуть необходимость установки большого количества LSP в сети оператора, на что будут израсходованы значительные ресурсы его маршрутизаторов.

PWE3 VPWS. Улучшением предыдущего подхода является расширение PWE3 к MPLS, которое стандартизируется в IETF рабочей группой PWE3. Эти расширения повышают масштабируемость посредством использования фиксированного числа LSP между РЕ-устройствами сети оператора.

Для этого посредством LSP строится полносвязная сеть между всеми РЕ, и на ее базе между каждой парой РЕ эмулируется соединение на уровне 2 типа «точка-точка», известное также как псевдопровод или туннель Мартини, по имени автора предварительного стандарта инкапсуляции Люка Мартини (Luca Martini). Каждый такой псевдопровод использует ресурсы только РЕ-устройств, что выгодно отличает этот метод от предыдущего, где в создании туннелей участвовали также и промежуточные маршрутизаторы.

Инкапсуляция, требуемая для продвижения данных по этим псевдопроводам, определяется для нескольких протоколов уровня 2, включая ATM, Frame Relay и Ethernet.

Kompella L2VPN. Эти сети носят имя Кирити Компеллы (Kireeti Kompella), автора предварительного стандарта, известного как draft kompella. В нем описан механизм создания VPWS с использованием Boarder Gateway Protocol (BGP) в качестве протокола автообнаружения и сигнализации.

 

Рис. 6. Простейшая схема построения MPLS-базированной VPWS

Первый шаг при установлении VPWS, базированного на draft kompella, заключается в том, чтобы распределить идентификаторы для каждого устройства CE. Эти идентификаторы должны быть уникальны внутри VPWS. Следующим шагом является установление соединений (обычно ATM или Frame Relay VC) между устройствами СЕ и РЕ. В каждом СЕ создается отдельный VC с каждым удаленным СЕ, с которым необходимо установить связь. Эти VC в типичном случае выбираются так, чтобы нашелся простой алгоритм отображения идентификатора удаленного СЕ на идентификатор используемого VC. Параллельно этому оператор должен установить туннели между РЕ-маршрутизаторами. Какой при этом применять туннельный протокол, не слишком важно, хотя MPLS был бы идеальным выбором, поскольку метки можно использовать для идентификации VC. Полносвязность не требуется, таким образом, нужны только туннели между теми РЕ, которые соединенны с СЕ, обменивающимися данными.

Теперь РЕ, получающее данные от другого РЕ, должно быть способно определить, по какому VC передать их соответствующему СЕ. Чтобы сделать это, РЕ-маршрутизатор распределяет блок MPLS-меток каждому СЕ – блок содержит по одной метке для каждого VC, который соединяет маршрутизаторы РЕ и СЕ. Если мы примем, что метка Lxy обозначает привязку VCy к СЕx, то пример на рис. 7 показывает, что РЕ 1 распределяет метки L12 и L13 устройству СЕ 1. Таким образом, данные с меткой L12, полученные от другого РЕ-маршрутизатора, будут посланы по каналу VC 2, а с меткой L13 – по VC 3.

После того как РЕ-маршрутизатор распределил свой набор меток, он должен сказать другим РЕ, что включился в VPWS и какие метки использовать при пересылке данных от подсоединенных к ним СЕ. Это выполняется с помощью Multi-Protocol BGP, который распространяет блок меток вместе с идентификатором VPWS.

 

Рис. 7. Распределение меток и установка виртуальных каналов (VC) в Kompella L2VPN

На рис. 7 пунктирная линия показывает, что СЕ 2 передает данные СЕ 1. Чтобы сделать это, СЕ 2 посылает данные по VC 1, который ассоциирован с СЕ 1. РЕ 2 знает, что данные, полученные по VC 1, должны быть туннелированы РЕ 1 с меткой L12. Когда РЕ 1 получает данные с меткой L12, то последняя удаляется и данные направляются по VC 2 к СЕ 1.

Одна из важных особенностей этого решения заключается в том, что конфигурация и управление в сети оператора выполняются проще, чем для арендованных линий, подходов на базе MPLS или туннелей Мартини. Вдобавок этот тип VPWS является более гибким по сравнению с арендованными линиями. В последнем случае обмен данными между заказчиком и оператором должен основываться на одинаковом протоколе уровня 2. Решения же на базе Kompella L2VPN позволяют зачастую использовать различные протоколы уровня 2 на разных сайтах заказчика, если данные передаются между ними как IP-трафик.

Virtual Private LAN Service (VPLS). Об этой технологии мы уже писали в нашем еженедельнике (ko-online.com.ua/37687), поэтому здесь представим лишь концепцию в общих чертах.

В этом типе VPN локальная сеть Ethernet на каждом сайте заказчика расширяется вплоть до границы сети оператора, которая в данном случае эмулирует функции коммутатора Ethernet или моста, объединяющего все ЛВС заказчика в один мостовой домен.

Одно из основных различий между VPWS и VPLS заключается в том, что VPWS обеспечивает только сервис типа «точка-точка», тогда как VPLS – соединения «точка-многоточка». Это также значит, что требования, предъявляемые к СЕ-устройствам, совершенно различны. В VPWS коммутация на уровне 2 должна выполняться СЕ, которым необходимо выбрать, какой виртуальный провод использовать, чтобы передать данные другому сайту заказчика. В VPLS же они просто направляют весь трафик, адресованный другим сайтам, РЕ-маршрутизатору.

IP-only LAN-like Service (IPLS). Во многих сетях для обмена данными между сайтами достаточно только IP-трафика, и СЕ-устройством служит IP-маршрутизатор, а не коммутатор второго уровня. В таком случае возможно использовать третий тип L2VPN – IPLS. В этом типе VPN присутствует только IP-трафик, так что IPLS легко спутать с L3VPN. Однако поскольку пакеты продвигаются на основе информации, находящейся в заголовке второго уровня, IPLS попадает в категорию L2VPN.

Механизм, используемый для установки IPLS, следующий.

На первом шаге РЕ изучают локально подсоединенные СЕ. Это делается автоматически с помощью отслеживания (snooping) фреймов IP и ARP, что позволяет определить как МАС-адрес, так и IP-адрес СЕ. Устройства РЕ могут также автоматически изучать другие РЕ в той же IPLS – это может выполняться методом автообнаружения, обеспечиваемого протоколом BGP.

Для каждого локально подключенного СЕ-устройства РЕ устанавливает новый псевдопровод Мартини к каждому удаленному РЕ, включенному в сеть IPLS. Когда по какому-нибудь псевдопроводу поступают данные, РЕ может направить их прямо соответствующему СЕ без просмотра адресной части пакета. Когда же по псевдопроводу к РЕ поступает сигнальная информация, то в нее включаются МАС- и IP-адрес СЕ, которые сохраняются на удаленном РЕ. Это позволяет каждому РЕ строить таблицу всех IP- и МАС-адресов СЕ-устройств, входящих в IPLS. Данная таблица используется для образования прокси-ARP, а он, в свою очередь, дает возможность СЕ изучать МАС-адреса удаленных СЕ.

Когда IPLS установлена, IP-пакеты маршрутизируются от одного сайта к другому следующим образом:

  • источник данных инкапсулирует IP-пакет в МАС-фрейм и направляет его к локальному СЕ;
  • СЕ извлекает из фрейма IP-пакет и выполняет маршрутизацию в соответствии с IP-адресом следующего транзитного маршрутизатора;
  • IP-адрес следующего транзитного маршрутизатора разрешается до МАС-адреса удаленного СЕ (с помощью функции прокси- ARP, предоставляемой РЕ);
  • затем СЕ вновь инкапсулирует IP-пакет в МАС-фрейм с адресом удаленного СЕ в качестве получателя и направляет фрейм РЕ;
  • РЕ использует МАС-адрес получателя (который является адресом удаленного СЕ), чтобы найти нужный псевдопровод Мартини, и посылает фрейм;
  • получающее РЕ знает, по какому псевдопроводу пришел фрейм, и таким образом знает, какому СЕ его направить;
  • СЕ получает МАС-фрейм, извлекает из него IP-пакет и передает его в оригинальном виде.

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

 

Рис. 8. Установка РЕ-устройством псевдопроводов в IPLS

На рис. 8 схематически показана установка РЕ-устройством псевдопроводов в IPLS (рассматривается только РЕ 1). Для каждого удаленного РЕ имеются один псевдопровод для получения данных от всех локальных СЕ, а также отдельные псевдопровода для передачи многоадресного трафика, поступающего от локальных СЕ.

Вопреки (а может быть, благодаря) ряду ограничений IPLS по сравнению с VPLS (основное из них – поддержка только IP-трафика) это решение имеет многочисленные преимущества, в частности более легкую конфигурацию и лучшую масштабируемость. Первое обязано способности РЕ автоматически определять подключенные устройства СЕ и РЕ. А второе свойство вытекает из меньшего числа МАС-адресов, которые необходимо хранить. На практике это значит, что количество сайтов в IPLS VPN может исчисляться сотнями, тогда как в VPLS VPN – десятками.

Nemiroff: все дело в безопасности


Юрий Бабак, руководитель проектов «ПроНЕТ»

В ходе эксплуатации разрозненных систем связи территориально распределенных подразделений у холдинга Nemiroff возникла проблема с управлением корпоративной сетью. «ПроНЕТ» ставилась задача построения единой системы, контролируемой и управляемой централизованно и способной делегировать некоторые полномочия в подразделения. Также необходимо было обеспечить безопасность данных, передаваемых между подразделениями и головным предприятием.

Был разработан проект решения поставленных задач с применением продуктов компании Check Point. На сегодня все удаленные подразделения и конечные пользователи работают с головным офисом через туннели, построенные на основе протоколов IPSec и SSL (если сотруднику необходимо получить доступ к ресурсам с устройства, на котором нет возможности установить клиентское ПО).

Весь трафик инспектируется, выполняются корреляции событий и генерация отчетов. Новые филиалы сравнительно легко добавляются в сеть (технология One Click VPN), также без больших затрат может быть проведено реконфигурирование существующих подключений. Было реализовано резервирование каналов связи. Таким образом, благодаря унификации систем управления при использовании продуктов Check Point удалось снизить затраты на администрирование и обеспечение безопасности ИТ-инфраструктуры Nemiroff, что позволило сократить время реакции на возникающие угрозы и повысить отказоустойчивость основных бизнес-процессов холдинга.В планах у заказчика – более тесно интегрировать сетевую инфраструктуру с системой корреляции и отчетности Check Point Eventia Suite.

РЕ-базированные VPN уровня 3

 

Рис. 9. VPN с использованием BGP

Группа, занимающаяся созданием L3VPN, добилась несколько больших успехов, чем разработчики L2VPN. Поэтому соответствующие протоколы более стабильны, а следовательно, оператору услуг легче приобрести оборудование, поддерживающее L3VPN, и вероятность совместимости маршрутизаторов от разных производителей выше.

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

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

VPN BGP/MPLS. Это решение считается самым важным. В настоящее время оно является наиболее используемым операторами услуг, которые предоставляют VPN.

Базовая версия передает трафик IPv4 VPN через сеть оператора с помощью MPLS-туннелей.

С тех пор как у операторов услуг BGP стал общепринятым в качестве протокола маршрутизации в магистральных сетях, то логически распределять маршруты нужно от присоединенных VPN-сайтов. Маршруты от каждого VPN-сайта или конфигурируются в РЕ-устройствах, или рассылаются ими посредством протоколов маршрутизации, таких как BGP или OSPF. РЕ передают маршруты к удаленным РЕ, используя BGP, а последние распространяют их присоединенным СЕ-устройствам той же VPN. Затем РЕ устанавливают полносвязные туннели между всеми устройствами, подсоединенными к той же VPN или к другим VPN, к которым нужно передавать трафик.

Виртуальные маршрутизаторы. Другим решением L3VPN является архитектура на базе виртуальных маршрутизаторов (Virtual Router, VR). Идея заключается в том, что РЕ-маршрутизатор работает как несколько логических VR, и каждому соответствует своя VPN-таблица продвижения пакетов. Как и обычный маршрутизатор, каждый VR содержит один или более экземпляров маршрутных протоколов, связанных таблицей продвижения пакетов. Для того чтобы связать VR в одном РЕ-устройстве с другим VR той же VPN в другом РЕ, необходимо установить туннель через сеть оператора. Затем VR могут обмениваться маршрутной информацией, используя любой стандартный протокол маршрутизации.

Здесь есть некоторое тонкое отличие от предыдущего решения. Наиболее эффективным в обоих случаях является соответствие каждому VR собственной таблицы маршрутизации и продвижения пакетов VRF к СЕ-устройству и от него. При применении BGP используется единственный экземпляр протокола для распространения маршрутов от всех VRF через сеть оператора (рис. 9). В случае же VR маршруты распространяются в операторской сети по множеству туннелей с помощью отдельных экземпляров маршрутных протоколов для каждой VRF (рис. 10).

 

Рис. 10. Использование множественных туннелей в VR-базированных VPN

Если сравнивать эти два решения, то нужно отметить следующее. По популярности у операторов услуг и производителей оборудования решение на базе VR далеко отстает от VPN BGP. Основная причина кроется в возможностях управления и масштабирования. В последнем случае (BGP) нужна единая полносвязная сеть туннелей между РЕ-маршрутизаторами. При VR-архитектуре необходимо управлять отдельными перекрывающимися туннелями для каждой VPN, и хотя эти туннели могут быть установлены с помощью автоконфигурации (предварительная версия стандарта), масштабируемость все еще вызывает беспокойство. К тому же требуются некоторые усилия и по конфигурации отдельных экземпляров маршрутных протоколов.

Основное же преимущество VR-архитектуры заключается в том, что VPN-маршруты хранятся совершенно отдельно от маршрутной информации операторской сети. Хотя при BGP-подходе маршруты хранятся в отдельных таблицах продвижения пакетов, они все еще передаются между РЕ-маршрутизаторами посредством того же экземпляра маршрутного протокола, который используется и для обмена интернет-маршрутами. Это значит, что любая проблема в сессии, вызванная VPN-маршрутами, потенциально может воздействовать на интернет-соединения.

На этом, собственно говоря, мы закончим довольно объемное как для формата нашего издания, но весьма поверхностное с точки зрения глубины рассмотрение функционирования различных VPN-технологий и их сравнение по ряду критериев.

С мыслью о конфиденциальности


Андрей Хабаров, начальник управления ИТ «Укринбанка»

Проект в «Укринбанке», выполняемый «Ланит – lv», начался еще весной 2005 г. Клиент столкнулся с проблемой объединения своих территориально разрозненных подразделений в единую защищенную корпоративную сеть. Среди задач, которые необходимо было решить, – обеспечение безопасного доступа из региональных подразделений к корпоративной информации в центральном узле, а также управление отделениями банка из головного офиса.

В проекте использовалось оборудование Juniper Networks. VPN-туннели строились на базе стандарта IPSec. Было подключено 30 филиальных узлов и 50 отделений. Сейчас все подразделения банка используют корпоративные данные и контролируются с помощью системы управления из центра. Решение обеспечило полноценный доступ всех банковских рабочих мест к информационным ресурсам, таким как централизованная карточная система, система финансового мониторинга, информационно-аналитическая система и пр., а также позволило внедрить принципиально новые средства финансового контроля и управления рисками. Кроме того, ощутимо увеличилась скорость обработки оперативных сведений. На основе построенной сети банк активно разрабатывает и внедряет новые бизнес-приложения.

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


Вадим Запарованый, ведущий специалист департамента сетей и телекоммуникаций «Инком»

«Инком» начал сотрудничать с «Эрсте Банком» в 2006 г., когда тот был еще независимым украинским АКБ «Престиж», ориентированным сугубо на частных клиентов. В прошлом году компания вошла в состав австрийской Erste Bank Group, сменив название и превратившись в универсальный банк. Учитывая принятые в группе требования, возникла необходимость в стандартизации услуг и получении возможностей их дальнейшего расширения. Для этого нужно было в первую очередь добиться эффективной работы ИТ-инфраструктуры за счет построения мультисервисной защищенной сети.

Реализация проекта осуществлялась в три этапа. На первом была построена защищенная корпоративная сеть передачи данных (решение базировалось на построении VPN-туннелей с применением стандарта IPSec) центрального офиса, а также сетевая инфраструктура 25 филиалов банка, которая позволила обеспечить бесперебойную работу специализированных приложений и системы связи. Второй этап заключался в подключении более ста отделений к сервисам локальной и глобальной сети в Киеве. Третий состоял в обеспечении безопасного обмена данными по MPLS-каналам с главным офисом Erste Bank Group (Вена), а также развертывании резервного ЦОД, гарантирующего отказоустойчивость решения в целом.

В проекте использовалось оборудование компании Cisco. В его рамках сеть из трехуровневой (центральный офис – отделения – филиалы) трансформировалась в двухуровневую (центральный офис – отделения), поскольку первый подход перестал удовлетворять потребности банка со множеством филиалов. После того как на центральные маршрутизаторы начало приходить в несколько раз больше каналов, чем было до этого, их конфигурация существенно расширились. Это сказалось как на их производительности, так и на сложности работы администратора. Поэтому было принято решение о переходе с технологии постоянных туннелей на DMVPN (Dynamic Multipoint Virtual Private Network – это способ создания виртуальных, связанных между собой IPSec-туннелей; при добавлении новых ветвей конфигурация на концентраторе не требуется). В данный момент этой задачей и занимается проектная команда.

 

SocButtons v1.5

Добавить комментарий

Обращайтесь к посетителям сайта так, как вы хотите чтобы они обращались к вам

Защитный код
Обновить

Допрос

Сколько вы готовы платить за качественный интернет для личного пользования 100 Мбит/c на загрузку и отдачу?

Вы здесь: Главная Пресса Виртуальные частные сети – обзор технологий