Сетевой анализ

 

Сетевой анализ. Часть I.

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

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

Модель ISO-OSI

Опустим историю и перейдем к делу… Модель OSI – Open System Interconnection описывает собственно взаимодействие открытых систем. В общем, открытая система (будь то ПО, ОС, компьютер или одна из его аппаратных частей) – это система, построенная на открытых спецификациях. В свою очередь, спецификация – это формализованное описание аппаратных и программных средств, способов их функционирования, взаимодействия с другими компонентами, условий эксплуатации и т.д. и т.п. Естественно, не всякая спецификация является стандартом, однако в случае, если она открытая, то третьим лицам безвозмездно :) дозволено разрабатывать на ее основе ПО и железо, а также делать свои расширения и улучшения чужих программных и аппаратных средств. Впрочем, мы отклонились от темы.

Вот она:

Рис. 1. Модель OSI – Open System Interconnection (модель взаимодействия открытых систем).

Модель OSI имеет семь уровней: прикладной, представительный, сеансовый, транспортный, сетевой, канальный, физический. Каждый уровень взаимодействует только со своим соседом снизу и сверху, а про другие и знать не знает. Нужно это для того, чтобы обеспечить независимое развитие этих уровней, кроссплатформенность, легкое обслуживание и замену. А достигается такой эффект благодаря очень простой операции – инкапсуляции заголовков.

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

Рис. 2. Инкапсуляция.

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

