Windows 7 y Windows Server 2008 R2

  • Artículo

BranchCache y DirectAccess: Mejora de la experiencia en las sucursales

Gary Olsen

Mientras la plebe por fin echa un primer vistazo a Windows Server 2008 R2 y Windows 7, los elegidos han estado trabajando con el código de Release Candidate (RC) desde mayo y la versión de salida a fabricación (RTM) desde agosto. Independiente del grupo al que pertenezca, probablemente esté lleno de expectativas. Quizás lo invitaron a una “fiesta informal” de la vista preliminar de Windows 7 como a mí, por ejemplo. (Mi yerno dio una, pero sólo porque quería el software gratuito de Microsoft.) Incluso si se perdió toda la anticipación, no pudo evitarse cada uno de los muchos informes noticiosos que alaban o cuestionan las nuevas características de estos productos, los cuales provienen de un árbol de código nuevo y constituyen sistemas operativos nuevos.

BranchCache y DirectAccess, posiblemente las joyas de la corona de estas versiones, valen la pena su atención. Con BranchCache, Microsoft apunta a brindar a los empleados de sucursales las mismas experiencias de trabajar con archivos que sus colegas en la oficina corporativa. Con DirectAccess, Microsoft apunta a usuarios remotos que se conectan a redes corporativas mediante redes privadas virtuales (VPN).

Como ocurre normalmente con Microsoft, sólo obtiene lo bueno en los productos nuevos. En este caso, sólo puede implementar clientes de BranchCache y Windows 7 y servidores 2008 R2. Observemos más detenidamente cada una de estas nuevas características.

BranchCache

BranchCache mejora la experiencia de sucursales al guardar en memoria caché archivos que se usan comúnmente a nivel local, ya sea en un servidor de Windows Server 2008 R2 o en estaciones de trabajo de los usuarios, en vez de obligarlos a obtener acceso a archivos mediante recursos compartidos de red ubicados a nivel central. BranchCache es genial, pero hay advertencias.

TI puede implementar BranchCache en el modo Caché distribuida o modo Caché hospedada (ver Figura 1). TI configura el modo mediante Directiva de grupo, de manera que al utilizar el modo hospedado en una oficina y el modo distribuido en otra requiere implementar dos directivas y planear estructuras de unidad organizacional (OU) según corresponda. Microsoft recomienda implementar el modo Caché distribuida en sitios de 50 o menos clientes, pero dependerá de la velocidad y ancho de banda del vínculo WAN, así como de otros factores. El modo Caché distribuida requerirá discos duros más grandes y quizás memoria y otros recursos, así que en algún momento será más ventajoso utilizar el modo Caché hospedada, sobre todo si existe un servidor de 2008 R2 en el sitio. Además, el modo Caché distribuida sólo puede funcionar en una subred local. Por lo que si existen varias subredes en un sitio, entonces un cliente en cada subred tendrá que almacenar en caché el archivo para que otras personas en esa subred lo descarguen. Sin embargo, el modo Caché hospedada puede atender varias subredes en el sitio, así que esa sería otra razón para elegirlo.

Figura 1 Una sucursal puede utilizar BranchCache ya sea en modo distribuido u hospedado.

En el modo Caché distribuida, ningún servidor de archivos reside en la sucursal. En su lugar, a través de una directiva, las máquinas de todos los usuarios son clientes de BranchCache, es decir, todas tienen la capacidad de almacenar en caché documentos que otras personas en la sucursal pueden descargar (si son la versión actual).

Por ejemplo, digamos que Caroline solicita un documento, Reports.docx, de un servidor de archivos habilitado para BranchCache en el sitio central. BranchCache envía metadatos que describen el contenido del archivo. Los valores hash en los metadatos se usan entonces para buscar contenido en la subred local. Si no se encuentra, se almacena una copia en caché en el disco local de su equipo. Más tarde ese día, Tyler debe modificar el documento Reports.docx, de manera que se pone en contacto con el recurso compartido en el servidor de archivos de la oficina central para obtener una copia para editarlo. El servidor de archivos vuelve a los metadatos, luego el cliente busca el contenido, que se encuentra y descarga desde el equipo de Caroline. Esto se hace de manera segura mediante una clave cifrada derivada de los valores hash de los metadatos. Al día siguiente, Abigail necesita modificar el mismo documento. El proceso es el mismo, pero abrirá la copia almacenada en caché en el equipo de Tyler. Nuevamente, la información de la versión se mantiene en el servidor. Los clientes se ponen en contacto con el servidor para determinar si existe una copia de la versión más reciente en su sitio.

