Archivo de la etiqueta: vpn

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!

VPN Split Tunneling con CMAK

Esta semana me gustaría hablaros sobre cómo crear nuestro cliente vpn para Windows haciendo split tunneling . Pero antes de nada vamos a ver en qué consiste esto del split tunneling.

SPLIT TUNNELING, ¿QUÉ ES?

Cuando establecemos un túnel VPN todo el tráfico es enrutado a través del mismo sin diferenciar el destino. Así por ejemplo, para alcanzar una página web cualquiera ubicada en Internet, esa conexión se enrutaría a la red de la oficina y desde allí iría a Internet. Esto puede ocasionar que el tiempo de latencia sea alto, ya que esa página web o servicio ha tardado más de lo necesario.  Si tratamos con aplicaciones de videoconferencia, que tienen una mayor carga de tráfico la situación se agrava. Aparte del consumo de ancho de banda que supondrá a la red corporativa que se verá sobrecargada a su vez.image

Es por ello, que a veces nos interesa optimizar este resultado. Esto lo podemos lograr por medio del split tunneling. Se trata de una técnica que permite dividir (“split”) el tráfico por medio de unas tablas de enrutamiento que establecemos en el cliente. De esta forma, se discrimina el tráfico, y sólo aquel que va destinado a la red corporativa es dirigido a través del túnel vpn, el resto íría por nuestra conexión normal a Internet.  image

Ventajas

Con este tipo de técnicas conseguimos lo siguiente:

  • Red más eficiente y rápida: sólo redirige el tráfico necesario, reduciendo el número de saltos para alcanzar el destino.
  • Privacidad: debido a que no todo el tráfico es redirigido a nuestra oficina, éste no deja rastro en los dispositivos que pudiera atravesar en la red corporativa.
  • Mayor ancho de banda: la red corporativa no se ve tan sobre cargada debido a que no todas las conexiones no son redirigidas hacia su infraestructura

Inconvenientes

Pero claro, este método puede no sernos útil en todos los casos. Hay ocasiones en las cuales tenemos que seguir empleando nuestra vpn de la forma habitual, ya que tiene sus desventajas:

  • Si la red de origen tiene el mismo direccionamiento no podremos emplearlo, a menos que lo cambiemos, debido a que sería incapaz de enrutarlo correctamente.
  • Aplicaciones vinculadas a ip’s o geolocalizadas: en otras situaciones simplemente es necesario que nuestro tráfico de Internet tenga que salir forzosamente por la red de la oficina.
  • Pérdida de seguridad: debido a que las conexiones que no van por el túnel vpn no está monitorizadas (al no se redirigidas a la propia infraestructura) se pierde control sobre ellas.

INSTALACIÓN DE CMAK Y CREACIÓN DE EJECUTABLE

Connection Manager Administration Kit (CMAK)

Se trata de una herramienta que se emplea para la personalización de conexiones de red remotas, permitiendo crear perfiles personalizados mediante un asistente.

Esta herramienta viene embebida dentro de las características de Windows, pero para poder usarla antes debemos habilitarla. Para ello vamos a “Programas y características”, y seleccionamos el tick de la característica.

Creación de perfiles de conexión

Una vez agregada la característica, podremos empezar a crear perfiles personalizados de conexión.  Ejecutamos la aplicación, que mostrará un asistente que guiará la creación del perfil. Hacemos clic en siguiente, y seleccionamos el sistema operativo en el que se va a instalar.image

Con CMAK también podemos modificar perfiles ya creados con anterioridad, pero para este ejemplo vamos a crear un nuevo, indicando el nombre que queremos que aparezca en las conexiones de red, así como el nombre que tendrá el ejecutable e introducimos el servidor vpn al que nos vamos a conectar.

image

Podemos modificar múltiples parámetros de la conexión como pueden ser los servidores DNS, los sufijos de conexión , así como la estrategia VPN, y la autenticación. image

