Diseño de VPC

En esta sección, se describen las prácticas recomendadas para dimensionar la VPC y las subredes, el flujo de tráfico y las implicaciones para el diseño de los servicios de directorio.

Estos son algunos aspectos que debe tener en cuenta al diseñar la VPC, las subredes, los grupos de seguridad, las políticas de enrutamiento y las listas de control de acceso a la red (ACL) para su Amazon, de WorkSpaces modo que pueda crear su WorkSpaces entorno con escalabilidad, seguridad y facilidad de administración:

• VPC: se recomienda utilizar una VPC independiente específica para la implementación. WorkSpaces Con una VPC independiente, puede especificar las barreras de control y seguridad necesarias para su empresa WorkSpaces mediante la creación de una separación de tráfico.

• Servicios de directorio: cada AWS Directory Service construcción requiere un par de subredes que proporcionen un servicio de directorio de alta disponibilidad dividido entre las AZ.

• Tamaño de subred: WorkSpaces las implementaciones están vinculadas a una construcción de directorio y residen en la misma VPC que haya elegido AWS Directory Service, pero pueden estar en diferentes subredes de VPC. Algunas consideraciones:

  • Los tamaños de las subredes son permanentes y no pueden cambiar. Debe dejar un amplio espacio para el crecimiento futuro.

  • Puede especificar un grupo de seguridad predeterminado para el que elija AWS Directory Service. El grupo de seguridad se aplica a todos los WorkSpaces que están asociados a la AWS Directory Service construcción específica.

  • Puede hacer que varias instancias AWS Directory Service usen la misma subred.

Tenga en cuenta sus planes para el futuro cuando diseñe su VPC. Por ejemplo, es posible que desee agregar componentes de administración, como un servidor antivirus, un servidor de administración de parches o un servidor de MFA AD o RADIUS. Vale la pena planificar direcciones IP adicionales disponibles en el diseño de su VPC para adaptarse a dichos requisitos.

Para obtener orientación y consideraciones detalladas sobre el diseño de las VPC y el tamaño de las subredes, consulte la presentación de re:Invent How Amazon.com is Moving to Amazon. WorkSpaces

Interfaces de red

Cada una WorkSpaces tiene dos interfaces de red elásticas (ENI), una interfaz de red de administración () y una interfaz de red eth0 principal (). eth1 AWS utiliza la interfaz de red de administración para administrar la WorkSpace : es la interfaz en la que termina la conexión del cliente. AWS utiliza un rango de direcciones IP privadas para esta interfaz. Para que el enrutamiento de red funcione correctamente, no puede usar este espacio de direcciones privado en ninguna red que pueda comunicarse con su WorkSpaces VPC.

Para obtener una lista de los rangos de IP privadas que se utilizan por región, consulta Amazon WorkSpaces Details.

nota

Amazon WorkSpaces y sus interfaces de red de administración asociadas no residen en su VPC y no puede ver la interfaz de red de administración ni el ID de instancia de Amazon Elastic Compute Cloud (Amazon EC2) en AWS Management Console su VPC (consulteFigure 5, y). Figure 6 Figure 7 Sin embargo, puede ver y modificar la configuración del grupo de seguridad de su interfaz de red principal (eth1) en la consola. La interfaz de red principal de cada una de WorkSpace ellas cuenta para sus cuotas de recursos de ENI en Amazon EC2. Para despliegues grandes de Amazon WorkSpaces, necesitas abrir un ticket de soporte a través del AWS Management Console para aumentar tus cuotas de ENI.

Flujo de tráfico

Puedes dividir el WorkSpaces tráfico de Amazon en dos componentes principales:

• El tráfico entre el dispositivo cliente y el WorkSpaces servicio de Amazon.

• El tráfico entre el WorkSpaces servicio de Amazon y el tráfico de la red del cliente.

En la siguiente sección se analizan estos dos componentes.

Dispositivo cliente para WorkSpace

