miércoles, 13 de septiembre de 2023

Como crear reglas de Firewall distribuidas en VMware on AWS

 Muestro un ejemplo de cómo crear una política de firewall distribuido Tier 3, que controle el trafico entre servidores web, de aplicación y de BBDD. Para ello, haremos una política que permita el trafico http entre el servidor de web y el de aplicación, otra que permita el trafico MySQL entre el servidor de aplicaciones y el de BBDD, y una ultima que elimine todo el trafico de cualquiera de las aplicaciones con esta regla tier 3, a cualquier otra aplicación dentro de esta regla.

Para ello, accedemos a nuestra web de VMware Cloud, entramos en nuestro SDDC, pinchamos en "Networking & Security" y de ahí, click en Distributed Firewall, en el menú de la izquierda, en el apartado de "security", y luego en "Add Policy":

Agregamos un nombre a la nueva política que vamos a crear, vamos a DFW justo a la derecha del nombre de la política, y pinchamos en editar. En la ventana flotante que aparece, pinchamos en Groups, y marcamos el nombre del grupo que nos interesa. Aplicamos,

Y ya podemos empezar con las reglas que aplicará esa política. Primero empezaremos con la regla para permitir trafico web. 

Sobre la política antes creada, pinchamos en los 3 puntitos de la izquierda, y en el menu que aparece, seleccionamos "add rule":

Esto nos genera un nuevo campo dentro de la politica. Lo nombramos de alguna forma identificable, en este caso por ejemplo, "allow web traffic", y editamos la regla:

Ya teníamos un grupo creado llamado Web Servers, conteniendo las maquinas de este servicio. Lo seleccionamos, y aplicamos:

Sobre la regla, editamos el campo "destinations",

En la ventana flotante que aparece, como las anteriores, seleccionamos el grupo correspondiente, en este caso "app servers" (pasa como anteriormente, ya teníamos creado el grupo con las VM que contienen las app, igual que teníamos el grupo web servers):

Ya para terminar, hacemos click en servicios ( 2 imágenes mas arriba, el siguiente campo editable de la regla, a la derecha de "destinations"), y lo mismo, editar. En este caso marcamos el servicio HTTP, y aplicamos:

De nuevo lo mismo que antes...en la ventana donde vemos la regla, esta vez editamos el campo "applied to", seleccionamos "groups", y marcamos el "3 Tier".

Con esto, hemos dejado lista la regla para permitir el trafico web del grupo web servers al grupo app servers, por el puerto http. Vamos a generar ahora una regla para permitir el trafico MySQL. 

Para ello, repetimos el paso de la tercera imagen de este post, ir a los 3 puntitos de la política que creamos, pulsamos, aparecerá un menú desplegable, y pinchamos sobre "add rule". Ponemos nuestro nombre a la regla, en este caso "allow MySQL traffic", y editamos el campo Sources:


En la ventana flotante que aparece, seleccionaremos "app servers" y Apply:

Como veis, es exactamente igual que en la primera regla. En el campo "destinations" lo editamos, para seleccionar el grupo "DB Servers", y aplicamos. 

En el campo Servicios buscamos el servicio MySQL (en vez de haciendo scrolling podemos utilizar el campo filter, para no dejarnos la vista) y aplicamos.

En applied to, seleccionamos grupos, y marcamos el "3 tier" como hicimos en la anterior regla. Quedará algo asi:

Ya solo falta la regla para descartar el resto del trafico. 

Como hemos hecho anteriormente, vamos a los 3 puntitos de la politica, damos a "add Rule" y ponemos un nombre identificable a la regla. Y editamos los 3 campos críticos de las reglas, source, destination, y applied to. En los 3 campos marcamos "3 Tier". La diferencia es que en el campo "allow, pinchamos para expandir menú, y marcamos "drop":

Una vez modificado, pulsamos en "publish" ¡y ya lo tenemos!

Hecha una regla, hechas todas, el procedimiento es el mismo.

martes, 12 de septiembre de 2023

Como crear un segmento de red de VMware on AWS

 Vamos a ver un ejemplo rápido de configuración de red en VMware Cloud on AWS. En concreto, la creacion de un segmento de red. Para ello, vamos a nuestra consola de VMware Cloud, https://www.vmware.com/cloud-solutions.html, y accedemos con nuestro login y pass.

Esto nos llevará a nuestra pantalla principal con nuestros SDDCs:

Accedemos al que vamos a configurar, y nos vamos a la pestaña de "networking & security". Desde ahí, en el menú de la izquierda, pulsamos sobre "segments", y "add segment"

Desde aquí podremos configurar los valores del segmento de red. Básicamente es indicar el nombre del segmento, tipo, que suele ser Routed, y el segmento de red CIDR. Pulsamos en SAVE, y nos aparecerá un aviso indicando si queremos configurar el segmento. 

Podemos pulsar en NO. Nos aparecerá el nuevo segmento junto con los que teníamos en pantalla en la captura superior.

jueves, 7 de septiembre de 2023

Configurar NSX y HCX para migrar de cargas de trabajo en GCVE

 Siguiendo con el anterior artículo donde desplegábamos una nube privada basada en hosts VMware en Google Cloud, GCVE, y teniendo en cuenta que esta solución, igual que las de Azure y AWS despliegan no solo hosts con ESXi, sino el vSphere, con vSAN y HCX, vamos a ver cómo configurar NSX-T y HCX para migrar cargas de trabajo entre distintos entornos de vSphere.

Para ello entramos en nuestra consola de GCVE (Google Cloud VMware Engine) y en Resources, entramos en la nube privada a configurar (aqui todavia está desplegandose la que creamos anteriormente...).

Vamos a vSphere Management Network, y seguidamente hacemos click en el FQDN del NSX manager:

Esto nos lleva a la consola del NSX. Ahí pinchamos en Networking:

Bien...si no lo tenemos abierto, abrimos la consola de vSphere de nuestro GCVE, y desde el menú, vamos al HCX:

Dentro, en el menú de la izquierda,  en el apartado de infraestructura, nos encontramos los apartados de Site Pairing e interconnect, donde vemos que es fácil agregar la conectividad de los distintos entornos. Adjunto un par de capturas de las ventanas:



Migrar cargas de trabajo es tan fácil como ir en nuestro HCX al menú principal de la izquierda, y en Services / migración, pinchar en Migrate:

En la ventana flotante configuramos los parámetros para la migración:

 En la ventana de Transfer and Placement tienes varios elementos para configurar la migración, no voy a entrar en detalle en todos porque son evidentes: ubicacion, datastore...pero sí interesa la opción de migración, que puede ser vMotion y bulk migration:

Una vez tenemos seleccionadas las opciones de transfer and placement, podemos ver la tarea que se va a ejecutar, ubicación de las VMs, formato de almacenamiento en destino...y ya solo queda pulsar en "validate", y "GO"

Con esto, hemos terminado. Una vez finalice la tarea, veremos la VM corriendo en el cluster receptor.

Si te ha gustado el articulo, puedes invitarme a un café ;)

Desplegando VMware en Google cloud: GCVE

 Anteriormente ya hemos visto cómo desplegar un SDDC en Azure y en AWS. Vamos a ver ahora cómo desplegarlo en Google Cloud.

Vamos a ver cómo implementar una nube privada, ver la red de VPC de GCP y la configuración de red de GCVE necesaria para conectarse al entorno de GCVE y migrar una máquina virtual mediante HCX.

Lo primero de todo, necesitamos dar permisos a los usuarios de Google Cloud Platform (GCP) a GCVE (Google Cloud VMware Engine) para el servicio en sí, no para agregar administradores de vSphere. Para ello, vamos al IAM de GCP (el usuario de GCP que configura el servicio de GCVE se agregará automáticamente). Para ello, entramos en GCP, y en el menú principal, vamos a IAM:

En la ventana principal, pulsamos en Add, y en la ventana flotante que aparece, agregamos nuestra cuenta de GCP. En el cuadro de "click to select a role", bajo "proyectos" ponemos "owner", luego pinchamos en "add another role" y en la barra de búsqueda que aparece para los roles buscamos "vmw" para seleccionar "VMware Engine Service Admin". Pulsamos en "SAVE"

Con esto, ya dejamos nuestro usuario de Google con acceso al servicio.

Antes de crear nuestra nube privada GCVE, debemos asignar una cuota al proyecto para la región donde montaremos el GCVE. Así que desde el menú de navegación, pinchamos en "Quotas". Como anteriormente, en el cuadro de filtro, buscamos "vmw",


 ...y seleccionamos VMware Engine API.

Si pulsamos en "all quotas", podremos ver las cuotas asignadas.

Tras esto, ya podemos meternos en la creación de la nube privada. De nuevo, vamos el menú principal, y hacemos click en VMware Engine:

Esto lanza el portal de Google Cloud VMware Engine. En él podemos ver el numero de nubes privadas disponibles, resumen de recursos, y distintas opciones de uso habitual. Bueno, vamos a empezar a crear nuestra nube privada, y para ello clickamos en "Create a private cloud":

Ponemos el nombre de nuestra nube, marcamos nuestra localización, un rango de IPs CIDR para la subnet de vSphere y vSAN, y otro rango /27 para el HCX. Después, ya podemos pulsar en "review & create".

Tras revisar la configuración, pulsamos en "create", y si todo está ok, veremos que aparece un mensaje indicando que la nube privada será aprovisionada en modo rápido. Esto nos desplegará un vSphere con HCX y NSX-T configurados con vSan, y listo para empezar a trabajar.

Podemos echar un ojo al proceso pinchando en Resources.


Un punto interesante... en la parte inferior el cuadro, en la Danger Zone, podemos eliminar la Private Cloud, pero también podemos elevar los permisos de trabajo del admin de vSphere con permisos Full admin, por el tiempo que indiquemos.


Si pinchamos en el cuadro "Elevate" remarcado de la imagen superior, nos lleva a la pantalla de elevación de permisos, por un tiempo máximo de 24 horas:

De nuevo en Resources, si vamos a la pestaña vSphere Management Network, ademas de la IP de los distintos elementos que componen nuestra nube privada, podremos ver su FQDN. En advanced vCenter settings podremos hacer forwarding de los logs.


Necesitaremos conectar nuestro GCVE con nuestro GCP, asi que para ello, desde la consola de Google Cloud, vamos al menú, y pulsamos VPC Network:

En la pantalla principal veremos las distintas VPC de las que disponemos:

Hacemos click en la GCVE-VPC-Network, y nos movemos a la opción remarcada más abajo, private service connection, y despues a "Private connection to services":

Esto nos permitirá asignar un intervalo IP a un servicio que no estará bajo el control de la red VPC.

Pero vamos a ir de nuevo a VPC network peering, ya que necesitaremos el Peered Project ID. Pinchamos en servicenetworking-googleapis-com

Aquí seleccionamos la región, donde podremos ver las rutas que hay, pero sobre todo, nos quedamos con el Peered Project ID

Pero volvemos a la consola de Google Cloud VMware Engine, y dentro de Network, pinchamos en Private Connection. 

Pinchamos en "add private connection", y es aqui donde necesitaremos el Peered Project ID que vimos antes

GCVE permite que las cargas de trabajo y las máquinas de administración de VMware tengan acceso directo a Internet, así como que se asignen direcciones IP públicas. 

Bueno...volvemos al Home de GCVE, y desde ahí podemos lanzar el vSphere Client. Si tenemos varias nubes, nos dejará seleccionar a cual queremos entrar. En este caso, la que montamos todavia está en provisioning:

Si hacemos click en nuestra nube, veremos una pantalla muy familiar:

No voy a dar una vuelta por toda la configuración del cluster, pero como curiosidad, los hosts de Google Cloud tienen 4 NICs de 25 Gbit/s cada uno (puedes verlo en configure/physical adapters).

Si te ha gustado el articulo, puedes invitarme a un café ;)

viernes, 25 de agosto de 2023

Desplegando una nube privada de VMware en Azure, parte 3: Conectando la infra on-prem con AVS

 Ahora que hemos visto como instalar Microsoft AVS y que hemos accedido al vCenter para ver que todo esta correctamente desplegado, vamos a ver cómo configurar ExpressRoute para permitir la conectividad con los recursos de AVS desde nuestro datacenter on-prem.

Partimos suponiendo que tenemos ExpressRoute ya montado que conecta nuestra infra on-prem con Azure, y que la parte responsable de ese circuito ExpressRoute nos puede facilitar el identificador de recurso y una clave de autenticación.

Empezamos desde Azure, en nuestro recurso AVS. En el menú izquierdo pinchamos en connectivity, y en la ventana principal, en las pestañas que tenemos a nuestra disposición, pinchamos en "ExpressRoute Global Reach":

No hay muchas opciones más allá de hacer click en "Add". Eso nos abre una ventana lateral en la que indicamos nuestra suscripcion y resource group, y donde tenemos que introducir también nuestro "Circuit ID" y nuestra "Authorization key". Una vez los introducimos, pulsamos "create"

Cuando se completa la conexion, vamos a "manage / Identity" donde como ya vimos en el anterior post, podemos ver la IP de conexion a nuestro vCenter, asi como el user y pass. Asi que accedemos a nuestro vCenter, donde podemos ver nuestro cluster sin problemas y sin necesitad de  maquina de salto.

¡No tiene mas complicaciones! Ahora, ¡a trastear con ese cluster AVS!

Si te ha gustado el articulo, puedes invitarme a un café ;)

martes, 22 de agosto de 2023

Desplegando una nube privada de VMware en Azure, parte 2: Instalando Microsoft AVS

 Anteriormente, ya vimos como solicitar cuota de hosts en Azure, así como la creación del Resource Group, como preparación previa para el despliegue de Microsoft AVS (Azure VMware Solution). Vamos ahora con AVS.

En nuestro Resource Group, pulsamos sobre "Crear",

Y hacemos una búsqueda para "Azure VMware Solution".

Pulsamos sobre "create", y llegaremos a un breve wizard para el despliegue. La primera pestaña que muestra nos indica los pre-requisitos para el despliegue, consistentes en el Enterprise Agreement para la cuota de host, y una red /22 disponible.

Pulsamos sobre "Next: Basics". Seleccionamos nuestra suscripcion y Resource Group para el despliegue, y en el apartado de detalles de la Private Cloud, indicamos el nombre que le vamos a dar, la region en la que se va a desplegar, y el tamaño del host, donde lo normal es que sea un nodo AV36. Movemos el manejador para seleccionar el numero de hosts. Lo ultimo que pide es facilitar un bloque de direcciones /22 que se utilizara para la gestión del cluster. Hay que tener especial cuidado en que sea un bloque de direcciones unico y que no se solape con otras vnets o redes onprem a las que luego conectemos.

Podemos ir a la pestaña de tags, o directamente "review and create". Veremos un resumen de los "agreements" y de las opciones seleccionadas para la creacion del servicio. Asi que le damos a Create, y esperamos unas horas a que termine de desplegarse.

Ahora conectaremos el AVS Private Cloud a una Azure Virtual Network para que podamos acceder a vCenter y NSX Manager desde un jumpbox que implementaremos en esa red virtual. Crearemos una nueva red virtual de Azure y conectaremos nuestra nube privada AVS a ella con la característica Azure vNet Connect. Asignaremos espacio IP no superpuesto para esta nueva red virtual y crearemos tres subredes dentro de ella.

