Exportar (0) Imprimir
Expandir todo
Personas que lo han encontrado útil: 3 de 3 - Valorar este tema

Introducción al acceso remoto (DirectAccess, enrutamiento y acceso remoto)

Publicada: febrero de 2012

Actualizado: marzo de 2012

Se aplica a: Windows Server 2012

Introducción a la tecnología Acceso remoto de Windows Server 2012, sus funciones nuevas y modificadas, y vínculos a recursos adicionales.

En Windows Server 2012, Acceso remoto combina dos servicios de red en un solo rol de servidor unificado.

Con Windows Server 2008 R2 llegó DirectAccess, una nueva característica de acceso remoto que permite conectarse a los recursos de la red corporativa sin necesidad de establecer conexiones de red privada virtual (VPN). DirectAccess proporciona únicamente soporte para los clientes de edición de Windows 7 Enterprise y Ultimate unidos a dominios. El servidor de Enrutamiento y acceso remoto (RRAS) de Windows suministra la conectividad de VPN tradicional a los clientes heredados, los clientes que no estén unidos a un dominio y los clientes de VPN de terceros. RRAS también proporciona conexiones sitio a sitio entre servidores. RRAS en Windows Server 2008 R2 no puede coexistir en el mismo servidor perimetral con DirectAccess y se debe implementar y administrar de forma separada de DirectAccess.

En Windows Server 2012, la característica DirectAccess y el servicio de rol RRAS se combinan en un nuevo rol de servidor unificado. Este nuevo rol de servidor de acceso remoto permite la administración, configuración y supervisión centralizada de servicios de acceso remoto basados en DirectAccess y en VPN. Además, DirectAccess de Windows Server 2012 ofrece numerosas actualizaciones y mejoras para tratar los bloqueadores de implementación y proporcionar una administración simplificada.

DirectAccess también está disponible en Windows Server 2012 Essentials y, del mismo modo, permite una conectividad sin problemas con la red de su organización desde cualquier ubicación remota con acceso a Internet sin tener que establecer una conexión de red privada virtual (VPN).

Para obtener más información sobre DirectAccess en Windows Server 2012 Essentials, consulte Configuración de DirectAccess en Windows Server 2012 Essentials.

El nuevo rol de servidor unificado para DirectAccess y RRAS proporciona un solo punto de configuración y administración para la implementación del servidor de acceso remoto. Windows Server 2012 incluye las siguientes mejoras respecto a DirectAccess de Windows 7 y RRAS.

  • Coexistencia de DirectAccess y RRAS

  • Implementación simplificada de DirectAccess

  • Eliminación de la implementación de infraestructura de clave pública (PKI) como requisito previo de DirectAccess

  • Compatibilidad de DNS64 y NAT64 integrada para tener acceso a recursos solo IPv4

  • Compatibilidad para el servidor de DirectAccess detrás de un dispositivo NAT

  • Directiva de seguridad de red simplificada

  • Compatibilidad de equilibrio de carga

  • Compatibilidad con varios dominios

  • Integración de NAP

  • Compatibilidad para OTP (autenticación basada en tokens)

  • Compatibilidad automatizada para túnel forzado

  • Mejoras de rendimiento e interoperabilidad de IP-HTTPS

  • Compatibilidad para "quitar de la administración" de DirectAccess a los clientes

  • Compatibilidad para multisitio

  • Compatibilidad para Server Core

  • Compatibilidad con Windows PowerShell

  • Supervisión de usuarios

  • Estado operativo del servidor

  • Diagnóstico

  • Contabilidad e informes

  • VPN de modo de túnel IPsec de IKEv2 de sitio a sitio

Tanto DirectAccess como RRAS implementan características de seguridad para proteger al servidor de tráfico de entrada hostil. Anteriormente, las configuraciones de estas características de seguridad entraban en conflicto entre sí si ambos servicios intentaban ejecutarse en el mismo servidor, impidiendo que tanto DirectAccess como RRAS funcionaran de la manera esperada.

DirectAccess depende de las tecnologías de transición de la versión seis del protocolo de Internet (IPv6) para establecer las conexiones de clientes. RRAS implementa la seguridad de protocolo de Internet (IPsec) de Intercambio de claves por red versión 2 (IKEv2), y configura los filtros de paquetes de entrada y salida para descartar todos los paquetes mediante tecnologías de transición. Esto hace que el tráfico de DirectAccess se bloquee si se instala RRAS y el acceso de VPN se implementa con IKEv2.

DirectAccess implementa la Protección IPsec contra ataques por denegación de servicio (DoSP) para proteger los recursos en la red corporativa. DoSP descarta todo el tráfico de IPv4, y todo el tráfico de IPv6 que no está protegido por IPsec, excepto los paquetes ICMPv6. Esto hace que todos los paquetes de IPv4 y los paquetes de IPv6 que no están protegidos por IPsec reenviados por RRAS se bloqueen si DirectAccess está habilitado.

Windows Server 2012El rol de servidor unificado de DirectAccess y RRAS soluciona estos problemas ya que modifica las directivas IKEv2 para permitir el tráfico de las tecnologías de transición de IPv6 y modifica la protección por denegación de servicio de IPsec para permitir el tráfico VPN. Estos cambios permiten que DirectAccess y RRAS coexistan en el mismo servidor.