Independientemente de su ubicación (local o remota), el dispositivo que ejecuta el WorkSpaces cliente de Amazon utiliza los mismos dos puertos para la conectividad con el WorkSpaces servicio de Amazon. El cliente utiliza el puerto 443 (puerto HTTPS) para toda la información relacionada con la autenticación y la sesión, y el puerto 4172 (puerto PCoIP), con el protocolo de control de transmisión (TCP) y el protocolo de datagramas de usuario (UDP), para la transmisión de píxeles a una determinada red y para comprobar el estado de la red. WorkSpace El tráfico de ambos puertos está cifrado. El tráfico del puerto 443 se usa para la autenticación y la información de sesión y usa TLS para cifrar el tráfico. El tráfico de streaming de píxeles utiliza el cifrado AES de 256 bits para la comunicación entre el cliente y el cliente, a través de la WorkSpace pasarela eth0 de streaming. Puede encontrar más información en la Seguridad sección de este documento.

Publicamos los rangos de IP por región de nuestras pasarelas de transmisión PCoIP y los puntos finales de comprobación del estado de la red. Puedes limitar el tráfico saliente en el puerto 4172 desde tu red corporativa a la pasarela de AWS streaming y a los puntos finales de comprobación del estado de la red permitiendo únicamente el tráfico saliente del puerto 4172 a AWS las regiones específicas en las que utilizas Amazon. WorkSpaces Para conocer los rangos de IP y los puntos finales de comprobación del estado de la red, consulte los rangos de IP de Amazon WorkSpaces PCoIP Gateway.

El WorkSpaces cliente de Amazon tiene una verificación de estado de la red integrada. Esta utilidad muestra a los usuarios si su red admite una conexión mediante un indicador de estado en la parte inferior derecha de la aplicación. La siguiente figura muestra una vista más detallada del estado de la red. Para acceder a ella, seleccione Red en la parte superior derecha del cliente.

Figura 1: WorkSpaces Cliente: comprobación de red

Un usuario inicia una conexión desde su cliente al WorkSpaces servicio de Amazon proporcionando su información de inicio de sesión para el directorio utilizado por la construcción de Directory Service, normalmente su directorio corporativo. La información de inicio de sesión se envía mediante HTTPS a las pasarelas de autenticación del WorkSpaces servicio de Amazon en la región en la que WorkSpace se encuentra. A continuación, la pasarela de autenticación del WorkSpaces servicio de Amazon reenvía el tráfico a la construcción específica de AWS Directory Service asociada a la suya WorkSpace.

Por ejemplo, cuando se utiliza el AD Connector, el AD Connector reenvía la solicitud de autenticación directamente a tu servicio de AD, que puede estar en las instalaciones o en una AWS VPC. Para obtener más información, consulte la sección Escenarios de implementación de AD DS de este documento. El AD Connector no almacena ninguna información de autenticación y actúa como un proxy sin estado. Como resultado, es imprescindible que el AD Connector tenga conectividad con un servidor AD. El AD Connector determina a qué servidor AD conectarse mediante los servidores DNS que defina al crear el AD Connector.

Si utilizas un AD Connector y tienes el MFA activado en el directorio, el token de MFA se comprueba antes de la autenticación del servicio de directorio. Si se produce un error en la validación de la MFA, la información de inicio de sesión del usuario no se reenvía a AWS Directory Service.

Una vez que el usuario se autentica, el tráfico de transmisión comienza utilizando el puerto 4172 (puerto PCoIP) a través de la puerta de enlace de transmisión hasta el AWS . WorkSpace La información relacionada con la sesión se sigue intercambiando a través de HTTPS durante toda la sesión. El tráfico de streaming utiliza el primer ENI de la WorkSpace (eth0de la WorkSpace) que no está conectada a la VPC. La conexión de red desde la pasarela de streaming al ENI la gestiona AWS. En caso de que se produzca un fallo de conexión entre las pasarelas de transmisión y la ENI de WorkSpaces transmisión, se CloudWatch generará un evento. Para obtener más información, consulta la CloudWatch sección Supervisión o registro con Amazon de este documento.

La cantidad de datos que se envían entre el WorkSpaces servicio de Amazon y el cliente depende del nivel de actividad de los píxeles. Para garantizar una experiencia óptima para los usuarios, recomendamos que el tiempo de ida y vuelta (RTT) entre el WorkSpaces cliente y la AWS región en la que WorkSpaces se encuentra usted sea inferior a 100 milisegundos (ms). Por lo general, esto significa que su WorkSpaces cliente se encuentra a menos de dos mil millas de la región en la que WorkSpace se aloja. La página web Connection Health Check puede ayudarte a determinar la AWS región más óptima para conectarte al WorkSpaces servicio de Amazon.

