SD-WAN BI.ZONE часть 1

Leave a Comment /

SD-WAN BI.ZONE часть 1 — в этой части обсудим общие вопросы, зачем нам эта технология, сравним с другими технологиями. Составим план развёртывания, подберём оборудование.

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

Защита межфилиальной сети

Повторим курс CCNA, повторим и расширим. В любой большой компании, да и в средних тоже, есть головной офис и есть филиалы. Упрощённая схема. На самом деле головных офисов может быть несколько: 3, 4, 8.. Несколько в этом регионе, несколько в том. А филиалы при этом разные. Допустим 50 филиалов. Из которых 20 средних и 30 совсем мелких.

При этом у совсем мелкого филиала только 1 ISP (далее использую аббревиатуру ISP для обозначения как провайдера, так и самой услуги интернета). У среднего 1-2 ISP. Скорость доступа везде разная, зависит от возможностей ISP и ценника. А у головных офисов 2 ISP + 2 MPLS (а под MPLS буду подразумевать MPLS VPN, скорее всего от тех же ISP). Как всё это хозяйство связать? Сначала теория.

VPN

Самый примитивный способ — набор VPN туннелей. Расскажу на примере Check Point (CP), на самом деле непринципиально. У CP есть отдельные Communities. Комьюнити охватывает несколько устройств (CP) и применяют на них единые (для этого комьюнити) настройки. Некоторые площадки связаны в VPN комьюнити по схеме звезда, другие по схеме меш. Одно устройство может участвовать сразу в нескольких комьюнити. Что там есть внутри, какие технологии?

  • В случае нескольких ISP/MPLS на GW можно выбирать через что желательнее строить туннель (Link Selection). При отвале переключаемся на менее приоритетный линк;
  • Есть подобие резервирования (MEP);
  • Есть автоматическое нарезание маршрутов (RIM).

Мощи моща технологий! 🙂 Пока работает как бы и хорошо.

А нужно ли туннелировать трафик внутри MPLS? Ведь для интернета это необходимо, иначе не будет связности. Через MPLS связность уже присутствует. Вообще-то нужно. Потому что только туннелирование даст возможность наложить сверху шифрование. Шифрование необходимо, так как трафик MPLS не защищается. Тем не менее, какой-то трафик может ходить через MPLS без туннелирования. Например трафик, управляющий теми же туннелями.

Чего тут нет при схеме с отдельными VPN туннелями? Нет какой-то внятного резервирования (MEP применим не во всех случаях). Нет реальной автоматизации, всё руками. Скорость линии доступа и её качество никак не учитывается. Если нужно переложить пакет из одного туннеля в другой, то его сначала нужно распаковать, а затем снова запаковать. Даже в случае MDS централизация довольно-таки условная, консолей много. Очень сложный траблшутинг. Здесь подробнее:

  • Потеря связности только до одной площадки через конкретного ISP;
  • Возможные проблемы c TCP (не устанавливаются сессии для приложений) когда туннель в одну сторону строится по одному каналу, а в обратную по другому;
  • Проблемы с ошибками в настройках шифрования, в VPN-доменах (человеческий фактор). И SA не поднимается;
  • Изощрённые проблемы с туннелями до оборудования не CP, особенно к VMware vShield Edge.

И дофига ещё всего, чего сейчас уже не припомню. Веселуха нон-стоп.

Нормальное такое обеспечение межфилиальной связи? Нет конечно. 🙂 Если офисов 2-3-4, ничего страшного. Но с ростом количества площадок количество туннелей растёт лавинообразно. Растёт количество сбоев, а значит даунтайм. Много ручной работы. Нужны спецы с хорошим опытом, которые ручками разруливают.

Сценарий (печальный) тут:

Не работает, будем чинить.

DMVPN

Компромиссный вариант, есть как плюсы, так и минусы. Сначала плюсы:

  • Технология бесплатная. Почти. У большинства компаний Border Routers (BRs) это CISCO, таков путь так сложилось исторически;
  • Отлично дружит с BGP;
  • Высокая отказоустойчивость, тот туннель упал, значит этот поднялся. По железкам тоже. Вопросов нет.

Теперь минусы:

  • "Листинг" (как любит говорить мой начальник) — это реально листинг. Километры настроек;
  • Настройки надо делать в консолях множества устройств. Ошибки недопустимы, но весьма возможны;
  • Можно привернуть политику на базе PfR (Performance Routing), листинг станет ещё просторнее;
  • При проблемах с каналами, не падении канала, а именно проблемы с качеством линии и отсутствии политики, требуется подстройка руками.

