Archivo de la etiqueta: networking

Construyendo una VPN Point-to-Site con autenticación RADIUS y AD en Microsoft Azure

Ya hemos comentado en otras ocasiones en este blog cómo establecemos una VPN Point to Site en Microsoft Azure. Aunque es una forma rápida y versátil de dar a equipos cliente acceso a nuestra red virtual de Azure, lo cierto es que nos enfrentamos a algunas limitaciones que en función del proyecto en que nos encontremos pueden ser todo un stopper para nosotros o nuestro cliente. Concretamente son las siguientes:

  • Sólo admiten 128 clientes como máximo. Como sabéis, las conexiones de App Service cuentan como un cliente.
  • El cliente sólo funciona en Windows 7 o superior (32 y 64 bits). Nos olvidamos de otras plataformas.
  • La autenticación se realiza mediante certificados, no hay nombres de usuario y contraseñas.
  • La comunicación normalmente es en un sentido, del cliente a la infraestructura de Azure y no viceversa.

Si estos puntos no nos suponen un gran problema, el P2S que Azure nos ofrece como servicio es una excelente forma de conectarnos a nuestra red virtual. Pero si resulta que lo es… ¿qué podemos hacer?

Alternativa 1: Máquina Virtual con Windows Server 2012 R2 y RRAS

Es lo primero que se nos viene a la cabeza. Pero no me cansaré de repetir que el rol de RRAS de Windows Server 2012 R2 (y versiones anteriores) no está soportado en Azure. Aunque al instalarlo nos de la sensación de que todo está OK, Azure eventualmente reinicia los adataptadores de red sintéticos asociados a dicha máquina, algo que hace que no sobreviva la configuración que hemos hecho del rol.

Los suficientemente valientes pueden probar a crear un script de autoconfiguración del rol que se ejecute cada vez que se encieda la máquina, pero os encontraréis con que el soporte de PowerShell de este rol es realmente pobre (está pensado para DirectAccess más que para VPN) y no os quedará más remedio que recurrir al viejo amigo netsh. Que la fuerza os acompañe.

Aunque consiguiéramos autoconfigurar la máquina en cada inicio esto es algo que considero bien lejos de ser estable y confiable, por lo que debíamos ir a otra alternativa.

La solución: gateway GNU/Linux con SoftEther VPN

Parece que GNU/Linux no se ve afectado por los cambios de adaptador de red de Azure, algo que nos arroja algo de luz al problema. Acto seguido necesitamos decidir con qué software implementar la solución. Decidí que SoftEther VPN era la mejor. Gracias a esto vamos a superar todas las limitaciones que hemos comentado antes.

¿Qué es SoftEther VPN?

SoftEther VPN es un potente software VPN de código abierto desarrollado por la Universidad de Tsukuba (Japón) que se posiciona como una alternativa poderosa a los sistemas de túneling existentes, ya sean los basados en RRAS de Microsoft o bien el extendido OpenVPN. ¿Qué lo hace tan genial?

  • Multi-protocolo. SoftEther VPN soporta L2TP/IPsec, SSTP, OpenVPN y SSL VPN (a través de un cliente propio).
  • Multi-plataforma, ya que corre bajo Windows, OSX, Linux, FreeBSD y Solaris.
  • Multi-arquitectura, soportando x86, x64, ARM, MIPS, SH-4, PowerPC y SPARC.
  • Multi-authentication backend: soportando usuarios y contraseñas locales, certificados X.509, Active Directory (sólo Windows) y RADIUS.

Como podéis ver se trata de un completísimo sistema de VPN que soporta prácticamente todo lo que podamos imaginar.

Autenticando con Active Directory

Os habrá llamado la atención que SoftEther VPN soporta Active Directory como backend de autenticación, pero lamentablemente sólo en el caso de que estemos ejecutando el servidor bajo Windows. Esto en Azure nos devolvería a la casilla de salida, así que tenemos que asumir que estamos en Linux. Sin embargo, en la lista también estaba RADIUS. ¿Tiene Microsoft algún servidor RADIUS que nos haga de pasarela a la autenticación de ADDS? ¡Sí! ¡El Network Policy Server! NPS para los amigos.

Nuestra arquitectura a alto nivel sería la siguiente:

gaw1

Así que dicho y hecho, nuestro escenario de demo se va a componer de tres máquinas en Azure:

  • SoftEther VPN (Linux)
  • NPS + ADDS (Windows)
  • App Server (no es indiferente el sistema operativo).

La última máquina de la lista es solo para comprobar conectividades y representa nuestra infraestructura en Azure.

Inyectando a nuestros clientes VPN P2S en la red de Azure: el adaptador de red TAP de Linux

Uno de los grandes problemas que nos podemos encontrar a la hora de conectar clientes a nuestra red virtual de Azure es que esta no es precisamente muy amiga de eso. Una red virtual de Azure se encuentra gobernada por el DHCP que Microsoft instaura en ella y por tanto si intentamos conectarlos a través de la máquina virtual que hemos desplegado, no obtendremos ningún resultado satisfactorio.