Потому что здесь - в среде физического уровня (когда данные доступны в некоторой общей области) - как раз и вступают в игру средства перехвата – сниферы ;) Сниферы принимают пакеты, обрабатывают их, читая и распаковывая заголовки, и представляют соответствующей программе в определенной последовательности (обычно в порядке поступления на адаптер) и в удобоваримом формате (в “распакованном” согласно выше описанной модели ISO-OSI виде (а вы думали, зачем я все это вам рассказываю). Это как раз тот случай, когда теоретические знания приводят к конкретным практическим результатам, будь то решение какой-либо ошибки или повышение производительности сети на основе полученных данных…

Сетевой монитор

Рассмотрим известную и наиболее доступную для администраторов Windows 2000 Server утилиту – "Сетевой монитор". В упомянутой ОС данная утилита представлена как Network Monitor Light, полная же версия есть в пакете SMS (System Management Server). Что же это такое? Сетевой монитор - это инструмент, который часто используется в качестве последнего способа разрешения различных проблем. Он применяется для получения статистики оценки загрузки каналов сети, пакетной передачи кадров, а также для захвата и дешифровки данных сети с целью последующего анализа. Для полномасштабного анализа необходимо апгрейдить Light версию до полной в SMS поставке, так как в целях безопасности Microsoft отрубила захват кадров кроме входящих-исходящих с компьютера и широковещательных (broadcast) пакетов.

Установить NetWork Monitor можно стандапртно: в аплете Add/Remove Programs -> Windows Components -> Management and Monitoring -> Network Monitor Tools, и окажется он после установки конечно в Administrative Tools. Первым, что вы увидите при запуске Сетевого монитора, будет окно захвата (Capture Window).

Рис. 3. Окно захвата утиллиты "Сетевой монитор"

Окно захвата делится на четыре части: графиков (Graph), общей статистики (Total Statistics), статистики сеанса (Session Statistics) и статистики станции (Station Statistics).

1. Графики (левый верхний угол) показывают текущую активность сети в виде шкалы.
2. Общая статистика (правый верхний угол) показывает общие данные с момента начала захвата. В полной версии, поставляемой в SMS, на данной панели показана полная статистика захвата кроме отфильтрованных вами кадров (см. ниже), а в Light показана полная статистика, но захвачено лишь столько пакетов, сколько показано в поле "Захваченной статистики" (Captured Statistics) панели "Общей статистики", опять же при условии, что не выполняется фильтрация.
3. Статистика сеанса (левый нижний угол) содержит информацию об отдельных сеансах между двумя узлами.
4. Статистика станции (самая нижняя панель) показывает общую статистику по кадрам, посланным-принятым отдельными узлами. Здесь, например, можно на вскидку определить, кто топит вашу сеть.

Начнем... Ищем кнопочку Start Capture (Начать Захват) на панели инструментов или F10. Надо оговорить одно "но" - ваш адаптер должен поддерживать драйвер NDIS 4.0 или выше (у меня с этим проблем еще не было). Естественно, драйвер должен быть установлен в системе. Устанавливается он в аплете "Сеть и Удаленный доступ к сети", как обычный сетевой протокол, настраивать его не надо. При использовании нескольких плат адаптеров вам будет предложено выбрать, на какой из них выполнять перехват.

После щелчка на кнопке Stop and View Captures (Остановить и просмотреть захваченные данные) или F12 на экране появится окно просмотра кадров Frame Viewer.

Рис. 4. Окно просмотра кадров (Frame Viewer) утиллиты Сетевой Монитор.

Оно делится на три части: панель сведений, панель детальной информации и Hex панель.

1. Панель сведений отображает список захваченных кадров. Указывается порядковый номер кадра, время, прошедшее с начала захвата, локальные адреса MAC – исходный и места назначения – это аппаратные адреса канального уровня. Далее идет используемый протокол и текстовое описание. После щелчка на любом кадре откроются следующие две панели окна просмотра кадров.
2. Панель детальной информации содержит, так сказать, внутренности кадра – описание его заголовков на чистом английском языке в порядке принадлежности их к уровням модели OSI, начиная с физического и выше. Вот здесь, хотя и написано все до боли понятно, без необходимых теоретических знаний вы не уловите сути и не сможете провести детальный анализ, но даже любопытному новичку многое здесь покажется знакомым.
3. Hex панель позволяет увидеть данные кадра в виде текста ASCII. Здесь, например, можно увидеть гуляющие по сети незашифрованные пароли. Попробуйте захватить пакеты почтового приложения Eudora старых версий для Маков, находящегося в режиме ожидания почты. Немного поковырявшись, вы будете приятно удивлены, увидев его открытым текстом в Hex панели.

Впрочем, будете всегда на чеку, так как и шифрование паролей не спасет вас от тандемов снифера с какой-нибудь программой вроде LCP у "похабника" (соседа по хабу) в роли особо грамотного юзера, возомнившего из себя крутого хакера. Однако если он все же оплошается и использует в качестве снифера Сетевой Монитор, то помните - мгновенно вычислить его можно, нажав на кнопку Identify Network Monitor Users (Определение пользователей сетевого монитора), находящееся в меню Tools (Сервис). Данная опция показывает текущие сеансы сетевого монитора в вашей сети и даже его статус (capture или running).

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

Параметры захвата можно задать и по-другому. Если захватывать не весь кадр, а только часть (заголовки без остальных данных), то резко снизится потребность в больших объемах буфера. Выставить параметры захвата и объем буфера можно в элементе Capture Buffer Settings (Параметры буфера захвата) меню Capture. Напомню, что заголовки Ethernet в сети TCP/IP обычно длиной в 60 байт.

И наконец - фильтры захвата. Тоже хороший способ сократить объем информации. Найти их можно во вкладке Filter (Фильтр) меню Capture.

Рис. 5. Фильтры захвата утиллиты Сетевой Монитор.

Выбирая кадры определенного типа, вы быстрей доберетесь до сути – фильтровать можно по протоколам, адресам и данным. Естественно, профессионалы делают свои сложные фильтры при помощи триггеров булевой логики. Удачные сложные фильтры рекомендую сохранять для решения, так сказать, типовых задач – подобных проблем возникающих в будущем. Захватываемые протоколы можно изменить в окне Capture Filter (Фильтр захвата), дважды щелкнув на элементе SAP/ETYPE = Any SAP or Any ETYPE’s, появится диалоговое окно Capture Filter SAP’s and ETYPE’s.

Рис. 6. Настройка захватываемые протоколов в утиллите Сетевой Монитор.

Использование фильтров сбережет ваши буферные ресурсы и увеличит время реакции системы. Задание адресов тоже скинет с ваших плеч горы ненужной информации, генерируемой хостами. Адреса отображаются в окне Address Expression (Адреса) двойным кликом на элементе Address Pairs (Адресные пары) во все том же окне Capture Filter. Адреса можно как добавлять, так и исключать. И последний пункт - Pattern Matches (Фрагменты данных). Фрагменты данных – это просто образец данных, которые вы ищете в захватываемых кадрах в Hex или в ASCII. Необходимо также указать смещение (offset) в байтах, оно определяет местоположение внутри кадра. Не забудьте, что в сетях Ethernet плавающая длина поля с MAC адресом, так что лучше ставьте offset с конца.

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

Рис. 7. Фильтр отображения утиллиты Сетевой Монитор.

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

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

Рис. 8. Настройка фильтра отображения для FTP кадров в утиллите Сетевой Монитор.

Ко всему прочему в панели Expressions (Выражения) окна Display Filter (Фильтр Отображения) вкладки Display вы сможете выбрать нужные и/или исключить ненужные свойства протокола FTP и других протоколов.

Рис. 9. Настройка свойств протокола FTP в фильтре отображения.

Как только вызывается фильтр, появляются только те кадры, которые вы заказывали.

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

Есть некоторые нюансы в использовании фильтров отображения и фильтров захвата.

1. Фильтр отображения позволяет определять только три адресные пары. Таким образом, при большом количестве сеансов фильтры захвата окажутся непригодными в отличии от фильтров отображения.
2. Фильтры отображения позволяют неограниченно использовать операторы OR, AND, NOT при создании условий поиска по фрагментам данных, а фильтры захвата - лишь AND.
3. При использовании фильтров захвата активно используется CPU, а при полном захвате - объемы буфера.
4. И наконец, для меня самое важное то, что при полном захвате я могу не думать о том, что ищу. В случае же использования фильтров захвата все время возникает мысль, что я что-то упустил. Поэтому, рекомендую все же использовать полный захват и фильтры отображения. А самое главное - не забывайте сохранять файлы захвата в качестве эталонов, а те, с помощью которых вы успешно разрешили проблемы в сети, снабжайте понятным названием, комментариями и естественно - соответствующими метками – все должно быть как в больнице :).

