Рано или поздно каждого сетевого администратора настигает задача растянуть L2 домен. После этого любой IT-администратор достает бубен и начинает танцевать танец разной степени сложности: от Pseudowire до Ethernet over GRE. Не миновала эта задача и нас (уж очень наши ИБ-продукты любят анализировать SPAN трафик). А решать мы ее решили с помощью нашего же продукта Kaspersky SD-WAN.



Растянутый L2, SPAN, информационная безопасность и SD-WAN — довольно странный набор сетевых технологий для статьи, но, если бы автор вам предложил почитать про очередные active/active балансировки по unequal cost каналам связи в SD-WAN это было бы не так любопытно.

В этой статье делимся опытом и показываем, как настроить решение в режиме передачи L2 трафика между филиалами. И, забегая вперед, можем сказать, что все получилось настолько просто, что даже бубен доставать не пришлось.

Зачем нам потребовалось передавать L2 трафик между филиалами.

Есть такой узкоспециализированный продукт для информационной безопасности технологических процессов Kaspersky Industrial CyberSecurity (KICS). И есть в этом продукте компонент под названием KICS for Networks, задача которого осуществлять мониторинг информационной безопасности промышленной сети. Если не вдаваться в детали, компонент этот представляет собой сервер, на который может поступать SPAN трафик для анализа более 50 промышленных протоколов на прикладном уровне. Если точки съема трафика географически распределены, то есть отличное решение в виде сенсора, который также может выступать приемником SPAN трафика, терминировать его на себе, и далее уже по L3 осуществлять взаимодействие с центральным сервером. Деталей несколько больше, но такого верхнеуровневого описания должно быть достаточно для дальнейшего понимания сути проблемы.

Казалось бы, все хорошо: главный сервер в центре, серверы-сенсоры в филиалах. Строй себе иерархию, да подключай удаленные участки сети для мониторинга. Но тут возникла история, издалека кажущаяся довольно стандартной. Многие пользователи столкнулись с проблемой — удаленных точек для съема SPAN трафика было достаточно много, но каждая из точек сама по себе была слишком маленькой для установки целого сервера-сенсора. Судите сами, сенсор рассчитан на съем данных с сотен, а то и тысяч источников. Устанавливать его в филиале, где всего несколько источников трафика, оказалось и дорого, и технически избыточно. К слову, и максимальное количество сенсоров на одну инсталляцию не так велико. Нужно было найти вариант сэкономить бюджет заказчика и при этом безопасно передать весь SPAN-трафик из большого количества маленьких филиалов на центральный сервер.

Что за зверь Kaspersky SD-WAN?

Это наше SD-WAN решение, которое в подкапотном пространстве существенно отличается от аналогов, что есть на разных рынках планеты. Конечно, как и практически все SD-WAN решения на рынке, оно умеет балансировать по active/active каналам связи, даже при условии, что у каждого канала разный вес, разная полоса пропускания, разная физика, если хотите. Кроме этого, как и многие другие продукты, наш умеет смотреть насколько хороши сейчас джиттер, задержки и прочие характеристики каналов связи и при необходимости переводить нужный трафик на канал с лучшими характеристиками. «Но как это поможет в решении выше озвученной задачи?», — уже наверняка задается вопросом читатель. Ответ – никак.

Действительно, большинство решений SD-WAN на рынке, включая зарубежные, просто не смогут решить поставленную выше задачу. Но Kaspersky SD-WAN базово представляет собой не только SD-WAN, а классический SDN. Фактически оно превращает вверенный ему underlay в растянутый коммутатор, поверх которого уже можно построить разные топологии: Pseudowire P2P или звезду или даже Full Mesh L2 топологию. А при должной конфигурации, навесив L3 IPv4 адреса на виртуальные порты этого коммутатора можно получить все те же P2P, P2M, M2M топологии, но уже в исполнении L3 VPN сервисов, что уже подводит к решению задачи передачи SPAN трафика.


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