Aquí entra en juego otra de esas capacidades de Linux que hace que nos maravillemos con él cada vez que hacemos temas de networking: el adaptador de red virtual TAP. Este adaptador de red es una interfaz virtual que se encuentra integrada en el kernel de Linux y que puede ser desplegada por las aplicaciones que lo requieran. Tiene infinidad de usos en software de tunneling y virtualización.

Cuando desplegamos el adaptador, obtenemos algo similar a esto:

gaw3

Como se puede ver en la imagen, la máquina virtual de SoftEther se encuentra dentro de la red virtual de Azure, y así lo refleja el adaptador eth0. Pero… ¿y si creamos un nuevo adaptador TAP? Llamémosle tap_vpn0. Este adaptador virtual no se encuentra realmente dentro de Azure: no ve la red virtual, el DHCP de Azure no tiene efecto sobre él y es agnóstico a nuestro entorno. ¡Es el candidato perfecto para unir nuestros clientes P2S!

Sin embargo, una vez unidos los clientes a este adaptador, debemos establecer comunicación con la red virtual de Azure. Esto lo podemos conseguir fácilmente convirtiendo nuestra máquina Linux en un router a su vez (ya sabéis, activar IP forwarding como hemos comentado otras veces). De esta manera el dibujo se convierte en el siguiente:

gaw2

User Defined Routes e IP forwarding a nivel de Azure

Hecho esto, necesitamos que Azure sepa a qué gateway enviar el tráfico dirigido a los clientes VPN y permitir que esa máquina acepte tráfico que no es necesariamente para ella. A día de hoy, esto es perfectamente posible:

  • User Defined Routes (UDR). No es ni más ni menos que una definición de tablas de rutas en una red virtual de Azure. Nos permite dirigir el tráfico a donde nos interese. Este tema merecerá un artículo del blog en exclusiva.
  • IP ForwardingFundamental si usamos tablas de rutas y enviamos el tráfico a una máquina virtual, ya que por defecto está no aceptará ningún packete de red en el que ella no sea la destinataria.
El resultado

Tras todo el proceso deberíamos tener operativo todo un hub de conexiones VPN que además nos permite superar las limitaciones que comentábamos al inicio del artículo.

gaw4

El resumen y To-Do list

