Когда данные перехвачены и применен фильтр вывода данных, наступает время анализировать кадры. Верхняя панель является итоговой панелью, которая содержит информацию перечисленную ниже. Эти столбцы можно переупорядочить, нажимая заголовок столбца и перетаскивая в новое желаемое положение.
• Номер кадра. Microsoft Network Monitor присваивает кадру номер для целей учета. Он в реальности не появляется в самом кадре, но добавляется программой, чтобы упростить ссылку на информацию, находящуюся в перехваченных данных.
• Время. Время, также присваиваемое Microsoft Network Monitor, позволяет узнать, сколько времени проходит между кадрами. Это предоставляет полезную информацию при выполнении анализа сетевой производительности. Время, которое выводится в этом столбце, конфигурируется в параметрах меню Display. Существуют три возможности: время дня, секунды с начала перехвата и секунды от прохождения предыдущего кадра. Выбирая время дня, можно сопоставить информацию из журнала событий Windows с информацией, перехваченной Microsoft Network Monitor. Такое сопоставление допустимо для мощного поиска неисправностей при появлении ошибочных сообщений.
• Адрес MAC источника. Это устройство, которое прежде всего создает кадр. Есть три возможности для вывода адреса MAC, задаваемые из меню Options. Можно выбрать вывод имени, которое присвоено адресу MAC в адресной книге Microsoft Network Monitor; можно выбрать вывод просто адреса MAC (поведение по умолчанию); или можно выбрать вывод имени поставщика, связанного с первыми шестью байтами адреса MAC. Это бывает полезно при попытке найти неизвестное устройство в сети.
• Адрес MAC места назначения. Это аппаратный адрес места назначения пакета.
• Протокол. Это основной протокол кадра.
• Описание. Это поле предоставляет суммарную информацию о кадре Описание также конфигурируемо с помощью параметров меню Display. Существует две возможности: последний протокол в кадре или автоматический выбор на основе используемого фильтра вывода. Часто можно собрать достаточно информации из сводки, чтобы получить представление о том, что происходит в сеансе перехвата. Трехходовое квитирование TCP легко обнаружить по описанию. Здесь часто показывается информация о флагах TCP.
• Другой адрес источника. Чтобы увидеть это поле, следует переместить ползунок в нижней части итоговой панели. Другой адрес источника является адресом другого протокола, содержащимся в кадре.
• Другой адрес места назначения. Это адрес другого протокола, содержащийся в кадре.
• Тип другого адреса. Этот адрес сообщает, какой протокол содержат поля другого адреса.
Детализированная панель находится в середине. Здесь происходит большая часть анализа. Microsoft Network Monitor использует файлы .dll и файлы .ini для синтаксического разбора протокола. Существуют, например, файлы TCP.dll и TCP.ini, хранящиеся в каталоге синтаксического разбора Microsoft Network Monitor. Чтобы правильно проанализировать протоколы, которые Microsoft Network Monitor не понимает, необходим анализатор .dll и файл .ini. Можно написать их самостоятельно или получить их от независимых поставщиков.
Шестнадцатеричная панель находится в нижней части и содержит специальную информацию об анализируемом кадре. Например, рассматривая трассировки протокола РОРЗ, мы замечаем, что вся информация находится в шестнадцатеричной трассировке, а не в детализированной панели. Знание того, как читать шестнадцатеричную трассировку, поможет создать специальные фильтры перехвата.
На рис. изображен транспортный кадр NetBIOS, который переносится поверх TCP, IP и протокола Ethernet. Этот конкретный кадр является дежурным кадром сеанса. Если требуется создать фильтр перехвата, который перехватывает только дежурные кадры сеанса NetBIOS (возможно, для анализа влияния дежурного трафика NetBIOS на сеть, нам понадобится использовать смещение образца. Мы расширяем раздел NBT трассировки, щелкая на знаке плюс рядом с итоговой строкой NBT. Затем выбираем строку NBT: packet type. Отметим, что соответствующий раздел шестнадцатеричной трассировки автоматически подсвечивается, когда мы выбираем различные строки в детализированной панели. Когда мы выбираем packet type = session keep alive, подсвечивается шестнадцатеричное число 85 в строке 30. Теперь мы можем отсчитывать, пока не увидим, что шестнадцатеричное число 85 находится в смещенной позиции шестнадца-теричного 36 с начала кадра. Вместо отсчета можно посмотреть в нижний правый угол экрана Microsoft Network Monitor. Там мы видим, что это смещение 54 (десятичное) х36 (шестнадцатеричное). Эту информацию можно ввести в шаблон совпадения фильтра перехвата.
Чтобы защитить свою сеть от неавторизованного просмотра, сетевой монитор может легко определить другие экземпляры программы в сети. Он может сделать это независимо от того, работает или нет программа. Как показано на рис., если драйвер установлен на машине, он будет сообщать имя машины, имя зарегистрированного на компьютере пользователя, адрес Ethernet машины, номер версии программы и перехватывает ли программа данные, или просто установлена. Чтобы получить эту информацию, необходимо выбрать в меню Tools пункт Identify network monitor users (Идентифицировать пользователей сетевого монитора). Важно отметить, что если имеются сетевые сегменты, разделенные маршрутизатором, который не пересылает мультивещательные сообщения, то невозможно будет определить установки сетевого монитора в другом сегменте, не соединившись с этим сегментом. Это связано с тем, что Netmon использует суффикс NetBIOS для объявления о своем присутствии в сети. Суффикс BE объявляет агента сетевого монитора, а суффикс BF объявляет в сети само приложение сетевого монитора. Если они не пересылаются, то необходимо будет соединиться с определенным сегментом, чтобы определить незаконные установки этих инструментов.
После выбора пункта меню "Определить пользователей сетевого монитора" машина Netmon посылает запрос станции BONE, как показано в следующей распечатке. Протокол BONE (сокращение от Bloodhound Oriented Network Entity, что может быть приблизительно переведено как "Сетевая ищейка") используется сетевым монитором, чтобы он мог общаться. Этот ьапрос станции является очень маленьким кадром многоадресной рассылки 802.3, который использует только 29 байтов.
Ответ направляется в машину, которая послала запрос, и является маленьким кадром 802.3, в этот раз требующим около 125 байтов. Ответ сообщает статус драйвера; 0x00000003 означает, что драйвер установлен и активен, но не перехватывает данные. Он содержит версию драйвера, машину, адрес MAC машины и имя любого пользователя, которое было сконфигурировано при конфигурировании драйвера.
Сетевой монитор SMS 1.2 включает несколько мастеров, которые помогут найти некоторые важные данные. Это отчеты (они не являются в действительности мастерами) верхнего пользователя и распределения протокола. Другие функции мастеров — поиск всех маршрутизаторов в файле перехвата и поиск всех имен в файле захвата, а также они могут разрешать адреса по именам. Недостаток этих отчетов в том, что не существует способа сохранить информацию помимо печати экрана (print screen) для перехвата отчета с экрана. Это существенный недостаток, так как часто полезно распечатать данные, в частности, отчет верхнего пользователя. Рассмотрим отчет верхнего пользователя.
Отчет верхнего пользователя активируется в режиме вывода (когда выводятся перехваченные данные в противоположность просмотру статистики сеанса). Отчет выбирается из меню Tools и имеет возможность показать, сколько выводить верхних пользователей, и основывается ли список на адресе канала данных или на адресе MAC. Можно также применить текущий фильтр вывода или выбрать игнорирование фильтра вывода и основывать отчет на всем файле перехвата. Как можно видеть на рис., отчет перечисляет имя, адрес, число кадров и процент числа кадров и размера кадра. Эта информация может помочь при планировании и расширении сети, а также при обнаружении нарушений эксплуатации сети.
Отчет о распределении протоколов доступен таким же образом, как и отчет верхних пользователей: из меню Tools в режиме вывода. Возможности этого отчета включают перечисление всех протоколов в кадре, сообщение о последнем протоколе в кадре и сообщение о первом действующем в кадре протоколе. Кроме того, можно выбрать дальнейшее ограничение на отчет, применяя текущий фильтр вывода к отчету. Этот отчет может стать ущественной помощью при попытке выявить аномалии в сети. Однако чтобы эта информация была наиболее полезна, необходимо знать, каким является нормальное распределение для сети. Если, например, сеть обычно имеет очень немного кадров ARP_RARP, но внезапно ими заполняется, есть хорошая исходная точка для поиска. Если же произошел внезапный всплеск пакетов UDP, это будет иметь другое значение. Знание того, что является нормальным для сети, трудно переоценить. Как можно видеть на рис. отчет перечисляет каждый протокол, число кадров и байтов и процент для перехваченных данных.
Поиск сетевых адресов по имени позволяет вводить имя компьютера, а поиск найдет соответствующий адрес МАО Это не очень сложно выполнить в сети TCP/IP, так как можно сделать ping имени хоста и затем получить информацию из кэша ARP с помощью команды ARP -а. Однако он может также использовать SAP, DNS и запрос базы данных SMS, поэтому это может быть более мощное решение. Если происходит обычная проверка адреса MAC, часто быстрее перейти в окно CMD и сделать ping и ARP -а. Как мы видим на рис, когда имя разрешено, будет выведена вся найденная о нем информация. Выбор только тех служб, которые присутствуют в сети, может оптимизировать этот процесс. Кроме того, можно ускорить процесс, делая локальную базу данных ADR первым источником, который будет запрашиваться с помощью кнопок "плюс" и "минус" рядом окном выбора службы.
Если требуется автоматически запускать сетевой монитор либо с помощью пакетного файла с триггером, либо с помощью службы планировщика Windows NT (команда AT), можно использовать следующие ключи командной строки. Каждый из этих ключей изменяет команду netmon. Пример пакетного файла включен в каталог batch на сайте издательства "ЛОРИ". Чтобы облегчить использование Netmon из командной строки, добавьте каталог с исполняемым файлом в путь доступа компьютера, изменяя переменную path системного окружения.
• /autostart — заставляет сетевой монитор запустить перехват данных немедленно после запуска. Пример: netmon /autostart.
• /remote computer - computer является именем удаленного агента, с которым
• желательно соединиться. Пример: Netmon /remote exchange.
• /net number - number определяет соединение с указанным сетевым интерфейсом. Эту информацию получают при помощи команды networks из меню capture. Пример: Netmon /net 2 (запустит Netmon, используя интерфейс сети #2, указанный в диалоговом окне сетей, но не начнется перехват данных, так как не определен ключ /autostart).
• /capturefilter path — определяет фильтр перехвата, который будет использоваться при работе сетевого монитора. Path задает расположение определенного фильтра перехвата.
• /displayfilter path — определяет фильтр вывода, который будет загружаться при запуске сетевого монитора.
• /buffersize number — задает размер буфера в байтах (одномегабайтный буфер перехвата будет определяться как /buffersize 1024000).
• /quickfilter type, address — указывает, что сетевой монитор начнет перехват данных сразу после запуска, и будет фильтровать на указанном адресе.
• /autostop — заставляет сетевой монитор остановить перехват данных, когда буфер заполнится. Пример: Netmon /autostart /buffersize 1024000 /autostop (запускает Netmon и немедленно начинает перехват данных с буфером перехвата в один мегабайт. Когда буфер перехвата заполнится, он остановится).
При запуске Systems Management Server Network Monitor версии 2.0 (V5.00646) можно подумать, что встретился со старым другом. Это полная версия Windows 2000 Network Monitor. Интерфейс практически такой же, и большинство утилит работает так же. Однако некоторые вещи изменились и появились новые свойства.
Новые свойства
Программы-эксперты — шесть экспертов, поставляемых вместе с Network Monitor 2.0, перечислены ниже.
• Эксперт среднего времени ответа сервера вычисляет среднее время, которое требуется серверу для ответа на запрос пользователя данных. Он может использовать SMB, специальные порты TCP или специальные сокеты IPX для получения этих чисел, выраженных в секундах.
• Распределение свойств вычисляет статистики кадров для определенного свойства, найденного в кадрах перехваченных данных. Эти свойства могут быть весьма специальными, такими как прием HTTP.
• Утилита объединения протоколов рекомбинирует данные транзакции которые были посланы по сети в множестве кадров. Этот эксперт может собрать все фрагменты вместе на основе информации, которая содержится в кадрах.
• Эксперт распределения протоколов проверяет перехваченные данные и предоставляет статистики о пакетах почти таким же образом, как мастер распределения протоколов в продукте 1.2.
• Эксперт пересылки TCP находит кадры TCP, которые были переслан на один и тот же компьютер. Это полезно при выявлении проблемнь компьютеров.
• Эксперт верхних пользователей находит верхних отправителей и получателей данных в файле перехвата, проверяя адреса источника и места назначения, содержащиеся в кадрах.
SMS 2.0 Platform Software Development Kit (SDK) позволяет разработать своих собственных экспертов, их можно также купить у независимых поставщиков. Эксперты запускаются из меню tools expert при работе в режиме показа. Как можно видеть на рис., эксперт среднего времени ответа сервера может быстро выделить проблему со временем ответа сети. На рисунке сервер 11.0.0.206 имеет среднее время ответа 2.378751 секунд, в то время как все остальные места назначения имеют времена ответа в долях секунды. Чтобы еще больше ухудшить ситуацию, этот медленный сервер используют десять пользователей. Раньше этот процесс превращался в десяток телефонных вызовов (что затрудняло выявление и исправление проблемы). Но теперь, когда благодаря мониторингу и анализу наши действия носят профилактический характер, можно решить проблему без всяких телефонных звонков. Пользователь только после решения проблемы заметит, что сервер стал видимо работать быстрее.
Эксперт пересылки TCP на рис. сообщает, что на самом деле существует несколько пересылок, но ни одна из них не идет на машину или из машины с длинным временем ответа. Так как это происходит не на коммутируемой магистрали, то пересылки могут быть вызваны сетевой перегрузкой, указывающей на возможную причину некоторых задержек.
Утилита объединения протоколов сообщает нам, что в перехваченных данных не существует фрагментированных пакетов, поэтому эта возможная причина может быть отброшена.
Рассматривая эксперт верхних пользователей, мы видим, что пять из десяти верхних пользователей соединены с сервером 11.0.0.206, и наш эксперт протоколов также говорит, что существует большое число соединений RPC с одной и той же машиной. Мы исследуем этот вопрос и находим, что 11.0.0.206 является более старой машиной, находится на 10-мегабитном сегменте Ethernet и даже не имеет в себе платы PCI Ethernet. Очевидно, что мы обнаружили причину слабой производительности. Пользователи не жаловались на нее раньше, потому что "она всегда медленная" и они "научились с этим жить". Замена старой платы на 100-мегабитную плату PCI решает эту проблему достаточно просто.
Как можно видеть на рис, эксперты записывают свою работу в окне статуса экспертов. Мониторинг этого окна удержит вас от попытки выполнить две программы-эксперта в одно время (что породит сообщение об ошибке). Это важно помнить, так как выполнение эксперта на большом файле перехвата может потребовать много времени на медленной машине, а окно статуса эксперта является единственным местом, которое позволит узнать, что компьютер не заблокирован. В это время можно заметить, что использование центрального процессора доходит до 100%, поэтому не надо выполнять экспертов на производственных серверах, так как это вызовет жалобы сообщества пользователей.