В меню Capture есть очень интересная опция Addresses, поговорим теперь о ней. Это база данных адресов, которые сетевой монитор нашел в вашей сети, и это очень полезная база данных. В ней вы увидите такие данные как имя NetBIOS, локальный адрес MAC. Их можно изменять, но это не рекомендуется, лучше создавайте описательное имя лишь для машин, у которых нет имени NetBIOS, например Макинтоши. Как только вы заведете его в базе, оно будет и в остальных окнах сетевого монитора. Поля SRC MAC Addr и DST MAC Addr (Исходный локальный адрес и локальный адрес места назначения) в окне просмотра захвата можно редактировать напрямую, выбрав в контекстном меню Edit Address (Изменить адрес). Там можно наделить адрес понятным именем и комментариями, база данных автоматически пополнится, а вам станет легче жить на белом свете и разрешать непонятные имена.

Жизнь в сети

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

Начнем с расшифровки IP заголовка:

Рис. 10. Расшифровка заголовка с помощью утиллиты Сетевой Монитор.

Version: 4 bits (Версия 4 бита). Поле версии указывает на формат заголовка сети.

IHL – Internet Header Length: 4 bits (Длина заголовка Internet: 4 бита) Это длина заголовка в 32-битном формате, указывает на начало данных в пакете. Минимальное значение для корректного заголовка – 5.

Type of Service: 8 bits (Тип службы: 8 бит). Тип службы абстрактные параметры качества желательного обслуживания данных, эти значения используются в качестве параметров службами управления передачей датаграмм. Короче говоря, с помощью этого параметра можно регулировать приоритет обслуживания у соответствующих служб. Параметры следующие:

Бит 0-2 – Приоритет;

Бит 3 – 0=Нормальная задержка, 1=Слабая задержка;

Бит 4 – 0= Нормальная производительность, 1=Высокая производительность;

Бит 5 – 0=Нормальная надежность, 1=Высокая надежность;

Бит 6-7 – Зарезервировано.

Вот такой интересный параметр TOS. Используется он, кстати, в такой продвинутой сетевой технологии как ATM для эффективного управления задержками и производительностью. Едем дальше…

Precedence (Приоритетность). Тип службы, используемой для интерпретации датаграммы во время передачи датаграммы в сети. Это тоже приоритетность, однако предназначена она для управления соединениями только в пределах конкретной сети. В глобальной сети можно использовать только один параметр: 110 – Управляется Глобальной сетью.