A continuación y uno de los pasos más importantes (sino el que más) es agregar tablas de enrutamiento, agregándolas mediante un fichero de texto que importamos desde nuestro equipo. Los datos a añadir en nuestro fichero de texto serían los siguientes: primero eliminar la puerta de enlace predeterminada y a continuación añadir cada una de las rutas de nuestra red privada virtual.

REMOVE_GATEWAY
ADD ruta MASK mascara puerta_enlace METRIC default IF default

image

Según sigamos el asistente nos va a permitir realizar gran número de personalizaciones como  agregar la configuración proxy de Internet ,scripts, acciones personalizadas, imágenes, icono de programa, etc.

image

Por último pulsamos finalizar y nos generará un exe con todas las configuraciones que hemos establecido.

image

El ejecutable se encontrará en una subcarpeta con el nombre que le hayamos dado al perfil . Este ejecutable  lo vamos a poder distribuir  masivamente por medio de GPO’s, System Center, etc.

Como comentario final me gustaría indicar que CMAK es una herramienta muy útil para la creación de clientes vpn ya que nos permite crear un ejecutable bastante personalizable y profesional, con la opción, entre otras, de realizar split tunneling.  ¡¡¡Hasta la próxima!!!

Configurar una VPN Point-To-Site en Azure

En anteriores artículos ya habíamos hablado de cómo configurar una red VPN Site-To-Site . En este artículo trataremos otra de las posibles configuraciones de redes privadas virtuales que es posible realizar en Microsoft Azure.

Una VPN Point-To-Site nos permite conectar nuestra máquina local de forma segura a una red virtual de Azure sin necesidad de disponer y configurar un dispositivo VPN o RRAS.  Este tipo de conexiones emplean un tunel hecho a traves del protocolo SSTP con autenticación basada en certificados entre la máquina cliente y la red virtual. Son una buena elección cuando :

  • Son pocas máquinas clientes las que necesitan conectarse a la red virtual de Azure, ya que este tipo de conectividades sólo permite que se conecten hasta 128.
  • No disponemos de un dispositivo VPN para configurar una conexión Site-To-Site, valga la redundancia.
  • Quieres conectarte de forma segura cuando estás offsite (por ejemplo cuando estás en una cafetería).

Como ejemplo, indicar que las  conexiones  de Azure App Service   a las redes virtuales son mediante Point-To-Site.

point2site

Entonces, ¿qué necesitamos para crear este tipo de redes?

  • Crear la red privada virtual y su correspondiente puerta de enlace (o gateway) de enrutamiento dinámico, ya que propicia conexiones más estables que los de tipo estático.
  • Crear los certificados que usaremos para identificar a clientes en la VPN Point-To-Site. Necesitaremos dos certificados, un certificado de raíz y un certificado cliente,  ambos autofirmados.
  • Configurar la máquina local para que se conecte a la VPN. Dicha computadora deberá tener instalado como sistema operativo Windows 7 , Windows Server 2008 R2 o versiones posteriores.

Paso 1.- Configurar la red privada virtual y su gateway.

Para crear la red virtual lo primero es ir a nuestro portal de Azure y en el menú ubicado en el lateral izquierdo de nuestra pantalla haremos click en la sección Networks.

image

Habiendo accedido a dicha sección, crearemos nuestra red virtual haciendo click en New –> Network Services –> Virtual Network –> Custom Create . Nos mostrará la primera página  asistente de instalación de creación de red virtual, donde podremos especificar el nombre y la localización en los campos Name y Location correspondiente. Luego, haremos click en la flecha ubicada en la parte inferior derecha  para avanzar al siguiente paso.

image

En la página DNS Servers and VPN Connectivity, elegiremos únicamente la opción Configure a poin-to-site VPN .

image

Avanzando a la siguiente página del asistente, especificaremos el rango de direcciones IP que los clientes VPN recibirán cuando se conecten. En nuestro caso elegiremos la configuración por defecto.

image