Así que accedemos al recurso creado, y pulsamos, en el menú izquierdo, en "connectivity"

Abrirá directamente en el panel de "Azure vnet connect". DOnde el menú desplegable de Virtual Network, pulsamos en "create new"

Esto genera una ventana para la configuración de la red virtual. Vamos a utilizar como rango una 192.168.96.0/24, y la vamos a dividir en 3 subnets /27, para gateway, otra para AzureBastion, y otra para management, tal y como puedes ver en la imagen:

Pulsamos OK, y seguidamente, Save:

Con esto, está creada la red que utilizaremos para AVS, dentro de su RG. Si entramos en el RG, veremos algo similar a esto:

A continuación, implementaremos Azure Bastion y una máquina virtual de Windows 10 para usarla como jumpbox administrativo, luego iniciaremos sesión en la máquina virtual de Windows 10 con Bastion para acceder a vCenter.

De nuevo, entramos en nuestro Resource Group, y pulsamos "create", como en la imagen superior. Buscamos "Bastion", y le damos a "create". 

En Project details indicamos la suscripción en la que nos encontramos trabajando, y el Resource Group, el que hemos creado para todo lo que estamos desplegando.

En Instance details, indicamos el nombre que le vamos a dar a Bastión, la región sobre la que se despliega, y el Tier, donde seleccionamos Basic.

En configure Virtual Network, seleccionamos la Vnet que creamos anteriormente, y la subnet que generamos para Bastión (3 imágenes más arriba).

En Public IP Address, seleccionamos "create new", y le damos un nombre reconocible, como se ve en la imagen inferior:

Pulsamos "review & create", donde vamos al resumen de la configuración deseada, y de nuevo, create.

Una vez creado, volvemos de nuevo al RG, y de nuevo, create. Esta vez buscamos "Microsoft Windows 10", seleccionamos un desktop Windows 10 u 11, y le damos a Create.

Seleccionamos la suscription y RG de este despliegue.

En instance details, damos el nombre a la máquina, en availability options no requerimos redundancia, pues será solo una maquina de salto, y en imagen, seleccionamos la más moderna que encontremos. En la captura, la que habia en este momento para Windows 10:

Introducimos username y password para la VM, y en Public inbound ports, seleccionamos "none", y hacemos click en la casilla de "confirm", justo debajo de inbound ports, y vamos a la pestaña Networking:

En Networking seleccionamos la subnet de management, en Public IP seleccionamos "none", en Network Security Group selecionamos "Basic", y en Public inbound ports, None.

Marcamos "review & create", nos sale el resumen habitual de configuración, y de nuevo, create.

Una vez desplegada la VM, nos dará la opción "go to resource". Pulsamos ahí, y nos llevará a la VM recien creada. Pulsamos en Connect, y seleccionamos Bastion, y Use Bastion:

Nos llevará a la pantalla de conexión de Bastión. Introducimos User y pass, lo que introducimos en la creación de la VM, y marcamos el "abrir en nueva ventana":

Por ahora dejamos la conexión en la nueva ventana, y volvemos a Azure. Pinchamos en Home, accedemos a nuestro AVS Private Cloud, vamos a "Identity", y ahí podremos ver nuestra dirección web de acceso:


Introducimos esta dirección en nuestro navegador, aceptamos los mensajes de seguridad, y nos cargará una ventana muy conocida:

Lanzamos el vSphere Client en HTML5. Nos cargará la pantalla de user y pass. Tenemos estos datos en la ventana "identity, que vimos 2 imágenes atrás, justo debajos de la ip de conexión. Copiamos user y pass, y accedemos al entorno. Esto nos mostrará nuestro entorno:


Si pinchamos sobre los hosts podremos ver en summary sus procesadores lógicos y demás detalles.

Si te ha gustado el articulo, puedes invitarme a un café ;)