Windows Server 2012 incluye características que facilitan la implementación, especialmente para organizaciones pequeñas y medianas. Estas nuevas características incluyen una lista simplificada de requisitos previos, la eliminación de la necesidad de realizar una implementación completa de PKI, aprovisionamiento de certificados integrado, y eliminación del requisito para dos direcciones IPv4 públicas consecutivas. Cada una de estas características se analiza más detalladamente en las siguientes secciones.

Los administradores ahora pueden implementar DirectAccess con un nuevo Asistente para introducción, que presenta una experiencia de configuración mucho más simplificada. El Asistente para introducción enmascara la complejidad de DirectAccess y permite una instalación automatizada en unos pocos pasos sencillos. Ya no es necesario que el administrador conozca los detalles técnicos de cosas como las tecnologías de transición de IPv6 y la implementación del Servidor de ubicación de red (NLS).

Uno de los principales bloqueadores de implementación para DirectAccess de Windows 7 es el requisito de una PKI para la autenticación basada en certificados de cliente y servidor. DirectAccess depende de las directivas AuthIP de IPsec para la autenticación y seguridad de tráfico de los clientes conectados a Internet. Para autenticar los recursos de dominio con Kerberos, el cliente primero debe establecer la conectividad con los servidores DNS y los controladores de dominio (DC).

DirectAccess de Windows 7 permite esta conectividad al implementar dos métodos de autenticación en las directivas de AuthIP. El túnel IPsec de infraestructura se establece con un certificado de equipo como primer método de autenticación y usuario NTLM como segundo método. Una vez que se establece este túnel y DC está disponible, el cliente puede obtener un token de Kerberos y establecer el túnel IPsec de intranet IPsec mediante un certificado de equipo y usuario Kerberos como el primer y segundo método de autenticación.

Esta implementación requiere que se aprovisionen el servidor de DirectAccess y todos los clientes con certificados de equipo para su mutua autenticación. Muchas organizaciones pequeñas y medianas consideran que la administración de una PKI interna es difícil. Windows Server 2012 DirectAccess hace que la implementación de PKI sea opcional para simplificar la configuración y la administración.

Esta funcionalidad se logra al implementar un proxy Kerberos basado en HTTPS. Las solicitudes de autenticación de cliente se envían a un servicio proxy Kerberos que ese ejecuta en el servidor de DirectAccess. El proxy Kerberos luego envía solicitudes Kerberos a los controladores de dominio en nombre del cliente.

El nuevo Asistente para introducción proporciona una experiencia sin problemas para el administrador al configurar esta solución de forma automática. En esta implementación simplificada de DirectAccess, las opciones de configuración de nivel de usuario, como el túnel forzado, la integración de la Protección de acceso a redes (NAP) y la autenticación en dos fases no están disponibles. Esta implementación requiere que se establezca un solo túnel IPsec, y tiene los siguientes requisitos:

  • El servidor de DirectAccess debe tener el puerto TCP 443 abierto en el firewall

  • El servidor de DirectAccess debe tener un certificado de autenticación de servidor para TLS emitido por la Entidad de certificación (CA) en quien confían los clientes de DirectAccess. Puede ser una CA pública y no requiere una implementación de PKI interna. Si no se encuentra disponible ningún certificado, el proceso de instalación del servidor de DirectAccess configurará el certificado de proxy KDC e IP-HTTPS necesario de forma automática como un certificado autofirmado.

Para permitir el acceso a recursos internos solo de IPv4, DirectAccess de Windows Server 2012 incluye compatibilidad nativa para una puerta de enlace de traducción de protocolos (NAT64) y resolución de nombres (DNS64) para convertir la comunicación de IPv6 de un cliente de DirectAccess en IPv4 para los servidores internos. Los equipos de intranet de solo IPv4 no pueden iniciar conexiones con clientes de DirectAccess para la administración remota debido a que la traducción realizada con NAT64 es unidireccional (para tráfico iniciado por el cliente de DirectAccess).

Existen tres instancias principales en que DirectAccess de solo IPv6 no concede un total acceso a los recursos intranet corporativos.

  • Los servidores de intranet que no son totalmente compatibles con IPv6 y solo admiten IPv4, como los servidores de archivo de Windows Server 2003

  • Entornos en los que IPv6 se ha deshabilitado administrativamente en la red

  • Aplicaciones que se ejecutan en servidores compatibles con IPv6 (como Windows Server 2008), que no son compatibles con IPv6 en sí mismas (como las aplicaciones que no pueden escuchar ni responder al tráfico en la interfaz IPv6)

Para tener acceso a estos recursos a través de DirectAccess, la traducción del protocolo debe realizarse entre el servidor de DirectAccess y los recursos internos de solo IPv4, con una traducción posterior nuevamente de IPv6 para las respuestas que se envían a los clientes de DirectAccess. NAT64 recibe el tráfico de IPv6 del cliente y lo convierte en tráfico IPv4 para la intranet. NAT64 se usa junto con DNS64. DNS64 intercepta las consultas de DNS de los clientes, y envía las respuestas después de convertir las respuestas de IPv4 en asignaciones IPv6 asociadas en NAT64.