Безусловно концепция концепцией, но скептически настроенный читатель логично скажет: «А покажи в деле».

L2 домен SD-WAN на практике. Руководство к действию.

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



В верхней части схемы представлены четыре площадки с CPE устройствами Sochi-L3, Portable-L3, Olimpia-L3 и Altay-L3 в режиме L3. CPE устройства могут выступать в качестве L3 шлюза для удаленного сегмента сети, маршрутизировать трафик через формируемую WAN-сеть, а также, при необходимости, обеспечивать локальный выход в сеть Интернет для удаленной площадки при помощи настраиваемой функции Direct Internet Access. Локальные сегменты подключены к сетевым интерфейсам eth2. Сетевое взаимодействие между площадками осуществляется посредством транспортного сервиса M2M и с использованием протокола BGP для динамической маршрутизации.

Для передачи IP трафика между площадками Sochi-L3, Olimpia-L3, Portable-L3 и Altay-L3 используется бридж с именем ‘lan’ с физическим сетевым интерфейсом eth2 на CPE, выступающим в качестве шлюза «по умолчанию» для локального сегмента сети. Для обмена маршрутной информацией с использованием BGP используется специальный сервисный сетевой интерфейс overlay.1 (dot1q tag 1), который впоследствии объединяется в M2M логическую сеть для передачи L3 трафика между сайтами. Сервисный интерфейс для транспортного сервиса M2M создается с использованием VLAN 1 / overlay.1.


Площадки Olimpia-L3 и Altay-L3 отправляют копию сетевого трафика SPAN с физических сетевых интерфейсов CPE eth3 на площадку Sochi-L3 с использованием транспортного сервиса P2M. Сетевой интерфейс eth3 на площадке Sochi-L3 связан с сервисным интерфейсом, имеющим роль Root (Hub), а на площадках Olimpia-L3 и Altay-L3 c ролью Leaf (Spoke). Трафик, приходящий на сервисный интерфейс с ролью Leaf направляется только в сервисный интерфейс с ролью Root.

Для передачи SPAN трафика от Olimpia-L3 и Altay-L3 к Sochi-L3 используется бридж с именем ‘span’, соединяющий сетевые интерфейсы eth3 и overlay.3 (dot1q tag 3). Сервисный интерфейс для транспортного сервиса P2M создается с использованием VLAN 3 / overlay.3.

В нижней части схемы изображены три площадки с CPE устройствами Sochi-L2, Portable-L2 и Olimpia-L2 в режиме L2. CPE устройства между площадками Sochi-L2 и Portable-L2 создают только «растянутый» через сеть WAN VLAN, а CPE устройство на площадке Olimpia-L2 передает только копию трафика SPAN на площадку Sochi-L2.

Для передачи IP трафика между площадками Sochi-L2 и Portable-L2 используется бридж ‘lan’, соединяющий интерфейсы eth2 overlay.2 (dot1q тэг 2). Сервисный интерфейс для транспортного сервиса P2P создается с использованием VLAN 2 / overlay.2.

Для передачи SPAN трафика от Olimpia-L2 к Sochi-L2 используется бридж ‘span’, соединяющий сетевые интерфейсы eth3 и overlay.3 (dot1q тэг 3). Сервисный интерфейс для транспортного сервиса P2P создается с использованием VLAN 3 / overlay.3.

Настройки передачи IP трафика между площадками Sochi-L3, Olimpia-L3, Portable-L3 и Altay-L3 с сервисом M2M, и SPAN трафика от Olimpia-L3 и Altay-L3 к Sochi-L3 с сервисом P2M

Список сетевых интерфейсов CPE Sochi-L3:



Сетевой интерфейс CPE Sochi-L3 lan:




Сетевой интерфейс CPE Sochi-L3 overlay1:




Сетевой интерфейс CPE Sochi-L3 overlay3:




Сетевой интерфейс CPE Sochi-L3 span:




Сетевые интерфейсы CPE Portable-L3. Настройка сетевых интерфейсов Portable-L3 аналогична настройке сетевых интерфейсов Sochi-L3. У CPE Portable-L3, в отличии от Sochi-L3 нет интерфейса overlay3



Сетевые интерфейсы CPE Olimpia-L3. Настройка сетевых интерфейсов Olimpia-L3 аналогична настройке сетевых интерфейсов Sochi-L3.



Сервисные интерфейсы CPE Sochi-L3:

• VLAN 1 – межсетевое взаимодействие между площадками.
• VLAN 3 – передача SPAN трафика от Olimpia-L3 и Altay-L3 к Sochi-L3.

Сервисные интерфейсы CPE Olimpia-L3 и Altay-L3 аналогичны Sochi-L3:

• VLAN 1
• VLAN 3

Сервисный интерфейс CPE Portable-L3:

• VLAN 1

Транспортный сервис P2M для передачи SPAN трафика от Olimpia-L3 и Altay-L3 к Sochi-L3:



Транспортный сервис M2M для сетевого взаимодействия между Sochi-L3, Portable-L3, Olimpia-L3 и Altay-L3:




И теперь, наконец, можно увидеть SPAN трафик на интерфейсе eth3 Sochi-L3, полученный от Olimpia-L3 и Altay-L3:



А также проверим L3 взаимодействие между площадками:



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

Настройка «растянутого» VLAN между Sochi-L2 и Portable-L2 с сервисом P2P и передачи SPAN трафика от Olimpia-L2 к Sochi-L2 с сервисом P2P

Топологии P2M, M2M рассмотрели, осталось ознакомиться с порядком настройки Pseudowire. Для этого подготовим растянутый VLAN между Sochi-L2 и Portable-L2 и обеспечим передачу SPAN трафика от Olimpia-L2 к Sochi-L2 по уже знакомому подходу к настройке.

Список сетевых интерфейсов CPE Sochi-L2:



Сетевой интерфейс CPE Sochi-L2 lan:




Сетевой интерфейс CPE Sochi-L2 overlay2:




Сетевой интерфейс CPE Sochi-L2 overlay3:




Сетевой интерфейс CPE Sochi-L2 span:




Сетевые интерфейсы CPE Portable-L2. Настройка сетевых интерфейсов Portable-L2 аналогична настройке сетевых интерфейсов Sochi-L2. У CPE Portable-L2, в отличии от Sochi-L2 нет интерфейсов overlay.3 и span.



Сетевые интерфейсы CPE Olimpia-L2. Настройка сетевых интерфейсов Olimpia-L2 аналогична настройке сетевых интерфейсов Sochi-L2. У CPE Olimpia-L2, в отличии от Sochi-L2 нет интерфейса overlay.2.



Сервисные интерфейсы CPE Sochi-L2:

• VLAN 2
• VLAN 3

Сервисный интерфейс CPE Portable-L2:

• VLAN 2

Сервисный интерфейс CPE Olimpia-L2:

• VLAN 3

Транспортный сервис P2P для «растянутого» VLAN между Sochi-L2 и Portable-L2:




Транспортный сервис P2P для передачи SPAN трафика от Olimpia-L2 к Sochi-L2.:




Готово! Посмотрим на SPAN трафик на интерфейсе eth3 Sochi-L2, полученный от Olimpia-L2:



А также проверим межсетевое взаимодействие между площадками Sochi-L2 и Portable-L2:

Финал истории

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

Можно ли было для решения задачи обойтись более традиционными способами? Привет, ERSPAN! Да, можно, но в примере выше было показано решение задачи под единым зонтиком управления и мониторинга оркестратора Kaspersky SD-WAN со всеми теми дополнительными возможностями по управлению трафиком, которые продукт умеет на борту – работа с UCMP, гарантированная доставка трафика с использованием Forward Error Correction или Packet Duplication, если нужна гарантия доставки SPAN пакетов.

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