Túneles Site-2-Site en Azure con Windows Server 2012

Hola a todos,

Hoy nos toca hablar de un tema que afecta a toda empresa que quiera integrar su infraestructura local con su infraestructura en Azure. Por supuesto, me refiero a los túneles S2S. Aunque ya hemos hablado de ellos, en este post vamos a detallar cómo hacer la configuración en el caso de usar una máquina Windows Server 2012.

A modo de resumen, un túnel Site-to-Site (S2S para los amigos), nos permite extender nuestra red local hasta Azure, de forma que las máquinas virtuales allí hospedadas puedan acceder a nuestros recursos locales y viceversa, todo de forma transparente al usuario.

Diagrama básico de la conexión.
Diagrama básico de la conexión.

Para llevar a cabo esta tarea, los requisitos no son muy elevados. En uno de los casos más básicos, nos basta con disponer de una suscripción a Azure, y una máquina con Windows Server 2012 (o 2012 R2) en nuestra intranet, que esté conectado directamente a Internet (con una IP pública). Hay otras posibles configuraciones, como una implementación con GNU/Linux que ya publicamos en nuestro blog.

Teniendo ambas cosas, podemos empezar a configurar nuestro túnel site-to-site:

Antes de nada, debemos cerciorarnos que en todo momento estamos trabajando en la misma Región (ej: Oeste de Europa, Norte de Europa, etc). Esto nos asegura que los recursos van a estar “próximos”, mejorando así su desempeño. En nuestro caso, elegimos “Norte de Europa”.

A continuación, vamos a definir la infraestructura de red virtual en Azure. Este paso es el más importante, y el que debemos tomar en primer lugar, porque actualmente es prácticamente imposible mover máquinas virtuales Azure de una red a otra. Hay formas de hacerlo, aunque implican destruir y volver a crear dicha máquina conservando en todo momento el almacenamiento.

Como nuestra red virtual se va a conectar con un túnel S2S, debemos definir además una “Red Local” y un DNS externo.

Asistente para la creación de una red local (1/2)
Asistente para la creación de una red local (1/2)
Asistente para la creación de una Red Local (2/2)
Asistente para la creación de una Red Local (2/2)

En el diálogo de creación de red local, especificamos el nombre que le vamos a asignar, la IP pública de nuestra máquina conectada directamente a Internet (en el ejemplo 130.130.130.130), y el rango (o rangos de direcciones) de nuestra red local, en este ejemplo 10.0.0.0/22. Esto le va a decir a Azure hacia dónde debe encaminar los paquetes dirigidos a nuestras direcciones de red locales.

Con la red local ya creada, procedemos a especificar nuestros servidores de DNS de la Intranet, que son los que se van a utilizar para direccionar por nombre las máquinas que hay en nuestra infraestructura local.

Añadir un Servidor DNS a las redes
Añadir un Servidor DNS a las redes

Con la red local y al menos un servidor DNS de la intranet ya definidos, podemos pasar a configurar  la nueva red Virtual:

En la creación de la Red Virtual (paso 1/3), definimos el nombre que le vamos a asignar y la Ubicación. Es importante recordar usar la Región que antes habíamos elegido, para optimizar el funcionamiento del despliegue. Podemos ver en el asistente que se va generando un diagrama de bloques que muestra la “Vista previa de la Red”, lo que nos ayudará a saber el estado de la misma.

Creación de la Red Virtual (1/2)
Creación de una Red Virtual (1/3)
Creación de la Red Virtual (2/2)
Creación de una Red Virtual (2/3)
Creación de la Red Virtual (3/3)
Creación de la Red Virtual (3/3)

En el siguiente diálogo (paso 2/3), elegimos el servidor DNS que hemos agregado previamente (o podemos agregar uno nuevo), y marcamos la opción de “Configurar una VPN de sitio a sitio”. En el desplegable de “Red Local”, elegimos la red local que hemos creado en el paso anterior, o bien podemos elegir crear una nueva red. En caso de crear una nueva red, los pasos a seguir son idénticos a los ya realizados.

Finalmente, en el tercer paso, nos toca definir el rango de direcciones de la red virtual (en este ejemplo 10.1.0.0/22). Hay que tener en cuenta que como estamos creando un túnel S2S, necesitamos definir un espacio de /29 (8 direcciones IP) para la puerta de enlace, así que hay que ser algo generosos para definir las direcciones, o nos arriesgamos a quedarnos con una red muy pequeña y fraccionada.

Aún debemos tomar otro paso adicional: Crear una puerta de enlace. Este paso es crítico, porque esta puerta de enlace es el punto de Azure por el que va a pasar todo el tráfico hacia/desde nuestra red local. Preferiblemente, usar enrutamiento dinámico, ya que en general es más tolerante a problemas de conexión. Esta puerta de enlace se crea desde la página de resumen de nuestra Red Virtual.

Esto es todo por el lado de Azure, pero aún nos falta configurar el lado de la Intranet. En esta captura vemos un entorno de producción en funcionamiento (

Red Virtual Una vez Terminada
Red Virtual Una vez Terminada

Configuración del Servidor RRAS en intranet.
Podemos descargar un script Powershell desde la página de resumen de la Red Virtual en Azure (ejecutar como Administrador) que automatiza todo el proceso de configuración de una máquina Windows Server 2012 (o 2012 R2), instalando el rol de RRAS y configurándolo para utilizar la puerta de enlace de la Red Virtual en Azure. Entre otros parámetros que configura, se incluyen la IP del gateway azure, la clave de acceso a la red, etc.

En las dos últimas capturas podemos ver la configuración de RRAS que nos ha dejado el script.

Interfaces de red en RRAS
Interfaces de red en RRAS
Ruta estática hacia Azure
Ruta estática hacia Azure

Normalmente, el script va a dejar el sistema listo y funcionando perfectamente, a la espera de pulsar el botón “Conectar” en la página de resumen de la Red Virtual en Azure. Como el RRAS se configura para conectarse automáticamente, y tenemos enrutamiento dinámico, veremos que en pocos segundos, la conexión se establece.

Y con esto, deberíamos de tener visibilidad entre las máquinas de ambas redes a través del túnel.

Bonus Troubleshooting:

  • Si tenemos varios segmentos de red en nuestra intranet, separados por diversos gateways (por ejemplo redes 192.168.x.x conviviendo con la red 10.0.x.x), debemos asegurarnos de que esos dispositivos pueden encaminar paquetes a la Red Virtual, usando como Gateway nuestra máquina RRAS, además de incorporar todos esos segmentos en nuestra definición de Red Local en Azure.
  • Si el cortafuegos de Windows está filtrando paquetes y haciendo imposible la comunicación entre Azure y tu intranet… No lo desactives. Recuerda que una interfaz de red está conectada a Internet con una IP pública.
    Esto puede pasar, por ejemplo, porque al configurar RRAS se desactive la configuración de Gateway en las diversas interfaces de Red de la máquina, de forma que una o más redes a las que esté conectada aparecen como “Red no identificada”. A estas redes se les aplica por defecto el perfil “público” del cortafuegos, el más restrictivo. Lo que podemos hacer es modificar la Política de Seguridad Local (Windows+R -> secpol.msc) y modificar las “Directivas de administrador de listas de redes” y hacer que las “Redes no identificadas” sean tratadas como redes privadas.

0 pensamientos en “Túneles Site-2-Site en Azure con Windows Server 2012”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *