Размещено на http://www.allbest.ru/

Курсовой проект

Разработка средства мониторинга трафика в ЛКС



Оглавление

• Введение
• 1. Теоретическая часть
• 1.1 Движение пакетов в сети и их структура
• 1.2 Протоколы и стандарты
• 1.2.1 Межсетевой протокол IP
• 1.2.2 TCP и UDP
• 1.3 Сокеты
• 1.4 Мониторинг сети
• 2. Практическая часть
• 2.1 Постановка задачи разработки
• 2.2 Формализация требований к программному средству
• 2.3 Выбор инструмента разработки и его обоснование
• 2.4 Проектирование системы
• 2.5 Реализация системы
• 2.6 Описание функционирования программного средства
• Заключение
• Список использованной литературы
• Приложение
• трафик сеть адресация сокет
• 

Введение

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

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

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

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

Актуальность данной работы обусловлена тем, что в связи с распространением персональных компьютеров и созданием на их основе автоматизированных рабочих мест (АРМ) возросло значение локальных вычислительных сетей (ЛВС), диагностика которых, является объектом нашего исследования.

Средства мониторинга сетей, использующих ОС Windows, имеют большое значение, поскольку данная операционная система получила широкое распространение в ЛВС, а также используется в серверных фермах (Windows Server).

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

Целью данного курсового проекта является представление способа передачи данных внутри сети, а также возможные пути отслеживания передаваемых пакетов между узлами и выявления соответствия источников посылаемого трафика.

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

· Исследование метода движения трафика в сети;

· Ознакомление с IP адресацией и IP пакетами;

· Ознакомление с протоколами TCP/UDP;

· Ознакомление с понятием и функциями сокета;

· Создание программного приложения мониторинга трафика (поступления и отправки IP пакетов).

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



1. Теоретическая часть

1.1 Движение пакетов в сети и их структура

Информация в локальных сетях передается отдельными порциями, называемыми в различных источниках пакетами (packets), кадрами (frames) или блоками. Предельная длина этих пакетов строго ограничена (обычно величиной в несколько килобайт). Ограничена длина пакета и снизу (как правило, несколькими десятками байт). Выбор пакетной передачи связан с несколькими важными соображениями.

Локальная сеть должна обеспечивать качественную, прозрачную связь всем абонентам (компьютерам) сети. Важнейшим параметром является время доступа к сети (access time), которое определяется как временной интервал между моментом готовности абонента к передаче (когда ему есть, что передавать) и моментом начала этой передачи. Это время ожидания абонентом начала своей передачи. Оно не должно быть слишком большим, иначе величина реальной, интегральной скорости передачи информации между приложениями сильно уменьшится даже при высокоскоростной связи.

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

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

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

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

Рисунок 1.1. Передача пакетов в сети между двумя абонентами.

Структура и размеры пакета в каждой сети жестко определены стандартом на данную сеть и связаны с аппаратными особенностями данной сети, выбранной топологией и типом среды передачи информации. Эти параметры зависят от используемого протокола (порядка обмена информацией).

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

Чаще всего пакет содержит в себе ряд основных полей (Рисунок 1.2).



Рисунок 1.2. Типичная структура пакета.

· Стартовая комбинация битов или преамбула, которая обеспечивает предварительную настройку аппаратуры адаптера или другого сетевого устройства на прием и обработку пакета. Это поле может полностью отсутствовать или же сводиться к единственному стартовому биту.

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

· Сетевой адрес (идентификатор) передающего абонента, то есть индивидуальный номер, присвоенный каждому передающему абоненту. Этот адрес информирует принимающего абонента, откуда пришел данный пакет. Включение в пакет адреса передатчика необходимо в том случае, когда одному приемнику могут попеременно приходить пакеты от разных передатчиков.

· Служебная информация, которая может указывать на тип пакета, его номер, размер, формат, маршрут его доставки, на то, что с ним надо делать приемнику и т.д.

· Данные (поле данных) - это та информация, ради передачи которой используется пакет. В отличие от всех остальных полей пакета поле данных имеет переменную длину, которая, собственно, и определяет полную длину пакета. Существуют специальные управляющие пакеты, которые не имеют поля данных. Их можно рассматривать как сетевые команды. Пакеты, включающие поле данных, называются информационными пакетами. Управляющие пакеты могут выполнять функцию начала и конца сеанса связи, подтверждения приема информационного пакета, запроса информационного пакета и т.д.

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

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

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

