Третьим шагом является команда DATA, за которой следует нажатие клавиши Enter или отправка возврата каретки и перевода строки (<CRLF>) (несколько анахронический термин). Когда сервер получит эту команду, протокол SMTP рассматривает весь последующий трафик как данные для этого поля, пока не получит строку, содержащую только одну точку. Другими словами, раздел данных завершается, когда получающий сервер получит строку символов return-T04Ka-return (<CRLF>.<CRLF>). Индикатор конца данных подтверждает транзакцию и приказывает серверу SMTP обработать данные в буфере обратного пути доступа и буфере пути доступа пересылки. Когда обработка закончена, сервер вернет ОК. Приняв сообщение, сервер вставляет отметку времени в начале строки почтовых данных, которая указывает идентичность посылающего и получающего хостов. При конечной доставке сообщения также вставляется строка пути возврата, которая содержит информацию из обратного пути, введенного вместе с командой mail. Поле данных почты может также содержать, если потребуется, тему данных, строки to, сс и from. На рис. показано использование этих команд в сеансе Telnet, созданном с сервером Exchange. Это хороший способ протестировать соединение Exchange и почты Интернета.
Команда DATA будет отказывать, только если транзакция является неполной или нет доступных ресурсов для обработки запроса. Реализация SMTP в Microsoft Exchange не позволит иметь неполное сообщение. Как можно видеть на рис, Exchange требует, чтобы команды вводились в определенном порядке, прежде чем он будет обрабатывать данные.
Протокол SMTP включает дополнительные свойства для помощи в поиске получателей и списков распространения. Этими командами являются команда VRFY, которая используется для предоставления информации о пользователях почтового ящика, и команда EXPR, используемая для списков распространения. Однако, как видно на рис. эти команды не реализованы в Microsoft Exchange по соображениям безопасности. Вместо них для предоставления этой информации используется LDAP.
Команда NOOP используется для определения отсутствия операции. Она не влияет ни на какие введенные ранее команды или параметры. Она просто означает ничего не делать и получает с сервера ответ ОК.
RSET является командой сброса, которая прерывает текущую транзакцию. Вся информация в буферах будет сброшена и таблицы состояния очищены. Она также получает с сервера ответ ОК. Эта команда может быть отправлена в любой момент во время общения.
Когда между двумя компьютерами впервые создается сеанс, есть возможность убедиться, что серверы общаются именно с тем, с кем они собирались общаться. Для этого используется команда HELO. Эта команда может посылаться только один раз и имеет форму HELO mred.com. HELO идентифицирует посылающий компьютер для сервера SMTP. Если при обработке команды не возникает ошибок, то ответом будет 250 ОК. Эту команду можно интерпретировать как "Привет, я mred.com". Если команда HELO посылается во второй раз, то ответом будет 503 bad sequence (неверная последовательность). В указанном домене никакой проверки не делается, и имя домена можно оставить пустым, как на рис. Когда сеанс заканчивается, для закрытия канала посылается команда QUIT.
Протокол РОРЗ используется как упрощенный протокол почты, который хранит сообщения на сервере, пока клиентская машина не соединится и не выгрузит их по запросу. Он делает не слишком много по обработке сообщения на сервере; служба РОРЗ просто слушает порт 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 суммирует команды РОРЗ, которые обычно встречаются в трассировках сетевого мониторинга.
Когда 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 сообщает нам, что это служба вызова удаленной процедуры.
Раньше при возникновении проблемы с сетью, часто приходилось гадать, что же вызвало неполадки. Позже появились специализированные устройства, которые были дорогими, трудными для управления и понимания. Теперь имеется сетевой монитор, который является программным инструментом анализа компании 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 на сайте издательства "ЛОРИ".
