Инструментальные средства моделирования методов доступа в локальных сетях

Розглядаються архітектура, алгоритми роботи та характеристики функціонування програмного комплексу для дослідження методів доступу, реалізованих у локальних мережах комп'ю¬терів. Відмінною рисою цього комплексу є універсальна повнота засобів моделювання. Розроблений інструментальний комплекс мо...

Full description

Saved in:

Bibliographic Details
Date:	2008
Main Author:	Алишов, Н.И.
Format:	Article
Language:	Ukrainian
Published:	Інститут програмних систем НАН України 2008
Subjects:	Локальні мережі
Online Access:	https://nasplib.isofts.kiev.ua/handle/123456789/324
Tags:	Add Tag No Tags, Be the first to tag this record!
Journal Title:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Cite this:	Инструментальные средства моделирования методов доступа в локальных сетях / Н.И. Алишов // Пробл. програмув. — 2008. — N 1. — С. 37-50. — Бібліогр.: 12 назв. — рос.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine

_version_	1860270189091749888
author	Алишов, Н.И.
author_facet	Алишов, Н.И.
citation_txt	Инструментальные средства моделирования методов доступа в локальных сетях / Н.И. Алишов // Пробл. програмув. — 2008. — N 1. — С. 37-50. — Бібліогр.: 12 назв. — рос.
collection	DSpace DC
description	Розглядаються архітектура, алгоритми роботи та характеристики функціонування програмного комплексу для дослідження методів доступу, реалізованих у локальних мережах комп'ю¬терів. Відмінною рисою цього комплексу є універсальна повнота засобів моделювання. Розроблений інструментальний комплекс може служити також для статистичного аналізу мережевих трафіків, моделювання алгоритмів доступу в канал і проектування мережевих структур із спільним поділюваним каналом. Рассматриваются архитектура, алгоритмы работы и характеристики функционирования программного комплекса для исследования методов доступа, реализуемых в локальных сетях компьютеров. Его отличительной особенностью является универсальная полнота средств моделирования. Разработанный инструментальный комплекс может служить также для статистического анализа сетевых трафиков, моделирования алгоритмов доступа в канал и проектирования сетевых структур с общим разделяемым каналом. Considered Architecture, algorithms of work and functioning characteristics of programmatic complex for research of access methods, that implemented in local computers networks. Distinctive feature of proposed complex is universal design facilities plenitude. The developed instrumental complex can serve also for the statistical analysis of network traffic, designs of channel access algorithms and planning of network structures with the sheared channel.
first_indexed	2025-12-07T19:05:44Z
format	Article
fulltext	Локальні мережі 37 УДК 004.732 Н.И. Алишов ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА МОДЕЛИРОВАНИЯ МЕТОДОВ ДОСТУПА В ЛОКАЛЬНЫХ СЕТЯХ Рассматриваются архитектура, алгоритмы работы и характеристики функционирования программного комплекса для исследования методов доступа, реализуемых в локальных сетях компьютеров. Его отли- чительной особенностью является универсальная полнота средств моделирования. Разработанный ин- струментальный комплекс может служить также для статистического анализа сетевых трафиков, моде- лирования алгоритмов доступа в канал и проектирования сетевых структур с общим разделяемым каналом. Введение В Институте кибернетики им. В.М. Глушкова НАН Украины разработана тех- нология универсального множественного доступа в распределенных системах для повышения эффективной производитель- ности на канальном уровне, а также для динамической оптимизации взаимодейст- вия узлов локальной сети. Основу данной технологии составляет адаптивный стеко- вый алгоритм ANIO, который является надстройкой над классическим методом доступа CSMA/CD. Благодаря данному не требуется разработка новой элементной базы, что позволяет реализовать предло- женный метод в существующих локальных сетях. Его реализация предполагает нали- чие в каждом узле сети унифицированного стекового механизма, который использу- ется для улучшения характеристик дисци- плины обслуживания стохастических за- просов. Универсальная полнота предло- женных алгоритмов позволяет реализовать практически любой протокол взаимодей- ствия узлов локальной сети на канальном уровне [1−3]. Постановка задачи Отсутствие проблемно-ориентиро- ванной системы для исследования методов доступа канального уровня, их сравнения и оценки обусловливает разработку специа- лизированной системы для оценки произ- водительности протоколов канального уровня. Такая система позволит классифи- цировать методы доступа по их эффектив- ной производительности, облегчить их усовершенствование, а также реализовать новые, более совершенные методы доступа на канальном уровне. И прежде всего не- обходимо разработать методику проведе- ния экспериментов, определить критерии оценки эффективности протокола, разра- ботать программную реализацию прото- кола (сетевую службу, драйвер), подобрать или разработать средства сбора и анализа результатов, спроектировать общую структуру операционной среды для прове- дения экспериментов. Состояние проблемы Для исследования сетевого трафика обычно используются сетевые анализа- торы (Network Sniffers) типа Tcpdump, WinDump, Ethereal и т.п. [4]. Как правило, анализаторы являются частью более ши- рокой категории аппаратного и программ- ного обеспечения, предназначенного для мониторинга сети и позволяющего адми- нистраторам контролировать свои локаль- ные и корпоративные сетевые службы и сетевой трафик. Существуют также инст- рументальные средства проектирования компьютерных сетей, позволяющие оце- нивать проектные решения, моделировать различные режимы функционирования сетей и т.д.. Наиболее известные среди них − ComNet, NetMarker XA, OpNet и др. [5]. Однако перечисленные системы не позво- ляют решать поставленные в данной ра- боте задачи должным образом, поэтому необходимо разработать такие инструмен- тальные средства, которые, с одной сто- роны, обладают функциями сетевых ана- лизаторов, а с другой − позволяют моде- лировать и проектировать локальные сети с новыми протоколами организации взаи- модействия сетевых ресурсов. Методы и алгоритмы решения задачи Локальні мережі 38 Алгоритм ANIO является концеп- цией множественного доступа в канал пе- редачи данных, основанной на исключе- нии арбитражных и случайных методов регулирования после установления логико- виртуального соединения. Чтобы исследо- вать эффективность функционирования данного алгоритма в операционной среде, была разработана его программная модель для проведения экспериментов. Про- граммно стековый механизм реализован как отдельный класс. Разработано про- граммное обеспечение, позволяющее вне- дрить данного механизма в операционную среду, организовать сохранение статисти- ческой информации в LOG-файлах, подоб- рать средства оценки эффективной произ- водительности локальной сети и промоде- лировать различные методы доступа в ка- нал [6, 7]. Программная реализация стека ANIO предполагает получение в реальном масштабе времени МАС-адреса узла, осу- ществившего передачу. В результате ра- боты стек должен выдавать информацию о том, что наступила очередь передачи па- кета; это необходимо для реализации дос- тупа к каналу по данному алгоритму. Для нормальной работы стек должен поддер- живать три типа операций (табл. 1): добав- ление нового элемента в стек, вращение стека в процессе формирования очереди и удаление элемента из стека. Алгоритм должен поддерживать следующие функции работы со стеком: инициализация стека, добавление нового элемента, сравнение элементов, поиск эле- мента, удаление элемента, сдвиг очереди, активный и пассивный режим работы, обработку наступления тайм-аута. Псевдо- программная модель упрощенного прин- ципа работы стекового механизма пока- зана на рис. 1. В табл. 2 приведены схемы форми- рования и соответствующие алгоритмы стековых операций. Описание общей структуры алго- ритма ANIO. Работа алгоритма начинается в момент получения МАС-адреса или сиг- нала тайм-аута (рис. 2). Если тайм-аут на- ступил в активном режиме, то алгоритм переходит в пассивный режим. При нас- туплении тайм-аута в пассивном режиме удаляется второй элемент стека (МАС-ад- рес узла, пропустившего передачу). Как только получен МАС-адрес, он сразу добавляется в стек в качестве нового элемента, счетчик (count) увеличивается на единицу. Затем выполняется поиск дубли- катов, новый элемент стека сравнивается с каждым элементом стека. В результате будет получен указатель (pAnioP) на дуб- ликат и номер (Position) элемента стека. Position = 0 – дубликаты не обнару- жены, новый МАС-адрес; Таблица 1. Основные операции управления стеком Действия Операция Причина Активный Пассивный Режим Добавление Новый узел начал передачу Добавить новый элемент в конец очереди Добавить новый элемент в конец очереди Начальный режим Добавить новый элемент в конец очереди Добавить новый элемент в конец очереди МАС Удалить 1-й эле- мент Удалить 2-й эле- мент Сдвиг Очередной узел совершил пере- дачу MyMAC Переход из ак- тивного режима в пассивный Переход из пас- сивного режима в активный Стационар- ный режим Ошибка Узел стоит в очереди, но начал пере- дачу раньше времени Добавить новый элемент в конец очереди Удалить N-й эле- мент Добавить новый элемент в конец очереди Удалить N-й эле- мент Сбой MAC Удалить 1-й эле- мент Удалить 2-й эле- мент У д ал ен и е Тайм-аут Очередной узел пропустил пере- дачу MyMAC Переход из ак- тивного режима в пассивный Переход из пас- сивного режима в активный Рабочий режим Локальні мережі 39 Position = 1 – новый элемент pAnioNew совпадает с текущим pAnioCur; очередной узел передал пакет в сеть, необ- ходимо удалить дубликат элемента из позиции 1. Если до этого был пассивный ре- жим и pAnioNew совпадает с локальным адресом MyMAC, значит локальный узел возобновил обмен данными и перешел в активный режим. Position = 2 – новый элемент pAnioNew совпадает с pAnioCur – >next; очередной узел передал пакет в сеть, необ- ходимо удалить дубликат элемента из позиции 2. Position = n – произошел сбой, узел поспешил с передачей пакета, необходимо удалить дубликат элемента из позиции n. После завершения операций со сте- ком нужно обеспечить движение очереди, т.е. перейти к следующему элементу стека. Чтобы определить наступление очереди передачи для локального узла, необходимо сравнить pAnioCur и MyMAC; и, если они совпадают, выдать сигнал о разрешении передачи пакета в сеть. Функция анализа адресов в качестве параметра получает МАС-адрес узла, ко- торый в данный момент отправил в сеть пакет. Если вместо МАС-адреса было пе- редано значение NULL, это значит, что произошел тайм-аут. В результате своего выполнения функция возвращает значение логического типа BOOLEAN: TRUE – на- ступила очередь передачи пакета в сеть, FALSE – очередь не наступила. Когда алгоритм находится в пас- сивном режиме, функция анализа состоя- ния локальной сети все время возвращает значение TRUE. При этом ведётся стек, но без участия локального узла: локальный узел имеет право в любой момент возобно- вить передачу. К основным функциям алгоритма ANIO прежде всего следует отнести: веде- ние списка очереди по алгоритму, пассив- ный мониторинг сетевых пакетов (на сете- вом либо на более высоком уровне), пас- сивный мониторинг доступа к сетевым системным библиотекам (DLL) и сетевым сервисам, активный мониторинг сетевых пакетов, т. е. мониторинг и задержка исхо- дящих пакетов для ожидания очереди (на более высоком уровне − мониторинг и фильтрация запросов к сетевым систем- ным DLL и сетевым сервисам) [8]. Комби- нируя перечисленные функции, можно по N=4 MAC N=2 N=3 N=1 N=Count -1 Count Position=N pAnioP pAnioCur MyMAC 1-й pAnioNew Position pAnioP У д а л е н и е э л е м е н т а Сравнение элементов разрешение Ведение очереди 2-й 3-й 4-й N-й П о и ск д уб л и ка то в N=0 N=Count Рис. 1. Упрощенный принцип работы стекового алгоритма Локальні мережі 40 Таблица 2. Алгоритмы реализации стековых операций Стек Алгоритм И н и ц и ал и за ц и я 1 M yM A C p A n io C u r p A n io N e w C o u n t = 1 MyMAC ? локальный МАС-адрес pAnioCur = pAnioNew; pAnioCur– >next = pAnioCur; pAnioCur– >prev = pAnioCur; pAnioNew– >MAC = MyMAC; Count = 1; Д о б ав л ен и е 1 M yM A C 2 p A n io C u r C o u n t = 2 0 N e w M A C p A n io N e w 1 M yM A C 2 3 p A n io C u r C o u n t = 3 Count – количество элементов в стеке МАС – МАС-адрес узла, передавшего в данный момент пакет в сеть pAnioNew– > prev = pAnioCur– > prev; pAnioCur– > prev– >next = pAnioNew; pAnioCur– > prev = pAnioNew; pAnioNew– > next = pAnioCur; pAnioNew– > MAC = MAC; Count++; П о и ск 1 MyMAC pAnioCur 2 03 pAnioP Position = 4 Count = 5 4 prev prevprevprev prev nextnextnextnext next Сравнение МАС адресов pAnioP Position = 3 pAnioP Position = 2pAnioP Position = 1 pAnioP Position = 0 MAC pAnioNew Position – номер позиции в стеке pAnioP – позиция в стеке while (!pAnioP == pAnioNew) { Position--; pAnioP = pAnioP – > prev;} Position = 1 – pAnioCur ? очередной элемент в активном режиме Position = 2 – pAnioCur –> next ? очередной элемент в пассивном режиме Position = (3 .. Count-1) ? МАС-адрес одного из узлов, ожидающего своей очереди передачи Position = (0 и Count) – pAnioNEW ? новый элемент стека У д ал ен и е 1 MyMAC CURR 2 3 NEXT PREV Count = 4 4 1 MyMAC 2 x NEXT Count = 3 3 CURR PREV _AnioStack * PREV = pAnioS– > prev; _AnioStack * CURR = pAnioS; _AnioStack * NEXT = pAnioS– > next; NEXT– >prev = PREV; PREV– >next = NEXT; ExFreePool(CURR); Count--; pAnioS = NEXT; С д в и г 1 M y M A C 2 3 p A n io C u r C o u n t = 3 p A n io C u r - > n e x t p A n io C u r - > p r e v n e x t n e x t n e x t p r e v p r e v p r e v pAnioCur ? текущий элемент pAnioCur – > next ? следующий элемент pAnioCur – > prev ? предыдущий элемент pAnioCur = pAnioCur – > next Локальні мережі 41 лучить любой класс системы сетевого об- мена − от простого сетевого монитора для отслеживания сетевой активности прило- жения до брандмауэра с возможностями поддержки виртуальных соединений. Разработка приложений или DLL с функциями алгоритма − это самая триви- альная и обеспечивающая наименьшую гибкость его реализации. Алгоритм на уровне приложения не является прозрач- ным, в данном случае пользователь дол- жен сам решать, нужно ли его использовать. Для того чтобы данные других при- ложений могли обрабатываться приложе- нием, реализующим алгоритм передачи этих данных, должны использоваться спе- циальные механизмы межпроцессной коммуникации: копирование данных из одного адресного пространства в другое или создание области совместно исполь- зуемой памяти, видимой из обоих адрес- ных пространств [9]. Следовательно, при- ложение, данные которого необходимо пе- редавать по алгоритму ANIO, должно быть разработано для взаимодействия с прило- жением, обрабатывающим его данные, с использованием данных механизмов. Но оно не обязано знать о существовании данного алгоритма. Реализация алгоритма на уровне собственной DLL также не обеспечивает прозрачной передачи данных. Для того чтобы передачу данных приложений вы- полняла некоторая библиотека DLL, необ- ходимо, чтобы приложения были разрабо- таны так, чтобы вызывать функции из дан- ной DLL. Затем, как исполняемый код DLL проецируется на адресное пространство вызывающего процесса (с помощью неяв- ной компоновки при загрузке приложения, или явной – в период выполнения), код и данные DLL просто становятся частью процесса приложения. Таким образом, уровень приложений и собственных DLL Н а ч а л о R e c e iv e M A C M A C = = N U L L A c t iv e M o d e = = T R U E C o m p a r e M A C ( M y M A C , M A C ) A c t iv e M o d e = F A L S E P o s i t io n = 0 p A n io P = N U L L P o s i t io n = 1 p A n io P = p A n io C u r P o s it io n = 2 p A n io P = p A n io C u r - > n e x t C o m p a r e M A C (M y M A C , M A C ) A c t iv e M o d e = T R U E P o s i t io n > 0 P o s it io n = = 1 К о н е ц R e c e iv e M A C M o d e S д а н е т д а д а н е т н е т д а н е т д а н е т д а н е т M A C M y M A C – М А С а д р е с л о к а л ь н о г о а д а п т е р а C o u n t – к о л и ч е с т в о э л е м е н т о в в с т е к е A c t i v e M o d e – р е ж и м р а б о т ы д р а й в е р а T R U E – а к т и в н ы й F A L S E – п а с с и в н ы й P o s i t i o n – п о з и ц и я в с т е к е 0 – э л е м е н т о т с у т с т в у е т в с т е к е 1 – т е к у щ и й э л е м е н т n – э л е м е н т п р и с у т с т в у е т с с т е к е в п о з и ц и и n p A n i o P – у к а з а т е л ь н а э л е м е н т , к о т о р ы й с т о и т в п о з и ц и и P o s i t io n p A n i o C u r – т е к у щ и й э л е м е н т с т е к а p A n io C u r -> n e x t с л е д у ю щ и й э л е м е н т с т е к а p A n io C u r -> p r e v п р е д ы д у щ и й э л е м е н т с т е к а M o d e S – р а з р е ш е н и е н а п е р е д а ч у п а к е т а в с е т ь T R U E – п р и ш л а о ч е р е д ь д л я п е р е д а ч и п а к е т а F A L S E – р е ж и м о ж и д а н и я о ч е р е д и C o m p a r e M A C ( ) – п р о ц е д у р а с р а в н е н и я М А С а д р е с о в T R U E - р а в н ы F A L S E - н е р а в н ы S h i f t ( ) – п р о ц е д у р а у д а л я е т М А С а д р е с и з с т е к а , н а к о т о р ы й у к а з ы в а е т p A n io S M o d e S = C o m p a r e M A C (M y M A C , p A n io C u r) p A n io P = p A n io N e w -> p r e v P o s i t io n = C o u n t -1 p A n io C u r = p A n io P p A n io N e w - > p r e v = p A n io C u r - > p r e v p A n io C u r - > p r e v- > n e x t = p A n io N e w p A n io C u r - > p r e v = p A n io N e w p A n io N e w - > n e x t = p A n io C u r C o u n t + + p A n io N e w - > M A С = M A C C o m p a r e M A C ( p A n io P , p A n io N e w ) н е т P o s it io n - - ; p A n io P = p A n io P - > p r e v ; д а Д о б а в л е н и е н о в о г о э л е м е т н а в с т е к Е с л и у з е л с л о к а л ь н ы м а д р е с о м ( M y M A C ) п р о и з в е л п е р е д а ч у д а н н ы х , т о н е о б х о д и м о п е р е в е с т и д р а й в е р в а к т и в н ы й р е ж и м П о и с к М А С д р е с а в с т е к е В р е з у л ь т а т е п о и с к а п о л у ч а е м : P o s i t i o n – п о з и ц и я в с т е к е p A n i o P – у к а з а т е л ь н а э л е м е н т У д а л е н и е н а й д е н н о г о э л е м е н т а и з с т е к а Е с л и о н н е я в л я е т с я н о в ы м , е д и н с т в е н н ы м и н е с т о и т в 0 - й п о з и ц и и В с л у ч а е , е с л и э л е м е н т б ы л п е р в ы м в о ч е р е д и ( п е р е д а ч а п а к е т а в с в о ю о ч е р е д ь ) , п р о и з в о д и м п е р е х о д к с л е д у ю щ е м у э л е м е н т у с т е к а ( п р о д в и ж е н и е о ч е р е д и Е с л и п р о и з о ш е л т а й м а у т , т о з н а ч е н и е М А С а д р е с а о т с у т с т в у е т S h i f t ( p A n io S ) О п р е д е л е н и е р е ж и м а р а з р е ш е н и я п е р е д а ч и п а к е т а В п а с с и в н о м р е ж и м е п е р е д а ч а п а к е т о в н е о г р а н и ч е н а В а к т и в н о м р е ж и м е п е р е д а ч а р а з р е ш е н а , в с л у ч а е н а с т у п л е н и я о ч е р е д и К о г д а п о с е т и п е р е д а е т с я п а к е т , а л г о р и т м п о л у ч а е т М А С а д р е с о т п р а в и т е л я п а к е т а , д л я о р г а н и з а ц и и в е д е н и я о ч е р е д и Е с л и т а й м а у т п р о и з о ш е л в п а с с и в н о м р е ж и м е , т о н е о б х о д и м о у д а л и т ь и з с т е к а 2 -й э л е м е н т (М А С а д р е с у з л а , п р о п у с т и в ш е г о п е р е д а ч у ) , н е у д а л я т ь 1 -й э л е м е н т в п а с с и в н о м р е ж и м е ( M y M A C ) Е с л и 1 -й э л е м е н т э т о л о к а л ь н ы й М А С а д р е с ( M y M A C ), т о у д а л я т ь е г о н е с л е д у е т . Н у ж н о п р о с т о п е р е в е с т и д р а й в е р в п а с с и в н ы й р е ж и м В о с т а л ь н ы х с л у ч а я х у д а л и т ь 1 - й э л е м е н т и з с т е к а Рис. 2. Блок-схема алгоритма ANIO Локальні мережі 42 не имеет всех возможностей по реализации функций алгоритма. Интерфейсы API, пре- доставляемые операционной системой (ОС) приложениям и DLL, не позволяют им выполнять пассивный или активный мониторинг сетевых пакетов или контро- лировать доступ к сетевым системным DLL и сетевым сервисам. Только лишь во взаимодействии с собственным драйвером приложение может реализовать алгоритм, причем в некоторых случаях приходит- ся использовать недокументированные методы. Возможности реализации алгоритма на уровне ядра ОС Сетевые компоненты, исполняю- щиеся в привилегированном режиме − режиме ядра, являются драйверами. Пре- жде чем перейти к дальнейшему рассмот- рению сетевой архитектуры Windows NT, позволяющая как и куда встраивать мо- дули алгоритма на уровне ядра, необхо- димо вспомнить механизм драйверов- фильтров, который может использоваться в качестве средства реализации алгоритма на любом уровне в стеке драйверов. Один из методов расширения воз- можностей системы ввода/вывода − разра- ботка и применение драйверов-фильтров (рис. 3). Перехватив запрос, драйвер- фильтр либо расширяет, либо замещает функциональность, обеспечиваемую пер- воначальным получателем запроса. При этом драйвер-фильтр использует либо сер- висы драйвера, которому изначально предназначался запрос, либо сервисы дру- гих программных модулей уровня ядра для обеспечения дополнительной функцио- нальности. Драйверы-фильтры могут встраиваться в любое место в стеке драй- веров, их может быть несколько, в том числе расположенных подряд. Драйвер- фильтр обычно исследует, модифицирует, завершает или передает дальше получен- ный пакет. На всех уровнях, которые будут обсуждаться в дальнейшем, возможны реализация и применение драйверов- фильтров. Реализация алгоритма на уровне транспортного драйвера Транспортные драйверы являются, фактически, стандартными драйверами промежуточного уровня и реализуют в своей верхней части стандартный интер- фейс, соответ-ствующий TDI-специфика- ции. Этот интерфейс в основном базиру- ется на получении и обработке пакетов IRP_MJ_INTERNAL_DEVICE_CONTROL, содержащих различные значения кон- трольных кодов TDI_XXX, которые опре- деляются TDI-спецификацией. В нижней части TDI драйвер взаимодействует с NDIS-библиотекой. Разработка драйверов транспорта хорошо документирована в Windows NT DDK (глава Network drivers, раздел Intermediate NDIS drivers and TDI drivers). Возможна реализация драйвера- фильтра, который будет присоединяться к объектам-устройствам, создаваемым драй- вером транспорта, например, к объектам- устройствам \Device\Tcp и \Device\Udp, создаваемым драйвером транспорта TCP/IP. Учитывая, что драйвер транспорта должен предоставлять единый интерфейс, облегчается задача его разработки. Про- П а к е т и з с е т и П а к е т в с е т ь д и с к Л О Г з а п и с и с е т ь О п е р а ц и о н н а я с и с т е м а Д р а й в е р - ф и л ь т р Рис. 3. Входящие и исходящие данные драйвера-фильтра Локальні мережі 43 цесс происходит с помощью вызова драй- вером транспорта функций, указатели на которые передаются TDI-клиентом драй- веру транспорта в самом начале сетевых операций в пакете IRP_MJ_INTER- NAL_DEVICE_ CONTROL с контрольным кодом TDI_SET_ EVENTJHANDLER, и ре- гистрируются драйвером транспорта. TDI- клиент вполне может использовать подоб- ный механизм функций обратного вызова в качестве альтернативы обычным пакетам запросов к транспорту с контрольными кодами TDI_XXX. Но когда драйвер транс- порта вызывает подобную функцию, он может передать TDI-клиенту в качестве параметров лишь ограниченное количе- ство данных. И тогда драйвер-фильтр, присоединенный к драйверу транспорта, не получит возможности проконтролиро- вать эти данные. Подобное свойство расширения возможностей взаимодействия клиента с определенным драйвером транспорта при- водит к частичной закрытости интерфейса между ними. В результате чего затрудня- ется разработка драйвера-фильтра, при- соединяемого к транспортному драйверу. При этом сохраняется возможность разра- ботки собственного драйвера транспорта DDK, который реализует требуемые функ- ции алгоритма. Реализация алгоритма на уровне сете- вого драйвера промежуточного уровня, поддерживающего интерфейс NDIS Разработка NDIS-драйверов проме- жуточного уровня − один из хорошо доку- ментированных механизмов расширения возможностей системы ввода/вывода ОС Windows NT. Типичные варианты реализа- ции промежуточного драйвера показаны на рис. 4. Промежуточный драйвер выгля- дит для драйвера транспорта как драйвер виртуальной сетевой карты. Используя ме- ханизм привязок, можно все транспорты привязать снизу к требуемому промежу- точному драйверу, который таким образом получит возможность контролировать все пакеты, идущие в/из сети. Это позволит ему реализовать такие функции защиты, как преобразование форматов пакетов, преобразование пользовательских данных в пакетах, фильтрация пакетов, регистра- ция пакетов, контроль содержимого пакетов. Благодаря таким правилам взаимо- действия посредством использования биб- лиотеки NDIS, встраивание промежуточ- ного драйвера между драйвером транс- порта, поддерживающим интерфейс NDIS в нижней части, и NDIS-драйвером сетевой карты не приводит к нарушению работы стека сетевых драйверов. N I C М и н и п о р т М и н и п о р т П р о т о к о л п р о т о к о л Д р а й в е р -ф и л ь т р Д р а й в е р т р а н с п о р т а Д р а й в е р N IC N D I S Рис. 4. Типы промежуточных драйверов Промежуточный драйвер, располо- женный над драйвером сетевой карты, фактически эквивалентен драйвер- фильтру, присоединенному к драйверу фи- зического устройства. Только последний встраивается в цепь драйверов, взаимодей- ствующих посредством пакетов IRP. Чтобы контролировать трафик на уровне драйверов, не обязательно заменять их собственными аналогами со встроенными функциями алгоритма ANIO можно соз- дать промежуточный драйвер, реализую- щий функции алгоритма ANIO и располо- жить его выше или ниже этих драйверов. Промежуточные драйверы являются неотъемлемой частью многих систем за- щиты сетевых ресурсов, реализующих пассивный мониторинг сетевых пакетов. Примером такой системы безопасности может служить программный анализатор сетевого трафика Microsoft Network Локальні мережі 44 Monitor. Подобные драйверы являются ча- стью многих систем безопасности, выпол- няющих фильтрацию и шифрование сете- вого трафика, например Guardian Windows NT Firewall. Реализация алгоритма на уровне драйверов сетевых устройств Реализация алгоритма на уровне драйверов сетевых карт (рис. 5), зависит от разработанного драйвера устройства в со- ответствии со стандартом NDIS, т. е. это NDIS-драйвер сетевой карты локальной или глобальной сети, или это драйвер уст- ройства, управляемый пакетами IRP. В первом случае лучше всего перейти к реа- лизации промежуточного драйвера, а во втором − к реализации драйвер-фильтра. На этом уровне возможна также реализа- ция собственного драйвера устройства со встроенными функциями алгоритма. Раз- работка собственных драйверов сетевых карт для глобальных и локальных сетей, поддерживаемых интерфейсом NDIS, хо- рошо документирована в DDK. Сравнительный анализ способов реализации алгоритма ANIO Анализ реализаций алгоритма вы- полним только для способов, имеющих возможность встраивания модуля алго- ритма и расширения своей функциональ- ности на данном уровне. Относительно следующих факторов: объем контроли- руемых данных, сложность реализации, прозрачность алгоритма, возможности, предоставляемые ОС коду алгоритма (табл. 3). При оценке объема контролируе- мых данных необходимо определить, ка- кие данные проходят через алгоритм и, следовательно, могут им контролироваться и обрабатываться [10]. Сложность реализации отражает степень ее документированности и слож- ность отладки. Данный фактор оценива- ется по трехбалльной шкале: низкая, сред- няя, высокая. Низкая сложность означает, что при разработке средства защиты ис- пользуются хорошо документированные интерфейсы и доступные средства от- ладки; средняя, − что используются доку- Пакет из сети Приемник Пакет в ОС Поток ANIO Пакет в сеть Поток LOG Анализ управляющих пакетов Новое время timeout Вкл/выкл запись в LOG файл Вкл/выкл алгоритм ANIO TimeOut timer Событие «сохранение в лог файл» и н ф о р м а ц и о н н а я за п и сь Формирование информационной записи MAC SIZE TIME 6 2 8 m записей Процедура записи в файл У п р а в л я ю щ а я з а п и с ь Формирование управляющей записи FLAG CTRL TIME 7 1 8 в ф а й л Буфер информационных записей 1 2 …. m М А С Событие «прием пакета из сети» Получение адреса отправителя из пакета МАС 6 Отправка одного пакетаАлгоритм управления ANIO Стек ANIO Пакет П а ке т пул 2 …. 1 0 Передатчик Событие «Инициализация ANIO» M yМ А С Получение локального МАС адреса Пакет из ОС Создание файла Anio.log Закрытие файла Anio.log Блокировка пакетов резрешениеМАС Рис. 5. Принцип работы драйвера Локальні мережі 45 ментированные интерфейсы, но отладка средства защиты уже не столь проста, по- скольку данное средство реализуется в ре- жиме ядра, а следовательно, большинство ошибок в нем могут привести к «падению» ОС и, кроме того, при отладке приходится иметь дело с ассемблерным кодом; высо- кая, – что проблемы с отладкой усугубля- ются частичным или полным отсутствием документации для разработки. Прозрачность алгоритма опреде- ляет, должен ли пользователь предпринять какие-либо действия для того, чтобы пере- дать свои данные с помощью данного алгоритма. Возможности, предоставляемые ОС коду алгоритма В зависимости от того, исполняется ли алгоритм в режиме пользователя или в привилегированном режиме − режиме яд- ра, ему предоставляются различные возмо- жности. В режиме ядра разрешено выпол- нение всех команд процессора и доступна системная область памяти и оборудование, тогда как в пользовательском режиме не- которые команды запрещены, а системные области памяти недоступны [11]. Выбор конкретного способа реали- зации алгоритма зависит от первоначально предъявляемых к данной системе требова- ний. Из вышеприведенного анализа сете- вой архитектуры и сравнительной характе- ристики различных способов реализации средств защиты сетевой информации сле- дует, что реализации на уровне промежу- точных драйверов и драйверов сетевых устройств наиболее предпочтительны (даже с учетом фактора реализации допол- нительной функциональности, не свойст- венной данному уровню относительно модели OSI, т. е, по сути дела, разработки некоторых функций драйвера транспорта) (табл. 4). ОС Windows NT позволяет внедрять разработанные драйверы в стек сетевых драйверов без необходимости модифика- ции существующих компонентов. Они мо- гут взаимодействовать с компонентами исполнительной системы, ядром и HAL, получая тем самым максимальные воз- можности для реализации функций алго- ритма. Данные драйверы способны кон- тролировать весь сетевой трафик, через них будут проходить данные всех прило- жений, исполняющихся в системе [12]. В результате исследования сетевой архитектуры можно сделать вывод, что не на всех ее уровнях операционная система Таблица 3. Сравнительный анализ возможностей реализации алгоритма Реализация алгоритма Объем контролируемых данных Сложность реализации Прозрачность Возможности, предоставляемые ОС Уровень OSI Приложение Только данные самого приложения Низкая - Минимальные 7 Собственная DLL Данные приложений, использующих эту DLL Низкая - Минимальные 6 Транспортный драйвер Данные приложений, использующих этот транспорт, + данные приложений, взаимо- действующих с другим транспортом напрямую Высокая + Максимальные 3 Промежуточный драйвер Данные приложений, использующих транспорты, привязанные снизу к этому промежуточному драйверу, + данные приложений, взаимодейст-вующих с промежуточным драйвером напрямую Средняя + Максимальные 2 Драйвер сетевого устройства Данные всех приложений Средняя + Максимальные 2 Аппаратная Весь трафик узла Высокая + Максимальные 1 Локальні мережі 46 Windows NT позволяет расширять свои возможности и, в частности, возможности по реализации управления передачей дан- ных по сети. Зачастую, если даже сетевая архитектура предоставляет возможность расширения своей функциональности, Microsoft ее не всегда документирует. Наилучшим вариантом расширения функциональности ОС является реализа- ция алгоритмов в виде промежуточных драйверов, располагающихся между драй- верами транспортов и драйверами сетевых карт. Но в этом случае может возникнуть проблема корректной работы такого драй- вера в сети, поскольку ОС позволяет встраивать собственные модули управле- ния на нижних уровнях взаимодействия сетевых узлов. Для реализации алгоритма на про- граммном уровне необходимо обеспечить мониторинг трафика в сегменте с общим доступом к среде передачи данных, орга- низовать управление доступом к среде пе- редачи данных, разработать и внедрить программную реализацию стекового алго- ритма ANIO, организовать сбор статистики в файл и разработать методику анализа для оценки производительности сети. С учётом вышеизложенного для разрабатываемой программы устанавли- ваются такие требования: • программа должна отслеживать прием и передачу пакетов, приходящих к драйверу сетевого адаптера как от пользо- вательских процессов, так и от компонент ОС, и сохранять передаваемые данные в LOG-файле; • от программы не требуется определять протоколы, однако при анализе LOG-файлов должно быть известно, кто передавал и принимал пакет, в какой мо- мент времени и какого размера; • на основе полученной информа- ции программа должна управлять переда- чей пакетов в сеть в соответствии с алго- ритмом; • пользователь должен иметь воз- можность управления программой (ло- кально и удаленно), сохранять настройки файлов для последующей автоматической перенастройки программы; • программа не должна приводить к сбоям в работе ОС или к существенным задержкам ввода/вывода. Поток LOG. Необходимо организо- вать протоколирование данных, обрабаты- вающие в драйвере на высоких приорите- тах IRQL, а функции ZwCreateFile и ZwWriteFile должны выполняться только на уровне PASSIVE_LEVEL. Подобная за- дача достаточно легко решается, если вы- сокоприоритетный программный код бу- дет помещать записи в промежуточный буфер, который будет сброшен на диск программным потоком, выполняющимся на подходящем для этого уровне PASSIVE_LEVEL. Системные программные потоки создаются вызовом PsCreate- SystemThread, а завершиться они должны самостоятельно − выполнением вызова PsTerminateSystemThread. Поэтому сетевая служба порождает поток LOG, работаю- щий на уровне PASSIVE_LEVEL и выпол- няющий все необходимые действия по сбору статистической информации. Таблица 4. Зависимость способа реализации алгоритма от предъявляемых к нему требований Требования к системе безопасности Рекомендуемый уровень реализации средства защиты Необходимо реализовать программу, обеспечи- вающую пассивный мониторинг компьютерной сети Реализация на уровне приложения и DLL Необходимо обеспечить активный моніторинг и управление трафиком Реализация на уровне драйвера ndis.sys, драйвера транспорта, промежуточного драйвера или драйвера устройства Локальні мережі 47 Структура информационной записи LOG-файла: struct LogFile // Основная структура { UCHARMAC[6]; // МАС- адрес отправителя па- кета short Size; // Размер пакета //Время прибытия пакета LARGE_INTEGER Time; }; struct LogFileEх // Дополнитель- ная структура { UCHAR MAC[6]; // МАС-ад- рес получателя short Flags; // Флаги LONG SetTimeOut; // Уста- новка времени ожидания тайм-аута //Количество тайм-аутов ULONG CountTimeOut; }; Поток ANIO. Чтобы не блокировать работой алгоритма процесс приема паке- тов из сети, управление стеком ANIO, не- обходимо организовать в отдельном по- токе. Сетевая служба порождает поток ANIO, создает стек, вносит туда локальный МАС-адрес. Затем в замкнутом цикле вы- полняются такие действия: • перевод потока в спящий режим; • ожидание события приема пакета (или прекращение ожидания по тайм-ауту); • определение причины, по кото- рым поток был пробуждён (тайм-аут, прием пакета из сети, завершение работы потока); • в случае получения пакета из сети производится оповещение алгоритма ANIO и передача указателя на МАС-адрес (если наступил тайм-аут, то в качестве указателя на МАС- адрес алгоритму передается зна- чение NULL). Алгоритм ANIO определяет момент наступления очереди передачи пакета в сеть (возвращает значение TRUE, если пора передать пакет); в данном случае за- пускается процедура FreeSend, пропус- кающая в сеть один пакет. При необходи- мости завершить поток обеспечивается его выход из замкнутого цикла, удаляется стек, завершается работа потока. Рассматриваемое программное обеспечение (ПО) работает корректно только под Windows 2000 Profesional, по- скольку разрабатывалось и тестировалось только под управлением данной ОС. Ис- пользована возможность работы с вирту- альными машинами на основе VMware (рис. 6). С помощью Dbgview.exe можно наблюдать за работой службы и сохранять все результаты в LOG-файле. К данному ПО прилагается руководство пользователя Dbgview.chm. Алгоритм ANIO работает в отдель- ном потоке и организует вращение стека, поэтому ему необходима информация о том, кто в данный момент времени пере- Рис. 6. Работа с виртуальными машинами на основе VMware Локальні мережі 48 дает пакет. Для поддержания очереди не- обходимо запретить на некоторое время передачу очередного пакета, до наступле- ния очереди передачи. Режим TIME OUT позволяет исключить возможную блоки- ровку сетевой службы: по истечении опре- деленного промежутка времени считается, что очередной узел пропустил свою пере- дачу и будет исключен из стека. Сетевая служба является промежу- точным звеном между драйвером сетевого адаптера и стеком протоколов tcp/ip. Через нее проходят все пакеты, передающие в сеть или принимающие из сети. Данная служба может запретить или разрешить передачу в сеть любого пакета. Кроме того, она переводит адаптер в режим NDIS_PACKET_TYPE_PROMISCUOUS. Программа, соответственно, может про- сматривать все передающиеся по сети па- кеты. В результате работы появляется anio.log − файл со статистикой. Для эффективной работы алгоритма необходимо определить оптимальное время TIME OUT. При небольшом значе- нии данной величины стек будет вра- щаться слишком быстро и узлы не будут успевать передавать свои пакеты. В этом случае процессор будет загружен выпол- нением операций со стеком, а ОС может «зависнуть». Если TIME OUT слишком велик, то передача данных будет выпол- няться медленно и много узлов сможет выполнить передачу пакета вне очереди. Управление сетевой службой Сетевая служба работает на уровне ядра, поэтому не имеет интерфейса управ- ления. Но ANIO нуждается в централизо- ванном управлении. Для управления рабо- той сетевой службы разработано специ- альное программное обеспечение (прило- жение ctrlANIO.exe), позволяющее переда- вать в сеть пакеты любого содержания. Данное приложение является сниффером, потому что позволяет просматривать все пакеты, передающиеся по сети. Управле- ние выполняется с помощью пакетов оп- ределенного формата. Данное ПО исполь- зует библиотеку WinPcap, поэтому тре- бует установки WinPcap_3_х. Перед началом работы необходимо выбрать адаптер и запустить его. При этом выполняется перевод адаптера в режим PROMISCUOUS и начинается перехват па- кетов из сети, который можно прекратить, нажав кнопку СТОП. Чтобы приостано- вить вывод пакетов на экран, следует на- жать кнопку ПАУЗА. Реализована воз- можность очистки окна от ненужных паке- тов. Для удобства есть окно редактиро- вания пакета − РЕДАКТОР УПРАВ- ЛЯЮЩЕГО ПАКЕТА (рис. 7), его можно вызвать из меню или щелкнув на одном из пакетов из списка. При выборе пакета из Рис. 7. Редактор управляющего пакета Локальні мережі 49 списка его содержимое помещается в ре- дактор, затем пакет можно повторно от- править в сеть. Имеется возможность пе- редачи пакета как одиночно, так и много- численно. Многочисленную передачу можно приостановить (кнопка ПАУЗА) либо прекратить (кнопка СТОП). Выбор опции «управляющий пакет» активизирует элементы редактирования и генерацию управляющего пакета, позволяющий изменить режим работы сетевой службы ANIO: - разрешить или запретить сбор ста- тистики; - запустить или остановить алго- ритм ANIO; - выполнить установку времени TIME OUT; - указать TIME OUT; -указать, от кого и кому предназна- чен пакет. Все адаптеры в режиме PROMISCUOUS видят этот пакет и выпол- няют его команды, если установлена служба ANIO. Обработка статистики Обработка статистики осуществля- ется приложением LogANIO (рис. 8), от- крывающие файл anio.log и помещает его в базу данных base\anio.db. Если БД пуста, то необходимо загрузить данные из файла anio.log. В приложении разработан набор стандартных SQL-запросов, кроме того реализована возможность формирования собственных запросов. По результатам за- просов можно построить диаграммы, ха- рактеризующие различные свойства сете- вых протоколов доступа в канал. Заключение Разработанный программный рабо- тает в режиме ядра ОС и устанавливается как драйвер-фильтр поверх драйвера сете- вого адаптера, что позволяет управлять режимами приема, просматривать все вхо- дящие и исходящие кадры, разрешать или запрещать прием определенных кадров из сети и их передачу в сеть. Сетевой драй- вер, сетевые службы и ряд системных про- грамм интегрированы в рамках инстру- ментальных средств, позволяющих моде- лировать в реальных локальных сетях множество сетевых протоколов канального уровня на базе универсального алгоритма ANIO, с целью оптимизации характеристик функционирования существующих и вновь разрабатываемых методов доступа в ло- кальных сетях компьютеров. Рис. 8. Программное обеспечение LogANIO.exe для обработки статистики Локальні мережі 50 1. Алишов Н.И. Адаптивный стековый алго- ритм универсального множественного доступа в распределенных системах и се- тях компьютеров // УСиМ. – 2004. – № 1. – С. 59–72. 2. Алишов Н.И., Петришина О.В. Конфликты доступа в локальных вычислительных се- тях // Математичні машини і системи. – 2006. – № 4. – С. 111–123. 3. Устройство для передачи информации: А.с. 1509970 СССР, МКИ G 08 C 19/28, G 06 F 13/00 / Б.Н. Малиновский, Н.И. Алишов, А.В. Кушнарев. – № 4360107/24; Заявл. 07.01.88; Опубл. 23.09.89, Бюл. № 35. – 10 с. 4. AbdelallahElhadj H., Khelalfa H.M., Kortebi H.M. An Experimental Sniffer Detector: Snifferwall Securite des Communications sur Internet. – Proc. of SECI02, 2002. – P. 69−79. 5. Bhatt S., Fujimoto R., Ogieski A. Parallel Simulation Techniques for Large-Scale Networks // IEEE Communication Magazine. – 1998 August. – Р. 42–47. 6. Петришина О.В. Інструментальне середо- вище дослідження множинного доступу в локальних мережах // Вісті академії інженерних наук України. – 2005. – № 4(27). – С. 38–40. 7. Петришина О.В. Технология реализация универсального множественного доступа // Комп’ютерні засоби, мережі та системи. – 2006. – № 5. – С. 80–85. 8. Полный справочник по С++ / Пер. с англ. – М.: Изд. дом «Вильямс», 2004. – 800 с. 9. Шеферд Дж. Программирование на Microsoft Visual C++ .NET / Пер. с англ. – М.: Изд.-торг. дом «Русская редакция», 2003. – 928 с. 10. Oney W. Programming the Microsoft Win- dows Driver Model. – Redmond, Washington: Microsoft Press., 2002. – 675 р. 11. Программирование драйверов Windows. – М.: ООО «Бином-Пресс», 2004. – 480 с. 12. Baker A., Lozano J. The Windows 2000 De- vice Driver Book // A Guide for Programmers, Second Edition. – Prentice Hall PTR, 2000. – 480 p. Получено 17.10.2007 Об авторе: Алишов Надир Исмаил-оглы, доктор технических наук. Место работы автора: Институт кибернетики им. В.М. Глушкова НАН Украины, 03680, Киев-187, проспект Академика Глушкова, 40. Тел.: (044) 526 3427. е-mail: anio@ukrtel.com
id	nasplib_isofts_kiev_ua-123456789-324
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
issn	1727-4907
language	Ukrainian
last_indexed	2025-12-07T19:05:44Z
publishDate	2008
publisher	Інститут програмних систем НАН України
record_format	dspace
spelling	Алишов, Н.И. 2008-03-31T13:27:18Z 2008-03-31T13:27:18Z 2008 Инструментальные средства моделирования методов доступа в локальных сетях / Н.И. Алишов // Пробл. програмув. — 2008. — N 1. — С. 37-50. — Бібліогр.: 12 назв. — рос. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/324 Розглядаються архітектура, алгоритми роботи та характеристики функціонування програмного комплексу для дослідження методів доступу, реалізованих у локальних мережах комп'ю¬терів. Відмінною рисою цього комплексу є універсальна повнота засобів моделювання. Розроблений інструментальний комплекс може служити також для статистичного аналізу мережевих трафіків, моделювання алгоритмів доступу в канал і проектування мережевих структур із спільним поділюваним каналом. Рассматриваются архитектура, алгоритмы работы и характеристики функционирования программного комплекса для исследования методов доступа, реализуемых в локальных сетях компьютеров. Его отличительной особенностью является универсальная полнота средств моделирования. Разработанный инструментальный комплекс может служить также для статистического анализа сетевых трафиков, моделирования алгоритмов доступа в канал и проектирования сетевых структур с общим разделяемым каналом. Considered Architecture, algorithms of work and functioning characteristics of programmatic complex for research of access methods, that implemented in local computers networks. Distinctive feature of proposed complex is universal design facilities plenitude. The developed instrumental complex can serve also for the statistical analysis of network traffic, designs of channel access algorithms and planning of network structures with the sheared channel. uk Інститут програмних систем НАН України Локальні мережі Инструментальные средства моделирования методов доступа в локальных сетях Local networks access methods modeling toolkit Article published earlier
spellingShingle	Инструментальные средства моделирования методов доступа в локальных сетях Алишов, Н.И. Локальні мережі
title	Инструментальные средства моделирования методов доступа в локальных сетях
title_alt	Local networks access methods modeling toolkit
title_full	Инструментальные средства моделирования методов доступа в локальных сетях
title_fullStr	Инструментальные средства моделирования методов доступа в локальных сетях
title_full_unstemmed	Инструментальные средства моделирования методов доступа в локальных сетях
title_short	Инструментальные средства моделирования методов доступа в локальных сетях
title_sort	инструментальные средства моделирования методов доступа в локальных сетях
topic	Локальні мережі
topic_facet	Локальні мережі
url	https://nasplib.isofts.kiev.ua/handle/123456789/324
work_keys_str_mv	AT ališovni instrumentalʹnyesredstvamodelirovaniâmetodovdostupavlokalʹnyhsetâh AT ališovni localnetworksaccessmethodsmodelingtoolkit

Инструментальные средства моделирования методов доступа в локальных сетях

Institution

Similar Items