Total Length: 16 bit (Общая длина: 16 бит) Эта длина датаграммы измеряемая в октетах. Все узлы обязаны быть готовы к приему датаграмм в 576 октетов – не случайное число: 64 октета заголовок (типичный равен 20) и 512 октетов блок данных.

Identification: 16 bits (Идентификация: 16 бит). Это идентификатор пакета, определяемый отправителем, помогает собрать датаграмму целиком, если пакет фрагментирован.

Flags: 3 bits (Флаги: 3 бита). Существуют следующие значения:

Bit 0-5: зарезервированный; должен быть нулевым.

Bit 6: 0=May Fragment (может фрагментироваться); 1=Don’t fragment (не фрагментировать).

Bit 7: 0=Last fragment (последний фрагмент); 1=More fragment (будут еще фрагменты).

Fragment offset: 13 bits (Смещение фрагмента: 13 бит). Это поле указывает, где в датаграмме расположен текущий фрагмент.

Time to Live: 8 bits (Время жизни: 8 бит). Это время жизни датаграммы в сети. Если это поле равно 0, датаграмма уничтожается. Оно уменьшается на единицу каждый раз при обработке заголовка, например маршрутизатором, в общем, по достижению определенного количества хопов, либо по окончанию времени (что быстрей закончится) датаграмма будет уничтожена.

Protocol: 8 bits (Протокол: 8 бит). Указывает протокол следующего уровня.

Header Checksum: 16 bits (Контрольная сумма заголовка: 16 бит). Название говорит само за себя.

Source address: 32 bits (Исходный адрес: 32 бита). Адрес источника.

Destination address: 32 bits (Адрес назначения: 32 бита).

Padding: variable (Дополнение: переменная). Дополняется к заголовку, чтобы гарантировать, что он имеет длину в 32 разряда.

Теперь посмотрим TCP пакет:

Рис. 11. Анализ TCP-пакета с помощью утиллиты Сетевой Монитор

Source port: 16 bits (Исходный порт: 16 бит). Номер исходного порта определяет порт отправителя.

Destination port: 16 bits (Порт назначения: 16 бит). Порт получателя.

Sequence number: 32 bits (Порядковый номер: 32 бита). Порядковый номер первого октета данных в сегменте (за исключением бита SYN). Если SYN присутствует, то порядковый номер – это начальный порядковый номер (ISN – Initial Sequence Number), и первый октет данных определяется как ISN + 1.

Acknowledgment number: 32 bits (Номер уведомления: 32 бита). Если используется бит уведомления ACK, то это поле содержит порядковый номер следующего сегмента, которого ожидает отправитель.

Data offset: 4 bits (Смещение данных: 4 бита). Это номер 32 разрядных слов и указывает он, где начинаются данные.

Reserved: 6 bits (Резервирование: 6 бит). Резерв для дальнейшего использование должен быть нулевым. Это резерв часто используется разработчиками для разработки сетевых приложений или своих расширений TCP.

Flags: 6 bits (Флаги: 6 бит слева на право). Флаги – это биты управления RFC 791. Этот список начинается с поля указателя Urgent и заканчивается данными из установки отправителя No:

URG. Определение поля указателя срочности.

ACK. Определение поля уведомления.

PSH. Функция PUSH.

RST. Сброс соединения.

SYN. Синхронизация. С этого флага начинается установка соединения.

FIN. Нет больше данных для отправки.

Window: 16 bits (Окно: 16 бит). Это номер октетов данных, начинающийся с указанного в поле уведомления ACK, которое отправитель сегмента желает принимать.

Checksum: 16 bits (Контрольная сумма: 16 бит).

Urgent Pointer: 16 bits (Указатель срочности: 16 бит). Это поле сообщает текущее значения указателя срочности в виде положительного смещения порядкового номера в этом фрагменте. Указатель срочности определяет порядковый номер октета срочных данных, естественно, если есть флаг URG.

Options: variable (Опции: переменная). Опции могут занять пространство в конце заголовка кратное 8 битам. Есть два формата опций:

1. Октет настройки.
2. Октет настройки, октет длины настройки, октет данных настройки.

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

Разряд 0 – конец списка настроек. Используется в конце всех настроек и только тогда, когда конец настроек не совпадает с концом заголовка TCP.

Разряд 1 – Отсутствие действия. Этот код добавляется между настройками, для выравнивания начала следующей настройки по границе слова.