noteNota
Antes de DirectAccess de Windows Server 2012, el único método disponible para proporcionar la traducción de protocolos para DirectAccess era mediante la implementación de Microsoft Forefront Unified Access Gateway DirectAccess.

El asistente para la instalación de DirectAccess configurará sin problemas los componentes de traducción de protocolos como una operación en segundo plano, sin ninguna necesidad de interacción administrativa. No se expone ninguna opción de configuración al administrador. El asistente para instalación habilitará automáticamente NAT64 y DNS64 si la interfaz interna del servidor de DirectAccess tiene una dirección IPv4 asignada. Para admitir esta funcionalidad, el asistente para instalación configurará un prefijo de red IPv6 para NAT64. El asistente asigna el prefijo NAT64 automáticamente y lo aplica a todos los intervalos IPv4 en la empresa.

Un servidor de DirectAccess de Windows Server 2008 R2 requiere dos interfaces de red con dos direcciones IPv4 públicas consecutivas asignadas a la interfaz externa. Esto es necesario para que pueda actuar como servidor Teredo. Para que los clientes detrás de una NAT puedan determinar el servidor Teredo y el tipo de dispositivo NAT, el servidor Teredo requiere dos direcciones IPv4 consecutivas.

Este requisito presenta dificultades para las organizaciones pequeñas y medianas que no tienen acceso a direcciones IPv4 públicas consecutivas. En el futuro, es posible que esto se convierta en un bloqueador de implementación a medida que el espacio disponible para direcciones IPv4 se acabe. DirectAccess de Windows Server 2012 permite implementar el servidor de DirectAccess detrás de un dispositivo NAT, con compatibilidad para una o varias interfaces de red, y elimina el requisito previo de direcciones IPv4.

Cuando se ejecuta el Asistente para instalación de acceso remoto o el Asistente para introducción de instalación de los Servicios de acceso remoto, comprobará el estado de las interfaces de red en el servidor para determinar si el servidor de DirectAccess se ubica detrás de un dispositivo NAT. En esta configuración, se implementará solo IP a través de HTTPS (IP-HTTPS). El protocolo IP-HTTPS es una tecnología de transición de IPv6 que permite que se establezca un túnel IP seguro mediante una conexión HTTP segura.

DirectAccess de Windows Server 2008 R2 usa dos túneles IPsec para establecer la conectividad a la red corporativa. El cliente de DirectAccess requiere que el túnel de infraestructura tenga acceso a los recursos de infraestructura como servidores de administración, DNS y DC. Todos estos servidores de infraestructura se muestran como extremos en la directiva de IPsec de túnel de infraestructura. Luego, el túnel intranet proporciona acceso a todos los otros recursos intranet corporativos.

Los extremos que se muestran en la directiva de túnel de infraestructura requieren actualizaciones periódicas a medida que la infraestructura cambia, como, por ejemplo, cuando se agregan servidores DNS o controladores de dominio a la red de producción, o cuando se quitan de ésta. Los clientes pueden perder conectividad con el dominio cuando sus directivas IPsec no se actualizan para reflejar los extremos de servidor de infraestructura actuales, y esta pérdida de conectividad evitará que reciban actualizaciones de directivas de grupo para corregir el error.

En Windows Server 2012, el modelo DirectAccess simplificado permite implementar DirectAccess en un único túnel IPsec, eliminando así este problema. Sin embargo, DirectAccess simplificado no admite algunas funcionalidades, que dependen de la autenticación basada en certificados. Algunos ejemplos son la autenticación en dos fases con tarjetas inteligentes, multisitio y la integración NAP. Las empresas que requieren una experiencia de DirectAccess con todas las características aún necesitarán implementar un modelo de dos túneles.

Si se necesita el modelo de dos túneles para la funcionalidad completa, hay disponibles otras funcionalidades para permitir que los administradores actualicen la lista de servidores a los que se puede acceder a través del túnel de infraestructura. Los nuevos servidores de System Center Configuration Manager y controladores de dominio se detectan y se agregan a la lista. Los servidores que ya no existen se quitan de la lista y se actualizan las entradas de los servidores cuyas direcciones IP han cambiado.

DirectAccess de Windows Server 2008 R2 no proporciona una solución completa de alta disponibilidad y está limitado a implementaciones de un solo servidor. Para proporcionar una redundancia de hardware limitada, DirectAccess se puede configurar dentro de un clúster de conmutación por error de Hyper-V configurado para migración en vivo de Hyper-V. Sin embargo, solo un nodo de servidor puede estar conectado a la vez.

Las implementaciones de DirectAccess se han desarrollado rápidamente más allá del punto en que un solo servidor puede proporcionar un poder de procesamiento adecuado. Las empresas necesitan la flexibilidad para implementar servidores adicionales en forma rápida y transparente para satisfacer los requisitos de carga que van cambiando. Adicionalmente, el Servidor de ubicación de red usado para la detección interna/externa debe estar muy disponible para evitar interrupciones graves para los clientes de DirectAccess conectados a la intranet.