Самое главное тут, даже если есть политика для трафика, это достаточно простая, негибкая политика. Руками всё равно надо. Меньше чем в случае с отдельными VPN, но тоже надо. Мы оставили DMVPN в качестве резервного решения, на случай если SD-WAN не взлетит (или откажет) по каким-то причинам. Ну и некоторые отдельные туннели VPN обязательно остаются. Нечего не поделаешь.

Сценарий:

Как-то работает, уже неплохо.

SD-WAN

Качественно новое решение, шаг вперёд. Кто может себе позволить эту технологию, получает ранее недоступные преимущества.

Через 10 лет всё будет на SD-WAN либо на каком-то подобии SD-WAN.

Это как со смартфонами. Технология настолько превосходящая всё и вся, что захват рынка очевиден. Рассмотрим подробнее.

Основная фича Traffic Engineering (TE), в реальном времени отслеживается состояние каждого канала передачи данных. Затем принимается решение через какой канал связи направить поток данных. Тут есть различия в реализации, но смысл везде один и тот же, перманентное ощупывание каналов связи на предмет их качества. И формирование трафика на лету.

Вроде бы похоже на PfR? Похоже, да не совсем. Уровень и гибкость политики на порядок выше. Например, для CISCO есть Cloud OnRamp for SaaS. Глазами не видел, читал рекламные буклеты. SD-WAN сам найдёт оптимальный маршрут для трафика к облачным сервисам типа Office 365 от всех площадок. То есть SD-WAN выберет площадку, выберет ISP на ней и завернёт туда трафик Office 365. Для DMVPN ничего такого и рядом нет, так как это решение только для связи площадок между собой.

В идеальном случае при SD-WAN мы задействуем все имеющиеся каналы связи для передачи. А значит повышается общая пропускная способность. Не суммируется конечно по пропускной всех каналов, но значительно повышается в сравнении с одним туннелем, одним каналом передачи. И не надо руками дёргать рычаги, всё перестраивается само, автоматика, пулемётика.

Самое приятное, у нас есть единая WEB-консоль управления контроллером, где мы производим все настройки и смотрим логи. Нам не надо ходить персонально к каждому устройству и лабать что-то там в его консоли через SSH. GUI рулит.

А у CISCO вдобавок необязательный vAnalytics. Не видел его в работе, возможно циска перехваливает. Умеет сам писать письма ISP о неполадках на его канале. Плюсом подсказывать что/где подкрутить надо, такое мы уже наблюдали в других продуктах CISCO (APIC/DNA Center). Расширенная аналитика по каналам и трафику присутствует.

Сам контроллер может быть как облачным, так и on premise или же на мощностях ISP. Это вкратце, далее подробнее.

Сценарий:

Не просто работает, а работает красиво.

SD-WAN vs DMVPN

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

SD-WAN CISCO

CISCO компания с громадным опытом, с технологической базой, патентами и лучшими спецами. Смотрит вдаль. Смотрела, смотрела, да и прикупила "тёмную лошадку" Viptela. А затем доработала имеющиеся там технологии. Получился законченный и передовой продукт. Для нас он, к сожалению, недоступен.

Кроме CISCO свой SD-WAN предлагает с десяток ведущих зарубежных компаний. При ближайшем рассмотрении оказалось, что либо эти решения недоступны, либо не подходят под наши требования.

Ну и ладно. Сможем мы порвать циску (как Тузик грелку)? Возможно, попробуем. И тут на сцену выходит BI.ZONE SD-WAN. Ради которого эта статья и пишется.

BI.ZONE SD-WAN

Отечественный, "православный" продукт. Стремительно развивается. Начинаю нахваливать. Что под капотом?

SD-WAN BI.ZONE
Технологии
  • Первое отличие от всяких цисок это то, что туннели не IPsec. Как? Вот так, продвинутый WireGuard, модифицированный, с возможностью шифрования по ГОСТ (здесь картинка с аплодирующим стоя пленумом компартии);
  • У CISCO vManage NMS (Network Management System), vSmart controller, vBond orchestrator. Всё это отдельные сущности, разные VMs (точнее vBond может быть и железным). У Бизона All-in-One контроллер в виде одной VM. Насколько это хорошо (или плохо) мне сложно сказать. Наверное для крутого гео-масштабирования плохо. Зато точно упрощает структуру;
  • Для выполнения настроек используется собственный двунаправленный протокол BCMP (BI.ZONE CPE Management Protocol). Он бинарный + атомарный, то есть на железку передаётся конкретное изменение, а не вся конфа целиком. Значит экономит пропускную полосу. Поддерживает логирование и версифицирование.
SD-WAN BI.ZONE