Разряд 2 – Максимальный размер фрагмента. Эта настройка определяет максимальный приемлемый размер принимаемого фрагмента. Это поле представлено только в запросе на соединение SYN. Если настройки нет, значит, допустимы любые фрагменты.

Padding: variable (Дополнение: переменная). Дополнение заголовка TCP как в случае с IP заголовком используются для выравнивания относительно 32 разрядной границы. Состоит из нулей.

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

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

To be Continue...

P.S. Собственно, большую часть представленной информации можно и, я бы сказал, нужно почерпнуть из RFC (в частности для данной статьи - 791,793).

Сетевой анализ. Часть II.

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

Средства анализа

Все средства, применяемые для анализа и диагностики локальных сетей, можно разделить на несколько классов.

1. Агенты систем управления, поставляющие информацию по протоколам SNMP или CMIP. Для получения и обработки данных от агентов обычно требуется наличие системы управления.
2. Встроенные системы диагностики и управления на основе программно-аппаратных модулей, поставляемые в сетевом коммутационном оборудовании. Они, как правило, управляют и выполняют мониторинг только одного устройства, но, как часто и случается, по совместительству выполняют функции SNMP-агентов, поставляя данные об устройстве системам управления.
3. Экспертные системы. Это мощнейшие системы, часто реализованные в виде отдельных модулей средств мониторинга и анализа сетей: систем управления сетями, сетевых анализаторов и т.д. Главное их отличие в том, что они содержат в себе знания технических специалистов о выявлении причин плохой роботы сети и о вариантах решения данной проблемы. Это вам не кнопочка диагностики в Windows XP, хотя простейший вариант этой системы выглядит именно как контекстно-зависимая справка. Более сложные представляют собой базы знаний с элементами искусственного интеллекта. Примерами таких систем являются встроенные в систему управления Spectrum от компании Cabletron и в анализатор протоколов Sniffer от Network General, HP Open View и SunNet Manager.
4. Анализаторы протоколов. Это программные или аппаратные системы, которые ограничиваются, в отличие от систем управления, лишь мониторингом и анализом трафика. Как правило, эти системы захватывают и декодируют пакеты широкого спектра протоколов. Они выполняют полное декодирование, то есть в удобной для специалиста форме показывают вложенность пакетов протоколов различных уровней друг в друга с расшифровкой содержания отдельных полей каждого пакета.
5. Сетевые анализаторы. Это все то оборудование для диагностики кабальных систем, которым тоже конечно должен владеть администратор ну или хотя бы знать о нем.

Делятся сетевые анализаторы на четыре группы:

• Сетевые мониторы. Они предназначены для тестирования кабелей, также умеют собирать статистику по трафику - его средней интенсивности, средней интенсивности пакетов с определенной ошибкой и т.д. Эти устройства самые интеллектуальные из четырех классов, так как умеют работать не только на физическом уровне модели OSI, но и на канальном, а нередко даже и на сетевом.
• Устройства сертификации кабельных систем. Просто выполняют сертификацию в соответствии с требованиями одного из международных стандартов на кабельные системы.
• Кабельные сканеры. Используются для диагностики медных кабельных систем.
• Тестеры. Предназначены для проверки на отсутствие физического разрыва. Самый доступный вариант, которым должен владеть ИМХО каждый администратор.

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

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

Кабельные сканеры и тестеры

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

Итак, основное назначение сканеров и тестеров - это определение электрических параметров кабелей: длины кабеля (тестером... слабо :)), параметра NEXT (Near End Cross Talk - перекрестные наводки на ближнем конце, т.е. помехозащищенность кабеля от внутренних источников помех; витую пару и лапшу в телефонах для того и перекручивают, чтоб уменьшить этот показатель), затухания, импеданса (активного сопротивления), схемы разводки пар проводников, уровня электрических шумов в кабеле и т.д.

Для определения местоположения неисправности кабельной системы (обрыва, замыкания, неправильно установленного разъема и т.д.) используется метод "отраженного импульса" (Time Domain Reflectometry, TDR). Метод этот состоит в том, что сканер излучает в кабель сигнал и измеряет время задержки до прихода отраженного сигнала, в общем, тот же ping только по-электрически. По полярности отраженного сигнала определяется характер повреждения кабеля (замыкание или обрыв). В хорошем кабеле без багов ответного импульса почти нет.

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

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

