Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается, как сетевой перенаправление может поддерживать универсальное соглашение об именовании (UNC) и несколько поставщиков UNC (MUP).
MUP — это системный компонент режима ядра, отвечающий за обработку путей UNC:
Он помогает найти сетевые ресурсы, определенные как с помощью UNC.
Он направляет все удалённый доступ к файловой системе с использованием UNC-имени к сетевому перенаправлению, которое может обрабатывать запросы удалённой файловой системы. Сетевой перенаправитель — это поставщик UNC.
MUP участвует, когда приложение использует UNC-путь; например, команда командной строки:
notepad \\server\public\readme.txt
MUP получает команды, содержащие имена UNC из приложений. Он отправляет имя каждому зарегистрированному поставщику UNC и другим установленным сетевым поставщикам. Когда UNC провайдер определяет имя UNC как собственное, MUP автоматически перенаправляет будущие экземпляры этого имени к этому поставщику.
MUP не участвует во время операции, которая создает сопоставленную букву диска (например, команду NET USE). Вместо этого маршрутизатор нескольких поставщиков (MPR) и библиотека DLL поставщика в режиме пользователя Windows Networking (WNet) для сетевого перенаправления обрабатывают эту операцию. Однако библиотека DLL поставщика WNet в пользовательском режиме может напрямую взаимодействовать с драйвером сетевого перенаправления в режиме ядра во время этой операции.
Для сетевых перенаправлений, которые соответствуют модели перенаправления, представленной в Windows Vista, MUP участвует даже при использовании сопоставленного сетевого диска. Операции с файлами, выполняемые на сопоставленном диске, проходят через MUP к сетевому перенаправителю. В этом случае MUP просто передает операцию сетевому перенаправителю.
MUP является частью mup.sys двоичного файла, который также включает клиент DFS (Дистрибутивная Файловая Система).
Ядровой сетевой перенаправитель обычно также имеет библиотеку DLL провайдера WNet в пользовательском режиме для поддержки установления соединений с удаленными ресурсами (например, сопоставления букв дисков с удаленными ресурсами). MPR — это библиотека DLL в пользовательском режиме, которая устанавливает сетевые подключения на основе запросов к поставщикам WNet. Вызовы MPR являются результатом любой из следующих операций:
Команда
net use x: \\server\share, выданная из командной строки.Подключение к сетевому диску, установленное из проводника Windows.
Прямые вызовы функций WNet.
Сетевой перенаправитель должен зарегистрироваться в MUP для обработки имен UNC. В MUP может быть зарегистрировано несколько различных поставщиков UNC. Эти поставщики UNC могут быть одним или несколькими из следующих перенаправлений:
- Сетевые мини-перенаправления на основе RDBSS, таких как перенаправление блока сообщений сервера (SMB) и перенаправление WebDAV.
- Устаревшие перенаправления не основаны на RDBSS.
Разрешение префикса
MUP определяет, какой поставщик может обрабатывать UNC-путь в операции на основе имен, обычно запрос IRP_MJ_CREATE. Это определение называется "разрешением префикса". Операция разрешения префикса служит двумя целями:
Операция на основе имен, которая привела к разрешению префикса, направляется поставщику, заявляющему права на префикс. При успешном выполнении MUP гарантирует, что последующие операции на основе дескриптора (IRP_MJ_READ и IRP_MJ_WRITE, например), переходят к тому же поставщику полностью обходя MUP.
Поставщик и его указанный префикс заносятся в кэш префиксов, который поддерживается MUP. Для последующих операций на основе имен MUP использует этот кэш префикса, чтобы определить, утверждал ли поставщик префикс перед попыткой выполнить разрешение префикса. Каждая запись в этом кэше префикса подвергается времени ожидания (называемому TTL) после добавления в кэш. Запись удаляется после истечения этого срока действия, после чего MUP снова выполняет разрешение префикса для этого префикса в последующей именной операции.
MUP выполняет разрешение префикса путем выдачи запроса IOCTL_REDIR_QUERY_PATH сетевым перенаправлениям, зарегистрированным в MUP. Входные и выходные буферы для IOCTL_REDIR_QUERY_PATH выделяются из непагрегированного пула.
Сетевые редиректоры должны допускать отправителей этого IOCTL только в режиме ядра, проверяя, что элемент RequesterMode в структуре IRP является KernelMode.
MUP использует структуру QUERY_PATH_REQUEST для информации о запросе.
Поставщики UNC должны использовать структуру QUERY_PATH_RESPONSE для информации ответа.
Любая устаревшая система перенаправления (не основанная на использовании RDBSS), которая регистрируется как поставщик UNC в MUP путем вызова FsRtlRegisterUncProvider, получает запрос IOCTL_REDIR_QUERY_PATH.
Сетевой мини-перенаправитель, указывающий поддержку как поставщик UNC, получает данное префиксное утверждение, как вызов IRP_MJ_CREATE. Этот запрос создания аналогичен вызову CreateFile в режиме пользователя с установленным флагом FILE_CREATE_TREE_CONNECTION. Мини-редиректор сети не получает команду префикса как вызов MRxLowIOSubmit[LOWIO_OP_IOCTL]. Для утверждения префикса RDBSS отправляет запрос MRxCreateSrvCall на мини-перенаправление сети, а затем вызов MRxSrvCallWinnerNotify и MRxCreateVNetRoot. Когда сетевой мини-перенаправитель регистрируется в RDBSS, RDBSS копирует таблицу диспетчера драйверов для сетевого мини-перенаправителя, чтобы указать на внутренние точки входа RDBSS. Затем RDBSS получает этот IOCTL_REDIR_QUERY_PATH внутренне для мини-перенаправления сети и вызывает MRxCreateSrvCall, MRxSrvCallWinnerNotify и MRxCreateVNetRoot. Исходная IOCTL_REDIR_QUERY_PATH IRP содержится в структуре RX_CONTEXT , переданной в подпрограмму MRxCreateSrvCall . Кроме того, изменяются следующие элементы в RX_CONTEXT, передаваемые в MRxCreateSrvCall :
- Член MajorFunction имеет значение IRP_MJ_CREATE даже если исходный IRP был IRP_MJ_DEVICE_CONTROL.
- Элемент PrefixClaim.SuppliedPathName.Buffer устанавливается в значение элемента FilePathName структуры QUERY_PATH_REQUEST.
- Участник PrefixClaim.SuppliedPathName.Length установлен как элемент PathNameLength структуры `QUERY_PATH_REQUEST`.
- Член Create.NtCreateParameters.SecurityContext устанавливается в член SecurityContext структуры QUERY_PATH_REQUEST.
- Для элемента Create.ThisIsATreeConnectOpen задано значение TRUE.
- Элемент Create.Flags имеет RX_CONTEXT_CREATE_FLAG_UNC_NAME битовый набор.
Если мини-перенаправление сети хочет просмотреть сведения об утверждении префикса, можно прочитать эти элементы в RX_CONTEXT, переданных в MRxCreateSrvCall. В противном случае, он может просто попытаться подключиться к ресурсу общего пользования сервера и вернуть STATUS_SUCCESS, если вызов MRxCreateSrvCall был успешным. RDBSS заявляет о префиксе от имени сетевого мини-редиректора.
Существует один случай, когда мини-перенаправитель сети может получить этот IOCTL напрямую. Сетевой мини-редиректор может сохранить копию своей таблицы диспетчеризации драйверов перед инициализацией и регистрацией в RDBSS. После вызова RxRegisterMinirdr для регистрации в RDBSS, сетевой мини-редиректор может сохранить копию точек входа таблицы диспетчера драйверов, установленных RDBSS, и восстановить исходную таблицу диспетчера драйверов. Восстановленная таблица диспетчера драйверов должна быть изменена таким образом, чтобы после проверки полученного IRP для тех IRP, которые представляют интерес для сети мини-перенаправителей, вызов перенаправлялся в точки входа диспетчера драйверов RDBSS. RDBSS копирует таблицу диспетчера драйверов сетевого мини-перенаправителя, когда драйвер инициализирует RDBSS и вызывает RxRegisterMinrdr. Сетевой мини-перенаправитель, который зависит от rdbsslib.lib, должен сохранить свою исходную таблицу диспетчера драйверов перед вызовом RxDriverEntry из подпрограммы DriverEntry для инициализации статической библиотеки RDBSS и восстановить эту таблицу после вызова RxRegisterMinrdr. Это требование связано с тем, что RDBSS копирует таблицу диспетчера мини-перенаправления сети в подпрограммах RxDriverEntry и RxRegisterMinrdr .
Значение реестра REG_SZ ProviderOrder определяет порядок запросов поставщиков во время разрешения префикса. Это значение хранится в следующем ключе:
HKLM\System\CurrentControlSet\Control\NetworkProvider\Order
Имена отдельных поставщиков в значении реестра ProviderOrder разделяются запятыми без начальных или конечных пробелов.
Например, это значение может содержать строку:
RDPNP,LanmanWorkstation,WebClient
Учитывая UNC-путь \\<server>\<share>\<path>, MUP выдает запрос разрешения префикса, если префикс (\\<server>\<share> или \\<server>, например) не найден в кэше префикса MUP. MUP отправляет запрос на разрешение префикса каждому поставщику в следующем порядке, пока один из них не заявляет права на префикс или пока запросы не будут отправлены всем поставщикам.
Клиент TS (RDPNP)
Перенаправление SMB (LanmanWorkstation)
Перенаправитель WebDAV (WebClient)
Изменения в значении реестра ProviderOrder требуют перезагрузки, чтобы вступили в силу в MUP.
MUP использует каждое указанное имя поставщика для поиска ключа реестра поставщика в следующем ключе реестра:
HKLM\System\CurrentControlSet\Services\<ProviderName>
Затем MUP считывает значение DeviceName в подразделе NetworkProvider, чтобы найти имя устройства, с которым будет зарегистрирован поставщик. Когда поставщик фактически регистрируется, MUP сопоставляет имя устройства, переданное в системе, со списком имен устройств известных поставщиков. Затем он помещает этого поставщика в упорядоченный список в целях разрешения префикса. Порядок поставщиков в этом списке определяется порядком, указанным в значении реестра ProviderOrder, о котором говорилось ранее.
Маршрутизатор для нескольких поставщиков (MPR), библиотека DLL, работающая в пользовательском режиме, установливает сетевые подключения на основе запросов к поставщикам WNet и также соблюдает этот порядок поставщиков.
MUP выдает запрос на разрешение префикса последовательно и останавливается, как только первый поставщик примет префикс. Таким образом, в предыдущем примере, если RDPNP утверждает префикс, MUP не вызывает перенаправления SMB или WebDAV.
"Разрешение последовательного префикса" (в отличие от параллельного) предотвращает, чтобы переадресатор сети с более низким приоритетом ProviderOrder вызывал проблемы с производительностью для переадресатора сети с более высоким приоритетом ProviderOrder. Например, рассмотрим удаленный сервер с брандмауэром, настроенным для блокировки определенных типов пакетов TCP/IP (например, доступ к HTTP), но разрешить другим пользователям (например, доступ к SMB). В этом случае, даже если сетевой перенаправитель SMB настроен как первый поставщик в значении ProviderOrder и быстро присваивает префикс, перенаправитель WebDAV может существенно задержать завершение разрешения префикса, ожидая истечения времени ожидания TCP-подключения.