Redes Azure: Emparejamiento de redes virtuales globales

Hace una semana había publicado un artículo sobre como podemos emparejar redes virtuales (en adelante vNets) ubicadas en diferentes suscripciones, para los que no lo habéis podido leer aquí os dejo el enlace: Redes Azure: Emparejamiento de redes virtuales ubicadas en diferentes suscripciones. Hoy me gustaría profundizar algo más al respecto y, cómo os había comentado el otro día dos tipos de emparejamientos:

• Emparejamiento de redes virtuales: conexión de redes virtuales dentro de la misma región de Azure
• Emparejamiento de redes virtuales globales: conexión de redes virtuales por regiones de Azure

En el articulo anterior citado al inicio del artículo habíamos visto como emparejar vNets de diferentes suscripciones pero de la misma región (Emparejamiento de redes virtuales), por lo que hoy empezaré una serie de artículos sobre emparejamientos de vNets en diferentes regiones (Emparejamiento de redes virtuales globales). “Básicamente” esto nos permitirá construir una “red virtual” utilizando Azure y diferentes regiones en el mundo, lo que nos permitirá ubicar diferentes servicios para nuestra compañía lo más “cerca” de los usuarios. Si tenemos cientos de usuarios en USA y tenemos nuestros servicios en alguna región de Azure en Europa claramente tendremos un problema de latencia muy importante, por lo que, la experiencia de usuarios se verá penalizada. Lo que trataremos es ubicar los servicios para los  de USA en alguna región  de USA donde Azure tenga presencia, de esta forma, podemos conectar a los usuarios a dichos servicios sin que para ello tengamos que crear estructuras diferentes (ejemplo: Directorio Activo replicado entre diferentes controladores de dominio ubicados en diferentes regiones).

Os dejo aquí un enlace donde Microsoft (en adelante MSFT) nos muestra las regiones de Azure donde tiene presencia: Regiones de Azure, la “foto” a día de hoy es la siguiente: 54 Regiones en todo el mundo y disponibles en 140 países

Como siempre,  primero os muestro la infografía de la topología a comentar en este artículo:

Lo primero comentaros los recursos que tengo creados en Azure para gestionar esta topología:

Redes Virtuales: es una topología Hub-Spoke, pensada en que las conexiones locales (On-Premises) y emparejamientos entre vNets se realice mediante las vNet definidas como Hubs. Las vNets utilizadas para Spoke serán utilizadas para implementar nuestros servicios y cargas de trabajo:

Nombre	Región	Direcciones	Notas
vNet-NorthEurope-Hub	Norte de Europa	172.16.0.0/16	El hub es una red virtual (VNet) en Azure que actúa como un punto central de conectividad para la red local
vNet-NorthEurope-Spoke00	Norte de Europa	172.17.0.0/16	Los spoke son redes virtuales (VNet) que se emparejan con el hub y que se pueden usar para aislar cargas de trabajo
vNet-WestEurope-Spoke00	Este de Europa	172.18.0.0/16	Los spoke son redes virtuales (VNet) que se emparejan con el hub y que se pueden usar para aislar cargas de trabajo
vNet-EastUS-Hub	Este de EE. UU.	172.20.0.0/16	El hub es una red virtual (VNet) en Azure que actúa como un punto central de conectividad para la red local
vNet-SouthCentralUS-Spoke00	Centro y Sur de EE. UU.	172.21.0.0/16	Los spoke son redes virtuales (VNet) que se emparejan con el hub y que se pueden usar para aislar cargas de trabajo
vNet-NorthCentralUS-Spoke00	Centro y Norte de EE. UU.	172.22.0.0/16	Los spoke son redes virtuales (VNet) que se emparejan con el hub y que se pueden usar para aislar cargas de trabajo

Servidores: hay un controlador de dominio por cada vNet y lo mismo con los servidores Web, pero en subredes IP diferentes aislando las cargas de trabajo entre ambos servicios.

