SMB достаточно развит, чтобы преобразовывать имя сервера множеством различных методов. Например, в URL file://prox/users/teresa/movies.xIs клиент возьмет часть между двумя наклонными чертами и следующей наклонной чертой в качестве имени сервера, а остальное будет интерпретировано как относительное имя. В примере именем сервера будет 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.
Пример потока сообщений
Типичная последовательность обмена сообщениями для клиента, соединенного с сервером уровня пользователя включает открытие файла, чтение из него данных, закрытие файла и разъединение с сервером. Механизм пакетирования запросов CIFS (называемый механизмом "AndX") дополнительно позволяет объединять в одно до шести сообщений в этой последовательности, поэтому в действительности в этой последовательности существуют только три перехода туда и обратно, и последнее из них клиент может сделать асинхронно.
Каждый сервер делает доступными для клиентов в сети множество ресурсов. Ресурсом может быть дерево каталогов, именованный канал, принтер и т.д. Клиентская машина видит сервер как единственного поставщика файла или другого доступного ресурса, поэтому она не знает о каких-либо зависимостях от хранения или службы.
Протокол CIFS требует аутентификации сервера пользователей, прежде чем будет разрешен доступ к файлу, и каждый сервер аутентифицирует своих собственных пользователей. Клиентская система должна посылать информацию аутентификации на сервер, прежде чем сервер разрешит доступ к своим ресурсам.
Протокол CIFS определяет два метода, которые могут быть выбраны сервером для безопасности: общий уровень и уровень пользователя.
Сервер общего уровня делает доступным некоторый каталог на дисковом устройстве (или другой ресурс). Для доступа может потребоваться дополнительный пароль. Таким образом, любой пользователь в сети, знающий имя сервера, имя ресурса и пароль, получает доступ к ресурсу. Серверы с безопасностью общего уровня могут использовать различные пароли для одного и того же общего ресурса, где различные пароли предоставляют различный уровень доступа.
Сервер уровня пользователя делает некоторый каталог на дисковом устройстве (или другой ресурс) доступным, но требует дополнительно, чтобы клиент предоставил имя и соответствующий пароль пользователя для получения доступа. Серверы уровня пользователя могут применить имя учетной записи и пароль, предоставленные клиентом. Серверы уровня пользователя предпочтительнее серверов общего уровня для любой новой серверной реализации, так как организации обычно считают, что сервер уровня пользователя легче администрировать. Серверы уровня пользователя могут применять имя учетной записи для проверки списков контроля доступа на отдельных файлах или иметь один список контроля доступа, который применяется ко всем файлам в каталоге.
Когда сервер уровня пользователя проверяет имя учетной записи и пароль, предоставленные клиентом, идентификатор, представляющий этот аутентифицированный экземпляр пользователя, возвращается клиенту в поле Идентификатор пользователя (UID) ответного SMB. Этот UID должен включаться во все последующие запросы, сделанные от имени пользователя с этого клиента. Сервер общего уровня не возвращает в поле UID никакой полезной информации.
Модель безопасности на уровне пользователя была добавлена после выпуска первоначального диалекта протокола CIFS, и, следовательно, некоторые клиенты могут оказаться неспособными послать имена учетных записей и пароли на сервер. Сервер в режиме безопасности на уровне пользователя, общающийся с одним из таких клиентов, будет позволять клиенту соединяться с ресурсами, даже если клиент не прислал информацию об имени учетной записи и пароле:
1. Если имя компьютера клиента идентично имени учетной записи, известной на сервере, и если предоставленный пароль для соединения с общим ресурсом совпадает с паролем этой учетной записи, неявно будет выполнен "вход пользователя в систему" с помощью этих значений. Если это не сработает, то сервер может отказать в запросе или присвоить используемое по умолчанию имя учетной записи по своему выбору.
2. Значение UID в последующих запросах клиента будет игнорироваться, и весь доступ будет проверяться в предположении имени учетной записи, выбранной выше.
Следующие примеры показывают интерфейс командной строки, позволяющий серверу предлагать дисковый ресурс, а клиенту соединяться и использовать этот ресурс.
a) NET SHARE
Команда NET SHARE при выполнении на сервере определяет имя каталога, который будет сделан доступным для клиентов в сети. Должно быть задано общее имя, которое предоставляется клиентам, желающим получить доступ к каталогу.
Примеры:
NET SHARE docs=c:\dirl\
Делает общедоступными все файлы в каталоге C:\DIR1 и его подкаталогах с общим именем docs в качестве имени, используемого для соединения с этим ресурсом.
b) NET USE
Клиенты могут получить доступ к одному или нескольким предлагаемым каталогам с помощью команды NET USE. Когда посылается команда NET USE, пользователь может свободно получить доступ к файлам без дополнительных специальных требований.
Примеры:
NET USE: d: \\SERVERl\DOCS отображает диск d: в общедоступный каталог DOCS на сервере Serverl. Пользователь может теперь обращаться к файлам на SERVER1 C:\DIR1, используя d:. Например, dir d: *.* выдаст список всех файлов на SERVER1 c:\dirl.
NET USE * \\SERVERl\DOCS mycoolpwd отображает следующий доступный диск, который использует DOCS на server 1, защищенный паролем mycoolpwd.
Для серверов уровня пользователя клиент обычно не должен предоставлять пароль с помощью команды NET USE. Если пользователю предлагается ввести пароль, обычно это указывает на сетевую проблему (например, он не может контактировать с контроллером домена, чтобы проверить полномочия). Этот сценарий предоставляет хорошую возможность проверить инструменты сетевого мониторинга (см. часть IV). Сейчас можно попробовать проверить, существует ли проблема безопасности:
NET USE * \\SERVERl\DOCS/USER:domainname\username password
Клиентское программное обеспечение должно помнить идентификатор диска, поставляемый вместе с запросом NET USE, и связать его со значением идентификатора дерева (TID), возвращаемого сервером в заголовке SMB. Последующие запросы, использующие этот TID, должны включать только имя пути доступа относительно присоединенного поддерева, так как сервер интерпретирует поддерево как корневой каталог (виртуальный корень). Когда пользователь ссылается на один из удаленных дисков, клиентское программное обеспечение просматривает свой список дисков для этого узла и включает идентификатор дерева, связываемый с этим диском в поле TID каждого запроса.
Отметим, что когда каталог объявляется общедоступным, будут затронуты все файлы, лежащие под этим каталогом. Если определенный файл находится внутри области нескольких общих ресурсов, то соединение с любой из областей общих ресурсов получает доступ к файлу с полномочиями, определенными для предложения, поименованного в NET USE. Сервер не будет проверять вложенные каталоги с более ограничительными полномочиями.
Когда создается контроллер домена, служба сервера оптимизирована для совместного использования файлов и принтеров. Это хорошо для серверов файлов и печати, но создает не оптимальную производительность для серверов регистрации. Чтобы изменить это, обратимся к сетевому апплету в панели управления (или сделаем щелчок правой кнопкой мыши по пиктограмме сети на рабочем столе), выберем сервер из закладок служб и щелкнем мышью по свойствам. Как можно видеть на рис, мы хотим выбрать максимальную производительность для сетевых приложений. Затем нажмем ОК. Примечание. Необходимо перезагрузить машину, чтобы получить какой-то эффект. Делая такие изменения, контроллер домена может утроить число одновременных регистрации — от шести до почти 20 регистрации в секунду.
Размещение сервера регистрации Когда речь идет о регистрации, чем ближе пользователь находится к контроллеру домена, тем лучше. Когда имеется удаленный сайт, не обязательно бездумно помещать BDC на другой стороне медленного соединения и надеяться на лучшее. Существуют также и другие ситуации. Должно быть рассмотрено влияние трафика WAN в связи с синхронизацией служб каталогов. В дополнение к этому, что произойдет, если линия WAN будет выключена, и службы каталогов устареют? Это только часть вопросов, которые должны быть рассмотрены до реализации. Дополнительно, скорее всего, понадобится реализовать WINS и DHCP и сконфигурировать для них репликацию, чтобы сократить этот вид трафика. Мы поговорим об этом в следующей главе, а сейчас, вероятно, лучше всего поместить BDC на другой стороне медленного соединения WAN, но это должна быть хорошо продуманная реализация.
Я ненавижу просмотр. Как правило, это долгий и утомительный процесс, а если и есть на свете что-то еще более отвратительное, чем неправильно работающий компьютер, то это медленный компьютер. Несколько часов сидеть и наблюдать за тем, как на экране вспыхивают цифры... волей-неволей задумаешься о том, можно ли как-то рационализировать этот процесс.
Если просмотр не оптимизирован, то программа просмотра создает дополнительный трафик всякий раз, когда кто-то регистрируется в сети.
Протокол РОРЗ используется как упрощенный протокол почты, который хранит сообщения на сервере, пока клиентская машина не соединится и не выгрузит их по запросу. Он делает не слишком много по обработке сообщения на сервере; служба РОРЗ просто слушает порт 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 суммирует команды РОРЗ, которые обычно встречаются в трассировках сетевого мониторинга.
