Cerrar
InicioAzureRedes Azure: Emparejamiento de redes virtuales ubicadas en diferentes suscripciones

Redes Azure: Emparejamiento de redes virtuales ubicadas en diferentes suscripciones

Como sabréis en Azure tenemos la posibilidad de crear redes virtuales casi tan complejas (o sin “casi”)  como en On-Premises, podemos crear subredes, VPN, filtrados, control de acceso a nivel de vNet, Subred, Interface de Red, etc.. y algo muy interesante es emparejar redes virtuales. El artículo de hoy mostraré como emparejar dos vNetworks de Azure pero que están en distintas suscripciones, algo que nos viene muy bien si queremos tener tráfico privado entre dos vNetworks y así comunicar nuestros servicios de forma segura. Esto, podemos hacerlo configurando una VPN entre ambas suscripciones, pero creo que la mejor manera (o una de ellas) de conectar dos vNetworks es emparejándolas.

El concepto es fácil de entender, emparejar nos permite conectar dos vNetworks que por defecto están 100% separadas. Esto es como si tenemos dos Switchs  que cada uno tiene su configuración, equipos conectados, etc.. y en un determinado momento queremos unir ambas redes. En el caso de tener dispositivos físicos conectaremos un cable de red entre ambos switchs y tenemos conexión de capa 2, pero si además necesitamos ofrecer conectividad de capa 3 puede debemos configurar el enrutamiento necesario. En Azure el concepto es el mismo, pero “sólo” nos debemos preocupar de realizar dos configuraciones muy sencillas.

Primero voy a mostraros la infografía para este artículo, en el cual se puede apreciar que tenemos dos vNetwork cada una en sendas suscripciones de Azure y que una de ellas además tiene una conexión VPN con varias sedes que tenemos en On-Premises. Aquí os dejo un enlace un artículo que tengo sobre la conexión VPN entre Azure y nuestros entornos On-Premises: Moviendo nuestros servicios y máquinas virtuales a Azure (Parte II). Ahora si, aquí vemos la infografía comentada:

El objetivo de emparejar las redes virtuales de Azure es conectar servicios de ambas suscripciones, además, esperando una baja latencia entre redes y la posibilidad de utilizar la puerta de enlace (VPN Gatewa) de una de las redes virtuales para darle servicio a la red emparejada y poder conectar la red emparejada con nuestras sedes con los servicios de de On-Premises.

Antes de poder realizar esta configuración debemos cumplir una serie de requisitos, pero el más elemental es iniciar sesión en Azure con  cuenta con los roles necesarios para poder realizar el emparejamiento. Los roles necesarios son los siguientes (para ampliar más info: Emparejamiento de red virtual)

  • Colaborador de red: para una red virtual implementada mediante Resource Manager.
  • Colaborador de la red virtual clásica: para una red virtual implementada a través del modelo de implementación clásico.

Las redes las podemos emparejar en la misma región de Azure o en distintas, el emparejamiento en diferentes zonas se llama vNet Global.  Algo que debemos tener en cuenta es que esto también tiene coste, mínimo, pero lo tiene (ampliar más info:Coste Emparejamiento vNet)

Otra cosa muy importante que debemos conocer, el emparejamiento no es transitivo, ejemplo:

  • Red 1 y Red 2
  • Red 2 y Red 3

Esto no hace que la red 2 tenga conexión con la red 1, tenedlo en cuenta. Hay varios limites mas que debéis conocer antes de poneros a emparejar varias vNets de Azure, aquí os dejo en enlace para que las veais con calma: Requisitos y restricciones. Pues antes de iniciar este artículo, voy a detallaros algo más el escenario a documentar:

  • Tengo dos suscripciones de Azure 100% independientes
  • Mi usuarios tiene permisos delegados en la suscripción en la cual no soy propietario de forma directa
  • Las sedes de On-Premises tiene firewalls Fortinet para conectar ambas oficinas con Azure, los cuales modificaremos para poder llegar a las suscripciones de Azure vía VPN y mediante el emparejamiento

La red 172.16.0.0/16 de la infografía tiene un Gateway VPN, vamos, que esa vNet la tenemos conectada ya con las oficinas remotas vía VPN (IPSec Site-to-Site). La red 172.17.0.0/16 es la vNet que tenemos en otra suscripción la cual vamos a emparejar con la red 172.16.0.0/16 y además utilizar su Gateway para poder llegar a los servicios que tenemos en On-Premises en las diferentes redes (192.168.0.0/24 y 192.168.1.0/24). Pues dicho esto, vamos ya directos a realizar el emparejamiento. Para realizar el emparejamiento de vNets de diferentes suscripciones, vamos a necesitar el ID de recurso de cada red a emparejar, por lo que, nos vamos a la red de Azure de cada suscripción, a la sección propiedades copiamos el Id. de recursos que nos es más que la URL del recurso. Esto debemos hacerlo por cada vNet de cada suscripciones. 

Una vez que ya tenemos el Id del recurso de cada red virtual de cada suscripción, vamos a irnos a cada red virtual a la sección de emparejamiento y pulsamos en Agregar:

Ahora tenemos que cubrir las siguientes opciones disponibles:

  • Nombre del emparejamiento: escribiremos un nombre descriptivo que nos permita identificar la red emparejada
  • Modelo de implementación: en mi caso elijo Resource Manager

Voy a marcar la casilla de Conozco mi id. de recurso (recordad que hemos copiado el Id de recurso de cada red virtual de cada suscripción), una vez que la hemos marcado, debemos pegar la URL del id. del recurso de la red que queremos emparejar con la red virtual de la suscripción en la cual nos encontramos. Una vez que hayamos pegado el ID del recurso, nos mostrará los directorios que tenga conectados dicha suscripción, seleccionamos la que corresponda y pulsamos en Autenticar. Si ya tenemos permisos sobre dicho recurso de la otra suscripción el proceso será automático, no tendremos que logarnos nuevamente en ningún caso:

Debemos dejar habilitada la opción Configuración del acceso a red virtual, esto nos permite la comunicación entre ambas redes. Si tenemos un Gateway VPN (subred 172.16.0.0/16 de la infografía) para conectarnos vía VPN desde On-Premises (u otras redes) y queremos que la red virtual que emparejemos (subred 172.17.0.0/16 de la infografía) la pueda utilizar, debemos habilitarlo, en mi caso lo habilitaré porque quiero que desde la red emparejada (subred 172.17.0.0/16 de la infografía) se pueda conectar con los recursos locales utilizando el Gateway VPN de esta red (subred 172.16.0.0/16 de la infografía). La opción Configuración de puertas de enlace remotas no la configuraré en este paso, puesto que la red a emparejar no tiene Gateway VPN (esto si lo haremos al contrario).

Una vez que hemos cubierto todas las opciones, pulsamos en Aceptar para completar la mitad del proceso:

Esperamos unos segundos  y veremos que ya tenemos la red emparejada, la red vNet-NorthEurope-00 es la red “remota” (subred 172.17.0.0/16 de la infografía) que acabamos de emparejar.

Como yo tengo acceso a la otra suscripción con mi cuenta, desde el mismo portal de Azure lo único que haré será conectarme al otro directorio con la otra suscripción en donde tenemos la otra vNet (subred 172.17.0.0/16 de la infografía) para configurar el emparejamiento:

Pues nos vamos directamente a la vNet, sección de emparejamiento y pulsamos en Agregar:

Volvemos a cubrir todos los datos como antes, pero ahora con los datos de la otra vNet (subred 172.16.0.0/16 de la infografía) de la otra suscripción, pero ahora si habilitamos la opción Configuración de puertas de enlace remotas, porque así haremos que esta vNet (subred 172.17.0.0/16 de la infografía) pueda llegar a los servicios de las redes conectadas por VPN desde la vNet (subred 172.16.0.0/16 de la infografía) a emparejar y pulsamos en Aceptar:

En cuestión de segundos ya tendremos ambas vNet emparejadas

Si ahora volvemos a la suscripción donde hemos realizado el emparejamiento inicial, vemos que ya está conectado

Mientras estaba configurando el emparejamiento de las diferentes vNets tenía una línea de comandos con un ping permanente a un host de otra vNet y mirad como cuando se ha terminado el emparejamiento se ha conectado sin problema y con una latencia de <1ms!!

Con esto ya tenemos emparejadas ambas vNets, pero para completar el proceso al 100% ahora tenemos que adaptar la configuración de VPN de los firewalls Fortinet que tengo conectando vía IPSec con el Gateway de Azure de la vNet 172.16.0.0/16 de la infografía. Lo que tenemos que hacer para poder llegar a la subred 172.17.0.0/16 de la red vNet emparejada es lo siguiente:

  1. Editamos la configuración VPN con Azure

2. Editamos la Fase 2 y añadimos

3. Configuramos la Fase 2  con los parámetros de Proposal esperados por Azure y definimos las subredes locales que gestiona cada firewall (192.168.0.0/24 y 192.168.1.0/24 respectivamente) y en Remote Address debemos añadir la subred IP de la red que hemos emparejado (172.17.0.0/16)  y a la cual queremos tener acceso desde las sedes de On-Premises vía VPN atravesando la vNet donde tenemos la subred IP 172.16.0.0/16:

Y como antes, tenía un ping permanente hacia una subred IP de la vNet emparejada (172.17.0.0/16) y como vemos en cuanto pasan unos segundos ya tenemos tráfico!!

Si quereis ver la tabla de enrutamiento de una interface de red de algún servidor que tengáis en Azure, podéis hacerlo desde la opción de Rutas eficaces  y veréis la “tabla de enrutamiento” que hará que se pueda comunicar con la vNet y porque Gateway se llega a cada subred:

Como habéis podido apreciar es muy sencillo, potente y rápido de configurar. Además, en mi caso he añadido la “complejidad” de hacerlo entre vNets de diferentes suscripciones y que las conexiones VPN de sedes locales con Azure puedan ser utilizadas también para llegar hasta y desde la vNet emparejada.

En próximos artículos sobre Azure iré mostrando diferentes topologías que se pueden implementar en Azure, donde los emparejamientos serán nuestros grandes aliados.

Ahora .. os toca probarlo a vosotros!!!

Microsoft Teams, con
Redes Azure: Emparej
NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This