Archivo de la etiqueta: linux

Gestión de Azure Storage con Azure CLI

Siguiendo un poco la estela de este otro post, me gustaría hablar del tratamiento que ofrece Azure CLI respecto al almacenamiento o Storage.

Con el conjunto de comandos que Azure CLI destina a este apartado, se podrá llevar a cabo una gestión de los diferentes elementos de almacenamiento, los cuales serían los siguientes:

  • Blobs: datos no estructurados, por ejemplo archivos multimedia.
  • Colas: almacenamiento fiable de mensajes.
  • Tablas: datos NoSQL estructurados.
  • Ficheros: compartición de archivos y datos comunes, basado en el protocolo SMB.

Al igual que cuando se introdujo el Azure CLI en el anterior post, la ayuda continua todos los comandos relativos al almacenamiento. Para mostrar dicha ayuda especificando los comandos relativos al almacenamiento, bastaría con escribir:

Azure CLI storage help

Puesto que es bastante extensa, puede ser conveniente refinar más especificando con más detalle el asunto. Así, si por ejemplo se quiere mostrar la ayuda solo referente al elemento blob, entonces:

Hay dos variables importantes que hay que establecer para poder acceder a los elementos: AZURE_STORAGE_ACCOUNT y AZURE_STORAGE_ACCESS_KEY. Esta asignación se puede realizar directamente en un script o en el bash:

La clave de la cuenta (storage access key) se puede descargar desde el portal de Azure. Una vez conectados, para ver las cuentas de almacenamiento de la subscripción seleccionada basta con indicar:

con lo que mostrará todas las cuentas de almacenamiento con que cuenta esa subscripción.

Azure CLI storage account list

Para no ser demasiado exhaustivo, y puesto que la ayuda es autodescriptiva, pondré como ejemplo a los blobs y algunas de sus operaciones.

Los blobs se almacenan en contenedores. La instrucción que crea un contenedor es la siguiente:

Si se quieren ver todos los blobs que hay en un contenedor determinado, la consulta sería la siguiente:

Azure CLI blob list

Por otro lado, para descargar un blob o subirlo, las órdenes respectivas serían la siguientes:

O si se quieren copiar blobs de diferentes cuentas de almacenamiento de forma asíncrona:

y para comprobar el estado de la copia:

Finalmente, para eliminar un blob:

Con respecto a los comandos relativos a los ficheros, tablas y colas, es posible realizar las típicas operaciones sobre estos tipos de elementos (crear, eliminar, mostrar). En la ayuda de Azure CLI se muestra con detalle dichas operaciones, aparte de otras como la gestión de la políticas de acceso de ficheros, tablas y colas, por lo que no es necesario repetirlas.

Y esto es todo por ahora. Espero haber contribuido un poco al conocimiento de esta versátil herramienta.

Administración de servicios de Azure mediante CLI

Hoy voy a a hablar de la interfaz de línea de comandos de Azure, o CLI de Azure. Dicha CLI provee al usuario de una serie de comandos de código abierto basados en shell que permiten crear y administrar recursos de Azure. Esto supone la gestión de servicios y aplicaciones utilizando scripts desde la línea de comandos.

La CLI de Azure está escrita en javascript y necesita de Node.js, tecnología que permite trabajar con javascript desde el lado del servidor, empleando un modelo asíncrono y controlado por eventos.

Cabe destacar que una de las cosas hacen interesante a esta herramienta es su carácter multiplataforma. De esta forma, existen instaladores para cada una de las tres plataformas soportadas:

  • Windows
  • Mac
  • Linux

Otras dos métodos de instalación serían las siguientes:

  • Instalación previa de Node.js y npm, para posteriormente instalar Azure CLI.
  • Ejecución de la CLI de Azure como contenedor de Docker. Consistiría simplemente en ejecutar en un host de Docker ‘docker run -it microsoft/azure-cli’.