Este es uno de los escenarios de BranchCache que entrarán en juego cuando los usuarios trabajen con diversos documentos. Los otros dos son:

  • El trabajador de una sucursal pide al servidor de archivos de la oficina principal un documento que no está en la memoria caché de un equipo local. El usuario recibe una copia, la cual se almacena en caché a nivel local.
  • El trabajador de una sucursal pide al servidor de archivos un documento que está en la memoria en el sitio local, pero el equipo está apagado. El cliente obtiene otra copia del servidor de archivos y la almacena en caché en su equipo. Futuras solicitudes conducirán a esta ruta, que es la copia en caché más reciente.

En cada caso, los documentos también se guardan en el servidor de archivos de la oficina principal. De esa manera, si Caroline vuelve y desea obtener acceso al documento, pero el equipo de Abigail que ahora guarda la versión más reciente está apagado, recibirá el documento desde el servidor de la oficina principal.

Con el modo Caché hospedada, TI configura un servidor de archivos Windows 2008 R2 en la sucursal con BranchCache al instalar la característica BranchCache y configurar una directiva de grupo que diga a los clientes que utilicen el modo Caché hospedada. El procedimiento descrito para el modo Caché distribuida funciona de la misma manera aquí, pero los archivos se almacenan en caché en un servidor BranchCache configurado a nivel local en lugar de los equipos de los usuarios.

Nota: los metadatos de contenido que mantiene el servidor de archivos en el sitio de la oficina central se envían a cada cliente cuando se solicita un archivo desde un servidor habilitado con BranchCache. Esto se usa para determinar si algún cliente o servidor local (dependiendo de qué modo caché se use) posee la copia más reciente.

El servidor habilitado con BranchCache en la sucursal se puede utilizar para otros propósitos, como un servidor web o Windows Server Update Services (WSUS). Se deben atender consideraciones especiales en estos casos y se describen en laGuía de implementación de BranchCache de Microsoft y la Guía para el usuario pionero de BranchCache de Microsoft.

Configuración de BranchCache

Para configurar BranchCache, tendrá que entender cómo funcionan los objetos de directiva de grupo (GPO) y cómo configurarlos en su estructura de OU para afectar a los equipos de cada sitio. Recuerde que todos los servidores involucrados en el escenario de BranchCache deben ser Windows Server 2008 R2 y todos los clientes, Windows 7. Este es el proceso:

Paso 1. Instalar la característica BranchCache mediante el Administrador de servidores.

 

Paso 2. Si usa BranchCache en un servidor de archivos, tendrá que instalar la función Servicios de archivo así como BranchCache para archivos remotos (ver Figura 2).

Figura 2 Una instalación de BranchCache requiere habilitar los Servicios de archivo y BranchCache para funciones de archivos remotos.

Paso 3. Configurar un GPO de BranchCache. Vaya a Configuración de equipo | Directivas | Plantillas administrativas | Red | BranchCache. Verá cinco configuraciones posibles:

  • Active BranchCache. Esto tiene que habilitarse para todas las aplicaciones de BranchCaching (ver Figura 3). Tenga en cuenta que habilitar BranchCache sin habilitar la configuración de directiva de modo Caché distribuida u hospedada provoca que el cliente de Windows 7 local almacene en caché los archivos localmente. Esto es útil si varios usuarios utilizan un equipo.

     

Figura 3 En la Consola de administración de directiva de grupo, habilite BranchCache para aplicar almacenamiento en caché en las sucursales.

  • Configure el modo Caché distribuida de BranchCache. Esto se aplica a todos los clientes en los GPO.
  • Configure el modo Caché hospedada de BranchCache. Especifique un servidor para hospedar la caché. Estas funciones se excluyen mutuamente. Sólo se puede configurar una para el sitio.
  • Configure BranchCache para archivos de red. Si no se configura o deshabilita, esto define un umbral de latencia de 80 ms. Si la solicitud de archivos demora más de 80 ms, entonces el archivo se irá a la memoria caché. Habilite esta configuración y cambie el valor de latencia según se desee.
  • Configure el porcentaje de espacio en disco para la caché de equipo de cliente. Esto está configurado de manera predeterminada al 5 por ciento del disco del usuario. Tendrá que jugar con esto para obtener la cantidad correcta y atender la caché frente a dar al usuario el espacio requerido. Esto puede ser un problema si tiene una configuración de disco que varía muchísimo en tamaño, ya que algunos tendrán mayor capacidad en caché que otros.

