Compatibilidad con nomenclatura UNC y MUP

En este artículo se describe cómo un redirector de red puede admitir la nomenclatura UNC y el proveedor UNC múltiple (MUP).

MUP es un servicio de Windows que ayuda a localizar los recursos de red identificados mediante UNC (convención de nomenclatura uniforme). Es un componente en modo kernel responsable de canalizar todos los accesos de sistema de archivos remotos mediante un nombre UNC a un redirector de red (el proveedor UNC) capaz de controlar las solicitudes del sistema de archivos remotos. MUP está implicado cuando una aplicación usa una ruta de acceso UNC; por ejemplo, un comando de línea de comandos como:

notepad \\server\public\readme.txt

MUP recibe comandos que contienen nombres UNC de aplicaciones. Envía el nombre a cada proveedor UNC registrado, estación de trabajo de LAN Manager y a cualquier otro que esté instalado. Cuando un proveedor UNC identifica un nombre UNC como propio, el MUP redirige automáticamente las instancias futuras de ese nombre a ese proveedor.

MUP no está implicado durante una operación que crea una letra de unidad asignada (por ejemplo, el comando "NET USE"). Esta operación se controla mediante el enrutador de varios proveedores (MPR) y un archivo DLL de proveedor de redes de Windows (WNet) en modo de usuario para el redirector de red. Sin embargo, un archivo DLL del proveedor de WNet en modo de usuario puede comunicarse directamente con un controlador de redireccionador de red en modo kernel durante esta operación.

Antes de Windows Vista, las operaciones de archivos remotos realizadas en una unidad asignada que no representan una unidad del sistema de archivos distribuido (DFS) no pasan por MUP. Estas operaciones van directamente al proveedor de red que gestionó la asignación de letras de unidad.

Para los redireccionadores de red que se ajustan al modelo de redirector actualizado introducido en Windows Vista, MUP está implicado incluso cuando se usa una unidad de red asignada. Las operaciones de archivo realizadas en la unidad asignada pasan por el MUP al redireccionador de red. En este caso, MUP simplemente pasa la operación al redirector de red implicado.

MUP forma parte del mup.sys binario, que también incluye el cliente DFS (sistema de archivos distribuido).

Normalmente, un redirector de red de kernel también tiene un archivo DLL de proveedor WNet en modo de usuario para admitir el establecimiento de conexiones a recursos remotos (asignar letras de unidad a recursos remotos, por ejemplo). El MPR es un archivo DLL en modo de usuario que establece conexiones de red basadas en consultas a proveedores de WNet. Las llamadas a MPR son el resultado de cualquiera de las siguientes operaciones:

• Un net use x: \\server\share comando emitido desde un símbolo del sistema.

• Una conexión de letra de unidad de red establecida desde el Explorador de Windows.

• Llamadas directas a funciones de WNet.

El redireccionador de red debe registrarse con el MUP para controlar los nombres de UNC. Puede haber varios proveedores de UNC registrados con el MUP. Estos proveedores UNC pueden ser uno o varios de los siguientes redireccionadores:

• Redirectores de red basados en RDBSS, como el redirector del bloque de mensajes del servidor (SMB) y el redirector webDAV.
• Redireccionadores heredados no basados en RDBSS.

Resolución de prefijos

El MUP determina qué proveedor puede controlar una ruta de UNC en una operación basada en nombres, normalmente una solicitud IRP_MJ_CREATE. Esta determinación se conoce como "resolución de prefijos". La operación de resolución de prefijo tiene dos propósitos:

• La operación basada en nombres que dio lugar a la resolución de prefijos se enruta al proveedor que reclama el prefijo. Si se ejecuta correctamente, el MUP garantiza que las operaciones posteriores basadas en identificadores (IRP_MJ_READ y IRP_MJ_WRITE, por ejemplo) vayan al mismo proveedor omitiendo por completo al MUP.