Ahondando más en la segunda forma de instalación y tomando como referencia para este post la versión para Linux, (en concreto, Xubuntu 14.04), la misma vendría dada con la instalación de tres paquetes:

Instalados estos tres paquetes, Azure CLI ya estará disponible en el sistema.
Por lo tanto, desde una ventana de consola, escribiendo ‘azure help’ mostrará información de ayuda diversa:

azure help

  • Versión de la herramienta. En este caso, la versión es 0.9.12
  • Comandos disponibles, agrupados según temática. Así, por ejemplo, para ver todos los comandos relacionados con la gestión de máquinas virtuales y las opciones aplicables, habría que indicarlo mediante el siguiente comando:

azure help vm

  • Modo de implementación seleccionado actualmente. Azure cuenta con dos modelos de implementación distintos para crear y gestionar recursos: el Administrador de Recursos (‘Azure Resource Management‘) y el Administrador de Servicios (‘Azure Service Management‘) o módo clásico. Por defecto, está seleccionado el modo clásico. Para cambiar de un modo a otro, se emplea el comando ‘azure config mode <arm|asm>’. Ambos modos son excluyentes entre sí, de manera que los recursos creados en un modo no se pueden administrar desde el otro. Entonces, si se quiere cambiar al modo de Administrador de Recursos, el comando sería:

El primer paso que hay que llevar a cabo para poder gestionar los recursos es poder acceder a los mismos. Para ello, se cuenta con tres formas de acceder a una cuenta y sus subscripciones:

  1. Accediendo a una subscripción, utilizando para ello el Directorio Activo (AD) o una Cuenta Microsoft (Microsoft Account).
  2. Mediante un archivo ‘publishsettings‘ de una subscripción descargado del portal de Azure.
  3. Mediante un certificado.

Tomando como ejemplo la segunda forma, habría que descargar el archivo publishsettings con un navegador e importarlo. Para llevar a cabo esto, se ejecutaría lo siguiente:

Con lo que se abriría la página del navegador (si no lo hiciera, basta con seguir el enlace que se indica), se introducirían las credenciales de la cuenta y se descargaría el archivo. A continuación, se importaría con el comando:

Una vez importado, el archivo se puede eliminar. Si hay otros archivos publishsettings que importar, los pasos a seguir son los mismos. Para ver todas las subscripciones que han sido importadas:

donde se mostrarán el nombre de la subscripción, su id, si está o no actualmente seleccionada, y el estado.

Para seleccionar una subscripción determinada y así poder gestionarla:

Y a partir de este momento, ya se pueden administrar los recursos de esa subscripción seleccionada. Por ejemplo, para ver una lista de las máquinas virtuales:

O se quiere crear un regla de firewall para una base de datos:

Por supuesto, todos los comandos de Azure CLI son susceptibles de ser incluidos en un script, con lo cual posibilita la automatización de ciertas tareas que pueden resultar pesadas, sobre todo si no se tiene acceso a Powershell.

Y esto es todo por ahora. Espero que este post haya servido para, por lo menos, dar una rápida visión de esta interesante herramienta.

Azure Site Recovery: Mobility Service en GNU/Linux

Quizá no hemos tenido todavía ocasión de hablar en este blog de Azure Site Recovery, la solución de recuperación de desastres ofrecida como servicio desde Microsoft Azure. Este servicio mantiene una sincronización de nuestra infraestructura on-premises, ya sean máquinas físicas, Amazon Web Services, Hyper-V o VMWare con Azure; y puede realizar una operación de failover y levantar todo el entorno en caso de desastre para seguir dando continuidad a nuestro negocio. La doble vertiente de lo que os acabo de contar, es que si estamos sincronizando nuestra infraestructura con Azure, podemos deducir fácilmente que este escenario es muy válido para realizar una migración a Azure de nuestra plataforma actual, beneficiándonos de RTOs y RPOs realmente bajos.

