SD-WAN Kaspersky — рассматриваем решение, сравниваем с SD-WAN BI.ZONE, выясняем плюсы и минусы каждой из этих двух технологий, делаем выводы.
Пришла пора схватки боссов. SD-WAN Kaspersky vs SD-WAN BI.ZONE. Задача посмотреть что "под капотом" и определить нишу для каждого из двух решений. Либо же сказать что решения равнозначны и полностью взаимозаменяемы.
Документация для SD-WAN Kaspersky 2.0 открыта и доступна (посмотрите сразу эту ссылку и ищите там, что непонятно здесь по тексту). У Бизона всё сложнее, документация только для заказчиков (с логином и паролем). 🙂
При рассмотрении есть три сложности:
- Относительно хорошо знаю решение BI.ZONE. Решение от Касперского видел на бумаге (и в лабе). Как оно работает в реале (и работает ли), у меня нет информации.
- Вторая сложность, расскажу малую часть SD-WAN Kaspersky. Там углубляться и углубляться. Функционал ну очень развесистый. Возможно пяток статей покрыли бы, но не одна.
- Третье, из-за развесистой
клюквыначинки Касперского могу где-то смело наврать. Могу также наврать про BI.ZONE по причине того, что компания не стремиться раскрывать свои технологии в деталях.
Изложил как сам понял, плюс чуть фантазии. Поправки в комментариях приветствую, обогащает знанием. Прошу понять и простить принять во внимание.
История SD-WAN Kaspersky
Российская фирма Brain4Net создала уникальную разработку — собственный SD-WAN. Согласитесь, не каждая компания на такое способна.
Изначально SD-WAN Brain4Net вообще не имел графического интерфейса, а конфигурация деплоилась на Контроллер через файл настроек. Сам этого не видел, рассказали коллеги, которые смотрели решение на предмет покупки. Не уточню когда точно, больше чем два года назад. То есть совсем простенько. Затем графический интерфейс таки доделали. Решение предлагалось именно как ПО для виртуализации, какого-то железа под него на момент не существовало.
Разработками Brain4Net заинтересовались в Касперском. Да и прикупили всю компанию целиком. Так появился SD-WAN Kaspersky. Проект получил новое развитие.
И дальше решение стали допиливать уже специалисты Касперского. Допилили GUI, добавили фичей, усилили требования к безопасности, обзавелись рекомендованным железом. У фирмы Касперского действительно большой опыт в разработке. В результате получился законченный продукт, названный SD-WAN Kaspersky 2.0. Его мы и будем посмотреть. В числе фич для 2.0: ZTP, VRRP, DPI, Full/Partial Mesh топологии, централизованное обновление CPEs с поддержкой расписания.
Первое что тут надо сказать, несмотря на появившееся железо, продукт по-прежнему в первую очередь ПО. Так говорят сами сотрудники Касперского, подробнее далее. Второе, на сегодня проводится агрессивная маркетинговая политика по внедрению продукта на рынок. И это хорошо, почему хорошо в заключении.
Лаба SD-WAN Kaspersky
Спецы Касперского в рамках продвижения продукта организовали вебинар "Kaspersky SD-WAN 2.0: функциональные возможности и практический опыт" . Вебинар шёл целую неделю (видео по дням прикладываю, немного подрезал, приятного просмотра). Большая часть моей статьи — это вольный пересказ вебинара (не скрываю этого).
Затем всем желающим предлагалось попробовать лабу с живым SD-WAN в тестовой среде. Конечно же не мог пройти мимо. Лаба выдернута из двухдневного курса Kaspersky SD-WAN (KL 004.2). По сути Касперский подарил стоимость этого курса, спасибо.
Лаба очень большая, из 8 частей (создание нового проекта с нуля, с настройкой шаблонов, с активацией CPEs, с эмуляцией отказа канала, с переключением канала при выходе за требуемые параметры качества, с проверкой работы коррекции ошибок). Поэтому лабу подробно пересказывать не буду. Вы всё равно не запомните (скачать PDF нельзя по нескольким причинам). А лучше сосредоточусь на своих субъективных впечатлениях. На том, что мне бросилось в глаза.
Итак, сначала тебя ждёт простенькая страничка входа:
Какой-то дополнительной защиты, второго фактора или сертификата (как у BI.ZONE), не предусмотрено. Упущение. Это же не вход в какую-то очередную консоль, нет. Это стратегический центр сети всей компании.
Дашборда
После введения кредитов попадаем в даршборду:
Логика настройки SD-WAN следующая, сначала создаётся новый Домен (название), новый Data Center (название и URL для подключения к VNF Manager, последний предполагается уже настроенным, о том что это — будет далее). Нужно указать IP адрес Zabbix Proxy (тоже уже типа есть и настроен).
Понравилось, серьёзный подход. Хотите SD-WAN? Давайте сразу Zabbix, будем всё мониторить. Графики Zabbix должны интегрироваться в GUI SD-WAN.
Затем Область IP-адресов для управляющих интерфейсов цпешек (MGMT-Net).
И наконец Тенант. Напомню, что одна инсталляция позволяет развёртывать несколько тенантов. В каждом их них свой проект, свой независимый SD-WAN. Со своим Web-интерфейсом (Self-Service Portal), своими админами, своим оборудованием и так далее.
Создание инстанса SD-WAN и CPEs
Затем создаётся уже инстанс самого SD-WAN в виде PNF, Physical Network Function (не единственный вариант развёртывания как оказалось). И привязывается к тенанту. В чём отличие PNF от VNF?
PNF is a physical device that cannot be virtualized as a VNF or Cloud Native Function (CNF).
В документации к SD-WAN Kaspersky написано:
PNF — заранее развернутая сетевая функция, которая в готовом виде загружается в веб-интерфейс Оркестратора. Оркестратор может осуществлять дальнейшую конфигурацию PNF.
Широко используются шаблоны. Для всего чего можно, для самого инстанса SD-WAN, для CPEs. Сначала ты создаёшь пустой шаблон. Потом подгружаешь в него из архива данные (в архиве есть XML-конфиг, настройки в нём можно поправить руками). На основании готового шаблона генерятся уже конечные элементы. Если нужно после генерации из шаблона обновить настройки, ты редактируешь их уже в GUI. Достаточно удобно.
В процессе добавления нового CPE необходимо указать идентификатор DPID, он берётся непосредственно в консоли VM для CPE (а формируется на основе MAC-адреса). Выглядит это так:
root@ и есть нужный нам DPIDКонсоль и активация CPE
К слову, консоль CPE достаточно функциональная. Сюда выводятся системные сообщения об изменениях в работе и тут доступны полезные команды (некоторые сразу, некоторые после ввода vtysh):
# ping ... # vtysh # show bgp summary # show ip route
После создания CPE в её настройках получаем строку активации для ZTP. И вставляем в браузер. Настройки передаются на VM CPE. Происходит подключение CPE к Оркестратору, затем обмен данными. Через некоторое время CPE готово к работе (активировано).
ZTP URL-ссылка содержит сетевые настройки, FQDN Оркестратора и его сертификат, CPE DPID и токен для 2FA.
Что ещё сразу заметно, так это обилие настроек. Их просто масса для всего чего угодно.
Настройки для мониторинга каналов
Настройка Ignore if no constrained path found говорит не производить переключение, если канал с заданными характеристиками не найден. Тут можно повыбирать как точно настроить. Затем применение на линке, уже со значениями ожидаемых характеристик канала.
Как видно параметров мониторинга качества больше, чем у Бизона (там только потери, джиттер и задержка). Трафик может отбираться прокаченным движком DPI (десятилетия разработки антивируса), а у Бизона DPI нет (отбор трафика по ACLs или DSCP).
Настройки для Forwarding Error Correction
Передающее устройство CPE кодирует поток выходящих в туннель пакетов трафика с добавлением избыточных пакетов. Степень избыточности можно настроить через параметры Контроллера SD-WAN или на отдельном туннеле.
Избыточный пакет содержит контрольные суммы для группы пакетов. Тогда при потере одного пакета из группы, по оставшимся пакетам группы и по контрольному пакету возможно восстановить потерянный пакет.
Восстановлением правильного порядка пакетов на выходе занимается допиленный OVS-коммутатор. Он в составе прошивки CPEs.
API
Управление Kaspersky SD-WAN основано на REST API. Им можно и нужно пользоваться. В том числе из GUI.
Конечно можно использовать и внешние инструменты для отправки API-запросов на SD-WAN. Всё это поможет автоматизировать рутинные операции.
Вывод
Ещё раз, у меня не было задачи показать все настройки. Задача — обратить внимание на специфику SD-WAN от Касперского. Надеюсь некоторое впечатление сложилось, некий вкус ощутился.
Процесс настройки нового развёртывания Kaspersky SD-WAN гораздо сложнее такого же в BI.ZONE. И состоит из пары десятков совсем непрозрачных операций. Далее вы увидите (надеюсь подсветил этот момент хорошо), что и само решение катастрофично сложнее.
Что показала эта лаба? Продукт от Касперского абсолютно иной, нежели BI.ZONE.
Начнём углубляться. Как мы знаем, любое сетевое решение делится на Management Plane, Control Plane, Data Plane. Можно выделить ещё уровни, но классически именно так. Рассмотрим. Начнём с BI.ZONE, потом перейдём к Касперскому.
Архитектура SD-WAN BI.ZONE
Пробежимся кратко, так как отчасти уже рассказывал. В качестве Management Plane, Control Plane был разработан собственный протокол BCMP. Разработать свой протокол весьма непростая задача. За это респект.
Data Plane (то что стоит туннели и передаёт данные) — модифицированный WireGuard (добавлены транспортные метки, возможно ещё что-то). В WireGuard уже есть нативное шифрование ChaCha20. Стойкость ко взлому находится на уровне между AES128 и AES256. Авторитетных бенчмарков на производительность так и не нашёл. Некоторые процессоры умеют аппаратное ускорение AES, некоторые нет, поэтому тут сложно сказать.
Оркестратор совмещён с Контроллером в All-in-One VM. Вся внутрянка это контейнеры. Сюда дополнительно прикручиваются VNF, каждая тоже в виде контейнера. "Каждая" сказано сильно. Пока это единственная VNF в виде очень простого FW. Ну и каких-то сторонних VNF не предусмотрело решением.
Лицензируются пропускные способности CPEs. Для ГОСТ-шифрования отдельные лицензии.
Получилось компактно и просто. Одна VM, BCMP занимается оркестрацией и управлением, а WireGuard непосредственно туннелями.
Плюсы и минусы
Простота гарантирует надёжность, при этом создаётся некоторая ограниченность. Скромность возможностей, я бы сказал. Нету гибкости. "Радостей жизни" типа BFD/BGP Soft Reconfiguration не предусмотрено в принципе. Когда на очередной встрече спросили у разрабов: "А где BFD?", они были прям удивлены таким вопросом. И каких-то вариантов развёртывания не существует. Вариант всегда один.
Что ещё? Много, прям очень много багов. Некоторая сырость решения. Баги и фичи допиливаются крайне медленно. Давно обещанный, необходимый функционал постоянно отодвигается на "когда-то потом". Тут просьба не пугаться и не помечать BI.ZONE в чёрный список. Как раз на нашем внедрении основные баги пофиксили. Проведена большая работа, множество тестов в постоянной коммуникации с разработчикам. Приняли это на себя. А вы теперь можете спокойно внедрять решение не затрудняясь проблемами. И всё что нужно на текущий момент — добавить фичи. Но даже и без этих фич решение хорошо работает. Как хорошо? Лучше чем DMVPN. Подробнее расскажу в завершающей статье про SD-WAN BI.ZONE.
Есть уже внедрённые, довольно-таки крупные проекты. Есть своя линейка оборудования.
Архитектура SD-WAN Kaspersky 2.0
Для более подробной инфы смотрите видео вебинара.
Здесь пошли по абсолютно другому пути. Собрали SD-WAN из множества готовых кусочков с некоторой модификацией. Кусочки выбрали тоже специфические. Напихали чего только можно, даже MongoDB засунули в решение (база CPEs в Оркестраторе).
Management Plane
Management Plane организован с помощью REST API. Здесь Оркестратор. Его функции:
- Предоставляет единый графический интерфейс, GUI;
- Отвечает за управление сервисами SD-WAN;
- Содержит базу CPEs;
- Отвечает за онбординг CPEs;
- Управляет средой виртуализации (VIM, VNFM);
- Дополнительно поддерживает автоматизированное средство доставки на CPEs Ansible, Python, Bash скриптов.
Control Plane
В качестве Control Plane выступает framework OpenFlow. Разработан он довольно давно, в начале пути SDN. С тех пор много раз перерабатывался. Нужен, понятное дело, чтобы высчитывать куда направлять трафик (программирует таблицы потоков). Здесь Контроллер. Он построен также как и у Бизона на контейнерах, тут ничего нового. Его функции:
- Обеспечивает построение требуемой топологии сети с помощью Overlay Network (подробнее далее);
- Управляет созданием транспортных сервисов;
- Выполняет мониторинг качества каналов;
- Переключает потоки трафика (штатно по TA, аварийно при отказе канала, интерфейса, CPE);
- Пишет логи.
Data Plane
Главное отличие от BI.ZONE — протокол Data Plane Geneve. Появился как логичное развитие VXLAN. Это одна из фич версии 2.0, изначально использовался как раз VXLAN. Причина тут поддержка новым протоколом дополнительных полей TLV (Type-Length-Value, это такой формат представления данных), которые расположены за базовым заголовком Geneve. Разработчики могут создавать свои поля, помещать туда (для этого и сделано) некоторую потребную им информацию. Поля используются конкретно в SD-WAN Kaspersky для передачи телеметрии (временных меток, параметров канала). В результате чего на Контроллере возможно в реальном времени высчитывать SLA для каждого канала связи.
Geneve дружелюбен к протоколам Control Plane или как написано в спецификации:
Geneve is a pure tunnel format specification that is capable of fulfilling the needs of many control planes by explicitly not selecting any one of them.
Основная задача Geneve строить туннели и таскать VLANs между локациями. Его природа создавать именно L2 связность (L2 поверх L3). Затем поверх готовой L2 связности натягивается Overlay Network. Здесь уже получится развернуть любую топологию. Такая уникальная гибкость даёт множество сценариев использования.
Поэтому SD-WAN Kaspersky по сути своей растянутый коммутатор. Можно назвать так. Можно сказать L2 SD-WAN. Или SD-WAN с поддержкой L2. А можно сказать классический SDN, где есть Underlay/Overlay и прочие присущие вещи. Выбирай любое название из перечисленного, будет верно. При этом CPEs не роутеры, а скорее коммутаторы (хотя сама лаборатория Касперского называет их именно Service Router).
Шифрование так же как у Бизона ChaCha20, насильно прикрученное поверх Geneve. Смена ключей происходит раз в час. Поскольку прикрученное насильно, то есть возможность его отключить. Причём отключить для всех каналов сразу или же только для выборочных каналов. Пример сценария где шифрование отключается далее.
Развёртывание SD-WAN
При компактной установке Оркестратор/Контроллер устанавливаются в одну VM, там же база мониторинга, там же логи. Доступен скрипт автоматической установки Оркестратора/Контроллера на чистый линукс. Поддерживаемые ОС:
- Ubuntu версии 20 LTS и выше;
- Astra Linux версии 1.7 и выше.
Технически возможно разнести Оркестратор и Контроллер по разным VMs. Именно так и делается в случае реализации с отказоустойчивостью.
CPEs
Существует четыре вида CPE:
- GW, такое устройство, к которому подключаются другие CPEs (в стандартной терминологии Hub);
Устройство CPE, которому назначена роль шлюза SD-WAN. Шлюзы устанавливают туннели со всеми устройствами в сети, включая другие шлюзы, таким образом обеспечивая связность между всеми устройствами и Контроллером SD-WAN. Вы можете установить несколько шлюзов для отказоустойчивости.
То есть речь не о каком-то специфическом железе или софте, GW — топологическая роль only.
- CPE, такое устройство, которое подключается к GW (в стандартной терминологии Spoke);
Все CPEs устанавливают туннели с GWs, а между собой (по умолчанию) не устанавливают. Вот и вся разница между CPE и GW. Зачем в Касперском отошли от традиционной терминологии, не знаю. Некоторую путаницу это вносит.
- uCPE, такое устройство, которое подключается к GW и имеет дополнительный функционал по сравнению с обычным CPE (рассмотрим далее);
- Транзитное CPE, такое устройство, которое появляется в случае топологии Partial Mesh.
Опять же Транзитное CPE — это только выделенная топологическая роль. Работает на основе топологического тега. Одинаковый тег для нескольких CPEs (назначается в настройках CPE) выделяет их в Регион. И заставляет устанавливать прямые туннели между собой (Spoke-to-Spoke). Когда трафик от CPE к CPE идёт не через GW, а через промежуточное CPE, то вот это промежуточное CPE будет называться Транзитным. Оно всегда имеет теги из разных Регионов. А если у него теги из всех существующих Регионов, тогда оно превратится в GW. Лучше посмотреть на картинке, словами по-человечески не объяснить.
uCPE
Рассмотрим подробнее третье — universal CPE. uCPE несёт на себе гипервизор. И в отличии от обычного CPE позволяет развёртывать на этом гипервизоре виртуальные сетевые функции (VNFs). В виде VMs. В общем случае одна VNF может быть представлена сразу несколькими виртуальными машинами. Тут есть особенность, контейнеры возможны, но запускаются они тоже внутри VMs (подробнее вебинар Day4). Получается такое вот "жирное" CPE.
Разворачиваются VNFs через VIM. Развёрнутые VNFs управляются, конфигурируются с помощью VNF Manager (VNFM) в GUI Оркестратора. VNFM позволяет организовывать VNFs в сервисные цепочки.
Механизм работы uCPE
Простыми словами работает так:
- Вы настраиваете на uCPE несколько VMs, допустим Router, FW, IPS, Антивирус (в общем случае это произвольный софт, главное чтобы он заработал в виртуальной среде);
- Далее с помощью VNFM создаёте сервисную цепочку. То есть в какой последовательности пакет должен проходить ваши VNFs;
- Сервисная цепочка привязывается к uCPE;
- Пакет поступает на входной интерфейс uCPE, далее он передаётся на сервисную цепочку;
- После прохождения сервисной цепочки возвращается обратно на uCPE. И уже затем поступает на выходной интерфейс.
Такой механизм даёт полную свободу. Делай с пакетом/кадром всё что захочешь. У Бизона ничего похожего близко нету.
Тут важный момент. Это не односторонняя связка, есть обратная связь. О чём речь? В случае каких-то преднастроенных событий, VNFs через API могут отправлять запросы на Оркестратор/Контроллер, тем самым управляя политиками прохождения трафика, то есть работой SD-WAN.
Для обычных CPEs тоже существует подобная возможность. Но сервисные цепочки выполняются не локально на цпешке, а централизованно в DC. Тут понятно будет некоторая задержка при пересылке пакета, вдобавок к задержке при обработке.
Когда может быть востребовано использование uCPE? Допустим, по требованию регулятора должно быть ГОСТ-шифрование. У Касперского из коробки нет поддержки ГОСТ-шифрования. Используем uCPEs, выключаем собственное шифрование на канале, портируем продукт с ГОСТ-шифрованием в VNF, профит. Такая удивительная гибкость позволит обойти практически любую проблему. Но создаются дополнительные сложности в эксплуатации.
Транспортные сервисы
SD-WAN Kaspersky 2.0 предоставляет следующие виды транспортных сервисов:
- L2 Point-to-Point, P2P;
- L2 Point-to-Multipoint, P2M;
- L2 Multipoint-to-Multipoint, M2M;
- IP multicast;
- TAP;
- L3 VPN.
Служебный сервис P2M создаётся автоматически для любой установки SD-WAN. Он нужен для управления SD-WAN сетью (MGMT) и мониторинга параметров SD-WAN через Zabbix. Служебный сервис M2M cоздаётся вручную и используется для мониторинга качества каналов. TAP — сервис для сбора и передачи копии трафика. Для сервиса L3 VPN создаются логические интерфейсы L3 в тех точках, где туннели терминятся.
Разные типы транспортных сервисов возможно комбинировать в рамках одной железки. Справедливо и для служебного, и для пользовательского трафика. Допустим через CPE построена связность L3 для некоторого пользовательского трафика одной топологии и через это же CPE L2 связность для другого пользовательского трафика с другой топологией.
NAT
В случае топологии Star CPEs/uCPEs нормально работают за NAT. Потому что они инициируют создание туннелей. А далее трафик нормально ходит через туннели в обе стороны.
Транзитные CPEs и GWs работают только через статический NAT с прокидыванием порта UDP 4800 (4800-4803 в случае 4 WAN каналов на CPEs). Аналогично при топологии Full Mesh статический NAT с UDP 4800 для всех CPEs. С Оркестратором/Контроллером ситуация та же, только портов больше (TCP 80/443, 6653-6656).
Оркестратор должен быть доступен для всех устройств SD-WAN по своему IP/FQDN. Онбординг происходит именно к Оркестратору, при раздельной установке с Контроллером, нужно этот момент учитывать.
Конечно же в локальной сети у Оркестратора/Контроллера используется гораздо больше портов (для связи с Zabbix, Mongo, Syslog и ещё). Просто их не нужно прокидывать через NAT. Какие это точно порты и для чего, можно узнать из записи вебинара (Day3).
Traffic Engineering
Частично уже приводил при описании лабы. Тут сводно на картинке.
И поскольку есть DPI, задать качество канала возможно отдельно для любого приложения (L7), ну или почти любого.
FEC/Зеркалирование
Опять же, настройки были показаны при рассказе про лабу. Здесь обсудим сам механизм работы.
Сначала про коррекцию ошибок FEC. Оптимально использовать, если WAN-канал всего один. Здесь обязательно будет снижение пропускной способности. Если, допустим, каждый 5 пакет контрольный (как было в примере на картинке), значит в теории сразу минус до 20% от пропускной (сколько реально не знаю). Эффективная ширина канала снижается.
Далее, должна возрастать нагрузка на CPEs. Расчёт контрольного пакета математическая операция, расчёт потерянного пакета математическая операция, плюс изменение порядка пакетов. И при возрастании трафика/потерь нагрузка пропорционально увеличится. Насколько указанное критично, опять же не знаю.
Кроме того, при высоком уровне потерь эта штука перестанет работать. То если потеряно несколько пакетов из группы, по одному контрольному пакету мы их восстановить не сможем. Нужно увеличивать количество избыточных пакетов, снижая эффективную ширину канала далее.
Теперь про зеркалирование. Используем когда есть два WAN-канала. По каналам передаётся полностью бит в бит одинаковая информация. Возможно параллелить не весь трафик, а только определённые приложения (DPI). По одному каналу потерялись одни пакеты, по другому другие. В совокупности на CPE назначения потерь нет. Вроде бы, но если потеряются одни и те же пакеты? Получается потери всё равно будут. При высоким уровне потерь такое возможно.
И здесь вся таже самая песня про операции над пакетами. Это не бесплатно, утилизирует CPU.
Можно ли включить и FEC, и зеркалирование? Да, можно. В теории. Чем обернётся на практике, сказать сложно.
Не совсем однозначная вещи. Надо смотреть как работают эти фичи в реальной жизни, каков от них профит. Возможно у лаборатории Касперского уже есть подобная статистика.
ZTP
С завода KESR (рассказ про линейку оборудования далее) имеют включённый DHCP на LAN портах. Достаточно воткнуться ноутом в такой порт, открыть браузер и вставить туда строку активации. Понятное дело CPE должно иметь связность с Оркестратором через WAN порты. Здесь всё идентично Бизону.
Возможно безопасное ZTP, когда для окончания активации CPE администратор должен ввести в GUI заранее заданный пароль (токен для 2FA, один на всю фабрику или уникальный для каждого CPE, настраивается). Таким образом несанкционированное подключение CPE, даже при наличии правильной строки активации, становится невозможным. И конечно уже подключённые CPEs можно принудительно выключать и удалять (руками или по таймеру).
Отказоустойчивость
Для CPE это отказоустойчивая пара Active/Standby.
Специальный процесс на CPE следит за состоянием каналов, LAN/WAN интерфейсов и сделает переключение активной ноды в случае необходимости.
Также отказы могут детектиться за счёт BFD, VRRP, BGP. Вариантов настройки масса, всё зависит от конкретной топологии и предпочтений заказчика.
Отказоустойчивость для центральных элементов приведена на картинке.
Типичная схема развёртывания
А как развёртывают в реальной жизни? Типичная схема, которую предлагает клиентам сама лаборатория Касперского:
Тут мы видим два Оркестратора (кластер Mongo плюс Redis) с Арбитром, три Контроллера. Нужен Zabbix, нужна расшаренная папка, где будут храниться необходимые Оркестратору файлы (разговор про бэкапы, образы VNFs, скрипты, файлы конфигураций).
Откат на рабочую конфигурацию
Человеческий фактор никто не отменял и случайные ошибки могут иметь место. Если CPE отвалится от Оркестратора, то это плохая ситуация. Чтобы такого не произошло, реализован механизм автоматического отката на рабочую конфу.
Траблшутинг
Алгоритм базового траблшутинга представлен на картинке.
Виртуализация
Виртуализация построена в Kaspersky SD-WAN на базе концепции NFV, Netwotk Function Virtualization. Она позволяет перенести физические элементы телекоммуникационной инфраструктуры в VNFs. И выстраивать получившиеся VNFs в сервисные цепочки. На самом деле в цепочке могут присутствовать как VNFs, так и PNFs.
Основная идея NFV в отделении программного обеспечения от аппаратного. Решается использованием стандартных серверов x86:
- Общий пул ресурсов для VNFs разного типа;
- Нет привязки к вендору;
- Жизненный цикл железа отвязан от ПО.
Вторая идея — возможность оркестрации, автоматизации и масштабирования на лету.
Оркестратор взаимодействует с виртуальной средой не напрямую, а через VIM, Virtual Infrastructure Manager. В решении в качестве VIM используется OpenStack (хотя возможно внедрение и на VMware). Почему так, почему OpenStack, не могу знать. Понятно одно, при задействовании uCPEs решение сильно усложняется. И SD-WAN здесь только часть решения, содержащая VNFM.
Рассказал очень упрощённо (смотрите вебинар Day4 и вы гарантированно прочувствуете сколько там всего при таком развёртывании). Катастрофа сложности решения именно здесь.
Минусы NFV:
- Влезать в историю с uCPE/VNFs имеет смысл при действительно большой, активно развивающейся сети. Потому что только парк серверов, их размещение и обслуживание будет стоить денег;
- VNF может иметь гораздо меньшую производительность, чем специализированное аппаратное решение.
Линейка оборудования
Разделяется по пропускной способности. Тут есть некоторое лукавство (у Бизона пропускная способность указана с учётом шифрования):
На тестируемых устройствах не использовалась технология DPI (Deep Packet Inspection), а также было выключено шифрование трафика.
Kaspersky Edge Service Router (Модель 1 от Булат, остальные от Крафтвей).
SD-WAN Kaspersky 2.0 — это ПО, уже говорил, поэтому образ CPE может быть установлен на собственное оборудование заказчика со сходными характеристиками. Смысл линейки оборудования от Касперского здесь, что она гарантирует 100% совместимость с образами CPEs, гарантирует пропускную способность и является рекомендованной для использования в составе SD-WAN Kaspersky. Образы естественно установлены с завода.
Конечно же CPEs могут быть развёрнуты как VMs на платформе виртуализации. Поддерживаются платформы:
- KVM;
- VMware.
Лицензирование
Лицензируются пропускные способности CPEs.
Для поддержки uCPE, third-party VNFs нужны лицензии Advanced против обычных Standard.
Плюсы и минусы
Гибкость решения позволяет создавать самые эпические схемы развёртывания. При этом продукт очень молодой. Чем больше наворотов будет задействовано, тем с большим количеством недокументированных проблем неизбежно придётся столкнуться. Поддержка Касперского тут вряд ли поможет. Они сами ещё годами будут собирать, документировать и фиксить проблемы. Весьма вероятно, что если вы запользуете все фичи решения, то станете первопроходцем по отлову багов.
Лаборатория Касперского поможет в начальном развёртывании:
Дальше сами. А сами-то сможете? Решение сложное, не тетрис ни разу. Либо опять к спецам Касперского, но уже за отдельную денюжку, либо нанимать своих с подобным опытом. Кстати, уже есть сертификационный экзамен "Certified Professional: Kaspersky SD-WAN (004.2)", кому интересно.
Но характеристики решения хороши. Тут и 4 WAN на CPE, зеркалирование трафика, контроль ошибок. Впереди BI.ZONE однозначно. Есть своя линейка оборудования KESR. Крупных проектов внедрения пока не было. Да и мелкие проекты только-только разворачиваются.
Сравнительная таблица
| Параметр | BI.ZONE | Kaspersky |
|---|---|---|
| Management Plane | BCMP | REST |
| Control Plane | BCMP | OpenFlow |
| Data Plane | WireGuard | Geneve |
| Шифрование | ChaCha20 | ChaCha20 |
| Топология | Star | Star/Partial Mesh/Full Mesh |
| Туннели между споками | нет | да (для Региона) |
| WAN каналов на CPE | 2 | 4 |
| VRRP | пока не реализовано (только между CPEs) | да (с любым оборудованием) |
| Балансировка трафика | L3 по двум каналам | L2-L4 по двум и более каналам |
| BFD | нет (min задержка при отвале BGP 3 сек) | да |
| Зеркалирование трафика | нет | да |
| Коррекция ошибок | нет | FEC |
| Traffic Engineering | базовый | продвинутый |
| DIA | да | пока не реализовано |
| Переключение каналов | бесшовное | бесшовное |
| QoS | пока не реализовано | да |
| Оркестратор/Контроллер | All-in-One VM | All-in-One VM/раздельная установка |
| Multi-tenant | да | да |
| Разделение прав доступа в GUI | базовое | гранулированное |
| SSH сессия из GUI | нет | да |
| Отказоустойчивость Оркестратора/Контроллера | да | да (несколько схем отказоустойчивости) |
| ZTP | да | да |
| Отказоустойчивость CPE | нет | да |
| VNF | только проприетарные BI.ZONE | любые (несколько схем развёртывания) |
| DPI | пока не реализовано (VNF) | да (модуль в прошивке CPE, возможно использование стороннего DPI как VNF) |
| Сервисные цепочки VNFs | нет | да |
| Откат на рабочую конфигурацию | да | да |
| Железо | Собственная линейка оборудования (есть модели с LTE) | Собственная линейка оборудования (есть модели с LTE) |
SD-WAN Kaspersky 2.1/2.2
Лаборатория Касперского не стоит на месте и уже скоро версия 2.1. Что туда войдёт?
- Новое топовое устройство Модель 5;
- Поддержка OSPF. Протокол поддерживался и ранее, но теперь централизованная настройка и оркестрация;
- Шифрование трафика Zabbix;
- Реализованы некоторые сценарии, которых не было в версии 2.0.
Не так много, гораздо больше в анонсированной версии 2.2:
SASE
Но и это ещё не всё, а если вы позвоните в течение первых пяти минут после эфира.. в Касперском смотрят вдаль. SD-WAN решение сетевое, к нему так или иначе нужно прикручивать решения по безопасности. Не одно, много. А почему бы не сделать на базе SD-WAN единое решение по безопасности? Называется такое SASE, Secure Access Service Edge.
В Касперском как раз занимаются разработкой решений по безопасности (какая удача).
Если у них получится (сделать быстро и безглючно), это будет ультимативное решение. CISCO прогнётся и заплачет. Когда? Обещают в конце 2024.
Далее SASE с другими решениями по безопасности интегрируется в единую концепцию XDR, Extended Detection and Response.
BI.ZONE vs Kaspersky
Некоторый функционал оба решения предлагают одинаково. Например, развёртывание Оркестратора/Контроллера в облаке или On-premises. Однако отличий куда больше и пора сделать заключительные выводы о роли/нише каждого из решений.
BI.ZONE
Сказал бы что SD-WAN BI.ZONE — классический SD-WAN. Простой как кирпич, но негибкий. Задачу свою выполняет, не более того. Подойдёт тем, кому нужно как раз попроще, без излишеств и сложных наворотов. Поставил, настроил, работает. С относительно небольшими трудозатратами. После развёртывания не требуется каких-то ультра-спецов для поддержки (управится и домохозяйка).
Только 2 WAN канала на устройство. Нет VRRP, BFD и много чего ещё нужного. Одна единственная VNF. Нет движка DPI, зеркалирования трафика, коррекции ошибок для передаваемых данных. Характеристики самого SD-WAN приемлемые, но не какие-то суперские. SD-WAN без эффекта "Вау!".
Kaspersky
Напротив, SD-WAN Kaspersky 2.0 крайне гибкое, как уже говорил, решение (даже избыточно). Назвал бы его гибрид.
Моделируй что угодно, одежду, снаряжение, любые ситуации. Что хочешь, то и получишь..
С моей точки зрения может выступать как:
- Классический L3 SD-WAN;
Замена и конкурент Бизона в первую очередь. Но также и остальных решений SD-WAN. Cо множеством плюшек и наворотов по желанию заказчика. У Бизона таких возможностей нету, здесь же всё решает желание и толщина кошелька.
- L2 SD-WAN;
Самое первое что приходит в голову, растягивание VLANs между удалёнными локациями.
- Отказоустойчивый SD-WAN;
С зеркалированием по каналам. Или с коррекцией ошибок. Подойдёт отлично например для банкоматов, для секретно-охранных-правительственных-VIP-систем.
- SD-WAN "
для бедных"для жадно-богато-экономных;
Сетевое решение класса SD-WAN всегда дорого. Оно не может быть дешёвым. Однако за счёт фичи коррекции ошибок позволяет использовать опять же в ряде случаев относительно дешёвые интернет-каналы вместо дорогих каналов MPLS с гарантированным SLA.
- Гибридный SD-WAN;
Такой где в качестве оверлея и L2 транспорт для одних приложений, и L3 для других.
- Наконец, провайдерский SD-WAN (MSP, Managed Service Provider).
Такой, где будет использовано максимальное количество предлагаемых решением наворотов. А уже провайдер сдаёт готовое решение в аренду клиентам. Тут есть момент. Поскольку Касперский под санкциями, не все провайдеры (а ведь на нашем рынке работают и иностранные) смогут его разворачивать.
Заключение
Решения не взаимозаменяемы. Точнее Касперский может заменить BI.ZONE, а вот в обратную сторону никак не получится. Может не только заменить, но и предоставить вагон фич и возможностей, которых у BI.ZONE нет. В противовес продукт от Касперского избыточно сложен. Что выбрать? Здесь зависит от стоимости, которой не знаю. Кто же мне скажет? 🙂 Помимо стоимости самого продукта, есть ещё стоимость владения (куда входит поддержка и обслуживания). Надо понимать, что стоимость владения у SD-WAN Kaspersky гораздо выше.
В итоге каждое из двух решений имеет как преимущества, так и риски. Подойти к вопросу выбора необходимо самым тщательным образом. Всё просчитать и взвесить. Обязательно договориться о проведении пилотного проекта/теста. Вживую посмотреть и оценить. А в самом конце результаты поделить на объявленную вам стоимость.
Обе компании располагают собственной тестовой инсталляцией в облаке, по запросу (с радостью) развернут там тенант для вас. Пробуйте, смотрите.
Теперь почему агрессивный маркетинг Касперского хорошо. Такой подход подтолкнёт оба решения развиваться активнее. В выигрыше окажутся все. Сами компании и конечно мы — заказчики/конечные пользователи. По оценке лаборатории Касперского каждая четвертая компания в России уже использует технологию SD-WAN.
Приглашаю поделиться мнением в Tелеграм канал