Interconexión entre VNets

Publicada el por

En un post anterior definimos una VNet como una división lógica de redes dentro de nuestro tenant. Las máquinas que están en una misma VNet pueden comunicarse entre ellas, incluso si están en diferentes subnets, porque ya hemos visto en el post de enrutamiento que Azure crea rutas por defecto que lo permiten. Sin embargo, a no ser que lo configuremos de forma explícita, máquinas virtuales que están en diferentes VNets no podrán comunicarse entre sí. En este caso vamos a ver las opciones que tenemos para configurar esta conexión entre VNets.

Para la conexión entre VNets tenemos 2 métodos principales:

  • Conexión VPN: Este es el método más complejo y tenemos que crear VPN Gateways en cada red para luego configurar los túneles IPSec/IKE entre las VNets. Es lo que conocemos como VPN Site-to-Site y también podríamos usar este método para conectar una VNet con una red on-premises, por ejemplo. Al ser más complejo, dedicaremos un post para hablar de este tipo de conexiones un poco más adelante.
  • VNet Peering: Es el método más sencillo y no requiere la configuración de VPN Gateways. Sólo es posible usar este método para conectar entre sí VNets de Azure y no para la conexión con una red on-premises. Vamos a centrarnos en VNet Peering y veremos un ejemplo de configuración.

VNet Peering

Vamos a partir de una situación en la que tenemos 2 máquinas virtuales que se encuentran en VNets diferentes, aunque en la misma región (este de EEUU):


Al estar en VNets diferentes, no hay conectividad por defecto entre estas máquinas:

Hay que tener en cuenta que en la máquina virtual VM2 (10.0.1.4) deberíamos crear una regla entrante en el Firewall que permita el tráfico ICMP (ping), de lo contrario, incluso si creamos el VNet Peering como veremos en este post, no recibiremos respuesta a nuestras peticiones de ping.

Si comprobamos las rutas efectivas que se están aplicando a la tarjeta de red de VM1:

Sólo están creadas las rutas por defecto que vimos en el post de enrutamiento.

Para permitir la conectividad entre las dos VNets, vamos a configurar VNet Peering entre las dos:Vamos a “Redes Virtuales”:

  1. Vamos a “Redes Virtuales”:

2. Y en cualquiera de las VNets por ejemplo, en RG1-vnet, vamos a “Emparejamientos”:

3. Y pulsamos en “Agregar” para crear un VNet Peering con la red RG2-vnet:

4. Y sólo tenemos que dar un nombre el emparejamiento y seleccionar la red de destino. Vemos que por defecto está habilitado el acceso a la red virtual:

5. Y repetimos el proceso en sentido inverso:

Una vez creados los emparejamientos ya podemos comprobar la conectividad que antes no era posible (recordar que el firewall de VM2 podría bloquear las peticiones de ping):

Si comprobamos las rutas efectivas que se están aplicando a las interfaces de red de las máquinas, por ejemplo la de VM1:

Vemos que Azure ha creado una ruta a la red 10.0.1.0/24 con tipo de próximo salto “Emparejamiento de VNet”. Esta es la ruta que permite conectividad entre las dos redes.

En este caso hemos configurado el denominado Regional VNet Peering, que permite la conexión entre VNets que están en la misma región. También podemos configurar Global VNet Peering, que permite la conectividad entre VNets que se encuentran en regiones diferentes.

Supongamos el siguiente escenario en el que tenemos 2 máquinas virtuales en redes diferentes y en regiones diferentes (este de EEUU y centro de EEUU):

Los rangos de direcciones IP son los mismos que en el primer escenario, pero ahora tenemos las máquinas virtuales y las redes a las que están conectadas en diferentes regiones de Azure.

El proceso de configuración de VNet Peering es igual que en el escenario anterior:

  1. Empezamos con cualquiera de las VNets, por ejemplo RG1-vnet, y en “Emparejamientos” pulsamos en “Agregar”:

2. Vemos que, aunque la red RG2-vnet está en otra región, podemos seleccionarla para el emparejamiento:

3. Y configuramos también el emparejamiento en sentido inverso:

Una vez configurado, ya tenemos conectividad entre VM1 y VM2 aunque estén en regiones diferentes (recordar que el firewall puede bloquear las peticiones de ping):

Si revisamos las rutas efectivas que se están aplicando a las interfaces de red, por ejemplo a la de VM1:

Vemos que Azure ha creado una ruta con destino 10.0.1.0/24 cuyo tipo de próximo salto es VNetGlobalPeering. Esta es la ruta que nos permite alcanzar una región diferente a la de origen.