El tema que me ocupa hoy sobre Azure Disaster Recovery es hablaros de una casuística concreta, pero muy común en los entornos de protección o migración de VMWare, AWS o máquinas físicas a Azure: el soporte del Mobility Service en GNU/Linux. El Mobility Service es un agente que se instala en las máquinas a proteger o migrar desde Windows y GNU/Linux. Este agente se integra con el kernel de la máquina en cuestión e intercepta las llamadas de E/S de disco, enviándolas al Process Server para que sean comprimidas, cifradas y enviadas al Master Target Server en Azure.

Si miramos las distribuciones de GNU/Linux actualmente soportadas, veremos que las opciones no son especialmente amplias. Tenemos las siguientes:

  • CentOS 6.4, 6.5, 6.6 (amd64)
  • Oracle Enterprise Linux 6.4, 6.5 (amd64)
  • SUSE Linux Enterprise Server SP3 (amd64)

Hay distribuciones muy comunes en entornos productivos empresariales que quedan fuera de esta lista, como Redhat Enterprise Linux, o Debian y las basadas en la misma, como Ubuntu. Lo primero que se le viene a un sysadmin a la cabeza, es que, si conocemos bien la distribución en la que queremos implementar el servicio, basta con adaptar el paquete de instalación, sistema de paquetes y sus scripts para que se instale en nuestro sistema. Así podríamos usar alien para convertir los RPM en DEB y editar los scripts para adaptar el sistema de arranque y las rutas… Craso error…

Como he comentado al principio de este artículo, este agente se integra con el kernel de Linux, que como los más técnicos sabréis se trata de un kernel monolítico, con la estructura que podéis ver en la siguiente imagen, cortesía de Wikipedia:

image

Como se puede ver, la totalidad del sistema operativo opera en modo kernel. Como todo en la vida, los kernels monolíticos tienen ventajas e inconvenientes sobre otras arquitecturas de núcleos de sistemas operativos, como los microkernel y los kernel híbridos. En cualquier caso, una de las consecuencias de este modelo es que si vamos a desarrollar algún software que requeire trabajar a bajo nivel con el sistema, probablemente debamos implementarlo dentro del kernel, seguramente como un módulo del mismo. Si desarrollamos un módulo para el kernel de Linux y realizamos una compilación para una versión determinada del kernel, este binario sólo se puede incorporar en la versión exacta del kernel para el que ha sido compilado. Por ejemplo, imaginad que desarrollamos un módulo para la versión 3.2.0; esta sólo se podrá ejecutar en esta versión concreta del kernel y en ninguna otra.

Cuando examiné el contenido del paquete de instalación del Mobility Service pude ver lo siguiente:

image

Y si examinamos el script install_vx podemos ver lo siguiente:

image

Esto empieza a pintar a versiones muy concretas del kernel en distintas distribuciones… Me temo que como nos salgamos de esto no vamos a lograr que el servicio funcione. Si vamos un poco más allá y examinamos los contenidos del paquete InMageVx-8.4.0.0-1.x86_x64.rpm descubrimos los siguientes archivos:

image
Y aquí definitivamente nos encontramos con los módulos del kernel y la versión concreta para la que están preparados. Llegados este punto, la única forma de la que podríamos hacer funcionar el Mobility Service sería instalando en nuestra distribución la versión concreta del kernel para la que está soportado. Tened en cuenta que aunque llevásemos a cabo esta acción, estaríamos totalmente fuera del soporte que Microsoft da a la solución, por no mencionar que es toda una temeridad cambiarle el kernel a un sistema del cual pretendemos hacer un plan de Disaster Recovery o una migración con RPOs y RTOs cercanos a cero.