DirectAccess de Windows Server 2012 aborda estos problemas mediante la compatibilidad integrada para Equilibrio de carga de red (NLB) de Windows para lograr una alta disponibilidad y escalabilidad tanto para VPN de DirectAccess como de RRAS. La configuración de NLB es fácil de establecer y automatizar mediante la nueva interfaz del asistente para la implementación. El proceso de configuración también proporciona compatibilidad integrada para soluciones de equilibrador de carga externo basado en hardware de terceros.

ImportantImportante
DirectAccess de Windows Server 2012 proporciona una solución básica de conmutación por error mediante Equilibrio de carga de red para un máximo de ocho nodos. A pesar de que la carga de red se compartirá a lo largo de todos los nodos NLB, las conexiones existentes no se transferirán automáticamente a otros servidores cuando un servidor deje de estar disponible.

El asistente para instalación de DirectAccess en Windows Server 2008 R2 se puede usar para configurar DirectAccess para un solo dominio. Esto significa que los clientes remotos de un dominio diferente del servidor de DirectAccess no podrán usar DirectAccess. Además, si los servidores de aplicaciones están en un dominio diferente, los clientes remotos no podrán tener acceso a ellos de forma remota mediante DirectAccess.

Aunque los administradores pueden configurar manualmente la compatibilidad con varios dominios en Windows Server 2008 R2, la implementación requiere la edición manual de las directivas de DirectAccess una vez completada la instalación. DirectAccess de Windows Server 2012 proporciona compatibilidad integrada para varios dominios que permite el acceso remoto de clientes a los recursos empresariales ubicados en dominios diferentes.

DirectAccess de Windows Server 2008 R2 permitía integrar la Protección de acceso a redes (NAP) requiriendo un certificado de mantenimiento para la autenticación del mismo nivel de IPsec del túnel de intranet. Un certificado de mantenimiento es un certificado con el identificador de objeto (OID) Mantenimiento del sistema. Un cliente de NAP solo puede obtener un certificado de mantenimiento de una Autoridad de registro de mantenimiento (HRA) si cumple los requisitos de mantenimiento del sistema configurados en un servidor de directivas de mantenimiento de NAP.

Para integrar NAP con DirectAccess de Windows Server 2008 R2, el administrador debe editar manualmente los objetos de Directiva de grupo y las directivas creados por el asistente para instalación de DirectAccess una vez implementado DirectAccess. DirectAccess de Windows Server 2012 permite configurar directamente una comprobación de mantenimiento de NAP mediante la interfaz de usuario de instalación. Esta característica automatiza la directiva y las modificaciones de GPO necesarias para la integración de NAP. Se puede habilitar el cumplimiento de la comprobación de mantenimiento de NAP desde el Asistente para instalación de acceso remoto.

noteNota
A pesar de que el nuevo asistente para instalación simplifica la integración de NAP con DirectAccess, no automatiza la implementación real misma de NAP. Un Administrador debe configurar el cumplimiento IPsec de NAP y la infraestructura HRA independientemente.

Para incrementar la seguridad de inicio, muchas organizaciones han implementado la autenticación en dos fases de contraseñas de un solo uso (OTP), y ordenan su uso para conexiones de acceso remoto. DirectAccess de Windows Server 2008 R2 admitía la autenticación en dos fases con tarjetas inteligentes, pero no podía realizar la integración con soluciones de proveedor OTP, como RSA SecurID. Esto impedía la implementación de DirectAccess en organizaciones que requieren este nivel de seguridad.

DirectAccess de Windows Server 2012 admite la autenticación en dos fases con tarjetas inteligentes o soluciones basadas en token OTP. Esta característica requiere la implementación de una PKI por lo que, si se selecciona la opción en el Asistente para instalación de DirectAccess, la opción Usar certificados de equipo se selecciona y se aplica automáticamente.

Además de admitir la autenticación estándar con tarjetas inteligentes, DirectAccess puede usar las funcionalidades de tarjetas inteligentes virtuales basadas en el Módulo de plataforma segura (TPM) disponibles en Windows Server 2012. El TPM de equipos cliente puede actuar como una tarjeta inteligente virtual para la autenticación en dos fases, por lo tanto, quita la sobrecarga y los costos en los que se ha incurrido durante la implementación de la tarjeta inteligente.

De forma predeterminada, los clientes de DirectAccess pueden tener acceso a Internet, a la intranet corporativa y a los recursos de LAN locales simultáneamente. Debido a que solo las conexiones hechas con la intranet corporativa se envían a través de los túneles IPsec de DirectAccess, esto se conoce como una configuración de túnel dividido. El túnel dividido proporciona una experiencia de usuario óptima cuando se tiene acceso a recursos en Internet, al mismo tiempo que proporciona aún una gran seguridad para el tráfico que se usa en la intranet.

Aunque el túnel dividido no supone un riesgo para la seguridad, algunas organizaciones requieren que todo el tráfico pase por un proxy corporativo para que pueda ser inspeccionado por sus IDS. Con conexiones VPN heredadas, los usuarios podrían establecer puentes para el tráfico entre redes, como una red doméstica y la red corporativa, y hacer que el cliente funcione como un enrutador. Por este motivo, normalmente los administradores deshabilitan el túnel dividido para las conexiones VPN, lo que fuerza el enrutamiento de todo el tráfico de red a través de la conexión VPN. Esto provoca un menor rendimiento cuando se tiene acceso a recursos de Internet, ya que todo el tráfico debe recorrer el túnel VPN y luego enviarse por el proxy a Internet. También consume gran parte del ancho de banda adicional en la red corporativa.