Amazon WorkSpaces Service a VPC

Una vez que se autentica una conexión de un cliente a un cliente WorkSpace y se inicia el tráfico de streaming, el WorkSpaces cliente mostrará un escritorio Windows o Linux (su Amazon WorkSpace) que está conectado a su nube privada virtual (VPC), y su red debería mostrar que ha establecido esa conexión. La interfaz WorkSpace de red elástica (ENI) principal, identificada comoeth1, tendrá una dirección IP asignada desde el servicio de Protocolo de configuración dinámica de host (DHCP) que proporciona la VPC, normalmente desde las mismas subredes que su Directory AWS Service. La dirección IP permanece en ella WorkSpace durante toda la vida útil de la. WorkSpace El ENI de su VPC tiene acceso a cualquier recurso de la VPC y a cualquier red que haya conectado a su VPC (mediante un emparejamiento de VPC, una conexión o una conexión VPN). AWS Direct Connect

El acceso del ENI a los recursos de la red viene determinado por la tabla de rutas de la subred y el grupo de seguridad predeterminado que el AWS Directory Service configura para cada uno WorkSpace, así como por cualquier grupo de seguridad adicional que usted asigne al ENI. Puede añadir grupos de seguridad al ENI situado frente a su VPC en cualquier momento mediante la AWS Management Console tecla o. AWS CLI (Para obtener más información sobre los grupos de seguridad, consulte Security Groups for Your WorkSpaces.) Además de los grupos de seguridad, puede usar el firewall basado en host que prefiera en un momento dado WorkSpace para limitar el acceso de la red a los recursos de la VPC.

Se recomienda crear el conjunto de opciones de DHCP con las IP del servidor DNS y los nombres de dominio totalmente cualificados que sean autoritativos para su Active Directory específico de su entorno y, a continuación, asignar esas opciones de DHCP creadas de forma personalizada y configuradas a la Amazon VPC que utiliza Amazon. WorkSpaces De forma predeterminada, Amazon Virtual Private Cloud (Amazon VPC) usa el AWS DNS en lugar del DNS del servicio de directorio. El uso de un conjunto de opciones de DHCP garantizará una resolución adecuada de los nombres de DNS y una configuración coherente de sus servidores de nombres de DNS internos WorkSpaces, no solo para su carga de trabajo o instancia, sino también para cualquier carga de trabajo o instancia de soporte que haya planificado para su implementación.

Cuando se aplican las opciones de DHCP, hay dos diferencias importantes en la forma en que se aplican WorkSpaces en comparación con la forma en que se aplican en las instancias EC2 tradicionales:

• La primera diferencia es la forma en que se aplicarán los sufijos DNS de las opciones de DHCP. Cada uno WorkSpace tiene una configuración de DNS configurada para su adaptador de red con las opciones Añadir sufijos DNS principales y específicos de la conexión y Añadir sufijos principales de los sufijos DNS principales activadas. La configuración se actualizará con el sufijo DNS configurado en el AWS Directory Service que registró y asociado al mismo de forma WorkSpace predeterminada. Además, si el sufijo DNS configurado en el conjunto de opciones de DHCP utilizado es diferente, se agregará y se aplicará a todos los sufijos asociados. WorkSpaces

• La segunda diferencia es que las IP DNS de la opción DHCP configuradas no se aplicarán a ellas WorkSpace debido a que el WorkSpaces servicio Amazon prioriza las direcciones IP de los controladores de dominio del directorio configurado.

Como alternativa, puede configurar una zona alojada privada de Route 53 para admitir un entorno de DNS híbrido o dividido y obtener la resolución de DNS adecuada para su WorkSpaces entorno de Amazon. Para obtener más información, consulte Opciones de DNS de nube híbrida para VPC y DNS AWS híbrido con Active Directory.

nota