Así pues terminamos con las siguientes conclusiones:

  • El Mobility Service de Azure Disaster Recovery sólo puede instalarse en las versiones de GNU/Linux concretamente soportadas: CentOS, Oracle Linux y SUSE Enterprise Linux en sus versiones y arquitecturas concretas.
  • Puesto que la intercepción de la E/S de disco de la máquina se realiza a bajo nivel desde el mismo kernel, el driver del agente está implementado como módulo del mismo. No podemos adaptarlo a otras versiones del kernel porque sólo tenemos los binarios.
  • Las alternativas que Microsoft podría implementar para dar un soporte a más distribuciones sería:
    • Distribuir el código fuente del agente de forma que se compile durante la instalación. Esto haría el agente mucho más universal y no dependiente de versiones concretas del kernel.
    • Proveer de un buen número de binarios que soporte las versiones del kernel más comunes que se pueden encontrar a día de hoy.

De una forma u otra, esperamos que Microsoft de soporte a un rango más amplio de distribuciones de GNU/Linux para que este servicio tan potente se haga muy flexible. ¿Quieres aportar tu sugerencia? ¡Déjasela caer en el User Voice de Azure Site Recovery!

Happy migration!

Configurar SNMP en Linux

Una de las múltiples tareas básicas del administrador es obtener toda información precisa acerca de los diferentes elementos presentes en nuestra red.  Existen muchas herramientas que nos pueden facilitar la recolección y procesado de dicha información,  un ejemplo sería SCOM del que ya hablaré en futuros artículos, las cuales se sirven  de una tecnología llamada SNMP para obtener los datos necesarios.

SNMP (Simple Network Management Protocol) fue creado para obtener información de varios sistemas en de una manera consistente. Esta operación, será llevado por agentes instalados en los diferentes dispositivos con el objetivo de ofrecer toda la información posible  utilizando el protocolo SNMP, según demanda, a partir de un archivo conocido como MIB, en el cual se indica toda la información que podremos recoger y/o cambiar en el dispositivo.

Actualmente existen tres versiones de dicho protocolo :

  • V1 donde  la información es intercambiada a través de mensajes (PDU) entre dos clientes  cuya autenticación se realiza a partir de una cadena de caracteres conocida como community string  en texto plano. Es  la versión más utilizada por ser la más simple, con lo que la utilizaremos en este ejemplo.
  • V2 donde se incorporan nuevos mecanismos de seguridad y se facilita el manejo de información.
  • V3 donde se incorporan más mecanismos de seguridad como encriptación del mensaje así como refuerzo de su integridad además de mejorar los mecanismos de autenticación entre los clientes.

Ahora imaginemos que en nuestra infraestructura  queremos monitorizar un dispositivo de red con Linux instalado (por ejemplo Ubuntu 14.04). Normalmente, en Linux , SNMP no viene implementado ni configurado por defecto, con lo que para poder obtener toda la información que necesitamos, es necesario ejecutar una serie de pasos que se detallan a continuación.

El primer punto a realizar es instalar el demonio de SNMP.

Una vez instalado,   podremos consultar el archivo de configuración  en /etc/snmp/snmpd.conf  donde , para que el agente SNMP sea accesible en toda la red, deberemos cambiar la configuración de la community string , para facilitar la autenticación entre clientes sustituyendo la siguiente línea:

por la línea

donde <red> es la red donde está ubicado el dispositivo, restringiendo así el acceso a todos los ordenadores pertenecientes a nuestra red y public  es la clave de autenticación que podemos cambiar si así lo deseamos.

Por otro lado,  hay que hacer que el agente pueda escuchar las peticiones de otras máquinas para proveer información ya que por defecto, en la configuración, sólo atiende a peticiones de la propia máquina donde está instalado.  Igual que la operación anterior , debemos modifcar el archivo de configuración /etc/default/snmpd  cambiando la linea

por la línea

Finalmente,  deberemos de reiniciar el proceso demonio para que los cambios se hagan efectivos :

Y con ello, ya tendríamos configurado de forma correcta el protocolo SNMP en un dispositivo de red con Linux. Comentar que en futuros artículos, hablaré de la herramienta  SCOM, cómo monitorizar este tipo de dispositivo, así como reforzar la seguridad configurando SNMPv3.

¡Nos vemos!

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!

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!