El riesgo de seguridad percibido con el túnel dividido no es válido en un escenario de DirectAccess, ya que las reglas de IPsec que habilitan DirectAccess requieren autenticación por parte del extremo del cliente. Si otro extremo intenta enrutar a través del cliente de DirectAccess, no constituirá un origen autenticado e IPsec impedirá la conexión. Sin embargo, debido a que algunas organizaciones tienen el requisito de forzar todo el tráfico a través del servidor proxy corporativo para que pueda ser inspeccionado, la opción de túnel forzado de DirectAccess proporciona esta capacidad.

La opción Túnel forzado estaba disponible en DirectAccess de Windows Server 2008 R2, pero requería pasos manuales para habilitarlo mediante una configuración de directiva de grupo. DirectAccess de Windows Server 2012 integra la opción Túnel forzado con el Asistente para instalación y la interfaz de usuario de administración para automatizar la configuración necesaria. Al habilitar la opción de túnel forzado se limita al cliente de DirectAccess a usar solo el protocolo IP-HTTPS para conectividad y, de manera predeterminada, se usa el servidor de DirectAccess como servidor NAT64/DNS64 para traducir recursos IPv6 para enviar al servidor proxy IPv4.

En algunas redes, la configuración del firewall de Internet puede impedir conexiones de cliente correctas mediante las tecnologías de transición 6to4 o Teredo IPv6. IP-HTTPS es una tecnología de transición IPv6 que se presentó en Windows 7 para asegurar que los clientes de DirectAccess se puedan conectar a la red corporativa aún cuando se produzcan errores en todas las otras tecnologías de transición IPv6. IP-HTTPS asigna una dirección IPv6 globalmente enrutable única a un host IPv4, encapsula los paquetes IPv6 dentro de IPv4 para su transmisión en un túnel HTTPS y enruta el tráfico IPv6 entre el host y otros nodos IPv6 globalmente enrutables.

Windows Server 2012 aporta varias mejoras a la implementación de IP-HTTPS. Los cambios en la tecnología permiten a los clientes IP-HTTPS obtener información sobre la configuración de proxy, y autenticar en un proxy HTTP si se requiere la autenticación. Se ha quitado el requisito de Windows 7 de implementar certificados de cliente para cada cliente IP-HTTPS.

IP-HTTPS funciona mediante la creación de una conexión SSL/TLS entre el cliente y el servidor, que luego pasa el tráfico IP a través de la conexión. Estos datos están cifrados por IPsec, lo cual significa que los datos se cifraron dos veces, primero con IPsec y, de nuevo, con SSL. El resultado es un rendimiento deficiente y una experiencia de usuario negativa en comparación con las otras tecnologías de transición 6to4 y Teredo de IPv6, y se limita la escalabilidad del servidor de DirectAccess.

DirectAccess de Windows Server 2012 incluye varias mejoras del rendimiento para IP-HTTPS para aumentar la escalabilidad y reducir la sobrecarga asociada a este método de conectividad. Estas optimizaciones incluyen cambios en búferes de recepción y comportamiento de envío por lotes, una contención de bloqueo reducida y la opción de implementar SSL con cifrado NULL.

IP-HTTPS se ejecuta en un contexto de sistema en vez de un contexto de usuario. Este contexto puede causar problemas de conexión. Por ejemplo, si un equipo cliente de DirectAccess está ubicado en la red de una compañía asociada que usa un proxy para el acceso a Internet, y no se usa la autodetección WPAD, el usuario debe configurar manualmente el proxy para poder tener acceso a Internet. Esta configuración se realiza en Internet Explorer usuario por usuario, y no se puede recuperar de manera intuitiva en nombre de IP-HTTPS. Además, si el proxy requiere autenticación, el cliente proporciona credenciales para el acceso a Internet, pero IP-HTTPS no suministrará las credenciales necesarias para autenticar en DirectAccess. En Windows Server 2012, una nueva característica soluciona estos problemas. Específicamente, el usuario puede configurar IP-HTTPS para que trabaje al estar detrás de un proxy que no está configurado con WPAD e IP-HTTPS solicitará y proporcionará las credenciales proxy necesarias para la solicitud IP-HTTPS autenticada, y retransmitirla al servidor de DirectAccess.

Al configurar IP-HTTPS en DirectAccess en el servidor, puede usar un certificado emitido por una Entidad de certificación (CA), o puede especificar que DirectAccess genere automáticamente un certificado autofirmado.

Los clientes de DirectAccess establecen una conectividad a la intranet corporativa cada vez que está disponible una conexión a Internet, aunque no haya ningún usuario con sesión iniciada. Esto les permite a los administradores de TI administrar equipos remotos para revisión y cumplimiento aún cuando no estén en la oficina. Para algunos clientes esta es la mayor ventaja de DirectAccess, y deciden mantener la solución del acceso remoto existente en funcionamiento para la conectividad de usuario, mientras que solo usan DirectAccess para la administración remota.

