ЧАСТЬ I Анализ протоколов: участники взаимодействия
Уровень представлений
Сеансовый уровень
Транспортный уровень
Сетевой уровень
Канальный уровень
Физический уровень
Проект IEEE 802
Как данные перемещаются по проводам
Особенности коммуникации в сетях Ethernet
Стек протоколов
Иерархический подход
Как все это объединяется?
Прикладные протоколы
Транспортные протоколы
Сетевые протоколы
Сетевая служба с поддержкой соединения
Сетевая служба без поддержки соединения
Адресация на канальном уровне
Адресация на сетевом уровне
Инкапсуляция данных
Реализация IP поверх различных стандартов LAN
Управление потоком
Функции межсетевого обмена сетевого уровня OSI
Службы WAN
Обзор главы
В следующей главе
Глава 2 Стек протоколов TCP/IP
Заголовок TCP
Трехходовое квитирование
Концепция времени молчания TCP
Полуоткрытые соединения и другие аномалии
Генерация команды сброса
Обработка команды сброса
Сценарий 2: TCP получает FIN из сети
Сценарий 3: оба пользователя закрывают соединение одновременно
Обмен срочной информацией
Управление окном
Интерфейс пользователь/TCP
TCP/Низкоуровневый интерфейс
Происходящие события: пользовательские вызовы
Состояние прослушивания
Протокол IP
Обзор главы
В следующей главе
Глава 3 Стек протоколов SPX/IPX
Протокол IPX
Работа на сетевом уровне модели OSI
Структура пакета
Адресация IPX
Сетевой номер
Зарезервированные сетевые номера
Внутренний сетевой номер
Номер узла
Номер сокета
Как работает маршрутизация IPX
Интерфейсы сеансов и дейтаграмм
Структуры заголовка сообщений
Обзор главы
В следующей главе
Глава 4 Блоки сообщений сервера
Определение имени сервера
Разрешение имени сервера
Транспорт сообщения
Пример потока сообщений
Согласование диалекта
Обратная совместимость
Настройка сеанса
Управление соединением
Подпись SMB
Оппортунистические блокировки
Исключающая oplock
Пакетная блокировка oplock
Level II Oplocks
Модель безопасности
Пример доступа/общего ресурса
Аутентификация
Заголовок SMB
Поле ТIB
Поле UID
Поле PID
Поле MID
Поле флагов
Поле Flags2
Поле состояния
Задержки
Кодирование режима доступа
Кодирование атрибутов файла
Кодирование расширенных атрибутов файла
Обзор главы
В следующей главе
ЧАСТЬ II Сетевой трафик: Анализ и оптимизация: взгляд на проблемы
Трафик клиента WINS
Регистрация имен и обновление
Трафик регистрации в системе
Поиск сервера регистрации
Оптимизация регистрации в сети
Просмотр
Где находятся резервные броузеры?
Оптимизация трафика броузера
Обзор главы
В следующей главе
Глава 6 Серверный трафик
Рекурсивный поиск
Объединение с WINS
Оптимизация DNS
Инициализация BDC
Обновления в базе данных
Оптимизация трафика синхронизации учетных записей
Служба NetLogon
Обзор главы
В следующей главе
Глава 7 Трафик приложений
Широковещание
ARP
Трехходовое квитирование
Сеанс NetBIOS
Согласование диалекта SMB
Просмотр Интернета
Secure Sockets Layer
Оптимизация трафика броузера в интрасети
Обзор главы
В следующей главе
Глава 8 Exchange и почта Интернета
Сервер Exchange в действии
Протокол РОРЗ
Общение Exchange с другим сервером
Обзор главы
В следующей главе
ЧАСТЬ III Сетевые мониторы: инструментальные средства работы
Перехват трафика вручную
Просмотр перехваченных данных
Сохранение перехваченных данных
Фильтрация данных перехвата
Анализ перехваченных данных
Система безопасности сетевого монитора
Установка сетевого монитора: обнаружение других мониторов
Сетевой монитор Systems Management Server 1.2
Соединение с удаленными агентами
Мастера-помощники
Конфигурирование триггеров
Network Monitor 2.0
А вот это не работает
Дополнительные свойства безопасности
Обзор главы
В следующей главе
ЧАСТЬ IV Сценарии поиска неисправностей: распространенные проблемы
Рассмотрим случай с портативным компьютером
Рабочая станция не может получить выделяемый DHCP адрес
Проанализируйте, что пропущено
Рабочая станция работает медленно
Что является источником недовольства?
Проблемы с регистрацией
Странные ошибки журнала событий
Выполнение без сопровождения
Избыточное широковещание
Почему они это делают?
Обзор главы
В следующей главе
Глава 11 Вопросы безопасности
Итак, где вы?
Прежде всего необходимо их найти
Как отбить нюх чужим ищейкам
Обзор главы
Приложения
Приложение В Утилиты командной строки
Приложение С Общие NCP
Приложение D Поиск обычных сетевых ошибок
Приложение Е Суффиксы NetBIOS
Приложение F Запуск контроллера домена
Приложение G Открытие страницы Web
Глоссарий

Author: Уилсон Э.   Труфанов О.  

Tags: компьютерные сети  

ISBN: 0-13-026495-4

Year: 2002

Text
                    1
Мониторинг
анализ сетей
Методы выявления неисправностей
реальные сценарии,
простые примеры,
I иллюстраций
1 производите.__.
¦ и поддержка новых \
;,| приложений *,
•ж Профессиональные
!* приемы мониторинга
! безопасности
I и защита
дательство
"Лори"
Эд Уилсх)н


Network Monitoring and Analysis Л Protocol Approach to Troubleshooting Ed Wilson Prentice Hall РКГ Upper Saddle River, New Jersey 07458 www.phpir, com
V* Мониторинг и анализ сетей Методы выявления неисправностей Эд Уилсон Издательство "ЛОРИ"
Network Monitoring and Analysis A Protocol Approach to Troubleshooting Ed Wilson Copyright 2000 ; ,,. ; .. , v • .. All rights reserved Мониторинг и анализ сетей Методы выявления неисправностей Эд Уилсон Переводчик О.Труфанов Научный редактор А.Киселева Корректор И.Гришина Верстка Л.Федерякиной ,' {; '^ Copyright © 2000 by Prentice Hall PRT Prentice Hall, Inc. Upper Saddle River, New Jersey 07458 ISBN 0-13-026495-4 © Издательство "ЛОРИ", 2002 Изд. N : OAI @3) ЛР N : 070612 30.09.97 г. ISBN 5-85582-163-3 Подписано в печать 03.04.2002 Формат 70x100/16 Гарнитура Нью-Баскервиль Печать офсетная Печ.л. 23 Тираж 3200 Заказ N 2138. Цена договорная Издательство "ЛОРИ". Москва, 123557 Б. Тишинский пер., д. 40, корп. 2 Телефон для оптовых покупателей: @95J59-01-62 www.lory-press.ru Отпечатано с готовых диапозитивов в ФГУП Издательство «Известия» Управления делами Президента РФ 101999, ГСП-9, г. Москва, К-6, Пушкинская пл., д. 5.
Посвящается моей жене и другу Терезе
Предисловие Компания Full Service Networking продает и поддерживает компьютерные сети для большого числа заказчиков. Основная часть нашего бизнеса со- состоит в обслуживании критически важных LAN и WAN для растущей базы заказчиков. Ключевым моментом в предоставлении этой службы является возможность быстро реагировать на множество сетевых проблем — часто с беспокойным пользователем, требующим немедленных ответов на сложные вопросы. Другим важным моментом являются постоянные изменения в базовой сетевой технологии. Это требует как специализации, так и интенсивной подготовки технического персонала для понимания особенностей новых технологий. Компания Microsoft, как и другие компании, работающие в этой отрас- отрасли, регулярно обновляет свои сетевые продукты. Мы работаем в отрасли, в которой постоянно выпускаются новые продукты. Их число растет экспо- экспоненциально, так как технологии стремительно развиваются. Как справиться с этой ситуацией и гарантировать высокий уровень об- обслуживания пользователей сетей? Ответственность лежит на инженерах, обслуживающих сеть на местах. Они должны работать более грамотно и эффективно. Сетевой инженер, хорошо понимающий процедуры и инструменты мо- мониторинга и анализа сложной сети, способен идентифицировать и разре- разрешить возникающие проблемы быстро и грамотно. Эти же инструменты поистине бесценны при профилактической работе с сетью для обнаруже- обнаружения потенциальных проблем, прежде чем они станут критическими. Книга "Мониторинг и анализ сетей: методы выявления неисправностей" даст се- сетевому инженеру возможность работать более эффективно. Джеймс Нармор Президент Full Service Networking
Введение ¦ •' > ¦ ¦¦!..: . i|. ¦'-¦¦'' .'¦-¦ -л, '¦- (, Вы задумывались когда-нибудь, что происходит внутри сети? Почему она рабо- работает медленно, что приводит к внезапному отказу задания печати или к неожи- неожиданному останову программы? Приходилось ли вам слышать от пользователей, что сервер работает медленно? Хотите ли вы получить лучшее представле- представление о том, какой реально существует трафик? Если так, то эта книга для вас, поскольку она посвящена сетевому мониторингу и анализу — возмож- возможно, наименее понимаемым видам деятельности администраторов сетей. Для многих вопрос состоит не в том, почему необходимо выполнять мо- мониторинг сети; на самом деле это понятно интуитивно. Вопрос в том, где найти для этого время? Прибавьте сюда тот факт, что потребуется время на подготовку и обучение, прежде чем можно будет получить наиболее по- полезную информацию. Возникает внутреннее сопротивление. В некотором смысле это похоже на смену масла в автомобиле. Сделать это необходимо, однако не хочется пачкаться. Время для изучения рабочих инструментов наступает не тогда, когда сеть не работает, а когда все идет хорошо. Мониторинг сети оставляет от- открытой дверь для потока коммуникации данных, позволяя лучше понять происходящие процессы. В книге дано множество советов и рекомендаций о возможностях дальнейшего исследования. Фактически будет предложена масса идей о настройке регулярного мониторинга и программы анализа. Отдельными областями, для которых это будет наиболее полезно, являют- являются поиск неисправностей, оптимизация и вопросы безопасности. Каждая из них заслуживает существенного внимания. В этой книге будут рассмотрены протоколы, которые, как правило, присут- присутствуют в сети, и описаны источники трафика. Исходя из этого рассматривает- рассматривается план тонкой настройки коммуникационных сценариев и предлагаются решения, которые работают в реальной жизни. Когда трафик оценен, мож- можно предсказать эффект добавления в сеть дополнительных служб или компьютеров. Это позволяет избавиться от реагирующего режима поиска фантомов и получить профилактический сбалансированный подход к управлению сетью. Предсказывая трафик, можно определить требования инфраструктуры и реализовать решения, прежде чем потребность в них появится у пользователей. t ¦ ,; , . .¦ Зачем используется мониторинг сети Сети — довольно шумное место. При рассмотрении сетевых записей преж- прежде всего бросается в глаза огромный объем данных, который переносится по проводам каждую секунду. Удивительно, что такое большое количество
viii Введение данных не теряется. Мы рассмотрим несколько способов уменьшения этого "шума". Однако при оптимизации сети правило: "Ничто не бывает бесплат- бесплатно" остается как никогда справедливым. При настройке операционной сис- системы необходимо проверить, от чего мы отказываемся, чтобы сократить часть трафика. Во многих ситуациях можно сделать изменения, не отбрасы- отбрасывая ничего существенного. В любом случае это должно быть тщательно взве- взвешенным решением, опирающимся на полное понимание конкретной сетевой конфигурации и функциональности, предоставленных специальной службой или настройкой. Наши советы и рекомендации помогут вам создать порядок из нематериального хаоса. Этот анализ и является нашей задачей при оптимизации сети. Оптимизация сети 1 • ^ . Вооружившись исчерпывающим пониманием протоколов, можно выбрать планы сокращения трафика. Одним из первых рассмотренных вопросов является удаление лишних служб. Как мы узнаем в обзоре протоколов, тра- трафик, связанный с дополнительными протоколами,— это не просто транс- транспорт, но и службы, связанные с протоколом. Каждая служба общается с другими, объявляя или другими способами сообщая о своем присутствии в сети. При простом удалении одной или двух служб можно сократить трафик в сети на 5-10 процентов. Чтобы использовать только необходимые в сети протоколы, необходимо знать, что такое протоколы, и где они используются. Поэтому в первом раз- разделе книги исследуются наиболее часто используемые протоколы и рассмат- рассматриваются их детали, чтобы понять, как они работают. С этими знаниями можно разработать некоторые методологии оптимизации. Мы увидим, ка- какие протоколы нам нужны, а какие нет. Мы получим уверенность при работе только с одним протоколом и избежим стремления "держать один про за- запас". Помимо потока излишнего трафика, сетевая коммуникация слишком замедляется, когда программы делают многочисленные попытки найти общий протокол. Невозможно выполнить точную базовую оценку производительности с по- помощью Сетевого монитора компании Microsoft (Microsoft Network Monitor) (хотя некоторые другие продукты, доступные в настоящее время, могут это сделать), но можно получить хорошее представление об использовании сети и вручную определить подходящие статистики в электронной таблице или базе данных. После отключения служб, сокращения числа протоколов и оптимизации того, что остается, можно будет построить графики изме- изменения производительности. Вы увидите, что процент использования, ши- широковещание и ошибки CRC падают вниз, как осенние листья после первого дождя. Вооружившись документами, полученными на этом этапе, можно переходить к планированию расширения. Планирование расширения • , .^л>/; ' . j Ц;>*>й Всякий раз при добавлении к сети новых рабочих станций, принтеров, сер- серверов или служб необходимо иметь четкое представление о том, как это по- повлияет на вычислительную среду. При планировании расширения следует
Введение ix представлять, где и какое влияние будет оказано на сеть. Бремя трафика, скорее всего, будет значительно больше, чем при простом общении новой машины с сервером. Если новая машина выполняет службы общего доступа к файлам, то она тем или иным образом будет объявлять о своем присутст- присутствии. Когда этот компьютер объявляет о готовности к работе, какое количе- количество трафика будет создаваться? Какое влияние это окажет на остальную часть сегмента? Если это единственный сегмент, то как насчет других ма- машин, также использующих этот кабель? Каким будет действие на маршрути- маршрутизатор или на коммутатор? Эти вещи необходимо рассмотреть, и именно о них пойдет речь в данном разделе. Вопросы безопасности Мониторинг сети может быть очень полезен для борьбы с разбушевавшими- разбушевавшимися хакерами. Хотя они и смогут проникнуть в сеть незамеченными — либо украв пароли, либо обходя систему безопасности — они не смогут скрыть свою деятельность, уже находясь внутри. Низкоуровневый сетевой монитор может видеть все. Как же обнаружить хакеров в сетевом окружении? Незаконный сервер DHCP является особенно неприятным. Сервер DHCP располагается в сети, получает клиентский запрос IP-адреса, а затем выдает свои собственные адреса. Они могут быть законными или незакон- незаконными для сети или дублировать незаконные адреса, создавая в сети боль- большие проблемы. В реальности мониторинг сети является лучшим способом найти незаконный сервер DHCP. Сетевой монитор Microsoft версии 2 упрощает выполнение этой задачи. Много лет назад высшие чины ВМФ США поняли, что самым лучшим способом борьбы с подводными лодками являются собственные подводные лодки. Эти молчаливые смертоносные устройства были намеренно созданы так, чтобы их невозможно было обнаружить. Так был рожден класс подвод- подводных лодок под названием "быстрая атака". Таким же образом единственным способом обнаружить нелегальное прослушивание сети является использо- использование сетевого монитора. Почти все инструменты в этом классе помогут в обнаружении тайного прослушивания. Сетевой монитор версии 2 может даже отключить неавторизованное прослушивание. Имитация IP-адреса является любимым приемом хакеров, когда один компьютер маскирует другой, используя IP-адрес другой машины и затем отвечая на запросы, адресованные кому-то другому. Можно обнаружить имитацию адреса, запуская утилиту сетевого мониторинга. Имитация IP-ад- IP-адреса может происходить также при неправильной конфигурации маршру- маршрутизаторов. В этом случае машина отвечает на запросы, направленные другой машине с тем же IP-адресом. Это может вызвать большие проблемы, прежде чем ошибка будет обнаружена. Поиск неисправностей Очевидно, что неработающую плату Ethernet обнаружить легко. Однако карту, которая считает себя хорошей и реально передает и получает время от времени информацию, найти значительно трудней. Это называется
Введение нестабильной работой. Карта Ethernet заполняет сеть фиктивной ин- информацией, приводя к замедлению всей коммуникации в сети. Это можно обнаружить с помощью инструментов мониторинга сети. Одно плохое приложение может повлиять на любую другую программу, работающую в сети. Плохие приложения могут проявить себя множеством различных способов. Они могут искать файлы, которые находятся не здесь, вызывая излишнюю нагрузку поиска на сервере, или даже создавать ненужный трафик. Мы рассмотрим несколько типичных сценариев и раз- разработаем схему, которую можно использовать для поиска других проблем в этой области. Мониторинг сети превосходно помогает разрешить трудные проблемы соединения. Очевидно, что если используется TCP/IP, то для тестирова- тестирования основной коммуникации между машинами можно сделать эхо-запрос (ping). Но это только первый шаг. Темой данного раздела является ситуация, когда ping работает, а общение с сервером невозможно. Аудитория >* ^ Эта книга предназначена прежде всего для сетевых администраторов, сис- системных архитекторов, технического персонала и всех, кто поддерживает Windows NT (хотя она будет полезна и тем, кто непосредственно не поддер- поддерживает Windows NT, так как протоколы по сути являются одинаковыми, не- независимо от платформы, на которой они используются). Книга также пригодится тем, кто готовится к сдаче экзаменов на сертификат MCSE, Cisco CCNA или Comptia Network Plus. Эта книга не покажется вам слишком слож- сложной. Здесь не предполагается знание вами протоколов или опыт работы с продуктами, поскольку они рассматриваются в ходе изложения материала. Основные понятия TCP/IP, DHCP, DNS и WINS будут полезны, так как они используются в некоторых из примеров. Если вы хотите выполнять мони- мониторинг и анализ сети и/или стремитесь научиться искать неисправности и оптимизировать сетевую коммуникацию, эта книга вам поможет. Структура книги ..i.;<...... В этой книге мониторинг и анализ сети рассматриваются с точки зрения протоколов. В примерах поиска неисправностей большей частью будет использоваться сетевой монитор компании Microsoft (называемый иначе Netmon). В настоящее время существуют четыре различные версии это- этого инструмента, которые сравниваются в книге. Называвшийся вначале bloodhound, Netmon немного изменился с момента своего появления. Еще более усложняет ситуацию интерфейс, который не очень понятен интуитив- интуитивно, а файлы оперативной помощи мало помогают разобраться в реальном использовании продукта. Мы закроем этот пробел и расскажем, как получить максимум пользы от этого мощного инструмента. Будут показаны типичные сценарии использо- использования, указаны потенциальные ловушки и рассмотрены реальные приме- примеры. Затем, после обзора модели OSI и самих протоколов, мы используем
Введение xi наши знания взаимосвязи протоколов для использования всей мощи сете- сетевого монитора. В заключение рассматривается взаимодействие протоко- протоколов друг с другом. Эта информация поможет понять, что мы разыскиваем в полях кадров. Мы становимся единым целым с сетью, так как говорим на языке наших машин. Мы покажем, как использовать сетевой монитор для анализа трафика сети и как искать неисправности с помощью этого инструмента. Мы рас- рассмотрим различные сценарии оптимизации и дадим множество информа- информации для размышлений. Прочитав эту книгу, вы увидите сеть в новом свете. Окончательным результатом станет умение использовать существующие инструменты для поиска неисправностей. Наш подход в определенной степени управляется нашей задачей, т.е. мы будем двигаться от общего к частному. Этот путь приведет нас в бурное море, но имея фундамент, заложенный в первой части, мы сможем уверенно в нем плавать. Часть I. Анализ протоколов: участники взаимодействия Чтобы правильно выполнить сетевой мониторинг и анализ, необходимб знать, что именно мы ищем. Эта часть книги поможет понять, что удержива- удерживает многих из нас от использования этих важных инструментов. Рассматри- Рассматривая повседневные протоколы и изучая связанные с ними характеристики, мы научимся более эффективно искать неисправности в сети. Глава 1: "Основные сетевые модели" начинается с модели взаимодействия открытых систем и модификаций, сделанных проектом IEEE 802. Мы рас- рассмотрим, как формируются пакеты, а также и способ, которым протоколы со всем этим работают. ,, . • .'• t: . : ' Глава 2: "Стек протоколов TCP/IP' представляет собой введение в этот про- протокол. Большая часть книги будет посвящена работе с протоколом управле- управления передачей, протоколу взаимодействия сетей и их "родственникам". < В главе 3: "Стек протоколов IPX/SPX' изучается протокол пакетного обме- обмена Интернета и протокол упорядоченного обмена пакетами. Мы рассмот- рассмотрим, как формируются пакеты, а также роль протокола объявления службы и как он осуществляет разрешение имени. Глава 4: "Блоки сообщений cepeepd' является основой изучения коммуникации сетевых компьютеров. Часть II. Анализ сетевого трафика и оптимизация: существующие проблемы Во второй части книги мы рассмотрим трафик с четырех различных точек зрения, а затем предложим рекомендации для сокращения трафика в каж- каждом из случаев. В главе 5: "Клиентский трафик" рассматриваются некоторые из источни- источников трафика клиента, включая просмотр ресурсов сети и попытки разреше- разрешения имени для коммуникации с другими машинами.
xii Введение В главе 6: "Серверный трафик!' обсуждаются некоторые источники трафи- трафика сервера, включая репликацию каталогов и ответы на запросы DNS. Глава 7: "Трафик приложений" посвящена трафику, связанному непосред- непосредственно с приложениями, такими как работа с файлами и печать, просмотр Интернета и даже программы e-mail. Часть III. Сетевые мониторы: инструменты работы Теперь мы переходим к интересному материалу — инструментам работы. Компания Microsoft предлагает несколько хороших, доступных и достаточ- достаточно мощных инструментов. В главе 8: "Семейство сетевых мониторов компании Microsoft' выделены как минимум три различных инструментальных набора сетевого монитора компании Microsoft. Здесь рассматриваются инструменты и связанные с ними вопросы, а также приемы для получения максимума возможного из этих недоработанных инструментов. Часть IV. Сценарии поиска неисправностей: „ \ рассмотрение общих проблем В данной части знания о протоколах и инструментах мониторинга сети применяются к некоторым проблемам реального мира. Вооруженные мощ- мощными инструментами мониторинга сети, мы сможем решать сложные проблемы. ¦• - ¦ : ". , .... В главе 9: "Проблемы соединения" рассматривается старый сценарий "Я не могу войти в сеть!". Существует, конечно, много вариантов, и иногда случа- случается видеть рабочую станцию, которая не может найти контроллер домена, получить адрес от DHCP или соединиться с сервером. Возможно, это проб- проблема пароля или другой вопрос регистрации. Эти проблемы просто не мо- могут пройти незамеченными для хорошо настроенного сетевого монитора. К сожалению, некоторые приложения не вполне отлажены к моменту свое- своего выпуска и поступают в производство преждевременно. Во многих случа- случаях не отловленные вовремя ошибки исправляются в последующих версиях. Но как понять, что та или иная проблема решается установкой пакета исп- исправлений? Чрезмерное широковещание, низкая сетевая производитель- производительность и нераспределенные страницы являются кандидатами для проверки с помощью Netmon. Глава 10: "Вопросы безопасности" посвящена использованию анализатора трафика. Здесь рассматриваются незаконные серверы DHCP, неавторизо- неавторизованный просмотр пакетов и т.п. На сайте издательства "ЛОРИ" (www.lory-press.ru) находятся копии файлов примеров, упомянутых в книге, фильтры, которые можно загру- загрузить в Microsoft Network Monitor для поиска неисправностей, а также несколько примеров пакетных файлов, которые можно использовать для за- запуска необслуживаемых сеансов Netmon с помощью службы планировщика Microsoft Windows NT.
Благодарности В реализации этого проекта помогали множество людей. В частности, большую часть книги изучил и прокомментировал технический пер- персонал Full Service Networking. Дэвид Мартин прочитал всю книгу не- несколько раз и поделился отличными идеями. Марк Грос и Джейсон Веббер потратили несколько выходных, чтобы создать почти все файлы сетевых примеров. Тереза Вилсон сделала некоторые рисунки. Об авторе Эд Уилсон, MCSE + I, MCT, Master ASE, CCNA — старший специа- специалист по компьютерным сетям в компании Full Service Networking (Цинцинатти, штат Огайо), являющейся партнером Microsoft по развертыванию решений. Он автор нескольких книг, посвященных работе с сетями и подготовке к экзаменам MCSE.
Содержание ЧАСТЬ I Анализ протоколов: участники взаимодействия 1 Глава 1 Базовые сетевые модели ¦ ¦ • ¦ ¦ 3 Модель 0SI 3 Уровень приложений 6 Уровень представлений 7 Сеансовый уровень 8 Транспортный уровень 9 Сетевой уровень 10 Канальный уровень 11 Физический уровень 12 Проект IEEE 802 13 Усовершенствования, сделанные в модели OSI 13 Подуровень управления логическим каналом (LLC) 13 Подуровень управления доступом к среде передачи (MAC) 15 Как данные перемещаются по проводам 15 Процесс создания пакета 16 Особенности коммуникации в сетях Ethernet 18 Какова во всем этом роль протоколов? 21 Стек протоколов 21 Иерархический подход 22 Как все это объединяется? 24 Прикладные протоколы 26 Транспортные протоколы 26 Сетевые протоколы 27 Сетевая служба с поддержкой соединения 27 Сетевая служба без поддержки соединения 28 Адресация на канальном уровне 29 Адресация на сетевом уровне 29 Инкапсуляция данных 30 Реализация IP поверх различных стандартов LAN 31 Управление потоком 35 Функции межсетевого обмена сетевого уровня OSI 36 Службы WAN 36 Обзор главы 41 В следующей главе 42 Глава 2 Стек протоколов TCP/IP 43 Протокол TCP 46 Заголовок TCP 47 Трехходовое квитирование 50 Концепция времени молчания TCP 52 Полуоткрытые соединения и другие аномалии 53 Генерация команды сброса 54 Обработка команды сброса 55 Сценарий 1: локальный пользователь инициирует закрытие 56 Сценарий 2: TCP получает FIN из сети 56
Содержание xv Сценарий 3: оба пользователя закрывают соединение одновременно '57 Обмен срочной информацией 57 Управление окном 57 Интерфейс пользователь/TCP 59 Команды пользователя TCP 59 Send (Послать) 60 Receive (Получить) 62 Close (Закрыть) 62 Status Abort (Прервать) 63 TCP/Низкоуровневый интерфейс 63 Происходящие события: пользовательские вызовы 64 Состояние прослушивания 65 Вызов SEND (Послать) 65 Протокол IP 67 Заголовок IP ¦ 71 Обзор главы 84 В следующей главе • ¦ • 84 Глава 3 Стек протоколов SPX/IPX 85 Протокол SPX 85 Заголовок SPX 85 Протокол IPX 91 Протокол без соединения 91 Работа на сетевом уровне модели OSI 91 Структура пакета • • • 92 Адресация IPX 95 Сетевой номер 95 Зарезервированные сетевые номера 96 Внутренний сетевой номер 96 Номер узла 96 Номер сокета 97 Как работает маршрутизация IPX 98 Интерфейсы сеансов и дейтаграмм 100 Структуры заголовка сообщений 101 Обзор главы 103 В следующей главе 103 Глава 4 Блоки сообщений сервера 104 Обзор работы SMB 105 Определение имени сервера 105 Разрешение имени сервера 106 Транспорт сообщения 106 Пример потока сообщений 106 Согласование диалекта 108 Создание соединения 108 Обратная совместимость 109 Настройка сеанса 109 Управление соединением 109 Подпись SMB 110 Оппортунистические блокировки 110 Исключающая oplock ¦ • • 111 Пакетная блокировка oplock 112 Level II Oplocks 114
xvi Содержание Модель безопасности 115 Пример доступа/общего ресурса 116 Аутентификация 117 Поддержка распределенной файловой системы (DFS) 118 Заголовок SMB 119 ПолеТЮ 120 ПолеШ) 120 ПолеРЮ 120 Поле MID 121 Поле флагов 121 ПолеНадэг 123 Поле состояния 123 Задержки 124 Буфер данных (SUFFER) и форматы строк 124 Кодирование режима доступа 125 Кодирование функции открытия (Open) 126 Кодирование действия открытия (Open) 126 Кодирование атрибутов файла 127 Кодирование расширенных атрибутов файла 127 Пакетные запросы (Сообщения "AndX") 128 Обзор главы 130 В следующей главе 130 ЧАСТЬ II Сетевой трафик Анализ и оптимизация: взгляд на проблемы 131 Глава 5 Клиентский трафик 133 Инициализация клиента f4'+; . . 133 Трафик DHCP 134 Трафик клиента WINS 142 Регистрация имен и обновление 142 Трафик регистрации в системе 147 Поиск сервера регистрации 148 Оптимизация регистрации в сети 156 Просмотр 159 Объявления хостов броузеров 161 Где находятся резервные броузеры? 163 Оптимизация трафика броузера 165 Обзор главы 166 В следующей главе 166 Глава 6 Серверный трафик 167 DNS 167 Разрешение адреса « • •;¦"•"•¦. ; ... 167 Рекурсивный поиск 169 Объединение с WINS 170 Оптимизация DNS 170 Инициализация BDC 170 Где находится PDC? 171 Обновления в базе данных 184 Оптимизация трафика синхронизации учетных записей 186 Служба NetLogon 186
Содержание xvii Обзор главы 190 В следующей главе 190 Глава 7 Трафик приложений 191 Работа с файлами и печать 191 Запрос WINS 191 Широковещание 192 ARP 193 Трехходовое квитирование 194 Сеанс NetBIOS 195 Согласование диалекта SMB 196 Просмотр Интернета 201 Страницы Web 201 Secure Sockets Layer ¦ • ¦ • 207 Оптимизация трафика броузера в интрасети 208 Обзор главы 209 В следующей главе 209 Глава 8 Exchange и почта Интернета 210 Exchange 210 Открытие и закрытие сеанса 213 Сервер Exchange в действии 214 Протокол РОРЗ 216 Общение Exchange с другим сервером 226 Обзор главы 229 В следующей главе 229 ЧАСТЬ III Сетевые мониторы: инструментальные средства работы ¦ 231 Глава 9 Семейство сетевых мониторов компании Microsoft 233 Сетевой монитор 233 Создание перехвата 234 Перехват трафика вручную 236 Просмотр перехваченных данных 238 Сохранение перехваченных данных 239 Фильтрация данных перехвата 240 Анализ перехваченных данных 242 Система безопасности сетевого монитора 245 Защита с помощью пароля 246 Установка сетевого монитора: обнаружение других мониторов 247 Сетевой монитор Systems Management Server 1.2 249 Дополнительные свойства 249 Соединение с удаленными агентами 251 Мастера-помощники 252 Конфигурирование триггеров 254 Network Monitor 2.0 256 Новые свойства 256 А вот это не работает 259 Дополнительные свойства безопасности 259 Обзор главы 263 В следующей главе 264
xviii Содержание ЧАСТЬ IV Сценарии поиска неисправностей: распространенные проблемы 265 Глава 10 Вопросы поиска неисправностей 267 Рабочая станция не может зарегистрироваться 267 Можно ли сделать ping сервера? 267 Рассмотрим случай с портативным компьютером 272 Рабочая станция не может получить выделяемый DHCP адрес 272 Взгляд на диалог 273 Проанализируйте, что пропущено 273 Рабочая станция работает медленно 275 Можно ли точно определить понятие "медленная"? 275 Что является источником недовольства? 275 Проблемы с регистрацией 276 Я пытаюсь аутентифицироваться, но где? 277 Странные ошибки журнала событий 281 Метод поиска серверных проблем 281 Выполнение без сопровождения 283 Избыточное широковещание 285 Кто это делает? 285 Почему они это делают? 287 Обзор главы 288 В следующей главе 288 Глава 11 Вопросы безопасности 289 Нелегальные серверы DHCP 289 Есть ли у меня для вас адрес? 289 Итак, где вы? 294 Нелегальный анализ сети ("вынюхивание") 294 Прежде всего необходимо их найти 295 Как отбить нюх чужим ищейкам 295 Обзор главы 296 Приложение А Список общеизвестных номеров портов TCP и UDP 297 Приложение В Утилиты командной строки 310 Приложение С Общие NCP 312 Приложение D Поиск обычных сетевых ошибок 321 Приложение Е Суффиксы NetBIOS 323 Приложение F Запуск контроллера домена • ¦ • 325 Приложение G Открытие страницы Web 336 Глоссарий 347
ЧАСТЬ I Анализ протоколов: участники взаимодействия . тобы правильно выполнить мониторинг и анализ сети, необходимо по- понимать, что требуется найти. Недостаточное знакомство с принципами работы сети часто удерживает многих от использования важных инстру- инструментов. Однако при рассмотрении более общих протоколов невозможно обойтись и без общих понятий, связанных с ними. Понимая, на что же фактически нацелен поиск неисправностей, вы сможете более эффективно осуществлять его в сети.
Глава 1 Базовые сетевые модели В этой главе рассматривается модель взаимодействия открытых систем (OSI) и приводятся примеры ее использования для мониторинга сети. Будут также обсуждаться модификации, сделанные в модели OSI рабочей группой IEEE 802. Затем остановимся на передаче данных по носителю в сети, а в заключение рассмотрим роль протоколов в этом процессе. _ Сетевые модели помогают нам представить себе способ, с помощью кото- которого компьютеры общаются друг с другом, и проанализировать работу сети с помощью инструментов мониторинга. Они очень важны для понимания протоколов и потока данных, а также для изучения сетевой оптимизации и сценариев поиска неисправностей. Модель OSI ~ \ Первый шаг в изучении мониторинга сети состоит в рассмотрении модели OSI. Эта модель создаст базовое понимание того, как работают протоколы. Модель OSI была разработана в 1984 г. Международной организацией по стандартизации (ISO) в качестве руководства по организации сетей переда- передачи данных. Она заменила спецификацию ISO 1978 г., разработанную для того, чтобы различные устройства могли обмениваться данными с помо- помощью однотипных протоколов. Модель OSI 1984 г. является международной "классикой", которой удовлетворяют практически все сетевые архитекту- архитектуры. Большинство реализаций конкретных сетей не совпадает с моделью OSI в точности, но в любой такой реализации функции, описанные моде- моделью, должны некоторым образом выполняться (или по крайней мере при- приниматься в расчет). Ценность модели OSI в качестве инструмента поиска неисправностей состоит в описании видов деятельности, или функций. На- Например, имея точное представление о том, что делает сценарий ("да, я могу сделать это, это и еще это, а вот это уже не могу"), можно точно локализо- локализовать проблему.
Глава 1 Модель OSI четко описывает функции и часто используется производи- производителями оборудования в качестве руководства по реализации необходимых свойств в своих конструкциях. Можно увидеть, как оборудование и про- программное обеспечение совместно обеспечивают надежную и эффективную коммуникацию между устройствами. В ходе изложения этой книги мы бу- будем постоянно ссылаться на модель OSI. Модель OSI представляет собой многоуровневый подход к коммуника- коммуникации, и каждый ее уровень предоставляет службы для нижележащего и вы- вышележащего уровня в иерархии. На рис. 1.1 изображены семь уровней модели OSI. Самый высокий уровень, седьмой, на схемах и рисунках обычно изобра- изображается сверху, так как именно на этом уровне находятся приложения и по- пользовательский интерфейс, если он вообще имеется. Два самых нижних уровня, первый и второй, соответствуют кабелям и сетевым адаптерам. 7. Уровень приложений 6. Уровень представлений 5. Сеансовый уровень 4. Транспортный уровень 3. Сетевой уровень 2. Канальный уровень 1. Физический уровень Рис. 1.1. Семиуровневая модель взаимодействия открытых систем является основой для понимания работы современных компьютерных сетей и поиска в них неисправностей
Базовые сетевые модели Для иллюстрации того, как происходит коммуникация данных в сетевой среде, можно рассмотреть аналогию с телефонной связью. Когда вы снимае- снимаете трубку и набираете номер, используются службы, предоставляемые теле- телефонной компанией. Телефон взаимодействует с проводами и другими элементами инфраструктуры телефонной сети. Звоня по телефону, мы мо- можем ничего не знать о проводах и другом оборудовании. Абоненты разгова- разговаривают как будто непосредственно друг с другом, оставив технические подробности оборудованию и специалистам. Модель OSI работает таким же образом. Уровень приложений на одной машине вступает в виртуальный диалог с уровнем приложений на другой машине, причем они ничего не знают о том, какую работу выполняют другие уровни. 7. Уровень приложений 1? 1L 5. Сеансовый уровень 4. Транспортный уровень 3. Сетевой уровень 1? 2. Канальный уровень 1? 1. Физический уровень 6. Уровень представлений 7. Уровень приложений 1? 6. Уровень представлений 1? 5. Сеансовый уровень 4. Транспортный уровень 3. Сетевой уровень 2. Канальный уровень 1. Физический уровень Рис. 1.2. Обмен данными с точки зрения каждого уровня модели 0SI и фактический обмен данными
Глава 1 На рис. 1.2 показано, что каждый уровень модели OSI считает, что он об- общается с тем же уровнем на другой машине. В реальности каждый уровень взаимодействует только с уровнями выше и ниже его в иерархии. Каждый уровень отвечает за выполнение определенных функций в соответствии с используемыми протоколами. Когда приложение хочет послать данные другому приложению, они пе- передаются из уровня приложений в нижележащий и т.д. по всему стеку про- протоколов. Каждый уровень будет добавлять заголовочную информацию, которая помогает ему в выполнении его специфической функции. В неко- некоторых случаях уровень может добавить не только заголовок, но и конце- вик. Данные разбиваются на куски, чтобы облегчить их передачу по сети. Данные, полученные из протокола TCP (транспортный уровень), называ- называются сегментом, но когда к ним на сетевом уровне добавляется заголовоч- заголовочная информация протокола IP, полученный блок данных становится пакетом, или дейтаграммой. Когда блок данных перемещается по кабелю в направлении своего места назначения, он называется кадром. Термины па- пакет и кадр иногда (хотя технически неправильно) используются как сино- синонимы. Чтобы быть полностью точными, пакет — это данные сетевого уровня, а кадр — это данные, передаваемые по кабелю. Данные передаются затем с уровня на уровень, и каждый уровень будет добавлять или убирать что-то из пакета согласно тому, где это происходит. На принимающем кон- конце линии связи происходит обратный процесс: данные поступают из кабе- кабеля на физическом уровне и перемещаются вверх, пока не прибудут на уровень приложений в том виде, в котором они были отправлены другим приложением. Только физический уровень фактически обменивается дан- данными со своим аналогом на другой машине. Взаимодействие между смеж- смежными уровнями происходит через интерфейс, который определяет, какие службы тот или иной уровень предоставляет уровню выше или ниже в иерархии. Теперь более подробно рассмотрим с этой точки зрения службы, предоставляемые каждым уровнем модели OSI. Уровень приложений Седьмой уровень, или уровень приложений, является самым верхним в моде- модели OSI и служит в качестве окна для доступа приложений к сетевым службам. Этот уровень непосредственно поддерживает приложения пользователя, но здесь располагаются не такие приложения, как Word или Excel. Они не явля- являются частью модели OSI. Приложениями, которые располагаются здесь, яв- являются Telnet, FTP и т.п. Этот уровень отвечает за общий доступ к сети, управление потоком и восстановление после ошибок. Уровень приложений взаимодействует с программными приложения- приложениями, которые реализуют или поддерживают коммуникационный компонент сетевого приложения. Сетевые приложения — пересылка файлов, e-mail, управление сетью, удаленный доступ и т.п. Функции уровня приложений обычно включают: • Идентификация коммуникационных партнеров — уровень приложе- приложений идентифицирует и определяет доступность коммуникационных партнеров для приложения, которое имеет данные для передачи.
Базовые сетевые модели • Определение доступности ресурсов — уровень приложений должен определить, достаточно ли доступных сетевых ресурсов для запро- запрошенной коммуникации. • Синхронизации коммуникации — коммуникация между приложениями требует согласованности, за которую отвечает уровень приложений. Уровень приложений является ближайшим к конечному пользователю уровнем OSI. То есть как уровень приложений OSI, так и пользователь не- непосредственно взаимодействуют с программным приложением. Несколько примеров реализаций уровня приложений: • Приложения TCP/IP — это такие протоколы из стека протоколов Интернета, как Telnet, протокол передачи файлов FTP и почтовый протокол SMTP. • Приложения OSI — это такие протоколы из стека OSI, как FTAM, VTP иСМ1Р. . Уровень представлений . Шестой уровень, уровень представлений, определяет формат, используе- используемый для пересылки данных между компьютерами. Его можно назвать сете- сетевым транслятором, так как он участвует в преобразовании данных из формата, поступающего из уровня приложений, в принятый промежуточ- промежуточный формат. На получающем компьютере уровень представлений преобра- преобразует данные обратно в формат, в котором уровень приложений другого компьютера их послал. Некоторыми из обычных видов деятельности, вы- выполняемых уровнем представлений, являются преобразование протоколов, трансляция данных, шифрование данных, изменение или преобразование множества символов и расширение графических команд. Уровень представ- представления управляет также сжатием данных для сокращения числа битов, необ- необходимых для передачи данных. Редиректор, который отвечает за решение, где получить данные для операций ввода или вывода ресурсов на сервере, располагается в уровне представления. Уровень представлений предоставляет множество функций кодирова- кодирования и преобразования, которые применимы к данным уровня приложений. Эти функции гарантируют, что информация, посланная из уровня прило- приложений одной системы, будет читаема уровнем приложений другой систе- системы. Некоторыми примерами схем кодирования и преобразования уровня представлений являются следующие: . ..:¦•.¦ • Общие форматы представления данных — использование стандарт- стандартных форматов изображений, звука и видео позволяет обмениваться данными приложений между различными типами компьютерных систем (JPEG, MPEG, GIF и т.д.). • Преобразование форматов представления символов — схемы преоб- преобразования используются для обмена информацией с системами, испо- использующими различные представления текста и данных (например, EBCDIC, ASCII и все более популярный язык разметки гипертекста
Глава 1 HTML, который описывает, как информация должна быть представ- представлена при просмотре в Web-браузере, таком как Internet Explorer или Opera). • Общие схемы сжатия данных — использование стандартных схем сжа- сжатия данных позволяет правильно восстановить в месте назначения данные, которые сжаты на устройстве источника. • Общие схемы шифрования данных — использование стандартных схем шифрования данных позволяет правильно расшифровать в ме- месте назначения данные, которые были зашифрованы на устройстве источника. Реализации уровня представлений обычно не связаны с определенным стеком протоколов. Некоторыми хорошо известными стандартами являются: • Данные: ASCII, EBCDIC, шифрование • Визуальные изображения: PICT, TIFF, GIF, JPEG • Аудио и видео: MIDI, MPEG, QuickTime " Ч ''"' '•• Сеансовый уровень Пятый уровень, сеансовый, позволят приложениям на различных компью- компьютерах настраивать, управлять и завершать общение, называемое сеансом. Он предоставляет свойства, которые естественно считать необходимыми на этом уровне, например распознавание имени и обеспечение безопасно- безопасности. Обеспечение безопасности требуется, чтобы помешать посторонним соединиться с компьютером через сеть. Другими свойствами, которые можно увидеть на этом уровне, являются инструменты для управления ком- коммуникацией машин во время сеанса. Здесь также находятся средства восста- восстановления данных, например контрольные точки между общающимися приложениями. Это позволяет машине знать, что было послано и когда. Критически важно, чтобы эта функция выполнялась — в частности, в нена- ненадежных сетях (таких как Интернет). При потере данных их придется по- повторно передавать только с момента последней контрольной точки. Этот уровень реализует также управление диалогом между общающимися про- процессами. Он определяет, какая сторона передает, когда и как долго. Таким образом, сеанс отвечает за управление запросами и ответами всех служб, которые происходят между приложениями, выполняющимися на двух раз- различных компьютерах. Сеансовый уровень создает, управляет и прекращает коммуникацион- коммуникационные сеансы между сущностями уровня представлений. Сеансы коммуни- коммуникации состоят из запросов и ответов служб, которые происходят между приложениями, расположенными в различных сетевых устройствах. Эти запросы и ответы координируются протоколами, реализованными на уровне сеанса. Некоторыми примерами реализаций уровня сеанса яв- являются следующие: AppleTalk Session Protocol, DEC SCP, NFS, SQL, RPC и реализации X Windows.
Базовые сетевые модели Транспортный уровень Четвертый уровень, транспортный, предоставляет дополнительный уро- уровень соединения под уровнем сеанса и тем самым определяет двухточечное соединение между приложениями хостов. Транспортный уровень отвечает за обеспечение доставки пакетов без ошибок, в определенной последовате- последовательности и без потерь и дублирования. На этом уровне перепаковываются со- сообщения, полученные из верхних уровней, при необходимости разделяются длинные сообщения на более мелкие пакеты, собираются вместе несколько небольших сообщений и помещаются в большие пакеты. Эта перепаковка позволяет передавать пакеты по сети более эффективно. В принимающей системе транспортный уровень снова собирает первоначальные сообщения и обычно посылает подтверждение отправителю. Транспортный уровень отвечает за сквозную обработку. Это логическая связь. Транспортный слой предоставляет функции управления потоком, обработки ошибок и решения проблем, связанных с передачей и получени- получением пакетов. Именно здесь находится протокол TCP (Transmission Control Protocol - Протокол управления передачей) из стека TCP/IP. Транспорт- Транспортный уровень реализует надежные службы транспортировки данных между сетями. Эти службы являются прозрачными для верхних слоев. Функции транспортного уровня обычно включают: • Управление потоком — организует передачу данных между устройства- устройствами, чтобы передающее устройство не посылало больше данных, чем принимающее устройство может обработать. Это особенно важно в пе- перегруженных сетях, где многие машины могут заполнить сеть инфор- информацией, предназначенной для одного и того же хоста. Было бы очень легко потерять пакеты, если бы не было некоторого способа управле- управления перегрузкой. Прибывшие дейтаграммы хранятся в памяти в буфе- буфере. Если он будет переполнен, прежде чем данные можно будет обработать, TCP имеет возможность послать индикатор неготовности. Он действует как красный свет, чтобы предоставить компьютеру время наверстать упущенное. Когда получатель готов обрабатывать дополни- дополнительные сегменты, он посылает индикатор готовности, и отправитель может снова возобновить передачу. • Мультиплексирование — позволяет передавать данные нескольких при- приложений по одной физической линии. Это достигается за счет много- многоуровневой структуры модели OSI. Различные приложения посылают сегменты в том виде, в котором они получены, и они могут направлять- направляться в одно или несколько мест назначения. Когда поток данных прибы- прибывает на транспортный уровень хоста назначения, он восстанавливается и передается наверх в соответствующее приложение. TCP использует номера портов, чтобы реализовать мультиплексирование. Так как не- несколько различных приложений могут использовать TCP (или UDP) одновременно, протоколы транспортного уровня хранят в заголовке идентификатор. Этот идентификатор является 16-битным номером порта, хранящимся в заголовке. Как TCP, так и UDP используют его для идентификации номера порта источника и номера порта места
10 Глава 1 назначения. Список общепринятых номеров портов содержится в Приложении А. Эти общепринятые номера портов присвоены IANA (Уполномоченным по присвоению номеров Интернета). Это номера между 1 и 1023 для различных серверных служб, таких как telnet, FTP, SMTP и т.п. Номера между 1024 и 5000 могут использоваться приложе- приложениями, создающими временные порты (короткоживущие порты). IPX/SPX использует аналогичную концепцию, хотя порты в этом стеке называются сокетами. • Управление виртуальными каналами — виртуальные каналы создают- •...,, ся, поддерживаются и завершаются на транспортном уровне. Это се- сеанс с поддержкой соединения. Чтобы произошла передача данных, в процесс вовлечены как передающая, так и получающая машины. Не- Невозможно послать данные на машину на этом уровне, не вовлекая обе машины. Инициирующая машина пошлет сообщение синхронизации, чтобы начать передачу, получающая машина подтвердит сообщение синхронизации и включит запрос синхронизированной последователь- последовательности. Когда он будет подтвержден, начнется передача данных. • Контроль ошибок и восстановление — контроль ошибок включает различные механизмы обнаружения ошибок передачи. Восстановле- Восстановление включает выполнение действий (например, запроса на повтор- . >; ную передачу данных) для разрешения любых возникающих ошибок. TCP и SPX требуют положительного подтверждения получения пе- , ' реданных данных. Когда данные передаются, запускается таймер. ,,. Если сигнал АСК (подтверждения) не получен до окончания времени таймера, сегмент посылается повторно. Сетевой уровень Третий уровень, сетевой, отвечает за сообщения адресации и преобразова- преобразование логических адресов и имен в физические адреса. Это уровень также вы- выбирает маршрут от источника к компьютеру назначения. Он определяет, какой путь должны пройти данные, чтобы прибыть на компьютер места на- назначения, на основе таких факторов, как загруженность линий, приоритет службы, маршрутизация и т.д. В дополнение к этим функциям, если сете- сетевой адаптер на маршрутизаторе не может передать фрагмент данных такой величины, который послан компьютером источником, то он будет компен- компенсировать это, разбивая данные на меньшие блоки. В месте назначения по- получающий компьютер будет соответствующим образом восстанавливать данные. Сетевой уровень управляет адресацией устройств и отслеживает расположение устройств в сети. В результате на этом уровне обычно нахо- находятся маршрутизаторы. Протокол IP (Internetwork Protocol, протокол меж- межсетевого обмена) относится к третьему уровню. Сетевой уровень реализует маршрутизацию и связанные с ней функции, которые позволяют нескольким каналам данных объединяться в общую сеть. Это осуществляется с помощью логической адресации (в противополож- противоположность физической адресации) устройств. Сетевой уровень поддерживает как ориентированные на соединение службы, так и службы без соединения из протоколов верхних уровней.
Базовые сетевые модели 11 Канальный уровень ь Второй, канальный уровень отвечает за передачу кадров данных из сетево- сетевого уровня в физический. На принимающей стороне соединения он преоб- преобразует полученные от физического уровня биты в кадры данных. Кадр данных является организованной, логической структурой, в которую мож- можно поместить данные. На рис. 1.3 показан типичный кадр данных. В нем мы видим адрес места назначения, адрес отправителя, тип кадра, длину кадра и данных, а также объем еще не переданной информации. Netwoik МопНм Г6Л0717'1018е<*.орЮе<.»Ш Доюте jjtH> РгакеЩже. _ ISrc KAC_AddrJpst НАС Jkddr Proto.ro lTDcscripf.on 1091 }136 569TSyttopt64E^D6ISvnapt6Q0l60 SHIP IETYPE * x0112 1093 1136 597|Htf KM_DB 1094 1136 617 |Н1ГКН DB -j ' •BROADCAST | SAP •BROADCAST I SAP iGeneral Svc [General Svc [HPS_445030 - Advertising Print (HPS_445030-HTHX - Ucknora Servi" I «¦ETHERHET: 802 3 Length ¦ 60 •¦ETHERHET: Destination address 010081000101 ETHERHET: 1 • Group address ETHERNET: 0. • Universally administered address ;. •¦ETHERHET: Source address : 00008104EED6 ETHERHET: 0 ¦ Ho routing information present ETHERHET: . . .0 • Universally administered address ETHERHET: Frame length . 60 (ОхООЗС) ETHERHET: Data Length 0x0013 A9) ETHERHET: Ethernet Data: Humber o( data bytes remaining • 46 @«002E) -LIT: 01 DSAP-OxAA SSAP-OxAA С IXC DSAP ¦ OxAA INDIVIDUAL : Sub-Hetoork Access Protocol (SNAP) LLC: SSAP - OxAA: COHHAHD : Sub-Net*ork Access Protocol (SNAP) IXC. Frame Category: Unnumbered Frame LLC Command - DI IXC. IXC Data. Humber ol data bytes remaining • 43 (ОжОогВ) ?Ы1Р PTVpr nnut I «I f booooooo "" 00000010 оооооого 00O0003O ill 00 SI 00 01 01 00 00 81 04 ЕЕ L'b 00 13 AA AA 03 00 00 81 01 «I UB 00 00 Cb 04 ЕЕ Ob 0) 1J OJ 00 00 30 01 00 40 iF 3b 53 30 04 S2 ПП n? П4 13 i? c0 S? CF 34 34 Л 30 33 30 00 21 0 9-tSO.F Рг 4451140 II Fi«ne FS 1032^23? Рис. 1.З. Типичный кадр данных включает информацию контроля ошибок и информацию о месте назначения, добавленные на канальном уровне Канальный уровень отвечает за безошибочную передачу этих кадров от одного компьютера другому через физический уровень. Одним из использу- используемых им методов является CRC (контроль с помощью циклического избы- избыточного кода), который представляет информацию для исправления ошибок и проверки, чтобы гарантировать правильность передачи кадра данных. Это "магическое" число позволяет получающему компьютеру знать, что пакет является допустимым. Это позволяет сетевому уровню осу- осуществлять практически безошибочную передачу через сетевое соединение. Обычно канальный уровень посылает кадр и затем ожидает подтвержде- подтверждения от получателя. Канальный уровень получателя обнаруживает любые проблемы с кадром, которые могут происходить во время передачи.
12 Глава 1 Кадры, получение которых не подтверждено, и кадры, поврежденные при передаче, пересылаются повторно. Таким образом, канальный уровень отвечает за уведомление, сетевую топологию и управление потоком. Канальный уровень предоставляет доступ к физической среде и обеспечи- обеспечивает надежный транзит данных через физический канал сети. Здесь определе- определены методы доступа к среде передачи Ethernet, Token Ring и FDDI. Каждая спецификация уровня канала данных определяет различные характеристики сети и протокола, включая: • Физическая адресация — в противоположность сетевой адресации определяет адресацию устройств на канальном уровне. • Сетевая топология — спецификации канального уровня часто опреде- определяют, как должны быть физически соединены устройства (например, по топологии "шина" или "кольцо"). ..,.•/ ¦-.' ".$.¦.•¦••.<¦¦. .vy-^ ^ • Уведомление об ошибках — в частности, сообщает протоколам верхних уровней, что произошла ошибка передачи. • Упорядочивание кадров — включает переупорядочивание кадров, пере- переданных вне последовательности. *,., • ¦¦. • Управление потоком — включает в себя замедление передачи данных, чтобы получающее устройство не получило больше данных, чем оно может обработать за один раз. ' '. .>-"»., s Некоторыми из физических устройств, обычно действующими на Этом уровне, являются мосты и коммутаторы (хотя некоторые из "интел- "интеллектуальных" современных коммутаторов способны захватывать и третий уровень). ¦ _¦ v Физический уровень ^-'-^"'-¦"."• •••¦••-•*»>¦¦¦¦•-*-й Первый, физический уровень передает поток данных между машинами. Как предполагает название, этот уровень содержит средства для соедине- соединения двух машин. Он связан с электрической, оптической, механической средой передачи, процедурами или интерфейсами, требуемыми для созда- создания соединения, будь то физический кабель, инфракрасное соединение, ла- лазер или другие методы. Физический уровень отвечает за перенос данных, которые создаются более высокими уровнями. Этот уровень определяет также, например, как кабель соединяется с картой сетевого адаптера, число используемых проводов и т.д. Он отвечает за перенос битов (единиц и нулей) из одного компьютера в другой. Биты не имеют никакого смысла на физическом уровне, они являются просто еди- единицами и нулями, электрическими импульсами или вспышками света. Фи- Физический уровень отвечает за обеспечение того, что когда передается единица, она будет получена как единица, а не как ноль. Этот уровень опре- определяет также, что такое единица, как долго длится импульс, какой длины он должен быть, какой силы и т.п., и таким образом уделяет внимание уров- уровню напряжения, частоте изменения напряжения, физическим скоростям данных и максимальным расстояниям, на которые они могут перемещаться. К этому уровню относятся такие устройства, как повторители (репитеры).
Базовые сетевые модели 13 Проект1ЕЕЕ802 - 7.1. В то время как ISO работал над моделью OSI, Институт инженеров по элек- электротехнике и электронике (IEEE) также разрабатывал стандарты LAN. Они получили известность как проект 802, названный по году и месяцу начала разработки (февраль 1980 г.). Поскольку эти модели возникли примерно в одно время, и две организации обменивались между собой информацией, два стандарта являются совместимыми. Проект 802 определяет стандарты для физических компонентов сети — кабеля интерфейса и прокладки кабе- кабеля — которые содержатся в двух первых уровнях модели OSI, физическом и уровне канала данных. Эти стандарты содержат спецификации для сетевых интерфейсных карт, компонентов глобальных сетей и компонентов, испо- используемых для создания коаксиальных сетей и сетей на витой паре. В проек- проекте 802 существуют двенадцать категорий, перечисленных в таблице 1.1. Таблица 1.1. Проект 802 Подраздел 802 Название 802.1 Межсетевой обмен 802.2 Управление логическим каналом 802.3 Локальные сети типа CSMA/CD (Ethernet) 802.4 Локальные сети с топологией "шина" и передачей маркера 802.5 ¦ Локальные сети с топологией "кольцо" и передачей маркера 802.6 Городские сети (MAN — Metropolitan Area Network) 802.7 . Техническая консультативная группа по широкополосной сети 802.8 Техническая консультативная группа по волоконной оптике 802.9 Интегрированные сети для передачи голоса/данных 802.10 Обеспечение сетевой безопасности '"¦ 802.11 Беспроводные сети ¦ 802.12 LAN с доступом по приоритету запроса, 100BaseVg-AnyLan Усовершенствования, сделанные в модели OSI Проект 802 делит канальный уровень на две части: подуровень управления логическим каналом (LLC) и подуровень управления доступом к среде (MAC). На рис. 1.4 показано, что проект 802 обеспечивает более детальный подход к стандартам, реализуя подразделы уровня канала данных. Подуровень управления логическим каналом (LLC) Подуровень LLC канального уровня управляет коммуникацией между устройствами, подключенными к одному каналу сети. LLC определяет испо- использование логических интерфейсных точек, называющихся служебными точками доступа (Service Access Point, SAP), которые позволяют протоколам
н Глава 1 7. Уровень приложений 6. Уровень представлений 5. Сеансовый уровень V •¦ ' 4. Транспортный уровень 3. Сетевой уровень 2. Канальный уровень 1. Физический уровень Управление логическим каналом (LLC) Управление доступом к среде передачи (MAC) Рис. 1.4. Проект 802 IEEE делит канальный уровень на два подуровня, чтобы предоставить более детальное определение методов доступа к среде передачи более высокого уровня использовать канал данных. Другие компьютеры так- также могут обращаться к SAP и использовать их для переноса информации из подуровня LLC на верхние уровни модели OSI. Поскольку JJLC находится выше других протоколов 802, он придает всему стеку большую гибкость, так как протоколы более высокого уровня могут те- теперь действовать независимо от типа среды передачи, которая расположена ниже. Однако подуровень управления доступом к среде передачи зависит от последней и связан со специальными типами протоколов 802.
Базовые сетевые модели 15 В стандарте 802.2 определены две служебные точки доступа (SAP): точка доступа к службе места назначения (DSAP) и точка доступа к службе источ- источника (SSAP). LLC обеспечивает поддержку между приложениями для управ- управления потоком с помощью использования битов готовности/неготовности и битов управления последовательностью. На рис. 1.5 показано, как эти две служебные точки доступа выглядят в приложении трассировки Network Monitor. ¦IXC: UI DSAP-OxEO SSAP=0xE0 С ¦IPX- SAP Packet - 3 0003C7B91A29.4058 -> 3.FFFFFFFFFFFF.452 - 0 Hops SAP: General Svc Resn fJVH1364 - RPC Serverl Рис. 1.5. Две служебные точки доступа, определенные в 802.2, отчетливо видны в сетевом мониторе Подуровень управления доступом к среде передачи (MAC) Нижним из двух подуровней канального уровня является уровень MAC, кото- который предоставляет для платы сетевого адаптера компьютера доступ к физи- физическому уровню. Подуровень управления доступом к среде общается непосредственно с картой сетевого адаптера и отвечает за доставку данных без ошибок между компьютерами в сети. В этой книге мы сосредоточимся на методе доступа, описанном в стандарте 802.3 — CSMA/CD (множественный доступ с контролем несущей и обнаружением конфликтов), на котором основана работа Ethernet. Чтобы несколько машин могли эффективно организовать совместный доступ к физическому уровню, они должны быть способны идентифициро- идентифицировать друг друга с помощью уникальных адресов. Наиболее важной функцио- функциональностью, предоставляемой уровнем MAC, является уникальный аппаратный адрес, называемый адресом MAC. Каждый интерфейс LAN должен иметь адрес MAC. Адрес MAC является 48-разрядным адресом, со- состоящим из 12 шестнадцатеричных цифр. Первые шесть шестнадцатерич- ных цифр представляют собой код поставщика (называемый также уникальным идентификатором организации (OUI)). Эти номера распреде- распределяются IEEE и могут быть очень полезны для сетевых администраторов, пытающихся найти драйверы для сетевой карты Etnernet, или при анализе сети. Последние шесть шестнадцатеричных цифр обычно присваиваются производителем и часто жестко кодируются в ROM устройства. Как данные перемещаются по проводам Чтобы надежно передавать по сетям большие файлы, последние должны быть разбиты на куски, называемые пакетами. Пакеты являются базовой единицей сетевой коммуникации. Так как данные делятся на пакеты, то перегрузка трафика сокращается, а скорость коммуникации возрастает, поскольку больше компьютеров имеет возможность для доступа к кабе- кабелю. В каждый пакет вносится специальная информация, которая позво- позволяет компьютеру разделить данные на фрагменты, собрать их снова
16 Глава 1 вместе и после сборки проверить на наличие ошибок. Фактически пакеты могут содержать множество различных типов данных, таких как сообщения, файлы, управляющие данные, команды или запросы служб, управляющие коды сеансов или сообщения об ошибках. Все пакеты, независимо от протокола, однотипны и содержат следую- следующую информацию: адрес источника (машины, отправляющей данные), адрес назначения (адрес выделенного получателя или получателей), сами данные, инструкции для различных сетевых компонентов, которые могут встретиться в пути, служебная информация для контроля ошибок и упорядочивания. Поскольку все перечисленные виды информации обязательно должны присутствовать во всех пакетах, последние состоят по крайней мере из трех основных разделов. Это заголовок, данные и концевик. В заголовке можно найти такую информацию, как адрес источника, адрес места назна- назначения, тип кадра и количество содержащихся в нем данных. Следующий раздел содержит сами передаваемые данные, количество которых зависит от типа сети и используемых коммуникационных протоколов. Например, кадр Ethernet может содержать полезную нагрузку (т.е. собственно данные) не менее 46 байтов и не более 1500 байтов, но сюда же входит заголовок TCP и заголовок IP. После удаления накладных расходов максимальный размер данных оказывается равным 1460 байтам. Содержимое концевика также зависит от используемого протокола и метода доступа; однако обыч- обычно там располагается некоторая информация для контроля ошибок (напри- (например, код CRC). CRC является одним из магических чисел, вычисляемых при обработке размера пакета с помощью некоторого алгоритма. Эти вы- вычисления можно воспроизвести, поэтому когда пакет прибывает в место назначения, получающий компьютер считывает из него значение CRC, по- повторно выполняет необходимые вычисления и сравнивает полученное зна- значение CRC с числом, содержащимся в концевике пакета. Если они совпадают, то пакет считается переданным безошибочно и передается на следующий уровень модели OSI. Если вычисленное получающим компьюте- компьютером число CRC не совпадает с числом, содержащимся в пакете, тогда про- протокол сочтет пакет плохим и отправит запрос на повторную передачу пакета. Процесс создания пакета Как рассматриваемые сетевые модели укладываются в этот процесс и ка- какую роль они играют? Каждый уровень модели OSI вносит свой вклад в формат пакета. Процесс создания пакета начинается на уровне приложе- приложений. Когда созданные там данные необходимо передать на другую машину в сети, уровень приложений добавляет небольшой объем заголовочной ин- информации. Оттуда данные переходят на уровень представлений, который добавит свою заголовочную информацию и затем перешлет пакет на сеан- сеансовый уровень, также добавляющий свою заголовочную информацию. За- Затем они переходят на транспортный уровень, где исходные данные разбиваются на пакеты, которые и будут передаваться по сети. Поэтому ре- реальный формат пакета зависит от типа используемого транспортного
Базовые сетевые модели 17 протокола. Например, транспортный протокол в составе стека протоколов TCP/IP — это протокол TCP. В стеке протоколов IPX/SPX протокол транс- транспортного уровня — это SPX. Каждый из этих транспортных протоколов управляет пакетами по-своему (более подробно поговорим об этом в следу- следующих главах). Однако после того как транспортный протокол разбивает данные на пакеты, он должен снабдить пакеты последовательной нумера- нумерацией, чтобы принимающий компьютер мог узнать, как собрать их снова, чтобы восстановить данные. Это произойдет на транспортном уровне при- принимающего компьютера. После того как транспортный протокол разобьет данные на пакеты, они передаются вниз на третий, сетевой уровень модели OSI. Здесь дейст- действия снова зависят от используемого стека протоколов. В стеке TCP/IP се- сетевым протоколом является протокол IP, а в IPX/SPX — протокол IPX. В целом, однако, сетевой уровень добавляет информацию маршрутизации, информацию об источнике и месте назначения в формате соответствующе- соответствующего протокола, контрольную сумму, а также информацию о синхронизации. Канальный уровень также будет добавлять свой заголовок и концевик CRC. Наконец, пакет попадает на физический уровень, готовый выпол- выполнить путешествие к месту назначения и содержащий не только полезную нагрузку данными, но также заголовочную и концевую информацию, добав- добавленную шестью верхними уровнями, чтобы гарантировать своевременную и точную доставку данных. На принимающей стороне пакет передается от физического уровня вверх вплоть до седьмого уровня приложений, и при этом каждый уровень удаляет информацию, добавленную соответствующим уровнем передающего компьютера. Пакеты адресуются специфическому месту назначения. В большинстве случаев место назначения является определенным компьютером, серве- сервером или клиентской машиной. Хотя весь трафик в кабеле виден каждой карте сетевого адаптера, компьютер не извлекает данные из кабеля, если они адресованы не ему. Иногда это не так. Например, существуют специа- специальные виды кадров — широковещательные кадры, которые рассылаются всем узлам в сети. В этом случае каждый сетевой адаптер будет извлекать широковещательные сообщения из кабеля и просматривать пакеты. Это одна из причин изучения способов контроля широковещательного трафика в главах 5 и 6. Бывают другие случаи, когда сетевой адаптер может извлекать из кабеля не предназначенный для него трафик — например, так работают маршрути- маршрутизаторы. В нашем исследовании сетевого трафика некоторые из файлов примеров связаны с маршрутизаторами. В этих пакетах необходимо внима- внимательно отслеживать, что в действительности является истинным источни- источником и местом назначения. Конечно, все эти вопросы приобретают особую важность в сети Ethernet, и это ведет нас к следующему разделу.
18 Глава 1 Особенности коммуникации в сетях Ethernet :: Уровень MAC (нижний подуровень уровня 2 OSI) определяет, как компью- компьютер будет получать доступ к кабелю и как он будет передавать и принимать данные. Для этого он общается с физическим уровнем (уровень 1 OSI) че- через общий интерфейс. Этот интерфейс состоит из базовых служб или фун- функций, которые управляют обменом данными между подуровнями MAC на двух различных машинах. При работе через эти интерфейсы подуровень MAC независим от нижележащей физической среды. Это может быть мед- медный или оптоволоконный кабель, радиопередача, лазерный или инфрак- инфракрасный луч. Первым из этих вспомогательных интерфейсов является сигнализация физической линии. Это подуровень уровня MAC, его основ- основная функция состоит в управлении доступом к кабелю. Так как мы рассматриваем Ethernet, используемым методом является контроль несущей — т.е. компьютер будет следить, когда линия освободит- освободится. Перед каждой передачей делается проверка, чтобы увидеть, не исполь- используется ли в данный момент линия. Однако в сети Ethernet отсутствует сигнал несущей. Как же проконтролировать деятельность? Выяснение того, что линия не занята, делается с помощью механизма синхронизации между кадрами данных. Вводится понятие межкадрового промежутка, кото- который имеет длину 96 бит-периодов (9,6 микросекунды). Межкадровый про- промежуток является поэтому наименьшим допустимым пробелом между кадрами данных в сети Ethernet. Сигнализация физической линии будет также обнаруживать, занята ли линия и имел ли место конфликт. Эти функ- функции реализованы в части платы Ethernet, называемой трансивером. Рань- Раньше трансивер был отдельным устройством, но он давно уже реализован как микросхема на карте Ethernet. Иногда это устройство называют модулем доступа к среде передачи (MAU — media access unit). Трансивер отвечает за четыре основные функции. Это передача электрических сигналов по кабе- кабелю, получение сигналов из кабеля, определение, свободен или занят кабель и наблюдение за данными с целью обнаружения конфликтов. Данные передаются в кабель с помощью так называемого манчестер- манчестерского кодирования (Manchester code). В этом коде первая половина значе- значения бита содержит дополнительное значение, в то время как вторая половина содержит реальное значение. Таким образом, каждый посылае- посылаемый в кабель сигнал является уникальным. Это работает, даже когда пере- передаются несколько пакетов с идентичной информацией. На рис. 6.1 показан период времени, использованный для передачи информации в кабель. Время, которое требуется для изменения в кабеле сигнала 1 в О, называется бит-периодом. 1 бит-период = 100 наносекундам 0 0 0 0 t 0 0 0 Рис. 1.6. Бит-период для Ethernet равен 100 наносекундам
Базовые сетевые модели 19 Так как в сети Ethernet не существует внешнего тактового генератора, манчестерское кодировние позволяет передатчикам и приемникам син- синхронизироваться друг с другом. Напряжение в кабеле Ethernet изменяется от -2.2 до О В, а сила тока — от -90 до 0 мА. Соединение с физической средой выполняет несколько важных задач, на- например передачу и получение данных, обнаружение конфликтов и контроль за длительностью передачи данных. Мы кратко рассмотрим некоторые из них. Карта Ethernet должна быть способна принять параллельный поток данных и передать его в кабель как последовательный поток данных. Это похоже на ситуацию, когда многополосная скоростная магистраль перехо- переходит в однополосный мост. Функция передачи не может потерять более 7. Уровень приложений Взаимодействие сетевых процессов и приложений 6. Уровень представлений Представление данных 5. Сеансовый уровень Коммуникация между хостами 4. Транспортный уровень Двухточечное соединение 3. Сетевой уровень Адресация и оптимальный маршрут 2. Канальный уровень Доступ к среде передачи 1.Физический уровень Передача двоичной информации Рис. 1.7. Уровень MAC добавляет заголовочную информацию к пакету данных
20 " '"'*ч Глава 1 двух полных ячеек битов. Задержка между ячейками битов должна быть менее 50 наносекунд. Когда соединение с физической средой получает по- поток битов, оно не может потерять более пяти ячеек битов. Как же уровень MAC передает данные? Рассмотрим это немного подробней. Уровень MAC получает пакет от LLC. Затем он добавляет в пакет следу- следующую информацию: преамбулу, начальный ограничитель кадра, адрес мес- места назначения, адрес источника, поле типа (для Ethernet), поле длины и поле данных с информацией протоколов более высоких уровней. Это пока- показано на рис. 1.7. Если данные занимают меньше 48 байтов, то поле данных дополняется нулями до минимальной длины. После создания пакета данных модуль передачи вычисляет CRC и поме- помещает ее в поле CRC. Весь пакет передается в модуль передачи MAC. В этом месте проверяется активность кабеля. Если кабель свободен, то модуль MAC выжидает межкадровый промежуток (9,6 микросекунд) и передает па- пакет. Во время передачи модуль MAC проверяет наличие конфликта. Если конфликтов нет, то передача завершается и можно посылать следующий кадр. Если возник конфликт, то вызывается функция обработки конфликтов. Функция обработки конфликтов используется для обнаружения конф- конфликтов в кабеле. Когда два компьютера передают свои данные одновремен- одновременно, общее напряжение возникающего конфликта превышает обычное значение в кабеле, и обнаружившая это машина будет генерировать сигнал конфликта. Это будет продолжаться в течение девяти бит-периодов, или 900 наносекунд. В течение этого времени машины, пытающиеся исполь- использовать кабель, будут повторно посылать свои пакеты со случайным интер- интервалом времени, чтобы избежать нового конфликта. Если отказ происходит 16 раз подряд, то протоколам верхних уровней возвращается ошибка. Функция контроля длительности передачи данных была введена в стан- стандарт 802.3, чтобы не давать одной машине возможность монополизировать кабель. Каждая машина может использовать кабель не более 30 миллисекунд за один раз и должна предоставить после этого другой машине возможность использовать кабель. Если машина не прервет передачу в течение этого вре- времени, то карта предполагает, что это слишком длинная передача, и должна ее прекратить. Уровень MAC отвечает также за получение данных из кабеля. Весь тра- трафик виден в кабеле, но только пакеты, адресованные локальной машине, обрабатываются уровнем MAC. Если пакет не адресован локальной маши- машине, то она просто отбрасывает пакет данных. Однако когда пакет получен из кабеля, то прежде всего необходимо проверить его на наличие ошибок. Это делается модулем MAC, проверяющим значение CRC. Если пакет не выдерживает этой начальной проверки, он отбрасывается как мусор. Когда пакет прошел проверку CRC, уровень MAC начинает процесс удаления пре- преамбулы, начального ограничителя пакета, адреса места назначения, адреса источника, поля типа и заполнения, которое могло быть добавлено в поле данных, чтобы он удовлетворял требованиям минимального размера. По- После того, как это сделано, выполняются две дополнительные проверки па- пакета. Уровень MAC будет проверять, имеет ли поле данных правильную длину и является ли кратным восьми битам. Если обе эти дополнительные
Базовые сетевые модели 21 проверки проходят успешно, данные объявляются неповрежденными и пе- передаются вверх по уровням протокола. Если пакет не выдерживает любую из этих проверок, он объявляется мусором и отбрасывается, а процесс дол- должен начинаться заново. . ,. j . ... .. ¦ . Какова во всем этом роль протоколов? : . Можно представлять себе протоколы как языки. Например, во Франции луч- лучше говорить по-французски. Если вы, скажем, попытаетесь найти общий язык с французом при помощи греческого языка, то у вас мало что получит- получится. Разумеется, всегда есть небольшая вероятность, что ваш собеседник тоже владеет греческим, но рассчитывать на это нельзя. Подобным же образом, протоколы у двух компьютеров, которые собираются общаться, должны сов- совпадать. Так же, как существуют правила функционирования языков — напри- например, согласование подлежащего и сказуемого, существуют правила для работы протоколов. У каждого протокола свой набор поддерживаемых команд, каждая из которых имеет определенное назначение. Подобно тому как в любом язы- языке существует различие между устной и письменной речью, есть различия в том, как функционируют протоколы. Так же, как существует много язы- языков, есть много протоколов. На всех уровнях модели OSI работают раз- различные протоколы, используемые для разных целей. Когда несколько протоколов работают вместе на различных уровнях модели OSI, они на- называются стеком протоколов. Сеть охватывает все уровни модели OSI. Та- Таким же образом стек протоколов включает в себя протоколы, которые работают на различных уровнях модели OSI. Стек протоколов " .<•.¦¦ > ¦ < и ,г Протоколы управляют коммуникацией между двумя или несколькими маши- машинами в сети. Существует множество различных протоколов, которые могут использоваться для управления обменом информацией между машинами в сети. Протоколы определяют, как они собираются взаимодействовать, как и когда пользователю разрешается передавать данные, как сообщается об ошибках, сколько данных можно послать за один раз. Без этих правил комму- коммуникация в сети была бы невозможна. В зависимости от того, на каком уровне протокола OSI должен действовать протокол, он может быть связан с разби- разбиением данных на достаточно маленькие фрагменты для передачи через ка- кабель на другой компьютер. При этом он должен знать, на сколько частей разбить данные, в каком порядке их передавать, как снова собрать их вместе и убедиться, что они прибыли в правильном порядке и в том же виде, в ка- каком передавались. Ему необходимо также знать расположение машины, куда предположительно направляются данные, и путь к ней. Кроме того, он дол- должен знать, как общаться с картой Ethernet, чтобы действительно передать данные в кабель. На принимающем компьютере протокол осуществляет некоторые из тех же действий, что и передающий компьютер, только в обратном поряд- порядке. Прежде всего, он должен распознать адресованный компьютеру пакет. Затем он должен извлечь данные из кабеля и поместить их в компьютер
22 Глава 1 с помощью карты Ethernet. Протоколы должны восстановить данные в пер- первоначальном порядке и, наконец, представить информацию приложению, чтобы оно могло работать с содержимым пакта. Как можно видеть из приведенного выше примера, в эту простую тран- транзакцию вовлечено много уровней модели OSI. Протокол уровня приложе- приложений общается с протоколом уровня приложений на другой машине, уровень представлений общается с уровнем представлений на другой машине, сеан- сеансовый уровень отвечает за установление соединения, транспортный уровень отвечает за доставку на другую машину данных, а сетевой уровень находит маршрут к месту назначения, уровню LLC и физическим уровням. Таким образом, чтобы выполнить свои задачи, каждый уровень добавля- добавляет информацию к основному пакету информации для целей отслеживания. Посылающая машина добавляет служебную информацию, по мере того как информация перемещается с уровня приложений на физический уровень. Когда машина получает данные из кабеля на первом уровне, она удаляет до- добавленную информацию на каждом уровне по мере ее перемещения на уро- уровень приложений. Уровень представлений затем представляет собранные данные уровню приложений в используемом формате. Необходимо помнить, что протоколы должны поддерживать маршрути- маршрутизацию. Хотя сегодня ситуация изменилась, в прошлом это было проблемой. Например, NETBEUI является быстрым протоколом, подходящим для небо- небольших рабочих групп, но он не маршрутизируется и поэтому не очень хоро- хорошо подходит для решений уровня предприятия. Конечно, существуют и другие причины, по которым можно отказаться от использования NETBEUI в WAN, но они будут рассмотрены позже. Есть несколько способов перемес- переместить данные из одной LAN в другую LAN через соединяющий их маршрути- маршрутизатор. Определять, как это сделать — функция протоколов третьего уровня. Иерархический подход ' "'' ; ^ 'ЧК! ; ^ ; s Чтобы в сети была коммуникация необходимо решить много задач. Но важно понимать, что происходит в сети, чтобы вести поиск неисправно- неисправностей. Стек протоколов использует подход на основе иерархии уровней. Есть по крайней мере четыре причины для использования такого подхода. Это уменьшает сложность, стандартизует интерфейсы, облегчает модуль- модульное проектирование и гарантирует взаимодействующую технологию. Информация должна быть подготовлена, переслана, получена и обрабо- обработана. Различные протоколы, выполняющие эту рутинную работу, являются темой обсуждения оставшейся части главы. Способ, который они совместно используют при обработке задачи пересылки данных из одной машины в другую, называется иерархическим представлением сети. Стек протоколов является комбинацией протоколов, и каждый уровень стека имеет свою фун- функцию, которая реализуется отдельным протоколом и правилами, управляю- управляющими тем, как он ведет себя в различных ситуациях. Каждый уровень имеет свои собственные обязанности. Как мы видим на рис. 1.8, каждый уровень выполняет определенные обязанности, задачи и обязательства. Каждый уровень общается с протоколом на уровне выше и ниже его в стеке, но не знает о других протоколах. Таким образом, протоколы способны
Базовые сетевые модели 23 7. Уровень приложений 6. Уровень представлений Взаимодействие сетевых О. процессов и приложений :¦!¦• :¦''' .'(' ¦;'.". {,¦. ' ¦,..•'' Представление данных :" 5. Сеансовый уровень Коммуникация между хостами 4. Транспортный уровень Двухточечное соединение 3. Сетевой уровень Адресация и оптимальный маршрут 2. Канальный уровень Доступ к среде передачи 1. Физический уровень Передача двоичной информации Рис. 1.8. Каждый уровень выполняет свою работу, будто бы игнорируя существование других протоколов получить виртуальную коммуникацию между уровнями на различных машинах. Например, приложение считает, что оно общается с уровнем приложений на другой машине. Нижние уровни модели определяют, как производители оборудования де- делают возможным для своих продуктов соединяться с сетью и с компьютерами, с которыми они связаны. Верхние уровни определяют, как приложения будут общаться друг с другом, правила их коммуникации и исправление ошибок. Чем больше уровней в стеке протоколов, тем более сложными становятся задачи и протоколы.
Глава 1 Как все это объединяется? ^ s ^ , -: ] Все эти вещи объединяются с помощью процесса, называемого связыванием. Он предоставляет нам большую гибкость, так как теперь протокол и плата сетевого адаптера являются независимыми, поэтому можно менять стек протоколов без изменения драйвера сетевого адаптера. Можно также изме- изменять методы доступа к среде, не изменяя при этом протокол. Поэтому мож- можно использовать TCP/IP через Ethernet, token-ring или любой другой метод, выбранный для реализации. Кроме того, если имеется несколько сетевых адаптеров, то можно связать протокол с одним из них или со все- всеми, как будет необходимо. Не имеет значения, как их связывать, по край- крайней мере, на работу протокола это не влияет. Однако может понадобиться уделить внимание порядку связывания протоколов (см. ниже). Netwoik Identification I Services 1 Protocols I Adapters Bindings Network bindings are connections between network cards, protocols, and services installed on this computer. You cart use this page to disable netwoik bindings or arrange the order in which this computer finds information on the network. Show Bindings for: I all services E S Microsoft DHCP Server В S NetBIOS Interface 1 WINS Client(TCP/IP) Ё S Network Monitor Agent Щ} Я Remote Access Server Service 13 S Server 'гч-)>:,- Й Я Workstation Enable Disable Move Up Move Down OK Рис. 1.9. В операционной системе Windows NT для оптимальной производительности порядок связывания можно сконфигурировать вручную
Базовые сетевые модели Порядок связывания — это порядок, в котором компьютер будет исполь- использовать протоколы при попытке коммуникации с другими машинами в сети или в мире. Поэтому порядок, в котором протоколы связаны с платой сете- сетевого адаптера, определяет порядок, в котором они будут пытаться общать- общаться друг с другом. Этот порядок в Windows NT можно определить вручную, как показано на рис. 1.9. Процесс связывания применяется не только к стеку протоколов и сетево- сетевому адаптеру; например, драйвер платы Ethernet должен быть связан с платой Ethernet, а транспортный протокол также должен быть связан с уровнем сеанса NetBIOS, расположенным выше него в стеке. Существует несколько стеков протоколов, разработанных в течение ряда лет. Некоторые из них перечислены ниже: 1. Стек протоколов ISO/OSI 2. IBM System Network Architecture (SNA) * 3. Digital DECnet : . . 4. Novel Netware 5. Apple AppleTalk 6. Стек протоколов Интернета, или TCP/IP В каждом из этих стеков существуют собственные протоколы для раз- различных уровней модели OSI. Отдельный протокол в составе стека может охватывать один или несколько уровней, но полный набор протоколов вы- выполняет все необходимые функции всех семи уровней. В данный момент полезно сгруппировать некоторые из этих уровней функциональности по областям обслуживания, как показано в таблице 1.2. Можно выделить три области функций: приложения, транспорт и сеть. Таблица 1.2. Модель 0SI предоставляет три важные службы Уровень Уровень OSI Предоставляемая функциональность Семь Шесть Пять Четыре Три Два Один Приложения Уровень представлений Сеансовый уровень Транспортный уровень Сетевой уровень Канальный уровень Физический уровень Прикладные службы, сетевые службы Прикладные службы, сетевые службы Прикладные службы, сетевые службы Транспортные службы Сетевые службы Сетевые службы Сетевые службы
26 Глава 1 Прикладные протоколы * Теперь можно поговорить о прикладных, транспортных и сетевых прото- протоколах. Прикладные протоколы охватывают верхние три уровня модели OSI, т.е. уровни приложений, представлений и сеансовый. Они обеспечи- обеспечивают взаимодействие и обмен данными между приложениями. Некоторые из распространенных прикладных протоколов перечислены ниже: 1. АРРС (Advanced Program-to-Program Communication), одноранговый протокол из стека IBM SNA, используемый в основном для систем AS/400. 2. FTAM (File Transfer Access and Management), протокол доступа к файлам из стека OSI. 3. Х.400, протокол CCITT для международной передачи электронной почты. ..-.-.*¦. ,.,.»¦>.,¦ -.; .. Л 4. Х.500, протокол ССПТ для служб файлов и каталогов на нескольких системах. 5. SMTP (Simple Mail Transport Protocol), протокол пересылки электронной почты из стека TCP/IP. ''v ¦ 6. FTP (File Transfer Protocol), протокол пересылки файлов из стека TCP/IP. 7. SNMP (Simple Network Management Protocol), протокол мониторинга сетей и сетевых компонентов из стека TCP/IP. 8. Telnet, протокол Интернета для дистанционного подключения к удаленным хостам и локальной обработки удаленных данных. . > ~ 9. Microsoft SMB (Server Message Blocks) и клиентские оболочки или редиректоры Microsoft. 10. NCP (Novell Netware Core Protocol) и клиентские оболочки или редиректоры Novell. 11. AppleTalk и Appleshare компании Apple. 12. AFP, протокол AppleTalk удаленного доступа к файлам. 13. DAP (Data Access Protocol), протокол доступа к файлам DECnet. Транспортные протоколы Транспортные протоколы располагаются на четвертом, среднем уровне модели OSI. Они предоставляют коммуникационные сеансы для обеспече- обеспечения надежного перемещения данных между компьютерами. Популярные транспортные протоколы перечислены ниже: . .. ....... 1. TCP (Transmission Control Protocol), протокол TCP/IP для гарантированной доставки последовательных данных.
Базовые сетевые модели 27 2. SPX (Sequential Packet Exchange), транспортная часть стека протоко- протоколов IPX/SPX для передачи последовательных данных. 3. NWLink, реализация IPX/SPX от Microsoft. 4. NetBEUI (расширенный интерфейс пользователя NetBIOS) создает коммуникационные сеансы между компьютерами и предоставляет нижележащие службы транспорта данных. ., . ....... 5. Протокол ATP (AppleTalk Transaction Protocol) из стека AppleTalk, протокол связывания имен NBP и протоколы транспорта данных. Сетевые протоколы Сетевые протоколы предоставляют так называемые службы канала данных и составляют нижние три уровня модели OSI. Эти протоколы обрабатыва- обрабатывают информацию адресации и маршрутизации, контроль ошибок и запросы повторной пересылки. Сетевые протоколы определяют также правила для коммуникации в сетевом окружении, таком как Ethernet или Token Ring. Наиболее популярные сетевые протоколы перечислены ниже: 1. IP (Internet Protocol), протокол TCP/IP для маршрутизации "¦ и пересылки пакетов. . . 2. IPX (Internetwork Packet Exchange), протокол NetWare для пересылки пакетов и маршрутизации. 3. NWLink, реализация Microsoft протокола IPX/SPX. 4. NetBEUI, транспортный протокол, который предоставляет службы транспорта данных для сеансов NetBIOS и приложений. 5. DDP (Datagram Delivery Protocol), протокол транспорта данных AppleTalk. , . , . Мы увидели, как эти протоколы укладываются в модель OSI, и получили представление о функциях каждого из них. Теперь следует рассмотреть, как все это отображается в совокупности, после чего можно исследовать различия в поведении этих протоколов, как используется каждый из них, а также различные уровни функциональности. Сетевая служба с поддержкой соединения ',''""."' Сетевая служба с поддержкой соединения включает три фазы: • Создание соединения - во время фазы создания соединения опреде- определяется единственный маршрут между исходной и целевой системами. Сетевые ресурсы в это время обычно резервируются, чтобы гаранти- гарантировать согласованный уровень службы (например, гарантированную пропускную способность).
28 Глава 1 • Пересылка данных — во время фазы пересылки данные последовате- последовательно передаются по определенному на предыдущем этапе маршруту. Данные всегда приходят в целевую систему в том порядке, в котором были посланы. • Прекращение соединения — во время фазы прекращения соединения созданное соединение, которое больше не требуется, прерывается. Дальнейшая коммуникация между исходной и целевой системами тре- требует создания нового соединения. Служба с поддержкой соединения имеет два существенных недостатка по сравнению с сетевыми службами без поддержки соединения: • Статический выбор маршрута — так как весь трафик должен переме- перемещаться по одному и тому же статическому маршруту, отказ в какой-либо точке этого маршрута вызывает отказ соединения. • Статическое резервирование сетевых ресурсов — гарантированный уровень пропускной способности требует привлечения ресурсов, не предназначенных для других пользователей сети. Если для коммуни- коммуникации требуется полная непрерываемая пропускная способность, то полоса пропускания используется неэффективно. Службы с поддержкой соединения используются для передачи данных при- приложений, которые нетерпимы к задержкам и переупорядочиванию пакетов. Приложения для голоса и видео обычно используют службы с поддержкой соединения. ч Сетевая служба без поддержки соединения Сетевая служба без поддержки соединения не определяет заранее маршрут от источника к системе назначения, упорядочивание пакетов, пропускную способность канала данных и другие гарантированные сетевые ресурсы. Каждый пакет должен быть снабжен полным адресом, так как для различ- различных пакетов на основе множества факторов могут выбираться различные пути доступа через сеть. Каждый пакет передается исходной системой неза- независимо и независимо обрабатывается промежуточными сетевыми устрой- устройствами. Служба без поддержки соединения предлагает два важных преимущества относительно службы с поддержкой соединения: • Динамический выбор маршрута — так как маршруты выбираются для каждого пакета отдельно, трафик можно направить в обход сбойного участка сети. • Динамическое выделение полосы пропускания — полоса пропускания используется более эффективно, поскольку сетевым ресурсам не выде- выделяют полосу пропускания, которую они не собираются использовать. Службы без поддержки соединения используются для передачи данных приложений, которые могут выдержать некоторую задержку и переупоря- переупорядочивание. Приложения, передающие данные, обычно используют службу без поддержки соединения.
Базовые сетевые модели 29 Адресация на канальном уровне и? is? н г ./ Адрес канального уровня уникальным образом идентифицирует каждое фи- физическое соединение сетевого устройства с сетью. Адреса канального уровня иногда называются физическими или аппаратными адресами. Обычно они образуют неиерархическое адресное пространство, задаются для каждого устройства заранее и, как правило, жестко. Оконечные системы имеют обычно только одно физическое сетевое соединение и, стало быть, только один адрес канального уровня. Маршрутизаторы и другие устройства, под- поддерживающие межсетевой обмен, обычно имеют несколько физических сетевых соединений и несколько адресов канального уровня. Адреса подуровня управления доступом к среде передачи (MAC) являют- являются подмножеством адресов канального уровня. Адреса MAC идентифициру- идентифицируют сетевые устройства в LAN, реализующие подуровень IEEE MAC канального уровня. Как большинство адресов канального уровня, адреса MAC являются уникальными для каждого интерфейса LAN. Адреса MAC имеют 48 битов в длину и выражаются с помощью 12 шестнадцатеричных цифр: первые шесть шестнадцатеричных цифр являются идентификацией производителя (или кодом поставщика), называемым уникальным иденти- идентификатором организации (ОШ). Эти шесть цифр устанавливаются IEEE. Последние шесть шестнадцатеричных цифр являются серийным номером интерфейса или другим значением, администрируемым определенным по- поставщиком. Адреса MAC иногда называются аппаратными или "зашитыми" адресами (Burned-in Address, BIA), так как они выжжены в постоянной па- памяти (ROM) и копируются в оперативную память (RAM), когда инициали- инициализируется плата интерфейса. Адресация на сетевом уровне Адрес сетевого уровня идентифицирует устройство сетевого уровня эталон- эталонной модели OSI. Сетевые адреса существуют обычно в иерархическом адрес- адресном пространстве. Иногда их называют виртуальными или логическими адресами. Отношение сетевого адреса с устройством является логическим и нефиксированным. Обычно адрес основывается либо на характеристиках физической сети (устройство находится в определенном сетевом сегменте), или на логическом объединении, которое не имеет физической основы (устройство является частью зоны AppleTalk). Оконечным системам требу- требуется один адрес сетевого уровня для каждого протокола сетевого уровня, ко- который они поддерживают. (Это предполагает, что устройство имеет только одно физическое сетевое соединение.) Маршрутизаторы и другие устройст- устройства, поддерживающие межсетевой обмен, требуют один адрес сетевого уров- уровня на каждое физическое соединение для каждого поддерживаемого протокола сетевого уровня. Например, маршрутизатор с тремя интерфейса- интерфейсами, каждый из которых поддерживает одновременно AppleTalk, TCP/IP и OSI, должен иметь три адреса сетевого уровня для каждого интерфейса. Поэтому маршрутизатор имеет девять адресов сетевого уровня.
30 Глава 1 Инкапсуляция данных ?н оцу &'"¦ hsn-> &* *n> Каждый уровень модели OSI общается с нижележащим уровнем и зависит от него в обеспечении специальных служб и функциональности. Так как каждый уровень предоставляет службу, он добавляет информацию к дан- данным приложения, чтобы можно было транспортировать информацию к машине места назначения. Конечно, добавленная специальная информация зависит от используемого стека протоколов, но, следуя общей модели, мы видим, что каждый уровень добавляет к данным заголовочную информацию, а в отдельных случаях также и концевик после данных, пока не будет полу- получен аккуратно сформированный пакет, который отправляется в кабель. 7. Уровень приложений 6. Уровень представлений 5. Сеансовый уровень 4. Транспортный уровень 3. Сетевой уровень 2. Канальный уровень 1. Физический уровень Заголовок уровня приложений - данные '¦I.K.- . •¦,!.!¦ ¦ I, ' ,-Us' I ';•¦.'( Г V Заголовок уровня представлений - данные ¦:¦¦ ;., ' . uiiil--! 1 ,;,.:,: ,. Заголовок сеансового уровня - данные Заголовок транспортного уровня -данные ;¦!.*,-¦ 1( I'.' ¦ ,¦ )¦ •!¦¦/¦"! ..-.¦¦¦ т.... ¦ Заголовок пакета - данные Заголовок кадра - данные 0101101010110001 ч 7. Уровень приложений •Л.. ¦-:.; ^ ^ 6. Уровень представлений 5. Сеансовый уровень 4. Транспортный уровень N. 3. Сетевой уровень \ \ 2. Канальный уровень 1. Физический уровень Ч N Рис. 1.10. Заголовочная информация, добавленная на передающем компьютере, удаляется на том же уровне на принимающем компьютере
Базовые сетевые модели 31 Как показано на рис. 1.10, каждый уровень добавляет заголовочную ин- информацию, чтобы выполнить службу, требуемую приложению. Когда дан- данные перемещаются вниз по модели OSI на посылающем компьютере, эта информация добавляется. На получающем компьютере заголовочная и концевая информация отбрасываются, когда данные перемещаются вверх по модели OSI. Можно насчитать пять шагов, связанных с процессом инкапсуляции данных, когда они готовятся транспортным уровнем для отправки в кабель. Они перечислены ниже: 1. С верхних уровней получена информация от пользователя, напри- например запрос регистрации на сервере, задание печати или поиск в Web. Информация преобразуется в данные, чтобы ее можно было транс- транспортировать к месту назначения. 2. Данные подготовлены для транспортировки на целевой компьютер. В случае TCP к данным добавляется заголовок TCP, содержащий ин- информацию об упорядочивании, помогающую сохранить все в порядке при преобразовании в сегменты. - ч • 3. На третьем уровне модели OSI находится протокол IP. Здесь будет добавлен заголовок IP, так как сегмент TCP преобразуется в пакет IP. Заголовок IP включает IP-адреса источника и места назначения, что поможет при маршрутизации (выполняемой на этом уровне модели OSI) пакета в соответствующее место назначения. 4. На уровне канала данных в нашем примере пакеты IP преобразуются в кадры Ethernet. Чтобы сетевое устройство могло общаться через локальный интерфейс с другим интерфейсом в сети, оно должно по- поместить пакет в кадр. Тип кадра должен совпадать, иначе устройства не смогут общаться. В примерах трассировок мы увидим, что кадры Ethernet создаются вокруг пакетов IP. 5. Теперь кадр Ethernet превращается в единицы и нули. Как говорилось ранее, эти биты перемещаются по сети особым образом, определен- определенным методами доступа, пока не достигнут своего места назначения. Реализация IP поверх различных стандартов LAN По мере совершенствования нашего мастерства в поиске неисправно- неисправностей нам понадобится понимание инкапсуляции LAN. Технологии LAN охватывают такие технологии настольных компьютеров, как Ethernet, Token Ring и Arcnet, и технологии MAN, например FDDI. В таких техно- технологиях, как Ethernet могут существовать несколько типов инкапсуляции, что вызывает некоторые проблемы взаимодействия. В каждой из этих технологий дейтаграммы IP необходимо разграничивать, адресовать и идентифицировать как дейтаграммы IP.
32 Глава 1 Ethernet II При пересылке через сеть Ethernet дейтаграммы IP испо- используют либо инкапсуляцию Ethernet II, либо IEEE 802.3 SNAP. Инкапсуля- Инкапсуляция Ethernet II использует двухбайтовое поле типа для обозначения протокола верхнего уровня. У этого поля два значения: 0x08-00 соответст- соответствует IP, a 0x08-06 соответствует ARP. Дейтаграммы IP, посылаемые в составе кадров Ethernet II, имеют макси- максимальный размер 1500 байтов и минимальный размер 46 байтов. Дейтаграм- Дейтаграммы IP размером меньше 46 байтов дополняются нулями до 46 байтов, чтобы сохранить минимальный размер кадра Ethernet, равный 64 байтам (не включая преамбулу). Как можно видеть на рис. 1.11, кадр Ethernet II состоит из преамбулы, за которой следует адрес места назначения, адрес источника, поле типа, полезная нагрузка и, наконец, контрольная последовательность кадра. Netwmt Menu» ¦ |G:\ch«t<foelwork cap IDetatfll Fra»e 1 0?S I 076 1 076 1 077 1 073 Src «AC Add Д1Н_В"ГИГ" 3COM CBDC4 JWH_B* EX 3COM CBDC4 JKH ЗА EX Dst MAC Add: ЗСбМ "CBOCV J«H_BA_EX 3COM CBDC4 JVH_BA_EX 3CCM CBDC4 Protect, ,^_- -„ ARP RAHAR? Reply. Taxget IP SKB С close file. FID SXB SHB SXB Я close file С tree disconnect disconn 11.0.0 49 Target Hdvr Addr 0xd802 loTcJ J -ETHERNET Destination address 00805FA63A32 ETHERNET 0 • Individual address ETHEHHET 0 ¦ universally ad»lnistered address -ETHERNET Source address 00608ССЮС4 3 \ ETHERNET 0 • No routing information present ETHERNET 0 ¦ Universally edmnistered address ETHERNET Fra»e length 60 (ОхООЗС) ETHERNET Ethernet Type 0x0800 (I? COD Internet Protocol) ETHERNET Ethernet Data Kuxber of data bytes returning • 46 @x002E) ¦ IP ID - 0xH9; Proto ¦ TCP. len 40 ¦TCP A . len 0. seq 16SS72S-USS72S. ack 3143336. vin 8613. src 1025 dst 13» 00000000 liliMiM*T.Wcbai|l»:tiM:b»:Bfr»MiT«Iil4 5 00 00009010 00 28 01 69 40 00 20 06 42 6? 0B 00 60 31 0B 00 00000020 00 C9 04 01 00 68 00 19 43 AD 00 2F F6 A8 SO 10 00000030 21 AS 38 ОС 00 00 00 00 00 00 00 00 f K8 Bn a |FB. 11/78 JOll 0(«0| Рис. 1.11. Кадр Ethernet II инкапсулирует дейтаграмму IP IEEE 802.3 SNAP Инкапсуляция IEEE 802.3 SNAP также начинается с преамбулы, адреса места назначения и адреса источника, однако дальше SNAP 802.3 расходится с инкапсуляцией Ethernet П. На рис. 1.12 показано, что для инкапсуляции дейтаграммы IP имеется поле длины и заголовок протокола доступа к подсети (SNAP), чтобы его можно было послать по сети, поддерживающей IEEE 802.3. Заголовок IEEE 802.3 использует опре- определенное значение ОхАА для полей точки доступа службы места назначения
Базовые сетевые модели 33 Nelmxk Monilot - |6:\clu№metMMk.cap (Sunaajfll ?? Ffe ?d< С:'=Р'ЗД loci; рКют Wind»» 10 072 13COM CC0B5l«BRQADCAST IARP. RAfiUR? Request Targe IP 11 0 0 205 0 932 JVH1364 «BROADCAST 0 970 1 001 1 075 1 0?S 00609777CB6 JVH BA_EX 3COX CBDC4 JUH BA EX BROADCAST •BROADCAST •BROADCAST 3COM C8DC4 ГОР ARP RAFJAEP ARP~RAS ARP ARP RAH ARP FJWH1364 - RPC Serverl 3 4 5 6 ,| ^ ,,,„,., ,.-,,.„4, .„¦,...,'.. ..HTf*. у, ¦FRAHE Base Sra«e properties -ETHERKET 802.3 length • 114 "•ETHERNET Destination address FFFFFFFFFFFF ETHERNET . 1 • Group address ETHERKET 1 • locally administered address -ETHERNET. Source address 0006C7B91A29 ETHERKET 0 " No routing inforMation present ! ETHERNET 0 ¦ Universally ad»inistered address ETHERKET Fra»e Leagth ¦ 114 @x0072) ETHERHET Data Length 0x0064 A00) ETKERKET Ethernet Data Kuiber of data bytes remaining • 100 @x0060 ¦ L1C UI DSAP-.lxEO SSAP-OxED С ¦IPX SAP Packet - 3 0008С7Э91Д29 4056 -> 3 FFFFFFFFFFFF 452 - 0 Hops Dst Port IP Multicast Src Port Unknown. B301) Request Target IP 11 0 1 3 Request Target IP 11 0 0 201 Reply Target IP 11 0 0 49 Target Hdvr Addr 006C «I 00000000 00000010 00000020 00000030 00000040 00000050 00000060 00000070 FF FF FF FF FF FF 00 08 C7 B9 11 29 00 64 E0 E0 03 FF FF 00 60 00 04 00 00 00 03 FF 04 52 00 00 00 03 00 08 C7 Ё9 FF FF FF FF FF 29 40 е II ) da» 0! 06 J0 4k 57 48 3J 33 3b 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 08 C7 B9 1A 29 E3 85 00 L 67 ИЗ) Рис. 1.12. Инкапсуляция SNAP IEEE 802.3 включает немного больше накладных расходов, чем кадр Ethernet II (DSAP) и точки доступа службы источника (SSAP), чтобы выделить кадр SNAP. Управляющий код 0x03 идентифицирует ненумерованный кадр. Поле кода организации задается равным 0x00-00-00, а дальше следует поле типа: 0x08-00 для IP и 0x08-06 для ARP — такое же, как в типе кадра Ethernet П. Дейтаграммы IP, посланные в составе кадров SNAP IEEE 802.3, имеют максимальный размер 1492 и минимальный размер 38 байтов. Это слегка отличается от ограничений размера Ethernet II и отражает больший раз- размер накладных расходов инкапсуляции 802.3 SNAP. Дейтаграммы IP мень- меньше 38 байтов в длину дополняются нулями, чтобы сохранить минимальный размер кадра Ethernet, равный 64 байтам (не включая преамбулу и начальный ограничитель). Сравнение Ethernet II и IEEE 802.3 В нормальной повседневной сети действительно возможно присутствие Ethernet II и IEEE 802.3. Дело в том, что стандарты TCP/IP требуют, чтобы все хосты могли посылать и полу- получать инкапсулированные кадры Ethernet II. Кроме того, большинство хос- хостов могут получать инкапсулированные пакеты IEEE 802.3. Некоторые хосты в сети могут одновременно посылать и получать пакеты IEEE 802.3. В таком случае, однако, по умолчанию должен использоваться тип Ethernet П. На рис. 1.13 одновременно показаны пакеты IEEE 802.3 и Ethernet II, поэтому можно получить хорошее представление о различиях между двумя методами инкапсуляции.
34 Глава 1 dtp* E* СОД Xoob 2«иге tfndow ¦FRAME: Base frame properties -ETHERNET Destination address FFFFFFFFFFrT ETHERNET 1 - Group address ETHERHET .1 ¦ Locally administered address ' . -ETHERNET Source address 0008C7B9U29 • ETHERHET . . 0 • No routing information present ETHERNET 0 • Universally administered address ETHERNET Frame length : 114 @x0072) ETHERHET Data length 0x0064 A00) ETHERNET Ethernet Data Number of data bytes remaining ¦ 100 @x00D) ¦LLC UI DSAP-0xE0 SSAP-OxEO С ¦ IPX SAP Packet - 3. 0008C7B«A?9 4058 -> 3. FFFFFFFFFFFF 452 - 0 Hops ¦SAP General Svc Sesp (ЛИНПЫ - RPC Server) Nelmxk Hondo) ¦FRAME: Base fraxe properties ETHERHET ETYPE • 0x0800 Protocol POP Internet Protocol -ETHERNET: Destination address a0B0SFAb3A32 ETHERNET D • Individual address ETHERNET: 0 ¦ Universally administered address i -ETHERNET Source address : 00608CCBDC43 I ETHERHET' 0 • Ho routing information present '-' -*' -. - ' i ETHERHET: . . .. 0 • Universally administered address . ETHERHET- Frame length : 60 (ОхООЗС) ETHERHET Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ; ETHERHET Ethernet Data: Number of data bytes remaining ¦ 46 @x002E) ¦IP: ID ¦ 0x169. Proto - TCP. Ian «0 ¦TCP A . len 0. seq 16SS72S-16SS725. ack 3143336. »in 8613. »rc: 1025 F»: \ тощ \ i dst 139 I Е1Ь«тМ/вО2 3 MAC Laua вьош Рис. 1.13. Сравнение IEEE 802.3 и Ethernet II Ethernet II используется по умолчанию для большинства сетей. Как мож- можно видеть на рис. 1.13, оба формата кадров имеют шестибайтовые D8 битов) адреса места назначения и источника. Это адрес MAC, адрес Ethernet или ап- аппаратный адрес хоста, который физически соединен с сетью. Эти адреса преобразуются в четырехбайтовые C2 бита) IP-адреса с помощью протокола преобразования адресов ARP, который будет рассмотрен в следующей главе. В заголовке Ethernet II следующие два байта используются для указания типа @x08-00 для IP, 0x08-06 для ARP). Это то же самое поле, которое позже встретится в кадре 802.3 точно перед началом части данных в кадре. Кадр IEEE 802.3 имеет вместо типа двухбайтовое поле длины. Оно не имеет соот- соответствия в кадре Ethernet II, позволяя тем самым отличить эти два метода инкапсуляции кадра. За полем типа в заголовке Ethernet II следует часть кадра с данными с размером от 46 до 1500 байтов. В методе инкапсуляции IEEE 802.3 после адресов места назначения и ис- источника находится двухбайтовое поле длины. Это поле используется для указания, сколько дальше следует байтов, но не включая CRC в конце кад- кадра. После поля длины следует раздел, определенный главой 802.2 проекта IEEE. Первые три поля в этом разделе являются полями LLC. Поля DSAP и SSAP всегда заданы как АА, а контрольное поле всегда задано как 03. В сле- следующих пяти байтах данных SNAP код организации задан как 0x00-00-00,
Базовые сетевые модели 35 что требует трех байтов. Следующие два байта формируют поле типа, кото- которое является таким же, как поле типа, имеющееся в Ethernet П. Это будет 0x08-00 для IP, 0x08-06 для ARP или 0x08-35 для кадра RARP. Другие типы перечислены в Приложении В. Поле циклического избыточного кода (CRC) содержит контрольную сумму, которая используется для обнаружения в кадре ошибок. Иногда его называют также контрольной последовательностью кадра (FRC). Минимальный размер инкапсулированных кадров IEEE 802.3 и кадров Ethernet II одинаков. Но в связи с дополнительными полями, вставленны- вставленными перед данными в кадре типа IEEE 802.3 (которые занимают восемь бай- байтов), минимальный и максимальный объемы данных на восемь байтов меньше, чем для кадров типа Ethernet П. Управление потоком Управление потоком является функцией, которая предотвращает перегруз- перегрузку сети, не позволяя передающему устройству перегружать принимающие устройства данными. Существует ряд возможных причин сетевой перегруз- перегрузки. Например, высокоскоростной компьютер может создавать трафик бы- быстрее, чем сеть может его передавать, или быстрее, чем устройство назначения может его получить и обработать. Существуют три обычно ис- используемых метода обработки сетевой перегрузки: 1. Буферизация используется сетевыми устройствами для временного хранения всплесков избыточных данных в памяти, пока их нельзя будет обработать. Случайные всплески данных легко обрабатывают- обрабатываются с помощью буферизации. Однако избыточные всплески данных могут переполнить память, заставляя устройство отбрасывать все прибывающие дополнительные дейтаграммы. 2. Принимающие устройства направляют источникам сообщения по- подавления передачи, чтобы предотвратить переполнение своих буфе- буферов. Получающее устройство посылает сообщение подавления передачи, чтобы источник уменьшил текущую скорость передачи данных по нескольким причинам. Возможно, наиболее общая причи- причина возникает, когда получающее устройство начинает отбрасывать полученные данные в связи с переполнением буферов. Когда это про- происходит, получающее устройство начинает посылать подавляющие источник сообщения передающему устройству со скоростью одного сообщения на каждый отброшенный пакет. Когда они начинают при- приходить на устройство источника, оно снижает скорость данных, пока не перестанет получать сообщения. Как только принимающее устройство прекратит посылать сообщения подавления передачи, устройство-источник станет постепенно увеличивать скорость данных до тех пор, пока снова не получит запросов подавления.
36 Глава 1 3. Создание окна является схемой управления потоком, при которой устройство-источник требует от устройства-приемника подтверждения ¦'¦ приема после передачи определенного числа пакетов. При размере окна, равном трем, источник требует подтверждения после отправки трех пакетов. Посмотрим, как это работает. Устройство-источник посы- посылает три пакета устройству назначения. После получения трех пакетов устройство назначения посылает источнику подтверждение. Источник получает подтверждение и посылает еще три пакета. Если устройство назначения не получает один или большее число пакетов по какой-то причине (например, из-за переполнения буферов), у него нет достаточ- достаточного количества пакетов, чтобы послать подтверждение. Источник, не получив подтверждения, повторно посылает пакеты с уменьшенной скоростью передачи. Функции межсетевого обмена сетевого уровня 0SI Функции межсетевого обмена сетевого уровня отвечают за выбор лучшего маршрута передачи пакетов в сети, создание сетевых адресов и коммуника- коммуникационных маршрутов. Маршрутизаторы используют протокол маршрутизации для обмена слу- служебной информацией между собой, используют маршрутизируемый прото- протокол для передачи пакетов пользователя, настраивают и поддерживают таблицы маршрутизации, находят сети, адаптируют изменения межсетевой топологии, используют адрес из двух частей и ограничивают распростране- распространение широковещательных рассылок. Службы WAN Х.25 Протокол Х.25 первоначально был разработан в 1970-х гг. для предоставления неинтеллектуальному терминалу соединения WAN через общедоступные сети данных (PDN — public data network). Однако благода- благодаря своей гибкости и надежности он стал международным стандартом для пересылки данных через PDN. Ориентированный на соединение интерфейс сети коммутации пакетов (PSN) предоставляет контроль ошибок и гарантированную доставку паке- пакетов с помощью коммутируемых или виртуальных цепей. Благодаря своей надежности он используется для приложений, которые требуют надежной передачи. Маршрутизатор будет соединяться с ассемблером/дизассембле- ассемблером/дизассемблером пакетов (PAD) в сети Х.25. PAD отвечает за разбиение сообщений на пакеты и соответствующую их адресацию. Спецификация Х.25 соответствует физическому, канальному и сетевому уровням модели OSI. Однако, так как спецификация Х.25 предшествовала модели OSI, названия уровней отличаются. Например, физический уровень называется Х.21 и определяет электрические и физические интерфейсы, ко- которые могут использоваться. Второй уровень называется протоколом сба- сбалансированной процедуры доступа к каналу (LAPB, Link Access Procedure Balanced), который заботится о создании кадра, управлении потоком и конт- контроле ошибок. Уровень пакета соответствует сетевому уровню и отвечает за настройку и адресацию виртуальной цепи.
Базовые сетевые модели 37 Frame Relay Отраслевой стандартный коммутируемый Протокол Frame Relay действует на канальном уровне. Он обрабатывает множество виртуа- виртуальных каналов с помощью инкапсуляции HDLC между соединенными устройствами. Frame Relay использует высококачественную цифровую тех- технику, делая методы контроля ошибок и управления потоком ненужными. Поэтому он является более эффективным и быстрым, чем протокол Х.25, в качестве замены которого он чаще всего рассматривается. Используя упро- упрощенное кадрирование без исправления ошибок, Frame Relay может очень быстро посылать информацию своего уровня. Первоначально он зарождал- зарождался как протокол для работы с интерфейсами ISDN, поэтому был разработан как независимый протокол. Внутри Frame Relay коммутация PDN реализуется с помощью статистиче- статистического метода мультиплексирования, а не с помощью временного разделения. При статистическом мультиплексировании доступные цепи формируются из устройств, которые в данный момент ничему не поставлены в соответст- соответствие. В связи с этими динамическими характеристиками сети реального вре- времени, которые пульсируют по своей природе, являются идеальными кандидатами для Frame Relay. Управление каналом осуществляется с помощью интерфейса локально- локального управления (Local Management Interface, LMI). LMI отвечает за создание постоянного виртуального канала (PVC, Permanent Virtual Circuit) и мони- мониторинг PVC. Так как цифровые каналы менее подвержены ошибкам, Frame Relay использует только алгоритм CRC для обнаружения плохих данных, но не использует никакого механизма для их исправления. Для управления по- потоком в канале Frame Relay полагается на верхние протоколы. ATM Технология ATM (Asynchronous Transfer Mode, асинхронный ре- режим передачи) является службой с поддержкой соединения и с негаранти- негарантированной доставкой. Он хорошо масштабируется и используется в LAN и WAN. ATM отличается от Frame Relay тем, что вместо разбиения сообще- сообщений на кадры переменного размера все сообщения разбиваются на ячейки одинакового размера. Каждая ячейка имеет пятибайтовый заголовок и 48-байтовое поле данных. Так как все ячейки имеют одинаковый размер, коммутация может быть сделана очень быстрой, и поэтому необходимость в буферизации исчезает. Поскольку это асинхронный метод, нет необходимости в технике TDM. При использовании ATM станция может посылать ячейки, когда ей это по- понадобится, а не ожидать очереди передачи, как в случае TDM. Хотя ATM не соответствует точно модели OSI, большинство его функ- функций можно соотнести с канальным и сетевым уровнями. Поэтому он мо- может действовать во множестве различных физических сред передачи, включая SONET и FDDI. Уровень адаптации ATM соответствует сеансово- сеансовому и транспортному уровням модели OSI. Он отвечает за получение дан- данных для протоколов более высокого уровня, такого как IP, и сегментирует данные в 48-байтовые ячейки для передачи через сеть ATM.
38 Глава 1 ISDN Это коммуникационный протокол, предложенный телефонны- телефонными компаниями, который позволяет телефонным сетям передавать дан- данные, голос и другие источника трафика по телефонным линиям. ISDN построен на двух основных типах коммуникационных каналов. Первым яв- является канал-носитель, или В-канал (Bearer), который может переносить голос, данные или изображения со скоростью 64 Кбит/сек, а вторым являет- является канал данных, или D-канал (Data), который имеет скорость 16 Кбит/сек и используется для контрольной информации, передачи сигналов и данных управления линией. ISDN реализуется обычно в двух версиях: ISDN Basic Rate Interface (BRI) с двумя каналами В и одним каналом D и ISDN Primary Rate Interface (PRI) с 23 каналами В и каналом D. HDLC Синхронный бит-ориентированный протокол канального уров- уровня, разработанный ISO. Производный от SDLC, HDLC определяет метод инкапсуляции данных на синхронных последовательных линиях, исполь- используя символы обрамления кадра и контрольные суммы. Данные переносятся в кадрах, которые могут содержать переменный объем данных. SLIP Используется как метод инкапсуляции последовательного кана- канала, поэтому является простым протоколом кадрирования пакетов. SLIP определяет несколько символов, которые обрамляют пакеты IP в последо- последовательном канале. Это техника с минимальными накладными расходами, которая не предоставляет согласования адресации, идентификации прото- протокола, обнаружения ошибок или механизма сжатия. Созданный для исполь- использования на медленных последовательных линиях связи (например, модемах), он определяет два специальных символа, которые применяются для обрамления кадра. Первый — символ END (OxCO), который используется для определения конца дейтаграммы IP. Второй символ — ESC (OxDB) используется для ука- указания, когда символ ОхСО встречается внутри дейтаграммы IP. ESC-символ SLIP отличается от ESC-символа ASCII (OxlB). SLIP использует технику, называемую символьным заполнением, для предотвращения появления символа END в середине дейтаграммы IP. Если символ END (OxCO) встречается внутри исходной дейтаграммы IP, то он за- заменяется последовательностью OxDB-DC. Если символ ESC (OxDB) встреча- встречается внутри дейтаграммы IP, то он заменяется последовательностью OxDB-DD. Это предотвращает зависание модема в середине передачи. Максимальный размер дейтаграммы IP для SLIP обычно ограничен 1500 байтами на более новых системах или 1006 байтами на реализациях Berkley UNIX версии 4.2. Однако эта распространенная практика не определена в стандартах. Чтобы сократить объем накладных расходов на потенциально медлен- медленных последовательных линиях связи, в RFC 1144 определен метод сжатия заголовков IP и TCP в заголовок размером от 3-х до 5-ти байтов, который известен как C-SLIP или Compressed SLIP.
Базовые сетевые модели 39 РРР Протокол РРР — наследник SLIP. РРР предоставляет соединения маршрутизатор-маршрутизатор и хост-сеть через синхронные последовате- последовательные линии связи, такие как ISDN или SONET, а также асинхронные кана- каналы, например типичные телефонные коммутируемые линии. Он исправляет недостатки SLIP. РРР является семейством протоколов, которые предоставляют мульти- протокольную инкапсуляцию, протокол контроля линии (LCP) для созда- создания, конфигурирования и тестирования соединения канала данных, и семейство протоколов управления сетью (NCP) для создания и конфигури- конфигурирования протоколов различных сетевых уровней. Как можно видеть на рис. 1.14, РРР устанавливает флаг как 0х7Е @1111110), чтобы указать начало и конец кадра РРР. В последовательных кадрах РРР будет задан только один символ флага. Поле адреса использует- используется для адресации пакета для узла места назначения. В двухточечной линии связи узел назначения адресовать не нужно. Поэтому в РРР поле адреса задается как OxFF, т.е. как адрес широковещания. В среде HDLC контрольное поле используется для функции подтвержде- подтверждения и упорядочивания уровня канала данных; однако в РРР контрольное поле задано как 0x03 для указания кадра ненумерованной информации (UI). Это то же самое, что и бит, который задается в методах кадрирования Ethernet. Netmxfc Monti» ¦ (GAvpnZcap (Detain I* Q"Pto» 1°°!' Wndow Help mm rw мел i ш Frame|T 1429 Time |Src НАС AddjDst MACAdcilproToccjDescription 292 6HPROX IJVH BA EX SMB 1С transact2 30 292 6.6FROX 9E32EAO0O10 PPP lrst Choice Co Findfirst. File 431 432 «33 «34 292.92PROX 292 92PROX 292.939E32EA00010 292 93JVH_BA_?X JVR_BA EX 9ЕЭ2ЕА0! PROX PROX 0D10 SHB PPP PPP SMB С transacts Findfirst. File • 4* lrst Choice Compression Frame (OxFD) lrst Choice Compression Frame (OxFD) R transact2 Findfirst (response to frame 431) M +FRAHE1 Base frame properties ¦ETHERMET: ETYPE • 0x0800 Protocol - IP: DOD Internet Protocol ¦IP ID - 0x«76F; Proto - 0x2F Len 148 ¦C-RE KS A . length: 112. Call ID 0 "•PPP lrst Choice Connression Fre*e (OxFC l s _Г" 00000000 00000010 00000020 00000030 00000040 00000050 00000060 00000070 00000080 00000090 000000A0 9E 32 00 94 07 8A 00 33 01 A3 Ы SB 56 BF 89 «0 «0 Fl E5 40 00 00 EA 00 «7 6F 30 81 ДЛЕО 6A Cl B0 03 A9 A6 A2 К DE 1С BO 04 01 01 00 00 86 0B 4E 00 60 00 2E 16 Al 19 0В 20 80 00 A8 00 00 01 80 2F 00 70 21 45 12 CF CS 01 79 20 11 02 04 00 10 00 90 DD 78 F0 00 00 ЭС 00 11 49 82 00 01 80 00 18 22 79 10 07 66 SO CE 70 00 00 81 23 05 B4 A8 ?3 38 04 78 97 52 02 CC 85 08 00 45 00 CB C9 D8 17 00 SA 00 00 37 A0 00 40 00 «2 CO 00 90 00 07 84 12 07 E« C7 АО 0А 00 00 00 02 00 2B CO 02 A0 00 Р20. oGo. eOue 3fiaH lie-' fdC e#d*. s4>! i. EjfC. E. - I | B+. +.*.tpE..a У .Св...S| ...xua... "yR . + Protocol Identf* o> E ncaptijaled Oata 0№50(«32| Рис. 1.14. Протокол РРР инкапсулирует IP для улучшенной передачи через синхронные и асинхронные каналы
40 Глава 1 Поле протокола имеет два байта и используется для идентификации протокола в полезной нагрузке РРР. Если поле задано как 0x00-21, то оно указывает на дейтаграмму IP. Контрольная последовательность кадра (FCS) является двухбайтовой CRC, аналогичной тому, что используется для ин- инкапсуляции Ethernet. Как и SLIP, РРР имеет метод, предотвращающий появление символа флага в середине данных. В синхронной линии связи, такой как ISDN, ис- используется заполнение битами для вставки дополнительных битов, чтобы отметить, когда появляется символ флага. Закодированное представление байтов может содержать более 8 битов, но дополнительные биты добавля- добавляются и удаляются аппаратурой синхронной линии связи. РРР использует также заполнение символами (подобно SLIP) на асинх- асинхронных линиях для предотвращения появления флага внутри кадра РРР. Если символ 0х7Е появляется в исходной дейтаграмме IP, то он заменяется строкой символов 0x7D-5D. Если символ ESC @x7D) возникает в исходной дейтаграмме, то он заменяется последовательностью 0x7D-5D снова в 0x7D. Символы меньше 0x20 также модифицируются, чтобы последователь- последовательные драйверы не интерпретировали их как управляющие символы, посы- посылая 0x7D, а затем исходный символ с дополненным шестым битом. Максимальная получаемая единица данных (MRU) равна 1500 байтам. Nrfwut МопКя - (G:\vpn2 cap (DetailII ?1 fie ?4 IP DOD Internet Protocol vFRAHE Base frame properties ¦ETHERNET: ETYPE - 0x0800 Protocol -IP ID - 0x4D6F: Proto ¦ 0x2F. Len 3? IP: Version ¦ 4 @x4) IP- Header Length - 20 @x14) ." ''*' .' ""."' ¦IP Service Type ¦ 0 @x0) IP: Total Length ¦ 32 @x20) IP: Identification • 19823 @x4D6F) ¦IP' Flags Summary ¦ 0 @x0) IP. Fragment Offset • 0 @x0) bytes IP Time to Live • 128 @x80) IP: Protocol ¦ Generic Routing Encapsulation IP Checksum - 0x7364 IP: Source Address ¦ J06 112.203 201 IP Destination Address ¦ 216 23 7 138 IP: Data: Humber at data bytes remaining • 12 (OxOOOC) -GRE К I l-r.qnh С Call I DO jJL GRE: 0 GRE: .0 GRE ..I GRE .0 GRE 0 GRE 1 GRE: Recursion Control GRE Ver ¦ 1 @x1) GRE: Protocol Type ¦ ОхвЗОВ GRE. Key length • 0 @x0) GRE: Key Call ID • 0 @x0) Checksum Absent Routing Absent Key Present Sequence Number Absent Strict Source Route Absent Acknowledge Sequence Humber Present 0 @x0) V. 00000000 9E 32 EA 00 01 01 00 01 90 DD 66 80 08 00 45 00 P20 00000010 00 20 4D6F 00 00 80 2F 73 64 CE 70 CB О D8 17 Ho 00000020 07 8A НЯЕП 88 0B 00 00 00 00 00 00 00 36 К EKC E. d ¦>] |Ft «41/491 [L2fx2| Рис. 1.15. Кадр РРТР имеет несколько заголовков перед информацией заголовка GRE
Базовые сетевые модели 41 РРТР Протокол РРТР является способом взять существующий кадр РРР и инкапсулировать его через межсетевой обмен IP. РРТР позволяет со- создать в Интернете защищенные виртуальные частные сети (VPN). РРТР мо- может использоваться независимо от того, поддерживает VPN провайдер услуг Интернета (ISP) или нет. Требуется только сервер, поддерживающий РРТР, и клиент, который может создать соединение РРТР. Инкапсуляция кадров РРР реализуется с помощью протокола инкапсуля- инкапсуляции базовой маршрутизации (GRE), который использует ID протокола IP, равный 47 @x2F). Для использования его с РРТР протокол GRE был усовер- усовершенствован, чтобы предоставить поле подтверждения. Как показано на рис. 1.15, кадр РРТР имеет заголовок среды и заголовок IP, прежде чем добраться до заголовка GRE. После заголовка GRE следует заголовок РРР, а затем полезная нагрузка РРР. Заголовок GRE начинается с двух байтов для флагов. Эти флаги указыва- указывают, присутствует ли полезная нагрузка GRE и номера последовательности и подтверждения. Поле типа протокола содержит значение Ethernet, которое соответствует РРР @х88-0В). Длина полезной нагрузки равна размеру полез- полезной нагрузки GRE в байтах. Идентификатор (ID) вызова является информа- информацией идентификации сеанса для этого пакета РРТР, за которым следуют номера последовательности и номер подтверждения — самый большой но- номер последовательности, полученный посылающим узлом этого сеанса. Номер последовательности используется для управления потоком, а не для повторной передачи потерянных кадров РРТР. Обзор главы В этой главе был охвачен большой материал. Она началась с рассмотрения модели OSI, где был показан уровень функциональности, предоставляемый каждым уровнем модели. Затем мы остановились на изменениях, сделанных в модели OSI проектом IEEE 802, и увидели, что канальный уровень был раз- разделен на две части: подуровень управления логическим каналом и подуро- подуровень управления доступом к среде передачи. Эти изменения предоставили немного больше контроля над нижними уровнями, позволяя управлению логического канала быть независимым от среды, так как он расположен поверх уровня MAC. Рассматривая формирование пакетов, мы познакомились с используемой терминологией (дейтаграммы IP, сегменты TCP, а также кадры Ethernet). После этого мы подробно рассмотрели реальную работу Ethernet, контроль несущей, обработку множественного доступа. Были обсуждены методы обнаружения конфликтов. Затем была исследована роль протоколов, концепция стека протоколов и иерархического подхода к сетевой коммуникации. Мы увидели, как рабо- работает связывание, позволяющее менять протоколы, не меняя при этом драй- драйверы сетевых адаптеров, а также ознакомились с концепцией порядка связывания протоколов.
42 Глава 1 Наконец, мы обратились к инкапсуляции данных и исследовали многие распространенные методы инкапсуляции, которые используются в насто- настоящее время. Мы обсудили роль заголовков и рассмотрели каждое из полей в наиболее популярных протоколах уровня сетевого интерфейса. В следующей главе - * Глава начинается с изучения стека протоколов TCP/IP. Мы увидим, как па- пакет протоколов отображается на различные уровни модели OSI, и исследу- исследуем некоторые из протоколов, обычно реализуемых в стандартном стеке протоколов TCP/IP. Затем мы рассмотрим протокол TCP и методы, которые он использует для обеспечения надежной передачи с поддержкой соединения. Мы обсудим методы управления потоком и упорядочивающие номера. Затем перейдем к протоколу IP. При обсуждении IP достаточно подробно исследуется способ инкапсу- инкапсуляции данных, заголовок IP и т.п. Будут рассмотрены наиболее общие команды, используемые с IP, и приведены рекомендации, которые помогут в дальнейшем при поиске неисправностей.
Глава 2 Стек протоколов TCP/IP Как упоминалось в предыдущей главе, TCP/IP — это не просто один-два протокола; обычно реализуется сразу целый набор протоколов, или, как иногда называют, стек протоколов. В предыдущей главе мы познакомились с соответствием между протоколами из стека TCP/IP и эталонной моделью OSI, но теперь рассмотрим этот стек более подробно. Как можно видеть на рис. 2.1, стек TCP/IP состоит из четырех уровней: уровень приложений, транспортный уровень, уровень Интернета и сетевой уровень. В совокуп- совокупности эти четыре уровня охватывают все функции модели OSI. Внизу стека находится уровень сетевого интерфейса, который соответ- соответствует физическому уровню модели OSI. Этот уровень отвечает за перенос кадров в среду передачи и за извлечение кадров из среды передачи. Необ- Необходимо отметить, что это независимый от среды передачи уровень. Не имеет значения, будет ли это медный провод, волоконно-оптический ка- кабель, лазер, инфракрасные лучи или радио. Кроме того, он не зависит от метода доступа к среде. Поэтому в локальной вычислительной сети (LAN) стек TCP/IP можно использовать поверх Ethernet, Token Ring или FDDI, и, конечно, можно использовать TCP/IP совместно с различными технологи- технологиями глобальных сетей (WAN), таких как последовательный канал, исполь- использующий старый протокол SLIP, или протокол РРР, который был создан как усовершенствование старого стандарта SLIP. РРР предоставляет службы ка- канального уровня, которые включают обнаружение ошибок, управление конфигурацией, а также методы безопасности. Другим типом технологий WAN является коммутация пакетов, например Frame Relay или ATM. Следующим уровнем снизу является уровень Интернета, который предо- предоставляет функции, соответствующие второму (канальному) и третьему (сете- (сетевому) уровням модели OSI. Уровень Интернета отвечает за инкапсуляцию пакетов в дейтаграммы IP и выполняет все необходимые алгоритмы маршру- маршрутизации. Здесь имеются четыре протокола IP: протокол управляющих сооб- сообщений Интернета (Internet Control Message Protocol, ICMP), протокол управления группами Интернет (Internet Group Management Protocol,
44 Глава 2 7. Уровень приложений 6. Уровень представлений 5. Сеансовый уровень Приложение Транспорт Интернет Сеть Рис. 2.1. Пакет протоколов TCP/IP состоит из четырех уровней, приблизительно соответствующих модели 0SI IGMP), протокол Интернет (Internet Protocol, IP) и протокол преобразова- преобразования адресов (Address Resolution Protocol, ARP). Протокол ICMP использу- используется для отправки сообщений и сообщений об ошибках относительно доставки пакетов. Он осуществляет это от имени IP. ICMP не делает IP "на- "надежным" протоколом, но он может предоставить определенный уровень обратной связи по специальным условиям. Сами сообщения ICMP перено- переносятся как дейтаграммы, т.е. без обеспечения надежности. Следующим про- протоколом, представленным на этом уровне, является IGMP. Он используется компьютерами для сообщения о своем членстве в определенной группе,
Стек протоколов TCP/IP 45 чтобы получать широковещательные рассылки от маршрутизаторов, кото- которые поддерживают широковещание. Эти рассылки передаются как дейтаг- дейтаграммы, т.е. являются ненадежной формой коммуникации. Последними двумя протоколами Интернета, о которых необходимо сказать, являются IP и ARP. В связи с важностью сетевой коммуникации мы рассмотрим их более детально. Остановимся сначала на протоколе IP. IP отвечает за адресацию и маршрутизацию пакетов между компьютера- компьютерами и сетями. (Каждое устройство в сети IP, имеющее IP-адрес, называется хостом; иногда хостами называют компьютеры, маршрутизаторы, принте- принтеры и даже управляемые концентраторы.) Именно поэтому адрес, присвоен- присвоенный хосту, поддерживающему стек TCP/IP, называется IP-адресом. Это протокол без поддержки соединения, т.е. он не создает сеанс перед переда- передачей данных. В этом отношении он является ненадежным протоколом, так как не гарантирует доставку, не требуя подтверждения, что данные получе- получены в месте назначения. Следующим протоколом уровня Интернета является протокол ARP. ARP используется для поиска аппаратного адреса машины в сети. Этот ад- адрес, называемый иногда адресом MAC или адресом платы Ethernet, требует- требуется, если два компьютера собираются общаться друг с другом. Адрес MAC должен быть преобразован в адрес IP, чтобы хосты общались с помощью протокола IP. ARP преобразует адрес с помощью широковещательной рас- рассылки для всех хостов в локальной сети. Компьютер места назначения будет отвечать пакетом, который содержит IP-адрес и адрес MAC. Эта информа- информация будет затем храниться в кэше ARP на локальной машине. Последующая информация предназначена для удаленного хоста; сначала будет проверя- проверяться кэш ARP, а затем посылаться другое широковещательное сообщение. Второй уровень сверху является транспортным уровнем, отвечающим за обеспечение сеансов коммуникации между компьютерами. В стеке сущест- существуют два транспортных протокола. Это протокол управления передачей (Transmission Control Protocol, TCP) и протокол пользовательских дейтаг- дейтаграмм (User Datagram Protocol, UDP). Для наличия двух транспортных про- протоколов в стеке есть серьезная причина, так как они работают по-разному. TCP является протоколом с поддержкой соединения, т.е. сначала он созда- создает соединение с другой машиной. Используемый, когда требуется надежное соединение, он обеспечивает подтверждение доставки каждого пакета. Если подтверждение не получено, то посылающий компьютер пошлет ин- информацию повторно. С другой стороны, UDP является протоколом без поддержки соединения, он не требует соединения и не гарантирует достав- доставку пакета. Это протокол, работающий без гарантии доставки: он оставляет задачу отслеживания пакетов и управление потоком данных приложению, которое обращается к транспортному уровню. Вверху модели находится уровень приложений. В стандартной реализа- реализации стека протоколов TCP/IP на этом уровне существует множество утилит. Такие протоколы, как FTP (File Transfer Protocol, протокол передачи фай- файлов), Telnet, SNMP (Simple Network Management Protocol, простой протокол управления сетью), DNS (служба имен доменов) находятся на этом уровне, так как именно здесь приложения получают доступ к сети. В реализации
46 Глава 2 TCP/IP компании Microsoft есть два способа, которыми приложения могут получить доступ к сети: либо через NetBIOS, либо через Windows Sockets. Интерфейс NetBIOS позволяет протоколам TCP/IP или NetBEUI использо- использовать службы именования и сообщений, используя соглашение об именах NetBIOS, в то время как служба Windows Sockets предоставляет интерфейс прикладного программирования (API) для транспортных протоколов, таких как TCP/IP или IPX. Протокол TCP Протокол управления передачей (протокол TCP) может выполнять базовую пересылку данных, используя непрерывный поток данных размером в байт. Данные упаковываются в сегменты для передачи протоколом Интернета. В общем TCP сам выполняет управление потоком и сам решает, когда переда- передавать и когда задержать данные, если потребуется. Определена функция push, которая позволяет пользователю узнать, когда TCP успешно передал все дан- данные, предоставленные ему приложением. Посылающий TCP может соби- собирать данные от посылающих пользователей и посылать эти данные в сегментах по своему собственному усмотрению, пока не будет вызвана функ- функция push, после чего он должен послать все не отосланные данные. Когда принимающий TCP видит флаг PUSH, он не должен ждать дополнительные данные от посылающего TCP, прежде чем передать данные в получающий процесс. Push заставляет TCP переслать и доставить полученные до этого момента данные прямо получателю. Мы увидим флаг push в некоторых примерах. Чтобы восстановить поврежденные, потерянные, пришедшие в непра- неправильном порядке или как-нибудь иначе поврежденные данные, TCP присва- присваивает порядковый номер каждому передаваемому октету. Это позволяет уровню TCP на получающей машине знать, в каком порядке должны прий- прийти пакеты, чтобы правильно их собрать. В дополнение к порядковым номе- номерам, каждый правильно полученный пакет должен также подтверждаться (путем передачи служебного сообщения АСК) получающим TCP. Если АСК не получен в течение периода ожидания, данные будут посланы повторно. Для определения, что пакет был поврежден, используется контрольная сумма. Она добавляется к каждому сегменту, передаваемому посылающей машиной, и проверяется получателем. Управление потоком обеспечивается с помощью "окна", которое посы- посылается назад с каждым АСК. Это окно является диапазоном порядковых но- номеров, которые могут быть переданы в следующем раунде коммуникации. Они находятся за последним успешно полученным сегментом. Окно указы- указывает число октетов, которое может послать отправитель, прежде чем полу- получить следующее разрешение. Чтобы хост разрешал общаться через TCP в одно время нескольким процессам, используются порты. Добавление номе- номера порта в конце адреса IP (например: 123.123.123.123:29) формирует со- кет. Пара сокетов используется для идентификации соединения, поэтому сокет можно использовать для переноса данных в обоих направлениях в одно время, т.е. это "дуплексная передача".
Стек протоколов TCP/IP 47 Хотя каждый хост отвечает за номера портов, которые он использует для этих соединений, некоторые функции были присвоены "хорошо известным портам". Эти службы доступны по известным адресам. Список этих хорошо известных портов находится в Приложении А. Комбинация сокетов, номе- номеров последовательности и размеров окон называется соединением. Два про- процесса общаются, устанавливая сначала соединение. Когда коммуникация заканчивается, соединение закрывается, чтобы освободить ресурсы. Есть два интерфейса, поддерживаемые протоколом управления переда- передачей. Это интерфейс пользователя и интерфейс Интернета. Интерфейс по- пользователя позволяет вызвать пять основных функций протокола. Этими функциями являются: Открыть соединение, Закрыть соединение, Пере- Передать данные, Получить данные и Статус. Функция "Статус" выдает инфор- информацию о соединении. Эти пять вызовов действуют так же, как их аналоги в любой другой программе. Например, можно открыть или закрыть файл таким же образом, как TCP выполняет функции аналогичного типа. Пассив- Пассивный запрос OPEN (открыть) означает, что процесс хочет принять входящие запросы соединения, а не пытается инициировать соединение. Часто процесс, запрашивающий пассивный OPEN, будет принимать за- запрос соединения от любого вызывающего абонента. В этом случае для обо- обозначения неуказанного сокета будет использоваться внешний сокет только из нулей. Неопределенные внешние сокеты допускаются только на пас- пассивных OPEN. Процесс службы, которая желает предоставлять услуги для других неизвестных процессов, будет создавать пассивный запрос OPEN с неопределенным внешним сокетом. Затем можно будет создать соедине- соединение с любым процессом, который запрашивает соединение с этим локаль- локальным сокетом. Это полезно, если известно, что этот локальный сокет связан с данной службой. Хорошо известные сокеты являются удобным механизмом связывания адреса сокета со стандартной службой. Например, процесс "TelnetServer" постоянно присвоен определенному сокету, а другие сокеты зарезервиро- зарезервированы для передачи файлов. Интерфейс Интернета, поддерживаемый TCP, предоставляет только два вызова. Он может посылать или получать дейтаг- дейтаграммы, адресованные модулям TCP на других хостах. Эти вызовы имеют ряд параметров, которые можно задавать. Они задаются как флаги в кадре, как мы увидим в примерах трассировок. Эти параметры включают тип службы, приоритеты, безопасность и другую управляющую информацию. Заголовок TCP Поля источника и места назначения Рассмотрим структуру заголов- заголовка TCP. Для этого обратимся к рис. 2.2 и разберем сегмент TCP, перехвачен- перехваченный сетевым монитором. Первое поле, которое встречается в заголовке TCP,— это порт источника, 16-разрядное поле, используемое для идентифи- идентификации процесса на исходном компьютере, посылающем сегмент TCP целево- целевому компьютеру. На рис. 2.2 это 0x04-05 (десятичное 1029). Следующее поле (очевидно) является портом места назначения. Как и порт источника, это также 16-разрядное поле, которое используется для идентификации процесса на принимающей машине. На рисунке это порт telnet 0x17 B3).
48 Глава 2 Netwoik Morale» - IFAbookcap«\98 logmi.cap (DetalH ЙКЮП» Vndow ISIB1 \ Щ Щ isi Src MAC Add Dst ИАС Add Description _|, а 561 KEHMV S71KEHNY 081 KEHHY 096 KEHHY 09t TERESA PROX PROX •BROADCAST •BROADCAST KEHHY HBT HBT HBT HBT HBT NS Registration req. for HGROCE <03> HS. Query req. for TERESA HS. Registration req for MGROCE <03> HS: Query req. for TERESA HS Query (Hode Status) rasp, for TERESA. Success 5091-45098. ack 12 09?TERESA KEHHY TERESA TCP TCP s.. len: lsn: 4. seq: 4S092-45052. ack. 797246C"* ¦FRAME Base frane properties ¦ETHERHET: ETYPE • 0x0800 : Protocol - IP: DOD Internet Protocol ¦IP ID • 0x3100; Proto - TCP. len: 46 •цТСР: S.. len: 8. seq: 45091-45098. ack. l^TCP: Source Port - 0x0401 Destination Port ¦ NETBIOS Session Service Sequence Hunoer - 45091 @x8023) AcknovledgeMent Humber ¦ 0 @x0) Data Offset • 28 (OxlC) Reserved • 0 @x0000) ' - Flags ¦ 0x02 : .. S. ¦ Ho urgent data * Acknowledgement field not significant •• Ho Push function ¦ Ho Reset * Synchronize sequence numbers Ho Fin 0. «in: 8192. src: 1025 dst: 139 (НГУ TCP: TCP: TCP: TCP: TCP: -TCP TCP: . .0. TCP: . .0.. . TCP: 0 .. TCP: 0 TCP: 1. TCP: 0 TCP: «indov ¦ 8192 @x2000) TCP: Checksu» ¦ 0x9A19 TCP: Urgent Pointer ¦ 0 @x0) TCP Option Kind (HaxiauM Segment bize) TCP: Option Length ¦ 4 @x4) TCP: Option Value ¦ 1460 @x5B4) г @x2) •-¦-¦г Packet options IF* 14/S3 Рис. 2.2. Типичный заголовок TCP в сетевом мониторе ^ Поле порядкового номера Теперь мы переходим к порядковому номе- номеру. 32-разрядное поле используется для идентификации порядкового номе- номера, который соответствует первому байту в этом сегменте. Упорядочивание TCP использует смещение байта в потоке данных для указания, где в потоке находятся данные. Когда флаг SYN (синхронизации) задается во время уста- установления соединения, номер последовательности становится начальным порядковым номером (ISN). Когда данные посылаются, ISN увеличивается на 1. Это сообщает посылающей и принимающей машинам, где в потоке данных они работают. Поле подтверждения Следующие 32 бита являются полем подтверж- подтверждения, которое указывает посылающей машине, что предыдущий сегмент был получен без изменений. Это поле имеет значение, только если задан флаг АСК (подтверждение). Это поле очень важно для установленного соединения. Поле смещения данных Это четырехразрядное поле используется для указания, где начинается полезная нагрузка TCP. Оно называется также полем длины заголовка, так как после вычисления, где начинаются данные TCP, мы знаем длину заголовка. Длина заголовка TCP (включая параметры) всегда кратна 32 битам и не превосходит 60 байтов. Шесть битов, следую- следующих за полем сдвига данных, зарезервированы и должны быть заданы как 0.
Стек протоколов TCP/IP 49 Шесть флагов TCP В заголовке TCP можно установить шесть флагов (см. ниже). Они устанавливаются с помощью одноразрядного поля для каж- каждого из доступных флагов. Поэтому поле флагов занимает в заголовке всего шесть битов. Если флаг не установлен (т.е. сброшен), то в соответствующем поле стоит значение 0. 1. Поле срочности (URG) существенно. При заданном флаге в поле ука- указателя срочности содержатся важные данные. Срочные данные не являются частью обычного потока данных и будут обрабатываться до о любых других данных. Срочные данные могут использоваться для ¦ '• '< прерывания программ и уведомления приложения о событиях десин- .¦''¦¦ хронизации. Они используются также для передачи по сети приложе- \.'- нию сообщения, которое не является частью текущего потока данных (данные вне полосы). . 2. Поле подтверждения (АСК) существенно, когда задан этот флаг. Когда создано нормальное соединение, флаг АСК будет постоянно в работе. 3. Флаг выталкивания (PSH) указывает, что данные в сегменте и другие полученные данные, которые находятся в буфере получения, немедлен- немедленно должны быть переданы в приложение. TCP часто будет держать вхо- входящие данные в буфере получения, когда буфер заполняется, он передает данные приложению. Это может вызывать проблемы в неко- некоторых приложениях, таких как Telnet, которому необходимо иметь воз- возможность передать клавишный ввод на другую машину. Выталкиваемые данные не должны подтверждаться немедленно, это может произойти при следующей нормальной передаче данных. 4. Флаг сброса (RST) используется для прекращения соединения. Когда на активном соединении получен флаг сброса, это означает, что про- произошла ошибка, и соединение должно быть принудительно закрыто. Получение сброса при попытке установления соединения означает отказ. 5. Флаг синхронизированного порядкового номера (SYN) используется в начале настройки соединения для создания порядковых номеров и подтверждения. До создания соединения ни одна из машин не знает о порядковых номерах другой машины. В начале общения используется трехходовое квитирование для передачи информации о порядковых номерах. Флаг SYN используется для согласования порядковых номеров. 6. Флаг завершения отправки данных (FIN) "культурно" завершает сое- ;. .. динение TCP. Когда одна машина хочет прекратить соединение, она посылает сегмент с установленным флагом FIN. Если обе машины послали сегменты с установленным FIN и подтвердили флаг, соеди- соединение завершается. . ' ,
50 """" Глава 2 Поле окна Поле окна содержит 16 битов и используется для указания числа байтов, которое готов принять отправитель сегмента TCP. Эти дан- данные должны начинаться с октета, указанного в поле подтверждения, иначе они будут отвергнуты. Это окно является явным указанием размера буфера TCP на посылающем хосте. Оно также используется для определения мак- максимального порядкового номера, который может быть подтвержден из это- этого сегмента добавлением номера текущего подтверждения к номеру поля окна. Контрольная сумма Контрольная сумма является 16-битным числом, представляющим собой двоичное дополнение суммы дополнений до едини- единицы всех 16-битных слов в заголовке TCP и тексте. Если сегмент имеет не- нечетное число октетов текста и заголовка, то последний октет дополняется справа нулями, пока не будет сформировано 16-битное слово для использо- использования при вычислении контрольной суммы. Важно отметить, что дополне- дополнение нулями не передается. Пока контрольная сумма вычисляется, поле контрольной суммы заполняется нулями. Указатель срочности Поле указателя срочности является 16-битным полем, которое задается равным порядковому номеру последнего октета срочных данных. Оно используется, только когда передаются сегменты с битом URG (срочный). Иначе это поле задается равным нулю @x0). Заполнение кадра и параметры Поле параметров является набо- набором из 32 битов, которые используются для хранения параметров TCP. Если параметры не используют все 32-битное поле, оно заполняется нулями. Трехходовое квитирование Процедура создания соединений использует флаг управления синхрониза- синхронизацией (SYN) и включает обмен тремя сообщениями. Этот обмен был назван трехходовым квитированием. Соединение инициируется при встрече при- прибывающего сегмента, содержащего SYN, и ожидающего входа TCN, кото- которые создаются командой пользователя OPEN. Соответствие локального и внешнего сокетов определяет, когда соединение было инициировано. Сое- Соединение становится "установленным", когда номера последовательности синхронизированы в обоих направлениях. Очистка соединения также включает обмен сегментами, несущими в этом случае управляющий флаг FIN. Протокол не делает никаких ограничений на повторное использова- использование определенного соединения. Соединение определяется парой сокетов. Новые экземпляры соединения будут называться инкарнациями соедине- соединения. При этом возникает проблема: "Как TCP идентифицирует сегменты дубликаты из предыдущих инкарнаций соединения?" Эта проблема стано- становится очевидной, если соединение открывается и закрывается в быстрой последовательности или прерывается в связи с нехваткой памяти, а затем восстанавливается. Чтобы избежать путаницы, необходимо воспрепятствовать использова- использованию сегментов из одной инкарнации соединения, в то время как те же самые номера последовательности от предыдущей инкарнации могут по-прежнему
Стек протоколов TCP/IP 51 присутствовать в сети. Мы хотим гарантировать это, даже если TCP преры- прерывает работу и теряет всю информацию о номерах последовательности, ко- которые он использует. Когда создается новое соединение, используется генератор начального порядкового номера (ISN), который выбирает но- новый 32- разрядный ISN. Генератор связан с 32-битными часами (возможно, фиктивными), младший бит которых увеличивается каждые четыре милли- миллисекунды. Таким образом, ISN циклически повторяется примерно каждые 4,55 часов. Так как мы предполагаем, что сегменты будут оставаться в сети не дольше, чем максимальное время жизни сегмента (MSL), и что MSL меньше 4,55 часов, то можно считать, что ISN будет уникальным. Для каждого соединения существует номер посылаемой последователь- последовательности и номер получаемой последовательности. Начальный номер посыла- посылаемой последовательности (ISS) выбирается посылающим данные TCP, a начальный номер принимаемой последовательности (IRS) узнается во время процедуры создания соединения. Чтобы соединение было установле- установлено или инициализировано, два TCP должны синхронизировать друг с дру- другом начальные номера последовательностей. Это делается при обмене устанавливающими соединение сегментами, несущими управляющий бит, называемый "SYN" (от слова синхронизация), и начальные номера последо- последовательностей. В качестве сокращения сегменты, переносящие бит SYN, также называются "SYN". Следовательно, решение требует подходящего ме- механизма для выбора начального номера последовательности и небольшого привлечения квитирования для обмена ISN. Синхронизация требует, чтобы каждая сторона посылала свой собствен- собственный начальный номер последовательности и получала подтверждение от другой стороны. Каждая сторона должна также получить начальный номер последовательности другой стороны и послать об этом подтверждение. 1. А—> В SYN мой номер последовательности X . . . . 2. А <--В АСК ваш номер последовательности X 3. А<—В SYN мой номер последовательности Y , i 4. А—> В АСК ваш номер последовательности Y Так как шаги 2 и 3 обычно объединяются в одном сообщении, то после- последовательность называется трехходовым квитированием. На рис. 2.3 показа- показано, как это выглядит в реальной жизни. Трехходовое квитирование необходимо в связи с тем, что номера после- последовательности не связаны с глобальными часами сети, и TCP может иметь другие механизмы для выбора ISN. Получатель первого SYN не может уз- узнать, является ли сегмент задержавшимся старым или нет, если он не по- помнит последний номер последовательности, использованный соединением (что не всегда возможно). Поэтому он должен запросить отправителя про- проверить, что TCP не создал сегмент, несущий номер последовательности, который может дублироваться старым сегментом, остающимся в сети. TCP должен оставаться спокойным в течение максимального периода жизни (MSL), прежде чем присваивать какие-либо номера последовательности
NeOratk Молям ¦ IF:Vboolccsps\3Harfundslu*B.cap Ше1аЛ1 l<3) |g|e>l5|Q| 111 * \\?Щ iiaf ISic HJC AddlDst НАС Add)Fro 1 0 650 KEHHY TERESA TCP 59059-59059. ack: 1816821 16 328 IKEHNY 16.329 ITERESA TERESA IKEWHY TCP TCP len len 18356770-18356773. ack ¦FRAHE Ease frame properties ¦ETHERNET ETYPE ¦ 0x0800 Protocol ¦ IP ID ¦ 0x4900. Proto • TCP. len IP DOD Internet Protocol 59059-59059 ack 18168214. win; TCP TCP TCP TCP. ¦TCP. TCP TCP TCP TCP Source Port ¦ 0x0401 Destination Port - NETBIOS Session Service Sequence Number - 59059 (ОхЕбВЗ) Acknowledgement Number ¦ 18168214 @xllS3996) Data Offset - 20 @x14) Reserved • 0 @x0000) Flags ¦ 0x10 . A. Vindov • 8590 @x218E) Checksum ¦ 0x5405 Urgent Pointer ¦ 0 @x0) Frame Padding I iL 00000000 00 80 SF OF C8 4i 00 10"ТВ EC~8D В2"8 0 TS 00 00000010 00 28 49 00 40 00 80 06 9D 79 0A 00 00 4C 0A 00 00000020 00 0B СД|Щ|||Ю:Щ|||М|Т|Щз(Д1:кИ||ИЬШЬЖ.1:».Ч1»11^ 00000030 w:i«f Д|1Д|Т|Ж111моо ПД 00 DO 00 00 g+J MifT (I.» <; ?y 1 trfr ±L .TCP protocol «j»m*y " frSTT/3 !О(Г34 |х22) Рис. 2.З. Для создания надежного соединения TCP использует трехходовое квитирование при запуске или восстановлении после ошибки, при которой память исполь- используемых номеров последовательности была стерта. Для этой спецификации MSL задается равным двум минутам. Это инженерный выбор, который мо- может быть изменен, если опыт покажет такую необходимость. Отметим, что если TCP повторно инициализирован, но сохранил в памяти номера после- последовательности, ему вообще не нужно ждать, он должен лишь использовать номера последовательности, превышающие использованные ранее. Концепция времени молчания TCP Если при аварийном прекращении работы хост не сохраняет никакой ин- информации о последних номерах последовательности, переданных во время активного (т.е. не закрытого) соединения, при отправке любых сегментов TCP будет происходить задержка на период не менее согласованного вре- времени MSL внутренней системы, частью которой является хост. Реализато- Реализаторы TCP могут нарушать ограничение "времени молчания", но они рискуют тем, что некоторые получатели в Интернете старые данные будут прини- принимать как новые, или отвергать новые данные как старые дубликаты. TCP использует пространство номеров последовательности всякий раз, когда сегмент формируется и вводится в очередь сетевого вывода на хосте источника. Обнаружение дубликатов и алгоритм упорядочивания
Стек протоколов TCP/IP 53 в протоколе TCP опирается на уникальное связывание данных сегмента с пространством последовательности, при условии, что номера последо- последовательности не переберут все 2гг значения, прежде чем данные сегмента, связанные с этими номерами последовательности, будут доставлены и подтверждены получателем, и все двойные копии сегментов "исчезнут" из Интернета. Без такого предположения двум различным сегментам TCP могли бы быть присвоены одинаковые или перекрывающиеся номе- номера последовательности, вызывая путаницу у получателя в определении, какие данные являются новыми, а какие старыми. Помните, что каждый сегмент связан с числом порядковых номеров последовательности, равным числу октетов данных в сегменте. При обычных условиях TCP отслеживает следующий номер последова- последовательности для отправки и самый старый, ожидающий подтверждения, что- чтобы избежать ошибочного использования номера последовательности, прежде чем первое использование было подтверждено. Однако это не га- гарантирует, что старые дублирующие данные удаляются из сети. Поэтому пространство последовательности сделано достаточно большим, чтобы со- сократить вероятность возникновения проблем из-за блуждающего дублика- дубликата. При двух Мбит/сек потребуется 4,5 часа для использования 23i октетов пространства последовательности. Так как максимальное время жизни сег- сегмента в сети, скорее всего, не превышает нескольких десятков секунд, это считается достаточной защитой для будущих сетей, даже если скорости пе- передачи данных вырастут до десятков Мбит/сек. При 100 Мбит/сек время цикла равно 5,4 мин, что, возможно, коротковато, но все еще в пределах разумного. Однако базовый механизм обнаружения дубликатов и алгоритм упорядо- упорядочивания в TCP может не сработать, если TCP источника не сохраняет номе- номера последовательности, которые он использовал в последнее время на данном соединении. Например, если бы TCP должен был запускать все сое- соединения с порядкового номера 0, то после аварийного завершения и переза- перезапуска TCP мог бы переформатировать предыдущее соединение (возможно, после разрешения полуоткрытого соединения) и послать пакеты с номерами последовательности, идентичными или перекрывающимися пакетами, все еще находящимися в сети, которые были посланы предыдущей инкарнацией того же соединения. При отсутствии информации о номерах последователь- последовательности, использованных определенным соединением, спецификация TCP ре- рекомендует, чтобы источник делал задержку на MSL секунд, прежде чем посылать в соединение сегменты, чтобы дать время сегментам, остающимся в сети от предыдущей инкарнации соединения, исчезнуть из системы. Даже те хосты, которые могут запоминать время дня и использовать его для выбо- выбора значений начального номера последовательности, не защищены от этой проблемы (т.е. даже если учитывается время дня для выбора начального номера последовательности в каждой новой инкарнации соединения). Полуоткрытые соединения и другие аномалии Созданное соединение называют "полуоткрытым", если один из TCP за- закрыл или прервал соединение на своем конце в одностороннем порядке,
54 Глава 2 или если два конца соединения стали десинхронизированными в связи с аварийным отключением, которое привело к потере памяти. Такие соеди- соединения будут автоматически восстанавливаться при пытке послать данные в любом направлении. Однако полуоткрытые соединения считаются анома- аномальными, и постепенно включается процедура восстановления. Если соеди- соединение узла А больше не существует, то попытка пользователя узла В послать ему какие-либо данные приведет к тому, что TCP узла В получит управляющее сообщение сброса в исходное состояние (reset). Такое сообще- сообщение указывает TCP узла В на ошибку, и ожидается прерывание соединения. Предположим, что два пользовательских процесса А и В общаются друг с другом, когда происходит авария, вызывая потерю памяти TCP процесса А. В зависимости от операционной системы, поддерживающей TCP процесса А, скорее всего, существует некоторый механизм восстановления ошибок. Когда TCP снова включен, А начнет соединение заново или с точки восста- восстановления. В результате А будет пытаться снова открыть (OPEN) соединение или послать (SEND) в соединение, которое он считает открытым. В послед- последнем случае он получает от локального (A) TCP сообщение "соединение не от- открыто". При попытке создать соединение TCP процесса А пошлет сегмент, содержащий SYN. >:.¦¦. ¦. ¦ ¦¦¦ >. ... цс.'Л1. ¦¦¦ ¦ Генерация команды сброса Как общее правило, команда сброса (RST) должна посылаться всякий раз, когда приходит сегмент, который, очевидно, не предназначен для текуще- текущего соединения. Команда сброса не должна посылаться, если неясно, что это именно тот случай. Ниже описаны три существующие группы состояний. 1. Если соединение не существует (CLOSED), то команда сброса (reset) посылается в ответ на любой входящий сегмент, за исключением дру- другой команды сброса. В частности, SYN, адресованный несуществую- несуществующему соединению, отбрасывается этими средствами. Если входящий сегмент имеет поле АСК, то команда сброса берет свой номер после- последовательности из поля сегмента АСК, иначе команда сброса имеет номер последовательности равный нулю, а поле АСК задается как сумма номера последовательности и длины входящего сегмента. Соединение остается в состоянии CLOSED. 2. Если соединение находится в любом не синхронизированном состоя- состоянии (LISTEN, SYN-SENT, SYN-RECEIVED), и входящий сегмент под- подтверждает что-то еще не посланное (сегмент несет неприемлемое АСК), или если входящий сегмент имеет уровень защиты или ячейку, которые не точно соответствуют уровню и ячейке, запрошенным со- соединением, то посылается команда сброса. Если посланный SYN еще не был подтвержден и уровень приоритета входящего сегмента выше, чем запрошенный уровень приоритета, то либо поднимается уровень локального приоритета (если допускается пользователем и системой), либо посылается команда сброса. Если уровень приорите- приоритета входящего сегмента меньше, чем запрошенный уровень приорите- приоритета, то процесс продолжается, как если бы приоритет соответствовал
Стек протоколов TCP/IP 55 точно (если удаленный TCP не может поднять уровень приоритета, чтобы соответствовать точно, это будет обнаружено в следующем сегменте, который он посылает, и соединение будет прекращено). Если посланный сигнал SYN был подтвержден (возможно, в этом вхо- входящем сегменте), то уровень приоритета входящего сегмента должен точно соответствовать уровню локального приоритета. Если это не так, должна быть послана команда сброса. Если входящий сегмент имеет поле АСК, то команда сброса берет номер последовательности из поля сегмента АСК; иначе команда сброса имеет номер последова- последовательности ноль, а поле АСК задается как сумма номера последовате- последовательности и длины входящего сегмента. Соединение остается в том же СОСТОЯНИИ. ¦ ... • ¦ Ч' -I.. 3. Если соединение находится в синхронизированном состоянии (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST АСК, TIME-WAIT), то любой неприемлемый сегмент (номер по- последовательности вне окна или неприемлемый номер подтвержде- подтверждения) должен извлекать только пустой сегмент подтверждения, содержащий текущий посланный номер последовательности и под- подтверждение, указывающее следующий ожидаемый к получению но- номер последовательности, и соединение остается в том же состоянии. Если входящий сегмент имеет уровень защиты, ячейку или приори- приоритет, которые не точно соответствуют уровню, ячейке и приоритету, запрошенным для соединения, посылается команда сброса и соеди- соединение переходит в состояние CLOSED. Команда сброса берет свой номер последовательности из поля АСК входящего сегмента. Обработка команды сброса . Во всех состояниях, кроме SYN-SENT, все сегменты сброса (RST) конт- контролируются проверкой их полей SEQ. Сброс будет признан действитель- действительным, если его номер последовательности находится в пределах окна. В со- состоянии SYN-SENT (RST получен в ответ на начальный SYN) RST является приемлемым, если поле АСК подтверждает SYN. Получатель RST сначала проверяет его, а затем изменяет состояние. Если получатель был в состоянии LISTEN, то он его игнорирует. Если полу- получатель был в состоянии SYN-RECEIVED, а ранее — в состоянии LISTEN, то получатель возвращается в состояние LISTEN; иначе получатель прерыва- прерывает соединение и переходит в состояние CLOSED. Если получатель был в другом состоянии, он прерывает соединение, уведомляет пользователя и переходит в состояние CLOSED. Закрытие соединения (CLOSE) является операцией, означающей: "У меня больше нет данных для пересылки". По- Понятие закрытия дуплексного соединения часто неверно интерпретируется, так как может быть не очевидно, как интерпретировать получающую сто- сторону соединения. Мы выбрали одностороннюю интерпретацию CLOSE. Пользователи, которые делают CLOSE, могут продолжать RECEIVE (полу- (получать), пока они не получат сообщение о том, что другая сторона также
56 Глава 2 CLOSED (закрыта). Таким образом, программа могла бы инициировать не- несколько команд SEND (послать) после команды CLOSE (закрыть), и затем продолжить получать, пока не будет получен сигнал, что команда RECEIVE (получить) не сработала, так как другая сторона закрылась (CLOSED). Мы предполагаем, что TCP будет сигнализировать пользователю, даже если нет никаких ожидающих RECEIVE и другая сторона закрыта, поэтому поль- пользователь сможет аккуратно завершить свою работу. TCP надежно доставит все буферы, посланные до того, как соединение было закрыто, поэтому пользователю, который не ожидает возврата никаких данных, необходимо только подождать сообщения, что соединение успешно закрыто, следовате- следовательно, все его данные были получены TCP местом назначения. Пользователи должны продолжать считывание соединений, которые они закрыли для отправки, пока TCP не сообщит об отсутствии данных. Рассмотрим три существующих сценария: 1. Закрытие инициирует пользователь, приказывая TCP закрыть соединение. 2. Закрытие инициирует удаленный TCP, посылая управляющий сигнал FIN. 3. Оба пользователя закрывают соединение одновременно. Сценарий 1: локальный пользователь инициирует закрытие В этом случае может быть создан сегмент FIN и помещен в очередь исходя- исходящих сегментов. Никакие другие команды SEND пользователя TCP не при- принимает и входит в состояние FIN-WAIT-1. В этом состоянии допускаются команды RECEIVE (получить). Все сегменты, предшествующие и включаю- включающие FIN, будут посылаться повторно, пока не будет подтверждено их полу- получение. Когда другой TCP подтвердит FIN и пошлет свою собственную команду FIN, первый TCP может подтвердить (АСК) этот FIN. Отметим, что TCP, получающий FIN, будет подтверждать (АСК), но не посылать свой собственный FIN, пока его пользователь также не закроет соединение. Сценарий 2: TCP получает FIN из сети Если из сети прибывает не вынужденный FIN, то получающий TCP может подтвердить его и сообщить пользователю, что соединение закрывается. Пользователь ответит командой CLOSE, затем TCP может послать FIN дру- другому TCP после отправки всех оставшихся данных. Затем TCP ожидает, пока его собственный FIN не будет подтвержден, после чего удаляет соеди- соединение. Если подтверждение АСК не поступает после периода ожидания по- пользователя, соединение прерывается и об этом сообщается пользователю.
Стек протоколов TCP/IP 57 Сценарий 3: оба пользователя закрывают соединение одновременно Одновременное закрытие пользователями на обоих концах соединения вы- вызывает обмен сегментами FIN. Когда все сегменты, предшествующие FIN, обработаны и подтверждены, каждый TCP может подтвердить полученный FIN. После получения этих АСК оба удалят соединение. Обмен срочной информацией Цель механизма срочной доставки TCP состоит в том, чтобы посылающий пользователь мог стимулировать получателя принять некоторые срочные данные и разрешить получающему TCP указать получателю, что все известные в данный момент срочные данные получены пользователем. Этот механизм позволяет в потоке данных обозначить точку как конец срочной информации. Всякий раз, когда эта точка у получающего TCP воз- возникает перед номером получаемой последовательности (RCV.NXT), TCP должен приказать пользователю перейти в "режим срочности". Когда но- номер получаемой последовательности сталкивается с указателем срочности, TCP должен приказать пользователю перейти в "нормальный режим". Если указатель срочности обновляется, когда пользователь находится в "режи- "режиме срочности", обновление будет для пользователя невидимым. Метод ис- использует поле срочности, которое переносится во всех передаваемых сегментах. Управляющий флаг URG указывает, что поле срочности имеет смысл и должно быть добавлено к номеру последовательности сегмента, чтобы породить указатель срочности. Отсутствие этого флага указывает, что ожидающих срочных данных нет. Чтобы послать указание о срочности, пользователь должен послать так- также по крайней мере один октет данных. Если посылающий пользователь указывает путь доступа, то своевременность доставки срочной информации в процесс места назначения улучшается. Управление окном Окно, посылаемое в каждом сегменте, указывает диапазон номеров после- последовательности, которые готов принять в данный момент отправитель окна (получатель данных). Существует допущение, что это связано с доступным в этот момент пространством буфера данных для соединения. Указание большого окна ускоряет передачу. Если поступает больше дан- данных, чем может быть принято, они будут отбрасываться. Это приведет к из- излишним повторным передачам, создающим дополнительную нагрузку на сеть и TCP. Указание маленького окна может ограничить передачу данных до появления задержки прохода туда и обратно перед передачей каждого нового сегмента. Предоставленные механизмы позволяют TCP объявлять большое окно, а потом сообщать, что оно значительно меньше, не принимая слишком много данных. Это так называемое "сжатие окна", очень обескураживает. Принцип надежности диктует, что TCP не будет сжимать окно самостояте- самостоятельно, но будет готов к такому поведение со стороны другого TCP.
58 Глава 2 Посылающий TCP должен быть готов принять от пользователя и по- послать по крайней мере один октет новых данных, даже если окно отправки равно нулю. Посылающий TCP должен регулярно повторно посылать кад- кадры получающему TCP, даже когда окно равно нулю. Для интервала повтор- повторной передачи рекомендуется использовать две минуты, когда размер окна равен нулю. Эта повторная передача является существенной для гарантии, что в том случае, когда оба TCP имеют нулевое окно, повторное открытие окна будет обязательно сообщено другому. Если сегмент прибывает, когда получающий TCP имеет нулевое окно, он все равно должен послать подтверждение, показывающее его следующий ожидаемый номер последовательности и текущее окно (ноль). Посылающий TCP упаковывает данные для передачи в сегменты, которые соответствуют текущему окну, и может перепаковывать сегменты в очереди повторной пе- передачи. Такая перепаковка не обязательна, но может оказаться полезной. При соединении с однонаправленным потоком данных информация об окне будет переноситься в сегментах подтверждения, которые все имеют одинаковый номер, поэтому не существует способа переупорядочить их, если они приходят в беспорядке. Это не является серьезной, но позволит ин- информации окна при случае временно основываться на старых отчетах полу- получателя данных. Избежать этой проблемы можно, действуя на основе информации окна из сегментов, которые несут самые большие номера под- подтверждения (т.е. сегменты с номером подтверждения, равным или большим, чем самый большой из полученных ранее). Процедура управления окном имеет существенное влияние на производи- производительность коммуникации. Следующие комментарии являются предложениями для реализации. Предложения по управлению окном Выделение очень маленького окна приводит к тому, что данные будут передаваться во множестве мелких сегментов, в то время как лучшая производительность достигается с помощью меньшего числа больших сегментов. Одним из предложений по избавлению от маленьких окон для получате- получателя является задержка обновления окна, пока дополнительное выделение не составит по крайней мере X процентов максимально возможного выделения для соединения (где X может быть от 20 до 40). Другое предложение для отправителя с целью избежать отправки малень- маленьких сегментов состоит в ожидании, пока окно не станет достаточно большим, прежде чем посылать данные. Если пользователь дает сигнал функции push, то данные должны быть отправлены, даже если это маленький сегмент. Отметим, что подтверждения не должны задерживаться, так как это может привести к ненужным повторным передачам. Одной из стратегий является отправка подтверждения, когда прибывает маленький сегмент (не обновляя информацию об окне), и затем отправка другого подтверждения с новой информацией об окне, когда окно станет больше. Сегмент, посылаемый для проверки нулевого окна, может также начать разбиение передаваемых данных в сегменты все меньшего' размера. Если сегмент, содержащий единст- единственный октет данных, посланный для проверки нулевого окна, принимается, он поглощает один октет доступного в данный момент окна.
Стек протоколов TCP/IP 59 Если посылающий TCP просто посылает столько, сколько может, когда окно ненулевое, то передаваемые данные будут разбиты на чередующиеся большие и маленькие сегменты. Со временем случайные паузы у получате- получателя, делающие доступным распределение окна, приведут к разбиению боль- больших сегментов на более мелкие. Через какое-то время передача данных будет осуществляться в основном маленькими сегментами. Суть вышеизложенного в том, что реализации TCP активно пытаются комбинировать выделение маленьких окон с большими окнами, так как ме- механизмы управления окном ведут к появлению множества маленьких окон в простейших реализациях. Интерфейс пользователь/ТСР Следующее ниже функциональное описание команд TCP является в ка- какой-то степени общим, однако весь TCP должен предоставить некоторый минимальный набор служб для гарантии, что все реализации TCP могут поддерживать одну и ту же иерархию протоколов. Этот раздел определяет функциональные интерфейсы, встречающиеся во всех реализациях TCP. Команды пользователя TCP Следующие разделы объясняют, как работают некоторые из наиболее об- общих команд TCP, и дают значительно лучшее понимание ситуации при по- - иске неисправностей. Описанные ниже пользовательские команды определяют базовые функции, которые будет выполнять TCP для поддер- I жки коммуникации между процессами. Хотя эти команды не обязательно [ будут видны, мы найдем признаки их работы в рассматриваемых приме- | pax трассировки. Различные реализации могут изменять точный формат | или предоставлять комбинации или подмножества базовых функций в [ одиночных вызовах. В частности, некоторые реализации могут захотеть ;' открывать соединение автоматически при получении команды пользова- ', теля SEND (послать) или RECEIVE (получить) для данного соединения. [ При предоставлении средств коммуникации между процессами TCP дол- должен не только принимать команды, но также и возвращать информацию процессам, которые он обслуживает. Она представляет собой общую ин- информацию о соединении (т.е. прерывания, удаленное закрытие, связыва- связывание неопределенного внешнего сокета). Ответы на специальные команды пользователя указывают успех или различные виды отказов. Мы предполагаем, что локальный TCP знает идентичность процессов, которые он обслуживает, и будет проверять полномочия процесса на ис- использование указанного соединения. В зависимости от реализации TCP идентификаторы локальной сети и TCP для адреса источника будут по- поставляться либо TCP, либо протоколом нижнего уровня (например, IP). Эти свойства являются результатом рассмотрения вопросов безопасно- безопасности, чтобы один TCP не смог маскировать другой, и т.д. Аналогичным об- образом, ни один процесс не может маскировать другой без возникновения конфликта TCP.
60 Глава 2 Если флаг "активный/пассивный" (Active/Passive) задан как пассивный, то он представляет собой вызов LISTEN для входящего соединения. Пассив- Пассивное открытие может иметь либо полностью специфицированный внешний сокет, ожидающий определенное соединение, либо не специфицированный внешний сокет, ожидающий любой вызов. Полностью специфицированный пассивный вызов можно сделать активным последующим выполнением команды SEND. Блок управления передачей (ТСВ) создается и частично за- заполняется данными из параметров команды OPEN. На активной команде OPEN TCP сразу начнет процедуру синхронизации (т.е. создания) соединения. Параметр задержки (если присутствует) позволяет вызывающей сторо- стороне установить задержку для всех данных, переданных TCP. Если данные не будут доставлены в место назначения в течение времени задержки, TCP прервет соединение. По умолчанию в настоящее время используется пять МИНуТ. .¦;.;¦.¦<>¦ TCP или некоторый компонент операционной системы будет проверять полномочия пользователя на открытие соединения с указанным приорите- приоритетом или защитой/ячейкой. Отсутствие приоритета или спецификации за- защиты/ячейки в вызове OPEN указывает, что должны использоваться значения по умолчанию. TCP будет принимать входящие запросы как подходящие только в том Случае, если информация защиты/ячейки в точности совпадает и если приоритет равен или выше приоритета, запрошенного в вызове OPEN. Приоритет соединения равен большему из значений, запрошенному в вызове OPEN и полученному из входящего запроса, и фиксируется на этом значении в течение жизни соединения. Реализации могут захотеть предо- предоставить пользователю управление этим согласованием приоритета. Напри- Например, пользователь может определять, что приоритет должен точно совпадать, или что любая попытка увеличить приоритет подтверждается пользователем. TCP будет возвращать пользователю имя локального соединения. Имя локального соединения может затем использоваться в качестве сокращен- сокращенного термина для соединения, определенного парой <локальный сокет, внешний сокетх Send (Послать) Этот вызов заставляет послать данные, содержащиеся в указанном пользова- пользователем буфере, в указанное соединение. Если соединение еще не было откры- открыто, то SEND рассматривается как ошибка. Некоторые реализации могут позволять пользователю сделать вызов SEND и в такой ситуации. В этом слу- случае будет автоматически выполняться команда OPEN. Если вызывающий процесс не уполномочен использовать это соединение, то возвращается ошибка. Если задан флаг PUSH, данные должны сразу передаваться получателю, и бит PUSH будет установлен в последнем сегменте, созданном из буфера. Если флаг PUSH не установлен, данные могут комбинироваться с данными из последующих команд SEND для эффективности передачи.
Стек протоколов TCP/IP 61 Если установлен флаг URGENT, то в сегментах, посланных TCP назна- назначения, будет задан указатель срочности. Получающий TCP будет сигнализи- сигнализировать об условии срочности получающему процессу, если указатель срочности показывает, что данные, предшествующие указателю срочно- срочности, не были получены получающим процессом. Назначение срочности со- состоит в стимуляции получателя к обработке срочных данных и для указания получателю, когда все известные в данный момент срочные дан- данные будут получены. Число раз, которое TCP посылающего пользователя сигнализирует о срочности, не обязательно будет равно числу уведомлений получающего пользователя о присутствии срочных данных. Если в OPEN не был определен никакой внешний сокет, но соединение установлено (например, потому что прослушиваемое соединение стало определенным в связи с получением внешнего сегмента на локальном соке- те), то обозначенный буфер посылается на подразумеваемый внешний со- сокет. Пользователи, которые применяют SEND с не указанным внешним сокетом, могут делать это, даже не зная точно адрес внешнего сокета. Однако если SEND выполняется до того, как был определен внешний со- сокет, то будет возвращаться ошибка. Пользователи могут применять вызов STATUS для определения статуса соединения. В некоторых реализациях TCP может уведомлять пользователя, когда связывается неопределенный сокет. Если определяется задержка, то задержка текущего пользователя этого соединения изменяется на новое значение. В простейшей реализации SEND не будет возвращать управление посылающему процессу, пока либо передача не будет завершена, либо не истечет время задержки. Однако этот простой метод может приводить к блокированию (например, обе сто- стороны соединения могут пытаться выполнить SEND, не выполнив ни одной команды RECEIVE) и реализует плохую производительность, поэтому он не рекомендуется. Более сложная и современная реализация будет немедлен- немедленно возвращать управление, чтобы следующий процесс выполнялся одно- одновременно с сетевым вводом-выводом, и, более того, чтобы реализовать несколько выполняющихся SEND. Несколько SEND обслуживаются в по- порядке простой очереди, поэтому TCP будет создавать очередь из тех, кого он не может обслужить немедленно. Здесь неявно предполагается асинхронный интерфейс пользователя, где SEND в дальнейшем вызывает появление некоторого вида SIGNAL (сиг- (сигнала) или псевдопрерывания от обслуживающего TCP. Альтернативой яв- является немедленный возврат ответа. Например, SEND мог бы немедленно вернуть локальное подтверждение, даже если посланный сегмент не был подтвержден удаленным TCP. Можно было бы оптимистично предполагать конечный успех. Если мы ошиблись, то соединение будет закрыто в любом случае в связи с истечением времени ожидания. В реализациях такого рода (синхронных) все равно будут некоторые асинхронные сигналы, но они бу- будут иметь дело с самим соединением, а не со специфическими сегментами или буферами. ,
62 Глава 2 Чтобы процесс различал индикаторы успеха/неудачи для различных SEND, может оказаться удобным возвращать адрес буфера вместе с кодиро- кодированным ответом на запрос SEND. Сигналы TCP пользователю обсуждаются ниже с указанием информации, которая должна быть возвращена вызываю- вызывающему процессу. Receive (Получить) Эта команда выделяет буфер получения, связанный с указанным соедине- соединением. Если этой команде не предшествует команда OPEN, или вызываю- вызывающий процесс не уполномочен использовать это соединение, возвращается ошибка. В простейшей реализации управление не будет возвращаться вызываю- вызывающей программе, пока не заполнится буфер или не произойдет какая-нибудь ошибка, но эта схема существенно подвержена блокированию. Более разви- развитая реализация будет позволять нескольким командам RECEIVE ожидать выполнения одновременно. Они будут выполняться по мере поступления сегментов. Эта стратегия позволяет увеличить пропускную способность за счет более развитой схемы (возможно, асинхронной) уведомления вызыва- вызывающей программы, что был получен PUSH или заполнен буфер. Если при- прибывает количество данных, достаточное для заполнения буфера до появления PUSH, флаг PUSH в ответ на RECEIVE задаваться не будет. Бу- Буфер будет заполнен таким количеством данных, сколько он может вмес- вместить. Если до заполнения буфера появляется PUSH, буфер возвращается частично заполненным и с указанием PUSH. При наличии срочных данных пользователь будет проинформирован об этом, как только они появятся, с помощью сигнала TCP пользователю. Полу- Получающий пользователь должен поэтому находиться в "срочном режиме". Если установлен флаг URGENT, остаются дополнительные срочные данные. Если флаг URGENT сброшен, то этот вызов RECEIVE вернул все срочные данные, и пользователь может теперь покинуть "срочный режим". Отметим, что дан- данные, следующие за указателем срочности (несрочные данные), нельзя доста- доставить пользователю в тот же буфер с предшествующими срочными данными, если только граница для пользователя четко не обозначена. Чтобы различить несколько ожидающих RECEIVE и компенсировать бу- буфер, который не полностью заполнен, код возврата сопровождается указате- указателем буфера и счетчиком байтов, указывающим реальную длину полученных данных. Альтернативные реализации RECEIVE могут иметь TCP, который выделя- выделяет буферную память, или TCP может совместно с пользователем использовать кольцевой буфер. Close (Закрыть) Эта команда вызывает закрытие указанного соединения. Если соединение не открыто, или же вызывающий процесс не уполномочен использовать это соединение, возвращается ошибка. Закрытие соединения предназначе- предназначено для элегантной работы в том смысле, что ожидающие SEND будут пере- переданы (и переданы повторно), когда позволит управление потоком, пока все
Стек протоколов TCP/IP 63 не будет обслужено. Таким образом, допустимо выполнить несколько вызо- вызовов SEND, за которыми следует CLOSE, и ожидать, что все данные будут по- посланы в место назначения. Также должно быть ясно, что пользователи могли бы продолжать RECEIVE (получать) на закрытых соединениях, так как другая сторона могла бы пытаться передавать свои завершающие дан- данные. Фактически CLOSE означает: "У меня для передачи больше ничего нет", а не "Я больше ничего не буду принимать". Может случиться (если протокол на уровне пользователя не очень хорошо проработан), что сто- сторона не сможет избавиться от всех своих данных до того, как закончится вы- выделенное время. В этом случае CLOSE превратится в ABORT, и закрываю- закрывающий TCP прервется. Пользователь может закрыть соединение в любое время по своей собственной инициативе или в ответ на различные пред- предложения от TCP (например, выполнено удаленное закрытие, превышена задержка передачи, место назначения недоступно). Так как закрытие соединения требует коммуникации с внешним TCP, соединение может оставаться в закрытом состоянии в течение некоторого времени. Попытки повторно открыть соединение, прежде чем TCP отве- ответит на команду CLOSE, будет приводить к сообщению об ошибке. CLOSE также подразумевает вызов функции push (выталкивания данных). Status Abort (Прервать) Эта команда вызывает прерывание всех ожидающих SEND и RECEIVE, уда- удаление ТСВ и отправку специального сообщения RESET для TCP на другой стороне соединения. В зависимости от реализации пользователи могут по- получать указания о прерывании для каждой ожидающей команды SEND или RECEIVE или просто получить подтверждение команды ABORT. TCP/Низкоуровневый интерфейс TCP вызывает модуль низкоуровневого протокола для реальной отправки и получения информации через сеть. Одним из случаев является система взаимодействия сетей ARPA, где низкоуровневым протоколом будет IP. Если низкоуровневым протоколом является IP, он предоставляет аргумен- аргументы для типа службы и для времени жизни. TCP использует следующие на- настройки для этих параметров: Type of service = precedence: routine; Delay: normal; Throughput: normal; Reliability: normal; или 00000000. Время жизни = одна минута, или 00111100. Отметим, что предполагаемое максимальное время жизни сегмента равно двум минутам. Здесь мы явно указываем, что сегмент будет уничтожен, если его окажется невозможно доставить по Ин- Интернету в течение одной минуты. Если нижним уровнем является IP (или другой протокол, который предоставляет это свойство) и используется маршрутизация источника, интерфейс должен разрешать передавать ин- информацию о маршруте. Особенно важно, чтобы адреса источника и места назначения, используемые в контрольной сумме TCP, принадлежали исход- исходному источнику и конечному месту назначения. Также важно сохранить маршрут возврата для ответа на запросы соединения.
64 Глава 2 Любой низкоуровневый протокол должен предоставлять адрес источни- источника, адрес места назначения, поля протокола и некоторый способ определе- определения "длины TCP" одновременно для предоставления функционально эквивалентной службы IP и для использования в контрольной сумме TCP. Обработка, показанная в этом разделе, является примером одной возмож- возможной реализации. Другие реализации могут иметь иную последовательность обработки, но они должны отличаться от приведенной в данном разделе только в деталях, а не по существу. Активность TCP можно охарактеризо- охарактеризовать как реакцию на события. Происходящие события можно разделить на три категории: пользовательские вызовы, прибывающие сегменты и исте- истечение времени ожидания. Этот раздел описывает обработку, которую вы- выполняет TCP в ответ на каждое из этих событий. Во многих случаях требуемая обработка зависит от состояния соединения. Происходящие события: пользовательские вызовы Модель TCP/интерфейс пользователя является моделью, где команды по- пользователя получают немедленный ответ и, возможно, ответ с задержкой с помощью события или псевдопрерывания. В следующих описаниях термин "сигнал" означает "причина задержанного ответа". Ответы об ошибках пре- предоставляются как строки символов. Например, пользовательские команды, обращающиеся к соединениям, которые не существуют, получают в ответ сообщение "Ошибка: соединение не открыто" ("error: connection not open"). Отметим, что в последующем все арифметические операции с номерами последовательности, номерами подтверждений, окнами и т.д. выполняются по модулю 2s2', так как это размер пространства номеров последовательно- последовательности. Отметим также, что "=<" означает "меньше или равно (по модулю 232)". Обработка входящих сегментов состоит в том, что они сначала проверяются на правильный номер последовательности (т.е. содержатся в диапазоне ожи- ожидаемого "окна получения" в пространстве номеров последовательности), а затем обычно выстраиваются в очередь и обрабатываются в порядке номе- номеров последовательности. Когда сегмент перекрывает другие уже полученные сегменты, он реконструируется, чтобы содержать только новые данные, и соответствующим образом изменяются поля заголовка. Обратите внимание, что если не упомянуто никакое изменение, TCP остается в том же состоянии (т.е. ТСВ не существует). Создайте новый блок управления передачей (ТСВ) для хранения информации о состоянии соединения. Запишите информа- информацию об идентификаторе локального сокета, внешнем сокете, приоритете, безопасности/ячейке и времени ожидания пользователя. Некоторые час- части внешнего сокета могут быть не определены при пассивном OPEN и дол- должны заполняться параметрами входящего сегмента SYN. Проверьте, что запрошенные безопасность и приоритет допустимы для этого пользовате- пользователя; если нет, верните "ошибка: приоритет недопустим" или "ошибка: защи- защита/ячейка недопустимы". Если соединение активно, введите состояние LISTEN и вернитесь. Если в активном состоянии и определен внешний сокет, пошлите сегмент SYN. Выбирается начальный номер посылаемой последова- последовательности (ISS). Сегмент SYN посылается в форме <SEQ=ISSxCTL=SYN>. За- Задайте SND.UNA как ISS, SND.NXT как ISS+1, введите состояние SYN-SENT и
Стек протоколов TCP/IP 65 вернитесь. Если вызывающая сторона не имеет доступа к указанному лока- локальному сокету, возвращается "ошибка: соединение недопустимо для этого процесса". Если нет места для создания нового соединения, возвращается "ошибка: недостаточно ресурсов". Состояние прослушивания Если текущее состояние соединения ACTIV и определен внешний сокет, то измените состояние на активное и выберите ISS. Пошлите сегмент SYN, за- задайте SND.UNA как ISS, SND.NXT как ISS+1-Введите состояние SYN-SENT. Данные, связанные с SEND, могут быть посланы с сегментом SYN или вы- выстроены в очередь для передачи после ввода состояния ESTABLISHED. Бит срочности (если запрошен в команде) должен посылаться с сегментами данных, посланными в результате этой команды. Если для занесения запро- запроса в очередь нет места, возвращается сообщение "ошибка: недостаточно ре- ресурсов". Если внешний сокет не определен, возвращается сообщение "ошибка: внешний сокет не определен". Вызов SEND (Послать) • CLOSED STATE (закрытое состояние, т.е. ТСВ не существует). Если пользователь не имеет доступа к такому соединению, возвращается сообщение "ошибка: соединение незаконно для этого процесса". Иначе возвращается сообщение "ошибка: соединение не существует". • LISTEN STATE (состояние прослушивания). Если определен внешний сокет, измените соединение из пассивного в активное и выберите ISS. Пошлите сегмент SYN и задайте SND.UNA как ISS, SND.NXT как ISS+1. Введите состояние SYN-SENT. Данные, связанные с SEND, могут посы- посылаться с сегментом SYN или ставиться в очередь для передачи после ввода состояния ESTABLISHED. Бит срочности (если запрошен в команде) должен посылаться с сегментами данных, посланными в резу- результате этой команды. Если для постановки этого запроса в очередь нет места, то возвращается сообщение "ошибка: недостаточно ресурсов". Если внешний сокет не был определен, то возвращается сообщение "ошибка: внешний сокет не определен". • SYN-SENT STATE SYN-RECETVED STATE. Создать очередь данных для пе- передачи после ввода состояния ESTABLISHMENT. Если для очереди нет пространства, возвращается сообщение "ошибка: недостаточно ресурсов". • ESTABLISHED STATE CLOSE-WAIT STATE. Сегментировать буфер и послать его с комбинированным подтверждением (значение подтвер- подтверждения = RCV.NXT). Если пространства для запоминания этого буфе- буфера недостаточно, возвращается сообщение "ошибка: недостаточно ресурсов". Если задан флаг срочности, то SND.UP <- SND.NXT-1 и в ис- исходящих сегментах задается указатель срочности. Вызовите CLOSED STATE (т.е. ТСВ не существует). Если пользователь не имеет доступа к такому соединению, возвращается сообщение "ошибка: соединение недопустимо для этого процесса". Иначе возвращается сообщение "ошибка: соединение не существует".
66 ¦" '"" Глава 2 . LISTEN STATE SYN-SENT STATE SYN-RECEIVED STATE. Создайте очередь для обработки после ввода состояния ESTABLISHED. Если для занесения этого запроса в очередь нет пространства, возвращается сообщение "ошибка: недостаточно ресурсов". ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE. Если в очереди для удовлетворения запроса недостаточное количество вхо- входящих сегментов, то запрос ставится в очередь. Если пространства очереди не хватает, чтобы запомнить RECEIVE, возвращается сооб- сообщение "ошибка: недостаточно ресурсов". Переберите входящие сег- сегменты в очереди в буфере получения и верните пользователю. Сделайте отметку "присутствует push" (PUSH), если имеется соответ- соответствующий флаг. Если RCV.UP предшествует данным, передаваемым в этот момент пользователю, уведомите его о присутствии срочных данных. Когда TCP берет на себя ответственность по доставке данных пользователю, этот факт должен быть сообщен отправителю с помо- помощью подтверждения. Формирование такого подтверждения описано ниже при обсуждении обработки входящих сегментов. Вызов RECEIVE: CLOSE-WAIT STATE. Так как удаленная сторона уже послала FIN, команды RECEIVE должны быть удовлетворены уже по- полученным текстом, но еще не доставленным пользователю. Если ника- никакой текст не ожидает доставки, то RECEIVE получит сообщение "ошибка: соединение закрыто". Иначе весь оставшийся текст может использоваться для удовлетворения RECEIVE. CLOSING STATE LAST-ACK STATE TIME-WAIT STATE. Возвращает "ошибка: соединение закрыто". Вызовите CLOSED STATE (т.е. ТСВ не существует). Если пользователь не должен иметь доступ к такому сое- соединению, возвращается сообщение "ошибка: соединение недопусти- недопустимо для этого процесса". Иначе возвращается сообщение "ошибка: соединение не существует". LISTEN STATE. Все ожидающие команды RECEIVE должны быть воз- возвращены с сообщением "ошибка: сброс соединения". Удалите ТСВ, введите состояние CLOSED и вернитесь. SYB-SENT STATE. Всем ожидающим в очереди командам SEND и RECEIVE должно быть выдано уведомление "сброс соединения", затем удалите ТСВ, введите состояние CLOSED и вернитесь. SYN-RECEIVED STATE ESTABLISHED STATE FIN WAIT-1 STATE FINWAIT-2 STATE CLOSE-WAIT STATE. Пошлите сегмент сброса: <SEQSND.NXTxCTL=RST>. Всем ожидающим в очереди командам SEND и RECEIVE должно быть выдано уведомление "сброс соедине- соединения"; все сегменты, ожидающие в очереди передачи (за исключением формы RST) или повторной передачи, должны быть сброшены, удалите ТСВ, введите состояние CLOSED и вернитесь. CLOSING STATE LAST-ACK STATE TIME-WAIT STATE. Верните сооб- сообщение "ok" и удалите ТСВ, введите состояние CLOSED и вернитесь.
Стек протоколов TCP/IP 67 Протокол IP Протокол IP создан для использования в связанных системах компьютер- компьютерных коммуникационных сетей с коммутацией пакетов. Протокол IP обраба- обрабатывает передаваемые от источника к месту назначения блоки данных, называемые дейтаграммами, где источниками и местами назначения явля- являются хосты, идентифицированные адресами фиксированной длины. Про- Протокол IP предусматривает также фрагментацию и повторную сборку длинных дейтаграмм. Функции IP ограничены доставкой пакетов битов (дейтаграмм Интерне- Интернета) от источника к месту назначения через связанную систему сетей. В нем не существует механизмов для обеспечения надежности двухточечной пере- передачи данных, управления потоком, упорядочивания или других служб, при- присутствующих обычно в протоколах взаимодействия хостов. Протокол IP может использовать службы поддерживающих его сетей для предоставления служб различных типов и качества. Этот протокол вызывается протоколами взаимодействия хостов в среде Интернета. Он вызывает протоколы локальных сетей для переноса дейтаг- дейтаграмм Интернета к следующему шлюзу или хосту места назначения. Напри- Например, модуль TCP будет вызывать модуль IP, чтобы получить сегмент TCP (включая заголовок TCP и данные пользователя) как часть с данными дей- дейтаграммы IP. Модуль TCP будет предоставлять адреса и другие параметры в заголовке IP модулю IP как аргументы вызова. Модуль IP будет затем созда- создавать дейтаграмму IP и вызывать интерфейс локальной сети для передачи дейтаграммы. Протокол IP реализует две базовые функции: адресацию и фрагмента- фрагментацию. Модули IP используют адреса, передаваемые в заголовке IP, для пере- передачи дейтаграмм IP в направлении их места назначения. Выбор пути доступа для передачи называется маршрутизацией. Модули IP используют поля заголовка IP в случае необходимости для фрагментации и повторной сборки дейтаграмм IP. Модель работы состоит в том, что модуль IP располагается на каждом хосте, вовлеченном в коммуникацию Интернета, и на каждом шлюзе, кото- который соединяет сети. Эти модули используют общие правила для интерпре- интерпретации полей адреса и для фрагментации и сборки дейтаграмм IP. Кроме того, эти модули (особенно на шлюзах) имеют процедуры для принятия решений о маршрутизации и другие функции. Протокол IP интерпретирует каждую дейтаграмму IP как независимую сущность, не связанную с другой дейтаграммой IP. He существует никаких соединений или логических связей (виртуальных или каких-либо других). Протокол IP использует четыре ключевых механизма при предоставле- предоставлении своих служб: тип службы, время жизни, параметры и контрольная сумма заголовка. Тип службы используется для указания качества желательной службы. Тип службы является абстрактным или обобщенным множеством параметров, характеризующих варианты служб, предоставляемых в сетях, из которых состоит Интернет. Это указание типа службы должно использовать- использоваться шлюзами для выбора параметров реальной передачи для определенной
68 Глава 2 сети, которая будет применяться для следующего перехода или для следую- следующего шлюза при маршрутизации дейтаграммы IP. Время жизни является указанием верхней границы времени жизни дейтаграммы IP. Оно задается отправителем дейтаграммы и уменьшается в точках вдоль маршрута, где оно обрабатывается. Если время жизни достигает нуля до того, как дей- дейтаграмма Интернета достигает своего места назначения, дейтаграмма IP раз- разрушается. Время жизни можно считать пределом времени саморазрушения. Параметры, предоставляемые для управляющих функций, необходимы или полезны в некоторых ситуациях, но для большинства обычных коммуни- коммуникаций не нужны. Параметры включают обеспечение отметок времени, безо- безопасности и специальной маршрутизации. Контрольная сумма заголовка предоставляет проверку того, что информация, используемая при обработке дейтаграмм IP, была передана правильно. Данные могут содержать ошибки. Если контрольная сумма заголовка неправильная, дейтаграмма IP тотчас от- отбрасывается сущностью, которая обнаружила ошибку. Протокол IP не предо- предоставляет надежного средства коммуникации. Не существует подтверждений между конечными точками или точками перехода. Отсутствует контроль ошибок данных, только контрольная сумма заголовка. Не существует по- повтора передачи и управления потоком. Обнаруженные ошибки могут сообщаться через протокол ICMP, который реализован в модуле протокола IP. Протокол IP, с одной стороны, общается с протоколами коммуникации хостов более высокого уровня, а с другой стороны, с протоколом локальной сети. Это проиллюстрировано на рис. 2.4. NeUrak Montn ¦ (F:\bookcopi\38 loon cap (S Frame 5 :6 ,7 : TiBe 7.559 560 560 .560 7 561 Src MAC Add TERESA Ш TERESA КЕШ? Dst MAC Aid: «BROADCAST •BROADCAST TERESA KENHV PROX Frotocc Description NETLOCC 1И1 0/2 0 LOGON Request ?ro« client ARP RAKARP Request. Tarset IP 10 0.0 76 ARPlRASARP Reply Target IP 10 0 0 11 Target Hdwx Addr 008Г KETLOGC LH2 0 Response to LOGON Request b'BT US Registration re; for KCSOCE <0 3- J ¦FRAME. Base frame properties ¦ETHERNET ETYPE - 0xG8Q0 Protocol ¦ГР ID • 0x2A00, Proto • UDP: Len ¦ IP DOD Internet Protocol HBT HS Ou^rw 00000020 00 0A 00 99 00 89 00 ЗА А0 0О00ООЭ0 00000040 00000050 00 18 01 00 00 01 JO 00 00 00 00 00 21) 46 45 45 46 46 43 45 46 46 44 45 42 43 41 43 41 43 41 43 41 43 41 43 41 43 41 !'< 41 1! 41 41 41 00 0A ?0 00 01 ¦ . FEEFFCEFF DEBCACACtCACACAi' Рис. 2.4. Протокол IP общается с протоколом TCP более высокого уровня, а также с сетевыми протоколами более низкого уровня
Стек протоколов TCP/IP 69 Модель работы при передаче дейтаграмм из одной прикладной про- программы в другую иллюстрирует следующий сценарий. Предположим, что эта передача будет включать один промежуточный шлюз. Передающая прикладная программа готовит свои данные, вызывает свой локальный модуль IP для отправки этих данных в виде дейтаграммы и передает адрес места назначения и другие параметры в качестве аргументов вызова. Мо- Модуль IP готовит заголовок дейтаграммы и присоединяет к нему данные. Модуль определяет адрес локальной сети для этого адреса IP; в данном случае это адрес шлюза. Он посылает эту дейтаграмму и адрес локальной сети в локальный сетевой интерфейс. Локальный сетевой интерфейс со- создает локальный сетевой заголовок и присоединяет к нему дейтаграмму, а затем посылает результат через локальную сеть. Дейтаграмма прибывает на хост шлюза в оболочке заголовка локальной сети, интерфейс локаль- локальной сети удаляет этот заголовок и передает дейтаграмму модулю IP. Мо- Модуль определяет из адреса IP, что дейтаграмма должна быть передана на другой хост во второй сети. Модуль определяет адрес локальной сети для хоста назначения. Он обращается к интерфейсу локальной сети, чтобы послать ей дейтаграмму. Интерфейс локальной сети создает заголовок ло- локальной сети и присоединяет дейтаграмму, посылая результат хосту на- назначения. На хосте назначения дейтаграмма освобождается от заголовка локальной сети интерфейсом локальной сети и передается модулю IP. Модуль IP определяет, что дейтаграмма предназначена для прикладной программы на этом хосте. Он передает данные прикладной программе в от- ответ на системный вызов, передавая адрес источника и другие параметры, как результат вызова. Функция или назначение протокола IP состоит в переносе дейтаграмм в пределах объединенной сети, или сетевого комплекса. Это реализуется пу- путем передачи дейтаграмм из одного модуля IP в другой, пока не будет до- достигнуто место назначения. Модули IP располагаются на хостах и шлюзах в системе Интернет. Дейтаграммы маршрутизируются из одного модуля IP в другой через отдельные сети на основе интерпретации адреса IP. Таким образом, одним из важных механизмов протокола IP является IP-адрес. При маршрутизации сообщений из одного модуля IP в другой дейтаг- дейтаграммам может понадобиться пересекать сеть, максимальный размер пакета в которой меньше размера дейтаграммы. Чтобы преодолеть эту трудность, в протоколе IP предоставлен механизм фрагментации. Существует различие между именами, адресами и маршрутами. Имя указывает, что мы ищем. Адрес указывает, где это находится. Маршрут указывает, как туда попасть. Протокол IP имеет дело прежде всего с адре- адресами. Задача протоколов высокого уровня (т.е. протокола хост-хост или приложения) — выполнить отображение из имен в адреса. Модуль IP ото- отображает IP-адреса в адреса локальной сети. Задача низкоуровневых проце- процедур (т.е. локальной сети или шлюзов) — выполнить отображение из адресов локальной сети или маршрутов. Адреса имеют фиксированную длину из четырех октетов C2 бита). Ад- Адрес начинается с номера сети, за которым следует локальный адрес (на- (называемый "собственным" полем). Есть три формата классов адресов IP:
70 Глава 2 в классе (а) старший бит равен нулю, следующие семь битов определяют сеть, а последние 24 бита являются локальным адресом; в классе (Ь) стар- старшими двумя битами будут один-ноль, следующие 14 битов определяют сеть, а последние 16 битов являются локальным адресом; в классе (с) старшими тремя битами будут один-один-ноль, следующие 21 бита определяют сеть, а последние восемь битов являются локальным адресом. При отображении адресов IP в адреса локальной сети должна быть прояв- проявлена осторожность; в ряде случаев единственный физический хост должен действовать как несколько различных хостов за счет использования несколь- нескольких различных адресов IP. Некоторые хосты будут также иметь несколько фи- физических интерфейсов (мультихост). Должно быть предусмотрено существование хоста с несколькими физическими сетевыми интерфейсами, каждый из которых может иметь несколько логических адресов IP. Фрагментация дейтаграммы IP необходима, когда она создается в лока- локальной сети, которая допускает большой размер пакета, и, чтобы достичь места назначения, должна пересекать локальную сеть, ограничивающую пакеты до меньшего размера. Дейтаграмма IP может быть помечена как "не фрагментировать". Любая помеченная таким образом дейтаграмма IP не будет фрагментироваться ни при каких обстоятельствах. Если дейтаграмма IP, помеченная "не фрагмен- фрагментировать", не может быть доставлена к своему месту назначения без фраг- фрагментации, она будет отбрасываться. Фрагментация, передача и сборка в локальной сети, которые не видны для модуля протокола IP, называются фрагментацией интрасети. Фрагментация IP и процедура сборки должны иметь возможность раз- разбить дейтаграмму на произвольное число фрагментов, которые можно в да- дальнейшем собрать снова. Получатель фрагментов использует поле идентификации для обеспечения того, что фрагменты различных дейтаг- дейтаграмм не смешиваются. Поле сдвига фрагмента и длина определяют часть исходной дейтаграммы, содержащейся в этом фрагменте. Флаг "дополните- "дополнительные фрагменты" указывает (будучи сброшенным) последний фрагмент. Эти поля предоставляют достаточно информации для сборки дейтаграмм. Поле идентификации используется для различения фрагментов одной дейтаграммы от фрагментов другой. Модуль исходного протокола дейтаг- дейтаграммы IP задает в поле идентификации значение, которое должно быть уникальным для этой пары источник-место назначения и протокола, пока дейтаграмма будет активной в системе Интернет. Модуль исходного прото- протокола всей дейтаграммы задает флаг "дополнительные фрагменты" равным нулю и сдвиг фрагмента как ноль. Чтобы фрагментировать длинную дейтаграмму IP, модуль протокола IP (например, в шлюзе) создает две новые дейтаграммы IP и копирует содер- содержимое полей заголовка IP из длинной дейтаграммы в оба новых заголовка IP. Данные длинной дейтаграммы делятся на две части по границе восьми октетов F4 бита) (вторая часть, в отличие от первой, может не быть це- целым, кратным восьми октетам). Вызовите число восьмиоктетных блоков в первой части NFB (для числа блоков фрагментов). Первая часть данных размещается в первой новой дейтаграмме IP, и поле общей длины задается
Стек протоколов TCP/IP 71 равным длине первой дейтаграммы. Флаг "дополнительные фрагменты" за- задается равным единице. Вторая часть данных помещается во второй новой дейтаграмме IP, и поле общей длины задается равным длине второй дейтаг- дейтаграммы. Флаг "дополнительные фрагменты" имеет то же самое значение, что и длинная дейтаграмма. Поле сдвига фрагмента второй новой дейтаг- дейтаграммы IP задается равным значению этого поля в длинной дейтаграмме плюс NFB. Эта процедура может быть обобщена для разбиения на п частей. Чтобы собрать фрагменты дейтаграммы IP, модуль протокола IP (например, на хо- хосте назначения) объединяет дейтаграммы IP, которые имеют одно и то же значение для четырех полей: идентификации, источника, места назначе- назначения и протокола. Сборка осуществляется помещением порции данных каж- каждого фрагмента в относительную позицию, указанную сдвигом фрагмента в заголовке IP этого фрагмента. Сдвиг фрагмента равен нулю, а флаг "допол- "дополнительные фрагменты" последнего фрагмента будет сброшен в ноль. Заголовок IP На рис. 2.5 показан пример заголовка IP, как он определен в сети Windows NT. Первое поле в заголовке IP предназначено для версии, которая имеет в длину четыре бита. Поле версии указывает формат заголовка IP и поэтому сообщает другим машинам, как интерпретировать данные. Здесь показана версия 4. Следующим полем является поле длины заголовка IP. Для этой информации выделены четыре бита. Это число является длиной заголовка Nctwoik МопИи - |G:\0717-O92CEDT cap IDelalll О» ?<* ¦FRAME Base (rame properties ~jj ¦ETHERNET ETYPE - 0x0800 . Protocol " IP: DOD Internet Protocol "P -IP. ID - 0xEE8. Proto - TCP. Len 40 '? IP Version • 4 @x4) • < ¦ Л IP Header Length • 20 @x14) .** «IP Service Type • 0 @x0) «^ IP. Precedence ¦ Routine .. ' ¦ A." IP: .. 0 • Normal Delay "y IP 0. . . ¦ Normal Throughput - '*> IP: 0 - Normal Reliability *•• IP Total Length ¦ 40 @«28) r, - 3816 <0xEE8> "IP Flags Summary • 2 @x2; IP 0 " Last fragment in datagram IP Is Cannot fragment datagram IP Fragment Offset • 0 @x0) bytes IP Time to Live ¦ 128 @x80) IP Protocol • TCP - Transmission Control IP Checksum • OxDtS? IP Source Address • 11 0.0 205 IP Destination Address -11.0 0.201 IP Data Number of data bytes remaining " 20 @x0014) ¦TCP A . len 0. seq 910?643-5107643. ack: 1312110836. »m 7376. src. 1062 dst: 1S« r\ oooooooo oo ed'sF «У за зг'оо'бо s? ii ев бс'ов"оо~1ГоТ ^ТГг'Г'еГу-ТТТГ" 00000010 00 28 D14ip<A 00 80 06 D4 52 0B 00 00 CD 0B 00 (И* С +R - 00000020 00 C9 04 26 06 1A 00 Si F8 BB 4E 35 39 30 SO 10 + 4.. e'*N590P 00000030 1С 00 F0 83 00 00 --a. 'ItfenacatoncrteMedlahagmOememblyi FO 1«й/ИO ОН 18(»12) и2(«2| Рис. 2.5. Структура заголовка IP
72 Глава 2 IP в 32-битных словах и поэтому указывает на начало данных. Отметим, что минимальное значение для правильного заголовка равно пяти, что состав- составляет 20 байтов. В шестнадцатеричной панели внизу рис. 2.5 выделенная об- область является заголовком IP. Первое число равно 45. Это означает, что это заголовок IP версии 4, имеющий длину 5x32 битов. Следующее поле использует восемь битов для типа службы, чтобы за- задать значения абстрактных параметров желаемого качества службы. Эти параметры должны использоваться при выборе параметров реальной служ- службы во время передачи дейтаграммы через определенную сеть. Несколько сетей предлагают приоритет службы, которая считает трафик с высоким приоритетом более важным, чем остальной трафик (обычно принимая тра- трафик только выше определенного приоритета во время высокой нагрузки). Основным выбором является трехсторонний компромисс между низкой задержкой, высокой надежностью и высокой пропускной способностью. В таблице 2.1 показано, как эти биты используются. • Бит 3: 0 = обычная задержка, 1 = низкая задержка • Бит 4: 0 = обычная пропускная способность, 1 = высокая пропускная способность • Бит 5: 0 = обычная надежность, 1 = высокая надежность • Биты 6-7: зарезервированы для будущего использования Таблица 2.1. Биты типа службы Двоичное представление И100000 11000000 10100000 10000000 01100000 •* 01000000 00100000 00000000 00100000 00010000 00001000 00000100 000000[00] Десятичное представление 224 192 160 128 96 64 32 0 32 16 8 4 Значение * .< Сетевой контроль Межсетевой контроль Critic/ECP Переопределение групповой записи Групповая запись Немедленно Приоритет Маршрутизация Приоритет Низкая задержка Высокая пропускная способность Высокая надежность Зарезервировано для будущего использования
Стек протоколов TCP/IP 73 Использование параметров задержки, пропускной способности и надеж- надежности может увеличить стоимость службы. Во многих сетях наилучшие пока- показатели для одного из этих параметров сочетаются с наихудшими для другого. Почти во всех случаях по крайней мере два из этих трех указателей должны быть заданы. Тип службы используется для определения обработки дейтаг- дейтаграммы во время ее передачи через систему Интернет. Рассмотрим каждый из этих вариантов подробнее. Задержка Если задать поле задержки как 1, то маршрутизатор IP будет выбирать тот маршрут к месту назначения, который имеет наименьшую за- задержку. Например, маршрутизатор IP выберет низкоскоростную наземную линию, а не спутниковую линию с более высокой задержкой, даже если по- последняя имеет большую полосу пропускания. Интерактивные сеансы, такие как telnet, могут требовать этот тип обслуживания. Пропускная способность Когда бит пропускной способности задан как 1, маршрутизатор IP будет выбирать маршрут с наибольшей пропускной способностью. В этом случае будет выбрана спутниковая, а не наземная ли- линия с более низкой скоростью из предыдущего примера, так как она ее про- пропускная способность выше. Если для загрузки большого файла используется такое приложение, как FTP, оно много выиграет от такой службы. Надежность Здесь также имеются две возможности, нормальная и высокая. Если задать это поле как 1, то маршрутизатор IP будет принимать решение первыми во время периодов перегрузки отбрасывать дейтаграммы с нормальной надежностью. Поле полной длины Следующее поле (длиной 16 битов) использует- используется для указания общей длины дейтаграммы. Она измеряется в октетах и включает заголовок IP и данные. Размер поля позволяет длине дейтаграм- дейтаграммы доходить до 65635 октетов. Такие длинные дейтаграммы являются не- непрактичными для большинства хостов и сетей. Все хосты должны быть готовы принять дейтаграммы до 576 байтов (целые или фрагментирован- ные). Рекомендуется, чтобы хосты посылали дейтаграммы больше 576 бай- байтов, только если есть уверенность, что место назначения готово принять дейтаграммы большего размера. Число 576 выбрано для того, чтобы предоставить возможность передать блок данных разумного размера в дополнение к требуемой информации за- заголовка. Например, этот размер позволяет поместить в дейтаграмме блок данных в 512 октетов плюс 64 октета заголовка. Максимальный заголовок IP имеет 60 байтов, а типичный заголовок IP — 20 байтов, не учитывая ва- вариантов, предоставляющих резерв для заголовков протоколов более высо- высокого уровня. Фрагментация и повторная сборка Если пакет IP с определенным размером максимального блока передачи (Maximum Transmission Unit, MTU) пересылается в сеть с размером MTU, который меньше, чем размер текущей дейтаграммы IP, дейтаграмма должна быть фрагментирована. Фрагментация не будет происходить, если размер дейтаграммы равен или меньше MTU сети, через которую передается пакет.
74 Глава 2 Фрагментация может происходить на посылающем хосте или на марш- маршрутизаторе. Каждый фрагмент посылается со своим собственным заголов- заголовком IP с достаточной информацией для выполнения повторной сборки в конечном месте назначения. Инструкции по сборке содержатся в иденти- идентификации, флаге фрагментации и полях сдвига фрагмента заголовка IP. На рис. 2.5 можно видеть, что следующим является поле идентифика- идентификации, занимающее два байта. Это идентифицирующее значение присваива- присваивается отправителем, чтобы помочь собрать фрагменты дейтаграммы. Оно используется в конечном месте назначения для рекомбинации всех фраг- фрагментов первоначальной дейтаграммы IP. Оно используется для группиров- группировки фрагментов. Поле идентификации выбирается посылающим узлом и помещается в исходную дейтаграмму IP вне зависимости от того, будет ли использоваться фрагментация. Следующим полем является поле флагов, для которого выделено три бита. Первый бит зарезервирован и должен быть равен нулю. Следующие два бита сообщают о фрагментации дейтаграммы. Если этот бит равен О (флаг сброшен), дейтаграмма может быть фрагментирована, если требует- требуется при передаче через маршрутизатор. Если этот бит равен 1, фрагмента- фрагментация запрещена. В этом случае маршрутизатор IP будет отбрасывать дейтаграмму и посылать источнику сообщение ICMP о том, что место на- назначения недоступно. Этот механизм используется при поиске маршрута MTU. Это делается с помощью PING, как показано на рис. 2.6. Второй бит является флагом дополнительных фрагментов, сообщающим, остались ли дополнительные фрагменты для передачи. Если он сброшен в О, то это означает, что это последний фрагмент; если он установлен в 1, то су- существуют дополнительные фрагменты для передачи. Флаг дополнительных фрагментов всегда установлен в 1 в первом фрагменте и во всех срединных фрагментах. Он сброшен в 0 в последнем фрагменте. . •.>,-,.,.. MS DOS Prompt ¦^'¦vMNOOWSsP^ktopj-ping prox -1 1<4СЮ -f -n 2 ring-ing PF.OX [10.0.0.10] with 1400 byte; of data: Reply from 10.0.0.10: bytes«1400 tiroe=dm; TTl=128 Peply from 10.0.0.10: fcyt«5=U00 time=lm? TTl=12S Ping ftatistici for 10.0.0.10: Pacl-etis Sent = 2, Received » 2, Last ш 0 (OX loss), Minimum = lmst Maximum a Ims, Average в lm; •:i\UINCOIsSvJDaiktop>pinfl pro-: -I 1S00 -f -n 2 Fingvra FP.OX [10.0.0.10] with 1500 bytes of data: 'packet needs to be fragmented but Offset. 'Packet needs to be fragmented but OF set. Pinj statistics for 10.0.0.10: Packet;: Stnt = 2, Fecev'«) = 0. tort = 2 A00* loss), 'A^proxiinate round trip time* in milii-recondr: Minimum a Cm?, Maximum » Oms, Average « Oms Рис. 2.6. Флаг "не фрагментировать" установлен в PING
I Стек протоколов TCP/IP 75 Поле сдвига фрагмента имеет в длину 13 битов и указывает, где в дей- дейтаграмме расположен этот фрагмент. Сдвиг фрагмента измеряется в еди- | ницах по восемь байтов F4 бита). Первый фрагмент имеет сдвиг ноль. Это используется для правильной сборки первоначальной полезной на- нагрузки IP. Полезная нагрузка фрагментируется по восьмибайтовым грани- | цам, называемым блоками фрагмента, и значение сдвига фрагмента является блоком фрагмента, где фрагмент начинается. 13 битов в поле сдвига фрагмента и каждое число в счетчике, представляющее восемь ок- октетов, допускают общую нагрузку 65536 октетов, фрагментированных на 8192 фрагментов. На практике полезная нагрузка IP может иметь максималь- максимальный размер только 65515 (IP MTU, равное 65535 байтов, минус минимальный размер заголовка IP, равного 20 байтам.) 1. Предположим, что имеется пакет IP в 1500 байтов с 20-байтовым за- заголовком IP и 1480-байтовой полезной нагрузкой. При фрагментиро- вании для переноса по 576-байтовой сети каждый фрагмент будет иметь свой собственный 20-байтовый заголовок IP и максимальную нагрузку IP в 522 байта (что соответствует 69 блокам фрагментов). f. При создании фрагментов первоначальный заголовок IP копируется (хотя не все параметры обязательно будут скопированы), и затем из- изменяются следующие поля: длина заголовка, TTL, общая длина, MF, сдвиг фрагмента и контрольная сумма заголовка. 2. В приведенном выше примере нагрузка в 1480 байтов делится на три фрагмента. Первый фрагмент состоит из 69 блоков фрагментов, ! второй — из 69 блоков фрагментов, а последний имеет 47 блоков фрагментов. 3. Заголовки IP для трех фрагментов будут содержать следующую ин- информацию: фрагмент 1 будет иметь общую длину 572, флаг MF будет установлен в 1 и сдвиг фрагмента будет установлен в 0. Фрагмент 2 бу- •;'| дет иметь общую длину 572, флаг MF будет установлен в 1 и сдвиг фрагмента будет равен 69. Фрагмент 3 будет иметь общую длину 396, флаг MF будет сброшен в 0 и сдвиг фрагмента будет задан как 138. Повторная сборка Фрагменты передаются промежуточным маршру- маршрутизатором IP по IP-адресу места назначения. Фрагменты могут следовать различными маршрутами к месту назначения и прибывать в порядке, от- отличном от того, в котором они были посланы. Сами фрагменты могут быть фрагментированы во время их перемещения к конечному пункту назначе- назначения. Для повторной сборки фрагментов в исходный вид IP использует поля идентификации и адрес IP источника. Когда узел места назначения получает фрагменты, он выделяет ресурсы для повторной сборки. Ресурсы повторной сборки состоят из буфера дан- данных, буфера заголовка, таблицы битов блоков фрагментов, поля общей длины данных и таймера. Если это первый фрагмент (со сдвигом фрагмен- фрагмента, равным 0), то его заголовок помещается в буфер заголовка. Если это по- последний фрагмент (с флагом MF, равным 0), то вычисляется общая длина данных.
76 Глава 2 Стандарты IP задают по умолчанию таймер повторной сборки на 15 се- секунд. Если все фрагменты не будут получены в течение этого времени, они будут отброшены и источнику может быть послано сообщение ICMP о пре- превышении времени ожидания. При получении фрагментов таймер задается как максимум текущего значения времени таймера и значения поля време- времени жизни из полученного фрагмента. Прибывающие дополнительные фрагменты помещаются в буфер дан- данных в порядке, согласно сдвигу фрагмента и длине, и соответствующие биты задаются в таблице битов блоков фрагментов. Когда приходит по- последний фрагмент (если все фрагменты в таблице битов блоков заданы как 1 для общей длины первоначальной нагрузки), повторная сборка заверше- завершена и полученная реконструированная полезная нагрузка доставляется соот- соответствующему протоколу верхнего уровня. Вопросы фрагментации при трансляционном переносе Трансля- Трансляционный перенос (translational bridging) используется для соединения се- сетей со смешанной средой передачи, таких как сеть Token Ring и Ethernet. При этом может возникнуть проблема, связанная с тем, что MTU двух се- сетей существенно различаются. В сегменте Token Ring допустимо MTU от 4464 до 17914, в то время как в сегменте Ethernet MTU ограничено 1500. Если два сегмента соединены мостом, то может возникнуть ситуация, когда пакеты отбрасываются, потому что мост не может фрагментировать дан- данные, как это делает маршрутизатор. Одно из решений — задать MTU на сер- серверах NT, соединенных с сетью Token Ring, равным 1500, для гарантии, что пакеты не будут отброшены в связи с чрезмерным размером. Конечно, прежде чем это сделать, необходимо выполнить мониторинг сети, чтобы уви- увидеть, были ли отброшены пакеты. Если это так, то может помочь следующая запись в реестре. В Реестре: HKEY LOCAL MACHINE\SYSTEM\CurrentCotrolSet\Services\adapter\Tcipip\ parameters Добавьте REG DWORD для MTU •- . . Принимает значения от 68 до значения MTU сети. Поле времени жизни (TTL — time-to-live) имеет восемь битов в длину и следует за полем сдвига фрагмента. Это поле указывает максимальное время, в течение которого дейтаграмма может оставаться в Интернете. Если это поле содержит значение ноль, то дейтаграмма должна быть разрушена. Это поле изменяется при обработке заголовка IP. Время измеряется в единицах секунд, но так как каждый модуль, обрабатывающий дейтаграмму, должен уменьшить TTL по крайней мере на единицу, даже если он занят этим менее секунды, TTL должно рассматриваться только как верхняя граница времени, в течение которого сможет существовать дейтаграмма. Цель состоит в том, чтобы отбрасывать дейтаграммы, которые невозможно доставить, связав
Стек протоколов TCP/IP 77 это с максимальным временем жизни дейтаграммы. По умолчанию TTL в Windows NT версии 3.5Х равно 32 секундам; в Windows NT 4.0 оно было поднято до 128 секунд. Это значение по сути является пределом того, ско- сколько маршрутизаторов может пройти дейтаграмма IP, прежде чем будет от- отброшена. Это значение можно изменить в реестре, как показано дальше: В Реестре: HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\Tcipip\parameters Добавьте REG DWORD для DefaultTTL Принимает значения от 1 до 255 Далее следует поле протокола, указывающее на протокол следующего уровня, используемый данными дейтаграммы IP. Для переноса этой инфор- информации используется восемь битов. Значения для различных протоколов определены в "Assigned Numbers" (Присвоенных номерах). Потом идет поле контрольной суммы заголовка с 16 битами, выделенны- выделенными для контрольной суммы только заголовка. Так как некоторые поля заго- заголовка изменяются (например, время жизни), то она вычисляется повторно и проверяется в каждой точке, в которой обрабатывается заголовок IP. Для вычисления контрольной суммы суммируются дополнения до единиц всех 16-битных слов в заголовке, и к полученной сумме применяется операция 16-битного дополнения до единиц. Значение поля контрольной суммы задается равным нулю. Следующие два поля являются адресом IP источника и адресом IP места назначения. Каждое из них имеет четыре октета. Именно здесь адреса IP включаются в обмен данными. Хотя это и важное поле, мы не собираемся тратить на него много времени, так как это может легко привести к обсужде- обсуждению маршрутизации, широковещания и т.п. Эти вопросы будут рассмотрены позже, при обсуждении сетевого трафика. Затем следует поле параметров, которое может появиться или не появи- появиться в дейтаграммах. Они должны быть реализованы всеми модулями IP (хостом и шлюзами). Необязательным моментом является их передача в каждой конкретной дейтаграмме, а не их реализация. В некоторых средах параметр безопасности может потребоваться во всех дейтаграммах. Поле параметров имеет переменную длину. Параметры IP будут иметь размер от одного до 40 октетов. Это будет давать максимальный размер заголовка IP в 60 байтов. Может быть ноль или большее количество параметров. Каждый параметр начинается с кода типа параметра. Этот код делится на три поля, первое из которых является полем копирования. Если это поле задано как 1, то параметр должен быть скопирован во все фрагменты. Если оно задано как 0, то он используется только в первом фрагменте. Следующие два бита в ок- октете кода параметра используются для указания класса используемого пара- параметра. Если он задан как 0, то это управление дейтаграммой или сетью, если как 2, то он используется для отладки или измерения. Другие являются заре- зарезервированными. Следующие пять битов используются для указания номера параметра в классе параметров.
78 Глава 2 Второй октет является длиной параметра, которая включает код типа параметра и октет длины, октет указателя и длину трех байтов данных о маршруте. Третий октет является указателем на данные о маршруте, ука- указывающим октет, где начинается адрес следующего источника, который будет обрабатываться. Указатель связан с этим параметром, наименьшее законное значение для него равно 4. Некоторые из этих параметров пере- перечислены в таблице 2.2. Таблица 2.2. Классы параметров и номера Класс параметра Номер параметра Значение параметра Class 0 Option 0 Однооктетный параметр, который используется для указания конца списка параметров. Он копируется в каждый фрагмент. Class 0 Option 1 Однооктетный параметр, который используется для выравнивания октетов в списке параметров. Он копируется в каждый фрагмент. Class 0 Option 3 Неопределенная маршрутизация от источника. Параметр переменной длины, используемый для ,. . ¦. маршрутизации дейтаграммы через указанный путь, где можно использовать альтернативные маршруты. Он копируется в каждый фрагмент. Class 0 Option 7 Записать маршрут. Параметр переменной длины, используемый для трассировки fI • ¦ маршрута в сети IP. Он не копируется в каждый фрагмент. Class 0 Option 9 Точная маршрутизация от источника. Параметр переменной длины, используемый для маршрутизации дейтаграммы через указанный путь, где нельзя использовать альтернативные " маршруты (противопоставление Option 3 выше). Он копируется в каждый фрагмент. Class 2 Option 4 Отметка времени Интернета. Параметр переменной длины, используемый для записи ряда отметок времени при каждом переходе. Он не копируется в каждый фрагмент. Параметр записи маршрута Параметр записи маршрута позволяет посылающей стороне создать заголовок IP с рядом пустых адресов IP в ка- качестве параметров IP. Когда дейтаграмма IP перемещается по сети, каждый встреченный маршрутизатор добавляет в список свой адрес IP, тем самым записывая пройденный к месту назначения маршрут. В параметре записи маршрута IP должно быть выделено достаточно места для хранения адре- адресов IP. Размер каждого поля определяется посылающим компьютером. Как
Стек протоколов TCP/IP 79 можно видеть в списке ниже, посылающий компьютер задает поле пара- параметров как 0x7, что указывает на использование параметра записи маршру- маршрута. Следующее поле - это поле длины параметра, которое является полем переменной длины, заданной в октетах посылающей машиной. Затем сле- следует поле указателя следующего слота, которое используется для указания сдвига октета в поле параметра записи маршрута, где начинается следующий доступный слот для записи адресов IP маршрута. IP: ID = 0xl3D; Proto = ICMP; Len: 92 IP: Version = 4 @x4) IP: Header Length = 52 @x34) ¦¦ ;> . + IP: Service Type = 0 @x0) , : . IP: Total Length = 92 @x5C) ..,./, : ¦• . ' IP: Identification = 7997 @xlF3D) ' "' + IP: Flags Summary = 0 @x0) IP: Fragment Offset = 0 @x0) bytes . -,•<-:, IP: Time to Live = 32 @x20) ¦ ... ...,;...' . ¦ IP: Protocol = ICMP - Internet Control Message .. .. . IP: Checksum = 0x3 63 9 IP: Source Address = 206.112.203.201 IP: Destination Address = 206.112.201.97 ' : IP: Option Fields = 7 @x7) IP: Record Route Option = 7 @x7) ' •¦' IP: Option Length = 31 (OxlF) IP: Next Slot Pointer = 4 @x4) .-,-..- ч IP: Route Traveled = 0 @x0) ¦•'¦•¦¦ IP: End of Options = 0 @x0) ¦, ; IP: Data: Number of data bytes remaining = 40 @x0028) Теперь посмотрим на ответ, который приходит из места назначения. Как можно видеть в приведенной ниже распечатке, большая часть информации выглядит точно так же, однако теперь она дополнена некоторой дополните- дополнительной информацией. Мы в наибольшей степени заинтересованы в маршруте к месту назначения. Мы видим адреса IP, которые были использованы для записи информации маршрутизатора, когда дейтаграмма IP перемещалась к своему месту назначения. Существуют максимум девять доступных слотов, которые могут распределяться посылающим компьютером. В этом примере использованы три из них. IP: ID = 0xFC5; Proto = ICMP; Len: 92 IP: Version = 4 @x4) IP: Header Length = 52 @x34) + IP: Service Type = 0 @x0) IP: Total Length = 92 @x5C) IP: Identification = 4037 @xFC5) + IP: Flags Summary = 0 @x0) IP: Fragment Offset = 0 @x0) bytes IP: Time to Live = 125 @x7D) IP: Protocol = ICMP - Internet Control Message IP: Checksum = 0x56EE IP: Source Address = 206.112.201.97
80 Глава 2 IP: Destination Address = 206.112.203.201 •..,.¦> IP: Option Fields = 7 @x7) -.,-... -, .. ,. IP: Record Route Option = 7 @x7) IP: Option Length =31 (OxlF) IP: Next Slot Pointer = 16 @x10) '" ' '¦'¦' >!-' * IP: Route Traveled = 206 (OxCE) ' ' ;" ' ' •'r IP: Gateway = 206.112.201.126 IP: Gateway = 206.112.201.97 IP: Gateway = 206.112.196.82 IP: End of Options = 0 @x0) IP: Data: Number of data bytes remaining =40 @x0028) Приведенные выше листинги были сделаны с помощью команды PING Windows NT с параметром команды -г. Она посылает сообщение с запросом Echo ICMP, который записывает маршрут. Неопределенная маршрутизация от источника Обычно маршру- маршрутизаторам и Windows NT разрешается принимать решения о маршрутиза- маршрутизации на основе таблиц маршрутизации. Однако иногда при поиске неисправностей, тестировании и отладке сетей необходимо определить маршрут к месту назначения, не беспокоясь о модификации таблиц марш- маршрутизации. Когда мы переопределяем путь доступа, который будет обычно использоваться, мы вмешиваемся в маршрутизацию IP от источника. IP поддерживает два вида маршрутизации от источника: неопределенную и точную. Сначала рассмотрим неопределенную маршрутизацию от источника. При неопределенной маршрутизации от источника IP-дейтаграмма ад- адресуется следующему маршрутизатору с помощью IP-адреса места назначе- назначения из заголовка IP. При неопределенном источнике маршрута хорошо то, что можно определить маршрутизатор, который находится в нескольких переходах. Посмотрим на поле параметров при использовании неопреде- неопределенной маршрутизации от источника. В распечатке ниже можно видеть, что поле кода параметра задано равным 131. Это значит, что используется параметр неопределенной маршрутизации от источника (см. рис. 2.7). IP: ID = 0xA32E; Proto = ICMP; Len: 68 IP: Version = 4 @x4) IP: Header Length = 28 (OxlC) + IP: Service Type = 0 @x0) IP: Total Length = 68 @x44) IP: Identification = 41774 @xA32E) + IP: Flags Summary = 0 @x0) IP: Fragment Offset = 0 @x0) bytes IP: Time to Live = 32 @x20) IP: Protocol = ICMP - Internet Control Message IP: Checksum = 0xlE34 IP: Source Address = 10.0.0.60 IP: Destination Address = 10.0.0.10 IP: Option Fields = 131 @x83) IP: Loose Source Routing Option = 131 @x83) IP: Option Length = 7 @x7) IP: Routing Pointer = 4 @x4)
Стек протоколов TCP/IP 81 Network Молим - (EAooukcapiUxite s .U*J_xJ [Tin» jgtc ШС Addr Igft KAC Addr brococol|l>«gctipci |2. elS|00902764H8r 1»»0X TCP I. A. . .., ! 10.00.00.60 To 10.00.00.10 I?: He»dtr Ltngrth - ?8 (OsclC) ¦4>X?: Service Type - 0 @x0) IP-. Total Length « 68 @x44) I»: Identification - 41774 <0xA32I) ^II»: tlmgs SuiMiy ¦ 0 @x0) IP: Fragment Olfc«c ¦ 0 @x0) bytes IP: Time to Live • 32 @x20) IP: Protocol ¦ ICUP - Internet Control ! IP: Checkrum ¦ 0x1134 IP: Source A4dre*a - 10.0.0.«0 IP: Destination Addxtst ¦ 10.0.0.10 Pi.liU о 131 @*S3) ¦IP: Loot* Source Boucing Option IP: Option L«a9Ch • 7 @x7) . -II:. Rout* Го Co • 10 (OxJJ J ¦"-¦'"' *"- 00000000 00 90 Zt 64 Ti, »« 00 90 27 64 FI BF 06 00 47 00 00000010 00 44 А.Э 21 00 00 ZO 01 II 34 0A 00 00 ЭС OA 00 00000020 00 0A fcb»TiУМЛЦЗДJfr|'flf«flP|tfiflfiTflJQ9 00 ZT SC 01 00 000000Э0 II» 00 61 «2 S3 C4 65 66 67 68 69 6A €B 6C 6D 61 00000040 67 70 71 72 73 74 ?$ ?6 77 61 $Z «Э ?4 «5 66 67 00000050 66 69 •^anoui octiens for W» IP packet if A.22E4 |l№3»(»22) Рис. 2.7. Выделен параметр неопределенной маршрутизации от источника IP: Route To Go = 10 (ОхА) IP: Gateway = 10.0.0.60 IP: End of Options = 0 @x0) IP: Data: Number of data bytes remaining = 40 @x0028) Поле длины параметра, приведенное выше, равно длине в байтах, полу- полученной 131 параметром. Это поле задается посылающей машиной. В дан- данном случае используется семь байтов для параметра неопределенной маршрутизации источника. Указатель маршрутизации используется для определения сдвига октета в полях параметра 131 для указания, где начина- начинаются данные маршрутизатора. Здесь мы пропускаем четыре байта с начала поля параметра и видим IP-адрес первого маршрутизатора в шестнадцате- ричном представлении. Это выделено на рис. 2.7. Если посмотреть на шест- надцатеричную панель (внизу экрана), можно увидеть, что поле параметра начинается с 83 (шестнадцатеричного значения 131, кода параметра неоп- неопределенной маршрутизации источника). Теперь сдвиг определен как 04, что сообщает, где в данных расположен IP-адрес первого маршрутизатора. Отсчитывая от 83 четыре числа, мы получаем ОА A0 в шестнадцатеричном представлении), что будет первым октетом IP-адреса маршрутизатора. Можно заставить PING использовать неопределенный маршрут от ис- источника, применяя параметр -j. Команда будет выглядеть как PING -j 10.0.0.10 10.0.0.60. Первый адрес определяет место назначения, а второй и
82 Глава 2 "i C:\WINNT\Suslem32\cmd еке ::S>pin» -j 207.78.244.6 imu.JHharris.com inging juliarris.con B16.23.2.1401 with 32 bytes of data: equest tined out. equest tined out. equest tined out. equest tined out. Рис. 2.8. Параметр неопределенной маршрутизации от источника определяет маршрут к месту назначения следующие адреса являются маршрутизаторами для использования в на- направлении к месту назначения. Это показано на рис. 2.8. Параметр точной маршрутизации от источника Этот параметр очень похож на неопределенный маршрут от источника. Как можно видеть в рас- распечатке ниже, поля выглядят почти идентично параметру неопределенной маршрутизации. Имеется поле кода параметра, который в данном случае содержит 137. Это код параметра точной маршрутизации от источника. Он равен 0x89 в шестнадцатеричном представлении, что видно в распечатке. Следующее поле определяет длину параметра, которая в данном случае так- также равна семи. Она будет меняться в зависимости от числа переходов, ко- которое будет определено для места назначения. Это задается посылающей машиной так же, как и прежде. Указатель маршрутизации используется для отметки начала данных для первого маршрутизатора, как было и в случае параметра неопределенной маршрутизации от источника. Можно использовать точную маршрутизацию от источника с целью тес- тестирования, используя команду PING с параметром -к. Например, можно ввести PING -к 10.0.0.10 10.0.0.60. Первый адрес определяет место назначе- назначения, а второй и последующие адреса являются маршрутизаторами для ис- использования в направлении места назначения. Что-нибудь подобное нельзя сделать с помощью команды TRACERT. IP: ID = 0XA32E; Proto = ICMP; Len: 68 IP: Version = 4 @x4) IP: Header Length = 28 (OxlC) + IP: Service Type = 0 @x0) IP: Total Length = 68 @x44) IP: Identification = 41774 @xA32E) + IP: Flags Summary = 0 @x0)
Стек протоколов TCP/IP 83 IP: Fragment Offset = 0 @x0) bytes , IP: Time to Live = 32 @x20) IP: Protocol = ICMP - Internet Control Message IP: Checksum = 0xlE34 IP: Source Address = 10.0.0.60 IP: Destination Address = 10.0.0.10 IP: Option Fields = 131 @x83) IP: Loose Source Routing Option = 131 @x83) IP: Option Length = 7 @x7) IP: Routing Pointer = 4 @x4) IP: Route To Go = 10 (OxA) . . IP: Gateway = 10.0.0.60 IP: End of Options = 0 @x0) IP: Data: Number of data bytes remaining = 40 @x0028) Параметр отметки времени Интернета Этот параметр работает ана- аналогично параметру записи маршрута в том смысле, что посылающий узел со- создает последовательность пустых пробелов, которые заполняются маршрутизаторами на пути к месту назначения. Записи являются IP-адресом маршрутизатора и отметкой времени. Отметка времени — это 32-битное це- целое число, которое является числом миллисекунд, прошедших с полуночи универсального (т.е. гринвичского) времени. Если универсальное время не- недоступно маршрутизатору, то он может использовать что-то другое, но дол- должен указать, что используется не универсальное время, задавая старший бит в поле отметки времени равным 1. Код параметра равен 68 @x44). Он сооб- сообщает, что используется параметр отметки времени Интернета. Поле длины параметра задается посылающей машиной, но оно имеет максимальную дли- длину 40 октетов, включая поля типа параметра, длины, указателя и флага пере- переполнения. Как можно видеть в листинге, поле указателя времени сообщает, где начинается отметка времени. Это смещение от начала поля параметра 68. Наименьшее законное значение для этого поля равно пяти, что показано в приведенной ниже распечатке. Следующее поле — это поле флага, использующее 0 для записи только отметки времени без IP-адресов, 1 для записи отметки времени с IP-адре- IP-адресом и 3 для определения посылающего узла и отметки времени, если он со- соответствует IP-адресу следующего маршрутизатора. В распечатке ниже задан флаг 1, это значение используется чаще всего. Размер этого параметра не изменяется с числом собранных отметок времени. Если выделенная для отметок времени область будет исчерпана, то будет увеличиваться поле пропущенных станций. Поля шлюза и точки времени используются для хранения IP-адреса и отметки времени. Они за- заполняются маршрутизатором при ответе на дейтаграмму. IP: ID = 0xC4BA; Proto = ICMP; Len: 72 IP: Version = 4 @x4) IP: Header Length = 32 @x2 0) + IP: Service Type = 0 @x0) IP: Total Length = 72 @x48) IP: Identification = 50362 @xC4BA)
84 Глава 2 + IP: Flags Summary = 0 @x0) IP: Fragment Offset = 0 @x0) bytes ¦ .. ' . IP: Time to Live = 32 @x20) ¦,..'.-¦ ;.'¦ IP: Protocol = ICMP - Internet Control Message IP: Checksum = 0x57El ¦¦•'¦ " :• IP: Source Address = 206.112.203.201 IP: Destination Address = 206.112.201.97 IP: Option Fields = 68 @x44) ';' ¦ IP: Internet Timestamp Option = 68 @x44) IP: Option Length = 12 (OxC) ¦ ¦ , . ; . IP: Time pointer = 5 @x5) ..,'-¦- IP: . . 0001 = Одновременно отметки времени • ¦ '..- ¦;' ... ' и адреса IP :,:.';-¦- IP: Missed stations = 0 @x0) ; . ; •:, IP: Time Route = 0 @x0) : ¦';"''- . v" ' ¦¦'¦¦'-¦¦'¦¦¦ IP: Gateway = 0.0.0.0 ' ¦/"'-.:¦¦ T^~"~7>~+— IP. Time point = о @x0) ¦ - IP: Gateway = 8:0:88:91 IP: Time Point = 50393600 (Ox300F200) IP: Data: Number of data bytes remaining = 40 @x0028) Обзор главы В этой главе был рассмотрен большой материал, значительная часть кото- которого обсуждалась достаточно подробно. Время, затраченное на изучение этой главы, окупится сторицей при попытке найти причину возникшей проблемы или настроить сеть. Знание протоколов, определяющих части кадра, пакета или дейтаграммы, является критически важным в любой ситуации. В следующей главе В следующей главе будет рассмотрен стек протоколов SPX/IPX. Подробно будет обсуждаться структура заголовков обоих протоколов. Будет проана- проанализирована функция сетевых номеров и зарезервированные сетевые номе- номера, а также номера сокетов и маршрутизация IPX. Завершится глава изучением структур заголовков сообщений.
Глава 3 Стек протоколов SPX/IPX Стек протоколов SPX/IPX все еще широко распространен во многих кор- корпоративных сетях. Это быстродействующий компактный набор протоко- протоколов для операционной системы Novell NetWare. Довольно эффективный, этот протокол может выполнять маршрутизацию. Мы собираемся рассмот- рассмотреть его и некоторые связанные с ним вопросы. Сначала познакомимся с такой важной частью стека SPX/IPX, как протокол SPX (Sequenced Packet Exchange — Протокол последовательного обмена пакетами). Протокол SPX , Протокол SPX — это протокол с поддержкой соединения, который обычно действует поверх протокола IPX (Internetwork Packet Exchange — Протокол межсетевого обмена пакетами). Он похож по функциональности на прото- протокол TCP из стека TCP/IP. SPX предоставляет управление соединением для двусторонней коммуникации, обеспечивая тем самым устойчивый поток данных. Он имеет возможность устанавливать соединение с одноранговым узлом на другой машине, согласовывать размер буфера и обеспечивать прави- правильную доставку и получение данных. Для этого он использует номера последо- последовательности и комбинацию подтверждений (ACKS) и не подтверждений (NAKS). Он не выполняет, однако, согласования размера пакета, как это де- делает TCP (хотя SPXII способен выполнять согласование размера пакета). Заголовок SPX Рассмотрим теперь 12-байтовый заголовок SPX. Трассировка сетевого мо- монитора на рис. 3.1 показывает, где находится SPX. По сути, здесь имеется заголовок Ethernet, заголовок IPX и заголовок SPX.
86 Глава 3 ?drt ОЛсар lde>\616l cap Не»! Tods Qptoa Wr«ta* *!ff^jj !¦? ЕЛ1Г J37 46 41 !48 3S6. 3d! 3S6.38! 354.Э9< 356.40( 3S6.«0( 356.40E 3S6.40! 3S6.40! 0Q609720F46D C0MPAQA63A32 ЭСОН 3FA631 0060972GM6D C0HPAQA63A32 00S09720F46D 00609777C86C COKPAQA63A32 006097207460 C0hPAQA63A32 C0KPAQA63A32 00609720F46D СОИРА0А63А32 00€0S7Z0F<6D С0КРАОА6ЭА32 ЗРХ SHB SHB SHB SHB MBIPX FID • 0x7001, P-e*d 0x4 «t ОхОООООЗХА OzOO, 0X6DA2 ~> 0x5374, FID - 0x7001, B»*d 0x4 at 0x00000311 FII> * 0x7001, R*a P«*d 0x4 ot 0x4 &»t.*, K««p Allv* 0x4 *t 0>000003FZ У J (tiu prop«rci*c 802.3 L«n«th - «0 .4001 -> 1.000000300001.600S - 0 Hop* SPX: Connection conceal 128 (OxBO) SPX: 1 - 2у*г«а Packet SPX: .0 * Acknovl«do*»*nt. Hoc ft*quired SPX: . .0 • Ho Attention SPX: ...0.... * Not. Ind o( !I«ff*gi SPX: 0 .. «Hoc *л SPX IX P«ck«t. SPX: Хялл 9Х.Х9ШШ сур* • 0x00 SPX: Source Connection * 27298 @«6AA2) SPX: D**cin*CLon Connection - 21361 (OxS371) SPX: Secfucnce number « 2 <OxZ) SPX: Ackno«i«dij# тшЬег ¦ 2 @x2) SPX: Allocation number ¦ 5 {OxSI SPX: &*t»: Mu*kb*r of dexa by^es i.nlna ¦ 4 @x0004) а&^гужяу*екжк*й 00000000 00 80 SI k6 3k 32 00 20 AF 3F A6 31 00 2A FF FF 00000010 00 2A 00 05 00 00 00 01 00 00 00 00 00 OWO 05 00000020 00 00 30 01 00 20 AF 3F A< Э1 40 01 ооооооэо ИЖ1ЖЛ^Ш|ТЛ|НМ oo 07 oo Рис. 3.1. Заголовок SPX следует за заголовками Ethernet и IPX ; \ * ¦ ¦ ¦ Заголовок SPX состоит из следующих семи полей: . •-,.¦¦¦'¦¦ • Управление соединением — 1 байт • Тип потока данных — 1 байт " ' • Идентификатор соединения источника — 2 байта • Идентификатор соединения места назначения — 2 байта • Номер последовательности - 2 байта ., . • Номер подтверждения — 2 байта ¦ ¦¦:¦ • Номер размещения — 2 байта Управление соединением Остановимся на некоторых функциях, предоставляемых полем управления соединением. Эквивалент флагов TCP, которые были показаны в главе 2, управление соединением предоставляет механизм двунаправленного потока данных, управления перегрузкой и дру- другие связанные с этим возможности. Поле управления соединением указыва- указывает три типа пакетов управления соединением. Эти значения могут быть либо логическими, либо могут быть заданы вместе с несколькими флагами. Сначала рассмотрим флаг конца сообщения.
Стек протоколов SPX/IPX 87 • Флаг "Конец сообщения" (End-of-message). Этот флаг устанавливается, когда в поле управления соединением появляется 0x10. Он использу- используется для указания конца сообщения партнеру по передаче. Так как SPX является транспортным протоколом на основе сообщений, посы- посылающая сторона задает этот флаг для указания, что сообщение завер- завершено. После того как получающая сторона получит этот пакет, она передаст данные в буфер сообщения вышележащего приложения. Это не запрос конца соединения, но скорее указание, что текущий обмен сообщениями закончился. • Флаг "Требуется подтверждение" (Acknowledgment-Required). Флаг требования подтверждения устанавливается, когда в поле управления соединением появляется 0x40. Он используется для указания, что дан- данные были посланы партнеру по передаче и требуется подтверждение. Прежде чем будут отправлены новые данные, должно быть получено подтверждение для этого пакета. • SPX требует подтверждения посланных данных; когда они получены, устанавливает флаг, сигнализирующий "конец сообщения" для парт- партнера. Число является комбинацией 0x40 и 0x10 и равно 0x50. • Флаг "Системный пакет" (System-Packet). Флаг системного пакета уста- устанавливается, когда в поле управления соединением появляется 0x80. Это пакет подтверждения, используемый внутренне протоколом SPX для подтверждения, что партнер по сеансу работает и соединение существует. Это сообщение типа "Я здесь". • Флаг "Комбинация системных пакетов" (System-Packet combination). Флаг комбинации системных пакетов устанавливается, когда в поле '¦;' управления соединением появляется ОхСО. ОхСО является суммой 0x80 и 0x40. Он используется внутренне протоколом SPX, показывая, что соединение все еще существует, требуя подтверждения (АСК) от партнера по коммуникации. Это пакет типа "Вы еще здесь?". Тип потока данных Тип потока данных (DataStream) сообщает, какой тип данных переносится внутри пакета. Он может быть задан как специаль- специальное число, определенное приложением через Winsock. Самой важной фун- функцией этого поля является обеспечение аккуратного разъединения сеанса. По умолчанию это будет одно из двух следующих сообщений: • Конец соединения (End-of-Connection). Если тип потока данных задан как OxFE, то партнер по сеансу хочет прекратить сеанс. • Конец соединения (End-of-Connection). Если тип потока данных за- задан как OxFF, то пакет передается, так как был получен запрос конца соединения. Некоторые из других записей, встречающиеся в этом поле, включают числа, перечисленные в таблице 3.1.
88 Глава 3 Таблица 3.1. Употребительные типы полей потока данных Номер поля Значение 0 Часть данных пакета содержит информацию, которую необходимо распечатать. 1 .¦•... Остановить печать и очистить буферы. 2' Остановить печать, но сохранить текущие данные и подождать дополнительных инструкций. '3 "¦'¦ Перезапустить задание печати, используя буферы данных. 4 Остановить печать из буферов данных и использовать данные, зарегистрированные в боковой полосе. Поле данных боковой полосы имеет три функции: (а) счетчик, (Ь) символ для печати и (с) конечный символ. 5 Начало нового пакета задания печати. 6 Передает управление процессу, а не серверу печати. 7 Извлекает принтер из процесса и возвращает его .., серверу печати. 8 ¦''• Конец задания. ; '. ,,. 254 Конец соединения. 255 АСК конца соединения. Идентификатор соединения источника и места назначения Это тре- третье и четвертое поля из семи полей заголовка SPX. Поля идентификаторов сое- соединения источника и места назначения занимают два байта и используются для демультиплексирования сеансов SPX через единственный сокет на уровне IPX. Если идентификатор соединения места назначения задан как 0XFFFF, значит, это пакет начального соединения. Порядковый номер Пятое поле в заголовке SPX является полем по- порядкового номера. Это двухбайтовое поле, содержащее счетчик передан- переданных пакетов данных. Это число будет увеличиваться после получения подтверждения о передаче пакета данных. Номер подтверждения Шестое поле является полем номера под- подтверждения, сообщающим номер последовательности следующего пакета SPX, который ожидается от партнера SPX. Номер размещения Последнее поле заголовка SPX является полем номера размещения. Это поле сообщает номер буфера получения, который доступен на рабочей станции. Этот номер почти всегда больше, чем номер подтверждения. Доступность свободных буферов вычисляется, как размер окна, который равен номеру размещения минус номер подтверждения плюс один. Это поле используется как механизм управления потоком. Он работает следующим образом. Когда получающая сторона посылает номер
Стек протоколов SPX/IPX 89 размещения меньше номера подтверждения, отправитель не будет больше посылать данные, пока получающая сторона не пошлет пакет с номером размещения больше номера подтверждения. Пример создания соединения Трассировка сетевого монитора, при- приведенная ниже, показывает последовательность успешной инициализации сеанса. Отметим, что идентификатор соединения места назначения задан как OxFFFF, а номер размещения как OxFFFF. Эта последовательность пакетов называется квитированием SPX. SPX: ConCtrl = OxCO, DtaStrm = 0x00, 0хЕ8А2 -> OxFFFF, Seq = 0, Ack = 0, Alloc = 65535 SPX: ConCtrl = 0x80, DtaStrm = 0x00, 0x9774 -> 0xE8A2, Seq = 0, Ack = 0, Alloc = 3 Пример обычного потока данных Трассировка сетевого монитора, приведенная ниже, показывает успешную передачу данных. Отметим, как связаны Seq и АСК, и что номер размещения (Alloc) всегда больше АСК. SPX: ConCtrl = 0x80, DtaStrm = 0x00, 0x9774 -> OxFFFF, Seq = 7, Ack = 8, Alloc = 9 SPX: ConCtrl = 0x50, DtaStrm = 0x00, 0x9774 -> 0xE8A2, Seq = 8, Ack = 7, Alloc = 10 SPX: ConCtrl = 0x80, DtaStrm = 0x00, 0xE8A2 -> 0x9774, Seq = 7, Ack = 9, Alloc = 10 SPX: ConCtrl = OxCO, DtaStrm = 0x00, 0x9774 -> 0xE8A2, Seq = 9, Ack = 7, Alloc = 10 Пример "культурного" закрытия сеанса Трассировка сетевого мо- монитора, приведенная ниже, показывает успешную последовательность пре- прекращения сеанса. Отметим, что задается поле DtaStrm для указания конца запроса соединения и ответа. SPX: ConCtrl = 0x50, DtaStrm = End of Connection Req., 0xE8A2 -> 0x9774, Seq = 10, Ack = 10, Alloc = 12 SPX: ConCtrl = 0x00, DtaStrm = End of Connection Resp., 0x9774 -> 0xE8A2, Seq = 10, Ack = 11, Alloc = 14 Общие рекомендации по чтению трассировок SPX Следующие ре- рекомендации могут оказаться полезными при выделении проблемы. • Можно видеть несколько идентификаторов сеансов, приходящих с од- одного компьютера. Попробуйте изолировать трассировку для опреде- определенного идентификатора сеанса, чтобы проверить его правильность. • Посмотрите на число переходов и сравните физический уровень Ethernet с Token Ring. Проблема может быть связана с промежуточ- промежуточными маршрутизаторами или с размером пакета. Помните, что SPX не выполняет согласования пакетов. • Обратите внимание на номер размещения и проверьте, что он боль- больше номера подтверждения. Это проверка того, что отсутствует ка- какая-либо проблема, связанная с переполнением буфера. В основном это происходит с 16-разрядными клиентами в реальном режиме.
90 Глава 3 • Проверьте все повторные передачи пакетов данных. Обычно пробле- проблема повторной передачи проявляется как вопрос производительности. Проверьте интервал времени между отправкой данных и получением пакета АСК, чтобы проверить наличие временной задержки. Ограничения протокола SPX Хотя SPX предоставляет транспорт с поддержкой соединения, SPX имеет несколько ограничений. • Только один пакет может ожидать в любой момент времени. ! ¦' • Коммуникация на основе SPX не делает никакого согласования пакета. ВНИМАНИЕ! Приведенные выше ограничения применимы только к про- протоколу SPX. SPX П является усовершенствованной версией SPX со следующими изменениями: • SPX II использует максимальный размер пакета, допустимый сетью. Пример: 1518 байтов для Ethernet (SPX имеет максимум 576 байтов). • Окна SPX II допускают несколько ожидающих пакетов и позволяют передавать отрицательное подтверждение (NAK), чтобы указать, что некоторые пакеты не были получены. • SPX II допускает согласование пакетов. Пакет запроса согласования размера может посылаться в любое время в процессе коммуникации, если пакеты не доходят до места назначения. Идентификатор соединения с источником Это поле содержит двух- двухбайтовый номер соединения SPX, присвоенный станцией источника SPX и используемый для отслеживания различных виртуальных соединений SPX, которые может поддерживать сокет. Этот номер появится в идентификаторе соединения места назначения, когда прибудут пакеты от партнера по соеди- соединению для этой станции. Идентификатор соединения с местом назначения Это поле содер- содержит двухбайтовый номер соединения SPX, присвоенный станции места на- назначения SPX. Он используется для отслеживания различных виртуальных соединений SPX, которые может поддерживать сокет. Этот номер появит- появится в идентификаторе соединения источника, когда пакеты посылаются партнеру по соединению. Порядковый номер SPX присваивает порядковый номер каждому пакету данных, посланных партнеру по соединению. Этот номер увеличива- увеличивается, когда пакет данных подтверждается, что обеспечивает упорядоченную передачу пакетов из источника в место назначения партнера по соедине- соединению. Это поле не увеличивается для пакетов, которые не содержат данных (системных пакетов). Номер подтверждения Это ожидаемый номер последовательности для следующего пакета данных от партнера по соединению в месте назначе- назначения. Это поле не увеличивается для пакетов, которые не содержат данных (системных пакетов).
Стек протоколов SPX/IPX 91 Номер размещения Этот номер используется для вычисления количе- количества доступных для получения пакетов буферов, посланных из места назна- назначения соединения. Он соответствует номеру последовательности пакета, который подготовлен для отправки, но еще не послан. Источник соедине- соединения не может превысить номер размещения. Когда источник соединения ге- генерирует ЕСВ (блок управления событиями) приема, SPX увеличивает номер размещения. Это поле не увеличивается для пакетов, которые не содержат данных (системных пакетов). Данные Запись данных (если они присутствуют) содержит любые данные или коды, которые посылаются на сервер и с сервера. Поле сокета указывает пакет SPX, посылаемый клиентом на сервер. Со- кет клиента сервера будет 8060. Пакет содержит также некоторые имею- имеющие отношение к SPX данные для целей соединения. Запись управления соединением в заголовке SPX показывает код COh, означающий, что пакет является системным пакетом, который требует подтверждения от сервера при получении. ,; t--:-X "Ъ'-'^-f . *й. ¦"-,-"•...¦¦¦•¦.¦¦•- .*>¦¦¦«¦. -.-¦¦ •¦•. г- ¦¦;--р|<":«11 ¦'»•-'? Протокол IPX Протокол IPX является протоколом третьего уровня без поддержки соеди- соединения, предназначенным для передачи дейтаграмм. Компания Novell адап- адаптировала его из старого протокола межсетевых дейтаграмм (протокол IDP) -стека Xerox (XNS). Протокол без соединения Поскольку он является протоколом без поддержки соединения, то когда процесс, выполняющийся на определенном узле, использует IPX для комму- коммуникации с процессом на другом узле, между двумя узлами не устанавливает- устанавливается соединение. Таким образом, пакеты IPX адресуются и посылаются к своему месту назначения, но нет гарантии или проверки успешной достав- доставки. Любое подтверждение пакета или управление соединением обеспечива- обеспечиваются протоколами выше IPX, такими как SPX. Термин дейтаграмма означает, что каждый пакет интерпретируется как отдельная сущность, не имеющая логической или последовательной связи с любым другим пакетом. Работа на сетевом уровне модели 0SI Как протокол сетевого уровня IPX адресует и маршрутизирует пакеты из од- одного местоположения в другое при межсетевом обмене IPX. IPX принимает решения о маршрутизации, просматривая поля адресов заголовка и на осно- основе информации, которую он получает из RIP или NLSP. IPX использует эту информацию для пересылки пакетов в их узел назначения или следующему маршрутизатору, предоставляющему путь к узлу назначения.
92 Глава 3 Структура пакета . Так как протокол IPX был адаптирован из старого протокола XNS ГОР, не удивительно, что их структуры похожи. Пакет IPX состоит из двух частей. Первая часть является 30-байтовым заголовком, который содержит адре- адреса сети, узла и сокета для машин источника и места назначения. Вторая часть является разделом данных, который иногда содержит заголовок протокола более высокого уровня, такого как SPX. Минимальный пакет IPX имеет 30 байтов (не считая заголовок MAC). Максимальный размер маршру- маршрутизированных пакетов IPX обычно имеет только 576 байтов, включая заго- заголовок IPX и нагрузку данных. Однако при использовании IPX II это число возрастает до 1500 байтов. Как было отмечено в главе 2 о TCP, сетевой уровень следует за заголов- заголовком MAC, поэтому IPX помещается после заголовка MAC и перед полезной нагрузкой. На рис. 3.2 показано, что заголовок IPX помещается внутри про- протокола MAC таким же образом, как описано в главе 2. ... , Network Momloi IDVcap lilet\61G1 ?* B«P<« I«* fiptont Window Help jafii \ |_|е|х| Vrema 3? эв iTiat Src НАС Addt 356. 383QQ$Q9?2OM6D Ь«. MAC Addr IProe C0JlPAQAb3A32 I SUB 00*09?20F46D |sHB read, ПС - 0x7001, *e»d 0x4 *t Ox000003U. r«*d, Head 0x4 ot 0x4 Base 1х*мт properties «•ITHIRMIT: вОг.Э Length - 60 -ITHI1UT1T. D.*tiu.cion Kd4r«*s : 0080SFA63A3Z BTHIBKST: 0 - XndLvidukl *ddr*s. 1ТИЖВКЖТ: 0, • Univet««lly iMlmiaixtered *ddr*ct -17Н1Ы1П: Souxc* »ddr«»» ; QQZ0Xt3Tk63i ' 1ТН11ШЖТ: 0 <• No routine infor»*cion pr**#nc ITHIRJfIT: 0. ¦ Universally »4»lnJ.*c*r*d addr*s* «rHIRjfIT: Гхтшш L*n«ch : 60 <OsOO3C) XTHIAirtT: D»t» L«ugcb : 0i002A D2 > JTHIWflT: lch*rn«c I>»c»: Vu»b*r o( d*t.s byt-** tcuiiung - -tfi (OxO0ZI> •IPX; SpX P»ck#c - 3001.00г0АГЭГА631.4001 -> I.000000000001.600S - 0 Hop* IPX: Ch»cksuxi - «5&Э5 (.QxTttt) IPX: IDP t«Mjrch - 42 @x2A) IPX: Transport, control • 0 @x0) IPX: P*ck*b cyp* * SPX .' •-IPX: DiftlMdon Addr«fi Зихшагу 1.000000000001.6005 IPX: IPX Addr«ss ¦ 00000001.000000000001 IPX: D«ebin*tion V*c »uab*r - 1 @x1) IPX: D«*cin*t.lDn Sock»c Hu«b«r - 0x6005 IPX: Source Net Kumber - 12Z8S @x3001) IPX: Source Socket Number ¦ 0x4001 IPX: L>*c»: llukbex of d*te. bycis re»kinlag - 12 @«0O0C) lL _ ;._ 30000000 00 80 SF кб ЗА 32 00 20 AF 3F k€ 31 00 ZX ft ?F 10000010 00 2A 00 05 00 00 00 01 00 QO 00 00 00 01 60 OS $_»:2. »?*!.• irF»:"l/23330 4 Рис. 3.2. Заголовок IPX помещен внутри протокола MAC Рассмотрим структуру заголовка IPX. Он состоит из следующих полей: • контрольная сумма (checksum) • длина пакета (packet length)
Стек протоколов SPX/IPX 93 • управление транспортом (transport control) ••- •¦¦¦•:... • тип пакета (packet type) : • сеть назначения (destination network) .^ • узел назначения (destination node) •¦ ¦¦ • сокет назначения (destination socket) • сеть источника (source network) • узел источника (source node) • : '¦ • • сокет источника (source socket) Контрольная сумма Поле контрольной суммы используется для обес- обеспечения целостности пакета. Контрольная сумма используется новыми вер- версиями Netware, так как 3.x и более ранние версии задают поле как OxFFFF и не используют контрольную сумму. Длина пакета Поле длины пакета является длиной заголовка IPX плюс длина данных в байтах. Длина пакета должна быть не менее 30 байтов, чтобы предоставить достаточно места для заголовка IPX. Управление транспортом Управление транспортом является числом маршрутизаторов, которые пересек пакет на пути к месту назначения. Посы- Посылающие узлы при создании пакета IPX всегда задают это поле как ноль. Ког- Когда маршрутизатор получает пакет, требующий дальнейшей маршрутизации для достижения конечного места назначения, значение поля увеличивается на единицу и пакет передается дальше. Тип пакета Поле типа пакета указывает вид службы, которая либо предлагается, либо требуется пакету. В таблице 3.2 перечислены некоторые часто используемые типы пакетов, которые могут встретиться в трассиров- трассировках сетей. Таблица 3.2. Типы пакетов IPX/SPX Тип пакета NLSP Информация маршрутизации Объявление службы Упорядоченный NCP Распространенный Значение поля (шестнадцатеричное) 0x00 0x01 0x04 0x05 0x11 0x14 Назначение Пакеты NLSP Пакеты RIP Пакеты SAP ¦<<¦.'' Пакеты SPX Пакеты NCP NetBIOS и другие распространяемые пакеты
94 ' Глава 3 Сеть назначения Сеть назначения является номером сети, к которой присоединен узел назначения. Когда посылающий компьютер задает это поле как 0x0, предполагается, что узел назначения находится в том же сетевом сегменте, что и посылающий узел. Существует особый случай, когда рабочая станция посылает широковеща- широковещательные запросы протоколов маршрутизации SAP — Get Neareast Server (Найти ближайший сервер) и RIP — Get Local Target (Найти локального по- получателя) (или Route Request — Запрос маршрута) во время инициализации. Так как рабочая станция еще не знает, к какой сети принадлежит, она задает поля сети источника и сети назначения как 0 для этих запросов. Когда марш- маршрутизатор получает один из этих запросов, он посылает ответ непосредст- непосредственно посылающей рабочей станции, заполняя поля сети источника и сети назначения соответствующими сетевыми номерами. ¦ ¦ f , . . ¦. ¦ ' , ' ВНИМАНИЕ! IPX не имеет номера сети широковещания (такого как OxFFFFFFFF). В дополнение к сетевому номеру 0 номера OxFFFFFFFF и OxFFFFFFFE зарезервированы для специальных целей. В связи с этим они не должны назначаться никакой сети IPX. Дополнительную информацию о зарезер- зарезервированных сетевых номерах можно найти ниже в разделе о зарезервиро- зарезервированных номерах. ¦"'¦ ¦ ¦' Узел назначения Поле узла назначения содержит физический адрес узла назначения. Узел в сети Ethernet будет использовать все шесть байтов этого поля для определения своего адреса. Некоторые другие методы до- доступа к сети могут использовать здесь меньше шести байтов. Адрес узла OxFFFFFFFFFFFF (т.е. шесть байтов по OxFF) посылает пакет всем узлам в сети назначения. . • ¦ • ¦ . . Сокет назначения Поле сокета назначения является адресом сокета процесса назначения пакета. Эти сокеты будут направлять пакеты в различ- различные процессы внутри одной машины. _ . . .¦ Л" f . . I" ВНИМАНИЕ! IPX не имеет широковещательного номера сокета (например, OxFFFF). Сеть источника Поле сети источника является номером сети, к кото- которой присоединен узел источника. Если посылающий узел задает это поле равным нулю, это означает, что локальная сеть машины источника неизве- неизвестна. Для маршрутизаторов правила, применяемые к полю сети назначе- назначения, также применимы к полю сети источника, за исключением того, что маршрутизаторы могут пересылать полученные пакеты, у которых это поле задано как ноль. Узел источника Поле узла источника — это адрес MAC узла источника. Адреса широковещания недопустимы.
Стек протоколов SPX/IPX 95 Сокет источника Сокет источника — это адрес процесса, передающе- передающего пакет. Процессам, общающимся при равноправном соединении узлов, не требуется посылать и получать один и тот же номер сокета. В сети рабо- рабочих станций и серверов сервер обычно "ожидает" на определенном сокете запросы на обслуживание. В таком случае сокет источника не обязательно тот же самый или вообще имеет значение. Важно только, чтобы сервер от- ответил сокету источника. Например, все файловые серверы NetWare имеют один и тот же адрес сокета, но запрос к ним может исходить из сокета с лю- любым номером. Номера сокетов источников следуют тем же соглашениям, что и сокеты места назначения. Заголовки протоколов более высокого уровня Заголовки протоко- протоколов более высокого уровня принадлежат таким Протоколам, как NCP или SPX. Они часто встречаются в части данных пакета IPX. Адресация IPX Теперь рассмотрим адресацию IPX. Как показано в таблице 3.3, IPX имеет свою собственную адресацию узлов (для внутрисетевой работы) и внутриуз- ловую адресацию. Для адресации узла IPX использует адрес MAC, который был присвоен карте сетевого интерфейса производителем самой карты. Таблица 3.3. Структура Сетевой номер 00000001 адреса IPX Адрес MAC 006008A1D4B4 Номер 435 сокета обработки Сетевой адрес IPX уникальным образом идентифицирует сервер IPX в сети IPX и отдельные процессы внутри сервера. Адрес IPX является 12-бай- 12-байтовым шестнадцатеричным числом, которое можно разделить на три части. Первая часть адреса IPX — самая длинная, это шестибайтовый аппаратный адрес сетевого адаптера. Последняя часть является двухбайтным номером сокета, который используется для ссылки на реальный выполняющийся на машине процесс. В таблице 3.3 показано, как выглядит этот адрес. Каждый номер в адресе IPX содержится в поле в заголовке IPX и представ- представляет сеть источника или места назначения, узел или сокет. Сетевой номер ис- используется только для операций сетевого уровня, а именно, маршрутизации. Номер узла используется для локальной (или в том же сегменте) передачи пакетов. Номер сокета направляет пакет в процесс, действующий внутри узла. Каждый адресный компонент описывается в следующих разделах. Сетевой номер Четырехбайтовый шестнадцатеричный адресный сетевой номер IPX испо- используется для маршрутизации пакетов IPX. Каждому сегменту присваивается уникальный сетевой номер, используемый маршрутизатороми для пере- пересылки пакетов к их конечному месту назначения в сети.
96 Глава 3 Сетевой номер IPX может содержать до восьми цифр, включая нули, хотя ведущие нули обычно не выводятся. Например, 0x00003001, 0x12345678 и 0хВ9 являются действительными сетевыми номерами. Зарезервированные сетевые номера Сеть назначения пакета IPX является обычно сетью IPX, которой был при- присвоен уникальный сетевой номер. Однако три сетевых номера: 0x0, OxFFFFFFFF и OxFFFFFFFE зарезервированы, так как они имеют специальные значения. В таблице 3.4 перечислены эти номера. Таблица 3.4. Зарезервированные сетевые номера Номер Значение 0x00000000 Локальный сетевой сегмент. Когда маршрутизатор получает .. .. пакет с идентификатором сети назначения равным О, то источник и место назначения считаются находящимися в одном сегменте. OxFFFFFFFF Это пакет запроса всех маршрутов. Когда маршрутизатор получает пакет с идентификатором сети назначения равным FFFFFFFF, он сообщает все маршруты, о которых знает. OxFFFFFFFE Это используемый по умолчанию маршрут, который является местом назначения для всех пакетов IPX, которые имеют неизвестную сеть назначения. RIP и NLSP распознают OxFFFFFFFE как используемый по умолчанию маршрут. В сети RIP маршрутизатор RIP, который соединяет LAN с большей сетевой инфраструктурой, такой как корпоративная магистраль, обычно объявляет используемый по умолчанию маршрут. Внутренний сетевой номер Службы Microsoft для NetWare, а также серверы NetWare 3.x и 4.x использу- используют внутренний сетевой номер. Этот шестнадцатеричный номер должен быть длиной от одной до восьми цифр. Обычно он присваивается при уста- установке. Внутренний сетевой номер используется для служб и маршрутизации пакетов IPX в физических сетях. Номер узла Номер узла является шестибайтовым шестнадцатеричным числом, исполь- используемым для уникальной идентификации устройства в среде IPX. Это число идентично физическому адресу платы сетевого интерфейса, который сое- соединяет устройство с сетью. Заголовок IPX содержит поля узла назначения и узла источника. Посколь- Поскольку номера узлов являются такими же, как адреса сетевой интерфейсной пла- платы, эти поля содержат такие же адреса места назначения и источника, как находящиеся в заголовке MAC. Например, рабочая станция, выполняющая IPX/SPX, использует адрес узла назначения для определения места и пере- пересылки пакетов другой рабочей станции в том же сетевом сегменте.
Стек протоколов SPX/IPX 97 Номер узла IPX должен быть уникальным в том же сетевом сегменте. На- Например, узел в сети 3001 может использовать номер 006008A1D4B4, а узел в сети 3002 также может использовать номер 006008АШ4В4. Это действует так же, как протокол IP, потому что адрес хоста может совпадать в различ- различных сетях IP. Поскольку каждый узел имеет отличный сетевой номер, IPX распознает каждый узел, как имеющий законный уникальный адрес. Номер сокета • Двухбайтовый шестнадцатеричный номер сокета идентифицирует место назначения процесса внутри узла. Это может быть нечто вроде маршрути- маршрутизации (RIP) или объявления (внутри устройства SAP). Так как обычно одно- одновременно действуют несколько процессов, номер сокета обеспечивает что-то вроде "почтового ящика", используемого каждым процессом для идентификации себя для IPX. Когда процессу требуется коммуникация в сети, он запрашивает номер сокета. Все пакеты, полученные IPX и адресованные сокету, пересылаются затем процессу. Номера сокетов предоставляют быстрый метод маршрути- маршрутизации пакетов в узле. Это работает таким же образом, как сокеты Windows или номера портов TCP/IP. Они являются логическими местами назначе- назначения на удаленной машине для межпроцессной коммуникации. В таблице 3.5 перечислены некоторые номера сокетов и процессы, встречающиеся обычно в достаточно активных сетях. Таблица 3.5. Общеупотребительные номера сокетов IPX/SPX и процессы Номер сокета 0x451 0x452 0x453 0x455 0x456 0x9001 0x9004 Процесс NCP SAP RIP Novell NetBIOS Диагностика NLSP Протокол IPXWAN Сокеты под номерами между 0x4000 и 0x7FFF являются динамическими; они создаются в ходе работы, когда рабочей станции понадобится коммуни- коммуникация с файловым сервером или другими сетевыми устройствами. Сокеты под номерами между 0x8000 и OxFFFF являются общеупотребительными; Novell присваивает их определенным процессам. Например, 0x9001 является номером сокета, который идентифицирует NLSP. Разработчики програм- программного обеспечения, пишущие приложения NetWare, могут контактировать с Novell для выяснения общеупотребительных сокетов.
98 >¦ - ••<¦¦ Глава 3 Как работает маршрутизация IPX "''.;'! Когда соединяются различные сетевые сегменты IPX, инструкции для мар- маршрутизации пакетов между этими сегментами приходят из протокола IPX. IPX выполняет эти функции уровня 3 с помощью RIP, SAP и NLSP. Если две рабочие станции находятся в одном сетевом сегменте, посыла- посылающая рабочая станция посылает пакеты прямо по физическому адресу ра- рабочей станции назначения (т.е. по адресу MAC). Если две рабочие станции находятся в двух различных сетевых сегментах, то первая рабочая станция должна найти маршрутизатор в своем собственном сегменте, который зна- знает, как переслать пакеты внешнему сегменту. Чтобы найти этот крайне важный маршрутизатор, рабочая станция бу- будет посылать широковещательный пакет RIP, запрашивающий самый быст- быстрый маршрут к сегменту назначения. Маршрутизатор того же сегмента с самым коротким путем к сегменту назначения ответит на запрос. В пакете ответа маршрутизатор включит в заголовок IPX свой собственный сетевой и узловой адрес. Очевидно, что если посылающим узлом является маршрутизатор, а не ра- рабочая станция, то ему не нужно будет посылать широковещательное сообще- сообщение RIP, чтобы получить эту информацию. Вместо этого маршрутизатор берет информацию из внутренней таблицы маршрутизации. Когда посылающая рабочая станция получит адрес маршрутизатора, она посылает пакеты рабочей станции назначения, помещая полный адрес IPX места назначения (т.е. сеть, узел и номер сокета) в поле места назначения заголовка IPX, как это было показано ранее в этой главе. Затем посылающая рабочая станция помещает свой собственный полный адрес IPX в соответствующее поле источника заголовка IPX. Посылающая рабочая станция заполнит также все другие поля в заголовке. Например, она поместит адрес узла маршрутизатора, который ответил на запрос RIP в поле адреса места назначения заголовка MAC. Она поместит свой собственный адрес в поле адреса источника заголовка MAC. Посылающая рабочая станция отправляет, наконец, пакет маршрутиза- маршрутизатору, который должен теперь выполнить несколько задач. В первую оче- очередь маршрутизатор просматривает поле контроля транспорта заголовка пакета IPX. Маршрутизатор RIP будет отбрасывать пакет, если это поле бо- больше 16. Маршрутизатор NLSP будет отбрасывать полученный пакет, если это число больше, чем ограничение числа переходов. После этого маршрутизатор проверяет поле типа пакета заголовка IPX. Если он видит в этом поле 20 @x14), это указывает на пакет NetBIOS. Он должен также посмотреть поле контроля транспорта. Если это значение равно восьми или больше, маршрутизатор отбрасывает пакет, так как пакет NetBIOS ограничен восьмью переходами (или сетями). Затем маршрутизатор сравнивает сетевой номер в пакете с сетевым но- номером сегмента, в который прибыл пакет. Если маршрутизатор обнаружит совпадение, то он отбрасывает пакет, чтобы избежать зацикливания. Если сетевой номер не совпадает, то он помещает сетевой адрес в следующее до- доступное поле сетевого номера. Он увеличивает поле контроля транспорта и посылает пакет всем напрямую соединенным сетевым сегментам, кото- которые не присутствуют в полях сетевых номеров.
Стек протоколов SPX/IPX 99 Теперь маршрутизатор проверяет поля адреса назначения, чтобы опреде- определить, как направить пакет. Если пакет адресован маршрутизатору, соответст- соответствующий процесс сокета обработает его внутренне; иначе маршрутизатор пересылает пакет. В дополнение к пакетам, непосредственно адресованным маршрутизатору, он должен также иметь дело с OxFFFFFFFFFFFF, которые обычно являются пакетами RIP, SAP или диагностики. Если пакет необходимо переслать, маршрутизатор помещает адрес мес- места назначения из заголовка IPX в поле адреса места назначения заголовка MAC. Затем маршрутизатор помещает свой собственный адрес в поле адре- адреса источника заголовка MAC, увеличивает поле контроля транспорта заго- заголовка IPX и пересылает пакет в сегмент назначения. Если, однако, поле контроля транспорта равно максимально допустимому числу переходов до того, как поле будет увеличено, маршрутизатор отбрасывает пакет. Для маршрутизаторов RIP это число равно 16, для маршрутизаторов NLSP это ограничение задается в диапазоне от 8 до 127. Широковещательные пакеты никогда повторно не посылаются в сетевые Сегменты, из которых они были получены. Если маршрутизатор не связан напрямую с сегментом, в котором находится узел конечного места назначе- назначения, он посылает пакет следующему маршрутизатору на пути к узлу назначе- назначения, помещая адрес узла следующего маршрутизатора в поле адреса места назначения заголовка MAC. Маршрутизатор берет эту информацию в своей информационной таблице маршрутизации и затем помещает адрес своего собственного узла в поле адреса источника заголовка MAC, увеличивает поле контроля транспорта в заголовке IPX и пересылает пакет следующему маршрутизатору. " ' ¦--,<¦-¦-¦• NCP Каждый NCP известен прежде всего по своему номеру, который состоит из трех полей. Например, номер для изменения пароля объекта связывания равен 0x2222 23 64. • Первое двухбайтовое поле x2222" является полем категории службы. • Второе число 3" является номером функции, который идентифицирует, где в таблице коммутации существует базовая функция. • Третье поле 4" идентифицирует специальную функцию NCP, которая выполняется. Номера NCP делятся на широкие функциональные категории. Напри- Например, большинство функций номера 23 являются NCP учета, связывания, со- соединения или файлового сервера. В таблице 3.6 перечислены некоторые из категорий служб NCP. Категория NCP запроса службы @x2222) и категория NCP ответа служ- службы @x3333) используются наиболее часто. Существуют две категории служб, которые не требуют создания пакетов ответа службы @x3333). Это разрушение служебного соединения @x5555) и запрос разбиения пакета @x7777). •
100 Глава 3 Таблица З.б. Категории служб NCP Номер NCP Категория службы 0x1111 , Создать служебное соединение 0x2222 Запрос службы . . ,; 0x3333 Ответ службы 0x5555 Разрушить служебное соединение 0x7777 ; - ¦ Запрос разбиения пакета 0x9999 Предыдущий запрос все еще обрабатывается (занят) Если клиенту посылается сообщение, что предыдущий запрос все еще обрабатывается @x9999), это означает, что клиент сделал другой запрос или снова послал тот же запрос, в то время как сервер все еще обрабатывает последний, сделанный тем же клиентом, запрос. Клиент посылает через соединение с сервером сообщение, которое со- содержит все параметры NCP, используя сетевой протокол, например IPX. Сервер выполняет процедуру и возвращает результаты клиенту. Каждое до- дополнительное сообщение увеличивает идентификационные номера в паке- пакете. Когда от клиента получен запрос NCP, создается ответ NCP. Это протокол, действующий по принципу один запрос — один ответ. Интерфейсы сеансов и дейтаграмм NCP разрешает клиенту общаться с сервером с помощью системы доставки сообщений, например IPX или SPX. SPX имеет преимущество, поддерживая упорядочивание и гарантированную доставку сообщений. Если понадобится, то может запрашиваться IPX, с целью улучшения производительности. Он предлагает преимущество использования низкоуровневого ненадежного ин- интерфейса дейтаграмм, такого как IPX. Кроме того, дейтаграммы предлагают перенос NCP в сети, где стандартные интерфейсы сеанса не существуют. В настоящее время большинство клиентов ограничены не более чем од- одним ожидающим запросом NCP для каждого соединения. Однако между двумя компьютерами может существовать несколько соединений. Если кли- клиент пользуется мультипользовательской системой, каждый пользователь может иметь отдельное соединение с сервером, а каждому соединению разрешено иметь ожидающий запрос NCP. Так как система безопасности доступа к серверу определяется на основе каждого соединения, то для нескольких задач принято использовать общее единственное соединение. При необходимости для каждой задачи могут быть созданы новые соединения в мультизадачной среде. Каждое новое со- соединение интерпретируется как отдельная сущность, несмотря на физиче- физическую машину, которая осуществляет соединение. Таким образом, клиент может поддерживать столько соединений с различными серверами, сколько потребуется.
Стек протоколов SPX/IPX 101 Структуры заголовка сообщений Посмотрим теперь на сообщение NCP. Сообщение NCP содержит семи- байтный заголовок запроса, за которым следует восьмибайтный заголовок ответа. Заголовок запроса содержит общую статусную информацию о те- текущем состоянии соединения и указывает требуемую службу, как показано в таблице 3.7. Таблица 3.7. Заголовок запроса сообщения NCP . Смещение Тип Содержимое Описание 0 Слово Байт Байт Байт Байт Requesttype @x2222) - Тип запроса Sequencenumber (последний номер последовательности +1) Порядковый номер ConnectionNumberLow (служебное_соединение) ¦ Номер соединения — меньший TaskNumber (текущий_номер_задачи) Номер задачи ConnectionNum- berHigh(oiy}Ke6Hoe_ соединение) — Номер соединения — больший Поле категории службы Порядковый номер охватывающего сообщения. Когда посылается запрос создания служебного соединения, это поле задается равным нулю. Последующие запросы его увеличивают. Служебное соединение, возвращаемое сервером при ответе на запрос создания служебного соединения. Это -* поле равно нулю при первом запросе. Это клиентская задача, которая запрашивает службу. Сервер отслеживает, какие задачи открывают файлы, и блокирует данные, чтобы освободить эти ресурсы, когда задача завершается. 255 задач могут совместно использовать одно соединение. Задача 0 зарезервирована для конца задачи. Возвращается сервером в ответ на создание запроса служебного соединения. При первом запросе равно 0. Заголовок ответа содержит требуемые параметры для удаленного выполнения процедур. Его структура показана в таблице 3.8. Проверяйте флаги состояния соединения всякий раз, когда получен от- ответ службы. Если бит 4 задан как 1, то соединение службы было, вероятно, прекращено на стороне сервера.
102 Таблица 3.8. Смещение Параметры,требуемые для Тип Содержимое удаленного выполнения Описание Глава 3 процедур Слово ReplyType@x3333) — Поле категории службы Тип ответа Байт Байт Байт Байт Sequencenumber (номер_последовате- льности_запроса) — Номер последовательности ConnectionNumber- Ьо-Цслужебное соеди- соединение) — Номер соединения — меньший Байт Sequencenumber Номер последовательности охватыва- охватывающего сообщения. Когда посылается запрос создания служебного соедине- соединения, это поле задается равным нулю. Последующие запросы его увеличивают. Служебное соединение, возвращаемое сервером при ответе на запрос создания служебного соединения. Это поле равно нулю при первом запросе. Это клиентская задача, которая запра- запрашивает службу. Сервер отслеживает, какие задачи открывают файлы, и бло- блокирует данные, чтобы освободить эти ресурсы, когда задача завершается. 255 задач могут совместно использовать одно соединение. Задача 0 зарезерви- зарезервирована для конца задачи. ConnectionNumber- Возвращается сервером в ответ High(oi}OKe6Hoe на создание запроса служебного соединение) — Номер соединения. При первом запросе соединения — больший равно 0. Байт CompletionCode(KOfl) — Код завершения, возвращаемый номер задачи) — Номер задачи Код завершения ConnectionStatusFlags (Флаги_состояния) — Флаги состояния соединения сервером. Он является частью ответа на запрос службы клиентскими машинами. Любое число, отличное от 0, указывает на ошибку, произошедшую во время обслуживания запроса. Когда это происходит, остальная часть ответа сервера не возвращается. Битовое поле, возвращаемое сервером как часть заголовка его ответа на запрос службы клиентом. Биты имеют следующие значения: 0 Плохое служебное соединение 2 Нет доступного соединения 4 Сервер выключен 6 Сервер хранит широковещательное сообщение
Стек протоколов SPX/IPX 103 Обзор главы , „1 В этой главе был рассмотрен пакет протоколов IPX/SPX и показано, где он действует в модели OSI. Обсуждалась структура пакета, адресация IPX и проведено сравнение со структурой TCP/IP и Ethernet. Была рассмотрена роль сетевого номера и зарезервированного сетевого номера. Были иссле- исследованы номера узлов и номера сокетов, а также выполнение маршрутиза- маршрутизации в IPX. В завершение мы рассмотрели структуру заголовков сообщений. В следующей главе В следующей главе будут рассмотрены блоки сообщений сервера. Мы уви- увидим, как они действуют, как определяются имена серверов и как они разре- разрешаются. Будет проанализировано согласование диалекта, создание соединения и исследовано, как они работают с клиентами нижнего уровня. Подробно рассмотрим настройки сеанса, управления соединением, а также блокировки. .
Глава 4 Блоки сообщений сервера Протокол блоков сообщений сервера (SMB — Server Message Blocks) являет- является рабочей лошадкой мира Windows NT и Windows 2000. Он используется между компьютерами для общего доступа к файлам, принтерам, последова- последовательным портам и для коммуникационных абстракций, таких как имено- именованные каналы и почтовые ящики. SMB является клиент-серверным протоколом типа запрос-ответ. Протокол SMB превратился в общую файловую систему Интернета (Common Internet File System, CIFS). CIFS предоставляет межплатформен- межплатформенный механизм клиентских систем для запроса служб файлов и печати на серверных системах. Он поддерживает файлы и печать, используя коман- команды доступа open (открыть), close (закрыть), read (читать), write (писать) и seek (искать). Кроме того, он поддерживает доступ к файлам и записям как в блокированном, так и в неблокированном режиме. Когда приложение блокирует файл, ему не могут помешать другие приложения. Блокированные файл или запись недоступны не блокирующим приложениям. SMB предоставляет кэширование с опережающим чтением и с обратной записью. Это безопасные операции до тех пор, пока только один клиент имеет доступ к файлу. Кэширование чтения и оптимизация упреждающего чтения являются безопасными при доступе к файлу или в режиме только чтения. Если несколько клиентов пытаются одновременно записывать в файл, то ничто не будет безопасным; поэтому все файловые операции дол- должны управляться на сервере. SMB уведомляет обращающегося к файлу кли- клиента об изменениях в режиме доступа, чтобы клиент мог использовать оптимальный метод доступа. Приложения регистрируются для уведомления сервером об изменениях содержимого файла или каталога. Это позволяет приложению знать, когда обновить изображение, не требуя от него постоянно запрашивать сервер. Существует почти столько же различных версий протокола SMB, сколь- сколько и поставщиков программного обеспечения. Каждая версия предоставля- предоставляет дополнительные функции, свойства и средства. Чтобы справиться с
Блоки сообщений сервера 105 этим изобилием, SMB выполняет так называемое согласование диалектов. Когда два компьютера вступают в контакт, они согласовывают диалект или версию SMB, которая будет использоваться при их общении. Это критиче- критический шаг в терминах как производительности, так и безошибочной комму- коммуникации, так как каждый диалект может предоставлять различные сообщения, а также изменения в полях и семантике существующих сообще- сообщений других диалектов. В дополнение к обычным атрибутам файлов, напри- например, времени создания и модификации, такими приложениями, как Word могут добавляться другие элементы, чтобы включить, например, имя автора или описание содержимого. Протокол может поддерживать виртуальные тома, используя файловую систему, которая может охватывать несколько томов и серверов, но выгля- выглядеть при этом для клиентской машины как находящаяся на одном сервере. | Файлы и каталоги поддерева могут перемещаться на другие серверы, имена при этом изменять не придется. В этом случае не нужно будет делать изме- изменения на настольном компьютере, когда делаются изменения на сервере. Эти поддеревья могут также реплицироваться для выравнивания нагрузки и устойчивости к ошибкам. Когда клиент запрашивает файл, SMB использует направления для пересылки клиента на сервер, который содержит данные. Все это происходит за сценой без вмешательства клиента. SMB позволяет клиенту преобразовывать имена серверов с помощью DNS, WINS, LMHOSTS или любого другого механизма преобразования имен. Это перемещает нас из неструктурированного, "плоского" простран- пространства серверных имен в иерархически организованное пространство, под- поддерживающее более широкий диапазон взаимодействия. Чтобы сберечь полосу пропускания, SMB может пакетировать запросы в одном сообщении для минимизации задержки перемещения туда и обратно, даже когда более поздние запросы зависят от результатов предыдущих; он поддерживает также имена файлов в кодировке Unicode. Обзор работы SMB Для получения доступа к файлу на сервере клиентское приложение должно разобрать полное имя файла, чтобы определить имя сервера и относитель- относительное имя на этом сервере, разрешить имя сервера в адрес транспортировки, создать соединение с сервером и затем обменяться сообщениями. Если имя сервера было ранее разрешено, то оно может находиться в кэше, поэтому разрешение имени может не понадобиться. Кроме того, если предыдущее соединение все еще доступно, то новое соединение тогда не потребуется. Этот процесс повторяется множество раз в течение нормального рабочего дня. Если соединение простаивало в течение некоторого времени, оно будет разорвано. Определение имени сервера SMB достаточно развит, чтобы преобразовывать имя сервера множеством различных методов. Например, в URL file://prox/users/teresa/movies.xls клиент возьмет часть между двумя наклонными чертами и следующей
106 Глава 4 наклонной чертой в качестве имени сервера, а остальное будет интерпре- интерпретировано как относительное имя. В примере именем сервера будет PROX, а относительным именем USERS/TERESA/MOVIES.XLS. В имени пути доступа \\prox\users\ed\booksbymred.ppt клиент возьмет часть между ведущими двумя обратными наклонными чертами и следую- следующей обратной наклонной чертой в качестве имени сервера, а остальное как относительное имя. В этом примере именем сервера является PROX, а отно- относительным именем будет USERS\ED\BOOKSBYMRED.PPT. В пути доступа h:\booksbymred.ppt, клиент будет использовать "h" в ка- качестве индекса в таблице, которая содержит имя сервера и префикс имени файла. Если содержимое таблицы для h будет PROX и пользователь \ed, то имя сервера и относительное имя будут такими же, как и в предыдущем примере. Разрешение имени сервера Когда имя сервера было определено, следующий шаг состоит в разрешении имени. Должны существовать некоторые средства для разрешения имени сервера SMB в транспортный адрес. Сервер должен также регистрировать свое имя в службе разрешения имен, известной его клиентам. Это обычно либо WINS, либо DNS. Имя сервера можно также определить как строковую форму адреса IP в обычной десятичной нотации с точками, например 10.0.0.10. В этом случае "разрешение" состоит в преобразовании в 32-разрядный адрес IP. Тип используемого разрешения имени может накладывать ограничения на форму имени сервера. Например, для NETBIOS имя сервера должно быть меньше 15 символов верхнего регистра. Транспорт сообщения ; <;.<.•¦ рт Когда SMB использует надежный транспорт с поддержкой соединения, ему не нужно гарантировать упорядоченную доставку сообщений между клиен- клиентом и сервером. В этом вопросе он полагается на четвертый уровень (транспортный). Однако транспорт должен обнаруживать ошибки либо на клиентском, либо на серверном узле и сообщать о них программному обес- обеспечению, чтобы можно было сделать исправления. Когда надежное транс- транспортное соединение с клиентской стороны завершается, выполняющаяся работа и все открытые клиентом ресурсы закрываются. Транспорт сообще- сообщений выполняется с помощью службы сеанса NETBIOS. . ¦ .-_• ' ¦ 11' • ¦ ' ¦ Пример потока сообщений Типичная последовательность обмена сообщениями для клиента, соединен- соединенного с сервером уровня пользователя включает открытие файла, чтение из него данных, закрытие файла и разъединение с сервером (см. таблицу 4.1). Механизм пакетирования запросов CIFS (называемый механизмом "AndX") дополнительно позволяет объединять в одно до шести сообщений в этой по- последовательности, поэтому в действительности в этой последовательности существуют только три перехода туда и обратно, и последнее из них клиент может сделать асинхронно.
Блоки сообщений сервера Таблица 4.1. Поток сообщений SMB Клиентская команда 107 Ответ сервера SMB COM NEGOTIATE -г ¦¦¦:¦*• ¦Г ¦ Это первое сообщение, посылаемое клиентской машиной на сервер. Оно будет включать список диалектов SMB, поддерживаемых клиентской машиной. Когда сервер отвечает, он указывает, какой диалект SMB должен использоваться. SMB_COM_SESSION_SETUP_ANDX Передает серверу для проверки имя пользователя и полномочия. ...-•¦ ¦ Успешный ответ от сервера включает .. , идентификатор пользователя UID, который будет использоваться в последующих SMB от пользователя. SMB COM TREE CONNECT SMB COM OPEN SMB COM READ [ SMB_COM_CLOSE I SMB_COM_TREE_DISCONNECT Это имя общего диска, доступ к которому хочет получить клиент. Ответ сервера включает поле идентификатор тома TID, которое будет использоваться в последующих запросах. Этот кадр будет передавать имя файла, относительно TID, который хочет открыть клиент. Успех этой команды будет включать идентификатор файла FID, который должен использоваться для последующих операций на файле. Здесь клиент предоставляет TID, FID, смещение файла и число байтов для чтения. Когда эта команда успешно выполняется, сервер, очевидно, возвращает запрошенные данные. Клиент закрывает файл, представленный в кадре с помощью TID и FID. Сервер отвечает кодом успеха. Клиент разъединяется с ресурсом, представленным TID. Основная функция редиректора клиентской машины — форматирова- форматирование удаленных запросов таким образом, который будет понятен машине места назначения, и отправка их по сети. Редиректор использует структуру SMB в качестве стандартного средства перемещения для отправки и ответа на запросы редиректора. Каждый заголовок SMB содержит код команды (определяющий задачу, выполнение которой редиректор хочет поручить удаленной станции) и несколько полей окружения и параметров (которые
108 Глава 4 определяют, как команда должна выполняться). Кроме того, в заголовке SMB последнее поле в SMB может содержать до 64Кбайт данных, посылаемых на удаленную станцию. Read SMB (запрос) Команда read SMB (иногда называемая командой чтения диапазона байтов) приказывает серверу прочитать определенный диапазон байтов из дискового файла. Она также включает дескриптор фай- файла, число байтов для чтения и т.д. Сдвиг файла основывается на "указателе поиска", который хранится редиректором локально для файла. Серверный указатель поиска для этого дескриптора файла недействителен в данном случае, так как множество процессов удаленных рабочих станций могут обращаться к одному серверу, используя системный дескриптор файла. Параметр "est'd total" (оценка общего числа байтов для чтения, включая прочитанные этим запросом) является необязательным. Сервер может испо- использовать эту информацию для упреждающего чтения или для оптимизации выделения буферов. Read SMB (ответ) Ответ на Read SMB несет с собой запрошенные данные. Мультиплексный идентификатор (MID) помечает ответ SMB для соответст- соответствующего запроса SMB. . , Вот как работает этот процесс: • Программа посылает запрос ввода-вывода операционной системе через вызов интерфейса прикладного программирования (API). • Операционная система (или редиректор с помощью прерывания "int21") определяет, что запрос предназначен для удаленного ресурса, и передает его редиректору. • Редиректор форматирует запрос ввода-вывода как запрос SMB и посылает его по сети на сервер. • Сервер получает SMB и посылает запрос ввода-вывода локальной операционной системе сервера. • Сервер форматирует данные ответа SMB. Данные возвращаются, если выполнена операция чтения, или возвращается код, если выпол- выполнена операция записи. Сервер посылает их по сети запрашивающей рабочей станции. . • Редиректор передает ответ в операционную систему. • Операционная система передает ответ вызывающему приложению. Согласование диалекта Создание соединения После разрешения имени сервера в адрес IP необходимо создать соедине- соединение с сервером. Создание соединения делается с помощью примитива call служебного сеанса NETBIOS, который требует, чтобы клиент предоставил "вызывающее имя" и "вызываемое имя". Вызывающее имя не существенно в CIFS, за исключением того, что идентичное имя из того же транспортного
Блоки сообщений сервера 109 адреса считается принадлежащим тому же клиенту; вызываемое имя всегда равно "SMBSERVER". Через TCP примитив call приводит к отправке пакета "запрос сеанса" на порт 139. Обратная совместимость Если клиент CIFS хочет взаимодействовать с более старыми серверами SMB, он может повторить запрос с новым вызываемым именем, если вызов был отклонен сервером. Выбор нового имени зависит от типа используемо- используемого разрешения имени. Например, если используется DNS, вызываемое имя будет создаваться из первого компонента имени DNS сервера и затем об- обрезаться до 15 символов, если потребуется. Затем он будет дополнен до 16 символов с помощью символов пробела B0 hex). Если используется NETBIOS, то вызываемым именем является имя NETBIOS. Если это не ра- работает, то можно сделать запрос NETBIOS "Состояние адаптера", чтобы получить имя NETBIOS на сервере и повторить создание соединения. Настройка сеанса Сервер CIFS ДОЛЖЕН зарегистрировать NETBIOS Listen, который прини- принимает все вызывающие имена имени "*SMBSERVER". Кроме того, если он хо- хочет поддерживать более старых клиентов SMB, он может иметь имя NETBIOS и зарегистрировать также порт 139 для прослушивания этого имени. Управление соединением Правила для прекращения надежного транспортного соединения пере- перечислены ниже: • Если сервер получает от клиента запрос создания транспорта, с ко- которым он уже общается, сервер может прекратить все другие транс- транспортные соединения с этим клиентом. Это позволяет серверу восстановиться из ситуации, когда клиент внезапно перезагружается и не может аккуратно прекратить свои действия по использованию общих ресурсов сервера. • Сервер может прервать транспортное соединение с клиентом в лю- любое время, если клиент создает неправильно сформированные или нелогичные запросы. Однако по возможности сервер будет сначала возвращать клиенту код ошибки, указывая причину прерывания. • Если сервер получает тяжелую ошибку на транспорте (например, от- отказ передачи), то транспортное соединение с этим клиентом может быть прервано. • Сервер может прекратить транспортное соединение, если клиент не имеет на сервере открытых ресурсов.
110 Глава 4 Подпись SMB Windows NT 4 с Service Pack 3 включает усовершенствованную версию про- протокола аутентификации SMB, известную также как протокол совместного использования файлов общей системы файлов Интернета (CIFS). Мо- Модернизированный протокол имеет два основных усовершенствования. Он поддерживает взаимную аутентификацию, которая препятствует использо- использованию атаки "человек в середине", и поддерживает аутентификацию сообще- сообщений, что препятствует использованию атак активных сообщений. Механизм подписи SMB обеспечивает эту аутентификацию, помещая цифровую подпись безопасности в каждый SMB. Затем она проверяется клиентом и сервером. Чтобы использовать механизм подписи SMB, имеется две возможности: сделать возможным или потребовать ее использование на клиенте и на сер- сервере. Если подпись SMB сделана возможной на сервере, то имеющие воз- возможность клиенты будут использовать CIFS во время всех последующих сеансов. Преимущество такого подхода состоит в том, что клиенты, не име- имеющие возможности подписи SMB, смогут использовать более старый про- протокол SMB. Если на сервере требуется подпись SMB, то клиент не сможет создать сеанс, не будучи был специально инициирован для подписи SMB. Подпись SMB отключена по умолчанию на серверной системе при установ- установке служебного пакета (service pack). Она, однако, инициирована по умолча- умолчанию, когда служебный пакет устанавливается на системе рабочей станции. Примечание. Подпись SMB не будет работать с прямым протоколом хоста IPX. Это связано с тем, что прямой протокол хоста IPX изменяет SMB спо- способом, который несовместим с поддерживающим подпись SMB. Эта несо- несовместимость наиболее очевидна, когда используются прямые клиенты хоста IPX, и на сервере требуется подпись SMB. Требование на сервере подписей SMB не позволит серверу связываться с прямым интерфейсом хо- хоста IPX, что заставит подписать все соединения с сервером. Если отклю- отключить связывание NWLink с сервером, то можно будет использовать подпись SMB. Кроме того, подпись SMB будет снижать производительность системы. Хотя она не потребляет дополнительную полосу пропускания, но использует центральный процессор на клиенте и на сервере. .¦ . Оппортунистические блокировки Сетевая производительность увеличивается, если клиент может локально буферизовать данные файла. Это связано с тем, что клиент не должен запи- записывать информацию в файл на сервере, если знает, что никакой другой процесс не получает доступа к данным. Таким же образом клиент может бу- буферизовать данные опережающего считывания из файла, если знает, что никакой другой процесс не записывает данные. Оппортунистические блокировки, или oplocks, позволяют клиентам ди- динамически изменять их стратегию буферизации согласованным образом. Все версии SMB из LAN-MAN 1.0 способствуют поддержке oplocks.
Блоки сообщений сервера 111 Три различных вида оппортунистических блокировок перечислены ниже. 1. Исключающая oplock позволяет клиенту открыть файл для своего собственного персонального использования, чтобы выполнить произвольную буферизацию. 2. Пакетная oplock позволяет клиенту держать на сервере открытый файл, даже если локальное средство доступа (accessor) на клиентской машине закрыло файл. ., ,^.,кГ 3. Level II oplock позволяет нескольким машинам читать файл, если сре- среди них нет записывающих клиентов. Level II oplock поддерживаются в том случае, если согласованный диалект будет LM 0.12 или больше. Открыв файл, клиент запрашивает сервер задать на файле определен- определенную oplock. Ответ сервера указывает тип oplock, предоставленный клиен- клиенту, позволяя ему соответствующим образом настроить свою политику буферизации. SMB_COM_LOCKING_ANDX SMB используется для передачи информа- информации ответа и прерывания oplock. Рассмотрим каждый из этих механизмов блокирования более подробно. ..:( . ( .; ¦ • •,; •.-..,¦¦ ..ч-. .±j ,>ж .»; j; л .• ¦ ¦;;.¦ ¦:•:.¦• '¦. ¦ ¦ ¦ . ¦ /.. ¦¦ ¦ n.j.-l'i. -~i -, Исключающая oplock , ,;,¦ ., .. ¦ Л•.-!•¦.,.,[..¦ .„¦¦;>:•,;¦.¦ Когда клиенту предоставляется исключающая oplock, он может буферизи- ровать блокированную информацию, выполнять опережающее чтение и записывать данные на клиентской стороне общения, так как знает, что к файлу не будет других средств доступа. Это происходит следующим обра- образом. Редиректор на клиенте открывает файл, запрашивая для клиента oplock. Если файл открыт кем-то другим, клиенту отказывают в oplock, и на локальном клиенте никакой локальной буферизации выполняться не мо- может. Это означает также, что на файле не может выполняться никакого опережающего чтения, если только редиректор не знает, что он имеет бло- блокированный диапазон опережающего чтения. Если сервер предоставляет исключающую oplock, клиент может выполнить некоторую оптимизацию для файла, например блокирование буферизации, чтение и запись данных. Протокол исключающей блокировки oplock показан в таблице 4.2. Таблица 4.2. Работа исключающей блокировки oplock Клиент А Клиент В Сервер Открыть (Open) \\ coolfile-> -т-.i.:--.. ¦' * *>•'.-¦ '¦ '•¦ • ' • <-Открытие успешно. ¦ '¦¦'¦ •¦ : : i • Предоставлена исключающая ¦ • ¦ ¦¦¦¦.:¦¦ ' блокировка oplock Открыть (Open) \\ .' ' •;.""•' coolffle-> ' . ' ' ' Г. : ;lli~''¦ •¦'¦¦:'¦¦•'¦'•
112 Таблица 4.2. Клиент А Работа исключающей блокировки Клиент В oplock (продолжение) Сервер Глава 4 : [lfj; rj ,, .. .. ;> ,!,,.- Исключающая блокировка для клиента А не разрешает запись Блокировать (Locks)-> , ¦¦-., л!1.«.ч.-. ?'„ . . ¦.. , ¦, 4И ,.-..•¦¦,, <-ответ на блокировку Записать (Writes) -> . ' '• ""'.J:'.'-'' - Р ¦¦'¦ •(¦•'•¦¦¦: ; f''j i' » <-ответ на запись Закрыть или сделано-> ....,.- <- открыть ответ клиенту В Как можно видеть, когда клиент А открывает файл, он может запросить исключительную блокировку oplocks. Если больше никто не открыл этот файл на сервере, то oplock предоставляется клиенту А. Если в некоторый момент в будущем другой клиент, например клиент В, запрашивает откры- открытие того же самого файла, то серверу необходимо, чтобы клиент А прервал свою блокировку oplock. Прерывание oplock включает отправку клиентом А на сервер любых данных для записи или блокировки, которые он буфери- зировал, и затем уведомление сервера, что подтверждается отмена блоки- блокировки. Это синхронизирующее сообщение информирует сервер, что теперь допустимо разрешить клиенту В завершить открытие файла. Клиент А должен также стереть все буферы опережающего чтения, которые он имел для файла. .'А"!Г. :'. , ••¦!'¦¦ :. \<Y't- ¦ ' ' •¦¦'¦• Пакетная блокировка oplock Пакетная блокировка oplock используются там, где обычные программы на клиенте ведут себя таким образом, что объем сетевого трафика растет выше приемлемого уровня для предоставляемой программой функциональности. Например, командный процессор выполняет команды из командной процедуры, делая следующие шаги: • Открывает командную процедуру • Ищет "следующую строку" в файле <" • Считывает строку из файла , • Закрывает файл • Выполняет команду Этот процесс повторяется для каждой команды, выполняемой из файла командной процедуры. Очевидно, что это приводит к обработке множест- множества файлов, создавая тем самым сетевой трафик, который можно было бы сократить, если бы программа просто оставляла файл открытым, считывала строку, выполняла команду и затем считывала новую строку.
Блоки сообщений сервера 113 Пакетное блокирование действует именно так, позволяя клиентам про- пропускать излишние запросы открытия и закрытия (см. таблицу 4.3). Когда командный процессор запрашивает следующую строку в файле, клиент либо запрашивает сервер, либо уже имеет эти данные в кэше опережающе- опережающего чтения. В любом случае объем сетевого трафика клиента существенно сокращается. Если сервер получает запрос для переименования или удаления файла, который имеет пакетную блокировку oplock, он информирует клиента, что необходимо удалить oplock. Клиент затем переходит в режим открыть и закрыть, описанный ранее. Клиент А открывает файл и запрашивает oplock. Если никто не откры- открывал этот файл на сервере, то клиенту А предоставляется oplock. В приве- приведенном выше случае клиент А сохраняет файл открытым для своей вызывающей программы для нескольких операций открыть/закрыть. Дан- Данные могут читаться для вызывающей программы с опережением; может также использоваться и другая оптимизация, например буферизированная блокировка. Таблица 4.3. Работа протокола пакетной блокировки oplock Клиент А Клиент В Сервер Открыть \\coolfile -> i . Прочитать -> Закрыть Открыть Искать Закр Закрыть -> <- открытие успешно. Предоставлена пакетная блокировка oplock. <- данные Открыть \\coolfile -> Прочитать <- данные <- удаление блокировки oplock для клиента А <- закрытие успешно для клиента А * <- закрытие успешно для клиента В
If* ' ••¦ Глава4 Однако когда другой клиент запрашивает на сервере операцию откры- открытия, переименования или удаления файла, клиент А должен очистить свои буферизированные данные и синхронизироваться с сервером. В большин- большинстве случаев это включает закрытие файла при условии, что вызывающая программа клиента А считает, что она закрыла файл. Когда файл закрыт, может быть завершен запрос клиента В на открытие. ' v'¦'-'¦ :^{'~ Level II Oplocks ; ; '- <¦¦¦¦ ^ ;ч Блокировки Level П oplock позволяют нескольким клиентам иметь открытым один файл при условии, что ни один клиент не выполняет операций записи в файл. Это важно для сред со старыми машинами. Большинство открытий в режиме совместимости этих клиентов отображается в запрос открытия для совместно используемого доступа к файлу для чтения/записи. Однако помни- помните, что это может также отменять блокировки oplock для других клиентов, даже если ни один из клиентов в действительности не намерен писать в файл. Последовательность действий почти такая же, как у исключающей блоки- блокировки oplock (см. таблицу 4.4). Основное различие состоит в том, что сервер информирует клиента, что он должен прекратить блокировку Level II oplock, когда никто не пишет в файл. То есть клиент А, например, может открыть файл для желательного доступа READ и общего доступа READ/WRITE. Это означает, что клиент А не будет выполнять никаких записей в файл. Когда клиент В открывает файл, сервер должен синхронизироваться с клиентом А, если последний имеет какие-либо буферизованные блокиров- блокировки. Когда он синхронизируется, запрос клиента В на открытие может быть завершен. Клиент В, однако, информируется, что он имеет Level II oplock, а не исключающую блокировку oplock для файла. . .,. Таблица 4.4. Протокол Level II oplock Клиент А Клиент В Сервер Открыть \\coolfile -> <- открытие успешно. ' . .f¦ ¦.,.,Ki Исключающая блокировка oplock предоставлена. Прочитать -> <- данные Открыть \\coolfile -> <- прервать на Level II oplock для клиента А Блокировки -> ' ¦ ¦ <- ответ блокировок Сделано-> <-открытие успешно. Oplock II ' предоставлена клиенту В
Блоки сообщений сервера 115 В этом случае ни один клиент с блокировкой level II oplock на файле не сможет буферизировать какую-либо информацию блокирования на локаль- локальной клиентской машине. Это позволяет серверу гарантировать, что если вы- выполняется какая-либо операция записи, то ему необходимо только уведомить клиентов level II, что блокировка должна быть прервана, без необходимости синхронизации всех аксессоров (средств доступа) файла. Level II oplock может быть ПРЕРВАНА В НИКУДА (BROKEN TO NONE), означая, что некоторый клиент, открывший файл, выполнил теперь опера- операцию записи в файл. Так как ни один клиент level II не может создать ситуа- ситуацию блокирования буфера, то информация на сервере остается в согласованном состоянии. Записывающий клиент, например, не сможет за- записать в заблокированный диапазон по определению. Однако данные опере- опережающего чтения могут буферизироваться на клиентской машине, снижая тем самым объем сетевого трафика, требуемого файлу. Когда прерывается блокировка level II oplock, буферизирующий клиент должен очистить свои буферы и прекратить выполнение всех операций на файле через сеть. Ника- Никакого ответа на прерывание oplock от клиента не ожидается, когда сервер прерывает его из LEVEL II в NONE. Модель безопасности Каждый сервер делает доступными для клиентов в сети множество ресур- ресурсов. Ресурсом может быть дерево каталогов, именованный канал, принтер и т.д. Клиентская машина видит сервер как единственного поставщика файла или другого доступного ресурса, поэтому она не знает о каких-либо зависимостях от хранения или службы. Протокол CIFS требует аутентификации сервера пользователей, прежде чем будет разрешен доступ к файлу, и каждый сервер аутентифицирует сво- своих собственных пользователей. Клиентская система должна посылать ин- информацию аутентификации на сервер, прежде чем сервер разрешит доступ к своим ресурсам. Протокол CIFS определяет два метода, которые могут быть выбраны сервером для безопасности: общий уровень и уровень пользователя. Сервер общего уровня делает доступным некоторый каталог на дисковом устройстве (или другой ресурс). Для доступа может потребоваться допол- дополнительный пароль. Таким образом, любой пользователь в сети, знающий имя сервера, имя ресурса и пароль, получает доступ к ресурсу. Серверы с безопасностью общего уровня могут использовать различные пароли для одного и того же общего ресурса, где различные пароли предоставляют различный уровень доступа. Сервер уровня пользователя делает некоторый каталог на дисковом устройстве (или другой ресурс) доступным, но требует дополнительно, что- чтобы клиент предоставил имя и соответствующий пароль пользователя для получения доступа. Серверы уровня пользователя могут применить имя учетной записи и пароль, предоставленные клиентом. Серверы уровня пользователя предпочтительнее серверов общего уровня для любой новой серверной реализации, так как организации обычно считают, что сервер уровня пользователя легче администрировать. Серверы уровня пользователя
116 могут применять имя учетной записи для проверки списков контроля досту- доступа на отдельных файлах или иметь один список контроля доступа, который применяется ко всем файлам в каталоге. Когда сервер уровня пользователя проверяет имя учетной записи и па- пароль, предоставленные клиентом, идентификатор, представляющий этот аутентифицированный экземпляр пользователя, возвращается клиенту в поле Идентификатор пользователя (UID) ответного SMB. Этот UID дол- должен включаться во все последующие запросы, сделанные от имени пользо- пользователя с этого клиента. Сервер общего уровня не возвращает в поле UID никакой полезной информации. Модель безопасности на уровне пользователя была добавлена после вы- выпуска первоначального диалекта протокола CIFS, и, следовательно, некото- некоторые клиенты могут оказаться неспособными послать имена учетных записей и пароли на сервер. Сервер в режиме безопасности на уровне поль- пользователя, общающийся с одним из таких клиентов, будет позволять клиенту соединяться с ресурсами, даже если клиент не прислал информацию об имени учетной записи и пароле: .'",..' '' '"'¦ 1. Если имя компьютера клиента идентично имени учетной записи, из- известной на сервере, и если предоставленный пароль для соединения с общим ресурсом совпадает с паролем этой учетной записи, неявно будет выполнен "вход пользователя в систему" с помощью этих значе- значений. Если это не сработает, то сервер может отказать в запросе или присвоить используемое по умолчанию имя учетной записи по своему выбору. 2. Значение UID в последующих запросах клиента будет игнорировать- игнорироваться, и весь доступ будет проверяться в предположении имени учетной записи, выбранной выше. ' .•?¦;-.. ь :> ,.ч Пример доступа/общего ресурса Следующие примеры показывают интерфейс командной строки, позволяющий серверу предлагать дисковый ресурс, а клиенту соединяться и использовать этот ресурс. a) NETSHARE , . . Команда NET SHARE при выполнении на сервере определяет имя ка- каталога, который будет сделан доступным для клиентов в сети. Дол- Должно быть задано общее имя, которое предоставляется клиентам, желающим получить доступ к каталогу. Примеры: NET SHARE docs=c:\dirl\ ¦¦¦*' Делает общедоступными все файлы в каталоге C:\DIR1 и его подкаталогах с общим именем docs в качестве имени, используемого для соединения с этим ресурсом.
Блоки сообщений сервера 117 Ь) NET USE Клиенты могут получить доступ к одному или нескольким предлагае- предлагаемым каталогам с помощью команды NET USE. Когда посылается . команда NET USE, пользователь может свободно получить доступ к файлам без дополнительных специальных требований. Примеры: : NET USE: d: \\SERVER1\DOCS отображает диск d: в общедоступный каталог DOCS на сервере Server 1. Пользователь может теперь обраща- ''*¦" ться к файлам на SERVER! C:\DIR1, используя d:. Например, dir d: *.* выдаст список всех файлов на SERVER1 c:\dirl. NET USE * \\SERVER1\DOCS mycoolpwd отображает следующий доступный диск, который использует DOCS на serverl, защищенный *'>'-' паролем mycoolpwd. Для серверов уровня пользователя клиент обычно не должен предостав- предоставлять пароль с помощью команды NET USE. Если пользователю предлагается ввести пароль, обычно это указывает на сетевую проблему (например, он не может контактировать с контроллером домена, чтобы проверить полномо- полномочия). Этот сценарий предоставляет хорошую возможность проверить инст- инструменты сетевого мониторинга (см. часть IV). Сейчас можно попробовать проверить, существует ли проблема безопасности: NET USE * \\SERVERl\DOCS/USER:domainname\username password Клиентское программное обеспечение должно помнить идентификатор диска, поставляемый вместе с запросом NET USE, и связать его со значени- значением идентификатора дерева (TID), возвращаемого сервером в заголовке SMB. Последующие запросы, использующие этот TID, должны включать то- только имя пути доступа относительно присоединенного поддерева, так как сервер интерпретирует поддерево как корневой каталог (виртуальный ко- корень). Когда пользователь ссылается на один из удаленных дисков, клиент- клиентское программное обеспечение просматривает свой список дисков для этого узла и включает идентификатор дерева, связываемый с этим диском в поле TID каждого запроса. Отметим, что когда каталог объявляется общедоступным, будут затро- затронуты все файлы, лежащие под этим каталогом. Если определенный файл находится внутри области нескольких общих ресурсов, то соединение с любой из областей общих ресурсов получает доступ к файлу с полномочи- полномочиями, определенными для предложения, поименованного в NET USE. Сер- Сервер не будет проверять вложенные каталоги с более ограничительными полномочиями. Аутентификация Сервер CIFS хранит зашифрованную форму пароля клиента. Чтобы полу- получить аутентифицированный доступ к серверным ресурсам, сервер посыла- посылает вызов клиенту, на который клиент отвечает подтверждением, что он знает пароль клиента.
118 ' ' Глава 4 Аутентификация использует шифрование DES в блочном режиме. Функ- Функция шифрования DES, обозначенная как Е(К, D), получает семибайтный ключ (К) и восьмибайтный блок данных (D) и создает восьмибайтный за- зашифрованный блок данных в качестве своего значения. Если данные для шифрования длиннее восьми байтов, функция шифрования применяется к каждому блоку из восьми последующих байтов и результаты соединяются вместе. Если ключ длиннее семи байтов, то данные сначала полностью шифруются с помощью первых семи байтов ключа, затем следующие семь байтов и т.д., соединяя каждый раз результаты. Другими словами, чтобы за- зашифровать 16-байтовую величину D0D1 с помощью 14-байтового ключа К0К1: 1 '-;' Е(К0К1, D0D1) = Е(К0, DO)E(KO,D1)E(K1, DO)E(K1, Dl) Поле EnayptionKey (Ключ Шифрования) в ответе SMB_COM_NEGPROT со- содержит восьмибайтный вызов, обозначенный ниже как "С8", выбираемый уникальным, чтобы предотвратить атаки повторного воспроизведения. Кли- Клиент отвечает 24-байтовым ответом, обозначенным "Р24" и вычисляемым, как описано ниже. (Примечание. Имя "EncryptionKey" является историческим — оно на самом деле не содержит ключа шифрования.) Клиент посылает ответ на вызов в запросе SMB_COM_TREE_CONNECT, SMB_COM_TREE_CONNECT_ANDX и/или SMB_COM_SESSION_SETUP_ANDX, который следует за обменом сообщением SMB_COM_NEGPROT. Сервер дол- должен проверить ответ, выполняя те же вычисления, которые делает клиент при его создании, и проверить, что строки совпадают. Если строки не совпадают, то, возможно, клиентская система неспособ- неспособна шифровать; если это так, то строка может быть паролем пользователя открытым текстом. Сервер должен попробовать проверить строку, как если бы это был незашифрованный пароль. • vj Поле SMB, используемое для хранения ответа, зависит от ответа: ,,., Password ъ SMB_COM_TREE_CONNECT .-.- >у Password в SMB_COM_TREE_CONNECT_ANDX' ,,-., ..,. . ..,-. ,. ',_ Account Password в SMB_COM_SESSION_SETUP_ANDX (Примечание. Здесь имена также являются историческими и не отража- отражают это использование.) Содержимое ответа на вызов зависит от диалекта CIFS, как показано в следующих разделах. Поддержка распределенной файловой системы (DFS) Диалекты протокола NT LM 0.12 и более поздние версии поддерживают опе- операции распределенной файловой системы (DFS — Distributed File System). DFS предоставляет для этого протокола способ использования единствен- единственной согласованной схемы именования файлов, которая может охватывать совокупность различных серверов и ресурсов общего доступа. Модель DFS использует модель на основе направлений. Этот протокол определяет способ, которым клиенты получают направления. ¦
Блоки сообщений сервера < 119 Клиент может установить в заголовке запроса SMB флаг, указывающий, что клиент хочет, чтобы сервер разрешил в DFS пути доступа SMB, кото- которые известны серверу. Сервер пытается разрешить запрошенное имя в файл, содержащийся внутри локального дерева каталогов, указанного TID запроса, и затем нормально продолжить. Если путь доступа запроса раз- разрешается в файл на другой системе, то сервер возвращает следующую ошибку. STATUS_DFS_PATH_NOT_COVERED — сервер не поддерживает часть пространства DFS, требуемую для разрешения пути доступа в запросе. Клиент должен запросить на этом сервере направление для дополнительной информации. Клиент запрашивает направление с помощью запроса TRANS2-DFS- GETREFERRAL, содержащего интересующий путь доступа DFS. Ответ с сервера указывает, как клиент должен продолжить. Метод, с помощью которого топологическое представление DFS хранится и поддерживается серверами, не определен этим протоколом. г ЗаголовокБМВ ,а,:.,.,,_Л1,,,.., ..iiifI, ls, ,.^ZZ^ Хотя каждая команда SMB имеет определенное кодирование, в заголовке SMB есть несколько полей, которые имеют значение для всех SMB. Как можно увидеть в распечатке ниже, протокол SMB выполняется поверх NetBIOS, который переносится поверх TCP, реализованный поверх IP, ко- который реализован поверх метода доступ к среде Ethernet. Эти поля описаны в последующих разделах. ¦,:--¦ •-: '.;-¦..¦¦, у ' ¦¦' г-,- + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x414; Proto = TCP; Len: 82 + TCP: .AP len: 42, seq: 365595-354636, ack: 13582702, win: 8760, src: 1032 dst: 139 (NBT Session) + NBT SS: Session Message, Len: 38 .., ...,,¦.' SMB: С get attributes, File = ... ..',,,' " ' . '. { ' \ SMB: SMB Status = Error Success r,\ ; ' SMB: Error class = No error SMB: Error code = No error : : SMB: Header: PID = 0x2011 TID = 0x1002 MID = 0xC502 UID = 0x1003 SMB: Tree ID (TID) = 4098 @x1002) SMB: Process ID (PID) = 8209 @x2011) "' ' : SMB: User ID (UID) = 4099 @x1003) „ : ..-...• SMB: Multiplex ID (MID) = 50434 @xC502) ' SMB: Flags Summary = 0 @x0) SMB: 0 = Lock & Read and Write & Unlock not supported SMB: 0. = Send No Ack not supported SMB: ....0... = Using case sensetive pathnames '¦ SMB: . . .0. . . . = No canonicalized pathnames ¦' ! ':!' SMB: ..0 = No Opportunistic lock •'¦¦¦ ¦'•' • SMB: .0 = No Change Notify : "*¦ ..'•¦.¦¦•„\<] SMB: 0 = Client command -¦'¦¦'"]/{>. I -.¦¦'¦ SMB: flags2 Summary = 32768 @x8000) SMB: 0 = Understands only DOS 8.3 filenames SMB: 0. = Does not understand extended attributes
120 Глава 4 ;.;.,,. SMB: ... О = No DFS capabilities ,, .. SMB: ..0 = No paging of 10 ,.. SMB: .0 = Using SMB status codes ' SMB: 1 = Using UNICODE strings SMB: Commnad = С get attributes ' ' ' .-.¦¦.- SMB: Word count = 0 ¦' ' ;'¦'¦ .'¦'¦ •** •' ;: :' •• ' SMB: Byte count = 3 i"-':^'' ' •'¦¦¦'¦ '-''¦'- : ' ¦¦•¦'• ¦ ; '¦' ' SMB: Byte parameters ;•.....! ¦/ - ¦ SMB: File name = ,' • : ¦¦¦ ¦¦> ¦ ¦-" '•¦; i • ¦¦ •¦¦ .?cf-. Поле TID TID представляет экземпляр аутентифицированного соединения с сервер- серверным ресурсом. TID возвращается сервером клиенту, когда тот успешно сое- соединяется с ресурсом, и клиент использует TID в последующих запросах, ссылающихся на ресурс. Если сервер выполняется в режиме безопасности общего доступа, TID яв- является единственным объектом, используемым для разрешения доступа к об- общему ресурсу. Если пользователь способен выполнить успешное соединение с сервером, определяя подходящее сетевое имя и пароль (если требуется), ресурс может быть доступен согласно правам доступа, связанным с общим ресурсом (одинаковыми для всех, кто получает доступ таким образом). Полеию -i-.-- .-.:.¦ -• ¦ ¦••¦ ¦•¦.-..¦ '•:. • .¦-.<,.¦!•,;..¦.;,¦-. Если, однако, сервер выполняется в режиме безопасности на уровне поль- пользователя, доступ к ресурсу основывается на UID (проверяемом в запросе SMB_COM_SESSION_SETUP_ANDX), и TID НЕ связан с контролем доступа, но просто определяет ресурс (такой как общее дерево каталогов). В большинстве запросов SMB TID должен содержать допустимое зна- значение. Исключения до получения созданного TID включают SMB_COM_ NEGOTIATE, SMB_COM_TREE_CONNECT, SMB_COM_ECHO и SMB_COM_SESSION_SETUP_ANDX, где в таких ситуациях для TID должно использоваться значение OxFFFF. Сервер всегда отвечает за обеспечение использования действительного TID, где допустимо. ПолеРГО Идентификатор процесса (PID) уникальным образом определяет процесс клиента. Клиенты информируют серверы о создании нового процесса, просто вводя новое значение PID в диалог о новых процессах. В базовом протоколе использовалось сообщение SMB SMB_COM_ PROCESS_EXIT для указания катастрофического завершения процесса на клиенте. В однозадачной системе DOS было возможно возникновение тя- тяжелых ошибок, вызываемых разрушением процесса, с остающимися от- открытыми файлами. Поэтому в таком случае посылается сообщение SMB SMB_COM_PROCESS_EXIT, чтобы позволить серверу закрыть все файлы, открытые этим процессом. В LANMAN 1.0 и более новых диалектах не посылается никаких сообще- сообщений SMB SMB_COM_PROCESS_EXIT. Операционная система клиента
Блоки сообщений сервера 121 должна гарантировать, что будет послано соответствующее сообщение SMB закрытия и очистки, когда последний процесс, обращающийся к фай- файлу, его закроет. С точки зрения сервера не существует понятия идентифи- идентификатора файла (FID), принадлежащего процессу. FID, возвращаемый сервером одному процессу, может использоваться любым другим процес- процессом, использующим то же транспортное соединение и TID. Не существует SMB создания процесса, посылаемого серверу; клиент должен гарантиро- гарантировать, что только допустимые клиентские процессы получают доступ к FID (и TID). При получении SMB_COM_TREE_DISCONNECT (или когда сеанс сервера и клиента прекращается) сервер будет делать недействительными все файлы, открытые процессом на этом клиенте. Поле MID Клиенты, использующие LANMAN 1.0 и более новые диалекты, обычно яв- являются мультизадачными и допускают несколько асинхронных запросов ввода/вывода на задачу. Поэтому вместе с PID используется мультиплекс- мультиплексный идентификатор (MID), чтобы разрешить мультиплексирование одно- одного соединения клиента и сервера среди нескольких клиентских процессов, потоков управления и запросов потоков управления. Несмотря на согласованный диалект, сервер отвечает за обеспечение того, что каждый ответ содержит те же самые значения MID и PID, которые они запрашивают. Клиент может затем использовать значения MID и PID для связывания запросов и ответов и иметь в любое время согласованное количество ожидающих запросов для определенного сервера. Поле флагов Внимательнее рассмотрим первое из двух полей флагов, как показано в таб- таблице 4.5. Это поле содержит восемь отдельных флагов (используются толь- только семь), которые пронумерованы от самого младшего до самого старшего и имеют следующие значения: SMB: Flags Summary = 0 @x0) SMB: 0 = Lock & Read и Write & Unlock не поддерживаются SMB: 0. = Send No Ack не поддерживается SMB: ....0... = Использование имен путей доступа с учетом регистра символов SMB: . . .0. . . . = Отсутствие канонизированных имен путей доступа SMB: . .0 = Нет оппортунистической блокировки SMB: .0 = Нет Change Notify SMB: 0 = Клиентская команда ' :
122 Таблица Номер бита 4.5. Сводная таблица Значение первого поля флагов SMB Глава 4 Самый ранний диалект 0 Когда этот бит устанавливается на сервере в ответе LANMAN 1.0 SMB_COM_NEGOTIATE, он указывает, что сервер поддерживает Lock and Read; Write and Unlock. 1 Когда установлен этот флаг, клиент гарантирует, что существует объявленный получающий буфер, который ¦¦:' ¦ будет поддерживать Send без подтверждения. . . 2 Зарезервирован. Должен быть равен нулю. 3 Когда установлен этот флаг, имена путей доступа LANMAN 1.0 должны интерпретироваться с учетом регистра символов. Когда флаг сброшен, имена путей доступа не зависят от регистра символов. 4 Когда этот бит сброшен в ноль, не используется LANMAN 1.0 никаких канонизированных имен путей доступа. ¦¦;>, ;... . Когда этот флаг установлен в 1, имена файлов/ ,-....., .,, -¦-,,, v ; каталогов заданы в верхнем регистре, являются : , ...... т< допустимыми символами, и удалены; в качестве , 1 разделителей используются одиночные обратные косые черты. ...,^_Р^ _ тт,,,.г тт -. 5 Оппортунистическая блокировка — когда флаг LANMAN 1.0 установлен, клиент запрашивает, чтобы файл был оппортунистически заблокирован, если этот процесс у- ¦; •¦¦ ,;<ф \::^,, .-,. ¦ открывает файл только во время запроса открытия. Если сервер "удовлетворяет" запрос этой oplock, этот г бит должен оставаться заданным в соответствующем ответе SMB для указания клиенту, что запрос oplock был удовлетворен. 6 Change Notify указывает, что сервер должен LANMAN 1.0 уведомить клиента о любом действии другого клиента, которое может изменить файл (удалить, задать атрибут, переименовать и т.д.). Если этот бит не задан, то сервер должен уведомить клиента только о запросе другого клиента на открытие файла. 7 Client Command — установленный бит свидетельствует, PC Network что этот SMB послан с сервера в ответ на запрос program 1.0 клиента. Поле команды содержит обычно то же самое значение в запросе клиентом протокола у сервера, как и в соответствующем ответе от сервера клиенту. Это бит однозначно отличает запрос команды от ответа команды.
Блоки сообщений сервера 123 Поле Flags2 Это поле содержит шесть отдельных флагов, которые пронумерованы от самого младшего к самому старшему биту и определены в таблице 4.6. Фла- Флаги, которые не определены, должны быть заданы нулем. SMB: flags2 Summary = 32768 @x8000) SMB: 0 = Понимает только имена файлов DOS 8.3 SMB: 0. = Не понимает расширенные атрибуты : SMB: ... 0 = Не поддерживает DFS SMB: . . 0 = Без подкачки ввода-вывода SMB: .0 = Использует коды состояния SMB SMB: 1 = Использует строки UNICODE Таблица 4.6. Раздел SMB flags2 Биты Значение Самый ранний диалект 0 Если установлен в запросе, сервер может возвращать в ответе длинные компоненты в именах путей доступа. 1 Если установлен, то клиент знает о расширенных атрибутах. 12 ¦¦!. Если установлен, то запрос любого имени NTLM0.12 v ¦ I пути доступа должен быть разрешен в распределенной файловой системе. '•,•,,¦'.*¦'¦¦ 13 Если установлен, то этот флаг указывает, что чтение будет разрешено, если клиент не имеет . _ полномочия на чтение, но выполнил полномочие. . .,.,,.-.,.,. Имеет смысл только для запроса чтения. 14 Если установлен, то этот флаг определяет, что NT LM 0.12 возвращаемый код ошибки является 32-битным кодом ошибки в status.status. Иначе используется ¦•'¦¦ "•'¦ класс состояния doserror. Этот флаг должен устанавливаться при использовании кодов . состояния NT. , _. '_ 15 Когда этот флаг задан, поля STRING NT LM 0.12 записываются в кодировке UNICODE. Когда не задан, то поля STRING кодируются в ASCII. Поле состояния SMB возвращает клиенту информацию об ошибке в поле состояния, как показано ниже. Диалекты протокола до NT LM 0.12 возвращают клиенту состояние, используя комбинацию Status.DosError.ErrorClass и Status.DosEr- ror.Error. Начиная с NT LM 0.12 CIFS, серверы могут возвращать клиентам
124 Глава 4 32-битную информацию об ошибках с помощью Status.Status, если входящее сообщение клиента SMB в поле Flags2 заголовка SMB имеет заданным бит 14. Содержимое параметров ответа не гарантировано в случае возвраще- возвращения ошибки и должно игнорироваться. Последующая запись или закрытие файла могут возвращать сообщение о том, что предыдущая запись не про- прошла. Обычно отказ обратной записи ограничен ошибками жесткого диска и отсутствием свободной памяти устройства. SMB: SMB Status = Error Success SMB: Error class = No error SMB: Error code = No error Задержки Обычно блокирование сообщений SMB на сервере не ожидается, они дол- должны возвращаться "немедленно". Но некоторые запросы SMB указывают на периоды задержки для завершения запроса на сервере. Если реализация сервера не может поддерживать задержки, то сразу после запроса будет возвращаться ошибка, как если бы произошла задержка, потому что ресурс был недоступен. у.--.-*-.. .-:..,,,, < Буфер данных (BUFFER) и форматы строк Часть данных SMB обычно содержит данные, которые прочитаны или за- записаны, пути доступа файлов или пути доступа каталогов. Формат порции данных зависит от сообщения. Все поля в порции данных имеют один формат. В каждом случае оно состоит из байта идентификации, за которым следуют данные (см. таблицу 4.7). Таблица 4.7. Буфер данных и форматы строк Идентификатор Описание Значение Блок данных 1 Диалект ' ' Строка, заканчивающаяся нулем 2 ; Имя пути доступа Строка, заканчивающаяся нулем 3 ,. ASCII Строка, заканчивающаяся нулем 4 Блок переменной 5 Когда идентификатор указывает на блок данных или блок переменной, формат является словом, указывающим длину последующих данных. Во всех диалектах до NT LM 0.12 все строки кодируются в ASCII. Если согласованный диалект — NT LM 0.12 или более поздний, то может проис- происходить обмен строками в кодировке Unicode. Строки Unicode включают имена файлов, имена ресурсов и имена пользователей. Они применимы к строкам, заканчивающимся нулем, строкам, определяющим длину, и к стро- строкам с префиксом типа. Во всех случаях, где строка передается в формате Unicode, она должна быть выровнена по границе слова относительно нача- начала SMB. Если строка не попадает естественным образом на двухбайтовую
Блоки сообщений сервера 125 границу, то вставляется нулевой байт дополнения, а строка Unicode будет начинаться со следующего адреса. В описании SMB элементы, которые мо- могут кодироваться в Unicode или ASCII, помечены как STRING. Если исполь- используется кодирование ASCII, даже если согласованной строкой является Unicode, величина помечается как UCHAR. Для строк Unicode с префиксом типа дополнительный байт находится после байта типа. Байт типа равен четырем (указывая SMB_FORMAT_ASCH), независимо от того, является строка ASCII или Unicode. Для строк, началь- начальные адреса которых находят с помощью смещения внутри фиксированной части SMB (в противоположность просто находимым в байте, следующем за предшествующим полем), гарантируется, что смещение будет правильно выровнено. Строками, которые никогда не передаются в Unicode, являются: Строки протокола в запросе Negative SMB. Строки имени службы в Tree Connect And X SMB. В поле FLAGS2 каждого заголовка SMB должен быть установлен в 15 бит. Несмотря на гибкую схему кодирования, ни одна часть порции данных не может быть опущена или вставлена в не принятом порядке. Кроме того, нельзя опустить ни WORDCOUNT, ни BYTECOUNT со значением 0 в конце сообщения. Кодирование режима доступа Различные клиентские запросы и ответы сервера, такие как SMB_COM_OPEN, передают режимы доступа к файлу закодированными в USHORT. Кодирование осуществляется следующим образом: 1111 11 -;ii ' ¦'-¦' ¦''¦>'¦ <¦¦ ¦ ' 54321098 7654 3210 ' - " • rWrC rLLL rSSS rAAA • где: ¦ ¦ • '• - ' :'-' -i> ¦ ¦¦' ¦ : • W — Режим сквозной записи. Никакого опережающего чтения или по- последующей записи не допускается на этом файле или устройстве. Ког- Когда возвращается ответ, ожидается, что данные будут на диске или устройстве. • S — Режим общего доступа: 0 — Режим совместимости 1 — Отказ чтения/записи/выполнения (исключающий) .,. 2 — Отказ записи 3 — Отказ чтения/выполнения 4 — Отказа нет • А — Режим доступа •. , ...... 0 — Открыт для чтения , . . . , ,: 1 — Открыт для записи 2 — Открыт для чтения и записи 3 — Открыт для выполнения { rSSSrAAA =11111111 (hex FF) указывает, что FCB открыт (???)
126 "> Глава 4 ¦ :. ¦¦•' С — Режим кэширования > :< .. • у« ¦; > •¦¦'¦¦¦ - ¦'<! О — Обычный файл ¦ il .<. ищ•.¦ .. ¦ в 1 — Не кэшировать этот файл .'>--;•'• .и; 'Ьо.дг • L — Локальность ссылки ' ' 0 — Локальность ссылки неизвестна '"''**¦ 1 — В основном последовательный доступ *> '' 2 — В основном случайный доступ 3 — Случайный доступ с некоторой локальностью от 4 до 7 — В настоящее время не определены Кодирование функции открытия (Open) Функция открытия (Open) определяет действие, которое будет выполнено, в зависимости от того, существует файл или нет. Это слово имеет следующий формат: биты: * —" •?¦— -^-~-;V- -;-',: • :i.-.:::.'.': ': ¦.:.. '';v->.;:-? "гл ' "; ПИП ¦' t^*-r.i- l-''S-i-лп: ¦;¦,.,¦№,о.\,i л,,..¦, $?...i/.i I ¦¦•;->-\п 5432 1098 7654 3210 г .ч-¦,.'.•;«...••u(«*;.o.- ¦< ->г.ъ <>, Kli $H, ,i; .<>; о .и I ГГГГ ГГГГ ГГГС ГГОО "¦"' ¦''' ' I' '''' '¦ ¦'•'>•• '¦¦ '< >¦' .Я/'.Л .П I ,o ". -..is. ;.; где: • С — Create (Создать) (действие, которое будет выполнено, если файл не существует). , ... -. ,.. О — Отказ J.UI i , г >v til 1/ s"i« ! 'ч 1.Т! .'. ул1 I M •¦' 1 ' ' '¦ • >»''»! ¦..¦¦ 1 ' R : СИ[. . H Mi,; .1-, ¦ /U. 11!(. (¦.:>; л.-. •.;. 1 — Создать файл >.¦ м.-„и. .- i,u . , г _ Зарезервировано (должен быть ноль) : ': •¦•'"• -- " • О — Open (Открыть) (действие, которое будет выполнено, если файл существует). 0 —Отказ А- /•••¦['*•. '/¦"•¦ 1 — Открыть файл ¦ 2 — Отрезать файл ¦¦1!: . i«;i . : •!.-. /Ч - Кодирование действия открытия (Open) Действие в ответе на запрос открытия или создания описывает действие, предпринимаемое в результате этого запроса. Оно имеет следующий формат: биты: ЦП И . .. . ¦ .1.1 VMM, ..,:,-„.,,„.,.Г., ! • О 5432 1098 7654 3210 г>../,¦¦••,!¦ /ж .. ,; ->мш> «.:ч-т ;,...:¦¦ : Lrrr rrrr rrrr rrOO *'»:'": ( • L — Lock (Блокировка) (состояние блокировки одним пользователем всего файла). 0 — Файл открыт другим пользователем (или режим не поддерживает- поддерживается сервером) 1 — Файл в настоящее время открыт только этим пользователем г — Зарезервировано (должно быть ноль)
Блоки сообщений сервера 127 • О — Открыть (действие, предпринимаемое при открытии) . i^!....,; 1 — Файл существовал и был открыт 2 — Файл не существовал, но был создан ; - . " ''".' 3 — Файл существовал и был обрезан ; J А \'< • i Кодирование атрибутов файла ,< Когда сообщения SMB передают информацию об атрибутах файлов, она кодируется в 16 битах, как показано в таблице 4.8. Таблица 4.8. Атрибуты файлов Значение Описание 0x01 Файл только для чтения 0x02 , , ¦ • ¦. Скрытый файл ' ¦ ' ¦ ; 0x04 , ь . Системный файл 0x08 • ~ -Том- :--•• ¦¦-r- 0x10 Каталог ^^-'¦¦>¦ ?' .о}1 •< • -¦¦; j\¦. ,¦-^ 0x20 ., ¦':'.-¦,. Архивный файл Другие Зарезервированы. Должны быть заданы в 0 Кодирование расширенных атрибутов файла Расширенные атрибуты файла являются 32-битным значением, составленным из атрибутов и флагов. Допустима любая комбинация атрибутов, перечисленных в таблице 4.9, за исключением того, что все остальные атрибуты файла переопределяют FILE_ATTRIBUTE_NORMAL. Допустима любая комбинация флагов, перечисленных в таблице 4.10. Таблица 4.9. Расширенные атрибуты файла Атрибут Обозначение Описание FILE_ATTRIBUTE_ 0x020 Файл не был архивирован с момента ARCHIVE последней модификации. Используется прежде всего для целей резервного копирования. FILE_ATTRIBUTE_ 0x800 Файл или каталог являются сжатыми. COMPRESSED Для файла это означает, что данные в файле сжаты. Для каталога это означает, • ¦ • что атрибут сжатия установлен по умолчанию. Новые файлы будут сжаты. FILE_ATTRIBUTE_ 0x080 Никаких специальных атрибутов. NORMAL Действителен, только если используется один.
128 Глава 4 Таблица 4.9. Расширенные атрибуты файла (продолжение) Атрибут Обозначение Описание FILE_ATTRUBUTE_ 0x002 Файл является скрытым и не включается HIDDEN в обычный листинг каталога. FILE_ATTRIBUTE_ 0x001 Файл предназначен только для чтения. READONLY ¦ ¦ . <~ ¦ - Приложения могут читать, но не могут писать в файл или удалять файл. FIILE_ATTRIBUTE_ 0x100 Файл является временным файлом. TEMPORARY .,_ .... FILE_ATTRIBUTE_ 0x010 Идентифицирует каталог. Не является DIRECTORY файлом по существу. FILE_ATTRIBUTE_ 0x004 Файл является частью операционной SYSTEM системы или используется исключительно операционной системой. Пакетные запросы (Сообщения "AndX") LANMAN 1. 0 и более поздние диалекты протокола CIFS допускают переда- передачу на сервер нескольких запросов SMB в одном сообщении. Сообщения этого типа называются AndX SMB, они подчиняются следующим правилам: • Вложенные команды не повторяют информацию заголовка SMB. Вме- Вместо этого следующее сообщение SMB начинается на поле WordCount. • Все множественные (сцепленные) запросы должны соответствовать согласованному размеру передачи. Например, если было послано со- сообщение SMB_COM_TREE_CONNECT_ANDX, включающее SMB_COM_OPEN_ANDX, которое включает SMB_COM_WRITE, то все они должны соответствовать согласованному размеру буфера. Это будет ограничивать размер записи. • Существует одно посылаемое сообщение, содержащее сцепленные за- запросы, и одно сообщение ответа на сцепленные запросы. Сервер может НЕ посылать отдельные ответы на каждый из сцепленных запросов. • Все сцепленные ответы должны соответствовать согласованному раз- размеру передачи. Это ограничивает, например, максимальное значение вложенного SMB_COM_READ. Клиент не должен запрашивать больше байтов, чем может поместиться во множественном ответе. • Сервер неявно будет использовать результат первой команды в команде "X". Например, TID, полученный через SMB_COM_TREE_ CONNECT_ANDX, мог бы использоваться во вложенном SMB_COM_ OPEN_ANDX, a FID, полученный в SMB_COM_OPEN_ANDX, мог бы использоваться во вложенном SMB COM READ.
Блоки сообщений сервера 129 • Каждый сцепленный запрос может ссылаться только на тот же FID и TID, что и другие команды в комбинированном запросе. Сцепленные запросы могут рассматриваться как выполняющие одну (из нескольких частей) операцию на одном ресурсе. , • Первая КОМАНДА, встретившая ошибку, будет останавливать всю да- дальнейшую обработку встроенных команд. Сервер не будет возвращать команды, которые выполнились успешно. Поэтому, если сцепленный запрос содержал SMB_COM_OPEN_ANDX и SMB_COM_READ, и сер- н' вер смог успешно открыть файл, но чтение встретило ошибку, то по- после этого файл остался бы открытым. Это в точности то же самое, как * L если бы запросы были посланы раздельно. Таблица 4.10. Дополнительные флаги Атрибут Определение Описание FILE_FLAG_WRITE 0x80000000 JTHROUGH FILE_FLAG_NO_BU 0x20000000 FFERING FILE_FLAG_RAND 0x10000000 ОМ ACCESS FILE_FLAG_SEQUE 0x08000000 NTIAL SCAN FILE_FLAG_DELET 0x04000000 E_ON_CLOSE FILE_FLAG_BACKU 0x02000000 P_SEMANTICS I FILE_FLAG_POSIX_ 0x01000000 SEMANTICS Приказывает ОС выполнить сквозную запись всего промежуточного кэша и перейти вместо этого прямо к файлу. Не разрешает отложенную запись. Запрашивает сервер открыть файл без промежуточной буферизации. Это запрос, который сервер не обязан принять. Указывает, что приложение будет использовать файл в режиме случайного доступа. Сервер может использовать эту информацию для оптимизации кэширования файла. Указывает, что приложение будет получать доступ к файлу в последовательном режиме. Сервер может использовать этот флаг для оптимизации кэширования. Приказывает серверу удалить файл ,|,,, немедленно после того, как все ,,-¦ ;,' дескрипторы будут закрыты. Файл открывается для резервного копирования или операции восстановления. Сервер должен позволить переопределить параметры безопасности файла, если были получены соответствующие полномочия. Использовать правила Posix (допускают имена, зависимые от регистра символов).
130 " ' " Глава 4 Если при обработке сцепленных запросов возникает ошибка, то послед- последним (из сцепленных запросов в буфере) будет запрос, встретивший ошиб- ошибку. Другие необработанные сцепленные запросы будет проигнорированы, когда сервер встретит ошибку, и не будут представлены в сцепленном отве- ответе. В действительности последняя допустимая команда ANDXCOMMAND (если существует) будет представлять SMB, на котором встретилась ошиб- ошибка. Если нет действительной команды ANDXCOMMAND, то возникшая при первом запросе/ответе ошибка и COMMAND содержат отказавшую коман- команду. Во всех случаях информация об ошибке возвращается в заголовке SMB в начале буфера ответа. Каждый сцепленный запрос и ответ содержит смещение (с начала заго- заголовка SMB) к следующему сцепленному запросу/ответу (в поле AndXOffset в различных протоколах "and X", например, SMB_COM_OPEN_ANDX). Это позволяет создавать запросы распакованными. Между концом предыдуще- предыдущего запроса (как определено WordCount и ByteCount) и началом следующего сцепленного запроса может быть пробел. Это упрощает создание сцеплен- сцепленных запросов протокола. Отметим, что так как клиент должен знать размер возвращаемых данных, чтобы послать правильное число получений (на- (например, SMB_COM_TRANSACTION, SMB_COM_READ_MPX), данные в каждом ответе SMP ожидаются обрезанными до максимального числа 512-байтных блоков (секторов), которые будут соответствовать (начиная с 32-битной границы) согласованному размеру буфера с нечетным числом байтов, остающихся (если остаются) в конечном буфере. _ Обзор главы В этой главе был рассмотрен протокол SMB. Глава началась с обзора его ра- работы; было показано, как определяется имя сервера. Далее мы обсудили разрешения имен серверов и функцию транспортных сообщений. Подроб- Подробно было изучено согласование диалекта, создание соединения и способы, которые использует SMB для обратной совместимости. Затем обсуждались вопросы настройки сеанса, управления соединением и подпись SMB. Мы познакомились со всеми видами блокировок: исключа- исключающими блокировками oplocks, пакетными блокировками и блокировками oplocks level II. Затем была рассмотрена модель безопасности и пример, ис- использующий доступ к ресурсу и общий доступ. Затем мы рассмотрели реальную структуру заголовка SMB. Были показа- показаны MID, TID, PID, UID и FID, рассмотрены задержки, буферы данных и ко- кодирование режима доступа. Конец главы был посвящен созданию пакетов запросов в SMB. ¦¦;.v>-. y.iUK^-r.u ¦ ."км-Я1л< В следующей главе п Л Мы переходим ко второй части книги, посвященной сетевому трафику. Начнем обзор на клиентской стороне, а затем перейдем на серверную сто- сторону трафика.
ЧАСТЬ II Сетевой трафик Анализ и оптимизация: взгляд на проблемы G существует множество вещей, вовлеченных в выполнение анализа и опти- оптимизации сетевого трафика. Необходимо рассмотреть общение между маши- машинами, а также общий поток информации. В этом разделе мы "подслушаем " общение между компьютерами. Сначала будет рассмотрена коммуникация между клиентами и серверами. Затем мы послушаем, что говорят сами серве- серверы. Наконец, перейдем к методам, которые помогут нам выявить максимум полезной информации из этого "шума".
Глава 5 Клиентский трафик Этот раздел книги начинается с изучения клиентского трафика. В этой главе будут рассмотрены различные его источники: трафик, связанный с протоко- протоколами, трафик, связанный с поиском различных объектов в сети, и т.п. Затем обсудим способы сокращения трафика, которые обычно применяются в сетях. Мы приступим к анализу с момента первого включения клиентской машины, т.е. с того, где начинается клиентский трафик. Инициализация клиента i i Клиентские машины начинают генерацию трафика с того момента, как то- только они включаются, и они не прекращают создавать трафик, пока не бу- будут выключены физически. Так как задача состоит в оптимизации сети, необходимо просто определить, сколько трафика создают эти машины, и до какой степени можно было бы сократить этот трафик, если это вообще возможно. Итак, откуда поступает трафик, когда включают машину? Это за- зависит прежде всего от протокола, который выполняется на данной маши- машине. Для начала необходимо взглянуть на "типичную машину Windows 98", которая использует DHCP для присвоения адреса IP, WINS для разрешения имен NetBIOS и DNS для работы в Интернете. Сама машина не реализует никакого общего доступа к файлам или печати. Она конфигурируется для регистрации в домене Windows NT и не использует никаких политик или профилей. Короче говоря, это может быть любой работающий ПК. Какой же вид трафика этот обычный компьютер собирается создавать, когда он регистрируется в сети? При загрузке машины и регистрации пользователя сети создаются по крайней мере четыре различных вида трафика. Эти типы трафика перечислены в таблице 5.1.
134 Глава 5 Таблица 5.1. Трафик при инициализации клиента Тип трафика Описание трафика Число кадров Число байтов DHCP WINS Проверка регистрации Общий трафик инициализации Получение IP-адреса 4 кадра от сервера DHCP Регистрация имени NetBIOS По крайней мере 4 кадра ' Проверка регистрации По крайней мере контроллером домена 24 кадра По крайней мере 32 кадра По крайней мере 1368 байтов По крайней мере 428 байтов ^ $. По крайней мере 3105 байтов По крайней мере 4901 байтов Трафик DHCP При использовании в сети TCP/IP существует вероятность, что в сети при- применяется DHCP для раздачи IP-адресов клиентским машинам и, возможно, некоторым принтерам. Нечего и говорить, что если TCP/IP является един- единственным протоколом в сети, то клиентская машина должна иметь допусти- допустимый IP-адрес, чтобы общаться с другими устройствами в сети, например компьютерами, маршрутизаторами, принтерами и серверами. Этот IP-ад- IP-адрес должен иметь подходящий сетевой адрес, адрес хоста и маску подсети, иначе коммуникация просто не будет происходить. Если имеется несколько сегментов, то требуется также используемый по умолчанию шлюз. DHCP может управлять этими простыми задачами, и даже сделать бо- больше. В действительности это четкий и эффективный протокол, которо- которому требуются только четыре кадра для выдачи адреса и два кадра для обновления этого адреса позже. Рассмотрим это подробнее. Процесс получения адреса Когда загружается клиент DHCP, первое, что он должен сделать, это найти сервер DHCP, выдающий IP-адреса для подсети, к которой он присоединен. Для этого устройство пошлет сообще- сообщение поиска DHCP, указывающее, что оно хотело бы получить IP-адрес. Сер- Сервер DHCP, получив сообщение поиска, ответит предложением DHCP. Оно говорит: "Я получил ваш запрос и вот адрес, который у меня есть". Клиент- Клиентская машина может получить несколько предложений DHCP от нескольких серверов, которые могут услышать сообщение поиска DHCP. Клиент выбе- выберет первое полученное им предложение DHCP и ответит серверу DHCP, что он хочет получить предложенный IP-адрес. Это называется запросом DHCP. Сервер DHCP при получении запроса ответит подтверждением (АСК): "Можете начинать использовать IP-адрес". Таблица 5.2 резюмирует этот процесс. Как можно видеть в таблице 5.2, DHCP использует широковещание в те- течение всего процесса. Это позволяет другим машинам в сети знать о том, что происходит. Рассмотрим этот процесс подробнее. В приведенной ниже рас- распечатке заголовка Ethernet можно видеть, что адресом назначения является FFFFFFFFFFFF. Это широковещательный адрес для уровня доступа к среде передачи. Все устройства в сегменте Ethernet должны будут обрабатывать
Клиентский трафик 135 этот кадр, пока не дойдут до раздела UDP (порта дейтаграмм пользователя) и не обнаружат, что они не имеют указанного порта UDP. В распечатке так- также видно, что размер кадра Ethernet равен 342 байтам. Это размер данного кадра Ethernet, включая заголовок. Число остающихся байтов равно 328, что является полезной нагрузкой минус 14-байтовый заголовок Ethernet. ETHERNET: ЕТУРЕ = 0x800 : Protocol = IP: DOD Internet Protocol ETHERNET: Destination address: FFFFFFFFFFFF ETHERNET: 1 = Group address ETHERNET: 1. = Locally administered address ETHERNET: Source address : 00104BEC8DB2 ETHERNET: 0 = No routing information present ETHERNET: 0. = Universally administered address ETHERNET: Frame Length : 342 @x0156) ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 328 @X0148) Г, ¦¦ .;•. .... ., ,,. ,--,.,. :¦•.;¦, . ,,¦. : .... Г •.,.:.;¦ Часть с заголовком IP разбирается в распечатке, которая следует за этим параграфом. Прежде всего отметим, что полезная нагрузка использует протокол UDP (протокол пользовательских дейтаграмм). Это компактный эффективный протокол, который идеально подходит для процесса DHCP. Таблица 5.2. Процесс получения IP Тип Место назначения Описание DHCP Discover Широковещание Клиент ищет сервер DHCP. DHCP Offer Широковещание Сервер DHCP, услышав сообщение DHCP Discover, отвечает адресом IP. DHCP Широковещание Клиент DHCP отвечает согласием принять предложение адреса IP. DHCP ACK Широковещание Сервер DHCP подтверждает выделение адреса. Отметим затем адрес IP источника 0.0.0.0. Это в действительности име- имеет смысл, так как машина еще не получила адрес IP, и поэтому значения 0.0.0.0 являются просто пустыми позициями. Адрес места назначения 255.255.255.255 указывает на сообщение широковещания. Это означает, что оно приходит на каждое устройство в определенной подсети. Если мар- маршрутизаторы сконфигурированы для пересылки широковещательных со- сообщений DHCP, то они будут также попадать в другие подсети. После завершения заголовка остается еще 308 байтов. Вычитание этих байтов из первоначальных 328 байтов дает длину заголовка IP, равную 20 байтам. IP: ID = 0x0; Proto = UDP; Len: 328 ; : IP: Version = 4 @x4) '¦..,; . i ¦ • •¦-•¦.¦ IP: Header Length = 20 @x14) IP: Service Type = 0 @x0) . . IP: Precedence = Routine
136 Глава 5 . . /.'..д.:.u IP: . . .0. . . . = Normal Delay ; ¦•• . ¦ :¦ ¦ ..,-.¦¦¦•¦¦'-•¦••¦¦ IP: ....0... = Normal Troughput •¦••¦-. :. ,..,.¦ ^ .,'.¦'¦ .; , IP: 0.. = Normal Reliability '¦¦¦¦>}' ,imi '¦¦"¦¦<¦'; IP: Total Length = 328 @x148) ,^, ,. , i v. ..... IP: Identification = 0 @x0) , . IP: Flags Summary = 0 @x0) IP: 0 = Last fragment in datagram • IP: 0. = May fragment datagram if necessary IP: Fragment Offset = 0 @x0) bytes IP: Time to Live = 128 @x80) IP: Protocol = UDP-User Datagram ' ":-: IP: Checksum = 0x39A6 • IP: Source Address =0.0.0.0 IP: Destination Address = 255.255.255.255 -.' • ¦ "• IP: Data: Number of data bytes remaining = 308 @x0134) Перейдем теперь к разделу UDP сообщения поиска DHCP. Отметим в приведенной ниже распечатке, что используется мультивещание IP (Multicast), и что порт источника UDP равен 68. Этот порт используется для запросов клиента ВООТР, в то время как порт назначения UDP равен 67, порту сервера ВООТР. Если маршрутизатор не позволяет пересылать на эти два порта UDP, а сервер DHCP находится в другой подсети, то эти за- запросы останутся без ответа, если не будет сконфигурирован отдельный агент пересылки ВООТР. UDP: IP Multicast: Src Port: BOOTP Client, F8); Dst Port: BOOTP Server F7): Length = 308 @x134) ¦ UDP: Source Port = BOOTP Client ..... y/, .., ¦ .-s. j . . п; UDP: Destination Port = BOOTP Server UDP: Total Length = 308 @x134) bytes ":/ UDP: UDP Checksum = 0x78C3 UDP: Data: Number of data bytes remaining = 300 @x012C) Последний раздел сообщения поиска DHCP является самым главным разделом кадра. Отметим, что это кадр поиска и таким идентифицируется. Затем мы видим несколько параметров, которые сообщают получающему компьютеру, как прочитать сообщение. Например, длина аппаратного ад- адреса равна шести байтам. Он прошел через 0 переходов и не имеет задан- заданных флагов. Задание флагов позволяет получающим машинам обработать сообщение более эффективным образом, не требуя чтения раздела флагов. Перейдем к разделу адреса. Можно видеть, что все задано как .0.0.0". За- Затем идет реальный адрес MAC машины клиента. В данном случае это 00104BEC8DB2. В запрошенном поле адреса мы видим, что машина "Kenny" (машина клиента Windows 98 DHCP) имела раньше IP-адрес в этой сети и запрашивает тот же адрес. Эта информация хранится в реестре и извле- извлекается при создании сообщения поиска DHCP. Если запрошенный адрес недоступен в сети, то запрашивающей машине будет послан NAK. DHCP: Dicover (xid=05D105Dl) DHCP: Op Code (op) = 1 @x1) DHCP: Hardware Type (htype) = 1 @x1) 10 Mb
Клиентский трафик 137 Ethernet DHCP: Harware Address Length (hlen) = 6 @x6) DHCP: Hops (hops) DHCP: Transaction ID (xid) = DHCP: Seconds (sees) DHCP: Flags (flags) = DHCP: 0 = Client IP Address (ciaddr) = Your IP Address (yiaddr) = Server IP Address (siaddr) = Relay IP Address (giaddr) = Client Ethernet Address (chaddr) Server Host Name (sname) = Boot File Name (file) Magic Cookie = [OK] Option Field (options) DHCP Message Type = Client-identifier = DHCP DHCP DHCP DHCP DHCP DHCP DHCP DHCP DHCP DHCP DHCP 8d b2 DHCP DHCP DHCP 0 @x0) 97584593 @x5Dl05Dl) 0 @x0) 0 @x0) No Broadcast 0.0.0.0 0.0.0.0 0.0.0.0 o.o.o.o ' ;•';¦ = 00104BEC8DB2 ' ' "'- ' <Blank> <Blank> '¦ ' DHCP Discover (Type: 1) 00 10 4b ex Requested Address Host Name Parameter Request List Of 2c2e 2f 39 DHCP: End of this option field 10.0.0.76 kenny (Length: 8) 01 03 06 Теперь мы переходим к серверному кадру DHCP Offer. Этот заголовок Ethernet имеет такие же свойства, как и заголовок из кадра DHCP Discover, поэтому нет необходимости повторять его здесь. Интересный момент от- относительно IP-заголовка показан в приведенной ниже распечатке. Адрес источника является IP-адресом сервера DHCP, и мы видим, что он по-преж- по-прежнему использует широковещание. Вспомните, в данный момент процесса клиентская машина не имеет адреса IP. Остающиеся данные равны 308 байтам, что идентично пакету предложения DHCP в конце заголовка IP. IP: Protocol = UDP - User Datagram IP: Checksum = 0x787B IP: Source Address = 10.0.0.11 IP: Destination Address = 255.255.255.255 IP: Data: Numberr of data bytes remaining = 308 @x0134) Раздел UDP выглядит точно так же, как заголовок UDP сообщения DHCP Discover, за исключением того, что порты источника и места назна- назначения переключаются, как показано ниже. UDP: IP Multicast: Src Port: BOOTP Server, F7); Dst Port: BOOTP Client F8); Length = 308 @x134) u' UDP: Source Port = BOOTP Server ¦>¦•¦'•*¦•'¦! ¦;v:' UDP: Destination Port = BOOTP Client ' ' ' ¦i! ¦ UDP: Total length = 308 @x134) bytes '"' >•'¦¦¦ UDP: UDP Checksum = 0x6D2F i ¦ UDP: Data: Number of data, bytes remaining = 300 @x012C) ¦ '
138 Глава 5 Теперь мы подошли к разделу DHCP пакета предложения DHCP. Отме- Отметим, что разделы предложения, Ethernet и флагов выглядят аналогично па- пакету запроса DHCP. Однако теперь IP-адрес заполнен с помощью точного IP-адреса, который был предоставлен в запросе DHCP. Это, очевидно, не всегда так, но происходит довольно часто в небольших сетях, имеющих в своем распоряжении большие адресные пулы. Раздел DHCP Options теперь заполнен. Клиентская машина имеет все, что ей нужно, чтобы правильно оценить предложение сервера. В данном случае маска подсети равна 255.0.0.0, выделенный адрес действителен в те- течение трех дней, делающий это предложение сервер DHCP имеет адрес 10.0.0.11, а адрес маршрутизатора 10.0.0.15. Кроме того, сервер DNS имеет адрес 10.0.0.10. Тот же самый сервер обеспечивает также службы разрешения имен NetBIOS с используемым по умолчанию методом 0x08. DHCP: Offer (xid = 05D105D1) ' DHCP: Op Code (op) = 2 @x2) •" "*""* DHCP: Hardware Type (htype) = 1 @x1) 10Mb Ethernet Hardware Address Length (hlen) = 6 @x6) (hops) = 0 @x0) (xid) = 97584593 ID DHCP: DHsCP: Hops DHCP: Transaction @x5D105Dl) DHCP: Seconds (sees) DHCP: Flag (flags) DHCP: 0 = No Client IP Address (ciaddr) Your IP Address (yiaddr) Server IP Address (siaddr) Relay IP Address (giaddr) DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: = 0 @x0) = 0 @x0) ' Broadcast = 0.0.0.0 ч = 10.0.0.76 :"v' = 0.0.0.0 = 0.0.0.0 = 00104BEC8DB2 <Blank> <Blank> DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: i4aur.' DHCP Offer 255.0.0.0 1 Day, 12:00:00 2 Days, 15:00:00 00:00 Client Ethernet Address (chaddr) Server Host Name (sname) = Boot File Name (file) Magic Cookie = [OK] Option Field (options) DHCP: DHCP Message Type Subnet Mask = Renewal Time Value (Tl) = Rebinding Time Value (T2) = IP Address Lease Time Server Identifier Router Domain Name Server NetBIOS Name Service NetBIOS Node Type End of option field Если все вышеприведенное выглядит хорошо на клиентской машине, то она посылает сообщение запроса DHCP, как показано в распечатке ниже. Здесь опущен заголовок Ethernet, заголовок IP и заголовок UDP, так как они выглядят аналогично. Кое-что интересное можно увидеть в нижней части кадра запроса DHCP, где присутствуют поля запрошенного адреса и имени хоста, заполненные на клиентской машине. 3 Days, 10.0.0. 10.0.0. 10.0.0. 10.0.0. о 11 15 10 10 = (Length: 1) 08
Клиентский трафик 139 DHCP: Request (xid = 05D105D1) DHCP: Op Code (op) = 1 (Oxl) DHCP: Hardware Type (htype) = 1 @x1) 10 Mb Ethernet DHCP: Hardware Address Length (hlen) = 6 @x6) .. ; DHCP ¦'¦• VJb'-- DHCP @x5D105Dl) DHCP: Seconds DHCP: Flags Hops Transaction ID (hops) (xid) (sees) (flags) 0 @x0) 97584593 0 @x0) 0 @x0) DHCP: 0 = No Broadcast . , DHCP: Client IP Address ; DHCP: Your IP Address ' ' " DHCP: Server IP Address DHCP: Relay IP Address DHCP: Client Ethernet Address DHCP: Server Host Name Boot File Name Magic Cookie = [OK] Option Field (options) DHCP: DHCP Message Type Client-Identifier DHCP: DHCP: DHCP: (ciaddr) (yiaddr) (siaddr) (giaddr) (chaddr) (sname) (file) DHCP: 8d b2 DHCP: Requested Address . ,.,... DHCP: Server Identifier DHCP: Host Name DHCP: Parameter Request List Of 2c 2e 2f 39 DHCP: End of this option field 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 00104BEC8DB2 <Blank> <Blank> DHCP Request (Type: 1) 00 10 4b ec 10.0.0.76 10.0.0.11 kenny (Length: 8) 01 03 06 Теперь мы переходим к конечному кадру в этом общении, который явля- является кадром подтверждения DHCP ACK, посылаемым сервером. Здесь так- также опущены все заголовки, кроме части DHCP кадра. Можно видеть, что этот кадр выглядит очень похоже на предложение DHCP, предложенное сервером DHCP во втором кадре. Мы видим, что клиенту на самом деле раз- разрешено использовать запрошенный машиной IP-адрес, и что все парамет- параметры остались такими же. Здесь снова всем машинам в подсети посылается широковещательное сообщение. Получив пакет, клиентская машина начнет использовать этот адрес. .- '-i1 , ' ¦¦:¦¦¦ DHCP: ACK (xid = 05D105D1) (op) = 2 @x2) (htype) = 1 @x1) 10 Mb DHCP: Op Code DHCP: Hardware Type Ethernet DHCP: Hardware Address Length (hlen) = 6 @x6) ¦ г.... DHCP: Hops (hops) = 0 @x0) Transaction ID (xid) = 97584593 DHCP: @x5D105Dl) DHCP: Seconds (sees) = 0 @x0)
140 Глава 5 DHCP: Flags DHCP: 0. DHCP: Client Your Server Relay Client DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: IP Address IP Address IP Address IP Address (flags) = 0 @x0) . = No Broadcast (ciaddr) = 0.0.0.0 (yiaddr) = 0.0.0.76 (siaddr) = 0.0.0.0 (giaddr) = 0.0.0.0 Ethernet Address (chaddr) = 00104BEC8DB2 Server Host Name (sname) = <Blank> . . Boot File Name (file) = <Blank> Magic Cookie = [OK] ' ,j...;or, ¦: Option Field (options) DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP Message Type = DHCP ACK Renewal Time Value (Tl) 1 Days, 12:00:00 Rebinding Time Value (T2) =2 Days, 15:00:00 = 3 Days, 0:00:00 10.0.0.11 255.0.0.0 -~- - 10.0.0.15 •". 10.0.0.10 10.0.0.10 (Length: 1) 08 IP Address Lease Time Server Identifier Subnet Mask Router Domain Name Server NetBIOS Name Service NetBIOS Node Type End of this option field Обновление выделенного адреса DHCP Выделенный IP-адрес дол- должен обновляться до истечения срока своей службы. Как можно видеть в распечатке выше, когда выделенный адрес подтверждается, одновременно задается время обновления. Процесс обновления требует только двух кад- кадров: запроса DHCP и последующего АСК. Клиент DHCP будет запрашивать обновление дважды — при запуске и при истечение половины выделенного времени. В каждом из этих случаев, если запрос успешен, он будет использовать только два кадра. Эти два кад- кадра выглядят точно так же, как кадры запроса и подтверждения, показанные в предыдущем разделе. Единственное различие состоит в том, что при за- запросе во время истечения половины выделенного времени это будет на- направленная дейтаграмма, а не широковещательное сообщение, как в случае обновления при запуске. Эти два кадра имеют размер всего 684 байта и требуют только 100 мил- миллисекунд для завершения. Если клиентской машине DHCP не удалось полу- получить обновление после двух попыток, она будет ждать до следующего периода обновления. Если срок выделенного адреса истекает, то машина возвращается к описанному ранее процессу из четырех кадров, как если бы она пыталась получить адрес в первый раз. Оптимизация трафика DHCP В действительности трафик DHCP имеет минимальное влияние на объем создаваемого сетевого трафика. Су- Существуют только шесть случаев, когда трафик будет присутствовать вооб- вообще. Они перечислены ниже: • Клиенту DHCP требуется адрес в первый раз — четыре кадра. • Автоматическое обновление при истечении половины выделенного времени — два кадра.
Клиентский трафик 141 • Перезапуск клиентской машины DHCP — два кадра. . • Машина перемещается в новую подсеть. Это будет создавать два кадра обновления, которые получат отрицательное подтверждение, затем четыре кадра для получения адреса — всего шесть кадров. • Замена NIC на машине — четыре кадра. „• ¦»¦,... ^ . f.t. • Адрес IP освобождается или обновляется вручную, с помощью либо ipconfig, либо winipcfg. Одним из основных способов сокращения объема трафика DHCP явля- является настройка длительности времени выделения. Это делается менедже- менеджером DHCP, как показано на рис. 5.1. Если длительность выделения адреса изменяется с используемых по умолчанию трех дней до тридцати дней, то сокращение трафика может быть существенным — 13684 байта на каждую машину. Такое изменение имеет смысл, когда область адресов значительно больше, чем число хостов, которые необходимо адресовать. Если это не так, то придется либо использовать длительность выделения по умолчанию, либо сделать длительность еще короче. Другой сценарий при настройке дли- длительности выделения номера может возникать в ситуации, когда существует Frsie 3 4 •1 I* '11 Ti» it 1* e 167 211 Src ИАС КИШУ TESESA fceim |sie Addr t4t НАС Addr • BROADCAST •BROADCAST ||У|в|: Protocol 08CP DHCP MJ»|hJ[?J Request ACK (s О id id •aSDlOSDI) -05D105D1) айзмаи 00 iO 08 TERESA Al D4 It'M i25S Otbnr Jlddr 255 255 255 255 25S 255 Type IP IP Othej ODP Data Ku»fae: -и»:.: DHCP Op Code DHCP Hardware Tjrpe ot data bytes rexai BHffl e) DHCP Hardware Addrese length (Ы. 1 @x1) 1 @«l) 10«b Ethernet ea) • i @»6) 0 @0) DHCP Hope (bops) - 0 (OkO) DHCP Transaction ID Isid) ¦ 97S94593 (OsSDIOSDt) DHCP Seconds - - -. -ПЯСР Flaas DHCP 0 DHCP Client IP Address (ctadd: DHCP Tour IP Addicts (ymiil DHCP Server IP Address (sieddrl DHCP Belay IP Address (giaddr) .... DHCP Client Ethernet Address (cbsddr) • 00104BECtDB2 DHCP Server Host Hue <sns*e DHCP Boot File Haae Ifile) DHCP Hajic Cookie - [OJC) •DHCP Optior. Field (optu DKCP DHCP Henaje Type DHCP Ciiect-identiiier DHCP Requested Address . DECP Sost Ka«5 »> -0 @>0) . . 0 @«0) Ho Bro»dca.i lll.l oo o.o 0 0 0 0 0 0 0 0 - DHCP Discover - <Tvpe. 1) 00 10 tb ec • 10.0 0 '• ¦ kenr.v 00000000 ooooooio 00000020 00000030 00000040 30000050 OOOOOOiO 00000070 QOOOOOeo 00000030 0000OOAO 3UG0O0B0 JO0Q0OC0 0O00OODO 0O0O0OEO 000000F0 00000100 »0 00 00 Ofi Oil DO 00 00 00 П0 1H 00 DO 00 00 00 00 00 00 00 >H 00 CO 00 00 00 GO 00 00 00 ДО 00 00 0U 00 jo oo со ас oo 00 00 \jQ 00 00 Ю 00 00 00 00 ¦1С 00 00 00 00 00 00 10 4? ТУ. 00 00 00 CO ЛП 00 00 00 CO 00 00 1.0 00 Г0 (fO 00 00 П0 CO 0ft Oft 00 00 CO Ofl 0<) 00 00 CJt П0 00 00 00 CO 00 i 0U 00 00 CO 00 i 00 00 00 CO 00 i 00 00 00 CO 00 i oo oo ou со до - 00 30 00 CO 00 i : oq oo m oo i 00 00 00 00 I 00 00 CO 00 < i oo oo o<> oo ; I 00 00 00 00 I 00 00 0П CO I 00 00 00 00 i 00 00 00 CO ' i 00 00 OU 00 | 00 00 00 00 1 00 00 00 00 i 00 00 00 00 1 00 00 00 00 Рис. 5.1. Трафик DHCP можно сократить, настраивая используемую по умолчанию длительность выделения адреса
142 - Глава 5 большое количество переносных компьютеров, которые соединяются с сетью на регулярной основе. Если пользователи не обучены освобождать свои IP-адреса при выходе из сети, они могут получать несколько адресов, требуя тем самым большего пространства адресов, чем необходимо. Трафик клиента WINS * ¦• . Получив подходящий IP-адрес, клиентский компьютер должен зарегистри- зарегистрировать в сети свое имя NetBIOS. В большинстве ситуаций эта регистрация будет вовлекать WINS. Большинство ресурсов, доступных в сети, включает некоторый вид компьютерного имени. Компьютеры в сети должны регист- регистрировать по крайней мере одно имя. Как правило они будут регистриро- регистрировать более одного имени, чтобы обеспечить в сети коммуникацию по имени. В мире Windows NT имя хоста и имя NetBIOS обычно совпадают (они не являются одним и тем же по сути, но обозначаются одним и тем же словом или комбинацией символов). В мире Unix имя хоста и имя NetBIOS могут быть различаться. В главе 1 говорилось, что NetBIOS (сетевая базовая система ввода-выво- ввода-вывода) не то же самое, что NetBEUI. NetBIOS является протоколом, используе- используемым различными приложениями. Он может переноситься через TCP/IP, IPX/SPX и, конечно, NetBEUI. Мы рассмотрим NetBIOS, потому что она используется через TCP/IP. Чтобы приложения могли общаться, имя NetBIOS должно быть преоб- преобразовано в адрес IP. Способ, которым это обычно делается, состоит в испо- использовании либо широковещания b-узлов, либо сервера имен NetBIOS, например WINS. Есть несколько преимуществ использования сервера WINS, а не просто широковещания. Первое состоит в том, что широкове- широковещание является очень дорогим предложением, когда речь идет о сетевой производительности. Каждое одиночное устройство в сегменте должно остановить и проверить каждый одиночный кадр широковещания, чтобы определить, не может ли он обслужить запрос. В большой сети широкове- широковещание NetBIOS может буквально заполнить всю сеть. С этим надо как-то бо- бороться. К счастью, компания Microsoft разработала для этой цели WINS. WINS полностью соответствует реализации сервера имен NetBIOS на основе RFC. С помощью WINS хосты могут отбрасывать кадр, как только они видят адрес MAC места назначения. Все функции службы имен NetBIOS через TCP/IP используют UDP порт 137. Рассмотрим регистрацию имен и процесс обновления. Регистрация имен и обновление Имена NetBIOS должны быть зарегистрированы для каждой службы или приложения, которые хотят использовать их коммуникационный меха- механизм. Примерами таких регистрируемых служб являются служба рабочей станции и служба сервера. Другие имена указывают специальные роли, ко- которые выполняются в сети, такие как основной, или первичный, контрол- контроллер домена (Primary Domain Controller, PDC) или резервный контроллер домена (Backup Domain Controller, BDC). Регистрируется само имя домена, а также имена пользователей, регистрирующихся в домене. Эти имена
Клиентский трафик 143 нужны для некоторых функций сообщений и коммуникации. Например, если необходимо послать сообщение, используя сетевую команду send (по- (послать) некому Джейсону, он должен иметь зарегистрированное имя пользо- пользователя, иначе ничего не получится. Общее число зарегистрированных имен зависит, очевидно, от числа запущенных служб. Каждое зарегистри- зарегистрированное имя будет использовать всего 214 байтов — ПО байтов для запро- запроса регистрации имени и 104 байта для ответа. Посмотрим теперь на такую транзакцию на листинге ниже: + FRAME: Base frame properties ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + ETHERNET: Destination address : 00805FA63A32 + ETHERNET: Source address : 00609788CF96 ETHERNET: Frame length : 110 (ОхООбЕ) " '-: ' ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 96 @x0060) + IP: ID = 0x1501; Proto = UDP; Len: 96 UDP: Src Port: NETBIOS Name Service, A37); Dst Port: NETBIOS Name Service A37); Length = 76 @x4C) UDP: Source Port = NETBIOS Name Service ;rT'' ' «»'> ¦ ¦ ¦ ¦ ¦ UDP: Destination Port = NETBIOS Name Service .. .. ; ,;-м1ч<'-- UDP: Total length =76 @x4C) bytes UDP: UDP Checksum = 0x3D0F UDP: Data: Number of data bytes remaining = 68 @x0044) В приведенном выше листинге можно видеть, что размер кадра равен ПО байтам. Порт места назначения является UDP портом 137 службы имен NetBIOS. Эта информация свидетельствует, что это, возможно, кадр запроса. Обратимся к следующему разделу. .)¦ »: «,.;¦-.-' ;.М|- ¦¦ >' '¦¦> ' ¦ ¦" NBT: NS: Registration req. for ED <03> NT: Transaction ID = 32894 @x807E) С ч'т; ;.. П».;— ?..>.; tU"•'¦Г-Ж : NBT: FlagBs Summary = 0x2900 - Req.; Registration; Success NBT: 0 = Request NBT: . 0101 = Registration -: NBT: 0 = Non-authoritative Answer NBT: 0 = Datagram not truncated NBT: 1 = Recursion desired NBT: 0 = Recursion not available NBT: 0 = Reserved NBT: 0 = Reserved NBT: 0.... = Not a broadcast packet NBT: 0000 = Success NBT: Question Count = 1 @x1) NBT: Answer Count = 0 @x0) NBT: Name Service Count = 0 @x0) : NBT: Additional Record Count = 1 @x1) NBT: Question Name = ED <03> NBT: Question Type = General Name Service NBT: Question Class = Internet Class . NBT: Resource Record Name = ED <03>
144 Глава 5 NBT: Resource Record Type = NetBIOS General Name Service NBT: Resource Record Class = Internet Class NBT: Time To Live = 300000 @x493E0) '' NBT: RDATA Length = 6 @x6) • . ¦ .... . ,¦, NBT: Resource Record Flags = 24576 @x6000) •'¦'¦ NBT: 0 = Unique NetBIOS Name ' :' •'"' NBT: .11 = Reserved -'* : .. NBT: ...0000000000000 = Reserved . ••; NBT: Owner IP Address = 11.0.0.190 В некоторых, отношениях пакет службы имен NetBIOS выглядит как структура типа QNS. В распечатке выше заголовок состоит из идентифика- идентификатора транзакции; раздела флагов, счетчика ответов, счетчика службы имен и счетчика дополнительных записей. Каждый из этих пунктов рассмотрен ниже. .&¦?.¦¦¦.. . -,,^ ¦ -. - ¦•¦. 1.- ¦¦ _ • - Идентификатор транзакции Поле идентификатора транзакции ис- использует 16 битов B байта) для отслеживания сообщений. Инициатор со- сообщения выбирает уникальный номер для каждой активной транзакции. Машина, которая отвечает на сообщение, будет использовать тот же самый идентификатор транзакции. Флаги Поле флагов также использует 16 битов. Они представлены в распечатке выше. Список ниже объясняет, что эти флаги означают. • Запрос/ответ (Request/response). Запрос/ответ является однобито- однобитовым флагом. Он устанавливается в ", чтобы указать запрос, или в ", чтобы указать ответ. • «•••- ¦- ¦¦¦¦ ¦ ¦¦• * • Код операции (Opcode). Флаг кода операции использует четыре бита, чтобы указать определенную операцию NetBIOS. Коды операций, обычно встречающиеся в этом флаге, перечислены в таблице 5.3. Таблица 5.3. Флаги кодов операций NetBIOS Шестнадцатеричный Значение код операции 0x0 ¦, Запрос имени 0x5 , Регистрация имени 0x6 Освобождение имени 0x7 . WACK (wait for acknowledgment — ждать подтверждения). Посылается, когда WINS слишком занят, чтобы ответить. Но по крайней мере позволяет посылающей машине знать, что пакет был получен (тем самым предотвращая повторную передачу). 0x8 Обновить имя F Регистрация группового имени
Клиентский трафик 145 NBT: Flags Summary = 0xAD80-Resp.; Registration; Success NBT: 1 = Response . . NBT: .0101 = Registration ' ' •¦¦¦•'•• ¦• nbT: 1 = Authoritative Answer NBT: 0 = Datagram not truncated .. NBT: 1 = Recursion desired , ,. . NBT: 1 = Recursion available NBT: 0 = Reserved NBT: 0 = Reserved NBT: 0.... = Not a broadcast packet NBT: 0000 = Success • Официальный ответ (Authoritative answer). Этот флаг использует один бит и устанавливается в 1, если отвечающая машина является уполномоченной для этого домена. Он всегда сбрасывается в 0 в запросе. В распечатке выше показана часть пакета ответа, и флаг установлен в 1. • Обрезание (Truncation). Этот однобитовый флаг устанавливается в 1, если сообщение должно быть сделано короче, в связи с размером пакета. • Желательна рекурсия (Recursion desired). Флаг желательности рекур- рекурсии задается как 1, если клиентская машина хочет, чтобы WINS повто- повторял на основе запроса, регистрации или выпуска. WINS будет также устанавливать этот флаг в пакете ответа. • Рекурсия доступна (Recursion available). Этот однобитовый флаг устанавливается в 1 только в ответах WINS, чтобы указать, что он поддерживает рекурсивный запрос, регистрацию и выпуск. • Широковещание (Broadcast). Еще один однобитовый флаг задаваемый как 1, если пакет передается в режиме широковещания или мульти- вещания. Он задается как 0, если пакет передается однонаправленно. Пакет в распечатке выше не был отправлен в режиме широковещания. • Возвращаемый код (Return code). Это последний флаг с четырьмя вы- выделенными для его использования битами. Возвращаемый код равен 0x0 для всех запросов, и он также равен 0x0 для положительного ответа. Другие значения указывают на ошибочные условия. Счетчик запросов Для использования счетчика запросов выделено 16 битов. Счетчик запросов всегда равен 0 для ответов. Для правильно сформатированного запроса, однако, это поле должно иметь число, как 0x1 в предыдущей распечатке. В распечатке ниже приведен пакет ответа, и счетчик запросов сброшен в 0x0. NBT: Question Count = 0 @x0) NBT: Answer Count = 1 @x1) NBT: Name Service Count = 0 @x0) . ...
146 ' Глава 5 Счетчик ответов Разделу счетчика ответов выделено 16 битов, он ис- используется для указания числа записей ресурса, содержащихся в разделе от- ответа пакета. Ответ, приведенный выше, имеет только одну запись в разделе ответа. Счетчик службы имен Раздел счетчика службы имен также имеет 16 би- битов и указывает число записей ресурсов, содержащихся в разделе полномочий пакета. . NBT: Additional Record Count = 0 @x0) Счетчик дополнительных записей Поле счетчика дополнительных записей является последним полем в заголовке службы имен и также испо- использует 16 битов. Используется дополнительный счетчик записей для указа- указания числа записей ресурсов в разделе пакета дополнительных записей ресурсов. В распечатке выше нет дополнительных записей. После информации заголовка мы переходим к записи запроса. Этот раз- раздел состоит из трех полей. Первое поле — имя запроса, которое является именем ресурса NetBIOS. Для имени NetBIOS без идентификатора области действия это поле имеет в длину 34 бита. Второе поле является типом за- запроса. Он задается как 0x00-20 для указания, что это имя NetBIOS. Третье поле является классом запроса, который задается как 0x00-01, указывая, что это класс запроса Интернета (IN). Эти числа не показаны в разделе ана- анализа сетевого монитора, они приведены в шестнадцатеричном виде ниже. NBT: Question Name = SERVERPDC <00> NBT: Question Type = General Name Service NBT: Question Class = Internet Class 00000: 00 08 C7 33 F3 E2 08 00 02 IB 35 B0 08 00 45 00 ...3 5...E. 00010: 00 4E 04 06 00 00 IE 11 IF 1С 0A 03 01 02 0A 01 .N 00020: 64 78 00 89 00 89 00 ЗА 30 AD 00 D2 01 00 00 01 dx :0 00030: 00 00 00 00 00 00 20 46 44 45 46 46 43 46 47 45 FDEFFCFGE 00040: 46 46 43 46 41 45 45 45 44 43 41 43 41 43 41 43 FFCFAEEEDCACACA 00050: 41 43 41 43 41 41 41 00 00 20 00 01 ACACAAA.... Имя записи ресурса Это следующее поле пакета NetBIOS. NBT: Resource Record Name = ORCO <1D> NBT: Resource Record Type = NetBIOS General Name Service NBT: Resource Record Class = Internet Class Тип записи ресурса Следующее поле является типом записи. Как видно в распечатке выше, это имя NetBIOS. Оно показано как 0x00-20 в шестнад- цатеричной трассировке.
Клиентский трафик 147 Класс записи ресурса Класс записи ресурса задается как 0x00-01, что указывает на класс имени Интернета (IN). NBT: Time To Live = 518400 @х7Е900) Время жизни Поле времени жизни является 32-битным полем, кото- которое используется для указания времени существования имени. В пакете ре- регистрации имени, обновления или запросе выпуска эта величина не имеет значения. Это поле задается как 0х04-93-Е0 C00000 секунд). Длина RDATA Это поле содержит 16 битов и используется для указа- указания числа байтов данных ресурса для этой записи. Оно задается как 0x00-06, как показано ниже. NBT: RDATE Length = б @x6) ' ¦ Флаги записей ресурсов Для двух специальных флагов записей ре- ресурсов выделено 16 битов. Старший бит используется для определения, яв- является ли регистрируемое, восстанавливаемое или обновляемое имя уникальным именем NetBIOS, или это групповое имя NetBIOS. Если этот флаг задан как 1, то это групповое имя. Если флаг задан как 0, то это уника- уникальное имя NetBIOS. В распечатке ниже зарегистрировано групповое имя. Следующие два бита указывают тип узла владельца. Он задается как 00 для В-узла, 01 для Р-узла, 10 для М-узла и 11 для Н-узла. Как можно видеть ниже, мы имеем владельца Н-узла. NBT: Resource Record Name = ORCO <1D> NBT: Resource Record Type = NetBIOS General Name Service NBT: Resource Record Class = Internet Class NBT: Time To Live = 518400 @x7E900) NBT: RDATA Length = 6 @x6) >: NBT: Resource Record Flags = 24576 @x6000) NBT: 0 = Unique NetBIOS Name NBT: .11 = Reserved NBT: ...0000000000000 = Reserved NBT: Owner IP Address = 192.168.2.2 IP-адрес владельца Последнее поле является IP-адресом владельца, которое соответствует регистрируемому, восстанавливаемому или осво- освобождаемому имени. В данном случае это машина 192.168.2.2. Трафик регистрации в системе После того как клиентский компьютер был включен и получил IP-адрес, следующий шаг состоит в регистрации в домене. Это происходит, когда пользователь вводит имя пользователя и пароль и затем нажимает ОК. Конт- Контроллер домена (либо первичный, либо один из резервных) будет проверять запрос. Клиентская машина должна найти сервер регистрации, инициировать переговоры для аутентификации пользователя и осуществить другие вещи, такие как выполнение регистрационных сценариев, копирование профилей и т.п. Как можно видеть в таблице 5.4, во время процесса регистрации создается значительный объем трафика.
148 Глава 5 Таблица 5.4. Трафик регистрации Шаг Тип трафика Объем трафика Найти сервер регистрации Широковещание или WINS Подготовка сеанса Проверка Прекращение сеанса ,... TCP.NBT.SMB SMB SMB i Общее число кадров Общее число байтов 4+кадра ,. 700+ байтов 11 кадров 1280 байтов для win95 1370 байта для winnt 4-20 кадров 765-3725 байтов 5 кадров 360 байтов 24+ кадров , 3105+ байтов Поиск сервера регистрации Прежде чем клиентская машина сможет зарегистрироваться в домене, пер- первый шаг состоит в поиске сервера регистрации. Обычно используются два способа: просто послать широковещательный запрос в почтовый ящик ре- регистрации в сети или запросить у WINS список контроллеров доменов, ко- которые зарегистрировались в службе разрешения имен. Второй метод является прямым запросом, если клиент имеет используемый по умолча- умолчанию тип разрешения имени Н-узла. Рассмотрим каждый из этих методов более подробно. Широковещательный метод ETHERNET: ETYPE = 0x0800 Protocol = IP: DOD Internet Protocol + ETHERNET: + ETHERNET: ETHERNET: ETHERNET: ETHERNET: @x00F6) Destination address : FFFFFFFFFFFF Source address : 00104BEC8DB2 Frame Length: 260 @x0104) Ethernet Type : 0x0800 (IP: DOD Internet Protocol) Ethernet Data: Number of data bytes remaining = 246 Широковещательный кадр адресуется в FFFFFFFFFFFF, имеет длину 260 байтов (включая 14 байтов заголовка Ethernet) и использует тип 0x0800, который соответствует IP. Затем мы видим адрес источника A0.0.0.76) и адрес назначения, равный 10.255.255.255, который является адресом широковещания для сети 10. В качестве транспортного протокола используется UDP. В разделе UDP мы видим, что оба порта, источника и места назначения, заданы как 138, это соответствует службе дейтаграмм NetBIOS. IP: ID = 0x2800; Proto = UDP; Len: 246 ... IP: Version = 4 @x4) IP: Header Length = 20 @x14) + IP: Service Type = 0 @x0)
Клиентский трафик 149 IP: Total Length = 246 @xF6) IP: Identification = 10240 @x2800) + IP: Flags Summary = 0 @x0) IP: Fragment Offset = 0 @x0) bytes IP: Time to Live = 128 @x80) IP: Protocol = UDP — User Datagram IP: Checksum = OxFCAC IP: Source Address =10.0.0.76 IP: Destination Address = 10.255.255.255 IP: Data: Number of data bytes remaining = 226 (OxOOE2) UDP: Src Port: NETBIOS Datagram Service, A38); Dst Port: NETBIOS Datagram Service A38); Length = 226 @xE2) UDP: Source Port = NETBIOS Datagram Service UDP: Destination Port = NETBIOS Datagram Service UDP: Total length 226 @xE2) bytes UDP: UDP Checksum = 0x17 02 UDP: Data: Number of data bytes remaining = 218 (OxOODA) ' ¦ Рассмотрим следующий раздел NetBIOS. На распечатке ниже эта дейтаг- дейтаграмма направляется группе. Здесь снова перечислены IP-адрес источника и порт UDP. В этот раз, однако, мы видим, что используется имя NetBIOS ма- машины. Эта машина называется KENNY, а имя места назначения NETMON — это желательный домен регистрации. Важно отметить, что оба эти имени NetBIOS имеют связанный с ними тип <00>. Это означает, что они являются уникальными именами. NBT: DS: Туре = 17 (DIRECT GROUP) NBT: Datagram Packet Type = DIRECT GROUP + NBT: Datagram Flags = 2 @x2) . . ¦ , NBT: Datagram ID = 20 @x14) ¦ . NBT: Source IP Address = 10.0.0.76 NBT: Source Port = 138 @x8A) : NBT: Datagram Length = 204 (OxCC) ... NBT: Packet Offset = 0 @x0) ;-. NBT: Source Name = KENNY <00> NBT: Destination Name = NETMON <00> NBT: DS Data: Number of data bytes remaining =13 6 @x0088) Перейдем к разделу SMB кадра. Самое важное в этом разделе, что он ис- использует SMB С Transact. Заголовок не раскрыт в этом представлении, но он имеет TID, PID, UID и MID, которые можно было бы ожидать для любой коммуникации SMB. Так как это достаточно длинная распечатка, были вы- выделены наиболее важные разделы. Отметим, что это запись в почтовый ящик с помощью ненадежного класса. Он хочет использовать имя файла \mailslot\net\netlogon. SMB: С transact, File = \MAILSLOT\NET\NETLOGON + SMB: SMB Status = Error Success ¦ ••!
150 Глава 5 + SMB: Header: PID = 0xl52F TID = OxFFFF MID = 0x0081 UID = OxFFFF SMB: Command = С transact -. ; -. , ,. SMB: Word count = 17 •, -• ¦ SMB: Word parameters , > .,;; SMB: Total parm bytes =0 SMB: Total data bytes = 44 SMB: Max parm bytes =0 - ; SMB: Max data bytes =0 SMB: Max setup words = 0 @x0) + SMB: Transact Flags Summary = 2 @x2) SMB: Transact timeout = 0 @x0) SMB: Parameter bytes = 0 @x0) SMB: Parameter offset = 92 @x5C) SMB: Data bytes = 44 @x2c) SMB: Data offset = 92 @x5c) SMB: Max setup words = 3 > ••i.; SMB: Setup words SMB: Mailslot opcode = Write mailslot SMB: Transaction priority = 0 1 ,.' ': SMB: Mailslot class = Unreliable (broadcast) '• " ¦•¦* -'< SMB: Byte count = 67 . ... ¦ ¦"'¦'¦<'¦.'-¦¦¦ SMB: Byte parameters ¦ "'.,.. • ' ;.•!'•' ¦ SMB: File name = \MAILSLOT\NET\NETLOGON и _,иш --, , SMB: Transaction data , , ,¦ SMB: Number of data bytes remaining = 44 (Ox002C) ;, Теперь мы переходим к разделу трассировки регистрации в сети (netlo- gon). Здесь мы видим запрос от пользователя MGROCE на машине KENNY. Кадр указывает, что он может использовать тип регистрации LM1.0 или LM2.0. Отметим также, что счетчик запросов равен 1, т.е. клиент пытается зарегистрироваться в этом сеансе впервые. NETLOGON: LM1.0/2.0 LOGON Request from client NETLOGON: Opcode = LM1.0/2.0 LOGON Request from client NETLOGON: Computer Name = KENNY NETLOGON: User Name = MGROCE NETLOGON: Mailslot Name = \MAILSLOT\TEMP\NETLOGON NETLOGON: Request Count = 1 @x1) NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later) Networking Интересным моментом в этой конкретной трассировке является то, что сразу за ней следует ARP_RARP от Teresa (контроллера домена). Предполо- Предположим, что можно извлечь адрес MAC из только что рассмотренного кадра. Эта информация там присутствовала. Это действительно так. Когда ма- машина Kenny отвечает на ARP Teresa, мы получаем кадр ответа netlogon, кото- который очень похож на предыдущий кадр, рассмотренный достаточно подроб- подробно. Существенная часть, однако, находится ниже. В этом разделе мы видим, что код команды является ответом (response) на запрос LOGON, а имя сер- сервера регистрации \\teresa. Контроллер домена teresa будет принимать тип регистрации LM2.0.
Клиентский трафик 151 NETLOGON LM2.0 Response to LOGON Request NETLOGON: Opcode = LM2.0 Response to LOGON Request NETLOGON: Logon Server Name = \\TERESA NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later) Networking Использование WINS Клиент Н-узла будет использовать WINS при поиске контроллера домена для обслуживания запроса регистрации. Это стандартный запрос WINS из 92 байтов, направленный в порт UDP 137. Как можно видеть в распечатке ниже, запрос NBT (имя запроса) предназна- предназначен для <1С>, что технически означает запрос WINS для первых 25 конт- контроллеров доменов, которые имеют зарегистрированное имя домена. Локально зарегистрированные контроллеры доменов получают приоритет в ответном сообщении. Первая запись в ответе всегда будет PDC. В рас- распечатке ниже отметим, что официальных ответов 0, счетчик запросов равен 1, а счетчик ответов равен 0. Это говорит нам, что это пакет запроса. NBT: NS: Query req for NETMON <1C> NBT: Transaction ID = 32774 @x8006) NBT: Flags Summary = 0x0110 - Req.; Query; Success NBT: 0 = Request .. NBT: .0000 = Query NBT: 0 = Non-authoritative Answer NBT: 0 = Datagram not truncated NBT: 1 = Recursion desired • • NBT: 0 = Recursion not available NBT: 0 .' = Reserved '. . NBT: 0 = Reserved NBT: 1.... = Broadcast pasket NBT: 0000 = Success NBT: Question Count = 1 @x1) NBT: Answer Count = 0 @x0) -!l ' ' : NBT: Name Service Count = 0 @x0) " ' ¦ '¦ NBT: Additional Record Count = 0 @x0) ' :¦ NBT: Question Name = NETMON <1C> ¦ •' NBT: Question Type = General Name Service NBT: Question Class = Internet Class Возвращаемый ответ утверждает, что это официальный ответ. Отме- Отметим, что счетчик запросов в этот раз равен 0, а счетчик ответов равен 1. Когда сервер регистрации идентифицирован, описанный выше процесс продолжается, посылая широковещательное сообщение в почтовый ящик регистрации в сети на сервере регистрации. Он должен получить ответ от сервера регистрации, сообщающий тип поддерживаемой регистрации. NBT: NS: Query (Node Status) resp. for NETMON <1C>, Success NBT: Transaction ID = 32774 @x8006) NBT: Flags Summary = 0x8500 - Resp.; Query; Success NBT: 1 = Response NBT: .0000 = Query NBT: 1 = Authoritative Answer
152 Глава 5 NBT: О = Datagram not truncated NBT: 1 = Recursion desired NBT: 0 = Recursion not available NBT: 0 = Reserved NBT: 0 = Reserved ' NBT: 0.... = Not a broadcast packet NBT: 0000 = Success : NBT: Question Count = 0 @x0) . ... NBT: Answer Count = 1 @x1) NBT: Name Service Count = 0 @x0) NBT: Additional Record Count = 0 @x0) NBT: Resource Record Name = NETMON <1C> NBT: Resource Record Type = NetBIOS General Name Service NBT: Resource Record Class = Internet Class NBT: Time To Live = 300000 @x493E0) NBT: RDATA Length = 6 @x6) + NBT: Resource Record Flags = 32768 @x8000) NBT: Owner IP Address = 10.0.0.11 Создание сеанса и проверка регистрации После того как сервер ре- регистрации был найден и на запрос регистрации послан ответ, следующий шаг состоит в создании сеанса. Создание сеанса TCP Первый шаг в создании сеанса состоит в вы- выполнении трехходового квитирования. Этот процесс требует трех кадров и 180 байтов. В первом кадре ниже мы видим S, который является флагом син- синхронизации, и диапазон последовательности 45091 — 45098. Обратите вни- внимание, что местом назначения является порт 139, т.е. порт сеанса NBT. Следующий кадр поступает с сервера Teresa; в этом кадре заданы оба флага А и S. Флаг А подтверждает предыдущий кадр машины Кеппу. Флаг S, флаг син- синхронизации номера машины Teresa, предлагает диапазон 7972459 — 7972462. Отметим здесь, что порт источника будет 139, а порт назначения — 1025, ко- который был портом источника предыдущего кадра с машины Кеппу. Важно также отметить, что номер подтверждения АСК 45092 находится в диапазо- диапазоне последовательности с машины Кеппу. Последняя часть трехходового квитирования состоит в подтверждении машиной Кеппу предыдущего кад- кадра с машины Teresa. Отметим еще раз, что порт назначения 139, и подтвер- подтверждение находится в диапазоне машины Teresa. В данном случае АСК (подтверждение) является номером последовательности 792460. FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID: = 0x3100; Proto = TCP; Len: 48 + TCP: S., len: 8, seq: 45091-45098, ack: 0, win: 8192, src: 1025 dst: 139 (NBT Session) + FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = ОхВЮб; Proto = TCP; Len: 44
Клиентский трафик 153 + TCP: .A..S., len: 4, seq: 7972459-7972462, ack: 45092, win: 8760, src: 139 (NBT Session) dst: 1025 + FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x3200; Proto = TCP; Len: 40 + TCP: .A...., len: 0, seq: 45092-45092, ack: 7972460, win: 8760, src: 1025 dst: 139 (NBT Session) Когда сеанс TCP создан, следующий шаг состоит в создании сеанса NetBIOS с сервером регистрации. Создание сеанса NetBIOS Это достаточно прямолинейный процесс, требующий только двух кадров и 182 байтов. Кадр запроса состоит из 126 бай- байтов, а ответ только из 56 байтов. Отметим, что вызываемое имя будет Teresa, а вызывающее имя — Kenny. Так как эти два имени были ранее разрешены, сеанс должен работать. NBT: SS: Session Request, Dest: TERESA, Source: KENNY <00>, Len: 68 NBT: Packet Type = Session Request NBT: Packet Flags = 0 @x0) NBT: 0 = Add 0 to Length NBT: Packet Length = 68 @x44) NBT: Called Name = TERESA NBT: Calling Name = KENNY <00> Ниже находится положительный ответ на запрос Kenny о создании се- сеанса NetBIOS с сервером регистрации Teresa. Мы опустили здесь раздел TCP этих распечаток, но если взглянуть на него, то можно заметить, что кадр с машины Kenny приходит из порта 1025 с местом назначения на пор- порте 139, как мы видели выше в трехходовом квитировании. Очевидно, что приведенный ниже кадр ответа приходит из порта 139 в порт 1025. NBT: SS: Positive Session Response, Len: 0 NBT: Packet Type = Positive Session Response NBT: Packet Flags = 0 @x0) NBT: 0 = Add 0 to Length NBT: Packet Length = 0 @x0) После создания сеанса NetBIOS необходимо согласовать протокол SMB, а затем создать сеанс SMB. Согласование диалекта SMB и настройка сеанса Теперь необходи- необходимо решить, какой диалект SMB мы собираемся использовать. Это должно быть согласовано до настройки сеанса. Потребуются два кадра в 212 байтов и 149 байтов соответственно. Машина Kenny посылает кадр SMB с коман- командой согласования С, перечисляющей допустимые строки диалектов. Это посылается из порта 1025 машины Kenny и приходит в порт 139 на машине Teresa.
154 Глава 5 SMB: С negotiate, Dialect = NT LM 0.12 + SMB: SMB Status = Error Success SMB: Header: PID = 0xl52F TID: = 0x0000 MID = 0x0101 UID = 0x0000 SMB: Tree ID (TID) = 0 @x0) SMB: Process ID (PID) = 5423 @xl52F) SMB: User ID (UID) = 0 @x0) SMB: Multiplex ID (MID) = 257 @x101) + SMB: Flags Summary = 0 @x0) + SMB: flags2 Summary = 0 @x0) ' SMB: Command = С negotiate SMB: Word count = 0 •'¦'• SMB: Byte count = 119 • ; . ., , . SMB: Byte parameters .;¦ . SMB: Dialect Strings Understood SMB: Dialect String = PC NETWORK PROGRAM 1.0 SMB: Dialect String = MICROSOFT NETWORKS 3.0 SMB: Dialect String = DOS LM1.2X002 SMB: Dialect String = DOS LANMAN2.1 SMB: Dialect String = Windows for Workgroups 3.1a SMB: Dialect String = NT LM 0.12 Ниже мы видим ответ от машины Teresa. Она посылает ответ, выбирая протокол с индексом 5, который соответствует диалекту NT LM 0.12. SMB: R negotiate. Dialect # = 5 .. + SMB: SMB Status = Error Success SMB: Header: PID = 0xl52F TID = 0x0000 MID = 0x0101 UID = 0x0000 SMB: Tree ID (TID) = 0 @x0) SMB: Process ID (PID) = 5423 @xl52F) ¦'" ' SMB: User ID (UID) = 0 @x0) SMB: Multiplex ID (MID) = 257 @x101) + SMB: Flags Summary = 128 @x80) .: ... , , + SMB: flags2 Summary = 0 @x0) SMB: Command С negotiate SMB: Word count = 17 SMB: Word parameters SMB: Protocol Index = 5 Теперь мы подошли к настройке сеанса SMB, которая также потребует два кадра из 207 байтов и 154 байтов соответственно. В первом кадре ниже мы видим две команды: С session set-up & X, передающую имя пользователя MGROCE, и С tree connect & X, которая сообщает нам, что машина Kenny пытается соединиться со скрытым общим ресурсом 1РС$ на машине Teresa. Это используется для межпроцессной коммуникации. Второй листинг соот- соответствует кадру с машины Teresa на машине Kenny, и он является ответом на обе команды, которые были переданы в предыдущем пакете. Отметим, что здесь нет ошибок, поэтому сеанс SMB был успешно создан.
Клиентский трафик 155 SMB: С session setup & X, Username = MGROCE, and С tree connect & X, Share = \\TERESA\IPC$ + SMB: SMB Status = Error Success + SMB: Header: PID = 0xl52F TID = 0x0000 MID = 0x0101 UID = 0x0001 + SMB: Command = С session setup & X + SMB: Command = С tree connect & X SMB: Command = No secondary command SMB: R session setup & X, and R tree connect & X, Type = IPC + SMB: SMB Status = Error Success + SMB: Header: PID = 0xl52F TID = 0x0801 MID = 0x0101 UID = 0x0801 + SMB: Command = С session setup & X + SMB: Command = С tree connect & X • '-' SMB: Command = No secondary command :, ¦ '•¦ Теперь машина Windows 98 (Kenny) начинает диалог с сервером (Tere- (Teresa) , направляя две регистрации удаленных вызовов API для проверки реги- регистрации. Эта API вызываются с помощью команды SMB С transact удаленной командой API. Первым вызывается API с именем NetWkstaUser- Logon, который делает запрос на проверку регистрации. Машина Teresa отвечает сообщением об успехе, которое приведено во втором фрагменте ниже. SMB: С transact - + SMB: Command = С transact + SMB: SMB Status = Error Success + SMB Header: PID = 0xl52F TID = 0x0801 MID = 0x0201 UID = 0x0801 + SMB Data: Number of data bytes remaining = 94 @x005E) SMB: R transact + SMB: SMB Status = Error Success + SMB Header: PID = 0xl52F TID = 0x0801 MID = 0x0201 UID = 0x0801 + SMB Command = С transact SMB: Data: Number of data bytes remaining = 103 @x0067) Вторым вызовом API является NetRemoteTOD. Этот вызов API извлека- извлекает информацию о времени сервера, чтобы определить смещение часового пояса для вычисления отметки времени и даты временного файла. Сервер сообщает время контроллера домена. SMB: С transact, Remote API + SMB: SMB status = Error Success + SMB: Header: PID = 0xl52F TID = 0x0801 MID = 0x0281 UID = 0x0801 + SMB: Command = С transact SMB: Data: Number of data bytes remaining =20 @x0014) SMB: R transact, Remote API (response to frame 25)
156 Глава 5 + SMB: SMB status = Error Success + SMB: Header: PID = 0xl52F TID = 0x0801 MID = 0x0281 UID = 0x0801 + SMB: Command = С transact SMB: Data: Number of data bytes remaining =25 @x0019) Оставшиеся шаги в этом месте включают соединение с общим ресурсом \\teresa\netlogon и выполнение регистрационных сценариев, профилей пользователя или системных политик. Это будет создавать дополнитель- дополнительный трафик. Когда все будет сделано, останется только "культурно" завер- завершить сеансы, которые были созданы во время процесса регистрации в системе. Это включает закрытие сеанса 1РС$, сеанса NetBIOS и сеанса TCP. При этом будет создаваться дополнительно пять кадров и 360 байтов тра- трафика. Можно обратиться к файлу 98_logon.cap на сайте издательства "ЛОРИ" (www.lory-press.ru), чтобы увидеть некоторые из этих шагов. Оптимизация регистрации в сети Использование LMHOSTS Начнем этот раздел с обсуждения двух способов, с помощью которых рабочая станция находит машину регистра- регистрации — с помощью широковещания и с помощью WINS. Существует и третий способ: использование файла lmhosts. Обратимся к этому файлу. 10.0.0.25 NTS1 10.0.0.26 NTS2 10.0.0.10 EXCHANGE #PRE #DOM:DOMAIN #PRE #DOM:DOMAIN #PRE #DOMAIN PDC #DOMAIN BDC #EXCHANGE SERVER Scope Properties - (Local) • IP Address Pool Start Addcet* End Address 10 10 0 0 . 0 . 0 . 50 . 254 | Subnet Masts: B55 00 i \ Exclusion Range Start Addless: End Address Lease Duration <~ Untmrted <? Limited To: Name: Comment: | Excluded Addresses: ) [tTgHouris) (o~^ Cancel Heip Рис. 5.2. Команда nbtstat -с предоставляет способ увидеть кэш имен NetBIOS
Клиентский трафик 157 Используя запись #PRE, мы приказываем машине сделать предваритель- предварительную загрузку записи в кэш имен NetBIOS. Она будет найдена, когда мы вве- введем nbtstat -с, как показано на рис. 5.2. Задав #DOM с именем домена, мы сообщаем машине, что это контроллер домена, и поэтому получаем допол- дополнительные записи, такие как <1С>, также показанные на рис. 5.2. Используя файл LMHOSTS, мы ускоряем процесс регистрации, не вы- выполняя при этом ни широковещательного запроса, ни запроса WINS, и, кроме того, сокращаем сетевой трафик. Стандартная проблема с реализа- реализацией LMHOSTS состоит в размещении его на всех клиентских машинах. Выход простой: поместите LMHOSTS в сценарий регистрации, и он сам скомпонуется на клиентские машины. На машине WIN NT он помещается в каталоге \\system32\drivers\etc. На машине Windows 9.x он помещается в каталог \\windows. Нужно ли иметь больше контроллеров доменов? Обычно процесс реги- регистрации происходит между 8 и 9 часами утра. Сколько реально необходимо иметь серверов регистрации? Помните, что добавление дополнительных резервных контроллеров доменов увеличивает сетевой трафик, как мы уви- увидим в следующей главе. Это означает, что было бы плохой идеей сделать каждый сервер в сети резервным контроллером домена (что встречается достаточно часто). Используя очень консервативную оценку, один контроллер домена мо- может легко управлять 2000 пользователей. Если вернуться к нашему окну ре- регистрации, можно видеть, что в течение одного часа C600 секунд), происходит в среднем меньше двух регистрации в секунду (если запросы регистрации распределены равномерно). Что делать в такой ситуации? Прежде всего, необходимо использовать монитор производительности для создания протокола утренней деятельности по регистрации. Как можно ви- видеть на рис. 5.3, лучшим способом это сделать является создание протокола (log) монитора производительности и протокола использования памяти, процессора и серверного объекта. Для этого надо перейти во view\log и вы- выбрать соответствующие режимы. В меню режимов выбирается тип прото- протокола (log), а затем вводится имя протокола. Можно использовать, например, logon.log или добавить дату. Выберите хорошее место для разме- размещения протокола (не в корне), интервал обновления и нажмите save (со- (сохранить). Теперь необходимо добавить некоторые показатели, нажимая кнопку "плюс", как показано на рис. 5.3. Когда показатели будут добавлены, необходимо вернуться в меню ре- режимов, выбрать тип протокола (log) и запустить протокол, как показано на рис. 5.4. Это будет достаточно большой протокол, так как записи в нем появляются каждую секунду. Если после создания протокола будут замечены периоды, когда происходит множество попыток регистрации в секунду, необходимо сделать несколько дополнительных изменений.
158 Глава 5 зд Perfoimance Momior Ete ?* У»« Qpiioru H* |C4.0G0Nlog SWtur Object S«vm Мепюу Coreuiei пяйсГ VVPROX Рис. 5.З. Создание представления протокола для мониторинга трафика регистрации Log Options Savejn: (С:)  Ц] й1 li^il m I 3comiq lavery I Catalog, wci I HPFonts I InetPub I Multimedia Files C] Winzip Щ mpsselup.bg CJ Progtam Files СИ Recycler i_J Temp File дате: Save Save as type: | Log Files ("log) : Update Time Cancel Interval (seconds): Start Log ? Periodic Update A.000 С Manual Update Рис. 5.4. Созданный протокол должен быть запущен
Клиентский трафик 159 г Optimization:— 1 f \4\rirme Memory Used ; С fjalance (• Maximize Throughput lot File Sharing <~ Мдатйге Throughput foi Network Applications Г Make Browser Broadcasts to UN Manager 2.x Clients Рис. 5.5. При правильной конфигурации службы сервера можно улучшить проверку регистрации Увеличение объема одновременной проверки регистрации Когда создается контроллер домена, служба сервера оптимизирована для совме- совместного использования файлов и принтеров. Это хорошо для серверов фай- файлов и печати, но создает не оптимальную производительность для серверов регистрации. Чтобы изменить это, обратимся к сетевому апплету в панели управления (или сделаем щелчок правой кнопкой мыши по пиктограмме сети на рабочем столе), выберем сервер из закладок служб и щелкнем мы- мышью по свойствам. Как можно видеть на рис. 5.5, мы хотим выбрать макси- максимальную производительность для сетевых приложений. Затем нажмем ОК. Примечание. Необходимо перезагрузить машину, чтобы получить какой-то эффект. Делая такие изменения, контроллер домена может утроить число одновременных регистрации — от шести до почти 20 регистрации в секунду. Размещение сервера регистрации Когда речь идет о регистрации, чем ближе пользователь находится к контроллеру домена, тем лучше. Когда имеется удаленный сайт, не обязательно бездумно помещать BDC на другой стороне медленного соединения и надеяться на лучшее. Существуют также и другие ситуации. Должно быть рассмотрено влияние трафика WAN в свя- связи с синхронизацией служб каталогов. В дополнение к этому, что произой- произойдет, если линия WAN будет выключена, и службы каталогов устареют? Это только часть вопросов, которые должны быть рассмотрены до реализации. Дополнительно, скорее всего, понадобится реализовать WINS и DHCP и сконфигурировать для них репликацию, чтобы сократить этот вид трафи- трафика. Мы поговорим об этом в следующей главе, а сейчас, вероятно, лучше всего поместить BDC на другой стороне медленного соединения WAN, но это должна быть хорошо продуманная реализация. . v Просмотр Я ненавижу просмотр. Как правило, это долгий и утомительный процесс, а если и есть на свете что-то еще более отвратительное, чем неправильно ра- работающий компьютер, то это медленный компьютер. Несколько часов си- сидеть и наблюдать за тем, как на экране вспыхивают цифры... волей-неволей задумаешься о том, можно ли как-то рационализировать этот процесс.
160 Глава 5 Если просмотр не оптимизирован, то программа просмотра создает до- дополнительный трафик всякий раз, когда кто-то регистрируется в сети. Хотя автор предполагает, что читатели знакомы с концепцией просмот- просмотра, необходимо рассмотреть несколько терминов, чтобы убедиться, что речь идет об одном и том же. В системе просмотра есть пять ролей про- просмотра. При чтении следующего далее списка помните, что один компью- компьютер может выполнять более одной роли. Компьютер, выполняющий любую из этих ролей, называется броузером (browser). 1. Мастер-броузер домена. Это всегда основной контроллер домена. Он отвечает за сбор объявлений для всего домена, включая все подсети сети TCP и сетевые сегменты. Когда этот список собран, мастер-броу- мастер-броузер домена предоставляет список ресурсов всем мастер-броузерам в сети. Мастер-броузер домена может также быть мастер-броузером для своего сегмента. 2. Мастер-броузер. Мастер-броузер отвечает за сбор информации для создания и поддержания списка просмотра, который включает все серверы в домене или рабочей группе мастер-броузера, а также все домены в сети. Сервер будет делать объявление сервера для мас- мастер-броузера домена или рабочей группы, посылая направленную дейтаграмму. Это объявление сервера перечисляет все доступные на компьютере службы, и поэтому, помимо серверов NT, такие сервер- _. . ные объявления будут также делаться рабочими станциями NT, ма- машинами Windows 9.x и компьютерами Windows for Workgroup, которые предоставляют какую-либо форму совместного использова- использования файлов и печати. Мастер-броузер получает это объявление и до- добавляет компьютер в список просмотра. Если домен включает более одной подсети TCP, то мастер-броузер будет отвечать только за свой сегмент, но будет поддерживать также список резервных броузеров локальной подсети. 3. Резервный броузер. Резервный броузер получает копию списка про- просмотра от мастер-броузера и передает список по запросу компьютерам в домене. Все контроллеры домена автоматически конфигурируются либо как мастер-броузер, либо как резервный броузер. Рабочие стан- станции Windows NT, компьютеры Windows 9.x и Windows for Workgroup могут быть резервными броузерами, если в домене существует мень- меньше трех серверов NT, выполняющих функции резервного броузера. Резервные броузеры вызывают мастер^эроузер каждые 15 минут, что- чтобы получить самую последнюю копию списка просмотра, а также те- текущий список доменов в сети. Если мастерброузер недоступен, то резервный броузер будет инициировать выборы. 4. Потенциальный броузер. Потенциальным броузером является компьютер, который может поддерживать список просмотра сетевых ресурсов, но еще не имеет списка. Он будет поддерживать список про- просмотра только в том случае, если мастер-броузер прикажет это делать. В этом случае потенциальный броузер становится резервным.
Клиентский трафик 161 5. Не-броузер. He-броузер может быть специально сконфигурирован так, чтобы не поддерживать список просмотра. Не будучи сконфигури- сконфигурирован как не-броузер, компьютер будет потенциальным броузером, если он имеет активные серверные компоненты. Объявления хостов броузеров Компьютер, который предоставляет ресурсы в сети, делает объявления хо- хостов каждые 12 минут (хотя эта частота выше во время инициализации кли- клиента) для гарантии, что он правильно добавлен в список просмотра. Это объявление имеет 243 байта, как видно на распечатке ниже. Отметим, что адрес FFFFFFFFFFFF места назначения Ethernet указывает, что это широко- широковещательное сообщение. В разделе IP можно видеть, что транспортным протоколом служит UDP. Местом назначения для IP здесь также является адрес широковещания, в данном случае 10.255.255.255. Если отнять 14 бай- байтов заголовка Ethernet, то нам останется 209 байтов полезной нагрузки IP. ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + ETHERNET: Destination address : FFFFFFFFFFFF + ETHERNET: Source address : 00902764FEBF ETHERNET: Frame Length : 243 @x00F3) ETHERNET: Ethernet Type: 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data byters remaining = 229 <0x00E5) IP: ID = 0x8004; Proto = UDP; Len: 229 IP: Version = 4 @x4) IP: Header Length = 20 @x14) ,; + IP: Service Type = 0 @x0) . ¦ .. • IP: Total Length = 229 @xE5) IP: Identification = 32772 @x8004) + IP: Flags Summary = 0 @x0) IP: Fragment Offset = 0 @x0) bytes IP: Time to Live = 128 @x80) IP: Protocol = UDP - User Datagram IP: Checksum = 0xA4C9 IP: Source Address = 10.0.0.60 IP: Destination Address = 10.255.255.255 IP: Data: Number of data bytes remaining = 209 (OxOODl) Можно заметить, что объявление хоста использует порт UDP 138, кото- который является портом службы дейтаграмм NetBIOS. Хотя броузер использует направленную дейтаграмму, она по-прежнему является широковещательной A0.255.255.255). В данном случае местом назначения является домен MRED. Отметим также, что объявление броузера использует службы протокола SMB, выполняющие транзакцию С в \mailslot\browse. + UDP: Src Port: NETBIOS Datagram Service, A38); Dst Port: NETBIOS Datagram Service A38); Length = 209 (OxDl)
162 Глава 5 NBT: DS: Туре = 17 (DIRECT GROUP) ,:/..щ<5 ... ; NBT: Datagram Packet Type = DIRECT TYPE ,,,..' + NBT: Datagram Flags = 26 (OxlA) ,.- . ,.., NBT: Datagram ID = 32892 @x807C) NBT: Source IP Address = 10.0.0.60 ' "' ' NBT: Source Port = 138 @x8A) NBT: Datagram Length = 187 (OxBB) -СЛ RWH9ft*t . ,• .••..¦ NBT: Packet Offset = 0 @x0) , . .,< . . ¦•..." NBT: Source Name = 2400 NBT: Destination Name = MRED <1D> NBT: DS Data: Number of data bytes remaining = 119 @x0077) ' ' SMB: С transact, File = \MAILSLOT\BROWSE + SMB: SMB Status = Error Success + SMB: Header: PID = 0x0000 TID = 0x0000 MID = 0x0000 UID =0x0000 .'". ;. + SMB: Command = С transact SMB: Data: Number of data bytes remaining = 33 @x0021) ¦.-...- Посмотрим теперь на сам формат реального объявления хоста. Прежде всего, мы видим интервал объявления, равный 12 минутам, и имя броузера, которое определено как 2400. Сводка типа сервера сообщает службы, кото- которые выполняются на машине. Сервер 2400 выполняет как серверные ком- компоненты, так и компоненты рабочей станции, и является резервным контроллером. Сложным моментом при чтении этого раздела является то, что одни поля используют 1 для "да", а другие для "нет". Отметим, что пере- перечисленные поля не принадлежат серверу NT. Здесь мы имеем 0, означаю- означающий, что это сервер NT. Значение I в поле резервного броузера говорит, что это резервный броузер. BROWSER: Host Announcement [0x01] 2400 BROWSER: Command = Host Announcement [0x01] BROWSER: Update Count = 0 @x0) BROWSER: Announcement Interval [minutes] = 12 BROWSER: Name = 2400 BROWSER: Major Version = 4 @x4) BROWSER: Minor Version = 0 @x0) BROWSER: Server Type Summary = 13 5187 @x21013) BROWSER: 1 = Workstation BROWSER: 1. = Server BROWSER: 0 . . = Not SQL Server BROWSER: 0... = Not Domain Controller BROWSER: 1.... = Backup Controller BROWSER: 0 = Not Time Source BROWSER: 0 = Not Apple Server BROWSER: 0 = Not Novel 1 BROWSER: = Not Domain Member Server BROWSER: 0 = Not Print Queue Server BROWSER: 0 = Not Dialing Server BROWSER: 0 = Not Xenix Server BROWSER: . . 1. . . . : = Windows NT Workstation
Клиентский трафик 163 BROWSER: О = Not WFW System . ..•I.. . .. BROWSER: 0 = Not NT Server BROWSER: ...0 = Not Potential Browser ¦ i BROWSER: 1 = Backup Browser Server BROWSER: ... 0 = Not Master Server BROWSER: 0. . . . = Not Domain Master Browser : BROWSER: 0 = Not OSF BROWSER: 0 = Not VMS BROWSER: 0 = Not Windows 95 or above BROWSER: .0 = Not Local List Only BROWSER: 0 = Not Domain Enum BROWSER: Browser Election Version = 271 (OxlOF) BROWSER: Browser Constant = 43605 @xAA55) Где находятся резервные броузеры? Когда клиентской машине необходимо просмотреть сеть, прежде всего не- необходимо найти резервный броузер, который предоставит ей список сете- сетевых ресурсов. Чтобы получить список резервных броузеров, необходимо найти мастер-броузер, который, как мы знаем, хранит список резервных броузеров. Когда это сделано, она сможет обратиться к резервному броузе- броузеру и получить список просмотра. Теоретически требуются только два кадра, чтобы получить список ре- резервных броузеров. Сначала посылается простое широковещательное со- сообщение с 216-байтовым кадром, содержащим команду броузера 0x09, являющуюся запросом для получения резервного списка. BROWSER: Get Backup List Request [0x09] BROWSER: Command = Get Backup List Request [0x09] BROWSER: Get Backup List Requested Count = 4 @x4) BROWSER: Backup Request Token = 1 @x1) За ним будет следовать 226-байтовый кадр ответа, в зависимости, конеч- конечно, от числа пронумерованных серверов. Как можно видеть ниже, команда броузера ОхОа создает ответный резервный список, в котором перечислены только два резервных броузера, PROX и 2400. BROWSER: Get Backup List Response [0x0a] 2 Servers BROWSER: Command = Get Backup List Response [OxOa] BROWSER: Backup Server Count = 2 @x2) BROWSER: Backup Response Token = 1 @x1) BROSWER: Backup Servers = PROX BROWSER: Backup Servers = 2400 Когда клиентский компьютер получил список резервных серверов, мож- можно обратиться к резервному броузеру и получить список просмотра. В таб- таблице 5.5 последовательность событий для рабочей станции Windows NT требует 16 кадров. Она начинается с создания соединения SMB с \srvsvc на машине Teresa. Если это успешно завершилось, то edit делает вызов RPC функции удаленного API NetServerGetlnfo. Здесь снова работает SMB, доставляя информацию, а затем машина edit закрывает соединение.
164 Глава 5 Таблица 5.5. Процедура для получения списка просмотра Источник Место назначения Протокол Описание EDLT TERESA EDLT TERESA EDLT TERESA SMB SMB MSRPC С NT create & X, File = \srvsvc R NT create & X, FID = 0x1007 c/o RPC Bind: UUID 4B324FC8-1670-01D3-1278-5A4 7BF6EE188 ca TERESA EDLT MSRPC c/o RPC Bind Ack: call 0x3 assoc grp 0x7931 xmit 0x1630 recv EDLT TERESA EDLT TERESA EDLT TERESA EDLT TERESA EDLT TERESA EDLT TERESA TERESA EDLT TERESA EDLT TERESA EDLT ,',i.j _u TERESA EDLT TERESA EDLT TERESA EDLT R_SRVSVC R_SRVSVC SMB SMB SMB SMB MSRPC MSRPC MSRPC MSRPC SMB SMB RPC Client call srvsvc: NetrServerGetInfo(..) RPC Server response srvsvc: NetrServerGetlnfo (..) С close file, FID = 0x1007 R close file С NT create & X, File = \wkssvc R NT create & X, FID = 0x1008 c/o RPC Bind: UUID 6BFFD098-A112-3610-9833-46C 3F87E345A ca c/o RPC Nbind Ack: call 0x1 assoc grp 0x7932 xmit 0x1630 recv c/o RPC Request: call 0x1 op- num 0x0 contex 0x0 hint 0x28 c/o RPC Response: call 0x1 context 0x0 hint 0x58 cancels 0x0 С close file, FID = 0x1008 R close file После завершения этой процедуры, когда клиентская машина получает список резервных броузеров, компьютер может выбрать сервер и получить список общих ресурсов. Это может потребовать еще 18 или 19 кадров и около 2000 байтов трафика сервера для девяти перечисленных общих ре- ресурсов. Общий объем трафика зависит, конечно, от числа перечисленных на сервере общих ресурсов.
Клиентский трафик 165 Оптимизация трафика броузера Хотя просмотр сети делает достаточно удобным для некоторых пользовате- пользователей исследование ресурсов LAN/WAN, это обеспечивается за счет доста- достаточно высокой цены в терминах использования трафика. Как мы видели в этом разделе, трафик броузера с необходимыми накладными расходами и сопровождением может потребовать много байтов из доступной полосы пропускания сети. Помня об этом, нам необходимо иметь возможность со- сохранить ресурсы и найти им лучшее применение. Рассмотрим некоторые идеи. Отключение серверных служб на рабочих станциях Отключите на машинах Windows 9.x общий доступ к файлам и печати, если они в действи- действительности не предоставляют службы файлов и печати. Это поможет убрать объявления и сократит объем списка просмотра. Даже не предоставляя ни- никаких ресурсов, эти машины будут требовать записи в списке просмотра, ко- которая занимает как минимум 27 байтов. Дополнительные серверные комментарии занимают лишнее место в списке просмотра и часто не пред- представляют особой ценности. Например, сервер с именем exchange не нужда- нуждается в действительности в каком-либо дополнительном комментарии. На рабочей станции или сервере Windows NT для того, чтобы отключить сер- серверную службу, достаточно обратиться к апплету служб в панели управления, выбрать серверную службу и задать ее как manual (ручное управление). Ограничьте число потенциальных броузеров Чтобы контролиро- контролировать число выборов броузеров, появление и удаление резервных броузеров и весь связанный с этим трафик, можно ограничить количество машин в иерархии броузеров. Это требует внесения изменений в каждую машину, которые перечислены ниже. • На машине Windows NT существует настройка реестра, которую необ- необходимо изменить: HKEY_LOCAL_MACHINE\SYSTEM\CurrentCont- rolSet\Services\Browser\ Parameters\MaintainServerList должен задан как по (нет). • На машине Windows 9.x в сетевом апплете в панели управления выбе- выберите службу общего использования файлов и печати. Выберите свой- свойства (properties) и отключите параметр "browse master". • На компьютере Windows for Workgroups необходимо отредактировать файл system.ini. В разделе network добавьте MaintainServerList = no. Удалите ненужные протоколы Просмотр выполняется для каждого протокола. Если компьютер имеет четыре установленных протокола, объ- объявления броузера и выборы будут повторяться для каждого из них. Если исключить два из этих протоколов, то можно существенно сократить объем трафика броузера. Используйте ярлыки для обращения к сетевым ресурсам Удобно использовать ярлыки для обращения к часто используемым сетевым ресур- ресурсам. Они значительно быстрее и существенно сокращают сетевой трафик. Использование редактора политик и отключения сетевого окружения для
166 Глава 5 большинства пользователей поможет реально сократить сетевой трафик. Создайте папку с ярлыками для ресурсов, которые им нужны, и сделайте ее общей группой значков рабочего стола. Обзор главы ,;г В этой главе был рассмотрен трафик клиента. Мы начали с исследования источников клиентского трафика с момента включения машины. Был рас- рассмотрен DHCP при запросе машиной IP-адреса. Затем обсуждался трафик клиента WINS в ситуациях, когда компьютер пытается зарегистрировать свое имя в сети или ищет другие компьютеры для коммуникации. Мы тщательно проанализировали трафик регистрации и процесс, во- вовлеченный в поиск сервера регистрации. За этим последовали некоторые предложения по сокращению трафика. Перейдя к просмотру ресурсов, мы исследовали процесс просмотра, увидели, как работают объявления хос- хостов, как выбираются, идентифицируются и используются резервные броу- броузеры. В завершение мы узнали некоторые способы сокращения этого трафика. ,!Г.*1: '." •' • ¦>..,"! В следующей главе * В следующей главе рассматривается трафик сервера. Она начинается с ис- исследования DNS. Мы увидим, как DNS разрешает имена и использует рекур- рекурсивный поиск. Мы узнаем, как DNS интегрируется с WINS и поговорим о способах оптимизации трафика DNS. Вслед за обсуждением WINS рассматривается трафик инициализации BDC. Мы увидим, как он находит PDC и обновляет свою базу данных, и по- познакомимся со способами оптимизации трафика синхронизации учетной записи и службы NetLogon. ,,.. „ , ,,; j • ¦ I1! -л.. ¦ ¦ <U : •'.(
Глава б Серверный трафик Серверы порождают очень большой объем трафика. При этом речь идет не об обычном трафике, связанном с пересылкой файлов, службами печати и т.д. Речь идет о стоимости наличия сервера в сети. DNS Система имен доменов (DNS) является относительно эффективным прото- | колом, созданным для помощи компьютерам в преобразовании имени хоста в IP-адрес. Это старший брат WINS, который, как мы знаем из предыдущей главы, преобразует имя NetBIOS в IP-адрес. В этом загадочном мире сетей различные приложения общаются по-разному. Например, когда вводится команда net use, используется команда, которая общается с NetBIOS. Когда вводится команда ping, используется команда с именем хоста. Другой способ: DNS является файлом hosts, a WINS является файлом lmhosts. Так как DNS создан эффективным протоколом, большая часть трафика создается, когда клиентская машина запрашивает сервер DNS и получает его ответ. Определение того, как часто это происходит, поможет при оцен- оценке влияния DNS на сеть. Различаются все и все пользователи (хотя иногда они обладают раздражающе похожими характеристиками). Одним из факторов, который имеет существенное влияние на сеть, яв- является рекурсивный поиск DNS. Рекурсивный поиск происходит, когда сер- сервер DNS не может самостоятельно разрешить имя и поэтому запрашивает другой сервер DNS или даже сервер WINS. Полученный ответ передается затем клиенту в ответ на запрос. Здесь есть потенциальная возможность удвоения объема трафика, связанного с DNS. , ¦¦ ¦ ¦ Разрешение адреса Поиск DNS является простым разговором между клиентской машиной и сервером DNS. Запрос равен приблизительно 81 байту, а ответ — 97 байтам, в зависимости от количества перечисленных имен серверов. Отметим, что
168 Глава 6 DNS является направленным протоколом, и адрес MAC места назначения является реальным адресом сервера DNS, а не широковещательным адре- адресом, как в других протоколах. Кроме того, мы видим в разделе IP, что место назначения является реальным IP-адресом сервера DNS в этой сети. + ETHERNET Destination address : 0008C733F3E2 ETHERNET: Source address : 00805F36CA55 ETHERNET: 0 = No routing information present ETHERNET: ...0. = Universally administered address ETHERNET: Frame Length : 81 @x0051) ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 67 @x0043) IP: ID = OxBOEE; Proto = UDP; Len: 67 IP: Version = 4 @x4) IP: Header Length = 20 @x14) + IP: Service Type = 0 @x0) IP: Total Length = 67 @x43) IP: Identification = 45294 (OxBOEE) i + IP: Flags Summary = 0 @x0) '' IP: Fragment Offset = 0 @x0) bytes IP: Time to Live = 128 @x80) IP: Protocol = UDP - User Datagram IP: Checksum = OxlOlE '¦¦'• , IP: Source Address = 10.1.1.36 IP: Destination Address 10.1.100.120 IP: Data: Number od data bytes remaining = 47 @x002F) DNS использует протокол UDP для повышения скорости и эффективно- эффективности. В распечатке ниже отметим, что порт источника является портом, вы- выбранным клиентской машиной. В данном случае это порт 1185. Клиентская машина, однако, не выбирает порт назначения, это будет общеизвестный порт 53. UDP: Src Port: Unknown, A185); Dst Port: DNS E3); Length = 47 @x2F) UDP: Source Port = OxO4Al UDP: Destination Port = DNS UDP: Total length = 47 @x2F) bytes UDP: UDP Checksum = 0x4FFl UDP: Data: Number of data bytes remaining =39 @x0027) В распечатке ниже отметим, что счетчик запросов равен 1 @x1), а счет- счетчик ответов равен 0 @x0). Это позволяет понять, что это кадр запроса. В разделе запроса мы видим вопрос: "Где находится Donald.Duck.Com?" Это запрос адреса хоста класса адреса Интернета. Это типичный клиентский запрос DNS. DNS: OxlrStd Qry for Donald.Duck.Com. of type Host Addr on class INET addr. . DNS: Query Identifier = 1 @x1)
Серверный трафик 169 . . + DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 (Oxl) DNS: Answer Entry Count = 0 @x0) DNS: Name Server Count = 0 @x0) DNS: Additional Records Count = 0 @x0) DNS: Question Section: Donald.Duck.Com. of type Host Addr on class INET addr. DNS: Question Name: Donald.Duck.Com. DNS: Question Type = Host Address DNS: Querstion Class = Internet address class Ответ возвращается от сервера DNS в следующем формате. Отметим, что теперь счетчик ответов задан как 1 @x1), а к разделу запроса (кото- (который был перенесен из предыдущего кадра) теперь добавлен раздел отве- ответа. В разделе ответа имеется поле времени жизни, которое задается по умолчанию как 3600 секунд, длина данных из четырех байтов и IP-адрес Donald.Duck.Com. DNS: 0x1:Std Qry Resp. for Donald.Duck.Com. of type Host Addr on class INET addr. DNS: Query Identifier = 1 @x1) + DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - No error DNS: Question Entry Count = 1 @x1) DNS: Answer Entry Count = 1 @x1) ; ' '"*"¦ DNS: Name Server Count = 0 @x0) . . • DNS: Additional Records Count = 0 @x0) DNS: Question Section: Donald.Duck.Com. of type Host Addr on class INET addr. DNS: Question Name: Donald.Duck.Com. DNS: Question Type = Host Address DNS: Question Class = Internet address class :,. DNS: Answer section: Donald.Duck.Com. of type Host Addr on class INET addr. DNS: Resource Name: Donald.Duck.Com. DNS: Resourse Type = Host Address DNS: Resourse Class = Internet address class Y •. DNS: Time To Live = 3 600 (OxElO) ,. DNS: Resource Data Length = 4 @x4) - DNS: IP address = 10.1.100.3 Рекурсивный поиск Если запрошенный сервер DNS не имеет информации для удовлетворения клиентского запроса, есть две возможности: сообщить клиенту, что имя не существует, или запросить запись у другого сервера DNS, если разрешен ре- рекурсивный поиск. Клиент делает запрос серверу DNS таким же образом, как в предыдущем примере. Когда сервер проверяет свою базу данных и не находит записи, он пересылает запрос своему рекурсивному партнеру. Это, по сути, тот же кадр, за исключением того, что первый сервер DNS изменяет адрес
170 Глава б назначения со своего на адрес рекурсивного партнера. Второй сервер DNS получает запрос, как любой другой запрос DNS, ищет информацию в своей базе данных и посылает ответ первому серверу. Этот ответ выглядит как кадр ответа на распечатке выше. Первый сервер DNS получает теперь от- ответ от второго сервера DNS, изменяет адрес места назначения со своего на адрес первоначальной запрашивающей клиентской машины и посылает от- ответ клиенту. Таким образом, клиент не знает, что поиск был рекурсивным. Объединение с WINS Так же, как сервер DNS может запрашивать рекурсивный поиск у другого сервера DNS, он может запрашивать информацию у сервера WINS, если за- запись не находится в системе DNS. Это позволяет DNS содержать статиче- статические записи DNS и использовать возможности динамической регистрации имен WINS. Это происходит аналогично рекурсивному поиску DNS. Сервер DNS получает запрос с клиентской машины. Если сервер DNS не имеет ин- информации, он запросит ее у сервера WINS. Когда от сервера WINS будет по- получена запись, адрес места назначения изменяется на адрес клиента, и кадр пересылается на клиентскую машину, как если бы информация поступила с сервера DNS. Оптимизация DNS Поиск DNS требует только двух относительно небольших кадров, если инфор- информация находится на сервере. Ниже перечислены три метода сокращения трафика DNS. • Не активизируйте рекурсию. Конечно, это может ограничить функ- функциональность DNS. В таком случае обеспечьте, чтобы все хосты были помещены в DNS, но это станет проблемой при использовании DHCP, который выдает IP-адреса динамически. • Настройте рекурсию, но убедитесь, что наиболее часто используемые серверы помещены в сервер DNS. Это сократит необходимость рекур- рекурсивного поиска. • Увеличьте TTL (время жизни) кэшированных записей. Выполняя рекурсивный поиск, сервер DNS будет кэшировать запись в течение 60 минут. Имя NetBIOS, найденное с помощью WINS, будет кэширова- ться в течение 10 минут. С помощью менеджера DNS можно увели- увеличить эти используемые по умолчанию значения, выбирая свойства DNS для зоны, как показано на рис. 6.1. Инициализация BDC Когда BDC подключается к сети после перезагрузки, он может создавать зна- значительный объем трафика и требует в результате достаточно много внима- внимания со стороны PDC. Ему необходимо найти PDC и синхронизировать базу данных учетных записей и секретную базу данных LSA. Необходимо сделать различные объявления, например регистрацию имени и выборы броузера.
Серверный трафик 171 Zone Properties - u.in-addi.aipa General SOA Record j Notify | WINS Reverse Lookup | г- Record Type | r Value - I Г f Description 1 The first entry in each гопй file is «he SOA (Start of | Authority) record. It ' indicates that the specified name server is authoritative for the domain. Primary Name Server DNS Name |prox.mted Responsible Peison Mailbox DNS Name |admin.mred. Serial Number |2 Refresh Interval |60 Retry Interval Expire Time |24 Minimum Default TTL |8 | Minutes _^J: I Minutes ж | | Hours 3 lours TTL [60 3 |Minutes jj OK Cancel Рис. 6.1. Изменение кэша TTL в менеджере DNS для сокращения трафика В примере файла запуска BDC инициализация занимает 123 кадра. Что же делает BDC? Рассмотрим деятельность BDC в этом процессе. Административные изменения происходят на PDC. Они могут быть сде- сделаны где угодно, но PDC поддерживает базу данных учетных записей реаль- реальных пользователей. BDC имеет только копию, с которой работает. Поэтому важно, чтобы эта копия была актуальной. Процесс, который это гарантирует, называется синхронизацией базы данных учетных записей. Синхронизировать необходимо три отдельные базы данных: SAM (менед- (менеджер безопасности учетных записей), встроенная база данных SAM (которая содержит встроенные локальные группы, такие как administrators и users) и база данных секретных паролей LSA (уполномоченный по локальной безо- безопасности), содержащая пароли учетных записей компьютера контроллера домена и информацию о доверительных отношениях. Где находится PDC? После выполнения обычных широковещательных сообщений броузера, за- запросов ARP, регистрации имен и регистрации хостов BDC пытается найти первичный контроллер домена. Для этого он пошлет широковещательное сообщение NBT, используя порт UDP 137 (службы имен NetBIOS) в качестве порта источника и места назначения, и запросит <1В>, связанный с именем домена. Кадр запроса занимает 92 байта, а ответ — 104 байта, как отмечено
172 Глава 6 в распечатке ниже. В нашем примере отметим, что запрос предназначен для MRED, являющегося именем домена. <1В> зарегистрирован только первичным контроллером домена. Отметим, что счетчик запросов в этом кадре задан как 1, а счетчик ответов как 0, указывая, что это кадр запроса. NBT: NS: Query reg. for MRED <1B> ......,;....;; NBT: Transaction ID = 32782 @x800E) ' '; '' "' ; NBT: Flags Summary = 0x0110 - Req.; Query; Success NBT: 0 = Request NBT: .0000 = Query NBT: 0 = Non-authoritative Answer NBT: 0 = Datagram not truncated NBT: 1 = Recursion desired . NBT: 0 = Recursion not available NBT: 0 = Reserved ' NBT: 0 = Reserved , NBT: 1.... = Broadcast packet NBT: 0000 = Success NBT: Question Count = 1 @x1) NBT: Answer Count = 0 @x0) •: NBT: Name Service Count = 0 @x0) ""' , ¦ NBT: Additional Record Count = 0 @x0) NBT: Question Name = MRED <1B> NBT: Question Type = General Name Service NBT: Question Class = Internet Class Ответ возвращается немедленно с помощью кадра, приведенного ниже. Отметим, что флаги в ответе изменились, причем оба флага официального ответа изменились на противоположные. Раздел счетчика ответов задан те- теперь как 1, а счетчик запросов как 0. В самом конце кадра владелец связыва- связывается с именем MRED <1B>, предоставляя нам IP-адрес владельца 10.0.0.10. NBT: NS: Query (Node Status) resp. for MRED .....,, <1B>, Success NBT: Transaction ID = 32782 @x800E) NBT: Flags Summary = 0x8500 - Resp.; Query; Success NBT: 1 = Response NBT: .0000 = Query NBT: 1 = Authoritative Answer NBT: 0 = Datagram not truncated NBT: 1 = Recursion desired NBT: 0 = Recursion not available NBT: 0 = Reserved NBT: 0 = Reserved NBT: 0.... = Not a broadcast packet NBT: 0000 = Success NBT: Question count = 0 @x0) NBT: Answer Count = 1 @x0) ; •. ¦ NBT: Name Service Count = 0 @x0) •:.. NBT: Additional Record Count = 0 @x0) NBT: Resource Record Name = MRED <1B> NBT: Resource Record Type = NetBIOS General Name Service
Серверный трафик 173 NBT: Resource Record Class = Internet Class NBT: Time to Live 300000 @x493E0) NBT: RDATA Length = 6 @x6) NBT: Resource Record Flags = 24576 @x6000) NBT: 0 = Unique NetBIOS Name NBT: .00 = В Node NBT: ...0000000000000 = Reserved NBT: Owner IP Address = 10.0.0.10 После обмена этими кадрами BDC пошлет дейтаграмму UDP на порт 138 службы дейтаграмм NetBIOS. Она посылается как ненадежное почто- почтовое сообщение в \mailslot\net\netlogon на машине, IP-адрес которой вер- вернулся в предыдущем запросе. Это делается для того, чтобы извлечь имя первичного контроллера домена. Отметим, что в разделе NetLogon кадра указано имя запрашивающего компьютера, имя почтового ящика, а также различные поддерживаемые версии Lanman. Этот раздел не должен повто- повторять перечисленную выше информацию, так как кадр посылается прямо указанной машине. NETLOGON: Query for Primary DC NETLOGON: Opcode = Query for Primary DC NETLOGON: Computer name = 2400 NETLOGON: Mailslot Name = \MAILSLOT\NET\GETDC116 NETLOGON: Unicode Computer Name = 2400 NETLOGON: NT Version = 1 @x1) NETLOGON: LMNT Token = WindowsNT Networking NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later) Networking Ответ возвращается из PDC. Отметим, что формат этого раздела изме- изменился незначительно. В поле opcode, которое говорит нам, что это ответ на первичный запрос, мы видим имя PDC, в данном случае PROX. Имя PDC в формате Unicode также PROX, а имя домена MRED. NETLOGON: Response to Primary Query NETLOGON: Opcode = Response to Primary Query NETLOGON: Primary PC Name = PROX NETLOGON: Pad = 0 @x0) NETLOGON: Unicode Primary DC Name = PROX NETLOGON: Unicode Domain Name = MRED NETLOGON: NT Version = 1 @x1) NETLOGON: LMNT Token = WindowsNT Nerworking NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later) Networking Теперь, когда основной контроллер домена найден, необходимо создать сеанс. Для этого сначала выполняется трехходовое квитирование (допол- (дополнительную информацию о трехходовом квитировании см. в главе 2). Затем мы создаем сеанс NetBIOS, как показано на распечатке ниже. Это кадр за- запроса сеанса NTB (показанный как packet type = session request) 0x81 из BDC. Вызывающее имя 2400 является именем BDC; в данном случае он
174 Глава б направляется PDC (вызванное имя PROX является в этом случае именем PDC). Это маленький кадр, длиной только 126 байтов, содержащий заголо- заголовок Ethernet. Портом источника в данном случае является порт 1025, кото- который можно увидеть в трассировке (BDC initialize.cap) на сайте издательства "ЛОРИ" (www.lory-press.ru). Порт места назначения — это общеизвестный порт 139 (сеанс NBT 0х8В). NBT: SS: Session Request, Dest: PROX , Source: 2400 <00>, Len: 68 NBT: Packet Type = Session Request ( . :, ,,.-. NBT: Packet Flags = 0 @x0) ". ' !.,,., ; NBT: 0 = Add 0 to Length " "; NBT: Packet Length = 68 @x44) ''"''' i;; ''i!l "' ¦¦ ! NBT: Called Name = PROX ¦ ' ;il" ' '"", ! :':' NBT: Calling Name = 2400 ¦ <0Q> ':''¦• '• ." Г>Щ Рассмотрим кадр ответа. Сетевой монитор подробно разбирает кадр, и в разделе NBT кадра можно видеть, что это "тип пакета = положительный от- ответ на сеанс @x82)". Этот кадр, который еще меньше кадра запроса NetBIOS (только 58 байтов составляют заголовок Ethernet), посылается от PDC (PROX) в BDC B400). В данном случае портом источника будет 139, а портом места назначения будет 1025 на BDC. NBT: SS: Positive Session Response, Len: 0 NBT: Packet Type = Positive Session Response NBT: Packet Flags = 0 @x0) NBT: 0 = Add 0 to Length \ . NBT: Packet Length = 0 @x0) Требуются только два кадра и 184 байта, чтобы создать сеанс NetBIOS между BDC и PDC. Теперь необходимо выполнить согласование протокола SMB. Для этого нужны два кадра и дополнительно 373 байта трафика в сети. Эти кадры используют те же порты, что и при предыдущем обмене; т.е. на BDC они приходят из порта 1025, а на PDC направляются в порт 139. Посмотрим на эти кадры в распечатке ниже. (Подробнее о согласовании диалекта SMB см. в главе 4.) Мы видим раздел SMB кадра из BDC, когда он пытается согласовать с PDC диалект, который будет использоваться при коммуникации. Мы видим, что TID, UID и MID заданы как 0x0; однако PID задан как OxCAFE. Разделы flags и flags2 аналогичны соответствующим раз- разделам, которые были подробно рассмотрены в главе 4, поэтому здесь не об- обсуждаются. Мы видим команду SMB С negotiate и строки диалектов, понятные BDC. Если начать считать с 0 (как практически всегда делает компьютер), можно заметить, что диалект #7 - это NT LM 0.12. SMB: С negotiate. Dialect = NT LM 0.12 SMB: SMB Status = Error Success SMB: Error class = No Error '' SMB: Error code = No Error SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000 UID = 0x0000 SMB: Tree ID (TID) = 0 @x0)
Серверный трафик 175 SMB: Process IP (PID) = 51966 (OxCAFE) SMB: User ID (UID) = 0 @x0) SMB: Multiplex ID (MID) = 0 @x0) SMB: Flags Summary = 24 @x18) SMB: flags2 Summary = 3 @x3) : SMB: Command = С negotiate SMB: Word count = 0 SMB: Byte count = 135 -(,- SMB: Byte parameters SMB: Dialect Strings Understood 3.1а 4', j.\ ,':К: SMB: Dialect String: SMB: Dialect String: SMB: Dialect String: SMB: Dialect String: SMB: Dialect String: SMB: Dialect String: SMB: Dialect String: PC NETWORK PROGRAM 1.0 XENIX CORE MICROSOFT NETWORK 1.03 LANMAN1.0 Windows for Workgroups LM1.2X002 LANMAN2.1 ' "¦¦ ~""'v SMB: Dialect String: NT LM 0.12 Теперь рассмотрим ответ от PDC для BDC, чтобы понять, как они разре- разрешают свои коммуникационные вопросы. Это 145-байтовый кадр (включая 14-байтовый заголовок Ethernet), который выходит из порта 139 на сторо- стороне PDC и идет в порт 1025 на стороне BDC. Отметим в распечатке ниже, что статус SMB определен как error success, что означает отсутствие оши- ошибок в этом разделе. Здесь снова нет TID, UID или MID, но имеется PID (OxCAFE), который совпадает с PID в предыдущем кадре. Командой SMB яв- является С negotiate. Отметим, что Protocol Index был выбран равным 7, что соответствует диалекту NT LM 0.12 из предыдущего кадра. Другие интере- интересующие моменты здесь также согласованы. Это NT Max Buffer Size D356) и Max Row Size F5636), которые обсуждаются в главе 4. Интерес вызывает имя домена, обозначенное как ???. Это связано с тем, что канал 1РС$ не был создан. Это следующее, что нужно сделать. SMB: R negotiate, Dialect # = 7 • . SMB: SMB Status = Error Success :; SMB: Error class = No error SMB: Error code = No error SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000 UID = 0x0000 SMB: SMB: Tree ID Process ID SMB: User ID SMB: Multiplex ID (TID) = 0 @x0) (PID) = 51966 (OxCAFE) (UID) = 0 @x0) (MID) = 0 @x0) SMB: Flags Summary = 152 @x98) SMB: flags2 Summary = 3 @x3) - SMB: Command = С negotiate SMB: Word count =17 SMB: Word parameters SMB: Protocol Index = 7 + SMB: Security Mode Summary (NT) = 3 @x3)
176 Глава б SMB: Max MPX requests =50 SMB: Max VCs = 1 @x1) SMB: NT Max Buffer Size = 4356 @x1104) . SMB: Max Row Size = 65536 @x10000) SMB: Session Key = 0 + SMB: Capabilities = 17405 @x43FD) SMB: Server Time = Aug 21, 1999 19:6:3.84 SMB: Server time zone = 240 (OxFO) SMB: Encryption key length = 8 @x8) SMB: Byte count = 18 SMB: Byte parameters SMB.- Domain name = ??? Теперь нам необходимо создать соединение с общим ресурсом 1РС$. Это используемый по умолчанию общий ресурс, созданный Windows NT (ино- (иногда называемый одним из административных общих ресурсов) для межпро- межпроцессной коммуникации. Он использует NetBIOS, и в этом случае NetBIOS перемещается поверх TCP, перемещающегося, в свою очередь, поверх IP, который перемещается поверх Ethernet. Этот кадр, содержащий 230 бай- байтов, поступает в порт 139 службы сеанса NetBIOS. Этот кадр содержит две команды SMB. Первая — С session service & X — используется для настройки сеанса. Вторая — С tree connect & X — сообщает нам, что BDC желает соеди- соединиться с общим ресурсом 1РС$. Этот раздел всегда сообщает имя файла, но существуют другие флаги, означающие, что это в действительности не файл, но просто способ, которым SMB ссылается на объекты в этой области. SMB: С session setup & X, Username = , and C tree connect & X, Share = \\PROX\IPC$ + SMB: SMB Status = Error Success ¦-• -'. + SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000 UID = 0x0000 : ..¦-. SMB: Command = С session setup & X SMB: Word count =13 SMB: Word parameters SMB: Next offset = 0x0084 SMB: Max Buffer Size = 4356 @x1104) ••' SMB: Max MPX requests =50 . ., SMB: VC number =0 ¦ • -¦ SMB: Session Key = 0 . SMB: Password length = 1 @x1) SMB: Unicode Password length = 0 @x0) + SMB: Capabilities = 212 @xD4) SMB: Byte count =71 SMB: Byte parameters SMB: Account name = SMB: Domain name = SMB: Native OS = Windows NT 13 81 SMB: Native Lanman = Windows NT 4.0 SMB: Command С tree connect & X SMB: Word count = 4 SMB: Word paramters
Серверный трафик 177 ¦ SMB: Next offset = 0x0000 " SMB: Discount flag = 0x0000 \'' '"'' SMB: Password length = 1 @x1) •' ¦ ' : SMB: Byte count = 29 -- ¦.: . ¦ ; ' ¦¦¦¦¦''' . SMB: Byte paramters • ¦ ¦•_¦•¦ ¦ ¦ ¦ :'• 'л ; SMB: Password = i .' " : . .-¦¦ - SMB: File name = \\PROX\IPC$ . . : SMB: Service Name = IPC SMB: Command = No secondary command Теперь мы подошли к ответу от PDC для BDC. Этот ответ, представлен- представленный в распечатке ниже, сообщает, что мы соединились с общим ресурсом 1РС$. Мы видим, что ошибок нет (error success), и первой командой SMB яв- является С session setup & X с именем домена MRED, который является на- нашим доменом. Следующей командой является С tree connect 8c X для службы имен IPC. Этот кадр имеет размер 194 байта. Таким образом, это взаимодействие требует двух кадров и 424 байта для создания соединения с общим ресурсом 1РС$. + SMB: SMB Status = Error Success + SMB: Header: PID = OxCAFE TID = Ox 7807 MID = 0x0000 UID = 0xC803 SMB: Command = С session setup & X SMB: Word count = 3 SMB: Word parameters SMB: Next offset = 0x0078 + SMB: Setup action = 0x0000 SMB: Byte count =79 SMB: Byte parameters SMB: Native OS = Windows NT 4.0 SMB: Native Lanman = NT LAN Manager 4.0 SMB: Domain name = MRED SMB: Command = С tree connect & X SMB: Word count = 3 SMB: Word parameters . . SMB: Next offset = 0x0088 + SMB: Optional Support = 1 @x1) SMB: Byte count = 7 SMB: Byte parameters SMB: Service Name = IPC SMB: Native FS = L?i?? ' SMB: Command = No secondary command Процесс создания сеанса с PDC потребовал девять кадров и использовал около 1200 байтов трафика. Конечный шаг синхронизации базы данных SAM состоит в создании защищенного канала с первичным контроллером домена. Этот трафик будет происходить только во время инициализации системы, так как защищенный канал всегда существует, если только одна из машин не выключена. Это позволяет создавать новые сеансы, когда истека- истекает срок действия, и сразу выполнять проверку и обновление, не требуя со- создания нового защищенного канала. Все это сберегает сетевую полосу пропускания и ускоряет время доступа.
178 Глава 6 Первый шаг в установлении защищенного канала с PDC состоит в созда- создании запроса на открытие именованного канала с NetLogon, для некоторых вызовов API (прикладного программного интерфейса) службы NetLogon. Посмотрим на распечатку ниже. В этом кадре мы видим только одну команду SMB — команду С NT create & X, направленную в файл \NetLogon. Флаги со- сообщают тип требуемого доступа, и если этот файл не существует, то команда откажет. Create Flags DWord 0x00000006 сообщает, что она запрашивает одновременно Oplock и OpBatch. SMB: С NT create & X, File = \NETLOGON '¦ ' ' : :' *: • '*'' + SMB: SMB Status = Error Success SMB: Header: PID = 0.0x5020 TID = 0x7807 MID = 0x0040 1 • UID = 0xC803 SMB: Tree ID (TID) = 30727 @x7807) ; t-, ... ", SMB: Process ID (PID) = 20512 @x5020) [ ,..-...:--»----. SMB: User ID (UID) = 51203 @xC803) SMB: Multiplex ID (MID) = 64 @x40) ' ' + SMB: Flags Summary = 24 @x18) + SMB: flags2 Summary = 32771 @x8003) SMB: Command = R NT create & X ¦ ,• ,: SMB: Word count = 24 ' .-,: SMB: Word parameters SMB: Next offset = 0x0000 SMB: Word count =24 SMB: Word parameters SMB: Name Length (NT) = 18 @x12) SMB: Create Flags DWord = 0x00000006 SMB: Root Dir FID = 0x00000000 SMB: Desired Access = 0x0002019F SMB: File Allocation Size = 0x0000000000000000 + SMB: NT File Attributes = 0x00000000 SMB: File Share Access = 0x00000003 SMB: Create Disposition = Open: If exist, Open, else fail + SMB: Create Options = 0 @x0) SMB: Impersonation Level = 0x00000002 SMB: Security Flags = 0x01 SMB: 1 = dynamic tracking SMB: 0. = effective only bit not set SMB: Byte count = 21 SMB: File name = \NETLOGON - .:. ¦ ¦ Рассмотрим ответ PDC на предыдущий кадр. Прежде всего мы видим, что состояние SMB говорит об отсутствии ошибок. Используется команда R NT create & X, которая сообщает нам ответ. Отметим, что TID, PID, UID и MID совпадают с предыдущим кадром. Интересный момент здесь состоит в том, что в предыдущем кадре, хотя он запрашивает Oplock, текущий уровень Oplock отсутствует. Мы видим также, что действие по созданию является файлом, который был открыт. Отметим также, что тип файла является именованным каналом в режиме сообщения, который и предполагалось увидеть.
Серверный трафик 179 SMB: R NT create & X, FID = 0x802 + SMB: SMB Status = Error Success SMB: Header: PID = 0x5020 TID = 0x7807 MID = 0x0040 UID = 0xC803 SMB: Tree ID (TID) = 30727 @x7807) SMB: Process ID (PID) = 20512 @x5020) SMB: User ID (UID) = 51203 @xC803) SMB: Multiplex ID (MID) = 64 @x40) + SMB: Flags Summary = 152 @x98) + SMB: flags2 Summary = 32771 @x8003) SMB: Command = R NT create & X ; SMB: Word count =34 SMB: Word parameters SMB: Next offset = 0x0067 SMB: Word count =34 SMB: Word parameters SMB: Oplock Level = NONE SMB: File ID (FID) = 2050 @x802) SMB: File name = \NETLOGON SMB: Create Action = File Opened SMB: Creation Time = Jan 1, 1601 0:0:0.0 SMB: NT Last Access Time = Jan 1, 1601 0:0:0.0 SMB: Last Write Time = Jan 1, 1601 0:0:0.0 SMB: Change Time = Jan 1, 1601 0:0:0.0 + SMB: NT File Attributes = 0x00000080 SMB: File Allocation Size = 0x0000000000001000 SMB: End of File = 0x0000000000000000 SMB: Device state 0x05FF SMB: Boolean Is Directory = 0 @x0) В двух предыдущих кадрах мы успешно создали именованный канал со службой NetLogon, чтобы можно было сделать RPC (вызов удаленной про- процедуры) вызовов API. Для этого потребуются два кадра и 323 байта. Теперь необходимо создать соединение RPC между PDC и BDC. Это происходит с помощью кадров RPC связывания и подтверждения связывания. Взгляните на первый из этих двух кадров на распечатке ниже. Первый кадр будет ис- использовать команду SMB С transact TransactNmPipe в файл NetLogon. Та- Таким образом, в этом кадре теперь используются протоколы MSRPC (удаленный вызов процедур Microsoft), SMB, TCP, IP и Ethernet. Распечатка ниже создана из 214-байтового кадра. Это тип пакета связывания RPC, где не задано никаких флагов. Параметры флагов раскрыты ниже, но обратите внимание, что каждый имеет значение 0, указывая, что флаг не задейст- задействован. Абстрактный интерфейс использует UUID (универсальный уникаль- уникальный идентификатор), который является строкой уникальной идентифика- идентификации, связанной с интерфейсом вызова удаленной процедуры. Он иногда называется также GUID (глобальный уникальный идентификатор). В кадре ниже UUID задан как 12345678-1234-ABCD-EF00- 01234567CFFB. MSRPC: с/о RPC Bind: UUID 12345678-1234-ABCD-EF00- 01234567CFFB call 0x1 assoc grp 0x0 xmit 0x1630 recv 0x1630 MSRPC: Version = 5 @x5)
180 Глава б MSRPC: Version (Minor) = 0 @x0) ¦ • ¦ MSRPC: Packet Type = Bind ' ' ' MSRPC: Flags 1=0 @x0) MSRPC: 0 = Reserved -or- Not the first fragmrnt (AES/DC) MSRPC: 0. = Not a last fragment -or- No cancel pending MSRPC: 0.. = Not a fragment -or- No cancel pending (AES/DC) MSRPC: ....0... = Receiver to respond with a fack PDU -or- Reserved (AES/DC) MSRPC: ...0.... = Not used -or- Does not support concurrent multiplexing (AES/DC) MSRPC: ..0 = Not for an idempotent request -or- Did not execute guaranteed call (Fault PDU only) (AES/DC) MSRPC: .0 = Not for a broadcast request -or- "Maybe1 call semantics not requested (AES/DC) MSRPC: 0 = Reserved -or- No object UUID specified in the optional object field (AES/DC) MSRPC: Packet Data Representation MSRPC: Fragment Length = 72 @x48) MSRPC: Authentication Length = 0 @x0) MSRPC: Call Identifier = 1 @x1) MSRPC: Max Trans Frag Size = 5680 @x1630) MSRPC: Max Recv Frag Size = 5680 @x1630) MSRPC: Assoc Group Identifier = 0 @x0) MSRPC: Presentation Context List MSRPC: Number of Context Elements = 1 @x1) MSRPC: Presentation Context Identifier = 0 @x0) MSRPC: Number of Transfer Syntaxs = 1 @x1) MSRPC: Abstract Interface UUID = 12345678-1234- ABCD-EF00-01234567CFFB ..¦ • . MSRPC: Abstract Interface Version = 1 @x1) MSRPC: Transfer Interface UIID = 8A885D04-1CEB- 11C9-9FE8-08002B104860 MSRPC: Transfer Interface Version = 2 @x2) Ответ приходит из PDC. Это кадр подтверждения связывания RPC, как видно в распечатке ниже. В нем заданы два флага @x3). Это те же поля фла- флагов, которые мы видели в кадре выше, и первая позиция сообщает нам, что это первый фрагмент, а вторая позиция — что это последний фрагмент @x3). Связанным идентификатором группы, который используется для от- отслеживания, будет 106023 @х19Е27). Отметим, что UUID интерфейса пере- передачи является таким же, как и в предыдущем кадре. Этот интерфейс RPC используется для передачи команд туда и обратно. ; MSRPC: с/о RPC Bind Ack: call 0x1 assoc grp 0xl9E27 xmit 0x1630 recv 0x1630 MSRPC: Version = 5 @x5) ' ' '' MSRPC: Version (Minor) = 0 @x0) MSRPC: Packet Type = Bind Ack MSRPC: Flags 1=3 @x3)
Серверный трафик 181 : MSRPC: Packet Data Representation .. ;.. MSRPC: Fragment Length = 68 @x44) , ... ¦; MSRPC: Authentication Length = 0 @x0) MSRPC: Call Identifier = 1 @x1) MSRPC: Max Trans Frag Size = 5680 @x1630) MSRPC: Max Recv Frag Size = 5680 @x1630) MSRPC: Assoc Group Identifier = 106023 @xl9E27) MSRPC: Secondary Address MSRPC: Secondary Address Length = 12 (OxC) MSRPC: Secondary Address Port ; : MSRPC: Padding Byte(s) MSRPC: Result List MSRPC: Number of Results = 1 @x1) MSRPC: Reserved = 0 @x0) MSRPC: Reserved 2 MSRPC: Presentatuion Context Results MSRPC: Result = Acceptance MSRPC: Reason = Reason not specified MSRPC: Transfer Syntax MSRPC: Transfer Interface UUID = 8A885D04- 1CEB-11C9-9FE8-08002B104860 MSRPC: Transfer Interface Version = 2 @x2) Теперь, когда соединение RPC между двумя контроллерами доменов со- создано (с помощью двух кадров и 396 байтов), BDC должен создать защищен- защищенный канал. Это будет сделано после проверки полномочий BDC. Для этого потребуются четыре кадра. В распечатке ниже можно видеть, что резерв- резервный контроллер домена посылает NetrServerReqChallenge, чтобы запро- запросить проверку имени учетной записи BDC, которая существует на первичном контроллере домена. Этот вызов NetrServerReqChallenge дела- делается службе NetLogon с помощью RPC. Отметим также, что в разделе пол- полномочий (credential) он сообщает Client-Challenge. Это указывает, что запрос идет с клиентской машины. R_LOGON: RPC Client call logon:NetrServerReqChallenge(..) R_LOGON: LOGONSRV_HANDLE PrimaryName = WPROX R_LOGON: wchar_t ComputerName = 2400 R_LOGON: PNETLOGON_CREDENTIAL ClientChallenge {..} R_LOGON: CHAR data [..] = 9A 53 AC F4 00 FF B2 01 Ответ возвращается из PDC, как показано ниже. Мы по-прежнему испо- используем в этом месте вызов NetrServerReqChallenge. Этот кадр приходит из порта 139 на PDC и поступает в порт 1025 на BDC, как и все остальные кадры, которые до сих пор рассматривались в этом разделе. Отметим, что раздел полномочий содержит ServerChallenge, что указывает на сообщение с сер- серверной машины. R_LOGON: RPC Server response logon: NetrServerReqChallenge(..) + R_LOGON: PNETLOGON_CREDENTIAL ServerChallenge (..) R_LOGON: Return Value = 0 @x0)
182 Глава 6 Теперь мы подошли к третьему кадру в этом обмене. BDC проверяет па- пароль учетной записи на PDC, используя вызов API NetrServerAuthenticate2. В распечатке ниже мы видим имя сервера регистрации \\prox и имя учет- учетной записи 2400$. Знак $ в конце имени учетной записи указывает, что это "скрытое" имя учетной записи, используемое прежде всего для администра- административных целей. В данном случае это учетная запись, которая использовалась для создания защищенного канала. Мы видим также имя компьютера 2400 и ClientCredential, это является указанием на то, что кадр с клиентской машины. • R_LOGON: RPC Client call logon: NetrServerAuthenticate2(..) R_LOGON: LOGONSRV_HANDLE PrimaryName = WPROX R_LOGON: wchar_t AccoutName = 2400$ R_LOGON: NETLOGON_SECURE_CHANNEL_TYPE AccountType = 6 @x6) R_LOGON: wchar_t ComputerName = 2400 + R_LOGON: PNETLOGON_CREDENTIAL ClientCredential {..} R_LOGON: PULONG NegotiateFlags = 1073742335 @x400001FF) Мы пришли к последнему кадру в этом разделе. Наконец, все сеансы и защищенный канал созданы. Теперь мы имеет ответ сервера RPC. Он снова использует вызов API NetrServerAuthenticate2. Отметим раздел полномо- полномочий, который утверждает, что это ServerCredential, указывая на то, что он прибыл с машины сервера. . : ¦ • =.• ., т¦•¦¦, .-, .. R_LOGON: RPC Server response logon: NetServerAuthenticate2(..) + R_LOGON: PNETLOGON_CREDENTIAL ServerCredential {..} R_LOGON: PULONG NegotiateFlags = 1073742335 @x400001FF) R_LOGON: Return Value = 0 @x0) Для создания защищенного канала требуются четыре кадра и 794 байта. Теперь мы готовы проверить базу данных учетных записей пользователей. Как было указано ранее, необходимо проверить три базы данных. Это база данных учетных записей SAM, которая содержит учетные записи пользова- пользователя и группы, созданные администратором; встроенная база данных SAM, которая имеет стандартные группы и учетные записи NT; и секретная база данных LSA, которая содержит пароли учетных записей компьютера, а так- также пароли для доверительных отношений. Для каждой из этих баз данных будет делаться клиентский вызов RPC, когда начнется процесс проверки базы данных учетных записей пользователей. Каждый из этих клиентских вызовов будет извлекать соответствующий ответ из PDC. Мы знаем, что с этим процессом связано шесть кадров, но не знаем, сколько реального тра- трафика будет создано, так как это зависит в некоторой степени от числа тре- требуемых обменов. Если желательно рассмотреть эти кадры более подробно, обратитесь к кадрам 59-64 в файле ВВС initizize.cap на сайте издательства "ЛОРИ" (www.lory-press.ru) Первый кадр содержит одну команду: NetrDatabaseDeltas. Конечно, эта команда направлена в IP-адрес PDC в общеизвестный порт 139, свя- связанный со службой сеанса NetBIOS. Мы по-прежнему начинаем на BDC из порта 1025.
Серверный трафик 183 R_LOGON: RPC Client call logon:NetrDatabaseDeltas(..) Второй кадр содержит ответ на вызов NetrDatabaseDeltas, который был послан BDC. Этот кадр является ответом PDC для BDC, и он содер- содержит все изменения, которые необходимо сделать в первой базе данных. Эти изменения перечислены в последнем разделе кадра. R_LOGON: RPC Server response logon:NetrDatabaseDeltas(..) + R_LOGON: PNETLOGON_AUTHENTICATOR ret_auth {..} + R_LOGON: PNLPR_MODIFIED_COUNT DomainModifiedCount {..} R_LOGON: PNETLOGON_DELTA_ENUM_ARRAY DeltaArray {..} R_LOGON: DWORD CountReturned = 1352648495 @x509FC72F) R_LOGON: PNETLOGON_DELTA_ENUM Deltas = 3072610600 @xB72451128) R_LOGON: PNETLOGON_DELTA_ENUM Deltas [..] + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R__LOGON: PNETLOGON_DELTA_ENUM Deltas {..} : + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} '" BDC снова посылает команду NetrDatabaseDeltas, чтобы начать процесс верификации для второй базы данных. R_LOGON: RPC Client call logon:NetrDatabaseDeltas(..) ' ¦¦¦¦'¦¦ Ответ приходит от PDC с изменениями, перечисленными ниже. R_LOGON: RPC Server response logon:NetrDatabaseDeltas(..) + R_LOGON: PNETLOGON_AUTHENTICATOR ret_auth {..} + R_LOGON: PNLPR_MODIFIED_COUNT DomainModifiedCount {..} ' R_LOGON: PNETLOGON_DELTA_ENUM_ARRAY DeltaArray {..} R_LOGON: DWORD CountReturned = 1607628464 @x5FD276B0) R_LOGON: PNETLOGON_DELTA_ENUM Deltas = 3144190501 @xBB688A25) R_LOGON: PNETLOGON_DELTA_ENUM Deltas [..] + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}' + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} ., . • + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} \ BDC посылает команду NetrDatabaseDeltas в третий раз. R_LOGON: RPC Client call logon:NetrDatabaseDeltas(..) Последний кадр в этом диалоге приходит из PDC в ответ на команду Ne- NetrDatabaseDeltas. Каждый из разделов RJLogon имеет рядом с собой знак +, указы- указывающий, что под заголовком находится дополнительная информация. Для более подробного рассмотрения ее можно найти на сайте издательства "ЛОРИ" (www.lory-press.ru).
184 '""" Глава 6 R_LOGON: RPC Server response logon:NetrDatabaseDeltas(..) + R_LOGON: PNETLOGON_AUTHENTICATOR ret_auth {..} ¦ ¦ + R_LOGON: PNLPR_MODIFIED_COUNT DomainModifiedCount {..} R_LOGON: PNETLOGON_DELTA_ENUM_ARRAY DeltaArray {..} R_LOGON: DWORD CountReturned =69777434 : @x428B8lA) R_LOGON: PNETLOGON_DELTA_ENUM Deltas = 3587951417 @xD5DBCB39) R_LOGON: PNETLOGON_DELTA_ENUM Deltas [..] + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} Здесь потребовалось шесть кадров и 1584 байта (включая заголовки Ethernet) для проверки базы данных учетных записей пользователей. Эти кадры включают очень немного, что приводит к весьма незначительной синхронизации учетной записи. Если бы было много изменений, то могло бы потребоваться больше шести кадров и было бы создано более 1584 байтов трафика. Обновления в базе данных PDC по умолчанию будет проверять свою базу данных каждые пять ми- минут. Если будут обнаружены изменения в любой из трех баз данных, то он пошлет сообщение всем резервным контроллерам домена, указывая изменение в SAM. PDC имеет таблицу каждого BDC, которая содержит идентификатор версии каждой из его баз данных. Если BDC имеет актуа- актуальную базу данных и не требуется никаких изменений, то она не будет модифицироваться. Windows NT 4.0 будет посылать объявление обновления одновременно максимум десяти BDC, чтобы не перегружать полосу пропускания сети. Эту величину можно, конечно, изменить для ситуаций, где полоса пропускания не является проблемой. Преимущество управления обновлениями состоит в сокращении использования полосы пропускания сети. Обратной стороной этого будет увеличение времени для изменения всех BDC. Как можно видеть на распечатке ниже, PDC выполняет команду "Announce Change to UAS or SAM". Отметим, что кадр включает имя PDC и имя доме- домена. Он содержит также порядковый номер, используемый для сравнения версий базы данных. Этот кадр посылается из PDC прямо в BDC. Это не широковещательный кадр; он посылается в порт UDP 138, который являет- является портом службы дейтаграмм NetBIOS. Это дейтаграмма, направленная в \mailslot\net\NetLogon. NETLOGON: Announce Change to UAS or SAM NETLOGON: Opcode = Announce Change to UAS or SAM NETLOGON: Low Serial Number = 210 @xD2) NETLOGON: Data and Time = 909938475 @x363C8F2B)
Серверный трафик 185 NETLOGON: NETLOGON: NETLOGON: NETLOGON: NETLOGON: NETLOGON: NETLOGON: + NETLOGON: + NETLOGON: + NETLOGON: NETLOGON: NETLOGON: 00 00 5D 5B 3F NETLOGON: ¦( Pulse = 7200 @xlC20) : .<( 7,v,.-, Random = 1 @x1) ''" r'- ¦ ¦ "ч Primary DC Name = PROX ; . . Domain Name = MRED Unicode Primary DC Name = PROX Unicode Domain Name = MRED DB Count = 3 @x3) DBChange Info Structure, DB Info = 0x0000 DBChange Info Structure, DB Info = 0x0001 DBChange Info Structure, DB Info = 0x0002 Domain SID Size = 24 @x18) Domain SID = 01 04 00 00 00 00 00 05 15 00 41 El 24 ЗС ЗА c7 . . . NT Version = 1 @x1) В таблице 6.1 содержится оставшаяся часть общения, требуемая для об- обновления базы данных. Отметим, что вслед за кадром объявления PDC мы видим такие же вещи, которые были подробно рассмотрены ранее в этой главе. BDC делает соединение именованным каналом с NetLogon, создает сеанс RPC и затем обновляет базу данных, используя RPC для вызова API NetrDatabaseDeltas. После обновления базы данных она использует SMB для разъединения и выхода из системы. Таблица 6.1. Последовательность периодических обновлений контроллера домена Источник Ргох 2400 Ргох 2400 Ргох 2400 Ргох 2400 2400 Ргох 2400 Ргох Место назначения 2400 Ргох 2400 Ргох 2400 ' Ргох 2400 Ргох Ргох 2400 Ргох ; 2400 Протокол NETLOGON SMB SMB MSRPC MSRPC R_LOGON R_LOGON TCP SMB SMB SMB SMB Описание Announce Change to UAS or SAM С NT Create & X, File = \NETLOGON R NT create & X, FID = Ox 100a c/o RPC Bind: UUID 12345678-1234-ABCDEF00-01234567C FFB call 0x1 assoc grp 0x0 xm c/o RPC Bind Ack: call 0x1 assoc grp 0x2A0A2 xmit 0x1630 recv 0x1630 RPC Client call logon:NetrDatabase- Deltas(..) RPC Server response logon:NetrData- baseDeltas(..) .A...., len: 0; seq: 15861295-15861295, ack: 235568, win: 8760, src: 1072 dst: 139 С tree disconnect R tree disconnect ..¦¦¦'. Clogoff&X R logoff &X
186 Глава б Оптимизация трафика синхронизации учетных записей Можно сделать кое-что для оптимизации трафика синхронизации учетных записей пользователей в базах данных. Эта оптимизация включает редакти- редактирование реестра и настройку параметров, связанных со службой NetLogon. В обычном реестре эти ключи даже не присутствуют — они должны быть добавлены вручную. На рис. 6.2 показан контроллер домена, в котором до- добавлены эти дополнительные параметры для ключа NetLogon. Как мож- можно видеть внизу рисунка, эти параметры расположены в HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\parameters. На сайте издательства "ЛОРИ" (www.lory-press.ru) находятся эти записи, сохраненные как файл с расширением .REG. Делая по нему двойной щел- щелчок мышью, можно внести их в реестр на используемой машине, однако, НЕ делайте это добавление на рабочей машине. Также убедитесь, что ис- исходный реестр сохранен, прежде чем делать какие-либо изменения. По крайней мере, сохраните этот ключ, прежде чем делать изменение. Преж- Прежде чем реализовывать, необходимо рассмотреть каждое из этих значений с его достоинствами и недостатками. Кроме того, НЕОБХОДИМО знать, ка- каким будет влияние каждого из них, прежде чем они будут добавлены. Когда они будут добавлены, нужно перезагрузить машину. Служба NetLogon H s , ^n^f, лл: ;; v; Служба NetLogon используется для синхронизации базы данных учетных записей пользователей между BDC и PDC. Помимо этой функции, NetLogon выполняет также и другие функции. Они перечислены ниже. 1. NetLogon обеспечивает для пользователей проверку регистрации. 2. NetLogon предоставляет поддержку для доверительных отношений между доменами. 3. NetLogon обеспечивает членство компьютеров в домене. Очевидно, что если служба NetLogon отказывает, то ничего из выше- вышеприведенного не произойдет. Давайте посмотрим на некоторые записи ре- реестра, которые могут оптимизировать службу NetLogon и сократить часть трафика, рассмотренного в этой главе. Каждую из этих записей можно увидеть на рис. 6.2. Они расположены в ключе \NetLogon\parameters. ChangeLogSize используется для определения размера журнала измене- изменений в байтах. Так как журнал изменений находится как в памяти, так и на жестком диске (\\winnt\netlogon.chg), то при увеличении размера будет использоваться больше памяти и дискового пространства. Но если ресурсы на PDC настолько ограничены, то модернизация требуется в любом случае. По умолчанию используется 64 Кбайта, что является также минимальным допустимым значением. Этого достаточно приблизительно для 2000 изме- изменений (изменение требует примерно 32 байта), что может показаться до- достаточно большой величиной, если не рассматривать всех паролей, паролей учетных записей машины, прав, разрешений, членства в группах, новых членов и т.п. В большой организации это количество может быстро
Серверный трафик 187 Reoiiliy tdito! fiegislry Edit ' r \ ¦ j \ j i : i : | I i i View Help ?fl О N<taWin2 Ш ?l NdaWan? Ш ?] NalSIOS ffi О NatBIOSInfoiMlun ffl S3 NacDDEd«b Й (Si NaDogon i ;-¦ (Si Enum ! :- ?j Sectrty ^ 1 Й C3 «negert a) CJ NnipSvc . ¦ ,| 2 Cl Nph S) О Nil» s> Cl p«*i -V a Cl PDOunp Jd ! лГ Name !JDGFl4 ^{ PulieConcursncy OPuiteM«x>r»m Pii3«Tineout1 i Data lvalue not tel) ОЛО40ОО0О D134304) OxOOOOOOOOlO) 0>«OOO«!013603) 0«000(ХШП5) 0<00015180186400) 0x00000073112I o«oaooo2S3i60o) OnO0OO0OS4AO0| 4e 45 54 4d 414*0000 -no- .My C«-jJ«WKTt'.l.OCAl..MACHlNE\SYSTEK\Cwi«vC-W;cfiel .< Рис. 6.2. Служба NetLogon управляется с помощью дополнений в реестре исчерпаться, приводя к тому, что новые записи станут перезаписывать еще не синхронизированные изменения. При этом запускается полная синхро- синхронизация, создавая ненужный трафик. Это одно из самых безопасных изменений, которое можно сделать для службы NetLogon. Максимальное значение равно 4194304 D мегабайта), что будет поддерживать 131072 изменения в журнале. Это не ухудшит про- производительность контроллера домена. Увеличение размера сократит число полных синхронизации с BDC. Другая причина для увеличения этого числа возникнет в том случае, когда ожидается, что BDC не синхронизируется с PDC с помощью выделенных 2000 изменений. DisablePasswordChange по умолчанию равно 0. Это означает, что пароль учетной записи машины должен изменяться каждые три дня и синхронизиро- синхронизироваться с одним из PDC. Если машина Windows NT не получает доступа к PDC после изменения пароля, то PDC будет кэшировать существующий пароль для следующих трех дней. Через шесть дней, когда компьютер Windows NT попытается аутентифицировать учетную запись машины, пароль не будет совпадать с паролем в базе данных системы безопасности. Это не должно меняться, если только не будут полностью оценены последствия такого изменения. Пароль учетной записи машины используется для защиты против подделки учетной записи компьютера и является поэтому составной частью системы безопасности NT.
188 Глава 6 Pulse используется для контроля частоты, с которой PDC будет просматри- просматривать изменения в базе данных служб каталогов и посылать сообщения "anno- "announce change to UAS or SAM" для BDC о том, что требуется обновление. По умолчанию используется значение pulse равное 300 секундам E минутам); оно может, однако, принимать максимальное значение 17200 секунд D8 часов). Служба NetLogon собирает изменения SAM и LSA, сделанные во время перио- периода pulse, и посылает сообщение "announce change to UAS or SAM" тем BDC, ко- которым необходимы изменения. Когда служба NetLogon запускается впервые, PDC посылает pulse каждому BDC с учетной записью машины. Кроме того, по достижении значения PulseMaximum PDC будет посылать pulse всем BDC, несмотря на то, нуждаются они в каких-либо изменениях или нет. В среде, где сетевой трафик следует всемерно экономить, использова- использование pulse каждые пять минут является лишним. Однако изменение этого значения на два дня будет чрезмерным, за исключением очень устойчивых сред. Если увеличить это значение до 172800 секунд, возникает риск исте- истечения срока действия пароля учетной записи машины. Конечно, можно за- задать ключ DisablePasswordChange, но это риск для системы безопасности, с которым большинство людей не согласятся. Если задать это значение слишком большим, это может привести к полной синхронизации и возник- возникновению трафика, которого пытались избежать. Задание pulse около значе- значения 3600 (один час) или даже 7200 (два часа) приводит к соответствующему сокращению трафика относительно безопасным образом. BDC удаленного офиса можно даже увеличить до 86400 секунд (один день). PulseConcurrency используется для управления количеством импульсов (pulses), которые будут одновременно посылаться BDC. То есть он управляет количеством BDC, контактирующих одновременно с PDC для проверки базы данных. Если PDC посылает одновременно 10 импульсов (значение по умол- умолчанию для Windows NT 4.0), то одновременно могут соединиться 10 BDC для обновления своей базы данных каталогов. Проблема здесь с полосой пропускания сети и с возможностью PDC обработать множество одновре- одновременных RPC, не создавая чрезмерной нагрузки на машину. Обычно это значение можно увеличивать, не создавая больших проб- проблем. Конечно, если имеются только три или четыре BDC, то можно сокра- сократить это число и освободить некоторые ресурсы на сервере. Увеличение PulseConcurrency будет увеличивать нагрузку на PDC, но обычно современные серверы легко справляются с такой нагрузкой. Уменьшение PulseConcurrency увеличит время, которое потребуется домену для распространения всех изменений SAM и LSA на BDC. В большом домене можно сократить это до такой степени, что домен никогда не будет синхронизирован. PulseMaximum используется для управления частотой, с которой PDC будет посылать сообщения pulse своим BDC, даже если базы данных явля- являются актуальными. По умолчанию используется 7200 секунд (два часа), а максимальное значение PulseMaximum равно 172800 секундам (два дня). Это значение можно задавать для гарантии, что PDC не всегда контактиру- контактирует с BDC при изменениях. Если PulseMaximum задан как максимум в два дня, возникает риск истечения срока действия пароля учетной записи. За- Задание его как один день выглядит достаточно безопасным для сети с боль- большим числом BDC в удаленных WAN.
Серверный трафик 189 PulseTimeoutl контролирует время ожидания PDC ответа от BDC, когда было послано сообщение "announce change to UAS or SAM". Если BDC не отвечает в течение этого периода, то он считается не реагирующим. Не ре- реагирующий BDC не учитывается числом PulseConcurrency, что позволит соединиться дополнительному BDC. Он сможет затем обновить изменения в базе данных, если кто-то превысит предел PulseTimeoutl. Если, однако, значение PulseConcurrency было увеличено, чтобы включить все BDC, то это не будет иметь никакого значения. По умолчанию на ответ на сообщение pulse дается 10 секунд. В WAN с медленными каналами связи значение по умолчанию Pulse- PulseTimeoutl может вызвать проблему, поэтому оно должно быть увеличено до максимума в 120 секунд. Прежде чем делать это, необходимо рассмотреть следующие вопросы. Если имеется большое число BDC, которые необходи- необходимо синхронизировать, и PDC должен ждать по две минуты, чтобы объявить каждый из них не реагирующим, то потребуется очень много времени, что- чтобы закончить частичную синхронизацию. Если число задано слишком мале- маленьким (минимум равен одной секунде), то PDC может считать BDC не реагирующим, когда фактически это не так. Это приведет к возрастанию нагрузки на PDC, когда BDC, наконец, ответит и начнет процесс частичной синхронизации. PulseTimeout2 определяет время, в течение которого PDC будет ожи- ожидать, пока BDC завершит частичную репликацию после ответа на сообще- сообщение "announce change to UAS or SAM" от PDC. Если число изменений возрастает (например, в связи с изменениями ChangeLogSize), то BDC бу- будет считаться не реагирующим, пока не продолжит контактировать с PDC для получения дополнительных изменений. По умолчанию используется 300 секунд. Это означает, что когда BDC контактирует с PDC, ему дается до- дополнительно пять минут, чтобы снова вступить в контакт, иначе он счита- считается не реагирующим. Если значение PulseTimeout2 задано слишком большим (максимум 3600 секунд), то медленный BDC будет занимать один из слотов PulseCon- PulseConcurrency в течение длительного времени (два часа), увеличивая тем самым время выполнения частичной синхронизации. Если это значение слиш- слишком маленькое (минимум равен 60 секундам), то нагрузка на PDC будет увеличиваться в связи с большим числом BDC, выполняющих частичные синхронизации. ReplicationGoverner применяется для управления долей полосы пропу- пропускания, которую может использовать служба NetLogon, при выполнении проверки базы данных. По умолчанию используется значение 100 процен- процентов сетевой полосы пропускания при использовании буфера размером 128 Кбайт данных. Это легко может поглотить весь канал на медленной линии связи между удаленными сайтами WAN. Задавая этот ключ как 50 про- процентов, тем самым изменяют две вещи. Теперь служба NetLogon будет обла- обладать буфером в 64 Кбайта данных и иметь для сообщений синхронизации 50 процентов полосы пропускания.
190 Глава 6 Это значение не должно задаваться меньше 25, иначе синхронизация может никогда не закончиться. Однако можно использовать команду AT планировщика команд, чтобы задавать для этого параметра различные зна- значения в течение дня. Например, можно задавать ReplicationGaverner рав- равным 25 днем и равным 100 ночью. Конечно, это следует делать на каждом BDC, но проблема невелика.' 땦>• ¦ : ч. . т.н:/ ¦ - Обзор главы В этой главе был рассмотрен серверный трафик. Начав с подробного ана- анализа трафика DNS, мы увидели, как DNS преобразует адрес, выполняет рекурсивный поиск и соединяется с WINS. Вслед за обсуждением DNS была рассмотрена инициализация BDC. В этом разделе мы исследовали, как BDC находит PDC и обновляет свою базу данных. Были изучены некоторые настройки реестра для оптимизации трафика синхронизации учетных записей, а также способы оптимизации службы NetLogon. ;"' '; ¦¦•¦¦'• '*•'»¦ .->., ^ >.-.:>..•.< В следующей главе тмч В следующей главе обратимся к трафику приложений. Будет рассмотрен трафик файлов и печати, квитирование TCP и трафик просмотра Интернета, а также почта Интернета. , .. '¦•;/¦ ХМ' '"' ¦ 7HV" ¦¦¦MV1 ¦• ¦ : ¦:.' •:.¦.! •
Глава 7 "! I.;,.1 У: :,. ':<^..-; '" i dr. : :ч,;Ц :-.«: UUvj. .г Трафик приложений Трафик, связанный с приложениями, является темой этой главы. Существу- Существует так много различных видов приложений, что было бы невозможно рас- рассмотреть их все в рамках одной главы, поэтому материал носит характер обзора. Мы собираемся предложить несколько полезных идей, которые помогут вам справиться со сложными реальными проблемами. Работа с файлами и печать Когда на сервере открывается файл или документ посылается на сетевой принтер, создается сеанс между клиентской машиной и сервером. Трафик, связанный с созданием этого сеанса, небольшой, и мало что можно сде- сделать, чтобы его оптимизировать. Как в большинстве транзакций, прежде всего необходимо найти машину. Это может вовлечь WINS, широковещание и ARP. Рассмотрим этот трафик на распечатке ниже. ¦ ¦¦ '- Запрос WINS ¦¦- *¦¦¦¦¦г>* Это стандартный запрос WINS. Он направляется в порт UDP 137, который является портом службы имен NetBIOS. Имя запроса находится там, где присутствует ED1750. Отметим, что счетчик запросов задан как 1, указывая, ЧТО ЭТО кадр запроса. -:,ii,-,i:w ;»i<> '¦. •: ¦->. ¦¦¦•. ., (, -i. !!¦!¦¦;... << .¦;..!;•/' + UDP: Src Port: NETBIOS Name Service, A37); Dst Port: "' NETBIOS Name Service A37); Length = 58 (ОхЗА) J-' ' NBT: NS: Query req. for ED1750 • ¦¦>¦¦•¦¦ ¦ ' :: NBT: Trnsaction ID = 33696 (Ox83A0) : + NBT: Flags Summary = 0x0100 - Req.; Query; Success NBT: Question Count = 1 @x1) NBT: Answer Count = 0 @x0) : - ' NBT: Name Service Count = 0 @x0) NBT: Additional Record Count = 0 @x0) . '.. NBT: Question Name = ED1750
192 Глава 7 NBT: Question Type = General Name Service NBT: Question Class = Internet Class '•¦¦-- Приведенный выше запрос повторяется три раза, прежде чем клиентская машина перестанет запрашивать WINS и обратится к широковещанию. Широковещание В широковещательном кадре ниже мы видим, что он направляется в адрес 10.255.255.255, который является сетевым адресом широковещания для этой подсети. Остальная часть пакета выглядит как запрос WINS. Он по-прежнему адресуется в порт службы имен NetBIOS и содержит тот же запрос для машины ED1750. IP: ID = 0хб02С; Proto = UDP; Len: 78 IP: Version = 4 @x4) IP: Header Length = 20 @x14) + IP: Service Type = 0 @x0) IP: Total Lengh = 78 @x4E) ' IP: Identification = 24620 @x602C) + IP: Flags Summary = 0 @x0) '.'•''.'..¦. IP: Fragment Offset = 0 @x0) bytes '¦'••;¦ ; • : !'1'Л";:-'|К ' IP: Time to Live = 128 @x80) ¦¦[ ' :' '¦ ""' ''-¦¦'•''¦¦'- '¦-¦'¦ '¦ IP: Protocol = UDP - User Datagram '¦.»..•. •<'¦•'. ¦, . IP: Checksum = 0xC538 \.'. ¦ ; IP: Source Address 10.0.0.60 IP: Destination Address = 10.255.255.255 IP: Data: Number of data bytes remaining = 58 @x003A) + UDP: Src Port: NETBIOS Name Service, A37); Dst Port: NETBIOS Name Service A37); Length = 58 (ОхЗА) NBT: NS: Query req. for ED 1750 - > iil; NBT: Transaction ID = 33696 @x83A0) ' • ¦<¦ ' ¦•¦•< '•... + NBT: Flags Summary = 0x0110 - Req.; Query; Success :¦ :;..-. NBT: Question Count = 1 @x1) NBT: Answer Count = 0 @x0) , • . ¦ .. ¦ -, NBT: Name Service Count = 0 @x0) NBT: Additional Record Count = 0 @x0) .'',.',V >; ¦ NBT: Question Name = ED1750 ' '¦ '' NBT: Question Type = General Name Service ; ' NBT: Question Class = Internet Class , ;¦;•.<•¦ Когда был сделан широковещательный запрос, искомая машина слышит запрос NBT для ED1750 и отвечает клиентской машине. Это будет направ- направленная дейтограмма UDP, а не широковещательный кадр. Он идет непо- непосредственно запрашивающей машине в порт 137 с IP-адресом машины в поле ответа. IP: ID = 0x7530; Proto = UDP; Len: 90 IP: Version = 4 @x4) IP: Header Length = 20 @x14) + IP: Service Type = 0 @x0) IP: Total Length = 90 @x5A)
Трафик приложений 193 IP: Identification = 30000 @x7530) + IP: Flags Summary = 0 @x0) IP: Fragment Offset = 0 @x0) bytes IP: Time to Live = 128 @x80) IP: Protocol = UDP - User Datagram . ,r IP: Checksum = ОхВОСЗ IP: Source Address =10.0.0.100 IP: Destination Address = 10.0.0.60 IP: Data: Number of data bytes remaining = 70 @x0046) + UDP: Src Port: NETBIOS Name Service, A37); Dst Port: NETBIOS Name Service A37); Length = 70 @x46) NBT: NS: Query (Node Status) resp. for ED1750, Success NBT: Transaction ID = 33696 @x83A0) + NBT: Flags Summary = 0x8500 - Resp.; Query; Success NBT: Question Count = 0 @x0) ,/ ,, , NBT: Answer Count = 1 @x1) ' ' .^ NBT: Name Service Count = 0 @x0) • NBT: Additional Record Count = 0 @x0) NBT: Resource Record Name = ED17 50 NBT: Resource Record Type = NetBIOS General Name Service NBT: Resource Record Class = Internet Class NBT: Time To Live = 300000 @x493E0) , . NBT: RDATA Length = 6 @x6) + NBT: Resource Record Flags = 24576 @x6000) NBT: Owner IP Address = 10.0.0.100 Когда клиентская машина получит IP-адрес от искомого компьютера, следующий шаг состоит в преобразовании IP-адреса в аппаратный адрес. ARP Чтобы преобразовать IP-адрес в аппаратный адрес, будет использоваться протокол ARP, как показано на распечатке ниже. Отметим, что указанный искомый аппаратный адрес состоит полностью из нулей, поскольку в данный момент клиентская машина не знает, каким является адрес MAC. Opcode, равный 1, указывает, что это запрос ARP. ARP_RARP: ARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP RARP: Request, Target IP: 10.0.0.100 Hardware Address Space = 1 @x1) Protocol Address Space = 2048 @x800) Hardware Address Length = 6 @x6) Protocol Address Length = 4 @x4) Opcode = 1 @x1) Sender's Hardware Address = 00902764FEBF Sender's Protocol Address = 10.0.0.60 Target's Hardware Address = 000000000000 Target's Protocol Address = 10.0.0.100 Ответ приходит из искомой машины, как показано ниже. При получении запроса ARP искомая машина отвечает с вписанным аппаратным адресом. Это не широковещательный кадр. Это кадр, специально направленный на адрес MAC запрашивающий машины.
194 Глава 7 ARP_RARP: ARP: 00902764FEBF ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP RARP: Reply, Target IP: 10.0.0.100 Target Hdwr Addr: Hardware Address Space = 1 @x1) Protocol Address Space = 2048 @x800) Hardware Address Length = 6 @x6) Protocol Address Length = 4 @x4) Opcode = 2 @x2) Sender's Hardware Address = 00609788CF96 Sender's Protocol Address = 10.0.0.100 Target's Hardware Address = 00902764FEBF Target's Protocol Address = 10.0.0.60 Frame Padding -¦-¦•¦ ¦ ¦ ¦• Потребовалось семь кадров и 547 байтов для нахождения IP-адреса и ад- адреса MAC искомой машины. Если бы использовался WINS, то можно было бы сократить этот трафик на несколько кадров. Если бы существовали файлы LMHOSTS, то трафик можно было бы сократить еще больше. Трехходовое квитирование Следующим шагом является создание сеанса TCP. Это влечет за собой трех- трехходовое квитирование, которое создаст еще 172 байта трафика. Первый из этих кадров приходит с клиентской машины. Отметим, что флаги заданы как S @x02), чтобы синхронизировать номера. аск: 0, win: Session Service @x28BD70A) @x0) .1.>Г I.'.i TCP: S., len: 4, seq: 42718986-42718989, 8192, src: 1164 dst: 139 (NBT Session) TCP: Source Port = 0x048C TCP: Destination Port = NETBIOS TCP: Sequence Number = 42718986 TCP: Acknowledgement Number = 0 ''• •¦•¦'"¦¦ TCP: Data Offset = 24 @x18) •¦¦'¦ TCP: Reserved: 0 @x0000) • + TCP: Flags = 0x02 : S. " ¦ • • ¦ ' TCP: Window = 8192 @x2000) TCP: Checksum = 0x84DA '>¦ > . :¦¦! ir.r.i. .} ¦:.'::> ¦ TCP: Urgent Pointer = 0 @x0) + TCP: Options " ""'"'• ' ' Ответ на этот кадр приходит с искомой машины. Он имеет два флага @x12), А и S. Флаг А говорит, что поле подтверждения значимо и подтвер- подтверждает последнюю передачу. Кроме того, флаг S говорит, что передается порядковый номер. TCP: .A..S., len: 4, seq: 141140299-141140302, ack: 42718987, win: 8760, src: 139 (NBT Session) dst: 1164 TCP: Source Port = NETBIOS Session Service TCP: Destination Port = 0x048C ; •¦'¦'¦'"¦ TCP: Sequence Number = 141140299 @x869A14B) ' ; -':'-. ... TCP: Acknowledgement Number = 42718987 @x28BD70B) ¦ :,: ;. . .,. TCP: Data Offset = 24 @x18) . ¦ TCP: Reserved: 0 @x0000)
Трафик приложений 195 + TCP: Flags = 0x12 : .A..S. TCP: Window = 8760 @x2238) ¦" ... ..,,.. TCP: Checksum = 0xD8DC ..;)-•:&;.- ,-¦>;„. - . . ! .vtr. TCP: Urgent Pointer = 0 @x0), ч,-. * ., .,. .,. . , + TCP: Options м--*'-»--- ¦¦•¦' ¦ ,-• ' •¦• ¦.¦•¦-..¦ TCP: Frame Padding Третий кадр в трехходовом квитировании содержит флаг А @x10), сооб- сообщающий, что поле подтверждения значимо. Оно подтверждает порядковый номер. Теперь сеанс TCP создан. TCP: .А , len: 0, seq: 42718987-42718987, ack: 141140300, win: 8760, src: 1164 dst: 139 (NBT Session) TCP: Source Port = 0x048C TCP: Destination Port = NETBIOS Session Service TCP: Sequence Number = 42718987 @x28BD70B) TCP: Acknowledgement Number = 141140299 @x869A14C) TCP: Data Offset = 20 @x14) '. ;1 • TCP: Reserved: 0 @x0000) . ,, ,, A , , . ... •''¦'¦• + TCP: Flags = 0x10 : .A. . . . ' ' : ' lf ¦ ' т" д '; :< TCP: Window = 8760 @x2238) :l': " ' '"' '''"' :'ч'"ь;' '"¦ ' TCP: Checksum = 0xF099 TCP: Urgent Pointer = 0 @x0) Сеанс NetBIOS Когда сеанс TCP создан, следующий шаг состоит в создании сеанса NetBIOS. Сеанс должен быть создан между двумя машинами, прежде чем начнет про- происходить какая-либо дальнейшая коммуникация. Для этого потребуется два кадра и 186 байтов. Важный момент здесь состоит в том, что вызываемое имя и вызывающее имя являются правильными. ; ¦,-....¦ NBT: SS: Session Request, Dest: ED1750 ''¦''" , Source 2400 <00> Len: 68 : &l NBT: Packet Type = Session Request ¦• ....... + NBT: Packet Flags = 0 @x0) . ¦¦¦:....••¦ NBT: Packet Length = 68 @x44) .. . ..- • .-•:.•¦ > NBT: Called Name = ED1750 NBT: Calling Name = 2400 <00> . . Второй кадр меньше размером и идет прямо на клиентскую машину. Чтобы был создан сеанс NetBIOS, тип пакета должен сообщать, что это положительный ответ сеанса. :.. NBT: SS: Positive Session Response, Len: 0 : NBT: Packet Type = Positive Session Response + NBT: Packet Flags = 0 @x0) NBT: Packet Length = 0 @x0) ' . NBT: Frame Padding
Глава 7 Согласование диалекта SMB Теперь, после создания сеанса TCP и сеанса NetBIOS, задача состоит в со- согласовании диалекта SMB. Два компьютера выберут самый высокий уро- уровень диалекта, который понятен обеим машинам. В примере ниже самым старшим высоким диалектом является NT LM 0.12, и мы видим команду SMB "С negotiate". : if SMB: С negitiate, Dialect = NT LM 0.12 " ; ''' [[ ••• SMB: SMB Status = Error Success -¦ ' ¦¦-•'¦' ¦¦. .;-¦>. ; . • SMB: Error class = No error SMB: Error code = No error + SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000 UID = 0x0000 + SMB: Command = С negotiate Ответ с серверной машины сообщает, что статус успешный и имеется от- ответ SMB на команду согласования. Кроме того, сервер поддерживает прото- протокол SMB NT LM 0.12, указанный позицией в первом сообщении с номером 7. Эти два кадра требуют в сети 371 байт. SMB: R negotiate, Dialect # = 7 SMB: SMB Status = Error Success SMB: Error class = No error ,Л .,., . ._ ( .. SMB: Error code = No error .<.«:»< -,'•< ,\n$J + SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000 UID = 0x0000 + SMB: Command = С negotiate J.^ . . . M После согласования диалекта SMB возникает реальное соединение с об- общим сетевым каталогом. Когда происходит соединение, каталог общего ре- ресурса или диска копируется по сети на клиентскую машину. Однако прежде чем это произойдет, нам необходимо согласовать соединение с реальным ресурсом. В этом месте два компьютера будет проверять безопасность. Да- Давайте посмотрим, как это происходит. Клиентская машина использует команду SMB "session setup & X" для настройки сеанса SMB. В этом кадре мы видим имя учетной записи и имя домена, указанные в качестве полномо- полномочий, которые передаются на серверную машину. В данном случае это поль- пользователь с именем ed из домена MRED. Мы видим также, что это машина Lanman Windows NT 4.0. Так как это развитая версия диалекта SMB, она мо- может обрабатывать несколько команд в одном кадре. Поэтому второй коман- командой SMB является "С tree connect & X". Она используется для создания соединения с общим ресурсом, которым в данном случае является общий ресурс 1РС$ на машине BIGGUY (рабочая станция Windows 98). SMB: С session setup & X, Username = ed, and С tree connect & X, Share = \\BIGGUY\IPC$ + SMB: SMB Status = Error Success + SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000 UID = 0x0000 SMB: Command = С session setup & X
Трафик приложений 197 SMB: Word count = 13 ¦ ''-¦'¦ * SMB: Word parameters 7 -i-Л ' SMB: Next offset = 0x0096 SMB: Max Buffer Size = 2920 @xB68) SMB: Max MPX requests = 2 SMB: VC number = 0 • ¦ ¦•'V->-- ¦¦' SMB: Session Key = -2147483587 ¦'¦ ;'^':-!" >i;! ; ;''¦'¦"• ; SMB: Password length = 24 @x18) ;:v ¦ SMB: Unicode Password length = 24 @x18) ''>**'¦ ' ¦¦¦ ¦¦. + SMB: Capabilities = 212 @xD4) - ¦ ¦¦¦ ¦¦• >- ¦ : Л ¦¦; SMB: Byte count = 89 . .; ; SMB: Byte parameters •;<». •;;•, _ у .•¦ .• ... SMB: Account name = ed , ¦>¦ . ( ( ,, .. ls... ; ..•.;, . , SMB: Domain name = MRED . • ( ,,;, ..j,!.-; ,-• SMB: Native OS = Windows NT 1381 " .", , './ ¦' SMB: Native Lanman = Windows NT 4.0 SMB: Command = С tree connect & X ¦• ; ; . SMB: Word count =4 • SMB: Word parameters •¦¦ : -.-. .;.. SMB: Next offset = 0x0000 SMB: Disconnect flag = 0x0000 SMB: Password length = 1 @x1) SMB: Byte count =19 : SMB: Byte parameters - , ,.t.:: .-Л'; SMB: Password = -.'.'•¦ SMB: File name = \\BIGGUY\IPC$ SMB: Service Name = IPC :<; SMB: Command = No secondary command Рассмотрим ответ на команду "С session setup & X". В этом кадре мы смотрим прежде всего на состояние SMB, указывающее на отсутствие оши- ошибок (error success). Мы хотим также дважды проверить полномочия, кото- которые используются для создания этого сеанса, и возможности данного сеанса. ¦ . ¦ ;•< • =¦¦ SMB: С session setup & X, Username = ed + SMB: SMB Status = Error Success + SMB: Header: PID = 0x0000 TID = 0x0800 MID = 0xAA82 UID = 0x0002 SMB: Command = С session setup & X SMB: Word count =13 SMB: Word parameters SMB: Next offset = 0x0075 SMB: Max Buffer Size = 2920 @xB68) SMB: Max MPX requests = 50 ! -' SMB: VC number = 1 SMB: Session Key =0 SMB: Password length = 24 @x18) SMB: Unicode Password length = 0 @x0) + SMB: Capabilities = 5 @x5) SMB: Byte count = 56 SMB: Byte parameters
198 Глава 7 - . и . SMB: Account name = ed ,, ..-;. SMB: Domain name = MRED •¦ ¦¦-' SMB: Native OS = Windows 4.0 ,x- . ' SMB: Native Lanman = Windows 4.0 .-,\ „ SMB: Command = No secondary command _¦,;¦> . После того как все согласования были выполнены, данные пересылают- пересылаются на машину клиента. Первый шаг состоит в поиске файла для пересылки на клиентскую машину с помощью команды "transact2 Findfirst". Эта коман- команда будет использовать функцию Findfirst для поиска определенного файла (в нашем случае утилиты Browstat.exe). Для этой операции задаются два флага. Один закроет дескриптор поиска после завершения, а второй будет продолжать после каждой найденной записи. Они могут считываться как двоичные числа. Флаг закрытия дескриптора поиска находится в первой позиции, а флаг ключа продолжения находится в четвертой позиции @101). SMB: Command = R transact2 чи ; -; 1.:?ыа:м,*: :?."-.? . ... . SMB: Word count = 15 ' ' ' ;'•¦ ¦ Vv SMB: Word parameters * : r- '- ''y v';k SMB: Total parm bytes = 58 :'¦'"¦ SMB: Total data bytes = 0 '- ¦ ''¦¦¦¦ SMB: Max parm bytes = 10 "¦'*' ' SMB: Max data bytes = 608 :' SMB: Max setup words = 0 @x0) + SMB: Transact Flags Summary = 0 @x0) SMB: Transact timeout = 0 @x0) SMB: Parameter bytes = 58 @x3A) SMB: Parameter offset = 68 @x44) |Л"- SMB: Data bytes = 0 @x0) "¦•"¦ '¦-•¦"• ¦' "' SMB: Data offset = 0 @x0) ;1Jir'' :' r<; "/'> ' ¦'•'•г ..<¦<; SMB: Max setup words = 1 '" >"':' '¦'^¦'"¦' •'¦':и("-1-- ••¦ l . .' ' SMB: Setup words ' :H С :.. :•!• :¦;.; SMB: Transact2 function = Findfirst ! ,;¦.¦: -.-..г; SMB: Byte count = 61 ¦ . -, ¦ SMB: Byte parameters SMB: Transaction parameters + SMB: Search attributes = 0x0016 ! > ", SMB: Find count = 6 ' SMB: Find Flags = 5 @x5) SMB: 1 = Close search handle upon completing request SMB: 0 . = Keep search handle open if end of search reached SMB: 1. . = Resume key is required for each entry found SMB: 0... = Start search from the beginning SMB: Info Level = Both Directory Info (NT) SMB: File name = \NTRESKIT\BROWSTAT.EXE
Трафик приложений 199 Получив ответ от сервера, клиентская машина посылает команду "R NT create & X". Параметр "Create flags Dword", равный 0x00000006, запрашивает как Oplock, так и Opbatch. Параметр "file share access", равный 0x00000001, запрашивает доступ к файлу на чтение. SMB: Command = R NT create & X ¦<¦;•¦.' SMB: Word count = 24 ¦<•..:. ¦¦:¦¦.¦,¦.:¦¦ .>-.гм,: ¦ > огуЛ! . ¦: '¦'/ j!-. L"¦•¦•>! ¦ SMB: Word parameters -hv ;¦ •• cprurri .; ..-.;<iin л v .,;,,-;, ),.;::,-/,<!, SMB: Next offset = 0x0000. ;>';:". ¦.w'v-.'-.t;:.•¦>-<• (¦;¦¦:*¦¦>¦¦ O!-, ,,f )U,. ;¦:¦., SMB: Word count = 24 -¦..•...: .-4-. ..: -^-но) f-lr ; i '_¦:¦¦ ¦>¦- i . j f П; ... .• •• SMB: Word parameters , , -,, та<..<' ,!•¦¦ .,.',"'¦.'..,,'.. ". / ¦¦' SMB: Name Length (NT) = 44 @x2C) ¦,-.-, i\/-\ r,,;i, ,- '"' ' ^ ' "¦ + SMB: Create Flags DWord = 0x00000006 ' -" '•. SMB: Root Dir FID = 0x00000000 + SMB: Desired Access = 0x00020089 SMB: File Allocation Size = 0x0000000000000000 + SMB: NT File Attributes = 0x00000000 + SMB: File Share Access = 0x00000001 SMB: Create Disposition = Open: If exist. Open, else fail + SMB: Create Options = 68 @x44) SMB: Impersonation Level = 0x00000002 + SMB: Security Flags = 0x03 SMB: Byte count = 47 SMB: File name = \NTRESKIT\BROWSTAT.EXE Теперь компьютер начинает процесс определения, как передать файл и что с ним делать после получения. В этом процессе снова задействована команда "R NT create & X" и Batch Oplock. В распечатке ниже содержится вся обычная информация, которую можно увидеть в подробном списке ка- каталога. Параметр "file allocation size" равен 0х000000000000А800, что соот- соответствует 4308 байтам в десятичных числах. Если это значение разделить на 1024, получится 42 Кбайта — размер browstat.exe. Здесь также присутству- присутствует "File ID". FID используется для мониторинга транзакции и отслеживания файла. .. , . . SMB: Command = R NT create & X -, - • iv ' . SMB: Word count = 34 , ' .. SMB: Word parameters , SMB: Next offset = 0x0067 SMB: Word count = 34 ;, : • , SMB: Word parameters ..- . i . ,¦ . •¦ . , ,, '.' ¦ .-'.. ( , , SMB: Oplock Level = Batch . ' , .., ,-. ¦-. _,. .-,• :.. SMB: File ID (FID) = 6157 @xl80D) -j ,ri. :,, ,. :. " ' , , SMB: File Name = \NTRESKIT\BROWSTAT.EXE ' ,/ 1 i!" : ' SMB: Create Action = File Opened ¦¦¦' '; • SMB: Creation Time = Jul 26, 1996 5:0:0.0 ' >H! c SMB: NT Last Access Time = Aug 15, 1999 20:59:1.79 SMB: Last Write Time = Jul 26, 1996 5:0:0.0 SMB: Change Time = Auf 24, 1999 1:33:11.25 + SMB: NT File Attributes = 0x00000020
200 i. ^'...-..... Глава 7 : ¦ :¦' /j.^,; ¦ . SMB: File Allocation Size = 0x00000000O0O0A800 . ,,..;¦ ; ,,lr. ,;i SMB: End of File = 0xOOOOOOO0OO0OA51O (|.,,iV,;:i ;¦, .,, SMB: File type = Disk file or directory ¦ ,• SMB: Device state = 0x0000 . .,.,,,,..,,.. SMB: Boolean Is Directory = 0 @x0) Несколькими кадрами дальше протокол SMB начинает реальную переда- передачу данных с сервера на клиентскую машину. Команда SMB "С read & X" на- начинает копирование данных по кабелю. Это полноразмерный кадр Ethernet A514 байтов, включая заголовок Erthernet), но он несет полезную нагрузку только в 1397 байтов — т.е. 117 байтов накладных расходов из заго- заголовка Ethernet, заголовка IP, заголовка TCP, заголовка NBT и, наконец, команды SMB. ., / ;,: SMB: Command = SMB: SMB: SMB: '"¦¦ SMB: SMB: SMB: SMB: SMB: SMB: SMB: Data @x0575) С read & X Word Word Next File count : = 12 ': "¦" ¦ parameters offset name = Bytes left = Data Data Byte Byte length offset count = = 0x0000 \NTRESKIT\BROWSTAT.EXE = 65535 = 32768 @x8000) = 59 (ОхЗВ) = 32768 : parameters : Number of data bytes remaining = 1397 Когда данные начнут перемещаться, SMB на некоторое время выпадает из картины и позволяет NBT переносить нагрузку, используя TCP, чтобы гарантировать безопасную доставку данных. Наша полезная нагрузка воз- возросла теперь до 1460 байтов, такой она будет оставаться для передачи. + FRAME: Base frame properties :.-,. , ,. ... , ¦. :•; + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet .: . Protocol + IP: ID = 0xl91C; Proto = TCP; Len: 1500 ''' + TCP: .A...., len: 1460, seq: 2012325-2013784, ack: 8796927, win: 7328, src: 139 (NBT Session) dst: 1073 NBT: SS: Session Message Cont., 1460 Bytes NBT: SS Data: Number of data bytes remaining = 1460 @x05B4) Когда данные будут переданы, наступает время закрыть сеанс. Для это- этого будет использоваться команда SMB "С tree disconnect". Команда "С tree disconnect" не использует имя файла (такое, как при передаче данных); вместо этого клиент использует идентификатор дерева (TID) удаленного диска, который будет отсоединяться. Сервер присваивает TID, когда впервые создается соединение. SMB: С tree disconnect + SMB: SMB Status = Error Success
.Трафик приложений 201 SMB: = 0x6802 + + SMB: Header: PID = OxCAFE TID = 0xD002 MID 0xB2C0 UID SMB: SMB: SMB: SMB: SMB: SMB: Tree ID (TID) = 53250 Process ID (PID) = 51966 User ID (UID) = 26626 Multiplex ID (MID) = 45760 Flags Summary = 24 @x18) @xD002) (OxCAFE) @x6802) @xB2C0) flags2 Summary = 32771 @x8003) Command = С tree disconnect SMB: SMB: Word count =0 Byte count = 0 Ответ возвращается с сервера со значением статуса "error success" и со- соответствующим номером TID. Когда эта команда завершается, сеанс SMB разъединяется. Для разъединения сеанса требуются два маленьких кадра по 93 байта каждый. 1 " SMB: R tree disconnect ' •.¦¦•••••¦ ' ; ¦ + SMB: SMB Status = Error Success "?'¦' SMB: Header: PID = OxCAFE TID = 0xD002 MID 0xB2C0 UID = 0x6802 SMB : SMB: SMB: SMB: + SMB: + SMB: Tree ID (TID) = Process ID (PID) = User ID (UID) = Multiplex ID (MID) = Flags Summary = 152 = 53250 = 51966 = 26626 = 45760 @x98) @xD002) (OxCAFE) @x6802) @xB2C0) flags2 Summary = 32771 @x8003) SMB: Command = С tree disconnect SMB: SMB: Word count = 0 Byte count =0 росмотр Интернета Трафик просмотра Интернета все в большей степени оказывает влияние на корпоративные сети с точки зрения как интрасетей, так и Интернета. Оба типа трафика имеют аналогичные схемы поведения, однако интрасети часто используют графику более интенсивно и требуют более широкую по- полосу пропускания. Посмотрим, что происходит, когда загружается одна страница Web. Страницы Web Для нашего примера рассмотрим, что происходит, когда запускается броу- броузер Microsoft Internet Explorer и открывается используемая по умолчанию начальная страница на сайте MSN. Как можно видеть на распечатке ниже, броузер начинает со стандартного запроса DNS. Это небольшая дейтаграм- дейтаграмма UDP, направленная в порт 53 сервера DNS. Она использует 78 байтов, включая заголовок Ethernet для этого кадра. Этот кадр повторяется, пока не придет ответ в третьем кадре трассировки (файл open msn page.cap на сайте издательства "ЛОРИ" (www.lory-press.ru)).
202 Глава 7 DNS: Oxl: Std Qry for home.microsoft.com of type Host Addr on class INET addr. DNS: Query Identifier = 1 (Oxl) + DNS: DNS Flags = Query, opCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 (Oxl) DNS: Answer Entry Count = 0 @x0) DNS: Name Server Count = 0 @x0) DNS: Additional Records Count = 0 @x0) DNS: Question Section: home.microsoft.com. of type Host Addr on class INET addr. .» - DNS: Question Name: home.microsoft.com. ,. , .¦¦._. DNS: Question Type = Host Address ' * '..''.' ' DNS: Question Class = Internet address class Ответ на запрос, где находится home.Microsoft.com, возвращается в 380- байтовом кадре. Полезная нагрузка UDP состоит из 264 байтов данных DNS. Для ясности кадр был слегка сокращен. Счетчик запросов (question entry count) равен единице, указывая, что имеется один запрос, который по- повторяется из предыдущего кадра. Счетчик ответов (answer entry count) равен четырем, что говорит о наличии четырех ответов на запрос, где находится home.Microsoft.com. Первая возвращаемая запись ресурса предоставляет клиентской машине IP-адрес. DNS: Oxl: Std Qry Resp. for home.microsoft.com. of type Host Addr on class INET addr. DNS: Query Identifier = 1 (Oxl) + DNS: DNS Flags = Response, OpCode - Std Qry, RD RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (Oxl) DNS: Answer Entry Count = 4 @x4) DNS: Name Server Count = 4 @x4) DNS: Additional Records Count = 4 @x4) ;>'¦• •. DNS: Question Section: home.microsoft.com. of type . i:i, Host Addr on class INET addr. .;.-,. DNS: Question Name: home.microsoft.com. .,.., . DNS: Question Type = Host Address -. . DNS: Question Class = Internet address class DNS: Answer section: home.microsoft.com. of type Host i;' Addr on class INET addr. D records present) DNS: Resource Record: home.microsoft.com. of type Host Addr on class INET addr. DNS: Resource Name: home.microsoft.com. .?••'.?: . -( DNS: Resource Type = Host Address . DNS: Resource Class Internet address class DNS: Time To Live = 95 @x5F) if • '¦ ¦'' "' DNS: Resource Data Length = 4 @x4) ^ -t ' DNS: IP address = 207.46.176.13 : '' '-'^' Когда имя будет преобразовано, можно инициировать контакт с помо- помощью трехходового квитирования. Оно направляется в порт 80, который яв- является портом, используемым для HTTP. Флаги 0x02 (здесь задано два
Трафик приложений 203 флага) говорят нам, что требуется синхронизировать номера последователь- последовательностей. Клиентская машина выбирает порт источника как 3488 (OxODAO). • TCP: ....S., len: 4, seq: 241730-241733, ack: 0, win: 8192, src: 3488 dst: 80 ¦-,.,.;¦¦ TCP: Source Port = OxODAO TCP: Destination Port = Hypertext Transfer Protocol TCP: Sequence Number = 241730 @x3B042) ' TCP: Acknowledgement Number = 0 @x0) ¦'•' . • • ''¦¦¦•¦•• TCP: Data Offset = 24 @x18) ........ • •,.,¦¦ >•": • : ¦ TCP: Reserved = 0 @x0000) + TCP: Flags = 0x02 : ....S. .'. • , . . Второй кадр квитирования возвращается с флагами, заданными как 0x12, означающими, что поле подтверждения значимо и заданы номера синхронизированной последовательности. Источником является порт 80, кадр посылается в порт 3488 на клиентской машине. Номер подтверждения на единицу больше, чем порядковый номер из клиентской машины. Кроме того, сервер передает свой собственный порядковый номер, как видно на распечатке ниже. ¦ ¦ - ¦ ¦ •* ¦ ¦ ¦ TCP: .A..S., len: 4, seq: 142002582-142002585, ack: 241731, win: 8760, src: 80 dst: 3488 TCP: Source Port = Hypertext Transfer Protocol TCP: Destination Port = OxODAO TCP: Sequence Number = 142002582 @x876C996) TCP: Acknowledgement Number = 241731 @x3B043) TCP: Data Offset = 24 @x18) TCP: Reserved = 0 @x0000) . . ,. + TCP: Flags = 0x12 : .A..S. В третьем кадре поле подтверждения является значимым, и можно срав- сравнить АСК с порядковым номером в предыдущем кадре. Здесь снова ис- используются те же порты места назначения и источника. Флаги 0x10 @10000 в двоичном виде равно 16 в десятичном и 10 в шестнадцатеричном) указывают на кадр АСК. TCP: .А , len: 0, seq: 241731-241731, ack: 142002583, win: 8760, src: 3488 dst: 80 TCP: Source Port = OxODAO TCP: Destination Port = Hypertext Transfer Protocol TCP: Sequence Number = 241731 @x3B043) TCP: Acknowledgement Number = 142002583 @x876C997) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) + TCP: Flags = 0x10 : .A.... Этот кадр завершает трехходовое квитирование, и мы готовы к загрузке страницы Web. Давайте посмотрим на кадр 9 в нашем файле "open msn page.cap" на сайте издательства "ЛОРИ" (www.lory-press.ru). Часть TCP кадра выглядит анало- аналогично другим, которые мы уже встречали. Она по-прежнему направляется в
204 Глава 7 порт 80. Здесь имеются два флага, но в этот раз они являются флагами АСК и Push. Если сравнить номер подтверждения с номером из предыдущего кадра, то легко видеть, что они подтверждают один и тот же кадр. Флаг push приказывает серверу продолжать и послать данные, которые имеются в буфере. Раздел HTTP посылает команду GET из home.Microsoft.com с помощью протокола HTTP/1.1. Недокументированный заголовок содержит данные cookie с информацией о городе, штате и zip-коде, которая может использоваться для персонализации начальной страницы MSN. ¦:;> .. TCP: .АР..., len: 577, seq: 241731-241307, ack: 142002583, win: 8760, src: 3488 dst: 80 TCP: Source Port = OxODAO TCP: Destination Port = Hypertext Transfer Protocol ¦'-¦•-'¦¦¦ TCP: Sequence Number = 241731 @x3B043) ; ' v TCP: Acknowledgement Number = 142002583 @x876C997) •^•"-¦"r TCP: Data Offset = 20 @x14) •<,f"A TCP: Reserved = 0 @x0000) ->¦- ¦',:•¦¦• *¦¦ .,.-•*¦ ' - ,.v •,.¦. TCP: Flags = 0x18 : .AP. . . " TCP: ..0 = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: 0. . = No Reset TCP: 0. = No Synchronize TCP: 0 = No Fin TCP: Window = 8760 @x2238) TCP: Checksum = 0xF9B5 TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 577 @x0241) HTTP: GET Request (from client using port 3488) HTTP: Request Method = GET ¦¦¦••¦¦¦ HTTP: Uniform Resource Identifier = / ;. ¦¦ •. HTTP: Protocol Version = HTTP/1.1 HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* HTTP: Accept-Language = en-us HTTP: Accept-Encoding = gzip, deflate HTTP: User-Agent = Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) HTTP: Host = home.microsoft.com HTTP: Connection = Keep-Alive HTTP: Undocumented Header = Cookie: HMCMISC=FCDEG=F&CITYCODE=OH%5FHamilton&LN=RTCI&CITYGU IDE=gCINC&VCARD%5FPOSTALCODE=45011&MINDIF=ll&P=t; CATEGORIES=MAIL%2CNEWS%2C HTTP: Undocumented Header Fieldname = Cookie HTTP: Undocumented Header Value = HMCMISC=FCDEG=F&CITYCODE=OH%5FHamilton&LN=RTCI&CIT В распечатке выше броузер говорит, что он хочет получить (GET) стра- страницу с сайта home.Microsoft.com и предоставляет свой cookie. Кадр ниже
Трафик приложений 205 является ответом с сервера. Страница указана в параметре "Undocumented header location" и будет выведена в адресном окне броузера. Мы видим теги HTML, которые указывают броузеру, как форматировать текст. Эта конк- конкретная страница никогда не выводится в броузере, а является страницей перенаправления, создающей достаточно интересный ответ, который можно увидеть в следующем кадре. ¦ . .., - ' ' . HTTP: Response (to client using port 3488) HTTP: Protocol Version = HTTP/1.1 ¦ HTTP: Status Code = Found HTTP: Reason = Object moved HTTP: Server = Microsoft-IIS/4.0 HTTP: Date = Tue, 24 Aug 1999 03:02:35 GMT HTTP: Undocumented Header = Location: http://www.msn.com/default.asp?HMC2MSN=l HTTP: Undocumented Header Fieldname = Location HTTP: Undocumented Header Value = http://www.msn.com/default.asp?HMC2MSN=l HTTP: Content-Type = text/html HTTP: Undocumented Header = <headxtitle>Object moved</titlex/head> HTTP: Undocumented Header Fieldname = , '--¦. > r.t <headxtitle>Object , HTTP: Undocumented Header Value = moved< /tit 1 ex /head> HTTP: Undocumented Header = <bodyxhl>0bject ' Moved</hl>This object may be found <a HREF="http://www.msn.com/default.asp?HMC2MSN=l">here</a>.</body> HTTP: Undocumented Header Fieldname = <bodyxhl>0bject HTTP: Undocumented Header Value = Moved</hl>This object may be found <a HREF="http:/ Сервер задает два флага: АСК, который мы могли бы ожидать, и флаг FIN (больше данных от отправителя нет 0x01). Сервер msn.com закрывает соединение. TCP: .A...F, len: 0, seq: 142002909-142002909, ack: 242308, win: 8183, src: 80 dst: 3488 TCP: Source Port = Hypertext Transfer Protocol TCP: Destination Port = OxODAO TCP: Sequence Number = 142002909 @x876CADD) : TCP: Acknowledgement Number = 242308 @x3B284) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) .'' TCP: Flags = 0x11 : .A...F ' TCP: ..0 = No urgent data TCP: ...1.... = Acknowledgement field significant : TCP: ....0... = No Push function TCP: 0. . = No Reset ... TCP: 0. = No Synchronize TCP: 1 = No more data from sender
206 ""'"""'¦'¦'"' Глава 7 Когда клиентский компьютер получает флаг FIN с сервера MSN, он не име- имеет другого варианта, кроме как заново создать соединение. Это указывается в разделе флагов @x04). J '. »¦*¦<•"' ''Л г* TCP: ...R.., len: 0, seq: 242308 - 242308, ack: ...„„,„,„ 142002583, win: 0, src: 3488 dst: 80 : ^ TCP: Source Port = OxODAO j'*»«^"«^ >••.,.!•*№« TCP: Destination Port = Hypertext Transfer Protocol TCP: Sequence Number = 242308 @x3B284) TCP: Acknowledgement Number = 142002583 @x876C997) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) ..¦¦;<-: tv TCP: Flags = 0x04 : ...R.. TCP: ..0 = No urgent data ,, . ,->¦¦¦ ; TCP: ...0.... = Acknowledgement field not significant ... TCP: ....0... = No Push function TCP: 1.. = Reset the connection TCP: 0. = No Synchronize TCP: 0 = NO Fin ¦•.' ;-."Г • В этом месте клиентская машина решает, что предыдущий ответ от DNS был не вполне точным, поэтому она пытается сделать повтор с помощью другого запроса DNS, как показано на распечатке ниже. UDP: Src Port: Unknown, C489); Dst Port: DNS E3); Length = 37 @x25) DNS: 0xl:Std Qry for www.msn.com. of type Host Addr on class INET addr. DNS: Query Identifier = 1 @x1) + DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 @x1) " " '--"¦¦' DNS: Answer Entry Count = 0 @x0) ...л т .-t "'¦¦"'' DNS: Name Server Count = 0 @x0) "''¦' ' "*'' ' '' ''" * " 1 •>r''1' DNS: Additional Records Count = 0 @x0) DNS: Question Section: www.msn.com. of type Host Addr on class INET addr. DNS: Question Name: www.msn.com. DNS: Question Type: Host Address DNS: Question Class = Internet address class После другого запроса DNS мы успешно получаем нужный адрес и про- проходим также через трехходовый процесс квитирования. Посылается за- запрос GET, и страница Web начинает загружаться, как видно на распечатке ниже. Первый кадр, который начинает транспортировать данные, имеет дополнительную информацию заголовка HTTP и поэтому ограничен по- полезной нагрузкой в 1263 байта. Последующим кадрам не требуется дубли- дублировать всю информацию заголовка, поэтому они смогут переносить до 1460 байтов данных, как показано в следующем кадре. HTTP: Response (to client using port 3491) HTTP: Protocol Version = HTTP/1.1
Трафик приложений 207 HTTP: Status Code = OK HTTP: Reason = OK •¦• •• т ¦ ¦ HTTP: Server = Microsoft-IIS/4.0 HTTP: Date = Tue, 24 Aug 1999 03:02:37 GMT HTTP: Content-Length = 35376 HTTP: Content-Type = text/html HTTP: Expires = Tue, 24 Aug 1999 03:02:37 GMT HTTP: Undocumented Header = Cache-control: private HTTP: Undocumented Header Filedname = Cache-control HTTP: Undocumented Header Value = private HTTP: Data: Number of data bytes remaining = 1263 @x04EF) Как можно видеть в заголовке HTTP ниже, пакет максимизируется для транспортировки данных, полагаясь на TCP в вопросах обработки ошибок и упорядочивания данных. HTTP: Response (to client using port 3491) HTTP: Data: Number of data bytes remaining = 1460 @x05B4) : Когда данные начинают передаваться по каналу, это происходит как лю- любая другая передача данных с помощью TCP/IP. В трассировке мы видим пару кадров HTTP, за которыми следует пара кадров АСК TCP. :.. .; I. Secure Sockets Layer Реализация Secure Sockets Layer (SSL) является существенной для успеш- успешной электронной коммерции и бизнеса в Интернете. Она начинается обычно с соединения с портом 80, как показано в трассировках. Когда клиентская машина попадает на страницу, которая требует SSL, сервер вернет FIN из порта 80 в порт назначения на клиентской машине. TCP: .A...F, len: 0, seg: 2958296-2958296, ack: 256976, win: 8092, src: 80 dst: 4346 TCP: Source Port = Hypertext Transfer Protocol TCP: Destination Port = OxlOFA TCP: Sequence Number = 2958296 @x2D23D8) TCP: Acknowledgement Number = 256976 (ОхЗЕВОО) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) TCP: Flags = 0x11 : .A...F TCP: ..0 = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: 0. . = No Reset TCP: 0. = No Synchronize " ;i • .¦: v TCP: 1 = No more data from sender Клиентская машина подтверждает FIN, по-прежнему используя тот же порт источника и приходя в порт HTTP 80 на сервере.
208 Глава 7 TCP: .A , len: 0, seq: 256976-256976, аск: 2958297, win: 7885, src: 4346 dst: 80 TCP: Source Port = OxlOFA TCP: Destination Port = Hypertext Transfer Protocol TCP: Sequence Number = 2 56976 @x3EBD0) TCP: Acknowledgement Number = 2958297 @x2D23D9) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) TCP: Flags = 0x10 : .A.... TCP: ..0 = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: 0.. = No Reset " ' ' TCP: 0. = No Synchronize '¦ /s ' TCP: 0 = No FIN .- ; !; ' • ¦." ¦:'"< ]': Теперь на сервере происходит интересная вещь: он переключает порты на клиентской машине. Порт источника на сервере изменяется на 443 — об- общеизвестный порт для коммуникации SSL, и также изменяется порт назна- назначения на клиентской машине. В данном случае порт назначения изменяется на 4347, на единицу больше, чем было в последнем соединении. Сервер также подтверждает предыдущий кадр с клиентской машины и по- посылает запрос для синхронизации номеров последовательности на запра- запрашивающую машину. Когда все это будет выполнено, между двумя машинами начнут перемещаться данные. —¦-•, :—: ~-г. — .-„. ^-ч-. TCP: .A..S., len: 4, seq: 2913904-2913907, ack: 252920, win 8760, src: 443 dst: 4347 TCP: Source Port = 0x0IBB , . ¦ • .. , TCP: Destination Port = OxlOFB TCP: Sequence Number = 2913904 @x2C7670) TCP: Acknowledgement Number = 252920 @x3DBF8) TCP: Data Offset = 24 @x18) TCP: Reserved = 0 @x0000) TCP: Flags = 0x12 : .A..S TCP: ..0 = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: 0. . = No Reset TCP: 1. = Synchronize sequence numbers TCP: 0 = No FIN Оптимизация трафика броузера в интрасети Лучшее, что можно сделать для оптимизации трафика броузера в интрасе- интрасети,— это небольшие, эффективные страницы Web, где создается большая часть трафика. Чтобы реализовать эту оптимизацию, можно предпринять следующее:
Трафик приложений 209 1. Сократите число графических изображений, используемых на стра- странице Web, так как они составляют существенную часть сетевого тра- трафика. При использовании графики проверьте, что графический формат оптимизирован для Web (т.е. не используйте файлы .bmp или .tiff, так как с ними связан большой объем дополнительных накладных расходов). 2. Ограничьте использование фреймов, так как использование несколь- нескольких фреймов может приводить к нескольким загрузкам для каждой страницы. 3. Сократите необходимость прокручивания страницы. Чтобы сделать это, разбейте страницу на меньшие куски. Таким образом, если клиент не заинтересован во всей странице, не будет затрачиваться дополнительное время для загрузки ненужной информации. 4. Разместите серверы прокси в удаленных местах и разрешите активное кэширование. Это позволит сократить количество повторных загрузок одной и той же информации. 5. Увеличьте размер кэша на локальной машине. Кэширование данных на локальной машине ускорит для пользователя процесс просмотра и сократит сетевой трафик. Все это уменьшает для компьютера необходи- необходимость загружать одну и ту же информацию при повторном посещении страниц Web. 6. Тщательно оцените необходимость защищенности (как узлов, защи- защищенных паролем, так и SSL), поскольку слишком слабая защищенность вызывает дополнительный сетевой трафик. Обзор главы В этой главе были рассмотрены различные типы трафика приложений. Мы начали с трафика пересылки файлов и печати. Помимо трафика, вовлечен- вовлеченного в пересылку данных, мы оценили также накладные расходы, связан- связанные с методами разрешения имен, созданием соединения и согласованием диалекта SMB. После просмотра трафика файлов и печати мы перешли к изучению трафика Интернета и показали взаимодействия, происходящие при просмотре Web. Здесь мы снова встретили трафик разрешения имени и трафик создания соединения. Накладные расходы здесь меньше, чем для трафика файлов и печати, так как протоколы оптимизированы для работы в среде с узкой полосой пропускания. В следующей главе В следующей главе мы рассмотрим трафик сервера Microsoft Exchange и сравним его с РОРЗ Интернета. Мы обсудим последовательность опера- операций, когда Exchange открывает и закрывает соединение, а также вопросы разрешения имен.
Глава 8 Exchange и почта Интернета При установке новые приложения загружают и автоматически запускают некоторые службы. Если приложение хорошее, то это будет одна или две службы. Однако многие приложения сегодня загружают множество служб, которые объявляют всем о своем существовании. Exchange ¦ ¦ - ¦¦¦»»¦; ¦¦¦*;¦¦ ¦¦> .-. >.-.-гв»--••¦:.-.¦. . ¦.¦- ¦¦ 1 Протокол SMTP (Simple Mail Transfer Protocol, простой протокол передачи почты) используется для получения почты из Интернета. Когда адрес сер- сервера преобразован (с помощью DNS), создается соединение с портом 25. Команды SMTP используются для управления потоком почты из одной ма- машины в другую. Каждая из этих команд заканчивается нажатием клавиши Enter или Return. Команды SMTP не зависят от регистра символов, хотя SMTP будет сохранять регистр при адресации, так как некоторые реализа- реализации могут иметь имена пользователей, зависящие от регистра символов. Как видно на рис. 8.1, для создания соединения может использоваться Telnet, а также другой сервер SMTP. Это часто делается для тестирования соединения Connect Host Name: |exchange.fullservjj Port: Ш 71 I } lerrnType: |vt100 Connect Cancel Рис. 8.1. Telnet может использоваться для тестирования соединения с Exchange
Exchange и почта Интернета 211 почты Интернета с Exchange. Процесс начинается с команды mail, посылаемой отправителем с помощью from: в форме <имя_пользователя>@<имя_^цомена>. From: является полем, которое сообщает серверу SMTP имя пользователя. <имя_пользователя>@<имя_^цомена> также станет ответом для адреса. Команда HELO (HELLO в некоторых реализациях) позволяет узнать, общаются ли две машины. В то время как приветствие при соединении идентифицирует сервер получателя, HELO используется для идентифика- идентификации отправителя на сервере SMTP. HELO и сопровождающий 250 ОК по- позволяют узнать, что отправитель и получатель находятся в состоянии начального соединения без выполняющихся транзакций и с пустыми буфе- буферами. Команда mail сообщает серверу SMTP, что начинается новая транзак- транзакция. Если все правильно, то вернется ответ 250 ОК. from: называется также адресом обратного пути. Он может содержать более одного почтового ящика, а также список хостов для обратной маршрутизации источника. Следующей командой MAIL используется для начала почтовой транзак- транзакции. Эта строка также будет содержать from:, что называется обратным пу- путем доступа и используется для извещений о недоставке. Эта информация хранится сервером SMTP отправителя в буфере обратных путей доступа, который будет обрабатываться после ввода всех данных. RCPT идентифицирует получателя сообщения и является командой, вводимой после команды mail. Если эта команда mail получена сервером SMTP правильно, то будет возвращаться ответ 250-ОК. Если получатель не- неизвестен, то с сервера вернется ошибка 550. Если получатель введен непра- неправильно, то будет порождаться ошибка 553 неправильно сформированного адреса. Протокол позволит в этом месте ввести в процесс несколько полу- получателей. Нажатие клавиши Return в конце строки RCPT и ввод другой команды RCPR вводит дополнительных получателей. Кроме почтового ящика в поле RCPT можно также поместить список маршрутов хостов источников. Данные RCPT хранятся в буфере путей доступа пересылки столько, сколько нужно серверу. Третьим шагом является команда DATA, за которой следует нажатие клавиши Enter или отправка возврата каретки и перевода строки (<CRLF>) (несколько анахронический термин). Когда сервер получит эту команду, протокол SMTP рассматривает весь последующий трафик как данные для этого поля, пока не получит строку, содержащую только одну точку. Други- Другими словами, раздел данных завершается, когда получающий сервер полу- получит строку символов геШгп-точка-return (<CRLF>.<CRLF>). Индикатор конца данных подтверждает транзакцию и приказывает серверу SMTP об- обработать данные в буфере обратного пути доступа и буфере пути доступа пересылки. Когда обработка закончена, сервер вернет ОК. Приняв сообще- сообщение, сервер вставляет отметку времени в начале строки почтовых данных, которая указывает идентичность посылающего и получающего хостов. При конечной доставке сообщения также вставляется строка пути возврата, ко- которая содержит информацию из обратного пути, введенного вместе с командой mail. Поле данных почты может также содержать, если потребу- потребуется, тему данных, строки to, ее и from. На рис. 8.2 показано использование этих команд в сеансе Telnet, созданном с сервером Exchange. Это хороший способ протестировать соединение Exchange и почты Интернета.
212 Глава 8 Telnet-208 112.201.97 ¦-IN :l Jdi Ieinmal Hdp j 220 taconic.fullservice.net ESMTP Seruer (Microsoft Exchange Internet Kail Serui ce $.5.2232.9) ready helo ; ¦, . - . , , .,,. ¦, .. J50 OK - .. ..... Mil fron: billgSraicrosoft.con 250 OK - nail fron <billgGnicrosoft.con> rcpt to: eduafullseruice.net 258 OK - Recipient <edwefullseruice.net> data ¦ .,¦ -.: , - • . JS4 Send data. End with CRLF.CRLF subject: looking forward to seeing your book Ed, just heard about your new book. An really looking forward to reading it. В SO OK Рис. 8.2. Команды SMTP, посылаемые во время тестового сеанса Команда DATA будет отказывать, только если транзакция является не- неполной или нет доступных ресурсов для обработки запроса. Реализация SMTP в Microsoft Exchange не позволит иметь неполное сообщение. Как можно видеть на рис. 8.3, Exchange требует, чтобы команды вводились в определенном порядке, прежде чем он будет обрабатывать данные. Я Telnet - exchange lullseivice.net Connect ?<*< lermnal Help 228 taconic.fullseruice.net ESMTP Seruer (Microsoft Exchange Internet Hail Serui ce 5.5.2232.9) ready helo 251 OK 503 Ho recipients: need RCPT 563 Ho originator: need HAIL ~ nail 581 Syntax Error nail fron: edwQfullseruice.net 250 OK - nail fron <eduQfullseruice.net> Рис. 8.З. Microsoft Exchange требует, чтобы команды SMTP были в определенном порядке
Exchange и почта Интернета 213 Протокол SMTP включает дополнительные свойства для помощи в по- поиске получателей и списков распространения. Этими командами являются команда VRFY, которая используется для предоставления информации о пользователях почтового ящика, и команда EXPR, используемая для спис- списков распространения. Однако, как видно на рис. 8.4, эти команды не реали- реализованы в Microsoft Exchange по соображениям безопасности. Вместо них для предоставления этой информации используется LDAP. Команда NOOP используется для определения отсутствия операции. Она не влияет ни на какие введенные ранее команды или параметры. Она просто означает ничего не делать и получает с сервера ответ ОК. RSET является командой сброса, которая прерывает текущую транзак- транзакцию. Вся информация в буферах будет сброшена и таблицы состояния очи- очищены. Она также получает с сервера ответ ОК. Эта команда может быть отправлена в любой момент во время общения. . ...... 9 Telnet exchange lullseivice.net Connect ?* Tetm«ial Help 229 taconic.fullseruice.net ESHTP Server (Hicrosoft Exchange Internet Mail Serui ce 5.5.2232.9) ready helo '258 OK ...... iwrfy dauem ' |252 Cannot uerify user . ;. •¦ urfy davea9fullseruice.net 252 Cannot uerify user expn service "¦" ¦ •>: i4>~ 502 copmand not inplenented •. .;.• -л* '. . •' ¦r Рис. 8.4. Дополнительные свойства SMTP, например VRFY и EXPN, не реализованы в Exchange Открытие и закрытие сеанса Когда между двумя компьютерами впервые создается сеанс, есть возмож- возможность убедиться, что серверы общаются именно с тем, с кем они собира- собирались общаться. Для этого используется команда HELO. Эта команда может посылаться только один раз и имеет форму HELO mred.com. HELO иденти- идентифицирует посылающий компьютер для сервера SMTP. Если при обработке команды не возникает ошибок, то ответом будет 250 ОК. Эту команду мож- можно интерпретировать как "Привет, я mred.com". Если команда HELO
214 Глава 8 посылается во второй раз, то ответом будет 503 bad sequence (неверная по- последовательность). В указанном домене никакой проверки не делается, и имя домена можно оставить пустым, как на рис. 8.2. Когда сеанс заканчивается, для закрытия канала посылается команда QUIT. Сервер Exchange в действии Рассмотрим теперь некоторые трассировки, показывающие, как работает почта SMTP в реальной жизни. Для создания соединения SMTP с Exchange требуется пять кадров и 420 байтов. Это включает трехходовое квитирова- квитирование, кадр готовности службы SMTP и еще один кадр подтверждения (АСК). Посмотрим на кадр готовности службы на распечатке ниже. Код ответа 220, как мы знаем из таблицы 8.1, означает, что служба готова. Этот кадр поступа- поступает из порта 25, который используется для службы SMTP. Код 220 посылается как стандартный код ASCII и показан в шестнадцатеричной панели как 32 32 30. Символ ASCII для 20 равен 50 и преобразуется в шестнадцатеричное 32. Символ ASCII для 0 равен 48 и преобразуется в шестнадцатеричное 30. SMTP: Rsp: Service ready, 102 bytes SMTP: Response = 220 taconic.fullservice.net ESMTP ' Server (Microsoft Exchange Internet Mail SMTP: Data = Service 5.5.2232.9) ready ........... , с Хотя TCP является дуплексным протоколом, SMTP действует только в полудуплексном режиме. Это означает, что посылаемый символ должен быть подтвержден перед посылкой следующего символа. Это требование создает большой объем трафика подтверждения (АСК). Например, просто отправка команды HELO требует 11 кадров и 695 байтов. Когда посылается и подтверждается HELO, следующий кадр с клиентской машины посылает 0D 0А (ASCII 13, возврат каретки, и ASCII 10, перевод строки), как видно на распечатке ниже. TCP: .АР , 1еп: 2, seq: 123557-123558 ack: 1430817, win 8658, src: 1667 dst: 25 (SMTP) TCP: Source Port = 0x0683 ¦ . TCP: Destination Port = SMTP " ~" TCP: Sequence Number = 123557 @xlE2A5) TCP: Acknowledgement Number = 1430817 @xl5D521) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) + TCP: Flags = 0x18 : .AP... .,-, ¦ ,-,.,. ..,bj_ ^ .;„. TCP: Window = 8658 @x21D2) ' ''' '' " ' " ' "' TCP: Checksum = 0x997F •• ' ¦ •'"' '-¦ <':*¦-¦¦•¦' '-¦' TCP: Urgent Pointer = 0 @x0) - TCP: Data: Number of data bytes remaining = 2 @x0002) SMTP: Cmd: completed, 2 bytes 00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10 f.. .E. 00010: 00 2A C2 B3 40 00 80 06 OF 15 CE 70 C2 B2 CE 70
Exchange и почта Интернета 215 .*. -@ р.. .р 00020: С9 61 06 83 00 19 00 01 Е2 А5 00 15 D5 21 50 18 .а ! Р. ¦. 00030: 21 D2 99 7F 00 00 0D ОА ' Таблица 8.1. Коды ответа SMTP Код Значение 211 Состояние или справка готовы. 214 Справочное сообщение. 220 Служба домена готова. 221 Служба домена закрывает канал передачи. ...... 250 Действие закончилось успешно (ОК). 251 Пользователь не локальный. Пересылка в место назначения. 354 Начало ввода почты. ' 421 Служба недоступна. Закрытие канала. 450 Действие не принято. Почтовый ящик недоступен ' • (почтовый ящик занят). 451 Действие прекращено. Обрабатывается локальная ошибка. .452 . .... . Действие не принято. Недостаточно системной памяти. .;*ii 500 - Синтаксическая ошибка. Команда не опознана. 501 ' ¦ Синтаксическая ошибка в параметрах или аргументах. '¦ > ¦ 502 Команда в системе не реализована. ' : ' 503 . . Неверная последовательность команд. Команды ,,,, , в неправильном порядке. , ...... 504 ';'¦ I: Параметр команды не реализован. Команда допустима, '! но параметр — нет. Г. ¦ , -.- 550 Действие не принято. Почтовый ящик недоступен ¦: (или не найден). ! ' 551 ^ Пользователь не локальный. Сообщение необходимо переслать. 552 . Действие прервано. Превышение выделенной памяти. 553 Действие не принято. Имя почтового ящика недопустимо ' v-* ¦' (неправильный синтаксис почтового ящика). 554 Отказ транзакции. ""¦>' "¦'"-¦¦ Когда посылающая машина пересылает кадр с завершенной коман- командой, получающий сервер SMTP подтверждает это ответом 250 ОК B50 ASCII в шестнадцатеричном виде будет 32 35 30; 20 — символ пробела; ASCII 79 в шестнадцатеричном виде 4F, a ASCII 75 — 4В. Отметим 0D 0А в качестве последних двух байтов в шестнадцатеричной панели).
216 Глава 8 TCP: .АР..., len: 8, seq: 1430817-1430824, ack: 123559, win: 8754, src: 25 (SMTP) dst: 1667 TCP: Source Port = SMTP TCP: Destination Port = 0x0683 TCP: Sequence Number = 1430817 @xl5D521) TCP: Acknowledgement Number = 123559 @xlE2A7) TCP: Data Offset = 20 @x14) ?• v.4' ' TCP: Reserved = 0 @x0000) + TCP: Flags = 0x18 : .AP... '" : - TCP: Windows = 8754 @x2232) ^ .'.. TCP: Checksum = 0xE776 TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 8 @x0008) SMTP: Rsp: Requested mail action okey, completed, 8 bytes SMTP: Response = 250 OK 00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 00 -• f E. 00010: 00 30 15 00 40 00 7D 06 BF D2 CE 70 C9 61 CE 70 .0..@.}....p.a.p 00020: C2 B2 00 19 06 83 00 15 D5 21 00 01 E2 A7 50 18 ! P. 00030: 22 32 E7 76 00 00 32 35 30 20 4F 4B 0D 0A .v..250 OK.. ПРОТОКОЛ РОРЗ -иЛи—^1 •< ¦•: ь- — Протокол РОРЗ используется как упрощенный протокол почты, который хранит сообщения на сервере, пока клиентская машина не соединится и не выгрузит их по запросу. Он делает не слишком много по обработке сообще- сообщения на сервере; служба РОРЗ просто слушает порт TCP ПО, пока почта не бу- будет извлечена, и удаляет ее из почтового хранилища. Это не очень развитый протокол, но он достаточно эффективен. Когда клиент РОРЗ хочет создать соединение, он следует схеме одиноч- одиночных рабочих команд. Подобно протоколу SMTP, который был рассмотрен ранее, команды состоят из символов ASCII, разделенных пробелами. Эти команды имеют длину в три или четыре символа. Модификаторы для команд РОРЗ могут быть до 40 символов длиной. Сервер РОРЗ дает два типа ответов. Первый ответ является положитель- положительным (+ОК, как показано на рис. 8.5). Отрицательным ответом является -ERR. Оба эти ответа должны быть представлены заглавными буквами и содержать либо знак -, либо знак +. Некоторые команды будут создавать многострочный ответ с сервера (на- (например, команда list), и каждая строка будет заканчиваться комбинацией возврата каретки и перевода строки (та же самая комбинация ASCII 13 и ASCII 10 использовалась в протоколе SMTP). Когда все строки будут посла- посланы, сервер пошлет . (ASCII 46) и дополнительный перевод строки. Это та же комбинация <RLF>. [точка]<RLF>, которую мы видели в протоколе SMTP.
Exchange и почта Интернета 217 ¦Э» Telnet - roetl.one.nel Connect ?dl leimlnal Help •OK PDP3 U1.21 1997/08/16 ready <3c3600800d57cii37aiiMil.one.net> user euilsan •OK ewilson selected pass VpPXUxZQ >OK Congratulations! stat »0K » 13203 List >OK 4 Messages A32B3 octets) 1 983 г 9t1 9 7911 i 9UI ' Рис. 8.5. Команды РОРЗ, отправленные во время сеанса Telnet Четыре состояния РОРЗ Во время процесса соединения клиента и получения почты РОРЗ проходит через четыре состояния. После начально- начального соединения TCP и последующего приветствия сервер входит в состояние авторизации, в котором клиент идентифицирует себя. Вслед за состоянием авторизации РОРЗ входит в состояние транзакции и получает команды с клиентской машины для обработки почты. После успешной обработки поч- почты и отправки клиентом команды завершения quit сеанс входит в фазу об- обновления и освобождает ресурсы, использованные во время состояния транзакции. Затем соединение TCP закрывается. Эта последовательность событий для успешного сеанса подробно описана в следующем списке. 1. Клиентская машина запрашивает у DNS адрес. 2. Когда адрес получен, машина инициирует трехходовое квитирова- квитирование на порте 110. 3. Вслед за трехходовым квитированием сервер посылает приветствие. 4. Клиент отвечает именем пользователя. 5. Сервер проверяет, существует ли пользователь в системе, и отвечает с помощью +ОК. 6. Клиент отвечает паролем. г 7. Сервер отвечает +ОК. 8. Клиент запрашивает состояние почтового ящика.
218 Глава 8 9. Сервер отвечает, посылая число и размер сообщений в почтовом ящике. 10. Клиент запрашивает список сообщений. • f iv 11. Сервер отвечает. . ,'.' ' " , 12. Клиент пересылает себе сообщения. 13. Клиент стирает сообщения на сервере. 14. Когда все сделано, он посылает команду завершения quit. 15. Сервер отвечает с помощью+ОК. Таблица 8.2 суммирует команды РОРЗ, которые обычно встречаются в трассировках сетевого мониторинга. Таблица 8.2. Обычно используемые команды РОРЗ Команда Аргументы Описание QUIT STAT Нет Нет LIST RETR Номер сообщения (не обязателен) Номер сообщения (требуется) DELE Номер сообщения (требуется) NOOP Нет RSET QUIT Нет Нет Используется для аккуратного закрытия сеанса РОРЗ. Позволяет серверу войти в состояние обновления, где он освобождает ресурсы. Запрашивает у сервера число и размер сообщений в почтовом ящике. Ответ будет иметь вид +ОК nn mm, где пп — число сообщений, a mm — число использованных байтов. Перечисляет сообщения по номеру и размеру. • .¦••. . ¦ -.•¦• •¦¦ Выбирает сообщение с сервера РОРЗ по номеру. Сервер возвращает +ОК, количество байтов и текст сообщения. Удаляет сообщение с сервера по номеру. Нет операции. Вызывает с сервера . ,- сообщение +ОК. Сбрасывает сеанс. Снимает отметки со всех сообщений, которые были помечены для удаления (используя команду DELE). Сервер удаляет сообщения, помеченные командой DELE, освобождает ресурсы, и закрывает соединение TCP.
Exchange и почта Интернета 219 Таблица 8.2. Обычно используемые команды РОРЗ (продолжение) Команда Аргументы Описание ТОР USER Номер сообщения и число строк для извлечения (требуется). Используется для извлечения некоторого числа строк из определенного сообщения. Если число запрошенных строк больше, чем объем сообщения, то извлекается все сообщение. Имя пользователя на Во время состояния приветствия сервере (требуется) до состояния транзакции сообщает серверу, какой почтовый ящик открыть. PASS Пароль (требуется) Используется во время состояния авторизации немедленно после успешной команды USER. При успехе сервер отвечает +ОК. Рассмотрим реальный сеанс РОРЗ. Этот кадр возникает немедленно по- после трехходового квитирования на порте ПО и сигнализирует о входе в фазу приветствия. РОРЗ использует TCP для переноса команд данных в виде текста ASCII. В распечатке ниже мы видим приветствие РОРЗ +ОК. TCP: .АР..., len: 66, seq: 836990619-836990684, ack: 124982, win:32736, src: 110 dst: 1844 TCP: Source Port = Post Office Protocol — Version 3 TCP: Destination Port = 0x0734 TCP: Sequence Number = 836990619 @x31E3769B) TCP: Acknowledgement Number = 124982 @xlE836) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) + TCP: Flags = 0x18 : .AP... ' . TCP: Window = 32736 @x7FE0) ¦ ; ....;• . TCP: Checksum = 0x5437 , ,. •..•-,¦ . ,', ,, TCP: Urgent Pointer = 0 @x0) . . , TCP: Data: Number of data bytes remaining = 66 @x0042) ¦ ' 00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 10 f E. 00010: 00 6A ЕЕ 25 40 00 3D 06 IF 69 CE 70 CO 64 CE 70 .j.%@.=..i.p.d.p 00020: D2 A9 00 6E 07 34 31 E3 76 9B 00 01 E8 36 50 18 ...n.41.v....6P. 00030: 7F E0 54 37 00 00 2B 4F 4B 20 50 4F 50 33 20 76 .T7..+OK РОРЗ v 00040: 31 2E 32 31 20 31 39 39 37 2F 30 38 2F 31 30 20 1.21 1997/08/10
220 Глава 8 Теперь мы входим в фазу авторизации, которая направляется с клиент- клиентской машины в порт TCP 110 на сервере. Отметим, что заданные в кадре флаги А и Р говорят нам, что поле подтверждения существенно, а также приказывают серверу отправить данные. В поле HEX мы видим команду USER и аргумент edwilso. Кадр заканчивается шестнадцатеричными 0D 0А, которые мы видели в других кадрах. Отметим, что этот трафик посылается как обычный текст ASCII. TCP: .АР..., len: 14, seq: 124982-124995, ack: 836990685, win: 8694, src: 1844 dst: 110 TCP: Source Port = 0x0734 '¦'¦¦¦¦¦¦ TCP: Destination Port = Post Office Protocol — Version 3 TCP: Sequence Number = 124982 @xlE836) TCP: Acknowledgement Number = 836990685 @x31E376DD) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) + TCP: Flags = 0x18 : .AP... TCP: Window = 8694 @x21F6) TCP: Checksum = 0xA9DE TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 14 (OxOOOE) • . . , 00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10 f...E. 00010: 00 36 06 DO 40 00 80 06 C3 F2 CE 70 D2 A9 CE 70 .6. .@ p. . .p 00020: CO 64 07 34 00 6E 00 01 E8 36 31 E3 76 DD 50 18 .d.4.n...61.v.p. 00030: 21 F6 A9 DE 00 00 55 53 45 52 20 65 64 77 69 6C ! USER edwi 1 00040: 73 6F 0D 0A so. . Сервер указывает, что существует пользователь с почтовым ящиком с именем ewilso. ASCII гарантирует, что регистр символов будет сохранен, использует это или нет определенная реализация. Команда PASS использу- использует регистр символов. Этот ответ приходит из порта 110 на компьютер мес- места назначения с заданными флагами А и Р. Мы неоднократно это увидим, пока сервер будет проходить через различные состояния. Отметим, что но- номер подтверждения совпадает с номером последовательности в следующем кадре. TCP: .АР..., len: 22, seq: 836990685-836990706, ack: 124996, win:32736, src: 110 dst: 1844 TCP: Source Port = Post Office Protocol - Version 3 TCP: Destination Port = 0x0734 TCP: Sequence Number = 836990685 @x31E376DD) TCP: Acknowledgement Number = 124996 @xlE844) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) + TCP: Flags = 0x18 : .AP...
Exchange и почта Интернета 221 „....., ¦;. TCP: Window = 32736 @x7FE0) , ,, . . .... v. .-. i!(, TCP: Checksum = 0x8AAD ' " .,/,,. TCP: Urgent Pointer = 0 @x0) ." ''"_' TCP: Data: Number of data bytes remaining =22 @x0016) 00000: 00 01 BO 81 66 80 F8 E0 07 00 01 01 08 00 45 10 f E. 00010: 00 ЗЕ ЕЕ 30 40 00 3D 06 IF 8A CE 70 CO 64 CE 70 .>.0@.=....p.d.p 00020: D2 A9 00 6E 07 34 31 E3 76 DD 00 01 E8 44 50 18 ...n.41.v....DP. 00030: 7F E0 8A AD 00 00 2B 4F 4B 20 65 64 77 69 6C 73 +OK edwils 00040: 6F 20 72 65 6C 65 63 74 65 64 0D 0A . ' Q. selected. Теперь начинаются заботы о почте РОРЗ. Через Интернет открытым текстом посылается пароль. Команда PASS переносит аргумент пароль, лег- легко различимый в шестнадцатеричной трассировке. Конечно, необходимо быть в нужном месте в нужное время, чтобы его перехватить, но пароль там есть. Он поступает с клиентской машины в порт 110 на сервере. Снова заданы флаги А и Р, а кадр заканчивается шестнадцатеричными 0D 0А. Сравните номер последовательности в кадре ниже с номером подтверждения из предыдущего кадра — они совпадают. TCP: .АР..., len: 15, seq: 124996-125010, ack: 836990707, win: 8672, src: 1844 dst: 110 TCP: Source Port = 0x0734 TCP: Destination Port = Post Office Protocol — Version 3 ; TCP: Sequence Number = 124996 @xlE844) TCP: Acknowledgement Number = 836990707 @x31E376F3) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) + TCP: Flags = 0x18 : .AP... TCP: Window = 8672 @x21E0) ' TCP: Checksum = 0x6533 TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 15 (OxOOOF) 00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10 f.. .E. 00010: 00 37 07 DO 40 00 80 06 C2 Fl CE 70 D2 A9 CE 70 .7. .@ p. - -p 00020: CO 64 07 34 00 6E 00 01 E8 44 31 E3 76 F3 50 18 .d.4.n...Dl.v.p. 00030: 21 E0 65 33 00 00 50 41 53 53 20 5A 31 61 2A 30 !.e3..PASS Zla*0 00040: 6D 38 69 0D OA m8i. . '
222 " Глава 8 Сервер отвечает из порта 110 с поздравлением +ОК и 0D 0А. Это сигна- сигнализирует об окончании состояния авторизации. Мы видим флаги А и Р, отправляя данные назад на клиентскую машину. TCP: .АР len: 22, seq: 836990707-836990728, ack: 125011, win:32736, src: 110 dst: 1844 TCP: Source Port = Post Office Protocol — Version 3 TCP: Destination Port = 0x0734 TCP: Sequence Number = 836990707 @x31E376F3) TCP: Acknowledgement Number = 125011 @xlE853) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) . .¦/'.'' (.. + TCP: Flags = 0x18 : .AP... ' " \ TCP: Window = 32736 @x7FE0) . ' ,ч TCP: Checksum = 0x8797 TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 22 @x0016) : ' ¦•"•.i 00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 10 1 f E. , i7 00010: 00 3E F2 24 40 00 3D 06 IB 96 CE 70 CO 64 CE 70 . , .>.$©.=....p.d.p ."¦;.;, .„,, 00020: D2 A9 00 6E 07 34 31 E3 76 F3 00 01 E8 53 50 18 . . .n.41.v. . . .SP. ""''" 00030: 7F E0 87 97 00 00 2B 4F 4B 20 43 6F 6E 67 72 61 " ' +OK Congra 00040: 74 75 6C 61 74 69 6F 6E 73 21 0D 0A . ;; - tulations!.. Первый кадр в фазе транзакции передает команду STAT, чтобы увидеть, сколько сообщений ожидают в почтовом ящике. TCP: .АР..., len: 6, seq: I 25011-125016, ack: 836990729, win: 8650, src: 1844 dst: 110 TCP: Source Port = 0x0734 TCP: Destination Port = Post Office Protocol - Version 3 TCP: Sequence Number = 125011 @xlE853) TCP: Acknowledgement Number = 836990729 @x31E37709) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) . , .. + TCP: Flags = 0x18 : .AP... . . :. . .* TCP: Window = 8650 @x21CA) TCP: Checksum = 0x2377 TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 6 @x0006) 00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10 f...E. 00010: 00 2E 08 DO 40 00 80 06 Cl FA CE 70 D2 A9 CE 70 @ p. . .p 00020: CO 64 07 34 00 6E 00 01 E8 53 31 E3 77 09 50 18 .d.4.n...Sl.w.P.
Exchange и почта Интернета 223 00030: 21 СА 23 77 00 00 53 54 41 54 0D 0А ... ! .#w. .STAT. . ¦.-.-¦-- Сервер отвечает числом сообщений и байтов в почтовом ящике пользо- пользователя. +ОК указывает на успешную команду. В данном случае на сервере в наличии девять сообщений общим объемом 48564 байтов, как показано в шестнадцатеричной панели в распечатке ниже. TCP: .AP..., len: 13, seq: 836990729-836990741, ack: 125017, win:32736, src: 110 dst: 1844 ., TCP: Source Port = Post Office Protocol - Version 3 гя. TCP: Destination Port = 0x0734 . . § \ Sequence Number = 836990729 @x31E37709) '•'¦"'" Acknowledgement Number = 125017 @xlE859) ';i "'"'.'¦'¦ Data Offset = 20 @x14) •' ¦ " ' Reserved = 0 @x0000) '¦ .•¦¦>;.''n-. •:'k.o-> v Flags = 0x18 : .AP... Window = 327 36 @x7FE0) .. ". ' . ': Checksum = OxOFFB ,'... .,,.¦:.;. Urgent Pointer = 0 @x0) Data: Number of data bytes remaining = 13 TCP: ''"" " TCP: TCP: TCP: + TCP: TCP: -/. TCP: TCP: TCP: (OxOOOD) 00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 10 f E. 00010: 00 35 F2 32 40 00 3D 06 IB 91 CE 70 CO 64 CE 70 .5.2@.=....p.d.p 00020: D2 A9 00 6E 01 34 31 E3 77 09 00 01 E8 59 50 18 ...n.41.w....YP. 00030: 7F EO OF FB 00 00 2B 4F 4B 20 39 20 34 38 35 36 +OK 9 4856 00040: 34 0D 0A . . . .., 4.. ..-¦...• , . ¦.. Следующей в интерактивной фазе является команда LIST, за которой следует 0D 0А, чтобы сообщить серверу, что команда закончилась. Мы видим это в шестнадцатеричной панели ниже. 125017-125022, ack: dst: 110 TCP: .АР..., len: 6, seq: 836990742, win: 8637, src: 1844 TCP: Source Port = 0x0734 TCP: Destination Port = Post Office Protocol - Version 3 TCP: Sequence Number = 125017 @xlE859) TCP: Acknowledgement Number = 836990742 @x31E37716) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) ': ' + TCP: Flags = 0x18 : .AP... TCP: Window = 8637 @x21BD) • TCP: Checksum = 0xl87C TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 6 @x0006) 00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10
224 ' Глава 8 00010: 00 2Е 09 DO 40 00 80 06 CO FA CE 70 D2 A9 CE 70 • • • -@ P- • -P 00020: CO 64 07 34 00 6E 00 01 E8 59 31 E3 77 16 50 18 •¦; .d.4.n.. .Yl.w.P. ¦>.... ;¦¦.¦* ,.¦¦ ¦-¦: 00030: 21 BD 18 7C 00 00 4C 49 53 54 OD OA . ,,'j'jv, ;•'•<•¦ t'H ! . . I . .LIST. . .-¦: ; , ... Сервер РОРЗ отвечает с помощью +ОК и девяти сообщений D8564 окте- октетов). Все они записаны в шестнадцатеричной панели — даже левая и правая круглые скобки. Этот кадр в действительности больше, чем приведено в распечатке ниже (он сокращен для ясности). Вслед за числом октетов сле- следуют сообщения, пронумерованные и с указанием размера. Программное обеспечение будет использовать эту информацию для запроса с сервера РОРЗ сообщений по отдельности. TCP: .АР..., 1еп: 107, seg: 836990742-836990848, ack: 125023, win:32736, src: 110 dst: 1844 TCP: Source Port = Post Office Protocol — Version 3 TCP: Destination Port = 0x0734 TCP: Sequence Number = 836990742 @x31E37716) TCP: Acknowledgement Number = 125023 @xlE85E) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) + TCP: Flags = 0x18 : .AP... . . TCP: Window = 32736 @x7FE0) TCP: Checksum = 0xF276 ; _¦ ¦". TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 107 (ОхООбВ) 00000: 00 01 ВО 81 66 80 F8 E0 07 00 01 01 08 00 45 10 f E. 00010: 00 93 F2 3D 40 00 3D 06 IB 28 CE 70 CO 64 CE 70 ...=@. = . . (.p.d.p 00020: D2 A9 00 6E 07 34 31 E3 77 16 00 01 E8 5F 50 18 ...n.41.w...._P. 00030: 7F E0 F2 76 00 00 2B 4F 4B 20 23. 20 6D 65 73 73 ..v..+OK 9 mess 00040: 61 67 65 73 20 28 34 38 35 36 34 20 6F 63 74 65 ages D8564 octe Клиент начинает теперь считывать сообщения по отдельности. Первой будет команда ТОР, запрашивающая первое сообщение, как мы видим в шестнадцатеричной панели в распечатке ниже. TCP: .АР..., len: 9, seg: 125023-125031, ack: 836990849, win: 8530, src: 1844 dst: 110 TCP: Source Port = 0x0734 TCP: Destination Port = Post Office Protocol - Version 3 TCP: Sequence Number = 125023 @xlE85F) TCP: Acknowledgement Number = 836990849 @x31E37781)
Exchange и почта Интернета 225 TCP: Data Offset = 20 @x14) . .. TCP: Reserved = 0 @x0000) + TCP: Flags = 0x18 : .AP... ' ' TCP: Window = 8530 @x2152) ' ': TCP: Checksum = 0xB57D TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 9 @x0009) 00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10 f...E. 00010: 00 31 0A DO 40 00 80 06 BF F7 CE 70 D2 A9 CE 70 • 1. .@ p.-.p 00020: CO 64 07 34 00 6E 00 01 E8 5F 31 E3 77 81 50 18 .d.4.n..._1.w.P. .-;,..; 00030: 21 52 B5 7D 00 00 54 4F 50 20 31 20 30 0D 0A !R.}.- TOP 10.. . • Сервер отвечает +ОК на команду ТОР, и текст первого сообщения на- начинает передаваться клиенту. Сообщение имеет в длину 4292 октета, и этот кадр содержит первый из заголовков сообщения received:... Большая часть шестнадцатеричной панели не включена, но этот кадр несет полез- полезную нагрузку 1024 байта, в основном занятую различными типами почто- почтовых заголовков. Мы снова видим установленные флаги А и Р. Этот кадр поступает с сервера клиенту, так как порт источника ПО. TCP: .AP..., len: 1024, seq: 836990849-836991872, ack: 125032, win:32736, src: 110 dst: 1844 TCP: Source Port = Post Office Protocol - Version 3 TCP: Destination Port = 0x0734 TCP: Sequence Number = 836990849 @x31E37781) TCP: Acknowledgement Number = 125032 @xlE868) TCP: Data Offset = 20 @x14) TCP: Reserved = 0 @x0000) + TCP: Flags = 0x18 : .AP... TCP: Window = 3273 6 @x7FE0) TCP: Checksum = 0xlD4E TCP: Urgent Pointer = 0 @x0) TCP: Data: Number of data bytes remaining = 1024 @x0400) 00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 10 f E. 00010: 04 28 F2 7B 40 00 3D 06 17 55 CE 70 CO 64 CE 70 . ( . {@. = ..U.p.d.p 00020: D2 A9 00 6E 07 34 31 E3 77 81 00 01 E8 68 50 18 ...n.41.w....hP. 00030: 7F E0 ID 4E 00 00 2B 4F 4B 20 34 32 39 32 20 6F ..N..+OK 4292 о 00040: 63 74 65 74 73 0D 0A 52 65 63 65 69 76 65 64 ЗА ctets..Received: Клиент и сервер продолжают передавать сообщения с помощью комбина- комбинации кадров АСК и кадров ACK/PUSH. Сеанс, наконец, завершается
226 -.,„>»-,..- Глава8 командой QUIT и одним последним АСК (подтверждением). Число кадров зависит от размера сообщений, но по сути общение клиента и сервера остается таким же. Общение Exchange с другим сервером Когда Exchange общается с другим сервером, он использует не РОРЗ или SMTP, а вызовы удаленной процедуры (RPC), которые являются значитель- значительно более безопасной и надежной формой коммуникации. Чтобы понять бо- более полно, как работает эта коммуникация, нам необходимо рассмотреть несколько вещей, уникальных для RPC. Служба вызова удаленной процеду- процедуры выполняется на сервере Windows NT и решает множество задач, таких как идентификация номера порта, на котором действует определенная служба. Вызов удаленной процедуры помогает Exchange при поиске номе- номеров UUID (универсальной уникальной идентификации), связанных с опре- определенной службой. Эти UUID классифицируются по первым двум символам числа, и хотя другие службы помимо Exchange используют эти числа, не- несколько из них являются уникальными для продукта. Три наиболее важных номера перечислены ниже. . , ., м...... ..,,¦. • А4 — хранилище обмена я ¦ . "' • F5 — каталог обмена • Е1 — служба вызова удаленной процедуры Если служба вызова удаленной процедуры отказывает, то серверы обме- обмена (Exchange) не могут общаться друг с другом, а также с другими клиент- клиентскими машинами. По этой причине хорошее понимание функции RPC может существенно помочь при поиске неисправностей. Если два сервера обмена (Exchange) хотят общаться друг с другом, преж- прежде всего необходимо запросить службу вызова удаленной процедуры на дру- другом сервере обмена, чтобы определить, где осуществляет прием МТА (агент транспорта сообщений). Необходимость этого обусловлена тем, что МТА будет перемещаться и осуществлять прием на различных портах при последовательных перезагрузках. Служба вызова удаленной процедуры за- занимается отслеживанием всех различных служб и поддерживает список портов, которые они используют. Когда сервер Microsoft Exchange запуска- запускается, он зарегистрируется в службе вызова удаленной процедуры и запро- запросит номер выделенного порта. Служба вызова удаленной процедуры обслуживает запросы TCP/IP на порте 135. Она имеет фиксированный UUID, равный E1AF8308-5D1F-11C9- 91A4-08002B14A0FA. Общение между серверами будет начинаться с механизма разрешения имени (поиск WINS, DNS, Broadcast, LMHOST), после чего следует треххо- трехходовое квитирование. Затем Exchange посылает кадр в порт TCP 135, кото- который является службой местонахождения на другом сервере, и связывает RPC со службой вызова удаленной процедуры на другом сервере обмена. Мы узнаем об этом, рассматривая абстрактный интерфейс UUID E1AF8308- 5D1F-11C9-91A1-08002B14A0FA. El сообщает нам, что это служба вызова удаленной процедуры.
Exchange и почта Интернета 227 + TCP: .АР len: 72, seq: 22639100-22639171, аск: 1469213, win: 8760, src: 1238 dst: 135 MSRPC: c/o RPC Bind: UUID E1AF8308-5D1F-11C9-91A4- 08002B14A0DFA call 0x0 assoc grp 0x0 xmit 0xl6DO recv 0xl6DO MSRPC: Version = 5 @x5) MSRPC: Version (Minor) = 0 @x0) '¦¦.!•-:¦ • ,- MSRPC: Packet Type = Bind MSRPC: Flags 1=0 @x0) MSRPC: 0 = Reserved -or- Not the first fragment (AES/DC) MSRPC: 0. = Not a last fragment -or- No cancel pending MSRPC: 0.. = Not a fragment -or- No cancel pending (AES/DC) MSRPC: ....0... = Receiver to respond with a fack PDU -or- Reserved (AES/DC) MSRPC: ...0.... = Not used -or- Does not support concurrent multiplexing (AES/DC) MSRPC: ..0 = Not for an idempotent request - or- Did not execute guaranteed call (Fault PDU only) (AES/DC) MSRPC: .0 = Not for a broadcast request -or- 'Maybe' call semantics not requested (AES/DC) MSRPC: 0 = Reserved -or- No object UUID specified in the optional object field (AES/DC) MSRPC: Packet Data Representation MSRPC: Fragment Length =72 @x48) MSRPC: Authentication Length = 0 @x0) MSRPC: Call Identifier = 0 @x0) MSRPC: Max Trans Frag Size = 5840 @xl6D0) MSRPC: Max Recv Frag Size = 5840 @xl6D0) MSRPC: Assoc Group Identifier = 0 @x0) MSRPC: Presentation Context List MSRPC: Number of Context Elements = 1 @x1) MSRPC: Presentation Context Identifier = 0 @x0) MSRPC: Number of Transfer Syntaxs = 1 @x1) MSRPC: Abstract Interface UUID = E1AF8308-5D1F- 11C9-91A4- 08002B14AOFA MSRPC: Abstract Interface Version = 3 @x3) MSRPC: Transfer Interface UUID = 8A885D04-1CEB- 11C9-9FE8- 08002B104860 MSRPC: Transfer Interface Version = 2 @x2) Другой сервер обмена подтверждает связывание с помощью BindAck в поле типа пакета, как можно видеть на распечатке. В разделе результатов мы видим подтверждение принятия. Мы успешно создали соединение RPC между службами вызова удаленных процедур двух серверов обмена. + TCP: .АР..., len: 60, seq: 1469213-1469272, ack: 22639172, win: 8688, src: 135 dst: 1238 MSRPC: c/o RPC Bind Ack: call 0x0 assoc grp 0x7622B xmit 0xl6D0 recv 0xl6D0 MSRPC: Version = 5 @x5) ¦¦¦¦'"¦¦¦¦ f ' MSRPC: Version (Minor) = 0 @x0)
228 . Глава 8 MSRPC: Packet Type = Bind Ack MSRPC: Flags 1=3 @x3) ' MSRPC: 1 = Reserved -or- First fragment (AES/DC) MSRPC: 1. = Last fragment -or- Cancel pending MSRPC: 0.. = Not a fragment -or- No cancel pending (AES/DC) MSRPC: ....0... = Receiver to respond with a fack PDU -or- Reserved (AES/DC) MSRPC: ...0.... = Not used -or- Does not support concurrent multiplexing (AES/DC) MSRPC: ..0 = Not for an idempotent request -or- Did not execute guaranteed call (Fault PDU only) (AES/DC) MSRPC: .0 = Not for a broadcast request -or- 'Maybe' call semantics not requested (AES/DC) MSRPC: 0 = Reserved -or- No object UUID specified in the optional object field (AES/DC! . ^ MSRPC: Packet Data Representation MSRPC: Fragment Length = 60 (ОхЗС) ¦ MSRPC: Authentication Length = 0 @x0) MSRPC: Call Identifier = 0 @x0) MSRPC: Max Trans Frag Size = 5840 @xl6D0) MSRPC: Max Recv Frag Size = 5840 @xl6D0) MSRPC: Assoc Group Identifier = 483883 @x7622B) + MSRPC: Secondary Address MSRPC: Padding Byte(s) ~ '"* * '"' MSRPC: Result List MSRPC: Number of Result = 1 @x1) MSRPC: Reserved = 0 @x0) MSRPC: Reserved 2 ' ' MSRPC: Presentation Context Results MSRPC: Result = Acceptance MSRPC: Reason = Reason not specified MSRPC: Transfer Syntax MSRPC: Transfer Interface UUID = 8A885D04- 1CEB-11C9-9FE8-08002B104860 MSRPC: Transfer Interface Version = 2 @x2) Первый сервер обмена посылает теперь RPC Request Opnum 0x3 друго- другому серверу обмена. В него включен UUID разыскиваемой службы. Эта команда используется для запроса номера порта службы, связанной с UUID. Получив этот номер порта, первый сервер обладает всей информацией, не- необходимой для контакта со службой на другой машине. Он закроет теперь соединение TCP/IP между ними и создаст соединение непосредственно с определенной службой. Серверы снова используют трехходовое квитирование TCP/IP для созда- создания соединения, а затем соединение делает двухходовое связывание RPC, означающее, что первый сервер обмена делает связывание RPC, за которым следует BindAck от второго сервера обмена.
Exchange и почта Интернета 229 Затем второй сервер обмена делает соединение с первым сервером с последующим BindAck. В этом общении имеются два связывания и два BindAck. Обзор главы В этой главе рассмотрен трафик сервера Exchange и почты Интернета. Мы начали с последовательности операций при открытии и закрытии сеансов Exchange. Были исследованы вопросы разрешения имен и роль TCP/IP. Затем мы перешли к рассмотрению Exchange в действии. Было подробно обсуждено взаимодействие, вовлеченное в обмен сообщениями. Вслед за этим мы перешли к протоколу РОРЗ. Мы увидели, как Exchange использует РОРЗ, когда необходимо взаимодействие с другими почтовыми системами Интернета. Затем было рассмотрено взаимодействие серверов Exchange друг с другом и показано использование RPC. В следующей главе В следующей главе мы начинаем изучать инструменты сетевого мониторин- мониторинга. Мы рассмотрим семейство мониторов компании Microsoft, начиная с облегченной версии, включенной в Windows NT 4.0 и Windows 2000. Затем мы постепенно перейдем к полнофункциональным продуктам, поставляе- поставляемым вместе с SMS 1.2 и 2.0. Мы обсудим несколько вопросов безопасности и способы автоматизации сбора трассировок сетевого монитора.
л v_ . и.. ЧАСТЬ III Сетевые мониторы: инструментальные средства работы Существует множество инструментальных средств работы, предо- предоставляющих некоторые низкоуровневые подробности, необходимые для выполнения сетевого мониторинга и анализа. Компания Microsoft выпус- выпустила несколько хороших программ, которые поставляются с серверными продуктами, а также более надежные инструменты, поставляемые вместе с продуктом Systems Management Server (SMS).
Глава 9 Семейство сетевых мониторов компании Microsoft В настоящее время существует несколько различных сетевых мониторов, поставляемых компанией Microsoft. Все они называются просто сетевыми мониторами. В этой главе будут рассмотрены эти продукты и показано, как установить, сконфигурировать и получить максимум возможного из этих мощных инструментов. В умелых руках сетевой монитор может предоста- предоставить много различной информации. Сетевой монитор < > " Раньше при возникновении проблемы с сетью, часто приходилось гадать, что же вызвало неполадки. Позже появились специализированные устройст- устройства, которые были дорогими, трудными для управления и понимания. Теперь имеется сетевой монитор, который является программным инструментом анализа компании Microsoft. Существуют две версии этой программы: сокра- сокращенная, поставляемая с серверными операционными системами, и полная, которая поставляется с сервером управления системами. Microsoft Network Monitor Lite способен перехватывать трафик, предназначенный только для машины, выполняющей программу. Полная версия переводит сетевой адаптер в "режим, не делающий различия" — т.е. он перехватывает трафик, направленный на компьютер, выполняющий Microsoft Nerwork Monitor, а также трафик, предназначенный для других устройств. Network Monitor 2.0 поставляется вместе с Windows 2000 в версии Lite, a полная версия поставляется вместе с Windows NT 4.0 и SMS 2.0. Network Monitor 1.2. поставляется вместе с Windows NT 4.0 и SMS 1.2. В действите- действительности существует лишь Небольшое различие между версиями продукта 2.0 и 1.2, так как функционально они одинаковы. Мы укажем различия, но большая часть рассматриваемого материала применима к любой версии продукта.
234 Глава 9 Л ГГ Microsoft Network Monitor копирует кадры в буфер перехвата, который является областью памяти с изменяемым размером. По умолчанию этот бу- буфер перехвата равен одному мегабайту, но это легко изменить. Однако в связи с этим зависимым от памяти буфером перехвата сетевой монитор мо- может перехватить лишь столько информации, сколько может поместиться в доступной памяти. Когда буфер будет заполнен, он начнет отбрасывать па- пакеты, и поэтому можно пропустить разыскиваемую информацию. Кроме того, сетевой монитор имеет склонность блокировать и связывать боль- большую часть ресурсов процессора, когда ему разрешается выполняться в те- течение продолжительных периодов после полного заполнения буфера. К счастью, легко прекратить его работу с помощью Task Manager, но тогда те- теряется весь перехваченный файл. Мы узнаем некоторые приемы решения этой проблемы при рассмотрении необслуживаемого мониторинга сети. Потеря файла обычно не является проблемой, так как можно выбрать, какую часть кадра необходимо увидеть, создавая фильтр перехвата. Фильтр перехвата (который в определенном смысле похож на запрос к базе данных) позволяет перехватывать только определенные адреса или типы кадров. Мы поговорим об этом в разделе о перехвате данных. Так как Microsoft Nerwork Monitor легкодоступный, очень мощный инст- инструмент, способный перехватывать данные из сети, необходимо позаботи- позаботиться о системе безопасности. Как мы видели в других главах, обладая определенными навыками, из сети можно получить очень важную инфор- информацию. Microsoft Nerwork Monitor может быть прекрасным инструментом для поиска неисправностей, но также может представлять существенную опасность, оказавшись в недобросовестных руках. Есть несколько способов защиты сети от неавторизованного использования этого инструмента. Мы^ поговорим об этом позже, в разделе о безопасности сетевого монитора. « Microsoft Network Monitor не устанавливается по умолчанию. Чтобы установить его, перейдите к вкладке служб сетевого апплета в панели управления и выберите добавить (add) инструменты сетевого монитора и агент. (ПРИМЕЧАНИЕ. Не забудьте выбрать инструменты сетевого мони- монитора и агента, а не просто агента сетевого монитора, который представлен в списке ниже и не включает программу Microsoft Network Monitor.) Уста- Установка версий SMS использует отдельную программу Setup.exe, находящую- находящуюся в каталоге NMEXR на сайте издательства "ЛОРИ" (www.lory-press.ru). Создание перехвата Когда данные перехватываются, карта Ethernet передает часть кадров, ко- которые она видит в сети, в буфер перехвата. Если буфер перехвата перепол- переполняется, то для определения того, что удерживается в памяти, будет использоваться принцип простой очереди, или FIFO (первый вошел, пер- первый вышел). Чтобы избежать переполнения буфера перехвата, можно из- изменить настройки буфера, выбирая их из меню перехвата. Появится диалоговое окно, позволяющее определить новый буфер перехвата в мега- мегабайтах. Здесь можно также определить, будет ли перехватываться весь кадр, или некоторое число байтов кадра, позволяя сохранить только информацию заголовка.
Семейство сетевых мониторов компании Microsoft 235 Другим способом сократить объем выбранных данных является создание фильтра перехвата для уточнения того, что именно плата передает в буфер перехвата. Начните свой сеанс перехвата, выбрав start в меню перехвата (или нажав кнопку Record). Как показано на рис. 9.1, сетевой монитор выво- выводит статистические данные о сеансе перехвата во время выполнения. Эти статистические данные дают представление о сетевой производительности в данный момент. Важно помнить, что это мгновенный снимок, и хотя он может дать некоторое представление о сети, его нельзя использовать в каче- качестве инструмента планирования. Если, однако, задокументировать эти запи- записи, развернуть их во времени и сравнить с информацией из управляемых концентраторов, коммутаторов, и маршрутизаторов, можно получить лучшее представление о сетевой производительности. Графическая панель (верхняя левая на рис. 9.1) показывает текущее со- состояние сети. Эти панели имеют изменяемый размер, позволяя лучше представить данные. Это полезное свойством при мониторинге процесса перехвата. Это высокоуровневое представление может помочь при поиске неисправностей, предоставляя перечисленную ниже информацию. < • Процент загруженности сети • Число кадров в секунду ... .-.-.-,¦¦.¦. ч > . . . , ,( ,., . Nolwoifc Moniloi |\?lhi4fMM\NEl?(.'jp!u«fWirv<l.iw(Sl.ihnnSljWII Capfcie look Qpbonj tfndow Ц<*> * Network Ulfeaten: 0 Fume» Ри Second 0 B/« P« Second 0 Broadcast» F« Second 0 MJhcettPa Second i 0 0 0 0 100 100 4125 100 NehmkAotttttl TERESA PROX ED1750 EDI 750 biguy 2400 2400 !•¦>? 2 1 3 9 31 2 91 1<-2 25 133 NetvwkAddn •BROADCAST USC 000118 ¦BROADCAST PROX PROX ¦BROADCAST PROX / TimEUpscd 000104733 Networic Statistics «Fram,.. 388 I! Bioadcasts 7 IS M<Ac«lt 32 «ByUs 62-893 В Framer Oiopced: 0 t. Nona! Cultured SlaMid Kfimn 338 И Fc&Tie: Diopped 0 P«i Second SMtHtcs .'i Netwoik Ullt«c.i 0 К Fiamet/trcond 0 В 8/et/t«ond 0 & Bioadcasts/second 0 ' УУ\ Netoofc Adienl Frames SentlFu usc'"booif8"|d" " ¦"¦"'|i TERESA «Rcvd ByUsSent 0 335 S>4es RcvdlDiected Fia 57 0 a lo Muticasls Sent 0 0 Broadcasts Sent 0 2 Рис. 9.1. Текущее представление о состоянии сети можно получить из статистических данных сеанса в окне перехвата сетевого монитора
236 Глава 9 • Число байтов в секунду ; ,-.,. .¦> ., ¦ -',-. ¦< • н-., . ;. ' • Число широковещательных сообщений в секунду ' ;?ф • Число мультивещательных сообщений в секунду Панель общей статистики (верхняя правая панель на рис. 9.1) показыва- показывает числовой итог информации, содержащейся в графической панели. По- Появляется также статистика относительно перехваченных данных. Панель сообщает, сколько кадров находится в буфере, какая доля буфера использо- использована, были или нет какие-либо кадры отброшены в связи с переполнением буфера. Дополнительная статистика предоставляет информацию о сетевой плате. Панель статистики сеанса (ниже графической панели) перечисляет се- сетевые адреса компьютеров, общающихся во время текущего сеанса перехва- перехвата. Она показывает, сколько кадров находится в сети и в каком направлении они движутся. Обратите особое внимание на стрелку, так как она использу- используется в сетевом мониторе для указания направления потока данных (исполь- (используется также при создании фильтров перехвата). Стрелка всегда указывает в направлении компьютера, который будет получать информацию. Например, на рис. 9.1 bigguy в столбце сетевого адреса 1 посылает 31 кадр в PROX в столбце сетевого адреса 2. PROX посылает 25 кадров назад bigguy. Панель статистики станции (ниже статистики сеанса) более подробно представляет информацию из статистики сеанса, перечисляя число байтов посланных и полученных каждой станцией, представленной в буфере пере- перехвата. Информация о посланных широковещательных и мультивещатель- мультивещательных сообщениях особенно полезна для быстрого выявления потенциальных проблем в сети. Кроме того, может понадобиться исследовать направление потока данных и размеры различных происходящих обменов данными. Все это может оказаться потенциальными узкими местами сети. Перехват трафика вручную ' Пришло время запустить сетевой монитор. Чтобы управлять перехватом вручную, используется меню перехвата (рис. 9.2). Однако прежде чем на- нажать Start, необходимо задать размер буфера. Выбор настроек буфера из меню перехвата позволит сконфигурировать буфер. Используемый по умол- умолчанию максимальный размер буфера перехвата, равный 8 мегабайтам, мень- меньше объема оперативной памяти, установленной на машине. Хотя можно использовать виртуальную память для буфера перехвата, лучше этого не де- делать для гарантии, что критически важная информация кадра надежно пере- перехвачена. Microsoft Network Monitor пошлет предупреждение при попытке ввести размер буфера перехвата больше физической памяти машины. Сооб- Сообщение говорит: "Запрашиваемый размер буфера может вызывать потерю кадров в связи с процессом подкачки. Вы уверены, что хотите разместить буфер этого размера?" Помимо выбора размера буфера можно также выбрать размер кадра, ко- который желательно перехватывать. Например, если интересует только ин- информация заголовка для определенного протокола, то можно задать здесь эту информацию и не тратить пространство на перехват лишних данных
Семейство сетевых мониторов компании Microsoft 237 ¦TJf -О "Captured Data Find All Names Clear Statistics ... Addresses... * Buffer Settings... ''- f Filler... . fretworks... Trigger... ; Dedicated Capture Mode ' Save Configuration fi; FS Рис. 9.2. Режим выделенного перехвата сокращает нагрузку центрального процессора, помогая тем самым избежать потери кадров во время сеанса перехвата кадра. Какой размер кадра перехватывается, зависит от определенного ис- исследуемого протокола. Например, так как мы знаем, что нормальный заго- заголовок Ethernet равен 14 байтам, можно задать кадр перехвата в 14 байтов и перехватывать только заголовки Ethernet. Это позволит нам перехватить 73142 кадра с помощью одномегабайтного буфера перехвата. Можно было бы использовать 34-байтовый кадр для перехвата заголовка IP A4 байтов для заголовка Ethernet и 20 байтов для заголовка IP). Это очень полезно при исследовании проблем передачи файлов, которые часто содержат 1200 или больше байтов данных пользователя, которые могут быстро заполнить буфер перехвата. Обновление окна статистики перехвата, показанного на рис. 9.1, созда- создает для центрального процессора нагрузку, которая может быть излишней. Выбирая режим выделенного (dedicated) перехвата в меню перехвата, мож- можно избежать нагрузки, связанной с обновлением изображения, и тем самым предоставить дополнительные ресурсы для перехвата кадров. Как показано Dedicated Mode on \Etheinet\NET2 Total Frames Captured: 83 Stop and View Pause Normal Mode Рис. 9.З. Меню перехвата позволяет полностью управлять сеансом перехвата. Здесь же задаются настройки буфера
238 Глава 9 на рис. 9.3, в режиме выделенного перехвата имеется возможность пере- переключения в нормальный режим, выбрав его из меню перехвата. Можно сде- сделать все эти переключения во время работы Microsoft Network Monitor и не потерять кадры. Кроме того, можно приостановить Netmon и продолжить работу приложения в этом режиме. Просмотр перехваченных данных Когда сеанс перехвата закончен, что мы имеем? Сетевой монитор упроща- упрощает задачу анализа данных, организуя перехваченные данные в несколько различных представлений и выполняя большую часть анализа протокола. На рис. 9.4 мы видим сводное представление. Оно полезно для получения обзора информации, содержащейся в перехваченных данных. Большое число кадров BPDU на рис. 9.4 являются конфигурационными сообщения- сообщениями коммутатора. 12 97< 13 88С 14 98 15 38С 16 99 19 012 21 021 23 037 25 04 27 06J 29 074 3i os; зз 09; 35 i: 37 12 39 137 41 14< 43 16 44 08С2400 44 08/ 44 08 44 087 44 08! 2400 44 OS! 0090F2B1929 2400 OO9OF2B1929 2400 0090F2B1929 0090F2B1929 0090F2B1929 C090F2B1929 0090F2BH29 C0SOFJ81929 0090F2B1929 0090F2B1929 0090F2B1929 0O9OF2B1929 0090F231929 0090F2B1929 0090F2B1929 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 4L= NBT Donuin Name Sow» protocol lumuv PROX 2400 PROX PROX 44 09C 2400 44 09CPROX 44 09C 2400 45 17< 0O90F2B1929 0090F2B1929 0090F281929 0090F281529 S3 22< 0090F2B1929 55 237 57 24S 0090F2B1929 0090F2B1929 IEEE 00000 PROX IEEE 00000 PROX IEEE 00000 IEEE 00000 IEEE 00000 IEEE 00000 IEEE 00000 IEEE 00000 IEEE 00000 IEEE 0CSO0 IEEE 00000 IEEE 00000 IEEE 00000 IEEE 00000 IEEE 00000 IEEE 00000 PROX •BROADCAST PROX 2400 PROX 2406 PROX 2400 PROX IEEE 00000 00000 IEEE IEEE IEEE IEEE 00000 IEEE 00000 IEEE 00000 BPDU NBT BPDU HBT BPDU BPDU BPDU BPDU BPDU EPDU BPDU BPDU BPDU BPDU BPDU BPDU BPDU BPDU SKB ARP.RAriARP ARP RA4ARP SKB" SXB SKB TCP TCP TCP BPDU BPDU BPDU BPDU BPDU BPDU BPDU Root BPDU Root BPDU Root BPDU. Root BPDU Root BPDU Root BPDU Soot BPDU Root BPDU Root BPDU Root BPDU Root BPDU Root BPDU Root BPDU Port 0x8005. Address Port 0x8005. Address Port 0x8005. Address Port 0x8005. Address OO9OF2V Port 0x8005. Address 0090FV» Port 0x8005. Address 0090р«Л Address 0090Fc^ Address 0090Fi% Address 0090Fi", Address 0090Fi% Address 0090F»-', Address 0090Fo> Address 0090F2>> Port 0x8005 Port 0x8005 Root BPDU Priority 0x8000. MS Refresh req tor KRED Root BPDU Priority 0x8000. NS Refresh req tor HRED Root BPDU Priority 0x8000, Priority 0x8000. Priority 0x8000. Priority 0x8000. Priority 0x8000. Priority 0x8000. Priority 0x8000. Port 0x8005. Priority 0x8000. Por! 0x8005. Priority 0x8000. Port 0x8005. Priority 0x8000. Port 0x8005. Priority 0x8000. Port 0x8005. Priority 0x8000. Port 0x8005. Address 0090FJ>> Priority 0x8000. Port 0x8005. Address 0090F?> Priority 0x8000. Port 0x8005. Address " С tree disconnect Request. Target IP 10 0.0 60 Reply. Target IP 10 0 0 10 Target Hdvr Addr R tree disconnect С logoff i X S logoff 4 X A F. len 0. soq 16643231-16643231. ack A F. len 0. seq 139748-139748. ack 166432| A . len 0. seq 16643232-16643232. ack Root BPDU Priority 0x8000. Port 0x8005. Address 0090F*, Port 0x8005. Port 0x8005 Port 0x8005. Port 0x8005. Port 0x8005. Port 0x8005. 009CV 432i-$ Root BPDU Root BPDU Root BPDU Root BPDU Root BPDU Root BPDU Priority 0x8000. Priority 0x8000. Priority 0x8000. Priority 0x8000. Priority 0x8000. Priority 0x8000. Address . Address 0090FiJ Address 0090FJ4 Address 0090FS-*» Address 0090Fii Address 0090F*> . -¦¦ ¦-¦ >Ы IF»: 1/320 Рис. 9.4. Сводное представление сетевого монитора позволяет быстро определить аномалии в перехваченных данных - Добавляя подробное и шестнадцатеричное представления из меню Window, можно найти такую информацию, как адрес источника и адрес места назначения кадра. На рис. 9.5 мы видим источник и место назначе- назначения трафика BPDU, который поглощает большую часть полосы пропуска- пропускания сети. Вооружившись этой информацией, можно перейти к машине и
Семейство сетевых мониторов компании Microsoft 239 провести небольшое расследование, почему машина заполняет сеть бес- бесполезной информацией. Это представление дает также данные о протоко- протоколах, которые нужны для изменения настроек буфера, если пользователя интересует какой-то определенный аспект. .. . .,., Netemfc MoralOf • (Слр(ше:7 (Detail) «Ф ?* ?* Hdp Frame 13 14 15 16 17 И Tine 12 13 14 15 16 97" 88C 981 38( 995 Src KAC Add 0090F2B1929 2400 0090F2B1929 2400 0090F2B1929 t Dst IEfCfc PROJ IEEE PROJ KAC Add 00000 00000 00000 Protocc BPDU HBT BPDU КВТ BPDU Description Root HS Root NS Root BPDU Priority Refresh req for BPDU: Priority Refresh req for BPDU' Priority 0x8000. KRED 3x8000. HREP 3x8000 Port Port Port 0x9005. < 1E> 0x8005 < 1?> 0x8005 Address Address Address ) 0Q90F:- 0090F>r 0G90F; 18 19 0i;0090F2B1929 IEEE 00000 BPDU Root BPDU Priority 0x8000 Port 0x8005 Address 0090F HERHET 802.3 Lenqth ¦ 72 ¦ETHERHET Destination address 0180C2000000 ¦ETHERHET Source address 0090F2B1929D ETHERHET Frame Length 72 @x0048) ETHERHET Data Length 0x002E D6) ETHERHET Ethernet Data Hu&ber of data bytes remaining ¦ОС: 0Т DSAP-0x42 SSAP-0»42 С -BPDU: Root BPDU Priority 0x8000 Port 0x8005. Add: BPDO: Protocol ID ¦ 0 @x0) Version ¦ 0 @x0) Message Type * Configuration Flags • 0 @x0) Root ID Priority • 32768 @x8000) !i Root ID • 0090F2B1929S Cost - 0 @x0) . Bridge ID Priority ¦ 32768 @x8000) Bridge ID - 0090F2B1929S ¦il BPDO: BPDU: «BPDU: BPDU: BPDU: BPDU BPDU BPDU: 58 @x0031) 0090F2B19295. Cost 0x0 i.H /,'-\;.i i;. м- J 00000010 03 00 00 00 00 00 80 00 00 90 F2 Bl 92 95 00 00 00000020 00 00 80 00 00 90 F2 Bl 92 9S 80 OS 00 00 14 00 00000030 02 00 OF 00 00 00 00 00 00 00 00 00 00 00 00 00 00000040 00 00 00 00 00 00 00 00 ' f. • ^ _. .. ._;. ¦ • ¦ С - - Е-1 J F«: 1ЭЛ20 Рис. 9.5. Подробное и шестнадцатеричное представления сетевого монитора позволяют найти источник и адреса места назначения машины, посылающей информацию по сети Сохранение перехваченных данных После перехвата данных из сети желательно сохранить их в качестве опор- опорной информации при проведении некоторых сетевых настроек или для предоставления основы для долгосрочного анализа. В любом случае он бу- будет сохранен как файл .cap, который можно открыть в сетевом мониторе в любое время. Кроме того, не забудьте сохранить данные в файле, прежде чем начинать другой сеанс перехвата, иначе можно потерять перехвачен- перехваченные данные. Для сохранения перехваченных данных следует выбрать команду Save из меню File. Имеется возможность выбрать место расположения, а также диапазон кадров, которые желательно сохранить. По умолчанию будут сохранены все перехваченные кадры. Можно также выбрать сохранение отфильтро- отфильтрованных перехваченных данных. Например, если сконфигурировать фильтр показа (который мы рассмотрим в следующем разделе), можно
240 Глава 9 сохранить данные только из текущего вывода на экран. Это позволяет модифицировать файл .cap. Можно также создать несколько файлов .cap из одного большого перехвата данных, что позволяет сохранить только интересующие данные. . ...... .... ... ... ,s,,, v . . ч, , , . ,.,. Фильтрация данных перехвата В сетевом мониторе используются два вида фильтров. Первым является фильтр перехвата, а вторым — фильтр вывода. Оба они работают аналогич- аналогичным образом. Фильтр работает в некотором смысле как запрос, применяю- применяющийся к базе данных. Он позволяет выбрать часть или подмножество доступных данных. Например, если удалось сузить проблему до определенно- определенного компьютера, то можно отфильтровать весь остальной трафик и сосредото- сосредоточиться только на этом компьютере. Еще одним свойством является возможность сохранить фильтры и использовать их позже (несколько полез- полезных фильтров находится на сайте издательства "ЛОРИ" (www.loiy-press.ru). Это пригодится при попытке исправить определенную проблему. Можно со- сохранить множество данных, а после выполнения изменений фильтр выполня- выполняется снова, позволяя тем самым проследить за произошедшими изменениями. Фильтр перехвата Чтобы создать фильтр перехвата, из меню надо вы- выбрать пункт filter. Как показано на рис. 9.6, можно фильтровать данные по протоколу, по адресу или по образцу данных (или по комбинации всех трех). Capture Filter ~SAP/ETYPE = TC (Address Pats) INCLUDE "ANY <¦¦> "ANY (Pattern Matches] »**«¦':•;. Cancel Help Load... Save... Рис. 9.6. Функции фильтра перехвата похожи на запрос базы данных тем, что позволяют определить подмножество данных для анализа
Семейство сетевых мониторов компании Microsoft 241 Если желательно фильтровать по протоколу, необходимо выбрать стро- строку SAP/ETYPE и нажать кнопку Edit line. Появится меню, позволяющее вы- выбрать тип протокола, который желательно отфильтровать. Чтобы выбрать один определенный протокол, проще всего отключить все протоколы и за- затем включить один протокол, который желательно проверить. Хотя диало- диалоговые окна довольно неудобны для использования, можно быстро перейти к разделу, щелкая по именованному заголовку и вводя затем первую букву требуемого протокола или адреса. Это немного лучше, чем прокручивать длинный список адресов. Если вас интересует только одна машина, выберите адресные пары и снова нажмите кнопку Edit line (или просто сделайте двойной щелчок по выражению). Этот фильтр работает одинаково в режиме перехвата и режи- режиме вывода и является отличным инструментом, используемым при анализе общения между серверами и рабочими станциями или между принтерами. Фильтр перехвата на совпадении с образцом немного сложнее для испо- использования, так как он требует определенных знаний о месте кадра, где мо- может появиться определенный образец. Для поиска этой информации используется анализ существующей перехваченной информации в шестнад- цатеричной панели. Когда будет найден шаблон для определенного приме- примера, создайте фильтр перехвата и протестируйте его для проверки, что он делает то, что нужно. Мы рассмотрим это при анализе шестнадцатеричной панели. Фильтр вывода данных Фильтр вывода данных работает почти так же, как и фильтр перехвата, но действует на уже перехваченных данных. Он не изменяет содержимое буфера перехвата. С помощью фильтра выво- вывода данных можно выбрать определенный протокол, адрес или свойство I .xpression E '1 Expression ED1750 |ETHERNET)<-->'ANY I Addiess ] Piotocd ] Property j Station X Ejection j Name lAddiess 1 1 ШЗЕШ CINPROXY 00104BSJ -> ED175O 10.0 0 7Г EDI 750 0060378BI HW KM DB HW KM DB JWH1364 JWH1364 JWH1364 JWH1364 3001.08LJ 08003E0 00600SA з.оооас; 3001.006 0008C78 il._J lid j "OK } Cancel ] Help ) Station 2 Name ¦ANY -BROADCAST ¦NETBIOS Multicast 2400 2400 bigguy 8IGGUY CINPROXf CINPR0W 4 I Addtess J J FFFFFFF—j 0300000—' 10.0.0.6C 0090276 0090278 10.0.0.61 216.23.7 00104B6 E_*Addiestes... J Рис. 9.7. Фильтрация адресов упрощает поиск неисправностей с помощью сетевого монитора
242 i: Глава 9 данных, чтобы помочь отсортировать данные. Выборка делается таким же образом, как и при создании фильтра перехвата. Однако существует одно важное различие: можно применять также логические операции AND, OR или NOT. Эта возможность предоставляет больший диапазон выбора при создании фильтра, чем это доступно в режиме фильтра перехвата. Как по- показано на рис. 9.7, появляется меню, позволяющее выбрать адрес, который желательно проверить. Существует возможность включить или исключить адрес. Можно также выбрать направление потока информации. Выберите имя для станции 1 в левом столбце, стрелку направления (помните, что вершина стрелки указывает направление потока данных), а затем выберите получателя в столбце станции 2. Например,, на рис. 9.7 фильтр включает трафик данных из ED1750 во все станции сети, а также трафик из любой станции сети в ED1750. Это полезно при анализе образцов трафика сервера. Анализ перехваченных данных Когда данные перехвачены и применен фильтр вывода данных, наступает время анализировать кадры. Верхняя панель является итоговой панелью, которая содержит информацию перечисленную ниже. Эти столбцы можно переупорядочить, нажимая заголовок столбца и перетаскивая в новое желаемое положение. '"" ' " "' ; - ~.- • ¦;•¦•• • ¦ • Номер кадра. Microsoft Network Monitor присваивает кадру номер для целей учета. Он в реальности не появляется в самом кадре, но добавляется программой, чтобы упростить ссылку на информацию, находящуюся в перехваченных данных. • Время. Время, также присваиваемое Microsoft Network Monitor, позво- позволяет узнать, сколько времени проходит между кадрами. Это предостав- предоставляет полезную информацию при выполнении анализа сетевой производительности. Время, которое выводится в этом столбце, кон- конфигурируется в параметрах меню Display. Существуют три возможно- возможности: время дня, секунды с начала перехвата и секунды от прохождения предыдущего кадра. Выбирая время дня, можно сопоставить инфор- информацию из журнала событий Windows с информацией, перехваченной Microsoft Network Monitor. Такое сопоставление допустимо для мощного поиска неисправностей при появлении ошибочных сообщений. • Адрес MAC источника. Это устройство, которое прежде всего создает кадр. Есть три возможности для вывода адреса MAC, задаваемые из меню Options. Можно выбрать вывод имени, которое присвоено адре- адресу MAC в адресной книге Microsoft Network Monitor; можно выбрать вывод просто адреса MAC (поведение по умолчанию); или можно вы- выбрать вывод имени поставщика, связанного с первыми шестью байта- байтами адреса MAC. Это бывает полезно при попытке найти неизвестное устройство в сети. • Адрес MAC места назначения. Это аппаратный адрес места назначения пакета. • Протокол. Это основной протокол кадра.
Семейство сетевых мониторов компании Microsoft - 243 • Описание. Это поле предоставляет суммарную информацию о кад- кадре. Описание также конфигурируемо с помощью параметров меню Display. Существует две возможности: последний протокол в кадре ¦:'~"'%Sr- или автоматический выбор на основе используемого фильтра вывода. Часто можно собрать достаточно информации из сводки, чтобы полу- получить представление о том, что происходит в сеансе перехвата. Трех- Трехходовое квитирование TCP легко обнаружить по описанию. Здесь часто показывается информация о флагах TCP. • Другой адрес источника. Чтобы увидеть это поле, следует переместить ползунок в нижней части итоговой панели. Другой адрес источника является адресом другого протокола, содержащимся в кадре. • Другой адрес места назначения. Это адрес другого протокола, содер- содержащийся в кадре. w • Тип другого адреса. Этот адрес сообщает, какой протокол содержат поля другого адреса. Детализированная панель находится в середине. Здесь происходит бо- большая часть анализа. Microsoft Network Monitor использует файлы .dll и файлы .ini для синтаксического разбора протокола. Существуют, напри- например, файлы TCP.dll и TCP.ini, хранящиеся в каталоге синтаксического раз- разбора Microsoft Network Monitor. Чтобы правильно проанализировать протоколы, которые Microsoft Network Monitor не понимает, необходим анализатор .dll и файл .ini. Можно написать их самостоятельно или получить их от независимых поставщиков. Шестнадцатеричная панель находится в нижней части и содержит спе- специальную информацию об анализируемом кадре. Например, рассматривая трассировки протокола РОРЗ, мы замечаем, что вся информация находит- находится в шестнадцатеричной трассировке, а не в детализированной панели. Знание того, как читать шестнадцатеричную трассировку, поможет создать специальные фильтры перехвата (см. рис. 9.8). На рис. 9.8 изображен транспортный кадр NetBIOS, который перено- переносится поверх TCP, IP и протокола Ethernet. Этот конкретный кадр являет- является дежурным кадром сеанса. Если требуется создать фильтр перехвата, который перехватывает только дежурные кадры сеанса NetBIOS (возмож- (возможно, для анализа влияния дежурного трафика NetBIOS на сеть), нам понадо- понадобится использовать смещение образца. Мы расширяем раздел NBT трассировки, щелкая на знаке плюс рядом с итоговой строкой NBT. Затем выбираем строку NBT: packet type. Отметим, что соответствующий раздел шестнадцатеричной трассировки автоматически подсвечивается, когда мы выбираем различные строки в детализированной панели. Когда мы вы- выбираем packet type = session keep alive, подсвечивается шестнадцатеричное число 85 в строке 30. Теперь мы можем отсчитывать, пока не увидим, что шестнадцатеричное число 85 находится в смещенной позиции шестнадца- теричного 36 с начала кадра. Вместо отсчета можно посмотреть в нижний правый угол экрана Microsoft Network Monitor. Там мы видим, что это сме- смещение 54 (десятичное) хЗб (шестнадцатеричное). Эту информацию можно ввести в шаблон совпадения фильтра перехвата, как показано на рис. 9.9.
244 Глава 9 Netmxfc Momto. - ICafrfina:7 IDeladll 5? Et E« ЕирЦ> lodt Qpteni Help Frame Time Src MAC Add Dst MAC AddlProtocdDescription 59 08«b: S9 26; 61 63 287 6S 16S >iggu у 0090F2B1929 2?< 0090F2B1929 0090F281929 biggu у Я1ЛЯТ PROX IEEE IEEE IEEE PROX 00000 00000 00000 TCP BPDU BPDU BPDU UDP SS Session KeeD Alive Len A A . len 0. seq 389B98092-389898092. ack 1Г"" Root BPDU Priority 0x8000. Port 0x8005. Address 0090Г; Root BPDU: Priority 0*8000. Port 0x800S. Address 0090Ff" Root BPDU Priority 0x8000. Port 0x8005. Address 0090F« Src Port Dnknovn. CS42); Dst Port. Unknown A45). I' TCP. Reserved - 0 @x0000) -TCP Flags ¦ 0x18 AP TCP .0 TCP 1 TCP: .. .1 TCP: 0 TCP TCP TCP Windov • 7650 @xlDE2) TCP Checksum • 0x5 IDA TCP Urgent Pointer • 0 @x0) TCP Data Number of data bytes remaining ¦ 4 @x0004) —HBT SS: Session Keep Alive. Len. 0 Ho urgent data Acknowledgement field significant Push {unction Ho Reset Ho Synchronize No Fi -HBT Packet Flags • 0 @x0) КВТ 0 • Add 0 to Length HBT Packet length • 0 @x0) 00000000 00 90 27 84 SB 1A' 00" 90 27 ~64" FA D6 9 o"5 00 00000010 00 2C AD 29 40 00 80 06 39 5C 0A 00 00 0A 0A 00 00000020 00 3D 00 8B OD FF 00 02 21 90 17 3D 5F 6C 50 18 00000030 ID E2 51 DA 00 00 ЁЁЯОО 00 00 ¦*Fsr"FdT~r ..!>¦ С 9\ .... -,i IE.- IP. J iLL IPtckatTyp. Рис. 9.8. Фильтрация адресов упрощает поиск неисправностей с помощью сетевого монитора . , Дополнительные 00, добавленные после 85, являются тем, что следует в шестнадцатеричной трассировке и сокращает число ложных совпадений. Возможная фильтрация по двум или трем числам обеспечивает более тон- тонкое управление процессом перехвата данных. Модификация вывода Существует пара настроек, которая облегчает изучение трассировок Microsoft Network Monitor. Первой является настрой- настройка текста вывода, который задается выбором шрифта из меню Display. Более функциональным изменением является присваивание определенным прото- протоколам специальных цветов. Можно например, присвоить красный цвет TCP, зеленый Browser, а желтый для трафика NetLogon. Это значительно облегча- облегчает трассировку определенных взаимодействий в перехваченных данных с большим числом кадров. Можно выбирать цвет переднего плана, который изменяет только цвет шрифта, или цвет фона, или и то и другое. Другим свойством Microsoft Network Monitor является дублирование, ко- которое выбирается из меню Window. При этом перехваченная информация копируется в другое окно, позволяя работать с обоими окнами, как если бы они были различными перехватами информации. Можно использовать различные фильтры вывода и сравнивать два представления одной и той же перехваченной информации. Чтобы помочь в отслеживании этого про- процесса, можно добавить также в том же меню в окно метку. Это позволит
Семейство сетевых мониторов компании Microsoft 245 ¦ Pattern Match i Offset (in hex) [36 ' <•" From Start of Frame ; С From End of Topology' Header j Pattern 8500 ' 1 (? Hex Г ASCII ' OK Cancel Help Рис. 9.9. Фильтр перехвата по совпадению образца требует образец и смещение избежать путаницы, связанной с работой с двумя представлениями с одним и тем же именем. При работе с дубликатом можно закрыть одно окно, не влияя на содержимое другого окна. Когда настройки будут сконфигури- сконфигурированы желательным образом, можно сохранить их, выбирая Save configuration из меню Display. Выбирая пункт Insert comment frame из меню Tools, можно добавить ин- информацию в файл .cap, чтобы помочь интерпретировать данные в другое время или с целью тренировки. Можно вставить два различных вида кадров: кадр закладки и кадр комментария. Данные будут появляться в трассировке как кадр комментария или закладки, и это позволит ввести сообщение, кото- которое будет храниться в кадре (см. рис. 9.10). Можно также выбрать коммента- комментарий или закладку из списка протоколов при создании фильтра вывода. Это полезно для обильно документированных кадров .cap, а затем можно будет распечатать результаты. При добавлении комментариев в файл .cap не стоит включать их статистические вычисления, так как это будет портить показа- показатели о том, сколько кадров передано во время периода перехвата. Если ана- анализируется не этот аспект трафика, то не имеет значения, включен ли кадр комментария в статистику перехвата. Можно передать также кадр комментария по действующей сети, чтобы помочь в поиске определенных кадров, когда себя проявляют некоторые сетевые проблемы. Это включает использование полной версии Microsoft Network Monitor и выполнение его в двух экземплярах, чтобы оба передава- передавали и получали одновременно. При использовании закладки можно собрать вместе некоторый массив информации в конечном разделе кадра закладки, как показано в детализированной панели на рис. 9.10. Система безопасности сетевого монитора При тех мощных возможностях, которые заложены в сетевом мониторе, очень важно принять соответствующие меры безопасности для защиты сети от неправильного использования этого инструмента. Компания Microsoft уже реализовала одно свойство безопасности в серверных продуктах,
246 Глава 9 iai [bi bi I+Th raei wKh.i i ? I frame Til Src НАС Add Pst MAC Add! Description iptio вршГ Root BPDU: Priority 0x8000. Port 0x8005. Address 009Ш»| NS Registration req ior PR0X*-m-*-m-+++<-+* N3 Registration req ior PROX-м- hhiiimi I Root BPDU: Priority 0x8000. Port 0x8005. Address """"¦^-J 1.902 1 936 2 687 3 915 0090F2B1929 PROX PROX 0090F2B1929 IEEE 00000 •BROADCAST BROADCAST IEEE 00000 BPDU NBT HBT BPDU 0 000 4C4F4ES44F5 4E4SS457S24 COKMEHTldfg «FRAME Base frame properties ¦ETHERNET ETYPE - 0x1984 Protocol • Unknown -TRAIL FRAME TYPE ¦ BookMark TRAIL Trail ID ¦ SMST TRAIL: TRAIL TRAIL -TRAIL Special Frame Type Block Statistics Use this Frame as a Statistics Endpoint Sho» Statistics (or all Fraiies. even it Filtered TRAIL Frames in Kill Tot«l TRAIL TRAIL: TRAIL: TRAIL: TRAIL- TRAIL TRAIL -TRAIL. TRAIL TRAIL AverageSiz< Minimum Si Maximum Si Total Time Average Ti Minimum Ti Maximum Ti Hock • 7 CMSE ¦ 88 i ¦ 72 1-110 - ','. • ' 6900 ll ' л Betveen Frames - 11S0 0 л Betveen Frames - 125 ie Batveen Fra»es > 2013 Bytes Per Second ¦ 89 BandVidth consumed tor 10 Kega Bits Per Second ¦ BandVidth consumed for 100 Mega Bits Per Second ' 0 0У. 0 OX 00000000 <E 45 54 57 52 4B 4D 4F 4E S4 4F 52 19 84 24 4D KETWRKMONTOR aSM 00000010 53 54 00 00 00 00 Ы 00 00 00 62 6F 6F 6B 6D 61 ST f bookma 00000020 72 6B 00 rk 1 .:. ^ — fl iT*i(8»<ef<»aii*imeir»eec»i * if*W17 0!r 0[xOJ LOW) Рис. 9.10. Кадр комментария предоставляет место для записи примечаний, которые остаются в файле перехвата которое состоит в том, что сетевой монитор будет контролировать трафик только между сервером, на котором он выполняется, и остальной сетью. Это защитит вас от некорректного использования. Однако версия, которая поставляется вместе с Systems Management Server (SMS), способна перехва- перехватывать кадры, посланные на компьютер или из любого компьютера в сети, а также перехватывать кадры в удаленной сети. Защита с помощью пароля Для сетевого монитора можно задать два пароля с помощью пиктограммы агента мониторинга в панели управления; это пароль вывода и пароль пе- перехвата, показанные на рис. 9.11. Пароль вывода разрешает доступ к сохра- сохраненному файлу перехвата (.cap). С помощью этого пароля разрешается только открыть сохраненный ранее файл перехвата. Он не разрешает пе- перехватывать новые данные. Это применимо только к Microsoft Network Monitor, установленному на машине, на которой пароль был задан. Он так- также не защищает файл .cap от просмотра в сети с помощью другого Microsoft Network Monitor. Другими словами, это защита с помощью пароля установ- установки программы и связанного с ней агента — а не данных.
Семейство сетевых мониторов компании Microsoft 247 Network Monitoring Password Change You can control access to Network Monitor with two types ot passwords. The Display password will restrict a user to viewing only previously saved capture files The Capture password allows the user to capture data, as well as to view capture files. Old Capture Password Password: Display Password Password: Confirm: | - Capture Password Password I Confirm: | Enter the old capture password for validation. This password will only grant permission to view previously saved capture files. This password will grant permission to capture frames and to view capture files. OK J Cancel j No Password Help Рис. 9.11. Апплет агента сетевого монитора в панели управления предоставляет базовую безопасность для сетевого монитора Пароль перехвата разрешает неограниченный доступ к сетевому мони- монитору. С помощью этого пароля можно открывать сохраненные файлы пере- перехвата, а также создавать новые перехваты данных. Пароль запрашивается при каждом запуске Microsoft Network Monitor. Если ввести пароль перехва- перехвата, то имеется полный доступ ко всем свойствам; если ввести пароль вывода, то можно выводить только файлы .cap. Важно задавать эти пароли на удаленных рабочих станциях и серверах, на которых установлен агент. Если служба выполняется без защиты паролем, то любой человек с версией SMS сетевого монитора может соединиться с ва- вашим сервером и использовать его для перехвата данных из сети. Эти пароли должны быть защищены, поскольку не существует способа восстановить их иначе, как удалить и снова выполнить установку Microsoft Network Monitor и связанных с ним агентов. Удаление ключа защиты в службе ВН в реестре не работает для восстановления при потерянном пароле. Установка сетевого монитора: обнаружение других мониторов , Чтобы защитить свою сеть от неавторизованного просмотра, сетевой мони- монитор может легко определить другие экземпляры программы в сети. Он может сделать это независимо от того, работает или нет программа. Как показано на рис. 9.12, если драйвер установлен на машине, он будет сообщать имя
Other Netwoik Monrtoi Installations Total Installed: 4 Total Running 2 Total Capturing 1 Machine Name jUsei Name jCuiient State hgguy PR OX TERESA kitchen pfcx MiED ¦(Сарйш.. Driver is installed Running Running Adaptei Addiess IVeuion ШМШШ Tl.XII 00902734881A 003CI2764FAD6 00&05F0FC84A J •&!¦ Г Add Names to Addtess Database ~0K I Help | Re.ieshList .11 У Рис. 9.12. Инструмент обнаружения установок сетевых мониторов позволяет управлять использованием Microsoft Network Monitor машины, имя зарегистрированного на компьютере пользователя, ад- адрес Ethernet машины, номер версии программы и перехватывает ли про- программа данные, или просто установлена. Чтобы получить эту информацию, необходимо выбрать в меню Tools пункт Identify network monitor users (Идентифицировать пользователей сетевого монитора). Важно отметить, что если имеются сетевые сегменты, разделенные маршрутизатором, кото- который не пересылает мультивещательные сообщения, то невозможно будет определить установки сетевого монитора в другом сегменте, не соединив- соединившись с этим сегментом. Это связано с тем, что Netmon использует суффикс NetBIOS для объявления о своем присутствии в сети. Суффикс BE объявля- объявляет агента сетевого монитора, а суффикс BF объявляет в сети само приложе- приложение сетевого монитора. Если они не пересылаются, то необходимо будет соединиться с определенным сегментом, чтобы определить незаконные установки этих инструментов. После выбора пункта меню "Определить пользователей сетевого мони- монитора" машина Netmon посылает запрос станции BONE, как показано в сле- следующей распечатке. Протокол BONE (сокращение от Bloodhound Oriented Network Entity, что может быть приблизительно переведено как "Сетевая ищейка") используется сетевым монитором, чтобы он мог общаться. Этот запрос станции является очень маленьким кадром многоадресной рассыл- рассылки 802.3, который использует только 29 байтов. BONE: Station Query Request С @x00) BONE: Signature = RTSS BONE: Command = Station Query Request С @x00)
Семейство сетевых мониторов компании Microsoft 249 BONE: Flags = 0x00 BONE: Bone Data: Number of data bytes remaining = 0 | @x0000) Ответ направляется в машину, которая послала запрос, и является мале- маленьким кадром 802.3, в этот раз требующим около 125 байтов. Ответ сообща- сообщает статус драйвера; 0x00000003 означает, что драйвер установлен и активен, но не перехватывает данные. Он содержит версию драйвера, ма- машину, адрес MAC машины и имя любого пользователя, которое было скон- сконфигурировано при конфигурировании драйвера. ¦-..'.. BONE: Station Query Response R @x01) ¦ •• ¦ - • ¦' BONE: Signature = RTSS BONE: Command = Station Query Response R @x01) BONE: Flags = 0x00 BONE: REsponse Data Length = 96 @x0060) . BONE: Station Query Flags = 0x000000003 ' . ', , BONE: Station Query Version 1.01 BONE: Station Query License Number = 0x00000000 BONE: Station Query Machine Name = TERESA BONE: Station Query User Name = MrED BONE: Station Query Node Address = 00805F0FC84A BONE: Bone Data: Number of data bytes remaining = 0 @x0000) ,,,, _,. . ,;. . ; ¦.-*-. , • - r Сетевой монитор Systems Management Server 1.2 Сетевой монитор, который поставляется вместе с SMS 1.2 (v4.00.351), рабо- работает в основном так же, как сетевой монитор из NT 4.O. Однако есть неско- несколько дополнительных свойств, которые делают его значительно более полезным инструментом для перегруженных сетевых администраторов. Дополнительные свойства Возможно, наиболее мощным дополнительным свойством, предоставляе- предоставляемым полной версией сетевого монитора, является возможность соединять- соединяться с удаленными агентами, выполняющимися на других машинах. Делая это, можно увидеть сетевой трафик, обычно невидимый в сегментированной разделенной коммутаторами сети. Используя свойство соединения с удаленной сетью, версия Netmon SMS может соединиться с другим сервером NT, рабочей станцией или машиной Windows 95 или 98, на которой установлен и выполняется агент сетевого мо- монитора. Агент сетевого монитора устанавливается как служба Windows NT и при желании может быть настроен для автоматического запуска для об- облегчения использования удаленного поиска неисправностей. При желании служба может быть оставлена с ручным управлением и запускаться удален- удаленно с помощью утилиты NETSVC из NT Resource Kit. Эта утилита позволяет запрашивать, перечислять, запускать и останавливать службы на удаленных машинах Windows NT.
250 Глава 9 Синтаксис Netsvc Netsvc \\имя_компыотера /команда Netsvc Netsvc Netsvc \\имя_компьютера \\имя_компьютера \\имя_компьютера /list /query /start "агент "агент сетевого сетевого монитора" монитора" Установка и конфигурирование агента сетевого монитора Windows 9.x Установка и работа агента сетевого монитора Windows 9.x не совсем прямо- прямолинейна. Агент находится на на сайте издательства "ЛОРИ" (www.lory-press.ru) в каталоге \admin\nettools\Netmon и состоит из двух частей. Имеется драй- драйвер протокола, который предоставляет показатели производительности сис- системному монитору для адаптеров NDIS 3.1. Это позволяет системному монитору просматривать статистику сетевого трафика. Агент сетевого монито- монитора использует некоторые функции, предоставляемые драйвером протокола для передачи информации назад в приложение Netmon. Вот шаги, необходимые для установки агента сетевого монитора Windows 9.x. 1. Откройте сетевой апплет в панели управления и щелкните по кнопке Add. '»_." 2. Выберите тип сетевого компонента и сделайте двойной щелчок по службе. 3. В диалоговом окне службы щелкните по кнопке Have disk. '" 4. Для установки из каталога используйте каталог на \admin\nettools\ Netmon на компакт-диске Windows 9.x. 5. В окне выбора сетевой службы щелкните по агенту Microsoft Network Monitor и подтвердите ОК. Приведенные выше шаги установят драйвер протокола и агента. Что- Чтобы сконфигурировать агент, вернитесь в сетевой апплет, выберите Micro- Microsoft Network Monitor Agent и щелкните по свойствам. Это приведет к появлению окна, аналогичного тому, которое мы видели ранее для машин Windows NT, где можно присвоить пароль перехвата и пароль вывода. Этот пароль должен задаваться, когда агент не выполняется и системный монитор не выводит данные производительности сети. Когда агент будет установлен и сконфигурирован, наступает время для его запуска. Это делается из команды запуска (run) вводом nmagent. Агент может останавливаться из команды запуска (run) с помощью ввода nmagent -close. Агент можно также запустить как службу на машине Windows 9.x, делая следующие изменения в реестре.
Семейство сетевых мониторов компании Microsoft 251 Запуск агента сетевого монитора как службы Выберите следующую строку в реестре на машине Windows 9.x HKEY_LOCAL_MACHINE\Software\Microsoft\CurrentVersion \RunServicesOnce Добавьте новое строковое значение nm agent Измените значение новой строки и введите nmagent.ехе Так как агент выполняется теперь как служба на машине Windows 9.x, он будет продолжать выполняться независимо от того, зарегистрирован на компьютере пользователь или нет. Чтобы остановить службу в любое время, используйте команду nmagent -close из окна запуска (run). Соединение с удаленными агентами . Чтобы соединиться с удаленным агентом, выберите networks из меню captu- capture. Появившееся окно выбора сети перехвата перечисляет все установлен- установленные на машине сетевые адаптеры и один дополнительный адаптер, называемый удаленным (remote). По умолчанию его состояние определяет- определяется как разъединенное и неизвестного типа. При успешном запросе сетевого агента можно просто сделать двойной щелчок по удаленной неизвестной сети, и появится окно, показанное на рис. 9.13. Введите имя машины одного из агентов, который будут возвращен этим запросом, и должно будет устано- установиться соединение. Если агент защищен паролем, то появится диалоговое окно, запрашивающее пароль. После соединения сеанс работает таким же образом, как и локальный перехват. Можно также настроить буфера пере- перехвата и сконфигурировать фильтр перехвата, но различия в способе работы сеанса нет. Connect To Network Monitoring Agent Current Status: No Connection Connect New Connection Information: Agent Name: JTERESA User Comment: |PR0X:| Agent status update frequency Every \2 Г~ 2,k>w Link seconds Cancel Рис. 9.13. Чтобы соединиться с удаленной сетью, введите имя поддерживающей агент машины
252 Глава 9 Мастера-помощники Сетевой монитор SMS 1.2 включает несколько мастеров, которые помогут найти некоторые важные данные. Это отчеты (они не являются в действи- действительности мастерами) верхнего пользователя и распределения протокола. Другие функции мастеров — поиск всех маршрутизаторов в файле перехва- перехвата и поиск всех имен в файле захвата, а также они могут разрешать адреса по именам. Недостаток этих отчетов в том, что не существует способа со- сохранить информацию помимо печати экрана (print screen) для перехвата отчета с экрана. Это существенный недостаток, так как часто полезно рас- распечатать данные, в частности, отчет верхнего пользователя. Рассмотрим отчет верхнего пользователя. Отчет верхнего пользователя активируется в режиме вывода (когда выво- выводятся перехваченные данные в противоположность просмотру статистики сеанса). Отчет выбирается из меню Tools и имеет возможность показать, сколько выводить верхних пользователей, и основывается ли список на ад- адресе канала данных или на адресе MAC. Можно также применить текущий фильтр вывода или выбрать игнорирование фильтра вывода и основывать отчет на всем файле перехвата. Как можно видеть на рис. 9.14, отчет пере- перечисляет имя, адрес, число кадров и процент числа кадров и размера кад- кадра. Эта информация может помочь при планировании и расширении сети, а также при обнаружении нарушений эксплуатации сети. TOP USERS Top Sender By Number of Frames, FAei Applied Name UNKNOWN UNKNOWN Address 10.112.201.80 10.112201 140 Frames 12 13 X Frames 48 52 X Filtered Frames 48 52 Bytes 2448 1722 KBytes 58 41 5 J «1 1 >Г Top Recipient By Number of Frames. Fdter Applied Name UNKNOWN UNKNOWN Address 10.112201.140 10.112.201.80 Frames 12 13 X Frames 48 52 X Filtered Frames 48 52 Bytes 2448 1722 X Bytes 58 41 X Filte| 58 41 Help Рис. 9.14. Отчет верхних пользователей Netmon может помочь при планировании сети
Семейство сетевых мониторов компании Microsoft 253 Отчет о распределении протоколов доступен таким же образом, как и отчет верхних пользователей: из меню Tools в режиме вывода. Возможно- Возможности этого отчета включают перечисление всех протоколов в кадре, сообще- сообщение о последнем протоколе в кадре и сообщение о первом действующем в кадре протоколе. Кроме того, можно выбрать дальнейшее ограничение на отчет, применяя текущий фильтр вывода к отчету. Этот отчет может стать существенной помощью при попытке выявить аномалии в сети. Однако чтобы эта информация была наиболее полезна, необходимо знать, каким является нормальное распределение для сети. Если, например, сеть обыч- обычно имеет очень немного кадров ARP_RARP, но внезапно ими заполняется, есть хорошая исходная точка для поиска. Если же произошел внезапный всплеск пакетов UDP, это будет иметь другое значение. Знание того, что является нормальным для сети, трудно переоценить. Как можно видеть на рис. 9.15, отчет перечисляет каждый протокол, число кадров и байтов и процент для перехваченных данных. _>.„. , ,. Protocol Distribution Report 25 Total Frames in Capture 4170 Total Bytes in Capture 25 Total Frames which Passed the Filter 4170 Total Bytes which Passed Filter All Protocols in each Frame Calculated. Filter Applied Help Protocol ETHERNET FRAME icmp ¦ IP MSRPC NBT R SRVSVC SMB TCP Frames 25 25 8 25 4 16 2 16 17 Bytes Claimed 350 0 320 500 192 64 96 2308 340 X Frames 100 100 32 100 16 64 8 64 68 % Bytes 8 0 7 11 4 1 2 55 8 % Filtered Frames 100 100 32 100 16 64 8 64 68 i or1* 7 1 4 1 2 5 8,r| «I i >Г Рис. 9.15. Отчет о распределении протоколов Netmon помогает в обнаружении сетевых аномалий Поиск сетевых адресов по имени позволяет вводить имя компьютера, а поиск найдет соответствующий адрес MAC. Это не очень сложно выпол- выполнить в сети TCP/IP, так как можно сделать ping имени хоста и затем полу- получить информацию из кэша ARP с помощью команды ARP -а. Однако он может также использовать SAP, DNS и запрос базы данных SMS, поэтому это может быть более мощное решение. Если происходит обычная провер- проверка адреса MAC, часто быстрее перейти в окно CMD и сделать ping и ARP -а. Как мы видим на рис. 9.16, когда имя разрешено, будет выведена вся
Find Network Addresses From Name Name: |teresa Local Machine Information Run Query [TERESA Aliases: Addresses: Ogtions Keep Names Type IP Address: MAC Address: Address | I 10.0.0.11 , • M 00 80 5F OF C8 4A (Ethernet] '' W <l 1 >Г fione Help Рис. 9.16. Поиск сетевого адреса из запросов имени нескольких источников для разрешения имени '*¦ ' . Ц'': ='¦• '. : найденная о нем информация. Выбор только тех служб, которые присутст- присутствуют в сети, может оптимизировать этот процесс. Кроме того, можно уско- ускорить процесс, делая локальную базу данных ADR первым источником, который будет запрашиваться с помощью кнопок "плюс" и "минус" рядом с окном выбора службы. Конфигурирование триггеров Триггер проверяет кадры по мере их прохождения. Сетевой монитор соби- собирает данные, чтобы найти кадры, удовлетворяющие некоторым критери- критериям. Если они удовлетворяют заданному условию, то сетевой монитор выполнит некоторые заданные действия. Это весьма мощный инструмент, открывающий почти неограниченные возможности. Очень простой триг- триггер, который не даст потерять данные во время сеанса мониторинга, созда- создается с помощью выбора триггера на пространстве буфера, выбирая 100% для задания пространства буфера и задавая затем действие триггера как остановку перехвата. Чтобы несколько усовершенствовать этот триггер, напишите простой пакетный файл, который будет выполнять команду net send, уведомляя, что перехват данных остановлен, а затем прикажите триггеру выполнить этот пакетный файл (с расширением .bat), когда перехват данных остановится.
Семейство сетевых мониторов компании Microsoft 255 Этот пакетный файл может состоять только из одной строки и выглядеть как файл, представленный ниже. Его можно написать в notepad и затем пе- переименовать файл с расширением .txt в файл с расширением .bat и указать в командной строке его расположение. Простой пакетный файл, уведомляющий при остановке перехвата данных ¦ .>. Net send administrator the capture has ceased! 'ic i,•••¦'•'• <¦ Примечание: Net send будет использовать следующее: имя пользователя, имя машины или *, означающее "все". Сообщение следует за местом назначения и не требует " " Использование триггеров может стать очень сложным, когда вводятся элементы смещения шаблона. Используя смещения шаблона, сетевой мони- монитор может идентифицировать широкое множество событий и выполнить все, что можно выполнить из командной строки — включая другой экземп- экземпляр сетевого монитора на другой машине. Использование шестнадцатерич- ной панели для идентификации смещения и шаблона для определения события, которое будет за этим инициироваться, может определить эти смещения шаблона. Это делается таким же способом, который рассматри- рассматривался ранее в этой главе в разделе о разработке фильтров перехвата. "¦¦'v Автоматический запуск сетевого монитора Если требуется авто- автоматически запускать сетевой монитор либо с помощью пакетного файла с триггером, либо с помощью службы планировщика Windows NT (команда AT), можно использовать следующие ключи командной строки. Каждый из этих ключей изменяет команду netmon. Пример пакетного файла вклю- включен в каталог batch на сайте издательства "ЛОРИ" (www.lory-press.ru). Что- Чтобы облегчить использование Netmon из командной строки, добавьте каталог с исполняемым файлом в путь доступа компьютера, изменяя пере- переменную path системного окружения. , ^ r ,r, ,. ,.т. ,,.,- • /autostart — заставляет сетевой монитор запустить перехват данных немедленно после запуска. Пример: netmon /autostart. • /remote computer - computer является именем удаленного агента, с которым > желательно соединиться. Пример: Netmon /remote exchange. ¦; ¦ • /net number - number определяет соединение с указанным сетевым ин- интерфейсом. Эту информацию получают при помощи команды ne- networks из меню capture. Пример: Netmon /net 2 (запустит Netmon, используя интерфейс сети #2, указанный в диалоговом окне сетей, но не начнется перехват данных, так как не определен ключ /autostart). • /capturefilter path — определяет фильтр перехвата, который будет ис- использоваться при работе сетевого монитора. Path задает расположение определенного фильтра перехвата.
256 ¦ Глава 9 • /displayfilter path — определяет фильтр вывода, который будет загру- загружаться при запуске сетевого монитора. • /buffersize number— задает размер буфера в байтах (одномегабайтный буфер перехвата будет определяться как /buffersize 1024000). • /quickfilter type, address — указывает, что сетевой монитор начнет пере- перехват данных сразу после запуска, и будет фильтровать на указанном адресе. • /autostop — заставляет сетевой монитор остановить перехват дан- данных, когда буфер заполнится. Пример: Netmon /autostart /buffersize 1024000 /autostop (запускает Netmon и немедленно начинает пере- перехват данных с буфером перехвата в один мегабайт. Когда буфер пере- перехвата заполнится, он остановится). Network Monitor 2.0 ,лн ^ : При запуске Systems Management Server Network Monitor версии 2.0 (V5.00646) можно подумать, что встретился со старым другом. Это полная версия Windows 2000 Network Monitor. Интерфейс практически такой же, и большинство утилит работает так же. Однако некоторые вещи измени- изменились и появились новые свойства. Новые свойства г„»_ _11 ^-^-„„.--^ '.....' Программы-эксперты — шесть экспертов, поставляемых вместе с Network Monitor 2.0, перечислены ниже. • Эксперт среднего времени ответа сервера вычисляет среднее время, которое требуется серверу для ответа на запрос пользователя данных. Он может использовать SMB, специальные порты TCP или специальные сокеты IPX для получения этих чисел, выраженных в секундах. • Распределение свойств вычисляет статистики кадров для определенно- определенного свойства, найденного в кадрах перехваченных данных. Эти свойства могут быть весьма специальными, такими как прием HTTP. • Утилита объединения протоколов рекомбинирует данные транзак- транзакции, которые были посланы по сети в множестве кадров. Этот экс- эксперт может собрать все фрагменты вместе на основе информации, которая содержится в кадрах. ¦.; ¦ j ¦. :..;-!/ • Эксперт распределения протоколов проверяет перехваченные дан- данные и предоставляет статистики о пакетах почти таким же образом, как мастер распределения протоколов в продукте 1.2. • Эксперт пересылки TCP находит кадры TCP, которые были пересланы на один и тот же компьютер. Это полезно при выявлении проблемных компьютеров.
Семейство сетевых мониторов компании Microsoft 257 • Эксперт верхних пользователей находит верхних отправителей и по- получателей данных в файле перехвата, проверяя адреса источника и места назначения, содержащиеся в кадрах. SMS 2.0 Platform Software Development Kit (SDK) позволяет разработать своих собственных экспертов, их можно также купить у независимых по- поставщиков. Эксперты запускаются из меню tools expert при работе в режи- режиме показа. Как можно видеть на рис. 9.17, эксперт среднего времени ответа сервера может быстро выделить проблему со временем ответа сети. На ри- рисунке сервер 11.0.0.206 имеет среднее время ответа 2.378751 секунд, в то время как все остальные места назначения имеют времена ответа в долях секунды. Чтобы еще больше ухудшить ситуацию, этот медленный сервер используют десять пользователей. Раньше этот процесс превращался в де- десяток телефонных вызовов (что затрудняло выявление и исправление проблемы). Но теперь, когда благодаря мониторингу и анализу наши дейст- действия носят профилактический характер, можно решить проблему без вся- всяких телефонных звонков. Пользователь только после решения проблемы заметит, что сервер стал видимо работать быстрее. Micro»* Network Мопйш - lEveM V>ewm| M fie ?<* V«w fipu*u v^xiow hfet Bl^-sl Л| Average Server Response Time { Setvtt SunvMry 11001550.000000000001 101Q 000000000001 1.000000000001 2300166 110.0207 110.0.20» 110.0205 1100201 1 Avewge Response Типе [se<x*!cfc] J 0 Retpomei 0.617262 0 00157U3 00OO4S2114 oocn 01295 0.0Л4464 Z 37851 O0O79O9O5 00309688 1797 14 634 1 г к «в 174 448 1 » Ciwit 1 2 3 3 1 2 10 15 26 The average was calculated by adding die individual response times and dmdmg by the number of responses ;To«r Events-10 'FP.lAttfb lOftONO) Л 1, :t «»0| Рис. 9.17. Эксперты создают отчеты, которые быстро указывают моменты, требующие внимания
258 Глава 9 Эксперт пересылки TCP на рис. 9.18 сообщает, что на самом деле су- существует несколько пересылок, но ни одна из них не идет на машину или из машины с длинным временем ответа. Так как это происходит не на коммутируемой магистрали, то пересылки могут быть вызваны сетевой перегрузкой, указывающей на возможную причину некоторых задержек. fat View Орсоо; О 004000 CIHFP1 О 004000 STOREXEC 0 019000 0800ЭЕ0 0 029000 CINFP1 55: Session Message. Lea 28 SS: Session Message, ten 56 к . len 0. seq ?6 SS: Session Kessage. lea 52 .jRrni G \2poVKbiс* lOOXdore _J Bin 2 G:\*n2622.c«>. lOOXdona 11г Е ¦¦< 1 15 i I» f il17 Ши 1 tl ... 1 ШЙ ^H ^H ^H ¦1 t i venl Vtewet Common | S»verty I Souce ( Ivtf* > TCPR«tt«ratnit RebantrmrtedFiamc ) TCP Rettanun* Retiantm^ed F tame ) TCP Retiamml Rptrantmxted Tiame 1 TCP Rebanont Rtf)ansm«ted Frame 1 1LJ* H^dantfntf Retranur^tteo ^facnc 1 TCP Rotiantmt Rctfdnfni'tco ^lanw 1 TCP Retianmt Racartpratted Fiame 1 TCP Retiantml Reuyar^ttd r'*me 1 TCP RMfammt Rotiantn^tetJ Ftame 1 TCP Retiarumt RebanvrMiled Frame 1 *SI»rt][^MicronU NetmriL M- . 1 Tme 120029 AM 1200 23 AM 12OO23AM 12 00 22 AM 1200 22 AM 1200 22 AM 120021AM 12:0021AM 120O17AM 1200.16AM 12:0015AM 120015AM I SrcAddrm 11.0Д2О1 11O0201 1100.201 1100201 1100201 11 00.201 1100201 1100.201 110 0207 110.0207 1100201 1100.201 М«„«006 I DjlAod | 23.00186 nooee 11 0068 110088 110088 110088 110088 110088 11.00183 1100133 11.00.88 110088 46 FB SeqNuntw 4412?6 328522943 328508348 328505C30 J28484739 328482C17 328479250 328475588 Э343215 3S43152 328475327 328475219 I Flare Numb» 3147 2X1 2260 2234 2200 2120 20% 1981 1287 1193 1051 1037 1 - oFbMJf I.I3IXI ШЁ 2992 ШЯ 2295 ШВ 2250 ЯШ 7PX H 2143 <^B 2110 ^Ш 2028 :^Ш 1879 ^Ш 1277 ^Ш 1184 ,^В 104S |Н 1022 ЩЛ " СОЙ) '" т 136АМ Рис. 9.18. Эксперт пересылки TCP идентифицирует пересылку кадров, что указывает на потенциальные сетевые проблемы — ¦« Утилита объединения протоколов сообщает нам, что в перехваченных' данных не существует фрагментированных пакетов, поэтому эта возможная причина может быть отброшена. Рассматривая эксперт верхних пользователей, мы видим, что пять из де- десяти верхних пользователей соединены с сервером 11.0.0.206, и наш эксперт протоколов также говорит, что существует большое число соединений RPC с одной и той же машиной. Мы исследуем этот вопрос и находим, что 11.0.0.206 является более старой машиной, находится на 10-мегабитном сег- сегменте Ethernet и даже не имеет в себе платы PCI Ethernet. Очевидно, что мы обнаружили причину слабой производительности. Пользователи не жалова- жаловались на нее раньше, потому что "она всегда медленная" и они "научились с этим жить". Замена старой платы на 100-мегабитную плату PCI решает эту проблему достаточно просто.
Семейство сетевых мониторов компании Microsoft 259 Как можно видеть на рис. 9.18, эксперты записывают свою работу в окне статуса экспертов. Мониторинг этого окна удержит вас от попытки выпол- выполнить две программы-эксперта в одно время (что породит сообщение об ошибке). Это важно помнить, так как выполнение эксперта на большом файле перехвата может потребовать много времени на медленной машине, а окно статуса эксперта является единственным местом, которое позволит узнать, что компьютер не заблокирован. В это время можно заметить, что использование центрального процессора доходит до 100%, поэтому не надо выполнять экспертов на производственных серверах, так как это вы- вызовет жалобы сообщества пользователей. А вот это не работает Невозможно соединиться с машиной Windows 95 или 98 и выполнить на ней удаленный сеанс сетевого монитора с помощью Network Monitor 2.0, так как для этого требуется драйвер Network Monitor версии 2, который требует Windows NT 4 с сервисным пакетом 4. Это также препятствует вы- выполнению приложения сетевого монитора на машине Windows 9.x. Раньше можно было установить полную версию сетевого монитора на портативном компьютере Windows 95 или 98 и наслаждаться улучшенными свойствами портативности 9.x, такими как улучшенное управление энергопотреблением и plug-and-play, а также иметь портативный сетевой анализатор. Невозмож- Невозможно установить Network Monitor 2.0 на этой платформе. Однако Windows 2000 Professional прекрасно работает на переносных компьютерах, и можно выполнять Network Monitor 2.0 на этой платформе. Тем не менее можно без проблем установить обе версии сетевого мони- монитора на одной машине. При необходимости можно выполнять обе версии на одной машине одновременно. Невозможно открыть файл .cap, созданный Network Monitor 2.0 на ма- машине Network Monitor 1.2. Если попробовать это сделать, будет получено сообщение об ошибке: "Файл перехваченной информации является недей- недействительным". Так как не существует способа сообщить, в каком формате записан файл .cap, лучше создать отдельные каталоги, чтобы избежать путаницы при выполнении в сети обеих версий. Несколько передач перехвата недопустимы в Network Monitor 2.0. Это несколько неудобно с точки зрения тестирования, однако в реальной жиз- жизни требуется редко. При переходе к утилитам перехвата передачи единст- единственными вариантами являются передача всех кадров, передача выбранных кадров или применение текущего фильтра изображения. Это еще одна при- причина для сохранения утилит версии 1.2 — по крайней мере в лабораторной среде. Дополнительные свойства безопасности Инструмент управления монитором непрерывно следит в сети за предо- предопределенными событиями. Эти события перечислены ниже: • Монитор перенаправления ICMP создает событие, когда маршрутизатор в сети перенаправляет кадры.
260 Глава 9 • Монитор маршрутизатора IP создает событие, когда маршрутизатор в сети отказывает. • Монитор IPRange создает событие, когда кадр имеет адрес источника, который находится вне диапазона адресов, заданных администрато- администратором как допустимые для определенной сети. • Монитор маршрутизатора IPX создает событие, когда в сети отказывает маршрутизатор IPX. • Мониторы DHCP и WINS создают событие, когда в сети будет обнару- обнаружен работающий недопустимый или неавторизованный сервер DHCP или сервер WINS. • Монитор SynAttack наблюдает за сигналами SynAttack в сети. Эта ата- атака будет создавать большое число не отвечающих соединений на сете- сетевом сервере, что в свою очередь поглощает большой объем ресурсов. Подобно пиявкам, synattack будут высасывать жизнь из сервера. Это атака отказа в обслуживании, и монитор SynAttack знает, как следить за характеристиками, которые указывают, что происходит атака этого типа. • - - ¦'•.'• ' ¦ • Монитор безопасности обнаруживает неавторизованные экземпляры сетевого монитора, выполняющиеся в сети. Когда утилита управления монитором используется для конфигурирова- конфигурирования и активации определенного монитора локально или удаленно, монитор проверяет кадры, проходящие мимо машины, так как он ищет определен- определенное свойство, связанное с событием, которое он ищет. Когда маршрутиза- маршрутизатор прекращает работу, он больше не объявляет себя в сети. Инструмент управления монитором может заметить отсутствие этих объявлений мони- монитора в течение определенного периода времени. Тогда он создаст событие и откроет инструмент сетевого монитора в окне просмотра событий. Чтобы использовать монитор, должна выполняться служба управления монитором. Она устанавливается при установке Network Monitor 2, но служба монитора по умолчанию задана для управления вручную. Помимо мониторов, которые поставляются вместе с Network Monitor 2, можно ис- использовать заказные мониторы или мониторы независимых поставщиков, чтобы еще больше расширить функциональность продукта. Нельзя выпол- выполнить утилиту управления монитором на любой системе, которая не удов- удовлетворяет требованиям выполнения приложения Network Monitor 2. Кроме того, он требует административных прав на компьютере, выполня- выполняющем утилиту управления монитором. Чтобы использовать службу собы- событий, требуется WBEM (управление предприятием на основе Windows), и вы получите это приглашение, запустив утилиту управления монитором на компьютере, который не имеет установленной WBEM. Windows 2000 имеет WBEM по умолчанию, и на машине Windows NT 4.0 вы получаете WBEM, когда устанавливаете административные инструменты SMS 2.O. Можно за- запустить утилиту из ММС, щелкая правой кнопкой мыши по сетевому мони- монитору и выбирая запуск утилиты управления сетевого монитора, или можно создать ссылку на mcsui.exe (что легче и быстрее). Кроме того, добавив
Семейство сетевых мониторов компании Microsoft 261 каталог netmon2 в path, можно запускать netmon.exe и mcsui.exe из окна за- запуска или приглашения CMD. Когда утилита управления монитором запу- запущена, можно выбрать любой из мониторов, перечисленных ранее в этом разделе, как показано на рис. 9.19. . ,. . , ,((.,, ,, _,, , м . ETHERNET: 000000000000 ETHERNET: 00902764FAO6 Instated Monitors 1СЫР Redrect Monitor IP Router Monitor IPRange Monitor > IPX Router Monitor Rogue DHCP and WINS Monitor Security Monitor ', SyrAttack Monitor Enabled Monitors Status «Qisable Configure | Start I I Security Monitor 1 IIP Route! Monitor 1 Configured J Рис. 9.19. Утилита управления сетевым монитором автоматизирует большую часть деятельности мониторинга Нежелательно выполнять утилиту управления монитором на той же ма- машине, которая выполняет первичный сайт SMS, лучше (в связи с требования- требованиями ресурсов) настроить отдельную машину для выполнения мониторинга. Затем можно будет использовать эту машину для мониторинга нескольких уда- удаленных компьютеров, а также для выполнения необслуживаемых трассиро- трассировок сетевого монитора и триггеров. По сути он станет сетевым управляющим компьютером. Посмотрим, как можно сконфигурировать монитор для сигнализации о том, что один из маршрутизаторов отключился. На рис. 9.19 установлен- установленные мониторы перечислены в левой панели вывода. Включенные монито- мониторы перечислены в правой панели вывода. Включите монитор, выбрав его из левого списка и нажимая кнопку Enable. Затем утилита управления сете- сетевым монитором предложит сконфигурировать включенный монитор. Если вам не нужно конфигурировать монитор в это время, в ответ нажмите по (нет). Не сконфигурированный монитор будет показан как включенный в правой панели. Если двинуться дальше и сконфигурировать монитор, то появится экран, изображенный на рис. 9.20. Чтобы проследить за опреде- определенным маршрутизатором, надо ввести IP-адрес в поле слева на экране и выбрать число секунд, после которых маршрутизатор считается отключен- отключенным, помещая это значение в поле внизу слева на экране. После этого на- нажмите кнопку Set monitor configuration (Задать конфигурацию монитора) в нижней правой стороне экрана (она не показана на рис. 9.20).
m Moraloi Conliol Tool ¦ IConligue IP Router Мопйш II M W»Jow Help IP Router Monitor Configuration a ¦•¦ Monitor these Router IP Addresses: 10. 10. 10. 10. 0.0.10 1.0.10 2.0.10 3.0.10 ft 1 I In the text bo» to the left, enter the IP Addresses of the routers that you wish to monitor for activity. Quiet routers are considered down in [180 seconds. In the text box to the left, enter a number from 10 to 600. This number represents the seconds of time that a router must be quiet before the router is considered Рис. 9.20. Окно конфигурации монитора маршрутизатора IP перечисляет маршрутизаторы, которые отслеживаются в данный момент Монитор маршрутизатора IP теперь сконфигурирован, но он не являет- является активным, пока не будет выбран в правой панели и не будет нажата снопка start (запуск). Теперь он выводится как действующий. Если сконфигурированный маршрутизатор IP обнаружен как неактив- шй, то утилита управления сетевым монитором будет выводить событие в курнале событий монитора (см. рис. 9.21). К сожалению, он не записывает i журнал событий Windows, и поэтому утилиты журнала событий не смогут >треагировать на это событие. Интересным свойством утилиты управления сетевым монитором являет- является возможность сконфигурировать несколько мониторов одного типа. Это »значает, что можно сконфигурировать несколько мониторов маршрутиза- маршрутизаторов IP и активировать их по отдельности или в одно время. Это позволит 1ыключить из сети определенный маршрутизатор для обслуживания без не- •бходимости выключать монитор маршрутизатора IP в целом. Это можно делать также и для других мониторов: например, использовать несколько юниторов безопасности, которые позволяют администратору выполнять нализ сети, но он должен будет получить разрешение от старшего админи- тратора. При таком сценарии старший администратор просто запускает ключенный ранее монитор безопасности, чтобы позволить младшему адми- [истратору выполнить анализ сети. По завершении монитор, содержащий дрес MAC, выключается. ' :
Семейство сетевых мониторов компании Microsoft 263 вв Moniloi Conliol Tool - (Event Vieweil M ?*e ?* tfew Window hlelp i MonitorEvents | I Severity | Soutct Event I Oesaipton Troe Dale IP Route Mont, limed out IP Routei Momr ijnedout IP Route Мог* timed oul IPRouteiHmed... 11:5809AM 8/28/9S IPRoutei tuned 11:5809AM &?8/3S IP Route» timed П 58 09AM 8/28/99 This router has not retransmitted within our timeout penod. It may no longer be fimctiona] Ж FofKeip.'prien ¦ if otalEvents: 3 Рис. 9.21. Обнаруженные события выводятся в журнале событий утилиты управления сетью Запуск Network Monitor 2 из командной строки Запущенный сете- сетевой монитор работает таким же образом, как в Netmon 1.2; однако синтаксис немного отличается: двоеточие ставится между ключом и модификатором. Например, Netmon /гето1е:имя_компъютера запускает Netmon версии 2 и соединяется с удаленным компьютером. Однако изменилась одна команда: /buffersize получает теперь размер буфера в мегабайтах, а не в байтах. На- Например, чтобы запустить Netmon v.2 и начать перехват данных с помощью трехмегабайтного буфера перехвата, введите Netmon /autostart /buffersize:3 из командной строки или команды run. Существует одна новая переменная командной строки, ключ /quickfiltername. Он используется для определения фильтра, который определяется параметром /quickfilter. Он игнорируется, если нет определенного параметра /quickfilter. Обзор главы В этой главе было подробно рассмотрено семейство сетевых мониторов компании Microsoft. Были выявлены сходства и различия двух поколений продуктов и даны рекомендации по их использованию для мониторинга, анализа, поиска неисправностей и работы системы безопасности. Было рассмотрено использование программ-мастеров из семейства 1.2 и про- программ-экспертов из семейства 2.0 для быстрого обнаружения потенциаль- потенциальных проблем и для идентификации областей, которые могут требовать дальнейшего исследования. В конце была обсуждена утилита, управления
264 Глава9 сетевым монитором, поставляемая вместе с Network Monitor 2.0, которая может автоматизировать некоторые из повседневных задач, связанные с проблемами безопасности и критически важным сетевым оборудованием. В следующей главе .^v Мы начнем заключительный раздел книги с рассмотрения поиска неисп- неисправностей. Мы обсудим некоторые наиболее стандартные проблемы: медленная сеть, пользователь не может зарегистрироваться, рабочая станция не может получить IP-адрес. Мы научимся пользоваться сетевым монитором для разрешения всех этих проблем. Другими словами, мы ис- " пользуем ту или иную проблему в качестве инструмента для закрепления полученных ранее знаний. Рассмотрев обычные проблемы, мы перейдем к некоторым особым со- сообщениям об ошибках. Наша цель состоит в разработке модели поиска не- неисправностей, а не просто в поиске ответа на какую-то неопределенную проблему. В конце рассматривается широковещательный шторм и обсужда- обсуждается стратегия выхода из проблемных ситуаций.
ЧАСТЬ IV Сценарии поиска неисправностей: распространенные проблемы еперъ мы готовы найти ответы на вопросы и проблемы, которые преследуют нас в течение долгого времени. Мы увидим, может ли помочь знание протоколов и утилит мониторинга при поиске неисправностей в сети.
Глава 10 Вопросы поиска неисправностей Основная проблема с соединением состоит в том, что оно либо есть, либо его нет — по крайней мере большую часть времени. Периодически возникающие проблемы соединения особенно неприятны. Обеспечить со- соединение — значит предоставить компьютерам возможность общаться друг с другом по проводам. Рабочая станция не может зарегистрироваться Одна из наиболее распространенных проблем соединения в сети возника- возникает, когда рабочая станция не может зарегистрироваться в домене. Хотя это могут вызывать многие причины (конфигурация протокола, разреше- разрешение имени, разрешение имени NetBIOS, полномочия), в этом разделе будут рассмотрены только некоторые из них. . ;,. . Можно ли сделать ping сервера? > Если рабочая станция имеет проблемы регистрации в домене, прежде все- всего необходимо проверить соединение. Для этого используется утилита ping. Как показано на распечатке ниже, сначала делается ping по имени, чтобы проверить разрешение имени. Он возвращается назад с ответом. За- Затем мы делаем ping по определенному IP-адресу, чтобы проверить, имеется ли доступ к тому же месту назначения, и, наконец, посылается большой па- пакет для проверки, что пакеты большого размера могут дойти до места на- назначения. Ping по умолчанию посылает очень маленький 32-байтовый пакет, который может дойти до места назначения, в то время как больший по объему трафик регистрации может не пройти через маршрутизатор. C:\>ping PROX Pinging PROX [10.0.0.10] with 32 bytes of data:
268 Глава 10 Reply from 10.0.0.10: bytes=32 time<10ms TTL=128 Reply from 10.0.0.10: bytes=32 time<10ms TTL=128 .., , Reply from 10.0.0.10: bytes = 32 time<10ms TTL=128 •¦"*, : Reply from 10.0.0.10: bytes=32 time<10ms TTL=128 C:\>ping 10.0.0.10 Pinging 10.0.0.10 with 32 bytes of data: Reply from 10.0.0.10: bytes=32 time<10ms TTL=128 Reply from 10.0.0.10: bytes=32 time<10ms TTL=128 Reply from 10.0.0.10: bytes = 32 time<10ms TTL=128 Reply from 10.0.0.10: bytes=32 time<10ms TTL=128 l C:\>ping 10.0.0.10 -1 4048 •'¦ - -r.a ,. лч ч ¦ • •-¦ Pinging 10.0.0.10 with 4048 bytes of data: Reply from 10.0.0.10: bytes=4048 time<10ms TTL=128 Reply from 10.0.0.10: bytes=4048 time<10ms TTL=128 Reply from 10.0.0.10: bytes=4048 time<10ms TTL=128 Reply from 10.0.0.10: bytes=4048 time<10ms TTL=128 Если большие пакеты не доходят до места назначения, а маленькие паке- пакеты доходят до сервера регистрации, то можно подредактировать реестр и определить меньший размер пакета как временную меру, пока не будет ясно, могут ли поддерживаться большие пакеты. Это делается в реестре следующим образом: Настройка размера пакетов TCP Добавьте значение в следующий ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcipip\ parameters_ Имя значения: TcpSendSegmentSize Тип будет Reg_Dword По умолчанию используется 1460 байтов Стандартное предупреждение о редактировании реестра Эти из- изменения будут влиять на всю коммуникацию с помощью TCP/IP и должны делаться только после тщательного тестирования. Конечно, прежде чем де- делать какие-либо изменения в реестре, убедитесь, что существует тщательно проверенная и актуальная резервная копия. По крайней мере сначала экс- экспортируйте ключ (см. рис. 10.1). Для импорта и экспорта ключей .reg Rege- dit является самым простым средством (он имеет также то достоинство, что может искать во всем реестре определенное значение). Для редактиро- редактирования реестра (локально или удаленно) используйте Regedit32, так как он имеет лучший редактор. Помощь от Netmon Повторите команды ping и выполните в трасси- трассировке Netmon выборку только рабочей станции и сервера. В дополнение к командам ping попробуйте также выполнить следующие команды. • Net view \\имя_сервера • Net use \\имя_сервера\{рс$
Вопросы поиска неисправностей 269 TI28 пэе 0x00000001 A1 OxOOOOOOPO fO] "pox" 0x00000001 П) Email Rea»t»Fik «^ iC! " J Ttanaent ' •_) Wnsock CiJ Pertcmanc* ?j Setirty _JNm _JV3PC*che _| W3Pn*y . _J W3SVC 4» Sstactadtunch 4 23 PM л I. Рис. 10.1. Прежде чем делать изменения, воспользуйтесь Regedit для экспорта ключей реестра Если эти две команды возвращаются с сообщением об ошибке, то имеет- имеется существенная проблема. Посмотрим на Netmon и проверим, можем ли мы обнаружить источник нашей проблемы. Мы видим, что команда ping работает фактически без каких-либо проблем. Это показано на распечатке ниже. Мы видим ICMP из источника в место назначения. Это тип эхо-пакета. Его размер 32 байта, что является используемым по умолчанию размером пакета ping. . ... . . , . ¦ ICMP: Echo, From 10.00.00.60 To 10.00.00.10 ICMP: ICMP: ICMP: ICMP: ICMP: @x0020) Packet Type = Echo Checksum = 0x2E5C Identifier = 256 @x100) Sequence Number = 7680 (OxlEOO) Data: Number of data bytes remaining = 32 За эхо-пакетом ICMP следует пакет ответа ICMP, который мы видим на распечатке ниже. Этот пакет возвращается из места назначения для ping как пакет эхо-ответ. Он также имеет 32 байта. Это говорит нам, что по край- крайней мере имеется элементарная коммуникация между рабочей станцией и сервером. . ... . ^ • '
270 Глава 10 '.U* ICMP: Echo Reply, To 10.00.00.60 From 10.00.00.10 " ' ICMP: Packet Type = Echo Reply ICMP: Checksum = 0x365C •¦•¦¦-• . \ ICMP: Identifier = 256 @x100) ICMP: Sequence Number = 7680 (OxlEOO) ICMP: Data: Number of data bytes remaining = 32 @x0020) Затем мы проверяем команду net view \\имя_сервера, что приводит к трехходовому квитированию между рабочей станцией и сервером. Треххо- Трехходовое квитирование происходит между рабочей станцией и портом 139, службой сеанса NetBIOS на сервере. Все работает нормально, поэтому да- давайте посмотрим раздел NBT следующего кадра, который показан на распе- распечатке ниже. Кадр из рабочей станции на сервер выглядит правильным. Мы видим, что тип пакета указывается как запрос сеанса (session request). Он содержит имя вызванного сервера и имя вызывающей рабочей станции. <00> является уникальным суффиксом NetBIOS, указывающим службу рабо- рабочей станции. Можно найти регистрацию <00> для этой машины в базе дан- данных WINS, отображающую ее в IP-адрес этой машины. Регистрация в базе данных WINS облегчает NetBIOS коммуникацию между машинами. NBT: SS: Session Request, Dest: PROX Source: j 2400 <00>, Len: 68 ,j NBT: Packet Type = Session Request ¦ ,. . , V . NBT: Packet Flags = 0 @x0) —., , ", ,, ' . L. NBT: 0 = Add 0 to Length ''"•* "* * . .... NBT: Packet Length = 68 @x44) ; -f ^.^ NBT: Called Name = PROX NBT: Calling Name = 2400 <00> V' ''''"''' Так как запрос сеанса NBT прошел нормально, посмотрим на ответ, ко- который приходит с сервера. Он содержится на распечатке ниже. В этом мес- месте мы получаем некоторую полезную информацию. Мы имеем ответ с отказом сеанса (Negative Session Response), и код ошибки службы сеанса го- говорит нам, что вызванное имя отсутствует. Теперь мы знаем, что проблема не на рабочей станции, а на сервере. Другие рабочие станции будут сталки- сталкиваться с той же проблемой. Теперь необходимо проверить, что происхо- происходит на сервере. Но сначала посмотрим, можно ли получить какую-либо дополнительную информацию из только что сделанной трассировки Netmon. NBT: SS: Negative Session Response, Len: 1 NBT: Packet Type = Negative Session Response NBT: Packet Flags = 0 @x0) NBT: 0 = Add 0 to Length NBT: Packet Length = 1 @x1) NBT: Session Service Error Code = Called Name Not Present Мы видим несколько запросов контроллера первичного домена, но не видим ответа. Это происходит, как SMB С transact в \mailslot\net\netlogon. Возможно, существует также проблема со службой netlogon.
Вопросы поиска неисправностей 271 UDP: Src Port: NETBIOS Datagram Service, A38); Dst Port: NETBIOS Datagram Service A38); Length = 230 @xE6) + NBT: DS: Type = 17 (DIRECT GROUP) M,;,; . + SMB: С transact. File = \MAILSLOT\NET\NETLOGON s NETLOGON: Query for Primary DC uuuiit. i , ¦ NETLOGON: Opcode = Query for Primary DC NETLOGON: Computer Name =2400 NETLOGON: Mailslot Name = \MAILSLOT\NET\GETDC915 NETLOGON: Unicode Computer Name = 2400 NETLOGON: NT Version = 1 @x1) '' NETLOGON: LMNT Token = WindowsNT Networking NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later) Networking Если заглянуть в просмотрщик событий на рабочей станции, можно уви- увидеть следующее сообщение: "Броузер не смог извлечь список серверов из мастер-броузера \\PROX в сети \Device\NetBT_E100Bl. Данные являются кодом ошибки". Это сообщение просто подтверждает, что на сервере име- имеется проблема. На сервере необходимо проверить следующее: • Проверьте, что служба сервера выполняется на компьютере места на- назначения. Проверьте апплет служб в панели управления (см. рис. 10.2). Если служба сервера не выполняется, машина будет все равно отве- отвечать на ping, но сеанс создать невозможно. Если служба сервера оста- остановлена, запустите ее. Это даже не требует перезагрузки машины. Это объяснит также сообщения ошибок броузера в журнале событий, так как служба броузера компьютера зависит от службы сервера. Кроме того, служба netlogon также зависит от службы сервера. Мы рассмат- рассматривали ранее проблемы со службой netlogon в трассировке Netlogon. Вопрос, конечно, в том, почему служба сервера остановлена? Некото- Некоторые вещи Netmon просто не может сообщить. Может быть, настало время сменить пароль администратора. •• •¦ ¦ *- ...... Services Seiyice Status Startup Remote Procedure Cal (RPC) Locator Remote Procedure Can (RPC) Service Schedule Started Started Automatic ±\ Automatic Manual Close"" i| Start SMS Client Service SMS Remote Control Agent SMS_NT_LOGON_DISCOVERY_AGENT Spooler TCP/IP NetBIOS Help» ',r Telephony Sei vice Startup Parameters: Stalled Started Slatted Automatic Manual Manual Manual Automatic Automatic Manual J Startup... HV/Profiles... Help Рис. 10.2. Проверьте состояние служб, чтобы исключить потенциальные проблемы
272 ¦¦¦¦"¦ Глава 10 • Проверьте, отвечает ли сервер места назначения. Он может быть за- заблокирован. Сервер может отвечать на эхо-пакет ICMP, даже если се- сеанс невозможно создать. Если компьютер заблокирован и невозможно восстановить управление через менеджер задач или каким-либо другим способом, следует сообщить всем пользователям о необходимости со- сохранить свои данные и по возможности аккуратно выйти из системы. Можно попробовать выполнить закрытие системы, хотя в зависимо- зависимости от того, что произошло, возможно, придется сделать полную за- загрузку. Если повезет, все восстановится нормально. Если нет, придется проверять процедуры резервного копирования. • Следующий пункт может показаться глупым, но если выполняется реги- регистрация пользователей в пределах лицензии, а ограничения лицензии превышены, то сервер будет отвечать на ping, но сеанс создаваться не будет. Проверьте апплет лицензии в панели управления и в журнале событий, чтобы убедиться, что ограничения лицензии не нарушены. • Проверьте, используется ли DNS или файл хоста. Методы разреше- разрешения имени хоста используются первыми в ping для разрешения име- имени. Команды net используют методы разрешения имени NetBIOS (lmhosts, WINS). Ping может работать, в то время как net view может простаивать. Рассмотрим случай с портативным компьютером Приведенный выше сценарий было бы практически невозможно разо- разобрать без использования Netmon. Если на рабочей станции установлены агенты, можно было бы соединиться удаленно и управлять трассировками; однако многие компании не очень широко используют агентов Netmon, и, конечно, Netmon 2 требует агентов версии 2, которые не работают на ма- машинах Windows 9.x. В таких случаях портативный компьютер с версией SMS Netmon становится мобильным сетевым анализатором. Портатив- Портативный компьютер не должен присоединяться к домену, чтобы перехватить трафик. Ему требуется только сетевое соединение, и вы можете решать сетевые проблемы там, где можно соединиться с сетью. Конечно, требует- требуется плата Ethernet для поддержки безразличного режима, но большинство современных плат поддерживают эти функции. Рабочая станция не может получить выделяемый DHCP адрес Хотя DHCP облегчает жизнь администратора, иногда клиентская машина Сталкивается с проблемами при получении адреса. В таких ситуациях ин- информация часто бывает скудной. Помимо того факта, что рабочая станция не получила адреса, мало что еще известно. Здесь начинают играть роль наши знания процессов DHCP и Netmon.
Вопросы поиска неисправностей 273 Взгляд на диалог ~ Прежде всего, необходимо проверить, что машина была сконфигурирована для запроса адреса. Если в окне свойств TCP/IP отмечено свойство "полу- "получать IP-адрес с сервера DHCP", то это должно работать. Если нет, мы преры- прерываем Netmon и просматриваем диалог. В идеале должны присутствовать четыре кадра, перечисленные ниже. 1. Поиск DHCP 2. Предложение DHCP 3. Запрос DHCP 4. DHCPACK Если эти четыре кадра не присутствуют, DHCP не будет работать, а кли- клиент не сможет получить адрес. Если ничего не присутствует, то клиент не- неправильно сконфигурирован для запроса адреса DHCP. Решение проблемы DHCP является процессом просмотра диалога и идентификацией того, что из диалога, представленного выше, пропущено. Проанализируйте, что пропущено Наш первый шаг состоит в просмотре трассировки и поиске пропущенно- пропущенного. Кадр запроса DHCP посылается с помощью многоадресной рассылки UDP IP из порта 68, клиентского порта ВООТР, в порт 67, серверный порт ВООТР. Magic cookie будет в порядке. Это четырехбайтная область в паке- пакете DHCP, которая идентифицирует начало поля, определенного поставщи- поставщиком для специальных параметров. Если используется данное поле параметров, это отмечается IP-адресом 99.130.83.99, который показан в трас- трассировке Netmon как шестнадцатеричное 63 82 53 63. Параметры могут пере- перечислять такие вещи, как идентификатор клиента, запрошенный адрес, а также другие позиции. В нашем поле параметров идентификатор клиента равен адресу MAC делающего запрос компьютера — в данном случае KENNY. Мы также видим, что машина KENNY запрашивает тот же адрес, которым она владела ранее. Если этот адрес доступен, его можно будет использовать снова. .,. ¦--,... UDP: IP Multicast: Src Port: BOOTP Client, F8); Dst Port: BOOTP Server F7); Length = 308 @x134) UDP: Source Port = BOOTP Client UDP: Destination Port = BOOTP Server UDP: Total length = 308 @x134) bytes UDP: UDP Checksum = 0x36C3 UDP: Data: Number of data bytes remaining = 3 00 @x012C) DHCP: Request (xid = 05F105F1) ' ' DHCP: Op Code (op) = 1 @x1) DHCP: Hardware Type (htype) = 1 @x1) 10 Mb Ethernet DHCP: Hardware Address Length (hlen) = 6 @x6) DHCP: Hops (hops) = 0 @x0)
274 Глава 10 DHCP: Transaction @x5F105Fl) DHCP: Seconds Flags Client Your Server Relay Client ID (xid) = 99681777 DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: DHCP: (sees) (flags) (ciaddr) (yiaddr) (siaddr) (giaddr) IP Address IP Address IP Address IP Address Ethernet Address (chaddr) Server Host Name (sname) Boot File Name (file) Magic Cookie = [OK] ¦ ;i •. ¦ .. DHCP: Option Field (options) DHCP: DHCP Message Type = DHCP Request Client-Identifier = (Type: 1) 00 0 @x0) ¦ - -4 0 @x0) . ;."*' 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 = 00104BEC8DB2 <Blank> <Blank> DHCP: 4b ec 8d b2 . . .. DHCP: '•"• ' DHCP: DHCP: 06 Of 2c 2e 2f DHCP: 10 Requested Address = 10.0.0.76 Host Name = kenny Parameter Request List = (Length: 8) 39 End of this option filed 01 03 В трассировке ниже запрошенный адрес недоступен, так как он получа- получает NACK, что является негативным подтверждением. Если рассмотреть часть IP в кадре, то можно увидеть машину, которая посылает этот NACK на рабочую станцию. Мы видим в этой части пакета, что он приходит из порта 67, порта сервера ВООТР, в порт 68, порт клиента ВООТР. Когда ра- рабочая станция получает NACK, она не будет инициализировать TCP/IP, пока не получит адрес. Если TCP/IP является единственным протоколом, машина не сможет общаться в сети, пока не будет обнаружен сервер DHCP. UDP: IP Multicast: Src Port: BOOTP Server, F7); Dst Port: BOOTP Client F8); Length = 308 @x134) UDP: Source Port = BOOTP Server UDP: Destination Port = BOOTP Client li;';: i;- UDP: Total length = 308 @x134) bytes : ' '* '¦"*•' UDP: UDP Checksum = 0x2D13 ¦' < UDP: Data: Number of data bytes remaining = 300 (OxO12C) DHCP: NACK (xid = 05F105F1) DHCP: Op Code (op) = 2 @x2) DHCP: Hardware Type (htype) = 1 @x1) 10 Mb Ethernet Так как клиентская машина посылает запросы DHCP и получает NACK с сервера DHCP, то можно сказать, что они общаются. Тот факт, что машина посылает запросы, является обнадеживающим, поскольку она делает все, что должна делать клиентская машина. Для проверки можно использовать команду ipconfig /renew из окна CMD, что заставит клиентскую машину со- создать трафик DHCP. Это один из способов выполнить передачу, не перезаг- перезагружая машину. В трассировке Netmon мы должны увидеть два кадра DHCP: запрос DHCP и DHCP ACK.
Вопросы поиска неисправностей 275 В нашей трассировке DHCP мы находим только запросы и один NACK. Мы не находим никакого другого трафика. Следующий шаг состоит в пере- переходе к серверу и изучению свойств DHCP. Там можно обнаружить, что сер- сервер не имеет свободных адресов, или что область действия была деактивирована. Это, видимо, две наиболее распространенные причины. Рабочая станция работает медленно Нет ничего необычного, когда пользователи жалуются на то, что сеть рабо- работает медленно. Эти жалобы сетевые администраторы слышат достаточно часто. Однако пользователи редко высказывают иные суждения, помимо общего наблюдения, что сеть медленная. Раньше администратор приходил к пользователю, наблюдал за его действиями и соглашался или не согла- соглашался с точностью наблюдений. Это не лучший способ для нового тысяче- тысячелетия. У нас есть Netmon в качестве средства спасения. Рассмотрим пример ниже, чтобы понять, как Netmon работает в этой ситуации. Можно ли точно определить понятие "медленная"? Простейшим способом определить понятие "медленная" является использо- использование эксперта среднего времени ответа сервера, имеющегося в Netmon 2.O. Прежде чем запускать эксперт, необходимо перехватить некоторый объем трафика между сервером и клиентской машиной. Если установлен агент версии 2, то все просто; если нет, то придется поместить портативный компьютер в том же сегменте, что и сервер, и сконфигурировать фильтр перехвата, который изолирует трафик между рабочей станцией и рассмат- рассматриваемым сервером. Это должно быть сделано после проверки на рабочей станции, сколько там открыто приложений, сколько имеется свободного пространства на диске для виртуальной памяти, и т.п. Когда будут исключе- исключены все возможные проблемы рабочей станции, можно начинать перехват данных. Что является источником недовольства? После воспроизведения источника недовольства загрузите перехваченный файл в Netmon 2.0 и сконфигурируйте эксперт времени ответа (см. рис. 10.3). Конфигурирование эксперта является существенно важным для получения точных результатов. Если, например, пользователь жаловался, что была мед- медленной почта РОРЗ, то необходимо добавить эксперту порт 110. Можно испо- использовать Приложение А для помощи в определении номеров общеизвестных портов при добавлении их эксперту. Изменяя конфигурационные файлы, эксперт может сообщить о боль- большинстве приложений, выполняющихся в сети. Если удалить все порты, кроме порта рассматриваемого приложения, будут получены различные показатели производительности. Использование Netmon 2.0 в этой облас- области почти не ограничено.
276 Глава 10 Aveiage Seiver Response Time Configuration Q ICP/IP ports Enter Port Number Enter pocket Number 1 :. ¦ i OK < Delete IPX Cancel Help Рис. 10.3. До выполнения эксперта среднего времени ответа сервера необходимо сконфигурировать его для рассматриваемого приложения , ; , . Эксперт создает отчет, перечисляя IP-адреса и среднее время ответа в се- секундах, как показано на рис. 10.4. Если результаты соответствуют базовым показателям, возможно, придется снова посмотреть на рабочую станцию и привычную работу определенного пользователя. Если они действительно медленные, то трассировка будет требовать дополнительного анализа. От- Отчет распределения протоколов, отчет верхних пользователей и эксперт пе- пересылки TCP могут предоставить ценную помощь при поиске причины медленной работы сети. Помимо просмотра на экране отчеты можно сохра- сохранить как текстовые файлы и распечатать или превратить в другие документы, например файлы Microsoft Word. Проблемы с регистрацией Пока людям необходимо будет регистрироваться в сети, будут возникать проблемы с регистрацией. На самом деле существует только несколько пере- переменных, вовлеченных в процесс регистрации: имя пользователя, пароль и домен. Если они неправильны, то регистрация будет отказывать. Журнал со- событий сервера может предоставить ценную информацию, но необходимо
Вопросы поиска неисправностей 277 Microsoft Netmxk MokIoi Qoton» Window Ц* Average Server Response Time [ Swver | Avetape Reipome Time (seconds) j Я Reiponset IS813* 303 21S32243135 020*667 9 1 216 32182.252 0 345556 . , S , ,- > 1 207 4S.mX 010C667 ' J 1 206.1512551» 057N92 1J 1 пшют"—дир————— as r- Toe average was calculated by addtog tbe individual response times aad dividing by the number otresponses. .'¦-.;•• ¦ ' ¦ ¦¦¦ ' .- . . " '¦ ; . ¦ ¦ , ¦ , ' . ¦ , - : P, ; . , •¦¦ ¦'¦'¦''-.-', .¦¦.:.-. ;• /*' i/ ^;':- ' .. \ . ; ^ ¦¦ i . j FC. 1/10S9 OII.0W)) L'lldl Рис. 10.4. Отчет о среднем времени ответа сервера подтверждает проблему с временем ответа найти контроллер домена, который получает и обрабатывает запросы ре- регистрации. Кроме того, если безопасная регистрация не включена (а лучше бы включить), то журнал событий ничем не сможет помочь. Однако разумное применение Netmon сможет помочь в разрешении проблемы. Я пытаюсь аутентифицироваться, но где? Иногда пользователь при попытке зарегистрироваться вводит неправиль- неправильное имя домена. На машинах на основе NT это не проблема, так как они вы- выбирают домен регистрации из выпадающего списка. В Windows 2000 весь вопрос с доменом скрыт от взгляда пользователя, поэтому пользователи не знают, где они регистрируются — либо на рабочей станции, либо в домене. Что доступно, там они и будут соединены. Давайте посмотрим на клиента Windows 98, регистрирующегося в доме- домене. Клиент вводит имя пользователя, пароль и имя домена, а затем начина- начинает жаловаться, что не может войти в домен. Мы говорим с клиентом по телефону, и он подтверждает, что ввел свое имя пользователя и пароль, и что имя домена было введено правильно. Мы советуем ему нажать пару раз клавишу caps lock и проверить, что индикатор загорается, гаснет, загорает- загорается, гаснет. Мы проверяем менеджера доменов пользователя и видим, что позиции отключения учетной записи и блокирования учетной записи не
Глава 10 помечены, поэтому можно быть уверенным, что учетная запись не заблоки- заблокирована. Просмотрщик событий также не показывает записей, указываю- указывающих на неудачные попытки регистрации. Мы просматриваем резервные контроллеры домена, но там тоже нет ничего подозрительного. Мы про- просим пользователя включить и выключить соединительный кабель из стен- стенной розетки и из платы Ethernet. Он подтверждает, что соединение нормальное. Он пытается повторить и снова не может аутентифицировать- ся, поэтому мы предлагаем ему перезагрузить машину, но он по-прежнему не может соединиться. Это удаленный клиент, и мы не можем наблюдать за регистрацией пользователей. Что тогда делать? Можно сказать ему, что ма- машина не работает, и посоветовать отправить ее в корпоративный отдел ин- информационных технологий для эффективной проверки, вызвать сервисную компанию для ремонта машины или попробовать использовать Netmon. Мы просим пользователя перезагрузить машину еще раз и запускаем Netmon, когда слышим сигнал на другом конце телефонной линии. Когда пользователь сообщает, что он по-прежнему не работает, мы останавлива- останавливаем Netmon и звоним пользователю после анализа трассировки (что мы и собираемся сейчас сделать). Мы видим запрос DHCP и DHCP ACK в первых двух кадрах, поэтому проблема не в DHCP. Следующий кадр является ARP_RARP, это означает, что компьютер взял присвоенный ему адрес и послал запрос ARP для этого адреса. Таким образом, если другая машина имеет этот адрес, то будет обес- обеспечена сетевая ошибка двойного IP-адреса. Другое свойство ARP_RARP со- состоит в том, что машины, которые имеют старый IP-адрес в своем кэше ARP, будут автоматически обновлять свой кэш ARP, когда они получат за- запрос. В нашей трассировке мы не видим никакого ответа на ARP_RARP, поэтому это не проблема двойного IP-адреса. Затем идут два широковещательных сообщения регистрации NBT. Мы видим уникальное широковещание NTB для <00>, что является на компью- компьютере службой рабочей станции, а также широковещание NBT для <03>, со- содержащееся в распечатке ниже. Этот кадр является широковещанием в сети дейтаграмм UDP в 10.255.255.255. Это широковещание используется для службы имен NetBIOS для регистрации имени компьютера в службе рассылки. Как можно видеть в разделе класса записи, это уникальное имя NetBIOS. До сих пор все выглядит, как должно быть. Мы подтвердили, что это не проблема соединения, потому что взаимодействие выглядит нормально. UDP: Src Port: NETBIOS Name Service, A37); Dst Port: NETBIOS Name Service A37); Length = 76 @x4C) v. ;. UDP: Source Port = NETBIOS Name Service , . UDP: Destination Port = NETBIOS Name Service UDP: Total length = 76 @x4C) bytes UDP: UDP Checksum = 0xF520 UDP: Data: Number of data bytes remaining = 68 ¦v'' @x0044) NBT: NS: Registration req. for KENNY ^'"- ¦ ¦ <03> NBT: Transaction ID = 4 @x4) • + NBT: Flags Summary = 0x2910 - Req.; Registration; Success
Вопросы поиска неисправностей 279 NBT: Question Count = 1 (Oxl) NBT: Answer Count = 0 @x0) ¦ "'•" NBT: Name Service Count = 0 @x0) NBT: Additional Record Count = 1 @x1) ' • ¦' *' NBT: Question Name = KENNY <03> - ¦ ' <¦'¦"¦ NBT: Question Type = General Name Service ¦ ¦"'¦• •; NBT: Question Class = Internet Class ¦¦.-). ;> ..' ... NBT: Resourse Record Name = KENNY <03> NBT: Resourse Record Type = NetBIOS General Name Service NBT: Resourse Record Class = Internet Class NBT: Time To Live = 300000 @x493E0) •.. NBT: RDATA Length = 6 @x6) NBT: Resource Record Flags = 0 @x0) NBT: 0 = Unique NetBIOS Name NBT: .00 = В Node NBT: ...0000000000000 = Reserved NBT: Owner IP Address = 10.0.0.76 Следующий кадр решает проблему. Отметим запрос группы <00>, что яв- является именем домена. Именем домена, который ищет рабочая станция, бу- будет NETMO. Это неправильно. Это неверный домен. Посмотрим, что происходит в оставшейся части перехваченного файла. UDP: Src Port: NETBIOS Name Service, A37); Dst Port: NETBIOS Name Service A37); Length = 76 @x4C) UDP: Source Port = NETBIOS Name Service Destination Port = NETBIOS Name Service Total length = 76 @x4C) bytes UDP Checksum = 0x7A22 Data: Number of data bytes remaining = 68 UDP: UDP: UDP: UDP: @x0044) NBT: NS: NBT: + NBT: Success NBT: NBT: NBT: NBT: NBT: NBT: NBT: NBT: NBT: Service NBT: NBT: NBT: NBT: Registration req. for NETMO <00> Transaction ID = 2 @x2) Flags Summary = 0x2910 - Req.; Registration; Question Count = 1 @x1) , , Answer Count = 0 @x0) . , . , .¦ Name Service Count = 1 @x1) Additional Record Count = 1 @x1) Question Name = NETMO <00> Question Type = General Name Service Question Class = Internet Class Resource Record Name = NETMO <00> Resource Record Type = NetBIOS General Name Resource Record Class = Internet Class Time To Live = 300000 @x493E0) RDATA Length = 6 @x6) Resource Record Flags = 32768 @x8000) NBT: 1 = Group NetBIOS Name NBT: .00 = В Node
280 Глава 10 NBT: ...0000000000000 = Reserved NBT: Owner IP Address = 10.0.0.76 ' ": * Рабочая станция пытается теперь сделать широковещательный запрос netlogon с помощью дейтаграммы UDP в сеть 10.255.255.255. Она поступает из порта 138 службы дейтаграмм NetBIOS и направляется в порт 138 служ- службы дейтаграмм NetBIOS на машине места назначения. Имя источника опре- определяет Kenny, а имя пользователя administrator. Машина Kenny пытается найти \mailslot\net\netlogon для домена NETMO. IP: ID = 0x3100; Proto = UDP: Len: 253 . ..'' IP: Version = 4 @x4) . IP: Header Length =20 @x14) i ' + IP: Service Type = 0 @x0) r.:-> IP: Total Length = 253 (OxFD) IP: Identification = 12544 @x3100) + IP: Flags Summary = 0 @x0) t . IP: Fragment Offset = 0 @x0) bytes IP: Time To Live = 128 @x80) IP: Protocol = UDP - User Datagram \, •¦-'¦ ' IP: Checksum = 0xF3A5 ¦¦ . ;- ¦ . • : ¦ IP: Source Address = 10.0.0.76 ..-' '.' IP: Destination Address = 10.255.255.255 IP: Data: Number of data bytes remaining = 233 @x00E9) ¦¦""¦ UDP: Src Port: NETBIOS Datagram Service, A38); Dst Port: NETBIOS Datagram Service A38); Length = 233 @xE9) UDP: Source Port = NETBIOS Datagram Service UDP: Destination Port = NETBIOS Datagram Service Total length = 233 @xE9) bytes UDP Checksum = 0xlB3 5 Data: Number of data bytes remaining = 225 ¦¦¦•¦qi> UDP: UDP: UDP: (OxOOEl) NBT: DS: NBT: + NBT: NBT: NBT: NBT: NBT: NBT: NBT: NBT: NBT: @x008F) SMB + SMB: + SMB: Type =17 (DIRECT GROUP) Datagram Packet Type = DIRECT GROUP Datagram Flags = 2 @x2) Datagram ID = 26 @x8A) Source IP Address = 10.0.0.76 Source Port = 138 @x8A) Datagram Length = 211 @xD3) Packet Offset = 0 @x0) Source Name = KENNY <00> Destination Name = NETMO <00> DS Data: Number of data bytes remaining = 143 С transact, File = \MAILSLOT\NET\NETLOGON SMB Status = Error Success Header: PID = 0xl52F TID = OxFFFF MID = 0x0101 UID = OxFFFF + SMB: Command = С transact SMB: Data: Number of data bytes remaining = 51 @x0033)
Вопросы поиска неисправностей 281 ""' NETLOGON: LM1.0/2.0 LOGON Request from client NETLOGON: Opcode = LM1.0/2.0 LOGON Request from client NETLOGON: Computer Name = KENNY • - ••¦ NETLOGON: User Name = ADMINISTRATOR NETLOGON: Mailslot Name = \MAILSLOT\TEMP\NETLOGON NETLOGON: Request Count = 1 @x1) NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later) Networking Оставшаяся часть файла перехвата является повторением приведенных выше кадров, которые уже были рассмотрены. Потребовалось меньше часа для анализа перехваченных данных без доставки машины для осмотра и тес- тестирования. Мы звоним пользователю, чтобы он ввел правильное имя домена, и он входит в сеть. Встречаются редкие ситуации, когда приложение будет испорчено в такой степени, что нам придется серьезно покопаться, но когда необходимо про- просмотреть взаимодействие приложений, можно получить некоторые очень ин- интересные представления и решать сложные раздражающие проблемы достаточно просто. Странные ошибки журнала событий Иногда в окнах журнала возникают достаточно странные ошибки событий. Одной из них является событие ID 2000, которое просто говорит STATUS_NO_SUCH_FILE. Это событие происходит, когда сетевое прило- приложение посылает команду удаления файла на общий диск, а файл уже был удален. Словом, во второй строке раздела данных сообщения об ошибке будет cOOOOOOf, которое соответствует STATUS_NO_SUCH_FILE . Метод поиска серверных проблем Это проблема связана с SMB. Сначала рассмотрим файл перехвата. Чтобы упростить это, мы создали фильтр вывода, который показывает только команды SMB для удаления файла. На рис. 10.5 показано, как создается этот фильтр вывода. Находясь в режиме вывода, выберите фильтр из меню вывода (display). Сделайте двойной щелчок по строке протокола, и когда появится диалоговое окно выбора, отключите все протоколы. Выберите SMB из списка протоколов в правой панели диалогового окна, а затем щел- щелкните по кнопке включить (enable). Простым способом перейти в раздел "S" списка протоколов без прокручивания длинного списка является щел- щелчок по панели меню name и ввод "S". Это переместит вас в раздел "S", позво- позволяя быстро найти протокол SMB. Когда протокол SMB будет включен, нужно будет найти команду SMB delete. Чтобы сделать это, щелкните по за- закладке property. К сожалению, диалоговое окно недостаточно разумно, что- чтобы помнить, какой протокол был только что включен, и перед нами опять оказывается тот же самый список протоколов. Ввод "S" здесь не поможет, поэтому придется прокручивать список, пока не будет найден протокол SMB. Щелкните по знаку "плюс" рядом с SMB, и появится длинный список свойств протокола. Прокручивайте его, пока не сможете выбрать command
282 Глава 10 Expression Expiession SMB Command == 0x6 (delete We) PioiocotPiopetiy Relation Value (Byte) Byles Remaining in Rpe Caching mode Capabilities ¦-""¦¦¦ Capabilities Flags Change count ge Time A о contains exists |0x06 echo end message exit OK Cancel Help Hex С Oecimal Рис. 10.5. Конфигурируя фильтр вывода, усилия по выявлению неисправностей можно свести к очень узкой проблеме „ .¦ ¦.,,,: , ., ........г. ¦ ¦¦¦ . :. из диалогового окна. Когда command будет выбрана, появится список зна- значений. Прокручивайте Вниз, пока не сможете выбрать delete file, а затем нажмите ок. Этот фильтр вывода показывает теперь команды SMB delete любого компьютера. При просмотре кадров SMB delete мы ищем сообщение об ошибке. Рас- Рассмотрим взаимодействие. Клиентская машина посылает на сервер команду С delete file. Параметры включают расположение файла. SMB: С delete file, File = \PROGRAMS\TEMP\tmpl665.aud ~ + SMB: SMB Status = Error Success + SMB: Header: PID = 0xl4E5 TID = 0x0800 MID = 0x6701 UID = 0x0800 SMB: Command = С delete file '¦ SMB: Word count = 1 ' ¦ SMB: Word parameters ¦¦; + SMB: File Attributes = 6 @x6) : ,. •¦ ,. . SMB: Byte count = 55 . ., n , ... : SMB: Byte parameters SMB: File name = \PROGRAMS\TEMP\tmpl665.aud Ответ с сервера возвращается в следующем кадре и представлен в распе- распечатке ниже. Мы имеем команду R delete file с сообщением об отсутствии ошибок. Файл был успешно удален с сервера. SMB: R delete file + SMB: SMB Status = Error Success
Вопросы поиска неисправностей 283 + SMB: Header: PID = 0х14Е5 TID = 0x0800 MID = 0x6701 UID = 0x0800 SMB: Command = С delete file SMB: Word count = 0 SMB: Byte count = 0 Мы не смогли локализовать проблему в первом файле перехваченных данных. Понятно, что эту ошибку найти будет трудно. Можно помочь себе, создавая фильтр перехвата, чтобы перехватывать только один тип пакетов. Чтобы получить требуемую информацию, которая показана на рис. 10.6, мы должны найти шаблон и смещение, указывающее команду SMB delete. Чтобы сделать это, мы ищем такой кадр в фильтре вывода. Как можно ви- видеть на рис. 10.7, выбор в панели вывода командной строки SMB высвечи- высвечивает 06 в шестнадцатеричной панели в строке смещения 03. Просматривая строку статуса Netmon в нижнем правом углу, мы видим, что точное смеще- смещение равно Зе в шестнадцатеричном виде. Мы имеем теперь смещение и шаблон для фильтра перехвата команды delete SMB. Capture Filter 1 Add —SAP/ETYPE - Any SAP or Any ETYPE (Addiess Pairs) INCLUDE "ANY <•-> "ANY (Pattern Matches) Offset ОхЗЕ pattern = 0x0600 Pattern Match Qffset(inhex| Щ & Fiom Sjatt of Frame *"" Fiom ?nd of Topology Header -.— i Pattern... I P.R OK Cancel Help ¦; I Pattern |0S00 <* Hea ^ ASCII OK. Cancel Help Load... MOT Edit Linfi.. Delete —rf 4"» 1} Save... | Рис. 10.6. Фильтр перехвата, который фильтрует команды SMB delete и ослабляет проблему заполнения буфера перехвата Выполнение без сопровождения Мы получили намек из журнала событий на то, почему происходят серверные ошибки. Вооруженные этой информацией, мы можем теперь выполнить Netmon без сопровождения и спланировать его выполнение с помощью команды AT. Так как используется очень специализированный фильтр
284 Глава 10 ¦ IFAbookcap.U«b delete cap (Detail) MAC AddlDst MAC AddiProt 925 00A02474:>DS 0008C7569F9 SMB С delete file. File ¦ NPROGRAMS^TE)IP\t»pU6S aud 9 92S I0008C7569F9 DOA024742D5 11 185J00A024742DS 300вС?56! 11 1880008C7S69F9 00A024742D5 41 73900609777СВ6 COHPAQA63A3 41 74QCOMPAQA63A3 00609777СВ6 SSB SHB SHB sub SHB R delete tile С delete tile R delate file С delete file. R delete file Fill • File • \DOMAIM jlS <i _ _ .,..,,..,:.„,.„ ¦FRAKE Base irane properties ¦ETHERHET, ETYPE ¦ 0x0800 Protocol • IP DOD Internet Protocol ¦IP: ID • 0x3CA7. Proto ¦ TCP. len 136 ¦TCP AP len 96 seq 4284951-428S046. ack SW3901. vin 7882 src; U57 dst ¦NBT SS Session Kessage. len: 92 «SHE С delete file. File • 4PROGRAMSsTE)IPNt»pl665 aud . » ¦5MB SMB Status " Error Success i ¦ ,. ; т ¦SKB Header PIP ¦ OxHES TIP ¦ 0x0800 KIP • 0x6701 UID • 0x0800 ' SKB SHB ¦SKB SKB SKB SHB 4] 00000000 ooooooio 00000020 00000030 00000040 00000050 00000060 00000070 21 i Word count i Vord paraneters File Attributes Byte count • 55 Byte parameters File na&e 00 08 00 88 00 CE IE CA 00 00 00 00 SC 00 53 00 C7 3C 04 05 00 00 50 SC m 6 @x6) '!*" - \PROGRAHSvrEHP\t»pU$.S »ud 56 A7 85 93 00 oa 00 oo 9F 40 00 00 00 E5 52 54 92 00 8Б 00 80 14 00 00 00 20 00 00 00 00 4F 45 АО Db 41 00 00 08 00 00 24 06 62 00 00 01 47 4D 74 25 17 5C 00 67 00 00 2D 0B 03 FF 00 01 52 50 5A 00 8E 53 00 06 00 00 08 00 8D 4D 00 00 41 SC 00 D7 2D 42 00 37 00 oa 1 ' 45 0B 50 1 OO 00 18 ИЯ00 00 00 4D 74 00 114 00 00 - '•¦¦viOSr-T^E ><«# •/. * .* 4 i Ab Ai-P - о . s SME| . С .St. g , 7 n PR 0 0 R* H SnTEK?M ^twihei Dw lypc of SM8 operaiioo Fa \li ;OKC2(x3E) Рис. 10.7. С помощью тщательного анализа шестнадцатеричнои панели мы находим необходимую информацию для создания мощных фильтров перехвата перехвата и можно определить достаточно большой буфер перехвата, то можно позволить ему выполняться в течение достаточно длинного периода времени. Сеанс NETMON без сопровождения использование фильтра перехвата Netmon /autostart /buffersize 1024000 /capturefilter с:/smbdelete.cf /autostop ВВЕДИТЕ ПРИВЕДЕННЫЙ ВЫШЕ ТЕКСТ КОМАНДЫ В ТЕКСТОВЫЙ ФАЙЛ И СОХРАНИТЕ КАК ФАЙЛ .ВАТ Используйте службу планировщика для автоматизации процесса. На рис. 10.8 мы видим, как использовать службу планировщика для авто- автоматизации сеанса Netmon без сопровождения. Чтобы это работало, необ- необходимо запустить службу планировщика, используя апплет службы в управляющей панели. Когда он будет выполняться, мы переходим в окно CMD и вводим требуемую команду AT. В данном случае мы приказываем планировщику выполнить наш файл .bat с понедельника до пятницы в 5:00 после обеда. Приведенный выше файл .bat будет выполняться, пока буфер не заполнится, и затем остановится.
Вопросы поиска неисправностей 285 Рис. 10.8. Использование команды AT для автоматизации сеансов перехвата сетевого монитора -~ V -,-. ' Выполняя автоматический сеанс Netmon во время проявления сервер- серверной проблемы, мы имеем хорошую возможность найти неправильно рабо- работающую программу, которая пытается повторно удалить уже удаленный файл. Тщательно созданный фильтр перехвата сокращает беспорядок, кото- который необходимо расчистить, чтобы найти проблемное приложение. Когда сообщение об ошибке будет обнаружено, мы просто разрешаем адрес ис- источника в имя пользователя и находим, какая программа выполняется в то время, когда мы видим ошибку. Кроме того, можно включить просмотр времени при открытии файла перехвата и точно увидеть, какой кадр соот- соответствует определенному сообщению об ошибке в просмотрщике событий. Избыточное широковещание Широковещание всегда является хорошим объектом для мониторинга, так как заставляет все машины в подсети просматривать кадр. Это создает лишнюю работу для многих машин. Кроме того, когда возникает широко- широковещательный шторм, он оказывает разрушительное влияние на всю сеть. К счастью, эти проблемы легко обнаружить, как видно на рис. 10.9. Кажется, имеется какая-то проблема. Кто это делает? При рассмотрении трафика широковещания первый шаг состоит в созда- создании фильтра вывода широковещания, выбирающего все широковещатель- широковещательные сообщения в окне фильтра вывода. Когда это будет сделано, проверка широковещательных сообщений достаточно прямолинейна. Если возника- возникает широковещательный шторм, как на рис. 10.9, его легко обнаружить. Наиболее активному пользователю отчет может дать представление о том, как он повлиял на сеть. Пользователь на рис. 10.9 создал 93 процента
286 Глава 10 Nelwo.lt Hondo. - |G\o.co1.c«p (SuMunll -RelTiRe TSx НАС &ddr TSst НАС kddr (Protocol 82,938 О06ОО889БВС2 FFFFFFFFFFFF ARP.RARP ARP: Request, Target IP' 10 1 61 17? 23 25 27 2* 31 зг 31 34 23S 236 23? 2J8 23? 240 241 242 2<J 2<« 246 247 248 249 2S0 !2S1 !2S2 l2S3 |2S4 255 256 I?S? 258 259 92,938 82,939 82.»3S 82,939 02,539 вг.?4В 82.940 82 940 83,131 вз.т 83.131 83.131 83,131 63.131 «3.131 83.132 83.132 83.132 83.132 вздзг взлзг вэлзг 83.132 83.132 83.132 83,133 83.133 83.133 83.133 83.133 83.133 183.133 оовооввэввсг 00ьС08вЭВ8С2 006Ш89ВВС2 FFFFFFSTFFFF собоове-зввсг [Ю600889ВВС2 *0В 00600889ВВС2 МИ08в9ВВС2 00&008ОТВВС2 00600889ВВС2 0в?0в9ВС 0в08в9С2 OOSD0889BBC2 00600889ВВС2 0«в008в988С2 00600889ВВС2 о 00400889ШС2 00S80889BBC2 08600889БВС2 OOS00889BBC2 o ооеоевезввсг 0060038 »8К2 FFF?FFTF FFFFFTFFFFFF FFFFFFFFFFFF FFFFFFFFFFFF FBTFFFTFFFFF FFFFFFFFWFF _ ARP RASP ARPR4RP _ ASP ЙАЙР ARPIR4RP 4RF RARP ARP RASP MSP_R*RP 4BP EARP iBP 8ARP ASP RASP ARP HARP _ ARP BASF ARP_RARP ARP_R«iP AHP RARP ARP~RAi?P ARP~RAj?P arpZrarp AR? HASP ARP RAHP AEP~RARP ARPlRAHP ARP RASP ARP RARP ARP_RARP ARP RARP АИР: ARP: ARP; ARP; ARP: ARP: ARP. dRP ARP: ARP: ARP: ARP: ARP ARP ARP; ARP ARP: &RP' ARP: ABP: ARP: ARP: ARP ARP: ASP: ARP ARP. iRP *RP: ARP ARP ARP Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request Request .Request Request Request Request Target IP, Target IP: Target IP; Target IP: Target IP: Target IP: Target IP: Target IP: Target IP: Target IP: Target IP: Target IP; Target IP: Target IP: Target IP; Target IP; Target IP; Target IP: Target IP: Target IP: Target IP: Target IP: Target IP: Target IP: Target IP: Target IP; Target IP; Target IP; Target IP: Target IP: Target IP: Target IP; Target IP: 10.1 10.1. 10.1. 10.1. 10.1. 10.1, 10.1. 10.1. 10 1. 10.1 10 1. 10,1 10,1 10.1 10.1 io.г. 10,1. 10,1. ю.г. 10,1. юл. io.i. 10.1 юл 10.1 юл 10.1 10.i 10.1 10.1 io i ic : 61 w& SI.175 61.174 61.173 61.172 «1.171 61.170 61.169 61.168 61.H? 61,166 41.165 61,164 61.163 61.162 .61.161 . 61. Ш .61 Ш .61,158 .61.157 .61.156 .61.155 61 1S4 61 1S3 .61 1S2 .61.151 61 ISO 61,149 61.148 .61.147 .61.146 61 145 6».144 JABP Ptotocoi Sietnty Wo»al«jn ' IFs: JO Л «88 ' fo«. мьгТ (Qewci Рис. 10.9. Некоторые проблемы очень легко обнаружить трафика в относительно загруженной сети. Наверняка этому пользовате- пользователю казалось, что сеть тормозит, и он не подозревал о своей причастности к этой проблеме. Следующий пакет ARP показывает IP-адрес и адрес MAC вызывающей шторм машины. ARP_RARP: ARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: ARP_RARP: Request, Target IP: 10.1.61.176 Hardware Address Space = 1 @x1) Protocol Address Space = 2048 @x800) '" Hardware Address Length = 6 @x6) Protocol Address Length = 4 @x4) Opcode = 1 @x1) Sender's Hardware Address = 00600889BBC2 Sender's Protocol Address = 10.1.1.163 Target's Hardware Address = 000000000000 Target's Protocol Address = 10. 1.61.176 Frame Padding
Вопросы поиска неисправностей 287 Поиск имени пользователя Получить IP-адрес из кадра можно использовать ping -a 10.0.0.163 для получения имени хоста можно использовать агр -а для вывода кэша ARP можно использовать nbtstat -a 10.0.0.163 для получения таблицы имен NetBIOS удаленной машины Почему они это делают? Очевидно, что это вопрос, на который необходимо ответить, чтобы испра- исправить проблему. В краткосрочном периоде, вооружившись информацией, полученной при использовании различных утилит командной строки, пе- перечисленных выше, можно проследить машину и отключить ее в сети. Это определенно улучшит время ответа для других пользователей сети. Теперь, когда проблема не вызывает кризиса (и сопровождающих теле- телефонных звонков), есть время проанализировать ее. Необходимо исследо- исследовать машину и проверить, какое установлено программное обеспечение, какие протоколы загружены, а также вид используемого сетевого адаптера. Кроме того, необходимо посмотреть, существуют ли обновления для любо- любого из этих объектов — приложений, драйверов и т.д. Не забудьте проверить обновления встроенных программ самого компьютера. Так как мы обнаружили проблему, можно вернуться назад и рассмотреть некоторые предыдущие трассировки, чтобы также поискать в них широко- широковещательные сообщения. Возможно, что мы не выполняли фильтр широко- широковещания на предыдущих трассировках. Может быть, важно увидеть, как долго существовала проблема, чтобы получить данные, которые помогут при выявлении причин неисправности. Определив, когда возникла пробле- проблема, можно получить представление о том, что изменилось в тот день, что было добавлено, удалено или обновлено, т.е. что вызвало проблему. Просмотр Web-сайтов поставщика, которые поддерживают определен- определенную комбинацию, существующую на рассматриваемой машине. Перейдите в раздел Web-сайта, посвященный поддержке, и выполните запрос о широ- широковещании ARP для стартеров. Если это не поможет, то может оказаться полезным посещение групп новостей в Интернете и запрос о шторме ши- широковещания ARP. Конечно, прежде чем делать такой запрос, проверьте архив группы новостей, чтобы увидеть, сколько раз этот вопрос уже зада- задавался. Если это распространенная проблема, то, конечно, множество лю- людей уже встречали аналогичные симптомы. Возможно, вы обнаружите, что эта проблема была вызвана старой как мир программой Jet Admin, которая пыталась автоматически найти все принтеры в мире, используя ARP для за- запроса всего адресного пространства в сети в поисках всех не сконфигури- сконфигурированных принтеров. Это может показаться хорошей идеей, пока не поймешь, что существует почти 17000000 адресов хостов в сети класса А. Это достаточно большой объем широковещания. Реализованное исправле- исправление включало: загрузку последней версии программного обеспечения,
288 " Глава 10 поиск всех файлов, связанных со старой программой (она не имела про- программу деинсталляции), поиск реестра для удаления всех ссылок на старую программу, перезагрузку машины, проверку с помощью Netmon, не начала ли она снова широковещание, и, наконец, установку нового программного обеспечения. Обзор главы t В этой главе обсуждались некоторые общие вопросы соединения и спосо- способы использования Netmon во время поиска неисправностей. Были рассмот- рассмотрены ситуации, где можно делать ping сервера, но нельзя сделать net view на сервере. В этом сценарии Netmon нашел ошибку сеанса NBT, утвержда- утверждающую, что служба не существует на целевой машине. Затем была рассмот- рассмотрена ситуация, когда клиентская машина DHCP не могла получить выделенный адрес. Машина делала правильные запросы, но не получала никакого ответа, кроме отказа на запрос получить старый IP-адрес. После успешного разрешения этой проблемы мы обратились к старой как мир жа- жалобе о том, что сеть работает медленно. Используя экспертов Netmon 2, мы смогли определить, насколько сеть медленна, и использовали дополнитель- дополнительные утилиты, помогающие ослабить источник замедления. Наконец, мы решили проблему регистрации, внимательно проверяя, что именно ввел пользователь. Это помогло избежать дорогостоящего вызова сервисной службы независимой компании или трудностей и неудобств по доставке компьютера в отдел информационных технологий компании. В следующей главе •»¦ ,•««*•¦ • В следующей главе мы рассмотрим сетевую безопасность. Мы исследуем, как обнаружить и остановить незаконные серверы DHCP, используя Network Monitor версий 1.2 и 2.0. Мы проанализируем процесс перехвата данных и создание триггера перехвата и фильтра перехвата. Затем мы рассмотрим настройку монитора сервера Rogue DHCP с помощью Network Monitor 2.0, используя существующие утилиты управления монитором. Затем мы остановимся на идентификации неавторизованного сетевого анализатора с помощью Network Monitor версий 1.2 и 2.0. Мы проанализи- проанализируем шаблоны трафика, связанные с каждым из них, и сконфигурируем триггеры и фильтры перехвата. Мы рассмотрим использование утилит управления сетевым монитором для прекращения доступа неавторизован- неавторизованных сетевых анализаторов к сети и поймем, как можно реально помешать сетевому анализатору собирать данные.
Глава 11 Вопросы безопасности Вопросы безопасности всегда вызывают пристальное внимание у каждого сетевого администратора. Защита сети является одной из наиболее важных обязанностей сетевого администратора и одним из вопросов, которые постоянно задают консультантам. Нелегальные серверы DHCP Нелегальными серверами DHCP являются "левые" серверы, которые рас- располагаются в сети подобно минным полям, ожидая прибытия ничего не ожидающего компьютера. Хотя большинство этих инцидентов происходит по вине наивных пользователей или неопытных администраторов, сущест- существуют ситуации, когда играет роль саботаж. В любом случае эффект будет один и тот же — неограниченный хаос, так как коммуникация между ма- машинами начинает разрушаться. В этом сценарии будут один или два резуль- результата. "Левый" сервер DHCP раздает адреса, которые действительны для определенной области сети, приводя тем самым к дублированию IP- адресов. Когда это происходит, машина, имевшая IP-адрес дольше всех, обычно выиг- выигрывает, когда отвечает на ARP_RARP, посланный машиной, получающей ад- адрес. Новая машина должна затем освободить адрес. В таком сценарии новая машина неспособна общаться с другими компьютерами. Другой результат состоит в том, что нелегальный сервер DHCP раздает адреса, которые не- недействительны в сети, и новые машины неспособны общаться с кем-либо, кроме себя самой. Ни один из таких сценариев никого не устраивает. Есть ли у меня для вас адрес? Когда клиентская машина DHCP подключается к линии, она делает широ- широковещательный запрос DHCP. Этот запрос поступает в каждую машину в сети, так как имеет место назначения в Ethernet FFFFFFFFFFFF и место на- назначения в IP 255.255.255.255. Как можно видеть на распечатке ниже, дей- тограмма UDP направляется во все машины, которые слушают порт 67.
290 Глава 11 ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet „ Protocol ' ETHERNET: Destination address: FFFFFFFFFFFF ...... --¦ ETHERNET: 1 = Group address ETHERNET: 1. = Locally administered address ETHERNET: Source address : 00104BEC8DB2 ETHERNET: 0 = No routing information present RTHERNET: 0. = Universally Administered address ETHERNET: Frame Length : 342 @x0156) ETHERNET: Ethernet Type : 0x800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 328 @x0148) IP: ID = 0x0; Proto = UDP; Len: 328 IP: Version = 4 @x4) IP: Header Length =20 @x14) IP: Service Type = 0 @x0) IP: Precedence = Routing IP: ...0.... = Normal Delay 4! ' ' IP: ....0... = Normal Throughput ¦ •¦-.¦¦'.¦> " IP: 0.. = Normal Reliability '•' ' ' : IP: Total Length = 328 @x148) ;..¦•>. . < IP: Identification = 0 @x0) ¦ ¦:¦--. • ¦ ¦.. • . IP: Flags Summary = 0 @x0) IP: 0 = Last fragment in datagram IP: 0. = May fragment datagram if necessary IP: Fragment Offset = 0 @x0) bytes IP: Time to Live = 128 @x80) ' IP: Protocol = UDP - User Datagram "' " ' ' ; IP: Checksum = 0x39A6 -i^-v-i .•'.. -^ "'¦' IP: Source Address = 0.0.0.0 ' '¦'<'' IP: Destination Address = 255.255.255.255 ¦ ¦ ¦•¦ IP: Data: Number of data bytes remaining =3 08 @x0134) UDP: IP Multicast: Src Port: BOOTP Client, F8); Dst Port: BOOTP Server F7); Length = 308 @x134) UDP: Source Port = BOOTP Client UDP: Destination Port = BOOTP Server ' ' ' ' UDP: Total length = 308 @x134) bytes ' UDP: UDP Checksum = 0x78C3 UDP: Data: Number of data bytes remaining = 300 @x012C) DHCP: Discover (xid = 05D105D1) DHCP: Op Code (op) = 1 @x1) DHCP: Hardware Type (htype) = 1 @x1) 10Mb Ethernet DHCP: Hardware Address Length (hlen) = 6 @x6) DHCP: Hops (hops) = 0 @x0) DHCP: Transaction ID (xid) = 97584593 @x5D105Dl) DHCP: Seconds (sees) = 0 @x0)
Вопросы безопасности 291 Любая машина, которая слышит этот запрос, может ответить, посылая широковещательное сообщение UDP с портом места назначения 68. Это ши- широковещание IP в адрес 255.255.255.255. Любая машина, которая слышит предложение DHCP, может запросить адрес. ETHERNET: ETYPE = 0x0x0800 : Protocol = IP: DOD Internet Protocol IP: ID = 0xB71F; ProtO = UDP: Len: 328 IP: Version = 4 @x4) - Г • •'• : ¦ , .¦¦¦•• IP: Header Length = 20 @x14) : ¦' ¦¦¦;..¦:->'¦ ¦ V - • .^ .... + IP: Service Type = 0 @x0) . ¦ ¦•..> .:• IP: Total Length = 328 @x148) -;1 .. •• ,-.. ,<-. IP: Identification = 46879 @xB71F) . ...:,, ¦ + IP: Flags Summary = 0 @x0) . , .. . ,... ..... IP: Fragment Offset = 0 @x0) bytes ¦' , . IP: Time to Live = 128 @x80) IP: Protocol = UDP - User Datagram ' IP: Checksum =0x787B IP: Source Address =10.0.0.11 ¦ 1 ' IP: Destination Address = 255.255.255.255 IP: Data: Number of data bytes remaining =3 08 @x0134) UDP: IP Multicast: Src Port: BOOTP Server, F7); Dst Port: BOOTP Client F8); Length = 308 @x134) UDP: Source Port = BOOTP Server UDP: Destination Port = BOOTP Client ¦; UDP: Total length = 308 @x134) bytes UDP: UDP Checksum = 0x6D2F UDP: Data: Number of data bytes remaining =3 00 @x012C) DHCP: Offer (xid = 05D105D1) DHCP: Op Code (op) = 2 @x2) Hardware Type (htype) = 1 @x1) 10Mb DHCP Ethernet DHCP DHCP DHCP @x5D105Dl) DHCP: Seconds DHCP: Flags DHCP: DHCP: Client DHCP: Your DHCP: DHCP: DHCP: DHCP: DHCP: DHCP : DHCP: Hardware Address Length (hlen) = 6 @x6) @x0) Hops (hops) = 0 Transaction ID (xid) = 97584593 (sees) = 0 @x0) (flags) = 0 @x0) 0 = No Broadcast IP Address (ciaddr) = 0.0.0.0 IP Address (yiaddr) = 10.0.0.76 IP Address (siaddr) = 0.0.0.0 IP Address (giaddr) = 0.0.0.0 Server Relay Client Ethernet Address (chaddr) = 00104BEC8DB2 Server Host Name (sname) = <Blank> Boot File Name (file) = <Blank> Magic Cookie = [OK] Option Field (options) DHCP: DHCP Message Type = DHCP Offer '< DHCP: Subnet Mask = 255.0.0.0
292 Глава 11 ..; . . . ,, . DHCP: Renewal Time Value (Tl) = 1 Days, 12:00:00 . ... _. .,. DHCP: Rebinding Time Value (T2) = 2 Days, 15:00:00 DHCP: IP Address Lease Time = 3 Days, 0:00:00 DHCP: Server Identifier = 10.0.0.11 DHCP: Router =10.0.0.15 DHCP: Domain Name Server =10.0.0.10 DHCP: NetBIOS Name Service = 10.0.0.10 В связи с широковещательной природой протокола DHCP нелегальных серверов DHCP быть в сети не должно. Одним из способов управления рас- распространением серверов DHCP является конфигурирование триггера со смещением 2А и шаблоном, совпадающим с 0201. Он будет обнаруживать и сигнализировать о деятельности DHCP в сети. Затем можно будет исполь- использовать перехваченную информацию для отслеживания и удаления неавто- неавторизованных машин. Это не такой простой способ использования триггера для изолирования ответа только на нелегальные серверы DHCP. Этот подход проиллюстрирован на рис. 11.1 и допустим в программах Netmon версий 1.2 и 2.0. Для Netmon 1.2 существует также утилита управления монитором, ко- которая может быть сконфигурирована для создания события, когда она Capture Tiiqqer Trigger on С Nothing f Pattern match С Suffer space <~ Pattern match then buffer space (* Bu.f/ei space Ihen pattern match Buffer Space r с r 25% 50* 75* Pattern Offset (Hex): Pattern: |0201 <* From Start of Fiame С Ftom End of Jopology Header Hex ASCil T nggei Action <• Audible Signal Only Slop Capture Execute Command Line |C:\roguedhcp.bat Browse... I Cancel Help Рис. 11.1. Триггер сигнализирует администратору о присутствии DHCP
Вопросы безопасности 293 [ИДГПД31В JfPe IConliguip Hoquc Dili С ami WINS MofMoil 1 rUI> Rogue DHCP and WINS Monitor Configuration What do you want the Rogue DHCP and WINS monitor to do? <* Monitor for Rogue DHCP and WINS Servers <* Monitor for Rogue DHCP Servers <~ Monitor for Rogue WINS Servers Valid DHCP Addresses Valid WINS Addresses In the text box to the left, enter the IP Addresses of the computers that you expect to be sending DHCP Server messages on your network. These valid servers will be ignored by the monitor. In the text box to the left, enter the IP Addresses of the computers that you expect to be sending WINS Server messages on your network. These valid servers will be ignored by the monitor. Рис. 11.2. Утилита управления монитором сервера незаконного DHCP и WINS создает событие при обнаружении нелегальных серверов обнаруживает "левый" сервер DHCP. Она работает таким же образом, как и триггер, показанный на рис. 11.1, но имеются дополнительные воз- возможности узнать, какие серверы DHCP авторизованы, поскольку они были перечислены при конфигурировании нелегального монитора, как на рис. 11.2. Утилита управления монитором незаконного монитора DHCP также требует проверки событий и ничего не делает для неавторизованного сер- сервера. Лучшим подходом было бы инициирование пакетного файла, кото- который вызывает команду shutdown из набора ресурсов NT. Windows 2000 реализует широковещание DHCPINFORM в реализации DHCP, которая со- создана для проверки в активном каталоге, прежде чем обслуживать запросы от клиентов. Это широковещание происходит, даже если он не находит контроллер домена. Активный каталог будет продолжать зондировать DHCPINFORM каждые пять минут, даже если начнет выполняться сервер DHCP. Когда контроллер появляется в сети, то если сервер DHCP не был специально авторизован в активном каталоге, он будет прекращать работу как сервер DHCP.
294 Глава 11 . . -. Y-sv . *¦ .j.'. . *¦ ¦ ¦ *.\~ ¦or*'-;"*--'? "¦••'АЦГ..- ¦•¦¦.--'•Г1-.'- -.-¦¦¦¦'¦:¦* ¦¦•¦' "• -v^jtf^-- ¦-*'* Итак, где вы? ^-^ ^: .^. Получив сигнал о наличии нелегального сервера DHCP, можно просмот- просмотреть перехваченное предложение DHCP, найти идентификатор сервера, а затем, используя такие утилиты, как ARP и NBTSTAT, найти сервер и выключить его. DHCP: Offer ' (xid=05D105Dl) DHCP: Op Code (op) DHCP: Hardware Type (htype) DHCP: Hardware Address Length = 2 @x2) = 1 @x1) (hlen) = 6 = 0 @x0) = 97584593 = 0 @x0) = 0 @x0) 10Mb Ethernet @x6) @x5D105Dl) DHCP DHCP DHCP DHCP DHCP DHCP DHCP: Hops (hops) DHCP: Transaction ID (xid) DHCP: Seconds . (sees) DHCP: Flags ' (flags) DHCP: 0 = No Broadcast DHCP: Client IP Address (ciaddr) =0.0.0.0 DHCP: Your IP Address (yiaddr) = 10.0.0.76 ,Л, DHCP: Server IP Address (siaddr) = 0.0.0.0 -.'..' ¦. y. DHCP: Relay IP Address (giaddr) = 0.0.0.0 DHCP: Client Ethernet Address (chaddr) = 00104BEC8DB2 DHCP: Server Host Name (sname) = <Blank> DHCP: Boot File Name (file) = <Blank> DHCP: Magic Cookie = [OK] DHCP: Option Field (options) ¦ '• ¦¦¦ DHCP: DHCP Message Type = DHCP Offer — — DHCP: Subnet Mask = 255.0.0.0 DHCP: Renewal Time Vaqlue (Tl) = 1 Days, 12:00:00 Rebinding Time Value (T2) = 2 Days, 15:00:00 IP Address Lease Time = 3 Days, 0: Server Identifier = 10.0.0.11 Router = 10.0.0.15 Domain Name Server = 10.0.0.10 NetBIOS Name Service = 10.0.0.10 00:00 Нелегальный анализ сети ("вынюхивание") Во многих отношениях нелегальный анализ сети ("вынюхивание", англ. sniffing) является значительно большей угрозой безопасности, чем нелега- нелегальный сервер DHCP. Как мы видели в этой книге, с помощью Netmon и правильного понимания протоколов в незащищенной сети можно собрать информацию любого вида. Это включает возможность считывать данные, которые передаются по линиям связи, такие как почта POP и SMTP, паро- пароли Telnet, FTP, POP3 и многое другое. Чтобы проанализировать сеть, необ- необходимо иметь портативный компьютер, плату Ethernet в свободном (беспорядочном) режиме и незащищенное сетевое соединение. В течение очень короткого времени можно собрать достаточно информации, чтобы сделать сеть полностью неуправляемой.
Вопросы безопасности 295 Прежде всего необходимо их найти Netmon 1.2 имеет возможность непосредственно определять драйвер для анализаторов и агентов 1.2. Однако он может фильтровать кадры системы безопасности, которые посылает программа Netmon 2.O. Эти кадры систе- системы безопасности показаны на рис. 11.3. Используя смещение 00 и шаблон 030000000002, можно сконфигурировать фильтры вывода и триггеры для изоляции кадров системы безопасности. Это можно сделать в Network Monitor 1.2 и 2.0. ?>№ Е« loo's Qpfom Wndow Hcip Time [ Dst НАС Addr Prot Description 10 10. 20 11 30 11 40 12 SO.12 LOCAL LOCAL LOCAL LOCAL LOCAL 030000000002 030000000002 030000000002 030000000002 030000000002 Bone Bone Bone Bone Security Check @x03) Security Check @x03) Security Check @x03) Security Check @x03) Security Check @*03) J ¦Frame Base frame properties ¦ETHERNET 602 3 length • 197 ¦LLC UI DSAP-0x03 SSAP-0x02 С Bone Signature - RTSS Bone Command " Security Check @x0 3) Bone Flags • 0x00 52 54 53 53 0J 00 00 '30 00 00 A8 00 01 00 00 07 05 D7 95 SO 5j 4F 58 00 :s 4D 00 ВС F0 12 00 CF 90 35 00 41 64 tb 6? 6E 69 73 74 72 61 ?4 bF 72 00 00 00 10 00 00 00 12 11 00 75 1'3 ;3 04 |78 0C Fl 12 0C 01 00 00 00 00 90 27 64 FA [>•> 00 ISO 27 64 РЛ Ob 50 00 52 00 4F 00 5Э 00 00 00 28 100 4D 00 00 00 EC 00 Fu 00 12 00 00 00 CF 00 *0 lOJi 35 00 01 00 41 00 64 00 12 00 69 03 SE 00 b« 00 73 00 74 00 72 00 61 00 74 00 6F 00 72 00 00 '00 00 00 00 Ll(. 10 00 00 UU 00 00 00 05 1У 20 11 -E5 Adftjnistrat or x»f x ¦ E'd ¦ Vd *P ft О S l И +.' . - ?. 5 Ad in l ii l1 Рис. 11.3. Кадры системы безопасности Netmon 2.0 являются хорошей мишенью для триггера Сетевой монитор может также использовать свойство определения по- пользователей сетевого монитора из меню tools. Версия 2 продукта способна определить драйвер 1.2 и драйвер 2.0. Конечно, Netmon 1.2 может обнару- обнаружить только свой собственный драйвер. Инструмент Netmon 2.0 показан на рис. 11.4. Как отбить нюх чужим ищейкам Наиболее мощным решением проблемы нелегального анализа сети являет- является утилита управления сетевым монитором. Неавторизованная программа будет закрыта при попытке выполнения. Это актуально только для
296 Глава 11 Identify Network Monitor Users Total Instated 4 Total Running 3 Total Capturing. 0 Relresh Ust Г Add Names to Address Database OK Help Рис. 11.4. Network Monitor 2.0 может обнаружить свой собственный драйвер и драйвер 1.1 ¦ - - ¦ :-¦• ¦,"¦', ""v<. программы сетевого монитора версии 2. Netmon 1.2 будет выполняться без последствий. Чтобы определить его присутствие, используйте утилиту идентификации пользователей сетевого монитора. Обзор главы . -.,.,. В этой главе были рассмотрены некоторые вопросы безопасности сетей, протоколов и утилит, используемые для анализа. Были обсуждены пробле- проблемы, возникающие при бездумном запуске в сети сервера DHCP, и несколько методов обнаружения и удаления таких серверов. Мы также рассмотрели во- вопросы безопасности, касающиеся утилит сетевого монитора. Мы увидели, что наиболее мощным оружием, которое существует для защиты от атак анали- анализа сети, является использование анализатора для обнаружения и выключения нелегальных сетевых мониторов.
Приложение А Список общеизвестных номеров портов TCP и UDP Таблица АЛ. Общеизвестные номера портов TCP и UDP Десятичное значение O/tcp, udp 1/tcp, udp 2/tcp, udp 3/tcp, udp 4/tcp, udp 5/tcp, udp 6/tcp, udp 7/tcp, udp 8/tcp, udp 9/tcp, udp 10/tcp, udp 11/tcp, udp 12/tcp, udp 13/tcp, udp 14/tcp, udp 15/tcp, udp Зарезервированное слово tcpmux compressnet compressnet Че echo discard systat daytime Описание Зарезервировано Мультиплексор службы порта TCP Утилита управления Процесс сжатия Не используется Вход удаленного задания Не используется Эхо-сигнал Не используется Отбросить; алиас= sink null Не используется Активные пользователи; алиас = users Не используется Время дня Не используется Не используется [было netstat]
298 Таблица АЛ. Десятичное значение 16/tcp, udp 17/tcp, udp 18/tcp, udp 19/tcp, udp 20/tcp, udp 21/tcp, udp 22/tcp, udp 23/tcp, udp 24/tcp, udp 25/tcp, udp 26/tcp, udp 27/tcp, udp 28/tcp, udp 29/tcp, udp 30/tcp, udp 31/tcp, udp 32/tcp, udp 33/tcp, udp 34/tcp, udp 35/tcp, udp 36/tcp, udp 37/tcp, udp 38/tcp, udp 39/tcp, udp 40/tcp, udp 41/tcp, udp Приложение А Общеизвестные номера портов TCP и UDP (продолжение) Зарезервированное Описание слово qotd msp chargen ftp-data - •* ftp telnet smtp nsw-fe " msg-icp msg-auth dsp time rip graphics He используется Ссылка дня; алиас = quote Протокол отправки сообщений .. . Генератор символов; ^ , ^р *\ i .,' './¦ Ш алиас = ttytst source А$ ¦' $¦ *J * * ч T* Пересылка файлов * / .L С' [данные по умолчанию] Пересылка файлов [управление], диалоговое соединения Не используется Telnet Любая частная почтовая система SMTP; алиас = mail Не используется NSW User System FE _____ Z He используется MSGICP He используется Аутентификация MSG ¦ t. - . » He используется Протокол DSP (Display Support Protocol) He используется Любой частный принт-сервер Не используется Время; алиас = timeserver Не используется Протокол определения местоположения ресурсов (RLP); алиас = resource Не используется графика
Список общеизвестных номеров портов TCP и UDP 299 Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение) Десятичное Зарезервированное Описание ; ;,,- значение слово 42/tcp, udp 43/tcp, udp 44/tcp, udp 45/tcp, udp 46/tcp, udp 47/tcp, udp 48/tcp, udp 49/tcp, udp 50/tcp, udp 51/tcp, udp 52/tcp, udp 53/tcp, udp 54/tcp, udp 55/tcp, udp 56/tcp, udp 57/tcp, udp 58/tcp, udp 59/tcp, udp 60/tcp, udp 61/tcp, udp 62/tcp, udp 63/tcp, udp 64/tcp, udp 65/tcp, udp 66/tcp, udp 67/tcp, udp 68/tcp, udp 69/udp 70/tcp, udp nameserver nicname mpm-flags mpm mpm-snd ni-ftp i login i. • re-mail-ck la-maint xns-time domain xns-ch isi-gl xns-auth xns-mail ni-mail acas via-ftp I ' covia tacacs-ds .; . sql*net bootpc bootpc tftp gopher Сервер имен хостов; алиас = nameserver Who Is; алиас = nicname Протокол MPM FLAGS Модуль обработки сообщений MPM [отправка по умолчанию] NIFTP • Не используется Протокол хоста регистрации Протокол проверки удаленной почты Поддержка логического адреса IMP Протокол времени XNS Сервер имен доменов Центр обмена информацией XNS Графический язык ISI Аутентификация XNS Любой частный терминальный доступ Почта XNS Любая частная файловая служба Не используется NIMAIL Службы АСА VIA Systems - FTP Интегратор коммуникации (CI) Служба базы данных TACACS Oracle SQL*NET Сервер протокола DHCP/BOOTP Серве протокола DHCP/BOOTP Протокол TFTP Gopher " '
300 Приложение А Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение) Десятичное Зарезервированное Описание*. ¦ i •• .:><;;-: значение слово Служба удаленных заданий Служба удаленных заданий Служба удаленных заданий *''''¦¦'•' Служба удаленных заданий '$' Любая частная служба внешнего соединения > > - Не используется <, \'. !' Любая частная служба RJE Vettcp Finger WWW HTTP Сервер имен HOSTS2 УтилитаXFER !' ' ' ' Устройство MIT ML : ! ' Средство общей трассировки Устройство MIT ML ¦'¦'' '-'¦ Micro Focus Cobol J Любая частная терминальная линия; алиас = ttylink Kerberos Шлюз Telnet SU/MIT Шлюз Telnet SU/MIT Отображение маркера атрибута ' безопасности DNSIX '. MIT Dover Spooler • , '¦¦ Протокол сетевой печати Протокол управления устройством (DCP) Диспетчер объектов Tivoli SUPDUP Спецификация протокола DIXIE Протокол Swift удаленного виртуального файла 71/tcp, udp 72/tcp, udp 73/tcp, udp 74/tcp, udp 75/udp 76/tcp, udp 77/tcp, udp 78/tcp, udp 79/tcp, udp 80/tcp, udp 81/tcp, udp 82/tcp, udp 83/tcp, udp 84/tcp, udp 85/tcp, udp 86/tcp, udp 87/tcp, udp 88/tcp, udp 89/tcp 89/udp 90/tcp, udp 91/tcp, udp 92/tcp, udp 93/tcp, udp 94/tcp, udp 95/tcp, udp 96/tcp, udp 97/tcp, udp netrjs-1 netrjs-2 netrjs-3 netrjs-4 vettcp i finger www hosts2-ns xfer mit-ml-dev ctf mit-ml-dev mfcobol kerboros su-mit-tg su-mit-tg mit-gov npp dcp objcall siipdup dixie swift-rvf
Список общеизвестных номеров портов TCP и UDP 301 Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение) Десятичное Зарезервированное Описание ;¦¦ значение слово 98/tcp, udp 99/tcp, udp 100/tcp 101/tcp, udp 102/tcp, udp 103/tcp, udp 104/tcp, udp 105/tcp, udp 106/tcp, udp 107/tcp, udp 108/tcp, udp 109/tcp, udp 110/tcp, udp 111/tcp, udp 112/tcp,udp 113/tcp, udp 114/tcp, udp 115/tcp, udp 116/tcp, udp 117/tcp, udp 118/tcp, udp 119/tcp, udp 120/tcp, udp 121/tcp, udp tacnews metagram newacct hostname iso-tsap gppitnp acr-nema csnet-ns 3com-tsmux rtelnet snagas pop2 рорЗ sunrpc mcidas auth audionews sftp ansanotify uucp-path sqlserv •. i ¦ nntp cfdptkt erpc TAC News Metagram Relay [нелегальное использование] сервер имен хостов NIC; алиас = hostname ISO-TSAP Genesis Point-to-Point TransNet; алиас = webster ACR-NEMA Digital Imag. & Comm. 300 Сервер имен почтовых ящиков 3COM-TSMUX Удаленная служба Telnet Сервер доступа шлюза SNA Протокол POP (Post Office Protocol) - версия 2; алиас = postoffice Протокол POP (Post Office Protocol) - версия З; алиас = postoffice Вызов удаленной процедуры компании SUN Протокол передачи данных McIDAS служба аутентификации; алиас = authentication Многоадресная рассылка аудио-новостей Протокол SFTP (Simple File Transfer Protocol) ., ( ', ANSA REX Notify Служба путей доступа UUCP Службы SQL Протокол передачи сетевых . • \ • новостей; алиас = usenet CFDPTKT Encore Expedited Remote Pro.Call
302 Таблица АЛ. Общеизвестные номера Десятичное значение 122/tcp, udp 123/tcp, udp 124/tcp, udp 125/tcp, udp 126/tcp, udp 127/tcp, udp 128/tcp, udp 129/tcp, udp 130/tcp, udp 131/tcp, udp 132/tcp, udp 133/tcp, udp 134/tcp, udp 135/tcp, udp 136/tcp, udp 137/tcp, udp 138/tcp, udp 139/tcp, udp 140/tcp, udp 141/tcp, udp 142.tcp, udp 143/tcp, udp 144/tcp, udp 145/tcp, udp 146/tcp, udp 147/tcp, udp 148/tcp, udp 149/tcp, udp 150/tcp, udp 151/tcp, udp Приложение А портов TCP и UDP (продолжение) Зарезервированное Описание ... . r < слово smakynet ntp ansatrader locus-map „¦;¦ unitary - r locus-con ¦¦¦ gss-xlicen pwdgen cisco-fna cisco-tna cisco-sys statsrv ingres-net loc-srv profile „,..,.,.. netbios-ns netbios-dgm netbios-ssn emfis-data emfis-cntl bl-idm imap2 news uaac iso-ipO iso-ip ¦'¦ ¦ ¦ ¦¦ ¦"¦ cronus ; aed-512 sql-net hems SMAKYNET Протокол сетевого времени; ал и ас = ntpd ntp ANSA REX Trader Locus PC-Interface Net Map Server Unisys Unitary Login Locus PC-Interface Conn Server GSS X License Verification Протокол генерации протоколов Cisco FNATIVE Cisco TNATIVE Cisco SYSMAINT Служба статистики Служба INGRES-NET Служба места расположения Служба именования PROFILE Служба имен NetBIOS Служба дейтаграмм NetBIOS > Служба сеанса NetBIOS Служба данных EMFIS Служба контроля EMFIS Britton-Lee IDM Промежуточный протокол доступа к почте версии 2 newS; алиас = news Протокол UAAC ISO-IP0 ISO-IP CRONUS-SUPPORT AED 512 Emulation Service SQL-NET HEMS
Список общеизвестных номеров портов TCP и UDP 303 Таблица АЛ. Общеизвестные номера Десятичное значение 152/tcp, udp 153/tcp, udp 154/tcp, udp 155/tcp, udp 156/tcp, udp 157/tcp, udp 158/tcp, udp 159/tcp, udp 160/tcp, udp 161/tcp, udp 162/tcp, udp 163/tcp, udp 164/tcp, udp 165/tcp, udp 166/tcp, udp 167/tcp, udp 168/tcp, udp 169/tcp, udp 170/tcp, udp 171/tcp, udp 172/tcp, udp 173/tcp, udp 174/tcp, udp 175/tcp, udp 176/tcp, udp 177/tcp, udp 178/tcp, udp 179/tcp, udp 180/tcp, udp 181/tcp, udp портов TCP и UDP (продолжение) Зарезервированное Описание слово bftp sgmp netsc-prod netsc-dev sqlsrv knet-cmp '" pcmail-srv nss-routing sgmp-traps snmp snmptrap cmip-man cmip-agent xns-courier Z1 s-net | narap r i Ml' ¦¦) ¦ rsvd ... send print-srv multiplex , cl/1 :. xyplex-mux mailq vmnet genrad-mux xdmcp nextstep bgp h unify . • f 1 . . . '. Fl . 1. i ¦ Фоновая программа пересылки файлов SGMP; алиас = sgmp Netscape ' ' Netscape ' "':' служба SQL Протокол сообщений/команд KNET/VM Сервер PCMail; алиас = repository NSS-Routing SGMP-TRAPS r" ' '' SNMP; алиас = snmp "¦''' SNMPTRAP ' ; Менеджер CMIP/TCP Агент CMIP/TCP : ' Xerox ' ''i>:' " ;'- SiriusSystems "' n>)" ¦ ' : NAMP RSVD SEND \ ' . .. Network PostScript Network Innovations Multiplex Network Innovations CL/1 Xyplex MAILQ VMNET ' '_ '¦'¦ GENRAD-MUX X Display Manager Control Protocol NextStep Window Server Border Gateway Protocol Intergraph Unify
304 Приложение А Таблица A.I. Общеизвестные номера Десятичное значение 182/tcp, udp 183/tcp, udp 184/tcp, udp 185/tcp, udp 186/tcp, udp 187/tcp, udp 188/tcp, udp 189/tcp, udp 190/tcp, udp 191/tcp, udp 192/tcp, udp 193/tcp, udp 194/tcp, udp 195/tcp, udp 196/tcp, udp 197/tcp, udp 198/tcp, udp 199/tcp, udp 200/tcp, udp 201/tcp, udp 202/tcp, udp 203/tcp, udp 204/tcp, udp 205/tcp, udp 206/tcp, udp 207/tcp, udp 208/tcp, udp 209/tcp, udp 210/tcp, udp 211/tcp, udp портов TCP и UDP (продолжение) Зарезервированное Описание слово audit ocbinder ocserver remote-kis kis aci .... , mumps „. qft- . SacP я i v prospero osu-nms ,,-,-. srmp ire dn6-nlm-aud dn6-smm-red dls dls-mon smux sre at-rtmp at-nbp at-3 at-echo at-5 at-zis at-7 at-8 tarn z39.50 914c/g Unisys Audit SITP OCBinder OCServer Remote-KIS Протокол KIS Прикладной интерфейс коммуникации Plus Five's MUMPS Queued File Transport Gateway Access Control Protocol Prospero OSU Network Monitoring System Spider Remote Monitoring Protocol Internet Relay Chat Protocol DNSIX Network Level Module Audit DNSIX Session Mgt Module Audit Redir Directory Location Service Directory Location Service Monitor SMUX IBM System Resource Controller AppleTalk Routing Maintenance AppleTalk Name Binding AppleTalk Unused AppleTalk Echo AppleTalk Unused AppleTalk Zone Information AppleTalk Unused AppleTalk Unused Trivial Authenticated Mail Protocol ANSI Z39.50 Texas Instruments 914C/G Terminal
Список общеизвестных номеров портов TCP и UDP 305 Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение) Десятичное значение 212/tcp, udp 213/tcp, udp 214/tcp, udp 215/tcp, udp 216/tcp, udp 217/tcp, udp 218/tcp, udp 219/tcp, udp 220/tcp, udp 221/tcp, udp 222/tcp, udp 223/tcp, udp 224-241 243/tcp, udp 245/tcp, udp 246/tcp, udp 247-255 345/tcp, udp 346/tcp, udp 347/tcp, udp 371/tcp, udp 372/tcp, udp 373/tcp, udp 374/tcp, udp 443/tcp 512/tcp Зарезервированное Описание слово anet ipx vmpwscs softpc atls dbase mpp uarps imap3 fln-spx fsh-spx cdc sur-meas link dsp3270 pawserv zserv fatserv clearcase ulistserv legent-1 legent-2 ssl print ATEXSSTR IPX VM PWSCS Insignia Solutions Access Technology License Server dBASE UNIX Netix Message Posting Protocol Unisys ARPs Interactive Mail Access Protocol v3 Berkeley rloging with SPX Auth Berkeley rshd with SPX Auth Certificate Distribution Center Зарезервировано Survey Measurement LINK Display System Protocol Зарезервировано Perf Analysis Workbench Zebra Server Fatmen Server Clearcase UNIX Listserv Legent Corporation Legent Corporation Secure Sockets Layer, используется для предоставления защищенной коммуникации в Интернете Windows NT Server и Windows NT Workstation версии 4.0 могут посылать клиентские задания печати LPD из любого доступного зарезервированного порта между 512 и 1023. (См. также описание портов от 721 до 731.)
306 Приложение А Таблица АЛ. Общеизвеаные номера портов TCP и UDP (продолжение) Десятичное Зарезервированное Описание значение слово 512/udp 513/tcp 513/udp 514/tcp biff login who cmd 514/udp syslog 515/tcp, udp printer 517/tcp, udp talk 518/tcp, udp ntalk 519/tcp, udp utime 520/tcp efs Используется почтовой системой для уведомления пользователей . о новой полученной почте; в настоящее время получает : " сообщения только от процессов на том же компьютере; алиас = comsat Удаленный вход в систему, подобно telnet; выполняется автоматическая аутентификация на основе номеров привилегированных портов и распределенных баз данных, которые идентифицируют "домены аутентификации". Поддерживает базы данных, показывающие, кто зарегистриро- зарегистрировался на компьютерах в локальной сети, и среднюю нагрузку компьютера; алиас = whod Подобно exec, но выполняется автоматическая аутентификация, как для сервера входа в систему Спулер; алиас = spooler; (служба сервера печати LDP будет ожидать входящие соединения на порте tcp515) Подобно линии связи tenex, но между компьютерами; к сожалению не использует протокол линии связи. (Это в действительности просто порт рандеву, из которого создается соединение TCP) Unixtime Сервер расширенных имен файлов
Список общеизвестных номеров портов TCP и UDP 307 Таблица А.1. Общеизвестные номера портов TCP и UDP (продолжение) Десятичное Зарезервированное Описание •-.,> значение слово 520/udp router 525/tcp, udp 526/tcp, udp 530/tcp, udp 531/tcp 531/udp 532/tcp, udp 533/tcp, udp 540/tcp, udp 543/tcp, udp 544/tcp, udp 550/tcp, udp 555/tcp, udp 556/tcp, udp 560/tcp, udp 561/tcp, udp 562/tcp, udp 564/tcp, udp 565/tcp, udp 570/tcp, udp 571/tcp, udp 600/tcp, udp 607/tcp, udp 666/tcp, udp 704/tcp, udp timed tempo courier conference rvd-control netnews netwall uucp klogin kshell new-rwho dsf remotefs rmonitor monitor chshell 9pfs whoami meter meter ipcserver nqs mdqs elcsd Локальный процесс маршрутизации (на сайте); использует вариант информационного протокола маршрутизации Xerox NS; алиас = router routed Сервер времени Newdate RPC Chat MIT-disk Readnews Для аварийного широковещания Uucpd Krcmd; алиас = cmd New-who Сервер rfs; алиас = rfs_server rfs Rmonitord Chcmd Служба файлов Plan 9 Whoami Demon Udemon сервер IRC Sun Nqs Демон копии/сервера Errlog
308 Приложение А Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение) Десятичное значение Зарезервированное слово Описание 721-731 740/tcp, udp 741/tcp, udp 742/tcp, udp 744/tcp, udp 747/tcp, udp 748/tcp, udp 749/tcp, udp 750/tcp 750/udp 751/tcp, udp 752/tcp, udp 753/tcp, udp 758/tcp, udp 759/tcp, udp 760/tcp, udp 762/tcp, udp 763/tcp, udp 764/tcp, udp 765/tcp, udp 767/tcp, udp 769/tcp, udp printer netcp netgw netrcs flexlm fujitsu-dev ris-cm kerberos-adm rfile loadav pump qrh rrh 754/tcp, udp tell nlogon con ns quotad cycleserv omserv webster phonebook vid В Windows NT 3.5x все задания печати TCP/IP, посланные с компьютера Windows NT, посылаются из портов TCP с 721 по 731. (Это изменилось для Windows NT Server и Windows NT Workstation версии 4.0, которые посылают задания печати клиента LPD из любого доступного резервного порта между 512 и 1023.) NETscout Control Protocol NetGW Network based Rev. Cont. Sys. Flexible License Manager Fujitsu Device Control Russell Info Sci Calendar Manager Администрация Kerberos Аутентификация Kerberos; алиас = kdc Аутентификация Kerberos Сервер паролей Kerberos Сервер регистрации пользователей Kerberos Послать; подчиненное распространение Kerberos 761/tcp, udprxe Phone
Список общеизвестных номеров портов TCP и UDP 309 Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение) Десятичное значение Зарезервированное Описание слово 770/tcp, udp 771/tcp, udp 772/tcp, udp 773/tcp 773/udp 774/tcp 774/udp 775/tcp 775/udp 776/tcp, udp 780/tcp, udp 781 /tcp, udp 782/tcp, udp 783/tcp, udp 800/tcp, udp 801/tcp, udp 888/tcp, udp 996/tcp, udp 997/tcp, udp 998/tcp 998/udp 999/tcp 999/udp 999/tcp, udp 1000/tcp 1000/udp cadlock rtip cycleserv2 submit notify rpasswd acmaint_dbd entomb acmaint_transd wpages wpgs hp-collector hp-managed-node hp-alarm-mgr mdbs_daemon device erlogin xtreelic maitrd busboy puparp garcon applix puprouter cadlock ock ¦'!-.- V > .¦•¦...-'" Сборщик данных производительности HP Узел, управляемый данными производительности HP менеджер сигналов данных производительности HP Вход в систему и передача параметров среды XTREE License Server Applix ас
ПриложёниёВ (U . » ;А -,.. i¦¦¦¦'¦•-. Утилиты командной строки ¦'¦( !.l Таблица B.I. Полезные утилиты командной строки Утилита Модификаторы Описание ping ARP Nbstat -a «¦¦¦»<..."t>r -a . . ; -а удаленное_имя -А удаленный_1Р-адрес -с -n -R ' ' " '¦' '' '' " "Г .. .¦¦'¦.¦'¦."..¦"Л ¦ ! -s Netstat -а Используется для тестирования соедине- соединения между двумя 1Р-хостами. Используется для просмотра на компьюте- компьютере кэша ARP. Выводит удаленную таблицу имен NetBIOS. Выводит локальный кэш имен NetBIOS. Выводит локальные имена NetBIOS. Перезагружает файл LMHosts. Выводит статистику преобразования имен. Выводит сеансы клиента и сервера, перечисляя удаленные компьютеры только по IP-адресам. : •> Пытается преобразовать IP-адрес удаленного компьютера в имя, используя файл HOSTS. Выводит все соединения и принимающие порты. Выводит статистику Ethernet. Выводит статистику по протоколам. Выводит содержимое таблицы маршрутизации.
Утилиты командной строки 311 Таблица В.1. Полезные утилиты командной строки (продолжение) Утилита Модификаторы Описание telnet IP-адрес Используется для создания удаленного сеанса на другом хосте. Используется для поиска неисправностей. FTP Nslookup At Rcmd Netsvc Ipconfig IP-адрес IP-адрес сервера DNS и получающего хоста Время и команда Имя сервера /query/list/start/stop /all | more /release /renew Используется для пересылки файлов в Интернет. Используется для проверки разрешения DNS. Используется для планирования запуска программы в определенное время. Используется для выполнения удаленной команды на хосте. Используется для удаленной остановки, запуска, перечисления и запроса статуса определенной службы на определенном сервере. Используется для вывода IP конфигурации о локальном хосте. Освобождает IP-адрес. Обновляет IP-адрес.
Приложение С Общие NCP Таблица С.1. Общее распределение NCP Тип Поле Значение NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения 0x2222 23 29 0x2222 23 254 0x1111 0x5555 0x2222 24 0x2222 97 0x2222 23 31 0x2222 23 26 0x2222 23 19 0x2222 23 23 0x2222 23 27 0x2222 23 21 0x2222 19 0x2222 23 28 0x2222 23 22 Изменить состояние соединения Очистить номер соединения Создать служебное соединение Разрушить служебное соединение Конец задания Получить размер максимального пакета большого пакета NCP Получить список соединений от объекта Получить адрес IP Получить адрес IP (старый) Получить ключ регистрации Получить список соединений объекта Получить список соединений объекта (старый) Получить номер станции Получить информацию о зарегистрированной станции Получить информацию о зарегистрированной станции (старую)
Общие NCP 313 Таблица C.I. Общее распределение NCP Тип NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP соединения NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы Поле 0x2222 23 05 0x2222 23 02 0x2222 23 24 0x2222 23 20 0x2222 23 00 0x2222 25 0x2222 33 0x2222 101 0x9999 0x3333 0x2222 23 30 0x2222 22 39 0x2222 87 10 0x2222 22 13 0x2222 22 33 0x2222 22 18 0x2222 22 22 0x2222 22 19 0x2222 87 12 0x2222 66 0x2222 59 0x2222 23 244 0x2222 74 (продолжение) Значение Получить информацию о зарегистрированной станции (старую) Получить список соединений пользователя (старый) Регистрация объекта с ключом Объект регистрации Пользователь регистрации (старый) Выход из системы Согласовать размер буфера Пакет запроса соединения пакетной передачи (burst connection) Обрабатываемый запрос Обработанный запрос Задать интервал задержки сторожевой схемы Добавить расширенное доверительное множество к файлу или каталогу Добавить доверительное множество к файлу или подкаталогу Добавить доверительное множество к каталогу Добавить ограничение дискового пространства пользователя Выделить дескриптор постоянного каталога Выделить специальный дескриптор временного каталога Выделить дескриптор временного каталога Выделить короткий дескриптор каталога Закрыть файл Зафиксировать файл Преобразовать путь доступа в запись каталога Копировать из одного (Ьайла в лттой
314 Приложение С Таблица С.1. Общее распределение NCP (продолжение) Тип Поле Значение NCP файловой системы 0x2222 22 10 NCP файловой системы 0x2222 67 NCP файловой системы 0x2222 77 NCP файловой системы 0x2222 22 20 NCP файловой системы 0x2222 87 08 NCP файловой системы 0x2222 22 11 NCP файловой системы 0x2222 22 14 NCP файловой системы 0x2222 87 11 NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы 0x2222 68 0x2222 22 23 0x2222 90 150 0x2222 63 0x2222 62 0x2222 87 22 0x2222 71 0x2222 22 35 NCP файловой системы 0x2222 22 31 NCP файловой системы 0x2222 22 45 NCP файловой системы 0x2222 22 01 NCP файловой системы 0x2222 22 03 NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы 0x2222 87 29 0x2222 22 42 0x2222 22 51 0x2222 87 31 0x2222 87 28 NCP файловой системы 0x2222 87 26 Создать каталог Создать файл Создать новый файл Удалить дескриптор каталога Удалить файл или подкаталог Удалить каталог .: Удалить доверительное множество из каталога Удалить доверительное множество из файла или подкаталога Стереть файл Извлечь базовый дескриптор Запрос миграции файла , Продолжить поиск файла Инициализировать поиск файла Создать базу каталога и номер тома Получить текущий размер файла Получить ограничения дискового пространства каталога Получить запись каталога Получить информацию о каталоге Получить путь доступа каталога Получить действующие права каталога Получить действующие права каталога Получить действующие права записи каталога Получить расширенную информацию о томе Получить информацию о файле Получить строку полного пути доступа Получить информацию о Huge NS
Общие NCP Таблица C.I. Тип Общее распределение Поле NCP (продолжение) Значение 315 NCP файловой системы 0x2222 22 52 NCP файловой системы 0x2222 22 48 NCP файловой системы 0x2222 22 47 NCP файловой системы 0x2222 87 24 NCP файловой системы 0x2222 87 19 NCP файловой системы 0x2222 22 41 NCP файловой системы 0x2222 22 50 NCP файловой системы 0x2222 22 26 NCP файловой системы 0x2222 87 21 NCP файловой системы 0x2222 90 10 NCP файловой системы 0x2222 90 11 NCP файловой системы 0x2222 85 NCP файловой системы 0x2222 22 44 NCP файловой системы 0x2222 22 21 NCP файловой системы 0x2222 18 NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы 0x2222 22 06 0x2222 22 05 0x2222 87 02 0x2222 23 243 NCP файловой системы 0x2222 87 35 Получить список смонтированных томов Получить запись каталога пространства имен Получить информацию о пространстве имен Получить список загруженных пространств имен по номеру тома Получить информацию о NS Получить используемое дисковое пространство и ограничения объекта Получить действующие права объекта для записи каталога Получить имя пути доступа пары номеров том-каталог Получить строку пути доступа из короткого дескриптора каталога Получить счетчик ссылок из номера записи каталога Получить счетчик ссылок из дескриптора каталога Получить битовое отображение блоков данных фрагментированного файла Получить информацию о томе и удалении Получить информацию о томе с дескриптором Получить информацию о томе с номером Получить имя тома Получить номер тома Инициализировать поиск Отобразить номер каталога в путь доступа Изменить атрибуты DOS файла или подкаталога
316 Таблица Тип С.1. Общее распределение Поле NCP (продолжение) Значение Приложение С NCP файловой системы 0x2222 87 07 NCP файловой системы 0x2222 22 04 NCP файловой системы 0x2222 87 06 NCP файловой системы 0x2222 87 34 NCP файловой системы 0x2222 84 NCP файловой системы 0x2222 87 01 NCP файловой системы 0x2222 87 30 NCP файловой системы 0x2222 87 32 NCP файловой системы 0x2222 87 33 NCP файловой системы 0x2222 22 49 NCP файловой системы 0x2222 65 NCP файловой системы 0x2222 76 NCP файловой системы 0x2222 90 00 NCP файловой системы 0x2222 22 16 NCP файловой системы 0x2222 87 18 NCP файловой системы 0x2222 22 29 NCP файловой системы 0x2222 87 23 NCP файловой системы 0x2222 72 NCP файловой системы 0x2222 22 17 NCP файловой системы 0x2222 87 17 NCP файловой системы 0x2222 22 28 NCP файловой системы 0x2222 22 43 NCP файловой системы 0x2222 22 34 Изменить информацию DOS о файле или каталоге Изменить маску максимальных прав Получить информацию о файле или каталоге Открыть элемент управления CallBack (обратного вызова) Открыть/создать файл (старый) Открыть/создать файл или подкаталог Открыть/создать файл или подкаталог Открыть/создать файл или подкаталог с помощью CallBack Открыть/создать файл или подкаталог II с помощью CallBack Открыть поток данных Открыть файл (старый) Открыть файл (старый) Выполнить синтаксический разбор дерева Удалить стертые файлы (старый) Удалить утилизируемый файл Удалить утилизируемый файл (старый) Запросить формат информации NS Прочитать из файла Восстановить стертый файл (старый) Восстановить утилизируемый файл Восстановить утилизируемый файл (старый) Удалить расширенное доверительное множество из каталога или файла Удалить ограничение дискового пространства пользователя
Общие NCP 317 Таблица C.I. Общее распределение NCP (продолжение) Тип Поле Значение NCP файловой системы 0x2222 22 15 NCP файловой системы 0x2222 69 NCP файловой системы 0x2222 22 46 NCP файловой системы 0x2222 87 04 NCP файловой системы 0x2222 22 24 NCP файловой системы 0x2222 22 30 NCP файловой системы 0x2222 22 40 NCP файловой системы 0x2222 22 12 NCP файловой системы 0x2222 22 02 NCP файловой системы 0x2222 23 15 NCP файловой системы 0x2222 22 38 NCP файловой системы 0x2222 87 05 NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы 0x2222 87 16 0x2222 22 27 0x2222 22 32 0x2222 64 0x2222 87 03 0x2222 87 20 0x2222 90 12 0x2222 22 36 Переименовать каталог Переименовать файл Переименовать или переместить (старый) Переименовать или переместить файл или подкаталог Восстановить извлеченный базовый дескриптор Просканировать каталог Просканировать дисковое пространство каталога ' Просканировать каталог для выявления доверительного множества Просканировать информацию о каталоге Просканировать информацию о файле Просканировать файл или каталог для выявления расширенного доверительного множества Просканировать файл или каталог для выявления доверительного множества Просканировать утилизируемые файлы Просканировать утилизируемые файлы (старый) Просканировать ограничения тома диска пользователя. Искать файл Искать файл или каталог Искать множество файлов или подкаталогов Задать размер сжатого файла Задать ограничение дискового пространства каталога
318 Приложение С Таблица С.1. Общее распределение NCP (продолжение) Тип Поле Значение NCP файловой системы 0x2222 22 37 NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы NCP файловой системы 0x2222 22 00 0x2222 22 25 0x2222 70 0x2222 79 0x2222 23 16 0x2222 75 NCP файловой системы 0x2222 87 27 NCP файловой системы 0x2222 87 25 NCP файловой системы 0x2222 87 09 NCP файловой системы NCP печати NCP печати NCP печати NCP печати NCP печати ;:.. • NCP печати NCP печати ; : NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью 0x2222 73 0x2222 17 01 0x2222 17 09 0x2222 17 06 0x2222 1710 0x2222 17 02 0x2222 17 03 0x2222 17 00 0x2222 23 132 0x2222 23 115 0x2222 23 111 0x2222 23 130 0x2222 23123 0x2222 23 109 0x2222 23 110 Задать информацию о записи каталога Задать дескриптор каталога Задать информацию о каталоге Задать атрибуты файла . . ., < / Задать расширенный атрибут файла Задать информацию о файле Задать для файла отметку времени и даты Задать информацию Huge NS >¦ Задать информацию NS Задать короткий дескриптор каталога Записать в файл .,..., Закрыть файл спулинга Создать файл спулинга , , :/, Получить статус принтера Получить очередь принтера ' Задать флаги файла спулера Загрузить в спулер дисковый файл Записать в файл спулера Прервать обслуживание задания очереди ¦ ''' Прервать обслуживания задания очереди (старый) Присоединить сервер очереди к очереди : !/ Изменить приоритет задания Изменить запись задания очереди Изменить запись задания очереди (старый) Изменить позицию задания очереди
Общие NCP 319 Таблица C.I. Общее распределение NCP (продолжение) Тип Поле Значение NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью 0x2222 23 133 Изменить на права клиента , . 0x2222 23 116 Изменить на права клиента (старый) 0x2222 23 127 Закрыть файл и запустить задание очереди 0x2222 23 105 Закрыть файл и запустить задание очереди (старый) 0x2222 23 100 Создать очередь 0x2222 23 121 Создать задание очереди и файл 0x2222 23 104 Создать задание очереди и файл (старый) 0x2222 23 101 Разрушить очередь 0x2222 23 112 Отсоединить сервер очереди от очереди 0x2222 23 131 Закончить обслуживание задания очереди 0x2222 23 114 Закончить обслуживание задания очереди (старый) 0x2222 23 135 Получить размер файла задания печати 0x2222 23 120 Получить размер файла задания печати (старый) 0x2222 23 129 Получить список заданий печати 0x2222 23 107 Получить список заданий печати (старый) 0x2222 23 137 Получить задания печати из списка форм 0x2222 23 136 Переместить задание очереди из источника Q в место назначения Q, 0x2222 23 125 Прочитать текущий статус очереди 0x2222 23 102 Прочитать текущий статус очереди (старый)
320 Таблица С.1. Общее Тип NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCP управления очередью NCPRPC NCP RPC NCPRPC NCP RPC NCPRPC NCP RPC NCP RPC распределение NCP Поле 0x2222 23 122 0x2222 23 108 0x2222 23 134 0x2222 23 118 0x2222 23 128 0x2222 23 106 0x2222 23117 0x2222 23 124 0x2222 23113 0x2222 23138 0x2222 23 126 0x2222 23 103 0x2222 23 119 0x2222 131 05 0x2222 131 04 0x2222 131 07 0x2222131 01 0x2222 131 03 0x2222 131 06 0x2222 131 02 Приложение С (продолжение) Значение Прочитать запись задания очереди Прочитать запись задания очереди (старый) Прочитать текущий статус сервера очередей Прочитать текущий статус сервера очередей (старый) Удалить задание из очереди Удалить задание из очереди ¦ (старый) Восстановить права сервера очередей Обслужить задание печати Обслужить задание печати (старый) Обслужить задание печати списком форм Задать текущий статус очереди Задать текущее состояние очереди (старый) Задать текущее состояние сервера очередей RPC "добавить пространство имен к тому" RPC "размонтировать том" RPC "выполнить файл NCF" RPC "загрузить NLM" RPC "смонтировать том" RPC "задать значение команды" RPC "Выгрузить NLM"
Приложение D Поиск обычных сетевых ошибок В этом приложении рассматриваются некоторые из наиболее распростра- распространенных ошибок и предлагаются методы их решения. Короткие/длинные кадры Короткими называют кадры, которые были преждевременно завершены. Они обычно возникают, когда сквозной коммутатор пересылает кадры, ко- которые столкнулись с конфликтами в сегменте источнике. Длинный кадр возникает, когда конец одного кадра и начало другого не четко определе- определены. Это может происходить, когда диаметр коллизионного домена превы- превышает спецификацию. Ошибки CRC или FCS Любое искажение кадра может приводить к ошибке контроля циклическо- циклического избыточного кода — CRC (называемой также ошибкой контрольной последовательности кадра). Передающий NIC выполняет вычисление на заголовке кадра и поле данных. Результат вычисления хранится в четырех байтах после поля данных. Когда кадр достигает места назначения, вы- выполняются те же самые вычисления и результат сравнивается с четы- рехбайтным полем. Несовпадение называется ошибкой CRC или FCS. Иска- Искажение может быть результатом плохо соединенных разъемов или кабелей, использования кабеля cat 3 для 100 Мбит/сек Ethernet, источников электро- электромагнитного шума, например трансформаторов и электромоторов, располо- расположенных возле кабеля UTP, исходящих кабелей, превышающих 100 метров, и множества других причин.
322 Приложение D Конфликты Конфликты вызываются наложением передач, в связи с двумя или большим числом NIC, посылающих пакеты одновременно. Конфликты могут про- происходить, если различные NIC решают передавать почти одновременно, так как ничего не слышат в сети в данный момент. Все пакеты, вовлеченные в конфликт, потеряны и автоматически передаются повторно. Поздние конфликты yg.^-ы-* -, v-.•-.,,¦*¦ r%Jt Обнаружение конфликта после того, как были переданы первые 64 байта пакета. NIC, определяющий поздний конфликт, проходит через обычные помехи CSMA/CD, ожидание и повтор, но также увеличивает счетчик поздних конфликтов. Опасность состоит в том, что пакеты, близкие по длине к 64 байтам, могут быть переданы до обнаружения конфликта и не передаваться NIC повторно. Это заставляет компьютер ожидать, пока другой конец не ответит должным образом, и затем повторить. Это может потре- потребовать нескольких секунд или даже вызвать закрытие соединения. Причи- Причиной поздних конфликтов является сеть, которая превышает ограничения синхронизации стандарта IEEE 802.3.
Приложение Е Суффиксы NetBIOS Таблица ЕЛ. Суффиксы NetBIOS Название <имя компьютера> <имя компьютера> <\\-_MSBROWSE_> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> Номер(Ьех) 0 1 1 3 6 IF 20 21 22 23 24 30 31 43 44 45 Тип и и G и и и и и и и и и и и и и Применение Служба рабочей станции Служба рассылки Мастер-броузер Служба рассылки Служба сервера RAS Служба NetDDE Служба сервера файлов Служба клиента RAS Microsoft Exchange Interchange (MSMail Connector) Microsoft Exchange Store Microsoft Echange Directory Служба сервера общего использования модема Служба клиента общего использования модема Удаленное управление клиентами SMS удаленные администраторы SMS Удаленный чат клиентов SMS
324 Приложение Е Таблица ЕЛ. Суффиксы NetBIOS (продолжение) Название <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя компьютера> <имя пользователя> <домен> <домен> <домен> <домен> <домен> <службы — INet> <IS — имя компьютера> <имя-компьютера> IRISMULTICAST IRISNAMESERVER Forte_$ND800ZA Номер(Ьех) 46 4С 52 87 6А BE BF 3 0 IB 1С ID IE 1С 0 [2B] [2F] [33] [20] Тип и и и и и и и и G и G и G G и и G G и Применение Удаленная передача клиентов SMS Служба TCPIP Pathworks DEC на Windows NT Служба TCPIP Pathworks DEC на Windows NT Microsoft Exchange MTA Microsoft Exchange IMC Агент сетевого монитора Приложение сетевого монитора Служба рассылки Имя домена Мастер-броузер домена Контроллеры домена мастер-броузер Выборы службы броузера IIS IIS Служба сервера Lotus Notes Lotus Notes Lotus Notes Служба сервера Gateway DCA IrmaLan
Приложение F Запуск контроллера домена Таблица F.I. Запуск контроллера домена Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения 67.409 2400 67.467 Ргох 67.468 2400 4 67.823 2400 5 68.823 2400 6 71.283 Ргох 7 72.727 2400 ¦BROADCAST DHCP ¦BROADCAST DHCP ¦BROADCAST ARP RARP ¦BROADCAST ARP RARP ¦BROADCAST ARP RARP ¦BROADCAST BROWSER ¦BROADCAST ARP RARP Запрос (xid=2BlD7FEF) ACK (xid=2BlD7FEF) ARP: Запрос, IP получения: 10.0.0.60 ARP: Запрос, IP получения: 10.0.0.60 ARP: Запрос, IP получения: 10.0.0.60 Объявление рабочей группы [0х0с] MRED ARP: Запрос, IP получения: 10.0.0.10
326 Приложение F Таблица F.I. Запуск контроллера домена (продолжение) Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения ¦ 8 72.728 Ргох 2400 ARP_RARP 9 72.728 2400 10 74.214 2400 11 75.714 2400 12 77.246 2400 13 77.996 2400 14 78.746 2400 15 79.496 2400 16 84.313 Ргох 17 87.283 2400 18 88.028 2400 19 88.778 2400 20 89.528 2400 Ргох Ргох Ргох NBT NBT NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦NETBIOS Mu- BROWSER licast ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ARP: Ответ, IP получения: 10.0.0.60, аппаратный адрес получения 00902764FEBF NS: Запрос регистрации 2400 <00> NS: Запрос регистрации 2400 <00> NS: Запрос регистрации ; ' 2400 <00> NS: Запрос регистрации 2400 <00> > NS: Запрос регистрации 2400 <00> NS: Запрос регистрации 2400 <00> NS: Запрос регистрации 2400 <00> Объявление MRED [ОхОс] рабочей группы NS: Запрос регистрации 2400 NS: Запрос регистрации 2400 NS: Запрос регистрации 2400 NS: Запрос регистрации 2400
Запуск контроллера домена 327 Таблица F.I. Запуск контроллера домена (продолжение) Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения 21 90.284 2400 22 90.308 2400 23 91.044 2400 24 91.794 2400 25 92.544 2400 26 93.295 2400 27 94.044 2400 28 94.794 2400 29 95.544 2400 30 96.297 2400 31 96.462 2400 32 96.462 Ргох 33 96.462 2400 34 96.463 Ргох ¦BROADCAST BROWSER ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST BROWSER ¦BROADCAST NBT 2400 Prox 2400 NBT NETLOGON NETLOGON Объявление хоста [0x01] 2400 NS: Запрос регистрации MRED <00> NS: Запрос регистрации MRED <00> NS: Запрос регистрации MRED <00> NS: Запрос регистрации MRED <00> NS: Запрос регистрации MRED <1C> NS: Запрос регистрации MRED<1C> NS: Запрос регистрации MRED <1C> NS: Запрос регистрации MRED <1C> Объявление хоста 2400 [0x01] NS: Запрос MRED <1B> NS: Запрос (статуса узла) главным образом MRED <1B>, успех Запрос первичного DC Ответ на первичный
328 Приложение F Таблица F.I. Запуск контроллера домена (продолжение) Кадр 35 36 37 38 39 40 41 42 43 44 45 Время 96.491 96.491 96.492 96.492 96.492 96.493 96.497 96.508 96.509 96.51 96.513 Адрес MAC источника 2400 Ргох 2400 2400 Ргох 2400 Ргох 2400 Ргох 2400 Ргох Адрес MAC назначения Ргох 2400 Ргох Ргох 2400 Ргох 2400 Ргох 2400 Ргох 2400 Протокол TCP TCP TCP NBT NBT SMB SMB SMB SMB SMB SMB Описание ....S., len: 4, seq: 78400-78403, ack:0, win: 8192, src:1025dst: 139 (сеанс NBT) .A..S., len: 4, seq: 171256-171259, ack: 78401, win: 8760, src: 139 (сеанс NBT) .A...., len: 0, seq: 78401-78401, ack: 171257, win: 8760, src: 1025 dst: 139 (сеанс NBT) SS: Запрос сеанса, назначение: PROX, источник: 2400 <00>, Len: 68 SS: Положительный ответ на сеанс, Len:0 С Negotiate, Dialect = NT LM 0.12 R Negotiate, Dialect # = 7 С Session Set-up & X, Username =, and С Tree Con- Connect & X, Share = \\PROX\IPC$ R Session Set-up & X, and R Tree Connect & X, Type = IPC С NT create &X, File=\NETLOGON R NT create &X, FID = 0x807
Запуск контроллера домена 329 Таблица F.I. Запуск контроллера домена (продолжение) Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения 46 96.513 2400 Ргох 47 96.518 Ргох 48 96.518 2400 49 96.519 Ргох 50 96.52 2400 51 96.53 Ргох 52 96.531 2400 53 96.532 TERESA 54 96.587 2400 55 96.658 2400 56 96.661 Ргох 2400 Ргох 2400 Ргох 2400 MSRPC с/о RPC Bind: UUID 12345678-1234-АВ CD-EF00-0123456 7CFFB call 0x1 assoc grp 0x0 xm MSRPC с/о RPC Bind Ack: call 0x1 assoc grp 0xl9D9Bxmit 0x1630 recv 0x1630 RJLOGON RPC Client Call Logon: NetrServer ReqChallenge(..) R_LOGON RPC Server Response Logon: NetrServerReq Challenge^.) R LOGON R_LOGON RPC Client Call Logon: NetrServer Authenticate2(..) RPC Server Response Logon: NetrServer Authenticate2(..) NS: Query Req. ForNETMON ¦BROADCAST NBT ¦BROADCAST ARP_RARP ARP: Request, Target IP: 10.0.0.60 ¦BROADCAST BROWSER Prox 2400 SMB SMB Объявление хоста [0x01] 2400 С NT Create &X, File = \NETLOGON R NT Create &X, FID = 0x808
330 Приложение F Таблица F.I. Запуск контроллера домена (продолжение) Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения 57 96.662 2400 Ргох MSRPC 58 96.664 Ргох 2400 MSRPC 59 96.667 2400 60 96.67 Ргох 61 96.675 2400 62 96.678 Ргох 63 96.683 2400 64 96.687 Ргох 65 96.782 2400 Ргох 2400 Ргох 2400 Ргох 2400 R_LOGON R_LOGON R_LOGON R LOGON R LOGON R LOGON ¦BROADCAST NBT c/o RPC Bind: UUID 12345678-1234-AB CD-EFOO-0123456 7CFFB call 0x0 assoc grp 0xl9D9B c/o RPC Bind Ack: Call 0x0 Assoc grp 0xl9D9Bxmit 0x1630 recv 0x1630 RPC Client Call Logon: NetrData- baseDeltas(..) RPC Server Response Logon: NetrDatabase Deltas (..) RPC Client Call Logon: Netr DatabaseDel tas (..) RPC Server Response Logon: NetrDatabase Delatas(..) RPC Client Call Logon: Netr DatabaseDeltas(..) RPC Server Response Logon: NetrDatabase Deltas (..) NS: Запрос регистрации MRED <1E>
Запуск контроллера домена 331 Таблица F.I. Запуск контроллера домена (продолжение) Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения 66 96.81 2400 Ргох TCP 67 96.91 2400 68 97.372 2400 69 97.374 Ргох 70 97.529 2400 71 97.654 2400 72 98.201 2400 73 98.279 2400 74 98.404 2400 75 98.951 2400 76 99.029 2400 77 99.156 2400 ¦BROADCAST NBT Ргох 2400 NETLOGON NETLOGON *BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT ¦BROADCAST NBT .A...., len: 0, seq: 80511-80511, ack: 172694, win: 7323, src: 1025 dst: 139 (NB) NS: Запрос регистрации 2400 <03> Запрос первичного DC Ответ на первичный запрос NS: Запрос регистрации MRED <1Е> NS: Запрос регистрации 2400 <03> NS: Запрос регистрации 2400++++++++++++ NS: Запрос регистрации MRED <1Е> NS: Запрос регистрации 2400 <03> NS: Запрос регистрации 2400++++++++++++ NS: Запрос регистрации MRED <1E> NS: Запрос регистрации 2400 <03>
332 Приложение F Таблица F.I. Запуск контроллера домена (продолжение) Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения 78 99.701 2400 79 99.785 2400 80 81 99.79 99.79 Ргох Ргох 82 99.92 2400 83 99.92 Ргох 84 99.92 2400 85 99.92 2400 86 99.92 Ргох 87 99.922 2400 88 99.922 Ргох ¦BROADCAST ¦BROADCAST ¦NETBIOS Multicast ¦BROADCAST Ргох 2400 Ргох Ргох 2400 Ргох 2400 NBT BROWSER BROWSER BROWSER TCP TCP TCP NBT NBT SMB SMB NS: Запрос регистрации 2400++++++++++++ Запрос объявления [0x02] Объявление локального мастера [OxOfj PROX Объявление локального мастера [0x0f] PROX ....S., len: 4, seq: 81842-81845, ack: 0, win: 8192, src: 1028 dst: 139 (NB) .A..S., len: 4, seq: 171273-171276, ack: 81843, win: 8760, src: 139 (сеанс NBT) .A...., len: 0, seq: 81843-81843, ack: 171274, win: 8760, src: 1028 dst: 139 (NB) SS: Запрос сеанса, Dest: PROX, Source: 2400 <00>, Len: 68 SS: Положительный ответ сеанса, Len:0 С Negative, Dialect = NT LM 0.12 R Negative, Dialect # = 7
Запуск контроллера домена 333 Таблица F.I. Запуск контроллера домена (продолжение) Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения 89 99.923 2400 Ргох 90 99.923 Ргох 91 99.924 2400 92 99.927 Ргох 93 99.928 2400 94 99.929 Ргох 95 100.094 2400 2400 Ргох 2400 Ргох 2400 Ргох 96 100.123 2400 97 100.123 Ргох Ргох 2400 98 100.124 2400 Ргох SMB SMB SMB SMB SMB SMB TCP TCP TCP TCP С Session Set-up & X, Username=, and С tree Con- Connect & X, Share = \\PROX\IPC$ R Session Set-up & X, and R Tree Connect & X, Type = IPC С Transact, Remote API R Transact, Remote API (ответ на кадр 91) С transact, Remote API R transact, Remote API (ответ на кадр 93) .A...., len: 0, seq: 82509-82509, ack: 171796, win: 8238, src: 1028 dst: 139 (NB) ....S., len: 4, seq: 82084-82087, ack: 0, win: 8192, src: 1029 dst: 1745 .A..S., len: 4, seq: 171282-171285, ack: 82085, win: 8760, src: 1745 dst: 1029 .A len: 0, seq: 82085-82085, ack: 171283, win: 8760, src: 1029 dst: 1745
334 Приложение F Таблица F.I. Запуск контроллера домена (продолжение) Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения 99 100.149 2400 100 100.152 Ргох Ргох 2400 TCP TCP 101 100.31 2400 102 100.451 2400 103 100.518 2400 104 100.518 Ргох Ргох TCP ¦BROADCAST NBT Ргох 2400 TCP TCP 105 100.522 Ргох 2400 TCP 106 100.522 2400 107 100.921 2400 108 101.177 2400 109 101.277 Ргох Ргох TCP ¦BROADCAST BROWSER *BROADCAST BROWSER ¦BROADCAST BROWSER .AP..., len: 1, seq: 82085-82085, ack: 171283, win: 8760, src: 1029 dst: 1745 AP..., len: 1129, seq: 171283-172411, ack: 82086, win: 8759, src: 1745 dst: 1029 .A...., len: 0, seq: 82086-82086, ack: 172412, win: 7631, src: 1029 dst: 1745 NS: Запрос регистрации 2400++++++++++++ .A...F, len: 0, seq: 82086-82086, ack: 172412, win: 7631, src: 1029 dst: 1745 .A...., 0, seq: 172412-172412. ack: 82087, win: 8759, src: 1745 dst: 1029 .A...F, len: 0, seq: 172412-172412, ack: 82087, win: 8759, src: 1745 dst: 1029 .A len: 0, seq: 82087-82087, ack: 172413, win: 7631, src: 1029 dst: 1745 Объявление хоста [0x01] 2400 Выборы [0x08] [Принудительно] Выборы [0x08] PROX
Запуск контроллера домена 335 Таблица F.I. Запуск контроллера домена (продолжение) Кадр Время Адрес MAC Адрес MAC Протокол Описание источника назначения ПО 102.278 Prox *BROADCAST BROWSER Выборы [0x08] PROX 111 103.28 Prox *BROADCAST BROWSER Выборы [0x08] PROX 112 104.281 Prox *BROADCAST BROWSER Выборы [0x08] ¦ ¦'. ': -^:..O. .Л'? ?:, ;' .-¦ ; . PROX 113 105.288 Prox ¦NETBIOS Multicast ¦BROADCAST Prox Prox Prox ¦BROADCAST ¦BROADCAST ¦BROADCAST BROWSER NBT NBT NBT NBT NBT NBT BROWSER Объявление локального мастера [OxOf] PROX Объявление локального мастера [OxOf] PROX NS: Запрос ED1750 NS: Запрос ED 1750 NS: Запрос ED1750 NS: Запрос ED 1750 NS: Запрос ED1750 NS: Регистрация ED <03> 114 105.289 Prox 115 126.562 2400 116 128.047 2400 117 129.547 2400 118 131.063 2400 119 131.813 2400 120 131.841 2400 121 131.842 bigguy *BROADCAST ARP_RARP ARP: Запрос, IP получателя: 10.0.0.60 122 132.563 2400 ¦BROADCAST NBT NS: Запрос ED1750 123 134.817 TERESA ¦BROADCAST BROWSER Объявление локального мастера [OxOf] TERESA
Приложение G i-r-Л Открытие страницы Web Таблица G.I. Открытие страницы Web Кадр Время Источник Место назначения Протокол Описание Л 1 9.525 proxWan 8AA851000101 DNS 2 9.525 proxWan 8AA851000101 DNS 3 9.635 8AA851000101 proxWan DNS 4 9.655 8AA851000101 proxWan DNS 5 9.655 proxWan 8AA851000101 ICMP 0x1: Стандартный запрос home. microsoft.com типа Host Addr на классе INET addr. Oxl: Стандартный запрос home. microsoft.com типа Host Addr на классе INET addr. Oxl: Стандартный ответ на запрос home.microsoft.com типа Host Addr на классе INET addr. Oxl: Стандартный ответ на запрос home.microsoft.com типа Host Addr на классе INET addr. Место назначения недоступно: 206.112.194.65. См. кадр 4
Открытие страницы Web 337 Таблица G.I. Открытие араницы Web (продолжение) Кадр Время Источник Место Протокол Описание назначения 6 9.655 proxWan 8AA851000101 TCP 7 9.826 8АА851000101 proxWan TCP 8 9.826 proxWan 8AA851000101 TCP 9 9.846 proxWan 8AA851000101 HTTP 10 10.136 8AA851000101 proxWan HTTP 11 10.136 8AA851000101 proxWan TCP 12 10.156 proxWan 8AA851000101 TCP 13 10.266 proxWan 8AA851000101 DNS 14 10.266 proxWan 8AA851000101 DNS ....S., len: 4, seq: 241730-241733, ack: 0, win: 8192, src: 3488 dst: 80 .A..S., len: 4, seq: 142002582-14200258 5, ack: 241731, win: 8760, src 80 dst: 3488 .A...., len: 0, seq: 241731-241731, ack: 142002583, win: 8760, ere: 3488 dst: 80 Запрос GET (от клиента через порт 3488) Ответ(клиенту через порт 3488) .A...F, len: 0, seq: 142002909-14200290 9, ack: 242308, win: 8183, src: 80 dst: 3488 ...R.., len: 0, seq: 242308-242308, ack: 142002583, win: 0, src: 3488 dst: 80 0x1: Стандартный запрос www.msn.com типа Host Addr на классе INETaddr. 0x1: Стандартный запрос www.msn.com типа Host Addr на классе INET addr.
338 Приложение G Таблица G.I. Открытие страницы Web (продолжение) Кадр Время Источник Место Протокол Описание .- назначения 0x1: Стандартный ответ на запрос www.msn.com типа Host Addr на классе INET addr. 15 10.417 8АА851000101 proxWan DNS 16 10.417 proxWan 8AA851000101 TCP 17 10.447 8AA851000101 proxWan DNS 18 10.447 proxWan 8AA851000101 ICMP 19 10.547 8AA851000101 proxWan TCP 20 10.547 proxWan 8AA851000101 TCP 21 10.567 proxWan 8AA851000101 HTTP 22 13.512 proxWan 8AA851000101 HTTP 23 13.932 8AA851000101 proxWan HTTP 24 14.032 8AA851000101 proxWan HTTP ....S., len: 4, seq: 241741-241744, ack:0, win: 8192, src: 3491 dst: 80 0x1: Стандартный ответ на запрос www.msn.com типа Host Addr на классе INET addr. Место назначения недоступно: 206.112.194.65. См. Кадр 17 .A..S., len: 4, seq: 631519114-631519117, ack: 241742, win: 8760, src: 80 dst: 3491 .A...., len: 0, seq: 241742-241742, ack: 631519115, win: 8760, src: 3491 dst: 80 Запрос GET (от клиента через порт 3491) Запрос GET (от клиента через порт 3491) Ответ (клиенту через порт 3491) Ответ (клиенту через пор г 3491)
Открытие страницы Web 339 Таблица G.I. Открытие страницы Web (продолжение) Кадр Время Источник Место Протокол Описание назначения 25 14.052 proxWan 8АА851000101 TCP 26 14.403 8АА851000101 proxWan HTTP 27 14.423 proxWan 8AA851000101 TCP 28 14.513 8AA851000101 proxWan HTTP 29 14.644 8AA851000101 proxWan HTTP 30 14.663 proxWan 8AA851000101 TCP 31 14.844 8AA851000101 proxWan HTTP 32 14.864 proxWan 8AA851000101 TCP 33 14.935 8AA851000101 proxWan HTTP 34 15.114 proxWan 8AA851000101 TCP 35 15.244 8AA851000101 proxWan HTTP 36 15.344 8AA851000101 proxWan HTTP .A...., len: 0, seq: 242091-242091, ack: 631522035, win: 8760, src: 3491 dst: 80 Ответ(клиенту через порт 3491) .A...., len: 0, seq: 242091-242091, ack: 631523495, win: 8760, src: 3491 dst: 80 Ответ (клиенту через порт 3491) Ответ(клиенту через порт 3491) .A...., len: 0, seq: 242091-242091, ack: 631526415, win: 8760, src: 3491 dst: 80 Ответ (клиенту через порт 3491) .A...., len: 0, seq: 242091-242091, ack: 631527875, win: 8760, src: 3491 dst: 80 Ответ (клиенту через порт 3491) .A...., len: 0, seq: 242091-242091, ack: 631529335, win: 8760, src: 3491 dst: 80 Ответ(клиенту через порт 3491) Ответ (клиенту через порт 3491)
340 Приложение G Таблица G.I. Открытие араницы Web (продолжение) Кадр Время Источник Место Протокол Описание назначения 37 15.364 proxWan 8АА851000101 TCP 38 15.456 8АА851000101 proxWan HTTP 39 15.555 8AA851000101 proxWan HTTP 40 15.575 proxWan 8AA851000101 TCP 41 15.705 8AA851000101 proxWan HTTP 42 15.725 proxWan 8AA851000101 TCP 43 15.805 8AA851000101 proxWan HTTP 44 15.896 8AA851000101 proxWan HTTP 45 15.896 proxWan 8AA851000101 TCP 46 16.005 8AA851000101 proxWan HTTP 47 16.106 8AA851000101 proxWan HTTP 48 16.106 proxWan 8AA851000101 TCP .A...., len: 0, seq: 242091-242091, ack: 631532255, win: 8760, src: 3491 dst: 80 Ответ (клиенту через порт 3491) Ответ (клиенту через порт 3491) A...., len: 0, seq: 242091-242091, ack: 631535175, win: 8760, src: 3491 dst: 80 Ответ(клиенту через порт 3491) .А len: 0, seq: 242091-242091, ack: 631536635, win: 8760, src: 3491 dst: 80 Ответ (клиенту через порт 3491) Ответ (клиенту через порт 3491) .A...., len: 0, seq: 242091-242091, ack: 631539555, win: 5840, src: 3491 dst: 80 Ответ (клиенту через порт 3491) Ответ (клиенту через порт 3491) .A...., len: 0, seq: 242091-242091, ack: 631542475, win: 2920, src: 3491 dst: 80
Открытие страницы Web 341 Таблица G.I. Открытие страницы Web (продолжение) Кадр Время Источник Место Протокол Описание назначения 49 16.186 proxWan 8АА851000101 TCP 50 16.216 8АА851000101 proxWan HTTP 51 16.346 8AA851000101 proxWan HTTP 52 16.346 proxWan 8AA851000101 DNS 53 16.346 proxWan 54 16.366 proxWan 8AA851000101 DNS 8AA851000101 TCP 55 16.516 8AA851000101 proxWan HTTP 56 16.536 proxWan 8AA851000101 TCP 57 16.698 8AA851000101 proxWan HTTP 58 16.797 8AA851000101 proxWan HTTP 59 16.797 proxWan 8AA851000101 TCP 60 16.897 8AA851000101 proxWan HTTP .A...., len: 0, seq: 242091-242091, ack: 631542475, win: 8760, src: 3491 dst:80 , , Ответ (клиенту через порт 3491) Ответ (клиенту через порт 3491) 0x2: Стандартный запрос msimg.com типа Host Addr на классе INET addr. 0x2: Стандартный запрос msimg.com типа Host Addr на классе INET addr. .A...., len: 0, seq: 242091-242091, ack: 631545395, win: 8760, src: 3491 dst: 80 Ответ (клиенту через порт 3491) .А len: 0, seq: 242091-242091, ack: 631546855, win: 8760, src: 3491 dst: 80 Ответ (клиенту через порт 3491) Ответ (клиенту через порт 3491) .A...., len: 0, seq: 242091-242091, ack: 631549775, win: 8760, src: 3491 dst: 80 Ответ (клиенту через порт 3491)
342 Приложение G Таблица G.I. Открытие страницы Web (продолжение) Кадр Время Источник Место Протокол Описание назначения 61 16.897 8АА851000101 proxWan DNS 62 16.897 proxWan 8AA851000101 TCP 63 16.897 proxWan 8AA851000101 TCP 64 16.917 8AA851000101 proxWan DNS 65 16.917 proxWan 8AA851000101 ICMP 66 17.067 8AA851000101 proxWan HTTP 67 17.207 8AA851000101 proxWan HTTP 68 17.207 proxWan 8AA851000101 TCP 69 17.247 8AA851000101 proxWan HTTP 70 17.247 8AA851000101 proxWan TCP 0x2: Стандартный запрос msimg.com типа Host Addr на классе INET addr. A len: 0, seq: 242091-242091, ack: 631551235, win: 8760, src: 3491 dst: 80 ....S., len: 4, seq: 241751-241754, ack: 0, win: 8192, src: 3494 dst: 80 0x2: Стандартный запрос msimg.com типа Host Addr на классе INET addr. Место назначения недоступно: 206.112.194.65. См. Кадр 64 Ответ(клиенту через порт 3491) Ответ (клиенту через порт 3491) А len: 0, seq: 242091-242091, ack: 631554155, win: 8760, src: 3491 dst: 80 Ответ(клиенту через порт 3491) A..S., len: 4, seq: 550165240-55016524 3, ack: 241752, win: 8760, src: 80 dst: 3494
Открытие страницы Web 343 Таблица G.I. Открытие араницы Web (продолжение) Кадр Время Источник Место Протокол назначения Описание 71 17.247 proxWan 8AA851000101 TCP 72 17.267 proxWan 8AA851000101 HTTP 73 17.418 proxWan 8AA851000101 TCP 74 17.498 8AA851000101 proxWan HTTP 75 17.618 proxWan 8AA851000101 TCP 76 18.229 proxWan 8AA851000101 HTTP 77 18.319 proxWan 8AA851000101 TCP 78 18.449 8AA851000101 proxWan HTTP 79 18.449 8AA851000101 proxWan TCP 80 18.449 proxWan 8AA851000101 TCP .A...., len: 0, seq: 241752-241752, ack: 550165241, win: 8760, src: 3494 dst. 80 Запрос GET (от клиента через порт 3494) .A...., len: 0, seq: 242091-242091, ack: 631554686, win: 8229, src: 3491 dst: 80 Ответ (клиенту через порт 3494) .A...., len: 0, seq: 242091-242091. ack: 550165457, win: 8544, src: 3494 dst: 80 Запрос GET (от клиента через порт 3494) ....S., len: 4, seq: 241766-241769, ack: 0, win: 8192, src: 3495 dst: 80 Ответ (клиенту через порт 3494) .A..S., len: 4, seq: 1485616298-1485616 301, ack: 241767, win: 8760, src 80 dst: 349 .A len: 0, seq: 241767-241767, ack: 1485616299, win: 8760, ere: 3495 dst: 80
344 Приложение G Таблица G.I. Открытие страницы Web (продолжение) Кадр Время Источник Место Протокол Описание назначения 81 18.479 proxWan 8AA851000101 HTTP 82 18.62 proxWan 8AA851000101 TCP 83 18.73 8AA851000101 proxWan HTTP 84 18.92 proxWan 8AA851000101 TCP 85 19.14 proxWan 8AA851000101 HTTP 86 19.141 proxWan 8AA851000101 HTTP 87 19.381 8AA851000101 proxWan HTTP 88 19.381 proxWan 8AA851000101 HTTP 89 19.381 8AA851000101 proxWan HTTP 90 19.401 proxWan 8AA851000101 HTTP 91 19.691 proxWan 8AA851000101 HTTP 92 1Э.761 8AA851000101 proxWan HTTP Запрос GET (от клиента через порт 3495) .A...., len: 0, seq: 242427-242427, ack: 550165671, win: 8330, ere: 3494 dst: 80 Ответ (клиенту через порт 3495) .A...., len: 0, seq: 242103-242103, ack: 1485616512, win: 8547, ere: 3495 dst: 80 Запрос GET (от клиента через порт 3494) Запрос GET (от клиента через порт 3495) Ответ (клиенту через порт 3494) Запрос GET и (от клиента через порт 3494) Ответ (клиенту через порт 3495) Запрос GET (от клиента через порт 3495) Запрос GET (от клиента через порт 3491) Ответ (клиенту через порт 3494)
Открытие страницы Web 345 Таблица G.I. Открытие страницы Web (продолжение) Кадр Время Источник Место Протокол Описание назначения 93 19.821 proxWan 8AA851000101 DNS 94 19.822 proxWan 8AA851000101 DNS 95 19.852 8AA851000101 proxWan HTTP 96 19.872 proxWan 8AA851000101 TCP 97 19.872 8AA851000101 proxWan HTTP 98 19.942 proxWan 8AA851000101 HTTP 99 19.942 8AA851000101 proxWan DNS 100 19.962 proxWan 8AA851000101 TCP 101 19.962 8AA851000101 proxWan DNS 102 19.962 proxWan 8AA851000101 ICMP 103 20.023 8AA851000101 proxWan HTTP 0x3: Стандартный запрос go.msn.com типа Host Addr на классе INET addr. 0x3: Стандартный запрос go.msn.com типа Host Addr на классе INET addr. Ответ (клиенту через порт 3494) .А...., 1еп: 0, seq: 243029-243029, ack: 550167891, win: 8760, src: 3494 dst: 80 Ответ (клиенту через порт 3495) Запрос GET (от клиента через порт 3495) 0x3: Стандартный ответ на запрос go.msn.com типа Host Addr на классе INET addr. ....S., len: 4, seq: 241781-241784, ack: 0, win: 8192, src: 3498 dst: 80 0x3: Стандартный ответ на запрос go.msn.com типа Host Addr на классе INET addr. Место назначения недоступно: 206.112.194.65. См. кадр 101 Ответ (клиенту через порт 3491)
346 Приложение G Таблица G.I. Открытие страницы Web (продолжение) Кадр Время Источник Место Протокол Описание назначения 104 20.222 proxWan 8AA851000101 TCP 105 20.222 8АА851000101 proxWan HTTP 106 20.222 8АА851000101 proxWan TCP 107 20.222 proxWan 8AA851000101 TCP 108 20.222 proxWan 8AA851000101 HTTP 109 20.422 proxWan 8AA851000101 TCP ¦ -V -.У ¦: ¦'. ¦ .?.¦ у'- '-:: ''•'¦¦¦ - " 110 20.533 8AA851000101 proxWan HTTP 111 20.643 proxWan 8AA851000101 HTTP 112 20.873 8AA851000101 proxWan HTTP 113 21.023 proxWan 8AA851000101 TCP 114 0 STATS .A...., len: 0, seq: 242571-242571, ack: 631554827, win: 8088, ere: 3491 dst:80 , ... Ответ(клиенту через порт 3495) .A..S., len: 4, seq: 170783881-170783884, ack: 241782, win: 8760, sre 80 dst: 3498 .A...., len: 0, seq: 241782-241782, ack: 170783882, win: 8760, ere: 3498 dst: 80 Запрос GET (от клиента через порт 3498) .A...., len: 0, seq: 243130-243130, ack: 1485617155, win: 7904, ere: 3495 dst: 80 Ответ (клиенту через порт 3498) . Запрос GET (от клиента через порт 3498) Ответ(клиенту через порт 3498) .A...., len: 0, seq: 242548-242548, ack: 170784332, win: 8310, ere: 3498 dst: 80 Число перехваченных кадров = 113
Глоссарий Аск Управляющий бит (подтверждения) не занимает места в последователь- последовательности и указывает, что поле подтверждения сегмента определяет следующий номер последовательности, который ожидает отправитель этого сегмента, подтверждая получение всех предыдущих номеров последовательности. I Bit Бит. Единица или ноль. Byte Байт. Восемь битов. Смотрите также Octet. Backup Browser Резервный броузер. Получает копию списка просмотра от мастер-броузера и передает список по запросу компьютерам домена. Connection Соединение. Логический путь коммуникации, определяемый парой сокетов. Datagram Дейтаграмма. Сообщение, посылаемое в коммуникационных сетях компьютеров с пакетной коммутацией. < = ,, ,, , ' Destination Address Целевой адрес. Адрес места назначения, обычно иденти- идентификаторы хоста и сети. Domain Master Browser Мастер-Броузер домена. Всегда первичный контроллер домена; он отвечает за сбор объявлений для всего домена, включая все подсети сети TCP и сетевые сегменты. Fin Управляющий бит (конец), занимающий один номер последовательности. Он указывает, что отправитель больше не будет посылать данные или контро- контролировать пространство занимающей последовательности. Fragment Фрагмент. Часть логической единицы данных; в частности, фрагмент Интернета является частью дейтаграммы Интернета. FTP Протокол пересылки файлов. Gratuitous ARP_RARP Добровольный ARP_RARP. Широковещательное сооб- сообщение, сделанное клиентом DHCP перед использованием адреса IP. Компью- Компьютер берет адрес, присвоенный ему DHCP, и посылает запрос ARP именно для этого адреса. Таким образом, если другая машина имеет этот адрес, то возник- возникнет сетевая ошибка двойного IP-адреса. Другое свойство добровольного ARP_RARP состоит в том, что машины, которые имеют старый IP-адрес в своем кэше, будут автоматически обновлять свой кэш ARP при получении запроса. GUID (Globally Unique Identifier) Глобальный уникальный идентификатор. Другое имя для UUID (Universally Unique Identifier — универсальный уника- уникальный идентификатор). Является уникальной идентифицирующей строкой, связанной с интерфейсом вызова удаленной процедуры. Например: 12345678-1234-ABCD-EF00-01234567CFFB.
348 Глоссарий Header Заголовок. Управляющая информация в начале сообщения, сегмента, фрагмента, пакета или блока данных. Host Хост. В терминологии IP любое устройство с IP-адресом. Это может быть компьютер, принтер, управляемый концентратор, коммутатор или маршрутиза- маршрутизатор. В более общем смысле это либо источник, либо место назначения сообщений в сети. Identification Идентификация. Поле протокола Интернета, присвоенное отправителем, которое помогает при сборке фрагментов дейтограммы. Internet address Адрес Интернета. Адрес источника или места назначения, характерный для уровня хоста. Это IP-адрес, такой как 10.0.0.10. Internet datagram Дейтаграмма Интернета. Единица обмена данными между модулями Интернета и протоколами более высокого уровня вместе с заголовком Интернета. Internet fragment Фрагмент Интернета. Часть данных дейтограммы Интернета с заголовком Интернета. IRS number (Initial Receive Sequence) Начальный номер последовательности получения. Первый номер последовательности, используемый отправителем при соединении. ISN (Initial Sequence Number) Начальный порядковый номер. Первый номер последовательности, используемый при соединении (ISS или IRS). Выбирается процедурой на основе часов. ISS number (Initial Send Sequence) Начальный номер посланной последовате- последовательности. Первый номер последовательности, используемой отправителем при соединении. Leader Заголовок. Управляющая информация в начале сообщения или блока данных; в частности, в ARPANET управляющая информация в сообщении ARPANET в интерфейсе хост-ШР. Left sequence Оставшаяся последовательность. Следующий номер последова- последовательности, который будет подтвержден при получении данных (или наимень- наименьший неподтвержденный в настоящее время номер последовательности), который иногда называется левым краем посланного окна. Local packet Локальный пакет. Единица информации в локальной сети. Magic Cookie Область из четырех байтов в пакете DHCP, которая идентифи- идентифицирует начало поля специальных параметров, зависящих от поставщика. Если используется данное поле параметров, это отмечается IP- адресом 99.130.83.99, который показывается в трассировке Netmon как шестнадцатеричное 63 82 53 63. Параметры могут содержать идентификатор клиента, запрошенный адрес, а также другие позиции. Master browser Мастер-броузер. Отвечает за сбор информации для создания и поддержания списка просмотра, который содержит все серверы в домене мастер-броузера или рабочей группы, а также перечисляет все домены в сети. Module Модуль. Реализация, обычно программная, протокола или другой процедуры.
Глоссарий 349 MSL (Maximum Segment Lifetime) Максимальное время жизни сегмента. Время, в течение которого сегмент TCP может существовать в системе взаимодействия сетей. Произвольно определен как две минуты. .,.. .с < . Nonbrowser He-броузер. Специально сконфигурирован для того, чтобы не под- поддерживать список просмотра. Octet Октет. Байт из восьми битов. Сегодня несколько анахронический тер- термин. Раньше существовали десятибитные байты. • . .-.-.. Options Параметры. Могут содержать несколько параметров, каждый из кото- которых может иметь в длину несколько октетов. Параметры используются прежде всего в ситуация проверки; например, для задания отметки времени. Протокол Интернета и TCP предоставляют поля параметров. Packet Пакет. Пакет данных с заголовком, который может или нет быть логически завершенным; чаще встречается физическое, а не логическое пакетирование данных. Port Порт. Часть сокета, которая определяет, какой канал логического ввода или вывода процесса связан с данными. Potential Browser Потенциальный броузер. Компьютер, который может под- поддерживать список просмотра сетевых ресурсов. Он пока еще не имеет списка и будет поддерживать список просмотра, только если мастер броузер прикажет ему это делать. Process Процесс. Программа во время выполнения; источник или место на- назначения данных с точки зрения TCP или другого протокола хост-хост. PUSH Управляющий бит, не использующий номер из последовательности и указывающий, что сегмент содержит данные, которые должны быть доставле- доставлены получающему пользователю. Receive next sequence number Следующий номер последовательности для по- получения. Следующий номер последовательности, который ожидает получить локальный TCP. Receive window Окно получения. Номера последовательности, которые готов получить локальный (получающий) TCP. Таким образом, локальный TCP рас- рассматривает сегменты, перекрывающие диапазон от RCV.NXT до RCV.NXT + RCV.WND -1, несущие приемлемые данные или управляющую информацию. Сегменты, содержащие номера последовательности полностью вне этого диа- диапазона, рассматриваются дубликатами и отбрасываются. RST Управляющий бит (сброс), не использующий пространство последовате- последовательности и указывающий, что получатель должен удалить соединение без даль- дальнейшего взаимодействия. Получатель может определить на основе номера последовательности и полей подтверждения входящего сегмента, должен он принять или игнорировать команду reset. В любом случае получение сегмента, содержащего RST, порождает RST в ответ. RTP (Real Time Protocol) Протокол реального времени. Протокол хост-хост для передачи информации, критически важной по времени. Segment Сегмент. Логическая единица данных; в частности сегмент TCP явля- является единицей данных, пересылаемых между парой модулей TCP.
350 Глоссарий i Segment acknowledgment Подтверждение сегмента. Номер последовательно- последовательности в поле подтверждения приходящего сегмента. Segment length Длина сегмента. Объем пространства номеров последовате- последовательности, занимаемый сегментом, включая любую управляющую информацию, которая занимает пространство последовательности. Segment sequence Последовательность сегментов. Номер в поле последователь- последовательности приходящего сегмента. ; . .'¦-.;.•¦ •¦¦,¦•.¦'.¦.". -ДСГ; ¦;¦¦ Send sequence Последовательность отправки. Следующий номер последо- последовательности, который будет использовать локальный (посылающий) TCP при соединении, выбираемый вначале из области начальных номеров по- последовательности (ISN) и увеличиваемый для каждого переданного октета данных. Send window Окно передачи. Представляет номера последовательности, кото- которые готов получить удаленный (получающий) TCP. Оно равно значению поля окна, определенного в сегментах удаленного TCP (получающего данные). Диа- Диапазон номеров новой последовательности, который может быть послан TCP, находится между SND.NXT и SND.UNA + SND.WND -1. (Конечно, ожидается пересылка номеров последовательности между SND.UNA и SND.NXT.) Socket Сокет. Адрес, который специально включает идентификатор порта, т.е. соединение адреса Интернета с портом TCP. Source address Адрес источника. Обычно идентификаторы сети и хоста. SYN Управляющий бит во входящем сегменте, занимающий номер последо- последовательности, используемый при инициации соединения, чтобы указать, где начнется нумерация последовательности. ТСВ (Transmission Control Block) Блок управления передачей. Структура данных, которая записывает состояние соединения. . TCP (Transmission Control Protocol) Протокол управления передачей. Протокол хост-хост для надежной коммуникации в межсетевых средах. Type of Service Тип службы. Поле протокола Интернета, которое указывает тип службы для этого фрагмента Интернета. UUID (Universally Unique Identifier) Универсальный уникальный идентифика- идентификатор. Уникальная идентификационная строка, связанная с интерфейсом вызова удаленной процедуры, называемая также иногда GUID (глобальный уникальный идентификатор). Пример: 12345678-1234-ABCD-EF00-01234567CFFB. URG Управляющий бит (срочности), не использующий номер последователь- последовательности, указывает, что получающий пользователь должен выполнить срочную обработку, как только будут получены данные с номерами последовательности меньше значения, указанного в указателе срочности. Urgent pointer Указатель срочности. Управляющее поле, имеющее смысл, то- только когда задан бит URG. Это поле передает значение указателя срочности, которое указывает октет данных, связанный со срочным вызовом посылающего пользователя.