En la última fase del proceso, podremos comprobar que Azure nos ha creado una subred por defecto sobre la cual se conectarán los clientes VPN. No obstante, es posible configurarlo a nuestro gusto. Si queremos usar la red point-to-site  que hemos configuramos, necesitaremos agregar una subred para la puerta de enlace (la cual reserva unas 8 direcciones IP). Basta con hacer click  en Add gateway subnet . Añadido dicho espacio de direcciones,  finalizamos el proceso de creación.

image

Con la VPN ya creada , nos faltaría crear  la puerta de enlace. Basta con acceder a la red creada dentro de la sección Networks y nos iremos a la pestaña  Dashboard . En dicho menú, para crear la puerta de enlace bastará con pulsar el botón Create Gateway ubicado en la parte inferior de la pantalla.  Azure nos creará una puerta de enlace de enrutamiento dinámico. No os preocupéis si el proceso de creación tarda.

image

Paso 2.- Creación y agregación de los certificados autofirmados

Como ya hemos dicho, la necesidad  de crear certificados autofirmados se debe a que la conectividad point-to-site usa autenticación por certificados por encima del uso de contraseña de usuarios.  Aquel que no posea el certificado cliente instalado de forma correcta no podrá conectarse a nuestra red virtual, incluso si de alguna manera obtiene la dirección IP de la red.

Antes de nada, deberemos crear el certificado raíz para que lo podamos subir al portal de Azure. Nos valdremos de la herramienta makecert.exe (la cual deberemos tener en nuestro equipo local). Y despues ejecutaremos los siguientes comando desde CMD o Powershell  (la opción elegida en este ejemplo) con el nombre del certificado que nosotros queramos. En este caso utilizaremos “<Certificado_Root>” .

Posteriormente creamos el certificado raíz  (al que llamaremos <CertificadoCliente>) , para ello y sin movernos de la consola, escribiremos lo siguiente :

Ya creados , los exportaremos  para poder instalarlos en sus correspondientes sitios empleando la herramienta  certmgr.mscAllí los encontraremos dentro de la carpeta Personal donde procederemos a exportarlos, empezando  el certificado de raíz, haremos click derecho y seleccionaremos  la opción de exportar.

image

Indicar que en el certificado raíz no hay que exportar la clave privada y que deberemos guardarlo con extensión “.cer”.

image

image

Realizaremos el mismo proceso  con el certificado cliente, pero en este caso sí que deberemos exportar la clave privada y el formato deberá ser “.pfx”. Ya elegido el formato del certificado, deberemos indicarle una contraseña, que usaremos a la hora de instalarlo en el equipo cliente para poder conectarnos de forma segura en la VPN.

image

Una vez tengamos los certificados,  procederemos a su instalación. En el caso del certificado raíz, basta con ir a la sección Certificates dentro de nuestra red en el panel de Azure, donde podremos subirlo presionando en el enlace Upload a Root Certificate :

 

image

Cuando ya se haya subido, nos quedaría instalar el certificado cliente sobre la máquina que queremos que se conecte a la VPN. Si hacemos click sobre él dos veces, introducimos la contraseña que indicamos cuando lo exportamos,  ya lo tendremos instalado.

Paso 3.- Configuración de la máquina cliente

Creados e instalados los certificados, tan sólo nos quedaría configurar la máquina cliente que se conectará a la VPN Point-To-Site.  Desde nuestra pestaña Dashboard  de nuestro portal de red en Azure, observamos  que en lateral derecho en la sección Quick Glance   podremos descargar el paquete cliente VPN según el procesador de la máquina cliente :

image

Cuando hayamos terminado de descargarlo e instalarlo, si nos dirigimos a la sección de redes de la máquina local, tendremos la opción de conectarnos a la red que hemos creado.

image

Y eso es todo, no es un proceso difícil  pero sí algo largo.  Esperemos que os haya gustado. Ahora no tendréis excusa para crearos vuestra propia VPN en Azure.

¡Muchas gracias por leernos!

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!