Blog de Amazon Web Services (AWS)

Amazon WorkSpaces: la subred en la que se inició WorkSpace no tiene una dirección IP privada disponible

Por: Caio Ribeiro César, Matheus Arrais

 

Recientemente, se nos dijo que al escalar el entorno, algunas organizaciones recibían el error «La subred en la que se lanzó el WorkSpace no tiene disponible». En esta publicación, analizaremos cómo resolver este problema cuando su organización disponga de un entorno de Amazon WorkSpaces mediante AD Connector para dirigir las solicitudes de directorio a su Microsoft Active Directory local (sin almacenar en caché ninguna información en la nube).

Amazon WorkSpaces es una solución de escritorio como servicio (DaaS) gestionada y segura.

Puede utilizar Amazon WorkSpaces para aprovisionar escritorios Windows o Linux en cuestión de minutos y escalar rápidamente para entregar miles de escritorios a empleados de todo el mundo. Amazon WorkSpaces ayuda a eliminar la complejidad de administrar el inventario de hardware, las versiones y parches del SO y la infraestructura de escritorio virtual (VDI), lo que ayuda a simplificar su estrategia de entrega de escritorios.

Con Amazon WorkSpaces, los usuarios obtienen un escritorio rápido y sensible de su elección al que se puede acceder desde cualquier lugar, en cualquier momento y desde cualquier dispositivo compatible. Comprueba aquí si tu dispositivo es compatible.

Amazon WorkSpaces utiliza directorios para almacenar y administrar información de WorkSpaces y usuarios. Para su directorio, puede elegir entre:

  • Simple Active Directory (no disponible en la región de São de Paulo).
  • Conector de Active Directory.
  • AWS Directory Service para Microsoft Active Directory, también conocido como «AD administrado».
  • Directorios externos, como Servicios de dominio de Azure Active Directory.

En este escenario, seguimos los pasos recomendados en el artículo «Habilitar un espacio de trabajo con conector de AD».

 

Parte 1 — Identificación del problema

Empezamos identificando el problema. WorkSpaces se inició, pero recibimos un mensaje de error de la consola que indica que la subred no tenía una IP disponible:

 

“The Subnet in which the WorkSpace was launched does not have an available private IP Address”

Continuamos con la investigación recopilando información de la VPC donde se estaba creando WorkSpaces y posteriormente sus subredes.

VPC donde están los espacios de trabajo y, por lo tanto, AD Connector:

 

 

Subred1:

 

 

Subred2:

 

 

Hemos confirmado en AD Connector que se estaban utilizando estas subredes:

 

El conector de AD utiliza las puertas de enlace de comunicación locales de Active Directory en las direcciones IP 10.0.5.139 y 10.0.6.202 en dos subredes /24, y para esta comunicación utiliza una cuenta de servicio de directorio.

Teniendo en cuenta la información «IPv4 disponible» en cada subred, sumamos la disponibilidad de 500 IPs, lo que explica el error ya que en este caso tenemos que aumentar un número superior a 500 WorkSpaces creados en el entorno. Recuerde que cada subred de AWS VPC consume cinco direcciones IP, siendo las primeras cuatro y la última dirección IP a efectos de gestión, obtenga más información al respecto accediendo a este enlace a la documentación. Además, cada conector de AD consume una dirección IP en cada subred en la que existe.

 

Parte 2 — Desarrollo de la solución

 

Comenzamos el paso de análisis para una posible solución, teniendo en cuenta los siguientes puntos:

a) Cambiar el CIDR de las subredes: no era posible, ya que las subredes debían recrearse para este cambio.
b) Cambiar subredes directamente en WorkSpaces: no existe tal configuración.
c) Cambiar el conector de AD que utiliza WorkSpaces: no era posible, dado que para cambiar el directorio, debemos realizar «Anular registro» y, en consecuencia, eliminar WorkSpaces del directorio, ya que se trataba de un entorno de producción esta opción fue descartada y reforzada por la imagen de abajo indicando el mensaje «Se ha producido un error. El directorio sólo se puede quitar si no hay espacios de trabajo asignados.»

 

 

d) Cambiar subredes de conector AD: no existe tal opción para modificar la subred de un conector AD ya creado.

e) Crear un nuevo conector de AD y utilizar dos subredes nuevas con un nuevo directorio para espacios de trabajo: esta sería la solución, siempre que se tengan en cuenta las prácticas recomendadas para que el usuario de la cuenta de Conector de AD sea diferente del usuario configurado para Conector de AD ya existentes.

 

Parte 3 — La solución

A partir de la opción «e» del elemento anterior, tenemos la siguiente solución: crear nuevas subredes y un nuevo conector AD para servir a los escritorios virtuales creados a partir de ahora.

 

Fuente – https://d1.awsstatic.com/International/es_ES/whitepapers/Best_Practices_for_Deploying_Amazon_WorkSpaces.pdf  

 

a) Creamos dos nuevas subredes, debido al inesperado aumento del número de usuarios que necesitan escritorios virtuales de WorkSpaces en esta subred. Por lo tanto, utilizamos dos nuevas subredes /24:

 

 

b) Hemos creado un nuevo conector de AD, apuntando a estas subredes (recordando que la cuenta de servicio debe ser diferente de la otra conexión de AD que se está utilizando en esta red).

 

Conector AD que utiliza las puertas de enlace de comunicación local de Active Directory en IP 10.0.2.140 y 10.0.7.222 en dos subredes /24, y para esta comunicación utiliza una cuenta de servicio «c4iocesar».

 

 

c) Ahora en Amazon WorkSpaces

  • Hemos seleccionado el nuevo directorio.

 

  • Opción «Acciones» > «Registrar».

 

  • Hemos seleccionado las nuevas subredes.

 

 

 

  • Finalmente podemos usar WorkSpaces en este nuevo directorio.

 

Como se muestra a continuación, puede comprobar que se han publicado nuevos Amazon Workspaces:

 

 

Conclusión

En esta publicación, analizamos cómo escalar sus WorkSpaces aunque haya agotado las direcciones IP de sus subredes. WorkSpaces se ejecutan en instancias de Amazon EC2 alojadas en la VPC. La comunicación entre EC2 y el cliente se gestiona mediante el protocolo PCoIP (PC sobre IP). La conexión del cliente debe permitir conexiones TCP y UDP salientes en el puerto 4172, junto con conexiones TCP salientes en el puerto 443. Para obtener más información acerca de WorkSpaces, visite https://aws.amazon.com/pt/workspaces/.

 


Sobre los autores

Matheus Arrais es Arquitecto de Soluciones para Socios de AWS. Se centra en las herramientas de gobierno y la estrategia de múltiples cuentas. Trabaja junto con socios de todo Brasil ayudándoles a emprender un viaje exitoso dentro de la asociación de AWS y a ofrecer la mejor solución para sus clientes.

Caio Ribeiro Cesar actualmente trabaja como arquitecto de soluciones especializado en tecnología de Microsoft en la nube de AWS. Comenzó su carrera profesional como administrador de sistemas, que continuó durante más de 13 años en áreas como seguridad de la información, identidad en línea y plataformas de correo electrónico corporativo. Recientemente se hizo fanático de la computación en la nube de AWS y ayuda a los clientes a aprovechar el poder de la tecnología de Microsoft en AWS.