Многофункциональные приборы мониторинга

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

Давайте посмотрим, что умеют такие приборы:

1. Интерфейс пользователя.

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

2. Функции проверки.

1. Сканирование кабеля. Позволяет измерять длину кабеля, расстояние до самого серьезного дефекта и распределение импеданса по длине. При проверке неэкранированной витой пары можно выявить следующие огрехи: расщепление пары, обрывы, замыкания и др. Для сетки Ethernet на коаксиале проверять можно прямо во время работы.
2. Функция карты кабелей. С помощью этой функции составляются карты кабелей и кабелей, ответвляющихся от центрального помещения.
3. Автоматическая проверка кабеля. В разных приборах по разному, но обычно сюда входят: длина кабеля, импеданс, схема подключения жил, затухание и параметр NEXT на частоте до 100 MGz.
4. Функция определения распределения кабельных жил. Осуществляет проверку правильности подсоединения жил, наличие промежуточных разрывов и перемычек на витых парах.
5. Проверка постоянным током. Используется для проверки коаксиала на предмет правильной расстановки терминаторов.
6. Определение скорости распространения сигнала NVP.
7. Проверка пары «сетевой адаптер-концентратор». Тест определяет местонахождение источника неисправности - кабель, концентратор, сетевой адаптер или ПО.
8. Автоматическая проверка сетевых адаптеров. Проверяет правильность вновь установленных сетевых адаптеров или каких-либо подозрительных. Для сетки Ethernet можно узнать MAC-адрес адаптера, уровень напряжения сигналов, если сигнал на адаптере не найден, то автоматически сканируется соединительный кабель и разъем.

3. Функции сбора статистики.

Эти функции позволяют в реальном времени проследить за изменением различных параметров.

1. Сетевая статистика. В этой группе собраны наиболее важные статистические показатели - коэффициент использования сегмента (utilization), уровень коллизий, уровень ошибок и уровень широковещательного трафика. Превышение этими показателями определенных пороговых значений говорят о проблемах на сегменте.
2. Статистика ошибочных кадров. Укороченные кадры (Short frames). Это кадры, имеющие длину, меньше допустимой, то есть меньше 64 байт. Этот тип делится кадров на два подкласса - короткие кадры (short) у них корректная контрольная сумма, и коротышки (runts), не имеющие корректной контрольной суммы. Наиболее вероятной причиной появления таких вот мутантов являются сырые дрова адаптеров или сами адаптеры, что конечно говорит об их неисправности.
   • Удлиненные кадры (Jabbers). Джаберсы имеют длину превышающие допустимое значение в 1518 байт с хорошей или плохой контрольной суммой. Они являются следствием затяжной передачи - опять же проблема в адаптере.
   • Кадры нормальных размеров, но с плохой контрольной суммой (Bad FCS) и кадры с ошибками выравнивания по границе байта. Кадры с неверной контрольной суммой являются следствием, плохих контактов, помех на кабелях, плохо работающих портов повторителей, мостов, коммутаторов, маршрутизаторов, сетевых адаптеров. Ошибка выравнивания всегда сопровождается ошибкой контрольной суммы и может быть следствием прекращения передачи кадра при распознавании коллизии передающим адаптером.
   • Кадры-призраки (ghosts) являются результатом электромагнитных наводок на кабеле. Они воспринимаются сетевыми адаптерами как кадры, не имеющие нормального признака начала кадра - 10101011. Кадры-призраки имеют длину более 72 байт, иначе они классифицируются как коллизии. Количество таких вот кадров призраков зависит от места подключения, причины их появления - петли заземления и др. проблемы с кабельной системой.

Если вы наивно полагаете, что к вашей сети все описанные мной пакости не относятся, то глубоко ошибаетесь. С виду капля из лужи тоже чиста, но если посмотреть в нее вооруженным глазом.. :) то мяса, там шевелящегося, едва ли не больше, чем самой воды. И если представить, что лужа - это сетка на основе всенародных чипов Realtek неизвестного китайского мастера, то, думаю, всем все сразу станет понятно. А если серьезно, знание процентного распределения общего количества ошибочных кадров по их типам может подсказать администратору причины неполадок в сети. Даже небольшой процент ошибочных кадров может сильно снизить пропускную способность сети, если протоколы восстановления кадров работают с большими таймаутами ожидания квитанций. Нормальный процент ошибочных кадров в сети должен быть не более 0,01 %.