Set Disk Space

 

Paso 4. Configurar “LanMan Server” de GPO en la directiva de BranchCache. En la misma área del GPO en el Paso 3, vaya a la configuración de LanMan Server y mire las propiedades para “Publicación de hash para BranchCache”. Las tres opciones son:

  • Anular el permiso de publicación de hash en todas las carpetas compartidas.
  • Permitir la publicación de hash para todas las carpetas compartidas.
  • Permitir la publicación de hash sólo para carpetas compartidas en las cuales BranchCache está habilitado.

Los servidores que ejecutan la función de servidor de Servicios de archivo en servidores 2008 R2, que se desea sean servidores de contenido de BranchCache, también deben ejecutar la función de BranchCache para Servicios de archivo de red y se debe habilitar la publicación de hash. BranchCache también se habilita individualmente en recursos compartidos de archivo. La publicación de hash se puede habilitar individualmente en un servidor (como para una configuración de servidor sin dominio) o en grupos de servidores mediante directiva de grupo. Por tanto, se puede habilitar BranchCache en todas las carpetas compartidas, algunas carpetas compartidas o bien deshabilitarla por completo.

 

Paso 5. Configurar el GPO en Windows Firewall para permitir el puerto TCP 80 entrante (aplicado al equipo de cliente).

Paso 6. Después de configurar todo, y si el recurso compartido de archivo existe con los archivos de los usuarios, vaya a Administrador de servidores | Servicios de archivo | Administración de recursos compartidos y almacenamiento. En el panel central están los recursos compartidos. Haga clic con el botón secundario en el recurso compartido y seleccione Propiedades y luego haga clic en Avanzado. En la ficha Almacenamiento en caché, habilite BranchCache (ver Figura 4). Nota: si la opción BranchCache no está disponible, entonces la característica BranchCache no se instaló correctamente o bien la directiva está configurada en deshabilitar, como se mencionó con anterioridad.

Figura 4 Habilite compartir archivos con BranchCache mediante controles de administración de recursos compartidos y almacenamiento.

Configuración de cliente de BranchCache

De manera predeterminada, todos los clientes de Windows 7 están habilitados para BranchCache, lo cual significa que no hay nada que habilitar en el cliente mismo. Sin embargo, se requieren algunos pasos relacionados con el cliente:

  • Ajuste la configuración de firewall. Aunque se mencionó anteriormente, existen otros requisitos para el modo Caché hospedada. Consulte los documentos de BranchCache de Microsoft mencionados al final de este artículo.
  • Los clientes deben estar en una unidad organizativa que contenga una directiva que habilite BranchCache y defina qué modo de caché se usará. Nuevamente, consulte los documentos al final de este artículo para obtener más detalles.

BranchCache: lo bueno

Esto es lo que me gusta de BranchCache:

  • Puede utilizar el sistema de transferencia inteligente en segundo plano (BITS) para habilitar las transferencias de archivo en segundo plano si el usuario inició sesión, incluso si la aplicación existe. Esta es una gran característica para sucursales conectadas por vínculos lentos. Si fuera necesario reiniciar un sistema, la transferencia de archivos continúa después de que eso finaliza. Para que esto funcione, claro está, las aplicaciones deben escribirse para aprovechar el BITS.
  • BranchCache se puede configurar a través de la utilidad de línea de comando Netsh y se encuentra bien documentado en el sitio de BranchCache para Windows Server R2 de TechNet.
  • Puede supervisar el rendimiento de BranchCache a través de contadores para el cliente, el servidor de archivos y el host de caché. No sólo son útiles para diagnosticar rendimiento, hasta donde puedo distinguir, observar estos contadores es la única manera de ver si el cliente realmente obtiene una copia en caché.
  • El entorno de BranchCache se puede controlar a través de una directiva de grupo.

BranchCache: lo malo