DirectAccess de Windows Server 2008 R2 no proporciona un método automatizado para limitar la implementación solo a "quitar de la administración", y los administradores deben editar manualmente las directivas creadas por el asistente para instalación. DirectAccess de Windows Server 2012 proporciona compatibilidad con una configuración que permite solo "quitar de la administración" a través de una opción del asistente para implementación que limita la creación de directivas a solo aquellas necesarias para la administración remota de equipos cliente. En esta implementación, las opciones de configuración de nivel de usuario, como túnel forzado, integración de la Protección de acceso a redes (NAP), y la autenticación en dos fases no están disponibles.

noteNota
"Quitar de la administración" requiere la implementación de ISATAP o servidores de administración con direcciones v6.

Los servidores de DirectAccess se pueden implementar en varios sitios para aumentar la capacidad y proporcionar un acceso más eficiente a los puntos de entrada más cercanos para los recursos de intranet. Esto funciona bien si los clientes permanecen en sus respectivos sitios y no necesitan desplazarse a diferentes sitios dentro de la empresa. Sin embargo, la configuración multisitio de DirectAccess requiere una planeación y un diseño cuidadosos si los clientes se desplazarán de un sitio al otro, para asegurar la conexión a través de los servidores de DirectAccess mediante la ruta más eficiente.

Hay muchos desafíos a tener en cuenta en un entorno multisitio, como asegurarse de que el cliente ubique el servidor IP-HTTPS, el servidor Teredo, el servidor DNS y el controlador de dominio más cercanos. DirectAccess de Windows Server 2012 proporciona una solución que permite la implementación de varios puntos de entrada de DirectAccess en diferentes ubicaciones geográficas y permite que los clientes, independientemente de su ubicación física, accedan a los recursos de la red corporativa de una manera eficaz.

Los servidores DirectAccess de Windows Server 2012 se pueden configurar en una implementación multisitio que permite a los usuarios remotos de ubicaciones geográficamente dispersas conectarse con el punto de entrada multisitio más próximo a ellos. Para los equipos cliente que ejecutan Windows 8, los puntos de entrada se pueden asignar automáticamente o el cliente los puede seleccionar manualmente. Para los equipos cliente de Windows 7, los puntos de entrada se pueden asignar estáticamente. Los clientes de Windows 7 también pueden aprovechar las ventajas de la selección automática de puntos de entrada si la organización implementa una solución de equilibrio de carga de servidor global (GSLB). El tráfico en la implementación multisitio se puede distribuir y equilibrar con un equilibrador de carga global externo.

Server Core es una opción de instalación de servidor mínima diseñada para reducir espacio en disco, servicios y requisitos de administración, y para disminuir la superficie expuesta a ataques del sistema operativo. El sistema Server Core no admite una interfaz gráfica de usuario, y los administradores deben usar una línea de comandos o herramientas de administración remota para realizar todas las tareas de configuración necesarias.

Una instalación Server Core admite solo un subconjunto limitado de las características disponibles en una instalación completa de Windows Server, y actualmente no incluye compatibilidad con la característica de DirectAccess o el rol de servidor de acceso remoto. Una instalación Server Core de Windows Server 2012 incluye compatibilidad para el rol de servidor unificado tanto para DirectAccess como para RRAS.

El nuevo rol de servidor de acceso remoto es completamente compatible con Windows PowerShell en Windows Server 2012, que se puede usar para instalación, configuración y supervisión. El rol de servidor de acceso remoto también se puede configurar mediante la administración de servidores remotos.

DirectAccess de Windows Server 2008 R2 carece de una interfaz de línea de comandos y scripting completa para opciones de configuración. Windows Server 2012 proporciona compatibilidad completa con Windows PowerShell para la instalación, configuración, administración, supervisión y solución de problemas del rol de servidor de acceso remoto.

Las funcionalidades de supervisión y diagnóstico tanto para el servidor de RRAS como para DirectAccess están limitadas en Windows Server 2008 R2. Para DirectAccess, las funcionalidades de supervisión solo incluyen un seguimiento de estado básico de DirectAccess y sus componentes. Los datos de seguimiento y estadísticas disponibles tienen poco significado o importancia para los administradores.

La supervisión de usuarios y del estado del servidor que se incorporó en Windows Server 2012 permite al administrador comprender el comportamiento de los clientes y las conexiones de DirectAccess. La consola de seguimiento se usa para mantener un seguimiento de la carga en el servidor de DirectAccess, actividad del usuario y uso de recursos actual. El administrador usa esta información para identificar actividades de uso potencialmente no deseadas o inadecuadas. El seguimiento de diagnóstico también se puede habilitar desde la consola de seguimiento.

Supervisión de usuarios

Los administradores de soluciones de acceso remoto requieren la capacidad para supervisar no solamente qué usuarios están conectados, sino también a qué recursos tienen acceso. Si los usuarios se quejan de que un servidor o recurso compartido de archivos en particular es inaccesible remotamente, el administrador actualmente no tiene una manera de determinar si otros usuarios pueden obtener acceso al recurso correctamente desde la consola de acceso remoto. Normalmente se necesitan varias herramientas y aplicaciones para solucionar problemas tales como el excesivo consumo de banda ancha por parte de algunos usuarios.

