Использование LMHOSTS Начнем этот раздел с обсуждения двух способов, с помощью которых рабочая станция находит машину регистрации — с помощью широковещания и с помощью WINS. Существует и третий способ: использование файла lmhosts. Обратимся к этому файлу.
Используя запись #PRE, мы приказываем машине сделать предварительную загрузку записи в кэш имен NetBIOS. Она будет найдена, когда мы введем nbtstat -с, как показано на рис. Задав #DOM с именем домена, мы сообщаем машине, что это контроллер домена, и поэтому получаем дополнительные записи, такие как <1С>, также показанные на рис.
Используя файл LMHOSTS, мы ускоряем процесс регистрации, не выполняя при этом ни широковещательного запроса, ни запроса WINS, и, кроме того, сокращаем сетевой трафик. Стандартная проблема с реализацией LMHOSTS состоит в размещении его на всех клиентских машинах. Выход простой: поместите LMHOSTS в сценарий регистрации, и он сам скомпонуется на клиентские машины. На машине WIN NT он помещается в каталоге \\system32\drivers\etc. На машине Windows 9.x он помещается в каталог \\windows.
Нужно ли иметь больше контроллеров доменов? Обычно процесс регистрации происходит между 8 и 9 часами утра. Сколько реально необходимо иметь серверов регистрации? Помните, что добавление дополнительных резервных контроллеров доменов увеличивает сетевой трафик, как мы увидим в следующей главе. Это означает, что было бы плохой идеей сделать каждый сервер в сети резервным контроллером домена (что встречается достаточно часто).
Используя очень консервативную оценку, один контроллер домена может легко управлять 2000 пользователей. Если вернуться к нашему окну регистрации, можно видеть, что в течение одного часа (3600 секунд), происходит в среднем меньше двух регистрации в секунду (если запросы регистрации распределены равномерно). Что делать в такой ситуации? Прежде всего, необходимо использовать монитор производительности для создания протокола утренней деятельности по регистрации. Как можно видеть на рис. лучшим способом это сделать является создание протокола (log) монитора производительности и протокола использования памяти, процессора и серверного объекта. Для этого надо перейти во view\log и выбрать соответствующие режимы. В меню режимов выбирается тип протокола (log), а затем вводится имя протокола. Можно использовать, например, logon.log или добавить дату. Выберите хорошее место для размещения протокола (не в корне), интервал обновления и нажмите save (сохранить). Теперь необходимо добавить некоторые показатели, нажимая кнопку "плюс", как показано на рис.
Когда показатели будут добавлены, необходимо вернуться в меню режимов, выбрать тип протокола (log) и запустить протокол, как показано на рис. Это будет достаточно большой протокол, так как записи в нем появляются каждую секунду.
Если после создания протокола будут замечены периоды, когда происходит множество попыток регистрации в секунду, необходимо сделать несколько дополнительных изменений.
Протокол РОРЗ используется как упрощенный протокол почты, который хранит сообщения на сервере, пока клиентская машина не соединится и не выгрузит их по запросу. Он делает не слишком много по обработке сообщения на сервере; служба РОРЗ просто слушает порт TCP 110, пока почта не будет извлечена, и удаляет ее из почтового хранилища. Это не очень развитый протокол, но он достаточно эффективен.
Когда клиент РОРЗ хочет создать соединение, он следует схеме одиночных рабочих команд. Подобно протоколу SMTP, который был рассмотрен ранее, команды состоят из символов ASCII, разделенных пробелами. Эти команды имеют длину в три или четыре символа. Модификаторы для команд РОРЗ могут быть до 40 символов длиной.
Сервер РОРЗ дает два типа ответов. Первый ответ является положительным. Отрицательным ответом является -ERR. Оба эти ответа должны быть представлены заглавными буквами и содержать либо знак -, либо знак +.
Некоторые команды будут создавать многострочный ответ с сервера (например, команда list), и каждая строка будет заканчиваться комбинацией возврата каретки и перевода строки (та же самая комбинация ASCII 13 и ASCII 10 использовалась в протоколе SMTP). Когда все строки будут посланы, сервер пошлет . (ASCII 46) и дополнительный перевод строки. Это та же комбинация <RLF>.[T04Ka]<RLF>, которую мы видели в протоколе SMTP.
Четыре состояния РОРЗ Во время процесса соединения клиента и получения почты РОРЗ проходит через четыре состояния. После начального соединения TCP и последующего приветствия сервер входит в состояние авторизации, в котором клиент идентифицирует себя. Вслед за состоянием авторизации РОРЗ входит в состояние транзакции и получает команды с клиентской машины для обработки почты. После успешной обработки почты и отправки клиентом команды завершения quit сеанс входит в фазу обновления и освобождает ресурсы, использованные во время состояния транзакции. Затем соединение TCP закрывается. Эта последовательность событий для успешного сеанса подробно описана в следующем списке.
1. Клиентская машина запрашивает у DNS адрес.
2. Когда адрес получен, машина инициирует трехходовое квитирование на порте 110.
3. Вслед за трехходовым квитированием сервер посылает приветствие.
4. Клиент отвечает именем пользователя.
5. Сервер проверяет, существует ли пользователь в системе, и отвечает с помощью +ОК.
6. Клиент отвечает паролем.
7. Сервер отвечает +ОК.
8. Клиент запрашивает состояние почтового ящика.
9. Сервер отвечает, посылая число и размер сообщений в почтовом ящике.
10. Клиент запрашивает список сообщений.
11. Сервер отвечает.
12. Клиент пересылает себе сообщения.
13. Клиент стирает сообщения на сервере.
14. Когда все сделано, он посылает команду завершения quit.
15. Сервер отвечает с помощью+ОК
Таблица 8.2 суммирует команды РОРЗ, которые обычно встречаются в трассировках сетевого мониторинга.
Раньше при возникновении проблемы с сетью, часто приходилось гадать, что же вызвало неполадки. Позже появились специализированные устройства, которые были дорогими, трудными для управления и понимания. Теперь имеется сетевой монитор, который является программным инструментом анализа компании Microsoft. Существуют две версии этой программы: сокращенная, поставляемая с серверными операционными системами, и полная, которая поставляется с сервером управления системами. Microsoft Network Monitor Lite способен перехватывать трафик, предназначенный только для машины, выполняющей программу. Полная версия переводит сетевой адаптер в "режим, не делающий различия" — т.е. он перехватывает трафик, направленный на компьютер, выполняющий Microsoft Nerwork Monitor, а также трафик, предназначенный для других устройств.
Network Monitor 2.0 поставляется вместе с Windows 2000 в версии Lite, а полная версия поставляется вместе с Windows NT 4.0 и SMS 2.0. Network Monitor 1.2. поставляется вместе с Windows NT 4.0 и SMS 1.2. В действительности существует лишь Небольшое различие между версиями продукта 2.0 и 1.2, так как функционально они одинаковы. Мы укажем различия, но большая часть рассматриваемого материала применима к любой версии продукта.
Microsoft Network Monitor копирует кадры в буфер перехвата, который является областью памяти с изменяемым размером. По умолчанию этот буфер перехвата равен одному мегабайту, но это легко изменить. Однако в связи с этим зависимым от памяти буфером перехвата сетевой монитор может перехватить лишь столько информации, сколько может поместиться в доступной памяти. Когда буфер будет заполнен, он начнет отбрасывать пакеты, и поэтому можно пропустить разыскиваемую информацию. Кроме того, сетевой монитор имеет склонность блокировать и связывать большую часть ресурсов процессора, когда ему разрешается выполняться в течение продолжительных периодов после полного заполнения буфера. К счастью, легко прекратить его работу с помощью Task Manager, но тогда теряется весь перехваченный файл. Мы узнаем некоторые приемы решения этой проблемы при рассмотрении необслуживаемого мониторинга сети. Потеря файла обычно не является проблемой, так как можно выбрать, какую часть кадра необходимо увидеть, создавая фильтр перехвата. Фильтр перехвата (который в определенном смысле похож на запрос к базе данных) позволяет перехватывать только определенные адреса или типы кадров. Мы поговорим об этом в разделе о перехвате данных.
Так как Microsoft Nerwork Monitor легкодоступный, очень мощный инструмент, способный перехватывать данные из сети, необходимо позаботиться о системе безопасности. Как мы видели в других главах, обладая определенными навыками, из сети можно получить очень важную информацию. Microsoft Nerwork Monitor может быть прекрасным инструментом для поиска неисправностей, но также может представлять существенную опасность, оказавшись в недобросовестных руках. Есть несколько способов защиты сети от неавторизованного использования этого инструмента. Мы-поговорим об этом позже, в разделе о безопасности сетевого монитора.
Microsoft Network Monitor не устанавливается по умолчанию. Чтобы установить его, перейдите к вкладке служб сетевого апплета в панели управления и выберите добавить (add) инструменты сетевого монитора и агент. (ПРИМЕЧАНИЕ. Не забудьте выбрать инструменты сетевого монитора и агента, а не просто агента сетевого монитора, который представлен в списке ниже и не включает программу Microsoft Network Monitor.) Установка версий SMS использует отдельную программу Setup.exe, находящуюся в каталоге NMEXR на сайте издательства "ЛОРИ".
Когда данные перехватываются, карта Ethernet передает часть кадров, которые она видит в сети, в буфер перехвата. Если буфер перехвата переполняется, то для определения того, что удерживается в памяти, будет использоваться принцип простой очереди, или FIFO (первый вошел, первый вышел). Чтобы избежать переполнения буфера перехвата, можно изменить настройки буфера, выбирая их из меню перехвата. Появится диалоговое окно, позволяющее определить новый буфер перехвата в мегабайтах. Здесь можно также определить, будет ли перехватываться весь кадр, или некоторое число байтов кадра, позволяя сохранить только информацию заголовка.
Другим способом сократить объем выбранных данных является создание фильтра перехвата для уточнения того, что именно плата передает в буфер перехвата. Начните свой сеанс перехвата, выбрав start в меню перехвата (или нажав кнопку Record). Как показано на рис., сетевой монитор выводит статистические данные о сеансе перехвата во время выполнения. Эти статистические данные дают представление о сетевой производительности в данный момент. Важно помнить, что это мгновенный снимок, и хотя он может дать некоторое представление о сети, его нельзя использовать в качестве инструмента планирования. Если, однако, задокументировать эти записи, развернуть их во времени и сравнить с информацией из управляемых концентраторов, коммутаторов, и маршрутизаторов, можно получить лучшее представление о сетевой производительности.
Графическая панель показывает текущее состояние сети. Эти панели имеют изменяемый размер, позволяя лучше представить данные. Это полезное свойством при мониторинге процесса перехвата. Это высокоуровневое представление может помочь при поиске неисправностей, предоставляя перечисленную ниже информацию.
• Процент загруженности сети
• Число кадров в секунду
• Число байтов в секунду
• Число широковещательных сообщений в секунду
• Число мультивещательных сообщений в секунду
Панель общей статистики показывает числовой итог информации, содержащейся в графической панели. Появляется также статистика относительно перехваченных данных. Панель сообщает, сколько кадров находится в буфере, какая доля буфера использована, были или нет какие-либо кадры отброшены в связи с переполнением буфера. Дополнительная статистика предоставляет информацию о сетевой плате.
Панель статистики сеанса (ниже графической панели) перечисляет сетевые адреса компьютеров, общающихся во время текущего сеанса перехвата. Она показывает, сколько кадров находится в сети и в каком направлении они движутся. Обратите особое внимание на стрелку, так как она используется в сетевом мониторе для указания направления потока данных (используется также при создании фильтров перехвата). Стрелка всегда указывает в направлении компьютера, который будет получать информацию. Например, на рис. bigguy в столбце сетевого адреса 1 посылает 31 кадр в PROX в столбце сетевого адреса 2. PROX посылает 25 кадров назад bigguy.
Панель статистики станции (ниже статистики сеанса) более подробно представляет информацию из статистики сеанса, перечисляя число байтов посланных и полученных каждой станцией, представленной в буфере перехвата. Информация о посланных широковещательных и мультивещательных сообщениях особенно полезна для быстрого выявления потенциальных проблем в сети. Кроме того, может понадобиться исследовать направление потока данных и размеры различных происходящих обменов данными. Все это может оказаться потенциальными узкими местами сети.
