Поделиться через

Поддержка именования UNC и MUP

  • Статья

В этой статье описывается, как сетевой перенаправление может поддерживать универсальное соглашение об именовании (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 (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. Когда мини-перенаправление сети регистрируется в RDBSSS, 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 для регистрации в RDBSSS сетевой мини-перенаправление может сохранить копию точек входа таблицы диспетчера драйверов, установленных RDBSS и восстановить исходную таблицу диспетчера драйверов. Восстановленная таблица диспетчера драйверов должна быть изменена таким образом, чтобы после проверки полученного IRP для этих ip-адресов, интересующих сети мини-перенаправления, вызов перенаправляется в точки входа драйвера RDBSS. RDBSS копирует в таблицу диспетчера драйверов мини-перенаправления сети, когда драйвер инициализирует RDBSSS и вызывает 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 отправляет запрос разрешения префикса каждому поставщику в следующем порядке, пока поставщик не утверждает префикс или пока не будут запрашиваться все поставщики:

  1. Клиент TS (RDPNP)

  2. Перенаправление SMB (LanmanWorkstation)

  3. Перенаправление 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-подключения.