Para obtener acceso al panel desde la nueva consola de administración del servidor de acceso remoto, seleccione la pestaña Panel en el panel de navegación. El panel muestra el estado de operativo general, y el estado y la actividad de los clientes remotos. El administrador también puede ver informes rápidos directamente desde el panel.

El panel de supervisión muestra un resumen del estado de conectividad de clientes remotos para los siguientes elementos. La información se genera a partir de los datos de cuentas y contadores del Monitor de rendimiento importantes.

  • Número total de clientes remotos activos conectados: incluidos los clientes remotos de DirectAccess y VPN

  • Número total de clientes de DirectAccess activos conectados: solo el número total de clientes conectados con DirectAccess

  • Número total de clientes de VPN activos conectados: solo el número total de clientes conectados con VPN

  • Total de usuarios únicos conectados: incluye los usuarios de DirectAccess y VPN, basados en las conexiones activas

  • Número total de conexiones acumulativas: número total de conexiones atendidas por el servidor de acceso remoto desde el último reinicio del servidor

  • Número máximo de clientes remotos conectados. Número máximo de usuarios remotos simultáneos conectados al servidor de acceso remoto desde el último reinicio del servidor

  • Número total de datos transferidos. Total de tráfico entrante y saliente del servidor de acceso remoto para DirectAccess y VPN desde el último reinicio del servidor

    1. Tráfico entrante: Total de bytes/tráfico que entra al servidor de acceso remoto/puerta de enlace

    2. Tráfico saliente: Total de bytes/tráfico que sale del servidor de acceso remoto/puerta de enlace

En una implementación de clústeres, el resumen del estado y la actividad de clientes remotos en el panel de acceso remoto muestra los valores totales para todos los nodos del clúster.

Los administradores pueden ver una lista de todos los usuarios remotos conectados actualmente, y pueden mostrar una lista de todos los recursos a los que se tiene acceso si se hace clic sobre un usuario remoto en particular. Los administradores pueden mostrar estadísticas de usuarios remotos si seleccionan el vínculo de estado de clientes remotos en la consola de administración de acceso remoto. Las estadísticas de usuarios se pueden filtrar en base a selecciones de criterio con los siguientes campos:

 

Nombre del campo

Valor

Nombre de usuario

El nombre de usuario o alias del usuario remoto. Se pueden usar comodines para seleccionar un grupo de usuarios, tal como contoso\* o *\administrator. Si no se especifica un dominio, se da por supuesto *\username.

Nombre de host

El nombre de la cuenta de equipo del usuario remoto. También se puede especificar una dirección IPv4 o IPv6.

Tipo

DirectAccess o VPN. Si se selecciona DirectAccess, entonces se muestran todos los usuarios remotos que se conectan con DirectAccess. Si se selecciona VPN, entonces se muestran todos los usuarios remotos que se conectan con VPN.

Dirección ISP

La dirección IPv4 o IPv6 del usuario remoto

Dirección IPv4

La dirección IPv4 interna del túnel que conecta al usuario remoto con la red corporativa

Dirección IPv6

La dirección IPv6 interna del túnel que conecta al usuario remoto con la red corporativa

Protocolo/túnel

La tecnología de transición usada por el cliente remoto, Teredo, 6to4 o IP-HTTPS en el caso de usuarios de DirectAccess, y PPTP, L2TP, SSTP o IKEv2 en el caso de usuarios de VPN

Recurso al que se accede

Todos los usuarios que tienen acceso a un extremo o un recurso corporativo en particular. El valor correspondiente a este campo es el nombre de host/dirección IP del servidor/extremo

Servidor

Servidor de acceso remoto al que se conectan los clientes. Relevante únicamente para implementaciones de clúster y multisitio.

Esta característica permite a los administradores administrar y supervisar el estado de las implementaciones de acceso remoto desde una consola de supervisión centralizada. La característica muestra alertas a los administradores cuando se detecta un problema al que hay que prestar atención. La interfaz muestra información de diagnóstico detallada con los pasos para proporcionar resolución.

El nodo Panel del árbol de la consola muestra el estado del servidor de acceso remoto, incluido el estado de la infraestructura de acceso remoto y los componentes relacionados, además de si la configuración está correctamente distribuida entre los puntos de entrada.

El nodo Estado operativo del servidor del árbol de la consola muestra el estado del servidor de acceso remoto, incluido el estado de la infraestructura de acceso remoto y los componentes relacionados. Al hacer clic sobre un componente determinado, los administradores pueden ver el estado, el historial de cambios y los detalles de supervisión de ese componente.

Si se implementan servidores de acceso remoto en una implementación multisitio o de clúster, todos los servidores en la implementación multisitio o de clúster se evalúan de forma asincrónica y se muestran con un estado general. Los administradores pueden desplazarse a través de la lista de servidores y expandir o contraer la vista para mostrar los componentes de servidor de DirectAccess y VPN.

A continuación, se muestran los componentes de acceso remoto con monitores de estado mostrados en el panel Estado de las operaciones del servidor.

  • 6to4

  • DNS

  • DNS64

  • Controlador de dominio

  • IP-HTTPS

  • IPsec

  • ISATAP

  • Kerberos

  • Servidores de administración

  • NAT64

  • Adaptadores de red

  • Servidor de ubicación de red

  • Seguridad de red (IPsec DoSP)

  • Servicios

  • Teredo

  • Equilibrio de carga

  • Direccionamiento VPN

  • Conectividad VPN