1.2 Протоколы и стандарты

TCP/IP

TCP/IP - это самое используемое семейство сетевых протоколов. Его используют все узлы сети Интернет. Стек TCP/IP состоит из 3 основных протоколов: TCP (протокол управления передачей), UDP (протокол пользовательских датаграмм) и IP (межсетевой протокол).

Краеугольным камнем всей архитектуры является межсетевой протокол IP (Internet Protocol). С его помощью реализуется адресация узлов сети и доставка данных. Межсетевой протокол управляющих сообщений ICMP (Internet Control Message Protocol) предназначен для передачи диагностической информации и сообщений об ошибках в работе сети.

1.2.1 Межсетевой протокол IP

Межсетевой протокол IP специфицирован в RFC 791. Его основные характеристики:

· реализует обмен информации пакетами, которые будем называть IP-сегментами (максимальный размер IP-сегмента - 65535 байт);

· является протоколом взаимодействия без установления логического соединения;

· для адресации узлов сети используется адрес длиной 4 байта;

· обеспечивает в случае необходимости фрагментацию IP-сегментов;

· IP-сегменты имеют конечное время жизни в сети;

· не гарантирует надежность доставки IP-сегментов адресату;

· не имеет средств управления интенсивностью передачи IP-сегментов посылающей стороной (flow control);

· не гарантирует правильную последовательность IP-сегментов на принимающей стороне.

Структура IP-пакета

IP-пакет состоит из заголовка и поля данных. Заголовок, как правило, имеющий длину 20 байт, имеет следующую структуру (рисунок 1.3).

Рисунок 1.3. Структура заголовка IP-пакета.



Поле Номер версии (Version), занимающее 4 бит, указывает версию протокола IP. Сейчас повсеместно используется версия 4 (IPv4), и готовится переход на версию 6 (IPv6).

Поле Длина заголовка (IHL) IP-пакета занимает 4 бит и указывает значение длины заголовка, измеренное в 32-битовых словах. Обычно заголовок имеет длину в 20 байт (пять 32-битовых слов), но при увеличении объема служебной информации эта длина может быть увеличена за счет использования дополнительных байт в поле Опции (IP Options). Наибольший заголовок занимает 60 октетов.

Поле Тип сервиса (Type of Service) занимает один байт и задает приоритетность пакета и вид критерия выбора маршрута. Первые три бита этого поля образуют подполе приоритета пакета (Precedence), Приоритет может иметь значения от самого низкого - 0 (нормальный пакет) до самого высокого - 7 (пакет управляющей информации). Маршрутизаторы и компьютеры могут принимать во внимание приоритет пакета и обрабатывать более важные пакеты в первую очередь. Поле Тип сервиса содержит также три бита, определяющие критерий выбора маршрута. Реально выбор осуществляется между тремя альтернативами: малой задержкой, высокой достоверностью и высокой пропускной способностью. Установленный бит D (delay) говорит о том, что маршрут должен выбираться для минимизации задержки доставки данного пакета, бит Т - для максимизации пропускной способности, а бит R - для максимизации надежности доставки. Во многих сетях улучшение одного из этих параметров связано с ухудшением другого, кроме того, обработка каждого из них требует дополнительных вычислительных затрат. Поэтому редко, когда имеет смысл устанавливать одновременно хотя бы два из этих трех критериев выбора маршрута. Зарезервированные биты имеют нулевое значение.

Поле Общая длина (Total Length) занимает 2 байта и означает общую длину пакета с учетом заголовка и поля данных. Максимальная длина пакета ограничена разрядностью поля, определяющего эту величину, и составляет 65535 байт, однако в большинстве хост-компьютеров и сетей столь большие пакеты не используются. При передаче по сетям различного типа длина пакета выбирается с учетом максимальной длины пакета протокола нижнего уровня, несущего IP-пакеты. Если это кадры Ethernet, то выбираются пакеты с максимальной длиной в 1500 байт, умещающиеся в поле данных кадра Ethernet. В стандарте предусматривается, что все хосты должны быть готовы принимать пакеты вплоть до 576 байт длиной (приходят ли они целиком или по фрагментам). Хостам рекомендуется отправлять пакеты размером более чем 576 байт, только если они уверены, что принимающий хост или промежуточная сеть готовы обслуживать пакеты такого размера.

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

