Conectando redes con NAT e IP dinámicas mediante VPN site to site a Azure

Como os hemos explicado en otras ocasiones, en Plain Concepts estamos estableciendo las redes de todas nuestras oficinas en torno a un hub central en Microsoft Azure, siguiendo una topología de estrella. La topología que tenemos diseñada se parecería –en grandes rasgos- a lo siguiente:

image

Evidentemente, utilizaríamos las capacidades del Azure Network Gateway con enrutamiento dinámico para poder establecer múltiples túneles IPsec site to site entre las distintas sedes. Sin embargo, y tal y como os hemos comentado en otros artículos, es necesario cumplir con una serie de requisitos para poder conectarse a Azure, entre los que se encuentran:

  • Disponer de un dispositivo gateway compatible, o bien una máquina Windows Server 2012 R2 ó UNIX (GNU/Linux incluido).
  • No debe haber ninguna clase de NAT entre los gateway que vamos a conectar, es decir, el nuestro y el de Azure.
  • Debemos disponer de una IP pública fija.

En una de nuestras oficinas nos hemos encontrado con un problema: no teníamos la posibilidad de disponer de IP fija, con lo que incumplíamos los requisitos y se tornaba imposible conectar la oficina dados los requerimientos. El procedimiento obvio era contratar una IP fija, pero ningún proveedor de fibra nos ha dado la opción, y como tampoco es menester de este artículo o blog discutir sobre las telcos, vamos sencillamente a tomar esa restricción como insalvable. La situación es esta:

image

Solución 1: Azure User Defined Routes e IP forwarding

Entre las grandes novedades del Build 2015 se encuentran importantes mejoras en el networking de Azure con la inclusión de las siguientes características:

Usando estas características podríamos establecer una máquina virtual en Azure como dispositivo de gateway para nuestra red virtual, de forma similar a como hicimos con Amazon Web Services. Así podríamos superar algunas de las limitaciones impuestras por el gateway de Azure.

Aunque esta sería la solución ideal, he de decir que me encontré con dificultades configurando el dispositivo y con muy poca documentación al respecto. Nada que reprocharle a Microsoft dado que son características que llevan muy poco tiempo publicadas; así que es una mera cuestión de esperar algunos meses a que tengamos documentación detallada.

Solución 2: Utilizar Amazon Web Services como intermediario

No podemos decir que no estemos sacando provecho del experimiento que hicimos para el Global Azure Bootcamp 2015. Si entre la red de Sevilla y la red de Azure ponemos alguna pasarela que sí cumpla con los requerimientos de Azure y las reestricciones de Sevilla, esta máquina podría encargarse de dirigir el tráfico entre ambos entornos.

Podríamos haber cumplido este requerimiento utilizando la red on-premises de Madrid, pero nos pareció oportuno dar a Sevilla independencia desde el punto de vista de infraestructura, por lo que desplegar una máquina en Amazon Web Services me pareció una solución ideal. El diagrama sería el siguiente:

image

Implementando la solución 2: los pasos

La implementación de la solución 2 se realiza a través de los siguientes pasos:

  1. Crear una VPC en AWS con una máquina virtual basada en GNU/Linux. En mi caso elegí Ubuntu 14.04 LTS, pero serviría cualquier distribución, incluso algún otro sabor de UNIX como FreeBSD.
  2. Configurar la red virtual de Azure y su gateway para conectar con la recién creada red de Amazon, tal y como ya explicamos en este artículo.
  3. Ya establecida la conexión en Azure y Amazon, debemos realizar lo propio en la misma máquina entre Sevilla y Amazon, asegurándonos de cumplir con los requerimientos de Sevilla, es decir, usar IP dinámica.

Estableciendo un túnel IPsec con IP dinámica en un extremo

El núcleo tecnológico de este artículo es precisamente establecer un túnel entre dos extremos: uno con IP fija y otro con IP dinámica utilizando IPsec, cosa que es posible si tenemos control de ambos. Dada la buena experiencia que nos ha dado siempre, he optado de nuevo por usar StrongSwan, con su potente implementación de IPsec con IKEv2. StrongSwan corre sobre Linux, Android, FreeBSD y Mac OSX.

Cabe destacar que no hemos usado ningún protocolo adicional para el transporte comó podría ser L2TP, dado que IPsec con IKEv2 ha funcionado estupendamente en modo túnel.

La máquina GNU/Linux usada para la implementación tiene las siguientes características:

  • 1 único nucleo de CPU
  • 1 GB de RAM
  • 1 adaptador de red con dirección IP privada asociada
  • 1 IP pública que mapee los puertos 500/UDP y 4500/UDP al adaptador de la máquina virtual

 Configurando la máquina en Sevilla

Así pues entramos en la máquina GNU/Linux y ejecutamos:

Tras lo cual estamos listos para configurar el stack de IPsec en el extremo de Sevilla en el archivo /etc/ipsec.conf:

Los parámetros importantes a explicar son:

  • left. El extremo izquierdo del túnel, habitualmente la máquina que inicia la conexión. Normalmente aquí especificaríamos una dirección IP, pero recordemos que nuestra IP es dinámica, por lo que utilizamos una resolución de dominio precedida por %. Este modificador indica que aunque le vamos a sugerir una IP, aceptaremos cualquiera.
  • leftsubnet. La subred que vamos a exponer a través del túnel.
  • leftid. Importantísimo parámetro en el caso de una IP dinámica. Es un identificador que deberá cuadrar con el que el otro extremo solicite en el momento de la conexión, de forma que IPsec sepa que se está conectando al lugar correcto. Va precedido de @ para indicar que el dominio no debe resolverse, ya que se usa sólo como identificación.
  • right. El extremo derecho del túnel. Este es Amazon y aquí si tenemos una IP pública fija.
  • rightsubnet. La subred en el otro extremo a la que querremos acceder a través del túnel.
  • rightid. Similar al leftid.

Y tras ello debemos poner la PSK en /etc/ipsec.secrets:

Esta configuración nos debería permitir establecer la conexión, pero para que los paquetes que pasen por la máquina entren por el túnel debemos especificar la política correcta en iptables:

Si además estamos usando iptables para filtrar tráfico deberemos poner las reglas correspondientes para permitir los puertos 500/UDP y 4500/UDP.

Configurando la máquina en Amazon Web Services

Recordemos que esta máquina va a conectar tanto a Sevilla como a Azure, por lo que debemos configurar StrongSwan adecuadamente. Voy a presuponer que hemos realizado ya en ella los pasos detallados en este artículo y tenemos nuestro túnel con Azure ya funcionando.

¡No olvides permitir el tráfico IPsec en el Security Group de AWS!

image

Después hay que modificar el /etc/ipsec.conf:

Tras ello, de igual forma que hicimos en el gateway de Sevilla, deberemos configurar el archivo /etc/ipsec.secrets con las PSK tanto de Sevilla como de Azure, para poder establecer ambos túneles.

Y del mismo modo, las políticas de iptables:

Llegados este punto ya sólo nos queda hacer ipsec restart en ambas máquinas y consultar desde la máquina de Amazon el estado de ambos túneles. Si todo ha ido bien deberíamos poder ver algo parecido a lo siguiente:

image

Comprobamos el resultado con un PING de Sevilla a Azure:

Ping Sevilla-Azure

 

Y si hacemos un PING desde Azure a una máquina de la red de Sevilla:

Ping Azure-Sevilla

Algunos consejos ante posibles problemas

  • Muchos de los problemas de configuración que se pueden presentar estableciendo túneles IPsec suelen estar en la configuración de ambos extremos. ¡Asegurate de que cuadran perfectamente entre ellos!
  • En otras ocasiones, puede haber problemas de conectividad de red y firewalls, comprueba todas las políticas.
  • ¿Sigues con problemas? Examinar el log de StrongSwan puede ayudarnos a diagnosticar. Lo encontrarás por defecto en el Syslog, en /var/log/syslog.
  • Si el dispositivo o máquina donde establecéis el túnel es al mismo tiempo la puerta de enlace por defecto, no será necesario tocar ninguna tabla de rutas.
  • ¿Más dudas? ¡Déjanos un comentario!

Happy networking!

0 pensamientos en “Conectando redes con NAT e IP dinámicas mediante VPN site to site a Azure”

  1. Carlos muy bonito!…un trabajo estupendo la verdad. No he llegado ha tener que integrar VPNs de AZURE con Gateway IP dinámicos en el extremo del cliente. Pero es un documento muy de agradecer. Saludos desde la competencia.

    1. ¡Gracias Miguel! Son problemas de redes bastante típicos donde con frecuencia demostramos que en muchas ocasiones las dificultades técnicas se pueden superar siendo creativos. Saludetes también desde la competencia 🙂

  2. Muy interesante el artículo, Carlos. Un par de dudas: ¿Perdéis mucho throughput por pasar por dos túneles IPSec desde Sevilla a Madrid y viceversa? ¿Habéis tenido problemas por fragmentación de paquetes?

    Saludos!

    1. Hola Juan, ¡que bueno verte por aquí!

      Sinceramente, aún no lo hemos sometido a pruebas de carga, así que no puedo decirte todavía cuanto perdemos por el overhead. SIn embargo mi sensación es que el principal limitante actual será el rendimiento de red de la máquina de Amazon, que es la más pequeña; pero en este sentido mejorarlo es tan fácil como subir el tamaño. Lo que sí te podría decir es que la latencia de un paquete que hace el viaje Sevilla – Amazon – Azure – Madrid y viceversa ronda los 110 ms sostenidos. En mi opinión no está nada mal para ese recorrido.

      Sobre problemas por fragmentación, de momento ninguno, aunque somos precavidos y en nuestro enlaces WAN ponemos la MTU a 1450. Cuando tenga más medidas las comento por aquí.

Deja un comentario

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