Cada uno WorkSpace debe actualizar la tabla de IP al aplicar un conjunto de opciones de DHCP nuevo o diferente a la VPC. Para actualizar, puede ejecutar ipconfig /renew o reiniciar cualquiera WorkSpace de las unidades de la VPC configuradas con las opciones de DHCP actualizadas configuradas. Si utilizas AD Connector y actualizas las direcciones IP de las direcciones IP/controladores de dominio conectados, debes actualizar la clave de DomainJoinDNS registro de Skylight en tu. WorkSpaces Se recomienda hacerlo mediante un GPO. La ruta a esta clave de registro esHKLM:\SOFTWARE\Amazon\Skylight. Este valor no REG_SZ se actualiza si se modifica la configuración de DNS del conector AD y los conjuntos de opciones de DHCP de la VPC tampoco actualizarán esta clave.

La figura de la sección Escenarios de implementación de AD DS de este documento técnico muestra el flujo de tráfico descrito.

Como se ha explicado anteriormente, el WorkSpaces servicio Amazon prioriza las direcciones IP del controlador de dominio del directorio configurado para la resolución de DNS e ignora los servidores DNS configurados en el conjunto de opciones de DHCP. Si necesitas tener un control más detallado de la configuración del servidor DNS de tu Amazon WorkSpaces, puedes usar las instrucciones para actualizar los servidores DNS de Amazon WorkSpaces en la guía Actualizar servidores DNS para Amazon de la WorkSpaces Guía de WorkSpaces administración de Amazon.

Si WorkSpaces necesita resolver otros servicios en AWS la VPC y utiliza las opciones de DHCP predeterminadas establecidas con su VPC, el servicio DNS del controlador de dominio de esta VPC debe estar configurado para utilizar el reenvío de DNS, apuntando al servidor DNS de Amazon con la dirección IP en la base del CIDR de la VPC más dos; es decir, si el CIDR de la VPC es 10.0.0.0/24, debe configurar el reenvío de DNS utilizando el solucionador de DNS de Route 53 estándar en 10.0.0.2.

En caso de WorkSpaces que necesite la resolución de DNS de los recursos de su red local, puede usar un punto final de salida de Route 53 Resolver, crear una regla de reenvío de Route 53 y asociar esta regla a las VPC que requieren esta resolución de DNS. Si ha configurado el reenvío del servicio DNS de su controlador de dominio al solucionador de DNS de Route 53 predeterminado de su VPC, como se explica en el párrafo anterior, el proceso de resolución de DNS se encuentra en la guía Resolución de consultas de DNS entre VPC y su red de la Guía para desarrolladores de Amazon Route 53.

Si utiliza el conjunto de opciones de DHCP predeterminado y necesita otros hosts de sus VPC que no forman parte de su dominio de Active Directory para poder resolver los nombres de host en su espacio de nombres de Active Directory, puede usar este punto final saliente de Route 53 Resolver y agregar otra regla de reenvío de Route 53 que reenvíe las consultas de DNS de su dominio de Active Directory a sus servidores DNS de Active Directory. Esta regla de reenvío de Route 53 tendrá que estar asociada al punto final saliente de Route 53 Resolver que puede acceder al servicio DNS de Active Directory y a todas las VPC que desee habilitar para resolver los registros de DNS en su dominio de WorkSpaces Active Directory.

Del mismo modo, se puede utilizar un terminal entrante de Route 53 Resolver para permitir la resolución por DNS de los registros DNS de su dominio de WorkSpaces Active Directory procedentes de la red local.

Figura 2: Ejemplo de resolución de WorkSpaces DNS con puntos finales de Route 53

• Amazon WorkSpaces utilizará el servicio DNS AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) para la resolución de DNS. El servicio AWS Managed Microsoft AD DNS resuelve el example.aws dominio y reenvía todas las demás consultas de DNS al solucionador de DNS de Route 53 predeterminado en la dirección IP base CIDR de la VPC +2 para habilitar la resolución de DNS.

  La VPC de Shared Services contiene un punto final de resolución de salida de Route 53, que está asociado a dos reglas de reenvío de Route 53. Una de estas reglas reenvía las consultas de DNS del example.com dominio a los servidores DNS locales. La segunda regla reenvía las consultas de DNS de su AWS Managed Microsoft AD dominio example.aws al servicio DNS de Active Directory en la VPC de Shared Services.

  Con esta arquitectura, Amazon WorkSpaces podrá resolver las consultas de DNS para lo siguiente:

  • Tu AWS Managed Microsoft AD dominioexample.aws.

  • Las instancias EC2 del dominio configuradas con el conjunto de opciones de DHCP predeterminado (por ejemplohost1.eu-west-1.compute.internal), así como otros AWS servicios o puntos finales.

  • Los hosts y los servicios de su dominio local, como. host3.example.com

