Implementar varios servidores de acceso remoto en una implementación multisitio

Artículo
08/03/2016

Se aplica a: Windows Server 2012 R2, Windows Server 2012

Windows Server 2012 combina DirectAccess y el enrutamiento y el servicio de acceso remoto (RRAS) VPN en una única función de acceso remoto. El acceso remoto se puede implementar en diversos escenarios de empresas. Esta información general proporciona una introducción al escenario empresarial para implementar servidores de acceso remoto en una configuración multisitio.

Descripción del escenario

En una implementación multisitio dos o más servidores de acceso remoto o clústeres de servidores han implementado y configurado como puntos de entrada diferentes en una sola ubicación o en ubicaciones geográficamente dispersas. Implementación de varios puntos de entrada en una sola ubicación permite la redundancia de servidores, o para la alineación de los servidores de acceso remoto con la arquitectura de red existente. Implementación por ubicación geográfica garantiza el uso eficaz de recursos, como equipos cliente remotos puedan conectarse a recursos de red interna mediante un punto de entrada más cercano a ellos. Puede distribuir el tráfico a través de una implementación multisitio y equilibrado con un equilibrador de carga global externo.

Una implementación multisitio es compatible con equipos cliente que ejecutan Windows 8 o Windows 7. Equipos cliente que ejecutan Windows 8 identificar automáticamente un punto de entrada o el usuario puede seleccionar manualmente un punto de entrada. Asignación automática se produce en el orden de prioridad siguiente:

Utilice un punto de entrada seleccionado manualmente por el usuario.
Utilice un punto de entrada identificado por un equilibrador de carga global externo si uno está implementada.
Utilice el punto de entrada más cercano identificado por el equipo cliente utilizando un mecanismo de sondeo automática.

Compatibilidad con clientes que ejecutan Windows 7 debe habilitarse manualmente en cada punto de entrada y no se admite la selección de un punto de entrada por estos clientes.

Requisitos previos

Antes de empezar a implementar este escenario, revise esta lista de requisitos importantes:

Deploy a Single DirectAccess Server with Advanced Settings debe implementarse antes de una implementación multisitio.

Los clientes de Windows 7 siempre se conectarán a un sitio específico. No podrá conectarse al sitio más cercano en función de la ubicación del cliente (a diferencia de Windows 8, los clientes de windows 8.1).

No se admite la opción de cambiar directivas fuera de la consola de administración de DirectAccess o de los cmdlets de Windows PowerShell.

Hay que implementar una infraestructura de clave pública.

Para obtener más información, consulte: Minimódulo de guía de prueba de laboratorio: básica PKI de Windows Server 2012.

La red corporativa debe estar habilitados para IPv6. Si utilizas ISATAP, debes eliminarlo y usar IPv6 nativo.

En este escenario

El escenario de implementación multisitio incluye una serie de pasos:

Deploy a Single DirectAccess Server with Advanced Settings: Un único servidor de acceso remoto con configuración avanzada debe implementarse antes de configurar una implementación multisitio.
Planear una implementación multisitio: Para crear una implementación multisitio desde un único servidor un número adicional de planeación de los pasos son necesarios, incluido el cumplimiento de requisitos previos de multisitio y planificación de grupos de seguridad de Active Directory, objetos de directiva de grupo (GPO), DNS y configuración de cliente.
Configurar una implementación multisitio: Esto consta de una serie de pasos de configuración, incluida la preparación de la infraestructura de Active Directory, la configuración del servidor de acceso remoto existente y la adición de varios servidores de acceso remoto como puntos de entrada a la implementación multisitio.
Solucionar problemas relacionados con una implementación multisitio: Esta sección de solución de problemas describe una serie de los errores más comunes que pueden producirse al implementar el acceso remoto en una implementación multisitio.

Aplicaciones prácticas

Una implementación multisitio proporciona lo siguiente:

Rendimiento mejorado, una implementación multisitio permite obtener acceso a los recursos internos mediante acceso remoto para conectarse con el punto de entrada más cercano y más adecuado de los equipos de cliente. Cliente tener acceso a recursos internos de manera eficaz y se mejora la velocidad de cliente que Internet las solicitudes que se enrutan a través de DirectAccess. El tráfico a través de puntos de entrada puede equilibrarse con un equilibrador de carga global externo.
Facilidad de administración: multisitio permite a los administradores alinear la implementación del acceso remoto a una implementación de sitios de Active Directory proporciona una arquitectura simplificada. Configuración compartida fácilmente puede establecerse a través de servidores de punto de entrada o de clústeres. Configuración de acceso remoto puede administrarse desde cualquiera de los servidores de la implementación o de forma remota mediante las herramientas de administración de servidor remoto (RSAT). Además, toda la implementación multisitio se puede supervisar desde una única consola de administración de acceso remoto.

Roles y características que se incluyen en este escenario

En la tabla siguiente se enumera los roles y características que se usan en este escenario.

Rol/característica	Compatibilidad con este escenario
Rol de acceso remoto	El rol se instala y desinstala mediante la consola del Administrador del servidor. Incluye tanto DirectAccess, que antes era una característica de Windows Server 2008 R2, como los servicios de enrutamiento y acceso remoto (RRAS), que antes eran un servicio de roles de los Servicios de acceso y directivas de redes (NPAS). El rol de acceso remoto consta de dos componentes: VPN de los Servicios de acceso remoto y enrutamiento de DirectAccess (RRAS): DirectAccess y VPN se administran en forma conjunta en la consola de administración de acceso remoto. Enrutamiento RRAS: las características del enrutamiento RRAS se administran en la consola de administración de acceso remoto heredada. Las dependencias son las siguientes: Servidor web de Internet Information Services (IIS): se requiere esta característica para configurar el servidor de ubicación de la red y el sondeo web predeterminado. Windows Internal Database: se usa para las cuentas locales en el servidor de acceso remoto.
Característica Herramientas de administración de acceso remoto	Esta característica se instala de la siguiente manera: Se instala de forma predeterminada en un servidor de acceso remoto cuando se instala el rol de acceso remoto, y admite la interfaz de usuario de la consola de administración de acceso remoto. Puede instalarse opcionalmente en un servidor que no ejecute el rol de servidor de acceso remoto. En este caso, se usa para la administración remota de un equipo de acceso remoto que ejecuta DirectAccess y VPN. La característica de herramientas de administración de acceso remoto consiste de los siguientes elementos: Herramientas de la línea de comandos y GUI de acceso remoto Módulo de acceso remoto para Windows PowerShell Las dependencias incluyen: Consola de administración de directivas de grupo Kit de administración de Connection Manager (CMAK) de RAS Windows PowerShell 3.0 Infraestructura y herramientas de administración de gráficos

Rol de acceso remoto

El rol se instala y desinstala mediante la consola del Administrador del servidor. Incluye tanto DirectAccess, que antes era una característica de Windows Server 2008 R2, como los servicios de enrutamiento y acceso remoto (RRAS), que antes eran un servicio de roles de los Servicios de acceso y directivas de redes (NPAS). El rol de acceso remoto consta de dos componentes:

VPN de los Servicios de acceso remoto y enrutamiento de DirectAccess (RRAS): DirectAccess y VPN se administran en forma conjunta en la consola de administración de acceso remoto.
Enrutamiento RRAS: las características del enrutamiento RRAS se administran en la consola de administración de acceso remoto heredada.

Las dependencias son las siguientes:

Servidor web de Internet Information Services (IIS): se requiere esta característica para configurar el servidor de ubicación de la red y el sondeo web predeterminado.
Windows Internal Database: se usa para las cuentas locales en el servidor de acceso remoto.

Característica Herramientas de administración de acceso remoto

Esta característica se instala de la siguiente manera:

Se instala de forma predeterminada en un servidor de acceso remoto cuando se instala el rol de acceso remoto, y admite la interfaz de usuario de la consola de administración de acceso remoto.
Puede instalarse opcionalmente en un servidor que no ejecute el rol de servidor de acceso remoto. En este caso, se usa para la administración remota de un equipo de acceso remoto que ejecuta DirectAccess y VPN.

La característica de herramientas de administración de acceso remoto consiste de los siguientes elementos:

Herramientas de la línea de comandos y GUI de acceso remoto
Módulo de acceso remoto para Windows PowerShell

Las dependencias incluyen:

Consola de administración de directivas de grupo
Kit de administración de Connection Manager (CMAK) de RAS
Windows PowerShell 3.0
Infraestructura y herramientas de administración de gráficos

Requisitos de hardware

Los requisitos de hardware para este escenario incluyen los siguientes:

Al menos dos equipos de acceso remoto que se recopile en una implementación multisitio. Requisitos de hardware de estos equipos se describen en Deploy a Single DirectAccess Server with Advanced Settings.
Para probar el escenario, al menos un equipo que ejecuta Windows 8 y configurado como un cliente de DirectAccess se requiere. Para probar el escenario para clientes que ejecutan Windows 7 se requiere al menos un equipo que ejecuta Windows 7.
Para equilibrar el tráfico de carga entre servidores de punto de entrada, es necesario un equilibrador de carga global externo de terceros.

Requisitos de software

Los requisitos de software para este escenario son los siguientes:

Requisitos de software para la implementación de un solo servidor. Para obtener más información, consulte Deploy a Single DirectAccess Server with Advanced Settings.
Además de los requisitos de software para un único servidor hay una serie de requisitos multisite-específicas:
- Requisitos de autenticación de IPsec, en una implementación multisitio de DirectAccess deben implementarse con IPsec de autenticación de certificados de la máquina. No se admite la opción para realizar la autenticación de IPsec con el servidor de acceso remoto como un proxy de Kerberos. Se requiere una CA interna para implementar los certificados IPsec.
- Requisitos de servidor de ubicación de red e IP-HTTPS, requieren certificados para IP-HTTPS y el servidor de ubicación de red debe ser emitido por una entidad de certificación. No se admite la opción de usar certificados que emite y autofirmados por el servidor de acceso remoto automáticamente. Los certificados se pueden emitir mediante una CA interna o una CA externa de terceros.
- Requisitos de Active Directory, es necesario al menos un sitio de Active Directory. El servidor de acceso remoto debe encontrarse en el sitio. Para los tiempos de actualización más rápidos, se recomienda que cada sitio tiene un controlador de dominio grabable, aunque esto no es obligatorio.
- Requisitos de grupo de seguridad: requisitos son los siguientes:
  - Un grupo de seguridad solo se requiere para todos los Windows 8 los equipos cliente de todos los dominios. Se recomienda crear un grupo de seguridad único de estos clientes para cada dominio.
  - Un grupo de seguridad único que contiene equipos con Windows 7 es necesario para cada punto de entrada configurado para admitir a clientes de Windows 7. Se recomienda tener un grupo de seguridad único para cada punto de entrada en cada dominio.
  - Los equipos no deben estar incluidos en más de un grupo de seguridad que incluya clientes de DirectAccess. Si los clientes están incluidos en varios grupos, la resolución de nombres para las solicitudes de los clientes no funcionará según lo esperado.
- Requisitos del GPO: GPO pueden crearse manualmente antes de configurar el acceso remoto o se crea automáticamente durante la implementación de acceso remoto. Requisitos son los siguientes:
  - Un GPO de cliente único se requiere para cada dominio.
  - Un GPO de servidor se requiere para cada punto de entrada en el dominio donde se encuentra el punto de entrada. Por tanto, si varios puntos de entrada se encuentran en el mismo dominio, habrá varios GPO (uno para cada punto de entrada) en el dominio de servidores.
  - Un único GPO de cliente de Windows 7 es necesario para cada punto de entrada habilitado para la compatibilidad con clientes de Windows 7, para cada dominio.

Problemas conocidos

Los siguientes son problemas conocidos al configurar un escenario de multisitio:

Varios puntos de entrada en la misma subred IPv4: agregar varios puntos de entrada en la misma subred IPv4 obtendrá un mensaje de conflicto de dirección IP y la dirección DNS64 para el punto de entrada no se configurará según lo esperado. Este problema se produce cuando no se ha implementado IPv6 en las interfaces de los servidores de la red corporativa internas. Para evitar este problema, ejecute el siguiente comando de Windows PowerShell en todos los servidores de acceso remoto actuales y futuros:
```
Set-NetIPInterface –InterfaceAlias <InternalInterfaceName> –AddressFamily IPv6 –DadTransmits 0
```
Si la dirección pública especificada para que los clientes de DirectAccess para conectarse al servidor de acceso remoto tiene un sufijo que se incluyen en la tabla NRPT, DirectAccess podrían no funcionar según lo esperado. Asegúrese de que la tabla NRPT tenga una exención para el nombre público. En una implementación multisitio, deben agregarse las exenciones para los nombres de todos los puntos de entrada públicos. Tenga en cuenta que if túnel forzado se habilita estas excepciones se agregan automáticamente. Se quitan si se deshabilita el túnel forzado.
Al usar el cmdlet de Windows PowerShell Disable-DAMultiSite, los parámetros WhatIf y Confirm no tienen ningún efecto y se deshabilitará la funcionalidad de multisitio y Windows 7 los GPO que se va a quitar.
Cuando Windows 7 los clientes que usan DCA en una implementación multisitio se actualizan a Windows 8, el Asistente de conectividad de red no funciona. Este problema puede resolverse antes de la actualización de cliente modificando el Windows 7 GPO mediante los siguientes cmdlets de Windows PowerShell:
```
Set-GPRegistryValue -Name <Windows7GpoName> -Domain <DomainName> -Key "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant" -ValueName "TemporaryValue" -Type Dword -Value 1
Remove-GPRegistryValue -Name <Windows7GpoName> -Domain <DomainName> -Key "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant" 
```
En caso de que ya se ha actualizado el cliente, a continuación, mueva el equipo cliente para el Windows 8 grupo de seguridad.
Cuando se modifica la configuración del controlador de dominio mediante el cmdlet de Windows PowerShell Set-DAEntryPointDC, si el parámetro ComputerName especifica un servidor de acceso remoto en un punto de entrada que no sea el último agregado a la implementación multisitio, se mostrará una advertencia que indica que el servidor especificado no se actualizará hasta la siguiente actualización de directiva. Se pueden ver los servidores reales que no se ha actualizado mediante el estado de configuración de en el panel de la consola de administración de acceso remoto. Esto no causará problemas de funcionamiento, sin embargo, puede ejecutar gpupdate /force en los servidores que no se ha actualizado para obtener el estado de configuración se actualiza inmediatamente.

Cuando se implementa la funcionalidad de multisitio en una red corporativa de sólo IPv4, cambiar interna prefijo IPv6 también cambios DNS64 la dirección de red, pero no actualiza la dirección de las reglas de firewall que permiten las consultas DNS para el servicio de DNS64. Para resolver este problema, ejecute los siguientes comandos de Windows PowerShell después de cambiar el prefijo IPv6 de la red interna:

$dns64Address = (Get-DAClientDnsConfiguration).NrptEntry | ?{ $_.DirectAccessDnsServers -match ':3333::1' } | Select-Object -First 1 -ExpandProperty DirectAccessDnsServers

$serverGpoName = (Get-RemoteAccess).ServerGpoName

$serverGpoDc = (Get-DAEntryPointDC).DomainControllerName

$gpoSession = Open-NetGPO -PolicyStore $serverGpoName -DomainController $serverGpoDc

Get-NetFirewallRule -GPOSession $gpoSession | ? {$_.Name -in @('0FDEEC95-1EA6-4042-8BA6-6EF5336DE91A', '24FD98AA-178E-4B01-9220-D0DADA9C8503')} |  Set-NetFirewallRule -LocalAddress $dns64Address

Save-NetGPO -GPOSession $gpoSession

Si se ha implementado DirectAccess cuando una infraestructura ISATAP existente está presente, al quitar un punto de entrada era un host ISATAP, las direcciones de servidor DNS de todos los sufijos DNS en la tabla NRPT quitará la dirección IPv6 del servicio DNS64.

Para resolver este problema, en el configuración de servidor de infraestructura asistente, en la DNS página, quitar los sufijos DNS que se han modificado y agréguelos de nuevo con las direcciones de servidor DNS correctas, haciendo clic en detectar en el direcciones de servidor DNS cuadro de diálogo.