12
разработчиками. Технология NFV позволяет интегрировать в управлении
программной конфигурацией корпоративных сетей унифицированное
оборудование, имеющее различную функциональность [8, c.92].
Особенностью такой интеграции является то, что технология NFV
предусматривает полную замену сетевого оборудования на
унифицированные сервера, а программно-конфигурируемые сети
позволяют в централизованном режиме управлять сетевым оборудованием
и программным обеспечением.
В соответствии со спецификацией протокола OpenFlow структура
связей между компонентами программно-конфигурируемых сетей может
быть представлена в виде рисунка 3.
Рисунок 3 – Интеграция программно-конфигурируемых сетей и
технологии NFV
Рассмотрим компоненты, используемые в этой системе управления
конфигурацией корпоративных сетей. В этом случае применяется
OpenFlow коммутатор для программирования конфигурации сети. Он
представлен в виде внутренней программы, позволяющей обрабатывать
пакеты с последующим распределением по сегментам корпоративной сети.
Также в системе управления конфигурацией корпоративных сетей
применяется OpenFlow-контроллер, выступающий сервисом для
13
управления логическим коммутатором. С его помощью производится
обработка операций полученных с логического коммутатора.
OpenFlow-ресурс является физическим ресурсом логического
коммутатора, привязанного к логическому коммутатору следующими
ресурсами [3, c.125]:
- портом коммутатора, на который поступают пакеты и
перенаправляются по корпоративной сети;
- очередью пакетов (QE) до момента обработки.
Связи между компонентами системы управления конфигурацией
корпоративных сетей приведены на рисунке 4.
Рисунок 4 – Связи между компонентами системы управления
конфигурацией корпоративных сетей
Как видно из рисунка 4 в этом случае применяется протокол
OpenFlow, позволяющий организовать взаимодействие между
контроллером OpenFlow и логическим коммутатором. Протокол OpenFlow
config позволяет управлять OpenFlow-коммутатором и реализовать
управление физическим устройством.
14
При интеграции с облачными технологиями важную роль
выполняют OpenFlow-контроллер и OpenFlow-коммутатор. Эти два
устройства создают программный интерфейс, позволяющий управлять
корпоративной сетью в облачной сети через конфигурирование
контролера.
При интеграции с облачными технологиями необходимо учитывать
следующие ограничения [10, c.152]:
- операции должны выполняться в удаленном режиме через панель
управления и программный интерфейс;
- каждая из операций управления конфигурацией компьютерной сети
должна быть изолирована от инфраструктуры пользователей.
Для создания интерфейса удаленного управления конфигурацией
корпоративной сети можно использовать протокол SOAP, позволяющий
организовать обмен информацией в децентрализованной среде. Для
определения механизма обмена сообщениями протокол SOAP
интегрируется XML технологиями.
Альтернативой выступает технология REST, представляющая собой
механизм создания программных средств для отправки запроса различным
облачным службам.
Для управления программной конфигурацией корпоративной сетью
в облачной инфраструктуре производятся операции по добавлению,
удалению и переносу вычислительной машины, задаются правила
маршрутизации пакетов сети и уточняется информация о состоянии
выполненных операций.
15
1.2 Методы обеспечения безопасности, верификации в
управлении программной конфигурацией корпоративных сетей
Программно-конфигурируемые сети являются современной
технологией для управления конфигурацией компьютерных сетей.
Программное управление компьютерной сетью позволяет реализовать
новые сетевые приложения, имеющие механизмы верификации и
корректности со стороны безопасности.
Рассмотрим модель безопасности программно-конфигурируемых
сетей, основанных на протоколе OpenFlow. Эта модель включает в свой
состав генерирующий трафик, конечные узлы и промежуточные узлы,
выполняющие маршрутизацию. В состав конечных узлов входят
запущенные процессы с виртуальных портов транспортного узла, а также
OpenFlow коммутаторы [17, c.112].
В такой модели передача данных производится внутри сегмента сети
с необходимым уровнем безопасности. В данном случае в корпоративной
сети выделяется управляющий узел или контроллер, который
обеспечивается безопасными каналами связи, взаимодействующими со
всеми коммутаторами. Контроллер выполняет функции динамического
обновления данных в соответствии с топологией сети. Используя эту
информацию, им генерируются и передаются команды от каждого
коммутатора.
В своей работе коммутатором применяется одна или несколько
таблиц потоков, которые формируются на основании полученных от
контролера команд. При помощи этих таблиц производятся
перенаправление и обработка пакетов. Контроллером отправляется набор
команд для коммутатора в ответ на события, которые произошли в сети.
В состав каждой записи входят логические условия «match fields»,
инструкции «action» и счетчики. Логические условия «match fields»
16
создают ограничения к заголовкам пакетов, в том числе TCP-заголовкам,
IP-заголовкам.
Когда находящийся в обработке пакет удовлетворяет логическим
условиям «match fields», тогда для него производится выполнение
инструкций из списка команд Delete, Output, Drop и Set. Если пакет не
входит ни в одну из таблиц потоков, то производится его передача на
контроллер.
Для определения семантики безопасности контроллер формирует
упорядоченный набор записей. При этом формируются различные правила
для установления уровня безопасности [14, c.65].
На каждом уровне безопасности выбираются конечные узлы,
представленные в виде пользовательских процессов. Каждый конечный
узел определяется соответствующим уровнем безопасности, который
известен только контроллеру.
Поскольку в программно-коммутируемых сетях трафик
перенаправляется в соответствии с таблицами потоков, то для многих из
них можно определить уровень безопасности. Для формирования правил
задания типов используется предикат forall, с помощью которого
определяются свойства уровней безопасности по формулам 3 и 4:
,
:),... ,(
:,... ,:
1
1
lowppforall
lowplowp
n
n
(3)
.
:),...,(
:,...,:
1
1
highppforall
highphighp
n
n
(4)
Таким образом, для типизации подсети в соответствии с уровнем
безопасности определяются жёстко разграниченные потоки правил.
17
На следующем этапе формируется множество
S
правил, которые
соответствуют Политике безопасности. При этом в это множество
добавляются события, позволяющие определить тип безопасности.
Для создания Политики безопасности корпоративной сети для
каждого вида информационного потока формируется набор безопасности
событий. Например, для каждой абстрактной команды существует
возможность определения политики безопасности с использованием
следующей формулы:
.
:))((:))((
actionmatchC
tmatchdstforalltmatchsrcforall
dstsrc
(5)
Если рассматривать эти правила в более детально, то можно
сформировать дерево решений для построения системы управления
корпоративной сетью. Совокупность правил из полученного подмножества
представлена в виде формальной системы безопасности, позволяющей
делать выводы о нарушении политики безопасности.
1.3 Применение аппарата и Е-сетей для решения задач анализа
и верификации программно-конфигурируемых сетей
Управление программной конфигурацией корпоративных сетей
упрощает процесс конфигурирования компьютерной сети за счет ее
разделения на уровни передачи данных и управления [16, c.134].
Протокол OpenFlow учитывает требования, предъявляемые к сетевой
инфраструктуре и установленным в корпоративной сети сервисам. Он не
имеет конечной реализации и предусматривает применение различных
спецификаций.
18
В настоящее время существует модель распределенной сети, в
которой описываются свойства и принципы маршрутизации пакетов,
основанных на двоичных разрешающих диаграммах.
Рассмотрим основные требования, предъявляемые к системе
управления программной конфигурацией корпоративных сетей и
протоколу OpenFlow, гарантирующего ее корректную работу [4, c.15].
Протокол OpenFlow является новым стандартам, позволяющим
обмениваться данными на уровне корпоративных сетей. В его состав
входят правила управления пакетами и таблица переадресации.
В управлении программной конфигурацией корпоративных сетей
применяются SDN-контроллеры, реализующие методы доставки,
обработки данных по маршрутам внутри корпоративной сети. Они
существенно повышают скорость процессов обработки и передачи данных,
сокращают вероятность возникновения ошибок в программной
конфигурации, которые могут привести к некорректной работе
корпоративной сети.
При управлении программной конфигурацией корпоративных сетей
могут возникнуть логические ошибки из-за не правильного
проектирования сетей. Для исправления этих ошибок производиться
верификация готовых решений.
В этом случае рекомендуется выделить подмножество
Р
процессов,
определённых в спецификации протокола OpenFlow и позволяющих
организовать взаимодействие между элементами системы управления
программной конфигурацией. Поскольку SDN-сети отличаются
динамическим характером, то каждый из ее элементов должен
соответствовать индивидуальному набору процессов, принадлежащих
определённому множеству [11, c.10].
19
Логическая система для организации взаимодействия между
элементами протокола OpenFlow позволяет проверить протокол на каждом
шаге и определить соответствие его работы требованиям.
Совокупность требований можно представить в виде функции
следующего вида:
,,,,,
.мод
SDN
спец
SDN
PSfPSf
(6)
где
спец
SDN
PSf ,,
- подмножество состояний протокола OpenFlow,
отражающего взаимосвязь между требованиями одной из версий
спецификации;
.
,,
мод
SDN
PSf
- множество, позволяющее установить взаимосвязь
между моделями реализации протокола OpenFlow.
Формально, проверка спецификации на непротиворечивость может
быть представлена в виде следующей функции:
,,,,,
.мод
SDN
спец
SDN
PSfPSf
(7)
где
спец
SDN
PSf
,,
- множество, определяющее взаимосвязь между
состояниями элементов, соответствующих требованиям спецификации
протокола OpenFlow;
.
,,
мод
SDN
PSf
- множество, определяющее взаимосвязь между
состоянием элементов протокола и последовательность их замены.
Рассмотрим возможность применения Е-сетей для формального
представления и анализа процессов протокола OpenFlow.
Аппарат Е-сетей можно использовать для описания системы
управления программной конфигурацией корпоративных сетей на
различных уровнях абстракции, то есть на уровне изменения таблиц
20
маршрутизации, организации взаимодействия с OpenFlow-контроллером, а
также для анализа правил коммутации [7, c.56].
В рамках поставленных задач рассмотрим модель Е-сети,
позволяющую организовать обмен управляющими сообщениями между
контроллером и коммутатором.
Состояние «Switch Learning» применяется для идентификации
сообщений, поступающих на порт коммутатора и для добавления новых
пользователей в корпоративную сеть. Для перенаправления полученных
пакетов применяется таблица переадресации. Если в ней обнаружены
совпадения, то коммутатор осуществляет пересылку пакетов адресату по
таблице переадресации.
Состояние «Change Command» применяется для передачи пакетов
напрямую адресату, используя инкапсуляции.
В этом случае после получения пакета данных OpenFlow-
коммутатором задается заголовок пакета и производится его пересылка
адресату [15, c.148].
Модель инициализации управляющего потока с применением
протокола OpenFlow приведена на рисунке 5.
21
Рисунок 5 – Модель процесса инициализации управляющих потоков, по
протоколу OpenFlow
В модели инициализации Е-сеть выполняет функции передачи
данных с одного устройства на другое. Управляемые переходы можно
применять для обучения OpenFlow-коммутатора.
В состав управляющего предиката входит информация, внесенная в
таблицу переадресации. Если в таблице переадресации не найдено данных,
то пакеты пересылаются на контроллер. Данный процесс включает
формирование предусловия, его обработку и передачу адресату. При этом
процесс обработки пакетов и их дальнейшая передача производится
методом инкапсуляции [6, c.83].
В соответствии с требованиями к протоколу OpenFlow каждая такая
логическая сеть разделяется по пропускной способности, топологиям и