Виртуальные частные сети на базе MPLS

Технологии виртуальных частных сетей (Virtual Private Networks -- VPN) постоянно совершенствуются, становятся надежнее и безопаснее, привлекая все большее внимание корпораций. Использование же для создания VPN мультипротокольной коммутации на базе меток (Multi-Protocol Label Switching -- MPLS) -- стандартизованной технологии, обеспечивающей ориентированную на соединение коммутацию, базированную на IP и присвоении меток пакетам данных, лишь укрепит их положение в корпоративном секторе.

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

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

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

Несмотря на то что тема MPLS неоднократно освещалась на страницах нашего еженедельника (к примеру, "Компьютерное Обозрение", # 27, 2004), мы для полноты изложения напомним особенности этой технологии.

MPLS: базовые понятия

Специалисты полагают, что MPLS в недалекой перспективе станет основной магистральной технологией, в том числе и в конвергентных сетях. Важно понимать, что она не заменит маршрутизацию на базе IP, а будет работать в одной связке как с существующими, так и с будущими технологиями маршрутизации. MPLS улучшает службы, которые могут предоставляться IP-сетями, обеспечивая конструирование трафика (Traffic Engi-nee-ring -- TE), VPN и QoS.

Введем теперь два необходимых для дальнейшего изложения определения. Пусть имеется ядро сети, поддерживающее MPLS. Тогда граничные маршрутизаторы (на входе и выходе из ядра) называются Label Edge Router (LER), а транзитные -- Label Switched Router (LSR).

Для продвижения данных по сети MPLS использует технику, известную как коммутация меток (рис. 1). Для этого входной LER (LER А) вставляет в начало каждого поступающего от отправителя пакета данных небольшую метку фиксированного формата. Хотя подобное решение является локальным, оно выполняется с учетом адреса получателя, требований QoS и текущего состояния сети. Заметим, что точный формат метки и способ ее добавления к пакету зависит от используемой технологии канального уровня в конкретной MPLS-сети. К примеру, метка может соответствовать виртуальным каналам ATM VPI/VCI, Frame Relay DLCI или длине волны DWDM в случае оптической сети.

Каждый транзитный LSR (LSR В) содержит таблицу соответствий <входной интерфейс, метка_n ><выходной интерфейс, метка_m >, на основании которой осуществляется коммутация пакетов. Как нетрудно понять из приведенной нотации, пакет, пришедший на входной интерфейс с одним значением метки, направляется на выходной интерфейс с другим значением -- происходит так называемый обмен метками. Таблица соответствий весьма проста, и решение о выборе маршрута вместе с процедурой обмена меток может быть выполнено на аппаратном уровне. Этот способ маршрутизации намного быстрее, чем традиционный анализ IP-заголовка, что и позволило говорить о коммутации. Поскольку соответствие между значениями входной и выходной метки для каждого маршрута, называемого Label Switched Path (LSP), постоянное, то он определяется начальной меткой. Набор пакетов, которые разделяют один LSP, именуется эквивалентным классом пересылки (Forwarding Equivalence Class -- FEC). Граничный LER на выходе (в нашем случае -- LER C и LER D) функционирует аналогично транзитным LSR, но пара <выходной интерфейс, метка_k > заменяется соответствующим LSP. Далее он удаляет метку пакета и направляет его адресату на основании своей маршрутной IP-таблицы.

Как уже упоминалось выше, MPLS является технологией, ориентированной на соединение. Это значит, что для передачи данных используется модель, которая предусматривает три четко выраженные фазы: установление соединения, передача данных и разрыв соединения.

Соединение, или LSP, может быть установлено с помощью разных механизмов, базирующихся, однако, на одном из двух общих основных прин-ципов: либо в ответ на запрос входного LER выходному LER (нисходящий по запросу -- downstream-on-demand), либо заблаговременно с помощью LSR и выходного LER (нисходящий без запроса -- downstream-unsolicited). Возможно сочетание обоих. Для формирования LSP используются традиционные протоколы маршрутизации и протоколы обмена метками (Label Distribution Protocol -- LDP), на которых мы не будем останавливаться.

Туннели и стеки меток

Рис. 1

Рис. 2

Рис. 3

Ключевая особенность MPLS заключается в том, что если LSP сформирован, то для пересылки данных по этому пути внутренние LSR не нуждаются в анализе содержимого передаваемых пакетов. Имея это в виду, LSP часто рассматривают как туннель через всю сеть MPLS или через ее магистральную часть. Это значит, что все полезные данные, включая IP заголовки, могут быть зашифрованы без нарушения способности сети передавать пакеты по назначению. На рис. 1 оба LSP функционируют как туннели: LSR В пересылают пакеты только на основании прикрепленных к ним меток. Они не инспектируют содержимое пакетов или инкапсулированных IP-заголовков.

Выходные LER могут распределять метки для множества FEC и устанавливать множество LSP. Там, где эти LSP параллельны, их можно маршрутизировать группой по туннелю более высокого уровня. Маркированным пакетам, входящим в высокоуровневый туннель, присваивается дополнительная метка. При этом метки начального уровня остаются, чтобы разобрать пакеты при выходе из туннеля. Таким образом формируется стек меток. Это позволяет LSR в ядре сети пересылать данные, базируясь только на метке высшего уровня, что уменьшает размер маршрутной таблицы и упрощает управление данными в магистрали. На рис. 2 два LSP между LER А и LER Е и между LER В и LER Е, соответствующие красным и синим меткам, прозрачно туннелируются через магистраль в одном LSP более высокого уровня между LSR С и LER Е. Для этого на входе в туннель LSR С добавляет метку (показано желтым цветом) в стек каждого пакета. На выходе верхняя метка удаляется из стека, и пакеты коммутируются на основании внутренних меток. В приведенном примере маршрутизатор на выходе из туннеля является также граничным в MPLS-сети, поэтому он удаляет и внутренние метки. Рассмотрим теперь...

...элементы VPN-решений на базе MPLS

Основой любого решения является использование LSP-туннеля для продвижения данных между фронтальными маршрутизаторами поставщика услуг, которыми ограничивается определенная VPN. Присваивая метки соответствующим пакетам, LER и LSR надежно сепарирует VPN-потоки от остальных данных, передающихся по магистрали. Это разделение представляет собой ключевой механизм, по-средством которого MPLS может поддерживать следующие характеристики схемы VPN-туннелирования, определяемые в RFC 2764:

инкапсуляцию данных независимо от применяемых протоколов, поскольку пакеты передаются по туннелю непрозрачно для промежуточных маршрутизаторов, формирующих магистраль;
мультиплексирование трафика различных VPN, передаваемого по разделяемой магистрали, посредством использования отдельных LSP-туннелей для каждого источника данных;
аутентификацию конечных точек LSP-туннелей с помощью про-токолов распределения меток (LDP);
обеспечение необходимого уровня QoS путем резервирования сетевых ресурсов для LSP-туннеля. MPLS поддерживает как IntServ, так и DiffServ;
надежную коммутацию и автоматическое перенаправление -LSP-туннеля за счет исключения -неисправного канала или маршрутизатора без вмешательства ад-министратора. Этот защитный механизм действует на нескольких различных уровнях, включая встроенный в LDP механизм обновлений на основании последовательных подтверждающих активность сообщений, повторный выбор LSP-туннеля, предварительную инициализацию альтернативных маршрутов, определение длины волны отказавшего канала в оптических сетях.

LSP-туннель представляет отличный способ инкапсуляции данных в канале между двумя LSR. Но как LSR определяют, какие LSP установить, чтобы обеспечить связность узлов для виртуальных частных сетей? По сути, как одни LSR решают, какие другие LSR обеспечивают доступ к VPN, которые они сами обслуживают? И далее, даже если это будет однажды установлено, как различные VPN отображаются на LSP-туннели -- отдельный туннель для каждой или единый туннель для всех VPN? Это сложные вопросы, которые не имеют единого "правильного" ответа.

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

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

Другая возможность заключается в присоединении признака принадлежности к VPN и маршрутной информации к протоколам IGP и EGP (напомним, что протоколом внутреннего шлюза (Interior Gateway Protocol) называется любой протокол маршрутизации, распределяющий маршруты внутри единственной автономной системы, к примеру OSPF, в то время как протокол внешнего шлюза (Exterior Gateway Protocol) применяется для распределения маршрутов между автономными системами, например BGP (Border Gateway Protocol) для Интернета). Такой подход позволяет использовать надежный механизм распределения, построенный на протоколах, способных сделать информацию о принадлежности к VPN доступной всем узлам LSR. При необходимости протокол маршрутизации может также служить для распределения внутренних меток для каждой VPN. Один из недостатков этого метода состоит в том, что он требует модификации соответствующих маршрутных протоколов. Существующие реализации требуют изменения кода, что весьма рискованно и может привести к нарушению стабильной работы сложной программы.

Вероятно, наиболее гибким методом обнаружения LSR VPN является чтение необходимой информации из директорий X.500 или LDAP. В этом случае каждый LER содержит лишь идентификаторы VPN, к которым он принадлежит. LER может затем узнать о топологии всех туннелей VPN LSP, которые требуется установить, -совместно со связанными с каждым туннелем маршрутами прямо из директории. Замечательно то, что это решение является универсальным и пригодно для всех типов VPN. Директория может также содержать другую информацию для поддержки VPN, которая должна быть синхронизирована во всех LSR, например PKI базированное шифрование данных или установка и хранение приоритетов для каждого VPN-туннеля. Дисциплина использования VPN директорий все еще должна быть определена и стандартизована. Если это будет проделано, идентификация LSR VPN с помощью директорий обеспечит исключительный метод обнаружения одноранговых VPN-узлов. Данная техника может быть реализована без какой-либо модификации протоколов маршрутизации.

Мультиплексирование VPN и класс обслуживания

Одна из ключевых задач, которую нужно решить поставщику услуг, заключается в том, чтобы сбалансировать необходимость минимизации числа LSP-туннелей, пересекающих ядро сети, и желание предоставить каждому заказчику запрашиваемый уровень услуг (Service Level Agree-ment -- SLA). Управлять SLA для заказчиков легче, если для каждой VPN предоставляется отдельный LSP-туннель. Однако здесь могут возникнуть проблемы, связанные с требуемыми ресурсами для создания и управления таким количеством туннелей.

Мультиплексирование нескольких VPN в один LSP-туннель осуществляется с помощью стека меток. Но это решение является чисто техническим и нуждается в согласовании с проводимой поставщиком услуг политикой и способом, каким выполняется мультиплексирование. Политика предполагает ответы на два вопроса: какой класс услуг (Class of Service -- CoS) предоставить и как мультиплексировать VPN и CoS в туннели LSP, проходящие через ядро сети.

Многие пользователи желают получить гарантированный минимум полосы пропускания по каналам VPN. Однако предоставление фиксированной полосы, которая обеспечивала бы необходимую максимальную скорость передачи данных между VPN-сайтами, неэффективно и дорого как для провайдера, так и для заказчика. Намного лучший вариант -- создание сети с резервом, превышающим минимальные требования по полосе пропускания, но разделяемой как данными VPN-заказчиков, так и общим трафиком Интернета. Разделение могло бы выполняться с учетом уровня CoS (например, "золотой", "серебряный", "бронзовый"), на который подписался заказчик.

Технология MPLS вполне поддерживает подобные решения. Механизм разделения общей полосы пропускания подобен DiffServ, однако в данном контексте будет использоваться терминология CoS, чтобы не смешивать с сервисом, предоставляемым Интернетом, который также может быть доступен в пределах любой из VPN.

Ответственность за отображение комбинации VPN и DSCP (DiffServ Code Point) на туннель LSP несет входной LER, и для передачи данных через ядро сети используется CoS. Оригинальный код DSCP инкапсулируется и пересылается сквозь ядро сети к выходному LER, так что различные наборы CoS в ядре прозрачны для сетей заказчика. Этот процесс показан на рис. 3.

Что касается мультиплексирования VPN и CoS в один внешний туннель, проходящий через ядро сети, то это может быть выполнено различными способами, на которых мы не будем останавливаться. Однако во всех случаях дополнительные уровни QoS внутренних туннелей могут также использоваться, чтобы служить отличительным признаком для специфических адресатов на выходном LER. Например, выходной LER способен обеспечивать доступ к более чем одному сегменту сети заказчика. Эти сегменты могут снабжаться отдельными VPN ID с помощью стека меток.

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365