Обновление настроек закончилось ошибкой? Будет прозрачный откат на предыдущие настройки (версию). Круто? Круто.

  • Обработка трафика производится локально на CPE и не требует какого-либо обращения к контроллеру. Решение о переключении трафика принимает CPE. Первоначальные настройки вносятся при ZTP (о ZTP ниже). Далее мы пушим с контроллера изменения. CPE их сжирает и работает автономно. Контроллер мониторит состояние каждого CPE, а CPE качество каналов и дирижирует прохождением трафика. Полностью автоматически;
  • В качестве OS для WEB-консоли (контроллера) by design предлагается Ubuntu 20.04 (э-м-мм..). Есть возможность заменить на Альт Линукс 8 СП или Астра Линукс 1.7;
  • DIA (Direct Internet Access) с отказоустойчивостью в случае 2 ISP. На каждом CPE выход в интернет из LAN реализован сразу и не требует начальной настройки;
  • Поддержка технологии VRF для WAN каналов есть. Для LAN в настоящий момент не поддерживается, но запланирована на середину 2024 года.
Функциональность
  • Заточка под ISP. Один SD-WAN (контроллер) можно поделить на несколько проектов. Со своими администраторами и устройствами (multitenant). Проекты друг для друга при этом не видны. Пров может прикупить такой контроллер и далее продавать его мощности как услугу конечным потребителям.
SD-WAN BI.ZONE

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

  • Zero-Touch Provisioning (ZTP). Oй кто это, ой что это? Допустим, мы залили в железку прошивку с нужными сертификатами (обязательное условие). Напомню, сертификаты нужны для аутентификации, не для шифрования. Пока непонятно кто будет заливать, возможно устройства сразу будет приходить прошитыми под проект (так и оказалось, всё CPEs приходят с уже вшитыми сертификатами). Далее отправляем железку по месту.

А в WEB-консоли создаём новое устройство, вбиваем нужные настройки для этого устройства и по результату генерим ссылку. Шлём ссылку по электронной почте. По приходу оборудования нужно воткнуть в него ноутбук. Открыть на ноутбуке браузер, открыть в браузере ссылку. Всё.

Самая большая проблема теперь воткнуть в железку правильный провод от провайдера и правильный провод из внутренней сети. Только втыкать (как оказалось) нужно быстро, есть тайм-аут в несколько минут. Железка подцепится к управлению, установит шифрованный канал. Шифронабор генерируется автоматически для каждой площадки контроллером. Оценили?

  • Лицензирование состоит из двух частей. На контроллер заливается лицензия, которая определяет доступное к использованию количество CPE. На CPE загружается лицензия по полосе пропускания.
  • Не разбирался с RA (Remote Access) и непонятно насколько это будет востребовано именно к устройствам SD-WAN.
Hub&Spoke

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

Важное, туннели между споками при этом не строятся. Трафик всегда идёт через хаб. Это не баг, это фича, архитектурное решение на текущей момент. Понятно что в результате какой-то хаб может стать узким местом. Обещают туннели между споками, в версии 1.6 в 2024 году.

При этом количество хабов не лимитировано. Кроме этого есть иерархия. Группа хабов и споков может быть выделена в регион. Тогда хабы региона приоритетны перед всеми другими хабами, при отправке трафика споками этого региона. Подробнее в следующих частях.

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

BI.ZONE TE

Мы можем настраивать не только QoS, в плане что этот трафик впереди того. А и задать для класса трафика качество канала. Допустим, мы хотим чтобы вот этот трафик ходил только через канал, у которого параметры (задержка, потери, джиттер) не хуже, чем мы определили. Очень гибко можно выбрать трафик: по IP, порту либо DSCP. И планируется ещё на базе библиотек движка DPI, после внедрения VNF DPI в начале 2024. Всего 8 пресетов, должно хватить.

Канал будет выбран, конечно же при наличии канала с заданными параметрами. А значит, как минимум нужен предварительный тест всех каналов (безотносительно SD-WAN). И по результату правильные настройки параметров канала для приложения/класса трафика. Итак, канал выбран, уже внутри канала QoS. Круто? Ваще огонь.

VNFs

Каждая отдельная дополнительная функция в CPE реализована в виде VNF (Virtual Network Function). Эти VNFs отделены от основного функционала (контейнеры). Поэтому добавление новых VNFs (с их выходом) должно быть прозрачным.

Пока единственной VNF является FW. Обычный stateful FW. Доверенная сеть LAN, трафик из неё пропускается. Трафик из других локаций инспектируется.

Планируется следующий порядок выхода VNF: сначала IDS (по факту уже код внедрен c версии 1.3.1), затем его заменит IPS и наконец дополнительно DPI. Возможно ещё что-то.

Логирование

Есть визуализация (stages) для работы BCMP протокола. То есть в WEB-консоли видны статусы операций применения настроек в реальном времени. Они как бы "бегут" в правой части экрана.