BranchCache ciertamente tendrá su lugar, pero cuidado con estos inconvenientes:

  • Debido a que el modo Caché distribuida en esencia transforma toda estación de trabajo en un servidor de archivos, las máquinas de cliente que hospedan muchos de los archivos a los que se obtiene acceso con frecuencia podrían sufrir problemas de rendimiento. Esto requerirá algunas pruebas para determinar el verdadero efecto.
  • En algunos casos, es posible que los clientes requieran espacio adicional en disco para permitir tamaños de caché suficientes.
  • Almacenar clientes en caché ahora será competir con colegas por recursos de red.
  • Es posible encontrar algunos retrasos durante el proceso inicial de almacenamiento en caché o cuando un archivo no está disponible en esta memoria. Sólo clientes de Windows 7 y servidores Windows Server 2008 R2 pueden participar, así que una implementación total de esta característica puede demorar un poco.

Si puede justificar colocar un servidor de archivos en la sucursal, ¿por qué no utilizar los recursos compartidos de archivos distribuidos (DFS)? En vez de enredarse con archivos en caché, puede utilizar la replicación de sistemas de archivos distribuidos (DFS-R) para replicar los archivos y mantener un espacio de nombres con DFS. Es posible que encuentre desventajas para almacenar en caché los archivos de red y quizás BranchCache funcionará en recursos compartidos de DFS. O quizás encontrará algún límite de rendimiento en que la caché sea más eficiente que DFS-R. Por otra parte, el impacto en el servidor para BranchCache sería menor que en una configuración de DFS completamente desarrollada. El punto es que tendrá que estudiar sus necesidades y examinar las opciones disponibles con BranchCache. Desde luego, cada entorno es diferente y lo que puede provocar problemas en algunas sucursales no lo hará en otras. No existe una respuesta correcta para todas las situaciones.

DirectAccess

Con DirectAccess, Microsoft aborda la deficiente experiencia de VPN que los usuarios han tenido desde Windows 2000, incluso con muchas mejoras desde la implementación inicial. Un cliente configurado con DirectAccess puede obtener acceso a un sitio de intranet desde una ubicación remota sin tener que establecer un vínculo de VPN de manera manual. Además, para su gran regocijo, el personal de TI puede administrar máquinas remotas por una conexión de Internet en vez de a través de la VPN. Incluso sin DirectAccess, un usuario remoto puede aprovechar la nueva característica de VPN de reconexión automática. Así que si estoy trabajando en casa, conectado a la intranet de mi empresa y el vínculo de Internet se cae, la VPN restablecerá la conexión cuando Internet esté disponible (sin molestarme con tener que volver a conectarme y reingresar mis credenciales como tendría que haberlo hecho, a menudo muchas veces, sin DirectAccess)

De hecho, desde el punto de vista de un usuario, DirectAccess es invisible. Cuando un usuario en un cliente habilitado hace clic en el vínculo de intranet, DirectAccess controla la conexión y desconexión. Los usuarios no tienen que abrir Connection Manager, ingresar sus credenciales, esperar por la conexión y así sucesivamente.

Aunque la conexión remota es en directo, el usuario tiene una configuración de “túnel dividido” de manera predeterminada (ver Figura 5). Esto permite el acceso simultáneo a la intranet, la red local (para el uso de dispositivos como impresoras) e Internet. En un escenario de VPN típico sin el túnel dividido, conectarse a Internet significa primero saltar a la intranet y luego pasar a la puerta de enlace de la red corporativa para obtener conectividad. Además, no tengo acceso a mi red local, aunque es posible solucionarlo. Así que nuevamente, DirectAccess está diseñado para proporcionar al usuario remoto una experiencia más “de oficina” que lo que puede ofrecer una VPN tradicional.

 

Figura 5 DirectAccess permite una configuración de túnel dividido para conectividad simultánea a la red corporativa e Internet.

Desde la perspectiva de TI, una vez que el equipo está en Internet (recuerde que DirectAccess siempre está habilitado si está instalado), es fácil aplicar (y asegurar a través de conexiones IPsec) parches, directivas y otras actualizaciones.

Requisitos de DirectAccess