Como el artículo ha constituido una explicación de alto nivel de cómo conseguir en Azure una VPN P2S autenticada mediante ADDS, os dejo con una serie de pasos de alto nivel para hacer la solución más fácil de seguir:

  1. Crear una nueva red virtual de Azure y asignarle un direccionamiento. En nuestro ejemplo 172.16.0.0/24.
  2. Crear máquinas para hospedar los siguientes servicios: SoftEther VPN (Linux), NPS (Windows), ADDS (Windows). Configurar todas las IPs privadas como estáticas.
  3. Configurar SoftEther VPN de la siguiente manera:
    1. Local Bridge hacia un adaptador TAP.
    2. Autenticación basada en RADIUS contra el servidor NPS.
    3. Activar protocolos L2TP/IPsec y SSTP. Opcionalmente podemos activar OpenVPN.
    4. Generar los certificados necesarios para SSTP y distribuirlos en los clientes que vayan a acceder. Recuerda que deben coincidir con el nombre del dominio al que conectas.
  4. Elegir un direccionamiento para nuestro adaptador TAP y asignarle una IP dentro de ese direccionamiento. En nuestro ejemplo 172.17.0.0/24 y el adaptador 172.17.0.1.
  5. Instalar y configurar un servidor DHCP (a mi me encanta dnsmasqque debe ejecutarse tras arrancar SoftEther VPN para que exista la interfaz TAP. Esto es importante porque sólo debe estar enlazado (binding) a la interfaz TAP y NUNCA a eth0, donde entraría en conflicto con el de Azure. Debe servir IPs en el rango del adaptador TAP.
  6. Activar IP forwarding en la máquina Linux en /etc/sysctl.conf.
  7. Activar IP forwarding a nivel de Azure en la máquina virtual Linux.
  8. Crear una UDR que haga que el tráfico para 172.17.0.0/24 se dirija a la IP privada de la máquina virtual con SoftEther.
  9. ¡Listos para funcionar!
Explicándolo en directo

Alberto Marcos y servidor explicamos y demostramos todo esto en directo en la Global Azure Bootcamp 2016. Si te la perdiste tienes la oportunidad de ver en HD la grabación de la sesión justo aquí: https://channel9.msdn.com/Events/Microsoft-Spain-Events/Global-Azure-BootCamp-2016/Construyendo-una-VPN-Point-to-Site-con-autenticacin-RADIUS-y-AD-en-Microsoft-Azure

Happy networking!

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!

Conectando Microsoft Azure con Amazon Web Services: Traffic Manager

Como continuación del artículo anterior en el que explicábamos como conectar Amazon y Azure, basado en la charla que dimos Carlos Milán y yo en Global Azure BOOTCAMP 2015 de Madrid, vamos a dedicar un artículo del blog a explicar cómo balancear la carga entre las dos nubes.

Si recordáis el escenario que conseguimos montar, a través de una conexión VPN S2S teníamos visibilidad de las máquinas virtuales de ambas nubes como si estuvieran en la misma red local. Esto nos permitía dejar volar nuestra imaginación y construir prácticamente cualquier entorno.

¿Qué vamos a hacer?

La idea es continuar desarrollando un escenario un poco más complejo aprovechando que tenemos visibilidad entre ambas nubes. Lo que se nos ocurrió es montar una aplicación web que estuviera replicada, balanceada y con soporte de failover entre Amazon y Azure. Casi nada, eh 🙂

image

 

Como veis en el dibujo tenemos un bosque de AD replicando con DCs en cada nube, y unos servidores IIS que van a formar la granja sobre la que se hospedará la aplicación web. La sincronización de los cambios en la web será tanto a nivel de código como de configuración, pero la explicación de como lo hemos hecho nos la guardamos para otro post 🙂

Partiendo de que la aplicación web es la misma en todo momento si accedemos al IIS de Amazon y de Azure, ¿cómo podemos tener un balanceo real de la carga, y que además sea susceptible de hacer un failover si una nube entera falla? Aquí es donde entra en juego un servicio que nos proporciona Azure llamado Traffic Manager.

Azure Traffic Manager

Se trata de un servicio de balanceo de red basado en DNS. Básicamente lo que hacemos es establecer unos extremos o “endpoints” y en función de la política que elijamos dirigirá el tráfico de manera inteligente a los mismos.

Las políticas que podemos seleccionar son las siguientes:

  • PERFORMANCE – Dirige al extremo “más cercano” basado en la latencia.
  • ROUND-ROBIN – Distribuye equitativamente el tráfico entre todas las localizaciones. Se pueden establecer pesos.
  • FAILOVER – Dirige a la localización de “backup” si el primario falla.

Citando directamente la documentación oficial, este servicio nos aporta las siguientes ventajas:

  • Mejorar la disponibilidad de las aplicaciones críticas:  permite mejorar la disponibilidad de las aplicaciones críticas supervisando los extremos y ofreciendo funcionalidad de conmutación por error automática cuando un extremo deja de estar activo.
  • Mejorar la capacidad de respuesta para las aplicaciones de alto rendimiento: Azure permite ejecutar servicios en la nube en los centros de datos ubicados en todo el mundo. Traffic Manager puede mejorar la capacidad de respuesta de las aplicaciones y los tiempos de entrega de contenido dirigiendo a los usuarios finales al extremo con la latencia de red más baja del cliente.
  • Actualizar y realizar el mantenimiento del servicio sin tiempo de inactividad:  admite escenarios extendidos para implementaciones en la nube híbrida y locales, entre los que se incluyen los escenarios “burst-to-cloud”, “migrate-to-cloud” y “failover-to-cloud”.
  • Distribución de tráfico para implementaciones grandes y complejas: con los perfiles anidados del Traffic Manager, en que un perfil puede tener otro perfil como extremo, puede crear configuraciones para optimizar el rendimiento y la distribución para implementaciones más grandes y complejas. Para obtener más información, vea Perfiles anidados.

Implementando el escenario

La implementación es tremendamente sencilla ya que únicamente debemos utilizar PowerShell para definir el perfil de Traffic Manager. No nos vale la interfaz gráfica dado que todavía no nos permite establecer extremos externos, como es Amazon en nuestro caso.

Vamos a analizar la configuración que nosotros definimos:

image

  • TimeToLiveInSeconds: este valor representa el TTL (TimeToLive) durante el cual va a mantener los endpoints en la resolución DNS. Nosotros lo hemos establecido en el mínimo posible (30 segundos) para que en caso de caída de un extremo, ese cambio se refleje lo más rápido posible en todos los servidores DNS con los que nos podamos cruzar.
  • MonitorRelativePath: es la ruta de la aplicación web que utilizará para monitorizar si el extremo está vivo. Básicamente intenta acceder y espera un 200 OK.
  • MonitorPort: el puerto de monitorización.
  • MonitorProtocol: el protocolo de acceso para la monitorización (http/https)
  • LoadBalancingMethod: aquí definimos el tipo de política o método de balanceo que va a utilizar Traffic Manager. Entre los 3 que veíamos antes, nosotros escogimos Round Robin, y al no especificarle pesos, por defecto es 50%-50%.
  • Endpoints: con este parámetro definimos todos los extremos de nuestra aplicación, en nuestro caso uno está en Azure y otro en Amazon.
  • MonitorStatus: nos indica el estado del servicio de Traffic Manager y de los endpoints definidos.
  • Name: es el nombre del perfil de Traffic Manager.
  • DomainName: es el nombre de acceso a Traffic Manager y por ende a nuestra aplicación. Si luego definimos un CNAME como es lo usual, tenemos que apuntar a este registro. En nuestro caso tenemos azurezon.plainconcepts.com –> azurezon.trafficmanager.net.
  • Status: los perfiles los podemos tener activados o desactivados, y eso nos da mucho juego. Imaginaros dos perfiles con los mismos endpoints, donde por defecto el perfil activo sea uno que funcione por “performance” pero ante cierta situación lo podamos cambiar a “failover”.

Este es el diagrama que nos quedaría:

image

Atendiendo a los parámetros que podemos configurar, y los tipos de balanceo que nos permite Traffic Manager, podemos conseguir escenarios tan interesantes como realizar una migración controlada de una nube a otra. ¿Os imagináis ir balanceando la carga de vuestra aplicación a otra nube e ir viendo como responde? Todo eso es perfectamente posible con Traffic Manager:

image

Otro detalle que debemos tener en cuenta, aunque el impacto es mínimo, es el precio de Traffic Manager y como varía en función de los endpoints. Por ejemplo un extremo “externo a Azure” tiene un coste que es casi el doble (€0,4022/mes), respecto a los extremos que estén en Azure (€0,2681/mes).

Una vez tengamos este entorno configurado, sólo nos queda… ¡la demo final!

Vamos a tirar abajo las máquinas de una nube y automáticamente el tráfico se balanceará a la otra, donde la aplicación estará replicada y actualizada.

Pero… ¿cuánto tiempo tarda Traffic Manager en darse cuenta de que un extremo está caído? Con el TTL de 30 segundos que hemos definido, la respuesta es… 2,5 min. Creo que dos minutos y medio para un failover entre entornos cloud de proveedores distintos no está nada mal 🙂

El dato del RTO (Recovery Time Objective) se calcula en base al número de intentos que realiza Traffic Manager antes de dar un extremo como “caído” (4), por el tiempo que espera entre cada intento (30 seg), más el TTL del registro DNS que tendrá que actualizar eliminando el extremo caído (30 seg): 4*30 + 30 = 150 seg = 2,5 min

En el siguiente gráfico se ve más claro:

Traffic Manager Monitoring Sequence

Podéis encontrar más información al respecto en este artículo.

Con los dos entornos activos, y con clientes distribuidos geográficamente y sin pasar por los mismos servidores DNS intermedios, la distribución de la carga será homogénea.

image image

Una vez el acceso a una de las nubes se vea afectada, como hicimos parando las máquinas de Amazon en nuestra demo, al cabo de 2,5 min todo el tráfico será dirigido únicamente a Azure.

Esperamos que os haya gustado esta segunda parte sobre como montamos un entorno de alta disponibilidad entre nubes y queda pendiente explicaros como hicimos para replicar la aplicación web.

Os dejamos con alguna foto más de la sesión, cortesía de Carmen.

Happy networking!

DSC_0107

DSC_0108

DSC_0111

DSC_0112

Conectando Microsoft Azure con Amazon Web Services

Tal y como os prometimos, después del Global Azure BOOTCAMP 2015 de Madrid, vamos a dedicar un artículo del blog a explicar cómo Alberto Marcos y servidor –Carlos Milán– llegamos a crear un escenario híbrido entre Amazon Web Services (de ahora en adelante AWS) y Microsoft Azure. Si te perdiste nuestra charla, ¡obligatorio que leas este post!

image

¿Qué vamos a hacer?

La idea es bastante simple: vamos a enlazar una VPC (Virtual Private Cloud) de AWS con una red virtual de Azure mediante un tunel site to site IPsec. La idea es que ambas redes queden interconectadas en un entorno LAN y podamos desplegar máquinas virtuales que disfruten de visibilidad a nivel de red local de ambos entornos.

image

Gracias a esta visibilidad, podemos, entre otras cosas:

  • Facilitar enormemente las migraciones de sistemas una plataforma a otra.
  • Crear un escenario de alta disponibilidad donde esta esté garantizada por más de un proveedor de cloud.
  • Crear una infraestructura única que aproveche capacidades especiales de un proveedor que no están disponibles en otro. Por ejemplo: AWS dispone de máquinas virtuales con GPU, mientras que Azure dispone del mejor escalado vertical del mercado con las máquinas de tipo G.
  • Etc…

Definiendo conceptos

Como sabréis los visitantes de nuestro blog, no somos ni mucho menos expertos en Amazon, pero desde luego que somos expertos en Azure; así que aventurarnos en este escenario nos obligó a estudiar un poco la plataforma. Y es que AWS y Azure no son tan distintos como a primera vista pueden parecer, sino que utilizan distinta nomeclatura para elementos que son bastante análogos entre sí. Aquí hay una lista de analogías:

image

Implementando el escenario

Vamos a comenzar con la serie de pasos que seguimos para implementar el escenario donde, como podréis imaginar, hay que realizar una serie de tareas tanto en AWS como en Azure. En el artículo daremos por sentado que tenemos tanto nuestra suscripción de AWS como la de Azure listas para usar.

Direccionamiento IP

Lo primero era elegir un direccionamiento IP para trabajar con ambas redes, que pensamos que podía ser el siguiente:

image

Es muy recomendable crear ambos entornos en una localización geográfica cercana. ¡Una vez tomada la decisión, ya podíamos comenzar a trabajar!

AWS – Creando la VPC

Deberemos crear una nueva VPC en AWS:

  1. Seleccionamos VPC with a Single Public Subnet.
    image
  2. Configuramos las opciones:
    • Establecemos su direccionamiento de acuerdo a lo planeado: 10.0.0.0/16
    • Le damos un nombre cualquiera.
    • Establecemos una subnet pública de 10.0.0.0/24.
    • Resto de opciones por defecto.
      image

¡Ya tenemos red! ¡Ahora a por la pasarela!

AWS – Creando la VM gateway

AWS dispone de un servicio de gateway SaaS, pero como este no cumple con las especificaciones necesarias para conectarse con Azure, vamos a crear nuestra propia máquina virtual que actuará como gateway a Azure de nuestra red.

  1. En el servicio de EC2 vamos a seleccionar una AMI (Amazon Machine Image) Windows Server 2012 R2 Base.
    image
  2. Una instancia de tipo t2.micro es más que suficiente para nuestro laboratorio.
  3. Seleccionamos que pertenezca a la VPC que hemos creado en la tarea anterior y dejamos el resto de opciones por defecto. Opcionalmente podemos especificar una IP interna o si no asignará una por DHCP estático.
  4. En la parte de almacenamiento, servirá bien el disco SSD de 30 GB por defecto. Tras la instalación de Windows Server 2012 R2 sólo nos quedarán unos 6 GB libres de espacio en disco, pero serán suficientes para nuestro propósito.
  5. Daremos un nombre a la máquina, nosotros la llamamos GATEWAY.
  6. Creamos un nuevo Security Group para ella. Los Security Groups son reglas de firewall que nosotros establecemos para regular el tráfico en las instancias de Amazon EC2; son equivalentes a los Endpoints y Security ACLs de Azure. Para la máquina de gateway en Amazon deberemos crear uno nuevo con las siguientes reglas:
    image
    Las reglas que corresponden a los puertos UDP 4500 y 500 son las del tráfico IPsec y verás que sólo las permitimos en una IP concreta. Esta IP es la de gateway de Azure, que en este punto todavía no tenemos establecido y por tanto no conocemos. Ignóralas de momento y volveremos más tarde a añadirlas.
  7. Creamos la máquina vritual.

AWS – Elastic IPs

Si vamos a crear un gateway IPsec en una máquina virtual, no querremos que su IP pública cambie o nos inutilizará el escenario. Por ello debemos reservar una que mantenga siempre.

  1. Desde EC2 Dashboard seleccionamos Elastic IPs.
  2. Seleccionamos Allocate New Address.
  3. Le indicamos que queremos asociar la IP a una instancia de máquina virtual.
  4. Seleccionamos la máquina GATEWAY que creamos en el proceso anterior.

Con estos sencillos pasos nuestra máquina ya tiene su IP pública fija, ¡anótala! Te hará falta en el siguiente paso, ¡nos vamos a Azure!

AZURE – Creando la red virtual

Vamos a proceder a crear una red virtual nueva:

image

Las opciones a configurar serán:

  • Queremos conecitividad site-to-site VPN.
  • Especificaremos una nueva red local.
  • Como red local definiremos el direccionamiento que hemos elegido para AWS: 10.0.0.0/16
  • La IP del dispositivo VPN: debe ser la Elastic IP que reservaste en la tarea anterior desde AWS.

La configuración de la red de AWS en Azure podría quedar así:

image

Mientras que la de Azure, en el último paso del asistente, quedaría así:

image

¡No olvides crear una subnet para el gateway! La necesitarás para lo que viene justo ahora.

AZURE – Creando el gateway

Entra en la red virtual que acabas de crear y selecciona Create gateway y Dynamic routing.

Botón de selección de tipo de gateway en el momento de su creación.

Cuando esté creado podremos ver la IP asignada desde el dashboard de la red virtual:

image

Y además haremos clic en Download VPN Device Script para descargar la configuración que ejecutaremos en la máquina Windows Server 2012 R2:

image

¡Es hora de volver a AWS!

AWS – Editando Security Group

¿Recuerda el Security Group que creamos para la máquina gateway en AWS? Como ya sabemos la IP del de Azure es hora de que lo agreguemos a las reglas. Recuerda:

image

Agregamos dos nuevas Custom UDP Rule a los puertos 4500 y 500 para permitir que el tráfico IPsec fluya desde el gateway de Azure.

AWS – Configurando RRAS en el gateway Windows Server 2012 R2

En este paso no voy a entrar en mucho detalle puesto que es análogo a lo que Antonio López Márquez ya nos explicó en este otro artículo. En realidad no tenemos más que llevar a la máquina Gateway el script de PowerShell que hemos descargado del portal de Azure y ejecutarlo. Este script agregará automáticamente el rol de RRAS al servidor y configurará la conexión con el gateway de Azure.

AWS – Desactivando Source/Destination Check

El Source/Destination Check de son una serie de verificaciones que los adaptadores de red virtuales de EC2 realizan para comprobar si el tráfico que una interfaz de red recibe está verdaderamente destinado a la misma. Como resulta obvio, esto puede resultar nefasto en una máquina de gateway que hace de pasarela para el tráfico destinado a otras máquinas, por lo que debemos desactivar estas comprobaciones.

  1. Desde el dashboard de EC2 seleccionamos Network Interfaces.
  2. Seleccionamos el interface de red de nuestra máquina gateway.
  3. En Action podremos seleccionar Change Source/Dest. Check, que cambiaremos a Disabled.

image

Llegados este punto, el tunel entre AWS y Azure debería estar establecido y así tendríamos que poder verlo en el dashboard de Azure. Desde AWS no tenemos un vistazo tan gráfico y deberemos entrar en la máquina Gateway para comprobar su estado. Debería lucir tal que así:

image

Pero esto no será suficiente para que el tráfico fluya entre las máquinas de ambas redes. Necesitaremos modificar la tabla de rutas de la red de AWS para conseguirlo.

AWS – Creando una nueva tabla de rutas para la subred

Crear y modificar tablas de rutas en AWS es bastante trivial:

  1. Nos dirigiremos al dashboard de EC2 y acto seguido a Route Tables.
  2. Clic en Create Route Table. Ten en cuenta que otra posibilidad es editar la tabla de rutas principal de la VPC que creamos anteriormente. Haz este paso a tu gusto.
  3. Le ponemos un nombre y la adjuntamos a la red que hemos creado.
  4. Posteriormente deberemos asociar la tabla de rutas a la subnet pública que creamos también en pasos anteriores.

Y finalmente deberemos editar dicha tabla para agregar la ruta a Azure a través del gateway. Esto quedaría así:

image

Como podéis ver la ruta a Azure se asocia directamente a la interfaz de red que se encuentra en la máquina de gateway.

Probando el escenario

¡Y esos eran todos los pasos! Ya estamos preparados para probar el escenario que hemos explicado. Para ello vamos a desplegar un par de máquinas virtuales, una en AWS y otra en Azure, donde probaremos si tienen conectividad entre ellas. El sistema operativo es irrelevante en este caso. En nuestro lab hemos puesto una máquina adicional Windows Server 2012 R2 en AWS y una máquina con Ubuntu GNU/Linux en Azure. El esquema sería el siguiente:

image

El resultado se pudo ver en directo en la presentación, hicimos ping de forma satisfactoria de la máquina AWS a la máquina Azure y viceversa, con lo que teníamos un canal de comunicaciones seguro y establecido entre ambos datacenters.

WP_20150425_11_48_29_Pro (Medium)

Por supuesto, nuestra demo no se limitó a enseñar un ping entre máquinas, sino que realizamos algunas pruebas más, algunas de ellas muy vistosas que nos reservamos para otro artículo. Espero que este artículo os haya resultado interesante y os anime a explorar las posibilidades de interoperabilidad y conexión de Azure, ¡incluso con su plataforma rival!

Os dejamos con algunas fotos de la charla del Bootcamp donde podéis ver a Alberto y servidor en acción 🙂

Happy networking!

Enlace relacionado: Connecting Clouds – Creating a site-to-site Network with Amazon Web Services and Windows Azure

WP_20150425_11_27_52_Pro (Medium)

WP_20150425_11_33_22_Pro (Medium)

WP_20150425_11_44_05_Pro (Medium)

WP_20150425_11_45_26_Pro (Medium)

WP_20150425_11_46_09_Pro (Medium)

WP_20150425_11_48_29_Pro (Medium)

Network Monitor (2/2)

¡Hola de nuevo!

¿Echabais de menos a Network Monitor? ¿Os supo a poco el anterior artículo donde hacíamos una introducción al producto?

Continuando con algunas curiosidades que podemos hacer con la herramienta de análisis de red de Microsoft, hoy vamos a conocer aquellas un poco más avanzadas:

Ejecución de la captura desde la línea de comandos:

Aquí tenéis la referencia general, donde podemos ver cosas tan interesantes como la posibilidad de especificar la red donde queremos capturar, o el tamaño máximo de la captura.

Managing Network Monitor from the command line: http://technet.microsoft.com/en-us/library/cc782726(v=ws.10).aspx

 

Trazas circulares:

Una de las cosas que más nos puede ayudar en el troubleshooting de un problema que no podemos reproducir en cualquier momento, es tener una captura que se mantenga en el tiempo, que el tamaño no se haga inmanejable, y que podamos pararla en el momento en el que el problema surja de nuevo.

La línea de comandos de Network Monitor nos permite hacerlo a través de las trazas circulares, pudiendo establecer un tamaño máximo de la traza, una hora de inicio o de fin, etc.

En el siguiente ejemplo, cuando se alcance el tamaño de la traza especificado, se creará un nuevo fichero de la cadena y se seguirá capturando, del modo que quedarían de la forma test(1).chn, test(2).chn, etc.

 

Fusionar trozos de capturas en una más grande:

Imaginaros que en ejemplo anterior, debido al tamaño de cada trozo o de la cantidad de datos que estamos capturando, tenemos que estar cambiando continuamente de trozo para analizar un problema. ¿No sería genial localizar la conversación que queremos en un grupo de trozos, y combinarlos en una traza única?

Network monitor también nos permite hacerlo con la siguiente sentencia:

 

Arrancar una captura con Windows:

Aunque Network Monitor permite capturar durante el arranque del Sistema Operativo, interesante sobre todo para escenarios de “slow logon”, la verdad es que no es el procedimiento más sencillo del mundo:

Capturing a trace at boot up: http://blogs.technet.com/b/netmon/archive/2010/01/04/capturing-a-trace-a-boot-up.aspx

Desde luego, no estamos vendidos sin opciones, y en este caso acude al rescate la herramienta de linea de comandos incorporada con el propio Windows para todos los temas de Networking: netsh

Simplemente tenemos que añadir la opción de persistent, y la herramienta seguirá capturando, incluso durante el arranque del sistema operativo:

clip_image002

No nos tenemos que olvidar de parar la captura:

Luego con Network Monitor podemos abrir sin problema este tipo de ficheros .etl cuando se trata de trazas de red.

clip_image004

 

Asociar la parada de la captura a un Evento:

Imaginaros que tenemos localizado un problema porque cuando ocurre aparece un evento en el Event Viewer, y nos gustaría analizar a nivel de red qué ocurre justo antes, de cara a determinar que propicia la aparición del problema. Con Network Monitor también podemos hacerlo, os dejamos las instrucciones en el siguiente enlace:

EventMon: Stopping a Capture Based on an EventLog Event: http://blogs.technet.com/b/netmon/archive/2007/02/22/eventmon-stopping-a-capture-based-on-an-eventlog-event.aspx

 

Microsoft Message Analyzer:

Hace un par de años que Microsoft sacó la evolución de Network Monitor, llamado Message Analyzer.

La verdad que personalmente no lo he usado mucho. No sé si porque ya estoy acostumbrado a Network Monitor, o por comodidad con los menús, pero tiene sus mejoras, como la posibilidad de cargar nuevos parsers, ver en un formato legible documentos, fotos o videos directamente seleccionando el grupo de trazas que lo forman, etc.

Os dejo el último artículo que ha presentado el grupo que lo lleva para que os hagáis una idea de lo potente que puede ser:

Troubleshooting Microsoft Azure Storage with Message Analyzer: http://azure.microsoft.com/blog/2015/01/27/troubleshooting-microsoft-azure-storage-with-message-analyzer

 

Y con esto acabamos la serie de artículos sobre Network Monitor. Esperamos que os hayan gustado.

¡Happy networking!

Elección del adaptador de red en equipos Windows

¿Os habéis fijado que cuando estamos conectados por wifi y conectamos el cable de red, automáticamente cambia el flujo de red? ¿Sabéis como establece Windows el adaptador adecuado para llegar a un recurso de red?

Hay dos factores que influyen principalmente en la elección de una conexión por parte de un equipo Windows:

  1. Si las IPs de los adaptadores pertenecen a diferentes subredes, lo primero que evalúa es la proximidad del recurso al que se desea conectar, haciendo matching con las máscaras de subred. Por tanto, si deseamos forzar a utilizar una conexión distinta de la que evalúa por defecto, deberemos eliminar la ruta que va a utilizar (la que considera más próxima), y asegurarnos que a través de que la ruta que existe para el adaptador deseado, se consigue llegar al recurso igualmente.
  2. Si las IPs de los adaptadores pertenecen a la misma subred, a partir de Windows XP, el valor que se evalúa para elegir una conexión u otra es la Métrica. Ésta se calcula automáticamente para cada tarjeta de red en función de su velocidad.

Cualquier cambio manual, debe ser seguido de un reinicio de los adaptadores de red.

Dado que este valor es teórico, a menudo sucede que una red inalámbrica “N” con velocidad nominal de 300Mbps tiene asignada una métrica 10, considerándose más rápida que una conexión Ethernet con 100Mbps y asignada una métrica 20 (cuánto más pequeño, mejor).

Sin embargo, se puede asignar manualmente los valores de la métrica en las tarjetas de red para obligar a su orden de preferencia.

Es necesario que el número elegido sea entre 5 y 50. Por defecto los valores que calcula son:

Link Speed Metric
Greater than or equal to 2 GB 5
Greater than 200 Mb 10
Greater than 20 Mb, and less than or equal to 200 Mb 20
Greater than 4 Mb, and less than or equal to 20 Mb 30
Greater than 500 kilobits (Kb), and less than or equal to 4 Mb 40
Less than or equal to 500 Kb 50

Si el valor de la métrica es el mismo para varios adaptadores, el orden de preferencia es el indicado en el “Binding Order”.

Podemos visualizar los valores de métrica establecidos mediante el comando:

 

O con el cmdlet de PowerShell:

 

Podemos modificar su valor a través de la interfaz gráfica:

clip_image002

O también mediante consola de comandos, ejecutando:

 

O mediante el cmdlet de PowerShell:

 

Esperamos que os haya parecido interesante y nos vemos la próxima semana.

Happy networking!

Microsoft Azure Site to Site cross-premises usando GNU/Linux (Ubuntu 12.04 LTS) y StrongSwan

Siempre comento en los eventos y charlas que la realidad de las empresas y organizaciones no son escenarios donde puedan afrontar un cambio total de infraestructuras a la nube. Normalmente, tendremos una serie de servidores y un espacio habilitado como nuestro CPD que no pueden ser descartados de forma inmediata. Es por ello que si bien la nube puede ser el futuro, los escenarios híbridos son el presente. Un escenario híbrido en Microsoft Azure es aquel que nos permite utilizar las capacidades de la plataforma de Microsoft como si se tratase de una red que forma parte de la nuestra, de forma transparente.

Los más aventajados en redes entenderéis perfectamente de qué estoy hablado. Si es posible conectar múltiples sucursales con una oficina central a través de túneles site to site entre ellos, ¿por qué no íbamos a poder hacer lo mismo con una red virtual de Azure?

Escenario tipo de VPN site to site con Azure, usado en este caso para hospedar servidores de identidad para Office 365
Escenario tipo de VPN site to site con Azure, usado en este caso para hospedar servidores de identidad para Office 365

Microsoft Azure nos permite realizar conexiones site to site a sus redes virtuales a través de túneles IPsec, utilizando IKEv1 (enrutado estático) ó IKEv2 (enrutado dinámico) con -en teoría- cualquier dispositivo que cumpla con las especificaciones. Este un listado de dispositivos soportados y sus respectivos scripts de configuración. Veréis que es posible usar una máquina genérica con GNU/Linux y openSwan, sin embargo, este sólo soporta enrutamiento estático y en mi experiencia, el enrutamiento dinámico propicia enlaces más estables con Azure. Que un dispositivo o software no esté en esta lista no implica que no funcione, sino que Microsoft no ha certificado ni da soporte al mismo.

Por diversos motivos de redes que explicaré en otro post, en Plain Concepts utilizamos GNU/Linux como router y servidor de perímetro, por lo que necesitábamos un stack IPsec que funcionase bien con Microsoft Azure y soportase enrutamiento dinámico. strongSwan parecía la solución más obvia y… ¡acertamos de pleno! Tanto openSwan como strongSwan son forks del descontinuado freeSwan. No voy a entrar a valorar cual de las dos implementaciones es mejor, así que sólo comentaré que openSwan funcionó bien con enrutamiento estático y strongSwan con dinámico.

Requerimientos

  • Una máquina GNU/Linux con el kernel 2.6 o superior.
  • Al menos dos interfaces físicas ethernet.
  • Conectividad directa a Internet sin NAT. Una de las interfaces debe recibir directamente la IP pública de nuestro proveedor.

Como soy muy de Debian y distribuciones basadas en el mismo, como Ubuntu, vamos a hacer la instalación y configuración en esta última, concretamente en Ubuntu 12.04 LTS.

Configurar Microsoft Azure

  1. Configurar una nueva red virtual de Azure preparada para la conexión VPN site to site. Hay un artículo detallado aquí; pero también podéis ver el video de la charla que Alberto y servidor dimos en el TechDays 2014 de Microsoft.
  2. Crear una puerta de enlace. Basta con hacer clic en la opción correspondiente. Recordad que utilizaremos enrutamiento dinámico. Este proceso es simple pero a Azure le llevará entre 15-30 minutos en completarlo. Tenemos la excusa perfecta para un café 🙂

    Botón de selección de tipo de gateway en el momento de su creación.
    Botón de selección de tipo de gateway en el momento de su creación.
  3. Tomar nota de la IP de gateway y de la pre-shared key. Las necesitaremos para configurar strongSwan en Linux.

    Pre-Shared Key del gateway de Azure
    Pre-Shared Key del gateway de Azure

Configuración de Ubuntu con strongSwan

  1. En primer lugar instalamos strongSwan:

  2. Editamos el archivo de configuración /etc/ipsec.conf:

  3. Ahora debemos editar /etc/ipsec.secrets para establecer nuestra pre-shared key:

  4. Para finalizar, debemos instruir a iptables qué trafico es el que debe direccionar a través del túnel que hemos establecido:

Si todo ha ido bien, deberíamos ver la siguiente pantalla en el portal de Azure:

Pantalla de estado de nuestra conexión VPN site to site con Microsoft Azure
Pantalla de estado de nuestra conexión VPN site to site con Microsoft Azure

No hay que olvidar también que para que el kernel de Linux haga forwarding de nuestros paquetes es necesario habilitar dicha característica:

Si queremos que este cambio sea permanente hay que eliminar la marca de comentario (#) en la línea net.ipv4.ip_forward=1 en el archivo /etc/sysctl.conf.

Hecho esto, nuestras máquinas on-premises deberían ver perfectamente las que se encuentran en nuestra red virtual de Azure y viceversa.

Os dejo por último con la charla que Alberto y servidor dimos sobre estos temas, que aunque hablábamos de openSwan, la configuración y el trabajo para ponerlo a punto era muy análogo, por lo que lo podéis ver todo de forma muy gráfica.

Happy networking!