Conectando Microsoft Azure con Amazon Web Services

Tal y como os prometimos, después del Global Azure BOOTCAMP 2015 de Madrid, vamos a dedicar un artículo del blog a explicar cómo Alberto Marcos y servidor –Carlos Milán– llegamos a crear un escenario híbrido entre Amazon Web Services (de ahora en adelante AWS) y Microsoft Azure. Si te perdiste nuestra charla, ¡obligatorio que leas este post!

¿Qué vamos a hacer?

La idea es bastante simple: vamos a enlazar una VPC (Virtual Private Cloud) de AWS con una red virtual de Azure mediante un tunel site to site IPsec. La idea es que ambas redes queden interconectadas en un entorno LAN y podamos desplegar máquinas virtuales que disfruten de visibilidad a nivel de red local de ambos entornos.

Gracias a esta visibilidad, podemos, entre otras cosas:

• Facilitar enormemente las migraciones de sistemas una plataforma a otra.
• Crear un escenario de alta disponibilidad donde esta esté garantizada por más de un proveedor de cloud.
• Crear una infraestructura única que aproveche capacidades especiales de un proveedor que no están disponibles en otro. Por ejemplo: AWS dispone de máquinas virtuales con GPU, mientras que Azure dispone del mejor escalado vertical del mercado con las máquinas de tipo G.
• Etc…

Definiendo conceptos

Como sabréis los visitantes de nuestro blog, no somos ni mucho menos expertos en Amazon, pero desde luego que somos expertos en Azure; así que aventurarnos en este escenario nos obligó a estudiar un poco la plataforma. Y es que AWS y Azure no son tan distintos como a primera vista pueden parecer, sino que utilizan distinta nomeclatura para elementos que son bastante análogos entre sí. Aquí hay una lista de analogías:

Implementando el escenario

Vamos a comenzar con la serie de pasos que seguimos para implementar el escenario donde, como podréis imaginar, hay que realizar una serie de tareas tanto en AWS como en Azure. En el artículo daremos por sentado que tenemos tanto nuestra suscripción de AWS como la de Azure listas para usar.

Direccionamiento IP

Lo primero era elegir un direccionamiento IP para trabajar con ambas redes, que pensamos que podía ser el siguiente:

Es muy recomendable crear ambos entornos en una localización geográfica cercana. ¡Una vez tomada la decisión, ya podíamos comenzar a trabajar!

AWS – Creando la VPC

Deberemos crear una nueva VPC en AWS:

1. Seleccionamos VPC with a Single Public Subnet.
   
2. Configuramos las opciones:
   • Establecemos su direccionamiento de acuerdo a lo planeado: 10.0.0.0/16
   • Le damos un nombre cualquiera.
   • Establecemos una subnet pública de 10.0.0.0/24.
   • Resto de opciones por defecto.
     

¡Ya tenemos red! ¡Ahora a por la pasarela!

AWS – Creando la VM gateway

AWS dispone de un servicio de gateway SaaS, pero como este no cumple con las especificaciones necesarias para conectarse con Azure, vamos a crear nuestra propia máquina virtual que actuará como gateway a Azure de nuestra red.

1. En el servicio de EC2 vamos a seleccionar una AMI (Amazon Machine Image) Windows Server 2012 R2 Base.
   
2. Una instancia de tipo t2.micro es más que suficiente para nuestro laboratorio.
3. Seleccionamos que pertenezca a la VPC que hemos creado en la tarea anterior y dejamos el resto de opciones por defecto. Opcionalmente podemos especificar una IP interna o si no asignará una por DHCP estático.
4. En la parte de almacenamiento, servirá bien el disco SSD de 30 GB por defecto. Tras la instalación de Windows Server 2012 R2 sólo nos quedarán unos 6 GB libres de espacio en disco, pero serán suficientes para nuestro propósito.
5. Daremos un nombre a la máquina, nosotros la llamamos GATEWAY.
6. Creamos un nuevo Security Group para ella. Los Security Groups son reglas de firewall que nosotros establecemos para regular el tráfico en las instancias de Amazon EC2; son equivalentes a los Endpoints y Security ACLs de Azure. Para la máquina de gateway en Amazon deberemos crear uno nuevo con las siguientes reglas:
   
   Las reglas que corresponden a los puertos UDP 4500 y 500 son las del tráfico IPsec y verás que sólo las permitimos en una IP concreta. Esta IP es la de gateway de Azure, que en este punto todavía no tenemos establecido y por tanto no conocemos. Ignóralas de momento y volveremos más tarde a añadirlas.
7. Creamos la máquina vritual.

AWS – Elastic IPs

Si vamos a crear un gateway IPsec en una máquina virtual, no querremos que su IP pública cambie o nos inutilizará el escenario. Por ello debemos reservar una que mantenga siempre.

1. Desde EC2 Dashboard seleccionamos Elastic IPs.
2. Seleccionamos Allocate New Address.
3. Le indicamos que queremos asociar la IP a una instancia de máquina virtual.
4. Seleccionamos la máquina GATEWAY que creamos en el proceso anterior.

Con estos sencillos pasos nuestra máquina ya tiene su IP pública fija, ¡anótala! Te hará falta en el siguiente paso, ¡nos vamos a Azure!