En una configuración básica de DirectAccess, el servidor DirectAccess está en la red perimetral, desde donde proporciona al usuario remoto conectividad a recursos internos dentro de los que se incluyen los servidores de aplicaciones, las entidades de certificación (CA), el DNS y los controladores de dominio (DC). Las CA y los servidores de aplicaciones se deben configurar para aceptar el tráfico IPv6. Estos son los componentes esenciales de una configuración de DirectAccess.

  • En el dominio de Active Directory, los clientes de DirectAccess sólo podrán obtener acceso a los DC de Windows 2008 ó 2008 R2.
  • Las definiciones de directiva de grupo deben reforzar la configuración de DirectAccess para:
    • Identificar clientes de DirectAccess.
    • Configurar la tabla de directivas de resolución de nombres (NRPT).
    • Eliminar el protocolo de direccionamiento automático de túnel dentro de un sitio (ISATAP) desde la lista de restricción global de DNS.
  • El servidor DirectAccess debe:
    • Ser miembro del dominio de Active Directory.
    • Ejecutarse en Windows Server 2008 R2.
    • Tener dos adaptadores de red configurados (uno para intranet y el otro para conectividad de Internet).
    • Tener dos direcciones IPv4 estáticas consecutivas solucionables externamente.
  • Estar instalado con la “característica” de administración de DirectAccess (a través del Administrador de servidores) y configurar la ejecución del asistente para configuración.

 

  • El servidor ISS/web habilita las funciones que determinan si se pueden alcanzar los recursos de intranet. Los clientes habilitados con DirectAccess deben configurar los servidores de aplicaciones para permitir el acceso.
  • Para uso con la CA requerida, instale Servicios de certificados de Active Directory y emita certificados de autenticación.
  • Debe haber disponible una red IPv6 nativa o tecnologías de transición a través de la intranet.
  • Al utilizar directivas IPsec para autenticación segura y cifrado de conexión de DirectAccess, el cliente se autentica antes de que el usuario inicie sesión.
  • Puede encontrar excepciones necesarias de firewall en la Guía para el usuario pionero de DirectAccess.

Como puede ver, DirectAccess no es para los débiles de corazón. El solo requisito de IPv6 sin duda levantará inquietud (y requerirá que la mayoría de las organizaciones implementen tecnologías de transición), pero 2008 R2 sí tiene los componentes. Además, tiene que habilitar la seguridad a través de una infraestructura de clave pública (PKI), proporcionar servicios de autenticación y configurar identificación de IPv6 para servidores de aplicaciones. Antes de ejecutar el asistente de instalación de DirectAccess, también tiene que configurar los grupos de seguridad, establecer directivas de firewall, instalar el DNS y completar varios otros requisitos previos.

Servidor DirectAccess

El servidor DirectAccess realiza muchas funciones, definidas a través del asistente de instalación de DirectAccess del Administrador de servidores (ver Figura 6).

Figura 6 Iniciar instalación de DirectAccess a través del Administrador de servidores.

El asistente de DirectAccess realiza cuatro tareas esenciales. A través del asistente:

  1. Identificar clientes activados con DirectAccess. Puede enumerar grupos de seguridad de otros dominios o bosques aquí, si se configuraron las confianzas. Debe definir grupos de seguridad adecuados antes de ejecutar el asistente.
  2. Definir la conectividad y seguridad (certificados) para el servidor DirectAccess. Identificará cuál interfaz de red está por el lado de Internet y cuál se conecta a la intranet. Instalar la CA y crear los certificados antes de ejecutar el asistente de instalación de DirectAccess. Además, definir la directiva de tarjeta inteligente.
  3. Identificar los servidores DNS, DC y, opcionalmente, de administración y otras infraestructuras para uso en el entorno de DirectAccess. También debe identificar un servidor altamente disponible como el servidor de ubicación de red. El servidor DirectAccess puede asumir esta función.
  4. Identificar los servidores de aplicaciones configurados para aceptar conexiones desde clientes de DirectAccess. La autorización predeterminada no es ninguna autorización adicional de extremo a extremo, pero puede seleccionar opciones de seguridad basadas en directivas IPsec.

DNS y el NRTP

Tal como se mencionó anteriormente, los clientes de DirectAccess pueden obtener acceso a la intranet de manera directa. Para permitir esto, debe implementar el NRPT, el cual define los servidores DNS por espacio de nombres DNS en vez de interfaz de red. Pienso en esto como la manera en que el reenvío condicional funciona en servidores DNS de Windows 2003 y 2008, donde puede definir los espacios de nombres de DNS con la dirección IP correcta para conectarse al servidor. NRPT permite que un cliente evite la iteración normal de DNS y vaya directamente al servidor DirectAccess.

