[1]Область техники, к которой относится изобретение
[2]Предполагаемое изобретение относится к области сетевых технологий, программно-конфигурируемых сетей и криптографической защиты информации.
[4]Для защиты каналов связи между сетями или центрами обработки данных (ЦОД) используются средства шифрования сетевого трафика. При этом для обеспечения прохождения данных через сегменты глобальной открытой сети применяются шифраторы, работающие на сетевом (L3) уровне эталонной модели ISO/OSI и имеющие возможность выполнять маршрутизацию шифрованного трафика. Такие устройства обычно называют криптографическими маршрутизаторами или крип-томаршрутизаторами. Поскольку криптомаршрутизаторы теряют часть пропускной способности за счет необходимости шифрования и расшифрования трафика, то для увеличения пропускной способности канала связи и его отказоустойчивости применяют технологии масштабирования защищенных каналов связи.
[5]Также актуальной является задача создания защищенного соединения между сетями на канальном уровне (L2) эталонной модели ISO/OSI, что позволяет объединять несвязанные локальные сети в одну локальную сеть и обеспечивает свободное прохождение трафика канального уровня (ARP, LLDP и др.), миграцию хостов и др. Для этого используются протоколы туннелирования, такие как GRE и VXLAN.
[6]Известен метод балансировки нагрузки с использованием программно-конфигурируемых сетей, являющийся составной частью способа (патент РФ №2576488, приоритет от 17.02.2015 г.), согласно которому транзитная сеть, построенная на базе технологии программно-конфигурируемых сетей (ПКС), включает следующие основные компоненты: OpenFlow-коммутаторы (барьерные коммутаторы), серверы верификации приходящего извне сети трафика, контроллер ПКС, сервер аутентификации. Транзитная сеть является промежуточным звеном передачи пакетов между пользовательскими терминалами и защищаемыми серверами.
[7]Структура контроллера включает в себя следующие блоки: блок сбора статистики, блок управления присутствием, блок генерации правил маршрутизации, блок переопределения адресов, коммутационный блок. Балансировка нагрузки осуществляется на основании статистики загрузки, которая собирается блоком сбора статистики путем опроса барьерных коммутаторов и серверов верификации через равные заданные промежутки времени. Статистические данные, получаемые контроллером от барьерных коммутаторов, представляют собой значения счетчиков входящих пакетов, а от серверов верификации - общая загрузка процессора и расход оперативной памяти. На основании этих данных реализуются методы равномерного распределения нагрузки, блок генерации правил маршрутизации генерирует правила маршрутизации и пересылает их на барьерные коммутаторы. Блок управления присутствием отвечает за отслеживание появления новых коммутаторов и серверов верификации в транзитной сети и перевод в «спящий» режим простаивающих серверов верификации. Блок реализует стратегию максимального использования ресурсов, смысл которой заключается в уплотнении задач верификации пакетов на серверах верификации и выведения из процесса простаивающего оборудования. Решение о переводе в «спящий» режим производится на основании статистики, получаемой от блока сбора статистики. Блок переназначения адреса используется при инициализации сети и отвечает за отправку барьерным коммутаторам команд на изменение своего IP-адреса.
[8]Барьерные коммутаторы представляют собой управляемые коммутаторы, поддерживающие протокол OpenFlow 1.3, и включают следующие основные компоненты: репозиторий правил маршрутизации, блок управления пакетами, блок обработки команд от контроллера, блок переназначения адреса. Основная задача коммутаторов заключается в распределении входящих пакетов на сервера верификации на основании правил, содержащихся в репозиторий правил маршрутизации. Блок обработки команд является центральным в структуре коммутатора и предназначен для обработки управляющих команд от контроллера ПКС.
[9]Принцип работы транзитной сети заключается в следующем. Пользовательский терминал посылает сетевой пакет одному из барьерных коммутаторов. Пусть среди правил маршрутизации барьерного коммутатора отсутствует правило для обработки пакетов от данного пользовательского терминала. В результате, коммутатор отсылает заголовок пакета контроллеру. Сам пакет сохраняется на барьерном коммутаторе в ожидании управляющих команд от контроллера. Последний принимает пакет и, опираясь на статистику загрузки серверов верификации, генерирует правило маршрутизации, согласно которому все пакеты, приходящие от данного пользовательского терминала, будут перенаправляться соответствующему серверу верификации. Данное правило по каналу управления передается коммутатору. После этого сохраненные в кэше коммутатора пакеты потока отправляются выбранному серверу верификации. Далее выполняется анализ пакета на сервере верификации и, в случае его легитимности, дальнейшая маршрутизация пакета целевому защищаемому серверу. Обратный трафик от сервера возвращается пользовательскому терминалу по тому же самому маршруту.
[10]Описанный способ имеет следующие недостатки:
[11]- способ не может быть применен для создания защищенного L2-соединения между сетями. В частности, по причине отсутствия поддержки протоколов туннелирования GRE, VXLAN;
[12]- способ не может быть применен для криптошлюзов с разными ключевыми наборами и при необходимости отправить зашифрованный пакет на корректный криптошлюз для расшифрования.
[13]Известен также способ соединения нескольких ЦОД на уровне L2 при помощи защищенных высокопроизводительных каналов связи с использованием технологии L2OverIP (статья по адресу: https://www.anti-malware.ru/analytics/Technology_Analysis/ViPNet_Coordinator_HW).
[14]Технология построения защищенной сети L20verIP позволяет организовать защищенное обмен для распределенных локальных сетей, использующих единое адресное пространство на канальном уровне (L2) сетевой модели OSI. Технология поддерживает обмен данными любых протоколов сетевого уровня через зашифрованное IP-соединение. С помощью L2OverIP узлы из разных сетевых сегментов могут взаимодействовать друг с другом так, как будто они находятся в одном сегменте локальной сети с прямой видимостью по МАС-адресам.
[15]В схеме для агрегации каналов используется технология EtherChannel, которая поддерживается в большинстве современных коммутаторов и обеспечивает масштабируемость зашифрованного канала. Производительность агрегированного канала можно увеличивать без его отключения за счет добавления новых физических каналов.
[16]Основными компонентами схемы в каждом ЦОД являются: коммутатор, на котором выполняется агрегирование каналов; кластер криптомаршрутизаторов с поддержкой технологии L2OverIP; граничные маршрутизаторы сети. Трафик, идущий из ЦОД, распределяется по линкам агрегированного канала, зашифровывается кластером криптомаршрутизаторов и через граничные маршрутизаторы сети передается в открытую сеть. В ЦОД, где находится получатель трафика, выполняется обратная процедура.
[17]Этот способ принимается в качестве прототипа. Однако, известный способ имеет следующие недостатки:
[18]- технология EtherChannel имеет ограничения по количеству агрегируемых каналов и, следовательно, по количеству подключаемых криптомаршрутизаторов;
[19]- агрегируемые физические каналы должны быть одинаковой производительности, что исключает возможность использования криптомаршрутизаторов с сетевыми интерфейсами разной производительности;
[20]- указанная технология L2OverIP поддерживается только на одинаковых криптомаршрутизаторах (производимых, в частности, компанией Инфо-ТеКС), что исключает возможность использования в схеме криптомаршрутизаторов разных производителей;
[21]- способ не может быть применен, если необходима возможность миграции хостов между ЦОД без перенастройки сетевого оборудования.
[22]Раскрытие изобретения
[23]Техническим результатом является
[24]1) обеспечение возможности создания кластера криптомаршрутизаторов без ограничений на их количество, производительность и тип;
[25]2) обеспечение возможности миграции конечных устройств между соединенными сетями без необходимости перенастройки сетевых устройств.
[26]Для этого предлагается способ создания защищенного L2-соединения между сетями с коммутацией пакетов, причем в сетях установлены:
[27]- контроллер, подключенный ко всем сетям и выполненный с возможностью:
[28]
формировать таблицы потоков, содержащие правила обработки сетевых пакетов;
[29] обмениваться управляющими сообщениями с коммутаторами по установленному протоколу управления;
[30] запрашивать, получать и анализировать информацию от других сетевых устройств;
[31]- коммутаторы, каждый из которых установлен в своей сети, подключен к ней и выполнен с возможностью:
[32] принимать и посылать сетевые пакеты;
[33] обмениваться управляющими сообщениями с контроллером по установленному протоколу управления;
[34] хранить в оперативной памяти, по крайней мере, три таблицы потоков и выполнять обработку сетевых пакетов по этим таблицам;
[35] обрабатывать пакеты при помощи заданной таблицы потоков;
[36] создавать виртуальные порты с поддержкой установленного протокола туннелирования;
[37]- криптографические маршрутизаторы (далее криптомаршрутизаторы), каждый из которых имеет в составе, по крайней мере, один процессор; причем в каждой сети установлено, по крайней мере, по два криптомарш-рутизатора, подключенные к своему коммутатору; каждый криптомарш-рутизатор выполнен с возможностью:
[38] принимать и посылать сетевые пакеты;
[39] загружать ключевую информацию;
[40] настраивать диапазоны туннелируемых IP-адресов;
[41] шифровать, расшифровывать и маршрутизировать сетевые пакеты;
[42] отвечать на запросы информации от контроллера;
[43]- рабочие станции, установленные и подключенные каждая к своей сети и выполненные с возможностью обмениваться между собой сетевыми пакетами;
[44]способ заключается в том, что:
[45]- формируют ключевую информацию для всех криптомаршрутизаторов;
[46]- выделяют в каждой сети диапазоны ГР-адресов для установленных устройств, а также диапазоны туннелируемых криптомаршрутизаторами IP-адресов;
[47]- включают криптомаршрутизаторы;
[48]- загружают на криптомаршрутизаторы ключевую информацию;
[49]- настраивают на криптомаршрутизаторах IP-адреса;
[50]- настраивают на криптомаршрутизаторах выделенные диапазоны туннелируемых IP-адресов;
[51]- включают коммутаторы;
[52]- создают на каждом коммутаторе два виртуальных порта:
[53] порт для инкапсуляции/декапсуляции сетевых пакетов в заголовки протокола туннелирования (далее туннельный порт);
[54] порт уровня L3, служащий конечным IP-интерфейсом туннеля (далее сетевой интерфейс);
[55]- настраивают на сетевых интерфейсах всех коммутаторов IP-адреса;
[56]- настраивают на коммутаторах IP-адрес контроллера;
[57]- включают контроллер;
[58]- создают на контроллере конфигурационный файл, содержащий значения следующих констант: таймаут неактивности правил в таблицах потоков, интервал запроса статистики, длительность одной итерации сбора статистики;
[59]- выполняют на контроллере регистрацию и инициализацию коммутаторов, в ходе которых загружают на каждый коммутатор три таблицы потоков с начальным набором правил:
[60] таблица 0 - предназначена для распределения по другим таблицам сетевых пакетов;
[61] таблица 1 - предназначена для обработки исходящих с коммутатора сетевых пакетов;
[62] таблица 2 - предназначена для обработки приходящих на коммутатор сетевых пакетов;
[63]- вычисляют в контроллере метрики криптомаршрутизаторов, выполняя следующие действия:
[64] получают значения загрузки процессоров криптомаршрутизаторов через интервал запроса статистики, в течение длительности одной итерации сбора статистики;
[65] вычисляют среднюю загрузку Li процессора каждого криптомаршрутизатора в процентах, где i - номер криптомаршрутизатора;
[66] вычисляют для каждого криптомаршрутизатора метрику по формуле Mi=(100-Li)/10
[67]и округляют полученное значение Mi до наибольшего целого числа;
[68] создают на контроллере для каждого коммутатора пустой одномерный массив (далее массив портов);
[69] записывают в конец массива портов каждого коммутатора номер каждого порта коммутатора, к которому подключен i-й криптомаршрутизатор, в количестве, равном значению Mi;
[70]- включают рабочие станции;
[71]- настраивают на рабочих станциях IP-адреса;
[72]- посылают сетевой трафик (далее поток) с одной рабочей станции (далее отправитель), подключенной к своему коммутатору (далее коммутатор 1), на другую рабочую станцию (далее получатель), подключенную к своему коммутатору (далее коммутатор 2);
[73]- посылают от отправителя ARP-запрос для определения МАС-адреса получателя по его IP-адресу;
[74]- осуществляют выбор криптомаршрутизатора и определение параметров туннеля на коммутаторе 1, выполняя следующие действия:
[75] получают на коммутаторе 1 ARP-запрос от отправителя;
[76] обрабатывают ARP-запрос на коммутаторе 1 по таблице потоков 0 и отправляют ARP-запрос на контроллер для анализа;
[77] посылают из контроллера на коммутатор 1 команду обработать ARP-запрос по таблице потоков 1 как широковещательный;
[78] обрабатывают ARP-запрос на коммутаторе 1 по таблице потоков 1 и снова отправляют ARP-запрос на контроллер для анализа;
[79] определяют криптомаршрутизатор, на который нужно отправить ARP-запрос; путем случайного выбора в контроллере из массива портов коммутатора 1 выходного порта для отправки ARP-запроса;
[80] посылают из контроллера на коммутатор 1 команду установить правило коммутации в таблицу потоков 0 с таймаутом неактивности;
[81] посылают из контроллера на коммутатор 1 команду отправить ARP-запрос в туннельный порт с установленными параметрами туннеля;
[82] определяют на коммутаторе 1 с участием контроллера МАС-адрес удаленного интерфейса туннеля, выполняя следующие действия:
[83]
посылают из контроллера на коммутатор 1 команду отправить ARP-запрос из сетевого интерфейса коммутатора 1;
[84] устанавливают при помощи искусственной подстановки в качестве МАС-адреса удаленного интерфейса туннеля МАС-адрес выбранного криптомаршрутизатора;
[85] устанавливают с контроллера в таблицы потоков 0 и 1 коммутатора 1 правила коммутации с таймаутом неактивности;
[86] посылают из коммутатора 1 на коммутатор 2 инкапсулированный ARP-запрос отправителя;
[87]- обрабатывают ARP-запрос отправителя на коммутаторе 2 с использованием контроллера, выполняя следующие действия:
[88] получают на коммутаторе 2 инкапсулированный ARP-запрос отправителя и согласно начальным правилам таблицы потоков 0 отправляют в туннельный порт;
[89] отправляют ARP-запрос отправителя после декапсуляции на туннельном порту коммутатора 2 согласно начальным правилам таблицы потоков 0 в таблицу потоков 2;
[90] обрабатывают ARP-запрос на коммутаторе 2 по таблице потоков 2 и отправляют на контроллер для анализа;
[91] посылают из контроллера на коммутатор 2 следующие команды:
[92] отправить ARP-запрос в порт, к которому подключен получатель;
[93] установить в таблицы потоков 0 и 2 правила коммутации с таймаутом неактивности;
[94]- получают ARP-запрос на получателе;
[95]- отправляют с получателя отправителю ARP-ответ, содержащий МАС-адрес получателя;
[96]- получают ARP-ответ на коммутаторе 2;
[97]- осуществляют выбор криптомаршрутизатора и определение параметров туннеля на коммутаторе 2, выполняя следующие действия:
[98] обрабатывают ARP-ответ на коммутаторе 2 по таблице потоков 0 и отправляют ARP-ответ на контроллер для анализа;
[99] посылают из контроллера на коммутатор 2 команду обработать ARP-ответ по таблице потоков 1 как широковещательный;
[100] обрабатывают ARP-ответ на коммутаторе 2 по таблице потоков 1 и снова отправляют ARP-ответ на контроллер для анализа;
[101] определяют криптомаршрутизатор, на который нужно отправить ARP-ответ; путем случайного выбора в контроллере из массива портов коммутатора 2 выходного порта для отправки ARP-ответа;
[102] посылают из контроллера на коммутатор 2 команду установить правило коммутации в таблицу потоков 0 с таймаутом неактивности;
[103] посылают из контроллера на коммутатор 2 команду отправить ARP-ответ в туннельный порт с установленными параметрами туннеля;
[104] определяют на коммутаторе 2 с участием контроллера МАС-адрес удаленного интерфейса туннеля, выполняя следующие действия:
[105] посылают из контроллера на коммутатор 2 команду отправить ARP-запрос из сетевого интерфейса коммутатора 2;
[106] устанавливают при помощи искусственной подстановки в качестве МАС-адреса удаленного интерфейса туннеля МАС-адрес выбранного криптомаршрутизатора;
[107] устанавливают с контроллера в таблицы потоков 0 и 1 коммутатора 2 правила коммутации с таймаутом неактивности;
[108] посылают из коммутатора 2 на коммутатор 1 инкапсулированный ARP-ответ получателя;
[109]- получают ARP-ответ получателя на коммутаторе 1;
[110]- обрабатывают ARP-ответ получателя на коммутаторе 1 с использованием контроллера, выполняя следующие действия:
[111] отправляют на коммутаторе 1 инкапсулированный ARP-ответ получателя согласно начальным правилам таблицы потоков 0 в туннельный порт;
[112] отправляют ARP-ответ получателя после декапсуляции на туннельном порту коммутатора 1 согласно начальным правилам таблицы потоков 0 в таблицу потоков 2;
[113] обрабатывают ARP-ответ на коммутаторе 1 по таблице потоков 2 и отправляют на контроллер для анализа;
[114] посылают из контроллера на коммутатор 1 следующие команды:
[115] отправить ARP-ответ в порт, к которому подключен отправитель;
[116] установить в таблицы потоков 0 и 2 правила коммутации с таймаутом неактивности;
[117]- получают ARP-ответ на отправителе;
[118]- передают данные потока между отправителем и получателем по сформированному L2-соединению без новых обращений к контроллеру.
[119]Отличительные особенности предлагаемого изобретения заключаются в следующем.
[120]Предлагаемый способ базируется на технологии ПКС, согласно которой вся логика обработки трафика выносится на централизованный контроллер, а коммутаторы, занимаются только коммутацией потоков трафика на основании таблиц потоков, загружаемых в них контроллером по установленному протоколу (например, OpenFlow).
[121]В предлагаемом способе каждый криптографический маршрутизатор обладает уникальным ключевым набором и туннелируемым диапазоном IP-адресов. Для того, чтобы корректно передать зашифрованный IP-пакет между парой криптомаршрутизаторов, обладающих ключами парной связи, выполняется подмена IP-адресов в заголовке исходного IP-пакета.
[122]Для объединения нескольких сетей в единую локальную сеть, а также для реализации возможности миграции виртуальных машин между сетями в способе используется протокол туннелирования (GRE), позволяющий передавать через открытую сеть трафик любого уровня в инкапсулированном виде.
[123]Распределение трафика на каждом коммутаторе происходит на основании метрик криптомаршрутизаторов, которые, в свою очередь, базируются на средней загрузке процессоров криптомаршрутизаторов за заданный промежуток времени.
[124]Предлагаемый способ позволяет обслуживать случаи миграции виртуальных машин между сетями благодаря использованию таймаута неактивности правил коммутации, динамически устанавливаемых в таблицы потоков распределяющих трафик коммутаторов.
[125]Заявленный технический результат достигается благодаря следующему.
[126]Количество подключаемых криптомаршрутизаторов, на которые происходит балансировка полезного трафика, зависит только от количества свободных портов на коммутаторе. В случае объединения нескольких коммутаторов в стек, количество свободных портов для подключения криптомаршрутизаторов будет значительно превышать количество криптомаршрутизаторов, необходимое для создания защищенного канала 10/40/100G, что полностью покрывает современные бизнес-требования.
[127]Возможность объединения в кластер криптомаршрутизаторов разной производительности также определяется только наличием портов соответствующей производительности на коммутаторе. Для балансировки при распределении трафика использует метрики криптомаршрутизаторов, которые пропорциональны их производительности и загрузке.
[128]В предлагаемом способе к криптомаршрутизаторам не предъявляются какие-либо специальные функциональные требования. Поэтому тип и производитель криптомаршрутизатора значения не имеют. Единственное условие заключается в том, чтобы пара криптомаршрутизаторов, участвующих в шифровании/расшифровании данного потока трафика, имели согласованные ключевые наборы и алгоритмы шифрования.
[129]В случае миграции конечного устройства из одной сети (ЦОДа) в другую, прекращается поток трафика от данного конечного устройства из сети, в которой оно находилось изначально. После истечения таймаута неактивности правил, коммутирующих потоки трафика от данного конечного устройства, все правила, относящиеся к данному конечному устройству, удаляются на всех коммутаторах. Далее контроллер заново формирует и загружает на коммутаторы новые правила, отправляющие трафик из и в новую локацию мигрировавшего конечного устройства.
[130]Краткое описание чертежей
[131]На фигуре графического изображения приведена схема объединения трех сетей посредством защищенного канала связи.
[132]Используются следующие обозначения:
[133]1, 2, 3 - соединяемые сети;
[134]4, 15, 20 - конечные устройства;
[135]5, 14, 19 - коммутаторы;
[137]7, 8, 12, 13, 17, 18 - криптомаршрутизаторы;
[138]9, 11, 16 - граничные маршрутизаторы сетей (для предложенного способа несущественны);
[139]10 - глобальная сеть.
[140]Осуществление изобретения
[141]Предлагаемый способ может быть реализован в следующей программно-аппаратной среде.
[142]В качестве коммутатора 5, 14, 19 может быть использован сервер со следующими аппаратными характеристиками:
[143]- процессор: один процессор Intel Xeon Е5-2620 v3 (2.40 GHz, 6 ядер);
[144]- оперативная память: 8 GB;
[145]- сетевые адаптеры 10G: 3 адаптера Intel 82599ES;
[146]- сетевые адаптеры 1G: 2 адаптера Intel I350-AM2.
[147]Данная конфигурация включает один NUMA-узел с 12 логическими ядрами при включенной технологии Hyper-Threading.
[148]Сетевые адаптеры 10G используются для передачи полезного трафика. Обязательное требование для них - поддержка технологии Intel DPDK.
[149]Сетевые адаптеры 1G используются для управляющей связи с контроллером и администрирования коммутатора.
[150]Тип и объем жесткого диска коммутатора критического значения не имеют, так как в ходе работы коммутатора частых или регулярных операций чтения-записи не происходит. Достаточным является жесткий диск 250 GB, тип SATA.
[151]Вариант программного обеспечения коммутатора:
[152]- Debian Server 8.7.1 (минимальная установка, ядро 4.10.5);
[153]- Open vSwitch 2.7.0;
[155]Аппаратное обеспечение контроллера 6 может значительно различаться в зависимости от максимально возможной нагрузки на контроллер. Нагрузка на контроллер зависит от количества новых потоков трафика в секунду, которые контроллер должен обработать, и от сложности логики обработки каждого потока. Ключевой аппаратной характеристикой работы контроллера является мощность процессора.
[156]В качестве контроллера 6 может быть использован сервер со следующими аппаратными характеристиками:
[157]- процессор: один процессор Intel Xeon Е5-2620 v3 (2.40 GHz, 6 ядер);
[158]- оперативная память: 4 GB;
[159]- сетевые адаптеры 1G: 2 адаптера Intel I350-AM2;
[160]- жесткий диск: 500 GB, SATA.
[161]Сетевые адаптеры 1G используются для управляющей связи с коммутаторами и администрирования контроллера.
[162]Вариант программного обеспечения контроллера:
[163]- Debian Server 8.7.1;
[164]- SDN-контроллер RYU;
[165]- программы, выполняющие функции создания L2-соединений и балансировки трафика.
[166]Сформировать программы, выполняющие функции создания L2-соединений и балансировки трафика, может специалист в области программирования (программист), компетентный в области сетевых технологий и программно-конфигурируемых сетей.
[167]Программно-аппаратное обеспечение конечных устройств 4, 15, 20 существенного значения для реализации способа не имеет. В качестве конечного устройства может быть использован любой персональный компьютер с установленной операционной системой и подключенный к сети. Единственным требованием к конечным устройствам является возможность отправки сетевого трафика между собой.
[168]Программно-аппаратное обеспечение криптомаршрутизаторов 7, 8, 12, 13, 17, 18 может быть различным, так как предлагаемый способ предназначен для одновременного использования криптомаршрутизаторов разной производительности. Варианты криптомаршрутизаторов, которые могут быть использованы в предлагаемой схеме, могут быть найдены (материал по адресу: https://infotecs.ru/product/setevye-komponenty/vipnet-coordinator-hw/).
[169]На фигуре графического изображения представлена схема соединения трех сетей 1, 2, 3 посредством защищенных каналов связи.
[170]На OF-коммутаторе 5, 14, 19 (далее коммутатор) каждой сети выделяется один порт, к которому подключается внутренняя локальная сеть. Будем считать, что этот порт имеет номер 01, и в дальнейшем будем называть такой порт портом доступа и обозначать как eth01.
[171]Также, на коммутаторе выделяется специальный порт, который выполняет инкапсуляцию/декапсуляцию Ethernet-фреймов, идущих из/в локальную сеть соответственно. Этот порт будем называть туннельным и считать, что туннельный порт имеет номер 02.
[172]Для создания туннелей требуется также IP-интерфейс на коммутаторе. Примем, что этот интерфейс будет иметь номер 03, называть такой интерфейс будем сетевым.
[173]Порт коммутатора, к которому подключается граничный маршрутизатор сети, будем называть внешним (по умолчанию номер 04).
[174]В схеме, представленной на фигуре графического изображения, в каждом коммутаторе используются два виртуальных порта veth04.1 и veth04.2, так как к каждому коммутатору подключены два криптомаршрутизатора. В общем случае, количество виртуальных портов коммутатора равно количеству подключенных к коммутатору криптомаршрутизаторов. Данные виртуальные порты реально не существуют в конфигурациях коммутаторов, однако, они будут использоваться в OF-таблицах (таблицах потоков). Каждый виртуальный порт отвечает за связь между парой сетей. Так будем считать, что между собой связаны следующие виртуальные порты:
[175]- veth04.1 коммутатора сети 1 и veth04.1 коммутатора сети 2;
[176]- veth04.2 коммутатора сети 1 и veth04.2 коммутатора сети 3;
[177]- veth04.2 коммутатора сети 2 и veth04.1 коммутатора сети 3.
[178]Связь между каждыми двумя сетями осуществляется напрямую, т.е. обрыв канала между парой сетей не предполагает изменение пути прохождения трафика через третью сеть. Далее вместо термина «сеть» будем использовать термин «ЦОД» аналогично прототипу.
[179]Опишем схему связи между ЦОД1 и ЦОД2 через GRE-туннель. Зададим на интерфейсах следующие IP-адреса. GRE-туннель будет создаваться между сетевыми интерфейсами OF-коммутаторов. Одна граница GRE-туннеля будет иметь сетевой адрес 172.16.101.2, а вторая - 172.16.102.2.
[180]Далее рассмотрим логику работы SDN-контроллера на примере прохождения ICMP-трафика между конечным устройством 4 client в ЦОД1 и конечным устройством 15 server в ЦОД2. Начнем с заполнения ARP-таблиц.
[181]1. Клиентская рабочая станция client отсылает в сторону OF-коммутатора 5 ARP-запрос для установления аппаратного адреса сервера server.
[182]2. ARP-запрос поступает в порт eth01 OF-коммутатора. Коммутатор в свою очередь должен отправить его широковещательно в другие ЦОД, т.к. в начальный момент времени расположение сервера неизвестно. Далее рассмотрим прохождения трафика только к ЦОД2.
[183]3. Для отправки ARP-запроса OF-коммутатор посылает его в туннельный порт eth02. Туннельный порт, инструктируемый SDN-контроллером, динамически создает GRE-туннель, устанавливая адрес отправителя 172.16.101.2, а адрес получателя 172.16.102.2.
[184]4. Предполагая, что все маршруты в другие ЦОД проходят через интерфейс eth03, ARP-запрос должен быть отправлен именно в этот интерфейс после упаковки в заголовки туннельного протокола. Однако, здесь возникнет проблема: для формирования Ethernet-фрейма, содержащего IP-пакет с адресом получателя 172.16.102.2, требуется знать аппаратный адрес получателя. В итоге контроллером 6 будет сформирован ARP-запрос от имени адреса 172.16.101.2. Этот ARP-запрос также будет отправлен через интерфейс eth03.
[185]5. Для обработки этого ARP-запроса OF-коммутатор должен заменить IP-адрес, для которого запрашивается аппаратный адрес, на адрес шлюза 9 локальной сети ЦОД1 172.16.101.1 и далее отправить запрос во внешний интерфейс eth04.
[186]6. В итоге на шлюз 9 поступит запрос отправить узлу 172.16.101.2 аппаратный адрес шлюза. Шлюз сформирует ARP-ответ в сторону узла 172.16.101.2. Этот ответ должен поступить в интерфейс eth04 OF-коммутатора.
[187]7. На OF-коммутаторе в полученном от шлюза ARP-ответе необходимо заменить адрес отправителя на адрес 172.16.102.2, для которого реально отправлялся ARP-запрос, а также отправить измененный ответ в интерфейс eth03, через который запрашивался аппаратный адрес узла 172.16.102.2.
[188]8. После получения ARP-ответа для адреса 172.16.102.2 в сетевой интерфейс eth03 поступит GRE-пакет, инкапсулирующий исходный ARP-запрос клиента client. Заметим, что аппаратный адрес получателя в этом GRE-пакете будет равен аппаратному адресу интерфейса маршрутизатора 9.
[189]9. GRE-пакет, попав в ЦОД2, поступает во внешний порт eth04 OF-коммутатора 14 и далее пересылается в туннельный порт eth02, где происходит декапсуляция, и исходный ARP-запрос клиента client отправляется OF-коммутатором в порт доступа eth01, из которого он попадает к серверу server.
[190]10. Обратный ARP-ответ от сервера проходит описанный путь с очевидными изменениями IP и аппаратных адресов.
[191]Рассмотрим конфигурацию OF-таблиц и действия контроллера 6. В каждом OF-коммутаторе будут использоваться три таблицы: таблица с номером 0, 1 и 2. Опишем таблицу с номером 0 после инициализации OF-коммутатора. Разделим таблицу потоков на несколько логических частей. Часть, которая описывает обработку GRE-трафика, выглядит, как показано в табл. 1 (здесь и далее несущественные для алгоритма параметры OF-записей опущены).
[192]
[193]Первое правило таблицы (напомним, что чем ниже правило в таблице, тем его приоритет выше) означает, что каждый входящий пакет необходимо считать пакетом нового потока и отправлять на контроллер для принятия решения об обработке нового потока.
[194]Второе правило определяет, как должен обрабатываться исходящий туннельный трафик (в данном случае GRE). Его необходимо послать в выходной интерфейс OF-коммутатора в сторону граничного маршрутизатора.
[195]Правило 3 отправляет входящий туннельный трафик в туннельный интерфейс для распаковки.
[196]Правила 4 и 5 определяют обработку распакованного GRE-трафика, перенаправляя его в соответствующие порты таблицы 2 в зависимости от адреса отправителя. Это происходит с помощью действия resubmit, которое запускает процедуру обработки трафика OF-коммутатором таблицей с номером 2.
[197]Правило resubmit позволяет указать не только номер таблицы, но и номер порта. В этом случае поток будет обработан новой таблицей, и при этом коммутатор будет считать, что поток пришел из порта, указанного в команде resubmit. Для примера, если выполняется команда resubmit (2, 4.1), то коммутатор запустит обработку потока таблицей 2 и в правилах будет «считать», что поток пришел из порта 4.1. Можно сказать, что действие resubmit позволяет не отправить поток на другой коммутатор, а отправить его в тот же, но в другой порт и другую таблицу. Заметим, что дополнительная классификация входящего трафика необходима для определения номера ЦОД, из которого пришел трафик.
[198]Вторая часть таблицы потоков 0 отвечает за обработку ARP-трафика (табл. 2).
[199]
[200]Первая строка указывает, что необходимо во всех ARP-запросах, приходящих от сетевого интерфейса коммутатора, подменять IP-адрес назначения на 172.16.101.1 (адрес шлюза), и отправлять запрос во внешний порт eth04 к граничному маршрутизатору. Вторая строка обеспечивает передачу ARP-ответов от граничного маршрутизатора с обратной заменой целевого адреса, третья позволяет направлять все ARP-запросы, приходящие от граничного маршрутизатора к сетевому интерфейсу OF-коммутатора, а четвертая отвечает за передачу всех ARP-ответов от сетевого интерфейса eth03 к граничному маршрутизатору.
[201]Таблица потоков с номером 1 обрабатывает трафик, идущий из локальной сети. Она описывает правила туннелирования трафика и зависит от используемого протокола туннелирования. Например, для GRE туннеля может указываться локальный адрес туннеля, удаленный адрес туннеля и идентификатор туннеля. В табл. 3 показана таблица потоков 1 для OF-коммутатора в случае использования протокола GRE.
[202]
[203]В таблице потоков 1 для каждого OF-коммутатора нужно правильно задать параметры GRE туннеля: адрес получателя и отправителя. Каждая запись фактически указывает, что трафик, приходящий в таблицу 1 с порта IN_PORT, должен быть отправлен в туннельный порт, при инкапсуляции в котором должны быть использованы указанные в инструкциях set_field значения параметров. Первая запись обеспечивает связь с ЦОД2 через порт veth04.1, а вторая - с ЦОД3 через порт veth04.2. Таким образом, после прохождения через таблицу потоков 1 поток будет инкапсулирован в заголовки протокола GRE и отправлен на граничный маршрутазатор через туннельный порт eth02. Однако, как уже отмечалось, Ethernet-трафик выйдет не из туннельного порта, а из сетевого интерфейса eth03, куда он будет передан через стек TCP/IP после GRE-инкапсуляции.
[204]Таблица потоков 2 OF-коммутатора (табл. 4) служит для обработки трафика, идущего в локальную сеть. После инициализации в этой таблице содержится только одно правило.
[205]
[206]Опишем базовый алгоритм работы контроллера 6. В алгоритме используются таблицы потоков №0, 1, 2 (далее таблицы), описанные выше. Ссылка на пример обсуждаемой таблицы потоков обозначается как «табл.».
[207]1. В начальный момент времени на рабочей станции client пользователь вводит команду ping server.
[208]2. Предполагаем, что раньше связи между двумя узлами не было, и рабочая станция обращается к серверу впервые. В этом случае рабочая станция для формирования Ethernet-фрейма должна узнать МАС-адрес сервера по его IP-адресу. Следовательно, с рабочей станции отправляется широковещательный ARP-запрос, который попадает на OF-коммутатор ЦОД1.
[209]3. Как ранее уже указывалось, в начальный момент времени в таблице 0 OF-коммутатора стоит правило, отправляющее первый пакет каждого нового потока на контроллер. ARP-запрос от рабочей станции коммутатор воспринимает как новый поток и поэтому обращается к контроллеру для получения указаний о том, как обработать данный новый поток.
[210]4. Контроллер, получив информацию о новом потоке, определяет, что адрес получателя ему неизвестен, поэтому на коммутатор он должен передать команду отправить этот поток во все порты, кроме входящего, т.е. запустить процесс изучения топологии. Однако, в случае использования туннелей недостаточно отправить трафик во все порты при помощи таблицы 0. Контроллер указывает OF-коммутатору ЦОД1 с помощью правила resubmit запустить процедуру обработки трафика по таблице с номером 1. Таким образом, контроллер отсылает команду обработать поток по таблице 1, считая, что он пришел последовательно из всех виртуальных портов: eth04.1 и eth04.2. В результате пакет будет отправлен по всем возможным направлениям: в ЦОД2 и в ЦОД3.
[211]5. Получив команду от контроллера, OF-коммутатор ЦОД1 отправляет трафик в таблицу 1. Для каждого порта с номером N в этой таблице существует запись, которая указывает, что если поток пришел в порт с номером N (напомним, что в таблице 1 это - виртуальные порты), то этот поток должен быть отправлен в GRE/VXLAN порт eth02 с заданными параметрами туннеля. Пакет после попадания в туннельный порт будет упакован, и новый туннельный пакет должен быть отправлен через сетевой интерфейс eth03. Однако, для формирования Ethernet-фрейма недостаточно информации, а именно, нет указания, какой использовать аппаратный адрес получателя. В итоге от имени адреса 172.16.101.2 формируется ARP-запрос к 172.16.102.2 (либо к 172.16.103.2). Этот запрос с заменой целевого адреса поступает на граничный маршрутизатор, который в свою очередь посылает ARP-ответ, обрабатываемый на коммутаторе при помощи таблицы 0. В итоге на коммутаторе ЦОД1 формируется Ethernet-фрейм и отправляется в выходной порт eth04.
[212]6. Туннельный трафик через глобальную сеть попадает на граничные маршрутизаторы ЦОД2 и ЦОД3 и затем на туннельный порт eth02 граничного OF-коммутатора каждого ЦОД. Далее будем рассматривать только ЦОД2, т.к. в ЦОД3 события будут происходить аналогично за тем лишь исключением, что широковещательный ARP-запрос к server будет отброшен в локальной сети ЦОД3 в силу того, что на него никто не ответит. OF-коммутатор ЦОД2 в соответствии с таблицей 0 отправляет декапсулированный GRE-трафик на обработку в таблицу с номером 2.
[213]7. Первоначально в таблице 2 стоит единственная запись, указывающая считать каждый приходящий пакет началом нового потока и отправлять его на анализ контроллеру. Таким образом, после попадания из туннеля в соответствующий порт таблицы 2 пакет будет отправлен для анализа на контроллер.
[214]8. Контроллер, получив пакет, определяет МАС-адрес отправителя и фиксирует в своей МАС-таблице, что этот адрес доступен за определенным виртуальным портом (veth04.1 или veth04.2) OF-коммутатора ЦОД2. Порт определяется на основании информации, полученной от OF-коммутатора, в которой указывается, в какой конкретно порт таблицы 2 пришел пакет нового потока. В примере, пакет с МАС-адресом client придет в порт 4.1 таблицы 2. Поэтому контроллер зафиксирует запись client:4.1.
[215]9. Контроллер передает на OF-коммутатор ЦОД2 следующие команды: отправить полученный пакет в выходной порт eth01, в таблице 0 установить запись, предписывающую отправлять весь трафик с МАС-адресом получателя client в порт 4.1 таблицы 1, которая связана с внешним портом eth04, отвечающим за связь с ЦОД1, а в таблице 2 установить запись, на основании которой OF-коммутатор должен отправлять весь трафик, приходящий с аппаратного адреса client на адрес server, в порт eth01 локальной сети. Таким образом, последнее правило предотвратит обращения к контроллеру для всех последующих пакетов данного потока. Отметим, что правило должно выставляться с таймаутом неактивности для отслеживания изменения топологии сети. Приведем итоговые записи в таблицах 0 и 2 OF-коммутатора Ц0Д2. Новые записи в таблице потоков 0 выглядят, как показано в табл. 5. Новые записи в таблице потоков 2 выглядят, как показано в табл. 6.
[216]
[217]
[218]10. В результате ARP-запрос от клиента попадет в локальную сеть ЦОД2 и потом серверу.
[219]11. Сервер отправит клиенту ARP-ответ, который вернется на OF-коммутатор ЦОД2.
[220]12. Полученный ARP-ответ OF-коммутатор может обработать, т.к. в таблице 0 уже имеется запись, соответствующая ARP-ответу: МАС-адрес получателя в ответе равен client. Эта запись диктует отправить пакет на обработку в порт 4.1 таблицы 1. И далее, согласно правилам таблицы 1, пакет будет инкапсулирован и отправлен в ЦОД1.
[221]13. В результате, ARP-ответ поступит в OF-коммутатор ЦОД1. Для этого ARP-ответа повторится такая же последовательность событий, что и для ARP-запроса на OF-коммутаторе ЦОД2.
[222]14. ICMP-запрос от клиента в сторону сервера, как и ICMP-ответ от сервера, уже не вызовут обращений к контроллеру, т.к. в каждом OF-коммутаторе уже есть правила обработки данных пакетов.
[223]Далее опишем балансировку трафика на криптографические маршрутизаторы на примере, приведенном на фигуре графического изображения. В конфигурацию коммутаторов добавится дополнительный порт для подключения второго криптомаршрутизатора.
[224]В каждом OF-коммутаторе будут задействованы таблицы с номерами 0, 1 и 2. Таблица 0 будет служить для классификации трафика и его распределения между криптомаршрутизаторами, таблицы 1 и 2 - для обработки трафика, соответственно исходящего и входящего в локальную сеть. Таблица с номером 0 в части обработки GRE-трафика после инициализации OF-коммутатора ЦОД1 выглядит как показано в табл. 7.
[225]
[226]Частично поясним записи таблицы. В строках 2-5 в адресах IP_DST вида 172.16.М.Р буква М означает 100+номер ЦОДа, Р - номер порта, в который подключей криптомаршрутизатор. При отправке GRE-трафика в глобальную сеть заменяется IP-адрес назначения GRE-туннеля. Это сделано для упрощения настройки криптомаршрутизаторов. Последние две строки таблицы предназначены для обработки входящего в коммутатор ЦОДа 1 туннельного трафика.
[227]Часть таблицы 0, отвечающая за обработку ARP-трафика (см. табл. 8), обеспечивает передачу ARP-запросов от криптомаршрутизаторов к сетевому интерфейсу eth03 OF-коммутатора, а также обратную передачу ARP-ответов. Таблица с номером 1 будет выглядеть, как показано в табл. 9.
[228]
[229]
[230]Дадим некоторые пояснения. Для управления прохождением трафика через криптомаршрутизатор будем использовать различные адреса удаленного интерфейса GRE-туннеля. Таким образом, IP-адрес отправителя однозначно определяет ЦОД-отправитель, а IP-адрес получателя определяет ЦОД-получатель, и через какой криптомаршрутизатор проходил трафик. Так, например, GRE-туннель вида:
[231]172.16.102.2←→172.16.103.4
[232]означает, что трафик поступает от ЦОД2, идет к ЦОД3 и проходит через криптомаршрутизатор, который подключен к порту eth04 OF-коммутатора ЦОД2. В приведенной таблице для каждого удаленного ЦОД, и для каждого криптомаршрутизатора, ведущего к нему, заданы свои адреса конечных точек GRE-туннеля. Входные виртуальные порты OF-коммутатора (первая колонка табл. 7) формируются по схеме: первая цифра - номер ЦОД, вторая цифра - номер порта, в который подключен криптомаршрутизатор.
[233]Принят следующий базовый алгоритм работы контроллера при балансировке ICMP-трафика.
[234]1. В начальный момент времени на рабочей станции пользователь вводит команду ping server.
[235]3.. Дальше повторяются шаги 2-4 описанной ранее схемы прохождения трафика без балансировки. Как и ранее рассмотрим только трафик, идущий в сторону ЦОД2.
[236]4. В начальный момент времен в таблице 1 (ЦОД1) пакет, приходящий в порты 4.1 и 4.2, является первым пакетом нового потока, и OF-коммутатор обращается к контроллеру за инструкциями.
[237]5. Контроллер, получив пакет из порта 4.1 таблицы 1 (в сторону ЦОД2), выбирает случайным образом (либо в соответствии с заданным алгоритмом балансировки) криптомаршрутизатор, через который должен пройти трафик. Пусть был выбран криптомаршрутизатор с номером 2. В этом случае контроллер отсылает OF-коммутатору команду установить правило: отправлять весь данный поток с помощью команды resubmit из таблицы 0 в таблицу 1, но в порт с номером 5.1.
[238]6. Получив команду от контроллера, OF-коммутатор отправляет трафик в туннельный порт с указанием какие параметры туннеля должны быть установлены. Однако для создания пакетного трафика недостаточно информации, а именно, нет указания какой использовать аппаратный адрес получателя. В итоге от имени адреса 172.16.101.2 формируется ARP-запрос к 172.16.102.5 и далее с помощью правил таблицы 0 он попадет на контроллер, т.к. к нему будет применима только запись с самым низким приоритетом.
[239]7. Контроллер, получив ARP-запрос, отправит в коммутатор два OpenFlow-правила: первое правило указывает, что необходимо подменить адрес источника и адрес назначения в ARP-запросе и отправить его в порт eth05, за которым находится граничный маршрутизатор, а второе указывает сделать обратную подмену и отправить в порт eth03. Правила приведены в табл. 10.
[240]
[241]Опишем правило формирования адресов для замены. Пусть к контроллеру поступает ARP-запрос со следующими параметрами:
[242]arp_spa=172.16.10N.2, arp_tpa=172.16.10М.Р,
[243]где N - номер ЦОД отправителя;
[244]М - номер ЦОД получателя;
[245]Р - номер порта OF-коммутатора ЦОДа отправителя, к которому подключей выбранный при балансировке криптомаршрутизатор.
[246]Тогда запрос трансформируется в следующий:
[247]arp_spa=172.16.10N.(M+1), arp_tpa=172.16.10N.1
[248]и отправляется в порт eth0P.
[249]Обратная трансформация выполняется по правилу:
[250]ARP-ответ с параметрами
[251]arp_spa=172.16.10N.1, arp_tpa=172.16.10N.(M+1),
[252]пришедший в порт eth0P, преобразуется в ARP-ответ:
[253]arp_spa=172.16.10М.Р, arp_tpa=172.16.10N.2
[254]и отправляется в порт eth03.
[255]8. После указанной замены в сетевой порт eth.03 будет получен ARP-ответ с аппаратным адресом выбранного граничного маршрутизатора. Теперь Ethernet-фрейм, содержащий туннельный пакет, будет сформирован и отправлен в выходной интерфейс eth05.
[256]9. Туннельный трафик через глобальную сеть попадает на граничный маршрутизатор ЦОД2 и ЦОД3 и далее на туннельный порт граничного OF-коммутатора каждого ЦОД. Это обеспечивается начальными правилами обработки ARP-запросов в OF-таблице с номером 0. Далее будем рассматривать только ЦОД2, т.к. в ЦОД3 события будут происходить аналогично за тем лишь исключением, что широковещательный ARP-запрос к server будет отброшен в локальной сети ЦОД3 в силу того, что на него никто не ответит. OF-коммутатор в соответствии с таблицей 0 отправляет распакованный GRE-трафик на обработку в таблицу с номером 2.
[257]10. Дальнейшие шаги полностью совпадают с шагами 7-11 схемы без балансировки нагрузки.
[258]11. В результате на OF-коммутатор ЦОД1 придет ARP-ответ от сервера server.
[259]12. Дальнейшие шаги почти полностью повторяют шаги 12-14 схемы без балансировки нагрузки. Отличие заключается только в том, что ARP-ответ после попадания в таблицу 1 коммутатора ЦОД2 также проходит описанную процедуру балансировки.
[260]Имеют значение настройки каждого криптографического маршрутизатора. В каждом ЦОД сетевые настройки криптографических маршрутизаторов со стороны локальной сети идентичны. Список адресов доступа на криптографических маршрутизаторах также идентичен. Фактически, в настройках указывается только один адрес доступа - локальная точка создания GRE-туннеля. Так, для криптомаршрутизаторов ЦОД1 этот адрес принят 172.16.101.2.
[261]Дополнительно к изложенному выше алгоритму рассмотрим процесс формирования метрик, на основании которых происходит балансировка трафика на криптомаршрутизаторы.
[262]1. Каждую секунду в течение 15 секунд специальный процесс, запущенный на контроллере, при помощи протокола SNMP опрашивает загрузку процессоров всех криптомаршрутизаторов, на которые происходит балансировка трафика.
[263]2. По истечении 15 секунд сбор статистики временно прекращается, и вычисляется средняя загрузка процессора каждого криптомаршрутизатора за указанный промежуток времени. Обозначим ее Li, где i - номер криптомаршрутизатора. Данный параметр будет измеряться в процентах. Если криптомаршрутизатор содержит несколько процессоров, то вычисляется средняя загрузка всех процессоров криптомаршрутизатора.
[264]3. Для каждого криптомаршрутизатора вычисляется метрика по формуле:
[266]Получившееся число округляется до большего целого числа. Заметим, что при вычислении метрики не используется загрузка оперативной памяти криптомаршрутизаторов, поскольку она не является критичным параметром работы данных устройств в контексте алгоритма.
[267]4. Далее на контроллере для каждого балансирующего трафик OF-коммутатора формируется массив (далее массив портов), в котором каждый порт коммутатора, ведущий к соответствующему криптомаршрутизатору, повторяется столько раз, сколько метрика М, данного криптомаршрутизатора.
[268]5. После того, как массив сформирован, для каждого нового потока на контроллере происходит случайный выбор элемента массива, которым, как уже упоминалось, является порт коммутатора, ведущий к соответствующему криптомаршрутизатору. Также, сразу после того, как массивы портов для всех коммутаторов сформированы, описанный процесс генерации метрик запускается заново с пункта 1.
[269]При объединении нескольких ЦОД, как уже говорилось ранее, требуется обеспечить миграцию хоста из одного ЦОД в другой с сохранением возможности установления с ним соединения других хостов. Описанная схема балансировки учитывает такую миграцию, что обеспечивается использованием таймаутов неактивности в OpenFlow-правилах.
[270]Так в таблицах 0 и 2 правила выставляются с указанием таймаута неактивности (idle_timeout). Если хост мигрирует в другой ЦОД, то трафик перестает приходить на локальный OF-коммутатор ЦОД, из которого мигрировал узел. В итоге, на коммутаторе в другом ЦОД также не будет входящего трафика в сторону мигрировавшего узла, поэтому неактуальные правила после истечения таймаута неактивности будут удалены как на локальном OF-коммутаторе, так и на OF-коммутаторах других ЦОД.
[271]После описанного выше удаления правил в таблицах при поступлении на какой-либо OF-коммутатор нового трафика, идущего в сторону мигрировавшего узла коммутатор обратится к контроллеру, который даст указания рассылать трафик широковещательно во все туннели. В результате, трафик дойдет до мигрировавшего узла, и на всех OF-коммутаторах будут установлены новые правила обработки входящих пакетов согласно описанным выше алгоритмам.
