Когда соединяются различные сетевые сегменты IPX, инструкции для маршрутизации пакетов между этими сегментами приходят из протокола IPX. IPX выполняет эти функции уровня 3 с помощью RIP, SAP и NLSP.
Если две рабочие станции находятся в одном сетевом сегменте, посылающая рабочая станция посылает пакеты прямо по физическому адресу рабочей станции назначения (т.е. по адресу MAC). Если две рабочие станции находятся в двух различных сетевых сегментах, то первая рабочая станция должна найти маршрутизатор в своем собственном сегменте, который знает, как переслать пакеты внешнему сегменту.
Чтобы найти этот крайне важный маршрутизатор, рабочая станция будет посылать широковещательный пакет RIP, запрашивающий самый быстрый маршрут к сегменту назначения. Маршрутизатор того же сегмента с самым коротким путем к сегменту назначения ответит на запрос. В пакете ответа маршрутизатор включит в заголовок IPX свой собственный сетевой и узловой адрес.
Очевидно, что если посылающим узлом является маршрутизатор, а не рабочая станция, то ему не нужно будет посылать широковещательное сообщение RIP, чтобы получить эту информацию. Вместо этого маршрутизатор берет информацию из внутренней таблицы маршрутизации.
Когда посылающая рабочая станция получит адрес маршрутизатора, она посылает пакеты рабочей станции назначения, помещая полный адрес IPX места назначения (т.е. сеть, узел и номер сокета) в поле места назначения заголовка IPX, как это было показано ранее в этой главе.
Затем посылающая рабочая станция помещает свой собственный полный адрес IPX в соответствующее поле источника заголовка IPX. Посылающая рабочая станция заполнит также все другие поля в заголовке. Например, она поместит адрес узла маршрутизатора, который ответил на запрос RIP в поле адреса места назначения заголовка MAC. Она поместит свой собственный адрес в поле адреса источника заголовка MAC.
Посылающая рабочая станция отправляет, наконец, пакет маршрутизатору, который должен теперь выполнить несколько задач. В первую очередь маршрутизатор просматривает поле контроля транспорта заголовка пакета IPX. Маршрутизатор RIP будет отбрасывать пакет, если это поле больше 16. Маршрутизатор NLSP будет отбрасывать полученный пакет, если это число больше, чем ограничение числа переходов.
После этого маршрутизатор проверяет поле типа пакета заголовка IPX. Если он видит в этом поле 20 (0x14), это указывает на пакет NetBIOS. Он должен также посмотреть поле контроля транспорта. Если это значение равно восьми или больше, маршрутизатор отбрасывает пакет, так как пакет NetBIOS ограничен восьмью переходами (или сетями).
Затем маршрутизатор сравнивает сетевой номер в пакете с сетевым номером сегмента, в который прибыл пакет. Если маршрутизатор обнаружит совпадение, то он отбрасывает пакет, чтобы избежать зацикливания. Если сетевой номер не совпадает, то он помещает сетевой адрес в следующее доступное поле сетевого номера. Он увеличивает поле контроля транспорта и посылает пакет всем напрямую соединенным сетевым сегментам, которые не присутствуют в полях сетевых номеров.
Теперь маршрутизатор проверяет поля адреса назначения, чтобы определить, как направить пакет. Если пакет адресован маршрутизатору, соответствующий процесс сокета обработает его внутренне; иначе маршрутизатор пересылает пакет. В дополнение к пакетам, непосредственно адресованным маршрутизатору, он должен также иметь дело с OxFFFFFFFFFFFF, которые обычно являются пакетами RIP, SAP или диагностики.
Если пакет необходимо переслать, маршрутизатор помещает адрес места назначения из заголовка IPX в поле адреса места назначения заголовка MAC. Затем маршрутизатор помещает свой собственный адрес в поле адреса источника заголовка MAC, увеличивает поле контроля транспорта заголовка IPX и пересылает пакет в сегмент назначения. Если, однако, поле контроля транспорта равно максимально допустимому числу переходов до того, как поле будет увеличено, маршрутизатор отбрасывает пакет. Для маршрутизаторов RIP это число равно 16, для маршрутизаторов NLSP это ограничение задается в диапазоне от 8 до 127.
Широковещательные пакеты никогда повторно не посылаются в сетевые Сегменты, из которых они были получены. Если маршрутизатор не связан напрямую с сегментом, в котором находится узел конечного места назначения, он посылает пакет следующему маршрутизатору на пути к узлу назначения, помещая адрес узла следующего маршрутизатора в поле адреса места назначения заголовка MAC. Маршрутизатор берет эту информацию в своей информационной таблице маршрутизации и затем помещает адрес своего собственного узла в поле адреса источника заголовка MAC, увеличивает поле контроля транспорта в заголовке IPX и пересылает пакет следующему маршрутизатору.
NCP Каждый NCP известен прежде всего по своему номеру, который состоит из трех полей. Например, номер для изменения пароля объекта связывания равен 0x2222 23 64.
• Первое двухбайтовое поле "0x2222" является полем категории службы.
• Второе число "23" является номером функции, который идентифицирует, где в таблице коммутации существует базовая функция.
• Третье поле "64" идентифицирует специальную функцию NCP, которая выполняется.
Номера NCP делятся на широкие функциональные категории. Например, большинство функций номера 23 являются NCP учета, связывания, соединения или файлового сервера. В таблице 3.6 перечислены некоторые из категорий служб NCP.
Категория NCP запроса службы (0x2222) и категория NCP ответа службы (0x3333) используются наиболее часто. Существуют две категории служб, которые не требуют создания пакетов ответа службы (0x3333). Это разрушение служебного соединения (0x5555) и запрос разбиения пакета (0x7777).
Если клиенту посылается сообщение, что предыдущий запрос все еще обрабатывается (0x9999), это означает, что клиент сделал другой запрос или снова послал тот же запрос, в то время как сервер все еще обрабатывает последний, сделанный тем же клиентом, запрос.
Клиент посылает через соединение с сервером сообщение, которое содержит все параметры NCP, используя сетевой протокол, например IPX. Сервер выполняет процедуру и возвращает результаты клиенту. Каждое дополнительное сообщение увеличивает идентификационные номера в пакете. Когда от клиента получен запрос NCP, создается ответ NCP. Это протокол, действующий по принципу один запрос — один ответ.
При использовании в сети TCP/IP существует вероятность, что в сети применяется DHCP для раздачи IP-адресов клиентским машинам и, возможно, некоторым принтерам. Нечего и говорить, что если TCP/IP является единственным протоколом в сети, то клиентская машина должна иметь допустимый IP-адрес, чтобы общаться с другими устройствами в сети, например компьютерами, маршрутизаторами, принтерами и серверами. Этот IP-адрес должен иметь подходящий сетевой адрес, адрес хоста и маску подсети, иначе коммуникация просто не будет происходить. Если имеется несколько сегментов, то требуется также используемый по умолчанию шлюз.
DHCP может управлять этими простыми задачами, и даже сделать больше. В действительности это четкий и эффективный протокол, которому требуются только четыре кадра для выдачи адреса и два кадра для обновления этого адреса позже. Рассмотрим это подробнее.
Процесс получения адреса Когда загружается клиент DHCP, первое что он должен сделать, это найти сервер DHCP, выдающий IP-адреса для подсети, к которой он присоединен. Для этого устройство пошлет сообщение поиска DHCP, указывающее, что оно хотело бы получить IP-адрес. Сервер DHCP, получив сообщение поиска, ответит предложением DHCP. Оно говорит: "Я получил ваш запрос и вот адрес, который у меня есть". Клиентская машина может получить несколько предложений DHCP от нескольких серверов, которые могут услышать сообщение поиска DHCP. Клиент выберет первое полученное им предложение DHCP и ответит серверу DHCP, что он хочет получить предложенный IP-адрес. Это называется запросом DHCP. Сервер DHCP при получении запроса ответит подтверждением (АСК): "Можете начинать использовать IP-адрес". Таблица резюмирует этот процесс.
Как можно видеть в таблице, DHCP использует широковещание в течение всего процесса. Это позволяет другим машинам в сети знать о том, что происходит. Рассмотрим этот процесс подробнее. В приведенной ниже распечатке заголовка Ethernet можно видеть, что адресом назначения является FFFFFFFFFFFF. Это широковещательный адрес для уровня доступа к среде передачи. Все устройства в сегменте Ethernet должны будут обрабатывать этот кадр, пока не дойдут до раздела UDP (порта дейтаграмм пользователя) и не обнаружат, что они не имеют указанного порта UDP. В распечатке также видно, что размер кадра Ethernet равен 342 байтам. Это размер данного кадра Ethernet, включая заголовок. Число остающихся байтов равно 328, что является полезной нагрузкой минус 14-байтовый заголовок Ethernet.
Протокол SMTP (Simple Mail Transfer Protocol, простой протокол передачи почты) используется для получения почты из Интернета. Когда адрес сервера преобразован (с помощью DNS), создается соединение с портом 25. Команды SMTP используются для управления потоком почты из одной машины в другую. Каждая из этих команд заканчивается нажатием клавиши Enter или Return. Команды SMTP не зависят от регистра символов, хотя SMTP будет сохранять регистр при адресации, так как некоторые реализации могут иметь имена пользователей, зависящие от регистра символов. Как видно на рис., для создания соединения может использоваться Telnet, а также другой сервер SMTP. Это часто делается для тестирования соединения почты Интернета с Exchange. Процесс начинается с команды mail, посылаемой отправителем с помощью from: в форме <имя_пользователя>@<имя_домена>. From: является полем, которое сообщает серверу SMTP имя пользователя. <имя_пользователя>@<имя_домена> также станет ответом для адреса.
Команда HELO (HELLO в некоторых реализациях) позволяет узнать, общаются ли две машины. В то время как приветствие при соединении идентифицирует сервер получателя, HELO используется для идентификации отправителя на сервере SMTP. HELO и сопровождающий 250 OK позволяют узнать, что отправитель и получатель находятся в состоянии начального соединения без выполняющихся транзакций и с пустыми буферами. Команда mail сообщает серверу SMTP, что начинается новая транзакция. Если все правильно, то вернется ответ 250 ОК. from: называется также адресом обратного пути. Он может содержать более одного почтового ящика, а также список хостов для обратной маршрутизации источника.
Следующей командой MAIL используется для начала почтовой транзакции. Эта строка также будет содержать from:, что называется обратным путем доступа и используется для извещений о недоставке. Эта информация хранится сервером SMTP отправителя в буфере обратных путей доступа, который будет обрабатываться после ввода всех данных.
RCPT идентифицирует получателя сообщения и является командой, вводимой после команды mail. Если эта команда mail получена сервером SMTP правильно, то будет возвращаться ответ 250-ОК. Если получатель неизвестен, то с сервера вернется ошибка 550. Если получатель введен неправильно, то будет порождаться ошибка 553 неправильно сформированного адреса. Протокол позволит в этом месте ввести в процесс несколько получателей. Нажатие клавиши Return в конце строки RCPT и ввод другой команды RCPR вводит дополнительных получателей. Кроме почтового ящика в поле RCPT можно также поместить список маршрутов хостов источников. Данные RCPT хранятся в буфере путей доступа пересылки столько, сколько нужно серверу.
Когда данные перехватываются, карта Ethernet передает часть кадров, которые она видит в сети, в буфер перехвата. Если буфер перехвата переполняется, то для определения того, что удерживается в памяти, будет использоваться принцип простой очереди, или FIFO (первый вошел, первый вышел). Чтобы избежать переполнения буфера перехвата, можно изменить настройки буфера, выбирая их из меню перехвата. Появится диалоговое окно, позволяющее определить новый буфер перехвата в мегабайтах. Здесь можно также определить, будет ли перехватываться весь кадр, или некоторое число байтов кадра, позволяя сохранить только информацию заголовка.
Другим способом сократить объем выбранных данных является создание фильтра перехвата для уточнения того, что именно плата передает в буфер перехвата. Начните свой сеанс перехвата, выбрав start в меню перехвата (или нажав кнопку Record). Как показано на рис., сетевой монитор выводит статистические данные о сеансе перехвата во время выполнения. Эти статистические данные дают представление о сетевой производительности в данный момент. Важно помнить, что это мгновенный снимок, и хотя он может дать некоторое представление о сети, его нельзя использовать в качестве инструмента планирования. Если, однако, задокументировать эти записи, развернуть их во времени и сравнить с информацией из управляемых концентраторов, коммутаторов, и маршрутизаторов, можно получить лучшее представление о сетевой производительности.
Чтобы защитить свою сеть от неавторизованного просмотра, сетевой монитор может легко определить другие экземпляры программы в сети. Он может сделать это независимо от того, работает или нет программа. Как показано на рис., если драйвер установлен на машине, он будет сообщать имя машины, имя зарегистрированного на компьютере пользователя, адрес Ethernet машины, номер версии программы и перехватывает ли программа данные, или просто установлена. Чтобы получить эту информацию, необходимо выбрать в меню Tools пункт Identify network monitor users (Идентифицировать пользователей сетевого монитора). Важно отметить, что если имеются сетевые сегменты, разделенные маршрутизатором, который не пересылает мультивещательные сообщения, то невозможно будет определить установки сетевого монитора в другом сегменте, не соединившись с этим сегментом. Это связано с тем, что Netmon использует суффикс NetBIOS для объявления о своем присутствии в сети. Суффикс BE объявляет агента сетевого монитора, а суффикс BF объявляет в сети само приложение сетевого монитора. Если они не пересылаются, то необходимо будет соединиться с определенным сегментом, чтобы определить незаконные установки этих инструментов.
После выбора пункта меню "Определить пользователей сетевого монитора" машина Netmon посылает запрос станции BONE, как показано в следующей распечатке. Протокол BONE (сокращение от Bloodhound Oriented Network Entity, что может быть приблизительно переведено как "Сетевая ищейка") используется сетевым монитором, чтобы он мог общаться. Этот ьапрос станции является очень маленьким кадром многоадресной рассылки 802.3, который использует только 29 байтов.
Ответ направляется в машину, которая послала запрос, и является маленьким кадром 802.3, в этот раз требующим около 125 байтов. Ответ сообщает статус драйвера; 0x00000003 означает, что драйвер установлен и активен, но не перехватывает данные. Он содержит версию драйвера, машину, адрес MAC машины и имя любого пользователя, которое было сконфигурировано при конфигурировании драйвера.