• El proveedor y su prefijo reclamado se escriben en una caché de prefijos que mantiene MUP. En cuanto a las operaciones posteriores basadas en nombres, el MUP usa esta caché de prefijos para determinar si un proveedor ya ha reclamado un prefijo antes de intentar realizar una resolución de prefijos. Cada entrada de esta caché de prefijos está sujeta a un tiempo de espera (denominado TTL) una vez que se agrega a la memoria caché. Una entrada se produce después de que expire este tiempo de espera, en cuyo momento MUP vuelve a realizar la resolución de prefijos para este prefijo en una operación posterior basada en nombres.

El MUP realiza la resolución de prefijo creando una solicitud IOCTL_REDIR_QUERY_PATH a los redireccionadores de red registrados con el MUP. Los búferes de entrada y salida para IOCTL_REDIR_QUERY_PATH se asignan desde un grupo no paginado.

Los redireccionadores de red solo deben permitir emisores en modo kernel de este IOCTL, comprobando que el miembro RequesterMode de la estructura del IRP sea KernelMode.

MUP usa la estructura QUERY_PATH_REQUEST para la información de solicitud.

Los proveedores UNC deben usar la estructura QUERY_PATH_RESPONSE para la información de respuesta.

Cualquier redirector de red heredado (no basado en el uso de RDBSS) que se registre como proveedor UNC con MUP llamando a FsRtlRegisterUncProvider recibe la solicitud IOCTL_REDIR_QUERY_PATH.

Un minidirector de red que indica la compatibilidad como proveedor UNC recibe esta notificación de prefijo como si fuera una llamada de IRP_MJ_CREATE. Esta solicitud de creación es similar a una llamada a CreateFile en modo de usuario con el indicador FILE_CREATE_TREE_CONNECTION activado. Un minidirector de red no recibe la notificación de prefijo como una llamada a MRxLowIOSubmit[LOWIO_OP_IOCTL]. Para una notificación de prefijo, RDBSS envía una solicitud MRxCreateSrvCall al minidirector de red seguido de una llamada a MRxSrvCallWinnerNotify y MRxCreateVNetRoot. Cuando un minidirector de red se registra con RDBSS, RDBSS copia la tabla de distribución de controladores para el minidirector de red para que apunte a los puntos de entrada de RDBSS internos. A continuación, RDBSS recibe este IOCTL_REDIR_QUERY_PATH internamente para el minidirector de red y llama a MRxCreateSrvCall, MRxSrvCallWinnerNotify y MRxCreateVNetRoot. La IOCTL_REDIR_QUERY_PATH IRP original se encuentra en la estructura de RX_CONTEXT que se pasa a la rutina MRxCreateSrvCall . Además, se modifican los siguientes miembros del RX_CONTEXT pasados a MRxCreateSrvCall :

• El miembro MajorFunction cambia a IRP_MJ_CREATE aunque el IRP original fuera IRP_MJ_DEVICE_CONTROL.
• El miembro PrefixClaim.SuppliedPathName.Buffer cambia al miembro FilePathName de la estructura QUERY_PATH_REQUEST.
• El miembro PrefixClaim.SuppliedPathName.Length cambia al miembro PathNameLength de la estructura QUERY_PATH_REQUEST.
• El miembro Create.NtCreateParameters.SecurityContext cambia al miembro SecurityContext de la estructura QUERY_PATH_REQUEST.
• El miembro Create.ThisIsATreeConnectOpen se establece en TRUE.
• El miembro Create.Flags tiene el activado el bit RX_CONTEXT_CREATE_FLAG_UNC_NAME.

Si el miniredireccionador de red quiere ver los detalles de la reclamación de prefijo, puede leer estos miembros en el RX_CONTEXT pasado a MRxCreateSrvCall. De lo contrario, este puede tratar de conectarse al recurso compartido del servidor y devolver STATUS_SUCCESS si la llamada a MRxCreateSrvCall se realizó correctamente. RDBSS realiza la notificación de prefijo en nombre del minidirector de red.