Así es cómo funciona NRPT (ver Figura 7):

  1. Una solicitud de consulta de nombre coincide con un espacio de nombres configurado para la intranet corporativa, que apunta al servidor DirectAccess.
  2. El NRPT contiene la dirección IP y el nombre de dominio completo (FQDN) del servidor de DirectAccess. Cuando se utiliza la dirección IP, la conexión con el servidor DNS se cifra por motivos de seguridad.
  3. Cuando se utiliza el FQDN, se debe resolver a través de Internet y encontrar el servidor DNS corporativo.
  4. Si el cliente envía una solicitud de resolución de nombre para un espacio de nombres no definido en el NRPT (como www.microsoft.com), entonces corresponde una resolución de nombre normal a través de Internet.

Figura 7 El NRPT permite la definición de los servidores DNS por espacio de nombres DNS en vez de interfaz.

 

El NRPT se configura durante la instalación de DirectAccess en la página de instalación de infraestructura del servidor y el asistente completa la dirección IPv6 del servidor DNS. La directiva de resolución de nombre, una nueva configuración de directiva de grupo para 2008 R2, define la configuración de directiva específica como IPsec, servidor DNS y cómo ocurre el retroceso de resolución de nombre cuando el espacio de nombres no está en la red consultada. Encontrará esto en Configuración del equipo| Configuración de Windows | Directiva de resolución de nombres (no olvide que debe ingresar los espacios de nombres con un punto al principio “.”, por ejemplo, .emea.corp.net).

Puede exponer contenido de NRPT con el comando Netsh: Directiva de mostrar nombre de Netsh.

Esto mostrará los espacios de nombres definidos.

Exclusiones de Firewall

Las exclusiones de firewall dependerán de cómo implemente la red IPv6 y de si utiliza tecnologías de transición. Además, cualquier servidor de archivos o aplicaciones al que los clientes remotos se deban conectar necesitarán Windows Firewall configurado adecuadamente. En la Figura 8 y Figura 9, más abajo, se muestran las exclusiones de firewall para el firewall en Internet e intranet del servidor DirectAccess, respectivamente. Obviamente sólo necesita configurar exclusiones para las tecnologías que está utilizando. (Tenga en cuenta que aun cuando en la Figura 9 aparece IPv4+NAT-PT, Windows 2008 R2 no lo implementa.)

 

Figura 8 Configuración de firewall para el firewall de Internet

Tecnología de transición Protocolo por permitir
Teredo UDP 3544
6to4 Protocolo IP 41
IP-HTTPS TCP 443
IPv6 nativo ICMPv6, Protocolo 50

 

 

Figura 9 Configuración de firewall para el firewall de intranet

 

Protocolo Tecnología IPv6
ISATAP IPv6 nativo IPv4 + NAT-PT
Protocolo 41 X    
TCP   X X
UDP   X X
ICMPV6   X  
Toda la conectividad IPv6   X  
UDP 500 IKE/AuthIP   X X

 

Conectividad - IPv6

Debido a que IPv6 permite que los clientes de DirectAccess mantengan conectividad continua con los recursos en la red corporativa, todos deben ejecutar el protocolo. Incluso si tiene una red IPv6 implementada por completo, es posible que permitir conectividad remota requiera el uso de una tecnología de transición que permitiría al cliente de DirectAccess conectarse con recursos Ipv4 al encapsular IPv6 dentro de paquetes IPv4. Estas tecnologías incluyen 6to4, IP-HTTPS y Teredo.  ISATAP también corresponde a una tecnología de encapsulación, pero sólo se usa internamente. No voy a entrar en descripciones detalladas aquí, pero en la Figura 10 se muestran opciones básicas de conexión.

 

Figura 10 Opciones de conexión preferida para clientes de DirectAccess

 

Si al cliente se le asigna: Método de conectividad preferido:
Dirección de IPv6 enrutable globalmente Dirección de IPv6 enrutable globalmente
Dirección IPv4 pública 6to4
Dirección IPv4 privada (NAT) Teredo
Si el cliente no se puede conectar mediante las opciones anteriores IP-HTTPS

* Fuente: Microsoft*