Поле Флаги (Flags) занимает 3 бита и содержит признаки, связанные с фрагментацией. Установленный бит DF (Do not Fragment) запрещает маршрутизатору фрагментировать данный пакет, а установленный бит MF (More Fragments) говорит о том, что данный пакет является промежуточным (не последним) фрагментом. Оставшийся бит зарезервирован.

Поле Смещение фрагмента (Fragment Offset) занимает 13 бит и задает смещение в байтах поля данных этого пакета от начала общего поля данных исходного пакета, подвергнутого фрагментации. Используется при сборке/разборке фрагментов пакетов при передачах их между сетями с различными величинами MTU. Смещение должно быть кратно 8 байт.

Поле Время жизни (Time to Live) занимает один байт и означает предельный срок, в течение которого пакет может перемещаться по сети. Время жизни данного пакета измеряется в секундах и задается источником передачи. На маршрутизаторах и в других узлах сети по истечении каждой секунды из текущего времени жизни вычитается единица; единица вычитается и в том случае, когда время задержки меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно считать равным максимальному числу узлов, которые разрешено пройти данному пакету до того, как он достигнет места назначения. Если параметр времени жизни станет нулевым до того, как пакет достигнет получателя, этот пакет будет уничтожен. Время жизни можно рассматривать как часовой механизм самоуничтожения. Значение этого поля изменяется при обработке заголовка IP-пакета.

Контрольная сумма (Header Checksum) занимает 2 байта и рассчитывается только по заголовку. Поскольку некоторые поля заголовка меняют свое значение в процессе передачи пакета по сети (например, время жизни), контрольная сумма проверяется и повторно рассчитывается при каждой обработке IP-заголовка. Контрольная сумма - 16 бит - подсчитывается как дополнение к сумме всех 16-битовых слов заголовка. При вычислении контрольной суммы значение самого поля "контрольная сумма" устанавливается в нуль. Если контрольная сумма неверна, то пакет будет отброшен, как только ошибка будет обнаружена.

Поля IP-адрес источника (Source IP Address) и IP-адрес назначения (Destination IP Address) имеют одинаковую длину - 32 бита - и одинаковую структуру.

Поле Опции (IP Options) является необязательным и используется обычно только при отладке сети. Механизм опций предоставляет функции управления, которые необходимы или просто полезны при определенных ситуациях, однако он не нужен при обычных коммуникациях. Это поле состоит из нескольких подполей, каждое из которых может быть одного из восьми предопределенных типов. В этих подполях можно указывать точный маршрут прохождения маршрутизаторов, регистрировать проходимые пакетом маршрутизаторы, помещать данные системы безопасности, а также временные отметки. Так как число подполей может быть произвольным, то в конце поля Опции должно быть добавлено несколько байт для выравнивания заголовка пакета по 32-битной границе.

Ниже приведена распечатка значений полей заголовка одного из реальных IP-пакетов, захваченных в сети Ethernet средствами анализатора протоколов Microsoft Network Monitor.

IP Version = 4 (0х4)

IP Header Length = 20 (0х14)

IP Service Type = 0 (0х0)

IP Precedence = Routine

IP ...0.... = Normal Delay

IP ....0... = Normal Throughput

IP .....0.. = Normal Reliability

IP Total Length = 54 (0х36)

IP Identification = 31746 (0x7C02)

IP Flags Summary ° 2 (0х2)

IP ....... 0 = Last fragment in datagram

IP ...... 1. = Cannot fragment datagram

IP Fragment Offset = 0 (0х0) bytes

IP Time to Live = 128 (0х80)

IP Protocol = TCP - Transmission Control

IP Checksum =0xEB86

IP Source Address = 194.85.135.75

IP Destination Address = 194.85.135.66

IP Data: Number of data bytes remaining = 34 (0х0022)