Nombre	Región	vNet	Subred	Subred IP	Notas
SRV-DC00	Norte de Europa	vNet-NorthEurope-Spoke00	Identity	172.17.2.0/24	Controlador de dominio
SRV-DC01	Este de Europa	vNet-WestEurope-Spoke00	Identity	172.18.2.0/24	Controlador de dominio
SRV-DC02	Centro y Norte de EE. UU.	vNet-NorthCentralUS-Spoke00	Identity	172.22.2.0/24	Controlador de dominio
SRV-DC03	Centro y Sur de EE. UU.	vNet-SouthCentralUS-Spoke00	Identity	172.21.2.0/24	Controlador de dominio
SRV-IIS00	Norte de Europa	vNet-NorthEurope-Spoke00	Web	172.17.3.0/24	Servidor Web
SRV-IIS01	Este de Europa	vNet-WestEurope-Spoke00	Web	172.18.3.0/24	Servidor Web
SRV-IIS02	Centro y Norte de EE. UU.	vNet-NorthCentralUS-Spoke00	Web	172.22.3.0/24	Servidor Web
SRV-IIS03	Centro y Sur de EE. UU.	vNet-SouthCentralUS-Spoke00	Web	172.21.3.0/24	Servidor Web

Aplicaciones de Red Virtual (NVA): serán servidores que tendrán el reenvío habilitado con dos funciones principales:

1. Enrutamiento: el enrutamiento entre las vNets de Spokes  emparejadas con cada vNet de Hub, evitando así conectar los Spokes como emparejamientos (atiendo a no superar los límites por región) y a poder filtrar la comunicaciones entre los Spokes
2. Salida a Internet: los equipos de las vNet saldrán a Internet (ruta por defecto 0.0.0.0/0.0.0.0) mediante los NVA (pero no en este artículo)

Los NVA se colocarán en la subred 1 de cada Hub, estarán en la subred IP 172.x.2.0/24, además las UDR (User-Defined Routes) se aplicarán a cada subred de cada Spoke

En cada vNet de Hub tendremos una subred para el Gateway que permitirá conectar la vNet con la red local más cercan a la región donde tenemos la vNet.

Ahora que ya tenemos claro los componentes de esta topología, vamos con los objetivos:

1. Emparejar las vNet definidas como Hub con las vNet definidas como Spokes (en diferentes regiones)
2. Conectar las vNets de Spokes entre si (vía enrutamiento mediante NVA)
3. Emparejar las vNets de Hubs (en diferentes regiones)
4. Conectar las vNets de Spokes de diferentes regiones utilizando la vNet de Hub
5. Conectar todas las vNet (Hubs y Spokes) con las redes On-Premises utilizando para ello el servicio de VPN con acceso mediante el emparejamiento.

En próximos artículos seguiré utilizando esta topología para ir implementando más servicios, configuraciones, etc.. pero con esto daríamos por iniciado una configuración de conexión global de nuestra red corporativa. Comentaros que esta es una de las múltiples configuraciones que podemos tener, pero también es muy común/normal poner en las vNet de los Hubs servicios comunes:

• Servidores DNS
• Controladores de Dominio
• IDS
• Etc..

En este caso, vamos  configurar en cada subred de cada vNet de los Spokes los servicios, aislando entre si los servicios no análogos. Comentaros que este artículo no dará alcance a la configuración del servicio de VPN, lo que haré será dejaros un artículo que tengo al respecto: Moviendo nuestros servicios y máquinas virtuales a Azure (Parte II). En ese artículo comento paso a paso como configurar una VPN entre Azure y un Firewall Fortinet, algo que también ya tendré pre-configurado para este artículo antes de iniciar el proceso de emparejamientos de las redes. Para este artículo, la VPN la tengo configurado únicamente en la vNet del Norte de Europa y será la que utilizaremos para que todas las redes puedan llegar a los servicios On-Premises.

Pues vamos a ello, lo primero, aquí tenemos todas vNet que tengo creadas, con sus subredes y ubicaciones para que todos los tengamos más claro.

Lo primero que haré será emparejar las vNet de los Hub con cada Spoke (según la topología mostrada en la infografía), para ello nos vamos a la vNet del Hub, sección de Emparejamientos y pulsamos en Agregar:

Este proyecto es muy sencillo:

• Escribimos un nombre para el emparejamiento
• Elegimos la vNet con la que no vamos a emparejar
• Escribimos el nombre con el que veremos identificado el emparejamiento desde la vNet emparejada
• Dejamos habilitadas las opciones de acceso de red virtual en ambos sentidos
• Habilitamos la casilla de Permitir tránsito de puerta de enlace, esto permitirá a la vNet emparejada conectarse con los servicios de On-Premises utilizando el Gateway de la red con la que se está emparejando (en nuestro caso con el Hub)

Una vez que hayamos realizado todas las configuraciones, pulsamos en Aceptar:

Si esperamos unos segundos veremos que el emparejamiento se ha completado sin problema, ya está conectado y habilito el tránsito de puerta de enlace para la vNet emparejada

Si ahora nos vemos al Spoke que hemos emparejado con el Hub y nos vamos a la sección de emparejamiento veremos que está conectado (si hubiese algún problema o proceso por terminar ya lo veríamos desde el Hub) :

Pues este mismo proceso debemos hacerlo desde el Hub (no es obligatorio desde el Hub) con todos los Spokes, esta sería la configuración con la otra vNet de Spoke que tenemos en Europa. En este caso seguimos habilitando el tránsito de puerta de enlace:

Y una vez completado, podemos observar que ya tenemos ambos emparejamientos completados!!

Y si lo vemos desde el punto de vista del último Spoke emparejado vemos que ya tenemos el estado a Conectado con el Hub, por lo que, proceso finalizado, ahora mismo tendríamos conexión entre cada Spoke con el Hub y con los servicios de On-Premises

Ahora debemos realizar en las otras vNet donde tenemos otro Hub y dos vNet de Spoke, pero ahí no tenemos Gateway, por lo que la única diferencia es que no tenemos que habilitar la casilla de Permitir el tránsito de puerta de enlace,  por el resto es todo igual. Una vez completado el proceso, ya podemos ver desde el Hub los emparejamientos de ambas redes:

Con esto ya tenemos emparejados los Hubs con sus respectivos Spokes, ahora vamos a iniciar las máquinas virtuales que tenemos en las vNet de Europa y ver que tenemos tráfico con los servicios de On-Premises. Recordad que aún no hemos habilitado el emparejamiento entre los Hubs ni tampoco entre los Spokes mediante NVA (Aplicaciones de Red Virtual). Entiendo que este proceso no tiene que mostrarse, pero bueno, aquí tenéis el inventario de activos que tengo para este artículo, simplemente selecciono las que tengo en Europa y pulso en el botón de comando de Inicio:

Ahora vemos las direcciones IP que tienen los servidores, para ello, pulsamos encima de los servidores a los cuales nos queremos conectar, vamos a la sección de red y ahí tenemos la IP que tiene cada servidor:

La conexión será la siguiente, aquí os dejo el flujo de tráfico que seguiría:

Si lanzamos una conexión RDP veremos que podemos conectarnos sin problema:

Si ahora desde este servidor al cual nos hemos conectado vía VPN utilizando RDP tratamos de conectarnos a otro servidor de otra vNet, veremos que es imposible (de momento). Olvidaros del PING (ICMP) porque esto por defecto Windows lo tiene filtrado por defecto, pero el RDP en máquinas virtuales de Azure no, sino sería imposible conectarnos a ellas.

De momento hemos conseguido tener tráfico hacia y desde las máquinas virtuales conectadas en las vNets de los Spokes pasando por el Hub correspondiente y llegando mediante la Gateway VPN configurado en la vNet del Hub. Ahora, antes de empezar con el tráfico entre Spokes mediante un NVA, vamos a conectar los Hubs y sin tocar nada, veamos si tenemos o no tráfico. En este emparejamiento si que habilitaremos la casilla de Permitir tránsito de puerta de enlace, porque queremos que la red emparejada (vNet-EastUS-Hub) pueda llegar a On-Premises vía la red desde la cual estamos realizando el emparejamiento (vNet-NorthEurope-Hub). Como veis en la captura, una vez que configuramos el emparejamiento lanza el proceso en ambas vNets:

Completado el proceso desde la sección de emparejamiento de cada Hube veremos que tenemos el estado de emparejamiento a Conectado (si todo ha ido bien claro):

¿Creéis que ahora deberíamos tener tráfico entre las vNets y On-Premises? Pues … la respuesta es NO, puesto que de momento no hemos habilitado algunas configuraciones que se necesitan para que pueda existir dicho enrutamiento. Antes de seguir con la configuración, si nos vamos a revisar las Rutas eficaces de la tarjeta de red de alguno de los servidores a los que queremos conectarnos veremos que aún no tenemos ruta para ello.

Recordad, quiero conectarme desde On-Premises hacia una vNet de Spoke de un emparejamiento entre Hubs, pero mejor os lo muestro:

Para poder tener tráfico desde las subredes ubicadas en nuestro caso en Estados Unidos, debemos realizar varias configuraciones:

• Habilitar el reenvío de tráfico en la red emparejada (su Hub): nos permite enviar tráfico de una vNet a otra
• Crear y configurar una aplicación de red virtual: es una máquina virtual que hará de enrutador (por ser simplista)
• Crear rutas definidas por el usuario (UDR): aplicada a cada vNet lo que nos permitirá definir por donde enviaremos el tráfico para llegar a otras subredes

Habilitar el reenvío debemos hacerlo en el emparejamiento de las vNets, editamos cada emparejamiento y habilitamos la opción de Configuración de tráfico reenviado:

Ahora debemos crear nuestro NVA, vamos, nuestro Firewall el cual nos permitirá enrutar el tráfico entre diferentes redes, algo que necesitaremos para conectar las vNets de Spokes entre si y con los servicios de On-Premises. Hay una infinidad de dispositivos de red en Azure, yo voy escoger el Firewall de Azure directamente, pero cada uno puede elegir el NVA que considere oportuno.  Antes de nada, cuando creemos nuestro Firewall nos solicitará una subred o que la creemos, pero si la tenemos creada se tiene que llamar AzureFirewallSubnet, por lo que ya la tengo creada previamente:

Ahora toca al Marketplace y buscar nuestro Firewall, insisto, yo escogeré el de MSFT, pero cada uno puede elegir el que mejor considere:

Pulsamos en Crear

Cubrimos los campos que nos solicitad, aquí es donde elegimos la vNet que ya tengamos creada, en mi caso recordad que será la vNets del Hub de EE.UU. y pulsamos en crear una IP Pública para el Firewall (sino la tenemos creada previamente):

Una vez hayamos completado todos campos, pulsamos en  Revisar y Crear

En el resumen de la configuración nos aseguramos de que está todo según lo hemos configurado, si es así, pulsamos en Crear:

Este proceso tardará unos 10 minutos en crearse, no tengáis prisa:

Una vez se haya completado el proceso, debemos ir a su configuración:

Una vez que accedemos al Firewall lo que veremos será la dirección IP Privada, la cual vamos a necesitar para definir las rutas personalizadas que debemos crear para la comunicación entre Spokes:

Lo primero y único que haremos será crear una regla básica de red, en la cual vamos a permitir las comunicaciones salientes desde las vNet de Spokes de EE.UU hacia cualquier red, luego iremos afinando más estas reglas:

El asistente es muy sencillo, una vez finalizadas las reglas pulsamos en Agregar

Y ya tenemos las reglas aplicadas

Ahora toca definir las rutas para poder llegar entre vNets de Spokes, debemos crear tantas tablas de rutas como vNets tengamos. En el Marketplace buscamos por Tablas de rutas y la seleccionamos:

Pulsamos en Crear:

Yo voy a crear dos tablas de rutas inicialmente, una por cada vNet de Spoke que tengo en las regiones de EE.UU.

Accedemos a cada tabla de rutas, vamos a la sección de Rutas y pulsamos en Agregar:

Escribimos un nombre para dicha ruta, la subred a la que queremos llegar, el tipo de próximo salto elegimos Dispositivo virtual y la IP privada del Firewall

Y listo, ya tenemos la rutas definidas para llegar a las diferentes subredes de  las otras vNets

Por último debemos asociar esta tabla de rutas a cada subred de cada vNet, para ello desde la sección Subredes  pulsamos en Asociar

Ahora elegimos la vNet

Y subred

Ahora pulsamos en Aceptar

Tenemos que hacerlo en todas las subredes que queramos tener tráfico entre ellas

Si ahora desde cualquier servidor comprobamos en la tarjeta de red las rutas eficaces .. ahí la tenemos!!

Ahora si que sí, desde cualquier servidor de alguna de la vNets de EE.UU vamos a probar a conectarnos a otro servidor y .. conectados! El servidor al que estamos conectado  por RDP tiene la IP 172.20.2.0/24 y al que nos contectamos vía SMB y RDP está en la subred 172.21.3.0/24:

La latencia es importante, variará entre diferentes zonas, pero bueno, por lo menos es muy estable y te “garantiza” tener un servicio decente, sin cortes y todo tráfico privado.

El artículo al final me ha quedado enorme, lo siento!! Para el siguiente será más cortito, únicamente conectar la redes Hub entre si y la sede On-Premises!!

Espero que os ayude/anime a utilizar Azure!!