1. Статистика по коллизиям. Эта статистика указывает на количество и виды коллизий на сегменте сети и позволяет определить наличие проблемы и ее местонахождение. Итак, основные типы коллизий в сети Ethernet.
   • Локальная коллизия (Local Collision). является результатом одновременной передачи двух и более узлов, принадлежащих к тому сегменту, в котором производятся изменения. Высокий уровень коллизий говорит о проблемах с кабельной системой.
   • Поздняя коллизия (Late Collision). Это коллизия, которая происходит после передачи первых 64 байт кадра, так как по протоколу Ethernet коллизия должна определятся именно в этот момент. Результатом поздней коллизии будет кадр, имеющий длину более 64 байт и содержащий неверное значение контрольной суммы. Обычно такие проблемы указывают на глюки сетевого адаптера или слишком длинную сетевую систему, а также большое количество промежуточных повторителей.
   • Удаленная коллизия (Remote Collision). Эти коллизии происходят на другой стороне повторителя, то есть в другом сегменте по отношению к измерительному прибору. Обычно все коллизии в сетях Ethernet от 10Base до Gigabit удаленные.

Интенсивность коллизий не должна превышать 5 %, а пики выше 20 % говорят о серьезных проблемах.

1. Распределение используемых сетевых протоколов. Это статистика по используемым протоколам в процентах относительно общего количество кадров в сети.
2. Генерирование трафика. Генерация прибором трафика для теста на пропускную способность.
3. Основные генераторы широковещательного трафика (Top Broadcasters). Станции, больше всех генерирующие широковещательные или групповые кадры.
4. Основные отправители (Top Senders). Функция позволяет отслеживать наиболее активные передающие узлы локальной сети.
5. Основные получатели (Top Receivers). Соответственно, по смыслу.

4. Функции анализа протоколов.

Это уже дорогостоящая функция, впрочем, обычно многофункциональные приборы могут декодировать несколько основных протоколов, таких как TCP/IP, Novell NetWare, NetBIOS и Banyan VINES. Не все правда могут отобразить ту картину, какую мы можем видеть в анализаторах протоколов, но в место этого собирается статистика о наиболее важных пакетах, свидетельствующих о наличии проблем в сетях. Например, при анализе протокола TCP/IP, собирается статистика по ICMP пакетам, с помощью них маршрутизаторы сообщают об ошибках узлам.

3. Функции ping.

Ну, куда без него...

Сетевые анализаторы

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

Анализаторы протоколов

Итак, с чего начали, тем и закончили… Снова анализаторы, снова сниферы… Напомню, что это - программное обеспечение состоящее из ядра, поддерживающего работу адаптера, и программного обеспечения, декодирующего протокол канального уровня, с которым работает сетевой адаптер, а также наиболее распространенные протоколы верхних уровней: IP, TCP, FTP, Telnet, HTTP, IPX, NCP, DECnet, NetBEUI и т.д. В состав некоторых анализаторов может входить экспертная система, позволяющая пользователю выдавать рекомендации о том, какие действия можно предпринять в данной ситуации, что могут означать те или иные неисправности, как их устранить.
Возможности анализа сети на физическом уровне у сниферов минимальные, поскольку всю информацию они получают от сетевого адаптера, а ее характер во многом зависит от типа этого адаптера.
И снова статья увеличивается до размера, когда ее приходится делить на части, так что мне приходится закругляться, но в третьей части, а она, надеюсь, будет, я вам расскажу немного о реальных практических проблемах и о том, как их можно решать при помощи сниферов. Еще я покажу другие анализаторы протоколов, ведь при всей своей бесплатности Network Monitor входит в состав далеко не бесплатной ОС Windows, да и то лишь Lite (вы ведь помните его нехорошее ограничение на перехват совсем чужих пакетов), а ведь есть еще Open Source, ну и возможно будет и еще что-нибудь вкусненькое, но говорить пока не буду, не хочу обещать.

To be Continue...

P.S. Ну, и для самых продвинутых людей исключительно рекомендую к ознакомлению - по кабелям стандарт EIA/TIA-568A (все те кабельные системы, при помощи которых строят сегодня сети, кроме коаксиала – устарел, батько…), ISO/IEC 11801 (аналогично).