Por el lado de la intranet, sin IPv6 nativo, DirectAccess permite el uso de ISATAP, lo cual genera una dirección IPv6 desde una dirección IPv4 e implementa su propia detección de vecinos. ISATAP utiliza clientes con DirectAccess activado para obtener acceso a recursos en una red IPv4. Por ejemplo, cuando un cliente de ISATAP arranca, debe encontrar un enrutador ISATAP. Lo hace emitiendo una consulta de DNS para el ISATAP.<nombre de dominio>. De manera que para Corp.net, buscaría .corp.net. de ISATAP. DNS de Windows 2008 implementa GlobalQueryBlockList, una característica adicional que incluye ISATAP de manera predeterminada. Esto provoca que se ignore cualquier solicitud de ISATAP.<nombre de dominio>. Por lo tanto, debe borrar ISATAP de la lista. Hágalo mediante el comando DNSCMD o a través de una entrada de registro.

Ante la solicitud de un comando, ingrese dnscmd /config /globalqueryblocklist wpad y presione Entrar. Esto definirá que GlobalQueryBlockList sólo contiene WPAD (por lo tanto, se elimina ISATAP). También puede conseguirlo si va a la clave de registro en

HKLM:\System\Current Control Set\Services\DNS\Parameters. Edite GlobalQueryBlockList y elimine ISATAP.

También puede implementar 6to4 de manera individual en hosts o en una red entera y transmitir paquetes IPv6 por una red IPv4. Como dato interesante, si 6to4 se implementa para toda una red, requiere sólo una dirección IPv4. No admite tráfico entre hosts únicamente de IPv4 e IPv6.

Teredo también proporciona paquetes IPv6 para que se enruten a redes IPv4, pero se utiliza cuando el cliente está detrás de un servidor de traducción de direcciones de red (NAT) que no está configurado para IPv6. Almacena paquetes IPv6 en el datagrama IPv4 que permite reenvíos desde NAT.

Windows 7 y Server 2008 R2 han implementado un protocolo denominado IP-HTTPS que incluye en el túnel paquetes IPv6 en un IPv4 HTTPS. Aunque IP-HTTPS tiene un rendimiento más deficiente que los otros protocolos, puede agregar servidores IP-HTTPS adicionales para mejorarlo un poco. IP-HTTPS es un protocolo bastante sencillo de habilitar para lograr que la conectividad de red IPv6 en IPv4 funcione.

Al diseñar la configuración de cliente de DirectAccess, puede utilizar DNS y NRTP para separar el tráfico de Internet y de la intranet, o bien puede usar algo llamado Forzar tunelización y forzar todo el tráfico a través del túnel. Forzar tunelización, lo cual requiere IP-HTTPS, se habilita a través de una configuración de directiva de grupo Configuración de equipo\Directivas\Plantillas administrativas\Red\Conexiones de red\Enrutar todo el tráfico a través de la red interna. Esta directiva debería aplicarse a los clientes de DirectAccess. Anteriormente mencioné que los clientes de DirectAccess pueden obtener acceso a recursos locales mientras están conectados a la intranet. Esto también corre para clientes de IP-HTTPS, pero si el usuario trata de obtener acceso a sitios de Internet, por ejemplo, se enrutaría a través de la intranet.

Ciertamente que el requisito de IPv6 y las complejas configuraciones son desventajas en DirectAccess, pero quedan rápidamente eclipsadas por las mejoras en la experiencia de usuario y la facilidad de administración de cliente remoto para TI.

Gran promesa

El número de trabajadores remotos, ya sea que estén en una sucursal, en la oficina de su casa o en ruta, está aumentado. BranchOffice y DirectAccess representan una gran promesa para las sucursales y otros trabajadores remotos, y sería sabio de parte de los administradores de TI que los investigaran. Ninguna de estas consideraciones representa una instalación rápida y sencilla, y existen muchas opciones y características disponibles. Además, estas características sólo funcionarán en clientes de Windows 7 y servidores de Windows Server 2008 R2, de manera que esto definitivamente afectará una escala de tiempo de implementación. Sería aconsejable que los administradores de TI estudiaran la documentación de Microsoft disponible y la configuraran en un laboratorio de pruebas para garantizar éxito.

Contenido relacionado

 

Gary Olsenes ingeniero de software de sistemas en el Centro de expertos técnicos a nivel mundial (WTEC) de HP para servicios Hewlett-Packard en Atlanta, Ga., y ha trabajado en el sector de TI desde 1981. Además de ser un MVP de Microsoft para Directory Services, es fundador/director del Grupo de usuarios de Active Directory de Atlanta y es colaborador frecuente de la revista Redmond.