La solución de problemas de conectividad de acceso remoto para RRAS y DirectAccess puede ser muy compleja debido a las capacidades de registro limitadas que se proporcionan actualmente. Normalmente, los administradores necesitan capturas del monitor de red y seguimiento de RRAS para solucionar problemas, debido a que los registros de visor de eventos no son muy útiles o prescriptivos.

Windows Server 2012 proporciona las siguientes mejoras de la característica de diagnóstico para la solución de problemas de acceso remoto.

  • Registro de eventos detallado para DirectAccess

    Los administradores pueden usar un registro de eventos mejorado para identificar problemas y realizar análisis de rendimiento y capacidad. Los registros de eventos están estandarizados para asegurar una experiencia coherente con otros componentes de redes.

  • Captura de paquetes y seguimiento

    El seguimiento integrado facilita a los administradores la recopilación de registros de seguimiento y captura de paquetes de red con un solo clic. Tanto el seguimiento con captura de paquetes como la correlación de registros se realizan como parte de un único proceso cuando el administrador hace clic en la tarea Iniciar seguimiento en el panel de tareas.

  • Correlación de registros

    Esta característica proporciona una colección y correlación de registros automatizadas para distintos componentes de DirectAccess con un solo clic, y así aprovecha la característica de seguimiento unificado de Windows. Los eventos recopilados a partir de diferentes componentes están consolidados en un único archivo a través de la correlación de identificadores de actividades. Los identificadores de actividades son GUID que identifican una tarea u opción específica. Cuando un componente registra un evento, asocia un identificador de actividades con el evento. El componente luego pasa este identificador o un evento de transferencia asignado al identificador al componente que realiza la siguiente tarea en el escenario, el cual asocia el identificador de actividades para registrar eventos. Al analizar el archivo de seguimiento resultante, la relación entre los distintos componentes relevantes para un escenario se pueden reconstruir.

  • Habilitación/visualización de registros

    El seguimiento se puede habilitar desde el panel de tareas del panel de supervisión o desde la línea de comandos, la cual controla también los niveles de registro, las palabras claves y los filtros. Los archivos ETL de seguimiento unificado resultantes que se generan pueden leerse y visualizarse con el monitor de red.

Un servidor de acceso remoto de Windows Server 2012 puede sacar partido de una implementación de servidor RADIUS existente o de Windows Internal Database (WID) con fines de contabilidad. La información y los datos históricos sobre el estado del servidor y la carga están disponibles a través de los contadores del Monitor de rendimiento del sistema y se almacenan en el almacén de cuentas de WID. Cuando una conexión se recibe o se desconecta en el servidor de acceso remoto, todas las estadísticas de usuarios remotos (incluidos los extremos a los que se tiene acceso) se guardan en el almacén de cuentas como una sesión. Esto permite que más adelante se pueda tener acceso a los detalles de la sesión por motivos de auditoria y generación de informes.

La funcionalidad de contabilidad e informes suministrada en el rol de servidor de acceso remoto incluye la capacidad para medir métricas específicas. Las métricas disponibles incluyen la cantidad de usuarios conectados a un servidor de DirectAccess específico y el total de bytes transferidos. Los administradores pueden crear informes personalizados para identificar patrones de uso y tráfico, incluido un historial de estos patrones.

Las funcionalidades de informes de DirectAccess y RRAS permiten a los administradores generar informes de uso enriquecidos sobre diversas estadísticas tales como estadísticas de usuarios remotos, disponibilidad y carga de servidor. Se aprovecha el almacén de cuentas de la bandeja de entrada para generar el informe de uso. Se debe habilitar la contabilidad de la bandeja de entrada en una base de datos de WID local para generar informes de uso. La contabilidad de NPS/RADIUS no se puede usar para generar informes.

El informe de uso muestra el historial de uso que indica qué usuarios establecieron conexiones remotas, a qué recursos tuvieron acceso, la cantidad total de usuarios únicos y la carga máxima de servidor generada. El administrador puede seleccionar un periodo de tiempo específico a partir del cual generar los datos.

La conectividad entre centros es una característica de Windows Server 2012 que proporciona la conectividad de red que permite que los proveedores de hospedaje de servicios puedan migrar sus aplicaciones e infraestructura a la nube. Esta característica incluye una solución de conectividad VPN de modo de túnel de Intercambio de claves por red versión 2 (IKEv2) de sitio a sitio e interfaz de administración. Windows Server 2008 R2 incorporó compatibilidad con IKEv2 en RRAS para conexiones de VPN. Una VPN de IKEv2 proporciona resistencia al cliente de VPN cuando el cliente se desplaza de una red a otra, o cuando pasa de una conexión inalámbrica a una con cable. El uso de IKEv2 e IPsec permite la compatibilidad para una autenticación firme y métodos de cifrado. En Windows Server 2012, RRAS proporciona otras mejoras de características para habilitar IKEv2 para conexiones de VPN de sitio a sitio.

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios

Adiciones de comunidad

AGREGAR
Mostrar:
© 2014 Microsoft. Reservados todos los derechos.