В WEB-консоли есть отдельные страницы по траблшутингу BGP, arp, RIB. Есть визуализация по срабатыванию правил FW, есть аудит действий админов, есть визуализация работы Nettracker (маршрутная информация).

Логи с контроллера возможно отправлять на Syslog-сервер (с версии 1.5.1).

Оборудование

Что там с оборудованием? Широка страна моя родная линейка от Бизона. Большинство моделей на x86-64, есть вариант с VMs. Изначально был и пиарился CyberEdge 110, он везде, на всех картинках. Устройство в разрезе "малый офис". Теперь всё гораздо лучше, а устройств гораздо больше:

SD-WAN BI.ZONE часть 1

Недостатки версии 1.3

Текущая версия прошивки 1.3.1. Не так всё прекрасно, начинаю накидывать "дёгтя в бочку":

  • Только 2 WAN канала на устройство, поэтому устройства на центровых площадках придётся ставить парами. Не для отказоустойчивости, а чтобы просто покрыть имеющиеся каналы связи. И через BGP разруливать трафик к ним. В далёком счастливом будущем обещается 4 WAN канала на CPE (не ранее 2024 года).

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

  • Нет VRRP-кластера. Ожидается в версии 1.4 (по факту в этой версии его не оказалось, нет и в 1.5.1).
  • Также нет настроек QoS для отдельного канала. Обещается в будущем реализация маркировки Forwarding Equivalence Classes (FEC) на базе специальных меток и очередей (Queueing).

То есть выбор канала по параметрам для класса трафика присутствует. При этом внутри самого канала трафик не приоритизируется. Есть в роадмапе решения, конец 2023 — середина 2024 года соответственно.

  • Контроллер может быть собран в виде отказоустойчивого кластера только в 1.4. Геораспределение присутствует, требование для корректной работы чтобы задержка между нодами кластера была менее 100мс.
  • FW такой, что без слёз не взглянешь. Набор примитивов для галочки. IPS и прочее планируется, но есть сомнения что железки младших моделей смогут вытянуть. Сомнения обоснованные. Всё это мы уже проходили на базе коробков 1400/1500 серий от CP.

Rollback изменений внесённых на FW CPE есть уже сейчас. Но правила FW нужно настраивать на каждом CPE отдельно. Центральное раскатывание планируется, когда неизвестно (шаблоны для FW были добавлены в 1.4).

У CISCO в этом плане получше. Гораздо. И если старые vEdge ничего такого не умеют (кроме голого FW), то для новых cEdge: Cisco AMP and AMP Threat Grid, URL filtering, The Snort intrusion prevention system (IPS).

Тут надо ещё добавить что выход 1.4 тоже "ожидается". Он был обещан ещё в конце 2022 года. Окончательно обещается апрель 2023 года.

Вопросы развёртывания

Самый первый вопрос: где приземлить контроллер? Выбрали вариант у себя, не в облаке. На одной из центровых площадок. Контроллер имеет внешний (публичный) адрес, мы его располагаем в DMZ и защищаем с помощью СЗИ от постороннего доступа.

Тут придётся помудрить с маршрутизацией, чтобы контроллер по своему адресу был доступен для CPEs через все каналы связи интернет+MPLS. Ведь у некоторых CPEs вообще не будет интернет каналов, только MPLS.

Ubuntu естественно заменяем. Там где возможно и где есть несколько линий связи настраиваем оборудование как хаб. На совсем маленьких площадках как спок. После выхода 1.4 посмотрим насколько затратно и целесообразно делать контроллер отказоустойчивым.

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

Оборудование надо предварительно заказывать. И даже уши крепления в стойку для некоторых моделей CPE надо заказывать отдельно. 🙂

План развёртывания

Сам план довольно-таки простой:

  • Определяем расположение хабов и контроллера;
  • Развёртываем контроллер;
  • Настраиваем маршрутизацию (на время теста SD-WAN отделён от продовой среды);
  • По мере поступления оборудования онбордим CPE площадки на SD-WAN контроллер;
  • После подключения каждого нового CPE проводим тесты: нагрузочное тестирование, эмуляция отказоустойчивости, эмуляция "ухудшения" канала;
  • Параллельно пилим политику. Сразу после ввода контроллера. Шаманим её, настраиваем, смотрим в результаты тестов, ещё шаманим. Неспешное, задумчивое занятие;
  • Когда все площадки будут подключены, проводим финальный тест;
  • Переводим в продакшен.

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

Пока это всё. Следующие части тоже уже планирую (потирает руки). Если где-то немного наврал, инфу ну очень трудно доставать, приношу извинения. Ещё раз сводно реклама плюсы SD-WAN BI.ZONE:

Приглашаю поделиться мнением в Tелеграм канал

Leave a Comment

Scroll to Top