Compatibilidad con nomenclatura UNC y MUP

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

MUP es un componente de modo kernel proporcionado por el sistema responsable de controlar las rutas UNC:

• Ayuda a localizar los recursos de red identificados como que usan UNC.

• Canaliza todos los accesos remotos del sistema de archivos mediante un nombre UNC a un redirector de red capaz de controlar las solicitudes del sistema de archivos remotos. El redirector de red es el proveedor de UNC.

MUP interviene cuando una aplicación utiliza una ruta 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 de UNC registrado y a cualquier otro proveedor de red que esté instalado. Cuando un proveedor de UNC identifica un nombre de UNC como propio, MUP redirige automáticamente las instancias futuras de ese nombre a ese proveedor.

MUP no interviene durante una operación que cree una letra de unidad asignada (por ejemplo, el comando "NET USE"). En su lugar, esta operación se gestiona 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.

Para los redirectores de red que se ajustan al modelo de redirector introducido en Windows Vista, el MUP interviene 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, el MUP solo transfiere la operación al redirector de red usado.

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

Normalmente, un redirector de red de kernel también tendrá un archivo DLL de proveedor de WNet en modo de usuario que admite que se realicen 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 al MPR se derivarían de cualquiera de las siguientes operaciones:

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

• Una conexión de letra de unidad de red establecida a través del 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 de UNC pueden ser uno o varios de los siguientes redirectores:

• Miniredirectores de red basados en RDBSS, como el redirector del bloque de mensajes del servidor (SMB) y el redirector WebDAV.
• Redirectores 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 o se conoce como "resolución de prefijos". La operación de resolución de prefijos tiene dos finalidades:

• La operación basada en nombres que dio lugar a la resolución de prefijos se redirecciona 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 insertan en una caché de prefijos mantenida por el 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 depende de un tiempo de espera (denominado TTL) una vez que se agrega a la memoria caché. La entrada se descarta después de que termine el tiempo de espera, en cuyo momento el MUP volverá a realizar la resolución de prefijos en 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.

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

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

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

Un miniredirector de red que sea compatible como proveedor de UNC recibirá esta reclamació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 miniredirector de red no recibirá la reclamación de prefijo como una llamada a MRxLowIOSubmit[LOWIO_OP_IOCTL]. En una reclamación de prefijo, RDBSS enviará una solicitud MRxCreateSrvCall al miniredirector de red seguida de una llamada a MRxSrvCallWinnerNotify y MRxCreateVNetRoot. Cuando un miniredirector de red se registra con RDBSS, RDBSS copia la tabla de distribución del controlador del miniredirector de red para apuntar a puntos de entrada de RDBSS internos. Tras esto, RDBSS recibe esta IOCTL_REDIR_QUERY_PATH internamente para el miniredirector de red y llama a MRxCreateSrvCall, MRxSrvCallWinnerNotify y MRxCreateVNetRoot. El IRP IOCTL_REDIR_QUERY_PATH original se incluirá en la estructura RX_CONTEXT pasada a la rutina MRxCreateSrvCall. Además, se modificarán 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 cambia a 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 realizará la reclamación de prefijo en nombre del miniredirector de red.

Hay un caso en el que un miniredirector 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 los interesados en el miniredirector de red, la llamada se reenvía a los puntos de entrada de distribución del controlador de RDBSS. RDBSS copiará a través de la tabla de distribución del controlador de un miniredirector de red cuando el controlador inicie RDBSS y llame 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 del miniredirector de red en las rutinas RxDriverEntry y RxRegisterMinrdr.

El valor del Registro REG_SZ ProviderOrder 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 la ruta de UNC \\<server>\<share>\<path>, el MUP genera 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. El MUP envía una solicitud de resolución de prefijos a cada proveedor en el orden siguiente hasta que un proveedor reclama el prefijo o hasta que se han consultado 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 que surta efecto en el 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, el MUP coteja el nombre del dispositivo pasado con la lista de nombres de dispositivos 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 viene determinado por el orden indicado en el valor de registro ProviderOrder descrito anteriormente.

El orden de proveedores también lo aplica 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.

El MUP genera la solicitud de resolución de prefijos en serie y se detiene en cuanto el primer proveedor reclama el prefijo. Por tanto, en el ejemplo anterior, si RDPNP reclama un prefijo, el MUP no llamará a los redirectores de 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 de SMB está configurado como primer proveedor en el valor ProviderOrder y reclama el prefijo rápidamente, el redirector de WebDAV podría ralentizar significativamente que finalizara la resolución de prefijos al esperar a que llegue el límite de tiempo de la conexión TCP.