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 “The Subnet in which the WorkSpace was launched does not have an available private ip address” En esta publicación, analizaremos cómo resolver este problema para los casos en que la organización disponga de un entorno de Amazon WorkSpaces usando AD Connector para dirigir las solicitudes de directorio a su Microsoft Active Directory local (sin almacenar ninguna información en la nube como caché).
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 flexible 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 sus usuarios. Para el directorio, se puede elegir entre:
- Simple Active Directory
- 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 esta publicación, 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 dirección 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.
La VPC es donde están las instancias de workspaces y, por lo tanto, el AD Connector:
Subred1:
Subred2:
Si revisamos el AD Connector, podemos confirmar que se estaban utilizando estas subredes:
El AD Connector 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 crear un número superior a 500 WorkSpaces en el entorno. Recuerde que cada subred de AWS VPC consume cinco direcciones IP, siendo las primeras cuatro y la última dirección utilizadas por AWS para gestión de redes, 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 es posible, ya que las subredes debían recrearsepara 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 “ Deregister ” y, en consecuencia, eliminar WorkSpaces. Como se trataba de un entorno productivo, esta opción fue descartada. Ver imagen a continuación
d) Cambiar subredes de conector AD: no existe la 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 paraque el usuario de la cuenta del AD Connector, sea diferente del usuario configurado para el conector ya existentes.
Parte 3 — La solución
A partir de la última opción, tenemos la siguiente solución: crear nuevas subredes y un nuevo conector AD para servir a los escritorios virtuales creados a partir de ahora.
a) Creamos dos nuevas subredes, en este caso con máscara de red de /24:
b) Se crea el nuevo AD Connector apuntando a estas subredes (recordar que la cuenta de servicio debe ser diferente de la cuenta del otro conector).
El AD Connector utiliza las puertas de enlace de comunicación local de Active Directory en los IP 10.0.2.140 y 10.0.7.222 de las subredes /24. Para esta comunicación utiliza la cuenta de servicio “c4iocesar”.
c) En Amazon WorkSpaces
- Seleccionamos el nuevo directorio.
- Ejecutamos la opción “Actions” -> “Register”.
- Se seleccionan las nuevas subredes.
- Y finalmente se registra el directorio.
- Ahora se puede usar WorkSpaces con este nuevo directorio.
Como se muestra a continuación, puede comprobar que se han publicado nuevos Amazon Workspaces satisfactoriamente:
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.
Sobre el traductor
Rene Martinez es Arquitecto de Solucionaes Senior en AWS Chile.