Протокол сетевого уровня IP предоставляет транспортному уровню службу ненадежной передачи данных. IP не дает гарантий относительно доставки дейтаграмм, сохранения порядка их следования и корректности информации. При перегрузке маршрутизаторов дейтаграммы могут быть потеряны, порядок их получения может отличаться от порядка отправки, и, кроме того, допускаются искажения битов (изменения значений с 0 на 1 и наоборот). Поскольку дейтаграммы являются средством передачи сегментов транспортного уровня, последний сталкивается с перечисленными проблемами.

IP адреса

IP отвечает за отправку единичных пакетов к месту их назначения. Это достигается путем связывания каждого компьютера в сети с некоторым IP адресом. Каждый IP адрес состоит из 32 бит, представленных в виде четырех десятичных чисел, разделенных точкой, каждое в диапазоне от 0 до 255. Пример IP адреса: 123.123.123.123. Пространство IP адресов разделено на сети, это сделано путем разделения 32 битов адреса на биты сети и биты хоста. Эта информация используется для распределения пакетов по местам назначения.

1.2.2 TCP и UDP

TCP и UDP для передачи данных используют протокол IP. Протокол IP отвечает за передачу пакетов в место назначения с минимальными затратами, а TCP и UDP используются для подготовки данных к отправке, путем разбиения их на пакеты.

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

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

UDP является наиболее простым протоколом для передачи пакетов данных. Он просто добавляет заголовок к данным и отсылает их по назначению, не обращая внимания на то, существует ли узел получателя и ожидает ли он данных.

UDP не гарантирует, что пакеты будут доставлены в том же порядке, в каком были отправлены. Если пакеты пересылаются между двумя сетями, используя различные пути, то они могут быть доставлены в неправильном порядке. Забота о корректности в этом случае ложится на приложения. Тем не менее, для приложений, которым важна скорость передачи, он полезен, даже несмотря на то, что отдельные пакеты будут потеряны или их порядок будет неправильным. Почти все приложения, использующие видео и голосовые потоки, используют UDP.

Установка TCP соединений

Рисунок 1.4. Установка и завершение TCP соединения.

TCP соединение может быть установлено только между двумя узлами: серверный узел ожидает запросы на соединения, а клиентский узел отправляет такие запросы. После получения запроса на соединение, сервер устанавливает соединение. Затем оба узла могут отсылать и получать данные через это соединение. В любое время любой узел (но обычно клиент) может закрыть соединение.

Это взаимодействие изображено на рисунке 1.3. На нем также показаны вызовы операционной системы, необходимые для управления сокетами.

Порты

TCP и UDP адрес состоит из IP адреса машины и номера порта. Порты позволяют узлам, использующим протокол TCP/IP, предоставлять несколько веб-сервисов одновременно, а клиентам устанавливать более одного соединения с одним сервером. На сервере порты используются для различия веб-сервисов между собой. HTTP серверы обычно используют хорошо известный порт 80. В любых ситуациях каждое соединение в сети имеет различные пары адресов назначения и источника (IP адреса + номер порта).

1.3 Сокеты

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

Следует различать клиентские и серверные сокеты. Клиентские сокеты можно сравнить с оконечными аппаратами телефонной сети, а серверные - с коммутаторами. Клиентское приложение использует только клиентские сокеты, а серверное -- как клиентские, так и серверные сокеты.

Интерфейс сокетов впервые появился в BSD Unix. Программный интерфейс сокетов описан в стандарте POSIX.1 и в той или иной мере поддерживается всеми современными операционными системами. Сокет означает комбинацию IP-адреса и номера порта, например 10.10.10.10:80.

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

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

Рисунок 1.5. Взаимодействие клиента и сервера.

1.4 Мониторинг сети

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

Анализаторы пакетов относятся к классу инструментальных программных средств для мониторинга сетевого трафика и выявления некоторых типов сетевых проблем. По умолчанию сетевой интерфейс видит пакеты, предназначенные только для него. Однако анализаторы устанавливают его в режим приема всех пакетов - promiscuous mode, прослушивают сеть и заставляют сетевой интерфейс принимать все фреймы, вне зависимости от того, кому они адресованы в сети.

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

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

· Пользовательский интерфейс. Большинство анализаторов имеют развитый дружественный интерфейс, базирующийсяна Windows. Этот интерфейс позволяет пользователю выводить результаты анализа интенсивности трафика;

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