AZURE – Creando la red virtual

Vamos a proceder a crear una red virtual nueva:

Las opciones a configurar serán:

• Queremos conecitividad site-to-site VPN.
• Especificaremos una nueva red local.
• Como red local definiremos el direccionamiento que hemos elegido para AWS: 10.0.0.0/16
• La IP del dispositivo VPN: debe ser la Elastic IP que reservaste en la tarea anterior desde AWS.

La configuración de la red de AWS en Azure podría quedar así:

Mientras que la de Azure, en el último paso del asistente, quedaría así:

¡No olvides crear una subnet para el gateway! La necesitarás para lo que viene justo ahora.

AZURE – Creando el gateway

Entra en la red virtual que acabas de crear y selecciona Create gateway y Dynamic routing.

Cuando esté creado podremos ver la IP asignada desde el dashboard de la red virtual:

Y además haremos clic en Download VPN Device Script para descargar la configuración que ejecutaremos en la máquina Windows Server 2012 R2:

¡Es hora de volver a AWS!

AWS – Editando Security Group

¿Recuerda el Security Group que creamos para la máquina gateway en AWS? Como ya sabemos la IP del de Azure es hora de que lo agreguemos a las reglas. Recuerda:

Agregamos dos nuevas Custom UDP Rule a los puertos 4500 y 500 para permitir que el tráfico IPsec fluya desde el gateway de Azure.

AWS – Configurando RRAS en el gateway Windows Server 2012 R2

En este paso no voy a entrar en mucho detalle puesto que es análogo a lo que Antonio López Márquez ya nos explicó en este otro artículo. En realidad no tenemos más que llevar a la máquina Gateway el script de PowerShell que hemos descargado del portal de Azure y ejecutarlo. Este script agregará automáticamente el rol de RRAS al servidor y configurará la conexión con el gateway de Azure.

AWS – Desactivando Source/Destination Check

El Source/Destination Check de son una serie de verificaciones que los adaptadores de red virtuales de EC2 realizan para comprobar si el tráfico que una interfaz de red recibe está verdaderamente destinado a la misma. Como resulta obvio, esto puede resultar nefasto en una máquina de gateway que hace de pasarela para el tráfico destinado a otras máquinas, por lo que debemos desactivar estas comprobaciones.

1. Desde el dashboard de EC2 seleccionamos Network Interfaces.
2. Seleccionamos el interface de red de nuestra máquina gateway.
3. En Action podremos seleccionar Change Source/Dest. Check, que cambiaremos a Disabled.

Llegados este punto, el tunel entre AWS y Azure debería estar establecido y así tendríamos que poder verlo en el dashboard de Azure. Desde AWS no tenemos un vistazo tan gráfico y deberemos entrar en la máquina Gateway para comprobar su estado. Debería lucir tal que así:

Pero esto no será suficiente para que el tráfico fluya entre las máquinas de ambas redes. Necesitaremos modificar la tabla de rutas de la red de AWS para conseguirlo.

AWS – Creando una nueva tabla de rutas para la subred

Crear y modificar tablas de rutas en AWS es bastante trivial:

1. Nos dirigiremos al dashboard de EC2 y acto seguido a Route Tables.
2. Clic en Create Route Table. Ten en cuenta que otra posibilidad es editar la tabla de rutas principal de la VPC que creamos anteriormente. Haz este paso a tu gusto.
3. Le ponemos un nombre y la adjuntamos a la red que hemos creado.
4. Posteriormente deberemos asociar la tabla de rutas a la subnet pública que creamos también en pasos anteriores.

Y finalmente deberemos editar dicha tabla para agregar la ruta a Azure a través del gateway. Esto quedaría así:

Como podéis ver la ruta a Azure se asocia directamente a la interfaz de red que se encuentra en la máquina de gateway.

Probando el escenario

¡Y esos eran todos los pasos! Ya estamos preparados para probar el escenario que hemos explicado. Para ello vamos a desplegar un par de máquinas virtuales, una en AWS y otra en Azure, donde probaremos si tienen conectividad entre ellas. El sistema operativo es irrelevante en este caso. En nuestro lab hemos puesto una máquina adicional Windows Server 2012 R2 en AWS y una máquina con Ubuntu GNU/Linux en Azure. El esquema sería el siguiente:

El resultado se pudo ver en directo en la presentación, hicimos ping de forma satisfactoria de la máquina AWS a la máquina Azure y viceversa, con lo que teníamos un canal de comunicaciones seguro y establecido entre ambos datacenters.

Por supuesto, nuestra demo no se limitó a enseñar un ping entre máquinas, sino que realizamos algunas pruebas más, algunas de ellas muy vistosas que nos reservamos para otro artículo. Espero que este artículo os haya resultado interesante y os anime a explorar las posibilidades de interoperabilidad y conexión de Azure, ¡incluso con su plataforma rival!

Os dejamos con algunas fotos de la charla del Bootcamp donde podéis ver a Alberto y servidor en acción 🙂

Happy networking!

Enlace relacionado: Connecting Clouds – Creating a site-to-site Network with Amazon Web Services and Windows Azure