Hay un caso en el que un minidirector de red podría recibir este IOCTL directamente. Un miniredireccionador de red podría guardar una copia de la tabla de distribución de controladores antes de inicializarse y registrarse con RDBSS. Después de llamar a RxRegisterMinirdr para registrarse en RDBSS, el miniredireccionador de red podría guardar una copia de los nuevos puntos de entrada de la tabla de distribución de controladores instalados por RDBSS y restaurar la tabla de distribución de controladores original. La tabla de distribución de controladores restaurada tendría que modificarse para que después de comprobar el IRP recibido para esos IRP de interés en el minidirector de red, la llamada se reenvía a los puntos de entrada de envío del controlador RDBSS. RDBSS copia a través de la tabla de distribución del controlador de un minidirector de red cuando el controlador inicializa RDBSS y llama a RxRegisterMinrdr. Un miniredireccionador de red que se vincula con rdbsslib.lib debe guardar la tabla de distribución del controlador original antes de llamar a RxDriverEntry en la rutina DriverEntry para iniciar la biblioteca estática de RDBSS y restaurar la tabla de distribución del controlador después de llamar a RxRegisterMinrdr. Este requisito se debe a que RDBSS copia a través de la tabla de distribución de minidirector de red en las rutinas RxDriverEntry y RxRegisterMinrdr .

El valor del Registro ProviderOrder de REG_SZ controla el orden en el que se consultan los proveedores durante la resolución de prefijos. Este valor se almacena en la siguiente clave:

HKLM\System\CurrentControlSet\Control\NetworkProvider\Order

Cada uno de los nombres de proveedor del valor de registro ProviderOrder están separados por comas y sin espacios en blanco iniciales o finales.

Por ejemplo, este valor podría incluir la cadena:

RDPNP,LanmanWorkstation,WebClient

Dada una ruta de acceso UNC \\<server>\<share>\<path>, MUP emite una solicitud de resolución de prefijos si el prefijo (\\server\share o \\server, por ejemplo) no se encuentra en la caché de prefijoS de MUP. MUP envía una solicitud de resolución de prefijo a cada proveedor en el orden siguiente hasta que un proveedor reclama el prefijo o hasta que se consultan todos los proveedores:

1. Cliente de TS (RDPNP)

2. Redireccionador de SMB (LanmanWorkstation)

3. Redireccionador de WebDAV (WebClient)

Los cambios en el valor del Registro ProviderOrder requieren un reinicio para surtir efecto en MUP.

El MUP usa cada nombre de proveedor que aparece para buscar la clave de registro del proveedor en la siguiente clave de registro:

HKLM\System\CurrentControlSet\Services\<ProviderName>

Tras esto, el MUP lee el valor DeviceName en la subclave NetworkProvider para buscar el nombre del dispositivo con el que se registrará el proveedor. Cuando el proveedor se registra realmente, MUP coincide con el nombre del dispositivo pasado con la lista de nombres de dispositivo de proveedores conocidos. A continuación, coloca el proveedor en una lista ordenada para los fines de la resolución de prefijos. El orden de los proveedores de esta lista se basa en el orden especificado en el valor del Registro ProviderOrder descrito anteriormente.

El enrutador de varios proveedores (MPR), el archivo DLL en modo de usuario que establece conexiones de red basadas en consultas a proveedores de WNet, también respeta este orden de proveedor.

El MUP genera la solicitud de resolución de prefijos en serie y se detiene en cuanto el primer proveedor reclama el prefijo. Por lo tanto, en el ejemplo anterior, si RDPNP reclama un prefijo, MUP no llama a los redireccionadores SMB o WebDAV.

"Resolución de prefijo serie" (frente a paralelo) impide que un redirector de red con menor prioridad ProviderOrder cause problemas de rendimiento para un redirector de red con mayor prioridad ProviderOrder. Por ejemplo, piense en un servidor remoto, con un firewall implementado, configurado para bloquear determinados tipos de paquetes TCP/IP (acceso a HTTP, por ejemplo), pero que sirve para permitir el acceso a otros (por ejemplo, SMB). En este caso, incluso si el redirector de red SMB está configurado como el primer proveedor en el valor ProviderOrder y reclama el prefijo rápidamente, el redirector de WebDAV podría retrasar significativamente la finalización de la resolución de prefijo esperando a que se agote el tiempo de espera de la conexión TCP.