Методология проведения анализа может быть представлена в виде следующих трех этапов:

1. Захват данных.

2. Просмотр захваченных данных.

3. Анализ данных.

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



2. Практическая часть

2.1 Постановка задачи разработки

Целью данного курсового проекта является представление способа передачи данных внутри сети, а также возможные пути отслеживания передаваемых пакетов между узлами и выявления соответствия источников посылаемого трафика.

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

Рисунок 2.1. Получение информации о пакетах.

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



2.2 Формализация требований к программному средству

Основные требования к программному средству мониторинга пакетов в сети:

· Захват поступающих пакетов

· Обработка заголовков IP-пакета

· Инициализация адресов получателя и отправителя

· Отсеивание внутреннего пинга по широковещательному адресу сети

· Получение информации о протоколе транспортного уровня

· Предоставление информации о времени жизни пакета и его размере

· Правильная обработка неподдерживаемых и ошибочных запросов

· Доступный интерфейс в виде таблицы пакетов в командной сроке

2.3 Выбор инструмента разработки и его обоснование

В качестве языка программирования был выбран язык Borland C++ Builder 6. Выбор заключался в знании данного языка и удобства работы при взаимодействии работы с сокетами.

C++Builder стал одними из самых популярных на сегодняшний день инструментов для создания программных приложений благодаря сочетанию удобства разработки пользовательских интерфейсов и компонентной архитектуры.

Отметим основные особенности Borland C++ Builder:

· удобная среда разработки;

· быстрота разработки приложений;

· невысокие требования разработанного приложения к ресурсам компьютера;

· возможность полного доступа к функциям операционных систем Windows.

2.4 Проектирование системы

Алгоритм работы приложения:

Рисунок 2.2. Блок-схема алгоритма.

2.5 Реализация системы

Реализация данной программы основана на использовании сокета прослушивания. Далее описана поэтапная реализация системы и приведена структура заголовка приходящего пакета.

1) Инициализации сокетов. Для реализации приложении используется WinSock 2.2 - сокет для взаимодействоя с системой Windows. Класс Socket обеспечивает широкий набор методов и свойств для сетевых взаимодействий. Он позволяет выполнять как синхронную, так и асинхронную передачу данных с использованием любого из коммуникационных протоколов, имеющихся в перечислении ProtocolType.

2) Создаем сокет. Получаем имя локального хоста, информацию о нем и присоединяем локальный адрес к нашему сокету.

3) Включаем режим приема всех приходящих из сети пакетов, указанием в качестве команды сокету SIO_RCVALL. Режим promiscuous включается только при активной системной плате или при выходе в Internet.

4) Делаем бесконечный цикл прихода IP пакетов. Цикл прекращается лишь при нажатии любой из клавиш на клавиатуре.

5) Разбор IP - заголовка пакета и вывод информации на экран.

Структура заголовка IP-пакета

typedef struct IPHeader {

UCHAR iph_verlen; // версия и длина заголовка

UCHAR iph_tos; // тип сервиса

USHORT iph_length; // длина всего пакета

USHORT iph_id; // Идентификация

USHORT iph_offset; // флаги и смещения

UCHAR iph_ttl; // время жизни пакета

UCHAR iph_protocol; // протокол

USHORT iph_xsum; // контрольная сумма

ULONG iph_src; // IP-адрес отправителя

ULONG iph_dest; // IP-адрес назначения

} IPHeader;

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



2.6 Описание функционирования программного средства

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

Пользователь может запустить приложение при помощи командной строки.



Заключение

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

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

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



Список использованной литературы

1. Ч. Калверт, К. Рейсдорф C / С++: Borland C++ Builder 6 - учебник

2. У. Ричард Стивенс Протоколы TCP/IP. Практическое руководство, BHV, Санкт-Петербург, 2013.

3. http://www.conlex.kz/protokol-setevogo-urovnya-ip-predostavlyaet-transportnomu-urovnyu-sluzhbu-nenadezhnoj-peredachi-dannyx/

4. http://www.opennet.ru/docs/RUS/tcpip/

5. http://www.xakep.ru/post/30601/default.asp



Приложение

Руководство пользователя.