• • Las demás cargas de trabajo de EC2 de la VPC de Shared Services (host1.eu-west-1.compute.internal) y de la WorkSpaces VPC (host2.eu-west-1.compute.internal) pueden utilizar las mismas resoluciones de DNS que las suyas WorkSpaces, siempre que las reglas de reenvío de Route 53 estén asociadas a ambas VPC. En este caso, la resolución de DNS del example.aws dominio pasará por el solucionador de DNS de Route 53 predeterminado en la dirección IP base CIDR de la VPC +2, que, según las reglas de reenvío de Route 53 configuradas y asociadas, la reenviará a través del punto de enlace saliente de Route 53 Resolver al WorkSpaces servicio DNS de Active Directory.

• • Por último, un cliente local también puede realizar la misma resolución de DNS, ya que el servidor DNS local está configurado con reenviadores condicionales para los eu-west-1.compute.internal dominios example.aws y, que reenvían las consultas de DNS de estos dominios a las direcciones IP del punto final entrante de Route 53 Resolver.

Ejemplo de una configuración típica

Consideremos un escenario en el que tiene dos tipos de usuarios y su AWS Directory Service utiliza un AD centralizado para la autenticación de los usuarios:

• Trabajadores que necesitan acceso total desde cualquier lugar (por ejemplo, empleados a tiempo completo): estos usuarios tendrán acceso total a Internet y a la red interna, y pasarán a través de un firewall desde la VPC a la red local.

• Trabajadores que solo deberían tener acceso restringido desde dentro de la red corporativa (por ejemplo, contratistas y consultores): estos usuarios han restringido el acceso a Internet a través de un servidor proxy a sitios web específicos de la VPC y tendrán acceso limitado a la red en la VPC y a la red local.

Le gustaría ofrecer a los empleados a tiempo completo la posibilidad de tener acceso de administrador local WorkSpace para instalar el software, y le gustaría aplicar la autenticación de dos factores con MFA. También quieres permitir que los empleados a tiempo completo accedan a Internet sin restricciones por parte de sus empleados. WorkSpace

En el caso de los contratistas, es mejor bloquear el acceso de los administradores locales para que solo puedan utilizar determinadas aplicaciones preinstaladas. Para ello WorkSpaces, desea aplicar controles restrictivos de acceso a la red mediante grupos de seguridad. Debe abrir los puertos 80 y 443 únicamente para acceder a sitios web internos específicos y desea bloquear por completo su acceso a Internet.

En este escenario, hay dos tipos de usuarios completamente diferentes con requisitos diferentes de acceso a la red y al escritorio. Se recomienda administrarlos y configurarlos de WorkSpaces forma diferente. Deberá crear dos conectores AD, uno para cada persona de usuario. Cada AD Connector requiere dos subredes que tengan suficientes direcciones IP disponibles para cumplir con sus estimaciones de crecimiento WorkSpaces de uso.

nota

Cada subred de AWS VPC consume cinco direcciones IP (las cuatro primeras y la última dirección IP) con fines de administración, y cada AD Connector consume una dirección IP en cada subred en la que persiste.

Otras consideraciones para este escenario son las siguientes:

• AWS Las subredes de VPC deben ser subredes privadas, de modo que el tráfico, como el acceso a Internet, pueda controlarse mediante una puerta de enlace de traducción de direcciones de red (NAT), un servidor proxy-NAT en la nube o enrutarse a través del sistema de administración de tráfico local.

• Hay un firewall para todo el tráfico de VPC destinado a la red local.

• El servidor AD de Microsoft y los servidores RADIUS de MFA son locales (consulte el Escenario 1: Uso del conector AD para la autenticación mediante proxy para AD DS local en este documento) o forman parte de la implementación en la AWS nube (consulte el Escenario 2 y el Escenario 3, Escenarios de implementación de AD DS, en este documento).

