КОММУТАЦИОННЫХ УСТРОЙСТВ

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

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

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

FlowChecker [Al-Shaer Е., Al-Haj S. FlowChecker: Configuration Analysis and Verification of Federated Openflow Infrastructures // Proceedings of the 3rd ACM Workshop on Assurable and Usable Security Configuration, (SafeConfig Ί0).— Chicago, Illinois, USA, 2010.— Pp. 37-44]. AntEater [Mai H., Khurshid A., Agarwal R., Caesar M., Godfrey P. В., King S. T. Debugging the Data Plane with Anteater // Proceedings of the ACM SIGCOMM 2011 Conference, (SIGCOMM Ί 1).— Toronto, Ontario, Canada, 2011.— Pp. 290-301].

Hassel [Kazemian P., Varghese G., McKeown N. Header Space Analysis: Static Checking For Networks // Presented as part of the 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI 12).— San Jose, CA, USA, 2012.— Pp. 113-126].

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

Однако ни одно из перечисленных средств не рассматривает задачу сбора информации об актуальной конфигурации сети. Все они предполагают, что указанная информация формируется с помощью внешних инструментов. Таким образом, диапазон задач, которые могут быть решены с помощью указанных средств, сводится к однократной проверки заданной статической конфигурации. Задача проверки конфигурации сети в динамике её работы здесь не рассматривается. Из уровня техники известны и более продвинутые средства верификации сети, которые ориентированные, в первую очередь, на динамический анализ конфигураций:

Veriflow [Khurshid A., Zhou W., Caesar M., Godfrey P. В. VeriFlow: Verifying Network-wide Invariants in Real Time // Proceedings of the First Workshop on Hot Topics in Software Defined Networks, (HotSDN Ί2). — Helsinki, Finland, 2012.— Pp. 49-54].

NetPlumber [Kazemian P., Chang M., Zeng H., Varghese G., McKeown N., Whyte S. Real Time Network Policy Checking Using Header Space Analysis // Presented as part of the 10th USENIX Symposium on Networked Systems Design and Implementation, (NSDI' 13).— Lombard, IL, USA, 2013.— Pp. 99-111].

Atomic Predicate (AP) Verifier [Yang H., Lam S. Real-Time Verification of Network Properties Using Atomic Predicates // IEEE/ACM Transactions on Networking.— 2015.— Vol. PP, no. 99.— Pp. 1-14].

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

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

Инструментарий средства АР Verifier ограничивается множеством модулей анализа, осуществляющих проверку состояния сети на соответствие некоторым классам свойств, и собственно верификатором, обеспечивающим необходимый для этого программный интерфейс. Таким образом, данное средство е предлагает какого-либо конкретного механизма получения информации ни об изначальной конфигурации сети, ни о вносимых в неё модификациях.

Средство NetPlumber построено на тех же принципах, что и средство Hassel, однако предназначено, в первую очередь, для динамической верификации особого класса компьютерных сетей - Программно- Конфигурируемых Сетей (ПКС) - в режиме реального времени. Отличительными чертами ПКС являются:

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

• Логическая централизация контура управления в единой точке - контроллере,

• Унификация интерфейса взаимодействия между контуроллером и контуром передачи данных. Перечисленные особенности ИКС упрощают процесс контроля за теми модификациями, которые вносятся контроллером в настройки подключённых к нему коммутационных устройств. Авторы средства NetPlumber рассматривают два варианта интеграции данного средства в ПКС:

1. В виде специального программного модуля, встроенного непосредственно в контроллер, и перехватывающего команды других модулей при их отправке на контур передачи данных. Этот подход и реализован в программном коде средства NetPlumber [https ://bitbucket. org/peymank/hassel-public/] .

2. В виде прокси-сервера находящегося между контроллером и коммутационными устройствами и перехватывающего команды для устройств уже после того, как они покинули контроллер. Этот подход лишь упоминается в научной статье, представляющей NetPlumber на конференции NSDF 13.

Наиболее близким к заявляемому техническому решению является подход к верификации сети, реализованный средством VeriFlow. Так же как и средство NetPlumber, средство VerifFlow ориентировано, в первую очередь, на использование в среде ПКС. Однако в качестве приоритетного способа интеграции своего средства в инфраструктуру сети авторы VeriFlow выбрали использование прокси-сервера [исходные коды соответствующей программной реализации могут быть получены после заполения формы по адресу http://web.engmllinois.ed^

release.php].

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

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

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

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

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

• Прокси-сервер, перехватывающий команды, передающиеся от контроллера на подключённые к нему коммутаторы ПКС, и сообщения, передающиеся в обратном направлении;

• Модуль разведки конфигурации собирает информацию о конфигурации сети, выполняя анализ потока сообщений между контроллером и коммутаторами или же запрашивая необходимые данные непосредственно у коммутаторов;

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

• Корректировщик моделей, отвечающий за вычисление обновлённой модели сети, которая получается из конфигурации ПКС в результате применения к ней заданного набора команд контроллера; • Верификатор, который отвечает за проверку формальных моделей ГЖС, построенных с помощью модуля конструктора, на соответствие формулам языка спецификации, описывающим требования к сети.

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

• Сообщения, направляемые контроллером на находящиеся в его подчинении коммутаторы, передаются через прокси-сервер, выполняющий первичный анализ их содержимого;

• Прокси-сервер задерживает такие команды контроллера, которые предписывают коммутаторам изменить своё поведение (например, удалить, модифицировать или добавить новые правила по обслуживанию пакетов), направляя их копии корректировщику моделей;

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

• Полученные таким образом формальные модели проверяются на соответствие предъявляемым к сети требованиям с помощью модуля верификации; • Верификатор помечает команду контроллера как безопасную лишь в том случае, если модель удовлетворяет каждому из требований политик маршрутизации. В противном случае команда считается небезопасной;

• Прокси-сервер получает от верификатора результаты проверки переданных ему команд контроллера и передаёт безопасные команды контроллера на коммутаторы;

• Если верификатор обнаружил небезопасную команду, которая может привести к нарушению требований политик маршрутизации и некорректному поведению сети, прокси-сервер осуществляет её блокировку: команда контроллера сбрасывается, а сам контроллер уведомляется о некорректности направленной им команды.

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

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

Для реализации предложенного способа динамического контроля соответствия настроек коммутационных устройств программно- конфигурируемой сети требованиям политик маршрутизации необходимо интегрировать модуль прокси-сервера в управляющую сеть, таким образом, чтобы он имел возможность поддерживать связь с её коммутаторами и контроллером:

• При первичной настройке прокси-сервера администратор указывает сетевые адреса для подключения к контроллеру, а так же диапазон адресов, через которые прокси-серверу следует ожидать подключения от коммутаторов;

• Каждый из коммутаторов перенастраивается таким образом, чтобы при включении они пытались подключиться к контроллеру ПКС не по тем адресам, на которых подключения ожидает контроллер, а по тем, которые были назначены прокси-серверу;

• При возникновении нового соединения с коммутатором прокси- сервер открывает новое соединение с контроллером и замыкает эти соединения друг с другом: те сообщения, которые поступают через соединение со стороны коммутатора направляются на соединение со стороны контроллера и наоборот, те сообщения, которые поступают от контроллера направляются на коммутатор.

При поступлении сообщений контроллера прокси-сервер выполняет их первичный анализ, соотнося их с одним из следующих классов:

• Команды - разнообразные сообщения, обработка которых приводит к изменению конфигурации ПКС. Примерами таких сообщений можно считать, в частности, добавление или удаление правил по обработке пакетов или инструкции по отключению отдельных портов устройства;

Запросы - сообщения, в ответ на которые коммутаторы возвращают информацию о своём состоянии, например, действующих портах или статистике по количеству пакетов, обработанных отдельными правилами;

• Служебные - все прочие сообщения, например, keep-alive сообщения, которые позволяют контроллеру ПКС время от времени убеждаться в работоспособности подключённых к нему коммутаторов.

Обработка различных классов сообщений контроллера осуществляется по-разному, в зависимости от текущего режима работы прокси-сервера:

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

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

• В режиме зеркалирования прокси-сервер направляет на верификацию копии команд контроллера. Однако прокси-сервер передаёт на коммутаторы все сообщения контроллера, вне зависимости от их типа, не дожидаясь результатов проверки верификатора. Такой режим удобно использовать, например, в тех сетях, конфигурация которых слишком сложна для быстрой проверки в режиме реального времени. Хотя зеркалирование и не позволяет предупредить возникновение небезопасных конфигураций, оно позволяет определить сам факт нарушения требований.

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

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

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

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

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