Пользовательский интерфейс предельно прост. Для запуска необходимо выбрать исполняемый файл Project.exe и открыть приложение. При этом откроется пустая командная строка.

В том случае, если компьютер или сервер не подключен к локальной сети, то есть пакеты не поступают, программа ничего не отобразит.

В случае если сетевое подключение есть, на экране начнут появляться статистические данные в виде отдельных строк, соответствующих пришедшему пакету. Каждая строка показывает:

1) IP адрес отправителя

2) IP адрес получателя

3) Протокол передачи

4) Размер пришедшего пакета

5) Время жизни пакета

Анализируя данные показатели можно сделать вывод о распределении трафика приходящего и отправляемого.

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

Рисунок 3.1. Внешний вид приложения.



Тест программы

#include <conio.h>

#include <stdio.h>

#include <winsock2.h>

#define MAX_PACKET_SIZE 0x10000

#define SIO_RCVALL 0x98000001

// Буфер для приёма данных

char Buffer[MAX_PACKET_SIZE]; // 64 Kb

//Структура заголовка IP-пакета

typedef struct IPHeader {

UCHAR iph_verlen; // версия и длина заголовка

UCHAR iph_tos; // тип сервиса

USHORT iph_length; // длина всего пакета

USHORT iph_id; // Идентификация

USHORT iph_offset; // флаги и смещения

UCHAR iph_ttl; // время жизни пакета

UCHAR iph_protocol; // протокол

USHORT iph_xsum; // контрольная сумма

ULONG iph_src; // IP-адрес отправителя

ULONG iph_dest; // IP-адрес назначения

} IPHeader;

char src[10];

char dest[10];

char ds[15];

unsigned short lowbyte;

unsigned short hibyte;

void main()

{

WSADATA wsadata; // Инициализация WinSock.

SOCKET s; // Cлущающий сокет.

char name[128]; // Имя хоста (компьютера).

HOSTENT* phe; // Информация о хосте.

SOCKADDR_IN sa; // Адрес хоста

IN_ADDR sa1; //

unsigned long flag = 1; // Флаг PROMISC Вкл/выкл.

// инициализация

WSAStartup(MAKEWORD(2,2), &wsadata);

s = socket( AF_INET, SOCK_RAW, IPPROTO_IP );

gethostname(name, sizeof(name));

phe = gethostbyname( name );

ZeroMemory( &sa, sizeof(sa) );

sa.sin_family = AF_INET;

sa.sin_addr.s_addr = ((struct in_addr *)phe->h_addr_list[0])->s_addr;

bind(s, (SOCKADDR *)&sa, sizeof(SOCKADDR));

// Включение в режим прослушивания

ioctlsocket(s, SIO_RCVALL, &flag);

// Бесконечный цикл приёма IP-пакетов.

while(!kbhit())

{

int count;

count = recv( s, Buffer, sizeof(Buffer), 0 );

// обработка IP-пакета

if( count >= sizeof(IPHeader) )

{

IPHeader* hdr = (IPHeader *)Buffer;

if( hdr->iph_ttl!= 128 )

{

//Разбор пакета

strcpy(src,"Пакет: ");

CharToOem(src,dest);

printf(dest);

// Преобразуем в понятный вид адрес отправителя.

printf("From ");

sa1.s_addr = hdr->iph_src;

printf(inet_ntoa(sa1));

// Преобразуем в понятный вид адрес получателя.

printf(" To ");

sa1.s_addr = hdr->iph_dest;

printf(inet_ntoa(sa1));

// Вычисляем протокол. Полный список этих констант

// содержится в файле winsock2.h

printf(" Prot: ");

if(hdr->iph_protocol == IPPROTO_TCP) printf("TCP ");

if(hdr->iph_protocol == IPPROTO_UDP) printf("UDP ");

// Вычисляем размер. Так как в сети принят прямой порядок

// байтов, а не обратный, то прийдётся поменять байты местами.

printf("Size: ");

lowbyte = hdr->iph_length>>8;

hibyte = hdr->iph_length<<8;

hibyte = hibyte + lowbyte;

printf("%u", hibyte);

// Вычисляем время жизни пакета.

printf(" TTL:%s\n",itoa(hdr->iph_ttl,"",10));

}

closesocket( s );

WSACleanup();

}

Размещено на Allbest.ru