Dado que a todos WorkSpaces se les concede algún tipo de acceso a Internet y que están alojados en una subred privada, también debe crear subredes públicas que puedan acceder a Internet a través de una puerta de enlace a Internet. Necesita una puerta de enlace NAT para los empleados a tiempo completo, que les permita acceder a Internet, y un servidor proxy NAT para los consultores y contratistas, a fin de limitar su acceso a sitios web internos específicos. Para evitar fallos, diseñar para una alta disponibilidad y limitar las tarifas de tráfico entre zonas de disponibilidad, debería disponer de dos puertas de enlace NAT y servidores NAT o proxy en dos subredes diferentes en una implementación con varias zonas de disponibilidad. Las dos AZ que seleccione como subredes públicas coincidirán con las dos AZ que utilice para sus WorkSpaces subredes, en regiones que tengan más de dos zonas. Puede enrutar todo el tráfico de cada zona de disponibilidad WorkSpaces a la subred pública correspondiente para limitar los cargos por tráfico entre zonas de disponibilidad y facilitar la administración. En la siguiente figura se muestra la configuración de la VPC.

Figura 3: Diseño de VPC de alto nivel

La siguiente información describe cómo configurar los dos WorkSpaces tipos diferentes:

Para configurarlo WorkSpaces para empleados a tiempo completo:

1. En Amazon WorkSpaces Management Console, selecciona la opción Directorios en la barra de menús.

2. Elija el directorio que aloja a sus empleados a tiempo completo.

3. Elija la configuración de administrador local.

Al activar esta opción, cualquier persona recién creada WorkSpace tendrá privilegios de administrador local. Para conceder acceso a Internet, configure la NAT para el acceso saliente a Internet desde su VPC. Para habilitar la MFA, debe especificar un servidor RADIUS, direcciones IP de servidor, puertos y una clave previamente compartida.

Para los empleados a tiempo completo WorkSpaces, el tráfico entrante al Protocolo de Escritorio Remoto (RDP) desde la subred del Helpdesk WorkSpace puede limitarse al Protocolo de Escritorio Remoto (RDP) mediante la aplicación de un grupo de seguridad predeterminado a través de la configuración del AD Connector.

Para configurarlo para contratistas y consultores WorkSpaces :

1. En Amazon WorkSpaces Management Console, deshabilite el acceso a Internet y la configuración de administrador local.

2. Añada un grupo de seguridad en la sección de configuración del grupo de seguridad para aplicar un grupo de seguridad a todos los nuevos que WorkSpaces se creen en ese directorio.

En el caso de los consultores WorkSpaces, limite el tráfico entrante y saliente al aplicando un grupo de seguridad predeterminado WorkSpaces mediante la configuración del Conector AD a todos los WorkSpaces asociados al Conector AD. El grupo de seguridad impide el acceso saliente desde cualquier lugar que no sea el WorkSpaces tráfico HTTP y HTTPS, así como el tráfico entrante a RDP desde la subred del Helpdesk de la red local.

nota

El grupo de seguridad solo se aplica al ENI que se encuentra en la VPC (eth1en la WorkSpace) y el acceso al mismo WorkSpace desde el WorkSpaces cliente no está restringido como resultado de un grupo de seguridad. En la siguiente figura se muestra el diseño final de la WorkSpaces VPC.

Figura 4: WorkSpaces diseño con personas de usuario

AWS Directory Service

Como se mencionó en la introducción, AWS Directory Service es un componente fundamental de Amazon WorkSpaces. Con AWS Directory Service, puede crear tres tipos de directorios con Amazon WorkSpaces:

• AWS Managed Microsoft AD es un Microsoft AD administrado, con tecnología Windows Server 2012 R2. AWS Managed Microsoft AD está disponible en las ediciones Standard o Enterprise.

• Simple AD es un servicio de directorio gestionado independiente, compatible con Microsoft AD y con tecnología Samba 4.

• AD Connector es un proxy de directorio para redirigir las solicitudes de autenticación y las búsquedas de usuarios o grupos a su Microsoft AD local existente.

En la siguiente sección se describen los flujos de comunicación para la autenticación entre el servicio de WorkSpaces corretaje de Amazon y AWS Directory Service, las prácticas recomendadas para la implementación WorkSpaces con AWS Directory Service y los conceptos avanzados, como el MFA. También analiza los conceptos de arquitectura de infraestructura para Amazon WorkSpaces a escala, los requisitos de Amazon VPC y AWS Directory Service, incluida la integración con Microsoft AD Domain Services (AD DS) locales.