Результат интеллектуальной деятельности: СПОСОБ ДИНАМИЧЕСКОГО КОНТРОЛЯ СООТВЕТСТВИЯ НАСТРОЕК КОММУТАЦИОННЫХ УСТРОЙСТВ ПРОГРАММНО-КОНФИГУРИРУЕМОЙ СЕТИ ТРЕБОВАНИЯМ ПОЛИТИК МАРШРУТИЗАЦИИ

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

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

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

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 '10). - Chicago, Illinois, USA, 2010. - Pp. 37-44].

AntEater [Mai H., Khurshid Α., Agarwal R., Caesar M., Godfrey P.В., King S.T. Debugging the Data Plane with Anteater // Proceedings of the ACM SIGCOMM 2011 Conference, (SIGCOMM '11). - 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 Α., Zhou W., Caesar M., Godfrey P.B. VeriFlow: Verifying Network-wide Invariants in Real Time // Proceedings of the First Workshop on Hot Topics in Software Defined Networks, (HotSDN '12). - 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 на конференции NSDI '13.

Наиболее близким к заявляемому техническому решению является подход к верификации сети, реализованный средством VeriFlow. Также как и средство NetPlumber средство VerifFlow ориентировано, в первую очередь, на использование в среде ПКС. Однако в качестве приоритетного способа интеграции своего средства в инфраструктуру сети авторы VeriFlow выбрали использование прокси-сервера [исходные коды соответствующей программной реализации могут быть получены после заполнения формы по адресу http://web.engr.illinois.edu/~khurshi1/projects/veriflow/veriflow-code-release.php].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Полученные таким образом формальные модели проверяются на соответствие предъявляемым к сети требованиям с помощью модуля верификации;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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